All of lore.kernel.org
 help / color / mirror / Atom feed
From: Maxime Ripard <maxime@cerno.tech>
To: Max Krummenacher <max.oss.09@gmail.com>
Cc: Marek Vasut <marex@denx.de>,
	Christoph Niedermaier <cniedermaier@dh-electronics.com>,
	Max Krummenacher <max.krummenacher@toradex.com>,
	Pengutronix Kernel Team <kernel@pengutronix.de>,
	David Airlie <airlied@linux.ie>, Sam Ravnborg <sam@ravnborg.org>,
	Sascha Hauer <s.hauer@pengutronix.de>,
	dri-devel@lists.freedesktop.org,
	DenysDrozdov <denys.drozdov@toradex.com>,
	Laurent Pinchart <laurent.pinchart@ideasonboard.com>,
	Shawn Guo <shawnguo@kernel.org>,
	Linux ARM <linux-arm-kernel@lists.infradead.org>,
	NXP Linux Team <linux-imx@nxp.com>
Subject: Re: [RFC PATCH] drm/panel: simple: panel-dpi: use bus-format to set bpc and bus_format
Date: Wed, 2 Mar 2022 15:21:42 +0100	[thread overview]
Message-ID: <20220302142142.zroy464l5etide2g@houat> (raw)
In-Reply-To: <CAEHkU3Womyq09Lz62SJohix5JywfKvBRvuWedqF1D7gvb+T2tQ@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 1353 bytes --]

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.

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.

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?

Maxime

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

WARNING: multiple messages have this Message-ID (diff)
From: Maxime Ripard <maxime@cerno.tech>
To: Max Krummenacher <max.oss.09@gmail.com>
Cc: Marek Vasut <marex@denx.de>,
	dri-devel@lists.freedesktop.org,
	Sascha Hauer <s.hauer@pengutronix.de>,
	Philipp Zabel <p.zabel@pengutronix.de>,
	Laurent Pinchart <laurent.pinchart@ideasonboard.com>,
	Fabio Estevam <festevam@gmail.com>,
	Linux ARM <linux-arm-kernel@lists.infradead.org>,
	DenysDrozdov <denys.drozdov@toradex.com>,
	David Airlie <airlied@linux.ie>,
	Christoph Niedermaier <cniedermaier@dh-electronics.com>,
	Pengutronix Kernel Team <kernel@pengutronix.de>,
	Sam Ravnborg <sam@ravnborg.org>, Shawn Guo <shawnguo@kernel.org>,
	Daniel Vetter <daniel@ffwll.ch>,
	NXP Linux Team <linux-imx@nxp.com>,
	Max Krummenacher <max.krummenacher@toradex.com>
Subject: Re: [RFC PATCH] drm/panel: simple: panel-dpi: use bus-format to set bpc and bus_format
Date: Wed, 2 Mar 2022 15:21:42 +0100	[thread overview]
Message-ID: <20220302142142.zroy464l5etide2g@houat> (raw)
In-Reply-To: <CAEHkU3Womyq09Lz62SJohix5JywfKvBRvuWedqF1D7gvb+T2tQ@mail.gmail.com>


[-- Attachment #1.1: Type: text/plain, Size: 1353 bytes --]

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.

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.

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?

Maxime

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

[-- Attachment #2: Type: text/plain, Size: 176 bytes --]

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

  reply	other threads:[~2022-03-02 14:21 UTC|newest]

Thread overview: 48+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-02-22  8:47 [RFC PATCH] drm/panel: simple: panel-dpi: use bus-format to set bpc and bus_format Max Krummenacher
2022-02-22  8:47 ` Max Krummenacher
2022-02-23 13:41 ` Maxime Ripard
2022-02-23 13:41   ` Maxime Ripard
2022-02-23 13:45   ` Marek Vasut
2022-02-23 13:45     ` Marek Vasut
2022-02-23 13:47     ` Maxime Ripard
2022-02-23 13:47       ` Maxime Ripard
2022-02-23 14:09       ` Marek Vasut
2022-02-23 14:09         ` Marek Vasut
2022-02-23 14:37         ` Maxime Ripard
2022-02-23 14:37           ` Maxime Ripard
2022-02-23 14:38           ` Marek Vasut
2022-02-23 14:38             ` Marek Vasut
2022-02-23 16:39             ` Maxime Ripard
2022-02-23 16:39               ` Maxime Ripard
2022-02-23 16:57               ` Marek Vasut
2022-02-23 16:57                 ` Marek Vasut
2022-02-23 15:25     ` Max Krummenacher
2022-02-23 15:25       ` Max Krummenacher
2022-03-02 14:21       ` Maxime Ripard [this message]
2022-03-02 14:21         ` Maxime Ripard
2022-03-02 16:22         ` Marek Vasut
2022-03-02 16:22           ` Marek Vasut
2022-03-07 15:26           ` Max Krummenacher
2022-03-07 15:26             ` Max Krummenacher
2022-03-18 16:35             ` Maxime Ripard
2022-03-18 16:35               ` Maxime Ripard
2022-03-18 17:05               ` Dave Stevenson
2022-03-18 17:05                 ` Dave Stevenson
2022-03-18 17:16                 ` Maxime Ripard
2022-03-18 17:16                   ` Maxime Ripard
2022-03-18 17:53                   ` Dave Stevenson
2022-03-18 17:53                     ` Dave Stevenson
2022-03-23  8:42                     ` Max Krummenacher
2022-03-23  8:42                       ` Max Krummenacher
2022-03-23 15:58                       ` Maxime Ripard
2022-03-23 15:58                         ` Maxime Ripard
2022-03-23 20:06                         ` Max Krummenacher
2022-03-23 20:06                           ` Max Krummenacher
2022-03-24  8:15                           ` Francesco Dolcini
2022-03-24  8:15                             ` Francesco Dolcini
2022-04-08 18:01                             ` Laurent Pinchart
2022-04-08 18:01                               ` Laurent Pinchart
2022-04-08 18:15                           ` Laurent Pinchart
2022-04-08 18:15                             ` Laurent Pinchart
2022-04-19 11:50                             ` Max Krummenacher
2022-04-19 11:50                               ` Max Krummenacher

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20220302142142.zroy464l5etide2g@houat \
    --to=maxime@cerno.tech \
    --cc=airlied@linux.ie \
    --cc=cniedermaier@dh-electronics.com \
    --cc=denys.drozdov@toradex.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=kernel@pengutronix.de \
    --cc=laurent.pinchart@ideasonboard.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-imx@nxp.com \
    --cc=marex@denx.de \
    --cc=max.krummenacher@toradex.com \
    --cc=max.oss.09@gmail.com \
    --cc=s.hauer@pengutronix.de \
    --cc=sam@ravnborg.org \
    --cc=shawnguo@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.