On Wed, Aug 23, 2023 at 1:48 PM Krzysztof Kozlowski
<krzysztof.kozlowski@xxxxxxxxxx> wrote:
>
> On 23/08/2023 05:54, Chen-Yu Tsai wrote:
> >>> +
> >>> + regulator {
> >>> + compatible = "mediatek,mt6358-regulator";
> >>> +
> >>> + buck_vgpu {
> >>> + regulator-name = "vgpu";
> >>> + regulator-min-microvolt = <625000>;
> >>> + regulator-max-microvolt = <900000>;
> >>> + regulator-ramp-delay = <6250>;
> >>> + regulator-enable-ramp-delay = <200>;
> >>> + regulator-allowed-modes = <MT6397_BUCK_MODE_AUTO
> >>
> >> mt6397?
> >>
> >> Both cases look a bit confusing.
> >
> > There's only two regulator binding header files, mt6397 and mt6360.
> > They seem to correspond to the two classes of PMICs that MediaTek has.
> > I believe the two header files and thus the macros are meant to be
> > shared?
>
> Defines have specific model name, so they do not look like meant to be
> shared. If all the values of the binding match, they can be shared, but
> then this should be mentioned in the binding plus it should be used in
> the driver. I don't see your driver patches add include of this header.
Indeed. AFAICT the original raw values 0 and 1 just map directly to the
register bitfield values. And those are common across the series of PMICs.
I'll look into cleaning it up.
ChenYu
> > MT6397 and co refer to their AP PMICs, i.e. PMICs that are companion
> > chips to the SoC and provide most of the power rails a system needs,
> > along with things like RTC, audio codecs, etc.. The MT6358 and MT6366
> > belong to this class.
> >
> > MT6360 and possibly others refer to their charger PMICs, which integrate
> > a battery charger, USB type-C PD stuff, LED drivers, and a handful of
> > regulators.
>
>
> Best regards,
> Krzysztof
>
