Re: [PATCH v2] ARM: dts: am335x-bone-common: Add i2c2 definition

[Pantelis Antoniou]

Hi Javier,

On May 13, 2014, at 7:39 AM, Javier Martinez Canillas wrote:

> On Tue, May 13, 2014 at 4:22 PM, Matt Porter <matt.porter@xxxxxxxxxx> wrote:
>> On Tue, May 13, 2014 at 04:06:02PM +0200, Javier Martinez Canillas wrote:
>>> On Tue, May 13, 2014 at 2:53 PM, Tom Rini <trini@xxxxxx> wrote:
>>>> On 05/12/2014 04:57 PM, Robert Nelson wrote:
>>>>>>> Either case if fine with me.  As who knows when the dtc "overlay" will
>>>>>>> every truly make it mainline, as the capemgr was the only real kernel
>>>>>>> user of the i2c/at24 eeprom information.
>>>>>> 
>>>>>> Sounds like we should keep it disabled though so u-boot can be used
>>>>>> to toggle it while waiting for the capemgr. That's because the board
>>>>>> has a header for pins, so it's not exactly limited to just the capes.
>>>>>> 
>>>>>> Anybody working on enabling/disabling cape dtb configurations in u-boot?
>>>>> 
>>>>> Well,
>>>>> 
>>>>> Would Tom even approve of that in mainline u-boot? He didn't want my
>>>>> "invert" the gpio to enable the usb hub on the older beagle xm A/B..
>>>>> 
>>>>> http://lists.denx.de/pipermail/u-boot/2014-January/172154.html
>>>>> 
>>>>> http://lists.denx.de/pipermail/u-boot/2014-January/172274.html
>>> 
>>> Using fdt set from the bootloader to use the same FDT for similar
>>> boards (like the example with Beagle xM variants) is kind of trying to
>>> replicate what we used to do from boards files where it was possible
>>> to manage a set of boards using the same platform code.
>>> 
>>> But Device Trees are meant to describe hardware and thus should be
>>> static, if two board are almost identical but slightly different, then
>>> are two different hardware where each need its proper FDT that
>>> describes it.
>>> 
>>>> 
>>>> I would think that using the 'fdt' command in U-Boot to add all
>>>> properties of every cape found on a running system would drive someone
>>>> to madness quite quickly.  Moving all of Pantelis' work for dynamic
>>>> device trees from the kernel to N bootloaders (U-Boot, barebox, UEFI,
>>>> etc) sounds like a step in the wrong direction.
>>>> 
>>> 
>>> Agreed. I think that until the device tree overlay and the cape
>>> manager find their way into mainline we should treat capes as if they
>>> were expansion boards attached to a Computer-on-Module. That is, a
>>> static based board which its own DTS including the BB{B,W} as an dtsi
>>> and not something that can be added on runtime.
>> 
>> It's far more complicated than a SOM plus carrier board. Consider that
>> you can have any 4 of these capes stacked on the BBB/BBW in any
>> combination (assuming no resource conflicts). Capturing all possible
>> combinations in static dtsis is not practical.
>> 
> 

Since this appears to be all coming back to DT overlays, let me try to 
address some points.

> Right, I forgot that the capes were stackable so is indeed not
> practical to model every single combination as DTS in mainline. Even
> if stacking was not possible there are just too many capes out there
> to have a DTS for every single cape.
> 

Each cape does have a DTS as dynamically loaded fragment; it works absolutely fine.

Trying to come up with a base DTS for all the capes you've stacked up
is an exponential problem.

> My point was that someone who wants to use a BBB + a set of capes can
> today write a DTS for its own stacked setup.
> 

No, the guy that designs a cape (or learns how to) can not write a DTS for
the base board and the cape in question. Doing that he essentially cuts
himself off from the community.

Let me explain, the point is for people to easily design capes, open-source their
design as well as their software, and share them to the community.

This requires that things are easily shareable.

Requiring a relative newbie in kernel development not only generate his own
base DT, but also to merge all of the other capes DT into his own is a
nightmare.

BTW, on another tangent, it's not just the BB people that care about dynamic
hardware configuration. There are a number of FPGA people that seem interested
as well.

The notion of hardware as something static that never changes is obsolete IMHO.

> Unfortunately I don't have a solution but what I'm pretty sure is that
> mangling the DTS from the bootloader is not the right one :-)
> 

No, it is not. And this is what we're trying to solve here.

>> -Matt
> 
> Best regards,
> Javier

Regards

-- Pantelis

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/