* [PATCH 13/19] drm/sun4i: backend: Set a default zpos in our reset hook
From: Maxime Ripard @ 2018-01-09 10:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cover.713e47b83733ed05f0c38f5ba6ef8b6c1e32805c.1515494838.git-series.maxime.ripard@free-electrons.com>
The our plane state zpos value will be set only if there's an existing
state attached to the plane when creating the property.
However, this is not the case during the probe, and we therefore need to
put our default value in our reset hook.
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
---
drivers/gpu/drm/sun4i/sun4i_layer.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/sun4i/sun4i_layer.c b/drivers/gpu/drm/sun4i/sun4i_layer.c
index c448cb6b9fa9..03549646528a 100644
--- a/drivers/gpu/drm/sun4i/sun4i_layer.c
+++ b/drivers/gpu/drm/sun4i/sun4i_layer.c
@@ -28,6 +28,7 @@ struct sun4i_plane_desc {
static void sun4i_backend_layer_reset(struct drm_plane *plane)
{
+ struct sun4i_layer *layer = plane_to_sun4i_layer(plane);
struct sun4i_layer_state *state;
if (plane->state) {
@@ -43,6 +44,7 @@ static void sun4i_backend_layer_reset(struct drm_plane *plane)
if (state) {
plane->state = &state->state;
plane->state->plane = plane;
+ plane->state->zpos = layer->id;
}
}
--
git-series 0.9.1
^ permalink raw reply related
* [PATCH 14/19] drm/sun4i: backend: Add support for zpos
From: Maxime Ripard @ 2018-01-09 10:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cover.713e47b83733ed05f0c38f5ba6ef8b6c1e32805c.1515494838.git-series.maxime.ripard@free-electrons.com>
Our various planes have a configurable zpos, that combined with the pipes
allow to configure the composition.
Since the interaction between the pipes, zpos and alphas framebuffers are
not trivials, let's just enable the zpos as an immutable property for now,
and use that zpos in our atomic_update part.
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
---
drivers/gpu/drm/sun4i/sun4i_backend.c | 15 +++++++++++++++
drivers/gpu/drm/sun4i/sun4i_backend.h | 2 ++
drivers/gpu/drm/sun4i/sun4i_framebuffer.c | 4 ++++
drivers/gpu/drm/sun4i/sun4i_layer.c | 3 +++
4 files changed, 24 insertions(+)
diff --git a/drivers/gpu/drm/sun4i/sun4i_backend.c b/drivers/gpu/drm/sun4i/sun4i_backend.c
index a18c86a15748..c4986054909b 100644
--- a/drivers/gpu/drm/sun4i/sun4i_backend.c
+++ b/drivers/gpu/drm/sun4i/sun4i_backend.c
@@ -272,6 +272,21 @@ int sun4i_backend_update_layer_buffer(struct sun4i_backend *backend,
return 0;
}
+int sun4i_backend_update_layer_zpos(struct sun4i_backend *backend, int layer,
+ struct drm_plane *plane)
+{
+ struct drm_plane_state *state = plane->state;
+ unsigned int priority = state->normalized_zpos;
+
+ DRM_DEBUG_DRIVER("Setting layer %d priority to %d\n", layer, priority);
+
+ regmap_update_bits(backend->engine.regs, SUN4I_BACKEND_ATTCTL_REG0(layer),
+ SUN4I_BACKEND_ATTCTL_REG0_LAY_PRISEL_MASK,
+ SUN4I_BACKEND_ATTCTL_REG0_LAY_PRISEL(priority));
+
+ return 0;
+}
+
static bool sun4i_backend_plane_uses_scaler(struct drm_plane_state *state)
{
u16 src_h = state->src_h >> 16;
diff --git a/drivers/gpu/drm/sun4i/sun4i_backend.h b/drivers/gpu/drm/sun4i/sun4i_backend.h
index 1ca8b7db6807..04a4f11b87a8 100644
--- a/drivers/gpu/drm/sun4i/sun4i_backend.h
+++ b/drivers/gpu/drm/sun4i/sun4i_backend.h
@@ -182,5 +182,7 @@ int sun4i_backend_update_layer_buffer(struct sun4i_backend *backend,
int layer, struct drm_plane *plane);
int sun4i_backend_update_layer_frontend(struct sun4i_backend *backend,
int layer, uint32_t in_fmt);
+int sun4i_backend_update_layer_zpos(struct sun4i_backend *backend,
+ int layer, struct drm_plane *plane);
#endif /* _SUN4I_BACKEND_H_ */
diff --git a/drivers/gpu/drm/sun4i/sun4i_framebuffer.c b/drivers/gpu/drm/sun4i/sun4i_framebuffer.c
index e68004844abe..5b3986437a50 100644
--- a/drivers/gpu/drm/sun4i/sun4i_framebuffer.c
+++ b/drivers/gpu/drm/sun4i/sun4i_framebuffer.c
@@ -35,6 +35,10 @@ static int sun4i_de_atomic_check(struct drm_device *dev,
if (ret)
return ret;
+ ret = drm_atomic_normalize_zpos(dev, state);
+ if (ret)
+ return ret;
+
return drm_atomic_helper_check_planes(dev, state);
}
diff --git a/drivers/gpu/drm/sun4i/sun4i_layer.c b/drivers/gpu/drm/sun4i/sun4i_layer.c
index 03549646528a..fbf25d59cf88 100644
--- a/drivers/gpu/drm/sun4i/sun4i_layer.c
+++ b/drivers/gpu/drm/sun4i/sun4i_layer.c
@@ -115,6 +115,7 @@ static void sun4i_backend_layer_atomic_update(struct drm_plane *plane,
}
sun4i_backend_update_layer_coord(backend, layer->id, plane);
+ sun4i_backend_update_layer_zpos(backend, layer->id, plane);
sun4i_backend_layer_enable(backend, layer->id, true);
}
@@ -237,6 +238,8 @@ struct drm_plane **sun4i_layers_init(struct drm_device *drm,
return ERR_CAST(layer);
};
+ drm_plane_create_zpos_immutable_property(&layer->plane, i);
+
DRM_DEBUG_DRIVER("Assigning %s plane to pipe %d\n",
i ? "overlay" : "primary", plane->pipe);
regmap_update_bits(engine->regs, SUN4I_BACKEND_ATTCTL_REG0(i),
--
git-series 0.9.1
^ permalink raw reply related
* [PATCH 15/19] drm/sun4i: backend: Check for the number of alpha planes
From: Maxime Ripard @ 2018-01-09 10:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cover.713e47b83733ed05f0c38f5ba6ef8b6c1e32805c.1515494838.git-series.maxime.ripard@free-electrons.com>
Due to the way the composition is done in hardware, we can only have a
single alpha-enabled plane active at a time, placed in the second (highest
priority) pipe.
Make sure of that in our atomic_check to not end up in an impossible
scenario.
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
---
drivers/gpu/drm/sun4i/sun4i_backend.c | 50 ++++++++++++++++++++++++++++-
drivers/gpu/drm/sun4i/sun4i_backend.h | 2 +-
drivers/gpu/drm/sun4i/sun4i_layer.c | 23 +-------------
3 files changed, 53 insertions(+), 22 deletions(-)
diff --git a/drivers/gpu/drm/sun4i/sun4i_backend.c b/drivers/gpu/drm/sun4i/sun4i_backend.c
index c4986054909b..dd995a6b8b12 100644
--- a/drivers/gpu/drm/sun4i/sun4i_backend.c
+++ b/drivers/gpu/drm/sun4i/sun4i_backend.c
@@ -329,6 +329,8 @@ static int sun4i_backend_atomic_check(struct sunxi_engine *engine,
struct drm_atomic_state *state = crtc_state->state;
struct drm_device *drm = state->dev;
struct drm_plane *plane;
+ unsigned int num_planes = 0;
+ unsigned int num_alpha_planes = 0;
unsigned int num_frontend_planes = 0;
DRM_DEBUG_DRIVER("Starting checking our planes\n");
@@ -341,6 +343,7 @@ static int sun4i_backend_atomic_check(struct sunxi_engine *engine,
drm_atomic_get_plane_state(state, plane);
struct sun4i_layer_state *layer_state =
state_to_sun4i_layer_state(plane_state);
+ struct drm_framebuffer *fb = plane_state->fb;
if (sun4i_backend_plane_uses_frontend(plane_state)) {
DRM_DEBUG_DRIVER("Using the frontend for plane %d\n",
@@ -351,6 +354,50 @@ static int sun4i_backend_atomic_check(struct sunxi_engine *engine,
} else {
layer_state->uses_frontend = false;
}
+
+ DRM_DEBUG_DRIVER("Plane FB format is %s\n",
+ drm_get_format_name(fb->format->format,
+ &format_name));
+ if (drm_format_has_alpha(fb->format->format))
+ num_alpha_planes++;
+
+ num_planes++;
+ }
+
+ /*
+ * The hardware is a bit unusual here.
+ *
+ * Even though it supports 4 layers, it does the composition
+ * in two separate steps.
+ *
+ * The first one is assigning a layer to one of its two
+ * pipes. If more that 1 layer is assigned to the same pipe,
+ * and if pixels overlaps, the pipe will take the pixel from
+ * the layer with the highest priority.
+ *
+ * The second step is the actual alpha blending, that takes
+ * the two pipes as input, and uses the eventual alpha
+ * component to do the transparency between the two.
+ *
+ * This two steps scenario makes us unable to guarantee a
+ * robust alpha blending between the 4 layers in all
+ * situations, since this means that we need to have one layer
+ * with alpha at the lowest position of our two pipes.
+ *
+ * However, we cannot even do that, since the hardware has a
+ * bug where the lowest plane of the lowest pipe (pipe 0,
+ * priority 0), if it has any alpha, will discard the pixel
+ * entirely and just display the pixels in the background
+ * color (black by default).
+ *
+ * Since means that we effectively have only three valid
+ * configurations with alpha, all of them with the alpha being
+ * on pipe1 with the lowest position, which can be 1, 2 or 3
+ * depending on the number of planes and their zpos.
+ */
+ if (num_alpha_planes > SUN4I_BACKEND_NUM_ALPHA_LAYERS) {
+ DRM_DEBUG_DRIVER("Too many planes with alpha, rejecting...\n");
+ return -EINVAL;
}
if (num_frontend_planes > SUN4I_BACKEND_NUM_FRONTEND_LAYERS) {
@@ -358,6 +405,9 @@ static int sun4i_backend_atomic_check(struct sunxi_engine *engine,
return -EINVAL;
}
+ DRM_DEBUG_DRIVER("State valid with %u planes, %u alpha, %u video\n",
+ num_planes, num_alpha_planes, num_frontend_planes);
+
return 0;
}
diff --git a/drivers/gpu/drm/sun4i/sun4i_backend.h b/drivers/gpu/drm/sun4i/sun4i_backend.h
index 04a4f11b87a8..52e77591186a 100644
--- a/drivers/gpu/drm/sun4i/sun4i_backend.h
+++ b/drivers/gpu/drm/sun4i/sun4i_backend.h
@@ -146,6 +146,8 @@
#define SUN4I_BACKEND_HWCCOLORTAB_OFF 0x4c00
#define SUN4I_BACKEND_PIPE_OFF(p) (0x5000 + (0x400 * (p)))
+#define SUN4I_BACKEND_NUM_LAYERS 4
+#define SUN4I_BACKEND_NUM_ALPHA_LAYERS 1
#define SUN4I_BACKEND_NUM_FRONTEND_LAYERS 1
struct sun4i_backend {
diff --git a/drivers/gpu/drm/sun4i/sun4i_layer.c b/drivers/gpu/drm/sun4i/sun4i_layer.c
index fbf25d59cf88..900e716443b8 100644
--- a/drivers/gpu/drm/sun4i/sun4i_layer.c
+++ b/drivers/gpu/drm/sun4i/sun4i_layer.c
@@ -201,32 +201,11 @@ struct drm_plane **sun4i_layers_init(struct drm_device *drm,
struct sun4i_backend *backend = engine_to_sun4i_backend(engine);
int i;
- planes = devm_kcalloc(drm->dev, ARRAY_SIZE(sun4i_backend_planes) + 1,
+ planes = devm_kcalloc(drm->dev, SUN4I_BACKEND_NUM_LAYERS,
sizeof(*planes), GFP_KERNEL);
if (!planes)
return ERR_PTR(-ENOMEM);
- /*
- * The hardware is a bit unusual here.
- *
- * Even though it supports 4 layers, it does the composition
- * in two separate steps.
- *
- * The first one is assigning a layer to one of its two
- * pipes. If more that 1 layer is assigned to the same pipe,
- * and if pixels overlaps, the pipe will take the pixel from
- * the layer with the highest priority.
- *
- * The second step is the actual alpha blending, that takes
- * the two pipes as input, and uses the eventual alpha
- * component to do the transparency between the two.
- *
- * This two steps scenario makes us unable to guarantee a
- * robust alpha blending between the 4 layers in all
- * situations. So we just expose two layers, one per pipe. On
- * SoCs that support it, sprites could fill the need for more
- * layers.
- */
for (i = 0; i < ARRAY_SIZE(sun4i_backend_planes); i++) {
const struct sun4i_plane_desc *plane = &sun4i_backend_planes[i];
struct sun4i_layer *layer;
--
git-series 0.9.1
^ permalink raw reply related
* [PATCH 16/19] drm/sun4i: backend: Assign the pipes automatically
From: Maxime Ripard @ 2018-01-09 10:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cover.713e47b83733ed05f0c38f5ba6ef8b6c1e32805c.1515494838.git-series.maxime.ripard@free-electrons.com>
Since we now have a way to enforce the zpos, check for the number of alpha
planes, the only missing part is to assign our pipe automatically instead
of hardcoding it.
The algorithm is quite simple, but requires two iterations over the list of
planes.
In the first one (which is the same one that we've had to check for alpha,
the frontend usage, and so on), we order the planes by their zpos.
We can then do a second iteration over that array by ascending zpos
starting with the pipe 0. When and if we encounter our alpha plane, we put
it and all the other subsequent planes in the second pipe.
And since we have runtime checks and pipe assignments now, we can just
remove the static declaration of the planes we used to have.
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
---
drivers/gpu/drm/sun4i/sun4i_backend.c | 41 +++++++++++++++++++++--
drivers/gpu/drm/sun4i/sun4i_layer.c | 50 ++++------------------------
drivers/gpu/drm/sun4i/sun4i_layer.h | 1 +-
3 files changed, 48 insertions(+), 44 deletions(-)
diff --git a/drivers/gpu/drm/sun4i/sun4i_backend.c b/drivers/gpu/drm/sun4i/sun4i_backend.c
index dd995a6b8b12..ad370ce66b4d 100644
--- a/drivers/gpu/drm/sun4i/sun4i_backend.c
+++ b/drivers/gpu/drm/sun4i/sun4i_backend.c
@@ -276,12 +276,16 @@ int sun4i_backend_update_layer_zpos(struct sun4i_backend *backend, int layer,
struct drm_plane *plane)
{
struct drm_plane_state *state = plane->state;
+ struct sun4i_layer_state *p_state = state_to_sun4i_layer_state(state);
unsigned int priority = state->normalized_zpos;
+ unsigned int pipe = p_state->pipe;
- DRM_DEBUG_DRIVER("Setting layer %d priority to %d\n", layer, priority);
-
+ DRM_DEBUG_DRIVER("Setting layer %d priority to %d and pipe %d\n",
+ layer, priority, pipe);
regmap_update_bits(backend->engine.regs, SUN4I_BACKEND_ATTCTL_REG0(layer),
+ SUN4I_BACKEND_ATTCTL_REG0_LAY_PIPESEL_MASK |
SUN4I_BACKEND_ATTCTL_REG0_LAY_PRISEL_MASK,
+ SUN4I_BACKEND_ATTCTL_REG0_LAY_PIPESEL(p_state->pipe) |
SUN4I_BACKEND_ATTCTL_REG0_LAY_PRISEL(priority));
return 0;
@@ -326,12 +330,15 @@ static void sun4i_backend_atomic_begin(struct sunxi_engine *engine,
static int sun4i_backend_atomic_check(struct sunxi_engine *engine,
struct drm_crtc_state *crtc_state)
{
+ struct drm_plane_state *plane_states[SUN4I_BACKEND_NUM_LAYERS] = { 0 };
struct drm_atomic_state *state = crtc_state->state;
struct drm_device *drm = state->dev;
struct drm_plane *plane;
unsigned int num_planes = 0;
unsigned int num_alpha_planes = 0;
unsigned int num_frontend_planes = 0;
+ unsigned int current_pipe = 0;
+ unsigned int i;
DRM_DEBUG_DRIVER("Starting checking our planes\n");
@@ -344,6 +351,7 @@ static int sun4i_backend_atomic_check(struct sunxi_engine *engine,
struct sun4i_layer_state *layer_state =
state_to_sun4i_layer_state(plane_state);
struct drm_framebuffer *fb = plane_state->fb;
+ struct drm_format_name_buf format_name;
if (sun4i_backend_plane_uses_frontend(plane_state)) {
DRM_DEBUG_DRIVER("Using the frontend for plane %d\n",
@@ -361,9 +369,19 @@ static int sun4i_backend_atomic_check(struct sunxi_engine *engine,
if (drm_format_has_alpha(fb->format->format))
num_alpha_planes++;
+ DRM_DEBUG_DRIVER("Plane zpos is %d\n",
+ plane_state->normalized_zpos);
+
+ /* Sort our planes by Zpos */
+ plane_states[plane_state->normalized_zpos] = plane_state;
+
num_planes++;
}
+ /* All our planes were disabled, bail out */
+ if (!num_planes)
+ return 0;
+
/*
* The hardware is a bit unusual here.
*
@@ -400,6 +418,25 @@ static int sun4i_backend_atomic_check(struct sunxi_engine *engine,
return -EINVAL;
}
+ /* We can't have an alpha plane at the lowest position */
+ if (drm_format_has_alpha(plane_states[0]->fb->format->format))
+ return -EINVAL;
+
+ for (i = 1; i < num_planes; i++) {
+ struct drm_plane_state *p_state = plane_states[i];
+ struct drm_framebuffer *fb = p_state->fb;
+ struct sun4i_layer_state *s_state = state_to_sun4i_layer_state(p_state);
+
+ /*
+ * The only alpha position is the lowest plane of the
+ * second pipe.
+ */
+ if (drm_format_has_alpha(fb->format->format))
+ current_pipe++;
+
+ s_state->pipe = current_pipe;
+ }
+
if (num_frontend_planes > SUN4I_BACKEND_NUM_FRONTEND_LAYERS) {
DRM_DEBUG_DRIVER("Too many planes going through the frontend, rejecting\n");
return -EINVAL;
diff --git a/drivers/gpu/drm/sun4i/sun4i_layer.c b/drivers/gpu/drm/sun4i/sun4i_layer.c
index 900e716443b8..ec7b906dbb84 100644
--- a/drivers/gpu/drm/sun4i/sun4i_layer.c
+++ b/drivers/gpu/drm/sun4i/sun4i_layer.c
@@ -19,13 +19,6 @@
#include "sun4i_layer.h"
#include "sunxi_engine.h"
-struct sun4i_plane_desc {
- enum drm_plane_type type;
- u8 pipe;
- const uint32_t *formats;
- uint32_t nformats;
-};
-
static void sun4i_backend_layer_reset(struct drm_plane *plane)
{
struct sun4i_layer *layer = plane_to_sun4i_layer(plane);
@@ -133,14 +126,7 @@ static const struct drm_plane_funcs sun4i_backend_layer_funcs = {
.update_plane = drm_atomic_helper_update_plane,
};
-static const uint32_t sun4i_backend_layer_formats_primary[] = {
- DRM_FORMAT_ARGB8888,
- DRM_FORMAT_RGB888,
- DRM_FORMAT_RGB565,
- DRM_FORMAT_XRGB8888,
-};
-
-static const uint32_t sun4i_backend_layer_formats_overlay[] = {
+static const uint32_t sun4i_backend_layer_formats[] = {
DRM_FORMAT_ARGB8888,
DRM_FORMAT_ARGB4444,
DRM_FORMAT_ARGB1555,
@@ -151,24 +137,9 @@ static const uint32_t sun4i_backend_layer_formats_overlay[] = {
DRM_FORMAT_XRGB8888,
};
-static const struct sun4i_plane_desc sun4i_backend_planes[] = {
- {
- .type = DRM_PLANE_TYPE_PRIMARY,
- .pipe = 0,
- .formats = sun4i_backend_layer_formats_primary,
- .nformats = ARRAY_SIZE(sun4i_backend_layer_formats_primary),
- },
- {
- .type = DRM_PLANE_TYPE_OVERLAY,
- .pipe = 1,
- .formats = sun4i_backend_layer_formats_overlay,
- .nformats = ARRAY_SIZE(sun4i_backend_layer_formats_overlay),
- },
-};
-
static struct sun4i_layer *sun4i_layer_init_one(struct drm_device *drm,
struct sun4i_backend *backend,
- const struct sun4i_plane_desc *plane)
+ enum drm_plane_type type)
{
struct sun4i_layer *layer;
int ret;
@@ -180,8 +151,9 @@ static struct sun4i_layer *sun4i_layer_init_one(struct drm_device *drm,
/* possible crtcs are set later */
ret = drm_universal_plane_init(drm, &layer->plane, 0,
&sun4i_backend_layer_funcs,
- plane->formats, plane->nformats,
- NULL, plane->type, NULL);
+ sun4i_backend_layer_formats,
+ ARRAY_SIZE(sun4i_backend_layer_formats),
+ NULL, type, NULL);
if (ret) {
dev_err(drm->dev, "Couldn't initialize layer\n");
return ERR_PTR(ret);
@@ -206,11 +178,11 @@ struct drm_plane **sun4i_layers_init(struct drm_device *drm,
if (!planes)
return ERR_PTR(-ENOMEM);
- for (i = 0; i < ARRAY_SIZE(sun4i_backend_planes); i++) {
- const struct sun4i_plane_desc *plane = &sun4i_backend_planes[i];
+ for (i = 0; i < SUN4I_BACKEND_NUM_LAYERS; i++) {
+ enum drm_plane_type type = i ? DRM_PLANE_TYPE_OVERLAY : DRM_PLANE_TYPE_PRIMARY;
struct sun4i_layer *layer;
- layer = sun4i_layer_init_one(drm, backend, plane);
+ layer = sun4i_layer_init_one(drm, backend, type);
if (IS_ERR(layer)) {
dev_err(drm->dev, "Couldn't initialize %s plane\n",
i ? "overlay" : "primary");
@@ -219,12 +191,6 @@ struct drm_plane **sun4i_layers_init(struct drm_device *drm,
drm_plane_create_zpos_immutable_property(&layer->plane, i);
- DRM_DEBUG_DRIVER("Assigning %s plane to pipe %d\n",
- i ? "overlay" : "primary", plane->pipe);
- regmap_update_bits(engine->regs, SUN4I_BACKEND_ATTCTL_REG0(i),
- SUN4I_BACKEND_ATTCTL_REG0_LAY_PIPESEL_MASK,
- SUN4I_BACKEND_ATTCTL_REG0_LAY_PIPESEL(plane->pipe));
-
layer->id = i;
planes[i] = &layer->plane;
};
diff --git a/drivers/gpu/drm/sun4i/sun4i_layer.h b/drivers/gpu/drm/sun4i/sun4i_layer.h
index 75b4868ba87c..36b20265bd31 100644
--- a/drivers/gpu/drm/sun4i/sun4i_layer.h
+++ b/drivers/gpu/drm/sun4i/sun4i_layer.h
@@ -24,6 +24,7 @@ struct sun4i_layer {
struct sun4i_layer_state {
struct drm_plane_state state;
+ unsigned int pipe;
bool uses_frontend;
};
--
git-series 0.9.1
^ permalink raw reply related
* [PATCH 17/19] drm/sun4i: backend: Make zpos configurable
From: Maxime Ripard @ 2018-01-09 10:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cover.713e47b83733ed05f0c38f5ba6ef8b6c1e32805c.1515494838.git-series.maxime.ripard@free-electrons.com>
Now that we have everything in place, we can make zpos configurable now.
Change the zpos property from an immutable one to a regular.
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
---
drivers/gpu/drm/sun4i/sun4i_layer.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/sun4i/sun4i_layer.c b/drivers/gpu/drm/sun4i/sun4i_layer.c
index ec7b906dbb84..9e538f761dcb 100644
--- a/drivers/gpu/drm/sun4i/sun4i_layer.c
+++ b/drivers/gpu/drm/sun4i/sun4i_layer.c
@@ -163,6 +163,9 @@ static struct sun4i_layer *sun4i_layer_init_one(struct drm_device *drm,
&sun4i_backend_layer_helper_funcs);
layer->backend = backend;
+ drm_plane_create_zpos_property(&layer->plane, 0, 0,
+ SUN4I_BACKEND_NUM_LAYERS - 1);
+
return layer;
}
@@ -189,8 +192,6 @@ struct drm_plane **sun4i_layers_init(struct drm_device *drm,
return ERR_CAST(layer);
};
- drm_plane_create_zpos_immutable_property(&layer->plane, i);
-
layer->id = i;
planes[i] = &layer->plane;
};
--
git-series 0.9.1
^ permalink raw reply related
* [PATCH 18/19] drm/sun4i: Add support for plane alpha
From: Maxime Ripard @ 2018-01-09 10:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cover.713e47b83733ed05f0c38f5ba6ef8b6c1e32805c.1515494838.git-series.maxime.ripard@free-electrons.com>
Our backend supports a per-plane alpha property. Support it through our new
helper.
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
---
drivers/gpu/drm/sun4i/sun4i_backend.c | 18 +++++++++++++++---
drivers/gpu/drm/sun4i/sun4i_backend.h | 3 +++
drivers/gpu/drm/sun4i/sun4i_layer.c | 2 ++
3 files changed, 20 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/sun4i/sun4i_backend.c b/drivers/gpu/drm/sun4i/sun4i_backend.c
index ad370ce66b4d..ec47098bfdb2 100644
--- a/drivers/gpu/drm/sun4i/sun4i_backend.c
+++ b/drivers/gpu/drm/sun4i/sun4i_backend.c
@@ -191,6 +191,15 @@ int sun4i_backend_update_layer_formats(struct sun4i_backend *backend,
DRM_DEBUG_DRIVER("Switching display backend interlaced mode %s\n",
interlaced ? "on" : "off");
+ val = SUN4I_BACKEND_ATTCTL_REG0_LAY_GLBALPHA(state->alpha);
+ if (state->alpha != 255)
+ val |= SUN4I_BACKEND_ATTCTL_REG0_LAY_GLBALPHA_EN;
+ regmap_update_bits(backend->engine.regs,
+ SUN4I_BACKEND_ATTCTL_REG0(layer),
+ SUN4I_BACKEND_ATTCTL_REG0_LAY_GLBALPHA_MASK |
+ SUN4I_BACKEND_ATTCTL_REG0_LAY_GLBALPHA_EN,
+ val);
+
ret = sun4i_backend_drm_format_to_layer(plane, fb->format->format,
&val);
if (ret) {
@@ -366,7 +375,8 @@ static int sun4i_backend_atomic_check(struct sunxi_engine *engine,
DRM_DEBUG_DRIVER("Plane FB format is %s\n",
drm_get_format_name(fb->format->format,
&format_name));
- if (drm_format_has_alpha(fb->format->format))
+ if (drm_format_has_alpha(fb->format->format) ||
+ (plane_state->alpha != 255))
num_alpha_planes++;
DRM_DEBUG_DRIVER("Plane zpos is %d\n",
@@ -419,7 +429,8 @@ static int sun4i_backend_atomic_check(struct sunxi_engine *engine,
}
/* We can't have an alpha plane at the lowest position */
- if (drm_format_has_alpha(plane_states[0]->fb->format->format))
+ if (drm_format_has_alpha(plane_states[0]->fb->format->format) ||
+ (plane_states[0]->alpha != 255))
return -EINVAL;
for (i = 1; i < num_planes; i++) {
@@ -431,7 +442,8 @@ static int sun4i_backend_atomic_check(struct sunxi_engine *engine,
* The only alpha position is the lowest plane of the
* second pipe.
*/
- if (drm_format_has_alpha(fb->format->format))
+ if (drm_format_has_alpha(fb->format->format) ||
+ (p_state->alpha != 255))
current_pipe++;
s_state->pipe = current_pipe;
diff --git a/drivers/gpu/drm/sun4i/sun4i_backend.h b/drivers/gpu/drm/sun4i/sun4i_backend.h
index 52e77591186a..03294d5dd1a2 100644
--- a/drivers/gpu/drm/sun4i/sun4i_backend.h
+++ b/drivers/gpu/drm/sun4i/sun4i_backend.h
@@ -68,11 +68,14 @@
#define SUN4I_BACKEND_CKMIN_REG 0x884
#define SUN4I_BACKEND_CKCFG_REG 0x888
#define SUN4I_BACKEND_ATTCTL_REG0(l) (0x890 + (0x4 * (l)))
+#define SUN4I_BACKEND_ATTCTL_REG0_LAY_GLBALPHA_MASK GENMASK(31, 24)
+#define SUN4I_BACKEND_ATTCTL_REG0_LAY_GLBALPHA(x) ((x) << 24)
#define SUN4I_BACKEND_ATTCTL_REG0_LAY_PIPESEL_MASK BIT(15)
#define SUN4I_BACKEND_ATTCTL_REG0_LAY_PIPESEL(x) ((x) << 15)
#define SUN4I_BACKEND_ATTCTL_REG0_LAY_PRISEL_MASK GENMASK(11, 10)
#define SUN4I_BACKEND_ATTCTL_REG0_LAY_PRISEL(x) ((x) << 10)
#define SUN4I_BACKEND_ATTCTL_REG0_LAY_VDOEN BIT(1)
+#define SUN4I_BACKEND_ATTCTL_REG0_LAY_GLBALPHA_EN BIT(0)
#define SUN4I_BACKEND_ATTCTL_REG1(l) (0x8a0 + (0x4 * (l)))
#define SUN4I_BACKEND_ATTCTL_REG1_LAY_HSCAFCT GENMASK(15, 14)
diff --git a/drivers/gpu/drm/sun4i/sun4i_layer.c b/drivers/gpu/drm/sun4i/sun4i_layer.c
index 9e538f761dcb..d5598de92f85 100644
--- a/drivers/gpu/drm/sun4i/sun4i_layer.c
+++ b/drivers/gpu/drm/sun4i/sun4i_layer.c
@@ -37,6 +37,7 @@ static void sun4i_backend_layer_reset(struct drm_plane *plane)
if (state) {
plane->state = &state->state;
plane->state->plane = plane;
+ plane->state->alpha = 255;
plane->state->zpos = layer->id;
}
}
@@ -163,6 +164,7 @@ static struct sun4i_layer *sun4i_layer_init_one(struct drm_device *drm,
&sun4i_backend_layer_helper_funcs);
layer->backend = backend;
+ drm_plane_create_alpha_property(&layer->plane, 255);
drm_plane_create_zpos_property(&layer->plane, 0, 0,
SUN4I_BACKEND_NUM_LAYERS - 1);
--
git-series 0.9.1
^ permalink raw reply related
* [PATCH 19/19] drm/sun4i: backend: Remove ARGB spoofing
From: Maxime Ripard @ 2018-01-09 10:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cover.713e47b83733ed05f0c38f5ba6ef8b6c1e32805c.1515494838.git-series.maxime.ripard@free-electrons.com>
We've had some code for quite some time to prevent the alpha bug from
happening on the lowest primary plane. Since we now check for this in our
atomic_check, we can simply remove it.
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
---
drivers/gpu/drm/sun4i/sun4i_backend.c | 12 +++---------
1 file changed, 3 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/sun4i/sun4i_backend.c b/drivers/gpu/drm/sun4i/sun4i_backend.c
index ec47098bfdb2..15a7bce27412 100644
--- a/drivers/gpu/drm/sun4i/sun4i_backend.c
+++ b/drivers/gpu/drm/sun4i/sun4i_backend.c
@@ -92,13 +92,8 @@ void sun4i_backend_layer_enable(struct sun4i_backend *backend,
SUN4I_BACKEND_MODCTL_LAY_EN(layer), val);
}
-static int sun4i_backend_drm_format_to_layer(struct drm_plane *plane,
- u32 format, u32 *mode)
+static int sun4i_backend_drm_format_to_layer(u32 format, u32 *mode)
{
- if (plane && (plane->type == DRM_PLANE_TYPE_PRIMARY) &&
- (format == DRM_FORMAT_ARGB8888))
- format = DRM_FORMAT_XRGB8888;
-
switch (format) {
case DRM_FORMAT_ARGB8888:
*mode = SUN4I_BACKEND_LAY_FBFMT_ARGB8888;
@@ -200,8 +195,7 @@ int sun4i_backend_update_layer_formats(struct sun4i_backend *backend,
SUN4I_BACKEND_ATTCTL_REG0_LAY_GLBALPHA_EN,
val);
- ret = sun4i_backend_drm_format_to_layer(plane, fb->format->format,
- &val);
+ ret = sun4i_backend_drm_format_to_layer(fb->format->format, &val);
if (ret) {
DRM_DEBUG_DRIVER("Invalid format\n");
return ret;
@@ -220,7 +214,7 @@ int sun4i_backend_update_layer_frontend(struct sun4i_backend *backend,
u32 val;
int ret;
- ret = sun4i_backend_drm_format_to_layer(NULL, fmt, &val);
+ ret = sun4i_backend_drm_format_to_layer(fmt, &val);
if (ret) {
DRM_DEBUG_DRIVER("Invalid format\n");
return ret;
--
git-series 0.9.1
^ permalink raw reply related
* [PATCH] ARM: imx: Improve the soc revision calculation flow
From: A.s. Dong @ 2018-01-09 10:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1515486632-18488-1-git-send-email-ping.bai@nxp.com>
Hi Jacky,
> -----Original Message-----
> From: Jacky Bai
> Sent: Tuesday, January 09, 2018 4:31 PM
> To: shawnguo at kernel.org; kernel at pengutronix.de; Fabio Estevam
> <fabio.estevam@nxp.com>
> Cc: linux-arm-kernel at lists.infradead.org; dl-linux-imx <linux-imx@nxp.com>;
> A.s. Dong <aisheng.dong@nxp.com>; jacky.baip at gmail.com
> Subject: [PATCH] ARM: imx: Improve the soc revision calculation flow
>
> On our i.MX6 SOC, the DIGPROG register is used for representing the SOC ID
> and silicon revision. The revision has two part: MAJOR and MINOR. each is
> represented in 8 bits in the register.
>
> bits [15:8]: reflect the MAJOR part of the revision; bits [7:0]: reflect the MINOR
> part of the revision;
>
> In our linux kernel, the soc revision is represented in 8 bits.
> MAJOR part and MINOR each occupy 4 bits.
>
> previous method does NOT take care about the MAJOR part in DIGPROG
> register. So reformat the revision read from the HW to be compatible with the
> revision format used in kernel.
>
It would be better if there's more clarification on the real effect of this patch in commit
message.
e.g. what real issue it could be if without this patch?
I guess it would show rev over 2.x correctly, right?
BTW, since this patch totally remove the using of already defined rev macros,
I wonder if it's a good idea.
Just a thought, how about do something like mx3 which keeps using the macros?
static struct {
u8 srev;
const char *name;
unsigned int rev;
} mx31_cpu_type[] = {
{ .srev = 0x00, .name = "i.MX31(L)", .rev = IMX_CHIP_REVISION_1_0 },
{ .srev = 0x10, .name = "i.MX31", .rev = IMX_CHIP_REVISION_1_1 },
{ .srev = 0x11, .name = "i.MX31L", .rev = IMX_CHIP_REVISION_1_1 },
{ .srev = 0x12, .name = "i.MX31", .rev = IMX_CHIP_REVISION_1_1 },
{ .srev = 0x13, .name = "i.MX31L", .rev = IMX_CHIP_REVISION_1_1 },
{ .srev = 0x14, .name = "i.MX31", .rev = IMX_CHIP_REVISION_1_2 },
{ .srev = 0x15, .name = "i.MX31L", .rev = IMX_CHIP_REVISION_1_2 },
{ .srev = 0x28, .name = "i.MX31", .rev = IMX_CHIP_REVISION_2_0 },
{ .srev = 0x29, .name = "i.MX31L", .rev = IMX_CHIP_REVISION_2_0 },
};
static int mx31_read_cpu_rev(void)
Regards
Dong Aisheng
> Signed-off-by: Bai Ping <ping.bai@nxp.com>
> ---
> arch/arm/mach-imx/anatop.c | 58 +++++++++++++++++--------------------------
> ---
> 1 file changed, 21 insertions(+), 37 deletions(-)
>
> diff --git a/arch/arm/mach-imx/anatop.c b/arch/arm/mach-imx/anatop.c index
> 649a84c..170cb30 100644
> --- a/arch/arm/mach-imx/anatop.c
> +++ b/arch/arm/mach-imx/anatop.c
> @@ -1,5 +1,6 @@
> /*
> * Copyright (C) 2013-2015 Freescale Semiconductor, Inc.
> + * Copyright NXP 2017.
> *
> * The code contained herein is licensed under the GNU General Public
> * License. You may obtain a copy of the GNU General Public License @@ -
> 116,6 +117,8 @@ void __init imx_init_revision_from_anatop(void)
> unsigned int revision;
> u32 digprog;
> u16 offset = ANADIG_DIGPROG;
> + u16 major_part, minor_part;
> +
>
> np = of_find_compatible_node(NULL, NULL, "fsl,imx6q-anatop");
> anatop_base = of_iomap(np, 0);
> @@ -127,45 +130,26 @@ void __init imx_init_revision_from_anatop(void)
> digprog = readl_relaxed(anatop_base + offset);
> iounmap(anatop_base);
>
> - switch (digprog & 0xff) {
> - case 0:
> - /*
> - * For i.MX6QP, most of the code for i.MX6Q can be resued,
> - * so internally, we identify it as i.MX6Q Rev 2.0
> - */
> - if (digprog >> 8 & 0x01)
> - revision = IMX_CHIP_REVISION_2_0;
> - else
> - revision = IMX_CHIP_REVISION_1_0;
> - break;
> - case 1:
> - revision = IMX_CHIP_REVISION_1_1;
> - break;
> - case 2:
> - revision = IMX_CHIP_REVISION_1_2;
> - break;
> - case 3:
> - revision = IMX_CHIP_REVISION_1_3;
> - break;
> - case 4:
> - revision = IMX_CHIP_REVISION_1_4;
> - break;
> - case 5:
> - /*
> - * i.MX6DQ TO1.5 is defined as Rev 1.3 in Data Sheet, marked
> - * as 'D' in Part Number last character.
> - */
> - revision = IMX_CHIP_REVISION_1_5;
> - break;
> - default:
> - /*
> - * Fail back to return raw register value instead of 0xff.
> - * It will be easy to know version information in SOC if it
> - * can't be recognized by known version. And some chip's
> (i.MX7D)
> - * digprog value match linux version format, so it needn't map
> - * again and we can use register value directly.
> + /*
> + * On i.MX7D digprog value match linux version format, so
> + * it needn't map again and we can use register value directly.
> + */
> + if (of_device_is_compatible(np, "fsl,imx7d-anatop")) {
> + revision = digprog & 0xff;
> + } else {
> +
> + /* MAJOR: [15:8], the major silicon revison;
> + * MINOR: [7: 0], the minor silicon revison;
> + *
> + * please refer to the i.MX RM for the detailed
> + * silicon revison bit define.
> + * format the major part and minor part to match the
> + * linux kernel soc version format.
> */
> revision = digprog & 0xff;
> + major_part = (digprog >> 8) & 0xf;
> + minor_part = digprog & 0xf;
> + revision = ((major_part + 1) << 4) | minor_part;
> }
>
> mxc_set_cpu_type(digprog >> 16 & 0xff);
> --
> 1.9.1
^ permalink raw reply
* [RESEND PATCH] ARM: pinctrl: sunxi-pinctrl: fix pin funtion can not be match correctly.
From: Maxime Ripard @ 2018-01-09 11:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180109055902.GA1306@arx-s1>
On Tue, Jan 09, 2018 at 01:59:02PM +0800, hao_zhang wrote:
> Pin function can not be match correctly when SUNXI_PIN describe with
> mutiple variant and same function.
>
> such as:
> on pinctrl-sun4i-a10.c
>
> SUNXI_PIN(SUNXI_PINCTRL_PIN(B, 2),
> SUNXI_FUNCTION(0x0, "gpio_in"),
> SUNXI_FUNCTION(0x1, "gpio_out"),
> SUNXI_FUNCTION_VARIANT(0x2, "pwm", /* PWM0 */
> PINCTRL_SUN4I_A10 |
> PINCTRL_SUN7I_A20),
> SUNXI_FUNCTION_VARIANT(0x3, "pwm", /* PWM0 */
> PINCTRL_SUN8I_R40)),
>
> it would always match to the first variant function
> (PINCTRL_SUN4I_A10, PINCTRL_SUN7I_A20)
>
> so we should add variant compare on it.
>
> Regards
> Hao
>
> Signed-off-by: hao_zhang <hao5781286@gmail.com>
Acked-by: Maxime Ripard <maxime.ripard@free-electrons.com>
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20180109/d70f6fc5/attachment-0001.sig>
^ permalink raw reply
* [PATCH] arm64: Implement branch predictor hardening for Falkor
From: Catalin Marinas @ 2018-01-09 11:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180109094146.GB4297@arm.com>
On Tue, Jan 09, 2018 at 09:41:46AM +0000, Will Deacon wrote:
> You'll need to send a fixup patch. for-next/core is non-rebasing.
I haven't pushed it out yet (will do this morning) but note that
for-next/core is based on 4.15-rc3.
--
Catalin
^ permalink raw reply
* [PATCH 00/12] Marvell NAND controller rework with ->exec_op()
From: Miquel RAYNAL @ 2018-01-09 11:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <87zi5nbh14.fsf@belgarion.home>
Hello Robert,
On Tue, 09 Jan 2018 08:57:59 +0100
Robert Jarzmik <robert.jarzmik@free.fr> wrote:
> Boris Brezillon <boris.brezillon@free-electrons.com> writes:
>
> Ok I recovered my NAND.
>
> For the next try, I'd like you to provide another "temporary patch"
> to disable BBT actual writing, just to be sure. Once the driver is
> working properly, I'll make another try without the temporary patch.
The best way to do it is to avoid using the BBT at all, and while I was
looking for the right line to comment in the Zylonite's board file I
found out that the boolean flash_bbt is not actually set and then I
remembered an old mail from you, then you should:
----->8-----
diff --git a/arch/arm/mach-pxa/zylonite.c b/arch/arm/mach-pxa/zylonite.c
index 0534949d63f6..d247ef01dc62 100644
--- a/arch/arm/mach-pxa/zylonite.c
+++ b/arch/arm/mach-pxa/zylonite.c
@@ -378,6 +378,8 @@ static struct mtd_partition
zylonite_nand_partitions[] = { static struct pxa3xx_nand_platform_data
zylonite_nand_info = { .parts = zylonite_nand_partitions,
.nr_parts = ARRAY_SIZE(zylonite_nand_partitions),
- .flash_bbt = 1,
.keep_config = 1,
};
static void __init zylonite_init_nand(void)
-----8<-----
Then, do not forget to resize the partition that stores the BBT to
remove the last 4 erase blocks from it to avoid UBI/UBIFS smashing it.
Then you should be fine.
You can test this branch (updated with last version I sent earlier):
https://github.com/miquelraynal/linux/tree/marvell/nand-next/nfc
Thanks,
Miqu?l
^ permalink raw reply related
* [PATCH] ARM: imx: Improve the soc revision calculation flow
From: Jacky Bai @ 2018-01-09 11:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <AM3PR04MB30614F10E6938D057D83A8180100@AM3PR04MB306.eurprd04.prod.outlook.com>
> -----Original Message-----
> From: A.s. Dong
> Sent: 2018?1?9? 18:59
> To: Jacky Bai <ping.bai@nxp.com>; shawnguo at kernel.org;
> kernel at pengutronix.de; Fabio Estevam <fabio.estevam@nxp.com>
> Cc: linux-arm-kernel at lists.infradead.org; dl-linux-imx <linux-imx@nxp.com>;
> jacky.baip at gmail.com
> Subject: RE: [PATCH] ARM: imx: Improve the soc revision calculation flow
>
> Hi Jacky,
>
> > -----Original Message-----
> > From: Jacky Bai
> > Sent: Tuesday, January 09, 2018 4:31 PM
> > To: shawnguo at kernel.org; kernel at pengutronix.de; Fabio Estevam
> > <fabio.estevam@nxp.com>
> > Cc: linux-arm-kernel at lists.infradead.org; dl-linux-imx
> > <linux-imx@nxp.com>; A.s. Dong <aisheng.dong@nxp.com>;
> > jacky.baip at gmail.com
> > Subject: [PATCH] ARM: imx: Improve the soc revision calculation flow
> >
> > On our i.MX6 SOC, the DIGPROG register is used for representing the
> > SOC ID and silicon revision. The revision has two part: MAJOR and
> > MINOR. each is represented in 8 bits in the register.
> >
> > bits [15:8]: reflect the MAJOR part of the revision; bits [7:0]:
> > reflect the MINOR part of the revision;
> >
> > In our linux kernel, the soc revision is represented in 8 bits.
> > MAJOR part and MINOR each occupy 4 bits.
> >
> > previous method does NOT take care about the MAJOR part in DIGPROG
> > register. So reformat the revision read from the HW to be compatible
> > with the revision format used in kernel.
> >
>
> It would be better if there's more clarification on the real effect of this patch in
> commit message.
> e.g. what real issue it could be if without this patch?
>
> I guess it would show rev over 2.x correctly, right?
Yes, this patch is mainly for fix the >= 2.1 revision issue we meet on QP.
>
> BTW, since this patch totally remove the using of already defined rev macros, I
> wonder if it's a good idea.
>
> Just a thought, how about do something like mx3 which keeps using the macros?
>
As anatop module is common for all i.MX 6SL, SLL, Solo, DL, DQ, DQP and 7D, If we use the way like mx3,
Maybe we need to add many static struct to cover all the above platform?
BR
Jacky Bai
> static struct {
> u8 srev;
> const char *name;
> unsigned int rev;
> } mx31_cpu_type[] = {
> { .srev = 0x00, .name = "i.MX31(L)", .rev = IMX_CHIP_REVISION_1_0 },
> { .srev = 0x10, .name = "i.MX31", .rev =
> IMX_CHIP_REVISION_1_1 },
> { .srev = 0x11, .name = "i.MX31L", .rev =
> IMX_CHIP_REVISION_1_1 },
> { .srev = 0x12, .name = "i.MX31", .rev =
> IMX_CHIP_REVISION_1_1 },
> { .srev = 0x13, .name = "i.MX31L", .rev =
> IMX_CHIP_REVISION_1_1 },
> { .srev = 0x14, .name = "i.MX31", .rev =
> IMX_CHIP_REVISION_1_2 },
> { .srev = 0x15, .name = "i.MX31L", .rev =
> IMX_CHIP_REVISION_1_2 },
> { .srev = 0x28, .name = "i.MX31", .rev =
> IMX_CHIP_REVISION_2_0 },
> { .srev = 0x29, .name = "i.MX31L", .rev =
> IMX_CHIP_REVISION_2_0 },
> };
> static int mx31_read_cpu_rev(void)
>
> Regards
> Dong Aisheng
>
>
> > Signed-off-by: Bai Ping <ping.bai@nxp.com>
> > ---
> > arch/arm/mach-imx/anatop.c | 58
> > +++++++++++++++++--------------------------
> > ---
> > 1 file changed, 21 insertions(+), 37 deletions(-)
> >
> > diff --git a/arch/arm/mach-imx/anatop.c b/arch/arm/mach-imx/anatop.c
> > index
> > 649a84c..170cb30 100644
> > --- a/arch/arm/mach-imx/anatop.c
> > +++ b/arch/arm/mach-imx/anatop.c
> > @@ -1,5 +1,6 @@
> > /*
> > * Copyright (C) 2013-2015 Freescale Semiconductor, Inc.
> > + * Copyright NXP 2017.
> > *
> > * The code contained herein is licensed under the GNU General Public
> > * License. You may obtain a copy of the GNU General Public License
> > @@ -
> > 116,6 +117,8 @@ void __init imx_init_revision_from_anatop(void)
> > unsigned int revision;
> > u32 digprog;
> > u16 offset = ANADIG_DIGPROG;
> > + u16 major_part, minor_part;
> > +
> >
> > np = of_find_compatible_node(NULL, NULL, "fsl,imx6q-anatop");
> > anatop_base = of_iomap(np, 0);
> > @@ -127,45 +130,26 @@ void __init imx_init_revision_from_anatop(void)
> > digprog = readl_relaxed(anatop_base + offset);
> > iounmap(anatop_base);
> >
> > - switch (digprog & 0xff) {
> > - case 0:
> > - /*
> > - * For i.MX6QP, most of the code for i.MX6Q can be resued,
> > - * so internally, we identify it as i.MX6Q Rev 2.0
> > - */
> > - if (digprog >> 8 & 0x01)
> > - revision = IMX_CHIP_REVISION_2_0;
> > - else
> > - revision = IMX_CHIP_REVISION_1_0;
> > - break;
> > - case 1:
> > - revision = IMX_CHIP_REVISION_1_1;
> > - break;
> > - case 2:
> > - revision = IMX_CHIP_REVISION_1_2;
> > - break;
> > - case 3:
> > - revision = IMX_CHIP_REVISION_1_3;
> > - break;
> > - case 4:
> > - revision = IMX_CHIP_REVISION_1_4;
> > - break;
> > - case 5:
> > - /*
> > - * i.MX6DQ TO1.5 is defined as Rev 1.3 in Data Sheet, marked
> > - * as 'D' in Part Number last character.
> > - */
> > - revision = IMX_CHIP_REVISION_1_5;
> > - break;
> > - default:
> > - /*
> > - * Fail back to return raw register value instead of 0xff.
> > - * It will be easy to know version information in SOC if it
> > - * can't be recognized by known version. And some chip's
> > (i.MX7D)
> > - * digprog value match linux version format, so it needn't map
> > - * again and we can use register value directly.
> > + /*
> > + * On i.MX7D digprog value match linux version format, so
> > + * it needn't map again and we can use register value directly.
> > + */
> > + if (of_device_is_compatible(np, "fsl,imx7d-anatop")) {
> > + revision = digprog & 0xff;
> > + } else {
> > +
> > + /* MAJOR: [15:8], the major silicon revison;
> > + * MINOR: [7: 0], the minor silicon revison;
> > + *
> > + * please refer to the i.MX RM for the detailed
> > + * silicon revison bit define.
> > + * format the major part and minor part to match the
> > + * linux kernel soc version format.
> > */
> > revision = digprog & 0xff;
> > + major_part = (digprog >> 8) & 0xf;
> > + minor_part = digprog & 0xf;
> > + revision = ((major_part + 1) << 4) | minor_part;
> > }
> >
> > mxc_set_cpu_type(digprog >> 16 & 0xff);
> > --
> > 1.9.1
^ permalink raw reply
* [PATCH] ARM: imx: Improve the soc revision calculation flow
From: A.s. Dong @ 2018-01-09 11:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <HE1PR04MB311350113E67477E2D0A55D187100@HE1PR04MB3113.eurprd04.prod.outlook.com>
> -----Original Message-----
> From: Jacky Bai
> Sent: Tuesday, January 09, 2018 7:07 PM
> To: A.s. Dong <aisheng.dong@nxp.com>; shawnguo at kernel.org;
> kernel at pengutronix.de; Fabio Estevam <fabio.estevam@nxp.com>
> Cc: linux-arm-kernel at lists.infradead.org; dl-linux-imx <linux-imx@nxp.com>;
> jacky.baip at gmail.com
> Subject: RE: [PATCH] ARM: imx: Improve the soc revision calculation flow
>
>
>
> > -----Original Message-----
> > From: A.s. Dong
> > Sent: 2018?1?9? 18:59
> > To: Jacky Bai <ping.bai@nxp.com>; shawnguo at kernel.org;
> > kernel at pengutronix.de; Fabio Estevam <fabio.estevam@nxp.com>
> > Cc: linux-arm-kernel at lists.infradead.org; dl-linux-imx
> > <linux-imx@nxp.com>; jacky.baip at gmail.com
> > Subject: RE: [PATCH] ARM: imx: Improve the soc revision calculation
> > flow
> >
> > Hi Jacky,
> >
> > > -----Original Message-----
> > > From: Jacky Bai
> > > Sent: Tuesday, January 09, 2018 4:31 PM
> > > To: shawnguo at kernel.org; kernel at pengutronix.de; Fabio Estevam
> > > <fabio.estevam@nxp.com>
> > > Cc: linux-arm-kernel at lists.infradead.org; dl-linux-imx
> > > <linux-imx@nxp.com>; A.s. Dong <aisheng.dong@nxp.com>;
> > > jacky.baip at gmail.com
> > > Subject: [PATCH] ARM: imx: Improve the soc revision calculation flow
> > >
> > > On our i.MX6 SOC, the DIGPROG register is used for representing the
> > > SOC ID and silicon revision. The revision has two part: MAJOR and
> > > MINOR. each is represented in 8 bits in the register.
> > >
> > > bits [15:8]: reflect the MAJOR part of the revision; bits [7:0]:
> > > reflect the MINOR part of the revision;
> > >
> > > In our linux kernel, the soc revision is represented in 8 bits.
> > > MAJOR part and MINOR each occupy 4 bits.
> > >
> > > previous method does NOT take care about the MAJOR part in DIGPROG
> > > register. So reformat the revision read from the HW to be compatible
> > > with the revision format used in kernel.
> > >
> >
> > It would be better if there's more clarification on the real effect of
> > this patch in commit message.
> > e.g. what real issue it could be if without this patch?
> >
> > I guess it would show rev over 2.x correctly, right?
>
>
> Yes, this patch is mainly for fix the >= 2.1 revision issue we meet on QP.
>
> >
> > BTW, since this patch totally remove the using of already defined rev
> > macros, I wonder if it's a good idea.
> >
> > Just a thought, how about do something like mx3 which keeps using the
> macros?
> >
>
> As anatop module is common for all i.MX 6SL, SLL, Solo, DL, DQ, DQP and 7D, If
> we use the way like mx3, Maybe we need to add many static struct to cover all
> the above platform?
Yes, as the data you used actually are according to rev macros. So a bit strange not use.
Shawn,
Or what your suggestion?
Regards
Dong Aisheng
>
> BR
> Jacky Bai
> > static struct {
> > u8 srev;
> > const char *name;
> > unsigned int rev;
> > } mx31_cpu_type[] = {
> > { .srev = 0x00, .name = "i.MX31(L)", .rev = IMX_CHIP_REVISION_1_0 },
> > { .srev = 0x10, .name = "i.MX31", .rev =
> > IMX_CHIP_REVISION_1_1 },
> > { .srev = 0x11, .name = "i.MX31L", .rev =
> > IMX_CHIP_REVISION_1_1 },
> > { .srev = 0x12, .name = "i.MX31", .rev =
> > IMX_CHIP_REVISION_1_1 },
> > { .srev = 0x13, .name = "i.MX31L", .rev =
> > IMX_CHIP_REVISION_1_1 },
> > { .srev = 0x14, .name = "i.MX31", .rev =
> > IMX_CHIP_REVISION_1_2 },
> > { .srev = 0x15, .name = "i.MX31L", .rev =
> > IMX_CHIP_REVISION_1_2 },
> > { .srev = 0x28, .name = "i.MX31", .rev =
> > IMX_CHIP_REVISION_2_0 },
> > { .srev = 0x29, .name = "i.MX31L", .rev =
> > IMX_CHIP_REVISION_2_0 },
> > };
> > static int mx31_read_cpu_rev(void)
> >
> > Regards
> > Dong Aisheng
> >
> >
> > > Signed-off-by: Bai Ping <ping.bai@nxp.com>
> > > ---
> > > arch/arm/mach-imx/anatop.c | 58
> > > +++++++++++++++++--------------------------
> > > ---
> > > 1 file changed, 21 insertions(+), 37 deletions(-)
> > >
> > > diff --git a/arch/arm/mach-imx/anatop.c b/arch/arm/mach-imx/anatop.c
> > > index
> > > 649a84c..170cb30 100644
> > > --- a/arch/arm/mach-imx/anatop.c
> > > +++ b/arch/arm/mach-imx/anatop.c
> > > @@ -1,5 +1,6 @@
> > > /*
> > > * Copyright (C) 2013-2015 Freescale Semiconductor, Inc.
> > > + * Copyright NXP 2017.
> > > *
> > > * The code contained herein is licensed under the GNU General Public
> > > * License. You may obtain a copy of the GNU General Public License
> > > @@ -
> > > 116,6 +117,8 @@ void __init imx_init_revision_from_anatop(void)
> > > unsigned int revision;
> > > u32 digprog;
> > > u16 offset = ANADIG_DIGPROG;
> > > + u16 major_part, minor_part;
> > > +
> > >
> > > np = of_find_compatible_node(NULL, NULL, "fsl,imx6q-anatop");
> > > anatop_base = of_iomap(np, 0);
> > > @@ -127,45 +130,26 @@ void __init imx_init_revision_from_anatop(void)
> > > digprog = readl_relaxed(anatop_base + offset);
> > > iounmap(anatop_base);
> > >
> > > - switch (digprog & 0xff) {
> > > - case 0:
> > > - /*
> > > - * For i.MX6QP, most of the code for i.MX6Q can be resued,
> > > - * so internally, we identify it as i.MX6Q Rev 2.0
> > > - */
> > > - if (digprog >> 8 & 0x01)
> > > - revision = IMX_CHIP_REVISION_2_0;
> > > - else
> > > - revision = IMX_CHIP_REVISION_1_0;
> > > - break;
> > > - case 1:
> > > - revision = IMX_CHIP_REVISION_1_1;
> > > - break;
> > > - case 2:
> > > - revision = IMX_CHIP_REVISION_1_2;
> > > - break;
> > > - case 3:
> > > - revision = IMX_CHIP_REVISION_1_3;
> > > - break;
> > > - case 4:
> > > - revision = IMX_CHIP_REVISION_1_4;
> > > - break;
> > > - case 5:
> > > - /*
> > > - * i.MX6DQ TO1.5 is defined as Rev 1.3 in Data Sheet, marked
> > > - * as 'D' in Part Number last character.
> > > - */
> > > - revision = IMX_CHIP_REVISION_1_5;
> > > - break;
> > > - default:
> > > - /*
> > > - * Fail back to return raw register value instead of 0xff.
> > > - * It will be easy to know version information in SOC if it
> > > - * can't be recognized by known version. And some chip's
> > > (i.MX7D)
> > > - * digprog value match linux version format, so it needn't map
> > > - * again and we can use register value directly.
> > > + /*
> > > + * On i.MX7D digprog value match linux version format, so
> > > + * it needn't map again and we can use register value directly.
> > > + */
> > > + if (of_device_is_compatible(np, "fsl,imx7d-anatop")) {
> > > + revision = digprog & 0xff;
> > > + } else {
> > > +
> > > + /* MAJOR: [15:8], the major silicon revison;
> > > + * MINOR: [7: 0], the minor silicon revison;
> > > + *
> > > + * please refer to the i.MX RM for the detailed
> > > + * silicon revison bit define.
> > > + * format the major part and minor part to match the
> > > + * linux kernel soc version format.
> > > */
> > > revision = digprog & 0xff;
> > > + major_part = (digprog >> 8) & 0xf;
> > > + minor_part = digprog & 0xf;
> > > + revision = ((major_part + 1) << 4) | minor_part;
> > > }
> > >
> > > mxc_set_cpu_type(digprog >> 16 & 0xff);
> > > --
> > > 1.9.1
^ permalink raw reply
* arm: Is VFP hotplug notifiers wrong?
From: Kohji Okuno @ 2018-01-09 11:12 UTC (permalink / raw)
To: linux-arm-kernel
Dear Thomas and all,
Could you please confirm about the following commit, again?
http://git.armlinux.org.uk/cgit/linux-arm.git/commit/arch/arm/vfp/vfpmodule.c?id=e5b61bafe70477e05e1dce0d6ca4ec181e23cb2a
The avobe commit eliminated the following fix, I think.
http://git.armlinux.org.uk/cgit/linux-arm.git/commit/arch/arm/vfp/vfpmodule.c?id=384b38b66947b06999b3e39a596d4f2fb94f77e4
vfp_force_reload() called from vfp_dying_cpu() does not clear
vfp_current_hw_state[cpu], because cpu stopper task does not own the
context held in the VFP hardware.
Best regards,
Kohji Okuno
^ permalink raw reply
* arm: Is VFP hotplug notifiers wrong?
From: Russell King - ARM Linux @ 2018-01-09 11:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180109.201221.1319754994300492102.okuno.kohji@jp.panasonic.com>
On Tue, Jan 09, 2018 at 08:12:21PM +0900, Kohji Okuno wrote:
> Dear Thomas and all,
>
> Could you please confirm about the following commit, again?
>
> http://git.armlinux.org.uk/cgit/linux-arm.git/commit/arch/arm/vfp/vfpmodule.c?id=e5b61bafe70477e05e1dce0d6ca4ec181e23cb2a
>
>
> The avobe commit eliminated the following fix, I think.
>
> http://git.armlinux.org.uk/cgit/linux-arm.git/commit/arch/arm/vfp/vfpmodule.c?id=384b38b66947b06999b3e39a596d4f2fb94f77e4
>
>
> vfp_force_reload() called from vfp_dying_cpu() does not clear
> vfp_current_hw_state[cpu], because cpu stopper task does not own the
> context held in the VFP hardware.
You are correct, tglx's patch was wrong, since the state in the CPU may
not be the current thread's state, so vfp_force_reload() may not do
anything.
vfp_force_reload() forces the reload of the specified state for the
specified CPU. What the original hotplug code did was to ensure that
the CPU's state would be reloaded when it came back up.
I do wish that people wouldn't combine functional changes and cleanups
into one patch - it makes this kind of thing harder to spot in review
and also means when we encounter crap like this, it means we can't
simply revert the cleanup.
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 8.8Mbps down 630kbps up
According to speedtest.net: 8.21Mbps down 510kbps up
^ permalink raw reply
* [PATCH 1/9] clk: samsung: exynos5433: Add clock flag to support suspend-to-ram
From: Krzysztof Kozlowski @ 2018-01-09 11:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1515484746-10656-2-git-send-email-cw00.choi@samsung.com>
On Tue, Jan 9, 2018 at 8:58 AM, Chanwoo Choi <cw00.choi@samsung.com> wrote:
> This patch adds the CLK_IS_CRITICAL and CLK_IGNORE_UNUSED flag
> to some clocks in order to avoid the hang-out in the suspend mode.
>
> Signed-off-by: Chanwoo Choi <cw00.choi@samsung.com>
> Cc: Tomasz Figa <tomasz.figa@gmail.com>
> Cc: Michael Turquette <mturquette@baylibre.com>
> Cc: Stephen Boyd <sboyd@codeaurora.org>
> Cc: linux-clk at vger.kernel.org
> ---
> drivers/clk/samsung/clk-exynos5433.c | 22 +++++++++++-----------
> 1 file changed, 11 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/clk/samsung/clk-exynos5433.c b/drivers/clk/samsung/clk-exynos5433.c
> index db270908037a..3dc53cd0c730 100644
> --- a/drivers/clk/samsung/clk-exynos5433.c
> +++ b/drivers/clk/samsung/clk-exynos5433.c
> @@ -583,25 +583,25 @@
> CLK_SET_RATE_PARENT | CLK_IGNORE_UNUSED, 0),
> GATE(CLK_ACLK_CAM1_333, "aclk_cam1_333", "div_aclk_cam1_333",
> ENABLE_ACLK_TOP, 13,
> - CLK_SET_RATE_PARENT | CLK_IGNORE_UNUSED, 0),
> + CLK_SET_RATE_PARENT | CLK_IS_CRITICAL, 0),
> GATE(CLK_ACLK_CAM1_400, "aclk_cam1_400", "div_aclk_cam1_400",
> ENABLE_ACLK_TOP, 12,
> CLK_SET_RATE_PARENT | CLK_IS_CRITICAL, 0),
> GATE(CLK_ACLK_CAM1_552, "aclk_cam1_552", "div_aclk_cam1_552",
> ENABLE_ACLK_TOP, 11,
> - CLK_SET_RATE_PARENT | CLK_IGNORE_UNUSED, 0),
> + CLK_SET_RATE_PARENT | CLK_IS_CRITICAL, 0),
> GATE(CLK_ACLK_CAM0_333, "aclk_cam0_333", "div_aclk_cam0_333",
> ENABLE_ACLK_TOP, 10,
> - CLK_SET_RATE_PARENT | CLK_IGNORE_UNUSED, 0),
> + CLK_SET_RATE_PARENT | CLK_IS_CRITICAL, 0),
> GATE(CLK_ACLK_CAM0_400, "aclk_cam0_400", "div_aclk_cam0_400",
> ENABLE_ACLK_TOP, 9,
> CLK_SET_RATE_PARENT | CLK_IS_CRITICAL, 0),
> GATE(CLK_ACLK_CAM0_552, "aclk_cam0_552", "div_aclk_cam0_552",
> ENABLE_ACLK_TOP, 8,
> - CLK_SET_RATE_PARENT | CLK_IGNORE_UNUSED, 0),
> + CLK_SET_RATE_PARENT | CLK_IS_CRITICAL, 0),
> GATE(CLK_ACLK_ISP_DIS_400, "aclk_isp_dis_400", "div_aclk_isp_dis_400",
> ENABLE_ACLK_TOP, 7,
> - CLK_SET_RATE_PARENT | CLK_IGNORE_UNUSED, 0),
> + CLK_SET_RATE_PARENT | CLK_IS_CRITICAL, 0),
> GATE(CLK_ACLK_ISP_400, "aclk_isp_400", "div_aclk_isp_400",
> ENABLE_ACLK_TOP, 6,
> CLK_SET_RATE_PARENT | CLK_IS_CRITICAL, 0),
> @@ -624,11 +624,11 @@
>
> /* ENABLE_SCLK_TOP_CAM1 */
> GATE(CLK_SCLK_ISP_SENSOR2, "sclk_isp_sensor2", "div_sclk_isp_sensor2_b",
> - ENABLE_SCLK_TOP_CAM1, 7, 0, 0),
> + ENABLE_SCLK_TOP_CAM1, 7, CLK_IGNORE_UNUSED, 0),
> GATE(CLK_SCLK_ISP_SENSOR1, "sclk_isp_sensor1", "div_sclk_isp_sensor1_b",
> ENABLE_SCLK_TOP_CAM1, 6, 0, 0),
> GATE(CLK_SCLK_ISP_SENSOR0, "sclk_isp_sensor0", "div_sclk_isp_sensor0_b",
> - ENABLE_SCLK_TOP_CAM1, 5, 0, 0),
> + ENABLE_SCLK_TOP_CAM1, 5, CLK_IGNORE_UNUSED, 0),
Marking this and few others related to ISP as ignore_unused or
is_critical looks like a hacky workaround for wrong topology or
missing clock users. The real cause should be fixed instead marking
all the clocks as critical or ignore_unused.
Best regards,
Krzysztof
> GATE(CLK_SCLK_ISP_MCTADC_CAM1, "sclk_isp_mctadc_cam1", "oscclk",
> ENABLE_SCLK_TOP_CAM1, 4, 0, 0),
> GATE(CLK_SCLK_ISP_UART_CAM1, "sclk_isp_uart_cam1", "div_sclk_isp_uart",
> @@ -636,7 +636,7 @@
> GATE(CLK_SCLK_ISP_SPI1_CAM1, "sclk_isp_spi1_cam1", "div_sclk_isp_spi1_b",
> ENABLE_SCLK_TOP_CAM1, 1, 0, 0),
> GATE(CLK_SCLK_ISP_SPI0_CAM1, "sclk_isp_spi0_cam1", "div_sclk_isp_spi0_b",
> - ENABLE_SCLK_TOP_CAM1, 0, 0, 0),
> + ENABLE_SCLK_TOP_CAM1, 0, CLK_IGNORE_UNUSED, 0),
>
> /* ENABLE_SCLK_TOP_DISP */
> GATE(CLK_SCLK_HDMI_SPDIF_DISP, "sclk_hdmi_spdif_disp",
> @@ -654,7 +654,7 @@
> ENABLE_SCLK_TOP_FSYS, 4, CLK_SET_RATE_PARENT, 0),
> GATE(CLK_SCLK_UFSUNIPRO_FSYS, "sclk_ufsunipro_fsys",
> "div_sclk_ufsunipro", ENABLE_SCLK_TOP_FSYS,
> - 3, CLK_SET_RATE_PARENT, 0),
> + 3, CLK_SET_RATE_PARENT | CLK_IS_CRITICAL, 0),
> GATE(CLK_SCLK_USBHOST30_FSYS, "sclk_usbhost30_fsys",
> "div_sclk_usbhost30", ENABLE_SCLK_TOP_FSYS,
> 1, CLK_SET_RATE_PARENT, 0),
> @@ -2982,7 +2982,7 @@ static void __init exynos5433_cmu_peris_init(struct device_node *np)
> GATE(CLK_PCLK_AUD_SLIMBUS, "pclk_aud_slimbus", "div_aclk_aud",
> ENABLE_PCLK_AUD, 6, 0, 0),
> GATE(CLK_PCLK_AUD_UART, "pclk_aud_uart", "div_aclk_aud",
> - ENABLE_PCLK_AUD, 5, 0, 0),
> + ENABLE_PCLK_AUD, 5, CLK_IS_CRITICAL, 0),
> GATE(CLK_PCLK_AUD_PCM, "pclk_aud_pcm", "div_aclk_aud",
> ENABLE_PCLK_AUD, 4, 0, 0),
> GATE(CLK_PCLK_AUD_I2S, "pclk_aud_i2s", "div_aclk_aud",
> @@ -3008,7 +3008,7 @@ static void __init exynos5433_cmu_peris_init(struct device_node *np)
> GATE(CLK_SCLK_AUD_SLIMBUS, "sclk_aud_slimbus", "div_sclk_aud_slimbus",
> ENABLE_SCLK_AUD1, 4, 0, 0),
> GATE(CLK_SCLK_AUD_UART, "sclk_aud_uart", "div_sclk_aud_uart",
> - ENABLE_SCLK_AUD1, 3, CLK_IGNORE_UNUSED, 0),
> + ENABLE_SCLK_AUD1, 3, CLK_IS_CRITICAL, 0),
> GATE(CLK_SCLK_AUD_PCM, "sclk_aud_pcm", "div_sclk_aud_pcm",
> ENABLE_SCLK_AUD1, 2, 0, 0),
> GATE(CLK_SCLK_I2S_BCLK, "sclk_i2s_bclk", "ioclk_i2s_bclk",
> --
> 1.9.1
>
^ permalink raw reply
* arm64 crashkernel fails to boot on acpi-only machines due to ACPI regions being no longer mapped as NOMAP
From: Bhupesh Sharma @ 2018-01-09 11:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180109030717.GA18820@linaro.org>
On Tue, Jan 9, 2018 at 10:12 AM, AKASHI Takahiro
<takahiro.akashi@linaro.org> wrote:
> Bhupesh,
>
> On Tue, Jan 09, 2018 at 01:30:07AM +0530, Bhupesh Sharma wrote:
>> Hello Akashi,
>>
>> On Tue, Dec 26, 2017 at 8:26 AM, Bhupesh Sharma <bhsharma@redhat.com> wrote:
>> > On Tue, Dec 26, 2017 at 7:58 AM, AKASHI Takahiro
>> > <takahiro.akashi@linaro.org> wrote:
>> >> On Tue, Dec 26, 2017 at 09:35:17AM +0800, Dave Young wrote:
>> >>> [snip]
>> >>> > > > Well, we may be able to change pr_warn() to pr_warn_once() here, but
>> >>> > > > I hope that adding "numa=off" to kernel command line should also work.
>> >>> > >
>> >>> > > Hmm, adding "numa=off" to crashkernel bootargs works, and TBH it was
>> >>> > > my initial thought process as well, but I am not sure if this will
>> >>> > > cause any regressions on aarch64 systems which use crashdump feature.
>> >>> >
>> >>> > It should be fine since we use numa=off by default for all other arches
>> >>> > ie. x86, ppc64 and s390. Actually disabling numa in kdump kernel can save
>> >>> > mm component memory usage.
>> >>> >
>> >>>
>> >>> Forgot to say I means in RHEL and Fedora we use numa=off for kdump..
>> >>
>> >> Thank you for the clarification.
>> >> (It might be better to make numa off automatically if maxcpus == 0 (and 1?).)
>> >>
>> >
>> > Not sure if we can leave this to the distribution-specific kdump
>> > scripts (as the crashkernel boot can be held up for sufficient time
>> > and may appear stuck). The distribution scripts may be different (for
>> > e.g. ubuntu and RHEL/fedora) across distributions and may have
>> > different bootarg options.
>> >
>> > So how about considering a kernel fix only which doesn't require
>> > relying on changing the distribution-specific kdump scripts, as we
>> > should avoid introducing a regression while trying to fix a regression
>> > :)
>> >
>> > Just my 2 cents.
>> >
>>
>> Sorry for the delay but I was on holidays in the last week.
>>
>> Are you planning to send a patch to fix this issue or do you want me
>> to send a RFC version instead?
>
> I should have submitted my own patch before my new year holidays,
> but I will do so as soon as possible.
Thanks for the confirmation.
I will look forward to the patches and give them a go on the arm64
boards available with me.
Regards,
Bhupesh
>
>> i think this is a blocking issue for aarch64 kdump support on newer
>> kernels (v4.14) and we are already hearing about this issue from other
>> users as well, so it would be great to get this fixed now that we have
>> root-caused the issue and found a possible way around.
>>
>> Regards,
>> Bhupesh
^ permalink raw reply
* [PATCH 1/3] ARM: dts: imx6ul-evk: Add support for mag3110 sensor
From: Marco Franchi @ 2018-01-09 11:46 UTC (permalink / raw)
To: linux-arm-kernel
The i.MX 6UL EVK has a MAG3110 Magnetometer sensor in its base board.
Add support for this sensor, which is included in the trivial i2c devices
and according to the bindings documentation, just need a compatible field
and an address.
Signed-off-by: Marco Franchi <marco.franchi@nxp.com>
---
arch/arm/boot/dts/imx6ul-14x14-evk.dts | 11 +++++++++++
1 file changed, 11 insertions(+)
diff --git a/arch/arm/boot/dts/imx6ul-14x14-evk.dts b/arch/arm/boot/dts/imx6ul-14x14-evk.dts
index 18fdb08..cb33baa 100644
--- a/arch/arm/boot/dts/imx6ul-14x14-evk.dts
+++ b/arch/arm/boot/dts/imx6ul-14x14-evk.dts
@@ -140,6 +140,17 @@
};
};
+&i2c1 {
+ clock-frequency = <100000>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_i2c1>;
+ status = "okay";
+
+ mag3110 at e {
+ compatible = "fsl,mag3110";
+ reg = <0x0e>;
+ };
+};
&lcdif {
assigned-clocks = <&clks IMX6UL_CLK_LCDIF_PRE_SEL>;
--
2.7.4
^ permalink raw reply related
* [PATCH 2/3] ARM: imx: Update imx_v6_v7_defconfig for mag3110 support
From: Marco Franchi @ 2018-01-09 11:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1515498385-23198-1-git-send-email-marco.franchi@nxp.com>
The i.MX 6UL EVK has support for the MAG3110 Magnetometer sensor, included
in its base board by default.
So add support for this Magnetometer in the imx_v6_v7_defconfig.
Signed-off-by: Marco Franchi <marco.franchi@nxp.com>
---
arch/arm/configs/imx_v6_v7_defconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/configs/imx_v6_v7_defconfig b/arch/arm/configs/imx_v6_v7_defconfig
index 4cb9829..ebff980 100644
--- a/arch/arm/configs/imx_v6_v7_defconfig
+++ b/arch/arm/configs/imx_v6_v7_defconfig
@@ -369,6 +369,7 @@ CONFIG_COMMON_CLK_PWM=y
CONFIG_IIO=y
CONFIG_IMX7D_ADC=y
CONFIG_VF610_ADC=y
+CONFIG_MAG3110=y
CONFIG_MPL3115=y
CONFIG_PWM=y
CONFIG_PWM_FSL_FTM=y
--
2.7.4
^ permalink raw reply related
* [PATCH 3/3] ARM: dts: imx7d-sdb: Add support for mpl3115 sensor
From: Marco Franchi @ 2018-01-09 11:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1515498385-23198-1-git-send-email-marco.franchi@nxp.com>
The i.MX 7D SDB has a MPL3115 Pressure sensor.
Add support for this sensor, which is included in the trivial i2c devices
and according to the bindings documentation, just need a compatible field
and an address.
Signed-off-by: Marco Franchi <marco.franchi@nxp.com>
---
arch/arm/boot/dts/imx7d-sdb.dts | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/arch/arm/boot/dts/imx7d-sdb.dts b/arch/arm/boot/dts/imx7d-sdb.dts
index a7a5dc7..a20c942 100644
--- a/arch/arm/boot/dts/imx7d-sdb.dts
+++ b/arch/arm/boot/dts/imx7d-sdb.dts
@@ -336,6 +336,11 @@
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_i2c2>;
status = "okay";
+
+ mpl3115 at 60 {
+ compatible = "fsl,mpl3115";
+ reg = <0x60>;
+ };
};
&i2c3 {
--
2.7.4
^ permalink raw reply related
* [PATCH 2/9] soc: samsung: pmu: Add powerup_conf callback
From: Krzysztof Kozlowski @ 2018-01-09 11:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1515484746-10656-3-git-send-email-cw00.choi@samsung.com>
On Tue, Jan 9, 2018 at 8:58 AM, Chanwoo Choi <cw00.choi@samsung.com> wrote:
> This patch adds the powerup_conf callback which is used to re-initialize
Do not describe every patch as this patch. It does not bring any
information because I am already looking at this patch.
http://elixir.free-electrons.com/linux/latest/source/Documentation/process/submitting-patches.rst#L151
> the PMU registers during the resume state.
>
> Signed-off-by: Chanwoo Choi <cw00.choi@samsung.com>
> ---
> drivers/soc/samsung/exynos-pmu.c | 8 ++++++++
> drivers/soc/samsung/exynos-pmu.h | 1 +
> include/linux/soc/samsung/exynos-pmu.h | 1 +
> 3 files changed, 10 insertions(+)
>
> diff --git a/drivers/soc/samsung/exynos-pmu.c b/drivers/soc/samsung/exynos-pmu.c
> index f56adbd9fb8b..cfc9de518344 100644
> --- a/drivers/soc/samsung/exynos-pmu.c
> +++ b/drivers/soc/samsung/exynos-pmu.c
> @@ -58,6 +58,14 @@ void exynos_sys_powerdown_conf(enum sys_powerdown mode)
> pmu_data->powerdown_conf_extra(mode);
> }
>
> +void exynos_sys_powerup_conf(enum sys_powerdown mode)
> +{
> + const struct exynos_pmu_data *pmu_data = pmu_context->pmu_data;
> +
Follow the existing pattern of exynos_sys_powerdown_conf() to check if
pmu_context was initialized. At this commit, for Exynos5433 it is not
being set.
Best regards,
Krzysztof
> + if (pmu_data->powerup_conf)
> + pmu_data->powerup_conf(mode);
> +}
> +
> /*
> * Split the data between ARM architectures because it is relatively big
> * and useless on other arch.
> diff --git a/drivers/soc/samsung/exynos-pmu.h b/drivers/soc/samsung/exynos-pmu.h
> index 977e4daf5a0f..efbaf8929252 100644
> --- a/drivers/soc/samsung/exynos-pmu.h
> +++ b/drivers/soc/samsung/exynos-pmu.h
> @@ -24,6 +24,7 @@ struct exynos_pmu_data {
> void (*pmu_init)(void);
> void (*powerdown_conf)(enum sys_powerdown);
> void (*powerdown_conf_extra)(enum sys_powerdown);
> + void (*powerup_conf)(enum sys_powerdown);
> };
>
> extern void __iomem *pmu_base_addr;
> diff --git a/include/linux/soc/samsung/exynos-pmu.h b/include/linux/soc/samsung/exynos-pmu.h
> index e57eb4b6cc5a..3aacf7b18401 100644
> --- a/include/linux/soc/samsung/exynos-pmu.h
> +++ b/include/linux/soc/samsung/exynos-pmu.h
> @@ -22,6 +22,7 @@ enum sys_powerdown {
> };
>
> extern void exynos_sys_powerdown_conf(enum sys_powerdown mode);
> +extern void exynos_sys_powerup_conf(enum sys_powerdown mode);
> #ifdef CONFIG_EXYNOS_PMU
> extern struct regmap *exynos_get_pmu_regmap(void);
> #else
> --
> 1.9.1
>
^ permalink raw reply
* [PATCH, v2] arm: omap2: timer: fix a kmemleak caused in omap_get_timer_dt
From: Ladislav Michl @ 2018-01-09 11:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1515489861-1474-1-git-send-email-qi.hou@windriver.com>
On Tue, Jan 09, 2018 at 05:24:21PM +0800, Qi Hou wrote:
> When more than one GP timers are used as kernel system timers and the
> corresponding nodes in device-tree are marked with the same "disabled"
> property, then the "attr" field of the property will be initialized
> more than once as the property being added to sys file system via
> __of_add_property_sysfs().
>
> In __of_add_property_sysfs(), the "name" field of pp->attr.attr is set
> directly to the return value of safe_name(), without taking care of
> whether it's already a valid pointer to a memory block. If it is, its
> old value will always be overwritten by the new one and the memory block
> allocated before will a "ghost", then a kmemleak happened.
As timers does not seem to be deallocated, this does not matter in practice.
Fix eats a bit more from heap.
> That the same "disabled" property being added to different nodes of device
> tree would cause that kind of kmemleak overhead, at leat once.
>
> To fix it, allocate the property dynamically, and delete static one.
>
> Signed-off-by: Qi Hou <qi.hou@windriver.com>
> ---
> arch/arm/mach-omap2/timer.c | 19 +++++++++++--------
> 1 file changed, 11 insertions(+), 8 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/timer.c b/arch/arm/mach-omap2/timer.c
> index ece09c9..206ae8d 100644
> --- a/arch/arm/mach-omap2/timer.c
> +++ b/arch/arm/mach-omap2/timer.c
> @@ -156,12 +156,6 @@ static struct clock_event_device clockevent_gpt = {
> .tick_resume = omap2_gp_timer_shutdown,
> };
>
> -static struct property device_disabled = {
> - .name = "status",
> - .length = sizeof("disabled"),
> - .value = "disabled",
> -};
> -
> static const struct of_device_id omap_timer_match[] __initconst = {
> { .compatible = "ti,omap2420-timer", },
> { .compatible = "ti,omap3430-timer", },
> @@ -203,8 +197,17 @@ static struct device_node * __init omap_get_timer_dt(const struct of_device_id *
> of_get_property(np, "ti,timer-secure", NULL)))
> continue;
>
> - if (!of_device_is_compatible(np, "ti,omap-counter32k"))
> - of_add_property(np, &device_disabled);
> + if (!of_device_is_compatible(np, "ti,omap-counter32k")) {
> + struct property *prop;
> +
> + prop = kzalloc(sizeof(*prop), GFP_KERNEL);
> + if (!prop)
> + return NULL;
> + prop->name = "status";
> + prop->length = sizeof("disabled");
> + prop->value = "disabled";
How about (see drivers/of/unittest.c)?
prop->value = "disabled";
prop->length = strlen(prop->value);
> + of_add_property(np, prop);
> + }
> return np;
> }
>
> --
> 2.7.4
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [Letux-kernel] [PATCH v5 3/5] misc serdev: Add w2sg0004 (gps receiver) power control driver
From: H. Nikolaus Schaller @ 2018-01-09 11:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <91850CC3-B280-4701-9D07-96AFF3A79A6F@goldelico.com>
Hi Johan,
> Am 22.12.2017 um 15:40 schrieb H. Nikolaus Schaller <hns@goldelico.com>:
>
> Hi Johan,
>
>> Am 22.12.2017 um 13:44 schrieb Johan Hovold <johan@kernel.org>:
>>
>> On Fri, Dec 01, 2017 at 08:49:36AM +0100, H. Nikolaus Schaller wrote:
>>> Add driver for Wi2Wi W2SG0004/84 GPS module connected to some SoC UART.
>>>
>>> It uses serdev API hooks to monitor and forward the UART traffic to /dev/ttyGPSn
>>> and turn on/off the module. It also detects if the module is turned on (sends data)
>>> but should be off, e.g. if it was already turned on during boot or power-on-reset.
>>>
>>> Additionally, rfkill block/unblock can be used to control an external LNA
>>> (and power down the module if not needed).
>>>
>>> The driver concept is based on code developed by Neil Brown <neilb@suse.de>
>>> but simplified and adapted to use the new serdev API introduced in v4.11.
>>
>> I'm sorry (and I know this discussion has been going on for a long
>> time),but this still feels like too much of a hack.
Happy new year ... Happy new attempt...
Let's restart this discussion and focus on the main roadblock (others are minor
details which can be sorted out later).
If it feels like a hack, the key issue seems to me to be the choice of
the API to present the GPS data to user space. Right?
I see three reasonable options how this presentation can be done:
1. char device
2. tty device
3. some new gps interface API (similar to network, bluetooth interfaces)
4. no driver and use the UART tty directly
Pros and cons:
1. char device
+ seems to save resources (but IMHO doesn't if we look deeper to handle select, blocking, buffer overflow)
- the standard function of buffering a character stream has to be done by this driver again, although tty subsystem already has proper buffering
- no line disciplines (e.g. if some gps client wants to translate CR and NL or use canonical/noncanonical mode)
- capabilities of the interface change if same chip is connected through USB or Bluetooth serial interface
2. tty device
+ full tty port like USB, Bluetooth or UART connection (w/o driver)
+ handles tcsetattr like USB, Bluetooth or UART
+ buffering and line disciplines come for free (at least wrt. driver code)
+ tested
- seems to appear to be complex and overkill and a hack (but IMHO is neither)
3. some new gps interface API
+ could become very elegant and general
- does not exist (AFAIK not even a plan but I am not aware of everything)
- no user-space daemons and applications exist which use it
4. no driver and use UART directly
+ a non-solution seems to be attractive
- must turn on/off chip by gpio hacks from user-space
- can not guarantee (!) to power off the chip if the last user-space process using it is killed
(which is essential for power-management of a handheld, battery operated device)
I would clearly prefer 3 over 2 over 1 over 4.
So do you see a chance that the kernel core team provides something useable
(not perfect) for variant 3 in reasonable time (let's say 3-6 months)?
If not, I want to suggest to accept the second-best choice 2. for now and we
will update the driver as soon as 3. appears. IMHO it would be a good test case
for a new subsystem.
Please advise how you want to proceed.
BR and thanks,
Nikolaus
^ permalink raw reply
* [PATCH v3] dt: psci: Update DT bindings to support hierarchical PSCI states
From: Ulf Hansson @ 2018-01-09 11:55 UTC (permalink / raw)
To: linux-arm-kernel
From: Lina Iyer <lina.iyer@linaro.org>
Update DT bindings to represent hierarchical CPU and CPU domain idle states
for PSCI. Also update the PSCI examples to clearly show how flattened and
hierarchical idle states can be represented in DT.
Signed-off-by: Lina Iyer <lina.iyer@linaro.org>
Reviewed-by: Rob Herring <robh@kernel.org>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
---
Changes in v3:
- Added Rob's reviewed-by-tag.
- Addressed comments from Sudeep.
Changes in v2:
- Addressed comments from Rob.
- Updated some labels in the examples to get more consistency.
For your information, I have picked up the work from Lina Iyer around the so
called CPU cluster idling series [1,2] and I working on new versions. However,
I decided to post the updates to the PSCI DT bindings first, as they will be
needed to be agreed upon before further changes can be done to the PSCI
firmware driver.
Note, these bindings have been discussed over and over again, at LKML, but
especially also at various Linux conferences, like LPC and Linaro Connect. We
finally came to a conclusion and the changes we agreed upon, should be
reflected in this update.
Of course, it's a while ago since the latest discussions, but hopefully people
don't have too hard time to remember.
Kind regards
Uffe
[1]
https://www.spinics.net/lists/arm-kernel/msg566200.html
[2]
https://lwn.net/Articles/716300/
---
Documentation/devicetree/bindings/arm/psci.txt | 156 +++++++++++++++++++++++++
1 file changed, 156 insertions(+)
diff --git a/Documentation/devicetree/bindings/arm/psci.txt b/Documentation/devicetree/bindings/arm/psci.txt
index a2c4f1d..17aa3d3 100644
--- a/Documentation/devicetree/bindings/arm/psci.txt
+++ b/Documentation/devicetree/bindings/arm/psci.txt
@@ -105,7 +105,163 @@ Case 3: PSCI v0.2 and PSCI v0.1.
...
};
+ARM systems can have multiple cores sometimes in hierarchical arrangement.
+This often, but not always, maps directly to the processor power topology of
+the system. Individual nodes in a topology have their own specific power states
+and can be better represented in DT hierarchically.
+
+For these cases, the definitions of the idle states for the CPUs and the CPU
+topology, must conform to the domain idle state specification [3]. The domain
+idle states themselves, must be compatible with the defined 'domain-idle-state'
+binding [1], and also need to specify the arm,psci-suspend-param property for
+each idle state.
+
+DT allows representing CPUs and CPU idle states in two different ways -
+
+The flattened model as given in Example 1, lists CPU's idle states followed by
+the domain idle state that the CPUs may choose. Note that the idle states are
+all compatible with "arm,idle-state".
+
+Example 2 represents the hierarchical model of CPUs and domain idle states.
+CPUs define their domain provider in their psci DT node. The domain controls
+the power to the CPU and possibly other h/w blocks that would enter an idle
+state along with the CPU. The CPU's idle states may therefore be considered as
+the domain's idle states and have the compatible "arm,idle-state". Such domains
+may also be embedded within another domain that may represent common h/w blocks
+between these CPUs. The idle states of the CPU topology shall be represented as
+the domain's idle states.
+
+In PSCI firmware v1.0, the OS-Initiated mode is introduced. In order to use it,
+the hierarchical representation must be used.
+
+Example 1: Flattened representation of CPU and domain idle states
+ cpus {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ CPU0: cpu at 0 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a53", "arm,armv8";
+ reg = <0x0>;
+ enable-method = "psci";
+ cpu-idle-states = <&CPU_PWRDN>, <&CLUSTER_RET>,
+ <&CLUSTER_PWRDN>;
+ };
+
+ CPU1: cpu at 1 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a57", "arm,armv8";
+ reg = <0x100>;
+ enable-method = "psci";
+ cpu-idle-states = <&CPU_PWRDN>, <&CLUSTER_RET>,
+ <&CLUSTER_PWRDN>;
+ };
+
+ idle-states {
+ CPU_PWRDN: cpu-power-down {
+ compatible = "arm,idle-state";
+ arm,psci-suspend-param = <0x000001>;
+ entry-latency-us = <10>;
+ exit-latency-us = <10>;
+ min-residency-us = <100>;
+ };
+
+ CLUSTER_RET: cluster-retention {
+ compatible = "arm,idle-state";
+ arm,psci-suspend-param = <0x1000010>;
+ entry-latency-us = <500>;
+ exit-latency-us = <500>;
+ min-residency-us = <2000>;
+ };
+
+ CLUSTER_PWRDN: cluster-power-down {
+ compatible = "arm,idle-state";
+ arm,psci-suspend-param = <0x1000030>;
+ entry-latency-us = <2000>;
+ exit-latency-us = <2000>;
+ min-residency-us = <6000>;
+ };
+ };
+
+ psci {
+ compatible = "arm,psci-0.2";
+ method = "smc";
+ };
+
+Example 2: Hierarchical representation of CPU and domain idle states
+
+ cpus {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ CPU0: cpu at 0 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a53", "arm,armv8";
+ reg = <0x0>;
+ enable-method = "psci";
+ power-domains = <&CPU_PD0>;
+ };
+
+ CPU1: cpu at 1 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a57", "arm,armv8";
+ reg = <0x100>;
+ enable-method = "psci";
+ power-domains = <&CPU_PD1>;
+ };
+
+ idle-states {
+ CPU_PWRDN: cpu-power-down {
+ compatible = "arm,idle-state";
+ arm,psci-suspend-param = <0x000001>;
+ entry-latency-us = <10>;
+ exit-latency-us = <10>;
+ min-residency-us = <100>;
+ };
+
+ CLUSTER_RET: cluster-retention {
+ compatible = "domain-idle-state";
+ arm,psci-suspend-param = <0x1000010>;
+ entry-latency-us = <500>;
+ exit-latency-us = <500>;
+ min-residency-us = <2000>;
+ };
+
+ CLUSTER_PWRDN: cluster-power-down {
+ compatible = "domain-idle-state";
+ arm,psci-suspend-param = <0x1000030>;
+ entry-latency-us = <2000>;
+ exit-latency-us = <2000>;
+ min-residency-us = <6000>;
+ };
+ };
+ };
+
+ psci {
+ compatible = "arm,psci-1.0";
+ method = "smc";
+
+ CPU_PD0: cpu-pd0 {
+ #power-domain-cells = <0>;
+ domain-idle-states = <&CPU_PWRDN>;
+ power-domains = <&CLUSTER_PD>;
+ };
+
+ CPU_PD1: cpu-pd1 {
+ #power-domain-cells = <0>;
+ domain-idle-states = <&CPU_PWRDN>;
+ power-domains = <&CLUSTER_PD>;
+ };
+
+ CLUSTER_PD: cluster-pd {
+ #power-domain-cells = <0>;
+ domain-idle-states = <&CLUSTER_RET>, <&CLUSTER_PWRDN>;
+ };
+ };
+
[1] Kernel documentation - ARM idle states bindings
Documentation/devicetree/bindings/arm/idle-states.txt
[2] Power State Coordination Interface (PSCI) specification
http://infocenter.arm.com/help/topic/com.arm.doc.den0022c/DEN0022C_Power_State_Coordination_Interface.pdf
+[3]. PM Domains description
+ Documentation/devicetree/bindings/power/power_domain.txt
--
2.7.4
^ permalink raw reply related
* [RFC PATCH 0/9] soc: samsung: Add support of suspend-to-RAM on Exynos5433
From: Krzysztof Kozlowski @ 2018-01-09 11:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1515484746-10656-1-git-send-email-cw00.choi@samsung.com>
On Tue, Jan 9, 2018 at 8:58 AM, Chanwoo Choi <cw00.choi@samsung.com> wrote:
> In the mainline, there is no case to support the suspend-to-RAM for Samsung
> Exynos SoC. This patchset support the suspend-to-RAM for 64bit Exynos SoC.
>
> For 32bit, arch/arm/mach-exynos/* directoy contains the suspend-related
> codes such as suspend.c/exynos.c. But, 64bit Exynos should contain
> the suspend-related codes in the drivers/soc/samsung/*. So, this patchset
> develop the patch4/5 for drivers/soc/samsung/exynos-pm.c. to support suspend
> 64bit Exynos SoC.
>
> But, I'm not sure what is proper approach for both 32/64bit Exynos.
> - Approach1 : Split out the supend-related codes between 32/64bit.
> : arch/arm/mach-exynos/* contains the suspend-related codes for 32bit.
> : drivers/soc/samsung/* contains the suspend-related codes for 64bit.
> - Approach2 : Consolidate the all suspend-related codes to drivers/soc/samsung/.
I prefer approach #2 - consolidate the code... unless this creates
some unmaintainable monster :)
Best regards,
Krzysztof
>
> Please let us know your opinion.
>
> The patch1/2/3 and 6/7/8/9 is just general patch. So, I add 'RFC' prefix to
> only cover-letter, patch4/5. If you want to add the 'RFC' prefix to all
> patches, I'll add 'RFC' prefix on v2.
>
> Based on:
> - git://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux.git (branch: for-next)
>
> Need to discuss patch4/5:
> - patch4: soc: samsung: Add generic power-management driver for Exynos
> - patch5: soc: samsung: pm: Add support for suspend-to-ram of Exynos5433
>
> [Remaining Issues]
> - The hang-out happen when disabling the MMC clocks on dw_mmc.c.
> I reported to Jaehoon Chung. He is checking this issue. To test the
> suspend-to-ram temporarily, you need to add CLK_IS_CRITICAL flag to
> 'aclk_mmc2/aclk_mmc0/sclk_mmc2/sclk_mmc0'.
> - I enabled the at least kernel configuration in order to test
> the suspend-to-RAM. So, I need to test it more time with DRM/Multimedia
> and other. But, the suspend-to-RAM of cpu is successful.
> - Exynos5433 SoC has two EXYNOS5433_EINT_WAKEUP_MASKx registers. The
> pinctr-exynos.c need to handle the extra EINT_WAKEUP_MASKx for Exynos5433.
> The suspend-to-ram test is failed on first time and then next tryout is ok.
> I'm developing it.
>
> Chanwoo Choi (9):
> clk: samsung: exynos5433: Add clock flag to support suspend-to-ram
> soc: samsung: pmu: Add powerup_conf callback
> soc: samsung: pmu: Add the PMU data of exynos5433 to support low-power state
> soc: samsung: Add generic power-management driver for Exynos
> soc: samsung: pm: Add support for suspend-to-ram of Exynos5433
> arm64: dts: exynos: Add iRAM device-tree node for Exynos5433
> arm64: dts: exynos: Use power key as a wakeup source on TM2/TM2E board
> arm64: dts: exynos: Add cpu_suspend property of PSCI for exynos5433
> arm64: dts: exynos: Add cpu topology information for Exynos5433 SoC
>
> arch/arm/mach-exynos/common.h | 3 -
> arch/arm/mach-exynos/exynos.c | 23 +-
> .../boot/dts/exynos/exynos5433-tm2-common.dtsi | 1 +
> arch/arm64/boot/dts/exynos/exynos5433.dtsi | 47 ++++
> drivers/clk/samsung/clk-exynos5433.c | 22 +-
> drivers/soc/samsung/Makefile | 5 +-
> drivers/soc/samsung/exynos-pm.c | 214 +++++++++++++++
> drivers/soc/samsung/exynos-pmu.c | 9 +
> drivers/soc/samsung/exynos-pmu.h | 3 +
> drivers/soc/samsung/exynos5433-pmu.c | 286 +++++++++++++++++++++
> include/linux/soc/samsung/exynos-pm.h | 21 ++
> include/linux/soc/samsung/exynos-pmu.h | 1 +
> include/linux/soc/samsung/exynos-regs-pmu.h | 148 +++++++++++
> 13 files changed, 745 insertions(+), 38 deletions(-)
> create mode 100644 drivers/soc/samsung/exynos-pm.c
> create mode 100644 drivers/soc/samsung/exynos5433-pmu.c
> create mode 100644 include/linux/soc/samsung/exynos-pm.h
>
> --
> 1.9.1
>
^ 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