Re: [PATCH 00/28] OMAP: DSS related board file changes
Hi, On 2013-03-28 14:48, Tomi Valkeinen wrote: So here are the DSS related board file changes for 3.10. First there are a bunch of patches adding the Kconfig options so that only one display device is created for a single video bus. Only Overo had more than two displays on the same bus, but unfortunately there were multiple boards with a setup that puts an LCD and DVI output on the same video bus. So the ifdeffery is not very nice. But, as discussed, this is the best way forward, and should be seen as a temporary solution until we get full DT support. Then the rest are converting the old omap_dss_device style displays to platform devices. Only TFP410, generic-dpi-panel, HDMI and Taal drivers have been converted yet, but those seem to form the bulk of the display options used. This series can be found from: git://gitorious.org/linux-omap-dss2/linux.git 3.10-lo/1-arch-dss These patches depend on a few dss header file changes. These header file changes can be found from: git://gitorious.org/linux-omap-dss2/linux.git 3.10/0-dss-headers If this series is applied without the relevant omapdss changes, everything compiles and the boards boot, but the converted displays do not work. The same happens if only the omapdss changes are applied, but not this series. The related omapdss changes can be found from: git://gitorious.org/linux-omap-dss2/linux.git 3.10/3-dss-dev-model I'll drop these patches and the branches mentioned above, as I don't have a solution to the multiple-displays-per-output problem. I'll continue looking at this, but it surely won't make into the next merge window. Tomi signature.asc Description: OpenPGP digital signature
Re: [PATCH 00/28] OMAP: DSS related board file changes
On 2013-03-31 11:39, Igor Grinberg wrote: On 03/28/13 18:48, Tomi Valkeinen wrote: On 2013-03-28 17:31, Igor Grinberg wrote: On 03/28/13 14:48, Tomi Valkeinen wrote: So here are the DSS related board file changes for 3.10. First there are a bunch of patches adding the Kconfig options so that only one display device is created for a single video bus. Only Overo had more than two displays on the same bus, but unfortunately there were multiple boards with a setup that puts an LCD and DVI output on the same video bus. Hmmm, so basically, if one could switch the display at runtime... This cannot be done anymore... This sounds like feature removal, no? I know several of our clients who used this feature (at least for evaluation purposes). At some point in time it was possible to have multiple displays for the same bus, and switch them at runtime. Sometime later it was changed so that the board file adds all the displays, but only one (per bus) is actually added to the list of panels, but you could still set the default display in the kernel args, and thus you could select which display gets added. Yeah, I remember we had to hack this to have the functionality back... Ok. You could've informed me so that I knew it's needed =). I've received no complaints about it, so I thought nobody is even using it. The reason why the multiple-displays-per-bus is problematic is that the video bus cannot be shared, and if we have multiple devices on the same bus, the drivers need extra trickery, delaying initializations, etc, to handle this. And it still doesn't work right, as it's easy to get two displays enabled at the same time, configuring the same video bus, creating a mess. Yep, looks like additional display manager framework is needed. Which will manage the displays on per bus basis? Quite often the case is that the other displays are not even present physically. But it is true that some boards have gpio switches that can be used to change the display during runtime. I don't think the runtime switch requirement will ever go away, so we'd better prepare for it wisely. Is there any strong pros you obtain while removing this feature? For an user, only indirectly. The change will make things sane on the display side, and will thus make it much easier to proceed towards DT adaptation, and Common Display Framework. While I can't say it's a strict must to remove this feature, I can say that it's been a constant headache for me for, well, ever. And I presume CDF would not have this feature anyway, as it's rather bad design. Well, I don't know about the CDF, but the runtime switch was there for ages... Think of a DVI or an HDMI... they have the EDID stuff to make the switch work as expected and it really brings multiple displays to the same video bus. I see this is only a meter of how we represent things. Instead of real EDID (or in addition), that comes with the display, currently we have the panel info already in the kernel and panel driver with board specific callbacks to make it work. So abstracting the above (in the long run) to CDF or some other framework, should suit everybody's needs. Probably, we will need board specific drivers, but that never was a problem... Comparing desktop DVI/HDMI to our case is not a very good comparison. For desktop DVI/HDMI there are no panel devices or such, so it's trivial to manage multiple outputs in the display driver. We need panel device hotplug/unplug support to make this work properly, and as there's no generic way to do that, we need board specific drivers to handle the hotplug/unplug. And we probably need some way to show the information about possible displays to the userspace. I mean, with a case like DVI/Panel on the board, it would make sense to show the userspace that there are those two options, even if the other device is not even present. Tomi signature.asc Description: OpenPGP digital signature
Re: [PATCH 00/28] OMAP: DSS related board file changes
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 04/02/13 11:01, Tomi Valkeinen wrote: On 2013-03-31 11:39, Igor Grinberg wrote: On 03/28/13 18:48, Tomi Valkeinen wrote: On 2013-03-28 17:31, Igor Grinberg wrote: On 03/28/13 14:48, Tomi Valkeinen wrote: So here are the DSS related board file changes for 3.10. First there are a bunch of patches adding the Kconfig options so that only one display device is created for a single video bus. Only Overo had more than two displays on the same bus, but unfortunately there were multiple boards with a setup that puts an LCD and DVI output on the same video bus. Hmmm, so basically, if one could switch the display at runtime... This cannot be done anymore... This sounds like feature removal, no? I know several of our clients who used this feature (at least for evaluation purposes). At some point in time it was possible to have multiple displays for the same bus, and switch them at runtime. Sometime later it was changed so that the board file adds all the displays, but only one (per bus) is actually added to the list of panels, but you could still set the default display in the kernel args, and thus you could select which display gets added. Yeah, I remember we had to hack this to have the functionality back... Ok. You could've informed me so that I knew it's needed =). I've received no complaints about it, so I thought nobody is even using it. Yeah, I know, we wanted to make sure that this is not our fault and when we did and it worked, I've lost in the amount of patches for DSS that were sent and what are the real intentions (also taking into account that it all was post factum). The reason why the multiple-displays-per-bus is problematic is that the video bus cannot be shared, and if we have multiple devices on the same bus, the drivers need extra trickery, delaying initializations, etc, to handle this. And it still doesn't work right, as it's easy to get two displays enabled at the same time, configuring the same video bus, creating a mess. Yep, looks like additional display manager framework is needed. Which will manage the displays on per bus basis? Quite often the case is that the other displays are not even present physically. But it is true that some boards have gpio switches that can be used to change the display during runtime. I don't think the runtime switch requirement will ever go away, so we'd better prepare for it wisely. Is there any strong pros you obtain while removing this feature? For an user, only indirectly. The change will make things sane on the display side, and will thus make it much easier to proceed towards DT adaptation, and Common Display Framework. While I can't say it's a strict must to remove this feature, I can say that it's been a constant headache for me for, well, ever. And I presume CDF would not have this feature anyway, as it's rather bad design. Well, I don't know about the CDF, but the runtime switch was there for ages... Think of a DVI or an HDMI... they have the EDID stuff to make the switch work as expected and it really brings multiple displays to the same video bus. I see this is only a meter of how we represent things. Instead of real EDID (or in addition), that comes with the display, currently we have the panel info already in the kernel and panel driver with board specific callbacks to make it work. So abstracting the above (in the long run) to CDF or some other framework, should suit everybody's needs. Probably, we will need board specific drivers, but that never was a problem... Comparing desktop DVI/HDMI to our case is not a very good comparison. For desktop DVI/HDMI there are no panel devices or such, so it's trivial to manage multiple outputs in the display driver. Well, reading EDID can sometimes involve additional hackery, but you are right in the general case. We need panel device hotplug/unplug support to make this work properly, and as there's no generic way to do that, we need board specific drivers to handle the hotplug/unplug. Yep, I don't see any problem with having board specific drivers. Multiple subsystems have them, so we also can have them in CDF. And we probably need some way to show the information about possible displays to the userspace. I mean, with a case like DVI/Panel on the board, it would make sense to show the userspace that there are those two options, even if the other device is not even present. Indeed this is needed for the runtime switch. - -- Regards, Igor. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJRWplwAAoJEBDE8YO64EfaKH4P/jaMuXrGyvCmfYgD5OLFU0fV BvsLyy0/DVqoDjB2N8YH8PnuixKrP17L8nEDckq725byXf/ZQEIaYTeyBZ/COYDD NGAkVn8sFe2w7FLsg+dVa2+GSgYL2Pprvvf4DrJy1JMepBsDlaSkZL7V5LOq7m7J 7PIMizeZIngeDy4OHu4BNAksylPUj/3iqPDGJ9BZpgzoj1TwbPDG/ECyKADD9J8+
Re: [PATCH 00/28] OMAP: DSS related board file changes
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 03/28/13 18:48, Tomi Valkeinen wrote: On 2013-03-28 17:31, Igor Grinberg wrote: On 03/28/13 14:48, Tomi Valkeinen wrote: So here are the DSS related board file changes for 3.10. First there are a bunch of patches adding the Kconfig options so that only one display device is created for a single video bus. Only Overo had more than two displays on the same bus, but unfortunately there were multiple boards with a setup that puts an LCD and DVI output on the same video bus. Hmmm, so basically, if one could switch the display at runtime... This cannot be done anymore... This sounds like feature removal, no? I know several of our clients who used this feature (at least for evaluation purposes). At some point in time it was possible to have multiple displays for the same bus, and switch them at runtime. Sometime later it was changed so that the board file adds all the displays, but only one (per bus) is actually added to the list of panels, but you could still set the default display in the kernel args, and thus you could select which display gets added. Yeah, I remember we had to hack this to have the functionality back... The reason why the multiple-displays-per-bus is problematic is that the video bus cannot be shared, and if we have multiple devices on the same bus, the drivers need extra trickery, delaying initializations, etc, to handle this. And it still doesn't work right, as it's easy to get two displays enabled at the same time, configuring the same video bus, creating a mess. Yep, looks like additional display manager framework is needed. Which will manage the displays on per bus basis? Quite often the case is that the other displays are not even present physically. But it is true that some boards have gpio switches that can be used to change the display during runtime. I don't think the runtime switch requirement will ever go away, so we'd better prepare for it wisely. Is there any strong pros you obtain while removing this feature? For an user, only indirectly. The change will make things sane on the display side, and will thus make it much easier to proceed towards DT adaptation, and Common Display Framework. While I can't say it's a strict must to remove this feature, I can say that it's been a constant headache for me for, well, ever. And I presume CDF would not have this feature anyway, as it's rather bad design. Well, I don't know about the CDF, but the runtime switch was there for ages... Think of a DVI or an HDMI... they have the EDID stuff to make the switch work as expected and it really brings multiple displays to the same video bus. I see this is only a meter of how we represent things. Instead of real EDID (or in addition), that comes with the display, currently we have the panel info already in the kernel and panel driver with board specific callbacks to make it work. So abstracting the above (in the long run) to CDF or some other framework, should suit everybody's needs. Probably, we will need board specific drivers, but that never was a problem... So the ifdeffery is not very nice. But, as discussed, this is the best way forward, and should be seen as a temporary solution until we get full DT support. I've missed this discussion, can you please point to it? Well, not so much discussion, but a few mails under Display related board specific boot args subject on l-o. I proposed a board specific kernel argument to select the displays present, Tony was less than enthusiastic about that. Yes, I can understand that ;-) And what will change with full DT support? Will we be able to define several displays through DT and select and active one during runtime? No, not as such. DT will let the bootloader pass the DT data, thus telling which displays are present. So we can have single kernel binary, which will work for all the cases. IMO, single kernel binary is a must. Dynamic switching during runtime will still be missing. This is not good, as it removes a functionality that worked before... For that I think we need board specific drivers. That driver should know about board specific restrictions etc (which are rather missing currently), remove the old display device, and create the new one. Well, yes we need a board specific drivers, but we need even more... Board specific driver should not poke with devices... I think for that we will need some kind of generic display manager (may be a part of CDF) that will deal with the device registration/removal and board specific drivers should implement some kind of API of the generic display manger. Well, actually, if there was a way to add a device while somehow marking it so that no driver will be bound to it... Then the user could use the standard sysfs interface to bind a driver to the device. I wonder if that could be done... I don't think this can fit current platform device framework. But may
Re: [PATCH 00/28] OMAP: DSS related board file changes
On 03/28/13 18:57, Tony Lindgren wrote: * Tomi Valkeinen tomi.valkei...@ti.com [130328 09:53]: On 2013-03-28 17:31, Igor Grinberg wrote: On 03/28/13 14:48, Tomi Valkeinen wrote: I've missed this discussion, can you please point to it? Well, not so much discussion, but a few mails under Display related board specific boot args subject on l-o. I proposed a board specific kernel argument to select the displays present, Tony was less than enthusiastic about that. If we can come up with a Linux generic command line option to select the panel that can be supported also in the long run, I have no objections to that naturally. What I'm against is a temporary custom cmdline option until the board-*.c files go away as we don't want to support it in the long run. Agreed totally, the panel select option does not have to be board specific (and it better not be...). -- Regards, Igor. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/28] OMAP: DSS related board file changes
On Sun, Mar 31, 2013 at 11:39:01AM +0300, Igor Grinberg wrote: Well, actually, if there was a way to add a device while somehow marking it so that no driver will be bound to it... Then the user could use the standard sysfs interface to bind a driver to the device. I wonder if that could be done... I don't think this can fit current platform device framework. But may be I'm missing something... May be Greg can comment on this? Greg? I have no idea what you all are talking about, sorry. greg k-h -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/28] OMAP: DSS related board file changes
On 03/28/13 14:48, Tomi Valkeinen wrote: So here are the DSS related board file changes for 3.10. First there are a bunch of patches adding the Kconfig options so that only one display device is created for a single video bus. Only Overo had more than two displays on the same bus, but unfortunately there were multiple boards with a setup that puts an LCD and DVI output on the same video bus. Hmmm, so basically, if one could switch the display at runtime... This cannot be done anymore... This sounds like feature removal, no? I know several of our clients who used this feature (at least for evaluation purposes). Is there any strong pros you obtain while removing this feature? So the ifdeffery is not very nice. But, as discussed, this is the best way forward, and should be seen as a temporary solution until we get full DT support. I've missed this discussion, can you please point to it? And what will change with full DT support? Will we be able to define several displays through DT and select and active one during runtime? -- Regards, Igor. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/28] OMAP: DSS related board file changes
On 2013-03-28 17:31, Igor Grinberg wrote: On 03/28/13 14:48, Tomi Valkeinen wrote: So here are the DSS related board file changes for 3.10. First there are a bunch of patches adding the Kconfig options so that only one display device is created for a single video bus. Only Overo had more than two displays on the same bus, but unfortunately there were multiple boards with a setup that puts an LCD and DVI output on the same video bus. Hmmm, so basically, if one could switch the display at runtime... This cannot be done anymore... This sounds like feature removal, no? I know several of our clients who used this feature (at least for evaluation purposes). At some point in time it was possible to have multiple displays for the same bus, and switch them at runtime. Sometime later it was changed so that the board file adds all the displays, but only one (per bus) is actually added to the list of panels, but you could still set the default display in the kernel args, and thus you could select which display gets added. The reason why the multiple-displays-per-bus is problematic is that the video bus cannot be shared, and if we have multiple devices on the same bus, the drivers need extra trickery, delaying initializations, etc, to handle this. And it still doesn't work right, as it's easy to get two displays enabled at the same time, configuring the same video bus, creating a mess. Quite often the case is that the other displays are not even present physically. But it is true that some boards have gpio switches that can be used to change the display during runtime. Is there any strong pros you obtain while removing this feature? For an user, only indirectly. The change will make things sane on the display side, and will thus make it much easier to proceed towards DT adaptation, and Common Display Framework. While I can't say it's a strict must to remove this feature, I can say that it's been a constant headache for me for, well, ever. And I presume CDF would not have this feature anyway, as it's rather bad design. So the ifdeffery is not very nice. But, as discussed, this is the best way forward, and should be seen as a temporary solution until we get full DT support. I've missed this discussion, can you please point to it? Well, not so much discussion, but a few mails under Display related board specific boot args subject on l-o. I proposed a board specific kernel argument to select the displays present, Tony was less than enthusiastic about that. And what will change with full DT support? Will we be able to define several displays through DT and select and active one during runtime? No, not as such. DT will let the bootloader pass the DT data, thus telling which displays are present. So we can have single kernel binary, which will work for all the cases. Dynamic switching during runtime will still be missing. For that I think we need board specific drivers. That driver should know about board specific restrictions etc (which are rather missing currently), remove the old display device, and create the new one. Well, actually, if there was a way to add a device while somehow marking it so that no driver will be bound to it... Then the user could use the standard sysfs interface to bind a driver to the device. I wonder if that could be done... Tomi signature.asc Description: OpenPGP digital signature
Re: [PATCH 00/28] OMAP: DSS related board file changes
* Tomi Valkeinen tomi.valkei...@ti.com [130328 09:53]: On 2013-03-28 17:31, Igor Grinberg wrote: On 03/28/13 14:48, Tomi Valkeinen wrote: I've missed this discussion, can you please point to it? Well, not so much discussion, but a few mails under Display related board specific boot args subject on l-o. I proposed a board specific kernel argument to select the displays present, Tony was less than enthusiastic about that. If we can come up with a Linux generic command line option to select the panel that can be supported also in the long run, I have no objections to that naturally. What I'm against is a temporary custom cmdline option until the board-*.c files go away as we don't want to support it in the long run. Regards, Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
