On Mon, 13 Jan 2025 14:51:53 +0000 Mark Brown <broonie@xxxxxxxxxx> wrote: > On Mon, Jan 13, 2025 at 03:45:51PM +0100, Kory Maincent wrote: > > Mark Brown <broonie@xxxxxxxxxx> wrote: > > > > joining it up with the power limiting. It's fortunately not used > > > dynamically by anything at the minute so we could just remove that API > > > and replace it by a power one, given that nobody uses it and there do > > > appear to be users for the power based API. We do have some things that > > > set current limits in constraints IIRC. > > > There is few users for the regulator_set_current_limit function. > > https://elixir.bootlin.com/linux/v6.12.6/A/ident/regulator_set_current_limit > > > > > Not sure we could replace it to power limit that easily. > > Huh, I wonder what tree I grepped in. The DRM usage is yet more broken > usage of the regulator API, I'm not sure why it attracts this so much, > but the others are legit. Still, we should be able to map between the > two. We could have something like that in regulator_request_power_budget()? if (rdev->desc->ops->get_voltage && rdev->desc->ops->set_current_limit) { ret = regulator_get_voltage(rdev); if (ret < 0) return ret; tmp_64 = pw_req; tmp_64 *= 1000000000ull; /* uA = mW * 1000000000 / uV */ uA = DIV_ROUND_CLOSEST_ULL(tmp_64, uV); ret = regulator_set_current_limit(rdev, uA); if (ret) return ret; } > > > We probably also need something explicit about how we handle baseline > > > load from things like passive components, the assumption probably needs > > > to be that it's negligable. > > > We could add a devicetree property on the consumer node, but lets keep it > > for later. > > One problem is that there might not be a consumer node - things like > random passives don't tend to get represented. Mmh true, so indeed if they are not represented lets assume they are negligible. ;) -- Köry Maincent, Bootlin Embedded Linux and kernel engineering https://bootlin.com
