devicetree.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Maxime Ripard <mripard@kernel.org>
To: Hans de Goede <hdegoede@redhat.com>
Cc: Thomas Zimmermann <tzimmermann@suse.de>,
	 Krzysztof Kozlowski <krzk@kernel.org>,
	Luca Weiss <luca.weiss@fairphone.com>,
	 Maarten Lankhorst <maarten.lankhorst@linux.intel.com>,
	David Airlie <airlied@gmail.com>,
	 Simona Vetter <simona@ffwll.ch>, Rob Herring <robh@kernel.org>,
	 Krzysztof Kozlowski <krzk+dt@kernel.org>,
	Conor Dooley <conor+dt@kernel.org>,
	 Javier Martinez Canillas <javierm@redhat.com>,
	Helge Deller <deller@gmx.de>,
	linux-fbdev@vger.kernel.org,  dri-devel@lists.freedesktop.org,
	devicetree@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2 1/5] dt-bindings: display: simple-framebuffer: Add interconnects property
Date: Thu, 3 Jul 2025 11:41:44 +0200	[thread overview]
Message-ID: <20250703-light-baboon-of-experiment-179ca3@houat> (raw)
In-Reply-To: <f5fe3fe1-903a-48ca-9249-b77bc07dbc77@redhat.com>

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

On Thu, Jul 03, 2025 at 10:34:23AM +0200, Hans de Goede wrote:
> Hi Thomas,
> 
> On 3-Jul-25 8:47 AM, Thomas Zimmermann wrote:
> > Hi
> > 
> > Am 02.07.25 um 22:43 schrieb Krzysztof Kozlowski:
> >> On 30/06/2025 10:40, Hans de Goede wrote:
> >>>> No one asks to drop them from the driver. I only want specific front
> >>>> compatible which will list and constrain the properties. It is not
> >>>> contradictory to your statements, U-boot support, driver support. I
> >>>> really do not see ANY argument why this cannot follow standard DT rules.
> >>> So what you are saying is that you want something like:
> >>>
> >>> framebuffer0: framebuffer@1d385000 {
> >>>     compatible = "qcom.simple-framebuffer-sm8650-mdss", "simple-framebuffer";
> >>> }
> >>>
> >>> and that the binding for qcom.simple-framebuffer-sm8650-mdss
> >>> can then list interconnects ?
> >> IMO yes (after adjusting above to coding style), but as mentioned in
> >> other response you can just get an ack or opinion from Rob or Conor.
> > 
> > But does that work with *any* device that requires interconnects? The next such simple-framebuffer device should work out of the box *without* the kernel knowing anything about it. That's one of the key features of the simple-framebuffer.  If we have to maintainer per-device feature sets, it breaks that assumption.
> 
> The driver code for this can still be generic and since the driver
> will bind to the fallback plain "simple-framebuffer" compatible
> this should also work for new platforms.
> 
> The e.g. "qcom.simple-framebuffer-sm8650-mdss" compatible would
> purely be something in the dt-bindings to document which simplefb
> implementations will have interconnects and which ones will not.
> 
> The driver does not necessarily need to check these more
> precise compatibles, it can still just check for the generic
> presence of interconnects.

This ship has kind of sailed though. This binding has been used by
plenty of firmwares and bootloaders over the years, and has been
deployed on plenty of devices already.

Good luck fixing it in all of them, and then updating every device.

Maxime

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

  parent reply	other threads:[~2025-07-03  9:41 UTC|newest]

Thread overview: 49+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-06-23  6:44 [PATCH v2 0/5] Add interconnent support for simpledrm/simplefb Luca Weiss
2025-06-23  6:44 ` [PATCH v2 1/5] dt-bindings: display: simple-framebuffer: Add interconnects property Luca Weiss
2025-06-27  7:40   ` Javier Martinez Canillas
2025-06-27  8:08   ` Krzysztof Kozlowski
2025-06-27  9:48     ` Luca Weiss
2025-06-27 10:06       ` Javier Martinez Canillas
2025-06-28 11:49       ` Krzysztof Kozlowski
2025-06-29 12:07         ` Hans de Goede
2025-06-30  8:24           ` Krzysztof Kozlowski
2025-06-30  8:38             ` Maxime Ripard
2025-06-30  9:36               ` Krzysztof Kozlowski
2025-06-30 10:10                 ` Hans de Goede
2025-06-30 10:45                 ` Maxime Ripard
2025-06-30  8:40             ` Hans de Goede
2025-07-02 20:43               ` Krzysztof Kozlowski
2025-07-03  6:47                 ` Thomas Zimmermann
2025-07-03  8:34                   ` Hans de Goede
2025-07-03  8:41                     ` Thomas Zimmermann
2025-07-03  9:41                     ` Maxime Ripard [this message]
2025-07-03  9:45                       ` Krzysztof Kozlowski
2025-07-06 11:24                 ` Dmitry Baryshkov
2025-07-11  7:49                   ` Luca Weiss
2025-07-11  7:56                     ` Krzysztof Kozlowski
2025-06-30  6:26         ` Thomas Zimmermann
2025-06-27 11:34     ` Thomas Zimmermann
2025-06-28 11:50       ` Krzysztof Kozlowski
2025-06-30  6:34         ` Thomas Zimmermann
2025-06-30  7:26           ` Hans de Goede
2025-06-30  7:46             ` Thomas Zimmermann
2025-06-23  6:44 ` [PATCH v2 2/5] drm/sysfb: simpledrm: Sort headers correctly Luca Weiss
2025-06-27  7:41   ` Javier Martinez Canillas
2025-06-27  7:41   ` Thomas Zimmermann
2025-06-23  6:44 ` [PATCH v2 3/5] drm/sysfb: simpledrm: Add support for interconnect paths Luca Weiss
2025-06-27  7:51   ` Javier Martinez Canillas
2025-07-11  7:43     ` Luca Weiss
2025-07-11  9:21       ` Javier Martinez Canillas
2025-08-27  8:42         ` Luca Weiss
2025-07-06 11:14   ` Dmitry Baryshkov
2025-07-09 11:59     ` Luca Weiss
2025-06-23  6:44 ` [PATCH v2 4/5] fbdev/simplefb: Sort headers correctly Luca Weiss
2025-06-27  7:43   ` Thomas Zimmermann
2025-06-27  7:52   ` Javier Martinez Canillas
2025-06-23  6:44 ` [PATCH v2 5/5] fbdev/simplefb: Add support for interconnect paths Luca Weiss
2025-06-27  7:56   ` Javier Martinez Canillas
2025-06-27  9:51     ` Luca Weiss
2025-06-27 10:02       ` Javier Martinez Canillas
2025-06-27 11:36     ` Thomas Zimmermann
2025-06-27 11:43       ` Javier Martinez Canillas
2025-06-23  8:17 ` [PATCH v2 0/5] Add interconnent support for simpledrm/simplefb Hans de Goede

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=20250703-light-baboon-of-experiment-179ca3@houat \
    --to=mripard@kernel.org \
    --cc=airlied@gmail.com \
    --cc=conor+dt@kernel.org \
    --cc=deller@gmx.de \
    --cc=devicetree@vger.kernel.org \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=hdegoede@redhat.com \
    --cc=javierm@redhat.com \
    --cc=krzk+dt@kernel.org \
    --cc=krzk@kernel.org \
    --cc=linux-fbdev@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=luca.weiss@fairphone.com \
    --cc=maarten.lankhorst@linux.intel.com \
    --cc=robh@kernel.org \
    --cc=simona@ffwll.ch \
    --cc=tzimmermann@suse.de \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).