The Linux Kernel Mailing List
 help / color / mirror / Atom feed
From: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
To: "Shenhar, Talel" <talel@amazon.com>, 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: Mon, 2 Jan 2023 13:47:20 +0100	[thread overview]
Message-ID: <8b844f3a-e9b0-28d5-200a-611fe3068bc0@linaro.org> (raw)
In-Reply-To: <2511c7aa-8ce6-a803-a1ea-6121df79c677@amazon.com>

On 02/01/2023 13:17, Shenhar, Talel wrote:
> Hi,
> 
> Want to consult on a topic that involve both drivers/memory and 
> drivers/edac.
> 
> * We want to introduce driver that reads DDR controller RAS register and 
> notify for ECC errors by using EDAC MC API found in drivers/edac.
> * We also want to have a capability to dynamically change DDR refresh 
> rate based on thermal values (best to be done in drivers/memory ?).
> 
> The pain point here is that both capabilities are controlled from the 
> DDR controller.
> This create issue while using 
> devm_platform_ioremap_resource*->devm_request_mem_region which prevent 
> two mapping of same area.

This could be avoided but the true problem is that you have two devices
for same memory mapping. Devicetree does not allow it and it points to
some wrong hardware representation in DTS.

> 
> It seems to be expected problem as we have 2 "framework" (edac and 
> memory) split while both aim for same HW unit.
> What is the recommended way to face such conflicts?

You now mix Devicetree and Linux drivers. You can have same IO address
space used by multiple drivers, even though it is not always good
approach (concurrent and conflicting change of same settings).

HW description is irrelevant to this.

> 
> We had several concept in mind but would love to get your point of view 
> first.

Describe hardware accurately and completely. This solves all the
problems, doesn't it? Linux drivers do not depend on it and you can make
it differently.

> 
> Things we had in mind:
> 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)
> 2) use other kernel API for mapping that doesn't do request_mem_region 
> (or use the reserve only for one of them)
> 3) have single driver (edac mc) handle also the refresh rate
> 4) export edac_mc.h and have the drivers/memory have all the needed code 
> to do both edac and refresh rate under drivers/memory

None of these address the core problem - possibly inaccurate hardware
description...

Best regards,
Krzysztof


  reply	other threads:[~2023-01-02 12:47 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 [this message]
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
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=8b844f3a-e9b0-28d5-200a-611fe3068bc0@linaro.org \
    --to=krzysztof.kozlowski@linaro.org \
    --cc=bp@alien8.de \
    --cc=linux-edac@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=shellykz@amazon.com \
    --cc=talel@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