> Am 06.12.2023 um 17:02 schrieb Conor Dooley <conor@xxxxxxxxxx>: > > On Tue, Dec 05, 2023 at 07:04:05PM +0100, H. Nikolaus Schaller wrote: >>> Am 05.12.2023 um 18:33 schrieb Andrew Davis <afd@xxxxxx>: >>> >>> On 12/5/23 2:17 AM, H. Nikolaus Schaller wrote: >>>>> + - enum: >>>>> + - ti,omap3430-gpu # Rev 121 >>>>> + - ti,omap3630-gpu # Rev 125 >>>> Is the "Rev 121" and "Rev 125" a property of the SoC integration (clock/reset/power >>>> hookup etc.) or of the integrated SGX core? >>> >>> The Rev is a property of the SGX core, not the SoC integration. >> >> Then, it should belong there and not be a comment of the ti,omap*-gpu record. >> In this way it does not seem to be a proper hardware description. >> >> BTW: there are examples where the revision is part of the compatible string, even >> if the (Linux) driver makes no use of it: >> >> drivers/net/ethernet/xilinx/xilinx_emaclite.c > > AFAICT these Xilinx devices that put the revisions in the compatible are > a different case - they're "soft" IP intended for use in the fabric of > an FPGA, and assigning a device specific compatible there does not make > sense. > > In this case it appears that the revision is completely known once you > see "ti,omap3630-gpu", so encoding the extra "121" into the compatible > string is not required. Well, I would not put my hand in the fire for this assumption. And I am a friend of explicitly stating what is instead ot encoding indirectly. > >> >>> But it seems that >>> compatible string is being used to define both (as we see being debated in the other >>> thread on this series). >>> >>>> In my understanding the Revs are different variants of the SGX core (errata >>>> fixes, instruction set, pipeline size etc.). And therefore the current driver code >>>> has to be configured by some macros to handle such cases. >>>> So the Rev should IMHO be part of the next line: >>>>> + - const: img,powervr-sgx530 >>>> + - enum: >>>> + - img,powervr-sgx530-121 >>>> + - img,powervr-sgx530-125 >>>> We have a similar definition in the openpvrsgx code. >>>> Example: compatible = "ti,omap3-sgx530-121", "img,sgx530-121", "img,sgx530"; >>>> (I don't mind about the powervr- prefix). >>>> This would allow a generic and universal sgx driver (loaded through just matching >>>> "img,sgx530") to handle the errata and revision specifics at runtime based on the >>>> compatible entry ("img,sgx530-121") and know about SoC integration ("ti,omap3-sgx530-121"). > > The "raw" sgx530 compatible does not seem helpful if the sgx530-121 or > sgx530-125 compatibles are also required to be present for the driver to > actually function. Indeed. This seems to be redundant (but may need some pattern processing). > The revision specific compatibles I would not object > to, but everything in here has different revisions anyway - does the > same revision actually appear in multiple devices? If it doesn't then I > don't see any value in the suffixed compatibles either. Well, we don't know. So far only a subset of SoC with the SGX GPU core variants has been considered (mainly because lack of user space code and device owners). Maybe someone with insider knowledge can give a hint if the SGX version numbers were assigned uniquely for each SoC integration project. > >>>> And user-space can be made to load the right firmware variant based on "img,sgx530-121" >>>> I don't know if there is some register which allows to discover the revision long >>>> before the SGX subsystem is initialized and the firmware is up and running. >>>> What I know is that it is possible to read out the revision after starting the firmware >>>> but it may just echo the version number of the firmware binary provided from user-space. >>> >>> We should be able to read out the revision (register EUR_CR_CORE_REVISION), the problem is >>> today the driver is built for a given revision at compile time. >> >> Yes, that is something we had planned to get rid of for a long time by using different compatible >> strings and some variant specific struct like many others drivers are doing it. >> But it was a to big task so nobody did start with it. >> >>> That is a software issue, >>> not something that we need to encode in DT. While the core ID (SGX5xx) can be also detected >>> (EUR_CR_CORE_ID), the location of that register changes, and so it does need encoded in >>> DT compatible. >> >> Ok, I didn't know about such registers as there is not much public information available. >> Fair enough, there are some error reports about in different forums. >> >> On the other hand we then must read out this register in more or less early initialization >> stages. Even if we know this information to be static and it could be as simple as a list >> of compatible strings in the driver. >> >>> The string "ti,omap3430-gpu" tells us the revision if we cannot detect it (as in the current >>> driver), and the SoC integration is generic anyway (just a reg and interrupt). >> >> It of course tells, but may need a translation table that needs to be maintained in a >> different format. Basically the same what the comments show in a non-machine readable >> format. >> >> I just wonder why the specific version can or should not become simply part of the DTS >> and needs this indirection. >> >> Basically it is a matter of openness for future (driver) development and why it needs >> careful decisions. >> >> So in other words: I would prefer to see the comments about versions encoded in the device >> tree binary to make it machine readable. > > It's already machine readable if it is invariant on an SoC given the > patch had SoC-specific compatibles. But needs a translation table to get to the revision number. I have not yet brought into discussion that there are different firmwares for sgx530-121, sgx530-125, sgx544-116 etc. And user-space code may also depend on to be able to chose the right one if multiple firmware packages are installed. Currently this is not the case but would be a major benfit for OS packages. To automate this we need a mechanism to scan the device tree for a compatible string that tells which firmware variant to load. But why force this to depend on the SoC compatible if it only depends indirectly? By the way, there is a tested and working driver using the scheme with the sub-versions: https://github.com/openpvrsgx-devgroup/linux_openpvrsgx/blob/11cc7876ba39b6172d19ee0bf0a872c1d3d745e1/drivers/gpu/drm/pvrsgx/pvr-drv.c#L306 On the other hand As far as I see this will can of course be adapted to the newly proposed scheme. But it still seems a bit twisted to me. Maybe because we for example define LCD panel compatibles not by the compatible of the device they are installed in. BR, Nikolaus