Re: [PATCH 2/5] dt-bindings: mfd: syscon: Add ti,am62-ddr-pmctrl

[Andrew Davis <afd@ti.com>]

On 4/22/25 11:12 AM, David Lechner wrote:
> On 4/21/25 12:03 PM, Andrew Davis wrote:
> 
> ...
> 
>> Which parent device? That is my point, if the top level node for the
>> whole CTRL_MMR region is made into one big syscon, then a big regmap
>> is made that covers the whole region. All the child devices also make
>> regmaps covering their device range. Now these registers under the child
>> device belong to two different regmaps. No synchronization is done as
>> these are not the same regmap, regmap only handles this for multiple
>> access to registers within the same regmap.
>>
> 
> Why does the child device have to create a new/separate regmap? Can it not use
> something like syscon_regmap_lookup_by_phandle_args() to get the regmap from
> the "syscon" node along with 1 or more args specifying the one or few registers
> out of the full range that are assigned to that specific child node? This way,
> all child nodes would be using the same shared regmap.
> 
> (And yes, I know technically they don't need to be child nodes - just using that
> terminology to be consistent with the previous discussion.)

Yes, this can be done, and is done for a couple drivers today. The issue is most
drivers do not expect to be a child node of a syscon nor fetch a regmap with
syscon_regmap_lookup_*() functions. The vast majority drivers do the normal thing,
which is platform_get_resource() and similar, that gets the memory from the standard
"reg" property inside their own node.

We have then two options, retrofit all the existing drivers we might use with
support for fetching syscon regmaps (some drivers do not use regmap in the
first place, so we would also have to add regmap support first). Or we do what
we are doing here, which is to have these devices not use overlapping register
regions (which has the minor side effect of sometimes causing some nodes to
cover only small range of registers, which seems to be a problem?).

We went for the latter option, and it has been working fine for all our
new devices. And we are fixing the same for some of our older devices, we
are actually almost done with that too (if we could get this patch and maybe
two others in we would be completely converted).

Andrew