Re: [PATCH] ARM: dts: am335x-bone* enable pmic-shutdown-controller
Hi Tony, On May 18, 2015, at 20:03 , Tony Lindgren t...@atomide.com wrote: * Robert Nelson robertcnel...@gmail.com [150518 09:51]: On Mon, May 18, 2015 at 11:29 AM, Tony Lindgren t...@atomide.com wrote: * Robert Nelson robertcnel...@gmail.com [150518 09:15]: On Mon, May 18, 2015 at 10:21 AM, Tony Lindgren t...@atomide.com wrote: All the rev information is in the board's eeprom: hexdump -e '8/1 %c' /sys/bus/i2c/devices/0-0050/eeprom -s 12 -n 4 Rev A5B 0A5B Rev C 000C Just another default qwerk to add to Pantelis' bone_capemgr. ;) It seems we should not even instantiate some devices on BBB until the EEPROM is parsed.. So maybe something like this: 1. The problem devices are initially set with status = disabled in the dts 2. We set up drivers/*/bbb-eeprom.c that parses the board revision at module_init time, and then flips the selected devices to have status = enabled and populates the revision info based on the eeprom and SoC revision passed in pdata. Then those devices get their struct device created and probed, but at a much later time. So rather than trying to init all that early, let's just init them much later when we have the proper I2C driver running? I see that working just fine. We (beagleboard.org) enforce the eeprom data, as all the official images require a proper baseboard eeprom. OK We just have to be very careful to limit the scope, otherwise we will end up with Pantelis' rejected capebus from the v3.2.x days... Naturally I was thinking #2 above would use Pantelis' code for CONFIG_OF_OVERLAY in mainline. But instead of the earlier patches, we can make things happen much later on to avoid the detect of EEPROM early on. Already been taken care of: https://lkml.org/lkml/2015/2/18/258 The patchset works, but it still needs some review eyeballs. There might be a rename to variants or something. You were part of that thread too :) I think it’s best if we go this path instead of twiddling with the status properties manually. Conceptually the idea is similar to the detection of the white/black, with the added joy of revision detection. Ain’t hardware designers a fun bunch or what? Regards, Tony Regards — Pantelis -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Unifying cape overlays into boot .dtb for BeagleBoard.org boards
Hi Russell, CCing gcl. On Jun 17, 2014, at 4:15 PM, Russell King - ARM Linux wrote: On Tue, Jun 17, 2014 at 08:58:31AM -0400, Matt Porter wrote: On Tue, Jun 17, 2014 at 10:09:31AM +0100, Russell King wrote: Why should kernel developers go to the extent of adding support for DT modification at runtime when the platform you want this for doesn't even support hotplugging of these capes? It's important to note that Jason's use case is not the real one driving runtime DT modification. You'll have to go back to threads like https://lkml.org/lkml/2013/2/22/255 over a year ago where this was all hashed out. The clearest use cases are the FPGA folks that are loading their bitstream from userspace and due to DT-everywhere also need to initiate runtime modification of the live DT tree from userspace. There's a lot of discussion over many threads where this has been debated. Okay, so it was debated, and the outcome of that debate has been... no change. That's probably because it is an incredible amount of work to achieve it, and none of the overloaded DT maintainers (who don't have enough time to review new bindings) have any intention of putting their precious resources towards it. Wait, wait wait. Who said there's no progress there. We're already proceeding in that direction. Apparently you are not aware that runtime modification of DT is part of the DT capabilities since a few years back, as normally used on pSeries class of machines. The overlays are a method of having a sane, easy to use method for reconfigurable hardware. From my rudimentary understanding of the OF code, it seems to mean that the way devices are created from the parsed OF tree structures (the device_node structures) needs to change such that when an OF tree node is removed, its corresponding device is also removed. This probably needs a struct device pointer in the device_node struct. Then there needs to be support to modify the parsed OF tree (not only to add nodes but also to remove nodes) and do the right thing when a node is added and/or removed. Already done. However, there's harder cases to solve. There's several instances where device nodes do not correspond with a struct device, and these nodes are parsed by the driver. Such things as the of_graph stuff, which describes the inter-connectivity of a display subsystem or v4l2 subsystem. The nodes may be specified, but the target device for one of the links may be disabled at original probe time, but later becomes enabled via modification - this is one of the difficult cases since it needs the driver to cooperate with the change, and there's no existing way to notify it of that change. Actually there is, and we're working on making a generic method of handling all these cases. Hint, take a look at of_reconfig_notifier_register please. As with any kernel change, it needs people to write code. If no one writes code, no change happens. Endlessly discussing it on mailing lists does not result in code being written. The code is already written. If you have any specific objections to the patchset I've already posted, comments are welcome. However, going back to the original stated platform - none of this complexity is required there. Once power is applied, the platform hardware configuration is fixed (unless you want to yank a board off and risk destroying the hardware in doing so.) So, if Jason's interest is in the capes, then the simplest and easiest approach is to have the boot loader deal with it. If it's about FPGAs and dynamically loading bitstreams into them, then maybe a dynamic device tree is the answer - but /someone/ then has to create patches to achieve that. If no one is willing to create those patches, then forget the idea of a dynamic device tree, because it won't happen on its own. The complexity is absolutely required, and it has nothing to do with beaglebone capes. The fact of the matter is that reconfigurable hardware is here, on shipping system, and we, as the linux kernel community have to make sure it works, and that it works in a sane way. -- FTTC broadband for 0.8mile line: now at 9.7Mbps down 460kbps up... slowly improving, and getting towards what was expected from it. Regards -- Pantelis -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Unifying cape overlays into boot .dtb for BeagleBoard.org boards
Hi Russell, On Jun 17, 2014, at 7:01 PM, Russell King - ARM Linux wrote: On Tue, Jun 17, 2014 at 04:32:11PM +0300, Pantelis Antoniou wrote: The complexity is absolutely required, and it has nothing to do with beaglebone capes. The fact of the matter is that reconfigurable hardware is here, on shipping system, and we, as the linux kernel community have to make sure it works, and that it works in a sane way. Right, so looking back in the git history, this project has been going on for... at least four years? Probably longer than the length of time that we've been converting ARM to DT. At no point during that has anyone brought up the issue of DT being dynamic, so none of the drivers which we have been converting caters for this. The timeline does not go that far back. The first (non-DT overlay based) capebus patchset was posted on October 2012 and after feedback (i.e. it was deemed to suck) it was pointed that a DT based generic method should be used; hence DT overlays. The dynamic DT part has always been part of PPC DT support for pSeries. Isn't this a bit of a missed opportunity, if this is a direction that OF wishes to head towards? I am going to let Grant answer that, but personally I believe a lot of the troubles we've been having with DT and dynamic device graph changes can be handled elegantly using something DT overlays (and the follow up work which is transaction DT support). Wouldn't it have been relevant to the discussion at kernel summit too, concerning DRM/v4l2/componentised systems? What if someone comes along tomorrow with part of their multimedia based system inside a FPGA which they program up at runtime? That case might already work on FPGA people's trees. I know Altera for sure uses overlays, and some xilinx guys popped up on past discussions. Their vendor trees probably use an older revision of the patches. BTW, there is nothing special about DRM/v4l2 that can't be handled by a generic DT mechanism. What makes this such a big problem? Regards -- Pantelis -- FTTC broadband for 0.8mile line: now at 9.7Mbps down 460kbps up... slowly improving, and getting towards what was expected from it. -- To unsubscribe from this list: send the line unsubscribe devicetree in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Unifying cape overlays into boot .dtb for BeagleBoard.org boards
Hi Russell, On Jun 17, 2014, at 8:05 PM, Russell King - ARM Linux wrote: On Tue, Jun 17, 2014 at 07:59:21PM +0300, Pantelis Antoniou wrote: That case might already work on FPGA people's trees. I know Altera for sure uses overlays, and some xilinx guys popped up on past discussions. Their vendor trees probably use an older revision of the patches. BTW, there is nothing special about DRM/v4l2 that can't be handled by a generic DT mechanism. What makes this such a big problem? Really? DRM is not hotpluggable in any shape or form, and David Airlie has indicated that he does strongly opposes moving it in that direction. DRM follows the card model, where, at probe time, the hardware is known and never changes until the card is torn down. No new connectors can be added once the card is initialised, and no connectors can be removed. Any changes must be done by tearing down the entire card and reconstructing it (if reconstructing it with a reduced set of hardware is appropriate.) That is a limitation of the current DRM implementation. I seems to be this is born out of some kind of misunderstanding about how DT can (and does) support dynamic changes. I admit that I haven't done much work on DRM (besides some tinkering with Rob Clark's ti_lcdc DRM driver), but knowing what DT does have a dynamic change notifier support, perhaps it can be made to work. As I said, the next thing coming is transactional DT support, perhaps you can share the DT fragment describing your use-case (before/after) and I'll try to accommodate in the next patch series. Regards -- Pantelis -- FTTC broadband for 0.8mile line: now at 9.7Mbps down 460kbps up... slowly improving, and getting towards what was expected from it. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Unifying cape overlays into boot .dtb for BeagleBoard.org boards
Hi Rusell,
On Jun 17, 2014, at 8:41 PM, Russell King - ARM Linux wrote:
On Tue, Jun 17, 2014 at 08:10:46PM +0300, Pantelis Antoniou wrote:
Hi Russell,
On Jun 17, 2014, at 8:05 PM, Russell King - ARM Linux wrote:
DRM is not hotpluggable in any shape or form, and David Airlie has
indicated that he does strongly opposes moving it in that direction.
DRM follows the card model, where, at probe time, the hardware is
known and never changes until the card is torn down. No new
connectors can be added once the card is initialised, and no
connectors can be removed. Any changes must be done by tearing down
the entire card and reconstructing it (if reconstructing it with a
reduced set of hardware is appropriate.)
That is a limitation of the current DRM implementation.
... an implementation which isn't going to change any time soon... and
certainly is not going to change because someone comes along with a
dynamic DT infrastructure.
We can't enforce anyone to use the facilities we provide. We can but point
the benefits of such.
I seems to be this is born out of some kind of misunderstanding about how
DT can (and does) support dynamic changes.
I admit that I haven't done much work on DRM (besides some tinkering with
Rob Clark's ti_lcdc DRM driver), but knowing what DT does have a dynamic
change notifier support, perhaps it can be made to work.
It can be made to work in the way that I described above - any change
to the hardware which makes up a DRM card would need the entire DRM
card torn down and re-created... as I said above.
The reason I know this is because I've been involved closely in dealing
with imx-drm, and Armada DRM, and the mess that people spew trying to
get their DT representations of their hardware (as multiple, separate
devices which can be probed asynchronously) to work with DT.
If DRM supported hot-plugging of components, dealing with that would
be much easier than it is, but - as I said above - this is not going
to happen. So, if it's not going to happen for the case which we
commonly find on ARM hardware today, it's certainly not going to
happen because DT wants to become dynamic.
This sounds more like a limitation of DRM than anything that has to do
with DT.
As I said, the next thing coming is transactional DT support, perhaps you
can share the DT fragment describing your use-case (before/after) and
I'll try to accommodate in the next patch series.
I don't have any - I'm using it as an example where a device (such as
the iMX6 SoC) which has quite a complex media infrastructure may be
extended externally via an FPGA to provide additional interfaces which
may then require dynamic changes to the DT description, thereby meaning
that we have to reconstruct the DRM card in its entirety.
If you want some DT to look at...
ldb: ldb@020e0008 {
#address-cells = 1;
#size-cells = 0;
compatible = fsl,imx6q-ldb, fsl,imx53-ldb;
gpr = gpr;
status = disabled;
lvds-channel@0 {
#address-cells = 1;
#size-cells = 0;
reg = 0;
status = disabled;
port@0 {
reg = 0;
lvds0_mux_0: endpoint {
remote-endpoint =
ipu1_di0_lvds0;
};
};
port@1 {
reg = 1;
lvds0_mux_1: endpoint {
remote-endpoint =
ipu1_di1_lvds0;
};
};
};
lvds-channel@1 {
#address-cells = 1;
#size-cells = 0;
reg = 1;
status = disabled;
port@0 {
reg = 0;
lvds1_mux_0: endpoint {
remote-endpoint =
ipu1_di0_lvds1;
};
};
port@1 {
reg = 1
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-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
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
Re: pandaboard boot crash with linux-next
Hi Tomi, On Mar 19, 2014, at 4:33 PM, Tomi Valkeinen wrote: On 19/03/14 16:29, Pantelis Antoniou wrote: Hi Tomi, On Mar 19, 2014, at 4:25 PM, Tomi Valkeinen wrote: On 17/03/14 16:09, Tomi Valkeinen wrote: Hi, I noticed that my omap4 panda does not boot with today's linux-next (8808b950581f71e3ee4cf8e6cae479f4c7106405). I didn't have much time to study it, but I didn't find any posts about the issue with a quick look. Below is the crash. I bisected this to the commit: commit ad2c12e9bc250b3387bcb4ab9ab114f43ff6122f Author: Pantelis Antoniou pa...@antoniou-consulting.com Date: Fri Dec 13 20:08:59 2013 +0200 of: device_node kobject lifecycle fixes After the move to having device nodes be proper kobjects the lifecycle of the node needs to be controlled better. At first convert of_add_node() in the unflattened functions to of_init_node() which initializes the kobject so that of_node_get/put work correctly even before of_init is called. Afterwards introduce of_node_is_initialized of_node_is_attached that query the underlying kobject about the state (attached means kobj is visible in sysfs) Using that make sure the lifecycle of the tree is correct at all times. Signed-off-by: Pantelis Antoniou pa...@antoniou-consulting.com [grant.likely: moved of_node_init() calls, fixed up locking, and dropped __of_populate() hunks] Signed-off-by: Grant Likely grant.lik...@linaro.org Can you try this? It should fix it (plus it should be in -next soon) Thanks, that fixes the issue (tested on omap4 panda). Tomi Yeah I know; my beaglebone hangs as well without it :) Regards -- Pantelis -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: pandaboard boot crash with linux-next
Hi Tomi, On Mar 19, 2014, at 4:25 PM, Tomi Valkeinen wrote: On 17/03/14 16:09, Tomi Valkeinen wrote: Hi, I noticed that my omap4 panda does not boot with today's linux-next (8808b950581f71e3ee4cf8e6cae479f4c7106405). I didn't have much time to study it, but I didn't find any posts about the issue with a quick look. Below is the crash. I bisected this to the commit: commit ad2c12e9bc250b3387bcb4ab9ab114f43ff6122f Author: Pantelis Antoniou pa...@antoniou-consulting.com Date: Fri Dec 13 20:08:59 2013 +0200 of: device_node kobject lifecycle fixes After the move to having device nodes be proper kobjects the lifecycle of the node needs to be controlled better. At first convert of_add_node() in the unflattened functions to of_init_node() which initializes the kobject so that of_node_get/put work correctly even before of_init is called. Afterwards introduce of_node_is_initialized of_node_is_attached that query the underlying kobject about the state (attached means kobj is visible in sysfs) Using that make sure the lifecycle of the tree is correct at all times. Signed-off-by: Pantelis Antoniou pa...@antoniou-consulting.com [grant.likely: moved of_node_init() calls, fixed up locking, and dropped __of_populate() hunks] Signed-off-by: Grant Likely grant.lik...@linaro.org Can you try this? It should fix it (plus it should be in -next soon) Regards -- Pantelis --8-8 commit be9577a6f756beaa87fd2073e3c74a8a608c37dc Author: Pantelis Antoniou pantelis.anton...@konsulko.com Date: Tue Mar 18 16:26:47 2014 +0200 of: of_add_property remove if semicolon. This semicolon shouldn't be there obviously, so remove it. Signed-off-by: Pantelis Antoniou pantelis.anton...@konsulko.com diff --git a/drivers/of/base.c b/drivers/of/base.c index 08156e6..887f4b0 100644 --- a/drivers/of/base.c +++ b/drivers/of/base.c @@ -1821,7 +1821,7 @@ int of_add_property(struct device_node *np, struct property *prop) if (rc) return rc; - if (of_node_is_attached(np)); + if (of_node_is_attached(np)) __of_add_property_sysfs(np, prop); return rc; --8-8 Tomi [0.00] ti_dt_clocks_register: failed to lookup clock node div_ts_ck [0.00] ti_dt_clocks_register: failed to lookup clock node bandgap_ts_fclk [0.00] Unable to handle kernel NULL pointer dereference at virtual address 004c [0.00] pgd = c0004000 [0.00] [004c] *pgd= [0.00] Internal error: Oops: 5 [#1] SMP ARM [0.00] Modules linked in: [0.00] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 3.14.0-rc6-next-20140317-09382-g8808b950581f #104 [0.00] task: c088ddf8 ti: c0882000 task.ti: c0882000 [0.00] PC is at kernfs_find_ns+0x14/0x13c [0.00] LR is at kernfs_find_and_get_ns+0x38/0x54 [0.00] pc : [c019607c]lr : [c019628c]psr: 61d3 [0.00] sp : c0883e00 ip : c0883e30 fp : c0883e2c [0.00] r10: c0891114 r9 : ebfa11c0 r8 : ebfcd464 [0.00] r7 : r6 : r5 : c07c1814 r4 : c08e9ad8 [0.00] r3 : c08f568c r2 : r1 : c07c1814 r0 : [0.00] Flags: nZCv IRQs off FIQs off Mode SVC_32 ISA ARM Segment kernel [0.00] Control: 10c5387d Table: 8000404a DAC: 0015 [0.00] Process swapper/0 (pid: 0, stack limit = 0xc0882248) [0.00] Stack: (0xc0883e00 to 0xc0884000) [0.00] 3e00: c08e9ad8 c07c1814 c08e9ad8 c07c1814 ebfcd464 [0.00] 3e20: c0883e4c c0883e30 c019628c c0196074 c07c1814 c07c1814 ebfcd490 [0.00] 3e40: c0883e6c c0883e50 c04c6180 c0196260 c0891140 c07c1814 ebfcd490 0001 [0.00] 3e60: c0883e9c c0883e70 c04c7308 c04c6160 c008a208 c008a130 c0883e9c [0.00] 3e80: c07c1814 c0891140 ebfcd464 a1d3 c0883ec4 c0883ea0 c04c7c9c c04c72cc [0.00] 3ea0: c0882000 ebfcd464 c074dcc8 c086bf64 0001 c074de24 c0883ee4 c0883ec8 [0.00] 3ec0: c0824b70 c04c7c14 c0891114 c0938af8 c074dcc8 c0883f54 c0883ee8 [0.00] 3ee0: c0824c58 c0824b18 c0e8bf6c c0882000 c0883f14 c0883f08 [0.00] 3f00: c05bc6b4 c05bc44c c0883f34 c0883f18 c04cca04 c05bc6b0 [0.00] 3f20: eb016b80 c0882000 c0883f4c c0883f38 c0938af8 c08910c0 c074dcc8 c074de24 [0.00] 3f40: c086ad60 c088a880 c0883f7c c0883f58 c0824f5c c0824c20 0001 c0883f68 [0.00] 3f60: 0001 c09380c0 c0882000 c0883f8c c0883f80 c0825250 c0824f1c [0.00] 3f80: c0883f9c c0883f90 c0825400 c0825238 c0883fac c0883fa0 c081d67c c08253fc [0.00] 3fa0: c0883ff4 c0883fb0 c0819a30 c081d664
Re: [PATCH] staging: Platform device tester - Allow removal
Hi Greg, On Aug 13, 2013, at 9:20 PM, Greg Kroah-Hartman wrote: On Tue, Aug 13, 2013 at 12:34:30PM +0300, Pantelis Antoniou wrote: This is a very simple device that allows testing of the removal path for platform devices. The only interface is a single writeable sysfs attribute (action). Why not use the existing unbind/bind sysfs files that all busses support? That's what userspace is expecting to use for adding and removing devices from drivers from userspace. This is a per-driver flag that the function platform_driver_probe() sets for all platform drivers in the first line of that function. Remove that line and see what happens :) I suppose you're talking about the sysfs bind/unbind attributes. Unfortunately it doesn't work for what I want to do; it doesn't use the same path that the of platform devices use for creating and unregistering. My intention is to use exactly the same path the kernel uses (and what the capemanager does). To wit: Using the bind/unbind method (removal seems to work) root@beaglebone:/sys/bus/platform/drivers/omap_i2c# echo 4819c000.i2c unbind [ 139.261522] omap_hwmod: i2c3: enabling [ 139.265514] omap_hwmod: i2c3: enabling clocks [ 139.270090] omap_hwmod: i2c3: clk_enable(dpll_per_m2_div4_ck) [ 139.276130] omap_hwmod: i2c3: _am33xx_enable_module: 2 [ 139.286477] omap_hwmod: i2c3: idling [ 139.290279] omap_hwmod: i2c3: _am33xx_disable_module [ 139.295501] omap_hwmod: i2c3: disabling clocks [ 139.305721] omap_hwmod: i2c3: enabling [ 139.309702] omap_hwmod: i2c3: enabling clocks [ 139.314279] omap_hwmod: i2c3: clk_enable(dpll_per_m2_div4_ck) [ 139.320332] omap_hwmod: i2c3: _am33xx_enable_module: 2 [ 139.341437] omap_hwmod: i2c3: disabling [ 139.345515] omap_hwmod: i2c3: _am33xx_disable_module [ 139.350735] omap_hwmod: i2c3: disabling clocks But creation just crashes. root@beaglebone:/sys/bus/platform/drivers/omap_i2c# echo 4819c000.i2c bind [ 145.053929] Unable to handle kernel NULL pointer dereference at virtual address 0001 [ 145.062651] pgd = ca8c [ 145.065507] [0001] *pgd=8f437831, *pte=, *ppte= [ 145.072163] Internal error: Oops: 17 [#1] SMP ARM [ 145.077105] Modules linked in: ipv6 autofs4 [ 145.081537] CPU: 0 PID: 301 Comm: sh Not tainted 3.11.0-rc5-00125-g3b988fb #146 [ 145.089222] task: cf5b5580 ti: cf464000 task.ti: cf464000 [ 145.094918] PC is at omap_i2c_runtime_suspend+0x10/0xb4 [ 145.100408] LR is at omap_i2c_runtime_suspend+0x8/0xb4 [ 145.105808] pc : [c0386350]lr : [c0386348]psr: a00f0013 [ 145.105808] sp : cf465e20 ip : fp : [ 145.117860] r10: 0008 r9 : c00523c0 r8 : cf465e70 [ 145.123346] r7 : 0008 r6 : 03e8 r5 : cf0bd210 r4 : c0027c78 [ 145.130202] r3 : r2 : fa19c000 r1 : cf0bd280 r0 : cf178c10 [ 145.137059] Flags: NzCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment user [ 145.144549] Control: 10c5387d Table: 8a8c0019 DAC: 0015 [ 145.150572] Process sh (pid: 301, stack limit = 0xcf464240) [ 145.156423] Stack: (0xcf465e20 to 0xcf466000) [ 145.161009] 5e20: c0386340 c02cb2fc c0027c84 c0027c78 cf0bd210 c02cc060 [ 145.169594] 5e40: cf0bd210 cf0bd210 c02cc0f4 cf0bd210 03e8 c02cc65c [ 145.178186] 5e60: cf465e8c c0059798 cf0bd2dc 000a0009 cf0bd280 [ 145.186781] 5e80: cf0bd210 03e8 002e cf175d00 c04c3ee4 c02cd344 [ 145.195377] 5ea0: cf178c10 cf0bd210 cf0bd200 c03867dc 0001 c0131124 cf0518b8 c0056890 [ 145.203977] 5ec0: 0003 cf102c08 000186a0 c0704d08 cf0bd210 c0704d08 [ 145.212568] 5ee0: c0714004 cf0bd244 c04c3ee4 cf15f6c0 c02c84ec c02c84d8 c02c7628 [ 145.221151] 5f00: cf5b5580 c0714004 c0704d08 000d cf0bd210 c02c6558 cf18fb48 cf465f80 [ 145.229743] 5f20: 000d cf3c4ec0 cf3c4ed8 c02c5c50 000d c012f050 cf501980 000d [ 145.238331] 5f40: 000d6408 cf465f80 000d6408 cf464000 000d c00d9a5c cf501980 000d6408 [ 145.246923] 5f60: 000d cf501980 000d6408 000d c00d9eb0 [ 145.255510] 5f80: 000d 000d 000d6408 b6f25a80 0004 c000dc08 [ 145.264108] 5fa0: c000da60 000d 000d6408 0001 000d6408 000d [ 145.272703] 5fc0: 000d 000d6408 b6f25a80 0004 000d 000d 000d6408 [ 145.281293] 5fe0: be89d984 b6e61b2c b6eb430c 600f0010 0001 [ 145.289926] [c0386350] (omap_i2c_runtime_suspend+0x10/0xb4) from [c02cb2fc] (pm_generic_runtime_suspend+0x2c/0x40) [ 145.301187] [c02cb2fc] (pm_generic_runtime_suspend+0x2c/0x40) from [c0027c84] (_od_runtime_suspend+0xc/0x24) [ 145.311890] [c0027c84] (_od_runtime_suspend+0xc/0x24) from [c02cc060] (__rpm_callback+0x38/0x68) [ 145.321488] [c02cc060] (__rpm_callback+0x38/0x68) from [c02cc0f4] (rpm_callback+0x64
Re: [PATCH] staging: Platform device tester - Allow removal
Hi Greg, Just to make sure we're on the same page this is with my platform device removal patchset applied. Without it you get the original crash I've posted in the pdevtest patch with the unbind method. Regards -- Pantelis -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] staging: Platform device tester - Allow removal
Hi Russell, On Aug 13, 2013, at 10:02 PM, Russell King - ARM Linux wrote: On Tue, Aug 13, 2013 at 09:59:03PM +0300, Pantelis Antoniou wrote: Hi Greg, Just to make sure we're on the same page this is with my platform device removal patchset applied. Without it you get the original crash I've posted in the pdevtest patch with the unbind method. Yes, congratulations, you've found a bug in the way OMAP uses the runtime PM stuff in this driver. That bug needs to be fixed irrespective of anything else. Not just OMAP. And not just PM stuff. There are crashes occurring due to the way resources are handled by platform devices created via OF. Regards -- Pantelis -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/5] omap: Properly handle resources for omap_devices
Hi On Aug 9, 2013, at 6:16 PM, Kevin Hilman wrote: Pantelis Antoniou pa...@antoniou-consulting.com writes: Hi Kevin, On Aug 7, 2013, at 9:45 PM, Kevin Hilman wrote: [fixing address for Benoit] Pantelis Antoniou pa...@antoniou-consulting.com writes: omap_device relies on the platform notifier callbacks managing resources behind the scenes. The resources were not properly linked causing crashes when removing the device. Rework the resource modification code so that linking is performed properly, and make sure that no resources that have no parent (which can happen for DMA IRQ resources) are ever left for cleanup by the core resource layer. Signed-off-by: Pantelis Antoniou pa...@antoniou-consulting.com This one failed my took more than 15 minutes to understand test. The changelog is rather vague (especially about what properly means), and the combination of moving code and changing it makes the patch rather clunky to read, so I remain a bit confused about what the actual problem is. Please elaborate. Also, could you share a crash dump as well as details about how to reproduce this problem? Thanks, Kevin It's the full patchset that fixes the problem: Let me illustrate: The kernel I use is located at: g...@github.com:pantoniou/linux-beagle-track-mainline.git branch: merge-20130806 (there are topic branches for other stuff too) Sorry, I don't have the time to go through a bunch of out of tree branches to figure this out. Can you create a simpler test case to reproduce this? e.g. Does this happen when building the serial driver as a module and then removing it? If not, why not? What 'bunch of out of tree branches'? There is a single merge branch against current mainline. And no you don't trigger this by removing a module. platform_driver_unregister() != platform_device_register(). I'll try to figure out something simpler, but it's pretty damn obvious that something is not right there. Do you think fixing problems in that part of platform device removal was something I did because I didn't have other things to do? It is broken and I'm trying to get it fixed. Are you? Kevin -- Pantelis -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/5] omap: Properly handle resources for omap_devices
Hi Kevin, On Aug 9, 2013, at 7:35 PM, Kevin Hilman wrote: Pantelis Antoniou pa...@antoniou-consulting.com writes: Hi On Aug 9, 2013, at 6:16 PM, Kevin Hilman wrote: Pantelis Antoniou pa...@antoniou-consulting.com writes: Hi Kevin, On Aug 7, 2013, at 9:45 PM, Kevin Hilman wrote: [fixing address for Benoit] Pantelis Antoniou pa...@antoniou-consulting.com writes: omap_device relies on the platform notifier callbacks managing resources behind the scenes. The resources were not properly linked causing crashes when removing the device. Rework the resource modification code so that linking is performed properly, and make sure that no resources that have no parent (which can happen for DMA IRQ resources) are ever left for cleanup by the core resource layer. Signed-off-by: Pantelis Antoniou pa...@antoniou-consulting.com This one failed my took more than 15 minutes to understand test. The changelog is rather vague (especially about what properly means), and the combination of moving code and changing it makes the patch rather clunky to read, so I remain a bit confused about what the actual problem is. Please elaborate. Also, could you share a crash dump as well as details about how to reproduce this problem? Thanks, Kevin It's the full patchset that fixes the problem: Let me illustrate: The kernel I use is located at: g...@github.com:pantoniou/linux-beagle-track-mainline.git branch: merge-20130806 (there are topic branches for other stuff too) Sorry, I don't have the time to go through a bunch of out of tree branches to figure this out. Can you create a simpler test case to reproduce this? e.g. Does this happen when building the serial driver as a module and then removing it? If not, why not? What 'bunch of out of tree branches'? There is a single merge branch against current mainline. And That branch contains multiple other branches (as you stated yourself above), many of which look to be out of tree: $ git log --oneline --merges panto/master..panto/merge-20130806 031297e Merge branch 'lcdc-fixes' into merge-20130806 44cf018 Merge branch 'usb-fixes' into merge-20130806 3cc739b Merge branch 'tscadc' into merge-20130806 f0ec35d Merge branch 'capemgr' into merge-20130806 4d87712 Merge branch 'general-fixes' into merge-20130806 04535fb Merge branch 'pinctrl-fixes' into merge-20130806 5115b55 Merge branch 'i2c-fixes' into merge-20130806 e96edf5 Merge branch 'capes' into merge-20130806 1eb1779 Merge branch 'dts-fixes' into merge-20130806 ca12149 Merge branch 'mmc-fixes' into merge-20130806 41ed7a0 Merge branch 'pdev-fixes' into merge-20130806 2ba9995 Merge branch 'of-fixes' into merge-20130806 38b5cb4 Merge branch 'dtc-overlays' into merge-20130806 167648d Merge branch 'dtc-fixes' into merge-20130806 2f7de02 Merge branch 'reset' into merge-20130806 $ git log --oneline --no-merges panto/master..panto/merge-20130806 |wc -l 85 Yes, but they have nothing to do with the problem at hand; the only branch that matters i pdev-fixes. And no you don't trigger this by removing a module. platform_driver_unregister() != platform_device_register(). I'll try to figure out something simpler, but it's pretty damn obvious that something is not right there. I agree something does not seem right, and never said otherwise. I'm simply looking for an easy way to reproduce it with mainline. Since it's so damn obvious, I'll accept the insult and agree to being a moron. Please educate me by making it even more obvious with a way to reproduce it against mainline. You can't reproduce it via rmmod'ing a module; it's not the same code path. That you need to do is to call platform_device_unregister() for the affected device on a DT enabled board. The only platform that triggers it currently is the beaglebone with DT overlays support. To get it to trigger on something simpler, I'll have to write a pretty elaborate module where I register the device and then immediately unregister it. Do you think fixing problems in that part of platform device removal was something I did because I didn't have other things to do? Settle down, I said nothing of the sort. On the contrary, I assumed you were being a generous citizen of the community and contributing back your fixes, and as a developer of this part of the kernel, I'm trying to help. If I didn't care, I wouldn't have responded in the first place. OK It is broken and I'm trying to get it fixed. Are you? I was, but your accusatory tone is reducing my motivation to help. I guess that's a fair accusation; sorry for coming out a bit strong here. Anyway, I'll see what it takes to come up with a test module that exhibits the issue easier. Kevin Regards -- Pantelis -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org
Re: [PATCH 3/5] omap: Properly handle resources for omap_devices
Hi Kevin,
On Aug 7, 2013, at 9:45 PM, Kevin Hilman wrote:
[fixing address for Benoit]
Pantelis Antoniou pa...@antoniou-consulting.com writes:
omap_device relies on the platform notifier callbacks managing resources
behind the scenes. The resources were not properly linked causing crashes
when removing the device.
Rework the resource modification code so that linking is performed properly,
and make sure that no resources that have no parent (which can happen for DMA
IRQ resources) are ever left for cleanup by the core resource layer.
Signed-off-by: Pantelis Antoniou pa...@antoniou-consulting.com
This one failed my took more than 15 minutes to understand test. The
changelog is rather vague (especially about what properly means), and
the combination of moving code and changing it makes the patch rather
clunky to read, so I remain a bit confused about what the actual problem
is. Please elaborate.
Also, could you share a crash dump as well as details about how to
reproduce this problem?
Thanks,
Kevin
It's the full patchset that fixes the problem:
Let me illustrate:
The kernel I use is located at:
g...@github.com:pantoniou/linux-beagle-track-mainline.git
branch: merge-20130806 (there are topic branches for other stuff too)
The DT overlay we're loading:
/*
* Copyright (C) 2013 CircuitCo
*
* Virtual cape for UART1 on connector pins P9.24 P9.26
*
* This program is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License version 2 as
* published by the Free Software Foundation.
*/
/dts-v1/;
/plugin/;
/ {
compatible = ti,beaglebone, ti,beaglebone-black;
/* identification */
part-number = BB-UART1;
version = 00A0;
/* state the resources this cape uses */
exclusive-use =
/* the pin header uses */
P9.24,/* uart1_txd */
P9.26,/* uart1_rxd */
/* the hardware ip uses */
uart1;
fragment@0 {
target = am33xx_pinmux;
__overlay__ {
bb_uart1_pins: pinmux_bb_uart1_pins {
pinctrl-single,pins =
0x184 0x20 /* P9.24 uart1_txd.uart1_txd
OUTPUT */
0x180 0x20 /* P9.26 uart1_rxd.uart1_rxd
INPUT */
;
};
};
};
fragment@1 {
target = uart1; /* really uart1 */
__overlay__ {
status = okay;
pinctrl-names = default;
pinctrl-0 = bb_uart1_pins;
};
};
};
Nothing complicated; just a serial device.
With the full patchset on a beaglebone and loading a simple case of a UART
'cape'.
root@beaglebone:/sys/devices/bone_capemgr.4# echo BB-UART1 slots
[ 58.546947] bone-capemgr bone_capemgr.4: part_number 'BB-UART1', version
'N/A'
[ 58.578374] bone-capemgr bone_capemgr.4: slot #4: generic override
[ 58.584925] bone-capemgr bone_capemgr.4: bone: Using override eeprom data
at slot 4
[ 58.593086] bone-capemgr bone_capemgr.4: slot #4: 'Override Board
Name,00A0,Override Manuf,BB-UART1'
[ 58.618455] bone-capemgr bone_capemgr.4: slot #4: Requesting part
number/version based 'BB-UART1-00A0.dtbo
[ 58.638258] bone-capemgr bone_capemgr.4: slot #4: Requesting firmware
'BB-UART1-00A0.dtbo' for board-name 'Override Board Name', version '00A0'
[ 58.681259] bone-capemgr bone_capemgr.4: slot #4: dtbo
'BB-UART1-00A0.dtbo' loaded; converting to live tree
[ 58.705075] bone-capemgr bone_capemgr.4: slot #4: #2 overlays
[ 58.735058] 48022000.serial: ttyO1 at MMIO 0x48022000 (irq = 89) is a OMAP
UART1
[ 58.757834] bone-capemgr bone_capemgr.4: slot #4: Applied #2 overlays.
root@beaglebone:/sys/devices/bone_capemgr.4# echo -4 slots
[ 62.362519] bone-capemgr bone_capemgr.4: Removed slot #4
Revert omap: Properly handle resources for omap_devices
Revert of: Link platform device resources properly.
Revert pdev: Fix platform device resource linking
root@beaglebone:/sys/devices/bone_capemgr.4# echo BB-UART1 slots
[ 39.317978] bone-capemgr bone_capemgr.4: part_number 'BB-UART1', version
'N/A'
[ 39.325630] bone-capemgr bone_capemgr.4: slot #4: generic override
[ 39.332248] bone-capemgr bone_capemgr.4: bone: Using override eeprom data
at slot 4
[ 39.340336] bone-capemgr bone_capemgr.4: slot #4: 'Override Board
Name,00A0,Override Manuf,BB-UART1'
[ 39.378854] bone-capemgr bone_capemgr.4: slot #4: Requesting part
number/version based 'BB-UART1-00A0.dtbo
[ 39.396013] bone-capemgr bone_capemgr.4: slot #4: Requesting firmware
'BB-UART1-00A0.dtbo' for board-name 'Override Board Name', version '00A0'
[ 39.438009] bone-capemgr bone_capemgr.4: slot #4: dtbo
'BB-UART1-00A0
Re: [PATCH 4/5] omap: Avoid crashes in the case of hwmod misconfiguration
Hi Kevin,
On Aug 8, 2013, at 12:15 AM, Kevin Hilman wrote:
Pantelis Antoniou pa...@antoniou-consulting.com writes:
omap hwmod is really sensitive to hwmod misconfiguration.
Getting a minor clock wrong always ended up in a crash.
Attempt to be more resilient by not assigning variables with
error codes and then attempting to use them.
Without this patch, missing a clock ends up with something like this:
omap_hwmod: ehrpwm0: cannot clk_get opt_clk ehrpwm0_tbclk!
Definitely agree we should not be crashing when given bad data.
nit Re: missing clock. I don't think there will be any crash if a
clock is missing. This looks to me more like the clock name is wrong
(tbclk instead of dbclk?), not missing.
Yes, I'll rephrase.
[...]
index 7341eff..42cb7d4 100644
--- a/arch/arm/mach-omap2/omap_hwmod.c
+++ b/arch/arm/mach-omap2/omap_hwmod.c
@@ -784,7 +784,9 @@ static int _init_interface_clks(struct omap_hwmod *oh)
if (IS_ERR(c)) {
pr_warning(omap_hwmod: %s: cannot clk_get
interface_clk %s\n,
oh-name, os-clk);
-ret = -EINVAL;
+if (ret == 0)
+ret = -EINVAL;
+continue;
the 'if (ret == 0)' adds confusion IMO. If we don't care additional
failures, errors, then just add a 'break' instead of these 3 lines.
[...]
I tried to carry on as much as possible even on the presence of errors.
The remaining clocks won't be initialized, but that might be OK.
Kevin
Regards
-- Pantelis
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/5] pdev: Fix platform device resource linking
Hi Greg, On Aug 7, 2013, at 8:56 AM, Greg Kroah-Hartman wrote: On Tue, Aug 06, 2013 at 01:27:35PM +0300, Pantelis Antoniou wrote: Hi Greg, On Aug 6, 2013, at 1:15 PM, Greg Kroah-Hartman wrote: On Tue, Aug 06, 2013 at 12:45:42PM +0300, Pantelis Antoniou wrote: Hi Greg, On Aug 6, 2013, at 12:36 PM, Greg Kroah-Hartman wrote: On Tue, Aug 06, 2013 at 10:53:40AM +0300, Pantelis Antoniou wrote: Platform device removal uncovered a number of problems with the way resources are handled in the core platform code. Resources now form child/parent linkages and this requires proper linking of the resources. On top of that the OF core directly creates it's own platform devices. Simplify things by providing helper functions that manage the linking properly. Ugh, the OF core shouldn't be creating platform devices. Well, yes, I know it does that today, but ick, ick, ick. Yep, ick, ick, ick is the correct form. Two functions are provided: platform_device_link_resources(), which links all the linkable resources (if not already linked). and platform_device_unlink_resources(), which unlinks all the resources. Why would anyone need to call this? I'm getting the feeling that OF should just have it's own bus of devices to handle this type of mess. ACPI is going through the same rewrite for this same type of problem (they did things differently.) I suggest you work with the ACPI developers to so the same thing they are, to solve it correctly for everyone. It's the same problem really. Another bus type might not fly well. The same device driver should be (in theory) be made to work unchanged either on an OF/ACPI/Fex( :) ) setup. No, that's not quite true, a driver needs to know how to talk to the bus, as that is how it communicates to the hardware. It can be done for different types of busses (see the OHCI USB controller for one example of this), but a driver will have to know what type of bus it is on in order to work properly. In the case of OF ACPI there is no 'bus'. The device is probably integrated in the SoC's silicon, but there is absolutely no way to 'probe' for it's existence; you have to use a-priori knowledge of the SoC's topology in order to configure it (along with any per-board specific information if there is any kind of shared resource configuration - i.e. pinmuxing or something else). Not all busses need to have the aiblity to probe for new devices, that's not a requirement at all. Some of them just know where the devices are at in the driver model, and create the devices for the bus just fine. So don't think that just because of that lack of probing, they should be on the platform bus at all. Platform is for the oh crap, I have no way to bind this to anything else, make it a platform device then. I'm not sure if you remember, but a long time ago when OF started getting into the kernel, there actually was an OCP (On Chip Peripheral) bus, and the switch to platform devices was mandated by kernel people, by their insistance that platform devices would cover every case. See here: http://lkml.indiana.edu/hypermail/linux/kernel/0405.1/0930.html I'm sure Matt Porter can shed some light on the exchange that led to the abandonment of the ocp bus concept. Since I've been down the new 'non hardware' bus road before, it seems that there is absolutely no consensus about when a new bus is acceptable or not. There are the 3 well known methods to do so in the Linux kernel right now: 1) Board files in which the configuration information is stored in the per-board platform file encoded in platform data structures. 2) OF, in which case the information is provided via the flat device tree blob the bootloader provides. 3) ACPI in which case the information is provided via the firmware's ACPI tables (I'm not overly familiar with ACPI, so there might be some more nuance here). The device driver for all these cases is absolutely the same; the only place where it differs it's in the way it uses to retrieve that configuration information. Not at all, they all should be differing in how to talk to the hardware, right? Or even if not, it should be pretty trivial for all of them to have drivers that bind to a multiple of different types of busses just fine, no need to want to abuse the platform code because people feel lazy. My point is that there are now a lot of ways to store the configuration options of a given driver; instead of coming up with different ways to get that depending on the bus type the platform happens to be using, let's dictate a single method of getting that information. I just don't feel that having N new bus types is the way to go there, since each bus type will require modification in each driver file for the bus type. OF configuration is pretty much there already, use that as a base and have converters from whatever else is out there to OF. What specifically would
Re: [PATCH 5/5] arm: omap: Proper cleanups for omap_device
Hi Greg, On Aug 6, 2013, at 1:14 PM, Greg Kroah-Hartman wrote: On Tue, Aug 06, 2013 at 12:37:25PM +0300, Pantelis Antoniou wrote: I don't like this at all, sorry. [snip] Don't shoot the messenger please... This is all about fixing a crash without messing too many things. I understand, it's not your fault at all. Let's start talking about the patchset again. I know all of this code is rather distasteful but it's only purpose is to fix a bunch of crashes in a code path that was supposed to be working, namely the removal of a platform device, in the supposedly well supported ARM OMAP arch. Can we agree to at least not crashing until we get to a consensus about fixing the whole mess properly? This will take at least a few minor kernel revisions while in the meantime users get crashes everyday. Regards -- Pantelis -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 5/5] arm: omap: Proper cleanups for omap_device
Hi Tony,
On Aug 7, 2013, at 7:15 PM, Tony Lindgren wrote:
* Pantelis Antoniou pa...@antoniou-consulting.com [130806 02:44]:
On Aug 6, 2013, at 12:33 PM, Greg Kroah-Hartman wrote:
On Tue, Aug 06, 2013 at 10:53:44AM +0300, Pantelis Antoniou wrote:
+
static int _omap_device_notifier_call(struct notifier_block *nb,
unsigned long event, void *dev)
{
@@ -185,9 +211,13 @@ static int _omap_device_notifier_call(struct
notifier_block *nb,
struct omap_device *od;
switch (event) {
- case BUS_NOTIFY_DEL_DEVICE:
+ case BUS_NOTIFY_UNBOUND_DRIVER:
+ /* NOTIFY_DEL_DEVICE is not the right call...
+ * we use a callback here, to make sure no-one is going to
+ * try to use the omap_device data after they're deleted
+ */
if (pdev-archdata.od)
- omap_device_delete(pdev-archdata.od);
+ device_schedule_callback(dev, _omap_device_cleanup);
Really? This is one sign that you are totally using the driver core
incorrectly. You shouldn't have to rely on notifier callbacks to handle
device removals, your bus code should do that for you directly.
I don't like this at all, sorry.
Don't shoot the messenger please...
As you're inititalizing capebus with DT, let's figure out what if
anything you actually need from omap_device. I'd much rather remove
dependencies than add more.
There is no such thing as capebus anymore. This is just the path of
removing a platform device, which happens to also be an omap_device.
If you need omap_device for the clocks, there are patches pending to
make them DT only for omaps. And we already have DT based solution for
pins, regulators and DMA.
So what else remains? The pieces needed for runtime PM?
What happens here is that the omap_device data are freed prematurely and then
end up
used again during the teardown of the platform device.
This is all about fixing a crash without messing too many things.
It seems this fix is only needed for supporting out-of-tree code?
These features with omap_device we may not even want to support in
the mainline tree as is being discussed..
What out of tree code? The only thing this patch does is make sure we
don't crash when a perfectly valid call to platform_device_unregister() happens.
Drivers that don't use omap_device work just fine.
Regards,
Tony
Regards
-- Pantelis
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/5] pdev: Fix platform device resource linking
Hi Greg, On Aug 6, 2013, at 12:36 PM, Greg Kroah-Hartman wrote: On Tue, Aug 06, 2013 at 10:53:40AM +0300, Pantelis Antoniou wrote: Platform device removal uncovered a number of problems with the way resources are handled in the core platform code. Resources now form child/parent linkages and this requires proper linking of the resources. On top of that the OF core directly creates it's own platform devices. Simplify things by providing helper functions that manage the linking properly. Ugh, the OF core shouldn't be creating platform devices. Well, yes, I know it does that today, but ick, ick, ick. Yep, ick, ick, ick is the correct form. Two functions are provided: platform_device_link_resources(), which links all the linkable resources (if not already linked). and platform_device_unlink_resources(), which unlinks all the resources. Why would anyone need to call this? I'm getting the feeling that OF should just have it's own bus of devices to handle this type of mess. ACPI is going through the same rewrite for this same type of problem (they did things differently.) I suggest you work with the ACPI developers to so the same thing they are, to solve it correctly for everyone. It's the same problem really. Another bus type might not fly well. The same device driver should be (in theory) be made to work unchanged either on an OF/ACPI/Fex( :) ) setup. What would it take to move all this into driver core? thanks, greg k-h Regards -- Pantelis -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/5] pdev: Fix platform device resource linking
Hi Greg, On Aug 6, 2013, at 1:15 PM, Greg Kroah-Hartman wrote: On Tue, Aug 06, 2013 at 12:45:42PM +0300, Pantelis Antoniou wrote: Hi Greg, On Aug 6, 2013, at 12:36 PM, Greg Kroah-Hartman wrote: On Tue, Aug 06, 2013 at 10:53:40AM +0300, Pantelis Antoniou wrote: Platform device removal uncovered a number of problems with the way resources are handled in the core platform code. Resources now form child/parent linkages and this requires proper linking of the resources. On top of that the OF core directly creates it's own platform devices. Simplify things by providing helper functions that manage the linking properly. Ugh, the OF core shouldn't be creating platform devices. Well, yes, I know it does that today, but ick, ick, ick. Yep, ick, ick, ick is the correct form. Two functions are provided: platform_device_link_resources(), which links all the linkable resources (if not already linked). and platform_device_unlink_resources(), which unlinks all the resources. Why would anyone need to call this? I'm getting the feeling that OF should just have it's own bus of devices to handle this type of mess. ACPI is going through the same rewrite for this same type of problem (they did things differently.) I suggest you work with the ACPI developers to so the same thing they are, to solve it correctly for everyone. It's the same problem really. Another bus type might not fly well. The same device driver should be (in theory) be made to work unchanged either on an OF/ACPI/Fex( :) ) setup. No, that's not quite true, a driver needs to know how to talk to the bus, as that is how it communicates to the hardware. It can be done for different types of busses (see the OHCI USB controller for one example of this), but a driver will have to know what type of bus it is on in order to work properly. In the case of OF ACPI there is no 'bus'. The device is probably integrated in the SoC's silicon, but there is absolutely no way to 'probe' for it's existence; you have to use a-priori knowledge of the SoC's topology in order to configure it (along with any per-board specific information if there is any kind of shared resource configuration - i.e. pinmuxing or something else). There are the 3 well known methods to do so in the Linux kernel right now: 1) Board files in which the configuration information is stored in the per-board platform file encoded in platform data structures. 2) OF, in which case the information is provided via the flat device tree blob the bootloader provides. 3) ACPI in which case the information is provided via the firmware's ACPI tables (I'm not overly familiar with ACPI, so there might be some more nuance here). The device driver for all these cases is absolutely the same; the only place where it differs it's in the way it uses to retrieve that configuration information. The board file method is pretty much no-go due to the need to support multiple boards from a single kernel; that leaves OF and ACPI. From what I can tell what ACPI supports is a very small subset of what OF can support right now; that is both number of device drivers, as well as what you can do with device driver functionality (see things like gpios etc, how much easier is to use with OF). Since we're in the let's make a wish stage, what I wish for is a board-file ACPI translator stage to OF data, and depreciating everything else gradually. That would kill platform_device and ACPI specific data and move everything to a common device structure supporting OF for configuration. What would it take to move all this into driver core? What specifically would you move into there? Pretty much everything that's in the union of platform_device whatever acpi uses to hold it's configuration info. thanks, greg k-h Regards -- Pantelis -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ti_tscadc: Update with IIO map interface deal with partial activation
Hi Jonathan, On May 6, 2013, at 7:12 PM, Jonathan Cameron wrote: On 05/06/2013 01:48 PM, Jan Luebbe wrote: Hi Pantelis, while trying out your patch on a custom AM335x board, I noticed that the sysfs entries ware missing. This is fixed in the first patch, you might want to squash that into your original patch. The second one makes sure that the iio framework does not read invalid data. Regards, Jan I don't believe Pantelis ever came back with a response to the various issues raised with the original patches? I am aware. We've been quite busy getting the new beaglebone out. I plan to revisit the full patchset for all the various fixes we had to do in a month or so. If Pantelis has moved on, Jan feel free to pick up the patches, respin them and resend to linux-iio if you like (with appropriate crediting naturally) I wouldn't mind Jan to pick up the IIO patches. Until these are appropriately fixed up and resent, I'm lazy so will ignore these. (your patches look reasonable to me based on a really superficial look) Jonathan Regards -- Pantelis -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/5] capemgr: Add beaglebone's cape driver bindings
Hi Grant On Mar 26, 2013, at 7:36 PM, Grant Likely wrote: On Mon, 7 Jan 2013 20:51:03 +0200, Pantelis Antoniou pa...@antoniou-consulting.com wrote: Document the beaglebone's cape driver bindings. Signed-off-by: Pantelis Antoniou pa...@antoniou-consulting.com Hi Pantelis, I'll go back and review the driver in a minute, but I'll start here since this is the data model that we'll be using for a long time. Overall this looks pretty sane. It's pretty well contained too which I like. Long term I do want to try and create some common patterns for overlay connections, but it's really hard to do that when this is the first serious attempt at implementing one. :-) This is nicely contained to only the beaglebone use case which makes it easy to try out without forcing this exact data model on all users. If it works in other places, then fantastic! we've got our generic model. If not, then we can refine the interface for new boards without breaking beaglebone. Glad you liked it. I really tried hard to keep things nicely separated since we're definitely on to uncharted waters. We will definitely adopt this for the beagleboard too (maybe some other boards too) so some rearrangement will take place for the v2 of the patches. We're under the gun for the new beaglebone that's coming out shortly, so the new patches will be out in a couple of weeks. Comments below... --- .../devicetree/bindings/misc/capes-beaglebone.txt | 110 + 1 file changed, 110 insertions(+) create mode 100644 Documentation/devicetree/bindings/misc/capes-beaglebone.txt diff --git a/Documentation/devicetree/bindings/misc/capes-beaglebone.txt b/Documentation/devicetree/bindings/misc/capes-beaglebone.txt new file mode 100644 index 000..f73cab5 --- /dev/null +++ b/Documentation/devicetree/bindings/misc/capes-beaglebone.txt @@ -0,0 +1,110 @@ +* TI Beaglebone DT Overlay Cape Driver + +Required properties: + +- compatible: ti,bone-capemgr capemgr sounds like a software construct. Can you rename this to something that sounds more like describing concrete hardware? From that perspective, ti,bone-capebus would be appropriate here, regardless of where the driver actually lives in the kernel tree. Hum, well I guess so, that would work. Perhaps same as with ti,beagle-capebus. But I thought using the work bus was out :) It would be better to be more specific here with the compatible property also. Put the actual board name into the compatible string. Following the lead of the board level compatible property, call it 'ti,am335x-bone-capebus. Newer boards can claim compatibilty with the older where appropriate. Let's not put am335x there, there's nothing SoC specific. The bone is a am335x, but the beagleboard is not, etc. There's also some crazy talk about compatibility between different board families; we can keep it aside for now, but let's not assign anything SoC specific. + +- eeprom: Contains the phandle beaglebone's baseboard i2c eeprom. + +- baseboardmaps - node containing a list of supported +beaglebone revisions; each node in should have the +following properties: +- board-name: The board name stored in the baseboard +eeprom. If it is stored in the baseboard eeprom, then why does it need to appear in the .dtb? It needs to because there are slightly different revisions of the bone. Defining the revisions it allows us to auto-load the dtbos containing the differences for the baseboard revision. In this way we keep the same kernel/software images working on all the bone revisions, significantly reducing the support burden. +- compatible-name: The name which will be used for +matching compatible capes. What is the matching logic for this compatible capes? How does it get used? See below. + +- slots: node containing a list of slot nodes (which in the beaglebone +case correspond to I2C addresses for dynamically probed capes, +or an override slot definition for hardcoded capes. +- eeprom: Contains the phandle beaglebone's cape i2c eeprom. + +It is possible to define override slots that will be activated +when the baseboard matches, and/or if supplied on the kernel command +line and/or when dynamically requested on runtime. +In that case the slot is marked with +- ti,cape-override: Marks a slot override. +- compatible: any of the runtime, kernel, or any compatible-name + on a matching baseboardmap node. +- Any of the eeprom-format-revision, board-name, version, manufacturer, + part-number, number-of-pins, serial-number, pin-usage, vdd-3v3exp, + vdd-5v, sys-5v, dc-supplied properties which fill in the simulated + cape's EEPROM fields. The part-number field is required, the rest + are optional taking into default values. I could use some help understanding the use-case for the override slots. It isn't clear to me
Re: [PATCH 5/6] OF: Introduce Device Tree resolve support.
Hi Grant, On Mar 19, 2013, at 7:18 PM, Grant Likely wrote: On Tue, 19 Mar 2013 13:51:01 +0200, Pantelis Antoniou pa...@antoniou-consulting.com wrote: Hi Grant, On Mar 16, 2013, at 11:24 AM, Grant Likely wrote: On Wed, 23 Jan 2013 12:58:02 +0200, Pantelis Antoniou pa...@antoniou-consulting.com wrote: Hi David, On Jan 23, 2013, at 6:40 AM, David Gibson wrote: Ok. Nonetheless it's not hard to avoid a recursive approach here. How can I find the maximum phandle value of a subtree without using recursion. Note that the whole function is just 6 lines long. It's a failure in the existing kernel DT data structures. We need a hash lookup for the phandles to eliminate the search entirely. Then you'd be able to allocated new phandles on the fly easily and resolve phandles without searching the whole tree (which has always been horrible). Yes, it is pretty obvious that the in-kernel data structures are sub-optimal. But I was not after modifying them, since that's a different kind of problem. Think about it this way; fixing up that aspect of the data structure makes the job you're trying to do a lot easier. I don't feel bad about asking you to add a radix tree for phandle lookups when it makes your patches a whole lot better. :-) Oh that's going to be fun... maybe. Since we're having a 'sub-optimal' data structures, I'd like to point out that the usage of of_find_by_name(), mostly by drivers trying to find a child of their own node, works by a lucky accident of how the device nodes are instantiated by the flat tree loader. Most of the use cases should be replaced by a call to of_get_child_by_name() which does the right thing. It is true. In fact, calling of_find_node_by_name() when using .dtb is most likely a bug since using node name to determine behaviour is strongly discouraged. Maybe mark the function as deprecated then? Easier to get people to fix it. Fair enough, but be warned that phandle resolution the overlay feature is mostly useless. In actual practice the amount of driver nodes that can be overlaid without a single case of referencing phandles outside (or within) their own blob is close to zero. That's not what I'm saying. I'm saying that (at least for now) we should require the overlay to already know the phandles from the parent and to refuse to load an overlay that defines phandles already in use in the base. Overlays do become usable at that point. A mechanism for phandle resolution so that conflicts can be found and resolved can be added as a feature enhancement. By splitting it out you'll be able to get the overlay feature merged even if we don't have agreement on the resolution mechanism yet. As long as we don't come up with something that's too difficult to use for non kernel developers. I would hate to punt and push all the complexity of phandle resolution to the driver/cape developer. FWIW, the resolution mechanism we use on the beaglebone seems to work just fine, and people seem to handle it just fine. The part that trips them is mostly how to install the updated dtc compiler that's required. g. Regards -- Pantelis -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/6] OF: Export all DT proc update functions
Hi Grant, The 3rd patch is in preparation for some patches I have in WIP that would allow drivers to set notifications for properties that are changed in runtime. I think that since you have the all configuration taking place via DT and you have a method to alter DT properties in run-time via /proc/device-tree, it's quite straightforward to be able to alter runtime behavior via the same mechanism. I.e. if you have some property that controls a devices behavior, it's intuitive that when you modify that property, the device's state changes accordingly. Regards -- Pantelis On Mar 16, 2013, at 11:45 AM, Grant Likely wrote: On Fri, 4 Jan 2013 21:31:07 +0200, Pantelis Antoniou pa...@antoniou-consulting.com wrote: There are other users for the proc DT functions. Export them. Signed-off-by: Pantelis Antoniou pa...@antoniou-consulting.com Hi Pantelis. Patches 1 2 look good. No comments there. This patch bothers me. The manipulation of the proc entries is part and parcel of adding and removing nodes. The real problem seems to be that the node addition/removal APIs need to be made usable by the overlay code. g. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 5/6] OF: Introduce Device Tree resolve support.
Hi Grant, On Mar 16, 2013, at 11:24 AM, Grant Likely wrote: On Wed, 23 Jan 2013 12:58:02 +0200, Pantelis Antoniou pa...@antoniou-consulting.com wrote: Hi David, On Jan 23, 2013, at 6:40 AM, David Gibson wrote: Ok. Nonetheless it's not hard to avoid a recursive approach here. How can I find the maximum phandle value of a subtree without using recursion. Note that the whole function is just 6 lines long. It's a failure in the existing kernel DT data structures. We need a hash lookup for the phandles to eliminate the search entirely. Then you'd be able to allocated new phandles on the fly easily and resolve phandles without searching the whole tree (which has always been horrible). Yes, it is pretty obvious that the in-kernel data structures are sub-optimal. But I was not after modifying them, since that's a different kind of problem. Since we're having a 'sub-optimal' data structures, I'd like to point out that the usage of of_find_by_name(), mostly by drivers trying to find a child of their own node, works by a lucky accident of how the device nodes are instantiated by the flat tree loader. Most of the use cases should be replaced by a call to of_get_child_by_name() which does the right thing. That said, I'd like to punt on the whole phandle resolution thing. The DT overlay support can be merged without the phandle resolution support if the core rejects any overlays with phandle collisions. Fair enough, but be warned that phandle resolution the overlay feature is mostly useless. In actual practice the amount of driver nodes that can be overlaid without a single case of referencing phandles outside (or within) their own blob is close to zero. g. Regards -- Pantelis -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/6] Introducing Device Tree Overlays
Hi Alan, On Feb 21, 2013, at 1:25 PM, delicious quinoa wrote: I like where this is heading. I'm interested in a use case where IP can be loaded into a FPGA, then add a blob to the device tree and load some drivers. I see your github tree. If I wanted to cherry-pick your code and play around with it, which branch should I use? not-capebus-21? not-capebus-v21 is the latest one and indeed that has it in. Please note that I had some other FPGA people interested with it. Perhaps we can go through use cases to come up with your requirements Thanks, Alan Tull Altera Corp Regards -- Pantelis On Fri, Jan 4, 2013 at 1:31 PM, Pantelis Antoniou pa...@antoniou-consulting.com wrote: The following patchset introduces Device Tree overlays, a method of dynamically altering the kernel's live Device Tree. This patchset is against mainline as of Friday Jan 4 2013. (4956964 Merge tag 'driver-core-3.8-rc2' of \ git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core) Note that a separate patch for the DTC compiler has been posted and is required to compile the DTS files according to the documentation. The patch is dtc: Dynamic symbols fixup support An implementation patchset for a beaglebone cape loader will follow, but if you want to check out a working kernel for the beaglebone please pull from: git://github.com/pantoniou/linux-bbxm.git branch not-capebus-v8 Pantelis Antoniou (6): OF: Introduce device tree node flag helpers. OF: export of_property_notify OF: Export all DT proc update functions OF: Introduce utility helper functions OF: Introduce Device Tree resolve support. OF: Introduce DT overlay support. .../devicetree/dynamic-resolution-notes.txt| 25 + Documentation/devicetree/overlay-notes.txt | 179 + drivers/of/Kconfig | 19 + drivers/of/Makefile| 4 +- drivers/of/base.c | 114 +-- drivers/of/overlay.c | 831 + drivers/of/resolver.c | 394 ++ drivers/of/util.c | 253 +++ include/linux/of.h | 243 ++ 9 files changed, 2005 insertions(+), 57 deletions(-) create mode 100644 Documentation/devicetree/dynamic-resolution-notes.txt create mode 100644 Documentation/devicetree/overlay-notes.txt create mode 100644 drivers/of/overlay.c create mode 100644 drivers/of/resolver.c create mode 100644 drivers/of/util.c -- 1.7.12 ___ devicetree-discuss mailing list devicetree-disc...@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/1] drivers: net: davinci_cpdma: acknowledge interrupt properly
Hi On Jan 31, 2013, at 12:17 PM, Mugunthan V N wrote: On 1/31/2013 1:33 AM, Koen Kooi wrote: Op 30 jan. 2013, om 20:56 heeft Mugunthan V N mugunthan...@ti.com het volgende geschreven: CPDMA interrupts are not properly acknowledged which leads to interrupt storm, only cpdma interrupt 0 is acknowledged in Davinci CPDMA driver. Changed cpdma_ctlr_eoi api to acknowledge 1 and 2 interrupts which are used for rx and tx respectively. A brief inspection shows that this still isn't following the TRM, but Pantelis' patch does. Can you please fix this driver to follow the TRM and make it work on both PG1.0 and PG2.0 instead of papering over bugs instead of fixing them properly? Existing driver implementation is also complies with TRM. What Pantelis added additionally are non-napi implementation, handled cpdma processed tx and rx processing separately and renamed wr_reg as per TRM naming convention.. Also he has added a dummy reading tx/rx stat which is mentioned in TRM, but this stat is required only when using multichannel for data transfer. Current implementation of CPSW driver uses only channel 0 of Tx and Rx channels respectively for transmission and reading stat doesn't gets any effect in interrupt acknowledgment. Since both tx and rx are processed in same napi api, so i have added interrupt acknowledgment to the same existing api. First of all, this method of not needing to read the stat registers besides when using multichannel for data transfers is never described anywhere in any manual, or in the driver sources. Secondly, I find the method of ack-ing all interrupt sources problematic. Consider the following sequence Rx-interrupt --- | | | IRQ handler | | schedules NAPI | | disables interrupts -- | cpsw_poll() | | handle Rx Tx-interrupt --- |-|- | | ack Rx Tx IRQ | | enable interrupts When will the Tx interrupt get handled? Is it guaranteed that the DMA logic will assert the Tx interrupt when the interrupts are enabled, even though the interrupt was previously acked? It is not clear in the TRM. Another problem that I see is that the other interrupts (MISC) are not supposed to be routed to the napi cpsw_poll() function at all. NAPI is for the tx/rx path as far as I know. Regards Mugunthan V N Regards -- Pantelis -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] cpsw: Fix interrupt storm among other things
Hi Peter, On Jan 28, 2013, at 11:14 PM, Peter Korsgaard wrote: Pantelis == Pantelis Antoniou pa...@antoniou-consulting.com writes: 'among other things' is not a very descriptive commit message. Pantelis Fix interrupt storm on bone A4 cause by non-by-the-book Pantelis interrupt handling. While at it, added a non-NAPI mode Pantelis (which is easier to debug), plus some general fixes. 'bone A4' is also not very descriptive. There also was an A4 revision of the old beaglebone. I guess you're instead referring to a new die revision? What is the impact of this change on earlier devices? Same driver works perfectly fine with the PG1.0 bone version I have. If you take a look at the TRM it should be pretty obvious why the change was needed. Pantelis +++ b/Documentation/devicetree/bindings/net/cpsw.txt Pantelis @@ -20,6 +20,7 @@ Required properties: Pantelis - cpts_clock_shift : Denominator to convert input clock ticks into nanoseconds Pantelis - phy_id : Specifies slave phy id Pantelis - mac-address : Specifies slave MAC address Pantelis +- disable-napi : Disables driver NAPI napi is not a hardware feature, so it doesn't belong here (if anything, it should be linux,disable-napi). Point taken. -- Bye, Peter Korsgaard Regards -- Pantelis -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] cpsw: Fix interrupt storm among other things
Hi Mugunthan, On Jan 29, 2013, at 1:45 PM, Mugunthan V N wrote: On 1/28/2013 6:41 PM, Pantelis Antoniou wrote: Fix interrupt storm on bone A4 cause by non-by-the-book interrupt handling. While at it, added a non-NAPI mode (which is easier to debug), plus some general fixes. Signed-off-by: Pantelis Antoniou pa...@antoniou-consulting.com --- Documentation/devicetree/bindings/net/cpsw.txt | 1 + drivers/net/ethernet/ti/cpsw.c | 222 + drivers/net/ethernet/ti/davinci_cpdma.c| 4 +- drivers/net/ethernet/ti/davinci_cpdma.h| 2 +- include/linux/platform_data/cpsw.h | 1 + 5 files changed, 194 insertions(+), 36 deletions(-) I have tested CPSW on AM335x EVM 1.5A with flood ping and i am not seeing any interrupt storm. Can you provide more details on how to reproduce the issue. A beaglebone prototype with the new silicon version, with the ethernet errata fixed displays this. You can't trigger it on old silicon. The TI people on the CC list can confirm. Regards Mugunthan V N Regards -- Pantelis -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] cpsw: Fix interrupt storm among other things
Hi, On Jan 30, 2013, at 11:03 AM, Mugunthan V N wrote: On 1/30/2013 2:06 PM, Pantelis Antoniou wrote: Hi Mugunthan, On Jan 29, 2013, at 1:45 PM, Mugunthan V N wrote: On 1/28/2013 6:41 PM, Pantelis Antoniou wrote: Fix interrupt storm on bone A4 cause by non-by-the-book interrupt handling. While at it, added a non-NAPI mode (which is easier to debug), plus some general fixes. Signed-off-by: Pantelis Antoniou pa...@antoniou-consulting.com --- Documentation/devicetree/bindings/net/cpsw.txt | 1 + drivers/net/ethernet/ti/cpsw.c | 222 + drivers/net/ethernet/ti/davinci_cpdma.c| 4 +- drivers/net/ethernet/ti/davinci_cpdma.h| 2 +- include/linux/platform_data/cpsw.h | 1 + 5 files changed, 194 insertions(+), 36 deletions(-) I have tested CPSW on AM335x EVM 1.5A with flood ping and i am not seeing any interrupt storm. Can you provide more details on how to reproduce the issue. A beaglebone prototype with the new silicon version, with the ethernet errata fixed displays this. You can't trigger it on old silicon. The TI people on the CC list can confirm. But i have the same silicon revision (PG2.0) in my EVM and I am not seeing any issues. Can you point me to the ethernet errata which you are mentioning? Regards Mugunthan V N What kernel version are you using? This is only triggered on the mainline driver. The advisory in question: From http://www.ti.com/lit/er/sprz360c/sprz360c.pdf Advisory 1.0.9: Ethernet Media Access Controller and Switch Subsystem: C0_TX_PEND and C0_RX_PEND Interrupts Not Connected to ARM Cortex-A8 I bet you're using an old kernel driver with the workarounds with the timers. If I had to guess (although I didn't use a probe or anything) is that the interrupts are now proper level interrupts, instead of working in edge triggered mode due to the workaround. Apparently the interrupt was never acked properly in the original driver (the sequence described in the TRM is not followed). Looking at the TRM (spruh73g.pdf) 14.3.1.3 Interrupts in particular, the the status registers are not read, and more damning the proper values to the CPDMA_EOI_VECTOR register are not written. The original driver blindly wrote zero (cpdma_ctlr_eoi), while you have to write different values according to the interrupt you ack. What happened was that on the first interrupt, the interrupt was never acked, and we had an irq storm... Regards -- Pantelis -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] cpsw: Fix interrupt storm among other things
Hi Mugunthan, On Jan 30, 2013, at 12:55 PM, Mugunthan V N wrote: On 1/30/2013 3:06 PM, Pantelis Antoniou wrote: Hi, On Jan 30, 2013, at 11:03 AM, Mugunthan V N wrote: On 1/30/2013 2:06 PM, Pantelis Antoniou wrote: Hi Mugunthan, On Jan 29, 2013, at 1:45 PM, Mugunthan V N wrote: On 1/28/2013 6:41 PM, Pantelis Antoniou wrote: Fix interrupt storm on bone A4 cause by non-by-the-book interrupt handling. While at it, added a non-NAPI mode (which is easier to debug), plus some general fixes. Signed-off-by: Pantelis Antoniou pa...@antoniou-consulting.com --- Documentation/devicetree/bindings/net/cpsw.txt | 1 + drivers/net/ethernet/ti/cpsw.c | 222 + drivers/net/ethernet/ti/davinci_cpdma.c| 4 +- drivers/net/ethernet/ti/davinci_cpdma.h| 2 +- include/linux/platform_data/cpsw.h | 1 + 5 files changed, 194 insertions(+), 36 deletions(-) I have tested CPSW on AM335x EVM 1.5A with flood ping and i am not seeing any interrupt storm. Can you provide more details on how to reproduce the issue. A beaglebone prototype with the new silicon version, with the ethernet errata fixed displays this. You can't trigger it on old silicon. The TI people on the CC list can confirm. But i have the same silicon revision (PG2.0) in my EVM and I am not seeing any issues. Can you point me to the ethernet errata which you are mentioning? Regards Mugunthan V N What kernel version are you using? This is only triggered on the mainline driver. The advisory in question: From http://www.ti.com/lit/er/sprz360c/sprz360c.pdf Advisory 1.0.9: Ethernet Media Access Controller and Switch Subsystem: C0_TX_PEND and C0_RX_PEND Interrupts Not Connected to ARM Cortex-A8 I bet you're using an old kernel driver with the workarounds with the timers. If I had to guess (although I didn't use a probe or anything) is that the interrupts are now proper level interrupts, instead of working in edge triggered mode due to the workaround. Apparently the interrupt was never acked properly in the original driver (the sequence described in the TRM is not followed). Looking at the TRM (spruh73g.pdf) 14.3.1.3 Interrupts in particular, the the status registers are not read, and more damning the proper values to the CPDMA_EOI_VECTOR register are not written. The original driver blindly wrote zero (cpdma_ctlr_eoi), while you have to write different values according to the interrupt you ack. What happened was that on the first interrupt, the interrupt was never acked, and we had an irq storm... Regards -- Pantelis The above mentioned advisory is for PG1.0 and not for PG2.0 I am booting net-next kernel. [0.00] Booting Linux on physical CPU 0x0 [0.00] Linux version 3.8.0-rc5-01248-gd2ed273 (a0131834@a0131834-linux) (gcc version 4.5.3 20110311 (prerelease) (GCC) ) #21 SMP Wed Jan 30 163 [0.00] CPU: ARMv7 Processor [413fc082] revision 2 (ARMv7), cr=10c53c7d [0.00] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache [root@arago /]# uname -a Linux arago 3.8.0-rc5-01248-gd2ed273 #21 SMP Wed Jan 30 16:13:26 IST 2013 armv7l GNU/Linux In theory what you are mentioning is correct. I have a beagle bone black and yet to try it. I don't know what kind of silicon revision you have there. FWIW both the original bone and the black show the exact same CPU: ARMv7 lines: bone-original: [0.00] CPU: ARMv7 Processor [413fc082] revision 2 (ARMv7), cr=10c5387d bone-black: (with the known silicon version that has the fix) [0.00] CPU: ARMv7 Processor [413fc082] revision 2 (ARMv7), cr=10c5387d TBH I haven't found a simple way to print out the silicon revision number. Anyone on the list know a quick and dirty method? Regards Mugunthan V N Regards -- Pantelis -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] cpsw: Fix interrupt storm among other things
Hi Vaibhav, On Jan 30, 2013, at 2:38 PM, Bedia, Vaibhav wrote: On Wed, Jan 30, 2013 at 16:38:50, Pantelis Antoniou wrote: [...] TBH I haven't found a simple way to print out the silicon revision number. Anyone on the list know a quick and dirty method? You can dump the DEVICE_ID register @ 0x44e10600. Bits 31:28 should be 0 for PG1.0 and 1 for PG2.0. Thanks this works perfectly: original-bone: root@beaglebone:~# devmem2 0x44e10600 w Read at address 0x44E10600 (0xb6ff4600): 0x0B94402E bone-black: root@beaglebone:~# devmem2 0x44e10600 w Read at address 0x44E10600 (0xb6fcc600): 0x1B94402E Regards, Vaibhav Regards -- Pantelis -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] cpsw: Fix interrupt storm among other things
Hi Vaibhav, On Jan 30, 2013, at 3:29 PM, Bedia, Vaibhav wrote: On Wed, Jan 30, 2013 at 18:14:30, Pantelis Antoniou wrote: Hi Vaibhav, On Jan 30, 2013, at 2:38 PM, Bedia, Vaibhav wrote: On Wed, Jan 30, 2013 at 16:38:50, Pantelis Antoniou wrote: [...] TBH I haven't found a simple way to print out the silicon revision number. Anyone on the list know a quick and dirty method? You can dump the DEVICE_ID register @ 0x44e10600. Bits 31:28 should be 0 for PG1.0 and 1 for PG2.0. Thanks this works perfectly: original-bone: root@beaglebone:~# devmem2 0x44e10600 w Read at address 0x44E10600 (0xb6ff4600): 0x0B94402E bone-black: root@beaglebone:~# devmem2 0x44e10600 w Read at address 0x44E10600 (0xb6fcc600): 0x1B94402E I just re-read the mail-chain and I am confused here. So the patch in question is meant for Bone-A4 which has PG1.0? It is a general bug fix. The problem was discovered only on the bone black which has PG2.0 silicon. The driver has been tested and it works on the original bone with PG1.0 as well. Regards, Vaibhav Regards -- Pantelis -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] cpsw: Fix interrupt storm among other things
Hi Vaibhav, On Jan 30, 2013, at 3:47 PM, Bedia, Vaibhav wrote: Hi Antoniou, On Wed, Jan 30, 2013 at 19:07:19, Pantelis Antoniou wrote: Hi Vaibhav, On Jan 30, 2013, at 3:29 PM, Bedia, Vaibhav wrote: On Wed, Jan 30, 2013 at 18:14:30, Pantelis Antoniou wrote: Hi Vaibhav, On Jan 30, 2013, at 2:38 PM, Bedia, Vaibhav wrote: On Wed, Jan 30, 2013 at 16:38:50, Pantelis Antoniou wrote: [...] TBH I haven't found a simple way to print out the silicon revision number. Anyone on the list know a quick and dirty method? You can dump the DEVICE_ID register @ 0x44e10600. Bits 31:28 should be 0 for PG1.0 and 1 for PG2.0. Thanks this works perfectly: original-bone: root@beaglebone:~# devmem2 0x44e10600 w Read at address 0x44E10600 (0xb6ff4600): 0x0B94402E bone-black: root@beaglebone:~# devmem2 0x44e10600 w Read at address 0x44E10600 (0xb6fcc600): 0x1B94402E I just re-read the mail-chain and I am confused here. So the patch in question is meant for Bone-A4 which has PG1.0? It is a general bug fix. The problem was discovered only on the bone black which has PG2.0 silicon. The driver has been tested and it works on the original bone with PG1.0 as well. But Mugunthan mentioned that he doesn't see this on an EVM with PG2.0 silicon... is there any board dependency here? I don't know, but I doubt it. How about we wait for Mugunthan to send us what are the DEVICE_ID contents for his board. Regards, Vaibhav Regards -- Pantelis -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] cpsw: Fix interrupt storm among other things
Hi Mugunthan, On Jan 30, 2013, at 3:53 PM, Mugunthan V N wrote: On 1/30/2013 7:21 PM, Pantelis Antoniou wrote: Hi Vaibhav, On Jan 30, 2013, at 3:47 PM, Bedia, Vaibhav wrote: Hi Antoniou, On Wed, Jan 30, 2013 at 19:07:19, Pantelis Antoniou wrote: Hi Vaibhav, On Jan 30, 2013, at 3:29 PM, Bedia, Vaibhav wrote: On Wed, Jan 30, 2013 at 18:14:30, Pantelis Antoniou wrote: Hi Vaibhav, On Jan 30, 2013, at 2:38 PM, Bedia, Vaibhav wrote: On Wed, Jan 30, 2013 at 16:38:50, Pantelis Antoniou wrote: [...] TBH I haven't found a simple way to print out the silicon revision number. Anyone on the list know a quick and dirty method? You can dump the DEVICE_ID register @ 0x44e10600. Bits 31:28 should be 0 for PG1.0 and 1 for PG2.0. Thanks this works perfectly: original-bone: root@beaglebone:~# devmem2 0x44e10600 w Read at address 0x44E10600 (0xb6ff4600): 0x0B94402E bone-black: root@beaglebone:~# devmem2 0x44e10600 w Read at address 0x44E10600 (0xb6fcc600): 0x1B94402E I just re-read the mail-chain and I am confused here. So the patch in question is meant for Bone-A4 which has PG1.0? It is a general bug fix. The problem was discovered only on the bone black which has PG2.0 silicon. The driver has been tested and it works on the original bone with PG1.0 as well. But Mugunthan mentioned that he doesn't see this on an EVM with PG2.0 silicon... is there any board dependency here? I don't know, but I doubt it. How about we wait for Mugunthan to send us what are the DEVICE_ID contents for his board. Regards, Vaibhav Regards -- Pantelis This is the device ID which i have [root@arago /]# devmem 0x44e10600 0x1B94402E No clue what's the difference of the black with the EVM, and why this happens. The fix is valid anyway. Regards Mugunthan V N Regards -- Pantelis -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] cpsw: Fix interrupt storm among other things
Fix interrupt storm on bone A4 cause by non-by-the-book interrupt handling.
While at it, added a non-NAPI mode (which is easier to debug), plus
some general fixes.
Signed-off-by: Pantelis Antoniou pa...@antoniou-consulting.com
---
Documentation/devicetree/bindings/net/cpsw.txt | 1 +
drivers/net/ethernet/ti/cpsw.c | 222 +
drivers/net/ethernet/ti/davinci_cpdma.c| 4 +-
drivers/net/ethernet/ti/davinci_cpdma.h| 2 +-
include/linux/platform_data/cpsw.h | 1 +
5 files changed, 194 insertions(+), 36 deletions(-)
diff --git a/Documentation/devicetree/bindings/net/cpsw.txt
b/Documentation/devicetree/bindings/net/cpsw.txt
index 6ddd028..d46b293 100644
--- a/Documentation/devicetree/bindings/net/cpsw.txt
+++ b/Documentation/devicetree/bindings/net/cpsw.txt
@@ -20,6 +20,7 @@ Required properties:
- cpts_clock_shift : Denominator to convert input clock ticks into
nanoseconds
- phy_id : Specifies slave phy id
- mac-address : Specifies slave MAC address
+- disable-napi : Disables driver NAPI
Optional properties:
- ti,hwmods: Must be cpgmac0
diff --git a/drivers/net/ethernet/ti/cpsw.c b/drivers/net/ethernet/ti/cpsw.c
index 40aff68..b6ca4af 100644
--- a/drivers/net/ethernet/ti/cpsw.c
+++ b/drivers/net/ethernet/ti/cpsw.c
@@ -148,10 +148,37 @@ struct cpsw_wr_regs {
u32 soft_reset;
u32 control;
u32 int_control;
- u32 rx_thresh_en;
- u32 rx_en;
- u32 tx_en;
- u32 misc_en;
+ u32 c0_rx_thresh_en;
+ u32 c0_rx_en;
+ u32 c0_tx_en;
+ u32 c0_misc_en;
+ u32 c1_rx_thresh_en;
+ u32 c1_rx_en;
+ u32 c1_tx_en;
+ u32 c1_misc_en;
+ u32 c2_rx_thresh_en;
+ u32 c2_rx_en;
+ u32 c2_tx_en;
+ u32 c2_misc_en;
+ u32 c0_rx_thresh_stat;
+ u32 c0_rx_stat;
+ u32 c0_tx_stat;
+ u32 c0_misc_stat;
+ u32 c1_rx_thresh_stat;
+ u32 c1_rx_stat;
+ u32 c1_tx_stat;
+ u32 c1_misc_stat;
+ u32 c2_rx_thresh_stat;
+ u32 c2_rx_stat;
+ u32 c2_tx_stat;
+ u32 c2_misc_stat;
+ u32 c0_rx_imax;
+ u32 c0_tx_imax;
+ u32 c1_rx_imax;
+ u32 c1_tx_imax;
+ u32 c2_rx_imax;
+ u32 c2_tx_imax;
+ u32 rgmii_ctl;
};
struct cpsw_ss_regs {
@@ -352,8 +379,8 @@ static void cpsw_ndo_set_rx_mode(struct net_device *ndev)
static void cpsw_intr_enable(struct cpsw_priv *priv)
{
- __raw_writel(0xFF, priv-wr_regs-tx_en);
- __raw_writel(0xFF, priv-wr_regs-rx_en);
+ __raw_writel(0xFF, priv-wr_regs-c0_tx_en);
+ __raw_writel(0xFF, priv-wr_regs-c0_rx_en);
cpdma_ctlr_int_ctrl(priv-dma, true);
return;
@@ -361,8 +388,8 @@ static void cpsw_intr_enable(struct cpsw_priv *priv)
static void cpsw_intr_disable(struct cpsw_priv *priv)
{
- __raw_writel(0, priv-wr_regs-tx_en);
- __raw_writel(0, priv-wr_regs-rx_en);
+ __raw_writel(0, priv-wr_regs-c0_tx_en);
+ __raw_writel(0, priv-wr_regs-c0_rx_en);
cpdma_ctlr_int_ctrl(priv-dma, false);
return;
@@ -399,7 +426,10 @@ void cpsw_rx_handler(void *token, int len, int status)
skb_put(skb, len);
cpts_rx_timestamp(priv-cpts, skb);
skb-protocol = eth_type_trans(skb, ndev);
- netif_receive_skb(skb);
+ if (priv-data.disable_napi)
+ netif_rx(skb);
+ else
+ netif_receive_skb(skb);
priv-stats.rx_bytes += len;
priv-stats.rx_packets++;
skb = NULL;
@@ -431,6 +461,7 @@ static irqreturn_t cpsw_interrupt(int irq, void *dev_id)
cpsw_disable_irq(priv);
napi_schedule(priv-napi);
}
+
return IRQ_HANDLED;
}
@@ -445,23 +476,104 @@ static inline int cpsw_get_slave_port(struct cpsw_priv
*priv, u32 slave_num)
static int cpsw_poll(struct napi_struct *napi, int budget)
{
struct cpsw_priv*priv = napi_to_priv(napi);
- int num_tx, num_rx;
+ int num_tx, num_rx, num_total_tx, num_total_rx;
+ int budget_left;
+
+ budget_left = budget;
- num_tx = cpdma_chan_process(priv-txch, 128);
- num_rx = cpdma_chan_process(priv-rxch, budget);
+ /* read status and throw away */
+ (void)__raw_readl(priv-wr_regs-c0_tx_stat);
+
+ /* handle all transmits */
+ num_total_tx = 0;
+ while (budget_left 0
+ (num_tx = cpdma_chan_process(priv-txch, 128)) 0) {
+ budget_left -= num_tx;
+ num_total_tx += num_tx;
+ }
- if (num_rx || num_tx)
- cpsw_dbg(priv, intr, poll %d rx, %d tx pkts\n
Re: [PATCH] cpsw: Fix interrupt storm among other things
Hi Richard,
Yes, I guess this was more of a drive-by patch dump - but people need this
to get PG2.0 silicon to work on am33xx.
On Jan 28, 2013, at 8:24 PM, Richard Cochran wrote:
On Mon, Jan 28, 2013 at 03:11:08PM +0200, Pantelis Antoniou wrote:
Fix interrupt storm on bone A4 cause by non-by-the-book interrupt handling.
While at it, added a non-NAPI mode (which is easier to debug), plus
some general fixes.
I have a few issues with this patch:
1. This is a networking patch. It should be addressed to netdev, it it
needs to have davem on CC.
2. The description is poor. You need to tell us more about this
storm. How can one trigger it? What is the effect? Does the
system lock up, or is the throughput poor? Tell us exactly what the
problem is. Tell us what is wrong in the interrupt handling, and
how the patch improves the situation.
PG2.0 fixed a number of silicon bugs. The old driver hard locked, since
it didn't follow the TRM described interrupt handling.
3. Don't just say general fixes, but do say exactly what you fixed.
4. Adding non-NAPI code is going backwards. Don't do that (and see the
recent discussion on netdev on just this very topic: Frank Li and
the fec driver).
Speaking of which, I'm probably the original developer of the fec driver.
And no, I don't think having a non-NAPI code path is backwards, especially
when trying to debug hardware problems; the non-NAPI driver is much easier
to understand and follow, especially when there is a convoluted method
you have to follow to have the h/w acknowledge the interrupt.
Not every device can be conveniently be made to shut up so that NAPI processing
can take place at a later time.
The NAPI case is still broken in this driver, which OOPs under load.
diff --git a/drivers/net/ethernet/ti/cpsw.c b/drivers/net/ethernet/ti/cpsw.c
index 40aff68..b6ca4af 100644
--- a/drivers/net/ethernet/ti/cpsw.c
+++ b/drivers/net/ethernet/ti/cpsw.c
@@ -148,10 +148,37 @@ struct cpsw_wr_regs {
u32 soft_reset;
u32 control;
u32 int_control;
-u32 rx_thresh_en;
-u32 rx_en;
-u32 tx_en;
-u32 misc_en;
+u32 c0_rx_thresh_en;
+u32 c0_rx_en;
+u32 c0_tx_en;
+u32 c0_misc_en;
How does renaming these help?
(If you really think that new names are needed, then put the cosmetic
renaming changes into its a separate patch.)
Those are the real register names in the updated TRM.
+u32 c1_rx_thresh_en;
+u32 c1_rx_en;
+u32 c1_tx_en;
+u32 c1_misc_en;
You added a bunch of new fields, but you don't use any of them.
dido.
Thanks,
Richard
Regards
-- Pantelis
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 5/6] OF: Introduce Device Tree resolve support.
Hi David, On Jan 23, 2013, at 6:40 AM, David Gibson wrote: On Tue, Jan 22, 2013 at 01:06:09PM +0200, Pantelis Antoniou wrote: Hi On Jan 22, 2013, at 6:05 AM, David Gibson wrote: On Mon, Jan 21, 2013 at 12:59:15PM +0200, Pantelis Antoniou wrote: Hi David On Jan 21, 2013, at 6:48 AM, David Gibson wrote: On Fri, Jan 04, 2013 at 09:31:09PM +0200, Pantelis Antoniou wrote: Introduce support for dynamic device tree resolution. Using it, it is possible to prepare a device tree that's been loaded on runtime to be modified and inserted at the kernel live tree. Signed-off-by: Pantelis Antoniou pa...@antoniou-consulting.com --- .../devicetree/dynamic-resolution-notes.txt| 25 ++ drivers/of/Kconfig | 9 + drivers/of/Makefile| 1 + drivers/of/resolver.c | 394 + include/linux/of.h | 17 + 5 files changed, 446 insertions(+) create mode 100644 Documentation/devicetree/dynamic-resolution-notes.txt create mode 100644 drivers/of/resolver.c diff --git a/Documentation/devicetree/dynamic-resolution-notes.txt b/Documentation/devicetree/dynamic-resolution-notes.txt new file mode 100644 index 000..0b396c4 --- /dev/null +++ b/Documentation/devicetree/dynamic-resolution-notes.txt @@ -0,0 +1,25 @@ +Device Tree Dynamic Resolver Notes +-- + +This document describes the implementation of the in-kernel +Device Tree resolver, residing in drivers/of/resolver.c and is a +companion document to Documentation/devicetree/dt-object-internal.txt[1] + +How the resolver works +-- + +The resolver is given as an input an arbitrary tree compiled with the +proper dtc option and having a /plugin/ tag. This generates the +appropriate __fixups__ __local_fixups__ nodes as described in [1]. + +In sequence the resolver works by the following steps: + +1. Get the maximum device tree phandle value from the live tree + 1. +2. Adjust all the local phandles of the tree to resolve by that amount. +3. Using the __local__fixups__ node information adjust all local references + by the same amount. +4. For each property in the __fixups__ node locate the node it references + in the live tree. This is the label used to tag the node. +5. Retrieve the phandle of the target of the fixup. +5. For each fixup in the property locate the node:property:offset location + and replace it with the phandle value. Hrm. So, I'm really still not convinced by this approach. First, I think it's unwise to allow overlays to change essentially anything in the base tree, rather than having the base tree define sockets of some sort where things can be attached. One could say that the labels define the sockets. It's not just things to be attached, properties might have to change, or something more complex, as we've found out in practice. Hrm. I know a number of these have come up previously in that big thread, but can you summarise some of these cases here. If things need modification in the base tree that still seems to me like the base tree hasn't properly described the socket arrangement (I realise that allowing such descriptions may require extensions to some of our device tree conventions). It would be pointless to number all the use-cases that Grant put in that long document, but I can summarize the cases that we've seen on the bone. * Addition of child device nodes to the ocp node, creates new platform devices of various kind (audio/video/pwms/timers) - almost any kind of platform device that the SoC supports. Removing the overlay unregisters the devices (but precious few drivers support that cleanly ATM). Since the capes don't support hotplug that's not a big deal. Ok, that's just adding nodes, which is straightforward. * Addition of pinctrl configuration nodes. Ok, do you know where I can look to see how the pinctrl stuff works? There's information about it in Documentation/pinctrl.txt, and there's the source in drivers/pinctrl. * Addition of i2c/spi etc device nodes and modification of the parent's node status property to okay, Ok. I'm assuming this is basically just to enable the bus controller which was previously disabled because it had nothing attached to it? Yes, but the configuration of the device might need to be altered. For example the clock, or adding/removing some properties that affect the driver. creates the bus platform device registers the devices on the bus. Slight complication with i2c client devices which are not platform devices need special handling. And this part is again just adding nodes. * Modification of configuration parameters of a disabled device and subsequent enablement. What sorts of modification are necessary to the parameters? Other than changing status = disabled of course
Re: [PATCH 6/6] OF: Introduce DT overlay support.
On Jan 23, 2013, at 7:12 AM, David Gibson wrote:
On Tue, Jan 22, 2013 at 01:08:04PM +0200, Pantelis Antoniou wrote:
Hi
On Jan 22, 2013, at 5:50 AM, David Gibson wrote:
On Fri, Jan 04, 2013 at 09:31:10PM +0200, Pantelis Antoniou wrote:
Introduce DT overlay support.
Using this functionality it is possible to dynamically overlay a part of
the kernel's tree with another tree that's been dynamically loaded.
It is also possible to remove node and properties.
Signed-off-by: Pantelis Antoniou pa...@antoniou-consulting.com
---
Documentation/devicetree/overlay-notes.txt | 179 +++
drivers/of/Kconfig | 10 +
drivers/of/Makefile| 1 +
drivers/of/overlay.c | 831
+
include/linux/of.h | 107
5 files changed, 1128 insertions(+)
create mode 100644 Documentation/devicetree/overlay-notes.txt
create mode 100644 drivers/of/overlay.c
diff --git a/Documentation/devicetree/overlay-notes.txt
b/Documentation/devicetree/overlay-notes.txt
new file mode 100644
index 000..5289cbb
--- /dev/null
+++ b/Documentation/devicetree/overlay-notes.txt
@@ -0,0 +1,179 @@
+Device Tree Overlay Notes
+-
+
+This document describes the implementation of the in-kernel
+device tree overlay functionality residing in drivers/of/overlay.c and is
a
+companion document to Documentation/devicetree/dt-object-internal.txt[1]
+Documentation/devicetree/dynamic-resolution-notes.txt[2]
+
+How overlays work
+-
+
+A Device Tree's overlay purpose is to modify the kernel's live tree, and
+have the modification affecting the state of the the kernel in a way that
+is reflecting the changes.
Um.. I'm having a great deal of trouble parsing that sentence.
+Since the kernel mainly deals with devices, any new device node that
result
+in an active device should have it created while if the device node is
either
+disabled or removed all together, the affected device should be
deregistered.
+
+Lets take an example where we have a foo board with the following base
tree
+which is taken from [1].
+
+ foo.dts
-
+ /* FOO platform */
+ / {
+ compatible = corp,foo;
+
+ /* shared resources */
+ res: res {
+ };
+
+ /* On chip peripherals */
+ ocp: ocp {
+ /* peripherals that are always instantiated */
+ peripheral1 { ... };
+ }
+ };
+ foo.dts
-
+
+The overlay bar.dts, when loaded (and resolved as described in [2]) should
+
+ bar.dts
-
+/plugin/; /* allow undefined label references and record them */
+/ {
+ /* various properties for loader use; i.e. part id etc. */
+ fragment@0 {
+ target = ocp;
+ __overlay__ {
+ /* bar peripheral */
+ bar {
+ compatible = corp,bar;
+ ... /* various properties and child nodes */
+ }
+ };
+ };
+};
+ bar.dts
-
+
+result in foo+bar.dts
+
+ foo+bar.dts
-
+ /* FOO platform + bar peripheral */
+ / {
+ compatible = corp,foo;
+
+ /* shared resources */
+ res: res {
+ };
+
+ /* On chip peripherals */
+ ocp: ocp {
+ /* peripherals that are always instantiated */
+ peripheral1 { ... };
+
+ /* bar peripheral */
+ bar {
+ compatible = corp,bar;
+ ... /* various properties and child nodes */
+ }
+ }
+ };
+ foo+bar.dts
-
+
+As a result of the the overlay, a new device node (bar) has been created
+so a bar platform device will be registered and if a matching device
driver
+is loaded the device will be created as expected.
Hrm. This all seems rather complicated. Maybe it needs to be, but
I'm not entirely convinced yet.
One other point - both of these patches are assuming that the overlay
is in the live tree format, but it still needs a bunch of extra
mangling. Would it simplify things to just go straight from the
overlay in flat tree form to modifications to the system-wide live
tree.
Sorry, I can't parse this. You mean apply the overlay without converting
to live tree format?
Yes.
The gymnastics required when operating on the flat tree will make grown, tough
as nails
s/w developers cry.
In essence you
Re: [PATCH 5/6] OF: Introduce Device Tree resolve support.
Hi On Jan 22, 2013, at 6:05 AM, David Gibson wrote: On Mon, Jan 21, 2013 at 12:59:15PM +0200, Pantelis Antoniou wrote: Hi David On Jan 21, 2013, at 6:48 AM, David Gibson wrote: On Fri, Jan 04, 2013 at 09:31:09PM +0200, Pantelis Antoniou wrote: Introduce support for dynamic device tree resolution. Using it, it is possible to prepare a device tree that's been loaded on runtime to be modified and inserted at the kernel live tree. Signed-off-by: Pantelis Antoniou pa...@antoniou-consulting.com --- .../devicetree/dynamic-resolution-notes.txt| 25 ++ drivers/of/Kconfig | 9 + drivers/of/Makefile| 1 + drivers/of/resolver.c | 394 + include/linux/of.h | 17 + 5 files changed, 446 insertions(+) create mode 100644 Documentation/devicetree/dynamic-resolution-notes.txt create mode 100644 drivers/of/resolver.c diff --git a/Documentation/devicetree/dynamic-resolution-notes.txt b/Documentation/devicetree/dynamic-resolution-notes.txt new file mode 100644 index 000..0b396c4 --- /dev/null +++ b/Documentation/devicetree/dynamic-resolution-notes.txt @@ -0,0 +1,25 @@ +Device Tree Dynamic Resolver Notes +-- + +This document describes the implementation of the in-kernel +Device Tree resolver, residing in drivers/of/resolver.c and is a +companion document to Documentation/devicetree/dt-object-internal.txt[1] + +How the resolver works +-- + +The resolver is given as an input an arbitrary tree compiled with the +proper dtc option and having a /plugin/ tag. This generates the +appropriate __fixups__ __local_fixups__ nodes as described in [1]. + +In sequence the resolver works by the following steps: + +1. Get the maximum device tree phandle value from the live tree + 1. +2. Adjust all the local phandles of the tree to resolve by that amount. +3. Using the __local__fixups__ node information adjust all local references + by the same amount. +4. For each property in the __fixups__ node locate the node it references + in the live tree. This is the label used to tag the node. +5. Retrieve the phandle of the target of the fixup. +5. For each fixup in the property locate the node:property:offset location + and replace it with the phandle value. Hrm. So, I'm really still not convinced by this approach. First, I think it's unwise to allow overlays to change essentially anything in the base tree, rather than having the base tree define sockets of some sort where things can be attached. One could say that the labels define the sockets. It's not just things to be attached, properties might have to change, or something more complex, as we've found out in practice. Hrm. I know a number of these have come up previously in that big thread, but can you summarise some of these cases here. If things need modification in the base tree that still seems to me like the base tree hasn't properly described the socket arrangement (I realise that allowing such descriptions may require extensions to some of our device tree conventions). It would be pointless to number all the use-cases that Grant put in that long document, but I can summarize the cases that we've seen on the bone. * Addition of child device nodes to the ocp node, creates new platform devices of various kind (audio/video/pwms/timers) - almost any kind of platform device that the SoC supports. Removing the overlay unregisters the devices (but precious few drivers support that cleanly ATM). Since the capes don't support hotplug that's not a big deal. * Addition of pinctrl configuration nodes. * Addition of i2c/spi etc device nodes and modification of the parent's node status property to okay, creates the bus platform device registers the devices on the bus. Slight complication with i2c client devices which are not platform devices need special handling. * Modification of configuration parameters of a disabled device and subsequent enablement. As far as the unwise part, a good deal of care has been taken so that people that don't use the overlay functionality have absolutely no overhead, or anything modified in the way they use DT. Yeah, that's not what I'm concerned about. I'm concerned about hard to debug problems because some subtle change in the base tree or the overlay or both causes the overlay to alter something in the base tree it really shouldn't. Define shouldn't. Let's say someone inserts a bogus overlay that makes the system fail, or misbehave in some other manner. What is the different between using the overlay and inserting kernel module that fails in a similar manner? As far as supporting arbitrary overlays, that is not the case, and never will be. Now since the beaglebone is for hobbyists too, we can't restrict what a user can do in any way
Re: [PATCH 6/6] OF: Introduce DT overlay support.
Hi
On Jan 22, 2013, at 5:50 AM, David Gibson wrote:
On Fri, Jan 04, 2013 at 09:31:10PM +0200, Pantelis Antoniou wrote:
Introduce DT overlay support.
Using this functionality it is possible to dynamically overlay a part of
the kernel's tree with another tree that's been dynamically loaded.
It is also possible to remove node and properties.
Signed-off-by: Pantelis Antoniou pa...@antoniou-consulting.com
---
Documentation/devicetree/overlay-notes.txt | 179 +++
drivers/of/Kconfig | 10 +
drivers/of/Makefile| 1 +
drivers/of/overlay.c | 831
+
include/linux/of.h | 107
5 files changed, 1128 insertions(+)
create mode 100644 Documentation/devicetree/overlay-notes.txt
create mode 100644 drivers/of/overlay.c
diff --git a/Documentation/devicetree/overlay-notes.txt
b/Documentation/devicetree/overlay-notes.txt
new file mode 100644
index 000..5289cbb
--- /dev/null
+++ b/Documentation/devicetree/overlay-notes.txt
@@ -0,0 +1,179 @@
+Device Tree Overlay Notes
+-
+
+This document describes the implementation of the in-kernel
+device tree overlay functionality residing in drivers/of/overlay.c and is a
+companion document to Documentation/devicetree/dt-object-internal.txt[1]
+Documentation/devicetree/dynamic-resolution-notes.txt[2]
+
+How overlays work
+-
+
+A Device Tree's overlay purpose is to modify the kernel's live tree, and
+have the modification affecting the state of the the kernel in a way that
+is reflecting the changes.
Um.. I'm having a great deal of trouble parsing that sentence.
+Since the kernel mainly deals with devices, any new device node that result
+in an active device should have it created while if the device node is
either
+disabled or removed all together, the affected device should be
deregistered.
+
+Lets take an example where we have a foo board with the following base tree
+which is taken from [1].
+
+ foo.dts
-
+/* FOO platform */
+/ {
+compatible = corp,foo;
+
+/* shared resources */
+res: res {
+};
+
+/* On chip peripherals */
+ocp: ocp {
+/* peripherals that are always instantiated */
+peripheral1 { ... };
+}
+};
+ foo.dts
-
+
+The overlay bar.dts, when loaded (and resolved as described in [2]) should
+
+ bar.dts
-
+/plugin/; /* allow undefined label references and record them */
+/ {
+/* various properties for loader use; i.e. part id etc. */
+fragment@0 {
+target = ocp;
+__overlay__ {
+/* bar peripheral */
+bar {
+compatible = corp,bar;
+... /* various properties and child nodes */
+}
+};
+};
+};
+ bar.dts
-
+
+result in foo+bar.dts
+
+ foo+bar.dts
-
+/* FOO platform + bar peripheral */
+/ {
+compatible = corp,foo;
+
+/* shared resources */
+res: res {
+};
+
+/* On chip peripherals */
+ocp: ocp {
+/* peripherals that are always instantiated */
+peripheral1 { ... };
+
+/* bar peripheral */
+bar {
+compatible = corp,bar;
+... /* various properties and child nodes */
+}
+}
+};
+ foo+bar.dts
-
+
+As a result of the the overlay, a new device node (bar) has been created
+so a bar platform device will be registered and if a matching device driver
+is loaded the device will be created as expected.
Hrm. This all seems rather complicated. Maybe it needs to be, but
I'm not entirely convinced yet.
One other point - both of these patches are assuming that the overlay
is in the live tree format, but it still needs a bunch of extra
mangling. Would it simplify things to just go straight from the
overlay in flat tree form to modifications to the system-wide live
tree.
Sorry, I can't parse this. You mean apply the overlay without converting
to live tree format?
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au| minimalist, thank you. NOT _the_
_other_
Re: [PATCH 5/6] OF: Introduce Device Tree resolve support.
Hi David
On Jan 21, 2013, at 6:48 AM, David Gibson wrote:
On Fri, Jan 04, 2013 at 09:31:09PM +0200, Pantelis Antoniou wrote:
Introduce support for dynamic device tree resolution.
Using it, it is possible to prepare a device tree that's
been loaded on runtime to be modified and inserted at the kernel
live tree.
Signed-off-by: Pantelis Antoniou pa...@antoniou-consulting.com
---
.../devicetree/dynamic-resolution-notes.txt| 25 ++
drivers/of/Kconfig | 9 +
drivers/of/Makefile| 1 +
drivers/of/resolver.c | 394
+
include/linux/of.h | 17 +
5 files changed, 446 insertions(+)
create mode 100644 Documentation/devicetree/dynamic-resolution-notes.txt
create mode 100644 drivers/of/resolver.c
diff --git a/Documentation/devicetree/dynamic-resolution-notes.txt
b/Documentation/devicetree/dynamic-resolution-notes.txt
new file mode 100644
index 000..0b396c4
--- /dev/null
+++ b/Documentation/devicetree/dynamic-resolution-notes.txt
@@ -0,0 +1,25 @@
+Device Tree Dynamic Resolver Notes
+--
+
+This document describes the implementation of the in-kernel
+Device Tree resolver, residing in drivers/of/resolver.c and is a
+companion document to Documentation/devicetree/dt-object-internal.txt[1]
+
+How the resolver works
+--
+
+The resolver is given as an input an arbitrary tree compiled with the
+proper dtc option and having a /plugin/ tag. This generates the
+appropriate __fixups__ __local_fixups__ nodes as described in [1].
+
+In sequence the resolver works by the following steps:
+
+1. Get the maximum device tree phandle value from the live tree + 1.
+2. Adjust all the local phandles of the tree to resolve by that amount.
+3. Using the __local__fixups__ node information adjust all local references
+ by the same amount.
+4. For each property in the __fixups__ node locate the node it references
+ in the live tree. This is the label used to tag the node.
+5. Retrieve the phandle of the target of the fixup.
+5. For each fixup in the property locate the node:property:offset location
+ and replace it with the phandle value.
Hrm. So, I'm really still not convinced by this approach.
First, I think it's unwise to allow overlays to change
essentially anything in the base tree, rather than having the base
tree define sockets of some sort where things can be attached.
One could say that the labels define the sockets. It's not just things
to be attached, properties might have to change, or something more complex,
as we've found out in practice.
As far as the unwise part, a good deal of care has been taken so that
people that don't use the overlay functionality have absolutely no
overhead, or anything modified in the way they use DT.
Second, even allowing overlays to change anything, I don't see
a lot of reason to do this kind of resolution within the kernel and
with data stored in the dtb itself, rather than doing the resolution
in userspace from an annotated overlay dts or dtb, then inserting the
fully resolved product into the kernel. In either case, the overlay
needs to be constructed with pretty intimate knowledge of the base
tree.
Fair enough, but that's one more thing of user-space crud to drag along, which
will get enabled pretty late in the boot sequence. Meaning a whole bunch of
devices,
like consoles, and root filesystems on the devices that need an overlay to
operate
won't work easily enough.
That said, I have some implementation comments below.
[snip]
+/**
+ * Find a subtree's maximum phandle value.
+ */
+static phandle __of_get_tree_max_phandle(struct device_node *node,
+phandle max_phandle)
+{
+struct device_node *child;
+
+if (node-phandle != 0 node-phandle != OF_PHANDLE_ILLEGAL
+node-phandle max_phandle)
+max_phandle = node-phandle;
+
+__for_each_child_of_node(node, child)
+max_phandle = __of_get_tree_max_phandle(child, max_phandle);
Recursion is best avoided given the kernel's limited stack space.
This is also trivial to implement non-recursively, using the allnext
pointer.
The caller passes a tree that's not yet been inserted in the live tree.
So there's no allnodes pointer yet. Care has been taken for the function
to not have excessive local variables. I would guess about 20-32 bytes for
the stack frame + the local variables, so with a 4K stack we would overflow at
a
nest level of 128, which has a pretty slim chance for a real system.
+
+return max_phandle;
+}
+
+/**
+ * Find live tree's maximum phandle value.
+ */
+static phandle of_get_tree_max_phandle(void)
+{
+struct device_node *node;
+phandle phandle;
+
+/* get root node */
+node = of_find_node_by_path(/);
+if (node
Re: [PATCH RESEND] ARM: dts: AM33XX: Rename I2C and GPIO nodes
Hi Benoit, On Jan 8, 2013, at 6:13 PM, Benoit Cousson wrote: Hi Anil, On 01/02/2013 11:12 AM, AnilKumar, Chimata wrote: On Wed, Nov 21, 2012 at 17:22:17, AnilKumar, Chimata wrote: Rename I2C and GPIO nodes according to AM33XX TRM. According to AM33XX TRM device instances are starting from 0 like i2c0, i2c1 and i2c3. Signed-off-by: Pantelis Antoniou pa...@antoniou-consulting.com [pa...@antoniou-consulting.com: initial patch by pantelis's] Signed-off-by: AnilKumar Ch anilku...@ti.com --- Changes from first version: - Updated pantelis's patch * Modified based on linux-omap/master * Added GPIO nodes renaming as well Hi Tony/Benoit, If there are no comments could you please pull this patch? Yep, it is done. The patch is available here: git://git.kernel.org/pub/scm/linux/kernel/git/bcousson/linux-omap-dt.git for_3.9/dts Regards, Benoit Note that when this lands in mainline, the DT patch bindings for DT overlays must be converted to the correct form. Regards -- Pantelis -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/5] capemgr: Beaglebone DT overlay based cape manager
Hi Arnd, On Jan 7, 2013, at 11:35 PM, Arnd Bergmann wrote: (Adding Sascha Hauer, Linus Walleij, Lee Jones to Cc) On Monday 07 January 2013, Tony Lindgren wrote: At the end of the line, some kind of hardware glue is going to be needed. I just feel that drawing from a sample size of 1 (maybe 2 if I get to throw in the beagleboard), it is a bit premature to think about making it overly general, besides the part that are obviously part of the infrastructure (like the DT overlay stuff). What I'm getting at, is that we need some user experience about this, before going away and creating structure out of possible misconception about the uses. IMHO stuff like this will be needed by many SoCs. Some examples of similar things for omaps that have eventually become generic frameworks have been the clock framework, USB OTG support, runtime PM, pinmux framework and so on. So I suggest a minimal generic API from the start as that will make things a lot easier in the long run. I agree. The ux500 platform already has the concept of user interface boards, which currently is not well integrated into devicetree. I believe Sascha mentioned that Pengutronix had been shipping some other systems with add-on boards and generating device tree binaries from source for each combination. Ideally, both of the above should be able to use the same DT overlay logic as BeagleBone, and I'm sure there are more of those. Arnd Hmm, I see. I will need some more information about the interface of the 'user interface boards'. I.e. how is the board identified, what is typically present on those boards, etc. Can we get some input by the owner of other similar hardware? I know the FPGA people have similar requirements for example. There are other people that are hitting problems getting DT to work with their systems, like the V4L people with the order of initialization; see http://lwn.net/Articles/531068/. I think the V4L problem is cleanly solved by the overlay being contained in the V4L device node and applied just before the device is probed. In the meantime it would be better to wait until we have some ack from the maintainers of the core subsystems about what they think. Regards -- Pantelis -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/5] capemgr: Beaglebone DT overlay based cape manager
Hi Guennadi,
On Jan 8, 2013, at 11:51 AM, Guennadi Liakhovetski wrote:
(adding linux-media ML to cc)
Hi Pantelis
On Tue, 8 Jan 2013, Pantelis Antoniou wrote:
Hi Arnd,
On Jan 7, 2013, at 11:35 PM, Arnd Bergmann wrote:
(Adding Sascha Hauer, Linus Walleij, Lee Jones to Cc)
On Monday 07 January 2013, Tony Lindgren wrote:
At the end of the line, some kind of hardware glue is going to be needed.
I just feel that drawing from a sample size of 1 (maybe 2 if I get to
throw
in the beagleboard), it is a bit premature to think about making it overly
general, besides the part that are obviously part of the infrastructure
(like the DT overlay stuff).
What I'm getting at, is that we need some user experience about this,
before
going away and creating structure out of possible misconception about the
uses.
IMHO stuff like this will be needed by many SoCs. Some examples of similar
things for omaps that have eventually become generic frameworks have been
the clock framework, USB OTG support, runtime PM, pinmux framework and
so on.
So I suggest a minimal generic API from the start as that will make things
a lot easier in the long run.
I agree. The ux500 platform already has the concept of user interface
boards,
which currently is not well integrated into devicetree. I believe Sascha
mentioned that Pengutronix had been shipping some other systems with add-on
boards and generating device tree binaries from source for each combination.
Ideally, both of the above should be able to use the same DT overlay logic
as BeagleBone, and I'm sure there are more of those.
Arnd
Hmm, I see.
I will need some more information about the interface of the 'user interface
boards'.
I.e. how is the board identified, what is typically present on those boards,
etc.
Can we get some input by the owner of other similar hardware? I know the FPGA
people have similar requirements for example. There are other people that
are hitting
problems getting DT to work with their systems, like the V4L people with the
order
of initialization; see http://lwn.net/Articles/531068/. I think the V4L
problem is
cleanly solved by the overlay being contained in the V4L device node and
applied just before
the device is probed.
You probably mean these related V4L patches:
http://thread.gmane.org/gmane.linux.drivers.video-input-infrastructure/58646
that base upon of asynchronous V4L2 subdevice probing, referenced above.
Yes, V4L DT nodes, as documented in
http://thread.gmane.org/gmane.linux.drivers.video-input-infrastructure/58646/focus=58648
contain port and endpoint nodes, that describe the configuration of
the hardware port and link to devices, connected to it. Not sure how well
this would work with DT overlays, because endpoint nodes on both sides of
the video data bus contain references to the other side and I don't know
whether and how these can be created and / or updated at run-time.
Otherwise, yes, the approach that we're currently developing on V4L allows
us to build video data pipelines independent of (sub)device driver probing
order.
I'm not very well versed at the V4L intricacies, and correct me if I got it
wrong,
but it seems like you have the problem on needing to probe a bunch of devices
only after
the parent device has been probed successfully.
Your async subdevice probing method seems to be doing this.
It might be simpler to do something like this:
v4ldevice {
compatible = foo,v4ldev;
...
overlay {
fragment@0 {
target = i2c0;
__overlay__ {
...
/* i2c devices */
};
};
fragment@0 {
target = ocp;
__overlay__ {
..
/* platform devices */
};
};
...
}:
};
And in the probe of the v4ldev apply the overlay. The i2c devices will end up
in the
i2c node, the platform devices to the ocp node, etc, and will be registered.
There is nothing preventing the overlay being in a part of the board dts file.
You will need to do a resolve pass for the phandles, but it's not
insurmountable IMO.
Regards
-- Pantelis
Thanks
Guennadi
In the meantime it would be better to wait until we have some ack from the
maintainers
of the core subsystems about what they think.
Regards
-- Pantelis
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/5] capemgr: Beaglebone DT overlay based cape manager
Hi Lee, On Jan 8, 2013, at 12:00 PM, Lee Jones wrote: At the end of the line, some kind of hardware glue is going to be needed. I just feel that drawing from a sample size of 1 (maybe 2 if I get to throw in the beagleboard), it is a bit premature to think about making it overly general, besides the part that are obviously part of the infrastructure (like the DT overlay stuff). What I'm getting at, is that we need some user experience about this, before going away and creating structure out of possible misconception about the uses. IMHO stuff like this will be needed by many SoCs. Some examples of similar things for omaps that have eventually become generic frameworks have been the clock framework, USB OTG support, runtime PM, pinmux framework and so on. So I suggest a minimal generic API from the start as that will make things a lot easier in the long run. I agree. The ux500 platform already has the concept of user interface boards, which currently is not well integrated into devicetree. I believe Sascha mentioned that Pengutronix had been shipping some other systems with add-on boards and generating device tree binaries from source for each combination. Ideally, both of the above should be able to use the same DT overlay logic as BeagleBone, and I'm sure there are more of those. Hmm, I see. I will need some more information about the interface of the 'user interface boards'. I.e. how is the board identified, what is typically present on those boards, etc. User Interface Boards are mearly removable PCBs which are interchangeable amongst various hardware platforms. They are connected via numerous connectors which carry all sorts of different data links; i2c, spi, rs232, etc. The UIB I'm looking at right now has a touchscreen, speakers, a key pad, leds, jumpers, switches and a bunch of sensors. You can find a small example of how we interface to these by viewing 'arch/arm/boot/dts/stuib.dtsi'. To add a UIB to a particular build, we currently include it as a *.dtsi from a platform's dts file. I see. What I'm asking about is whether there's a method where you can read an EEPROM, or some GPIO code combination where I can find out what kind of board is plugged each time. If there is not, there is no way to automatically load the overlays; you can always use the kernel command line, or have the a user space application to request the loading of a specific board's overlay. Regards -- Pantelis Can we get some input by the owner of other similar hardware? I know the FPGA people have similar requirements for example. There are other people that are hitting problems getting DT to work with their systems, like the V4L people with the order of initialization; see http://lwn.net/Articles/531068/. I think the V4L problem is cleanly solved by the overlay being contained in the V4L device node and applied just before the device is probed. In the meantime it would be better to wait until we have some ack from the maintainers of the core subsystems about what they think. Regards -- Pantelis -- Lee Jones Linaro ST-Ericsson Landing Team Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/5] capemgr: Beaglebone DT overlay based cape manager
Hi Arnd, On Jan 8, 2013, at 2:12 PM, Arnd Bergmann wrote: On Tuesday 08 January 2013, Lee Jones wrote: If there is not, there is no way to automatically load the overlays; you can always use the kernel command line, or have the a user space application to request the loading of a specific board's overlay. Unfortunately, there is no way to probe the UIBs. :( I thought that some of the newer UIBs had it, just not the old ones. As Pantelis says, we could at least detect the ones that have an EEPROM on them, and use a command line option or device tree attribute for the others. Arnd So I gather the new ones have an eeprom? Regards -- Pantelis -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] omap: DT node Timer iteration fix
The iterator correctly handles of_node_put() calls.
Remove it before continue'ing the loop.
Without this patch you get:
ERROR: Bad of_node_put() on /ocp/timer@44e31000!
[c001329c] (unwind_backtrace+0x0/0xe0) from [c03dd8f0]
(of_node_release+0x2c/0xa0)!
[c03dd8f0] (of_node_release+0x2c/0xa0) from [c03ddea0]
(of_find_matching_node_and_match+0x78/0x90)!
[c03ddea0] (of_find_matching_node_and_match+0x78/0x90) from [c06d349c]
(omap_get_timer_dt+0x78/0x90)!
[c06d349c] (omap_get_timer_dt+0x78/0x90) from [c06d3664]
(omap_dm_timer_init_one.clone.2+0x34/0x2bc)!
[c06d3664] (omap_dm_timer_init_one.clone.2+0x34/0x2bc) from [c06d3a2c]
(omap2_gptimer_clocksource_init.clone.4+0x24/0xa8)!
[c06d3a2c] (omap2_gptimer_clocksource_init.clone.4+0x24/0xa8) from
[c06cca58] (time_init+0x20/0x30)!
[c06cca58] (time_init+0x20/0x30) from [c06c9690] (start_kernel+0x1a8/0x2fc)!
Signed-off-by: Pantelis Antoniou pa...@antoniou-consulting.com
---
arch/arm/mach-omap2/timer.c | 8 ++--
1 file changed, 2 insertions(+), 6 deletions(-)
diff --git a/arch/arm/mach-omap2/timer.c b/arch/arm/mach-omap2/timer.c
index 691aa67..b8ad6e6 100644
--- a/arch/arm/mach-omap2/timer.c
+++ b/arch/arm/mach-omap2/timer.c
@@ -165,15 +165,11 @@ static struct device_node * __init
omap_get_timer_dt(struct of_device_id *match,
struct device_node *np;
for_each_matching_node(np, match) {
- if (!of_device_is_available(np)) {
- of_node_put(np);
+ if (!of_device_is_available(np))
continue;
- }
- if (property !of_get_property(np, property, NULL)) {
- of_node_put(np);
+ if (property !of_get_property(np, property, NULL))
continue;
- }
of_add_property(np, device_disabled);
return np;
--
1.7.12
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] omap: Avoid crashes in the case of hwmod misconfiguration
omap hwmod is really sensitive to hwmod misconfiguration.
Getting a minor clock wrong always ended up in a crash.
Attempt to be more resilient by not assigning variables with
error codes and then attempting to use them.
Without this patch, missing a clock ends up with something like this:
omap_hwmod: ehrpwm0: cannot clk_get opt_clk ehrpwm0_tbclk!
Unable to handle kernel NULL pointer dereference at virtual address 002a!
pgd = c0004000!
[002a] *pgd=!
Internal error: Oops: 5 [#1] SMP ARM!
Modules linked in:!
CPU: 0Not tainted (3.8.0-rc2-12157-g76c7825-dirty #291)!
PC is at __clk_prepare+0x10/0x70!
LR is at clk_prepare+0x1c/0x34!
pc : [c03e37f0]lr : [c03e386c]psr: a113!
sp : cf04fef8 ip : fp : !
r10: ffea r9 : r8 : !
r7 : fffe r6 : 0001 r5 : fffe r4 : fffe!
r3 : cf041ac0 r2 : cf04ff00 r1 : r0 : fffe!
Flags: NzCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment kernel!
Control: 10c5387d Table: 80004019 DAC: 0015!
Process swapper/0 (pid: 1, stack limit = 0xcf04e240)!
Stack: (0xcf04fef8 to 0xcf05)!
fee0: cf041ac0 c07749f4!
ff00: fffe c03e386c c07499cc c073c070 c073d2fc c06d4e4c c073c070 c071cc18!
ff20: c06d4c4c c0708284 c06c91bc c0025e28 c073a030 0001!
ff40: c06f5f60 c06f5f40 c06d5324 c06d533c cf04e000 c0008870 c06d5324 c060abe8!
ff60: c07082e8 0002 0001 c06f5f60 c06f5f40 c077d700 0099 c04a43d4!
ff80: 0001 0001 c06c91bc c04a42dc !
ffa0: c000d678 !
ffc0: !
ffe0: 0013 9e7befee f7bbaaab!
[c03e37f0] (__clk_prepare+0x10/0x70) from [c03e386c]
(clk_prepare+0x1c/0x34)!
[c03e386c] (clk_prepare+0x1c/0x34) from [c06d4e4c] (_init+0x200/0x288)!
[c06d4e4c] (_init+0x200/0x288) from [c0025e28]
(omap_hwmod_for_each+0x28/0x58)!
[c0025e28] (omap_hwmod_for_each+0x28/0x58) from [c06d533c]
(omap_hwmod_setup_all+0x18/0x34)!
[c06d533c] (omap_hwmod_setup_all+0x18/0x34) from [c0008870]
(do_one_initcall+0x90/0x160)!
[c0008870] (do_one_initcall+0x90/0x160) from [c04a43d4]
(kernel_init+0xf8/0x290)!
[c04a43d4] (kernel_init+0xf8/0x290) from [c000d678]
(ret_from_fork+0x14/0x3c)!
Code: e92d4038 e2504000 01a05004 0a15 (e594302c) !
---[ end trace 1b75b31a2719ed1c ]---!
Kernel panic - not syncing: Attempted to kill init! exitcode=0x000b!
Signed-off-by: Pantelis Antoniou pa...@antoniou-consulting.com
---
arch/arm/mach-omap2/omap_hwmod.c | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod.c b/arch/arm/mach-omap2/omap_hwmod.c
index 4653efb..2b58e21 100644
--- a/arch/arm/mach-omap2/omap_hwmod.c
+++ b/arch/arm/mach-omap2/omap_hwmod.c
@@ -783,7 +783,9 @@ static int _init_interface_clks(struct omap_hwmod *oh)
if (IS_ERR(c)) {
pr_warning(omap_hwmod: %s: cannot clk_get
interface_clk %s\n,
oh-name, os-clk);
- ret = -EINVAL;
+ if (ret == 0)
+ ret = -EINVAL;
+ continue;
}
os-_clk = c;
/*
@@ -819,7 +821,9 @@ static int _init_opt_clks(struct omap_hwmod *oh)
if (IS_ERR(c)) {
pr_warning(omap_hwmod: %s: cannot clk_get opt_clk
%s\n,
oh-name, oc-clk);
- ret = -EINVAL;
+ if (ret == 0)
+ ret = -EINVAL;
+ continue;
}
oc-_clk = c;
/*
--
1.7.12
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 6/6] OF: Introduce DT overlay support.
Hi Rob,
On Jan 6, 2013, at 4:24 AM, Rob Landley wrote:
On 01/04/2013 01:31:10 PM, Pantelis Antoniou wrote:
Introduce DT overlay support.
Using this functionality it is possible to dynamically overlay a part of
the kernel's tree with another tree that's been dynamically loaded.
It is also possible to remove node and properties.
Signed-off-by: Pantelis Antoniou pa...@antoniou-consulting.com
Just commenting on the documentation a bit...
---
Documentation/devicetree/overlay-notes.txt | 179 +++
drivers/of/Kconfig | 10 +
drivers/of/Makefile| 1 +
drivers/of/overlay.c | 831
+
include/linux/of.h | 107
5 files changed, 1128 insertions(+)
create mode 100644 Documentation/devicetree/overlay-notes.txt
create mode 100644 drivers/of/overlay.c
diff --git a/Documentation/devicetree/overlay-notes.txt
b/Documentation/devicetree/overlay-notes.txt
new file mode 100644
index 000..5289cbb
--- /dev/null
+++ b/Documentation/devicetree/overlay-notes.txt
@@ -0,0 +1,179 @@
+Device Tree Overlay Notes
+-
+
+This document describes the implementation of the in-kernel
+device tree overlay functionality residing in drivers/of/overlay.c and is a
+companion document to Documentation/devicetree/dt-object-internal.txt[1]
+Documentation/devicetree/dynamic-resolution-notes.txt[2]
+
+How overlays work
+-
+
+A Device Tree's overlay purpose is to modify the kernel's live tree, and
+have the modification affecting the state of the the kernel in a way that
+is reflecting the changes.
My wild guess here is this has something to do with hotplug support, but I
don't know if modules are expected to do this or if userspace does it and
modules respond... Could you give a couple sentences about the purpose and
potential users of this mechanism in the summary?
In a nutshell, the idea is that you have an unspecified method of detecting
some kind of hardware
interface(s) and you want to insert to the live tree the fragment that will
enable your hardware
to function.
Which method to use is up to what comes naturally for each case.
+Since the kernel mainly deals with devices, any new device node that result
results
OK
+in an active device should have it created while if the device node is
either
+disabled or removed all together, the affected device should be
deregistered.
I'm not following this bit. It looks like some test is missing between while
if?
I'll reword it to make it clearer.
+Lets take an example where we have a foo board with the following base tree
+which is taken from [1].
+
+ foo.dts
-
+/* FOO platform */
+/ {
+compatible = corp,foo;
+
+/* shared resources */
+res: res {
+};
+
+/* On chip peripherals */
+ocp: ocp {
+/* peripherals that are always instantiated */
+peripheral1 { ... };
+}
+};
+ foo.dts
-
+
+The overlay bar.dts, when loaded (and resolved as described in [2]) should
+
+ bar.dts
-
+/plugin/; /* allow undefined label references and record them */
+/ {
+/* various properties for loader use; i.e. part id etc. */
+fragment@0 {
+target = ocp;
+__overlay__ {
+/* bar peripheral */
+bar {
+compatible = corp,bar;
+... /* various properties and child nodes */
+}
+};
+};
+};
+ bar.dts
-
+
+result in foo+bar.dts
+
+ foo+bar.dts
-
+/* FOO platform + bar peripheral */
+/ {
+compatible = corp,foo;
+
+/* shared resources */
+res: res {
+};
+
+/* On chip peripherals */
+ocp: ocp {
+/* peripherals that are always instantiated */
+peripheral1 { ... };
+
+/* bar peripheral */
+bar {
+compatible = corp,bar;
+... /* various properties and child nodes */
+}
+}
+};
+ foo+bar.dts
-
+
+As a result of the the overlay, a new device node (bar) has been created
+so a bar platform device will be registered and if a matching device driver
+is loaded the device will be created
[PATCH 0/5] DT Overlay based cape manager for TI's Beaglebone
Introducing a Device Tree overlay cape manager. Using it it is possible to support the growing cape ecosystem for the beaglebone, without having to hack a board file for each and every cape plug combination. It is possible to force load capes, and also possible to remove them if need be (although precious few drivers support removal). This patch is against the mainline kernel as of Jan 7 2013, top of the tree: 5f243b9 Merge tag 'arm64-fixes' of \ git://git.kernel.org/pub/scm/linux/kernel/git/cmarinas/linux-aarch640 You will need to have the DTC compiler patch which was posted seperately to the DTC mailing list dtc: Dynamic symbols fixup support, as well as the I2C accessor patch i2c-EEPROM: In kernel memory accessor interface I posted earlier. Note that not many interesting capes are supported in the mainline kernel, since the drivers some time to land in mainline, but you can see an example of a (almost) feature complete linux kernel at: git://github.com/pantoniou/linux-bbxm.git branch not-capebus-v9 Pantelis Antoniou (5): capemgr: Beaglebone DT overlay based cape manager capemgr: Add beaglebone's cape driver bindings capemgr: am335x-bone capemgr bindings capemgr: firmware makefiles for DT objects capemgr: Weather cape cape definition .../devicetree/bindings/misc/capes-beaglebone.txt | 110 ++ arch/arm/boot/dts/am335x-bone.dts | 75 +- arch/arm/mach-omap2/Kconfig|2 + drivers/misc/Kconfig |2 + drivers/misc/Makefile |1 + drivers/misc/cape/Kconfig |5 + drivers/misc/cape/Makefile |5 + drivers/misc/cape/beaglebone/Kconfig | 11 + drivers/misc/cape/beaglebone/Makefile |5 + drivers/misc/cape/beaglebone/capemgr.c | 1835 firmware/Makefile | 12 + firmware/capes/cape-bone-weather-00A0.dts | 66 + 12 files changed, 2128 insertions(+), 1 deletion(-) create mode 100644 Documentation/devicetree/bindings/misc/capes-beaglebone.txt create mode 100644 drivers/misc/cape/Kconfig create mode 100644 drivers/misc/cape/Makefile create mode 100644 drivers/misc/cape/beaglebone/Kconfig create mode 100644 drivers/misc/cape/beaglebone/Makefile create mode 100644 drivers/misc/cape/beaglebone/capemgr.c create mode 100644 firmware/capes/cape-bone-weather-00A0.dts -- 1.7.12 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/5] capemgr: am335x-bone capemgr bindings
Bindings which enable the DT overlay based cape manager for
the Texas Instruments Beaglebone platform.
Signed-off-by: Pantelis Antoniou pa...@antoniou-consulting.com
---
arch/arm/boot/dts/am335x-bone.dts | 68 ++-
1 file changed, 67 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/am335x-bone.dts
b/arch/arm/boot/dts/am335x-bone.dts
index 11b240c..5faeece 100644
--- a/arch/arm/boot/dts/am335x-bone.dts
+++ b/arch/arm/boot/dts/am335x-bone.dts
@@ -38,7 +38,7 @@
};
};
- ocp {
+ ocp: ocp {
uart1: serial@44e09000 {
status = okay;
};
@@ -51,6 +51,35 @@
reg = 0x24;
};
+ baseboard_eeprom: baseboard_eeprom@50 {
+ compatible = at,24c256;
+ reg = 0x50;
+ };
+ };
+
+ i2c3: i2c@4819c000 {
+ status = okay;
+ clock-frequency = 10;
+
+ cape_eeprom0: cape_eeprom0@54 {
+ compatible = at,24c256;
+ reg = 0x54;
+ };
+
+ cape_eeprom1: cape_eeprom1@55 {
+ compatible = at,24c256;
+ reg = 0x55;
+ };
+
+ cape_eeprom2: cape_eeprom2@56 {
+ compatible = at,24c256;
+ reg = 0x56;
+ };
+
+ cape_eeprom3: cape_eeprom3@57 {
+ compatible = at,24c256;
+ reg = 0x57;
+ };
};
};
@@ -83,6 +112,43 @@
default-state = off;
};
};
+
+ bone_capemgr {
+ compatible = ti,bone-capemgr;
+ status = okay;
+
+ eeprom = baseboard_eeprom;
+
+ baseboardmaps {
+ baseboard_beaglebone: board@0 {
+ board-name = A335BONE;
+ compatible-name = ti,beaglebone;
+ };
+ };
+
+ slots {
+ slot@0 {
+ eeprom = cape_eeprom0;
+ };
+
+ slot@1 {
+ eeprom = cape_eeprom1;
+ };
+
+ slot@2 {
+ eeprom = cape_eeprom2;
+ };
+
+ slot@3 {
+ eeprom = cape_eeprom3;
+ };
+ };
+
+ /* mapping between board names and dtb objects */
+ capemaps {
+
+ };
+ };
};
/include/ tps65217.dtsi
--
1.7.12
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 4/5] capemgr: firmware makefiles for DT objects
Makefile rules to support compiling DT cape definitions. Signed-off-by: Pantelis Antoniou pa...@antoniou-consulting.com --- firmware/Makefile | 7 +++ 1 file changed, 7 insertions(+) diff --git a/firmware/Makefile b/firmware/Makefile index cbb09ce..361b2af 100644 --- a/firmware/Makefile +++ b/firmware/Makefile @@ -147,6 +147,9 @@ quiet_cmd_mkdir = MKDIR $(patsubst $(objtree)/%,%,$@) quiet_cmd_ihex = IHEX$@ cmd_ihex = $(OBJCOPY) -Iihex -Obinary $ $@ +quiet_cmd_dtco = DTCO $@ + cmd_dtco = $(objtree)/scripts/dtc/dtc -O dtb -o $@ -b 0 $(DTC_FLAGS) -@ $ + quiet_cmd_ihex2fw = IHEX2FW $@ cmd_ihex2fw = $(objtree)/$(obj)/ihex2fw $ $@ @@ -233,6 +236,10 @@ $(obj)/%.fw: $(obj)/%.HEX $(ihex2fw_dep) | $(objtree)/$(obj)/$$(dir %) $(obj)/%.fw: $(obj)/%.H16 $(ihex2fw_dep) | $(objtree)/$(obj)/$$(dir %) $(call cmd,h16tofw) +# DTBO is device tree blob object +$(obj)/%.dtbo: $(obj)/%.dts | $(objtree)/$(obj)/$$(dir %) + $(call cmd,dtco) + $(firmware-dirs): $(call cmd,mkdir) -- 1.7.12 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 5/5] capemgr: Weather cape cape definition
Add the weather cape to the supported capes.
Signed-off-by: Pantelis Antoniou pa...@antoniou-consulting.com
---
arch/arm/boot/dts/am335x-bone.dts | 9 -
firmware/Makefile | 5 +++
firmware/capes/cape-bone-weather-00A0.dts | 66 +++
3 files changed, 79 insertions(+), 1 deletion(-)
create mode 100644 firmware/capes/cape-bone-weather-00A0.dts
diff --git a/arch/arm/boot/dts/am335x-bone.dts
b/arch/arm/boot/dts/am335x-bone.dts
index 5faeece..b02f29a 100644
--- a/arch/arm/boot/dts/am335x-bone.dts
+++ b/arch/arm/boot/dts/am335x-bone.dts
@@ -146,7 +146,14 @@
/* mapping between board names and dtb objects */
capemaps {
-
+ /* Weather cape */
+ cape@0 {
+ part-number = BB-BONE-WTHR-01;
+ version@00A0 {
+ version = 00A0;
+ dtbo = cape-bone-weather-00A0.dtbo;
+ };
+ };
};
};
};
diff --git a/firmware/Makefile b/firmware/Makefile
index 361b2af..5ebb757 100644
--- a/firmware/Makefile
+++ b/firmware/Makefile
@@ -136,6 +136,11 @@ fw-shipped-$(CONFIG_USB_VICAM) += vicam/firmware.fw
fw-shipped-$(CONFIG_VIDEO_CPIA2) += cpia2/stv0672_vp4.bin
fw-shipped-$(CONFIG_YAM) += yam/1200.bin yam/9600.bin
+# Capes
+
+# the weather cape
+fw-shipped-$(CONFIG_CAPE_BEAGLEBONE) += capes/cape-bone-weather-00A0.dtbo
+
fw-shipped-all := $(fw-shipped-y) $(fw-shipped-m) $(fw-shipped-)
# Directories which we _might_ need to create, so we have a rule for them.
diff --git a/firmware/capes/cape-bone-weather-00A0.dts
b/firmware/capes/cape-bone-weather-00A0.dts
new file mode 100644
index 000..ad91577
--- /dev/null
+++ b/firmware/capes/cape-bone-weather-00A0.dts
@@ -0,0 +1,66 @@
+/*
+* Copyright (C) 2012 Texas Instruments Incorporated - http://www.ti.com/
+*
+* This program is free software; you can redistribute it and/or modify
+* it under the terms of the GNU General Public License version 2 as
+* published by the Free Software Foundation.
+*/
+/dts-v1/;
+/plugin/;
+
+/ {
+ compatible = ti,beaglebone;
+ part-number = BB-BONE-WTHR-01;
+ version = 00A0;
+
+ fragment@0 {
+ target = am33xx_pinmux;
+ __overlay__ {
+ pinctrl-single,pins =
+ 0x0c 0x37 /* gpmc_ad3.gpio1_3,
OMAP_PIN_INPUT_PULLUP | OMAP_MUX_MODE7 - w1-gpio */
+ ;
+ };
+ };
+
+ fragment@1 {
+ target = i2c3; /* actually I2C2 */
+
+ __overlay__ {
+ /* needed to avoid gripping by DTC */
+ #address-cells = 1;
+ #size-cells = 0;
+
+ /* Ambient light sensor */
+ tsl2550@39 {
+ compatible = tsl,tsl2550;
+ reg = 0x39;
+ };
+
+ /* Humidity Sensor */
+ sht21@40 {
+ compatible = sensiron,sht21;
+ reg = 0x40;
+ };
+
+ /* Barometric pressure sensor */
+ bmp085@77 {
+ compatible = bosch,bmp085;
+ reg = 0x77;
+ };
+ };
+ };
+
+ fragment@2 {
+ target = ocp;
+ __overlay__ {
+ onewire@0 {
+ compatible = w1-gpio;
+ pinctrl-names = default;
+ pinctrl-0 = weather_cape_w1_pins;
+ status = okay;
+
+ gpios = gpio2 3 0;
+ };
+ };
+ };
+};
--
1.7.12
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/5] capemgr: Add beaglebone's cape driver bindings
Document the beaglebone's cape driver bindings.
Signed-off-by: Pantelis Antoniou pa...@antoniou-consulting.com
---
.../devicetree/bindings/misc/capes-beaglebone.txt | 110 +
1 file changed, 110 insertions(+)
create mode 100644 Documentation/devicetree/bindings/misc/capes-beaglebone.txt
diff --git a/Documentation/devicetree/bindings/misc/capes-beaglebone.txt
b/Documentation/devicetree/bindings/misc/capes-beaglebone.txt
new file mode 100644
index 000..f73cab5
--- /dev/null
+++ b/Documentation/devicetree/bindings/misc/capes-beaglebone.txt
@@ -0,0 +1,110 @@
+* TI Beaglebone DT Overlay Cape Driver
+
+Required properties:
+
+- compatible: ti,bone-capemgr
+
+- eeprom: Contains the phandle beaglebone's baseboard i2c eeprom.
+
+- baseboardmaps - node containing a list of supported
+ beaglebone revisions; each node in should have the
+ following properties:
+ - board-name: The board name stored in the baseboard
+ eeprom.
+ - compatible-name: The name which will be used for
+ matching compatible capes.
+
+- slots: node containing a list of slot nodes (which in the beaglebone
+ case correspond to I2C addresses for dynamically probed capes,
+ or an override slot definition for hardcoded capes.
+ - eeprom: Contains the phandle beaglebone's cape i2c eeprom.
+
+ It is possible to define override slots that will be activated
+ when the baseboard matches, and/or if supplied on the kernel command
+ line and/or when dynamically requested on runtime.
+ In that case the slot is marked with
+ - ti,cape-override: Marks a slot override.
+ - compatible: any of the runtime, kernel, or any compatible-name
+ on a matching baseboardmap node.
+ - Any of the eeprom-format-revision, board-name, version, manufacturer,
+ part-number, number-of-pins, serial-number, pin-usage, vdd-3v3exp,
+ vdd-5v, sys-5v, dc-supplied properties which fill in the simulated
+ cape's EEPROM fields. The part-number field is required, the rest
+ are optional taking into default values.
+
+- capemaps: node contains list of cape mappings, which allow converting
+ from a part-number version tuple to the filename of the dtbo file.
+ - part-number: part number contained in the EEPROM
+ - version node containing a
+ - version: specific version to map to
+ - dtbo: name of the dtbo file
+
+Example:
+bone_capemgr {
+ compatible = ti,bone-capemgr;
+ status = okay;
+
+ eeprom = baseboard_eeprom;
+
+ baseboardmaps {
+ baseboard_beaglebone: board@0 {
+ board-name = A335BONE;
+ compatible-name = ti,beaglebone;
+ };
+ };
+
+ slots {
+ slot@0 {
+ eeprom = cape_eeprom0;
+ };
+
+ slot@1 {
+ eeprom = cape_eeprom1;
+ };
+
+ slot@2 {
+ eeprom = cape_eeprom2;
+ };
+
+ slot@3 {
+ eeprom = cape_eeprom3;
+ };
+ };
+
+ /* mapping between board names and dtb objects */
+ capemaps {
+ /* Weather cape */
+ cape@0 {
+ part-number = BB-BONE-WTHR-01;
+ version@00A0 {
+ version = 00A0;
+ dtbo = cape-bone-weather-00A0.dtbo;
+ };
+ };
+ };
+};
+
+Example of the override syntax when used on a bone compatible foo board.
+
+{
+ ...
+
+ baseboardmaps {
+ ...
+ baseboard_beaglebone: board@0 {
+ board-name = A335FOO;
+ compatible-name = ti,foo;
+ };
+
+ slot@6 {
+ ti,cape-override;
+ compatible = ti,foo;
+ board-name = FOO-hardcoded;
+ version = 00A0;
+ manufacturer = Texas Instruments;
+ part-number = BB-BONE-FOO-01;
+ };
+ };
+
+};
+
--
1.7.12
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/5] capemgr: Beaglebone DT overlay based cape manager
A cape loader based on DT overlays and DT objects. Beaglebone cape manager implementation. Signed-off-by: Pantelis Antoniou pa...@antoniou-consulting.com --- arch/arm/mach-omap2/Kconfig|2 + drivers/misc/Kconfig |2 + drivers/misc/Makefile |1 + drivers/misc/cape/Kconfig |5 + drivers/misc/cape/Makefile |5 + drivers/misc/cape/beaglebone/Kconfig | 11 + drivers/misc/cape/beaglebone/Makefile |5 + drivers/misc/cape/beaglebone/capemgr.c | 1835 8 files changed, 1866 insertions(+) create mode 100644 drivers/misc/cape/Kconfig create mode 100644 drivers/misc/cape/Makefile create mode 100644 drivers/misc/cape/beaglebone/Kconfig create mode 100644 drivers/misc/cape/beaglebone/Makefile create mode 100644 drivers/misc/cape/beaglebone/capemgr.c diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig index 41b581f..f0c2eab 100644 --- a/arch/arm/mach-omap2/Kconfig +++ b/arch/arm/mach-omap2/Kconfig @@ -18,6 +18,8 @@ config ARCH_OMAP2PLUS_TYPICAL select TWL4030_CORE if ARCH_OMAP3 || ARCH_OMAP4 select TWL4030_POWER if ARCH_OMAP3 || ARCH_OMAP4 select VFP + select OF_OVERLAY + select OF_RESOLVE help Compile a kernel suitable for booting most boards diff --git a/drivers/misc/Kconfig b/drivers/misc/Kconfig index b151b7c..45558a3 100644 --- a/drivers/misc/Kconfig +++ b/drivers/misc/Kconfig @@ -507,4 +507,6 @@ source drivers/misc/lis3lv02d/Kconfig source drivers/misc/carma/Kconfig source drivers/misc/altera-stapl/Kconfig source drivers/misc/mei/Kconfig +source drivers/misc/cape/Kconfig + endmenu diff --git a/drivers/misc/Makefile b/drivers/misc/Makefile index 2129377..c06d457 100644 --- a/drivers/misc/Makefile +++ b/drivers/misc/Makefile @@ -49,3 +49,4 @@ obj-y += carma/ obj-$(CONFIG_USB_SWITCH_FSA9480) += fsa9480.o obj-$(CONFIG_ALTERA_STAPL) +=altera-stapl/ obj-$(CONFIG_INTEL_MEI)+= mei/ +obj-y += cape/ diff --git a/drivers/misc/cape/Kconfig b/drivers/misc/cape/Kconfig new file mode 100644 index 000..a2ef85e --- /dev/null +++ b/drivers/misc/cape/Kconfig @@ -0,0 +1,5 @@ +# +# Capes +# + +source drivers/misc/cape/beaglebone/Kconfig diff --git a/drivers/misc/cape/Makefile b/drivers/misc/cape/Makefile new file mode 100644 index 000..7c4eb96 --- /dev/null +++ b/drivers/misc/cape/Makefile @@ -0,0 +1,5 @@ +# +# Makefile for cape like devices +# + +obj-y += beaglebone/ diff --git a/drivers/misc/cape/beaglebone/Kconfig b/drivers/misc/cape/beaglebone/Kconfig new file mode 100644 index 000..99a31ec --- /dev/null +++ b/drivers/misc/cape/beaglebone/Kconfig @@ -0,0 +1,11 @@ +# +# Beaglebone capes +# + +config CAPE_BEAGLEBONE + tristate Beaglebone cape support + depends on ARCH_OMAP2PLUS OF I2C + default n + select OF_PLUGIN + help + Say Y here to include support for beaglebone capes diff --git a/drivers/misc/cape/beaglebone/Makefile b/drivers/misc/cape/beaglebone/Makefile new file mode 100644 index 000..5b4549f --- /dev/null +++ b/drivers/misc/cape/beaglebone/Makefile @@ -0,0 +1,5 @@ +# +# Makefile for beaglebone capes +# + +obj-$(CONFIG_CAPE_BEAGLEBONE) += capemgr.o diff --git a/drivers/misc/cape/beaglebone/capemgr.c b/drivers/misc/cape/beaglebone/capemgr.c new file mode 100644 index 000..651f48d --- /dev/null +++ b/drivers/misc/cape/beaglebone/capemgr.c @@ -0,0 +1,1835 @@ +/* + * TI Beaglebone cape controller + * + * Copyright (C) 2012 Pantelis Antoniou pa...@antoniou-consulting.com + * Copyright (C) 2012 Texas Instruments Inc. + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation; either version 2 of the License, or + * (at your option) any later version. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA. + */ + +#include linux/module.h +#include linux/delay.h +#include linux/i2c.h +#include linux/err.h +#include linux/interrupt.h +#include linux/completion.h +#include linux/platform_device.h +#include linux/clk.h +#include linux/io.h +#include linux/of.h +#include linux/of_i2c.h +#include linux/of_device.h +#include linux/of_fdt.h +#include linux/slab.h +#include linux/pm_runtime.h +#include linux/pinctrl/consumer.h +#include linux/firmware.h +#include linux/err.h +#include linux/ctype.h +#include linux/string.h +#include linux
Re: [PATCH] omap: Properly handle resources for omap_devices
Hi,
On Jan 7, 2013, at 10:05 PM, Tony Lindgren wrote:
Hi,
* Pantelis Antoniou pa...@antoniou-consulting.com [130103 14:34]:
omap_device relies on the platform notifier callbacks managing resources
behind the scenes. The resources were not properly linked causing crashes
when removing the device.
Rework the resource modification code so that linking is performed properly,
and make sure that no resources that have no parent (which can happen for DMA
IRQ resources) are ever left for cleanup by the core resource layer.
Sounds like a fix, but it's hard to figure out from the patch which parts
are the fix. Can you please split this patch into two, first move the
code around with no functional changes, and then a second patch to fix
the issue?
Thanks,
Tony
OK Tony, will do.
Regards
-- Pantelis
Signed-off-by: Pantelis Antoniou pa...@antoniou-consulting.com
---
arch/arm/mach-omap2/omap_device.c | 232
--
1 file changed, 148 insertions(+), 84 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_device.c
b/arch/arm/mach-omap2/omap_device.c
index e065daa..9f8dba1 100644
--- a/arch/arm/mach-omap2/omap_device.c
+++ b/arch/arm/mach-omap2/omap_device.c
@@ -494,30 +494,156 @@ static int omap_device_fill_resources(struct
omap_device *od,
}
/**
- * _od_fill_dma_resources - fill in array of struct resource with dma
resources
+ * omap_device_fixup_resources - Fix platform device resources
* @od: struct omap_device *
- * @res: pointer to an array of struct resource to be filled in
- *
- * Populate one or more empty struct resource pointed to by @res with
- * the dma resource data for this omap_device @od. Used by
- * omap_device_alloc() after calling omap_device_count_resources().
- *
- * Ideally this function would not be needed at all. If we have
- * mechanism to get dma resources from DT.
*
- * Returns 0.
+ * Fixup the platform device resources so that the resources
+ * from the hwmods are included for.
*/
-static int _od_fill_dma_resources(struct omap_device *od,
- struct resource *res)
+static int omap_device_fixup_resources(struct omap_device *od)
{
-int i, r;
+struct platform_device *pdev = od-pdev;
+int i, j, ret, res_count;
+struct resource *res, *r, *rnew, *rn;
+unsigned long type;
-for (i = 0; i od-hwmods_cnt; i++) {
-r = omap_hwmod_fill_dma_resources(od-hwmods[i], res);
-res += r;
+/*
+ * DT Boot:
+ * OF framework will construct the resource structure (currently
+ * does for MEM IRQ resource) and we should respect/use these
+ * resources, killing hwmod dependency.
+ * If pdev-num_resources 0, we assume that MEM IRQ resources
+ * have been allocated by OF layer already (through DTB).
+ *
+ * Non-DT Boot:
+ * Here, pdev-num_resources = 0, and we should get all the
+ * resources from hwmod.
+ *
+ * TODO: Once DMA resource is available from OF layer, we should
+ * kill filling any resources from hwmod.
+ */
+
+/* count number of resources hwmod provides */
+res_count = omap_device_count_resources(od, IORESOURCE_IRQ |
+IORESOURCE_DMA | IORESOURCE_MEM);
+
+/* if no resources from hwmod, we're done already */
+if (res_count == 0)
+return 0;
+
+/* Allocate resources memory to account for all hwmod resources */
+res = kzalloc(sizeof(struct resource) * res_count, GFP_KERNEL);
+if (!res) {
+ret = -ENOMEM;
+goto fail_no_res;
}
+/* fill all the resources */
+ret = omap_device_fill_resources(od, res);
+if (ret != 0)
+goto fail_no_fill;
+
+/*
+ * If pdev-num_resources 0, then assume that,
+ * MEM and IRQ resources will only come from DT and only
+ * fill DMA resource from hwmod layer.
+ */
+if (pdev-num_resources 0) {
+
+dev_dbg(pdev-dev, %s(): resources allocated %d hwmod #%d\n,
+__func__, pdev-num_resources, res_count);
+
+/* find number of resources needing to be inserted */
+for (i = 0, j = 0, r = res; i res_count; i++, r++) {
+type = resource_type(r);
+if (type == IORESOURCE_DMA)
+j++;
+}
+
+/* no need to insert anything, just return */
+if (j == 0) {
+kfree(res);
+return 0;
+}
+
+/* we need to insert j additional resources */
+rnew = kzalloc(sizeof(*rnew) *
+(pdev-num_resources + j), GFP_KERNEL);
+if (rnew == NULL)
+goto fail_no_rnew;
+
+/*
+ * Unlink any resources from any lists
Re: [PATCH 1/5] capemgr: Beaglebone DT overlay based cape manager
Hi Tony, On Jan 7, 2013, at 10:09 PM, Tony Lindgren wrote: * Pantelis Antoniou pa...@antoniou-consulting.com [130107 10:54]: A cape loader based on DT overlays and DT objects. Beaglebone cape manager implementation. Signed-off-by: Pantelis Antoniou pa...@antoniou-consulting.com --- arch/arm/mach-omap2/Kconfig|2 + drivers/misc/Kconfig |2 + drivers/misc/Makefile |1 + drivers/misc/cape/Kconfig |5 + drivers/misc/cape/Makefile |5 + drivers/misc/cape/beaglebone/Kconfig | 11 + drivers/misc/cape/beaglebone/Makefile |5 + drivers/misc/cape/beaglebone/capemgr.c | 1835 The driver should probably be in drivers/bus? It was a bus on the previous iteration and there was a flame storm of epic proportions. It is not a bus at all now, it's just a device loader; there are no bus constructs at all. I am at a loss to classify it really, so drivers/misc where every misfit ends up sounded OK. I'm open to suggestions though. 8 files changed, 1866 insertions(+) create mode 100644 drivers/misc/cape/Kconfig create mode 100644 drivers/misc/cape/Makefile create mode 100644 drivers/misc/cape/beaglebone/Kconfig create mode 100644 drivers/misc/cape/beaglebone/Makefile create mode 100644 drivers/misc/cape/beaglebone/capemgr.c diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig index 41b581f..f0c2eab 100644 --- a/arch/arm/mach-omap2/Kconfig +++ b/arch/arm/mach-omap2/Kconfig @@ -18,6 +18,8 @@ config ARCH_OMAP2PLUS_TYPICAL select TWL4030_CORE if ARCH_OMAP3 || ARCH_OMAP4 select TWL4030_POWER if ARCH_OMAP3 || ARCH_OMAP4 select VFP +select OF_OVERLAY +select OF_RESOLVE help Compile a kernel suitable for booting most boards You should just make the driver depend on OF_OVERLAY and OF_RESOLVE as most SoCs won't need this. Then we can select it in the omap2plus_defconfig. OK Regards, Tony Regards -- Pantelis -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/5] capemgr: Beaglebone DT overlay based cape manager
Hi Tony, On Jan 7, 2013, at 10:23 PM, Tony Lindgren wrote: * Pantelis Antoniou pa...@antoniou-consulting.com [130107 12:16]: Hi Tony, On Jan 7, 2013, at 10:09 PM, Tony Lindgren wrote: * Pantelis Antoniou pa...@antoniou-consulting.com [130107 10:54]: A cape loader based on DT overlays and DT objects. Beaglebone cape manager implementation. Signed-off-by: Pantelis Antoniou pa...@antoniou-consulting.com --- arch/arm/mach-omap2/Kconfig|2 + drivers/misc/Kconfig |2 + drivers/misc/Makefile |1 + drivers/misc/cape/Kconfig |5 + drivers/misc/cape/Makefile |5 + drivers/misc/cape/beaglebone/Kconfig | 11 + drivers/misc/cape/beaglebone/Makefile |5 + drivers/misc/cape/beaglebone/capemgr.c | 1835 The driver should probably be in drivers/bus? It was a bus on the previous iteration and there was a flame storm of epic proportions. Heh :) It is not a bus at all now, it's just a device loader; there are no bus constructs at all. I am at a loss to classify it really, so drivers/misc where every misfit ends up sounded OK. Right.. I'm open to suggestions though. Well how about split it to an eeprom driver, and Linux generic device loader parts? All that's left is the eeprom driver (accessor) and calls to the generic DT overlay constructs. If you caught on the previous patchset about DT overlays it should be clear. So it is split along those lines already. Regards, Tony Regards -- Pantelis -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/5] capemgr: Beaglebone DT overlay based cape manager
Hi Tony, On Jan 7, 2013, at 10:35 PM, Tony Lindgren wrote: * Pantelis Antoniou pa...@antoniou-consulting.com [130107 12:29]: On Jan 7, 2013, at 10:23 PM, Tony Lindgren wrote: Well how about split it to an eeprom driver, and Linux generic device loader parts? All that's left is the eeprom driver (accessor) and calls to the generic DT overlay constructs. If you caught on the previous patchset about DT overlays it should be clear. So it is split along those lines already. Hmm I was thinking something like this: drivers/base/device-loader.c drivers/misc/eeprom/beaglebone-cape.c Then you may be able to just load the configuration for it from a .dts file and maybe no hardware specific glue is even needed. At the end of the line, some kind of hardware glue is going to be needed. I just feel that drawing from a sample size of 1 (maybe 2 if I get to throw in the beagleboard), it is a bit premature to think about making it overly general, besides the part that are obviously part of the infrastructure (like the DT overlay stuff). What I'm getting at, is that we need some user experience about this, before going away and creating structure out of possible misconception about the uses. Regards, Tony Regards -- Pantelis -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/6] Introducing Device Tree Overlays
Hi Richard, It should, but there are a few differences in the syntax plus the fact that I didn't write it. It should go in by a separate patch by the original author. Regards -- Pantelis Από το iPad μου 5 Ιαν 2013, 11:35 π.μ., ο/η Richard Cochran richardcoch...@gmail.com έγραψε: On Sat, Jan 05, 2013 at 12:16:51AM -0600, Joel A Fernandes wrote: The problem being addressed is discussed in this thread: http://permalink.gmane.org/gmane.linux.kernel/1389017 Thanks for the link. Since the motivation is already documented in that post, why not add it into Documentation/devicetree/overlay-notes.txt as well? Thanks, Richard -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/6] Introducing Device Tree Overlays
The following patchset introduces Device Tree overlays, a method of dynamically altering the kernel's live Device Tree. This patchset is against mainline as of Friday Jan 4 2013. (4956964 Merge tag 'driver-core-3.8-rc2' of \ git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core) Note that a separate patch for the DTC compiler has been posted and is required to compile the DTS files according to the documentation. The patch is dtc: Dynamic symbols fixup support An implementation patchset for a beaglebone cape loader will follow, but if you want to check out a working kernel for the beaglebone please pull from: git://github.com/pantoniou/linux-bbxm.git branch not-capebus-v8 Pantelis Antoniou (6): OF: Introduce device tree node flag helpers. OF: export of_property_notify OF: Export all DT proc update functions OF: Introduce utility helper functions OF: Introduce Device Tree resolve support. OF: Introduce DT overlay support. .../devicetree/dynamic-resolution-notes.txt| 25 + Documentation/devicetree/overlay-notes.txt | 179 + drivers/of/Kconfig | 19 + drivers/of/Makefile| 4 +- drivers/of/base.c | 114 +-- drivers/of/overlay.c | 831 + drivers/of/resolver.c | 394 ++ drivers/of/util.c | 253 +++ include/linux/of.h | 243 ++ 9 files changed, 2005 insertions(+), 57 deletions(-) create mode 100644 Documentation/devicetree/dynamic-resolution-notes.txt create mode 100644 Documentation/devicetree/overlay-notes.txt create mode 100644 drivers/of/overlay.c create mode 100644 drivers/of/resolver.c create mode 100644 drivers/of/util.c -- 1.7.12 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/6] OF: Introduce device tree node flag helpers.
Helper functions for working with device node flags.
Signed-off-by: Pantelis Antoniou pa...@antoniou-consulting.com
---
include/linux/of.h | 20
1 file changed, 20 insertions(+)
diff --git a/include/linux/of.h b/include/linux/of.h
index 5ebcc5c..2ff35b5 100644
--- a/include/linux/of.h
+++ b/include/linux/of.h
@@ -114,6 +114,26 @@ static inline void of_node_set_flag(struct device_node *n,
unsigned long flag)
set_bit(flag, n-_flags);
}
+static inline void of_node_clear_flag(struct device_node *n, unsigned long
flag)
+{
+ clear_bit(flag, n-_flags);
+}
+
+static inline int of_property_check_flag(struct property *p, unsigned long
flag)
+{
+ return test_bit(flag, p-_flags);
+}
+
+static inline void of_property_set_flag(struct property *p, unsigned long flag)
+{
+ set_bit(flag, p-_flags);
+}
+
+static inline void of_property_clear_flag(struct property *p, unsigned long
flag)
+{
+ clear_bit(flag, p-_flags);
+}
+
extern struct device_node *of_find_all_nodes(struct device_node *prev);
/*
--
1.7.12
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/6] OF: Export all DT proc update functions
There are other users for the proc DT functions.
Export them.
Signed-off-by: Pantelis Antoniou pa...@antoniou-consulting.com
---
drivers/of/base.c | 108 -
include/linux/of.h | 29 ++
2 files changed, 87 insertions(+), 50 deletions(-)
diff --git a/drivers/of/base.c b/drivers/of/base.c
index d598216..526db99 100644
--- a/drivers/of/base.c
+++ b/drivers/of/base.c
@@ -1126,6 +1126,61 @@ int of_property_notify(int action, struct device_node
*np,
}
#endif
+#ifdef CONFIG_PROC_DEVICETREE
+
+void of_add_proc_dt_entry(struct device_node *dn)
+{
+ struct proc_dir_entry *ent;
+
+ ent = proc_mkdir(strrchr(dn-full_name, '/') + 1, dn-parent-pde);
+ if (ent)
+ proc_device_tree_add_node(dn, ent);
+}
+
+void of_remove_proc_dt_entry(struct device_node *dn)
+{
+ struct device_node *parent;
+ struct property *prop;
+
+ if (!dn)
+ return;
+
+ parent = dn-parent;
+ prop = dn-properties;
+ while (prop) {
+ if (dn-pde)
+ remove_proc_entry(prop-name, dn-pde);
+ prop = prop-next;
+ }
+
+ if (dn-pde)
+ remove_proc_entry(dn-pde-name,
+ parent ? parent-pde : NULL);
+}
+
+void of_add_proc_dt_prop_entry(struct device_node *np,
+ struct property *prop)
+{
+ if (np prop np-pde)
+ proc_device_tree_add_prop(np-pde, prop);
+}
+
+void of_remove_proc_dt_prop_entry(struct device_node *np,
+ struct property *prop)
+{
+ if (np prop np-pde)
+ proc_device_tree_remove_prop(np-pde, prop);
+}
+
+void of_update_proc_dt_prop_entry(struct device_node *np,
+ struct property *newprop, struct property *oldprop)
+{
+ if (np newprop oldprop np-pde)
+ proc_device_tree_update_prop(np-pde, newprop, oldprop);
+}
+
+#endif /* CONFIG_PROC_DEVICETREE */
+
/**
* of_add_property - Add a property to a node
*/
@@ -1153,11 +1208,8 @@ int of_add_property(struct device_node *np, struct
property *prop)
*next = prop;
write_unlock_irqrestore(devtree_lock, flags);
-#ifdef CONFIG_PROC_DEVICETREE
/* try to add to proc as well if it was initialized */
- if (np-pde)
- proc_device_tree_add_prop(np-pde, prop);
-#endif /* CONFIG_PROC_DEVICETREE */
+ of_add_proc_dt_prop_entry(np, prop);
return 0;
}
@@ -1199,11 +1251,7 @@ int of_remove_property(struct device_node *np, struct
property *prop)
if (!found)
return -ENODEV;
-#ifdef CONFIG_PROC_DEVICETREE
- /* try to remove the proc node as well */
- if (np-pde)
- proc_device_tree_remove_prop(np-pde, prop);
-#endif /* CONFIG_PROC_DEVICETREE */
+ of_remove_proc_dt_prop_entry(np, prop);
return 0;
}
@@ -1253,11 +1301,8 @@ int of_update_property(struct device_node *np, struct
property *newprop)
if (!found)
return -ENODEV;
-#ifdef CONFIG_PROC_DEVICETREE
/* try to add to proc as well if it was initialized */
- if (np-pde)
- proc_device_tree_update_prop(np-pde, newprop, oldprop);
-#endif /* CONFIG_PROC_DEVICETREE */
+ of_update_proc_dt_prop_entry(np, newprop, oldprop);
return 0;
}
@@ -1293,22 +1338,6 @@ int of_reconfig_notify(unsigned long action, void *p)
return notifier_to_errno(rc);
}
-#ifdef CONFIG_PROC_DEVICETREE
-static void of_add_proc_dt_entry(struct device_node *dn)
-{
- struct proc_dir_entry *ent;
-
- ent = proc_mkdir(strrchr(dn-full_name, '/') + 1, dn-parent-pde);
- if (ent)
- proc_device_tree_add_node(dn, ent);
-}
-#else
-static void of_add_proc_dt_entry(struct device_node *dn)
-{
- return;
-}
-#endif
-
/**
* of_attach_node - Plug a device node into the tree and global list.
*/
@@ -1332,27 +1361,6 @@ int of_attach_node(struct device_node *np)
return 0;
}
-#ifdef CONFIG_PROC_DEVICETREE
-static void of_remove_proc_dt_entry(struct device_node *dn)
-{
- struct device_node *parent = dn-parent;
- struct property *prop = dn-properties;
-
- while (prop) {
- remove_proc_entry(prop-name, dn-pde);
- prop = prop-next;
- }
-
- if (dn-pde)
- remove_proc_entry(dn-pde-name, parent-pde);
-}
-#else
-static void of_remove_proc_dt_entry(struct device_node *dn)
-{
- return;
-}
-#endif
-
/**
* of_detach_node - Unplug a node from the device tree.
*
diff --git a/include/linux/of.h b/include/linux/of.h
index aea3694..305b087 100644
--- a/include/linux/of.h
+++ b/include/linux/of.h
@@ -309,6 +309,35 @@ static inline int of_property_notify(int action, struct
device_node *np,
}
#endif
+#ifdef CONFIG_PROC_DEVICETREE
+
+extern void of_add_proc_dt_entry(struct device_node *dn);
+extern void of_remove_proc_dt_entry(struct device_node *dn
[PATCH 4/6] OF: Introduce utility helper functions
Introduce helper functions for working with the live DT tree.
__of_free_property() frees a dynamically created property
__of_free_tree() recursively frees a device node tree
__of_copy_property() copies a property dynamically
__of_create_empty_node() creates an empty node
__of_find_node_by_full_name() finds the node with the full name
and
of_multi_prop_cmp() performs a multi property compare but without
having to take locks.
Signed-off-by: Pantelis Antoniou pa...@antoniou-consulting.com
---
drivers/of/Makefile | 2 +-
drivers/of/util.c | 253
include/linux/of.h | 59
3 files changed, 313 insertions(+), 1 deletion(-)
create mode 100644 drivers/of/util.c
diff --git a/drivers/of/Makefile b/drivers/of/Makefile
index e027f44..abcc08a 100644
--- a/drivers/of/Makefile
+++ b/drivers/of/Makefile
@@ -1,4 +1,4 @@
-obj-y = base.o
+obj-y = base.o util.o
obj-$(CONFIG_OF_FLATTREE) += fdt.o
obj-$(CONFIG_OF_PROMTREE) += pdt.o
obj-$(CONFIG_OF_ADDRESS) += address.o
diff --git a/drivers/of/util.c b/drivers/of/util.c
new file mode 100644
index 000..5117e2b
--- /dev/null
+++ b/drivers/of/util.c
@@ -0,0 +1,253 @@
+/*
+ * Utility functions for working with device tree(s)
+ *
+ * Copyright (C) 2012 Pantelis Antoniou pa...@antoniou-consulting.com
+ * Copyright (C) 2012 Texas Instruments Inc.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * version 2 as published by the Free Software Foundation.
+ */
+
+#include linux/kernel.h
+#include linux/module.h
+#include linux/of.h
+#include linux/of_device.h
+#include linux/string.h
+#include linux/ctype.h
+#include linux/errno.h
+#include linux/string.h
+#include linux/slab.h
+#include linux/err.h
+
+/**
+ * __of_free_property - release the memory of an allocated property
+ * @prop: Property to release
+ *
+ * Release the memory of an allocated property only after checking
+ * that the property has been marked as OF_DYNAMIC.
+ * Only call on known allocated properties.
+ */
+void __of_free_property(struct property *prop)
+{
+ if (prop == NULL)
+ return;
+
+ if (of_property_check_flag(prop, OF_DYNAMIC)) {
+ kfree(prop-value);
+ kfree(prop-name);
+ kfree(prop);
+ } else {
+ pr_warn(%s: property %p cannot be freed; memory is gone\n,
+ __func__, prop);
+ }
+}
+
+/**
+ * __of_free_tree - release the memory of a device tree node and
+ * of all it's children + properties.
+ * @node: Device Tree node to release
+ *
+ * Release the memory of a device tree node and of all it's children.
+ * Also release the properties and the dead properties.
+ * Only call on detached node trees, and you better be sure that
+ * no pointer exist for any properties. Only safe to do if you
+ * absolutely control the life cycle of the node.
+ * Also note that the node is not removed from the all_nodes list,
+ * neither from the parent's child list; this should be handled before
+ * calling this function.
+ */
+void __of_free_tree(struct device_node *node)
+{
+ struct property *prop;
+ struct device_node *noden;
+
+ /* sanity check */
+ if (!node)
+ return;
+
+ /* free recursively any children */
+ while ((noden = node-child) != NULL) {
+ node-child = noden-sibling;
+ __of_free_tree(noden);
+ }
+
+ /* free every property already allocated */
+ while ((prop = node-properties) != NULL) {
+ node-properties = prop-next;
+ __of_free_property(prop);
+ }
+
+ /* free dead properties already allocated */
+ while ((prop = node-deadprops) != NULL) {
+ node-deadprops = prop-next;
+ __of_free_property(prop);
+ }
+
+ if (of_node_check_flag(node, OF_DYNAMIC)) {
+ kfree(node-type);
+ kfree(node-name);
+ kfree(node);
+ } else {
+ pr_warn(%s: node %p cannot be freed; memory is gone\n,
+ __func__, node);
+ }
+}
+
+/**
+ * __of_copy_property - Copy a property dynamically.
+ * @prop: Property to copy
+ * @flags: Allocation flags (typically pass GFP_KERNEL)
+ *
+ * Copy a property by dynamically allocating the memory of both the
+ * property stucture and the property name contents. The property's
+ * flags have the OF_DYNAMIC bit set so that we can differentiate between
+ * dynamically allocated properties and not.
+ * Returns the newly allocated property or NULL on out of memory error.
+ */
+struct property *__of_copy_property(const struct property *prop, gfp_t flags)
+{
+ struct property *propn;
+
+ propn = kzalloc(sizeof(*prop), flags);
+ if (propn == NULL)
+ return NULL;
+
+ propn-name = kstrdup
[PATCH 5/6] OF: Introduce Device Tree resolve support.
Introduce support for dynamic device tree resolution.
Using it, it is possible to prepare a device tree that's
been loaded on runtime to be modified and inserted at the kernel
live tree.
Signed-off-by: Pantelis Antoniou pa...@antoniou-consulting.com
---
.../devicetree/dynamic-resolution-notes.txt| 25 ++
drivers/of/Kconfig | 9 +
drivers/of/Makefile| 1 +
drivers/of/resolver.c | 394 +
include/linux/of.h | 17 +
5 files changed, 446 insertions(+)
create mode 100644 Documentation/devicetree/dynamic-resolution-notes.txt
create mode 100644 drivers/of/resolver.c
diff --git a/Documentation/devicetree/dynamic-resolution-notes.txt
b/Documentation/devicetree/dynamic-resolution-notes.txt
new file mode 100644
index 000..0b396c4
--- /dev/null
+++ b/Documentation/devicetree/dynamic-resolution-notes.txt
@@ -0,0 +1,25 @@
+Device Tree Dynamic Resolver Notes
+--
+
+This document describes the implementation of the in-kernel
+Device Tree resolver, residing in drivers/of/resolver.c and is a
+companion document to Documentation/devicetree/dt-object-internal.txt[1]
+
+How the resolver works
+--
+
+The resolver is given as an input an arbitrary tree compiled with the
+proper dtc option and having a /plugin/ tag. This generates the
+appropriate __fixups__ __local_fixups__ nodes as described in [1].
+
+In sequence the resolver works by the following steps:
+
+1. Get the maximum device tree phandle value from the live tree + 1.
+2. Adjust all the local phandles of the tree to resolve by that amount.
+3. Using the __local__fixups__ node information adjust all local references
+ by the same amount.
+4. For each property in the __fixups__ node locate the node it references
+ in the live tree. This is the label used to tag the node.
+5. Retrieve the phandle of the target of the fixup.
+5. For each fixup in the property locate the node:property:offset location
+ and replace it with the phandle value.
diff --git a/drivers/of/Kconfig b/drivers/of/Kconfig
index d37bfcf..f9a6193 100644
--- a/drivers/of/Kconfig
+++ b/drivers/of/Kconfig
@@ -83,4 +83,13 @@ config OF_MTD
depends on MTD
def_bool y
+config OF_RESOLVE
+ bool OF Dynamic resolution support
+ depends on OF
+ select OF_DYNAMIC
+ select OF_DEVICE
+ help
+ Enable OF dynamic resolution support. This allows you to
+ load Device Tree object fragments are run time.
+
endmenu # OF
diff --git a/drivers/of/Makefile b/drivers/of/Makefile
index abcc08a..9a809c9 100644
--- a/drivers/of/Makefile
+++ b/drivers/of/Makefile
@@ -11,3 +11,4 @@ obj-$(CONFIG_OF_MDIO) += of_mdio.o
obj-$(CONFIG_OF_PCI) += of_pci.o
obj-$(CONFIG_OF_PCI_IRQ) += of_pci_irq.o
obj-$(CONFIG_OF_MTD) += of_mtd.o
+obj-$(CONFIG_OF_RESOLVE) += resolver.o
diff --git a/drivers/of/resolver.c b/drivers/of/resolver.c
new file mode 100644
index 000..016d7da
--- /dev/null
+++ b/drivers/of/resolver.c
@@ -0,0 +1,394 @@
+/*
+ * Functions for dealing with DT resolution
+ *
+ * Copyright (C) 2012 Pantelis Antoniou pa...@antoniou-consulting.com
+ * Copyright (C) 2012 Texas Instruments Inc.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * version 2 as published by the Free Software Foundation.
+ */
+
+#include linux/kernel.h
+#include linux/module.h
+#include linux/of.h
+#include linux/of_device.h
+#include linux/of_fdt.h
+#include linux/string.h
+#include linux/ctype.h
+#include linux/errno.h
+#include linux/string.h
+#include linux/slab.h
+
+/**
+ * Find a subtree's maximum phandle value.
+ */
+static phandle __of_get_tree_max_phandle(struct device_node *node,
+ phandle max_phandle)
+{
+ struct device_node *child;
+
+ if (node-phandle != 0 node-phandle != OF_PHANDLE_ILLEGAL
+ node-phandle max_phandle)
+ max_phandle = node-phandle;
+
+ __for_each_child_of_node(node, child)
+ max_phandle = __of_get_tree_max_phandle(child, max_phandle);
+
+ return max_phandle;
+}
+
+/**
+ * Find live tree's maximum phandle value.
+ */
+static phandle of_get_tree_max_phandle(void)
+{
+ struct device_node *node;
+ phandle phandle;
+
+ /* get root node */
+ node = of_find_node_by_path(/);
+ if (node == NULL)
+ return OF_PHANDLE_ILLEGAL;
+
+ /* now search recursively */
+ read_lock(devtree_lock);
+ phandle = __of_get_tree_max_phandle(node, 0);
+ read_unlock(devtree_lock);
+
+ of_node_put(node);
+
+ return phandle;
+}
+
+/**
+ * Adjust a subtree's phandle values by a given delta.
+ * Makes sure not to just adjust the device node's phandle value,
+ * but modify the phandle properties values as well.
+ */
+static
[PATCH 2/6] OF: export of_property_notify
of_property_notify can be utilized by other users too, export it.
Signed-off-by: Pantelis Antoniou pa...@antoniou-consulting.com
---
drivers/of/base.c | 8 +---
include/linux/of.h | 11 +++
2 files changed, 12 insertions(+), 7 deletions(-)
diff --git a/drivers/of/base.c b/drivers/of/base.c
index 2390ddb..d598216 100644
--- a/drivers/of/base.c
+++ b/drivers/of/base.c
@@ -1115,7 +1115,7 @@ int of_parse_phandle_with_args(const struct device_node
*np, const char *list_na
EXPORT_SYMBOL(of_parse_phandle_with_args);
#if defined(CONFIG_OF_DYNAMIC)
-static int of_property_notify(int action, struct device_node *np,
+int of_property_notify(int action, struct device_node *np,
struct property *prop)
{
struct of_prop_reconfig pr;
@@ -1124,12 +1124,6 @@ static int of_property_notify(int action, struct
device_node *np,
pr.prop = prop;
return of_reconfig_notify(action, pr);
}
-#else
-static int of_property_notify(int action, struct device_node *np,
- struct property *prop)
-{
- return 0;
-}
#endif
/**
diff --git a/include/linux/of.h b/include/linux/of.h
index 2ff35b5..aea3694 100644
--- a/include/linux/of.h
+++ b/include/linux/of.h
@@ -298,6 +298,17 @@ extern int of_parse_phandle_with_args(const struct
device_node *np,
const char *list_name, const char *cells_name, int index,
struct of_phandle_args *out_args);
+#if defined(CONFIG_OF_DYNAMIC)
+extern int of_property_notify(int action, struct device_node *np,
+ struct property *prop);
+#else
+static inline int of_property_notify(int action, struct device_node *np,
+ struct property *prop)
+{
+ return 0;
+}
+#endif
+
extern void of_alias_scan(void * (*dt_alloc)(u64 size, u64 align));
extern int of_alias_get_id(struct device_node *np, const char *stem);
--
1.7.12
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] omap: Properly handle resources for omap_devices
omap_device relies on the platform notifier callbacks managing resources
behind the scenes. The resources were not properly linked causing crashes
when removing the device.
Rework the resource modification code so that linking is performed properly,
and make sure that no resources that have no parent (which can happen for DMA
IRQ resources) are ever left for cleanup by the core resource layer.
Signed-off-by: Pantelis Antoniou pa...@antoniou-consulting.com
---
arch/arm/mach-omap2/omap_device.c | 232 --
1 file changed, 148 insertions(+), 84 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_device.c
b/arch/arm/mach-omap2/omap_device.c
index e065daa..9f8dba1 100644
--- a/arch/arm/mach-omap2/omap_device.c
+++ b/arch/arm/mach-omap2/omap_device.c
@@ -494,30 +494,156 @@ static int omap_device_fill_resources(struct omap_device
*od,
}
/**
- * _od_fill_dma_resources - fill in array of struct resource with dma resources
+ * omap_device_fixup_resources - Fix platform device resources
* @od: struct omap_device *
- * @res: pointer to an array of struct resource to be filled in
- *
- * Populate one or more empty struct resource pointed to by @res with
- * the dma resource data for this omap_device @od. Used by
- * omap_device_alloc() after calling omap_device_count_resources().
- *
- * Ideally this function would not be needed at all. If we have
- * mechanism to get dma resources from DT.
*
- * Returns 0.
+ * Fixup the platform device resources so that the resources
+ * from the hwmods are included for.
*/
-static int _od_fill_dma_resources(struct omap_device *od,
- struct resource *res)
+static int omap_device_fixup_resources(struct omap_device *od)
{
- int i, r;
+ struct platform_device *pdev = od-pdev;
+ int i, j, ret, res_count;
+ struct resource *res, *r, *rnew, *rn;
+ unsigned long type;
- for (i = 0; i od-hwmods_cnt; i++) {
- r = omap_hwmod_fill_dma_resources(od-hwmods[i], res);
- res += r;
+ /*
+* DT Boot:
+* OF framework will construct the resource structure (currently
+* does for MEM IRQ resource) and we should respect/use these
+* resources, killing hwmod dependency.
+* If pdev-num_resources 0, we assume that MEM IRQ resources
+* have been allocated by OF layer already (through DTB).
+*
+* Non-DT Boot:
+* Here, pdev-num_resources = 0, and we should get all the
+* resources from hwmod.
+*
+* TODO: Once DMA resource is available from OF layer, we should
+* kill filling any resources from hwmod.
+*/
+
+ /* count number of resources hwmod provides */
+ res_count = omap_device_count_resources(od, IORESOURCE_IRQ |
+ IORESOURCE_DMA | IORESOURCE_MEM);
+
+ /* if no resources from hwmod, we're done already */
+ if (res_count == 0)
+ return 0;
+
+ /* Allocate resources memory to account for all hwmod resources */
+ res = kzalloc(sizeof(struct resource) * res_count, GFP_KERNEL);
+ if (!res) {
+ ret = -ENOMEM;
+ goto fail_no_res;
}
+ /* fill all the resources */
+ ret = omap_device_fill_resources(od, res);
+ if (ret != 0)
+ goto fail_no_fill;
+
+ /*
+* If pdev-num_resources 0, then assume that,
+* MEM and IRQ resources will only come from DT and only
+* fill DMA resource from hwmod layer.
+*/
+ if (pdev-num_resources 0) {
+
+ dev_dbg(pdev-dev, %s(): resources allocated %d hwmod #%d\n,
+ __func__, pdev-num_resources, res_count);
+
+ /* find number of resources needing to be inserted */
+ for (i = 0, j = 0, r = res; i res_count; i++, r++) {
+ type = resource_type(r);
+ if (type == IORESOURCE_DMA)
+ j++;
+ }
+
+ /* no need to insert anything, just return */
+ if (j == 0) {
+ kfree(res);
+ return 0;
+ }
+
+ /* we need to insert j additional resources */
+ rnew = kzalloc(sizeof(*rnew) *
+ (pdev-num_resources + j), GFP_KERNEL);
+ if (rnew == NULL)
+ goto fail_no_rnew;
+
+ /*
+* Unlink any resources from any lists.
+* This is important since the copying destroys any
+* linkage
+*/
+ for (i = 0, r = pdev-resource;
+ i pdev-num_resources; i++, r++) {
+
+ if (!r-parent)
+ continue;
+
+ dev_dbg(pdev-dev
[PATCH] omap: am33xx-hwmod: Fix wrongly terminated am33xx_usbss_mpu_irqs array
The IRQ array must be terminated by -1 and not by -1+OMAP_INTC_START
This led to having a resource list of 100s of IRQs.
Signed-off-by: Pantelis Antoniou pa...@antoniou-consulting.com
---
arch/arm/mach-omap2/omap_hwmod_33xx_data.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_33xx_data.c
b/arch/arm/mach-omap2/omap_hwmod_33xx_data.c
index 081c71e..e402303 100644
--- a/arch/arm/mach-omap2/omap_hwmod_33xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_33xx_data.c
@@ -2070,7 +2070,7 @@ static struct omap_hwmod_irq_info am33xx_usbss_mpu_irqs[]
= {
{ .name = usbss-irq, .irq = 17 + OMAP_INTC_START, },
{ .name = musb0-irq, .irq = 18 + OMAP_INTC_START, },
{ .name = musb1-irq, .irq = 19 + OMAP_INTC_START, },
- { .irq = -1 + OMAP_INTC_START, },
+ { .irq = -1, },
};
static struct omap_hwmod am33xx_usbss_hwmod = {
--
1.7.12
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] Device Tree Overlays Proposal (Was Re: capebus moving omap_devices to mach-omap2)
Hi David,
On Nov 13, 2012, at 9:25 AM, David Gibson wrote:
On Mon, Nov 12, 2012 at 09:52:32AM -0700, Stephen Warren wrote:
On 11/12/2012 05:10 AM, Pantelis Antoniou wrote:
[snip]
Oh yes. In fact if one was to use a single kernel image for beagleboard
and beaglebone, for the cape to work for both, it is required for it's
dtb to be compatible.
Well, as Grant pointed out, it's not actually strictly necessary for the
.dtb to be compatible; only the .dts /need/ be compatible, and the .dtb
can be generated at run-time using dtc for example.
So, actually, I think a whole bunch of problems with phandle
resolution disappear if we don't try to define an overlay .dtb format,
or at least treat it only as a very shortlived object. A more precise
proposal below. Note that this works more or less equally well with
either the original overlay approach or the graft/graft-bundle
proposal I made elsewhere.
1) We annotate the base tree with some extra label information for
nodes which overlays are likely to want to reference by phandle. e.g.
beaglebone_pic: interrupt-controller@X {
...
phandle,symbolic-name = beaglebone_pic;
};
We could extend dtc to (optionally?) auto-generate those properties
from its existing label syntax. Not sure if that's a good idea or
not yet. In any case, we compile this augmented base tree to .dtb as
normal and boot our kernel with it.
I'm fine with that. You can auto-generate when there's a label to a node.
The cape dt fragment will use the label name to reference a node.
More details below...
2) The information for the capes/modules/whatever is
distributed/packaged as .dts, never .dtb. When userspace detects the
new module (or the user explicitly tells it, if it's not probeable) it
picks up the correct dts and runs it through dtc in a special mode.
In this mode dtc takes the existing base tree (from /proc/device-tree,
say) as well as the new dts. In this mode, dtc allocates phandles for
the new tree fragment so as not to collide with anything from the
supplied base tree (as well as avoiding internal conflicts,
obviously). It also allows node references to the base tree by using
those label annotations from (1) to match symbolic names to the
phandle values in the base tree.
Not good to rely on userspace kicking off dtc and compiling from source.
Some capes/expansion boards might have your root fs device, for example
there is an eMMC cape coming up, while networking capes are common too.
However I have a compromise.
I agree that compiling from source can be an option for a runtime definable
cape, but for built-in capes we could do a bit better.
In particular, I don't see any particular need to have a DT fragment
reference anything that dependent of the runtime device tree. It should
be possible to compile the DT fragment in kernel, against the generated
flattened device tree, producing a flattened DT fragment with the phandles
already resolved.
So the sequence could be something like this:
$ dtc -O dtb -o am335x-bone.dtb -b 0 am335x-bone.dts -@ ${LAST_PHANDLE_FILE}
$ dtc -O dtbf -R am335x-bone.dtb -o weather-cape.dtb -b 0 weather-cape.dts -@
${LAST_PHANDLE_FILE}
$ dtc -O dtbf -R am335x-bone.dtb -o geiger-cape.dtb -b 0 geiger-cape.dts -@
${LAST_PHANDLE_FILE}
The ${LAST_PHANDLE_FILE} can be updated with the last phandle value generated.
Alternatively we could have a way to statically assign a phandle range
for well known capes. All the others will have to use the runtime compile
mechanism.
$ dtc -O dtb -o am335x-bone.dtb -b 0 am335x-bone.dts
$ dtc -O dtbf -R am335x-bone.dtb -o weather-cape.dtb -b 0 weather-cape.dts
$ dtc -O dtbf -R am335x-bone.dtb -o geiger-cape.dtb -b 0 geiger-cape.dts
With the cape dtses having a /phandle-range/ statement at the top.
This can work because the cape dts do not cross-reference each other, and
neither the boot dts references the capes.
That way we can use request_firmware() pretty early in the boot sequence
and get the DT fragment we need even before user-space starts and root fs
has mounted. request_firmware() can locate the fragments in the kernel
image before rootfs.
I don't know if this will cover all the cases Grant has in mind though.
So just to make sure I got it right, this could work for our case.
i2c2: i2c@4819c000 {
compatible = ti,omap4-i2c;
#address-cells = 1;
#size-cells = 0;
ti,hwmods = i2c3;
reg = 0x4819c000 0x1000;
interrupt-parent = intc;
interrupts = 30;
status = disabled;
};
And in the cape definition (when compiled with the special mode I describe
below)
/ {
plugin-bundle;
compatible = cco,weather-cape;
version = 00A0;
i2c2-graft = {
compatible = dt,graft;
graft-point = i2c2;
#address-cells = 1;
#size-cells = 0;
/* Ambient light
Re: [RFC] Device Tree Overlays Proposal (Was Re: capebus moving omap_devices to mach-omap2)
Hi Grant,
On Nov 13, 2012, at 2:24 PM, Grant Likely wrote:
On Tue, Nov 13, 2012 at 8:09 AM, Pantelis Antoniou
pa...@antoniou-consulting.com wrote:
On Nov 13, 2012, at 9:25 AM, David Gibson wrote:
Not good to rely on userspace kicking off dtc and compiling from source.
Some capes/expansion boards might have your root fs device, for example
there is an eMMC cape coming up, while networking capes are common too.
However I have a compromise.
I agree that compiling from source can be an option for a runtime definable
cape, but for built-in capes we could do a bit better.
In particular, I don't see any particular need to have a DT fragment
reference anything that dependent of the runtime device tree. It should
be possible to compile the DT fragment in kernel, against the generated
flattened device tree, producing a flattened DT fragment with the phandles
already resolved.
Do you mean linking dtc into the kernel?
No, no :)
Typo there, s/in kernel/outside of the kernel/
So the sequence could be something like this:
$ dtc -O dtb -o am335x-bone.dtb -b 0 am335x-bone.dts -@ ${LAST_PHANDLE_FILE}
$ dtc -O dtbf -R am335x-bone.dtb -o weather-cape.dtb -b 0 weather-cape.dts
-@ ${LAST_PHANDLE_FILE}
$ dtc -O dtbf -R am335x-bone.dtb -o geiger-cape.dtb -b 0 geiger-cape.dts -@
${LAST_PHANDLE_FILE}
The ${LAST_PHANDLE_FILE} can be updated with the last phandle value
generated.
Alternatively we could have a way to statically assign a phandle range
for well known capes. All the others will have to use the runtime compile
mechanism.
$ dtc -O dtb -o am335x-bone.dtb -b 0 am335x-bone.dts
$ dtc -O dtbf -R am335x-bone.dtb -o weather-cape.dtb -b 0 weather-cape.dts
$ dtc -O dtbf -R am335x-bone.dtb -o geiger-cape.dtb -b 0 geiger-cape.dts
With the cape dtses having a /phandle-range/ statement at the top.
I really think the whole phandle allocation thing is a non problem.
Generating phandles is the easy part, and using a good hash function
pretty much solves it entirely. I know people are worried about
collisions, but there are only two scenarios where collisions may
happen:
1) base and overlay try to define same phandle
- Easy to detect - kernel can complain and refuse to load if it happens
- Will never happen when overlay is compiled against the base used
to boot (dtc can resolve the conflict)
- Hash phandle generation makes this exceptionally rare
2) two overlays try to define same phandle
- Also easy to detect on loading the second overlay - kernel will
- Hash phandle generation still makes this exceptionally rare
In both cases a collision is extremely rare and if it does happen it
will not fail silently. Besides, in the odd scenario where it does
happen, a node can be manually assigned a phandle. It is far better to
do the manual override maybe once or twice (actually, I'd be surprised
if it is ever needed) than to get into any kind of numberspace
management for phandles. That's just a maintenance nightmare.
The reason people (or at least me) is wary of collisions is that it
throws the user completely out of the normal workflow.
i.e. normal workflow is like this:
a) Edit cape DTS
b) Feed the DTB to the running kernel
c) It works.
When a collision happens c turns into
c.1) Fails with a message that 'there's a phandle collision'
c.2) Google about the error message, land on a page describing solution.
c.3) Modify the cape DTS to use an explicit phandle value.
c.4) It finally works.
Let's just say I don't expect users to deal with this easily.
Anyway, it's all academic at this point. I mostly care about making
the in-kernel dtc compile to handle the collisions automatically.
I think we agree that compiling a fragment that doesn't export any
phandles against the base dts, should produce a dtb that would load
without any collisions.
The hard bit to solve has always been when the overlay expects
different phandles than the base is using, and that problem only
occurs if the overlay is compiled against a different base dtb than
was used to boot the system. Hashed phandle generation even makes
phandles very stable when the base dtb is recompiled, and if they do
change, then the kernel can detect it and report an error. Again, no
silent failures. Phandle fixup does make the problem disappears
entirely but I'm concerned that it is still incomplete (see below) and
would be conceptually expensive.
Once of the requests is to support one overlay .dtb with many
different baseboards, but now that I've thought about it more I
realize that it just won't work for anything beyond the most trivial
case. Phandle fixup isn's sufficient. The format of GPIO, Interrupt,
clock, etc specifiers may change if the base board nodes change. The
specifiers are not portable.
My intention wasn't never to make overlays overly portable. My intention
was to make them in a way that portability can be introduced if the boards
are 'close' enough
Re: [RFC] Device Tree Overlays Proposal (Was Re: capebus moving omap_devices to mach-omap2)
Hi Mitch, On Nov 13, 2012, at 9:09 PM, Mitch Bradley wrote: On 11/13/2012 8:29 AM, Stephen Warren wrote: On 11/13/2012 11:10 AM, Mitch Bradley wrote: It seems to me that this capebus discussion is missing an important point. The name capebus suggests that it is a bus, so there should be a parent node to represent that bus. It should have a driver whose API implements all of the system-interface functions a cape needs. It was discussed earlier that capebus isn't actually a bus. It's simply a collection of a bunch of pins from the SoC hooked up to connectors. I'd agree that it's mis-named. Nevertheless, to the extent that the set of pins is finite and well-defined, it should be possible to define a set of software interfaces to support the functionality represented by those pins. It might depend on the underlying SoC, but even so, it would still be best to encapsulate the interface set. I hear all these use cases that presuppose a wide variety of user skill sets. If one really wants to support such users well, it's important to define a coherent single point of interface. That's what capebus is. Too bad there's such a fuss about the name. Check out the thread from the start for the sordid details. Regards -- Pantelis -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] pwm-backlight: Pinctrl-fy
Hi Linus, On Nov 11, 2012, at 7:26 PM, Linus Walleij wrote: On Fri, Nov 9, 2012 at 9:06 AM, Thierry Reding thierry.red...@avionic-design.de wrote: On Wed, Oct 31, 2012 at 05:57:27PM +0200, Pantelis Antoniou wrote: + pinctrl = devm_pinctrl_get_select_default(pdev-dev); + if (IS_ERR(pinctrl)) + dev_warn(pdev-dev, unable to select pin group\n); + I just saw this done in a similar way in some other driver and then remembered your patch. When I reviewed this I wasn't sure if a warning was good enough in this case. I've checked the kernel tree and it seems like a majority handled this as failure instead of a warning. I took a look at the pinctrl core and it seems like indeed if neither pinctrl is enabled or if there isn't actually a pinmux configuration for a device, then devm_pinctrl_get_select_default() will actually not return an error, so in those cases where an error is returned it should actually be handled as a fatal error. So it depends. One good reason to just error out and return the error code is if the error returned is -EPROBE_DEFER, right? Because then you're pinctrl driver is not up yet, and you need to bail out and be revisited later. On a related key we have this debate going on with some subsystem maintainers as to whether we should try do centralize boilerplate like this, the lates suggestion is: http://marc.info/?l=linux-kernelm=135263661110528w=2 Interesting... This is certainly much nicer than peppering all the devices with pinctrl calls. The fun never ends... Indeed. Yours, Linus Walleij Regards -- Pantelis -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] Device Tree Overlays Proposal (Was Re: capebus moving omap_devices to mach-omap2)
Hi Grant, Sorry for the late comments, travelling... On Nov 9, 2012, at 6:28 PM, Grant Likely wrote: On Tue, Nov 6, 2012 at 10:37 PM, Stephen Warren swar...@wwwdotorg.org wrote: On 11/05/2012 01:40 PM, Grant Likely wrote: Hey folks, As promised, here is my early draft to try and capture what device tree overlays need to do and how to get there. Comments and suggestions greatly appreciated. Interesting. This just came up internally at NVIDIA within the last couple weeks, and was discussed on the U-Boot mailing list very recently too: http://lists.denx.de/pipermail/u-boot/2012-October/thread.html#138227 (it spills into the November archive too) For these cases it is proposed to implement an overlay feature for the so that the initial device tree data can be modified by userspace at I don't know if you're maintaining this as a document and taking patches to it, but if so: Sure, why not... http://git.secretlab.ca/?p=devicetree-overlays.git;a=summary for the so split across those two lines. fixed - SHOULD reliably handle changes between different underlying overlays (ie. what happens to existing .dtb overly files if the structure of the dtb it is layered over changes. If not possible, then SHALL detect when the base tree doesn't match and refuse to apply the overlay. Perhaps use (versioned) DT bindings to represent the interface between the two .dts files? See the links to the U-Boot mailing list discussions below? Implementing versioning is conceptually a lot more complex than plain overlays since it means either the kernel or u-boot needs to start filtering the data that it's given. This can get really complex in a hurry. Mitch makes a valid point later in this thread that when it comes to manipulating the data depending on the board then the data overlay model alone doesn't handle it well. I'm not actually opposed to it, but it needs to be done in an elegant way. The DT data model already imposes more of a conceptual learning curve than I wish it did and I don't want to make that worse with a versioning model that is difficult to get ones head around. Suggestions and proposals are definitely welcome here. I didn't find versioning all that difficult TBH. Making the property access functions work sanely with versioning should cover most (if not all) kernel users. Keep non versioned property access function available to possibly users with a prefix for those that need it. - What is the model for overlays? - Can an overlay modify existing properties? - Can an overlay add new properties to existing nodes? - Can an overlay delete existing nodes/properties? This proposal is very oriented at an overlay-based approach. I'm not totally convinced that a pure overlay approach (as in how dtc does overlayed DT nodes) will be flexible enough, but would love to be persuaded. Again see below. The way I'm currently thinking about the overlay approach is as a discrete set of changes that all can be applied at once.* That certainly doesn't preclude the change being generated with a script or other tool in either firmware or userspace. For most changes it works really well. Of the scenarios that don't work well, I can think of two. The first is it moving or renaming existing nodes, and the second is if the structure of the base tree changes (say due to a firmware update). Although the second limitation is specifically with binary .dtb overlays. Recompiling the dts overlay against the new tree would work fine.** Atomicity should be handled correctly. I can't imagine how hard would be to back out a semi-applied overlay without some kind of core DT tracking support. Leaving it to the driver/user is too difficult to get right. About moving and renaming nodes, I can't think of a user-case today that needs it. Perhaps it can be handled by removal re-insertion? *with the caveat that not all types of changes are a good idea and we may disallow. For example, is changing properties in existing nodes a good idea? Yes, changing properties is something that we need. One such change is the change of the bus controller 'status' properties to enabled upon insertion of a child device node, and change back to 'on-demand' when all the child device nodes are gone. ** all this is based on my current ideas about the .dtb overlay format which would be trivial to implement, but I'm not committed to that approach just yet. The above problems could be solved. It may be sufficient to solve it by making the phandle values less volatile. Right now dtc generates phandles linearly. Generated phandles could be overridden with explicit phandle properties, but it isn't a fantastic solution. Perhaps generating the phandle from a hash of the node name would be sufficient. Node names don't have to be unique though right; perhaps hash the path-name instead of the node-name? But then, why not just reference by path name;
Re: [RFC] Device Tree Overlays Proposal (Was Re: capebus moving omap_devices to mach-omap2)
Hi Grant, On Nov 9, 2012, at 7:02 PM, Grant Likely wrote: On Wed, Nov 7, 2012 at 12:54 AM, Mitch Bradley w...@firmworks.com wrote: On 11/6/2012 12:37 PM, Stephen Warren wrote: This proposal is very oriented at an overlay-based approach. I'm not totally convinced that a pure overlay approach (as in how dtc does overlayed DT nodes) will be flexible enough, but would love to be persuaded. Again see below. An overlay approach will not be powerful enough to solve the sorts of problems that occur when a product goes into full production, becomes a family, and starts to evolve. Issues like second-source parts that aren't quite compatible and need to be detected and reported, board-stuff options for different customer profiles, speed grades of parts that aren't properly probeable but instead need to be identified by some subterfuge, the list of tedious issues goes on and on. It's nice to pretend that the world fits into a few coherent simple use cases, but 30 years of experience shipping computer product families proves otherwise. You need a programming language to solve the full set of problems - which I why the device tree is designed so it can be generated and modified by a program. I'm not going to argue with that. There is nothing saying that the overlay wouldn't be generated or applied by a script. However, I do strongly think that the data model needs to be independent of any tool or execution environment used to manipulate it. I certainly am not interested in encoding scripts or bytecode into the tree - the opposite of the approach used by ACPI which must execute AML to even retrieve the device tree. I like the overlay approach because it is conceptually straightforward and provides a working model of how changes could be made from userspace while still being usable by firmware. An alternate approach from userspace would be to use a live virtual filesystem to manipulate the device tree, though that approach only applies to Linux userspace. Firmware would still need its own approach. g. I completely agree here. I certainly wouldn't want to introduce any kind of bytecode or a programming model for manipulating DT. I know OF has a full blown forth interpreter, but that's not what modern DT should be (IMHO). Having DT provide such a programming model will preclude a number of users of accessing it, and on top of that, complexity will increase considerably. When faced with a new problem, vendors will just code a workaround, never bothering fixing it properly. In a nutshell, let's not turn DT into ACPI, please. Regards -- Pantelis -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] Device Tree Overlays Proposal (Was Re: capebus moving omap_devices to mach-omap2)
Hi Grant, On Nov 9, 2012, at 10:33 PM, Grant Likely wrote: On Wed, Nov 7, 2012 at 11:02 AM, Pantelis Antoniou pa...@antoniou-consulting.com wrote: On Nov 7, 2012, at 11:19 AM, Benoit Cousson wrote: Maybe some extra version match table can just be passed during the board machine_init of_platform_populate(NULL, omap_dt_match_table, NULL, NULL, panda_version_match_table); Would we need explicit of_platform_populate calls if we have node modification notifiers? In that case the notifier would pick it up automatically, and can do the per version matching internally. There still needs to be something to register everything below this node is interesting which is exactly what of_platform_populate() does now. I see the notifiers being used by the of_platform_populate backend to know when nodes have been created (or destroyed). g. I see. So of_platform_populate could just register the notifier and not do the tree walk itself. Perhaps the name is a bit misleading then? Regards -- Pantelis -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] Device Tree Overlays Proposal (Was Re: capebus moving omap_devices to mach-omap2)
Hi Grant, On Nov 9, 2012, at 11:22 PM, Grant Likely wrote: On Fri, Nov 9, 2012 at 5:32 AM, Joel A Fernandes agnel.j...@gmail.com wrote: Hi Pantelis, I hope I'm not too late to reply as I'm traveling. On Nov 6, 2012, at 5:30 AM, Pantelis Antoniou pa...@antoniou-consulting.com wrote: Joanne has purchased one of Jane's capes and packaged it into a rugged case for data logging. As far as Joanne is concerned, the BeagleBone and cape together are a single unit and she'd prefer a single monolithic FDT instead of using an FDT overlay. Option A: Using dtc, she uses the BeagleBone and cape .dts source files to generate a single .dtb for the entire system which is loaded by U-Boot. -or- Unlikely. Option B: Joanne uses a tool to merge the BeagleBone and cape .dtb files (instead of .dts files), -or- Possible but low probability. Option C: U-Boot loads both the base and overlay FDT files, merges them, and passes the resolved tree to the kernel. Could be made to work. Only really required if Joanne wants the cape interface to work for u-boot too. For example if the cape has some kind of network interface that u-boot will use to boot from. I love Grant's hashing idea a lot keeping the phandle problem for compile time and not requiring fixups. IMO it is still a cleaner approach if u-boot does the simple tree merging for all cases, and not the kernel reasons mentioned below. I'm more than sufficiently convinced that making changes at runtime from userspace is pretty much required. Also consider: it is order of magnitudes easier to modify the kernel than it is to change the firmware for end users. Complete agreement here. (1) From a development standpoint, very little or nothing will have to be changed in kernel (except for scripts/dtc) considering we are moving forward with hashing. (2) Also this discussed a while back but at some point is going to brought up again- loading of dt fragment directly from EEPROM and merging at run time. If we were to implement this in kernel, we would have to add cape specific EEPROM reading code, merge the tree before it is unflattened and parse. Unless it is required for boot to userspace I'm not considering merging before userspace starts. That's well after the tree is unflattened into the live form. If it is require to boot then I agree that is should be done in firmware. I see zero problem with having a beaglebone specific cape driver that knows to read the eeprom and request a specific configuration file. Heck, the kernel doesn't even need to parse the eeprom data. It can be read from userspace and userspace decides which overlay to provide. There's nothing stopping userspace from reading the eeprom, looking up the correct dts for the board, downloading the file from the Internet, compiling it with dtc and installing it and yes that is getting a little extreme. We're trying to come up with the method that will work best for us. From an ease of use perspective, having a kernel driver doing the probing and performing the DT fragment insertion looks the best. It's especially nice for the manufacturer, since he can make sure that when he ships a board a single kernel image will contain everything with no possibility of RMAs. For h/w prototyping, where the user is tinkering around with his own design, the user space approach would be best. The downloading over the internet DTS file, is a bit extreme for now :) I think doing tree merging in kernel is messy and we should do it in uboot considering we might have to read EEPROM for this use case. Ideally reading the fragment from the EEPROM for all capes and merging without worrying about version detection, Doing the merge and passing the merged blob to the kernel which (kernel) works the same way it does today. It may be sufficient to solve it by making the phandle values less volatile. Right now dtc generates phandles linearly. Generated phandles could be overridden with explicit phandle properties, but it isn't a fantastic solution. Perhaps generating the phandle from a hash of the node name would be sufficient. I doubt the hash method will work reliably. We only have 32 bits to work with, nothing like the SHA hashes of git. I was wondering I have worked with kernel's crypto code in the past to generate 32 bit md5sums of 1000s of dataitems, from what I've seen, collisions are rare and since we are talking about just a few nodes that are being referenced in the base dt. I think the probability is even less (ofcourse such an analysis strongly depends on dataset). this method also takes away a lot of complexity with having it to do runtime fixups and will help us get off the ground quickly. It wouldn't be hard to put together a test and run it on all the .dts files in the kernel; generating md5 sums for all the full_name paths and seeing if we've got any collisions yet. We can also
Re: [RFC] Device Tree Overlays Proposal (Was Re: capebus moving omap_devices to mach-omap2)
Hi Stephen,
On Nov 10, 2012, at 12:57 AM, Stephen Warren wrote:
On 11/08/2012 07:26 PM, David Gibson wrote:
...
I also think graft will handle most of your use cases, although as I
said I don't fully understand the implications of some of them, so I
could be wrong. So, the actual insertion of the subtree is pretty
trivial to implement. phandles are the obvious other matter to be
dealt with. I haven't found the right thread where what you've
envisaged so far is discussed, so here are things I can see:
1) Avoiding phandle collisions between main tree and subtree (or
between subtrees).
I'm hopeful that this can be resolved just by establishing some
conventions about the ranges of phandles to be used for various
components. I'd certainly be happy to add a directive to dtc which
enforces allocation of phandles within a specified range.
One case I wonder about is:
Base board A that's split into two .dts files e.g. due to there being
two versions of the base board which are 90% identical, yet there being
a few differences between them.
Base board B that's just a single .dts file.
We might allocate phandle range 0..999 for the base board.
Child board X plugs into either, so the two base boards need to export
the same set of phandle IDs to the child board to allow it to reference
them.
If base board A version 2 comes along after the phandle IDs that the
child board uses are defined, then how do we handle assigning a specific
phandle ID range to each of base board A's two version-specific
overlays, when the version-specific changes might affect arbitrary
phandle IDs within the range, and require some to be moved into the base
board version-specific overlays and some to stay in the common base
board .dts?
Static phandle allocation, could work, but not without considerable trouble.
Maybe we're over-engineering things. Perhaps having the kernel use the
phandle values generated by dtc is not required.
What about the following simple scheme:
1) Have dtc create local phandle values the same way, as it is today.
Generate the flat tree normally, but keep in a table the locations
of all phandle references. Keep track of non resolvable phandle references
in a different table. One could use the fixup mechanism I described in
a previous email, if you don't care about keeping a big table.
2) Upon loading the base DT or the overlay, the kernel makes sure the phandles
don't overlap; simply add a per DT fragment constant offset.
3) Resolve phandle references that were unresolved at compile time.
2) Resolving phandle references within a subtree
If we can handle (1) by convention, we don't need anything here, the
references are fine as is.
(3) Resolving phandle references from the subtree to the main tree.
So, I think this can actually be avoided, at least in cases where what
physical connections are available to the expansion module is well
defined. The main causes to have external references are interrupts
and gpios. Interrupts we handle by defining an interrupt specifier
space for the interrupts available on the expansion
socket/connector/bus/whatever. In the master tree we then have
something like:
...
expansion-socket@ {
expansion-id = SlotA;
interrupt-map = /* map expansion irq specs to
board interrupt controllers */ ;
interrupt-map-mask = ... ;
ranges = /* map expansion local addresses to global
mmio */ ;
};
We would end up needing an interrupt-map or ranges type of property for
basically any resource type.
For example, what about an I2C bus that's routed to the daughter board,
and the daughter board contains an I2C bus mux, whose control path isn't
through I2C but rather GPIOs? In this case, the I2C bus mux isn't a
child of the I2C bus, but a separate entity that indicates its parent
I2C bus using a phandle. I presume a similar argument applies to almost
any kind of resource. This is probably do-able, but certainly something
to consider with the socket approach. I do like the socket approach though.
Capebus has taken this approach.
You see, perhaps from the standpoint of the standard platform devices that
a cape provides, a bus is not a very fitting construct.
But from a hardware engineer/user perspective, a cape is an expansion board,
and virtual slots are used. This is similar to what you're saying
with socket approach, right?
Regards
-- Pantelis
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] Device Tree Overlays Proposal (Was Re: capebus moving omap_devices to mach-omap2)
Hi Stephen, On Nov 10, 2012, at 1:23 AM, Stephen Warren wrote: On 11/09/2012 09:28 AM, Grant Likely wrote: On Tue, Nov 6, 2012 at 10:37 PM, Stephen Warren swar...@wwwdotorg.org wrote: ... I do rather suspect this use-case is quite common. NVIDIA certainly has a bunch of development boards with pluggable PMIC/audio/WiFi/display/..., and I believe there's some ability to re-use the pluggable components with a variety of base-boards. Given people within NVIDIA started talking about this recently, I asked them to enumerate all the boards we have that support pluggable components, and how common it is that some boards support being plugged into different main boards. I don't know when that enumeration will complete (or even start) but hopefully I can provide some feedback on how common the use-case is for us once it's done. From your perspective, is it important to use the exact same .dtb overlays for those add-on boards, or is it okay to have a separate build of the overlay for each base tree? I certainly think it'd be extremely beneficial to use the exact same child board .dtb with arbitrary base boards. Oh yes. In fact if one was to use a single kernel image for beagleboard and beaglebone, for the cape to work for both, it is required for it's dtb to be compatible. We're not there yet, but people would like to have an upgrade path. beaglebone - beagleboard - pandaboard - future-boards It is not possible yet, but perhaps newer boards could have that. Consider something like the Arduino shield connector format, which I /believe/ has been re-used across a wide variety of Arduino boards and other compatible or imitation boards. Now consider a vendor of an Arduino shield. The shield vendor probably wants to publish a single .dtb file that works for users irrespective of which board they're using it with. (Well, I'm not sure that Arduino can run Linux; perhaps that's why you picked BeagleBone capes for your document!) Arduino can't possible do it. Using arduino shields with an adapter could be possible though. I suppose it would be acceptable for the shield vendor to ship the .dts file rather than the .dtb, and hence need to build the shield .dtb for a specific base board. However, I think the process for an end-user needs to be as simple as drop this .dts/.dtb file into some standard directory, and I imagine it'll be much easier for distros/... to make that process work if they're dealing with a .dtb that they can just blast into the kernel's firmware loader interface, rather than having to also locate the base-board .dts/.dtb file, and run dtc and/or other tools on both .dts files together. Yes. A single supported dtb is the way to go ideally. Regards -- Pantelis -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] Device Tree Overlays Proposal (Was Re: capebus moving omap_devices to mach-omap2)
Hi Joel, Again, sorry for the late reply due to travel. On Nov 10, 2012, at 5:36 AM, Joel A Fernandes wrote: Hi Pantelis, On Fri, Nov 9, 2012 at 2:13 AM, Pantelis Antoniou pa...@antoniou-consulting.com wrote: Option C: U-Boot loads both the base and overlay FDT files, merges them, and passes the resolved tree to the kernel. Could be made to work. Only really required if Joanne wants the cape interface to work for u-boot too. For example if the cape has some kind of network interface that u-boot will use to boot from. I love Grant's hashing idea a lot keeping the phandle problem for compile time and not requiring fixups. IMO it is still a cleaner approach if u-boot does the tree merging for all cases, and not the kernel. That way from a development standpoint, very little or nothing will have to be changed in kernel (except for scripts/dtc) considering we are moving forward with hashing. Also this discussed a while back but at some point is going to brought up again- loading of dt fragment directly from EEPROM and merging at run time. If we were to implement this in kernel, we would have to add cape specific EEPROM reading code, merge the tree before it is unflattened and parse. I think doing tree merging in kernel is messy and we should do it in uboot. Ideally reading the fragment from the EEPROM for all capes and merging without worrying about version detection, Doing the merge and passing the merged blob to the kernel which (kernel) works the same way it does today. Not going to work, for a lot of cases. Doing it in the kernel seems to be the cleaner option. There are valid use cases for doing in u-boot too. True, if dynamic runtime stuff from userspace is what we're talking about, then yeah I see the important need for kernel to do the merge. Kernel doing the merge is our use case, and I feel it's the use case of about 90% of users. u-boot doing the merge is the rest. Alternatively to hashing, reading david gibsons paper I followed, phandle is supposed to 'uniquely' identity node. I wonder why the node name itself is not sufficient to unquiely identify. The code that does the tree walking can then just strcmp the node name while it walks the tree instead of having to find a node with a phandle number. I guess the reason is phandles are small to store as data values. Another approach can be to arrange the string block in alphabetical order (unless it already is), and store phandle as index of the node name referenced relative to the starting of the strong block. This will not affect nodes in dtb being moved around since they will still have the same index value. the problem being adding or removing nodes Changes the offsets of all other nodes in the string block as well.. Hmm. This is pretty radical change to the DT format, no? Yes, true and the only way hypothetically to replace the phandle tree-walking mechanism is to store node paths instead of phandle which David pointed is too long to store, so I guess this wont work after all. Anyway this was an interesting exercise, thanks. It is always nice to have a fresh perspective. Thank you. Regards, Joel Regards -- Pantelis -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] Device Tree Overlays Proposal (Was Re: capebus moving omap_devices to mach-omap2)
Hi Rob. On Nov 11, 2012, at 10:47 PM, Rob Landley wrote: On 11/09/2012 10:28:59 AM, Grant Likely wrote: On Tue, Nov 6, 2012 at 10:37 PM, Stephen Warren swar...@wwwdotorg.org wrote: On 11/05/2012 01:40 PM, Grant Likely wrote: I'm not actually opposed to it, but it needs to be done in an elegant way. The DT data model already imposes more of a conceptual learning curve than I wish it did and I don't want to make that worse with a versioning model that is difficult to get ones head around. Speaking of which... I want to poke at board emulation in qemu, from scratch. Specifically, I want to start with an unpopulated board (just the processor), add a block of physical memory and a serial device, and boot an initramfs in there with stdin/stdout. Then I want to incrementally add an RTC, network card, and three block devices. I'd like to define this board by giving qemu and the kernel the same device tree they can parse, and I'd like to _build_ this device tree so I understand what's in it. I'd like to repeat this exercize for arm, mips, ppc, x86, x86-64, sparc, sh4, and maybe other boards. And I'd like to write up an article on doing it as a learning exercise. Last time I checked, doing this wasn't possible. (qemu couldn't define a board by parsing a device tree, the kernel used the device tree as a guideline but it only really read data the drivers you linked in were expecting, the only documentation about what any of the nodes were was was read the other device trees as examples or read the source code of the drivers looking for data in the tree...) Is it a more realistic project now? If so, where would I start? (Once upon a time I read the booting-without-of document, back when it lived in the ppc directory. It didn't really say what should go in any of the nodes.) Rob It should be possible when the stuff we're talking about is ready. I don't know what you'll find is broken during the exercise, but I guess your article is going to be entertaining at least :) Regards -- Pantelis -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] Device Tree Overlays Proposal (Was Re: capebus moving omap_devices to mach-omap2)
Hi Stephen, On Nov 12, 2012, at 6:49 PM, Stephen Warren wrote: On 11/12/2012 04:23 AM, Pantelis Antoniou wrote: Hi Grant, Sorry for the late comments, travelling... On Nov 9, 2012, at 6:28 PM, Grant Likely wrote: ... *with the caveat that not all types of changes are a good idea and we may disallow. For example, is changing properties in existing nodes a good idea? Yes, changing properties is something that we need. One such change is the change of the bus controller 'status' properties to enabled upon insertion of a child device node, and change back to 'on-demand' when all the child device nodes are gone. Do we actually need to do that? From the base-board perspective, consider an SoC's I2C channel that is routed to the child board connector. The routing to the connector is always present on the base board. Only the presence (or lack thereof) of devices on that I2C bus is influenced by whether a child board is connected or not, and the design of the child board. Therefore, wouldn't it make sense for the base board to always enable the I2C controller? That would make it easier for someone to hook up a couple wires to the I2C pins and use utilities such as i2cget/set to communicate with it, without going through the whole process of creating a DT to represent the device. This could speed up simple hacking/prototyping and allow it to proceed in a less structured way. Unfortunately that doesn't work for the beaglebone (am355x) and a large number of general purpose SoCs. What is different between general purpose SoCs and vertical market SoCs (i.e. OMAP) is that the design of the the latter is for devices where pretty much all the interfaces are expected to be active at the same time. General purpose SoCs put more peripherals in the SoC, but due to packaging considerations (and price), the peripheral pins are highly muxed. So the i2c bus pins are shared with the LCD controller are shared with the analog input and so on. It is impossible (and on top of that really dangerous) to enable peripheral blocks without knowing what's connected on the other side. In a nutshell, for the bone and similar devices, probing with the devices enabled doesn't work. Regards -- Pantelis -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] Device Tree Overlays Proposal (Was Re: capebus moving omap_devices to mach-omap2)
Hi Stephen, On Nov 12, 2012, at 7:10 PM, Stephen Warren wrote: On 11/12/2012 10:00 AM, Pantelis Antoniou wrote: Hi Stephen, On Nov 12, 2012, at 6:49 PM, Stephen Warren wrote: On 11/12/2012 04:23 AM, Pantelis Antoniou wrote: Hi Grant, Sorry for the late comments, travelling... On Nov 9, 2012, at 6:28 PM, Grant Likely wrote: ... *with the caveat that not all types of changes are a good idea and we may disallow. For example, is changing properties in existing nodes a good idea? Yes, changing properties is something that we need. One such change is the change of the bus controller 'status' properties to enabled upon insertion of a child device node, and change back to 'on-demand' when all the child device nodes are gone. Do we actually need to do that? From the base-board perspective, consider an SoC's I2C channel that is routed to the child board connector. The routing to the connector is always present on the base board. Only the presence (or lack thereof) of devices on that I2C bus is influenced by whether a child board is connected or not, and the design of the child board. Therefore, wouldn't it make sense for the base board to always enable the I2C controller? That would make it easier for someone to hook up a couple wires to the I2C pins and use utilities such as i2cget/set to communicate with it, without going through the whole process of creating a DT to represent the device. This could speed up simple hacking/prototyping and allow it to proceed in a less structured way. Unfortunately that doesn't work for the beaglebone (am355x) and a large number of general purpose SoCs. What is different between general purpose SoCs and vertical market SoCs (i.e. OMAP) is that the design of the the latter is for devices where pretty much all the interfaces are expected to be active at the same time. General purpose SoCs put more peripherals in the SoC, but due to packaging considerations (and price), the peripheral pins are highly muxed. So the i2c bus pins are shared with the LCD controller are shared with the analog input and so on. It is impossible (and on top of that really dangerous) to enable peripheral blocks without knowing what's connected on the other side. In a nutshell, for the bone and similar devices, probing with the devices enabled doesn't work. I think this can be solved by deferring the pinmux to the .dts for the child board. Presumably the I2C controller node can be enabled just fine, but the I2C signals not actually routed out to any pins on the SoC until the specific pinmux configuration is loaded. Well, I2C is just an example; same thing happens with SPI, LCD, audio, etc. So you'll end up hacking the device drivers to handle a weird state that basically means 'don't activate until I tell you to go'. It is simpler just not to create the device. But your explanation still feels a little odd; is it really true on the BeagleBone, you can either use LCD for graphics /or/ you can use the I2C controller to communicate with a cape? I certainly fully understand that from a SoC's perspective (and soc.dtsi perspective) you can't just enable everything due to pinmux constraints, but it seems that once you get to the level of a particular board design, the designer has made those trade-offs and so you know which specific combination is to be selected. There are multiple I2C busses, multiple SPI buses, multiple options to connect something that produces audio, and so on. It is not odd at the least for the kind of market these chips are for. Even TI doesn't know exactly the kind of applications these devices will be used for. The chip is there to provide connection option at a (cheap) price point. Think of a swiss-army knife with some tools that can be used at the same time, and some that can't. Regards -- Pantelis -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] Device Tree Overlays Proposal (Was Re: capebus moving omap_devices to mach-omap2)
Hi Stephen, On Nov 12, 2012, at 7:29 PM, Stephen Warren wrote: On 11/12/2012 10:19 AM, Pantelis Antoniou wrote: Hi Stephen, On Nov 12, 2012, at 7:10 PM, Stephen Warren wrote: On 11/12/2012 10:00 AM, Pantelis Antoniou wrote: Hi Stephen, On Nov 12, 2012, at 6:49 PM, Stephen Warren wrote: On 11/12/2012 04:23 AM, Pantelis Antoniou wrote: Hi Grant, Sorry for the late comments, travelling... On Nov 9, 2012, at 6:28 PM, Grant Likely wrote: ... *with the caveat that not all types of changes are a good idea and we may disallow. For example, is changing properties in existing nodes a good idea? Yes, changing properties is something that we need. One such change is the change of the bus controller 'status' properties to enabled upon insertion of a child device node, and change back to 'on-demand' when all the child device nodes are gone. Do we actually need to do that? From the base-board perspective, consider an SoC's I2C channel that is routed to the child board connector. The routing to the connector is always present on the base board. Only the presence (or lack thereof) of devices on that I2C bus is influenced by whether a child board is connected or not, and the design of the child board. Therefore, wouldn't it make sense for the base board to always enable the I2C controller? That would make it easier for someone to hook up a couple wires to the I2C pins and use utilities such as i2cget/set to communicate with it, without going through the whole process of creating a DT to represent the device. This could speed up simple hacking/prototyping and allow it to proceed in a less structured way. Unfortunately that doesn't work for the beaglebone (am355x) and a large number of general purpose SoCs. What is different between general purpose SoCs and vertical market SoCs (i.e. OMAP) is that the design of the the latter is for devices where pretty much all the interfaces are expected to be active at the same time. General purpose SoCs put more peripherals in the SoC, but due to packaging considerations (and price), the peripheral pins are highly muxed. So the i2c bus pins are shared with the LCD controller are shared with the analog input and so on. It is impossible (and on top of that really dangerous) to enable peripheral blocks without knowing what's connected on the other side. In a nutshell, for the bone and similar devices, probing with the devices enabled doesn't work. I think this can be solved by deferring the pinmux to the .dts for the child board. Presumably the I2C controller node can be enabled just fine, but the I2C signals not actually routed out to any pins on the SoC until the specific pinmux configuration is loaded. Well, I2C is just an example; same thing happens with SPI, LCD, audio, etc. So you'll end up hacking the device drivers to handle a weird state that basically means 'don't activate until I tell you to go'. It is simpler just not to create the device. But your explanation still feels a little odd; is it really true on the BeagleBone, you can either use LCD for graphics /or/ you can use the I2C controller to communicate with a cape? I certainly fully understand that from a SoC's perspective (and soc.dtsi perspective) you can't just enable everything due to pinmux constraints, but it seems that once you get to the level of a particular board design, the designer has made those trade-offs and so you know which specific combination is to be selected. There are multiple I2C busses, multiple SPI buses, multiple options to connect something that produces audio, and so on. It is not odd at the least for the kind of market these chips are for. Even TI doesn't know exactly the kind of applications these devices will be used for. The chip is there to provide connection option at a (cheap) price point. Think of a swiss-army knife with some tools that can be used at the same time, and some that can't. Yes, I fully understand the flexibility of the SoC; the NVIDIA Tegra SoC I maintain has exactly the same kind of flexibility. However, I'm still thining that presumably the pins that could be used for hypothetical example as any of (a) LCD, (b) I2C controller 2, (c) UART 3 have been routed to the cape-bus connector specifically for the purpose of e.g. I2C controller 2, and hence their usage has been locked in. Is that not the case? Is it instead true that some SoC pins are routed to both an LCD connector /and/ the cape-bus connector so the board itself has a usage conflict, or is it true that the cape-bus connector is in fact just a set of 100 random pins each with no specific pre-defined purpose, and it's up to the cape designer to pick the SoC's pinmux configuration rather than the base board designer? That would make the cape-bus pinout specific to the BeagleBone or the specific SoC on the board, which if IIUC is something very different to the Arduino shield pinout
Re: [RFC] Device Tree Overlays Proposal (Was Re: capebus moving omap_devices to mach-omap2)
Hi David, On Nov 9, 2012, at 3:26 AM, David Gibson wrote: On Mon, Nov 05, 2012 at 08:40:30PM +, Grant Likely wrote: Hey folks, As promised, here is my early draft to try and capture what device tree overlays need to do and how to get there. Comments and suggestions greatly appreciated. Device Tree Overlay Feature Hrm. So, you may yet convince me otherwise, but I'm really getting a feeling of overengineering from this proposal so far. Purpose === Sometimes it is not convenient to describe an entire system with a single FDT. For example, processor modules that are plugged into one or more modules (a la the BeagleBone), or systems with an FPGA peripheral that is programmed after the system is booted. For these cases it is proposed to implement an overlay feature for the so that the initial device tree data can be modified by userspace at runtime by loading additional overlay FDTs that amend the original data. User Stories [snip] The user stories mostly sound reasonable to me, but I don't know enough about the hardware in question to know what they'll mean in terms of what needs to be added to the base device tree. Summary points: - Create an FDT overlay data format and usage model - SHALL reliable resolve or validate of phandles between base and overlay trees So, I'm not at all clear on what this proposed phandle validation would involve. I'm also not convinced it's as necessary as you think, more on that below. [snip - lots of technical stuff] So, let me take a stab at this from a more bottom-up approach, and see if we meet in the middle somewhere. As I discussed in the other thread with Daniel Mack, I can see two different operationso on the fdt that might be useful in this context. I think of them as graft - which takes one fdt and adds it as a new subtree to an existing fdt - and overlay where a new fdt adds or overrides arbitrary properties in an existing tree. Overlay is more or less what we do at the source level in dtc already. Overlay is obviously more general - you can add, change and possibly delete any existing node or property. Graft can only add new nodes and properties, not modify existing ones. But that restriction comes with some advantages: reversing the operation is just a matter of deleting the subtree with no extra tracking info required. It's simple to see how to have rules or permissions about where subtrees can be grafted, and if the graft point is identified by a label or id, rather than full path, it automatically adapts to at least some changes in the base tree structure. I think graft is basically a safer operation, particular if we're doing this at runtime with userspace passing in these fdt fragments. In fact I'd go so far as to say if you really need the full overlay functionality, then you really ought to be working at the bootloader or early kernel load level to assemble the correct full device tree. And as Mitch says, an existing programming language (C, OFW Forth or whatever as you please) will serve you better for this sort of general manipulation than a limited template system. I also think graft will handle most of your use cases, although as I said I don't fully understand the implications of some of them, so I could be wrong. So, the actual insertion of the subtree is pretty trivial to implement. phandles are the obvious other matter to be dealt with. I haven't found the right thread where what you've envisaged so far is discussed, so here are things I can see: An overlay is more generic and can handle more complex cases. For our use case, a graft should work - with a few caveats. Due to the insertion/removal of the DT fragments other node's state change from 'disabled' - 'okay' and platform devices created or removed. This can be handled either via overlays, or via special casing it. 1) Avoiding phandle collisions between main tree and subtree (or between subtrees). I'm hopeful that this can be resolved just by establishing some conventions about the ranges of phandles to be used for various components. I'd certainly be happy to add a directive to dtc which enforces allocation of phandles within a specified range. Really doubtful IMHO. That will impose yet more structure on the DT syntax, and it will make it even more difficult for users. We're talking about users that do understand the hardware, but can't really grok linux kernel development. DT is used a structured h/w definition and seems to work just fine for these kind of users. 2) Resolving phandle references within a subtree If we can handle (1) by convention, we don't need anything here, the references are fine as is. (3) Resolving phandle references from the subtree to the main tree. So, I think this can actually be avoided, at least in cases where what physical connections are available to the expansion module is well defined. The main causes
Re: [RFC] Device Tree Overlays Proposal (Was Re: capebus moving omap_devices to mach-omap2)
Hi Grant, On Nov 6, 2012, at 9:45 PM, Grant Likely wrote: On Tue, Nov 6, 2012 at 7:34 PM, Pantelis Antoniou pa...@antoniou-consulting.com wrote: On Nov 6, 2012, at 12:14 PM, Grant Likely wrote: On Tue, Nov 6, 2012 at 10:30 AM, Pantelis Antoniou pa...@antoniou-consulting.com wrote: For hot-plugging, you need it. Whether kernel code can deal with large parts of the DT going away... How about we use the dead properties method and move/tag the removed modes as such, and not really remove them. Nodes already use krefs, and I'm thinking about making them kobjects so that they appear in sysfs and we'll have some tools to figure out when reference counts don't get decremented properly. From the little I've looked in the of code, and the drivers, it's going to be pretty bad. I don't think all users take references properly, and we have a big global lock for accessing the DT. I'm a lot more optimistic on this front... I wrote a patch today to make the change and took some measurements: On the versatile express qemu model I measured the free memory with /proc/device-tree, with /sys/device-tree, and with both. Here's what I found: /proc/device-tree only: 114776kB free /sys/device-tree only: 114792kB free both enabled: 114716kB free The back of a napkin calculation indicates that on this platform /proc/devicetree costs 76kB and /sys/device-tree costs 60kb. I'm happy to see that using /sys instead of /proc appears to be slightly cheaper which makes it easier to justify the change. The diffstat makes me even happier: arch/arm/plat-omap/Kconfig|1 - arch/powerpc/platforms/pseries/dlpar.c| 23 --- arch/powerpc/platforms/pseries/reconfig.c | 40 -- drivers/of/Kconfig|8 drivers/of/base.c | 116 drivers/of/fdt.c |5 ++- fs/proc/Makefile |1 - fs/proc/proc_devtree.c| 13 +- fs/proc/root.c|4 +- include/linux/of.h| 35 include/linux/proc_fs.h | 16 include/linux/string.h| 11 + 12 files changed, 107 insertions(+), 166 deletions(-) Interesting. Not so bad then. There are still a few odds and ends that need to be tidied up, but I'll get it out for review shortly. I've not touched the sparc code yet, and I need to take another look over the existing OF_DYNAMIC code. I think that CONFIG_OF_DYNAMIC will probably go away and the add node/property functions will get used by fdt.c and pdt.c for initial construction of the device tree. CONFIG_OF_DYNAMIC never made sense to me. Glad to see the config option gone. I'm not totally up to date with the -next dt stuff, but if we're there can we rename all the prom_ functions to something saner? Adding and removing nodes at runtime as part of the normal operation of the system (and not as something that happens once in a blue moon under controlled conditions) will uncover lots of bugs. I'm hoping so! Its time to clean that mess up. :-) Fortunately adding nodes is not where we're going to have problems. The problems will be on node removal. Addition-only at least means we can have something useful before hunting down and squashing all the bugs. I'll admit that removing nodes is going to be quite rare at least for me use cases. I did come across a couple of people that do hot-plugging (using something completely different) that could use it for sure. So let's think about locking too Yes, the locking does need to be sorted out. Perhaps come up with a dt-stress test tool/boot time validator? g. Regards -- Pantelis P.S. Lots of teeth grinding in the ELCE about the lack of a DT preprocessor. The pinctrl arguments have been mentioned more than once. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] Device Tree Overlays Proposal (Was Re: capebus moving omap_devices to mach-omap2)
Hi Grant On Nov 6, 2012, at 9:45 PM, Grant Likely wrote: On Tue, Nov 6, 2012 at 7:34 PM, Pantelis Antoniou pa...@antoniou-consulting.com wrote: [ snip ] g. Since we've started talking about longer term goals, and the versioning provision seems to stand, I hope we address how much the fragment versioning thing is similar to the way board revisions progress. If a versioning syntax is available then one could create a single DT file for a bunch of 'almost' similar board and board revisions. Using a single DTB in the same manner you have a single uImage would make some people quite happy, since you won't have to do any bootloader magic to make sure you pass the correct DTB for the specific revision. Regards -- Pantelis -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] Device Tree Overlays Proposal (Was Re: capebus moving omap_devices to mach-omap2)
Hi Stephen,
On Nov 6, 2012, at 11:37 PM, Stephen Warren wrote:
On 11/05/2012 01:40 PM, Grant Likely wrote:
Hey folks,
As promised, here is my early draft to try and capture what device
tree overlays need to do and how to get there. Comments and
suggestions greatly appreciated.
Interesting. This just came up internally at NVIDIA within the last
couple weeks, and was discussed on the U-Boot mailing list very recently
too:
http://lists.denx.de/pipermail/u-boot/2012-October/thread.html#138227
(it spills into the November archive too)
I am aware of this discussion. For our use case u-boot DT manipulation was
tried, but then abandoned. Asking our user base to modify anything in u-boot
was ruled out.
For these cases it is proposed to implement an overlay feature for the
so that the initial device tree data can be modified by userspace at
I don't know if you're maintaining this as a document and taking patches
to it, but if so:
for the so split across those two lines.
Jane solves this problem by storing an FDT overlay for each cape in the
root filesystem. When the kernel detects that a cape is installed it
reads the cape's eeprom to identify it and uses request_firmware() to
obtain the appropriate overlay. Userspace passes the overlay to the
kernel in the normal way. If the cape doesn't have an eeprom, then the
kernel will still use firmware_request(), but userspace needs to already
know which cape is installed.
As mentioned by Pantelis, multiple versions of a board is also very
common. We already have the following .dts files in the kernel where
this applies, for the main board even:
arch/arm/boot/dts/tegra30-cardhu.dtsi
arch/arm/boot/dts/tegra30-cardhu-a02.dts
arch/arm/boot/dts/tegra30-cardhu-a04.dts
Exactly. I've made this point in another email, but IMHO board-revision
management is exactly the same with cape revision management.
Ideally you'd like to get rid of those three, and replace it with only
one that's properly versioned.
Summary points:
- SHOULD reliably handle changes between different underlying overlays
(ie. what happens to existing .dtb overly files if the structure of
the dtb it is layered over changes. If not possible, then SHALL
detect when the base tree doesn't match and refuse to apply the
overlay.
Perhaps use (versioned) DT bindings to represent the interface between
the two .dts files? See the links to the U-Boot mailing list discussions
below?
- What is the model for overlays?
- Can an overlay modify existing properties?
- Can an overlay add new properties to existing nodes?
- Can an overlay delete existing nodes/properties?
This proposal is very oriented at an overlay-based approach. I'm not
totally convinced that a pure overlay approach (as in how dtc does
overlayed DT nodes) will be flexible enough, but would love to be
persuaded. Again see below.
It may be sufficient to solve it by making the phandle values less
volatile. Right now dtc generates phandles linearly. Generated phandles
could be overridden with explicit phandle properties, but it isn't a
fantastic solution. Perhaps generating the phandle from a hash of the
node name would be sufficient.
Node names don't have to be unique though right; perhaps hash the
path-name instead of the node-name? But then, why not just reference by
path name; similar to {/path/to/node} rather than label?
It would work for references to the known base DTS. If you have a
cape that's cross-device compatible that can simply fail.
I like this for it's simplicity though.
This handles many of the use cases, but it assumes that an overlay is
board specific. If it ever is required to support multiple base boards
with a single overlay file then there is a problem. The .dtb overlays
generated in this manor cannot handle different phandles or nodes that
are in a different place. On the other hand, the overlay source files
should have no problem being compiled for multiple targets.
s/manor/manner/
I do rather suspect this use-case is quite common. NVIDIA certainly has
a bunch of development boards with pluggable
PMIC/audio/WiFi/display/..., and I believe there's some ability to
re-use the pluggable components with a variety of base-boards.
Given people within NVIDIA started talking about this recently, I asked
them to enumerate all the boards we have that support pluggable
components, and how common it is that some boards support being plugged
into different main boards. I don't know when that enumeration will
complete (or even start) but hopefully I can provide some feedback on
how common the use-case is for us once it's done.
My earlier thoughts on how to support this included explicit
inter-board/-component connector objects in the .dts files that allow
renaming of GPIOs, I2C buses, regulators, etc.:
http://lists.denx.de/pipermail/u-boot/2012-October/138476.html
Re: [RFC] Device Tree Overlays Proposal (Was Re: capebus moving omap_devices to mach-omap2)
Hi Benoit,
On Nov 7, 2012, at 11:19 AM, Benoit Cousson wrote:
Hi Panto,
On 11/07/2012 09:13 AM, Pantelis Antoniou wrote:
Hi Grant
On Nov 6, 2012, at 9:45 PM, Grant Likely wrote:
On Tue, Nov 6, 2012 at 7:34 PM, Pantelis Antoniou
pa...@antoniou-consulting.com wrote:
[ snip ]
g.
Since we've started talking about longer term goals, and the versioning
provision seems to stand, I hope we address how much the fragment versioning
thing is similar to the way board revisions progress.
If a versioning syntax is available then one could create a single DT
file for a bunch of 'almost' similar board and board revisions.
I even think that the version issue is probably much more important for the
short term than the overlay aspect. Well at least as important. We start
having as well a bunch a panda board version with different HW setup.
Having a single board-XXX.dts that will support all these versions is
probably the best approach to avoid choosing that from the bootloader.
We need to figure out a format + mechanism compatible with the current
non-versioned format to allow filtering the nodes at runtime to keep only the
relevant one.
Something that can find the driver that will provide the proper board version
or subsystem version or whatever like that:
compatible-version = ti,panda-version, panda;
Then at runtime we should create only the node with the correct match between
the driver version and the string version.
This is exactly what we need. FWIW the capebus syntax is a little bit different.
/* regular panda audio routing */
sound: sound {
compatible = ti,abe-twl6040;
ti,model = PandaBoard;
compatible-version = ti,panda-version, panda;
/* Audio routing */
ti,audio-routing =
Headset Stereophone, HSOL,
Headset Stereophone, HSOR,
Ext Spk, HFL,
Ext Spk, HFR,
Line Out, AUXL,
Line Out, AUXR,
HSMIC, Headset Mic,
Headset Mic, Headset Mic Bias,
AFML, Line In,
AFMR, Line In;
};
/* Audio routing is different between PandaBoard4430 and PandaBoardES */
sound {
ti,model = PandaBoardES;
compatible-version = ti,panda-version, panda-es;
/* Audio routing */
ti,audio-routing =
Headset Stereophone, HSOL,
Headset Stereophone, HSOR,
Ext Spk, HFL,
Ext Spk, HFR,
Line Out, AUXL,
Line Out, AUXR,
AFML, Line In,
AFMR, Line In;
};
We use this syntax for capebus (totally non-standard of-course),
sound: sound {
compatible = ti,abe-twl6040;
model@0 {
ti,model = PandaBoard;
ti,audio-routing =
Headset Stereophone, HSOL,
Headset Stereophone, HSOR,
Ext Spk, HFL,
Ext Spk, HFR,
Line Out, AUXL,
Line Out, AUXR,
HSMIC, Headset Mic,
Headset Mic, Headset Mic Bias,
AFML, Line In,
AFMR, Line In;
};
model@1 {
ti,model = PandaBoardES;
ti,audio-routing =
Headset Stereophone, HSOL,
Headset Stereophone, HSOR,
Ext Spk, HFL,
Ext Spk, HFR,
Line Out, AUXL,
Line Out, AUXR,
AFML, Line In,
AFMR, Line In;
};
/* common properties for either model */
};
The difference is that you don't get to repeat the common properties.
I don't know if this breaks any conventions but seems to work fine for our case.
Maybe some extra version match table can just be passed during the board
machine_init
of_platform_populate(NULL, omap_dt_match_table, NULL, NULL,
panda_version_match_table);
Would we need explicit of_platform_populate calls if we have node modification
notifiers?
In that case the notifier would pick it up automatically, and can do the per
version matching internally.
Regards,
Benoit
Regards
-- Pantelis
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] Device Tree Overlays Proposal (Was Re: capebus moving omap_devices to mach-omap2)
Hi Benoit, On Nov 7, 2012, at 12:12 PM, Benoit Cousson wrote: On 11/07/2012 12:02 PM, Pantelis Antoniou wrote: Hi Benoit, [snip] I don't know if this breaks any conventions but seems to work fine for our case. Yeah, my main concern with that approach is that you change the structure of the tree by adding an extra node/hierarchy that will not be there in case of non-versioned tree. That's why I think we should have something lighter that will not change the structure. Ideally we should be able to add extra versioned node to the original dts without changing it at all. You will still need the versioned nodes to be injected to the non-versioned ones. FWIW the driver will use the standard of_property_read_* interface. You can patch of_property_read to hide the version node matching, and it will work. I'll leave Grant answer what approach is better, I don't claim to have the insight to handle all cases. Maybe some extra version match table can just be passed during the board machine_init of_platform_populate(NULL, omap_dt_match_table, NULL, NULL, panda_version_match_table); Would we need explicit of_platform_populate calls if we have node modification notifiers? In that case the notifier would pick it up automatically, and can do the per version matching internally. Yes indeed, but here I was thinking about an intermediate step, i.e. now, without any dynamic node insertion mechanism. Thanks to this simple approach, when can already fix the board versionning problem. As I pointed, with a kind of injection mechanism. the versioned node contents end up in the proper place in the device tree. Your method will work in a much more simpler way. Regards, Benoit Regards -- Pantelis -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] Device Tree Overlays Proposal (Was Re: capebus moving omap_devices to mach-omap2)
Hi Stephen, On Nov 7, 2012, at 6:18 PM, Stephen Warren wrote: On 11/07/2012 01:47 AM, Pantelis Antoniou wrote: Hi Stephen, On Nov 6, 2012, at 11:37 PM, Stephen Warren wrote: On 11/05/2012 01:40 PM, Grant Likely wrote: Hey folks, As promised, here is my early draft to try and capture what device tree overlays need to do and how to get there. Comments and suggestions greatly appreciated. Interesting. This just came up internally at NVIDIA within the last couple weeks, and was discussed on the U-Boot mailing list very recently too: http://lists.denx.de/pipermail/u-boot/2012-October/thread.html#138227 (it spills into the November archive too) I am aware of this discussion. For our use case u-boot DT manipulation was tried, but then abandoned. Asking our user base to modify anything in u-boot was ruled out. For these cases it is proposed to implement an overlay feature for the so that the initial device tree data can be modified by userspace at I don't know if you're maintaining this as a document and taking patches to it, but if so: for the so split across those two lines. Jane solves this problem by storing an FDT overlay for each cape in the root filesystem. When the kernel detects that a cape is installed it reads the cape's eeprom to identify it and uses request_firmware() to obtain the appropriate overlay. Userspace passes the overlay to the kernel in the normal way. If the cape doesn't have an eeprom, then the kernel will still use firmware_request(), but userspace needs to already know which cape is installed. As mentioned by Pantelis, multiple versions of a board is also very common. We already have the following .dts files in the kernel where this applies, for the main board even: arch/arm/boot/dts/tegra30-cardhu.dtsi arch/arm/boot/dts/tegra30-cardhu-a02.dts arch/arm/boot/dts/tegra30-cardhu-a04.dts Exactly. I've made this point in another email, but IMHO board-revision management is exactly the same with cape revision management. Ideally you'd like to get rid of those three, and replace it with only one that's properly versioned. I don't expect we would ever get rid of some of those .dts files; there is after all a common subset that applies to all boards, and an incremental difference that applies to only A02/3, and another for A04/5/... Representing those as separate source files seems appropriate to me. If we try and dump all the multiple versions into a single file with some markup indicating which version of the board some sub-sections of the .dts apply to, I think we'll end up with rather complex .dts files. In this case, the simple overlay model works extremely well. If that's your use case, fine. We're not really trying to impose any special format for the DT files. We think that for our use cases a single DT works better, not so much from the developer point of view but from the users. A single DT is much easier to support, especially for users that aren't so great at boot-loader option juggling. Regards -- Pantelis -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] Device Tree Overlays Proposal (Was Re: capebus moving omap_devices to mach-omap2)
Hi Stephen,
On Nov 7, 2012, at 6:25 PM, Stephen Warren wrote:
On 11/07/2012 03:19 AM, Benoit Cousson wrote:
Hi Panto,
On 11/07/2012 09:13 AM, Pantelis Antoniou wrote:
Hi Grant
On Nov 6, 2012, at 9:45 PM, Grant Likely wrote:
On Tue, Nov 6, 2012 at 7:34 PM, Pantelis Antoniou
pa...@antoniou-consulting.com wrote:
[ snip ]
g.
Since we've started talking about longer term goals, and the versioning
provision seems to stand, I hope we address how much the fragment versioning
thing is similar to the way board revisions progress.
If a versioning syntax is available then one could create a single DT
file for a bunch of 'almost' similar board and board revisions.
I even think that the version issue is probably much more important for the
short term than the overlay aspect. Well at least as important. We start
having as well a bunch a panda board version with different HW setup.
Having a single board-XXX.dts that will support all these versions is
probably the best approach to avoid choosing that from the bootloader.
We need to figure out a format + mechanism compatible with the current
non-versioned format to allow filtering the nodes at runtime to keep only
the relevant one.
Something that can find the driver that will provide the proper board
version or subsystem version or whatever like that:
compatible-version = ti,panda-version, panda;
Then at runtime we should create only the node with the correct match
between the driver version and the string version.
/* regular panda audio routing */
sound: sound {
compatible = ti,abe-twl6040;
ti,model = PandaBoard;
compatible-version = ti,panda-version, panda;
/* Audio routing */
ti,audio-routing =
Headset Stereophone, HSOL,
Headset Stereophone, HSOR,
Ext Spk, HFL,
Ext Spk, HFR,
Line Out, AUXL,
Line Out, AUXR,
HSMIC, Headset Mic,
Headset Mic, Headset Mic Bias,
AFML, Line In,
AFMR, Line In;
};
/* Audio routing is different between PandaBoard4430 and PandaBoardES */
sound {
ti,model = PandaBoardES;
compatible-version = ti,panda-version, panda-es;
/* Audio routing */
ti,audio-routing =
Headset Stereophone, HSOL,
Headset Stereophone, HSOR,
Ext Spk, HFL,
Ext Spk, HFR,
Line Out, AUXL,
Line Out, AUXR,
AFML, Line In,
AFMR, Line In;
};
Maybe some extra version match table can just be passed during the board
machine_init
of_platform_populate(NULL, omap_dt_match_table, NULL, NULL,
panda_version_match_table);
Is the only difference here the content of the ti,audio-routing
property? If so, then I don't think there's any need for infra-structure
for this; the driver code already reads that property and adjusts its
behaviour based upon it.
I do see that Headset Mic exists only in one of the tables above.
Perhaps the driver could scan the routing table, and only create the
ASoC object for the headset if it's mentioned in the routing table?
If there are additional differences, then you can always use the .data
field in of_device_id to automatically associate some configuration data
with different compatible values.
Even better might be to extend the binding so that all HW differences
are represented explicitly as properties; that way you wouldn't even
need different compatible values.
I think that perhaps the choice of the SoC specific driver was unfortunate.
There are cases where a standard driver should be configured differently
depending on the board revision/model. In that case per-revision
driver changes are out of the question.
Regards
-- Pantelis
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/3] capebus moving omap_devices to mach-omap2
Hi Joel, On Nov 6, 2012, at 4:06 AM, Joel A Fernandes wrote: Hi Grant, On Mon, Nov 5, 2012 at 5:58 PM, Grant Likely grant.lik...@secretlab.ca wrote: Joel A Fernandes agnel.j...@gmail.com wrote: Hi Grant, On Mon, Nov 5, 2012 at 2:14 PM, Grant Likely grant.lik...@secretlab.ca wrote: I'm open to suggestions if anyone has any. I have not objections to a fixup approach, but I'm not comfortable with anything that is fragile to modifications to the fragment. I am fairly new to the DT world so please bear with me, but how about a method that resolves symbols the same way that the linux dynamic linker does when shared libraries are loaded? A separate table (similar to .PLT/GOT sections in the ELF object format) could be created when the fragment is loaded, and the phandle references could be fixed to point to the table offsets during compile time. This table would be a second level indirection and the kernel would populate this table with the in-kernel values of the phandles that the dt fragment refers to. That's an interesting idea that is worth exploring. That would make it possible to avoid a fixup stage, but it also means that any parsing code must know how to handle the got-like table. It won't be backwards compatible with existing tools. It also wouldn't easily support the case of firmware applying the overlay and passing the resulting tree to the kernel. Hmmm Not being backwards compatible at the data level is a big problem. I really want a method that can resolve back to the current data format or is a compatible extension of it. Is it meaningful or feasible to make the table a part of the tree structure itself? the table would initially be empty. If I'm right, this is how the GOT tables in ELF objects that refer to unresolved symbols in shared libraries are implemented as well, they are a part of the object and are loaded into memory and fixed up. If the table is a part of the DT data, the tools would then be able to parse such a tree. We could enforce that the got-like tree would strictly follow a predefined format. Something along these lines would also avoid the need for a tree fix up. Do you think this reduces the difficulty of backward compatibility with the parsing tools and firmware loading? To be honest here, we are discussing a new object format. There are a few twists IMO. a) We definitely, absolutely, don't want to introduce anything that will risk compatibility with devices already out there. The binary format for device trees that don't need the dynamic resolution features we're talking about here, should be be usable for those older devices. b) Device tree is flexible enough to store the additional data in it's own node format. So we shouldn't have any kind of binary data tacked on; this ties with a) - make sure that the binary format doesn't change. c) There is no need (at least AFAIKT) of having any other resolution type than a phandle of a node. d) Finally, for some use-cases the problem is simplified by not having all the features of a true dynamic linker. For example for the capebus case the 'base' DTS won't have any references to any fragments. It is only the fragments that have unresolved references and only to the 'base' DTS. This might involve changes to the DT core, but as such, this method wouldn't suffer from the fragility problem of either base or fragment DT trees being modified. The table itself could be added to the tree by the compiler, and the phandles could point to it (fixed). such phandles could be marked for special handling to facilitate the 1-level indirection. That's part of the problem. Property values are essentially anaonymous data. There is no mechanism currently for marking data such as indicate which data values are phandles. If there were then it would be a simple matter to find all the phandles and fix them up. We could possibly add data type suppplementary properties to the tree to solve that problem. They would have to be optional for the base tree to retain backwards compatibility, but could be required on overlays. Sure, so if we add data type supplementary properties to the tree to indicate the data type as indirect phandle, then kernel could refer to the index in the got-like table to fetch the actual phandle address (1-level of indirection), instead of directly using the address in the data field. I'm fine with this. Thanks and Regards, Joel Regards -- Pantelis -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] Device Tree Overlays Proposal (Was Re: capebus moving omap_devices to mach-omap2)
Hi Grant, On Nov 5, 2012, at 9:40 PM, Grant Likely wrote: Hey folks, As promised, here is my early draft to try and capture what device tree overlays need to do and how to get there. Comments and suggestions greatly appreciated. Device Tree Overlay Feature Purpose === Sometimes it is not convenient to describe an entire system with a single FDT. For example, processor modules that are plugged into one or more modules (a la the BeagleBone), or systems with an FPGA peripheral that is programmed after the system is booted. For these cases it is proposed to implement an overlay feature for the so that the initial device tree data can be modified by userspace at runtime by loading additional overlay FDTs that amend the original data. User Stories Note - These are potential use cases, but just because it is listed here doesn't mean it is important. I just want to thoroughly think through the implications before making design decisions. Jane is building custom BeagleBone expansion boards called 'capes'. She can boot the system with a stock BeagleBoard device tree, but additional data is needed before a cape can be used. She could replace the FDT file used by U-Boot with one that contains the extra data, but she uses the same Linux system image regardless of the cape, and it is inconvenient to have to select a different device tree at boot time depending on the cape. Jane solves this problem by storing an FDT overlay for each cape in the root filesystem. When the kernel detects that a cape is installed it reads the cape's eeprom to identify it and uses request_firmware() to obtain the appropriate overlay. Userspace passes the overlay to the kernel in the normal way. If the cape doesn't have an eeprom, then the kernel will still use firmware_request(), but userspace needs to already know which cape is installed. Jane is a really productive hardware engineer - she manages to fix a number of problems with her cape design by spinning different revisions of the cape. Using the flexibility that the DT provides, documents and defines the hardware changes of the cape revisions in the FDT overlay. The loader matches the revision of the cape with the proper FDT overlay so that the drivers are relieved of having to do revision management. Nigel is building a real-time video processing system around a MIPS SoC and a Virtex FPGA. Video data is streamed through the FPGA for post processing operations like motion tracking or compression. The FPGA is configured via the SPI bus, and is also connected to GPIO lines and the memory mapped peripheral bus. Nigel has designed several FPGA configurations for different video processing tasks. The user will choose which configuration to load which can even be reprogrammed at runtime to switch tasks. Each FPGA has a different interface to the processor, so the kernel needs additional data before it can use each device. Nigel is passing that data to the kernel using an FDT overlay. When Linux loads a new FPGA configuration, it uses request_firmare() to obtain the overlay for that FPGA. When the FPGA gets reprogrammed, the kernel throws away the previous overlay data and uses request_firmware() to get the overlay for the new design. Mandy has a Raspberry Pi which she has wired by hand up to sensors and motor controllers in her prototype autonomous robot project. She is doing self-hosted driver development on the Raspberry Pi itself. However, she needs a method to tell the kernel about the attached devices. By installing dtc on the Pi, Mandy compiles the overlay for her prototype hardware. However, she doesn't have a copy of the Pi's original FDT source, so instead she uses the dtc 'fs' input format to compile the overlay file against the live DT data in /proc. Jane (the cape designer) can use this too. Developing the cape, she really appreciates that she doesn't have to reboot every time she makes a change in the cape hardware. By removing the FDT overlay, compiling with the dtc on the board, and re-inserting the overlay, she can be more productive by waiting less. Johnny, Jane's little son, doesn't know anything about device trees, linux kernel trees, or hard-core s/w engineering. He is a bright kid, and due to the board having a node.js based educational electronic design kit, he can use the web-based simplified development environment, that allows him graphically to connect the parts in his kit. He can save the design and the IDE creates on the fly the DT overlay for later use. Amit is writing kernel drivers for Jane's BeagleBone capes, but he finds loading new DT files into the root filesystem inconvenient. Instead, he includes the FDT overlay file in the initramfs that is built and linked in at kernel compile time so that the kernel can find and load overlays automatically. Joanne has purchased one of Jane's capes and packaged it into a rugged case for data
Re: [RFC] Device Tree Overlays Proposal (Was Re: capebus moving omap_devices to mach-omap2)
Hi Timur, On Nov 5, 2012, at 10:40 PM, Tabi Timur-B04825 wrote: On Mon, Nov 5, 2012 at 2:40 PM, Grant Likely grant.lik...@secretlab.ca wrote: Jane is building custom BeagleBone expansion boards called 'capes'. She can boot the system with a stock BeagleBoard device tree, but additional data is needed before a cape can be used. She could replace the FDT file used by U-Boot with one that contains the extra data, but she uses the same Linux system image regardless of the cape, and it is inconvenient to have to select a different device tree at boot time depending on the cape. What's wrong with having the boot loader detect the presence of the Cape and update the device tree accordingly? We do this all the time in U-Boot. Doing stuff like reading EEPROMs and testing for the presence of hardware is easier in U-Boot than in Linux. For configurations that can be determined by the boot loader, I'm not sure overlays are practical. Each use case is different. For our use-cases boot loader DT modifications just won't work. What's nice about the stuff we're talking about is that if you don't use the new functionality, nothing changes for you. Go on and use DT the old way if you'd like. Nigel is building a real-time video processing system around a MIPS SoC and a Virtex FPGA. Video data is streamed through the FPGA for post processing operations like motion tracking or compression. The FPGA is configured via the SPI bus, and is also connected to GPIO lines and the memory mapped peripheral bus. Nigel has designed several FPGA configurations for different video processing tasks. The user will choose which configuration to load which can even be reprogrammed at runtime to switch tasks. Now this, on the other hand, makes more sense. If the hardware configuration is literally user-configurable, then okay. However, I'm not sure I see the need to update the device tree. The device tree is generally for hardware that cannot be discovered/probed by the device driver. If we're loading a configuration from user space, doesn't the driver already know what the hardware's capabilities are, since it's the one doing the uploading of a new FPGA code? Why not skip the device tree update and just tell the driver what the new capabilities are? -- Timur Tabi Linux kernel developer at Freescale Regards -- Pantelis -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/3] capebus moving omap_devices to mach-omap2
Από το iPhone μου 6 Νοε 2012, 12:16, ο/η Grant Likely grant.lik...@secretlab.ca έγραψε: On Tue, Nov 6, 2012 at 8:14 AM, Pantelis Antoniou pa...@antoniou-consulting.com wrote: On Nov 6, 2012, at 4:06 AM, Joel A Fernandes wrote: Sure, so if we add data type supplementary properties to the tree to indicate the data type as indirect phandle, then kernel could refer to the index in the got-like table to fetch the actual phandle address (1-level of indirection), instead of directly using the address in the data field. I'm fine with this. But if the data about phandles is already in the tree, then the need for a GOT simply goes away. The phandles can be fixed up directly and it is so much better because it works with existing parsing code after the merge is applied. Either way works. It is your call after all. I agree that your method is simpler. g. Regards -- Pantelis-- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] Device Tree Overlays Proposal (Was Re: capebus moving omap_devices to mach-omap2)
Hi Grant, On Nov 6, 2012, at 12:14 PM, Grant Likely wrote: On Tue, Nov 6, 2012 at 10:30 AM, Pantelis Antoniou pa...@antoniou-consulting.com wrote: Hi Grant, On Nov 5, 2012, at 9:40 PM, Grant Likely wrote: Hey folks, As promised, here is my early draft to try and capture what device tree overlays need to do and how to get there. Comments and suggestions greatly appreciated. Device Tree Overlay Feature Purpose === Sometimes it is not convenient to describe an entire system with a single FDT. For example, processor modules that are plugged into one or more modules (a la the BeagleBone), or systems with an FPGA peripheral that is programmed after the system is booted. For these cases it is proposed to implement an overlay feature for the so that the initial device tree data can be modified by userspace at runtime by loading additional overlay FDTs that amend the original data. User Stories Note - These are potential use cases, but just because it is listed here doesn't mean it is important. I just want to thoroughly think through the implications before making design decisions. Jane is building custom BeagleBone expansion boards called 'capes'. She can boot the system with a stock BeagleBoard device tree, but additional data is needed before a cape can be used. She could replace the FDT file used by U-Boot with one that contains the extra data, but she uses the same Linux system image regardless of the cape, and it is inconvenient to have to select a different device tree at boot time depending on the cape. Jane solves this problem by storing an FDT overlay for each cape in the root filesystem. When the kernel detects that a cape is installed it reads the cape's eeprom to identify it and uses request_firmware() to obtain the appropriate overlay. Userspace passes the overlay to the kernel in the normal way. If the cape doesn't have an eeprom, then the kernel will still use firmware_request(), but userspace needs to already know which cape is installed. Jane is a really productive hardware engineer - she manages to fix a number of problems with her cape design by spinning different revisions of the cape. Using the flexibility that the DT provides, documents and defines the hardware changes of the cape revisions in the FDT overlay. The loader matches the revision of the cape with the proper FDT overlay so that the drivers are relieved of having to do revision management. Okay By installing dtc on the Pi, Mandy compiles the overlay for her prototype hardware. However, she doesn't have a copy of the Pi's original FDT source, so instead she uses the dtc 'fs' input format to compile the overlay file against the live DT data in /proc. Jane (the cape designer) can use this too. Developing the cape, she really appreciates that she doesn't have to reboot every time she makes a change in the cape hardware. By removing the FDT overlay, compiling with the dtc on the board, and re-inserting the overlay, she can be more productive by waiting less. Yes, but I'll leave this paragraph out of the spec. It isn't significantly different from what is already there. No problem. Johnny, Jane's little son, doesn't know anything about device trees, linux kernel trees, or hard-core s/w engineering. He is a bright kid, and due to the board having a node.js based educational electronic design kit, he can use the web-based simplified development environment, that allows him graphically to connect the parts in his kit. He can save the design and the IDE creates on the fly the DT overlay for later use. Yes. Joanne has purchased one of Jane's capes and packaged it into a rugged case for data logging. As far as Joanne is concerned, the BeagleBone and cape together are a single unit and she'd prefer a single monolithic FDT instead of using an FDT overlay. Option A: Using dtc, she uses the BeagleBone and cape .dts source files to generate a single .dtb for the entire system which is loaded by U-Boot. -or- Unlikely. Option B: Joanne uses a tool to merge the BeagleBone and cape .dtb files (instead of .dts files), -or- Possible but low probability. Option C: U-Boot loads both the base and overlay FDT files, merges them, and passes the resolved tree to the kernel. Could be made to work. Only really required if Joanne wants the cape interface to work for u-boot too. For example if the cape has some kind of network interface that u-boot will use to boot from. Unlikely for your focus perhaps, but I'm trying to capture all the relevant permutations, and I can guarantee that some people really will want this. If not on the bone, then on some other platform. No problem there. Certainly they are valid scenarios. Summary points: - Create an FDT overlay data format and usage model - SHALL reliable resolve or validate of phandles between base and overlay trees - SHOULD reliably
Re: [RFC] Device Tree Overlays Proposal (Was Re: capebus moving omap_devices to mach-omap2)
Hi Russ,
On Nov 6, 2012, at 8:29 PM, Russ Dill wrote:
On Tue, Nov 6, 2012 at 10:35 AM, Tony Lindgren t...@atomide.com wrote:
* Grant Likely grant.lik...@secretlab.ca [121106 03:16]:
On Tue, Nov 6, 2012 at 10:30 AM, Pantelis Antoniou
pa...@antoniou-consulting.com wrote:
Another can of worms is the pinctrl nodes.
Yes... new pinctrl data would need to trigger adding new data to
pinctrl. I don't know if the pinctrl api supports that.
The actual pins stay the same, just their configuration
changes. AFAIK all that is already supported using the
pinctrl framework.
For example, considering hotplugging capes on the beaglebone:
1. You need to map all the sensible modes for the pins exposed
to the capes in the board specific .dts file. This will
add roughly 4 x nr_capbus_pins named modes in the .dts file
so not too bad.
2. Claim all the capebus pins during the capbus driver probe
and set them to some safe mode.
3. Try to detect the connected cape(s) over i2c.
4. Use pinctr_select_state to set the desired modes for
the pins used by the cape(s).
5. Enable capebus regulators and clocks etc.
6. Load the driver modules for whatever omap internal
devices the cape supports.
You could also claim the pin for the omap internal
devices instead of claiming them in the capebus, but then
things can get messy with binding and unbinding the
drivers. So just claiming all the pins in the capebus
probably keeps things simpler.
That assumes that for a particular external bus, certain pins aren't
already shared with functions already on the board, for instance if an
I²C bus brought out to the external bus already has a chip connected
to it.
This is our case on the bone. We don't enable the peripheral until
a cape that references it is enabled.
I don't think that very big changes are going to be needed TBH.
So now we use:
am3358_pinmux: pinmux@44e10800 {
bone_dvi_cape_led_pins: pinmux_bone_dvi_cape_led_pins {
pinctrl-single,pins =
0x48 0x07 /* gpmc_a2.gpio1_18, OUTPUT |
MODE7 */
0x4c 0x07 /* gpmc_a3.gpio1_19, OUTPUT |
MODE7 */
;
};
};
And in the cape definition:
pinctrl-0 = bone_geiger_cape_pins;
Ideally if we could do this in the cape definition:
cape_pinmux {
parent = am3358_pinmux;
bone_dvi_cape_led_pins: pinmux_bone_dvi_cape_led_pins {
pinctrl-single,pins =
0x48 0x07 /* gpmc_a2.gpio1_18, OUTPUT |
MODE7 */
0x4c 0x07 /* gpmc_a3.gpio1_19, OUTPUT |
MODE7 */
;
};
pinctrl-0 = bone_geiger_cape_pins;
It would be just fine.
Regards
-- Pantelis
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
