* [PATCH 0/3] drm: bridge: Add NWL MIPI DSI host controller support
From: Guido Günther @ 2019-07-24 15:52 UTC (permalink / raw)
To: David Airlie, Daniel Vetter, Rob Herring, Mark Rutland, Shawn Guo,
Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam,
NXP Linux Team, Andrzej Hajda, Neil Armstrong, Laurent Pinchart,
Jonas Karlman, Jernej Skrabec, Lee Jones, Guido Günther,
dri-devel, devicetree, linux-arm-kernel, linux-kernel
This adds initial support for the NWL MIPI DSI Host controller found on i.MX8
SoCs.
It adds support for the i.MX8MQ but the same IP core can also be found on e.g.
i.MX8QXP. I added the necessary hooks to support other imx8 variants but since
I only have imx8mq boards to test I omitted the platform data for other SoCs.
The code is based on NXPs BSP so I added Robert Chiras as
Co-authored-by. Robert, if this looks sane could you add your
Signed-off-by:?
The most notable changes over the BSP driver are
- Calculate HS mode timing from phy_configure_opts_mipi_dphy
- Perform all clock setup via DT
- Merge nwl-imx and nwl drivers
- Add B0 silion revision quirk
- become a bridge driver to hook into mxsfb (from what I read[0] DCSS, which
also can drive the nwl on the imx8mq will likely not become part of
imx-display-subsystem so it makes sense to make it drive a bridge for dsi as
well).
- Use panel_bridge to attach the panel
This has been tested on a Librem 5 devkit using mxsfb with Robert's patches[1]
and the rocktech-jh057n00900 panel driver. The DCSS can later on also act as
input source too.
Changes from v0:
- Add quirk for IMQ8MQ silicon B0 revision to not mess with the
system reset controller on power down since enable() won't work
otherwise.
- Drop devm_free_irq() handled by the device driver core
- Disable tx esc clock after the phy power down to unbreak
disable/enable (unblank/blank)
- Add ports to dt binding docs
- Select GENERIC_PHY_MIPI_DPHY instead of GENERIC_PHY for
phy_mipi_dphy_get_default_config
- Select DRM_MIPI_DSI
- Include drm_print.h to fix build on next-20190408
- Drop some debugging messages
- Newline terminate all DRM_ printouts
- Turn component driver into a drm bridge
[0]: https://lists.freedesktop.org/archives/dri-devel/2019-May/219484.html
[1]: https://patchwork.freedesktop.org/series/62822/
Guido Günther (3):
arm64: imx8mq: add imx8mq iomux-gpr field defines
dt-bindings: display/bridge: Add binding for IMX NWL mipi dsi host
controller
drm/bridge: Add NWL MIPI DSI host controller support
.../bindings/display/bridge/imx-nwl-dsi.txt | 89 +++
drivers/gpu/drm/bridge/Kconfig | 2 +
drivers/gpu/drm/bridge/Makefile | 1 +
drivers/gpu/drm/bridge/imx-nwl/Kconfig | 15 +
drivers/gpu/drm/bridge/imx-nwl/Makefile | 2 +
drivers/gpu/drm/bridge/imx-nwl/nwl-drv.c | 529 +++++++++++++
drivers/gpu/drm/bridge/imx-nwl/nwl-drv.h | 72 ++
drivers/gpu/drm/bridge/imx-nwl/nwl-dsi.c | 745 ++++++++++++++++++
drivers/gpu/drm/bridge/imx-nwl/nwl-dsi.h | 111 +++
include/linux/mfd/syscon/imx8mq-iomuxc-gpr.h | 62 ++
10 files changed, 1628 insertions(+)
create mode 100644 Documentation/devicetree/bindings/display/bridge/imx-nwl-dsi.txt
create mode 100644 drivers/gpu/drm/bridge/imx-nwl/Kconfig
create mode 100644 drivers/gpu/drm/bridge/imx-nwl/Makefile
create mode 100644 drivers/gpu/drm/bridge/imx-nwl/nwl-drv.c
create mode 100644 drivers/gpu/drm/bridge/imx-nwl/nwl-drv.h
create mode 100644 drivers/gpu/drm/bridge/imx-nwl/nwl-dsi.c
create mode 100644 drivers/gpu/drm/bridge/imx-nwl/nwl-dsi.h
create mode 100644 include/linux/mfd/syscon/imx8mq-iomuxc-gpr.h
--
2.20.1
^ permalink raw reply
* Re: [PATCH] arm64: dts: qcom: msm8998: Node ordering, address cleanups
From: Vinod Koul @ 2019-07-24 15:35 UTC (permalink / raw)
To: Jeffrey Hugo
Cc: agross, bjorn.andersson, robh+dt, mark.rutland, linux-arm-msm,
devicetree, linux-kernel
In-Reply-To: <20190722165823.21539-1-jeffrey.l.hugo@gmail.com>
On 22-07-19, 09:58, Jeffrey Hugo wrote:
> DT nodes should be ordered by address, then node name, and finally label.
> The msm8998 dtsi does not follow this, so clean it up by reordering the
> nodes. While we are at it, extend the addresses to be fully 32-bits wide
> so that ordering is easy to determine when adding new nodes. Also, two
> or so nodes had the wrong address value in their node name (did not match
> the reg property), so fix those up as well.
>
> Hopefully going forward, things can be maintained so that a cleanup like
> this is not needed.
lgtm, ideally I would have liked that we reg addresses fixed first and
then sort the file (remember a patch should do one thing)
But then any cleanup is better to do :) so:
Reviewed-by: Vinod Koul <vkoul@kernel.org>
>
> Signed-off-by: Jeffrey Hugo <jeffrey.l.hugo@gmail.com>
> ---
> arch/arm64/boot/dts/qcom/msm8998.dtsi | 254 +++++++++++++-------------
> 1 file changed, 127 insertions(+), 127 deletions(-)
>
> diff --git a/arch/arm64/boot/dts/qcom/msm8998.dtsi b/arch/arm64/boot/dts/qcom/msm8998.dtsi
> index c13ed7aeb1e0..4b66a1c588f8 100644
> --- a/arch/arm64/boot/dts/qcom/msm8998.dtsi
> +++ b/arch/arm64/boot/dts/qcom/msm8998.dtsi
> @@ -787,14 +787,22 @@
> ranges = <0 0 0 0xffffffff>;
> compatible = "simple-bus";
>
> - rpm_msg_ram: memory@68000 {
> + gcc: clock-controller@100000 {
> + compatible = "qcom,gcc-msm8998";
> + #clock-cells = <1>;
> + #reset-cells = <1>;
> + #power-domain-cells = <1>;
> + reg = <0x00100000 0xb0000>;
> + };
> +
> + rpm_msg_ram: memory@778000 {
> compatible = "qcom,rpm-msg-ram";
> - reg = <0x778000 0x7000>;
> + reg = <0x00778000 0x7000>;
> };
>
> qfprom: qfprom@780000 {
> compatible = "qcom,qfprom";
> - reg = <0x780000 0x621c>;
> + reg = <0x00780000 0x621c>;
> #address-cells = <1>;
> #size-cells = <1>;
>
> @@ -804,47 +812,10 @@
> };
> };
>
> - gcc: clock-controller@100000 {
> - compatible = "qcom,gcc-msm8998";
> - #clock-cells = <1>;
> - #reset-cells = <1>;
> - #power-domain-cells = <1>;
> - reg = <0x100000 0xb0000>;
> - };
> -
> - tlmm: pinctrl@3400000 {
> - compatible = "qcom,msm8998-pinctrl";
> - reg = <0x3400000 0xc00000>;
> - interrupts = <GIC_SPI 208 IRQ_TYPE_LEVEL_HIGH>;
> - gpio-controller;
> - #gpio-cells = <0x2>;
> - interrupt-controller;
> - #interrupt-cells = <0x2>;
> - };
> -
> - spmi_bus: spmi@800f000 {
> - compatible = "qcom,spmi-pmic-arb";
> - reg = <0x800f000 0x1000>,
> - <0x8400000 0x1000000>,
> - <0x9400000 0x1000000>,
> - <0xa400000 0x220000>,
> - <0x800a000 0x3000>;
> - reg-names = "core", "chnls", "obsrvr", "intr", "cnfg";
> - interrupt-names = "periph_irq";
> - interrupts = <GIC_SPI 326 IRQ_TYPE_LEVEL_HIGH>;
> - qcom,ee = <0>;
> - qcom,channel = <0>;
> - #address-cells = <2>;
> - #size-cells = <0>;
> - interrupt-controller;
> - #interrupt-cells = <4>;
> - cell-index = <0>;
> - };
> -
> tsens0: thermal@10ab000 {
> compatible = "qcom,msm8998-tsens", "qcom,tsens-v2";
> - reg = <0x10ab000 0x1000>, /* TM */
> - <0x10aa000 0x1000>; /* SROT */
> + reg = <0x010ab000 0x1000>, /* TM */
> + <0x010aa000 0x1000>; /* SROT */
>
> #qcom,sensors = <14>;
> #thermal-sensor-cells = <1>;
> @@ -852,8 +823,8 @@
>
> tsens1: thermal@10ae000 {
> compatible = "qcom,msm8998-tsens", "qcom,tsens-v2";
> - reg = <0x10ae000 0x1000>, /* TM */
> - <0x10ad000 0x1000>; /* SROT */
> + reg = <0x010ae000 0x1000>, /* TM */
> + <0x010ad000 0x1000>; /* SROT */
>
> #qcom,sensors = <8>;
> #thermal-sensor-cells = <1>;
> @@ -943,16 +914,107 @@
> };
> };
>
> + ufshc: ufshc@1da4000 {
> + compatible = "qcom,msm8998-ufshc", "qcom,ufshc", "jedec,ufs-2.0";
> + reg = <0x01da4000 0x2500>;
> + interrupts = <GIC_SPI 265 IRQ_TYPE_LEVEL_HIGH>;
> + phys = <&ufsphy_lanes>;
> + phy-names = "ufsphy";
> + lanes-per-direction = <2>;
> + power-domains = <&gcc UFS_GDSC>;
> + #reset-cells = <1>;
> +
> + clock-names =
> + "core_clk",
> + "bus_aggr_clk",
> + "iface_clk",
> + "core_clk_unipro",
> + "ref_clk",
> + "tx_lane0_sync_clk",
> + "rx_lane0_sync_clk",
> + "rx_lane1_sync_clk";
> + clocks =
> + <&gcc GCC_UFS_AXI_CLK>,
> + <&gcc GCC_AGGRE1_UFS_AXI_CLK>,
> + <&gcc GCC_UFS_AHB_CLK>,
> + <&gcc GCC_UFS_UNIPRO_CORE_CLK>,
> + <&rpmcc RPM_SMD_LN_BB_CLK1>,
> + <&gcc GCC_UFS_TX_SYMBOL_0_CLK>,
> + <&gcc GCC_UFS_RX_SYMBOL_0_CLK>,
> + <&gcc GCC_UFS_RX_SYMBOL_1_CLK>;
> + freq-table-hz =
> + <50000000 200000000>,
> + <0 0>,
> + <0 0>,
> + <37500000 150000000>,
> + <0 0>,
> + <0 0>,
> + <0 0>,
> + <0 0>;
> +
> + resets = <&gcc GCC_UFS_BCR>;
> + reset-names = "rst";
> + };
> +
> + ufsphy: phy@1da7000 {
> + compatible = "qcom,msm8998-qmp-ufs-phy";
> + reg = <0x01da7000 0x18c>;
> + #address-cells = <1>;
> + #size-cells = <1>;
> + ranges;
> +
> + clock-names =
> + "ref",
> + "ref_aux";
> + clocks =
> + <&gcc GCC_UFS_CLKREF_CLK>,
> + <&gcc GCC_UFS_PHY_AUX_CLK>;
> +
> + reset-names = "ufsphy";
> + resets = <&ufshc 0>;
> +
> + ufsphy_lanes: lanes@1da7400 {
> + reg = <0x01da7400 0x128>,
> + <0x01da7600 0x1fc>,
> + <0x01da7c00 0x1dc>,
> + <0x01da7800 0x128>,
> + <0x01da7a00 0x1fc>;
> + #phy-cells = <0>;
> + };
> + };
> +
> tcsr_mutex_regs: syscon@1f40000 {
> compatible = "syscon";
> - reg = <0x1f40000 0x20000>;
> + reg = <0x01f40000 0x20000>;
> };
>
> - apcs_glb: mailbox@9820000 {
> - compatible = "qcom,msm8998-apcs-hmss-global";
> - reg = <0x17911000 0x1000>;
> + tlmm: pinctrl@3400000 {
> + compatible = "qcom,msm8998-pinctrl";
> + reg = <0x03400000 0xc00000>;
> + interrupts = <GIC_SPI 208 IRQ_TYPE_LEVEL_HIGH>;
> + gpio-controller;
> + #gpio-cells = <0x2>;
> + interrupt-controller;
> + #interrupt-cells = <0x2>;
> + };
>
> - #mbox-cells = <1>;
> + spmi_bus: spmi@800f000 {
> + compatible = "qcom,spmi-pmic-arb";
> + reg = <0x0800f000 0x1000>,
> + <0x08400000 0x1000000>,
> + <0x09400000 0x1000000>,
> + <0x0a400000 0x220000>,
> + <0x0800a000 0x3000>;
> + reg-names = "core", "chnls", "obsrvr", "intr", "cnfg";
> + interrupt-names = "periph_irq";
> + interrupts = <GIC_SPI 326 IRQ_TYPE_LEVEL_HIGH>;
> + qcom,ee = <0>;
> + qcom,channel = <0>;
> + #address-cells = <2>;
> + #size-cells = <0>;
> + interrupt-controller;
> + #interrupt-cells = <4>;
> + cell-index = <0>;
> };
>
> usb3: usb@a8f8800 {
> @@ -1044,7 +1106,7 @@
>
> sdhc2: sdhci@c0a4900 {
> compatible = "qcom,sdhci-msm-v4";
> - reg = <0xc0a4900 0x314>, <0xc0a4000 0x800>;
> + reg = <0x0c0a4900 0x314>, <0x0c0a4000 0x800>;
> reg-names = "hc_mem", "core_mem";
>
> interrupts = <GIC_SPI 125 IRQ_TYPE_LEVEL_HIGH>,
> @@ -1149,6 +1211,16 @@
> #size-cells = <0>;
> };
>
> + blsp2_uart1: serial@c1b0000 {
> + compatible = "qcom,msm-uartdm-v1.4", "qcom,msm-uartdm";
> + reg = <0x0c1b0000 0x1000>;
> + interrupts = <GIC_SPI 114 IRQ_TYPE_LEVEL_HIGH>;
> + clocks = <&gcc GCC_BLSP2_UART2_APPS_CLK>,
> + <&gcc GCC_BLSP2_AHB_CLK>;
> + clock-names = "core", "iface";
> + status = "disabled";
> + };
> +
> blsp2_i2c0: i2c@c1b5000 {
> compatible = "qcom,i2c-qup-v2.2.1";
> reg = <0x0c1b5000 0x600>;
> @@ -1239,14 +1311,11 @@
> #size-cells = <0>;
> };
>
> - blsp2_uart1: serial@c1b0000 {
> - compatible = "qcom,msm-uartdm-v1.4", "qcom,msm-uartdm";
> - reg = <0xc1b0000 0x1000>;
> - interrupts = <GIC_SPI 114 IRQ_TYPE_LEVEL_HIGH>;
> - clocks = <&gcc GCC_BLSP2_UART2_APPS_CLK>,
> - <&gcc GCC_BLSP2_AHB_CLK>;
> - clock-names = "core", "iface";
> - status = "disabled";
> + apcs_glb: mailbox@17911000 {
> + compatible = "qcom,msm8998-apcs-hmss-global";
> + reg = <0x17911000 0x1000>;
> +
> + #mbox-cells = <1>;
> };
>
> timer@17920000 {
> @@ -1320,75 +1389,6 @@
> redistributor-stride = <0x0 0x20000>;
> interrupts = <GIC_PPI 9 IRQ_TYPE_LEVEL_HIGH>;
> };
> -
> - ufshc: ufshc@1da4000 {
> - compatible = "qcom,msm8998-ufshc", "qcom,ufshc", "jedec,ufs-2.0";
> - reg = <0x01da4000 0x2500>;
> - interrupts = <GIC_SPI 265 IRQ_TYPE_LEVEL_HIGH>;
> - phys = <&ufsphy_lanes>;
> - phy-names = "ufsphy";
> - lanes-per-direction = <2>;
> - power-domains = <&gcc UFS_GDSC>;
> - #reset-cells = <1>;
> -
> - clock-names =
> - "core_clk",
> - "bus_aggr_clk",
> - "iface_clk",
> - "core_clk_unipro",
> - "ref_clk",
> - "tx_lane0_sync_clk",
> - "rx_lane0_sync_clk",
> - "rx_lane1_sync_clk";
> - clocks =
> - <&gcc GCC_UFS_AXI_CLK>,
> - <&gcc GCC_AGGRE1_UFS_AXI_CLK>,
> - <&gcc GCC_UFS_AHB_CLK>,
> - <&gcc GCC_UFS_UNIPRO_CORE_CLK>,
> - <&rpmcc RPM_SMD_LN_BB_CLK1>,
> - <&gcc GCC_UFS_TX_SYMBOL_0_CLK>,
> - <&gcc GCC_UFS_RX_SYMBOL_0_CLK>,
> - <&gcc GCC_UFS_RX_SYMBOL_1_CLK>;
> - freq-table-hz =
> - <50000000 200000000>,
> - <0 0>,
> - <0 0>,
> - <37500000 150000000>,
> - <0 0>,
> - <0 0>,
> - <0 0>,
> - <0 0>;
> -
> - resets = <&gcc GCC_UFS_BCR>;
> - reset-names = "rst";
> - };
> -
> - ufsphy: phy@1da7000 {
> - compatible = "qcom,msm8998-qmp-ufs-phy";
> - reg = <0x01da7000 0x18c>;
> - #address-cells = <1>;
> - #size-cells = <1>;
> - ranges;
> -
> - clock-names =
> - "ref",
> - "ref_aux";
> - clocks =
> - <&gcc GCC_UFS_CLKREF_CLK>,
> - <&gcc GCC_UFS_PHY_AUX_CLK>;
> -
> - reset-names = "ufsphy";
> - resets = <&ufshc 0>;
> -
> - ufsphy_lanes: lanes@1da7400 {
> - reg = <0x01da7400 0x128>,
> - <0x01da7600 0x1fc>,
> - <0x01da7c00 0x1dc>,
> - <0x01da7800 0x128>,
> - <0x01da7a00 0x1fc>;
> - #phy-cells = <0>;
> - };
> - };
> };
> };
>
> --
> 2.17.1
--
~Vinod
^ permalink raw reply
* Re: [PATCH 05/13] dt-bindings: cpufreq: qcom-nvmem: Support pstates provided by a power domain
From: Rob Herring @ 2019-07-24 15:26 UTC (permalink / raw)
To: Niklas Cassel
Cc: Ilia Lin, Andy Gross, Viresh Kumar, Nishanth Menon, Stephen Boyd,
linux-arm-msm, jorge.ramirez-ortiz, bjorn.andersson, ulf.hansson,
Mark Rutland, linux-pm, devicetree, linux-kernel
In-Reply-To: <20190705095726.21433-6-niklas.cassel@linaro.org>
On Fri, Jul 05, 2019 at 11:57:16AM +0200, Niklas Cassel wrote:
> Some Qualcomm SoCs have support for Core Power Reduction (CPR).
> On these platforms, we need to attach to the power domain provider
> providing the performance states, so that the leaky device (the CPU)
> can configure the performance states (which represent different
> CPU clock frequencies).
>
> Signed-off-by: Niklas Cassel <niklas.cassel@linaro.org>
> ---
> .../bindings/opp/qcom-nvmem-cpufreq.txt | 111 ++++++++++++++++++
> 1 file changed, 111 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/opp/qcom-nvmem-cpufreq.txt b/Documentation/devicetree/bindings/opp/qcom-nvmem-cpufreq.txt
> index c5ea8b90e35d..e19a95318e98 100644
> --- a/Documentation/devicetree/bindings/opp/qcom-nvmem-cpufreq.txt
> +++ b/Documentation/devicetree/bindings/opp/qcom-nvmem-cpufreq.txt
> @@ -23,6 +23,15 @@ In 'operating-points-v2' table:
>
> Optional properties:
> --------------------
> +In 'cpus' nodes:
In 'cpus' node or 'cpu' nodes?
> +- power-domains: A phandle pointing to the PM domain specifier which provides
> + the performance states available for active state management.
> + Please refer to the power-domains bindings
> + Documentation/devicetree/bindings/power/power_domain.txt
> + and also examples below.
> +- power-domain-names: Should be
> + - 'cpr' for qcs404.
> +
> In 'operating-points-v2' table:
> - nvmem-cells: A phandle pointing to a nvmem-cells node representing the
> efuse registers that has information about the
^ permalink raw reply
* Re: [PATCH net-next v1 1/4] enetc: Clean up local mdio bus allocation
From: Andrew Lunn @ 2019-07-24 15:18 UTC (permalink / raw)
To: Claudiu Manoil
Cc: David S . Miller, Rob Herring, Li Yang, alexandru.marginean,
netdev, devicetree, linux-arm-kernel, linux-kernel
In-Reply-To: <1563979301-596-2-git-send-email-claudiu.manoil@nxp.com>
On Wed, Jul 24, 2019 at 05:41:38PM +0300, Claudiu Manoil wrote:
> Though it works, this is not how it should have been.
> What's needed is a pointer to the mdio registers.
> Store it properly inside bus->priv allocated space.
> Use devm_* variant to further clean up the init error /
> remove paths.
>
> Fixes following sparse warning:
> warning: incorrect type in assignment (different address spaces)
> expected void *priv
> got struct enetc_mdio_regs [noderef] <asn:2>*[assigned] regs
>
> Fixes: ebfcb23d62ab ("enetc: Add ENETC PF level external MDIO support")
>
> Signed-off-by: Claudiu Manoil <claudiu.manoil@nxp.com>
> ---
> v1 - added this patch
>
> .../net/ethernet/freescale/enetc/enetc_mdio.c | 31 +++++++------------
> 1 file changed, 12 insertions(+), 19 deletions(-)
>
> diff --git a/drivers/net/ethernet/freescale/enetc/enetc_mdio.c b/drivers/net/ethernet/freescale/enetc/enetc_mdio.c
> index 77b9cd10ba2b..1e3cd21c13ee 100644
> --- a/drivers/net/ethernet/freescale/enetc/enetc_mdio.c
> +++ b/drivers/net/ethernet/freescale/enetc/enetc_mdio.c
> @@ -15,7 +15,8 @@ struct enetc_mdio_regs {
> u32 mdio_addr; /* MDIO address */
> };
>
> -#define bus_to_enetc_regs(bus) (struct enetc_mdio_regs __iomem *)((bus)->priv)
> +#define bus_to_enetc_regs(bus) (*(struct enetc_mdio_regs __iomem **) \
> + ((bus)->priv))
>
> #define ENETC_MDIO_REG_OFFSET 0x1c00
> #define ENETC_MDC_DIV 258
> @@ -146,12 +147,12 @@ static int enetc_mdio_read(struct mii_bus *bus, int phy_id, int regnum)
> int enetc_mdio_probe(struct enetc_pf *pf)
> {
> struct device *dev = &pf->si->pdev->dev;
> - struct enetc_mdio_regs __iomem *regs;
> + struct enetc_mdio_regs __iomem **regsp;
> struct device_node *np;
> struct mii_bus *bus;
> - int ret;
> + int err;
>
> - bus = mdiobus_alloc_size(sizeof(regs));
> + bus = devm_mdiobus_alloc_size(dev, sizeof(*regsp));
> if (!bus)
> return -ENOMEM;
>
> @@ -159,41 +160,33 @@ int enetc_mdio_probe(struct enetc_pf *pf)
> bus->read = enetc_mdio_read;
> bus->write = enetc_mdio_write;
> bus->parent = dev;
> + regsp = bus->priv;
> snprintf(bus->id, MII_BUS_ID_SIZE, "%s", dev_name(dev));
>
> /* store the enetc mdio base address for this bus */
> - regs = pf->si->hw.port + ENETC_MDIO_REG_OFFSET;
> - bus->priv = regs;
> + *regsp = pf->si->hw.port + ENETC_MDIO_REG_OFFSET;
This is all very odd and different to every other driver.
If i get the code write, there are 4 registers, each u32 in size,
starting at pf->si->hw.port + ENETC_MDIO_REG_OFFSET?
There are macros like enetc_port_wr() and enetc_global_wr(). It think
it would be much cleaner to add a macro enet_mdio_wr() which takes
hw, off, val.
#define enet_mdio_wr(hw, off, val) enet_port_wr(hw, off + ENETC_MDIO_REG_OFFSET, val)
struct enetc_mdio_priv {
struct enetc_hw *hw;
}
struct enetc_mdio_priv *mdio_priv;
bus = devm_mdiobus_alloc_size(dev, sizeof(*mdio_priv));
mdio_priv = bus->priv;
mdio_priv->hw = pf->si->hw;
static int enetc_mdio_write(struct mii_bus *bus, int phy_id, int regnum,
u16 value)
{
struct enetc_mdio_priv *mdio_priv = bus->priv;
...
enet_mdio_wr(priv->hw, ENETC_MDIO_CFG, mdio_cfg);
}
All the horrible casts go away, the driver is structured like every
other driver, sparse is probably happy, etc.
Andrew
^ permalink raw reply
* Re: [PATCH 03/13] dt-bindings: cpufreq: qcom-nvmem: Make speedbin related properties optional
From: Rob Herring @ 2019-07-24 14:56 UTC (permalink / raw)
Cc: Andy Gross, Ilia Lin, Viresh Kumar, Nishanth Menon, Stephen Boyd,
linux-arm-msm, jorge.ramirez-ortiz, bjorn.andersson, ulf.hansson,
Niklas Cassel, Mark Rutland, linux-pm, devicetree, linux-kernel
In-Reply-To: <20190705095726.21433-4-niklas.cassel@linaro.org>
On Fri, 5 Jul 2019 11:57:14 +0200, Niklas Cassel wrote:
> Not all Qualcomm platforms need to care about the speedbin efuse,
> nor the value blown into the speedbin efuse.
> Therefore, make the nvmem-cells and opp-supported-hw properties
> optional.
>
> Signed-off-by: Niklas Cassel <niklas.cassel@linaro.org>
> ---
> Documentation/devicetree/bindings/opp/qcom-nvmem-cpufreq.txt | 4 ++++
> 1 file changed, 4 insertions(+)
>
Reviewed-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* Re: [PATCH 01/13] dt-bindings: cpufreq: Re-organise kryo cpufreq to use it for other nvmem based qcom socs
From: Rob Herring @ 2019-07-24 14:53 UTC (permalink / raw)
Cc: Viresh Kumar, Nishanth Menon, Stephen Boyd, Ilia Lin, Andy Gross,
linux-arm-msm, jorge.ramirez-ortiz, bjorn.andersson, ulf.hansson,
Sricharan R, Niklas Cassel, Mark Rutland, linux-pm, devicetree,
linux-kernel
In-Reply-To: <20190705095726.21433-2-niklas.cassel@linaro.org>
On Fri, 5 Jul 2019 11:57:12 +0200, Niklas Cassel wrote:
> From: Sricharan R <sricharan@codeaurora.org>
>
> The kryo cpufreq driver reads the nvmem cell and uses that data to
> populate the opps. There are other qcom cpufreq socs like krait which
> does similar thing. Except for the interpretation of the read data,
> rest of the driver is same for both the cases. So pull the common things
> out for reuse.
>
> Signed-off-by: Sricharan R <sricharan@codeaurora.org>
> [niklas.cassel@linaro.org: split dt-binding into a separate patch and
> do not rename the compatible string.]
> Signed-off-by: Niklas Cassel <niklas.cassel@linaro.org>
> ---
> Changes since RFC:
> -Made DT bindings a separate patch.
> -Keep the original compatible string, since renaming it breaks DT
> backwards compatibility.
>
> .../opp/{kryo-cpufreq.txt => qcom-nvmem-cpufreq.txt} | 10 +++++-----
> 1 file changed, 5 insertions(+), 5 deletions(-)
> rename Documentation/devicetree/bindings/opp/{kryo-cpufreq.txt => qcom-nvmem-cpufreq.txt} (98%)
>
Reviewed-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* [PATCH net-next v1 4/4] arm64: dts: fsl: ls1028a: Enable eth port1 on the ls1028a QDS board
From: Claudiu Manoil @ 2019-07-24 14:41 UTC (permalink / raw)
To: David S . Miller
Cc: andrew, Rob Herring, Li Yang, alexandru.marginean, netdev,
devicetree, linux-arm-kernel, linux-kernel
In-Reply-To: <1563979301-596-1-git-send-email-claudiu.manoil@nxp.com>
LS1028a has one Ethernet management interface. On the QDS board, the
MDIO signals are multiplexed to either on-board AR8035 PHY device or
to 4 PCIe slots allowing for SGMII cards.
To enable the Ethernet ENETC Port 1, which can only be connected to a
RGMII PHY, the multiplexer needs to be configured to route the MDIO to
the AR8035 PHY. The MDIO/MDC routing is controlled by bits 7:4 of FPGA
board config register 0x54, and value 0 selects the on-board RGMII PHY.
The FPGA board config registers are accessible on the i2c bus, at address
0x66.
The PF3 MDIO PCIe integrated endpoint device allows for centralized access
to the MDIO bus. Add the corresponding devicetree node and set it to be
the MDIO bus parent.
Signed-off-by: Alex Marginean <alexandru.marginean@nxp.com>
Signed-off-by: Claudiu Manoil <claudiu.manoil@nxp.com>
---
v1 - none
.../boot/dts/freescale/fsl-ls1028a-qds.dts | 40 +++++++++++++++++++
.../arm64/boot/dts/freescale/fsl-ls1028a.dtsi | 6 +++
2 files changed, 46 insertions(+)
diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1028a-qds.dts b/arch/arm64/boot/dts/freescale/fsl-ls1028a-qds.dts
index de6ef39f3118..663c4b728c07 100644
--- a/arch/arm64/boot/dts/freescale/fsl-ls1028a-qds.dts
+++ b/arch/arm64/boot/dts/freescale/fsl-ls1028a-qds.dts
@@ -85,6 +85,26 @@
system-clock-frequency = <25000000>;
};
};
+
+ mdio-mux {
+ compatible = "mdio-mux-multiplexer";
+ mux-controls = <&mux 0>;
+ mdio-parent-bus = <&enetc_mdio_pf3>;
+ #address-cells=<1>;
+ #size-cells = <0>;
+
+ /* on-board RGMII PHY */
+ mdio@0 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0>;
+
+ qds_phy1: ethernet-phy@5 {
+ /* Atheros 8035 */
+ reg = <5>;
+ };
+ };
+ };
};
&duart0 {
@@ -164,6 +184,26 @@
};
};
};
+
+ fpga@66 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ compatible = "fsl,ls1028aqds-fpga", "fsl,fpga-qixis-i2c",
+ "simple-mfd";
+ reg = <0x66>;
+
+ mux: mux-controller {
+ compatible = "reg-mux";
+ #mux-control-cells = <1>;
+ mux-reg-masks = <0x54 0xf0>; /* 0: reg 0x54, bits 7:4 */
+ };
+ };
+
+};
+
+&enetc_port1 {
+ phy-handle = <&qds_phy1>;
+ phy-connection-type = "rgmii-id";
};
&sai1 {
diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1028a.dtsi b/arch/arm64/boot/dts/freescale/fsl-ls1028a.dtsi
index 7975519b4f56..de71153fda00 100644
--- a/arch/arm64/boot/dts/freescale/fsl-ls1028a.dtsi
+++ b/arch/arm64/boot/dts/freescale/fsl-ls1028a.dtsi
@@ -536,6 +536,12 @@
compatible = "fsl,enetc";
reg = <0x000100 0 0 0 0>;
};
+ enetc_mdio_pf3: mdio@0,3 {
+ compatible = "fsl,enetc-mdio";
+ reg = <0x000300 0 0 0 0>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
ethernet@0,4 {
compatible = "fsl,enetc-ptp";
reg = <0x000400 0 0 0 0>;
--
2.17.1
^ permalink raw reply related
* [PATCH net-next v1 3/4] dt-bindings: net: fsl: enetc: Add bindings for the central MDIO PCIe endpoint
From: Claudiu Manoil @ 2019-07-24 14:41 UTC (permalink / raw)
To: David S . Miller
Cc: andrew, Rob Herring, Li Yang, alexandru.marginean, netdev,
devicetree, linux-arm-kernel, linux-kernel
In-Reply-To: <1563979301-596-1-git-send-email-claudiu.manoil@nxp.com>
The on-chip PCIe root complex that integrates the ENETC ethernet
controllers also integrates a PCIe enpoint for the MDIO controller
provinding for cetralized control of the ENETC mdio bus.
Add bindings for this "central" MDIO Integrated PCIe Endpoit.
Signed-off-by: Claudiu Manoil <claudiu.manoil@nxp.com>
---
v1 - none
.../devicetree/bindings/net/fsl-enetc.txt | 42 +++++++++++++++++--
1 file changed, 39 insertions(+), 3 deletions(-)
diff --git a/Documentation/devicetree/bindings/net/fsl-enetc.txt b/Documentation/devicetree/bindings/net/fsl-enetc.txt
index 25fc687419db..c090f6df7a39 100644
--- a/Documentation/devicetree/bindings/net/fsl-enetc.txt
+++ b/Documentation/devicetree/bindings/net/fsl-enetc.txt
@@ -11,7 +11,9 @@ Required properties:
to parent node bindings.
- compatible : Should be "fsl,enetc".
-1) The ENETC external port is connected to a MDIO configurable phy:
+1. The ENETC external port is connected to a MDIO configurable phy
+
+1.1. Using the local ENETC Port MDIO interface
In this case, the ENETC node should include a "mdio" sub-node
that in turn should contain the "ethernet-phy" node describing the
@@ -47,8 +49,42 @@ Example:
};
};
-2) The ENETC port is an internal port or has a fixed-link external
-connection:
+1.2. Using the central MDIO PCIe enpoint device
+
+In this case, the mdio node should be defined as another PCIe
+endpoint node, at the same level with the ENETC port nodes.
+
+Required properties:
+
+- reg : Specifies PCIe Device Number and Function
+ Number of the ENETC endpoint device, according
+ to parent node bindings.
+- compatible : Should be "fsl,enetc-mdio".
+
+The remaining required mdio bus properties are standard, their bindings
+already defined in Documentation/devicetree/bindings/net/mdio.txt.
+
+Example:
+
+ ethernet@0,0 {
+ compatible = "fsl,enetc";
+ reg = <0x000000 0 0 0 0>;
+ phy-handle = <&sgmii_phy0>;
+ phy-connection-type = "sgmii";
+ };
+
+ mdio@0,3 {
+ compatible = "fsl,enetc-mdio";
+ reg = <0x000300 0 0 0 0>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ sgmii_phy0: ethernet-phy@2 {
+ reg = <0x2>;
+ };
+ };
+
+2. The ENETC port is an internal port or has a fixed-link external
+connection
In this case, the ENETC port node defines a fixed link connection,
as specified by Documentation/devicetree/bindings/net/fixed-link.txt.
--
2.17.1
^ permalink raw reply related
* [PATCH net-next v1 2/4] enetc: Add mdio bus driver for the PCIe MDIO endpoint
From: Claudiu Manoil @ 2019-07-24 14:41 UTC (permalink / raw)
To: David S . Miller
Cc: andrew, Rob Herring, Li Yang, alexandru.marginean, netdev,
devicetree, linux-arm-kernel, linux-kernel
In-Reply-To: <1563979301-596-1-git-send-email-claudiu.manoil@nxp.com>
ENETC ports can manage the MDIO bus via local register
interface. However there's also a centralized way
to manage the MDIO bus, via the MDIO PCIe endpoint
device integrated by the same root complex that also
integrates the ENETC ports (eth controllers).
Depending on board design and use case, centralized
access to MDIO may be better than using local ENETC
port registers. For instance, on the LS1028A QDS board
where MDIO muxing is requiered. Also, the LS1028A on-chip
switch doesn't have a local MDIO register interface.
The current patch registers the above PCIe enpoint as a
separate MDIO bus and provides a driver for it by re-using
the code used for local MDIO access. It also allows the
ENETC port PHYs to be managed by this driver if the local
"mdio" node is missing from the ENETC port node.
Signed-off-by: Claudiu Manoil <claudiu.manoil@nxp.com>
---
v1 - fixed mdio bus allocation
- requested only BAR0 region, as it's the only one used by the driver
.../net/ethernet/freescale/enetc/enetc_mdio.c | 90 +++++++++++++++++++
.../net/ethernet/freescale/enetc/enetc_pf.c | 5 +-
2 files changed, 94 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/freescale/enetc/enetc_mdio.c b/drivers/net/ethernet/freescale/enetc/enetc_mdio.c
index 1e3cd21c13ee..378cc8dd27f9 100644
--- a/drivers/net/ethernet/freescale/enetc/enetc_mdio.c
+++ b/drivers/net/ethernet/freescale/enetc/enetc_mdio.c
@@ -190,3 +190,93 @@ void enetc_mdio_remove(struct enetc_pf *pf)
if (pf->mdio)
mdiobus_unregister(pf->mdio);
}
+
+#define ENETC_MDIO_DEV_ID 0xee01
+#define ENETC_MDIO_DEV_NAME "FSL PCIe IE Central MDIO"
+#define ENETC_MDIO_BUS_NAME ENETC_MDIO_DEV_NAME " Bus"
+#define ENETC_MDIO_DRV_NAME ENETC_MDIO_DEV_NAME " driver"
+#define ENETC_MDIO_DRV_ID "fsl_enetc_mdio"
+
+static int enetc_pci_mdio_probe(struct pci_dev *pdev,
+ const struct pci_device_id *ent)
+{
+ struct enetc_mdio_regs __iomem **regsp;
+ struct device *dev = &pdev->dev;
+ struct mii_bus *bus;
+ int err;
+
+ bus = devm_mdiobus_alloc_size(dev, sizeof(*regsp));
+ if (!bus)
+ return -ENOMEM;
+
+ bus->name = ENETC_MDIO_BUS_NAME;
+ bus->read = enetc_mdio_read;
+ bus->write = enetc_mdio_write;
+ bus->parent = dev;
+ regsp = bus->priv;
+ snprintf(bus->id, MII_BUS_ID_SIZE, "%s", dev_name(dev));
+
+ pcie_flr(pdev);
+ err = pci_enable_device_mem(pdev);
+ if (err) {
+ dev_err(dev, "device enable failed\n");
+ return err;
+ }
+
+ err = pci_request_region(pdev, 0, ENETC_MDIO_DRV_ID);
+ if (err) {
+ dev_err(dev, "pci_request_region failed\n");
+ goto err_pci_mem_reg;
+ }
+
+ *regsp = pci_iomap_range(pdev, 0, ENETC_MDIO_REG_OFFSET, 0);
+ if (!bus->priv) {
+ err = -ENXIO;
+ dev_err(dev, "iomap failed\n");
+ goto err_ioremap;
+ }
+
+ err = of_mdiobus_register(bus, dev->of_node);
+ if (err)
+ goto err_mdiobus_reg;
+
+ pci_set_drvdata(pdev, bus);
+
+ return 0;
+
+err_mdiobus_reg:
+ iounmap(*regsp);
+err_ioremap:
+ pci_release_mem_regions(pdev);
+err_pci_mem_reg:
+ pci_disable_device(pdev);
+
+ return err;
+}
+
+static void enetc_pci_mdio_remove(struct pci_dev *pdev)
+{
+ struct mii_bus *bus = pci_get_drvdata(pdev);
+
+ mdiobus_unregister(bus);
+ iounmap(bus_to_enetc_regs(bus));
+ pci_release_mem_regions(pdev);
+ pci_disable_device(pdev);
+}
+
+static const struct pci_device_id enetc_pci_mdio_id_table[] = {
+ { PCI_DEVICE(PCI_VENDOR_ID_FREESCALE, ENETC_MDIO_DEV_ID) },
+ { 0, } /* End of table. */
+};
+MODULE_DEVICE_TABLE(pci, enetc_mdio_id_table);
+
+static struct pci_driver enetc_pci_mdio_driver = {
+ .name = ENETC_MDIO_DRV_ID,
+ .id_table = enetc_pci_mdio_id_table,
+ .probe = enetc_pci_mdio_probe,
+ .remove = enetc_pci_mdio_remove,
+};
+module_pci_driver(enetc_pci_mdio_driver);
+
+MODULE_DESCRIPTION(ENETC_MDIO_DRV_NAME);
+MODULE_LICENSE("Dual BSD/GPL");
diff --git a/drivers/net/ethernet/freescale/enetc/enetc_pf.c b/drivers/net/ethernet/freescale/enetc/enetc_pf.c
index 258b3cb38a6f..7d6513ff8507 100644
--- a/drivers/net/ethernet/freescale/enetc/enetc_pf.c
+++ b/drivers/net/ethernet/freescale/enetc/enetc_pf.c
@@ -750,6 +750,7 @@ static int enetc_of_get_phy(struct enetc_ndev_priv *priv)
{
struct enetc_pf *pf = enetc_si_priv(priv->si);
struct device_node *np = priv->dev->of_node;
+ struct device_node *mdio_np;
int err;
if (!np) {
@@ -773,7 +774,9 @@ static int enetc_of_get_phy(struct enetc_ndev_priv *priv)
priv->phy_node = of_node_get(np);
}
- if (!of_phy_is_fixed_link(np)) {
+ mdio_np = of_get_child_by_name(np, "mdio");
+ if (mdio_np) {
+ of_node_put(mdio_np);
err = enetc_mdio_probe(pf);
if (err) {
of_node_put(priv->phy_node);
--
2.17.1
^ permalink raw reply related
* [PATCH net-next v1 1/4] enetc: Clean up local mdio bus allocation
From: Claudiu Manoil @ 2019-07-24 14:41 UTC (permalink / raw)
To: David S . Miller
Cc: andrew, Rob Herring, Li Yang, alexandru.marginean, netdev,
devicetree, linux-arm-kernel, linux-kernel
In-Reply-To: <1563979301-596-1-git-send-email-claudiu.manoil@nxp.com>
Though it works, this is not how it should have been.
What's needed is a pointer to the mdio registers.
Store it properly inside bus->priv allocated space.
Use devm_* variant to further clean up the init error /
remove paths.
Fixes following sparse warning:
warning: incorrect type in assignment (different address spaces)
expected void *priv
got struct enetc_mdio_regs [noderef] <asn:2>*[assigned] regs
Fixes: ebfcb23d62ab ("enetc: Add ENETC PF level external MDIO support")
Signed-off-by: Claudiu Manoil <claudiu.manoil@nxp.com>
---
v1 - added this patch
.../net/ethernet/freescale/enetc/enetc_mdio.c | 31 +++++++------------
1 file changed, 12 insertions(+), 19 deletions(-)
diff --git a/drivers/net/ethernet/freescale/enetc/enetc_mdio.c b/drivers/net/ethernet/freescale/enetc/enetc_mdio.c
index 77b9cd10ba2b..1e3cd21c13ee 100644
--- a/drivers/net/ethernet/freescale/enetc/enetc_mdio.c
+++ b/drivers/net/ethernet/freescale/enetc/enetc_mdio.c
@@ -15,7 +15,8 @@ struct enetc_mdio_regs {
u32 mdio_addr; /* MDIO address */
};
-#define bus_to_enetc_regs(bus) (struct enetc_mdio_regs __iomem *)((bus)->priv)
+#define bus_to_enetc_regs(bus) (*(struct enetc_mdio_regs __iomem **) \
+ ((bus)->priv))
#define ENETC_MDIO_REG_OFFSET 0x1c00
#define ENETC_MDC_DIV 258
@@ -146,12 +147,12 @@ static int enetc_mdio_read(struct mii_bus *bus, int phy_id, int regnum)
int enetc_mdio_probe(struct enetc_pf *pf)
{
struct device *dev = &pf->si->pdev->dev;
- struct enetc_mdio_regs __iomem *regs;
+ struct enetc_mdio_regs __iomem **regsp;
struct device_node *np;
struct mii_bus *bus;
- int ret;
+ int err;
- bus = mdiobus_alloc_size(sizeof(regs));
+ bus = devm_mdiobus_alloc_size(dev, sizeof(*regsp));
if (!bus)
return -ENOMEM;
@@ -159,41 +160,33 @@ int enetc_mdio_probe(struct enetc_pf *pf)
bus->read = enetc_mdio_read;
bus->write = enetc_mdio_write;
bus->parent = dev;
+ regsp = bus->priv;
snprintf(bus->id, MII_BUS_ID_SIZE, "%s", dev_name(dev));
/* store the enetc mdio base address for this bus */
- regs = pf->si->hw.port + ENETC_MDIO_REG_OFFSET;
- bus->priv = regs;
+ *regsp = pf->si->hw.port + ENETC_MDIO_REG_OFFSET;
np = of_get_child_by_name(dev->of_node, "mdio");
if (!np) {
dev_err(dev, "MDIO node missing\n");
- ret = -EINVAL;
- goto err_registration;
+ return -EINVAL;
}
- ret = of_mdiobus_register(bus, np);
- if (ret) {
+ err = of_mdiobus_register(bus, np);
+ if (err) {
of_node_put(np);
dev_err(dev, "cannot register MDIO bus\n");
- goto err_registration;
+ return err;
}
of_node_put(np);
pf->mdio = bus;
return 0;
-
-err_registration:
- mdiobus_free(bus);
-
- return ret;
}
void enetc_mdio_remove(struct enetc_pf *pf)
{
- if (pf->mdio) {
+ if (pf->mdio)
mdiobus_unregister(pf->mdio);
- mdiobus_free(pf->mdio);
- }
}
--
2.17.1
^ permalink raw reply related
* [PATCH net-next v1 0/4] enetc: Add mdio bus driver for the PCIe MDIO endpoint
From: Claudiu Manoil @ 2019-07-24 14:41 UTC (permalink / raw)
To: David S . Miller
Cc: andrew, Rob Herring, Li Yang, alexandru.marginean, netdev,
devicetree, linux-arm-kernel, linux-kernel
Second patch just registers the PCIe endpoint device containing
the MDIO registers as a standalone MDIO bus driver, to allow
an alternative way to control the MDIO bus. The same code used
by the ENETC ports (eth controllers) to manage MDIO via local
registers applies and is reused.
Bindings are provided for the new MDIO node, similarly to ENETC
port nodes bindings.
Last patch enables the ENETC port 1 and its RGMII PHY on the
LS1028A QDS board, where the MDIO muxing configuration relies
on the MDIO support provided in the first patch.
Claudiu Manoil (4):
enetc: Clean up local mdio bus allocation
enetc: Add mdio bus driver for the PCIe MDIO endpoint
dt-bindings: net: fsl: enetc: Add bindings for the central MDIO PCIe
endpoint
arm64: dts: fsl: ls1028a: Enable eth port1 on the ls1028a QDS board
.../devicetree/bindings/net/fsl-enetc.txt | 42 ++++++-
.../boot/dts/freescale/fsl-ls1028a-qds.dts | 40 ++++++
.../arm64/boot/dts/freescale/fsl-ls1028a.dtsi | 6 +
.../net/ethernet/freescale/enetc/enetc_mdio.c | 119 +++++++++++++++---
.../net/ethernet/freescale/enetc/enetc_pf.c | 5 +-
5 files changed, 190 insertions(+), 22 deletions(-)
--
2.17.1
^ permalink raw reply
* Re: [PATCH V5 1/5] dt-bindings: imx: Add clock binding doc for i.MX8MN
From: Rob Herring @ 2019-07-24 14:41 UTC (permalink / raw)
To: Shawn Guo, Anson Huang
Cc: Michael Turquette, Stephen Boyd, Mark Rutland, Sascha Hauer,
Sascha Hauer, Fabio Estevam, Catalin Marinas, Will Deacon,
Maxime Ripard, Olof Johansson, Simon Horman, Jagan Teki,
Leonard Crestez, Bjorn Andersson, Dinh Nguyen,
Enric Balletbo i Serra, Dong Aisheng, Bai Ping, Abel Vesa, Lucas
In-Reply-To: <20190722015043.GP3738@dragon>
On Sun, Jul 21, 2019 at 7:51 PM Shawn Guo <shawnguo@kernel.org> wrote:
>
> On Wed, Jun 19, 2019 at 01:52:43PM +0800, Anson.Huang@nxp.com wrote:
> > From: Anson Huang <Anson.Huang@nxp.com>
> >
> > Add the clock binding doc for i.MX8MN.
> >
> > Signed-off-by: Anson Huang <Anson.Huang@nxp.com>
> > Reviewed-by: Maxime Ripard <maxime.ripard@bootlin.com>
>
> Applied all, thanks.
This breaks building of 'dt_binding_check'. Looks like there are tabs
in the file which doesn't mix with YAML. Please fix.
Rob
^ permalink raw reply
* Re: [PATCH 1/2] dt-bindings: interconnect: Update Qualcomm SDM845 DT bindings
From: Stephen Boyd @ 2019-07-24 14:18 UTC (permalink / raw)
To: David Dai, bjorn.andersson, georgi.djakov, robh+dt
Cc: evgreen, ilina, seansw, elder, linux-kernel, devicetree,
linux-arm-msm, linux-pm
In-Reply-To: <8c181f08-559b-5d77-a617-65cfd3d5da55@codeaurora.org>
Quoting David Dai (2019-07-23 14:48:42)
> On 7/23/2019 7:42 AM, Stephen Boyd wrote:
> > Quoting David Dai (2019-07-19 13:32:23)
> >> +- compatible : shall contain only one of the following:
> >> + "qcom,sdm845-bcm-voter",
> >> +
> >> +Examples:
> >> +
> >> +apps_rsc: rsc@179c0000 {
> > But there isn't a reg property.
> I'll change this to the generic example with just apps_rsc: rsc {
> >
> >> + label = "apps_rsc";
> > Is label required?
Any answer?
> >
> >> + compatible = "qcom,rpmh-rsc";
> >> +
> >> + apps_bcm_voter: bcm_voter {
> >> + compatible = "qcom,sdm845-bcm-voter";
> >> + };
> >> +}
> >> +
> >> +disp_rsc: rsc@179d0000 {
> >> + label = "disp_rsc";
> >> + compatible = "qcom,rpmh-rsc";
> >> +
> >> + disp_bcm_voter: bcm_voter {
> >> + compatible = "qcom,sdm845-bcm-voter";
> >> + };
> >> +}
> >> diff --git a/Documentation/devicetree/bindings/interconnect/qcom,sdm845.txt b/Documentation/devicetree/bindings/interconnect/qcom,sdm845.txt
> >> index 5c4f1d9..27f9ed9 100644
> >> --- a/Documentation/devicetree/bindings/interconnect/qcom,sdm845.txt
> >> +++ b/Documentation/devicetree/bindings/interconnect/qcom,sdm845.txt
[...]
> >> +
> >> +mem_noc: interconnect@1380000 {
> >> + compatible = "qcom,sdm845-mem_noc";
> >> + reg = <0 0x1380000 0 0x27200>;
> >> + #interconnect-cells = <1>;
> >> + qcom,bcm-voter = <&apps_bcm_voter>, <&disp_bcm_voter>;
> >> +};
> > How does a consumer target a particular RSC? For example, how can
> > display decide to use the disp_bcm_voter node from mem_noc here? Maybe
> > you can add that consumer to the example?
>
> I was thinking that the association between the bcm voters and the icc
> nodes would be handled by the interconnect provider, and that there
> would be a set of display specific icc nodes with their own unique IDs
> that the consumers could reference. I will mention this as part of the
> description and provide an example.
>
> Ex: interconnects = <&mmss_noc MASTER_MDP0_DISP &mem_noc SLAVE_EBI_DISP>;
>
It looks backwards to me. Don't the consumers want to consume a
particular RSC, i.e. apps or display RSC, so they can choose where to
put the bcm vote and then those RSCs want to find MMIO registers for
mmss_noc or mem_noc that they have to write to tune something else like
QoS? If the MMIO space is the provider then I'm lost how it can
differentiate between the RSCs that may be targetting the particular
NoC.
Maybe I've just completely missed something and this is all decided
already. If so, sorry, I'm just trying to understand.
^ permalink raw reply
* Re: [PATCH v4 7/8] dt-bindings: arm: sunxi: add binding for Lichee Zero Plus core board
From: Maxime Ripard @ 2019-07-24 14:14 UTC (permalink / raw)
To: Icenowy Zheng
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA, Linus Walleij,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-gpio-u79uwXL29TY76Z2rM5mHXA,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw, Rob Herring, Chen-Yu Tsai,
linux-clk-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <7d24576697521f4985617113dbc4cc41-h8G6r0blFSE@public.gmane.org>
On Wed, Jul 24, 2019 at 09:09:01PM +0800, Icenowy Zheng wrote:
> 在 2019-07-23 03:29，Maxime Ripard 写道：
> > On Sat, Jul 20, 2019 at 07:39:08PM +0800, Icenowy Zheng wrote:
> > >
> > >
> > > 于 2019年7月20日 GMT+08:00 下午6:13:18, Maxime Ripard
> > > <maxime.ripard-LDxbnhwyfcJBDgjK7y7TUQ@public.gmane.org> 写到:
> > > >On Sat, Jul 13, 2019 at 11:46:33AM +0800, Icenowy Zheng wrote:
> > > >> The Lichee Zero Plus is a core board made by Sipeed, with a microUSB
> > > >> connector on it, TF slot or WSON8 SD chip, optional eMMC or SPI
> > > >Flash.
> > > >> It has a gold finger connector for expansion, and UART is available
> > > >from
> > > >> reserved pins w/ 2.54mm pitch. The board can use either SoChip S3 or
> > > >> Allwinner V3L SoCs.
> > > >>
> > > >> Add the device tree binding of the basic version of the core board --
> > > >> w/o eMMC or SPI Flash, w/ TF slot or WSON8 SD, and use S3 SoC.
> > > >>
> > > >> Signed-off-by: Icenowy Zheng <icenowy-h8G6r0blFSE@public.gmane.org>
> > > >> ---
> > > >> No changes since v3.
> > > >>
> > > >> Patch introduced in v2.
> > > >>
> > > >> Documentation/devicetree/bindings/arm/sunxi.yaml | 5 +++++
> > > >> 1 file changed, 5 insertions(+)
> > > >>
> > > >> diff --git a/Documentation/devicetree/bindings/arm/sunxi.yaml
> > > >b/Documentation/devicetree/bindings/arm/sunxi.yaml
> > > >> index 000a00d12d6a..48c126a7a848 100644
> > > >> --- a/Documentation/devicetree/bindings/arm/sunxi.yaml
> > > >> +++ b/Documentation/devicetree/bindings/arm/sunxi.yaml
> > > >> @@ -353,6 +353,11 @@ properties:
> > > >> - const: licheepi,licheepi-zero
> > > >> - const: allwinner,sun8i-v3s
> > > >>
> > > >> + - description: Lichee Zero Plus (with S3, without eMMC/SPI
> > > >Flash)
> > > >> + items:
> > > >> + - const: sipeed,lichee-zero-plus
> > > >> + - const: allwinner,sun8i-s3
> > > >
> > > >If the S3 is just a rebranded V3, then we should have the v3 compatile
> > > >in that list too.
> > >
> > > S3 is V3 with copackaged DDR3 DRAM.
> > >
> > > It's pin incompatible w/ V3.
> >
> > Does it matter though?
> >
> > If the only thing that changes is the package, we're not manipulating
> > that, and any software that deals with the v3 can deal with the
> > s3. Which is what the compatible is about.
>
> Okay. Should the S3 compatible be kept befoer the V3 one?
Yep, something like (in the DT)
compatible = "sipeed,lichee-zero-plus", "allwinner,sun8i-s3", "allwinner,sun8i-v3"
Maxime
--
Maxime Ripard, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
--
You received this message because you are subscribed to the Google Groups "linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
To view this discussion on the web, visit https://groups.google.com/d/msgid/linux-sunxi/20190724141425.aycdkdwlgmljwpgr%40flea.
^ permalink raw reply
* Re: [PATCH v2 4/5] arm64: dts: qcom: sdm845: remove macro from unit name
From: Stephen Boyd @ 2019-07-24 14:11 UTC (permalink / raw)
To: Andy Gross
Cc: linux-arm-msm, Bjorn Andersson, Vinod Koul, Rob Herring,
Mark Rutland, devicetree, linux-kernel, Amit Kucheria,
Marc Gonzalez
In-Reply-To: <20190724044906.12007-5-vkoul@kernel.org>
Quoting Vinod Koul (2019-07-23 21:49:05)
> Unit name is supposed to be a number, using a macro with hex value is
> not recommended, so add the value in unit name.
>
> arch/arm64/boot/dts/qcom/pm8998.dtsi:81.18-84.6: Warning (unit_address_format): /soc/spmi@c440000/pmic@0/adc@3100/adc-chan@0x06: unit name should not have leading "0x"
> arch/arm64/boot/dts/qcom/pm8998.dtsi:81.18-84.6: Warning (unit_address_format): /soc/spmi@c440000/pmic@0/adc@3100/adc-chan@0x06: unit name should not have leading 0s
>
> Signed-off-by: Vinod Koul <vkoul@kernel.org>
> ---
Reviewed-by: Stephen Boyd <swboyd@chromium.org>
^ permalink raw reply
* Re: [PATCH v2 7/7] arm64: dts: allwinner: a64: enable ANX6345 bridge on Teres-I
From: Maxime Ripard @ 2019-07-24 13:58 UTC (permalink / raw)
To: Vasily Khoruzhick
Cc: Andrzej Hajda, Torsten Duwe, Harald Geyer, Chen-Yu Tsai,
Rob Herring, Mark Rutland, Thierry Reding, David Airlie,
Daniel Vetter, Laurent Pinchart, Icenowy Zheng, Sean Paul,
Greg Kroah-Hartman, Thomas Gleixner, dri-devel, devicetree,
arm-linux, linux-kernel
In-Reply-To: <CA+E=qVeDpLqAM6Qsd6oHfeYHB_JHdSb5GtY7i994GT5_RW4_Bg@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 4866 bytes --]
On Mon, Jul 15, 2019 at 05:28:53PM -0700, Vasily Khoruzhick wrote:
> On Fri, Jul 12, 2019 at 1:15 PM Maxime Ripard <maxime.ripard@bootlin.com> wrote:
> >
> > On Wed, Jul 10, 2019 at 03:11:04PM -0700, Vasily Khoruzhick wrote:
> > > On Wed, Jul 10, 2019 at 4:40 AM Maxime Ripard <maxime.ripard@bootlin.com> wrote:
> > > > > > > There's another issue: if we introduce edp-connector we'll have to
> > > > > > > specify power up delays somewhere (in dts? or in platform driver?), so
> > > > > > > edp-connector doesn't really solve the issue of multiple panels with
> > > > > > > same motherboard.
> > > > > >
> > > > > > And that's what that compatible is about :)
> > > > >
> > > > > Sorry, I fail to see how it would be different from using existing
> > > > > panels infrastructure and different panels compatibles. I think Rob's
> > > > > idea was to introduce generic edp-connector.
> > > >
> > > > Again, there's no such thing as a generic edp-connector. The spec
> > > > doesn't define anything related to the power sequence for example.
> > > >
> > > > > If we can't make it generic then let's use panel infrastructure.
> > > >
> > > > Which uses a device specific compatible. Really, I'm not sure what
> > > > your objection and / or argument is here.
> > > >
> > > > In addition, when that was brought up in the discussion, you rejected
> > > > it because it was inconvenient:
> > > > https://patchwork.freedesktop.org/patch/283012/?series=56163&rev=1#comment_535206
> > >
> > > It is inconvenient, but I don't understand how having board-specific
> > > connectors fixes it.
> >
> > How it would not fix it?
>
> I think I got your idea, but yet I think it's not the best solution.
>
> Do I understand correctly that you're proposing to introduce
> board-specific edp-connector driver that will be aware of worst case
> power up delays and will control backlight and power?
>
> Then why not to add another board-specific panel (e.g.
> "pine64,pinebook-panel") to simple-panel.c that does the same?
That would be fine for me too. Thierry was against it though IIRC, and
I don't recall why exactly.
> > You'll have one connector, without the need to describe each and every
> > panel in the device tree and rely on the EDID instead, and you'll have
> > the option to power up the regulator you need.
> >
> > I really don't understand what's the issue here, so let's take a step
> > back. What are is the issue , what are your requirements, and how
> > would you like that to be described ?
>
> We have a device (Pinebook) that uses the same board with multiple edp
> panels. So far there're pinebooks with 3 different panels: 11" with
> 768p panel, 11" with 1080p panel, 14" with 768p panel.
>
> Currently there's no way to describe all pinebooks with a single dts.
> There's a simple workaround though -- we can just specify a panel with
> worst power up delays in dts and it'll work since anx6345 driver
> ignores panel modes anyway and uses EDID.
>
> Originally I proposed to extend simple-panel driver to support generic
> edp-panel but it was rejected. I still believe that it's the best
> solution assuming we can specify delays in dts, since panels list is
> specific to particular device and it probably can't be reused, i.e.
> there's no good reason to move it into C code.
>
> Rob Herring proposed to introduce edp-connector. While I still believe
> that it's not accurate description of hardware since it'll have to
> have backlight node (backlight is actually panel property) I was OK
> with this approach assuming we can store delays in dts.
>
> Later it evolved into board-specific edp-connector.
I think you got that wrong. As far as I'm concerned, the plan was to
have two compatibles: the board-specific one, and the generic one.
Something like compatible = "pine64,pinebook-edp-connector",
"edp-connector"; or whatever.
> So far I don't understand why everyone is trying to avoid introducing
> edp-panel driver that can read delays from dts. Basically, I don't
> understand what's the magic behind simple-panel.c and why new panels
> should be added there rather than described in dts. [1] Doesn't
> explain that.
So others might have different viewpoints here as well, but the major
downside I see in putting those kind of values in the device tree is
that at some point, someone will get it wrong, and chances are that
even for the same panel, everyone will use a slightly different set of
timings.
And once it's wrong, then it's a mess to fix. You have to track down
every DT using it, make sure it's corrected, and then every user will
have to change their DT in their system. Whereas if you have just a
compatible and those timings in the kernel, then the only thing
required is a kernel update, which should be a pretty standard
operation.
Maxime
--
Maxime Ripard, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH 2/3] RTF: drm/panel: simple: Add TI nspire panels
From: Linus Walleij @ 2019-07-24 13:58 UTC (permalink / raw)
To: Sam Ravnborg,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Rob Herring
Cc: Fabian Vogt, Daniel Tang, Linux ARM, open list:DRM PANEL DRIVERS
In-Reply-To: <20190723175445.GA23588@ravnborg.org>
Hi Sam,
fixed most things, one question remain:
On Tue, Jul 23, 2019 at 7:54 PM Sam Ravnborg <sam@ravnborg.org> wrote:
> Furthermore I did not see any bindings for the panels.
> If they indeed are missing, then please provide bindings in the yaml
> format.
IIUC we do not create binding documents for the simple panels,
but I can do this of course, just vaguely remember that the DT
people didn't want to see bindings that all look the same
but instead rely on panel-common.txt
Yours,
Linus Walleij
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply
* [PATCH 1/2] drm/pl111: Deprecate the pads from the DT binding
From: Linus Walleij @ 2019-07-24 13:49 UTC (permalink / raw)
To: dri-devel, Maarten Lankhorst, Maxime Ripard, Sean Paul
Cc: devicetree, Pawel Moll, Liviu Dudau, Sam Ravnborg,
linux-arm-kernel
The pads were an earlier workaround for the internal image
pipeline in the Linux fbdev subsystem. As we move to generic
definition of display properties and drivers that no longer
need this to work, deprecate this property.
Cc: Sam Ravnborg <sam@ravnborg.org>
Cc: Pawel Moll <pawel.moll@arm.com>
Cc: Liviu Dudau <Liviu.Dudau@arm.com>
Cc: devicetree@vger.kernel.org
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
---
Documentation/devicetree/bindings/display/arm,pl11x.txt | 9 +++++----
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/Documentation/devicetree/bindings/display/arm,pl11x.txt b/Documentation/devicetree/bindings/display/arm,pl11x.txt
index 572fa2773ec4..3f977e72a200 100644
--- a/Documentation/devicetree/bindings/display/arm,pl11x.txt
+++ b/Documentation/devicetree/bindings/display/arm,pl11x.txt
@@ -39,9 +39,11 @@ Required sub-nodes:
- port: describes LCD panel signals, following the common binding
for video transmitter interfaces; see
- Documentation/devicetree/bindings/media/video-interfaces.txt;
- when it is a TFT panel, the port's endpoint must define the
- following property:
+ Documentation/devicetree/bindings/media/video-interfaces.txt
+
+Deprecated properties:
+ The port's endbpoint subnode had this, now deprecated property
+ in the past. Drivers should be able to survive without it:
- arm,pl11x,tft-r0g0b0-pads: an array of three 32-bit values,
defining the way CLD pads are wired up; first value
@@ -80,7 +82,6 @@ Example:
port {
clcd_pads: endpoint {
remote-endpoint = <&clcd_panel>;
- arm,pl11x,tft-r0g0b0-pads = <0 8 16>;
};
};
--
2.21.0
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply related
* Re: [PATCH v2 2/2] dt-bindings: arm: Document Armadeus SoM and Dev boards devicetree binding
From: Rob Herring @ 2019-07-24 13:47 UTC (permalink / raw)
To: Sébastien Szymanski
Cc: Mark Rutland, devicetree, Shawn Guo, Sascha Hauer, NXP Linux Team,
Pengutronix Kernel Team, Fabio Estevam,
moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE
In-Reply-To: <20190724120623.2385-2-sebastien.szymanski@armadeus.com>
On Wed, Jul 24, 2019 at 6:44 AM Sébastien Szymanski
<sebastien.szymanski@armadeus.com> wrote:
>
> Document the following Armadeus SoM and Dev boards devicetree binding
> already supported:
> - armadeus,imx27-apf27 and armadeus,imx27-apf27dev
> - armadeus,imx28-apf28 and armadeus,imx28-apf28dev
> - armadeus,imx51-apf51 and armadeus,imx51-apf51dev
> - armadeus,imx6{q,dl}-apf6 and armadeus,imx{q,dl}-apf6dev
> - armadeus,imx6{ul,ull}-opos6ul and armadeus,imx{ul,ull}-opos6uldev
>
> Signed-off-by: Sébastien Szymanski <sebastien.szymanski@armadeus.com>
> ---
>
> Changes for v2:
> - new patch
>
> Documentation/devicetree/bindings/arm/fsl.yaml | 15 ++++++++++++++-
> 1 file changed, 14 insertions(+), 1 deletion(-)
Reviewed-by: Rob Herring <robh@kernel.org>
_______________________________________________
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/3] dt-bindings: net: dsa: ksz: document Microchip KSZ87xx family switches
From: Marek Vasut @ 2019-07-24 13:40 UTC (permalink / raw)
To: netdev
Cc: Marek Vasut, Andrew Lunn, David S . Miller, Florian Fainelli,
Rob Herring, Tristram Ha, Vivien Didelot, Woojung Huh, devicetree
In-Reply-To: <20190724134048.31029-1-marex@denx.de>
Document Microchip KSZ87xx family switches. These include
KSZ8765 - 5 port switch
KSZ8794 - 4 port switch
KSZ8795 - 5 port switch
Signed-off-by: Marek Vasut <marex@denx.de>
Cc: Andrew Lunn <andrew@lunn.ch>
Cc: David S. Miller <davem@davemloft.net>
Cc: Florian Fainelli <f.fainelli@gmail.com>
Cc: Rob Herring <robh+dt@kernel.org>
Cc: Tristram Ha <Tristram.Ha@microchip.com>
Cc: Vivien Didelot <vivien.didelot@gmail.com>
Cc: Woojung Huh <woojung.huh@microchip.com>
Cc: devicetree@vger.kernel.org
---
Documentation/devicetree/bindings/net/dsa/ksz.txt | 3 +++
1 file changed, 3 insertions(+)
diff --git a/Documentation/devicetree/bindings/net/dsa/ksz.txt b/Documentation/devicetree/bindings/net/dsa/ksz.txt
index 4ac21cef370e..5e8429b6f9ca 100644
--- a/Documentation/devicetree/bindings/net/dsa/ksz.txt
+++ b/Documentation/devicetree/bindings/net/dsa/ksz.txt
@@ -5,6 +5,9 @@ Required properties:
- compatible: For external switch chips, compatible string must be exactly one
of the following:
+ - "microchip,ksz8765"
+ - "microchip,ksz8794"
+ - "microchip,ksz8795"
- "microchip,ksz9477"
- "microchip,ksz9897"
- "microchip,ksz9896"
--
2.20.1
^ permalink raw reply related
* Re: [PATCH 3/3] dt-bindings: aspeed: Remove mention of deprecated compatibles
From: Rob Herring @ 2019-07-24 13:40 UTC (permalink / raw)
To: Andrew Jeffery
Cc: Mark Rutland, devicetree, linux-aspeed, Linus Walleij,
linux-kernel@vger.kernel.org, open list:GPIO SUBSYSTEM,
Joel Stanley, Lee Jones,
moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE
In-Reply-To: <20190724081313.12934-4-andrew@aj.id.au>
On Wed, Jul 24, 2019 at 2:13 AM Andrew Jeffery <andrew@aj.id.au> wrote:
>
> Guide readers away from using the aspeed,g[45].* compatible patterns.
>
> Signed-off-by: Andrew Jeffery <andrew@aj.id.au>
> ---
> Documentation/devicetree/bindings/mfd/aspeed-scu.txt | 2 --
> Documentation/devicetree/bindings/misc/aspeed-p2a-ctrl.txt | 2 --
> .../devicetree/bindings/pinctrl/aspeed,ast2400-pinctrl.yaml | 5 +----
> .../devicetree/bindings/pinctrl/aspeed,ast2500-pinctrl.yaml | 4 +---
> 4 files changed, 2 insertions(+), 11 deletions(-)
Reviewed-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* Re: [PATCH v2 0/9] Exynos Adaptive Supply Voltage support
From: Marek Szyprowski @ 2019-07-24 13:10 UTC (permalink / raw)
To: Viresh Kumar, Sylwester Nawrocki
Cc: krzk, robh+dt, vireshk, devicetree, kgene, pankaj.dubey,
linux-samsung-soc, linux-arm-kernel, linux-kernel, linux-pm,
b.zolnierkie
In-Reply-To: <20190723020450.z2pqwetkn2tfhacq@vireshk-i7>
Hi Viresh,
On 2019-07-23 04:04, Viresh Kumar wrote:
> On 18-07-19, 16:30, Sylwester Nawrocki wrote:
>> This is second iteration of patch series adding ASV (Adaptive Supply
>> Voltage) support for Exynos SoCs. The first one can be found at:
>> https://lore.kernel.org/lkml/20190404171735.12815-1-s.nawrocki@samsung.com
>>
>> The main changes comparing to the first (RFC) version are:
>> - moving ASV data tables from DT to the driver,
>> - converting the chipid and the ASV drivers to use regmap,
>> - converting the ASV driver to proper platform driver.
>>
>> I tried the opp-supported-hw bitmask approach as in the Qualcomm CPUFreq
>> DT bindings but it resulted in too many OPPs and DT nodes, around 200
>> per CPU cluster. So the ASV OPP tables are now in the ASV driver, as in
>> downstream kernels.
> Hmm. Can you explain why do you have so many OPPs? How many
> frequencies do you actually support per cluster and what all varies
> per frequency based on hw ? How many hw version do u have ?
For big cores there are 20 frequencies (2100MHz .. 200MHz). Each SoC
might belong to one of the 3 production 'sets' and each set contains 14
so called 'asv groups', which assign the certain voltage values for each
of those 20 frequencies (the lower asv group means lower voltage needed
for given frequency).
> I am asking as the OPP core can be improved to support your case if
> possible. But I need to understand the problem first.
Best regards
--
Marek Szyprowski, PhD
Samsung R&D Institute Poland
^ permalink raw reply
* Re: [PATCH] ARM: imx25: provide a fixed regulator for usb phys
From: Uwe Kleine-König @ 2019-07-24 13:09 UTC (permalink / raw)
To: Peter Chen, felipe.balbi@linux.intel.com, Marco Felsch
Cc: devicetree@vger.kernel.org, Fabio Estevam,
linux-usb@vger.kernel.org, dl-linux-imx, Pengutronix Kernel Team,
Shawn Guo
In-Reply-To: <VI1PR04MB53270E979BA9817D47A7AFC88BFD0@VI1PR04MB5327.eurprd04.prod.outlook.com>
Hello,
On Thu, Jun 27, 2019 at 03:15:10AM +0000, Peter Chen wrote:
>
> > On 19-06-26 02:40, Peter Chen wrote:
> > >
> > > > Subject: [PATCH] ARM: imx25: provide a fixed regulator for usb phys
> > > >
> > > > The usb phys are internal to the SoC and so it their 5V supply. With
> > > > this regulator added explicitly the following (harmless) boot messages go away:
> > > >
> > > > usb_phy_generic usbphy:usb-phy@0: usbphy:usb-phy@0 supply vcc not found, using dummy regulator
> > > > usb_phy_generic usbphy:usb-phy@1: usbphy:usb-phy@1 supply vcc not found, using dummy regulator
> > > >
> > >
> > > To eliminate the warning message, I suggest doing below changes, as
> > > vcc supply is not mandatory.
> > >
> > > diff --git a/drivers/usb/phy/phy-generic.c
> > > b/drivers/usb/phy/phy-generic.c index a53b89be5324..01a5ff1a0515
> > > 100644
> > > --- a/drivers/usb/phy/phy-generic.c
> > > +++ b/drivers/usb/phy/phy-generic.c
> > > @@ -275,7 +275,7 @@ int usb_phy_gen_create_phy(struct device *dev, struct usb_phy_generic *nop,
> > > }
> > > }
> > >
> > > - nop->vcc = devm_regulator_get(dev, "vcc");
> > > + nop->vcc = devm_regulator_get_optional(dev, "vcc");
> >
> > Is the regulator optional? IMHO this shouldn't be the fix. I think the right fix is Uwe's
> > approach.
> >
>
> Add Felipe.
>
> Some USB PHY's power are from the core system's power (eg, DDR), and some are
> fixed at the board and no switch for it. So, it is transparent for software at some cases.
It's not clear to me how to proceed. There are two opposing opinions and
I don't know enough about USB on mx25 to judge myself.
Felipe?
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-K�nig |
Industrial Linux Solutions | http://www.pengutronix.de/ |
^ permalink raw reply
* Re: [PATCH v4 7/8] dt-bindings: arm: sunxi: add binding for Lichee Zero Plus core board
From: Icenowy Zheng @ 2019-07-24 13:09 UTC (permalink / raw)
To: Maxime Ripard
Cc: devicetree, Linus Walleij, linux-kernel, linux-gpio, linux-sunxi,
Rob Herring, Chen-Yu Tsai, linux-clk, linux-arm-kernel
In-Reply-To: <20190722192934.3jaf3r4rnyeslqyw@flea>
在 2019-07-23 03:29，Maxime Ripard 写道：
> On Sat, Jul 20, 2019 at 07:39:08PM +0800, Icenowy Zheng wrote:
>>
>>
>> 于 2019年7月20日 GMT+08:00 下午6:13:18, Maxime Ripard
>> <maxime.ripard@bootlin.com> 写到:
>> >On Sat, Jul 13, 2019 at 11:46:33AM +0800, Icenowy Zheng wrote:
>> >> The Lichee Zero Plus is a core board made by Sipeed, with a microUSB
>> >> connector on it, TF slot or WSON8 SD chip, optional eMMC or SPI
>> >Flash.
>> >> It has a gold finger connector for expansion, and UART is available
>> >from
>> >> reserved pins w/ 2.54mm pitch. The board can use either SoChip S3 or
>> >> Allwinner V3L SoCs.
>> >>
>> >> Add the device tree binding of the basic version of the core board --
>> >> w/o eMMC or SPI Flash, w/ TF slot or WSON8 SD, and use S3 SoC.
>> >>
>> >> Signed-off-by: Icenowy Zheng <icenowy@aosc.io>
>> >> ---
>> >> No changes since v3.
>> >>
>> >> Patch introduced in v2.
>> >>
>> >> Documentation/devicetree/bindings/arm/sunxi.yaml | 5 +++++
>> >> 1 file changed, 5 insertions(+)
>> >>
>> >> diff --git a/Documentation/devicetree/bindings/arm/sunxi.yaml
>> >b/Documentation/devicetree/bindings/arm/sunxi.yaml
>> >> index 000a00d12d6a..48c126a7a848 100644
>> >> --- a/Documentation/devicetree/bindings/arm/sunxi.yaml
>> >> +++ b/Documentation/devicetree/bindings/arm/sunxi.yaml
>> >> @@ -353,6 +353,11 @@ properties:
>> >> - const: licheepi,licheepi-zero
>> >> - const: allwinner,sun8i-v3s
>> >>
>> >> + - description: Lichee Zero Plus (with S3, without eMMC/SPI
>> >Flash)
>> >> + items:
>> >> + - const: sipeed,lichee-zero-plus
>> >> + - const: allwinner,sun8i-s3
>> >
>> >If the S3 is just a rebranded V3, then we should have the v3 compatile
>> >in that list too.
>>
>> S3 is V3 with copackaged DDR3 DRAM.
>>
>> It's pin incompatible w/ V3.
>
> Does it matter though?
>
> If the only thing that changes is the package, we're not manipulating
> that, and any software that deals with the v3 can deal with the
> s3. Which is what the compatible is about.
Okay. Should the S3 compatible be kept befoer the V3 one?
>
> Maxime
>
> --
> Maxime Ripard, Bootlin
> Embedded Linux and Kernel engineering
> https://bootlin.com
>
> _______________________________________________
> 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 1/3] enetc: Add mdio bus driver for the PCIe MDIO endpoint
From: Claudiu Manoil @ 2019-07-24 12:57 UTC (permalink / raw)
To: Claudiu Manoil, Andrew Lunn
Cc: devicetree@vger.kernel.org, netdev@vger.kernel.org,
Alexandru Marginean, linux-kernel@vger.kernel.org, Leo Li,
Rob Herring, David S . Miller,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <VI1PR04MB4880DAE881769F6DC845CEEF96C60@VI1PR04MB4880.eurprd04.prod.outlook.com>
>-----Original Message-----
>From: netdev-owner@vger.kernel.org <netdev-owner@vger.kernel.org> On
>Behalf Of Claudiu Manoil
>Sent: Wednesday, July 24, 2019 12:53 PM
>To: Andrew Lunn <andrew@lunn.ch>
>Cc: David S . Miller <davem@davemloft.net>; devicetree@vger.kernel.org;
>netdev@vger.kernel.org; Alexandru Marginean
><alexandru.marginean@nxp.com>; linux-kernel@vger.kernel.org; Leo Li
><leoyang.li@nxp.com>; Rob Herring <robh+dt@kernel.org>; linux-arm-
>kernel@lists.infradead.org
>Subject: RE: [PATCH net-next 1/3] enetc: Add mdio bus driver for the PCIe MDIO
>endpoint
>
>>-----Original Message-----
>>From: Andrew Lunn <andrew@lunn.ch>
>>Sent: Wednesday, July 24, 2019 1:25 AM
>>To: Claudiu Manoil <claudiu.manoil@nxp.com>
>>Cc: David S . Miller <davem@davemloft.net>; devicetree@vger.kernel.org;
>>netdev@vger.kernel.org; Alexandru Marginean
>><alexandru.marginean@nxp.com>; linux-kernel@vger.kernel.org; Leo Li
>><leoyang.li@nxp.com>; Rob Herring <robh+dt@kernel.org>; linux-arm-
>>kernel@lists.infradead.org
>>Subject: Re: [PATCH net-next 1/3] enetc: Add mdio bus driver for the
>>PCIe MDIO endpoint
>>
>>> + bus = mdiobus_alloc_size(sizeof(u32 *));
>>> + if (!bus)
>>> + return -ENOMEM;
>>> +
>>
>>> + bus->priv = pci_iomap_range(pdev, 0, ENETC_MDIO_REG_OFFSET, 0);
>>
>>This got me confused for a while. You allocate space for a u32 pointer.
>>bus->priv will point to this space. However, you are not using this
>>space, you {ab}use the pointer to directly hold the return from
>>pci_iomap_range(). This works, but sparse is probably unhappy, and you
>>are wasting the space the u32 pointer takes.
>>
>
>Thanks Andrew,
>This is not what I wanted to do, don't ask me how I got to this, it's confusing
>indeed.
>What's needed here is mdiobus_alloc() or better, devm_mdiobus_alloc().
>I've got to do some cleanup in the local mdio bus probing too.
>Will send v2.
>
This is tricky actually, mdiobus_alloc won't do it, I still need to allocate space
for the pointer.
So it's not ok to store the register space pointer directly into priv
(even if iomap returns void *), it's unusual.
Looks like I will have to use double pointers!
^ 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