Re: [RFC] About ARM expansion boards and others things

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



2011/5/4 Igor Grinberg <grinberg@xxxxxxxxxxxxxx>:
> On 05/03/11 20:25, Enric Balletbà i Serra wrote:
>
>> Hi guys,
>> I'm thinking probably in a crazy idea, I hope someone can help me or
>> kill definitely this idea from my mind.
>
> This is not that crazy as you think it is...
>
>> I'll explain a little more, the real problem is I don't know how to
>> add support for an expansion board for IGEP v2 board. I see most of
>> boards adds the support inside the board-xxxxx.c file, for example if
>> the expansion board has a Touchscreen interface using ADS7846/TSC2046
>> they register ads7846 platform data in board-xxxx.c file. This is ok
>> beacause the ads7846 can be detected and if expansion board is not
>> present Âthe detection fails, but maybe other devices in expansion
>> board can't be detected (for example an I/O expansion). So which is
>> the best form to do this ?
>>
>> I'm thinking in create a kernel module for the expansion board that
>> add all the new features, the expansion board should come with a I2C
>> E2PROM for board ID storage, so the idea is create an i2c driver that
>> reads the E2PROM and if found the Board ID inits all the expansion
>> board devices.
>
> Why do you need to create a new driver? Why don't you use the existing one?
> at24 works nice with most i2c EEPROMs.
>
> Let me generalize:
> 1) Lets call each board that actually has SoC, like IGEP, a System On Module (SoM)
> 2) SoM has on-board and on-SoC devices
> 3) expansion has additional on-board devices
> 4) We are talking about X SoMs and Y extensions
> 5) Each SoM can be connected to each extension and communicate with its devices.
> 6) We are looking for a solution to be able to detect the expansion and register
> Â the devices it has assembled.

Great generalitzation !

>> I have done a few experiments, I've created a kernel module (driver)
>> for a custom expansion board for IGEP v2, Âthe expansion board has :
>> Â Â- I2C E2PROM
>> Â Â- ADS7846 touch controller (spi)
>> Â Â- Seiko 7.0inch LCD
>> Â Â- General purpose I/O
>>
>> The driver is capable to register correctly i2c and spi devices and
>> seems is working but I have problems with the Seiko 7.0inch LCD and
>> configuring the MUX from driver.
>
> Like Tony already said the generic MUX API should solve the problem of MUX.
> But, you will still have a problem with devices that have to be initialized
> very early, like IO chips.

Right, about the MUX, there is any patch or specification for the MUX API ?

>
>> Basically I wonder if it's possible add another omap_dss_device from
>> kernel module to the omap DSS driver (something like
>> omap_dss_register_new_device). Is a good or bad idea ? Why ? Is any
>> reason to not export the MUX functionality to be used for other
>> drivers ?
>
> ...
>
>> All of this is a crazy idea ? What's the best form to solve the problem ?
>
> This is not crazy at all.
> We already use this concept in our BSP, we detect the expansion
> by reading data from EEPROM, and register the devices accordingly.
> We solve the MUX problem by initializing the pins to some default state
> and once the expansion detection is done, we reconfigure the pins
> to their right state as required by connected devices.
>
> And yes the above is done from board file.

So its possilbe read the EEPROM in board file ? How ? I was thinking
wasn't possible read the EEPROM in board initialitzation because was
in a early state.

> I don't see any reason to create a driver for the expansion,
> unless it can be removed/attached "on the fly" while the SoM is up and running.

Completely agree, normally expansion board can't be connected "on the fly"

>
> Nevertheless, some framework or at least an agreement on how we should
> separate the SoM code from the expansion code.
>
> I thought of some convention like board-*.c will stay the code for the SoM
> and exp-*.c will be used for the expansion code.
> Now, the code in board-*.c will do the detection of the expansion and
> run the appropriate exp_*_init() function, which will do the initialization steps
> for the detected expansion.
> A bit more complicated solution will be needed if there are several expansions
> connected all together.
>

Looks good for me if this is the accepted solution.

> I have had this in my mind for very long time, but did not want to bother,
> because there were discussions about a totally different approach which uses
> device trees (DT), where the detection of expansion is moved away
> from the kernel code.
>
> With the DT approach, the kernel (should) get(s) all the information regarding
> the devices and how they are wired for free (no detection).
> If I understand correctly, the information about devices
> (whether on SoM or expansion) could be either statically added to the DT
> structures or dynamically detected by the bootloader and passed to the
> kernel (like ATAGS work now).

Really interesting, I'll look that, do you think is the future to
solve this problem ? Have you tested ?

>
> I still doubt what approach would be better...

Me too, but I think it's interesting doing a brainstorming about this
theme because it's a common problem for board manufacturers.

Regards,
   Enric
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [Linux Arm (vger)]     [ARM Kernel]     [ARM MSM]     [Linux Tegra]     [Linux WPAN Networking]     [Linux Wireless Networking]     [Maemo Users]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite Trails]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux