[PATCH v2] ARM: EXYNOS: Use platform device name as power domain name
The power domain nodes in DTS may be very generic (e.g. power-domain for Exynos 5420) making it very hard to debug: $ cat /sys/kernel/debug/pm_genpd/pm_genpd_summary domain status slaves power-domainon Use platform device name instead so the names will be a little more user friendly: domain status slaves 100440e0.power-domain on Signed-off-by: Krzysztof Kozlowski k.kozlow...@samsung.com Suggested-by: Javier Martinez Canillas javier.marti...@collabora.co.uk Suggested-by: Sergei Shtylyov sergei.shtyl...@cogentembedded.com Reviewed-by: Javier Martinez Canillas javier.marti...@collabora.co.uk --- Notes: Changes since v1: 1. Add Javier's reviewed-by. arch/arm/mach-exynos/pm_domains.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/arm/mach-exynos/pm_domains.c b/arch/arm/mach-exynos/pm_domains.c index 37266a826437..84e1d9f4d76c 100644 --- a/arch/arm/mach-exynos/pm_domains.c +++ b/arch/arm/mach-exynos/pm_domains.c @@ -125,7 +125,7 @@ static __init int exynos4_pm_init_power_domain(void) return -ENOMEM; } - pd-pd.name = kstrdup(np-name, GFP_KERNEL); + pd-pd.name = kstrdup(dev_name(dev), GFP_KERNEL); pd-name = pd-pd.name; pd-base = of_iomap(np, 0); pd-pd.power_off = exynos_pd_power_off; -- 1.9.1 -- 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] dmaengine: pl330: Set residue in tx_status callback
Hi Vinod, Hi Russell, On 11 December 2014 at 11:42, Jassi Brar jaswinder.si...@linaro.org wrote: On 11 December 2014 at 10:17, Vinod Koul vinod.k...@intel.com wrote: On Tue, Dec 09, 2014 at 08:48:04PM +0530, Jassi Brar wrote: As Russell pointed out, that ain't the case either. So we are yet to figure out benefits of having explicit issue_pending() after tx_submit(). callback ? The callback is set after prep() and before tx_submit(), but here we talk after tx_submit(). Perhaps the idea dates back to async-only days, when client drivers would prepare and queue descriptors in the controller driver rather than having to manage the dependency queues themselves (?). Today ~95% clients are slave and I am yet to find one that really can't work with submit and issue_pending tied together. Not to forget the 100% of the controller drivers have to manage 'submitted' and 'active' queues -- only to have arguably negative side-effects. If we agree that clubbing submit and issue_pending is the right thing to do, I can start converting the ~90 client drivers. Please let me know either way. Cheers! -- 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
[PATCH 7/7] exynos: fimg2d: follow-up fix for G2D_COEFF_MODE_GB_COLOR
Also add the register field formatting info provided by
Inki Dae inki@samsung.com.
Signed-off-by: Tobias Jakobi tjak...@math.uni-bielefeld.de
Reviewed-by: Inki Dae inki@samsung.com
Tested-by: Joonyoung Shim jy0922.s...@samsung.com
---
exynos/exynos_fimg2d.h | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/exynos/exynos_fimg2d.h b/exynos/exynos_fimg2d.h
index f76f2a9..9db0c88 100644
--- a/exynos/exynos_fimg2d.h
+++ b/exynos/exynos_fimg2d.h
@@ -151,6 +151,12 @@ enum e_g2d_op {
G2D_OP_CONJOINT_DST = 0x22,
};
+/*
+ * The G2D_COEFF_MODE_DST_{COLOR,ALPHA} modes both use the ALPHA_REG(0x618)
+ * register. The registers fields are as follows:
+ * bits 31:8 = color value (RGB order)
+ * bits 7:0 = alpha value
+ */
enum e_g2d_coeff_mode {
G2D_COEFF_MODE_ONE,
G2D_COEFF_MODE_ZERO,
@@ -160,7 +166,7 @@ enum e_g2d_coeff_mode {
G2D_COEFF_MODE_DST_COLOR,
/* Global Alpha : Set by ALPHA_REG(0x618) */
G2D_COEFF_MODE_GB_ALPHA,
- /* Global Color : Set by ALPHA_REG(0x618) */
+ /* Global Color and Alpha : Set by ALPHA_REG(0x618) */
G2D_COEFF_MODE_GB_COLOR,
/* (1-SRC alpha)/DST Alpha */
G2D_COEFF_MODE_DISJOINT_S,
--
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: [PATCH 4/7] drm/exynos: make zpos property immutable
On 2015년 02월 19일 22:22, Gustavo Padovan wrote:
From: Gustavo Padovan gustavo.pado...@collabora.co.uk
We already set each plane zpos at init, after that changes to zpos are
not expected. This patch turns zpos into a read-only property so now it is
impossible to set zpos.
Signed-off-by: Gustavo Padovan gustavo.pado...@collabora.co.uk
---
drivers/gpu/drm/exynos/exynos_drm_plane.c | 21 ++---
1 file changed, 2 insertions(+), 19 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_plane.c
b/drivers/gpu/drm/exynos/exynos_drm_plane.c
index 504bd6e..2fbac9b 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_plane.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_plane.c
@@ -184,27 +184,10 @@ static void exynos_plane_destroy(struct drm_plane
*plane)
drm_plane_cleanup(plane);
}
-static int exynos_plane_set_property(struct drm_plane *plane,
- struct drm_property *property,
- uint64_t val)
-{
- struct drm_device *dev = plane-dev;
- struct exynos_drm_plane *exynos_plane = to_exynos_plane(plane);
- struct exynos_drm_private *dev_priv = dev-dev_private;
-
- if (property == dev_priv-plane_zpos_property) {
- exynos_plane-zpos = val;
- return 0;
- }
-
- return -EINVAL;
-}
-
static struct drm_plane_funcs exynos_plane_funcs = {
.update_plane = exynos_update_plane,
.disable_plane = exynos_disable_plane,
.destroy= exynos_plane_destroy,
- .set_property = exynos_plane_set_property,
It's a good idea for a hardware overlay to a plane object isn't changed
by user-space. However, this patch would make the compatibility of the
existing application - using set_property ioctl to change hardware
overlay to particular plane - to be broken because the set_property
ioctl request will always be failed without the set_property callback.
So how about leaving warning message 'the hardware overlay cannot be
changed to another anymore' when the set_property ioctl is requested by
user-space, and returning just 0?
Thanks,
Inki Dae
};
static void exynos_plane_attach_zpos_property(struct drm_plane *plane,
@@ -216,8 +199,8 @@ static void exynos_plane_attach_zpos_property(struct
drm_plane *plane,
prop = dev_priv-plane_zpos_property;
if (!prop) {
- prop = drm_property_create_range(dev, 0, zpos, 0,
- MAX_PLANE - 1);
+ prop = drm_property_create_range(dev, DRM_MODE_PROP_IMMUTABLE,
+ zpos, 0, MAX_PLANE - 1);
if (!prop)
return;
--
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
[PATCH 1/7] tests/exynos: fimg2d: add a checkerboard test
This makes it easier to spot memory corruptions which don't become
visible when using a plain buffer filled with a solid color (so
corruptions that are just a permutation of the bytes in the buffer).
Signed-off-by: Tobias Jakobi tjak...@math.uni-bielefeld.de
Reviewed-by: Inki Dae inki@samsung.com
Tested-by: Joonyoung Shim jy0922.s...@samsung.com
---
tests/exynos/exynos_fimg2d_test.c | 117 ++
1 file changed, 117 insertions(+)
diff --git a/tests/exynos/exynos_fimg2d_test.c
b/tests/exynos/exynos_fimg2d_test.c
index 14b38a9..da23f58 100644
--- a/tests/exynos/exynos_fimg2d_test.c
+++ b/tests/exynos/exynos_fimg2d_test.c
@@ -57,6 +57,9 @@ struct fimg2d_test_case {
int (*blend)(struct exynos_device *dev,
struct exynos_bo *src, struct exynos_bo *dst,
enum e_g2d_buf_type);
+ int (*checkerboard)(struct exynos_device *dev,
+ struct exynos_bo *src, struct exynos_bo *dst,
+ enum e_g2d_buf_type);
};
struct connector {
@@ -209,6 +212,33 @@ static struct exynos_bo *exynos_create_buffer(struct
exynos_device *dev,
return bo;
}
+/* Allocate buffer and fill it with checkerboard pattern, where the tiles *
+ * have a random color. The caller has to free the buffer.*/
+void *create_checkerboard_pattern(unsigned int num_tiles_x,
+ unsigned int num_tiles_y,
unsigned int tile_size)
+{
+ unsigned int *buf;
+ unsigned int x, y, i, j;
+ const unsigned int stride = num_tiles_x * tile_size;
+
+ if (posix_memalign((void*)buf, 64, num_tiles_y * tile_size * stride *
4) != 0)
+ return NULL;
+
+ for (x = 0; x num_tiles_x; ++x) {
+ for (y = 0; y num_tiles_y; ++y) {
+ const unsigned int color = 0xff00 + (random()
0xff);
+
+ for (i = 0; i tile_size; ++i) {
+ for (j = 0; j tile_size; ++j) {
+ buf[x * tile_size + y * stride *
tile_size + i + j * stride] = color;
+ }
+ }
+ }
+ }
+
+ return buf;
+}
+
static void exynos_destroy_buffer(struct exynos_bo *bo)
{
exynos_bo_destroy(bo);
@@ -540,11 +570,90 @@ err_free_userptr:
return 0;
}
+static int g2d_checkerboard_test(struct exynos_device *dev,
+ struct exynos_bo *src,
+ struct exynos_bo *dst,
+ enum e_g2d_buf_type type)
+{
+ struct g2d_context *ctx;
+ struct g2d_image src_img = {0}, dst_img = {0};
+ unsigned int src_x, src_y, dst_x, dst_y, img_w, img_h;
+ void *checkerboard = NULL;
+ int ret;
+
+ ctx = g2d_init(dev-fd);
+ if (!ctx)
+ return -EFAULT;
+
+ dst_img.bo[0] = dst-handle;
+
+ src_x = 0;
+ src_y = 0;
+ dst_x = 0;
+ dst_y = 0;
+
+ checkerboard = create_checkerboard_pattern(screen_width / 32,
screen_height / 32, 32);
+ if (checkerboard == NULL) {
+ ret = -1;
+ goto fail;
+ }
+
+ img_w = screen_width - (screen_width % 32);
+ img_h = screen_height - (screen_height % 32);
+
+ switch (type) {
+ case G2D_IMGBUF_GEM:
+ memcpy(src-vaddr, checkerboard, img_w * img_h * 4);
+ src_img.bo[0] = src-handle;
+ break;
+ case G2D_IMGBUF_USERPTR:
+ src_img.user_ptr[0].userptr = (unsigned long)checkerboard;
+ src_img.user_ptr[0].size = img_w * img_h * 4;
+ break;
+ default:
+ ret = -EFAULT;
+ goto fail;
+ }
+
+ printf(checkerboard test with %s.\n,
+ type == G2D_IMGBUF_GEM ? gem : userptr);
+
+ src_img.width = img_w;
+ src_img.height = img_h;
+ src_img.stride = src_img.width * 4;
+ src_img.buf_type = type;
+ src_img.color_mode = G2D_COLOR_FMT_ARGB | G2D_ORDER_AXRGB;
+
+ dst_img.width = screen_width;
+ dst_img.height = screen_height;
+ dst_img.stride = dst_img.width * 4;
+ dst_img.buf_type = G2D_IMGBUF_GEM;
+ dst_img.color_mode = G2D_COLOR_FMT_ARGB | G2D_ORDER_AXRGB;
+ src_img.color = 0xff00;
+ ret = g2d_solid_fill(ctx, dst_img, src_x, src_y, screen_width,
screen_height);
+ if (ret 0)
+ goto fail;
+
+ ret = g2d_copy(ctx, src_img, dst_img, src_x, src_y, dst_x, dst_y,
+ img_w, img_h);
+ if (ret 0)
+ goto fail;
+
+ g2d_exec(ctx);
+
+fail:
+ free(checkerboard);
+ g2d_fini(ctx);
+
+ return ret;
+}
+
static struct fimg2d_test_case test_case = {
.solid_fill = g2d_solid_fill_test,
[PATCH v2] clocksource: exynos_mct: fix for sleeping in atomic ctx handling cpu hotplug notif.
This is to fix an issue of sleeping in atomic context when processing
hotplug notifications in Exynos MCT(Multi-Core Timer).
The issue was reproducible on Exynos 3250 (Rinato board) and Exynos 5420
(Arndale Octa board).
Whilst testing cpu hotplug events on kernel configured with DEBUG_PREEMPT
and DEBUG_ATOMIC_SLEEP we get following BUG message, caused by calling
request_irq() and free_irq() in the context of hotplug notification
(which is in this case atomic context).
root@target:~# echo 0 /sys/devices/system/cpu/cpu1/online
[ 25.157867] IRQ18 no longer affine to CPU1
...
[ 25.158445] CPU1: shutdown
root@target:~# echo 1 /sys/devices/system/cpu/cpu1/online
[ 40.785859] CPU1: Software reset
[ 40.786660] BUG: sleeping function called from invalid context at
mm/slub.c:1241
[ 40.786668] in_atomic(): 1, irqs_disabled(): 128, pid: 0, name: swapper/1
[ 40.786678] Preemption disabled at:[ (null)] (null)
[ 40.786681]
[ 40.786692] CPU: 1 PID: 0 Comm: swapper/1 Not tainted
3.19.0-rc4-00024-g7dca860 #36
[ 40.786698] Hardware name: SAMSUNG EXYNOS (Flattened Device Tree)
[ 40.786728] [c0014a00] (unwind_backtrace) from [c0011980]
(show_stack+0x10/0x14)
[ 40.786747] [c0011980] (show_stack) from [c0449ba0]
(dump_stack+0x70/0xbc)
[ 40.786767] [c0449ba0] (dump_stack) from [c00c6124]
(kmem_cache_alloc+0xd8/0x170)
[ 40.786785] [c00c6124] (kmem_cache_alloc) from [c005d6f8]
(request_threaded_irq+0x64/0x128)
[ 40.786804] [c005d6f8] (request_threaded_irq) from [c0350b8c]
(exynos4_local_timer_setup+0xc0/0x13c)
[ 40.786820] [c0350b8c] (exynos4_local_timer_setup) from [c0350ca8]
(exynos4_mct_cpu_notify+0x30/0xa8)
[ 40.786838] [c0350ca8] (exynos4_mct_cpu_notify) from [c003b330]
(notifier_call_chain+0x44/0x84)
[ 40.786857] [c003b330] (notifier_call_chain) from [c0022fd4]
(__cpu_notify+0x28/0x44)
[ 40.786873] [c0022fd4] (__cpu_notify) from [c0013714]
(secondary_start_kernel+0xec/0x150)
[ 40.786886] [c0013714] (secondary_start_kernel) from [40008764]
(0x40008764)
Solution:
Clockevent irqs cannot be requested/freed every time cpu is
hot-plugged/unplugged as CPU_STARTING/CPU_DYING notifications
that signals hotplug or unplug events are sent with both preemption
and local interrupts disabled. Since request_irq() may sleep it is
moved to the initialization stage and performed for all possible
cpus prior putting them online. Then, in the case of hotplug event
the irq asociated with the given cpu will simply be enabled.
Similarly on cpu unplug event the interrupt is not freed but just
disabled.
Note that after successful request_irq() call for a clockevent device
associated to given cpu the requested irq is disabled (via disable_irq()).
That is to make things symmetric as we expect hotplug event as a next
thing (which will enable irq again). This should not pose any problems
because at the time of requesting irq the clockevent device is not
fully initialized yet, therefore should not produce interrupts at that point.
For disabling an irq at cpu unplug notification disable_irq_nosync() is
chosen which is a non-blocking function. This again shouldn't be a problem as
prior sending CPU_DYING notification interrupts are migrated away
from the cpu.
Fixes: 7114cd749a12 (clocksource: exynos_mct: use (request/free)_irq calls for
local timer registration)
Signed-off-by: Damian Eppel d.ep...@samsung.com
Cc: sta...@vger.kernel.org
Reported-by: Krzysztof Kozlowski k.kozlow...@samsung.com
Reviewed-by: Krzysztof Kozlowski k.kozlow...@samsung.com
Tested-by: Krzysztof Kozlowski k.kozlow...@samsung.com
(Tested on Arndale Octa Board)
Tested-by: Marcin Jabrzyk m.jabr...@samsung.com
(Tested on Rinato B2 (Exynos 3250) board)
---
Notes:
Changes since v1:
o added Krzysztof's and Marcin's Reviewed-by / Tested-by
with information about the test HW.
drivers/clocksource/exynos_mct.c | 45
1 file changed, 32 insertions(+), 13 deletions(-)
diff --git a/drivers/clocksource/exynos_mct.c b/drivers/clocksource/exynos_mct.c
index 83564c9..9beca58 100644
--- a/drivers/clocksource/exynos_mct.c
+++ b/drivers/clocksource/exynos_mct.c
@@ -466,15 +466,12 @@ static int exynos4_local_timer_setup(struct
clock_event_device *evt)
exynos4_mct_write(TICK_BASE_CNT, mevt-base + MCT_L_TCNTB_OFFSET);
if (mct_int_type == MCT_INT_SPI) {
- evt-irq = mct_irqs[MCT_L0_IRQ + cpu];
- if (request_irq(evt-irq, exynos4_mct_tick_isr,
- IRQF_TIMER | IRQF_NOBALANCING,
- evt-name, mevt)) {
- pr_err(exynos-mct: cannot register IRQ %d\n,
- evt-irq);
+
+ if (evt-irq == -1)
return -EIO;
- }
- irq_force_affinity(mct_irqs[MCT_L0_IRQ + cpu], cpumask_of(cpu));
+
+ irq_force_affinity(evt-irq, cpumask_of(cpu));
+
Re: [v3] libdrm: improvements to userspace exynos component
On 2015-03-11 19:56, Emil Velikov wrote: Tobias, Can you please re-spin the remaining patches on top of master, and address Inki's comment. Also please add Inki's and Joonyoung Shim's tags. Done. I hope I did the tagging correctly. 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
[PATCH 3/7] exynos: honor the repeat mode in g2d_copy_with_scale
This is useful when the default repeat mode, which is 'repeat' produces artifacts at the borders of the copied image. Choose the 'pad' mode to make use of the color of the destination image. In my usage case the destination is the framebuffer, which is solid filled with a background color. Scaling with 'pad' mode would then just do the right thing and also produces nice borders on the output. Signed-off-by: Tobias Jakobi tjak...@math.uni-bielefeld.de Reviewed-by: Inki Dae inki@samsung.com Tested-by: Joonyoung Shim jy0922.s...@samsung.com --- exynos/exynos_fimg2d.c | 5 + 1 file changed, 5 insertions(+) diff --git a/exynos/exynos_fimg2d.c b/exynos/exynos_fimg2d.c index 20c3179..5f9e9a7 100644 --- a/exynos/exynos_fimg2d.c +++ b/exynos/exynos_fimg2d.c @@ -462,6 +462,11 @@ g2d_copy_with_scale(struct g2d_context *ctx, struct g2d_image *src, g2d_add_cmd(ctx, SRC_SELECT_REG, G2D_SELECT_MODE_NORMAL); g2d_add_cmd(ctx, SRC_COLOR_MODE_REG, src-color_mode); + + g2d_add_cmd(ctx, SRC_REPEAT_MODE_REG, src-repeat_mode); + if (src-repeat_mode == G2D_REPEAT_MODE_PAD) + g2d_add_cmd(ctx, SRC_PAD_VALUE_REG, dst-color); + g2d_add_base_addr(ctx, src, g2d_src); g2d_add_cmd(ctx, SRC_STRIDE_REG, src-stride); -- 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
[PATCH 2/7] exynos: add g2d_scale_and_blend
This is a combination of g2d_copy_with_scale and g2d_scale.
It is a pretty common operation to scale one buffer and then
blend it on top of another, so provide a direct way to that
operation.
Signed-off-by: Tobias Jakobi tjak...@math.uni-bielefeld.de
Reviewed-by: Inki Dae inki@samsung.com
Tested-by: Joonyoung Shim jy0922.s...@samsung.com
---
exynos/exynos_fimg2d.c | 129 +
exynos/fimg2d.h| 5 ++
2 files changed, 134 insertions(+)
diff --git a/exynos/exynos_fimg2d.c b/exynos/exynos_fimg2d.c
index 7a3da82..20c3179 100644
--- a/exynos/exynos_fimg2d.c
+++ b/exynos/exynos_fimg2d.c
@@ -638,3 +638,132 @@ g2d_blend(struct g2d_context *ctx, struct g2d_image *src,
return 0;
}
+/**
+ * g2d_scale_and_blend - apply scaling to source buffer and then blend to
destination buffer
+ *
+ * @ctx: a pointer to g2d_context structure.
+ * @src: a pointer to g2d_image structure including image and buffer
+ * information to source.
+ * @dst: a pointer to g2d_image structure including image and buffer
+ * information to destination.
+ * @src_x: x start position to source buffer.
+ * @src_y: y start position to source buffer.
+ * @src_w: width value to source buffer.
+ * @src_h: height value to source buffer.
+ * @dst_x: x start position to destination buffer.
+ * @dst_y: y start position to destination buffer.
+ * @dst_w: width value to destination buffer.
+ * @dst_h: height value to destination buffer.
+ * @op: blend operation type.
+ */
+drm_public int
+g2d_scale_and_blend(struct g2d_context *ctx, struct g2d_image *src,
+ struct g2d_image *dst, unsigned int src_x, unsigned int src_y,
+ unsigned int src_w, unsigned int src_h, unsigned int dst_x,
+ unsigned int dst_y, unsigned int dst_w, unsigned int dst_h,
+ enum e_g2d_op op)
+{
+ union g2d_point_val pt;
+ union g2d_bitblt_cmd_val bitblt;
+ union g2d_blend_func_val blend;
+ unsigned int scale;
+ unsigned int scale_x, scale_y;
+
+ bitblt.val = 0;
+ blend.val = 0;
+
+ if (op == G2D_OP_SRC || op == G2D_OP_CLEAR)
+ g2d_add_cmd(ctx, DST_SELECT_REG, G2D_SELECT_MODE_BGCOLOR);
+ else
+ g2d_add_cmd(ctx, DST_SELECT_REG, G2D_SELECT_MODE_NORMAL);
+
+ g2d_add_cmd(ctx, DST_COLOR_MODE_REG, dst-color_mode);
+ if (dst-buf_type == G2D_IMGBUF_USERPTR)
+ g2d_add_cmd(ctx, DST_BASE_ADDR_REG | G2D_BUF_USERPTR,
+ (unsigned long)dst-user_ptr[0]);
+ else
+ g2d_add_cmd(ctx, DST_BASE_ADDR_REG, dst-bo[0]);
+
+ g2d_add_cmd(ctx, DST_STRIDE_REG, dst-stride);
+
+ g2d_add_cmd(ctx, SRC_SELECT_REG, src-select_mode);
+ g2d_add_cmd(ctx, SRC_COLOR_MODE_REG, src-color_mode);
+
+ switch (src-select_mode) {
+ case G2D_SELECT_MODE_NORMAL:
+ if (src-buf_type == G2D_IMGBUF_USERPTR)
+ g2d_add_cmd(ctx, SRC_BASE_ADDR_REG | G2D_BUF_USERPTR,
+ (unsigned long)src-user_ptr[0]);
+ else
+ g2d_add_cmd(ctx, SRC_BASE_ADDR_REG, src-bo[0]);
+
+ g2d_add_cmd(ctx, SRC_STRIDE_REG, src-stride);
+ break;
+ case G2D_SELECT_MODE_FGCOLOR:
+ g2d_add_cmd(ctx, FG_COLOR_REG, src-color);
+ break;
+ case G2D_SELECT_MODE_BGCOLOR:
+ g2d_add_cmd(ctx, BG_COLOR_REG, src-color);
+ break;
+ default:
+ fprintf(stderr , failed to set src.\n);
+ return -EINVAL;
+ }
+
+ if (src_w == dst_w src_h == dst_h)
+ scale = 0;
+ else {
+ scale = 1;
+ scale_x = g2d_get_scaling(src_w, dst_w);
+ scale_y = g2d_get_scaling(src_h, dst_h);
+ }
+
+ if (src_x + src_w src-width)
+ src_w = src-width - src_x;
+ if (src_y + src_h src-height)
+ src_h = src-height - src_y;
+
+ if (dst_x + dst_w dst-width)
+ dst_w = dst-width - dst_x;
+ if (dst_y + dst_h dst-height)
+ dst_h = dst-height - dst_y;
+
+ if (src_w = 0 || src_h = 0 || dst_w = 0 || dst_h = 0) {
+ fprintf(stderr, invalid width or height.\n);
+ g2d_reset(ctx);
+ return -EINVAL;
+ }
+
+ if (scale) {
+ g2d_add_cmd(ctx, SRC_SCALE_CTRL_REG, G2D_SCALE_MODE_BILINEAR);
+ g2d_add_cmd(ctx, SRC_XSCALE_REG, scale_x);
+ g2d_add_cmd(ctx, SRC_YSCALE_REG, scale_y);
+ }
+
+ bitblt.data.alpha_blend_mode = G2D_ALPHA_BLEND_MODE_ENABLE;
+ blend.val = g2d_get_blend_op(op);
+ g2d_add_cmd(ctx, BITBLT_COMMAND_REG, bitblt.val);
+ g2d_add_cmd(ctx, BLEND_FUNCTION_REG, blend.val);
+
+ pt.val = 0;
+ pt.data.x = src_x;
+ pt.data.y = src_y;
+ g2d_add_cmd(ctx, SRC_LEFT_TOP_REG, pt.val);
+
[PATCH 4/7] exynos: use structure initialization instead of memset
Keeps the code cleaner, since the structs have to be initialized
once anyway.
Signed-off-by: Tobias Jakobi tjak...@math.uni-bielefeld.de
Reviewed-by: Inki Dae inki@samsung.com
Tested-by: Joonyoung Shim jy0922.s...@samsung.com
---
exynos/exynos_fimg2d.c| 4 +---
tests/exynos/exynos_fimg2d_test.c | 15 ---
2 files changed, 5 insertions(+), 14 deletions(-)
diff --git a/exynos/exynos_fimg2d.c b/exynos/exynos_fimg2d.c
index 5f9e9a7..aecd1c3 100644
--- a/exynos/exynos_fimg2d.c
+++ b/exynos/exynos_fimg2d.c
@@ -188,7 +188,7 @@ static void g2d_reset(struct g2d_context *ctx)
static int g2d_flush(struct g2d_context *ctx)
{
int ret;
- struct drm_exynos_g2d_set_cmdlist cmdlist;
+ struct drm_exynos_g2d_set_cmdlist cmdlist = {0};
if (ctx-cmd_nr == 0 ctx-cmd_buf_nr == 0)
return -1;
@@ -198,8 +198,6 @@ static int g2d_flush(struct g2d_context *ctx)
return -EINVAL;
}
- memset(cmdlist, 0, sizeof(struct drm_exynos_g2d_set_cmdlist));
-
cmdlist.cmd = (uint64_t)(uintptr_t)ctx-cmd[0];
cmdlist.cmd_buf = (uint64_t)(uintptr_t)ctx-cmd_buf[0];
cmdlist.cmd_nr = ctx-cmd_nr;
diff --git a/tests/exynos/exynos_fimg2d_test.c
b/tests/exynos/exynos_fimg2d_test.c
index da23f58..b7003c4 100644
--- a/tests/exynos/exynos_fimg2d_test.c
+++ b/tests/exynos/exynos_fimg2d_test.c
@@ -255,7 +255,7 @@ static void wait_for_user_input(int last)
static int g2d_solid_fill_test(struct exynos_device *dev, struct exynos_bo
*dst)
{
struct g2d_context *ctx;
- struct g2d_image img;
+ struct g2d_image img = {0};
unsigned int count, img_w, img_h;
int ret = 0;
@@ -263,7 +263,6 @@ static int g2d_solid_fill_test(struct exynos_device *dev,
struct exynos_bo *dst)
if (!ctx)
return -EFAULT;
- memset(img, 0, sizeof(struct g2d_image));
img.bo[0] = dst-handle;
printf(solid fill test.\n);
@@ -306,7 +305,7 @@ static int g2d_copy_test(struct exynos_device *dev, struct
exynos_bo *src,
enum e_g2d_buf_type type)
{
struct g2d_context *ctx;
- struct g2d_image src_img, dst_img;
+ struct g2d_image src_img = {0}, dst_img = {0};
unsigned int src_x, src_y, dst_x, dst_y, img_w, img_h;
unsigned long userptr, size;
int ret;
@@ -315,8 +314,6 @@ static int g2d_copy_test(struct exynos_device *dev, struct
exynos_bo *src,
if (!ctx)
return -EFAULT;
- memset(src_img, 0, sizeof(struct g2d_image));
- memset(dst_img, 0, sizeof(struct g2d_image));
dst_img.bo[0] = dst-handle;
src_x = 0;
@@ -389,7 +386,7 @@ static int g2d_copy_with_scale_test(struct exynos_device
*dev,
enum e_g2d_buf_type type)
{
struct g2d_context *ctx;
- struct g2d_image src_img, dst_img;
+ struct g2d_image src_img = {0}, dst_img = {0};
unsigned int src_x, src_y, dst_x, dst_y, img_w, img_h;
unsigned long userptr, size;
int ret;
@@ -398,8 +395,6 @@ static int g2d_copy_with_scale_test(struct exynos_device
*dev,
if (!ctx)
return -EFAULT;
- memset(src_img, 0, sizeof(struct g2d_image));
- memset(dst_img, 0, sizeof(struct g2d_image));
dst_img.bo[0] = dst-handle;
src_x = 0;
@@ -477,7 +472,7 @@ static int g2d_blend_test(struct exynos_device *dev,
enum e_g2d_buf_type type)
{
struct g2d_context *ctx;
- struct g2d_image src_img, dst_img;
+ struct g2d_image src_img = {0}, dst_img = {0};
unsigned int src_x, src_y, dst_x, dst_y, img_w, img_h;
unsigned long userptr, size;
int ret;
@@ -486,8 +481,6 @@ static int g2d_blend_test(struct exynos_device *dev,
if (!ctx)
return -EFAULT;
- memset(src_img, 0, sizeof(struct g2d_image));
- memset(dst_img, 0, sizeof(struct g2d_image));
dst_img.bo[0] = dst-handle;
src_x = 0;
--
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
[PATCH] phy: exynos5-usbdrd: Add to support for Exynos5433 SoC
This patch adds driver data to support for Exynos5433 SoC.
The Exynos5433 has one USB3.0 Host and USB3.0 DRD(Dual Role Device).
Exynos5433 is simplar to Eyxnos7 but Exynos5433 have
one more USB3.0 Host controller.
Signed-off-by: Jaewon Kim jaewon02@samsung.com
---
.../devicetree/bindings/phy/samsung-phy.txt|3 ++-
drivers/phy/phy-exynos5-usbdrd.c | 10 ++
include/linux/mfd/syscon/exynos5-pmu.h |3 +++
3 files changed, 15 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/phy/samsung-phy.txt
b/Documentation/devicetree/bindings/phy/samsung-phy.txt
index 91e38cf..60c6f2a 100644
--- a/Documentation/devicetree/bindings/phy/samsung-phy.txt
+++ b/Documentation/devicetree/bindings/phy/samsung-phy.txt
@@ -128,6 +128,7 @@ Required properties:
- compatible : Should be set to one of the following supported values:
- samsung,exynos5250-usbdrd-phy - for exynos5250 SoC,
- samsung,exynos5420-usbdrd-phy - for exynos5420 SoC.
+ - samsung,exynos5433-usbdrd-phy - for exynos5433 SoC.
- samsung,exynos7-usbdrd-phy - for exynos7 SoC.
- reg : Register offset and length of USB DRD PHY register set;
- clocks: Clock IDs array as required by the controller
@@ -139,7 +140,7 @@ Required properties:
PHY operations, associated by phy name. It is used to
determine bit values for clock settings register.
For Exynos5420 this is given as 'sclk_usbphy30' in CMU.
- - optional clocks: Exynos7 SoC has now following additional
+ - optional clocks: Exynos5433 Exynos7 SoC has now following additional
gate clocks available:
- phy_pipe: for PIPE3 phy
- phy_utmi: for UTMI+ phy
diff --git a/drivers/phy/phy-exynos5-usbdrd.c b/drivers/phy/phy-exynos5-usbdrd.c
index 0437401..597e7dd 100644
--- a/drivers/phy/phy-exynos5-usbdrd.c
+++ b/drivers/phy/phy-exynos5-usbdrd.c
@@ -624,6 +624,13 @@ static const struct exynos5_usbdrd_phy_drvdata
exynos5250_usbdrd_phy = {
.has_common_clk_gate= true,
};
+static const struct exynos5_usbdrd_phy_drvdata exynos5433_usbdrd_phy = {
+ .phy_cfg= phy_cfg_exynos5,
+ .pmu_offset_usbdrd0_phy = EXYNOS5_USBDRD_PHY_CONTROL,
+ .pmu_offset_usbdrd1_phy = EXYNOS5433_USBHOST30_PHY_CONTROL,
+ .has_common_clk_gate= false,
+};
+
static const struct exynos5_usbdrd_phy_drvdata exynos7_usbdrd_phy = {
.phy_cfg= phy_cfg_exynos5,
.pmu_offset_usbdrd0_phy = EXYNOS5_USBDRD_PHY_CONTROL,
@@ -638,6 +645,9 @@ static const struct of_device_id
exynos5_usbdrd_phy_of_match[] = {
.compatible = samsung,exynos5420-usbdrd-phy,
.data = exynos5420_usbdrd_phy
}, {
+ .compatible = samsung,exynos5433-usbdrd-phy,
+ .data = exynos5433_usbdrd_phy
+ }, {
.compatible = samsung,exynos7-usbdrd-phy,
.data = exynos7_usbdrd_phy
},
diff --git a/include/linux/mfd/syscon/exynos5-pmu.h
b/include/linux/mfd/syscon/exynos5-pmu.h
index 00ef24b..9352adc 100644
--- a/include/linux/mfd/syscon/exynos5-pmu.h
+++ b/include/linux/mfd/syscon/exynos5-pmu.h
@@ -36,6 +36,9 @@
#define EXYNOS5420_MTCADC_PHY_CONTROL (0x724)
#define EXYNOS5420_DPTX_PHY_CONTROL(0x728)
+/* Exynos5433 specific register definitions */
+#define EXYNOS5433_USBHOST30_PHY_CONTROL (0x728)
+
#define EXYNOS5_PHY_ENABLE BIT(0)
#define EXYNOS5_MIPI_PHY_S_RESETN BIT(1)
--
1.7.9.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: [GIT PULL] Exynos fixes for v4.0
Krzysztof Kozlowski wrote: Dear Kukjin, Hi, This groups important fixes for this v4.0-rc cycle. I hope you will find useful such grouping them in a pull request. Thanks for your gentle reminder :-) 1. Fix second suspend to RAM on Trats2 board. This has shown up after enabling L2 cache but actually the use delayed reset assertion is to be blamed. 2. Fix power domain issues with disp1 domain and HDMI (some of them) on Odroid XU3: - disp1 power domain can be turned off, - no more imprecise external abort faults. 3. Proper fix for build breakage of cpuidle on !SMP. This allows using Exynos cpuidle driver on UP. Best regards, Krzysztof The following changes since commit 2d2c9a8d0a4f90e298315d2f4a282d8bd5d45e5c: ARM: dts: add display power domain for exynos5250 (2015-02-27 05:29:32 +0900) are available in the git repository at: git://git.linaro.org/people/marek.szyprowski/linux-srpol.git v4.0-rc1-exynos-fixes for you to fetch changes up to c1b57bce36a69f3972a1db433d3c8b34e0541e63: ARM: EXYNOS: cpuidle: Fix build breakage on !SMP (2015-03-11 13:02:08 +0100) Andrzej Hajda (4): arm/exynos: add asynchronous bridge clock bindings arm/exynos/pm_domains: add support for async-bridge clocks ARM: dts: exynos5420: add async-bridge clocks to disp1 power domain ARM: dts: exynos5420: add async-bridge clocks to gsc power domain When I checked the patches, I expected that we could get the review from clock guys even we could do it though. And basically/usually the 'RFC' tagging means it's not a patch can be upstreamed and will be posted after gathering some comments so I didn't queue them in my tree. I'm still thinking like that... Bartlomiej Zolnierkiewicz (1): ARM: EXYNOS: cpuidle: Fix build breakage on !SMP Yeah, we need to fix it up asap and I'll finish it by this weekend. Sorry for the inconvenience. Krzysztof Kozlowski (1): ARM: EXYNOS: Fix failed second suspend on Exynos4 I'll have a look at this with above. Thanks, Kukjin .../bindings/arm/exynos/power_domain.txt | 3 ++ arch/arm/boot/dts/exynos5420.dtsi | 8 +++-- arch/arm/mach-exynos/common.h | 2 ++ arch/arm/mach-exynos/exynos.c | 29 +++- arch/arm/mach-exynos/platsmp.c | 39 ++ arch/arm/mach-exynos/pm.c | 2 ++ arch/arm/mach-exynos/pm_domains.c | 27 --- arch/arm/mach-exynos/suspend.c | 3 ++ drivers/cpuidle/cpuidle-exynos.c | 3 +- 9 files changed, 71 insertions(+), 45 deletions(-) -- 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 v5 1/9] arm64: dts: exynos: Add dts files for 64-bit Exynos5433 SoC
[...] Do CPUs enter the kernel at EL2 or at EL1? Could you give me a tip how to check the kernel at EL2 or EL1? Hmm... I thought we logged this but it looks like we don't. You could hack in a check of is_hyp_mode_available() and is_hyp_mode_mismatched(). That will tell you if EL2/hyp is available, and whether all CPUs enter at the same mode (mandatory per the boot protocol). OK, I'll try it. I check the return value of is_hyp_mode_available() to catch whether EL1 or EL2. The is_hyp_mode_available() returns 'false' during kernel booting. - __boot_cpu_mode[0]: 0xe11 (BOOT_CPU_MODE_EL1) - __boot_cpu_mode[1]: 0x0 Thanks for taking a look. It's unfortunate that CPUs aren't booted at EL2 (especially given that booting them at EL1N means the FW is doing more work to be less helpful to the OS), but at least they seem to be booted in consistent modes. Thanks, Mark. -- 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: [GIT PULL 2/2] Samsung fixes-2 for v4.0
Eduardo Valentin wrote: Hi Eduardo, On Fri, Mar 06, 2015 at 07:16:53PM +0900, Kukjin Kim wrote: Arnd Bergmann wrote: + Eduardo Hi Arnd, On Tuesday 03 March 2015 04:00:14 Kukjin Kim wrote: Please pull Samsung tmu and hdmi regression fixes for v4.0 and I know this is quite big for fixes but I couldn't handle this series for previous merge window because of dependency with driver side...sorry for that and please pull so that we could support them in v4.0 on exynos platforms. What kind of dependency do you have there? It really should not be necessary to wait for driver changes, unless you do an incompatible DT binding change, which you should avoid. For TMU patches, I've asked Eduardo to provide topic branch for 'include/dt-bindings/thermal/thermal_exynos.h' has been added via thermal tree because if I can't apply the patch in Samsung tree for arm-soc, kernel build breakage will be happened. But I couldn't get Eduardo's topic branch. Specifically, the developer, while migrating the driver to support DT and OF thermal, decided to create a header with constants. The header is used by DT files and the driver code. The header was the dependency. Yes, sometimes we can't avoid the situation so it can be a kind of dependency... Arnd, Do you have any updates on this? Thanks, Kukjin BR, Eduardo Valentin http://www.spinics.net/lists/linux-samsung-soc/msg41877.html For HDMI patches, I thought the DT changes have a dependency with drm/exynos: add support for 'hdmi' clock so waited for its applying then in drm tree. But I couldn't send it to arm-soc after that... http://www.spinics.net/lists/linux-samsung-soc/msg42173.html I asked about the situation (late DT changes?) when I sent a pull-request, then I couldn't get a access my kernel.org because of biz. trip to China :( http://www.spinics.net/lists/linux-samsung-soc/msg42235.html I've pulled it into fixes, but won't forward it until I hear a good explanation. As you know, basically I tried to make a clear branch for pull-request but in that case, I couldn't find a solution. Sorry for the inconvenience. I hope v4.0 can support them properly. Thanks, Kukjin -- 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] ARM: exynos_defconfig: Enable CPU idle
Krzysztof Kozlowski wrote: Current Exynos CPU idle driver supports entering AFTR (Arm Off, Top Running) mode on Exynos 4210 (coupled), Exynos 4x12 and Exynos 5250. Enable it in default configuration to reduce energy consumption. Signed-off-by: Krzysztof Kozlowski k.kozlow...@samsung.com --- arch/arm/configs/exynos_defconfig | 2 ++ 1 file changed, 2 insertions(+) diff --git a/arch/arm/configs/exynos_defconfig b/arch/arm/configs/exynos_defconfig index 70e5d0bdb4e4..7e0622a36da9 100644 --- a/arch/arm/configs/exynos_defconfig +++ b/arch/arm/configs/exynos_defconfig @@ -26,6 +26,8 @@ CONFIG_ZBOOT_ROM_BSS=0x0 CONFIG_ARM_APPENDED_DTB=y CONFIG_ARM_ATAG_DTB_COMPAT=y CONFIG_CMDLINE=root=/dev/ram0 rw ramdisk=8192 initrd=0x4100,8M console=ttySAC1,115200 init=/linuxrc mem=256M +CONFIG_CPU_IDLE=y +CONFIG_ARM_EXYNOS_CPUIDLE=y CONFIG_VFP=y CONFIG_NEON=y CONFIG_PM=y -- OK, will apply. Thanks, Kukjin -- 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
[PATCH v2 RESEND 3/4] ARM: dts: exynos5420: add async-bridge clocks to disp1 power domain
FIMD and MIXER IPs in disp1 power domain have async-bridges (to GSCALER),
therefore their clocks should be enabled during power domain switch.
Signed-off-by: Andrzej Hajda a.ha...@samsung.com
Reviewed-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
Tested-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
Reviewed-by: Sylwester Nawrocki s.nawro...@samsung.com
---
arch/arm/boot/dts/exynos5420.dtsi | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/exynos5420.dtsi
b/arch/arm/boot/dts/exynos5420.dtsi
index c0e98cf..55e3887 100644
--- a/arch/arm/boot/dts/exynos5420.dtsi
+++ b/arch/arm/boot/dts/exynos5420.dtsi
@@ -283,9 +283,11 @@
clock CLK_MOUT_SW_ACLK300,
clock CLK_MOUT_USER_ACLK300_DISP1,
clock CLK_MOUT_SW_ACLK400,
-clock CLK_MOUT_USER_ACLK400_DISP1;
+clock CLK_MOUT_USER_ACLK400_DISP1,
+clock CLK_FIMD1, clock CLK_MIXER;
clock-names = oscclk, pclk0, clk0,
- pclk1, clk1, pclk2, clk2;
+ pclk1, clk1, pclk2, clk2,
+ asb0, asb1;
};
pinctrl_0: pinctrl@1340 {
--
1.9.1
--
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
[PATCH v2 RESEND 4/4] ARM: dts: exynos5420: add async-bridge clocks to gsc power domain
Both GSCALER IPs in gsc power domain have async-bridges (to FIMD and MIXER),
therefore their clocks should be enabled during power domain switch.
Signed-off-by: Andrzej Hajda a.ha...@samsung.com
Reviewed-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
Tested-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
---
arch/arm/boot/dts/exynos5420.dtsi | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm/boot/dts/exynos5420.dtsi
b/arch/arm/boot/dts/exynos5420.dtsi
index 55e3887..4eaeabe 100644
--- a/arch/arm/boot/dts/exynos5420.dtsi
+++ b/arch/arm/boot/dts/exynos5420.dtsi
@@ -251,6 +251,8 @@
compatible = samsung,exynos4210-pd;
reg = 0x10044000 0x20;
#power-domain-cells = 0;
+ clocks = clock CLK_GSCL0, clock CLK_GSCL1;
+ clock-names = asb0, asb1;
};
isp_pd: power-domain@10044020 {
--
1.9.1
--
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
[PATCH v2 RESEND 1/4] arm/exynos: add asynchronous bridge clock bindings
The patch adds bindings for clocks required by async-bridges present in the particular power domain. Signed-off-by: Andrzej Hajda a.ha...@samsung.com Reviewed-by: Javier Martinez Canillas javier.marti...@collabora.co.uk Tested-by: Javier Martinez Canillas javier.marti...@collabora.co.uk --- Documentation/devicetree/bindings/arm/exynos/power_domain.txt | 3 +++ 1 file changed, 3 insertions(+) diff --git a/Documentation/devicetree/bindings/arm/exynos/power_domain.txt b/Documentation/devicetree/bindings/arm/exynos/power_domain.txt index 1e09703..5da38c5 100644 --- a/Documentation/devicetree/bindings/arm/exynos/power_domain.txt +++ b/Documentation/devicetree/bindings/arm/exynos/power_domain.txt @@ -22,6 +22,9 @@ Optional Properties: - pclkN, clkN: Pairs of parent of input clock and input clock to the devices in this power domain. Maximum of 4 pairs (N = 0 to 3) are supported currently. + - asbN: Clocks required by asynchronous bridges (ASB) present in + the power domain. These clock should be enabled during power + domain on/off operations. - power-domains: phandle pointing to the parent power domain, for more details see Documentation/devicetree/bindings/power/power_domain.txt -- 1.9.1 -- 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 0/7] drm/exynos: clean ups
On 2015년 02월 19일 22:22, Gustavo Padovan wrote: From: Gustavo Padovan gustavo.pado...@collabora.co.uk Hi, Here goes some clean ups to the exynos drivers. The main clean ups is the presetting and zpos making the property immutable and the removal of *_win_data structures. With your cleanup patch set, the plane test doesn't work. Have you ever tested plane feature with modetest application? I typed like below and it looks like no problem but I cannot see anything on Panel except for cute four penguins. # modetest -P 29:100x100+0+0 trying to open device 'i915'...failed. trying to open device 'radeon'...failed. trying to open device 'nouveau'...failed. trying to open device 'vmwgfx'...failed. trying to open device 'omapdrm'...failed. trying to open device 'exynos'...success. testing 100x100@XR24 overlay plane 25 And for two plane test, # modetest -P 29:100x100+0+0 -P 29:100x100+0+100 trying to open device 'i915'...failed. trying to open device 'radeon'...failed. trying to open device 'nouveau'...failed. trying to open device 'vmwgfx'...failed. trying to open device 'omapdrm'...failed. trying to open device 'exynos'...success. testing 100x100@XR24 overlay plane 25 testing 100x100@XR24 overlay plane 26 Still no screen. Thanks, Inki Dae Gustavo Padovan (6): drm/exynos: remove unused exynos_crtc-win_enable() callback drm/exynos: remove struct *_win_data abstraction on planes drm/exynos: preset zpos value for overlay planes drm/exynos: make zpos property immutable drm/exynos: remove exynos_plane_destroy() drm/exynos: remove leftover functions declarations Mandeep Singh Baines (1): drm/exynos: track vblank events on a per crtc basis drivers/gpu/drm/exynos/exynos7_drm_decon.c | 176 +-- drivers/gpu/drm/exynos/exynos_drm_crtc.c | 101 ++ drivers/gpu/drm/exynos/exynos_drm_crtc.h | 7 +- drivers/gpu/drm/exynos/exynos_drm_drv.c| 27 drivers/gpu/drm/exynos/exynos_drm_drv.h| 20 +-- drivers/gpu/drm/exynos/exynos_drm_fimd.c | 195 ++ drivers/gpu/drm/exynos/exynos_drm_plane.c | 66 +++-- drivers/gpu/drm/exynos/exynos_drm_plane.h | 7 +- drivers/gpu/drm/exynos/exynos_drm_vidi.c | 134 +- drivers/gpu/drm/exynos/exynos_mixer.c | 217 ++--- 10 files changed, 311 insertions(+), 639 deletions(-) -- 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
[PATCH v2 RESEND 2/4] arm/exynos/pm_domains: add support for async-bridge clocks
Since Exynos5420 there are async-bridges (ASB) between different IPs. These
bridges must be operational during power domain on/off, ie. clocks used
by these bridges should be enabled.
This patch enabled these clocks during domain on/off.
Signed-off-by: Andrzej Hajda a.ha...@samsung.com
Reviewed-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
Tested-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
Reviewed-by: Sylwester Nawrocki s.nawro...@samsung.com
---
arch/arm/mach-exynos/pm_domains.c | 27 +++
1 file changed, 23 insertions(+), 4 deletions(-)
diff --git a/arch/arm/mach-exynos/pm_domains.c
b/arch/arm/mach-exynos/pm_domains.c
index 37266a8..507dad0 100644
--- a/arch/arm/mach-exynos/pm_domains.c
+++ b/arch/arm/mach-exynos/pm_domains.c
@@ -37,6 +37,7 @@ struct exynos_pm_domain {
struct clk *oscclk;
struct clk *clk[MAX_CLK_PER_DOMAIN];
struct clk *pclk[MAX_CLK_PER_DOMAIN];
+ struct clk *asb_clk[MAX_CLK_PER_DOMAIN];
};
static int exynos_pd_power(struct generic_pm_domain *domain, bool power_on)
@@ -45,14 +46,19 @@ static int exynos_pd_power(struct generic_pm_domain
*domain, bool power_on)
void __iomem *base;
u32 timeout, pwr;
char *op;
+ int i;
pd = container_of(domain, struct exynos_pm_domain, pd);
base = pd-base;
+ for (i = 0; i MAX_CLK_PER_DOMAIN; i++) {
+ if (IS_ERR(pd-asb_clk[i]))
+ break;
+ clk_prepare_enable(pd-asb_clk[i]);
+ }
+
/* Set oscclk before powering off a domain*/
if (!power_on) {
- int i;
-
for (i = 0; i MAX_CLK_PER_DOMAIN; i++) {
if (IS_ERR(pd-clk[i]))
break;
@@ -81,8 +87,6 @@ static int exynos_pd_power(struct generic_pm_domain *domain,
bool power_on)
/* Restore clocks after powering on a domain*/
if (power_on) {
- int i;
-
for (i = 0; i MAX_CLK_PER_DOMAIN; i++) {
if (IS_ERR(pd-clk[i]))
break;
@@ -92,6 +96,12 @@ static int exynos_pd_power(struct generic_pm_domain *domain,
bool power_on)
}
}
+ for (i = 0; i MAX_CLK_PER_DOMAIN; i++) {
+ if (IS_ERR(pd-asb_clk[i]))
+ break;
+ clk_disable_unprepare(pd-asb_clk[i]);
+ }
+
return 0;
}
@@ -131,6 +141,15 @@ static __init int exynos4_pm_init_power_domain(void)
pd-pd.power_off = exynos_pd_power_off;
pd-pd.power_on = exynos_pd_power_on;
+ for (i = 0; i MAX_CLK_PER_DOMAIN; i++) {
+ char clk_name[8];
+
+ snprintf(clk_name, sizeof(clk_name), asb%d, i);
+ pd-asb_clk[i] = clk_get(dev, clk_name);
+ if (IS_ERR(pd-asb_clk[i]))
+ break;
+ }
+
pd-oscclk = clk_get(dev, oscclk);
if (IS_ERR(pd-oscclk))
goto no_clk;
--
1.9.1
--
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
[PATCH v2 RESEND 0/4] Fix power domains handling on exynos542x
Hi Kukjin, This is resend of my patchset with added (Reviewed|Tested)-by tags and removed RFC prefix. Exynos chipsets since 542x have asynchronous bridges connecting different IPs. These bridges should be operational during power domain switching, ie associated clocks cannot be gated. This patchset adds binding to provide such clocks per power domain and adds code which enables them during domain on/off operation. This patchset fixes power domain issues with disp1 domain and HDMI (some of them) on Odroid XU3: - disp1 power domain can be turned off, - no more imprecise external abort faults. The patchset is based on samsung-fixes-dt tag from kgene/linux-samsung. It was successfully tested on OdroidXU3. Regards Andrzej Andrzej Hajda (4): arm/exynos: add asynchronous bridge clock bindings arm/exynos/pm_domains: add support for async-bridge clocks ARM: dts: exynos5420: add async-bridge clocks to disp1 power domain ARM: dts: exynos5420: add async-bridge clocks to gsc power domain .../bindings/arm/exynos/power_domain.txt | 3 +++ arch/arm/boot/dts/exynos5420.dtsi | 8 +-- arch/arm/mach-exynos/pm_domains.c | 27 ++ 3 files changed, 32 insertions(+), 6 deletions(-) -- 1.9.1 -- 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 0/7] drm/exynos: clean ups
On 2015년 03월 13일 03:45, Gustavo Padovan wrote: 2015-03-12 Inki Dae inki@samsung.com: On 2015년 02월 19일 22:22, Gustavo Padovan wrote: From: Gustavo Padovan gustavo.pado...@collabora.co.uk Hi, Here goes some clean ups to the exynos drivers. The main clean ups is the presetting and zpos making the property immutable and the removal of *_win_data structures. With your cleanup patch set, the plane test doesn't work. Have you ever tested plane feature with modetest application? I typed like below and it looks like no problem but I cannot see anything on Panel except for cute four penguins. # modetest -P 29:100x100+0+0 trying to open device 'i915'...failed. trying to open device 'radeon'...failed. trying to open device 'nouveau'...failed. trying to open device 'vmwgfx'...failed. trying to open device 'omapdrm'...failed. trying to open device 'exynos'...success. testing 100x100@XR24 overlay plane 25 And for two plane test, # modetest -P 29:100x100+0+0 -P 29:100x100+0+100 trying to open device 'i915'...failed. trying to open device 'radeon'...failed. trying to open device 'nouveau'...failed. trying to open device 'vmwgfx'...failed. trying to open device 'omapdrm'...failed. trying to open device 'exynos'...success. testing 100x100@XR24 overlay plane 25 testing 100x100@XR24 overlay plane 26 Still no screen. Well, I did some more testing and even without my patches I can't see a plane on the screen. Running only on exynos-drm-next also doesn't work so it is not something that my patches introduced, it is already a bug upstream. I'm using a snow for testing. It's strange. I can see a semicircular small box on the screen without your patch set, and that works well on not only exynos-drm-next but also exynos-drm-fixes. I'm using a trarts2 board based on Exynos4412 SoC. Could anyone check the plane test with modetest for double-check? Thanks, Inki Dae 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 -- 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
[PATCH 1/8] mfd: cros ec: Remove parent field
From: Gwendal Grignou gwen...@chromium.org
parent and dev were pointing to the same device structure.
parent is unused, removed.
Signed-off-by: Gwendal Grignou gwen...@chromium.org
Reviewed-by: Stephen Barber smbar...@chromium.org
Tested-by: Stephen Barber smbar...@chromium.org
Reviewed-by: Puthikorn Voravootivat put...@chromium.org
Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
---
drivers/mfd/cros_ec_i2c.c | 1 -
drivers/mfd/cros_ec_spi.c | 1 -
drivers/platform/chrome/cros_ec_lpc.c | 1 -
include/linux/mfd/cros_ec.h | 2 --
4 files changed, 5 deletions(-)
diff --git a/drivers/mfd/cros_ec_i2c.c b/drivers/mfd/cros_ec_i2c.c
index c0c30f4f946f..82b4d6148698 100644
--- a/drivers/mfd/cros_ec_i2c.c
+++ b/drivers/mfd/cros_ec_i2c.c
@@ -145,7 +145,6 @@ static int cros_ec_i2c_probe(struct i2c_client *client,
ec_dev-cmd_xfer = cros_ec_cmd_xfer_i2c;
ec_dev-ec_name = client-name;
ec_dev-phys_name = client-adapter-name;
- ec_dev-parent = client-dev;
err = cros_ec_register(ec_dev);
if (err) {
diff --git a/drivers/mfd/cros_ec_spi.c b/drivers/mfd/cros_ec_spi.c
index bf6e08e8013e..27bd52e5e8b7 100644
--- a/drivers/mfd/cros_ec_spi.c
+++ b/drivers/mfd/cros_ec_spi.c
@@ -363,7 +363,6 @@ static int cros_ec_spi_probe(struct spi_device *spi)
ec_dev-cmd_xfer = cros_ec_cmd_xfer_spi;
ec_dev-ec_name = ec_spi-spi-modalias;
ec_dev-phys_name = dev_name(ec_spi-spi-dev);
- ec_dev-parent = ec_spi-spi-dev;
ec_dev-din_size = EC_MSG_BYTES + EC_MSG_PREAMBLE_COUNT;
ec_dev-dout_size = EC_MSG_BYTES;
diff --git a/drivers/platform/chrome/cros_ec_lpc.c
b/drivers/platform/chrome/cros_ec_lpc.c
index 8f9ac4d7bbd0..860310513cf0 100644
--- a/drivers/platform/chrome/cros_ec_lpc.c
+++ b/drivers/platform/chrome/cros_ec_lpc.c
@@ -214,7 +214,6 @@ static int cros_ec_lpc_probe(struct platform_device *pdev)
ec_dev-dev = dev;
ec_dev-ec_name = pdev-name;
ec_dev-phys_name = dev_name(dev);
- ec_dev-parent = dev;
ec_dev-cmd_xfer = cros_ec_cmd_xfer_lpc;
ec_dev-cmd_readmem = cros_ec_lpc_readmem;
diff --git a/include/linux/mfd/cros_ec.h b/include/linux/mfd/cros_ec.h
index 324a34683971..14cf522123dd 100644
--- a/include/linux/mfd/cros_ec.h
+++ b/include/linux/mfd/cros_ec.h
@@ -85,7 +85,6 @@ struct cros_ec_command {
* to using dword.
* @din_size: size of din buffer to allocate (zero to use static din)
* @dout_size: size of dout buffer to allocate (zero to use static dout)
- * @parent: pointer to parent device (e.g. i2c or spi device)
* @wake_enabled: true if this device can wake the system from sleep
* @cmd_xfer: send command to EC and get response
* Returns the number of bytes received if the communication succeeded, but
@@ -113,7 +112,6 @@ struct cros_ec_device {
uint8_t *dout;
int din_size;
int dout_size;
- struct device *parent;
bool wake_enabled;
int (*cmd_xfer)(struct cros_ec_device *ec,
struct cros_ec_command *msg);
--
2.1.4
--
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
[PATCH 0/8] cros_ec: Add multiple EC and protocol v3 support
Hello, Newer Chromebooks have more than one Embedded Controller (EC) in the system. These additional ECs are connected through I2C with a host EC which is the one that is connected to the Application Processor (AP) through I2C, SPI or LPC. So, on these platforms sub-processors are chained to each other, i.e: AP -- Host EC -- Power Delivery (PD) EC The AP sends commands to the additional EC through the host EC using a set of passthru commands and the host redirects to the correct EC. This series adds support for multiple EC in a system and also for the protocol version 3 that is used on newer ECs. The patches were tested on an Exynos5250 Snow, Exynos5420 Peach Pit, Exynos5800 Peach Pi and x86 Pixel Chromebook with no regressions found. Most patches were taken from the downstream ChromiumOS v3.14 tree with fixes squashed, split to minimise the cross subsystem churn and changes for mainline inclusion but were not modified functionality wise. I don't have access neither to a Chromebook with more than one EC nor one that supports the protocol version 3 though, so testing on those systems will be highly appreciated. The series depend on platform/chrome: Add user-space dev inferface support [0] that is already merged in the chrome-platform tree so probably these patches should also go through that tree once the mfd patches are acked. The series is composed of the following patches: Gwendal Grignou (2): mfd: cros ec: Remove parent field mfd: cros-ec: Support multiple EC in a system Javier Martinez Canillas (2): mfd: cros_ec: Sanity check in and out sizes platform/chrome: cros_ec_lpc - Use existing function to check EC result Stephen Barber (3): mfd: cros_ec: rev cros_ec_commands.h mfd: cros_ec: add proto v3 skeleton mfd: cros_ec: add bus-specific proto v3 code Todd Broch (1): mfd: cros_ec: Instantiate sub-devices from device tree drivers/mfd/cros_ec.c | 359 ++ drivers/mfd/cros_ec_i2c.c | 165 +++- drivers/mfd/cros_ec_spi.c | 401 + drivers/platform/chrome/cros_ec_dev.c | 4 +- drivers/platform/chrome/cros_ec_lightbar.c | 14 +- drivers/platform/chrome/cros_ec_lpc.c | 90 ++- include/linux/mfd/cros_ec.h| 30 ++- include/linux/mfd/cros_ec_commands.h | 277 ++-- 8 files changed, 1183 insertions(+), 157 deletions(-) Patches #1, #2 and #3 are just small fixes or cleanups. Patch #4 allows the driver to instantiate sub-devices defined in DT instead of using a fixed list of mfd cells. Patch #5 adds support to make multiple EC have a different device id and also exposing a per EC character device interface. Patch #6 synchronises the cros_ec_commands.h with a newer version of the file in the EC firmware repository. Patch #7 adds the EC host command protocol v3 support to the cros_ec driver and patch #8 adds the bus specific proto v3 support for I2C, SPI and LPC. Best regards, Javier [0]: https://lkml.org/lkml/2015/2/2/214 -- 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 06/10] iio: exynos-adc: add experimental touchscreen support
On Wednesday 04 March 2015 15:10:00 Dmitry Torokhov wrote:
+static int exynos_adc_ts_init(struct exynos_adc *info)
+{
+ int ret;
+
+ if (info-tsirq = 0)
+ return -ENODEV;
+
+ info-input = input_allocate_device();
+ if (!info-input)
+ return -ENOMEM;
+
+ info-input-evbit[0] = BIT_MASK(EV_KEY) | BIT_MASK(EV_ABS);
+ info-input-keybit[BIT_WORD(BTN_TOUCH)] = BIT_MASK(BTN_TOUCH);
+
+ input_set_abs_params(info-input, ABS_X, 0, 0x3FF, 0, 0);
+ input_set_abs_params(info-input, ABS_Y, 0, 0x3FF, 0, 0);
+
+ info-input-name = S3C24xx TouchScreen;
+ info-input-id.bustype = BUS_HOST;
+ info-input-open = exynos_adc_ts_open;
+ info-input-close = exynos_adc_ts_close;
+
+ input_set_drvdata(info-input, info);
+
+ ret = input_register_device(info-input);
+ if (ret)
+ input_free_device(info-input);
If you fail to register input device are you sure you want to continue
and register interrupt?
+
+ disable_irq(info-tsirq);
+ ret = request_threaded_irq(info-tsirq, NULL, exynos_ts_isr,
+0, touchscreen, info);
+ if (ret)
+ input_unregister_device(info-input);
+
+ return ret;
+}
Sorry for the delayed reply, I've now folded in this patch:
diff --git a/drivers/iio/adc/exynos_adc.c b/drivers/iio/adc/exynos_adc.c
index 75cd381a8181..d11cd604562c 100644
--- a/drivers/iio/adc/exynos_adc.c
+++ b/drivers/iio/adc/exynos_adc.c
@@ -732,8 +732,10 @@ static int exynos_adc_ts_init(struct exynos_adc *info)
input_set_drvdata(info-input, info);
ret = input_register_device(info-input);
- if (ret)
+ if (ret) {
input_free_device(info-input);
+ return ret;
+ }
disable_irq(info-tsirq);
ret = request_threaded_irq(info-tsirq, NULL, exynos_ts_isr,
Arnd
--
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
[PATCH 2/8] mfd: cros_ec: Sanity check in and out sizes
The cros_ec_cmd_xfer() function is used to communicate with the EC
and callers set the sizes of data in the input and output buffers.
But these sizes need to be checked to ensure that don't exceed the
fixed maximum length of the input and output buffers.
Reported-by : Dan Carpenter dan.carpen...@oracle.com
Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
---
drivers/mfd/cros_ec.c | 14 ++
1 file changed, 14 insertions(+)
diff --git a/drivers/mfd/cros_ec.c b/drivers/mfd/cros_ec.c
index c4aecc6f8373..07c53c27c82a 100644
--- a/drivers/mfd/cros_ec.c
+++ b/drivers/mfd/cros_ec.c
@@ -70,6 +70,20 @@ int cros_ec_cmd_xfer(struct cros_ec_device *ec_dev,
{
int ret;
+ if (msg-insize ARRAY_SIZE(msg-indata)) {
+ dev_err(ec_dev-dev,
+ response of size %u is too big (max: %u)\n,
+ msg-insize, ARRAY_SIZE(msg-indata));
+ return -EMSGSIZE;
+ }
+
+ if (msg-outsize ARRAY_SIZE(msg-outdata)) {
+ dev_err(ec_dev-dev,
+ request of size %u is too big (max: %u)\n,
+ msg-outsize, ARRAY_SIZE(msg-outdata));
+ return -EMSGSIZE;
+ }
+
mutex_lock(ec_dev-lock);
ret = ec_dev-cmd_xfer(ec_dev, msg);
if (msg-result == EC_RES_IN_PROGRESS) {
--
2.1.4
--
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
[PATCH 6/8] mfd: cros_ec: rev cros_ec_commands.h
From: Stephen Barber smbar...@chromium.org
Update cros_ec_commands.h to the latest version in the EC
firmware sources and add power domain and passthru commands.
Also, update lightbar to use new command names.
Signed-off-by: Stephen Barber smbar...@chromium.org
Reviewed-by: Randall Spangler rspang...@chromium.org
Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
---
drivers/platform/chrome/cros_ec_lightbar.c | 14 +-
include/linux/mfd/cros_ec_commands.h | 277 ++---
2 files changed, 262 insertions(+), 29 deletions(-)
diff --git a/drivers/platform/chrome/cros_ec_lightbar.c
b/drivers/platform/chrome/cros_ec_lightbar.c
index b4ff47a9069a..e499c01c3353 100644
--- a/drivers/platform/chrome/cros_ec_lightbar.c
+++ b/drivers/platform/chrome/cros_ec_lightbar.c
@@ -168,8 +168,8 @@ static ssize_t brightness_store(struct device *dev,
return -EINVAL;
param = (struct ec_params_lightbar *)msg.outdata;
- param-cmd = LIGHTBAR_CMD_BRIGHTNESS;
- param-brightness.num = val;
+ param-cmd = LIGHTBAR_CMD_SET_BRIGHTNESS;
+ param-set_brightness.num = val;
ret = lb_throttle();
if (ret)
return ret;
@@ -216,11 +216,11 @@ static ssize_t led_rgb_store(struct device *dev, struct
device_attribute *attr,
if (i == 4) {
param = (struct ec_params_lightbar *)msg.outdata;
- param-cmd = LIGHTBAR_CMD_RGB;
- param-rgb.led = val[0];
- param-rgb.red = val[1];
- param-rgb.green = val[2];
- param-rgb.blue = val[3];
+ param-cmd = LIGHTBAR_CMD_SET_RGB;
+ param-set_rgb.led = val[0];
+ param-set_rgb.red = val[1];
+ param-set_rgb.green = val[2];
+ param-set_rgb.blue = val[3];
/*
* Throttle only the first of every four transactions,
* so that the user can update all four LEDs at once.
diff --git a/include/linux/mfd/cros_ec_commands.h
b/include/linux/mfd/cros_ec_commands.h
index a49cd41feea7..13b630c10d4c 100644
--- a/include/linux/mfd/cros_ec_commands.h
+++ b/include/linux/mfd/cros_ec_commands.h
@@ -515,7 +515,7 @@ struct ec_host_response {
/*
* Notes on commands:
*
- * Each command is an 8-byte command value. Commands which take params or
+ * Each command is an 16-bit command value. Commands which take params or
* return response data specify structs for that data. If no struct is
* specified, the command does not input or output data, respectively.
* Parameter/response length is implicit in the structs. Some underlying
@@ -966,7 +966,7 @@ struct rgb_s {
/* List of tweakable parameters. NOTE: It's __packed so it can be sent in a
* host command, but the alignment is the same regardless. Keep it that way.
*/
-struct lightbar_params {
+struct lightbar_params_v0 {
/* Timing */
int32_t google_ramp_up;
int32_t google_ramp_down;
@@ -1000,32 +1000,81 @@ struct lightbar_params {
struct rgb_s color[8]; /* 0-3 are Google colors */
} __packed;
+struct lightbar_params_v1 {
+ /* Timing */
+ int32_t google_ramp_up;
+ int32_t google_ramp_down;
+ int32_t s3s0_ramp_up;
+ int32_t s0_tick_delay[2]; /* AC=0/1 */
+ int32_t s0a_tick_delay[2]; /* AC=0/1 */
+ int32_t s0s3_ramp_down;
+ int32_t s3_sleep_for;
+ int32_t s3_ramp_up;
+ int32_t s3_ramp_down;
+ int32_t tap_tick_delay;
+ int32_t tap_display_time;
+
+ /* Tap-for-battery params */
+ uint8_t tap_pct_red;
+ uint8_t tap_pct_green;
+ uint8_t tap_seg_min_on;
+ uint8_t tap_seg_max_on;
+ uint8_t tap_seg_osc;
+ uint8_t tap_idx[3];
+
+ /* Oscillation */
+ uint8_t osc_min[2]; /* AC=0/1 */
+ uint8_t osc_max[2]; /* AC=0/1 */
+ uint8_t w_ofs[2]; /* AC=0/1 */
+
+ /* Brightness limits based on the backlight and AC. */
+ uint8_t bright_bl_off_fixed[2]; /* AC=0/1 */
+ uint8_t bright_bl_on_min[2];/* AC=0/1 */
+ uint8_t bright_bl_on_max[2];/* AC=0/1 */
+
+ /* Battery level thresholds */
+ uint8_t battery_threshold[LB_BATTERY_LEVELS - 1];
+
+ /* Map [AC][battery_level] to color index */
+ uint8_t s0_idx[2][LB_BATTERY_LEVELS]; /* AP is running */
+ uint8_t s3_idx[2][LB_BATTERY_LEVELS]; /* AP is sleeping */
+
+ /* Color palette */
+ struct rgb_s color[8]; /* 0-3 are Google colors */
+} __packed;
+
struct ec_params_lightbar {
uint8_t cmd; /* Command (see enum lightbar_command) */
union {
struct {
[PATCH 5/8] mfd: cros-ec: Support multiple EC in a system
From: Gwendal Grignou gwen...@chromium.org
Chromebooks can have more than one Embedded Controller so the
cros_ec device id has to be incremented for each EC registered.
Add code to handle multiple EC. First ec found is cros-ec0,
second cros-ec1 and so on.
Signed-off-by: Gwendal Grignou gwen...@chromium.org
Reviewed-by: Dmitry Torokhov d...@chromium.org
Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
---
drivers/mfd/cros_ec.c | 7 ++-
drivers/platform/chrome/cros_ec_dev.c | 4 ++--
include/linux/mfd/cros_ec.h | 2 ++
3 files changed, 10 insertions(+), 3 deletions(-)
diff --git a/drivers/mfd/cros_ec.c b/drivers/mfd/cros_ec.c
index 9da95cc0a1ee..ffaf17823115 100644
--- a/drivers/mfd/cros_ec.c
+++ b/drivers/mfd/cros_ec.c
@@ -28,6 +28,8 @@
#define EC_COMMAND_RETRIES 50
+static int dev_id;
+
int cros_ec_prepare_tx(struct cros_ec_device *ec_dev,
struct cros_ec_command *msg)
{
@@ -134,6 +136,8 @@ int cros_ec_register(struct cros_ec_device *ec_dev)
struct device *dev = ec_dev-dev;
int err = 0;
+ ec_dev-id = dev_id;
+
if (ec_dev-din_size) {
ec_dev-din = devm_kzalloc(dev, ec_dev-din_size, GFP_KERNEL);
if (!ec_dev-din)
@@ -147,7 +151,7 @@ int cros_ec_register(struct cros_ec_device *ec_dev)
mutex_init(ec_dev-lock);
- err = mfd_add_devices(dev, 0, cros_devs,
+ err = mfd_add_devices(dev, ec_dev-id, cros_devs,
ARRAY_SIZE(cros_devs),
NULL, ec_dev-irq, NULL);
if (err) {
@@ -163,6 +167,7 @@ int cros_ec_register(struct cros_ec_device *ec_dev)
return err;
}
#endif
+ dev_id += ARRAY_SIZE(cros_devs);
dev_info(dev, Chrome EC device registered\n);
diff --git a/drivers/platform/chrome/cros_ec_dev.c
b/drivers/platform/chrome/cros_ec_dev.c
index 6090d0b2826f..3f5983601dd9 100644
--- a/drivers/platform/chrome/cros_ec_dev.c
+++ b/drivers/platform/chrome/cros_ec_dev.c
@@ -178,7 +178,7 @@ static int ec_device_probe(struct platform_device *pdev)
{
struct cros_ec_device *ec = dev_get_drvdata(pdev-dev.parent);
int retval = -ENOTTY;
- dev_t devno = MKDEV(ec_major, 0);
+ dev_t devno = MKDEV(ec_major, ec-id);
/* Instantiate it (and remember the EC) */
cdev_init(ec-cdev, fops);
@@ -190,7 +190,7 @@ static int ec_device_probe(struct platform_device *pdev)
}
ec-vdev = device_create(cros_class, NULL, devno, ec,
-CROS_EC_DEV_NAME);
+CROS_EC_DEV_NAME %d, ec-id);
if (IS_ERR(ec-vdev)) {
retval = PTR_ERR(ec-vdev);
dev_err(pdev-dev, : failed to create device\n);
diff --git a/include/linux/mfd/cros_ec.h b/include/linux/mfd/cros_ec.h
index 14cf522123dd..8828e8ec347b 100644
--- a/include/linux/mfd/cros_ec.h
+++ b/include/linux/mfd/cros_ec.h
@@ -74,6 +74,7 @@ struct cros_ec_command {
*
* @priv: Private data
* @irq: Interrupt to use
+ * @id: Device id
* @din: input buffer (for data from EC)
* @dout: output buffer (for data to EC)
* \note
@@ -108,6 +109,7 @@ struct cros_ec_device {
/* These are used to implement the platform-specific interface */
void *priv;
int irq;
+ int id;
uint8_t *din;
uint8_t *dout;
int din_size;
--
2.1.4
--
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
[PATCH 8/8] mfd: cros_ec: add bus-specific proto v3 code
From: Stephen Barber smbar...@chromium.org
Add proto v3 support to the SPI, I2C, and LPC.
Signed-off-by: Stephen Barber smbar...@chromium.org
Reviewed-by: Puthikorn Voravootivat put...@chromium.org
Reviewed-by: Gwendal Grignou gwen...@chromium.org
Tested-by: Puthikorn Voravootivat put...@chromium.org
Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
---
drivers/mfd/cros_ec_i2c.c | 166 +-
drivers/mfd/cros_ec_spi.c | 395 +-
drivers/platform/chrome/cros_ec_lpc.c | 73 ++-
include/linux/mfd/cros_ec.h | 6 +
4 files changed, 580 insertions(+), 60 deletions(-)
diff --git a/drivers/mfd/cros_ec_i2c.c b/drivers/mfd/cros_ec_i2c.c
index 7decf8cdcb29..ef85a291405e 100644
--- a/drivers/mfd/cros_ec_i2c.c
+++ b/drivers/mfd/cros_ec_i2c.c
@@ -13,6 +13,7 @@
* GNU General Public License for more details.
*/
+#include linux/delay.h
#include linux/kernel.h
#include linux/module.h
#include linux/i2c.h
@@ -22,6 +23,32 @@
#include linux/platform_device.h
#include linux/slab.h
+/**
+ * Request format for protocol v3
+ * byte 0 0xda (EC_COMMAND_PROTOCOL_3)
+ * byte 1-8struct ec_host_request
+ * byte 10-response data
+ */
+struct ec_host_request_i2c {
+ /* Always 0xda to backward compatible with v2 struct */
+ uint8_t command_protocol;
+ struct ec_host_request ec_request;
+} __packed;
+
+
+/*
+ * Response format for protocol v3
+ * byte 0 result code
+ * byte 1 packet_length
+ * byte 2-9struct ec_host_response
+ * byte 10-response data
+ */
+struct ec_host_response_i2c {
+ uint8_t result;
+ uint8_t packet_length;
+ struct ec_host_response ec_response;
+} __packed;
+
static inline struct cros_ec_device *to_ec_dev(struct device *dev)
{
struct i2c_client *client = to_i2c_client(dev);
@@ -29,6 +56,134 @@ static inline struct cros_ec_device *to_ec_dev(struct
device *dev)
return i2c_get_clientdata(client);
}
+static int cros_ec_pkt_xfer_i2c(struct cros_ec_device *ec_dev,
+ struct cros_ec_command *msg)
+{
+ struct i2c_client *client = ec_dev-priv;
+ int ret = -ENOMEM;
+ int i;
+ int packet_len;
+ u8 *out_buf = NULL;
+ u8 *in_buf = NULL;
+ u8 sum;
+ struct i2c_msg i2c_msg[2];
+ struct ec_host_response *ec_response;
+ struct ec_host_request_i2c *ec_request_i2c;
+ struct ec_host_response_i2c *ec_response_i2c;
+ int request_header_size = sizeof(struct ec_host_request_i2c);
+ int response_header_size = sizeof(struct ec_host_response_i2c);
+
+ i2c_msg[0].addr = client-addr;
+ i2c_msg[0].flags = 0;
+ i2c_msg[1].addr = client-addr;
+ i2c_msg[1].flags = I2C_M_RD;
+
+ packet_len = msg-insize + response_header_size;
+ BUG_ON(packet_len ec_dev-din_size);
+ in_buf = ec_dev-din;
+ i2c_msg[1].len = packet_len;
+ i2c_msg[1].buf = (char *) in_buf;
+
+ packet_len = msg-outsize + request_header_size;
+ BUG_ON(packet_len ec_dev-dout_size);
+ out_buf = ec_dev-dout;
+ i2c_msg[0].len = packet_len;
+ i2c_msg[0].buf = (char *) out_buf;
+
+ /* create request data */
+ ec_request_i2c = (struct ec_host_request_i2c *) out_buf;
+ ec_request_i2c-command_protocol = EC_COMMAND_PROTOCOL_3;
+
+ ec_dev-dout++;
+ ret = cros_ec_prepare_tx(ec_dev, msg);
+ ec_dev-dout--;
+
+ /* send command to EC and read answer */
+ ret = i2c_transfer(client-adapter, i2c_msg, 2);
+ if (ret 0) {
+ dev_dbg(ec_dev-dev, i2c transfer failed: %d\n, ret);
+ goto done;
+ } else if (ret != 2) {
+ dev_err(ec_dev-dev, failed to get response: %d\n, ret);
+ ret = -EIO;
+ goto done;
+ }
+
+ ec_response_i2c = (struct ec_host_response_i2c *) in_buf;
+ msg-result = ec_response_i2c-result;
+ ec_response = ec_response_i2c-ec_response;
+
+ switch (msg-result) {
+ case EC_RES_SUCCESS:
+ break;
+ case EC_RES_IN_PROGRESS:
+ ret = -EAGAIN;
+ dev_dbg(ec_dev-dev, command 0x%02x in progress\n,
+ msg-command);
+ goto done;
+
+ default:
+ dev_dbg(ec_dev-dev, command 0x%02x returned %d\n,
+ msg-command, msg-result);
+ /*
+* When we send v3 request to v2 ec, ec won't recognize the
+* 0xda (EC_COMMAND_PROTOCOL_3) and will return with status
+* EC_RES_INVALID_COMMAND with zero data length.
+*
+* In case of invalid command for v3 protocol the data length
+* will be at least sizeof(struct ec_host_response)
+*/
+ if (ec_response_i2c-result == EC_RES_INVALID_COMMAND
+
[PATCH 4/8] mfd: cros_ec: Instantiate sub-devices from device tree
From: Todd Broch tbr...@chromium.org
If the EC device tree node has sub-nodes, try to instantiate them as
MFD sub-devices. We can configure the EC features provided by the board.
Signed-off-by: Todd Broch tbr...@chromium.org
Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
---
drivers/mfd/cros_ec.c | 22 +++---
1 file changed, 11 insertions(+), 11 deletions(-)
diff --git a/drivers/mfd/cros_ec.c b/drivers/mfd/cros_ec.c
index 07c53c27c82a..9da95cc0a1ee 100644
--- a/drivers/mfd/cros_ec.c
+++ b/drivers/mfd/cros_ec.c
@@ -17,6 +17,7 @@
* battery charging and regulator control, firmware update.
*/
+#include linux/of_platform.h
#include linux/interrupt.h
#include linux/slab.h
#include linux/module.h
@@ -123,18 +124,8 @@ EXPORT_SYMBOL(cros_ec_cmd_xfer);
static const struct mfd_cell cros_devs[] = {
{
- .name = cros-ec-keyb,
- .id = 1,
- .of_compatible = google,cros-ec-keyb,
- },
- {
- .name = cros-ec-i2c-tunnel,
- .id = 2,
- .of_compatible = google,cros-ec-i2c-tunnel,
- },
- {
.name = cros-ec-ctl,
- .id = 3,
+ .id = 1,
},
};
@@ -164,6 +155,15 @@ int cros_ec_register(struct cros_ec_device *ec_dev)
return err;
}
+#ifdef CONFIG_OF
+ err = of_platform_populate(dev-of_node, NULL, NULL, dev);
+ if (err) {
+ mfd_remove_devices(dev);
+ dev_err(dev, Failed to register sub-devices\n);
+ return err;
+ }
+#endif
+
dev_info(dev, Chrome EC device registered\n);
return 0;
--
2.1.4
--
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
[PATCH 7/8] mfd: cros_ec: add proto v3 skeleton
From: Stephen Barber smbar...@chromium.org
Add support in cros_ec.c to handle EC host command protocol v3.
For v3+, probe for maximum shared protocol version and max
request, response, and passthrough sizes. For now, this will
always fall back to v2, since there is no bus-specific code
for handling proto v3 packets.
Signed-off-by: Stephen Barber smbar...@chromium.org
Reviewed-by: Puthikorn Voravootivat put...@chromium.org
Reviewed-by: Gwendal Grignou gwen...@chromium.org
Tested-by: Puthikorn Voravootivat put...@chromium.org
Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
---
drivers/mfd/cros_ec.c | 338 +-
drivers/mfd/cros_ec_i2c.c | 4 +
drivers/mfd/cros_ec_spi.c | 7 +-
drivers/platform/chrome/cros_ec_lpc.c | 4 +
include/linux/mfd/cros_ec.h | 20 +-
5 files changed, 320 insertions(+), 53 deletions(-)
diff --git a/drivers/mfd/cros_ec.c b/drivers/mfd/cros_ec.c
index ffaf17823115..c71b671ebacd 100644
--- a/drivers/mfd/cros_ec.c
+++ b/drivers/mfd/cros_ec.c
@@ -30,11 +30,253 @@
static int dev_id;
+static int prepare_packet(struct cros_ec_device *ec_dev,
+ struct cros_ec_command *msg)
+{
+ struct ec_host_request *request;
+ u8 *out;
+ int i;
+ u8 csum = 0;
+
+ BUG_ON(ec_dev-proto_version != EC_HOST_REQUEST_VERSION);
+ BUG_ON(msg-outsize + sizeof(*request) ec_dev-dout_size);
+
+ out = ec_dev-dout;
+ request = (struct ec_host_request *)out;
+ request-struct_version = EC_HOST_REQUEST_VERSION;
+ request-checksum = 0;
+ request-command = msg-command;
+ request-command_version = msg-version;
+ request-reserved = 0;
+ request-data_len = msg-outsize;
+
+ for (i = 0; i sizeof(*request); i++)
+ csum += out[i];
+
+ /* Copy data and update checksum */
+ memcpy(out + sizeof(*request), msg-outdata, msg-outsize);
+ for (i = 0; i msg-outsize; i++)
+ csum += msg-outdata[i];
+
+ request-checksum = -csum;
+
+ return sizeof(*request) + msg-outsize;
+}
+
+static int send_command(struct cros_ec_device *ec_dev,
+ struct cros_ec_command *msg)
+{
+ int ret;
+
+ if (ec_dev-proto_version 2)
+ ret = ec_dev-pkt_xfer(ec_dev, msg);
+ else
+ ret = ec_dev-cmd_xfer(ec_dev, msg);
+
+ if (msg-result == EC_RES_IN_PROGRESS) {
+ int i;
+ struct cros_ec_command status_msg = { };
+ struct ec_response_get_comms_status *status;
+
+ status_msg.command = EC_CMD_GET_COMMS_STATUS;
+ status_msg.insize = sizeof(*status);
+
+ /*
+* Query the EC's status until it's no longer busy or
+* we encounter an error.
+*/
+ for (i = 0; i EC_COMMAND_RETRIES; i++) {
+ usleep_range(1, 11000);
+
+ ret = ec_dev-cmd_xfer(ec_dev, status_msg);
+ if (ret 0)
+ break;
+
+ msg-result = status_msg.result;
+ if (status_msg.result != EC_RES_SUCCESS)
+ break;
+
+ status = (struct ec_response_get_comms_status *)
+status_msg.indata;
+ if (!(status-flags EC_COMMS_STATUS_PROCESSING))
+ break;
+ }
+ }
+
+ return ret;
+}
+
+static int cros_ec_host_command_proto_probe(struct cros_ec_device *ec_dev,
+ int devidx,
+ struct cros_ec_command *msg)
+{
+ /*
+* Try using v3+ to query for supported protocols. If this
+* command fails, fall back to v2. Returns the highest protocol
+* supported by the EC.
+* Also sets the max request/response/passthru size.
+*/
+ int ret;
+
+ if (!ec_dev-pkt_xfer)
+ return -EPROTONOSUPPORT;
+
+ memset(msg, 0, sizeof(*msg));
+ msg-command = EC_CMD_PASSTHRU_OFFSET(devidx) |
EC_CMD_GET_PROTOCOL_INFO;
+ msg-insize = sizeof(struct ec_response_get_protocol_info);
+
+ ret = send_command(ec_dev, msg);
+
+ if (ret 0) {
+ dev_dbg(ec_dev-dev,
+ failed to probe for EC[%d] protocol version: %d\n,
+ devidx, ret);
+ return ret;
+ }
+
+ if (devidx 0 msg-result == EC_RES_INVALID_COMMAND)
+ return -ENODEV;
+ else if (msg-result != EC_RES_SUCCESS)
+ return msg-result;
+
+ return 0;
+}
+
+static int cros_ec_host_command_proto_probe_v2(struct cros_ec_device *ec_dev)
+{
+ struct cros_ec_command msg = { };
+ struct ec_params_hello *hello_params;
+ struct
[PATCH 3/8] platform/chrome: cros_ec_lpc - Use existing function to check EC result
Commit 6db07b633658 (mfd: cros_ec: Check result code from EC messages)
added a common cros_ec_check_result() function that can be used to check
the ec_msg-result for errors and warns about them.
Use the existing function instead of duplicating same check in the driver.
Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
---
drivers/platform/chrome/cros_ec_lpc.c | 14 ++
1 file changed, 2 insertions(+), 12 deletions(-)
diff --git a/drivers/platform/chrome/cros_ec_lpc.c
b/drivers/platform/chrome/cros_ec_lpc.c
index 860310513cf0..3a675817c95d 100644
--- a/drivers/platform/chrome/cros_ec_lpc.c
+++ b/drivers/platform/chrome/cros_ec_lpc.c
@@ -95,19 +95,9 @@ static int cros_ec_cmd_xfer_lpc(struct cros_ec_device *ec,
/* Check result */
msg-result = inb(EC_LPC_ADDR_HOST_DATA);
-
- switch (msg-result) {
- case EC_RES_SUCCESS:
- break;
- case EC_RES_IN_PROGRESS:
- ret = -EAGAIN;
- dev_dbg(ec-dev, command 0x%02x in progress\n,
- msg-command);
+ ret = cros_ec_check_result(ec, msg);
+ if (ret)
goto done;
- default:
- dev_dbg(ec-dev, command 0x%02x returned %d\n,
- msg-command, msg-result);
- }
/* Read back args */
args.flags = inb(EC_LPC_ADDR_HOST_ARGS);
--
2.1.4
--
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 0/7] drm/exynos: clean ups
2015-03-12 Inki Dae inki@samsung.com: On 2015년 02월 19일 22:22, Gustavo Padovan wrote: From: Gustavo Padovan gustavo.pado...@collabora.co.uk Hi, Here goes some clean ups to the exynos drivers. The main clean ups is the presetting and zpos making the property immutable and the removal of *_win_data structures. With your cleanup patch set, the plane test doesn't work. Have you ever tested plane feature with modetest application? I typed like below and it looks like no problem but I cannot see anything on Panel except for cute four penguins. # modetest -P 29:100x100+0+0 trying to open device 'i915'...failed. trying to open device 'radeon'...failed. trying to open device 'nouveau'...failed. trying to open device 'vmwgfx'...failed. trying to open device 'omapdrm'...failed. trying to open device 'exynos'...success. testing 100x100@XR24 overlay plane 25 And for two plane test, # modetest -P 29:100x100+0+0 -P 29:100x100+0+100 trying to open device 'i915'...failed. trying to open device 'radeon'...failed. trying to open device 'nouveau'...failed. trying to open device 'vmwgfx'...failed. trying to open device 'omapdrm'...failed. trying to open device 'exynos'...success. testing 100x100@XR24 overlay plane 25 testing 100x100@XR24 overlay plane 26 Still no screen. Well, I did some more testing and even without my patches I can't see a plane on the screen. Running only on exynos-drm-next also doesn't work so it is not something that my patches introduced, it is already a bug upstream. I'm using a snow for testing. 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: [PATCH] ARM: dts: remove usb2-phy on Exynos5 series SoC
Hi, On Thu, Mar 12, 2015 at 3:40 PM, Jaewon Kim jaewon02@samsung.com wrote: Exynos5 series SoC does not have usb2-phy on USB3.0 Controller. It is controlled by only usb3-phy. So, this patch remove usb2-phy property. Why would you want to remove the usb2-phy property ? The usb2-phy projected here is actually the UTMI+ phy which is present as a part of a hybrid PHY controller (that includes both UTMI+ as well as PIPE3 phys). And the exynos5-usbdrd phy driver also differentiates between the two PHYs. It does try to separate out the initializations for UTMI+ and PIPE3 phy, if you notice the functions: exynos5_usbdrd_utmi_init() and exynos5_usbdrd_pipe3_init(). I don't think this change seems valid. Signed-off-by: Jaewon Kim jaewon02@samsung.com --- arch/arm/boot/dts/exynos5250.dtsi |4 ++-- arch/arm/boot/dts/exynos5420.dtsi |8 2 files changed, 6 insertions(+), 6 deletions(-) diff --git a/arch/arm/boot/dts/exynos5250.dtsi b/arch/arm/boot/dts/exynos5250.dtsi index 9bb1b0b..b58b169 100644 --- a/arch/arm/boot/dts/exynos5250.dtsi +++ b/arch/arm/boot/dts/exynos5250.dtsi @@ -565,8 +565,8 @@ compatible = synopsys,dwc3; reg = 0x1200 0x1; interrupts = 0 72 0; - phys = usbdrd_phy 0, usbdrd_phy 1; - phy-names = usb2-phy, usb3-phy; + phys = usbdrd_phy 0; + phy-names = usb3-phy; }; }; diff --git a/arch/arm/boot/dts/exynos5420.dtsi b/arch/arm/boot/dts/exynos5420.dtsi index 9dc2e97..0df14bb 100644 --- a/arch/arm/boot/dts/exynos5420.dtsi +++ b/arch/arm/boot/dts/exynos5420.dtsi @@ -845,8 +845,8 @@ compatible = snps,dwc3; reg = 0x1200 0x1; interrupts = 0 72 0; - phys = usbdrd_phy0 0, usbdrd_phy0 1; - phy-names = usb2-phy, usb3-phy; + phys = usbdrd_phy0 0; + phy-names = usb3-phy; }; }; @@ -871,8 +871,8 @@ compatible = snps,dwc3; reg = 0x1240 0x1; interrupts = 0 73 0; - phys = usbdrd_phy1 0, usbdrd_phy1 1; - phy-names = usb2-phy, usb3-phy; + phys = usbdrd_phy1 1; + phy-names = usb3-phy; }; }; -- 1.7.9.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 -- Best Regards Vivek Gautam Samsung RD Institute, Bangalore India -- 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 PATCH v2 3/3] ARM: dts: exynos5420: add async-bridge clocks to disp1 power domain
On 06/02/15 11:55, Andrzej Hajda wrote: FIMD and MIXER IPs in disp1 power domain have async-bridges (to GSCALER), therefore their clocks should be enabled during power domain switch. Signed-off-by: Andrzej Hajda a.ha...@samsung.com --- arch/arm/boot/dts/exynos5420.dtsi | 6 -- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/arch/arm/boot/dts/exynos5420.dtsi b/arch/arm/boot/dts/exynos5420.dtsi index e1fa800..58579f5 100644 --- a/arch/arm/boot/dts/exynos5420.dtsi +++ b/arch/arm/boot/dts/exynos5420.dtsi @@ -293,9 +293,11 @@ clock CLK_MOUT_SW_ACLK300, clock CLK_MOUT_USER_ACLK300_DISP1, clock CLK_MOUT_SW_ACLK400, - clock CLK_MOUT_USER_ACLK400_DISP1; + clock CLK_MOUT_USER_ACLK400_DISP1, + clock CLK_FIMD1, clock CLK_MIXER; clock-names = oscclk, pclk0, clk0, - pclk1, clk1, pclk2, clk2; + pclk1, clk1, pclk2, clk2, + asb0, asb1; }; In general I don't like those clock/clock-names properties in the power domain nodes, since the power domains are not really consumers of those clocks. However these clocks are essential for the exynos power domains operation. There are more dependencies between the clocks and the power domains which adding of those properties does not cover. And we'll need to address those dependencies somehow. Anyway, the subject patch looks OK to me, given that support for clocks/ clock-names in the exynos power domain device nodes has been merged for quite long already. The entire feature has been merged without PM or clk subsystem maintainer ACK, I don't see a reason not to merge this small addition of more clocks, especially that it fixes a real bug. Please feel free to add: Reviewed-by: Sylwester Nawrocki s.nawro...@samsung.com -- Regards, Sylwester -- 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: [GIT PULL] Exynos fixes for v4.0
Hello, On 2015-03-12 12:04, Kukjin Kim wrote: Krzysztof Kozlowski wrote: This groups important fixes for this v4.0-rc cycle. I hope you will find useful such grouping them in a pull request. Thanks for your gentle reminder :-) 1. Fix second suspend to RAM on Trats2 board. This has shown up after enabling L2 cache but actually the use delayed reset assertion is to be blamed. 2. Fix power domain issues with disp1 domain and HDMI (some of them) on Odroid XU3: - disp1 power domain can be turned off, - no more imprecise external abort faults. 3. Proper fix for build breakage of cpuidle on !SMP. This allows using Exynos cpuidle driver on UP. Best regards, Krzysztof The following changes since commit 2d2c9a8d0a4f90e298315d2f4a282d8bd5d45e5c: ARM: dts: add display power domain for exynos5250 (2015-02-27 05:29:32 +0900) are available in the git repository at: git://git.linaro.org/people/marek.szyprowski/linux-srpol.git v4.0-rc1-exynos-fixes for you to fetch changes up to c1b57bce36a69f3972a1db433d3c8b34e0541e63: ARM: EXYNOS: cpuidle: Fix build breakage on !SMP (2015-03-11 13:02:08 +0100) Andrzej Hajda (4): arm/exynos: add asynchronous bridge clock bindings arm/exynos/pm_domains: add support for async-bridge clocks ARM: dts: exynos5420: add async-bridge clocks to disp1 power domain ARM: dts: exynos5420: add async-bridge clocks to gsc power domain When I checked the patches, I expected that we could get the review from clock guys even we could do it though. And basically/usually the 'RFC' tagging means it's not a patch can be upstreamed and will be posted after gathering some comments so I didn't queue them in my tree. I'm still thinking like that... Frankly we thought that if the only comments are reports that the patches fixed the issue, there is no need to resend them without any change. I also don't know why you think that the review from clock maintainers is needed. Those patches modify power domain driver and implement the requirements from exynos5422 technical note about power on/off procedures. The quality of technical note is a different story (those requirements are not clearly stated there and one need to collect them from different chapters). The patches were posted with 'RFC' tag, because we were not sure if they will fix the lockup issues on all 5420+ based boards, but after comments from others it looks that they are finally the right approach. Bartlomiej Zolnierkiewicz (1): ARM: EXYNOS: cpuidle: Fix build breakage on !SMP Yeah, we need to fix it up asap and I'll finish it by this weekend. Sorry for the inconvenience. Krzysztof Kozlowski (1): ARM: EXYNOS: Fix failed second suspend on Exynos4 I'll have a look at this with above. Thanks, Kukjin .../bindings/arm/exynos/power_domain.txt | 3 ++ arch/arm/boot/dts/exynos5420.dtsi | 8 +++-- arch/arm/mach-exynos/common.h | 2 ++ arch/arm/mach-exynos/exynos.c | 29 +++- arch/arm/mach-exynos/platsmp.c | 39 ++ arch/arm/mach-exynos/pm.c | 2 ++ arch/arm/mach-exynos/pm_domains.c | 27 --- arch/arm/mach-exynos/suspend.c | 3 ++ drivers/cpuidle/cpuidle-exynos.c | 3 +- 9 files changed, 71 insertions(+), 45 deletions(-) Best regards -- Marek Szyprowski, PhD Samsung RD Institute Poland -- 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 PATCH 2/3] arm/exynos/pm_domains: add support for async-bridge clocks
On 05/02/15 13:35, Andrzej Hajda wrote:
Since Exynos5420 there are async-bridges (ASB) between different IPs. These
bridges must be operational during power domain on/off, ie. clocks used
by these bridges should be enabled.
This patch enabled these clocks during domain on/off.
Signed-off-by: Andrzej Hajda a.ha...@samsung.com
Reviewed-by: Sylwester Nawrocki s.nawro...@samsung.com
---
arch/arm/mach-exynos/pm_domains.c | 27 +++
1 file changed, 23 insertions(+), 4 deletions(-)
diff --git a/arch/arm/mach-exynos/pm_domains.c
b/arch/arm/mach-exynos/pm_domains.c
index 0e2bc36..ecff522 100644
--- a/arch/arm/mach-exynos/pm_domains.c
+++ b/arch/arm/mach-exynos/pm_domains.c
@@ -37,6 +37,7 @@ struct exynos_pm_domain {
struct clk *oscclk;
struct clk *clk[MAX_CLK_PER_DOMAIN];
struct clk *pclk[MAX_CLK_PER_DOMAIN];
+ struct clk *asb_clk[MAX_CLK_PER_DOMAIN];
};
static int exynos_pd_power(struct generic_pm_domain *domain, bool power_on)
@@ -45,14 +46,19 @@ static int exynos_pd_power(struct generic_pm_domain
*domain, bool power_on)
void __iomem *base;
u32 timeout, pwr;
char *op;
+ int i;
pd = container_of(domain, struct exynos_pm_domain, pd);
base = pd-base;
+ for (i = 0; i MAX_CLK_PER_DOMAIN; i++) {
+ if (IS_ERR(pd-asb_clk[i]))
+ break;
+ clk_prepare_enable(pd-asb_clk[i]);
+ }
+
/* Set oscclk before powering off a domain*/
if (!power_on) {
- int i;
-
for (i = 0; i MAX_CLK_PER_DOMAIN; i++) {
if (IS_ERR(pd-clk[i]))
break;
@@ -81,8 +87,6 @@ static int exynos_pd_power(struct generic_pm_domain
*domain, bool power_on)
/* Restore clocks after powering on a domain*/
if (power_on) {
- int i;
-
for (i = 0; i MAX_CLK_PER_DOMAIN; i++) {
if (IS_ERR(pd-clk[i]))
break;
@@ -92,6 +96,12 @@ static int exynos_pd_power(struct generic_pm_domain
*domain, bool power_on)
}
}
+ for (i = 0; i MAX_CLK_PER_DOMAIN; i++) {
+ if (IS_ERR(pd-asb_clk[i]))
+ break;
+ clk_disable_unprepare(pd-asb_clk[i]);
+ }
+
return 0;
}
@@ -137,6 +147,15 @@ static __init int exynos4_pm_init_power_domain(void)
pd-pd.power_off = exynos_pd_power_off;
pd-pd.power_on = exynos_pd_power_on;
+ for (i = 0; i MAX_CLK_PER_DOMAIN; i++) {
+ char clk_name[8];
+
+ snprintf(clk_name, sizeof(clk_name), asb%d, i);
+ pd-asb_clk[i] = clk_get(dev, clk_name);
+ if (IS_ERR(pd-asb_clk[i]))
+ break;
+ }
+
pd-oscclk = clk_get(dev, oscclk);
if (IS_ERR(pd-oscclk))
goto no_clk;
--
Sylwester Nawrocki
Samsung RD Institute Poland
--
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: [GIT PULL] Exynos fixes for v4.0
On czw, 2015-03-12 at 20:04 +0900, Kukjin Kim wrote: Krzysztof Kozlowski wrote: Dear Kukjin, Hi, This groups important fixes for this v4.0-rc cycle. I hope you will find useful such grouping them in a pull request. Thanks for your gentle reminder :-) 1. Fix second suspend to RAM on Trats2 board. This has shown up after enabling L2 cache but actually the use delayed reset assertion is to be blamed. 2. Fix power domain issues with disp1 domain and HDMI (some of them) on Odroid XU3: - disp1 power domain can be turned off, - no more imprecise external abort faults. 3. Proper fix for build breakage of cpuidle on !SMP. This allows using Exynos cpuidle driver on UP. Best regards, Krzysztof The following changes since commit 2d2c9a8d0a4f90e298315d2f4a282d8bd5d45e5c: ARM: dts: add display power domain for exynos5250 (2015-02-27 05:29:32 +0900) are available in the git repository at: git://git.linaro.org/people/marek.szyprowski/linux-srpol.git v4.0-rc1-exynos-fixes for you to fetch changes up to c1b57bce36a69f3972a1db433d3c8b34e0541e63: ARM: EXYNOS: cpuidle: Fix build breakage on !SMP (2015-03-11 13:02:08 +0100) Andrzej Hajda (4): arm/exynos: add asynchronous bridge clock bindings arm/exynos/pm_domains: add support for async-bridge clocks ARM: dts: exynos5420: add async-bridge clocks to disp1 power domain ARM: dts: exynos5420: add async-bridge clocks to gsc power domain When I checked the patches, I expected that we could get the review from clock guys even we could do it though. And basically/usually the 'RFC' tagging means it's not a patch can be upstreamed and will be posted after gathering some comments so I didn't queue them in my tree. I'm still thinking like that... You are right that it was tagged RFC. However Javier looked at it and gave his reviewed-by/tested-by tags. Anyway maybe Sylwester (+cc) could look at them and share his comments? The patches are necessary now to fix power domain issues related to HDMI. Bartlomiej Zolnierkiewicz (1): ARM: EXYNOS: cpuidle: Fix build breakage on !SMP Yeah, we need to fix it up asap and I'll finish it by this weekend. Sorry for the inconvenience. Thanks! Krzysztof Kozlowski (1): ARM: EXYNOS: Fix failed second suspend on Exynos4 I'll have a look at this with above. Great, thanks again! Best regards, Krzysztof -- 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: exynos_defconfig: Enable ChromeOS EC chardev driver
Javier Martinez Canillas wrote: Exynos Chromebooks have an Embedded Controller known as the ChromeOS EC Enable the driver that provides an interface to access from user-space. Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk --- arch/arm/configs/exynos_defconfig | 2 ++ 1 file changed, 2 insertions(+) diff --git a/arch/arm/configs/exynos_defconfig b/arch/arm/configs/exynos_defconfig index 3d22aae39a83..14fa9f05f768 100644 --- a/arch/arm/configs/exynos_defconfig +++ b/arch/arm/configs/exynos_defconfig @@ -173,6 +173,8 @@ CONFIG_RTC_DRV_S5M=y CONFIG_RTC_DRV_S3C=y CONFIG_DMADEVICES=y CONFIG_PL330_DMA=y +CONFIG_CHROME_PLATFORMS=y +CONFIG_CROS_EC_CHARDEV=y CONFIG_COMMON_CLK_MAX77686=y CONFIG_COMMON_CLK_MAX77802=y CONFIG_COMMON_CLK_S2MPS11=y -- OK, will apply. Thanks, Kukjin -- 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
[PATCH] ARM: dts: remove usb2-phy on Exynos5 series SoC
Exynos5 series SoC does not have usb2-phy on USB3.0 Controller. It is controlled by only usb3-phy. So, this patch remove usb2-phy property. Signed-off-by: Jaewon Kim jaewon02@samsung.com --- arch/arm/boot/dts/exynos5250.dtsi |4 ++-- arch/arm/boot/dts/exynos5420.dtsi |8 2 files changed, 6 insertions(+), 6 deletions(-) diff --git a/arch/arm/boot/dts/exynos5250.dtsi b/arch/arm/boot/dts/exynos5250.dtsi index 9bb1b0b..b58b169 100644 --- a/arch/arm/boot/dts/exynos5250.dtsi +++ b/arch/arm/boot/dts/exynos5250.dtsi @@ -565,8 +565,8 @@ compatible = synopsys,dwc3; reg = 0x1200 0x1; interrupts = 0 72 0; - phys = usbdrd_phy 0, usbdrd_phy 1; - phy-names = usb2-phy, usb3-phy; + phys = usbdrd_phy 0; + phy-names = usb3-phy; }; }; diff --git a/arch/arm/boot/dts/exynos5420.dtsi b/arch/arm/boot/dts/exynos5420.dtsi index 9dc2e97..0df14bb 100644 --- a/arch/arm/boot/dts/exynos5420.dtsi +++ b/arch/arm/boot/dts/exynos5420.dtsi @@ -845,8 +845,8 @@ compatible = snps,dwc3; reg = 0x1200 0x1; interrupts = 0 72 0; - phys = usbdrd_phy0 0, usbdrd_phy0 1; - phy-names = usb2-phy, usb3-phy; + phys = usbdrd_phy0 0; + phy-names = usb3-phy; }; }; @@ -871,8 +871,8 @@ compatible = snps,dwc3; reg = 0x1240 0x1; interrupts = 0 73 0; - phys = usbdrd_phy1 0, usbdrd_phy1 1; - phy-names = usb2-phy, usb3-phy; + phys = usbdrd_phy1 1; + phy-names = usb3-phy; }; }; -- 1.7.9.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: [PATCH] ARM: exynos_defconfig: Enable Marvell WiFi-Ex support
Martinez Canillas wrote: Exynos5420 Peach Pit and Exynos5800 Peach Pi boards have a MMC/SDIO Marvell WiFi-Ex chip. This patch enables wireless support and the mwifiex driver. Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk --- arch/arm/configs/exynos_defconfig | 4 1 file changed, 4 insertions(+) diff --git a/arch/arm/configs/exynos_defconfig b/arch/arm/configs/exynos_defconfig index 70e5d0bdb4e4..dcef516bcd0d 100644 --- a/arch/arm/configs/exynos_defconfig +++ b/arch/arm/configs/exynos_defconfig @@ -34,6 +34,10 @@ CONFIG_PACKET=y CONFIG_UNIX=y CONFIG_NET_KEY=y CONFIG_INET=y +CONFIG_WIRELESS=y +CONFIG_CFG80211=y +CONFIG_MWIFIEX=y +CONFIG_MWIFIEX_SDIO=y CONFIG_RFKILL_REGULATOR=y CONFIG_UEVENT_HELPER_PATH=/sbin/hotplug CONFIG_DEVTMPFS=y -- OK, will apply. Thanks, Kukjin -- 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
