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@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. > > 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.
Attachment:
signature.asc
Description: PGP signature
