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

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

[Ludovic Desroches]

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.

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.

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

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.

Ludovic
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[Pantelis Antoniou]

Hi Ludovic,

> On Jan 22, 2015, at 17:02 , Ludovic Desroches <ludovic.desroches@atmel.com> 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.

> 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 ;)

> 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.

> 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.

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

> Ludovic
> —

Regards

— Pantelis

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[Ludovic Desroches]

Hi Pantelis,

On Thu, Jan 22, 2015 at 10:54:42PM +0200, Pantelis Antoniou wrote:
> Hi Ludovic,
> 
> > On Jan 22, 2015, at 17:02 , Ludovic Desroches <ludovic.desroches@atmel.com> 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.
> 
> > 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.

> > 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.

> 
> > 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.

> 
> 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.


Regards

Ludovic
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[Pantelis Antoniou]

Hi Ludovic,

> On Jan 23, 2015, at 11:07 , Ludovic Desroches <ludovic.desroches@atmel.com> wrote:
> 
> Hi Pantelis,
> 
> On Thu, Jan 22, 2015 at 10:54:42PM +0200, Pantelis Antoniou wrote:
>> Hi Ludovic,
>> 
>>> On Jan 22, 2015, at 17:02 , Ludovic Desroches <ludovic.desroches@atmel.com> 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.
>> 
>>> 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.
> 
>>> 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.

>> 
>>> 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.

>> 
>> 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

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html