add Mr. Dae
On Thu, May 22, 2014 at 11:16 PM, Rahul Sharma
wrote:
> Hi Inki,
>
> This is another one which has not got reviewed. Please review.
>
> Regards,
> Rahul Sharma
>
> On 30 April 2014 19:11, Rahul Sharma wrote:
>> From: Rahul Sharma
>>
>> While testing S2R on exynos board, system is h
'm
> > > pointing out is that you're removing proper attribution from Chrome OS
> > > patches, and this is the second time it has happened.
>
First, we don't know what's going on Chrome OS. probably you think we refer
your codes. but we don't know chrome c
'm
> > > pointing out is that you're removing proper attribution from Chrome OS
> > > patches, and this is the second time it has happened.
>
First, we don't know what's going on Chrome OS. probably you think we refer
your codes. but we don't know chrome c
Hi,
I don't think it's not required, each tree has each own mailing list. don't
need to post all patches to samsung-soc list.
Thank you,
Kyungmin Park
On Mon, Apr 22, 2013 at 4:20 AM, Tomasz Figa wrote:
> Several entries in MAINTAINERS file related to Samsung SoCs do no
Hi,
I don't think it's not required, each tree has each own mailing list. don't
need to post all patches to samsung-soc list.
Thank you,
Kyungmin Park
On Mon, Apr 22, 2013 at 4:20 AM, Tomasz Figa wrote:
> Several entries in MAINTAINERS file related to Samsung SoCs do no
r. The driver uses 4210 and
>> 4212 to differentiate between different register addresses and
>> features, but most things are just exynos4-hdmi compatible.
I would like to distinguish between 4210 and 4x12. since it has
different features. e.g., HDMI v1.3 and v1.4.
and I also want to us
driver uses 4210 and
>> 4212 to differentiate between different register addresses and
>> features, but most things are just exynos4-hdmi compatible.
I would like to distinguish between 4210 and 4x12. since it has
different features. e.g., HDMI v1.3 and v1.4.
and I also want to use 4412
d for this one too.
>>
>>> And please check if exynos4212 and 4412 SoCs have same fimg-2d ip. If it's
>>> different, we might need to add ip version property or compatible string to
>>> each dtsi file to identify the ip version.
>>
>> AFAIK, they both
gt;>
>>> And please check if exynos4212 and 4412 SoCs have same fimg-2d ip. If it's
>>> different, we might need to add ip version property or compatible string to
>>> each dtsi file to identify the ip version.
>>
>> AFAIK, they both have the same IP
and 16 words where each word is 8 bytes long.
Interesting, BTW can you describe the problem? what's the issue and
why this patch is needed?
does it improve the performance or reduce the fimd bandwidth?
Thank you,
Kyungmin Park
>
> Signed-off-by: Prathyush K
> ---
> drivers/gpu
Hi,
To get the proper review, please add proper maintainers.
Thank you,
Kyungmin Park
On Tue, Nov 20, 2012 at 8:55 PM, Rahul Sharma wrote:
> Hi All,
>
> Kindly review the following patch-set.
>
> regards,
> Rahul Sharma
>
> On Fri, Nov 9, 2012 at 9:51 PM, Rahul Sharma
On 11/20/12, Prathyush K wrote:
> On Mon, Nov 19, 2012 at 3:14 PM, Kyungmin Park
> wrote:
>
>> Hi,
>>
>> On 11/15/12, Prathyush K wrote:
>> > The 'pages' structure is not required since we can use the 'sgt'. Even
>> for
>> >
and 16 words where each word is 8 bytes long.
Interesting, BTW can you describe the problem? what's the issue and
why this patch is needed?
does it improve the performance or reduce the fimd bandwidth?
Thank you,
Kyungmin Park
>
> Signed-off-by: Prathyush K
> ---
> drivers/gpu/drm/ex
Hi,
To get the proper review, please add proper maintainers.
Thank you,
Kyungmin Park
On Tue, Nov 20, 2012 at 8:55 PM, Rahul Sharma wrote:
> Hi All,
>
> Kindly review the following patch-set.
>
> regards,
> Rahul Sharma
>
> On Fri, Nov 9, 2012 at 9:51 PM, Rahul Sharma
On 11/20/12, Prathyush K wrote:
> On Mon, Nov 19, 2012 at 3:14 PM, Kyungmin Park
> wrote:
>
>> Hi,
>>
>> On 11/15/12, Prathyush K wrote:
>> > The 'pages' structure is not required since we can use the 'sgt'. Even
>> for
>> >
ma->vm_flags |= VM_IO | VM_DONTEXPAND | VM_DONTDUMP;
How do you sure VM_MIXEDMAP is not required?
> +
> + vm_size = vma->vm_end - vma->vm_start;
> +
> + if (vm_size > buffer->size)
> + return -EINVAL;
does it really happended?
Thank you,
Kyungmin Par
DRM_ERROR("invalid page offset\n");
> - return -EINVAL;
> - }
> + if (!buf->sgt)
> + return -EINTR;
>
> - pfn = __phys_to_pfn(sg_phys(sgl)) + page_offset;
> - } else {
> - if (!buf->pa
ma->vm_flags |= VM_IO | VM_DONTEXPAND | VM_DONTDUMP;
How do you sure VM_MIXEDMAP is not required?
> +
> + vm_size = vma->vm_end - vma->vm_start;
> +
> + if (vm_size > buffer->size)
> + return -EINVAL;
does it really happended?
Thank you,
Kyungmin Par
DRM_ERROR("invalid page offset\n");
> - return -EINVAL;
> - }
> + if (!buf->sgt)
> + return -EINTR;
>
> - pfn = __phys_to_pfn(sg_phys(sgl)) + page_offset;
> - } else {
> - if (!buf->pa
;> - simplify error handling in vb2_dc_get_dmabuf (from Laurent Pinchart)
>
> For now, NACK. See below.
Sad news!
It's failed to merge by very poor samsung board support at mainline.
CC arm & samsung mailing list.
Thank you,
Kyungmin Park
>
> I spent 4 days trying to setup a
;> - simplify error handling in vb2_dc_get_dmabuf (from Laurent Pinchart)
>
> For now, NACK. See below.
Sad news!
It's failed to merge by very poor samsung board support at mainline.
CC arm & samsung mailing list.
Thank you,
Kyungmin Park
>
> I spent 4 days trying to setup a
To Mr. Shim,
Can you check these patch series?
Thank you,
Kyungmin Park
On 9/28/12, Rahul Sharma wrote:
> This patch set adds the DT based support for Samsung's Exynos5250 in
> DRM-HDMI.
> It includes disabling of hdmi internal interrupt, suppport for platform
> variants f
To Mr. Shim,
Can you check these patch series?
Thank you,
Kyungmin Park
On 9/28/12, Rahul Sharma wrote:
> This patch set adds the DT based support for Samsung's Exynos5250 in
> DRM-HDMI.
> It includes disabling of hdmi internal interrupt, suppport for platform
> variants f
imd or fb?. I think 'fb' is used
for framebuffer historically.
but now it's used both fb and drm, so fimd is neutral and architecture
specific.
To do this, Modify arch-exynos first and update it at each drivers it properly.
Thank you,
Kyungmin Park
> + fimd using DRM fra
imd or fb?. I think 'fb' is used
for framebuffer historically.
but now it's used both fb and drm, so fimd is neutral and architecture
specific.
To do this, Modify arch-exynos first and update it at each drivers it properly.
Thank you,
Kyungmin Park
> + fimd using DRM fra
Hi,
I bet 1st option. And configure it at user space. IOW set the proper ALSA
kcontrol. And set the proper DRM audio config by IOCTL..
Any other opinions?
Thank you,
Kyungmin Park
From: RAHUL SHARMA [mailto:rahul.sha...@samsung.com]
Sent: Thursday, July 19, 2012 6:57 PM
To: dri-devel at
_dt_parse_pdata(&pdev->dev);
> + if (IS_ERR(pdata))
> + return PTR_ERR(pdata);
> + }
> if (!pdata) {
> dev_err(dev, "no platform data specified\n");
> return -EINVAL;
> @@ -
_dt_parse_pdata(&pdev->dev);
> + if (IS_ERR(pdata))
> + return PTR_ERR(pdata);
> + }
> if (!pdata) {
> dev_err(dev, "no platform data specified\n");
> return -EINVAL;
> @@ -
locked
>>>>>> when the pages are released.
>>>>>>
>>>>>> but this lock might result in significant degradation of system
>>>>> performance
>>>>>> because the pages couldn't be swapped out so we limit user-d
;>>>> malloc()
>>>>> or
>>>>>> mmaped into a gem. and to guarantee the pages to user space not to be
>>>>>> swapped out, the VMAs within the user space would be locked and then
>>>>> unlocked
>>>>>> when
xynos_map_dmabuf(struct
> dma_buf_attachment *attach,
>
> buffer = exynos_gem_obj->buffer;
>
> - /* TODO. consider physically non-continuous memory with IOMMU. */
> + size = buffer->size;
> + n_pages = PAGE_ALIGN(size) >> PAGE_SHIFT;
>
> -
xynos_map_dmabuf(struct
> dma_buf_attachment *attach,
>
> buffer = exynos_gem_obj->buffer;
>
> - /* TODO. consider physically non-continuous memory with IOMMU. */
> + size = buffer->size;
> + n_pages = PAGE_ALIGN(size) >> PAGE_SHIFT;
>
> -
Hi Tomasz,
How about to add this program to tools directory? tools/drm or tools/media?
Thank you,
Kyungmin Park
On Wed, Apr 11, 2012 at 1:13 AM, Tomasz Stanislawski
wrote:
> Hi Everyone,
> This email contains a test application showing DMABUF sharing
> between DRM/KMS display and cap
Hi Tomasz,
How about to add this program to tools directory? tools/drm or tools/media?
Thank you,
Kyungmin Park
On Wed, Apr 11, 2012 at 1:13 AM, Tomasz Stanislawski
wrote:
> Hi Everyone,
> This email contains a test application showing DMABUF sharing
> between DRM/KMS display and cap
+ V4L2 develper
Sylwester, please give your opinions? How to handle it at v4l2 side.
Thank you,
Kyungmin Park
On Apr 6, 2012 12:44 AM, "Ville Syrj?l?" wrote:
> On Fri, Apr 06, 2012 at 03:05:36PM +0900, Inki Dae wrote:
> > Hi Ville,
> >
> > > -Original Mes
+ V4L2 develper
Sylwester, please give your opinions? How to handle it at v4l2 side.
Thank you,
Kyungmin Park
On Apr 6, 2012 12:44 AM, "Ville Syrjälä" wrote:
> On Fri, Apr 06, 2012 at 03:05:36PM +0900, Inki Dae wrote:
> > Hi Ville,
> >
> > > -Original Mess
/prime support has already been reviewed
> by a lot of folks, and tested with a few different drivers (exynos,
> omapdrm, i915, nouveau, udl) with some driver support that could be
> pushed for 3.5 cycle if the core support makes it in for 3.4 cycle.
Yes,
/prime support has already been reviewed
> by a lot of folks, and tested with a few different drivers (exynos,
> omapdrm, i915, nouveau, udl) with some driver support that could be
> pushed for 3.5 cycle if the core support makes it in for 3.4 cycle.
Yes,
Reviewed-by: Kyungmin Park
On 3/17/12, Rob Clark wrote:
> From: Rob Clark
>
> Works in a similar way to get_file(), and is needed in cases such as
> when the exporter needs to also keep a reference to the dmabuf (that
> is later released with a dma_buf_put()), and possibl
Reviewed-by: Kyungmin Park
On 3/17/12, Rob Clark wrote:
> From: Rob Clark
>
> Works in a similar way to get_file(), and is needed in cases such as
> when the exporter needs to also keep a reference to the dmabuf (that
> is later released with a dma_buf_put()), and possibl
Hi,
Also you can find relevant patches at git
http://git.infradead.org/users/kmpark/linux-samsung/shortlog/refs/heads/samsung-drm
To Mr. Dae.
Can you rebase the latest drm-next tree or mainline to merge easily?
Thank you,
Kyungmin Park
On 11/12/11, Inki Dae wrote:
> Hello, Dave. sorry
Hi,
Also you can find relevant patches at git
http://git.infradead.org/users/kmpark/linux-samsung/shortlog/refs/heads/samsung-drm
To Mr. Dae.
Can you rebase the latest drm-next tree or mainline to merge easily?
Thank you,
Kyungmin Park
On 11/12/11, Inki Dae wrote:
> Hello, Dave. sorry
From: Kyungmin Park
As Exynos DRM is merged at mainline. Also update the maintainer entry.
Signed-off-by: Kyungmin Park
---
diff --git a/MAINTAINERS b/MAINTAINERS
index 5d6941f..1deeac9 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -2327,6 +2327,13 @@ S: Supported
F: drivers/gpu/drm
From: Kyungmin Park
As Exynos DRM is merged at mainline. Also update the maintainer entry.
Signed-off-by: Kyungmin Park
---
diff --git a/MAINTAINERS b/MAINTAINERS
index 5d6941f..1deeac9 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -2327,6 +2327,13 @@ S: Supported
F: drivers/gpu/drm
; Second, I think there could be use for a common low level display
> framework. Currently the lower level code (display HW handling, etc.)
> and higher level code (buffer management, policies, etc) seem to be
> usually tied together, like the fb framework or the drm. Granted, the
>
; Second, I think there could be use for a common low level display
> framework. Currently the lower level code (display HW handling, etc.)
> and higher level code (buffer management, policies, etc) seem to be
> usually tied together, like the fb framework or the drm. Granted, the
>
;> for that.
>>
>> The problem I'm seeing compared to other drivers is the following:
>>
>> Imagine for example that you have a disc driver that allocates temporary
>> memory out of the same DMA pool as the DRM driver.
>>
>> Now you have a video player that is a DRM client. It contains a security
>> flaw and is compromized by somebody trying to play a specially crafted video
>> stream. The video player starts to allocate gem buffers until it receives an
>> -ENOMEM. Then it stops allocating and does nothing.
>>
>> Now the system tries an important disc access (paging for example). This
>> fails, because the video player has exhausted all DMA memory and the disc
>> driver fails to allocate.
>>
>> The system is dead.
>>
>> The point is:
>>
>> If there is a chance that other drivers will use the same DMA/CMA pool as
>> the DRM driver, DRM must leave enough DMA/CMA memory for those drivers to
>> work.
>
> ah, ok, I get your point
>
>
>> The difference compared to other drm drivers:
>>
>> There are other drm drivers that work the same way, with a static allocator.
>> For example "via" and "sis". But those drivers completely claim the
>> resources they are using. Nobody else is expected to use VRAM / AGP.
>>
>> In the Samsung case, it's not clear to me whether the DMA/CMA pool *can* be
>> shared with other devices.
>> If it is, IMHO you must implement an allocation limit in DRM, if not, the
>> driver should probably be safe.
>
> It is possible to create a device private CMA pool.. ?although OTOH it
> might be desirable to let some other drivers (like v4l2) use buffers
> from the same pool..
That's the final goal. memory sharing among multimedia devices (v4l2),
display(fimd, hdmi), and 3D (mali).
currently mali drivers is tightly coupled with UMP and it's hard to
use the CMA. it's need to solve this issue also.
In case of multimedia drivers, it has fixed memory area as scenario
and display also has similar restriction. I don't expect DRI request
the more memory than CMA pool has.
>
> I'm not entirely sure what will happen w/ dma_alloc_coherent, etc, if
> the global CMA pool is exhausted.
The primary goal of CMA is guarantee the memory for multimedia. So if
other device use the multimedia CMA pool, it should release the used
memory. and it's hard to release the memory. it should has display CMA
pool and don't share the other multimedia devices CMA pool.
CMA can share the same CMA pool and specify the device usage which CMA
pool used.
>
> Marek? ?I guess you know what would happen?
He will comeback when 21 Sep.
Thank you,
Kyungmin Park
or that.
>>
>> The problem I'm seeing compared to other drivers is the following:
>>
>> Imagine for example that you have a disc driver that allocates temporary
>> memory out of the same DMA pool as the DRM driver.
>>
>> Now you have a video player that is a DRM client. It contains a security
>> flaw and is compromized by somebody trying to play a specially crafted video
>> stream. The video player starts to allocate gem buffers until it receives an
>> -ENOMEM. Then it stops allocating and does nothing.
>>
>> Now the system tries an important disc access (paging for example). This
>> fails, because the video player has exhausted all DMA memory and the disc
>> driver fails to allocate.
>>
>> The system is dead.
>>
>> The point is:
>>
>> If there is a chance that other drivers will use the same DMA/CMA pool as
>> the DRM driver, DRM must leave enough DMA/CMA memory for those drivers to
>> work.
>
> ah, ok, I get your point
>
>
>> The difference compared to other drm drivers:
>>
>> There are other drm drivers that work the same way, with a static allocator.
>> For example "via" and "sis". But those drivers completely claim the
>> resources they are using. Nobody else is expected to use VRAM / AGP.
>>
>> In the Samsung case, it's not clear to me whether the DMA/CMA pool *can* be
>> shared with other devices.
>> If it is, IMHO you must implement an allocation limit in DRM, if not, the
>> driver should probably be safe.
>
> It is possible to create a device private CMA pool.. although OTOH it
> might be desirable to let some other drivers (like v4l2) use buffers
> from the same pool..
That's the final goal. memory sharing among multimedia devices (v4l2),
display(fimd, hdmi), and 3D (mali).
currently mali drivers is tightly coupled with UMP and it's hard to
use the CMA. it's need to solve this issue also.
In case of multimedia drivers, it has fixed memory area as scenario
and display also has similar restriction. I don't expect DRI request
the more memory than CMA pool has.
>
> I'm not entirely sure what will happen w/ dma_alloc_coherent, etc, if
> the global CMA pool is exhausted.
The primary goal of CMA is guarantee the memory for multimedia. So if
other device use the multimedia CMA pool, it should release the used
memory. and it's hard to release the memory. it should has display CMA
pool and don't share the other multimedia devices CMA pool.
CMA can share the same CMA pool and specify the device usage which CMA
pool used.
>
> Marek? I guess you know what would happen?
He will comeback when 21 Sep.
Thank you,
Kyungmin Park
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
you please give
>> me
>> > more comments why display object should be considered for multiple
>> > instances? I am afraid there is any part I don't care.
>> >
>> > thank you.
>>
>> Just thinking hypothetically.. what if
t; me
>> > more comments why display object should be considered for multiple
>> > instances? I am afraid there is any part I don't care.
>> >
>> > thank you.
>>
>> Just thinking hypothetically.. what if some future device had two hdmi
>
CC Eric (freescale), Rob (TI) who working the DRM with other ARM SoCs.
As Dave mentioned, Please review Samsung DRM codes.
Thank you,
Kyungmin Park
-Original Message-
From: Dave Airlie [mailto:airl...@gmail.com]
Sent: Monday, August 29, 2011 11:27 PM
To: Inki Dae
Cc: airlied at
CC Eric (freescale), Rob (TI) who working the DRM with other ARM SoCs.
As Dave mentioned, Please review Samsung DRM codes.
Thank you,
Kyungmin Park
-Original Message-
From: Dave Airlie [mailto:airl...@gmail.com]
Sent: Monday, August 29, 2011 11:27 PM
To: Inki Dae
Cc: airl...@linux.ie
52 matches
Mail list logo
