On Mon, Oct 05, 2020 at 12:38:20PM +0300, Dmitry Osipenko wrote: > 05.10.2020 12:16, Thierry Reding пишет: > ... > >> I think you meant regmap in regards to protecting IO accesses, but this > >> is not what regmap is about if IO accesses are atomic by nature. > > > > Then why is there regmap-mmio? > > To protect programming sequences for example, actually that's the only > real use-case I saw in kernel drivers once. In our case there are no > sequences that require protection, at least I'm not aware about that. True. But I'd still prefer to have a more formal mechanism of handing out access to registers. Either way, this isn't very relevant in the case of tegra20-devfreq because there's really no reason for it to be a separate driver with device tree lookup since it's all internal to the MC driver. The only reason (unless I'm missing something) for that is to have the code located in drivers/devfreq. We can do that without requiring DT lookup either like we did for tegra-smmu/tegra-mc, or by directly copying the code into drivers/memory. It's become fairly common in recent years to group code by IP rather than functionality. We nowadays have good tools to help with subsystem wide refactoring that make it much less necessary for subsystem code to be concentrated in a single directory. > >> Secondly, you're missing that tegra30-devfreq driver will also need to > >> perform the MC lookup [3] and then driver will no longer work for the > >> older DTs if phandle becomes mandatory because these DTs do not have the > >> MC phandle in the ACTMON node. > >> > >> [3] > >> https://github.com/grate-driver/linux/commit/441d19281f9b3428a4db1ecb3a02e1ec02a8ad7f > >> > >> So we will need the fall back for T30/124 as well. > > > > No, we don't need the fallback because this is new functionality which > > can and should be gated on the existence of the new phandle. If there's > > no phandle then we have no choice but to use the old code to ensure old > > behaviour. > > You just repeated what I was trying to say:) > > Perhaps I spent a bit too much time touching that code to the point that > lost feeling that there is a need to clarify everything in details. I assumed that by "fall back" you meant the lookup-by-compatible. But what I was talking about is the fall back to the current code which does not use the MC device tree node at all. The latter is going to be required to ensure that the code continues to work as-is. But the former is not required because we have fall back code that already works with old device trees. New code that is using the memory controller's timings nodes can be gated on the existence of the phandle in DT and doing so is not going to break backwards-compatibility. But perhaps I was misunderstanding what you were trying to say. Thierry
Attachment:
signature.asc
Description: PGP signature
