Re: [PATCH V7 11/12] Documentation: bridge: Add documentation for ps8622 DT properties

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




On 22/09/14 10:54, Thierry Reding wrote:

>> I wish all new display component bindings would use the video
>> ports/endpoints to describe the connections. It will be very difficult
>> to improve the display driver model later if we're missing such critical
>> pieces from the DT bindings.
> 
> I disagree. Why would we want to burden all devices with a bloated

I agree that the .dts becomes more bloated with video graph.

> binding and drivers with parsing a complex graph when it's not even

Hopefully not all drivers will need to do the parsing themselves. If
it's common stuff, I don't see why we can't have helpers to do the work.

> known that it will be necessary? Evidently this device works fine
> using the current binding. Just because there are bindings to describe

Well, I can write almost any kind of bindings, and then evidently my
device would work. For me, on my board.

> ports in a generic way doesn't mean it has to be applied everywhere.
> After all the concept of ports/endpoints applies to non-video devices
> too, yet we don't require the bindings for those devices to add ports
> or endpoints nodes.

I guess non-video devices haven't had need for those. I have had lots of
boards with video setup that cannot be represented with simple phandles.
I'm not sure if I have just been unlucky or what, but my understand is
that other people have encountered such boards also. Usually the
problems encountered there have been circumvented with some hacky video
driver for that specific board, or maybe a static configuration handled
by the boot loader.

> Also it won't be very difficult to extend the binding in a backwards
> compatible way if that becomes necessary.

I don't know about that. More or less all the cases I've encountered
where a binding has not been good from the start have been all but "not
very difficult".

Do we have a standard way of representing the video pipeline with simple
phandles? Or does everyone just do their own version? If there's no
standard way, it sounds it'll be a mess to support in the future.

If there's much objection to the bloatiness of video graphs, maybe we
could come up with an simpler alternative (like the phandles here), and
"standardize" it. Then, if common display framework or some such ever
realizes, we could say that if your driver uses CDF, you need to support
these video graph bindings and these simpler bindings to be compatible.

However, I do have a slight recollection that alternative
simplifications to the video graph were discussed at some point, and,
while I may remember wrong, I think it was not accepted. At least I had
one method to simplify the ports/endpoints, but that was removed from
the patches I had.

 Tomi


Attachment: signature.asc
Description: OpenPGP digital signature


[Index of Archives]     [Device Tree Compilter]     [Device Tree Spec]     [Linux Driver Backports]     [Video for Linux]     [Linux USB Devel]     [Linux PCI Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Yosemite Backpacking]
  Powered by Linux