[PATCH 2/2] ARM: dts: duovero-parlor: Add HDMI output

[Tomi Valkeinen]

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


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 901 bytes
Desc: OpenPGP digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140226/2df1d694/attachment.sig>