From: Michael Walle <michael@walle.cc>
To: Alexander Stein <Alexander.Stein@ew.tq-group.com>
Cc: Miquel Raynal <miquel.raynal@bootlin.com>,
Richard Weinberger <richard@nod.at>,
Vignesh Raghavendra <vigneshr@ti.com>,
Rob Herring <robh@kernel.org>, Pratyush Yadav <p.yadav@ti.com>,
Tudor Ambarus <tudor.ambarus@microchip.com>,
linux-mtd@lists.infradead.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: AW: (EXT) Re: [PATCH v2 1/2] dt-bindings: mtd: spi-nor: Add output-driver-strength property
Date: Wed, 13 Oct 2021 16:23:49 +0200 [thread overview]
Message-ID: <da3f810389e3bd42392424a0ddc80cac@walle.cc> (raw)
In-Reply-To: <kcEE.9geNR42QRKGTSoedF1sEfQ.ALRP5Q7A1wE@vtuxmail01.tq-net.de>
Hi,
Am 2021-10-13 10:47, schrieb Alexander Stein:
> Am 2021-10-12 09:48, schrieb Michael Walle:
>> Am 2021-10-12 08:17, schrieb Alexander Stein:
>> > This property is for optimizing output voltage impedance and is
>> > specific to each board. It overwrites the default set by the flash
>> > device. Various flash devices support different impedances.
>> >
>> > Signed-off-by: Alexander Stein <alexander.stein@ew.tq-group.com>
>> > ---
>> > Changes in v2:
>> > * Updated the property description and the commit message accordingly
>> >
>> > Documentation/devicetree/bindings/mtd/jedec,spi-nor.yaml | 8 ++++++++
>> > 1 file changed, 8 insertions(+)
>> >
>> > diff --git a/Documentation/devicetree/bindings/mtd/jedec,spi-nor.yaml
>> > b/Documentation/devicetree/bindings/mtd/jedec,spi-nor.yaml
>> > index ed590d7c6e37..4c3c506a8853 100644
>> > --- a/Documentation/devicetree/bindings/mtd/jedec,spi-nor.yaml
>> > +++ b/Documentation/devicetree/bindings/mtd/jedec,spi-nor.yaml
>> > @@ -72,6 +72,14 @@ properties:
>> > be used on such systems, to denote the absence of a reliable
>> > reset
>> > mechanism.
>> >
>> > + output-driver-strength:
>> > + $ref: /schemas/types.yaml#/definitions/uint32
>> > + description:
>> > + Output driver strength in ohms which optimizes the impedance at
>> > Vcc/2
>> > + output voltage. This property overwrites the default set by the
>> > flash
>> > + device. This is board specific and should be determined by the
>> > + manufacturer. Various flash devices support different
>> > impedances.
>>
>> Mh, this seems to be very tailored to this flash chip. Eg. the
>> "Vcc/2",
>> is
>> this something specific to this flash or is this some kind of common
>> usage?
>
> "Vcc/2" is taken from the datasheet description.
But this property should be as generic as possible. So at least I'd
drop the "optimizes the imdance at Vcc/2". And as Rob mentioned,
"strength" implies (milli)amps. Shouldn't it be output-driver-impedance
in this case?
>> For example, Winbond flashes specifies the output driver strength in
>> percent.
>> Settings are 25%, 50%, 75%, 100% there.
>>
>> I'd have to ask a hardware guy, if one could convert between these two
>> representations of the driver strength.
>
> Well, 100% must map to some actual value. Which then can be used to
> create
> a discrete value table, which are then supported by the flash driver.
Which unfortunatly isn't possible because there is no refence for this
obscure value. That is, the datasheet doesn't mention what 100% actually
is.
> E.g. for Micron not every flash supports the same set of settings for
> driver strength.
> Macronix uses similar settings (values and bitmask), but in a different
> register. But if some vendors have pretty much incompatible settings,
> it
> might be feasible to provide vendor specific settings, e.g.
> "micron,drive-strength = <45>" (for 45 Ohm) or "winbond,drive-strength
> = <100>"
> (for 100%).
Different registers/values aren't the problem here. The problem is that
different units are used to express the same thing. But lets wait for
Rob's answer to my previous question.
To summarize there are flashes where you can select different impedances
for the output driver and flashes where you can select different
percentages
for the output driver strength and there might also be flashes where you
can specify the output driver strength in (milli)amps. And it might not
always be possible to convert between these values. Therefore, will
these
be three different DT properties?
-michael
prev parent reply other threads:[~2021-10-13 14:24 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-10-13 8:47 Alexander Stein
2021-10-13 14:23 ` Michael Walle [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=da3f810389e3bd42392424a0ddc80cac@walle.cc \
--to=michael@walle.cc \
--cc=Alexander.Stein@ew.tq-group.com \
--cc=devicetree@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mtd@lists.infradead.org \
--cc=miquel.raynal@bootlin.com \
--cc=p.yadav@ti.com \
--cc=richard@nod.at \
--cc=robh@kernel.org \
--cc=tudor.ambarus@microchip.com \
--cc=vigneshr@ti.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®