in case of Exynos DRM.
This dma mapping API calls internally iommu_map function of iommu framework
after allocating physical pages and iova space, and the iova space will be
mapped with physical pages.
Please, look into the dma mapping framework - arch/arm/mm/dma-mapping.c -
if you want to u
Hi Daniel,
2015ë
10ì 28ì¼ 20:52ì Daniel Stone ì´(ê°) ì´ ê¸:
> Hi Inki,
>
> On 28 October 2015 at 11:16, Inki Dae wrote:
>> 2015ë
10ì 28ì¼ 20:00ì Daniel Stone ì´(ê°) ì´ ê¸:
>>> On 28 October 2015 at 10:58, Daniel Stone wrote:
>>>>
Hi Daniel,
2015ë
10ì 28ì¼ 20:00ì Daniel Stone ì´(ê°) ì´ ê¸:
> Hi,
>
> On 28 October 2015 at 10:58, Daniel Stone wrote:
>> On 28 October 2015 at 10:48, Inki Dae wrote:
>>> In Tizen platform, there is a buffer manager called TBM(Tizem Buffer
>>> Ma
Hi Daniel,
2015ë
10ì 28ì¼ 19:15ì Daniel Stone ì´(ê°) ì´ ê¸:
> Hi Inki,
>
> On 28 October 2015 at 06:55, Inki Dae wrote:
>>and revive a Exynos specific interface which was used
>>to get fake offset, which is required for application using render node
.
Thanks,
Inki Dae
2015ë
10ì 28ì¼ 15:55ì Inki Dae ì´(ê°) ì´ ê¸:
> Hi Dave,
>
>This pull request includes comprehensive cleanups to HDMI part and
>several fixups, and revive a Exynos specific interface which was used
>to get fake offset, which is required for ap
driver as default. For this, I got already Acked-by from Krzysztof
Kozlowski who is a Exynos SoC maintainer.
Please kindly let me know if there is any problem.
Thanks,
Inki Dae
The following changes since commit d7e1bc3f5e70c5a106606e33cfa4d413459611ba:
Merge branch 'msm-next' of git
;
> I guess this will go with rest of patchset through Exynos DRM tree:
> Acked-by: Krzysztof Kozlowski
Thanks for ack. I will pick it up.
Thanks,
Inki Dae
>
>
> Best regards,
> Krzysztof
>
> --
> To unsubscribe from this list: send the line "unsubscribe linu
R or DECON -
TV path of DECON controller transfers Display data to HDMI like MIXER IP of
previous Exynos SoC did.
Thanks,
Inki Dae
>
> Best regards,
> Krzysztof
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc"
> in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
2015-10-23 22:03 GMT+09:00 Andrzej Hajda :
>
> On 10/23/2015 01:55 PM, Inki Dae wrote:
> > Hi Andrzej,
> >
> >
> > 2015ë
10ì 20ì¼ 18:22ì Andrzej Hajda ì´(ê°) ì´ ê¸:
> >> DECON-TV IP is responsible for generating video stream which is transfer
>drm_dev = drm_dev;
> ctx->pipe = priv->pipe++;
>
> - for (zpos = 0; zpos < WINDOWS_NR; zpos++) {
> - type = exynos_plane_get_type(zpos, CURSOR_WIN);
> - ret = exynos_plane_init(drm_dev, >planes[zpos],
> + for (win = ctx->first_win; win < WINDOWS_NR; win++) {
> + int tmp = (win == ctx->first_win) ? 0 : win;
AFAIK, DECON TV for Exynos5433 SoC has four hardware overlays so I guess
you used ctx->first_win to initialize four planes in case of IFTYPE_HDMI.
However, with IFTYPE_HDMI ctx->first_win has 1, as a result,
ctx->planes[] will have 0, 2nd, 3rd and 4th planes and this means we
should use 0, 2nd ~ 4th hardware overlay excepting 1st overlay. Is this
your intention?
Shouldn't ctx->planes[] have 1st, 2nd ,3rd and 4th planes so that we can
use 1st ~ 4th hardware overlay for DECON TV?
DECON TV for Exynos5433 SoC can use only 1st ~ 4th hardware overlays.
And other thing, it may be trivial but I think it'd be better to use
'ovl' instead of 'tmp.
Thanks,
Inki Dae
Hi,
How about combining patch 5 and 6?
Patch 5 just introduces new internal API but these API aren't used
anywhere in patch 5.
Thanks,
Inki Dae
2015ë
10ì 13ì¼ 16:00ì Joonyoung Shim ì´(ê°) ì´ ê¸:
> The buffer allocation using DMA mapping API can't support non-continuous
>
Hi Gustavo,
Please ping~ and re-base on top of exynos-drm-next.
Thanks,
Inki Dae
2015ë
09ì 05ì¼ 05:15ì Gustavo Padovan ì´(ê°) ì´ ê¸:
> From: Gustavo Padovan
>
> Hi,
>
> This series adds proper runtime PM suport to CRTCs and Encoders, so
> now instead of rel
2015ë
10ì 13ì¼ 14:23ì Joonyoung Shim ì´(ê°) ì´ ê¸:
> On 10/13/2015 02:11 PM, Inki Dae wrote:
>>
>> Merged.
>>
>
> Thanks for merge but this will be conflicted with the patch of Daniel,
> http://patchwork.freedesktop.org/patch/60565/
Right. With Daniel
Merged.
Thanks,
Inki Dae
2015ë
10ì 05ì¼ 12:04ì Joonyoung Shim ì´(ê°) ì´ ê¸:
> The commit d931589c01a2 ("drm/exynos: remove DRM_EXYNOS_GEM_MAP_OFFSET
> ioctl") removed it same with the ioctl that this patch adds. The reason
> that removed DRM_EXYNOS_GEM_MAP_OFFS
Merged.
Thanks,
Inki Dae
2015ë
10ì 02ì¼ 09:33ì Joonyoung Shim ì´(ê°) ì´ ê¸:
> Struct of gem object in exynos_drm driver is struct exynos_drm_gem_obj.
> It's too long and we can know its meaning of name without _obj postfix.
>
> We use several names to variable name o
Merged.
Thanks,
Inki Dae
2015ë
10ì 02ì¼ 09:30ì Joonyoung Shim ì´(ê°) ì´ ê¸:
> The arm_iommu_detach_device() is a function to detach device of iommu
> attached by arm_iommu_attach_device(). The exynos-drm uses
> arm_iommu_attach_device() so it should use arm_iommu_deta
Hi, Ingi.
Merged. Thanks for your first patch to drm world. :)
This patch isn't trivial so will go to next.
Thanks,
Inki Dae
2015ë
10ì 02ì¼ 17:59ì Ingi Kim ì´(ê°) ì´ ê¸:
> This patch fixes spelling errors in drm fimc/gsc
> inavild -> invaild
>
> Signed-o
Hi Andrzej,
For all patches, merged excepting patch 2 which cleans up dt binding
document.
Thanks,
Inki Dae
2015ë
09ì 25ì¼ 21:48ì Andrzej Hajda ì´(ê°) ì´ ê¸:
> Hi,
>
> This is another set of cleanup/improvement patches for HDMI.
>
> The patchset is based on
Also ping~~
2015ë
09ì 19ì¼ 12:53ì Inki Dae ì´(ê°) ì´ ê¸:
> On 2015ë
09ì 05ì¼ 05:15, Gustavo Padovan wrote:
>> From: Gustavo Padovan
>>
>> Let pm_runtime handle the enabling/disabling of the device with proper
>> refcnt instead of rely on specific flags
Gustavo, please ping~~~
2015ë
09ì 19ì¼ 12:51ì Inki Dae ì´(ê°) ì´ ê¸:
> Hi Gustavo,
>
> On 2015ë
09ì 05ì¼ 05:15, Gustavo Padovan wrote:
>> From: Gustavo Padovan
>>
>> Instead of having a .clock_enable callback enable the dp clock directly
>> from F
Merged.
Thanks,
Inki Dae
2015ë
09ì 05ì¼ 07:05ì Gustavo Padovan ì´(ê°) ì´ ê¸:
> From: Gustavo Padovan
>
> Set one of the planes for each crtc driver as a cursor plane enabled
> window managers to fully work on exynos.
>
> Signed-off-by: Gustavo Padovan
>
&g
Hi Gustavo,
Merged.
Thanks,
Inki Dae
2015ë
09ì 05ì¼ 07:05ì Gustavo Padovan ì´(ê°) ì´ ê¸:
> From: Gustavo Padovan
>
> Define DEFAULT_WIN as zero to help set the primary plane on all CRTCs.
> Some CRTCs were defining a variable to store the default window, but that
> i
Hi Dave,
This pull request includes regression fixups, build warnings, and
trivial cleanups which mostly remove some codes not used anymore.
Please, kindly let me know if there is any problem.
Thanks,
Inki Dae
The following changes since commit
Hi Emil,
On 2015ë
09ì 30ì¼ 21:19, Emil Velikov wrote:
> Hi Inki,
>
> On 30 September 2015 at 12:21, Inki Dae wrote:
>> This patch removes unnecessary pm suspend/resume functions.
>>
>> All kms sub drivers will be controlled by top of Exynos drm driver
>>
m_dev exists.
Thanks for your patch. However, the pm interfaces of KMS drivers aren't
required because these are controlled by top of Exynos drm driver and
connector dpms. So I posted a patch that it removes pm interfaces of dp
driver.
Thanks,
Inki Dae
>
> Signed-off-by: Charles Keepax
> -
This patch removes unnecessary pm suspend/resume functions.
All kms sub drivers will be controlled by top of Exynos drm driver
and connector dpms so these sub drivers shouldn't have their own
pm interfaces.
Signed-off-by: Inki Dae
---
drivers/gpu/drm/exynos/exynos_dp_core.c | 23
On 2015ë
09ì 24ì¼ 10:01, Joonyoung Shim wrote:
> Hi Inki,
>
> On 08/17/2015 06:03 PM, Inki Dae wrote:
>> On 2015ë
08ì 17ì¼ 17:17, Joonyoung Shim wrote:
>>> On 08/17/2015 04:52 PM, Inki Dae wrote:
>>>> On 2015ë
08ì 17ì¼ 14:29, Joonyoung Shim wrote
00644
> --- a/drivers/gpu/drm/exynos/exynos7_drm_decon.c
> +++ b/drivers/gpu/drm/exynos/exynos7_drm_decon.c
> @@ -637,7 +637,6 @@ static const struct exynos_drm_crtc_ops decon_crtc_ops = {
> .enable = decon_enable,
> .disable = decon_disable,
> .mode_fixup = decon_mode_fixup
able(crtc, true);
You are forcing FIMD driver to enable DP clock every time FIMD is
enabled. Please know that in Exynos Display pipeline, Encoder device
could be used according to how Display path is configured.
For example,
FIMD - Panel
FIMD - MIPI-DSI - Panel
FIMD - DP - Panel
.
On 2015ë
09ì 04ì¼ 16:19, Daniel Vetter wrote:
> On Fri, Sep 04, 2015 at 01:05:35PM +0900, Inki Dae wrote:
>> Hi Gustavo,
>>
>> I had already a review but I didn't give any comment to you. Sorry about
>> that. This patch looks good to me but one thing isn't cl
0
> +#define CURSOR_WIN 1
You fixed overlay number for cursor with 1. However, Display controllers
of Exynos SoC have fixed overlay priority like this,
win 4 > win 3 > win 2 > win 1 > win 0 so if we fix the overlay number
for cursor and we use another overlay - which has a higher layer than
cursor - to display caption or UI then the we couldn't see the cursor on
screen without additional work such as color key or alpha channel.
So before that, you need to check how many overlays can be used
according to Exynos SoC versions, and which way is better - one is for
top layer to be fixed for cursor, other is for one given layer to be
fixed by user-space for cursor.
Thanks,
Inki Dae
> +
s_drm_fb.h"
>> #include "exynos_drm_fbdev.h"
>> -#include "exynos_drm_gem.h"
>> #include "exynos_drm_iommu.h"
>>
>> #define MAX_CONNECTOR 4
>> @@ -160,7 +159,7 @@ static int exynos_drm_fbdev_create(struct drm
even if we don't get too many reviewers. We better keep it around for
>> a couple of weeks in case others are swamped with unrelated work atm,
>> yet willing to take a look.
> Sure, I'm going to wait and do some pings from time to time :)
>
I had a review and looks good to me. There
On 2015ë
09ì 01ì¼ 04:57, Emil Velikov wrote:
> On 31 August 2015 at 20:27, Tobias Jakobi
> wrote:
>> Hello!
>>
>> Inki Dae wrote:
>>> On 2015ë
08ì 24ì¼ 23:13, Tobias Jakobi wrote:
>
>>>> +if (g2d_check_space(ctx, 7, 1))
>>
On 2015ë
09ì 01ì¼ 03:53, Emil Velikov wrote:
> On 31 August 2015 at 14:25, Inki Dae wrote:
>> On 2015ë
08ì 24ì¼ 23:14, Tobias Jakobi wrote:
>>> We now validate the blending mode via g2d_validate_mode()
>>> prior to feeding it to g2d_get_blend_op().
>>&
On 2015ë
09ì 01ì¼ 03:30, Emil Velikov wrote:
> On 31 August 2015 at 13:36, Inki Dae wrote:
>> Hi Emil,
>>
>> On 2015ë
08ì 31ì¼ 20:58, Emil Velikov wrote:
>>> Hi all,
>>>
>>> On 18 August 2015 at 08:01, Inki Dae wrote:
>>>> F
RO,
> - 0, 0, 0);
> - break;
With this, how about changing above switch and case statement to if
statement?
Thanks,
Inki Dae
> }
>
> return val.val;
>
t; + fprintf(stderr , "invalid select mode for source.\n");
> + return -EINVAL;
> + }
> +
> + if (g2d_validate_blending_op(op)) {
> + fprintf(stderr , "unsupported blending operation.\n");
> + return
+
> + gem_space = src->select_mode == G2D_SELECT_MODE_NORMAL ? 2 : 1;
> +
> + if (g2d_check_space(ctx, 12, gem_space))
> + return -ENOSPC;
As I mentioned before, above two lines could be integrated with other
patches.
Thanks,
Inki Dae
>
>
P_DISJOINT_DST:
> + case G2D_OP_CONJOINT_CLEAR:
> + case G2D_OP_CONJOINT_SRC:
> + case G2D_OP_CONJOINT_DST:
> + return 0;
Ditto, You could modify it like above.
Thanks,
Inki Dae
> + }
> +
> + return 1;
> +}
> +
> +/*
> * g2d_add_cmd - set given command and value to user side command buffer.
> *
> * @ctx: a pointer to g2d_context structure.
>
ctx, 11, 2))
> + return -ENOSPC;
Above lines could be integrated with 3 and 4 patches as one patch. And
you can make other codes to other one.
Thanks,
Inki Dae
> +
> + g2d_add_cmd(ctx, DST_SELECT_REG, G2D_SELECT_MODE_BGCOLOR);
> + g2d_add_cmd(ctx, DST_COLOR_MODE_R
On 2015ë
08ì 24ì¼ 23:13, Tobias Jakobi wrote:
> The amount of commands (regular and GEM) doesn't depend
> on the input here.
>
> Signed-off-by: Tobias Jakobi
> ---
> exynos/exynos_fimg2d.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/exynos/exynos_fimg2d.c
Hi Emil,
On 2015ë
08ì 31ì¼ 20:58, Emil Velikov wrote:
> Hi all,
>
> On 18 August 2015 at 08:01, Inki Dae wrote:
>> From: Joonyoung Shim
>>
>> This patch allows clients who want to use render node to access
>> rendering relevant ioctls - g2d, post processo
2015-08-27 17:31 GMT+09:00 Joonyoung Shim :
> If exynos_drm_gem_init() is failed, the result is ERR_PTR, so we should
> just return the result. If not, wrong porinter will be referenced from
> err label.
>
> Reported-by: Dan Carpenter
> Signed-off-by: Joonyoung Shim
> ---
>
On 2015ë
08ì 27ì¼ 00:45, Gustavo Padovan wrote:
> Hi Inki,
>
> 2015-08-24 Inki Dae :
>
>> On 2015ë
08ì 16ì¼ 01:26, Gustavo Padovan wrote:
>>> From: Gustavo Padovan
>>>
>>> .prepare_plane() and .cleanup_plane() allows to perform ext
{fimd/decon}_update_plane.
Hyungwon,
Gustavo already posted atomic_begin/flush support. However, he didn't
consider decon drivers.
Can you post only atomic_begin/flush support for decon drivers?
Thanks,
Inki Dae
>
> Signed-off-by: Hyungwon Hwang
> ---
> drivers/gpu/drm/exynos/exy
epare_plane(exynos_crtc,
> + exynos_plane);
There is no any reason to use prepare_plane/cleanup_plane callback
names. How about using atomic_begin/atomic_flush callback names instead
for consistency between framework and device drivers?
Thanks
From: Joonyoung Shim <jy0922.s...@samsung.com>
This patch allows clients who want to use render node to access
rendering relevant ioctls - g2d, post processor and gem allocation.
Signed-off-by: Joonyoung Shim
Signed-off-by: Inki Dae
---
drivers/gpu/drm/exynos/exynos_drm_drv.
On 2015ë
08ì 17ì¼ 17:17, Joonyoung Shim wrote:
> On 08/17/2015 04:52 PM, Inki Dae wrote:
>> On 2015ë
08ì 17ì¼ 14:29, Joonyoung Shim wrote:
>>> On 08/16/2015 02:07 PM, Inki Dae wrote:
>>>> On 2015ë
07ì 28ì¼ 17:53, Joonyoung Shim wrote:
>>>&
On 2015ë
08ì 17ì¼ 14:29, Joonyoung Shim wrote:
> On 08/16/2015 02:07 PM, Inki Dae wrote:
>> On 2015ë
07ì 28ì¼ 17:53, Joonyoung Shim wrote:
>>> The drm_gem_object_release() function already performs this cleanup,
>>> so there is no reason to do it exp
On 2015ë
08ì 17ì¼ 14:29, Joonyoung Shim wrote:
> On 08/16/2015 01:50 PM, Inki Dae wrote:
>> On 2015ë
07ì 28ì¼ 17:53, Joonyoung Shim wrote:
>>> Don't create a fake mmap offset in exynos_drm_gem_dumb_map_offset. If
>>> not, it will call drm_gem_create_mmap_of
On 2015ë
08ì 16ì¼ 14:26, Inki Dae wrote:
> On 2015ë
07ì 28ì¼ 17:53, Joonyoung Shim wrote:
>> The dma-buf codes of exynos drm is almost same with prime helpers. A
>> difference is that consider DMA_NONE when import dma-buf, but it's wrong
>> and we don't consider i
ea to use prime helpers. However, I'm not sure of
there really is no any corner case the prime helper doesn't consider for
Vendor SoC yet. So let's have more reviews about this.
Thanks,
Inki Dae
>
> Signed-off-by: Joonyoung Shim
> ---
> drivers/gpu/drm/exynos/Makefile|
rea_struct *vma)
> obj = vma->vm_private_data;
> exynos_gem_obj = to_exynos_gem_obj(obj);
>
> - ret = check_gem_flags(exynos_gem_obj->flags);
> - if (ret)
> + if (exynos_gem_obj->flags & ~(EXYNOS_BO_MASK)) {
> + DRM_ERROR("invalid flags.\n");
> goto err_close_vm;
> + }
I will remove above checking as Daniel Stone commented because user
space cannot control the flag.
Thanks,
Inki Dae
>
> update_vm_cache_attr(exynos_gem_obj, vma);
>
>
e function would be called by drm_gem_vm_close
function which drops a reference of the gem object.
However, drm_gem_vm_close should be a pair with drm_gem_vm_open
function. These will be called whenever a process opens or closes the
VMA. So the reference count of the gem object had already been t
n in case of
not using dumb* interfaces. I.e.,
exynos_drm_gem_create_ioctl -> exynos_drm_gem_mmap
And drm_gem_create_mmap_offset checks if vma_node was already allocated
or not so this patch doesn't make sense.
Thanks,
Inki Dae
>
> Signed-off-by: Joonyoung Shim
> ---
>
;
> mutex_unlock(>struct_mutex);
>
> - return convert_to_vm_err_msg(ret);
> + switch (ret) {
> + case 0:
> + case -ERESTARTSYS:
You missed -EINTR but I can modify it.
Thanks,
Inki Dae
> + return VM_FAULT_NOPAGE;
> + case -ENOMEM:
> + return VM_FAULT_OOM;
> + default:
> + return VM_FAULT_SIGBUS;
> + }
> }
>
> int exynos_drm_gem_mmap(struct file *filp, struct vm_area_struct *vma)
>
are NULL or not.
Signed-off-by: Inki Dae
---
drivers/gpu/drm/drm_crtc_helper.c | 44 ++-
1 file changed, 29 insertions(+), 15 deletions(-)
diff --git a/drivers/gpu/drm/drm_crtc_helper.c
b/drivers/gpu/drm/drm_crtc_helper.c
index ef53475..aa1f42f 100644
locks.
Signed-off-by: Inki Dae
---
drivers/gpu/drm/drm_atomic.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
index 1066e4b..4349154 100644
--- a/drivers/gpu/drm/drm_atomic.c
+++ b/drivers/gpu/drm/drm_atomic.c
@@ -1230,9
2015-08-13 0:54 GMT+09:00 Gustavo Padovan :
> 2015-08-12 Gustavo Padovan :
>
>> Hi Inki,
>>
>> 2015-08-11 Inki Dae :
>>
>> > On 2015ë
08ì 11ì¼ 09:38, Gustavo Padovan wrote:
>> > > Hi Inki,
>> > >
>> > > 2015-08-07 Inki
On 2015ë
08ì 12ì¼ 00:03, Daniel Vetter wrote:
> On Tue, Aug 11, 2015 at 09:13:54PM +0900, Inki Dae wrote:
>> On 2015ë
08ì 11ì¼ 09:38, Gustavo Padovan wrote:
>>> Hi Inki,
>>>
>>> 2015-08-07 Inki Dae :
>>>
>>>> Hi Gustavo,
>
Hi Dave,
This pull request fixes memory leak and some issues related to
mixer and gscaler driver issues.
Please kindly let me know if there is any problem.
Thanks,
Inki Dae
The following changes since commit bdce3e7c729907e303396690b2b23b972c6717be:
Merge branch 'msm-fixes-4.2
On 2015ë
07ì 22ì¼ 15:59, Archit Taneja wrote:
> Use the newly created wrapper drm_fb_helper functions instead of calling
> core fbdev functions directly. They also simplify the fb_info creation.
>
> COMPILE TESTED ONLY.
Acked-by: Inki Dae
Thanks,
Inki Dae
>
>
This patch fixes null pointer access incurred when
encoder driver didn't set its own mode_fixup callback.
mode_fixup callback shoudn't be called if the callback
of drm_encoder_helper_funcs is NULL.
Changelog v2:
- change it to else if
Signed-off-by: Inki Dae
Reviewed-by: Maarten Lankhorst
On 2015ë
08ì 11ì¼ 09:38, Gustavo Padovan wrote:
> Hi Inki,
>
> 2015-08-07 Inki Dae :
>
>> Hi Gustavo,
>>
>> On 2015ë
08ì 06ì¼ 22:31, Gustavo Padovan wrote:
>>> From: Gustavo Padovan
>>>
>>> struct exynos_drm_encoder
This patch fixes null pointer access incurred when
encoder driver didn't set its own mode_fixup callback.
mode_fixup callback shoudn't be called if the callback
of drm_encoder_helper_funcs is NULL.
Signed-off-by: Inki Dae
---
drivers/gpu/drm/drm_atomic_helper.c | 3 +++
1 file changed, 3
On 2015ë
08ì 11ì¼ 18:04, Inki Dae wrote:
> On 2015ë
07ì 13ì¼ 15:38, Archit Taneja wrote:
>> Use the newly created wrapper drm_fb_helper functions instead of calling
>> core fbdev functions directly. They also simplify the fb_info creation.
>>
>> COMPILE TEST
On 2015ë
07ì 13ì¼ 15:38, Archit Taneja wrote:
> Use the newly created wrapper drm_fb_helper functions instead of calling
> core fbdev functions directly. They also simplify the fb_info creation.
>
> COMPILE TESTED ONLY.
>
> Cc: Inki Dae
> Cc: Joonyoung Shim
Hi Daniel,
On 2015ë
08ì 07ì¼ 21:28, Daniel Vetter wrote:
> On Fri, Aug 7, 2015 at 1:50 PM, Inki Dae wrote:
>>
>> Booting is locked up here. This patch looks good to me so I tried to
>> find why locked up and I found the booting is locked up as soon as
>> console_l
to
find why locked up and I found the booting is locked up as soon as
console_lock function is called. Can you and other guys look into this
issue?
Thanks,
Inki Dae
> Signed-off-by: Gustavo Padovan
> ---
> drivers/gpu/drm/exynos/Makefile | 7 +-
> drivers/gpu/drm/exynos/e
gt;> Signed-off-by: Marek Szyprowski
>
> Gentle ping...
Sorry, I missed it. Merged.
Thanks,
Inki Dae
>
>> ---
>> drivers/gpu/drm/exynos/exynos_drm_fimc.c | 1 -
>> 1 file changed, 1 deletion(-)
>>
>> diff --git a/drivers/gpu/drm/exynos/exynos_drm
- set dp->dpms_mode after enable/disable
I don't see patch v2 10/11 and 11/11 in my mailbox. Did you miss them?
Thanks,
Inki Dae
>
> Gustavo Padovan (11):
> drm/exynos: split display's .dpms() into .enable() and .disable()
> drm/exynos: remove wrappers for phy_power_{on,off}
>
On 2015ë
08ì 04ì¼ 23:47, Gustavo Padovan wrote:
> Hi Inki,
>
> 2015-08-04 Inki Dae :
>
>> On 2015ë
08ì 04ì¼ 04:09, Gustavo Padovan wrote:
>>> From: Gustavo Padovan
>>>
>>> struct exynos_drm_encoder was justing wrapping struct drm_
On 2015ë
08ì 04ì¼ 04:09, Gustavo Padovan wrote:
> From: Gustavo Padovan
>
> struct exynos_drm_encoder was justing wrapping struct drm_encoder, it had
> only a drm_encoder member and the internal exynos_drm_encoders ops that
> was directly mapped to the drm_encoder helper funcs.
>
> So now
On 2015ë
08ì 04ì¼ 04:09, Gustavo Padovan wrote:
> From: Gustavo Padovan
>
> This functions was just hiding the encoder and connector creation in
> a way that was less clean than if we get rid of it. For example,
> exynos_encoder ops had .create_connector() defined only because we were
>
Anyway, I merged below patch so let's resolve this issue with more
generic way later.
P.s., I removed the patch which incurred the kernel hang issue from
exynos-drm-fixes, and moved it to exynos-drm-next with below patch so
now there must be no any problem with exynos-drm-fixes.
Thanks,
Inki
Hi Gustavo,
For 1 through 9 merged. And I guess you have the rest we have to review
but this patch series doesn't have consistency of previous, v2.
So please, post the rest again re-basing on top of exynos-drm-next.
Thanks,
Inki Dae
On 2015ë
07ì 30ì¼ 05:11, Gustavo Padovan wrote:
>
Hi Gustavo,
On 2015ë
07ì 30ì¼ 05:11, Gustavo Padovan wrote:
> Hi Inki,
>
> Any comments about this series?
Will review all of them. Now we are reviewing fix-up and clean-up patches.
Thanks,
Inki Dae
>
> Thanks,
>
> Gustavo
>
> 2015-07-16 G
+ samsung-soc
On 2015ë
07ì 28ì¼ 17:51, Joonyoung Shim wrote:
> This is simplest solution about reported problem[1]. It's no problem to
> clear channel only when iommu is enabled, if we consider that we cannot
> recognize iommu errors when iommu is disabled and it have been valid
> until now.
On 2015ë
07ì 22ì¼ 19:08, Inki Dae wrote:
> On 2015ë
07ì 22ì¼ 17:42, Joonyoung Shim wrote:
>> On 07/22/2015 05:22 PM, Inki Dae wrote:
>>> On 2015ë
07ì 22ì¼ 17:12, Joonyoung Shim wrote:
>>>> On 07/22/2015 01:55 PM, Inki Dae wrote:
>>>>>
On 2015ë
07ì 22ì¼ 17:42, Joonyoung Shim wrote:
> On 07/22/2015 05:22 PM, Inki Dae wrote:
>> On 2015ë
07ì 22ì¼ 17:12, Joonyoung Shim wrote:
>>> On 07/22/2015 01:55 PM, Inki Dae wrote:
>>>> On 2015ë
07ì 22ì¼ 11:02, Joonyoung Shim wrote:
>>&
On 2015ë
07ì 22ì¼ 17:12, Joonyoung Shim wrote:
> On 07/22/2015 01:55 PM, Inki Dae wrote:
>> On 2015ë
07ì 22ì¼ 11:02, Joonyoung Shim wrote:
>>> On 07/21/2015 10:19 PM, Krzysztof Kozlowski wrote:
>>>> Hi,
>>>>
>>>> Today's linux-n
ce_if_possible and then we can remove
>> drm_iommu_attach_device_if_possible and clear_channels function pointer.
>>
>> Signed-off-by: Joonyoung Shim
>> Tested-by: Marek Szyprowski
>> Signed-off-by: Inki Dae
>>
>> :04 04 83379efbf4
Hi Stephen,
On 2015ë
06ì 23ì¼ 15:43, Stephen Rothwell wrote:
> Hi Inki,
>
> On Tue, 23 Jun 2015 15:14:53 +0900 Inki Dae wrote:
>>
>> This patch fixes the below build error reported by Stephen,
>> https://lkml.org/lkml/2015/6/22/665
>
> Don't do
nt_by_regs function
with "static inline".
Signed-off-by: Inki Dae
---
include/linux/of_graph.h |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/linux/of_graph.h b/include/linux/of_graph.h
index 1c1d5b9..f8bcd0e 100644
--- a/include/linux/of_graph.h
+++ b/incl
This patch fixes the below build error reported by Stephen,
https://lkml.org/lkml/2015/6/22/665
To fix the error, this patch declares of_graph_get_endpoint_by_regs function
with "static inline".
Signed-off-by: Inki Dae
---
include/linux/of_graph.h |2 +-
1 file changed, 1
dt at kernel.org>
>
> FYI, Since I'm merging this via exynos-next into my tree, it broke
> module builds of exynos, because it doesn't export the symbol it adds,
> I've added a patch to my -next tree to fix it up.
>
> Inki, in future can you add a modular build to pre-pull te
On 2015ë
06ì 23ì¼ 11:10, Krzysztof Kozlowski wrote:
> 2015-06-22 21:35 GMT+09:00 Krzysztof Kozlowski :
>> 2015-06-22 20:42 GMT+09:00 Inki Dae :
>>> + Krzysztof
>>>
>>> On 2015ë
06ì 22ì¼ 18:10, Inki Dae wrote:
>>>> On 2015ë
06ì 12ì¼ 21
+ Samsung SoC mailing list.
On 2015ë
06ì 12ì¼ 21:59, Hyungwon Hwang wrote:
> This patch renames pll_clk to sclk_clk. The clock referenced by pll_clk
> is actually not the pll input clock for dsi. The pll input clock comes
> from the board's oscillator directly. But for the backward
>
On 2015ë
06ì 22ì¼ 20:59, Krzysztof Kozlowski wrote:
> 2015-06-22 20:42 GMT+09:00 Inki Dae :
>> + Krzysztof
>>
>> On 2015ë
06ì 22ì¼ 18:10, Inki Dae wrote:
>>> On 2015ë
06ì 12ì¼ 21:59, Hyungwon Hwang wrote:
>>>> The clock which was named as
On 2015ë
06ì 22ì¼ 20:41, Varka Bhadram wrote:
> Hi,
>
> On 06/22/2015 04:46 PM, Inki Dae wrote:
>
>> From: Joonyoung Shim
>>
>> DECON(Display and Enhancement Controller) is new IP replacing FIMD in
>> Exynos5433. This patch adds Exynos5433 decon driv
+ Krzysztof
On 2015ë
06ì 22ì¼ 18:10, Inki Dae wrote:
> On 2015ë
06ì 12ì¼ 21:59, Hyungwon Hwang wrote:
>> The clock which was named as 'pll_clk' is actually not the clock source
>> of PLL in MIPI DSI. This patch fixes this disagreement.
>
> Mr. Kukjin and Krzys
ed-off-by: Hyungwon Hwang
Signed-off-by: Inki Dae
---
.../devicetree/bindings/video/exynos5433-decon.txt | 65 ++
drivers/gpu/drm/exynos/Kconfig |6 +
drivers/gpu/drm/exynos/Makefile|1 +
drivers/gpu/drm/exynos/exynos5433_drm_decon.c
inline through drm-next.
Thanks,
Inki Dae
>
> Signed-off-by: Hyungwon Hwang
> ---
> Changes before:
> - Refer https://patchwork.kernel.org/patch/6191811
> Changes for v6:
> - None
>
> arch/arm/boot/dts/exynos4.dtsi | 2 +-
> 1 file changed, 1 insertion(+), 1 deletio
On 2015ë
06ì 17ì¼ 23:33, Gustavo Padovan wrote:
> Hi Inki,
>
> 2015-06-17 Inki Dae :
>
>> Hi Gustavo,
>>
>> On 2015ë
06ì 17ì¼ 05:35, Gustavo Padovan wrote:
>>> HI Inki,
>>>
>>> 2015-06-15 Inki Dae :
>>>
>>>
, the waiting there is really unnecessary because
page flip operation does already it.
Signed-off-by: Inki Dae
---
drivers/gpu/drm/exynos/exynos_drm_fb.c |2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_fb.c
b/drivers/gpu/drm/exynos/exynos_drm_fb.c
index 789db6f
On 2015ë
06ì 19ì¼ 14:46, Krzysztof Kozlowski wrote:
> 2015-06-19 14:28 GMT+09:00 Inki Dae :
>> On 2015ë
06ì 19ì¼ 14:23, Krzysztof Kozlowski wrote:
>>> The field 'vma' of 'exynos_drm_gem_obj' structure was introduced in
>>> 2a3098ff6c21 ("drm/exynos: ad
may be mapped to multiple
> user-space VMAs so 'vma' field does not look useful anyway.
Krzysztof,
The vma member would be removed by below patch,
http://lists.freedesktop.org/archives/dri-devel/2015-May/082764.html
Thanks,
Inki Dae
>
> Signed-off-by: Krzysztof Kozlowski
> ---
>
On 2015ë
06ì 17ì¼ 23:33, Gustavo Padovan wrote:
> Hi Inki,
>
> 2015-06-17 Inki Dae :
>
>> Hi Gustavo,
>>
>> On 2015ë
06ì 17ì¼ 05:35, Gustavo Padovan wrote:
>>> HI Inki,
>>>
>>> 2015-06-15 Inki Dae :
>>>
>>>
Hi Gustavo,
On 2015ë
06ì 17ì¼ 05:35, Gustavo Padovan wrote:
> HI Inki,
>
> 2015-06-15 Inki Dae :
>
>> Hi Gustavo,
>>
>> On 2015ë
06ì 02ì¼ 00:04, Gustavo Padovan wrote:
>>> From: Gustavo Padovan
>>>
>>> Hi,
>>>
>
701 - 800 of 2980 matches
Mail list logo