Re: [PATCH v1 1/2] dt-bindings: drm/bridge: anx7625: add DPI flag and swing setting

[Xin Ji]

On Tue, Dec 29, 2020 at 04:34:20PM +0200, Laurent Pinchart wrote:
> 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.
Hi Laurent Pinchart, the swing register setting is optional. Basically, no need
to care about it if customer PCB layout match our chip requirement. The
property define just in case. So far, we just found one customer encountered
DP tx swing issue. As the datasheet swing register adjusting algorithm
has a little complex, we will help customer to adjust the DP tx swing
case by case.
> 
> > > > +  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.

At anx7625 driver probe stage, for the DSI, driver needs call some special
interface to attach to DSI interface. For the DPI port, there is no such
limitation, so we need to know what kind of MIPI signal type at driver initial
stage.
Maybe we can keep this flag, if the future has defined DSI, I'll submit new
patch to remove this flag.

Thanks,
Xin

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