| Message ID | 20200403185640.118569-1-thierry.reding@gmail.com |
|---|---|
| Headers | show |
| Series | of: reserved-memory: Various improvements | expand |
On Fri, Apr 3, 2020 at 12:56 PM Thierry Reding <thierry.reding@gmail.com> wrote: > > From: Thierry Reding <treding@nvidia.com> > > Hi Rob, all, > > this is a set of patches that I've been working on to allow me to use > reserved memory regions more flexibly. One of the use-cases that I have > is an external memory controller driver that gets passed one or two > tables from firmware containing a set of EMC frequencies and the > corresponding register values to program for these frequencies. > > One of these tables is the "nominal" table and an optional second table > is "derated" and is used when the DRAM chips are overheating. I want to > be able to pass these tables as separate memory-region entries. > > So what this small patchset does is make the reserved-memory code adapt > to this situation better. On one hand, while the DT bindings currently > support multiple regions per device tree node, it's slightly unintuitive > to specify them. The first patch adds a memory-region-names property > that allows the DT to specify a "consumer" name for these regions much > like we do for things like clocks, resets or the reg property. At the > same time, a new alias for memory-region, named memory-regions, is > introduced to make this more consistent with other bindings. It's just not worth supporting both flavors (forever). I don't want to repeat gpio vs. gpios. Let's just stick with 'memory-region' and allow that to be more than one entry. I'm not a fan of *-names, but fine. Rob
On Sat, Apr 04, 2020 at 07:24:25PM -0600, Rob Herring wrote: > On Fri, Apr 3, 2020 at 12:56 PM Thierry Reding <thierry.reding@gmail.com> wrote: > > > > From: Thierry Reding <treding@nvidia.com> > > > > Hi Rob, all, > > > > this is a set of patches that I've been working on to allow me to use > > reserved memory regions more flexibly. One of the use-cases that I have > > is an external memory controller driver that gets passed one or two > > tables from firmware containing a set of EMC frequencies and the > > corresponding register values to program for these frequencies. > > > > One of these tables is the "nominal" table and an optional second table > > is "derated" and is used when the DRAM chips are overheating. I want to > > be able to pass these tables as separate memory-region entries. > > > > So what this small patchset does is make the reserved-memory code adapt > > to this situation better. On one hand, while the DT bindings currently > > support multiple regions per device tree node, it's slightly unintuitive > > to specify them. The first patch adds a memory-region-names property > > that allows the DT to specify a "consumer" name for these regions much > > like we do for things like clocks, resets or the reg property. At the > > same time, a new alias for memory-region, named memory-regions, is > > introduced to make this more consistent with other bindings. > > It's just not worth supporting both flavors (forever). I don't want to > repeat gpio vs. gpios. Let's just stick with 'memory-region' and allow > that to be more than one entry. Alright, I'll drop the corresponding changes from the bindings and the OF core then. > I'm not a fan of *-names, but fine. I suppose I could work without them, but I like the descriptiveness that they add to the device tree. There are also cases where they can be very essential. For example, what if a device can take two separate memory regions. One case that we have on Tegra is the display controller that can have a framebuffer and a color-conversion lookup table assigned to it on boot. I think in this particular case both are actually always there, but what if either of them was optional. Without -names it would be impossible to describe the context if only one is provided in device tree. Thierry
From: Thierry Reding <treding@nvidia.com> Hi Rob, all, this is a set of patches that I've been working on to allow me to use reserved memory regions more flexibly. One of the use-cases that I have is an external memory controller driver that gets passed one or two tables from firmware containing a set of EMC frequencies and the corresponding register values to program for these frequencies. One of these tables is the "nominal" table and an optional second table is "derated" and is used when the DRAM chips are overheating. I want to be able to pass these tables as separate memory-region entries. So what this small patchset does is make the reserved-memory code adapt to this situation better. On one hand, while the DT bindings currently support multiple regions per device tree node, it's slightly unintuitive to specify them. The first patch adds a memory-region-names property that allows the DT to specify a "consumer" name for these regions much like we do for things like clocks, resets or the reg property. At the same time, a new alias for memory-region, named memory-regions, is introduced to make this more consistent with other bindings. Patches 2 and 3 add support in the core OF reserved-memory code for these binding changes, with a fallback to the memory-region property if no memory-regions property exists. Patch 4 implements support for releasing multiple regions assigned to a single device rather than just the first. Thierry Thierry Reding (4): dt-bindings: reserved-memory: Introduce memory-region{s,-names} of: reserved-memory: Support memory-regions property of: reserved-memory: Support lookup of regions by name of: reserved-memory: Support multiple regions per device .../reserved-memory/reserved-memory.txt | 12 +++-- drivers/of/of_reserved_mem.c | 52 +++++++++++++------ include/linux/of_reserved_mem.h | 11 ++++ 3 files changed, 55 insertions(+), 20 deletions(-)