From: Mark Brown <broonie@kernel.org>
To: Marek Vasut <marex@denx.de>
Cc: Sam Ravnborg <sam@ravnborg.org>, dri-devel@lists.freedesktop.org
Subject: Re: [RFC][PATCH] regulator: rpi-panel: Add regulator/backlight driver for RPi panel
Date: Sat, 1 Aug 2020 02:16:53 +0100 [thread overview]
Message-ID: <20200801011653.GD4510@sirena.org.uk> (raw)
In-Reply-To: <5cfc1d07-c8ce-47d7-8763-1efa0316d05a@denx.de>
[-- Attachment #1.1: Type: text/plain, Size: 1688 bytes --]
On Thu, Jul 30, 2020 at 09:37:48PM +0200, Marek Vasut wrote:
> On 7/30/20 9:13 PM, Mark Brown wrote:
> > On Thu, Jul 30, 2020 at 06:28:07PM +0200, Marek Vasut wrote:
> >> about it ? I can over-complicate this and split it into multiple
> >> drivers, but I don't think it's worth the complexity, considering that
> >> this is likely a one-off device which will never be re-used elsewhere,
> >> except on this one particular display module for RPi.
> > Now you've written that you've pretty much guaranteed someone's going to
> > use the same component elsewhere :)
> How? The firmware is closed and not available, neither is documentation
> for it, sadly.
Companies often find other markets for their one off things, the
original RPi is a great example of this!
> > I don't 100% follow how this would actually get used in a
> > system (perhaps the binding would help) but for these things if there's
> > only one tightly coupled user that's possible it's sometimes simpler to
> > just skip APIs and do things directly.
> That's what I'm trying to replace by this patch and tc358762 bridge
> driver and panel driver, the combined version is already in tree:
> drivers/gpu/drm/panel/panel-raspberrypi-touchscreen.c
> but the tc358762 is clearly a generic bridge and the panel is generic
> too, so combining it into one panel driver doesn't seem right.
I see, so this is the remaining bits. Perhaps the binding might help me
see how things fit together - I don't know anything about the system
really. It's not doing anything that looks like it should cause the
framework too many problems so I'm not overly worried from that point of
view but equally well it's obviously not ideal.
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
[-- Attachment #2: Type: text/plain, Size: 160 bytes --]
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
next prev parent reply other threads:[~2020-08-01 1:17 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-07-29 21:46 [RFC][PATCH] regulator: rpi-panel: Add regulator/backlight driver for RPi panel Marek Vasut
2020-07-30 15:59 ` Sam Ravnborg
2020-07-30 16:28 ` Marek Vasut
2020-07-30 19:13 ` Mark Brown
2020-07-30 19:37 ` Marek Vasut
2020-08-01 1:16 ` Mark Brown [this message]
2020-08-03 7:21 ` Marek Vasut
2020-08-03 19:48 ` Mark Brown
2020-08-03 22:29 ` Marek Vasut
2020-08-04 14:25 ` Mark Brown
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=20200801011653.GD4510@sirena.org.uk \
--to=broonie@kernel.org \
--cc=dri-devel@lists.freedesktop.org \
--cc=marex@denx.de \
--cc=sam@ravnborg.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.