Re: Fixing nouveau for >4k PAGE_SIZE
On Sun, 2013-08-11 at 08:17 +0200, Maarten Lankhorst wrote:
> > So I'm still a bit confused :-)
> >
> The fun has been doubled because TTM expects PAGE units, so some of
> the PAGE_SHIFT's are
> genuine. Some may be a result of PAGE_SHIFT == 12, so honestly I don't
> know the specific ones.
Right, and the other way around too :-)
I think I found at least two cases where "12" was used where it should
have been PAGE_SHIFT (basically ttm_mem_reg->num_pages). This
is only the tip of the iceberg, so this isn't a formal patch submission,
but I would appreciate your thought as to whether the below is correct
(and thus I'm on the right track) :
--- a/drivers/gpu/drm/nouveau/nouveau_sgdma.c
+++ b/drivers/gpu/drm/nouveau/nouveau_sgdma.c
@@ -31,7 +31,7 @@ nv04_sgdma_bind(struct ttm_tt *ttm, struct ttm_mem_reg *mem)
{
struct nouveau_sgdma_be *nvbe = (struct nouveau_sgdma_be *)ttm;
struct nouveau_mem *node = mem->mm_node;
- u64 size = mem->num_pages << 12;
+ u64 size = mem->num_pages << PAGE_SHIFT;
if (ttm->sg) {
node->sg = ttm->sg;
diff --git a/drivers/gpu/drm/nouveau/nouveau_ttm.c b/drivers/gpu/drm/nouveau/nou
index 19e3757..f0629de 100644
--- a/drivers/gpu/drm/nouveau/nouveau_ttm.c
+++ b/drivers/gpu/drm/nouveau/nouveau_ttm.c
@@ -252,8 +252,8 @@ nv04_gart_manager_new(struct ttm_mem_type_manager *man,
node->page_shift = 12;
- ret = nouveau_vm_get(man->priv, mem->num_pages << 12, node->page_shift,
-NV_MEM_ACCESS_RW, &node->vma[0]);
+ ret = nouveau_vm_get(man->priv, mem->num_pages << PAGE_SHIFT,
+node->page_shift, NV_MEM_ACCESS_RW, &node->vma[0]);
if (ret) {
kfree(node);
Thanks !
Cheers,
Ben.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Fixing nouveau for >4k PAGE_SIZE
On Sun, 2013-08-11 at 17:06 +1000, Benjamin Herrenschmidt wrote:
> I think I found at least two cases where "12" was used where it should
> have been PAGE_SHIFT (basically ttm_mem_reg->num_pages). This
> is only the tip of the iceberg, so this isn't a formal patch submission,
> but I would appreciate your thought as to whether the below is correct
> (and thus I'm on the right track) :
This patch (which needs cleanups, and probably be broken down for
bisectability) makes it work for me. I've disabled nouveau_dri for now
as this has its own problems related to Ajax recent gallium endian
changes.
Note the horrible duplication of nouveau_vm_map_sg...
I think to fix it "cleanly" we probably need to slightly change the
->map_sg API to the vmmr. However, I do have a question whose answer
might make things a LOT easier if "yes" can make things a lot easier:
Can we guarantee that that such an sg object (I assume this is always
a ttm_bo getting placed in the "TT" memory, correct ?) has an alignment
in *card VM space* that is a multiple of the *system page size* ? Ie,
can we make that happen easily ?
For example, if my system page size is 64k, can we guarantee that it
will always be mapped in the card at a virtual address that is 64k
aligned ?
If that is the case, then we *know* that a given page in the page list
passed to nouveau_vm_map_sg() will never cross a pde boundary (will
always be fully contained in the bottom level of the page table). That
allows to simplify the code a bit, and maybe to write a unified function
that can still pass down page lists to the vmmr
On the other hand, if we have to handle misalignment, then we may as
well stick to 1 PTE at a time like my patch does to avoid horrible
complications.
Cheers,
Ben.
diff --git a/drivers/gpu/drm/nouveau/core/engine/fifo/nv40.c
b/drivers/gpu/drm/nouveau/core/engine/fifo/nv40.c
index 5c7433d..c314a5f 100644
--- a/drivers/gpu/drm/nouveau/core/engine/fifo/nv40.c
+++ b/drivers/gpu/drm/nouveau/core/engine/fifo/nv40.c
@@ -190,8 +190,8 @@ nv40_fifo_chan_ctor(struct nouveau_object *parent,
if (size < sizeof(*args))
return -EINVAL;
- ret = nouveau_fifo_channel_create(parent, engine, oclass, 0, 0xc0,
- 0x1000, args->pushbuf,
+ ret = nouveau_fifo_channel_create(parent, engine, oclass, 0, 0x80,
+ 0x1, args->pushbuf,
(1ULL << NVDEV_ENGINE_DMAOBJ) |
(1ULL << NVDEV_ENGINE_SW) |
(1ULL << NVDEV_ENGINE_GR) |
diff --git a/drivers/gpu/drm/nouveau/core/subdev/vm/base.c
b/drivers/gpu/drm/nouveau/core/subdev/vm/base.c
index ef3133e..5833851 100644
--- a/drivers/gpu/drm/nouveau/core/subdev/vm/base.c
+++ b/drivers/gpu/drm/nouveau/core/subdev/vm/base.c
@@ -84,10 +84,11 @@ nouveau_vm_map_sg_table(struct nouveau_vma *vma, u64 delta,
u64 length,
{
struct nouveau_vm *vm = vma->vm;
struct nouveau_vmmgr *vmm = vm->vmm;
- int big = vma->node->type != vmm->spg_shift;
+ u32 shift = vma->node->type;
+ int big = shift != vmm->spg_shift;
u32 offset = vma->node->offset + (delta >> 12);
- u32 bits = vma->node->type - 12;
- u32 num = length >> vma->node->type;
+ u32 bits = shift - 12;
+ u32 num = length >> shift;
u32 pde = (offset >> vmm->pgt_bits) - vm->fpde;
u32 pte = (offset & ((1 << vmm->pgt_bits) - 1)) >> bits;
u32 max = 1 << (vmm->pgt_bits - bits);
@@ -98,7 +99,7 @@ nouveau_vm_map_sg_table(struct nouveau_vma *vma, u64 delta,
u64 length,
for_each_sg(mem->sg->sgl, sg, mem->sg->nents, i) {
struct nouveau_gpuobj *pgt = vm->pgt[pde].obj[big];
- sglen = sg_dma_len(sg) >> PAGE_SHIFT;
+ sglen = sg_dma_len(sg) >> shift;
end = pte + sglen;
if (unlikely(end >= max))
@@ -106,7 +107,7 @@ nouveau_vm_map_sg_table(struct nouveau_vma *vma, u64 delta,
u64 length,
len = end - pte;
for (m = 0; m < len; m++) {
- dma_addr_t addr = sg_dma_address(sg) + (m <<
PAGE_SHIFT);
+ dma_addr_t addr = sg_dma_address(sg) + (m << shift);
vmm->map_sg(vma, pgt, mem, pte, 1, &addr);
num--;
@@ -121,7 +122,7 @@ nouveau_vm_map_sg_table(struct nouveau_vma *vma, u64 delta,
u64 length,
}
if (m < sglen) {
for (; m < sglen; m++) {
- dma_addr_t addr = sg_dma_address(sg) + (m <<
PAGE_SHIFT);
+ dma_addr_t addr = sg_dma_address(sg) + (m <<
shift);
vmm->map_sg(vma, pgt, mem, pte, 1, &addr);
num--;
@@ -136,6 +137,7 @@ finish:
vmm->flush(vm);
}
+#if PAGE_SHIFT == 12
void
n
Re: EDID modes unavailable when no connector/crtc available at boot
On Sun, Aug 11, 2013 at 2:41 PM, Tony Prisk wrote: > I am working on the HDMI driver for the i.MX6 as part of the larger DRM > driver written by Sascha Hauer and need a little advice. I seem to be > missing one important part of the subsystem that I haven't been able to > resolve. > fbcon is limited by boot sizes as at least with dynamic memory management and how fbdev works resizing the allocation is nearly impossible to do race free, since fbdev will hand out mmaps to userspace and that stops you from ever moving anything once the device is open. But this is only for the fbdev emulation, a real kms application should be able to use a larger size no problems. Dave. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Fixing nouveau for >4k PAGE_SIZE
Op 11-08-13 10:04, Benjamin Herrenschmidt schreef:
> On Sun, 2013-08-11 at 17:06 +1000, Benjamin Herrenschmidt wrote:
>
>> I think I found at least two cases where "12" was used where it should
>> have been PAGE_SHIFT (basically ttm_mem_reg->num_pages). This
>> is only the tip of the iceberg, so this isn't a formal patch submission,
>> but I would appreciate your thought as to whether the below is correct
>> (and thus I'm on the right track) :
> This patch (which needs cleanups, and probably be broken down for
> bisectability) makes it work for me. I've disabled nouveau_dri for now
> as this has its own problems related to Ajax recent gallium endian
> changes.
>
> Note the horrible duplication of nouveau_vm_map_sg...
>
> I think to fix it "cleanly" we probably need to slightly change the
> ->map_sg API to the vmmr. However, I do have a question whose answer
> might make things a LOT easier if "yes" can make things a lot easier:
>
> Can we guarantee that that such an sg object (I assume this is always
> a ttm_bo getting placed in the "TT" memory, correct ?) has an alignment
> in *card VM space* that is a multiple of the *system page size* ? Ie,
> can we make that happen easily ?
>
> For example, if my system page size is 64k, can we guarantee that it
> will always be mapped in the card at a virtual address that is 64k
> aligned ?
>
> If that is the case, then we *know* that a given page in the page list
> passed to nouveau_vm_map_sg() will never cross a pde boundary (will
> always be fully contained in the bottom level of the page table). That
> allows to simplify the code a bit, and maybe to write a unified function
> that can still pass down page lists to the vmmr
>
> On the other hand, if we have to handle misalignment, then we may as
> well stick to 1 PTE at a time like my patch does to avoid horrible
> complications.
>
> Cheers,
> Ben.
>
> diff --git a/drivers/gpu/drm/nouveau/core/engine/fifo/nv40.c
> b/drivers/gpu/drm/nouveau/core/engine/fifo/nv40.c
> index 5c7433d..c314a5f 100644
> --- a/drivers/gpu/drm/nouveau/core/engine/fifo/nv40.c
> +++ b/drivers/gpu/drm/nouveau/core/engine/fifo/nv40.c
> @@ -190,8 +190,8 @@ nv40_fifo_chan_ctor(struct nouveau_object *parent,
> if (size < sizeof(*args))
> return -EINVAL;
>
> - ret = nouveau_fifo_channel_create(parent, engine, oclass, 0, 0xc0,
> - 0x1000, args->pushbuf,
> + ret = nouveau_fifo_channel_create(parent, engine, oclass, 0, 0x80,
> + 0x1, args->pushbuf,
> (1ULL << NVDEV_ENGINE_DMAOBJ) |
> (1ULL << NVDEV_ENGINE_SW) |
> (1ULL << NVDEV_ENGINE_GR) |
Why the size change?
> diff --git a/drivers/gpu/drm/nouveau/core/subdev/vm/base.c
> b/drivers/gpu/drm/nouveau/core/subdev/vm/base.c
> index ef3133e..5833851 100644
> --- a/drivers/gpu/drm/nouveau/core/subdev/vm/base.c
> +++ b/drivers/gpu/drm/nouveau/core/subdev/vm/base.c
> @@ -84,10 +84,11 @@ nouveau_vm_map_sg_table(struct nouveau_vma *vma, u64
> delta, u64 length,
> {
> struct nouveau_vm *vm = vma->vm;
> struct nouveau_vmmgr *vmm = vm->vmm;
> - int big = vma->node->type != vmm->spg_shift;
> + u32 shift = vma->node->type;
> + int big = shift != vmm->spg_shift;
> u32 offset = vma->node->offset + (delta >> 12);
> - u32 bits = vma->node->type - 12;
> - u32 num = length >> vma->node->type;
> + u32 bits = shift - 12;
> + u32 num = length >> shift;
> u32 pde = (offset >> vmm->pgt_bits) - vm->fpde;
> u32 pte = (offset & ((1 << vmm->pgt_bits) - 1)) >> bits;
> u32 max = 1 << (vmm->pgt_bits - bits);
> @@ -98,7 +99,7 @@ nouveau_vm_map_sg_table(struct nouveau_vma *vma, u64 delta,
> u64 length,
>
> for_each_sg(mem->sg->sgl, sg, mem->sg->nents, i) {
> struct nouveau_gpuobj *pgt = vm->pgt[pde].obj[big];
> - sglen = sg_dma_len(sg) >> PAGE_SHIFT;
> + sglen = sg_dma_len(sg) >> shift;
>
> end = pte + sglen;
> if (unlikely(end >= max))
Please add a WARN_ON(big); in map_sg and map_sg_table if you do this.
> @@ -106,7 +107,7 @@ nouveau_vm_map_sg_table(struct nouveau_vma *vma, u64
> delta, u64 length,
> len = end - pte;
>
> for (m = 0; m < len; m++) {
> - dma_addr_t addr = sg_dma_address(sg) + (m <<
> PAGE_SHIFT);
> + dma_addr_t addr = sg_dma_address(sg) + (m << shift);
>
> vmm->map_sg(vma, pgt, mem, pte, 1, &addr);
> num--;
> @@ -121,7 +122,7 @@ nouveau_vm_map_sg_table(struct nouveau_vma *vma, u64
> delta, u64 length,
> }
> if (m < sglen) {
> for (; m < sglen; m++) {
> - dma_addr_t addr = sg_dma_address(sg) + (m <<
> PAGE_SHIFT);
> +
Re: Fixing nouveau for >4k PAGE_SIZE
On Sun, 2013-08-11 at 11:02 +0200, Maarten Lankhorst wrote:
> > diff --git a/drivers/gpu/drm/nouveau/core/engine/fifo/nv40.c
> > b/drivers/gpu/drm/nouveau/core/engine/fifo/nv40.c
> > index 5c7433d..c314a5f 100644
> > --- a/drivers/gpu/drm/nouveau/core/engine/fifo/nv40.c
> > +++ b/drivers/gpu/drm/nouveau/core/engine/fifo/nv40.c
> > @@ -190,8 +190,8 @@ nv40_fifo_chan_ctor(struct nouveau_object *parent,
> > if (size < sizeof(*args))
> > return -EINVAL;
> >
> > - ret = nouveau_fifo_channel_create(parent, engine, oclass, 0, 0xc0,
> > - 0x1000, args->pushbuf,
> > + ret = nouveau_fifo_channel_create(parent, engine, oclass, 0, 0x80,
> > + 0x1, args->pushbuf,
> > (1ULL << NVDEV_ENGINE_DMAOBJ) |
> > (1ULL << NVDEV_ENGINE_SW) |
> > (1ULL << NVDEV_ENGINE_GR) |
> Why the size change?
This reverts the value to older ones, however that patch might not be
needed anymore (I was carrying it from Dave but if we don't map the
registers into userspace we shouldn't need to force align them).
> > diff --git a/drivers/gpu/drm/nouveau/core/subdev/vm/base.c
> > b/drivers/gpu/drm/nouveau/core/subdev/vm/base.c
> > index ef3133e..5833851 100644
> > --- a/drivers/gpu/drm/nouveau/core/subdev/vm/base.c
> > +++ b/drivers/gpu/drm/nouveau/core/subdev/vm/base.c
> > @@ -84,10 +84,11 @@ nouveau_vm_map_sg_table(struct nouveau_vma *vma, u64
> > delta, u64 length,
> > {
> > struct nouveau_vm *vm = vma->vm;
> > struct nouveau_vmmgr *vmm = vm->vmm;
> > - int big = vma->node->type != vmm->spg_shift;
> > + u32 shift = vma->node->type;
> > + int big = shift != vmm->spg_shift;
> > u32 offset = vma->node->offset + (delta >> 12);
> > - u32 bits = vma->node->type - 12;
> > - u32 num = length >> vma->node->type;
> > + u32 bits = shift - 12;
> > + u32 num = length >> shift;
> > u32 pde = (offset >> vmm->pgt_bits) - vm->fpde;
> > u32 pte = (offset & ((1 << vmm->pgt_bits) - 1)) >> bits;
> > u32 max = 1 << (vmm->pgt_bits - bits);
> > @@ -98,7 +99,7 @@ nouveau_vm_map_sg_table(struct nouveau_vma *vma, u64
> > delta, u64 length,
> >
> > for_each_sg(mem->sg->sgl, sg, mem->sg->nents, i) {
> > struct nouveau_gpuobj *pgt = vm->pgt[pde].obj[big];
> > - sglen = sg_dma_len(sg) >> PAGE_SHIFT;
> > + sglen = sg_dma_len(sg) >> shift;
> >
> > end = pte + sglen;
> > if (unlikely(end >= max))
> Please add a WARN_ON(big); in map_sg and map_sg_table if you do this.
So that's debatable :-)
The above code is map_sg. Arguably my patch *fixes* using it with card
large pages :-)
IE, Look at the "usual" case (PAGE_SHIFT=12). Today, the above means
sglen will be in units of small pages. But everything else in that loop
operates in units of whatever is represented by the pte, which can
either be 4k or larger.
So adding "sglen" to "pte" was never right for shift != 12 before
(regardless of PAGE_SHIFT).
With my patch, it's more correct, so as such, adding a WARN_ON here
wouldn't be "if I do this" :-)
Now, the "big" case still cannot really work here with PAGE_SHIFT=12,
because that would require the sg segments to be multiple of
"shift" (the card large page) and that is not going to be the case.
So funnily enough, we *could* use card large pages of 64k ("big") if ...
we had PAGE_SHIFT=16 ... which we do on ppc64 :-) But not anywhere else.
But yes, the point remains, in the general case, that function cannot
work for the "big" case, so I wonder if we should catch it with a
WARN_ON and maybe simplify the code a bunch while at it...
> > @@ -106,7 +107,7 @@ nouveau_vm_map_sg_table(struct nouveau_vma *vma, u64
> > delta, u64 length,
> > len = end - pte;
> >
> > for (m = 0; m < len; m++) {
> > - dma_addr_t addr = sg_dma_address(sg) + (m <<
> > PAGE_SHIFT);
> > + dma_addr_t addr = sg_dma_address(sg) + (m << shift);
> >
> > vmm->map_sg(vma, pgt, mem, pte, 1, &addr);
> > num--;
> > @@ -121,7 +122,7 @@ nouveau_vm_map_sg_table(struct nouveau_vma *vma, u64
> > delta, u64 length,
> > }
> > if (m < sglen) {
> > for (; m < sglen; m++) {
> > - dma_addr_t addr = sg_dma_address(sg) + (m <<
> > PAGE_SHIFT);
> > + dma_addr_t addr = sg_dma_address(sg) + (m <<
> > shift);
> >
> > vmm->map_sg(vma, pgt, mem, pte, 1, &addr);
> > num--;
> > @@ -136,6 +137,7 @@ finish:
> > vmm->flush(vm);
> > }
> >
> > +#if PAGE_SHIFT == 12
> > void
> > nouveau_vm_map_sg(struct nouveau_vma *vma, u64 delta, u64 length,
> > struct nouveau_mem *mem)
> > @@ -143,10 +145,11 @@ nouveau_vm_map_sg(struct nouveau_vma *vma
Re: [PATCH] i915: Fix SDVO potentially turning off randomly
On Sat, Aug 10, 2013 at 09:57:57PM +0200, Guillaume Clement wrote: > Some Poulsbo cards seem to incorrectly report > SDVO_CMD_STATUS_TARGET_NOT_SPECIFIED instead of SDVO_CMD_STATUS_PENDING, > which causes the display to be turned off. > > This could also happen to i915. > > Signed-off-by: Guillaume Clement Queued for -next, thanks for the patch. Let's see whether we're lucky and this fixes something ;-) -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] gma500: Fix SDVO turning off randomly
On Sat, Aug 10, 2013 at 10:12 PM, Patrik Jakobsson wrote: > I will give this a spin on my gma500 and i915 hardware on monday. The gma500 > sdvo code should be pretty much identical to i915 from around 2011 but I guess > we've diverged since then. I'll also rework sdvo for gma500 a little in the > coming days when I start working on Minnowboard support so I'll probably > compare > it to i915 for any peculiarities. If you take this opportunity to share a bit of code between gma500 and i915 (the sdvo #defines header and maybe the sdvo i2c read/write and cmd helpers) I'd be interested in such a patch. We probably need an struct intel_sdvo_chip to abstract away a few things. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: EDID modes unavailable when no connector/crtc available at boot
On Sun, Aug 11, 2013 at 7:42 PM, Tony Prisk wrote:
> On 11/08/13 20:42, Dave Airlie wrote:
>>
>> On Sun, Aug 11, 2013 at 2:41 PM, Tony Prisk wrote:
>>>
>>> I am working on the HDMI driver for the i.MX6 as part of the larger DRM
>>> driver written by Sascha Hauer and need a little advice. I seem to be
>>> missing one important part of the subsystem that I haven't been able to
>>> resolve.
>>>
>> fbcon is limited by boot sizes as at least with dynamic memory
>> management and how fbdev works resizing the allocation is nearly
>> impossible to do race free, since fbdev will hand out mmaps to
>> userspace and that stops you from ever moving anything once the device
>> is open.
>>
>> But this is only for the fbdev emulation, a real kms application
>> should be able to use a larger size no problems.
>>
>> Dave.
>
> It seems to be worse than just a fbcon issue as far as I can tell.
>
> I am making an assumption, but I believe
> '/sys/class/drm/card0-HDMI-A-1/modes' should list all the supported modes of
> the connector (regardless of fbcon).
> Using 'cat /sys/class/drm/card0-HDMI-A-1/modes', it appears the supported
> modes are being limited by fbcon
>
> 1) HDMI Cable connected at bootup (fb @ 1920x1080)
> cat /sys/class/drm/card0-HDMI-A-1/modes
> 1920x1080
> 1280x720
> 1280x720
> 720x576
> 720x480
> 640x480
>
> 2) HDMI Cable NOT connected at bootup (fb @ 1024x768), cable is then
> connected after userspace has started (still in console)
> cat /sys/class/drm/card0-HDMI-A-1/modes
> 720x576
> 720x480
> 640x480
>
>
> Following back through the source:
>
> static struct drm_connector_funcs imx_hdmi_connector_funcs = {
> .fill_modes = drm_helper_probe_single_connector_modes,
> ...
> };
>
> static struct drm_connector_helper_funcs imx_hdmi_connector_helper_funcs = {
> .get_modes = imx_hdmi_connector_get_modes,
> .mode_valid = imx_hdmi_connector_mode_valid,
> ...
> };
>
>
> It appears that only drm_helper_probe_single_connector_modes() calls
> .get_modes() and .mode_valid()
> .fill_modes() is called from drm_fb_helper_probe_connector_modes(), which is
> called from drm_fb_helper_hotplug_event()
> drm_fb_helper_hotplug_event() sets max_width to fb_helper->fb->width, and
> max_height to fb_helper->fb->height.
> fb->width is 1024 if booted without the cable connected, hence the clipping
> of the values.
fill_modes is also called from the drm_crtc.c userspace interface, all
the functions in drm_fb_helper are for fbdev/con use, the fact sysfs
is wrong is only a side effect.
Userspace should get a full list of modes, try using the modetest
application which I think should work.
Dave.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 67994] New: System freezes when playing video on open source AMD drivers with VDPAU
https://bugs.freedesktop.org/show_bug.cgi?id=67994 Priority: medium Bug ID: 67994 Assignee: dri-devel@lists.freedesktop.org Summary: System freezes when playing video on open source AMD drivers with VDPAU Severity: normal Classification: Unclassified OS: Linux (All) Reporter: scorp@yandex.ua Hardware: x86 (IA32) Status: NEW Version: XOrg CVS Component: DRM/Radeon Product: DRI Kernel - Linux 3.11rc4 Version mesa-common-dev - 9.2.0~git20130729+9.2.9b8ad643-0ubuntu0sarvatt~raring Version libg3dvl-mesa - 9.3~git1308091520.e8d897~gd~r Driver - Gallium 0.4 To repeat the freezing - start the video on player with support for VDPAU (mplayer or XBMC), stop it, and then run another video. -- 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 67994] System freezes when playing video on open source AMD drivers with VDPAU
https://bugs.freedesktop.org/show_bug.cgi?id=67994 --- Comment #1 from Nikita --- My graphic card - Mobility Radeon HD 4650 -- 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 43829] Resuming my AMD A4-3300 based laptop leaves the screen black
https://bugs.freedesktop.org/show_bug.cgi?id=43829 --- Comment #29 from ka.n...@mail.ru --- I've the same issue on my HP4545s laptop (A4-4300M CPU). At boot time I get ... [drm:radeon_acpi_init] *ERROR* Cannot find a backlight controller ... then the computer boots and works just fine (except the brightness control is @ /sys/class/backlight/radeon_bl0/brightness, commonly unrecognizable by the software) but after resuming I have totally black screen. I can still ssh to it: it resumes normally - the only thing that goes wrong is the screen remains off. (It goes off as soon as the resume process begins). Kernels 3.9.X still have the issue. I'm not sure the absence of the ACPI-controllable brightness is relevant to the case. -- 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 67994] System freezes when playing video on open source AMD drivers with VDPAU
https://bugs.freedesktop.org/show_bug.cgi?id=67994 --- Comment #2 from Nikita --- Created attachment 83941 --> https://bugs.freedesktop.org/attachment.cgi?id=83941&action=edit dmesg log -- 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 67994] System freezes (GPU lockup) when playing video on open source AMD drivers with VDPAU
https://bugs.freedesktop.org/show_bug.cgi?id=67994 Nikita changed: What|Removed |Added Summary|System freezes when playing |System freezes (GPU lockup) |video on open source AMD|when playing video on open |drivers with VDPAU |source AMD drivers with ||VDPAU -- 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 67994] System freezes (GPU lockup) when playing video on open source AMD drivers with VDPAU
https://bugs.freedesktop.org/show_bug.cgi?id=67994 --- Comment #3 from Christian König --- Please post the full dmesg output, especially the bootup sequence. Does that also happen with dpm disabled? -- 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 67994] System freezes (GPU lockup) when playing video on open source AMD drivers with VDPAU
https://bugs.freedesktop.org/show_bug.cgi?id=67994 --- Comment #4 from Nikita --- Created attachment 83946 --> https://bugs.freedesktop.org/attachment.cgi?id=83946&action=edit Full dmesg log -- 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 67994] System freezes (GPU lockup) when playing video on open source AMD drivers with VDPAU
https://bugs.freedesktop.org/show_bug.cgi?id=67994 --- Comment #5 from Nikita --- (In reply to comment #3) > Does that also happen with dpm disabled? Without "radeon.dpm=1", all played normally -- 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 67981] Graphical Glitches with RV200 on IBM Thinkpad T40
https://bugs.freedesktop.org/show_bug.cgi?id=67981 Alex Deucher changed: What|Removed |Added Assignee|xorg-driver-...@lists.x.org |dri-devel@lists.freedesktop ||.org QA Contact|xorg-t...@lists.x.org | Product|xorg|Mesa Version|6.99.99.900 (7.0 RC0) |unspecified Component|Driver/Radeon |Drivers/DRI/Radeon --- Comment #1 from Alex Deucher --- This is probably a duplicate of bug 51658. -- 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 67994] Lockup with UVD and DPM on RV730
https://bugs.freedesktop.org/show_bug.cgi?id=67994 Christian König changed: What|Removed |Added Summary|System freezes (GPU lockup) |Lockup with UVD and DPM on |when playing video on open |RV730 |source AMD drivers with | |VDPAU | -- 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
[PATCH] drm/radeon: fix UVD message buffer validation
From: Christian König
When the message buffer is currently moving block until it is idle again.
Signed-off-by: Christian König
Cc: sta...@vger.kernel.org
---
drivers/gpu/drm/radeon/radeon_uvd.c |8
1 file changed, 8 insertions(+)
diff --git a/drivers/gpu/drm/radeon/radeon_uvd.c
b/drivers/gpu/drm/radeon/radeon_uvd.c
index f1c1575..b79f4f5 100644
--- a/drivers/gpu/drm/radeon/radeon_uvd.c
+++ b/drivers/gpu/drm/radeon/radeon_uvd.c
@@ -356,6 +356,14 @@ static int radeon_uvd_cs_msg(struct radeon_cs_parser *p,
struct radeon_bo *bo,
return -EINVAL;
}
+ if (bo->tbo.sync_obj) {
+ r = radeon_fence_wait(bo->tbo.sync_obj, false);
+ if (r) {
+ DRM_ERROR("Failed waiting for UVD message (%d)!\n", r);
+ return r;
+ }
+ }
+
r = radeon_bo_kmap(bo, &ptr);
if (r) {
DRM_ERROR("Failed mapping the UVD message (%d)!\n", r);
--
1.7.9.5
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Nouveau] [PATCH] drm/nouveau: mark last megabyte as usable
On Thu, Aug 8, 2013 at 1:24 AM, Maarten Lankhorst
wrote:
> It's my megabyte, I want to use it! At this point in init
> vbios is copied over already, so there's no reason it cannot
> used to hold other data now.
I believe there's areas in here where the SBIOS/VBIOS can communicate
to the driver on various events actually, at least in some situations.
I'd rather leave it reserved for the moment. Also, if/when we do do
this, we'll want to stick the vbios image back on module unload so
it's there for reload too.
Ben.
>
> Signed-off-by: Maarten Lankhorst
> ---
> diff --git a/drivers/gpu/drm/nouveau/core/subdev/fb/ramnvc0.c
> b/drivers/gpu/drm/nouveau/core/subdev/fb/ramnvc0.c
> index cf97c4d..507d35d 100644
> --- a/drivers/gpu/drm/nouveau/core/subdev/fb/ramnvc0.c
> +++ b/drivers/gpu/drm/nouveau/core/subdev/fb/ramnvc0.c
> @@ -119,7 +119,6 @@ nvc0_ram_create(struct nouveau_object *parent, struct
> nouveau_object *engine,
> struct nouveau_bios *bios = nouveau_bios(pfb);
> struct nouveau_ram *ram;
> const u32 rsvd_head = ( 256 * 1024) >> 12; /* vga memory */
> - const u32 rsvd_tail = (1024 * 1024) >> 12; /* vbios etc */
> u32 parts = nv_rd32(pfb, 0x022438);
> u32 pmask = nv_rd32(pfb, 0x022554);
> u32 bsize = nv_rd32(pfb, 0x10f20c);
> @@ -156,7 +155,7 @@ nvc0_ram_create(struct nouveau_object *parent, struct
> nouveau_object *engine,
> /* if all controllers have the same amount attached, there's no holes
> */
> if (uniform) {
> offset = rsvd_head;
> - length = (ram->size >> 12) - rsvd_head - rsvd_tail;
> + length = (ram->size >> 12) - rsvd_head;
> ret = nouveau_mm_init(&pfb->vram, offset, length, 1);
> } else {
> /* otherwise, address lowest common amount from 0GiB */
> @@ -167,7 +166,7 @@ nvc0_ram_create(struct nouveau_object *parent, struct
> nouveau_object *engine,
>
> /* and the rest starting from (8GiB + common_size) */
> offset = (0x02ULL >> 12) + (bsize << 8);
> - length = (ram->size >> 12) - (bsize << 8) - rsvd_tail;
> + length = (ram->size >> 12) - (bsize << 8);
>
> ret = nouveau_mm_init(&pfb->vram, offset, length, 0);
> if (ret)
>
> ___
> Nouveau mailing list
> nouv...@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/nouveau
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/nouveau: fix ltcg memory corruptions
On Thu, Aug 8, 2013 at 1:16 AM, Maarten Lankhorst
wrote:
> Allocating type=0 marks the memory as free. This allows the ltcg memory to be
> allocated twice. Add a BUG_ON in core/mm.c to prevent this ever happening
> again.
> Additionally some registers were not initialized in init, this causes them to
> be
> uninitialized after suspend.
Ack in general. A couple of things though:
1. Split the two changes into two patches
2. drm/nvc0-/ltcg, and not drm/nouveau - this is the format we
generally use for specific fixes
Thanks,
Ben.
>
> Signed-off-by: Maarten Lankhorst
> ---
> diff --git a/drivers/gpu/drm/nouveau/core/core/mm.c
> b/drivers/gpu/drm/nouveau/core/core/mm.c
> index d829172..7a4e089 100644
> --- a/drivers/gpu/drm/nouveau/core/core/mm.c
> +++ b/drivers/gpu/drm/nouveau/core/core/mm.c
> @@ -98,6 +98,8 @@ nouveau_mm_head(struct nouveau_mm *mm, u8 type, u32
> size_max, u32 size_min,
> u32 splitoff;
> u32 s, e;
>
> + BUG_ON(!type);
> +
> list_for_each_entry(this, &mm->free, fl_entry) {
> e = this->offset + this->length;
> s = this->offset;
> @@ -162,6 +164,8 @@ nouveau_mm_tail(struct nouveau_mm *mm, u8 type, u32
> size_max, u32 size_min,
> struct nouveau_mm_node *prev, *this, *next;
> u32 mask = align - 1;
>
> + BUG_ON(!type);
> +
> list_for_each_entry_reverse(this, &mm->free, fl_entry) {
> u32 e = this->offset + this->length;
> u32 s = this->offset;
> diff --git a/drivers/gpu/drm/nouveau/core/subdev/ltcg/nvc0.c
> b/drivers/gpu/drm/nouveau/core/subdev/ltcg/nvc0.c
> index bcca883..7288940 100644
> --- a/drivers/gpu/drm/nouveau/core/subdev/ltcg/nvc0.c
> +++ b/drivers/gpu/drm/nouveau/core/subdev/ltcg/nvc0.c
> @@ -30,8 +30,9 @@ struct nvc0_ltcg_priv {
> struct nouveau_ltcg base;
> u32 part_nr;
> u32 subp_nr;
> - struct nouveau_mm tags;
> u32 num_tags;
> + u32 tag_base;
> + struct nouveau_mm tags;
> struct nouveau_mm_node *tag_ram;
> };
>
> @@ -117,10 +118,6 @@ nvc0_ltcg_init_tag_ram(struct nouveau_fb *pfb, struct
> nvc0_ltcg_priv *priv)
> u32 tag_size, tag_margin, tag_align;
> int ret;
>
> - nv_wr32(priv, 0x17e8d8, priv->part_nr);
> - if (nv_device(pfb)->card_type >= NV_E0)
> - nv_wr32(priv, 0x17e000, priv->part_nr);
> -
> /* tags for 1/4 of VRAM should be enough (8192/4 per GiB of VRAM) */
> priv->num_tags = (pfb->ram->size >> 17) / 4;
> if (priv->num_tags > (1 << 17))
> @@ -142,7 +139,7 @@ nvc0_ltcg_init_tag_ram(struct nouveau_fb *pfb, struct
> nvc0_ltcg_priv *priv)
> tag_size += tag_align;
> tag_size = (tag_size + 0xfff) >> 12; /* round up */
>
> - ret = nouveau_mm_tail(&pfb->vram, 0, tag_size, tag_size, 1,
> + ret = nouveau_mm_tail(&pfb->vram, 1, tag_size, tag_size, 1,
> &priv->tag_ram);
> if (ret) {
> priv->num_tags = 0;
> @@ -152,7 +149,7 @@ nvc0_ltcg_init_tag_ram(struct nouveau_fb *pfb, struct
> nvc0_ltcg_priv *priv)
> tag_base += tag_align - 1;
> ret = do_div(tag_base, tag_align);
>
> - nv_wr32(priv, 0x17e8d4, tag_base);
> + priv->tag_base = tag_base;
> }
> ret = nouveau_mm_init(&priv->tags, 0, priv->num_tags, 1);
>
> @@ -182,8 +179,6 @@ nvc0_ltcg_ctor(struct nouveau_object *parent, struct
> nouveau_object *engine,
> }
> priv->subp_nr = nv_rd32(priv, 0x17e8dc) >> 28;
>
> - nv_mask(priv, 0x17e820, 0x0010, 0x); /* INTR_EN &= ~0x10
> */
> -
> ret = nvc0_ltcg_init_tag_ram(pfb, priv);
> if (ret)
> return ret;
> @@ -209,13 +204,36 @@ nvc0_ltcg_dtor(struct nouveau_object *object)
> nouveau_ltcg_destroy(ltcg);
> }
>
> +int
> +nvc0_ltcg_init(struct nouveau_object *object)
> +{
> + struct nouveau_ltcg *ltcg = (struct nouveau_ltcg *)object;
> + struct nvc0_ltcg_priv *priv = (struct nvc0_ltcg_priv *)ltcg;
> + struct nouveau_fb *pfb = nouveau_fb(ltcg->base.base.parent);
> + int ret;
> +
> + ret = nouveau_subdev_init(&pfb->base);
> + if (ret)
> + return ret;
> +
> + nv_mask(priv, 0x17e820, 0x0010, 0x); /* INTR_EN &= ~0x10
> */
> +
> + nv_wr32(priv, 0x17e8d8, priv->part_nr);
> + if (nv_device(pfb)->card_type >= NV_E0)
> + nv_wr32(priv, 0x17e000, priv->part_nr);
> +
> + nv_wr32(priv, 0x17e8d4, priv->tag_base);
> +
> + return 0;
> +}
> +
> struct nouveau_oclass
> nvc0_ltcg_oclass = {
> .handle = NV_SUBDEV(LTCG, 0xc0),
> .ofuncs = &(struct nouveau_ofuncs) {
> .ctor = nvc0_ltcg_ctor,
> .dtor = nvc0_ltcg_dtor,
> - .init = _nouveau_ltcg_init,
> + .init = nvc0_ltcg_init,
> .fini = _nouveau_ltcg_fini,
> },
> };
>
> __
[Bug 16193] NULL pointer dereference - radeon_unmap_vram_bos+0x22/0x50
https://bugzilla.kernel.org/show_bug.cgi?id=16193 Scott Wood changed: What|Removed |Added CC||sc...@buserror.net --- Comment #3 from Scott Wood --- I saw this (or something very similar) on Ubuntu's 3.8.0-27 kernel (but I hope this is useful information anyway -- I doubt it's an Ubuntu issue, and this code doesn't appear to have changed since 3.8), when using alt-enter to toggle fullscreen in dosbox (which worked many times in the past, so it's not easily reproduceable). The NULL pointer is in rdev->gem.objects. I notice that elsewhere, rdev->gem.mutex is held when the list is modified, but it does not appear to be held when traversed in radeon_unmap_vram_bos(). Will ttm_bo_unmap_virtual() ever acquire gem.mutex itself (i.e. can bo->destroy() be called)? It wasn't immediately obvious that it would from reading the code, but if ttm_bo_unmap_virtual() can't cause list entry deletion then why use list_for_each_entry_safe()? Is there something else that ensures that the list won't be modified concurrently with radeon_unmap_vram_bos()? -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 64201] OpenCL usage result segmentation fault on r600g with HD6850.
https://bugs.freedesktop.org/show_bug.cgi?id=64201 --- Comment #39 from Erdem U. Altınyurt --- Still got luck ups with my HD6850. Using latest trunk with 3.11 RC4 kernel.. :( -- 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
EDID modes unavailable when no connector/crtc available at boot
I am working on the HDMI driver for the i.MX6 as part of the larger DRM driver written by Sascha Hauer and need a little advice. I seem to be missing one important part of the subsystem that I haven't been able to resolve. In my testing, powering on the system with only a HDMI cable connected works perfectly. Resolution is set to 1920x1080 as requested (with the framebuffer console at the same resolution). If I boot up the system without an HDMI cable connected (or any other cable), I get the expected: [1.470273] imx_hdmi_connector_detect [1.470276] returned cable DISCONNECTED [1.470289] imx-drm imx-drm: No connectors reported connected with modes [1.470297] [drm] Cannot find any crtc or sizes - going 1024x768 When I connect the cable at a later time, all EDID detected modes are 'truncated' to '<= 1024x768', but because I have a video=xxx in bootargs, the driver still seems to initialize to 1920x1080, but with a framebuffer of 1024x768. I assume this is a mistake on my part, but I don't know what I'm missing that would cause it. I see in drm_crtc_helper.c:drm_helper_mode_fill_fb_struct that the width/height are set to the initialized mode. Later in drm_fb_helper.c:drm_fb_helper_hotplug_event, max_width if set to fb->width. This is what causes the modes to be truncated when the HDMI connector is finally connected (max_width is now limited to 1024). Suggestions appreciated. Regards Tony Prisk
EDID modes unavailable when no connector/crtc available at boot
On 11/08/13 20:42, Dave Airlie wrote:
> On Sun, Aug 11, 2013 at 2:41 PM, Tony Prisk wrote:
>> I am working on the HDMI driver for the i.MX6 as part of the larger DRM
>> driver written by Sascha Hauer and need a little advice. I seem to be
>> missing one important part of the subsystem that I haven't been able to
>> resolve.
>>
> fbcon is limited by boot sizes as at least with dynamic memory
> management and how fbdev works resizing the allocation is nearly
> impossible to do race free, since fbdev will hand out mmaps to
> userspace and that stops you from ever moving anything once the device
> is open.
>
> But this is only for the fbdev emulation, a real kms application
> should be able to use a larger size no problems.
>
> Dave.
It seems to be worse than just a fbcon issue as far as I can tell.
I am making an assumption, but I believe
'/sys/class/drm/card0-HDMI-A-1/modes' should list all the supported
modes of the connector (regardless of fbcon).
Using 'cat /sys/class/drm/card0-HDMI-A-1/modes', it appears the
supported modes are being limited by fbcon
1) HDMI Cable connected at bootup (fb @ 1920x1080)
cat /sys/class/drm/card0-HDMI-A-1/modes
1920x1080
1280x720
1280x720
720x576
720x480
640x480
2) HDMI Cable NOT connected at bootup (fb @ 1024x768), cable is then
connected after userspace has started (still in console)
cat /sys/class/drm/card0-HDMI-A-1/modes
720x576
720x480
640x480
Following back through the source:
static struct drm_connector_funcs imx_hdmi_connector_funcs = {
.fill_modes = drm_helper_probe_single_connector_modes,
...
};
static struct drm_connector_helper_funcs imx_hdmi_connector_helper_funcs = {
.get_modes = imx_hdmi_connector_get_modes,
.mode_valid = imx_hdmi_connector_mode_valid,
...
};
It appears that only drm_helper_probe_single_connector_modes() calls
.get_modes() and .mode_valid()
.fill_modes() is called from drm_fb_helper_probe_connector_modes(),
which is called from drm_fb_helper_hotplug_event()
drm_fb_helper_hotplug_event() sets max_width to fb_helper->fb->width,
and max_height to fb_helper->fb->height.
fb->width is 1024 if booted without the cable connected, hence the
clipping of the values.
Regards
Tony Prisk
Fixing nouveau for >4k PAGE_SIZE
Hi folks !
So I've been trying to figure out what it would take to make
nouveau work properly on architectures where PAGE_SIZE isn't
4k such as most ppc64's. An initial patch from Dave fixed a
bogon in nv41.c nv41_vm_map_sg() which was trying to handle
the case at that low level, but this isn't enough, and after
a bit of digging, I also think that's not the right approach:
So, from what I can tell, subdev/vm/base.c is not clean vs. PAGE_SIZE
in a number of places unless I'm mistaken. For example, in
nouveau_vm_map_sg_table(), something like that:
sglen = sg_dma_len(sg) >> PAGE_SHIFT;
end = pte + sglen;
Seems to imply an assumption here that the "pte" is in multiple of
PAGE_SHIFT, but afaik, it's not. So further down, we do:
for (m = 0; m < len; m++) {
dma_addr_t addr = sg_dma_address(sg) + (m <<
PAGE_SHIFT);
vmm->map_sg(vma, pgt, mem, pte, 1, &addr);
num--;
pte++;
But in fact, inside vmm->map_sg, with the current code, we will have
incremented pte by more than 1 ... so we basically lose track here.
if (num == 0)
goto finish;
}
if (unlikely(end >= max)) {
pde++;
pte = 0;
}
We need to similarly make sure we don't end up crossing accross two
pde's here, ie, that our 64k page isn't mapped at a non-multiple of
64k in the card space, where is that enforced ? (It might be, I don't
know). If it is, then we need to recalc the pde on each sub page.
So I'm thinking the right fix is to remove the inner loop in nv41.c
nv41_vm_map_sg() and similars, let those basically deal with card-size
PTEs exclusively, and move the breakdown logic inside
nouveau_vm_map_sg_table() and friendes, that's the only way it can get
pte and pde right anyway and it would generally work with all backends
(well, hopefully)
Now, to do that, I need a better understanding of the various things
in there since I'm not familiar with nouveau at all. What I think I've
figured out is with a few questions, it would be awesome if you could
answer them so I can have a shot at fixing it all :-)
- There is spg_shift and lpg_shift in the backend vmm. My understanding
is those correspond to the supported small and large page shift respectively
in the card's MMU, correct ? On nv41 they are both 12.
- vma->node->type indicates the desired page shift for a given vma
object we are trying to map. It may or may not match spg_shift. If it
doesn't, the 'big' flag gets set in the various vm/base.c functions,
which makes them use a different page table via:
struct nouveau_gpuobj *pgt = vm->pgt[pde].obj[big];
Question: Can that ever happen on nv41 ? Or rather, can node->type
ever be set to something that is neither vmm->spg_shift nor vmm->lpg_shift ?
- vma->node->offset is the location in bytes in the card memory space
of the nouveau_vma object, right ?
- In nouveau_vm_map_sg_table(), we take a "delta" argument. I assume that's
an indication of where within the "vma" we want to map the sg list, ie page
1 of the sg list gets mapped to page 1 of the VMA, correct ?
Thanks !
Ben.
Fixing nouveau for >4k PAGE_SIZE
On Sun, 2013-08-11 at 10:41 +1000, Benjamin Herrenschmidt wrote: > Now, to do that, I need a better understanding of the various things > in there since I'm not familiar with nouveau at all. What I think I've > figured out is with a few questions, it would be awesome if you could > answer them so I can have a shot at fixing it all :-) Ok, a few more questions :-) - in struct nouveau_mm_node, what unit are "offset" and "length" ? They *seem* to be hard wired to be in units of 4k (regardless of either of system page size) which I assume means card small page size, but "offset" is in bytes ? At least according to my parsing of the code in nouveau_vm_map_at(). The big question then is whether that represents card address space or system address space... I assume the former right ? So a function like nouveau_vm_map_at() is solely concerned with mapping a piece of card address space in the card VM and thus shouldn't be concerned by the system PAGE_SIZE at all, right ? IE. The only one we should actually care about here is nouveau_vm_map_sg_table() or am I missing an important piece of the puzzle ? Additionally, nv41.c has only map_sg() callbacks, no map() callbacks, should I assume that means that nouveau_vm_map() and nouveau_vm_map_at() will never be called on these ? - In vm/base.c this construct appears regulary: struct nouveau_gpuobj *pgt = vm->pgt[pde].obj[big]; Which makes me believe we have separate page tables for small vs. large pages (in card mmu) (though I assume big is always 0 on nv40 unless missed something, I want to make sure I'm not breaking everything else...). Thus I assume that each "pte" in a "big" page table maps a page size of 1 << vmm->lpg_shift, is that correct ? vmm->pgt_bits is always the same however, thus I assume that PDEs always map the same amount of space, but regions for large pages just have fewer PTEs, which seem to correspond to what the code does here: u32 pte = (offset & ((1 << vmm->pgt_bits) - 1)) >> bits; - My basic idea is to move the card page vs system PAGE breakdown up into vm/base.c, which seems reasonably simple in the case of nouveau_vm_map_sg_table() since we only call vmm->map_sg for one PTE at a time, but things get a bit trickier with nouveau_vm_map_sg which passes the whole page list down. Following my idea would mean essentially also making it operate one PTE at a time, thus potentially reducing the performance of the map operations. One option is to special case the PAGE_SIZE==12 case to keep the existing behaviour and operate in "reduced" (one PTE per call) mode in the other case but I dislike special casing like that (bitrots, one code path gets untested/unfixed, etc...) Another option would be to make struct nouveau_mem *mem ->pages always be an array of 4k (ie, create a breakdown when constructing that list), but I have yet to figure out what the impact would be (where that stuff gets created) and whether this is realistic at all... - struct nouveau_mem is called "node" in various places (in nouveau_ttm) which is confusing. What is the relationship between nouveau_mem, nouveau_mm and nouveau_mm_node ? nouveau_mem seems to be having things such as "offset" in multiple of PAGE_SIZE, but have a "page_shift" member that appears to match the buffer object page_shift, hence seem to indicate that it is a card page shift... Would it be possible, maybe, to add comments next to the fields in those various data structure indicating in which units they are ? - Similar confusion arises with things like struct ttm_mem_reg *mem. For example, in nouveau_ttm.c, I see statements like: ret = nouveau_vm_get(man->priv, mem->num_pages << 12, node->page_shift, NV_MEM_ACCESS_RW, &node->vma[0]); Which seems to indicate that mem->num_pages is in multiple of 4k always, though I would have though that a ttm object was in multiple of PAGE_SIZE, am I wrong ? Especially since the same object is later populated using: mem->start = node->vma[0].offset >> PAGE_SHIFT; So the "start" member is in units of PAGE_SHIFT here, not 12. So I'm still a bit confused :-) Cheers, Ben.
Fixing nouveau for >4k PAGE_SIZE
Op 11-08-13 07:36, Benjamin Herrenschmidt schreef: > On Sun, 2013-08-11 at 10:41 +1000, Benjamin Herrenschmidt wrote: >> Now, to do that, I need a better understanding of the various things >> in there since I'm not familiar with nouveau at all. What I think I've >> figured out is with a few questions, it would be awesome if you could >> answer them so I can have a shot at fixing it all :-) > Ok, a few more questions :-) > > - in struct nouveau_mm_node, what unit are "offset" and "length" ? Depends on the context. It's re-used a few times. In case of nouveau_vm it's multiples of 1<<12, which is the smallest unit a card can address. > They *seem* to be hard wired to be in units of 4k (regardless of either > of system page size) which I assume means card small page size, but > "offset" is in bytes ? At least according to my parsing of the code in > nouveau_vm_map_at(). Correct. > The big question then is whether that represents card address space or > system address space... I assume the former right ? So a function like > nouveau_vm_map_at() is solely concerned with mapping a piece of card > address space in the card VM and thus shouldn't be concerned by the > system PAGE_SIZE at all, right ? Former, but the code entangles system PAGE_SIZE and card PAGE_SIZE/SHIFT/MASK in some cases. > IE. The only one we should actually care about here is > nouveau_vm_map_sg_table() or am I missing an important piece of the > puzzle ? nouveau_vm_map_sg too. nouveau_vm_map is special, and also used to map VRAM into BAR1/BAR3 by subdev/bar code. > Additionally, nv41.c has only map_sg() callbacks, no map() callbacks, > should I assume that means that nouveau_vm_map() and nouveau_vm_map_at() > will never be called on these ? Correct. all cards before the nv50 family have no real vm. the BAR used for vram is just an identity mapping, not the entirety of VRAM may be accessible to the system. > - In vm/base.c this construct appears regulary: > > struct nouveau_gpuobj *pgt = vm->pgt[pde].obj[big]; > > Which makes me believe we have separate page tables for small vs. large > pages (in card mmu) (though I assume big is always 0 on nv40 unless > missed something, I want to make sure I'm not breaking everything > else...). > > Thus I assume that each "pte" in a "big" page table maps a page size > of 1 << vmm->lpg_shift, is that correct ? Correct, nv50+ are the only ones that support large pages. > vmm->pgt_bits is always the same however, thus I assume that PDEs always > map the same amount of space, but regions for large pages just have > fewer PTEs, which seem to correspond to what the code does here: > > u32 pte = (offset & ((1 << vmm->pgt_bits) - 1)) >> bits; > > - My basic idea is to move the card page vs system PAGE breakdown > up into vm/base.c, which seems reasonably simple in the case of > nouveau_vm_map_sg_table() since we only call vmm->map_sg for one PTE at > a time, but things get a bit trickier with nouveau_vm_map_sg which > passes the whole page list down. > > Following my idea would mean essentially also making it operate one PTE > at a time, thus potentially reducing the performance of the map > operations. > > One option is to special case the PAGE_SIZE==12 case to keep the > existing behaviour and operate in "reduced" (one PTE per call) > mode in the other case but I dislike special casing like that (bitrots, > one code path gets untested/unfixed, etc...) > > Another option would be to make struct nouveau_mem *mem ->pages always > be an array of 4k (ie, create a breakdown when constructing that list), > but I have yet to figure out what the impact would be (where that stuff > gets created) and whether this is realistic at all... > > - struct nouveau_mem is called "node" in various places (in > nouveau_ttm) which is confusing. What is the relationship between > nouveau_mem, nouveau_mm and nouveau_mm_node ? nouveau_mem seems to be > having things such as "offset" in multiple of PAGE_SIZE, but have a > "page_shift" member that appears to match the buffer object page_shift, > hence seem to indicate that it is a card page shift... > > Would it be possible, maybe, to add comments next to the fields in > those various data structure indicating in which units they are ? > > - Similar confusion arises with things like struct ttm_mem_reg *mem. > For example, in nouveau_ttm.c, I see statements like: > > ret = nouveau_vm_get(man->priv, mem->num_pages << 12, node->page_shift, >NV_MEM_ACCESS_RW, &node->vma[0]); > > Which seems to indicate that mem->num_pages is in multiple of 4k always, > though I would have though that a ttm object was in multiple of > PAGE_SIZE, am I wrong ? > > Especially since the same object is later populated using: > > mem->start = node->vma[0].offset >> PAGE_SHIFT; > > So the "start" member is in units of PAGE_SHIFT here, not 12. > > So I'm still a bit confused :-) > The fun has been doubled because TTM expects PAGE units, so some of the PAGE
[Bug 67888] R600g: GPU hang occurs when trying to do GPU profile of Trine 2 apitrace trace
https://bugs.freedesktop.org/show_bug.cgi?id=67888 --- Comment #3 from fossphreak at gmail.com --- It doesn't seem to be clear in the dmesg output - I am using the vanilla Linux 3.11-rc2 kernel. I can recompile the kernel with extra debugging options turned on if required. Do you need any other information? -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130811/bbb648d7/attachment.html>
Fixing nouveau for >4k PAGE_SIZE
On Sun, 2013-08-11 at 08:17 +0200, Maarten Lankhorst wrote:
> > So I'm still a bit confused :-)
> >
> The fun has been doubled because TTM expects PAGE units, so some of
> the PAGE_SHIFT's are
> genuine. Some may be a result of PAGE_SHIFT == 12, so honestly I don't
> know the specific ones.
Right, and the other way around too :-)
I think I found at least two cases where "12" was used where it should
have been PAGE_SHIFT (basically ttm_mem_reg->num_pages). This
is only the tip of the iceberg, so this isn't a formal patch submission,
but I would appreciate your thought as to whether the below is correct
(and thus I'm on the right track) :
--- a/drivers/gpu/drm/nouveau/nouveau_sgdma.c
+++ b/drivers/gpu/drm/nouveau/nouveau_sgdma.c
@@ -31,7 +31,7 @@ nv04_sgdma_bind(struct ttm_tt *ttm, struct ttm_mem_reg *mem)
{
struct nouveau_sgdma_be *nvbe = (struct nouveau_sgdma_be *)ttm;
struct nouveau_mem *node = mem->mm_node;
- u64 size = mem->num_pages << 12;
+ u64 size = mem->num_pages << PAGE_SHIFT;
if (ttm->sg) {
node->sg = ttm->sg;
diff --git a/drivers/gpu/drm/nouveau/nouveau_ttm.c b/drivers/gpu/drm/nouveau/nou
index 19e3757..f0629de 100644
--- a/drivers/gpu/drm/nouveau/nouveau_ttm.c
+++ b/drivers/gpu/drm/nouveau/nouveau_ttm.c
@@ -252,8 +252,8 @@ nv04_gart_manager_new(struct ttm_mem_type_manager *man,
node->page_shift = 12;
- ret = nouveau_vm_get(man->priv, mem->num_pages << 12, node->page_shift,
-NV_MEM_ACCESS_RW, &node->vma[0]);
+ ret = nouveau_vm_get(man->priv, mem->num_pages << PAGE_SHIFT,
+node->page_shift, NV_MEM_ACCESS_RW, &node->vma[0]);
if (ret) {
kfree(node);
Thanks !
Cheers,
Ben.
Fixing nouveau for >4k PAGE_SIZE
On Sun, 2013-08-11 at 17:06 +1000, Benjamin Herrenschmidt wrote:
> I think I found at least two cases where "12" was used where it should
> have been PAGE_SHIFT (basically ttm_mem_reg->num_pages). This
> is only the tip of the iceberg, so this isn't a formal patch submission,
> but I would appreciate your thought as to whether the below is correct
> (and thus I'm on the right track) :
This patch (which needs cleanups, and probably be broken down for
bisectability) makes it work for me. I've disabled nouveau_dri for now
as this has its own problems related to Ajax recent gallium endian
changes.
Note the horrible duplication of nouveau_vm_map_sg...
I think to fix it "cleanly" we probably need to slightly change the
->map_sg API to the vmmr. However, I do have a question whose answer
might make things a LOT easier if "yes" can make things a lot easier:
Can we guarantee that that such an sg object (I assume this is always
a ttm_bo getting placed in the "TT" memory, correct ?) has an alignment
in *card VM space* that is a multiple of the *system page size* ? Ie,
can we make that happen easily ?
For example, if my system page size is 64k, can we guarantee that it
will always be mapped in the card at a virtual address that is 64k
aligned ?
If that is the case, then we *know* that a given page in the page list
passed to nouveau_vm_map_sg() will never cross a pde boundary (will
always be fully contained in the bottom level of the page table). That
allows to simplify the code a bit, and maybe to write a unified function
that can still pass down page lists to the vmmr
On the other hand, if we have to handle misalignment, then we may as
well stick to 1 PTE at a time like my patch does to avoid horrible
complications.
Cheers,
Ben.
diff --git a/drivers/gpu/drm/nouveau/core/engine/fifo/nv40.c
b/drivers/gpu/drm/nouveau/core/engine/fifo/nv40.c
index 5c7433d..c314a5f 100644
--- a/drivers/gpu/drm/nouveau/core/engine/fifo/nv40.c
+++ b/drivers/gpu/drm/nouveau/core/engine/fifo/nv40.c
@@ -190,8 +190,8 @@ nv40_fifo_chan_ctor(struct nouveau_object *parent,
if (size < sizeof(*args))
return -EINVAL;
- ret = nouveau_fifo_channel_create(parent, engine, oclass, 0, 0xc0,
- 0x1000, args->pushbuf,
+ ret = nouveau_fifo_channel_create(parent, engine, oclass, 0, 0x80,
+ 0x1, args->pushbuf,
(1ULL << NVDEV_ENGINE_DMAOBJ) |
(1ULL << NVDEV_ENGINE_SW) |
(1ULL << NVDEV_ENGINE_GR) |
diff --git a/drivers/gpu/drm/nouveau/core/subdev/vm/base.c
b/drivers/gpu/drm/nouveau/core/subdev/vm/base.c
index ef3133e..5833851 100644
--- a/drivers/gpu/drm/nouveau/core/subdev/vm/base.c
+++ b/drivers/gpu/drm/nouveau/core/subdev/vm/base.c
@@ -84,10 +84,11 @@ nouveau_vm_map_sg_table(struct nouveau_vma *vma, u64 delta,
u64 length,
{
struct nouveau_vm *vm = vma->vm;
struct nouveau_vmmgr *vmm = vm->vmm;
- int big = vma->node->type != vmm->spg_shift;
+ u32 shift = vma->node->type;
+ int big = shift != vmm->spg_shift;
u32 offset = vma->node->offset + (delta >> 12);
- u32 bits = vma->node->type - 12;
- u32 num = length >> vma->node->type;
+ u32 bits = shift - 12;
+ u32 num = length >> shift;
u32 pde = (offset >> vmm->pgt_bits) - vm->fpde;
u32 pte = (offset & ((1 << vmm->pgt_bits) - 1)) >> bits;
u32 max = 1 << (vmm->pgt_bits - bits);
@@ -98,7 +99,7 @@ nouveau_vm_map_sg_table(struct nouveau_vma *vma, u64 delta,
u64 length,
for_each_sg(mem->sg->sgl, sg, mem->sg->nents, i) {
struct nouveau_gpuobj *pgt = vm->pgt[pde].obj[big];
- sglen = sg_dma_len(sg) >> PAGE_SHIFT;
+ sglen = sg_dma_len(sg) >> shift;
end = pte + sglen;
if (unlikely(end >= max))
@@ -106,7 +107,7 @@ nouveau_vm_map_sg_table(struct nouveau_vma *vma, u64 delta,
u64 length,
len = end - pte;
for (m = 0; m < len; m++) {
- dma_addr_t addr = sg_dma_address(sg) + (m <<
PAGE_SHIFT);
+ dma_addr_t addr = sg_dma_address(sg) + (m << shift);
vmm->map_sg(vma, pgt, mem, pte, 1, &addr);
num--;
@@ -121,7 +122,7 @@ nouveau_vm_map_sg_table(struct nouveau_vma *vma, u64 delta,
u64 length,
}
if (m < sglen) {
for (; m < sglen; m++) {
- dma_addr_t addr = sg_dma_address(sg) + (m <<
PAGE_SHIFT);
+ dma_addr_t addr = sg_dma_address(sg) + (m <<
shift);
vmm->map_sg(vma, pgt, mem, pte, 1, &addr);
num--;
@@ -136,6 +137,7 @@ finish:
vmm->flush(vm);
}
+#if PAGE_SHIFT == 12
void
nouveau_
EDID modes unavailable when no connector/crtc available at boot
On Sun, Aug 11, 2013 at 2:41 PM, Tony Prisk wrote: > I am working on the HDMI driver for the i.MX6 as part of the larger DRM > driver written by Sascha Hauer and need a little advice. I seem to be > missing one important part of the subsystem that I haven't been able to > resolve. > fbcon is limited by boot sizes as at least with dynamic memory management and how fbdev works resizing the allocation is nearly impossible to do race free, since fbdev will hand out mmaps to userspace and that stops you from ever moving anything once the device is open. But this is only for the fbdev emulation, a real kms application should be able to use a larger size no problems. Dave.
Fixing nouveau for >4k PAGE_SIZE
Op 11-08-13 10:04, Benjamin Herrenschmidt schreef:
> On Sun, 2013-08-11 at 17:06 +1000, Benjamin Herrenschmidt wrote:
>
>> I think I found at least two cases where "12" was used where it should
>> have been PAGE_SHIFT (basically ttm_mem_reg->num_pages). This
>> is only the tip of the iceberg, so this isn't a formal patch submission,
>> but I would appreciate your thought as to whether the below is correct
>> (and thus I'm on the right track) :
> This patch (which needs cleanups, and probably be broken down for
> bisectability) makes it work for me. I've disabled nouveau_dri for now
> as this has its own problems related to Ajax recent gallium endian
> changes.
>
> Note the horrible duplication of nouveau_vm_map_sg...
>
> I think to fix it "cleanly" we probably need to slightly change the
> ->map_sg API to the vmmr. However, I do have a question whose answer
> might make things a LOT easier if "yes" can make things a lot easier:
>
> Can we guarantee that that such an sg object (I assume this is always
> a ttm_bo getting placed in the "TT" memory, correct ?) has an alignment
> in *card VM space* that is a multiple of the *system page size* ? Ie,
> can we make that happen easily ?
>
> For example, if my system page size is 64k, can we guarantee that it
> will always be mapped in the card at a virtual address that is 64k
> aligned ?
>
> If that is the case, then we *know* that a given page in the page list
> passed to nouveau_vm_map_sg() will never cross a pde boundary (will
> always be fully contained in the bottom level of the page table). That
> allows to simplify the code a bit, and maybe to write a unified function
> that can still pass down page lists to the vmmr
>
> On the other hand, if we have to handle misalignment, then we may as
> well stick to 1 PTE at a time like my patch does to avoid horrible
> complications.
>
> Cheers,
> Ben.
>
> diff --git a/drivers/gpu/drm/nouveau/core/engine/fifo/nv40.c
> b/drivers/gpu/drm/nouveau/core/engine/fifo/nv40.c
> index 5c7433d..c314a5f 100644
> --- a/drivers/gpu/drm/nouveau/core/engine/fifo/nv40.c
> +++ b/drivers/gpu/drm/nouveau/core/engine/fifo/nv40.c
> @@ -190,8 +190,8 @@ nv40_fifo_chan_ctor(struct nouveau_object *parent,
> if (size < sizeof(*args))
> return -EINVAL;
>
> - ret = nouveau_fifo_channel_create(parent, engine, oclass, 0, 0xc0,
> - 0x1000, args->pushbuf,
> + ret = nouveau_fifo_channel_create(parent, engine, oclass, 0, 0x80,
> + 0x1, args->pushbuf,
> (1ULL << NVDEV_ENGINE_DMAOBJ) |
> (1ULL << NVDEV_ENGINE_SW) |
> (1ULL << NVDEV_ENGINE_GR) |
Why the size change?
> diff --git a/drivers/gpu/drm/nouveau/core/subdev/vm/base.c
> b/drivers/gpu/drm/nouveau/core/subdev/vm/base.c
> index ef3133e..5833851 100644
> --- a/drivers/gpu/drm/nouveau/core/subdev/vm/base.c
> +++ b/drivers/gpu/drm/nouveau/core/subdev/vm/base.c
> @@ -84,10 +84,11 @@ nouveau_vm_map_sg_table(struct nouveau_vma *vma, u64
> delta, u64 length,
> {
> struct nouveau_vm *vm = vma->vm;
> struct nouveau_vmmgr *vmm = vm->vmm;
> - int big = vma->node->type != vmm->spg_shift;
> + u32 shift = vma->node->type;
> + int big = shift != vmm->spg_shift;
> u32 offset = vma->node->offset + (delta >> 12);
> - u32 bits = vma->node->type - 12;
> - u32 num = length >> vma->node->type;
> + u32 bits = shift - 12;
> + u32 num = length >> shift;
> u32 pde = (offset >> vmm->pgt_bits) - vm->fpde;
> u32 pte = (offset & ((1 << vmm->pgt_bits) - 1)) >> bits;
> u32 max = 1 << (vmm->pgt_bits - bits);
> @@ -98,7 +99,7 @@ nouveau_vm_map_sg_table(struct nouveau_vma *vma, u64 delta,
> u64 length,
>
> for_each_sg(mem->sg->sgl, sg, mem->sg->nents, i) {
> struct nouveau_gpuobj *pgt = vm->pgt[pde].obj[big];
> - sglen = sg_dma_len(sg) >> PAGE_SHIFT;
> + sglen = sg_dma_len(sg) >> shift;
>
> end = pte + sglen;
> if (unlikely(end >= max))
Please add a WARN_ON(big); in map_sg and map_sg_table if you do this.
> @@ -106,7 +107,7 @@ nouveau_vm_map_sg_table(struct nouveau_vma *vma, u64
> delta, u64 length,
> len = end - pte;
>
> for (m = 0; m < len; m++) {
> - dma_addr_t addr = sg_dma_address(sg) + (m <<
> PAGE_SHIFT);
> + dma_addr_t addr = sg_dma_address(sg) + (m << shift);
>
> vmm->map_sg(vma, pgt, mem, pte, 1, &addr);
> num--;
> @@ -121,7 +122,7 @@ nouveau_vm_map_sg_table(struct nouveau_vma *vma, u64
> delta, u64 length,
> }
> if (m < sglen) {
> for (; m < sglen; m++) {
> - dma_addr_t addr = sg_dma_address(sg) + (m <<
> PAGE_SHIFT);
> +
Fixing nouveau for >4k PAGE_SIZE
On Sun, 2013-08-11 at 11:02 +0200, Maarten Lankhorst wrote:
> > diff --git a/drivers/gpu/drm/nouveau/core/engine/fifo/nv40.c
> > b/drivers/gpu/drm/nouveau/core/engine/fifo/nv40.c
> > index 5c7433d..c314a5f 100644
> > --- a/drivers/gpu/drm/nouveau/core/engine/fifo/nv40.c
> > +++ b/drivers/gpu/drm/nouveau/core/engine/fifo/nv40.c
> > @@ -190,8 +190,8 @@ nv40_fifo_chan_ctor(struct nouveau_object *parent,
> > if (size < sizeof(*args))
> > return -EINVAL;
> >
> > - ret = nouveau_fifo_channel_create(parent, engine, oclass, 0, 0xc0,
> > - 0x1000, args->pushbuf,
> > + ret = nouveau_fifo_channel_create(parent, engine, oclass, 0, 0x80,
> > + 0x1, args->pushbuf,
> > (1ULL << NVDEV_ENGINE_DMAOBJ) |
> > (1ULL << NVDEV_ENGINE_SW) |
> > (1ULL << NVDEV_ENGINE_GR) |
> Why the size change?
This reverts the value to older ones, however that patch might not be
needed anymore (I was carrying it from Dave but if we don't map the
registers into userspace we shouldn't need to force align them).
> > diff --git a/drivers/gpu/drm/nouveau/core/subdev/vm/base.c
> > b/drivers/gpu/drm/nouveau/core/subdev/vm/base.c
> > index ef3133e..5833851 100644
> > --- a/drivers/gpu/drm/nouveau/core/subdev/vm/base.c
> > +++ b/drivers/gpu/drm/nouveau/core/subdev/vm/base.c
> > @@ -84,10 +84,11 @@ nouveau_vm_map_sg_table(struct nouveau_vma *vma, u64
> > delta, u64 length,
> > {
> > struct nouveau_vm *vm = vma->vm;
> > struct nouveau_vmmgr *vmm = vm->vmm;
> > - int big = vma->node->type != vmm->spg_shift;
> > + u32 shift = vma->node->type;
> > + int big = shift != vmm->spg_shift;
> > u32 offset = vma->node->offset + (delta >> 12);
> > - u32 bits = vma->node->type - 12;
> > - u32 num = length >> vma->node->type;
> > + u32 bits = shift - 12;
> > + u32 num = length >> shift;
> > u32 pde = (offset >> vmm->pgt_bits) - vm->fpde;
> > u32 pte = (offset & ((1 << vmm->pgt_bits) - 1)) >> bits;
> > u32 max = 1 << (vmm->pgt_bits - bits);
> > @@ -98,7 +99,7 @@ nouveau_vm_map_sg_table(struct nouveau_vma *vma, u64
> > delta, u64 length,
> >
> > for_each_sg(mem->sg->sgl, sg, mem->sg->nents, i) {
> > struct nouveau_gpuobj *pgt = vm->pgt[pde].obj[big];
> > - sglen = sg_dma_len(sg) >> PAGE_SHIFT;
> > + sglen = sg_dma_len(sg) >> shift;
> >
> > end = pte + sglen;
> > if (unlikely(end >= max))
> Please add a WARN_ON(big); in map_sg and map_sg_table if you do this.
So that's debatable :-)
The above code is map_sg. Arguably my patch *fixes* using it with card
large pages :-)
IE, Look at the "usual" case (PAGE_SHIFT=12). Today, the above means
sglen will be in units of small pages. But everything else in that loop
operates in units of whatever is represented by the pte, which can
either be 4k or larger.
So adding "sglen" to "pte" was never right for shift != 12 before
(regardless of PAGE_SHIFT).
With my patch, it's more correct, so as such, adding a WARN_ON here
wouldn't be "if I do this" :-)
Now, the "big" case still cannot really work here with PAGE_SHIFT=12,
because that would require the sg segments to be multiple of
"shift" (the card large page) and that is not going to be the case.
So funnily enough, we *could* use card large pages of 64k ("big") if ...
we had PAGE_SHIFT=16 ... which we do on ppc64 :-) But not anywhere else.
But yes, the point remains, in the general case, that function cannot
work for the "big" case, so I wonder if we should catch it with a
WARN_ON and maybe simplify the code a bunch while at it...
> > @@ -106,7 +107,7 @@ nouveau_vm_map_sg_table(struct nouveau_vma *vma, u64
> > delta, u64 length,
> > len = end - pte;
> >
> > for (m = 0; m < len; m++) {
> > - dma_addr_t addr = sg_dma_address(sg) + (m <<
> > PAGE_SHIFT);
> > + dma_addr_t addr = sg_dma_address(sg) + (m << shift);
> >
> > vmm->map_sg(vma, pgt, mem, pte, 1, &addr);
> > num--;
> > @@ -121,7 +122,7 @@ nouveau_vm_map_sg_table(struct nouveau_vma *vma, u64
> > delta, u64 length,
> > }
> > if (m < sglen) {
> > for (; m < sglen; m++) {
> > - dma_addr_t addr = sg_dma_address(sg) + (m <<
> > PAGE_SHIFT);
> > + dma_addr_t addr = sg_dma_address(sg) + (m <<
> > shift);
> >
> > vmm->map_sg(vma, pgt, mem, pte, 1, &addr);
> > num--;
> > @@ -136,6 +137,7 @@ finish:
> > vmm->flush(vm);
> > }
> >
> > +#if PAGE_SHIFT == 12
> > void
> > nouveau_vm_map_sg(struct nouveau_vma *vma, u64 delta, u64 length,
> > struct nouveau_mem *mem)
> > @@ -143,10 +145,11 @@ nouveau_vm_map_sg(struct nouveau_vma *vma
[PATCH] i915: Fix SDVO potentially turning off randomly
On Sat, Aug 10, 2013 at 09:57:57PM +0200, Guillaume Clement wrote: > Some Poulsbo cards seem to incorrectly report > SDVO_CMD_STATUS_TARGET_NOT_SPECIFIED instead of SDVO_CMD_STATUS_PENDING, > which causes the display to be turned off. > > This could also happen to i915. > > Signed-off-by: Guillaume Clement Queued for -next, thanks for the patch. Let's see whether we're lucky and this fixes something ;-) -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch
[PATCH] gma500: Fix SDVO turning off randomly
On Sat, Aug 10, 2013 at 10:12 PM, Patrik Jakobsson wrote: > I will give this a spin on my gma500 and i915 hardware on monday. The gma500 > sdvo code should be pretty much identical to i915 from around 2011 but I guess > we've diverged since then. I'll also rework sdvo for gma500 a little in the > coming days when I start working on Minnowboard support so I'll probably > compare > it to i915 for any peculiarities. If you take this opportunity to share a bit of code between gma500 and i915 (the sdvo #defines header and maybe the sdvo i2c read/write and cmd helpers) I'd be interested in such a patch. We probably need an struct intel_sdvo_chip to abstract away a few things. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch
EDID modes unavailable when no connector/crtc available at boot
On Sun, Aug 11, 2013 at 7:42 PM, Tony Prisk wrote:
> On 11/08/13 20:42, Dave Airlie wrote:
>>
>> On Sun, Aug 11, 2013 at 2:41 PM, Tony Prisk wrote:
>>>
>>> I am working on the HDMI driver for the i.MX6 as part of the larger DRM
>>> driver written by Sascha Hauer and need a little advice. I seem to be
>>> missing one important part of the subsystem that I haven't been able to
>>> resolve.
>>>
>> fbcon is limited by boot sizes as at least with dynamic memory
>> management and how fbdev works resizing the allocation is nearly
>> impossible to do race free, since fbdev will hand out mmaps to
>> userspace and that stops you from ever moving anything once the device
>> is open.
>>
>> But this is only for the fbdev emulation, a real kms application
>> should be able to use a larger size no problems.
>>
>> Dave.
>
> It seems to be worse than just a fbcon issue as far as I can tell.
>
> I am making an assumption, but I believe
> '/sys/class/drm/card0-HDMI-A-1/modes' should list all the supported modes of
> the connector (regardless of fbcon).
> Using 'cat /sys/class/drm/card0-HDMI-A-1/modes', it appears the supported
> modes are being limited by fbcon
>
> 1) HDMI Cable connected at bootup (fb @ 1920x1080)
> cat /sys/class/drm/card0-HDMI-A-1/modes
> 1920x1080
> 1280x720
> 1280x720
> 720x576
> 720x480
> 640x480
>
> 2) HDMI Cable NOT connected at bootup (fb @ 1024x768), cable is then
> connected after userspace has started (still in console)
> cat /sys/class/drm/card0-HDMI-A-1/modes
> 720x576
> 720x480
> 640x480
>
>
> Following back through the source:
>
> static struct drm_connector_funcs imx_hdmi_connector_funcs = {
> .fill_modes = drm_helper_probe_single_connector_modes,
> ...
> };
>
> static struct drm_connector_helper_funcs imx_hdmi_connector_helper_funcs = {
> .get_modes = imx_hdmi_connector_get_modes,
> .mode_valid = imx_hdmi_connector_mode_valid,
> ...
> };
>
>
> It appears that only drm_helper_probe_single_connector_modes() calls
> .get_modes() and .mode_valid()
> .fill_modes() is called from drm_fb_helper_probe_connector_modes(), which is
> called from drm_fb_helper_hotplug_event()
> drm_fb_helper_hotplug_event() sets max_width to fb_helper->fb->width, and
> max_height to fb_helper->fb->height.
> fb->width is 1024 if booted without the cable connected, hence the clipping
> of the values.
fill_modes is also called from the drm_crtc.c userspace interface, all
the functions in drm_fb_helper are for fbdev/con use, the fact sysfs
is wrong is only a side effect.
Userspace should get a full list of modes, try using the modetest
application which I think should work.
Dave.
[Bug 67994] New: System freezes when playing video on open source AMD drivers with VDPAU
https://bugs.freedesktop.org/show_bug.cgi?id=67994 Priority: medium Bug ID: 67994 Assignee: dri-devel at lists.freedesktop.org Summary: System freezes when playing video on open source AMD drivers with VDPAU Severity: normal Classification: Unclassified OS: Linux (All) Reporter: scorp.exe at yandex.ua Hardware: x86 (IA32) Status: NEW Version: XOrg CVS Component: DRM/Radeon Product: DRI Kernel - Linux 3.11rc4 Version mesa-common-dev - 9.2.0~git20130729+9.2.9b8ad643-0ubuntu0sarvatt~raring Version libg3dvl-mesa - 9.3~git1308091520.e8d897~gd~r Driver - Gallium 0.4 To repeat the freezing - start the video on player with support for VDPAU (mplayer or XBMC), stop it, and then run another video. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130811/bb2ac3df/attachment-0001.html>
[Bug 67994] System freezes when playing video on open source AMD drivers with VDPAU
https://bugs.freedesktop.org/show_bug.cgi?id=67994 --- Comment #1 from Nikita --- My graphic card - Mobility Radeon HD 4650 -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130811/1ad17a7b/attachment.html>
[Bug 43829] Resuming my AMD A4-3300 based laptop leaves the screen black
https://bugs.freedesktop.org/show_bug.cgi?id=43829 --- Comment #29 from ka.nick at mail.ru --- I've the same issue on my HP4545s laptop (A4-4300M CPU). At boot time I get ... [drm:radeon_acpi_init] *ERROR* Cannot find a backlight controller ... then the computer boots and works just fine (except the brightness control is @ /sys/class/backlight/radeon_bl0/brightness, commonly unrecognizable by the software) but after resuming I have totally black screen. I can still ssh to it: it resumes normally - the only thing that goes wrong is the screen remains off. (It goes off as soon as the resume process begins). Kernels 3.9.X still have the issue. I'm not sure the absence of the ACPI-controllable brightness is relevant to the case. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130811/a56ba9ce/attachment.html>
[Bug 67994] System freezes when playing video on open source AMD drivers with VDPAU
https://bugs.freedesktop.org/show_bug.cgi?id=67994 --- Comment #2 from Nikita --- Created attachment 83941 --> https://bugs.freedesktop.org/attachment.cgi?id=83941&action=edit dmesg log -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130811/7b35ab96/attachment.html>
[Bug 67994] System freezes (GPU lockup) when playing video on open source AMD drivers with VDPAU
https://bugs.freedesktop.org/show_bug.cgi?id=67994 Nikita changed: What|Removed |Added Summary|System freezes when playing |System freezes (GPU lockup) |video on open source AMD|when playing video on open |drivers with VDPAU |source AMD drivers with ||VDPAU -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130811/1d189065/attachment.html>
[Bug 67994] System freezes (GPU lockup) when playing video on open source AMD drivers with VDPAU
https://bugs.freedesktop.org/show_bug.cgi?id=67994 --- Comment #3 from Christian K?nig --- Please post the full dmesg output, especially the bootup sequence. Does that also happen with dpm disabled? -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130811/af434c8f/attachment.html>
[Bug 67994] System freezes (GPU lockup) when playing video on open source AMD drivers with VDPAU
https://bugs.freedesktop.org/show_bug.cgi?id=67994 --- Comment #4 from Nikita --- Created attachment 83946 --> https://bugs.freedesktop.org/attachment.cgi?id=83946&action=edit Full dmesg log -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130811/3f00ca8b/attachment.html>
[Bug 67994] System freezes (GPU lockup) when playing video on open source AMD drivers with VDPAU
https://bugs.freedesktop.org/show_bug.cgi?id=67994 --- Comment #5 from Nikita --- (In reply to comment #3) > Does that also happen with dpm disabled? Without "radeon.dpm=1", all played normally -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130811/4fc0c367/attachment.html>
[Bug 67981] Graphical Glitches with RV200 on IBM Thinkpad T40
https://bugs.freedesktop.org/show_bug.cgi?id=67981 Alex Deucher changed: What|Removed |Added Assignee|xorg-driver-ati at lists.x.org |dri-devel at lists.freedesktop ||.org QA Contact|xorg-team at lists.x.org | Product|xorg|Mesa Version|6.99.99.900 (7.0 RC0) |unspecified Component|Driver/Radeon |Drivers/DRI/Radeon --- Comment #1 from Alex Deucher --- This is probably a duplicate of bug 51658. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130811/655d9780/attachment-0001.html>
[Bug 67994] Lockup with UVD and DPM on RV730
https://bugs.freedesktop.org/show_bug.cgi?id=67994 Christian K?nig changed: What|Removed |Added Summary|System freezes (GPU lockup) |Lockup with UVD and DPM on |when playing video on open |RV730 |source AMD drivers with | |VDPAU | -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130811/dc8ca3de/attachment.html>
[PATCH] drm/radeon: fix UVD message buffer validation
From: Christian K?nig
When the message buffer is currently moving block until it is idle again.
Signed-off-by: Christian K?nig
Cc: stable at vger.kernel.org
---
drivers/gpu/drm/radeon/radeon_uvd.c |8
1 file changed, 8 insertions(+)
diff --git a/drivers/gpu/drm/radeon/radeon_uvd.c
b/drivers/gpu/drm/radeon/radeon_uvd.c
index f1c1575..b79f4f5 100644
--- a/drivers/gpu/drm/radeon/radeon_uvd.c
+++ b/drivers/gpu/drm/radeon/radeon_uvd.c
@@ -356,6 +356,14 @@ static int radeon_uvd_cs_msg(struct radeon_cs_parser *p,
struct radeon_bo *bo,
return -EINVAL;
}
+ if (bo->tbo.sync_obj) {
+ r = radeon_fence_wait(bo->tbo.sync_obj, false);
+ if (r) {
+ DRM_ERROR("Failed waiting for UVD message (%d)!\n", r);
+ return r;
+ }
+ }
+
r = radeon_bo_kmap(bo, &ptr);
if (r) {
DRM_ERROR("Failed mapping the UVD message (%d)!\n", r);
--
1.7.9.5
