* Re: [linux-sunxi] [PATCH 2/3] rtc: sun6i: Add support for H6 RTC
From: Chen-Yu Tsai @ 2019-08-05 10:54 UTC (permalink / raw)
To: Ondřej Jirman, Chen-Yu Tsai, Alessandro Zummo,
Alexandre Belloni, Rob Herring, Mark Rutland, Maxime Ripard,
linux-rtc, devicetree, linux-arm-kernel, linux-kernel,
linux-sunxi
In-Reply-To: <20190805104529.z3mex3m2tss7lzlr@core.my.home>
On Mon, Aug 5, 2019 at 6:45 PM Ondřej Jirman <megous@megous.com> wrote:
>
> On Mon, Aug 05, 2019 at 06:16:14PM +0800, Chen-Yu Tsai wrote:
> > On Fri, Apr 12, 2019 at 8:07 PM megous via linux-sunxi
> > <linux-sunxi@googlegroups.com> wrote:
> > >
> > > From: Ondrej Jirman <megous@megous.com>
> > >
> > > RTC on H6 is mostly the same as on H5 and H3. It has slight differences
> > > mostly in features that are not yet supported by this driver.
> > >
> > > Some differences are already stated in the comments in existing code.
> > > One other difference is that H6 has extra bit in LOSC_CTRL_REG, called
> > > EXT_LOSC_EN to enable/disable external low speed crystal oscillator.
> > >
> > > It also has bit EXT_LOSC_STA in LOSC_AUTO_SWT_STA_REG, to check whether
> > > external low speed oscillator is working correctly.
> > >
> > > This patch adds support for enabling LOSC when necessary:
> > >
> > > - during reparenting
> > > - when probing the clock
> > >
> > > H6 also has capacbility to automatically reparent RTC clock from
> > > external crystal oscillator, to internal RC oscillator, if external
> > > oscillator fails. This is enabled by default. Disable it during
> > > probe.
> > >
> > > Signed-off-by: Ondrej Jirman <megous@megous.com>
> > > ---
> > > drivers/rtc/rtc-sun6i.c | 40 ++++++++++++++++++++++++++++++++++++++--
> > > 1 file changed, 38 insertions(+), 2 deletions(-)
> > >
> > > diff --git a/drivers/rtc/rtc-sun6i.c b/drivers/rtc/rtc-sun6i.c
> > > index 11f56de52179..7375a530c565 100644
> > > --- a/drivers/rtc/rtc-sun6i.c
> > > +++ b/drivers/rtc/rtc-sun6i.c
> > > @@ -41,9 +41,11 @@
> > > /* Control register */
> > > #define SUN6I_LOSC_CTRL 0x0000
> > > #define SUN6I_LOSC_CTRL_KEY (0x16aa << 16)
> > > +#define SUN6I_LOSC_CTRL_AUTO_SWT_BYPASS BIT(15)
> >
> > Manual says bit 14? Or is this different from LOSC_AUTO_SWT_EN?
> >
> > The rest looks ok.
>
> To give you more information. This is a new thing in H6 BSP, compared
> to BSPs for previous SoCs (H5/H3).
>
> 20 #define REG_CLK32K_AUTO_SWT_EN BIT(14)
> 21 #define REG_CLK32K_AUTO_SWT_BYPASS BIT(15)
>
> Init sequence changed in H6 BSP to:
>
> 646 /*
> 647 * Step1: select RTC clock source
> 648 */
> 649 tmp_data = readl(chip->base + SUNXI_LOSC_CTRL);
> 650 tmp_data &= (~REG_CLK32K_AUTO_SWT_EN);
> 651
> 652 /* Disable auto switch function */
> 653 tmp_data |= REG_CLK32K_AUTO_SWT_BYPASS;
> 654 writel(tmp_data, chip->base + SUNXI_LOSC_CTRL);
> 655
> 656 tmp_data = readl(chip->base + SUNXI_LOSC_CTRL);
> 657 tmp_data |= (RTC_SOURCE_EXTERNAL | REG_LOSCCTRL_MAGIC);
> 658 writel(tmp_data, chip->base + SUNXI_LOSC_CTRL);
> 659
> 660 /* We need to set GSM after change clock source */
> 661 udelay(10);
> 662 tmp_data = readl(chip->base + SUNXI_LOSC_CTRL);
> 663 tmp_data |= (EXT_LOSC_GSM | REG_LOSCCTRL_MAGIC);
> 664 writel(tmp_data, chip->base + SUNXI_LOSC_CTRL);
> 665
I don't have this in my H6 BSPs. One is H6 Lichee v1.1 downloaded from Pine64.
The link was from linux-sunxi wiki's H6 page.
The other is a 4.9 kernel tree, which I believe is from Allwinner's github:
https://github.com/Allwinner-Homlet/H6-BSP4.9-linux
> For older BSPs, the init sequence looked like this:
>
> 482 /*
> 483 * Step1: select RTC clock source
> 484 */
> 485 tmp_data = sunxi_rtc_read(SUNXI_LOSC_CTRL_REG);
> 486 tmp_data &= (~REG_CLK32K_AUTO_SWT_EN);
> 487 tmp_data |= (RTC_SOURCE_EXTERNAL | REG_LOSCCTRL_MAGIC);
> 488 tmp_data |= (EXT_LOSC_GSM);
> 489 sunxi_rtc_write(tmp_data, SUNXI_LOSC_CTRL_REG);
> 490
>
> EXT_LOSC_GSM has values 4 values from low to high, and I guess it configures
> gain for the oscillator's amplifier in the feedback loop of the circuit.
>
> So the new code, for some reason changed from single write to sequence
> of individual writes/config steps:
>
> 1) disable auto-switch and enable auto-switch bypass
> 2) select RTC clock source (to LOSC)
> (wait)
Maybe it's possible to glitch if these two are combined?
> 3) configure gain on the LOSC
>
> regards,
> o.
>
> > ChenYu
>
> --
> You received this message because you are subscribed to the Google Groups "linux-sunxi" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscribe@googlegroups.com.
> To view this discussion on the web, visit https://groups.google.com/d/msgid/linux-sunxi/20190805104529.z3mex3m2tss7lzlr%40core.my.home.
_______________________________________________
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 v1 13/16] drm/panel: drop return code from drm_panel_detach()
From: Laurent Pinchart @ 2019-08-05 10:56 UTC (permalink / raw)
To: Sam Ravnborg
Cc: Neil Armstrong, David Airlie, Linus Walleij, dri-devel,
Andrzej Hajda, Thierry Reding, Benjamin Gaignard, Fabio Estevam,
Marek Vasut, Laurent Pinchart, Joonyoung Shim, Vincent Abriou,
Krzysztof Kozlowski, Jonathan Hunter, Maxime Ripard, Kukjin Kim,
linux-arm-kernel, Philipp Zabel, NXP Linux Team,
Pengutronix Kernel Team, Jonas Karlman, Sascha Hauer, Alison Wang,
Maarten Lankhorst, Gwan-gyeong Mun, Inki Dae, Alexios Zavras,
linux-samsung-soc, Stefan Agner, linux-tegra, Thomas Gleixner,
Sean Paul, Allison Randal, Jernej Skrabec, Shawn Guo,
Seung-Woo Kim, Kyungmin Park, Daniel Vetter, Enrico Weigelt
In-Reply-To: <20190804201637.1240-14-sam@ravnborg.org>
Hi Sam,
Thank you for the patch.
On Sun, Aug 04, 2019 at 10:16:34PM +0200, Sam Ravnborg wrote:
> There are no errors that can be reported by this function,
> so drop the return code.
> Fix the only bridge driver that checked the return result.
>
> Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
> Cc: Thierry Reding <thierry.reding@gmail.com>
> Cc: Sam Ravnborg <sam@ravnborg.org>
> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
> Cc: Maxime Ripard <maxime.ripard@bootlin.com>
> Cc: Sean Paul <sean@poorly.run>
> Cc: David Airlie <airlied@linux.ie>
> Cc: Daniel Vetter <daniel@ffwll.ch>
> Cc: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
> Cc: Andrzej Hajda <a.hajda@samsung.com>
> Cc: Gwan-gyeong Mun <gwan-gyeong.mun@intel.com>
> Cc: Thomas Gleixner <tglx@linutronix.de>
> Cc: Linus Walleij <linus.walleij@linaro.org>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
> ---
> drivers/gpu/drm/bridge/analogix/analogix_dp_core.c | 3 +--
> drivers/gpu/drm/drm_panel.c | 6 +-----
> include/drm/drm_panel.h | 2 +-
> 3 files changed, 3 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
> index f2f7f69d6cc3..22885dceaa17 100644
> --- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
> +++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
> @@ -1780,8 +1780,7 @@ void analogix_dp_unbind(struct analogix_dp_device *dp)
> if (dp->plat_data->panel) {
> if (drm_panel_unprepare(dp->plat_data->panel))
> DRM_ERROR("failed to turnoff the panel\n");
> - if (drm_panel_detach(dp->plat_data->panel))
> - DRM_ERROR("failed to detach the panel\n");
> + drm_panel_detach(dp->plat_data->panel);
> }
>
> drm_dp_aux_unregister(&dp->aux);
> diff --git a/drivers/gpu/drm/drm_panel.c b/drivers/gpu/drm/drm_panel.c
> index 9946b8d9bacc..da19d5b4a2f4 100644
> --- a/drivers/gpu/drm/drm_panel.c
> +++ b/drivers/gpu/drm/drm_panel.c
> @@ -219,15 +219,11 @@ EXPORT_SYMBOL(drm_panel_attach);
> *
> * This function should not be called by the panel device itself. It
> * is only for the drm device that called drm_panel_attach().
> - *
> - * Return: 0 on success or a negative error code on failure.
> */
> -int drm_panel_detach(struct drm_panel *panel)
> +void drm_panel_detach(struct drm_panel *panel)
> {
> panel->connector = NULL;
> panel->drm = NULL;
> -
> - return 0;
> }
> EXPORT_SYMBOL(drm_panel_detach);
>
> diff --git a/include/drm/drm_panel.h b/include/drm/drm_panel.h
> index 5e62deea49ba..624bd15ecfab 100644
> --- a/include/drm/drm_panel.h
> +++ b/include/drm/drm_panel.h
> @@ -153,7 +153,7 @@ int drm_panel_add(struct drm_panel *panel);
> void drm_panel_remove(struct drm_panel *panel);
>
> int drm_panel_attach(struct drm_panel *panel, struct drm_connector *connector);
> -int drm_panel_detach(struct drm_panel *panel);
> +void drm_panel_detach(struct drm_panel *panel);
>
> int drm_panel_prepare(struct drm_panel *panel);
> int drm_panel_unprepare(struct drm_panel *panel);
--
Regards,
Laurent Pinchart
_______________________________________________
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 v1 14/16] drm/panel: call prepare/enable only once
From: Laurent Pinchart @ 2019-08-05 10:59 UTC (permalink / raw)
To: Sam Ravnborg
Cc: Neil Armstrong, David Airlie, Linus Walleij, dri-devel,
Andrzej Hajda, Thierry Reding, Benjamin Gaignard, Fabio Estevam,
Marek Vasut, Laurent Pinchart, Joonyoung Shim, Vincent Abriou,
Krzysztof Kozlowski, Jonathan Hunter, Maxime Ripard, Kukjin Kim,
linux-arm-kernel, Philipp Zabel, NXP Linux Team,
Pengutronix Kernel Team, Jonas Karlman, Sascha Hauer, Alison Wang,
Maarten Lankhorst, Gwan-gyeong Mun, Inki Dae, Alexios Zavras,
linux-samsung-soc, Stefan Agner, linux-tegra, Thomas Gleixner,
Sean Paul, Allison Randal, Jernej Skrabec, Shawn Guo,
Seung-Woo Kim, Kyungmin Park, Daniel Vetter, Enrico Weigelt
In-Reply-To: <20190804201637.1240-15-sam@ravnborg.org>
Hi Sam,
Thank you for the patch.
On Sun, Aug 04, 2019 at 10:16:35PM +0200, Sam Ravnborg wrote:
> Many panel drivers duplicate logic to prevent prepare to be called
> for a panel that is already prepared.
> Likewise for enable.
>
> Implement this logic in drm_panel so the individual drivers
> no longer needs this.
> A panel is considered prepared/enabled only if the prepare/enable call
> succeeds.
> For disable/unprepare it is unconditionally considered
> disabled/unprepared.
>
> This allows calls to prepare/enable again, even if there were
> some issue disabling a regulator or similar during disable/unprepare.
Is this the right place to handle this ? Shouldn't the upper layers
ensure than enable/disable and prepare/unprepare are correcty balanced,
and not called multiple times ? Adding enabled and prepared state to
drm_panel not only doesn't align well with atomic state handling, but
also would hide issues in upper layers that should really be fixed
there.
> Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
> Cc: Maxime Ripard <maxime.ripard@bootlin.com>
> Cc: Sean Paul <sean@poorly.run>
> Cc: Thierry Reding <thierry.reding@gmail.com>
> Cc: Sam Ravnborg <sam@ravnborg.org>
> Cc: David Airlie <airlied@linux.ie>
> Cc: Daniel Vetter <daniel@ffwll.ch>
> ---
> drivers/gpu/drm/drm_panel.c | 66 ++++++++++++++++++++++++++++++-------
> include/drm/drm_panel.h | 21 ++++++++++++
> 2 files changed, 75 insertions(+), 12 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_panel.c b/drivers/gpu/drm/drm_panel.c
> index da19d5b4a2f4..0853764040de 100644
> --- a/drivers/gpu/drm/drm_panel.c
> +++ b/drivers/gpu/drm/drm_panel.c
> @@ -66,10 +66,21 @@ EXPORT_SYMBOL(drm_panel_init);
> */
> int drm_panel_prepare(struct drm_panel *panel)
> {
> - if (panel && panel->funcs && panel->funcs->prepare)
> - return panel->funcs->prepare(panel);
> + int ret = -ENOSYS;
>
> - return panel ? -ENOSYS : -EINVAL;
> + if (!panel)
> + return -EINVAL;
> +
> + if (panel->prepared)
> + return 0;
> +
> + if (panel->funcs && panel->funcs->prepare)
> + ret = panel->funcs->prepare(panel);
> +
> + if (ret >= 0)
> + panel->prepared = true;
> +
> + return ret;
> }
> EXPORT_SYMBOL(drm_panel_prepare);
>
> @@ -85,10 +96,21 @@ EXPORT_SYMBOL(drm_panel_prepare);
> */
> int drm_panel_enable(struct drm_panel *panel)
> {
> - if (panel && panel->funcs && panel->funcs->enable)
> - return panel->funcs->enable(panel);
> + int ret = -ENOSYS;
>
> - return panel ? -ENOSYS : -EINVAL;
> + if (!panel)
> + return -EINVAL;
> +
> + if (panel->enabled)
> + return 0;
> +
> + if (panel->funcs && panel->funcs->enable)
> + ret = panel->funcs->enable(panel);
> +
> + if (ret >= 0)
> + panel->enabled = true;
> +
> + return ret;
> }
> EXPORT_SYMBOL(drm_panel_enable);
>
> @@ -104,10 +126,20 @@ EXPORT_SYMBOL(drm_panel_enable);
> */
> int drm_panel_disable(struct drm_panel *panel)
> {
> - if (panel && panel->funcs && panel->funcs->disable)
> - return panel->funcs->disable(panel);
> + int ret = -ENOSYS;
>
> - return panel ? -ENOSYS : -EINVAL;
> + if (!panel)
> + return -EINVAL;
> +
> + if (!panel->enabled)
> + return 0;
> +
> + if (panel->funcs && panel->funcs->disable)
> + ret = panel->funcs->disable(panel);
> +
> + panel->enabled = false;
> +
> + return ret;
> }
> EXPORT_SYMBOL(drm_panel_disable);
>
> @@ -124,10 +156,20 @@ EXPORT_SYMBOL(drm_panel_disable);
> */
> int drm_panel_unprepare(struct drm_panel *panel)
> {
> - if (panel && panel->funcs && panel->funcs->unprepare)
> - return panel->funcs->unprepare(panel);
> + int ret = -ENOSYS;
>
> - return panel ? -ENOSYS : -EINVAL;
> + if (!panel)
> + return -EINVAL;
> +
> + if (!panel->prepared)
> + return 0;
> +
> + if (panel->funcs && panel->funcs->unprepare)
> + ret = panel->funcs->unprepare(panel);
> +
> + panel->prepared = false;
> +
> + return ret;
> }
> EXPORT_SYMBOL(drm_panel_unprepare);
>
> diff --git a/include/drm/drm_panel.h b/include/drm/drm_panel.h
> index 624bd15ecfab..7493500fc9bd 100644
> --- a/include/drm/drm_panel.h
> +++ b/include/drm/drm_panel.h
> @@ -65,6 +65,9 @@ struct drm_panel_funcs {
> * @prepare:
> *
> * Turn on panel and perform set up.
> + * When the panel is successfully prepared the prepare() function
> + * will not be called again until the panel has been unprepared.
> + *
> */
> int (*prepare)(struct drm_panel *panel);
>
> @@ -72,6 +75,8 @@ struct drm_panel_funcs {
> * @enable:
> *
> * Enable panel (turn on back light, etc.).
> + * When the panel is successfully enabled the enable() function
> + * will not be called again until the panel has been disabled.
> */
> int (*enable)(struct drm_panel *panel);
>
> @@ -79,6 +84,7 @@ struct drm_panel_funcs {
> * @disable:
> *
> * Disable panel (turn off back light, etc.).
> + * If the panel is already disabled the disable() function is not called.
> */
> int (*disable)(struct drm_panel *panel);
>
> @@ -86,6 +92,7 @@ struct drm_panel_funcs {
> * @unprepare:
> *
> * Turn off panel.
> + * If the panel is already unprepared the unprepare() function is not called.
> */
> int (*unprepare)(struct drm_panel *panel);
>
> @@ -145,6 +152,20 @@ struct drm_panel {
> * Panel entry in registry.
> */
> struct list_head list;
> +
> + /**
> + * @prepared:
> + *
> + * Set to true when the panel is successfully prepared.
> + */
> + bool prepared;
> +
> + /**
> + * @enabled:
> + *
> + * Set to true when the panel is successfully enabled.
> + */
> + bool enabled;
> };
>
> void drm_panel_init(struct drm_panel *panel);
--
Regards,
Laurent Pinchart
_______________________________________________
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] pinctrl: meson-g12a: add pwm_a on GPIOE_2 pinmux
From: Linus Walleij @ 2019-08-05 11:01 UTC (permalink / raw)
To: Neil Armstrong
Cc: Martin Blumenstingl, Kevin Hilman, linux-kernel@vger.kernel.org,
open list:GPIO SUBSYSTEM, open list:ARM/Amlogic Meson...,
Linux ARM
In-Reply-To: <20190729125838.6498-1-narmstrong@baylibre.com>
On Mon, Jul 29, 2019 at 2:58 PM Neil Armstrong <narmstrong@baylibre.com> wrote:
> Add the missing pinmux for the pwm_a function on the GPIOE_2 pin.
>
> Reviewed-by: Kevin Hilman <khilman@baylibre.com>
> Reviewed-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
> Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
Patch applied.
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 v1 15/16] drm/panel: add backlight support
From: Laurent Pinchart @ 2019-08-05 11:04 UTC (permalink / raw)
To: Sam Ravnborg
Cc: Neil Armstrong, David Airlie, Linus Walleij, dri-devel,
Andrzej Hajda, Thierry Reding, Benjamin Gaignard, Fabio Estevam,
Marek Vasut, Laurent Pinchart, Joonyoung Shim, Vincent Abriou,
Krzysztof Kozlowski, Jonathan Hunter, Maxime Ripard, Kukjin Kim,
linux-arm-kernel, Philipp Zabel, NXP Linux Team,
Pengutronix Kernel Team, Jonas Karlman, Sascha Hauer, Alison Wang,
Maarten Lankhorst, Gwan-gyeong Mun, Inki Dae, Alexios Zavras,
linux-samsung-soc, Stefan Agner, linux-tegra, Thomas Gleixner,
Sean Paul, Allison Randal, Jernej Skrabec, Shawn Guo,
Seung-Woo Kim, Kyungmin Park, Daniel Vetter, Enrico Weigelt
In-Reply-To: <20190804201637.1240-16-sam@ravnborg.org>
Hi Sam,
Thank you for the patch.
On Sun, Aug 04, 2019 at 10:16:36PM +0200, Sam Ravnborg wrote:
> Panels often supports backlight as specified in a device tree.
> Update the drm_panel infrastructure to support this to
> simplify the drivers.
>
> With this the panel driver just needs to add the following to the
> probe() function:
>
> err = drm_panel_of_backlight(panel);
> if (err)
> return err;
>
> Then drm_panel will handle all the rest.
Do you have an example on how this will simplify drivers ? How many
existing panel drivers would benefit from this, and do you plan to
convert them ?
>
> Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
> Cc: Maxime Ripard <maxime.ripard@bootlin.com>
> Cc: Sean Paul <sean@poorly.run>
> Cc: Thierry Reding <thierry.reding@gmail.com>
> Cc: Sam Ravnborg <sam@ravnborg.org>
> Cc: David Airlie <airlied@linux.ie>
> Cc: Daniel Vetter <daniel@ffwll.ch>
> ---
> drivers/gpu/drm/drm_panel.c | 41 +++++++++++++++++++++++++++++++++++++
> include/drm/drm_panel.h | 23 +++++++++++++++++++++
> 2 files changed, 64 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_panel.c b/drivers/gpu/drm/drm_panel.c
> index 0853764040de..d8139674b883 100644
> --- a/drivers/gpu/drm/drm_panel.c
> +++ b/drivers/gpu/drm/drm_panel.c
> @@ -21,6 +21,7 @@
> * DEALINGS IN THE SOFTWARE.
> */
>
> +#include <linux/backlight.h>
> #include <linux/err.h>
> #include <linux/module.h>
>
> @@ -110,6 +111,7 @@ int drm_panel_enable(struct drm_panel *panel)
> if (ret >= 0)
> panel->enabled = true;
>
> + backlight_enable(panel->backlight);
> return ret;
> }
> EXPORT_SYMBOL(drm_panel_enable);
> @@ -134,6 +136,8 @@ int drm_panel_disable(struct drm_panel *panel)
> if (!panel->enabled)
> return 0;
>
> + backlight_disable(panel->backlight);
> +
> if (panel->funcs && panel->funcs->disable)
> ret = panel->funcs->disable(panel);
>
> @@ -308,6 +312,43 @@ struct drm_panel *of_drm_find_panel(const struct device_node *np)
> EXPORT_SYMBOL(of_drm_find_panel);
> #endif
>
> +#ifdef CONFIG_BACKLIGHT_CLASS_DEVICE
> +/**
> + * drm_panel_of_backlight - use backlight device node for backlight
> + * @panel: DRM panel
> + *
> + * Use this function to enable backlight handling if your panel
> + * uses device tree and has a backlight handle.
> + *
> + * When panel is enabled backlight will be enabled after a
> + * successfull call to &drm_panel_funcs.enable()
> + *
> + * When panel is disabled backlight will be disabled before the
> + * call to &drm_panel_funcs.disable().
> + *
> + * A typical implementation for a panel driver supporting device tree
> + * will call this function and then backlight just works.
> + *
> + * Return: 0 on success or a negative error code on failure.
> + */
> +int drm_panel_of_backlight(struct drm_panel *panel)
> +{
> + struct backlight_device *backlight;
> +
> + if (!panel || !panel->dev)
> + return -EINVAL;
> +
> + backlight = devm_of_find_backlight(panel->dev);
> +
> + if (IS_ERR(backlight))
> + return PTR_ERR(backlight);
> +
> + panel->backlight = backlight;
> + return 0;
> +}
> +EXPORT_SYMBOL(drm_panel_of_backlight);
> +#endif
> +
> MODULE_AUTHOR("Thierry Reding <treding@nvidia.com>");
> MODULE_DESCRIPTION("DRM panel infrastructure");
> MODULE_LICENSE("GPL and additional rights");
> diff --git a/include/drm/drm_panel.h b/include/drm/drm_panel.h
> index 7493500fc9bd..31349c2393b7 100644
> --- a/include/drm/drm_panel.h
> +++ b/include/drm/drm_panel.h
> @@ -28,6 +28,7 @@
> #include <linux/errno.h>
> #include <linux/list.h>
>
> +struct backlight_device;
> struct device_node;
> struct drm_connector;
> struct drm_device;
> @@ -59,6 +60,10 @@ struct display_timing;
> *
> * To save power when no video data is transmitted, a driver can power down
> * the panel. This is the job of the .unprepare() function.
> + *
> + * Backlight can be handled automatically if configured using
> + * drm_panel_of_backlight(). Then the driver do not need to implement the
> + * functionality to enable/disable backlight.
> */
> struct drm_panel_funcs {
> /**
> @@ -139,6 +144,15 @@ struct drm_panel {
> */
> struct device *dev;
>
> + /**
> + * @backlight:
> + *
> + * Backlight device, used to turn on backlight after
> + * the call to enable(), and to turn off
> + * backlight before call to disable().
> + */
> + struct backlight_device *backlight;
> +
> /**
> * @funcs:
> *
> @@ -193,4 +207,13 @@ static inline struct drm_panel *of_drm_find_panel(const struct device_node *np)
> }
> #endif
>
> +#if defined(CONFIG_BACKLIGHT_CLASS_DEVICE) && defined(CONFIG_DRM_PANEL)
> +int drm_panel_of_backlight(struct drm_panel *panel);
I would expect callers of this function to depend on (or select)
CONFIG_DRM_PANEL, so I would drop it from here.
> +#else
> +static inline int drm_panel_of_backlight(struct drm_panel *panel)
> +{
> + return -EINVAL;
Maybe -ENOSYS ?
> +}
> +#endif
> +
> #endif
--
Regards,
Laurent Pinchart
_______________________________________________
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 01/11] arm64: mm: Remove bit-masking optimisations for PAGE_OFFSET and VMEMMAP_START
From: Catalin Marinas @ 2019-08-05 11:07 UTC (permalink / raw)
To: Steve Capper
Cc: crecklin, ard.biesheuvel, maz, bhsharma, will, linux-arm-kernel
In-Reply-To: <20190729162117.832-2-steve.capper@arm.com>
On Mon, Jul 29, 2019 at 05:21:07PM +0100, Steve Capper wrote:
> Currently there are assumptions about the alignment of VMEMMAP_START
> and PAGE_OFFSET that won't be valid after this series is applied.
>
> These assumptions are in the form of bitwise operators being used
> instead of addition and subtraction when calculating addresses.
>
> This patch replaces these bitwise operators with addition/subtraction.
>
> Signed-off-by: Steve Capper <steve.capper@arm.com>
Reviewed-by: Catalin Marinas <catalin.marinas@arm.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: [linux-sunxi] [PATCH 2/3] rtc: sun6i: Add support for H6 RTC
From: Ondřej Jirman @ 2019-08-05 11:10 UTC (permalink / raw)
To: Chen-Yu Tsai
Cc: Mark Rutland, Alessandro Zummo, Alexandre Belloni, devicetree,
Maxime Ripard, linux-kernel, linux-sunxi, Rob Herring,
linux-arm-kernel, linux-rtc
In-Reply-To: <CAGb2v67pcxdxjdRX_HN4133A32eA566DDtUJUKV7pqzxDtOaeg@mail.gmail.com>
On Mon, Aug 05, 2019 at 06:54:17PM +0800, Chen-Yu Tsai wrote:
> On Mon, Aug 5, 2019 at 6:45 PM Ondřej Jirman <megous@megous.com> wrote:
> >
> > On Mon, Aug 05, 2019 at 06:16:14PM +0800, Chen-Yu Tsai wrote:
> > > On Fri, Apr 12, 2019 at 8:07 PM megous via linux-sunxi
> > > <linux-sunxi@googlegroups.com> wrote:
> > > >
> > > > From: Ondrej Jirman <megous@megous.com>
> > > >
> > > > RTC on H6 is mostly the same as on H5 and H3. It has slight differences
> > > > mostly in features that are not yet supported by this driver.
> > > >
> > > > Some differences are already stated in the comments in existing code.
> > > > One other difference is that H6 has extra bit in LOSC_CTRL_REG, called
> > > > EXT_LOSC_EN to enable/disable external low speed crystal oscillator.
> > > >
> > > > It also has bit EXT_LOSC_STA in LOSC_AUTO_SWT_STA_REG, to check whether
> > > > external low speed oscillator is working correctly.
> > > >
> > > > This patch adds support for enabling LOSC when necessary:
> > > >
> > > > - during reparenting
> > > > - when probing the clock
> > > >
> > > > H6 also has capacbility to automatically reparent RTC clock from
> > > > external crystal oscillator, to internal RC oscillator, if external
> > > > oscillator fails. This is enabled by default. Disable it during
> > > > probe.
> > > >
> > > > Signed-off-by: Ondrej Jirman <megous@megous.com>
> > > > ---
> > > > drivers/rtc/rtc-sun6i.c | 40 ++++++++++++++++++++++++++++++++++++++--
> > > > 1 file changed, 38 insertions(+), 2 deletions(-)
> > > >
> > > > diff --git a/drivers/rtc/rtc-sun6i.c b/drivers/rtc/rtc-sun6i.c
> > > > index 11f56de52179..7375a530c565 100644
> > > > --- a/drivers/rtc/rtc-sun6i.c
> > > > +++ b/drivers/rtc/rtc-sun6i.c
> > > > @@ -41,9 +41,11 @@
> > > > /* Control register */
> > > > #define SUN6I_LOSC_CTRL 0x0000
> > > > #define SUN6I_LOSC_CTRL_KEY (0x16aa << 16)
> > > > +#define SUN6I_LOSC_CTRL_AUTO_SWT_BYPASS BIT(15)
> > >
> > > Manual says bit 14? Or is this different from LOSC_AUTO_SWT_EN?
> > >
> > > The rest looks ok.
> >
> > To give you more information. This is a new thing in H6 BSP, compared
> > to BSPs for previous SoCs (H5/H3).
> >
> > 20 #define REG_CLK32K_AUTO_SWT_EN BIT(14)
> > 21 #define REG_CLK32K_AUTO_SWT_BYPASS BIT(15)
> >
> > Init sequence changed in H6 BSP to:
> >
> > 646 /*
> > 647 * Step1: select RTC clock source
> > 648 */
> > 649 tmp_data = readl(chip->base + SUNXI_LOSC_CTRL);
> > 650 tmp_data &= (~REG_CLK32K_AUTO_SWT_EN);
> > 651
> > 652 /* Disable auto switch function */
> > 653 tmp_data |= REG_CLK32K_AUTO_SWT_BYPASS;
> > 654 writel(tmp_data, chip->base + SUNXI_LOSC_CTRL);
> > 655
> > 656 tmp_data = readl(chip->base + SUNXI_LOSC_CTRL);
> > 657 tmp_data |= (RTC_SOURCE_EXTERNAL | REG_LOSCCTRL_MAGIC);
> > 658 writel(tmp_data, chip->base + SUNXI_LOSC_CTRL);
> > 659
> > 660 /* We need to set GSM after change clock source */
> > 661 udelay(10);
> > 662 tmp_data = readl(chip->base + SUNXI_LOSC_CTRL);
> > 663 tmp_data |= (EXT_LOSC_GSM | REG_LOSCCTRL_MAGIC);
> > 664 writel(tmp_data, chip->base + SUNXI_LOSC_CTRL);
> > 665
>
> I don't have this in my H6 BSPs. One is H6 Lichee v1.1 downloaded from Pine64.
> The link was from linux-sunxi wiki's H6 page.
>
> The other is a 4.9 kernel tree, which I believe is from Allwinner's github:
>
> https://github.com/Allwinner-Homlet/H6-BSP4.9-linux
Interesting. :) I have the BSP I was using saved here:
https://megous.com/git/linux/tree/drivers/rtc/rtc-sunxi.c?h=h6-4.9-bsp#n649
It's based of 4.9.119
https://megous.com/git/linux/log/?h=h6-4.9-bsp
I don't remember where I found it. But I imported it fairly recently, and
the code you pointed to looks like an older version that I can found in some
beta H6 BSP, that I imported way earlier and is based on 4.9.56:
https://megous.com/git/linux/tree/drivers/rtc/rtc-sunxi.c?h=linux-h6
https://megous.com/git/linux/log/?h=linux-h6
Hmm, archeology. :)
> > For older BSPs, the init sequence looked like this:
> >
> > 482 /*
> > 483 * Step1: select RTC clock source
> > 484 */
> > 485 tmp_data = sunxi_rtc_read(SUNXI_LOSC_CTRL_REG);
> > 486 tmp_data &= (~REG_CLK32K_AUTO_SWT_EN);
> > 487 tmp_data |= (RTC_SOURCE_EXTERNAL | REG_LOSCCTRL_MAGIC);
> > 488 tmp_data |= (EXT_LOSC_GSM);
> > 489 sunxi_rtc_write(tmp_data, SUNXI_LOSC_CTRL_REG);
> > 490
> >
> > EXT_LOSC_GSM has values 4 values from low to high, and I guess it configures
> > gain for the oscillator's amplifier in the feedback loop of the circuit.
> >
> > So the new code, for some reason changed from single write to sequence
> > of individual writes/config steps:
> >
> > 1) disable auto-switch and enable auto-switch bypass
> > 2) select RTC clock source (to LOSC)
> > (wait)
>
> Maybe it's possible to glitch if these two are combined?
That's what I thought too. Or the programmer thought so, and was just
programming defensively, and there's no real problem in the practice.
But that specific delay() seems like someone trying to solve a real issue. Of
course there's no knowing if it was on H6 or on some other SoC.
regards,
o.
>
> > 3) configure gain on the LOSC
> >
> > regards,
> > o.
> >
> > > ChenYu
> >
> > --
> > You received this message because you are subscribed to the Google Groups "linux-sunxi" group.
> > To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscribe@googlegroups.com.
> > To view this discussion on the web, visit https://groups.google.com/d/msgid/linux-sunxi/20190805104529.z3mex3m2tss7lzlr%40core.my.home.
_______________________________________________
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 v1 16/16] drm/panel: simple: use drm_panel infrastructure
From: Laurent Pinchart @ 2019-08-05 11:12 UTC (permalink / raw)
To: Sam Ravnborg
Cc: Neil Armstrong, David Airlie, Linus Walleij, dri-devel,
Andrzej Hajda, Thierry Reding, Benjamin Gaignard, Fabio Estevam,
Marek Vasut, Laurent Pinchart, Joonyoung Shim, Vincent Abriou,
Krzysztof Kozlowski, Jonathan Hunter, Maxime Ripard, Kukjin Kim,
linux-arm-kernel, Philipp Zabel, NXP Linux Team,
Pengutronix Kernel Team, Jonas Karlman, Sascha Hauer, Alison Wang,
Maarten Lankhorst, Gwan-gyeong Mun, Inki Dae, Alexios Zavras,
linux-samsung-soc, Stefan Agner, linux-tegra, Thomas Gleixner,
Sean Paul, Allison Randal, Jernej Skrabec, Shawn Guo,
Seung-Woo Kim, Kyungmin Park, Daniel Vetter, Enrico Weigelt
In-Reply-To: <20190804201637.1240-17-sam@ravnborg.org>
Hi Sam,
Thank you for the patch.
On Sun, Aug 04, 2019 at 10:16:37PM +0200, Sam Ravnborg wrote:
> Use drm_panel infrastrucute:
> - drm_panel has guards for calling disable/enable twice
As stated in the review of the corresponding patch, I think those checks
should be dropped, but not moved to the panel core.
> - drm_panel has backlight support
This answers my first question in the review of 15/16 :-)
> To use the drm_panel infrastructure use the drm_panel_*
> variants for prepare/enable/disable/unprepare.
>
> Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
> Cc: Thierry Reding <thierry.reding@gmail.com>
> Cc: Sam Ravnborg <sam@ravnborg.org>
The change looks good overall,
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
but this is pending an agreement on what to do with the multiple
prepare/enable guards.
> ---
> drivers/gpu/drm/panel/panel-simple.c | 73 +++++-----------------------
> 1 file changed, 11 insertions(+), 62 deletions(-)
>
> diff --git a/drivers/gpu/drm/panel/panel-simple.c b/drivers/gpu/drm/panel/panel-simple.c
> index bff7578f84dd..c7eed34f2c9c 100644
> --- a/drivers/gpu/drm/panel/panel-simple.c
> +++ b/drivers/gpu/drm/panel/panel-simple.c
> @@ -21,7 +21,6 @@
> * DEALINGS IN THE SOFTWARE.
> */
>
> -#include <linux/backlight.h>
> #include <linux/delay.h>
> #include <linux/gpio/consumer.h>
> #include <linux/module.h>
> @@ -98,13 +97,10 @@ struct panel_desc {
>
> struct panel_simple {
> struct drm_panel base;
> - bool prepared;
> - bool enabled;
> bool no_hpd;
>
> const struct panel_desc *desc;
>
> - struct backlight_device *backlight;
> struct regulator *supply;
> struct i2c_adapter *ddc;
>
> @@ -232,20 +228,9 @@ static int panel_simple_disable(struct drm_panel *panel)
> {
> struct panel_simple *p = to_panel_simple(panel);
>
> - if (!p->enabled)
> - return 0;
> -
> - if (p->backlight) {
> - p->backlight->props.power = FB_BLANK_POWERDOWN;
> - p->backlight->props.state |= BL_CORE_FBBLANK;
> - backlight_update_status(p->backlight);
> - }
> -
> if (p->desc->delay.disable)
> msleep(p->desc->delay.disable);
>
> - p->enabled = false;
> -
> return 0;
> }
>
> @@ -253,9 +238,6 @@ static int panel_simple_unprepare(struct drm_panel *panel)
> {
> struct panel_simple *p = to_panel_simple(panel);
>
> - if (!p->prepared)
> - return 0;
> -
> gpiod_set_value_cansleep(p->enable_gpio, 0);
>
> regulator_disable(p->supply);
> @@ -263,8 +245,6 @@ static int panel_simple_unprepare(struct drm_panel *panel)
> if (p->desc->delay.unprepare)
> msleep(p->desc->delay.unprepare);
>
> - p->prepared = false;
> -
> return 0;
> }
>
> @@ -274,9 +254,6 @@ static int panel_simple_prepare(struct drm_panel *panel)
> unsigned int delay;
> int err;
>
> - if (p->prepared)
> - return 0;
> -
> err = regulator_enable(p->supply);
> if (err < 0) {
> dev_err(panel->dev, "failed to enable supply: %d\n", err);
> @@ -291,8 +268,6 @@ static int panel_simple_prepare(struct drm_panel *panel)
> if (delay)
> msleep(delay);
>
> - p->prepared = true;
> -
> return 0;
> }
>
> @@ -300,20 +275,9 @@ static int panel_simple_enable(struct drm_panel *panel)
> {
> struct panel_simple *p = to_panel_simple(panel);
>
> - if (p->enabled)
> - return 0;
> -
> if (p->desc->delay.enable)
> msleep(p->desc->delay.enable);
>
> - if (p->backlight) {
> - p->backlight->props.state &= ~BL_CORE_FBBLANK;
> - p->backlight->props.power = FB_BLANK_UNBLANK;
> - backlight_update_status(p->backlight);
> - }
> -
> - p->enabled = true;
> -
> return 0;
> }
>
> @@ -413,7 +377,7 @@ static void panel_simple_parse_panel_timing_node(struct device *dev,
>
> static int panel_simple_probe(struct device *dev, const struct panel_desc *desc)
> {
> - struct device_node *backlight, *ddc;
> + struct device_node *ddc;
> struct panel_simple *panel;
> struct display_timing dt;
> int err;
> @@ -422,8 +386,6 @@ static int panel_simple_probe(struct device *dev, const struct panel_desc *desc)
> if (!panel)
> return -ENOMEM;
>
> - panel->enabled = false;
> - panel->prepared = false;
> panel->desc = desc;
>
> panel->no_hpd = of_property_read_bool(dev->of_node, "no-hpd");
> @@ -441,24 +403,13 @@ static int panel_simple_probe(struct device *dev, const struct panel_desc *desc)
> return err;
> }
>
> - backlight = of_parse_phandle(dev->of_node, "backlight", 0);
> - if (backlight) {
> - panel->backlight = of_find_backlight_by_node(backlight);
> - of_node_put(backlight);
> -
> - if (!panel->backlight)
> - return -EPROBE_DEFER;
> - }
> -
> ddc = of_parse_phandle(dev->of_node, "ddc-i2c-bus", 0);
> if (ddc) {
> panel->ddc = of_find_i2c_adapter_by_node(ddc);
> of_node_put(ddc);
>
> - if (!panel->ddc) {
> - err = -EPROBE_DEFER;
> - goto free_backlight;
> - }
> + if (!panel->ddc)
> + return -EPROBE_DEFER;
> }
>
> if (!of_get_display_timing(dev->of_node, "panel-timing", &dt))
> @@ -468,6 +419,10 @@ static int panel_simple_probe(struct device *dev, const struct panel_desc *desc)
> panel->base.dev = dev;
> panel->base.funcs = &panel_simple_funcs;
>
> + err = drm_panel_of_backlight(&panel->base);
> + if (err)
> + goto free_ddc;
> +
> err = drm_panel_add(&panel->base);
> if (err < 0)
> goto free_ddc;
> @@ -479,9 +434,6 @@ static int panel_simple_probe(struct device *dev, const struct panel_desc *desc)
> free_ddc:
> if (panel->ddc)
> put_device(&panel->ddc->dev);
> -free_backlight:
> - if (panel->backlight)
> - put_device(&panel->backlight->dev);
This looks weird, where
>
> return err;
> }
> @@ -492,15 +444,12 @@ static int panel_simple_remove(struct device *dev)
>
> drm_panel_remove(&panel->base);
>
> - panel_simple_disable(&panel->base);
> - panel_simple_unprepare(&panel->base);
> + drm_panel_disable(&panel->base);
> + drm_panel_unprepare(&panel->base);
>
> if (panel->ddc)
> put_device(&panel->ddc->dev);
>
> - if (panel->backlight)
> - put_device(&panel->backlight->dev);
> -
> return 0;
> }
>
> @@ -508,8 +457,8 @@ static void panel_simple_shutdown(struct device *dev)
> {
> struct panel_simple *panel = dev_get_drvdata(dev);
>
> - panel_simple_disable(&panel->base);
> - panel_simple_unprepare(&panel->base);
> + drm_panel_disable(&panel->base);
> + drm_panel_unprepare(&panel->base);
> }
>
> static const struct drm_display_mode ampire_am_480272h3tmqw_t01h_mode = {
--
Regards,
Laurent Pinchart
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: next/master build: 230 builds: 5 failed, 225 passed, 6 errors, 1344 warnings (next-20190805)
From: Mark Brown @ 2019-08-05 11:12 UTC (permalink / raw)
To: Alex Deucher, Christian König, David Zhou, David Airlie,
Daniel Vetter, Tao Zhou, Dennis Li
Cc: linux-next, amd-gfx, dri-devel, linux-arm-kernel,
kernel-build-reports
In-Reply-To: <5d47f990.1c69fb81.a5d88.ee1f@mx.google.com>
[-- Attachment #1.1: Type: text/plain, Size: 686 bytes --]
On Mon, Aug 05, 2019 at 02:40:32AM -0700, kernelci.org bot wrote:
Today's -next fails to build an arm allmodconfig due to:
> allmodconfig (arm, gcc-8) — FAIL, 2 errors, 16 warnings, 0 section mismatches
>
> Errors:
> drivers/gpu/drm/amd/amdgpu/amdgpu_device.c:279:9: error: implicit declaration of function 'readq'; did you mean 'readb'? [-Werror=implicit-function-declaration]
> drivers/gpu/drm/amd/amdgpu/amdgpu_device.c:298:3: error: implicit declaration of function 'writeq'; did you mean 'writeb'? [-Werror=implicit-function-declaration]
due to 4fa1c6a679bb0 (drm/amdgpu: add RREG64/WREG64(_PCIE) operations)
which introduces use of readq() and writeq().
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
[-- Attachment #2: Type: text/plain, Size: 176 bytes --]
_______________________________________________
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: Mark Brown @ 2019-08-05 11:13 UTC (permalink / raw)
To: Ashish Kumar
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: <VI1PR04MB401579932CF0E7D4AE80E0C995DA0@VI1PR04MB4015.eurprd04.prod.outlook.com>
[-- Attachment #1.1: Type: text/plain, Size: 1037 bytes --]
On Mon, Aug 05, 2019 at 09:07:47AM +0000, Ashish Kumar wrote:
> 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/
Please don't send content free pings and please allow a reasonable time
for review. People get busy, go on holiday, attend conferences and so
on so unless there is some reason for urgency (like critical bug fixes)
please allow at least a couple of weeks for review. If there have been
review comments then people may be waiting for those to be addressed.
Sending content free pings adds to the mail volume (if they are seen at
all) which is often the problem and since they can't be reviewed
directly if something has gone wrong you'll have to resend the patches
anyway, so sending again is generally a better approach though there are
some other maintainers who like them - if in doubt look at how patches
for the subsystem are normally handled.
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
[-- Attachment #2: Type: text/plain, Size: 176 bytes --]
_______________________________________________
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 1/2] dt-bindings: spi: spi-fsl-qspi: Add ls2080a compatibility string to bindings
From: Mark Brown @ 2019-08-05 11:13 UTC (permalink / raw)
To: Ashish Kumar
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: <VI1PR04MB4015C2C9407598EFEEB4CB2D95DA0@VI1PR04MB4015.eurprd04.prod.outlook.com>
[-- Attachment #1.1: Type: text/plain, Size: 1037 bytes --]
On Mon, Aug 05, 2019 at 09:08:17AM +0000, Ashish Kumar wrote:
> 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/
Please don't send content free pings and please allow a reasonable time
for review. People get busy, go on holiday, attend conferences and so
on so unless there is some reason for urgency (like critical bug fixes)
please allow at least a couple of weeks for review. If there have been
review comments then people may be waiting for those to be addressed.
Sending content free pings adds to the mail volume (if they are seen at
all) which is often the problem and since they can't be reviewed
directly if something has gone wrong you'll have to resend the patches
anyway, so sending again is generally a better approach though there are
some other maintainers who like them - if in doubt look at how patches
for the subsystem are normally handled.
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
[-- Attachment #2: Type: text/plain, Size: 176 bytes --]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH] usb: yurex: Fix use-after-free in yurex_delete
From: Suzuki K Poulose @ 2019-08-05 11:15 UTC (permalink / raw)
To: linux-kernel
Cc: Oliver Neukum, Suzuki K Poulose, Jiri Kosina, linux-usb,
syzkaller-bugs, gregkh, syzbot+d1fedb1c1fdb07fca507, Alan Stern,
andreyknvl, Tomoki Sekiyama, dtor, linux-arm-kernel
syzbot reported the following crash [0]:
BUG: KASAN: use-after-free in usb_free_coherent+0x79/0x80
drivers/usb/core/usb.c:928
Read of size 8 at addr ffff8881b18599c8 by task syz-executor.4/16007
CPU: 0 PID: 16007 Comm: syz-executor.4 Not tainted 5.3.0-rc2+ #23
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
Google 01/01/2011
Call Trace:
__dump_stack lib/dump_stack.c:77 [inline]
dump_stack+0xca/0x13e lib/dump_stack.c:113
print_address_description+0x6a/0x32c mm/kasan/report.c:351
__kasan_report.cold+0x1a/0x33 mm/kasan/report.c:482
kasan_report+0xe/0x12 mm/kasan/common.c:612
usb_free_coherent+0x79/0x80 drivers/usb/core/usb.c:928
yurex_delete+0x138/0x330 drivers/usb/misc/yurex.c:100
kref_put include/linux/kref.h:65 [inline]
yurex_release+0x66/0x90 drivers/usb/misc/yurex.c:392
__fput+0x2d7/0x840 fs/file_table.c:280
task_work_run+0x13f/0x1c0 kernel/task_work.c:113
tracehook_notify_resume include/linux/tracehook.h:188 [inline]
exit_to_usermode_loop+0x1d2/0x200 arch/x86/entry/common.c:163
prepare_exit_to_usermode arch/x86/entry/common.c:194 [inline]
syscall_return_slowpath arch/x86/entry/common.c:274 [inline]
do_syscall_64+0x45f/0x580 arch/x86/entry/common.c:299
entry_SYSCALL_64_after_hwframe+0x49/0xbe
RIP: 0033:0x413511
Code: 75 14 b8 03 00 00 00 0f 05 48 3d 01 f0 ff ff 0f 83 04 1b 00 00 c3 48
83 ec 08 e8 0a fc ff ff 48 89 04 24 b8 03 00 00 00 0f 05 <48> 8b 3c 24 48
89 c2 e8 53 fc ff ff 48 89 d0 48 83 c4 08 48 3d 01
RSP: 002b:00007ffc424ea2e0 EFLAGS: 00000293 ORIG_RAX: 0000000000000003
RAX: 0000000000000000 RBX: 0000000000000007 RCX: 0000000000413511
RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000006
RBP: 0000000000000001 R08: 0000000029a2fc22 R09: 0000000029a2fc26
R10: 00007ffc424ea3c0 R11: 0000000000000293 R12: 000000000075c9a0
R13: 000000000075c9a0 R14: 0000000000761938 R15: ffffffffffffffff
Allocated by task 2776:
save_stack+0x1b/0x80 mm/kasan/common.c:69
set_track mm/kasan/common.c:77 [inline]
__kasan_kmalloc mm/kasan/common.c:487 [inline]
__kasan_kmalloc.constprop.0+0xbf/0xd0 mm/kasan/common.c:460
kmalloc include/linux/slab.h:552 [inline]
kzalloc include/linux/slab.h:748 [inline]
usb_alloc_dev+0x51/0xf95 drivers/usb/core/usb.c:583
hub_port_connect drivers/usb/core/hub.c:5004 [inline]
hub_port_connect_change drivers/usb/core/hub.c:5213 [inline]
port_event drivers/usb/core/hub.c:5359 [inline]
hub_event+0x15c0/0x3640 drivers/usb/core/hub.c:5441
process_one_work+0x92b/0x1530 kernel/workqueue.c:2269
worker_thread+0x96/0xe20 kernel/workqueue.c:2415
kthread+0x318/0x420 kernel/kthread.c:255
ret_from_fork+0x24/0x30 arch/x86/entry/entry_64.S:352
Freed by task 16007:
save_stack+0x1b/0x80 mm/kasan/common.c:69
set_track mm/kasan/common.c:77 [inline]
__kasan_slab_free+0x130/0x180 mm/kasan/common.c:449
slab_free_hook mm/slub.c:1423 [inline]
slab_free_freelist_hook mm/slub.c:1470 [inline]
slab_free mm/slub.c:3012 [inline]
kfree+0xe4/0x2f0 mm/slub.c:3953
device_release+0x71/0x200 drivers/base/core.c:1064
kobject_cleanup lib/kobject.c:693 [inline]
kobject_release lib/kobject.c:722 [inline]
kref_put include/linux/kref.h:65 [inline]
kobject_put+0x171/0x280 lib/kobject.c:739
put_device+0x1b/0x30 drivers/base/core.c:2213
usb_put_dev+0x1f/0x30 drivers/usb/core/usb.c:725
yurex_delete+0x40/0x330 drivers/usb/misc/yurex.c:95
kref_put include/linux/kref.h:65 [inline]
yurex_release+0x66/0x90 drivers/usb/misc/yurex.c:392
__fput+0x2d7/0x840 fs/file_table.c:280
task_work_run+0x13f/0x1c0 kernel/task_work.c:113
tracehook_notify_resume include/linux/tracehook.h:188 [inline]
exit_to_usermode_loop+0x1d2/0x200 arch/x86/entry/common.c:163
prepare_exit_to_usermode arch/x86/entry/common.c:194 [inline]
syscall_return_slowpath arch/x86/entry/common.c:274 [inline]
do_syscall_64+0x45f/0x580 arch/x86/entry/common.c:299
entry_SYSCALL_64_after_hwframe+0x49/0xbe
The buggy address belongs to the object at ffff8881b1859980
which belongs to the cache kmalloc-2k of size 2048
The buggy address is located 72 bytes inside of
2048-byte region [ffff8881b1859980, ffff8881b185a180)
The buggy address belongs to the page:
page:ffffea0006c61600 refcount:1 mapcount:0 mapping:ffff8881da00c000
index:0x0 compound_mapcount: 0
flags: 0x200000000010200(slab|head)
raw: 0200000000010200 0000000000000000 0000000100000001 ffff8881da00c000
raw: 0000000000000000 00000000000f000f 00000001ffffffff 0000000000000000
page dumped because: kasan: bad access detected
Memory state around the buggy address:
ffff8881b1859880: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
ffff8881b1859900: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
> ffff8881b1859980: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
^
ffff8881b1859a00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
ffff8881b1859a80: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
==================================================================
A quick look at the yurex_delete() shows that we drop the reference
to the usb_device before releasing any buffers associated with the
device. Delay the reference drop until we have finished the cleanup.
[0] https://lore.kernel.org/lkml/0000000000003f86d8058f0bd671@google.com/
Fixes: 6bc235a2e24a5e ("USB: add driver for Meywa-Denki & Kayac YUREX")
Cc: Jiri Kosina <jkosina@suse.cz>
Cc: Tomoki Sekiyama <tomoki.sekiyama@gmail.com>
Cc: Oliver Neukum <oneukum@suse.com>
Cc: andreyknvl@google.com
Cc: gregkh@linuxfoundation.org
Cc: Alan Stern <stern@rowland.harvard.edu>
Cc: syzkaller-bugs@googlegroups.com
Cc: dtor@chromium.org
Reported-by: syzbot+d1fedb1c1fdb07fca507@syzkaller.appspotmail.com
Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com>
---
drivers/usb/misc/yurex.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/usb/misc/yurex.c b/drivers/usb/misc/yurex.c
index 7b306aa22d25..6715a128e6c8 100644
--- a/drivers/usb/misc/yurex.c
+++ b/drivers/usb/misc/yurex.c
@@ -92,7 +92,6 @@ static void yurex_delete(struct kref *kref)
dev_dbg(&dev->interface->dev, "%s\n", __func__);
- usb_put_dev(dev->udev);
if (dev->cntl_urb) {
usb_kill_urb(dev->cntl_urb);
kfree(dev->cntl_req);
@@ -108,6 +107,7 @@ static void yurex_delete(struct kref *kref)
dev->int_buffer, dev->urb->transfer_dma);
usb_free_urb(dev->urb);
}
+ usb_put_dev(dev->udev);
kfree(dev);
}
--
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
* Re: [PATCH v2 1/5] pinctrl: uniphier: Separate modem group from UART ctsrts group
From: Linus Walleij @ 2019-08-05 11:18 UTC (permalink / raw)
To: Kunihiko Hayashi
Cc: Masami Hiramatsu, Jassi Brar, open list:GPIO SUBSYSTEM,
linux-kernel@vger.kernel.org, Masahiro Yamada, Linux ARM
In-Reply-To: <1564465410-9165-2-git-send-email-hayashi.kunihiko@socionext.com>
On Tue, Jul 30, 2019 at 7:43 AM Kunihiko Hayashi
<hayashi.kunihiko@socionext.com> wrote:
> It depends on the board implementation whether to have each pins of
> CTS/RTS, and others for modem. So it is necessary to divide current
> uart_ctsrts group into uart_ctsrts and uart_modem groups.
>
> Since the number of implemented pins for modem differs depending
> on SoC, each uart_modem group also has a different number of pins.
>
> Signed-off-by: Kunihiko Hayashi <hayashi.kunihiko@socionext.com>
Patch applied with Masahiro's ACK.
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 v2 2/5] pinctrl: uniphier: Add another audio I/O pin-mux settings for LD20
From: Linus Walleij @ 2019-08-05 11:19 UTC (permalink / raw)
To: Kunihiko Hayashi
Cc: Masami Hiramatsu, Jassi Brar, open list:GPIO SUBSYSTEM,
linux-kernel@vger.kernel.org, Masahiro Yamada, Linux ARM
In-Reply-To: <1564465410-9165-3-git-send-email-hayashi.kunihiko@socionext.com>
On Tue, Jul 30, 2019 at 7:43 AM Kunihiko Hayashi
<hayashi.kunihiko@socionext.com> wrote:
> This adds support for pinmux settings of aout1b group. This group includes
> audio I/O signals derived from xirq pins, and it is equivalent to "aout1"
> in functionality.
>
> Signed-off-by: Kunihiko Hayashi <hayashi.kunihiko@socionext.com>
Patch applied with Masahiro's ACK.
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 v2 3/5] pinctrl: uniphier: Add 5th LD20 MPEG2-TS input pin-mux setting
From: Linus Walleij @ 2019-08-05 11:20 UTC (permalink / raw)
To: Kunihiko Hayashi
Cc: Masami Hiramatsu, Jassi Brar, open list:GPIO SUBSYSTEM,
linux-kernel@vger.kernel.org, Masahiro Yamada, Linux ARM
In-Reply-To: <1564465410-9165-4-git-send-email-hayashi.kunihiko@socionext.com>
On Tue, Jul 30, 2019 at 7:43 AM Kunihiko Hayashi
<hayashi.kunihiko@socionext.com> wrote:
> The 5th serial TS interface uses the following pins:
> hscin4_s: PCA[11-14]
>
> Signed-off-by: Kunihiko Hayashi <hayashi.kunihiko@socionext.com>
> Acked-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Patch applied.
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 v2 4/5] pinctrl: uniphier: Add Pro5 PCIe pin-mux settings
From: Linus Walleij @ 2019-08-05 11:21 UTC (permalink / raw)
To: Kunihiko Hayashi
Cc: Masami Hiramatsu, Jassi Brar, open list:GPIO SUBSYSTEM,
linux-kernel@vger.kernel.org, Masahiro Yamada, Linux ARM
In-Reply-To: <1564465410-9165-5-git-send-email-hayashi.kunihiko@socionext.com>
On Tue, Jul 30, 2019 at 7:43 AM Kunihiko Hayashi
<hayashi.kunihiko@socionext.com> wrote:
> Pro5 PCIe interface uses the following pins:
> XPERST, XPEWAKE, XPECLKRQ
>
> Signed-off-by: Kunihiko Hayashi <hayashi.kunihiko@socionext.com>
Patch applied with Masahiro's ACK.
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 v2 5/5] pinctrl: uniphier: Fix Pro5 SD pin-mux setting
From: Linus Walleij @ 2019-08-05 11:21 UTC (permalink / raw)
To: Kunihiko Hayashi
Cc: Masami Hiramatsu, Jassi Brar, open list:GPIO SUBSYSTEM,
linux-kernel@vger.kernel.org, Masahiro Yamada, Linux ARM
In-Reply-To: <1564465410-9165-6-git-send-email-hayashi.kunihiko@socionext.com>
On Tue, Jul 30, 2019 at 7:43 AM Kunihiko Hayashi
<hayashi.kunihiko@socionext.com> wrote:
> SD uses the following pins starting from 247:
> SDCD, SDWP, SDVOLC, SDCLK, SDCMD, SDDAT{0,1,2,3}
>
> Signed-off-by: Kunihiko Hayashi <hayashi.kunihiko@socionext.com>
> Acked-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Patch applied.
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: [linux-sunxi] [PATCH 2/3] rtc: sun6i: Add support for H6 RTC
From: Chen-Yu Tsai @ 2019-08-05 11:21 UTC (permalink / raw)
To: Ondřej Jirman, Chen-Yu Tsai, Alessandro Zummo,
Alexandre Belloni, Rob Herring, Mark Rutland, Maxime Ripard,
linux-rtc, devicetree, linux-arm-kernel, linux-kernel,
linux-sunxi
In-Reply-To: <20190805111037.76vmanzcurffpbdf@core.my.home>
On Mon, Aug 5, 2019 at 7:10 PM Ondřej Jirman <megous@megous.com> wrote:
>
> On Mon, Aug 05, 2019 at 06:54:17PM +0800, Chen-Yu Tsai wrote:
> > On Mon, Aug 5, 2019 at 6:45 PM Ondřej Jirman <megous@megous.com> wrote:
> > >
> > > On Mon, Aug 05, 2019 at 06:16:14PM +0800, Chen-Yu Tsai wrote:
> > > > On Fri, Apr 12, 2019 at 8:07 PM megous via linux-sunxi
> > > > <linux-sunxi@googlegroups.com> wrote:
> > > > >
> > > > > From: Ondrej Jirman <megous@megous.com>
> > > > >
> > > > > RTC on H6 is mostly the same as on H5 and H3. It has slight differences
> > > > > mostly in features that are not yet supported by this driver.
> > > > >
> > > > > Some differences are already stated in the comments in existing code.
> > > > > One other difference is that H6 has extra bit in LOSC_CTRL_REG, called
> > > > > EXT_LOSC_EN to enable/disable external low speed crystal oscillator.
> > > > >
> > > > > It also has bit EXT_LOSC_STA in LOSC_AUTO_SWT_STA_REG, to check whether
> > > > > external low speed oscillator is working correctly.
> > > > >
> > > > > This patch adds support for enabling LOSC when necessary:
> > > > >
> > > > > - during reparenting
> > > > > - when probing the clock
> > > > >
> > > > > H6 also has capacbility to automatically reparent RTC clock from
> > > > > external crystal oscillator, to internal RC oscillator, if external
> > > > > oscillator fails. This is enabled by default. Disable it during
> > > > > probe.
> > > > >
> > > > > Signed-off-by: Ondrej Jirman <megous@megous.com>
> > > > > ---
> > > > > drivers/rtc/rtc-sun6i.c | 40 ++++++++++++++++++++++++++++++++++++++--
> > > > > 1 file changed, 38 insertions(+), 2 deletions(-)
> > > > >
> > > > > diff --git a/drivers/rtc/rtc-sun6i.c b/drivers/rtc/rtc-sun6i.c
> > > > > index 11f56de52179..7375a530c565 100644
> > > > > --- a/drivers/rtc/rtc-sun6i.c
> > > > > +++ b/drivers/rtc/rtc-sun6i.c
> > > > > @@ -41,9 +41,11 @@
> > > > > /* Control register */
> > > > > #define SUN6I_LOSC_CTRL 0x0000
> > > > > #define SUN6I_LOSC_CTRL_KEY (0x16aa << 16)
> > > > > +#define SUN6I_LOSC_CTRL_AUTO_SWT_BYPASS BIT(15)
> > > >
> > > > Manual says bit 14? Or is this different from LOSC_AUTO_SWT_EN?
> > > >
> > > > The rest looks ok.
> > >
> > > To give you more information. This is a new thing in H6 BSP, compared
> > > to BSPs for previous SoCs (H5/H3).
> > >
> > > 20 #define REG_CLK32K_AUTO_SWT_EN BIT(14)
> > > 21 #define REG_CLK32K_AUTO_SWT_BYPASS BIT(15)
> > >
> > > Init sequence changed in H6 BSP to:
> > >
> > > 646 /*
> > > 647 * Step1: select RTC clock source
> > > 648 */
> > > 649 tmp_data = readl(chip->base + SUNXI_LOSC_CTRL);
> > > 650 tmp_data &= (~REG_CLK32K_AUTO_SWT_EN);
> > > 651
> > > 652 /* Disable auto switch function */
> > > 653 tmp_data |= REG_CLK32K_AUTO_SWT_BYPASS;
> > > 654 writel(tmp_data, chip->base + SUNXI_LOSC_CTRL);
> > > 655
> > > 656 tmp_data = readl(chip->base + SUNXI_LOSC_CTRL);
> > > 657 tmp_data |= (RTC_SOURCE_EXTERNAL | REG_LOSCCTRL_MAGIC);
> > > 658 writel(tmp_data, chip->base + SUNXI_LOSC_CTRL);
> > > 659
> > > 660 /* We need to set GSM after change clock source */
> > > 661 udelay(10);
> > > 662 tmp_data = readl(chip->base + SUNXI_LOSC_CTRL);
> > > 663 tmp_data |= (EXT_LOSC_GSM | REG_LOSCCTRL_MAGIC);
> > > 664 writel(tmp_data, chip->base + SUNXI_LOSC_CTRL);
> > > 665
> >
> > I don't have this in my H6 BSPs. One is H6 Lichee v1.1 downloaded from Pine64.
> > The link was from linux-sunxi wiki's H6 page.
> >
> > The other is a 4.9 kernel tree, which I believe is from Allwinner's github:
> >
> > https://github.com/Allwinner-Homlet/H6-BSP4.9-linux
>
> Interesting. :) I have the BSP I was using saved here:
>
> https://megous.com/git/linux/tree/drivers/rtc/rtc-sunxi.c?h=h6-4.9-bsp#n649
>
> It's based of 4.9.119
>
> https://megous.com/git/linux/log/?h=h6-4.9-bsp
>
> I don't remember where I found it. But I imported it fairly recently, and
> the code you pointed to looks like an older version that I can found in some
> beta H6 BSP, that I imported way earlier and is based on 4.9.56:
>
> https://megous.com/git/linux/tree/drivers/rtc/rtc-sunxi.c?h=linux-h6
> https://megous.com/git/linux/log/?h=linux-h6
>
> Hmm, archeology. :)
That's good enough for me. I suppose if we do have any more doubts we could
ask them directly.
Reviewed-by: Chen-Yu Tsai <wens@csie.org>
> > > For older BSPs, the init sequence looked like this:
> > >
> > > 482 /*
> > > 483 * Step1: select RTC clock source
> > > 484 */
> > > 485 tmp_data = sunxi_rtc_read(SUNXI_LOSC_CTRL_REG);
> > > 486 tmp_data &= (~REG_CLK32K_AUTO_SWT_EN);
> > > 487 tmp_data |= (RTC_SOURCE_EXTERNAL | REG_LOSCCTRL_MAGIC);
> > > 488 tmp_data |= (EXT_LOSC_GSM);
> > > 489 sunxi_rtc_write(tmp_data, SUNXI_LOSC_CTRL_REG);
> > > 490
> > >
> > > EXT_LOSC_GSM has values 4 values from low to high, and I guess it configures
> > > gain for the oscillator's amplifier in the feedback loop of the circuit.
> > >
> > > So the new code, for some reason changed from single write to sequence
> > > of individual writes/config steps:
> > >
> > > 1) disable auto-switch and enable auto-switch bypass
> > > 2) select RTC clock source (to LOSC)
> > > (wait)
> >
> > Maybe it's possible to glitch if these two are combined?
>
> That's what I thought too. Or the programmer thought so, and was just
> programming defensively, and there's no real problem in the practice.
>
> But that specific delay() seems like someone trying to solve a real issue. Of
> course there's no knowing if it was on H6 or on some other SoC.
It's probably for the clock waveform to stabilize. Why they do it _after_
switching to the clock is weird though.
> regards,
> o.
>
> >
> > > 3) configure gain on the LOSC
> > >
> > > regards,
> > > o.
> > >
> > > > ChenYu
> > >
> > > --
> > > You received this message because you are subscribed to the Google Groups "linux-sunxi" group.
> > > To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscribe@googlegroups.com.
> > > To view this discussion on the web, visit https://groups.google.com/d/msgid/linux-sunxi/20190805104529.z3mex3m2tss7lzlr%40core.my.home.
>
> --
> You received this message because you are subscribed to the Google Groups "linux-sunxi" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscribe@googlegroups.com.
> To view this discussion on the web, visit https://groups.google.com/d/msgid/linux-sunxi/20190805111037.76vmanzcurffpbdf%40core.my.home.
_______________________________________________
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] tracing: Function stack size and its name mismatch in arm64
From: Will Deacon @ 2019-08-05 11:25 UTC (permalink / raw)
To: Joel Fernandes
Cc: Jiping Ma, catalin.marinas, will.deacon, linux-kernel,
Steven Rostedt, takahiro.akashi, mingo, kernel-team,
linux-arm-kernel
In-Reply-To: <20190803082642.GA224541@google.com>
[+Akashi, since he may remember more of the gory details here]
On Sat, Aug 03, 2019 at 04:26:42AM -0400, Joel Fernandes wrote:
> On Fri, Aug 02, 2019 at 11:22:59AM -0400, Steven Rostedt wrote:
> [snip]
> > > There is not PC in ARM64 stack, LR is used to for walk_stackframe in
> > > ARM64. Tere is no the issue in ARM32 because there is PC in ARM32 stack.
> > > PC is used to calculate the stack size in trace_stack.c, so the
> > > function name and its stack size appear to be off-by-one.
> > > ARM64 stack layout:
> > > LR
> > > FP
> > > ......
> > > LR
> > > FP
> > > ......
> >
> > I think you are not explaining the issue correctly. From looking at the
> > document, I think what you want to say is that the LR is saved *after*
> > the data for the function. Is that correct? If so, then yes, it would
> > cause the stack tracing algorithm to be incorrect.
> >
> > Most archs do this:
> >
> > On entry to a function:
> >
> > save return address
> > reserve local variables and such for current function
> >
> > I think you are saying that arm64 does this backwards.
> >
> > reserve local variables and such for current function
> > save return address (LR)
>
> Actually for arm64 it is like what you said about 'Most archs'. It saves FP
> and LR first onto the current stack frame, then assigns the top of the stack
> to FP (marking the new frame). Then executes branch-link, and then allocates
> space to variables on stack in the callee.
>
> Disassembly of prog:
>
> int foo(int x, int y) {
> int a[32];
> return (x + y + a[31]);
> }
>
> int bar(void) {
> foo(1, 2);
> }
>
> confirms it:
>
> 000000000000073c <bar>:
> 73c: a9bf7bfd stp x29, x30, [sp, #-16]! <-- save FP and LR
> 740: 910003fd mov x29, sp <-- create new FP
> 744: 52800041 mov w1, #0x2 <-- pass arguments
> 748: 52800020 mov w0, #0x1
> 74c: 97fffff4 bl 71c <foo> <-- branch (sets LR)
> 750: d503201f nop
> 754: a8c17bfd ldp x29, x30, [sp], #16 <-- restore FP, LR
> 758: d65f03c0 ret
>
> 000000000000071c <foo>:
> 71c: d10243ff sub sp, sp, #0x90 <-- space for local var
> 720: b9000fe0 str w0, [sp, #12]
> 724: b9000be1 str w1, [sp, #8]
> 728: b9400fe1 ldr w1, [sp, #12]
> 72c: b9400be0 ldr w0, [sp, #8]
> 730: 0b000021 add w1, w1, w0
> 734: b9408fe0 ldr w0, [sp, #140]
> 738: 0b000020 add w0, w1, w0
> 73c: 910243ff add sp, sp, #0x90 <-- restore sp before ret
> 740: d65f03c0 ret
I think we need to untangle things a bit here.
The arm64 PCS makes no guarantee about the position of the frame record with
respect to stack allocations, so relying on this is fragile at best. This is
partly why the ftrace-with-regs work currently relies on
-fpatchable-function-entry, since that allows the very beginning of the
function to be intercepted which I don't think is necessarily the case with
-pg/_mcount.
For the snippet above, foo is a leaf function and does not have a frame record
placed on the stack. If we instead look at something like:
__attribute__((noinline)) int baz(int x)
{
return x;
}
__attribute__((noinline)) int bar(int x)
{
int a[32];
return baz(x * a[0]);
}
int foo(int x)
{
return bar(x);
}
then the first instruction of bar() allocates stack space and pushes
the frame record at the same time:
stp x29, x30, [sp, -144]!
This can be read as "subtract 144 bytes (32*4 + 16) from the stack pointer,
write the frame record there and then update the stack pointer to point at the
bottom of the newly allocated stack", which means that the array 'a[32]' sits
directly /above/ the frame record on the stack. However, this is just what my
GCC happened to do today. When we looked at this back in 2015, there were other
cases we ended up having to identify with heuristics based on what had been
observed under various compilers:
http://lists.infradead.org/pipermail/linux-arm-kernel/2015-December/393721.html
This was deemed to be far too fragile, so we didn't merge it in the end.
If this is to work reliably, then we need support from the tools. This was
raised when we first merged support for ftrace, but I'm not sure it went
anywhere:
https://gcc.gnu.org/ml/gcc/2016-01/msg00035.html
So, I completely agree with Steve that we shouldn't be littering the core code
with #ifdef CONFIG_ARM64, but we probably do need something in the arch backend
if we're going to do this properly, and that in turn is likely to need a very
different algorithm from the one currently in use.
Will
_______________________________________________
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 1/1] arm64: dts: rockchip: Add support for TB-96AI board
From: Manivannan Sadhasivam @ 2019-08-05 11:28 UTC (permalink / raw)
To: Elon Zhang
Cc: mark.rutland, devicetree, heiko, linux-kernel, linux-rockchip,
robh+dt, linux-arm-kernel
In-Reply-To: <20190805015755.26017-1-zhangzj@rock-chips.com>
Hi Elon,
Thanks for the v2. Still the DT needs to be cleaned up a bit. I have tested this
patch on TB96-AI SOM/Carrier board and found that the USB ports are not working
at all! Do we need to change any switch settings?
Comments are inline.
On Mon, Aug 05, 2019 at 09:57:55AM +0800, Elon Zhang wrote:
> Add devicetree support for RK3399Pro TB-96AI board, one of
> the 96Boards family.
>
> The TB-96AI board is a 96Boards Compute SOM design, launched
> by Linaro, Rockchip and Beiqicloud.
>
> More information can be obtained from the following websites:
> 1.https://www.96boards.org/product/tb-96ai/
> 2.http://t.rock-chips.com/
> 3.http://www.beiqicloud.com/
>
> This patch add basic node for the board and support booting up
> to Fedora.
>
> Signed-off-by: Elon Zhang <zhangzj@rock-chips.com>
> ---
> changes since v1:
> - remove needless node
> - using a standard LED formats for 96Boards
>
> arch/arm64/boot/dts/rockchip/Makefile | 1 +
> .../boot/dts/rockchip/rk3399pro-tb-96ai.dts | 560 ++++++++++++++++++
> 2 files changed, 561 insertions(+)
> create mode 100644 arch/arm64/boot/dts/rockchip/rk3399pro-tb-96ai.dts
>
> diff --git a/arch/arm64/boot/dts/rockchip/Makefile b/arch/arm64/boot/dts/rockchip/Makefile
> index 5f2687acbf94..3d6c8d4363b5 100644
> --- a/arch/arm64/boot/dts/rockchip/Makefile
> +++ b/arch/arm64/boot/dts/rockchip/Makefile
> @@ -27,3 +27,4 @@ dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3399-rock960.dtb
> dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3399-rockpro64.dtb
> dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3399-sapphire.dtb
> dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3399-sapphire-excavator.dtb
> +dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3399pro-tb-96ai.dtb
> diff --git a/arch/arm64/boot/dts/rockchip/rk3399pro-tb-96ai.dts b/arch/arm64/boot/dts/rockchip/rk3399pro-tb-96ai.dts
> new file mode 100644
> index 000000000000..767b37b854ba
> --- /dev/null
> +++ b/arch/arm64/boot/dts/rockchip/rk3399pro-tb-96ai.dts
> @@ -0,0 +1,560 @@
> +// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
> +/*
> + * Copyright (c) 2019 Fuzhou Rockchip Electronics Co., Ltd.
> + */
> +
> +/dts-v1/;
> +#include "rk3399pro.dtsi"
> +#include "rk3399-opp.dtsi"
> +
> +/ {
> + compatible = "beiqi,rk3399pro-tb-96ai", "rockchip,rk3399pro";
> +
> + chosen {
> + stdout-path = "serial2:1500000n8";
> + };
> +
> + xin32k: xin32k {
> + compatible = "fixed-clock";
> + clock-frequency = <32768>;
> + clock-output-names = "xin32k";
> + #clock-cells = <0>;
> + };
> +
> + vcc5v0_sys: vccsys {
> + compatible = "regulator-fixed";
> + regulator-name = "vcc5v0_sys";
> + regulator-always-on;
> + regulator-boot-on;
> + regulator-min-microvolt = <5000000>;
> + regulator-max-microvolt = <5000000>;
> + };
> +
> + leds {
Still the LEDs are not defined as per the format I shared before...
> + compatible = "gpio-leds";
> + pinctrl-names = "default";
> + pinctrl-0 = <&work_led1>,<&work_led2>,<&work_led3>;
> +
> + work_led1 {
> + gpios = <&gpio2 5 GPIO_ACTIVE_HIGH>;
> + label = "system_work_led1";
> + retain-state-suspended;
> + };
> +
> + work_led2 {
> + gpios = <&gpio2 4 GPIO_ACTIVE_HIGH>;
> + label = "system_work_led2";
> + retain-state-suspended;
> + };
> +
> + work_led3 {
> + gpios = <&gpio2 3 GPIO_ACTIVE_HIGH>;
> + label = "system_work_led3";
> + retain-state-suspended;
> + };
> + };
> +};
> +
> +&cpu_l0 {
> + cpu-supply = <&vdd_cpu_l>;
> +};
> +
> +&cpu_l1 {
> + cpu-supply = <&vdd_cpu_l>;
> +};
> +
> +&cpu_l2 {
> + cpu-supply = <&vdd_cpu_l>;
> +};
> +
> +&cpu_l3 {
> + cpu-supply = <&vdd_cpu_l>;
> +};
> +
> +&cpu_b0 {
> + cpu-supply = <&vdd_cpu_b>;
> +};
> +
> +&cpu_b1 {
> + cpu-supply = <&vdd_cpu_b>;
> +};
> +
> +&emmc_phy {
> + status = "okay";
> +};
> +
> +&i2c0 {
> + status = "okay";
> + i2c-scl-rising-time-ns = <180>;
> + i2c-scl-falling-time-ns = <30>;
> + clock-frequency = <400000>;
> +
> + rk809: pmic@20 {
> + compatible = "rockchip,rk809";
> + reg = <0x20>;
> + interrupt-parent = <&gpio1>;
> + interrupts = <RK_PC2 IRQ_TYPE_LEVEL_LOW>;
> + pinctrl-names = "default", "pmic-sleep",
> + "pmic-power-off", "pmic-reset";
Does these pinctrl configs useful other than default?
> + pinctrl-0 = <&pmic_int_l>;
> + pinctrl-1 = <&soc_slppin_slp>, <&rk809_slppin_slp>;
> + pinctrl-2 = <&soc_slppin_gpio>, <&rk809_slppin_pwrdn>;
> + pinctrl-3 = <&soc_slppin_gpio>,<&rk809_slppin_null>;
> + rockchip,system-power-controller;
> + pmic-reset-func = <1>;
> + wakeup-source;
> + #clock-cells = <1>;
> + clock-output-names = "rk808-clkout1", "rk808-clkout2";
> +
> + vcc1-supply = <&vcc5v0_sys>;
> + vcc2-supply = <&vcc5v0_sys>;
> + vcc3-supply = <&vcc5v0_sys>;
> + vcc4-supply = <&vcc5v0_sys>;
> + vcc5-supply = <&vcc_buck5>;
> + vcc6-supply = <&vcc_buck5>;
> + vcc7-supply = <&vcc3v3_sys>;
> + vcc8-supply = <&vcc3v3_sys>;
> + vcc9-supply = <&vcc5v0_sys>;
> +
> + pwrkey {
> + status = "okay";
No compatible needed?
> + };
> +
> + rtc {
> + status = "okay";
No compatible needed?
> + };
> +
> + pinctrl_rk8xx: pinctrl_rk8xx {
Mainline MFD driver has no pinctrl support for RK809.
> + gpio-controller;
> + #gpio-cells = <2>;
> +
> + rk809_slppin_null: rk809_slppin_null {
> + pins = "gpio_slp";
> + function = "pin_fun0";
> + };
> +
> + rk809_slppin_slp: rk809_slppin_slp {
> + pins = "gpio_slp";
> + function = "pin_fun1";
> + };
> +
> + rk809_slppin_pwrdn: rk809_slppin_pwrdn {
> + pins = "gpio_slp";
> + function = "pin_fun2";
> + };
> +
> + rk809_slppin_rst: rk809_slppin_rst {
> + pins = "gpio_slp";
> + function = "pin_fun3";
> + };
> + };
> +
> + regulators {
> + vdd_center: DCDC_REG1 {
> + regulator-always-on;
> + regulator-boot-on;
> + regulator-min-microvolt = <750000>;
> + regulator-max-microvolt = <1350000>;
> + regulator-initial-mode = <0x2>;
> + regulator-name = "vdd_center";
Please match the regulator names with schematic.
> + regulator-state-mem {
> + regulator-on-in-suspend;
> + regulator-suspend-microvolt = <900000>;
> + };
> + };
> +
> + vdd_cpu_l: DCDC_REG2 {
> + regulator-always-on;
> + regulator-boot-on;
> + regulator-min-microvolt = <750000>;
> + regulator-max-microvolt = <1350000>;
> + regulator-ramp-delay = <6001>;
> + regulator-initial-mode = <0x2>;
> + regulator-name = "vdd_cpu_l";
> + regulator-state-mem {
> + regulator-off-in-suspend;
> + };
> + };
> +
> + vcc_ddr: DCDC_REG3 {
> + regulator-always-on;
> + regulator-boot-on;
> + regulator-name = "vcc_ddr";
> + regulator-initial-mode = <0x2>;
> + regulator-state-mem {
> + regulator-on-in-suspend;
> + };
> + };
> +
> + vcc3v3_sys: DCDC_REG4 {
> + regulator-always-on;
> + regulator-boot-on;
> + regulator-min-microvolt = <3300000>;
> + regulator-max-microvolt = <3300000>;
> + regulator-initial-mode = <0x2>;
> + regulator-name = "vcc3v3_sys";
> + regulator-state-mem {
> + regulator-on-in-suspend;
> + regulator-suspend-microvolt = <3300000>;
> + };
> + };
> +
> + vcc_buck5: DCDC_REG5 {
> + regulator-always-on;
> + regulator-boot-on;
> + regulator-min-microvolt = <2200000>;
> + regulator-max-microvolt = <2200000>;
> + regulator-name = "vcc_buck5";
> + regulator-state-mem {
> + regulator-on-in-suspend;
> + regulator-suspend-microvolt = <2200000>;
> + };
> + };
> +
> + vcca_0v9: LDO_REG1 {
> + regulator-always-on;
> + regulator-boot-on;
> + regulator-min-microvolt = <900000>;
> + regulator-max-microvolt = <900000>;
> + regulator-name = "vcca_0v9";
> + regulator-state-mem {
> + regulator-off-in-suspend;
> + };
> + };
> +
> + vcc_1v8: LDO_REG2 {
> + regulator-always-on;
> + regulator-boot-on;
> + regulator-min-microvolt = <1800000>;
> + regulator-max-microvolt = <1800000>;
> +
> + regulator-name = "vcc_1v8";
> + regulator-state-mem {
> + regulator-on-in-suspend;
> + regulator-suspend-microvolt = <1800000>;
> + };
> + };
> +
> + vcc0v9_soc: LDO_REG3 {
> + regulator-always-on;
> + regulator-boot-on;
> + regulator-min-microvolt = <900000>;
> + regulator-max-microvolt = <900000>;
> +
> + regulator-name = "vcc0v9_soc";
> + regulator-state-mem {
> + regulator-on-in-suspend;
> + regulator-suspend-microvolt = <900000>;
> + };
> + };
> +
> + vcca_1v8: LDO_REG4 {
> + regulator-always-on;
> + regulator-boot-on;
> + regulator-min-microvolt = <1800000>;
> + regulator-max-microvolt = <1800000>;
> +
> + regulator-name = "vcca_1v8";
> + regulator-state-mem {
> + regulator-off-in-suspend;
> + };
> + };
> +
> + vdd1v5_dvp: LDO_REG5 {
> + regulator-always-on;
> + regulator-boot-on;
> + regulator-min-microvolt = <1500000>;
> + regulator-max-microvolt = <1500000>;
> +
> + regulator-name = "vdd1v5_dvp";
> + regulator-state-mem {
> + regulator-off-in-suspend;
> + };
> + };
> +
> + vcc_1v5: LDO_REG6 {
> + regulator-always-on;
> + regulator-boot-on;
> + regulator-min-microvolt = <1500000>;
> + regulator-max-microvolt = <1500000>;
> +
> + regulator-name = "vcc_1v5";
> + regulator-state-mem {
> + regulator-off-in-suspend;
> + };
> + };
> +
> + vcc_3v0: LDO_REG7 {
> + regulator-always-on;
> + regulator-boot-on;
> + regulator-min-microvolt = <3000000>;
> + regulator-max-microvolt = <3000000>;
> +
> + regulator-name = "vcc_3v0";
> + regulator-state-mem {
> + regulator-off-in-suspend;
> + };
> + };
> +
> + vccio_sd: LDO_REG8 {
> + regulator-always-on;
> + regulator-boot-on;
> + regulator-min-microvolt = <1800000>;
> + regulator-max-microvolt = <3300000>;
> +
> + regulator-name = "vccio_sd";
> + regulator-state-mem {
> + regulator-on-in-suspend;
> + regulator-suspend-microvolt = <3300000>;
> + };
> + };
> +
> + vcc_sd: LDO_REG9 {
> + regulator-always-on;
> + regulator-boot-on;
> + regulator-min-microvolt = <3300000>;
> + regulator-max-microvolt = <3300000>;
> +
> + regulator-name = "vcc_sd";
> + regulator-state-mem {
> + regulator-on-in-suspend;
> + regulator-suspend-microvolt = <3300000>;
> + };
> + };
> +
> + vcc5v0_usb: SWITCH_REG1 {
> + regulator-min-microvolt = <5000000>;
> + regulator-max-microvolt = <5000000>;
> +
> + regulator-name = "vcc5v0_usb";
> + regulator-state-mem {
> + regulator-off-in-suspend;
> + };
> + };
> +
> + vccio_3v3: SWITCH_REG2 {
> + regulator-always-on;
> + regulator-boot-on;
> + regulator-min-microvolt = <3300000>;
> + regulator-max-microvolt = <3300000>;
> +
> + regulator-name = "vccio_3v3";
> + regulator-state-mem {
> + regulator-off-in-suspend;
> + };
> + };
> + };
> + };
> +
> + vdd_cpu_b: regulator@1c {
> + compatible = "fcs,fan53555";
> + reg = <0x1c>;
> + vin-supply = <&vcc5v0_sys>;
> + pinctrl-0 = <&vsel1_gpio>;
> + vsel-gpios = <&gpio1 RK_PC1 GPIO_ACTIVE_HIGH>;
> + regulator-name = "vdd_cpu_b";
> + regulator-min-microvolt = <712500>;
> + regulator-max-microvolt = <1500000>;
> + regulator-ramp-delay = <2300>;
> + fcs,suspend-voltage-selector = <1>;
> + regulator-always-on;
> + regulator-boot-on;
> + regulator-initial-state = <3>;
> + regulator-state-mem {
> + regulator-off-in-suspend;
> + };
> + };
> +
> + vdd_gpu: regulator@10 {
> + compatible = "fcs,fan53555";
> + status = "okay";
> + reg = <0x10>;
> + vin-supply = <&vcc5v0_sys>;
> + pinctrl-0 = <&vsel2_gpio>;
> + vsel-gpios = <&gpio1 RK_PB6 GPIO_ACTIVE_HIGH>;
> + regulator-name = "vdd_gpu";
> + regulator-min-microvolt = <735000>;
> + regulator-max-microvolt = <1400000>;
> + regulator-ramp-delay = <2300>;
> + fcs,suspend-voltage-selector = <1>;
> + regulator-always-on;
> + regulator-boot-on;
> + regulator-state-mem {
> + regulator-off-in-suspend;
> + };
> + };
> +};
> +
> +&i2c8 {
> + status = "okay";
> + i2c-scl-rising-time-ns = <345>;
> + i2c-scl-falling-time-ns = <11>;
> + clock-frequency = <100000>;
> +};
> +
> +&io_domains {
> + status = "okay";
> + bt656-supply = <&vcca_1v8>; /* APIO2_VDD */
> + audio-supply = <&vcca_1v8>; /* APIO5_VDD */
> + sdmmc-supply = <&vccio_sd>; /* SDMMC0_VDD */
> + gpio1830-supply = <&vcc_1v8>; /* APIO4_VDD */
> +};
> +
> +&pinctrl {
> + pinctrl-names = "default";
> + pinctrl-0 = <&npu_ref_clk>;
> +
> + leds {
> + work_led1: work_led1 {
> + rockchip,pins =
> + <2 5 RK_FUNC_GPIO &pcfg_pull_none>;
> + };
> +
> + work_led2: work_led2 {
> + rockchip,pins =
> + <2 4 RK_FUNC_GPIO &pcfg_pull_none>;
> + };
> +
> + work_led3: work_led3 {
> + rockchip,pins =
> + <2 3 RK_FUNC_GPIO &pcfg_pull_none>;
> + };
> + };
> +
> + npu_clk {
> + npu_ref_clk: npu-ref-clk {
> + rockchip,pins =
> + <0 RK_PA2 1 &pcfg_pull_none>;
> + };
> + };
> +
> + pmic {
> + pmic_int_l: pmic-int-l {
> + rockchip,pins =
> + <1 RK_PC2 0 &pcfg_pull_up>;
> + };
> +
> + soc_slppin_gpio: soc-slppin-gpio {
> + rockchip,pins =
> + <1 RK_PA5 0 &pcfg_output_low>;
> + };
> +
> + soc_slppin_slp: soc-slppin-slp {
> + rockchip,pins =
> + <1 RK_PA5 1 &pcfg_pull_down>;
> + };
> +
> + vsel1_gpio: vsel1-gpio {
> + rockchip,pins =
> + <1 RK_PC1 0 &pcfg_pull_down>;
> + };
> +
> + vsel2_gpio: vsel2-gpio {
> + rockchip,pins =
> + <1 RK_PB6 0 &pcfg_pull_down>;
> + };
> + };
> +
> + usb3 {
> + usb3_host_en: usb3-host-en {
> + rockchip,pins =
> + <2 RK_PA2 RK_FUNC_GPIO &pcfg_output_high>;
> + };
> + };
> +};
> +
> +&pmu_io_domains {
> + status = "okay";
> + pmu1830-supply = <&vcc_1v8>;
> +};
> +
> +&pwm0 {
> + status = "okay";
> +};
> +
> +&pwm2 {
> + status = "okay";
> +};
> +
> +&saradc {
> + status = "okay";
> + vref-supply = <&vcc_1v8>;
> +};
> +
> +&sdhci {
> + bus-width = <8>;
> + mmc-hs400-1_8v;
> + non-removable;
> + keep-power-in-suspend;
> + mmc-hs400-enhanced-strobe;
> + status = "okay";
> +};
> +
> +&tcphy1 {
No tcphy0? I can see this used in schematics.
> + status = "okay";
> +};
> +
> +&tsadc {
> + rockchip,hw-tshut-mode = <1>; /* tshut mode 0:CRU 1:GPIO */
> + rockchip,hw-tshut-polarity = <1>; /* tshut polarity 0:LOW 1:HIGH */
> + status = "okay";
> +};
> +
> +&u2phy1 {
No u2phy0?
> + status = "okay";
> +
> + u2phy1_otg: otg-port {
> + status = "okay";
> + };
> +
> + u2phy1_host: host-port {
> + phy-supply = <&vcc5v0_usb>;
> + status = "okay";
> + };
> +};
> +
> +&uart0 {
> + pinctrl-names = "default";
> + pinctrl-0 = <&uart0_xfer &uart0_cts>;
> + status = "okay";
> +};
> +
> +&uart2 {
> + status = "okay";
> +};
> +
> +&uart4 {
> + status = "okay";
> +};
> +
> +&usb_host0_ehci {
> + status = "okay";
> +};
> +
> +&usb_host1_ehci {
> + status = "okay";
> +};
> +
> +&usb_host0_ohci {
> + status = "okay";
> +};
> +
> +&usb_host1_ohci {
> + status = "okay";
> +};
> +
> +&usbdrd3_1 {
> + status = "okay";
> + pinctrl-names = "default";
> + pinctrl-0 = <&usb3_host_en>;
> +};
> +
> +&usbdrd_dwc3_0 {
No usbdrd3_0?
Thanks,
Mani
> + status = "okay";
> +};
> +
> +&usbdrd_dwc3_1 {
> + snps,dis-u3-autosuspend-quirk;
> + status = "okay";
> +};
> +
> --
> 2.17.1
>
>
>
_______________________________________________
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 02/11] arm64: mm: Flip kernel VA space
From: Catalin Marinas @ 2019-08-05 11:29 UTC (permalink / raw)
To: Steve Capper
Cc: crecklin, ard.biesheuvel, maz, bhsharma, will, linux-arm-kernel
In-Reply-To: <20190729162117.832-3-steve.capper@arm.com>
On Mon, Jul 29, 2019 at 05:21:08PM +0100, Steve Capper wrote:
> diff --git a/arch/arm64/mm/dump.c b/arch/arm64/mm/dump.c
> index 82b3a7fdb4a6..6f0b9f8ddf55 100644
> --- a/arch/arm64/mm/dump.c
> +++ b/arch/arm64/mm/dump.c
> @@ -26,6 +26,8 @@
> #include <asm/ptdump.h>
>
> static const struct addr_marker address_markers[] = {
> + { PAGE_OFFSET, "Linear Mapping start" },
> + { VA_START, "Linear Mapping end" },
> #ifdef CONFIG_KASAN
> { KASAN_SHADOW_START, "Kasan shadow start" },
> { KASAN_SHADOW_END, "Kasan shadow end" },
> @@ -40,9 +42,8 @@ static const struct addr_marker address_markers[] = {
> { PCI_IO_END, "PCI I/O end" },
> #ifdef CONFIG_SPARSEMEM_VMEMMAP
> { VMEMMAP_START, "vmemmap start" },
> - { VMEMMAP_START + VMEMMAP_SIZE, "vmemmap end" },
> + { -1, "vmemmap end" },
Why not keep the original vmemmap end here? We even leave a 2MB gap.
--
Catalin
_______________________________________________
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] arm64: io: Relax implicit barriers in default I/O accessors
From: Will Deacon @ 2019-08-05 11:35 UTC (permalink / raw)
To: Catalin Marinas; +Cc: Will Deacon, linux-arm-kernel
In-Reply-To: <20190805103905.GC59981@iMac.local>
On Mon, Aug 05, 2019 at 11:39:05AM +0100, Catalin Marinas wrote:
> On Mon, Jul 29, 2019 at 06:05:18PM +0100, Will Deacon wrote:
> > As a concrete example, consider the following:
> >
> > memcpy(dma_buffer, data, bufsz);
> > writel(DMA_START, dev->ctrl_reg);
> >
> > A DMB ST instruction between the final write to the DMA buffer and the
> > write to the control register will ensure that the writes to the DMA
> > buffer are observed before the write to the control register by all
> > observers. Put another way, if an observer can see the write to the
> > control register, it can also see the writes to memory.
>
> I think one of the counter arguments here were that a device does not
> "observe" the write to the control register as that's not a master
> access (by the device). Do you mean that if another CPU (not the device)
> can observe the writel(), it would have also observed the write to the
> DMA buffer (assuming the DMB)? Since the device is also an observer of
> the DMA buffer accesses, the multi-copy atomicity ensures that the
> device is also seeing the buffer updates following a DMB.
Yes, that's right.
> > This has always
> > been the case and is not sufficient to provide the ordering required by
> > Linux, since there is no guarantee that the master interface of the
> > DMA-capable device has observed either of the accesses. However, in an
> > other-multi-copy atomic world, we can infer two things:
> >
> > 1. A write arriving at an endpoint shared between multiple CPUs is
> > visible to all CPUs
> >
> > 2. A write that is visible to all CPUs is also visible to all other
> > observers in the shareability domain
> >
> > Pieced together, this allows us to use DMB OSHST for our default I/O
> > write accessors and DMB OSHLD for our default I/O read accessors (the
> > outer-shareability is for handling non-cacheable mappings) for shared
> > devices. Memory-mapped, DMA-capable peripherals that are private to a
> > CPU (i.e. inaccessible to other CPUs) still require the DSB, however
> > these are few and far between and typically require special treatment
> > anyway which is outside of the scope of the portable driver API (e.g.
> > GIC, page-table walker, SPE profiler).
>
> I think there is another class of devices which are not CPU private
> (USB, network). The buffer here is on-chip and the CPU can't do much
> other than issuing a DSB (and even this may not be sufficient). The
> multi-copy atomicity rule would work between CPUs here but not
> necessarily for the device. Not sure they rely on the barrier in
> writel(), I guess we can wait and fix them with the mandatory barriers
> afterwards. In the meantime:
>
> Reviewed-by: Catalin Marinas <catalin.marinas@arm.com>
Thanks! I don't think that the on-chip case is too bad: either the device
observes updates like the CPUs (which would be necessary in order to
guarantee coherence with the CPU caches), or the buffer is really part of
the peripheral and mapped non-cacheable, so DMB would work for endpoint
ordering. I suppose you could imagine a magic, device-specific dance to
ensure visibility, but if that involves things like MMIO registers and
read-backs then you'll need mandatory barriers anyway.
Will
_______________________________________________
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] arm64/cache: fix -Woverride-init compiler warnings
From: Qian Cai @ 2019-08-05 11:47 UTC (permalink / raw)
To: Will Deacon; +Cc: Mark Rutland, Catalin Marinas, linux-kernel, linux-arm-kernel
In-Reply-To: <20190805095256.ocgdb2yfhnbdz6kw@willie-the-truck>
> On Aug 5, 2019, at 5:52 AM, Will Deacon <will@kernel.org> wrote:
>
> On Fri, Aug 02, 2019 at 11:32:24AM -0400, Qian Cai wrote:
>> The commit 155433cb365e ("arm64: cache: Remove support for ASID-tagged
>> VIVT I-caches") introduced some compiation warnings from GCC,
>>
>> arch/arm64/kernel/cpuinfo.c:38:26: warning: initialized field
>> overwritten [-Woverride-init]
>> [ICACHE_POLICY_VIPT] = "VIPT",
>> ^~~~~~
>> arch/arm64/kernel/cpuinfo.c:38:26: note: (near initialization for
>> 'icache_policy_str[2]')
>> arch/arm64/kernel/cpuinfo.c:39:26: warning: initialized field
>> overwritten [-Woverride-init]
>> [ICACHE_POLICY_PIPT] = "PIPT",
>> ^~~~~~
>> arch/arm64/kernel/cpuinfo.c:39:26: note: (near initialization for
>> 'icache_policy_str[3]')
>> arch/arm64/kernel/cpuinfo.c:40:27: warning: initialized field
>> overwritten [-Woverride-init]
>> [ICACHE_POLICY_VPIPT] = "VPIPT",
>> ^~~~~~~
>> arch/arm64/kernel/cpuinfo.c:40:27: note: (near initialization for
>> 'icache_policy_str[0]')
>>
>> because it initializes icache_policy_str[0 ... 3] twice.
>>
>> Fixes: 155433cb365e ("arm64: cache: Remove support for ASID-tagged VIVT I-caches")
>> Signed-off-by: Qian Cai <cai@lca.pw>
>> ---
>> arch/arm64/kernel/cpuinfo.c | 4 ++--
>> 1 file changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/arch/arm64/kernel/cpuinfo.c b/arch/arm64/kernel/cpuinfo.c
>> index 876055e37352..193b38da8d96 100644
>> --- a/arch/arm64/kernel/cpuinfo.c
>> +++ b/arch/arm64/kernel/cpuinfo.c
>> @@ -34,10 +34,10 @@
>> static struct cpuinfo_arm64 boot_cpu_data;
>>
>> static char *icache_policy_str[] = {
>> - [0 ... ICACHE_POLICY_PIPT] = "RESERVED/UNKNOWN",
>> + [ICACHE_POLICY_VPIPT] = "VPIPT",
>> + [ICACHE_POLICY_VPIPT + 1] = "RESERVED/UNKNOWN",
>> [ICACHE_POLICY_VIPT] = "VIPT",
>> [ICACHE_POLICY_PIPT] = "PIPT",
>> - [ICACHE_POLICY_VPIPT] = "VPIPT",
>
> I really don't like this patch. Using "[0 ... MAXIDX] = <default>" is a
> useful idiom and I think the code is more error-prone the way you have
> restructured it.
>
> Why are you passing -Woverride-init to the compiler anyway? There's only
> one Makefile that references that option, and it's specific to a pinctrl
> driver.
Those extra warnings can be enabled by “make W=1”. “-Woverride-init “ seems to be useful
to catch potential developer mistakes with unintented double-initializations. It is normal to
start to fix the most of false-positives first before globally enabling the flag by default just like
“-Wimplicit-fallthrough” mentioned in,
https://lwn.net/Articles/794944/
_______________________________________________
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 02/11] arm64: mm: Flip kernel VA space
From: Steve Capper @ 2019-08-05 11:50 UTC (permalink / raw)
To: Catalin Marinas
Cc: crecklin@redhat.com, ard.biesheuvel@linaro.org, maz@kernel.org,
bhsharma@redhat.com, nd, will@kernel.org,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <20190805112951.GE59981@iMac.local>
Hi Catalin,
On Mon, Aug 05, 2019 at 12:29:51PM +0100, Catalin Marinas wrote:
> On Mon, Jul 29, 2019 at 05:21:08PM +0100, Steve Capper wrote:
> > diff --git a/arch/arm64/mm/dump.c b/arch/arm64/mm/dump.c
> > index 82b3a7fdb4a6..6f0b9f8ddf55 100644
> > --- a/arch/arm64/mm/dump.c
> > +++ b/arch/arm64/mm/dump.c
> > @@ -26,6 +26,8 @@
> > #include <asm/ptdump.h>
> >
> > static const struct addr_marker address_markers[] = {
> > + { PAGE_OFFSET, "Linear Mapping start" },
> > + { VA_START, "Linear Mapping end" },
> > #ifdef CONFIG_KASAN
> > { KASAN_SHADOW_START, "Kasan shadow start" },
> > { KASAN_SHADOW_END, "Kasan shadow end" },
> > @@ -40,9 +42,8 @@ static const struct addr_marker address_markers[] = {
> > { PCI_IO_END, "PCI I/O end" },
> > #ifdef CONFIG_SPARSEMEM_VMEMMAP
> > { VMEMMAP_START, "vmemmap start" },
> > - { VMEMMAP_START + VMEMMAP_SIZE, "vmemmap end" },
> > + { -1, "vmemmap end" },
>
> Why not keep the original vmemmap end here? We even leave a 2MB gap.
Because I overlooked this when I added the 2MB gap :-), apologies, we
should keep the original vmemmap end.
Cheers,
--
Steve
_______________________________________________
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 v1 05/16] drm/fsl-dcu: fix opencoded use of drm_panel_*
From: Sam Ravnborg @ 2019-08-05 11:54 UTC (permalink / raw)
To: Stefan Agner
Cc: Neil Armstrong, David Airlie, dri-devel, Thierry Reding,
Laurent Pinchart, Marek Vasut, linux-samsung-soc, Sean Paul,
Allison Randal, Krzysztof Kozlowski, Jonathan Hunter,
Maxime Ripard, Kukjin Kim, NXP Linux Team, Sam Ravnborg,
Jonas Karlman, Alison Wang, Gwan-gyeong Mun, Alexios Zavras,
Laurent Pinchart, linux-tegra, Thomas Gleixner, Vincent Abriou,
linux-arm-kernel, Jernej Skrabec, Enrico Weigelt, Seung-Woo Kim,
Kyungmin Park, Pengutronix Kernel Team, Shawn Guo
In-Reply-To: <8567eb4c916a0b1d134bd62112a11903@agner.ch>
Hi Stefan.
Thanks for the feedback.
On Mon, Aug 05, 2019 at 11:16:26AM +0200, Stefan Agner wrote:
> On 2019-08-04 22:16, Sam Ravnborg wrote:
> > Use drm_panel_get_modes() to access modes.
> > This has a nice side effect to simplify the code.
> >
> > Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
> > Cc: Stefan Agner <stefan@agner.ch>
> > Cc: Alison Wang <alison.wang@nxp.com>
> > ---
> > drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_rgb.c | 10 +---------
> > 1 file changed, 1 insertion(+), 9 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_rgb.c
> > b/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_rgb.c
> > index 279d83eaffc0..a92fd6c70b09 100644
> > --- a/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_rgb.c
> > +++ b/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_rgb.c
> > @@ -65,17 +65,9 @@ static const struct drm_connector_funcs
> > fsl_dcu_drm_connector_funcs = {
> > static int fsl_dcu_drm_connector_get_modes(struct drm_connector *connector)
> > {
> > struct fsl_dcu_drm_connector *fsl_connector;
> > - int (*get_modes)(struct drm_panel *panel);
> > - int num_modes = 0;
> >
> > fsl_connector = to_fsl_dcu_connector(connector);
> > - if (fsl_connector->panel && fsl_connector->panel->funcs &&
> > - fsl_connector->panel->funcs->get_modes) {
> > - get_modes = fsl_connector->panel->funcs->get_modes;
> > - num_modes = get_modes(fsl_connector->panel);
> > - }
> > -
> > - return num_modes;
> > + return drm_panel_get_modes(fsl_connector->panel);
>
> Oh, that old code looks rather messy. Thanks for the simplification!
>
> This behaves slightly different since it now returns -EINVAL or -ENOSYS,
> but that is what we want.
You are right, and I will add this to the changelog when I apply.
Sam
_______________________________________________
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