rom EDID.
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/drivers/gpu/drm/drm_edid.c?h=v5.14.14#n4725
Signed-off-by: Inki Dae
Thanks,
Inki Dae
> DRM_DEV_DEBUG_KMS(hdata->dev, "%s : width[%d] x height[%d]\n",
> (hd
ne automatically as part of plane init, if drivers set the
> modifier list correctly. Which is the case here.
>
> Signed-off-by: Daniel Vetter
Acked-by: Inki Dae
Thanks,
Inki Dae
> Cc: Inki Dae
> Cc: Joonyoung Shim
> Cc: Seung-Woo Kim
> Cc: Kyungmin Park
20. 2. 12. 오전 1:22에 Ville Syrjala 이(가) 쓴 글:
> From: Ville Syrjälä
>
> Replace the hand rolled encoder bitmask thing with drm_encoder_mask()
>
> Cc: Inki Dae
> Cc: Joonyoung Shim
> Cc: Seung-Woo Kim
> Cc: Kyungmin Park
> Acked-by: Thomas Zimmermann
> Signed
19. 8. 1. 오전 1:58에 Andrzej Pietrasiewicz 이(가) 쓴 글:
> Switch to using the ddc provided by the generic connector.
>
> Signed-off-by: Andrzej Pietrasiewicz
> Acked-by: Sam Ravnborg
> Reviewed-by: Emil Velikov
Acked-by: Inki Dae
Thanks,
Inki Dae
> ---
> drivers/gpu/drm
19. 3. 26. 오후 10:19에 Daniel Vetter 이(가) 쓴 글:
> This will give the exynos fbdev a name!
>
> v2: Rebase
>
> Signed-off-by: Daniel Vetter
Acked-by: Inki Dae
Thanks,
Inki Dae
> Cc: Inki Dae
> Cc: Joonyoung Shim
> Cc: Seung-Woo Kim
> Cc: Kyungmin Park
> C
2017년 12월 06일 03:24에 Noralf Trønnes 이(가) 쓴 글:
> This driver can use drm_fb_helper_lastclose() as its .lastclose callback.
> It can also use drm_fb_helper_output_poll_changed() as its
> .output_poll_changed callback.
>
> Cc: Inki Dae
> Cc: Joonyoung Shim
> Cc: Seung-Wo
ed callback.
>>
>> Cc: Inki Dae
>> Cc: Joonyoung Shim
>> Cc: Seung-Woo Kim
>> Cc: Kyungmin Park
>> Signed-off-by: Noralf Trønnes
>> ---
>> drivers/gpu/drm/exynos/exynos_drm_drv.c | 8 ++--
>> drivers/gpu/drm/exynos/ex
2017년 07월 05일 00:18에 Daniel Vetter 이(가) 쓴 글:
> From: Thierry Reding
>
> The FB helper core now supports deferred setup, so the driver's custom
> implementation can be removed.
Reviewed-by: Inki Dae
Tested-by: Inki Dae
Thanks,
Inki Dae
>
> v2: Drop NULL check, drm_
2017년 05월 31일 17:45에 Daniel Vetter 이(가) 쓴 글:
> On Tue, May 30, 2017 at 09:03:34AM +0900, Inki Dae wrote:
>> Hi Daniel,
>>
>> 2017년 05월 24일 23:51에 Daniel Vetter 이(가) 쓴 글:
>>> Only in the load failure path, where the hardware is quiet anyway.
>>>
>>&
Hi Daniel,
2017년 05월 24일 23:51에 Daniel Vetter 이(가) 쓴 글:
> Only in the load failure path, where the hardware is quiet anyway.
>
> Cc: Inki Dae
> Cc: Joonyoung Shim
> Cc: Seung-Woo Kim
> Cc: Kyungmin Park
> Signed-off-by: Daniel Vetter
> ---
> drivers/gpu/drm/
makes it a bit more obviuos what's going on wrt the
>>> runtime pm refdancing.
>>
>> Commit message copypasta.
>
> Hm, yeah. Inki, can you pls adjust that when merging to exynos-next? Just
> drop the last sentence that talks about pm refdancing.
>
2016년 08월 16일 01:02에 Daniel Vetter 이(가) 쓴 글:
> On Mon, Aug 15, 2016 at 04:42:18PM +0100, Chris Wilson wrote:
>> Rendering operations to the dma-buf are tracked implicitly via the
>> reservation_object (dmabuf->resv). This is used to allow poll() to
>> wait upon outstanding rendering (or just quer
2016년 05월 30일 03:35에 Daniel Vetter 이(가) 쓴 글:
> We want to hide drm_atomic_state internals better.
Acked-by: Inki Dae
Thanks,
Inki Dae
>
> Cc: Inki Dae
> Signed-off-by: Daniel Vetter
> ---
> drivers/gpu/drm/exynos/exynos_drm_drv.c | 8
> 1 file change
anyone not to call this function
with mutex lock?
If there is such case then,
some_function()
{
mutex_lock();
...
mutex_unlock();
drm_fb_helper_add_one_connector();
...
}
So in this case, other users should consider to make sure to unlock before
calling this
2016-05-30 3:35 GMT+09:00 Daniel Vetter :
> We want to hide drm_atomic_state internals better.
>
Acked-by: Inki Dae
> Cc: Inki Dae
> Signed-off-by: Daniel Vetter
> ---
> drivers/gpu/drm/exynos/exynos_drm_drv.c | 8
> 1 file changed, 4 insertions(+), 4 deletion
2016년 04월 27일 02:29에 Daniel Vetter 이(가) 쓴 글:
> No dev->struct_mutex anywhere to be seen.
Acked-by: Inki Dae
Thanks,
Inki Dae
>
> Cc: Inki Dae
> Signed-off-by: Daniel Vetter
> ---
> drivers/gpu/drm/exynos/exynos_drm_drv.c | 2 +-
> 1 file changed, 1 insertion(+),
w yet. Picked it up.
Thanks,
Inki Dae
>
> Cc: Inki Dae
> Signed-off-by: Daniel Vetter
> ---
> drivers/gpu/drm/exynos/exynos_drm_fb.c | 11 ---
> 1 file changed, 11 deletions(-)
>
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_fb.c
> b/drivers/gpu/d
Hi Daniel,
It seems your patch is exactly same as below my one I posted before,
http://www.spinics.net/lists/dri-devel/msg97922.html
Anyway, it's ok if this patch can go to mainline.
Acked-by: Inki Dae
2016년 01월 12일 06:41에 Daniel Vetter 이(가) 쓴 글:
> The core takes care of this now. A
Hi, Daniel. You can repost your patch set including the below my patch. And
my patch numbering is wrong. Sorry about that.
[PATCH 1/4] -> [PATCH 4/4]
Thanks,
Inki Dae
> -Original Message-
> From: Inki Dae [mailto:inki@samsung.com]
> Sent: Thursday, August 08, 2013 1:40
Signed-off-by: Inki Dae
Signed-off-by: Kyungmin Park
---
drivers/gpu/drm/exynos/exynos_drm_dmabuf.c | 12
1 files changed, 8 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_dmabuf.c
b/drivers/gpu/drm/exynos/exynos_drm_dmabuf.c
index 3cd56e1..fd76449
> -Original Message-
> From: Daniel Vetter [mailto:daniel.vet...@ffwll.ch] On Behalf Of Daniel
> Vetter
> Sent: Thursday, August 08, 2013 8:21 AM
> To: Inki Dae
> Cc: Daniel Vetter; Intel Graphics Development; DRI Development
> Subject: Re: [PATCH
2013/8/7 Daniel Vetter
> On Wed, Aug 7, 2013 at 2:01 PM, Inki Dae wrote:
> >
> >
> > 2013/8/7 Daniel Vetter
> >>
> >> On Wed, Aug 07, 2013 at 07:18:45PM +0900, Joonyoung Shim wrote:
> >> > On 08/07/2013 06:55 PM, Daniel Vetter wrote:
> &g
2013/8/7 Daniel Vetter
> On Wed, Aug 07, 2013 at 07:18:45PM +0900, Joonyoung Shim wrote:
> > On 08/07/2013 06:55 PM, Daniel Vetter wrote:
> > >On Wed, Aug 7, 2013 at 11:40 AM, Inki Dae wrote:
> > >>>-Original Message-
> > >>>Fr
> -Original Message-
> From: Daniel Vetter [mailto:daniel.vet...@ffwll.ch]
> Sent: Wednesday, August 07, 2013 6:15 PM
> To: DRI Development
> Cc: Intel Graphics Development; Daniel Vetter; Inki Dae
> Subject: [PATCH 1/3] drm: use common drm_gem_dmabuf_release in i91
> -Original Message-
> From: Daniel Vetter [mailto:daniel.vet...@ffwll.ch]
> Sent: Tuesday, July 16, 2013 4:12 PM
> To: DRI Development
> Cc: Daniel Vetter; Inki Dae; Laurent Pinchart; Intel Graphics Development;
> Ben Skeggs; Rob Clark; Alex Deucher
> Subject:
2012/12/14 Daniel Vetter
> On Thu, Dec 13, 2012 at 4:16 PM, Inki Dae wrote:
> > How about rebasing this patch to top of
> > git://people.freedesktop.org/~airlied/linux.git drm-next?
> > Exynos's many patches have already been merged to drm-next. Or if you are
>
,
How about rebasing this patch to top of git://
people.freedesktop.org/~airlied/linux.git drm-next?
Exynos's many patches have already been merged to drm-next. Or if you are
ok, I'd like to rebase your patch to -next and test it. I don't care either
way. :)
If there is any problem, please let
per sets up need to be overwritten anyway
> again due to the multiple backing storage objects support exynos has,
> but does not use for the fbdev.
>
Hi Daniel,
I'd rebase this patch to -next. This patch is conflicted with -next.
And if there is no any problem after test, will appl
2012/11/8 Rob Clark
> On Wed, Nov 7, 2012 at 10:25 AM, Inki Dae wrote:
> >
> >
> > 2012/11/7 Imre Deak
> >>
> >> On Wed, 2012-11-07 at 18:31 +0900, Inki Dae wrote:
> >> > 2012/11/2 Imre Deak
> >> >
2012/11/7 Imre Deak
> On Wed, 2012-11-07 at 18:31 +0900, Inki Dae wrote:
> > 2012/11/2 Imre Deak
> > The patchset adds the missing event_lock when accessing the
> > vblank_event_list in drm_vblank_off() and as preparation for
> > this
> &g
Hi Imre,
Works fine. But we should wait for Rob's patch set to be merged to -next,
and this may be rebased on top of latest Rob's patch set again.
Thanks,
Inki Dae
> In v2:
> - Instead of fixing the event_lock vs. vblank_time_lock lockdep issue in
> drm_handle_vblank(), fi
to plane->format_types[n]; otherwise, could
you please tell me about the purpose that format_types[] and format_count are
used?
Thank you,
Inki Dae.
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Hi, Jesse.
Jesse Barnes virtuousgeek.org> writes:
>
> On Mon, 31 Oct 2011 11:40:57 + (UTC)
> Inki Dae gmail.com> wrote:
> > below is my simple idea.
> > 1. user requests buffer allocation with pixel format and resolution
through
> > gem framework.
ser gets the gem handle from gem framework.
5. user sets the gem handle to specific drm framebuffer through
drm_mode_addfb2 function.
6. user requests setcrtc with fb id and crtc id.
7. drm framework sets framebuffer(corresponding to fb id) to drm_mode_set.
8. crtc calls set_config callbac
34 matches
Mail list logo
