Re: [PATCH v2] ARM: dts: am335x-bone-common: Add i2c2 definition
Hello Jhon,
On Wed, May 14, 2014 at 7:44 AM, John Syn wrote:
>
> On 5/13/14, 8:39 PM, "Pantelis Antoniou"
> wrote:
>
>>Hi John,
>>
>>On May 13, 2014, at 1:24 PM, John Syn wrote:
>>
>>>
>>> On 5/13/14, 10:51 AM, "Javier Martinez Canillas"
>>> wrote:
>>>
Hello Pantelis,
On Tue, May 13, 2014 at 7:07 PM, Pantelis Antoniou
wrote:
> 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
>> 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 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.
>
It seems that you misunderstood my comments. I do think that DT
overlays and the cape manager are a great solution for any hardware
that could be expanded on runtime and I really hope that they can
eventually land into mainline.
In fact if you look on my previous mail you will see that I said:
"until device tree overlay and the cape manager find their way into
mainline..."
>> 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
Re: [PATCH v2] ARM: dts: am335x-bone-common: Add i2c2 definition
Hello Jhon,
On Wed, May 14, 2014 at 7:44 AM, John Syn john3...@gmail.com wrote:
On 5/13/14, 8:39 PM, Pantelis Antoniou pantelis.anton...@gmail.com
wrote:
Hi John,
On May 13, 2014, at 1:24 PM, John Syn wrote:
On 5/13/14, 10:51 AM, Javier Martinez Canillas jav...@dowhile0.org
wrote:
Hello Pantelis,
On Tue, May 13, 2014 at 7:07 PM, Pantelis Antoniou
pantelis.anton...@gmail.com wrote:
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.por...@linaro.org
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 tr...@ti.com 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.
It seems that you misunderstood my comments. I do think that DT
overlays and the cape manager are a great solution for any hardware
that could be expanded on runtime and I really hope that they can
eventually land into mainline.
In fact if you look on my previous mail you will see that I said:
until device tree overlay and the cape manager find their way into
mainline...
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.
What I said that I'm against is modifying a FDT using U-Boot scripts
Re: [PATCH v2] ARM: dts: am335x-bone-common: Add i2c2 definition
On 5/13/14, 8:39 PM, "Pantelis Antoniou"
wrote:
>Hi John,
>
>On May 13, 2014, at 1:24 PM, John Syn wrote:
>
>>
>> On 5/13/14, 10:51 AM, "Javier Martinez Canillas"
>> wrote:
>>
>>> Hello Pantelis,
>>>
>>> On Tue, May 13, 2014 at 7:07 PM, Pantelis Antoniou
>>> wrote:
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
> 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 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.
>>>
>>> It seems that you misunderstood my comments. I do think that DT
>>> overlays and the cape manager are a great solution for any hardware
>>> that could be expanded on runtime and I really hope that they can
>>> eventually land into mainline.
>>>
>>> In fact if you look on my previous mail you will see that I said:
>>> "until device tree overlay and the cape manager find their way into
>>> mainline..."
>>>
> 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
Re: [PATCH v2] ARM: dts: am335x-bone-common: Add i2c2 definition
Hi John,
On May 13, 2014, at 1:24 PM, John Syn wrote:
>
> On 5/13/14, 10:51 AM, "Javier Martinez Canillas"
> wrote:
>
>> Hello Pantelis,
>>
>> On Tue, May 13, 2014 at 7:07 PM, Pantelis Antoniou
>> wrote:
>>> 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
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 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.
>>>
>>
>> It seems that you misunderstood my comments. I do think that DT
>> overlays and the cape manager are a great solution for any hardware
>> that could be expanded on runtime and I really hope that they can
>> eventually land into mainline.
>>
>> In fact if you look on my previous mail you will see that I said:
>> "until device tree overlay and the cape manager find their way into
>> mainline..."
>>
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
>>>
Re: [PATCH v2] ARM: dts: am335x-bone-common: Add i2c2 definition
Hi Javier,
On May 13, 2014, at 10:51 AM, Javier Martinez Canillas wrote:
> Hello Pantelis,
>
> On Tue, May 13, 2014 at 7:07 PM, Pantelis Antoniou
> wrote:
>> 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 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 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.
>>
>
> It seems that you misunderstood my comments. I do think that DT
> overlays and the cape manager are a great solution for any hardware
> that could be expanded on runtime and I really hope that they can
> eventually land into mainline.
>
> In fact if you look on my previous mail you will see that I said:
> "until device tree overlay and the cape manager find their way into
> mainline..."
>
>>> 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
Re: [PATCH v2] ARM: dts: am335x-bone-common: Add i2c2 definition
On 5/13/14, 10:51 AM, "Javier Martinez Canillas"
wrote:
>Hello Pantelis,
>
>On Tue, May 13, 2014 at 7:07 PM, Pantelis Antoniou
> wrote:
>> 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
>>>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 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.
>>
>
>It seems that you misunderstood my comments. I do think that DT
>overlays and the cape manager are a great solution for any hardware
>that could be expanded on runtime and I really hope that they can
>eventually land into mainline.
>
>In fact if you look on my previous mail you will see that I said:
>"until device tree overlay and the cape manager find their way into
>mainline..."
>
>>> 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
Re: [PATCH v2] ARM: dts: am335x-bone-common: Add i2c2 definition
Hello Pantelis,
On Tue, May 13, 2014 at 7:07 PM, Pantelis Antoniou
wrote:
> 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 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 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.
>
It seems that you misunderstood my comments. I do think that DT
overlays and the cape manager are a great solution for any hardware
that could be expanded on runtime and I really hope that they can
eventually land into mainline.
In fact if you look on my previous mail you will see that I said:
"until device tree overlay and the cape manager find their way into
mainline..."
>> 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.
>
What I said that I'm against is modifying a FDT using U-Boot scripts
commands that is something that mentioned in this
Re: [PATCH v2] ARM: dts: am335x-bone-common: Add i2c2 definition
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 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 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 majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2] ARM: dts: am335x-bone-common: Add i2c2 definition
On Tue, May 13, 2014 at 4:22 PM, Matt Porter 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 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.
>
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.
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.
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 :-)
> -Matt
Best regards,
Javier
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2] ARM: dts: am335x-bone-common: Add i2c2 definition
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 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.
-Matt
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2] ARM: dts: am335x-bone-common: Add i2c2 definition
On 05/13/2014 10:06 AM, Javier Martinez Canillas wrote:
> 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.
Sometimes nothing exposes just how big a problem something is (and how
much we need the solution to it) like actually showing the output.
Someone could also start posting the profileN device trees for the
am335x GP EVMs too.
--
Tom
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2] ARM: dts: am335x-bone-common: Add i2c2 definition
On Tue, May 13, 2014 at 2:53 PM, Tom Rini 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.
> --
> Tom
Best regards,
Javier
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2] ARM: dts: am335x-bone-common: Add i2c2 definition
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 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. -- Tom -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2] ARM: dts: am335x-bone-common: Add i2c2 definition
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 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. -- Tom -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2] ARM: dts: am335x-bone-common: Add i2c2 definition
On Tue, May 13, 2014 at 2:53 PM, Tom Rini tr...@ti.com 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.
--
Tom
Best regards,
Javier
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2] ARM: dts: am335x-bone-common: Add i2c2 definition
On 05/13/2014 10:06 AM, Javier Martinez Canillas wrote:
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.
Sometimes nothing exposes just how big a problem something is (and how
much we need the solution to it) like actually showing the output.
Someone could also start posting the profileN device trees for the
am335x GP EVMs too.
--
Tom
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2] ARM: dts: am335x-bone-common: Add i2c2 definition
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 tr...@ti.com 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.
-Matt
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2] ARM: dts: am335x-bone-common: Add i2c2 definition
On Tue, May 13, 2014 at 4:22 PM, Matt Porter matt.por...@linaro.org 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 tr...@ti.com 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.
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.
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.
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 :-)
-Matt
Best regards,
Javier
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2] ARM: dts: am335x-bone-common: Add i2c2 definition
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.por...@linaro.org 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 tr...@ti.com 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 majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2] ARM: dts: am335x-bone-common: Add i2c2 definition
Hello Pantelis,
On Tue, May 13, 2014 at 7:07 PM, Pantelis Antoniou
pantelis.anton...@gmail.com wrote:
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.por...@linaro.org 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 tr...@ti.com 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.
It seems that you misunderstood my comments. I do think that DT
overlays and the cape manager are a great solution for any hardware
that could be expanded on runtime and I really hope that they can
eventually land into mainline.
In fact if you look on my previous mail you will see that I said:
until device tree overlay and the cape manager find their way into
mainline...
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.
What I said that I'm against is modifying a FDT using U-Boot scripts
commands that is something that mentioned in this thread. That is not
a robust way to do it and also is not something that a newbie could do
it neither.
Also, doing these FDT changes in the bootloader has several
disadvantages, besides having to implement on each bootloaders like
Tom said, you need to upgrade your
Re: [PATCH v2] ARM: dts: am335x-bone-common: Add i2c2 definition
On 5/13/14, 10:51 AM, Javier Martinez Canillas jav...@dowhile0.org
wrote:
Hello Pantelis,
On Tue, May 13, 2014 at 7:07 PM, Pantelis Antoniou
pantelis.anton...@gmail.com wrote:
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.por...@linaro.org
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 tr...@ti.com 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.
It seems that you misunderstood my comments. I do think that DT
overlays and the cape manager are a great solution for any hardware
that could be expanded on runtime and I really hope that they can
eventually land into mainline.
In fact if you look on my previous mail you will see that I said:
until device tree overlay and the cape manager find their way into
mainline...
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.
What I said that I'm against is modifying a FDT using U-Boot scripts
commands that is something that mentioned in this thread. That is not
a robust way to do it and also is not something that a newbie could do
it neither.
Also, doing these FDT changes in the bootloader has several
disadvantages, besides having to
Re: [PATCH v2] ARM: dts: am335x-bone-common: Add i2c2 definition
Hi Javier,
On May 13, 2014, at 10:51 AM, Javier Martinez Canillas wrote:
Hello Pantelis,
On Tue, May 13, 2014 at 7:07 PM, Pantelis Antoniou
pantelis.anton...@gmail.com wrote:
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.por...@linaro.org 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 tr...@ti.com 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.
It seems that you misunderstood my comments. I do think that DT
overlays and the cape manager are a great solution for any hardware
that could be expanded on runtime and I really hope that they can
eventually land into mainline.
In fact if you look on my previous mail you will see that I said:
until device tree overlay and the cape manager find their way into
mainline...
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.
What I said that I'm against is modifying a FDT using U-Boot scripts
commands that is something that mentioned in this thread. That is not
a robust way to do it and also is not something that a newbie could do
it neither.
Also, doing these FDT changes
Re: [PATCH v2] ARM: dts: am335x-bone-common: Add i2c2 definition
Hi John,
On May 13, 2014, at 1:24 PM, John Syn wrote:
On 5/13/14, 10:51 AM, Javier Martinez Canillas jav...@dowhile0.org
wrote:
Hello Pantelis,
On Tue, May 13, 2014 at 7:07 PM, Pantelis Antoniou
pantelis.anton...@gmail.com wrote:
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.por...@linaro.org
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 tr...@ti.com 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.
It seems that you misunderstood my comments. I do think that DT
overlays and the cape manager are a great solution for any hardware
that could be expanded on runtime and I really hope that they can
eventually land into mainline.
In fact if you look on my previous mail you will see that I said:
until device tree overlay and the cape manager find their way into
mainline...
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.
What I said that I'm against is modifying a FDT using U-Boot scripts
commands that is something that mentioned in this thread. That is not
a robust way to do it and also is not
Re: [PATCH v2] ARM: dts: am335x-bone-common: Add i2c2 definition
On 5/13/14, 8:39 PM, Pantelis Antoniou pantelis.anton...@gmail.com
wrote:
Hi John,
On May 13, 2014, at 1:24 PM, John Syn wrote:
On 5/13/14, 10:51 AM, Javier Martinez Canillas jav...@dowhile0.org
wrote:
Hello Pantelis,
On Tue, May 13, 2014 at 7:07 PM, Pantelis Antoniou
pantelis.anton...@gmail.com wrote:
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.por...@linaro.org
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 tr...@ti.com 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.
It seems that you misunderstood my comments. I do think that DT
overlays and the cape manager are a great solution for any hardware
that could be expanded on runtime and I really hope that they can
eventually land into mainline.
In fact if you look on my previous mail you will see that I said:
until device tree overlay and the cape manager find their way into
mainline...
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.
What I said that I'm against is modifying a FDT using U-Boot scripts
commands that is something that mentioned
Re: [PATCH v2] ARM: dts: am335x-bone-common: Add i2c2 definition
* Robert Nelson [140512 13:58]: > >> 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 Right, no idea. But until we have some way to actually use the capes without conflicting dts entries, I can't merge them. Regards, Tony -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2] ARM: dts: am335x-bone-common: Add i2c2 definition
>> 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 Regards, -- Robert Nelson http://www.rcn-ee.com/ -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2] ARM: dts: am335x-bone-common: Add i2c2 definition
* Robert Nelson [140512 13:27]: > >> > > >> > If these pins are not used for i2c2 on some capes, this device > >> > should be set to status = "disabled" state by default. Then > >> > u-boot could re-enable it on the boards that have i2c2 in use. > >> > >> To-date, this is the i2c bus that all capes have placed an at24 eeprom > >> for cape identification. > > > > And how many capes actually implement the eeprom cape identification > > out of the available capes? :) > > Not including one off designs in someone's lab. We will never have an > accurate number. ;) > > So far; just the ones that want their "cape" detected in the default > image currently being shipped by CircuitCo. Otherwise the few that > I've seen without an eeprom, usually follow this default pinmux. > > http://elinux.org/CircuitCo:Basic_Proto_Cape > > Which includes that i2c bus enabled. OK thanks for the info. > 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? Regards, Tony -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2] ARM: dts: am335x-bone-common: Add i2c2 definition
>> > >> > If these pins are not used for i2c2 on some capes, this device >> > should be set to status = "disabled" state by default. Then >> > u-boot could re-enable it on the boards that have i2c2 in use. >> >> To-date, this is the i2c bus that all capes have placed an at24 eeprom >> for cape identification. > > And how many capes actually implement the eeprom cape identification > out of the available capes? :) Not including one off designs in someone's lab. We will never have an accurate number. ;) So far; just the ones that want their "cape" detected in the default image currently being shipped by CircuitCo. Otherwise the few that I've seen without an eeprom, usually follow this default pinmux. http://elinux.org/CircuitCo:Basic_Proto_Cape Which includes that i2c bus enabled. 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. Regards, -- Robert Nelson http://www.rcn-ee.com/ -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2] ARM: dts: am335x-bone-common: Add i2c2 definition
* Robert Nelson [140512 13:00]:
> >>
> >> + i2c2_pins: pinmux_i2c2_pins {
> >> + pinctrl-single,pins = <
> >> + 0x178 (PIN_INPUT_PULLUP | MUX_MODE3)/*
> >> uart1_ctsn.i2c2_sda */
> >> + 0x17c (PIN_INPUT_PULLUP | MUX_MODE3)/*
> >> uart1_rtsn.i2c2_scl */
> >> + >;
> >> + };
> >> +
> >> uart0_pins: pinmux_uart0_pins {
> >> pinctrl-single,pins = <
> >> 0x170 (PIN_INPUT_PULLUP | MUX_MODE0)/*
> >> uart0_rxd.uart0_rxd */
> >>
> >> @@ -222,6 +229,15 @@
> >>
> >> };
> >>
> >> +
> >> + {
> >> + pinctrl-names = "default";
> >> + pinctrl-0 = <_pins>;
> >> +
> >> + status = "okay";
> >> + clock-frequency = <10>;
> >> +};
> >> +
> >
> > If these pins are not used for i2c2 on some capes, this device
> > should be set to status = "disabled" state by default. Then
> > u-boot could re-enable it on the boards that have i2c2 in use.
>
> To-date, this is the i2c bus that all capes have placed an at24 eeprom
> for cape identification.
And how many capes actually implement the eeprom cape identification
out of the available capes? :)
Tony
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2] ARM: dts: am335x-bone-common: Add i2c2 definition
>>
>> + i2c2_pins: pinmux_i2c2_pins {
>> + pinctrl-single,pins = <
>> + 0x178 (PIN_INPUT_PULLUP | MUX_MODE3)/*
>> uart1_ctsn.i2c2_sda */
>> + 0x17c (PIN_INPUT_PULLUP | MUX_MODE3)/*
>> uart1_rtsn.i2c2_scl */
>> + >;
>> + };
>> +
>> uart0_pins: pinmux_uart0_pins {
>> pinctrl-single,pins = <
>> 0x170 (PIN_INPUT_PULLUP | MUX_MODE0)/*
>> uart0_rxd.uart0_rxd */
>>
>> @@ -222,6 +229,15 @@
>>
>> };
>>
>> +
>> + {
>> + pinctrl-names = "default";
>> + pinctrl-0 = <_pins>;
>> +
>> + status = "okay";
>> + clock-frequency = <10>;
>> +};
>> +
>
> If these pins are not used for i2c2 on some capes, this device
> should be set to status = "disabled" state by default. Then
> u-boot could re-enable it on the boards that have i2c2 in use.
To-date, this is the i2c bus that all capes have placed an at24 eeprom
for cape identification.
Regards,
--
Robert Nelson
http://www.rcn-ee.com/
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2] ARM: dts: am335x-bone-common: Add i2c2 definition
* Matt Ranostay [140509 18:43]:
> Add missing i2c2 bus define to access various cape and
> prototype/breakout board devices.
>
> Signed-off-by: Matt Ranostay
> ---
> arch/arm/boot/dts/am335x-bone-common.dtsi | 16
> 1 file changed, 16 insertions(+)
>
> diff --git a/arch/arm/boot/dts/am335x-bone-common.dtsi
> b/arch/arm/boot/dts/am335x-bone-common.dtsi
> index 2e7d932..5fdae2e 100644
> --- a/arch/arm/boot/dts/am335x-bone-common.dtsi
> +++ b/arch/arm/boot/dts/am335x-bone-common.dtsi
> @@ -84,6 +84,13 @@
> >;
> };
>
> + i2c2_pins: pinmux_i2c2_pins {
> + pinctrl-single,pins = <
> + 0x178 (PIN_INPUT_PULLUP | MUX_MODE3)/*
> uart1_ctsn.i2c2_sda */
> + 0x17c (PIN_INPUT_PULLUP | MUX_MODE3)/*
> uart1_rtsn.i2c2_scl */
> + >;
> + };
> +
> uart0_pins: pinmux_uart0_pins {
> pinctrl-single,pins = <
> 0x170 (PIN_INPUT_PULLUP | MUX_MODE0)/*
> uart0_rxd.uart0_rxd */
>
> @@ -222,6 +229,15 @@
>
> };
>
> +
> + {
> + pinctrl-names = "default";
> + pinctrl-0 = <_pins>;
> +
> + status = "okay";
> + clock-frequency = <10>;
> +};
> +
If these pins are not used for i2c2 on some capes, this device
should be set to status = "disabled" state by default. Then
u-boot could re-enable it on the boards that have i2c2 in use.
Regards,
Tony
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2] ARM: dts: am335x-bone-common: Add i2c2 definition
* Matt Ranostay mranos...@gmail.com [140509 18:43]:
Add missing i2c2 bus define to access various cape and
prototype/breakout board devices.
Signed-off-by: Matt Ranostay mranos...@gmail.com
---
arch/arm/boot/dts/am335x-bone-common.dtsi | 16
1 file changed, 16 insertions(+)
diff --git a/arch/arm/boot/dts/am335x-bone-common.dtsi
b/arch/arm/boot/dts/am335x-bone-common.dtsi
index 2e7d932..5fdae2e 100644
--- a/arch/arm/boot/dts/am335x-bone-common.dtsi
+++ b/arch/arm/boot/dts/am335x-bone-common.dtsi
@@ -84,6 +84,13 @@
;
};
+ i2c2_pins: pinmux_i2c2_pins {
+ pinctrl-single,pins =
+ 0x178 (PIN_INPUT_PULLUP | MUX_MODE3)/*
uart1_ctsn.i2c2_sda */
+ 0x17c (PIN_INPUT_PULLUP | MUX_MODE3)/*
uart1_rtsn.i2c2_scl */
+ ;
+ };
+
uart0_pins: pinmux_uart0_pins {
pinctrl-single,pins =
0x170 (PIN_INPUT_PULLUP | MUX_MODE0)/*
uart0_rxd.uart0_rxd */
@@ -222,6 +229,15 @@
};
+
+i2c2 {
+ pinctrl-names = default;
+ pinctrl-0 = i2c2_pins;
+
+ status = okay;
+ clock-frequency = 10;
+};
+
If these pins are not used for i2c2 on some capes, this device
should be set to status = disabled state by default. Then
u-boot could re-enable it on the boards that have i2c2 in use.
Regards,
Tony
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2] ARM: dts: am335x-bone-common: Add i2c2 definition
+ i2c2_pins: pinmux_i2c2_pins {
+ pinctrl-single,pins =
+ 0x178 (PIN_INPUT_PULLUP | MUX_MODE3)/*
uart1_ctsn.i2c2_sda */
+ 0x17c (PIN_INPUT_PULLUP | MUX_MODE3)/*
uart1_rtsn.i2c2_scl */
+ ;
+ };
+
uart0_pins: pinmux_uart0_pins {
pinctrl-single,pins =
0x170 (PIN_INPUT_PULLUP | MUX_MODE0)/*
uart0_rxd.uart0_rxd */
@@ -222,6 +229,15 @@
};
+
+i2c2 {
+ pinctrl-names = default;
+ pinctrl-0 = i2c2_pins;
+
+ status = okay;
+ clock-frequency = 10;
+};
+
If these pins are not used for i2c2 on some capes, this device
should be set to status = disabled state by default. Then
u-boot could re-enable it on the boards that have i2c2 in use.
To-date, this is the i2c bus that all capes have placed an at24 eeprom
for cape identification.
Regards,
--
Robert Nelson
http://www.rcn-ee.com/
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2] ARM: dts: am335x-bone-common: Add i2c2 definition
* Robert Nelson robertcnel...@gmail.com [140512 13:00]:
+ i2c2_pins: pinmux_i2c2_pins {
+ pinctrl-single,pins =
+ 0x178 (PIN_INPUT_PULLUP | MUX_MODE3)/*
uart1_ctsn.i2c2_sda */
+ 0x17c (PIN_INPUT_PULLUP | MUX_MODE3)/*
uart1_rtsn.i2c2_scl */
+ ;
+ };
+
uart0_pins: pinmux_uart0_pins {
pinctrl-single,pins =
0x170 (PIN_INPUT_PULLUP | MUX_MODE0)/*
uart0_rxd.uart0_rxd */
@@ -222,6 +229,15 @@
};
+
+i2c2 {
+ pinctrl-names = default;
+ pinctrl-0 = i2c2_pins;
+
+ status = okay;
+ clock-frequency = 10;
+};
+
If these pins are not used for i2c2 on some capes, this device
should be set to status = disabled state by default. Then
u-boot could re-enable it on the boards that have i2c2 in use.
To-date, this is the i2c bus that all capes have placed an at24 eeprom
for cape identification.
And how many capes actually implement the eeprom cape identification
out of the available capes? :)
Tony
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2] ARM: dts: am335x-bone-common: Add i2c2 definition
If these pins are not used for i2c2 on some capes, this device should be set to status = disabled state by default. Then u-boot could re-enable it on the boards that have i2c2 in use. To-date, this is the i2c bus that all capes have placed an at24 eeprom for cape identification. And how many capes actually implement the eeprom cape identification out of the available capes? :) Not including one off designs in someone's lab. We will never have an accurate number. ;) So far; just the ones that want their cape detected in the default image currently being shipped by CircuitCo. Otherwise the few that I've seen without an eeprom, usually follow this default pinmux. http://elinux.org/CircuitCo:Basic_Proto_Cape Which includes that i2c bus enabled. 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. Regards, -- Robert Nelson http://www.rcn-ee.com/ -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2] ARM: dts: am335x-bone-common: Add i2c2 definition
* Robert Nelson robertcnel...@gmail.com [140512 13:27]: If these pins are not used for i2c2 on some capes, this device should be set to status = disabled state by default. Then u-boot could re-enable it on the boards that have i2c2 in use. To-date, this is the i2c bus that all capes have placed an at24 eeprom for cape identification. And how many capes actually implement the eeprom cape identification out of the available capes? :) Not including one off designs in someone's lab. We will never have an accurate number. ;) So far; just the ones that want their cape detected in the default image currently being shipped by CircuitCo. Otherwise the few that I've seen without an eeprom, usually follow this default pinmux. http://elinux.org/CircuitCo:Basic_Proto_Cape Which includes that i2c bus enabled. OK thanks for the info. 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? Regards, Tony -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2] ARM: dts: am335x-bone-common: Add i2c2 definition
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 Regards, -- Robert Nelson http://www.rcn-ee.com/ -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2] ARM: dts: am335x-bone-common: Add i2c2 definition
* Robert Nelson robertcnel...@gmail.com [140512 13:58]: 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 Right, no idea. But until we have some way to actually use the capes without conflicting dts entries, I can't merge them. Regards, Tony -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2] ARM: dts: am335x-bone-common: Add i2c2 definition
Add missing i2c2 bus define to access various cape and
prototype/breakout board devices.
Signed-off-by: Matt Ranostay
---
arch/arm/boot/dts/am335x-bone-common.dtsi | 16
1 file changed, 16 insertions(+)
diff --git a/arch/arm/boot/dts/am335x-bone-common.dtsi
b/arch/arm/boot/dts/am335x-bone-common.dtsi
index 2e7d932..5fdae2e 100644
--- a/arch/arm/boot/dts/am335x-bone-common.dtsi
+++ b/arch/arm/boot/dts/am335x-bone-common.dtsi
@@ -84,6 +84,13 @@
>;
};
+ i2c2_pins: pinmux_i2c2_pins {
+ pinctrl-single,pins = <
+ 0x178 (PIN_INPUT_PULLUP | MUX_MODE3)/*
uart1_ctsn.i2c2_sda */
+ 0x17c (PIN_INPUT_PULLUP | MUX_MODE3)/*
uart1_rtsn.i2c2_scl */
+ >;
+ };
+
uart0_pins: pinmux_uart0_pins {
pinctrl-single,pins = <
0x170 (PIN_INPUT_PULLUP | MUX_MODE0)/*
uart0_rxd.uart0_rxd */
@@ -222,6 +229,15 @@
};
+
+ {
+ pinctrl-names = "default";
+ pinctrl-0 = <_pins>;
+
+ status = "okay";
+ clock-frequency = <10>;
+};
+
/include/ "tps65217.dtsi"
{
--
1.8.3.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2] ARM: dts: am335x-bone-common: Add i2c2 definition
Add missing i2c2 bus define to access various cape and
prototype/breakout board devices.
Signed-off-by: Matt Ranostay mranos...@gmail.com
---
arch/arm/boot/dts/am335x-bone-common.dtsi | 16
1 file changed, 16 insertions(+)
diff --git a/arch/arm/boot/dts/am335x-bone-common.dtsi
b/arch/arm/boot/dts/am335x-bone-common.dtsi
index 2e7d932..5fdae2e 100644
--- a/arch/arm/boot/dts/am335x-bone-common.dtsi
+++ b/arch/arm/boot/dts/am335x-bone-common.dtsi
@@ -84,6 +84,13 @@
;
};
+ i2c2_pins: pinmux_i2c2_pins {
+ pinctrl-single,pins =
+ 0x178 (PIN_INPUT_PULLUP | MUX_MODE3)/*
uart1_ctsn.i2c2_sda */
+ 0x17c (PIN_INPUT_PULLUP | MUX_MODE3)/*
uart1_rtsn.i2c2_scl */
+ ;
+ };
+
uart0_pins: pinmux_uart0_pins {
pinctrl-single,pins =
0x170 (PIN_INPUT_PULLUP | MUX_MODE0)/*
uart0_rxd.uart0_rxd */
@@ -222,6 +229,15 @@
};
+
+i2c2 {
+ pinctrl-names = default;
+ pinctrl-0 = i2c2_pins;
+
+ status = okay;
+ clock-frequency = 10;
+};
+
/include/ tps65217.dtsi
tps {
--
1.8.3.2
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
