[RFC] using dt overlays: how to? today?

Hi Ludovic,

On Jan 23, 2015, at 11:07 , Ludovic Desroches [off-list ref] wrote:

Hi Pantelis,

On Thu, Jan 22, 2015 at 10:54:42PM +0200, Pantelis Antoniou wrote:

quoted

Hi Ludovic,

quoted

On Jan 22, 2015, at 17:02 , Ludovic Desroches [off-list ref] wrote:

Hi,

I have assisted to Pantelis' talk about device tree and overlays at ELCE
2014. Since the patch 'Introduce DT overlay support' is now part of the
mainline, I wanted to have a look about it and to use it for our boards.

Excellent.

quoted

Firstly, this is what I want to achieve by using this feature:
- manage several revisions of our boards
- manage modules we can plug on the board, mainly display modules
(resistive or capacitive one)
- manage cpu modules plug on the motherboard
- I would like to have all this stuff in the kernel. I don't want a
dependency on the bootloader or the user space.

That?s awesome; that?s exactly what I want to use it for. Maybe this thing
can be used by others as well ;)

It seems quite close from what you want to achieve with cape manager.

quoted

quoted

At the moment, we have many dts files to manage these cases (not all are
in mainline). It is becoming a pain.

Tell me about it.

You can have a look here:
https://github.com/linux4sam/linux-at91/tree/master/arch/arm/boot/dts

For example, we have up to 6 dts files for a single device:
sama5d36ek.dts, sama5d36ek_hdmi.dts, sama5d36ek_pda4.dts,
sama5d36ek_pda7.dts, sama5d36ek_revc.dts, sama5d36ek_revc_pda4.dts,
sama5d36ek_revc_pda7.dts

Our goal is that customers don't have to care about all this stuff. They
load a single dtb file which can manage all these cases.
The change between revison c and revison d is the i2c device to which
the audio codec is connected. Difference between pda4 and pda7 (which
are display modules with a capacitive touchscreen) can be the irq used
the touch keyboard or the touchscreen.

Information we need are stored in an EEPROM which is accessible through
a one wire bus. As I said, we would like that the customers have no
dependency on other components if possible: bootloader, userspace,
firmware.

Makes sense. I was wondering if I can find another board to test my patches
on. If you send me the boards in question I can put them in my lab and run
my tests against them too.

The patches for the beagle cape-manager will be forthcoming as soon as 3.19 is out;
I have some ideas about board revision control too, but I need to run them through
the maintainers to make sure I don?t go off to the weeds.

quoted

quoted

I wanted to see if we can use device tree fragments as it seems to be
closed to be achieved when I had assisted to the talk. I have found a
thread about 'DT-Overlay configfs interface'
(http://thread.gmane.org/gmane.linux.drivers.devicetree/101871), there
are still discussions about security concerns, so it may not be included
quickly. I have also found an interesting thread about cape manager for
Beaglebone (http://thread.gmane.org/gmane.linux.documentation/8279) but
there is no more activity on it, is it canceled or is there a new topic
I have missed?

Here are my questions:
- Is it acceptable to manage device tree fragments with a driver such as
the cape manager? Or at an other place in the kernel such as
arch/arm/mach-at91/board-dt-sama5.c for example?
- Is it possible to get access to eeprom from the kernel? Pantelis did
an interface to access it through i2c but it seems it was not
accepted. In my case, it will be through the one wire interface.

Thanks for sharing your opinion about this or redirecting me to a
similar thread.

I?m waiting for 3.19 to go out and I?ll address everything you described
above.

Do you think it's too early to use it? We are currently trying to
release a new kernel (based on 3.18) with some patches which have not been
sent or accepted yet. Since I could merge easily your patches from Grant
branch, I thought we could try to use it but spending time on a oneshoot
solution is useless. That's why I would like to know what is the status
since it seems only the sysfs part is still in development.

No it not too early; it just works. The only bit missing is the configfs
interface but we?re getting there.

quoted

Feel free to post specific requirement about your use cases, and I?ll try
to address them.

Thanks so what is the next step? Posting a new patch series or the cape
manager? I mean if you plan to do it, I could have a look on how to
access the EEPROM through one wire.

The next step is the cape-manager/revision manager series, right after 
3.19 is out.

Regards

Ludovic

Regards

? Pantelis