diff mbox series

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

Message ID 20250226153929.274562-3-mathis.foerst@mt.com (mailing list archive)
State New
Headers show
Series MT9M114 driver bugfix and improvements | expand

Commit Message

Mathis Foerst Feb. 26, 2025, 3:39 p.m. UTC
The MT9M114 supports the different slew rates (0 to 7) on the output pads.
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@mt.com>
---
 .../devicetree/bindings/media/i2c/onnn,mt9m114.yaml         | 6 ++++++
 1 file changed, 6 insertions(+)

Comments

Sakari Ailus Feb. 27, 2025, 10:14 a.m. UTC | #1
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.

> 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@mt.com>
> ---
>  .../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).

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

> +    minimum: 0
> +    maximum: 7

Please also add a default.

> +
>  required:
>    - compatible
>    - reg
Conor Dooley Feb. 28, 2025, 7:11 p.m. UTC | #2
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.
> 
> > 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@mt.com>
> > ---
> >  .../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).
> 
> > +    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?
> 
> > +    minimum: 0
> > +    maximum: 7
> 
> Please also add a default.

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.

> 
> > +
> >  required:
> >    - compatible
> >    - reg
> 
> -- 
> Regards,
> 
> Sakari Ailus
Mathis Foerst March 4, 2025, 11:48 a.m. UTC | #3
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@mt.com>
> > > ---
> > >  .../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.

> 
> > 
> > > +
> > >  required:
> > >    - compatible
> > >    - reg
> > 
> > -- 
> > Regards,
> > 
> > Sakari Ailus

Best regards,
Mathis Foerst
Conor Dooley March 4, 2025, 4:39 p.m. UTC | #4
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@mt.com>
> > > > ---
> > > >  .../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?
Mathis Foerst March 5, 2025, 9:59 a.m. UTC | #5
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@mt.com>
> > > > > ---
> > > > >  .../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.
Conor Dooley March 5, 2025, 4:29 p.m. UTC | #6
On Wed, Mar 05, 2025 at 10:59:27AM +0100, Mathis Foerst wrote:
> 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@mt.com>
> > > > > > ---
> > > > > >  .../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.

So the answer is trial and error then?
Conor Dooley March 5, 2025, 4:30 p.m. UTC | #7
On Wed, Mar 05, 2025 at 04:29:24PM +0000, Conor Dooley wrote:
> On Wed, Mar 05, 2025 at 10:59:27AM +0100, Mathis Foerst wrote:
> > 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@mt.com>
> > > > > > > ---
> > > > > > >  .../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.
> 
> So the answer is trial and error then?

And I guess, keep the register values if there's no actual unit
corresponding to these values.
diff mbox series

Patch

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
+    description: Slew rate ot the output pads DOUT[7:0], LINE_VALID, FRAME_VALID and PIXCLK
+    minimum: 0
+    maximum: 7
+
 required:
   - compatible
   - reg