Re: [PATCH v1 2/8] MT9M114: Add pad-slew-rate DT-binding

[Mathis Foerst]

On Tue, Mar 04, 2025 at 04:39:34PM +0000, Conor Dooley wrote:
> On Tue, Mar 04, 2025 at 12:48:58PM +0100, Mathis Foerst wrote:
> > Hi Conor, Hi Sakari,
> > 
> > On Fri, Feb 28, 2025 at 07:11:31PM +0000, Conor Dooley wrote:
> > > On Thu, Feb 27, 2025 at 10:14:02AM +0000, Sakari Ailus wrote:
> > > > Hi Mathis,
> > > > 
> > > > On Wed, Feb 26, 2025 at 04:39:23PM +0100, Mathis Foerst wrote:
> > > > > The MT9M114 supports the different slew rates (0 to 7) on the output pads.
> > > > 
> > > > "the output pads" probably means pixel data interface (DVP or CSI-2)
> > > > signals in this cases? I suppose this is about clock modulation?
> > > > It'd be good to say that.
> > 
> > The slew rate defines the slope of the voltage flanks on the output pads (how fast
> > the pads go from LOW to HIGH or vice versa). I tried to clarify the description.
> > 
> > > > 
> > > > > At the moment, this is hardcoded to 7 (the fastest rate).
> > > > > The user might want to change this values due to EMC requirements.
> > > > > 
> > > > > Add the 'pad-slew-rate' property to the MT9M114 DT-bindings for selecting
> > > > > the desired slew rate.
> > > > > 
> > > > > Signed-off-by: Mathis Foerst <mathis.foerst@xxxxxx>
> > > > > ---
> > > > >  .../devicetree/bindings/media/i2c/onnn,mt9m114.yaml         | 6 ++++++
> > > > >  1 file changed, 6 insertions(+)
> > > > > 
> > > > > diff --git a/Documentation/devicetree/bindings/media/i2c/onnn,mt9m114.yaml b/Documentation/devicetree/bindings/media/i2c/onnn,mt9m114.yaml
> > > > > index 72e258d57186..666afe10c538 100644
> > > > > --- a/Documentation/devicetree/bindings/media/i2c/onnn,mt9m114.yaml
> > > > > +++ b/Documentation/devicetree/bindings/media/i2c/onnn,mt9m114.yaml
> > > > > @@ -74,6 +74,12 @@ properties:
> > > > >      description: Bypass the internal PLL of the sensor to use EXTCLK directly as SYSCLK.
> > > > >      type: boolean
> > > > >  
> > > > > +  onnn,slew-rate:
> > > > > +    $ref: /schemas/types.yaml#/definitions/uint8
> > > > 
> > > > No need to make this 8-bit (i.e. just use 32 bits).
> > 
> > Okay, I thought 8-bit would fit the small value range [0,7]. Changed it to 32 bits.
> > 
> > > > 
> > > > > +    description: Slew rate ot the output pads DOUT[7:0], LINE_VALID, FRAME_VALID and PIXCLK
> > > > 
> > > > Please wrap at 80 characters.
> > > > 
> > > > Is there more information on the effect than 7 is the fastest?
> > 
> > There is no more information about the exact meaning of the values.
> > As described above, the higher the value, the steeper the voltage flanks.
> > 
> > > > 
> > > > > +    minimum: 0
> > > > > +    maximum: 7
> > > > 
> > > > Please also add a default.
> > 
> > Sure, I added the default value 7 that matches the currently hardcoded 
> > value in the driver.
> > 
> > > 
> > > It'd also be great (IMO) if it were given in terms of actual units, not
> > > nebulous values that I assume to be the register values.
> > 
> > I agree, but the documentation does not provide further details about the
> > unit of the value. So using the register value is my best-effort approach.
> 
> If they don't provide em, how is anyone meant to calculate what's
> correct? Trial and error?

The correct slew-rate is a trade-off:

You would usually start with the fastest slew-rate as it leads to an
output signal that's as close as possible to a perfect square-wave.
On higher link frequencies a too slow slew rate can cause the signal to
not reach the HIGH voltage level before going to LOW again s.t. the
reveiver cannot interpret the digital signal correctly.

But steeper voltage flanks lead to higher electromagnetic emissions s.t.
a device might not pass the electromagnetic compatibility (EMC)
certification with the high slew rate.
In this case you would lower the slew rate until your emissions are
within the allowed range.

The actual emissions depend on many factors like the PCB layout, the
length and shielding of cables etc. This makes it hard to fully simulate
them.
So even if would know the exact unit of the configured slew rate of the
camera sensor, it would not fully allow us to calculate the correct value
for it.