dri-devel.lists.freedesktop.org archive mirror
 help / color / mirror / Atom feed
From: Marek Vasut <marex@denx.de>
To: Mark Brown <broonie@kernel.org>
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: Mon, 3 Aug 2020 09:21:25 +0200	[thread overview]
Message-ID: <20116f3c-64d7-0f52-b38a-56c62398a5e9@denx.de> (raw)
In-Reply-To: <20200801011653.GD4510@sirena.org.uk>

On 8/1/20 3:16 AM, Mark Brown wrote:
> 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 suspect the firmware in this ATTINY88 is written specifically for this
board, so I doubt re-use in its current form will happen. If there is
ever another display board, the firmware will likely be different to
match the new board. But that's all pure speculation.

>>> 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.

See below:

/ {
  panel: panel {
    compatible = "powertip,ph800480t013-idf02";
    power-supply = <&attiny>;
    backlight = <&attiny>;
    port {
      panel_in: endpoint {
        remote-endpoint = <&bridge_out>;
      };
    };
  };
};

&i2c {
  attiny: regulator@45 {
    compatible = "raspberrypi,7inch-touchscreen-panel-regulator";
    reg = <0x45>;
  };
};

&ltdc {
  status = "okay";

  port {
    ltdc_ep0_out: endpoint@0 {
      reg = <0>;
      remote-endpoint = <&dsi_in>;
    };
  };
};

&dsi {
  #address-cells = <1>;
  #size-cells = <0>;
  status = "okay";
  phy-dsi-supply = <&reg18>;

  bridge@0 {
    compatible = "toshiba,tc358762";
    reg = <0>;
    vddc-supply = <&attiny>;
    #address-cells = <1>;
    #size-cells = <0>;
    status = "okay";

    ports {
      #address-cells = <1>;
      #size-cells = <0>;

      port@0 {
        reg = <0>;
        bridge_in: endpoint {
          remote-endpoint = <&dsi_out>;
        };
      };

      port@1 {
        reg = <1>;
        bridge_out: endpoint {
          remote-endpoint = <&panel_in>;
        };
      };
    };
  };

  ports {
    #address-cells = <1>;
    #size-cells = <0>;

    port@0 {
      reg = <0>;
      dsi_in: endpoint {
        remote-endpoint = <&ltdc_ep0_out>;
      };
    };

    port@1 {
      reg = <1>;
      dsi_out: endpoint {
        remote-endpoint = <&bridge_in>;
      };
    };
  };
};
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

  reply	other threads:[~2020-08-03  8:21 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
2020-08-03  7:21           ` Marek Vasut [this message]
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=20116f3c-64d7-0f52-b38a-56c62398a5e9@denx.de \
    --to=marex@denx.de \
    --cc=broonie@kernel.org \
    --cc=dri-devel@lists.freedesktop.org \
    --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 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).