[RFC][PATCH] regulator: rpi-panel: Add regulator/backlight driver for RPi panel

[Marek Vasut]

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 at 45 {
    compatible = "raspberrypi,7inch-touchscreen-panel-regulator";
    reg = <0x45>;
  };
};

&ltdc {
  status = "okay";

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

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

  bridge at 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 at 0 {
        reg = <0>;
        bridge_in: endpoint {
          remote-endpoint = <&dsi_out>;
        };
      };

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

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

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

    port at 1 {
      reg = <1>;
      dsi_out: endpoint {
        remote-endpoint = <&bridge_in>;
      };
    };
  };
};