On 09/01/2020 16:28, Mark Brown wrote:
On Thu, Jan 09, 2020 at 02:14:42PM +0000, Steven Price wrote:
On 08/01/2020 22:52, Nicolas Boichat wrote:
That'd be a bit awkward to match, though... Currently all bifrost
share the same compatible "arm,mali-bifrost", and it'd seem
weird/wrong to match "mediatek,mt8183-mali" in this driver? I have no
idea if any other Mali implementation will require a second regulator,
but with the MT8183 we do need it, see below.
This doesn't sound particularly hard, just new. Plenty of other devices
have quirks done based on the SoC they're in or the IP revision, this
would just be another of those quirks.
Well if devfreq was working (see patch 7
https://patchwork.kernel.org/patch/11322851/ for a partial
implementation), it would adjust both mali and sram regulators, see
the OPP table in patch 2
(https://patchwork.kernel.org/patch/11322825/): SRAM voltage needs to
be increased for frequencies >=698Mhz.
Now if you have some better idea how to implement this, I'm all ears!
Set a flag based on the compatible, then base runtime decisions off
that.
I'm not sure if it's better, but could we just encode the list of
regulators into device tree. I'm a bit worried about special casing an
"sram" regulator given that other platforms might have a similar
situation but call the second regulator a different name.
Obviously the list of regulators bound on a given platform is encoded in
the device tree but you shouldn't really be relying on that to figure
out what to request in the driver - the driver should know what it's
expecting.
From a driver perspective we don't expect to have to worry about power
domains/multiple regulators - the hardware provides a bunch of power
registers to turn on/off various parts of the hardware and this should
be linked (in hardware) to a PDC which sorts it out. The GPU/PDC handles
the required sequencing. So it *should* be a case of turn power/clocks
on and go.
However certain integrations may have quirks such that there are
physically multiple supplies. These are expected to all be turned on
before using the GPU. Quite how this is best represented is something
I'm not sure about.
Bear in mind that getting regulator stuff wrong can result
in physical damage to the system so it pays to be careful and to
consider that platform integrators have a tendency to rely on things
that just happen to work but aren't a good idea or accurate
representations of the system. It's certainly *possible* to do
something like that, the information is there, but I would not in any
way recommend doing things that way as it's likely to not be robust.
The possibility that the regulator setup may vary on other platforms
(which I'd expect TBH) does suggest that just requesting a bunch of
supply names optionally and hoping that we got all the ones that are
important on a given platform is going to lead to trouble down the line.
Certainly if we miss a regulator the GPU isn't going to work properly
(some cores won't be able to power up successfully). However at the
moment the driver will happily do this if someone provides it with a DT
which includes regulators that it doesn't know about. So I'm not sure
how adding special case code for a SoC would help here.
Steve, please fix your mail client to word wrap within paragraphs at
something substantially less than 80 columns. Doing this makes your
messages much easier to read and reply to.
Sorry about that - I switched to my laptop to escape the noisy work
going on outside the office, and apparently that was misconfigured.
Hopefully fixed now, thanks for letting me know!
Steve
