linux-kernel - Re: [PATCH 0/2] arm64: dts: amlogic: handle hdmi system clock

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date: Fri, 28 Jun 2024 11:10:43 +0200
From: Jerome Brunet <jbrunet@...libre.com>
To: Neil Armstrong <neil.armstrong@...aro.org>
Cc: Kevin Hilman <khilman@...libre.com>,  linux-kernel@...r.kernel.org,
  linux-amlogic@...ts.infradead.org,  devicetree@...r.kernel.org,  Rob
 Herring <robh@...nel.org>,  Krzysztof Kozlowski <krzk+dt@...nel.org>,
  Conor Dooley <conor+dt@...nel.org>
Subject: Re: [PATCH 0/2] arm64: dts: amlogic: handle hdmi system clock

On Fri 28 Jun 2024 at 10:10, Neil Armstrong <neil.armstrong@...aro.org> wrote:

> Hi,
>
> On 26/06/2024 17:27, Jerome Brunet wrote:
>> This patchset adds the setup of the HDMI system clock for HDMI Tx.
>> This is another step in cleaning HDMI Tx and its direct usage of HHI
>> register space. Eventually, this will help remove component usage from
>> the Amlogic display drivers.
>
> Thanks,
>
> Beware we will need to keep old DT with new kernel functional for a while,
> do removal of component & HHI in meson_dw_hdmi would need to wait for multiple
> kernel releases.

Oh, I'm aware of the pain DT backward compatibility will be on this one.
Situation is slightly more complex than the PWM ...

I'm not sure how keeping support both for the 'legacy HHI direct access'
and 'modern API and region' approaches will look like. It's likely to be a
mess.

What I posted so far are things I'm sure of and will not cause issue.
When I get to the controversial stuff, I'll post an RFC first.

>
> A migration step would be to add a phandle to hhi right now, so we can drop
> components earlier, then in a second time add a proper PHY and then mark
> the hhi reg as deprecated.

Giving the hhi syscon to HDMI-Tx is solving half the problem.
IMO, HDMI-TX should just get the HDMI PHY register space in HHI. Indeed
that could be added now as well, without causing issue to the existing
DTs and drivers.

The display drivers should not directly poke in the HHI bus, nor should it have
access to the whole bus.

If we are going to take the pain of fixing the DT interface, better do
it once and for all.

The 2 main HHI offenders are HDMI-Tx and vclk:
* HDMI-TX: I've got the that mostly sorted out, for an RFC at least.
* Vclk: Here it is more a matter CCF usage that HHI
  * The HDMI pll could use the regular DCO/mult-range driver from what I
    can see
  * The vclk display would need to get the DCO clock along with all the
    ODs/divider handle. Without rate propagation, it would be free to
    recreate the setups it needs. I don't have the full list and I did
    not spend much time on this yet but that's the idea.

>
> Neil
>
>> Jerome Brunet (2):
>>    arm64: dts: amlogic: gx: correct hdmi clocks
>>    arm64: dts: amlogic: setup hdmi system clock
>>   arch/arm64/boot/dts/amlogic/meson-g12-common.dtsi | 5 +++++
>>   arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi       | 9 +++++++--
>>   arch/arm64/boot/dts/amlogic/meson-gxl.dtsi        | 9 +++++++--
>>   3 files changed, 19 insertions(+), 4 deletions(-)
>> 

-- 
Jerome