* [PATCH] ARM: multi_v7_defconfig: Select CONFIG_USB_ONBOARD_DEV as built-in
From: Fabio Estevam @ 2024-04-08 14:02 UTC (permalink / raw)
To: arnd; +Cc: broonie, javier.carrasco, linux-arm-kernel, Fabio Estevam
From: Fabio Estevam <festevam@denx.de>
Selecting CONFIG_USB_ONBOARD_DEV as a module may cause the following
run-time error when probing a USB2514 hub on a imx6q-udoo board:
usb 1-1: device not accepting address 5, error -71
usb usb1-port1: unable to enumerate USB device
Fix this issue by selecting CONFIG_USB_ONBOARD_DEV as built-in so
that the USB hub reset line and clock can be activated earlier.
Signed-off-by: Fabio Estevam <festevam@denx.de>
---
Here is the imx6q-udoo boot log from Mark's farm that shows the problem:
https://storage.kernelci.org/next/master/next-20240408/arm/multi_v7_defconfig/gcc-10/lab-broonie/baseline-imx6dl-udoo.html
arch/arm/configs/multi_v7_defconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/configs/multi_v7_defconfig b/arch/arm/configs/multi_v7_defconfig
index 86bf057ac366..1cc5f2c1a0c6 100644
--- a/arch/arm/configs/multi_v7_defconfig
+++ b/arch/arm/configs/multi_v7_defconfig
@@ -885,7 +885,7 @@ CONFIG_USB_CHIPIDEA_UDC=y
CONFIG_USB_CHIPIDEA_HOST=y
CONFIG_USB_ISP1760=y
CONFIG_USB_HSIC_USB3503=y
-CONFIG_USB_ONBOARD_DEV=m
+CONFIG_USB_ONBOARD_DEV=y
CONFIG_AB8500_USB=y
CONFIG_KEYSTONE_USB_PHY=m
CONFIG_NOP_USB_XCEIV=y
--
2.34.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: [PATCH] dt-bindings: net: rockchip-dwmac: use rgmii-id in example
From: Andrew Lunn @ 2024-04-08 14:02 UTC (permalink / raw)
To: Sascha Hauer
Cc: David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Heiko Stuebner,
David Wu, netdev, devicetree, linux-arm-kernel, linux-rockchip,
linux-kernel
In-Reply-To: <20240408-rockchip-dwmac-rgmii-id-binding-v1-1-3886d1a8bd54@pengutronix.de>
On Mon, Apr 08, 2024 at 08:44:10AM +0200, Sascha Hauer wrote:
> The dwmac supports specifying the RGMII clock delays, but it is
> recommended to use rgmii-id and to specify the delays in the phy node
> instead [1].
>
> Change the example accordingly to no longer promote this undesired
> setting.
>
> [1] https://lore.kernel.org/all/1a0de7b4-f0f7-4080-ae48-f5ffa9e76be3@lunn.ch/
>
> Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Andrew
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v5 0/4] Update Energy Model after chip binning adjusted voltages
From: Rafael J. Wysocki @ 2024-04-08 14:06 UTC (permalink / raw)
To: Lukasz Luba
Cc: linux-kernel, linux-pm, rafael, dietmar.eggemann,
linux-arm-kernel, sboyd, nm, linux-samsung-soc, daniel.lezcano,
viresh.kumar, krzysztof.kozlowski, alim.akhtar, m.szyprowski,
mhiramat
In-Reply-To: <20240403154907.1420245-1-lukasz.luba@arm.com>
On Wed, Apr 3, 2024 at 5:49 PM Lukasz Luba <lukasz.luba@arm.com> wrote:
>
> Hi all,
>
> This is a follow-up patch aiming to add EM modification due to chip binning.
> The first RFC and the discussion can be found here [1].
>
> It uses Exynos chip driver code as a 1st user. The EM framework has been
> extended to handle this use case easily, when the voltage has been changed
> after setup. On my Odroid-xu4 in some OPPs I can observe ~20% power difference.
> According to that data in driver tables it could be up to ~29%.
>
> This chip binning is applicable to a lot of SoCs, so the EM framework should
> make it easy to update. It uses the existing OPP and DT information to
> re-calculate the new power values.
>
> It has dependency on Exynos SoC driver tree.
>
> Changes:
> v5:
> - adjusted aligning of the function arguments in patch 1/4 (Dietmar)
> - adjusted the in-code comment patch 4/4 (Dietmar)
> - added Reviewed-by to all patches (Dietmar)
> v4:
> - added asterisk in the comment section (test robot)
> - change the patch 2/4 header name and use 'Refactor'
> v3:
> - updated header description patch 2/4 (Dietmar)
> - removed 2 sentences from comment and adjusted in patch 3/4 (Dietmar)
> - patch 4/4 re-phrased code comment (Dietmar)
> - collected tags (Krzysztof, Viresh)
> v2:
> - removed 'ret' from error message which wasn't initialized (Christian)
> v1:
> - exported the OPP calculation function from the OPP/OF so it can be
> used from EM fwk (Viresh)
> - refactored EM updating function to re-use common code
> - added new EM function which can be used by chip device drivers which
> modify the voltage in OPPs
> RFC is at [1]
>
> Regards,
> Lukasz Luba
>
> [1] https://lore.kernel.org/lkml/20231220110339.1065505-1-lukasz.luba@arm.com/
>
> Lukasz Luba (4):
> OPP: OF: Export dev_opp_pm_calc_power() for usage from EM
> PM: EM: Refactor em_adjust_new_capacity()
> PM: EM: Add em_dev_update_chip_binning()
> soc: samsung: exynos-asv: Update Energy Model after adjusting voltage
>
> drivers/opp/of.c | 17 +++--
> drivers/soc/samsung/exynos-asv.c | 10 ++-
> include/linux/energy_model.h | 5 ++
> include/linux/pm_opp.h | 8 +++
> kernel/power/energy_model.c | 106 +++++++++++++++++++++++++------
> 5 files changed, 121 insertions(+), 25 deletions(-)
>
> --
All patches in the series applied as 6.10 material, thanks!
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH v3] ARM: imx_v6_v7_defconfig: Update ONBOARD_USB_HUB to ONBOAD_USB_DEV
From: Fabio Estevam @ 2024-04-08 14:09 UTC (permalink / raw)
To: shawnguo; +Cc: broonie, javier.carrasco, linux-arm-kernel, Fabio Estevam
From: Fabio Estevam <festevam@denx.de>
The onboard_usb_hub driver has been updated to support non-hub devices,
which has led to some renaming.
Update to the new name (ONBOARD_USB_DEV) accordingly.
Based on similar fixes done by Javier Carrasco for other defconfigs.
Fixes: 0bb36055c049 ("ARM: imx_v6_v7_defconfig: Select CONFIG_USB_ONBOARD_HUB")
Signed-off-by: Fabio Estevam <festevam@denx.de>
---
Changes since v2:
- Adjust the Fixes tag. (Javier)
arch/arm/configs/imx_v6_v7_defconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/configs/imx_v6_v7_defconfig b/arch/arm/configs/imx_v6_v7_defconfig
index b06128da94e5..cf2480dce285 100644
--- a/arch/arm/configs/imx_v6_v7_defconfig
+++ b/arch/arm/configs/imx_v6_v7_defconfig
@@ -336,7 +336,7 @@ CONFIG_USB_SERIAL_FTDI_SIO=m
CONFIG_USB_SERIAL_OPTION=m
CONFIG_USB_TEST=m
CONFIG_USB_EHSET_TEST_FIXTURE=m
-CONFIG_USB_ONBOARD_HUB=y
+CONFIG_USB_ONBOARD_DEV=y
CONFIG_NOP_USB_XCEIV=y
CONFIG_USB_MXS_PHY=y
CONFIG_USB_GADGET=y
--
2.34.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: [PATCH] dt-bindings: net: rockchip-dwmac: use rgmii-id in example
From: Dragan Simic @ 2024-04-08 14:13 UTC (permalink / raw)
To: Sascha Hauer
Cc: David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Heiko Stuebner,
David Wu, netdev, devicetree, linux-arm-kernel, linux-rockchip,
linux-kernel, Andrew Lunn
In-Reply-To: <20240408-rockchip-dwmac-rgmii-id-binding-v1-1-3886d1a8bd54@pengutronix.de>
Hello Sascha,
On 2024-04-08 08:44, Sascha Hauer wrote:
> The dwmac supports specifying the RGMII clock delays, but it is
> recommended to use rgmii-id and to specify the delays in the phy node
> instead [1].
>
> Change the example accordingly to no longer promote this undesired
> setting.
>
> [1]
> https://lore.kernel.org/all/1a0de7b4-f0f7-4080-ae48-f5ffa9e76be3@lunn.ch/
>
> Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
I'd suggest that the following link is also added to the patch
description as a reference, because it contains rather useful
information:
https://lore.kernel.org/linux-rockchip/2973a2cb1f478031ae6d478c853c33ae@manjaro.org/
Otherwise,
Reviewed-by: Dragan Simic <dsimic@manjaro.org>
> ---
> Documentation/devicetree/bindings/net/rockchip-dwmac.yaml | 4 +---
> 1 file changed, 1 insertion(+), 3 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/net/rockchip-dwmac.yaml
> b/Documentation/devicetree/bindings/net/rockchip-dwmac.yaml
> index 70bbc4220e2ac..6bbe96e352509 100644
> --- a/Documentation/devicetree/bindings/net/rockchip-dwmac.yaml
> +++ b/Documentation/devicetree/bindings/net/rockchip-dwmac.yaml
> @@ -137,8 +137,6 @@ examples:
> assigned-clock-parents = <&ext_gmac>;
>
> rockchip,grf = <&grf>;
> - phy-mode = "rgmii";
> + phy-mode = "rgmii-id";
> clock_in_out = "input";
> - tx_delay = <0x30>;
> - rx_delay = <0x10>;
> };
>
> ---
> base-commit: 39cd87c4eb2b893354f3b850f916353f2658ae6f
> change-id: 20240408-rockchip-dwmac-rgmii-id-binding-6166af659845
>
> Best regards,
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v2 0/2] Add missing mmc statistics in DW GMAC
From: patchwork-bot+netdevbpf @ 2024-04-08 14:30 UTC (permalink / raw)
To: Minda Chen
Cc: alexandre.torgue, joabreu, davem, edumazet, kuba, pabeni,
mcoquelin.stm32, netdev, linux-stm32, linux-arm-kernel,
linux-kernel
In-Reply-To: <20240408012943.66508-1-minda.chen@starfivetech.com>
Hello:
This series was applied to netdev/net.git (main)
by David S. Miller <davem@davemloft.net>:
On Mon, 8 Apr 2024 09:29:41 +0800 you wrote:
> Add miss MMC statistic in DW GMAC
>
> base on 6.9-rc1
>
> changed
> v2:
> patch2 : remove mmc_rx_control_g due to it is gotten in
> ethtool_ops::get_eth_ctrl_stats.
>
> [...]
Here is the summary with links:
- [v2,1/2] net: stmmac: mmc_core: Add GMAC LPI statistics
https://git.kernel.org/netdev/net/c/dfe073f8714d
- [v2,2/2] net: stmmac: mmc_core: Add GMAC mmc tx/rx missing statistics
https://git.kernel.org/netdev/net/c/ff20393bdc45
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH net-next v11 00/13] Introduce PHY listing and link_topology tracking
From: Maxime Chevallier @ 2024-04-08 14:32 UTC (permalink / raw)
To: patchwork-bot+netdevbpf
Cc: davem, netdev, linux-kernel, thomas.petazzoni, andrew, kuba,
edumazet, pabeni, linux, linux-arm-kernel, christophe.leroy,
herve.codina, f.fainelli, hkallweit1, vladimir.oltean,
kory.maincent, jesse.brandeburg, corbet, kabel,
piergiorgio.beruto, o.rempel, nicveronese, horms, mwojtas
In-Reply-To: <171242462917.4000.9759453824684907063.git-patchwork-notify@kernel.org>
Hi,
On Sat, 06 Apr 2024 17:30:29 +0000
patchwork-bot+netdevbpf@kernel.org wrote:
> Hello:
>
> This series was applied to netdev/net-next.git (main)
> by David S. Miller <davem@davemloft.net>:
>
> On Thu, 4 Apr 2024 11:29:50 +0200 you wrote:
> > Hello everyone,
> >
> > This is V11 for the link topology addition, allowing to track all PHYs
> > that are linked to netdevices.
> >
> > This V11 addresses the various netlink-related issues that were raised
> > by Jakub, and fixes some typos in the documentation.
> >
> > [...]
>
> Here is the summary with links:
> - [net-next,v11,01/13] net: phy: Introduce ethernet link topology representation
> https://git.kernel.org/netdev/net-next/c/6916e461e793
> - [net-next,v11,02/13] net: sfp: pass the phy_device when disconnecting an sfp module's PHY
> https://git.kernel.org/netdev/net-next/c/0ec5ed6c130e
> - [net-next,v11,03/13] net: phy: add helpers to handle sfp phy connect/disconnect
> https://git.kernel.org/netdev/net-next/c/e75e4e074c44
> - [net-next,v11,04/13] net: sfp: Add helper to return the SFP bus name
> https://git.kernel.org/netdev/net-next/c/fdd353965b52
> - [net-next,v11,05/13] net: ethtool: Allow passing a phy index for some commands
> https://git.kernel.org/netdev/net-next/c/841942bc6212
> - [net-next,v11,06/13] netlink: specs: add phy-index as a header parameter
> (no matching commit)
> - [net-next,v11,07/13] net: ethtool: Introduce a command to list PHYs on an interface
> (no matching commit)
> - [net-next,v11,08/13] netlink: specs: add ethnl PHY_GET command set
> (no matching commit)
> - [net-next,v11,09/13] net: ethtool: plca: Target the command to the requested PHY
> (no matching commit)
> - [net-next,v11,10/13] net: ethtool: pse-pd: Target the command to the requested PHY
> (no matching commit)
> - [net-next,v11,11/13] net: ethtool: cable-test: Target the command to the requested PHY
> (no matching commit)
> - [net-next,v11,12/13] net: ethtool: strset: Allow querying phy stats by index
> (no matching commit)
> - [net-next,v11,13/13] Documentation: networking: document phy_link_topology
> (no matching commit)
It looks like commits 6 to 13 didn't make it upstream with (the "no
matching commit" messages above). Is that expected ?
Thanks,
Maxime
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 1/1] arm64: dts: rockchip: enable onboard spi flash for rock-3a
From: Jonas Karlman @ 2024-04-08 14:44 UTC (permalink / raw)
To: Chukun Pan, Heiko Stuebner
Cc: Conor Dooley, Krzysztof Kozlowski, Rob Herring, linux-arm-kernel,
linux-rockchip, linux-kernel, devicetree
In-Reply-To: <20240408124005.182565-1-amadeus@jmu.edu.cn>
Hi Chukun,
On 2024-04-08 14:40, Chukun Pan wrote:
> There is a mx25u12835f spi flash on this board, enable it.
>
> [ 2.525805] spi-nor spi4.0: mx25u12835f (16384 Kbytes)
>
> Signed-off-by: Chukun Pan <amadeus@jmu.edu.cn>
> ---
> arch/arm64/boot/dts/rockchip/rk3568-rock-3a.dts | 12 ++++++++++++
> 1 file changed, 12 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/rockchip/rk3568-rock-3a.dts b/arch/arm64/boot/dts/rockchip/rk3568-rock-3a.dts
> index a5e974ea659e..d8738cc47c73 100644
> --- a/arch/arm64/boot/dts/rockchip/rk3568-rock-3a.dts
> +++ b/arch/arm64/boot/dts/rockchip/rk3568-rock-3a.dts
> @@ -757,6 +757,18 @@ &sdmmc2 {
> status = "okay";
> };
>
> +&sfc {
This is missing:
#address-cells = <1>;
#size-cells = <0>;
> + status = "okay";
> +
> + flash@0 {
> + compatible = "jedec,spi-nor";
> + reg = <0x0>;
> + spi-max-frequency = <50000000>;
At least in U-Boot the spi clock only support 24, 100 or 200 mhz and I
am pretty sure the spi flash support 100mhz, so I would suggest you test
with 100mhz, same as used on other rk356x boards.
For U-Boot I have used 24 mhz for rk356x boards not defining a flash@0
node in linux device tree, such as the rock-3a board.
Regards,
Jonas
> + spi-rx-bus-width = <4>;
> + spi-tx-bus-width = <1>;
> + };
> +};
> +
> &tsadc {
> rockchip,hw-tshut-mode = <1>;
> rockchip,hw-tshut-polarity = <0>;
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 08/17] clk: samsung: gs101: add support for cmu_hsi2
From: André Draszik @ 2024-04-08 14:49 UTC (permalink / raw)
To: Peter Griffin, mturquette, sboyd, robh, krzk+dt, conor+dt, vkoul,
kishon, alim.akhtar, avri.altman, bvanassche, s.nawrocki,
cw00.choi, jejb, martin.petersen, chanho61.park, ebiggers
Cc: linux-scsi, linux-phy, devicetree, linux-clk, linux-samsung-soc,
linux-kernel, linux-arm-kernel, tudor.ambarus, saravanak,
willmcvicker
In-Reply-To: <20240404122559.898930-9-peter.griffin@linaro.org>
Hi Pete,
On Thu, 2024-04-04 at 13:25 +0100, Peter Griffin wrote:
> CMU_HSI2 is the clock management unit used for the hsi2 block.
> HSI stands for High Speed Interface and as such it generates
> clocks for PCIe, UFS and MMC card.
>
> This patch adds support for the muxes, dividers, and gates in
> cmu_hsi2.
>
> CLK_GOUT_HSI2_HSI2_CMU_HSI2_PCLK is marked as CLK_IS_CRITICAL
> as disabling it leads to an immediate system hang.
>
> CLK_GOUT_HSI2_SYSREG_HSI2_PCLK is also marked CLK_IS_CRITICAL.
> A hang is not observed with fine grained clock control, but
> UFS IP does not function with syscon controlling this clock
> just around hsi2_sysreg register accesses.
Would it make sense to add this clock to the &ufs_0 node in the DTS
instead? Seems more natural than a clock that's constantly enabled?
> [...]
>
> Updated regex for clock name mangling
> sed \
> -e 's|^PLL_LOCKTIME_PLL_\([^_]\+\)|fout_\L\1_pll|' \
> \
> -e 's|^PLL_CON0_MUX_CLKCMU_\([^_]\+\)_\(.*\)|mout_\L\1_\2|' \
> -e 's|^PLL_CON0_PLL_\(.*\)|mout_pll_\L\1|' \
> -e 's|^CLK_CON_MUX_MUX_CLK_\(.*\)|mout_\L\1|' \
> -e '/^PLL_CON[1-4]_[^_]\+_/d' \
> -e '/^[^_]\+_CMU_[^_]\+_CONTROLLER_OPTION/d' \
> -e '/^CLKOUT_CON_BLK_[^_]\+_CMU_[^_]\+_CLKOUT0/d' \
> \
> -e 's|_IPCLKPORT||' \
> -e 's|_RSTNSYNC||' \
> -e 's|_G4X2_DWC_PCIE_CTL||' \
> -e 's|_G4X1_DWC_PCIE_CTL||' \
> -e 's|_PCIE_SUB_CTRL||' \
> -e 's|_INST_0||g' \
> -e 's|_LN05LPE||' \
> -e 's|_TM_WRAPPER||' \
> -e 's|_SF||' \
> \
> -e 's|^CLK_CON_DIV_DIV_CLK_\([^_]\+\)_\(.*\)|dout_\L\1_\2|' \
> \
> -e 's|^CLK_CON_BUF_CLKBUF_\([^_]\+\)_\(.*\)|gout_\L\1_\2|' \
> -e 's|^CLK_CON_GAT_CLK_BLK_\([^_]\+\)_UID_\(.*\)|gout_\L\1_\2|' \
> -e 's|^gout_[^_]\+_[^_]\+_cmu_\([^_]\+\)_pclk$|gout_\1_\1_pclk|' \
> -e 's|^CLK_CON_GAT_GOUT_BLK_\([^_]\+\)_UID_\(.*\)|gout_\L\1_\2|' \
> -e 's|^CLK_CON_GAT_CLK_\([^_]\+\)_\(.*\)|gout_\L\1_clk_\L\1_\2|' \
> \
> -e '/^\(DMYQCH\|PCH\|QCH\|QUEUE\)_/d'
Thank you for the updated regex.
> ---
> drivers/clk/samsung/clk-gs101.c | 558 +++++++++++++++++++++++
> include/dt-bindings/clock/google,gs101.h | 63 +++
> 2 files changed, 621 insertions(+)
>
> diff --git a/drivers/clk/samsung/clk-gs101.c b/drivers/clk/samsung/clk-gs101.c
> index d065e343a85d..b9f84c7d5c22 100644
> --- a/drivers/clk/samsung/clk-gs101.c
> +++ b/drivers/clk/samsung/clk-gs101.c
> @@ -22,6 +22,7 @@
> #define CLKS_NR_MISC (CLK_GOUT_MISC_XIU_D_MISC_ACLK + 1)
> #define CLKS_NR_PERIC0 (CLK_GOUT_PERIC0_SYSREG_PERIC0_PCLK + 1)
> #define CLKS_NR_PERIC1 (CLK_GOUT_PERIC1_SYSREG_PERIC1_PCLK + 1)
> +#define CLKS_NR_HSI2 (CLK_GOUT_HSI2_XIU_P_HSI2_ACLK + 1)
>
> /* ---- CMU_TOP ------------------------------------------------------------- */
>
> @@ -3409,6 +3410,560 @@ static const struct samsung_cmu_info peric1_cmu_info __initconst = {
> .clk_name = "bus",
> };
>
> +/* ---- CMU_HSI2 ---------------------------------------------------------- */
This comment is shorter that all the other similar comments in this file.
> [...]
> +
> +PNAME(mout_hsi2_bus_user_p) = { "oscclk", "dout_cmu_hsi2_bus" };
> +PNAME(mout_hsi2_pcie_user_p) = { "oscclk", "dout_cmu_hsi2_pcie" };
> +PNAME(mout_hsi2_ufs_embd_user_p) = { "oscclk", "dout_cmu_hsi2_ufs_embd" };
> +PNAME(mout_hsi2_mmc_card_user_p) = { "oscclk", "dout_cmu_hsi2_mmc_card" };
Can you make these alphabetical, too, please, which would also match their usage
below:
> +
> +static const struct samsung_mux_clock hsi2_mux_clks[] __initconst = {
> + MUX(CLK_MOUT_HSI2_BUS_USER, "mout_hsi2_bus_user", mout_hsi2_bus_user_p,
> + PLL_CON0_MUX_CLKCMU_HSI2_BUS_USER, 4, 1),
> + MUX(CLK_MOUT_HSI2_MMC_CARD_USER, "mout_hsi2_mmc_card_user",
> + mout_hsi2_mmc_card_user_p, PLL_CON0_MUX_CLKCMU_HSI2_MMC_CARD_USER,
> + 4, 1),
> + MUX(CLK_MOUT_HSI2_PCIE_USER, "mout_hsi2_pcie_user",
> + mout_hsi2_pcie_user_p, PLL_CON0_MUX_CLKCMU_HSI2_PCIE_USER,
> + 4, 1),
> + MUX(CLK_MOUT_HSI2_UFS_EMBD_USER, "mout_hsi2_ufs_embd_user",
> + mout_hsi2_ufs_embd_user_p, PLL_CON0_MUX_CLKCMU_HSI2_UFS_EMBD_USER,
> + 4, 1),
> +};
> +
> +static const struct samsung_gate_clock hsi2_gate_clks[] __initconst = {
> +
Here and below: all these extra empty lines are not needed.
> + GATE(CLK_GOUT_HSI2_PCIE_GEN4_1_PCIE_003_PHY_REFCLK_IN,
> + "gout_hsi2_pcie_gen4_1_pcie_003_phy_refclk_in",
> + "mout_hsi2_pcie_user",
> + CLK_CON_GAT_CLK_BLK_HSI2_UID_PCIE_GEN4_1_IPCLKPORT_PCIE_003_PCIE_SUB_CTRL_INST_0_PHY_REFCLK_IN,
> + 21, 0, 0),
> +
> + GATE(CLK_GOUT_HSI2_PCIE_GEN4_1_PCIE_004_PHY_REFCLK_IN,
> + "gout_hsi2_pcie_gen4_1_pcie_004_phy_refclk_in",
> + "mout_hsi2_pcie_user",
> + CLK_CON_GAT_CLK_BLK_HSI2_UID_PCIE_GEN4_1_IPCLKPORT_PCIE_004_PCIE_SUB_CTRL_INST_0_PHY_REFCLK_IN,
> + 21, 0, 0),
> +
> + GATE(CLK_GOUT_HSI2_SSMT_PCIE_IA_GEN4A_1_ACLK,
> + "gout_hsi2_ssmt_pcie_ia_gen4a_1_aclk",
> + "mout_hsi2_bus_user",
The two strings fit on the same line.
> + CLK_CON_GAT_CLK_BLK_HSI2_UID_SSMT_PCIE_IA_GEN4A_1_IPCLKPORT_ACLK,
> + 21, 0, 0),
> +
> + GATE(CLK_GOUT_HSI2_SSMT_PCIE_IA_GEN4A_1_PCLK,
> + "gout_hsi2_ssmt_pcie_ia_gen4a_1_pclk",
> + "mout_hsi2_bus_user",
dito.
> [...]
> + /* Disabling this clock makes the system hang. Mark the clock as critical. */
> + GATE(CLK_GOUT_HSI2_HSI2_CMU_HSI2_PCLK,
> + "gout_hsi2_hsi2_cmu_hsi2_pclk", "mout_hsi2_bus_user",
> + CLK_CON_GAT_GOUT_BLK_HSI2_UID_HSI2_CMU_HSI2_IPCLKPORT_PCLK,
> + 21, CLK_IS_CRITICAL, 0),
I have a similar clock in USB, which also causes a hang if off, I wonder what we
could do better here.
Cheers,
Andre'
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v5 0/1] irqchip/gic-v3: Enable non-coherent GIC designs probing
From: Lorenzo Pieralisi @ 2024-04-08 14:54 UTC (permalink / raw)
To: linux-kernel
Cc: linux-arm-kernel, linux-acpi, acpica-devel, Mark Rutland,
Robin Murphy, Rafael J. Wysocki, Fang Xiang, Marc Zyngier,
Robert Moore
In-Reply-To: <ZeiBFBDhwlJnCUZ2@lpieralisi>
On Wed, Mar 06, 2024 at 03:43:32PM +0100, Lorenzo Pieralisi wrote:
> On Tue, Jan 23, 2024 at 12:03:31PM +0100, Lorenzo Pieralisi wrote:
> > This series is v5 of previous series:
> >
> > v4: https://lore.kernel.org/all/20231227110038.55453-1-lpieralisi@kernel.org
> > v3: https://lore.kernel.org/all/20231006125929.48591-1-lpieralisi@kernel.org
> > v2: https://lore.kernel.org/all/20230906094139.16032-1-lpieralisi@kernel.org
> > v1: https://lore.kernel.org/all/20230905104721.52199-1-lpieralisi@kernel.org
> >
> > v4 -> v5
> > - ACPICA patches merged for v6.8
> > - Refactored ACPI parsing code according to review
> > - Rebased against v6.8-rc1
>
> Hi Marc, all,
>
> this is not an urgent fix (I don't think there is any ACPI platform
> affected in the field so it is not even a fix), I am just asking please
> what should I do with it, I appreciate it is late in the cycle (and I
> know some fixes got merged in -rcX leading up to -rc7 that are
> pre-requisite for this patch to work).
Hi,
just a reminder to ask how to proceed with this patch, I know it
is not urgent, just to understand how to handle it please.
The related ACPICA changes are already merged in the mainline.
Thanks,
Lorenzo
> Thanks,
> Lorenzo
>
> > v3 -> v4:
> > - Dropped patches [1-3], already merged
> > - Added Linuxized ACPICA changes accepted upstream
> > - Rebased against v6.7-rc3
> >
> > v2 -> v3:
> > - Added ACPICA temporary changes and ACPI changes to implement
> > ECR https://bugzilla.tianocore.org/show_bug.cgi?id=4557
> > - ACPI changes are for testing purposes - subject to ECR code
> > first approval
> >
> > v1 -> v2:
> > - Updated DT bindings as per feedback
> > - Updated patch[2] to use GIC quirks infrastructure
> >
> > Original cover letter
> > ---
> > The GICv3 architecture specifications provide a means for the
> > system programmer to set the shareability and cacheability
> > attributes the GIC components (redistributors and ITSes) use
> > to drive memory transactions.
> >
> > Albeit the architecture give control over shareability/cacheability
> > memory transactions attributes (and barriers), it is allowed to
> > connect the GIC interconnect ports to non-coherent memory ports
> > on the interconnect, basically tying off shareability/cacheability
> > "wires" and de-facto making the redistributors and ITSes non-coherent
> > memory observers.
> >
> > This series aims at starting a discussion over a possible solution
> > to this problem, by adding to the GIC device tree bindings the
> > standard dma-noncoherent property. The GIC driver uses the property
> > to force the redistributors and ITSes shareability attributes to
> > non-shareable, which consequently forces the driver to use CMOs
> > on GIC memory tables.
> >
> > On ARM DT DMA is default non-coherent, so the GIC driver can't rely
> > on the generic DT dma-coherent/non-coherent property management layer
> > (of_dma_is_coherent()) which would default all GIC designs in the field
> > as non-coherent; it has to rely on ad-hoc dma-noncoherent property handling.
> >
> > When a consistent approach is agreed upon for DT an equivalent binding will
> > be put forward for ACPI based systems.
> >
> > Lorenzo Pieralisi (1):
> > irqchip/gic-v3: Enable non-coherent redistributors/ITSes ACPI probing
> >
> > drivers/acpi/processor_core.c | 15 +++++++++++++++
> > drivers/irqchip/irq-gic-v3-its.c | 4 ++++
> > drivers/irqchip/irq-gic-v3.c | 9 +++++++++
> > include/linux/acpi.h | 3 +++
> > 4 files changed, 31 insertions(+)
> >
> > --
> > 2.34.1
> >
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH] soc: mediatek: mtk-socinfo: select CONFIG_SOC_BUS
From: AngeloGioacchino Del Regno @ 2024-04-08 14:55 UTC (permalink / raw)
To: Daniel Golle, Arnd Bergmann
Cc: Matthias Brugger, William-tw Lin, Arnd Bergmann, Ulf Hansson,
linux-kernel, linux-arm-kernel, linux-mediatek
In-Reply-To: <ZhPqLGYxK3NRCSXl@makrotopia.org>
Il 08/04/24 14:59, Daniel Golle ha scritto:
> Hi,
>
> On Mon, Apr 08, 2024 at 02:55:00PM +0200, Arnd Bergmann wrote:
>> From: Arnd Bergmann <arnd@arndb.de>
>>
>> This is needed to avoid a link failure:
>>
>> ERROR: modpost: "soc_device_register" [drivers/soc/mediatek/mtk-socinfo.ko] undefined!
>> ERROR: modpost: "soc_device_unregister" [drivers/soc/mediatek/mtk-socinfo.ko] undefined!
>>
>
> I've tried to take care of this in the exact same way a long time
> ago. Don't ask me why it didn't find it's way into stable yet
>
> https://patchwork.kernel.org/project/linux-mediatek/patch/cc8f7f7da5bdccce514a320e0ae7468659cf7346.1707327680.git.daniel@makrotopia.org/
>
>
Sorry, went out of my radar for reasons.
Your commit should take precedence.
Angelo
> Cheers
>
>
> Daniel
>
>> Fixes: 423a54da3c7e ("soc: mediatek: mtk-socinfo: Add driver for getting chip information")
>> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
>> ---
>> drivers/soc/mediatek/Kconfig | 1 +
>> 1 file changed, 1 insertion(+)
>>
>> diff --git a/drivers/soc/mediatek/Kconfig b/drivers/soc/mediatek/Kconfig
>> index 50c664b65f4d..1b7afb19ccd6 100644
>> --- a/drivers/soc/mediatek/Kconfig
>> +++ b/drivers/soc/mediatek/Kconfig
>> @@ -72,6 +72,7 @@ config MTK_SOCINFO
>> tristate "MediaTek SoC Information"
>> default y
>> depends on NVMEM_MTK_EFUSE
>> + select SOC_BUS
>> help
>> The MediaTek SoC Information (mtk-socinfo) driver provides
>> information about the SoC to the userspace including the
>> --
>> 2.39.2
>>
>>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 1/1] arm64: dts: rockchip: enable onboard spi flash for rock-3a
From: Jonas Karlman @ 2024-04-08 14:56 UTC (permalink / raw)
To: Chukun Pan, Heiko Stuebner
Cc: Conor Dooley, Krzysztof Kozlowski, Rob Herring, linux-arm-kernel,
linux-rockchip, linux-kernel, devicetree
In-Reply-To: <421ab43b-ff92-41c6-9904-3c7681c926be@kwiboo.se>
Hi again,
On 2024-04-08 16:44, Jonas Karlman wrote:
> Hi Chukun,
>
> On 2024-04-08 14:40, Chukun Pan wrote:
>> There is a mx25u12835f spi flash on this board, enable it.
>>
>> [ 2.525805] spi-nor spi4.0: mx25u12835f (16384 Kbytes)
>>
>> Signed-off-by: Chukun Pan <amadeus@jmu.edu.cn>
>> ---
>> arch/arm64/boot/dts/rockchip/rk3568-rock-3a.dts | 12 ++++++++++++
>> 1 file changed, 12 insertions(+)
>>
>> diff --git a/arch/arm64/boot/dts/rockchip/rk3568-rock-3a.dts b/arch/arm64/boot/dts/rockchip/rk3568-rock-3a.dts
>> index a5e974ea659e..d8738cc47c73 100644
>> --- a/arch/arm64/boot/dts/rockchip/rk3568-rock-3a.dts
>> +++ b/arch/arm64/boot/dts/rockchip/rk3568-rock-3a.dts
>> @@ -757,6 +757,18 @@ &sdmmc2 {
>> status = "okay";
>> };
>>
>> +&sfc {
>
> This is missing:
>
> #address-cells = <1>;
> #size-cells = <0>;
>
>> + status = "okay";
>> +
>> + flash@0 {
>> + compatible = "jedec,spi-nor";
>> + reg = <0x0>;
>> + spi-max-frequency = <50000000>;
>
> At least in U-Boot the spi clock only support 24, 100 or 200 mhz and I
> am pretty sure the spi flash support 100mhz, so I would suggest you test
> with 100mhz, same as used on other rk356x boards.
Sorry, looked at spi clock instead of sfc clock.
sfc clock support 24, 50, 75, 100, 125 and 150 mhz.
Regards,
Jonas
>
> For U-Boot I have used 24 mhz for rk356x boards not defining a flash@0
> node in linux device tree, such as the rock-3a board.
>
> Regards,
> Jonas
>
>> + spi-rx-bus-width = <4>;
>> + spi-tx-bus-width = <1>;
>> + };
>> +};
>> +
>> &tsadc {
>> rockchip,hw-tshut-mode = <1>;
>> rockchip,hw-tshut-polarity = <0>;
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 1/1] arm64: dts: rockchip: enable onboard spi flash for rock-3a
From: Heiko Stübner @ 2024-04-08 15:04 UTC (permalink / raw)
To: Chukun Pan, Jonas Karlman
Cc: Conor Dooley, Krzysztof Kozlowski, Rob Herring, linux-arm-kernel,
linux-rockchip, linux-kernel, devicetree
In-Reply-To: <b32c284e-f3ec-44b0-abbd-7fa403bc9870@kwiboo.se>
Am Montag, 8. April 2024, 16:56:59 CEST schrieb Jonas Karlman:
> On 2024-04-08 16:44, Jonas Karlman wrote:
> > On 2024-04-08 14:40, Chukun Pan wrote:
> >> There is a mx25u12835f spi flash on this board, enable it.
> >>
> >> [ 2.525805] spi-nor spi4.0: mx25u12835f (16384 Kbytes)
> >>
> >> Signed-off-by: Chukun Pan <amadeus@jmu.edu.cn>
> >> ---
> >> arch/arm64/boot/dts/rockchip/rk3568-rock-3a.dts | 12 ++++++++++++
> >> 1 file changed, 12 insertions(+)
> >>
> >> diff --git a/arch/arm64/boot/dts/rockchip/rk3568-rock-3a.dts b/arch/arm64/boot/dts/rockchip/rk3568-rock-3a.dts
> >> index a5e974ea659e..d8738cc47c73 100644
> >> --- a/arch/arm64/boot/dts/rockchip/rk3568-rock-3a.dts
> >> +++ b/arch/arm64/boot/dts/rockchip/rk3568-rock-3a.dts
> >> @@ -757,6 +757,18 @@ &sdmmc2 {
> >> status = "okay";
> >> };
> >>
> >> +&sfc {
> >
> > This is missing:
> >
> > #address-cells = <1>;
> > #size-cells = <0>;
> >
> >> + status = "okay";
> >> +
> >> + flash@0 {
> >> + compatible = "jedec,spi-nor";
> >> + reg = <0x0>;
> >> + spi-max-frequency = <50000000>;
> >
> > At least in U-Boot the spi clock only support 24, 100 or 200 mhz and I
> > am pretty sure the spi flash support 100mhz, so I would suggest you test
> > with 100mhz, same as used on other rk356x boards.
>
> Sorry, looked at spi clock instead of sfc clock.
> sfc clock support 24, 50, 75, 100, 125 and 150 mhz.
I think in some previous discussion the agreement was that the node
should specify the max frequency the flash supports and have the
controller worry about its own clock ranges.
Though in this case the 50MHz for the flash even matches the clock
frequency supported by the sfc
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH] dt-bindings: net: rockchip-dwmac: use rgmii-id in example
From: Heiko Stübner @ 2024-04-08 15:05 UTC (permalink / raw)
To: David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, David Wu,
Sascha Hauer
Cc: netdev, devicetree, linux-arm-kernel, linux-rockchip,
linux-kernel, Andrew Lunn, Sascha Hauer
In-Reply-To: <20240408-rockchip-dwmac-rgmii-id-binding-v1-1-3886d1a8bd54@pengutronix.de>
Am Montag, 8. April 2024, 08:44:10 CEST schrieb Sascha Hauer:
> The dwmac supports specifying the RGMII clock delays, but it is
> recommended to use rgmii-id and to specify the delays in the phy node
> instead [1].
>
> Change the example accordingly to no longer promote this undesired
> setting.
>
> [1] https://lore.kernel.org/all/1a0de7b4-f0f7-4080-ae48-f5ffa9e76be3@lunn.ch/
>
> Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
Reviewed-by: Heiko Stuebner <heiko@sntech.de>
> ---
> Documentation/devicetree/bindings/net/rockchip-dwmac.yaml | 4 +---
> 1 file changed, 1 insertion(+), 3 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/net/rockchip-dwmac.yaml b/Documentation/devicetree/bindings/net/rockchip-dwmac.yaml
> index 70bbc4220e2ac..6bbe96e352509 100644
> --- a/Documentation/devicetree/bindings/net/rockchip-dwmac.yaml
> +++ b/Documentation/devicetree/bindings/net/rockchip-dwmac.yaml
> @@ -137,8 +137,6 @@ examples:
> assigned-clock-parents = <&ext_gmac>;
>
> rockchip,grf = <&grf>;
> - phy-mode = "rgmii";
> + phy-mode = "rgmii-id";
> clock_in_out = "input";
> - tx_delay = <0x30>;
> - rx_delay = <0x10>;
> };
>
> ---
> base-commit: 39cd87c4eb2b893354f3b850f916353f2658ae6f
> change-id: 20240408-rockchip-dwmac-rgmii-id-binding-6166af659845
>
> Best regards,
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v2] ASoC: dt-bindings: imx-audio-spdif: convert to YAML
From: Krzysztof Kozlowski @ 2024-04-08 15:06 UTC (permalink / raw)
To: Shengjiu Wang
Cc: Shengjiu Wang, lgirdwood, broonie, robh+dt,
krzysztof.kozlowski+dt, conor+dt, linux-sound, devicetree,
linux-kernel, shawnguo, s.hauer, kernel, festevam, imx,
linux-arm-kernel
In-Reply-To: <CAA+D8ANiKH7Oc+KAjD_BMp9P2EVeM8Q6dLGFCC8a83bJXUpPEA@mail.gmail.com>
On 08/04/2024 10:01, Shengjiu Wang wrote:
>>> +
>>> +anyOf:
>>> + - required:
>>> + - spdif-in
>>> + - required:
>>> + - spdif-out
>>> + - required:
>>> + - spdif-out
>>> + - spdif-in
>>
>> Do you need the last required block?
>
> Yes, one of them or both are required.
And? It's already there: that's the meaning of any. It is not oneOf...
Before answering please test your changes and ideas. I pointed issue
here and you responded just to close my comment. That does not make me
happy, just wastes my time.
>
>>
>>> +
>>> +additionalProperties: false
>>> +
>>> +examples:
>>> + - |
>>> + sound {
>>
>> That's a random change...
>>
>> Instead of sending two patches per day, please carefully address the
>> feedback.
>
> In v1 you suggest to change it to spdif? but spdif may conflict
> with the fsl,spdif.yaml. so which name I should use?
I don't understand where is the conflict. That's a different binding.
Best regards,
Krzysztof
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH net-next v1 00/12] First try to replace page_frag with page_frag_cache
From: Alexander Duyck @ 2024-04-08 15:09 UTC (permalink / raw)
To: Yunsheng Lin
Cc: davem, kuba, pabeni, netdev, linux-kernel, Matthias Brugger,
AngeloGioacchino Del Regno, Alexei Starovoitov, Daniel Borkmann,
Jesper Dangaard Brouer, John Fastabend, linux-arm-kernel,
linux-mediatek, bpf
In-Reply-To: <05c21500-033b-dfee-6aa7-1ee967616213@huawei.com>
On Mon, Apr 8, 2024 at 6:38 AM Yunsheng Lin <linyunsheng@huawei.com> wrote:
>
> On 2024/4/8 1:02, Alexander Duyck wrote:
> > On Sun, Apr 7, 2024 at 6:10 AM Yunsheng Lin <linyunsheng@huawei.com> wrote:
> >>
> >> After [1], Only there are two implementations for page frag:
> >>
> >> 1. mm/page_alloc.c: net stack seems to be using it in the
> >> rx part with 'struct page_frag_cache' and the main API
> >> being page_frag_alloc_align().
> >> 2. net/core/sock.c: net stack seems to be using it in the
> >> tx part with 'struct page_frag' and the main API being
> >> skb_page_frag_refill().
> >>
> >> This patchset tries to unfiy the page frag implementation
> >> by replacing page_frag with page_frag_cache for sk_page_frag()
> >> first. net_high_order_alloc_disable_key for the implementation
> >> in net/core/sock.c doesn't seems matter that much now have
> >> have pcp support for high-order pages in commit 44042b449872
> >> ("mm/page_alloc: allow high-order pages to be stored on the
> >> per-cpu lists").
> >>
> >> As the related change is mostly related to networking, so
> >> targeting the net-next. And will try to replace the rest
> >> of page_frag in the follow patchset.
> >>
> >> After this patchset, we are not only able to unify the page
> >> frag implementation a little, but seems able to have about
> >> 0.5+% performance boost testing by using the vhost_net_test
> >> introduced in [1] and page_frag_test.ko introduced in this
> >> patch.
> >
> > One question that jumps out at me for this is "why?". No offense but
> > this is a pretty massive set of changes with over 1400 additions and
> > 500+ deletions and I can't help but ask why, and this cover page
> > doesn't give me any good reason to think about accepting this set.
>
> There are 375 + 256 additions for testing module and the documentation
> update in the last two patches, and there is 198 additions and 176
> deletions for moving the page fragment allocator from page_alloc into
> its own file in patch 1.
> Without above number, there are above 600+ additions and 300+ deletions,
> deos that seems reasonable considering 140+ additions are needed to for
> the new API, 300+ additions and deletions for updating the users to use
> the new API as there are many users using the old API?
Maybe it would make more sense to break this into 2 sets. The first
one adding your testing, and the second one consolidating the API.
With that we would have a clearly defined test infrastructure in place
for the second set which is making significant changes to the API. In
addition it would provide the opportunity for others to point out any
other test that they might want pulled in since this is likely to have
impact outside of just the tests you have proposed.
> > What is meant to be the benefit to the community for adding this? All
> > I am seeing is a ton of extra code to have to review as this
> > unification is adding an additional 1000+ lines without a good
> > explanation as to why they are needed.
>
> Some benefits I see for now:
> 1. Improve the maintainability of page frag's implementation:
> (1) future bugfix and performance can be done in one place.
> For example, we may able to save some space for the
> 'page_frag_cache' API user, and avoid 'get_page()' for
> the old 'page_frag' API user.
The problem as I see it is it is consolidating all the consumers down
to the least common denominator in terms of performance. You have
already demonstrated that with patch 2 which enforces that all drivers
have to work from the bottom up instead of being able to work top down
in the page.
This eventually leads you down the path where every time somebody has
a use case for it that may not be optimal for others it is going to be
a fight to see if the new use case can degrade the performance of the
other use cases.
> (2) Provide a proper API so that caller does not need to access
> internal data field. Exposing the internal data field may
> enable the caller to do some unexpcted implementation of
> its own like below, after this patchset the API user is not
> supposed to do access the data field of 'page_frag_cache'
> directly[Currently it is still acessable from API caller if
> the caller is not following the rule, I am not sure how to
> limit the access without any performance impact yet].
> https://elixir.bootlin.com/linux/v6.9-rc3/source/drivers/net/ethernet/chelsio/inline_crypto/chtls/chtls_io.c#L1141
This just makes the issue I point out in 1 even worse. The problem is
this code has to be used at the very lowest of levels and is as
tightly optimized as it is since it is called at least once per packet
in the case of networking. Networking that is still getting faster
mind you and demanding even fewer cycles per packet to try and keep
up. I just see this change as taking us in the wrong direction.
> 2. page_frag API may provide a central point for netwroking to allocate
> memory instead of calling page allocator directly in the future, so
> that we can decouple 'struct page' from networking.
I hope not. The fact is the page allocator serves a very specific
purpose, and the page frag API was meant to serve a different one and
not be a replacement for it. One thing that has really irked me is the
fact that I have seen it abused as much as it has been where people
seem to think it is just a page allocator when it was really meant to
just provide a way to shard order 0 pages into sizes that are half a
page or less in size. I really meant for it to be a quick-n-dirty slab
allocator for sizes 2K or less where ideally we are working with
powers of 2.
It concerns me that you are talking about taking this down a path that
will likely lead to further misuse of the code as a backdoor way to
allocate order 0 pages using this instead of just using the page
allocator.
> >
> > Also I wouldn't bother mentioning the 0.5+% performance gain as a
> > "bonus". Changes of that amount usually mean it is within the margin
> > of error. At best it likely means you haven't introduced a noticeable
> > regression.
>
> For micro-benchmark ko added in this patchset, performance gain seems quit
> stable from testing in system without any other load.
Again, that doesn't mean anything. It could just be that the code
shifted somewhere due to all the code moved so a loop got more aligned
than it was before. To give you an idea I have seen performance gains
in the past from turning off Rx checksum for some workloads and that
was simply due to the fact that the CPUs were staying awake longer
instead of going into deep sleep states as such we could handle more
packets per second even though we were using more cycles. Without
significantly more context it is hard to say that the gain is anything
real at all and a 0.5% gain is well within that margin of error.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 1/1] arm64: dts: rockchip: enable onboard spi flash for rock-3a
From: Jonas Karlman @ 2024-04-08 15:14 UTC (permalink / raw)
To: Heiko Stübner, Chukun Pan
Cc: Conor Dooley, Krzysztof Kozlowski, Rob Herring, linux-arm-kernel,
linux-rockchip, linux-kernel, devicetree
In-Reply-To: <3066222.xgJ6IN8ObU@diego>
On 2024-04-08 17:04, Heiko Stübner wrote:
> Am Montag, 8. April 2024, 16:56:59 CEST schrieb Jonas Karlman:
>> On 2024-04-08 16:44, Jonas Karlman wrote:
>>> On 2024-04-08 14:40, Chukun Pan wrote:
>>>> There is a mx25u12835f spi flash on this board, enable it.
>>>>
>>>> [ 2.525805] spi-nor spi4.0: mx25u12835f (16384 Kbytes)
>>>>
>>>> Signed-off-by: Chukun Pan <amadeus@jmu.edu.cn>
>>>> ---
>>>> arch/arm64/boot/dts/rockchip/rk3568-rock-3a.dts | 12 ++++++++++++
>>>> 1 file changed, 12 insertions(+)
>>>>
>>>> diff --git a/arch/arm64/boot/dts/rockchip/rk3568-rock-3a.dts b/arch/arm64/boot/dts/rockchip/rk3568-rock-3a.dts
>>>> index a5e974ea659e..d8738cc47c73 100644
>>>> --- a/arch/arm64/boot/dts/rockchip/rk3568-rock-3a.dts
>>>> +++ b/arch/arm64/boot/dts/rockchip/rk3568-rock-3a.dts
>>>> @@ -757,6 +757,18 @@ &sdmmc2 {
>>>> status = "okay";
>>>> };
>>>>
>>>> +&sfc {
>>>
>>> This is missing:
>>>
>>> #address-cells = <1>;
>>> #size-cells = <0>;
>>>
>>>> + status = "okay";
>>>> +
>>>> + flash@0 {
>>>> + compatible = "jedec,spi-nor";
>>>> + reg = <0x0>;
>>>> + spi-max-frequency = <50000000>;
>>>
>>> At least in U-Boot the spi clock only support 24, 100 or 200 mhz and I
>>> am pretty sure the spi flash support 100mhz, so I would suggest you test
>>> with 100mhz, same as used on other rk356x boards.
>>
>> Sorry, looked at spi clock instead of sfc clock.
>> sfc clock support 24, 50, 75, 100, 125 and 150 mhz.
>
> I think in some previous discussion the agreement was that the node
> should specify the max frequency the flash supports and have the
> controller worry about its own clock ranges.
Interesting, sounds like there is a need to do some modification to spi
and clk drivers in U-Boot to support that.
>
> Though in this case the 50MHz for the flash even matches the clock
> frequency supported by the sfc
I think the on-board spi nor flash support 104/108/133 mhz so 50 mhz is
wrong in any case.
Regards,
Jonas
>
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 1/1] arm64: dts: imx8qxp-mek: add cm40_i2c, wm8960/wm8962 and sai[0,1,4,5]
From: Frank Li @ 2024-04-08 15:36 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Shawn Guo,
Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
open list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE,
moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE,
open list
In-Reply-To: <938489b1-eb94-4f8a-8881-230951299f6a@linaro.org>
On Fri, Apr 05, 2024 at 08:21:18PM +0200, Krzysztof Kozlowski wrote:
> On 05/04/2024 16:46, Frank Li wrote:
> > On Fri, Apr 05, 2024 at 08:41:59AM +0200, Krzysztof Kozlowski wrote:
> >> On 04/04/2024 18:19, Frank Li wrote:
> >>> imx8qxp-mek use two kind audio codec, wm8960 and wm8962. Using dummy gpio
> >>> i2c bus mux to connect both i2c devices. One will probe failure and other
> >>> will probe success when devices driver check whoami. So one dtb can cover
> >>> both board configuration.
> >>
> >> I don't understand it. Either you add real device or not. If one board
> >> has two devices, then why do you need to check for failures?
> >>
> >> Anyway, don't add fake stuff to DTS.
> >
> > NAK can't resolve the problem. It should be common problem for long time
> > cycle boards. Some chipes will be out life cycle. such as some sensor. So
> > chips on boards have been replace by some pin to pin compatible sensor. For
> > example:
> > old boards: use sensor A with address 0x1a
> > new bench: use sensor B with address 0x1b.
> >
> > You can treat it as two kind boards, RevA or RevB. But most user want to
> > use one dtb to handle such small differences. For this case, it should be
> > simple. Just add a super set.
> > i2c
> > {
> > sensorA@1a
> > {
> > }
> > sensorB@1b
> > {
> > }
> > }
> >
> > It also depend on whoami check by i2c devices. Only A or B will probe.
> >
> > wm8960 and wm8962 are more complex example. wm8960 is out of life. But
> > wm8962 and wm8960 have the same i2c address. The current i2c frame can't
> > allow the same i2c address in one i2c bus.
> >
> > You are feel to NAK my method, but I hope you also provide constructive
> > solution to help resolve the problem.
>
> Yes, we resolved it long time ago. Your bootloader can (usually easily)
> detect revision of the board and load appropriate DTS or DTS+DTSO.
I knewn it. But the problem is one development boards A have many options,
so create many child dts for files, A1, A2, ... An which base on A
If there are difference happen at A, create new B. then create all child
dtb, B1, B2, ... Bn. DTB number will increase exponent.
If change is quite bit, we have to do that. But if change is quite small,
One dtb can cover it by driver auto detect, which will work like some
adaptor card have not plug into boards, or some sensor or NOR-flash have
not installed because reduce cost.
Although boot loader can update dts or choose difference dts, It also cause
many confusition, such as layerscape, uboot update many kernel dtb's
information, which actually increase dependence between uboot and kernel.
Also it confuse people, for example, when try to debug kernel dtb, why
change have not token affect when change dts because not realized uboot
over write it.
What's I dide is that trying to reduce unnecessary dts.
Frank
>
> Best regards,
> Krzysztof
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH 0/9] rtc: convert multiple bindings into dtschema
From: Javier Carrasco @ 2024-04-08 15:53 UTC (permalink / raw)
To: Alexandre Belloni, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Jiaxun Yang, Vladimir Zapolskiy, Joel Stanley, Andrew Jeffery,
Maxime Coquelin, Alexandre Torgue
Cc: linux-rtc, devicetree, linux-kernel, linux-arm-kernel,
linux-aspeed, linux-stm32, Javier Carrasco
This series converts the following bindings into dtschema, moving them
to trivial-rtc whenever possible:
- orion-rtc: trival-rtc, referenced in arm arch.
- google,goldfish-rtc: trivial-rtc, referenced in mips arch.
- lpc32xx-rtc: trival-rtc, referenced in arm arch.
- maxim,ds1742: trivial-rtc, not referenced in arch, cheap conversion.
- rtc-aspeed: 3 devices to trivial-rtc, all referenced in arm arch.
- pxa-rtc: add missing properties and convert. Referenced in arm arch.
- st,spear600-rtc: trivial-rtc, referenced in arm arch.
- stmp3xxx-rtc: convert, referenced in arm arch.
- via,vt8500-rtc: trivial-rtc, referenced in arm arch.
Signed-off-by: Javier Carrasco <javier.carrasco.cruz@gmail.com>
---
Javier Carrasco (9):
dt-bindings: rtc: orion-rtc: move to trivial-rtc
dt-bindings: rtc: google,goldfish-rtc: move to trivial-rtc
dt-bindings: rtc: lpc32xx-rtc: move to trivial-rtc
dt-bindings: rtc: maxim,ds1742: move to trivial-rtc
dt-bindings: rtc: rtc-aspeed: move to trivial-rtc
dt-bindings: rtc: pxa-rtc: convert to dtschema
dt-bindings: rtc: spear-rtc: move to trivial-rtc
dt-bindings: rtc: stmp3xxx-rtc: convert to dtschema
dt-bindings: rtc: via,vt8500-rtc: move to trivial-rtc
.../devicetree/bindings/rtc/fsl,stmp3xxx-rtc.yaml | 45 ++++++++++++++++++++++
.../bindings/rtc/google,goldfish-rtc.txt | 17 --------
.../devicetree/bindings/rtc/lpc32xx-rtc.txt | 15 --------
.../devicetree/bindings/rtc/marvell,pxa-rtc.yaml | 40 +++++++++++++++++++
.../devicetree/bindings/rtc/maxim,ds1742.txt | 12 ------
.../devicetree/bindings/rtc/orion-rtc.txt | 18 ---------
Documentation/devicetree/bindings/rtc/pxa-rtc.txt | 14 -------
.../devicetree/bindings/rtc/rtc-aspeed.txt | 22 -----------
.../devicetree/bindings/rtc/spear-rtc.txt | 15 --------
.../devicetree/bindings/rtc/stmp3xxx-rtc.txt | 21 ----------
.../devicetree/bindings/rtc/trivial-rtc.yaml | 18 +++++++++
.../devicetree/bindings/rtc/via,vt8500-rtc.txt | 15 --------
12 files changed, 103 insertions(+), 149 deletions(-)
---
base-commit: fec50db7033ea478773b159e0e2efb135270e3b7
change-id: 20240406-rtc_dtschema-302824d1ec20
Best regards,
--
Javier Carrasco <javier.carrasco.cruz@gmail.com>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH 1/9] dt-bindings: rtc: orion-rtc: move to trivial-rtc
From: Javier Carrasco @ 2024-04-08 15:53 UTC (permalink / raw)
To: Alexandre Belloni, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Jiaxun Yang, Vladimir Zapolskiy, Joel Stanley, Andrew Jeffery,
Maxime Coquelin, Alexandre Torgue
Cc: linux-rtc, devicetree, linux-kernel, linux-arm-kernel,
linux-aspeed, linux-stm32, Javier Carrasco
In-Reply-To: <20240408-rtc_dtschema-v1-0-c447542fc362@gmail.com>
This RTC requires a compatible, a reg and a single interrupt,
which makes it suitable for a direct conversion into trivial-rtc.
Signed-off-by: Javier Carrasco <javier.carrasco.cruz@gmail.com>
---
Documentation/devicetree/bindings/rtc/orion-rtc.txt | 18 ------------------
Documentation/devicetree/bindings/rtc/trivial-rtc.yaml | 2 ++
2 files changed, 2 insertions(+), 18 deletions(-)
diff --git a/Documentation/devicetree/bindings/rtc/orion-rtc.txt b/Documentation/devicetree/bindings/rtc/orion-rtc.txt
deleted file mode 100644
index 3bf63ffa5160..000000000000
--- a/Documentation/devicetree/bindings/rtc/orion-rtc.txt
+++ /dev/null
@@ -1,18 +0,0 @@
-* Mvebu Real Time Clock
-
-RTC controller for the Kirkwood, the Dove, the Armada 370 and the
-Armada XP SoCs
-
-Required properties:
-- compatible : Should be "marvell,orion-rtc"
-- reg: physical base address of the controller and length of memory mapped
- region.
-- interrupts: IRQ line for the RTC.
-
-Example:
-
-rtc@10300 {
- compatible = "marvell,orion-rtc";
- reg = <0xd0010300 0x20>;
- interrupts = <50>;
-};
diff --git a/Documentation/devicetree/bindings/rtc/trivial-rtc.yaml b/Documentation/devicetree/bindings/rtc/trivial-rtc.yaml
index c9e3c5262c21..5e63c8f7f618 100644
--- a/Documentation/devicetree/bindings/rtc/trivial-rtc.yaml
+++ b/Documentation/devicetree/bindings/rtc/trivial-rtc.yaml
@@ -45,6 +45,8 @@ properties:
- isil,isl1208
# Intersil ISL1218 Low Power RTC with Battery Backed SRAM
- isil,isl1218
+ # Mvebu Real-time Clock
+ - marvell,orion-rtc
# SPI-BUS INTERFACE REAL TIME CLOCK MODULE
- maxim,mcp795
# Real Time Clock Module with I2C-Bus
--
2.40.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH 2/9] dt-bindings: rtc: google,goldfish-rtc: move to trivial-rtc
From: Javier Carrasco @ 2024-04-08 15:53 UTC (permalink / raw)
To: Alexandre Belloni, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Jiaxun Yang, Vladimir Zapolskiy, Joel Stanley, Andrew Jeffery,
Maxime Coquelin, Alexandre Torgue
Cc: linux-rtc, devicetree, linux-kernel, linux-arm-kernel,
linux-aspeed, linux-stm32, Javier Carrasco
In-Reply-To: <20240408-rtc_dtschema-v1-0-c447542fc362@gmail.com>
This RTC requires a compatible, a reg and a single interrupt,
which makes it suitable for a direct conversion into trivial-rtc.
Signed-off-by: Javier Carrasco <javier.carrasco.cruz@gmail.com>
---
.../devicetree/bindings/rtc/google,goldfish-rtc.txt | 17 -----------------
Documentation/devicetree/bindings/rtc/trivial-rtc.yaml | 2 ++
2 files changed, 2 insertions(+), 17 deletions(-)
diff --git a/Documentation/devicetree/bindings/rtc/google,goldfish-rtc.txt b/Documentation/devicetree/bindings/rtc/google,goldfish-rtc.txt
deleted file mode 100644
index 634312dd95ca..000000000000
--- a/Documentation/devicetree/bindings/rtc/google,goldfish-rtc.txt
+++ /dev/null
@@ -1,17 +0,0 @@
-Android Goldfish RTC
-
-Android Goldfish RTC device used by Android emulator.
-
-Required properties:
-
-- compatible : should contain "google,goldfish-rtc"
-- reg : <registers mapping>
-- interrupts : <interrupt mapping>
-
-Example:
-
- goldfish_timer@9020000 {
- compatible = "google,goldfish-rtc";
- reg = <0x9020000 0x1000>;
- interrupts = <0x3>;
- };
diff --git a/Documentation/devicetree/bindings/rtc/trivial-rtc.yaml b/Documentation/devicetree/bindings/rtc/trivial-rtc.yaml
index 5e63c8f7f618..b889b9317a41 100644
--- a/Documentation/devicetree/bindings/rtc/trivial-rtc.yaml
+++ b/Documentation/devicetree/bindings/rtc/trivial-rtc.yaml
@@ -41,6 +41,8 @@ properties:
- epson,rx8571
# I2C-BUS INTERFACE REAL TIME CLOCK MODULE
- epson,rx8581
+ # Android Goldfish Real-time Clock
+ - google,goldfish-rtc
# Intersil ISL1208 Low Power RTC with Battery Backed SRAM
- isil,isl1208
# Intersil ISL1218 Low Power RTC with Battery Backed SRAM
--
2.40.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH 3/9] dt-bindings: rtc: lpc32xx-rtc: move to trivial-rtc
From: Javier Carrasco @ 2024-04-08 15:53 UTC (permalink / raw)
To: Alexandre Belloni, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Jiaxun Yang, Vladimir Zapolskiy, Joel Stanley, Andrew Jeffery,
Maxime Coquelin, Alexandre Torgue
Cc: linux-rtc, devicetree, linux-kernel, linux-arm-kernel,
linux-aspeed, linux-stm32, Javier Carrasco
In-Reply-To: <20240408-rtc_dtschema-v1-0-c447542fc362@gmail.com>
This RTC requires a compatible, a reg and a single interrupt,
which makes it suitable for a direct conversion into trivial-rtc.
Signed-off-by: Javier Carrasco <javier.carrasco.cruz@gmail.com>
---
Documentation/devicetree/bindings/rtc/lpc32xx-rtc.txt | 15 ---------------
Documentation/devicetree/bindings/rtc/trivial-rtc.yaml | 2 ++
2 files changed, 2 insertions(+), 15 deletions(-)
diff --git a/Documentation/devicetree/bindings/rtc/lpc32xx-rtc.txt b/Documentation/devicetree/bindings/rtc/lpc32xx-rtc.txt
deleted file mode 100644
index a87a1e9bc060..000000000000
--- a/Documentation/devicetree/bindings/rtc/lpc32xx-rtc.txt
+++ /dev/null
@@ -1,15 +0,0 @@
-* NXP LPC32xx SoC Real Time Clock controller
-
-Required properties:
-- compatible: must be "nxp,lpc3220-rtc"
-- reg: physical base address of the controller and length of memory mapped
- region.
-- interrupts: The RTC interrupt
-
-Example:
-
- rtc@40024000 {
- compatible = "nxp,lpc3220-rtc";
- reg = <0x40024000 0x1000>;
- interrupts = <52 0>;
- };
diff --git a/Documentation/devicetree/bindings/rtc/trivial-rtc.yaml b/Documentation/devicetree/bindings/rtc/trivial-rtc.yaml
index b889b9317a41..d6ce7ac29033 100644
--- a/Documentation/devicetree/bindings/rtc/trivial-rtc.yaml
+++ b/Documentation/devicetree/bindings/rtc/trivial-rtc.yaml
@@ -55,6 +55,8 @@ properties:
- microcrystal,rv3029
# Real Time Clock
- microcrystal,rv8523
+ # NXP LPC32xx SoC Real-time Clock
+ - nxp,lpc3220-rtc
# Real-time Clock Module
- pericom,pt7c4338
# I2C bus SERIAL INTERFACE REAL-TIME CLOCK IC
--
2.40.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH 4/9] dt-bindings: rtc: maxim,ds1742: move to trivial-rtc
From: Javier Carrasco @ 2024-04-08 15:53 UTC (permalink / raw)
To: Alexandre Belloni, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Jiaxun Yang, Vladimir Zapolskiy, Joel Stanley, Andrew Jeffery,
Maxime Coquelin, Alexandre Torgue
Cc: linux-rtc, devicetree, linux-kernel, linux-arm-kernel,
linux-aspeed, linux-stm32, Javier Carrasco
In-Reply-To: <20240408-rtc_dtschema-v1-0-c447542fc362@gmail.com>
This RTC only requires the compatible a reg and properties,
which makes it suitable for a direct conversion into trivial-rtc.
Signed-off-by: Javier Carrasco <javier.carrasco.cruz@gmail.com>
---
Documentation/devicetree/bindings/rtc/maxim,ds1742.txt | 12 ------------
Documentation/devicetree/bindings/rtc/trivial-rtc.yaml | 2 ++
2 files changed, 2 insertions(+), 12 deletions(-)
diff --git a/Documentation/devicetree/bindings/rtc/maxim,ds1742.txt b/Documentation/devicetree/bindings/rtc/maxim,ds1742.txt
deleted file mode 100644
index d0f937c355b5..000000000000
--- a/Documentation/devicetree/bindings/rtc/maxim,ds1742.txt
+++ /dev/null
@@ -1,12 +0,0 @@
-* Maxim (Dallas) DS1742/DS1743 Real Time Clock
-
-Required properties:
-- compatible: Should contain "maxim,ds1742".
-- reg: Physical base address of the RTC and length of memory
- mapped region.
-
-Example:
- rtc: rtc@10000000 {
- compatible = "maxim,ds1742";
- reg = <0x10000000 0x800>;
- };
diff --git a/Documentation/devicetree/bindings/rtc/trivial-rtc.yaml b/Documentation/devicetree/bindings/rtc/trivial-rtc.yaml
index d6ce7ac29033..710b096fe6f7 100644
--- a/Documentation/devicetree/bindings/rtc/trivial-rtc.yaml
+++ b/Documentation/devicetree/bindings/rtc/trivial-rtc.yaml
@@ -49,6 +49,8 @@ properties:
- isil,isl1218
# Mvebu Real-time Clock
- marvell,orion-rtc
+ # Maxim DS1742/DS1743 Real-time Clock
+ - maxim,ds1742
# SPI-BUS INTERFACE REAL TIME CLOCK MODULE
- maxim,mcp795
# Real Time Clock Module with I2C-Bus
--
2.40.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH 5/9] dt-bindings: rtc: rtc-aspeed: move to trivial-rtc
From: Javier Carrasco @ 2024-04-08 15:53 UTC (permalink / raw)
To: Alexandre Belloni, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Jiaxun Yang, Vladimir Zapolskiy, Joel Stanley, Andrew Jeffery,
Maxime Coquelin, Alexandre Torgue
Cc: linux-rtc, devicetree, linux-kernel, linux-arm-kernel,
linux-aspeed, linux-stm32, Javier Carrasco
In-Reply-To: <20240408-rtc_dtschema-v1-0-c447542fc362@gmail.com>
The RTCs documented in this binding require a compatible, a reg
and a single interrupt, which make them suitable for a direct
conversion into trivial-rtc.
Signed-off-by: Javier Carrasco <javier.carrasco.cruz@gmail.com>
---
.../devicetree/bindings/rtc/rtc-aspeed.txt | 22 ----------------------
.../devicetree/bindings/rtc/trivial-rtc.yaml | 6 ++++++
2 files changed, 6 insertions(+), 22 deletions(-)
diff --git a/Documentation/devicetree/bindings/rtc/rtc-aspeed.txt b/Documentation/devicetree/bindings/rtc/rtc-aspeed.txt
deleted file mode 100644
index 2e956b3dc276..000000000000
--- a/Documentation/devicetree/bindings/rtc/rtc-aspeed.txt
+++ /dev/null
@@ -1,22 +0,0 @@
-ASPEED BMC RTC
-==============
-
-Required properties:
- - compatible: should be one of the following
- * aspeed,ast2400-rtc for the ast2400
- * aspeed,ast2500-rtc for the ast2500
- * aspeed,ast2600-rtc for the ast2600
-
- - reg: physical base address of the controller and length of memory mapped
- region
-
- - interrupts: The interrupt number
-
-Example:
-
- rtc@1e781000 {
- compatible = "aspeed,ast2400-rtc";
- reg = <0x1e781000 0x18>;
- interrupts = <22>;
- status = "disabled";
- };
diff --git a/Documentation/devicetree/bindings/rtc/trivial-rtc.yaml b/Documentation/devicetree/bindings/rtc/trivial-rtc.yaml
index 710b096fe6f7..0f773167d32a 100644
--- a/Documentation/devicetree/bindings/rtc/trivial-rtc.yaml
+++ b/Documentation/devicetree/bindings/rtc/trivial-rtc.yaml
@@ -24,6 +24,12 @@ properties:
- abracon,abb5zes3
# AB-RTCMC-32.768kHz-EOZ9: Real Time Clock/Calendar Module with I2C Interface
- abracon,abeoz9
+ # ASPEED BMC ast2400 Real-time Clock
+ - aspeed,ast2400-rtc
+ # ASPEED BMC ast2500 Real-time Clock
+ - aspeed,ast2500-rtc
+ # ASPEED BMC ast2600 Real-time Clock
+ - aspeed,ast2600-rtc
# I2C, 32-Bit Binary Counter Watchdog RTC with Trickle Charger and Reset Input/Output
- dallas,ds1374
# Dallas DS1672 Real-time Clock
--
2.40.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH 6/9] dt-bindings: rtc: pxa-rtc: convert to dtschema
From: Javier Carrasco @ 2024-04-08 15:53 UTC (permalink / raw)
To: Alexandre Belloni, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Jiaxun Yang, Vladimir Zapolskiy, Joel Stanley, Andrew Jeffery,
Maxime Coquelin, Alexandre Torgue
Cc: linux-rtc, devicetree, linux-kernel, linux-arm-kernel,
linux-aspeed, linux-stm32, Javier Carrasco
In-Reply-To: <20240408-rtc_dtschema-v1-0-c447542fc362@gmail.com>
Convert existing binding to dtschema to support validation.
The missing 'reg' and 'interrupts' properties have been added, taking
the 2 supported interrupts into account to fix the example.
Signed-off-by: Javier Carrasco <javier.carrasco.cruz@gmail.com>
---
.../devicetree/bindings/rtc/marvell,pxa-rtc.yaml | 40 ++++++++++++++++++++++
Documentation/devicetree/bindings/rtc/pxa-rtc.txt | 14 --------
2 files changed, 40 insertions(+), 14 deletions(-)
diff --git a/Documentation/devicetree/bindings/rtc/marvell,pxa-rtc.yaml b/Documentation/devicetree/bindings/rtc/marvell,pxa-rtc.yaml
new file mode 100644
index 000000000000..43d68681a1bf
--- /dev/null
+++ b/Documentation/devicetree/bindings/rtc/marvell,pxa-rtc.yaml
@@ -0,0 +1,40 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/rtc/marvell,pxa-rtc.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: PXA Real Time Clock
+
+maintainers:
+ - Javier Carrasco <javier.carrasco.cruz@gmail.com>
+
+allOf:
+ - $ref: rtc.yaml#
+
+properties:
+ compatible:
+ const: marvell,pxa-rtc
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ items:
+ - description: 1 Hz
+ - description: Alarm
+
+required:
+ - compatible
+ - reg
+ - interrupts
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ rtc@40900000 {
+ compatible = "marvell,pxa-rtc";
+ reg = <0x40900000 0x3c>;
+ interrupts = <30>, <31>;
+ };
diff --git a/Documentation/devicetree/bindings/rtc/pxa-rtc.txt b/Documentation/devicetree/bindings/rtc/pxa-rtc.txt
deleted file mode 100644
index 8c6672a1b7d7..000000000000
--- a/Documentation/devicetree/bindings/rtc/pxa-rtc.txt
+++ /dev/null
@@ -1,14 +0,0 @@
-* PXA RTC
-
-PXA specific RTC driver.
-
-Required properties:
-- compatible : Should be "marvell,pxa-rtc"
-
-Examples:
-
-rtc@40900000 {
- compatible = "marvell,pxa-rtc";
- reg = <0x40900000 0x3c>;
- interrupts = <30 31>;
-};
--
2.40.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox