On 11/05/2012 02:55 AM, Tomi Valkeinen wrote:
But even then, choosing the manager is not easy, as whoever chooses the
manager needs to observe all the possible displays used at the same time...
Right. I was wondering if omapfb/omapdrm could understand the 'all possible displays information' better compared to a panel's probe.
Even omapdrm/omafb can't be perfect because we could insert a panel driver module at any time, and omapfb/omapdrm may miss that out.
True, omapdrm/fb may have a better idea. It's still unclear though. Currently we have quite strict order in the sequence the modules need to be loaded, which is quite bad and causes issues. We should make things more dynamic, so that the initialization of the drivers could happen more freely.
But that creates more problems: when booting up, omapfb starts. But omapfb can't know if all the panel drivers have already been loaded. omapfb may see that DVI is the default display, but what should it do if DVI doesn't have a driver yet? It could wait, but perhaps the driver for DVI will never even be loaded.
The encoder which is connected to the crtc (manager) is picked by combination of encoder->possible_crtcs bitmask and connector->best_encoder(). We could keep things limited so that the association of crtc to encoder (manager to output, roughly) never changes, but this isn't really the right thing to do. It is better that the dssdev not rely on knowing the manager it is attached to at probe time, but instead grab resources more dynamically.
Also, at the moment we don't really have any notification to userspace about new encoders/connectors showing up (or conversely, being removed). Only about existing connectors being plugged/unplugged. The closest analogy is perhaps the USB display devices, but even there it is only the entire drm device that is plugged/unplugged. And TBH I don't really see the point in supporting panel drivers being dynamically loaded. It isn't like someone is dynamically soldering on a new display connector to some board that is running. I think omapfb or omapdrm probe should trigger registering the compiled-in panel drivers, so that it can be sure that the dssdev's pop up before it goes and creates drm connector objects. Currently we have to hack around this in omapdrm with late_initcall() to ensure the panel drivers are probed first, but that is an ugly hack that I'd like to get rid of.
BR, -R
On 2012-11-05 16:21, Rob Clark wrote:
On 11/05/2012 02:55 AM, Tomi Valkeinen wrote:
But even then, choosing the manager is not easy, as whoever chooses the
manager needs to observe all the possible displays used at the same time...
Right. I was wondering if omapfb/omapdrm could understand the 'all possible displays information' better compared to a panel's probe.
Even omapdrm/omafb can't be perfect because we could insert a panel driver module at any time, and omapfb/omapdrm may miss that out.
True, omapdrm/fb may have a better idea. It's still unclear though. Currently we have quite strict order in the sequence the modules need to be loaded, which is quite bad and causes issues. We should make things more dynamic, so that the initialization of the drivers could happen more freely.
But that creates more problems: when booting up, omapfb starts. But omapfb can't know if all the panel drivers have already been loaded. omapfb may see that DVI is the default display, but what should it do if DVI doesn't have a driver yet? It could wait, but perhaps the driver for DVI will never even be loaded.
The encoder which is connected to the crtc (manager) is picked by combination of encoder->possible_crtcs bitmask and connector->best_encoder(). We could keep things limited so that the association of crtc to encoder (manager to output, roughly) never changes, but this isn't really the right thing to do. It is better that the dssdev not rely on knowing the manager it is attached to at probe time, but instead grab resources more dynamically.
Also, at the moment we don't really have any notification to userspace about new encoders/connectors showing up (or conversely, being removed). Only about existing connectors being plugged/unplugged. The closest analogy is perhaps the USB display devices, but even there it is only the entire drm device that is plugged/unplugged. And TBH I don't really see the point in supporting panel drivers being dynamically loaded. It isn't like someone is dynamically soldering on a new display connector to some board that is running. I think omapfb or omapdrm probe should trigger registering the compiled-in panel drivers, so that it can be sure that the dssdev's pop up before it goes and creates drm connector objects. Currently we have to hack around this in omapdrm with late_initcall() to ensure the panel drivers are probed first, but that is an ugly hack that I'd like to get rid of.
We have panel devices and panel drivers, each of which can appear at any time. Both are needed for the panel probe to happen. If we don't support device hotplugging (dynamic creation of devices), we need to use late_initcall for omapfb/drm. At least I don't see any other option.
You say that omapdrm should trigger registering of the drivers. How would that work? Do you mean that the panel drivers would register themselves to some common list, and omapdrm would go through this list when drm is loaded, calling probe for the items in the list? I guess that's doable, but... It's not how kernel drivers are supposed to work, and so doesn't sound very clean approach to me.
I think we should support proper hotplugging of the panels. This would fix the problem about init order, but it would also give us device hotplug support. Obviously nobody is going to solder panel to a running board, but I don't see any reason why panels, or, more likely, panels on an add-on boards (like the capes being discussed in omap ml) would not be hotpluggable using whatever connector is used on the particular use case.
And even if we don't support removing of the devices, things like the add-on capes could cause the panel on the cape to be identified at some late time (the panel is not described in the board file or DT data, but found at runtime depending on the ID of the cape). This would add another step to the init sequence that should be just right, if we don't support hotplug.
Yes, I know it's not simple =). And I'm fine with simpler approach for the time being, but I'd like full hotplug to be the future goal. At least the common panel framework should not create restrictions about this, even if drm wouldn't allow device hotplug.
Tomi
On Tue, Nov 6, 2012 at 7:41 AM, Tomi Valkeinen tomba@iki.fi wrote:
On 2012-11-05 16:21, Rob Clark wrote:
On 11/05/2012 02:55 AM, Tomi Valkeinen wrote:
But even then, choosing the manager is not easy, as whoever chooses the
>manager needs to observe all the possible displays used at the same >time...
Right. I was wondering if omapfb/omapdrm could understand the 'all possible displays information' better compared to a panel's probe.
Even omapdrm/omafb can't be perfect because we could insert a panel driver module at any time, and omapfb/omapdrm may miss that out.
True, omapdrm/fb may have a better idea. It's still unclear though. Currently we have quite strict order in the sequence the modules need to be loaded, which is quite bad and causes issues. We should make things more dynamic, so that the initialization of the drivers could happen more freely.
But that creates more problems: when booting up, omapfb starts. But omapfb can't know if all the panel drivers have already been loaded. omapfb may see that DVI is the default display, but what should it do if DVI doesn't have a driver yet? It could wait, but perhaps the driver for DVI will never even be loaded.
The encoder which is connected to the crtc (manager) is picked by combination of encoder->possible_crtcs bitmask and connector->best_encoder(). We could keep things limited so that the association of crtc to encoder (manager to output, roughly) never changes, but this isn't really the right thing to do. It is better that the dssdev not rely on knowing the manager it is attached to at probe time, but instead grab resources more dynamically.
Also, at the moment we don't really have any notification to userspace about new encoders/connectors showing up (or conversely, being removed). Only about existing connectors being plugged/unplugged. The closest analogy is perhaps the USB display devices, but even there it is only the entire drm device that is plugged/unplugged. And TBH I don't really see the point in supporting panel drivers being dynamically loaded. It isn't like someone is dynamically soldering on a new display connector to some board that is running. I think omapfb or omapdrm probe should trigger registering the compiled-in panel drivers, so that it can be sure that the dssdev's pop up before it goes and creates drm connector objects. Currently we have to hack around this in omapdrm with late_initcall() to ensure the panel drivers are probed first, but that is an ugly hack that I'd like to get rid of.
We have panel devices and panel drivers, each of which can appear at any time. Both are needed for the panel probe to happen. If we don't support device hotplugging (dynamic creation of devices), we need to use late_initcall for omapfb/drm. At least I don't see any other option.
You say that omapdrm should trigger registering of the drivers. How would that work? Do you mean that the panel drivers would register themselves to some common list, and omapdrm would go through this list when drm is loaded, calling probe for the items in the list? I guess that's doable, but... It's not how kernel drivers are supposed to work, and so doesn't sound very clean approach to me.
I mean, similar to how we handle the subdev for dmm.. the omap_drm_init() does the platform_driver_register() for the dmm device before the platform_driver_register() for omapdrm itself, so we know if there is a dmm device, the driver gets probed first before omapdrm.
It could be a matter of iterating through a list, or something like this.. that is basically an implementation detail. But the end result is that the order the drivers are registered is controlled so the probe sequence works out properly (not to mention suspend/resume sequence).
I think we should support proper hotplugging of the panels. This would fix the problem about init order, but it would also give us device hotplug support. Obviously nobody is going to solder panel to a running board, but I don't see any reason why panels, or, more likely, panels on an add-on boards (like the capes being discussed in omap ml) would not be hotpluggable using whatever connector is used on the particular use case.
And even if we don't support removing of the devices, things like the add-on capes could cause the panel on the cape to be identified at some late time (the panel is not described in the board file or DT data, but found at runtime depending on the ID of the cape). This would add another step to the init sequence that should be just right, if we don't support hotplug.
If capes are really hot-pluggable, then maybe it is worth thinking about how to make this more dynamic. Although it is a bigger problem, which involves userspace being aware that connectors can dynamically appear/disappear. And the dynamic disappearing is something I worry about more.. it adds the possibility of all sorts of interesting race conditions, such as connectors disappearing in the middle of modeset. I prefer not making things more complicated and error prone than they need to be. If there is not a legitimate use case for connector hw dynamically appearing/disappearing then I don't think we should go there. It sounds nice and simple and clean, but in reality I think it just introduces a whole lot of ways for things to go wrong. A wise man once said:
https://github.com/robclark/kernel-omap4/blob/master/Documentation/Submittin...
BR, -R
Yes, I know it's not simple =). And I'm fine with simpler approach for the time being, but I'd like full hotplug to be the future goal. At least the common panel framework should not create restrictions about this, even if drm wouldn't allow device hotplug.
Tomi
-- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 2012-11-06 16:40, Rob Clark wrote:
I mean, similar to how we handle the subdev for dmm.. the omap_drm_init() does the platform_driver_register() for the dmm device before the platform_driver_register() for omapdrm itself, so we know if there is a dmm device, the driver gets probed first before omapdrm.
Well, I consider that a bit hacky too. That's not how linux device framework is supposed to be used. I know it makes life easier to do the registering like that, though.
It could be a matter of iterating through a list, or something like this.. that is basically an implementation detail. But the end result is that the order the drivers are registered is controlled so the probe sequence works out properly (not to mention suspend/resume sequence).
I feel that this kind of solution just tries to solve the generic problem of init/suspend ordering in a single driver, instead of fixing the device framework itself.
Or, of course it's possible that our drive architecture just sucks, and the device framework is fine. In that case the workaround is even worse, and we should fix our drivers.
I think we should support proper hotplugging of the panels. This would fix the problem about init order, but it would also give us device hotplug support. Obviously nobody is going to solder panel to a running board, but I don't see any reason why panels, or, more likely, panels on an add-on boards (like the capes being discussed in omap ml) would not be hotpluggable using whatever connector is used on the particular use case.
And even if we don't support removing of the devices, things like the add-on capes could cause the panel on the cape to be identified at some late time (the panel is not described in the board file or DT data, but found at runtime depending on the ID of the cape). This would add another step to the init sequence that should be just right, if we don't support hotplug.
If capes are really hot-pluggable, then maybe it is worth thinking about how to make this more dynamic. Although it is a bigger problem, which involves userspace being aware that connectors can dynamically appear/disappear. And the dynamic disappearing is something I worry about more.. it adds the possibility of all sorts of interesting race conditions, such as connectors disappearing in the middle of modeset. I prefer not making things more complicated and error prone than they need to be. If there is not a legitimate use case for connector hw dynamically appearing/disappearing then I don't think we should go there. It sounds nice and simple and clean, but in reality I think it just introduces a whole lot of ways for things to go wrong. A wise
Yes, I agree that it complicates things.
man once said:
https://github.com/robclark/kernel-omap4/blob/master/Documentation/Submittin...
I've done things simple lots of times in the omapdss driver, only to have to rewrite the thing in more complex way later to accommodate new scenarios. I think it's good to write the code in a bit more generic way than the use case at the moment of writing requires, because more often than not, it'll save time in the future.
Hotplugging is not some abstract future scenario, we already have hardware that could use it. For example, omap3 SDP board has a switchable output to DVI or LCD panel. In this case we know what the two options are, but the disabled component is still effectually removed from the system, and plugged back in when it's enabled.
Hotplug is not a high priority item, but I do wish we get it supported in common panel framework. Then it's at least possible to extend drm in the future to support it.
Anyway, this makes me wonder... omapdrm currently maps the elements of the whole video pipeline to drm elements (encoder, connector, etc). Would it make more sense to just map the DISPC to these drm elements? Connector would then be the output from DISPC.
This would map the drm elements to the static hardware blocks, and the meaning of those blocks would be quite similar to what they are in the desktop world (I guess).
The panel driver, the external chips, and the DSS internal output blocks (dsi, dpi, ...) would be handled separately from those drm elements. The DSS internal blocks are static, of course, but they can be effectively considered the same way as external chips.
The omapdrm driver needs of course to access those separate elements also, but that shouldn't be a problem. If omapdrm needs to call a function in the panel driver, all it needs to do is go through the chain to find the panel. Well, except if one output connected two two panels via a bridge chip...
And if drm is at some point extended to support panel drivers, or chains of external display entities, it would be easier to add that support.
What would it require the manage the elements like that? Would it help? It sounds to me that this would simplify the model.
Tomi
On Wed, Nov 7, 2012 at 4:01 AM, Tomi Valkeinen tomi.valkeinen@ti.com wrote:
On 2012-11-06 16:40, Rob Clark wrote:
I mean, similar to how we handle the subdev for dmm.. the omap_drm_init() does the platform_driver_register() for the dmm device before the platform_driver_register() for omapdrm itself, so we know if there is a dmm device, the driver gets probed first before omapdrm.
Well, I consider that a bit hacky too. That's not how linux device framework is supposed to be used. I know it makes life easier to do the registering like that, though.
It could be a matter of iterating through a list, or something like this.. that is basically an implementation detail. But the end result is that the order the drivers are registered is controlled so the probe sequence works out properly (not to mention suspend/resume sequence).
I feel that this kind of solution just tries to solve the generic problem of init/suspend ordering in a single driver, instead of fixing the device framework itself.
Or, of course it's possible that our drive architecture just sucks, and the device framework is fine. In that case the workaround is even worse, and we should fix our drivers.
well, I guess by splitting things up into many pieces, we push the device framework in ways that it is not pushed on desktop. But I've enough on my plate so I wasn't going to volunteer to try and fix that ;-)
controlling the order that the drivers are registered is currently the most straightforward way to not have problems w/ probe/init/suspend..
I think we should support proper hotplugging of the panels. This would fix the problem about init order, but it would also give us device hotplug support. Obviously nobody is going to solder panel to a running board, but I don't see any reason why panels, or, more likely, panels on an add-on boards (like the capes being discussed in omap ml) would not be hotpluggable using whatever connector is used on the particular use case.
And even if we don't support removing of the devices, things like the add-on capes could cause the panel on the cape to be identified at some late time (the panel is not described in the board file or DT data, but found at runtime depending on the ID of the cape). This would add another step to the init sequence that should be just right, if we don't support hotplug.
If capes are really hot-pluggable, then maybe it is worth thinking about how to make this more dynamic. Although it is a bigger problem, which involves userspace being aware that connectors can dynamically appear/disappear. And the dynamic disappearing is something I worry about more.. it adds the possibility of all sorts of interesting race conditions, such as connectors disappearing in the middle of modeset. I prefer not making things more complicated and error prone than they need to be. If there is not a legitimate use case for connector hw dynamically appearing/disappearing then I don't think we should go there. It sounds nice and simple and clean, but in reality I think it just introduces a whole lot of ways for things to go wrong. A wise
Yes, I agree that it complicates things.
man once said:
https://github.com/robclark/kernel-omap4/blob/master/Documentation/Submittin...
I've done things simple lots of times in the omapdss driver, only to have to rewrite the thing in more complex way later to accommodate new scenarios. I think it's good to write the code in a bit more generic way than the use case at the moment of writing requires, because more often than not, it'll save time in the future.
well, if it is not effecting userspace ABI, then I think, when in doubt I prefer to start simple. It can always be changed later if needed.
Hotplugging is not some abstract future scenario, we already have hardware that could use it. For example, omap3 SDP board has a switchable output to DVI or LCD panel. In this case we know what the two options are, but the disabled component is still effectually removed from the system, and plugged back in when it's enabled.
I would look at this as two different connectors which can not be used at the same time. You have this scenario with desktop graphics cards.
Hotplug is not a high priority item, but I do wish we get it supported in common panel framework. Then it's at least possible to extend drm in the future to support it.
Anyway, this makes me wonder... omapdrm currently maps the elements of the whole video pipeline to drm elements (encoder, connector, etc). Would it make more sense to just map the DISPC to these drm elements? Connector would then be the output from DISPC.
I think:
plane->overlay crtc->manager
is pretty clear. And really
encoder->output
should be the way it is.. on the branch w/ omapdss/omapdrm kms re-write, this is how it is for plane/crtc, except for now:
encoder+connector->dssdev
Basically the encoder is doing the "control" stuff (power on/off, set timings, etc), and the connector is only doing non control stuff (detect, reading edid, etc).
But I think this will probably change a bit as CFP comes into the picture. Currently the drm connector is somewhat a "passive" element, but I think this will have to change a bit w/ CFP.
This would map the drm elements to the static hardware blocks, and the meaning of those blocks would be quite similar to what they are in the desktop world (I guess).
The panel driver, the external chips, and the DSS internal output blocks (dsi, dpi, ...) would be handled separately from those drm elements. The DSS internal blocks are static, of course, but they can be effectively considered the same way as external chips.
I think dsi/dpi/etc map to encoder. The big question is where the panel's fit. But to userspace somehow this should look like connectors. I think:
encoder->output connector->panel
could work.. although connector is less passive than KMS currently assumes. And "panel" could really be a whole chain in the case of bridge chips, etc. I don't know, maybe there are better ways. But I think userspace really just wants to know "which monitor" which is basically connector.
The omapdrm driver needs of course to access those separate elements also, but that shouldn't be a problem. If omapdrm needs to call a function in the panel driver, all it needs to do is go through the chain to find the panel. Well, except if one output connected two two panels via a bridge chip...
yeah, that is a really ugly case in our hw since it is quite non-transparent (ie. implications about use of planes, etc).
And if drm is at some point extended to support panel drivers, or chains of external display entities, it would be easier to add that support.
What would it require the manage the elements like that? Would it help? It sounds to me that this would simplify the model.
I'm not really entirely sure.. other than at least other drivers supporting CFP will have the same requirements ;-)
I guess the two best options are either bury some sort of chain of panel drivers in the connector, or introduce some internal elements in DRM which are not necessarily visible to userspace. (Or at least userspace should have the option to ignore it for backwards compatibility. For atomic pageflip/modeset, the converting of everything to properties makes it easier to think about exposing new KMS mode object types to userspace.)
Either way, I think we need to break this into stages. And first stage is to ignore chains of panel drivers and just support single panel drivers (ignoring bridges, etc). I'm not entirely sure what the second stage should be, but am open to suggestions and seeing how it evolves.
BR, -R
Tomi
On 2012-11-07 16:32, Rob Clark wrote:
On Wed, Nov 7, 2012 at 4:01 AM, Tomi Valkeinen tomi.valkeinen@ti.com wrote:
Hotplugging is not some abstract future scenario, we already have hardware that could use it. For example, omap3 SDP board has a switchable output to DVI or LCD panel. In this case we know what the two options are, but the disabled component is still effectually removed from the system, and plugged back in when it's enabled.
I would look at this as two different connectors which can not be used at the same time. You have this scenario with desktop graphics cards.
Yes, that's an option with fixed amount of display devices. But doesn't work for capes.
Hotplug is not a high priority item, but I do wish we get it supported in common panel framework. Then it's at least possible to extend drm in the future to support it.
Anyway, this makes me wonder... omapdrm currently maps the elements of the whole video pipeline to drm elements (encoder, connector, etc). Would it make more sense to just map the DISPC to these drm elements? Connector would then be the output from DISPC.
I think:
plane->overlay crtc->manager
is pretty clear. And really
encoder->output
should be the way it is.. on the branch w/ omapdss/omapdrm kms
I'm not so sure. The output (dpi/dsi/hdmi...) is the second step in our chain. The primary "output" is in the DISPC module, the overlay manager. That's where the timings, pixel clock, etc. are programmed. The second step, our output, is really a converter IP. It receives the primary output, converts it and outputs something else. Just like an external converter chip would do.
And the output can be quite a bit anything. For example, with DBI or DSI command mode outputs we don't have any of the conventional video timings. It doesn't make sense to program, say, video blanking periods to those outputs. But even with DBI and DSI we do have video blanking periods in the DISPC's output, the ovl mgr.
Of course, at the end of the chain we have a panel that uses normal video timings (well, most likely but not necessarily), and so we could program those timings at the end of the chain, in the block before the panel. But even then the encoder doesn't really map to the DSS's output block, as the DSS's output block may not have the conventional timings (like DBI), or they may be something totally different than what we get in the end of the chain to the panel.
So I think mapping encoder to output will not work with multiple display blocks in a chain. Thus I'd see the encoder would better match the DISPC's output, or alternatively perhaps the block which is just before the panel (whatever that is, sometimes it can be OMAP's DSI/HDMI/etc). However, the latter may be a bit strange as the block could be an external component, possibly hotpluggable.
re-write, this is how it is for plane/crtc, except for now:
encoder+connector->dssdev
Basically the encoder is doing the "control" stuff (power on/off, set timings, etc), and the connector is only doing non control stuff (detect, reading edid, etc).
But I think this will probably change a bit as CFP comes into the picture. Currently the drm connector is somewhat a "passive" element, but I think this will have to change a bit w/ CFP.
This would map the drm elements to the static hardware blocks, and the meaning of those blocks would be quite similar to what they are in the desktop world (I guess).
The panel driver, the external chips, and the DSS internal output blocks (dsi, dpi, ...) would be handled separately from those drm elements. The DSS internal blocks are static, of course, but they can be effectively considered the same way as external chips.
I think dsi/dpi/etc map to encoder. The big question is where the panel's fit. But to userspace somehow this should look like connectors. I think:
encoder->output connector->panel
could work.. although connector is less passive than KMS currently assumes. And "panel" could really be a whole chain in the case of bridge chips, etc. I don't know, maybe there are better ways. But I think userspace really just wants to know "which monitor" which is basically connector.
Hmm yes. Well, even if we map encoder and connector to the ovl manager, the userspace could see which monitor there is. Obviously we need to make changes for that to work, but as a model it feels a lot more natural to me than using output and panel for encoder and connector.
Perhaps it's wrong to say "map connector to ovl mgr". It would be more like "this connector observes the chain connected to this ovl mgr", even though the connector wouldn't observe any block in the chain directly. Just observing the plug in/out status, etc.
But I think encoder really maps quite well directly to the output side of overlay manager.
The omapdrm driver needs of course to access those separate elements also, but that shouldn't be a problem. If omapdrm needs to call a function in the panel driver, all it needs to do is go through the chain to find the panel. Well, except if one output connected two two panels via a bridge chip...
yeah, that is a really ugly case in our hw since it is quite non-transparent (ie. implications about use of planes, etc).
Not really in this case. You're perhaps thinking about connecting two outputs to a single panel. Which is problematic also.
We don't have in sights a board that splits one output to two panels, so I think we should just ignore that for now. But two outputs for one panel is on the table.
And if drm is at some point extended to support panel drivers, or chains of external display entities, it would be easier to add that support.
What would it require the manage the elements like that? Would it help? It sounds to me that this would simplify the model.
I'm not really entirely sure.. other than at least other drivers supporting CFP will have the same requirements ;-)
I guess the two best options are either bury some sort of chain of panel drivers in the connector, or introduce some internal elements in DRM which are not necessarily visible to userspace. (Or at least userspace should have the option to ignore it for backwards compatibility. For atomic pageflip/modeset, the converting of everything to properties makes it easier to think about exposing new KMS mode object types to userspace.)
Yes, I don't think we should or need to expose these new elements to userspace, at least in the first place.
Tomi
On Wed, Nov 7, 2012 at 9:13 AM, Tomi Valkeinen tomi.valkeinen@ti.com wrote:
On 2012-11-07 16:32, Rob Clark wrote:
On Wed, Nov 7, 2012 at 4:01 AM, Tomi Valkeinen tomi.valkeinen@ti.com wrote:
Hotplugging is not some abstract future scenario, we already have hardware that could use it. For example, omap3 SDP board has a switchable output to DVI or LCD panel. In this case we know what the two options are, but the disabled component is still effectually removed from the system, and plugged back in when it's enabled.
I would look at this as two different connectors which can not be used at the same time. You have this scenario with desktop graphics cards.
Yes, that's an option with fixed amount of display devices. But doesn't work for capes.
Only if capes are hotpluggable.. otherwise probe what cape(s?) are present at boot time (is this possible to detect a cape from sw?), and create the associated connector(s).
Anyways, I think we are stretching a bit hard for use cases for hot-pluggable panels.. I just prefer to ignore hotplug for now and come back to it when there is a more legitimate use-case.
Hotplug is not a high priority item, but I do wish we get it supported in common panel framework. Then it's at least possible to extend drm in the future to support it.
Anyway, this makes me wonder... omapdrm currently maps the elements of the whole video pipeline to drm elements (encoder, connector, etc). Would it make more sense to just map the DISPC to these drm elements? Connector would then be the output from DISPC.
I think:
plane->overlay crtc->manager
is pretty clear. And really
encoder->output
should be the way it is.. on the branch w/ omapdss/omapdrm kms
I'm not so sure. The output (dpi/dsi/hdmi...) is the second step in our chain. The primary "output" is in the DISPC module, the overlay manager. That's where the timings, pixel clock, etc. are programmed. The second step, our output, is really a converter IP. It receives the primary output, converts it and outputs something else. Just like an external converter chip would do.
the timings, pixel clock, vblank/framedone irqs, that all maps to crtc.
encoder == converter, so I think this fits. "An encoder takes pixel data from a CRTC and converts it to a format suitable for any attached connectors" (from drm docbook)
And the output can be quite a bit anything. For example, with DBI or DSI command mode outputs we don't have any of the conventional video timings. It doesn't make sense to program, say, video blanking periods to those outputs. But even with DBI and DSI we do have video blanking periods in the DISPC's output, the ovl mgr.
the encoder has mode_fixup() which can alter the timings that end up getting set, which might be a way to account for this. I guess really it should be the panel driver that is telling the encoder what adjusted timings to give to the crtc.. so the panel driver doesn't quite map to connector.
Of course, at the end of the chain we have a panel that uses normal video timings (well, most likely but not necessarily), and so we could program those timings at the end of the chain, in the block before the panel. But even then the encoder doesn't really map to the DSS's output block, as the DSS's output block may not have the conventional timings (like DBI), or they may be something totally different than what we get in the end of the chain to the panel.
So I think mapping encoder to output will not work with multiple display blocks in a chain. Thus I'd see the encoder would better match the DISPC's output, or alternatively perhaps the block which is just before the panel (whatever that is, sometimes it can be OMAP's DSI/HDMI/etc). However, the latter may be a bit strange as the block could be an external component, possibly hotpluggable.
re-write, this is how it is for plane/crtc, except for now:
encoder+connector->dssdev
Basically the encoder is doing the "control" stuff (power on/off, set timings, etc), and the connector is only doing non control stuff (detect, reading edid, etc).
But I think this will probably change a bit as CFP comes into the picture. Currently the drm connector is somewhat a "passive" element, but I think this will have to change a bit w/ CFP.
This would map the drm elements to the static hardware blocks, and the meaning of those blocks would be quite similar to what they are in the desktop world (I guess).
The panel driver, the external chips, and the DSS internal output blocks (dsi, dpi, ...) would be handled separately from those drm elements. The DSS internal blocks are static, of course, but they can be effectively considered the same way as external chips.
I think dsi/dpi/etc map to encoder. The big question is where the panel's fit. But to userspace somehow this should look like connectors. I think:
encoder->output connector->panel
could work.. although connector is less passive than KMS currently assumes. And "panel" could really be a whole chain in the case of bridge chips, etc. I don't know, maybe there are better ways. But I think userspace really just wants to know "which monitor" which is basically connector.
Hmm yes. Well, even if we map encoder and connector to the ovl manager, the userspace could see which monitor there is. Obviously we need to make changes for that to work, but as a model it feels a lot more natural to me than using output and panel for encoder and connector.
well, what we call 'ovl mgr' is really where the (vblank) interrupt generation is. This really should be the crtc. I tried it differently initially, and it wasn't really working out.
Perhaps it's wrong to say "map connector to ovl mgr". It would be more like "this connector observes the chain connected to this ovl mgr", even though the connector wouldn't observe any block in the chain directly. Just observing the plug in/out status, etc.
But I think encoder really maps quite well directly to the output side of overlay manager.
The omapdrm driver needs of course to access those separate elements also, but that shouldn't be a problem. If omapdrm needs to call a function in the panel driver, all it needs to do is go through the chain to find the panel. Well, except if one output connected two two panels via a bridge chip...
yeah, that is a really ugly case in our hw since it is quite non-transparent (ie. implications about use of planes, etc).
Not really in this case. You're perhaps thinking about connecting two outputs to a single panel. Which is problematic also.
yes, sorry, I read that backwards..
We don't have in sights a board that splits one output to two panels, so I think we should just ignore that for now. But two outputs for one panel is on the table.
And if drm is at some point extended to support panel drivers, or chains of external display entities, it would be easier to add that support.
What would it require the manage the elements like that? Would it help? It sounds to me that this would simplify the model.
I'm not really entirely sure.. other than at least other drivers supporting CFP will have the same requirements ;-)
I guess the two best options are either bury some sort of chain of panel drivers in the connector, or introduce some internal elements in DRM which are not necessarily visible to userspace. (Or at least userspace should have the option to ignore it for backwards compatibility. For atomic pageflip/modeset, the converting of everything to properties makes it easier to think about exposing new KMS mode object types to userspace.)
Yes, I don't think we should or need to expose these new elements to userspace, at least in the first place.
It *might* be useful someday, if there are ever any settings for a bridge chip, etc, which we'd want to expose to userspace as properties.. but I think we can come back to that later.
BR, -R
Tomi
On 2012-11-07 21:18, Rob Clark wrote:
On Wed, Nov 7, 2012 at 9:13 AM, Tomi Valkeinen tomi.valkeinen@ti.com wrote:
On 2012-11-07 16:32, Rob Clark wrote:
On Wed, Nov 7, 2012 at 4:01 AM, Tomi Valkeinen tomi.valkeinen@ti.com wrote:
Hotplugging is not some abstract future scenario, we already have hardware that could use it. For example, omap3 SDP board has a switchable output to DVI or LCD panel. In this case we know what the two options are, but the disabled component is still effectually removed from the system, and plugged back in when it's enabled.
I would look at this as two different connectors which can not be used at the same time. You have this scenario with desktop graphics cards.
Yes, that's an option with fixed amount of display devices. But doesn't work for capes.
Only if capes are hotpluggable.. otherwise probe what cape(s?) are present at boot time (is this possible to detect a cape from sw?), and create the associated connector(s).
Well, a cape can be anything. For beaglebone they have capes with eeprom, and you can detect it.
The reason I'd like to have hotplug is that it would simplify panel drivers in the case where we have multiple possible panels for the same output, like the DVI/LCD case above for omap3 SDP.
If we don't have hotplug, then both DVI and LCD panel devices are present at the same time, and they will share resources. In the minimum they are sharing the video output, but more often than not they share gpios/powers/etc.
It's normal that a driver will acquire resources for its device in its probe, and thus we would have two drivers acquiring the same resources at boot time, leading to the other driver failing. We currently manage this by acquiring the resources late, only when the panel is being enabled. But I think that's rather ugly.
It would be much cleaner if the panel device does not exist at all if the panel is disconnected, and is created only when it is connected. This of course creates the problem of who is responsible for creating the panel device, and what triggers it. I think that's case specific, and for capes, it'd be the cape driver.
But then again, I guess it's acceptable that we don't allow changing the plugged-in panels at runtime. The user would have to select them with kernel parameters or such. I guess this would be ok for capes and development boards. I'm not aware of a production board that would switch panels at runtime, although I know these were on the table in Nokia.
Anyways, I think we are stretching a bit hard for use cases for hot-pluggable panels.. I just prefer to ignore hotplug for now and come back to it when there is a more legitimate use-case.
Ok, fair enough. But let's keep hotplug in mind, and if we're going to create code that would make hotplug impossible to implement, let's stop for a moment and think if we can do that in some other way.
I'm not so sure. The output (dpi/dsi/hdmi...) is the second step in our chain. The primary "output" is in the DISPC module, the overlay manager. That's where the timings, pixel clock, etc. are programmed. The second step, our output, is really a converter IP. It receives the primary output, converts it and outputs something else. Just like an external converter chip would do.
the timings, pixel clock, vblank/framedone irqs, that all maps to crtc.
encoder == converter, so I think this fits. "An encoder takes pixel data from a CRTC and converts it to a format suitable for any attached connectors" (from drm docbook)
Oh, ok. Then what you say makes sense. I thought encoder contains the timings, as you said previously: "Basically the encoder is doing the "control" stuff (power on/off, set timings, etc)".
In the case we have a long chain of display blocks, encoder could cover all of them, not just the output block of OMAP? I don't know where the panel goes, though.
And the output can be quite a bit anything. For example, with DBI or DSI command mode outputs we don't have any of the conventional video timings. It doesn't make sense to program, say, video blanking periods to those outputs. But even with DBI and DSI we do have video blanking periods in the DISPC's output, the ovl mgr.
the encoder has mode_fixup() which can alter the timings that end up getting set, which might be a way to account for this. I guess really it should be the panel driver that is telling the encoder what adjusted timings to give to the crtc.. so the panel driver doesn't quite map to connector.
The panel can't say what timings to give to crtc, it depends on what's between the crtc and the panel. In case of OMAP DSI, the dsi driver needs to specify the timings for crtc, based on the panel.
Tomi
dri-devel@lists.freedesktop.org
-
Rob Clark -
Rob Clark -
Tomi Valkeinen -
Tomi Valkeinen