Re: [PATCHv7 03/15] v4l: vb2: add support for shared buffer (dma_buf)
Tomasz,
I've encountered an issue with this patch when userspace does several
stream_on/stream_off cycles. When the user tries to qbuf a buffer
after doing stream_off, we trigger the "dmabuf already pinned" warning
since we didn't unmap the buffer as dqbuf was never called.
The below patch adds calls to unmap in queue_cancel, but my feeling is that we
probably should be calling detach too (i.e. put_dmabuf).
Thoughts?
--Dima
Subject: [PATCH] v4l: vb2: unmap dmabufs on STREAM_OFF event
Currently, if the user issues a STREAM_OFF request and then
tries to re-enqueue buffers, it will trigger a warning in
the vb2 allocators as the buffer would still be mapped
from before STREAM_OFF was called. The current expectation
is that buffers will be unmapped in dqbuf, but that will never
be called on the mapped buffers after a STREAM_OFF event.
Cc: Sumit Semwal
Cc: Tomasz Stanislawski
Signed-off-by: Dima Zavin
---
drivers/media/video/videobuf2-core.c | 22 --
1 files changed, 20 insertions(+), 2 deletions(-)
diff --git a/drivers/media/video/videobuf2-core.c
b/drivers/media/video/videobuf2-core.c
index b431dc6..e2a8f12 100644
--- a/drivers/media/video/videobuf2-core.c
+++ b/drivers/media/video/videobuf2-core.c
@@ -1592,8 +1592,26 @@ static void __vb2_queue_cancel(struct vb2_queue *q)
/*
* Reinitialize all buffers for next use.
*/
- for (i = 0; i < q->num_buffers; ++i)
- q->bufs[i]->state = VB2_BUF_STATE_DEQUEUED;
+ for (i = 0; i < q->num_buffers; ++i) {
+ struct vb2_buffer *vb = q->bufs[i];
+ int plane;
+
+ vb->state = VB2_BUF_STATE_DEQUEUED;
+
+ if (q->memory != V4L2_MEMORY_DMABUF)
+ continue;
+
+ for (plane = 0; plane < vb->num_planes; ++plane) {
+ struct vb2_plane *p = &vb->planes[plane];
+
+ if (!p->mem_priv)
+ continue;
+ if (p->dbuf_mapped) {
+ call_memop(q, unmap_dmabuf, p->mem_priv);
+ p->dbuf_mapped = 0;
+ }
+ }
+ }
}
/**
--
1.7.7.3
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH V2 12/16] drm/radeon: Make radeon card usable for Loongson.
On Tue, Jun 19, 2012 at 3:19 PM, Lucas Stach wrote:
> Hello Huacai,
>
> Am Dienstag, den 19.06.2012, 14:50 +0800 schrieb Huacai Chen:
>> 1, Use 32-bit DMA as a workaround (Loongson has a hardware bug that it
>> doesn't support DMA address above 4GB).
>
> This is a bug of your platform/CPU and should be fixed at a lower level,
> not in every driver. While radeon might be the only device using 40bit
> DMA right know, it is very well possible that other devices pop up in
> the future. So please fix your platform code to disallow >32bit DMA.
Hi, Lucas
I have fixed my platform code to disallow >32bit DMA. This method fix
the DMA problems in SATA and sound card, but fails on radeon (display
is OK, but accerlaration is unusable), because need_dma32 not only
affect dma_mask/coherent_dma_mask, but also affect th gfp_flags of
ttm_get_pages(). Platform code fixes cannot solve the problem of
ttm_get_pages(), could you please give me some suggestions? Thank you.
>
>> 2, Read vga bios offered by system firmware.
>> 3, Handle io prot correctly for MIPS.
>
> This seems good to me, but you should really split this out in a
> separate TTM patch.
>
>> 4, Don't use swiotlb on Loongson machines (when use swiotlb, GPU reset
>> occurs at resume from suspend).
>>
> While SWIOTLB might not be a common setup, simply ignoring it because it
> doesn't work on your platform is the wrong thing to do. Could you please
> try to root-cause the issue?
>
> Thanks,
> Lucas
>
>> Signed-off-by: Huacai Chen
>> Signed-off-by: Hongliang Tao
>> Signed-off-by: Hua Yan
>> Cc: dri-devel@lists.freedesktop.org
>> ---
>> drivers/gpu/drm/drm_vm.c | 2 +-
>> drivers/gpu/drm/radeon/radeon_bios.c | 32
>>
>> drivers/gpu/drm/radeon/radeon_device.c | 5 +
>> drivers/gpu/drm/radeon/radeon_ttm.c | 6 +++---
>> drivers/gpu/drm/ttm/ttm_bo_util.c | 2 +-
>> include/drm/drm_sarea.h | 2 ++
>> 6 files changed, 44 insertions(+), 5 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/drm_vm.c b/drivers/gpu/drm/drm_vm.c
>> index 961ee08..3f06166 100644
>> --- a/drivers/gpu/drm/drm_vm.c
>> +++ b/drivers/gpu/drm/drm_vm.c
>> @@ -62,7 +62,7 @@ static pgprot_t drm_io_prot(uint32_t map_type, struct
>> vm_area_struct *vma)
>> tmp = pgprot_writecombine(tmp);
>> else
>> tmp = pgprot_noncached(tmp);
>> -#elif defined(__sparc__) || defined(__arm__)
>> +#elif defined(__sparc__) || defined(__arm__) || defined(__mips__)
>> tmp = pgprot_noncached(tmp);
>> #endif
>> return tmp;
>> diff --git a/drivers/gpu/drm/radeon/radeon_bios.c
>> b/drivers/gpu/drm/radeon/radeon_bios.c
>> index 501f488..2630e22 100644
>> --- a/drivers/gpu/drm/radeon/radeon_bios.c
>> +++ b/drivers/gpu/drm/radeon/radeon_bios.c
>> @@ -29,6 +29,7 @@
>> #include "radeon_reg.h"
>> #include "radeon.h"
>> #include "atom.h"
>> +#include
>>
>> #include
>> #include
>> @@ -73,6 +74,32 @@ static bool igp_read_bios_from_vram(struct radeon_device
>> *rdev)
>> return true;
>> }
>>
>> +#ifdef CONFIG_CPU_LOONGSON3
>> +extern u64 vgabios_addr;
>> +static bool loongson3_read_bios(struct radeon_device *rdev)
>> +{
>> + u8 *bios;
>> + resource_size_t size = 512 * 1024; /* ??? */
>> +
>> + rdev->bios = NULL;
>> +
>> + bios = (u8 *)vgabios_addr;
>> + if (!bios) {
>> + return false;
>> + }
>> +
>> + if (size == 0 || bios[0] != 0x55 || bios[1] != 0xaa) {
>> + return false;
>> + }
>> + rdev->bios = kmalloc(size, GFP_KERNEL);
>> + if (rdev->bios == NULL) {
>> + return false;
>> + }
>> + memcpy(rdev->bios, bios, size);
>> + return true;
>> +}
>> +#endif
>> +
>> static bool radeon_read_bios(struct radeon_device *rdev)
>> {
>> uint8_t __iomem *bios;
>> @@ -490,6 +517,11 @@ bool radeon_get_bios(struct radeon_device *rdev)
>> if (r == false) {
>> r = radeon_read_disabled_bios(rdev);
>> }
>> +#ifdef CONFIG_CPU_LOONGSON3
>> + if (r == false) {
>> + r = loongson3_read_bios(rdev);
>> + }
>> +#endif
>> if (r == false || rdev->bios == NULL) {
>> DRM_ERROR("Unable to locate a BIOS ROM\n");
>> rdev->bios = NULL;
>> diff --git a/drivers/gpu/drm/radeon/radeon_device.c
>> b/drivers/gpu/drm/radeon/radeon_device.c
>> index 066c98b..8aac7ab 100644
>> --- a/drivers/gpu/drm/radeon/radeon_device.c
>> +++ b/drivers/gpu/drm/radeon/radeon_device.c
>> @@ -777,6 +777,11 @@ int radeon_device_init(struct radeon_device *rdev,
>> (rdev->family < CHIP_RS400))
>> rdev->need_dma32 = true;
>>
>> +#ifdef CONFIG_CPU_LOONGSON3
>> + /* Workaround: Loongson 3 doesn't support 40-bits DMA */
>> + rdev->need_dma32 = true;
>> +#endif
>> +
>> dma_bits = rdev->need_dma32 ? 32 : 40;
>> r = pci_set_dma_mask(rdev->pdev, DMA_BIT_MASK(dma_bits));
>> if (r) {
>> diff --git a/drivers/gpu/drm/radeon/radeon_ttm
Re: [PATCH V2 12/16] drm/radeon: Make radeon card usable for Loongson.
Am Mittwoch, den 20.06.2012, 14:12 +0800 schrieb Huacai Chen: > On Tue, Jun 19, 2012 at 3:19 PM, Lucas Stach wrote: > > Hello Huacai, > > > > Am Dienstag, den 19.06.2012, 14:50 +0800 schrieb Huacai Chen: > >> 1, Use 32-bit DMA as a workaround (Loongson has a hardware bug that it > >>doesn't support DMA address above 4GB). > > > > This is a bug of your platform/CPU and should be fixed at a lower level, > > not in every driver. While radeon might be the only device using 40bit > > DMA right know, it is very well possible that other devices pop up in > > the future. So please fix your platform code to disallow >32bit DMA. > > Hi, Lucas > I have fixed my platform code to disallow >32bit DMA. This method fix > the DMA problems in SATA and sound card, but fails on radeon (display > is OK, but accerlaration is unusable), because need_dma32 not only > affect dma_mask/coherent_dma_mask, but also affect th gfp_flags of > ttm_get_pages(). Platform code fixes cannot solve the problem of > ttm_get_pages(), could you please give me some suggestions? Thank you. If your platform does disallow >32bit DMA masks, radeon should already do the right thing and set need_dma32 to true. Have a look at radeon_device.c:783 Make sure you really disallow >32bit DMA masks, not just prefer <=32bit masks. > > > > >> 2, Read vga bios offered by system firmware. > >> 3, Handle io prot correctly for MIPS. > > > > This seems good to me, but you should really split this out in a > > separate TTM patch. > > > >> 4, Don't use swiotlb on Loongson machines (when use swiotlb, GPU reset > >>occurs at resume from suspend). > >> > > While SWIOTLB might not be a common setup, simply ignoring it because it > > doesn't work on your platform is the wrong thing to do. Could you please > > try to root-cause the issue? > > [snip] ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH V2 12/16] drm/radeon: Make radeon card usable for Loongson.
On Wed, Jun 20, 2012 at 2:38 PM, Lucas Stach wrote: > Am Mittwoch, den 20.06.2012, 14:12 +0800 schrieb Huacai Chen: >> On Tue, Jun 19, 2012 at 3:19 PM, Lucas Stach wrote: >> > Hello Huacai, >> > >> > Am Dienstag, den 19.06.2012, 14:50 +0800 schrieb Huacai Chen: >> >> 1, Use 32-bit DMA as a workaround (Loongson has a hardware bug that it >> >> doesn't support DMA address above 4GB). >> > >> > This is a bug of your platform/CPU and should be fixed at a lower level, >> > not in every driver. While radeon might be the only device using 40bit >> > DMA right know, it is very well possible that other devices pop up in >> > the future. So please fix your platform code to disallow >32bit DMA. >> >> Hi, Lucas >> I have fixed my platform code to disallow >32bit DMA. This method fix >> the DMA problems in SATA and sound card, but fails on radeon (display >> is OK, but accerlaration is unusable), because need_dma32 not only >> affect dma_mask/coherent_dma_mask, but also affect th gfp_flags of >> ttm_get_pages(). Platform code fixes cannot solve the problem of >> ttm_get_pages(), could you please give me some suggestions? Thank you. > > If your platform does disallow >32bit DMA masks, radeon should already > do the right thing and set need_dma32 to true. Have a look at > radeon_device.c:783 > > Make sure you really disallow >32bit DMA masks, not just prefer <=32bit > masks. I know, my previous code change is provide an arch-specific dma_map_ops::set_dma_mask() and dma_set_coherent_mask() to force the dma_mask/coherent_dma_mask <=bit, but always return success. In fact the right way is return an error code when driver try to set the dma_mask >32bit. Thank you very much! >> >> > >> >> 2, Read vga bios offered by system firmware. >> >> 3, Handle io prot correctly for MIPS. >> > >> > This seems good to me, but you should really split this out in a >> > separate TTM patch. >> > >> >> 4, Don't use swiotlb on Loongson machines (when use swiotlb, GPU reset >> >> occurs at resume from suspend). >> >> >> > While SWIOTLB might not be a common setup, simply ignoring it because it >> > doesn't work on your platform is the wrong thing to do. Could you please >> > try to root-cause the issue? >> > > [snip] > > ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH V2 12/16] drm/radeon: Make radeon card usable for Loongson.
On Wed, Jun 20, 2012 at 9:26 AM, Alex Deucher wrote:
> On Tue, Jun 19, 2012 at 9:57 AM, j.glisse wrote:
>> On Tue, Jun 19, 2012 at 02:50:20PM +0800, Huacai Chen wrote:
>>> 1, Use 32-bit DMA as a workaround (Loongson has a hardware bug that it
>>> doesn't support DMA address above 4GB).
>>> 2, Read vga bios offered by system firmware.
>>> 3, Handle io prot correctly for MIPS.
>>> 4, Don't use swiotlb on Loongson machines (when use swiotlb, GPU reset
>>> occurs at resume from suspend).
>>>
>>> Signed-off-by: Huacai Chen
>>> Signed-off-by: Hongliang Tao
>>> Signed-off-by: Hua Yan
>>> Cc: dri-devel@lists.freedesktop.org
>>> ---
>>> drivers/gpu/drm/drm_vm.c | 2 +-
>>> drivers/gpu/drm/radeon/radeon_bios.c | 32
>>>
>>> drivers/gpu/drm/radeon/radeon_device.c | 5 +
>>> drivers/gpu/drm/radeon/radeon_ttm.c | 6 +++---
>>> drivers/gpu/drm/ttm/ttm_bo_util.c | 2 +-
>>> include/drm/drm_sarea.h | 2 ++
>>> 6 files changed, 44 insertions(+), 5 deletions(-)
>>>
>>> diff --git a/drivers/gpu/drm/drm_vm.c b/drivers/gpu/drm/drm_vm.c
>>> index 961ee08..3f06166 100644
>>> --- a/drivers/gpu/drm/drm_vm.c
>>> +++ b/drivers/gpu/drm/drm_vm.c
>>> @@ -62,7 +62,7 @@ static pgprot_t drm_io_prot(uint32_t map_type, struct
>>> vm_area_struct *vma)
>>> tmp = pgprot_writecombine(tmp);
>>> else
>>> tmp = pgprot_noncached(tmp);
>>> -#elif defined(__sparc__) || defined(__arm__)
>>> +#elif defined(__sparc__) || defined(__arm__) || defined(__mips__)
>>> tmp = pgprot_noncached(tmp);
>>> #endif
>>> return tmp;
>>> diff --git a/drivers/gpu/drm/radeon/radeon_bios.c
>>> b/drivers/gpu/drm/radeon/radeon_bios.c
>>> index 501f488..2630e22 100644
>>> --- a/drivers/gpu/drm/radeon/radeon_bios.c
>>> +++ b/drivers/gpu/drm/radeon/radeon_bios.c
>>> @@ -29,6 +29,7 @@
>>> #include "radeon_reg.h"
>>> #include "radeon.h"
>>> #include "atom.h"
>>> +#include
>>>
>>> #include
>>> #include
>>> @@ -73,6 +74,32 @@ static bool igp_read_bios_from_vram(struct radeon_device
>>> *rdev)
>>> return true;
>>> }
>>>
>>> +#ifdef CONFIG_CPU_LOONGSON3
>>> +extern u64 vgabios_addr;
>>
>> Ugly, is this how platform specific stuff are handled usualy ? I hope not,
>> i would rather see a platform specific function such as
>> loongson3_get_vga_bios.
>
> It could be hooked in as a pci quirk similar to how we read the vbios
> from the legacy vga location on x86.
Hi, Alex, the method you said is pci_fixup_video() in arch/x86/pci/fixup.c?
>
> Alex
>
>>
>> Cheers,
>> Jerome
>>
>>> +static bool loongson3_read_bios(struct radeon_device *rdev)
>>> +{
>>> + u8 *bios;
>>> + resource_size_t size = 512 * 1024; /* ??? */
>>> +
>>> + rdev->bios = NULL;
>>> +
>>> + bios = (u8 *)vgabios_addr;
>>> + if (!bios) {
>>> + return false;
>>> + }
>>> +
>>> + if (size == 0 || bios[0] != 0x55 || bios[1] != 0xaa) {
>>> + return false;
>>> + }
>>> + rdev->bios = kmalloc(size, GFP_KERNEL);
>>> + if (rdev->bios == NULL) {
>>> + return false;
>>> + }
>>> + memcpy(rdev->bios, bios, size);
>>> + return true;
>>> +}
>>> +#endif
>>> +
>>> static bool radeon_read_bios(struct radeon_device *rdev)
>>> {
>>> uint8_t __iomem *bios;
>>> @@ -490,6 +517,11 @@ bool radeon_get_bios(struct radeon_device *rdev)
>>> if (r == false) {
>>> r = radeon_read_disabled_bios(rdev);
>>> }
>>> +#ifdef CONFIG_CPU_LOONGSON3
>>> + if (r == false) {
>>> + r = loongson3_read_bios(rdev);
>>> + }
>>> +#endif
>>> if (r == false || rdev->bios == NULL) {
>>> DRM_ERROR("Unable to locate a BIOS ROM\n");
>>> rdev->bios = NULL;
>>> diff --git a/drivers/gpu/drm/radeon/radeon_device.c
>>> b/drivers/gpu/drm/radeon/radeon_device.c
>>> index 066c98b..8aac7ab 100644
>>> --- a/drivers/gpu/drm/radeon/radeon_device.c
>>> +++ b/drivers/gpu/drm/radeon/radeon_device.c
>>> @@ -777,6 +777,11 @@ int radeon_device_init(struct radeon_device *rdev,
>>> (rdev->family < CHIP_RS400))
>>> rdev->need_dma32 = true;
>>>
>>> +#ifdef CONFIG_CPU_LOONGSON3
>>> + /* Workaround: Loongson 3 doesn't support 40-bits DMA */
>>> + rdev->need_dma32 = true;
>>> +#endif
>>> +
>>> dma_bits = rdev->need_dma32 ? 32 : 40;
>>> r = pci_set_dma_mask(rdev->pdev, DMA_BIT_MASK(dma_bits));
>>> if (r) {
>>> diff --git a/drivers/gpu/drm/radeon/radeon_ttm.c
>>> b/drivers/gpu/drm/radeon/radeon_ttm.c
>>> index c94a225..f49bdd1 100644
>>> --- a/drivers/gpu/drm/radeon/radeon_ttm.c
>>> +++ b/drivers/gpu/drm/radeon/radeon_ttm.c
>>> @@ -630,7 +630,7 @@ static int radeon_ttm_tt_populate(struct ttm_tt *ttm)
>>> }
>>> #endif
>>>
>>> -#ifdef CONFIG_SWIOTLB
>>> +#if defined(CONFIG_SWIOTLB) && !defined(CONFIG_CPU_LOONGSON3)
>>> if (swiotlb_nr_tbl()) {
>>> return ttm_dma_populate(>t->ttm, rdev->dev);
>>
Re: [PATCH 1/3] drm/exynos: Use devm_* functions in exynos_drm_fimd.c
2012/6/19, Sachin Kamat :
> devm_* functions are device managed functions and make error handling
> and cleanup cleaner and simpler.
>
> Signed-off-by: Sachin Kamat
> Signed-off-by: Sachin Kamat
> ---
> drivers/gpu/drm/exynos/exynos_drm_fimd.c | 40
> ++
> 1 files changed, 8 insertions(+), 32 deletions(-)
>
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> index 29fdbfe..a68d2b3 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> @@ -78,7 +78,6 @@ struct fimd_context {
> struct drm_crtc *crtc;
> struct clk *bus_clk;
> struct clk *lcd_clk;
> - struct resource *regs_res;
> void __iomem*regs;
> struct fimd_win_datawin_data[WINDOWS_NR];
> unsigned intclkdiv;
> @@ -813,7 +812,7 @@ static int __devinit fimd_probe(struct platform_device
> *pdev)
> return -EINVAL;
> }
>
> - ctx = kzalloc(sizeof(*ctx), GFP_KERNEL);
> + ctx = devm_kzalloc(&pdev->dev, sizeof(*ctx), GFP_KERNEL);
> if (!ctx)
> return -ENOMEM;
>
> @@ -838,33 +837,26 @@ static int __devinit fimd_probe(struct platform_device
> *pdev)
> goto err_clk;
> }
>
> - ctx->regs_res = request_mem_region(res->start, resource_size(res),
> -dev_name(dev));
> - if (!ctx->regs_res) {
> - dev_err(dev, "failed to claim register region\n");
> - ret = -ENOENT;
> - goto err_clk;
> - }
> -
> - ctx->regs = ioremap(res->start, resource_size(res));
> + ctx->regs = devm_request_and_ioremap(&pdev->dev, res);
> if (!ctx->regs) {
> dev_err(dev, "failed to map registers\n");
> ret = -ENXIO;
> - goto err_req_region_io;
> + goto err_clk;
> }
>
> res = platform_get_resource(pdev, IORESOURCE_IRQ, 0);
> if (!res) {
> dev_err(dev, "irq request failed.\n");
> - goto err_req_region_irq;
> + goto err_clk;
> }
>
> ctx->irq = res->start;
>
> - ret = request_irq(ctx->irq, fimd_irq_handler, 0, "drm_fimd", ctx);
> - if (ret < 0) {
> + ret = devm_request_irq(&pdev->dev, ctx->irq, fimd_irq_handler,
> + 0, "drm_fimd", ctx);
> + if (ret) {
> dev_err(dev, "irq request failed.\n");
> - goto err_req_irq;
> + goto err_clk;
> }
>
> ctx->vidcon0 = pdata->vidcon0;
> @@ -899,14 +891,6 @@ static int __devinit fimd_probe(struct platform_device
> *pdev)
>
> return 0;
>
> -err_req_irq:
> -err_req_region_irq:
> - iounmap(ctx->regs);
> -
> -err_req_region_io:
> - release_resource(ctx->regs_res);
> - kfree(ctx->regs_res);
> -
> err_clk:
> clk_disable(ctx->lcd_clk);
> clk_put(ctx->lcd_clk);
> @@ -916,7 +900,6 @@ err_bus_clk:
> clk_put(ctx->bus_clk);
>
> err_clk_get:
> - kfree(ctx);
> return ret;
> }
>
> @@ -944,13 +927,6 @@ out:
> clk_put(ctx->lcd_clk);
> clk_put(ctx->bus_clk);
>
> - iounmap(ctx->regs);
> - release_resource(ctx->regs_res);
> - kfree(ctx->regs_res);
> - free_irq(ctx->irq, ctx);
> -
> - kfree(ctx);
> -
> return 0;
> }
>
> --
> 1.7.4.1
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>
Applied.
Thanks,
Inki Dae
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/3] drm/exynos: Use devm_* functions in exynos_hdmi.c
2012/6/19, Sachin Kamat :
> devm_* functions are device managed functions and make error handling
> and cleanup cleaner and simpler.
>
> Signed-off-by: Sachin Kamat
> Signed-off-by: Sachin Kamat
> ---
> drivers/gpu/drm/exynos/exynos_hdmi.c | 36
> ++---
> 1 files changed, 7 insertions(+), 29 deletions(-)
>
> diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c
> b/drivers/gpu/drm/exynos/exynos_hdmi.c
> index a137e9e..5816b0f 100644
> --- a/drivers/gpu/drm/exynos/exynos_hdmi.c
> +++ b/drivers/gpu/drm/exynos/exynos_hdmi.c
> @@ -63,7 +63,6 @@ struct hdmi_context {
> booldvi_mode;
> struct mutexhdmi_mutex;
>
> - struct resource *regs_res;
> void __iomem*regs;
> unsigned intexternal_irq;
> unsigned intinternal_irq;
> @@ -2280,16 +2279,17 @@ static int __devinit hdmi_probe(struct
> platform_device *pdev)
> return -EINVAL;
> }
>
> - drm_hdmi_ctx = kzalloc(sizeof(*drm_hdmi_ctx), GFP_KERNEL);
> + drm_hdmi_ctx = devm_kzalloc(&pdev->dev, sizeof(*drm_hdmi_ctx),
> + GFP_KERNEL);
> if (!drm_hdmi_ctx) {
> DRM_ERROR("failed to allocate common hdmi context.\n");
> return -ENOMEM;
> }
>
> - hdata = kzalloc(sizeof(struct hdmi_context), GFP_KERNEL);
> + hdata = devm_kzalloc(&pdev->dev, sizeof(struct hdmi_context),
> + GFP_KERNEL);
> if (!hdata) {
> DRM_ERROR("out of memory\n");
> - kfree(drm_hdmi_ctx);
> return -ENOMEM;
> }
>
> @@ -2318,26 +2318,18 @@ static int __devinit hdmi_probe(struct
> platform_device *pdev)
> goto err_resource;
> }
>
> - hdata->regs_res = request_mem_region(res->start, resource_size(res),
> -dev_name(dev));
> - if (!hdata->regs_res) {
> - DRM_ERROR("failed to claim register region\n");
> - ret = -ENOENT;
> - goto err_resource;
> - }
> -
> - hdata->regs = ioremap(res->start, resource_size(res));
> + hdata->regs = devm_request_and_ioremap(&pdev->dev, res);
> if (!hdata->regs) {
> DRM_ERROR("failed to map registers\n");
> ret = -ENXIO;
> - goto err_req_region;
> + goto err_resource;
> }
>
> /* DDC i2c driver */
> if (i2c_add_driver(&ddc_driver)) {
> DRM_ERROR("failed to register ddc i2c driver\n");
> ret = -ENOENT;
> - goto err_iomap;
> + goto err_resource;
> }
>
> hdata->ddc_port = hdmi_ddc;
> @@ -2398,16 +2390,9 @@ err_hdmiphy:
> i2c_del_driver(&hdmiphy_driver);
> err_ddc:
> i2c_del_driver(&ddc_driver);
> -err_iomap:
> - iounmap(hdata->regs);
> -err_req_region:
> - release_mem_region(hdata->regs_res->start,
> - resource_size(hdata->regs_res));
> err_resource:
> hdmi_resources_cleanup(hdata);
> err_data:
> - kfree(hdata);
> - kfree(drm_hdmi_ctx);
> return ret;
> }
>
> @@ -2425,18 +2410,11 @@ static int __devexit hdmi_remove(struct
> platform_device *pdev)
>
> hdmi_resources_cleanup(hdata);
>
> - iounmap(hdata->regs);
> -
> - release_mem_region(hdata->regs_res->start,
> - resource_size(hdata->regs_res));
> -
> /* hdmiphy i2c driver */
> i2c_del_driver(&hdmiphy_driver);
> /* DDC i2c driver */
> i2c_del_driver(&ddc_driver);
>
> - kfree(hdata);
> -
> return 0;
> }
>
> --
> 1.7.4.1
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>
Applied.
Thanks,
Inki Dae
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 3/3] drm/exynos: Use devm_* functions in exynos_mixer.c
2012/6/19, Sachin Kamat :
> devm_* functions are device managed functions and make error handling
> and cleanup cleaner and simpler.
>
> Signed-off-by: Sachin Kamat
> Signed-off-by: Sachin Kamat
> ---
> drivers/gpu/drm/exynos/exynos_mixer.c | 48
> +---
> 1 files changed, 14 insertions(+), 34 deletions(-)
>
> diff --git a/drivers/gpu/drm/exynos/exynos_mixer.c
> b/drivers/gpu/drm/exynos/exynos_mixer.c
> index e2147a2..30fcc12 100644
> --- a/drivers/gpu/drm/exynos/exynos_mixer.c
> +++ b/drivers/gpu/drm/exynos/exynos_mixer.c
> @@ -956,7 +956,8 @@ static int __devinit mixer_resources_init(struct
> exynos_drm_hdmi_context *ctx,
>
> clk_set_parent(mixer_res->sclk_mixer, mixer_res->sclk_hdmi);
>
> - mixer_res->mixer_regs = ioremap(res->start, resource_size(res));
> + mixer_res->mixer_regs = devm_ioremap(&pdev->dev, res->start,
> + resource_size(res));
> if (mixer_res->mixer_regs == NULL) {
> dev_err(dev, "register mapping failed.\n");
> ret = -ENXIO;
> @@ -967,38 +968,34 @@ static int __devinit mixer_resources_init(struct
> exynos_drm_hdmi_context *ctx,
> if (res == NULL) {
> dev_err(dev, "get memory resource failed.\n");
> ret = -ENXIO;
> - goto fail_mixer_regs;
> + goto fail;
> }
>
> - mixer_res->vp_regs = ioremap(res->start, resource_size(res));
> + mixer_res->vp_regs = devm_ioremap(&pdev->dev, res->start,
> + resource_size(res));
> if (mixer_res->vp_regs == NULL) {
> dev_err(dev, "register mapping failed.\n");
> ret = -ENXIO;
> - goto fail_mixer_regs;
> + goto fail;
> }
>
> res = platform_get_resource_byname(pdev, IORESOURCE_IRQ, "irq");
> if (res == NULL) {
> dev_err(dev, "get interrupt resource failed.\n");
> ret = -ENXIO;
> - goto fail_vp_regs;
> + goto fail;
> }
>
> - ret = request_irq(res->start, mixer_irq_handler, 0, "drm_mixer", ctx);
> + ret = devm_request_irq(&pdev->dev, res->start, mixer_irq_handler,
> + 0, "drm_mixer", ctx);
> if (ret) {
> dev_err(dev, "request interrupt failed.\n");
> - goto fail_vp_regs;
> + goto fail;
> }
> mixer_res->irq = res->start;
>
> return 0;
>
> -fail_vp_regs:
> - iounmap(mixer_res->vp_regs);
> -
> -fail_mixer_regs:
> - iounmap(mixer_res->mixer_regs);
> -
> fail:
> if (!IS_ERR_OR_NULL(mixer_res->sclk_dac))
> clk_put(mixer_res->sclk_dac);
> @@ -1013,16 +1010,6 @@ fail:
> return ret;
> }
>
> -static void mixer_resources_cleanup(struct mixer_context *ctx)
> -{
> - struct mixer_resources *res = &ctx->mixer_res;
> -
> - free_irq(res->irq, ctx);
> -
> - iounmap(res->vp_regs);
> - iounmap(res->mixer_regs);
> -}
> -
> static int __devinit mixer_probe(struct platform_device *pdev)
> {
> struct device *dev = &pdev->dev;
> @@ -1032,16 +1019,16 @@ static int __devinit mixer_probe(struct
> platform_device *pdev)
>
> dev_info(dev, "probe start\n");
>
> - drm_hdmi_ctx = kzalloc(sizeof(*drm_hdmi_ctx), GFP_KERNEL);
> + drm_hdmi_ctx = devm_kzalloc(&pdev->dev, sizeof(*drm_hdmi_ctx),
> + GFP_KERNEL);
> if (!drm_hdmi_ctx) {
> DRM_ERROR("failed to allocate common hdmi context.\n");
> return -ENOMEM;
> }
>
> - ctx = kzalloc(sizeof(*ctx), GFP_KERNEL);
> + ctx = devm_kzalloc(&pdev->dev, sizeof(*ctx), GFP_KERNEL);
> if (!ctx) {
> DRM_ERROR("failed to alloc mixer context.\n");
> - kfree(drm_hdmi_ctx);
> return -ENOMEM;
> }
>
> @@ -1072,17 +1059,10 @@ fail:
>
> static int mixer_remove(struct platform_device *pdev)
> {
> - struct device *dev = &pdev->dev;
> - struct exynos_drm_hdmi_context *drm_hdmi_ctx =
> - platform_get_drvdata(pdev);
> - struct mixer_context *ctx = drm_hdmi_ctx->ctx;
> -
> - dev_info(dev, "remove successful\n");
> + dev_info(&pdev->dev, "remove successful\n");
>
> pm_runtime_disable(&pdev->dev);
>
> - mixer_resources_cleanup(ctx);
> -
> return 0;
> }
>
> --
> 1.7.4.1
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>
Applied.
Thanks,
Inki Dae
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCHv7 06/15] v4l: vb2-dma-contig: remove reference of alloc_ctx from a buffer
Hi Laurent, On 06/19/2012 11:00 PM, Laurent Pinchart wrote: > Hi Tomasz, > > Thanks for the patch. > > On Thursday 14 June 2012 15:37:40 Tomasz Stanislawski wrote: >> This patch removes a reference to alloc_ctx from an instance of a DMA >> contiguous buffer. It helps to avoid a risk of a dangling pointer if the >> context is released while the buffer is still valid. > > Can this really happen ? All drivers except marvell-ccic seem to call > vb2_dma_contig_cleanup_ctx() in their remove handler and probe cleanup path > only. Freeing the context while buffers are still around would be a driver > bug, and I expect drivers to destroy the queue in that case anyway. > > This being said, removing the dereference step is a good idea, so I think the > patch should be applied, possibly with a different commit message. > The problem may happen if a DMABUF sharing is used. - process A uses V4L2 queue to create a buffer - process A exports a buffer and shares it with the process B (by sockets or /proc/pid/fd) - the process A gets killed, queue is destroyed - someone call rmmod on v4l driver, alloc_ctx is freed - process B keeps reference to a buffer that has a dangling reference to alloc_ctx The presented scenario might be a bit too pathological and artificial. Moreover it involves root privileges. But it is possible to trigger this bug. One solution might be keeping reference count in alloc_ctx but it would be easier to get rid of the reference to alloc_ctx from vb2-dma-contig buffer. BTW. I decided to drop 'Remove unneeded allocation context structure' because Marek Szyprowski is working on extension to vb2-dma-contig that allow to create buffers with no kernel mappings. That feature involved additional parameter to alloc_ctx other than pointer to the device. Regards, Tomasz Stanislawski >> Moreover it removes one >> dereference step while accessing a device structure. >> >> Signed-off-by: Tomasz Stanislawski >> Signed-off-by: Kyungmin Park > > Acked-by: Laurent Pinchart > >> +dma_free_coherent(buf->dev, buf->size, buf->vaddr, >>buf->dma_addr); >> kfree(buf); >> } ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCHv7 06/15] v4l: vb2-dma-contig: remove reference of alloc_ctx from a buffer
Hi Tomasz, On Wednesday 20 June 2012 13:51:06 Tomasz Stanislawski wrote: > On 06/19/2012 11:00 PM, Laurent Pinchart wrote: > > On Thursday 14 June 2012 15:37:40 Tomasz Stanislawski wrote: > >> This patch removes a reference to alloc_ctx from an instance of a DMA > >> contiguous buffer. It helps to avoid a risk of a dangling pointer if the > >> context is released while the buffer is still valid. > > > > Can this really happen ? All drivers except marvell-ccic seem to call > > vb2_dma_contig_cleanup_ctx() in their remove handler and probe cleanup > > path only. Freeing the context while buffers are still around would be a > > driver bug, and I expect drivers to destroy the queue in that case anyway. > > > > This being said, removing the dereference step is a good idea, so I think > > the patch should be applied, possibly with a different commit message. > > The problem may happen if a DMABUF sharing is used. > - process A uses V4L2 queue to create a buffer > - process A exports a buffer and shares it with the process B (by sockets or > /proc/pid/fd) - the process A gets killed, queue is destroyed > - someone call rmmod on v4l driver, alloc_ctx is freed That's where the problem is in my opinion. As long as a buffer is in use, the queue should not get destroyed and the context should not be freed. If the driver is removed it will kfree the structure that embeds the queue, and even possible free the whole memory region that backs the buffers. We would then have much bigger trouble than just a dangling context pointer. >From a V4L2 point of view this needs to be solved for the dmabuf exporter role only, so it's not a huge concern in the context of this patch set, but we of course need to address the issue. > - process B keeps reference to a buffer that has a dangling reference to > alloc_ctx > > The presented scenario might be a bit too pathological and artificial. > Moreover it involves root privileges. But it is possible to trigger this > bug. One solution might be keeping reference count in alloc_ctx but it > would be easier to get rid of the reference to alloc_ctx from > vb2-dma-contig buffer. > > BTW. I decided to drop 'Remove unneeded allocation context structure' > because Marek Szyprowski is working on extension to vb2-dma-contig > that allow to create buffers with no kernel mappings. That feature > involved additional parameter to alloc_ctx other than pointer to > the device. OK. -- Regards, Laurent Pinchart ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/edid: don't return stack garbage from supports_rb
On Tue, 2012-06-19 at 11:33 +0200, Daniel Vetter wrote: > We need to initialize this to false, because the is_rb callback only > ever sets it to true. > > Noticed while reading through the code. > > Cc: Adam Jackson > Cc: sta...@vger.kernel.org > Signed-Off-by: Daniel Vetter Reviewed-by: Adam Jackson - ajax signature.asc Description: This is a digitally signed message part ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 50422] Furmark.exe crash with wine (32 bits under 64 bits) with llvm-3.1 and r600-llvm-compiler enabled
https://bugs.freedesktop.org/show_bug.cgi?id=50422 --- Comment #3 from Henri Verbeet 2012-06-20 08:41:51 PDT --- This isn't just another instance of "Clang is broken" / bug 44466, right? -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Thunderbolt, Apple Monitor & MBA, and excess kworker load
Hi, At work, I wish to attach a 27" Apple Display using thunderbolt to my Mac Book Air 4,2 13". Using OS X, it works fine, but as I prefer using Linux, I tested out Ubuntu's stock kernel and (among other) 3.5.0-rc3+ as of f40759e. Hotplug doesn't work (known issue), but also with coldplug the display reacts _very_ slow, way too slow for real use: The screen updates only every half second or so. Is this a known bug? Might something go afoul with kworker -- they need about 75% of the CPU with the large display attached, and less than 1% _without_ the large display. Any hints are most welcome, also on where I may dig further to determine the root causes... Thanks & best, Dominik ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Thunderbolt, Apple Monitor & MBA, and excess kworker load
On Wed, Jun 20, 2012 at 08:56:26AM -0700, Greg KH wrote: > On Wed, Jun 20, 2012 at 05:48:42PM +0200, Dominik Brodowski wrote: > > Hi, > > > > At work, I wish to attach a 27" Apple Display using thunderbolt to my Mac > > Book Air 4,2 13". Using OS X, it works fine, but as I prefer using Linux, I > > tested out Ubuntu's stock kernel and (among other) 3.5.0-rc3+ as of f40759e. > > Hotplug doesn't work (known issue), but also with coldplug the display > > reacts _very_ slow, way too slow for real use: The screen updates only every > > half second or so. Is this a known bug? Might something go afoul with > > kworker -- they need about 75% of the CPU with the large display attached, > > and less than 1% _without_ the large display. > > It's not really a known bug, but it is known that Thunderbolt doesn't > work all that well, if at all, in Linux due to the BIOS issues that you > have run into (the hotplug stuff.) > > Once the device is seen, it should just work like any other PCI device, > and so, that might be a DRM driver issue somehow. A quick full-system profile would be a good start to tell where we're burning through all these cycles exaclty. Also, anything special going on with interrupts (if this excessive load is due to supurious display hotplug events, drm/i915 should get _tons_ of interrupts). -Daniel -- Daniel Vetter Mail: dan...@ffwll.ch Mobile: +41 (0)79 365 57 48 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH V2 12/16] drm/radeon: Make radeon card usable for Loongson.
On Wed, Jun 20, 2012 at 4:28 AM, Huacai Chen wrote: > On Wed, Jun 20, 2012 at 9:26 AM, Alex Deucher wrote: >> On Tue, Jun 19, 2012 at 9:57 AM, j.glisse wrote: >>> On Tue, Jun 19, 2012 at 02:50:20PM +0800, Huacai Chen wrote: 1, Use 32-bit DMA as a workaround (Loongson has a hardware bug that it doesn't support DMA address above 4GB). 2, Read vga bios offered by system firmware. 3, Handle io prot correctly for MIPS. 4, Don't use swiotlb on Loongson machines (when use swiotlb, GPU reset occurs at resume from suspend). Signed-off-by: Huacai Chen Signed-off-by: Hongliang Tao Signed-off-by: Hua Yan Cc: dri-devel@lists.freedesktop.org --- drivers/gpu/drm/drm_vm.c | 2 +- drivers/gpu/drm/radeon/radeon_bios.c | 32 drivers/gpu/drm/radeon/radeon_device.c | 5 + drivers/gpu/drm/radeon/radeon_ttm.c | 6 +++--- drivers/gpu/drm/ttm/ttm_bo_util.c | 2 +- include/drm/drm_sarea.h | 2 ++ 6 files changed, 44 insertions(+), 5 deletions(-) diff --git a/drivers/gpu/drm/drm_vm.c b/drivers/gpu/drm/drm_vm.c index 961ee08..3f06166 100644 --- a/drivers/gpu/drm/drm_vm.c +++ b/drivers/gpu/drm/drm_vm.c @@ -62,7 +62,7 @@ static pgprot_t drm_io_prot(uint32_t map_type, struct vm_area_struct *vma) tmp = pgprot_writecombine(tmp); else tmp = pgprot_noncached(tmp); -#elif defined(__sparc__) || defined(__arm__) +#elif defined(__sparc__) || defined(__arm__) || defined(__mips__) tmp = pgprot_noncached(tmp); #endif return tmp; diff --git a/drivers/gpu/drm/radeon/radeon_bios.c b/drivers/gpu/drm/radeon/radeon_bios.c index 501f488..2630e22 100644 --- a/drivers/gpu/drm/radeon/radeon_bios.c +++ b/drivers/gpu/drm/radeon/radeon_bios.c @@ -29,6 +29,7 @@ #include "radeon_reg.h" #include "radeon.h" #include "atom.h" +#include #include #include @@ -73,6 +74,32 @@ static bool igp_read_bios_from_vram(struct radeon_device *rdev) return true; } +#ifdef CONFIG_CPU_LOONGSON3 +extern u64 vgabios_addr; >>> >>> Ugly, is this how platform specific stuff are handled usualy ? I hope not, >>> i would rather see a platform specific function such as >>> loongson3_get_vga_bios. >> >> It could be hooked in as a pci quirk similar to how we read the vbios >> from the legacy vga location on x86. > Hi, Alex, the method you said is pci_fixup_video() in arch/x86/pci/fixup.c? Correct, although you will probably need it in arch/mips/pci for your platform. You may want to make your quirk specific to this pci device unless you need it for all vga chips on your platform. Alex ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Thunderbolt, Apple Monitor & MBA, and excess kworker load
On Wed, Jun 20, 2012 at 05:48:42PM +0200, Dominik Brodowski wrote: > Hi, > > At work, I wish to attach a 27" Apple Display using thunderbolt to my Mac > Book Air 4,2 13". Using OS X, it works fine, but as I prefer using Linux, I > tested out Ubuntu's stock kernel and (among other) 3.5.0-rc3+ as of f40759e. > Hotplug doesn't work (known issue), but also with coldplug the display > reacts _very_ slow, way too slow for real use: The screen updates only every > half second or so. Is this a known bug? Might something go afoul with > kworker -- they need about 75% of the CPU with the large display attached, > and less than 1% _without_ the large display. It's not really a known bug, but it is known that Thunderbolt doesn't work all that well, if at all, in Linux due to the BIOS issues that you have run into (the hotplug stuff.) Once the device is seen, it should just work like any other PCI device, and so, that might be a DRM driver issue somehow. greg k-h ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 51190] [RADEON:KMS:RV370:RESUME] garbage on screen (console or X) after suspend-resume with radeon (KMS only)
https://bugs.freedesktop.org/show_bug.cgi?id=51190 --- Comment #7 from cyberbat 2012-06-20 10:56:44 PDT --- (In reply to comment #6) > No, I mean writing the string 'mem'. I don't know what if anything writing 3 > will do. I've tried echo -n "mem" > /sys/power/state Just the same behavior as described. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 51190] [RADEON:KMS:RV370:RESUME] garbage on screen (console or X) after suspend-resume with radeon (KMS only)
https://bugs.freedesktop.org/show_bug.cgi?id=51190 --- Comment #8 from cyberbat 2012-06-20 11:00:28 PDT --- I got following in dmesg after restoring after mem > /sys/power/state: radeon :01:00.0: restoring config space at offset 0xf (was 0x1ff, writing 0x10a) radeon :01:00.0: restoring config space at offset 0x6 (was 0x0, writing 0xc010) radeon :01:00.0: restoring config space at offset 0x4 (was 0x8, writing 0xd008) radeon :01:00.0: restoring config space at offset 0x3 (was 0x0, writing 0x8) radeon :01:00.0: restoring config space at offset 0x1 (was 0x100107, writing 0x100507) ... [drm] PCIE GART of 512M enabled (table at 0xD004). radeon :01:00.0: WB enabled [drm] radeon: ring at 0xB0001000 [drm:r100_ring_test] *ERROR* radeon: ring test failed (scratch(0x15E4)=0xCAFEDEAD) [drm:r100_cp_init] *ERROR* radeon: cp isn't working (-22). radeon :01:00.0: failed initializing CP (-22). -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PULL] first drm-intel-next for 3.6
Hi Dave, Resend of the pull as request on irc, all the fancy details are below the cut. Mail is completely unchanged, so it's still babbling about rc2 and regression that are tracked down by now ;-) Cheers, Daniel --- Hi Dave, rc2 is out the door so I've figured I'll annoy you with the first -next pull request for 3.6 already. Highlights: - new wait_rendring_timeout interface (Ben) - l3 cache remapping and error uevent support (Ben) - even more infoframes work from Paulo - gen4 hotplug rework from Chris - prep work to make Laurent Pincharts original mode constification for connector->mode_fixup possible QA reported a few new bugs this time around, but no regressions afact. For 3.5 the only thing I'm aware of is the edp vdd dmesg spam Linus originally reported - it looks like that might have been introduced in 3.5. But somehow my brain is routinely offline when I work on that issue, so things seem to take forever (and atm I'm at patch v4 for that little problem). Yours, Daniel The following changes since commit 63bc620b45af8c743ac291c8725933278c712692: radeon: add radeon prime vmap support. (2012-05-31 14:14:01 +0100) are available in the git repository at: git://people.freedesktop.org/~danvet/drm-intel tags/drm-intel-next-2012-06-04 for you to fetch changes up to 1523c310b3ed964b71a8db16f70c3bc21cc0642e: drm/i915: add min freq control to debugfs (2012-06-04 21:34:47 +0200) Ben Widawsky (8): drm/i915: timeout parameter for seqno wait drm/i915: improve i915_wait_request_begin trace drm/i915: wait render timeout ioctl drm/i915: s/i915_wait_request/i915_wait_seqno/g drm/i915: Dynamic Parity Detection handling drm/i915: enable parity error interrupts drm/i915: remap l3 on hw init drm/i915: l3 parity sysfs interface Chris Wilson (6): drm/i915: All members of gen4 have hotplug, so unconditionally enable its irq drm/i915: Inspect the right status bits for DP/HDMI hotplug on gen4 drm/i915: SDVO hotplug have different interrupt status bits for i915/i965/g4x drm/i915/hdmi: Query the live connector status bit for G4x drm/i915/dp: For consistency use the DP hotplug synonyms drm/i915/hdmi: Fix reg values for g4x_hdmi_connected Daniel Vetter (14): drm/i915: clarify preferred sdvo input mode code drm/i915: don't silently ignore sdvo mode_set failures drm/i915: there's no cxsr on ilk drm/i915: reuse the sdvo tv clock adjustment in ilk mode_set drm/i915: s/mdelay/msleep/ in the sdvo detect function drm/i915: ivybridge_handle_parity_error should be static drm/i915: initialize the parity work only once drm/i915: simplify sysfs setup code Merge remote-tracking branch 'airlied/drm-prime-vmap' into drm-intel-next-queued drm/i915: clarify IBX dp workaround drm/i915: extract object active state flushing code drm/i915: compute the target_clock for edp directly drm/i915: adjusted_mode->clock in the dp mode_fixup drm/i915: don't chnage the original mode in dp_mode_fixup Jesse Barnes (1): drm/i915: add min freq control to debugfs Paulo Zanoni (11): drm/i915: add set_infoframes to struct intel_hdmi drm/i915: properly alternate between DVI and HDMI drm/i915: only set the HDMI port on the DIP once drm/i915: enable DIP before enabling each InfoFrame drm/i915: don't wait for vblank while writing InfoFrames drm/i915: explicitly disable the DIPs we're not using drm/i915: disable DIP while changing the port drm/i915: don't write 0 to DIP control at HDMI init drm/i915: don't set SDVO_BORDER_ENABLE when we're HDMI drm/i915: remove comment about HSW HDMI DIPs drm/i915: add some barriers when changing DIPs drivers/gpu/drm/i915/i915_debugfs.c | 66 +++ drivers/gpu/drm/i915/i915_dma.c |1 + drivers/gpu/drm/i915/i915_drv.h | 11 +- drivers/gpu/drm/i915/i915_gem.c | 242 +++ drivers/gpu/drm/i915/i915_irq.c | 171 - drivers/gpu/drm/i915/i915_reg.h | 56 +- drivers/gpu/drm/i915/i915_sysfs.c | 127 +++- drivers/gpu/drm/i915/i915_trace.h | 28 ++- drivers/gpu/drm/i915/intel_ddi.c|3 +- drivers/gpu/drm/i915/intel_display.c| 47 ++--- drivers/gpu/drm/i915/intel_dp.c | 53 +++--- drivers/gpu/drm/i915/intel_drv.h|9 +- drivers/gpu/drm/i915/intel_hdmi.c | 318 +-- drivers/gpu/drm/i915/intel_overlay.c|4 +- drivers/gpu/drm/i915/intel_panel.c |2 +- drivers/gpu/drm/i915/intel_ringbuffer.c | 16 +- drivers/gpu/drm/i915/intel_sdvo.c | 56 -- include/drm/i915_drm.h | 10 + 18 files changed, 965 insertions(+), 255 deletions(-) -- Daniel Vetter Mail: dan...@ffwll.ch Mobile: +41 (0)79 365 57 4
Re: drm-next radeon patches
Hi Christian, the 3rd patch doesnt' apply cleanly to my -next tree, Can you rebase them onto my current drm-core-next? Dave. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/edid: Do dmt_modes_for_range less aggressively
On Tue, 2012-06-19 at 14:55 -0400, Adam Jackson wrote: > Only fill it in for pre-1.1 monitors - when GTF hadn't yet been defined > - or for EDID 1.4's explicit "just a range, not a timing formula" case. > > Bugzilla: https://bugs.freedesktop.org/51146 > Signed-off-by: Adam Jackson Self-nak, at any rate hold off from doing this for the moment. The bz above is turning out more subtle than I was expecting. I'm really not a fan of how the extra_modes changes introduced new failure cases despite my best efforts to be conservative. Wish I'd said no harder. - ajax signature.asc Description: This is a digitally signed message part ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 51273] New: Kernel panic with dynpm and kernel 3.5
https://bugs.freedesktop.org/show_bug.cgi?id=51273 Bug #: 51273 Summary: Kernel panic with dynpm and kernel 3.5 Classification: Unclassified Product: DRI Version: XOrg CVS Platform: Other OS/Version: All Status: NEW Severity: normal Priority: medium Component: DRM/Radeon AssignedTo: dri-devel@lists.freedesktop.org ReportedBy: ern...@gmail.com Hi, I've been running with the following in my rc.local for a while: echo dynpm > /sys/class/drm/card0/device/power_method But when I tried a 3.5 kernel today I got a kernel panic as soon as dynpm was enabled! Ubuntu kernel 3.5.0-1.1-generic 01:00.0 VGA compatible controller: Advanced Micro Devices [AMD] nee ATI Barts PRO [ATI Radeon HD 6800 -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 51273] Kernel panic with dynpm and kernel 3.5
https://bugs.freedesktop.org/show_bug.cgi?id=51273 Alex Deucher changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #1 from Alex Deucher 2012-06-20 14:49:19 PDT --- Fix already upstream: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=commitdiff;h=0ec0612a80f957000999c3f7b31a84e3558c719d -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/5] DRM i.MX: Add parallel display support
On Thu, Jun 14, 2012 at 03:43:24PM +0200, Sascha Hauer wrote:
> +static const struct of_device_id imx_pd_dt_ids[] = {
> + { .compatible = "fsl,imx-parallel-display", .data = NULL, },
Can we use particular soc name to define the compatible string? Also,
the .data initialization seems not needed.
> + { /* sentinel */ }
> +};
--
Regards,
Shawn
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/5] DRM: Add i.MX drm core support
On Thu, Jun 14, 2012 at 03:43:23PM +0200, Sascha Hauer wrote:
...
> +struct drm_device *imx_drm_device_get(void)
> +{
> + struct imx_drm_device *imxdrm = __imx_drm_device();
> + struct imx_drm_encoder *enc;
> + struct imx_drm_connector *con;
> + struct imx_drm_crtc *crtc;
> +
> + mutex_lock(&imxdrm->mutex);
> +
> + list_for_each_entry(enc, &imxdrm->encoder_list, list) {
> + if (!try_module_get(enc->owner)) {
> + dev_err(imxdrm->dev, "could not get module %s\n",
> + module_name(enc->owner));
> + goto unwind_enc;
> + }
> + }
> +
> + list_for_each_entry(con, &imxdrm->connector_list, list) {
> + if (!try_module_get(con->owner)) {
> + dev_err(imxdrm->dev, "could not get module %s\n",
> + module_name(con->owner));
> + goto unwind_con;
> + }
> + }
> +
> + list_for_each_entry(crtc, &imxdrm->crtc_list, list) {
> + if (!try_module_get(crtc->owner)) {
> + dev_err(imxdrm->dev, "could not get module %s\n",
> + module_name(crtc->owner));
> + goto unwind_crtc;
> + }
> + }
> +
> + imxdrm->references++;
> +
> + mutex_unlock(&imxdrm->mutex);
> +
> + return imx_drm_device->drm;
Though I'm not quite sure about the point of retrieving the static
variable imx_drm_device from calling __imx_drm_device(), shouldn't
imxdrm be used here since you already retrieve it?
> +
> +unwind_crtc:
> + list_for_each_entry_continue_reverse(crtc, &imxdrm->crtc_list, list)
> + module_put(crtc->owner);
> +unwind_con:
> + list_for_each_entry_continue_reverse(con, &imxdrm->connector_list, list)
> + module_put(con->owner);
> +unwind_enc:
> + list_for_each_entry_continue_reverse(enc, &imxdrm->encoder_list, list)
> + module_put(enc->owner);
> +
> + mutex_unlock(&imxdrm->mutex);
> +
> + return NULL;
> +
> +}
> +EXPORT_SYMBOL_GPL(imx_drm_device_get);
...
> +/*
> + * register a connector to the drm core
> + */
> +static int imx_drm_connector_register(
> + struct imx_drm_connector *imx_drm_connector)
> +{
> + struct imx_drm_device *imxdrm = __imx_drm_device();
> + int ret;
> +
> + drm_connector_init(imxdrm->drm, imx_drm_connector->connector,
> + imx_drm_connector->connector->funcs,
> + imx_drm_connector->connector->connector_type);
> + drm_mode_group_reinit(imxdrm->drm);
> + ret = drm_sysfs_connector_add(imx_drm_connector->connector);
> + if (ret)
> + goto err;
Simply return ret to save the err path?
> +
> + return 0;
> +err:
> +
> + return ret;
> +}
...
> +/*
> + * imx_drm_add_encoder - add a new encoder
> + */
> +int imx_drm_add_encoder(struct drm_encoder *encoder,
> + struct imx_drm_encoder **newenc, struct module *owner)
> +{
> + struct imx_drm_device *imxdrm = __imx_drm_device();
> + struct imx_drm_encoder *imx_drm_encoder;
> + int ret;
> +
> + mutex_lock(&imxdrm->mutex);
> +
> + if (imxdrm->references) {
> + ret = -EBUSY;
> + goto err_busy;
> + }
> +
> + imx_drm_encoder = kzalloc(sizeof(struct imx_drm_encoder), GFP_KERNEL);
sizeof(*imx_drm_encoder)
> + if (!imx_drm_encoder) {
> + ret = -ENOMEM;
> + goto err_alloc;
> + }
> +
> + imx_drm_encoder->encoder = encoder;
> + imx_drm_encoder->owner = owner;
> +
> + ret = imx_drm_encoder_register(imx_drm_encoder);
> + if (ret) {
> + kfree(imx_drm_encoder);
> + ret = -ENOMEM;
> + goto err_register;
> + }
> +
> + list_add_tail(&imx_drm_encoder->list, &imxdrm->encoder_list);
> +
> + *newenc = imx_drm_encoder;
> +
> + mutex_unlock(&imxdrm->mutex);
> +
> + return 0;
> +
> +err_register:
> + kfree(imx_drm_encoder);
> +err_alloc:
> +err_busy:
> + mutex_unlock(&imxdrm->mutex);
> +
> + return ret;
> +}
> +EXPORT_SYMBOL_GPL(imx_drm_add_encoder);
...
> +/*
> + * imx_drm_add_connector - add a connector
> + */
> +int imx_drm_add_connector(struct drm_connector *connector,
> + struct imx_drm_connector **new_con,
> + struct module *owner)
> +{
> + struct imx_drm_device *imxdrm = __imx_drm_device();
> + struct imx_drm_connector *imx_drm_connector;
> + int ret;
> +
> + mutex_lock(&imxdrm->mutex);
> +
> + if (imxdrm->references) {
> + ret = -EBUSY;
> + goto err_busy;
> + }
> +
> + imx_drm_connector = kzalloc(sizeof(struct imx_drm_connector),
sizeof(*imx_drm_connector)
> + GFP_KERNEL);
> + if (!imx_drm_connector) {
> + ret = -ENOMEM;
> + goto err_alloc;
> + }
> +
> + imx_drm_connector->connector = connector;
> +
[PATCH] drm via: initialize object_idr
The field obejct_idr of struct drm_via_private was introduced with the commit http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=commitdiff;h=77ee8f3825054f23b17e9c8f728f061defd86cdc . In that patch idr_init(&dev->object_name_idr) was called instead of idr_init(&dev_priv->object_idr) by mistake, leaving the dev_priv->object_idr uninitialized. To be more exact, the object_idr buffer is filled with zeros because of kzalloc(), but the dev_priv->object_idr.lock spinlock can cause system freeze at lib/idr.c:move_to_free_list() when spin_lock_irqsave() is called on this spinlock. Signed-off-by: M?rton N?meth Signed-off-by: James Simmons diff --git a/drivers/gpu/drm/via/via_map.c b/drivers/gpu/drm/via/via_map.c index 1f18225..240bc49 100644 --- a/drivers/gpu/drm/via/via_map.c +++ b/drivers/gpu/drm/via/via_map.c @@ -100,12 +100,10 @@ int via_driver_load(struct drm_device *dev, unsigned long chipset) if (dev_priv == NULL) return -ENOMEM; + idr_init(&dev_priv->object_idr); dev->dev_private = (void *)dev_priv; - dev_priv->chipset = chipset; - idr_init(&dev->object_name_idr); - pci_set_master(dev->pdev); ret = drm_vblank_init(dev, 1);
[Bug 50422] Furmark.exe crash with wine (32 bits under 64 bits) with llvm-3.1 and r600-llvm-compiler enabled
https://bugs.freedesktop.org/show_bug.cgi?id=50422 --- Comment #2 from Tom Stellard 2012-06-19 19:11:00 PDT --- I've been seeing a few strange crashes in the LLVM backend when using wine. What version of wine are you using? Does it work with an older version of wine? -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[PATCH V2 12/16] drm/radeon: Make radeon card usable for Loongson.
On Tue, Jun 19, 2012 at 3:19 PM, Lucas Stach wrote:
> Hello Huacai,
>
> Am Dienstag, den 19.06.2012, 14:50 +0800 schrieb Huacai Chen:
>> 1, Use 32-bit DMA as a workaround (Loongson has a hardware bug that it
>> ? ?doesn't support DMA address above 4GB).
>
> This is a bug of your platform/CPU and should be fixed at a lower level,
> not in every driver. While radeon might be the only device using 40bit
> DMA right know, it is very well possible that other devices pop up in
> the future. So please fix your platform code to disallow >32bit DMA.
Hi, Lucas
I have fixed my platform code to disallow >32bit DMA. This method fix
the DMA problems in SATA and sound card, but fails on radeon (display
is OK, but accerlaration is unusable), because need_dma32 not only
affect dma_mask/coherent_dma_mask, but also affect th gfp_flags of
ttm_get_pages(). Platform code fixes cannot solve the problem of
ttm_get_pages(), could you please give me some suggestions? Thank you.
>
>> 2, Read vga bios offered by system firmware.
>> 3, Handle io prot correctly for MIPS.
>
> This seems good to me, but you should really split this out in a
> separate TTM patch.
>
>> 4, Don't use swiotlb on Loongson machines (when use swiotlb, GPU reset
>> ? ?occurs at resume from suspend).
>>
> While SWIOTLB might not be a common setup, simply ignoring it because it
> doesn't work on your platform is the wrong thing to do. Could you please
> try to root-cause the issue?
>
> Thanks,
> Lucas
>
>> Signed-off-by: Huacai Chen
>> Signed-off-by: Hongliang Tao
>> Signed-off-by: Hua Yan
>> Cc: dri-devel at lists.freedesktop.org
>> ---
>> ?drivers/gpu/drm/drm_vm.c ? ? ? ? ? ? ? | ? ?2 +-
>> ?drivers/gpu/drm/radeon/radeon_bios.c ? | ? 32
>>
>> ?drivers/gpu/drm/radeon/radeon_device.c | ? ?5 +
>> ?drivers/gpu/drm/radeon/radeon_ttm.c ? ?| ? ?6 +++---
>> ?drivers/gpu/drm/ttm/ttm_bo_util.c ? ? ?| ? ?2 +-
>> ?include/drm/drm_sarea.h ? ? ? ? ? ? ? ?| ? ?2 ++
>> ?6 files changed, 44 insertions(+), 5 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/drm_vm.c b/drivers/gpu/drm/drm_vm.c
>> index 961ee08..3f06166 100644
>> --- a/drivers/gpu/drm/drm_vm.c
>> +++ b/drivers/gpu/drm/drm_vm.c
>> @@ -62,7 +62,7 @@ static pgprot_t drm_io_prot(uint32_t map_type, struct
>> vm_area_struct *vma)
>> ? ? ? ? ? ? ? tmp = pgprot_writecombine(tmp);
>> ? ? ? else
>> ? ? ? ? ? ? ? tmp = pgprot_noncached(tmp);
>> -#elif defined(__sparc__) || defined(__arm__)
>> +#elif defined(__sparc__) || defined(__arm__) || defined(__mips__)
>> ? ? ? tmp = pgprot_noncached(tmp);
>> ?#endif
>> ? ? ? return tmp;
>> diff --git a/drivers/gpu/drm/radeon/radeon_bios.c
>> b/drivers/gpu/drm/radeon/radeon_bios.c
>> index 501f488..2630e22 100644
>> --- a/drivers/gpu/drm/radeon/radeon_bios.c
>> +++ b/drivers/gpu/drm/radeon/radeon_bios.c
>> @@ -29,6 +29,7 @@
>> ?#include "radeon_reg.h"
>> ?#include "radeon.h"
>> ?#include "atom.h"
>> +#include
>>
>> ?#include
>> ?#include
>> @@ -73,6 +74,32 @@ static bool igp_read_bios_from_vram(struct radeon_device
>> *rdev)
>> ? ? ? return true;
>> ?}
>>
>> +#ifdef CONFIG_CPU_LOONGSON3
>> +extern u64 vgabios_addr;
>> +static bool loongson3_read_bios(struct radeon_device *rdev)
>> +{
>> + ? ? u8 *bios;
>> + ? ? resource_size_t size = 512 * 1024; /* ??? */
>> +
>> + ? ? rdev->bios = NULL;
>> +
>> + ? ? bios = (u8 *)vgabios_addr;
>> + ? ? if (!bios) {
>> + ? ? ? ? ? ? return false;
>> + ? ? }
>> +
>> + ? ? if (size == 0 || bios[0] != 0x55 || bios[1] != 0xaa) {
>> + ? ? ? ? ? ? return false;
>> + ? ? }
>> + ? ? rdev->bios = kmalloc(size, GFP_KERNEL);
>> + ? ? if (rdev->bios == NULL) {
>> + ? ? ? ? ? ? return false;
>> + ? ? }
>> + ? ? memcpy(rdev->bios, bios, size);
>> + ? ? return true;
>> +}
>> +#endif
>> +
>> ?static bool radeon_read_bios(struct radeon_device *rdev)
>> ?{
>> ? ? ? uint8_t __iomem *bios;
>> @@ -490,6 +517,11 @@ bool radeon_get_bios(struct radeon_device *rdev)
>> ? ? ? if (r == false) {
>> ? ? ? ? ? ? ? r = radeon_read_disabled_bios(rdev);
>> ? ? ? }
>> +#ifdef CONFIG_CPU_LOONGSON3
>> + ? ? if (r == false) {
>> + ? ? ? ? ? ? r = loongson3_read_bios(rdev);
>> + ? ? }
>> +#endif
>> ? ? ? if (r == false || rdev->bios == NULL) {
>> ? ? ? ? ? ? ? DRM_ERROR("Unable to locate a BIOS ROM\n");
>> ? ? ? ? ? ? ? rdev->bios = NULL;
>> diff --git a/drivers/gpu/drm/radeon/radeon_device.c
>> b/drivers/gpu/drm/radeon/radeon_device.c
>> index 066c98b..8aac7ab 100644
>> --- a/drivers/gpu/drm/radeon/radeon_device.c
>> +++ b/drivers/gpu/drm/radeon/radeon_device.c
>> @@ -777,6 +777,11 @@ int radeon_device_init(struct radeon_device *rdev,
>> ? ? ? ? ? (rdev->family < CHIP_RS400))
>> ? ? ? ? ? ? ? rdev->need_dma32 = true;
>>
>> +#ifdef CONFIG_CPU_LOONGSON3
>> + ? ? /* Workaround: Loongson 3 doesn't support 40-bits DMA */
>> + ? ? rdev->need_dma32 = true;
>> +#endif
>> +
>> ? ? ? dma_bits = rdev->need_dma32 ? 32 : 40;
>> ? ? ? r = pci_set_dma_mask(rdev->pdev, DMA_BIT_MASK(dma_bits));
>> ? ? ? if (r) {
>> diff --git a/drivers/gpu/drm/radeon/radeon_
[PATCH V2 12/16] drm/radeon: Make radeon card usable for Loongson.
Am Mittwoch, den 20.06.2012, 14:12 +0800 schrieb Huacai Chen: > On Tue, Jun 19, 2012 at 3:19 PM, Lucas Stach wrote: > > Hello Huacai, > > > > Am Dienstag, den 19.06.2012, 14:50 +0800 schrieb Huacai Chen: > >> 1, Use 32-bit DMA as a workaround (Loongson has a hardware bug that it > >>doesn't support DMA address above 4GB). > > > > This is a bug of your platform/CPU and should be fixed at a lower level, > > not in every driver. While radeon might be the only device using 40bit > > DMA right know, it is very well possible that other devices pop up in > > the future. So please fix your platform code to disallow >32bit DMA. > > Hi, Lucas > I have fixed my platform code to disallow >32bit DMA. This method fix > the DMA problems in SATA and sound card, but fails on radeon (display > is OK, but accerlaration is unusable), because need_dma32 not only > affect dma_mask/coherent_dma_mask, but also affect th gfp_flags of > ttm_get_pages(). Platform code fixes cannot solve the problem of > ttm_get_pages(), could you please give me some suggestions? Thank you. If your platform does disallow >32bit DMA masks, radeon should already do the right thing and set need_dma32 to true. Have a look at radeon_device.c:783 Make sure you really disallow >32bit DMA masks, not just prefer <=32bit masks. > > > > >> 2, Read vga bios offered by system firmware. > >> 3, Handle io prot correctly for MIPS. > > > > This seems good to me, but you should really split this out in a > > separate TTM patch. > > > >> 4, Don't use swiotlb on Loongson machines (when use swiotlb, GPU reset > >>occurs at resume from suspend). > >> > > While SWIOTLB might not be a common setup, simply ignoring it because it > > doesn't work on your platform is the wrong thing to do. Could you please > > try to root-cause the issue? > > [snip]
[PATCH V2 12/16] drm/radeon: Make radeon card usable for Loongson.
On Wed, Jun 20, 2012 at 2:38 PM, Lucas Stach wrote: > Am Mittwoch, den 20.06.2012, 14:12 +0800 schrieb Huacai Chen: >> On Tue, Jun 19, 2012 at 3:19 PM, Lucas Stach wrote: >> > Hello Huacai, >> > >> > Am Dienstag, den 19.06.2012, 14:50 +0800 schrieb Huacai Chen: >> >> 1, Use 32-bit DMA as a workaround (Loongson has a hardware bug that it >> >> ? ?doesn't support DMA address above 4GB). >> > >> > This is a bug of your platform/CPU and should be fixed at a lower level, >> > not in every driver. While radeon might be the only device using 40bit >> > DMA right know, it is very well possible that other devices pop up in >> > the future. So please fix your platform code to disallow >32bit DMA. >> >> Hi, Lucas >> I have fixed my platform code to ?disallow >32bit DMA. This method fix >> the DMA problems in SATA and sound card, but fails on radeon (display >> is OK, but accerlaration is unusable), because need_dma32 not only >> affect dma_mask/coherent_dma_mask, but also affect th gfp_flags of >> ttm_get_pages(). Platform code fixes cannot solve the problem of >> ttm_get_pages(), could you please give me some suggestions? Thank you. > > If your platform does disallow >32bit DMA masks, radeon should already > do the right thing and set need_dma32 to true. Have a look at > radeon_device.c:783 > > Make sure you really disallow >32bit DMA masks, not just prefer <=32bit > masks. I know, my previous code change is provide an arch-specific dma_map_ops::set_dma_mask() and dma_set_coherent_mask() to force the dma_mask/coherent_dma_mask <=bit, but always return success. In fact the right way is return an error code when driver try to set the dma_mask >32bit. Thank you very much! >> >> > >> >> 2, Read vga bios offered by system firmware. >> >> 3, Handle io prot correctly for MIPS. >> > >> > This seems good to me, but you should really split this out in a >> > separate TTM patch. >> > >> >> 4, Don't use swiotlb on Loongson machines (when use swiotlb, GPU reset >> >> ? ?occurs at resume from suspend). >> >> >> > While SWIOTLB might not be a common setup, simply ignoring it because it >> > doesn't work on your platform is the wrong thing to do. Could you please >> > try to root-cause the issue? >> > > [snip] > >
[PATCH V2 12/16] drm/radeon: Make radeon card usable for Loongson.
On Wed, Jun 20, 2012 at 9:26 AM, Alex Deucher wrote:
> On Tue, Jun 19, 2012 at 9:57 AM, j.glisse wrote:
>> On Tue, Jun 19, 2012 at 02:50:20PM +0800, Huacai Chen wrote:
>>> 1, Use 32-bit DMA as a workaround (Loongson has a hardware bug that it
>>> ? ?doesn't support DMA address above 4GB).
>>> 2, Read vga bios offered by system firmware.
>>> 3, Handle io prot correctly for MIPS.
>>> 4, Don't use swiotlb on Loongson machines (when use swiotlb, GPU reset
>>> ? ?occurs at resume from suspend).
>>>
>>> Signed-off-by: Huacai Chen
>>> Signed-off-by: Hongliang Tao
>>> Signed-off-by: Hua Yan
>>> Cc: dri-devel at lists.freedesktop.org
>>> ---
>>> ?drivers/gpu/drm/drm_vm.c ? ? ? ? ? ? ? | ? ?2 +-
>>> ?drivers/gpu/drm/radeon/radeon_bios.c ? | ? 32
>>>
>>> ?drivers/gpu/drm/radeon/radeon_device.c | ? ?5 +
>>> ?drivers/gpu/drm/radeon/radeon_ttm.c ? ?| ? ?6 +++---
>>> ?drivers/gpu/drm/ttm/ttm_bo_util.c ? ? ?| ? ?2 +-
>>> ?include/drm/drm_sarea.h ? ? ? ? ? ? ? ?| ? ?2 ++
>>> ?6 files changed, 44 insertions(+), 5 deletions(-)
>>>
>>> diff --git a/drivers/gpu/drm/drm_vm.c b/drivers/gpu/drm/drm_vm.c
>>> index 961ee08..3f06166 100644
>>> --- a/drivers/gpu/drm/drm_vm.c
>>> +++ b/drivers/gpu/drm/drm_vm.c
>>> @@ -62,7 +62,7 @@ static pgprot_t drm_io_prot(uint32_t map_type, struct
>>> vm_area_struct *vma)
>>> ? ? ? ? ? ? ? tmp = pgprot_writecombine(tmp);
>>> ? ? ? else
>>> ? ? ? ? ? ? ? tmp = pgprot_noncached(tmp);
>>> -#elif defined(__sparc__) || defined(__arm__)
>>> +#elif defined(__sparc__) || defined(__arm__) || defined(__mips__)
>>> ? ? ? tmp = pgprot_noncached(tmp);
>>> ?#endif
>>> ? ? ? return tmp;
>>> diff --git a/drivers/gpu/drm/radeon/radeon_bios.c
>>> b/drivers/gpu/drm/radeon/radeon_bios.c
>>> index 501f488..2630e22 100644
>>> --- a/drivers/gpu/drm/radeon/radeon_bios.c
>>> +++ b/drivers/gpu/drm/radeon/radeon_bios.c
>>> @@ -29,6 +29,7 @@
>>> ?#include "radeon_reg.h"
>>> ?#include "radeon.h"
>>> ?#include "atom.h"
>>> +#include
>>>
>>> ?#include
>>> ?#include
>>> @@ -73,6 +74,32 @@ static bool igp_read_bios_from_vram(struct radeon_device
>>> *rdev)
>>> ? ? ? return true;
>>> ?}
>>>
>>> +#ifdef CONFIG_CPU_LOONGSON3
>>> +extern u64 vgabios_addr;
>>
>> Ugly, is this how platform specific stuff are handled usualy ? I hope not,
>> i would rather see a platform specific function such as
>> loongson3_get_vga_bios.
>
> It could be hooked in as a pci quirk similar to how we read the vbios
> from the legacy vga location on x86.
Hi, Alex, the method you said is pci_fixup_video() in arch/x86/pci/fixup.c?
>
> Alex
>
>>
>> Cheers,
>> Jerome
>>
>>> +static bool loongson3_read_bios(struct radeon_device *rdev)
>>> +{
>>> + ? ? u8 *bios;
>>> + ? ? resource_size_t size = 512 * 1024; /* ??? */
>>> +
>>> + ? ? rdev->bios = NULL;
>>> +
>>> + ? ? bios = (u8 *)vgabios_addr;
>>> + ? ? if (!bios) {
>>> + ? ? ? ? ? ? return false;
>>> + ? ? }
>>> +
>>> + ? ? if (size == 0 || bios[0] != 0x55 || bios[1] != 0xaa) {
>>> + ? ? ? ? ? ? return false;
>>> + ? ? }
>>> + ? ? rdev->bios = kmalloc(size, GFP_KERNEL);
>>> + ? ? if (rdev->bios == NULL) {
>>> + ? ? ? ? ? ? return false;
>>> + ? ? }
>>> + ? ? memcpy(rdev->bios, bios, size);
>>> + ? ? return true;
>>> +}
>>> +#endif
>>> +
>>> ?static bool radeon_read_bios(struct radeon_device *rdev)
>>> ?{
>>> ? ? ? uint8_t __iomem *bios;
>>> @@ -490,6 +517,11 @@ bool radeon_get_bios(struct radeon_device *rdev)
>>> ? ? ? if (r == false) {
>>> ? ? ? ? ? ? ? r = radeon_read_disabled_bios(rdev);
>>> ? ? ? }
>>> +#ifdef CONFIG_CPU_LOONGSON3
>>> + ? ? if (r == false) {
>>> + ? ? ? ? ? ? r = loongson3_read_bios(rdev);
>>> + ? ? }
>>> +#endif
>>> ? ? ? if (r == false || rdev->bios == NULL) {
>>> ? ? ? ? ? ? ? DRM_ERROR("Unable to locate a BIOS ROM\n");
>>> ? ? ? ? ? ? ? rdev->bios = NULL;
>>> diff --git a/drivers/gpu/drm/radeon/radeon_device.c
>>> b/drivers/gpu/drm/radeon/radeon_device.c
>>> index 066c98b..8aac7ab 100644
>>> --- a/drivers/gpu/drm/radeon/radeon_device.c
>>> +++ b/drivers/gpu/drm/radeon/radeon_device.c
>>> @@ -777,6 +777,11 @@ int radeon_device_init(struct radeon_device *rdev,
>>> ? ? ? ? ? (rdev->family < CHIP_RS400))
>>> ? ? ? ? ? ? ? rdev->need_dma32 = true;
>>>
>>> +#ifdef CONFIG_CPU_LOONGSON3
>>> + ? ? /* Workaround: Loongson 3 doesn't support 40-bits DMA */
>>> + ? ? rdev->need_dma32 = true;
>>> +#endif
>>> +
>>> ? ? ? dma_bits = rdev->need_dma32 ? 32 : 40;
>>> ? ? ? r = pci_set_dma_mask(rdev->pdev, DMA_BIT_MASK(dma_bits));
>>> ? ? ? if (r) {
>>> diff --git a/drivers/gpu/drm/radeon/radeon_ttm.c
>>> b/drivers/gpu/drm/radeon/radeon_ttm.c
>>> index c94a225..f49bdd1 100644
>>> --- a/drivers/gpu/drm/radeon/radeon_ttm.c
>>> +++ b/drivers/gpu/drm/radeon/radeon_ttm.c
>>> @@ -630,7 +630,7 @@ static int radeon_ttm_tt_populate(struct ttm_tt *ttm)
>>> ? ? ? }
>>> ?#endif
>>>
>>> -#ifdef CONFIG_SWIOTLB
>>> +#if defined(CONFIG_SWIOTLB) && !defined(CONFIG_CPU_LOONGSON3)
>>> ? ? ? if (swiotlb_nr_tbl()) {
>>> ? ? ? ? ? ? ? return ttm_dma_populate(>t->ttm, rdev->dev);
[PATCH 1/3] drm/exynos: Use devm_* functions in exynos_drm_fimd.c
2012/6/19, Sachin Kamat :
> devm_* functions are device managed functions and make error handling
> and cleanup cleaner and simpler.
>
> Signed-off-by: Sachin Kamat
> Signed-off-by: Sachin Kamat
> ---
> drivers/gpu/drm/exynos/exynos_drm_fimd.c | 40
> ++
> 1 files changed, 8 insertions(+), 32 deletions(-)
>
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> index 29fdbfe..a68d2b3 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> @@ -78,7 +78,6 @@ struct fimd_context {
> struct drm_crtc *crtc;
> struct clk *bus_clk;
> struct clk *lcd_clk;
> - struct resource *regs_res;
> void __iomem*regs;
> struct fimd_win_datawin_data[WINDOWS_NR];
> unsigned intclkdiv;
> @@ -813,7 +812,7 @@ static int __devinit fimd_probe(struct platform_device
> *pdev)
> return -EINVAL;
> }
>
> - ctx = kzalloc(sizeof(*ctx), GFP_KERNEL);
> + ctx = devm_kzalloc(&pdev->dev, sizeof(*ctx), GFP_KERNEL);
> if (!ctx)
> return -ENOMEM;
>
> @@ -838,33 +837,26 @@ static int __devinit fimd_probe(struct platform_device
> *pdev)
> goto err_clk;
> }
>
> - ctx->regs_res = request_mem_region(res->start, resource_size(res),
> -dev_name(dev));
> - if (!ctx->regs_res) {
> - dev_err(dev, "failed to claim register region\n");
> - ret = -ENOENT;
> - goto err_clk;
> - }
> -
> - ctx->regs = ioremap(res->start, resource_size(res));
> + ctx->regs = devm_request_and_ioremap(&pdev->dev, res);
> if (!ctx->regs) {
> dev_err(dev, "failed to map registers\n");
> ret = -ENXIO;
> - goto err_req_region_io;
> + goto err_clk;
> }
>
> res = platform_get_resource(pdev, IORESOURCE_IRQ, 0);
> if (!res) {
> dev_err(dev, "irq request failed.\n");
> - goto err_req_region_irq;
> + goto err_clk;
> }
>
> ctx->irq = res->start;
>
> - ret = request_irq(ctx->irq, fimd_irq_handler, 0, "drm_fimd", ctx);
> - if (ret < 0) {
> + ret = devm_request_irq(&pdev->dev, ctx->irq, fimd_irq_handler,
> + 0, "drm_fimd", ctx);
> + if (ret) {
> dev_err(dev, "irq request failed.\n");
> - goto err_req_irq;
> + goto err_clk;
> }
>
> ctx->vidcon0 = pdata->vidcon0;
> @@ -899,14 +891,6 @@ static int __devinit fimd_probe(struct platform_device
> *pdev)
>
> return 0;
>
> -err_req_irq:
> -err_req_region_irq:
> - iounmap(ctx->regs);
> -
> -err_req_region_io:
> - release_resource(ctx->regs_res);
> - kfree(ctx->regs_res);
> -
> err_clk:
> clk_disable(ctx->lcd_clk);
> clk_put(ctx->lcd_clk);
> @@ -916,7 +900,6 @@ err_bus_clk:
> clk_put(ctx->bus_clk);
>
> err_clk_get:
> - kfree(ctx);
> return ret;
> }
>
> @@ -944,13 +927,6 @@ out:
> clk_put(ctx->lcd_clk);
> clk_put(ctx->bus_clk);
>
> - iounmap(ctx->regs);
> - release_resource(ctx->regs_res);
> - kfree(ctx->regs_res);
> - free_irq(ctx->irq, ctx);
> -
> - kfree(ctx);
> -
> return 0;
> }
>
> --
> 1.7.4.1
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>
Applied.
Thanks,
Inki Dae
[PATCH 2/3] drm/exynos: Use devm_* functions in exynos_hdmi.c
2012/6/19, Sachin Kamat :
> devm_* functions are device managed functions and make error handling
> and cleanup cleaner and simpler.
>
> Signed-off-by: Sachin Kamat
> Signed-off-by: Sachin Kamat
> ---
> drivers/gpu/drm/exynos/exynos_hdmi.c | 36
> ++---
> 1 files changed, 7 insertions(+), 29 deletions(-)
>
> diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c
> b/drivers/gpu/drm/exynos/exynos_hdmi.c
> index a137e9e..5816b0f 100644
> --- a/drivers/gpu/drm/exynos/exynos_hdmi.c
> +++ b/drivers/gpu/drm/exynos/exynos_hdmi.c
> @@ -63,7 +63,6 @@ struct hdmi_context {
> booldvi_mode;
> struct mutexhdmi_mutex;
>
> - struct resource *regs_res;
> void __iomem*regs;
> unsigned intexternal_irq;
> unsigned intinternal_irq;
> @@ -2280,16 +2279,17 @@ static int __devinit hdmi_probe(struct
> platform_device *pdev)
> return -EINVAL;
> }
>
> - drm_hdmi_ctx = kzalloc(sizeof(*drm_hdmi_ctx), GFP_KERNEL);
> + drm_hdmi_ctx = devm_kzalloc(&pdev->dev, sizeof(*drm_hdmi_ctx),
> + GFP_KERNEL);
> if (!drm_hdmi_ctx) {
> DRM_ERROR("failed to allocate common hdmi context.\n");
> return -ENOMEM;
> }
>
> - hdata = kzalloc(sizeof(struct hdmi_context), GFP_KERNEL);
> + hdata = devm_kzalloc(&pdev->dev, sizeof(struct hdmi_context),
> + GFP_KERNEL);
> if (!hdata) {
> DRM_ERROR("out of memory\n");
> - kfree(drm_hdmi_ctx);
> return -ENOMEM;
> }
>
> @@ -2318,26 +2318,18 @@ static int __devinit hdmi_probe(struct
> platform_device *pdev)
> goto err_resource;
> }
>
> - hdata->regs_res = request_mem_region(res->start, resource_size(res),
> -dev_name(dev));
> - if (!hdata->regs_res) {
> - DRM_ERROR("failed to claim register region\n");
> - ret = -ENOENT;
> - goto err_resource;
> - }
> -
> - hdata->regs = ioremap(res->start, resource_size(res));
> + hdata->regs = devm_request_and_ioremap(&pdev->dev, res);
> if (!hdata->regs) {
> DRM_ERROR("failed to map registers\n");
> ret = -ENXIO;
> - goto err_req_region;
> + goto err_resource;
> }
>
> /* DDC i2c driver */
> if (i2c_add_driver(&ddc_driver)) {
> DRM_ERROR("failed to register ddc i2c driver\n");
> ret = -ENOENT;
> - goto err_iomap;
> + goto err_resource;
> }
>
> hdata->ddc_port = hdmi_ddc;
> @@ -2398,16 +2390,9 @@ err_hdmiphy:
> i2c_del_driver(&hdmiphy_driver);
> err_ddc:
> i2c_del_driver(&ddc_driver);
> -err_iomap:
> - iounmap(hdata->regs);
> -err_req_region:
> - release_mem_region(hdata->regs_res->start,
> - resource_size(hdata->regs_res));
> err_resource:
> hdmi_resources_cleanup(hdata);
> err_data:
> - kfree(hdata);
> - kfree(drm_hdmi_ctx);
> return ret;
> }
>
> @@ -2425,18 +2410,11 @@ static int __devexit hdmi_remove(struct
> platform_device *pdev)
>
> hdmi_resources_cleanup(hdata);
>
> - iounmap(hdata->regs);
> -
> - release_mem_region(hdata->regs_res->start,
> - resource_size(hdata->regs_res));
> -
> /* hdmiphy i2c driver */
> i2c_del_driver(&hdmiphy_driver);
> /* DDC i2c driver */
> i2c_del_driver(&ddc_driver);
>
> - kfree(hdata);
> -
> return 0;
> }
>
> --
> 1.7.4.1
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>
Applied.
Thanks,
Inki Dae
[PATCH 3/3] drm/exynos: Use devm_* functions in exynos_mixer.c
2012/6/19, Sachin Kamat :
> devm_* functions are device managed functions and make error handling
> and cleanup cleaner and simpler.
>
> Signed-off-by: Sachin Kamat
> Signed-off-by: Sachin Kamat
> ---
> drivers/gpu/drm/exynos/exynos_mixer.c | 48
> +---
> 1 files changed, 14 insertions(+), 34 deletions(-)
>
> diff --git a/drivers/gpu/drm/exynos/exynos_mixer.c
> b/drivers/gpu/drm/exynos/exynos_mixer.c
> index e2147a2..30fcc12 100644
> --- a/drivers/gpu/drm/exynos/exynos_mixer.c
> +++ b/drivers/gpu/drm/exynos/exynos_mixer.c
> @@ -956,7 +956,8 @@ static int __devinit mixer_resources_init(struct
> exynos_drm_hdmi_context *ctx,
>
> clk_set_parent(mixer_res->sclk_mixer, mixer_res->sclk_hdmi);
>
> - mixer_res->mixer_regs = ioremap(res->start, resource_size(res));
> + mixer_res->mixer_regs = devm_ioremap(&pdev->dev, res->start,
> + resource_size(res));
> if (mixer_res->mixer_regs == NULL) {
> dev_err(dev, "register mapping failed.\n");
> ret = -ENXIO;
> @@ -967,38 +968,34 @@ static int __devinit mixer_resources_init(struct
> exynos_drm_hdmi_context *ctx,
> if (res == NULL) {
> dev_err(dev, "get memory resource failed.\n");
> ret = -ENXIO;
> - goto fail_mixer_regs;
> + goto fail;
> }
>
> - mixer_res->vp_regs = ioremap(res->start, resource_size(res));
> + mixer_res->vp_regs = devm_ioremap(&pdev->dev, res->start,
> + resource_size(res));
> if (mixer_res->vp_regs == NULL) {
> dev_err(dev, "register mapping failed.\n");
> ret = -ENXIO;
> - goto fail_mixer_regs;
> + goto fail;
> }
>
> res = platform_get_resource_byname(pdev, IORESOURCE_IRQ, "irq");
> if (res == NULL) {
> dev_err(dev, "get interrupt resource failed.\n");
> ret = -ENXIO;
> - goto fail_vp_regs;
> + goto fail;
> }
>
> - ret = request_irq(res->start, mixer_irq_handler, 0, "drm_mixer", ctx);
> + ret = devm_request_irq(&pdev->dev, res->start, mixer_irq_handler,
> + 0, "drm_mixer", ctx);
> if (ret) {
> dev_err(dev, "request interrupt failed.\n");
> - goto fail_vp_regs;
> + goto fail;
> }
> mixer_res->irq = res->start;
>
> return 0;
>
> -fail_vp_regs:
> - iounmap(mixer_res->vp_regs);
> -
> -fail_mixer_regs:
> - iounmap(mixer_res->mixer_regs);
> -
> fail:
> if (!IS_ERR_OR_NULL(mixer_res->sclk_dac))
> clk_put(mixer_res->sclk_dac);
> @@ -1013,16 +1010,6 @@ fail:
> return ret;
> }
>
> -static void mixer_resources_cleanup(struct mixer_context *ctx)
> -{
> - struct mixer_resources *res = &ctx->mixer_res;
> -
> - free_irq(res->irq, ctx);
> -
> - iounmap(res->vp_regs);
> - iounmap(res->mixer_regs);
> -}
> -
> static int __devinit mixer_probe(struct platform_device *pdev)
> {
> struct device *dev = &pdev->dev;
> @@ -1032,16 +1019,16 @@ static int __devinit mixer_probe(struct
> platform_device *pdev)
>
> dev_info(dev, "probe start\n");
>
> - drm_hdmi_ctx = kzalloc(sizeof(*drm_hdmi_ctx), GFP_KERNEL);
> + drm_hdmi_ctx = devm_kzalloc(&pdev->dev, sizeof(*drm_hdmi_ctx),
> + GFP_KERNEL);
> if (!drm_hdmi_ctx) {
> DRM_ERROR("failed to allocate common hdmi context.\n");
> return -ENOMEM;
> }
>
> - ctx = kzalloc(sizeof(*ctx), GFP_KERNEL);
> + ctx = devm_kzalloc(&pdev->dev, sizeof(*ctx), GFP_KERNEL);
> if (!ctx) {
> DRM_ERROR("failed to alloc mixer context.\n");
> - kfree(drm_hdmi_ctx);
> return -ENOMEM;
> }
>
> @@ -1072,17 +1059,10 @@ fail:
>
> static int mixer_remove(struct platform_device *pdev)
> {
> - struct device *dev = &pdev->dev;
> - struct exynos_drm_hdmi_context *drm_hdmi_ctx =
> - platform_get_drvdata(pdev);
> - struct mixer_context *ctx = drm_hdmi_ctx->ctx;
> -
> - dev_info(dev, "remove successful\n");
> + dev_info(&pdev->dev, "remove successful\n");
>
> pm_runtime_disable(&pdev->dev);
>
> - mixer_resources_cleanup(ctx);
> -
> return 0;
> }
>
> --
> 1.7.4.1
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>
Applied.
Thanks,
Inki Dae
[PATCHv7 06/15] v4l: vb2-dma-contig: remove reference of alloc_ctx from a buffer
Hi Laurent, On 06/19/2012 11:00 PM, Laurent Pinchart wrote: > Hi Tomasz, > > Thanks for the patch. > > On Thursday 14 June 2012 15:37:40 Tomasz Stanislawski wrote: >> This patch removes a reference to alloc_ctx from an instance of a DMA >> contiguous buffer. It helps to avoid a risk of a dangling pointer if the >> context is released while the buffer is still valid. > > Can this really happen ? All drivers except marvell-ccic seem to call > vb2_dma_contig_cleanup_ctx() in their remove handler and probe cleanup path > only. Freeing the context while buffers are still around would be a driver > bug, and I expect drivers to destroy the queue in that case anyway. > > This being said, removing the dereference step is a good idea, so I think the > patch should be applied, possibly with a different commit message. > The problem may happen if a DMABUF sharing is used. - process A uses V4L2 queue to create a buffer - process A exports a buffer and shares it with the process B (by sockets or /proc/pid/fd) - the process A gets killed, queue is destroyed - someone call rmmod on v4l driver, alloc_ctx is freed - process B keeps reference to a buffer that has a dangling reference to alloc_ctx The presented scenario might be a bit too pathological and artificial. Moreover it involves root privileges. But it is possible to trigger this bug. One solution might be keeping reference count in alloc_ctx but it would be easier to get rid of the reference to alloc_ctx from vb2-dma-contig buffer. BTW. I decided to drop 'Remove unneeded allocation context structure' because Marek Szyprowski is working on extension to vb2-dma-contig that allow to create buffers with no kernel mappings. That feature involved additional parameter to alloc_ctx other than pointer to the device. Regards, Tomasz Stanislawski >> Moreover it removes one >> dereference step while accessing a device structure. >> >> Signed-off-by: Tomasz Stanislawski >> Signed-off-by: Kyungmin Park > > Acked-by: Laurent Pinchart > >> +dma_free_coherent(buf->dev, buf->size, buf->vaddr, >>buf->dma_addr); >> kfree(buf); >> }
[PATCHv7 06/15] v4l: vb2-dma-contig: remove reference of alloc_ctx from a buffer
Hi Tomasz, On Wednesday 20 June 2012 13:51:06 Tomasz Stanislawski wrote: > On 06/19/2012 11:00 PM, Laurent Pinchart wrote: > > On Thursday 14 June 2012 15:37:40 Tomasz Stanislawski wrote: > >> This patch removes a reference to alloc_ctx from an instance of a DMA > >> contiguous buffer. It helps to avoid a risk of a dangling pointer if the > >> context is released while the buffer is still valid. > > > > Can this really happen ? All drivers except marvell-ccic seem to call > > vb2_dma_contig_cleanup_ctx() in their remove handler and probe cleanup > > path only. Freeing the context while buffers are still around would be a > > driver bug, and I expect drivers to destroy the queue in that case anyway. > > > > This being said, removing the dereference step is a good idea, so I think > > the patch should be applied, possibly with a different commit message. > > The problem may happen if a DMABUF sharing is used. > - process A uses V4L2 queue to create a buffer > - process A exports a buffer and shares it with the process B (by sockets or > /proc/pid/fd) - the process A gets killed, queue is destroyed > - someone call rmmod on v4l driver, alloc_ctx is freed That's where the problem is in my opinion. As long as a buffer is in use, the queue should not get destroyed and the context should not be freed. If the driver is removed it will kfree the structure that embeds the queue, and even possible free the whole memory region that backs the buffers. We would then have much bigger trouble than just a dangling context pointer. >From a V4L2 point of view this needs to be solved for the dmabuf exporter role only, so it's not a huge concern in the context of this patch set, but we of course need to address the issue. > - process B keeps reference to a buffer that has a dangling reference to > alloc_ctx > > The presented scenario might be a bit too pathological and artificial. > Moreover it involves root privileges. But it is possible to trigger this > bug. One solution might be keeping reference count in alloc_ctx but it > would be easier to get rid of the reference to alloc_ctx from > vb2-dma-contig buffer. > > BTW. I decided to drop 'Remove unneeded allocation context structure' > because Marek Szyprowski is working on extension to vb2-dma-contig > that allow to create buffers with no kernel mappings. That feature > involved additional parameter to alloc_ctx other than pointer to > the device. OK. -- Regards, Laurent Pinchart
[PATCH] drm/edid: don't return stack garbage from supports_rb
On Tue, 2012-06-19 at 11:33 +0200, Daniel Vetter wrote: > We need to initialize this to false, because the is_rb callback only > ever sets it to true. > > Noticed while reading through the code. > > Cc: Adam Jackson > Cc: stable at vger.kernel.org > Signed-Off-by: Daniel Vetter Reviewed-by: Adam Jackson - ajax -- next part -- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20120620/a3ab9bf1/attachment-0001.pgp>
[Bug 50422] Furmark.exe crash with wine (32 bits under 64 bits) with llvm-3.1 and r600-llvm-compiler enabled
https://bugs.freedesktop.org/show_bug.cgi?id=50422 --- Comment #3 from Henri Verbeet 2012-06-20 08:41:51 PDT --- This isn't just another instance of "Clang is broken" / bug 44466, right? -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
Thunderbolt, Apple Monitor & MBA, and excess kworker load
Hi, At work, I wish to attach a 27" Apple Display using thunderbolt to my Mac Book Air 4,2 13". Using OS X, it works fine, but as I prefer using Linux, I tested out Ubuntu's stock kernel and (among other) 3.5.0-rc3+ as of f40759e. Hotplug doesn't work (known issue), but also with coldplug the display reacts _very_ slow, way too slow for real use: The screen updates only every half second or so. Is this a known bug? Might something go afoul with kworker -- they need about 75% of the CPU with the large display attached, and less than 1% _without_ the large display. Any hints are most welcome, also on where I may dig further to determine the root causes... Thanks & best, Dominik
Thunderbolt, Apple Monitor & MBA, and excess kworker load
On Wed, Jun 20, 2012 at 08:56:26AM -0700, Greg KH wrote: > On Wed, Jun 20, 2012 at 05:48:42PM +0200, Dominik Brodowski wrote: > > Hi, > > > > At work, I wish to attach a 27" Apple Display using thunderbolt to my Mac > > Book Air 4,2 13". Using OS X, it works fine, but as I prefer using Linux, I > > tested out Ubuntu's stock kernel and (among other) 3.5.0-rc3+ as of f40759e. > > Hotplug doesn't work (known issue), but also with coldplug the display > > reacts _very_ slow, way too slow for real use: The screen updates only every > > half second or so. Is this a known bug? Might something go afoul with > > kworker -- they need about 75% of the CPU with the large display attached, > > and less than 1% _without_ the large display. > > It's not really a known bug, but it is known that Thunderbolt doesn't > work all that well, if at all, in Linux due to the BIOS issues that you > have run into (the hotplug stuff.) > > Once the device is seen, it should just work like any other PCI device, > and so, that might be a DRM driver issue somehow. A quick full-system profile would be a good start to tell where we're burning through all these cycles exaclty. Also, anything special going on with interrupts (if this excessive load is due to supurious display hotplug events, drm/i915 should get _tons_ of interrupts). -Daniel -- Daniel Vetter Mail: daniel at ffwll.ch Mobile: +41 (0)79 365 57 48
[PATCH V2 12/16] drm/radeon: Make radeon card usable for Loongson.
On Wed, Jun 20, 2012 at 4:28 AM, Huacai Chen wrote: > On Wed, Jun 20, 2012 at 9:26 AM, Alex Deucher > wrote: >> On Tue, Jun 19, 2012 at 9:57 AM, j.glisse wrote: >>> On Tue, Jun 19, 2012 at 02:50:20PM +0800, Huacai Chen wrote: 1, Use 32-bit DMA as a workaround (Loongson has a hardware bug that it ? ?doesn't support DMA address above 4GB). 2, Read vga bios offered by system firmware. 3, Handle io prot correctly for MIPS. 4, Don't use swiotlb on Loongson machines (when use swiotlb, GPU reset ? ?occurs at resume from suspend). Signed-off-by: Huacai Chen Signed-off-by: Hongliang Tao Signed-off-by: Hua Yan Cc: dri-devel at lists.freedesktop.org --- ?drivers/gpu/drm/drm_vm.c ? ? ? ? ? ? ? | ? ?2 +- ?drivers/gpu/drm/radeon/radeon_bios.c ? | ? 32 ?drivers/gpu/drm/radeon/radeon_device.c | ? ?5 + ?drivers/gpu/drm/radeon/radeon_ttm.c ? ?| ? ?6 +++--- ?drivers/gpu/drm/ttm/ttm_bo_util.c ? ? ?| ? ?2 +- ?include/drm/drm_sarea.h ? ? ? ? ? ? ? ?| ? ?2 ++ ?6 files changed, 44 insertions(+), 5 deletions(-) diff --git a/drivers/gpu/drm/drm_vm.c b/drivers/gpu/drm/drm_vm.c index 961ee08..3f06166 100644 --- a/drivers/gpu/drm/drm_vm.c +++ b/drivers/gpu/drm/drm_vm.c @@ -62,7 +62,7 @@ static pgprot_t drm_io_prot(uint32_t map_type, struct vm_area_struct *vma) ? ? ? ? ? ? ? tmp = pgprot_writecombine(tmp); ? ? ? else ? ? ? ? ? ? ? tmp = pgprot_noncached(tmp); -#elif defined(__sparc__) || defined(__arm__) +#elif defined(__sparc__) || defined(__arm__) || defined(__mips__) ? ? ? tmp = pgprot_noncached(tmp); ?#endif ? ? ? return tmp; diff --git a/drivers/gpu/drm/radeon/radeon_bios.c b/drivers/gpu/drm/radeon/radeon_bios.c index 501f488..2630e22 100644 --- a/drivers/gpu/drm/radeon/radeon_bios.c +++ b/drivers/gpu/drm/radeon/radeon_bios.c @@ -29,6 +29,7 @@ ?#include "radeon_reg.h" ?#include "radeon.h" ?#include "atom.h" +#include ?#include ?#include @@ -73,6 +74,32 @@ static bool igp_read_bios_from_vram(struct radeon_device *rdev) ? ? ? return true; ?} +#ifdef CONFIG_CPU_LOONGSON3 +extern u64 vgabios_addr; >>> >>> Ugly, is this how platform specific stuff are handled usualy ? I hope not, >>> i would rather see a platform specific function such as >>> loongson3_get_vga_bios. >> >> It could be hooked in as a pci quirk similar to how we read the vbios >> from the legacy vga location on x86. > Hi, Alex, the method you said is pci_fixup_video() in arch/x86/pci/fixup.c? Correct, although you will probably need it in arch/mips/pci for your platform. You may want to make your quirk specific to this pci device unless you need it for all vga chips on your platform. Alex
Thunderbolt, Apple Monitor & MBA, and excess kworker load
On Wed, Jun 20, 2012 at 05:48:42PM +0200, Dominik Brodowski wrote: > Hi, > > At work, I wish to attach a 27" Apple Display using thunderbolt to my Mac > Book Air 4,2 13". Using OS X, it works fine, but as I prefer using Linux, I > tested out Ubuntu's stock kernel and (among other) 3.5.0-rc3+ as of f40759e. > Hotplug doesn't work (known issue), but also with coldplug the display > reacts _very_ slow, way too slow for real use: The screen updates only every > half second or so. Is this a known bug? Might something go afoul with > kworker -- they need about 75% of the CPU with the large display attached, > and less than 1% _without_ the large display. It's not really a known bug, but it is known that Thunderbolt doesn't work all that well, if at all, in Linux due to the BIOS issues that you have run into (the hotplug stuff.) Once the device is seen, it should just work like any other PCI device, and so, that might be a DRM driver issue somehow. greg k-h
[Bug 51190] [RADEON:KMS:RV370:RESUME] garbage on screen (console or X) after suspend-resume with radeon (KMS only)
https://bugs.freedesktop.org/show_bug.cgi?id=51190 --- Comment #7 from cyberbat 2012-06-20 10:56:44 PDT --- (In reply to comment #6) > No, I mean writing the string 'mem'. I don't know what if anything writing 3 > will do. I've tried echo -n "mem" > /sys/power/state Just the same behavior as described. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 51190] [RADEON:KMS:RV370:RESUME] garbage on screen (console or X) after suspend-resume with radeon (KMS only)
https://bugs.freedesktop.org/show_bug.cgi?id=51190 --- Comment #8 from cyberbat 2012-06-20 11:00:28 PDT --- I got following in dmesg after restoring after mem > /sys/power/state: radeon :01:00.0: restoring config space at offset 0xf (was 0x1ff, writing 0x10a) radeon :01:00.0: restoring config space at offset 0x6 (was 0x0, writing 0xc010) radeon :01:00.0: restoring config space at offset 0x4 (was 0x8, writing 0xd008) radeon :01:00.0: restoring config space at offset 0x3 (was 0x0, writing 0x8) radeon :01:00.0: restoring config space at offset 0x1 (was 0x100107, writing 0x100507) ... [drm] PCIE GART of 512M enabled (table at 0xD004). radeon :01:00.0: WB enabled [drm] radeon: ring at 0xB0001000 [drm:r100_ring_test] *ERROR* radeon: ring test failed (scratch(0x15E4)=0xCAFEDEAD) [drm:r100_cp_init] *ERROR* radeon: cp isn't working (-22). radeon :01:00.0: failed initializing CP (-22). -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[PULL] first drm-intel-next for 3.6
Hi Dave, Resend of the pull as request on irc, all the fancy details are below the cut. Mail is completely unchanged, so it's still babbling about rc2 and regression that are tracked down by now ;-) Cheers, Daniel --- Hi Dave, rc2 is out the door so I've figured I'll annoy you with the first -next pull request for 3.6 already. Highlights: - new wait_rendring_timeout interface (Ben) - l3 cache remapping and error uevent support (Ben) - even more infoframes work from Paulo - gen4 hotplug rework from Chris - prep work to make Laurent Pincharts original mode constification for connector->mode_fixup possible QA reported a few new bugs this time around, but no regressions afact. For 3.5 the only thing I'm aware of is the edp vdd dmesg spam Linus originally reported - it looks like that might have been introduced in 3.5. But somehow my brain is routinely offline when I work on that issue, so things seem to take forever (and atm I'm at patch v4 for that little problem). Yours, Daniel The following changes since commit 63bc620b45af8c743ac291c8725933278c712692: radeon: add radeon prime vmap support. (2012-05-31 14:14:01 +0100) are available in the git repository at: git://people.freedesktop.org/~danvet/drm-intel tags/drm-intel-next-2012-06-04 for you to fetch changes up to 1523c310b3ed964b71a8db16f70c3bc21cc0642e: drm/i915: add min freq control to debugfs (2012-06-04 21:34:47 +0200) Ben Widawsky (8): drm/i915: timeout parameter for seqno wait drm/i915: improve i915_wait_request_begin trace drm/i915: wait render timeout ioctl drm/i915: s/i915_wait_request/i915_wait_seqno/g drm/i915: Dynamic Parity Detection handling drm/i915: enable parity error interrupts drm/i915: remap l3 on hw init drm/i915: l3 parity sysfs interface Chris Wilson (6): drm/i915: All members of gen4 have hotplug, so unconditionally enable its irq drm/i915: Inspect the right status bits for DP/HDMI hotplug on gen4 drm/i915: SDVO hotplug have different interrupt status bits for i915/i965/g4x drm/i915/hdmi: Query the live connector status bit for G4x drm/i915/dp: For consistency use the DP hotplug synonyms drm/i915/hdmi: Fix reg values for g4x_hdmi_connected Daniel Vetter (14): drm/i915: clarify preferred sdvo input mode code drm/i915: don't silently ignore sdvo mode_set failures drm/i915: there's no cxsr on ilk drm/i915: reuse the sdvo tv clock adjustment in ilk mode_set drm/i915: s/mdelay/msleep/ in the sdvo detect function drm/i915: ivybridge_handle_parity_error should be static drm/i915: initialize the parity work only once drm/i915: simplify sysfs setup code Merge remote-tracking branch 'airlied/drm-prime-vmap' into drm-intel-next-queued drm/i915: clarify IBX dp workaround drm/i915: extract object active state flushing code drm/i915: compute the target_clock for edp directly drm/i915: adjusted_mode->clock in the dp mode_fixup drm/i915: don't chnage the original mode in dp_mode_fixup Jesse Barnes (1): drm/i915: add min freq control to debugfs Paulo Zanoni (11): drm/i915: add set_infoframes to struct intel_hdmi drm/i915: properly alternate between DVI and HDMI drm/i915: only set the HDMI port on the DIP once drm/i915: enable DIP before enabling each InfoFrame drm/i915: don't wait for vblank while writing InfoFrames drm/i915: explicitly disable the DIPs we're not using drm/i915: disable DIP while changing the port drm/i915: don't write 0 to DIP control at HDMI init drm/i915: don't set SDVO_BORDER_ENABLE when we're HDMI drm/i915: remove comment about HSW HDMI DIPs drm/i915: add some barriers when changing DIPs drivers/gpu/drm/i915/i915_debugfs.c | 66 +++ drivers/gpu/drm/i915/i915_dma.c |1 + drivers/gpu/drm/i915/i915_drv.h | 11 +- drivers/gpu/drm/i915/i915_gem.c | 242 +++ drivers/gpu/drm/i915/i915_irq.c | 171 - drivers/gpu/drm/i915/i915_reg.h | 56 +- drivers/gpu/drm/i915/i915_sysfs.c | 127 +++- drivers/gpu/drm/i915/i915_trace.h | 28 ++- drivers/gpu/drm/i915/intel_ddi.c|3 +- drivers/gpu/drm/i915/intel_display.c| 47 ++--- drivers/gpu/drm/i915/intel_dp.c | 53 +++--- drivers/gpu/drm/i915/intel_drv.h|9 +- drivers/gpu/drm/i915/intel_hdmi.c | 318 +-- drivers/gpu/drm/i915/intel_overlay.c|4 +- drivers/gpu/drm/i915/intel_panel.c |2 +- drivers/gpu/drm/i915/intel_ringbuffer.c | 16 +- drivers/gpu/drm/i915/intel_sdvo.c | 56 -- include/drm/i915_drm.h | 10 + 18 files changed, 965 insertions(+), 255 deletions(-) -- Daniel Vetter Mail: daniel at ffwll.ch Mobile: +41 (0)79 365 5
drm-next radeon patches
Hi Christian, the 3rd patch doesnt' apply cleanly to my -next tree, Can you rebase them onto my current drm-core-next? Dave.
[PATCH] drm/edid: Do dmt_modes_for_range less aggressively
On Tue, 2012-06-19 at 14:55 -0400, Adam Jackson wrote: > Only fill it in for pre-1.1 monitors - when GTF hadn't yet been defined > - or for EDID 1.4's explicit "just a range, not a timing formula" case. > > Bugzilla: https://bugs.freedesktop.org/51146 > Signed-off-by: Adam Jackson Self-nak, at any rate hold off from doing this for the moment. The bz above is turning out more subtle than I was expecting. I'm really not a fan of how the extra_modes changes introduced new failure cases despite my best efforts to be conservative. Wish I'd said no harder. - ajax -- next part -- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20120620/a204a391/attachment.pgp>
[Bug 51273] New: Kernel panic with dynpm and kernel 3.5
https://bugs.freedesktop.org/show_bug.cgi?id=51273 Bug #: 51273 Summary: Kernel panic with dynpm and kernel 3.5 Classification: Unclassified Product: DRI Version: XOrg CVS Platform: Other OS/Version: All Status: NEW Severity: normal Priority: medium Component: DRM/Radeon AssignedTo: dri-devel at lists.freedesktop.org ReportedBy: ernstp at gmail.com Hi, I've been running with the following in my rc.local for a while: echo dynpm > /sys/class/drm/card0/device/power_method But when I tried a 3.5 kernel today I got a kernel panic as soon as dynpm was enabled! Ubuntu kernel 3.5.0-1.1-generic 01:00.0 VGA compatible controller: Advanced Micro Devices [AMD] nee ATI Barts PRO [ATI Radeon HD 6800 -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 51273] Kernel panic with dynpm and kernel 3.5
https://bugs.freedesktop.org/show_bug.cgi?id=51273 Alex Deucher changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #1 from Alex Deucher 2012-06-20 14:49:19 PDT --- Fix already upstream: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=commitdiff;h=0ec0612a80f957000999c3f7b31a84e3558c719d -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
