linux-kernel - Re: [PATCH v2 3/3] ARM: dts: lpc32xx: Update spi clock properties

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]

Message-ID: <20220327183213.GA36326@localhost>
Date:   Sun, 27 Mar 2022 14:32:13 -0400
From:   Trevor Woerner <twoerner@...il.com>
To:     Vladimir Zapolskiy <vz@...ia.com>
Cc:     Robin Murphy <robin.murphy@....com>, Arnd Bergmann <arnd@...db.de>,
        Kuldeep Singh <singh.kuldeep87k@...il.com>,
        Olof Johansson <olof@...om.net>, SoC Team <soc@...nel.org>,
        Rob Herring <robh+dt@...nel.org>,
        DTML <devicetree@...r.kernel.org>,
        Linux ARM <linux-arm-kernel@...ts.infradead.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v2 3/3] ARM: dts: lpc32xx: Update spi clock properties

Hi Vladimir,

On Sun 2022-03-27 @ 07:27:00 PM, Vladimir Zapolskiy wrote:
> Hi Trevor,
> 
> On 3/27/22 5:57 AM, Trevor Woerner wrote:
> > On the lpc32xx both the SPI and SSP peripherals are APB devices (low-speed)
> > 
> > lpc32xx-apb-peripherals.png
> > The APB devices on this SoC are driven by the PERIPH_CLK which can be
> > derived from either the HCLK or the SYSCLK.
> 
> thank you for the data, I'd like to reference to Table 14, which says that
> both bus clock source and function clock source for SSP0 and SSP1 are a
> non-selectable HCLK. I'm unsure if for instance PERIPH_CLK can be set as
> a function clock source for SSPx.

Interesting. I see that I had assumed that all APB peripherals would be driven
by the PERIPH_CLK since the diagram shows that clock as going to all APB
peripherals.

In the SSP chapter, for example, there is a clock prescale register, which
says:

	This register controls the factor by which the prescaler divides the AHB clock
	HCLK to yield the prescaler clock that is, in turn, divided by the SCR factor
	in SSPnCR0, to determine the bit clock.

So that confirms that the clock driving the SSP (an APB peripheral) is the
AHB's HCLK!

Section 21.7 of the SPI chapter also clearly shows the SPI clock as being
derived from the HCLK as well.

Thanks for the clarification :-)

> > lpc32xx-clock.png
> > The default on reset is for PERIPH_CLK to be derived from the SYSCLK but
> > both U-Boot and Linux run in "normal" mode, which is to say that
> > PERIPH_CLK, HCLK, ARM_CLK, and DDRAM_CLK are derived from the HCLK PLL.>
> > There is no separate SSP clock, the SSP is driven by one clock: the
> > PERIPH_CLK (or "apb_pclk").
> 
> Right, there is no separate SSP clock in sense of a bus clock, it is
> correct to get HCLK clock (or equally its child SSP clock) rate as a bus
> clock rate, and the reason for introduction of SSP0/SSP1 clocks is that
> these clocks are gated.
> 
> If I'm correct above, what does it mean in connection to LPC32xx device
> tree bindings? The first or single clock source shall remain to be SSPx
> clock, either the former is "sspclk" or "apb_pclk".

Doesn't this mean the apb_pclk should not be specified as the SSP/SPI clock?
If sspclk is a synonym for HCLK, then sspclk and apb_pclk are completely
different clocks. On my device HCLK is 260MHz and PERIPH_CLK is 13MHz.