| Message ID | 20230713090015.127541-1-william.qiu@starfivetech.com |
|---|---|
| Headers | show |
| Series | Add SPI module for StarFive JH7110 SoC | expand |
On Thu, Jul 13, 2023 at 05:00:14PM +0800, William Qiu wrote: > The SPI controller only need apb_pclk clock to work properly on JH7110 SoC, > so there add minItems whose value is equal to 1. Other platforms do not > have this constraint. Presumably this means that this is some variant of the usual pl022 IP, or that the clock is in fact present but is not modelled in your DT?
On Thu, Jul 13, 2023 at 02:39:19PM +0200, Krzysztof Kozlowski wrote: > On 13/07/2023 14:28, Mark Brown wrote: > > On Thu, Jul 13, 2023 at 05:00:14PM +0800, William Qiu wrote: > > > >> The SPI controller only need apb_pclk clock to work properly on JH7110 SoC, > >> so there add minItems whose value is equal to 1. Other platforms do not > >> have this constraint. > > > > Presumably this means that this is some variant of the usual pl022 IP, > > Hm, in such case this could mean we need dedicated compatible. Except the vendor in the ID registers should be different if the IP is modified. I suspect that PCLK and SSPCLK are tied to the same clock source. There must be an SSPCLK because that is the one used to clock the SPI bus and we need to know the frequency of it. Rob
On 2023/7/13 22:57, Rob Herring wrote: > On Thu, Jul 13, 2023 at 02:39:19PM +0200, Krzysztof Kozlowski wrote: >> On 13/07/2023 14:28, Mark Brown wrote: >> > On Thu, Jul 13, 2023 at 05:00:14PM +0800, William Qiu wrote: >> > >> >> The SPI controller only need apb_pclk clock to work properly on JH7110 SoC, >> >> so there add minItems whose value is equal to 1. Other platforms do not >> >> have this constraint. >> > >> > Presumably this means that this is some variant of the usual pl022 IP, >> >> Hm, in such case this could mean we need dedicated compatible. > > Except the vendor in the ID registers should be different if the IP is > modified. > > I suspect that PCLK and SSPCLK are tied to the same clock source. There > must be an SSPCLK because that is the one used to clock the SPI bus and > we need to know the frequency of it. > > Rob After communicating with colleagues in SoC FE, I learned that PCLK and SSPCLK were homologous on JH7110. He said that SSPCLK would divide the frequency internally anyway, and there was no need for external part frequency, so he directly gave them together. So, should I call this clock ssp_apb or keep it SSPCLK? Best regards, William
On Fri, Jul 14, 2023 at 03:14:59PM +0800, William Qiu wrote: > On 2023/7/13 22:57, Rob Herring wrote: > > I suspect that PCLK and SSPCLK are tied to the same clock source. There > > must be an SSPCLK because that is the one used to clock the SPI bus and > > we need to know the frequency of it. > After communicating with colleagues in SoC FE, I learned that PCLK and > SSPCLK were homologous on JH7110. He said that SSPCLK would divide the > frequency internally anyway, and there was no need for external part frequency, > so he directly gave them together. > So, should I call this clock ssp_apb or keep it SSPCLK? I'd expect this to be handled in the DTS for the SoC - connect both clocks the binding requires to whatever the upstream clock is, it's not clear to me that any binding change is required.
On 2023/7/14 19:52, Mark Brown wrote: > On Fri, Jul 14, 2023 at 03:14:59PM +0800, William Qiu wrote: >> On 2023/7/13 22:57, Rob Herring wrote: > >> > I suspect that PCLK and SSPCLK are tied to the same clock source. There >> > must be an SSPCLK because that is the one used to clock the SPI bus and >> > we need to know the frequency of it. > >> After communicating with colleagues in SoC FE, I learned that PCLK and >> SSPCLK were homologous on JH7110. He said that SSPCLK would divide the >> frequency internally anyway, and there was no need for external part frequency, >> so he directly gave them together. > >> So, should I call this clock ssp_apb or keep it SSPCLK? > > I'd expect this to be handled in the DTS for the SoC - connect both > clocks the binding requires to whatever the upstream clock is, it's not > clear to me that any binding change is required. You mean binding two clocks, with the same clock source? Then there is no need to modify YAML. Best regards, William
On Tue, Jul 18, 2023 at 02:06:01PM +0800, William Qiu wrote: > On 2023/7/14 19:52, Mark Brown wrote: > > On Fri, Jul 14, 2023 at 03:14:59PM +0800, William Qiu wrote: > >> After communicating with colleagues in SoC FE, I learned that PCLK and > >> SSPCLK were homologous on JH7110. He said that SSPCLK would divide the > >> frequency internally anyway, and there was no need for external part frequency, > >> so he directly gave them together. > >> So, should I call this clock ssp_apb or keep it SSPCLK? > > I'd expect this to be handled in the DTS for the SoC - connect both > > clocks the binding requires to whatever the upstream clock is, it's not > > clear to me that any binding change is required. > You mean binding two clocks, with the same clock source? Then there is no > need to modify YAML. Yes, exactly.
On Thu, 13 Jul 2023 17:00:12 +0800, William Qiu wrote: > This patchset adds initial rudimentary support for the StarFive > SPI controller. And this driver will be used in StarFive's > VisionFive 2 board. The first patch constrain minItems of clocks > for JH7110 SPI and Patch 2 adds support for StarFive JH7110 SPI. > > Changes v1->v2: > - Rebaed to v6.5rc1. > - Submitted reference file separately. > - Dropped 'status' node as it was 'okay' by default. > - Dropped Co-developed-by message. > > [...] Applied to https://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi.git for-next Thanks! [1/3] dt-bindings: spi: add reference file to YAML commit: 8858babff615ee366bf570c1facfbd0845dd924e [2/3] dt-bindings: spi: constrain minItems of clocks and clock-names (no commit info) All being well this means that it will be integrated into the linux-next tree (usually sometime in the next 24 hours) and sent to Linus during the next merge window (or sooner if it is a bug fix), however if problems are discovered then the patch may be dropped or reverted. You may get further e-mails resulting from automated or manual testing and review of the tree, please engage with people reporting problems and send followup patches addressing any issues that are reported if needed. If any updates are required or you are submitting further changes they should be sent as incremental updates against current git, existing patches will not be replaced. Please add any relevant lists and maintainers to the CCs when replying to this mail. Thanks, Mark