On Thu, Nov 19, 2020 at 05:22:43PM +0300, Dmitry Osipenko wrote:
> 16.11.2020 16:33, Mark Brown пишет:
> > No, you are failing to understand the purpose of this code. To
> > reiterate unless the device supports operating with the supply
> > physically absent then the driver should not be
16.11.2020 16:33, Mark Brown пишет:
> On Sun, Nov 15, 2020 at 08:42:10PM +0300, Dmitry Osipenko wrote:
>> 13.11.2020 20:28, Mark Brown пишет:
>
What should we do?
>
>>> As I keep saying the consumer driver should be enumerating the voltages
>>> it can set, if it can't find any and wants to
On Sun, Nov 15, 2020 at 08:42:10PM +0300, Dmitry Osipenko wrote:
> 13.11.2020 20:28, Mark Brown пишет:
> >> What should we do?
> > As I keep saying the consumer driver should be enumerating the voltages
> > it can set, if it can't find any and wants to continue then it can just
> > skip setting
13.11.2020 20:28, Mark Brown пишет:
> On Fri, Nov 13, 2020 at 08:13:49PM +0300, Dmitry Osipenko wrote:
>> 13.11.2020 19:15, Mark Brown пишет:
>
>>> My point here is that the driver shouldn't be checking for a dummy
>>> regulator, the driver should be checking the features that are provided
>>> to
On Fri, Nov 13, 2020 at 08:13:49PM +0300, Dmitry Osipenko wrote:
> 13.11.2020 19:15, Mark Brown пишет:
> > On Fri, Nov 13, 2020 at 06:55:27PM +0300, Dmitry Osipenko wrote:
> >> 13.11.2020 17:29, Mark Brown пишет:
> >
> >>> It's not clear if it matters - it's more a policy decision on the part
>
On Fri, Nov 13, 2020 at 08:13:49PM +0300, Dmitry Osipenko wrote:
> 13.11.2020 19:15, Mark Brown пишет:
> > My point here is that the driver shouldn't be checking for a dummy
> > regulator, the driver should be checking the features that are provided
> > to it by the regulator and handling those.
13.11.2020 19:15, Mark Brown пишет:
> On Fri, Nov 13, 2020 at 06:55:27PM +0300, Dmitry Osipenko wrote:
>> 13.11.2020 17:29, Mark Brown пишет:
>
>>> It's not clear if it matters - it's more a policy decision on the part
>>> of the driver about what it thinks safe error handling is. If it's not
>
On Fri, Nov 13, 2020 at 06:55:27PM +0300, Dmitry Osipenko wrote:
> 13.11.2020 17:29, Mark Brown пишет:
> > It's not clear if it matters - it's more a policy decision on the part
> > of the driver about what it thinks safe error handling is. If it's not
> If regulator_get() returns a dummy
13.11.2020 17:29, Mark Brown пишет:
> On Fri, Nov 13, 2020 at 01:37:01AM +0300, Dmitry Osipenko wrote:
>> 12.11.2020 23:01, Mark Brown пишет:
But it's not allowed to change voltage of a dummy regulator, is it
intentional?
>
>>> Of course not, we can't know if the requested new voltage
On Fri, Nov 13, 2020 at 01:37:01AM +0300, Dmitry Osipenko wrote:
> 12.11.2020 23:01, Mark Brown пишет:
> >> But it's not allowed to change voltage of a dummy regulator, is it
> >> intentional?
> > Of course not, we can't know if the requested new voltage is valid - the
> > driver would have to
12.11.2020 23:01, Mark Brown пишет:
>> But it's not allowed to change voltage of a dummy regulator, is it
>> intentional?
> Of course not, we can't know if the requested new voltage is valid - the
> driver would have to have explict support for handling situations where
> it's not possible to
On Thu, Nov 12, 2020 at 10:16:14PM +0300, Dmitry Osipenko wrote:
> 12.11.2020 20:16, Mark Brown пишет:
> > On Thu, Nov 12, 2020 at 07:59:36PM +0300, Dmitry Osipenko wrote:
> >> Also, some device-trees won't have that regulator anyways because board
> >> schematics isn't available, and thus, we
12.11.2020 20:16, Mark Brown пишет:
> On Thu, Nov 12, 2020 at 07:59:36PM +0300, Dmitry Osipenko wrote:
>> 11.11.2020 14:55, Mark Brown пишет:
>>> On Wed, Nov 11, 2020 at 12:23:41AM +0300, Dmitry Osipenko wrote:
>
I already changed that code to use regulator_get_optional() for v2.
>
>>> That
On Thu, Nov 12, 2020 at 07:59:36PM +0300, Dmitry Osipenko wrote:
> 11.11.2020 14:55, Mark Brown пишет:
> > On Wed, Nov 11, 2020 at 12:23:41AM +0300, Dmitry Osipenko wrote:
> >> I already changed that code to use regulator_get_optional() for v2.
> > That doesn't look entirely appropriate given
11.11.2020 14:55, Mark Brown пишет:
> On Wed, Nov 11, 2020 at 12:23:41AM +0300, Dmitry Osipenko wrote:
>> 10.11.2020 23:32, Mark Brown пишет:
>
> + if (!device_property_present(dc->dev, "core-supply"))
> + return;
>
This is a potentially heavy operation, so I think we should
On Wed, Nov 11, 2020 at 12:23:41AM +0300, Dmitry Osipenko wrote:
> 10.11.2020 23:32, Mark Brown пишет:
> >>> + if (!device_property_present(dc->dev, "core-supply"))
> >>> + return;
> >> This is a potentially heavy operation, so I think we should avoid that
> >> here. How about you use
On Tue, Nov 10, 2020 at 09:29:45PM +0100, Thierry Reding wrote:
> > + err = dev_pm_opp_of_add_table(dc->dev);
> > + if (err) {
> > + dev_err(dc->dev, "failed to add OPP table: %d\n", err);
> > + goto put_hw;
> > + }
> > +
> > + err = devm_add_action(dc->dev,
10.11.2020 23:29, Thierry Reding пишет:
>> +/* legacy device-trees don't have OPP table */
>> +if (!device_property_present(dc->dev, "operating-points-v2"))
>> +return 0;
> "Legacy" is a bit confusing here. For one, no device trees currently
> have these tables and secondly,
10.11.2020 23:32, Mark Brown пишет:
> On Tue, Nov 10, 2020 at 09:29:45PM +0100, Thierry Reding wrote:
>> On Thu, Nov 05, 2020 at 02:44:08AM +0300, Dmitry Osipenko wrote:
>
>>> + /*
>>> +* Voltage scaling is optional and trying to set voltage for a dummy
>>> +* regulator will error out.
10.11.2020 23:29, Thierry Reding пишет:
>> +
>> +dc->opp_table = dev_pm_opp_get_opp_table(dc->dev);
>> +if (IS_ERR(dc->opp_table))
>> +return dev_err_probe(dc->dev, PTR_ERR(dc->opp_table),
>> + "failed to prepare OPP table\n");
>> +
>> +if
On Tue, Nov 10, 2020 at 09:29:45PM +0100, Thierry Reding wrote:
> On Thu, Nov 05, 2020 at 02:44:08AM +0300, Dmitry Osipenko wrote:
> > + /*
> > +* Voltage scaling is optional and trying to set voltage for a dummy
> > +* regulator will error out.
> > +*/
> > + if
On Thu, Nov 05, 2020 at 02:44:08AM +0300, Dmitry Osipenko wrote:
> Add OPP and SoC core voltage scaling support to the display controller
> driver. This is required for enabling system-wide DVFS on older Tegra
> SoCs.
>
> Tested-by: Peter Geis
> Tested-by: Nicolas Chauvet
> Signed-off-by:
Add OPP and SoC core voltage scaling support to the display controller
driver. This is required for enabling system-wide DVFS on older Tegra
SoCs.
Tested-by: Peter Geis
Tested-by: Nicolas Chauvet
Signed-off-by: Dmitry Osipenko
---
drivers/gpu/drm/tegra/Kconfig | 1 +
23 matches
Mail list logo
