This patch fixes the issue that when buffer allocation is requested
without iommu, the allocation is failed.
Without iommu, dma_alloc_attrs function allocates some memory region
and returns cpu address so this patch makes the cpu address to be set
to buf->kvaddr correctly.
Signed-off-by: Inki Dae
On Sun, Dec 23, 2012 at 6:31 AM, Borislav Petkov wrote:
> On Sun, Dec 23, 2012 at 01:22:12PM +0100, Borislav Petkov wrote:
>> Right, let me try that and report back.
>
> Yep, looks like reverting the above commit fixes it - the boston.com
> website loads just fine.
>
> Thanks.
>
> --
> Regards/Gru
Bypasses the mie for fimd by parsing the register and bit offset values
from "mie-bypass" node, if "mie-bypass" node is present in the dts file.
Signed-off-by: Leela Krishna Amudala
---
drivers/gpu/drm/exynos/exynos_drm_fimd.c | 55
1 file changed, 55 insertions(
Hi Terje,
I applied your patches on top of upstream 1224 kernel. Then I read the
codes. So here is my review comments(I use "git diff" to print out,
check below). I admit it's easy for me to not need to find the
corresponding lines in your 8 patch mails, but I've no idea whether it
is ok for you.
2012/12/24 Sachin Kamat
> This eliminates the need for explicit clk_put and makes the
> cleanup and exit path code simpler.
>
> Cc: Eunchul Kim
> Signed-off-by: Sachin Kamat
> ---
> drivers/gpu/drm/exynos/exynos_drm_fimc.c | 46
> ++---
> 1 files changed, 10 insertion
This patchset has more fixes for fixing more issues related to wait for vblank.
Patch 1: add mixer apply function
The mixer window enabled flag is being done in both exynos_drm_hdmi as
well as exynos_mixer. This patch moves the flag to one place and adds the
mixer apply function similar to
Currently, an enabled flag for each mixer window is being set
in both mixer and the common hdmi framework. This patch adds
an apply function in mixer and moves the enabled flag inside
the mixer. This is required to ensure the enabled flag is updated
by the resume flag during dpms.
Signed-off-by: P
This patch checks if vblank is enabled inside wait for vblank. If not
enabled, vblank is temporarily enabled before waiting and then disabled
afterwards. This ensures that the wait never times out.
Signed-off-by: Prathyush K
---
drivers/gpu/drm/exynos/exynos_drm_fimd.c | 12
1 file
From: Sean Paul
We should not finish a pageflip or set wait_for_vblank to zero
if a layer update is pending. This might result in a page fault or corruption
on screen. This patch adds a check in the irq handler to exit if a layer
update is pending. Also, calls layer_update only once per layer per
This patch adds a check in fimd_window_suspend to call win_disable
only if the window is enabled.
Signed-off-by: Prathyush K
---
drivers/gpu/drm/exynos/exynos_drm_fimd.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
b/drivers/
From: Akshu Agrawal
If any fimd channel was already active, initializing iommu will result
in a PAGE FAULT (e.g. u-boot could have turned on the display and
not disabled it before the kernel starts). This patch checks if any
channel is active before initializing iommu and disables it.
Signed-off
Before freeing a framebuffer, we call complete_scanout encoder
function which just calls wait for vblank of all the encoders.
This is not a very optimized method since a framebuffer might not
be in use by a crtc and we end up waiting for vblank unnecessarily.
Instead, this patch modifies the wait_
The wait_for_vblank interface is modified to the complete_scanout
function in hdmi. This inturn calls the complete_scanout mixer op.
This patch also adds the mixer_complete_scanout function.
Inside mixer_complete_scanout, we read the base register and shadow
register for each window and compare it
The wait_for_vblank interface is modified to the complete_scanout
function in fimd. This patch adds the fimd_complete_scanout function
Inside fimd_complete_scanout, we read the shadow register for each
window and compare it with the dma address of the framebuffer. If
the dma_address is in the shad
2012/12/26 Prathyush K
> From: Akshu Agrawal
>
> If any fimd channel was already active, initializing iommu will result
> in a PAGE FAULT (e.g. u-boot could have turned on the display and
> not disabled it before the kernel starts). This patch checks if any
> channel is active before initializin
Good patch set. will apply them after review and test.
Thanks,
Inki Dae
2012/12/26 Prathyush K
> This patchset has more fixes for fixing more issues related to wait for
> vblank.
>
> Patch 1: add mixer apply function
> The mixer window enabled flag is being done in both
> exynos_drm_hdm
Hi Vikas,
On Monday 24 December 2012 12:33:50 Vikas Sajjan wrote:
> On Wed, Dec 19, 2012 at 6:51 PM, Laurent Pinchart wrote:
> > On Friday 14 December 2012 16:27:26 Tomi Valkeinen wrote:
> >> Hi,
> >>
> >> I have been testing Common Display Framework on OMAP, and making changes
> >> that I've dis
https://bugzilla.kernel.org/show_bug.cgi?id=42787
Stephan Diestelhorst changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Kernel Version|3.0.0
https://bugzilla.kernel.org/show_bug.cgi?id=42787
--- Comment #3 from Stephan Diestelhorst
2012-12-26 12:40:46 ---
Created an attachment (id=89691)
--> (https://bugzilla.kernel.org/attachment.cgi?id=89691)
dmesg of flickering system
--
Configure bugmail: https://bugzilla.kernel.org/userp
Hi Michael
On Sat, Dec 1, 2012 at 3:54 AM, Michael Hasselmann
wrote:
> On Fri, 2012-09-28 at 23:51 +0200, Luc Verhaegen wrote:
>> We still have, i hope (depends on what the FOSDEM organizers have left
>> for us), 6 slots fully open: first come first serve, and the earlier
>> bird gets the nicer s
https://bugzilla.kernel.org/show_bug.cgi?id=50091
--- Comment #22 from schaefer.fr...@gmx.net 2012-12-26 17:34:22 ---
UPDATE:
I've tested with 3.8.0-rc1, and now I have a good chance that the system
starts.
The criticial point is shortly before the the KDE Desktop appears (near the end
of the
https://bugzilla.kernel.org/show_bug.cgi?id=50091
--- Comment #23 from schaefer.fr...@gmx.net 2012-12-26 17:35:26 ---
Maybe I should add: x86 32bit system with 6 GB RAM.
--
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
--- You are receiving this mail because: --
On Sat, Dec 22, 2012 at 12:01 PM, Lucas Kannebley Tavares
wrote:
> During the process of obtaining the speed cap for the device, it
> attempts go get the PCI Host bus. However on architectures such as PPC
> or IA64, those do not appear as devices.
>
> Signed-off-by: Lucas Kannebley Tavares
> ---
On Thu, Dec 27, 2012 at 8:40 AM, Bjorn Helgaas wrote:
> On Sat, Dec 22, 2012 at 12:01 PM, Lucas Kannebley Tavares
> wrote:
>> During the process of obtaining the speed cap for the device, it
>> attempts go get the PCI Host bus. However on architectures such as PPC
>> or IA64, those do not appear
It is a bit more precise to compute the total number of pixels first and
then divide, rather than multiplying the line pixel count by the
already-rounded line duration.
Signed-off-by: Daniel Kurtz
---
drivers/gpu/drm/drm_irq.c |6 +-
1 files changed, 5 insertions(+), 1 deletions(-)
diff
Hi,
DISP1BLK_CFG register is related to GScaler, HDCP and MIXER as well. So
it's not good that this register is controlled in fimd module. And I think
the function to control the register should be placed in SoC common file .
In other words, other drivers should be able to control the register
thr
are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20121226/77a70acf/attachment-0001.html>
ttp://lists.freedesktop.org/archives/dri-devel/attachments/20121226/9b4ff1f2/attachment.html>
attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20121226/9fb98ba9/attachment.html>
u are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20121226/0c2ab450/attachment.html>
ause:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20121226/9f7230a1/attachment.html>
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20121226/66efc27e/attachment.html>
scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20121226/cdab866c/attachment.html>
This patch fixes the issue that when buffer allocation is requested
without iommu, the allocation is failed.
Without iommu, dma_alloc_attrs function allocates some memory region
and returns cpu address so this patch makes the cpu address to be set
to buf->kvaddr correctly.
Signed-off-by: Inki Dae
Bypasses the mie for fimd by parsing the register and bit offset values
from "mie-bypass" node, if "mie-bypass" node is present in the dts file.
Signed-off-by: Leela Krishna Amudala
---
drivers/gpu/drm/exynos/exynos_drm_fimd.c | 55
1 file changed, 55 insertions(
Hi Terje,
I applied your patches on top of upstream 1224 kernel. Then I read the
codes. So here is my review comments(I use "git diff" to print out,
check below). I admit it's easy for me to not need to find the
corresponding lines in your 8 patch mails, but I've no idea whether it
is ok for you.
gt; free_irq(ctx->irq, ctx);
> -err_clk:
> - clk_put(ctx->sclk_fimc_clk);
> - clk_put(ctx->fimc_clk);
> - clk_put(ctx->wb_clk);
> - clk_put(ctx->wb_b_clk);
>
> return ret;
> }
> @@ -1891,11 +1870,6 @@ static int __devexit fimc_remove(struct
> platform_device *pdev)
>
> free_irq(ctx->irq, ctx);
>
> - clk_put(ctx->sclk_fimc_clk);
> - clk_put(ctx->fimc_clk);
> - clk_put(ctx->wb_clk);
> - clk_put(ctx->wb_b_clk);
> -
> return 0;
> }
>
> --
> 1.7.4.1
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20121226/bae9c430/attachment-0001.html>
This patchset has more fixes for fixing more issues related to wait for vblank.
Patch 1: add mixer apply function
The mixer window enabled flag is being done in both exynos_drm_hdmi as
well as exynos_mixer. This patch moves the flag to one place and adds the
mixer apply function similar to
Currently, an enabled flag for each mixer window is being set
in both mixer and the common hdmi framework. This patch adds
an apply function in mixer and moves the enabled flag inside
the mixer. This is required to ensure the enabled flag is updated
by the resume flag during dpms.
Signed-off-by: P
This patch checks if vblank is enabled inside wait for vblank. If not
enabled, vblank is temporarily enabled before waiting and then disabled
afterwards. This ensures that the wait never times out.
Signed-off-by: Prathyush K
---
drivers/gpu/drm/exynos/exynos_drm_fimd.c | 12
1 file
From: Sean Paul
We should not finish a pageflip or set wait_for_vblank to zero
if a layer update is pending. This might result in a page fault or corruption
on screen. This patch adds a check in the irq handler to exit if a layer
update is pending. Also, calls layer_update only once per layer per
This patch adds a check in fimd_window_suspend to call win_disable
only if the window is enabled.
Signed-off-by: Prathyush K
---
drivers/gpu/drm/exynos/exynos_drm_fimd.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
b/drivers/
From: Akshu Agrawal
If any fimd channel was already active, initializing iommu will result
in a PAGE FAULT (e.g. u-boot could have turned on the display and
not disabled it before the kernel starts). This patch checks if any
channel is active before initializing iommu and disables it.
Signed-off
Before freeing a framebuffer, we call complete_scanout encoder
function which just calls wait for vblank of all the encoders.
This is not a very optimized method since a framebuffer might not
be in use by a crtc and we end up waiting for vblank unnecessarily.
Instead, this patch modifies the wait_
The wait_for_vblank interface is modified to the complete_scanout
function in hdmi. This inturn calls the complete_scanout mixer op.
This patch also adds the mixer_complete_scanout function.
Inside mixer_complete_scanout, we read the base register and shadow
register for each window and compare it
The wait_for_vblank interface is modified to the complete_scanout
function in fimd. This patch adds the fimd_complete_scanout function
Inside fimd_complete_scanout, we read the shadow register for each
window and compare it with the dma address of the framebuffer. If
the dma_address is in the shad
drm_dev, dev);
> -
> + }
> return 0;
> }
>
> --
> 1.8.0
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20121226/7a0a6e56/attachment.html>
/gpu/drm/exynos/regs-mixer.h | 1 +
> include/video/samsung_fimd.h| 1 +
> 10 files changed, 202 insertions(+), 48 deletions(-)
>
> --
> 1.8.0
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20121226/331fe265/attachment.html>
Hi Vikas,
On Monday 24 December 2012 12:33:50 Vikas Sajjan wrote:
> On Wed, Dec 19, 2012 at 6:51 PM, Laurent Pinchart wrote:
> > On Friday 14 December 2012 16:27:26 Tomi Valkeinen wrote:
> >> Hi,
> >>
> >> I have been testing Common Display Framework on OMAP, and making changes
> >> that I've dis
https://bugzilla.kernel.org/show_bug.cgi?id=42787
Stephan Diestelhorst changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Kernel Version|3.0.0
https://bugzilla.kernel.org/show_bug.cgi?id=42787
--- Comment #3 from Stephan Diestelhorst
2012-12-26 12:40:46 ---
Created an attachment (id=89691)
--> (https://bugzilla.kernel.org/attachment.cgi?id=89691)
dmesg of flickering system
--
Configure bugmail: https://bugzilla.kernel.org/userp
Hi Michael
On Sat, Dec 1, 2012 at 3:54 AM, Michael Hasselmann
wrote:
> On Fri, 2012-09-28 at 23:51 +0200, Luc Verhaegen wrote:
>> We still have, i hope (depends on what the FOSDEM organizers have left
>> for us), 6 slots fully open: first come first serve, and the earlier
>> bird gets the nicer s
https://bugzilla.kernel.org/show_bug.cgi?id=50091
--- Comment #22 from schaefer.frank at gmx.net 2012-12-26 17:34:22 ---
UPDATE:
I've tested with 3.8.0-rc1, and now I have a good chance that the system
starts.
The criticial point is shortly before the the KDE Desktop appears (near the end
of
https://bugzilla.kernel.org/show_bug.cgi?id=50091
--- Comment #23 from schaefer.frank at gmx.net 2012-12-26 17:35:26 ---
Maybe I should add: x86 32bit system with 6 GB RAM.
--
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
--- You are receiving this mail because:
On Sat, Dec 22, 2012 at 12:01 PM, Lucas Kannebley Tavares
wrote:
> During the process of obtaining the speed cap for the device, it
> attempts go get the PCI Host bus. However on architectures such as PPC
> or IA64, those do not appear as devices.
>
> Signed-off-by: Lucas Kannebley Tavares
> ---
t;> - goto err_clk;
>> + return ret;
>> }
>>
>> /* context initailization */
>> @@ -1867,11 +1851,6 @@ err_ippdrv_register:
>> pm_runtime_disable(dev);
>> err_get_irq:
>> free_irq(ctx->irq, ctx);
>> -err_clk:
>> - clk_put(ctx->sclk_fimc_clk);
>> - clk_put(ctx->fimc_clk);
>> - clk_put(ctx->wb_clk);
>> - clk_put(ctx->wb_b_clk);
>>
>> return ret;
>> }
>> @@ -1891,11 +1870,6 @@ static int __devexit fimc_remove(struct
platform_device *pdev)
>>
>> free_irq(ctx->irq, ctx);
>>
>> - clk_put(ctx->sclk_fimc_clk);
>> - clk_put(ctx->fimc_clk);
>> - clk_put(ctx->wb_clk);
>> - clk_put(ctx->wb_b_clk);
>> -
>> return 0;
>> }
>>
>> --
>> 1.7.4.1
>>
>> ___
>> dri-devel mailing list
>> dri-devel at lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>
>
--
With warm regards,
Sachin
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20121226/29337af0/attachment-0001.html>
t;> - goto err_clk;
>> + return ret;
>> }
>>
>> /* context initailization */
>> @@ -1867,11 +1851,6 @@ err_ippdrv_register:
>> pm_runtime_disable(dev);
>> err_get_irq:
>> free_irq(ctx->irq, ctx);
>> -err_clk:
>> - clk_put(ctx->sclk_fimc_clk);
>> - clk_put(ctx->fimc_clk);
>> - clk_put(ctx->wb_clk);
>> - clk_put(ctx->wb_b_clk);
>>
>> return ret;
>> }
>> @@ -1891,11 +1870,6 @@ static int __devexit fimc_remove(struct
platform_device *pdev)
>>
>> free_irq(ctx->irq, ctx);
>>
>> - clk_put(ctx->sclk_fimc_clk);
>> - clk_put(ctx->fimc_clk);
>> - clk_put(ctx->wb_clk);
>> - clk_put(ctx->wb_b_clk);
>> -
>> return 0;
>> }
>>
>> --
>> 1.7.4.1
>>
>> ___
>> dri-devel mailing list
>> dri-devel at lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>
>
--
With warm regards,
Sachin
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20121226/f8f07618/attachment.html>
57 matches
Mail list logo
