Hi Xin Ji,
On Tue, Dec 29, 2020 at 02:50:48PM +0800, Xin Ji wrote:
> On Mon, Dec 28, 2020 at 05:08:56PM +0200, Laurent Pinchart wrote:
> > On Fri, Dec 25, 2020 at 07:01:09PM +0800, Xin Ji wrote:
> > > Add DPI flag for distinguish MIPI input signal type, DSI or DPI. Add
> > > swing setting for adjusting DP tx PHY swing
> > >
> > > Signed-off-by: Xin Ji <xji@xxxxxxxxxxxxxxxx>
> > > ---
> > > .../bindings/display/bridge/analogix,anx7625.yaml | 19 +++++++++++++++++++
> > > 1 file changed, 19 insertions(+)
> > >
> > > diff --git a/Documentation/devicetree/bindings/display/bridge/analogix,anx7625.yaml b/Documentation/devicetree/bindings/display/bridge/analogix,anx7625.yaml
> > > index 60585a4..34a7faf 100644
> > > --- a/Documentation/devicetree/bindings/display/bridge/analogix,anx7625.yaml
> > > +++ b/Documentation/devicetree/bindings/display/bridge/analogix,anx7625.yaml
> > > @@ -34,6 +34,14 @@ properties:
> > > description: used for reset chip control, RESET_N pin B7.
> > > maxItems: 1
> > >
> > > + anx,swing-setting:
> > > + $ref: /schemas/types.yaml#/definitions/uint32-array
> > > + description: an array of swing register setting for DP tx PHY
> >
> > Register values in DT are frowned upon.
>
> Hi Laurent Pinchart, as the different vendor has the different PCB layout,
> it effects DP CTS test result, so they may need config DP tx Swing register
> to adjust signal swing(the default swing setting is not satisfy for
> every platform). If we move the config code to driver file, it must define
> swing register setting for each vendor, so the DT is the best way. Do you
> have any idea for it if you don't agree to add in DT.
If it depends on the PCB layout then it should indeed be in DT. What I
wonder is if there would be a better way to specify the data than
register values. The ANX7625 datasheet isn't public, so there's
effectively no way for someone to write a device tree compliant with
this binding only with the information contained here. Reviewing the
bindings is equally difficult. It would be best if this property instead
contained information that could be documented clearly.
> > > + anx,mipi-dpi-in:
> > > + $ref: /schemas/types.yaml#/definitions/uint32
> > > + description: indicate the MIPI rx signal type is DPI or DSI
> >
> > This sounds similar to the bus-type property defined in
> > Documentation/devicetree/bindings/media/video-interfaces.txt (which is
> > getting converted to YAML, Rob has posted a patch series, I expect it to
> > land in v5.13). I think it would make sense to extend bus-type to
> > support DSI, and use that property.
>
> Sorry, I didn't found any define for DPI or DSI flag in Rob's patches.
> Do you mean I just remove this flag define and call a special function
> to read the port's type(DSI or DPI)?
video-interfaces.yaml has initially been written for cameras, so it
doesn't support DSI. I think it would make sense to extend the bus-type
property with a DSI type, and use it here instead of a vendor-specific
property.
Alternatively, I'm wondering if this isn't information we could query at
runtime. DRM bridges and panels have a type, so we could look at the
next bridge or panel to find the type of the connected device instead of
specifying it in DT.
> > > +
> > > ports:
> > > type: object
> > >
> > > @@ -72,6 +80,17 @@ examples:
> > > reg = <0x58>;
> > > enable-gpios = <&pio 45 GPIO_ACTIVE_HIGH>;
> > > reset-gpios = <&pio 73 GPIO_ACTIVE_HIGH>;
> > > + anx,swing-setting = <0x00 0x14>, <0x01 0x54>,
> > > + <0x02 0x64>, <0x03 0x74>, <0x04 0x29>,
> > > + <0x05 0x7b>, <0x06 0x77>, <0x07 0x5b>,
> > > + <0x08 0x7f>, <0x0c 0x20>, <0x0d 0x60>,
> > > + <0x10 0x60>, <0x12 0x40>, <0x13 0x60>,
> > > + <0x14 0x14>, <0x15 0x54>, <0x16 0x64>,
> > > + <0x17 0x74>, <0x18 0x29>, <0x19 0x7b>,
> > > + <0x1a 0x77>, <0x1b 0x5b>, <0x1c 0x7f>,
> > > + <0x20 0x20>, <0x21 0x60>, <0x24 0x60>,
> > > + <0x26 0x40>, <0x27 0x60>;
> > > + anx,mipi-dpi-in = <0>;
> > >
> > > ports {
> > > #address-cells = <1>;
--
Regards,
Laurent Pinchart
