Hi Jani,
On Monday 17 December 2012 18:53:37 Jani Nikula wrote:
> On Mon, 17 Dec 2012, Laurent Pinchart wrote:
> > On Friday 23 November 2012 16:51:37 Tomi Valkeinen wrote:
> >> On 2012-11-22 23:45, Laurent Pinchart wrote:
> >> > From: Laurent Pinchart <laurent.pinchart+renesas@xxxxxxxxxxxxxxxx>
> >> >
> >> > Hi everybody,
> >> >
> >> > Here's the second RFC of what was previously known as the Generic Panel
> >> > Framework.
> >>
> >> Nice work! Thanks for working on this.
> >>
> >> I was doing some testing with the code, seeing how to use it in omapdss.
> >> Here are some thoughts:
> >>
> >> In your model the DSS gets the panel devices connected to it from
> >> platform data. After the DSS and the panel drivers are loaded, DSS gets
> >> a notification and connects DSS and the panel.
> >>
> >> I think it's a bit limited way. First of all, it'll make the DT data a
> >> bit more complex (although this is not a major problem). With your
> >> model, you'll need something like:
> >>
> >> soc-base.dtsi:
> >>
> >> dss {
> >> dpi0: dpi {
> >> };
> >> };
> >>
> >> board.dts:
> >>
> >> &dpi0 {
> >> panel = &dpi-panel;
> >> };
> >>
> >> / {
> >> dpi-panel: dpi-panel {
> >> ...panel data...;
> >> };
> >> };
> >>
> >> Second, it'll prevent hotplug, and even if real hotplug would not be
> >> supported, it'll prevent cases where the connected panel must be found
> >> dynamically (like reading ID from eeprom).
> >
> > Hotplug definitely needs to be supported, as the common display framework
> > also targets HDMI and DP. The notification mechanism was actually
> > designed to support hotplug.
>
> I can see the need for a framework for DSI panels and such (in fact Tomi
> and I have talked about it like 2-3 years ago already!) but what is the
> story for HDMI and DP? In particular, what's the relationship between
> DRM and CDF here? Is there a world domination plan to switch the DRM
> drivers to use this framework too? ;) Do you have some rough plans how
> DRM and CDF should work together in general?
There's always a world domination plan, isn't there ? :-)
I certainly want CDF to be used by DRM (or more accurately KMS). That's what
the C stands for, common refers to sharing panel and other display entity
drivers between FBDEV, KMS and V4L2.
I currently have no plan to expose CDF internals to userspace through the KMS
API. We might have to do so later if the hardware complexity grows in such a
way that finer control than what KMS provides needs to be exposed to
userspace, but I don't think we're there yet. The CDF API will thus only be
used internally in the kernel by display controller drivers. The KMS core
might get functions to handle common display entity operations, but the bulk
of the work will be in the display controller drivers to start with. We will
then see what can be abstracted in KMS helper functions.
Regarding HDMI and DP, I imagine HDMI and DP drivers that would use the CDF
API. That's just a thought for now, I haven't tried to implement them, but it
would be nice to handle HDMI screens and DPI/DBI/DSI panels in a generic way.
Do you have thoughts to share on this topic ?
--
Regards,
Laurent Pinchart
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
