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] [thread-next>] [day] [month] [year] [list]
Date:   Sun, 7 Nov 2021 14:45:37 +0100
From:   "H. Nikolaus Schaller" <hns@...delico.com>
To:     Paul Cercueil <paul@...pouillou.net>
Cc:     Paul Boddie <paul@...die.org.uk>, Rob Herring <robh+dt@...nel.org>,
        Mark Rutland <mark.rutland@....com>,
        Thomas Bogendoerfer <tsbogend@...ha.franken.de>,
        Geert Uytterhoeven <geert+renesas@...der.be>,
        Kees Cook <keescook@...omium.org>,
        "Eric W. Biederman" <ebiederm@...ssion.com>,
        Miquel Raynal <miquel.raynal@...tlin.com>,
        David Airlie <airlied@...ux.ie>,
        Daniel Vetter <daniel@...ll.ch>,
        Neil Armstrong <narmstrong@...libre.com>,
        Robert Foss <robert.foss@...aro.org>,
        Laurent Pinchart <Laurent.pinchart@...asonboard.com>,
        Jernej Skrabec <jernej.skrabec@...il.com>,
        Ezequiel Garcia <ezequiel@...labora.com>,
        Harry Wentland <harry.wentland@....com>,
        Sam Ravnborg <sam@...nborg.org>,
        Maxime Ripard <maxime@...no.tech>,
        Hans Verkuil <hverkuil-cisco@...all.nl>,
        Liam Girdwood <lgirdwood@...il.com>,
        Mark Brown <broonie@...nel.org>,
        "open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS" 
        <devicetree@...r.kernel.org>,
        linux-mips <linux-mips@...r.kernel.org>,
        linux-kernel <linux-kernel@...r.kernel.org>,
        Discussions about the Letux Kernel 
        <letux-kernel@...nphoenux.org>, Jon as Karlman <jonas@...boo.se>,
        dri-devel <dri-devel@...ts.freedesktop.org>
Subject: Re: [PATCH v5 5/7] MIPS: DTS: jz4780: Account for Synopsys HDMI
 driver and LCD controllers

Hi Paul,

> Am 05.10.2021 um 23:52 schrieb Paul Cercueil <paul@...pouillou.net>:
> 
> Hi Paul,
> 
> Le mar., oct. 5 2021 at 23:44:12 +0200, Paul Boddie <paul@...die.org.uk> a écrit :
>> On Tuesday, 5 October 2021 22:50:12 CEST Paul Cercueil wrote:
>>> Hi Nikolaus & Paul,
>>> Le mar., oct. 5 2021 at 14:29:17 +0200, H. Nikolaus Schaller
>> <hns@...delico.com> a écrit :
>>> >
>>> > diff --git a/arch/mips/boot/dts/ingenic/jz4780.dtsi
>>> > b/arch/mips/boot/dts/ingenic/jz4780.dtsi
>>> > index 9e34f433b9b5..c3c18a59c377 100644
>>> > --- a/arch/mips/boot/dts/ingenic/jz4780.dtsi
>>> > +++ b/arch/mips/boot/dts/ingenic/jz4780.dtsi
>>> > @@ -424,6 +424,51 @@ i2c4: i2c@...54000 {
>>> >
>>> >  		status = "disabled";
>>> >
>>> >  	};
>>> >
>>> > +	hdmi: hdmi@...80000 {
>>> > +		compatible = "ingenic,jz4780-dw-hdmi";
>>> > +		reg = <0x10180000 0x8000>;
>>> > +		reg-io-width = <4>;
>>> > +
>>> > +		clocks = <&cgu JZ4780_CLK_AHB0>, <&cgu JZ4780_CLK_HDMI>;
>>> > +		clock-names = "iahb", "isfr";
>>> > +
>>> > +		assigned-clocks = <&cgu JZ4780_CLK_HDMI>;
>>> > +		assigned-clock-rates = <27000000>;
>>> Any reason why this is set to 27 MHz? Is it even required? Because with
>>> the current ci20.dts, it won't be clocked at anything but 48 MHz.
>> EXCLK will be 48MHz, but the aim is to set the HDMI peripheral clock to 27MHz,
>> which is supposedly required. I vaguely recall a conversation about whether we
>> were doing this right, but I don't recall any conclusion.
> 
> But right now your HDMI clock is 48 MHz and HDMI works.

Is it? How did you find out?

And have you tried to remove assigned-clocks from jz4780.dtsi?

1. I read back:

root@...ux:~# cat /sys/kernel/debug/clk/hdmi/clk_rate
26909090
root@...ux:~# 

So for me it seems to be running at ~27 MHz.

2. If I remove the assigned-clocks or assigned-clock-rates from DT
the boot process hangs shortly after initializing drm.

3. If I set assigned-clock-rates = <48000000>, HDMI also works.

I get it read back from /sys/kernel/debug/clk/hdmi/clk_rate
of 46736842.

4. Conclusions:
* assigned-clocks are required
* it does not matter if 27 or 48 MHz
* I have no idea which value is more correct
* so I'd stay on the safe side of 27 MHz

5. But despite that found, please look into the programming
manual section 18.1.2.16. There is an

"Import Note: The clock must be between 18M and 27M, it occurs
fatal error if exceeding the range. "

6. Therefore I think it *may* work overclocked with 48MHz
but is not guaranteed or reliable above 27 MHz.

So everything is ok here.

> 
>>> > +
>>> > +		interrupt-parent = <&intc>;
>>> > +		interrupts = <3>;
>>> > +
>>> > +		/* ddc-i2c-bus = <&i2c4>; */
>>> > +
>>> > +		status = "disabled";
>>> > +	};
>>> > +
>>> > +	lcdc0: lcdc0@...50000 {
>>> > +		compatible = "ingenic,jz4780-lcd";
>>> > +		reg = <0x13050000 0x1800>;
>>> > +
>>> > +		clocks = <&cgu JZ4780_CLK_TVE>, <&cgu JZ4780_CLK_LCD0PIXCLK>;
>>> > +		clock-names = "lcd", "lcd_pclk";
>>> > +
>>> > +		interrupt-parent = <&intc>;
>>> > +		interrupts = <31>;
>>> > +
>>> > +		status = "disabled";
>>> I think you can keep lcdc0 enabled by default (not lcdc1 though), since
>>> it is highly likely that you'd want that.
>> As far as I know, the clock gating for the LCD controllers acts like a series
>> circuit, meaning that they both need to be enabled. Some testing seemed to
>> confirm this. Indeed, I seem to remember only enabling one clock and not
>> getting any output until I figured this weird arrangement out.
> 
> I'm not talking about clocks though, but about LCDC0 and LCDC1.

Ah, you mean status = "okay"; vs. status = "disabled";

Well, IMHO it is common practise to keep SoC subsystems disabled by
default (to save power and boot time) unless a board specific DTS explicitly
requests the SoC feature to be active. See for example mmc0, mmc1 or i2c0..i2c4.

All these are disabled in jz4780.dtsi and partially enabled in ci20.dts.

Why should lcdc0 be an exception in jz4780.dtsi?

BR and thanks,
Nikolaus

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ