Already struct exynos_drm_gem_buf has pages of the buffer when buffer is
created, so just can use pages in page fault handler, we don't have to
make sgtable of the buffer. But this needs to construct pages of the
buffer that is imported from dma-buf prime.
Signed-off-by: Joonyoung
Don't create a fake mmap offset in exynos_drm_gem_dumb_map_offset. If
not, it will call drm_gem_create_mmap_offset whenever user requests
DRM_IOCTL_MODE_MAP_DUMB ioctl.
Signed-off-by: Joonyoung Shim
---
drivers/gpu/drm/exynos/exynos_drm_gem.c | 12 +++-
1 file changed, 7 inser
The exynos_drm_gem_map_buf can be merged in exynos_drm_gem_fault.
Signed-off-by: Joonyoung Shim
---
drivers/gpu/drm/exynos/exynos_drm_gem.c | 36 +++--
1 file changed, 12 insertions(+), 24 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_gem.c
b/drivers
Already struct exynos_drm_gem_buf has pages of the buffer, so we don't
need to copy from sg table of the buffer to sg table of dma-buf
attachment, just can make sg table from pages of the buffer.
Signed-off-by: Joonyoung Shim
---
drivers/gpu/drm/exynos/exynos_drm_dmabuf.c
For more correct error information.
Signed-off-by: Joonyoung Shim
---
drivers/gpu/drm/exynos/exynos_drm_gem.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_gem.c
b/drivers/gpu/drm/exynos/exynos_drm_gem.c
index 8fffc4d..550d267
The struct exynos_drm_gem_obj can have fields of the struct
exynos_drm_gem_buf then don't need to use exynos_drm_buf.c file.
Signed-off-by: Joonyoung Shim
---
drivers/gpu/drm/exynos/Makefile | 3 +-
drivers/gpu/drm/exynos/exynos_drm_buf.c | 170
dr
The function roundup_gem_size can be merged in exynos_drm_gem_create.
Signed-off-by: Joonyoung Shim
---
drivers/gpu/drm/exynos/exynos_drm_gem.c | 9 +
1 file changed, 1 insertion(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_gem.c
b/drivers/gpu/drm/exynos
The drm_gem_object_release() function already performs this cleanup,
so there is no reason to do it explicitly.
Signed-off-by: Joonyoung Shim
---
drivers/gpu/drm/exynos/exynos_drm_gem.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_gem.c
b/drivers/gpu
The function check_gem_flags is too simple, so it's better to move codes
in each consumer functions.
Signed-off-by: Joonyoung Shim
---
drivers/gpu/drm/exynos/exynos_drm_gem.c | 24
1 file changed, 8 insertions(+), 16 deletions(-)
diff --git a/drivers/gpu/drm/e
The userptr, write and pfnmap of struct exynos_drm_gem_buf are not used
anywhere.
Signed-off-by: Joonyoung Shim
---
drivers/gpu/drm/exynos/exynos_drm_gem.h | 7 ---
1 file changed, 7 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_gem.h
b/drivers/gpu/drm/exynos
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 it any more, so we can use prime interface.
Signed-off-by: Joonyoung Shim
---
drivers/gpu/drm/exynos/Makefile
There is no reason to use mutex locking in pagefault handler.
Signed-off-by: Joonyoung Shim
---
drivers/gpu/drm/exynos/exynos_drm_gem.c | 5 -
1 file changed, 5 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_gem.c
b/drivers/gpu/drm/exynos/exynos_drm_gem.c
index 752cb7c
The function update_vm_cache_attr can be merged in exynos_drm_gem_mmap.
Signed-off-by: Joonyoung Shim
---
drivers/gpu/drm/exynos/exynos_drm_gem.c | 28 +++-
1 file changed, 11 insertions(+), 17 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_gem.c
b/drivers
p
patches like it need to more review after merge atomic patchset.
Thanks.
>
> On 2015-06-01 17:04, Gustavo Padovan wrote:
>> From: Joonyoung Shim
>>
>> Handle changes by removing copy from adjusted_mode to mode as using
>> adjusted_mode of crtc_state.
>>
>>
On 06/03/2015 11:30 PM, Gustavo Padovan wrote:
> From: Gustavo Padovan
>
> The atomic modesetting interfaces supports async commits that should be
> implemented by the drivers. If drm core requests an async commit
> exynos_atomic_commit() will schedule a work task to run the update later.
> It al
On 06/09/2015 11:27 PM, Gustavo Padovan wrote:
> Hi Inki and Joonyoung,
>
> Any comments on this series?
I saw this series in brief and good mostly. I feel it can be better to
split a atomic patch and cleanup patches, it can make to merge easier.
It's problem to give late any feedback about patc
On 06/10/2015 10:36 PM, Gustavo Padovan wrote:
> Hi Marek,
>
> 2015-06-10 Marek Szyprowski :
>
>> Hello,
>>
>> On 2015-06-01 17:04, Gustavo Padovan wrote:
>>> From: Gustavo Padovan
>>>
>>> Hi,
>>>
>>> Here goes the full support for atomic modesetting on exynos. I've
>>> split the patches in the
touch planes except to disable plane.
Also it leads eliminable enabled and resume of struct exynos_drm_plane.
Signed-off-by: Gustavo Padovan
Signed-off-by: Joonyoung Shim
---
This patch was modified from original patch of Gustavo Padovan -
http://www.spinics.net/lists/linux-samsung-soc/msg45351
eroff"). Don't need to wait vblank anymore.
Signed-off-by: Joonyoung Shim
---
drivers/gpu/drm/exynos/exynos_mixer.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/gpu/drm/exynos/exynos_mixer.c
b/drivers/gpu/drm/exynos/exynos_mixer.c
index 6bab717..f93f038 100644
--- a/drivers
disabled, so it may continue display output of prior when clocks for
fimd are enabled again.
Signed-off-by: Joonyoung Shim
---
drivers/gpu/drm/exynos/exynos_drm_fimd.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
b/drivers/gpu/drm/exynos
planes except to disable plane.
Also it leads eliminable enabled and resume of struct exynos_drm_plane.
Signed-off-by: Gustavo Padovan
Signed-off-by: Joonyoung Shim
Tested-by: Marek Szyprowski
---
This patch was modified from original patch of Gustavo Padovan -
http://www.spinics.net/lists
On 06/11/2015 11:01 PM, Gustavo Padovan wrote:
> Hi Joonyoung,
>
> 2015-06-11 Joonyoung Shim :
>
>> On 06/10/2015 10:36 PM, Gustavo Padovan wrote:
>>> Hi Marek,
>>>
>>> 2015-06-10 Marek Szyprowski :
>>>
>>>> Hello,
>>>>
This fixes reset codes to support memory mapped hdmi phy as well as hdmi
phy dedicated i2c lines.
Signed-off-by: Joonyoung Shim
---
drivers/gpu/drm/exynos/exynos_hdmi.c | 8 ++--
1 file changed, 2 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c
b/drivers
In booting, we can see a below message.
[3.241728] exynos-mixer 1445.mixer: Unbalanced pm_runtime_enable!
Already pm_runtime_enable is called by probe function. Remove
pm_runtime_enable/disable from mixer_bind and mixer_unbind.
Signed-off-by: Joonyoung Shim
---
I'm not sure wh
] [] (arch_cpu_idle) from []
(cpu_startup_entry+0x108/0x16c)
[ 20.083846] [] (cpu_startup_entry) from []
(start_kernel+0x3a0/0x3ac)
[ 20.091980] ---[ end trace 2c76ee0500489d1b ]---
Signed-off-by: Joonyoung Shim
---
It can be any root solution than this patch. Actually i'm not sure
whether it'
The exynos_drm_dmabuf.c file doesn't include any module feature and it
isn't built to module.
Signed-off-by: Joonyoung Shim
---
drivers/gpu/drm/exynos/exynos_drm_dmabuf.c | 4
1 file changed, 4 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_dmabuf.c
b/drivers/gpu/
The exynos drm driver has DRIVER_PRIME capability, then it's reasonable
to support dmabuf as default. Remove DRM_EXYNOS_DMABUF config, it will
prevent that user selects the option unnecessarily.
Signed-off-by: Joonyoung Shim
---
This patch can be conflicted below link patch of Marek to r
The exynos_plane_dpms can cause misunderstanding as using dpms term
because it is irrelevant with dpms functionality of DRM. Split to
functions fit for the one purpose instead of DPMS flags.
Signed-off-by: Joonyoung Shim
---
drivers/gpu/drm/exynos/exynos_drm_crtc.c | 4 ++--
drivers/gpu/drm
from commit e7cd8041 ("drm/exynos: Don't touch DPMS
when updating overlay planes").
Make .update_plane function called only by set_plane and call
exynos_plane_on in it.
Signed-off-by: Joonyoung Shim
---
drivers/gpu/drm/exynos/exynos_drm_crtc.c | 4 ++--
drivers/gpu/drm/exynos/exy
+Cc dri-devel ML.
Hi Alban,
On 01/30/2015 06:18 AM, Alban Browaeys wrote:
> The hdmi outputs black screen only even though under the hood Xorg and
> framebuffer console are fine : devices found and initialized, but
> not a pixel out.
>
> Commit 93bca243ec96 ("drm/exynos: remove struct exynos_dr
+Cc Inki,
Hi,
On 01/23/2015 09:42 PM, Gustavo Padovan wrote:
> From: Gustavo Padovan
>
> exynos_plane_dpms(DRM_MODE_DPMS_ON) calls the win_enable()'s callback
> from the underlying layer. However neither one of these layers implement
> win_enable() - FIMD, Mixer and VIDI. Thus the call to exyno
+Cc Inki,
Hi,
On 01/23/2015 09:42 PM, Gustavo Padovan wrote:
> From: Gustavo Padovan
>
> The drm_file event_list hasn't been used anymore by exynos, so we don't
> need any code to clean it.
>
No, it is used from drm core e.g. drm_irq.c file.
Thanks.
> Signed-off-by: Gustavo Padovan
> ---
>
+Cc Inki,
Hi,
On 01/30/2015 02:10 AM, Gustavo Padovan wrote:
> From: Mandeep Singh Baines
>
> The goal of the change is to make sure we send the vblank event on the
> current vblank. My hope is to fix any races that might be causing flicker.
> After this change I only see a flicker in the trans
, int zpos);
> -
> /* This function gets pipe value to crtc device matched with out_type. */
> int exynos_drm_crtc_get_pipe_from_type(struct drm_device *drm_dev,
> unsigned int out_type);
>
Acked-by: Joonyoung Shim
Thanks.
+Cc Inki,
Hi,
On 01/23/2015 09:42 PM, Gustavo Padovan wrote:
> From: Gustavo Padovan
>
> struct {fimd,mixer,vidi}_win_data was just keeping the same data
> as struct exynos_drm_plane thus get ride of it and use exynos_drm_plane
> directly.
>
> It changes how planes are created and remove .win_
Hi,
On 01/23/2015 09:43 PM, Gustavo Padovan wrote:
> From: Daniel Kurtz
>
> The 'mode' is the modeline information which specifies the ideal mode
> requested by the mode set initiator (usually userspace).
> The 'adjusted_mode' is the actual hardware mode after all the crtcs
> and encoders have h
Hi,
On 01/30/2015 09:24 AM, Joonyoung Shim wrote:
> +Cc dri-devel ML.
>
> Hi Alban,
>
> On 01/30/2015 06:18 AM, Alban Browaeys wrote:
>> The hdmi outputs black screen only even though under the hood Xorg and
>> framebuffer console are fine : devices found and init
We get wrong pipe value for crtc since commit 93bca243ec96 ("drm/exynos:
remove struct exynos_drm_manager"). We should should increase pipe value
before call exynos_drm_crtc_create.
Signed-off-by: Joonyoung Shim
---
drivers/gpu/drm/exynos/exynos_drm_fimd.c | 13 +++--
drive
Use driver internal struct as argument instead of struct exynos_drm_crtc
except functions of exynos_drm_crtc_ops and instead of struct
exynos_drm_display except functions of exynos_drm_display_ops.
It can reduce unnecessary variable declaration.
Signed-off-by: Joonyoung Shim
---
drivers/gpu
GHT(win_data->mode_height);
> + val |= MXR_MXR_RES_WIDTH(win_data->mode_width);
> mixer_reg_write(res, MXR_RESOLUTION, val);
> }
>
>
Acked-by: Joonyoung Shim
Thanks.
On 06/24/2015 06:35 AM, Gustavo Padovan wrote:
> From: Gustavo Padovan
>
> When mode's vrefresh is zero we should ask DRM core to calculate vrefresh
> for us so we can get the correct value instead of relying on fixed value
> defined in a macro. But if vrefresh is still zero we should fail the
>
On 06/24/2015 06:35 AM, Gustavo Padovan wrote:
> From: Gustavo Padovan
>
> We already have the plane pointer in before calling .update_plane() or
> disable_plane() so pass it directly to those calls avoiding a new
> conversion from zpos to struct exynos_drm_plane.
>
> Signed-off-by: Gustavo Pado
On 06/24/2015 06:35 AM, Gustavo Padovan wrote:
> From: Gustavo Padovan
>
> struct drm_crtc already stores the enabled state of the crtc
> thus we don't need to replicate enabled in exynos_drm_crtc.
>
> Signed-off-by: Gustavo Padovan
> ---
> drivers/gpu/drm/exynos/exynos_drm_crtc.c | 16 ---
+Cc Hyungwon,
On 06/24/2015 06:35 AM, Gustavo Padovan wrote:
> From: Gustavo Padovan
>
> exynos_dp_commit() was getting called twice by exynos encoder core, once
> inside the .enable() call and another time by .commit() itself.
>
> The remove of the second call caused the wake of a bug, the ope
Hi Gustavo,
On 06/24/2015 06:35 AM, Gustavo Padovan wrote:
> From: Gustavo Padovan
>
> Hi,
>
> This set improves exynos in a number of ways. The first five patches are
> general clean up/fixes.
>
> Patches 06 to 12 are improvements on top of the newly added atomic modesetting
> support.
I'm n
On 06/29/2015 03:35 PM, Hyungwon Hwang wrote:
> Dear Marek,
>
> On Thu, 25 Jun 2015 15:10:12 +0200
> Marek Szyprowski wrote:
>
>> Some drivers (like Exynos mixer) calls
>> drm_iommu_attach_device_if_possible before registering crtc, so
>> additional check for NULL crtc pointer is required.
>
>
Wmaybe-uninitialized]
int ret;
^
Signed-off-by: Joonyoung Shim
---
drivers/gpu/drm/exynos/exynos_drm_g2d.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_g2d.c
b/drivers/gpu/drm/exynos/exynos_drm_g2d.c
index 810e1ee..7584834 100644
--- a/d
manual.
Signed-off-by: Joonyoung Shim
---
drivers/gpu/drm/exynos/exynos_mixer.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_mixer.c
b/drivers/gpu/drm/exynos/exynos_mixer.c
index cae98db..60538bf 100644
--- a/drivers/gpu/drm/exynos
If CONFIG_ARM_DMA_USE_IOMMU is disable, CONFIG_DRM_EXYNOS_IOMMU also is
disable. When CONFIG_DRM_EXYNOS_IOMMU is disable,
is_drm_iommu_supported() returns always false, so we can remove to use
ifdef CONFIG_ARM_DMA_USE_IOMMU in is_drm_iommu_supported().
Signed-off-by: Joonyoung Shim
---
drivers
Already drm_iommu_attach_device and drm_iommu_detach_device check
whether support iommu internally, so we don't have to call
is_drm_iommu_supported before call them.
Signed-off-by: Joonyoung Shim
---
drivers/gpu/drm/exynos/exynos5433_drm_decon.c | 3 +--
drivers/gpu/drm/e
can remove
drm_iommu_attach_device_if_possible and clear_channels function pointer.
Signed-off-by: Joonyoung Shim
---
drivers/gpu/drm/exynos/exynos5433_drm_decon.c | 5 +++--
drivers/gpu/drm/exynos/exynos7_drm_decon.c| 5 +++--
drivers/gpu/drm/exynos/exynos_drm_drv.h | 1 -
drivers/gpu/
Hi Hyungwon,
On 07/02/2015 09:39 PM, Joonyoung Shim wrote:
> +Cc Hyungwon,
>
> On 06/24/2015 06:35 AM, Gustavo Padovan wrote:
>> From: Gustavo Padovan
>>
>> exynos_dp_commit() was getting called twice by exynos encoder core, once
>> inside the .enable() call and
On 07/09/2015 03:25 PM, Andrzej Hajda wrote:
> The driver used incorrect flags to clear interrupt status.
> The patch fixes it.
>
> Signed-off-by: Andrzej Hajda
> ---
> drivers/gpu/drm/exynos/exynos_mixer.c | 8 +++-
> 1 file changed, 3 insertions(+), 5 deletions(-)
>
> diff --git a/drivers
ertions(+), 51 deletions(-)
>
Looks good to me except one comment of "drm/exynos/mixer: fix interrupt
clearing" patch. Also below my patch can be dropped by this patchset.
http://www.spinics.net/lists/dri-devel/msg85322.html
Reviewed-by: Joonyoung Shim
+Cc Andrzej,
On 07/07/2015 02:41 AM, Daniel Vetter wrote:
> On Mon, Jul 06, 2015 at 11:20:13AM -0300, Gustavo Padovan wrote:
>> From: Gustavo Padovan
>>
>> struct drm_crtc already stores the enabled state of the crtc
>> thus we don't need to replicate enabled in exynos_drm_crtc.
>>
I think exyno
* clear interrupts */
> - if (~val & MXR_INT_EN_VSYNC) {
> - /* vsync interrupt use different bit for read and clear */
> - val &= ~MXR_INT_EN_VSYNC;
> - val |= MXR_INT_CLEAR_VSYNC;
> - }
> mixer_reg_write(res, MXR_INT_STATUS, val);
>
> spin_unlock(&res->reg_slock);
>
Reviewed-by: Joonyoung Shim
Thanks.
On 07/10/2015 07:56 AM, Gustavo Padovan wrote:
> 2015-07-09 Joonyoung Shim :
>
>> +Cc Andrzej,
>>
>> On 07/07/2015 02:41 AM, Daniel Vetter wrote:
>>> On Mon, Jul 06, 2015 at 11:20:13AM -0300, Gustavo Padovan wrote:
>>>> From: Gustavo Padovan
>>
hdmi_v14_conf struct
>
> drivers/gpu/drm/exynos/exynos_hdmi.c | 860
> ++-
> 1 file changed, 245 insertions(+), 615 deletions(-)
>
Looks good to me about this patchset,
Reviewed-by: Joonyoung Shim
ror 1
If you post the stuff that only be related, it will be reviewed and
merged easier.
01-04 and 06-11 patches look good to me, about them,
Reviewed-by: Joonyoung Shim
>
>
> v2: Fix comments by Joonyoung
The vidi is virtual kms driver and now it is registered earlier than
actual hw kms drivers, so it will occupy crtc index 0. Some users
assume the condition yet that actual hw kms driver has crtc index 0.
It may or may not be matter but let's arrange register order.
Signed-off-by: Joonyoung
On 10/19/2015 09:20 PM, Inki Dae wrote:
> 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.
>
I split it to be easy to understand changes of codes on patch file. It's
no matter to me to combine them.
Anyway
Hi,
This patchset is for cleanup about fb and fbdev codes of exynos-drm
driver. This removes unnecesary and redundant codes mostly, and make a
variable having too long name to be short.
Thanks.
Joonyoung Shim (9):
drm/exynos: remove exynos_drm_fb_set_buf_cnt()
drm/exynos: s
The exynos_drm_fb_set_buf_cnt() is used to set buffer count only in
exynos_drm_fbdev_update(). This patch sets directly buffer count in
exynos_drm_framebuffer_init() without using exynos_drm_fb_set_buf_cnt(),
so there is no any reason to keep exynos_drm_fb_set_buf_cnt().
Signed-off-by: Joonyoung
This patch moves codes to update fb_info into exynos_drm_fbdev_update(),
so fb_info is updated via only one function.
Signed-off-by: Joonyoung Shim
---
drivers/gpu/drm/exynos/exynos_drm_fbdev.c | 29 +
1 file changed, 13 insertions(+), 16 deletions(-)
diff --git a
The variable name "exynos_gem_obj" is too long, so some lines exceed 80
characters. It's simple to use "obj" instead of "exynos_gem_obj".
Signed-off-by: Joonyoung Shim
---
drivers/gpu/drm/exynos/exynos_drm_fbdev.c | 30 ++
1
Current codes get first gem object and then again get remain gem
objects. They can be unified to one routine.
Signed-off-by: Joonyoung Shim
---
drivers/gpu/drm/exynos/exynos_drm_fb.c | 23 ---
1 file changed, 8 insertions(+), 15 deletions(-)
diff --git a/drivers/gpu/drm
We can get buffer count of framebuffer using drm_format_num_planes(), so
keeping exynos_drm_fb_get_buf_cnt() is unnecessary.
Signed-off-by: Joonyoung Shim
---
drivers/gpu/drm/exynos/exynos_drm_fb.c| 9 -
drivers/gpu/drm/exynos/exynos_drm_fb.h| 3 ---
drivers/gpu/drm/exynos
This modifies exynos_drm_framebuffer_init() to be possible to support
multiple buffers. Then it can be used by exynos_user_fb_create().
Signed-off-by: Joonyoung Shim
---
drivers/gpu/drm/exynos/exynos_drm_fb.c| 36 +--
drivers/gpu/drm/exynos/exynos_drm_fb.h
Using exynos_drm_framebuffer_init(), redundant codes can be removed.
Signed-off-by: Joonyoung Shim
---
drivers/gpu/drm/exynos/exynos_drm_fb.c | 47 ++
1 file changed, 13 insertions(+), 34 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_fb.c
b
-off-by: Joonyoung Shim
---
drivers/gpu/drm/exynos/exynos_drm_fb.c | 9 -
1 file changed, 9 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_fb.c
b/drivers/gpu/drm/exynos/exynos_drm_fb.c
index d2e746e..6d1b70e 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fb.c
+++ b/drivers
It can get exynos_gem object via function argument, so no need to call
exynos_drm_fb_gem_obj() in exynos_drm_fbdev_update.
It also can get struct drm_framebuffer *fb via helper->fb, so can remove
a function argument for it.
Signed-off-by: Joonyoung Shim
---
drivers/gpu/drm/exy
rt() to import dma-bufs, so
exynos-drm driver using drm_gem_prime_import() needs calling
drm_prime_gem_destroy().
Signed-off-by: Joonyoung Shim
---
drivers/gpu/drm/exynos/exynos_drm_gem.c | 9 +
drivers/gpu/drm/exynos/exynos_drm_gem.h | 2 ++
2 files changed, 7 insertions(+), 4 deletion
There is no guarantee that DMA addresses are the same as physical
addresses, but dma_to_pfn() knows how to convert a dma_addr_t to a PFN
which can then be converted to a struct page.
Suggested-by: Russell King
Signed-off-by: Joonyoung Shim
---
drivers/gpu/drm/exynos/exynos_drm_gem.c | 3 ++-
1
Hi,
This patchset is small cleanup about exynos_drm_gem codes of exynos-drm
driver. This removes unnecessary and redundant codes, and staticize a
local function.
Thanks.
Joonyoung Shim (4):
drm/exynos: remove unnecessary NULL assignment
drm/exynos: staticize exynos_drm_gem_init
The exynos_drm_gem_init() is used only in exynos_drm_gem.c file. Make it
static and don't export it.
Signed-off-by: Joonyoung Shim
---
drivers/gpu/drm/exynos/exynos_drm_gem.c | 3 +--
drivers/gpu/drm/exynos/exynos_drm_gem.h | 4
2 files changed, 1 insertion(+), 6 deletions(-)
diff --
The beginning of statement in function is next line of a brace.
Signed-off-by: Joonyoung Shim
---
drivers/gpu/drm/exynos/exynos_drm_gem.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_gem.c
b/drivers/gpu/drm/exynos/exynos_drm_gem.c
By if statment, some function callings are written twice. It needs
several line feed by indentation in if statment. Make to one function
calling from outside if statment.
Signed-off-by: Joonyoung Shim
---
drivers/gpu/drm/exynos/exynos_drm_gem.c | 56 ++---
1 file
They will be freed right or was freed already, so NULL assignment is
unnecessary.
Signed-off-by: Joonyoung Shim
---
drivers/gpu/drm/exynos/exynos_drm_gem.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_gem.c
b/drivers/gpu/drm/exynos/exynos_drm_gem.c
G2D and IPP drivers get event time from do_gettimeofday(), but drm
vblank event gets it from ktime. Use ktime for consistency.
Signed-off-by: Joonyoung Shim
---
drivers/gpu/drm/exynos/exynos_drm_g2d.c | 4 +++-
drivers/gpu/drm/exynos/exynos_drm_ipp.c | 4 +++-
2 files changed, 6 insertions
On 09/16/2015 02:31 PM, Joonyoung Shim wrote:
> G2D and IPP drivers get event time from do_gettimeofday(), but drm
> vblank event gets it from ktime. Use ktime for consistency.
Oops, this causes build errors, please ignore, i will retry.
Thanks.
>
> Signed-off-by: Jo
+Cc: Boram Park,
Hi Marek,
On 12/16/2015 09:21 PM, Marek Szyprowski wrote:
> This patch adds all infrastructure to make zpos plane property
> configurable from userspace.
>
> Signed-off-by: Marek Szyprowski
> ---
> drivers/gpu/drm/exynos/exynos_drm_drv.h | 4 ++-
> drivers/gpu/drm/exynos/ex
Hi Marek,
On 12/16/2015 09:21 PM, Marek Szyprowski wrote:
> Properly configure blending properties of given hardware layer based on
> the selected pixel format. Currently only per-pixel-based alpha is possible
> when respective pixel format has been selected. Configuration of global,
> per-plane a
On 12/17/2015 10:05 PM, Marek Szyprowski wrote:
> Hello,
>
> On 2015-12-17 03:55, Joonyoung Shim wrote:
>> +Cc: Boram Park,
>>
>> Hi Marek,
>>
>> On 12/16/2015 09:21 PM, Marek Szyprowski wrote:
>>> This patch adds all infrastructure to make zpo
+Cc Boram Park,
On 12/18/2015 12:54 AM, Marek Szyprowski wrote:
> Hi Joonyoung,
>
> On 2015-12-17 05:19, Joonyoung Shim wrote:
>> Hi Marek,
>>
>> On 12/16/2015 09:21 PM, Marek Szyprowski wrote:
>>> Properly configure blending properties of given hardware l
On 01/30/2015 11:36 PM, Gustavo Padovan wrote:
> 2015-01-30 Joonyoung Shim :
>
>> +Cc Inki,
>>
>> Hi,
>>
>> On 01/23/2015 09:42 PM, Gustavo Padovan wrote:
>>> From: Gustavo Padovan
>>>
>>> exynos_plane_dpms(DRM_MODE_DPMS_ON)
Hi,
On 01/30/2015 11:42 PM, Gustavo Padovan wrote:
> Hi Joonyoung,
>
> 2015-01-30 Joonyoung Shim :
>
>> +Cc Inki,
>>
>> Hi,
>>
>> On 01/23/2015 09:42 PM, Gustavo Padovan wrote:
>>> From: Gustavo Padovan
>>>
>>> struct {f
Hi,
On 01/30/2015 11:44 PM, Gustavo Padovan wrote:
> Hi Joonyoung,
>
> 2015-01-30 Joonyoung Shim :
>
>> Hi,
>>
>> On 01/23/2015 09:43 PM, Gustavo Padovan wrote:
>>> From: Daniel Kurtz
>>>
>>> The 'mode' is the modeline infor
+Cc dri-devel ML,
Hi,
On 01/31/2015 06:45 AM, Gustavo Padovan wrote:
> From: Prathyush K
>
> When VPLL clock of less than 140 MHz was used and all the three
> clocks - hdmiphy, hdmi, sclk_hdmi are disabled, the system hangs
> during S2R when HDMI is connected. Since we want to use a vpll
> cloc
On 01/31/2015 02:17 AM, Gustavo Padovan wrote:
> 2015-01-30 Daniel Vetter :
>
>> On Fri, Jan 30, 2015 at 03:57:53PM +, Daniel Stone wrote:
>>> Hi,
>>>
>>> On 30 January 2015 at 14:30, Gustavo Padovan wrote:
>>>> 2015-01-30 Joonyoung Shim :
gt;dev->of_node,
> + "samsung,exynos5420-hdmi")) {
> + clk_disable_unprepare(hdata->res.sclk_hdmi);
> + clk_disable_unprepare(hdata->res.hdmi);
> + }
> +
> if (hdata->hdmiphy_port)
> put_device(&hdata->hdmiphy_port->dev);
> put_device(&hdata->ddc_adpt->dev);
>
Looks fine to me but i'm not sure any there are any side effects to
change parent clock of mout_hdmi clock.
Acked-by: Joonyoung Shim
Thanks.
Hi,
On 02/03/2015 12:58 PM, Kukjin Kim wrote:
> Marek Szyprowski wrote:
>>
>> Hi all,
>>
>> This is yet another update on patchset, which enables HDMI support for
>> Exynos based platforms.
>>
>> Beside DTS changes, this patchset adds parent domain support for Exynos
>> PM domains and add support
Hi,
On 02/03/2015 10:28 PM, Gustavo Padovan wrote:
> Hi Joonyoung,
>
> 2015-01-29 Joonyoung Shim :
>
>> The exynos_update_plane functions can be called from set_plane as well
>> as set_crtc and pageflip. Currently the plane displayed by set_plane
>> isn't cal
Hi,
On 02/03/2015 10:41 PM, Gustavo Padovan wrote:
> From: Gustavo Padovan
>
> This issue was caused by the latest exynos_update_plane() clean up
> that unified plane operations. After those changes the plane failed
> to go the On state. This patch fix this problem by doing correct account
> of
Hi,
On 02/03/2015 11:16 PM, Gustavo Padovan wrote:
> 2015-02-02 Joonyoung Shim :
>
>> Hi,
>>
>> On 01/30/2015 11:44 PM, Gustavo Padovan wrote:
>>> Hi Joonyoung,
>>>
>>> 2015-01-30 Joonyoung Shim :
>>>
>>>> Hi,
>>&
ied to support NV12MT in format_check. I really welcome the
new way.
Acked-by: Joonyoung Shim
Thanks.
> - The gem side for the gsc support doesn't look better: The code
> forgets to set the pixel format and makes a big mess with the tiling
> mode bits, inadvertedly setting them all.
Hi,
On 02/04/2015 04:14 AM, Gustavo Padovan wrote:
> From: Gustavo Padovan
>
> Hi,
>
> This series clean ups a few more paths from exynos-drm with the most important
> being the removal of the global page flip queue and the removal in driver
> internal data (struct *_win_data) that was replicat
Hi,
On 02/04/2015 04:14 AM, Gustavo Padovan wrote:
> From: Gustavo Padovan
>
> exynos_plane_dpms(DRM_MODE_DPMS_ON) calls the win_enable()'s callback
> from the underlying layer. However neither one of these layers implement
> win_enable() - FIMD, Mixer and VIDI. Thus the call to exynos_plane_dpm
Hi,
On 02/04/2015 04:14 AM, Gustavo Padovan wrote:
> From: Gustavo Padovan
>
> struct {fimd,mixer,vidi}_win_data was just keeping the same data
> as struct exynos_drm_plane thus get ride of it and use exynos_drm_plane
> directly.
>
> It changes how planes are created and remove .win_mode_set()
Hi,
On 02/04/2015 04:14 AM, Gustavo Padovan wrote:
> From: Gustavo Padovan
>
> The atomic helper to disable planes also uses the optional
> .atomic_disable() helper. The unique operation it does is calling
> .win_disable()
>
Is there any reason to split this patch from patch 06/14?
> exynos_d
Hi,
On 02/04/2015 04:14 AM, Gustavo Padovan wrote:
> From: Gustavo Padovan
>
> Add CRTC callbacks .atomic_begin() .atomic_flush(). On exynos they
> unprotect the windows before the commit and protects it after based on
> a plane mask tha store which plane will be updated.
>
I don't think they
401 - 500 of 584 matches
Mail list logo
