[PATCHv1 3/9] soc: amlogic: meson-ee-pwrc: Add hdmi power domain Meson g12a SoCs
Martin Blumenstingl
martin.blumenstingl at googlemail.com
Mon May 3 10:52:13 PDT 2021
Hi Anand,
On Mon, May 3, 2021 at 6:37 PM Anand Moon <linux.amoon at gmail.com> wrote:
[...]
> > > whenever I try something new it fails. Please ignore this series.
> > if the VPU and HDMI power domains were separate (from hardware
> > perspective, not from driver perspective) then your change is a good
> > step forward.
> > in that case VPU_HHI_MEMPD would need to be removed from wherever it's
> > currently used -> that means we need to also decide if we want to
> > break compatibility with older (before this series) .dtbs
> >
> >
>
> As per the datasheet S922X Datasheet, HDMI and VPU are different
> reg controller and they are independent of each other.
[...]
> Note: HDMI and AUDIO and Ethernet are also independent of each other.
let me say it this way: I've seen cases where the information from the
datasheet is not correct
Also to me it doesn't explicitly state that the bits are independent
of each other (at the same time it also doesn't state that they belong
together).
In the same datasheet you also find the HHI_HDMI_PLL_CNTL0 register
hdmi_dpll_M, hdmi_dpll_N and hdmi_dpll_od are listed in there.
The PLL output depends on hdmi_dpll_M and hdmi_dpll_N while
hdmi_dpll_od is taking the output of the two and dividing it.
This relation is nowhere described in the datasheet either so you
"just have to know it".
Unfortunately I don't know of any good way to check the relationship
of the power domain registers other than someone from Amlogic
explaining to us how it works internally.
[...]
> Below is the output on Odroid N2.
>
> [alarm at archl-on2 ~]$ sudo cat /sys/kernel/debug/pm_genpd/pm_genpd_summary
> domain status children
> performance
> /device runtime status
> ----------------------------------------------------------------------------------------------
> HDMI on
> 0
> /devices/platform/soc/ff600000.bus/ff600000.hdmi-tx unsupported
> 0
> AUDIO on
> 0
> /devices/platform/sound unsupported
> 0
> ETH on
> 0
> /devices/platform/soc/ff3f0000.ethernet active
> 0
> VPU on
> 0
> /devices/platform/soc/ff900000.vpu unsupported
> 0
This describes what Linux sees (based on how you configured the device-tree).
The output confirms what you are expecting to see (I think), but based
on that we can't tell what's right or wrong in terms of the actual
hardware.
To make another example: I could edit meson-g12b-odroid-n2.dtsi and
change the vin-supply of "VDDAO_3V3" to &usb_pwr_en
Then /sys/kernel/debug/regulator/regulator_summary would show that
VDDAO_3V3 is taking the voltage from USB_PWR_EN as input.
But from a hardware (schematics) perspective this is not correct.
Since the schematics describe the relation (input, output) between the
regulators we know how they are connected to each other.
If this relation was not described in the schematics then we'd be in
the same situation as with the power domains.
Best regards,
Martin
More information about the linux-arm-kernel
mailing list