From: Roger Quadros <rogerq@kernel.org>
To: "Niedermayr, BENEDIKT" <benedikt.niedermayr@siemens.com>,
"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
"krzysztof.kozlowski@linaro.org" <krzysztof.kozlowski@linaro.org>,
"linux-omap@vger.kernel.org" <linux-omap@vger.kernel.org>
Cc: "tony@atomide.com" <tony@atomide.com>,
"robh+dt@kernel.org" <robh+dt@kernel.org>
Subject: Re: [PATCH v5 2/3] memory: omap-gpmc: add support for wait pin polarity
Date: Tue, 20 Sep 2022 18:27:37 +0300 [thread overview]
Message-ID: <bf2d96c3-366c-9ad2-5632-ee7ab5d99b39@kernel.org> (raw)
In-Reply-To: <d7b86ccf4c66e590c247ad24f84944ccdc3b1902.camel@siemens.com>
Hi,
On 20/09/2022 15:17, Niedermayr, BENEDIKT wrote:
> Hi Krzysztof,
>
> On Tue, 2022-09-20 at 13:23 +0200, Krzysztof Kozlowski wrote:
>> On 20/09/2022 12:12, Niedermayr, BENEDIKT wrote:
>>>> I commented exactly below the line which I question. I don't question
>>>> other lines. So let me be a bit more specific:
>>>>
>>>> Why do you need
>>>> "p->wait_pin_polarity != WAITPINPOLARITY_DEFAULT"
>>>> ? Can you write a scenario where this is useful?
>>>>
>>> Ok. I think I got you now. Sorry I'm relatively new to OSS contributions, so please be patient with me...
>>>
>>> If I remove that part of the if clause, then an error message would be printed in case "p->wait_pin_polarity == WAITPINPOLARITY_DEFAULT".
>>
>> Exactly this will happen. As expected. This value cannot appear in DTS,
>> therefore I would expect error message.
>>
>> Now you allow such value in DTS which is not the same as your bindings.
>>
> And now I completely got it...
> With this implementation it's even possible to set WAITPINPOLARITY_DEFAULT in the DT...
>
> Ok, changing this will lead to an error message if the "gpmc,wait-pin-polarity" is not set in DT. Means the DT property is more orless not an optional
> property anymore.
> If one defines the wait-pin without defining the polarity the driver probes successfully but and error message is printed.
> Is this an acceptable solution for you?
>
No this is not acceptable. As current implementations don't define polarity and rely on reset defaults.
You can check return value of "of_property_read_u32(np, "gpmc,wait-pin-polarity", &p->wait_pin_polarity))"
" * Return: 0 on success, -EINVAL if the property does not exist,
* -ENODATA if property does not have a value, and -EOVERFLOW if the
* property data isn't large enough."
If property is present you don't need to check for WAITPINPOLARITY_DEFAULT as that is not valid value for this property.
If property is not present you force WAITPINPOLARITY_DEFAULT and don't print error message.
>
>>
>>> But this is a not an error case. WAITPINPOLARITY_DEFAULT is a valid value, is assigned right before the if clause as an init value(not extracted from
>>> DT),
>>> and leads to not touching the GPMC_CONFIG register in gpmc_cs_program_settings().
>>> So in gpmc_cs_program_settings() if:
>>> p->wait_pin_polarity != WAITPINPOLARITY_ACTIVE_HIGH -> Issue a write to the GPMC_CONFIG register
>>> p->wait_pin_polarity != WAITPINPOLARITY_ACTIVE_LOW -> Issua a write to the GPMC_CONFIG register
>>> p->wait_pin_polarity != WAITPINPOLARITY_DEFAULT -> Do not touch the GPMC_CONFIG register
>>>
>>> We want to preserve the reset value of the GPMC_CONFIG register in case the DT does not use the "gpmc,wait-pin-polarity" property. Otherwise
>>> we might break platforms which rely on these reset values.
>>
>> Best regards,
>> Krzysztof
> Cheers,
> benedikt
>
cheers,
-roger
next prev parent reply other threads:[~2022-09-20 15:27 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-09-16 12:07 [PATCH v5 0/3] gpmc wait-pin additions B. Niedermayr
2022-09-16 12:07 ` [PATCH v5 1/3] memory: omap-gpmc: allow shared wait pins B. Niedermayr
2022-09-19 9:34 ` Krzysztof Kozlowski
2022-09-19 12:37 ` Niedermayr, BENEDIKT
2022-09-20 7:33 ` Krzysztof Kozlowski
2022-09-16 12:07 ` [PATCH v5 2/3] memory: omap-gpmc: add support for wait pin polarity B. Niedermayr
2022-09-19 9:38 ` Krzysztof Kozlowski
2022-09-19 13:25 ` Niedermayr, BENEDIKT
2022-09-20 7:33 ` Roger Quadros
2022-09-20 7:39 ` Krzysztof Kozlowski
2022-09-20 9:13 ` Niedermayr, BENEDIKT
2022-09-20 9:47 ` Krzysztof Kozlowski
2022-09-20 10:12 ` Niedermayr, BENEDIKT
2022-09-20 11:23 ` Krzysztof Kozlowski
2022-09-20 12:17 ` Niedermayr, BENEDIKT
2022-09-20 15:27 ` Roger Quadros [this message]
2022-09-16 12:07 ` [PATCH v5 3/3] dt-bindings: memory-controllers: gpmc-child: add wait-pin polarity B. Niedermayr
2022-09-20 11:21 ` Krzysztof Kozlowski
2022-09-20 12:01 ` Niedermayr, BENEDIKT
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=bf2d96c3-366c-9ad2-5632-ee7ab5d99b39@kernel.org \
--to=rogerq@kernel.org \
--cc=benedikt.niedermayr@siemens.com \
--cc=devicetree@vger.kernel.org \
--cc=krzysztof.kozlowski@linaro.org \
--cc=linux-omap@vger.kernel.org \
--cc=robh+dt@kernel.org \
--cc=tony@atomide.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;
as well as URLs for NNTP newsgroup(s).