* Re: [PATCH v2 5/7] dt-bindings: phy: qcom,ipq8074-qmp-pcie: add ipq9574 gen3x2 PHY
From: Rob Herring @ 2024-04-09 20:49 UTC (permalink / raw)
To: Alexandru Gagniuc
Cc: Kishon Vijay Abraham I, Krzysztof Kozlowski, linux-phy,
Conor Dooley, linux-kernel, Konrad Dybcio, linux-arm-msm,
Bjorn Andersson, Vinod Koul, devicetree
In-Reply-To: <20240409190833.3485824-6-mr.nuke.me@gmail.com>
On Tue, 09 Apr 2024 14:08:31 -0500, Alexandru Gagniuc wrote:
> The IPQ9574 gen3x2 PHY is very similar to IPQ6018. It requires two
> extra clocks named "anoc" and "snoc". Document this, and add a
> new compatible string for this PHY.
>
> Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
> ---
> .../phy/qcom,ipq8074-qmp-pcie-phy.yaml | 31 ++++++++++++++++++-
> 1 file changed, 30 insertions(+), 1 deletion(-)
>
My bot found errors running 'make dt_binding_check' on your patch:
yamllint warnings/errors:
dtschema/dtc warnings/errors:
/builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/phy/qcom,ipq8074-qmp-pcie-phy.example.dtb: phy@84000: clock-names: ['aux', 'cfg_ahb', 'pipe'] is too short
from schema $id: http://devicetree.org/schemas/phy/qcom,ipq8074-qmp-pcie-phy.yaml#
doc reference errors (make refcheckdocs):
See https://patchwork.ozlabs.org/project/devicetree-bindings/patch/20240409190833.3485824-6-mr.nuke.me@gmail.com
The base for the series is generally the latest rc1. A different dependency
should be noted in *this* patch.
If you already ran 'make dt_binding_check' and didn't see the above
error(s), then make sure 'yamllint' is installed and dt-schema is up to
date:
pip3 install dtschema --upgrade
Please check and re-submit after running the above command yourself. Note
that DT_SCHEMA_FILES can be set to your schema file to speed up checking
your schema. However, it must be unset to test all examples with your schema.
^ permalink raw reply
* Re: [PATCH v3 1/2] dt-bindings: dma: fsl-edma: remove 'clocks' from required
From: Frank Li @ 2024-04-09 21:09 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: conor+dt, devicetree, dmaengine, imx, krzysztof.kozlowski+dt,
linux-kernel, peng.fan, robh, vkoul
In-Reply-To: <b15ad271-037e-4ee3-ad88-e8068d31c8c8@linaro.org>
On Tue, Apr 09, 2024 at 10:02:32PM +0200, Krzysztof Kozlowski wrote:
> On 09/04/2024 20:54, Frank Li wrote:
> > fsl,imx8qm-adma and fsl,imx8qm-edma don't require 'clocks'. Remove it from
> > required and add 'if' block for other compatible string to keep the same
> > restrictions.
> >
> > Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
> > Signed-off-by: Frank Li <Frank.Li@nxp.com>
> > ---
> >
> > Notes:
> > Change from v2 to v3
> > - rebase to dmaengine/next
>
> This fails...
What's wrong?
https://git.kernel.org/pub/scm/linux/kernel/git/vkoul/dmaengine.git/log/?h=next
>
> >
> > diff --git a/Documentation/devicetree/bindings/dma/fsl,edma.yaml b/Documentation/devicetree/bindings/dma/fsl,edma.yaml
> > index 825f4715499e5..657a7d3ebf857 100644
> > --- a/Documentation/devicetree/bindings/dma/fsl,edma.yaml
> > +++ b/Documentation/devicetree/bindings/dma/fsl,edma.yaml
> > @@ -82,7 +82,6 @@ required:
> > - compatible
> > - reg
> > - interrupts
> > - - clocks
> > - dma-channels
> >
> > allOf:
> > @@ -187,6 +186,22 @@ allOf:
> > "#dma-cells":
> > const: 3
> >
> > + - if:
> > + properties:
> > + compatible:
> > + contains:
>
> It does not look like you tested the bindings, at least after quick
> look. Please run `make dt_binding_check` (see
> Documentation/devicetree/bindings/writing-schema.rst for instructions).
> Maybe you need to update your dtschema and yamllint.
Strange, Test passed
make ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- -j8 dt_binding_check DT_SCHEMA_FILES=fsl,edma.yaml
LINT Documentation/devicetree/bindings
DTEX Documentation/devicetree/bindings/dma/fsl,edma.example.dts
CHKDT Documentation/devicetree/bindings/processed-schema.json
SCHEMA Documentation/devicetree/bindings/processed-schema.json
DTC_CHK Documentation/devicetree/bindings/dma/fsl,edma.example.dtb
>
> Best regards,
> Krzysztof
>
^ permalink raw reply
* Re: [PATCH net-next v7 13/17] net: pse-pd: Use regulator framework within PSE framework
From: Jakub Kicinski @ 2024-04-09 21:16 UTC (permalink / raw)
To: Kory Maincent
Cc: David S. Miller, Eric Dumazet, Paolo Abeni, Jonathan Corbet,
Luis Chamberlain, Russ Weight, Greg Kroah-Hartman,
Rafael J. Wysocki, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Oleksij Rempel, Mark Brown, Frank Rowand, Andrew Lunn,
Heiner Kallweit, Russell King, Thomas Petazzoni, netdev,
linux-kernel, linux-doc, devicetree, Dent Project, kernel,
Maxime Chevallier
In-Reply-To: <20240409-feature_poe-v7-13-11e38efd4dee@bootlin.com>
On Tue, 09 Apr 2024 17:04:03 +0200 Kory Maincent wrote:
> -static inline struct pse_control *of_pse_control_get(struct device_node *node)
> +static inline struct pse_control *of_pse_control_get(struct device *dev,
> + struct device_node *node)
One of the related patches breaks the build:
drivers/net/mdio/fwnode_mdio.c: In function ‘fwnode_find_pse_control’:
drivers/net/mdio/fwnode_mdio.c:32:35: error: passing argument 1 of ‘of_pse_control_get’ from incompatible pointer type [-Werror=incompatible-pointer-types]
32 | psec = of_pse_control_get(np);
| ^~
| |
| struct device_node *
In file included from drivers/net/mdio/fwnode_mdio.c:13:
./include/linux/pse-pd/pse.h:157:69: note: expected ‘struct device *’ but argument is of type ‘struct device_node *’
157 | static inline struct pse_control *of_pse_control_get(struct device *dev,
| ~~~~~~~~~~~~~~~^~~
drivers/net/mdio/fwnode_mdio.c:32:16: error: too few arguments to function ‘of_pse_control_get’
32 | psec = of_pse_control_get(np);
| ^~~~~~~~~~~~~~~~~~
In file included from drivers/net/mdio/fwnode_mdio.c:13:
./include/linux/pse-pd/pse.h:157:35: note: declared here
157 | static inline struct pse_control *of_pse_control_get(struct device *dev,
| ^~~~~~~~~~~~~~~~~~
cc1: all warnings being treated as errors
^ permalink raw reply
* Re: [PATCH v2 00/13] ASoC: ti: davinci-i2s: Add features to McBSP driver
From: Mark Brown @ 2024-04-09 23:34 UTC (permalink / raw)
To: Liam Girdwood, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Peter Ujfalusi, Jaroslav Kysela, Takashi Iwai, Bastien Curutchet
Cc: linux-sound, devicetree, linux-kernel, alsa-devel,
Thomas Petazzoni, herve.codina, christophercordahi
In-Reply-To: <20240402071213.11671-1-bastien.curutchet@bootlin.com>
On Tue, 02 Apr 2024 09:12:00 +0200, Bastien Curutchet wrote:
> This series aims to add some features to McBSP driver.
>
> Convert bindings from .txt to .yaml.
> Add possibility to use an external clock as sample rate generator's
> input.
> Add handling of new formats (TDM, S24_LE, BP_FC).
> Enable the detection of unexpected frame pulses.
> Set the clock free-running mode according to SND_SOC_DAIFMT_[GATED/CONT]
> configuration in DAI format.
> Add ti,T1-framing[tx/rx] properties in DT. They allow to set the data
> delay to two bit-clock periods.
>
> [...]
Applied to
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git for-next
Thanks!
[01/13] ASoC: dt-bindings: davinci-mcbsp: convert McBSP bindings to yaml schema
commit: 22a1dd652de329394ca81dd2fe046444920c96dc
[02/13] ASoC: dt-bindings: davinci-mcbsp: Add optional clock
commit: 6a4b6b062a5917d611c1bde7189c5147cf0ca832
[03/13] ASoC: ti: davinci-i2s: Remove the unused clk_input_pin attribute
commit: 904fb8f843a99ae7473d184412b6c7bd46a51593
[04/13] ASoC: ti: davinci-i2s: Replace dev_err with dev_err_probe
commit: 6b1517b30d6dc9442d92f0273726f1e7390eff2c
[05/13] ASoC: ti: davinci-i2s: Use external clock to drive sample rate generator
commit: 714ffb8d36f94bdc6d576417b451e9c568c83894
[06/13] ASoC: ti: davinci-i2s: Delete unnecessary assignment
commit: 7dd7a6d2648b0b253cb8be3cdf8e895a995548fe
[07/13] ASoC: ti: davinci-i2s: Add TDM support
commit: 37e313cda35aa16623ccae630530651c786a1392
[08/13] ASoC: ti: davinci-i2s: Add handling of BP_FC format
commit: eff21f5f8ea01834835ebe35995dba40f8435795
[09/13] ASoC: ti: davinci-i2s: Enable unexpected frame pulses detection
commit: 94d57c541dbdd350a91baeee94d3f5148e1d4dd7
[10/13] ASoC: ti: davinci-i2s: Link free-run mode to SND_SOC_DAIFMT_[GATED/CONT]
commit: 091b440ffd7cb542fd45c39dddd56bd870f9e180
[11/13] ASoC: ti: davinci-i2s: Add S24_LE to supported formats
commit: 92e7bb2b6aa374c130dcf052f2c52f63c5b75d38
[12/13] ASoC: dt-bindings: davinci-mcbsp: Add the 'ti,T1-framing-{rx/tx}' flags
commit: 609302ca04a3177463b0fbf4d5fc55a3ab4f900d
[13/13] ASoC: ti: davinci-i2s: Add T1 framing support
commit: 08e02fa48429c34db231cc3b58b940de2f7caf35
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.
You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.
If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.
Please add any relevant lists and maintainers to the CCs when replying
to this mail.
Thanks,
Mark
^ permalink raw reply
* Re: [PATCH v4 2/2] phy: add driver for MediaTek XFI T-PHY
From: Jacob Keller @ 2024-04-10 0:15 UTC (permalink / raw)
To: Daniel Golle, Vinod Koul, Bc-bocun Chen, Steven Liu, John Crispin,
Chunfeng Yun, Kishon Vijay Abraham I, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Matthias Brugger,
AngeloGioacchino Del Regno, Qingfang Deng, SkyLake Huang,
Philipp Zabel, linux-arm-kernel, linux-mediatek, linux-phy,
devicetree, linux-kernel, netdev
In-Reply-To: <8719c82634df7e8e984f1a608be3ba2f2d494fb4.1712625857.git.daniel@makrotopia.org>
On 4/8/2024 7:24 PM, Daniel Golle wrote:
> Add driver for MediaTek's XFI T-PHY which can be found in the MT7988
> SoC. The XFI T-PHY is a 10 Gigabit/s Ethernet SerDes PHY with muxes on
> the internal side to be used with either USXGMII PCS or LynxI PCS,
> depending on the selected PHY interface mode.
>
> The PHY can operates only in PHY_MODE_ETHERNET, the submode is one of
> PHY_INTERFACE_MODE_* corresponding to the supported modes:
>
> * USXGMII \
> * 10GBase-R }- USXGMII PCS - XGDM \
> * 5GBase-R / \
> }- Ethernet MAC
> * 2500Base-X \ /
> * 1000Base-X }- LynxI PCS - GDM /
> * Cisco SGMII (MAC side) /
>
> I chose the name XFI T-PHY because names of functions dealing with the
> phy in the vendor driver are prefixed "xfi_pextp_".
>
> The register space used by the phy is called "pextp" in the vendor
> sources, which could be read as "_P_CI _ex_press _T_-_P_hy", and that
> is quite misleading as this phy isn't used for anything related to
> PCIe, so I wanted to find a better name.
>
> XFI is still somehow related (as in: you would find the relevant
> places using grep in the vendor driver when looking for that) and the
> term seemed to at least somehow be aligned with the function of that
> phy: Dealing with (up to) 10 Gbit/s Ethernet serialized differential
> signals.
>
> In order to work-around a performance issue present on the first of
> two XFI T-PHYs found in MT7988, special tuning is applied which can
> be selected by adding the 'mediatek,usxgmii-performance-errata'
> property to the device tree node, similar to how the vendor driver is
> doing that too.
>
> There is no documentation for most registers used for the
> analog/tuning part, however, most of the registers have been partially
> reverse-engineered from MediaTek's SDK implementation (see links, an
> opaque sequence of 32-bit register writes) and descriptions for all
> relevant digital registers and bits such as resets and muxes have been
> supplied by MediaTek.
>
Not an expert in PHY drivers, or this particular hardware, but nothing
seems out of place to me.
Reviewed-by: Jacob Keller <jacob.e.keller@intel.com>
I appreciate the links to the vendor driver code and your explanations
of how and why this differs.
> Link: https://git01.mediatek.com/plugins/gitiles/openwrt/feeds/mtk-openwrt-feeds/+/b72d6cba92bf9e29fb035c03052fa1e86664a25b/21.02/files/target/linux/mediatek/files-5.4/drivers/net/ethernet/mediatek/mtk_sgmii.c
> Link: https://git01.mediatek.com/plugins/gitiles/openwrt/feeds/mtk-openwrt-feeds/+/dec96a1d9b82cdcda4a56453fd0b453d4cab4b85/21.02/files/target/linux/mediatek/files-5.4/drivers/net/ethernet/mediatek/mtk_eth_soc.c
> Signed-off-by: Daniel Golle <daniel@makrotopia.org>
> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
> ---
> v4:
> Functional changes:
> * Include fix for SGMII, found in vendor SDK[1].
>
> Non-functional/cosmetic changes:
> * Separate allocation and assignment of bools in mtk_xfi_tphy_setup().
> * Remove unnecessary parentheses.
> * Explain naming in commit message.
> * Drop unnecessary dependencies from Kconfig.
> * Provide URL references to source of magic values.
> * Add kernel-doc comments.
>
> [1]: https://git01.mediatek.com/plugins/gitiles/openwrt/feeds/mtk-openwrt-feeds/+/b72d6cba92bf9e29fb035c03052fa1e86664a25b
>
> v3: no changes
>
> v2:
> * use IO helpers from mtk-io.h instead of rolling my own
> * use devm_clk_bulk_get()
> * yse devm_platform_ioremap_resource()
> * unify name and description everywhere
> * invert bool is_xgmii into bool use_lynxi_pcs and add comments
> describing the meaning of each of the stack variables
> * not much we can do about remaining magic values unless MTK provides
> definitions for them
>
> MAINTAINERS | 1 +
> drivers/phy/mediatek/Kconfig | 11 +
> drivers/phy/mediatek/Makefile | 1 +
> drivers/phy/mediatek/phy-mtk-xfi-tphy.c | 451 ++++++++++++++++++++++++
> 4 files changed, 464 insertions(+)
> create mode 100644 drivers/phy/mediatek/phy-mtk-xfi-tphy.c
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index a4924fda31829b..98b4b391d224f9 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -13870,6 +13870,7 @@ L: netdev@vger.kernel.org
> S: Maintained
> F: drivers/net/phy/mediatek-ge-soc.c
> F: drivers/net/phy/mediatek-ge.c
> +F: drivers/phy/mediatek/phy-mtk-xfi-tphy.c
>
> MEDIATEK I2C CONTROLLER DRIVER
> M: Qii Wang <qii.wang@mediatek.com>
> diff --git a/drivers/phy/mediatek/Kconfig b/drivers/phy/mediatek/Kconfig
> index 3849b7c87d2872..60e00057e8bc71 100644
> --- a/drivers/phy/mediatek/Kconfig
> +++ b/drivers/phy/mediatek/Kconfig
> @@ -13,6 +13,17 @@ config PHY_MTK_PCIE
> callback for PCIe GEN3 port, it supports software efuse
> initialization.
>
> +config PHY_MTK_XFI_TPHY
> + tristate "MediaTek 10GE SerDes XFI T-PHY driver"
> + depends on ARCH_MEDIATEK || COMPILE_TEST
> + depends on OF
> + select GENERIC_PHY
> + help
> + Say 'Y' here to add support for MediaTek XFI T-PHY driver.
> + The driver provides access to the Ethernet SerDes T-PHY supporting
> + 1GE and 2.5GE modes via the LynxI PCS, and 5GE and 10GE modes
> + via the USXGMII PCS found in MediaTek SoCs with 10G Ethernet.
> +
> config PHY_MTK_TPHY
> tristate "MediaTek T-PHY Driver"
> depends on ARCH_MEDIATEK || COMPILE_TEST
> diff --git a/drivers/phy/mediatek/Makefile b/drivers/phy/mediatek/Makefile
> index f6e24a47e08153..1b8088df71e845 100644
> --- a/drivers/phy/mediatek/Makefile
> +++ b/drivers/phy/mediatek/Makefile
> @@ -8,6 +8,7 @@ obj-$(CONFIG_PHY_MTK_PCIE) += phy-mtk-pcie.o
> obj-$(CONFIG_PHY_MTK_TPHY) += phy-mtk-tphy.o
> obj-$(CONFIG_PHY_MTK_UFS) += phy-mtk-ufs.o
> obj-$(CONFIG_PHY_MTK_XSPHY) += phy-mtk-xsphy.o
> +obj-$(CONFIG_PHY_MTK_XFI_TPHY) += phy-mtk-xfi-tphy.o
>
> phy-mtk-hdmi-drv-y := phy-mtk-hdmi.o
> phy-mtk-hdmi-drv-y += phy-mtk-hdmi-mt2701.o
> diff --git a/drivers/phy/mediatek/phy-mtk-xfi-tphy.c b/drivers/phy/mediatek/phy-mtk-xfi-tphy.c
> new file mode 100644
> index 00000000000000..3e3af7f7a3fdf5
> --- /dev/null
> +++ b/drivers/phy/mediatek/phy-mtk-xfi-tphy.c
> @@ -0,0 +1,451 @@
> +// SPDX-License-Identifier: GPL-2.0-or-later
> +/*
> + * MediaTek 10GE SerDes XFI T-PHY driver
> + *
> + * Copyright (c) 2024 Daniel Golle <daniel@makrotopia.org>
> + * Bc-bocun Chen <bc-bocun.chen@mediatek.com>
> + * based on mtk_usxgmii.c and mtk_sgmii.c found in MediaTek's SDK (GPL-2.0)
> + * Copyright (c) 2022 MediaTek Inc.
> + * Author: Henry Yen <henry.yen@mediatek.com>
> + */
> +
> +#include <linux/module.h>
> +#include <linux/device.h>
> +#include <linux/platform_device.h>
> +#include <linux/of.h>
> +#include <linux/io.h>
> +#include <linux/clk.h>
> +#include <linux/reset.h>
> +#include <linux/phy.h>
> +#include <linux/phy/phy.h>
> +
> +#include "phy-mtk-io.h"
> +
> +#define MTK_XFI_TPHY_NUM_CLOCKS 2
> +
> +#define REG_DIG_GLB_70 0x0070
> +#define XTP_PCS_RX_EQ_IN_PROGRESS(x) FIELD_PREP(GENMASK(25, 24), (x))
> +#define XTP_PCS_MODE_MASK GENMASK(17, 16)
> +#define XTP_PCS_MODE(x) FIELD_PREP(GENMASK(17, 16), (x))
> +#define XTP_PCS_RST_B BIT(15)
> +#define XTP_FRC_PCS_RST_B BIT(14)
> +#define XTP_PCS_PWD_SYNC_MASK GENMASK(13, 12)
> +#define XTP_PCS_PWD_SYNC(x) FIELD_PREP(XTP_PCS_PWD_SYNC_MASK, (x))
> +#define XTP_PCS_PWD_ASYNC_MASK GENMASK(11, 10)
> +#define XTP_PCS_PWD_ASYNC(x) FIELD_PREP(XTP_PCS_PWD_ASYNC_MASK, (x))
> +#define XTP_FRC_PCS_PWD_ASYNC BIT(8)
> +#define XTP_PCS_UPDT BIT(4)
> +#define XTP_PCS_IN_FR_RG BIT(0)
> +
> +#define REG_DIG_GLB_F4 0x00f4
> +#define XFI_DPHY_PCS_SEL BIT(0)
> +#define XFI_DPHY_PCS_SEL_SGMII FIELD_PREP(XFI_DPHY_PCS_SEL, 1)
> +#define XFI_DPHY_PCS_SEL_USXGMII FIELD_PREP(XFI_DPHY_PCS_SEL, 0)
> +#define XFI_DPHY_AD_SGDT_FRC_EN BIT(5)
> +
> +#define REG_DIG_LN_TRX_40 0x3040
> +#define XTP_LN_FRC_TX_DATA_EN BIT(29)
> +#define XTP_LN_TX_DATA_EN BIT(28)
> +
> +#define REG_DIG_LN_TRX_B0 0x30b0
> +#define XTP_LN_FRC_TX_MACCK_EN BIT(5)
> +#define XTP_LN_TX_MACCK_EN BIT(4)
> +
> +#define REG_ANA_GLB_D0 0x90d0
> +#define XTP_GLB_USXGMII_SEL_MASK GENMASK(3, 1)
> +#define XTP_GLB_USXGMII_SEL(x) FIELD_PREP(GENMASK(3, 1), (x))
> +#define XTP_GLB_USXGMII_EN BIT(0)
> +
> +/**
> + * struct mtk_xfi_tphy - run-time data of the XFI phy instance
> + * @base: IO memory area to access phy registers.
> + * @dev: Kernel device used to output prefixed debug info.
> + * @reset: Reset control corresponding to the phy instance.
> + * @clocks: All clocks required for the phy to operate.
> + * @da_war: Enables work-around for 10GBase-R mode.
> + */
> +struct mtk_xfi_tphy {
> + void __iomem *base;
> + struct device *dev;
> + struct reset_control *reset;
> + struct clk_bulk_data clocks[MTK_XFI_TPHY_NUM_CLOCKS];
> + bool da_war;
> +};
> +
> +/**
> + * mtk_xfi_tphy_setup() - Setup phy for specified interface mode.
> + * @xfi_tphy: XFI phy instance.
> + * @interface: Ethernet interface mode
> + *
> + * The setup function is the condensed result of combining the 5 functions which
> + * setup the phy in MediaTek's GPL licensed public SDK sources. They can be found
> + * in mtk_sgmii.c[1] as well as mtk_usxgmii.c[2].
> + *
> + * Many magic values have been replaced by register and bit definitions, however,
> + * that has not been possible in all cases. While the vendor driver uses a
> + * sequence of 32-bit writes, here we try to only modify the actually required
> + * bits.
> + *
> + * [1]: https://git01.mediatek.com/plugins/gitiles/openwrt/feeds/mtk-openwrt-feeds/+/b72d6cba92bf9e29fb035c03052fa1e86664a25b/21.02/files/target/linux/mediatek/files-5.4/drivers/net/ethernet/mediatek/mtk_sgmii.c
> + *
> + * [2]: https://git01.mediatek.com/plugins/gitiles/openwrt/feeds/mtk-openwrt-feeds/+/dec96a1d9b82cdcda4a56453fd0b453d4cab4b85/21.02/files/target/linux/mediatek/files-5.4/drivers/net/ethernet/mediatek/mtk_eth_soc.c
> + */
> +static void mtk_xfi_tphy_setup(struct mtk_xfi_tphy *xfi_tphy,
> + phy_interface_t interface)
> +{
> + bool is_1g, is_2p5g, is_5g, is_10g, da_war, use_lynxi_pcs;
> +
> + /* shorthands for specific clock speeds depending on interface mode */
> + is_1g = interface == PHY_INTERFACE_MODE_1000BASEX ||
> + interface == PHY_INTERFACE_MODE_SGMII;
> + is_2p5g = interface == PHY_INTERFACE_MODE_2500BASEX;
> + is_5g = interface == PHY_INTERFACE_MODE_5GBASER;
> + is_10g = interface == PHY_INTERFACE_MODE_10GBASER ||
> + interface == PHY_INTERFACE_MODE_USXGMII;
> +
> + /* Is overriding 10GBase-R tuning value required? */
> + da_war = xfi_tphy->da_war && (interface == PHY_INTERFACE_MODE_10GBASER);
> +
> + /* configure input mux to either
> + * - USXGMII PCS (64b/66b coding) for 5G/10G
> + * - LynxI PCS (8b/10b coding) for 1G/2.5G
> + */
> + use_lynxi_pcs = is_1g || is_2p5g;
> +
> + dev_dbg(xfi_tphy->dev, "setting up for mode %s\n", phy_modes(interface));
> +
> + /* Setup PLL setting */
> + mtk_phy_update_bits(xfi_tphy->base + 0x9024, 0x100000, is_10g ? 0x0 : 0x100000);
> + mtk_phy_update_bits(xfi_tphy->base + 0x2020, 0x202000, is_5g ? 0x202000 : 0x0);
> + mtk_phy_update_bits(xfi_tphy->base + 0x2030, 0x500, is_1g ? 0x0 : 0x500);
> + mtk_phy_update_bits(xfi_tphy->base + 0x2034, 0xa00, is_1g ? 0x0 : 0xa00);
> + mtk_phy_update_bits(xfi_tphy->base + 0x2040, 0x340000, is_1g ? 0x200000 : 0x140000);
> +
> + /* Setup RXFE BW setting */
> + mtk_phy_update_bits(xfi_tphy->base + 0x50f0, 0xc10, is_1g ? 0x410 : is_5g ? 0x800 : 0x400);
> + mtk_phy_update_bits(xfi_tphy->base + 0x50e0, 0x4000, is_5g ? 0x0 : 0x4000);
> +
> + /* Setup RX CDR setting */
> + mtk_phy_update_bits(xfi_tphy->base + 0x506c, 0x30000, is_5g ? 0x0 : 0x30000);
> + mtk_phy_update_bits(xfi_tphy->base + 0x5070, 0x670000, is_5g ? 0x620000 : 0x50000);
> + mtk_phy_update_bits(xfi_tphy->base + 0x5074, 0x180000, is_5g ? 0x180000 : 0x0);
> + mtk_phy_update_bits(xfi_tphy->base + 0x5078, 0xf000400, is_5g ? 0x8000000 :
> + 0x7000400);
> + mtk_phy_update_bits(xfi_tphy->base + 0x507c, 0x5000500, is_5g ? 0x4000400 :
> + 0x1000100);
> + mtk_phy_update_bits(xfi_tphy->base + 0x5080, 0x1410, is_1g ? 0x400 : is_5g ? 0x1010 : 0x0);
> + mtk_phy_update_bits(xfi_tphy->base + 0x5084, 0x30300, is_1g ? 0x30300 :
> + is_5g ? 0x30100 :
> + 0x100);
> + mtk_phy_update_bits(xfi_tphy->base + 0x5088, 0x60200, is_1g ? 0x20200 :
> + is_5g ? 0x40000 :
> + 0x20000);
> +
> + /* Setting RXFE adaptation range setting */
> + mtk_phy_update_bits(xfi_tphy->base + 0x50e4, 0xc0000, is_5g ? 0x0 : 0xc0000);
> + mtk_phy_update_bits(xfi_tphy->base + 0x50e8, 0x40000, is_5g ? 0x0 : 0x40000);
> + mtk_phy_update_bits(xfi_tphy->base + 0x50ec, 0xa00, is_1g ? 0x200 : 0x800);
> + mtk_phy_update_bits(xfi_tphy->base + 0x50a8, 0xee0000, is_5g ? 0x800000 :
> + 0x6e0000);
> + mtk_phy_update_bits(xfi_tphy->base + 0x6004, 0x190000, is_5g ? 0x0 : 0x190000);
> +
> + if (is_10g)
> + writel(0x01423342, xfi_tphy->base + 0x00f8);
> + else if (is_5g)
> + writel(0x00a132a1, xfi_tphy->base + 0x00f8);
> + else if (is_2p5g)
> + writel(0x009c329c, xfi_tphy->base + 0x00f8);
> + else
> + writel(0x00fa32fa, xfi_tphy->base + 0x00f8);
> +
> + /* Force SGDT_OUT off and select PCS */
> + mtk_phy_update_bits(xfi_tphy->base + REG_DIG_GLB_F4,
> + XFI_DPHY_AD_SGDT_FRC_EN | XFI_DPHY_PCS_SEL,
> + XFI_DPHY_AD_SGDT_FRC_EN |
> + (use_lynxi_pcs ? XFI_DPHY_PCS_SEL_SGMII :
> + XFI_DPHY_PCS_SEL_USXGMII));
> +
> + /* Force GLB_CKDET_OUT */
> + mtk_phy_set_bits(xfi_tphy->base + 0x0030, 0xc00);
> +
> + /* Force AEQ on */
> + writel(XTP_PCS_RX_EQ_IN_PROGRESS(2) | XTP_PCS_PWD_SYNC(2) | XTP_PCS_PWD_ASYNC(2),
> + xfi_tphy->base + REG_DIG_GLB_70);
> +
> + usleep_range(1, 5);
> + writel(XTP_LN_FRC_TX_DATA_EN, xfi_tphy->base + REG_DIG_LN_TRX_40);
> +
> + /* Setup TX DA default value */
> + mtk_phy_update_bits(xfi_tphy->base + 0x30b0, 0x30, 0x20);
> + writel(0x00008a01, xfi_tphy->base + 0x3028);
> + writel(0x0000a884, xfi_tphy->base + 0x302c);
> + writel(0x00083002, xfi_tphy->base + 0x3024);
> +
> + /* Setup RG default value */
> + if (use_lynxi_pcs) {
> + writel(0x00011110, xfi_tphy->base + 0x3010);
> + writel(0x40704000, xfi_tphy->base + 0x3048);
> + } else {
> + writel(0x00022220, xfi_tphy->base + 0x3010);
> + writel(0x0f020a01, xfi_tphy->base + 0x5064);
> + writel(0x06100600, xfi_tphy->base + 0x50b4);
> + if (interface == PHY_INTERFACE_MODE_USXGMII)
> + writel(0x40704000, xfi_tphy->base + 0x3048);
> + else
> + writel(0x47684100, xfi_tphy->base + 0x3048);
> + }
> +
> + if (is_1g)
> + writel(0x0000c000, xfi_tphy->base + 0x3064);
> +
> + /* Setup RX EQ initial value */
> + mtk_phy_update_bits(xfi_tphy->base + 0x3050, 0xa8000000,
> + (interface != PHY_INTERFACE_MODE_10GBASER) ? 0xa8000000 : 0x0);
> + mtk_phy_update_bits(xfi_tphy->base + 0x3054, 0xaa,
> + (interface != PHY_INTERFACE_MODE_10GBASER) ? 0xaa : 0x0);
> +
> + if (!use_lynxi_pcs)
> + writel(0x00000f00, xfi_tphy->base + 0x306c);
> + else if (is_2p5g)
> + writel(0x22000f00, xfi_tphy->base + 0x306c);
> + else
> + writel(0x20200f00, xfi_tphy->base + 0x306c);
> +
> + mtk_phy_update_bits(xfi_tphy->base + 0xa008, 0x10000, da_war ? 0x10000 : 0x0);
> +
> + mtk_phy_update_bits(xfi_tphy->base + 0xa060, 0x50000, use_lynxi_pcs ? 0x50000 : 0x40000);
> +
> + /* Setup PHYA speed */
> + mtk_phy_update_bits(xfi_tphy->base + REG_ANA_GLB_D0,
> + XTP_GLB_USXGMII_SEL_MASK | XTP_GLB_USXGMII_EN,
> + is_10g ? XTP_GLB_USXGMII_SEL(0) :
> + is_5g ? XTP_GLB_USXGMII_SEL(1) :
> + is_2p5g ? XTP_GLB_USXGMII_SEL(2) :
> + XTP_GLB_USXGMII_SEL(3));
> + mtk_phy_set_bits(xfi_tphy->base + REG_ANA_GLB_D0, XTP_GLB_USXGMII_EN);
> +
> + /* Release reset */
> + mtk_phy_set_bits(xfi_tphy->base + REG_DIG_GLB_70,
> + XTP_PCS_RST_B | XTP_FRC_PCS_RST_B);
> + usleep_range(150, 500);
> +
> + /* Switch to P0 */
> + mtk_phy_update_bits(xfi_tphy->base + REG_DIG_GLB_70,
> + XTP_PCS_IN_FR_RG |
> + XTP_FRC_PCS_PWD_ASYNC |
> + XTP_PCS_PWD_ASYNC_MASK |
> + XTP_PCS_PWD_SYNC_MASK |
> + XTP_PCS_UPDT,
> + XTP_PCS_IN_FR_RG |
> + XTP_FRC_PCS_PWD_ASYNC |
> + XTP_PCS_UPDT);
> + usleep_range(1, 5);
> +
> + mtk_phy_clear_bits(xfi_tphy->base + REG_DIG_GLB_70, XTP_PCS_UPDT);
> + usleep_range(15, 50);
> +
> + if (use_lynxi_pcs) {
> + /* Switch to Gen2 */
> + mtk_phy_update_bits(xfi_tphy->base + REG_DIG_GLB_70,
> + XTP_PCS_MODE_MASK | XTP_PCS_UPDT,
> + XTP_PCS_MODE(1) | XTP_PCS_UPDT);
> + } else {
> + /* Switch to Gen3 */
> + mtk_phy_update_bits(xfi_tphy->base + REG_DIG_GLB_70,
> + XTP_PCS_MODE_MASK | XTP_PCS_UPDT,
> + XTP_PCS_MODE(2) | XTP_PCS_UPDT);
> + }
> + usleep_range(1, 5);
> +
> + mtk_phy_clear_bits(xfi_tphy->base + REG_DIG_GLB_70, XTP_PCS_UPDT);
> +
> + usleep_range(100, 500);
> +
> + /* Enable MAC CK */
> + mtk_phy_set_bits(xfi_tphy->base + REG_DIG_LN_TRX_B0, XTP_LN_TX_MACCK_EN);
> + mtk_phy_clear_bits(xfi_tphy->base + REG_DIG_GLB_F4, XFI_DPHY_AD_SGDT_FRC_EN);
> +
> + /* Enable TX data */
> + mtk_phy_set_bits(xfi_tphy->base + REG_DIG_LN_TRX_40,
> + XTP_LN_FRC_TX_DATA_EN | XTP_LN_TX_DATA_EN);
> + usleep_range(400, 1000);
> +}
> +
> +/**
> + * mtk_xfi_tphy_set_mode() - Setup phy for specified interface mode.
> + *
> + * @phy: Phy instance.
> + * @mode: Only PHY_MODE_ETHERNET is supported.
> + * @submode: An Ethernet interface mode.
> + *
> + * Validate selected mode and call function mtk_xfi_tphy_setup().
> + *
> + * Return:
> + * * %0 - OK
> + * * %-EINVAL - invalid mode
> + */
> +static int mtk_xfi_tphy_set_mode(struct phy *phy, enum phy_mode mode, int
> + submode)
> +{
> + struct mtk_xfi_tphy *xfi_tphy = phy_get_drvdata(phy);
> +
> + if (mode != PHY_MODE_ETHERNET)
> + return -EINVAL;
> +
> + switch (submode) {
> + case PHY_INTERFACE_MODE_1000BASEX:
> + case PHY_INTERFACE_MODE_2500BASEX:
> + case PHY_INTERFACE_MODE_SGMII:
> + case PHY_INTERFACE_MODE_5GBASER:
> + case PHY_INTERFACE_MODE_10GBASER:
> + case PHY_INTERFACE_MODE_USXGMII:
> + mtk_xfi_tphy_setup(xfi_tphy, submode);
> + return 0;
> + default:
> + return -EINVAL;
> + }
> +}
> +
> +/**
> + * mtk_xfi_tphy_reset() - Reset the phy.
> + *
> + * @phy: Phy instance.
> + *
> + * Reset the phy using the external reset controller.
> + *
> + * Return:
> + * %0 - OK
> + */
> +static int mtk_xfi_tphy_reset(struct phy *phy)
> +{
> + struct mtk_xfi_tphy *xfi_tphy = phy_get_drvdata(phy);
> +
> + reset_control_assert(xfi_tphy->reset);
> + usleep_range(100, 500);
> + reset_control_deassert(xfi_tphy->reset);
> + usleep_range(1, 10);
> +
> + return 0;
> +}
> +
> +/**
> + * mtk_xfi_tphy_power_on() - Power-on the phy.
> + *
> + * @phy: Phy instance.
> + *
> + * Prepare and enable all clocks required for the phy to operate.
> + *
> + * Return:
> + * See clk_bulk_prepare_enable().
> + */
> +static int mtk_xfi_tphy_power_on(struct phy *phy)
> +{
> + struct mtk_xfi_tphy *xfi_tphy = phy_get_drvdata(phy);
> +
> + return clk_bulk_prepare_enable(MTK_XFI_TPHY_NUM_CLOCKS, xfi_tphy->clocks);
> +}
> +
> +/**
> + * mtk_xfi_tphy_power_off() - Power-off the phy.
> + *
> + * @phy: Phy instance.
> + *
> + * Disable and unprepare all clocks previously enabled.
> + *
> + * Return:
> + * See clk_bulk_prepare_disable().
> + */
> +static int mtk_xfi_tphy_power_off(struct phy *phy)
> +{
> + struct mtk_xfi_tphy *xfi_tphy = phy_get_drvdata(phy);
> +
> + clk_bulk_disable_unprepare(MTK_XFI_TPHY_NUM_CLOCKS, xfi_tphy->clocks);
> +
> + return 0;
> +}
> +
> +static const struct phy_ops mtk_xfi_tphy_ops = {
> + .power_on = mtk_xfi_tphy_power_on,
> + .power_off = mtk_xfi_tphy_power_off,
> + .set_mode = mtk_xfi_tphy_set_mode,
> + .reset = mtk_xfi_tphy_reset,
> + .owner = THIS_MODULE,
> +};
> +
> +/**
> + * mtk_xfi_tphy_probe() - Probe phy instance from Device Tree.
> + * @pdev: Matching platform device.
> + *
> + * The probe function gets IO resource, clocks, reset controller and
> + * whether the DA work-around for 10GBase-R is required from Device Tree and
> + * allocates memory for holding that information in a struct mtk_xfi_tphy.
> + *
> + * Return:
> + * * %0 - OK
> + * * %-ENODEV - Missing associated Device Tree node (should never happen).
> + * * %-ENOMEM - Out of memory.
> + * * Any error value which devm_platform_ioremap_resource(),
> + * devm_clk_bulk_get(), devm_reset_control_get_exclusive(),
> + * devm_phy_create() or devm_of_phy_provider_register() may return.
> + */
> +static int mtk_xfi_tphy_probe(struct platform_device *pdev)
> +{
> + struct device_node *np = pdev->dev.of_node;
> + struct phy_provider *phy_provider;
> + struct mtk_xfi_tphy *xfi_tphy;
> + struct phy *phy;
> + int ret;
> +
> + if (!np)
> + return -ENODEV;
> +
> + xfi_tphy = devm_kzalloc(&pdev->dev, sizeof(*xfi_tphy), GFP_KERNEL);
> + if (!xfi_tphy)
> + return -ENOMEM;
> +
> + xfi_tphy->base = devm_platform_ioremap_resource(pdev, 0);
> + if (IS_ERR(xfi_tphy->base))
> + return PTR_ERR(xfi_tphy->base);
> +
> + xfi_tphy->dev = &pdev->dev;
> + xfi_tphy->clocks[0].id = "topxtal";
> + xfi_tphy->clocks[1].id = "xfipll";
> + ret = devm_clk_bulk_get(&pdev->dev, MTK_XFI_TPHY_NUM_CLOCKS, xfi_tphy->clocks);
> + if (ret)
> + return ret;
> +
> + xfi_tphy->reset = devm_reset_control_get_exclusive(&pdev->dev, NULL);
> + if (IS_ERR(xfi_tphy->reset))
> + return PTR_ERR(xfi_tphy->reset);
> +
> + xfi_tphy->da_war = of_property_read_bool(np, "mediatek,usxgmii-performance-errata");
> +
> + phy = devm_phy_create(&pdev->dev, NULL, &mtk_xfi_tphy_ops);
> + if (IS_ERR(phy))
> + return PTR_ERR(phy);
> +
> + phy_set_drvdata(phy, xfi_tphy);
> + phy_provider = devm_of_phy_provider_register(&pdev->dev, of_phy_simple_xlate);
> +
> + return PTR_ERR_OR_ZERO(phy_provider);
> +}
> +
> +static const struct of_device_id mtk_xfi_tphy_match[] = {
> + { .compatible = "mediatek,mt7988-xfi-tphy", },
> + { /* sentinel */ }
> +};
> +MODULE_DEVICE_TABLE(of, mtk_xfi_tphy_match);
> +
> +static struct platform_driver mtk_xfi_tphy_driver = {
> + .probe = mtk_xfi_tphy_probe,
> + .driver = {
> + .name = "mtk-xfi-tphy",
> + .of_match_table = mtk_xfi_tphy_match,
> + },
> +};
> +module_platform_driver(mtk_xfi_tphy_driver);
> +
> +MODULE_DESCRIPTION("MediaTek 10GE SerDes XFI T-PHY driver");
> +MODULE_AUTHOR("Daniel Golle <daniel@makrotopia.org>");
> +MODULE_AUTHOR("Bc-bocun Chen <bc-bocun.chen@mediatek.com>");
> +MODULE_LICENSE("GPL");
^ permalink raw reply
* Re: [PATCH v4 1/2] dt-bindings: phy: mediatek,mt7988-xfi-tphy: add new bindings
From: Jacob Keller @ 2024-04-10 0:16 UTC (permalink / raw)
To: Daniel Golle, Vinod Koul, Bc-bocun Chen, Steven Liu, John Crispin,
Chunfeng Yun, Kishon Vijay Abraham I, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Matthias Brugger,
AngeloGioacchino Del Regno, Qingfang Deng, SkyLake Huang,
Philipp Zabel, linux-arm-kernel, linux-mediatek, linux-phy,
devicetree, linux-kernel, netdev
In-Reply-To: <da5498096f71a40ca1eac4124b7bb601c82396fb.1712625857.git.daniel@makrotopia.org>
On 4/8/2024 7:23 PM, Daniel Golle wrote:
> Add bindings for the MediaTek XFI Ethernet SerDes T-PHY found in the
> MediaTek MT7988 SoC which can operate at various interfaces modes:
>
> via USXGMII PCS:
> * USXGMII
> * 10GBase-R
> * 5GBase-R
>
> via LynxI SGMII PCS:
> * 2500Base-X
> * 1000Base-X
> * Cisco SGMII (MAC side)
>
> Signed-off-by: Daniel Golle <daniel@makrotopia.org>
> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Reviewed-by: Jacob Keller <jacob.e.keller@intel.com>
^ permalink raw reply
* RE: [PATCH v5 0/7] PCI: dwc: rcar-gen4: Add R-Car V4H support
From: Yoshihiro Shimoda @ 2024-04-10 0:32 UTC (permalink / raw)
To: Bjorn Helgaas
Cc: lpieralisi@kernel.org, kw@linux.com, robh@kernel.org,
bhelgaas@google.com, krzysztof.kozlowski+dt@linaro.org,
conor+dt@kernel.org, jingoohan1@gmail.com, mani@kernel.org,
marek.vasut+renesas@gmail.com, linux-pci@vger.kernel.org,
devicetree@vger.kernel.org, linux-renesas-soc@vger.kernel.org
In-Reply-To: <20240409132808.GA2071934@bhelgaas>
Hi Bjorn,
> From: Bjorn Helgaas, Sent: Tuesday, April 9, 2024 10:28 PM
>
> On Mon, Apr 08, 2024 at 10:24:51AM +0900, Yoshihiro Shimoda wrote:
>
> > Yoshihiro Shimoda (7):
> > dt-bindings: PCI: rcar-gen4-pci-host: Add R-Car V4H compatible
> > dt-bindings: PCI: rcar-gen4-pci-ep: Add R-Car V4H compatible
> > PCI: dwc: Add PCIE_PORT_{FORCE,LANE_SKEW} macros
> > PCI: dwc: rcar-gen4: Add rcar_gen4_pcie_platdata
> > PCI: dwc: rcar-gen4: Add .ltssm_enable() for other SoC support
> > PCI: dwc: rcar-gen4: Add support for r8a779g0
>
> Previous history for this file uses a "PCI: rcar-gen4: " prefix
> (without "dwc:"). I don't think we need to replicate the whole file
> path here in the precious subject line space, so "PCI: rcar-gen4: "
> should be enough.
Oops. I'll fix the subjects.
Best regards,
Yoshihiro Shimoda
> > misc: pci_endpoint_test: Document a policy about adding pci_device_id
> >
> > .../bindings/pci/rcar-gen4-pci-ep.yaml | 4 +-
> > .../bindings/pci/rcar-gen4-pci-host.yaml | 4 +-
> > drivers/misc/pci_endpoint_test.c | 1 +
> > drivers/pci/controller/dwc/pcie-designware.h | 6 +
> > drivers/pci/controller/dwc/pcie-rcar-gen4.c | 272 +++++++++++++++++-
> > 5 files changed, 270 insertions(+), 17 deletions(-)
> >
> > --
> > 2.25.1
> >
^ permalink raw reply
* Re: (subset) [PATCH 1/2] arm64: dts: ti: k3-am62p5-sk: minor whitespace cleanup
From: Nishanth Menon @ 2024-04-10 0:39 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Benoît Cousson, Tony Lindgren, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Vignesh Raghavendra,
Tero Kristo, linux-omap, devicetree, linux-kernel,
linux-arm-kernel
In-Reply-To: <63fc911e-8906-43d0-a4bf-80ceac83d178@linaro.org>
On 22:04-20240409, Krzysztof Kozlowski wrote:
> On 09/04/2024 21:36, Nishanth Menon wrote:
> > Hi Krzysztof Kozlowski,
> >
> > On Thu, 08 Feb 2024 11:51:45 +0100, Krzysztof Kozlowski wrote:
> >> The DTS code coding style expects exactly one space before '{'
> >> character.
> >>
> >>
> > As discussed offline, I am picking this patch up.
> >
> > I have applied the following to branch ti-k3-dts-next on [1].
> > Thank you!
> >
> > [1/2] arm64: dts: ti: k3-am62p5-sk: minor whitespace cleanup
> > commit: 45ab8daed512258c07fd14536a3633440dabfe84
>
> What about the omap one (second in the series)? Shall I take it?
I had poked Tony about it (he is the maintainer for OMAP). Tony: could
you comment?
--
Regards,
Nishanth Menon
Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3 1A34 DDB5 849D 1736 249D
^ permalink raw reply
* Re: [RFC PATCH v2 0/2] fw_devlink overlay fix
From: Saravana Kannan @ 2024-04-10 0:41 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Herve Codina, Rob Herring, kernel-team, linux-kernel, imx,
linux-arm-kernel, linux-i2c, devicetree, linux-spi, linux-acpi
In-Reply-To: <CAMuHMdVL4xUMARcze=ZyZA=Hi3=nvfZ34juSKG7cgA5ygxASaw@mail.gmail.com>
On Tue, Apr 9, 2024 at 8:10 AM Geert Uytterhoeven <geert@linux-m68k.org> wrote:
>
> Hi Saravana,
>
> On Tue, Apr 9, 2024 at 7:37 AM Saravana Kannan <saravanak@google.com> wrote:
> > Don't bother reviewing this patch. It needs to be tested and possibly
> > refactored first.
> >
> > Geert and Herve,
> >
> > This patch serious should hopefully fix both of your use cases
> > [1][2][3]. Can you please check to make sure the device links created
> > to/from the overlay devices are to/from the right ones?
>
> Thanks for your series!
>
> After applying the first patch (the revert), the issue reported in
> [1] is back, as expected.
> After applying both patches, applying[A]/unapplying[B]/reapplying[C]
> overlay [4] works as without this series, so
> Tested-by: Geert Uytterhoeven <geert+renesas@glider.be>
>
> Note that the state of /sys/class/devlink/ after [C] is still not the
> same as after [A], as reported before in [5]:
> - platform:e6060000.pinctrl--platform:keys link is not recreated in [B],
> - nothing changes in /sys/class/devlink in [C].
> But that issue is not introduced in this series.
Thanks for the testing and additional info! Looks like I'll need to
make more changes to accommodate more cases. I'll send out v3 once I
figure it out, but it should continue working for you.
-Saravana
>
> > [1] - https://lore.kernel.org/lkml/CAMuHMdXEnSD4rRJ-o90x4OprUacN_rJgyo8x6=9F9rZ+-KzjOg@mail.gmail.com/
>
> [4] "arm64: dts: renesas: ebisu: cn41: Add overlay for MSIOF0 and 25LC040"
> https://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-drivers.git/commit/?h=topic/renesas-overlays&id=222a4936b0d3dabd43bdffb3a578423bff97b02d
> [5] https://lore.kernel.org/lkml/CAMuHMdXNoYH8PJE1xb4PK-vzjXtOzrxNJoZhsHT-H4Ucm=7_ig@mail.gmail.com/
>
> Gr{oetje,eeting}s,
>
> Geert
>
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
>
> In personal conversations with technical people, I call myself a hacker. But
> when I'm talking to journalists I just say "programmer" or something like that.
> -- Linus Torvalds
^ permalink raw reply
* [PATCH v6 1/7] dt-bindings: PCI: rcar-gen4-pci-host: Add R-Car V4H compatible
From: Yoshihiro Shimoda @ 2024-04-10 0:48 UTC (permalink / raw)
To: lpieralisi, kw, robh, bhelgaas, krzysztof.kozlowski+dt, conor+dt,
jingoohan1, mani
Cc: marek.vasut+renesas, linux-pci, devicetree, linux-renesas-soc,
Yoshihiro Shimoda, Conor Dooley, Geert Uytterhoeven
In-Reply-To: <20240410004832.3726922-1-yoshihiro.shimoda.uh@renesas.com>
Document bindings for R-Car V4H (R8A779G0) PCIe host module.
Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
Acked-by: Conor Dooley <conor.dooley@microchip.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
---
Documentation/devicetree/bindings/pci/rcar-gen4-pci-host.yaml | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/pci/rcar-gen4-pci-host.yaml b/Documentation/devicetree/bindings/pci/rcar-gen4-pci-host.yaml
index ffb34339b637..955c664f1fbb 100644
--- a/Documentation/devicetree/bindings/pci/rcar-gen4-pci-host.yaml
+++ b/Documentation/devicetree/bindings/pci/rcar-gen4-pci-host.yaml
@@ -16,7 +16,9 @@ allOf:
properties:
compatible:
items:
- - const: renesas,r8a779f0-pcie # R-Car S4-8
+ - enum:
+ - renesas,r8a779f0-pcie # R-Car S4-8
+ - renesas,r8a779g0-pcie # R-Car V4H
- const: renesas,rcar-gen4-pcie # R-Car Gen4
reg:
--
2.25.1
^ permalink raw reply related
* [PATCH v6 0/7] PCI: rcar-gen4: Add R-Car V4H support
From: Yoshihiro Shimoda @ 2024-04-10 0:48 UTC (permalink / raw)
To: lpieralisi, kw, robh, bhelgaas, krzysztof.kozlowski+dt, conor+dt,
jingoohan1, mani
Cc: marek.vasut+renesas, linux-pci, devicetree, linux-renesas-soc,
Yoshihiro Shimoda
The pcie-rcar-gen4 driver can reuse other R-Car Gen4 support like
r8a779g0 (R-Car V4H) and r8a779h0 (R-Car V4M). However, some
initializing settings differ between R-Car S4-8 (r8a779f0) and
others. The R-Car S4-8 will be minority about the setting way. So,
R-Car V4H will be majority and this is generic initialization way
as "renesas,rcar-gen4-pcie{-ep}" compatible. For now, I tested
both R-Car S4-8 and R-Car V4H on this driver. I'll support one more
other SoC (R-Car V4M) in the future.
Changes from v5:
https://lore.kernel.org/linux-pci/20240408012458.3717977-1-yoshihiro.shimoda.uh@renesas.com/
- Drop "dwc: " prefixes from the subjects in patch [0456]/7.
Changes from v4:
https://lore.kernel.org/linux-pci/20240403053304.3695096-1-yoshihiro.shimoda.uh@renesas.com/
- Fix compatible string for renesas,r8a779f0-pcie-ep which was described
accidentally from v3...
Changes from v3:
https://lore.kernel.org/linux-pci/20240401023942.134704-1-yoshihiro.shimoda.uh@renesas.com/
- Modify the code to use "do .. while" instead of goto in patch 6/7.
Changes from v2:
https://lore.kernel.org/linux-pci/20240326024540.2336155-1-yoshihiro.shimoda.uh@renesas.com/
- Add a new patch which just add a platdata in patch 4/7.
- Modify the subjects in patch [56]/7.
- Modify the description and code about Bjorn's comment in patch [56]/7.
- Add missing MODULE_FIRMWARE(9 in patch 6/7.
- Document a policy aboud adding pci_device_id instead of adding r8a779g0's id
in patch 7/7.
Changes from v1:
https://lore.kernel.org/linux-pci/20240229120719.2553638-1-yoshihiro.shimoda.uh@renesas.com/
- Based on v6.9-rc1.
- Add Acked-by and/or Reviewed-by in patch [126/6].
Yoshihiro Shimoda (7):
dt-bindings: PCI: rcar-gen4-pci-host: Add R-Car V4H compatible
dt-bindings: PCI: rcar-gen4-pci-ep: Add R-Car V4H compatible
PCI: dwc: Add PCIE_PORT_{FORCE,LANE_SKEW} macros
PCI: rcar-gen4: Add rcar_gen4_pcie_platdata
PCI: rcar-gen4: Add .ltssm_enable() for other SoC support
PCI: rcar-gen4: Add support for r8a779g0
misc: pci_endpoint_test: Document a policy about adding pci_device_id
.../bindings/pci/rcar-gen4-pci-ep.yaml | 4 +-
.../bindings/pci/rcar-gen4-pci-host.yaml | 4 +-
drivers/misc/pci_endpoint_test.c | 1 +
drivers/pci/controller/dwc/pcie-designware.h | 6 +
drivers/pci/controller/dwc/pcie-rcar-gen4.c | 272 +++++++++++++++++-
5 files changed, 270 insertions(+), 17 deletions(-)
--
2.25.1
^ permalink raw reply
* [PATCH v6 2/7] dt-bindings: PCI: rcar-gen4-pci-ep: Add R-Car V4H compatible
From: Yoshihiro Shimoda @ 2024-04-10 0:48 UTC (permalink / raw)
To: lpieralisi, kw, robh, bhelgaas, krzysztof.kozlowski+dt, conor+dt,
jingoohan1, mani
Cc: marek.vasut+renesas, linux-pci, devicetree, linux-renesas-soc,
Yoshihiro Shimoda, Conor Dooley, Geert Uytterhoeven
In-Reply-To: <20240410004832.3726922-1-yoshihiro.shimoda.uh@renesas.com>
Document bindings for R-Car V4H (R8A779G0) PCIe endpoint module.
Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
Acked-by: Conor Dooley <conor.dooley@microchip.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
---
Documentation/devicetree/bindings/pci/rcar-gen4-pci-ep.yaml | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/pci/rcar-gen4-pci-ep.yaml b/Documentation/devicetree/bindings/pci/rcar-gen4-pci-ep.yaml
index fe38f62da066..91b81ac75592 100644
--- a/Documentation/devicetree/bindings/pci/rcar-gen4-pci-ep.yaml
+++ b/Documentation/devicetree/bindings/pci/rcar-gen4-pci-ep.yaml
@@ -16,7 +16,9 @@ allOf:
properties:
compatible:
items:
- - const: renesas,r8a779f0-pcie-ep # R-Car S4-8
+ - enum:
+ - renesas,r8a779f0-pcie-ep # R-Car S4-8
+ - renesas,r8a779g0-pcie-ep # R-Car V4H
- const: renesas,rcar-gen4-pcie-ep # R-Car Gen4
reg:
--
2.25.1
^ permalink raw reply related
* [PATCH v6 3/7] PCI: dwc: Add PCIE_PORT_{FORCE,LANE_SKEW} macros
From: Yoshihiro Shimoda @ 2024-04-10 0:48 UTC (permalink / raw)
To: lpieralisi, kw, robh, bhelgaas, krzysztof.kozlowski+dt, conor+dt,
jingoohan1, mani
Cc: marek.vasut+renesas, linux-pci, devicetree, linux-renesas-soc,
Yoshihiro Shimoda
In-Reply-To: <20240410004832.3726922-1-yoshihiro.shimoda.uh@renesas.com>
R-Car Gen4 PCIe controller needs to use the Synopsys-specific PCIe
configuration registers. So, add the macros.
Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
---
drivers/pci/controller/dwc/pcie-designware.h | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/drivers/pci/controller/dwc/pcie-designware.h b/drivers/pci/controller/dwc/pcie-designware.h
index 26dae4837462..aa4db6eaf02a 100644
--- a/drivers/pci/controller/dwc/pcie-designware.h
+++ b/drivers/pci/controller/dwc/pcie-designware.h
@@ -71,6 +71,9 @@
#define LINK_WAIT_IATU 9
/* Synopsys-specific PCIe configuration registers */
+#define PCIE_PORT_FORCE 0x708
+#define PORT_FORCE_DO_DESKEW_FOR_SRIS BIT(23)
+
#define PCIE_PORT_AFR 0x70C
#define PORT_AFR_N_FTS_MASK GENMASK(15, 8)
#define PORT_AFR_N_FTS(n) FIELD_PREP(PORT_AFR_N_FTS_MASK, n)
@@ -92,6 +95,9 @@
#define PORT_LINK_MODE_4_LANES PORT_LINK_MODE(0x7)
#define PORT_LINK_MODE_8_LANES PORT_LINK_MODE(0xf)
+#define PCIE_PORT_LANE_SKEW 0x714
+#define PORT_LANE_SKEW_INSERT_MASK GENMASK(23, 0)
+
#define PCIE_PORT_DEBUG0 0x728
#define PORT_LOGIC_LTSSM_STATE_MASK 0x1f
#define PORT_LOGIC_LTSSM_STATE_L0 0x11
--
2.25.1
^ permalink raw reply related
* [PATCH v6 4/7] PCI: rcar-gen4: Add rcar_gen4_pcie_platdata
From: Yoshihiro Shimoda @ 2024-04-10 0:48 UTC (permalink / raw)
To: lpieralisi, kw, robh, bhelgaas, krzysztof.kozlowski+dt, conor+dt,
jingoohan1, mani
Cc: marek.vasut+renesas, linux-pci, devicetree, linux-renesas-soc,
Yoshihiro Shimoda
In-Reply-To: <20240410004832.3726922-1-yoshihiro.shimoda.uh@renesas.com>
This driver supports r8a779f0 now. In the future, add support for
r8a779g0 and r8a779h0. To support these new SoCs, need other
initializing settings. So, at first, add rcar_gen4_pcie_platdata
and have a member with mode. No behavior changes.
Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
---
drivers/pci/controller/dwc/pcie-rcar-gen4.c | 30 ++++++++++++++-------
1 file changed, 21 insertions(+), 9 deletions(-)
diff --git a/drivers/pci/controller/dwc/pcie-rcar-gen4.c b/drivers/pci/controller/dwc/pcie-rcar-gen4.c
index 0be760ed420b..da2821d6efce 100644
--- a/drivers/pci/controller/dwc/pcie-rcar-gen4.c
+++ b/drivers/pci/controller/dwc/pcie-rcar-gen4.c
@@ -48,11 +48,15 @@
#define RCAR_GEN4_PCIE_EP_FUNC_DBI_OFFSET 0x1000
#define RCAR_GEN4_PCIE_EP_FUNC_DBI2_OFFSET 0x800
+struct rcar_gen4_pcie_platdata {
+ enum dw_pcie_device_mode mode;
+};
+
struct rcar_gen4_pcie {
struct dw_pcie dw;
void __iomem *base;
struct platform_device *pdev;
- enum dw_pcie_device_mode mode;
+ const struct rcar_gen4_pcie_platdata *platdata;
};
#define to_rcar_gen4_pcie(_dw) container_of(_dw, struct rcar_gen4_pcie, dw)
@@ -137,7 +141,7 @@ static int rcar_gen4_pcie_start_link(struct dw_pcie *dw)
* Since dw_pcie_setup_rc() sets it once, PCIe Gen2 will be trained.
* So, this needs remaining times for up to PCIe Gen4 if RC mode.
*/
- if (changes && rcar->mode == DW_PCIE_RC_TYPE)
+ if (changes && rcar->platdata->mode == DW_PCIE_RC_TYPE)
changes--;
for (i = 0; i < changes; i++) {
@@ -172,9 +176,9 @@ static int rcar_gen4_pcie_common_init(struct rcar_gen4_pcie *rcar)
reset_control_assert(dw->core_rsts[DW_PCIE_PWR_RST].rstc);
val = readl(rcar->base + PCIEMSR0);
- if (rcar->mode == DW_PCIE_RC_TYPE) {
+ if (rcar->platdata->mode == DW_PCIE_RC_TYPE) {
val |= DEVICE_TYPE_RC;
- } else if (rcar->mode == DW_PCIE_EP_TYPE) {
+ } else if (rcar->platdata->mode == DW_PCIE_EP_TYPE) {
val |= DEVICE_TYPE_EP;
} else {
ret = -EINVAL;
@@ -437,9 +441,9 @@ static void rcar_gen4_remove_dw_pcie_ep(struct rcar_gen4_pcie *rcar)
/* Common */
static int rcar_gen4_add_dw_pcie(struct rcar_gen4_pcie *rcar)
{
- rcar->mode = (uintptr_t)of_device_get_match_data(&rcar->pdev->dev);
+ rcar->platdata = of_device_get_match_data(&rcar->pdev->dev);
- switch (rcar->mode) {
+ switch (rcar->platdata->mode) {
case DW_PCIE_RC_TYPE:
return rcar_gen4_add_dw_pcie_rp(rcar);
case DW_PCIE_EP_TYPE:
@@ -480,7 +484,7 @@ static int rcar_gen4_pcie_probe(struct platform_device *pdev)
static void rcar_gen4_remove_dw_pcie(struct rcar_gen4_pcie *rcar)
{
- switch (rcar->mode) {
+ switch (rcar->platdata->mode) {
case DW_PCIE_RC_TYPE:
rcar_gen4_remove_dw_pcie_rp(rcar);
break;
@@ -500,14 +504,22 @@ static void rcar_gen4_pcie_remove(struct platform_device *pdev)
rcar_gen4_pcie_unprepare(rcar);
}
+static struct rcar_gen4_pcie_platdata platdata_rcar_gen4_pcie = {
+ .mode = DW_PCIE_RC_TYPE,
+};
+
+static struct rcar_gen4_pcie_platdata platdata_rcar_gen4_pcie_ep = {
+ .mode = DW_PCIE_EP_TYPE,
+};
+
static const struct of_device_id rcar_gen4_pcie_of_match[] = {
{
.compatible = "renesas,rcar-gen4-pcie",
- .data = (void *)DW_PCIE_RC_TYPE,
+ .data = &platdata_rcar_gen4_pcie,
},
{
.compatible = "renesas,rcar-gen4-pcie-ep",
- .data = (void *)DW_PCIE_EP_TYPE,
+ .data = &platdata_rcar_gen4_pcie_ep,
},
{},
};
--
2.25.1
^ permalink raw reply related
* [PATCH v6 5/7] PCI: rcar-gen4: Add .ltssm_enable() for other SoC support
From: Yoshihiro Shimoda @ 2024-04-10 0:48 UTC (permalink / raw)
To: lpieralisi, kw, robh, bhelgaas, krzysztof.kozlowski+dt, conor+dt,
jingoohan1, mani
Cc: marek.vasut+renesas, linux-pci, devicetree, linux-renesas-soc,
Yoshihiro Shimoda
In-Reply-To: <20240410004832.3726922-1-yoshihiro.shimoda.uh@renesas.com>
This driver can reuse other R-Car Gen4 SoCs support like r8a779g0 and
r8a779h0. However, r8a779g0 and r8a779h0 require other initializing
settings that differ than r8a779f0. So, add a new function pointer
.ltssm_enable() for it. No behavior changes.
After applied this patch, probing SoCs by rcar_gen4_pcie_of_match[]
will be changed like below:
- r8a779f0 as "renesas,r8a779f0-pcie" and "renesas,r8a779f0-pcie-ep"
Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
---
drivers/pci/controller/dwc/pcie-rcar-gen4.c | 41 ++++++++++++++++++---
1 file changed, 36 insertions(+), 5 deletions(-)
diff --git a/drivers/pci/controller/dwc/pcie-rcar-gen4.c b/drivers/pci/controller/dwc/pcie-rcar-gen4.c
index da2821d6efce..47ec394885f5 100644
--- a/drivers/pci/controller/dwc/pcie-rcar-gen4.c
+++ b/drivers/pci/controller/dwc/pcie-rcar-gen4.c
@@ -48,7 +48,9 @@
#define RCAR_GEN4_PCIE_EP_FUNC_DBI_OFFSET 0x1000
#define RCAR_GEN4_PCIE_EP_FUNC_DBI2_OFFSET 0x800
+struct rcar_gen4_pcie;
struct rcar_gen4_pcie_platdata {
+ int (*ltssm_enable)(struct rcar_gen4_pcie *rcar);
enum dw_pcie_device_mode mode;
};
@@ -61,8 +63,8 @@ struct rcar_gen4_pcie {
#define to_rcar_gen4_pcie(_dw) container_of(_dw, struct rcar_gen4_pcie, dw)
/* Common */
-static void rcar_gen4_pcie_ltssm_enable(struct rcar_gen4_pcie *rcar,
- bool enable)
+static void rcar_gen4_pcie_ltssm_control(struct rcar_gen4_pcie *rcar,
+ bool enable)
{
u32 val;
@@ -127,9 +129,13 @@ static int rcar_gen4_pcie_speed_change(struct dw_pcie *dw)
static int rcar_gen4_pcie_start_link(struct dw_pcie *dw)
{
struct rcar_gen4_pcie *rcar = to_rcar_gen4_pcie(dw);
- int i, changes;
+ int i, changes, ret;
- rcar_gen4_pcie_ltssm_enable(rcar, true);
+ if (rcar->platdata->ltssm_enable) {
+ ret = rcar->platdata->ltssm_enable(rcar);
+ if (ret)
+ return ret;
+ }
/*
* Require direct speed change with retrying here if the link_gen is
@@ -157,7 +163,7 @@ static void rcar_gen4_pcie_stop_link(struct dw_pcie *dw)
{
struct rcar_gen4_pcie *rcar = to_rcar_gen4_pcie(dw);
- rcar_gen4_pcie_ltssm_enable(rcar, false);
+ rcar_gen4_pcie_ltssm_control(rcar, false);
}
static int rcar_gen4_pcie_common_init(struct rcar_gen4_pcie *rcar)
@@ -504,6 +510,23 @@ static void rcar_gen4_pcie_remove(struct platform_device *pdev)
rcar_gen4_pcie_unprepare(rcar);
}
+static int r8a779f0_pcie_ltssm_enable(struct rcar_gen4_pcie *rcar)
+{
+ rcar_gen4_pcie_ltssm_control(rcar, true);
+
+ return 0;
+}
+
+static struct rcar_gen4_pcie_platdata platdata_r8a779f0_pcie = {
+ .ltssm_enable = r8a779f0_pcie_ltssm_enable,
+ .mode = DW_PCIE_RC_TYPE,
+};
+
+static struct rcar_gen4_pcie_platdata platdata_r8a779f0_pcie_ep = {
+ .ltssm_enable = r8a779f0_pcie_ltssm_enable,
+ .mode = DW_PCIE_EP_TYPE,
+};
+
static struct rcar_gen4_pcie_platdata platdata_rcar_gen4_pcie = {
.mode = DW_PCIE_RC_TYPE,
};
@@ -513,6 +536,14 @@ static struct rcar_gen4_pcie_platdata platdata_rcar_gen4_pcie_ep = {
};
static const struct of_device_id rcar_gen4_pcie_of_match[] = {
+ {
+ .compatible = "renesas,r8a779f0-pcie",
+ .data = &platdata_r8a779f0_pcie,
+ },
+ {
+ .compatible = "renesas,r8a779f0-pcie-ep",
+ .data = &platdata_r8a779f0_pcie_ep,
+ },
{
.compatible = "renesas,rcar-gen4-pcie",
.data = &platdata_rcar_gen4_pcie,
--
2.25.1
^ permalink raw reply related
* [PATCH v6 6/7] PCI: rcar-gen4: Add support for r8a779g0
From: Yoshihiro Shimoda @ 2024-04-10 0:48 UTC (permalink / raw)
To: lpieralisi, kw, robh, bhelgaas, krzysztof.kozlowski+dt, conor+dt,
jingoohan1, mani
Cc: marek.vasut+renesas, linux-pci, devicetree, linux-renesas-soc,
Yoshihiro Shimoda
In-Reply-To: <20240410004832.3726922-1-yoshihiro.shimoda.uh@renesas.com>
This driver previously supported r8a779f0 (R-Car S4-8). Add support
for r8a779g0 (R-Car V4H).
To support r8a779g0, it requires specific firmware.
Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
---
drivers/pci/controller/dwc/pcie-rcar-gen4.c | 201 +++++++++++++++++++-
1 file changed, 200 insertions(+), 1 deletion(-)
diff --git a/drivers/pci/controller/dwc/pcie-rcar-gen4.c b/drivers/pci/controller/dwc/pcie-rcar-gen4.c
index 47ec394885f5..a62804674f4e 100644
--- a/drivers/pci/controller/dwc/pcie-rcar-gen4.c
+++ b/drivers/pci/controller/dwc/pcie-rcar-gen4.c
@@ -5,8 +5,10 @@
*/
#include <linux/delay.h>
+#include <linux/firmware.h>
#include <linux/interrupt.h>
#include <linux/io.h>
+#include <linux/iopoll.h>
#include <linux/module.h>
#include <linux/of.h>
#include <linux/pci.h>
@@ -20,9 +22,10 @@
/* Renesas-specific */
/* PCIe Mode Setting Register 0 */
#define PCIEMSR0 0x0000
-#define BIFUR_MOD_SET_ON BIT(0)
+#define APP_SRIS_MODE BIT(6)
#define DEVICE_TYPE_EP 0
#define DEVICE_TYPE_RC BIT(4)
+#define BIFUR_MOD_SET_ON BIT(0)
/* PCIe Interrupt Status 0 */
#define PCIEINTSTS0 0x0084
@@ -37,19 +40,47 @@
#define PCIEDMAINTSTSEN 0x0314
#define PCIEDMAINTSTSEN_INIT GENMASK(15, 0)
+/* Port Logic Registers 89 */
+#define PRTLGC89 0x0b70
+
+/* Port Logic Registers 90 */
+#define PRTLGC90 0x0b74
+
/* PCIe Reset Control Register 1 */
#define PCIERSTCTRL1 0x0014
#define APP_HOLD_PHY_RST BIT(16)
#define APP_LTSSM_ENABLE BIT(0)
+/* PCIe Power Management Control */
+#define PCIEPWRMNGCTRL 0x0070
+#define APP_CLK_REQ_N BIT(11)
+#define APP_CLK_PM_EN BIT(10)
+
+/*
+ * The R-Car Gen4 documents don't describe the PHY registers' name.
+ * But, the initialization procedure describes these offsets. So,
+ * this driver makes up own #defines for the offsets.
+ */
+#define RCAR_GEN4_PCIE_PHY_0f8 0x0f8
+#define RCAR_GEN4_PCIE_PHY_148 0x148
+#define RCAR_GEN4_PCIE_PHY_1d4 0x1d4
+#define RCAR_GEN4_PCIE_PHY_514 0x514
+#define RCAR_GEN4_PCIE_PHY_700 0x700
+
#define RCAR_NUM_SPEED_CHANGE_RETRIES 10
#define RCAR_MAX_LINK_SPEED 4
#define RCAR_GEN4_PCIE_EP_FUNC_DBI_OFFSET 0x1000
#define RCAR_GEN4_PCIE_EP_FUNC_DBI2_OFFSET 0x800
+#define RCAR_GEN4_PCIE_FIRMWARE_NAME "rcar_gen4_pcie.bin"
+#define RCAR_GEN4_PCIE_FIRMWARE_BASE_ADDR 0xc000
+
+MODULE_FIRMWARE(RCAR_GEN4_PCIE_FIRMWARE_NAME);
+
struct rcar_gen4_pcie;
struct rcar_gen4_pcie_platdata {
+ void (*additional_common_init)(struct rcar_gen4_pcie *rcar);
int (*ltssm_enable)(struct rcar_gen4_pcie *rcar);
enum dw_pcie_device_mode mode;
};
@@ -57,12 +88,144 @@ struct rcar_gen4_pcie_platdata {
struct rcar_gen4_pcie {
struct dw_pcie dw;
void __iomem *base;
+ void __iomem *phy_base;
struct platform_device *pdev;
const struct rcar_gen4_pcie_platdata *platdata;
};
#define to_rcar_gen4_pcie(_dw) container_of(_dw, struct rcar_gen4_pcie, dw)
/* Common */
+static void rcar_gen4_pcie_phy_reg_update_bits(struct rcar_gen4_pcie *rcar,
+ u32 offset, u32 mask, u32 val)
+{
+ u32 tmp;
+
+ tmp = readl(rcar->phy_base + offset);
+ tmp &= ~mask;
+ tmp |= val;
+ writel(tmp, rcar->phy_base + offset);
+}
+
+static int rcar_gen4_pcie_reg_check_bit(struct rcar_gen4_pcie *rcar,
+ u32 offset, u32 mask)
+{
+ struct dw_pcie *dw = &rcar->dw;
+
+ if (dw_pcie_readl_dbi(dw, offset) & mask)
+ return -EAGAIN;
+
+ return 0;
+}
+
+static int rcar_gen4_pcie_update_phy_firmware(struct rcar_gen4_pcie *rcar)
+{
+ const u32 check_addr[] = { 0x00101018, 0x00101118, 0x00101021, 0x00101121};
+ struct dw_pcie *dw = &rcar->dw;
+ const struct firmware *fw;
+ unsigned int i, timeout;
+ u32 data;
+ int ret;
+
+ ret = request_firmware(&fw, RCAR_GEN4_PCIE_FIRMWARE_NAME, dw->dev);
+ if (ret) {
+ dev_err(dw->dev, "%s: Requesting firmware failed\n", __func__);
+ return ret;
+ }
+
+ for (i = 0; i < (fw->size / 2); i++) {
+ data = fw->data[i * 2] | fw->data[(i * 2) + 1] << 8;
+ timeout = 100;
+ do {
+ dw_pcie_writel_dbi(dw, PRTLGC89, RCAR_GEN4_PCIE_FIRMWARE_BASE_ADDR + i);
+ dw_pcie_writel_dbi(dw, PRTLGC90, data);
+ if (rcar_gen4_pcie_reg_check_bit(rcar, PRTLGC89, BIT(30)) >= 0)
+ break;
+ if (!(--timeout)) {
+ ret = -ETIMEDOUT;
+ goto exit;
+ }
+ usleep_range(100, 200);
+ } while (1);
+ }
+
+ rcar_gen4_pcie_phy_reg_update_bits(rcar, RCAR_GEN4_PCIE_PHY_0f8, BIT(17), BIT(17));
+
+ for (i = 0; i < ARRAY_SIZE(check_addr); i++) {
+ timeout = 100;
+ do {
+ dw_pcie_writel_dbi(dw, PRTLGC89, check_addr[i]);
+ ret = rcar_gen4_pcie_reg_check_bit(rcar, PRTLGC89, BIT(30));
+ ret |= rcar_gen4_pcie_reg_check_bit(rcar, PRTLGC90, BIT(0));
+ if (ret >= 0)
+ break;
+ if (!(--timeout)) {
+ ret = -ETIMEDOUT;
+ goto exit;
+ }
+ usleep_range(100, 200);
+ } while (1);
+ }
+
+ ret = 0;
+exit:
+ release_firmware(fw);
+
+ return ret;
+}
+
+static int rcar_gen4_pcie_enable_phy(struct rcar_gen4_pcie *rcar)
+{
+ struct dw_pcie *dw = &rcar->dw;
+ u32 val;
+ int ret;
+
+ val = dw_pcie_readl_dbi(dw, PCIE_PORT_FORCE);
+ val |= PORT_FORCE_DO_DESKEW_FOR_SRIS;
+ dw_pcie_writel_dbi(dw, PCIE_PORT_FORCE, val);
+
+ val = readl(rcar->base + PCIEMSR0);
+ val |= APP_SRIS_MODE;
+ writel(val, rcar->base + PCIEMSR0);
+
+ rcar_gen4_pcie_phy_reg_update_bits(rcar, RCAR_GEN4_PCIE_PHY_700, BIT(28), 0);
+ rcar_gen4_pcie_phy_reg_update_bits(rcar, RCAR_GEN4_PCIE_PHY_700, BIT(20), 0);
+ rcar_gen4_pcie_phy_reg_update_bits(rcar, RCAR_GEN4_PCIE_PHY_700, BIT(12), 0);
+ rcar_gen4_pcie_phy_reg_update_bits(rcar, RCAR_GEN4_PCIE_PHY_700, BIT(4), 0);
+
+ rcar_gen4_pcie_phy_reg_update_bits(rcar, RCAR_GEN4_PCIE_PHY_148,
+ GENMASK(23, 22), BIT(22));
+ rcar_gen4_pcie_phy_reg_update_bits(rcar, RCAR_GEN4_PCIE_PHY_148,
+ GENMASK(18, 16), GENMASK(17, 16));
+ rcar_gen4_pcie_phy_reg_update_bits(rcar, RCAR_GEN4_PCIE_PHY_148,
+ GENMASK(7, 6), BIT(6));
+ rcar_gen4_pcie_phy_reg_update_bits(rcar, RCAR_GEN4_PCIE_PHY_148,
+ GENMASK(2, 0), GENMASK(11, 0));
+ rcar_gen4_pcie_phy_reg_update_bits(rcar, RCAR_GEN4_PCIE_PHY_1d4,
+ GENMASK(16, 15), GENMASK(16, 15));
+ rcar_gen4_pcie_phy_reg_update_bits(rcar, RCAR_GEN4_PCIE_PHY_514, BIT(26), BIT(26));
+ rcar_gen4_pcie_phy_reg_update_bits(rcar, RCAR_GEN4_PCIE_PHY_0f8, BIT(16), 0);
+ rcar_gen4_pcie_phy_reg_update_bits(rcar, RCAR_GEN4_PCIE_PHY_0f8, BIT(19), BIT(19));
+
+ val = readl(rcar->base + PCIERSTCTRL1);
+ val &= ~APP_HOLD_PHY_RST;
+ writel(val, rcar->base + PCIERSTCTRL1);
+
+ ret = readl_poll_timeout(rcar->phy_base + RCAR_GEN4_PCIE_PHY_0f8, val,
+ !(val & BIT(18)), 100, 10000);
+ if (ret < 0)
+ return ret;
+
+ ret = rcar_gen4_pcie_update_phy_firmware(rcar);
+ if (ret)
+ return ret;
+
+ val = readl(rcar->base + PCIERSTCTRL1);
+ val |= APP_LTSSM_ENABLE;
+ writel(val, rcar->base + PCIERSTCTRL1);
+
+ return 0;
+}
+
static void rcar_gen4_pcie_ltssm_control(struct rcar_gen4_pcie *rcar,
bool enable)
{
@@ -200,6 +363,9 @@ static int rcar_gen4_pcie_common_init(struct rcar_gen4_pcie *rcar)
if (ret)
goto err_unprepare;
+ if (rcar->platdata->additional_common_init)
+ rcar->platdata->additional_common_init(rcar);
+
return 0;
err_unprepare:
@@ -241,6 +407,10 @@ static void rcar_gen4_pcie_unprepare(struct rcar_gen4_pcie *rcar)
static int rcar_gen4_pcie_get_resources(struct rcar_gen4_pcie *rcar)
{
+ rcar->phy_base = devm_platform_ioremap_resource_byname(rcar->pdev, "phy");
+ if (IS_ERR(rcar->phy_base))
+ return PTR_ERR(rcar->base);
+
/* Renesas-specific registers */
rcar->base = devm_platform_ioremap_resource_byname(rcar->pdev, "app");
@@ -517,6 +687,31 @@ static int r8a779f0_pcie_ltssm_enable(struct rcar_gen4_pcie *rcar)
return 0;
}
+static void rcar_gen4_pcie_additional_common_init(struct rcar_gen4_pcie *rcar)
+{
+ struct dw_pcie *dw = &rcar->dw;
+ u32 val;
+
+ /*
+ * The SoC manual said the register setting is required. Otherwise,
+ * linkup failed.
+ */
+ val = dw_pcie_readl_dbi(dw, PCIE_PORT_LANE_SKEW);
+ val &= ~PORT_LANE_SKEW_INSERT_MASK;
+ if (dw->num_lanes < 4)
+ val |= BIT(6);
+ dw_pcie_writel_dbi(dw, PCIE_PORT_LANE_SKEW, val);
+
+ val = readl(rcar->base + PCIEPWRMNGCTRL);
+ val |= APP_CLK_REQ_N | APP_CLK_PM_EN;
+ writel(val, rcar->base + PCIEPWRMNGCTRL);
+}
+
+static int rcar_gen4_pcie_ltssm_enable(struct rcar_gen4_pcie *rcar)
+{
+ return rcar_gen4_pcie_enable_phy(rcar);
+}
+
static struct rcar_gen4_pcie_platdata platdata_r8a779f0_pcie = {
.ltssm_enable = r8a779f0_pcie_ltssm_enable,
.mode = DW_PCIE_RC_TYPE,
@@ -528,10 +723,14 @@ static struct rcar_gen4_pcie_platdata platdata_r8a779f0_pcie_ep = {
};
static struct rcar_gen4_pcie_platdata platdata_rcar_gen4_pcie = {
+ .additional_common_init = rcar_gen4_pcie_additional_common_init,
+ .ltssm_enable = rcar_gen4_pcie_ltssm_enable,
.mode = DW_PCIE_RC_TYPE,
};
static struct rcar_gen4_pcie_platdata platdata_rcar_gen4_pcie_ep = {
+ .additional_common_init = rcar_gen4_pcie_additional_common_init,
+ .ltssm_enable = rcar_gen4_pcie_ltssm_enable,
.mode = DW_PCIE_EP_TYPE,
};
--
2.25.1
^ permalink raw reply related
* [PATCH v6 7/7] misc: pci_endpoint_test: Document a policy about adding pci_device_id
From: Yoshihiro Shimoda @ 2024-04-10 0:48 UTC (permalink / raw)
To: lpieralisi, kw, robh, bhelgaas, krzysztof.kozlowski+dt, conor+dt,
jingoohan1, mani
Cc: marek.vasut+renesas, linux-pci, devicetree, linux-renesas-soc,
Yoshihiro Shimoda, Frank Li
In-Reply-To: <20240410004832.3726922-1-yoshihiro.shimoda.uh@renesas.com>
To avoid becoming struct pci_device_id pci_endpoint_test_tbl longer
and longer, document a policy. For example, if PCIe endpoint controller
can configure vendor id and/or product id, you can reuse one of
existing entries to test.
Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
---
Cc: Frank Li <Frank.li@nxp.com>
---
drivers/misc/pci_endpoint_test.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/misc/pci_endpoint_test.c b/drivers/misc/pci_endpoint_test.c
index c38a6083f0a7..3c8a0afad91d 100644
--- a/drivers/misc/pci_endpoint_test.c
+++ b/drivers/misc/pci_endpoint_test.c
@@ -980,6 +980,7 @@ static const struct pci_endpoint_test_data j721e_data = {
.irq_type = IRQ_TYPE_MSI,
};
+/* Don't need to add a new entry if you can use existing entry to test */
static const struct pci_device_id pci_endpoint_test_tbl[] = {
{ PCI_DEVICE(PCI_VENDOR_ID_TI, PCI_DEVICE_ID_TI_DRA74x),
.driver_data = (kernel_ulong_t)&default_data,
--
2.25.1
^ permalink raw reply related
* RE: [PATCH 09/17] phy: samsung-ufs: use exynos_get_pmu_regmap_by_phandle() to obtain PMU regmap
From: Alim Akhtar @ 2024-04-10 0:59 UTC (permalink / raw)
To: 'Peter Griffin', mturquette, sboyd, robh, krzk+dt,
conor+dt, vkoul, kishon, 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, andre.draszik,
saravanak, willmcvicker
In-Reply-To: <20240404122559.898930-10-peter.griffin@linaro.org>
Hi Peter,
> -----Original Message-----
> From: Peter Griffin <peter.griffin@linaro.org>
> Sent: Thursday, April 4, 2024 5:56 PM
> To: mturquette@baylibre.com; sboyd@kernel.org; robh@kernel.org;
> krzk+dt@kernel.org; conor+dt@kernel.org; vkoul@kernel.org;
> kishon@kernel.org; alim.akhtar@samsung.com; avri.altman@wdc.com;
> bvanassche@acm.org; s.nawrocki@samsung.com; cw00.choi@samsung.com;
> jejb@linux.ibm.com; martin.petersen@oracle.com;
> chanho61.park@samsung.com; ebiggers@kernel.org
> Cc: linux-scsi@vger.kernel.org; linux-phy@lists.infradead.org;
> devicetree@vger.kernel.org; linux-clk@vger.kernel.org; linux-samsung-
> soc@vger.kernel.org; linux-kernel@vger.kernel.org; linux-arm-
> kernel@lists.infradead.org; tudor.ambarus@linaro.org;
> andre.draszik@linaro.org; saravanak@google.com;
> willmcvicker@google.com; Peter Griffin <peter.griffin@linaro.org>
> Subject: [PATCH 09/17] phy: samsung-ufs: use
> exynos_get_pmu_regmap_by_phandle() to obtain PMU regmap
>
> This allows us to obtain a PMU regmap that is created by the exynos-pmu
> driver. Platforms such as gs101 require exynos-pmu created regmap to issue
> SMC calls for PMU register accesses. Existing platforms still get a MMIO
> regmap as before.
>
> Signed-off-by: Peter Griffin <peter.griffin@linaro.org>
> ---
Acked-by: Alim Akhtar <alim.akhtar@samsung.com>
> drivers/phy/samsung/phy-samsung-ufs.c | 5 +++--
> 1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/phy/samsung/phy-samsung-ufs.c
> b/drivers/phy/samsung/phy-samsung-ufs.c
> index 183c88e3d1ec..c567efafc30f 100644
> --- a/drivers/phy/samsung/phy-samsung-ufs.c
> +++ b/drivers/phy/samsung/phy-samsung-ufs.c
> @@ -18,6 +18,7 @@
> #include <linux/phy/phy.h>
> #include <linux/platform_device.h>
> #include <linux/regmap.h>
> +#include <linux/soc/samsung/exynos-pmu.h>
>
> #include "phy-samsung-ufs.h"
>
> @@ -255,8 +256,8 @@ static int samsung_ufs_phy_probe(struct
> platform_device *pdev)
> goto out;
> }
>
> - phy->reg_pmu = syscon_regmap_lookup_by_phandle(
> - dev->of_node, "samsung,pmu-syscon");
> + phy->reg_pmu = exynos_get_pmu_regmap_by_phandle(dev-
> >of_node,
> + "samsung,pmu-
> syscon");
> if (IS_ERR(phy->reg_pmu)) {
> err = PTR_ERR(phy->reg_pmu);
> dev_err(dev, "failed syscon remap for pmu\n");
> --
> 2.44.0.478.gd926399ef9-goog
^ permalink raw reply
* Re: [RFC PATCH v2 0/2] fw_devlink overlay fix
From: Saravana Kannan @ 2024-04-10 1:06 UTC (permalink / raw)
To: Herve Codina
Cc: Geert Uytterhoeven, Rob Herring, kernel-team, linux-kernel, imx,
linux-arm-kernel, linux-i2c, devicetree, linux-spi, linux-acpi,
Luca Ceresoli, Thomas Petazzoni
In-Reply-To: <20240409150247.61e30a86@bootlin.com>
On Tue, Apr 9, 2024 at 6:02 AM Herve Codina <herve.codina@bootlin.com> wrote:
>
> Hi Saravana,
>
> +CC Luca and Thomas
>
> On Mon, 8 Apr 2024 22:37:01 -0700
> Saravana Kannan <saravanak@google.com> wrote:
>
> > Don't bother reviewing this patch. It needs to be tested and possibly
> > refactored first.
> >
> > Geert and Herve,
> >
> > This patch serious should hopefully fix both of your use cases
> > [1][2][3]. Can you please check to make sure the device links created
> > to/from the overlay devices are to/from the right ones?
> >
> > I've only compile tested it. If I made some obvious mistake, feel free
> > to fix it and give it a shot.
> >
> > Cc: Rob Herring <robh@kernel.org>
> >
> > [1] - https://lore.kernel.org/lkml/CAMuHMdXEnSD4rRJ-o90x4OprUacN_rJgyo8x6=9F9rZ+-KzjOg@mail.gmail.com/
> > [2] - https://lore.kernel.org/all/20240221095137.616d2aaa@bootlin.com/
> > [3] - https://lore.kernel.org/lkml/20240312151835.29ef62a0@bootlin.com/
> >
>
> I tested your patches.
>
> Concerning my use cases, they fix the issue described in
> https://lore.kernel.org/all/20240221095137.616d2aaa@bootlin.com/
I went back and looked at the example. I'm not even sure I understand
that example. In that example at the link above, are you saying
without any changes to upstream reg_dock_sys_3v3 was listing it's
supplier as i2c5 instead of tca6424_dock_1? Why wasn't Geert's
existing changes in of_i2c_notify not sufficient? Looking at it, it
does:
rd->dn->fwnode.flags &= ~FWNODE_FLAG_NOT_DEVICE;
Which should clear the flag for tca6424_dock_1. Can you help me
understand why it's not getting cleared?
> But not the one described in
> https://lore.kernel.org/lkml/20240312151835.29ef62a0@bootlin.com/
> A link is still present between the i2c@600 and the PCI device.
> instead of the i2c@600 and the pci-ep-bus.
What do you mean by PCI device here? You say the same thing in the
link, but I don't understand what you mean. Can you clarify what
exactly gets added by the overlay? Please use the fwnode name in all
the descriptions, even when talking about device links. That should
help avoid the confusion.
Also, if you can show what the target node of the overlay looks like,
that'd help too.
> Adding the patch clearing the FWNODE_FLAG_NOT_DEVICE in device_add() available
> at [1] on top of your patches fixes the link issue.
> With this additional patch applied, the link is present between the i2c@600
> and the pci-ep-bus.
I know the problem with this patch series. But to fix it properly, I
need to understand the root of the overlay node in your examples and
the target it's applied to.
-Saravana
>
> [1] https://lore.kernel.org/lkml/20240220111044.133776-2-herve.codina@bootlin.com/
>
> Best regards,
> Hervé
^ permalink raw reply
* [PATCH v7 0/3] riscv: sophgo: add dmamux support for Sophgo CV1800/SG2000 SoCs
From: Inochi Amaoto @ 2024-04-10 1:20 UTC (permalink / raw)
To: Vinod Koul, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Chen Wang, Inochi Amaoto, Paul Walmsley, Palmer Dabbelt,
Albert Ou
Cc: Jisheng Zhang, Liu Gui, Jingbao Qiu, dlan, dmaengine, devicetree,
linux-kernel, linux-riscv
Add dma multiplexer support for the Sophgo CV1800/SG2000 SoCs.
As the syscon device of CV1800 have a usb phy subdevices. The
binding of the syscon can not be complete without the usb phy
is finished. As a result, the binding of syscon is removed
and will be evolved in its original series after the usb phy
binding is fully explored.
Changed from v6:
1. fix copyright time.
2. driver only output mapping info in when debugging.
3. remove dma-master check in the driver init since the binding
always require it.
Changed from v5:
1. remove dead binding header.
2. make "reg" required so the syscon binding can have the same
example node of the dmamux binding.
Changed from v4:
1. remove the syscon binding since it can not be complete (still
lack some subdevices)
2. add reg description for the binding,
3. remove the fixed channel assign for dmamux binding
3. driver adopt to the binding change. Now the driver allocates all the
channel when initing and maps the request chan to the channel dynamicly.
Changed from v3:
1. fix dt-binding address issue.
Changed from v2:
1. add reg property of dmamux node in the binding of patch 2
Changed from v1:
1. fix wrong title of patch 2.
Inochi Amaoto (3):
dt-bindings: dmaengine: Add dma multiplexer for CV18XX/SG200X series
SoC
soc/sophgo: add top sysctrl layout file for CV18XX/SG200X
dmaengine: add driver for Sophgo CV18XX/SG200X dmamux
.../bindings/dma/sophgo,cv1800-dmamux.yaml | 51 ++++
drivers/dma/Kconfig | 9 +
drivers/dma/Makefile | 1 +
drivers/dma/cv1800-dmamux.c | 260 ++++++++++++++++++
include/soc/sophgo/cv1800-sysctl.h | 30 ++
5 files changed, 351 insertions(+)
create mode 100644 Documentation/devicetree/bindings/dma/sophgo,cv1800-dmamux.yaml
create mode 100644 drivers/dma/cv1800-dmamux.c
create mode 100644 include/soc/sophgo/cv1800-sysctl.h
--
2.44.0
^ permalink raw reply
* [PATCH v7 1/3] dt-bindings: dmaengine: Add dma multiplexer for CV18XX/SG200X series SoC
From: Inochi Amaoto @ 2024-04-10 1:21 UTC (permalink / raw)
To: Vinod Koul, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Chen Wang, Inochi Amaoto, Paul Walmsley, Palmer Dabbelt,
Albert Ou
Cc: Jisheng Zhang, Liu Gui, Jingbao Qiu, dlan, dmaengine, devicetree,
linux-kernel, linux-riscv, Krzysztof Kozlowski
In-Reply-To: <IA1PR20MB49538A66B7AAE7801C5A7C04BB062@IA1PR20MB4953.namprd20.prod.outlook.com>
The DMA IP of Sophgo CV18XX/SG200X is based on a DW AXI CORE, with
an additional channel remap register located in the top system control
area. The DMA channel is exclusive to each core.
In addition, the DMA multiplexer is a subdevice of system controller,
so this binding only contains necessary properties for the multiplexer
itself.
Add the dmamux binding for CV18XX/SG200X series SoC.
Signed-off-by: Inochi Amaoto <inochiama@outlook.com>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
---
.../bindings/dma/sophgo,cv1800-dmamux.yaml | 51 +++++++++++++++++++
1 file changed, 51 insertions(+)
create mode 100644 Documentation/devicetree/bindings/dma/sophgo,cv1800-dmamux.yaml
diff --git a/Documentation/devicetree/bindings/dma/sophgo,cv1800-dmamux.yaml b/Documentation/devicetree/bindings/dma/sophgo,cv1800-dmamux.yaml
new file mode 100644
index 000000000000..480cb117db9b
--- /dev/null
+++ b/Documentation/devicetree/bindings/dma/sophgo,cv1800-dmamux.yaml
@@ -0,0 +1,51 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/dma/sophgo,cv1800-dmamux.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Sophgo CV1800/SG200 Series DMA multiplexer
+
+maintainers:
+ - Inochi Amaoto <inochiama@outlook.com>
+
+description: |
+ The DMA multiplexer of CV1800 is a subdevice of the system
+ controller. It support mapping 8 channels, but each channel
+ can be mapped only once.
+
+allOf:
+ - $ref: dma-router.yaml#
+
+properties:
+ compatible:
+ const: sophgo,cv1800-dmamux
+
+ reg:
+ items:
+ - description: DMA channal remapping register
+ - description: DMA channel interrupt mapping register
+
+ '#dma-cells':
+ const: 2
+ description:
+ The first cells is device id. The second one is the cpu id.
+
+ dma-masters:
+ maxItems: 1
+
+required:
+ - reg
+ - '#dma-cells'
+ - dma-masters
+
+additionalProperties: false
+
+examples:
+ - |
+ dma-router@154 {
+ compatible = "sophgo,cv1800-dmamux";
+ reg = <0x154 0x8>, <0x298 0x4>;
+ #dma-cells = <2>;
+ dma-masters = <&dmac>;
+ };
--
2.44.0
^ permalink raw reply related
* [PATCH v7 2/3] soc/sophgo: add top sysctrl layout file for CV18XX/SG200X
From: Inochi Amaoto @ 2024-04-10 1:21 UTC (permalink / raw)
To: Vinod Koul, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Chen Wang, Inochi Amaoto, Paul Walmsley, Palmer Dabbelt,
Albert Ou
Cc: Jisheng Zhang, Liu Gui, Jingbao Qiu, dlan, dmaengine, devicetree,
linux-kernel, linux-riscv
In-Reply-To: <IA1PR20MB49538A66B7AAE7801C5A7C04BB062@IA1PR20MB4953.namprd20.prod.outlook.com>
The "top" system controller of CV18XX/SG200X exposes control
register access for various devices. Add soc header file to
describe it.
Signed-off-by: Inochi Amaoto <inochiama@outlook.com>
---
include/soc/sophgo/cv1800-sysctl.h | 30 ++++++++++++++++++++++++++++++
1 file changed, 30 insertions(+)
create mode 100644 include/soc/sophgo/cv1800-sysctl.h
diff --git a/include/soc/sophgo/cv1800-sysctl.h b/include/soc/sophgo/cv1800-sysctl.h
new file mode 100644
index 000000000000..b9396d33e240
--- /dev/null
+++ b/include/soc/sophgo/cv1800-sysctl.h
@@ -0,0 +1,30 @@
+/* SPDX-License-Identifier: GPL-2.0-or-later */
+/*
+ * Copyright (C) 2023 Inochi Amaoto <inochiama@outlook.com>
+ */
+
+#ifndef CV1800_SYSCTL_H
+#define CV1800_SYSCTL_H
+
+/*
+ * SOPHGO CV1800/SG2000 SoC top system controller registers offsets.
+ */
+
+#define CV1800_CONF_INFO 0x004
+#define CV1800_SYS_CTRL_REG 0x008
+#define CV1800_USB_PHY_CTRL_REG 0x048
+#define CV1800_SDMA_DMA_CHANNEL_REMAP0 0x154
+#define CV1800_SDMA_DMA_CHANNEL_REMAP1 0x158
+#define CV1800_TOP_TIMER_CLK_SEL 0x1a0
+#define CV1800_TOP_WDT_CTRL 0x1a8
+#define CV1800_DDR_AXI_URGENT_OW 0x1b8
+#define CV1800_DDR_AXI_URGENT 0x1bc
+#define CV1800_DDR_AXI_QOS_0 0x1d8
+#define CV1800_DDR_AXI_QOS_1 0x1dc
+#define CV1800_SD_PWRSW_CTRL 0x1f4
+#define CV1800_SD_PWRSW_TIME 0x1f8
+#define CV1800_DDR_AXI_QOS_OW 0x23c
+#define CV1800_SD_CTRL_OPT 0x294
+#define CV1800_SDMA_DMA_INT_MUX 0x298
+
+#endif // CV1800_SYSCTL_H
--
2.44.0
^ permalink raw reply related
* [PATCH v7 3/3] dmaengine: add driver for Sophgo CV18XX/SG200X dmamux
From: Inochi Amaoto @ 2024-04-10 1:21 UTC (permalink / raw)
To: Vinod Koul, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Chen Wang, Inochi Amaoto, Paul Walmsley, Palmer Dabbelt,
Albert Ou
Cc: Jisheng Zhang, Liu Gui, Jingbao Qiu, dlan, dmaengine, devicetree,
linux-kernel, linux-riscv
In-Reply-To: <IA1PR20MB49538A66B7AAE7801C5A7C04BB062@IA1PR20MB4953.namprd20.prod.outlook.com>
Sophgo CV18XX/SG200X use DW AXI CORE with a multiplexer for remapping
its request lines. The multiplexer supports at most 8 request lines.
Add driver for Sophgo CV18XX/SG200X DMA multiplexer.
Signed-off-by: Inochi Amaoto <inochiama@outlook.com>
---
drivers/dma/Kconfig | 9 ++
drivers/dma/Makefile | 1 +
drivers/dma/cv1800-dmamux.c | 260 ++++++++++++++++++++++++++++++++++++
3 files changed, 270 insertions(+)
create mode 100644 drivers/dma/cv1800-dmamux.c
diff --git a/drivers/dma/Kconfig b/drivers/dma/Kconfig
index 002a5ec80620..cb31520b9f86 100644
--- a/drivers/dma/Kconfig
+++ b/drivers/dma/Kconfig
@@ -546,6 +546,15 @@ config PLX_DMA
These are exposed via extra functions on the switch's
upstream port. Each function exposes one DMA channel.
+config SOPHGO_CV1800_DMAMUX
+ tristate "Sophgo CV1800/SG2000 series SoC DMA multiplexer support"
+ depends on MFD_SYSCON
+ depends on ARCH_SOPHGO
+ help
+ Support for the DMA multiplexer on Sophgo CV1800/SG2000
+ series SoCs.
+ Say Y here if your board have this soc.
+
config STE_DMA40
bool "ST-Ericsson DMA40 support"
depends on ARCH_U8500
diff --git a/drivers/dma/Makefile b/drivers/dma/Makefile
index dfd40d14e408..7465f249ee47 100644
--- a/drivers/dma/Makefile
+++ b/drivers/dma/Makefile
@@ -67,6 +67,7 @@ obj-$(CONFIG_PPC_BESTCOMM) += bestcomm/
obj-$(CONFIG_PXA_DMA) += pxa_dma.o
obj-$(CONFIG_RENESAS_DMA) += sh/
obj-$(CONFIG_SF_PDMA) += sf-pdma/
+obj-$(CONFIG_SOPHGO_CV1800_DMAMUX) += cv1800-dmamux.o
obj-$(CONFIG_STE_DMA40) += ste_dma40.o ste_dma40_ll.o
obj-$(CONFIG_STM32_DMA) += stm32-dma.o
obj-$(CONFIG_STM32_DMAMUX) += stm32-dmamux.o
diff --git a/drivers/dma/cv1800-dmamux.c b/drivers/dma/cv1800-dmamux.c
new file mode 100644
index 000000000000..ccee023f9d1d
--- /dev/null
+++ b/drivers/dma/cv1800-dmamux.c
@@ -0,0 +1,260 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (C) 2024 Inochi Amaoto <inochiama@outlook.com>
+ */
+
+#include <linux/bitops.h>
+#include <linux/module.h>
+#include <linux/of_dma.h>
+#include <linux/of_address.h>
+#include <linux/of_platform.h>
+#include <linux/platform_device.h>
+#include <linux/llist.h>
+#include <linux/regmap.h>
+#include <linux/spinlock.h>
+#include <linux/mfd/syscon.h>
+
+#include <soc/sophgo/cv1800-sysctl.h>
+
+#define DMAMUX_NCELLS 2
+#define MAX_DMA_MAPPING_ID 42
+#define MAX_DMA_CPU_ID 2
+#define MAX_DMA_CH_ID 7
+
+#define DMAMUX_INTMUX_REGISTER_LEN 4
+#define DMAMUX_NR_CH_PER_REGISTER 4
+#define DMAMUX_BIT_PER_CH 8
+#define DMAMUX_CH_MASk GENMASK(5, 0)
+#define DMAMUX_INT_BIT_PER_CPU 10
+#define DMAMUX_CH_UPDATE_BIT BIT(31)
+
+#define DMAMUX_CH_REGPOS(chid) \
+ ((chid) / DMAMUX_NR_CH_PER_REGISTER)
+#define DMAMUX_CH_REGOFF(chid) \
+ ((chid) % DMAMUX_NR_CH_PER_REGISTER)
+#define DMAMUX_CH_REG(chid) \
+ ((DMAMUX_CH_REGPOS(chid) * sizeof(u32)) + \
+ CV1800_SDMA_DMA_CHANNEL_REMAP0)
+#define DMAMUX_CH_SET(chid, val) \
+ (((val) << (DMAMUX_CH_REGOFF(chid) * DMAMUX_BIT_PER_CH)) | \
+ DMAMUX_CH_UPDATE_BIT)
+#define DMAMUX_CH_MASK(chid) \
+ DMAMUX_CH_SET(chid, DMAMUX_CH_MASk)
+
+#define DMAMUX_INT_BIT(chid, cpuid) \
+ BIT((cpuid) * DMAMUX_INT_BIT_PER_CPU + (chid))
+#define DMAMUX_INTEN_BIT(cpuid) \
+ DMAMUX_INT_BIT(8, cpuid)
+#define DMAMUX_INT_CH_BIT(chid, cpuid) \
+ (DMAMUX_INT_BIT(chid, cpuid) | DMAMUX_INTEN_BIT(cpuid))
+#define DMAMUX_INT_MASK(chid) \
+ (DMAMUX_INT_BIT(chid, 0) | \
+ DMAMUX_INT_BIT(chid, 1) | \
+ DMAMUX_INT_BIT(chid, 2))
+#define DMAMUX_INT_CH_MASK(chid, cpuid) \
+ (DMAMUX_INT_MASK(chid) | DMAMUX_INTEN_BIT(cpuid))
+
+struct cv1800_dmamux_data {
+ struct dma_router dmarouter;
+ struct regmap *regmap;
+ spinlock_t lock;
+ struct llist_head free_maps;
+ struct llist_head reserve_maps;
+ DECLARE_BITMAP(mapped_peripherals, MAX_DMA_MAPPING_ID);
+};
+
+struct cv1800_dmamux_map {
+ struct llist_node node;
+ unsigned int channel;
+ unsigned int peripheral;
+ unsigned int cpu;
+};
+
+static void cv1800_dmamux_free(struct device *dev, void *route_data)
+{
+ struct cv1800_dmamux_data *dmamux = dev_get_drvdata(dev);
+ struct cv1800_dmamux_map *map = route_data;
+ unsigned long flags;
+
+ spin_lock_irqsave(&dmamux->lock, flags);
+
+ regmap_update_bits(dmamux->regmap,
+ DMAMUX_CH_REG(map->channel),
+ DMAMUX_CH_MASK(map->channel),
+ DMAMUX_CH_UPDATE_BIT);
+
+ regmap_update_bits(dmamux->regmap, CV1800_SDMA_DMA_INT_MUX,
+ DMAMUX_INT_CH_MASK(map->channel, map->cpu),
+ DMAMUX_INTEN_BIT(map->cpu));
+
+ spin_unlock_irqrestore(&dmamux->lock, flags);
+
+ dev_dbg(dev, "free channel %u for req %u (cpu %u)\n",
+ map->channel, map->peripheral, map->cpu);
+}
+
+static void *cv1800_dmamux_route_allocate(struct of_phandle_args *dma_spec,
+ struct of_dma *ofdma)
+{
+ struct platform_device *pdev = of_find_device_by_node(ofdma->of_node);
+ struct cv1800_dmamux_data *dmamux = platform_get_drvdata(pdev);
+ struct cv1800_dmamux_map *map;
+ struct llist_node *node;
+ unsigned long flags;
+ unsigned int chid, devid, cpuid;
+ int ret;
+
+ if (dma_spec->args_count != DMAMUX_NCELLS) {
+ dev_err(&pdev->dev, "invalid number of dma mux args\n");
+ return ERR_PTR(-EINVAL);
+ }
+
+ devid = dma_spec->args[0];
+ cpuid = dma_spec->args[1];
+ dma_spec->args_count = 1;
+
+ if (devid > MAX_DMA_MAPPING_ID) {
+ dev_err(&pdev->dev, "invalid device id: %u\n", devid);
+ return ERR_PTR(-EINVAL);
+ }
+
+ if (cpuid > MAX_DMA_CPU_ID) {
+ dev_err(&pdev->dev, "invalid cpu id: %u\n", cpuid);
+ return ERR_PTR(-EINVAL);
+ }
+
+ dma_spec->np = of_parse_phandle(ofdma->of_node, "dma-masters", 0);
+ if (!dma_spec->np) {
+ dev_err(&pdev->dev, "can't get dma master\n");
+ return ERR_PTR(-EINVAL);
+ }
+
+ spin_lock_irqsave(&dmamux->lock, flags);
+
+ if (test_bit(devid, dmamux->mapped_peripherals)) {
+ llist_for_each_entry(map, dmamux->reserve_maps.first, node) {
+ if (map->peripheral == devid && map->cpu == cpuid)
+ goto found;
+ }
+
+ ret = -EINVAL;
+ goto failed;
+ } else {
+ node = llist_del_first(&dmamux->free_maps);
+ if (!node) {
+ ret = -ENODEV;
+ goto failed;
+ }
+
+ map = llist_entry(node, struct cv1800_dmamux_map, node);
+ llist_add(&map->node, &dmamux->reserve_maps);
+ set_bit(devid, dmamux->mapped_peripherals);
+ }
+
+found:
+ chid = map->channel;
+ map->peripheral = devid;
+ map->cpu = cpuid;
+
+ regmap_set_bits(dmamux->regmap,
+ DMAMUX_CH_REG(chid),
+ DMAMUX_CH_SET(chid, devid));
+
+ regmap_update_bits(dmamux->regmap, CV1800_SDMA_DMA_INT_MUX,
+ DMAMUX_INT_CH_MASK(chid, cpuid),
+ DMAMUX_INT_CH_BIT(chid, cpuid));
+
+ spin_unlock_irqrestore(&dmamux->lock, flags);
+
+ dma_spec->args[0] = chid;
+
+ dev_dbg(&pdev->dev, "register channel %u for req %u (cpu %u)\n",
+ chid, devid, cpuid);
+
+ return map;
+
+failed:
+ spin_unlock_irqrestore(&dmamux->lock, flags);
+ of_node_put(dma_spec->np);
+ dev_err(&pdev->dev, "errno %d\n", ret);
+ return ERR_PTR(ret);
+
+}
+
+static int cv1800_dmamux_probe(struct platform_device *pdev)
+{
+ struct device *dev = &pdev->dev;
+ struct device_node *mux_node = dev->of_node;
+ struct cv1800_dmamux_data *data;
+ struct cv1800_dmamux_map *tmp;
+ struct device *parent = dev->parent;
+ struct device_node *dma_master;
+ struct regmap *regmap = NULL;
+ unsigned int i;
+
+ if (!parent)
+ return -ENODEV;
+
+ regmap = device_node_to_regmap(parent->of_node);
+ if (IS_ERR(regmap))
+ return PTR_ERR(regmap);
+
+ data = devm_kmalloc(dev, sizeof(*data), GFP_KERNEL);
+ if (!data)
+ return -ENOMEM;
+
+ spin_lock_init(&data->lock);
+ init_llist_head(&data->free_maps);
+
+ for (i = 0; i <= MAX_DMA_CH_ID; i++) {
+ tmp = devm_kmalloc(dev, sizeof(*tmp), GFP_KERNEL);
+ if (!tmp) {
+ /* It is OK for not allocating all channel */
+ dev_warn(dev, "can not allocate channel %u\n", i);
+ continue;
+ }
+
+ init_llist_node(&tmp->node);
+ tmp->channel = i;
+ llist_add(&tmp->node, &data->free_maps);
+ }
+
+ /* if no channel is allocated, the probe must fail */
+ if (llist_empty(&data->free_maps))
+ return -ENOMEM;
+
+ data->regmap = regmap;
+ data->dmarouter.dev = dev;
+ data->dmarouter.route_free = cv1800_dmamux_free;
+
+ platform_set_drvdata(pdev, data);
+
+ return of_dma_router_register(mux_node,
+ cv1800_dmamux_route_allocate,
+ &data->dmarouter);
+}
+
+static void cv1800_dmamux_remove(struct platform_device *pdev)
+{
+ of_dma_controller_free(pdev->dev.of_node);
+}
+
+static const struct of_device_id cv1800_dmamux_ids[] = {
+ { .compatible = "sophgo,cv1800-dmamux", },
+ { }
+};
+MODULE_DEVICE_TABLE(of, cv1800_dmamux_ids);
+
+static struct platform_driver cv1800_dmamux_driver = {
+ .driver = {
+ .name = "cv1800-dmamux",
+ .of_match_table = cv1800_dmamux_ids,
+ },
+ .probe = cv1800_dmamux_probe,
+ .remove_new = cv1800_dmamux_remove,
+};
+module_platform_driver(cv1800_dmamux_driver);
+
+MODULE_AUTHOR("Inochi Amaoto <inochiama@outlook.com>");
+MODULE_DESCRIPTION("Sophgo CV1800/SG2000 Series Soc DMAMUX driver");
+MODULE_LICENSE("GPL");
--
2.44.0
^ permalink raw reply related
* Re: [PATCH] riscv: dts: sophgo: add initial Milk-V Duo S board device tree
From: Inochi Amaoto @ 2024-04-10 1:24 UTC (permalink / raw)
To: Jisheng Zhang
Cc: Michael Opdenacker, Inochi Amaoto, Conor Dooley, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Chen Wang, Paul Walmsley,
Palmer Dabbelt, Albert Ou, devicetree, linux-riscv, linux-kernel
In-Reply-To: <1514d28a-5e96-4531-a972-894e41902efa@bootlin.com>
On Tue, Apr 09, 2024 at 03:08:17PM +0200, Michael Opdenacker wrote:
> Hi Inochi
>
> On 4/9/24 at 14:27, Inochi Amaoto wrote:
> > On Tue, Apr 09, 2024 at 01:13:32PM +0100, Conor Dooley wrote:
> > > On Tue, Apr 09, 2024 at 03:17:35PM +0800, Inochi Amaoto wrote:
> > > > On Tue, Apr 09, 2024 at 08:45:04AM +0200, michael.opdenacker@bootlin.com wrote:
> > > > > From: Michael Opdenacker <michael.opdenacker@bootlin.com>
> > > > >
> > > > > This adds initial support for the Milk-V Duo S board
> > > > > (https://milkv.io/duo-s), enabling the serial port and
> > > > > read-only SD card support, allowing to boot Linux to the
> > > > > command line.
> > > > >
> > > > Hi Michael,
> > > >
> > > > I think your patch losts the board binding and have wrong compatiable.
> > > > Also, the SD can have rw support with proper property. See link [1]
> > > > (need 'disable-wp').
> > > [1] doesn't go anywhere useful.
> > >
> > This is my fault, I copied the wrong url. The right patch is
> > https://lore.kernel.org/r/20240217144826.3944-1-jszhang@kernel.org.
>
>
> No problem, I found out.
> I confirm that using the "disable-wp;" property does the trick to make the
> MMC writable.
>
> However, it wasn't mentioned in the above URL...
>
> By the way, do I really need those under &sdhci0?
>
> + bus-width = <4>; + no-1-8-v; + no-mmc; + no-sdio;
>
> My board looks happy so far without them ;-)
FYI, Jisheng. Could you share some suggestions?
> Thanks again for your help
> Cheers
> Michael.
>
> --
> Michael Opdenacker, Bootlin
> Embedded Linux and Kernel engineering
> https://bootlin.com
>
^ permalink raw reply
* Re: [PATCH net-next v2 3/5] net: stmmac: dwmac-socfpga: use pcs_init/pcs_exit
From: Jakub Kicinski @ 2024-04-10 1:34 UTC (permalink / raw)
To: Romain Gantois
Cc: David S. Miller, Eric Dumazet, Paolo Abeni, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Geert Uytterhoeven,
Magnus Damm, Alexandre Torgue, Jose Abreu, Maxime Coquelin,
Russell King, Clément Léger, Thomas Petazzoni, netdev,
devicetree, linux-kernel, linux-renesas-soc, linux-stm32,
linux-arm-kernel, Russell King (Oracle), Maxime Chevallier
In-Reply-To: <20240409-rzn1-gmac1-v2-3-79ca45f2fc79@bootlin.com>
On Tue, 09 Apr 2024 11:21:46 +0200 Romain Gantois wrote:
> + struct regmap_config pcs_regmap_cfg = {
> + .reg_bits = 16,
> + .val_bits = 16,
> + .reg_shift = regmap_upshift(1),
This appears to displease the compiler:
drivers/net/ethernet/stmicro/stmmac/dwmac-socfpga.c:389:16: error: call to undeclared function 'regmap_upshift'; ISO C99 and later do not support implicit function declarations [-Wimplicit-function-declaration]
389 | .reg_shift = regmap_upshift(1),
| ^
--
pw-bot: cr
^ permalink raw reply
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