On 3/2/22 15:21, Maxime Ripard wrote:
Hi,
Hi,
Please try to avoid top posting
On Wed, Feb 23, 2022 at 04:25:19PM +0100, Max Krummenacher wrote:
The goal here is to set the element bus_format in the struct
panel_desc. This is an enum with the possible values defined in
include/uapi/linux/media-bus-format.h.
The enum values are not constructed in a way that you could calculate
the value from color channel width/shift/mapping/whatever. You rather
would have to check if the combination of color channel
width/shift/mapping/whatever maps to an existing value and otherwise
EINVAL out.
I don't see the value in having yet another way of how this
information can be specified and then having to write a more
complicated parser which maps the dt data to bus_format.
Generally speaking, sending an RFC without explicitly stating what you
want a comment on isn't very efficient.
Isn't that what RFC stands for -- Request For Comment ?
That being said, what I (and I can only assume Marek) don't like is the
string encoding. Especially when the similar bus-type property uses a
integer with the various available bus options we have.
Right, the string encoding isn't good.
Having an integer, with a set of defines that you would map to the
proper MEDIA_BUS_* would be more efficient and more elegant.
That being said, the first question that needs to be answered is why
does this have to be in the DT in the first place?
Because panel-simple panel-dpi , you may need to specify the bus format
between the last bridge and the panel .
