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

Thanks. This is the first of the steps we needed to understand.

I don't think we'll need help with the hardware itself; we have a guy here who's designing and building it, and as long as we can make the da8xx structures and 138 tables set up the system for him, we're all set. We'll let you know.

We will now focus on making sure we can build the kernel and then try to make those changes.

In the wiki entry on setting up the LCD, the i2cset command was used to set a couple addresses in chip 0x38. Did that only apply to the DVI and not the LCD? If it applies to the LCD, is there documentation on what those addresses on the chip do so we can set them for the LCD we are attaching.

The TFP410 DVI interface chip is located at address 0x38 on the i2c bus. The link provided at TI allows access to the data sheet for the part, which contains a full address map for the part. The TFP410 allows using the LCD peripheral on the OMAP-L138 or ARM-1808 (on the corresponding MityDSP-L138 or MityARM-1808 modules) to drive a DVI output interface used by most monitors. This chip needs to be configured properly if you are using the DVI interface on the Industrial I/O board. The register settings are the minimum required to ensure proper operation with the current LCD driver configuration supporting VGA (640x480) resolution.

Keep in mind, that for the MityDSP-L138F or MityARM-1808F (modules including an FPGA), the LCD peripheral pins are routed to the FPGA. The FPGA must be programmed to then route the signals to the SoM edge connector. This was done to provide more flexibility to folks that might need more FPGA I/O and might not require a LCD or DVI panel. On non-FPGA versions, the LCD output pins (also multiplexed with some of the uPP pins) are routed directly to the edge connector of the module.

Interaction with this chip is not necessary if you are using a different interface connected to the LCD peripheral (e.g., an LCD). Note, that you can't use both the DVI and the external LCD on the Industrial I/O card at the same time (unless they both support identical timings or you can tweak the timings between the two in the FPGA, which is highly unlikely).

-Mike

Great. Sounds like for our purposes we probably don't need these commands, since we're connecting the LCD through the FPGA. We'll follow up further if that turns out not to be the case.

I need to access spi0. It appears something related to it is compiled into the kernel (devices-da8xx.c/.o). But I don't see a mechanism on the running platform to load/access the device.

On the current industrial I/O kernel configuration, SPI0 is disabled as pins associated with it are used for the MII interface. I assume you are using a custom host board solution.

Do you need access via ARM? or DSP?

If by ARM, you will need to modify the kernel by updating the arch/arm/mach-davinci/board-mitydspl138.c file and enable the spi0 port and appropriate chip-select line, defining the device attached and the SPI configuration. In addition, you will need to ensure that the MII ethernet interface is disabled (and configure the correct pin-mux settings). You should be able to follow along from the SPI1 configuration.

If your device isn't one that is already supported by the linux kernel, you might consider instantiating the "spidev" device, which allows for writing userspace libraries for communicating with spi-port. See the Documentation/spi/spidev in the kernel source tree for more information.

-Mike

We are looking at the user space solution. My hardware person says I'm wrong, he has attached the device I need to access to spi1.