Received: by 2002:a05:6a10:5bc5:0:0:0:0 with SMTP id os5csp3509501pxb; Wed, 13 Oct 2021 07:26:56 -0700 (PDT) X-Google-Smtp-Source: ABdhPJy4Q3J5RIk9pMtBjqhIZ66TDse1v2konwTNEb6gkJOkfmAGJJfYBCGrqGmGonPUrhwoKl8l X-Received: by 2002:a17:902:e884:b0:13f:19bf:fc16 with SMTP id w4-20020a170902e88400b0013f19bffc16mr28063196plg.67.1634135215989; Wed, 13 Oct 2021 07:26:55 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1634135215; cv=none; d=google.com; s=arc-20160816; b=Y/bhEBHRk6M2pJYepIl04JX1L/b9fPBMpH//7822MI2mRi2PDD68WKkPoDDl337ouR bd36dFBXGFumBbmldMVnvxRECgJbHC7THfwC/oz8uMGofo5FYOboxwJOo94JIOWyArSb FrZXySsTpMHPk+Cjta8HAA84Y8PuhLGpY438LU4B8QYt/d7ge/ziJA4WbIx0HnVub4Lm uXg1znkOJ1VXx/aGLHh/0nXyLB9OnWoyj+6oJGgIrl8lusO5QwiOx+KWmgtxJnfaX4wG MWWVtHnz799TGJtma1pvHxGNcgG2BG7l7Mv6pH5uAP4XuO3QN2I7IoSDgqdTN0kXHUn9 c48w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:message-id:user-agent:references:in-reply-to :subject:cc:to:from:date:content-transfer-encoding:mime-version :dkim-signature; bh=ew25jgYD/j/6YfYm/jAJS8kiMsBSWL7LMk0vNn14EGo=; b=Gn+Gpqi9Qveq1kq/LInpuUD+6Uk/ZEh1imUSi9u3//dZLPXoXa9Ott6/YeJ7E8JFgI 67YCin+bC8zU69XLmNZ9aCQk7YiU6aRqYgDJYqgivfr810LOxrlaEPZiV2EaJYuYQQDZ tc/Mor81wfGKOHAGchICj5nU8NmnQkzq9RBMhcjWInqNwV6P3TNFHNYwZUX8i+xs9n+a PeTvz7ic5EphTWXw0e42F4a+Q/ScalqS57xjzFbsrU4n0e+tCMxUcAyTNkgjJicIZ4zI S4Xf0CUYRZkt5qfjTl5wrshmxHb1GfQNyCd2DVayJfTve5IG9oPgYUIWOxZANSHUp9xx l+YQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@walle.cc header.s=mail2016061301 header.b=YYipjHGX; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id c17si18394072pls.182.2021.10.13.07.26.43; Wed, 13 Oct 2021 07:26:55 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@walle.cc header.s=mail2016061301 header.b=YYipjHGX; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230324AbhJMO0N (ORCPT + 99 others); Wed, 13 Oct 2021 10:26:13 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:48270 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S236976AbhJMOZ6 (ORCPT ); Wed, 13 Oct 2021 10:25:58 -0400 Received: from ssl.serverraum.org (ssl.serverraum.org [IPv6:2a01:4f8:151:8464::1:2]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 5197EC061570; Wed, 13 Oct 2021 07:23:53 -0700 (PDT) Received: from ssl.serverraum.org (web.serverraum.org [172.16.0.2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ssl.serverraum.org (Postfix) with ESMTPSA id B0BA522247; Wed, 13 Oct 2021 16:23:49 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=walle.cc; s=mail2016061301; t=1634135030; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=ew25jgYD/j/6YfYm/jAJS8kiMsBSWL7LMk0vNn14EGo=; b=YYipjHGXQSe4vSaJdTse5KQDnvajaZyHPfvjjpsy+/rBuJzBxYH8Z8WWQEPrAlJlDcKe5e 2IOcOAHuNnvvEekr8T0DUXeqGW5Uq4plQX2ZkrXTqsjPHcSVh2RKUjvQ+rOeSRH0yyyfnb 7qoez8zyM/pXTGsgtVj3XUrJP7NvjRo= MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Wed, 13 Oct 2021 16:23:49 +0200 From: Michael Walle To: Alexander Stein Cc: Miquel Raynal , Richard Weinberger , Vignesh Raghavendra , Rob Herring , Pratyush Yadav , Tudor Ambarus , 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 In-Reply-To: References: User-Agent: Roundcube Webmail/1.4.11 Message-ID: X-Sender: michael@walle.cc Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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 >> > --- >> > 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