* [PATCH] clk: samsung: s3c: Remove unneeded enumeration
From: Chanwoo Choi @ 2017-12-20 9:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1511749908-29777-1-git-send-email-cw00.choi@samsung.com>
Dear Sylwester,
Gently Ping.
Regards,
Chanwoo Choi
On 2017? 11? 27? 11:31, Chanwoo Choi wrote:
> This patch just removes the unneeded enumeration for PLL index.
>
> Signed-off-by: Chanwoo Choi <cw00.choi@samsung.com>
> ---
> drivers/clk/samsung/clk-s3c2412.c | 11 ++---------
> drivers/clk/samsung/clk-s3c2443.c | 17 ++++-------------
> drivers/clk/samsung/clk-s3c64xx.c | 17 ++++++-----------
> 3 files changed, 12 insertions(+), 33 deletions(-)
>
> diff --git a/drivers/clk/samsung/clk-s3c2412.c b/drivers/clk/samsung/clk-s3c2412.c
> index b8340a49921b..1555e407529e 100644
> --- a/drivers/clk/samsung/clk-s3c2412.c
> +++ b/drivers/clk/samsung/clk-s3c2412.c
> @@ -27,11 +27,6 @@
> #define CLKSRC 0x1c
> #define SWRST 0x30
>
> -/* list of PLLs to be registered */
> -enum s3c2412_plls {
> - mpll, upll,
> -};
> -
> static void __iomem *reg_base;
>
> #ifdef CONFIG_PM_SLEEP
> @@ -144,10 +139,8 @@ struct samsung_mux_clock s3c2412_muxes[] __initdata = {
> };
>
> static struct samsung_pll_clock s3c2412_plls[] __initdata = {
> - [mpll] = PLL(pll_s3c2440_mpll, MPLL, "mpll", "xti",
> - LOCKTIME, MPLLCON, NULL),
> - [upll] = PLL(pll_s3c2410_upll, UPLL, "upll", "urefclk",
> - LOCKTIME, UPLLCON, NULL),
> + PLL(pll_s3c2440_mpll, MPLL, "mpll", "xti", LOCKTIME, MPLLCON, NULL),
> + PLL(pll_s3c2410_upll, UPLL, "upll", "urefclk", LOCKTIME, UPLLCON, NULL),
> };
>
> struct samsung_gate_clock s3c2412_gates[] __initdata = {
> diff --git a/drivers/clk/samsung/clk-s3c2443.c b/drivers/clk/samsung/clk-s3c2443.c
> index d94b85a42356..9580a6baf4d7 100644
> --- a/drivers/clk/samsung/clk-s3c2443.c
> +++ b/drivers/clk/samsung/clk-s3c2443.c
> @@ -41,11 +41,6 @@ enum supported_socs {
> S3C2450,
> };
>
> -/* list of PLLs to be registered */
> -enum s3c2443_plls {
> - mpll, epll,
> -};
> -
> static void __iomem *reg_base;
>
> #ifdef CONFIG_PM_SLEEP
> @@ -225,10 +220,8 @@ struct samsung_clock_alias s3c2443_common_aliases[] __initdata = {
> /* S3C2416 specific clocks */
>
> static struct samsung_pll_clock s3c2416_pll_clks[] __initdata = {
> - [mpll] = PLL(pll_6552_s3c2416, MPLL, "mpll", "mpllref",
> - LOCKCON0, MPLLCON, NULL),
> - [epll] = PLL(pll_6553, EPLL, "epll", "epllref",
> - LOCKCON1, EPLLCON, NULL),
> + PLL(pll_6552_s3c2416, MPLL, "mpll", "mpllref", LOCKCON0, MPLLCON, NULL),
> + PLL(pll_6553, EPLL, "epll", "epllref", LOCKCON1, EPLLCON, NULL),
> };
>
> PNAME(s3c2416_hsmmc0_p) = { "sclk_hsmmc0", "sclk_hsmmcext" };
> @@ -279,10 +272,8 @@ struct samsung_clock_alias s3c2416_aliases[] __initdata = {
> /* S3C2443 specific clocks */
>
> static struct samsung_pll_clock s3c2443_pll_clks[] __initdata = {
> - [mpll] = PLL(pll_3000, MPLL, "mpll", "mpllref",
> - LOCKCON0, MPLLCON, NULL),
> - [epll] = PLL(pll_2126, EPLL, "epll", "epllref",
> - LOCKCON1, EPLLCON, NULL),
> + PLL(pll_3000, MPLL, "mpll", "mpllref", LOCKCON0, MPLLCON, NULL),
> + PLL(pll_2126, EPLL, "epll", "epllref", LOCKCON1, EPLLCON, NULL),
> };
>
> static struct clk_div_table armdiv_s3c2443_d[] = {
> diff --git a/drivers/clk/samsung/clk-s3c64xx.c b/drivers/clk/samsung/clk-s3c64xx.c
> index 7306867a0ab8..6db01cf5ab83 100644
> --- a/drivers/clk/samsung/clk-s3c64xx.c
> +++ b/drivers/clk/samsung/clk-s3c64xx.c
> @@ -56,11 +56,6 @@
> #define GATE_ON(_id, cname, pname, o, b) \
> GATE(_id, cname, pname, o, b, CLK_IGNORE_UNUSED, 0)
>
> -/* list of PLLs to be registered */
> -enum s3c64xx_plls {
> - apll, mpll, epll,
> -};
> -
> static void __iomem *reg_base;
> static bool is_s3c6400;
>
> @@ -364,12 +359,12 @@ static void __init s3c64xx_clk_sleep_init(void) {}
>
> /* List of PLL clocks. */
> static struct samsung_pll_clock s3c64xx_pll_clks[] __initdata = {
> - [apll] = PLL(pll_6552, FOUT_APLL, "fout_apll", "fin_pll",
> - APLL_LOCK, APLL_CON, NULL),
> - [mpll] = PLL(pll_6552, FOUT_MPLL, "fout_mpll", "fin_pll",
> - MPLL_LOCK, MPLL_CON, NULL),
> - [epll] = PLL(pll_6553, FOUT_EPLL, "fout_epll", "fin_pll",
> - EPLL_LOCK, EPLL_CON0, NULL),
> + PLL(pll_6552, FOUT_APLL, "fout_apll", "fin_pll",
> + APLL_LOCK, APLL_CON, NULL),
> + PLL(pll_6552, FOUT_MPLL, "fout_mpll", "fin_pll",
> + MPLL_LOCK, MPLL_CON, NULL),
> + PLL(pll_6553, FOUT_EPLL, "fout_epll", "fin_pll",
> + EPLL_LOCK, EPLL_CON0, NULL),
> };
>
> /* Aliases for common s3c64xx clocks. */
>
^ permalink raw reply
* [PATCH v2 2/3] ARM: dts: r8a7743: Add CMT SoC specific support
From: Simon Horman @ 2017-12-20 9:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAMuHMdWPufohN+g=gFwi2V6vsGvhO7kTh8kj9AKCkraGKWGZBg@mail.gmail.com>
On Tue, Dec 19, 2017 at 12:20:45PM +0100, Geert Uytterhoeven wrote:
> On Mon, Dec 18, 2017 at 6:39 PM, Fabrizio Castro
> <fabrizio.castro@bp.renesas.com> wrote:
> > Add CMT[01] support to SoC DT.
> >
> > Signed-off-by: Fabrizio Castro <fabrizio.castro@bp.renesas.com>
> > Reviewed-by: Biju Das <biju.das@bp.renesas.com>
>
> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Thanks, applied.
^ permalink raw reply
* [PATCH v2 4/4] ARM: dts: r8a7745: Add TPU support
From: Simon Horman @ 2017-12-20 9:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1513620411-17478-5-git-send-email-fabrizio.castro@bp.renesas.com>
On Mon, Dec 18, 2017 at 06:06:51PM +0000, Fabrizio Castro wrote:
> Add TPU support to SoC DT.
>
> Signed-off-by: Fabrizio Castro <fabrizio.castro@bp.renesas.com>
> Reviewed-by: Biju Das <biju.das@bp.renesas.com>
> ---
> v1->v2:
> * No change
Thanks, applied.
^ permalink raw reply
* [PATCH v2 2/4] ARM: dts: r8a7745: Add PWM SoC support
From: Simon Horman @ 2017-12-20 9:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAMuHMdUi953N1J+vfJWJo0GMKO4tBZV9HnX7haG0fvyNHfOvOA@mail.gmail.com>
On Tue, Dec 19, 2017 at 12:25:54PM +0100, Geert Uytterhoeven wrote:
> On Mon, Dec 18, 2017 at 7:06 PM, Fabrizio Castro
> <fabrizio.castro@bp.renesas.com> wrote:
> > Add the definitions for pwm[0123456] to the SoC .dtsi.
> >
> > Signed-off-by: Fabrizio Castro <fabrizio.castro@bp.renesas.com>
> > Reviewed-by: Biju Das <biju.das@bp.renesas.com>
>
> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
>
> > --- a/arch/arm/boot/dts/r8a7745.dtsi
> > +++ b/arch/arm/boot/dts/r8a7745.dtsi
> > @@ -968,6 +968,83 @@
> > status = "disabled";
> > };
> >
> > + pwm0: pwm at e6e30000 {
> > + compatible = "renesas,pwm-r8a7745",
> > + "renesas,pwm-rcar";
>
> I think this can fit on one line.
No need. I have fixed this when applying the patch.
^ permalink raw reply
* [PATCH] ARM: dts: at91: sama5d2_ptc_ek: use TCB0 as timers
From: Nicolas Ferre @ 2017-12-20 9:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171219213209.13823-1-alexandre.belloni@free-electrons.com>
Use tcb0 for timers as selected in sama5_defconfig.
Signed-off-by: Nicolas Ferre <nicolas.ferre@microchip.com>
---
Hi Alex,
Adding the newly added sama5d2_ptc_ek to the series.
Not tested though.
Regards,
Nicolas
arch/arm/boot/dts/at91-sama5d2_ptc_ek.dts | 12 ++++++++++++
1 file changed, 12 insertions(+)
diff --git a/arch/arm/boot/dts/at91-sama5d2_ptc_ek.dts b/arch/arm/boot/dts/at91-sama5d2_ptc_ek.dts
index 186cb03e2672..e603a267bdf1 100644
--- a/arch/arm/boot/dts/at91-sama5d2_ptc_ek.dts
+++ b/arch/arm/boot/dts/at91-sama5d2_ptc_ek.dts
@@ -149,6 +149,18 @@
};
};
+ tcb0: timer at f800c000 {
+ timer0: timer at 0 {
+ compatible = "atmel,tcb-timer";
+ reg = <0>;
+ };
+
+ timer1: timer at 1 {
+ compatible = "atmel,tcb-timer";
+ reg = <1>;
+ };
+ };
+
uart0: serial at f801c000 {
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_uart0_default>;
--
2.9.0
^ permalink raw reply related
* [PATCH v5 0/4] ARM: ep93xx: ts72xx: Add support for BK3 board
From: Lukasz Majewski @ 2017-12-20 8:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAK8P3a1W+jU79GriKLZ1SXoVLaxC+przqQUTyHH6zz8+9dw2jg@mail.gmail.com>
Hi Arnd,
> On Tue, Dec 19, 2017 at 10:36 PM, Lukasz Majewski <lukma@denx.de>
> wrote:
> > Hi Arnd,
> >
> >> Hi!
> >>
> >> On Mon Dec 18 12:55:40 2017 Arnd Bergmann <arnd@arndb.de> wrote:
> >> > > GCC 7.2 is working
> >> >
> >> > Ah wait, this is still for ep93xx, which is always at least
> >> > armv4t, right? So it won't have a problem with the armv4
> >> > deprecation anyway, even
> >>
> >> Correct.
> >
> > Maybe a bit off topic :-)
> >
> > Are there any more comments regarding this patch series? Are those
> > patches eligible for applying them to -next?
>
> Alexander already sent a pull request, I just haven't pulled them. If
> there are any other comments or additional patches, they should be
> done on top of the first pull request, unless there is a major
> regression in the original pull (which is unlikely).
Thanks for reply.
>
> Arnd
Best regards,
Lukasz Majewski
--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20171220/391d72da/attachment-0001.sig>
^ permalink raw reply
* [PATCH v3 5/5] ARM: dts: r8a7743: Add TPU support
From: Simon Horman @ 2017-12-20 8:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1513690500-12165-6-git-send-email-fabrizio.castro@bp.renesas.com>
On Tue, Dec 19, 2017 at 01:35:00PM +0000, Fabrizio Castro wrote:
> Add TPU support to SoC DT.
>
> Signed-off-by: Fabrizio Castro <fabrizio.castro@bp.renesas.com>
> Reviewed-by: Biju Das <biju.das@bp.renesas.com>
> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
> ---
> v2->v3:
> * No change
Thanks, applied.
^ permalink raw reply
* [PATCH v3 3/5] ARM: dts: r8a7743: Add PWM SoC support
From: Simon Horman @ 2017-12-20 8:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1513690500-12165-4-git-send-email-fabrizio.castro@bp.renesas.com>
On Tue, Dec 19, 2017 at 01:34:58PM +0000, Fabrizio Castro wrote:
> Add the definitions for pwm[0123456] to the SoC .dtsi.
>
> Signed-off-by: Fabrizio Castro <fabrizio.castro@bp.renesas.com>
> Reviewed-by: Biju Das <biju.das@bp.renesas.com>
> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
> ---
> v2->v3:
> * pwm[0123456] compatible definitions don't wrap anymore
Thanks, applied.
^ permalink raw reply
* [PATCH v3 1/5] ARM: shmobile: defconfig: Enable PWM
From: Simon Horman @ 2017-12-20 8:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1513690500-12165-2-git-send-email-fabrizio.castro@bp.renesas.com>
On Tue, Dec 19, 2017 at 01:34:56PM +0000, Fabrizio Castro wrote:
> RZ/G1 and R-Car platforms have PWM timers. This patch enables PWM support
> by default.
>
> Signed-off-by: Fabrizio Castro <fabrizio.castro@bp.renesas.com>
> Reviewed-by: Biju Das <biju.das@bp.renesas.com>
Thanks, applied.
^ permalink raw reply
* [PATCH] soc: renesas: rcar-sysc: Mark rcar_sysc_matches[] __initconst
From: Simon Horman @ 2017-12-20 8:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1513698884-26663-1-git-send-email-geert+renesas@glider.be>
On Tue, Dec 19, 2017 at 04:54:44PM +0100, Geert Uytterhoeven wrote:
> rcar_sysc_matches[] is used only by rcar_sysc_pd_init(), which is
> __init. Hence mark rcar_sysc_matches[] __initconst.
>
> This frees another 1764 bytes (arm32/shmobile_defconfig) or 1000 bytes
> (arm64/renesas_defconfig) of memory after kernel init.
>
> Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Reviewed-by: Simon Horman <simon.horman@netronome.com>
^ permalink raw reply
* [PATCH] ARM: multi_v7_defconfig: Select PWM_RCAR as module
From: Simon Horman @ 2017-12-20 8:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1513691837-16192-1-git-send-email-fabrizio.castro@bp.renesas.com>
On Tue, Dec 19, 2017 at 01:57:17PM +0000, Fabrizio Castro wrote:
> Enable PWM support for R-Car and friends by default.
>
> Signed-off-by: Fabrizio Castro <fabrizio.castro@bp.renesas.com>
> Reviewed-by: Biju Das <biju.das@bp.renesas.com>
Thanks, applied.
^ permalink raw reply
* [PATCH v3 00/19] ARM: dts: aspeed: updates and new machines
From: Arnd Bergmann @ 2017-12-20 8:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CACPK8Xdf3__yuMEvD0NiZXihU-8F1R15aEwwJueHLZ6Jfs82oQ@mail.gmail.com>
On Wed, Dec 20, 2017 at 4:37 AM, Joel Stanley <joel@jms.id.au> wrote:
> On Wed, Dec 20, 2017 at 1:53 PM, Joel Stanley <joel@jms.id.au> wrote:
>> This series of device tree patches for the ASPEED BMC machines
>> moves all systems to use the soon to be merged clk driver, and
>> updates machines to use all of the drivers we have upstream.
>>
>> v3: Address review from Rob and Cedric
>> - Move aspeed-gpio.h usage out into the patches where use of the GPIO
>> is added
>> - Clarify that the aspeed-clock.h patch will be merged as part of
>> the device tree tree. This is to ensure we don't depend on the clk
>> tree for building.
>
> Arnd, Michael, Stephen; how do we resolve this? We need the
> dt-bindings header to be present for both the clk driver and the
> device tree to build.
>
> The clk driver is not (yet - soon I hope?) merged by Michael and
> Stephen. I am about to commit the device tree changes that will go
> through the ARM SoC tree.
There are several options:
- avoid the use of the header and redefine the binding to have a
clear mapping between hardware clock lines and the numeric
representation. This works better for some SoCs than others,
YMMV.
- Don't use the constants in the dts files for now, but use the
numbers directly, and update the dts files for the next merge window
- merge only one side for 4.16, either the driver or the dts files,
and follow up with the other one in 4.17
- make one shared git branch that contains only the headers
and base both the driver and the dts files on that branch so you
get a single shared commit ID.
I'm fine with any of the above, please pick whatever suits you best.
Arnd
^ permalink raw reply
* [PATCH 3/3] [v6] pinctrl: qcom: qdf2xxx: add support for new ACPI HID QCOM8002
From: Stephen Boyd @ 2017-12-20 8:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <d511f096-bad4-c7b3-d7d4-11b1fa3b1cce@codeaurora.org>
On 12/19, Timur Tabi wrote:
> Frankly, I thought I had everything resolved already, and it sounds
> like you want me to start over from scratch anyway.
>
Here's the patch. I get a hang when dumping debugfs, but at least
sysfs expose fails when trying to request blocked gpios. I need
to check if we need to say "yes" to pins that are above the gpio
max for pinctrl. I'll do that tomorrow.
---
drivers/gpio/gpiolib.c | 4 +-
drivers/pinctrl/qcom/pinctrl-msm.c | 98 ++++++++++++++++++++++++++++++++++++--
include/linux/gpio/driver.h | 3 ++
3 files changed, 99 insertions(+), 6 deletions(-)
diff --git a/drivers/gpio/gpiolib.c b/drivers/gpio/gpiolib.c
index 8db2680bf872..5f118f044caa 100644
--- a/drivers/gpio/gpiolib.c
+++ b/drivers/gpio/gpiolib.c
@@ -1475,8 +1475,8 @@ static void gpiochip_irqchip_free_valid_mask(struct gpio_chip *gpiochip)
gpiochip->irq_valid_mask = NULL;
}
-static bool gpiochip_irqchip_irq_valid(const struct gpio_chip *gpiochip,
- unsigned int offset)
+bool gpiochip_irqchip_irq_valid(const struct gpio_chip *gpiochip,
+ unsigned int offset)
{
/* No mask means all valid */
if (likely(!gpiochip->irq_valid_mask))
diff --git a/drivers/pinctrl/qcom/pinctrl-msm.c b/drivers/pinctrl/qcom/pinctrl-msm.c
index 273badd92561..4c2ce1f7d449 100644
--- a/drivers/pinctrl/qcom/pinctrl-msm.c
+++ b/drivers/pinctrl/qcom/pinctrl-msm.c
@@ -105,6 +105,17 @@ static const struct pinctrl_ops msm_pinctrl_ops = {
.dt_free_map = pinctrl_utils_free_map,
};
+static int msm_pinmux_request(struct pinctrl_dev *pctldev, unsigned offset)
+{
+ struct msm_pinctrl *pctrl = pinctrl_dev_get_drvdata(pctldev);
+ struct gpio_chip *chip = &pctrl->chip;
+
+ if (gpiochip_irqchip_irq_valid(chip, offset))
+ return 0;
+
+ return -EINVAL;
+}
+
static int msm_get_functions_count(struct pinctrl_dev *pctldev)
{
struct msm_pinctrl *pctrl = pinctrl_dev_get_drvdata(pctldev);
@@ -166,6 +177,7 @@ static int msm_pinmux_set_mux(struct pinctrl_dev *pctldev,
}
static const struct pinmux_ops msm_pinmux_ops = {
+ .request = msm_pinmux_request,
.get_functions_count = msm_get_functions_count,
.get_function_name = msm_get_function_name,
.get_function_groups = msm_get_function_groups,
@@ -493,6 +505,9 @@ static void msm_gpio_dbg_show_one(struct seq_file *s,
"pull up"
};
+ if (!gpiochip_irqchip_irq_valid(chip, offset))
+ return;
+
g = &pctrl->soc->groups[offset];
ctl_reg = readl(pctrl->regs + g->ctl_reg);
@@ -503,7 +518,7 @@ static void msm_gpio_dbg_show_one(struct seq_file *s,
seq_printf(s, " %-8s: %-3s %d", g->name, is_out ? "out" : "in", func);
seq_printf(s, " %dmA", msm_regval_to_drive(drive));
- seq_printf(s, " %s", pulls[pull]);
+ seq_printf(s, " %s\n", pulls[pull]);
}
static void msm_gpio_dbg_show(struct seq_file *s, struct gpio_chip *chip)
@@ -511,10 +526,8 @@ static void msm_gpio_dbg_show(struct seq_file *s, struct gpio_chip *chip)
unsigned gpio = chip->base;
unsigned i;
- for (i = 0; i < chip->ngpio; i++, gpio++) {
+ for (i = 0; i < chip->ngpio; i++, gpio++)
msm_gpio_dbg_show_one(s, NULL, chip, i, gpio);
- seq_puts(s, "\n");
- }
}
#else
@@ -795,6 +808,76 @@ static void msm_gpio_irq_handler(struct irq_desc *desc)
chained_irq_exit(chip, desc);
}
+static int msm_gpio_init_irq_valid_mask(struct gpio_chip *chip,
+ struct msm_pinctrl *pctrl)
+{
+ int ret;
+ unsigned int len, i;
+ unsigned int max_gpios = pctrl->soc->ngpios;
+ struct device_node *np = pctrl->dev->of_node;
+
+ /* The number of GPIOs in the ACPI tables */
+ ret = device_property_read_u16_array(pctrl->dev, "gpios", NULL, 0);
+ if (ret > 0 && ret < max_gpios) {
+ u16 *tmp;
+
+ len = ret;
+ tmp = kmalloc_array(len, sizeof(tmp[0]), GFP_KERNEL);
+ if (!tmp)
+ return -ENOMEM;
+
+ ret = device_property_read_u16_array(pctrl->dev, "gpios", tmp,
+ len);
+ if (ret < 0) {
+ dev_err(pctrl->dev, "could not read list of GPIOs\n");
+ kfree(tmp);
+ return ret;
+ }
+
+ bitmap_zero(chip->irq_valid_mask, max_gpios);
+ for (i = 0; i < len; i++)
+ set_bit(tmp[i], chip->irq_valid_mask);
+
+ return 0;
+ }
+
+ /* If there's a DT ngpios-ranges property then add those ranges */
+ ret = of_property_count_u32_elems(np, "ngpios-ranges");
+ if (ret > 0 && ret % 2 == 0 && ret / 2 < max_gpios) {
+ u32 start;
+ u32 count;
+
+ len = ret / 2;
+ bitmap_zero(chip->irq_valid_mask, max_gpios);
+
+ for (i = 0; i < len; i++) {
+ of_property_read_u32_index(np, "ngpios-ranges",
+ i * 2, &start);
+ of_property_read_u32_index(np, "ngpios-ranges",
+ i * 2 + 1, &count);
+ bitmap_set(chip->irq_valid_mask, start, count);
+ }
+ }
+
+ return 0;
+}
+
+static bool msm_gpio_needs_irq_valid_mask(struct msm_pinctrl *pctrl)
+{
+ int ret;
+ struct device_node *np = pctrl->dev->of_node;
+
+ ret = device_property_read_u16_array(pctrl->dev, "gpios", NULL, 0);
+ if (ret > 0)
+ return true;
+
+ ret = of_property_count_u32_elems(np, "ngpios-ranges");
+ if (ret > 0 && ret % 2 == 0)
+ return true;
+
+ return false;
+}
+
static int msm_gpio_init(struct msm_pinctrl *pctrl)
{
struct gpio_chip *chip;
@@ -811,6 +894,7 @@ static int msm_gpio_init(struct msm_pinctrl *pctrl)
chip->parent = pctrl->dev;
chip->owner = THIS_MODULE;
chip->of_node = pctrl->dev->of_node;
+ chip->irq_need_valid_mask = msm_gpio_needs_irq_valid_mask(pctrl);
ret = gpiochip_add_data(&pctrl->chip, pctrl);
if (ret) {
@@ -818,6 +902,12 @@ static int msm_gpio_init(struct msm_pinctrl *pctrl)
return ret;
}
+ ret = msm_gpio_init_irq_valid_mask(chip, pctrl);
+ if (ret) {
+ dev_err(pctrl->dev, "Failed to setup irq valid bits\n");
+ return ret;
+ }
+
ret = gpiochip_add_pin_range(&pctrl->chip, dev_name(pctrl->dev), 0, 0, chip->ngpio);
if (ret) {
dev_err(pctrl->dev, "Failed to add pin range\n");
diff --git a/include/linux/gpio/driver.h b/include/linux/gpio/driver.h
index af20369ec8e7..be977c1c7498 100644
--- a/include/linux/gpio/driver.h
+++ b/include/linux/gpio/driver.h
@@ -262,6 +262,9 @@ int gpiochip_irqchip_add_key(struct gpio_chip *gpiochip,
bool nested,
struct lock_class_key *lock_key);
+bool gpiochip_irqchip_irq_valid(const struct gpio_chip *gpiochip,
+ unsigned int offset);
+
#ifdef CONFIG_LOCKDEP
/*
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply related
* [PATCH 00/45] Migrate TCB bindings
From: Nicolas Ferre @ 2017-12-20 8:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171219213209.13823-1-alexandre.belloni@free-electrons.com>
On 19/12/2017 at 22:31, Alexandre Belloni wrote:
> Hi,
>
> As the bindings were acked by Rob a while ago [1] and I think there is
> consensus on what they look like, I'm planning to apply that series for
> 4.16 so we get a smoother transition for the TCB driver rework.
>
> I've simply removed the PWM binding change that I will submit with the
> driver change itself.
> There is also a small fix in the at91sam9261ek patch.
>
> [1] https://patchwork.kernel.org/patch/9755341/
>
> Cc: Antoine Aubert <a.aubert@overkiz.com>
> Cc: devicetree at vger.kernel.org
> Cc: Douglas Gilbert <dgilbert@interlog.com>
> Cc: Fabio Porcedda <fabio.porcedda@gmail.com>
> Cc: Gregory CLEMENT <gregory.clement@free-electrons.com>
> Cc: Joachim Eastwood <manabian@gmail.com>
> Cc: Marek Vasut <marex@denx.de>
> Cc: Martin Reimann <martin.reimann@egnite.de>
> Cc: Peter Rosin <peda@axentia.se>
> Cc: Raashid Muhammed <raashidmuhammed@zilogic.com>
> Cc: Rob Herring <robh+dt@kernel.org>
> Cc: Rodolfo Giometti <giometti@linux.it>
> Cc: Sergio Tanzilli <tanzilli@acmesystems.it>
> Cc: Tim Schendekehl <tim.schendekehl@egnite.de>
>
> Alexandre Belloni (45):
> ARM: at91: Document new TCB bindings
> ARM: dts: at91: at91rm9200: TC blocks are also simple-mfd and syscon
> devices
> ARM: dts: at91: at91rm9200ek: use TCB0 for timers
> ARM: dts: at91: mpa1600: use TCB0 as timers
> ARM: dts: at91: at91sam9260: TC blocks are also simple-mfd and syscon
> devices
> ARM: dts: at91: at91sam9260ek: use TCB0 as timers
> ARM: dts: at91: sam9_l9260: use TCB0 as timers
> ARM: dts: at91: ethernut5: use TCB0 as timers
> ARM: dts: at91: foxg20: use TCB0 as timers
> ARM: dts: at91: animeo_ip: use TCB0 as timers
> ARM: dts: at91: kizbox: use TCB0 as timers
> ARM: dts: at91: at91sam9g20ek: use TCB0 as timers
> ARM: dts: at91: ge863-pro3: use TCB0 as timers
> ARM: dts: at91: at91sam9261: TC blocks are also simple-mfd and syscon
> devices
> ARM: dts: at91: at91sam9261ek: use TCB0 as timers
> ARM: dts: at91: at91sam9263: TC blocks are also simple-mfd and syscon
> devices
> ARM: dts: at91: at91sam9263ek: use TCB0 as timers
> ARM: dts: at91: calao: use TCB0 as timers
> ARM: dts: at91: at91sam9g45: TC blocks are also simple-mfd and syscon
> devices
> ARM: dts: at91: at91sam9m10g45ek: use TCB0 as timers
> ARM: dts: at91: pm9g45: use TCB0 as timers
> ARM: dts: at91: at91sam9rl: TC blocks are also simple-mfd and syscon
> devices
> ARM: dts: at91: at91sam9rlek: use TCB0 as timers
> ARM: dts: at91: at91sam9n12: TC blocks are also simple-mfd and syscon
> devices
> ARM: dts: at91: at91sam9n12ek: use TCB0 as timers
> ARM: dts: at91: at91sam9x5: TC blocks are also simple-mfd and syscon
> devices
> ARM: dts: at91: at91sam9x5cm: use TCB0 as timers
> ARM: dts: at91: acme/g25: use TCB0 as timers
> ARM: dts: at91: cosino: use TCB0 as timers
> ARM: dts: at91: kizboxmini: use TCB0 as timers
> ARM: dts: at91: sama5d3: TC blocks are also simple-mfd and syscon
> devices
> ARM: dts: at91: sama5d3xek: use TCB0 as timers
> ARM: dts: at91: sama5d3 Xplained: use TCB0 as timers
> ARM: dts: at91: kizbox2: use TCB0 as timers
> ARM: dts: at91: sama5d3xek_cmp: use TCB0 as timers
> ARM: dts: at91: linea/tse850-3: use TCB0 as timers
> ARM: dts: at91: sama5d4: TC blocks are also simple-mfd and syscon
> devices
> ARM: dts: at91: sama5d4: Add TCB2
> ARM: dts: at91: sama5d4ek: use TCB2 as timers
> ARM: dts: at91: sama5d4 Xplained: use TCB2 as timers
> ARM: dts: at91: ma5d4: use TCB2 as timers
> ARM: dts: at91: vinco: use TCB2 as timers
> ARM: dts: at91: sama5d2: TC blocks are also simple-mfd and syscon
> devices
> ARM: dts: at91: sama5d2 Xplained: use TCB0 as timers
> ARM: dts: at91: sama5d27_som1_ek: use TCB0 as timers
For the whole series:
Acked-by: Nicolas Ferre <nicolas.ferre@microchip.com>
Thanks, best regards,
Nicolas
> .../devicetree/bindings/arm/atmel-at91.txt | 32 -------------
> .../devicetree/bindings/mfd/atmel-tcb.txt | 56 ++++++++++++++++++++++
> arch/arm/boot/dts/animeo_ip.dts | 12 +++++
> arch/arm/boot/dts/at91-ariag25.dts | 12 +++++
> arch/arm/boot/dts/at91-ariettag25.dts | 12 +++++
> arch/arm/boot/dts/at91-cosino.dtsi | 12 +++++
> arch/arm/boot/dts/at91-foxg20.dts | 12 +++++
> arch/arm/boot/dts/at91-kizbox.dts | 12 +++++
> arch/arm/boot/dts/at91-kizbox2.dts | 12 +++++
> arch/arm/boot/dts/at91-kizboxmini.dts | 12 +++++
> arch/arm/boot/dts/at91-linea.dtsi | 12 +++++
> arch/arm/boot/dts/at91-qil_a9260.dts | 12 +++++
> arch/arm/boot/dts/at91-sam9_l9260.dts | 12 +++++
> arch/arm/boot/dts/at91-sama5d27_som1_ek.dts | 12 +++++
> arch/arm/boot/dts/at91-sama5d2_xplained.dts | 12 +++++
> arch/arm/boot/dts/at91-sama5d3_xplained.dts | 12 +++++
> arch/arm/boot/dts/at91-sama5d4_ma5d4.dtsi | 12 +++++
> arch/arm/boot/dts/at91-sama5d4_xplained.dts | 12 +++++
> arch/arm/boot/dts/at91-sama5d4ek.dts | 12 +++++
> arch/arm/boot/dts/at91-vinco.dts | 12 +++++
> arch/arm/boot/dts/at91rm9200.dtsi | 8 +++-
> arch/arm/boot/dts/at91rm9200ek.dts | 12 +++++
> arch/arm/boot/dts/at91sam9260.dtsi | 8 +++-
> arch/arm/boot/dts/at91sam9260ek.dts | 12 +++++
> arch/arm/boot/dts/at91sam9261.dtsi | 4 +-
> arch/arm/boot/dts/at91sam9261ek.dts | 20 ++++++++
> arch/arm/boot/dts/at91sam9263.dtsi | 4 +-
> arch/arm/boot/dts/at91sam9263ek.dts | 12 +++++
> arch/arm/boot/dts/at91sam9g20ek_common.dtsi | 12 +++++
> arch/arm/boot/dts/at91sam9g45.dtsi | 8 +++-
> arch/arm/boot/dts/at91sam9m10g45ek.dts | 12 +++++
> arch/arm/boot/dts/at91sam9n12.dtsi | 8 +++-
> arch/arm/boot/dts/at91sam9n12ek.dts | 12 +++++
> arch/arm/boot/dts/at91sam9rl.dtsi | 4 +-
> arch/arm/boot/dts/at91sam9rlek.dts | 12 +++++
> arch/arm/boot/dts/at91sam9x5.dtsi | 8 +++-
> arch/arm/boot/dts/at91sam9x5cm.dtsi | 12 +++++
> arch/arm/boot/dts/ethernut5.dts | 12 +++++
> arch/arm/boot/dts/ge863-pro3.dtsi | 12 +++++
> arch/arm/boot/dts/mpa1600.dts | 12 +++++
> arch/arm/boot/dts/pm9g45.dts | 12 +++++
> arch/arm/boot/dts/sama5d2.dtsi | 8 +++-
> arch/arm/boot/dts/sama5d3.dtsi | 4 +-
> arch/arm/boot/dts/sama5d3_tcb1.dtsi | 4 +-
> arch/arm/boot/dts/sama5d3xcm.dtsi | 12 +++++
> arch/arm/boot/dts/sama5d3xcm_cmp.dtsi | 12 +++++
> arch/arm/boot/dts/sama5d4.dtsi | 18 ++++++-
> arch/arm/boot/dts/tny_a9260_common.dtsi | 12 +++++
> arch/arm/boot/dts/tny_a9263.dts | 12 +++++
> arch/arm/boot/dts/usb_a9260_common.dtsi | 12 +++++
> arch/arm/boot/dts/usb_a9263.dts | 12 +++++
> 51 files changed, 575 insertions(+), 51 deletions(-)
> create mode 100644 Documentation/devicetree/bindings/mfd/atmel-tcb.txt
>
--
Nicolas Ferre
^ permalink raw reply
* [PATCH 42/45] ARM: dts: at91: vinco: use TCB2 as timers
From: Gregory CLEMENT @ 2017-12-20 8:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171219213209.13823-43-alexandre.belloni@free-electrons.com>
Hi Alexandre,
On mar., d?c. 19 2017, Alexandre Belloni <alexandre.belloni@free-electrons.com> wrote:
> As TCB2 doesn't have any output pins, use it for timers
>
> Cc: Gregory CLEMENT <gregory.clement@free-electrons.com>
> Signed-off-by: Alexandre Belloni <alexandre.belloni@free-electrons.com>
Acked-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
Thanks,
Gregory
> ---
> arch/arm/boot/dts/at91-vinco.dts | 12 ++++++++++++
> 1 file changed, 12 insertions(+)
>
> diff --git a/arch/arm/boot/dts/at91-vinco.dts b/arch/arm/boot/dts/at91-vinco.dts
> index 9f6005708ea8..1be9889a2b3a 100644
> --- a/arch/arm/boot/dts/at91-vinco.dts
> +++ b/arch/arm/boot/dts/at91-vinco.dts
> @@ -151,6 +151,18 @@
> status = "okay";
> };
>
> + tcb2: timer at fc024000 {
> + timer at 0 {
> + compatible = "atmel,tcb-timer";
> + reg = <0>;
> + };
> +
> + timer at 1 {
> + compatible = "atmel,tcb-timer";
> + reg = <1>;
> + };
> + };
> +
> macb1: ethernet at fc028000 {
> phy-mode = "rmii";
> status = "okay";
> --
> 2.15.1
>
--
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
^ permalink raw reply
* [PATCH v5 0/4] ARM: ep93xx: ts72xx: Add support for BK3 board
From: Arnd Bergmann @ 2017-12-20 8:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171219223612.1a67ba5b@jawa>
On Tue, Dec 19, 2017 at 10:36 PM, Lukasz Majewski <lukma@denx.de> wrote:
> Hi Arnd,
>
>> Hi!
>>
>> On Mon Dec 18 12:55:40 2017 Arnd Bergmann <arnd@arndb.de> wrote:
>> > > GCC 7.2 is working
>> >
>> > Ah wait, this is still for ep93xx, which is always at least armv4t,
>> > right? So it won't have a problem with the armv4 deprecation
>> > anyway, even
>>
>> Correct.
>
> Maybe a bit off topic :-)
>
> Are there any more comments regarding this patch series? Are those
> patches eligible for applying them to -next?
Alexander already sent a pull request, I just haven't pulled them. If there
are any other comments or additional patches, they should be done
on top of the first pull request, unless there is a major regression in
the original pull (which is unlikely).
Arnd
^ permalink raw reply
* [PATCH] of: build dbts with symbols when CONFIG_OF_OVERLAY is set
From: Andre Heider @ 2017-12-20 8:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <0468b711-ba39-98d8-5bbe-0246a98db863@gmail.com>
On 18/12/17 23:10, Frank Rowand wrote:
> On 12/16/17 09:25, Andre Heider wrote:
>> Hi Frank,
>>
>> On 15/12/17 22:06, Frank Rowand wrote:
>>> On 12/14/17 07:12, Andre Heider wrote:
>>>> The overlay feature requires the base dtb to be built with symbols, so
>>>> lets build the dtbs with symbols when overlay support was explicitly
>>>> enabled.
>>>>
>>>> With CONFIG_OF_ALL_DTBS on ARCH=arm the 989 dtb files grow about ~38% on
>>>> average.
>>>>
>>>> Totals in bytes with the 3 biggest ones:
>>>>
>>>> Before:
>>>> ????90471??? arch/arm/boot/dts/am57xx-beagle-x15-revc.dtb
>>>> ????90521??? arch/arm/boot/dts/am57xx-beagle-x15-revb1.dtb
>>>> ????92639??? arch/arm/boot/dts/dra7-evm.dtb
>>>> ????25731296??? total
>>>>
>>>> After:
>>>> ????133203??? arch/arm/boot/dts/am57xx-beagle-x15-revc.dtb
>>>> ????133237??? arch/arm/boot/dts/am57xx-beagle-x15-revb1.dtb
>>>> ????134545??? arch/arm/boot/dts/dra7-evm.dtb
>>>> ????35464440??? total
>>>>
>>>> Signed-off-by: Andre Heider <a.heider@gmail.com>
>>>> ---
>>>>
>>>> Hi,
>>>>
>>>> while playing around with overlays I noticed that I needed to rebuilt
>>>> my distro's device trees because they didn't come with symbols.
>>>>
>>>> Is that for a reason, maybe the not so minor increase in size?
>>>
>>> Yes, size is the issue.
>>>
>>>
>>>>
>>>> Thanks,
>>>> Andre
>>>>
>>>> ? drivers/of/unittest-data/Makefile | 7 -------
>>>> ? scripts/Makefile.lib????????????? | 5 +++++
>>>> ? 2 files changed, 5 insertions(+), 7 deletions(-)
>>>>
>>>> diff --git a/drivers/of/unittest-data/Makefile b/drivers/of/unittest-data/Makefile
>>>> index 32389acfa616..b65061013512 100644
>>>> --- a/drivers/of/unittest-data/Makefile
>>>> +++ b/drivers/of/unittest-data/Makefile
>>>> @@ -15,13 +15,6 @@ targets += overlay.dtb overlay.dtb.S
>>>> ? targets += overlay_bad_phandle.dtb overlay_bad_phandle.dtb.S
>>>> ? targets += overlay_bad_symbol.dtb overlay_bad_symbol.dtb.S
>>>> ? targets += overlay_base.dtb overlay_base.dtb.S
>>>> -
>>>> -# enable creation of __symbols__ node
>>>> -DTC_FLAGS_overlay := -@
>>>> -DTC_FLAGS_overlay_bad_phandle := -@
>>>> -DTC_FLAGS_overlay_bad_symbol := -@
>>>> -DTC_FLAGS_overlay_base := -@
>>>> -
>>>> ? endif
>>>> ? ? .PRECIOUS: \
>>>
>>> No.? The unittests require these to be set unconditionally.
>>>
>>>
>>>> diff --git a/scripts/Makefile.lib b/scripts/Makefile.lib
>>>> index 1ca4dcd2d500..c7ba4aa8a07a 100644
>>>> --- a/scripts/Makefile.lib
>>>> +++ b/scripts/Makefile.lib
>>>> @@ -278,6 +278,11 @@ DTC_FLAGS += -Wnode_name_chars_strict \
>>>> ????? -Wproperty_name_chars_strict
>>>> ? endif
>>>> ? +ifeq ($(CONFIG_OF_OVERLAY),y)
>>>> +# enable creation of __symbols__ node
>>>> +DTC_FLAGS += -@
>>>> +endif
>>>> +
>>>> ? DTC_FLAGS += $(DTC_FLAGS_$(basetarget))
>>>> ? ? # Generate an assembly file to wrap the output of the device tree compiler
>>>>
>>>
>>> Not needed.? Instead set DTC_FLAGS in the make command.? For example:
>>>
>>> ??? DTC_FLAGS=-@ make qcom-apq8074-dragonboard.dtb
>>>
>>> There are a few architecture Makefiles that need to be fixed to not unconditionally
>>> set DTC_FLAGS.
>>
>> Rebuilding the dts files manually with symbols isn't the problem. The
>> idea was to enable it with a switch which distros simply can flip.
>>
>> Passing DTC_FLAGS to `make` would work too I guess, but on multi
>> platform builds that's still the same issue if there're boards which
>> can't handle that because of the size increase.
>>
>> Would a solution which enables symbols per family work? E.g.
>> CONFIG_MACH_SUN7I chooses to use -@ because it can handle it.
>>
>> Thanks,
>> Andre
>
> Making it easy for distros to increase the size of .dtb files is
> not the correct answer. We are trying to decrease the footprint
> of devicetree, not increase it.
I'm not sure I follow. If it's not acceptable to increase the size,
why's there overlay support in the first place?
There're distros/downstreams that support overlays today, like armbian,
beaglebone and rpi. All carrying their own patches to enable symbols [1]
[2] [3] and I'm sure others will follow. Why can't there be some sort of
switch for those to build their dtbs with symbols?
Regards,
Andre
[1]
https://github.com/armbian/build/blob/master/patch/kernel/sunxi-next/add-overlay-compilation-support.patch#L98
[2]
https://github.com/beagleboard/linux/commit/ed6b9450c2a2ec21149f14ff24770b69888abda6
[3]
https://github.com/raspberrypi/linux/blob/rpi-4.15.y/arch/arm/boot/dts/Makefile#L1124
^ permalink raw reply
* [PATCH v4 4/4] ARM: pinctrl: sunxi-pinctrl: fix pin funtion can not be match correctly.
From: Linus Walleij @ 2017-12-20 8:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171213144748.GA18267@arx-s1>
On Wed, Dec 13, 2017 at 3:47 PM, hao_zhang <hao5781286@gmail.com> wrote:
> Pin function can not be match correctly when SUNXI_PIN describe with
> mutiple variant and same function.
>
> such as:
> on pinctrl-sun4i-a10.c
>
> SUNXI_PIN(SUNXI_PINCTRL_PIN(B, 2),
> SUNXI_FUNCTION(0x0, "gpio_in"),
> SUNXI_FUNCTION(0x1, "gpio_out"),
> SUNXI_FUNCTION_VARIANT(0x2, "pwm", /* PWM0 */
> PINCTRL_SUN4I_A10 |
> PINCTRL_SUN7I_A20),
> SUNXI_FUNCTION_VARIANT(0x3, "pwm", /* PWM0 */
> PINCTRL_SUN8I_R40)),
>
> it would always match to the first variant function
> (PINCTRL_SUN4I_A10, PINCTRL_SUN7I_A20)
>
> so we should add variant compare on it.
>
> Signed-off-by: hao_zhang <hao5781286@gmail.com>
Please resend patch with Maxime's suggestions fixed and his
ACK added so I can apply it.
I can take this patch separatelt, it does not need to be part of
the PWM series.
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH] pinctrl: rockchip: enable clock when reading pin direction register
From: Linus Walleij @ 2017-12-20 8:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171212174343.192017-1-briannorris@chromium.org>
On Tue, Dec 12, 2017 at 6:43 PM, Brian Norris <briannorris@chromium.org> wrote:
> We generally leave the GPIO clock disabled, unless an interrupt is
> requested or we're accessing IO registers. We forgot to do this for the
> ->get_direction() callback, which means we can sometimes [1] get
> incorrect results [2] from, e.g., /sys/kernel/debug/gpio.
>
> Enable the clock, so we get the right results!
>
> [1] Sometimes, because many systems have 1 or mor interrupt requested on
> each GPIO bank, so they always leave their clock on.
>
> [2] Incorrect, meaning the register returns 0, and so we interpret that
> as "input".
>
> Signed-off-by: Brian Norris <briannorris@chromium.org>
Patch applied with Heiko's review tag.
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH v2 4/4] pinctrl: mediatek: update MAINTAINERS entry with MediaTek pinctrl driver
From: Linus Walleij @ 2017-12-20 7:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <d41feb63ea2ebbfe58f5940ff27b031dd8024b28.1513059082.git.sean.wang@mediatek.com>
On Tue, Dec 12, 2017 at 7:24 AM, <sean.wang@mediatek.com> wrote:
> From: Sean Wang <sean.wang@mediatek.com>
>
> I work for MediaTek on maintaining the existing MediaTek SoC whose target
> to home gateway such as MT7622 and MT7623 that is reusing MT2701 related
> files and will keep adding support for the following such kinds of SoCs
> in the future.
>
> Signed-off-by: Sean Wang <sean.wang@mediatek.com>
> Reviewed-by: Biao Huang <biao.huang@mediatek.com>
Patch applied.
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH v2 3/4] pinctrl: mediatek: add pinctrl driver for MT7622 SoC
From: Linus Walleij @ 2017-12-20 7:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <5b42c51c965fb2824646630dd93d3d531610e344.1513059081.git.sean.wang@mediatek.com>
On Tue, Dec 12, 2017 at 7:24 AM, <sean.wang@mediatek.com> wrote:
> From: Sean Wang <sean.wang@mediatek.com>
>
> Add support for pinctrl on MT7622 SoC. The IO core found on the SoC has
> the registers for pinctrl, pinconf and gpio mixed up in the same register
> range. However, the IO core for the MT7622 SoC is completely distinct from
> anyone of previous MediaTek SoCs which already had support, such as
> the hardware internal, register address map and register detailed
> definition for each pin.
>
> Therefore, instead, the driver is being newly implemented by reusing
> generic methods provided from the core layer with GENERIC_PINCONF,
> GENERIC_PINCTRL_GROUPS, and GENERIC_PINMUX_FUNCTIONS for the sake of code
> simplicity and rid of superfluous code. Where the function of pins
> determined by groups is utilized in this driver which can help developers
> less confused with what combinations of pins effective on the SoC and even
> reducing the mistakes during the integration of those relevant boards.
>
> As the gpio_chip handling is also only a few lines, the driver also
> implements the gpio functionality directly through GPIOLIB.
>
> Signed-off-by: Sean Wang <sean.wang@mediatek.com>
> Reviewed-by: Biao Huang <biao.huang@mediatek.com>
Patch applied. Very nice work!
As I've seen visiting Asia how popular MTK chips are for all kinds
of devices it's really nice to have proper upstream support directly from
Mediatek on these chips. You guys are awesome.
Some suggestions for improvements:
> +static void mtk_w32(struct mtk_pinctrl *pctl, u32 reg, u32 val)
> +{
> + writel_relaxed(val, pctl->base + reg);
> +}
> +
> +static u32 mtk_r32(struct mtk_pinctrl *pctl, u32 reg)
> +{
> + return readl_relaxed(pctl->base + reg);
> +}
> +
> +static void mtk_rmw(struct mtk_pinctrl *pctl, u32 reg, u32 mask, u32 set)
> +{
> + u32 val;
> +
> + val = mtk_r32(pctl, reg);
> + val &= ~mask;
> + val |= set;
> + mtk_w32(pctl, reg, val);
> +}
Have you considered replacing this with regmap-mmio? It does pretty much
the same thing. It could be an improvemet reducing code a bit and making
it more generic. The error codes from eg regmap_update_bits() can be
safely ignored on MMIO maps.
> +static int mtk_build_gpiochip(struct mtk_pinctrl *hw, struct device_node *np)
> +{
> + struct gpio_chip *chip = &hw->chip;
> + int ret;
> +
> + chip->label = PINCTRL_PINCTRL_DEV;
> + chip->parent = hw->dev;
> + chip->request = gpiochip_generic_request;
> + chip->free = gpiochip_generic_free;
> + chip->direction_input = mtk_gpio_direction_input;
> + chip->direction_output = mtk_gpio_direction_output;
Please submit a patch implementing chip->get_direction(), it
is really helpful, especially for debugging.
If your pin controller later adds support for things that can be
used from the GPIO side, like open drain or debounce, then
please consider at that point to also implement
chip->set_config() in the gpio_chip. That way your GPIO consumers
can use e.g. open drain through pin control as back-end.
See drivers/pinctrl/intel/pinctrl-intel.c for an example.
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH v2 2/4] pinctrl: mediatek: cleanup for placing all drivers under the menu
From: Linus Walleij @ 2017-12-20 7:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <fc13c7249505784c1f89a2e0775bb9a75cd38c3f.1513059081.git.sean.wang@mediatek.com>
On Tue, Dec 12, 2017 at 7:24 AM, <sean.wang@mediatek.com> wrote:
> From: Sean Wang <sean.wang@mediatek.com>
>
> Since lots of MediaTek drivers had been added, it seems slightly better
> for that adding cleanup for placing MediaTek pinctrl drivers under the
> independent menu as other kinds of drivers usually was done.
>
> Signed-off-by: Sean Wang <sean.wang@mediatek.com>
> Reviewed-by: Biao Huang <biao.huang@mediatek.com>
Patch applied. Also very nice!
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH v2 1/4] dt-bindings: pinctrl: add bindings for MediaTek MT7622 SoC
From: Linus Walleij @ 2017-12-20 7:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <eb93acdb07a0205e9d3089058b45aee1a6c04d50.1513059081.git.sean.wang@mediatek.com>
On Tue, Dec 12, 2017 at 7:24 AM, <sean.wang@mediatek.com> wrote:
> From: Sean Wang <sean.wang@mediatek.com>
>
> Add devicetree bindings for MediaTek MT7622 pinctrl driver.
>
> Signed-off-by: Sean Wang <sean.wang@mediatek.com>
> Reviewed-by: Biao Huang <biao.huang@mediatek.com>
Patch applied with Rob's ACK.
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH V2 9/9] ARM: dts: stm32: add initial support of stm32mp157c eval board
From: Linus Walleij @ 2017-12-20 7:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1513610272-7824-10-git-send-email-ludovic.Barre@st.com>
On Mon, Dec 18, 2017 at 4:17 PM, Ludovic Barre <ludovic.Barre@st.com> wrote:
> From: Ludovic Barre <ludovic.barre@st.com>
>
> Add support of stm32mp157c evaluation board (part number: STM32MP157C-EV1)
> split in 2 elements:
> -Daughter board (part number: STM32MP157C-ED1)
> which includes CPU, memory and power supply
> -Mother board (part number: STM32MP157C-EM1)
> which includes external peripherals (like display, camera,...)
> and extension connectors.
>
> The daughter board can run alone, this is why the device tree files
> are split in two layers, for the complete evaluation board (ev1)
> and for the daughter board alone (ed1).
>
> Signed-off-by: Ludovic Barre <ludovic.barre@st.com>
> Signed-off-by: Alexandre Torgue <alexandre.torgue@st.com>
(...)
> diff --git a/arch/arm/boot/dts/stm32mp157c-ev1.dts b/arch/arm/boot/dts/stm32mp157c-ev1.dts
Evaluation boards are important because they set a pattern that customers
will use.
Please consider to include nodes for all GPIO blocks used in this
evaluation board, and add:
gpio-line-names = "foo", "bar" ...;
See for example
arch/arm/boot/dts/bcm2835-rpi-a.dts
arch/arm/boot/dts/ste-snowball.dts
It's good to have because probably you guys have proper schematics and
know rail names of the stuff connected to those GPIO lines and so on,
so you can give the lines proper names.
It will be helpful for people using the reference design, especially with the
new character device, and also sets a pattern for people doing devices
based on the reference design and we really want to do that.
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH V2 6/9] pinctrl: stm32: Add STM32MP157 MPU support
From: Linus Walleij @ 2017-12-20 7:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1513610272-7824-7-git-send-email-ludovic.Barre@st.com>
On Mon, Dec 18, 2017 at 4:17 PM, Ludovic Barre <ludovic.Barre@st.com> wrote:
> From: Ludovic Barre <ludovic.barre@st.com>
>
> This driver consists of 2 controllers due to a hole in mapping:
> -1 controller for GPIO bankA to K.
> -1 controller for GPIO bankZ.
>
> Signed-off-by: Alexandre Torgue <alexandre.torgue@st.com>
> Signed-off-by: Ludovic Barre <ludovic.barre@st.com>
> Reviewed-by: Rob Herring <robh@kernel.org>
Patch applied.
Yours,
Linus Walleij
^ 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