All of lore.kernel.org
 help / color / mirror / Atom feed
From: Michal Simek <michal.simek@amd.com>
To: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>,
	Conor Dooley <conor@kernel.org>,
	Piyush Mehta <piyush.mehta@amd.com>
Cc: robh+dt@kernel.org, krzysztof.kozlowski+dt@linaro.org,
	conor+dt@kernel.org, p.zabel@pengutronix.de,
	devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
	git@amd.com
Subject: Re: [PATCH 1/2] dt-bindings: reset: Updated binding for Versal-NET reset driver
Date: Tue, 18 Jul 2023 16:01:56 +0200	[thread overview]
Message-ID: <5df3e976-9fc2-19af-e6b4-e2bea0d64623@amd.com> (raw)
In-Reply-To: <22e7dc73-2411-5cb1-6cef-daa5f2af8297@linaro.org>



On 7/18/23 15:20, Krzysztof Kozlowski wrote:
> On 18/07/2023 15:11, Michal Simek wrote:
>>>>
>>>> That numbers in DT are virtual no matter if you use ID from 0 to max or random
>>>> values it is up to code to handle them. Checking nr_pins against ID is done in
>>>> core but it is up to drivers.
>>>
>>> No, you confuse "virtual" and "ID". IDs are not virtual. IDs are real
>>> and have representation in Linux driver. You do not need to define
>>> anything virtual in the bindings.
>>
>> Not sure how you define ID itself. But HW doesn't know ID. HW knows only
>> register which you can use to perform the reset. It is not really 128bit
>> register where every bit targets to different IP.
>>
>> And this is SW-firmware interface like SCMI reset driver.
>>
>> Firmware is saying that ID 0 is QSPI, ID 1 is MMC.
>> Their Linux driver is asking for nr_reset via firmware call which can be
>> different for different SOC and that's fine and I have no problem with it.
>> But only SCMI server is dictating that ID 0 is QSPI and ID 1 is MMC. Different
>> SCMI server implementation can map it differently.
> 
> Sure, and all this points to: no need for bindings.
> 
>>
>>
>>>> In our case that IDs are coming from firmware and driver itself is just matching
>>>> them.
>>>
>>> So they are the same as if coming from hardware - no need for IDs.
>>
>> It is hard to say what hardware here exactly is. From my perspective and I am
>> not advocating not using IDs from 0 to max, it is just a number.
>>
>> If my firmware knows that QSPI reset is 0xc10402dU then I will just pass it to
>> reach my goal which is reset QSPI IP.
>>
>> If you think that we should use IDs from 0 to max NR I am happy to pass this
>> message to PM team and we should extend any SW to do translation between.
> 
> When we talk about IDs and bindings, we mean IDs meaningful to Linux.
> Whatever is ignored by Linux and passed to anyone else - hardware or
> firmware - is not a ID anymore from bindings point of view. It's just
> some value.

Please correct me if I am wrong. Description about ID should be removed from 
commit message because it is not necessary. And
include/dt-bindings/reset/xlnx-versal-net-resets.h
should be added when we merge also DT for versal-net SOC.

Thanks,
Michal

  parent reply	other threads:[~2023-07-18 14:04 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-07-17 11:23 [PATCH 0/2] reset: reset-zynqmp: add support for Versal NET platform Piyush Mehta
2023-07-17 11:23 ` [PATCH 1/2] dt-bindings: reset: Updated binding for Versal-NET reset driver Piyush Mehta
2023-07-17 18:40   ` Conor Dooley
2023-07-17 20:47     ` Krzysztof Kozlowski
2023-07-18  7:10       ` Michal Simek
2023-07-18  7:39         ` Krzysztof Kozlowski
2023-07-18 13:11           ` Michal Simek
2023-07-18 13:20             ` Krzysztof Kozlowski
2023-07-18 13:21               ` Krzysztof Kozlowski
2023-07-18 13:59                 ` Michal Simek
2023-07-18 14:01               ` Michal Simek [this message]
2023-07-18 14:04                 ` Krzysztof Kozlowski
2023-07-18 14:30                   ` Michal Simek
2023-07-18 18:01                     ` Krzysztof Kozlowski
2023-07-19  6:23                       ` Michal Simek
2023-07-19  6:36                         ` Krzysztof Kozlowski
2023-07-17 11:23 ` [PATCH 2/2] reset: reset-zynqmp: add support for Versal NET platform Piyush Mehta

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=5df3e976-9fc2-19af-e6b4-e2bea0d64623@amd.com \
    --to=michal.simek@amd.com \
    --cc=conor+dt@kernel.org \
    --cc=conor@kernel.org \
    --cc=devicetree@vger.kernel.org \
    --cc=git@amd.com \
    --cc=krzysztof.kozlowski+dt@linaro.org \
    --cc=krzysztof.kozlowski@linaro.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=p.zabel@pengutronix.de \
    --cc=piyush.mehta@amd.com \
    --cc=robh+dt@kernel.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.