On Fri, Jun 07, 2024 at 06:55:01PM +0100, Conor Dooley wrote: > On Fri, Jun 07, 2024 at 06:29:49PM +0100, Dave Stevenson wrote: > > > > > --- > > > > I got the report of this third hand, I don't have a device and can't > > > > test this. I do wonder why the RPis get away with the sequence that > > > > seemingly doesn't work for the guy that reported this to me. My theory > > > > is either that they noticed the sequence was wrong while adding some > > > > other MSR access that is needed on this board while either cross > > > > checking the values written or because the other MSR accesses didn't > > > > take effect. > > > > Did the change fix it for the reporter? We're using the driver with no > > changes to the register settings cf mainline. > > Why it works on the Pi but not on a Microchip board is likely to be > > something quite subtle. > > I've asked, maybe it turns out to just be the first of my suggestions, > and they noticed it was not matching in passing. Apparently it was the latter & they did need to fix the sequence to be able to write the MSRs. > They did introduce two > additional MSR accesses, both outside of the range documented in the > datasheets I could find online. They did have explanations for what those > undocumented MSRs did (0x5040 and 0x5041) in the mail I got, but given > it's third hand info to me, I dunno if we have the datasheet etc. I'll > try to find out some more next week. Seemingly what those two additional MSRs do is under NDA so I would have no way of justifying a patch to add them or the devicetree property required to know whether or not the additional MSR writes is needed. :)
Attachment:
signature.asc
Description: PGP signature
