* RE: [EXT] Re: [Patch v3 1/2] dt-bindings: spi: spi-fsl-qspi: Add ls2080a compatibility string to bindings
From: Ashish Kumar @ 2019-08-05 9:08 UTC (permalink / raw)
To: broonie@kernel.org
Cc: devicetree@vger.kernel.org, Han Xu, bbrezillon@kernel.org,
Kuldeep Singh, linux-mtd@lists.infradead.org, Rob Herring,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <CA+EcR23hhD2=abMtNGDoW1LtXSE4qfjTy1uzU7sgrbi7W=KSbw@mail.gmail.com>
> -----Original Message-----
> From: Han Xu <xhnjupt@gmail.com>
> Sent: Thursday, August 1, 2019 8:53 PM
> To: Rob Herring <robh@kernel.org>
> Cc: Ashish Kumar <ashish.kumar@nxp.com>; devicetree@vger.kernel.org;
> bbrezillon@kernel.org; Kuldeep Singh <kuldeep.singh@nxp.com>;
> broonie@kernel.org; linux-mtd@lists.infradead.org; linux-arm-
> kernel@lists.infradead.org
> Subject: [EXT] Re: [Patch v3 1/2] dt-bindings: spi: spi-fsl-qspi: Add ls2080a
> compatibility string to bindings
>
> Caution: EXT Email
>
> On Tue, Jul 9, 2019 at 3:09 PM Rob Herring <robh@kernel.org> wrote:
> >
> > On Wed, 19 Jun 2019 16:41:53 +0530, Ashish Kumar wrote:
> > > There are 2 version of QSPI-IP, according to which controller
> > > registers sets can be big endian or little endian.There are some
> > > other minor changes like RX fifo depth etc.
> > >
> > > The big endian version uses driver compatible "fsl,ls1021a-qspi" and
> > > little endian version uses driver compatible "fsl,ls2080a-qspi"
> > >
> > > Signed-off-by: Kuldeep Singh <kuldeep.singh@nxp.com>
> > > Signed-off-by: Ashish Kumar <ashish.kumar@nxp.com>
> > > ---
> > > v3:
> > > Rebase to top
> > > v2:
> > > Convert to patch series and rebasing done on top of tree
> > >
> > > Documentation/devicetree/bindings/spi/spi-fsl-qspi.txt | 3 +--
> > > 1 file changed, 1 insertion(+), 2 deletions(-)
> > >
> >
> > Reviewed-by: Rob Herring <robh@kernel.org>
>
> Acked-by: Han Xu <han.xu@nxp.com>
Hello Mark,
Could you please send this patch[1] from your spi tree, It applies seamlessly on
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi.git/
[1]: http://patchwork.ozlabs.org/patch/1118636/
Regards
Ashish
>
> >
> > ______________________________________________________
> > Linux MTD discussion mailing list
> > https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Flists
> > .infradead.org%2Fmailman%2Flistinfo%2Flinux-
> mtd%2F&data=02%7C01%7C
> >
> Ashish.Kumar%40nxp.com%7Ca172f045af714e408d0a08d716942751%7C686
> ea1d3bc
> >
> 2b4c6fa92cd99c5c301635%7C0%7C1%7C637002697881500159&sdata=f
> 8i1y4aa
> > k3gPnuXM3fD1xFPp4RB7GEWZ45%2BeWPOoNSA%3D&reserved=0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* RE: [EXT] Re: [Patch v3 2/2] dt-bindings: spi: spi-fsl-qspi: Add bindings of ls1088a and ls1012a
From: Ashish Kumar @ 2019-08-05 9:07 UTC (permalink / raw)
To: broonie@kernel.org
Cc: devicetree@vger.kernel.org, Han Xu, bbrezillon@kernel.org,
Kuldeep Singh, linux-mtd@lists.infradead.org, Rob Herring,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <CA+EcR20ui8Liot+PtzdU6CJb5WzLDHS0Xc7VR7qGAOpD5=ArNQ@mail.gmail.com>
> -----Original Message-----
> From: Han Xu <xhnjupt@gmail.com>
> Sent: Thursday, August 1, 2019 8:54 PM
> To: Rob Herring <robh@kernel.org>
> Cc: Ashish Kumar <ashish.kumar@nxp.com>; devicetree@vger.kernel.org;
> bbrezillon@kernel.org; Kuldeep Singh <kuldeep.singh@nxp.com>;
> broonie@kernel.org; linux-mtd@lists.infradead.org; linux-arm-
> kernel@lists.infradead.org
> Subject: [EXT] Re: [Patch v3 2/2] dt-bindings: spi: spi-fsl-qspi: Add bindings of
> ls1088a and ls1012a
>
> Caution: EXT Email
>
> On Tue, Jul 9, 2019 at 3:09 PM Rob Herring <robh@kernel.org> wrote:
> >
> > On Wed, 19 Jun 2019 16:41:54 +0530, Ashish Kumar wrote:
> > > Signed-off-by: Kuldeep Singh <kuldeep.singh@nxp.com>
> > > Signed-off-by: Ashish Kumar <ashish.kumar@nxp.com>
> > > ---
> > > v3:
> > > Rebase to top
> > > v2:
> > > Convert to patch series and rebasing done on top of tree
> > >
> > > Documentation/devicetree/bindings/spi/spi-fsl-qspi.txt | 2 ++
> > > 1 file changed, 2 insertions(+)
> > >
> >
> > Reviewed-by: Rob Herring <robh@kernel.org>
>
> Acked-by: Han Xu <han.xu@nxp.com>
Hello Mark,
Could you please send this patch[1] from your spi tree, It applies seamlessly on
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi.git/
[1]: http://patchwork.ozlabs.org/patch/1118637/
Regards
Ashish
>
> >
> > ______________________________________________________
> > Linux MTD discussion mailing list
> >
> https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Flists.inf
> radead.org%2Fmailman%2Flistinfo%2Flinux-
> mtd%2F&data=02%7C01%7CAshish.Kumar%40nxp.com%7C243dc21894
> ad4c2a651808d716945016%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7
> C1%7C637002698562132108&sdata=6YZyZ6D6DywgLYlp%2BWZfkvyaDr
> TKvR56JkOxy0XSD9k%3D&reserved=0
>
>
>
> --
> Sincerely,
>
> Han XU
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 1/7] drm/msm/mdp4: Drop unused GPIO include
From: Linus Walleij @ 2019-08-05 9:01 UTC (permalink / raw)
To: open list:DRM PANEL DRIVERS, Maarten Lankhorst, Maxime Ripard,
Sean Paul
Cc: MSM, Rob Clark, freedreno, Linux ARM
In-Reply-To: <CACRpkdZ-6qBxzTTY4=CV+-ZmnTRPmPNAWrHMb_cMXTYdaNeYQQ@mail.gmail.com>
On Sun, Jul 28, 2019 at 12:02 PM Linus Walleij <linus.walleij@linaro.org> wrote:
> On Sat, Jun 29, 2019 at 3:01 PM Linus Walleij <linus.walleij@linaro.org> wrote:
>
> > This file is not using any symbols from <linux/gpio.h> so just
> > drop this include.
> >
> > Cc: Rob Clark <robdclark@gmail.com>
> > Cc: Sean Paul <sean@poorly.run>
> > Cc: linux-arm-msm@vger.kernel.org
> > Cc: freedreno@lists.freedesktop.org
> > Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
>
> Rob & friends: can this be merged to wherever you merge
> the MSM DRM patches? If it is in drm-misc I can apply it
> but I need some ACKs.
Ping on this!
Yours,
Linus Walleij
_______________________________________________
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 v3 2/4] serial: mctrl_gpio: Add a NULL check to mctrl_gpio_to_gpiod()
From: Schrempf Frieder @ 2019-08-05 9:01 UTC (permalink / raw)
To: Uwe Kleine-König
Cc: linux-serial@vger.kernel.org, geert+renesas@glider.be,
shawnguo@kernel.org, s.hauer@pengutronix.de, Jiri Slaby,
linux-kernel@vger.kernel.org, linux-imx@nxp.com,
kernel@pengutronix.de, Greg Kroah-Hartman, festevam@gmail.com,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <20190802121231.wk6yg5mkyivs3rni@pengutronix.de>
On 02.08.19 14:12, Uwe Kleine-König wrote:
> On Fri, Aug 02, 2019 at 10:04:10AM +0000, Schrempf Frieder wrote:
>> From: Frieder Schrempf <frieder.schrempf@kontron.de>
>>
>> As it is allowed to use the mctrl_gpio_* functions before
>> initialization (as the 8250 driver does according to 434be0ae7aa7),
>
> Actually I was surprised some time ago that 8250 used serial_mctrl
> without first initializing it and expecting it to work. I didn't look in
> detail, but I wouldn't go so far to call this "allowed". The commit
> itself calls it "workaround" which seems a better match.
Ok, but if this is considered to be a workaround and as the 8250 driver
does not use mctrl_gpio_to_gpiod(), we should maybe just drop this patch
instead of encouraging others to use mctrl_gpio before initialization.
I'm really not sure what's best, so depending on what you will propose,
I'll send a new version of this patch with adjusted commit message or not.
By the way, Uwe and Fabio: Thanks for your reviews!
>
>> it seems appropriate to have a NULL check in all of the functions.
>> Otherwise the mctrl_gpio_to_gpiod() function is prone to be used
>> in a context that can lead to a NULL pointer dereference.
>>
>> Signed-off-by: Frieder Schrempf <frieder.schrempf@kontron.de>
>
> Best regards
> Uwe
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH 4/4 v2] ARM: nspire: Move CLCD set-up to device tree
From: Linus Walleij @ 2019-08-05 8:58 UTC (permalink / raw)
To: Daniel Tang, Fabian Vogt
Cc: Linus Walleij, Sam Ravnborg, dri-devel, linux-arm-kernel
In-Reply-To: <20190805085847.25554-1-linus.walleij@linaro.org>
This moves the nspire over to using the device tree to
set-up and probe the PL111 DRM driver and use the panels
from the simple-panel drivers.
Cc: Daniel Tang <dt.tangr@gmail.com>
Cc: Fabian Vogt <fabian@ritter-vogt.de>
Tested-by: Fabian Vogt <fabian@ritter-vogt.de>
Acked-by: Sam Ravnborg <sam@ravnborg.org>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
---
ChangeLog v1->v2:
- Now tested
- This will be sent separately to ARM SoC after the rest
of the patches land.
---
arch/arm/boot/dts/nspire-classic.dtsi | 19 ++++-
arch/arm/boot/dts/nspire-cx.dts | 18 +++-
arch/arm/boot/dts/nspire.dtsi | 10 ++-
arch/arm/mach-nspire/Makefile | 1 -
arch/arm/mach-nspire/clcd.c | 114 --------------------------
arch/arm/mach-nspire/clcd.h | 10 ---
arch/arm/mach-nspire/nspire.c | 25 ------
7 files changed, 43 insertions(+), 154 deletions(-)
delete mode 100644 arch/arm/mach-nspire/clcd.c
delete mode 100644 arch/arm/mach-nspire/clcd.h
diff --git a/arch/arm/boot/dts/nspire-classic.dtsi b/arch/arm/boot/dts/nspire-classic.dtsi
index c53f42777851..fabd8270f168 100644
--- a/arch/arm/boot/dts/nspire-classic.dtsi
+++ b/arch/arm/boot/dts/nspire-classic.dtsi
@@ -8,7 +8,13 @@
/include/ "nspire.dtsi"
&lcd {
- lcd-type = "classic";
+ port {
+ clcd_pads: endpoint {
+ remote-endpoint = <&panel_in>;
+ /* Dummy values, since we are grayscale */
+ arm,pl11x,tft-r0g0b0-pads = <0 8 16>;
+ };
+ };
};
&fast_timer {
@@ -69,6 +75,17 @@
#interrupt-cells = <1>;
};
};
+
+ panel {
+ compatible = "ti,nspire-classic-lcd-panel";
+ ports {
+ port {
+ panel_in: endpoint {
+ remote-endpoint = <&clcd_pads>;
+ };
+ };
+ };
+ };
chosen {
bootargs = "debug earlyprintk console=tty0 console=ttyS0,115200n8 root=/dev/ram0";
};
diff --git a/arch/arm/boot/dts/nspire-cx.dts b/arch/arm/boot/dts/nspire-cx.dts
index da95c3736651..1551d0d0189f 100644
--- a/arch/arm/boot/dts/nspire-cx.dts
+++ b/arch/arm/boot/dts/nspire-cx.dts
@@ -9,7 +9,12 @@
/include/ "nspire.dtsi"
&lcd {
- lcd-type = "cx";
+ port {
+ clcd_pads: endpoint {
+ remote-endpoint = <&panel_in>;
+ arm,pl11x,tft-r0g0b0-pads = <0 8 16>;
+ };
+ };
};
&fast_timer {
@@ -106,6 +111,17 @@
};
};
};
+
+ panel {
+ compatible = "ti,nspire-cx-lcd-panel";
+ ports {
+ port {
+ panel_in: endpoint {
+ remote-endpoint = <&clcd_pads>;
+ };
+ };
+ };
+ };
chosen {
bootargs = "debug earlyprintk console=tty0 console=ttyAMA0,115200n8 root=/dev/ram0";
};
diff --git a/arch/arm/boot/dts/nspire.dtsi b/arch/arm/boot/dts/nspire.dtsi
index c35fd6667716..d9a0fd7524dc 100644
--- a/arch/arm/boot/dts/nspire.dtsi
+++ b/arch/arm/boot/dts/nspire.dtsi
@@ -95,8 +95,14 @@
reg = <0xC0000000 0x1000>;
interrupts = <21>;
- clocks = <&apb_pclk>;
- clock-names = "apb_pclk";
+ /*
+ * We assume the same clock is fed to APB and CLCDCLK.
+ * There is some code to scale the clock down by a factor
+ * 48 for the display so likely the frequency to the
+ * display is 1MHz and the CLCDCLK is 48 MHz.
+ */
+ clocks = <&apb_pclk>, <&apb_pclk>;
+ clock-names = "clcdclk", "apb_pclk";
};
adc: adc@C4000000 {
diff --git a/arch/arm/mach-nspire/Makefile b/arch/arm/mach-nspire/Makefile
index 1d568c600452..4716b9b9aa7b 100644
--- a/arch/arm/mach-nspire/Makefile
+++ b/arch/arm/mach-nspire/Makefile
@@ -1,3 +1,2 @@
# SPDX-License-Identifier: GPL-2.0-only
obj-y += nspire.o
-obj-y += clcd.o
diff --git a/arch/arm/mach-nspire/clcd.c b/arch/arm/mach-nspire/clcd.c
deleted file mode 100644
index 44738dcb391d..000000000000
--- a/arch/arm/mach-nspire/clcd.c
+++ /dev/null
@@ -1,114 +0,0 @@
-// SPDX-License-Identifier: GPL-2.0-only
-/*
- * linux/arch/arm/mach-nspire/clcd.c
- *
- * Copyright (C) 2013 Daniel Tang <tangrs@tangrs.id.au>
- */
-
-#include <linux/init.h>
-#include <linux/of.h>
-#include <linux/amba/bus.h>
-#include <linux/amba/clcd.h>
-#include <linux/dma-mapping.h>
-
-static struct clcd_panel nspire_cx_lcd_panel = {
- .mode = {
- .name = "Color LCD",
- .refresh = 60,
- .xres = 320,
- .yres = 240,
- .sync = 0,
- .vmode = FB_VMODE_NONINTERLACED,
- .pixclock = 1,
- .hsync_len = 6,
- .vsync_len = 1,
- .right_margin = 50,
- .left_margin = 38,
- .lower_margin = 3,
- .upper_margin = 17,
- },
- .width = 65, /* ~6.50 cm */
- .height = 49, /* ~4.87 cm */
- .tim2 = TIM2_IPC,
- .cntl = CNTL_LCDTFT | CNTL_LCDVCOMP(1),
- .bpp = 16,
- .caps = CLCD_CAP_565,
-};
-
-static struct clcd_panel nspire_classic_lcd_panel = {
- .mode = {
- .name = "Grayscale LCD",
- .refresh = 60,
- .xres = 320,
- .yres = 240,
- .sync = FB_SYNC_HOR_HIGH_ACT | FB_SYNC_VERT_HIGH_ACT,
- .vmode = FB_VMODE_NONINTERLACED,
- .pixclock = 1,
- .hsync_len = 6,
- .vsync_len = 1,
- .right_margin = 6,
- .left_margin = 6,
- },
- .width = 71, /* 7.11cm */
- .height = 53, /* 5.33cm */
- .tim2 = 0x80007d0,
- .cntl = CNTL_LCDMONO8,
- .bpp = 8,
- .grayscale = 1,
- .caps = CLCD_CAP_5551,
-};
-
-int nspire_clcd_setup(struct clcd_fb *fb)
-{
- struct clcd_panel *panel;
- size_t panel_size;
- const char *type;
- dma_addr_t dma;
- int err;
-
- BUG_ON(!fb->dev->dev.of_node);
-
- err = of_property_read_string(fb->dev->dev.of_node, "lcd-type", &type);
- if (err) {
- pr_err("CLCD: Could not find lcd-type property\n");
- return err;
- }
-
- if (!strcmp(type, "cx")) {
- panel = &nspire_cx_lcd_panel;
- } else if (!strcmp(type, "classic")) {
- panel = &nspire_classic_lcd_panel;
- } else {
- pr_err("CLCD: Unknown lcd-type %s\n", type);
- return -EINVAL;
- }
-
- panel_size = ((panel->mode.xres * panel->mode.yres) * panel->bpp) / 8;
- panel_size = ALIGN(panel_size, PAGE_SIZE);
-
- fb->fb.screen_base = dma_alloc_wc(&fb->dev->dev, panel_size, &dma,
- GFP_KERNEL);
-
- if (!fb->fb.screen_base) {
- pr_err("CLCD: unable to map framebuffer\n");
- return -ENOMEM;
- }
-
- fb->fb.fix.smem_start = dma;
- fb->fb.fix.smem_len = panel_size;
- fb->panel = panel;
-
- return 0;
-}
-
-int nspire_clcd_mmap(struct clcd_fb *fb, struct vm_area_struct *vma)
-{
- return dma_mmap_wc(&fb->dev->dev, vma, fb->fb.screen_base,
- fb->fb.fix.smem_start, fb->fb.fix.smem_len);
-}
-
-void nspire_clcd_remove(struct clcd_fb *fb)
-{
- dma_free_wc(&fb->dev->dev, fb->fb.fix.smem_len, fb->fb.screen_base,
- fb->fb.fix.smem_start);
-}
diff --git a/arch/arm/mach-nspire/clcd.h b/arch/arm/mach-nspire/clcd.h
deleted file mode 100644
index 7f36bd8511c5..000000000000
--- a/arch/arm/mach-nspire/clcd.h
+++ /dev/null
@@ -1,10 +0,0 @@
-/* SPDX-License-Identifier: GPL-2.0-only */
-/*
- * linux/arch/arm/mach-nspire/clcd.h
- *
- * Copyright (C) 2013 Daniel Tang <tangrs@tangrs.id.au>
- */
-
-int nspire_clcd_setup(struct clcd_fb *fb);
-int nspire_clcd_mmap(struct clcd_fb *fb, struct vm_area_struct *vma);
-void nspire_clcd_remove(struct clcd_fb *fb);
diff --git a/arch/arm/mach-nspire/nspire.c b/arch/arm/mach-nspire/nspire.c
index 957bd0c0fbd5..2d4abb0288b9 100644
--- a/arch/arm/mach-nspire/nspire.c
+++ b/arch/arm/mach-nspire/nspire.c
@@ -12,14 +12,12 @@
#include <linux/irqchip/arm-vic.h>
#include <linux/clkdev.h>
#include <linux/amba/bus.h>
-#include <linux/amba/clcd.h>
#include <asm/mach/arch.h>
#include <asm/mach-types.h>
#include <asm/mach/map.h>
#include "mmio.h"
-#include "clcd.h"
static const char *const nspire_dt_match[] __initconst = {
"ti,nspire",
@@ -29,28 +27,6 @@ static const char *const nspire_dt_match[] __initconst = {
NULL,
};
-static struct clcd_board nspire_clcd_data = {
- .name = "LCD",
- .caps = CLCD_CAP_5551 | CLCD_CAP_565,
- .check = clcdfb_check,
- .decode = clcdfb_decode,
- .setup = nspire_clcd_setup,
- .mmap = nspire_clcd_mmap,
- .remove = nspire_clcd_remove,
-};
-
-
-static struct of_dev_auxdata nspire_auxdata[] __initdata = {
- OF_DEV_AUXDATA("arm,pl111", NSPIRE_LCD_PHYS_BASE,
- NULL, &nspire_clcd_data),
- { }
-};
-
-static void __init nspire_init(void)
-{
- of_platform_default_populate(NULL, nspire_auxdata, NULL);
-}
-
static void nspire_restart(enum reboot_mode mode, const char *cmd)
{
void __iomem *base = ioremap(NSPIRE_MISC_PHYS_BASE, SZ_4K);
@@ -62,6 +38,5 @@ static void nspire_restart(enum reboot_mode mode, const char *cmd)
DT_MACHINE_START(NSPIRE, "TI-NSPIRE")
.dt_compat = nspire_dt_match,
- .init_machine = nspire_init,
.restart = nspire_restart,
MACHINE_END
--
2.21.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH 3/4 v2] drm/panel: simple: Support TI nspire panels
From: Linus Walleij @ 2019-08-05 8:58 UTC (permalink / raw)
To: Daniel Tang, Fabian Vogt; +Cc: Linus Walleij, dri-devel, linux-arm-kernel
In-Reply-To: <20190805085847.25554-1-linus.walleij@linaro.org>
This adds support for the TI nspire panels to the simple panel
roster. This code is based on arch/arm/mach-nspire/clcd.c.
This includes likely the first grayscale panel supported.
These panels will be used with the PL11x DRM driver.
Cc: Daniel Tang <dt.tangr@gmail.com>
Cc: Fabian Vogt <fabian@ritter-vogt.de>
Tested-by: Fabian Vogt <fabian@ritter-vogt.de>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
---
ChangeLog v1->v2:
- Bump clock frequency to 10 MHz after Fabian's trial-and-error
- Changed vsymbol names to ti_nspire_*
- Sorted alphabetically
- Specify positive edge on the classic display bus
---
drivers/gpu/drm/panel/panel-simple.c | 64 ++++++++++++++++++++++++++++
1 file changed, 64 insertions(+)
diff --git a/drivers/gpu/drm/panel/panel-simple.c b/drivers/gpu/drm/panel/panel-simple.c
index 5a93c4edf1e4..96f894b44313 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -2578,6 +2578,64 @@ static const struct panel_desc tianma_tm070rvhg71 = {
.bus_format = MEDIA_BUS_FMT_RGB888_1X7X4_SPWG,
};
+static const struct drm_display_mode ti_nspire_cx_lcd_mode[] = {
+ {
+ .clock = 10000,
+ .hdisplay = 320,
+ .hsync_start = 320 + 50,
+ .hsync_end = 320 + 50 + 6,
+ .htotal = 320 + 50 + 6 + 38,
+ .vdisplay = 240,
+ .vsync_start = 240 + 3,
+ .vsync_end = 240 + 3 + 1,
+ .vtotal = 240 + 3 + 1 + 17,
+ .vrefresh = 60,
+ .flags = DRM_MODE_FLAG_NVSYNC | DRM_MODE_FLAG_NHSYNC,
+ },
+};
+
+static const struct panel_desc ti_nspire_cx_lcd_panel = {
+ .modes = ti_nspire_cx_lcd_mode,
+ .num_modes = 1,
+ .bpc = 8,
+ .size = {
+ .width = 65,
+ .height = 49,
+ },
+ .bus_format = MEDIA_BUS_FMT_RGB888_1X24,
+ .bus_flags = DRM_BUS_FLAG_PIXDATA_NEGEDGE,
+};
+
+static const struct drm_display_mode ti_nspire_classic_lcd_mode[] = {
+ {
+ .clock = 10000,
+ .hdisplay = 320,
+ .hsync_start = 320 + 6,
+ .hsync_end = 320 + 6 + 6,
+ .htotal = 320 + 6 + 6 + 6,
+ .vdisplay = 240,
+ .vsync_start = 240 + 0,
+ .vsync_end = 240 + 0 + 1,
+ .vtotal = 240 + 0 + 1 + 0,
+ .vrefresh = 60,
+ .flags = DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC,
+ },
+};
+
+static const struct panel_desc ti_nspire_classic_lcd_panel = {
+ .modes = ti_nspire_classic_lcd_mode,
+ .num_modes = 1,
+ /* The grayscale panel has 8 bit for the color .. Y (black) */
+ .bpc = 8,
+ .size = {
+ .width = 71,
+ .height = 53,
+ },
+ /* This is the grayscale bus format */
+ .bus_format = MEDIA_BUS_FMT_Y8_1X8,
+ .bus_flags = DRM_BUS_FLAG_PIXDATA_POSEDGE,
+};
+
static const struct drm_display_mode toshiba_lt089ac29000_mode = {
.clock = 79500,
.hdisplay = 1280,
@@ -3029,6 +3087,12 @@ static const struct of_device_id platform_of_match[] = {
}, {
.compatible = "tianma,tm070rvhg71",
.data = &tianma_tm070rvhg71,
+ }, {
+ .compatible = "ti,nspire-cx-lcd-panel",
+ .data = &ti_nspire_cx_lcd_panel,
+ }, {
+ .compatible = "ti,nspire-classic-lcd-panel",
+ .data = &ti_nspire_classic_lcd_panel,
}, {
.compatible = "toshiba,lt089ac29000",
.data = &toshiba_lt089ac29000,
--
2.21.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH 2/4 v2] drm/panel: simple: Add TI nspire panel bindings
From: Linus Walleij @ 2019-08-05 8:58 UTC (permalink / raw)
To: Daniel Tang, Fabian Vogt
Cc: devicetree, Linus Walleij, dri-devel, linux-arm-kernel
In-Reply-To: <20190805085847.25554-1-linus.walleij@linaro.org>
Add bindings for the TI NSPIRE simple display panels.
Cc: devicetree@vger.kernel.org
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
---
ChangeLog v1->v2:
- New patch as bindings are required
- Let's use YAML
---
.../bindings/display/panel/ti,nspire.yaml | 36 +++++++++++++++++++
1 file changed, 36 insertions(+)
create mode 100644 Documentation/devicetree/bindings/display/panel/ti,nspire.yaml
diff --git a/Documentation/devicetree/bindings/display/panel/ti,nspire.yaml b/Documentation/devicetree/bindings/display/panel/ti,nspire.yaml
new file mode 100644
index 000000000000..fa81602a922a
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/panel/ti,nspire.yaml
@@ -0,0 +1,36 @@
+# SPDX-License-Identifier: (GPL-2.0+ OR X11)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/panel/ti,nspire.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Texas Instruments NSPIRE Display Panels
+
+maintainers:
+ - Linus Walleij <linus.walleij@linaro.org>
+
+properties:
+ compatible:
+ oneOf:
+ - items:
+ - enum:
+ - ti,nspire-cx-lcd-panel
+ - ti,nspire-classic-lcd-panel
+
+required:
+ - compatible
+
+additionalProperties: false
+
+examples:
+ - |
+ panel {
+ compatible = "ti,nspire-cx-lcd-panel";
+ ports {
+ port {
+ panel_in: endpoint {
+ remote-endpoint = <&pads>;
+ };
+ };
+ };
+ };
--
2.21.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH 1/4 v2] drm/pl111: Support grayscale
From: Linus Walleij @ 2019-08-05 8:58 UTC (permalink / raw)
To: Daniel Tang, Fabian Vogt
Cc: Linus Walleij, Sam Ravnborg, dri-devel, linux-arm-kernel
In-Reply-To: <20190805085847.25554-1-linus.walleij@linaro.org>
Migrating the TI nspire calculators to use the PL111 driver for
framebuffer requires grayscale support for the elder panel
which uses 8bit grayscale only.
DRM does not support 8bit grayscale framebuffers in memory,
but by defining the bus format to be MEDIA_BUS_FMT_Y8_1X8 we
can get the hardware to turn on a grayscaling feature and
convert the RGB framebuffer to grayscale for us.
Cc: Daniel Tang <dt.tangr@gmail.com>
Cc: Fabian Vogt <fabian@ritter-vogt.de>
Tested-by: Fabian Vogt <fabian@ritter-vogt.de>
Acked-by: Sam Ravnborg <sam@ravnborg.org>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
---
ChangeLog v1->v2:
- Now tested
---
drivers/gpu/drm/pl111/pl111_display.c | 29 +++++++++++++++++++++++++--
include/linux/amba/clcd-regs.h | 1 +
2 files changed, 28 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/pl111/pl111_display.c b/drivers/gpu/drm/pl111/pl111_display.c
index 450166d167f6..1751fca6f6f5 100644
--- a/drivers/gpu/drm/pl111/pl111_display.c
+++ b/drivers/gpu/drm/pl111/pl111_display.c
@@ -126,6 +126,7 @@ static void pl111_display_enable(struct drm_simple_display_pipe *pipe,
struct drm_framebuffer *fb = plane->state->fb;
struct drm_connector *connector = priv->connector;
struct drm_bridge *bridge = priv->bridge;
+ bool grayscale = false;
u32 cntl;
u32 ppl, hsw, hfp, hbp;
u32 lpp, vsw, vfp, vbp;
@@ -185,6 +186,20 @@ static void pl111_display_enable(struct drm_simple_display_pipe *pipe,
if (connector->display_info.bus_flags &
DRM_BUS_FLAG_PIXDATA_DRIVE_NEGEDGE)
tim2 |= TIM2_IPC;
+
+ if (connector->display_info.num_bus_formats == 1 &&
+ connector->display_info.bus_formats[0] ==
+ MEDIA_BUS_FMT_Y8_1X8)
+ grayscale = true;
+
+ /*
+ * The AC pin bias frequency is set to max count when using
+ * grayscale so at least once in a while we will reverse
+ * polarity and get rid of any DC built up that could
+ * damage the display.
+ */
+ if (grayscale)
+ tim2 |= TIM2_ACB_MASK;
}
if (bridge) {
@@ -216,8 +231,18 @@ static void pl111_display_enable(struct drm_simple_display_pipe *pipe,
writel(0, priv->regs + CLCD_TIM3);
- /* Hard-code TFT panel */
- cntl = CNTL_LCDEN | CNTL_LCDTFT | CNTL_LCDVCOMP(1);
+ /*
+ * Detect grayscale bus format. We do not support a grayscale mode
+ * toward userspace, instead we expose an RGB24 buffer and then the
+ * hardware will activate its grayscaler to convert to the grayscale
+ * format.
+ */
+ if (grayscale)
+ cntl = CNTL_LCDEN | CNTL_LCDMONO8;
+ else
+ /* Else we assume TFT display */
+ cntl = CNTL_LCDEN | CNTL_LCDTFT | CNTL_LCDVCOMP(1);
+
/* On the ST Micro variant, assume all 24 bits are connected */
if (priv->variant->st_bitmux_control)
cntl |= CNTL_ST_CDWID_24;
diff --git a/include/linux/amba/clcd-regs.h b/include/linux/amba/clcd-regs.h
index 516a6fda83c5..421b0fa90d6a 100644
--- a/include/linux/amba/clcd-regs.h
+++ b/include/linux/amba/clcd-regs.h
@@ -42,6 +42,7 @@
#define TIM2_PCD_LO_MASK GENMASK(4, 0)
#define TIM2_PCD_LO_BITS 5
#define TIM2_CLKSEL (1 << 5)
+#define TIM2_ACB_MASK GENMASK(10, 6)
#define TIM2_IVS (1 << 11)
#define TIM2_IHS (1 << 12)
#define TIM2_IPC (1 << 13)
--
2.21.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH 0/4 v2] PL111 DRM conversion of nspire
From: Linus Walleij @ 2019-08-05 8:58 UTC (permalink / raw)
To: Daniel Tang, Fabian Vogt; +Cc: Linus Walleij, dri-devel, linux-arm-kernel
This now works, I think.
So this is a cold-coded attempt to move the TI nspire over to
using DRM. It is more or less the last user of the old fbdev
driver so it is a noble cause and interesting usecase.
This can be applied on top of a vanilla Torvalds v5.3-rc1
kernel out since sunday.
I do not expect these patches to "just work", I expect them to
need some hacking, so someone who is actually working on the
hardware will need to step in and fix it up.
It does outline the overall idea of how to do this.
I found no defconfig for nspire in the kernel so I used
ARMv4t multi.
Configuring the driver for nspire:
- Disable CONFIG_FB_ARMCLCD
- Enable CONFIG_DRM_PL111, CONFIG_DRM_PANEL_SIMPLE
The ARM patch will be merged separately through ARM SoC.
Linus Walleij (4):
drm/pl111: Support grayscale
drm/panel: simple: Add TI nspire panel bindings
drm/panel: simple: Support TI nspire panels
ARM: nspire: Move CLCD set-up to device tree
.../bindings/display/panel/ti,nspire.yaml | 36 ++++++
arch/arm/boot/dts/nspire-classic.dtsi | 19 ++-
arch/arm/boot/dts/nspire-cx.dts | 18 ++-
arch/arm/boot/dts/nspire.dtsi | 10 +-
arch/arm/mach-nspire/Makefile | 1 -
arch/arm/mach-nspire/clcd.c | 114 ------------------
arch/arm/mach-nspire/clcd.h | 10 --
arch/arm/mach-nspire/nspire.c | 25 ----
drivers/gpu/drm/panel/panel-simple.c | 64 ++++++++++
drivers/gpu/drm/pl111/pl111_display.c | 29 ++++-
include/linux/amba/clcd-regs.h | 1 +
11 files changed, 171 insertions(+), 156 deletions(-)
create mode 100644 Documentation/devicetree/bindings/display/panel/ti,nspire.yaml
delete mode 100644 arch/arm/mach-nspire/clcd.c
delete mode 100644 arch/arm/mach-nspire/clcd.h
--
2.21.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v3 2/2] ARM: dts: imx6ul-kontron-n6310: Add Kontron i.MX6UL N6310 SoM and boards
From: Krzysztof Kozlowski @ 2019-08-05 8:52 UTC (permalink / raw)
To: Shawn Guo
Cc: Mark Rutland, devicetree, Sascha Hauer,
linux-kernel@vger.kernel.org, Schrempf Frieder, Rob Herring,
NXP Linux Team, Pengutronix Kernel Team, Fabio Estevam,
linux-arm-kernel
In-Reply-To: <20190803154724.GS8870@X250.getinternet.no>
On Sat, 3 Aug 2019 at 17:47, Shawn Guo <shawnguo@kernel.org> wrote:
>
> On Mon, Jul 29, 2019 at 07:20:07PM +0200, Krzysztof Kozlowski wrote:
> > Add support for i.MX6UL modules from Kontron Electronics GmbH (before
> > acquisition: Exceet Electronics) and evalkit boards based on it:
> >
> > 1. N6310 SOM: i.MX6 UL System-on-Module, a 25x25 mm solderable module
> > (LGA pads and pin castellations) with 256 MB RAM, 1 MB NOR-Flash,
> > 256 MB NAND and other interfaces,
> > 2. N6310 S: evalkit, w/wo eMMC, without display,
> > 3. N6310 S 43: evalkit with 4.3" display,
> > 4. N6310 S 50: evalkit with 5.0" display.
> >
> > This includes device nodes for unsupported displays (Admatec
> > T043C004800272T2A and T070P133T0S301).
>
> Do not include unsupported devices.
OK
>
> >
> > The work is based on Exceet/Kontron source code (GPLv2) with numerous
> > changes:
> > 1. Reorganize files,
> > 2. Rename Exceet -> Kontron,
> > 3. Rename models/compatibles to match newest Kontron product naming,
> > 4. Fix coding style errors and adjust to device tree coding guidelines,
> > 5. Fix DTC warnings,
> > 6. Extend compatibles so eval boards inherit the SoM compatible,
> > 7. Use defines instead of GPIO and interrupt flag values,
> > 8. Use proper vendor compatible for Macronix SPI NOR,
> > 9. Sort nodes alphabetically.
> >
> > Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
> >
> > ---
> >
> > Changes since v2, after Fabio's review:
> > 1. Add "imx6ul" compatible to board name (that's what I understood from
> > review),
> > 2. Add vendor/device prefix to eeprom and document the compatible,
> > 3. Use "admatecde" as vendor compatible to avoid confusion with Admatec
> > AG in Switzerland (also making LCD panels),
> > 4. Use generic names for nodes,
> > 5. Use IRQ_TYPE_LEVEL_LOW,
> > 6. Move iomux to the end of files,
> > 7. Remove regulators node (include regulators in top level),
> > 8. Remove cpu clock-frequency,
> > 9. Other minor fixes pointed by Fabio.
> >
> > Changes since v1, after Frieder's review:
> > 1. Remove unneeded license notes,
> > 2. Add Kontron copyright (2018),
> > 3. Rename the files/models/compatibles to new naming - N6310,
> > 4. Remove unneeded CPU operating points override,
> > 5. Switch regulator nodes into simple children nodes without addresses
> > (so not simple bus),
> > 6. Use proper vendor compatible for Macronix SPI NOR.
> > ---
> > .../devicetree/bindings/arm/fsl.yaml | 4 +
> > .../devicetree/bindings/eeprom/at25.txt | 1 +
>
> Please make them two separate patches.
Sure.
>
> > arch/arm/boot/dts/Makefile | 3 +
> > .../boot/dts/imx6ul-kontron-n6310-s-43.dts | 119 +++++
> > .../boot/dts/imx6ul-kontron-n6310-s-50.dts | 119 +++++
>
> Are they identical except the display node? Please manage to save
> duplicated data.
Since removing of display panels (unsupported), there will be no
differentiation between S-43 and S-50.
>
> > arch/arm/boot/dts/imx6ul-kontron-n6310-s.dts | 420 ++++++++++++++++++
> > .../boot/dts/imx6ul-kontron-n6310-som.dtsi | 134 ++++++
> > 7 files changed, 800 insertions(+)
> > create mode 100644 arch/arm/boot/dts/imx6ul-kontron-n6310-s-43.dts
> > create mode 100644 arch/arm/boot/dts/imx6ul-kontron-n6310-s-50.dts
> > create mode 100644 arch/arm/boot/dts/imx6ul-kontron-n6310-s.dts
> > create mode 100644 arch/arm/boot/dts/imx6ul-kontron-n6310-som.dtsi
> >
> > diff --git a/Documentation/devicetree/bindings/arm/fsl.yaml b/Documentation/devicetree/bindings/arm/fsl.yaml
> > index 7294ac36f4c0..6a6c09d67dea 100644
> > --- a/Documentation/devicetree/bindings/arm/fsl.yaml
> > +++ b/Documentation/devicetree/bindings/arm/fsl.yaml
> > @@ -161,6 +161,10 @@ properties:
> > items:
> > - enum:
> > - fsl,imx6ul-14x14-evk # i.MX6 UltraLite 14x14 EVK Board
> > + - kontron,imx6ul-n6310-som # Kontron N6310 SOM
> > + - kontron,imx6ul-n6310-s # Kontron N6310 S Board
> > + - kontron,imx6ul-n6310-s-43 # Kontron N6310 S 43 Board
> > + - kontron,imx6ul-n6310-s-50 # Kontron N6310 S 50 Board
> > - const: fsl,imx6ul
> >
> > - description: i.MX6ULL based Boards
> > diff --git a/Documentation/devicetree/bindings/eeprom/at25.txt b/Documentation/devicetree/bindings/eeprom/at25.txt
> > index b3bde97dc199..42577dd113dd 100644
> > --- a/Documentation/devicetree/bindings/eeprom/at25.txt
> > +++ b/Documentation/devicetree/bindings/eeprom/at25.txt
> > @@ -3,6 +3,7 @@ EEPROMs (SPI) compatible with Atmel at25.
> > Required properties:
> > - compatible : Should be "<vendor>,<type>", and generic value "atmel,at25".
> > Example "<vendor>,<type>" values:
> > + "anvo,anv32e61w"
> > "microchip,25lc040"
> > "st,m95m02"
> > "st,m95256"
> > diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
> > index 9159fa2cea90..28b6cb3454a3 100644
> > --- a/arch/arm/boot/dts/Makefile
> > +++ b/arch/arm/boot/dts/Makefile
> > @@ -569,6 +569,9 @@ dtb-$(CONFIG_SOC_IMX6UL) += \
> > imx6ul-geam.dtb \
> > imx6ul-isiot-emmc.dtb \
> > imx6ul-isiot-nand.dtb \
> > + imx6ul-kontron-n6310-s.dtb \
> > + imx6ul-kontron-n6310-s-43.dtb \
> > + imx6ul-kontron-n6310-s-50.dtb \
> > imx6ul-liteboard.dtb \
> > imx6ul-opos6uldev.dtb \
> > imx6ul-pico-hobbit.dtb \
> > diff --git a/arch/arm/boot/dts/imx6ul-kontron-n6310-s-43.dts b/arch/arm/boot/dts/imx6ul-kontron-n6310-s-43.dts
> > new file mode 100644
> > index 000000000000..c83793725245
> > --- /dev/null
> > +++ b/arch/arm/boot/dts/imx6ul-kontron-n6310-s-43.dts
> > @@ -0,0 +1,119 @@
> > +// SPDX-License-Identifier: GPL-2.0
> > +/*
> > + * Copyright (C) 2017 exceet electronics GmbH
> > + * Copyright (C) 2018 Kontron Electronics GmbH
> > + * Copyright (c) 2019 Krzysztof Kozlowski <krzk@kernel.org>
> > + */
> > +
> > +#include "imx6ul-kontron-n6310-s.dts"
> > +
> > +/ {
> > + model = "Kontron N6310 S 43";
> > + compatible = "kontron,imx6ul-n6310-s-43", "kontron,imx6ul-n6310-s",
> > + "kontron,imx6ul-n6310-som", "fsl,imx6ul";
> > +
> > + backlight: backlight {
> > + compatible = "pwm-backlight";
> > + pwms = <&pwm7 0 5000000>;
> > + brightness-levels = <0 4 8 16 32 64 128 255>;
> > + default-brightness-level = <6>;
> > + status = "okay";
> > + };
> > +
> > + panel {
> > + compatible = "admatecde,t043c004800272t2a";
>
> Undocumented/unsupported compatible?
>
> > + backlight = <&backlight>;
> > +
> > + port {
> > + panel_in: endpoint {
> > + remote-endpoint = <&display_out>;
> > + };
> > + };
> > + };
> > +};
> > +
> > +&i2c4 {
> > + touchscreen@5d {
> > + compatible = "goodix,gt928";
> > + reg = <0x5d>;
> > + pinctrl-names = "default";
> > + pinctrl-0 = <&pinctrl_cap_touch>;
> > + interrupt-parent = <&gpio5>;
> > + interrupts = <6 IRQ_TYPE_LEVEL_LOW>;
> > + reset-gpios = <&gpio5 8 GPIO_ACTIVE_HIGH>;
> > + irq-gpios = <&gpio5 6 GPIO_ACTIVE_HIGH>;
> > + };
> > +};
> > +
> > +&lcdif {
> > + pinctrl-names = "default";
> > + pinctrl-0 = <&pinctrl_lcdif_dat &pinctrl_lcdif_ctrl>;
> > + status = "okay";
> > +
> > + port {
> > + display_out: endpoint {
> > + remote-endpoint = <&panel_in>;
> > + };
> > + };
> > +};
> > +
> > +&pwm7 {
> > + pinctrl-names = "default";
> > + pinctrl-0 = <&pinctrl_pwm7>;
> > + status = "okay";
> > +};
> > +
> > +&iomuxc {
> > + pinctrl_lcdif_dat: lcdifdatgrp {
> > + fsl,pins = <
> > + MX6UL_PAD_LCD_DATA00__LCDIF_DATA00 0x79
> > + MX6UL_PAD_LCD_DATA01__LCDIF_DATA01 0x79
> > + MX6UL_PAD_LCD_DATA02__LCDIF_DATA02 0x79
> > + MX6UL_PAD_LCD_DATA03__LCDIF_DATA03 0x79
> > + MX6UL_PAD_LCD_DATA04__LCDIF_DATA04 0x79
> > + MX6UL_PAD_LCD_DATA05__LCDIF_DATA05 0x79
> > + MX6UL_PAD_LCD_DATA06__LCDIF_DATA06 0x79
> > + MX6UL_PAD_LCD_DATA07__LCDIF_DATA07 0x79
> > + MX6UL_PAD_LCD_DATA08__LCDIF_DATA08 0x79
> > + MX6UL_PAD_LCD_DATA09__LCDIF_DATA09 0x79
> > + MX6UL_PAD_LCD_DATA10__LCDIF_DATA10 0x79
> > + MX6UL_PAD_LCD_DATA11__LCDIF_DATA11 0x79
> > + MX6UL_PAD_LCD_DATA12__LCDIF_DATA12 0x79
> > + MX6UL_PAD_LCD_DATA13__LCDIF_DATA13 0x79
> > + MX6UL_PAD_LCD_DATA14__LCDIF_DATA14 0x79
> > + MX6UL_PAD_LCD_DATA15__LCDIF_DATA15 0x79
> > + MX6UL_PAD_LCD_DATA16__LCDIF_DATA16 0x79
> > + MX6UL_PAD_LCD_DATA17__LCDIF_DATA17 0x79
> > + MX6UL_PAD_LCD_DATA18__LCDIF_DATA18 0x79
> > + MX6UL_PAD_LCD_DATA19__LCDIF_DATA19 0x79
> > + MX6UL_PAD_LCD_DATA20__LCDIF_DATA20 0x79
> > + MX6UL_PAD_LCD_DATA21__LCDIF_DATA21 0x79
> > + MX6UL_PAD_LCD_DATA22__LCDIF_DATA22 0x79
> > + MX6UL_PAD_LCD_DATA23__LCDIF_DATA23 0x79
> > + >;
> > + };
> > +
> > + pinctrl_lcdif_ctrl: lcdifctrlgrp {
> > + fsl,pins = <
> > + MX6UL_PAD_LCD_CLK__LCDIF_CLK 0x79
> > + MX6UL_PAD_LCD_ENABLE__LCDIF_ENABLE 0x79
> > + MX6UL_PAD_LCD_HSYNC__LCDIF_HSYNC 0x79
> > + MX6UL_PAD_LCD_VSYNC__LCDIF_VSYNC 0x79
> > + MX6UL_PAD_LCD_RESET__LCDIF_RESET 0x79
> > + >;
> > + };
> > +
> > + pinctrl_cap_touch: captouchgrp {
> > + fsl,pins = <
> > + MX6UL_PAD_SNVS_TAMPER6__GPIO5_IO06 0x1b0b0 /* Touch Interrupt */
> > + MX6UL_PAD_SNVS_TAMPER7__GPIO5_IO07 0x1b0b0 /* Touch Reset */
> > + MX6UL_PAD_SNVS_TAMPER8__GPIO5_IO08 0x1b0b0 /* Touch Wake */
> > + >;
> > + };
> > +
> > + pinctrl_pwm7: pwm7grp {
> > + fsl,pins = <
> > + MX6UL_PAD_CSI_VSYNC__PWM7_OUT 0x110b0
> > + >;
> > + };
> > +};
> > diff --git a/arch/arm/boot/dts/imx6ul-kontron-n6310-s-50.dts b/arch/arm/boot/dts/imx6ul-kontron-n6310-s-50.dts
> > new file mode 100644
> > index 000000000000..f9c9afa58771
> > --- /dev/null
> > +++ b/arch/arm/boot/dts/imx6ul-kontron-n6310-s-50.dts
> > @@ -0,0 +1,119 @@
> > +// SPDX-License-Identifier: GPL-2.0
> > +/*
> > + * Copyright (C) 2017 exceet electronics GmbH
> > + * Copyright (C) 2018 Kontron Electronics GmbH
> > + * Copyright (c) 2019 Krzysztof Kozlowski <krzk@kernel.org>
> > + */
> > +
> > +#include "imx6ul-kontron-n6310-s.dts"
> > +
> > +/ {
> > + model = "Kontron N6310 S 50";
> > + compatible = "kontron,imx6ul-n6310-s-50", "kontron,imx6ul-n6310-s",
> > + "kontron,imx6ul-n6310-som", "fsl,imx6ul";
> > +
> > + backlight: backlight {
> > + compatible = "pwm-backlight";
> > + pwms = <&pwm7 0 5000000>;
> > + brightness-levels = <0 4 8 16 32 64 128 255>;
> > + default-brightness-level = <6>;
> > + status = "okay";
> > + };
> > +
> > + panel {
> > + compatible = "admatecde,t070p133t0s301";
> > + backlight = <&backlight>;
> > +
> > + port {
> > + panel_in: endpoint {
> > + remote-endpoint = <&display_out>;
> > + };
> > + };
> > + };
> > +};
> > +
> > +&i2c4 {
> > + touchscreen@5d {
> > + compatible = "goodix,gt928";
> > + reg = <0x5d>;
> > + pinctrl-names = "default";
> > + pinctrl-0 = <&pinctrl_cap_touch>;
> > + interrupt-parent = <&gpio5>;
> > + interrupts = <6 IRQ_TYPE_LEVEL_LOW>;
> > + reset-gpios = <&gpio5 8 GPIO_ACTIVE_HIGH>;
> > + irq-gpios = <&gpio5 6 GPIO_ACTIVE_HIGH>;
> > + };
> > +};
> > +
> > +&lcdif {
> > + pinctrl-names = "default";
> > + pinctrl-0 = <&pinctrl_lcdif_dat &pinctrl_lcdif_ctrl>;
> > + status = "okay";
> > +
> > + port {
> > + display_out: endpoint {
> > + remote-endpoint = <&panel_in>;
> > + };
> > + };
> > +};
> > +
> > +&pwm7 {
> > + pinctrl-names = "default";
> > + pinctrl-0 = <&pinctrl_pwm7>;
> > + status = "okay";
> > +};
> > +
> > +&iomuxc {
> > + pinctrl_lcdif_dat: lcdifdatgrp {
> > + fsl,pins = <
> > + MX6UL_PAD_LCD_DATA00__LCDIF_DATA00 0x79
> > + MX6UL_PAD_LCD_DATA01__LCDIF_DATA01 0x79
> > + MX6UL_PAD_LCD_DATA02__LCDIF_DATA02 0x79
> > + MX6UL_PAD_LCD_DATA03__LCDIF_DATA03 0x79
> > + MX6UL_PAD_LCD_DATA04__LCDIF_DATA04 0x79
> > + MX6UL_PAD_LCD_DATA05__LCDIF_DATA05 0x79
> > + MX6UL_PAD_LCD_DATA06__LCDIF_DATA06 0x79
> > + MX6UL_PAD_LCD_DATA07__LCDIF_DATA07 0x79
> > + MX6UL_PAD_LCD_DATA08__LCDIF_DATA08 0x79
> > + MX6UL_PAD_LCD_DATA09__LCDIF_DATA09 0x79
> > + MX6UL_PAD_LCD_DATA10__LCDIF_DATA10 0x79
> > + MX6UL_PAD_LCD_DATA11__LCDIF_DATA11 0x79
> > + MX6UL_PAD_LCD_DATA12__LCDIF_DATA12 0x79
> > + MX6UL_PAD_LCD_DATA13__LCDIF_DATA13 0x79
> > + MX6UL_PAD_LCD_DATA14__LCDIF_DATA14 0x79
> > + MX6UL_PAD_LCD_DATA15__LCDIF_DATA15 0x79
> > + MX6UL_PAD_LCD_DATA16__LCDIF_DATA16 0x79
> > + MX6UL_PAD_LCD_DATA17__LCDIF_DATA17 0x79
> > + MX6UL_PAD_LCD_DATA18__LCDIF_DATA18 0x79
> > + MX6UL_PAD_LCD_DATA19__LCDIF_DATA19 0x79
> > + MX6UL_PAD_LCD_DATA20__LCDIF_DATA20 0x79
> > + MX6UL_PAD_LCD_DATA21__LCDIF_DATA21 0x79
> > + MX6UL_PAD_LCD_DATA22__LCDIF_DATA22 0x79
> > + MX6UL_PAD_LCD_DATA23__LCDIF_DATA23 0x79
> > + >;
> > + };
> > +
> > + pinctrl_lcdif_ctrl: lcdifctrlgrp {
> > + fsl,pins = <
> > + MX6UL_PAD_LCD_CLK__LCDIF_CLK 0x79
> > + MX6UL_PAD_LCD_ENABLE__LCDIF_ENABLE 0x79
> > + MX6UL_PAD_LCD_HSYNC__LCDIF_HSYNC 0x79
> > + MX6UL_PAD_LCD_VSYNC__LCDIF_VSYNC 0x79
> > + MX6UL_PAD_LCD_RESET__LCDIF_RESET 0x79
> > + >;
> > + };
> > +
> > + pinctrl_cap_touch: captouchgrp {
> > + fsl,pins = <
> > + MX6UL_PAD_SNVS_TAMPER6__GPIO5_IO06 0x1b0b0 /* Touch Interrupt */
> > + MX6UL_PAD_SNVS_TAMPER7__GPIO5_IO07 0x1b0b0 /* Touch Reset */
> > + MX6UL_PAD_SNVS_TAMPER8__GPIO5_IO08 0x1b0b0 /* Touch Wake */
> > + >;
> > + };
> > +
> > + pinctrl_pwm7: pwm7grp {
> > + fsl,pins = <
> > + MX6UL_PAD_CSI_VSYNC__PWM7_OUT 0x110b0
> > + >;
> > + };
> > +};
> > diff --git a/arch/arm/boot/dts/imx6ul-kontron-n6310-s.dts b/arch/arm/boot/dts/imx6ul-kontron-n6310-s.dts
> > new file mode 100644
> > index 000000000000..4206a4b3f0df
> > --- /dev/null
> > +++ b/arch/arm/boot/dts/imx6ul-kontron-n6310-s.dts
> > @@ -0,0 +1,420 @@
> > +// SPDX-License-Identifier: GPL-2.0
> > +/*
> > + * Copyright (C) 2017 exceet electronics GmbH
> > + * Copyright (C) 2018 Kontron Electronics GmbH
> > + * Copyright (c) 2019 Krzysztof Kozlowski <krzk@kernel.org>
> > + */
> > +
> > +/dts-v1/;
> > +
> > +#include "imx6ul-kontron-n6310-som.dtsi"
> > +
> > +/ {
> > + model = "Kontron N6310 S";
> > + compatible = "kontron,imx6ul-n6310-s", "kontron,imx6ul-n6310-som",
> > + "fsl,imx6ul";
> > +
> > + pwm-beeper {
> > + compatible = "pwm-beeper";
> > + pwms = <&pwm8 0 5000>;
> > + };
> > +
> > + gpio-leds {
> > + compatible = "gpio-leds";
> > + pinctrl-names = "default";
> > + pinctrl-0 = <&pinctrl_gpio_leds>;
> > +
> > + led1 {
> > + label = "debug-led1";
> > + gpios = <&gpio1 30 GPIO_ACTIVE_LOW>;
> > + default-state = "off";
> > + linux,default-trigger = "heartbeat";
> > + };
> > +
> > + led2 {
> > + label = "debug-led2";
> > + gpios = <&gpio5 3 GPIO_ACTIVE_LOW>;
> > + default-state = "off";
> > + };
> > +
> > + led3 {
> > + label = "debug-led3";
> > + gpios = <&gpio5 2 GPIO_ACTIVE_LOW>;
> > + default-state = "off";
> > + };
> > + };
> > +
> > + reg_3v3: regulator-3v3 {
> > + compatible = "regulator-fixed";
> > + regulator-name = "3v3";
> > + regulator-min-microvolt = <3300000>;
> > + regulator-max-microvolt = <3300000>;
> > + };
> > +
> > + reg_vref_adc: regulator-vref-adc {
> > + compatible = "regulator-fixed";
> > + regulator-name = "vref-adc";
> > + regulator-min-microvolt = <3300000>;
> > + regulator-max-microvolt = <3300000>;
> > + };
> > +
> > + reg_usb_otg1_vbus: regulator-usb-otg1-vbus {
> > + compatible = "regulator-fixed";
> > + regulator-name = "usb_otg1_vbus";
> > + regulator-min-microvolt = <5000000>;
> > + regulator-max-microvolt = <5000000>;
> > + gpio = <&gpio1 4 GPIO_ACTIVE_HIGH>;
> > + enable-active-high;
> > + };
> > +};
> > +
> > +&adc1 {
> > + pinctrl-names = "default";
> > + pinctrl-0 = <&pinctrl_adc1>;
> > + num-channels = <3>;
> > + vref-supply = <®_vref_adc>;
> > + status = "okay";
> > +};
> > +
> > +&can2 {
> > + pinctrl-names = "default";
> > + pinctrl-0 = <&pinctrl_flexcan2>;
> > + status = "okay";
> > +};
> > +
> > +&ecspi1 {
> > + cs-gpios = <&gpio4 26 GPIO_ACTIVE_HIGH>;
> > + pinctrl-names = "default";
> > + pinctrl-0 = <&pinctrl_ecspi1>;
> > + status = "okay";
> > +
> > + eeprom@0 {
> > + compatible = "anvo,anv32e61w", "atmel,at25";
> > + reg = <0>;
> > + spi-max-frequency = <20000000>;
> > + spi-cpha;
> > + spi-cpol;
> > + pagesize = <1>;
> > + size = <8192>;
> > + address-width = <16>;
> > + };
> > +};
> > +
> > +&fec1 {
> > + pinctrl-0 = <&pinctrl_enet1>;
> > + /delete-node/ mdio;
> > +};
> > +
> > +&fec2 {
> > + pinctrl-names = "default";
> > + pinctrl-0 = <&pinctrl_enet2 &pinctrl_enet2_mdio>;
> > + phy-mode = "rmii";
> > + phy-handle = <ðphy2>;
> > + status = "okay";
> > +
> > + mdio {
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > +
> > + ethphy1: ethernet-phy@1 {
> > + reg = <1>;
> > + micrel,led-mode = <0>;
> > + clocks = <&clks IMX6UL_CLK_ENET_REF>;
> > + clock-names = "rmii-ref";
> > + };
> > +
> > + ethphy2: ethernet-phy@2 {
> > + reg = <2>;
> > + micrel,led-mode = <0>;
> > + clocks = <&clks IMX6UL_CLK_ENET2_REF>;
> > + clock-names = "rmii-ref";
> > + };
> > + };
> > +};
> > +
> > +&i2c1 {
> > + clock-frequency = <100000>;
> > + pinctrl-names = "default";
> > + pinctrl-0 = <&pinctrl_i2c1>;
> > + status = "okay";
> > +};
> > +
> > +&i2c4 {
> > + clock-frequency = <100000>;
> > + pinctrl-names = "default";
> > + pinctrl-0 = <&pinctrl_i2c4>;
> > + status = "okay";
> > +
> > + rtc@32 {
> > + compatible = "epson,rx8900";
> > + reg = <0x32>;
> > + };
> > +};
> > +
> > +&pwm8 {
> > + pinctrl-names = "default";
> > + pinctrl-0 = <&pinctrl_pwm8>;
> > + status = "okay";
> > +};
> > +
> > +&snvs_poweroff {
> > + status = "okay";
> > +};
> > +
> > +&uart1 {
> > + pinctrl-names = "default";
> > + pinctrl-0 = <&pinctrl_uart1>;
> > + status = "okay";
> > +};
> > +
> > +&uart2 {
> > + pinctrl-names = "default";
> > + pinctrl-0 = <&pinctrl_uart2>;
> > + linux,rs485-enabled-at-boot-time;
> > + rs485-rx-during-tx;
> > + rs485-rts-active-low;
> > + uart-has-rtscts;
> > + status = "okay";
> > +};
> > +
> > +&uart3 {
> > + pinctrl-names = "default";
> > + pinctrl-0 = <&pinctrl_uart3>;
> > + fsl,uart-has-rtscts;
> > + status = "okay";
> > +};
> > +
> > +&uart4 {
> > + pinctrl-names = "default";
> > + pinctrl-0 = <&pinctrl_uart4>;
> > + status = "okay";
> > +};
> > +
> > +&usbotg1 {
> > + pinctrl-names = "default";
> > + pinctrl-0 = <&pinctrl_usbotg1>;
> > + dr_mode = "otg";
> > + srp-disable;
> > + hnp-disable;
> > + adp-disable;
> > + vbus-supply = <®_usb_otg1_vbus>;
> > + status = "okay";
> > +};
> > +
> > +&usbotg2 {
> > + dr_mode = "host";
> > + disable-over-current;
> > + status = "okay";
> > +};
> > +
> > +&usdhc1 {
> > + pinctrl-names = "default";
> > + pinctrl-0 = <&pinctrl_usdhc1>;
> > + cd-gpios = <&gpio1 19 GPIO_ACTIVE_LOW>;
> > + keep-power-in-suspend;
> > + enable-sdio-wakeup;
>
> Check Documentation/devicetree/bindings/power/wakeup-source.txt
Indeed, thanks.
> > + vmmc-supply = <®_3v3>;
> > + voltage-ranges = <3300 3300>;
> > + no-1-8-v;
> > + status = "okay";
> > +};
> > +
> > +&usdhc2 {
> > + pinctrl-names = "default", "state_100mhz", "state_200mhz";
> > + pinctrl-0 = <&pinctrl_usdhc2>;
> > + pinctrl-1 = <&pinctrl_usdhc2_100mhz>;
> > + pinctrl-2 = <&pinctrl_usdhc2_200mhz>;
> > + non-removable;
> > + keep-power-in-suspend;
> > + enable-sdio-wakeup;
> > + vmmc-supply = <®_3v3>;
> > + voltage-ranges = <3300 3300>;
> > + no-1-8-v;
> > + status = "okay";
> > +};
> > +
> > +&wdog1 {
> > + pinctrl-names = "default";
> > + pinctrl-0 = <&pinctrl_wdog>;
> > + status = "okay";
>
> We usually put 'status' at the end of property list.
OK
>
> > + fsl,ext-reset-output;
> > +};
> > +
> > +&iomuxc {
> > + pinctrl-0 = <&pinctrl_reset_out &pinctrl_gpio>;
> > +
> > + pinctrl_wdog: wdoggrp {
> > + fsl,pins = <
> > + MX6UL_PAD_GPIO1_IO09__WDOG1_WDOG_ANY 0x30b0
> > + >;
> > + };
> > +
> > + pinctrl_gpio: gpio {
>
> Please consistently name the node like:
>
> pinctrl_xxx: xxxgrp
>
> And keep them well sorted alphabetically.
Sure
>
> > + fsl,pins = <
> > + MX6UL_PAD_SNVS_TAMPER5__GPIO5_IO05 0x1b0b0 /* DOUT1 */
> > + MX6UL_PAD_SNVS_TAMPER4__GPIO5_IO04 0x1b0b0 /* DIN1 */
> > + MX6UL_PAD_SNVS_TAMPER1__GPIO5_IO01 0x1b0b0 /* DOUT2 */
> > + MX6UL_PAD_SNVS_TAMPER0__GPIO5_IO00 0x1b0b0 /* DIN2 */
> > + >;
> > + };
> > +
> > + pinctrl_usbotg1: usbotg1 {
> > + fsl,pins = <
> > + MX6UL_PAD_GPIO1_IO04__GPIO1_IO04 0x1b0b0
> > + >;
> > + };
> > +
> > + pinctrl_gpio_leds: gpio_leds {
> > + fsl,pins = <
> > + MX6UL_PAD_UART5_TX_DATA__GPIO1_IO30 0x1b0b0 /* LED H14 */
> > + MX6UL_PAD_SNVS_TAMPER3__GPIO5_IO03 0x1b0b0 /* LED H15 */
> > + MX6UL_PAD_SNVS_TAMPER2__GPIO5_IO02 0x1b0b0 /* LED H16 */
> > + >;
> > + };
> > +
> > + /* FRAM */
> > + pinctrl_ecspi1: ecspi1grp-1 {
>
> Meaningless '-1' suffix.
Thanks for the review!
Krzysztof
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 0/6] hwspinlock: allow sharing of hwspinlocks
From: Fabien DESSENNE @ 2019-08-05 8:48 UTC (permalink / raw)
To: Bjorn Andersson
Cc: Ohad Ben-Cohen, Mark Rutland, Alexandre TORGUE, Jonathan Corbet,
linux-doc@vger.kernel.org, linux-remoteproc@vger.kernel.org,
linux-kernel@vger.kernel.org, devicetree@vger.kernel.org,
Rob Herring, Maxime Coquelin,
linux-stm32@st-md-mailman.stormreply.com,
linux-arm-kernel@lists.infradead.org, Benjamin GAIGNARD
In-Reply-To: <20190801191403.GA7234@tuxbook-pro>
On 01/08/2019 9:14 PM, Bjorn Andersson wrote:
> On Wed 13 Mar 08:50 PDT 2019, Fabien Dessenne wrote:
>
>> The current implementation does not allow two different devices to use
>> a common hwspinlock. This patch set proposes to have, as an option, some
>> hwspinlocks shared between several users.
>>
>> Below is an example that explain the need for this:
>> exti: interrupt-controller@5000d000 {
>> compatible = "st,stm32mp1-exti", "syscon";
>> interrupt-controller;
>> #interrupt-cells = <2>;
>> reg = <0x5000d000 0x400>;
>> hwlocks = <&hsem 1>;
>> };
>> The two drivers (stm32mp1-exti and syscon) refer to the same hwlock.
>> With the current hwspinlock implementation, only the first driver succeeds
>> in requesting (hwspin_lock_request_specific) the hwlock. The second request
>> fails.
>>
>>
>> The proposed approach does not modify the API, but extends the DT 'hwlocks'
>> property with a second optional parameter (the first one identifies an
>> hwlock) that specifies whether an hwlock is requested for exclusive usage
>> (current behavior) or can be shared between several users.
>> Examples:
>> hwlocks = <&hsem 8>; Ref to hwlock #8 for exclusive usage
>> hwlocks = <&hsem 8 0>; Ref to hwlock #8 for exclusive (0) usage
>> hwlocks = <&hsem 8 1>; Ref to hwlock #8 for shared (1) usage
>>
>> As a constraint, the #hwlock-cells value must be 1 or 2.
>> In the current implementation, this can have theorically any value but:
>> - all of the exisiting drivers use the same value : 1.
>> - the framework supports only one value : 1 (see implementation of
>> of_hwspin_lock_simple_xlate())
>> Hence, it shall not be a problem to restrict this value to 1 or 2 since
>> it won't break any driver.
>>
> Hi Fabien,
>
> Your series looks good, but it makes me wonder why the hardware locks
> should be an exclusive resource.
>
> How about just making all (specific) locks shared?
Hi Bjorn,
Making all locks shared is a possible implementation (my first
implementation
was going this way) but there are some drawbacks we must be aware of:
A/ This theoretically break the legacy behavior (the legacy works with
exclusive (UNUSED radix tag) usage). As a consequence, an existing driver
that is currently failing to request a lock (already claimed by another
user) would now work fine. Not sure that there are such drivers, so this
point is probably not a real issue.
B/ This would introduce some inconsistency between the two 'request' API
which are hwspin_lock_request() and hwspin_lock_request_specific().
hwspin_lock_request() looks for an unused lock, so requests for an exclusive
usage. On the other side, request_specific() would request shared locks.
Worst the following sequence can transform an exclusive usage into a shared
one:
-hwspin_lock_request() -> returns Id#0 (exclusive)
-hwspin_lock_request() -> returns Id#1 (exclusive)
-hwspin_lock_request_specific(0) -> returns Id#0 and makes Id#0 shared
Honestly I am not sure that this is a real issue, but it's better to have it
in mind before we take ay decision
I could not find any driver using the hwspin_lock_request() API, we may
decide
to remove (or to make deprecated) this API, having everything 'shared
without
any conditions'.
I can see three options:
1- Keep my initial proposition
2- Have hwspin_lock_request_specific() using shared locks and
hwspin_lock_request() using unused (so 'initially' exclusive) locks.
3- Have hwspin_lock_request_specific() using shared locks and
remove/make deprecated hwspin_lock_request().
Just let me know what is your preference.
BR
Fabien
>
> Regards,
> Bjorn
>
>> Fabien Dessenne (6):
>> dt-bindings: hwlock: add support of shared locks
>> hwspinlock: allow sharing of hwspinlocks
>> dt-bindings: hwlock: update STM32 #hwlock-cells value
>> ARM: dts: stm32: Add hwspinlock node for stm32mp157 SoC
>> ARM: dts: stm32: Add hwlock for irqchip on stm32mp157
>> ARM: dts: stm32: hwlocks for GPIO for stm32mp157
>>
>> .../devicetree/bindings/hwlock/hwlock.txt | 27 +++++--
>> .../bindings/hwlock/st,stm32-hwspinlock.txt | 6 +-
>> Documentation/hwspinlock.txt | 10 ++-
>> arch/arm/boot/dts/stm32mp157-pinctrl.dtsi | 2 +
>> arch/arm/boot/dts/stm32mp157c.dtsi | 10 +++
>> drivers/hwspinlock/hwspinlock_core.c | 82 +++++++++++++++++-----
>> drivers/hwspinlock/hwspinlock_internal.h | 2 +
>> 7 files changed, 108 insertions(+), 31 deletions(-)
>>
>> --
>> 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 v2 0/5] ARM: make DaVinci part of the ARM v5 multiplatform build
From: Bartosz Golaszewski @ 2019-08-05 8:31 UTC (permalink / raw)
To: Arnd Bergmann
Cc: David Lechner, Kevin Hilman, Sekhar Nori,
Linux Kernel Mailing List, Bartosz Golaszewski, Hans Verkuil,
Mauro Carvalho Chehab, Linux ARM, Linux Media Mailing List
In-Reply-To: <CAK8P3a1FXyRRi5q48h-=egFjgoRJvy6_zuO9MQaAOMA-bsJKRA@mail.gmail.com>
czw., 25 lip 2019 o 16:57 Arnd Bergmann <arnd@arndb.de> napisał(a):
>
> On Thu, Jul 25, 2019 at 3:13 PM Bartosz Golaszewski <brgl@bgdev.pl> wrote:
> >
> > From: Bartosz Golaszewski <bgolaszewski@baylibre.com>
> >
> > This series makes DaVinci part of the multiplatform build for ARM v5.
> >
> > First three patches fix build errors spotted and fixed by Arnd with v1.
> >
> > The fourth patch adds necessary bits and pieces for davinci to support
> > multiplatform build and the last one actually adds all davinci boards
> > to multi_v5_defconfig.
> >
> > Tested on da850-lcdk with both multi_v5 as well as davinci_all defconfigs.
> >
> > v1 -> v2:
> > - added patches from Arnd that fix build errors spotted when building
> > random configurations (much appreciated)
> > - rebased on top of v5.3-rc1
>
> > Arnd Bergmann (3):
> > staging: media/davinci_vpfe: fix pinmux setup compilation
> > media: davinci-vpbe: remove obsolete includes
> > davinci: fix sleep.S build error on ARMv4
> >
> > Bartosz Golaszewski (2):
> > ARM: davinci: support multiplatform build for ARM v5
> > ARM: multi_v5_defconfig: make DaVinci part of the ARM v5 multiplatform build
>
>
> Thanks a lot for reposting the series!
>
> I wonder how we shoud deal with the dependencies now that the two media
> patches got merged in the linux-media tree.
>
> It would be tempting to just merge the arch/arm/ changes, but that creates
> a bisection problem when the vpbe driver is enabled. I don't care
> about the staging driver really as that one is broken anyway, but including
> the "media: davinci-vpbe: remove obsolete includes" fix would be better
> here.
>
> Mauro, any idea for how to handle that? Should we apply an identical
> patch to the davinci tree, or maybe only have it the ARM tree and you
> drop it from your tree (I don't know if you have a rule against rebasing).
> Sorry for not coordinating with Bartosz before I sent the patch again
> earlier this week.
>
>
> Arnd
Hi Arnd,
is there any action required from me for this series?
Bart
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v2 0/9] ARM: davinci: da850-evm: remove more legacy GPIO calls
From: Bartosz Golaszewski @ 2019-08-05 8:30 UTC (permalink / raw)
To: Sekhar Nori, Kevin Hilman, Bartlomiej Zolnierkiewicz,
David Lechner, Linus Walleij
Cc: Bartosz Golaszewski, linux-fbdev, Linux Kernel Mailing List,
Linux ARM
In-Reply-To: <20190722134423.26555-1-brgl@bgdev.pl>
pon., 22 lip 2019 o 15:44 Bartosz Golaszewski <brgl@bgdev.pl> napisał(a):
>
> From: Bartosz Golaszewski <bgolaszewski@baylibre.com>
>
> This is another small step on the path to liberating davinci from legacy
> GPIO API calls and shrinking the davinci GPIO driver by not having to
> support the base GPIO number anymore.
>
> This time we're removing the legacy calls used indirectly by the LCDC
> fbdev driver.
>
> First two patches enable the GPIO backlight driver in
> davinci_all_defconfig.
>
> Patch 3/12 models the backlight GPIO as an actual GPIO backlight device.
>
> Patches 4-6 extend the fbdev driver with regulator support and convert
> the da850-evm board file to using it.
>
> Last three patches are improvements to the da8xx fbdev driver since
> we're already touching it in this series.
>
> v1 -> v2:
> - dopped the gpio-backlight patches from this series as since v5.3-rc1 we
> can probe the module with neither the OF node nor platform data
> - collected review and ack tags
> - rebased on top of v5.3-rc1
>
> Bartosz Golaszewski (9):
> ARM: davinci: refresh davinci_all_defconfig
> ARM: davinci_all_defconfig: enable GPIO backlight
> ARM: davinci: da850-evm: model the backlight GPIO as an actual device
> fbdev: da8xx: add support for a regulator
> ARM: davinci: da850-evm: switch to using a fixed regulator for lcdc
> fbdev: da8xx: remove panel_power_ctrl() callback from platform data
> fbdev: da8xx-fb: use devm_platform_ioremap_resource()
> fbdev: da8xx-fb: drop a redundant if
> fbdev: da8xx: use resource management for dma
>
> arch/arm/configs/davinci_all_defconfig | 27 ++----
> arch/arm/mach-davinci/board-da850-evm.c | 90 +++++++++++++-----
> drivers/video/fbdev/da8xx-fb.c | 118 +++++++++++++-----------
> include/video/da8xx-fb.h | 1 -
> 4 files changed, 141 insertions(+), 95 deletions(-)
>
> --
> 2.21.0
>
Hi Sekhar,
the fbdev patches have been acked by Bartlomiej. I think the entire
series can go through the ARM-SoC tree.
Bart
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [RESEND PATCH 00/10] ARM: davinci: use the new clocksource driver
From: Bartosz Golaszewski @ 2019-08-05 8:29 UTC (permalink / raw)
To: Sekhar Nori, Kevin Hilman
Cc: Bartosz Golaszewski, Linux Kernel Mailing List, Linux ARM
In-Reply-To: <20190722131748.30319-1-brgl@bgdev.pl>
pon., 22 lip 2019 o 15:17 Bartosz Golaszewski <brgl@bgdev.pl> napisał(a):
>
> From: Bartosz Golaszewski <bgolaszewski@baylibre.com>
>
> Sekhar,
>
> the following patches switch DaVinci to using the new clocksource driver which
> is now upstream. They are rebased on top of v5.3-rc1. Additionally the
> following two patches were reverted locally due to a regression in v5.3-rc1
> about which the relevant maintainers have been already notified:
>
> 2eef1399a866 modules: fix BUG when load module with rodata=n
> 93651f80dcb6 modules: fix compile error if don't have strict module rwx
>
> Bartosz Golaszewski (10):
> ARM: davinci: enable the clocksource driver for DT mode
> ARM: davinci: WARN_ON() if clk_get() fails
> ARM: davinci: da850: switch to using the clocksource driver
> ARM: davinci: da830: switch to using the clocksource driver
> ARM: davinci: move timer definitions to davinci.h
> ARM: davinci: dm355: switch to using the clocksource driver
> ARM: davinci: dm365: switch to using the clocksource driver
> ARM: davinci: dm644x: switch to using the clocksource driver
> ARM: davinci: dm646x: switch to using the clocksource driver
> ARM: davinci: remove legacy timer support
>
> arch/arm/Kconfig | 1 +
> arch/arm/mach-davinci/Makefile | 3 +-
> arch/arm/mach-davinci/da830.c | 45 +--
> arch/arm/mach-davinci/da850.c | 50 +--
> arch/arm/mach-davinci/davinci.h | 3 +
> arch/arm/mach-davinci/devices-da8xx.c | 1 -
> arch/arm/mach-davinci/devices.c | 19 -
> arch/arm/mach-davinci/dm355.c | 28 +-
> arch/arm/mach-davinci/dm365.c | 26 +-
> arch/arm/mach-davinci/dm644x.c | 28 +-
> arch/arm/mach-davinci/dm646x.c | 28 +-
> arch/arm/mach-davinci/include/mach/common.h | 17 -
> arch/arm/mach-davinci/include/mach/time.h | 35 --
> arch/arm/mach-davinci/time.c | 414 --------------------
> 14 files changed, 110 insertions(+), 588 deletions(-)
> delete mode 100644 arch/arm/mach-davinci/include/mach/time.h
> delete mode 100644 arch/arm/mach-davinci/time.c
>
> --
> 2.21.0
>
Hi Sekhar,
a gentle ping. Is this series good to go in for v5.4?
Bart
_______________________________________________
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 05/14] gpio: lpc32xx: allow building on non-lpc32xx targets
From: Bartosz Golaszewski @ 2019-08-05 8:27 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Andrew Lunn, LINUXWATCHDOG, LKML, Jason Cooper, David S. Miller,
Greg Kroah-Hartman, Gregory Clement, USB list, Russell King,
Vladimir Zapolskiy, linux-gpio, soc, netdev, Alan Stern,
Guenter Roeck, linux-serial, Sylvain Lemieux, Lee Jones,
Linus Walleij, arm-soc, Sebastian Hesselbarth
In-Reply-To: <CAK8P3a3KpKvRKXY72toE_5eAp4ER_Mre0GX3guwGeQgsY2HX+g@mail.gmail.com>
pt., 2 sie 2019 o 13:20 Arnd Bergmann <arnd@arndb.de> napisał(a):
>
> On Fri, Aug 2, 2019 at 9:10 AM Bartosz Golaszewski
> <bgolaszewski@baylibre.com> wrote:
> > > -#include <mach/hardware.h>
> > > -#include <mach/platform.h>
> > > +#define _GPREG(x) (x)
> >
> > What purpose does this macro serve?
> >
> > >
> > > #define LPC32XX_GPIO_P3_INP_STATE _GPREG(0x000)
> > > #define LPC32XX_GPIO_P3_OUTP_SET _GPREG(0x004)
>
> In the existing code base, this macro converts a register offset to
> an __iomem pointer for a gpio register. I changed the definition of the
> macro here to keep the number of changes down, but I it's just
> as easy to remove it if you prefer.
Could you just add a comment so that it's clear at first glance?
>
> > > @@ -167,14 +166,26 @@ struct lpc32xx_gpio_chip {
> > > struct gpio_regs *gpio_grp;
> > > };
> > >
> > > +void __iomem *gpio_reg_base;
> >
> > Any reason why this can't be made part of struct lpc32xx_gpio_chip?
>
> It could be, but it's the same for each instance, and not known until
> probe() time, so the same pointer would need to be copied into each
> instance that is otherwise read-only.
>
> Let me know if you'd prefer me to rework these two things or leave
> them as they are.
I would prefer not to have global state in the driver, let's just
store the pointer in the data passed to gpiochip_add_data().
Bart
>
> > > +static inline u32 gpreg_read(unsigned long offset)
> >
> > Here and elsewhere: could you please keep the lpc32xx_gpio prefix for
> > all symbols?
>
> Sure.
>
> Arnd
_______________________________________________
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] MIPS: remove support for DMA_ATTR_WRITE_COMBINE
From: Sergei Shtylyov @ 2019-08-05 8:06 UTC (permalink / raw)
To: Christoph Hellwig, iommu
Cc: Shawn Anastasio, Will Deacon, Michael Ellerman, linuxppc-dev,
linux-kernel, Russell King, linux-mips, Paul Burton,
Catalin Marinas, James Hogan, Robin Murphy, linux-arm-kernel
In-Reply-To: <20190805080145.5694-3-hch@lst.de>
Hello!
On 05.08.2019 11:01, Christoph Hellwig wrote:
> Mips uses the KSEG1 kernel memory segment do map dma coherent
MIPS. s/do/to/?
> allocations for n
on-coherent devices as uncachable, and does not have
Uncacheable?
> any kind of special support for DMA_ATTR_WRITE_COMBINE in the allocation
> path. Thus supporting DMA_ATTR_WRITE_COMBINE in dma_mmap_attrs will
> lead to multiple mappings with different caching attributes.
>
> Fixes: 8c172467be36 ("MIPS: Add implementation of dma_map_ops.mmap()")
> Signed-off-by: Christoph Hellwig <hch@lst.de>
[...]
MBR, Sergei
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH 2/2] MIPS: remove support for DMA_ATTR_WRITE_COMBINE
From: Christoph Hellwig @ 2019-08-05 8:01 UTC (permalink / raw)
To: iommu
Cc: Shawn Anastasio, Will Deacon, Michael Ellerman, linuxppc-dev,
linux-kernel, Russell King, linux-mips, Paul Burton,
Catalin Marinas, James Hogan, Robin Murphy, linux-arm-kernel
In-Reply-To: <20190805080145.5694-1-hch@lst.de>
Mips uses the KSEG1 kernel memory segment do map dma coherent
allocations for non-coherent devices as uncachable, and does not have
any kind of special support for DMA_ATTR_WRITE_COMBINE in the allocation
path. Thus supporting DMA_ATTR_WRITE_COMBINE in dma_mmap_attrs will
lead to multiple mappings with different caching attributes.
Fixes: 8c172467be36 ("MIPS: Add implementation of dma_map_ops.mmap()")
Signed-off-by: Christoph Hellwig <hch@lst.de>
---
arch/mips/Kconfig | 1 -
arch/mips/mm/dma-noncoherent.c | 8 --------
2 files changed, 9 deletions(-)
diff --git a/arch/mips/Kconfig b/arch/mips/Kconfig
index d50fafd7bf3a..86e6760ef0d0 100644
--- a/arch/mips/Kconfig
+++ b/arch/mips/Kconfig
@@ -1119,7 +1119,6 @@ config DMA_PERDEV_COHERENT
config DMA_NONCOHERENT
bool
- select ARCH_HAS_DMA_MMAP_PGPROT
select ARCH_HAS_SYNC_DMA_FOR_DEVICE
select ARCH_HAS_UNCACHED_SEGMENT
select NEED_DMA_MAP_STATE
diff --git a/arch/mips/mm/dma-noncoherent.c b/arch/mips/mm/dma-noncoherent.c
index ed56c6fa7be2..1d4d57dd9acf 100644
--- a/arch/mips/mm/dma-noncoherent.c
+++ b/arch/mips/mm/dma-noncoherent.c
@@ -65,14 +65,6 @@ long arch_dma_coherent_to_pfn(struct device *dev, void *cpu_addr,
return page_to_pfn(virt_to_page(cached_kernel_address(cpu_addr)));
}
-pgprot_t arch_dma_mmap_pgprot(struct device *dev, pgprot_t prot,
- unsigned long attrs)
-{
- if (attrs & DMA_ATTR_WRITE_COMBINE)
- return pgprot_writecombine(prot);
- return pgprot_noncached(prot);
-}
-
static inline void dma_sync_virt(void *addr, size_t size,
enum dma_data_direction dir)
{
--
2.20.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH 1/2] dma-mapping: fix page attributes for dma_mmap_*
From: Christoph Hellwig @ 2019-08-05 8:01 UTC (permalink / raw)
To: iommu
Cc: Gavin Li, Shawn Anastasio, Will Deacon, Michael Ellerman,
linuxppc-dev, linux-kernel, Russell King, linux-mips, Paul Burton,
Catalin Marinas, James Hogan, Robin Murphy, linux-arm-kernel
In-Reply-To: <20190805080145.5694-1-hch@lst.de>
All the way back to introducing dma_common_mmap we've defaulyed to mark
the pages as uncached. But this is wrong for DMA coherent devices.
Later on DMA_ATTR_WRITE_COMBINE also got incorrect treatment as that
flag is only treated special on the alloc side for non-coherent devices.
Introduce a new dma_pgprot helper that deals with the check for coherent
devices so that only the remapping cases even reach arch_dma_mmap_pgprot
and we thus ensure no aliasing of page attributes happens, which makes
the powerpc version of arch_dma_mmap_pgprot obsolete and simplifies the
remaining ones.
Note that this means arch_dma_mmap_pgprot is a bit misnamed now, but
we'll phase it out soon.
Fixes: 64ccc9c033c6 ("common: dma-mapping: add support for generic dma_mmap_* calls")
Reported-by: Shawn Anastasio <shawn@anastas.io>
Reported-by: Gavin Li <git@thegavinli.com>
Signed-off-by: Christoph Hellwig <hch@lst.de>
---
arch/arm/mm/dma-mapping.c | 4 +---
arch/arm64/mm/dma-mapping.c | 4 +---
arch/powerpc/Kconfig | 1 -
arch/powerpc/kernel/dma-common.c | 17 -----------------
drivers/iommu/dma-iommu.c | 6 +++---
include/linux/dma-mapping.h | 1 +
include/linux/dma-noncoherent.h | 5 -----
kernel/dma/mapping.c | 17 ++++++++++++++++-
kernel/dma/remap.c | 2 +-
9 files changed, 23 insertions(+), 34 deletions(-)
delete mode 100644 arch/powerpc/kernel/dma-common.c
diff --git a/arch/arm/mm/dma-mapping.c b/arch/arm/mm/dma-mapping.c
index 6774b03aa405..d42557ee69c2 100644
--- a/arch/arm/mm/dma-mapping.c
+++ b/arch/arm/mm/dma-mapping.c
@@ -2405,9 +2405,7 @@ long arch_dma_coherent_to_pfn(struct device *dev, void *cpu_addr,
pgprot_t arch_dma_mmap_pgprot(struct device *dev, pgprot_t prot,
unsigned long attrs)
{
- if (!dev_is_dma_coherent(dev))
- return __get_dma_pgprot(attrs, prot);
- return prot;
+ return __get_dma_pgprot(attrs, prot);
}
void *arch_dma_alloc(struct device *dev, size_t size, dma_addr_t *dma_handle,
diff --git a/arch/arm64/mm/dma-mapping.c b/arch/arm64/mm/dma-mapping.c
index 1d3f0b5a9940..bd2b039f43a6 100644
--- a/arch/arm64/mm/dma-mapping.c
+++ b/arch/arm64/mm/dma-mapping.c
@@ -14,9 +14,7 @@
pgprot_t arch_dma_mmap_pgprot(struct device *dev, pgprot_t prot,
unsigned long attrs)
{
- if (!dev_is_dma_coherent(dev) || (attrs & DMA_ATTR_WRITE_COMBINE))
- return pgprot_writecombine(prot);
- return prot;
+ return pgprot_writecombine(prot);
}
void arch_sync_dma_for_device(struct device *dev, phys_addr_t paddr,
diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index 77f6ebf97113..d8dcd8820369 100644
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@ -121,7 +121,6 @@ config PPC
select ARCH_32BIT_OFF_T if PPC32
select ARCH_HAS_DEBUG_VIRTUAL
select ARCH_HAS_DEVMEM_IS_ALLOWED
- select ARCH_HAS_DMA_MMAP_PGPROT
select ARCH_HAS_ELF_RANDOMIZE
select ARCH_HAS_FORTIFY_SOURCE
select ARCH_HAS_GCOV_PROFILE_ALL
diff --git a/arch/powerpc/kernel/dma-common.c b/arch/powerpc/kernel/dma-common.c
deleted file mode 100644
index dc7ef6b17b69..000000000000
--- a/arch/powerpc/kernel/dma-common.c
+++ /dev/null
@@ -1,17 +0,0 @@
-// SPDX-License-Identifier: GPL-2.0-or-later
-/*
- * Contains common dma routines for all powerpc platforms.
- *
- * Copyright (C) 2019 Shawn Anastasio.
- */
-
-#include <linux/mm.h>
-#include <linux/dma-noncoherent.h>
-
-pgprot_t arch_dma_mmap_pgprot(struct device *dev, pgprot_t prot,
- unsigned long attrs)
-{
- if (!dev_is_dma_coherent(dev))
- return pgprot_noncached(prot);
- return prot;
-}
diff --git a/drivers/iommu/dma-iommu.c b/drivers/iommu/dma-iommu.c
index a7f9c3edbcb2..0015fe610b23 100644
--- a/drivers/iommu/dma-iommu.c
+++ b/drivers/iommu/dma-iommu.c
@@ -574,7 +574,7 @@ static void *iommu_dma_alloc_remap(struct device *dev, size_t size,
struct iova_domain *iovad = &cookie->iovad;
bool coherent = dev_is_dma_coherent(dev);
int ioprot = dma_info_to_prot(DMA_BIDIRECTIONAL, coherent, attrs);
- pgprot_t prot = arch_dma_mmap_pgprot(dev, PAGE_KERNEL, attrs);
+ pgprot_t prot = dma_pgprot(dev, PAGE_KERNEL, attrs);
unsigned int count, min_size, alloc_sizes = domain->pgsize_bitmap;
struct page **pages;
struct sg_table sgt;
@@ -975,7 +975,7 @@ static void *iommu_dma_alloc_pages(struct device *dev, size_t size,
return NULL;
if (IS_ENABLED(CONFIG_DMA_REMAP) && (!coherent || PageHighMem(page))) {
- pgprot_t prot = arch_dma_mmap_pgprot(dev, PAGE_KERNEL, attrs);
+ pgprot_t prot = dma_pgprot(dev, PAGE_KERNEL, attrs);
cpu_addr = dma_common_contiguous_remap(page, alloc_size,
VM_USERMAP, prot, __builtin_return_address(0));
@@ -1035,7 +1035,7 @@ static int iommu_dma_mmap(struct device *dev, struct vm_area_struct *vma,
unsigned long pfn, off = vma->vm_pgoff;
int ret;
- vma->vm_page_prot = arch_dma_mmap_pgprot(dev, vma->vm_page_prot, attrs);
+ vma->vm_page_prot = dma_pgprot(dev, vma->vm_page_prot, attrs);
if (dma_mmap_from_dev_coherent(dev, vma, cpu_addr, size, &ret))
return ret;
diff --git a/include/linux/dma-mapping.h b/include/linux/dma-mapping.h
index f7d1eea32c78..3dda399ec9ce 100644
--- a/include/linux/dma-mapping.h
+++ b/include/linux/dma-mapping.h
@@ -611,6 +611,7 @@ static inline void dma_sync_single_range_for_device(struct device *dev,
#define dma_get_sgtable(d, t, v, h, s) dma_get_sgtable_attrs(d, t, v, h, s, 0)
#define dma_mmap_coherent(d, v, c, h, s) dma_mmap_attrs(d, v, c, h, s, 0)
+pgprot_t dma_pgprot(struct device *dev, pgprot_t prot, unsigned long attrs);
extern int dma_common_mmap(struct device *dev, struct vm_area_struct *vma,
void *cpu_addr, dma_addr_t dma_addr, size_t size,
unsigned long attrs);
diff --git a/include/linux/dma-noncoherent.h b/include/linux/dma-noncoherent.h
index 3813211a9aad..9ae5cee543c4 100644
--- a/include/linux/dma-noncoherent.h
+++ b/include/linux/dma-noncoherent.h
@@ -42,13 +42,8 @@ void arch_dma_free(struct device *dev, size_t size, void *cpu_addr,
dma_addr_t dma_addr, unsigned long attrs);
long arch_dma_coherent_to_pfn(struct device *dev, void *cpu_addr,
dma_addr_t dma_addr);
-
-#ifdef CONFIG_ARCH_HAS_DMA_MMAP_PGPROT
pgprot_t arch_dma_mmap_pgprot(struct device *dev, pgprot_t prot,
unsigned long attrs);
-#else
-# define arch_dma_mmap_pgprot(dev, prot, attrs) pgprot_noncached(prot)
-#endif
#ifdef CONFIG_DMA_NONCOHERENT_CACHE_SYNC
void arch_dma_cache_sync(struct device *dev, void *vaddr, size_t size,
diff --git a/kernel/dma/mapping.c b/kernel/dma/mapping.c
index b945239621d8..51d9657e0a8f 100644
--- a/kernel/dma/mapping.c
+++ b/kernel/dma/mapping.c
@@ -150,6 +150,21 @@ int dma_get_sgtable_attrs(struct device *dev, struct sg_table *sgt,
}
EXPORT_SYMBOL(dma_get_sgtable_attrs);
+/*
+ * Return the page attributes used for mapping dma_alloc_* memory, either in
+ * kernel space if remapping is needed, or to userspace through dma_mmap_*.
+ */
+pgprot_t dma_pgprot(struct device *dev, pgprot_t prot, unsigned long attrs)
+{
+ if (dev_is_dma_coherent(dev) ||
+ (IS_ENABLED(CONFIG_DMA_NONCOHERENT_CACHE_SYNC) &&
+ (attrs & DMA_ATTR_NON_CONSISTENT)))
+ return prot;
+ if (IS_ENABLED(CONFIG_ARCH_HAS_DMA_MMAP_PGPROT))
+ return arch_dma_mmap_pgprot(dev, prot, attrs);
+ return pgprot_noncached(prot);
+}
+
/*
* Create userspace mapping for the DMA-coherent memory.
*/
@@ -164,7 +179,7 @@ int dma_common_mmap(struct device *dev, struct vm_area_struct *vma,
unsigned long pfn;
int ret = -ENXIO;
- vma->vm_page_prot = arch_dma_mmap_pgprot(dev, vma->vm_page_prot, attrs);
+ vma->vm_page_prot = dma_pgprot(dev, vma->vm_page_prot, attrs);
if (dma_mmap_from_dev_coherent(dev, vma, cpu_addr, size, &ret))
return ret;
diff --git a/kernel/dma/remap.c b/kernel/dma/remap.c
index a594aec07882..ffe78f0b2fe4 100644
--- a/kernel/dma/remap.c
+++ b/kernel/dma/remap.c
@@ -218,7 +218,7 @@ void *arch_dma_alloc(struct device *dev, size_t size, dma_addr_t *dma_handle,
/* create a coherent mapping */
ret = dma_common_contiguous_remap(page, size, VM_USERMAP,
- arch_dma_mmap_pgprot(dev, PAGE_KERNEL, attrs),
+ dma_pgprot(dev, PAGE_KERNEL, attrs),
__builtin_return_address(0));
if (!ret) {
__dma_direct_free_pages(dev, size, page);
--
2.20.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* fix default dma_mmap_* pgprot v2
From: Christoph Hellwig @ 2019-08-05 8:01 UTC (permalink / raw)
To: iommu
Cc: Shawn Anastasio, Will Deacon, Michael Ellerman, linuxppc-dev,
linux-kernel, Russell King, linux-mips, Paul Burton,
Catalin Marinas, James Hogan, Robin Murphy, linux-arm-kernel
Hi all,
As Shawn pointed out we've had issues with the dma mmap pgprots ever
since the dma_common_mmap helper was added beyong the initial
architectures - we default to uncached mappings, but for devices that
are DMA coherent, or if the DMA_ATTR_NON_CONSISTENT is set (and
supported) this can lead to aliasing of cache attributes. This patch
fixes that. My explanation of why this hasn't been much of an issue
is that the dma_mmap_ helpers aren't used widely and mostly just in
architecture specific drivers.
Changes since v1:
- fix handling of DMA_ATTR_NON_CONSISTENT where it is a no-op
(which is most architectures)
- remove DMA_ATTR_WRITE_COMBINE on mips, as it seem dangerous as-is
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH] power: reset: make reboot-mode user selectable
From: Arnd Bergmann @ 2019-08-05 7:57 UTC (permalink / raw)
To: Sebastian Reichel
Cc: Arnd Bergmann, linux-pm, linux-kernel, Bartosz Golaszewski,
linux-arm-kernel, Nandor Han
Nandor Han points out that there might be drivers that can use
the reboot-mode interfaces but might also be usable on configurations
without device tree.
Move the 'depends on OF' dependency into CONFIG_REBOOT_MODE since
that is the only thing that truely has a compile-time dependency
on CONFIG_OF, and make it user visible to make it possible to
disable it.
The drivers that used to 'select REBOOT_MODE' of course now have to
use 'depends on REBOOT_MODE instead'. With this, we can soften the
dependency and allow compile-testing the three front-end drivers
on non-OF platforms.
Note: anyone who was using a reboot mode driver in their kernel
configuration now has to enable CONFIG_REBOOT_MODE as well.
Suggested-by: Nandor Han <nandor.han@vaisala.com>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
Nandor, this is so far untested, could you make sure this
works in all configurations and forward it along with the
bugfix?
Sebastian, I'm not convinced this is a good idea, just sending
it as Nandor requested. Please decide for yourself.
---
arch/arm/configs/davinci_all_defconfig | 1 +
arch/arm64/configs/defconfig | 1 +
drivers/power/reset/Kconfig | 22 +++++++++++++---------
include/linux/reboot-mode.h | 20 ++++++++++++++++++++
4 files changed, 35 insertions(+), 9 deletions(-)
diff --git a/arch/arm/configs/davinci_all_defconfig b/arch/arm/configs/davinci_all_defconfig
index b34970ce6b31..ebf506c01899 100644
--- a/arch/arm/configs/davinci_all_defconfig
+++ b/arch/arm/configs/davinci_all_defconfig
@@ -139,6 +139,7 @@ CONFIG_GPIO_PCA953X_IRQ=y
CONFIG_RESET_CONTROLLER=y
CONFIG_POWER_RESET=y
CONFIG_POWER_RESET_GPIO=y
+CONFIG_REBOOT_MODE=m
CONFIG_SYSCON_REBOOT_MODE=m
CONFIG_BATTERY_LEGO_EV3=m
CONFIG_WATCHDOG=y
diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig
index 0e58ef02880c..bb7d7bec1413 100644
--- a/arch/arm64/configs/defconfig
+++ b/arch/arm64/configs/defconfig
@@ -419,6 +419,7 @@ CONFIG_ROCKCHIP_IODOMAIN=y
CONFIG_POWER_RESET_MSM=y
CONFIG_POWER_RESET_XGENE=y
CONFIG_POWER_RESET_SYSCON=y
+CONFIG_REBOOT_MODE=y
CONFIG_SYSCON_REBOOT_MODE=y
CONFIG_BATTERY_SBS=m
CONFIG_BATTERY_BQ27XXX=y
diff --git a/drivers/power/reset/Kconfig b/drivers/power/reset/Kconfig
index a564237278ff..997323d443f5 100644
--- a/drivers/power/reset/Kconfig
+++ b/drivers/power/reset/Kconfig
@@ -9,6 +9,13 @@ menuconfig POWER_RESET
if POWER_RESET
+config REBOOT_MODE
+ tristate "Pass reboot-mode to firmware"
+ depends on OF
+ help
+ Some drivers allow setting the reboot mode through a platform
+ interface that the boot firmware can read.
+
config POWER_RESET_AS3722
bool "ams AS3722 power-off driver"
depends on MFD_AS3722
@@ -107,9 +114,9 @@ config POWER_RESET_MSM
config POWER_RESET_QCOM_PON
tristate "Qualcomm power-on driver"
- depends on ARCH_QCOM
+ depends on ARCH_QCOM || COMPILE_TEST
depends on MFD_SPMI_PMIC
- select REBOOT_MODE
+ depends on REBOOT_MODE || !REBOOT_MODE
help
Power On support for Qualcomm boards.
If you have a Qualcomm platform and need support for
@@ -223,14 +230,11 @@ config POWER_RESET_ZX
help
Reboot support for ZTE SoCs.
-config REBOOT_MODE
- tristate
-
config SYSCON_REBOOT_MODE
tristate "Generic SYSCON regmap reboot mode driver"
- depends on OF
+ depends on OF || COMPILE_TEST
depends on MFD_SYSCON
- select REBOOT_MODE
+ depends on REBOOT_MODE || !REBOOT_MODE
help
Say y here will enable reboot mode driver. This will
get reboot mode arguments and store it in SYSCON mapped
@@ -248,8 +252,8 @@ config POWER_RESET_SC27XX
config NVMEM_REBOOT_MODE
tristate "Generic NVMEM reboot mode driver"
- depends on OF
- select REBOOT_MODE
+ depends on OF || COMPILE_TEST
+ depends on REBOOT_MODE || !REBOOT_MODE
help
Say y here will enable reboot mode driver. This will
get reboot mode arguments and store it in a NVMEM cell,
diff --git a/include/linux/reboot-mode.h b/include/linux/reboot-mode.h
index 4a2abb38d1d6..bd002060e3d0 100644
--- a/include/linux/reboot-mode.h
+++ b/include/linux/reboot-mode.h
@@ -9,11 +9,31 @@ struct reboot_mode_driver {
struct notifier_block reboot_notifier;
};
+#if IS_ENABLED(CONFIG_REBOOT_MODE)
int reboot_mode_register(struct reboot_mode_driver *reboot);
int reboot_mode_unregister(struct reboot_mode_driver *reboot);
int devm_reboot_mode_register(struct device *dev,
struct reboot_mode_driver *reboot);
void devm_reboot_mode_unregister(struct device *dev,
struct reboot_mode_driver *reboot);
+#else
+static inline int reboot_mode_register(struct reboot_mode_driver *reboot)
+{
+ return 0;
+}
+static inline int reboot_mode_unregister(struct reboot_mode_driver *reboot)
+{
+ return 0;
+}
+static inline int devm_reboot_mode_register(struct device *dev,
+ struct reboot_mode_driver *reboot)
+{
+ return 0;
+}
+static inline void devm_reboot_mode_unregister(struct device *dev,
+ struct reboot_mode_driver *reboot)
+{
+}
+#endif
#endif
--
2.20.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH] arm: initialize the dma-remap atomic pool for LPAE configs
From: Christoph Hellwig @ 2019-08-05 7:56 UTC (permalink / raw)
To: Russell King - ARM Linux admin
Cc: Vignesh Raghavendra, Konrad Rzeszutek Wilk, linux-kernel, iommu,
linux-arm-kernel, Roger Quadros
In-Reply-To: <20190805075637.5373-1-hch@lst.de>
When we use the generic dma-direct + remap code we also need to
initialize the atomic pool that is used for GFP_ATOMIC allocations on
non-coherent devices.
Fixes: ad3c7b18c5b3 ("arm: use swiotlb for bounce buffering on LPAE configs")
Signed-off-by: Christoph Hellwig <hch@lst.de>
---
arch/arm/mm/dma-mapping.c | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/arch/arm/mm/dma-mapping.c b/arch/arm/mm/dma-mapping.c
index 6774b03aa405..e509365cc9ca 100644
--- a/arch/arm/mm/dma-mapping.c
+++ b/arch/arm/mm/dma-mapping.c
@@ -2423,4 +2423,10 @@ void arch_dma_free(struct device *dev, size_t size, void *cpu_addr,
{
__arm_dma_free(dev, size, cpu_addr, dma_handle, attrs, false);
}
+
+static int __init atomic_pool_init(void)
+{
+ return dma_atomic_pool_init(GFP_DMA, pgprot_noncached(PAGE_KERNEL));
+}
+postcore_initcall(atomic_pool_init);
#endif /* CONFIG_SWIOTLB */
--
2.20.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* arm swiotlb fix
From: Christoph Hellwig @ 2019-08-05 7:56 UTC (permalink / raw)
To: Russell King - ARM Linux admin
Cc: Vignesh Raghavendra, Konrad Rzeszutek Wilk, linux-kernel, iommu,
linux-arm-kernel, Roger Quadros
Hi all,
my commit to add swiotlb to arm failed to initialize the atomic pool,
which is needed for GFP_ATOMIC allocations on non-coherent devices.
These are fairly rare, but exist so we should wire it up. For 5.4
I plan to move the initilization to the common dma-remap code so it
won't be missed for other architectures.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [Linux-stm32] [PATCH V3 1/3] mmc: mmci: fix read status for busy detect
From: Ludovic BARRE @ 2019-08-05 7:33 UTC (permalink / raw)
To: Ulf Hansson
Cc: DTML, linux-mmc@vger.kernel.org, Linux Kernel Mailing List,
Rob Herring, Srinivas Kandagatla, Maxime Coquelin, linux-stm32,
Linux ARM
In-Reply-To: <dd5c1e86-f0b1-cdfa-1b91-486f99d4e50c@st.com>
hi Ulf
On 7/26/19 11:41 AM, Ludovic BARRE wrote:
> hi Ulf
>
> Thanks to your "Clarify comments ..." commit, like is closes
> I resumed upstream of this series.
>
> On 7/15/19 6:31 PM, Ulf Hansson wrote:
>> On Mon, 3 Jun 2019 at 17:55, Ludovic Barre <ludovic.Barre@st.com> wrote:
>>>
>>> From: Ludovic Barre <ludovic.barre@st.com>
>>>
>>> "busy_detect_flag" is used to read & clear busy value of mmci status.
>>> "busy_detect_mask" is used to manage busy irq of mmci mask.
>>> So to read mmci status the busy_detect_flag must be take account.
>>> if the variant does not support busy detect feature the flag is null
>>> and there is no impact.
>>
>> By reading the changelog, it doesn't tell me the purpose of this
>> change. When going forward, please work harder on your changelogs.
>>
>> Make sure to answer the questions, *why* is this change needed,
>> *what/how* does the change do.
>
> Ok, I will explain the differences with the legacy and the needs of
> sdmmc variant about busy detection.
>
>>
>>>
>>> Not need to re-read the status register in mmci_cmd_irq, the
>>> status parameter can be used.
>>>
>>> Signed-off-by: Ludovic Barre <ludovic.barre@st.com>
>>> ---
>>> drivers/mmc/host/mmci.c | 5 +++--
>>> 1 file changed, 3 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/drivers/mmc/host/mmci.c b/drivers/mmc/host/mmci.c
>>> index 356833a..5b5cc45 100644
>>> --- a/drivers/mmc/host/mmci.c
>>> +++ b/drivers/mmc/host/mmci.c
>>> @@ -1240,7 +1240,7 @@ mmci_cmd_irq(struct mmci_host *host, struct
>>> mmc_command *cmd,
>>> */
>>> if (!host->busy_status &&
>>> !(status & (MCI_CMDCRCFAIL|MCI_CMDTIMEOUT)) &&
>>> - (readl(base + MMCISTATUS) &
>>> host->variant->busy_detect_flag)) {
>>> + (status & host->variant->busy_detect_flag)) {
>>
>> I suggested you to do this change through some of my earlier comments,
>> however I think it should be made as a stand alone change.
>>
>> Anyway, when looking at the details in your series, I decided to try
>> to help out a bit, so I have prepared a couple of related patches for
>> cleaning up and clarifying the busy detection code/comments in mmci. I
>> have incorporated the above change, so let me post them asap.
>>
>>>
>>> /* Clear the busy start IRQ */
>>> writel(host->variant->busy_detect_mask,
>>> @@ -1517,7 +1517,8 @@ static irqreturn_t mmci_irq(int irq, void *dev_id)
>>> * to make sure that both start and end interrupts
>>> are always
>>> * cleared one after the other.
>>> */
>>> - status &= readl(host->base + MMCIMASK0);
>>> + status &= readl(host->base + MMCIMASK0) |
>>> + host->variant->busy_detect_flag;
>>
>> As I told earlier in the review, this looks wrong to me.
>>
>> It means that you will add the bit for the ->busy_detect_flag to the
>> status field we have just read from the MMCISTATUS register. That
>> means the busy status may be set when it shouldn't.
>>
>>> if (host->variant->busy_detect)
>>> writel(status &
>>> ~host->variant->busy_detect_mask,
>>> host->base + MMCICLEAR);
>>> --
>>> 2.7.4
>>>
>>
>> By looking at the other changes in the series, I assume @subject patch
>> is intended to prepare for the other changes on top. But it's not
>> really clear.
>>
>> Anyway, in that regards, the below is my observations of what seems to
>> be important part, when supporting busy detection for the stm32 sdmmc
>> variant (except the timeout things in patch2, which I intend to
>> comment separately on).
>>
>> I figured, these are the involved register bits/masks:
>>
>> MMCISTATUS:
>> MCI_STM32_BUSYD0 BIT(20)
>> MCI_STM32_BUSYD0END BIT(21)
>>
>> MMCIMASK0:
>> MCI_STM32_BUSYD0ENDMASK BIT(21)
>
> it's exact:
> MCI_STM32_BUSYD0 BIT(20): This is a hardware status flag only (inverted
> value of d0 line), it does not generate an interrupt, and so no mask
> bit.
>
> MCI_STM32_BUSYD0ENDMASK BIT(21): This indicates only end of busy
> following a CMD response. On busy to Not busy changes, an interrupt
> is generated (if unmask) and BUSYD0END status flag is set.
> status flag is cleared by writing corresponding interrupt clear bit in
> MMCICLEAR.
>
>>
>> For the legacy ST variant, there is only one register bit in
>> MMCISTATUS that is used for indicating busy (MCI_ST_CARDBUSY BIT(24)).
>> There is no dedicated busy-end bit for the busy-end IRQ, which I
>> believe is the reason to why the current code also is bit messy.
>
> yes
>
>>
>> It seems like the stm32 sdmmc variant have a separate status bit for
>> the busy-end IRQ, correct?
>
> yes
>
>>
>> If I understand correctly by looking at patch3, you don't use the
>> dedicated busy-end status bit (MCI_STM32_BUSYD0END), right? Then why
>> not?
>
> like your are clarify in previous series, the busy detection is done
> in 3 steps.
>
> if I use:
> .busy_detect_flag = MCI_STM32_BUSYD0ENDMASK,
> .busy_detect_mask = MCI_STM32_BUSYD0ENDMASK,
>
> the sdmmc request will be not correctly completed, because the third
> step can't be happen.
>
> chronologies:
> step1: when busyd0end change to 1
> => busyd0end interrupt is unmasked
> => busy_status = cmd_sent | respend
> => return to mmci_irq
> step2: busyd0end is yet to 1
> => clear the busyd0end interrupt
> => the hardware clear busyd0end status flag on interrupt clear
> => return to mmci_irq
>
> like MCI_STM32_BUSYD0END interrupt is generated only on change
> busy to not busy, when the interrupt is cleared (status is 0)
> the step 3 can't happen (no irq pending to re-enter in mmci_cmd_irq).
> sdmmc can't complete the request.
>
> If I use:
> .busy_detect_flag = MCI_STM32_BUSYD0,
> .busy_detect_mask = MCI_STM32_BUSYD0ENDMASK,
>
> Like there is no MCI_STM32_BUSYD0 irq mask, the status read in mmci_irq
> "status &= readl(host->base + MMCIMASK0)" can't take account the
> busy_detect_flag (for sdmmc). So the step 2 can't be passed.
> However we could share re-read between step 1 and step 2.
>
> proposal:
>
> +
> + u32 busy_val = readl(base + MMCISTATUS) &
> + host->variant->busy_detect_flag;
> +
> if (!host->busy_status &&
> - !(status & (MCI_CMDCRCFAIL|MCI_CMDTIMEOUT)) &&
> - (readl(base + MMCISTATUS) &
> host->variant->busy_detect_flag)) {
> + !(status & (MCI_CMDCRCFAIL|MCI_CMDTIMEOUT)) && busy_val) {
>
> writel(readl(base + MMCIMASK0) |
> host->variant->busy_detect_mask,
> @@ -1262,8 +1265,7 @@ mmci_cmd_irq(struct mmci_host *host, struct
> mmc_command *cmd,
> * both the start and the end interrupts needs to be cleared,
> * one after the other. So, clear the busy start IRQ here.
> */
> - if (host->busy_status &&
> - (status & host->variant->busy_detect_flag)) {
> + if (host->busy_status && busy_val) {
>
>
> what do you think about it ?
>
I give up this proposal for a new version based on mmci_host_ops
callback to done the busy completion.
>>
>> Thoughts?
>>
>> Kind regards
>> Uffe
>>
>
> Regards
> Ludo
> _______________________________________________
> Linux-stm32 mailing list
> Linux-stm32@st-md-mailman.stormreply.com
> https://st-md-mailman.stormreply.com/mailman/listinfo/linux-stm32
_______________________________________________
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 v4 09/10] rtc: mt6397: fix alarm register overwrite
From: Alexandre Belloni @ 2019-08-05 7:24 UTC (permalink / raw)
To: Hsin-Hsiung Wang
Cc: Mark Rutland, Alessandro Zummo, srv_heupstream, devicetree,
Ran Bi, Sean Wang, Liam Girdwood, Rob Herring, linux-kernel,
Richard Fontana, Mark Brown, linux-mediatek, Allison Randal,
linux-rtc, Matthias Brugger, Thomas Gleixner, Eddie Huang,
Lee Jones, Kate Stewart, linux-arm-kernel
In-Reply-To: <1564982518-32163-10-git-send-email-hsin-hsiung.wang@mediatek.com>
On 05/08/2019 13:21:57+0800, Hsin-Hsiung Wang wrote:
> From: Ran Bi <ran.bi@mediatek.com>
>
> Alarm registers high byte was reserved for other functions.
> This add mask in alarm registers operation functions.
> This also fix error condition in interrupt handler.
>
> Fixes: fc2979118f3f ("rtc: mediatek: Add MT6397 RTC driver")
>
> Signed-off-by: Ran Bi <ran.bi@mediatek.com>
Acked-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
> ---
> drivers/rtc/rtc-mt6397.c | 47 +++++++++++++++++++++++++++++++++--------------
> 1 file changed, 33 insertions(+), 14 deletions(-)
>
> diff --git a/drivers/rtc/rtc-mt6397.c b/drivers/rtc/rtc-mt6397.c
> index b46ed4d..828def7 100644
> --- a/drivers/rtc/rtc-mt6397.c
> +++ b/drivers/rtc/rtc-mt6397.c
> @@ -47,6 +47,14 @@
>
> #define RTC_AL_SEC 0x0018
>
> +#define RTC_AL_SEC_MASK 0x003f
> +#define RTC_AL_MIN_MASK 0x003f
> +#define RTC_AL_HOU_MASK 0x001f
> +#define RTC_AL_DOM_MASK 0x001f
> +#define RTC_AL_DOW_MASK 0x0007
> +#define RTC_AL_MTH_MASK 0x000f
> +#define RTC_AL_YEA_MASK 0x007f
> +
> #define RTC_PDN2 0x002e
> #define RTC_PDN2_PWRON_ALARM BIT(4)
>
> @@ -103,7 +111,7 @@ static irqreturn_t mtk_rtc_irq_handler_thread(int irq, void *data)
> irqen = irqsta & ~RTC_IRQ_EN_AL;
> mutex_lock(&rtc->lock);
> if (regmap_write(rtc->regmap, rtc->addr_base + RTC_IRQ_EN,
> - irqen) < 0)
> + irqen) == 0)
> mtk_rtc_write_trigger(rtc);
> mutex_unlock(&rtc->lock);
>
> @@ -225,12 +233,12 @@ static int mtk_rtc_read_alarm(struct device *dev, struct rtc_wkalrm *alm)
> alm->pending = !!(pdn2 & RTC_PDN2_PWRON_ALARM);
> mutex_unlock(&rtc->lock);
>
> - tm->tm_sec = data[RTC_OFFSET_SEC];
> - tm->tm_min = data[RTC_OFFSET_MIN];
> - tm->tm_hour = data[RTC_OFFSET_HOUR];
> - tm->tm_mday = data[RTC_OFFSET_DOM];
> - tm->tm_mon = data[RTC_OFFSET_MTH];
> - tm->tm_year = data[RTC_OFFSET_YEAR];
> + tm->tm_sec = data[RTC_OFFSET_SEC] & RTC_AL_SEC_MASK;
> + tm->tm_min = data[RTC_OFFSET_MIN] & RTC_AL_MIN_MASK;
> + tm->tm_hour = data[RTC_OFFSET_HOUR] & RTC_AL_HOU_MASK;
> + tm->tm_mday = data[RTC_OFFSET_DOM] & RTC_AL_DOM_MASK;
> + tm->tm_mon = data[RTC_OFFSET_MTH] & RTC_AL_MTH_MASK;
> + tm->tm_year = data[RTC_OFFSET_YEAR] & RTC_AL_YEA_MASK;
>
> tm->tm_year += RTC_MIN_YEAR_OFFSET;
> tm->tm_mon--;
> @@ -251,14 +259,25 @@ static int mtk_rtc_set_alarm(struct device *dev, struct rtc_wkalrm *alm)
> tm->tm_year -= RTC_MIN_YEAR_OFFSET;
> tm->tm_mon++;
>
> - data[RTC_OFFSET_SEC] = tm->tm_sec;
> - data[RTC_OFFSET_MIN] = tm->tm_min;
> - data[RTC_OFFSET_HOUR] = tm->tm_hour;
> - data[RTC_OFFSET_DOM] = tm->tm_mday;
> - data[RTC_OFFSET_MTH] = tm->tm_mon;
> - data[RTC_OFFSET_YEAR] = tm->tm_year;
> -
> mutex_lock(&rtc->lock);
> + ret = regmap_bulk_read(rtc->regmap, rtc->addr_base + RTC_AL_SEC,
> + data, RTC_OFFSET_COUNT);
> + if (ret < 0)
> + goto exit;
> +
> + data[RTC_OFFSET_SEC] = ((data[RTC_OFFSET_SEC] & ~(RTC_AL_SEC_MASK)) |
> + (tm->tm_sec & RTC_AL_SEC_MASK));
> + data[RTC_OFFSET_MIN] = ((data[RTC_OFFSET_MIN] & ~(RTC_AL_MIN_MASK)) |
> + (tm->tm_min & RTC_AL_MIN_MASK));
> + data[RTC_OFFSET_HOUR] = ((data[RTC_OFFSET_HOUR] & ~(RTC_AL_HOU_MASK)) |
> + (tm->tm_hour & RTC_AL_HOU_MASK));
> + data[RTC_OFFSET_DOM] = ((data[RTC_OFFSET_DOM] & ~(RTC_AL_DOM_MASK)) |
> + (tm->tm_mday & RTC_AL_DOM_MASK));
> + data[RTC_OFFSET_MTH] = ((data[RTC_OFFSET_MTH] & ~(RTC_AL_MTH_MASK)) |
> + (tm->tm_mon & RTC_AL_MTH_MASK));
> + data[RTC_OFFSET_YEAR] = ((data[RTC_OFFSET_YEAR] & ~(RTC_AL_YEA_MASK)) |
> + (tm->tm_year & RTC_AL_YEA_MASK));
> +
> if (alm->enabled) {
> ret = regmap_bulk_write(rtc->regmap,
> rtc->addr_base + RTC_AL_SEC,
> --
> 2.6.4
>
--
Alexandre Belloni, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v4 10/10] rtc: Add support for the MediaTek MT6358 RTC
From: Alexandre Belloni @ 2019-08-05 7:23 UTC (permalink / raw)
To: Hsin-Hsiung Wang
Cc: Mark Rutland, Alessandro Zummo, srv_heupstream, devicetree,
Ran Bi, Sean Wang, Liam Girdwood, Rob Herring, linux-kernel,
Richard Fontana, Mark Brown, linux-mediatek, Allison Randal,
linux-rtc, Matthias Brugger, Thomas Gleixner, Eddie Huang,
Lee Jones, Kate Stewart, linux-arm-kernel
In-Reply-To: <1564982518-32163-11-git-send-email-hsin-hsiung.wang@mediatek.com>
Hi,
The subject should be:
"rtc: mt6397: Add support for the MediaTek MT6358 RTC"
On 05/08/2019 13:21:58+0800, Hsin-Hsiung Wang wrote:
> From: Ran Bi <ran.bi@mediatek.com>
>
> This add support for the MediaTek MT6358 RTC. Driver using
> compatible data to store different RTC_WRTGR address offset.
>
> Review-by: Yingjoe Chen <yingjoe.chen@mediatek.com>
> Signed-off-by: Ran Bi <ran.bi@mediatek.com>
> ---
> drivers/rtc/rtc-mt6397.c | 43 +++++++++++++++++++++++++++++++++++--------
> 1 file changed, 35 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/rtc/rtc-mt6397.c b/drivers/rtc/rtc-mt6397.c
> index 828def7..e23c215 100644
> --- a/drivers/rtc/rtc-mt6397.c
> +++ b/drivers/rtc/rtc-mt6397.c
> @@ -12,6 +12,7 @@
> #include <linux/irqdomain.h>
> #include <linux/platform_device.h>
> #include <linux/of_address.h>
> +#include <linux/of_device.h>
> #include <linux/of_irq.h>
> #include <linux/io.h>
> #include <linux/mfd/mt6397/core.h>
> @@ -19,7 +20,8 @@
> #define RTC_BBPU 0x0000
> #define RTC_BBPU_CBUSY BIT(6)
>
> -#define RTC_WRTGR 0x003c
> +#define RTC_WRTGR_MT6358 0x3a
> +#define RTC_WRTGR_MT6397 0x3c
>
> #define RTC_IRQ_STA 0x0002
> #define RTC_IRQ_STA_AL BIT(0)
> @@ -63,6 +65,10 @@
> #define RTC_NUM_YEARS 128
> #define RTC_MIN_YEAR_OFFSET (RTC_MIN_YEAR - RTC_BASE_YEAR)
>
> +struct mtk_rtc_compatible {
I would name that struct mtk_rtc_data
> + u32 wrtgr_addr;
and this member should be wrtgr_offset or simply wrtgr.
> +};
> +
> struct mt6397_rtc {
> struct device *dev;
> struct rtc_device *rtc_dev;
> @@ -70,7 +76,25 @@ struct mt6397_rtc {
> struct regmap *regmap;
> int irq;
> u32 addr_base;
> + const struct mtk_rtc_compatible *dev_comp;
> +};
> +
> +static const struct mtk_rtc_compatible mt6358_rtc_compat = {
> + .wrtgr_addr = RTC_WRTGR_MT6358,
> +};
> +
> +static const struct mtk_rtc_compatible mt6397_rtc_compat = {
> + .wrtgr_addr = RTC_WRTGR_MT6397,
> +};
> +
> +static const struct of_device_id mt6397_rtc_of_match[] = {
> + { .compatible = "mediatek,mt6358-rtc",
> + .data = (void *)&mt6358_rtc_compat, },
> + { .compatible = "mediatek,mt6397-rtc",
> + .data = (void *)&mt6397_rtc_compat, },
> + {}
> };
> +MODULE_DEVICE_TABLE(of, mt6397_rtc_of_match);
>
> static int mtk_rtc_write_trigger(struct mt6397_rtc *rtc)
> {
> @@ -78,7 +102,8 @@ static int mtk_rtc_write_trigger(struct mt6397_rtc *rtc)
> int ret;
> u32 data;
>
> - ret = regmap_write(rtc->regmap, rtc->addr_base + RTC_WRTGR, 1);
> + ret = regmap_write(rtc->regmap,
> + rtc->addr_base + rtc->dev_comp->wrtgr_addr, 1);
> if (ret < 0)
> return ret;
>
> @@ -324,6 +349,7 @@ static int mtk_rtc_probe(struct platform_device *pdev)
> struct resource *res;
> struct mt6397_chip *mt6397_chip = dev_get_drvdata(pdev->dev.parent);
> struct mt6397_rtc *rtc;
> + const struct of_device_id *of_id;
> int ret;
>
> rtc = devm_kzalloc(&pdev->dev, sizeof(struct mt6397_rtc), GFP_KERNEL);
> @@ -333,6 +359,13 @@ static int mtk_rtc_probe(struct platform_device *pdev)
> res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> rtc->addr_base = res->start;
>
> + of_id = of_match_device(mt6397_rtc_of_match, &pdev->dev);
> + if (!of_id) {
> + dev_err(&pdev->dev, "Failed to probe of_node\n");
> + return -EINVAL;
This will never happen because probe would not be called if there is no
match. You could also use of_device_get_match_data to avoid having to
move the of_device_id table.
> + }
> + rtc->dev_comp = of_id->data;
> +
> rtc->irq = platform_get_irq(pdev, 0);
> if (rtc->irq < 0)
> return rtc->irq;
> @@ -408,12 +441,6 @@ static int mt6397_rtc_resume(struct device *dev)
> static SIMPLE_DEV_PM_OPS(mt6397_pm_ops, mt6397_rtc_suspend,
> mt6397_rtc_resume);
>
> -static const struct of_device_id mt6397_rtc_of_match[] = {
> - { .compatible = "mediatek,mt6397-rtc", },
> - { }
> -};
> -MODULE_DEVICE_TABLE(of, mt6397_rtc_of_match);
> -
> static struct platform_driver mtk_rtc_driver = {
> .driver = {
> .name = "mt6397-rtc",
> --
> 2.6.4
>
--
Alexandre Belloni, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
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