mbox series

[v2,00/14] HSI2, UFS & UFS phy support for Tensor GS101

Message ID 20240423205006.1785138-1-peter.griffin@linaro.org (mailing list archive)
Headers show
Series HSI2, UFS & UFS phy support for Tensor GS101 | expand

Message

Peter Griffin April 23, 2024, 8:49 p.m. UTC
Hi James, Martin, Alim, Bart, Krzysztof, Vinod, all

Firstly, many thanks to everyone who reviewed and tested v1.

This series adds support for the High Speed Interface (HSI) 2 clock
management unit, UFS controller and UFS phy calibration/tuning for GS101
found in Pixel 6.

With this series applied, UFS is now functional on gs101. The SKhynix
HN8T05BZGKX015 can be enumerated, partitions mounted etc. This allows us to
move away from the initramfs rootfs we have been using for development so far.

Merge Strategy
1) UFS driver/bindings via UFS/SCSI tree (James / Martin / Alim)
2) GS101 DTS/DTSI should go via Krzysztofs Exynos SoC tree
3) Clock driver/bindings via Clock tree (Krzysztof / Stephen)
4) PHY driver/bindings via PHY tree (Vinod)

The v2 series has been rebased on next-20240422, as such all the phy parts
which were already queued by Vinod have been dropped. Two new phy patches
are added to address review feedback received after the patches were queued.

The series is broadly split into the following parts:
1) dt-bindings documentation updates
2) gs101/oriole dts & dtsi updates
3) Prepatory patches for ufs-exynos driver
4) GS101 ufs-exynos support
5) gs101 phy fixes

As well as the v1 review feedback some additional cmu_hsi2 clocks were marked
as CLK_IGNORE_UNUSED in v2 so that all other remaining clocks in cmu_hsi2 can
be disabled and UFS will still be functional.

The sysreg clock was also moved from CLK_IS_CRITICAL in clk-gs101 to ufs node,
as the system is still functional with that clock disabled, however fine grained
clocking just around sysreg register accesses doesn't result in functional UFS.

kind regards,

Peter

Changes since v1:
 - collect up tags
 - google,gs101-clock: alphabetical ordering (Andre)
 - re-order samsung,exynos-ufs.yaml as per Krzysztof review
 - Ensure google,gs101.h dt-bindings is contained with bindings patch (Andre / Krzysztof)
 - fix google,gs101-hsi2-sysreg size (0x10000 not 0x1000) (Andre)
 - drop blank lines in clk-gs101 (Andre)
 - cmu-hsi2 alphabetical ordering (Andre / Krzysztof)
 - use GPIO defines in DT and add TODO pmic comment (Krzysztof)
 - Add sysreg clock to ufs node (Andre)
 - Mark additional cmu_hsi2 clocks with CLK_IGNORE_UNUSED flag (Peter)

lore v1: https://lore.kernel.org/linux-clk/20240404122559.898930-1-peter.griffin@linaro.org/

Peter Griffin (14):
  dt-bindings: clock: google,gs101-clock:  add HSI2 clock management
    unit
  dt-bindings: soc: google: exynos-sysreg: add dedicated hsi2 sysreg
    compatible
  dt-bindings: ufs: exynos-ufs: Add gs101 compatible
  arm64: dts: exynos: gs101: enable cmu-hsi2 clock controller
  arm64: dts: exynos: gs101: Add the hsi2 sysreg node
  arm64: dts: exynos: gs101: Add ufs, ufs-phy and ufs regulator dt nodes
  clk: samsung: gs101: add support for cmu_hsi2
  scsi: ufs: host: ufs-exynos: Add EXYNOS_UFS_OPT_UFSPR_SECURE option
  scsi: ufs: host: ufs-exynos: add EXYNOS_UFS_OPT_TIMER_TICK_SELECT
    option
  scsi: ufs: host: ufs-exynos: allow max frequencies up to 267Mhz
  scsi: ufs: host: ufs-exynos: add some pa_dbg_ register offsets into
    drvdata
  scsi: ufs: host: ufs-exynos: Add support for Tensor gs101 SoC
  phy: samsung-ufs: ufs: remove superfluous mfd/syscon.h header
  phy: samsung-ufs: ufs: exit on first reported error

 .../bindings/clock/google,gs101-clock.yaml    |  30 +-
 .../soc/samsung/samsung,exynos-sysreg.yaml    |   2 +
 .../bindings/ufs/samsung,exynos-ufs.yaml      |  38 +-
 .../boot/dts/exynos/google/gs101-oriole.dts   |  18 +
 arch/arm64/boot/dts/exynos/google/gs101.dtsi  |  54 ++
 drivers/clk/samsung/clk-gs101.c               | 508 +++++++++++++++++-
 drivers/phy/samsung/phy-samsung-ufs.c         |  11 +-
 drivers/ufs/host/ufs-exynos.c                 | 197 ++++++-
 drivers/ufs/host/ufs-exynos.h                 |  24 +-
 include/dt-bindings/clock/google,gs101.h      |  63 +++
 10 files changed, 921 insertions(+), 24 deletions(-)

Comments

Krzysztof Kozlowski April 25, 2024, 7:08 a.m. UTC | #1
On 23/04/2024 22:49, Peter Griffin wrote:
> Hi James, Martin, Alim, Bart, Krzysztof, Vinod, all
> 
> Firstly, many thanks to everyone who reviewed and tested v1.
> 
> This series adds support for the High Speed Interface (HSI) 2 clock
> management unit, UFS controller and UFS phy calibration/tuning for GS101
> found in Pixel 6.
> 
> With this series applied, UFS is now functional on gs101. The SKhynix
> HN8T05BZGKX015 can be enumerated, partitions mounted etc. This allows us to
> move away from the initramfs rootfs we have been using for development so far.
> 
> Merge Strategy
> 1) UFS driver/bindings via UFS/SCSI tree (James / Martin / Alim)
> 2) GS101 DTS/DTSI should go via Krzysztofs Exynos SoC tree
> 3) Clock driver/bindings via Clock tree (Krzysztof / Stephen)
> 4) PHY driver/bindings via PHY tree (Vinod)
> 
> The v2 series has been rebased on next-20240422, as such all the phy parts
> which were already queued by Vinod have been dropped. Two new phy patches
> are added to address review feedback received after the patches were queued.
> 
> The series is broadly split into the following parts:
> 1) dt-bindings documentation updates
> 2) gs101/oriole dts & dtsi updates
> 3) Prepatory patches for ufs-exynos driver
> 4) GS101 ufs-exynos support
> 5) gs101 phy fixes
> 

I asked to split, otherwise please explain why PHY and UFS depends on
DTS and clk.

Best regards,
Krzysztof
Peter Griffin April 25, 2024, 10:31 a.m. UTC | #2
Hi Krzysztof,

On Thu, 25 Apr 2024 at 08:08, Krzysztof Kozlowski <krzk@kernel.org> wrote:
>
> On 23/04/2024 22:49, Peter Griffin wrote:
> > Hi James, Martin, Alim, Bart, Krzysztof, Vinod, all
> >
> > Firstly, many thanks to everyone who reviewed and tested v1.
> >
> > This series adds support for the High Speed Interface (HSI) 2 clock
> > management unit, UFS controller and UFS phy calibration/tuning for GS101
> > found in Pixel 6.
> >
> > With this series applied, UFS is now functional on gs101. The SKhynix
> > HN8T05BZGKX015 can be enumerated, partitions mounted etc. This allows us to
> > move away from the initramfs rootfs we have been using for development so far.
> >
> > Merge Strategy
> > 1) UFS driver/bindings via UFS/SCSI tree (James / Martin / Alim)
> > 2) GS101 DTS/DTSI should go via Krzysztofs Exynos SoC tree
> > 3) Clock driver/bindings via Clock tree (Krzysztof / Stephen)
> > 4) PHY driver/bindings via PHY tree (Vinod)
> >
> > The v2 series has been rebased on next-20240422, as such all the phy parts
> > which were already queued by Vinod have been dropped. Two new phy patches
> > are added to address review feedback received after the patches were queued.
> >
> > The series is broadly split into the following parts:
> > 1) dt-bindings documentation updates
> > 2) gs101/oriole dts & dtsi updates
> > 3) Prepatory patches for ufs-exynos driver
> > 4) GS101 ufs-exynos support
> > 5) gs101 phy fixes
> >
>
> I asked to split, otherwise please explain why PHY and UFS depends on
> DTS and clk.

Seems I misunderstood your feedback. I thought you just want me to
make clear who was merging what from the series via which tree. But
you want separate series?

1) ufs host dt bindings & driver
2) minor phy fixes series (most patches got applied already for phy)

What do you want for cmu_hsi2 clocks and dts/dtsi? The device tree
depends on the clock bindings to compile

Thanks,

Peter.
Krzysztof Kozlowski April 25, 2024, 10:47 a.m. UTC | #3
On 25/04/2024 12:31, Peter Griffin wrote:
> Hi Krzysztof,
> 
> On Thu, 25 Apr 2024 at 08:08, Krzysztof Kozlowski <krzk@kernel.org> wrote:
>>
>> On 23/04/2024 22:49, Peter Griffin wrote:
>>> Hi James, Martin, Alim, Bart, Krzysztof, Vinod, all
>>>
>>> Firstly, many thanks to everyone who reviewed and tested v1.
>>>
>>> This series adds support for the High Speed Interface (HSI) 2 clock
>>> management unit, UFS controller and UFS phy calibration/tuning for GS101
>>> found in Pixel 6.
>>>
>>> With this series applied, UFS is now functional on gs101. The SKhynix
>>> HN8T05BZGKX015 can be enumerated, partitions mounted etc. This allows us to
>>> move away from the initramfs rootfs we have been using for development so far.
>>>
>>> Merge Strategy
>>> 1) UFS driver/bindings via UFS/SCSI tree (James / Martin / Alim)
>>> 2) GS101 DTS/DTSI should go via Krzysztofs Exynos SoC tree
>>> 3) Clock driver/bindings via Clock tree (Krzysztof / Stephen)
>>> 4) PHY driver/bindings via PHY tree (Vinod)
>>>
>>> The v2 series has been rebased on next-20240422, as such all the phy parts
>>> which were already queued by Vinod have been dropped. Two new phy patches
>>> are added to address review feedback received after the patches were queued.
>>>
>>> The series is broadly split into the following parts:
>>> 1) dt-bindings documentation updates
>>> 2) gs101/oriole dts & dtsi updates
>>> 3) Prepatory patches for ufs-exynos driver
>>> 4) GS101 ufs-exynos support
>>> 5) gs101 phy fixes
>>>
>>
>> I asked to split, otherwise please explain why PHY and UFS depends on
>> DTS and clk.
> 
> Seems I misunderstood your feedback. I thought you just want me to
> make clear who was merging what from the series via which tree. But
> you want separate series?
> 
> 1) ufs host dt bindings & driver
> 2) minor phy fixes series (most patches got applied already for phy)
> 
> What do you want for cmu_hsi2 clocks and dts/dtsi? The device tree
> depends on the clock bindings to compile

This is not specific to Samsung Soc, Qualcomm soc or any other arm-soc.
Independent patches for different subsystems should not be put together
in one patchset. You create false impression of dependencies, grow CC
list, cause issues when applying (I cannot just apply entire set with
one command, but need to run multiple commands (!!!), plus certain
subsystems will reject your patchset because they take everything or
nothing) and possible bisection issues (because patches which should be
tested independently, are put together so testing does not uncover
undocumented dependencies).

Almost never combine independent patches which are targeted to entirely
different subsystems. There are exceptions, but regular feature work is
not one of them.

Subsystem is everything in top level of drivers/ and drivers/soc/ (or
kind of arch/arm64/boot/dts/, but that tricky because
Tesla/Google/Exynos are one subsystem). Or whatever is there in
MAINTAINERS file.

I don't know, we keep repeating this over multiple times, so it could be
added to some docs, but people do not read docs...

1. Drivers and driver bindings go to subsystems.
2. DTS and board compatibles go to soc.
a. Any dependency on driver is a near-NAK.
b. Any dependency on headers must be clearly expressed, because headers
cannot be back-merged from subsystem tree to DTS tree.
c. Any usage or usage of bindings from other sets must be clearly
expressed (linked).
3. drivers/soc go to soc.

Things from list above targeting the same maintainer tree, can be
combined in one series, with dependencies expressed in patch changelogs
or cover letter.

Best regards,
Krzysztof