Messages in this thread | | | Date | Tue, 25 Oct 2022 09:49:30 +0200 | From | Miquel Raynal <> | Subject | Re: [PATCH] dt-bindings: memory-controllers: arm,pl353-smc: Extend to support 'arm,pl354' SMC |
| |
Hi Rob,
robh@kernel.org wrote on Mon, 24 Oct 2022 09:31:41 -0500:
> On Mon, Oct 24, 2022 at 3:14 AM Miquel Raynal <miquel.raynal@bootlin.com> wrote: > > > > Hi Rob, > > > > robh@kernel.org wrote on Fri, 21 Oct 2022 15:39:28 -0500: > > > > > Add support for the Arm PL354 static memory controller to the existing > > > Arm PL353 binding. Both are different configurations of the same IP with > > > support for different types of memory interfaces. > > > > > > The 'arm,pl354' binding has already been in use upstream for a long time > > > in Arm development boards. The existing users have only the controller > > > without any child devices, so drop the required address properties > > > (ranges, #address-cells, #size-cells). The schema for 'ranges' is too > > > constrained as the order is not important and the PL354 has 8 > > > chipselects (And the PL353 actually has up to 8 too). > > > > I'm not convinced the ranges constraint should be soften. For me > > the order was important (and the description in the yaml useful, but > > that's a personal opinion). What makes you think the ranges order is > > not relevant on PL353? > > Address translation looks for a matching entry, so order doesn't > matter. However, we have seen cases in PCI hosts where the driver > populates registers based on the order of ranges. That's a driver > problem IMO. For PCI, it was multiple entries of the same type. For > this, we have the chip select number in the entry, so we shouldn't > have the same sort of problem. Except there is another issue that the > SRAM interface chipselects are numbered 1 and 2. The PL353 can have 4 > NAND chipselects, I don't think the host addresses are necessarily in > order or contiguous either, so you could need 4 entries for NAND. The > existing description doesn't handle that, and the chipselects for the > SRAM interface should have been numbered 4-7. I don't mind saying the > entries should be in order by chipselect, but we can't define indices > of the entries as was done. It's all kind of academic because we don't > have any h/w needing anything else though the Arm boards would if the > child nodes actually got defined (not likely at this point).
Alright, thanks for the feedback.
Cheers, Miquèl
| |