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

Hi Dennis,

If you are trying to use the EMIFA on one of the chip select spaces for the FPGA with custom FPGA code, you will need to write a kernel module driver to provide access to the physical memory in linux. There is a pretty good book online about writing kernel device drivers, it provides some pretty good examples as to how to access external memory space and map it into user space or just plain access it from within the driver module. At some point we will try to provide some additional examples here as well that include drivers for FPGA IP offered by Critical Link for the MityDSP-L138F and MityARM-1808F.

-Mike

Wading through the kernel I haven't spotted a uPP module, will I need to write a module for that also.

Hi Dennis,

It doesn't look like there is a uPP driver for the linux / ARM side available from TI at the moment. They do have drivers for DSP/BIOS, which might work if you wanted to use the DSP core of the OMAP-L138. It may not be too difficult to craft up a driver for the uPP depending on what you are trying to accomplish.

Sorry.

-Mike

Building the uPP driver. I need to register and interrupt service routine.
To do that I need to know the irq number that is generated. The
documentation cover's which wire is asserted, but not what irq number
that causes the CPU to generate. Is there documentation on this?

The information you are looking for is in the OMAP-L138 System Reference Guide, in the ARM interrupt controller section (chapter 12). The event you are mapping is defined in the kernel at arch/arm/mach-davinci/include/mach/irqs.h as IRQ_DA850_RPIINT (not sure why the macro was named RPIINT....).

As you are writing a platform driver, you might want to look in arch/arm/mach-davinci at the device resource initialization and device instantiation for other OMAP peripherals in the devices-da8xx.c. If you can declare your resources to the rest of the kernel and reserve them using the platform framework, it's always a good idea. This way the /proc information is more accurate, and you are safer in terms of avoiding other drivers trying to use the same set of resources...

-Mike

Interrupt number 91 (aka IRQ_DA850_RPIINT) works. It works, when I queue a DMA write I get an interrupt when it is complete. Thanks for the pointer about the platform drivers. I've used the primitive "request_mem_region" and "request_irq" described in the "Device Drivers" book you pointed me to; I'll look at the platform stuff as soon as I get a chance. What I don't understand now is why the "digital loopback" isn't looping the data written to the Q channel back to the I channel. I've probably mis-set/not-set something in one of the registers. Thanks for the help.