| Message ID | 1738736156-119203-1-git-send-email-shawn.lin@rock-chips.com |
|---|---|
| Headers | show |
| Series | Initial support for RK3576 UFS controller | expand |
On Wed, 5 Feb 2025 at 07:16, Shawn Lin <shawn.lin@rock-chips.com> wrote: > > This patchset adds initial UFS controller supprt for RK3576 SoC. > Patch 1 is the dt-bindings. Patch 2-4 deal with rpm and spm support > in advanced suggested by Ulf. Patch 5 exports two new APIs for host > driver. Patch 6 and 7 are the host driver and dtsi support. Looks like this series is almost ready to be merged? If so, may I suggest that I pick patch2, patch3 and patch4 via my pmdomain tree and share them via an immutable branch, so they can be pulled into James/Martin's scsi tree? Or do you prefer another route? Kind regards Uffe > > > Changes in v7: > - add definitions for all kinds of hex values if possible > - Misc log and comment improvement > - use udelay for less than 10us cases > - other improvements suggested by Mani > - Use 0x0 for consistency > - Collect Mani's acked-by tag > > Changes in v6: > - fix indentation to 4 spaces suggested by Krzysztof > - export dev_pm_genpd_rpm_always_on() > - replace host drivers with glue drivers suggested by Mani > - add Main's review tag > - remove UFS_MAX_CLKS > - improve err log > - remove hardcoded clocks > - remove comment from ufs_rockchip_device_reset() > - remove pm_runtime_* from ufs_rockchip_remove() > - rebase to scsi/next > - move ufs_rockchip_set_pm_lvl to ufs_rockchip_rk3576_init() > - add comments about device_set_awake_path() > - remove comments suggested by Mani > > Changes in v5: > - use ufshc for devicetree example suggested by Mani > - fix a compile warning > - use device_set_awake_path() and disable ref_out_clk in suspend > - remove pd_id from header > - reconstruct ufs_rockchip_hce_enable_notify() to workaround hce enable > without using new quirk > > Changes in v4: > - properly describe reset-gpios > - deal with power domain of rpm and spm suggested by Ulf > - Fix typo and disable clks in ufs_rockchip_remove > - remove clk_disable_unprepare(host->ref_out_clk) from > ufs_rockchip_remove > > Changes in v3: > - rename the file to rockchip,rk3576-ufshc.yaml > - add description for reset-gpios > - use rockchip,rk3576-ufshc as compatible > - reword Kconfig description > - elaborate more about controller in commit msg > - use rockchip,rk3576-ufshc for compatible > - remove useless header file > - remove inline for ufshcd_is_device_present > - use usleep_range instead > - remove initialization, reverse Xmas order > - remove useless varibles > - check vops for null > - other small fixes for err path > - remove pm_runtime_set_active > - fix the active and inactive reset-gpios logic > - fix rpm_lvl and spm_lvl to 5 and move to end of probe path > - remove unnecessary system PM callbacks > - use UFSHCI_QUIRK_DME_RESET_ENABLE_AFTER_HCE instead > of UFSHCI_QUIRK_BROKEN_HCE > > Changes in v2: > - rename the file > - add reset-gpios > > Shawn Lin (6): > dt-bindings: ufs: Document Rockchip UFS host controller > soc: rockchip: add header for suspend mode SIP interface > pmdomain: rockchip: Add smc call to inform firmware > scsi: ufs: core: Export ufshcd_dme_reset() and ufshcd_dme_enable() > scsi: ufs: rockchip: initial support for UFS > arm64: dts: rockchip: Add UFS support for RK3576 SoC > > Ulf Hansson (1): > pmdomain: core: Introduce dev_pm_genpd_rpm_always_on() > > .../bindings/ufs/rockchip,rk3576-ufshc.yaml | 105 ++++++ > arch/arm64/boot/dts/rockchip/rk3576.dtsi | 24 ++ > drivers/pmdomain/core.c | 35 ++ > drivers/pmdomain/rockchip/pm-domains.c | 8 + > drivers/ufs/core/ufshcd.c | 6 +- > drivers/ufs/host/Kconfig | 12 + > drivers/ufs/host/Makefile | 1 + > drivers/ufs/host/ufs-rockchip.c | 353 +++++++++++++++++++++ > drivers/ufs/host/ufs-rockchip.h | 90 ++++++ > include/linux/pm_domain.h | 7 + > include/soc/rockchip/rockchip_sip.h | 3 + > include/ufs/ufshcd.h | 2 + > 12 files changed, 644 insertions(+), 2 deletions(-) > create mode 100644 Documentation/devicetree/bindings/ufs/rockchip,rk3576-ufshc.yaml > create mode 100644 drivers/ufs/host/ufs-rockchip.c > create mode 100644 drivers/ufs/host/ufs-rockchip.h > > -- > 2.7.4 >
Hi Ulf, 在 2025/2/7 18:17, Ulf Hansson 写道: > On Wed, 5 Feb 2025 at 07:16, Shawn Lin <shawn.lin@rock-chips.com> wrote: >> >> This patchset adds initial UFS controller supprt for RK3576 SoC. >> Patch 1 is the dt-bindings. Patch 2-4 deal with rpm and spm support >> in advanced suggested by Ulf. Patch 5 exports two new APIs for host >> driver. Patch 6 and 7 are the host driver and dtsi support. > > Looks like this series is almost ready to be merged? > > If so, may I suggest that I pick patch2, patch3 and patch4 via my > pmdomain tree and share them via an immutable branch, so they can be > pulled into James/Martin's scsi tree? Or do you prefer another route? > Thanks for the review. I'm fine with both. Let's wait for James/Martin's opinion. > Kind regards > Uffe > >> >> >> Changes in v7: >> - add definitions for all kinds of hex values if possible >> - Misc log and comment improvement >> - use udelay for less than 10us cases >> - other improvements suggested by Mani >> - Use 0x0 for consistency >> - Collect Mani's acked-by tag >> >> Changes in v6: >> - fix indentation to 4 spaces suggested by Krzysztof >> - export dev_pm_genpd_rpm_always_on() >> - replace host drivers with glue drivers suggested by Mani >> - add Main's review tag >> - remove UFS_MAX_CLKS >> - improve err log >> - remove hardcoded clocks >> - remove comment from ufs_rockchip_device_reset() >> - remove pm_runtime_* from ufs_rockchip_remove() >> - rebase to scsi/next >> - move ufs_rockchip_set_pm_lvl to ufs_rockchip_rk3576_init() >> - add comments about device_set_awake_path() >> - remove comments suggested by Mani >> >> Changes in v5: >> - use ufshc for devicetree example suggested by Mani >> - fix a compile warning >> - use device_set_awake_path() and disable ref_out_clk in suspend >> - remove pd_id from header >> - reconstruct ufs_rockchip_hce_enable_notify() to workaround hce enable >> without using new quirk >> >> Changes in v4: >> - properly describe reset-gpios >> - deal with power domain of rpm and spm suggested by Ulf >> - Fix typo and disable clks in ufs_rockchip_remove >> - remove clk_disable_unprepare(host->ref_out_clk) from >> ufs_rockchip_remove >> >> Changes in v3: >> - rename the file to rockchip,rk3576-ufshc.yaml >> - add description for reset-gpios >> - use rockchip,rk3576-ufshc as compatible >> - reword Kconfig description >> - elaborate more about controller in commit msg >> - use rockchip,rk3576-ufshc for compatible >> - remove useless header file >> - remove inline for ufshcd_is_device_present >> - use usleep_range instead >> - remove initialization, reverse Xmas order >> - remove useless varibles >> - check vops for null >> - other small fixes for err path >> - remove pm_runtime_set_active >> - fix the active and inactive reset-gpios logic >> - fix rpm_lvl and spm_lvl to 5 and move to end of probe path >> - remove unnecessary system PM callbacks >> - use UFSHCI_QUIRK_DME_RESET_ENABLE_AFTER_HCE instead >> of UFSHCI_QUIRK_BROKEN_HCE >> >> Changes in v2: >> - rename the file >> - add reset-gpios >> >> Shawn Lin (6): >> dt-bindings: ufs: Document Rockchip UFS host controller >> soc: rockchip: add header for suspend mode SIP interface >> pmdomain: rockchip: Add smc call to inform firmware >> scsi: ufs: core: Export ufshcd_dme_reset() and ufshcd_dme_enable() >> scsi: ufs: rockchip: initial support for UFS >> arm64: dts: rockchip: Add UFS support for RK3576 SoC >> >> Ulf Hansson (1): >> pmdomain: core: Introduce dev_pm_genpd_rpm_always_on() >> >> .../bindings/ufs/rockchip,rk3576-ufshc.yaml | 105 ++++++ >> arch/arm64/boot/dts/rockchip/rk3576.dtsi | 24 ++ >> drivers/pmdomain/core.c | 35 ++ >> drivers/pmdomain/rockchip/pm-domains.c | 8 + >> drivers/ufs/core/ufshcd.c | 6 +- >> drivers/ufs/host/Kconfig | 12 + >> drivers/ufs/host/Makefile | 1 + >> drivers/ufs/host/ufs-rockchip.c | 353 +++++++++++++++++++++ >> drivers/ufs/host/ufs-rockchip.h | 90 ++++++ >> include/linux/pm_domain.h | 7 + >> include/soc/rockchip/rockchip_sip.h | 3 + >> include/ufs/ufshcd.h | 2 + >> 12 files changed, 644 insertions(+), 2 deletions(-) >> create mode 100644 Documentation/devicetree/bindings/ufs/rockchip,rk3576-ufshc.yaml >> create mode 100644 drivers/ufs/host/ufs-rockchip.c >> create mode 100644 drivers/ufs/host/ufs-rockchip.h >> >> -- >> 2.7.4 >> >
Ulf, > If so, may I suggest that I pick patch2, patch3 and patch4 via my > pmdomain tree and share them via an immutable branch, so they can be > pulled into James/Martin's scsi tree? Sure, that's fine with me.
On Wed, 12 Feb 2025 at 22:56, Martin K. Petersen <martin.petersen@oracle.com> wrote: > > > Ulf, > > > If so, may I suggest that I pick patch2, patch3 and patch4 via my > > pmdomain tree and share them via an immutable branch, so they can be > > pulled into James/Martin's scsi tree? > > Sure, that's fine with me. Okay, great! I have picked up the patches and pushed them to the below immutable branch, which is based upon rc2. git.kernel.org/pub/scm/linux/kernel/git/ulfh/linux-pm.git rockchip Kind regards Uffe
Am Montag, 17. Februar 2025, 18:10:32 MEZ schrieb Steven Price: > On 17/02/2025 15:16, Heiko Stübner wrote: > > Hi Steven, > > > > Am Montag, 17. Februar 2025, 15:47:21 MEZ schrieb Steven Price: > >> On 05/02/2025 06:15, Shawn Lin wrote: > >>> Inform firmware to keep the power domain on or off. > >>> > >>> Suggested-by: Ulf Hansson <ulf.hansson@linaro.org> > >>> Signed-off-by: Shawn Lin <shawn.lin@rock-chips.com> > >>> --- > >> > >> This patch is causing my Firefly RK3288 to fail to boot, it hangs > >> shortly after reaching user space, but the bootup messages include the > >> suspicious line "Bad mode in prefetch abort handler detected". > >> I suspect the firmware on this board doesn't support this new SMC > >> correctly. Reverting this patch on top of linux-next gets everything > >> working again. > > > > Is your board actually running some trusted firmware? > > Not as far as I know. > > > Stock rk3288 never had tf-a / psci [0], I did work on that for a while, > > but don't think that ever took off. > > > > I'm wondering who the smcc call is calling, but don't know about > > about smcc stuff. > > Good question - it's quite possible things are blowing up just because > there's nothing there to handle the SMC. My DTB is as upstream: > > cpus { > #address-cells = <0x01>; > #size-cells = <0x00>; > enable-method = "rockchip,rk3066-smp"; > rockchip,pmu = <0x06>; > > I haven't investigated why this code is attempting to call an SMC on > this board. I guess the why is easy, something to do with suspend :-) . I did go testing a bit, booting a rk3288-veyron produces the same issue you saw, likely due to the non-existent trusted-firmware. On the arm64-side, I tried a plethora of socs + tfa-versions, rk3328: v2.5 upstream(?)-tf-a rk3399: v2.9 upstream-tf-a px30: v2.4+v2.9 upstream-tf-a rk3568: v2.3 vendor-tf-a rk3588: v2.3 vendor-tf-a and all ran just fine. So it really looks like the smcc call going to some unset location is the culprit. Looking at other users of arm_smcc_smc, most of them seem to be handled unguarded, but some older(?) arm32 boards actually check their DTs for an optee node before trying their smc-call. I guess in the pm-domain case, we could just wrap the call with: if(arm_smccc_1_1_get_conduit() != SMCCC_CONDUIT_NONE) I've checked in my boards now, and all the boards mentioned above seem to handle this well with smccc-versions of at least 0x10002 . Heiko
On Tue, 18 Feb 2025 at 01:53, Shawn Lin <shawn.lin@rock-chips.com> wrote: > > Hi Heiko, Steven > > 在 2025/2/18 4:50, Heiko Stübner 写道: > > Am Montag, 17. Februar 2025, 18:10:32 MEZ schrieb Steven Price: > >> On 17/02/2025 15:16, Heiko Stübner wrote: > >>> Hi Steven, > >>> > >>> Am Montag, 17. Februar 2025, 15:47:21 MEZ schrieb Steven Price: > >>>> On 05/02/2025 06:15, Shawn Lin wrote: > >>>>> Inform firmware to keep the power domain on or off. > >>>>> > >>>>> Suggested-by: Ulf Hansson <ulf.hansson@linaro.org> > >>>>> Signed-off-by: Shawn Lin <shawn.lin@rock-chips.com> > >>>>> --- > >>>> > >>>> This patch is causing my Firefly RK3288 to fail to boot, it hangs > >>>> shortly after reaching user space, but the bootup messages include the > >>>> suspicious line "Bad mode in prefetch abort handler detected". > >>>> I suspect the firmware on this board doesn't support this new SMC > >>>> correctly. Reverting this patch on top of linux-next gets everything > >>>> working again. > >>> > >>> Is your board actually running some trusted firmware? > >> > >> Not as far as I know. > >> > >>> Stock rk3288 never had tf-a / psci [0], I did work on that for a while, > >>> but don't think that ever took off. > >>> > >>> I'm wondering who the smcc call is calling, but don't know about > >>> about smcc stuff. > >> > >> Good question - it's quite possible things are blowing up just because > >> there's nothing there to handle the SMC. My DTB is as upstream: > >> > >> cpus { > >> #address-cells = <0x01>; > >> #size-cells = <0x00>; > >> enable-method = "rockchip,rk3066-smp"; > >> rockchip,pmu = <0x06>; > >> > >> I haven't investigated why this code is attempting to call an SMC on > >> this board. > > > > I guess the why is easy, something to do with suspend :-) . > > > > I did go testing a bit, booting a rk3288-veyron produces the same issue > > you saw, likely due to the non-existent trusted-firmware. > > > > On the arm64-side, I tried a plethora of socs + tfa-versions, > > > > rk3328: v2.5 upstream(?)-tf-a > > rk3399: v2.9 upstream-tf-a > > px30: v2.4+v2.9 upstream-tf-a > > rk3568: v2.3 vendor-tf-a > > rk3588: v2.3 vendor-tf-a > > > > and all ran just fine. > > So it really looks like the smcc call going to some unset location is > > the culprit. > > > > Looking at other users of arm_smcc_smc, most of them seem to be handled > > unguarded, but some older(?) arm32 boards actually check their DTs for an > > optee node before trying their smc-call. > > > > I guess in the pm-domain case, we could just wrap the call with: > > if(arm_smccc_1_1_get_conduit() != SMCCC_CONDUIT_NONE) > > > > Thanks for the report and helping find out the cause! > > @Ulf, if the solution above seems reasonable to you, I can cook a fix-up > patch. Seems reasonable to me, thanks! [...] Kind regards Uffe
在 2025/2/18 19:05, Ulf Hansson 写道: > On Tue, 18 Feb 2025 at 01:53, Shawn Lin <shawn.lin@rock-chips.com> wrote: >> >> Hi Heiko, Steven >> >> 在 2025/2/18 4:50, Heiko Stübner 写道: >>> Am Montag, 17. Februar 2025, 18:10:32 MEZ schrieb Steven Price: >>>> On 17/02/2025 15:16, Heiko Stübner wrote: >>>>> Hi Steven, >>>>> >>>>> Am Montag, 17. Februar 2025, 15:47:21 MEZ schrieb Steven Price: >>>>>> On 05/02/2025 06:15, Shawn Lin wrote: >>>>>>> Inform firmware to keep the power domain on or off. >>>>>>> >>>>>>> Suggested-by: Ulf Hansson <ulf.hansson@linaro.org> >>>>>>> Signed-off-by: Shawn Lin <shawn.lin@rock-chips.com> >>>>>>> --- >>>>>> >>>>>> This patch is causing my Firefly RK3288 to fail to boot, it hangs >>>>>> shortly after reaching user space, but the bootup messages include the >>>>>> suspicious line "Bad mode in prefetch abort handler detected". >>>>>> I suspect the firmware on this board doesn't support this new SMC >>>>>> correctly. Reverting this patch on top of linux-next gets everything >>>>>> working again. >>>>> >>>>> Is your board actually running some trusted firmware? >>>> >>>> Not as far as I know. >>>> >>>>> Stock rk3288 never had tf-a / psci [0], I did work on that for a while, >>>>> but don't think that ever took off. >>>>> >>>>> I'm wondering who the smcc call is calling, but don't know about >>>>> about smcc stuff. >>>> >>>> Good question - it's quite possible things are blowing up just because >>>> there's nothing there to handle the SMC. My DTB is as upstream: >>>> >>>> cpus { >>>> #address-cells = <0x01>; >>>> #size-cells = <0x00>; >>>> enable-method = "rockchip,rk3066-smp"; >>>> rockchip,pmu = <0x06>; >>>> >>>> I haven't investigated why this code is attempting to call an SMC on >>>> this board. >>> >>> I guess the why is easy, something to do with suspend :-) . >>> >>> I did go testing a bit, booting a rk3288-veyron produces the same issue >>> you saw, likely due to the non-existent trusted-firmware. >>> >>> On the arm64-side, I tried a plethora of socs + tfa-versions, >>> >>> rk3328: v2.5 upstream(?)-tf-a >>> rk3399: v2.9 upstream-tf-a >>> px30: v2.4+v2.9 upstream-tf-a >>> rk3568: v2.3 vendor-tf-a >>> rk3588: v2.3 vendor-tf-a >>> >>> and all ran just fine. >>> So it really looks like the smcc call going to some unset location is >>> the culprit. >>> >>> Looking at other users of arm_smcc_smc, most of them seem to be handled >>> unguarded, but some older(?) arm32 boards actually check their DTs for an >>> optee node before trying their smc-call. >>> >>> I guess in the pm-domain case, we could just wrap the call with: >>> if(arm_smccc_1_1_get_conduit() != SMCCC_CONDUIT_NONE) >>> >> >> Thanks for the report and helping find out the cause! >> >> @Ulf, if the solution above seems reasonable to you, I can cook a fix-up >> patch. > > Seems reasonable to me, thanks! Thanks Ulf, I have sent a individual fix-up patch. > > [...] > > Kind regards > Uffe >
On Thu, 13 Feb 2025 at 16:20, Ulf Hansson <ulf.hansson@linaro.org> wrote: > > On Wed, 12 Feb 2025 at 22:56, Martin K. Petersen > <martin.petersen@oracle.com> wrote: > > > > > > Ulf, > > > > > If so, may I suggest that I pick patch2, patch3 and patch4 via my > > > pmdomain tree and share them via an immutable branch, so they can be > > > pulled into James/Martin's scsi tree? > > > > Sure, that's fine with me. > > Okay, great! I have picked up the patches and pushed them to the below > immutable branch, which is based upon rc2. > > git.kernel.org/pub/scm/linux/kernel/git/ulfh/linux-pm.git rockchip Hi Martin, We got a report about an issue in the branch above a couple of days ago. The problem has been fixed and I have just published it to the branch above. If you already pulled-in the branch to your tree, please pull again to get the fix too. Kind regards Uffe
Ulf, > We got a report about an issue in the branch above a couple of days > ago. The problem has been fixed and I have just published it to the > branch above. > > If you already pulled-in the branch to your tree, please pull again to > get the fix too. I already pulled and have this sitting in a dedicated rockchip branch. However, I ran into several build errors in ufs-rockchip.c with gcc 14. So I haven't actually put any of this in my main tree yet. I will rebase on top of the new branch. Thanks!
On Wed, 05 Feb 2025 14:15:49 +0800, Shawn Lin wrote: > This patchset adds initial UFS controller supprt for RK3576 SoC. > Patch 1 is the dt-bindings. Patch 2-4 deal with rpm and spm support > in advanced suggested by Ulf. Patch 5 exports two new APIs for host > driver. Patch 6 and 7 are the host driver and dtsi support. > > > Changes in v7: > - add definitions for all kinds of hex values if possible > - Misc log and comment improvement > - use udelay for less than 10us cases > - other improvements suggested by Mani > - Use 0x0 for consistency > - Collect Mani's acked-by tag > > [...] Applied to 6.15/scsi-queue, thanks! [1/7] dt-bindings: ufs: Document Rockchip UFS host controller https://git.kernel.org/mkp/scsi/c/d90e92023771 [5/7] scsi: ufs: core: Export ufshcd_dme_reset() and ufshcd_dme_enable() https://git.kernel.org/mkp/scsi/c/6b070711b702 [6/7] scsi: ufs: rockchip: initial support for UFS https://git.kernel.org/mkp/scsi/c/d3cbe455d6eb [7/7] arm64: dts: rockchip: Add UFS support for RK3576 SoC https://git.kernel.org/mkp/scsi/c/c75e5e010fef