Hi Dragan, On Sunday, 30 June 2024 14:04:50 CEST Dragan Simic wrote: > > I also expected that (for v1) there would be a similar construct as was > > recently added for rk3588. But I should interpret Heiko's comments as > > that strategy should not be applied to rk356x? > > The trouble with applying the same strategy, ... One of the reasons I like/hoped for it is that I'm a 'sucker' for consistency. > ... the need for voltage ranges depends on one of the board features, > i.e. the GPU and NPU voltage regulators. As such, it still has to > affect the RK356x SoC dtsi, which may warrant separate > rk356x-gpu-range.dtsi, for example, but the troubles would arise ... ... but it's probably better if I (generally) abstain from taking part in the discussion about the correct/desired implementation as I don't understand the material in enough detail to meaningfully contribute. > That's why the v1 went with a macro instead. ... which didn't seem to help with my consistency wish ;-) (AFAIC there's no need to discuss this further (publicly)) > > When we/upstream adds npu support, I think we should also follow > > downstream's OPP values, unless we have a very good reason to > > deviate from that. > > That would make sense, especially because we haven't had the NPU > supported before in the mainline. I first wondered why you hadn't *updated* the npu OPP values ... to later find out they haven't been specified at all in 'upstream'. Cheers, Diederik
Attachment:
signature.asc
Description: This is a digitally signed message part.
