[RFC 6/6] drm/exynos: mixer: add more pixel formats
The mixer natively support RGB565, ARGB and ARGB1555
so expose these formats. Also, since being of 16-bit size,
these formats have a lower bandwidth requirement, making
them useful in situations where this is a bottleneck.
Signed-off-by: Tobias Jakobi tjak...@math.uni-bielefeld.de
---
drivers/gpu/drm/exynos/exynos_mixer.c | 21 ++---
1 file changed, 14 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_mixer.c
b/drivers/gpu/drm/exynos/exynos_mixer.c
index 512f7b3..7dec7c7 100644
--- a/drivers/gpu/drm/exynos/exynos_mixer.c
+++ b/drivers/gpu/drm/exynos/exynos_mixer.c
@@ -127,6 +127,11 @@ static const u8 filter_cr_horiz_tap4[] = {
static const uint32_t mixer_formats[] = {
DRM_FORMAT_XRGB,
DRM_FORMAT_ARGB,
+ DRM_FORMAT_RGB565,
+ DRM_FORMAT_XRGB1555,
+ DRM_FORMAT_ARGB1555,
+ DRM_FORMAT_XRGB,
+ DRM_FORMAT_ARGB,
};
static const uint32_t vp_formats[] = {
@@ -556,30 +561,32 @@ static void mixer_graph_buffer(struct mixer_context *ctx,
int win)
unsigned int x_ratio = 0, y_ratio = 0;
unsigned int src_x_offset, src_y_offset, dst_x_offset, dst_y_offset;
dma_addr_t dma_addr;
- unsigned int fmt, blend;
+ unsigned int fmt, blend = 0;
u32 val;
plane = ctx-planes[win];
switch (plane-pixel_format) {
case DRM_FORMAT_ARGB:
- fmt = MIXER_PIXELFORMAT_ARGB;
blend = 1;
+ case DRM_FORMAT_XRGB:
+ fmt = MIXER_PIXELFORMAT_ARGB;
break;
case DRM_FORMAT_ARGB:
- fmt = MIXER_PIXELFORMAT_ARGB;
blend = 1;
- break;
-
case DRM_FORMAT_XRGB:
fmt = MIXER_PIXELFORMAT_ARGB;
- blend = 0;
+ break;
+
+ case DRM_FORMAT_ARGB1555:
+ blend = 1;
+ case DRM_FORMAT_XRGB1555:
+ fmt = MIXER_PIXELFORMAT_ARGB1555;
break;
case DRM_FORMAT_RGB565:
fmt = MIXER_PIXELFORMAT_RGB565;
- blend = 0;
break;
default:
--
2.0.5
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC 5/6] drm/exynos: mixer: use more general check for VP format
The mixer itself can't handle 'video' formats like NV12 or
NV21. It needs the VP (video processor) for this task.
With the previous patch we ensure that DRM planes with
a NV12 format can only be created when this setup is
supported. Hence the check now reduces to checking the
pixel format (currently only NV12).
Signed-off-by: Tobias Jakobi tjak...@math.uni-bielefeld.de
---
drivers/gpu/drm/exynos/exynos_mixer.c | 12 +++-
1 file changed, 11 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/exynos/exynos_mixer.c
b/drivers/gpu/drm/exynos/exynos_mixer.c
index 50df981..512f7b3 100644
--- a/drivers/gpu/drm/exynos/exynos_mixer.c
+++ b/drivers/gpu/drm/exynos/exynos_mixer.c
@@ -133,6 +133,16 @@ static const uint32_t vp_formats[] = {
DRM_FORMAT_NV12,
};
+static inline bool is_vp_format(const struct mixer_context *ctx, unsigned int
win)
+{
+ switch (ctx-planes[win].pixel_format) {
+ case DRM_FORMAT_NV12:
+ return true;
+ default:
+ return false;
+ }
+}
+
static inline u32 vp_reg_read(struct mixer_resources *res, u32 reg_id)
{
return readl(res-vp_regs + reg_id);
@@ -970,7 +980,7 @@ static void mixer_win_commit(struct exynos_drm_crtc *crtc,
unsigned int win)
}
mutex_unlock(mixer_ctx-mixer_mutex);
- if (win 1 mixer_ctx-vp_enabled)
+ if (is_vp_format(mixer_ctx, win))
vp_video_buffer(mixer_ctx, win);
else
mixer_graph_buffer(mixer_ctx, win);
--
2.0.5
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC 4/6] drm/exynos: remove global pixel format list
Currently the pixel formats that are supported by a plane
object are hard-coded to three entries.
This is not correct since depending on the particular
hardware block (DECON7, FIMD, VP, etc.) the supported
formats are different.
Let each block specify its own list of formats.
Signed-off-by: Tobias Jakobi tjak...@math.uni-bielefeld.de
---
drivers/gpu/drm/exynos/exynos7_drm_decon.c | 7 +++
drivers/gpu/drm/exynos/exynos_drm_fimd.c | 7 +++
drivers/gpu/drm/exynos/exynos_drm_plane.c | 10 ++
drivers/gpu/drm/exynos/exynos_drm_vidi.c | 7 +++
drivers/gpu/drm/exynos/exynos_mixer.c | 18 ++
5 files changed, 41 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos7_drm_decon.c
b/drivers/gpu/drm/exynos/exynos7_drm_decon.c
index ca70599..73788a1 100644
--- a/drivers/gpu/drm/exynos/exynos7_drm_decon.c
+++ b/drivers/gpu/drm/exynos/exynos7_drm_decon.c
@@ -42,6 +42,11 @@
#define WINDOWS_NR 2
+static const uint32_t decon_formats[] = {
+ DRM_FORMAT_XRGB,
+ DRM_FORMAT_ARGB,
+};
+
struct decon_context {
struct device *dev;
struct drm_device *drm_dev;
@@ -767,6 +772,8 @@ static int decon_bind(struct device *dev, struct device
*master, void *data)
}
plane_config.possible_crtcs = 1 ctx-pipe;
+ plane_config.pixel_formats = decon_formats;
+ plane_config.num_pixel_formats = ARRAY_SIZE(decon_formats);
for (i = 0; i WINDOWS_NR; i++) {
plane_config.type = (i == ctx-default_win) ?
diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
index 93fbaa5..1db8db7 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
@@ -144,6 +144,11 @@ static struct fimd_driver_data exynos5_fimd_driver_data = {
.has_vtsel = 1,
};
+static const uint32_t fimd_formats[] = {
+ DRM_FORMAT_XRGB,
+ DRM_FORMAT_ARGB,
+};
+
struct fimd_context {
struct device *dev;
struct drm_device *drm_dev;
@@ -1005,6 +1010,8 @@ static int fimd_bind(struct device *dev, struct device
*master, void *data)
ctx-pipe = priv-pipe++;
plane_config.possible_crtcs = 1 ctx-pipe;
+ plane_config.pixel_formats = fimd_formats;
+ plane_config.num_pixel_formats = ARRAY_SIZE(fimd_formats);
for (i = 0; i WINDOWS_NR; i++) {
plane_config.type = (i == ctx-default_win) ?
diff --git a/drivers/gpu/drm/exynos/exynos_drm_plane.c
b/drivers/gpu/drm/exynos/exynos_drm_plane.c
index d24b32a..563d471 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_plane.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_plane.c
@@ -19,12 +19,6 @@
#include exynos_drm_gem.h
#include exynos_drm_plane.h
-static const uint32_t formats[] = {
- DRM_FORMAT_XRGB,
- DRM_FORMAT_ARGB,
- DRM_FORMAT_NV12,
-};
-
/*
* This function is to get X or Y size shown via screen. This needs length and
* start position of CRTC.
@@ -212,8 +206,8 @@ int exynos_plane_init(struct drm_device *dev,
err = drm_universal_plane_init(dev, exynos_plane-base,
config-possible_crtcs,
- exynos_plane_funcs, formats,
- ARRAY_SIZE(formats), config-type);
+ exynos_plane_funcs,
config-pixel_formats,
+ config-num_pixel_formats, config-type);
if (err) {
DRM_ERROR(failed to initialize plane\n);
return err;
diff --git a/drivers/gpu/drm/exynos/exynos_drm_vidi.c
b/drivers/gpu/drm/exynos/exynos_drm_vidi.c
index ca7cc8a..94d2e84 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_vidi.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_vidi.c
@@ -33,6 +33,11 @@
#define ctx_from_connector(c) container_of(c, struct vidi_context, \
connector)
+static const uint32_t vidi_formats[] = {
+ DRM_FORMAT_XRGB,
+ DRM_FORMAT_ARGB,
+};
+
struct vidi_context {
struct exynos_drm_display display;
struct platform_device *pdev;
@@ -470,6 +475,8 @@ static int vidi_bind(struct device *dev, struct device
*master, void *data)
vidi_ctx_initialize(ctx, drm_dev);
plane_config.possible_crtcs = 1 ctx-pipe;
+ plane_config.pixel_formats = vidi_formats;
+ plane_config.num_pixel_formats = ARRAY_SIZE(vidi_formats);
for (i = 0; i WINDOWS_NR; i++) {
plane_config.type = (i == ctx-default_win) ?
diff --git a/drivers/gpu/drm/exynos/exynos_mixer.c
b/drivers/gpu/drm/exynos/exynos_mixer.c
index 207d5c9..50df981 100644
--- a/drivers/gpu/drm/exynos/exynos_mixer.c
+++ b/drivers/gpu/drm/exynos/exynos_mixer.c
@@ -43,6 +43,7 @@
#define MIXER_WIN_NR 3
#define MIXER_DEFAULT_WIN
[RFC 3/6] drm/exynos: introduce struct exynos_drm_plane_config
This struct encapsulates the configuration for a plane
object. The pixel format config is currently unused.
Signed-off-by: Tobias Jakobi tjak...@math.uni-bielefeld.de
---
drivers/gpu/drm/exynos/exynos7_drm_decon.c | 17 ++---
drivers/gpu/drm/exynos/exynos_drm_drv.h| 19 +++
drivers/gpu/drm/exynos/exynos_drm_fimd.c | 17 ++---
drivers/gpu/drm/exynos/exynos_drm_plane.c | 14 +++---
drivers/gpu/drm/exynos/exynos_drm_plane.h | 3 +--
drivers/gpu/drm/exynos/exynos_drm_vidi.c | 17 ++---
drivers/gpu/drm/exynos/exynos_mixer.c | 17 ++---
7 files changed, 67 insertions(+), 37 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos7_drm_decon.c
b/drivers/gpu/drm/exynos/exynos7_drm_decon.c
index 84a3638..ca70599 100644
--- a/drivers/gpu/drm/exynos/exynos7_drm_decon.c
+++ b/drivers/gpu/drm/exynos/exynos7_drm_decon.c
@@ -756,8 +756,8 @@ static int decon_bind(struct device *dev, struct device
*master, void *data)
struct decon_context *ctx = dev_get_drvdata(dev);
struct drm_device *drm_dev = data;
struct exynos_drm_plane *exynos_plane;
- enum drm_plane_type type;
- unsigned int zpos;
+ struct exynos_drm_plane_config plane_config = { 0 };
+ unsigned int i;
int ret;
ret = decon_ctx_initialize(ctx, drm_dev);
@@ -766,11 +766,14 @@ static int decon_bind(struct device *dev, struct device
*master, void *data)
return ret;
}
- for (zpos = 0; zpos WINDOWS_NR; zpos++) {
- type = (zpos == ctx-default_win) ? DRM_PLANE_TYPE_PRIMARY :
- DRM_PLANE_TYPE_OVERLAY;
- ret = exynos_plane_init(drm_dev, ctx-planes[zpos],
- 1 ctx-pipe, type, zpos);
+ plane_config.possible_crtcs = 1 ctx-pipe;
+
+ for (i = 0; i WINDOWS_NR; i++) {
+ plane_config.type = (i == ctx-default_win) ?
+ DRM_PLANE_TYPE_PRIMARY : DRM_PLANE_TYPE_OVERLAY;
+ plane_config.zpos = i;
+
+ ret = exynos_plane_init(drm_dev, ctx-planes[i],
plane_config);
if (ret)
return ret;
}
diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.h
b/drivers/gpu/drm/exynos/exynos_drm_drv.h
index 4c14a89..35698f3 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_drv.h
+++ b/drivers/gpu/drm/exynos/exynos_drm_drv.h
@@ -116,6 +116,25 @@ struct exynos_drm_plane {
};
/*
+ * Exynos DRM plane configuration structure.
+ *
+ * @possible_crtcs: bitfield describing the valid CRTCs
+ * for this plane.
+ * @type: plane type (primary, overlay, etc.)
+ * @zpos: z-position of the plane.
+ * @pixel_formats: supported pixel formats.
+ * @num_pixel_formats: number of elements in 'pixel_formats'.
+ */
+
+struct exynos_drm_plane_config {
+ unsigned long possible_crtcs;
+ enum drm_plane_type type;
+ unsigned int zpos;
+ const uint32_t *pixel_formats;
+ unsigned int num_pixel_formats;
+};
+
+/*
* Exynos DRM Display Structure.
* - this structure is common to analog tv, digital tv and lcd panel.
*
diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
index 589579f..93fbaa5 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
@@ -997,18 +997,21 @@ static int fimd_bind(struct device *dev, struct device
*master, void *data)
struct drm_device *drm_dev = data;
struct exynos_drm_private *priv = drm_dev-dev_private;
struct exynos_drm_plane *exynos_plane;
- enum drm_plane_type type;
- unsigned int zpos;
+ struct exynos_drm_plane_config plane_config = { 0 };
+ unsigned int i;
int ret;
ctx-drm_dev = drm_dev;
ctx-pipe = priv-pipe++;
- for (zpos = 0; zpos WINDOWS_NR; zpos++) {
- type = (zpos == ctx-default_win) ? DRM_PLANE_TYPE_PRIMARY :
- DRM_PLANE_TYPE_OVERLAY;
- ret = exynos_plane_init(drm_dev, ctx-planes[zpos],
- 1 ctx-pipe, type, zpos);
+ plane_config.possible_crtcs = 1 ctx-pipe;
+
+ for (i = 0; i WINDOWS_NR; i++) {
+ plane_config.type = (i == ctx-default_win) ?
+ DRM_PLANE_TYPE_PRIMARY : DRM_PLANE_TYPE_OVERLAY;
+ plane_config.zpos = i;
+
+ ret = exynos_plane_init(drm_dev, ctx-planes[i],
plane_config);
if (ret)
return ret;
}
diff --git a/drivers/gpu/drm/exynos/exynos_drm_plane.c
b/drivers/gpu/drm/exynos/exynos_drm_plane.c
index 043a6ba..d24b32a 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_plane.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_plane.c
@@ -206,23 +206,23 @@ static void exynos_plane_attach_zpos_property(struct
drm_plane *plane,
[RFC 1/6] drm/exynos: mixer: move pixelformat defines
Move the defines for the pixelformats that the mixer supports out
of mixer_graph_buffer() to the top of the source.
Also add handling of RGB565 and exit if the pixelformat is not
supported.
Signed-off-by: Tobias Jakobi tjak...@math.uni-bielefeld.de
---
drivers/gpu/drm/exynos/exynos_mixer.c | 24 ++--
1 file changed, 14 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_mixer.c
b/drivers/gpu/drm/exynos/exynos_mixer.c
index 3e07f04..9c398d5 100644
--- a/drivers/gpu/drm/exynos/exynos_mixer.c
+++ b/drivers/gpu/drm/exynos/exynos_mixer.c
@@ -44,6 +44,11 @@
#define MIXER_WIN_NR 3
#define MIXER_DEFAULT_WIN 0
+#define MIXER_PIXELFORMAT_RGB565 4
+#define MIXER_PIXELFORMAT_ARGB1555 5
+#define MIXER_PIXELFORMAT_ARGB 6
+#define MIXER_PIXELFORMAT_ARGB 7
+
struct mixer_resources {
int irq;
void __iomem*mixer_regs;
@@ -536,31 +541,30 @@ static void mixer_graph_buffer(struct mixer_context *ctx,
int win)
plane = ctx-planes[win];
- #define RGB565 4
- #define ARGB1555 5
- #define ARGB 6
- #define ARGB 7
-
switch (plane-pixel_format) {
case DRM_FORMAT_ARGB:
- fmt = ARGB;
+ fmt = MIXER_PIXELFORMAT_ARGB;
blend = 1;
break;
case DRM_FORMAT_ARGB:
- fmt = ARGB;
+ fmt = MIXER_PIXELFORMAT_ARGB;
blend = 1;
break;
case DRM_FORMAT_XRGB:
- fmt = ARGB;
+ fmt = MIXER_PIXELFORMAT_ARGB;
blend = 0;
break;
- default:
- fmt = ARGB;
+ case DRM_FORMAT_RGB565:
+ fmt = MIXER_PIXELFORMAT_RGB565;
blend = 0;
break;
+
+ default:
+ DRM_DEBUG_KMS(pixelformat unsupported by mixer\n);
+ return;
}
/* check if mixer supports requested scaling setup */
--
2.0.5
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC] drm/exynos: improve pixel format handling
Hello, this is an attempt to somewhat improve the handling for supported pixel formats in the Exynos DRM. Currently DRM planes are always created with XRGB, ARGB and NV12 as supported formats, even though the formats depend on the 'consumer' (mixer, FIMD, video processor, etc.). This series is based on the remaining patches of this series: http://www.spinics.net/lists/linux-samsung-soc/msg43103.html With best wishes, Tobias -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC 2/6] drm/exynos: remove used 'activated' field from exynos_drm_plane
Signed-off-by: Tobias Jakobi tjak...@math.uni-bielefeld.de
---
drivers/gpu/drm/exynos/exynos_drm_drv.h | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.h
b/drivers/gpu/drm/exynos/exynos_drm_drv.h
index 6a849cf..4c14a89 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_drv.h
+++ b/drivers/gpu/drm/exynos/exynos_drm_drv.h
@@ -77,7 +77,6 @@ extern void exynos4412_qos(u8 tm, u8 ac);
* @color_key: color key on or off.
* @local_path: in case of lcd type, local path mode on or off.
* @transparency: transparency on or off.
- * @activated: activated or not.
* @enabled: enabled or not.
* @resume: to resume or not.
*
@@ -112,7 +111,6 @@ struct exynos_drm_plane {
bool color_key:1;
bool local_path:1;
bool transparency:1;
- bool activated:1;
bool enabled:1;
bool resume:1;
};
--
2.0.5
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC 3/6] drm/exynos: introduce struct exynos_drm_plane_config
Hi Tobias,
2015-04-15 Tobias Jakobi tjak...@math.uni-bielefeld.de:
Hello Gustavo!
Gustavo Padovan wrote:
Hi Tobias,
2015-04-15 Tobias Jakobi tjak...@math.uni-bielefeld.de:
This struct encapsulates the configuration for a plane
object. The pixel format config is currently unused.
Signed-off-by: Tobias Jakobi tjak...@math.uni-bielefeld.de
---
drivers/gpu/drm/exynos/exynos7_drm_decon.c | 17 ++---
drivers/gpu/drm/exynos/exynos_drm_drv.h| 19 +++
drivers/gpu/drm/exynos/exynos_drm_fimd.c | 17 ++---
drivers/gpu/drm/exynos/exynos_drm_plane.c | 14 +++---
drivers/gpu/drm/exynos/exynos_drm_plane.h | 3 +--
drivers/gpu/drm/exynos/exynos_drm_vidi.c | 17 ++---
drivers/gpu/drm/exynos/exynos_mixer.c | 17 ++---
7 files changed, 67 insertions(+), 37 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos7_drm_decon.c
b/drivers/gpu/drm/exynos/exynos7_drm_decon.c
index 84a3638..ca70599 100644
--- a/drivers/gpu/drm/exynos/exynos7_drm_decon.c
+++ b/drivers/gpu/drm/exynos/exynos7_drm_decon.c
@@ -756,8 +756,8 @@ static int decon_bind(struct device *dev, struct
device *master, void *data)
struct decon_context *ctx = dev_get_drvdata(dev);
struct drm_device *drm_dev = data;
struct exynos_drm_plane *exynos_plane;
- enum drm_plane_type type;
- unsigned int zpos;
+ struct exynos_drm_plane_config plane_config = { 0 };
+ unsigned int i;
int ret;
ret = decon_ctx_initialize(ctx, drm_dev);
@@ -766,11 +766,14 @@ static int decon_bind(struct device *dev, struct
device *master, void *data)
return ret;
}
- for (zpos = 0; zpos WINDOWS_NR; zpos++) {
- type = (zpos == ctx-default_win) ? DRM_PLANE_TYPE_PRIMARY :
- DRM_PLANE_TYPE_OVERLAY;
- ret = exynos_plane_init(drm_dev, ctx-planes[zpos],
- 1 ctx-pipe, type, zpos);
+ plane_config.possible_crtcs = 1 ctx-pipe;
+
+ for (i = 0; i WINDOWS_NR; i++) {
+ plane_config.type = (i == ctx-default_win) ?
+ DRM_PLANE_TYPE_PRIMARY : DRM_PLANE_TYPE_OVERLAY;
+ plane_config.zpos = i;
+
+ ret = exynos_plane_init(drm_dev, ctx-planes[i],
plane_config);
if (ret)
return ret;
}
diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.h
b/drivers/gpu/drm/exynos/exynos_drm_drv.h
index 4c14a89..35698f3 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_drv.h
+++ b/drivers/gpu/drm/exynos/exynos_drm_drv.h
@@ -116,6 +116,25 @@ struct exynos_drm_plane {
};
/*
+ * Exynos DRM plane configuration structure.
+ *
+ * @possible_crtcs: bitfield describing the valid CRTCs
+ *for this plane.
+ * @type: plane type (primary, overlay, etc.)
+ * @zpos: z-position of the plane.
+ * @pixel_formats: supported pixel formats.
+ * @num_pixel_formats: number of elements in 'pixel_formats'.
+ */
+
+struct exynos_drm_plane_config {
+ unsigned long possible_crtcs;
+ enum drm_plane_type type;
+ unsigned int zpos;
+ const uint32_t *pixel_formats;
+ unsigned int num_pixel_formats;
+};
As a follow up of my atomic series I started cleaning up exynos drm a bit
more
and right now I'm removing most of struct exynos_drm_plane. Most of the
plane
information there is also present in plane-state thus I'm basically
removing
all the duplicated information there.
Sounds like a good plan.
That said, I think we avoid creating exynos_drm_plane_config and stuff
everything directly in struct exynos_drm_plane, it will be quite small and
easier to manipulate.
So that would imply that we then just have:
int exynos_plane_init(struct drm_device *dev, struct exynos_drm_plane
*exynos_plane);
Correct?
Correct, passing exynos_drm_plane simplifies things a lot for us.
Anyway, I'm going to wait then until the cleanups are posted and rebase
this series onto it.
Right, I'll probably have that the next week or the other one, I'm currently
working on some testing scripts to speed up my testing and make sure I'm not
breaking anything.
Gustavo
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC 1/6] drm/exynos: mixer: move pixelformat defines
Hi Tobias, 2015-04-15 Tobias Jakobi tjak...@math.uni-bielefeld.de: Move the defines for the pixelformats that the mixer supports out of mixer_graph_buffer() to the top of the source. Also add handling of RGB565 and exit if the pixelformat is not supported. Signed-off-by: Tobias Jakobi tjak...@math.uni-bielefeld.de --- drivers/gpu/drm/exynos/exynos_mixer.c | 24 ++-- 1 file changed, 14 insertions(+), 10 deletions(-) Reviewed-by: Gustavo Padovan gustavo.pado...@collabora.co.uk Gustavo -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC 2/6] drm/exynos: remove used 'activated' field from exynos_drm_plane
Hi Tobias, 2015-04-15 Tobias Jakobi tjak...@math.uni-bielefeld.de: Signed-off-by: Tobias Jakobi tjak...@math.uni-bielefeld.de I think you mean unused in the commit subject. And would also be good to have some commit message as well. Other than that: Reviewed-by: Gustavo Padovan gustavo.pado...@collabora.co.uk Gustavo -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC 3/6] drm/exynos: introduce struct exynos_drm_plane_config
Hi Tobias,
2015-04-15 Tobias Jakobi tjak...@math.uni-bielefeld.de:
This struct encapsulates the configuration for a plane
object. The pixel format config is currently unused.
Signed-off-by: Tobias Jakobi tjak...@math.uni-bielefeld.de
---
drivers/gpu/drm/exynos/exynos7_drm_decon.c | 17 ++---
drivers/gpu/drm/exynos/exynos_drm_drv.h| 19 +++
drivers/gpu/drm/exynos/exynos_drm_fimd.c | 17 ++---
drivers/gpu/drm/exynos/exynos_drm_plane.c | 14 +++---
drivers/gpu/drm/exynos/exynos_drm_plane.h | 3 +--
drivers/gpu/drm/exynos/exynos_drm_vidi.c | 17 ++---
drivers/gpu/drm/exynos/exynos_mixer.c | 17 ++---
7 files changed, 67 insertions(+), 37 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos7_drm_decon.c
b/drivers/gpu/drm/exynos/exynos7_drm_decon.c
index 84a3638..ca70599 100644
--- a/drivers/gpu/drm/exynos/exynos7_drm_decon.c
+++ b/drivers/gpu/drm/exynos/exynos7_drm_decon.c
@@ -756,8 +756,8 @@ static int decon_bind(struct device *dev, struct device
*master, void *data)
struct decon_context *ctx = dev_get_drvdata(dev);
struct drm_device *drm_dev = data;
struct exynos_drm_plane *exynos_plane;
- enum drm_plane_type type;
- unsigned int zpos;
+ struct exynos_drm_plane_config plane_config = { 0 };
+ unsigned int i;
int ret;
ret = decon_ctx_initialize(ctx, drm_dev);
@@ -766,11 +766,14 @@ static int decon_bind(struct device *dev, struct device
*master, void *data)
return ret;
}
- for (zpos = 0; zpos WINDOWS_NR; zpos++) {
- type = (zpos == ctx-default_win) ? DRM_PLANE_TYPE_PRIMARY :
- DRM_PLANE_TYPE_OVERLAY;
- ret = exynos_plane_init(drm_dev, ctx-planes[zpos],
- 1 ctx-pipe, type, zpos);
+ plane_config.possible_crtcs = 1 ctx-pipe;
+
+ for (i = 0; i WINDOWS_NR; i++) {
+ plane_config.type = (i == ctx-default_win) ?
+ DRM_PLANE_TYPE_PRIMARY : DRM_PLANE_TYPE_OVERLAY;
+ plane_config.zpos = i;
+
+ ret = exynos_plane_init(drm_dev, ctx-planes[i],
plane_config);
if (ret)
return ret;
}
diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.h
b/drivers/gpu/drm/exynos/exynos_drm_drv.h
index 4c14a89..35698f3 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_drv.h
+++ b/drivers/gpu/drm/exynos/exynos_drm_drv.h
@@ -116,6 +116,25 @@ struct exynos_drm_plane {
};
/*
+ * Exynos DRM plane configuration structure.
+ *
+ * @possible_crtcs: bitfield describing the valid CRTCs
+ * for this plane.
+ * @type: plane type (primary, overlay, etc.)
+ * @zpos: z-position of the plane.
+ * @pixel_formats: supported pixel formats.
+ * @num_pixel_formats: number of elements in 'pixel_formats'.
+ */
+
+struct exynos_drm_plane_config {
+ unsigned long possible_crtcs;
+ enum drm_plane_type type;
+ unsigned int zpos;
+ const uint32_t *pixel_formats;
+ unsigned int num_pixel_formats;
+};
As a follow up of my atomic series I started cleaning up exynos drm a bit more
and right now I'm removing most of struct exynos_drm_plane. Most of the plane
information there is also present in plane-state thus I'm basically removing
all the duplicated information there.
That said, I think we avoid creating exynos_drm_plane_config and stuff
everything directly in struct exynos_drm_plane, it will be quite small and
easier to manipulate.
Gustavo
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC 2/6] drm/exynos: remove used 'activated' field from exynos_drm_plane
Gustavo Padovan wrote: Hi Tobias, 2015-04-15 Tobias Jakobi tjak...@math.uni-bielefeld.de: Signed-off-by: Tobias Jakobi tjak...@math.uni-bielefeld.de I think you mean unused in the commit subject. And would also be good to have some commit message as well. Other than that: Right, I'm going to change that and respin the series! With best wishes, Tobias -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC 3/6] drm/exynos: introduce struct exynos_drm_plane_config
Hello Gustavo!
Gustavo Padovan wrote:
Hi Tobias,
2015-04-15 Tobias Jakobi tjak...@math.uni-bielefeld.de:
This struct encapsulates the configuration for a plane
object. The pixel format config is currently unused.
Signed-off-by: Tobias Jakobi tjak...@math.uni-bielefeld.de
---
drivers/gpu/drm/exynos/exynos7_drm_decon.c | 17 ++---
drivers/gpu/drm/exynos/exynos_drm_drv.h| 19 +++
drivers/gpu/drm/exynos/exynos_drm_fimd.c | 17 ++---
drivers/gpu/drm/exynos/exynos_drm_plane.c | 14 +++---
drivers/gpu/drm/exynos/exynos_drm_plane.h | 3 +--
drivers/gpu/drm/exynos/exynos_drm_vidi.c | 17 ++---
drivers/gpu/drm/exynos/exynos_mixer.c | 17 ++---
7 files changed, 67 insertions(+), 37 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos7_drm_decon.c
b/drivers/gpu/drm/exynos/exynos7_drm_decon.c
index 84a3638..ca70599 100644
--- a/drivers/gpu/drm/exynos/exynos7_drm_decon.c
+++ b/drivers/gpu/drm/exynos/exynos7_drm_decon.c
@@ -756,8 +756,8 @@ static int decon_bind(struct device *dev, struct device
*master, void *data)
struct decon_context *ctx = dev_get_drvdata(dev);
struct drm_device *drm_dev = data;
struct exynos_drm_plane *exynos_plane;
-enum drm_plane_type type;
-unsigned int zpos;
+struct exynos_drm_plane_config plane_config = { 0 };
+unsigned int i;
int ret;
ret = decon_ctx_initialize(ctx, drm_dev);
@@ -766,11 +766,14 @@ static int decon_bind(struct device *dev, struct
device *master, void *data)
return ret;
}
-for (zpos = 0; zpos WINDOWS_NR; zpos++) {
-type = (zpos == ctx-default_win) ? DRM_PLANE_TYPE_PRIMARY :
-DRM_PLANE_TYPE_OVERLAY;
-ret = exynos_plane_init(drm_dev, ctx-planes[zpos],
-1 ctx-pipe, type, zpos);
+plane_config.possible_crtcs = 1 ctx-pipe;
+
+for (i = 0; i WINDOWS_NR; i++) {
+plane_config.type = (i == ctx-default_win) ?
+DRM_PLANE_TYPE_PRIMARY : DRM_PLANE_TYPE_OVERLAY;
+plane_config.zpos = i;
+
+ret = exynos_plane_init(drm_dev, ctx-planes[i],
plane_config);
if (ret)
return ret;
}
diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.h
b/drivers/gpu/drm/exynos/exynos_drm_drv.h
index 4c14a89..35698f3 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_drv.h
+++ b/drivers/gpu/drm/exynos/exynos_drm_drv.h
@@ -116,6 +116,25 @@ struct exynos_drm_plane {
};
/*
+ * Exynos DRM plane configuration structure.
+ *
+ * @possible_crtcs: bitfield describing the valid CRTCs
+ * for this plane.
+ * @type: plane type (primary, overlay, etc.)
+ * @zpos: z-position of the plane.
+ * @pixel_formats: supported pixel formats.
+ * @num_pixel_formats: number of elements in 'pixel_formats'.
+ */
+
+struct exynos_drm_plane_config {
+unsigned long possible_crtcs;
+enum drm_plane_type type;
+unsigned int zpos;
+const uint32_t *pixel_formats;
+unsigned int num_pixel_formats;
+};
As a follow up of my atomic series I started cleaning up exynos drm a bit more
and right now I'm removing most of struct exynos_drm_plane. Most of the plane
information there is also present in plane-state thus I'm basically removing
all the duplicated information there.
Sounds like a good plan.
That said, I think we avoid creating exynos_drm_plane_config and stuff
everything directly in struct exynos_drm_plane, it will be quite small and
easier to manipulate.
So that would imply that we then just have:
int exynos_plane_init(struct drm_device *dev, struct exynos_drm_plane
*exynos_plane);
Correct?
Anyway, I'm going to wait then until the cleanups are posted and rebase
this series onto it.
With best wishes,
Tobias
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] thermal: exynos: Reorder exynos_map_dt_data() function
Hi Lukasz,
On 04/15/2015 08:05 PM, Lukasz Majewski wrote:
Hi Joonyoung,
Hi Lukasz,
On 01/30/2015 05:14 PM, Lukasz Majewski wrote:
Hi Eduardo, Abhilash,
On Thu, Jan 22, 2015 at 06:02:07PM +0530, Abhilash Kesavan wrote:
Hi Lukasz,
On Thu, Jan 22, 2015 at 2:31 PM, Lukasz Majewski
l.majew...@samsung.com wrote:
Hi Abhilash,
Hi Lukasz,
On Mon, Jan 19, 2015 at 5:14 PM, Lukasz Majewski
l.majew...@samsung.com wrote:
The exynos_map_dt_data() function must be called before
thermal_zone_of_sensor_register(), and hence provide tmu_read()
function, before it is needed.
This change is driven by adding support for enabling
thermal_zoneX when it is properly initialized.
One can read the mode of operation
at /sys/class/thermal/thermal_zone0/mode Such functionality was
missing in the of-thermal.c code.
Reported-by: Abhilash Kesavan a.kesa...@samsung.com
Signed-off-by: Lukasz Majewski l.majew...@samsung.com
---
drivers/thermal/samsung/exynos_tmu.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/thermal/samsung/exynos_tmu.c
b/drivers/thermal/samsung/exynos_tmu.c index 9d2d685..5d946ab
100644 --- a/drivers/thermal/samsung/exynos_tmu.c
+++ b/drivers/thermal/samsung/exynos_tmu.c
@@ -975,15 +975,16 @@ static int exynos_tmu_probe(struct
platform_device *pdev) platform_set_drvdata(pdev, data);
mutex_init(data-lock);
+ ret = exynos_map_dt_data(pdev);
+ if (ret)
+ goto err_sensor;
It's enough to just return ret.
One more, i think to need to take out regulator enable codes from
exynos_map_dt_data. If not, can't restore about regulator when error
occurs.
+
data-tzd =
thermal_zone_of_sensor_register(pdev-dev, 0, data,
exynos_sensor_ops); if (IS_ERR(data-tzd)) {
pr_err(thermal: tz: %p ERROR\n, data-tzd);
return PTR_ERR(data-tzd);
}
- ret = exynos_map_dt_data(pdev);
- if (ret)
- goto err_sensor;
pdata = data-pdata;
I have been testing this along with your v5 patch set and am
seeing incorrect temperature being reported at boot-up on
exynos7.
Does it show a maximal temperature value (0x1FF)?
I did not print the current temperature register, but I remember
the message showing ~105C. Will give you the register value when
I test with more debug prints tomorrow.
It looks
like exynos_tmu_read gets called from
thermal_zone_of_device_update during boot-up, now that we have
it populated early. However, as the tmu initialization function
has not been called yet it returns a wrong value. Does that
sound correct ?
No, this is a mistake. However, I'm wondering why on Exynos4/5
this error didn't show up...
I have been lowering the software trip point temperature in the
exynos7 dts file (to 55C) for testing purposes. Hence, when the
temperature is read incorrectly as ~105C the board trips at
boot-up
this is a very unusual
value - I had problems with
reading 0xFF values with
similar symptom (but this
was caused by lack of vtmu).
itself. Maybe for exynos4/5 the incorrect value read during
boot-up is in the non-tripping range and once the tmu is
initialized later it continues to function properly thereafter ?
The reordering is needed to be able to call set_mode callback at
of-thermal.c to set the mode.
If this change causes problems, then another solution (probably
not so neat) must be found.
Please let me know if you need any further details.
Abhilash, could you provide more details (like relevant output from
dmesg) and point me a list of patches which shall I apply to test
this issue on Exynos4/5?
What is the status of this patch? Is it still required?
It is strange, since on Exynos4/5 this works and some problems show
up when run on Exynos7.
I'm also wondering the status of this patch.
This patch has been dropped.
I get below errors when boots odroidxu3 board without this patch.
Could you share the exact SHA1 and branch which you use in your setup?
I tested with of odroidxu3 patchset for pwm-fan control of Anand Moon on
20150414 -next.
http://www.spinics.net/lists/arm-kernel/msg412031.html
For a reference please check following branch at github (this is the
code which should be merged to v4.1-rc1)
g...@github.com:lmajewski/linux-samsung-thermal.git
branch: next [1]
This branch includes exynos7 support done by Chanwoo.
I got following errors from branch [1] without patchset of Anand Moon,
[4.576442] thermal thermal_zone0: failed to read out thermal zone 0
[4.581685] 1006.tmu supply vtmu not found, using dummy regulator
[4.588223] thermal thermal_zone1: failed to read out thermal zone 1
[4.594110] 10064000.tmu supply vtmu not found, using dummy regulator
[4.600849] thermal
Re: [PATCH 1/2] thermal: exynos: Reorder exynos_map_dt_data() function
Hi Lukasz,
On 01/30/2015 05:14 PM, Lukasz Majewski wrote:
Hi Eduardo, Abhilash,
On Thu, Jan 22, 2015 at 06:02:07PM +0530, Abhilash Kesavan wrote:
Hi Lukasz,
On Thu, Jan 22, 2015 at 2:31 PM, Lukasz Majewski
l.majew...@samsung.com wrote:
Hi Abhilash,
Hi Lukasz,
On Mon, Jan 19, 2015 at 5:14 PM, Lukasz Majewski
l.majew...@samsung.com wrote:
The exynos_map_dt_data() function must be called before
thermal_zone_of_sensor_register(), and hence provide tmu_read()
function, before it is needed.
This change is driven by adding support for enabling
thermal_zoneX when it is properly initialized.
One can read the mode of operation
at /sys/class/thermal/thermal_zone0/mode Such functionality was
missing in the of-thermal.c code.
Reported-by: Abhilash Kesavan a.kesa...@samsung.com
Signed-off-by: Lukasz Majewski l.majew...@samsung.com
---
drivers/thermal/samsung/exynos_tmu.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/thermal/samsung/exynos_tmu.c
b/drivers/thermal/samsung/exynos_tmu.c index 9d2d685..5d946ab
100644 --- a/drivers/thermal/samsung/exynos_tmu.c
+++ b/drivers/thermal/samsung/exynos_tmu.c
@@ -975,15 +975,16 @@ static int exynos_tmu_probe(struct
platform_device *pdev) platform_set_drvdata(pdev, data);
mutex_init(data-lock);
+ ret = exynos_map_dt_data(pdev);
+ if (ret)
+ goto err_sensor;
It's enough to just return ret.
One more, i think to need to take out regulator enable codes from
exynos_map_dt_data. If not, can't restore about regulator when error
occurs.
+
data-tzd =
thermal_zone_of_sensor_register(pdev-dev, 0, data,
exynos_sensor_ops); if (IS_ERR(data-tzd)) {
pr_err(thermal: tz: %p ERROR\n, data-tzd);
return PTR_ERR(data-tzd);
}
- ret = exynos_map_dt_data(pdev);
- if (ret)
- goto err_sensor;
pdata = data-pdata;
I have been testing this along with your v5 patch set and am
seeing incorrect temperature being reported at boot-up on
exynos7.
Does it show a maximal temperature value (0x1FF)?
I did not print the current temperature register, but I remember the
message showing ~105C. Will give you the register value when I test
with more debug prints tomorrow.
It looks
like exynos_tmu_read gets called from
thermal_zone_of_device_update during boot-up, now that we have
it populated early. However, as the tmu initialization function
has not been called yet it returns a wrong value. Does that
sound correct ?
No, this is a mistake. However, I'm wondering why on Exynos4/5
this error didn't show up...
I have been lowering the software trip point temperature in the
exynos7 dts file (to 55C) for testing purposes. Hence, when the
temperature is read incorrectly as ~105C the board trips at boot-up
this is a very unusual
value - I had problems with
reading 0xFF values with
similar symptom (but this was
caused by lack of vtmu).
itself. Maybe for exynos4/5 the incorrect value read during boot-up
is in the non-tripping range and once the tmu is initialized later
it continues to function properly thereafter ?
The reordering is needed to be able to call set_mode callback at
of-thermal.c to set the mode.
If this change causes problems, then another solution (probably
not so neat) must be found.
Please let me know if you need any further details.
Abhilash, could you provide more details (like relevant output from
dmesg) and point me a list of patches which shall I apply to test this
issue on Exynos4/5?
What is the status of this patch? Is it still required?
It is strange, since on Exynos4/5 this works and some problems show up
when run on Exynos7.
I'm also wondering the status of this patch.
I get below errors when boots odroidxu3 board without this patch.
[4.831980] thermal thermal_zone0: failed to read out thermal zone (-22)
[4.838096] thermal thermal_zone1: failed to read out thermal zone (-22)
[4.844894] thermal thermal_zone2: failed to read out thermal zone (-22)
[4.851470] thermal thermal_zone3: failed to read out thermal zone (-22)
[4.858186] thermal thermal_zone4: failed to read out thermal zone (-22)
Thanks.
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/1] ARM: dts: Add keep-power-in-suspend to WiFi SDIO node for Peach Boards
Hello Kukjin, On 04/07/2015 05:09 PM, Doug Anderson wrote: Javier, On Tue, Apr 7, 2015 at 6:03 AM, Javier Martinez Canillas javier.marti...@collabora.co.uk wrote: The Marvell mwifiex driver prevents the system to enter into a suspend state if the card power is not preserved during a suspend/resume cycle. So Suspend-to-RAM and Suspend-to-idle is failing on Exynos5800 Peach Pi and Exynos5420 Peach Pit Chromebooks. Add the keep-power-in-suspend Power Management property to the SDIO/MMC node so the mwifiex suspend handler doesn't fail and the system is able to enter into a suspend state. Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk --- arch/arm/boot/dts/exynos5420-peach-pit.dts | 1 + arch/arm/boot/dts/exynos5800-peach-pi.dts | 1 + 2 files changed, 2 insertions(+) Reviewed-by: Doug Anderson diand...@chromium.org Any comments on this patch? Best regards, Javier -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] pwm: Add clk enable/disable for pwm_samsung_enable/pwm_samsung_disable
On Wed, 2015-04-15 at 03:35 +0930, Anand Moon wrote: diff --git a/drivers/pwm/pwm-samsung.c b/drivers/pwm/pwm-samsung.c index 3e9b583..b579753 100644 --- a/drivers/pwm/pwm-samsung.c +++ b/drivers/pwm/pwm-samsung.c @@ -247,6 +247,7 @@ static int pwm_samsung_enable(struct pwm_chip *chip, struct pwm_device *pwm) tcon = ~TCON_MANUALUPDATE(tcon_chan); tcon |= TCON_START(tcon_chan) | TCON_AUTORELOAD(tcon_chan); writel(tcon, our_chip-base + REG_TCON); + clk_prepare_enable(our_chip-base_clk); spin_unlock_irqrestore(samsung_pwm_lock, flags); @@ -265,6 +266,7 @@ static void pwm_samsung_disable(struct pwm_chip *chip, struct pwm_device *pwm) tcon = readl(our_chip-base + REG_TCON); tcon = ~TCON_AUTORELOAD(tcon_chan); writel(tcon, our_chip-base + REG_TCON); + clk_disable_unprepare(our_chip-base_clk); spin_unlock_irqrestore(samsung_pwm_lock, flags); } As far as i can tell this code doesn't have any effect. clk_enable is refcounted, so the clock will stay enabled for as long as the driver is loaded (as it's enabled in _probe). Your code above just raises and lowers the clocks enabled refcount, but won't actually ever cause it to be disabled. With respect to trying to disabling the clocks on pwm_disable, that will need some more work to ensure the output signal has the expected level when you turn of the clock. Specifically, when disabling from a non-100% duty state the driver relies on the PWM turning the output signal low at the end of a duty cycle. However if you turn off the clock at the start of a duty cycle while the output signal is still high it will unexpectedly remain high. -- Sjoerd Simons sjoerd.sim...@collabora.co.uk Collabora Ltd. -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] pwm: Add clk enable/disable for pwm_samsung_enable/pwm_samsung_disable
hi Sjoerd, Are you referring to handle of polarity (PWM_POLARITY_NORMAL/PWM_POLARITY_INVERSED) during enable and disable. How can I analyses if the clock is high and low. -Anand Moon On 15 April 2015 at 14:04, Sjoerd Simons sjoerd.sim...@collabora.co.uk wrote: On Wed, 2015-04-15 at 03:35 +0930, Anand Moon wrote: diff --git a/drivers/pwm/pwm-samsung.c b/drivers/pwm/pwm-samsung.c index 3e9b583..b579753 100644 --- a/drivers/pwm/pwm-samsung.c +++ b/drivers/pwm/pwm-samsung.c @@ -247,6 +247,7 @@ static int pwm_samsung_enable(struct pwm_chip *chip, struct pwm_device *pwm) tcon = ~TCON_MANUALUPDATE(tcon_chan); tcon |= TCON_START(tcon_chan) | TCON_AUTORELOAD(tcon_chan); writel(tcon, our_chip-base + REG_TCON); + clk_prepare_enable(our_chip-base_clk); spin_unlock_irqrestore(samsung_pwm_lock, flags); @@ -265,6 +266,7 @@ static void pwm_samsung_disable(struct pwm_chip *chip, struct pwm_device *pwm) tcon = readl(our_chip-base + REG_TCON); tcon = ~TCON_AUTORELOAD(tcon_chan); writel(tcon, our_chip-base + REG_TCON); + clk_disable_unprepare(our_chip-base_clk); spin_unlock_irqrestore(samsung_pwm_lock, flags); } As far as i can tell this code doesn't have any effect. clk_enable is refcounted, so the clock will stay enabled for as long as the driver is loaded (as it's enabled in _probe). Your code above just raises and lowers the clocks enabled refcount, but won't actually ever cause it to be disabled. With respect to trying to disabling the clocks on pwm_disable, that will need some more work to ensure the output signal has the expected level when you turn of the clock. Specifically, when disabling from a non-100% duty state the driver relies on the PWM turning the output signal low at the end of a duty cycle. However if you turn off the clock at the start of a duty cycle while the output signal is still high it will unexpectedly remain high. -- Sjoerd Simons sjoerd.sim...@collabora.co.uk Collabora Ltd. -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] thermal: exynos: Reorder exynos_map_dt_data() function
Hi Joonyoung,
Hi Lukasz,
On 01/30/2015 05:14 PM, Lukasz Majewski wrote:
Hi Eduardo, Abhilash,
On Thu, Jan 22, 2015 at 06:02:07PM +0530, Abhilash Kesavan wrote:
Hi Lukasz,
On Thu, Jan 22, 2015 at 2:31 PM, Lukasz Majewski
l.majew...@samsung.com wrote:
Hi Abhilash,
Hi Lukasz,
On Mon, Jan 19, 2015 at 5:14 PM, Lukasz Majewski
l.majew...@samsung.com wrote:
The exynos_map_dt_data() function must be called before
thermal_zone_of_sensor_register(), and hence provide tmu_read()
function, before it is needed.
This change is driven by adding support for enabling
thermal_zoneX when it is properly initialized.
One can read the mode of operation
at /sys/class/thermal/thermal_zone0/mode Such functionality was
missing in the of-thermal.c code.
Reported-by: Abhilash Kesavan a.kesa...@samsung.com
Signed-off-by: Lukasz Majewski l.majew...@samsung.com
---
drivers/thermal/samsung/exynos_tmu.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/thermal/samsung/exynos_tmu.c
b/drivers/thermal/samsung/exynos_tmu.c index 9d2d685..5d946ab
100644 --- a/drivers/thermal/samsung/exynos_tmu.c
+++ b/drivers/thermal/samsung/exynos_tmu.c
@@ -975,15 +975,16 @@ static int exynos_tmu_probe(struct
platform_device *pdev) platform_set_drvdata(pdev, data);
mutex_init(data-lock);
+ ret = exynos_map_dt_data(pdev);
+ if (ret)
+ goto err_sensor;
It's enough to just return ret.
One more, i think to need to take out regulator enable codes from
exynos_map_dt_data. If not, can't restore about regulator when error
occurs.
+
data-tzd =
thermal_zone_of_sensor_register(pdev-dev, 0, data,
exynos_sensor_ops); if (IS_ERR(data-tzd)) {
pr_err(thermal: tz: %p ERROR\n, data-tzd);
return PTR_ERR(data-tzd);
}
- ret = exynos_map_dt_data(pdev);
- if (ret)
- goto err_sensor;
pdata = data-pdata;
I have been testing this along with your v5 patch set and am
seeing incorrect temperature being reported at boot-up on
exynos7.
Does it show a maximal temperature value (0x1FF)?
I did not print the current temperature register, but I remember
the message showing ~105C. Will give you the register value when
I test with more debug prints tomorrow.
It looks
like exynos_tmu_read gets called from
thermal_zone_of_device_update during boot-up, now that we have
it populated early. However, as the tmu initialization function
has not been called yet it returns a wrong value. Does that
sound correct ?
No, this is a mistake. However, I'm wondering why on Exynos4/5
this error didn't show up...
I have been lowering the software trip point temperature in the
exynos7 dts file (to 55C) for testing purposes. Hence, when the
temperature is read incorrectly as ~105C the board trips at
boot-up
this is a very unusual
value - I had problems with
reading 0xFF values with
similar symptom (but this
was caused by lack of vtmu).
itself. Maybe for exynos4/5 the incorrect value read during
boot-up is in the non-tripping range and once the tmu is
initialized later it continues to function properly thereafter ?
The reordering is needed to be able to call set_mode callback at
of-thermal.c to set the mode.
If this change causes problems, then another solution (probably
not so neat) must be found.
Please let me know if you need any further details.
Abhilash, could you provide more details (like relevant output from
dmesg) and point me a list of patches which shall I apply to test
this issue on Exynos4/5?
What is the status of this patch? Is it still required?
It is strange, since on Exynos4/5 this works and some problems show
up when run on Exynos7.
I'm also wondering the status of this patch.
This patch has been dropped.
I get below errors when boots odroidxu3 board without this patch.
Could you share the exact SHA1 and branch which you use in your setup?
For a reference please check following branch at github (this is the
code which should be merged to v4.1-rc1)
g...@github.com:lmajewski/linux-samsung-thermal.git
branch: next [1]
This branch includes exynos7 support done by Chanwoo.
[4.831980] thermal thermal_zone0: failed to read out thermal zone
(-22) [4.838096] thermal thermal_zone1: failed to read out
thermal zone (-22) [4.844894] thermal thermal_zone2: failed to
read out thermal zone (-22) [4.851470] thermal thermal_zone3:
failed to read out thermal zone (-22) [4.858186] thermal
thermal_zone4: failed to read out thermal zone (-22)
This issue has been fixed by following patch:
thermal: exynos: fix: Check if data-tmu_read callback is
