* [PATCH v1 07/16] drm/mxsfb: fix opencoded use of drm_panel_*
From: Sam Ravnborg @ 2019-08-04 20:16 UTC (permalink / raw)
To: dri-devel, Thierry Reding
Cc: Neil Armstrong, David Airlie, Linus Walleij, Stefan Agner,
Andrzej Hajda, Laurent Pinchart, Benjamin Gaignard, Fabio Estevam,
Marek Vasut, Laurent Pinchart, Joonyoung Shim, Sam Ravnborg,
Krzysztof Kozlowski, Jonathan Hunter, Maxime Ripard, Kukjin Kim,
Allison Randal, 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, linux-tegra, Thomas Gleixner, Sean Paul,
linux-arm-kernel, Jernej Skrabec, Shawn Guo, Seung-Woo Kim,
Vincent Abriou, Kyungmin Park, Daniel Vetter, Enrico Weigelt
In-Reply-To: <20190804201637.1240-1-sam@ravnborg.org>
Use the drm_panel_get_modes() function.
Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
Cc: Marek Vasut <marex@denx.de>
Cc: Stefan Agner <stefan@agner.ch>
Cc: Shawn Guo <shawnguo@kernel.org>
Cc: Sascha Hauer <s.hauer@pengutronix.de>
Cc: Pengutronix Kernel Team <kernel@pengutronix.de>
Cc: Fabio Estevam <festevam@gmail.com>
Cc: NXP Linux Team <linux-imx@nxp.com>
Cc: linux-arm-kernel@lists.infradead.org
---
drivers/gpu/drm/mxsfb/mxsfb_out.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/mxsfb/mxsfb_out.c b/drivers/gpu/drm/mxsfb/mxsfb_out.c
index 231d016c6f47..be36f4d6cc96 100644
--- a/drivers/gpu/drm/mxsfb/mxsfb_out.c
+++ b/drivers/gpu/drm/mxsfb/mxsfb_out.c
@@ -30,7 +30,7 @@ static int mxsfb_panel_get_modes(struct drm_connector *connector)
drm_connector_to_mxsfb_drm_private(connector);
if (mxsfb->panel)
- return mxsfb->panel->funcs->get_modes(mxsfb->panel);
+ return drm_panel_get_modes(mxsfb->panel);
return 0;
}
--
2.20.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v1 06/16] drm/msm: fix opencoded use of drm_panel_*
From: Sam Ravnborg @ 2019-08-04 20:16 UTC (permalink / raw)
To: dri-devel, Thierry Reding
Cc: Neil Armstrong, David Airlie, Linus Walleij, Stefan Agner,
Andrzej Hajda, Laurent Pinchart, Benjamin Gaignard, Fabio Estevam,
Marek Vasut, Laurent Pinchart, Joonyoung Shim, Sam Ravnborg,
Krzysztof Kozlowski, Jonathan Hunter, Maxime Ripard, Kukjin Kim,
Allison Randal, 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, linux-tegra, Thomas Gleixner, Sean Paul,
linux-arm-kernel, Jernej Skrabec, Shawn Guo, Seung-Woo Kim,
Vincent Abriou, Kyungmin Park, Daniel Vetter, Enrico Weigelt
In-Reply-To: <20190804201637.1240-1-sam@ravnborg.org>
Use the function drm_panel_get_modes().
Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
Cc: Alexios Zavras <alexios.zavras@intel.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Allison Randal <allison@lohutok.net>
Cc: Sam Ravnborg <sam@ravnborg.org>
Cc: Enrico Weigelt <info@metux.net>
---
drivers/gpu/drm/msm/disp/mdp4/mdp4_lvds_connector.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/msm/disp/mdp4/mdp4_lvds_connector.c b/drivers/gpu/drm/msm/disp/mdp4/mdp4_lvds_connector.c
index ecef4f5b9f26..0e21252fd1d6 100644
--- a/drivers/gpu/drm/msm/disp/mdp4/mdp4_lvds_connector.c
+++ b/drivers/gpu/drm/msm/disp/mdp4/mdp4_lvds_connector.c
@@ -55,7 +55,7 @@ static int mdp4_lvds_connector_get_modes(struct drm_connector *connector)
if (panel) {
drm_panel_attach(panel, connector);
- ret = panel->funcs->get_modes(panel);
+ ret = drm_panel_get_modes(panel);
drm_panel_detach(panel);
}
--
2.20.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v1 05/16] drm/fsl-dcu: fix opencoded use of drm_panel_*
From: Sam Ravnborg @ 2019-08-04 20:16 UTC (permalink / raw)
To: dri-devel, Thierry Reding
Cc: Neil Armstrong, David Airlie, Linus Walleij, Stefan Agner,
Andrzej Hajda, Laurent Pinchart, Benjamin Gaignard, Fabio Estevam,
Marek Vasut, Laurent Pinchart, Joonyoung Shim, Sam Ravnborg,
Krzysztof Kozlowski, Jonathan Hunter, Maxime Ripard, Kukjin Kim,
Allison Randal, 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, linux-tegra, Thomas Gleixner, Sean Paul,
linux-arm-kernel, Jernej Skrabec, Shawn Guo, Seung-Woo Kim,
Vincent Abriou, Kyungmin Park, Daniel Vetter, Enrico Weigelt
In-Reply-To: <20190804201637.1240-1-sam@ravnborg.org>
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);
}
static int fsl_dcu_drm_connector_mode_valid(struct drm_connector *connector,
--
2.20.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v1 04/16] drm/imx: fix opencoded use of drm_panel_*
From: Sam Ravnborg @ 2019-08-04 20:16 UTC (permalink / raw)
To: dri-devel, Thierry Reding
Cc: Neil Armstrong, David Airlie, Linus Walleij, Stefan Agner,
Andrzej Hajda, Laurent Pinchart, Benjamin Gaignard, Fabio Estevam,
Marek Vasut, Laurent Pinchart, Joonyoung Shim, Sam Ravnborg,
Krzysztof Kozlowski, Jonathan Hunter, Maxime Ripard, Kukjin Kim,
Allison Randal, 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, linux-tegra, Thomas Gleixner, Sean Paul,
linux-arm-kernel, Jernej Skrabec, Shawn Guo, Seung-Woo Kim,
Vincent Abriou, Kyungmin Park, Daniel Vetter, Enrico Weigelt
In-Reply-To: <20190804201637.1240-1-sam@ravnborg.org>
Use the drm_panel_get_modes() function to get the modes.
This patch leave one test for the function pointer:
panel->funcs->get_modes
This is used to check if the panel may have any modes.
There is no direct replacement.
We may be able to just check that drm_panel_get_modes() return > 0,
but as this is not the same functionality it is left for later.
Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
Cc: Philipp Zabel <p.zabel@pengutronix.de>
Cc: Shawn Guo <shawnguo@kernel.org>
Cc: Sascha Hauer <s.hauer@pengutronix.de>
Cc: Pengutronix Kernel Team <kernel@pengutronix.de>
Cc: Fabio Estevam <festevam@gmail.com>
Cc: NXP Linux Team <linux-imx@nxp.com>
Cc: linux-arm-kernel@lists.infradead.org
---
drivers/gpu/drm/imx/imx-ldb.c | 11 ++++-------
drivers/gpu/drm/imx/parallel-display.c | 11 ++++-------
2 files changed, 8 insertions(+), 14 deletions(-)
diff --git a/drivers/gpu/drm/imx/imx-ldb.c b/drivers/gpu/drm/imx/imx-ldb.c
index db461b6a257f..695f307f36b2 100644
--- a/drivers/gpu/drm/imx/imx-ldb.c
+++ b/drivers/gpu/drm/imx/imx-ldb.c
@@ -124,14 +124,11 @@ static void imx_ldb_ch_set_bus_format(struct imx_ldb_channel *imx_ldb_ch,
static int imx_ldb_connector_get_modes(struct drm_connector *connector)
{
struct imx_ldb_channel *imx_ldb_ch = con_to_imx_ldb_ch(connector);
- int num_modes = 0;
+ int num_modes;
- if (imx_ldb_ch->panel && imx_ldb_ch->panel->funcs &&
- imx_ldb_ch->panel->funcs->get_modes) {
- num_modes = imx_ldb_ch->panel->funcs->get_modes(imx_ldb_ch->panel);
- if (num_modes > 0)
- return num_modes;
- }
+ num_modes = drm_panel_get_modes(imx_ldb_ch->panel);
+ if (num_modes > 0)
+ return num_modes;
if (!imx_ldb_ch->edid && imx_ldb_ch->ddc)
imx_ldb_ch->edid = drm_get_edid(connector, imx_ldb_ch->ddc);
diff --git a/drivers/gpu/drm/imx/parallel-display.c b/drivers/gpu/drm/imx/parallel-display.c
index 2e51b2fade75..e7ce17503ae1 100644
--- a/drivers/gpu/drm/imx/parallel-display.c
+++ b/drivers/gpu/drm/imx/parallel-display.c
@@ -47,14 +47,11 @@ static int imx_pd_connector_get_modes(struct drm_connector *connector)
{
struct imx_parallel_display *imxpd = con_to_imxpd(connector);
struct device_node *np = imxpd->dev->of_node;
- int num_modes = 0;
+ int num_modes;
- if (imxpd->panel && imxpd->panel->funcs &&
- imxpd->panel->funcs->get_modes) {
- num_modes = imxpd->panel->funcs->get_modes(imxpd->panel);
- if (num_modes > 0)
- return num_modes;
- }
+ num_modes = drm_panel_get_modes(imxpd->panel);
+ if (num_modes > 0)
+ return num_modes;
if (imxpd->edid) {
drm_connector_update_edid_property(connector, imxpd->edid);
--
2.20.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v1 03/16] drm/exynos: fix opencoded use of drm_panel_*
From: Sam Ravnborg @ 2019-08-04 20:16 UTC (permalink / raw)
To: dri-devel, Thierry Reding
Cc: Neil Armstrong, David Airlie, Linus Walleij, Stefan Agner,
Andrzej Hajda, Laurent Pinchart, Benjamin Gaignard, Fabio Estevam,
Marek Vasut, Laurent Pinchart, Joonyoung Shim, Sam Ravnborg,
Krzysztof Kozlowski, Jonathan Hunter, Maxime Ripard, Kukjin Kim,
Allison Randal, 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, linux-tegra, Thomas Gleixner, Sean Paul,
linux-arm-kernel, Jernej Skrabec, Shawn Guo, Seung-Woo Kim,
Vincent Abriou, Kyungmin Park, Daniel Vetter, Enrico Weigelt
In-Reply-To: <20190804201637.1240-1-sam@ravnborg.org>
Call via drm_panel_get_modes().
Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
Cc: Inki Dae <inki.dae@samsung.com>
Cc: Joonyoung Shim <jy0922.shim@samsung.com>
Cc: Seung-Woo Kim <sw0312.kim@samsung.com>
Cc: Kyungmin Park <kyungmin.park@samsung.com>
Cc: Kukjin Kim <kgene@kernel.org>
Cc: Krzysztof Kozlowski <krzk@kernel.org>
Cc: linux-arm-kernel@lists.infradead.org
Cc: linux-samsung-soc@vger.kernel.org
---
drivers/gpu/drm/exynos/exynos_drm_dsi.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_dsi.c b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
index 6926cee91b36..36b02b456d9c 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
@@ -1460,7 +1460,7 @@ static int exynos_dsi_get_modes(struct drm_connector *connector)
struct exynos_dsi *dsi = connector_to_dsi(connector);
if (dsi->panel)
- return dsi->panel->funcs->get_modes(dsi->panel);
+ return drm_panel_get_modes(dsi->panel);
return 0;
}
--
2.20.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v1 02/16] drm/exynos: fix opencoded use of drm_panel_*
From: Sam Ravnborg @ 2019-08-04 20:16 UTC (permalink / raw)
To: dri-devel, Thierry Reding
Cc: Neil Armstrong, David Airlie, Linus Walleij, Stefan Agner,
Andrzej Hajda, Laurent Pinchart, Benjamin Gaignard, Fabio Estevam,
Marek Vasut, Laurent Pinchart, Joonyoung Shim, Sam Ravnborg,
Krzysztof Kozlowski, Jonathan Hunter, Maxime Ripard, Kukjin Kim,
Allison Randal, 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, linux-tegra, Thomas Gleixner, Sean Paul,
linux-arm-kernel, Jernej Skrabec, Shawn Guo, Seung-Woo Kim,
Vincent Abriou, Kyungmin Park, Daniel Vetter, Enrico Weigelt
In-Reply-To: <20190804201637.1240-1-sam@ravnborg.org>
drm_panel_attach() will check if there is a controller
already attached - drop the check in the driver.
Use drm_panel_get_modes() so the driver no longer uses the function
pointer.
Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
Cc: Inki Dae <inki.dae@samsung.com>
Cc: Joonyoung Shim <jy0922.shim@samsung.com>
Cc: Seung-Woo Kim <sw0312.kim@samsung.com>
Cc: Kyungmin Park <kyungmin.park@samsung.com>
Cc: Kukjin Kim <kgene@kernel.org>
Cc: Krzysztof Kozlowski <krzk@kernel.org>
Cc: linux-arm-kernel@lists.infradead.org
Cc: linux-samsung-soc@vger.kernel.org
---
drivers/gpu/drm/exynos/exynos_drm_dpi.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_dpi.c b/drivers/gpu/drm/exynos/exynos_drm_dpi.c
index 3cebb19ec1c4..5479ff71cbc6 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_dpi.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_dpi.c
@@ -43,7 +43,7 @@ exynos_dpi_detect(struct drm_connector *connector, bool force)
{
struct exynos_dpi *ctx = connector_to_dpi(connector);
- if (ctx->panel && !ctx->panel->connector)
+ if (ctx->panel)
drm_panel_attach(ctx->panel, &ctx->connector);
return connector_status_connected;
@@ -85,7 +85,7 @@ static int exynos_dpi_get_modes(struct drm_connector *connector)
}
if (ctx->panel)
- return ctx->panel->funcs->get_modes(ctx->panel);
+ return drm_panel_get_modes(ctx->panel);
return 0;
}
--
2.20.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v1 01/16] drm/bridge: tc358767: fix opencoded use of drm_panel_*
From: Sam Ravnborg @ 2019-08-04 20:16 UTC (permalink / raw)
To: dri-devel, Thierry Reding
Cc: Neil Armstrong, David Airlie, Linus Walleij, Stefan Agner,
Andrzej Hajda, Laurent Pinchart, Benjamin Gaignard, Fabio Estevam,
Marek Vasut, Laurent Pinchart, Joonyoung Shim, Sam Ravnborg,
Krzysztof Kozlowski, Jonathan Hunter, Maxime Ripard, Kukjin Kim,
Allison Randal, 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, linux-tegra, Thomas Gleixner, Sean Paul,
linux-arm-kernel, Jernej Skrabec, Shawn Guo, Seung-Woo Kim,
Vincent Abriou, Kyungmin Park, Daniel Vetter, Enrico Weigelt
In-Reply-To: <20190804201637.1240-1-sam@ravnborg.org>
Replace open coded version with call to drm_panel_get_modes().
Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
Cc: Andrzej Hajda <a.hajda@samsung.com>
Cc: Neil Armstrong <narmstrong@baylibre.com>
Cc: Laurent Pinchart <Laurent.pinchart@ideasonboard.com>
Cc: Jonas Karlman <jonas@kwiboo.se>
Cc: Jernej Skrabec <jernej.skrabec@siol.net>
---
drivers/gpu/drm/bridge/tc358767.c | 10 ++++------
1 file changed, 4 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/bridge/tc358767.c b/drivers/gpu/drm/bridge/tc358767.c
index 42f03a985ac0..cebc8e620820 100644
--- a/drivers/gpu/drm/bridge/tc358767.c
+++ b/drivers/gpu/drm/bridge/tc358767.c
@@ -1312,7 +1312,7 @@ static int tc_connector_get_modes(struct drm_connector *connector)
{
struct tc_data *tc = connector_to_tc(connector);
struct edid *edid;
- unsigned int count;
+ int count;
int ret;
ret = tc_get_display_props(tc);
@@ -1321,11 +1321,9 @@ static int tc_connector_get_modes(struct drm_connector *connector)
return 0;
}
- if (tc->panel && tc->panel->funcs && tc->panel->funcs->get_modes) {
- count = tc->panel->funcs->get_modes(tc->panel);
- if (count > 0)
- return count;
- }
+ count = drm_panel_get_modes(tc->panel);
+ if (count > 0)
+ return count;
edid = drm_get_edid(connector, &tc->aux.ddc);
--
2.20.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v1 0/16] drm: panel related updates
From: Sam Ravnborg @ 2019-08-04 20:16 UTC (permalink / raw)
To: dri-devel, Thierry Reding
Cc: Neil Armstrong, David Airlie, Linus Walleij, Stefan Agner,
Andrzej Hajda, Laurent Pinchart, Benjamin Gaignard, Fabio Estevam,
Marek Vasut, Laurent Pinchart, Joonyoung Shim, Sam Ravnborg,
Krzysztof Kozlowski, Jonathan Hunter, Maxime Ripard, Kukjin Kim,
Allison Randal, 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, linux-tegra, Thomas Gleixner, Sean Paul,
linux-arm-kernel, Jernej Skrabec, Shawn Guo, Seung-Woo Kim,
Vincent Abriou, Kyungmin Park, Daniel Vetter, Enrico Weigelt
The first 9 patches replaces direct use of the drm_panel
function pointers with their drm_panel_* counterparts.
The function pointers are only supposed to be used by
the drm_panel infrastructure and direct use are discouraged.
ili9322 is updated to handle bus_flags in get_modes like everyone else.
This is in preparation for a later patch series where controller
becomes an arugument to get_modes() and not like today where drm_panel
is attached to a controller.
The remaining patches move functionality to the drm_panel core that
today are repeated in many drivers.
As preparation for this the inline functions are moved to drm_panel.c
and kernel-doc is made inline.
panel-simple is updated to benefit from the additional infrastructure
and is an example for the simplifications that can be done.
The patchset has been tested on my embedded target,
and build tested.
Feedback welcome!
The "fix opencoded" patches are all independent and can be applied
out of order. They were kept here to keep panel related patches in one series.
Sam
Cc: Alexios Zavras <alexios.zavras@intel.com>
Cc: Alison Wang <alison.wang@nxp.com>
Cc: Allison Randal <allison@lohutok.net>
Cc: Andrzej Hajda <a.hajda@samsung.com>
Cc: Benjamin Gaignard <benjamin.gaignard@linaro.org>
Cc: Daniel Vetter <daniel@ffwll.ch>
Cc: David Airlie <airlied@linux.ie>
Cc: Enrico Weigelt <info@metux.net>
Cc: Fabio Estevam <festevam@gmail.com>
Cc: Gwan-gyeong Mun <gwan-gyeong.mun@intel.com>
Cc: Inki Dae <inki.dae@samsung.com>
Cc: Jernej Skrabec <jernej.skrabec@siol.net>
Cc: Jonas Karlman <jonas@kwiboo.se>
Cc: Jonathan Hunter <jonathanh@nvidia.com>
Cc: Joonyoung Shim <jy0922.shim@samsung.com>
Cc: Krzysztof Kozlowski <krzk@kernel.org>
Cc: Kukjin Kim <kgene@kernel.org>
Cc: Kyungmin Park <kyungmin.park@samsung.com>
Cc: Laurent Pinchart <Laurent.pinchart@ideasonboard.com>
Cc: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Cc: Linus Walleij <linus.walleij@linaro.org>
Cc: linux-arm-kernel@lists.infradead.org
Cc: linux-samsung-soc@vger.kernel.org
Cc: linux-tegra@vger.kernel.org
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Cc: Marek Vasut <marex@denx.de>
Cc: Maxime Ripard <maxime.ripard@bootlin.com>
Cc: Neil Armstrong <narmstrong@baylibre.com>
Cc: NXP Linux Team <linux-imx@nxp.com>
Cc: Pengutronix Kernel Team <kernel@pengutronix.de>
Cc: Philipp Zabel <p.zabel@pengutronix.de>
Cc: Sam Ravnborg <sam@ravnborg.org>
Cc: Sascha Hauer <s.hauer@pengutronix.de>
Cc: Sean Paul <sean@poorly.run>
Cc: Seung-Woo Kim <sw0312.kim@samsung.com>
Cc: Shawn Guo <shawnguo@kernel.org>
Cc: Stefan Agner <stefan@agner.ch>
Cc: Thierry Reding <thierry.reding@gmail.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Vincent Abriou <vincent.abriou@st.com>
Sam Ravnborg (16):
drm/bridge: tc358767: fix opencoded use of drm_panel_*
drm/exynos: fix opencoded use of drm_panel_*
drm/exynos: fix opencoded use of drm_panel_*
drm/imx: fix opencoded use of drm_panel_*
drm/fsl-dcu: fix opencoded use of drm_panel_*
drm/msm: fix opencoded use of drm_panel_*
drm/mxsfb: fix opencoded use of drm_panel_*
drm/sti: fix opencoded use of drm_panel_*
drm/tegra: fix opencoded use of drm_panel_*
drm/panel: ili9322: move bus_flags to get_modes()
drm/panel: move drm_panel functions to .c file
drm/panel: use inline comments in drm_panel.h
drm/panel: drop return code from drm_panel_detach()
drm/panel: call prepare/enable only once
drm/panel: add backlight support
drm/panel: simple: use drm_panel infrastructure
drivers/gpu/drm/bridge/analogix/analogix_dp_core.c | 3 +-
drivers/gpu/drm/bridge/tc358767.c | 10 +-
drivers/gpu/drm/drm_panel.c | 185 ++++++++++++++++-
drivers/gpu/drm/exynos/exynos_drm_dpi.c | 4 +-
drivers/gpu/drm/exynos/exynos_drm_dsi.c | 2 +-
drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_rgb.c | 10 +-
drivers/gpu/drm/imx/imx-ldb.c | 11 +-
drivers/gpu/drm/imx/parallel-display.c | 11 +-
.../gpu/drm/msm/disp/mdp4/mdp4_lvds_connector.c | 2 +-
drivers/gpu/drm/mxsfb/mxsfb_out.c | 2 +-
drivers/gpu/drm/panel/panel-ilitek-ili9322.c | 34 ++-
drivers/gpu/drm/panel/panel-simple.c | 73 +------
drivers/gpu/drm/sti/sti_dvo.c | 8 +-
drivers/gpu/drm/tegra/output.c | 2 +-
include/drm/drm_panel.h | 227 +++++++++++----------
15 files changed, 349 insertions(+), 235 deletions(-)
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 1/3] RFT: drm/pl111: Support grayscale
From: Fabian Vogt @ 2019-08-04 20:13 UTC (permalink / raw)
To: Linus Walleij; +Cc: Daniel Tang, open list:DRM PANEL DRIVERS, Linux ARM
In-Reply-To: <CACRpkda-5xu2-X5yo=dXchSvuD=ZmZSpTbGNrkv6V+UKs27xWA@mail.gmail.com>
Hi,
Am Samstag, 3. August 2019, 11:51:59 CEST schrieb Linus Walleij:
> On Thu, Jul 25, 2019 at 9:26 PM Fabian Vogt <fabian@ritter-vogt.de> wrote:
>
> > On a real CX the LCD displays shows content without
> > any other changes to the set, but has a ~3Hz pulsating effect scrolling from
> > the top to the bottom and the gray text changes color slightly.
>
> So you mean something meaningful appears in the LCD
> but there are visual disturbances?
>
> > Without the patchset applied everything looks perfectly.
> >
> > I tried setting vrefresh to 20, fb_bpp to 16 and forcing an inverted panel
> > clock, but the pulsing didn't change.
> >
> > Using the emulated CX I compared the contents of the registers and found
> > that only the IPC bit (which I tried to set, so that's likely not it) and
> > the interrupt registers have a different content.
> >
> > Any idea?
>
> I think it's the clock settings in patch 2/3.
>
> I just set them to "1000" (1MHz since its in kHz) based on some
> educated guesses.
>
> The old driver set the clock to "1" (kHz) so just try that first,
> maybe it is really that slow.
Did that, it looked rather unhealthy for the LCD. Mostly white with some
glitching except for ~2-3 lines with content scrolling on the screen.
200kHz was still way to slow, so tried the opposite direction.
With a clock of 10MHz the display seems to be working fine and produces a
visibly stable output.
Thanks,
Fabian
> It's just that the old driver also set refres to 60 fps which doesn't
> add up, but I think that setting is simply ignored and that is why
> it works.
>
> Yours,
> Linus Walleij
---
diff --git a/drivers/gpu/drm/panel/panel-simple.c b/drivers/gpu/drm/panel/panel-simple.c
index e5cfe1398a3b..3addcdab8adb 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -2763,7 +2763,7 @@ static const struct panel_desc arm_rtsm = {
static const struct drm_display_mode nspire_cx_lcd_mode[] = {
{
- .clock = 1000,
+ .clock = 10000,
.hdisplay = 320,
.hsync_start = 320 + 50,
.hsync_end = 320 + 50 + 6,
@@ -2791,7 +2791,7 @@ static const struct panel_desc nspire_cx_lcd_panel = {
static const struct drm_display_mode nspire_classic_lcd_mode[] = {
{
- .clock = 1000,
+ .clock = 10000,
.hdisplay = 320,
.hsync_start = 320 + 6,
.hsync_end = 320 + 6 + 6,
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH] clk: versatile: Add of_node_put() in cm_osc_setup()
From: Nishka Dasgupta @ 2019-08-04 16:34 UTC (permalink / raw)
To: mturquette, sboyd, linux-clk, linus.walleij, linux-arm-kernel
Cc: Nishka Dasgupta
In function cm_osc_setup, variable parent takes the value returned by
of_get_parent, which gets a node but does not put it. If parent is not
put before it goes out of scope, it may cause a memory leak.
Hence put parent before the function terminates.
Issue found with Coccinelle.
Signed-off-by: Nishka Dasgupta <nishkadg.linux@gmail.com>
---
drivers/clk/versatile/clk-versatile.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/clk/versatile/clk-versatile.c b/drivers/clk/versatile/clk-versatile.c
index 90bb0b041b7a..fd54d5c0251c 100644
--- a/drivers/clk/versatile/clk-versatile.c
+++ b/drivers/clk/versatile/clk-versatile.c
@@ -70,6 +70,7 @@ static void __init cm_osc_setup(struct device_node *np,
return;
}
cm_base = of_iomap(parent, 0);
+ of_node_put(parent);
if (!cm_base) {
pr_err("could not remap core module base\n");
return;
--
2.19.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH] pinctrl: freescale: mxs: Add of_node_put() before return
From: Nishka Dasgupta @ 2019-08-04 16:04 UTC (permalink / raw)
To: linus.walleij, linux-arm-kernel, linux-gpio, linux-imx, s.hauer,
kernel, stefan, shawnguo, festevam, aisheng.dong
Cc: Nishka Dasgupta
Each iteration of for_each_child_of_node puts the previous node, but in
the case of a return from the middle of the loop, there is no put, thus
causing a memory leak. Hence add an of_node_put before the return in
three places.
Issue found with Coccinelle.
Signed-off-by: Nishka Dasgupta <nishkadg.linux@gmail.com>
---
drivers/pinctrl/freescale/pinctrl-mxs.c | 12 +++++++++---
1 file changed, 9 insertions(+), 3 deletions(-)
diff --git a/drivers/pinctrl/freescale/pinctrl-mxs.c b/drivers/pinctrl/freescale/pinctrl-mxs.c
index 641b3088876f..735cedd0958a 100644
--- a/drivers/pinctrl/freescale/pinctrl-mxs.c
+++ b/drivers/pinctrl/freescale/pinctrl-mxs.c
@@ -488,8 +488,10 @@ static int mxs_pinctrl_probe_dt(struct platform_device *pdev,
if (of_property_read_u32(child, "reg", &val)) {
ret = mxs_pinctrl_parse_group(pdev, child,
idxg++, NULL);
- if (ret)
+ if (ret) {
+ of_node_put(child);
return ret;
+ }
continue;
}
@@ -499,15 +501,19 @@ static int mxs_pinctrl_probe_dt(struct platform_device *pdev,
f->ngroups,
sizeof(*f->groups),
GFP_KERNEL);
- if (!f->groups)
+ if (!f->groups) {
+ of_node_put(child);
return -ENOMEM;
+ }
fn = child->name;
i = 0;
}
ret = mxs_pinctrl_parse_group(pdev, child, idxg++,
&f->groups[i++]);
- if (ret)
+ if (ret) {
+ of_node_put(child);
return ret;
+ }
}
return 0;
--
2.19.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH] pinctrl: samsung: exynos: Add of_node_put() before return
From: Nishka Dasgupta @ 2019-08-04 16:02 UTC (permalink / raw)
To: linus.walleij, linux-arm-kernel, linux-gpio, tomasz.figa, krzk,
s.nawrocki, kgene, linux-samsung-soc
Cc: Nishka Dasgupta
Each iteration of for_each_child_of_node puts the previous node, but in
the case of a return from the middle of the loop, there is no put, thus
causing a memory leak. Hence add an of_node_put before the return.
Issue found with Coccinelle.
Signed-off-by: Nishka Dasgupta <nishkadg.linux@gmail.com>
---
drivers/pinctrl/samsung/pinctrl-exynos.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/pinctrl/samsung/pinctrl-exynos.c b/drivers/pinctrl/samsung/pinctrl-exynos.c
index ebc27b06718c..e7f4cbad2c92 100644
--- a/drivers/pinctrl/samsung/pinctrl-exynos.c
+++ b/drivers/pinctrl/samsung/pinctrl-exynos.c
@@ -486,8 +486,10 @@ int exynos_eint_wkup_init(struct samsung_pinctrl_drv_data *d)
if (match) {
irq_chip = kmemdup(match->data,
sizeof(*irq_chip), GFP_KERNEL);
- if (!irq_chip)
+ if (!irq_chip) {
+ of_node_put(np);
return -ENOMEM;
+ }
wkup_np = np;
break;
}
--
2.19.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH] pinctrl: nomadik: abx500: Add of_node_put() before return
From: Nishka Dasgupta @ 2019-08-04 15:51 UTC (permalink / raw)
To: linus.walleij, linux-arm-kernel, linux-gpio; +Cc: Nishka Dasgupta
Each iteration of for_each_child_of_node puts the previous node, but in
the case of a return from the middle of the loop, there is no put, thus
causing a memory leak. Hence add an of_node_put before the return.
Issue found with Coccinelle.
Signed-off-by: Nishka Dasgupta <nishkadg.linux@gmail.com>
---
drivers/pinctrl/nomadik/pinctrl-abx500.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/pinctrl/nomadik/pinctrl-abx500.c b/drivers/pinctrl/nomadik/pinctrl-abx500.c
index c3595200e1e6..7aa534576a45 100644
--- a/drivers/pinctrl/nomadik/pinctrl-abx500.c
+++ b/drivers/pinctrl/nomadik/pinctrl-abx500.c
@@ -815,6 +815,7 @@ static int abx500_dt_node_to_map(struct pinctrl_dev *pctldev,
&reserved_maps, num_maps);
if (ret < 0) {
pinctrl_utils_free_map(pctldev, *map, *num_maps);
+ of_node_put(np);
return ret;
}
}
--
2.19.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH] pinctrl: nomadik: nomadik: Add of_node_put() before return
From: Nishka Dasgupta @ 2019-08-04 15:51 UTC (permalink / raw)
To: linus.walleij, linux-arm-kernel, linux-gpio; +Cc: Nishka Dasgupta
Each iteration of for_each_child_of_node puts the previous node, but in
the case of a return from the middle of the loop, there is no put, thus
causing a memory leak. Hence add an of_node_put before the return.
Issue found with Coccinelle.
Signed-off-by: Nishka Dasgupta <nishkadg.linux@gmail.com>
---
drivers/pinctrl/nomadik/pinctrl-nomadik.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/pinctrl/nomadik/pinctrl-nomadik.c b/drivers/pinctrl/nomadik/pinctrl-nomadik.c
index ddd1f466d302..2a8190b11d10 100644
--- a/drivers/pinctrl/nomadik/pinctrl-nomadik.c
+++ b/drivers/pinctrl/nomadik/pinctrl-nomadik.c
@@ -1508,6 +1508,7 @@ static int nmk_pinctrl_dt_node_to_map(struct pinctrl_dev *pctldev,
&reserved_maps, num_maps);
if (ret < 0) {
pinctrl_utils_free_map(pctldev, *map, *num_maps);
+ of_node_put(np);
return ret;
}
}
--
2.19.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH] pinctrl: spear: spear: Add of_node_put() before return
From: Nishka Dasgupta @ 2019-08-04 15:49 UTC (permalink / raw)
To: vireshk, linus.walleij, linux-arm-kernel, linux-gpio; +Cc: Nishka Dasgupta
Each iteration of for_each_child_of_node puts the previous node, but in
the case of a return from the middle of the loop, there is no put, thus
causing a memory leak. Hence add an of_node_put before the return in
two places.
Issue found with Coccinelle.
Signed-off-by: Nishka Dasgupta <nishkadg.linux@gmail.com>
---
drivers/pinctrl/spear/pinctrl-spear.c | 8 ++++++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/drivers/pinctrl/spear/pinctrl-spear.c b/drivers/pinctrl/spear/pinctrl-spear.c
index c4f850345dc4..7ec19c73f870 100644
--- a/drivers/pinctrl/spear/pinctrl-spear.c
+++ b/drivers/pinctrl/spear/pinctrl-spear.c
@@ -157,12 +157,16 @@ static int spear_pinctrl_dt_node_to_map(struct pinctrl_dev *pctldev,
/* calculate number of maps required */
for_each_child_of_node(np_config, np) {
ret = of_property_read_string(np, "st,function", &function);
- if (ret < 0)
+ if (ret < 0) {
+ of_node_put(np);
return ret;
+ }
ret = of_property_count_strings(np, "st,pins");
- if (ret < 0)
+ if (ret < 0) {
+ of_node_put(np);
return ret;
+ }
count += ret;
}
--
2.19.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: [PATCH 0/1] coresight: Fix for v5.3-rc3
From: Mathieu Poirier @ 2019-08-04 13:26 UTC (permalink / raw)
To: Greg KH; +Cc: linux-arm-kernel, Suzuki K. Poulose
In-Reply-To: <20190802091028.GA14004@kroah.com>
On Fri, 2 Aug 2019 at 03:10, Greg KH <gregkh@linuxfoundation.org> wrote:
>
> On Thu, Aug 01, 2019 at 02:16:46PM -0600, Mathieu Poirier wrote:
> > On Thu, 1 Aug 2019 at 12:17, Greg KH <gregkh@linuxfoundation.org> wrote:
> > >
> > > On Thu, Aug 01, 2019 at 11:23:22AM -0600, Mathieu Poirier wrote:
> > > > Good morning Greg,
> > > >
> > > > Here is a fix I'd like you to consider for this cycle. Do you think you
> > > > could apply it to driver-core-next rather than char-misc-next?
> > >
> > > All of my -next branches are for 5.4-rc1, not 5.3 (i.e. the "next"
> > > kernel).
> > >
> > > So either one of them isn't going to matter to you for 5.3-final.
> > >
> > > > My current
> > > > coresight branch is based on driver-core-next to pick up Suzuki's
> > > > generic device lookup helpers patchset [1]. Applying it to char-misc-next
> > > > will create two different signature for the same patch, something that
> > > > gives Stephen a hard time when building the linux-next tree.
> > >
> > > Why would Suzuki's patch matter for 5.3-final?
> >
> > There was a similar situation during the 5.2 cycle [1]. Here too we
> > can fix a problem that is present in 5.3 rather than wait for 5.4.
> >
> > [1]. https://www.spinics.net/lists/arm-kernel/msg736274.html
>
> But that has nothing to do with Suzuki's patch that is in my driver core
> tree. I still fail to see the dependency here.
There is indeed no correlation between the fix and the patches in the
core tree. When writing the original email I didn't know in what tree
you would end up applying the patch and feared we'd end up having the
same patch in two different tree. Thanks to your explanation below
this won't happen.
>
> > > > I also think this patch should go in stable but haven't marked it as such since
> > > > it doesn't apply to any of the stable trees. Once it is part of v5.3 I intend
> > > > to send a new version of the patch that does apply cleanly to those trees. Let
> > > > me know if you want me to proceed differently.
> > > >
> > > > Thanks,
> > > > Mathieu
> > > >
> > > > [1]. https://www.spinics.net/lists/dri-devel/msg219674.html
> > > >
> > > >
> > > > Suzuki K Poulose (1):
> > > > coresight: Fix DEBUG_LOCKS_WARN_ON for uninitialized attribute
> > > >
> > > > drivers/hwtracing/coresight/coresight-etm-perf.c | 1 +
> > > > 1 file changed, 1 insertion(+)
> > >
> > > Why would this patch depend on anything in any of my trees?
> >
> > I send you patches for inclusion in the next cycle and as such I
> > thought it should be the same for fixes in the current cycle. If that
> > is not the case, should I send them directly to Linus?
>
> You can send me fixes to forward on to Linus for this current cycle, if
> they are not depending on patches that are only for the -next release.
>
> I always keep 2 branches in my git trees:
> -linus : patches for Linus this release cycle
> -next : patches for Linus the next release cycle
>
> If you have bugfixes, make them against my -linus branch and send them
> on. Odds are they don't have dependancies other than what is in Linus's
> tree, so that's fine.
Perfect, that's the link I was missing.
Thanks,
Mathieu
>
> If you have patches for the next cycle, send them against my -next
> branch.
>
> thanks,
>
> greg k-h
_______________________________________________
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 6/6] dt-bindings: arm: coresight: Add support for coresight-needs-save-restore
From: Mathieu Poirier @ 2019-08-04 13:13 UTC (permalink / raw)
To: Andrew Murray
Cc: Al Grant, Suzuki K Poulose, Alexander Shishkin, Coresight ML,
Sudeep Holla, Leo Yan, linux-arm-kernel, Mike Leach
In-Reply-To: <20190802143751.GP56241@e119886-lin.cambridge.arm.com>
On Fri, 2 Aug 2019 at 08:37, Andrew Murray <andrew.murray@arm.com> wrote:
>
> On Fri, Aug 02, 2019 at 11:40:54AM +0100, Suzuki K Poulose wrote:
> > Hi Andrew,
> >
> > On 30/07/2019 13:51, Andrew Murray wrote:
> > > Some coresight components, because of choices made during hardware
> > > integration, require their state to be saved and restored across CPU low
> > > power states.
> > >
> > > The software has no reliable method of detecting when save/restore is
> > > required thus let's add a binding to inform the kernel.
> > >
> > > Signed-off-by: Andrew Murray <andrew.murray@arm.com>
> > > ---
> > > Documentation/devicetree/bindings/arm/coresight.txt | 3 +++
> > > 1 file changed, 3 insertions(+)
> > >
> > > diff --git a/Documentation/devicetree/bindings/arm/coresight.txt b/Documentation/devicetree/bindings/arm/coresight.txt
> > > index fcc3bacfd8bc..7cbdb7893af8 100644
> > > --- a/Documentation/devicetree/bindings/arm/coresight.txt
> > > +++ b/Documentation/devicetree/bindings/arm/coresight.txt
> > > @@ -92,6 +92,9 @@ its hardware characteristcs.
> > > * arm,cp14: must be present if the system accesses ETM/PTM management
> > > registers via co-processor 14.
> > > + * arm,coresight-needs-save-restore: boolean. Indicates that software
> > > + should save/restore state across power down.
> > > +
> >
> > Do you think we could be a bit more descriptive here about when people could add
> > it to the DT ? Here we don't mention when someone should use this property and
> > it may be added to platforms where it may be absolutely unnecessary. How about :
> >
> > "Indicates that the hardware implementation may not honor the Powerup request
> > from the software and thus might loose the register context on CPU power
> > down (e.g, during CPUIdle). Software must save/restore the context during a
> > CPU power transition cycle."
>
> How about the following:
>
> "Indicates that the hardware will loose register context on CPU power down (e.g.
> CPUIdle), despite the TRCPDCR.PU bit being set."
>
> I'm keen to avoid making suggestions about what the kernel will do when it sees
> this flag and thus prefer to focus on describing what the hardware does. So I
> dropped your last sentence. However the name of the flag still implies policy
> which I don't like.
>
> I also changed the 'may not honor' wording, I'm not sure if this is really the
> case or if the spec is open to interpretation.
>
> It would great for this wording to also apply to other CS components though I
> haven't investigated if these have a PU bit or something different.
Exactly - the definition needs to be broad enough to apply to other CS
components. Mike what do you think would be appropriate for CTIs?
>
> Thanks,
>
> Andrew Murray
>
> >
> > Cheers
> > Suzuki
_______________________________________________
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: dts: rockchip: Add dts for Leez RK3399 P710 SBC
From: Heiko Stuebner @ 2019-08-04 9:59 UTC (permalink / raw)
To: Andy Yan
Cc: devicetree, robh+dt, linux-kernel, linux-arm-kernel,
open list:ARM/Rockchip SoC...
In-Reply-To: <CANbgqATNLO=wJfKNDY74qmQUqAP_9Xv29nGhLj+Y0Cc7CAMQyg@mail.gmail.com>
Hi Andy,
Am Sonntag, 4. August 2019, 10:38:26 CEST schrieb Andy Yan:
> Heiko Stuebner <heiko@sntech.de> 于2019年8月4日周日 上午8:34写道：
> > Am Samstag, 3. August 2019, 13:46:12 CEST schrieb Andy Yan:
> > > Leez P710 is a RK3399 based SBC, designed by Leez team
> > > from lenovo [0].
> > >
> > > Specification
> > > - Rockchip RK3399
> > > - 4/2GB LPDDR4
> > > - TF sd scard slot
> > > - eMMC
> > > - M.2 B-Key for 4G LTE
> > > - AP6256 for WiFi + BT
> > > - Gigabit ethernet
> > > - HDMI out
> > > - 40 pin header
> > > - TYPE-C Power supply
> > >
> > > [0] https://leez.lenovo.com
> > >
> > > Signed-off-by: Andy Yan <andyshrk@gmail.com>
> > > ---
> > > .../devicetree/bindings/arm/rockchip.yaml | 5 +
> > > arch/arm64/boot/dts/rockchip/Makefile | 1 +
> > > .../boot/dts/rockchip/rk3399-leez-p710.dts | 635 ++++++++++++++++++
> > > 3 files changed, 641 insertions(+)
> > > create mode 100644 arch/arm64/boot/dts/rockchip/rk3399-leez-p710.dts
> > >
> > > diff --git a/Documentation/devicetree/bindings/arm/rockchip.yaml
> > b/Documentation/devicetree/bindings/arm/rockchip.yaml
> > > index 34865042f4e4..da9cd947abfa 100644
> > > --- a/Documentation/devicetree/bindings/arm/rockchip.yaml
> > > +++ b/Documentation/devicetree/bindings/arm/rockchip.yaml
> > > @@ -329,6 +329,11 @@ properties:
> > > - khadas,edge-v
> > > - const: rockchip,rk3399
> > >
> > > + - description: Leez RK3399 P710
> > > + items:
> > > + - const: leez,p710
> >
> > Is "leez" really the vendor?
> > Part of me would assume something like
> > lenovo,leez-p710
> >
> >
> According to Leez team， they want to treat Leez an independent vendor here。
ok, that should be fine then. You'll just have to also add
an entry for them into the vendor-prefixes.yaml file then.
(And of course rework the regulator tree)
Thanks
Heiko
> > So please clarify :-)
> > And also please make sure the decided vendor is part of the vendor-prefixes
> > binding in Documentation/devicestree/bindings/vendor-prefixes.yaml
> >
> > > + - const: rockchip,rk3399
> > > +
> > > - description: mqmaker MiQi
> > > items:
> > > - const: mqmaker,miqi
> > > diff --git a/arch/arm64/boot/dts/rockchip/Makefile
> > b/arch/arm64/boot/dts/rockchip/Makefile
> > > index daa2c78e22c3..1f18a9392d15 100644
> > > --- a/arch/arm64/boot/dts/rockchip/Makefile
> > > +++ b/arch/arm64/boot/dts/rockchip/Makefile
> > > @@ -20,6 +20,7 @@ dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3399-hugsun-x99.dtb
> > > dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3399-khadas-edge.dtb
> > > dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3399-khadas-edge-captain.dtb
> > > dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3399-khadas-edge-v.dtb
> > > +dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3399-leez-p710.dtb
> > > dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3399-nanopc-t4.dtb
> > > dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3399-nanopi-m4.dtb
> > > dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3399-nanopi-neo4.dtb
> > > diff --git a/arch/arm64/boot/dts/rockchip/rk3399-leez-p710.dts
> > b/arch/arm64/boot/dts/rockchip/rk3399-leez-p710.dts
> > > new file mode 100644
> > > index 000000000000..b342f5e8692b
> > > --- /dev/null
> > > +++ b/arch/arm64/boot/dts/rockchip/rk3399-leez-p710.dts
> > > @@ -0,0 +1,635 @@
> > > +// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
> > > +/*
> > > + * Copyright (c) 2019 Andy Yan <andy.yan@gmail.com>
> > > + */
> > > +
> > > +/dts-v1/;
> > > +#include <dt-bindings/input/linux-event-codes.h>
> > > +#include <dt-bindings/pwm/pwm.h>
> > > +#include "rk3399.dtsi"
> > > +#include "rk3399-opp.dtsi"
> > > +
> > > +/ {
> > > + model = "Leez RK3399 P710";
> > > + compatible = "leez,p710", "rockchip,rk3399";
> >
> > same comment as above, so maybe:
> > model = "Lenovo Leez RK3399 P710";
> > compatible = "lenovo,leez-p710", "rockchip,rk3399";
> >
> >
> >
> > > +
> > > + chosen {
> > > + stdout-path = "serial2:1500000n8";
> > > + };
> > > +
> > > + clkin_gmac: external-gmac-clock {
> > > + compatible = "fixed-clock";
> > > + clock-frequency = <125000000>;
> > > + clock-output-names = "clkin_gmac";
> > > + #clock-cells = <0>;
> > > + };
> > > +
> > > + sdio_pwrseq: sdio-pwrseq {
> > > + compatible = "mmc-pwrseq-simple";
> > > + clocks = <&rk808 1>;
> > > + clock-names = "ext_clock";
> > > + pinctrl-names = "default";
> > > + pinctrl-0 = <&wifi_enable_h>;
> > > + reset-gpios = <&gpio0 RK_PB2 GPIO_ACTIVE_LOW>;
> > > + };
> > > +
> > > + dc5v_adp: dc-5v {
> > > + compatible = "regulator-fixed";
> > > + regulator-name = "dc5v_adapter";
> > > + regulator-always-on;
> > > + regulator-boot-on;
> > > + regulator-min-microvolt = <5000000>;
> > > + regulator-max-microvolt = <5000000>;
> > > + };
> > > +
> > > + vcc5v0_sys: vcc-sys {
> >
> > vcc5v0_sys: vcc5v0-sys ?
> >
> > > + compatible = "regulator-fixed";
> > > + regulator-name = "vcc5v0_sys";
> > > + regulator-always-on;
> > > + regulator-boot-on;
> > > + regulator-min-microvolt = <5000000>;
> > > + regulator-max-microvolt = <5000000>;
> > > + vin-supply = <&dc5v_adp>;
> > > + };
> > > +
> > > + vcc3v3_sys: vcc3v3-sys {
> > > + compatible = "regulator-fixed";
> > > + regulator-name = "vcc3v3_sys";
> > > + regulator-always-on;
> > > + regulator-boot-on;
> > > + regulator-min-microvolt = <3300000>;
> > > + regulator-max-microvolt = <3300000>;
> > > + vin-supply = <&vcc5v0_sys>;
> > > + };
> > > +
> > > + vcc5v0_host: vcc5v0-host-regulator {
> > > + compatible = "regulator-fixed";
> > > + enable-active-high;
> > > + gpio = <&gpio2 RK_PA2 GPIO_ACTIVE_HIGH>;
> > > + pinctrl-names = "default";
> > > + pinctrl-0 = <&vcc5v0_host_en>;
> > > + regulator-name = "vcc5v0_host";
> > > + regulator-always-on;
> > > + vin-supply = <&vcc5v0_sys>;
> > > + };
> > > +
> > > + vcc_lan: vcc3v3-phy-regulator {
> > > + compatible = "regulator-fixed";
> > > + regulator-name = "vcc_lan";
> > > + regulator-always-on;
> > > + regulator-boot-on;
> > > + regulator-min-microvolt = <3300000>;
> > > + regulator-max-microvolt = <3300000>;
> > > +
> > > + regulator-state-mem {
> > > + regulator-off-in-suspend;
> > > + };
> > > + };
> >
> > In general, please model an actual regulator-tree and do not copy the
> > unspecific Rockchip vendor tree. These unconnected regulators are a very
> > good indicator that the real power-tree got ignored (missing vin-supply
> > here)
> >
> > I found schematics on https://github.com/leezsbc/resources/wiki/Leez-P710:
> > 链接: https://pan.baidu.com/s/1NPWbuI5csT4zftKUCnRs7g
> > 提取码: rvrh
> >
> > and there the power-tree is described in a complete way.
> >
> > regulator/regulator_summaray in the kernels debugfs should
> > show a nice tree structure starting from the dc-adapter input.
> >
> > Also please use names matching the supply names from the schematics.
> >
> > Same for pinctrl names, please use names as used in the board schematics.
> >
> >
> > > + vdd_log: vdd-log {
> > > + compatible = "pwm-regulator";
> > > + pwms = <&pwm2 0 25000 1>;
> > > + regulator-name = "vdd_log";
> > > + regulator-always-on;
> > > + regulator-boot-on;
> > > + regulator-min-microvolt = <800000>;
> > > + regulator-max-microvolt = <1400000>;
> > > + vin-supply = <&vcc5v0_sys>;
> > > + };
> > > +};
> > > +
> > > +&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";
> > > +};
> > > +
> > > +&gmac {
> > > + assigned-clocks = <&cru SCLK_RMII_SRC>;
> > > + assigned-clock-parents = <&clkin_gmac>;
> > > + clock_in_out = "input";
> > > + phy-supply = <&vcc_lan>;
> > > + phy-mode = "rgmii";
> > > + pinctrl-names = "default";
> > > + pinctrl-0 = <&rgmii_pins>;
> > > + snps,reset-gpio = <&gpio3 RK_PB7 GPIO_ACTIVE_LOW>;
> > > + snps,reset-active-low;
> > > + snps,reset-delays-us = <0 10000 50000>;
> > > + tx_delay = <0x28>;
> > > + rx_delay = <0x11>;
> > > + status = "okay";
> > > +};
> > > +
> > > +&gpu {
> > > + mali-supply = <&vdd_gpu>;
> > > + status = "okay";
> > > +};
> > > +
> > > +&hdmi {
> > > + ddc-i2c-bus = <&i2c3>;
> >
> > can this also use the internal i2c inside the dw-hdmi?
> >
> >
> > > + pinctrl-names = "default";
> > > + pinctrl-0 = <&hdmi_cec>;
> > > + status = "okay";
> > > +};
> > > +
> > > +&hdmi_sound {
> > > + status = "okay";
> > > +};
> > > +
> > > +&i2c0 {
> > > + clock-frequency = <400000>;
> > > + i2c-scl-rising-time-ns = <168>;
> > > + i2c-scl-falling-time-ns = <4>;
> > > + status = "okay";
> > > +
> > > + rk808: pmic@1b {
> > > + compatible = "rockchip,rk808";
> > > + reg = <0x1b>;
> > > + interrupt-parent = <&gpio1>;
> > > + interrupts = <21 IRQ_TYPE_LEVEL_LOW>;
> > > + #clock-cells = <1>;
> > > + clock-output-names = "xin32k", "rk808-clkout2";
> > > + pinctrl-names = "default";
> > > + pinctrl-0 = <&pmic_int_l>;
> > > + rockchip,system-power-controller;
> > > + wakeup-source;
> > > +
> > > + vcc1-supply = <&vcc5v0_sys>;
> > > + vcc2-supply = <&vcc5v0_sys>;
> > > + vcc3-supply = <&vcc5v0_sys>;
> > > + vcc4-supply = <&vcc5v0_sys>;
> > > + vcc6-supply = <&vcc5v0_sys>;
> > > + vcc7-supply = <&vcc5v0_sys>;
> > > + vcc8-supply = <&vcc3v3_sys>;
> > > + vcc9-supply = <&vcc5v0_sys>;
> > > + vcc10-supply = <&vcc5v0_sys>;
> > > + vcc11-supply = <&vcc5v0_sys>;
> > > + vcc12-supply = <&vcc3v3_sys>;
> > > + vddio-supply = <&vcc_1v8>;
> > > +
> > > + regulators {
> > > + vdd_center: DCDC_REG1 {
> > > + regulator-name = "vdd_center";
> > > + regulator-always-on;
> > > + regulator-boot-on;
> > > + regulator-min-microvolt = <750000>;
> > > + regulator-max-microvolt = <1350000>;
> > > + regulator-ramp-delay = <6001>;
> > > + regulator-state-mem {
> > > + regulator-off-in-suspend;
> > > + };
> > > + };
> > > +
> > > + vdd_cpu_l: DCDC_REG2 {
> > > + regulator-name = "vdd_cpu_l";
> > > + regulator-always-on;
> > > + regulator-boot-on;
> > > + regulator-min-microvolt = <750000>;
> > > + regulator-max-microvolt = <1350000>;
> > > + regulator-ramp-delay = <6001>;
> > > + regulator-state-mem {
> > > + regulator-off-in-suspend;
> > > + };
> > > + };
> > > +
> > > + vcc_ddr: DCDC_REG3 {
> > > + regulator-name = "vcc_ddr";
> > > + regulator-always-on;
> > > + regulator-boot-on;
> > > + regulator-state-mem {
> > > + regulator-on-in-suspend;
> > > + };
> > > + };
> > > +
> > > + vcc_1v8: DCDC_REG4 {
> > > + regulator-name = "vcc_1v8";
> > > + regulator-always-on;
> > > + regulator-boot-on;
> > > + regulator-min-microvolt = <1800000>;
> > > + regulator-max-microvolt = <1800000>;
> > > + regulator-state-mem {
> > > + regulator-on-in-suspend;
> > > + regulator-suspend-microvolt =
> > <1800000>;
> > > + };
> > > + };
> > > +
> > > + vcc1v8_dvp: LDO_REG1 {
> > > + regulator-name = "vcc1v8_dvp";
> > > + regulator-always-on;
> > > + regulator-boot-on;
> > > + regulator-min-microvolt = <1800000>;
> > > + regulator-max-microvolt = <1800000>;
> > > + regulator-state-mem {
> > > + regulator-off-in-suspend;
> > > + };
> > > + };
> > > +
> > > + vcc1v8_hdmi: LDO_REG2 {
> > > + regulator-name = "vcc1v8_hdmi";
> > > + regulator-always-on;
> > > + regulator-boot-on;
> > > + regulator-min-microvolt = <1800000>;
> > > + regulator-max-microvolt = <1800000>;
> > > + regulator-state-mem {
> > > + regulator-off-in-suspend;
> > > + };
> > > + };
> > > +
> > > + vcca_1v8: LDO_REG3 {
> > > + regulator-name = "vcca_1v8";
> > > + regulator-always-on;
> > > + regulator-boot-on;
> > > + regulator-min-microvolt = <1800000>;
> > > + regulator-max-microvolt = <1800000>;
> > > + regulator-state-mem {
> > > + regulator-on-in-suspend;
> > > + regulator-suspend-microvolt =
> > <1800000>;
> > > + };
> > > + };
> > > +
> > > + vccio_sd: LDO_REG4 {
> > > + regulator-name = "vccio_sd";
> > > + regulator-always-on;
> > > + regulator-boot-on;
> > > + regulator-min-microvolt = <3000000>;
> > > + regulator-max-microvolt = <3000000>;
> > > + regulator-state-mem {
> > > + regulator-on-in-suspend;
> > > + regulator-suspend-microvolt =
> > <3000000>;
> > > + };
> > > + };
> > > +
> > > + vcca3v0_codec: LDO_REG5 {
> > > + regulator-name = "vcca3v0_codec";
> > > + regulator-always-on;
> > > + regulator-boot-on;
> > > + regulator-min-microvolt = <3000000>;
> > > + regulator-max-microvolt = <3000000>;
> > > + regulator-state-mem {
> > > + regulator-off-in-suspend;
> > > + };
> > > + };
> > > +
> > > + vcc_1v5: LDO_REG6 {
> > > + regulator-name = "vcc_1v5";
> > > + regulator-always-on;
> > > + regulator-boot-on;
> > > + regulator-min-microvolt = <1500000>;
> > > + regulator-max-microvolt = <1500000>;
> > > + regulator-state-mem {
> > > + regulator-on-in-suspend;
> > > + regulator-suspend-microvolt =
> > <1500000>;
> > > + };
> > > + };
> > > +
> > > + vcc0v9_hdmi: LDO_REG7 {
> > > + regulator-name = "vcc0v9_hdmi";
> > > + regulator-always-on;
> > > + regulator-boot-on;
> > > + regulator-min-microvolt = <900000>;
> > > + regulator-max-microvolt = <900000>;
> > > + regulator-state-mem {
> > > + regulator-off-in-suspend;
> > > + };
> > > + };
> > > +
> > > + vcc_3v0: LDO_REG8 {
> > > + regulator-name = "vcc_3v0";
> > > + regulator-always-on;
> > > + regulator-boot-on;
> > > + regulator-min-microvolt = <3000000>;
> > > + regulator-max-microvolt = <3000000>;
> > > + regulator-state-mem {
> > > + regulator-on-in-suspend;
> > > + regulator-suspend-microvolt =
> > <3000000>;
> > > + };
> > > + };
> > > +
> >
> > unneeded blank line
> >
> > > + };
> > > + };
> > > +
> >
> >
> > Heiko
> >
> >
> >
_______________________________________________
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 9/9] arm64: Retrieve stolen time as paravirtualized guest
From: Marc Zyngier @ 2019-08-04 9:53 UTC (permalink / raw)
To: Steven Price
Cc: kvm, Radim Krčmář, Catalin Marinas,
Suzuki K Pouloze, linux-doc, Russell King, linux-kernel,
James Morse, linux-arm-kernel, Paolo Bonzini, Will Deacon, kvmarm,
Julien Thierry
In-Reply-To: <20190802145017.42543-10-steven.price@arm.com>
On Fri, 2 Aug 2019 15:50:17 +0100
Steven Price <steven.price@arm.com> wrote:
> Enable paravirtualization features when running under a hypervisor
> supporting the PV_TIME_ST hypercall.
>
> For each (v)CPU, we ask the hypervisor for the location of a shared
> page which the hypervisor will use to report stolen time to us. We set
> pv_time_ops to the stolen time function which simply reads the stolen
> value from the shared page for a VCPU. We guarantee single-copy
> atomicity using READ_ONCE which means we can also read the stolen
> time for another VCPU than the currently running one while it is
> potentially being updated by the hypervisor.
>
> Signed-off-by: Steven Price <steven.price@arm.com>
> ---
> arch/arm64/kernel/Makefile | 1 +
> arch/arm64/kernel/kvm.c | 155 +++++++++++++++++++++++++++++++++++++
nit: Why not using paravirt.c, which clearly states what it does? The
alternative would be to name it kvm-pv.c.
> include/linux/cpuhotplug.h | 1 +
> 3 files changed, 157 insertions(+)
> create mode 100644 arch/arm64/kernel/kvm.c
>
> diff --git a/arch/arm64/kernel/Makefile b/arch/arm64/kernel/Makefile
> index 478491f07b4f..eb36edf9b930 100644
> --- a/arch/arm64/kernel/Makefile
> +++ b/arch/arm64/kernel/Makefile
> @@ -63,6 +63,7 @@ obj-$(CONFIG_CRASH_CORE) += crash_core.o
> obj-$(CONFIG_ARM_SDE_INTERFACE) += sdei.o
> obj-$(CONFIG_ARM64_SSBD) += ssbd.o
> obj-$(CONFIG_ARM64_PTR_AUTH) += pointer_auth.o
> +obj-$(CONFIG_PARAVIRT) += kvm.o
>
> obj-y += vdso/ probes/
> obj-$(CONFIG_COMPAT_VDSO) += vdso32/
> diff --git a/arch/arm64/kernel/kvm.c b/arch/arm64/kernel/kvm.c
> new file mode 100644
> index 000000000000..245398c79dae
> --- /dev/null
> +++ b/arch/arm64/kernel/kvm.c
> @@ -0,0 +1,155 @@
> +// SPDX-License-Identifier: GPL-2.0
> +// Copyright (C) 2019 Arm Ltd.
> +
> +#define pr_fmt(fmt) "kvmarm-pv: " fmt
> +
> +#include <linux/arm-smccc.h>
> +#include <linux/cpuhotplug.h>
> +#include <linux/io.h>
> +#include <linux/printk.h>
> +#include <linux/psci.h>
> +#include <linux/reboot.h>
> +#include <linux/slab.h>
> +
> +#include <asm/paravirt.h>
> +#include <asm/pvclock-abi.h>
> +#include <asm/smp_plat.h>
> +
> +struct kvmarm_stolen_time_region {
> + struct pvclock_vcpu_stolen_time_info *kaddr;
> +};
> +
> +static DEFINE_PER_CPU(struct kvmarm_stolen_time_region, stolen_time_region);
> +
> +static bool steal_acc = true;
> +static int __init parse_no_stealacc(char *arg)
> +{
> + steal_acc = false;
> + return 0;
> +}
> +early_param("no-steal-acc", parse_no_stealacc);
> +
> +/* return stolen time in ns by asking the hypervisor */
> +static u64 kvm_steal_clock(int cpu)
> +{
> + struct kvmarm_stolen_time_region *reg;
> +
> + reg = per_cpu_ptr(&stolen_time_region, cpu);
> + if (!reg->kaddr) {
> + pr_warn_once("stolen time enabled but not configured for cpu %d\n",
> + cpu);
> + return 0;
> + }
> +
> + return le64_to_cpu(READ_ONCE(reg->kaddr->stolen_time));
> +}
> +
> +static int disable_stolen_time_current_cpu(void)
> +{
> + struct kvmarm_stolen_time_region *reg;
> +
> + reg = this_cpu_ptr(&stolen_time_region);
> + if (!reg->kaddr)
> + return 0;
> +
> + memunmap(reg->kaddr);
> + memset(reg, 0, sizeof(*reg));
> +
> + return 0;
> +}
> +
> +static int stolen_time_dying_cpu(unsigned int cpu)
> +{
> + return disable_stolen_time_current_cpu();
> +}
> +
> +static int init_stolen_time_cpu(unsigned int cpu)
> +{
> + struct kvmarm_stolen_time_region *reg;
> + struct arm_smccc_res res;
> +
> + reg = this_cpu_ptr(&stolen_time_region);
> +
> + if (reg->kaddr)
> + return 0;
Can this actually happen? It'd take two CPU_UP calls from the HP
notifiers to get in that situation...
> +
> + arm_smccc_1_1_invoke(ARM_SMCCC_HV_PV_TIME_ST, &res);
> +
> + if ((long)res.a0 < 0)
> + return -EINVAL;
> +
> + reg->kaddr = memremap(res.a0,
> + sizeof(struct pvclock_vcpu_stolen_time_info),
> + MEMREMAP_WB);
> +
> + if (reg->kaddr == NULL) {
> + pr_warn("Failed to map stolen time data structure\n");
> + return -EINVAL;
-ENOMEM is the expected return code.
> + }
> +
> + if (le32_to_cpu(reg->kaddr->revision) != 0 ||
> + le32_to_cpu(reg->kaddr->attributes) != 0) {
> + pr_warn("Unexpected revision or attributes in stolen time data\n");
> + return -ENXIO;
> + }
> +
> + return 0;
> +}
> +
> +static int kvm_arm_init_stolen_time(void)
> +{
> + int ret;
> +
> + ret = cpuhp_setup_state(CPUHP_AP_ARM_KVMPV_STARTING,
> + "hypervisor/kvmarm/pv:starting",
> + init_stolen_time_cpu, stolen_time_dying_cpu);
> + if (ret < 0)
> + return ret;
> + return 0;
> +}
> +
> +static bool has_kvm_steal_clock(void)
> +{
> + struct arm_smccc_res res;
> +
> + /* To detect the presence of PV time support we require SMCCC 1.1+ */
> + if (psci_ops.smccc_version < SMCCC_VERSION_1_1)
> + return false;
> +
> + arm_smccc_1_1_invoke(ARM_SMCCC_ARCH_FEATURES_FUNC_ID,
> + ARM_SMCCC_HV_PV_FEATURES, &res);
> +
> + if (res.a0 != SMCCC_RET_SUCCESS)
> + return false;
> +
> + arm_smccc_1_1_invoke(ARM_SMCCC_HV_PV_FEATURES,
> + ARM_SMCCC_HV_PV_TIME_ST, &res);
> +
> + if (res.a0 != SMCCC_RET_SUCCESS)
> + return false;
> +
> + return true;
> +}
> +
> +static int __init kvm_guest_init(void)
> +{
> + int ret = 0;
> +
> + if (!has_kvm_steal_clock())
> + return 0;
> +
> + ret = kvm_arm_init_stolen_time();
> + if (ret)
> + return ret;
> +
> + pv_ops.time.steal_clock = kvm_steal_clock;
> +
> + static_key_slow_inc(¶virt_steal_enabled);
> + if (steal_acc)
> + static_key_slow_inc(¶virt_steal_rq_enabled);
> +
> + pr_info("using stolen time PV\n");
> +
> + return 0;
> +}
> +early_initcall(kvm_guest_init);
Is there any reason why we wouldn't directly call into this rather than
using an initcall?
> diff --git a/include/linux/cpuhotplug.h b/include/linux/cpuhotplug.h
> index 068793a619ca..89d75edb5750 100644
> --- a/include/linux/cpuhotplug.h
> +++ b/include/linux/cpuhotplug.h
> @@ -136,6 +136,7 @@ enum cpuhp_state {
> /* Must be the last timer callback */
> CPUHP_AP_DUMMY_TIMER_STARTING,
> CPUHP_AP_ARM_XEN_STARTING,
> + CPUHP_AP_ARM_KVMPV_STARTING,
> CPUHP_AP_ARM_CORESIGHT_STARTING,
> CPUHP_AP_ARM64_ISNDEP_STARTING,
> CPUHP_AP_SMPCFD_DYING,
Thanks,
M.
--
Without deviation from the norm, progress is not possible.
_______________________________________________
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] efi/arm: fix allocation failure when reserving the kernel base
From: Ard Biesheuvel @ 2019-08-04 7:57 UTC (permalink / raw)
To: Chester Lin, linux@armlinux.org.uk
Cc: Juergen Gross, linux-efi@vger.kernel.org,
guillaume.gardet@arm.com, linux-kernel@vger.kernel.org,
rppt@linux.ibm.com, Joey Lee, geert@linux-m68k.org,
ren_guo@c-sky.com, Gary Lin, akpm@linux-foundation.org,
mingo@kernel.org, linux-arm-kernel@lists.infradead.org
In-Reply-To: <20190802053744.5519-1-clin@suse.com>
Hello Chester,
On Fri, 2 Aug 2019 at 08:40, Chester Lin <clin@suse.com> wrote:
>
> In some cases the arm32 efistub could fail to allocate memory for
> uncompressed kernel. For example, we got the following error message when
> verifying EFI stub on Raspberry Pi-2 [kernel-5.2.1 + grub-2.04] :
>
> EFI stub: Booting Linux Kernel...
> EFI stub: ERROR: Unable to allocate memory for uncompressed kernel.
> EFI stub: ERROR: Failed to relocate kernel
>
> After checking the EFI memory map we found that the first page [0 - 0xfff]
> had been reserved by Raspberry Pi-2's firmware, and the efistub tried to
> set the dram base at 0, which was actually in a reserved region.
>
This by itself is a violation of the Linux boot protocol for 32-bit
ARM when using the decompressor. The decompressor rounds down its own
base address to a multiple of 128 MB, and assumes the whole area is
available for the decompressed kernel and related data structures.
(The first TEXT_OFFSET bytes are no longer used in practice, which is
why putting a reserved region of 4 KB bytes works at the moment, but
this is fragile). Note that the decompressor does not look at any DT
or EFI provided memory maps *at all*.
So unfortunately, this is not something we can fix in the kernel, but
we should fix it in the bootloader or in GRUB, so it does not put any
reserved regions in the first 128 MB of memory,
> grub> lsefimmap
> Type Physical start - end #Pages Size Attributes
> reserved 0000000000000000-0000000000000fff 00000001 4KiB WB
> conv-mem 0000000000001000-0000000007ef5fff 00007ef5 130004KiB WB
> RT-data 0000000007ef6000-0000000007f09fff 00000014 80KiB RT WB
> conv-mem 0000000007f0a000-000000002d871fff 00025968 615840KiB WB
> .....
>
> To avoid a reserved address, we have to ignore the memory regions which are
> marked as EFI_RESERVED_TYPE, and only conventional memory regions can be
> chosen. If the region before the kernel base is unaligned, it will be
> marked as EFI_RESERVED_TYPE and let kernel ignore it so that memblock_limit
> will not be sticked with a very low address such as 0x1000.
>
> Signed-off-by: Chester Lin <clin@suse.com>
> ---
> arch/arm/mm/mmu.c | 3 ++
> drivers/firmware/efi/libstub/arm32-stub.c | 43 ++++++++++++++++++-----
> 2 files changed, 37 insertions(+), 9 deletions(-)
>
> diff --git a/arch/arm/mm/mmu.c b/arch/arm/mm/mmu.c
> index f3ce34113f89..909b11ba48d8 100644
> --- a/arch/arm/mm/mmu.c
> +++ b/arch/arm/mm/mmu.c
> @@ -1184,6 +1184,9 @@ void __init adjust_lowmem_bounds(void)
> phys_addr_t block_start = reg->base;
> phys_addr_t block_end = reg->base + reg->size;
>
> + if (memblock_is_nomap(reg))
> + continue;
> +
> if (reg->base < vmalloc_limit) {
> if (block_end > lowmem_limit)
> /*
> diff --git a/drivers/firmware/efi/libstub/arm32-stub.c b/drivers/firmware/efi/libstub/arm32-stub.c
> index e8f7aefb6813..10d33d36df00 100644
> --- a/drivers/firmware/efi/libstub/arm32-stub.c
> +++ b/drivers/firmware/efi/libstub/arm32-stub.c
> @@ -128,7 +128,7 @@ static efi_status_t reserve_kernel_base(efi_system_table_t *sys_table_arg,
>
> for (l = 0; l < map_size; l += desc_size) {
> efi_memory_desc_t *desc;
> - u64 start, end;
> + u64 start, end, spare, kernel_base;
>
> desc = (void *)memory_map + l;
> start = desc->phys_addr;
> @@ -144,27 +144,52 @@ static efi_status_t reserve_kernel_base(efi_system_table_t *sys_table_arg,
> case EFI_BOOT_SERVICES_DATA:
> /* Ignore types that are released to the OS anyway */
> continue;
> -
> + case EFI_RESERVED_TYPE:
> + /* Ignore reserved regions */
> + continue;
> case EFI_CONVENTIONAL_MEMORY:
> /*
> * Reserve the intersection between this entry and the
> * region.
> */
> start = max(start, (u64)dram_base);
> - end = min(end, (u64)dram_base + MAX_UNCOMP_KERNEL_SIZE);
> + kernel_base = round_up(start, PMD_SIZE);
> + spare = kernel_base - start;
> + end = min(end, kernel_base + MAX_UNCOMP_KERNEL_SIZE);
> +
> + status = efi_call_early(allocate_pages,
> + EFI_ALLOCATE_ADDRESS,
> + EFI_LOADER_DATA,
> + MAX_UNCOMP_KERNEL_SIZE / EFI_PAGE_SIZE,
> + &kernel_base);
> + if (status != EFI_SUCCESS) {
> + pr_efi_err(sys_table_arg,
> + "reserve_kernel_base: alloc failed.\n");
> + goto out;
> + }
> + *reserve_addr = kernel_base;
>
> + if (!spare)
> + break;
> + /*
> + * If there's a gap between start and kernel_base,
> + * it needs be reserved so that the memblock_limit
> + * will not fall on a very low address when running
> + * adjust_lowmem_bounds(), wchich could eventually
> + * cause CMA reservation issue.
> + */
> status = efi_call_early(allocate_pages,
> EFI_ALLOCATE_ADDRESS,
> - EFI_LOADER_DATA,
> - (end - start) / EFI_PAGE_SIZE,
> + EFI_RESERVED_TYPE,
> + spare / EFI_PAGE_SIZE,
> &start);
> if (status != EFI_SUCCESS) {
> pr_efi_err(sys_table_arg,
> - "reserve_kernel_base(): alloc failed.\n");
> + "reserve spare-region failed\n");
> goto out;
> }
> - break;
>
> + break;
> case EFI_LOADER_CODE:
> case EFI_LOADER_DATA:
> /*
> @@ -220,7 +245,7 @@ efi_status_t handle_kernel_image(efi_system_table_t *sys_table,
> *image_size = image->image_size;
> status = efi_relocate_kernel(sys_table, image_addr, *image_size,
> *image_size,
> - dram_base + MAX_UNCOMP_KERNEL_SIZE, 0);
> + *reserve_addr + MAX_UNCOMP_KERNEL_SIZE, 0);
> if (status != EFI_SUCCESS) {
> pr_efi_err(sys_table, "Failed to relocate kernel.\n");
> efi_free(sys_table, *reserve_size, *reserve_addr);
> @@ -233,7 +258,7 @@ efi_status_t handle_kernel_image(efi_system_table_t *sys_table,
> * in memory. The kernel determines the base of DRAM from the
> * address at which the zImage is loaded.
> */
> - if (*image_addr + *image_size > dram_base + ZIMAGE_OFFSET_LIMIT) {
> + if (*image_addr + *image_size > *reserve_addr + ZIMAGE_OFFSET_LIMIT) {
> pr_efi_err(sys_table, "Failed to relocate kernel, no low memory available.\n");
> efi_free(sys_table, *reserve_size, *reserve_addr);
> *reserve_size = 0;
> --
> 2.22.0
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH] arm64: dts: rockchip: Add dts for Leez RK3399 P710 SBC
From: Heiko Stuebner @ 2019-08-04 0:34 UTC (permalink / raw)
To: Andy Yan
Cc: devicetree, robh+dt, linux-kernel, linux-arm-kernel,
linux-rockchip
In-Reply-To: <20190803114612.4830-1-andyshrk@gmail.com>
Hi Andy,
Am Samstag, 3. August 2019, 13:46:12 CEST schrieb Andy Yan:
> Leez P710 is a RK3399 based SBC, designed by Leez team
> from lenovo [0].
>
> Specification
> - Rockchip RK3399
> - 4/2GB LPDDR4
> - TF sd scard slot
> - eMMC
> - M.2 B-Key for 4G LTE
> - AP6256 for WiFi + BT
> - Gigabit ethernet
> - HDMI out
> - 40 pin header
> - TYPE-C Power supply
>
> [0] https://leez.lenovo.com
>
> Signed-off-by: Andy Yan <andyshrk@gmail.com>
> ---
> .../devicetree/bindings/arm/rockchip.yaml | 5 +
> arch/arm64/boot/dts/rockchip/Makefile | 1 +
> .../boot/dts/rockchip/rk3399-leez-p710.dts | 635 ++++++++++++++++++
> 3 files changed, 641 insertions(+)
> create mode 100644 arch/arm64/boot/dts/rockchip/rk3399-leez-p710.dts
>
> diff --git a/Documentation/devicetree/bindings/arm/rockchip.yaml b/Documentation/devicetree/bindings/arm/rockchip.yaml
> index 34865042f4e4..da9cd947abfa 100644
> --- a/Documentation/devicetree/bindings/arm/rockchip.yaml
> +++ b/Documentation/devicetree/bindings/arm/rockchip.yaml
> @@ -329,6 +329,11 @@ properties:
> - khadas,edge-v
> - const: rockchip,rk3399
>
> + - description: Leez RK3399 P710
> + items:
> + - const: leez,p710
Is "leez" really the vendor?
Part of me would assume something like
lenovo,leez-p710
So please clarify :-)
And also please make sure the decided vendor is part of the vendor-prefixes
binding in Documentation/devicestree/bindings/vendor-prefixes.yaml
> + - const: rockchip,rk3399
> +
> - description: mqmaker MiQi
> items:
> - const: mqmaker,miqi
> diff --git a/arch/arm64/boot/dts/rockchip/Makefile b/arch/arm64/boot/dts/rockchip/Makefile
> index daa2c78e22c3..1f18a9392d15 100644
> --- a/arch/arm64/boot/dts/rockchip/Makefile
> +++ b/arch/arm64/boot/dts/rockchip/Makefile
> @@ -20,6 +20,7 @@ dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3399-hugsun-x99.dtb
> dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3399-khadas-edge.dtb
> dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3399-khadas-edge-captain.dtb
> dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3399-khadas-edge-v.dtb
> +dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3399-leez-p710.dtb
> dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3399-nanopc-t4.dtb
> dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3399-nanopi-m4.dtb
> dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3399-nanopi-neo4.dtb
> diff --git a/arch/arm64/boot/dts/rockchip/rk3399-leez-p710.dts b/arch/arm64/boot/dts/rockchip/rk3399-leez-p710.dts
> new file mode 100644
> index 000000000000..b342f5e8692b
> --- /dev/null
> +++ b/arch/arm64/boot/dts/rockchip/rk3399-leez-p710.dts
> @@ -0,0 +1,635 @@
> +// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
> +/*
> + * Copyright (c) 2019 Andy Yan <andy.yan@gmail.com>
> + */
> +
> +/dts-v1/;
> +#include <dt-bindings/input/linux-event-codes.h>
> +#include <dt-bindings/pwm/pwm.h>
> +#include "rk3399.dtsi"
> +#include "rk3399-opp.dtsi"
> +
> +/ {
> + model = "Leez RK3399 P710";
> + compatible = "leez,p710", "rockchip,rk3399";
same comment as above, so maybe:
model = "Lenovo Leez RK3399 P710";
compatible = "lenovo,leez-p710", "rockchip,rk3399";
> +
> + chosen {
> + stdout-path = "serial2:1500000n8";
> + };
> +
> + clkin_gmac: external-gmac-clock {
> + compatible = "fixed-clock";
> + clock-frequency = <125000000>;
> + clock-output-names = "clkin_gmac";
> + #clock-cells = <0>;
> + };
> +
> + sdio_pwrseq: sdio-pwrseq {
> + compatible = "mmc-pwrseq-simple";
> + clocks = <&rk808 1>;
> + clock-names = "ext_clock";
> + pinctrl-names = "default";
> + pinctrl-0 = <&wifi_enable_h>;
> + reset-gpios = <&gpio0 RK_PB2 GPIO_ACTIVE_LOW>;
> + };
> +
> + dc5v_adp: dc-5v {
> + compatible = "regulator-fixed";
> + regulator-name = "dc5v_adapter";
> + regulator-always-on;
> + regulator-boot-on;
> + regulator-min-microvolt = <5000000>;
> + regulator-max-microvolt = <5000000>;
> + };
> +
> + vcc5v0_sys: vcc-sys {
vcc5v0_sys: vcc5v0-sys ?
> + compatible = "regulator-fixed";
> + regulator-name = "vcc5v0_sys";
> + regulator-always-on;
> + regulator-boot-on;
> + regulator-min-microvolt = <5000000>;
> + regulator-max-microvolt = <5000000>;
> + vin-supply = <&dc5v_adp>;
> + };
> +
> + vcc3v3_sys: vcc3v3-sys {
> + compatible = "regulator-fixed";
> + regulator-name = "vcc3v3_sys";
> + regulator-always-on;
> + regulator-boot-on;
> + regulator-min-microvolt = <3300000>;
> + regulator-max-microvolt = <3300000>;
> + vin-supply = <&vcc5v0_sys>;
> + };
> +
> + vcc5v0_host: vcc5v0-host-regulator {
> + compatible = "regulator-fixed";
> + enable-active-high;
> + gpio = <&gpio2 RK_PA2 GPIO_ACTIVE_HIGH>;
> + pinctrl-names = "default";
> + pinctrl-0 = <&vcc5v0_host_en>;
> + regulator-name = "vcc5v0_host";
> + regulator-always-on;
> + vin-supply = <&vcc5v0_sys>;
> + };
> +
> + vcc_lan: vcc3v3-phy-regulator {
> + compatible = "regulator-fixed";
> + regulator-name = "vcc_lan";
> + regulator-always-on;
> + regulator-boot-on;
> + regulator-min-microvolt = <3300000>;
> + regulator-max-microvolt = <3300000>;
> +
> + regulator-state-mem {
> + regulator-off-in-suspend;
> + };
> + };
In general, please model an actual regulator-tree and do not copy the
unspecific Rockchip vendor tree. These unconnected regulators are a very
good indicator that the real power-tree got ignored (missing vin-supply here)
I found schematics on https://github.com/leezsbc/resources/wiki/Leez-P710:
链接: https://pan.baidu.com/s/1NPWbuI5csT4zftKUCnRs7g
提取码: rvrh
and there the power-tree is described in a complete way.
regulator/regulator_summaray in the kernels debugfs should
show a nice tree structure starting from the dc-adapter input.
Also please use names matching the supply names from the schematics.
Same for pinctrl names, please use names as used in the board schematics.
> + vdd_log: vdd-log {
> + compatible = "pwm-regulator";
> + pwms = <&pwm2 0 25000 1>;
> + regulator-name = "vdd_log";
> + regulator-always-on;
> + regulator-boot-on;
> + regulator-min-microvolt = <800000>;
> + regulator-max-microvolt = <1400000>;
> + vin-supply = <&vcc5v0_sys>;
> + };
> +};
> +
> +&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";
> +};
> +
> +&gmac {
> + assigned-clocks = <&cru SCLK_RMII_SRC>;
> + assigned-clock-parents = <&clkin_gmac>;
> + clock_in_out = "input";
> + phy-supply = <&vcc_lan>;
> + phy-mode = "rgmii";
> + pinctrl-names = "default";
> + pinctrl-0 = <&rgmii_pins>;
> + snps,reset-gpio = <&gpio3 RK_PB7 GPIO_ACTIVE_LOW>;
> + snps,reset-active-low;
> + snps,reset-delays-us = <0 10000 50000>;
> + tx_delay = <0x28>;
> + rx_delay = <0x11>;
> + status = "okay";
> +};
> +
> +&gpu {
> + mali-supply = <&vdd_gpu>;
> + status = "okay";
> +};
> +
> +&hdmi {
> + ddc-i2c-bus = <&i2c3>;
can this also use the internal i2c inside the dw-hdmi?
> + pinctrl-names = "default";
> + pinctrl-0 = <&hdmi_cec>;
> + status = "okay";
> +};
> +
> +&hdmi_sound {
> + status = "okay";
> +};
> +
> +&i2c0 {
> + clock-frequency = <400000>;
> + i2c-scl-rising-time-ns = <168>;
> + i2c-scl-falling-time-ns = <4>;
> + status = "okay";
> +
> + rk808: pmic@1b {
> + compatible = "rockchip,rk808";
> + reg = <0x1b>;
> + interrupt-parent = <&gpio1>;
> + interrupts = <21 IRQ_TYPE_LEVEL_LOW>;
> + #clock-cells = <1>;
> + clock-output-names = "xin32k", "rk808-clkout2";
> + pinctrl-names = "default";
> + pinctrl-0 = <&pmic_int_l>;
> + rockchip,system-power-controller;
> + wakeup-source;
> +
> + vcc1-supply = <&vcc5v0_sys>;
> + vcc2-supply = <&vcc5v0_sys>;
> + vcc3-supply = <&vcc5v0_sys>;
> + vcc4-supply = <&vcc5v0_sys>;
> + vcc6-supply = <&vcc5v0_sys>;
> + vcc7-supply = <&vcc5v0_sys>;
> + vcc8-supply = <&vcc3v3_sys>;
> + vcc9-supply = <&vcc5v0_sys>;
> + vcc10-supply = <&vcc5v0_sys>;
> + vcc11-supply = <&vcc5v0_sys>;
> + vcc12-supply = <&vcc3v3_sys>;
> + vddio-supply = <&vcc_1v8>;
> +
> + regulators {
> + vdd_center: DCDC_REG1 {
> + regulator-name = "vdd_center";
> + regulator-always-on;
> + regulator-boot-on;
> + regulator-min-microvolt = <750000>;
> + regulator-max-microvolt = <1350000>;
> + regulator-ramp-delay = <6001>;
> + regulator-state-mem {
> + regulator-off-in-suspend;
> + };
> + };
> +
> + vdd_cpu_l: DCDC_REG2 {
> + regulator-name = "vdd_cpu_l";
> + regulator-always-on;
> + regulator-boot-on;
> + regulator-min-microvolt = <750000>;
> + regulator-max-microvolt = <1350000>;
> + regulator-ramp-delay = <6001>;
> + regulator-state-mem {
> + regulator-off-in-suspend;
> + };
> + };
> +
> + vcc_ddr: DCDC_REG3 {
> + regulator-name = "vcc_ddr";
> + regulator-always-on;
> + regulator-boot-on;
> + regulator-state-mem {
> + regulator-on-in-suspend;
> + };
> + };
> +
> + vcc_1v8: DCDC_REG4 {
> + regulator-name = "vcc_1v8";
> + regulator-always-on;
> + regulator-boot-on;
> + regulator-min-microvolt = <1800000>;
> + regulator-max-microvolt = <1800000>;
> + regulator-state-mem {
> + regulator-on-in-suspend;
> + regulator-suspend-microvolt = <1800000>;
> + };
> + };
> +
> + vcc1v8_dvp: LDO_REG1 {
> + regulator-name = "vcc1v8_dvp";
> + regulator-always-on;
> + regulator-boot-on;
> + regulator-min-microvolt = <1800000>;
> + regulator-max-microvolt = <1800000>;
> + regulator-state-mem {
> + regulator-off-in-suspend;
> + };
> + };
> +
> + vcc1v8_hdmi: LDO_REG2 {
> + regulator-name = "vcc1v8_hdmi";
> + regulator-always-on;
> + regulator-boot-on;
> + regulator-min-microvolt = <1800000>;
> + regulator-max-microvolt = <1800000>;
> + regulator-state-mem {
> + regulator-off-in-suspend;
> + };
> + };
> +
> + vcca_1v8: LDO_REG3 {
> + regulator-name = "vcca_1v8";
> + regulator-always-on;
> + regulator-boot-on;
> + regulator-min-microvolt = <1800000>;
> + regulator-max-microvolt = <1800000>;
> + regulator-state-mem {
> + regulator-on-in-suspend;
> + regulator-suspend-microvolt = <1800000>;
> + };
> + };
> +
> + vccio_sd: LDO_REG4 {
> + regulator-name = "vccio_sd";
> + regulator-always-on;
> + regulator-boot-on;
> + regulator-min-microvolt = <3000000>;
> + regulator-max-microvolt = <3000000>;
> + regulator-state-mem {
> + regulator-on-in-suspend;
> + regulator-suspend-microvolt = <3000000>;
> + };
> + };
> +
> + vcca3v0_codec: LDO_REG5 {
> + regulator-name = "vcca3v0_codec";
> + regulator-always-on;
> + regulator-boot-on;
> + regulator-min-microvolt = <3000000>;
> + regulator-max-microvolt = <3000000>;
> + regulator-state-mem {
> + regulator-off-in-suspend;
> + };
> + };
> +
> + vcc_1v5: LDO_REG6 {
> + regulator-name = "vcc_1v5";
> + regulator-always-on;
> + regulator-boot-on;
> + regulator-min-microvolt = <1500000>;
> + regulator-max-microvolt = <1500000>;
> + regulator-state-mem {
> + regulator-on-in-suspend;
> + regulator-suspend-microvolt = <1500000>;
> + };
> + };
> +
> + vcc0v9_hdmi: LDO_REG7 {
> + regulator-name = "vcc0v9_hdmi";
> + regulator-always-on;
> + regulator-boot-on;
> + regulator-min-microvolt = <900000>;
> + regulator-max-microvolt = <900000>;
> + regulator-state-mem {
> + regulator-off-in-suspend;
> + };
> + };
> +
> + vcc_3v0: LDO_REG8 {
> + regulator-name = "vcc_3v0";
> + regulator-always-on;
> + regulator-boot-on;
> + regulator-min-microvolt = <3000000>;
> + regulator-max-microvolt = <3000000>;
> + regulator-state-mem {
> + regulator-on-in-suspend;
> + regulator-suspend-microvolt = <3000000>;
> + };
> + };
> +
unneeded blank line
> + };
> + };
> +
Heiko
_______________________________________________
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 06/34] drm/i915: convert put_page() to put_user_page*()
From: John Hubbard @ 2019-08-03 20:03 UTC (permalink / raw)
To: Joonas Lahtinen, Andrew Morton, john.hubbard
Cc: linux-fbdev, Jan Kara, kvm, David Airlie, Dave Hansen,
Dave Chinner, dri-devel, linux-mm, sparclinux, Ira Weiny,
ceph-devel, devel, rds-devel, linux-rdma, x86, amd-gfx,
Christoph Hellwig, Jason Gunthorpe, xen-devel, devel, linux-media,
intel-gfx, Jani Nikula, linux-block, Jérôme Glisse,
linux-rpi-kernel, Rodrigo Vivi, Dan Williams, linux-arm-kernel,
linux-nfs, netdev, LKML, linux-xfs, linux-crypto, linux-fsdevel
In-Reply-To: <7d9a9c57-4322-270b-b636-7214019f87e9@nvidia.com>
On 8/2/19 11:48 AM, John Hubbard wrote:
> On 8/2/19 2:19 AM, Joonas Lahtinen wrote:
>> Quoting john.hubbard@gmail.com (2019-08-02 05:19:37)
>>> From: John Hubbard <jhubbard@nvidia.com>
...
> In order to deal with the merge problem, I'll drop this patch from my series,
> and I'd recommend that the drm-intel-next take the following approach:
Actually, I just pulled the latest linux.git, and there are a few changes:
>
> 1) For now, s/put_page/put_user_page/ in i915_gem_userptr_put_pages(),
> and fix up the set_page_dirty() --> set_page_dirty_lock() issue, like this
> (based against linux.git):
>
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_userptr.c b/drivers/gpu/drm/i915/gem/i915_gem_userptr.c
> index 528b61678334..94721cc0093b 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_userptr.c
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_userptr.c
> @@ -664,10 +664,10 @@ i915_gem_userptr_put_pages(struct drm_i915_gem_object *obj,
>
> for_each_sgt_page(page, sgt_iter, pages) {
> if (obj->mm.dirty)
> - set_page_dirty(page);
> + set_page_dirty_lock(page);
I see you've already applied this fix to your tree, in linux.git already.
>
> mark_page_accessed(page);
> - put_page(page);
> + put_user_page(page);
But this conversion still needs doing. So I'll repost a patch that only does
this (plus the other call sites).
That can go in via either your tree, or Andrew's -mm tree, without generating
any conflicts.
thanks,
--
John Hubbard
NVIDIA
_______________________________________________
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 6/6] arm64: dts: meson-g12b-khadas-vim3: add initial device-tree
From: Martin Blumenstingl @ 2019-08-03 18:50 UTC (permalink / raw)
To: Neil Armstrong
Cc: khilman, Christian Hewitt, linux-kernel, linux-arm-kernel,
linux-amlogic
In-Reply-To: <20190731124000.22072-7-narmstrong@baylibre.com>
On Wed, Jul 31, 2019 at 2:44 PM Neil Armstrong <narmstrong@baylibre.com> wrote:
[...]
> + memory@0 {
> + device_type = "memory";
> + reg = <0x0 0x0 0x0 0x40000000>;
nit-pick: we typically use the memory size used in the board size with
the lowest amount of RAM - 2GiB in this case. so I would change it to
0x80000000
[...]
> + leds {
> + compatible = "gpio-leds";
> +
> + white {
> + label = "vim3:white";
downstream sources use label="sys_led"
should we call it vim3:white:sys?
_______________________________________________
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] net: mdio-octeon: Fix Kconfig warnings and build errors
From: Randy Dunlap @ 2019-08-03 18:34 UTC (permalink / raw)
To: Nathan Chancellor
Cc: devel, andrew, f.fainelli, lkp, kernel-build-reports, gregkh,
willy, broonie, linux-next, netdev, davem, linux-arm-kernel,
hkallweit1
In-Reply-To: <20190803060155.89548-1-natechancellor@gmail.com>
On 8/2/19 11:01 PM, Nathan Chancellor wrote:
> After commit 171a9bae68c7 ("staging/octeon: Allow test build on
> !MIPS"), the following combination of configs cause a few Kconfig
> warnings and build errors (distilled from arm allyesconfig and Randy's
> randconfig builds):
>
> CONFIG_NETDEVICES=y
> CONFIG_STAGING=y
> CONFIG_COMPILE_TEST=y
>
> and CONFIG_OCTEON_ETHERNET as either a module or built-in.
>
> WARNING: unmet direct dependencies detected for MDIO_OCTEON
> Depends on [n]: NETDEVICES [=y] && MDIO_DEVICE [=y] && MDIO_BUS [=y]
> && 64BIT [=n] && HAS_IOMEM [=y] && OF_MDIO [=n]
> Selected by [y]:
> - OCTEON_ETHERNET [=y] && STAGING [=y] && (CAVIUM_OCTEON_SOC ||
> COMPILE_TEST [=y]) && NETDEVICES [=y]
>
> In file included from ../drivers/net/phy/mdio-octeon.c:14:
> ../drivers/net/phy/mdio-cavium.h:111:36: error: implicit declaration of
> function ‘writeq’; did you mean ‘writel’?
> [-Werror=implicit-function-declaration]
> 111 | #define oct_mdio_writeq(val, addr) writeq(val, (void *)addr)
> | ^~~~~~
>
> CONFIG_64BIT is not strictly necessary if the proper readq/writeq
> definitions are included from io-64-nonatomic-lo-hi.h.
>
> CONFIG_OF_MDIO is not needed when CONFIG_COMPILE_TEST is enabled because
> of commit f9dc9ac51610 ("of/mdio: Add dummy functions in of_mdio.h.").
>
> Fixes: 171a9bae68c7 ("staging/octeon: Allow test build on !MIPS")
> Reported-by: kbuild test robot <lkp@intel.com>
> Reported-by: Mark Brown <broonie@kernel.org>
> Reported-by: Randy Dunlap <rdunlap@infradead.org>
> Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
Works for me. Fixes the reported build errors. Thanks.
Acked-by: Randy Dunlap <rdunlap@infradead.org> # build-tested
> ---
>
> v1 -> v2:
>
> * Address Randy's reported failure here: https://lore.kernel.org/netdev/b3444283-7a77-ece8-7ac6-41756aa7dc60@infradead.org/
> by not requiring CONFIG_OF_MDIO when CONFIG_COMPILE_TEST is set.
>
> * Improve commit message
>
> drivers/net/phy/Kconfig | 4 ++--
> drivers/net/phy/mdio-cavium.h | 2 ++
> 2 files changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/net/phy/Kconfig b/drivers/net/phy/Kconfig
> index 20f14c5fbb7e..0e3d9e3d3533 100644
> --- a/drivers/net/phy/Kconfig
> +++ b/drivers/net/phy/Kconfig
> @@ -159,8 +159,8 @@ config MDIO_MSCC_MIIM
>
> config MDIO_OCTEON
> tristate "Octeon and some ThunderX SOCs MDIO buses"
> - depends on 64BIT
> - depends on HAS_IOMEM && OF_MDIO
> + depends on (64BIT && OF_MDIO) || COMPILE_TEST
> + depends on HAS_IOMEM
> select MDIO_CAVIUM
> help
> This module provides a driver for the Octeon and ThunderX MDIO
> diff --git a/drivers/net/phy/mdio-cavium.h b/drivers/net/phy/mdio-cavium.h
> index ed5f9bb5448d..b7f89ad27465 100644
> --- a/drivers/net/phy/mdio-cavium.h
> +++ b/drivers/net/phy/mdio-cavium.h
> @@ -108,6 +108,8 @@ static inline u64 oct_mdio_readq(u64 addr)
> return cvmx_read_csr(addr);
> }
> #else
> +#include <linux/io-64-nonatomic-lo-hi.h>
> +
> #define oct_mdio_writeq(val, addr) writeq(val, (void *)addr)
> #define oct_mdio_readq(addr) readq((void *)addr)
> #endif
>
--
~Randy
_______________________________________________
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/4] clk: meson: add g12a cpu dynamic divider driver
From: Martin Blumenstingl @ 2019-08-03 18:34 UTC (permalink / raw)
To: Neil Armstrong
Cc: linux-amlogic, linux-clk, linux-kernel, linux-arm-kernel, jbrunet
In-Reply-To: <20190731084019.8451-3-narmstrong@baylibre.com>
On Wed, Jul 31, 2019 at 10:41 AM Neil Armstrong <narmstrong@baylibre.com> wrote:
>
> Add a clock driver for the cpu dynamic divider, this divider needs
> to have a flag set before setting the divider value then removed
> while writing the new value to the register.
>
> This drivers implements this behavior and will be used essentially
> on the Amlogic G12A and G12B SoCs for cpu clock trees.
>
> Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
Reviewed-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
personally I would add:
Suggested-by: Jerome Brunet <jbrunet@baylibre.com>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox