12.11.2020 20:16, Mark Brown пишет:

On Thu, Nov 12, 2020 at 07:59:36PM +0300, Dmitry Osipenko wrote:

quoted

11.11.2020 14:55, Mark Brown пишет:

quoted

On Wed, Nov 11, 2020 at 12:23:41AM +0300, Dmitry Osipenko wrote:

quoted

quoted

quoted

I already changed that code to use regulator_get_optional() for v2.

quoted

quoted

That doesn't look entirely appropriate given that the core does most
likely require some kind of power to operate.

quoted

We will need to do this because older DTBs won't have that regulator and
we want to keep them working.

quoted

Also, some device-trees won't have that regulator anyways because board
schematics isn't available, and thus, we can't fix them.

This is what dummy supplies are for?

But it's not allowed to change voltage of a dummy regulator, is it
intentional?

quoted

quoted

quoted

Regarding the enumerating supported voltage.. I think this should be
done by the OPP core, but regulator core doesn't work well if
regulator_get() is invoked more than one time for the same device, at
least there is a loud debugfs warning about an already existing

quoted

quoted

I don't understand why this would be an issue - if nothing else the core
could just offer an interface to trigger the check.

quoted

It's not an issue, I just described what happens when device driver
tries to get a regulator twice.

quoted

There was an issue once that check is added to the regulator core code.
But perhaps not worth to discuss it for now because I don't remember
details.

So there's no known obstacle to putting enumeration of supported
voltages into the OPP core then?  I'm a bit confused here.

It's an obstacle if both OPP and device driver need to get the same
regulator. Like in the case of this DRM driver, which need to control
the voltage instead of allowing OPP core to do it.

Please notice that devm_tegra_dc_opp_table_init() of this patch doesn't
use dev_pm_opp_set_regulators(), which would allow OPP core to filter
out unsupported OPPs. But then OPP core will need need to get an already
requested regulator and this doesn't work well.

quoted

quoted

quoted

directory for a regulator. It's easy to check whether the debug
directory exists before creating it, like thermal framework does it for
example, but then there were some other more difficult issues.. I don't
recall what they were right now. Perhaps will be easier to simply get a
error from regulator_set_voltage() for now because it shouldn't ever
happen in practice, unless device-tree has wrong constraints.

quoted

quoted

The constraints might not be wrong, there might be some board which has
a constraint somewhere for 

quoted

In this case board's DT shouldn't specify unsupportable OPPs.

Ah, so each board duplicates the OPP tables then, or there's an
expectation that if there's some limit then they'll copy and modify the
table?  If that's the case then it's a bit redundant to do filtering
indeed.

I think this is not strictly defined. Either way will work, although
perhaps it should be more preferred that unsupported OPPs aren't present
in a device-tree.