2013/10/3 Sean Paul seanp...@chromium.org:
On Thu, Oct 3, 2013 at 9:55 AM, Inki Dae inki@samsung.com wrote:
Hi, thank you for your contribution and the below is my short comments,
2013/10/2 Sean Paul seanp...@chromium.org:
This patch adds a drm_bridge driver for the PTN3460 DisplayPort
2013/10/4 Sean Paul seanp...@chromium.org:
On Thu, Oct 3, 2013 at 1:18 PM, Inki Dae inki@samsung.com wrote:
2013/10/4 Sean Paul seanp...@chromium.org:
On Thu, Oct 3, 2013 at 10:43 AM, Inki Dae inki@samsung.com wrote:
2013/10/2 Sean Paul seanp...@chromium.org:
This patch adds code
2013/10/4 Sean Paul seanp...@chromium.org:
On Thu, Oct 3, 2013 at 1:39 PM, Inki Dae inki@samsung.com wrote:
2013/10/3 Sean Paul seanp...@chromium.org:
On Thu, Oct 3, 2013 at 9:55 AM, Inki Dae inki@samsung.com wrote:
Hi, thank you for your contribution and the below is my short comments
2013/10/4 Sean Paul seanp...@chromium.org:
On Thu, Oct 3, 2013 at 2:23 PM, Inki Dae inki@samsung.com wrote:
2013/10/4 Sean Paul seanp...@chromium.org:
On Thu, Oct 3, 2013 at 1:39 PM, Inki Dae inki@samsung.com wrote:
2013/10/3 Sean Paul seanp...@chromium.org:
On Thu, Oct 3, 2013 at 9
2013/10/4 Olof Johansson o...@lixom.net:
On Thu, Oct 3, 2013 at 10:39 AM, Inki Dae inki@samsung.com wrote:
2013/10/3 Sean Paul seanp...@chromium.org:
On Thu, Oct 3, 2013 at 9:55 AM, Inki Dae inki@samsung.com wrote:
Can a regulator be used instead of gpio in other board case
2013/10/4 Sean Paul seanp...@chromium.org:
This patch adds code to look for the ptn3460 in the device tree file on
exynos initialization. If ptn node is found, the driver will initialize
the ptn3460 driver and skip creating a DP connector (since the bridge
driver will register its own
2013/10/4 Sean Paul seanp...@chromium.org:
On Thu, Oct 3, 2013 at 10:29 PM, Inki Dae inki@samsung.com wrote:
2013/10/4 Sean Paul seanp...@chromium.org:
This patch adds code to look for the ptn3460 in the device tree file on
exynos initialization. If ptn node is found, the driver
> -Original Message-
> From: Geert Uytterhoeven [mailto:ge...@linux-m68k.org]
> Sent: Thursday, September 05, 2013 5:21 PM
> To: David Herrmann; H. Peter Anvin
> Cc: Inki Dae; David Airlie; Geoff Levand; dri-de...@lists.freedesktop.org;
> linux-fb...@vger.kernel
-Original Message-
From: Geert Uytterhoeven [mailto:ge...@linux-m68k.org]
Sent: Thursday, September 05, 2013 5:21 PM
To: David Herrmann; H. Peter Anvin
Cc: Inki Dae; David Airlie; Geoff Levand; dri-de...@lists.freedesktop.org;
linux-fb...@vger.kernel.org; linux-kernel
> -Original Message-
> From: Antonios Motakis [mailto:a.mota...@virtualopensystems.com]
> Sent: Tuesday, July 23, 2013 9:05 PM
> To: Inki Dae
> Cc: Linux ARM Kernel; Linux IOMMU; Linux Samsung SOC; kvm-arm; Cho
KyongHo;
> Joerg Roedel; Sachin Kamat; Jiri Kosina; Wei
> -Original Message-
> From: Antonios Motakis [mailto:a.mota...@virtualopensystems.com]
> Sent: Tuesday, July 23, 2013 8:00 PM
> To: Inki Dae
> Cc: Linux ARM Kernel; Linux IOMMU; Linux Samsung SOC; kvm-arm; Cho
KyongHo;
> Joerg Roedel; Sachin Kamat; Jiri Kosina; Wei
't have any meaning we have to use
iommu group feature. I think the implementation should be one more devices
per a group. So I guess a given device object should be wrapped by higher
device object than the given device object. For a good example, you can
refer to intel-iommu.c file.
Thanks,
a given device object should be wrapped by higher
device object than the given device object. For a good example, you can
refer to intel-iommu.c file.
Thanks,
Inki Dae
+ if (IS_ERR(group)) {
+ dev_err(dev, Failed to allocate IOMMU group\n);
+ return PTR_ERR(group
-Original Message-
From: Antonios Motakis [mailto:a.mota...@virtualopensystems.com]
Sent: Tuesday, July 23, 2013 8:00 PM
To: Inki Dae
Cc: Linux ARM Kernel; Linux IOMMU; Linux Samsung SOC; kvm-arm; Cho
KyongHo;
Joerg Roedel; Sachin Kamat; Jiri Kosina; Wei Yongjun; open list
Subject
-Original Message-
From: Antonios Motakis [mailto:a.mota...@virtualopensystems.com]
Sent: Tuesday, July 23, 2013 9:05 PM
To: Inki Dae
Cc: Linux ARM Kernel; Linux IOMMU; Linux Samsung SOC; kvm-arm; Cho
KyongHo;
Joerg Roedel; Sachin Kamat; Jiri Kosina; Wei Yongjun; open list; Alex
> -Original Message-
> From: linux-kernel-ow...@vger.kernel.org [mailto:linux-kernel-
> ow...@vger.kernel.org] On Behalf Of Russell King - ARM Linux
> Sent: Monday, April 29, 2013 6:52 PM
> To: Inki Dae
> Cc: gre...@linuxfoundation.org; linux-kernel@vger.ker
Hi,
> -Original Message-
> From: linux-kernel-ow...@vger.kernel.org [mailto:linux-kernel-
> ow...@vger.kernel.org] On Behalf Of Uwe Kleine-Konig
> Sent: Monday, April 29, 2013 4:35 PM
> To: Inki Dae
> Cc: gre...@linuxfoundation.org; linux-kernel@vger.ker
Hi,
-Original Message-
From: linux-kernel-ow...@vger.kernel.org [mailto:linux-kernel-
ow...@vger.kernel.org] On Behalf Of Uwe Kleine-Konig
Sent: Monday, April 29, 2013 4:35 PM
To: Inki Dae
Cc: gre...@linuxfoundation.org; linux-kernel@vger.kernel.org; dri-
de
-Original Message-
From: linux-kernel-ow...@vger.kernel.org [mailto:linux-kernel-
ow...@vger.kernel.org] On Behalf Of Russell King - ARM Linux
Sent: Monday, April 29, 2013 6:52 PM
To: Inki Dae
Cc: gre...@linuxfoundation.org; linux-kernel@vger.kernel.org; dri-
de
by type
argument because the definition of 'of_device_id' should be fixed.
So this patch makes 'of_devce_id' definition to be fixed and
only its instance name to be defined by type.
Signed-off-by: Inki Dae
---
include/linux/module.h |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff
by type
argument because the definition of 'of_device_id' should be fixed.
So this patch makes 'of_devce_id' definition to be fixed and
only its instance name to be defined by type.
Signed-off-by: Inki Dae inki@samsung.com
---
include/linux/module.h |2 +-
1 files changed, 1 insertions(+), 1
Applied.
Thanks,
Inki Dae
2013/3/12 Alexandru Gheorghiu :
> Replaced calls to kzalloc followed by memcpy with call to kmemdup.
> Patch found using coccinelle.
>
> Signed-off-by: Alexandru Gheorghiu
> ---
> drivers/gpu/drm/exynos/exynos_drm_vidi.c |6 ++
> 1 file
Applied.
Thanks,
Inki Dae
2013/3/12 Alexandru Gheorghiu gheorghiuan...@gmail.com:
Replaced calls to kzalloc followed by memcpy with call to kmemdup.
Patch found using coccinelle.
Signed-off-by: Alexandru Gheorghiu gheorghiuan...@gmail.com
---
drivers/gpu/drm/exynos/exynos_drm_vidi.c
two more devices. So I guess that the
fence_excl could be used for write access(may need buffer sync like
blocking) and read access for the fence_shared(may not need buffer
sync). I'm not sure that I understand these two things correctly so
could you please give me more comments for them?
Thanks,
Inki
comments for them?
Thanks,
Inki Dae
+ fence_get(fence);
+
+ mutex_unreserve_unlock(bo-lock);
+ }
+ reservation_ticket_fini(ticket);
+}
+EXPORT_SYMBOL(ticket_commit);
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body
2013/1/31 Daniel Vetter :
> On Thu, Jan 31, 2013 at 06:32:15PM +0900, Inki Dae wrote:
>> Hi,
>>
>> below is my opinion.
>>
>> > +struct fence;
>> > +struct fence_ops;
>> > +struct fence_cb;
>> > +
>> > +/**
>> > +
E_FLAG_ACCESS_WRITE_BIT as write
operation and then other sides(read or write operation) would wait for
the write operation completion.
And also consumer calls that function with FENCE_FLAG_ACCESS_READ_BIT
so that other consumers could ignore the fence-wait to any read
operations.
Thanks,
Inki Dae
with FENCE_FLAG_ACCESS_READ_BIT
so that other consumers could ignore the fence-wait to any read
operations.
Thanks,
Inki Dae
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
2013/1/31 Daniel Vetter dan...@ffwll.ch:
On Thu, Jan 31, 2013 at 06:32:15PM +0900, Inki Dae wrote:
Hi,
below is my opinion.
+struct fence;
+struct fence_ops;
+struct fence_cb;
+
+/**
+ * struct fence - software synchronization primitive
+ * @refcount: refcount for this fence
2013/1/16 Maarten Lankhorst :
> Op 16-01-13 07:28, Inki Dae schreef:
>> 2013/1/15 Maarten Lankhorst :
>>> This type of fence can be used with hardware synchronization for simple
>>> hardware that can block execution until the condition
>>> (dma_bu
2013/1/16 Maarten Lankhorst maarten.lankho...@canonical.com:
Op 16-01-13 07:28, Inki Dae schreef:
2013/1/15 Maarten Lankhorst m.b.lankho...@gmail.com:
This type of fence can be used with hardware synchronization for simple
hardware that can block execution until the condition
(dma_buf[offset
Checked it out and applied. For ARCH_MULTIPLATFORM support, Such
header files shouldn't be included. And for this, we are planning on
supporting device tree for ipp driver.
Thanks,
Inki Dae
2013/1/22 Arnd Bergmann :
> While the exynos DRM support in principle can work on
> multipl
Checked it out and applied. For ARCH_MULTIPLATFORM support, Such
header files shouldn't be included. And for this, we are planning on
supporting device tree for ipp driver.
Thanks,
Inki Dae
2013/1/22 Arnd Bergmann a...@arndb.de:
While the exynos DRM support in principle can work
2013/1/16 Maarten Lankhorst :
> Op 16-01-13 07:28, Inki Dae schreef:
>> 2013/1/15 Maarten Lankhorst :
>>> This type of fence can be used with hardware synchronization for simple
>>> hardware that can block execution until the condition
>>> (dma_bu
2013/1/16 Maarten Lankhorst maarten.lankho...@canonical.com:
Op 16-01-13 07:28, Inki Dae schreef:
2013/1/15 Maarten Lankhorst m.b.lankho...@gmail.com:
This type of fence can be used with hardware synchronization for simple
hardware that can block execution until the condition
(dma_buf[offset
er *fh, int id);
- This function is called by device's interrupt handler or somewhere
when dma access to this buffer has been completed and calls
fence_signal() with each fence registed to each reservation object in
fh->entries to notify dma access completion to other deivces. At this
time, other d
in fh-entries.
- release each seqno_fence_dmabuf object in seqno_fence's
sync_buf_list and call dma_buf_put() to put the reference count to
dmabuf.
Now the fence-helper framework is just WIP yet so there may be my
missing points. If you are ok, I'd like to post it as RFC.
Thanks,
Inki Dae
_space_size,
> > priv->da_space_order);
> > - if (!mapping)
> > + if (IS_ERR(mapping))
> > return -ENOMEM;
>
> One more fix is needed here.
> -
;
One more fix is needed here.
- return -ENOMEM;
+ return PTR_ERR(mapping);
Oh, good point, I missed. Please re-send it.
Thanks,
Inki Dae
dev-dma_parms = devm_kzalloc(dev, sizeof(*dev-dma_parms),
___
dri-devel
Hi Hiroshi,
2012. 10. 16. 오후 11:13 Hiroshi Doyu 작성:
> Hi Inki,
>
> Inki Dae wrote @ Tue, 16 Oct 2012 12:12:49 +0200:
>
>> Hi Hiroshi,
>>
>> 2012/10/16 Hiroshi Doyu :
>>> Hi Inki/Marek,
>>>
>>> On Tue, 16 Oct 2012 02:50:16 +0200
&
Hi Russell,
2012/10/16 Russell King - ARM Linux :
> On Tue, Oct 16, 2012 at 07:12:49PM +0900, Inki Dae wrote:
>> Hi Hiroshi,
>>
>> I'm not sure I understand what you mean but we had already tried this
>> way and for this, you can refer to below link,
>>
Hi Hiroshi,
2012/10/16 Hiroshi Doyu :
> Hi Inki/Marek,
>
> On Tue, 16 Oct 2012 02:50:16 +0200
> Inki Dae wrote:
>
>> 2012/10/15 Marek Szyprowski :
>> > Hello,
>> >
>> > Some devices, which have IOMMU, for some use cases might require to
>
Hi Hiroshi,
2012/10/16 Hiroshi Doyu hd...@nvidia.com:
Hi Inki/Marek,
On Tue, 16 Oct 2012 02:50:16 +0200
Inki Dae inki@samsung.com wrote:
2012/10/15 Marek Szyprowski m.szyprow...@samsung.com:
Hello,
Some devices, which have IOMMU, for some use cases might require to
allocate
Hi Russell,
2012/10/16 Russell King - ARM Linux li...@arm.linux.org.uk:
On Tue, Oct 16, 2012 at 07:12:49PM +0900, Inki Dae wrote:
Hi Hiroshi,
I'm not sure I understand what you mean but we had already tried this
way and for this, you can refer to below link,
http://www.mail
Hi Hiroshi,
2012. 10. 16. 오후 11:13 Hiroshi Doyu hd...@nvidia.com 작성:
Hi Inki,
Inki Dae inki@samsung.com wrote @ Tue, 16 Oct 2012 12:12:49 +0200:
Hi Hiroshi,
2012/10/16 Hiroshi Doyu hd...@nvidia.com:
Hi Inki/Marek,
On Tue, 16 Oct 2012 02:50:16 +0200
Inki Dae inki
mode should be physically
contiguous and also maybe OMAP but now dma-mapping framework doesn't
guarantee physically continuous memory allocation so this patch set
would make it possible.
Tested-by: Inki Dae
Reviewed-by: Inki Dae
Thanks,
Inki Dae
> Best regards
> --
> Marek Szyprowski
>
contiguous and also maybe OMAP but now dma-mapping framework doesn't
guarantee physically continuous memory allocation so this patch set
would make it possible.
Tested-by: Inki Dae inki@samsung.com
Reviewed-by: Inki Dae inki@samsung.com
Thanks,
Inki Dae
Best regards
--
Marek Szyprowski
Applied.
Thanks,
Inki Dae
2012/9/7 Mandeep Singh Baines :
> The double invocations are incorrect but seem to be safe so I don't
> think this will fix any bugs.
>
> Before:
>
> [7.639366] drm_prime_init_file ee3675d0
> [7.639377] drm_prime_init_file ee3
Hi,
2012/9/6 Paul Menzel :
> Dear Inki Dae,
>
>
> Am Donnerstag, den 06.09.2012, 11:35 +0900 schrieb InKi Dae:
>
>> 2012/9/6 Mandeep Singh Baines :
>> > The double invocations are incorrect but seem to be safe so I don't
>> > think this will fix any bugs.
&g
Hi,
2012/9/6 Paul Menzel paulepan...@users.sourceforge.net:
Dear Inki Dae,
Am Donnerstag, den 06.09.2012, 11:35 +0900 schrieb InKi Dae:
2012/9/6 Mandeep Singh Baines m...@chromium.org:
The double invocations are incorrect but seem to be safe so I don't
think this will fix any bugs
Applied.
Thanks,
Inki Dae
2012/9/7 Mandeep Singh Baines m...@chromium.org:
The double invocations are incorrect but seem to be safe so I don't
think this will fix any bugs.
Before:
[7.639366] drm_prime_init_file ee3675d0
[7.639377] drm_prime_init_file ee3675d0
[7.639507
t;
> [6.363842] drm_prime_init_file edc2e5d0
> [6.363994] drm_prime_destroy_file edc2e5d0
> [6.364260] drm_prime_init_file edc2e750
> [8.004837] drm_prime_init_file ee36ded0
>
> Signed-off-by: Mandeep Singh Baines
> CC: Stéphane Marchesin
> CC: Pawel Osciak
> CC: Ink
[6.363994] drm_prime_destroy_file edc2e5d0
[6.364260] drm_prime_init_file edc2e750
[8.004837] drm_prime_init_file ee36ded0
Signed-off-by: Mandeep Singh Baines m...@chromium.org
CC: Stéphane Marchesin marc...@chromium.org
CC: Pawel Osciak posc...@google.com
CC: Inki Dae inki@samsung.com
> -Original Message-
> From: Thomas Meyer [mailto:tho...@m3y3r.de]
> Sent: Tuesday, August 07, 2012 3:57 PM
> To: inki@samsung.com; jy0922.s...@samsung.com; sw0312@samsung.com;
> kyungmin.p...@samsung.com; airl...@linux.ie; dri-
> de...@lists.freedesktop.org;
-Original Message-
From: Thomas Meyer [mailto:tho...@m3y3r.de]
Sent: Tuesday, August 07, 2012 3:57 PM
To: inki@samsung.com; jy0922.s...@samsung.com; sw0312@samsung.com;
kyungmin.p...@samsung.com; airl...@linux.ie; dri-
de...@lists.freedesktop.org;
301 - 355 of 355 matches
Mail list logo
