| Message ID | 1393261669-32039-3-git-send-email-florian.vaussard@epfl.ch (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On Mon, Feb 24, 2014 at 06:07:49PM +0100, Florian Vaussard wrote: > + hdmi0: connector@0 { > + compatible = "hdmi-connector"; This looks way to generic a compatible string. Are you sure it's correct?
Hi Russell, On Mon, Feb 24, 2014 at 3:03 PM, Russell King - ARM Linux <linux@arm.linux.org.uk> wrote: > On Mon, Feb 24, 2014 at 06:07:49PM +0100, Florian Vaussard wrote: >> + hdmi0: connector@0 { >> + compatible = "hdmi-connector"; > > This looks way to generic a compatible string. Are you sure it's > correct? > That compatible string is correct according to the latest series posted by Tomi Valkeinen to add DT bindings for the OMAP Display SubSystem (DSS) [0]. The property is added on this patch [1] and as far as I understood the idea is that it could be a generic DT binding that can be used by platform specific HDMI connectors like the omap dss HDMI connector [2]. I'm adding Tomi to the cc list so he can a correct me if I'm wrong. Thanks a lot and best regards, Javier [0]: http://www.spinics.net/lists/linux-omap/msg102522.html [1]: http://www.spinics.net/lists/linux-omap/msg102559.html [2]: http://www.spinics.net/lists/arm-kernel/msg302197.html
Hi Russell, Javier, On 02/24/2014 09:22 PM, Javier Martinez Canillas wrote: > Hi Russell, > > On Mon, Feb 24, 2014 at 3:03 PM, Russell King - ARM Linux > <linux@arm.linux.org.uk> wrote: >> On Mon, Feb 24, 2014 at 06:07:49PM +0100, Florian Vaussard wrote: >>> + hdmi0: connector@0 { >>> + compatible = "hdmi-connector"; >> >> This looks way to generic a compatible string. Are you sure it's >> correct? >> > > That compatible string is correct according to the latest series > posted by Tomi Valkeinen to add DT bindings for the OMAP Display > SubSystem (DSS) [0]. > Indeed, this compatible string comes from the DSS series. > The property is added on this patch [1] and as far as I understood the > idea is that it could be a generic DT binding that can be used by > platform specific HDMI connectors like the omap dss HDMI connector > [2]. > On the other side, looking at drivers/video/omap2/displays-new/connector-hdmi.c from the DSS series [1], the compatible string is "omapdss,hdmi-connector", which makes me wonder which one should be used :) BTW, "omapdss" seems a strange prefix, isn't it? Tomi, any inputs? Regards, Florian [1] https://git.kernel.org/cgit/linux/kernel/git/tomba/linux.git/tree/drivers/video/omap2/displays-new/connector-hdmi.c?h=work/dss-dt-review-3
On Mon, Feb 24, 2014 at 05:22:27PM -0300, Javier Martinez Canillas wrote: > Hi Russell, > > On Mon, Feb 24, 2014 at 3:03 PM, Russell King - ARM Linux > <linux@arm.linux.org.uk> wrote: > > On Mon, Feb 24, 2014 at 06:07:49PM +0100, Florian Vaussard wrote: > >> + hdmi0: connector@0 { > >> + compatible = "hdmi-connector"; > > > > This looks way to generic a compatible string. Are you sure it's > > correct? > > > > That compatible string is correct according to the latest series > posted by Tomi Valkeinen to add DT bindings for the OMAP Display > SubSystem (DSS) [0]. in which case: N N AA CCCC K K NN N A A C C K K N N N A A C KK N N N AAAAAA C KK N NN A A C C K K N N A A CCCC K K Yes, that's a very big nack. Two things: 1. OMAP really doesn't have the right to define a compatible string which is as generic as "hdmi-connector". 2. Even with "omapdss," before it, the convention that DT people have adopted is for the prefix to be "companyname," and not a subsystem. I'm not the only one with this concern - I discussed it with Arnd last night and his comments were about it being "obviously bogus". > The property is added on this patch [1] and as far as I understood the > idea is that it could be a generic DT binding that can be used by > platform specific HDMI connectors like the omap dss HDMI connector [2]. Why do the physical connectors need a DT binding? Surely what needs the DT binding is the HDMI encoder - and that certainly should no way be a generic name, because there's no such thing as a generic HDMI encoder chip.
Hi, On 02/25/2014 01:39 PM, Russell King - ARM Linux wrote: > On Mon, Feb 24, 2014 at 05:22:27PM -0300, Javier Martinez Canillas wrote: >> Hi Russell, >> >> On Mon, Feb 24, 2014 at 3:03 PM, Russell King - ARM Linux >> <linux@arm.linux.org.uk> wrote: >>> On Mon, Feb 24, 2014 at 06:07:49PM +0100, Florian Vaussard wrote: >>>> + hdmi0: connector@0 { >>>> + compatible = "hdmi-connector"; >>> >>> This looks way to generic a compatible string. Are you sure it's >>> correct? >>> >> >> That compatible string is correct according to the latest series >> posted by Tomi Valkeinen to add DT bindings for the OMAP Display >> SubSystem (DSS) [0]. > > in which case: > > N N AA CCCC K K > NN N A A C C K K > N N N A A C KK > N N N AAAAAA C KK > N NN A A C C K K > N N A A CCCC K K > What a nice nack. > Yes, that's a very big nack. Two things: > > 1. OMAP really doesn't have the right to define a compatible string which > is as generic as "hdmi-connector". > > 2. Even with "omapdss," before it, the convention that DT people have adopted > is for the prefix to be "companyname," and not a subsystem. > > I'm not the only one with this concern - I discussed it with Arnd last > night and his comments were about it being "obviously bogus". > I agree. It should probably be "ti,omapdss-hdmi-connector", or simply "ti,hdmi-connector", if any. >> The property is added on this patch [1] and as far as I understood the >> idea is that it could be a generic DT binding that can be used by >> platform specific HDMI connectors like the omap dss HDMI connector [2]. > > Why do the physical connectors need a DT binding? Surely what needs the > DT binding is the HDMI encoder - and that certainly should no way be a > generic name, because there's no such thing as a generic HDMI encoder > chip. > The HDMI IP is declared in omap4.dtsi, with the compatible "ti,omap4-hdmi". The code of the HDMI connector [1] seems to mainly call ops of the connected endpoint, so it seems to act as a logical termination in the DSS chain, but I may be wrong. Regards, Florian [1] https://git.kernel.org/cgit/linux/kernel/git/tomba/linux.git/tree/drivers/video/omap2/displays-new/connector-hdmi.c?h=work%2Fdss-dt-review-3
Hi, On Tue, Feb 25, 2014 at 12:39:21PM +0000, Russell King - ARM Linux wrote: > > That compatible string is correct according to the latest series > > posted by Tomi Valkeinen to add DT bindings for the OMAP Display > > SubSystem (DSS) [0]. > > in which case: > > N N AA CCCC K K > NN N A A C C K K > N N N A A C KK > N N N AAAAAA C KK > N NN A A C C K K > N N A A CCCC K K > > Yes, that's a very big nack. Two things: > > 1. OMAP really doesn't have the right to define a compatible string which > is as generic as "hdmi-connector". AFAIK the idea was to have "hdmi-connector" as part of the common display framework [1]. It's not really platform specific, since it's just a connector. Since omapdss does not yet implement the common display framework, but wants to keep a stable DT API it rewrites "hdmi-connector" to "omapdss,hdmi-connector" for now. > 2. Even with "omapdss," before it, the convention that DT people have adopted > is for the prefix to be "companyname," and not a subsystem. > > I'm not the only one with this concern - I discussed it with Arnd last > night and his comments were about it being "obviously bogus". > > > The property is added on this patch [1] and as far as I understood the > > idea is that it could be a generic DT binding that can be used by > > platform specific HDMI connectors like the omap dss HDMI connector [2]. > > Why do the physical connectors need a DT binding? This is the termination of the video bus and useful information for xrandr. > Surely what needs the DT binding is the HDMI encoder - and that > certainly should no way be a generic name, because there's no such > thing as a generic HDMI encoder chip. The HDMI encoder and companion chips are described separatly and properly prefixed [0]. [0] http://www.spinics.net/lists/linux-omap/msg102522.html [1] https://lwn.net/Articles/563157/ -- Sebastian
On Tuesday 25 February 2014 14:41:48 Sebastian Reichel wrote: > On Tue, Feb 25, 2014 at 12:39:21PM +0000, Russell King - ARM Linux wrote: > > > That compatible string is correct according to the latest series > > > posted by Tomi Valkeinen to add DT bindings for the OMAP Display > > > SubSystem (DSS) [0]. > > > > in which case: > > > > N N AA CCCC K K > > NN N A A C C K K > > N N N A A C KK > > N N N AAAAAA C KK > > N NN A A C C K K > > N N A A CCCC K K > > > > Yes, that's a very big nack. Two things: > > > > 1. OMAP really doesn't have the right to define a compatible string which > > is as generic as "hdmi-connector". > > AFAIK the idea was to have "hdmi-connector" as part of the common > display framework [1]. It's not really platform specific, since it's > just a connector. > > Since omapdss does not yet implement the common display framework, > but wants to keep a stable DT API it rewrites "hdmi-connector" to > "omapdss,hdmi-connector" for now. And since the common display framework has been pretty much nacked, we have no framework on which drivers can rely ;-) > > 2. Even with "omapdss," before it, the convention that DT people have > > adopted is for the prefix to be "companyname," and not a subsystem. > > > > I'm not the only one with this concern - I discussed it with Arnd last > > night and his comments were about it being "obviously bogus". > > > > > The property is added on this patch [1] and as far as I understood the > > > idea is that it could be a generic DT binding that can be used by > > > platform specific HDMI connectors like the omap dss HDMI connector [2]. > > > > Why do the physical connectors need a DT binding? > > This is the termination of the video bus and useful information for > xrandr. I don't think all physical connectors require a DT binding per-se, but they need to be represented in DT as they're part of the hardware. We could push connector-related information to the nodes of all chips that have interfaces wired directly to connectors, but that would result in more complex DT bindings and core. I believe modeling connectors using separate DT nodes is be best, and would allow easier support for more complex connectors that carry multiple streams/signals in parallel (video, audio, DDC, ...). > > Surely what needs the DT binding is the HDMI encoder - and that certainly > > should no way be a generic name, because there's no such thing as a > > generic HDMI encoder chip. > > The HDMI encoder and companion chips are described separatly and properly > prefixed [0]. > > [0] http://www.spinics.net/lists/linux-omap/msg102522.html > [1] https://lwn.net/Articles/563157/
On Tue, Feb 25, 2014 at 05:51:21PM +0100, Laurent Pinchart wrote: > I don't think all physical connectors require a DT binding per-se, but they > need to be represented in DT as they're part of the hardware. We could push > connector-related information to the nodes of all chips that have interfaces > wired directly to connectors, but that would result in more complex DT > bindings and core. I believe modeling connectors using separate DT nodes is be > best, and would allow easier support for more complex connectors that carry > multiple streams/signals in parallel (video, audio, DDC, ...). There is some sanity to representing physical connectors in DT, but it's not for the reason you mention above. If you consider that it's possible on PCs to find out what connectors are on the motherboard and where they are located, this is very useful information to be stored and presented. However, the idea that you combine streams at connectors is not a universal truth, and is certainly false for HDMI. HDMI combines video and audio at the encoder stage, not at the connector stage, and many HDMI encoders will provide everything required for driving the connector. However, my major objection here is not really that: my major objection is using something as generic as "hdmi-connector" as a compatible string. The reason is that we have to remember that DT is not just "a Linux thing". It's /supposed/ to be an OS independent representation of the hardware. If we invent something generic called a "hdmi-connector" then we had better first do a thorough search to make sure we're not trampling on anything which is standardized or becoming a standard - if there is, we should work with them - and if that's not possible, then we need to distingush ourselves from them. What we can't do is go around inventing generic stuff without having our eyes wide open. So, here's a good question to probe how far this has been thought through already: what has been done to discuss the creation of this generic "hdmi-connector" thing with the various parties who are interested in HDMI outputs under DRM using device tree? If that hasn't happened, that's quite a failing - it means that we're on the road to having two _implementation specific_ DT representations for the same hardware - one for fbdev and one for DRM. That really isn't on. Yes, it then opens a pandora's box of problems about how we determine whether DRM or fbdev should bind to the DT nodes, but that should be an entirely separate issue (and, ideally of course, both should use the same sub-drivers for the components.)
Hi, On 25/02/14 22:56, Russell King - ARM Linux wrote: > On Tue, Feb 25, 2014 at 05:51:21PM +0100, Laurent Pinchart wrote: First I want to summarize the omapdss DT bindings, even if it was already more or less covered earlier: We have a bunch of panels and encoders used on OMAP boards, and we have separate, omapdss specific, drivers for those. My plan is to continue improving those drivers until they can be platform independent. This would be the Common Display Framework that's been discussed (or a precursor to it). We need DT bindings for OMAP display, and one option would've been adding a compatible string of "ti,xxx" for every panel and encoder. That would obviously be wrong DT representation. So I wanted to do proper DT bindings, with proper compatible string. This creates the problem that we don't have generic drivers for those components yet. For this, I created a hack that, on OMAP, appends "omapdss," to the display components at boot time. This way we can have OMAP specific drivers for the time being, but others could still use the same bindings for their platform and platform specific drivers with similar trick. Note that the above is not merged yet, but I'd really want to get it in for the next merge window, so if that general concept is bad, please nack it asap. And preferably give ideas for an alternative =). >> I don't think all physical connectors require a DT binding per-se, but they >> need to be represented in DT as they're part of the hardware. We could push >> connector-related information to the nodes of all chips that have interfaces >> wired directly to connectors, but that would result in more complex DT >> bindings and core. I believe modeling connectors using separate DT nodes is be >> best, and would allow easier support for more complex connectors that carry >> multiple streams/signals in parallel (video, audio, DDC, ...). There are things we need to represent for the connectors. For example, a +5V going to the connector is not managed by any IP. In some cases neither is a hotplug detect GPIO. The i2c lines for the DDC need to be managed by someone (with DVI. HDMI DDC on OMAP is managed by by the HDMI IP). I guess one could argue that those are standard properties of HDMI or DVI, and thus could well be managed by the HDMI or DVI encoder, even if the encoder IP itself doesn't have anything to do with those. Maybe they could, but I think modeling the connector separately is more correct, and allows more freedom. Say, the HDMI could as well be directly wired to a panel, without any connector, although this is perhaps more common with eDP. In that case the connector related things can be just left out. Additionally, but perhaps not strictly needed, the connector represents a "termination" for the display pipeline, so there's a distinct display element at the end of the chain, sometimes a panel, sometimes a connector, which marks the end. This makes the pipeline consistent in the case where you've got an encoder, output of which goes on some boards to a connector and on some boards to a panel (compared to some boards having a panel after the encoder, and some having nothing). > There is some sanity to representing physical connectors in DT, but it's > not for the reason you mention above. If you consider that it's possible > on PCs to find out what connectors are on the motherboard and where they > are located, this is very useful information to be stored and presented. > > However, the idea that you combine streams at connectors is not a > universal truth, and is certainly false for HDMI. HDMI combines video > and audio at the encoder stage, not at the connector stage, and many > HDMI encoders will provide everything required for driving the connector. > > However, my major objection here is not really that: my major objection > is using something as generic as "hdmi-connector" as a compatible string. > The reason is that we have to remember that DT is not just "a Linux thing". > It's /supposed/ to be an OS independent representation of the hardware. > > If we invent something generic called a "hdmi-connector" then we had > better first do a thorough search to make sure we're not trampling on > anything which is standardized or becoming a standard - if there is, > we should work with them - and if that's not possible, then we need to > distingush ourselves from them. Yes, I agree that the connectors (DVI, analog-tv, and HDMI) are in a sense much more generic than bindings for a single IP, and thus more important to get right. > What we can't do is go around inventing generic stuff without having our > eyes wide open. > > So, here's a good question to probe how far this has been thought through > already: what has been done to discuss the creation of this generic > "hdmi-connector" thing with the various parties who are interested in > HDMI outputs under DRM using device tree? They have been discussed, in the context of Common Display Framework proposals, and in the context of OMAP DSS DT bindings. They've seen multiple review rounds, but I agree that finding about the connectors there may be rather difficult if one is not interested in OMAP DSS, or one see CDF as nonsense. Those OMAP bindings are used on both OMAP fbdev and DRM drivers, so at least in that case they've been proven to work on both frameworks. > If that hasn't happened, that's quite a failing - it means that we're > on the road to having two _implementation specific_ DT representations > for the same hardware - one for fbdev and one for DRM. That really > isn't on. I hope not. Afais, the bindings are really about the HW. Not fbdev or DRM. At the moment I do see that usually the existing fbdev and drm bindings are, in my opinion, quite bad. They don't give proper and detailed description of the hardware, in a way that should work on other platforms with very different display pipelines. The proposed bindings in my patches are the designed to be as generic as we've (mostly me and Laurent) been able to make them, and very similar ones have been used by Laurent on shmobile for his CDF patch series. The HDMI connector in particular doesn't even define much anything at all. At the moment, it only defines the connection to the previous item in the display pipeline, usually the HDMI encoder. The +5V I plan to add at some point, and it should be a clear addition, it's there by the spec. The same for HPD and i2c, although those should be optional so that an IP can handle those if the system is so designed. So while I fully confess that I haven't looked at other platform's HDMI, I don't see how the above could go badly wrong. The connector would obviously be extended later to add any missing features. > Yes, it then opens a pandora's box of problems about how we determine > whether DRM or fbdev should bind to the DT nodes, but that should be > an entirely separate issue (and, ideally of course, both should use > the same sub-drivers for the components.) Yes, this is what the common display framework tries to accomplish. But as you say, it's a separate issue. The DT bindings should just model the hardware so well that we're as confident as we can be that the current boards can be described with those. So how to go forward? It's very difficult to get feedback on complex DT bindings. I recently posted only the DT documentation part for OMAP DSS [1], in hopes to get some feedback for a smaller series, but nothing so far. It might be easier to look at the whole series [2] to see how the board dts files are changed, though. Maybe the subject "OMAP DSS DT bindings documentation" is not quite correct, as there's really nothing OMAP specific there except the SoC bindings itself. Perhaps re-sending with subject of "Generic display bindings" would catch more eyes. Tomi [1] http://mid.gmane.org/1392294752-18762-1-git-send-email-tomi.valkeinen@ti.com [2] http://mid.gmane.org/1390301833-24944-1-git-send-email-tomi.valkeinen@ti.com
On Wed, Feb 26, 2014 at 01:14:18PM +0200, Tomi Valkeinen wrote: > We have a bunch of panels and encoders used on OMAP boards, and we have > separate, omapdss specific, drivers for those. My plan is to continue > improving those drivers until they can be platform independent. This > would be the Common Display Framework that's been discussed (or a > precursor to it). I believe CDF has been knocked on the head. Also - DRM is not going to ever support hotplugging components - this was discussed at kernel summit last year and David Airlie was quite adamant about that. So, any "framework" which forces hotplugging of components on subsystems isn't going to fly. This is why we now have the component helpers in the driver model - to allow devices to be collected together into one logical subsystem group, and bound/unbound as a group. Remember that "hotplugging" in this context does not mean that the user can physically do something with the hardware. It means that they're separate devices which can be probed/removed at will. Every device in Linux can be bound and unbound from its driver at any time by userspace, and that is something which is expected to be handled gracefully.
On 26/02/14 14:03, Russell King - ARM Linux wrote: > On Wed, Feb 26, 2014 at 01:14:18PM +0200, Tomi Valkeinen wrote: >> We have a bunch of panels and encoders used on OMAP boards, and we have >> separate, omapdss specific, drivers for those. My plan is to continue >> improving those drivers until they can be platform independent. This >> would be the Common Display Framework that's been discussed (or a >> precursor to it). > > I believe CDF has been knocked on the head. I refuse to believe that we can't have common drivers for display components. Maybe CDF as it's been proposed in its current form is not good (although I haven't seen any explanation why), we need something like it. So the "CDF" I speak of is not any particular set of patches already sent, but a framework that would allow us to have generic display drivers. I'd be very glad if someone can point me to the discussions where CDF has been knocked on the head. > Also - DRM is not going to ever support hotplugging components - this > was discussed at kernel summit last year and David Airlie was quite Ok. Very odd stance. Maybe there's a reason for it that I just don't see. > adamant about that. So, any "framework" which forces hotplugging of > components on subsystems isn't going to fly. CDF doesn't force hotplugging. Although without hotplugging (hot-unplug not needed), or at least some minimal form of it, the system is a bit crippled. Leave one kernel module out, or have one driver probe fail, the whole display subsystem fails, even if some display pipelines would work fine. On OMAP4 SDP board, for example, this would mean that if the user doesn't compile PicoDLP driver, or the driver fails to probe, the two LCDs and the analog TV out would also fail. Many of the boards don't even have a PicoDLP module installed, so a fail there somewhere is guaranteed. > This is why we now have the component helpers in the driver model - > to allow devices to be collected together into one logical subsystem > group, and bound/unbound as a group. Yep, it's a good start. The component helpers could well be used with CDF. But if I'm not mistaken, it suffers from the problems above, when there are multiple independent pipelines (simultaneous or non-simultaneous) handled by the same IPs. And, while I may be mistaken, it sounds that the component helpers leave mostly everything up to the display drivers. Everyone devising their own way to describe the hardware in DT, and the connections between the components. Of course, the core component system shouldn't define anything DT related, as it doesn't. But that part is still needed, which is where CDF comes in. In my opinion, the component helpers or similar would be used with CDF in the beginning, because DRM doesn't support hotplug. Eventually we should get some kind of basic hotplug support, so that we could add display pipelines when they are ready. I need to ask Dave why he is so strongly opposed to hotplugging components. > Remember that "hotplugging" in this context does not mean that the > user can physically do something with the hardware. It means that > they're separate devices which can be probed/removed at will. Every > device in Linux can be bound and unbound from its driver at any time > by userspace, and that is something which is expected to be handled > gracefully. Hmm, sorry, can you rephrase? My use of hotplug in this context means roughly "add a new display, and whatever is related to that, when the drivers required have been probed". So with hotplug, a new fbdev or a combination of drm crtcs, encoders, etc, could appear even after the initial probe of the display controller. But all this is, I think, a bit aside the original point. The original point was about DT bindings. What kind of framework we have in the kernel side to handle the bindings is an interesting and very important topic, but they are not strictly tied together. Even if CDF is the worst thing ever, and needs to die quickly, I think the proposed DT bindings are still valid. They describe the hardware as precisely and as future-proofly as we've been able to come up with. People can use component helpers with them if they see that's a good approach. Or if on some beautiful day we get an agreement on CDF or something similar, and we can support hotplugging components, we already have proper DT bindings for it. Tomi
On Wed, Feb 26, 2014 at 02:44:02PM +0200, Tomi Valkeinen wrote: > > Also - DRM is not going to ever support hotplugging components - this > > was discussed at kernel summit last year and David Airlie was quite > > Ok. Very odd stance. Maybe there's a reason for it that I just don't see. DRM is like ALSA - it's a card level subsystem. All components have to be present before the card level is brought up for the subsystem to function correctly. > > adamant about that. So, any "framework" which forces hotplugging of > > components on subsystems isn't going to fly. > > CDF doesn't force hotplugging. > > Although without hotplugging (hot-unplug not needed), or at least some > minimal form of it, the system is a bit crippled. Leave one kernel > module out, or have one driver probe fail, the whole display subsystem > fails, even if some display pipelines would work fine. That is, unfortunately, one of the side effects of the policy - but that's not a policy that's going to change any time soon. As I said, that was made very clear at the last kernel summit - we had a /specific/ session on the issues around multi-device DRM chaired by David. There are some DRM drivers which have tried to do this, but they're all buggy in some regard, whether that be to the point of oopsing the kernel if things don't quite go to plan, or whether it's races between different parts. > > This is why we now have the component helpers in the driver model - > > to allow devices to be collected together into one logical subsystem > > group, and bound/unbound as a group. > > Yep, it's a good start. The component helpers could well be used with CDF. > > But if I'm not mistaken, it suffers from the problems above, when there > are multiple independent pipelines (simultaneous or non-simultaneous) > handled by the same IPs. It may "suffer from the problems above" that you've raised, but that's by explicit design of it - because that's what subsystems like DRM and ALSA require, and this is _precisely_ the problem it's solving. It's solving the "subsystem requires a stable view of hardware components, but we have multiple devices and drivers which need probing" problem. > And, while I may be mistaken, it sounds that the component helpers leave > mostly everything up to the display drivers. Everyone devising their own > way to describe the hardware in DT, and the connections between the > components. Of course, the core component system shouldn't define > anything DT related, as it doesn't. But that part is still needed, which > is where CDF comes in. Sigh. It's very easy for people to get the wrong end of the stick. What the component helpers do is provide a _subsystem_ _independent_ method of collecting a set of devices together and binding them to the drivers at an appropriate time, in a way that is _completely_ independent of whether you're using platform data, DT, ACPI, or whatever other hardware description language comes along. It's up to the users of this to define how components are grouped together, whether that be at the subsystem level or at the driver level - whatever is appropriate. If a subsystem (eg, a display subsystem) wants to define "this is how you define in DT the bindings between all components" and provide its own hook for the "add_components" callback which does this, then it's at liberty to do that. If we can come up with a generic way to describe how all the components in a display subsystem should be connected together, then great - but that needs to happen very quickly. Philipp Zabel is working on replacing the imx-drm binding method right now for 3.15, and is probably completely unaware of anything that's been talked about here. I need to sort out Armada DRM at some point to use the component stuff, which includes sorting out TDA998x for DT - which again needs to be done in such a way that it follows a common theme. > I need to ask Dave why he is so strongly opposed to hotplugging components. I suspect one reason for it is because it means rewriting the XF86 backend to Xorg to cope with it... > > Remember that "hotplugging" in this context does not mean that the > > user can physically do something with the hardware. It means that > > they're separate devices which can be probed/removed at will. Every > > device in Linux can be bound and unbound from its driver at any time > > by userspace, and that is something which is expected to be handled > > gracefully. > > Hmm, sorry, can you rephrase? I'll do better than that. Try running this script with the /sys/bus/.../drivers/whatever for the drivers you wish to test: #!/bin/sh for driver in "$@"; do if [ -f "${driver}/unbind" ]; then for device in "${driver}"/*; do if [ -d "${device}" ]; then devname="$(basename "${device}")" echo "$devname" > "${driver}/unbind" echo "$devname" > "${driver}/bind" fi done fi done The system should survive that. > So with hotplug, a new fbdev or a combination of drm crtcs, encoders, > etc, could appear even after the initial probe of the display controller. This is the exact situation that David is opposed to. DRM, like ALSA, whats to have a stable view of hardware - once the drm_device has been created and probed, no further changes to it are allowed. Certainly no changes to the CRTCs will _ever_ be permitted, because it completely destroys the user API for referecing which encoders can be associated with which CRTCs - not only at the kernel level, but also the Xorg and Xrandr level too. That's done via a bitmask of allowable CRTCs, where bit 0 refers to the first CRTC, bit 1 to the second and so on. That's propagated all the way through to userspace, right through the Xorg interfaces to applications. Connectors and encoders are fixed at the moment after initial probe time in DRM due to the way the fbdev emulation layer works. There's also issues there concerning bitmasks for which connectors can be cloned onto other connectors which follows the same pattern as above - and again, that propagates all the way through userspace. So, if this is going to get fixed, there has to be a desire to break userspace quite badly, and there is no such desire to do that. For instance, let's say that Xorg is up and running, and you have the gnome applet for configuring your display open, and you have two CRTCs. Then the first CRTC is removed from the system, resulting in CRTC 1 becoming CRTC 0 in the kernel. What happens... Think the same thing through for a system with three connectors, A, B, C numbered 0, 1, and 2 respectively. A and be cloned onto B. Now connector A is removed, meaning B and C appear to become numbers 0 and 1 in the kernel...
On 26/02/14 15:28, Russell King - ARM Linux wrote: > On Wed, Feb 26, 2014 at 02:44:02PM +0200, Tomi Valkeinen wrote: >>> Also - DRM is not going to ever support hotplugging components - this >>> was discussed at kernel summit last year and David Airlie was quite >> >> Ok. Very odd stance. Maybe there's a reason for it that I just don't see. > > DRM is like ALSA - it's a card level subsystem. All components have > to be present before the card level is brought up for the subsystem to > function correctly. Well, yes, at the moment. I don't know what his message was, but if it was "DRM won't get hotplug, even if someone would do it properly", that sounds just silly. >> But if I'm not mistaken, it suffers from the problems above, when there >> are multiple independent pipelines (simultaneous or non-simultaneous) >> handled by the same IPs. > > It may "suffer from the problems above" that you've raised, but that's > by explicit design of it - because that's what subsystems like DRM and > ALSA require, and this is _precisely_ the problem it's solving. > > It's solving the "subsystem requires a stable view of hardware components, > but we have multiple devices and drivers which need probing" problem. And that's good. What I'd like to avoid is developers using the component helpers, and designing the DT just for that use case, preventing the use of a possible future framework. The example in your component helper commit: imx-drm { compatible = "fsl,drm"; crtcs = <&ipu1>; connectors = <&hdmi>; }; How would that be extended if one imx board has an external HDMI encoder? Or maybe the board has an external HDMI encoder, and also a separate level-shifter/ESD chip like some OMAP boards have. Or maybe a board has two displays connected to one imx LCD output, and a GPIO is used to switch between the used display. Rephrasing: How would those DT bindings be extended to allow arbitrarily long or complex display pipelines? The proposed OMAP DSS and CDF DT bindings try to allow all the above cases. So in my opinion, using component helpers is good, but it'd be important to make sure the DT bindings for all platforms are future proof, and also compatible so that we can share encoder/panel drivers. >> And, while I may be mistaken, it sounds that the component helpers leave >> mostly everything up to the display drivers. Everyone devising their own >> way to describe the hardware in DT, and the connections between the >> components. Of course, the core component system shouldn't define >> anything DT related, as it doesn't. But that part is still needed, which >> is where CDF comes in. > > Sigh. It's very easy for people to get the wrong end of the stick. > > What the component helpers do is provide a _subsystem_ _independent_ > method of collecting a set of devices together and binding them to the > drivers at an appropriate time, in a way that is _completely_ independent > of whether you're using platform data, DT, ACPI, or whatever other > hardware description language comes along. Yep, that's what I meant with "Of course, the core component system shouldn't define anything DT related, as it doesn't.". Maybe that's not even English, so my bad =). > It's up to the users of this to define how components are grouped > together, whether that be at the subsystem level or at the driver > level - whatever is appropriate. > > If a subsystem (eg, a display subsystem) wants to define "this is how > you define in DT the bindings between all components" and provide its > own hook for the "add_components" callback which does this, then it's > at liberty to do that. > > If we can come up with a generic way to describe how all the components > in a display subsystem should be connected together, then great - but > that needs to happen very quickly. Philipp Zabel is working on replacing > the imx-drm binding method right now for 3.15, and is probably completely > unaware of anything that's been talked about here. I need to sort out Yes, I just pinged him a few hours ago about this. I've been ill for a few weeks, so I'm catching up on emails, but I want to sync with him asap to see if the OMAP DSS side and his imx series have things in common. > Armada DRM at some point to use the component stuff, which includes > sorting out TDA998x for DT - which again needs to be done in such a way > that it follows a common theme. BeagleBoneBlack has TDA998x, so I'm also very interested in that. >> So with hotplug, a new fbdev or a combination of drm crtcs, encoders, >> etc, could appear even after the initial probe of the display controller. > > This is the exact situation that David is opposed to. DRM, like ALSA, > whats to have a stable view of hardware - once the drm_device has been > created and probed, no further changes to it are allowed. > > Certainly no changes to the CRTCs will _ever_ be permitted, because it > completely destroys the user API for referecing which encoders can be > associated with which CRTCs - not only at the kernel level, but also the > Xorg and Xrandr level too. That's done via a bitmask of allowable CRTCs, > where bit 0 refers to the first CRTC, bit 1 to the second and so on. > That's propagated all the way through to userspace, right through the Xorg > interfaces to applications. > > Connectors and encoders are fixed at the moment after initial probe time > in DRM due to the way the fbdev emulation layer works. There's also issues > there concerning bitmasks for which connectors can be cloned onto other > connectors which follows the same pattern as above - and again, that > propagates all the way through userspace. > > So, if this is going to get fixed, there has to be a desire to break > userspace quite badly, and there is no such desire to do that. > > For instance, let's say that Xorg is up and running, and you have the > gnome applet for configuring your display open, and you have two CRTCs. > Then the first CRTC is removed from the system, resulting in CRTC 1 > becoming CRTC 0 in the kernel. What happens... > > Think the same thing through for a system with three connectors, A, B, C > numbered 0, 1, and 2 respectively. A and be cloned onto B. Now connector > A is removed, meaning B and C appear to become numbers 0 and 1 in the > kernel... I specifically said "hot-unplug not needed". Fbs, crtcs, etc. could only appear, never to be removed individually. I don't see much benefit in supporting hot-unplug, but I see much benefit with hot-plug. And I'm sure there could be problems with only hot-plug, but I'd bet they are much simpler if we never remove the components individually. Usually, all the hot-plugging would happen before the rootfs is mounted. However, it'd still be possible to load a display driver as a module later, as long as any user (say, X) would be loaded after that. Do you see that model as overly problematic, possibly breaking the userspace API? Tomi
Hi Russell, On Wednesday 26 February 2014 13:28:56 Russell King - ARM Linux wrote: > On Wed, Feb 26, 2014 at 02:44:02PM +0200, Tomi Valkeinen wrote: > > > Also - DRM is not going to ever support hotplugging components - this > > > was discussed at kernel summit last year and David Airlie was quite > > > > Ok. Very odd stance. Maybe there's a reason for it that I just don't see. > > DRM is like ALSA - it's a card level subsystem. All components have > to be present before the card level is brought up for the subsystem to > function correctly. I agree with Tomi here, I believe hot-plug (without hot-unplug) would be useful in case part of a video pipeline fails to probe. In a multi-output system (let's say HDMI and DSI panel for instance) I'd like the HDMI output to work if the DSI panel driver isn't loaded. DRM doesn't support this, and will not in the near future, but let's just keep in mind that real use cases exist. I'm not asking anyone to implement DRM hot- plug support now, but the idea itself shouldn't be nacked if someone can come up with a proper implementation. > > > adamant about that. So, any "framework" which forces hotplugging of > > > components on subsystems isn't going to fly. > > > > CDF doesn't force hotplugging. > > > > Although without hotplugging (hot-unplug not needed), or at least some > > minimal form of it, the system is a bit crippled. Leave one kernel > > module out, or have one driver probe fail, the whole display subsystem > > fails, even if some display pipelines would work fine. > > That is, unfortunately, one of the side effects of the policy - but that's > not a policy that's going to change any time soon. As I said, that was > made very clear at the last kernel summit - we had a /specific/ session > on the issues around multi-device DRM chaired by David. > > There are some DRM drivers which have tried to do this, but they're all > buggy in some regard, whether that be to the point of oopsing the kernel > if things don't quite go to plan, or whether it's races between different > parts. > > > > This is why we now have the component helpers in the driver model - > > > to allow devices to be collected together into one logical subsystem > > > group, and bound/unbound as a group. > > > > Yep, it's a good start. The component helpers could well be used with CDF. > > > > But if I'm not mistaken, it suffers from the problems above, when there > > are multiple independent pipelines (simultaneous or non-simultaneous) > > handled by the same IPs. > > It may "suffer from the problems above" that you've raised, but that's > by explicit design of it - because that's what subsystems like DRM and > ALSA require, and this is _precisely_ the problem it's solving. > > It's solving the "subsystem requires a stable view of hardware components, > but we have multiple devices and drivers which need probing" problem. > > > And, while I may be mistaken, it sounds that the component helpers leave > > mostly everything up to the display drivers. Everyone devising their own > > way to describe the hardware in DT, and the connections between the > > components. Of course, the core component system shouldn't define > > anything DT related, as it doesn't. But that part is still needed, which > > is where CDF comes in. > > Sigh. It's very easy for people to get the wrong end of the stick. > > What the component helpers do is provide a _subsystem_ _independent_ > method of collecting a set of devices together and binding them to the > drivers at an appropriate time, in a way that is _completely_ independent > of whether you're using platform data, DT, ACPI, or whatever other > hardware description language comes along. I think we all agree here, the component framework is required to implement clean support for component-based, DT-based systems, but doesn't depend on DT and doesn't imply any specific DT binding. What I believe bother people is that the example you have goes in a direction that might not be future-proof, and should thus not be used as an example to create display-related DT bindings. My understanding is that it's just an example to illustrate the kind of use case that the component framework can help with, not a proper DT bindings example that should be followed to design now DT bindings. > It's up to the users of this to define how components are grouped > together, whether that be at the subsystem level or at the driver > level - whatever is appropriate. > > If a subsystem (eg, a display subsystem) wants to define "this is how > you define in DT the bindings between all components" and provide its > own hook for the "add_components" callback which does this, then it's > at liberty to do that. > > If we can come up with a generic way to describe how all the components > in a display subsystem should be connected together, then great - but > that needs to happen very quickly. Philipp Zabel is working on replacing > the imx-drm binding method right now for 3.15, and is probably completely > unaware of anything that's been talked about here. I need to sort out > Armada DRM at some point to use the component stuff, which includes > sorting out TDA998x for DT - which again needs to be done in such a way > that it follows a common theme. > > > I need to ask Dave why he is so strongly opposed to hotplugging > > components. > > I suspect one reason for it is because it means rewriting the XF86 > backend to Xorg to cope with it... <troll>The world is moving to Wayland anyway</troll> ;-) > > > Remember that "hotplugging" in this context does not mean that the > > > user can physically do something with the hardware. It means that > > > they're separate devices which can be probed/removed at will. Every > > > device in Linux can be bound and unbound from its driver at any time > > > by userspace, and that is something which is expected to be handled > > > gracefully. > > > > Hmm, sorry, can you rephrase? > > I'll do better than that. Try running this script with the > /sys/bus/.../drivers/whatever for the drivers you wish to test: > > #!/bin/sh > for driver in "$@"; do > if [ -f "${driver}/unbind" ]; then > for device in "${driver}"/*; do > if [ -d "${device}" ]; then > devname="$(basename "${device}")" > echo "$devname" > "${driver}/unbind" > echo "$devname" > "${driver}/bind" > fi > done > fi > done > > The system should survive that. I've kept this problem in the back of my head for some time now and I'm curious to know whether you have thought about how to solve it for component- based systems. Given that DRM doesn't support hot-unplug, is the solution based on preventing driver unbind by returning an error from the remove handler ? > > So with hotplug, a new fbdev or a combination of drm crtcs, encoders, > > etc, could appear even after the initial probe of the display controller. > > This is the exact situation that David is opposed to. DRM, like ALSA, > whats to have a stable view of hardware - once the drm_device has been > created and probed, no further changes to it are allowed. > > Certainly no changes to the CRTCs will _ever_ be permitted, because it > completely destroys the user API for referecing which encoders can be > associated with which CRTCs - not only at the kernel level, but also the > Xorg and Xrandr level too. That's done via a bitmask of allowable CRTCs, > where bit 0 refers to the first CRTC, bit 1 to the second and so on. > That's propagated all the way through to userspace, right through the Xorg > interfaces to applications. > > Connectors and encoders are fixed at the moment after initial probe time > in DRM due to the way the fbdev emulation layer works. There's also issues > there concerning bitmasks for which connectors can be cloned onto other > connectors which follows the same pattern as above - and again, that > propagates all the way through userspace. > > So, if this is going to get fixed, there has to be a desire to break > userspace quite badly, and there is no such desire to do that. > > For instance, let's say that Xorg is up and running, and you have the > gnome applet for configuring your display open, and you have two CRTCs. > Then the first CRTC is removed from the system, resulting in CRTC 1 > becoming CRTC 0 in the kernel. What happens... > > Think the same thing through for a system with three connectors, A, B, C > numbered 0, 1, and 2 respectively. A and be cloned onto B. Now connector > A is removed, meaning B and C appear to become numbers 0 and 1 in the > kernel...
diff --git a/arch/arm/boot/dts/omap4-duovero-parlor.dts b/arch/arm/boot/dts/omap4-duovero-parlor.dts index 96f51d8..d038242 100644 --- a/arch/arm/boot/dts/omap4-duovero-parlor.dts +++ b/arch/arm/boot/dts/omap4-duovero-parlor.dts @@ -15,6 +15,10 @@ model = "OMAP4430 Gumstix Duovero on Parlor"; compatible = "gumstix,omap4-duovero-parlor", "gumstix,omap4-duovero", "ti,omap4430", "ti,omap4"; + aliases { + display0 = &hdmi0; + }; + leds { compatible = "gpio-leds"; led0 { @@ -35,6 +39,15 @@ gpio-key,wakeup; }; }; + + hdmi0: connector@0 { + compatible = "hdmi-connector"; + label = "hdmi"; + + hdmi_connector_in: endpoint { + remote-endpoint = <&hdmi_out>; + }; + }; }; &omap4_pmx_core { @@ -77,6 +90,15 @@ 0x30 (PIN_INPUT_PULLUP | MUX_MODE3) /* gpmc_a24.gpio_48: amdix enabled */ >; }; + + dss_hdmi_pins: pinmux_dss_hdmi_pins { + pinctrl-single,pins = < + 0x58 (PIN_INPUT_PULLUP | MUX_MODE0) /* hdmi_hpd.hdmi_hpd */ + 0x5a (PIN_INPUT_PULLUP | MUX_MODE0) /* hdmi_cec.hdmi_cec */ + 0x5c (PIN_INPUT_PULLUP | MUX_MODE0) /* hdmi_ddc_scl.hdmi_ddc_scl */ + 0x5e (PIN_INPUT_PULLUP | MUX_MODE0) /* hdmi_ddc_sda.hdmi_ddc_sda */ + >; + }; }; &i2c2 { @@ -143,4 +165,18 @@ }; }; +&dss { + status = "ok"; +}; + +&hdmi { + status = "ok"; + + pinctrl-names = "default"; + pinctrl-0 = <&dss_hdmi_pins>; + + hdmi_out: endpoint { + remote-endpoint = <&hdmi_connector_in>; + }; +};
Add the necessary DTS nodes to enable the micro-HDMI output on Parlor board. Signed-off-by: Florian Vaussard <florian.vaussard@epfl.ch> --- arch/arm/boot/dts/omap4-duovero-parlor.dts | 36 ++++++++++++++++++++++++++++++ 1 file changed, 36 insertions(+)