From: "Shenhar, Talel" <talel@amazon.com>
To: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>, <bp@alien8.de>
Cc: <talelshenhar@gmail.com>, <shellykz@amazon.com>,
<linux-edac@vger.kernel.org>, <linux-kernel@vger.kernel.org>
Subject: Re: RFC on drivers/memory vs drivers/edac memory mapping for DDR Controller
Date: Tue, 3 Jan 2023 16:34:02 +0200 [thread overview]
Message-ID: <7cc4d012-1382-204c-5ba5-73bdf6dae2d5@amazon.com> (raw)
In-Reply-To: <add4e548-c7cd-741d-90e5-5c7c9ec7284f@linaro.org>
On 1/3/2023 4:24 PM, Krzysztof Kozlowski wrote:
> CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe.
>
>
>
> On 03/01/2023 14:47, Shenhar, Talel wrote:
>> So how would you have the DT described and how would driver/s look like
>> for cases that the unit registers are split interchangeably?
>>
>>> You did not Cc relevant here mailing addresses (DT and Rob), so this
>>> discussion might miss their feedback.
>>>
>>> How the drivers map IO address space is independent question and should
>>> not determine the hardware description. You want to say that hardware
>>> changes depending on OS? One OS means hardware is like that and on other
>>> OS it's different?
> BTW, you nicely skipped points of my email which are a bit
> inconvenient,e.g. how you want to tie DTS and bindings to one specific
> driver implementation and ignore the rest...
Sorry missed that.
Rob would probably be relevant for this topic as well, however, I didn't
want to focus on DT for this topic.
Seems your question is what I am actually asking...
However your answer keep getting back to do "full hardware description
in dt and that it doesn't relate to driver" but does not give concrete
response hence I fail to get the answer or direction I am looking for.
The solution I previously gave show different possibility for describing
the HW and the impact on the drivers and wonder what is the best path.
For now I think this is the path I shall take which is option 1:
"1) map more specific region to avoid conflict (we don't need the same
registers on both entity so if we do very specific multiple mapping this
shall be resolved)"
Which seems to be what you are trying to say by give more complete HW
description.
>
> Best regards,
> Krzysztof
>
next prev parent reply other threads:[~2023-01-03 14:34 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-01-02 12:17 RFC on drivers/memory vs drivers/edac memory mapping for DDR Controller Shenhar, Talel
2023-01-02 12:47 ` Krzysztof Kozlowski
2023-01-02 13:44 ` Shenhar, Talel
2023-01-02 13:59 ` Krzysztof Kozlowski
2023-01-02 16:21 ` Shenhar, Talel
2023-01-02 16:25 ` Krzysztof Kozlowski
2023-01-03 13:12 ` Shenhar, Talel
2023-01-03 13:23 ` Krzysztof Kozlowski
2023-01-03 13:47 ` Shenhar, Talel
2023-01-03 14:02 ` Krzysztof Kozlowski
2023-01-03 14:24 ` Krzysztof Kozlowski
2023-01-03 14:34 ` Shenhar, Talel [this message]
2023-01-02 13:43 ` Borislav Petkov
2023-01-02 16:14 ` Shenhar, Talel
2023-01-02 16:23 ` Borislav Petkov
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=7cc4d012-1382-204c-5ba5-73bdf6dae2d5@amazon.com \
--to=talel@amazon.com \
--cc=bp@alien8.de \
--cc=krzysztof.kozlowski@linaro.org \
--cc=linux-edac@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=shellykz@amazon.com \
--cc=talelshenhar@gmail.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