Mity CPU Platforms » MityDSP-L138 (ARM9 Based Platforms)

Hi Scott,

Unfortunately, TI (nor Critical Link) provides linux drivers for the UPP.

The memory map that includes the base address of the UPP peripheral is in the OMAP-L138 specification. The register details for the UPP and how to set it up is located in the UPP User's Guide. We have been successful in using this device with the DSP core, but have not tried to use it from the ARM/linux space.

You might consider posting to the TI E2E website to see if anyone else has done this and could provide example code.

Good luck!

-Mike

Mike,

Thanks for the link to the OMAP specification. I think that is all I needed to start work on my driver. In the default mityDSP configuration, are the clocks and power enabled to the uPP? I assume I will need to set the pin mux for the uPP?

thanks, Scott

You will definitely need to configure the pin mux. You should assume that the UPP is powered down (in the reset state) as well. You may need to add the UPP clock to the clock tree in linux and turn it on, I haven't checked if that has even been defined yet.

-Mike

Mike,

Where is the clock tree? I think I have printed out the uPP status and control register, and if what I'm looking at is correct it is partially enabled, only the local reset is asserted. Scott

check arch/arm/mach-davinci/da850.c

There is likely a clock that needs to be defined/enabled for the UPP.

Also there is a power and sleep controller register that may need to be enabled (part of the same clock structures in linux, I think) to take the UPP controller out of reset if you enable the peripheral.

-Mike

Mike,

I see there is nothing in the da850.c file for the uPP, either for clock, or pin muxing. I could just write a kernel module to access the pin mux and PSC registers directly if I don't want to mess with recompiling the whole kernel? thanks, Scott

Sure you can, though the pinmux setter/getter routines in the kernel are not currently exported.

-Mike

Mike,

I was just planning on mapping the registers and accessing them that way. It looks like there is a specific method for setting the module PSC out of reset, but I assume just writing the correct pin mux value to the register will set the muxing? I also need to preserve the muxing setup for the GPIO (programing and interrupt) if I want to use the base module. It looks like that is set in PINMUX register 13, and not shown in the TI pinmux utility.

Mike,

I have a couple questions here. I am attempting to write a upp userspace loopback driver/routine. I have memory mapped the pin mux registers, PSC1 registers and the upp registers. I am unsure if the pin mux changes are in effect. To test I attempted to clear out MUX13 which comes in at 0x8808 at bootup, but zeroing this out does not take. I was setting the KICK0R and KICK1R registers to unlock the SYSCONFIG if that is still necessary. Is there something I am missing?

As far a power and clock, if the module is not getting power and clock then I would not be able to write to the upp control registers?

I'll try and post my code. Any help is appreciated, Scott

Hi Mike,

I am looking for a uPP driver for linux and I was searching around when I came across this thread. I know im replying to a very old thread, but I noticed that you mentioned that critical link does not have a uPP driver yet. From the other threads in this forum its not clear whether such a driver has been developed or not. So I was wondering whether you could help me out in connecting an ARM with an FPGA through the uPP interface? More specifically, I am interested in connecting an AM1808 with a Spartan 6 FPGA for transferring a custom raw video stream.

Regards,
Shahzad

Hello Shahzad,

Unfortunately, there is still no UPP driver available. Have you looked at pushing the data in using the VPIF? Supposedly, there has been some work done by TI to push a couple of different modes of camera data using the Video 4 Linux framework (V4L) using the VPIF peripheral driver under linux.

Are you planning on converting the stream in the ARM, or just capturing or routing it directly to a framebuffer?

-Mike

Hi Mike,

Thanks for the prompt reply. Actually the data stream is from an H.264 encoder in an FPGA, so im not sure if VPIF would be helpful here. Thats why I was looking for a uPP driver. The other option seems to be the EMIFA interface on the AM1808. What do you say?

Regards,
Shahzad

If you are not using the on-Board NAND in your design (e.g., booting to a RAMDISK or off of MMC or something), then the EMIFA would probably work. Though, you may still have to roll up a kernel module/driver to fetch the data (I would recommend using an EDMA rather than CPU polled I/O). You should be able to push at least 40 MB / second (100 Mhz clock @ 16 bits with 5 wait states per read -- conservative). But if the NAND is in play, you might stall longer than you can afford to while the bus is off reading or writing to the NAND.

If you are comfortable writing linux kernel code, the UPP interface as actually very simple -- particularly if you have a fixed application in mind. I think part of the reason that there isn't a general purpose UPP driver written for linux is that it is rather flexible (2 ports, 8 or 16 bits wide, input or output, etc.) and the processing of the data for it ends up being very application specific. That and the UPP only seems to be available for a very limited number of the more recent SOCs from TI (i.e., only the OMAP-L1XX family).

We could probably assist you in at least putting together a data mover portion of a linux UPP engine for you, but we might need a small support contract put in place for that. At the moment, I don't think there is any active work on it here. We normally use the DSP core on L138 to interface with FPGA's with the UPP. We prefer the RTOS of DSP/BIOS for prepping inbound high speed data.

If you don't mind me asking... Are you using the AM1808 to decode the H.264? Does it have enough muscle? We've only used the OMAP-L138 to decode H.264 (D1 as well as 800x600) by leveraging the CODEC framework and the DSP core with TI's gstreamer customization. I haven't tried lower resolutions, but the ARM-9 on the AM1808 labored (read: was way too slow) on the larger stuff.

-Mike

Shahzad, I have not found uPP drivers for the ARM in linux. My suggestion in developing them is to read the TI uPP manual, get it working in loopback mode and them transition that to you application. Be sure you set the pin mux for the uPP. I do it when I load the driver instead of rebuilding the kernel with the correct pinmux. The main.c is my attempt to loopback the uPP from 1 channel back to the other. I map the pinmux registers, set the correct pinmux for them uPP, then map the uPP control registers to do a transfer from channel a to channel b. The missing header files I believe just describe the pinmux registers and uPP control registers. Good luck, Scott

@Mike

Thanks for the detailed answer. We are only using the AM1808 as an embedded video server for the stream coming from the FPGA, so I cannot comment on the AM1808's H.264 decoding capabilities. But we have used the AM1808 to stream video using the LIVE555 media server (from a locally stored file) and we are satisfied with its performance. The next step is to stream the output of the FPGA-based H.264 encoder.

We are not using the on-Board NAND, so I think EMIFA could be one option. But given that the amount of effort (in terms of writing a device driver) is the same, Im thinking of uPP. Do you think we could get more than 40MB/sec with uPP?

As for getting assistance, I will have to talk to the rest of the team and get back to you.

@Scott

Thanks for your input. Which main.c and header files are you referring to?

Regards,
Shahzad

We have demonstrated capturing as high as 100 MB/sec using UPP in 180 MB blocks without issue. So it's feasible. If you are using the LCDC controller, make sure it gets the highest bus master priority (and use some fifo'ing in your FPGA UPP interface).

-Mike