On 28/07/2022 02:22, Julius Werner wrote: >>> By "use case" I mean our particular platform and firmware requirements >>> -- or rather, the realities of building devices with widely >>> multi-sourced LPDDR parts. One cannot efficiently build firmware that >>> can pass an exact vendor-and-part-specific compatible string to Linux >>> for this binding for every single LPDDR part used on such a platform. >> >> Why cannot? You want to pass them as numerical values which directly map >> to vendor ID and some part, don't they? > > Yes, but the current compatible string format also requires the exact > part number, of which there are many thousands and it's impossible to > build a list in advance. Even for vendors, hardcoding 255 strings in a > tight firmware space would be an unnecessary burden. There are 25 for LPDDR2/3 and and 12 for LPDD4 (although many reserved so it might grow to ~32). You will not have 255 of them, although I actually don't insist on that - we can code manufacturer ID as well. > There's also an > update problem -- firmware may be built and signed and burned into ROM > long before the assembly of the final mainboard. Board manufacturers > want to be able to just drop-in replace a newly-sourced LPDDR part in > their existing production line without having to worry if the existing > (and possibly no longer changeable) firmware contains a string table > entry for this part. > > If you just want the compatible string to be unique, encoding the > numbers like Doug suggested (e.g. jedec,lpddr3-ff-0100) would work for > us. > >> If we talk about standard, then DT purpose is not for autodetectable >> pieces. These values are autodetectable, so such properties should not >> be encoded in DT. > > But the DT is the only interface that we have to pass information from > firmware to kernel and userspace. Where else should these properties > be encoded? They are auto-detectable, but not for the kernel itself > (only for memory-training firmware running in SRAM). Maybe the usual > rules of thumb don't apply here, because unlike all other peripheral > controllers the memory controller is special in that the kernel cannot > simply reinitialize it and get the same information from the original > source again. True, I thought these registers are aliased or also exposed as memory controllers, but at least for one MC I don't see it so kernel cannot read them. Best regards, Krzysztof
