On Fri, Jan 17, 2025 at 10:46:00AM +0100, Gregory CLEMENT wrote: > >> - const: mti,mips-cm > >> + oneOf: > >> + - const: mti,mips-cm > >> + - const: mti,eyeq6-cm > > > > Being a mobileye device, the vendor prefix should be mobileye. > > I chose mti because actually this block is part of the I6500 and > provided as is by MIPS. But MIPS or MTI did not create eyeq6, so then product does not fit vendor. > > > > >> + description: > >> + On EyeQ6 the HCI (Hardware Cache Initialization) information for > >> + the L2 cache in multi-cluster configuration is broken. > >> > >> reg: > >> description: > >> @@ -25,14 +30,29 @@ properties: > >> > >> required: > >> - compatible > >> - - reg > >> > >> additionalProperties: false > >> > >> +if: > >> + properties: > >> + compatible: > >> + contains: > >> + const: mti,eyeq6-cm > >> +then: > >> + properties: > >> + reg: false > >> +else: > >> + required: > >> + - reg > > > > How does one access this block with no registers? Is this some subset of > > a larger block? If so, need to define that block first. > > CM stands for Coherence Manager. This component is mandatory when you > want to do SMP across MIPS core. This is part of the MIPS architecture, > and the address of the CM is provided by the Coprocessor 0. > > "CP0 is incorporated on the CPU chip and supports the virtual memory > system and exception handling. CP0 is also referred to as the System > Control Coprocessor." > > So to summarize, in a functional system, this information doesn't have > to be exposed through the device tree, as it is available at runtime > from any MIPS CPU. > > > > > These 2 blocks don't look related and the only property shared is > > 'compatible'. This should be a separate doc. > > As mentioned in the cover letter, I reused the work from Jiaxun, who > needed to deal with bogus CM but in a different way. In his use case, > the issue with the CM was that the address in CP0 was wrong. In my case, > this address is correct; it is only one piece of information reported by > the CM that is wrong. I don't mind creating a separate doc if you > still think it is the right thing to do. So the programming interface in general is the same, but in one case the reg/address detection does not work reliably? I guess could stay the same doc, but all this should be explained in binding description. Best regards, Krzysztof
