* Re: [PATCH 4/7] dt-bindings: timer: renesas, cmt: Add CMT0 and CMT1 to r8a77995
From: Simon Horman @ 2019-07-24 11:13 UTC (permalink / raw)
To: Magnus Damm
Cc: linux-kernel, mark.rutland, devicetree, geert+renesas,
daniel.lezcano, linux-renesas-soc, robh+dt, tglx
In-Reply-To: <156345029298.5307.13303613183227788698.sendpatchset@octo>
On Thu, Jul 18, 2019 at 08:44:53PM +0900, Magnus Damm wrote:
> From: Magnus Damm <damm+renesas@opensource.se>
>
> This patch adds DT binding documentation for the CMT devices on
> the R-Car Gen3 D3 (r8a77995) SoC.
>
> Signed-off-by: Magnus Damm <damm+renesas@opensource.se>
> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
> Reviewed-by: Rob Herring <robh@kernel.org>
Reviewed-by: Simon Horman <horms+renesas@verge.net.au>
^ permalink raw reply
* Re: [PATCH 3/7] dt-bindings: timer: renesas, cmt: Add CMT0 and CMT1 to r8a7792
From: Simon Horman @ 2019-07-24 11:13 UTC (permalink / raw)
To: Magnus Damm
Cc: linux-kernel, mark.rutland, devicetree, geert+renesas,
daniel.lezcano, linux-renesas-soc, robh+dt, tglx
In-Reply-To: <156345027946.5307.6314778386600420219.sendpatchset@octo>
On Thu, Jul 18, 2019 at 08:44:39PM +0900, Magnus Damm wrote:
> From: Magnus Damm <damm+renesas@opensource.se>
>
> This patch adds DT binding documentation for the CMT devices on
> the R-Car Gen2 V2H (r8a7792) SoC.
>
> Signed-off-by: Magnus Damm <damm+renesas@opensource.se>
> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
> Reviewed-by: Rob Herring <robh@kernel.org>
Reviewed-by: Simon Horman <horms+renesas@verge.net.au>
^ permalink raw reply
* Re: [PATCH 2/7] dt-bindings: timer: renesas, cmt: Update CMT1 on sh73a0 and r8a7740
From: Simon Horman @ 2019-07-24 11:12 UTC (permalink / raw)
To: Magnus Damm
Cc: linux-kernel, mark.rutland, devicetree, geert+renesas,
daniel.lezcano, linux-renesas-soc, robh+dt, tglx
In-Reply-To: <156345026539.5307.17098096827162445534.sendpatchset@octo>
On Thu, Jul 18, 2019 at 08:44:25PM +0900, Magnus Damm wrote:
> From: Magnus Damm <damm+renesas@opensource.se>
>
> This patch reworks the DT binding documentation for the 6-channel
> 48-bit CMTs known as CMT1 on r8a7740 and sh73a0.
>
> After the update the same style of DT binding as the rest of the upstream
> SoCs will now also be used by r8a7740 and sh73a0. The DT binding "cmt-48"
> is removed from the DT binding documentation, however software support for
> this deprecated binding will still remain in the CMT driver for some time.
>
> Signed-off-by: Magnus Damm <damm+renesas@opensource.se>
> Reviewed-by: Rob Herring <robh@kernel.org>
Reviewed-by: Simon Horman <horms+renesas@verge.net.au>
^ permalink raw reply
* Re: [PATCH 1/7] dt-bindings: timer: renesas, cmt: Add CMT0234 to sh73a0 and r8a7740
From: Simon Horman @ 2019-07-24 11:12 UTC (permalink / raw)
To: Magnus Damm
Cc: linux-kernel, mark.rutland, devicetree, geert+renesas,
daniel.lezcano, linux-renesas-soc, robh+dt, tglx
In-Reply-To: <156345025207.5307.17135263586186534810.sendpatchset@octo>
On Thu, Jul 18, 2019 at 08:44:12PM +0900, Magnus Damm wrote:
> From: Magnus Damm <damm+renesas@opensource.se>
>
> Document the on-chip CMT devices included in r8a7740 and sh73a0.
>
> Included in this patch is DT binding documentation for 32-bit CMTs
> CMT0, CMT2, CMT3 and CMT4. They all contain a single channel and are
> quite similar however some minor differences still exist:
> - "Counter input clock" (clock input and on-device divider)
> One example is that RCLK 1/1 is supported by CMT2, CMT3 and CMT4.
> - "Wakeup request" (supported by CMT0 and CMT2)
>
> Because of this one unique compat string per CMT device is selected.
>
> Signed-off-by: Magnus Damm <damm+renesas@opensource.se>
> Reviewed-by: Rob Herring <robh@kernel.org>
Reviewed-by: Simon Horman <horms+renesas@verge.net.au>
^ permalink raw reply
* Re: [PATCH 6/7] clocksource/drivers/sh_cmt: r8a7740 and sh73a0 SoC-specific match
From: Simon Horman @ 2019-07-24 11:12 UTC (permalink / raw)
To: Magnus Damm
Cc: linux-kernel, mark.rutland, devicetree, geert+renesas,
daniel.lezcano, linux-renesas-soc, robh+dt, tglx
In-Reply-To: <156345032407.5307.16702422867507502597.sendpatchset@octo>
On Thu, Jul 18, 2019 at 08:45:24PM +0900, Magnus Damm wrote:
> From: Magnus Damm <damm+renesas@opensource.se>
>
> Add SoC-specific matching for CMT1 on r8a7740 and sh73a0.
>
> This allows us to move away from the old DT bindings such as
> - "renesas,cmt-48-sh73a0"
> - "renesas,cmt-48-r8a7740"
> - "renesas,cmt-48"
> in favour for the now commonly used format "renesas,<soc>-<device>"
>
> Signed-off-by: Magnus Damm <damm+renesas@opensource.se>
Reviewed-by: Simon Horman <horms+renesas@verge.net.au>
> ---
>
> drivers/clocksource/sh_cmt.c | 8 ++++++++
> 1 file changed, 8 insertions(+)
>
> --- 0001/drivers/clocksource/sh_cmt.c
> +++ work/drivers/clocksource/sh_cmt.c 2019-07-18 19:29:06.005414716 +0900
> @@ -928,6 +928,14 @@ static const struct of_device_id sh_cmt_
> .data = &sh_cmt_info[SH_CMT0_RCAR_GEN2]
> },
> {
> + .compatible = "renesas,r8a7740-cmt1",
> + .data = &sh_cmt_info[SH_CMT_48BIT]
Perhaps as a follow-up SH_CMT_48BIT could be renamed.
> + },
> + {
> + .compatible = "renesas,sh73a0-cmt1",
> + .data = &sh_cmt_info[SH_CMT_48BIT]
> + },
> + {
> .compatible = "renesas,rcar-gen2-cmt0",
> .data = &sh_cmt_info[SH_CMT0_RCAR_GEN2]
> },
>
^ permalink raw reply
* RE: [PATCH 3/5] clk: imx8mm: correct the usb1_ctrl parent to be usb_bus
From: Jun Li @ 2019-07-24 11:09 UTC (permalink / raw)
To: Shawn Guo
Cc: mark.rutland@arm.com, Peter Chen, Peng Fan, Jacky Bai,
Anson Huang, devicetree@vger.kernel.org, sboyd@kernel.org,
Daniel Baluta, s.hauer@pengutronix.de, linux-clk@vger.kernel.org,
robh+dt@kernel.org, dl-linux-imx, kernel@pengutronix.de,
Aisheng Dong, Leonard Crestez, festevam@gmail.com,
mturquette@baylibre.com, linux-arm-kernel@lists.infradead.org
In-Reply-To: <20190722033418.GX3738@dragon>
> -----Original Message-----
> From: Shawn Guo <shawnguo@kernel.org>
> Sent: 2019年7月22日 11:34
> To: Jun Li <jun.li@nxp.com>
> Cc: sboyd@kernel.org; robh+dt@kernel.org; mark.rutland@arm.com;
> s.hauer@pengutronix.de; kernel@pengutronix.de; festevam@gmail.com; dl-linux-imx
> <linux-imx@nxp.com>; mturquette@baylibre.com; Peter Chen <peter.chen@nxp.com>;
> Jacky Bai <ping.bai@nxp.com>; Leonard Crestez <leonard.crestez@nxp.com>; Daniel
> Baluta <daniel.baluta@nxp.com>; Anson Huang <anson.huang@nxp.com>; Aisheng
> Dong <aisheng.dong@nxp.com>; Peng Fan <peng.fan@nxp.com>;
> devicetree@vger.kernel.org; linux-arm-kernel@lists.infradead.org;
> linux-clk@vger.kernel.org
> Subject: Re: [PATCH 3/5] clk: imx8mm: correct the usb1_ctrl parent to be usb_bus
>
> On Wed, Jul 03, 2019 at 03:23:25PM +0800, jun.li@nxp.com wrote:
> > From: Li Jun <jun.li@nxp.com>
> >
> > Per latest imx8mm datasheet of CCM, the parent of usb1_ctrl_root_clk
> > should be usb_bus.
> >
> > Signed-off-by: Li Jun <jun.li@nxp.com>
>
> I only received 3 patches as a series. In that case, the patches should have subject prefix
> like '[PATCH 1/3]' ...
Another 2 patches are for driver, so I didn't send them to you, yes, I should use
the subject prefix like '[PATCH 1/3]' to avoid confusing, will pay attention this.
Thanks
Li Jun
>
> The patches look good to me. Applied all 3, thanks.
>
> Shawn
>
> > ---
> > drivers/clk/imx/clk-imx8mm.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/clk/imx/clk-imx8mm.c
> > b/drivers/clk/imx/clk-imx8mm.c index 6b8e75d..735cf9d 100644
> > --- a/drivers/clk/imx/clk-imx8mm.c
> > +++ b/drivers/clk/imx/clk-imx8mm.c
> > @@ -631,7 +631,7 @@ static int __init imx8mm_clocks_init(struct device_node
> *ccm_node)
> > clks[IMX8MM_CLK_UART2_ROOT] = imx_clk_gate4("uart2_root_clk", "uart2",
> base + 0x44a0, 0);
> > clks[IMX8MM_CLK_UART3_ROOT] = imx_clk_gate4("uart3_root_clk", "uart3",
> base + 0x44b0, 0);
> > clks[IMX8MM_CLK_UART4_ROOT] = imx_clk_gate4("uart4_root_clk", "uart4",
> base + 0x44c0, 0);
> > - clks[IMX8MM_CLK_USB1_CTRL_ROOT] = imx_clk_gate4("usb1_ctrl_root_clk",
> "usb_core_ref", base + 0x44d0, 0);
> > + clks[IMX8MM_CLK_USB1_CTRL_ROOT] =
> > +imx_clk_gate4("usb1_ctrl_root_clk", "usb_bus", base + 0x44d0, 0);
> > clks[IMX8MM_CLK_GPU3D_ROOT] = imx_clk_gate4("gpu3d_root_clk",
> "gpu3d_div", base + 0x44f0, 0);
> > clks[IMX8MM_CLK_USDHC1_ROOT] = imx_clk_gate4("usdhc1_root_clk",
> "usdhc1", base + 0x4510, 0);
> > clks[IMX8MM_CLK_USDHC2_ROOT] = imx_clk_gate4("usdhc2_root_clk",
> > "usdhc2", base + 0x4520, 0);
> > --
> > 2.7.4
> >
_______________________________________________
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 2/2] dt-bindings: IDU-intc: Add support for edge-triggered interrupts
From: Alexey Brodkin @ 2019-07-24 10:53 UTC (permalink / raw)
To: Mischa Jonker
Cc: Vineet Gupta, kstewart@linuxfoundation.org, tglx@linutronix.de,
robh+dt@kernel.org, linux-snps-arc@lists.infradead.org,
linux-kernel@vger.kernel.org, devicetree@vger.kernel.org
In-Reply-To: <20190723102606.309089-2-mischa.jonker@synopsys.com>
Hi Mischa,
> -----Original Message-----
> From: Mischa Jonker <mischa.jonker@synopsys.com>
> Sent: Tuesday, July 23, 2019 1:26 PM
> To: Vineet Gupta <vgupta@synopsys.com>; Alexey Brodkin <abrodkin@synopsys.com>;
> kstewart@linuxfoundation.org; tglx@linutronix.de; robh+dt@kernel.org; linux-snps-
> arc@lists.infradead.org; linux-kernel@vger.kernel.org; devicetree@vger.kernel.org
> Cc: Mischa Jonker <mischa.jonker@synopsys.com>
> Subject: [PATCH 2/2] dt-bindings: IDU-intc: Add support for edge-triggered interrupts
>
> This updates the documentation for supporting a optional extra interrupt
> cell to specify edge vs level triggered.
LGTM as well. But maybe split pure clean-up changes from addition of
the new property description so that info about addition of new property is
clearly seen? Otherwise it gets a bit lost among nice and useful generic fixes.
-Alexey
^ permalink raw reply
* RE: [PATCH 1/2] ARCv2: IDU-intc: Add support for edge-triggered interrupts
From: Alexey Brodkin @ 2019-07-24 10:47 UTC (permalink / raw)
To: Mischa Jonker
Cc: Vineet Gupta, kstewart@linuxfoundation.org, tglx@linutronix.de,
robh+dt@kernel.org, linux-snps-arc@lists.infradead.org,
linux-kernel@vger.kernel.org, devicetree@vger.kernel.org
In-Reply-To: <20190723102606.309089-1-mischa.jonker@synopsys.com>
Hi Mischa,
> -----Original Message-----
> From: Mischa Jonker <mischa.jonker@synopsys.com>
> Sent: Tuesday, July 23, 2019 1:26 PM
> To: Vineet Gupta <vgupta@synopsys.com>; Alexey Brodkin <abrodkin@synopsys.com>;
> kstewart@linuxfoundation.org; tglx@linutronix.de; robh+dt@kernel.org; linux-snps-
> arc@lists.infradead.org; linux-kernel@vger.kernel.org; devicetree@vger.kernel.org
> Cc: Mischa Jonker <mischa.jonker@synopsys.com>
> Subject: [PATCH 1/2] ARCv2: IDU-intc: Add support for edge-triggered interrupts
>
> This adds support for an optional extra interrupt cell to specify edge
> vs level triggered. It is backward compatible with dts files with only
> one cell, and will default to level-triggered in such a case.
In general LGTM. Still a couple of comments.
It might be useful to explain changes
made to idu_irq_set_affinity() as it's not immediately clear what affinity
has to do with IRQ modes (in theory it should be orthogonal).
But what happens we're actually fixing previously implemented short-cut
when instead of a separately set IRQ mode we were doing it together with
setup of distribution since it's done with the same one command
(anyways we relied on the one and only IRQ type being supported).
And now we have a proper implementation with separated setup of IRQ mode and
affinity.
> static int
> idu_irq_set_affinity(struct irq_data *data, const struct cpumask *cpumask,
> bool force)
> @@ -263,13 +285,32 @@ idu_irq_set_affinity(struct irq_data *data, const struct cpumask *cpumask,
> else
> distribution_mode = IDU_M_DISTRI_RR;
>
> - idu_set_mode(data->hwirq, IDU_M_TRIG_LEVEL, distribution_mode);
> + idu_set_mode(data->hwirq, false, 0, true, distribution_mode);
>
> raw_spin_unlock_irqrestore(&mcip_lock, flags);
>
> return IRQ_SET_MASK_OK;
> }
>
> +static int idu_irq_set_type(struct irq_data *data, u32 type)
> +{
> + unsigned long flags;
> +
> + if (type & ~(IRQ_TYPE_EDGE_RISING | IRQ_TYPE_LEVEL_HIGH))
> + return -EINVAL;
Maybe add an explanation why only these types are supported?
-Alexey
^ permalink raw reply
* Re: [PATCH v2 1/9] soc: samsung: Add exynos chipid driver support
From: Krzysztof Kozlowski @ 2019-07-24 10:47 UTC (permalink / raw)
To: Bartlomiej Zolnierkiewicz
Cc: Sylwester Nawrocki, robh+dt, vireshk, devicetree, kgene,
pankaj.dubey, linux-samsung-soc@vger.kernel.org, linux-arm-kernel,
linux-kernel, linux-pm, Marek Szyprowski
In-Reply-To: <1117f432-8adf-fbe9-f4af-f8acb755326e@samsung.com>
On Tue, 23 Jul 2019 at 16:10, Bartlomiej Zolnierkiewicz
<b.zolnierkie@samsung.com> wrote:
>
>
> Hi Krzysztof,
>
> On 7/23/19 2:57 PM, Krzysztof Kozlowski wrote:
> > On Thu, 18 Jul 2019 at 16:31, Sylwester Nawrocki <s.nawrocki@samsung.com> wrote:
> >>
> >> From: Pankaj Dubey <pankaj.dubey@samsung.com>
> >>
> >> Exynos SoCs have Chipid, for identification of product IDs and SoC
> >> revisions. This patch intends to provide initialization code for all
> >> these functionalities, at the same time it provides some sysfs entries
> >> for accessing these information to user-space.
> >>
> >> This driver uses existing binding for exynos-chipid.
> >>
> >> Changes by Bartlomiej:
> >> - fixed return values on errors
> >> - removed bogus kfree_const()
> >> - added missing Exynos4210 EVT0 id
> >> - converted code to use EXYNOS_MASK define
> >> - fixed np use after of_node_put()
> >> - fixed too early use of dev_info()
> >> - made driver fail for unknown SoC-s
> >> - added SPDX tag
> >> - updated Copyrights
> >>
> >> Signed-off-by: Pankaj Dubey <pankaj.dubey@samsung.com>
> >> [m.szyprowski: for suggestion and code snippet of product_id_to_soc_id]
> >> Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
> >> Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
> >> [s.nawrocki: updated copyright date]
> >> Signed-off-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
> >> ---
> >> drivers/soc/samsung/Kconfig | 5 ++
> >> drivers/soc/samsung/Makefile | 2 +
> >> drivers/soc/samsung/exynos-chipid.c | 111 ++++++++++++++++++++++++++++
> >> 3 files changed, 118 insertions(+)
> >> create mode 100644 drivers/soc/samsung/exynos-chipid.c
> >>
> >> diff --git a/drivers/soc/samsung/Kconfig b/drivers/soc/samsung/Kconfig
> >> index 2186285fda92..2905f5262197 100644
> >> --- a/drivers/soc/samsung/Kconfig
> >> +++ b/drivers/soc/samsung/Kconfig
> >> @@ -7,6 +7,11 @@ menuconfig SOC_SAMSUNG
> >>
> >> if SOC_SAMSUNG
> >>
> >> +config EXYNOS_CHIPID
> >> + bool "Exynos Chipid controller driver" if COMPILE_TEST
> >> + depends on ARCH_EXYNOS || COMPILE_TEST
> >> + select SOC_BUS
> >> +
> >> config EXYNOS_PMU
> >> bool "Exynos PMU controller driver" if COMPILE_TEST
> >> depends on ARCH_EXYNOS || ((ARM || ARM64) && COMPILE_TEST)
> >> diff --git a/drivers/soc/samsung/Makefile b/drivers/soc/samsung/Makefile
> >> index 29f294baac6e..3b6a8797416c 100644
> >> --- a/drivers/soc/samsung/Makefile
> >> +++ b/drivers/soc/samsung/Makefile
> >> @@ -1,4 +1,6 @@
> >> # SPDX-License-Identifier: GPL-2.0
> >> +
> >> +obj-$(CONFIG_EXYNOS_CHIPID) += exynos-chipid.o
> >> obj-$(CONFIG_EXYNOS_PMU) += exynos-pmu.o
> >>
> >> obj-$(CONFIG_EXYNOS_PMU_ARM_DRIVERS) += exynos3250-pmu.o exynos4-pmu.o \
> >> diff --git a/drivers/soc/samsung/exynos-chipid.c b/drivers/soc/samsung/exynos-chipid.c
> >> new file mode 100644
> >> index 000000000000..78b123ee60c0
> >> --- /dev/null
> >> +++ b/drivers/soc/samsung/exynos-chipid.c
> >> @@ -0,0 +1,111 @@
> >> +// SPDX-License-Identifier: GPL-2.0
> >> +/*
> >> + * Copyright (c) 2019 Samsung Electronics Co., Ltd.
> >> + * http://www.samsung.com/
> >> + *
> >> + * EXYNOS - CHIP ID support
> >> + * Author: Pankaj Dubey <pankaj.dubey@samsung.com>
> >> + * Author: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
> >> + */
> >> +
> >> +#include <linux/io.h>
> >> +#include <linux/of.h>
> >> +#include <linux/of_address.h>
> >> +#include <linux/of_platform.h>
> >> +#include <linux/platform_device.h>
> >
> > Any changes here from my previous comments?
> >
> > I have also one more new thought later.
> >
> >> +#include <linux/slab.h>
> >> +#include <linux/sys_soc.h>
> >> +
> >> +#define EXYNOS_SUBREV_MASK (0xF << 4)
> >> +#define EXYNOS_MAINREV_MASK (0xF << 0)
> >> +#define EXYNOS_REV_MASK (EXYNOS_SUBREV_MASK | EXYNOS_MAINREV_MASK)
> >> +#define EXYNOS_MASK 0xFFFFF000
> >> +
> >> +static const struct exynos_soc_id {
> >> + const char *name;
> >> + unsigned int id;
> >> +} soc_ids[] = {
> >> + { "EXYNOS3250", 0xE3472000 },
> >> + { "EXYNOS4210", 0x43200000 }, /* EVT0 revision */
> >> + { "EXYNOS4210", 0x43210000 },
> >> + { "EXYNOS4212", 0x43220000 },
> >> + { "EXYNOS4412", 0xE4412000 },
> >> + { "EXYNOS5250", 0x43520000 },
> >> + { "EXYNOS5260", 0xE5260000 },
> >> + { "EXYNOS5410", 0xE5410000 },
> >> + { "EXYNOS5420", 0xE5420000 },
> >> + { "EXYNOS5440", 0xE5440000 },
> >> + { "EXYNOS5800", 0xE5422000 },
> >> + { "EXYNOS7420", 0xE7420000 },
> >> + { "EXYNOS5433", 0xE5433000 },
> >> +};
> >> +
> >> +static const char * __init product_id_to_soc_id(unsigned int product_id)
> >> +{
> >> + int i;
> >> +
> >> + for (i = 0; i < ARRAY_SIZE(soc_ids); i++)
> >> + if ((product_id & EXYNOS_MASK) == soc_ids[i].id)
> >> + return soc_ids[i].name;
> >> + return NULL;
> >> +}
> >> +
> >> +int __init exynos_chipid_early_init(void)
> >> +{
> >> + struct soc_device_attribute *soc_dev_attr;
> >> + void __iomem *exynos_chipid_base;
> >> + struct soc_device *soc_dev;
> >> + struct device_node *root;
> >> + struct device_node *np;
> >> + u32 product_id;
> >> + u32 revision;
> >> +
> >> + /* look up for chipid node */
> >> + np = of_find_compatible_node(NULL, NULL, "samsung,exynos4210-chipid");
> >> + if (!np)
> >> + return -ENODEV;
> >> +
> >> + exynos_chipid_base = of_iomap(np, 0);
> >> + of_node_put(np);
> >> +
> >> + if (!exynos_chipid_base) {
> >> + pr_err("Failed to map SoC chipid\n");
> >> + return -ENXIO;
> >> + }
> >> +
> >> + product_id = readl_relaxed(exynos_chipid_base);
> >> + revision = product_id & EXYNOS_REV_MASK;
> >> + iounmap(exynos_chipid_base);
> >> +
> >> + soc_dev_attr = kzalloc(sizeof(*soc_dev_attr), GFP_KERNEL);
> >> + if (!soc_dev_attr)
> >> + return -ENOMEM;
> >> +
> >> + soc_dev_attr->family = "Samsung Exynos";
> >> +
> >> + root = of_find_node_by_path("/");
> >> + of_property_read_string(root, "model", &soc_dev_attr->machine);
> >> + of_node_put(root);
> >> +
> >> + soc_dev_attr->revision = kasprintf(GFP_KERNEL, "%x", revision);
> >> + soc_dev_attr->soc_id = product_id_to_soc_id(product_id);
> >> + if (!soc_dev_attr->soc_id) {
> >> + pr_err("Unknown SoC\n");
> >
> > In case of running old kernel on unknown SoC (new revision of existing
> > one or older design not longer supported like 4415), the device will
> > not bind. This was added by Bartlomiej. Why? I imagine that soc driver
> > could be still matched and just report "Unknown". I am not sure if
> > this changes anything, though.
>
> I was thinking that we shouldn't be pretending that we know how to
> handle unsupported SoCs, i.e. that we know how to correctly read its
> product_id and revision.
Reasonable, thanks for explanation.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v4 3/5] drivers: devfreq: events: extend events by type of counted data
From: Chanwoo Choi @ 2019-07-24 10:24 UTC (permalink / raw)
To: Lukasz Luba, devicetree, linux-kernel, linux-pm,
linux-samsung-soc, linux-arm-kernel
Cc: b.zolnierkie, krzk, robh+dt, mark.rutland, kyungmin.park,
m.szyprowski, s.nawrocki, myungjoo.ham, kgene, willy.mh.wolff.ml
In-Reply-To: <37af143f-a585-a28a-a36f-2ed25c5b6d3b@partner.samsung.com>
Hi Lukasz,
On 19. 7. 24. 오후 7:15, Lukasz Luba wrote:
> Hi Chanwoo,
>
> Could you have a look a this patch, please?
> This patch has been rewritten accorifing to your suggestion.
> Krzysztof tried to apply 5/5 DT patch on his current branch,
> but it is missing earlier stuff.
> The other patches have needed ACKs so could go through devfreq tree
> probably, but this one left.
Sorry for the late reply. It looks good to me.
Acked-by: Chanwoo Choi <cw00.choi@samsung.com>
>
> Regards,
> Lukasz
>
> On 6/5/19 11:12 AM, Lukasz Luba wrote:
>> This patch adds posibility to choose what type of data should be counted
>> by the PPMU counter. Now the type comes from DT where the event has been
>> defined. When there is no 'event-data-type' the default value is used,
>> which is 'read+write data in bytes'.
>> It is needed when you want to know not only read+write data bytes but
>> i.e. only write data in byte, or number of read requests, etc.
>>
>> Signed-off-by: Lukasz Luba <l.luba@partner.samsung.com>
>> ---
>> drivers/devfreq/event/exynos-ppmu.c | 60 ++++++++++++++++++++---------
>> include/linux/devfreq-event.h | 6 +++
>> 2 files changed, 47 insertions(+), 19 deletions(-)
>>
>> diff --git a/drivers/devfreq/event/exynos-ppmu.c b/drivers/devfreq/event/exynos-ppmu.c
>> index 17f3c86a6f00..12f637320e9e 100644
>> --- a/drivers/devfreq/event/exynos-ppmu.c
>> +++ b/drivers/devfreq/event/exynos-ppmu.c
>> @@ -161,9 +161,9 @@ static int exynos_ppmu_set_event(struct devfreq_event_dev *edev)
>> if (ret < 0)
>> return ret;
>>
>> - /* Set the event of Read/Write data count */
>> + /* Set the event of proper data type monitoring */
>> ret = regmap_write(info->regmap, PPMU_BEVTxSEL(id),
>> - PPMU_RO_DATA_CNT | PPMU_WO_DATA_CNT);
>> + edev->desc->data_type);
>> if (ret < 0)
>> return ret;
>>
>> @@ -375,23 +375,11 @@ static int exynos_ppmu_v2_set_event(struct devfreq_event_dev *edev)
>> if (ret < 0)
>> return ret;
>>
>> - /* Set the event of Read/Write data count */
>> - switch (id) {
>> - case PPMU_PMNCNT0:
>> - case PPMU_PMNCNT1:
>> - case PPMU_PMNCNT2:
>> - ret = regmap_write(info->regmap, PPMU_V2_CH_EVx_TYPE(id),
>> - PPMU_V2_RO_DATA_CNT | PPMU_V2_WO_DATA_CNT);
>> - if (ret < 0)
>> - return ret;
>> - break;
>> - case PPMU_PMNCNT3:
>> - ret = regmap_write(info->regmap, PPMU_V2_CH_EVx_TYPE(id),
>> - PPMU_V2_EVT3_RW_DATA_CNT);
>> - if (ret < 0)
>> - return ret;
>> - break;
>> - }
>> + /* Set the event of proper data type monitoring */
>> + ret = regmap_write(info->regmap, PPMU_V2_CH_EVx_TYPE(id),
>> + edev->desc->data_type);
>> + if (ret < 0)
>> + return ret;
>>
>> /* Reset cycle counter/performance counter and enable PPMU */
>> ret = regmap_read(info->regmap, PPMU_V2_PMNC, &pmnc);
>> @@ -507,6 +495,7 @@ static int of_get_devfreq_events(struct device_node *np,
>> struct device_node *events_np, *node;
>> int i, j, count;
>> const struct of_device_id *of_id;
>> + int ret;
>>
>> events_np = of_get_child_by_name(np, "events");
>> if (!events_np) {
>> @@ -556,6 +545,39 @@ static int of_get_devfreq_events(struct device_node *np,
>> desc[j].driver_data = info;
>>
>> of_property_read_string(node, "event-name", &desc[j].name);
>> + ret = of_property_read_u32(node, "event-data-type",
>> + &desc[j].data_type);
>> + if (ret) {
>> + /* Set the event of proper data type counting.
>> + * Check if the data type has been defined in DT,
>> + * use default if not.
>> + */
>> + if (info->ppmu_type == EXYNOS_TYPE_PPMU_V2) {
>> + struct devfreq_event_dev edev;
>> + int id;
>> + /* Not all registers take the same value for
>> + * read+write data count.
>> + */
>> + edev.desc = &desc[j];
>> + id = exynos_ppmu_find_ppmu_id(&edev);
>> +
>> + switch (id) {
>> + case PPMU_PMNCNT0:
>> + case PPMU_PMNCNT1:
>> + case PPMU_PMNCNT2:
>> + desc[j].data_type = PPMU_V2_RO_DATA_CNT
>> + | PPMU_V2_WO_DATA_CNT;
>> + break;
>> + case PPMU_PMNCNT3:
>> + desc[j].data_type =
>> + PPMU_V2_EVT3_RW_DATA_CNT;
>> + break;
>> + }
>> + } else {
>> + desc[j].data_type = PPMU_RO_DATA_CNT |
>> + PPMU_WO_DATA_CNT;
>> + }
>> + }
>>
>> j++;
>> }
>> diff --git a/include/linux/devfreq-event.h b/include/linux/devfreq-event.h
>> index 4db00b02ca3f..cc160b1274c0 100644
>> --- a/include/linux/devfreq-event.h
>> +++ b/include/linux/devfreq-event.h
>> @@ -81,14 +81,20 @@ struct devfreq_event_ops {
>> * struct devfreq_event_desc - the descriptor of devfreq-event device
>> *
>> * @name : the name of devfreq-event device.
>> + * @data_type : the data type which is going to be counted in the register.
>> * @driver_data : the private data for devfreq-event driver.
>> * @ops : the operation to control devfreq-event device.
>> *
>> * Each devfreq-event device is described with a this structure.
>> * This structure contains the various data for devfreq-event device.
>> + * The data_type describes what is going to be counted in the register.
>> + * It might choose to count e.g. read requests, write data in bytes, etc.
>> + * The full supported list of types is present in specyfic header in:
>> + * include/dt-bindings/pmu/.
>> */
>> struct devfreq_event_desc {
>> const char *name;
>> + u32 data_type;
>> void *driver_data;
>>
>> const struct devfreq_event_ops *ops;
>>
>
>
--
Best Regards,
Chanwoo Choi
Samsung Electronics
^ permalink raw reply
* Re: [PATCH] extcon: arizona: Update binding example to use available defines
From: Chanwoo Choi @ 2019-07-24 10:16 UTC (permalink / raw)
To: Charles Keepax
Cc: myungjoo.ham, robh+dt, mark.rutland, linux-kernel, devicetree,
patches
In-Reply-To: <20190724094914.19284-1-ckeepax@opensource.cirrus.com>
On 19. 7. 24. 오후 6:49, Charles Keepax wrote:
> Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com>
> ---
> Documentation/devicetree/bindings/extcon/extcon-arizona.txt | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/Documentation/devicetree/bindings/extcon/extcon-arizona.txt b/Documentation/devicetree/bindings/extcon/extcon-arizona.txt
> index 7f3d94ae81ffb..208daaff0be4f 100644
> --- a/Documentation/devicetree/bindings/extcon/extcon-arizona.txt
> +++ b/Documentation/devicetree/bindings/extcon/extcon-arizona.txt
> @@ -72,5 +72,5 @@ codec: wm8280@0 {
> 1 2 1 /* MICDET2 MICBIAS2 GPIO=high */
> >;
>
> - wlf,gpsw = <0>;
> + wlf,gpsw = <ARIZONA_GPSW_OPEN>;
> };
>
Applied it. Thanks.
--
Best Regards,
Chanwoo Choi
Samsung Electronics
^ permalink raw reply
* Re: [PATCH v4 3/5] drivers: devfreq: events: extend events by type of counted data
From: Lukasz Luba @ 2019-07-24 10:15 UTC (permalink / raw)
To: devicetree, linux-kernel, linux-pm, linux-samsung-soc,
linux-arm-kernel, cw00.choi
Cc: b.zolnierkie, krzk, robh+dt, mark.rutland, kyungmin.park,
m.szyprowski, s.nawrocki, myungjoo.ham, kgene, willy.mh.wolff.ml
In-Reply-To: <20190605091236.24263-4-l.luba@partner.samsung.com>
Hi Chanwoo,
Could you have a look a this patch, please?
This patch has been rewritten accorifing to your suggestion.
Krzysztof tried to apply 5/5 DT patch on his current branch,
but it is missing earlier stuff.
The other patches have needed ACKs so could go through devfreq tree
probably, but this one left.
Regards,
Lukasz
On 6/5/19 11:12 AM, Lukasz Luba wrote:
> This patch adds posibility to choose what type of data should be counted
> by the PPMU counter. Now the type comes from DT where the event has been
> defined. When there is no 'event-data-type' the default value is used,
> which is 'read+write data in bytes'.
> It is needed when you want to know not only read+write data bytes but
> i.e. only write data in byte, or number of read requests, etc.
>
> Signed-off-by: Lukasz Luba <l.luba@partner.samsung.com>
> ---
> drivers/devfreq/event/exynos-ppmu.c | 60 ++++++++++++++++++++---------
> include/linux/devfreq-event.h | 6 +++
> 2 files changed, 47 insertions(+), 19 deletions(-)
>
> diff --git a/drivers/devfreq/event/exynos-ppmu.c b/drivers/devfreq/event/exynos-ppmu.c
> index 17f3c86a6f00..12f637320e9e 100644
> --- a/drivers/devfreq/event/exynos-ppmu.c
> +++ b/drivers/devfreq/event/exynos-ppmu.c
> @@ -161,9 +161,9 @@ static int exynos_ppmu_set_event(struct devfreq_event_dev *edev)
> if (ret < 0)
> return ret;
>
> - /* Set the event of Read/Write data count */
> + /* Set the event of proper data type monitoring */
> ret = regmap_write(info->regmap, PPMU_BEVTxSEL(id),
> - PPMU_RO_DATA_CNT | PPMU_WO_DATA_CNT);
> + edev->desc->data_type);
> if (ret < 0)
> return ret;
>
> @@ -375,23 +375,11 @@ static int exynos_ppmu_v2_set_event(struct devfreq_event_dev *edev)
> if (ret < 0)
> return ret;
>
> - /* Set the event of Read/Write data count */
> - switch (id) {
> - case PPMU_PMNCNT0:
> - case PPMU_PMNCNT1:
> - case PPMU_PMNCNT2:
> - ret = regmap_write(info->regmap, PPMU_V2_CH_EVx_TYPE(id),
> - PPMU_V2_RO_DATA_CNT | PPMU_V2_WO_DATA_CNT);
> - if (ret < 0)
> - return ret;
> - break;
> - case PPMU_PMNCNT3:
> - ret = regmap_write(info->regmap, PPMU_V2_CH_EVx_TYPE(id),
> - PPMU_V2_EVT3_RW_DATA_CNT);
> - if (ret < 0)
> - return ret;
> - break;
> - }
> + /* Set the event of proper data type monitoring */
> + ret = regmap_write(info->regmap, PPMU_V2_CH_EVx_TYPE(id),
> + edev->desc->data_type);
> + if (ret < 0)
> + return ret;
>
> /* Reset cycle counter/performance counter and enable PPMU */
> ret = regmap_read(info->regmap, PPMU_V2_PMNC, &pmnc);
> @@ -507,6 +495,7 @@ static int of_get_devfreq_events(struct device_node *np,
> struct device_node *events_np, *node;
> int i, j, count;
> const struct of_device_id *of_id;
> + int ret;
>
> events_np = of_get_child_by_name(np, "events");
> if (!events_np) {
> @@ -556,6 +545,39 @@ static int of_get_devfreq_events(struct device_node *np,
> desc[j].driver_data = info;
>
> of_property_read_string(node, "event-name", &desc[j].name);
> + ret = of_property_read_u32(node, "event-data-type",
> + &desc[j].data_type);
> + if (ret) {
> + /* Set the event of proper data type counting.
> + * Check if the data type has been defined in DT,
> + * use default if not.
> + */
> + if (info->ppmu_type == EXYNOS_TYPE_PPMU_V2) {
> + struct devfreq_event_dev edev;
> + int id;
> + /* Not all registers take the same value for
> + * read+write data count.
> + */
> + edev.desc = &desc[j];
> + id = exynos_ppmu_find_ppmu_id(&edev);
> +
> + switch (id) {
> + case PPMU_PMNCNT0:
> + case PPMU_PMNCNT1:
> + case PPMU_PMNCNT2:
> + desc[j].data_type = PPMU_V2_RO_DATA_CNT
> + | PPMU_V2_WO_DATA_CNT;
> + break;
> + case PPMU_PMNCNT3:
> + desc[j].data_type =
> + PPMU_V2_EVT3_RW_DATA_CNT;
> + break;
> + }
> + } else {
> + desc[j].data_type = PPMU_RO_DATA_CNT |
> + PPMU_WO_DATA_CNT;
> + }
> + }
>
> j++;
> }
> diff --git a/include/linux/devfreq-event.h b/include/linux/devfreq-event.h
> index 4db00b02ca3f..cc160b1274c0 100644
> --- a/include/linux/devfreq-event.h
> +++ b/include/linux/devfreq-event.h
> @@ -81,14 +81,20 @@ struct devfreq_event_ops {
> * struct devfreq_event_desc - the descriptor of devfreq-event device
> *
> * @name : the name of devfreq-event device.
> + * @data_type : the data type which is going to be counted in the register.
> * @driver_data : the private data for devfreq-event driver.
> * @ops : the operation to control devfreq-event device.
> *
> * Each devfreq-event device is described with a this structure.
> * This structure contains the various data for devfreq-event device.
> + * The data_type describes what is going to be counted in the register.
> + * It might choose to count e.g. read requests, write data in bytes, etc.
> + * The full supported list of types is present in specyfic header in:
> + * include/dt-bindings/pmu/.
> */
> struct devfreq_event_desc {
> const char *name;
> + u32 data_type;
> void *driver_data;
>
> const struct devfreq_event_ops *ops;
>
^ permalink raw reply
* Re: [PATCH] extcon: fsa9480: Support the FSA880 variant
From: Chanwoo Choi @ 2019-07-24 10:12 UTC (permalink / raw)
To: Linus Walleij, MyungJoo Ham
Cc: linux-kernel, linux-gpio, Mike Lockwood, devicetree,
cpgs (cpgs@samsung.com)
In-Reply-To: <20190723174301.31278-1-linus.walleij@linaro.org>
On 19. 7. 24. 오전 2:43, Linus Walleij wrote:
> The older compatible variant of this chip is called FSA880
> and works the same way, if we need some quirks in the future,
> it is good to let it have its own compatible string.
>
> Cc: devicetree@vger.kernel.org
> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
> ---
> Documentation/devicetree/bindings/extcon/extcon-fsa9480.txt | 4 +++-
> drivers/extcon/extcon-fsa9480.c | 1 +
> 2 files changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/Documentation/devicetree/bindings/extcon/extcon-fsa9480.txt b/Documentation/devicetree/bindings/extcon/extcon-fsa9480.txt
> index d592c21245f2..624bd76f468e 100644
> --- a/Documentation/devicetree/bindings/extcon/extcon-fsa9480.txt
> +++ b/Documentation/devicetree/bindings/extcon/extcon-fsa9480.txt
> @@ -5,7 +5,9 @@ controlled using I2C and enables USB data, stereo and mono audio, video,
> microphone, and UART data to use a common connector port.
>
> Required properties:
> - - compatible : Must be "fcs,fsa9480"
> + - compatible : Must be one of
> + "fcs,fsa9480"
> + "fcs,fsa880"
> - reg : Specifies i2c slave address. Must be 0x25.
> - interrupts : Should contain one entry specifying interrupt signal of
> interrupt parent to which interrupt pin of the chip is connected.
> diff --git a/drivers/extcon/extcon-fsa9480.c b/drivers/extcon/extcon-fsa9480.c
> index 350fb34abfa0..8405512f5199 100644
> --- a/drivers/extcon/extcon-fsa9480.c
> +++ b/drivers/extcon/extcon-fsa9480.c
> @@ -363,6 +363,7 @@ MODULE_DEVICE_TABLE(i2c, fsa9480_id);
>
> static const struct of_device_id fsa9480_of_match[] = {
> { .compatible = "fcs,fsa9480", },
> + { .compatible = "fcs,fsa880", },
> { },
> };
> MODULE_DEVICE_TABLE(of, fsa9480_of_match);
>
Applied it. Thanks.
--
Best Regards,
Chanwoo Choi
Samsung Electronics
^ permalink raw reply
* Re: [PATCH v4 5/5] DT: arm: exynos4412: add event data type which is monitored
From: Lukasz Luba @ 2019-07-24 10:09 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: devicetree, linux-kernel, linux-pm, linux-samsung-soc,
linux-arm-kernel, b.zolnierkie, robh+dt, mark.rutland, cw00.choi,
kyungmin.park, m.szyprowski, s.nawrocki, myungjoo.ham, kgene,
willy.mh.wolff.ml
In-Reply-To: <20190723175853.GA29195@kozik-lap>
Hi Krzysztof,
On 7/23/19 7:58 PM, Krzysztof Kozlowski wrote:
> On Wed, Jun 05, 2019 at 11:12:36AM +0200, Lukasz Luba wrote:
>> The patch adds new field in the PPMU event which shows explicitly
>> what kind of data the event is monitoring. It is possible to change it
>> using defined values in exynos_ppmu.h file.
>>
>> Acked-by: Chanwoo Choi <cw00.choi@samsung.com>
>> Signed-off-by: Lukasz Luba <l.luba@partner.samsung.com>
>> ---
>> arch/arm/boot/dts/exynos4412-ppmu-common.dtsi | 10 ++++++++++
>> 1 file changed, 10 insertions(+)
>>
>
> I tried to apply this... but prerequisites were not merged into
> v5.3-rc1. This one will have to wait then till next release.
Indeed, I will ask Chanwoo for ack for patch 4/5.
Regards,
Lukasz
>
> Best regards,
> Krzysztof
>
>
>
^ 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 9:55 UTC (permalink / raw)
To: Saeed Mahameed, davem@davemloft.net
Cc: linux-arm-kernel@lists.infradead.org, Leo Li,
devicetree@vger.kernel.org, netdev@vger.kernel.org,
Alexandru Marginean, robh+dt@kernel.org,
linux-kernel@vger.kernel.org
In-Reply-To: <2e3c565cacae6050656aeb7c0132736c60f9f4ee.camel@mellanox.com>
>-----Original Message-----
>From: Saeed Mahameed <saeedm@mellanox.com>
[...]
>
>mdiobus_free(bus) is missing here and in every error path.
>
[...]
>
>this should come last to be symmetrical with probe flow.
>
Will clean these up too. Thanks.
^ 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 9:53 UTC (permalink / raw)
To: Andrew Lunn
Cc: David S . Miller, devicetree@vger.kernel.org,
netdev@vger.kernel.org, Alexandru Marginean,
linux-kernel@vger.kernel.org, Leo Li, Rob Herring,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <20190723222454.GE13517@lunn.ch>
>-----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.
Thanks,
Claudiu
^ permalink raw reply
* [PATCH] extcon: arizona: Update binding example to use available defines
From: Charles Keepax @ 2019-07-24 9:49 UTC (permalink / raw)
To: cw00.choi
Cc: myungjoo.ham, robh+dt, mark.rutland, linux-kernel, devicetree,
patches
Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com>
---
Documentation/devicetree/bindings/extcon/extcon-arizona.txt | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/extcon/extcon-arizona.txt b/Documentation/devicetree/bindings/extcon/extcon-arizona.txt
index 7f3d94ae81ffb..208daaff0be4f 100644
--- a/Documentation/devicetree/bindings/extcon/extcon-arizona.txt
+++ b/Documentation/devicetree/bindings/extcon/extcon-arizona.txt
@@ -72,5 +72,5 @@ codec: wm8280@0 {
1 2 1 /* MICDET2 MICBIAS2 GPIO=high */
>;
- wlf,gpsw = <0>;
+ wlf,gpsw = <ARIZONA_GPSW_OPEN>;
};
--
2.11.0
^ permalink raw reply related
* Re: [PATCH V6 16/21] soc/tegra: pmc: Add pmc wake support for tegra210
From: Dmitry Osipenko @ 2019-07-24 9:31 UTC (permalink / raw)
To: Sowjanya Komatineni, thierry.reding, jonathanh, tglx, jason,
marc.zyngier, linus.walleij, stefan, mark.rutland
Cc: pdeschrijver, pgaikwad, sboyd, linux-clk, linux-gpio, jckuo,
josephl, talho, linux-tegra, linux-kernel, mperttunen, spatra,
robh+dt, devicetree
In-Reply-To: <6fefa6cc-f762-d473-a0ce-248d352a9a53@nvidia.com>
24.07.2019 2:39, Sowjanya Komatineni пишет:
>
> On 7/23/19 7:27 AM, Dmitry Osipenko wrote:
>> 23.07.2019 6:43, Dmitry Osipenko пишет:
>>> 23.07.2019 6:31, Sowjanya Komatineni пишет:
>>>> On 7/22/19 8:25 PM, Dmitry Osipenko wrote:
>>>>> 23.07.2019 6:09, Sowjanya Komatineni пишет:
>>>>>> On 7/22/19 8:03 PM, Dmitry Osipenko wrote:
>>>>>>> 23.07.2019 4:52, Sowjanya Komatineni пишет:
>>>>>>>> On 7/22/19 6:41 PM, Dmitry Osipenko wrote:
>>>>>>>>> 23.07.2019 4:08, Dmitry Osipenko пишет:
>>>>>>>>>> 23.07.2019 3:58, Dmitry Osipenko пишет:
>>>>>>>>>>> 21.07.2019 22:40, Sowjanya Komatineni пишет:
>>>>>>>>>>>> This patch implements PMC wakeup sequence for Tegra210 and
>>>>>>>>>>>> defines
>>>>>>>>>>>> common used RTC alarm wake event.
>>>>>>>>>>>>
>>>>>>>>>>>> Signed-off-by: Sowjanya Komatineni <skomatineni@nvidia.com>
>>>>>>>>>>>> ---
>>>>>>>>>>>> drivers/soc/tegra/pmc.c | 111
>>>>>>>>>>>> ++++++++++++++++++++++++++++++++++++++++++++++++
>>>>>>>>>>>> 1 file changed, 111 insertions(+)
>>>>>>>>>>>>
>>>>>>>>>>>> diff --git a/drivers/soc/tegra/pmc.c b/drivers/soc/tegra/pmc.c
>>>>>>>>>>>> index 91c84d0e66ae..c556f38874e1 100644
>>>>>>>>>>>> --- a/drivers/soc/tegra/pmc.c
>>>>>>>>>>>> +++ b/drivers/soc/tegra/pmc.c
>>>>>>>>>>>> @@ -57,6 +57,12 @@
>>>>>>>>>>>> #define PMC_CNTRL_SYSCLK_OE BIT(11) /* system clock
>>>>>>>>>>>> enable */
>>>>>>>>>>>> #define PMC_CNTRL_SYSCLK_POLARITY BIT(10) /* sys clk
>>>>>>>>>>>> polarity */
>>>>>>>>>>>> #define PMC_CNTRL_MAIN_RST BIT(4)
>>>>>>>>>>>> +#define PMC_CNTRL_LATCH_WAKEUPS BIT(5)
>>>>>>>>>> Please follow the TRM's bits naming.
>>>>>>>>>>
>>>>>>>>>> PMC_CNTRL_LATCHWAKE_EN
>>>>>>>>>>
>>>>>>>>>>>> +#define PMC_WAKE_MASK 0x0c
>>>>>>>>>>>> +#define PMC_WAKE_LEVEL 0x10
>>>>>>>>>>>> +#define PMC_WAKE_STATUS 0x14
>>>>>>>>>>>> +#define PMC_SW_WAKE_STATUS 0x18
>>>>>>>>>>>> #define DPD_SAMPLE 0x020
>>>>>>>>>>>> #define DPD_SAMPLE_ENABLE BIT(0)
>>>>>>>>>>>> @@ -87,6 +93,11 @@
>>>>>>>>>>>> #define PMC_SCRATCH41 0x140
>>>>>>>>>>>> +#define PMC_WAKE2_MASK 0x160
>>>>>>>>>>>> +#define PMC_WAKE2_LEVEL 0x164
>>>>>>>>>>>> +#define PMC_WAKE2_STATUS 0x168
>>>>>>>>>>>> +#define PMC_SW_WAKE2_STATUS 0x16c
>>>>>>>>>>>> +
>>>>>>>>>>>> #define PMC_SENSOR_CTRL 0x1b0
>>>>>>>>>>>> #define PMC_SENSOR_CTRL_SCRATCH_WRITE BIT(2)
>>>>>>>>>>>> #define PMC_SENSOR_CTRL_ENABLE_RST BIT(1)
>>>>>>>>>>>> @@ -1922,6 +1933,55 @@ static const struct irq_domain_ops
>>>>>>>>>>>> tegra_pmc_irq_domain_ops = {
>>>>>>>>>>>> .alloc = tegra_pmc_irq_alloc,
>>>>>>>>>>>> };
>>>>>>>>>>>> +static int tegra210_pmc_irq_set_wake(struct irq_data
>>>>>>>>>>>> *data,
>>>>>>>>>>>> unsigned int on)
>>>>>>>>>>>> +{
>>>>>>>>>>>> + struct tegra_pmc *pmc = irq_data_get_irq_chip_data(data);
>>>>>>>>>>>> + unsigned int offset, bit;
>>>>>>>>>>>> + u32 value;
>>>>>>>>>>>> +
>>>>>>>>>>>> + if (data->hwirq == ULONG_MAX)
>>>>>>>>>>>> + return 0;
>>>>>>>>>>>> +
>>>>>>>>>>>> + offset = data->hwirq / 32;
>>>>>>>>>>>> + bit = data->hwirq % 32;
>>>>>>>>>>>> +
>>>>>>>>>>>> + /*
>>>>>>>>>>>> + * Latch wakeups to SW_WAKE_STATUS register to capture
>>>>>>>>>>>> events
>>>>>>>>>>>> + * that would not make it into wakeup event register
>>>>>>>>>>>> during
>>>>>>>>>>>> LP0 exit.
>>>>>>>>>>>> + */
>>>>>>>>>>>> + value = tegra_pmc_readl(pmc, PMC_CNTRL);
>>>>>>>>>>>> + value |= PMC_CNTRL_LATCH_WAKEUPS;
>>>>>>>>>>>> + tegra_pmc_writel(pmc, value, PMC_CNTRL);
>>>>>>>>>>>> + udelay(120);
>>>>>>>>>>> Why it takes so much time to latch the values? Shouldn't some
>>>>>>>>>>> status-bit
>>>>>>>>>>> be polled for the completion of latching?
>>>>>>>>>>>
>>>>>>>>>>> Is this register-write really getting buffered in the PMC?
>>>>>>>>>>>
>>>>>>>>>>>> + value &= ~PMC_CNTRL_LATCH_WAKEUPS;
>>>>>>>>>>>> + tegra_pmc_writel(pmc, value, PMC_CNTRL);
>>>>>>>>>>>> + udelay(120);
>>>>>>>>>>> 120 usecs to remove latching, really?
>>>>>>>>>>>
>>>>>>>>>>>> + tegra_pmc_writel(pmc, 0, PMC_SW_WAKE_STATUS);
>>>>>>>>>>>> + tegra_pmc_writel(pmc, 0, PMC_SW_WAKE2_STATUS);
>>>>>>>>>>>> +
>>>>>>>>>>>> + tegra_pmc_writel(pmc, 0, PMC_WAKE_STATUS);
>>>>>>>>>>>> + tegra_pmc_writel(pmc, 0, PMC_WAKE2_STATUS);
>>>>>>>>>>>> +
>>>>>>>>>>>> + /* enable PMC wake */
>>>>>>>>>>>> + if (data->hwirq >= 32)
>>>>>>>>>>>> + offset = PMC_WAKE2_MASK;
>>>>>>>>>>>> + else
>>>>>>>>>>>> + offset = PMC_WAKE_MASK;
>>>>>>>>>>>> +
>>>>>>>>>>>> + value = tegra_pmc_readl(pmc, offset);
>>>>>>>>>>>> +
>>>>>>>>>>>> + if (on)
>>>>>>>>>>>> + value |= 1 << bit;
>>>>>>>>>>>> + else
>>>>>>>>>>>> + value &= ~(1 << bit);
>>>>>>>>>>>> +
>>>>>>>>>>>> + tegra_pmc_writel(pmc, value, offset);
>>>>>>>>>>> Why the latching is done *before* writing into the WAKE
>>>>>>>>>>> registers?
>>>>>>>>>>> What
>>>>>>>>>>> it is latching then?
>>>>>>>>>> I'm looking at the TRM doc and it says that latching should be
>>>>>>>>>> done
>>>>>>>>>> *after* writing to the WAKE_MASK / LEVEL registers.
>>>>>>>>>>
>>>>>>>>>> Secondly it says that it's enough to do:
>>>>>>>>>>
>>>>>>>>>> value = tegra_pmc_readl(pmc, PMC_CNTRL);
>>>>>>>>>> value |= PMC_CNTRL_LATCH_WAKEUPS;
>>>>>>>>>> tegra_pmc_writel(pmc, value, PMC_CNTRL);
>>>>>>>>>>
>>>>>>>>>> in order to latch. There is no need for the delay and to
>>>>>>>>>> remove the
>>>>>>>>>> "LATCHWAKE_EN" bit, it should be a oneshot action.
>>>>>>>>> Although, no. TRM says "stops latching on transition from 1
>>>>>>>>> to 0 (sequence - set to 1,set to 0)", so it's not a oneshot
>>>>>>>>> action.
>>>>>>>>>
>>>>>>>>> Have you tested this code at all? I'm wondering how it happens to
>>>>>>>>> work
>>>>>>>>> without a proper latching.
>>>>>>>> Yes, ofcourse its tested and this sequence to do transition is
>>>>>>>> recommendation from Tegra designer.
>>>>>>>> Will check if TRM doesn't have update properly or will re-confirm
>>>>>>>> internally on delay time...
>>>>>>>>
>>>>>>>> On any of the wake event PMC wakeup happens and WAKE_STATUS
>>>>>>>> register
>>>>>>>> will have bits set for all events that triggered wake.
>>>>>>>> After wakeup PMC doesn't update SW_WAKE_STATUS register as per PMC
>>>>>>>> design.
>>>>>>>> SW latch register added in design helps to provide a way to capture
>>>>>>>> those events that happen right during wakeup time and didnt make
>>>>>>>> it to
>>>>>>>> SW_WAKE_STATUS register.
>>>>>>>> So before next suspend entry, latching all prior wake events
>>>>>>>> into SW
>>>>>>>> WAKE_STATUS and then clearing them.
>>>>>>> I'm now wondering whether the latching cold be turned ON permanently
>>>>>>> during of the PMC's probe, for simplicity.
>>>>>> latching should be done on suspend-resume cycle as wake events gets
>>>>>> generates on every suspend-resume cycle.
>>>>> You're saying that PMC "doesn't update SW_WAKE_STATUS" after wake-up,
>>>>> then I don't quite understand what's the point of disabling the
>>>>> latching
>>>>> at all.
>>>> When latch wake enable is set, events are latched and during 1 to 0
>>>> transition latching is disabled.
>>>>
>>>> This is to avoid sw_wake_status and wake_status showing diff events.
>>> Okay.
>>>
>>>> Currently driver is not relying on SW_WAKE_STATUS but its good to latch
>>>> and clear so even at some point for some reason when SW_WAKE_STATUS is
>>>> used, this wlil not cause mismatch with wake_status.
>>> Then the latching need to be enabled on suspend and disabled early on
>>> resume to get a proper WAKE status.
>> Actually, it will be better to simply not implement the latching until
>> it will become really needed. In general you shouldn't add into the
>> patchset anything that is unused.
>
> OK, will remove latch_wake for now.
>
> Will send next version once I get all the review feedback ..
>
That's not a bad idea. Wait for one-two weeks and if it will happen that
nobody is replying, then just issue a new version.
^ permalink raw reply
* Re: [PATCH v6 11/22] clk: sunxi-ng: a64: Add minimum rate for PLL_MIPI
From: Maxime Ripard @ 2019-07-24 9:05 UTC (permalink / raw)
To: Jagan Teki
Cc: Michael Nazzareno Trimarchi, David Airlie, Daniel Vetter,
Chen-Yu Tsai, Michael Turquette, Rob Herring, Mark Rutland,
linux-arm-kernel, linux-kernel, linux-clk, dri-devel, devicetree,
linux-amarula, linux-sunxi
In-Reply-To: <CAMty3ZDpOA1mD77t3RB6hEG7o3+ws8y64m1DU8=3HdZ4zy4AUw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 8910 bytes --]
On Mon, Jul 22, 2019 at 03:51:04PM +0530, Jagan Teki wrote:
> Hi Maxime,
>
> On Sat, Jul 20, 2019 at 3:02 PM Maxime Ripard <maxime.ripard-LDxbnhwyfcJBDgjK7y7TUQ@public.gmane.org> wrote:
> >
> > On Sat, Jul 20, 2019 at 12:46:27PM +0530, Jagan Teki wrote:
> > > On Sat, Jul 20, 2019 at 12:28 PM Maxime Ripard
> > > <maxime.ripard-LDxbnhwyfcJBDgjK7y7TUQ@public.gmane.org> wrote:
> > > >
> > > > On Thu, Jul 11, 2019 at 07:43:16PM +0200, Michael Nazzareno Trimarchi wrote:
> > > > > > > tcon-pixel clock is the rate that you want to achive on display side
> > > > > > > and if you have 4 lanes 32bit or lanes and different bit number that
> > > > > > > you need to have a clock that is able to put outside bits and speed
> > > > > > > equal to pixel-clock * bits / lanes. so If you want a pixel-clock of
> > > > > > > 40 mhz and you have 32bits and 4 lanes you need to have a clock of
> > > > > > > 40 * 32 / 4 in no-burst mode. I think that this is done but most of
> > > > > > > the display.
> > > > > >
> > > > > > So this is what the issue is then?
> > > > > >
> > > > > > This one does make sense, and you should just change the rate in the
> > > > > > call to clk_set_rate in sun4i_tcon0_mode_set_cpu.
> > > > > >
> > > > > > I'm still wondering why that hasn't been brought up in either the
> > > > > > discussion or the commit log before though.
> > > > > >
> > > > > Something like this?
> > > > >
> > > > > drivers/gpu/drm/sun4i/sun4i_tcon.c | 20 +++++++++++---------
> > > > > drivers/gpu/drm/sun4i/sun6i_mipi_dsi.h | 2 --
> > > > > 2 files changed, 11 insertions(+), 11 deletions(-)
> > > > >
> > > > > diff --git a/drivers/gpu/drm/sun4i/sun4i_tcon.c
> > > > > b/drivers/gpu/drm/sun4i/sun4i_tcon.c
> > > > > index 64c43ee6bd92..42560d5c327c 100644
> > > > > --- a/drivers/gpu/drm/sun4i/sun4i_tcon.c
> > > > > +++ b/drivers/gpu/drm/sun4i/sun4i_tcon.c
> > > > > @@ -263,10 +263,11 @@ static int sun4i_tcon_get_clk_delay(const struct
> > > > > drm_display_mode *mode,
> > > > > }
> > > > >
> > > > > static void sun4i_tcon0_mode_set_common(struct sun4i_tcon *tcon,
> > > > > - const struct drm_display_mode *mode)
> > > > > + const struct drm_display_mode *mode,
> > > > > + u32 tcon_mul)
> > > > > {
> > > > > /* Configure the dot clock */
> > > > > - clk_set_rate(tcon->dclk, mode->crtc_clock * 1000);
> > > > > + clk_set_rate(tcon->dclk, mode->crtc_clock * tcon_mul * 1000);
> > > > >
> > > > > /* Set the resolution */
> > > > > regmap_write(tcon->regs, SUN4I_TCON0_BASIC0_REG,
> > > > > @@ -335,12 +336,13 @@ static void sun4i_tcon0_mode_set_cpu(struct
> > > > > sun4i_tcon *tcon,
> > > > > u8 bpp = mipi_dsi_pixel_format_to_bpp(device->format);
> > > > > u8 lanes = device->lanes;
> > > > > u32 block_space, start_delay;
> > > > > - u32 tcon_div;
> > > > > + u32 tcon_div, tcon_mul;
> > > > >
> > > > > - tcon->dclk_min_div = SUN6I_DSI_TCON_DIV;
> > > > > - tcon->dclk_max_div = SUN6I_DSI_TCON_DIV;
> > > > > + tcon->dclk_min_div = 4;
> > > > > + tcon->dclk_max_div = 127;
> > > > >
> > > > > - sun4i_tcon0_mode_set_common(tcon, mode);
> > > > > + tcon_mul = bpp / lanes;
> > > > > + sun4i_tcon0_mode_set_common(tcon, mode, tcon_mul);
> > > > >
> > > > > /* Set dithering if needed */
> > > > > sun4i_tcon0_mode_set_dithering(tcon, sun4i_tcon_get_connector(encoder));
> > > > > @@ -366,7 +368,7 @@ static void sun4i_tcon0_mode_set_cpu(struct
> > > > > sun4i_tcon *tcon,
> > > > > */
> > > > > regmap_read(tcon->regs, SUN4I_TCON0_DCLK_REG, &tcon_div);
> > > > > tcon_div &= GENMASK(6, 0);
> > > > > - block_space = mode->htotal * bpp / (tcon_div * lanes);
> > > > > + block_space = mode->htotal * tcon_div * tcon_mul;
> > > > > block_space -= mode->hdisplay + 40;
> > > > >
> > > > > regmap_write(tcon->regs, SUN4I_TCON0_CPU_TRI0_REG,
> > > > > @@ -408,7 +410,7 @@ static void sun4i_tcon0_mode_set_lvds(struct
> > > > > sun4i_tcon *tcon,
> > > > >
> > > > > tcon->dclk_min_div = 7;
> > > > > tcon->dclk_max_div = 7;
> > > > > - sun4i_tcon0_mode_set_common(tcon, mode);
> > > > > + sun4i_tcon0_mode_set_common(tcon, mode, 1);
> > > > >
> > > > > /* Set dithering if needed */
> > > > > sun4i_tcon0_mode_set_dithering(tcon, sun4i_tcon_get_connector(encoder));
> > > > > @@ -487,7 +489,7 @@ static void sun4i_tcon0_mode_set_rgb(struct
> > > > > sun4i_tcon *tcon,
> > > > >
> > > > > tcon->dclk_min_div = 6;
> > > > > tcon->dclk_max_div = 127;
> > > > > - sun4i_tcon0_mode_set_common(tcon, mode);
> > > > > + sun4i_tcon0_mode_set_common(tcon, mode, 1);
> > > > >
> > > > > /* Set dithering if needed */
> > > > > sun4i_tcon0_mode_set_dithering(tcon, connector);
> > > > > diff --git a/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.h
> > > > > b/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.h
> > > > > index 5c3ad5be0690..a07090579f84 100644
> > > > > --- a/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.h
> > > > > +++ b/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.h
> > > > > @@ -13,8 +13,6 @@
> > > > > #include <drm/drm_encoder.h>
> > > > > #include <drm/drm_mipi_dsi.h>
> > > > >
> > > > > -#define SUN6I_DSI_TCON_DIV 4
> > > > > -
> > > > > struct sun6i_dsi {
> > > > > struct drm_connector connector;
> > > > > struct drm_encoder encoder;
> > > >
> > > > I had more something like this in mind:
> > > > http://code.bulix.org/nlp5a4-803511
> > >
> > > Worth to look at it. was it working on your panel? meanwhile I will check it.
> >
> > I haven't tested it.
> >
> > > We have updated with below change [1], seems working on but is
> > > actually checking the each divider as before start with 4... till 127.
> > >
> > > This new approach, is start looking the best divider from 4.. based on
> > > the idea vs rounded it will ended up best divider like [2]
> >
> > But why?
> >
> > I mean, it's not like it's the first time I'm asking this...
> >
> > If the issue is what Micheal described, then the divider has nothing
> > to do with it. We've had that discussion over and over again.
>
> This is what Michael is mentioned in above mail "tcon-pixel clock is
> the rate that you want to achive on display side and if you have 4
> lanes 32bit or lanes and different bit number that you need to have
> a clock that is able to put outside bits and speed equal to
> pixel-clock * bits / lanes. so If you want a pixel-clock of 40 mhz
> and you have 32bits and 4 lanes you need to have a clock of 40 * 32
> / 4 in no-burst mode. "
Yeah, so we need to change the clock rate.
> He is trying to manage the bpp/lanes into dclk_mul (in last mail)
> and it can multiply with pixel clock which is rate argument in
> sun4i_dclk_round_rate.
>
> The solution I have mentioned in dclk_min, max is bpp/lanes also
> multiple rate in dotclock sun4i_dclk_round_rate.
>
> In both cases the overall pll_rate depends on dividers, the one that I
> have on this patch is based on BSP and the Michael one is more generic
> way so-that it can not to touch other functionalities and looping
> dividers to find the best one.
>
> If dclk_min/max is bpp/lanes then dotclock directly using divider 6
> (assuming 24-bit and 4 lanes) and return the pll_rate and divider 6
> associated.
>
> if dclk_mul is bpp/lanes, on Michael new change, the dividers start
> with 4 and end with 127 but the constant ideal rate which rate *
> bpp/lanes but the loop from sun4i_dclk_round_rate computed the divider
> as 6 only, ie what I'm mentioned on the above mail.
We've been over this a couple of times already.
The clock is generated like this:
PLL -> TCON Module Clock -> TCON DCLK
You want the TCON DCLK to be at the pixel clock rate * bpp /
lanes. Fine, that makes sense.
Except that the patch you've sent, instead of changing the rate
itself, changes the ratio between the module clock and DCLK.
And this is where the issue lies. First, from a logical viewpoint, it
doesn't make sense. If you want to change the clock rate, then just do
it. Don't hack around the multipliers trying to fall back to something
that works for you.
Then, the ratio itself needs to be set to 4. This is the part that
we've discussed way too many times already, but in the Allwinner BSP,
that ratio is hardcoded to 4, and we've had panels that need it at
that value.
So, what you want to do is to have:
TCON DCLK = pixel clock * bpp / lanes
TCON Module Clock = DCLK * 4
PLL = Module Clock * Module Clock Divider (which I believe is 1 in most cases)
So you want to increase the PLL. Fortunately for use, this is exactly
what a call to clk_set_rate will end up doing.
Maxime
--
Maxime Ripard, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
^ permalink raw reply
* [PATCH 2/2] dt-bindings: gpu: mali-utgard: add mediatek, mt7623-mali compatible
From: ryder.lee @ 2019-07-24 9:01 UTC (permalink / raw)
To: Matthias Brugger, Rob Herring
Cc: Weijie Gao, Sean Wang, devicetree, linux-kernel, linux-arm-kernel,
linux-mediatek, Ryder Lee
In-Reply-To: <af7b5a2e00eb3a4b6262807c378e43afd5f74779.1563867856.git.ryder.lee@mediatek.com>
From: Sean Wang <sean.wang@mediatek.com>
The MediaTek MT7623 SoC contains a Mali-450, so add a compatible for it
and define its own vendor-specific properties.
Signed-off-by: Sean Wang <sean.wang@mediatek.com>
Signed-off-by: Ryder Lee <ryder.lee@mediatek.com>
Reviewed-by: Rob Herring <robh@kernel.org>
---
Documentation/devicetree/bindings/gpu/arm,mali-utgard.txt | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/Documentation/devicetree/bindings/gpu/arm,mali-utgard.txt b/Documentation/devicetree/bindings/gpu/arm,mali-utgard.txt
index ae63f09fda7d..73021e2dda25 100644
--- a/Documentation/devicetree/bindings/gpu/arm,mali-utgard.txt
+++ b/Documentation/devicetree/bindings/gpu/arm,mali-utgard.txt
@@ -17,6 +17,7 @@ Required properties:
+ amlogic,meson8b-mali
+ amlogic,meson-gxbb-mali
+ amlogic,meson-gxl-mali
+ + mediatek,mt7623-mali
+ rockchip,rk3036-mali
+ rockchip,rk3066-mali
+ rockchip,rk3188-mali
@@ -88,6 +89,10 @@ to specify one more vendor-specific compatible, among:
Required properties:
* resets: phandle to the reset line for the GPU
+ - mediatek,mt7623-mali
+ Required properties:
+ * resets: phandle to the reset line for the GPU
+
- Rockchip variants:
Required properties:
* resets: phandle to the reset line for the GPU
--
2.18.0
^ permalink raw reply related
* [PATCH 1/2] arm: dts: mt7623: add Mali-450 device node
From: ryder.lee @ 2019-07-24 9:00 UTC (permalink / raw)
To: Matthias Brugger, Rob Herring
Cc: Weijie Gao, Sean Wang, devicetree, linux-kernel, linux-arm-kernel,
linux-mediatek, Ryder Lee
From: Ryder Lee <ryder.lee@mediatek.com>
Add a node for Mali-450.
Signed-off-by: Sean Wang <sean.wang@mediatek.com>
Signed-off-by: Ryder Lee <ryder.lee@mediatek.com>
---
kmscube as well as X11 EGL tests work fine (use Lima driver).
---
arch/arm/boot/dts/mt7623.dtsi | 25 +++++++++++++++++++++++++
1 file changed, 25 insertions(+)
diff --git a/arch/arm/boot/dts/mt7623.dtsi b/arch/arm/boot/dts/mt7623.dtsi
index a79f0b6c3429..6a9c5afb9a36 100644
--- a/arch/arm/boot/dts/mt7623.dtsi
+++ b/arch/arm/boot/dts/mt7623.dtsi
@@ -3,6 +3,7 @@
* Copyright (c) 2017-2018 MediaTek Inc.
* Author: John Crispin <john@phrozen.org>
* Sean Wang <sean.wang@mediatek.com>
+ * Ryder Lee <ryder.lee@mediatek.com>
*
*/
@@ -733,6 +734,30 @@
#reset-cells = <1>;
};
+ mali: gpu@13040000 {
+ compatible = "mediatek,mt7623-mali", "arm,mali-450";
+ reg = <0 0x13040000 0 0x30000>;
+ interrupts = <GIC_SPI 170 IRQ_TYPE_LEVEL_LOW>,
+ <GIC_SPI 171 IRQ_TYPE_LEVEL_LOW>,
+ <GIC_SPI 172 IRQ_TYPE_LEVEL_LOW>,
+ <GIC_SPI 173 IRQ_TYPE_LEVEL_LOW>,
+ <GIC_SPI 174 IRQ_TYPE_LEVEL_LOW>,
+ <GIC_SPI 175 IRQ_TYPE_LEVEL_LOW>,
+ <GIC_SPI 176 IRQ_TYPE_LEVEL_LOW>,
+ <GIC_SPI 177 IRQ_TYPE_LEVEL_LOW>,
+ <GIC_SPI 178 IRQ_TYPE_LEVEL_LOW>,
+ <GIC_SPI 179 IRQ_TYPE_LEVEL_LOW>,
+ <GIC_SPI 180 IRQ_TYPE_LEVEL_LOW>;
+ interrupt-names = "gp", "gpmmu", "pp0", "ppmmu0", "pp1",
+ "ppmmu1", "pp2", "ppmmu2", "pp3", "ppmmu3",
+ "pp";
+ clocks = <&topckgen CLK_TOP_MMPLL>,
+ <&g3dsys CLK_G3DSYS_CORE>;
+ clock-names = "bus", "core";
+ power-domains = <&scpsys MT2701_POWER_DOMAIN_MFG>;
+ resets = <&g3dsys MT2701_G3DSYS_CORE_RST>;
+ };
+
mmsys: syscon@14000000 {
compatible = "mediatek,mt7623-mmsys",
"mediatek,mt2701-mmsys",
--
2.18.0
^ permalink raw reply related
* Re: [Sound-open-firmware] [PATCH v2 1/5] ASoC: SOF: imx: Add i.MX8 HW support
From: Daniel Baluta @ 2019-07-24 8:58 UTC (permalink / raw)
To: Lucas Stach
Cc: Pierre-Louis Bossart, Mark Rutland, Aisheng Dong, Peng Fan,
Fabio Estevam, Anson Huang, Devicetree List, Daniel Baluta,
S.j. Wang, Marco Felsch, Linux Kernel Mailing List, Paul Olaru,
Rob Herring, dl-linux-imx, Pengutronix Kernel Team,
Leonard Crestez, Shawn Guo, linux-arm-kernel, sound-open-fir
In-Reply-To: <1563957164.2311.28.camel@pengutronix.de>
On Wed, Jul 24, 2019 at 11:32 AM Lucas Stach <l.stach@pengutronix.de> wrote:
>
> Hi Daniel,
>
> Am Mittwoch, den 24.07.2019, 09:54 +0300 schrieb Daniel Baluta:
> > On Tue, Jul 23, 2019 at 6:18 PM Pierre-Louis Bossart
> [...]
> >
> > > Also are all the resources device-managed, I don't see a remove()?
> >
> > Good catch for pm stuff. We mostly didn't care about remove because
> > drivers are always Y in our distribution.
>
> Linux drivers need to be hotplug aware, even if they are not built as a
> module. You can test things by manually unbinding the driver from the
> device via sysfs.
Agree. Will take this into consideration when sending next version!
^ permalink raw reply
* [PATCH v8 11/11] usb: mtu3: register a USB Role Switch for dual role mode
From: Chunfeng Yun @ 2019-07-24 8:50 UTC (permalink / raw)
To: Rob Herring, Greg Kroah-Hartman, Biju Das
Cc: Mark Rutland, Chunfeng Yun, Matthias Brugger, Adam Thomson,
Li Jun, Badhri Jagan Sridharan, Heikki Krogerus, Hans de Goede,
Andy Shevchenko, Min Guo, devicetree, linux-kernel, linux-usb,
linux-arm-kernel, linux-mediatek, Linus Walleij
In-Reply-To: <1563958245-6321-1-git-send-email-chunfeng.yun@mediatek.com>
Because extcon is not allowed for new bindings, and the
dual role switch is supported by USB Role Switch,
especially for Type-C drivers, so register a USB Role
Switch to support the new way
Signed-off-by: Chunfeng Yun <chunfeng.yun@mediatek.com>
---
v8 no changes
v7 no changes
v6 no changes
v5 no changes
v4 changes:
1. assign fwnode member of usb_role_switch struct suggested by Heikki
v3 changes:
1. select USB_ROLE_SWITCH in Kconfig suggested by Heikki
2. rename ssusb_mode_manual_switch() to ssusb_mode_switch()
v2 no changes
---
drivers/usb/mtu3/Kconfig | 1 +
drivers/usb/mtu3/mtu3.h | 5 ++++
drivers/usb/mtu3/mtu3_debugfs.c | 4 +--
drivers/usb/mtu3/mtu3_dr.c | 48 ++++++++++++++++++++++++++++++++-
drivers/usb/mtu3/mtu3_dr.h | 6 ++---
drivers/usb/mtu3/mtu3_plat.c | 3 ++-
6 files changed, 60 insertions(+), 7 deletions(-)
diff --git a/drivers/usb/mtu3/Kconfig b/drivers/usb/mtu3/Kconfig
index 928c2cd6fc00..bf98fd36341d 100644
--- a/drivers/usb/mtu3/Kconfig
+++ b/drivers/usb/mtu3/Kconfig
@@ -44,6 +44,7 @@ config USB_MTU3_DUAL_ROLE
bool "Dual Role mode"
depends on ((USB=y || USB=USB_MTU3) && (USB_GADGET=y || USB_GADGET=USB_MTU3))
depends on (EXTCON=y || EXTCON=USB_MTU3)
+ select USB_ROLE_SWITCH
help
This is the default mode of working of MTU3 controller where
both host and gadget features are enabled.
diff --git a/drivers/usb/mtu3/mtu3.h b/drivers/usb/mtu3/mtu3.h
index 76ecf12fdf62..6087be236a35 100644
--- a/drivers/usb/mtu3/mtu3.h
+++ b/drivers/usb/mtu3/mtu3.h
@@ -199,6 +199,9 @@ struct mtu3_gpd_ring {
* @id_nb : notifier for iddig(idpin) detection
* @id_work : work of iddig detection notifier
* @id_event : event of iddig detecion notifier
+* @role_sw : use USB Role Switch to support dual-role switch, can't use
+* extcon at the same time, and extcon is deprecated.
+* @role_sw_used : true when the USB Role Switch is used.
* @is_u3_drd: whether port0 supports usb3.0 dual-role device or not
* @manual_drd_enabled: it's true when supports dual-role device by debugfs
* to switch host/device modes depending on user input.
@@ -212,6 +215,8 @@ struct otg_switch_mtk {
struct notifier_block id_nb;
struct work_struct id_work;
unsigned long id_event;
+ struct usb_role_switch *role_sw;
+ bool role_sw_used;
bool is_u3_drd;
bool manual_drd_enabled;
};
diff --git a/drivers/usb/mtu3/mtu3_debugfs.c b/drivers/usb/mtu3/mtu3_debugfs.c
index 62c57ddc554e..c96e5dab0a48 100644
--- a/drivers/usb/mtu3/mtu3_debugfs.c
+++ b/drivers/usb/mtu3/mtu3_debugfs.c
@@ -453,9 +453,9 @@ static ssize_t ssusb_mode_write(struct file *file, const char __user *ubuf,
return -EFAULT;
if (!strncmp(buf, "host", 4) && !ssusb->is_host) {
- ssusb_mode_manual_switch(ssusb, 1);
+ ssusb_mode_switch(ssusb, 1);
} else if (!strncmp(buf, "device", 6) && ssusb->is_host) {
- ssusb_mode_manual_switch(ssusb, 0);
+ ssusb_mode_switch(ssusb, 0);
} else {
dev_err(ssusb->dev, "wrong or duplicated setting\n");
return -EINVAL;
diff --git a/drivers/usb/mtu3/mtu3_dr.c b/drivers/usb/mtu3/mtu3_dr.c
index 5fcb71af875a..08e18448e8b8 100644
--- a/drivers/usb/mtu3/mtu3_dr.c
+++ b/drivers/usb/mtu3/mtu3_dr.c
@@ -7,6 +7,8 @@
* Author: Chunfeng Yun <chunfeng.yun@mediatek.com>
*/
+#include <linux/usb/role.h>
+
#include "mtu3.h"
#include "mtu3_dr.h"
#include "mtu3_debug.h"
@@ -280,7 +282,7 @@ static int ssusb_extcon_register(struct otg_switch_mtk *otg_sx)
* This is useful in special cases, such as uses TYPE-A receptacle but also
* wants to support dual-role mode.
*/
-void ssusb_mode_manual_switch(struct ssusb_mtk *ssusb, int to_host)
+void ssusb_mode_switch(struct ssusb_mtk *ssusb, int to_host)
{
struct otg_switch_mtk *otg_sx = &ssusb->otg_switch;
@@ -318,6 +320,47 @@ void ssusb_set_force_mode(struct ssusb_mtk *ssusb,
mtu3_writel(ssusb->ippc_base, SSUSB_U2_CTRL(0), value);
}
+static int ssusb_role_sw_set(struct device *dev, enum usb_role role)
+{
+ struct ssusb_mtk *ssusb = dev_get_drvdata(dev);
+ bool to_host = false;
+
+ if (role == USB_ROLE_HOST)
+ to_host = true;
+
+ if (to_host ^ ssusb->is_host)
+ ssusb_mode_switch(ssusb, to_host);
+
+ return 0;
+}
+
+static enum usb_role ssusb_role_sw_get(struct device *dev)
+{
+ struct ssusb_mtk *ssusb = dev_get_drvdata(dev);
+ enum usb_role role;
+
+ role = ssusb->is_host ? USB_ROLE_HOST : USB_ROLE_DEVICE;
+
+ return role;
+}
+
+static int ssusb_role_sw_register(struct otg_switch_mtk *otg_sx)
+{
+ struct usb_role_switch_desc role_sx_desc = { 0 };
+ struct ssusb_mtk *ssusb =
+ container_of(otg_sx, struct ssusb_mtk, otg_switch);
+
+ if (!otg_sx->role_sw_used)
+ return 0;
+
+ role_sx_desc.set = ssusb_role_sw_set;
+ role_sx_desc.get = ssusb_role_sw_get;
+ role_sx_desc.fwnode = dev_fwnode(ssusb->dev);
+ otg_sx->role_sw = usb_role_switch_register(ssusb->dev, &role_sx_desc);
+
+ return PTR_ERR_OR_ZERO(otg_sx->role_sw);
+}
+
int ssusb_otg_switch_init(struct ssusb_mtk *ssusb)
{
struct otg_switch_mtk *otg_sx = &ssusb->otg_switch;
@@ -328,6 +371,8 @@ int ssusb_otg_switch_init(struct ssusb_mtk *ssusb)
if (otg_sx->manual_drd_enabled)
ssusb_dr_debugfs_init(ssusb);
+ else if (otg_sx->role_sw_used)
+ ret = ssusb_role_sw_register(otg_sx);
else
ret = ssusb_extcon_register(otg_sx);
@@ -340,4 +385,5 @@ void ssusb_otg_switch_exit(struct ssusb_mtk *ssusb)
cancel_work_sync(&otg_sx->id_work);
cancel_work_sync(&otg_sx->vbus_work);
+ usb_role_switch_unregister(otg_sx->role_sw);
}
diff --git a/drivers/usb/mtu3/mtu3_dr.h b/drivers/usb/mtu3/mtu3_dr.h
index ba6fe357ce29..5e58c4dbd54a 100644
--- a/drivers/usb/mtu3/mtu3_dr.h
+++ b/drivers/usb/mtu3/mtu3_dr.h
@@ -71,7 +71,7 @@ static inline void ssusb_gadget_exit(struct ssusb_mtk *ssusb)
#if IS_ENABLED(CONFIG_USB_MTU3_DUAL_ROLE)
int ssusb_otg_switch_init(struct ssusb_mtk *ssusb);
void ssusb_otg_switch_exit(struct ssusb_mtk *ssusb);
-void ssusb_mode_manual_switch(struct ssusb_mtk *ssusb, int to_host);
+void ssusb_mode_switch(struct ssusb_mtk *ssusb, int to_host);
int ssusb_set_vbus(struct otg_switch_mtk *otg_sx, int is_on);
void ssusb_set_force_mode(struct ssusb_mtk *ssusb,
enum mtu3_dr_force_mode mode);
@@ -86,8 +86,8 @@ static inline int ssusb_otg_switch_init(struct ssusb_mtk *ssusb)
static inline void ssusb_otg_switch_exit(struct ssusb_mtk *ssusb)
{}
-static inline void
-ssusb_mode_manual_switch(struct ssusb_mtk *ssusb, int to_host) {}
+static inline void ssusb_mode_switch(struct ssusb_mtk *ssusb, int to_host)
+{}
static inline int ssusb_set_vbus(struct otg_switch_mtk *otg_sx, int is_on)
{
diff --git a/drivers/usb/mtu3/mtu3_plat.c b/drivers/usb/mtu3/mtu3_plat.c
index fd0f6c5dfbc1..9c256ea3cdf5 100644
--- a/drivers/usb/mtu3/mtu3_plat.c
+++ b/drivers/usb/mtu3/mtu3_plat.c
@@ -299,8 +299,9 @@ static int get_ssusb_rscs(struct platform_device *pdev, struct ssusb_mtk *ssusb)
otg_sx->is_u3_drd = of_property_read_bool(node, "mediatek,usb3-drd");
otg_sx->manual_drd_enabled =
of_property_read_bool(node, "enable-manual-drd");
+ otg_sx->role_sw_used = of_property_read_bool(node, "usb-role-switch");
- if (of_property_read_bool(node, "extcon")) {
+ if (!otg_sx->role_sw_used && of_property_read_bool(node, "extcon")) {
otg_sx->edev = extcon_get_edev_by_phandle(ssusb->dev, 0);
if (IS_ERR(otg_sx->edev)) {
dev_err(ssusb->dev, "couldn't get extcon device\n");
--
2.21.0
^ permalink raw reply related
* [PATCH v8 10/11] usb: common: add USB GPIO based connection detection driver
From: Chunfeng Yun @ 2019-07-24 8:50 UTC (permalink / raw)
To: Rob Herring, Greg Kroah-Hartman, Biju Das
Cc: Mark Rutland, Chunfeng Yun, Matthias Brugger, Adam Thomson,
Li Jun, Badhri Jagan Sridharan, Heikki Krogerus, Hans de Goede,
Andy Shevchenko, Min Guo, devicetree, linux-kernel, linux-usb,
linux-arm-kernel, linux-mediatek, Linus Walleij
In-Reply-To: <1563958245-6321-1-git-send-email-chunfeng.yun@mediatek.com>
Due to the requirement of usb-connector.txt binding, the old way
using extcon to support USB Dual-Role switch is now deprecated
when use Type-B connector.
This patch introduces a driver of Type-B connector which typically
uses an input GPIO to detect USB ID pin, and try to replace the
function provided by extcon-usb-gpio driver
Signed-off-by: Chunfeng Yun <chunfeng.yun@mediatek.com>
Tested-by: Nagarjuna Kristam <nkristam@nvidia.com>
---
v8 changes:
1. rename the driver name and usb new compatible suggested by Heikki
2. move the driver into usb/common from usb/roles suggested by Heikki
v7 changes:
1. remove macro DEV_PMS_OPS suggested by Andy
2. add tested-by Nagarjuna
v6 changes:
1. get usb-role-swtich by usb_role_switch_get()
v5 changes:
1. put usb_role_switch when error happens suggested by Biju
2. don't treat bype-B connector as a virtual device suggested by Rob
v4 changes:
1. remove linux/gpio.h suggested by Linus
2. put node when error happens
v3 changes:
1. treat bype-B connector as a virtual device;
2. change file name again
v2 changes:
1. file name is changed
2. use new compatible
---
drivers/usb/common/Kconfig | 13 ++
drivers/usb/common/Makefile | 1 +
drivers/usb/common/usb-conn-gpio.c | 284 +++++++++++++++++++++++++++++
3 files changed, 298 insertions(+)
create mode 100644 drivers/usb/common/usb-conn-gpio.c
diff --git a/drivers/usb/common/Kconfig b/drivers/usb/common/Kconfig
index 848545b099cf..d611477aae41 100644
--- a/drivers/usb/common/Kconfig
+++ b/drivers/usb/common/Kconfig
@@ -36,3 +36,16 @@ config USB_ULPI_BUS
To compile this driver as a module, choose M here: the module will
be called ulpi.
+config USB_CONN_GPIO
+ tristate "USB GPIO Based Connection Detection Driver"
+ depends on GPIOLIB
+ select USB_ROLE_SWITCH
+ help
+ The driver supports USB role switch between host and device via GPIO
+ based USB cable detection, used typically if an input GPIO is used
+ to detect USB ID pin, and another input GPIO may be also used to detect
+ Vbus pin at the same time, it also can be used to enable/disable
+ device if an input GPIO is only used to detect Vbus pin.
+
+ To compile the driver as a module, choose M here: the module will
+ be called usb-conn-gpio.ko
diff --git a/drivers/usb/common/Makefile b/drivers/usb/common/Makefile
index 0a7c45e85481..8227ffc2cf0b 100644
--- a/drivers/usb/common/Makefile
+++ b/drivers/usb/common/Makefile
@@ -7,5 +7,6 @@ obj-$(CONFIG_USB_COMMON) += usb-common.o
usb-common-y += common.o
usb-common-$(CONFIG_USB_LED_TRIG) += led.o
+obj-$(CONFIG_USB_CONN_GPIO) += usb-conn-gpio.o
obj-$(CONFIG_USB_OTG_FSM) += usb-otg-fsm.o
obj-$(CONFIG_USB_ULPI_BUS) += ulpi.o
diff --git a/drivers/usb/common/usb-conn-gpio.c b/drivers/usb/common/usb-conn-gpio.c
new file mode 100644
index 000000000000..e4935e99f295
--- /dev/null
+++ b/drivers/usb/common/usb-conn-gpio.c
@@ -0,0 +1,284 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * USB GPIO Based Connection Detection Driver
+ *
+ * Copyright (C) 2019 MediaTek Inc.
+ *
+ * Author: Chunfeng Yun <chunfeng.yun@mediatek.com>
+ *
+ * Some code borrowed from drivers/extcon/extcon-usb-gpio.c
+ */
+
+#include <linux/device.h>
+#include <linux/gpio/consumer.h>
+#include <linux/interrupt.h>
+#include <linux/irq.h>
+#include <linux/module.h>
+#include <linux/of.h>
+#include <linux/pinctrl/consumer.h>
+#include <linux/platform_device.h>
+#include <linux/regulator/consumer.h>
+#include <linux/usb/role.h>
+
+#define USB_GPIO_DEB_MS 20 /* ms */
+#define USB_GPIO_DEB_US ((USB_GPIO_DEB_MS) * 1000) /* us */
+
+#define USB_CONN_IRQF \
+ (IRQF_TRIGGER_RISING | IRQF_TRIGGER_FALLING | IRQF_ONESHOT)
+
+struct usb_conn_info {
+ struct device *dev;
+ struct usb_role_switch *role_sw;
+ enum usb_role last_role;
+ struct regulator *vbus;
+ struct delayed_work dw_det;
+ unsigned long debounce_jiffies;
+
+ struct gpio_desc *id_gpiod;
+ struct gpio_desc *vbus_gpiod;
+ int id_irq;
+ int vbus_irq;
+};
+
+/**
+ * "DEVICE" = VBUS and "HOST" = !ID, so we have:
+ * Both "DEVICE" and "HOST" can't be set as active at the same time
+ * so if "HOST" is active (i.e. ID is 0) we keep "DEVICE" inactive
+ * even if VBUS is on.
+ *
+ * Role | ID | VBUS
+ * ------------------------------------
+ * [1] DEVICE | H | H
+ * [2] NONE | H | L
+ * [3] HOST | L | H
+ * [4] HOST | L | L
+ *
+ * In case we have only one of these signals:
+ * - VBUS only - we want to distinguish between [1] and [2], so ID is always 1
+ * - ID only - we want to distinguish between [1] and [4], so VBUS = ID
+ */
+static void usb_conn_detect_cable(struct work_struct *work)
+{
+ struct usb_conn_info *info;
+ enum usb_role role;
+ int id, vbus, ret;
+
+ info = container_of(to_delayed_work(work),
+ struct usb_conn_info, dw_det);
+
+ /* check ID and VBUS */
+ id = info->id_gpiod ?
+ gpiod_get_value_cansleep(info->id_gpiod) : 1;
+ vbus = info->vbus_gpiod ?
+ gpiod_get_value_cansleep(info->vbus_gpiod) : id;
+
+ if (!id)
+ role = USB_ROLE_HOST;
+ else if (vbus)
+ role = USB_ROLE_DEVICE;
+ else
+ role = USB_ROLE_NONE;
+
+ dev_dbg(info->dev, "role %d/%d, gpios: id %d, vbus %d\n",
+ info->last_role, role, id, vbus);
+
+ if (info->last_role == role) {
+ dev_warn(info->dev, "repeated role: %d\n", role);
+ return;
+ }
+
+ if (info->last_role == USB_ROLE_HOST)
+ regulator_disable(info->vbus);
+
+ ret = usb_role_switch_set_role(info->role_sw, role);
+ if (ret)
+ dev_err(info->dev, "failed to set role: %d\n", ret);
+
+ if (role == USB_ROLE_HOST) {
+ ret = regulator_enable(info->vbus);
+ if (ret)
+ dev_err(info->dev, "enable vbus regulator failed\n");
+ }
+
+ info->last_role = role;
+
+ dev_dbg(info->dev, "vbus regulator is %s\n",
+ regulator_is_enabled(info->vbus) ? "enabled" : "disabled");
+}
+
+static void usb_conn_queue_dwork(struct usb_conn_info *info,
+ unsigned long delay)
+{
+ queue_delayed_work(system_power_efficient_wq, &info->dw_det, delay);
+}
+
+static irqreturn_t usb_conn_isr(int irq, void *dev_id)
+{
+ struct usb_conn_info *info = dev_id;
+
+ usb_conn_queue_dwork(info, info->debounce_jiffies);
+
+ return IRQ_HANDLED;
+}
+
+static int usb_conn_probe(struct platform_device *pdev)
+{
+ struct device *dev = &pdev->dev;
+ struct usb_conn_info *info;
+ int ret = 0;
+
+ info = devm_kzalloc(dev, sizeof(*info), GFP_KERNEL);
+ if (!info)
+ return -ENOMEM;
+
+ info->dev = dev;
+ info->id_gpiod = devm_gpiod_get_optional(dev, "id", GPIOD_IN);
+ if (IS_ERR(info->id_gpiod))
+ return PTR_ERR(info->id_gpiod);
+
+ info->vbus_gpiod = devm_gpiod_get_optional(dev, "vbus", GPIOD_IN);
+ if (IS_ERR(info->vbus_gpiod))
+ return PTR_ERR(info->vbus_gpiod);
+
+ if (!info->id_gpiod && !info->vbus_gpiod) {
+ dev_err(dev, "failed to get gpios\n");
+ return -ENODEV;
+ }
+
+ if (info->id_gpiod)
+ ret = gpiod_set_debounce(info->id_gpiod, USB_GPIO_DEB_US);
+ if (!ret && info->vbus_gpiod)
+ ret = gpiod_set_debounce(info->vbus_gpiod, USB_GPIO_DEB_US);
+ if (ret < 0)
+ info->debounce_jiffies = msecs_to_jiffies(USB_GPIO_DEB_MS);
+
+ INIT_DELAYED_WORK(&info->dw_det, usb_conn_detect_cable);
+
+ info->vbus = devm_regulator_get(dev, "vbus");
+ if (IS_ERR(info->vbus)) {
+ dev_err(dev, "failed to get vbus\n");
+ return PTR_ERR(info->vbus);
+ }
+
+ info->role_sw = usb_role_switch_get(dev);
+ if (IS_ERR(info->role_sw)) {
+ if (PTR_ERR(info->role_sw) != -EPROBE_DEFER)
+ dev_err(dev, "failed to get role switch\n");
+
+ return PTR_ERR(info->role_sw);
+ }
+
+ if (info->id_gpiod) {
+ info->id_irq = gpiod_to_irq(info->id_gpiod);
+ if (info->id_irq < 0) {
+ dev_err(dev, "failed to get ID IRQ\n");
+ ret = info->id_irq;
+ goto put_role_sw;
+ }
+
+ ret = devm_request_threaded_irq(dev, info->id_irq, NULL,
+ usb_conn_isr, USB_CONN_IRQF,
+ pdev->name, info);
+ if (ret < 0) {
+ dev_err(dev, "failed to request ID IRQ\n");
+ goto put_role_sw;
+ }
+ }
+
+ if (info->vbus_gpiod) {
+ info->vbus_irq = gpiod_to_irq(info->vbus_gpiod);
+ if (info->vbus_irq < 0) {
+ dev_err(dev, "failed to get VBUS IRQ\n");
+ ret = info->vbus_irq;
+ goto put_role_sw;
+ }
+
+ ret = devm_request_threaded_irq(dev, info->vbus_irq, NULL,
+ usb_conn_isr, USB_CONN_IRQF,
+ pdev->name, info);
+ if (ret < 0) {
+ dev_err(dev, "failed to request VBUS IRQ\n");
+ goto put_role_sw;
+ }
+ }
+
+ platform_set_drvdata(pdev, info);
+
+ /* Perform initial detection */
+ usb_conn_queue_dwork(info, 0);
+
+ return 0;
+
+put_role_sw:
+ usb_role_switch_put(info->role_sw);
+ return ret;
+}
+
+static int usb_conn_remove(struct platform_device *pdev)
+{
+ struct usb_conn_info *info = platform_get_drvdata(pdev);
+
+ cancel_delayed_work_sync(&info->dw_det);
+
+ if (info->last_role == USB_ROLE_HOST)
+ regulator_disable(info->vbus);
+
+ usb_role_switch_put(info->role_sw);
+
+ return 0;
+}
+
+static int __maybe_unused usb_conn_suspend(struct device *dev)
+{
+ struct usb_conn_info *info = dev_get_drvdata(dev);
+
+ if (info->id_gpiod)
+ disable_irq(info->id_irq);
+ if (info->vbus_gpiod)
+ disable_irq(info->vbus_irq);
+
+ pinctrl_pm_select_sleep_state(dev);
+
+ return 0;
+}
+
+static int __maybe_unused usb_conn_resume(struct device *dev)
+{
+ struct usb_conn_info *info = dev_get_drvdata(dev);
+
+ pinctrl_pm_select_default_state(dev);
+
+ if (info->id_gpiod)
+ enable_irq(info->id_irq);
+ if (info->vbus_gpiod)
+ enable_irq(info->vbus_irq);
+
+ usb_conn_queue_dwork(info, 0);
+
+ return 0;
+}
+
+static SIMPLE_DEV_PM_OPS(usb_conn_pm_ops,
+ usb_conn_suspend, usb_conn_resume);
+
+static const struct of_device_id usb_conn_dt_match[] = {
+ { .compatible = "linux,usb-conn-gpio", },
+ { }
+};
+MODULE_DEVICE_TABLE(of, usb_conn_dt_match);
+
+static struct platform_driver usb_conn_driver = {
+ .probe = usb_conn_probe,
+ .remove = usb_conn_remove,
+ .driver = {
+ .name = "usb-conn-gpio",
+ .pm = &usb_conn_pm_ops,
+ .of_match_table = usb_conn_dt_match,
+ },
+};
+
+module_platform_driver(usb_conn_driver);
+
+MODULE_AUTHOR("Chunfeng Yun <chunfeng.yun@mediatek.com>");
+MODULE_DESCRIPTION("USB GPIO based connection detection driver");
+MODULE_LICENSE("GPL v2");
--
2.21.0
^ permalink raw reply related
* [PATCH v8 09/11] usb: common: create Kconfig file
From: Chunfeng Yun @ 2019-07-24 8:50 UTC (permalink / raw)
To: Rob Herring, Greg Kroah-Hartman, Biju Das
Cc: Mark Rutland, Chunfeng Yun, Matthias Brugger, Adam Thomson,
Li Jun, Badhri Jagan Sridharan, Heikki Krogerus, Hans de Goede,
Andy Shevchenko, Min Guo, devicetree, linux-kernel, linux-usb,
linux-arm-kernel, linux-mediatek, Linus Walleij
In-Reply-To: <1563958245-6321-1-git-send-email-chunfeng.yun@mediatek.com>
Create Kconfig file for USB common core, and move USB_LED_TRIG
and USB_ULPI_BUS configs into the new file from the parent Kconfig,
it will help to add new configs later.
Signed-off-by: Chunfeng Yun <chunfeng.yun@mediatek.com>
---
v8:
new patch
---
drivers/usb/Kconfig | 35 +----------------------------------
drivers/usb/common/Kconfig | 38 ++++++++++++++++++++++++++++++++++++++
2 files changed, 39 insertions(+), 34 deletions(-)
create mode 100644 drivers/usb/common/Kconfig
diff --git a/drivers/usb/Kconfig b/drivers/usb/Kconfig
index 6e59d370ef81..7bf94e65ed2f 100644
--- a/drivers/usb/Kconfig
+++ b/drivers/usb/Kconfig
@@ -36,8 +36,7 @@ menuconfig USB_SUPPORT
if USB_SUPPORT
-config USB_COMMON
- tristate
+source "drivers/usb/common/Kconfig"
config USB_ARCH_HAS_HCD
def_bool y
@@ -175,36 +174,4 @@ source "drivers/usb/typec/Kconfig"
source "drivers/usb/roles/Kconfig"
-config USB_LED_TRIG
- bool "USB LED Triggers"
- depends on LEDS_CLASS && LEDS_TRIGGERS
- select USB_COMMON
- help
- This option adds LED triggers for USB host and/or gadget activity.
-
- Say Y here if you are working on a system with led-class supported
- LEDs and you want to use them as activity indicators for USB host or
- gadget.
-
-config USB_ULPI_BUS
- tristate "USB ULPI PHY interface support"
- select USB_COMMON
- help
- UTMI+ Low Pin Interface (ULPI) is specification for a commonly used
- USB 2.0 PHY interface. The ULPI specification defines a standard set
- of registers that can be used to detect the vendor and product which
- allows ULPI to be handled as a bus. This module is the driver for that
- bus.
-
- The ULPI interfaces (the buses) are registered by the drivers for USB
- controllers which support ULPI register access and have ULPI PHY
- attached to them. The ULPI PHY drivers themselves are normal PHY
- drivers.
-
- ULPI PHYs provide often functions such as ADP sensing/probing (OTG
- protocol) and USB charger detection.
-
- To compile this driver as a module, choose M here: the module will
- be called ulpi.
-
endif # USB_SUPPORT
diff --git a/drivers/usb/common/Kconfig b/drivers/usb/common/Kconfig
new file mode 100644
index 000000000000..848545b099cf
--- /dev/null
+++ b/drivers/usb/common/Kconfig
@@ -0,0 +1,38 @@
+# SPDX-License-Identifier: GPL-2.0
+
+config USB_COMMON
+ tristate
+
+
+config USB_LED_TRIG
+ bool "USB LED Triggers"
+ depends on LEDS_CLASS && LEDS_TRIGGERS
+ select USB_COMMON
+ help
+ This option adds LED triggers for USB host and/or gadget activity.
+
+ Say Y here if you are working on a system with led-class supported
+ LEDs and you want to use them as activity indicators for USB host or
+ gadget.
+
+config USB_ULPI_BUS
+ tristate "USB ULPI PHY interface support"
+ select USB_COMMON
+ help
+ UTMI+ Low Pin Interface (ULPI) is specification for a commonly used
+ USB 2.0 PHY interface. The ULPI specification defines a standard set
+ of registers that can be used to detect the vendor and product which
+ allows ULPI to be handled as a bus. This module is the driver for that
+ bus.
+
+ The ULPI interfaces (the buses) are registered by the drivers for USB
+ controllers which support ULPI register access and have ULPI PHY
+ attached to them. The ULPI PHY drivers themselves are normal PHY
+ drivers.
+
+ ULPI PHYs provide often functions such as ADP sensing/probing (OTG
+ protocol) and USB charger detection.
+
+ To compile this driver as a module, choose M here: the module will
+ be called ulpi.
+
--
2.21.0
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox