From: Jason Kridner <hidden> Date: 2014-06-16 13:22:50
Adding devicetree and linux-arm-kernel lists based on feedback on IRC...
On Tue, Jun 10, 2014 at 12:46 PM, Jason Kridner [off-list ref] wrote:
I'd like to discuss moving our current library of cape devicetree
overlay sources into a single tree, including the boot .dtb files for
BeagleBoard.org boards and moving towards enabling as much of the cape
support into a single boot-time .dtb file with an approach similar to
the cape-universal overlay
(https://github.com/cdsteinkuehler/beaglebone-universal-io), but not
in an overlay.
First of all, I want to note this doesn't change my view on the
importance of mainline support for devicetree overlays. They are still
absolutely critical and highly useful, solving problems that cannot be
solved through boot-time devicetrees. I'm simply looking for an
approach that will complement the availability of overlays and provide
the best user experience.
Robert has been talking about the actions required to clean-up Debian
Jessie support in another thread
(https://groups.google.com/d/msg/beagleboard/2b8rArtfABY/A8d1JzmJa4IJ)
and I suggested we should add a bit of a detour by cleaning up the
cape support for the mainline kernel and switching away our primary
process of supporting capes from using overlays to using a single
devicetree file provided at boot. I promised a pull-request and hadn't
gotten around to sending it until now (below). No architecture changes
have been made in my pull-request, just bringing in the kernel
devicetree source history. This suggestion is based on several
assumptions, any number of which might be wrong.
The assumptions (for which I'm looking for feedback/corrections):
* The overlays pretty much all need to be compiled into the kernel if
they are going to be loaded using kernel command-line arguments or
/etc/capemgr for the majority of distros. While many cape devicetree
use cases are perfectly happy with loading at run-time rather than
boot-time, it seems there should be a mechanism for pushing cape
support into the category of being available at boot-time across
distributions.
* The devicetree sources, including the primary boot .dts files, will
eventually be removed from the kernel source tree. I'm not too sure if
and when it'll really happen, but starting up a project to maintain
the definitive beagleboard.org board devicetree files outside the
kernel seems to make sense. Given the interdependency of the boot .dtb
and the overlay .dtbo files, combining them into a single repository
where every distribution can pick them up seems like a natural and
obvious choice. There are of course some dependencies on kernel
versions, but I believe most of those have settled out by now and we
should be OK moving forward.
* There seems to be little or no interest in my previous proposal to
use cape EEPROMs to store the overlay fragments. Given some churn in
the devicetree node definitions, it is likely this would have failed
in bad ways anyway. It seems mostly reasonable to expect users to
update their kernel and firmware to gain support for new add-on
hardware and we mostly try to avoid regressions (with the seemingly
ever-living exception of 3D graphics support), so I think I'm better
aligned with the community to drop my older suggestion. Some people,
including CircuitCo, are building capes without configuration EEPROMs
now, so a different recommended mechanism seems like a requirement.
* With the patches in our vendor 3.8 kernels and with all recent
mainline kernels, performing userspace muxing operations has become
easy again. It seems to be possible to turn on drivers not currently
in use without an unacceptable level of bloat or conflict. This has
been partially proven out using Charles' universal cape
(https://github.com/cdsteinkuehler/beaglebone-universal-io), though I
still have some concerns about conflicts. The result might be that
there is still some number of overlays, but the approach of minimizing
the overlays and instead relying on the existing loading/unloading
mechanisms of the mainline drivers as much as possible feels right to
me.
* It will still be some time before devicetree overlay support is
adopted in the mainline kernel. While I still see a strong need to
have devicetree overlay support and CapeMgr in the mainline, the
desire here is to optimize the user experience in the shortest term
possible. Users get really confused by the errors that get generated
by loading incorrect devicetree overlays and it is always nice when
you can avoid confusing users.
My suggestion is:
* Maintain the source for .dtb and .dtbo files for all BeagleBoard.org
boards at http://github.com/beagleboard/devicetree-source, overriding
the sources in the mainline kernel when performing kernel builds. We
can host pre-built .dtb and .dtbo files at a normailzed location
outside the source repository for those that don't want to perform the
builds, since I don't believe the binary format is changing any time
soon other than the overlay support we utilize. Any patches accepted
into mainline as long as these files still exist there as well should
be merged to try to keep these in-line as long as possible,
anticipating eventual removal from mainline.
* Have cape makers submit pull requests to have their cape enabled in
the single boot-time devicetree overlay for each board they support.
The base drivers should be enabled at the earliest point where they
don't cause a conflict, minimizing what gets put into their overlays.
The final mux configuration and other points of conflict should be
kept in a board-specific overlay to make that configuration available
at boot. If the cape is disabled on the kernel command-line, the
kernel doesn't include CapeMgr support, or the board doesn't include a
configuration EEPROM, users would still have the ability to perform
run-time userspace mux configuration without CapeMgr unless
conflicting drivers need to be loaded.
Alternatively, if we don't think this is where things belong, perhaps
we could try to move all of this into the u-boot sources, though
people using other bootloaders might not find this the most useful
approach.
The pull request for http://github.com/beagleboard/devicetree-source:
The following changes since commit a524bf5d5e173795ce4cb214280f304588b1d78d:
capes: add BB-VIEW-LCD4-01-00A0 & BB-VIEW-LCD7-01-00A0 (2014-05-29
15:59:31 -0500)
are available in the git repository at:
git at github.com:jadonk/cape-firmware master
for you to fetch changes up to 9de20db80056b72d6e1f61b68447ba8f2d12cf9c:
Beagle DTS: remove deleted files from Makefile (2014-06-02 12:35:28 -0400)
----------------------------------------------------------------
[...] Too many changes to list bringing in kernel history.
From: Russell King - ARM Linux <hidden> Date: 2014-06-17 09:09:31
On Mon, Jun 16, 2014 at 09:22:50AM -0400, Jason Kridner wrote:
Adding devicetree and linux-arm-kernel lists based on feedback on IRC...
On Tue, Jun 10, 2014 at 12:46 PM, Jason Kridner [off-list ref] wrote:
quoted
I'd like to discuss moving our current library of cape devicetree
overlay sources into a single tree, including the boot .dtb files for
BeagleBoard.org boards and moving towards enabling as much of the cape
support into a single boot-time .dtb file with an approach similar to
the cape-universal overlay
(https://github.com/cdsteinkuehler/beaglebone-universal-io), but not
in an overlay.
First of all, I want to note this doesn't change my view on the
importance of mainline support for devicetree overlays. They are still
absolutely critical and highly useful, solving problems that cannot be
solved through boot-time devicetrees. I'm simply looking for an
approach that will complement the availability of overlays and provide
the best user experience.
Here's the most obvious question in the world on this topic. Are capes
hot-pluggable?
Looking at the posts on google+ from David Anders, they're using pin
headers for connectivity, with no additional protection against hot-
plugging, and no sequencing of pin connection. In other words, they are
not hot-pluggable.
So, why do we need to add a load of infrastructure to the kernel to allow
the device tree to be modified at run time? At present, the way the
entire DT infrastructure works is that it assumes the DT remains static
and never changes - this applies not only to the core DT code, but also
to all the drivers which have been converted.
So, you're asking for a feature which is impossible to really make use
of on the hardware which you want to use it.
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?
The logical way to deal with this is to have the boot loader merge DT
fragments together before it calls the kernel, so the kernel sees a single
DT blob which describes the whole hardware.
A good way that this could have been done is to put an I2C EEPROM on
each cape, and have that store the DT fragment. The boot loader could
have then read that from each cape, and used that information to build
up the final DT. Why this hasn't been thought of, considering that the
kernel has been moving towards DT for years, is quite unbelievable.
I'm quite sure you're going to say that that introduces additional
hardware expense. Yes it does, but it also eliminates the problem you
are now bringing up.
--
FTTC broadband for 0.8mile line: now at 9.7Mbps down 460kbps up... slowly
improving, and getting towards what was expected from it.
From: Matt Porter <hidden> Date: 2014-06-17 12:58:31
On Tue, Jun 17, 2014 at 10:09:31AM +0100, Russell King wrote:
On Mon, Jun 16, 2014 at 09:22:50AM -0400, Jason Kridner wrote:
quoted
Adding devicetree and linux-arm-kernel lists based on feedback on IRC...
On Tue, Jun 10, 2014 at 12:46 PM, Jason Kridner [off-list ref] wrote:
quoted
I'd like to discuss moving our current library of cape devicetree
overlay sources into a single tree, including the boot .dtb files for
BeagleBoard.org boards and moving towards enabling as much of the cape
support into a single boot-time .dtb file with an approach similar to
the cape-universal overlay
(https://github.com/cdsteinkuehler/beaglebone-universal-io), but not
in an overlay.
First of all, I want to note this doesn't change my view on the
importance of mainline support for devicetree overlays. They are still
absolutely critical and highly useful, solving problems that cannot be
solved through boot-time devicetrees. I'm simply looking for an
approach that will complement the availability of overlays and provide
the best user experience.
Here's the most obvious question in the world on this topic. Are capes
hot-pluggable?
Looking at the posts on google+ from David Anders, they're using pin
headers for connectivity, with no additional protection against hot-
plugging, and no sequencing of pin connection. In other words, they are
not hot-pluggable.
So, why do we need to add a load of infrastructure to the kernel to allow
the device tree to be modified at run time? At present, the way the
entire DT infrastructure works is that it assumes the DT remains static
and never changes - this applies not only to the core DT code, but also
to all the drivers which have been converted.
So, you're asking for a feature which is impossible to really make use
of on the hardware which you want to use it.
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.
-Matt
From: Russell King - ARM Linux <hidden> Date: 2014-06-17 13:15:22
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:
quoted
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.
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.
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.
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.
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.
--
FTTC broadband for 0.8mile line: now at 9.7Mbps down 460kbps up... slowly
improving, and getting towards what was expected from it.
From: Matt Porter <hidden> Date: 2014-06-17 13:30:43
On Tue, Jun 17, 2014 at 02:15:22PM +0100, Russell King wrote:
On Tue, Jun 17, 2014 at 08:58:31AM -0400, Matt Porter wrote:
quoted
On Tue, Jun 17, 2014 at 10:09:31AM +0100, Russell King wrote:
quoted
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.
I don't believe this is completely true. Pantelis and Grant are working
together on getting DT overlays upstream. It's pretty far along. It
doesn't mean there aren't serious issues with the way the DT core code
was implement assuming it would be static.
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.
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.
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.
Yes, I suppose you missed the active work on the DT overlay series. As I
mentioned, there's active development on these things. There's also
active discussion on some of the challenges.
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.
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:
quoted
On Tue, Jun 17, 2014 at 10:09:31AM +0100, Russell King wrote:
quoted
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.
From: Grant Likely <hidden> Date: 2014-06-17 13:50:35
On Tue, 17 Jun 2014 10:09:31 +0100, Russell King - ARM Linux [off-list ref] wrote:
On Mon, Jun 16, 2014 at 09:22:50AM -0400, Jason Kridner wrote:
quoted
Adding devicetree and linux-arm-kernel lists based on feedback on IRC...
On Tue, Jun 10, 2014 at 12:46 PM, Jason Kridner [off-list ref] wrote:
quoted
I'd like to discuss moving our current library of cape devicetree
overlay sources into a single tree, including the boot .dtb files for
BeagleBoard.org boards and moving towards enabling as much of the cape
support into a single boot-time .dtb file with an approach similar to
the cape-universal overlay
(https://github.com/cdsteinkuehler/beaglebone-universal-io), but not
in an overlay.
First of all, I want to note this doesn't change my view on the
importance of mainline support for devicetree overlays. They are still
absolutely critical and highly useful, solving problems that cannot be
solved through boot-time devicetrees. I'm simply looking for an
approach that will complement the availability of overlays and provide
the best user experience.
Here's the most obvious question in the world on this topic. Are capes
hot-pluggable?
Looking at the posts on google+ from David Anders, they're using pin
headers for connectivity, with no additional protection against hot-
plugging, and no sequencing of pin connection. In other words, they are
not hot-pluggable.
So, why do we need to add a load of infrastructure to the kernel to allow
the device tree to be modified at run time? At present, the way the
entire DT infrastructure works is that it assumes the DT remains static
and never changes - this applies not only to the core DT code, but also
to all the drivers which have been converted.
As others have pointed out, capes aren't the only use case. pseries
already modifies the tree at runtime, and the FPGA users want the
ability to add/remove additional DT blocks. I've also heard from
hobbiest/maker developers that by deferring the load of additional data
to userspace means they don't need to mess with the boot path once it is
working. The feature is coming.
g.
On 17/06/14 10:09, Russell King - ARM Linux 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?
I'm not convinced you should, but Grant Likely seemed to be much more open
to the idea with the latest attempt https://lkml.org/lkml/2014/5/29/586
A good way that this could have been done is to put an I2C EEPROM on
each cape, and have that store the DT fragment. The boot loader could
have then read that from each cape, and used that information to build
up the final DT. Why this hasn't been thought of, considering that the
kernel has been moving towards DT for years, is quite unbelievable.
I believe that was Jasons original idea.
From a users perspective, a fixed DT fragment in EEPROM quickly ends up
being out of step with OS implementation and simply becomes another
pain point that needs worked around.
Anyway, there already exist capes in large scale production that don't
have the EEPROM. As well as ones that use the required I2C bus for other
purposes, thereby blocking all other capes connected at the same time
from using that mechanism even when they are capable of doing so.
Not forgetting the number of capes that have shipped already without the
DT fragment in their EEPROMS.
Too late to shut the barn door, question is where to go from here.
Consolidation the dt knowledge in one tree is a good idea, regardless of
how it's eventually used.
From: Russell King - ARM Linux <hidden> Date: 2014-06-17 16:01:19
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.
Isn't this a bit of a missed opportunity, if this is a direction that
OF wishes to head towards?
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?
--
FTTC broadband for 0.8mile line: now at 9.7Mbps down 460kbps up... slowly
improving, and getting towards what was expected from it.
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:
quoted
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 majordomo at vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
From: Russell King - ARM Linux <hidden> Date: 2014-06-17 17:05:31
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.)
--
FTTC broadband for 0.8mile line: now at 9.7Mbps down 460kbps up... slowly
improving, and getting towards what was expected from it.
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:
quoted
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.
From: Russell King - ARM Linux <hidden> Date: 2014-06-17 17:41:28
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:
quoted
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.
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.
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 at 020e0008 {
#address-cells = <1>;
#size-cells = <0>;
compatible = "fsl,imx6q-ldb", "fsl,imx53-ldb";
gpr = <&gpr>;
status = "disabled";
lvds-channel at 0 {
#address-cells = <1>;
#size-cells = <0>;
reg = <0>;
status = "disabled";
port at 0 {
reg = <0>;
lvds0_mux_0: endpoint {
remote-endpoint = <&ipu1_di0_lvds0>;
};
};
port at 1 {
reg = <1>;
lvds0_mux_1: endpoint {
remote-endpoint = <&ipu1_di1_lvds0>;
};
};
};
lvds-channel at 1 {
#address-cells = <1>;
#size-cells = <0>;
reg = <1>;
status = "disabled";
port at 0 {
reg = <0>;
lvds1_mux_0: endpoint {
remote-endpoint = <&ipu1_di0_lvds1>;
};
};
port at 1 {
reg = <1>;
lvds1_mux_1: endpoint {
remote-endpoint = <&ipu1_di1_lvds1>;
};
};
};
};
hdmi: hdmi at 0120000 {
#address-cells = <1>;
#size-cells = <0>;
reg = <0x00120000 0x9000>;
interrupts = <0 115 0x04>;
gpr = <&gpr>;
clocks = <&clks 123>, <&clks 124>;
clock-names = "iahb", "isfr";
status = "disabled";
port at 0 {
reg = <0>;
hdmi_mux_0: endpoint {
remote-endpoint = <&ipu1_di0_hdmi>;
};
};
port at 1 {
reg = <1>;
hdmi_mux_1: endpoint {
remote-endpoint = <&ipu1_di1_hdmi>;
};
};
};
mipi_dsi: mipi at 021e0000 {
#address-cells = <1>;
#size-cells = <0>;
reg = <0x021e0000 0x4000>;
status = "disabled";
port at 0 {
reg = <0>;
mipi_mux_0: endpoint {
remote-endpoint = <&ipu1_di0_mipi>;
};
};
port at 1 {
reg = <1>;
mipi_mux_1: endpoint {
remote-endpoint = <&ipu1_di1_mipi>;
};
};
};
ipu1: ipu at 02400000 {
#address-cells = <1>;
#size-cells = <0>;
compatible = "fsl,imx6q-ipu";
reg = <0x02400000 0x400000>;
interrupts = <0 6 IRQ_TYPE_LEVEL_HIGH>,
<0 5 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&clks 130>, <&clks 131>, <&clks 132>;
clock-names = "bus", "di0", "di1";
resets = <&src 2>;
ipu1_di0: port at 2 {
#address-cells = <1>;
#size-cells = <0>;
reg = <2>;
ipu1_di0_disp0: endpoint at 0 {
};
ipu1_di0_hdmi: endpoint at 1 {
remote-endpoint = <&hdmi_mux_0>;
};
ipu1_di0_mipi: endpoint at 2 {
remote-endpoint = <&mipi_mux_0>;
};
ipu1_di0_lvds0: endpoint at 3 {
remote-endpoint = <&lvds0_mux_0>;
};
ipu1_di0_lvds1: endpoint at 4 {
remote-endpoint = <&lvds1_mux_0>;
};
};
ipu1_di0_lvds1: endpoint at 4 {
remote-endpoint = <&lvds1_mux_0>;
};
};
ipu1_di1: port at 3 {
#address-cells = <1>;
#size-cells = <0>;
reg = <3>;
ipu1_di0_disp1: endpoint at 0 {
};
ipu1_di1_hdmi: endpoint at 1 {
remote-endpoint = <&hdmi_mux_1>;
};
ipu1_di1_mipi: endpoint at 2 {
remote-endpoint = <&mipi_mux_1>;
};
ipu1_di1_lvds0: endpoint at 3 {
remote-endpoint = <&lvds0_mux_1>;
};
ipu1_di1_lvds1: endpoint at 4 {
remote-endpoint = <&lvds1_mux_1>;
};
};
};
display-subsystem {
compatible = "fsl,imx-display-subsystem";
ports = <&ipu1_di0>, <&ipu1_di1>, <&ipu2_di0>, <&ipu2_di1>;
};
ipu1, mipi_dsi, ldb and hdmi are each separate platform devices, which
are combined to look like a single DRM device. Each device can be
enabled by the platform code. All enabled devices must be present to
cause the DRM device to "bind". The above connectivity is parsed via
the of_graph helpers, and enumerated by the driver(s).
Let's say that we have ipu1 and hdmi enabled, but ldb disabled. ldb is
connected to an external FPGA. Someone loads a bitstream after boot
into the FPGA, and then updates the DT dynamically to enable the ldb
device.
Great, so a new platform device gets spawned for the new device. What
triggers the ipu or display subsystem level (which is what's really
needed) to tell it something changed here?
This is exactly my point - such stuff has not been thought about, because
(I reckon) not many people are even aware of DT wanting to become dynamic.
It's certainly not clear from the use model that we've been basing our
driver conversions on that DT is anything but static...
--
FTTC broadband for 0.8mile line: now at 9.7Mbps down 460kbps up... slowly
improving, and getting towards what was expected from it.
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:
quoted
Hi Russell,
On Jun 17, 2014, at 8:05 PM, Russell King - ARM Linux wrote:
quoted
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.
quoted
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.
quoted
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 at 020e0008 {
#address-cells = <1>;
#size-cells = <0>;
compatible = "fsl,imx6q-ldb", "fsl,imx53-ldb";
gpr = <&gpr>;
status = "disabled";
lvds-channel at 0 {
#address-cells = <1>;
#size-cells = <0>;
reg = <0>;
status = "disabled";
port at 0 {
reg = <0>;
lvds0_mux_0: endpoint {
remote-endpoint = <&ipu1_di0_lvds0>;
};
};
port at 1 {
reg = <1>;
lvds0_mux_1: endpoint {
remote-endpoint = <&ipu1_di1_lvds0>;
};
};
};
lvds-channel at 1 {
#address-cells = <1>;
#size-cells = <0>;
reg = <1>;
status = "disabled";
port at 0 {
reg = <0>;
lvds1_mux_0: endpoint {
remote-endpoint = <&ipu1_di0_lvds1>;
};
};
port at 1 {
reg = <1>;
lvds1_mux_1: endpoint {
remote-endpoint = <&ipu1_di1_lvds1>;
};
};
};
};
hdmi: hdmi at 0120000 {
#address-cells = <1>;
#size-cells = <0>;
reg = <0x00120000 0x9000>;
interrupts = <0 115 0x04>;
gpr = <&gpr>;
clocks = <&clks 123>, <&clks 124>;
clock-names = "iahb", "isfr";
status = "disabled";
port at 0 {
reg = <0>;
hdmi_mux_0: endpoint {
remote-endpoint = <&ipu1_di0_hdmi>;
};
};
port at 1 {
reg = <1>;
hdmi_mux_1: endpoint {
remote-endpoint = <&ipu1_di1_hdmi>;
};
};
};
mipi_dsi: mipi at 021e0000 {
#address-cells = <1>;
#size-cells = <0>;
reg = <0x021e0000 0x4000>;
status = "disabled";
port at 0 {
reg = <0>;
mipi_mux_0: endpoint {
remote-endpoint = <&ipu1_di0_mipi>;
};
};
port at 1 {
reg = <1>;
mipi_mux_1: endpoint {
remote-endpoint = <&ipu1_di1_mipi>;
};
};
};
ipu1: ipu at 02400000 {
#address-cells = <1>;
#size-cells = <0>;
compatible = "fsl,imx6q-ipu";
reg = <0x02400000 0x400000>;
interrupts = <0 6 IRQ_TYPE_LEVEL_HIGH>,
<0 5 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&clks 130>, <&clks 131>, <&clks 132>;
clock-names = "bus", "di0", "di1";
resets = <&src 2>;
ipu1_di0: port at 2 {
#address-cells = <1>;
#size-cells = <0>;
reg = <2>;
ipu1_di0_disp0: endpoint at 0 {
};
ipu1_di0_hdmi: endpoint at 1 {
remote-endpoint = <&hdmi_mux_0>;
};
ipu1_di0_mipi: endpoint at 2 {
remote-endpoint = <&mipi_mux_0>;
};
ipu1_di0_lvds0: endpoint at 3 {
remote-endpoint = <&lvds0_mux_0>;
};
ipu1_di0_lvds1: endpoint at 4 {
remote-endpoint = <&lvds1_mux_0>;
};
};
ipu1_di0_lvds1: endpoint at 4 {
remote-endpoint = <&lvds1_mux_0>;
};
};
ipu1_di1: port at 3 {
#address-cells = <1>;
#size-cells = <0>;
reg = <3>;
ipu1_di0_disp1: endpoint at 0 {
};
ipu1_di1_hdmi: endpoint at 1 {
remote-endpoint = <&hdmi_mux_1>;
};
ipu1_di1_mipi: endpoint at 2 {
remote-endpoint = <&mipi_mux_1>;
};
ipu1_di1_lvds0: endpoint at 3 {
remote-endpoint = <&lvds0_mux_1>;
};
ipu1_di1_lvds1: endpoint at 4 {
remote-endpoint = <&lvds1_mux_1>;
};
};
};
display-subsystem {
compatible = "fsl,imx-display-subsystem";
ports = <&ipu1_di0>, <&ipu1_di1>, <&ipu2_di0>, <&ipu2_di1>;
};
ipu1, mipi_dsi, ldb and hdmi are each separate platform devices, which
are combined to look like a single DRM device. Each device can be
enabled by the platform code. All enabled devices must be present to
cause the DRM device to "bind". The above connectivity is parsed via
the of_graph helpers, and enumerated by the driver(s).
Let's say that we have ipu1 and hdmi enabled, but ldb disabled. ldb is
connected to an external FPGA. Someone loads a bitstream after boot
into the FPGA, and then updates the DT dynamically to enable the ldb
device.
Great, so a new platform device gets spawned for the new device. What
triggers the ipu or display subsystem level (which is what's really
needed) to tell it something changed here?
The ipu can register an of_reconfig notifier, and it will be notified of
any changes in the topology. Perhaps this can be part of the DRM core,
I can't be sure.
This is very similar to the way the platform/i2c/spi bus notifiers work
in my patchset; whenever the state of a device node change due to the live
tree changing the status of a child node from/to enabled/disabled the
parent (bus or in this case the ipu) will be notified and then it is
free to take action.
The hairy part (which the patchset provides) is making sure all the
changes are recorded, applied and potentially rolled back in a controlled
manner, so that the state of the DT tree is consistent at all times.
This is exactly my point - such stuff has not been thought about, because
(I reckon) not many people are even aware of DT wanting to become dynamic.
It's certainly not clear from the use model that we've been basing our
driver conversions on that DT is anything but static...
FWIW, the changes to support dynamic DT are not that great.
We know that trying to handle cases where each property change has to be
handled gets hairy fast, so what we're trying to do is make thing easier
by performing the device state change in a well defined manner.
So to return in your previous example, when the FPGA bitstream is loaded
and ldb should be enabled, the DT core will notify the parent bus (which
I can't tell exactly from your fragment but it should be) the platform
bus, which will end up of registering the platform device.
Now if DRM can't handle that, then that's a limitation of the DRM subsystem,
which fortunately is not shared by most of the other subsystems in the kernel.
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.