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:12, Shenhar, Talel wrote:
On 1/2/2023 6:25 PM, Krzysztof Kozlowski wrote:No, that's not true and such DT description will get probably Rob's or
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.The way the HW shall be described in DT is tightly coupled to the way
On 02/01/2023 17:21, Shenhar, Talel wrote:
On 1/2/2023 3:59 PM, Krzysztof Kozlowski wrote:The correct solution is to describe hardware. The hardware is memory
On 02/01/2023 14:44, Shenhar, Talel wrote:You are right.
On 1/2/2023 2:47 PM, Krzysztof Kozlowski wrote:I explained - using same IO address suggests you used Linux driver
On 02/01/2023 13:17, Shenhar, Talel wrote:Can you elaborate on this inaccurate hardware description?
Things we had in mind:None of these address the core problem - possibly inaccurate hardware
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
description...
structure in your hardware description. I assume we talk here about
Devicetree. If not, that's quite different case... then I guess ACPI,
which I do not care - I am not it's maintainer.
Also, I'd like to write down my understanding of your response from above:No. Sorry, we probably talk about two different things.
it seems you see as possible solution both using different API that
allow overlapping (solution 2) and also for splitting the IO address
space to finer pieces to achieve full HW description (solution 1)
You started writing that you have a hardware described as one IO address
space and now have a problem developing drivers for it.
The driver model for this is entirely different problem than problem of
accurate hardware description. Whether you described HW correct or not,
I don't know. You did not provide any details here, like DTS or bindings
(if we talk about Devicetree).
Having multiple drivers using similar resources is already solved many
times (MFD, syscon).
Whether the solution is correct or not is one more (third) topic: poking
to same IO address space from two different drivers is error-prone. This
one is solvable with splitting IO address space.
Best regards,
Krzysztof
Let me elaborate on this.
We will write down the hardware description via device tree.
Then we will write the driver which will honor that binding.
So the question is what is the best practice there assuming there is no
shared registers however there is overlapping.
controller. There is no hardware called "scaller of memory controller".
There is no hardware called "EDAC" because that's purely a Linux term.
Your DTS should accurately describe the hardware, not drivers. Then
drivers can do whatever they want with it - have safe, non-concurrent
access or keep poking same registers and break things...
the drivers will work on mapping the IO addresses.
mine comments. The HW shall be described without tying to one, specific
driver implementation. Otherwise why do you make it tightly coupled to
Linux, but ignore BSD, firmware and bootloaders?
Don't tightly couple DT with your drivers.
There are 3 ways to describe the HW as far as I see it from addressAgain, the driver does not matter. You have one device, describe
point of view: (actually 2 as option 3 is not really sane)
1) one big chunk of registers
2) smaller chunk of registers aiming to have each chunk describe a
subset of the HW capablity (e.g. RAS, e.g. Refresh-rate, ...)
3) describe each register with its name
Each option dictate how driver shall map the address space.
properly one device. DT is not to describe drivers.
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?
Drivers are not related to DT bindings and DTS. Two different things.
If option 1 is chosen, then we shall have 2 drivers with same reg
description.
For that case, they can both remap the whole space or each one can try
to map only the section it needs.
If option 2 is chosen, then each driver can use DT to know exactly what
it needs to map and do it in safer manner.
Best regards,
Krzysztof