Hi, Lucas, sorry for so long a delay because I have a holiday for one month.
I found Loongson-3 must turn on SWIOTLB if the system memory has
addresses above 4G. As I know, there are two ways to get a DMA addr,
the first way is use dma_alloc_coherent(), and the other one is use
map_page()/map_sg()
On Wed August 1 2012 22:49:57 Rémi Denis-Courmont wrote:
> Le mercredi 1 août 2012 14:35:03 Laurent Pinchart, vous avez écrit :
> > > But in general, the V4L element in the pipeline does not know how fast
> > > the downstream element(s) will consume the buffers. Thus it has to copy
> > > from the M
On Thu August 2 2012 08:56:43 Rémi Denis-Courmont wrote:
> Le jeudi 2 août 2012 09:35:58 Hans Verkuil, vous avez écrit :
> > On Wed August 1 2012 22:49:57 Rémi Denis-Courmont wrote:
> > > > What about using the CREATE_BUFS ioctl to add new MMAP buffers at
> > > > runtime ?
> > >
> > > Does CREATE_
On Wed, 2012-08-01 at 09:25 -0500, Rob Clark wrote:
> On Wed, Aug 1, 2012 at 4:21 AM, Tomi Valkeinen wrote:
> > I guess the fact is that DRM concepts do not really match the OMAP DSS
> > hardware, and we'll have to use whatever gives us least problems.
>
> Actually, I think it does map fairly we
On Wed, 2012-08-01 at 22:08 -0700, bwidawsk wrote:
> On 2012-08-01 03:06, Chris Wilson wrote:
> > On Wed, 01 Aug 2012 10:38:36 +0100, James Bottomley
> > wrote:
> >> On Wed, 2012-08-01 at 09:58 +0100, Chris Wilson wrote:
> >> > On Wed, 01 Aug 2012 09:45:04 +0100, James Bottomley
> >> wrote:
> >>
On 2012-08-02 00:20, James Bottomley wrote:
On Wed, 2012-08-01 at 22:08 -0700, bwidawsk wrote:
On 2012-08-01 03:06, Chris Wilson wrote:
> On Wed, 01 Aug 2012 10:38:36 +0100, James Bottomley
> wrote:
>> On Wed, 2012-08-01 at 09:58 +0100, Chris Wilson wrote:
>> > On Wed, 01 Aug 2012 09:45:04 +010
On Thu, Aug 2, 2012 at 2:13 AM, Tomi Valkeinen wrote:
> On Wed, 2012-08-01 at 09:25 -0500, Rob Clark wrote:
>> On Wed, Aug 1, 2012 at 4:21 AM, Tomi Valkeinen wrote:
>
>> > I guess the fact is that DRM concepts do not really match the OMAP DSS
>> > hardware, and we'll have to use whatever gives us
On Thu, 2012-08-02 at 07:45 -0500, Rob Clark wrote:
> On Thu, Aug 2, 2012 at 2:13 AM, Tomi Valkeinen wrote:
> > On Wed, 2012-08-01 at 09:25 -0500, Rob Clark wrote:
> >> On Wed, Aug 1, 2012 at 4:21 AM, Tomi Valkeinen
> >> wrote:
> >
> >> > I guess the fact is that DRM concepts do not really match
On Thu, Aug 02, 2012 at 08:45:30AM +0800, Zhang Rui wrote:
> On 三, 2012-08-01 at 15:49 +0200, Luca Tettamanti wrote:
> > AMD ACPI interface may overload the standard event
> > ACPI_VIDEO_NOTIFY_PROBE (0x81) to signal AMD-specific events. In such
> > cases we don't want to send the keypress (KEY_SWI
On Thu, Aug 2, 2012 at 8:15 AM, Tomi Valkeinen wrote:
> On Thu, 2012-08-02 at 07:45 -0500, Rob Clark wrote:
>> On Thu, Aug 2, 2012 at 2:13 AM, Tomi Valkeinen wrote:
>> > On Wed, 2012-08-01 at 09:25 -0500, Rob Clark wrote:
>> >> On Wed, Aug 1, 2012 at 4:21 AM, Tomi Valkeinen
>> >> wrote:
>> >
>>
I admit I'm not really an ACPI expert, but thinking about this more,
I'm wondering if maybe we should just send the appropriate brightness
change, switch display, etc. event to userspace rather than handling
it directly in the radeon driver, then let userspace callback down via
the bl interface, et
From: Jerome Glisse
Lock/unlock mutex in proper order to avoid deadlock in case
of GPU reset triggered from VM code path.
Cc: sta...@vger.kernel.org [3.5]
Signed-off-by: Jerome Glisse
---
drivers/gpu/drm/radeon/radeon_gart.c | 11 +--
1 file changed, 9 insertions(+), 2 deletions(-)
On Thu, Aug 2, 2012 at 12:05 PM, wrote:
> From: Jerome Glisse
>
> Lock/unlock mutex in proper order to avoid deadlock in case
> of GPU reset triggered from VM code path.
>
> Cc: sta...@vger.kernel.org [3.5]
> Signed-off-by: Jerome Glisse
Reviewed-by: Alex Deucher
> ---
> drivers/gpu/drm/rad
Hi Laurent, Hi Dima,
On 06/27/2012 10:40 PM, Laurent Pinchart wrote:
> Hi Dima,
>
> On Tuesday 26 June 2012 13:53:34 Dima Zavin wrote:
>> On Tue, Jun 26, 2012 at 2:40 AM, Hans Verkuil wrote:
>>> On Tue 26 June 2012 11:11:06 Laurent Pinchart wrote:
On Tuesday 26 June 2012 10:40:44 Tomasz Sta
On Thu, Aug 2, 2012 at 5:03 PM, Alex Deucher wrote:
> I admit I'm not really an ACPI expert, but thinking about this more,
> I'm wondering if maybe we should just send the appropriate brightness
> change, switch display, etc. event to userspace rather than handling
> it directly in the radeon driv
On Thu, Aug 2, 2012 at 12:31 PM, Luca Tettamanti wrote:
> On Thu, Aug 2, 2012 at 5:03 PM, Alex Deucher wrote:
>> I admit I'm not really an ACPI expert, but thinking about this more,
>> I'm wondering if maybe we should just send the appropriate brightness
>> change, switch display, etc. event to u
On Thu, Aug 02, 2012 at 01:26:55PM +0200, Ortwin Glück wrote:
> I have managed to turn the crash into a WARN_ON, by adding this to the
> begin of nouveau_software_vblank():
>
> if (!psw) {
> WARN_ON(1);
> return;
> }
Yes, I know about it, but t
On Thu, Aug 2, 2012 at 12:33 PM, Alex Deucher wrote:
> On Thu, Aug 2, 2012 at 12:31 PM, Luca Tettamanti wrote:
>> On Thu, Aug 2, 2012 at 5:03 PM, Alex Deucher wrote:
>>> I admit I'm not really an ACPI expert, but thinking about this more,
>>> I'm wondering if maybe we should just send the approp
Hi Rémi,
On Thursday 02 August 2012 09:56:43 Rémi Denis-Courmont wrote:
> Le jeudi 2 août 2012 09:35:58 Hans Verkuil, vous avez écrit :
> > On Wed August 1 2012 22:49:57 Rémi Denis-Courmont wrote:
> > > > What about using the CREATE_BUFS ioctl to add new MMAP buffers at
> > > > runtime ?
> > >
>
Hi Hans,
On Thursday 02 August 2012 09:08:18 Hans Verkuil wrote:
> On Thu August 2 2012 08:56:43 Rémi Denis-Courmont wrote:
> > Le jeudi 2 août 2012 09:35:58 Hans Verkuil, vous avez écrit :
> > > On Wed August 1 2012 22:49:57 Rémi Denis-Courmont wrote:
> > > > > What about using the CREATE_BUFS io
https://bugs.freedesktop.org/show_bug.cgi?id=51787
--- Comment #2 from almos 2012-08-02 22:04:09 UTC ---
It might not help in fixing this, but I found that the framerate is much more
consistent if I load all cpu cores with something while playing ut2004.
Normally, the framerate counter is green,
https://bugs.freedesktop.org/show_bug.cgi?id=51787
--- Comment #3 from Andy Furniss 2012-08-02
22:32:43 UTC ---
(In reply to comment #2)
> It might not help in fixing this, but I found that the framerate is much more
> consistent if I load all cpu cores with something while playing ut2004.
> Nor
On 2012-08-01 03:06, Chris Wilson wrote:
On Wed, 01 Aug 2012 10:38:36 +0100, James Bottomley
wrote:
On Wed, 2012-08-01 at 09:58 +0100, Chris Wilson wrote:
> On Wed, 01 Aug 2012 09:45:04 +0100, James Bottomley
wrote:
> > On Wed, 2012-08-01 at 09:16 +0100, Chris Wilson wrote:
> > > On Wed, 01
On an AOpen i915GMm-hfs the hotplug events generated
by transitions between connector_status_unknown and
connector_status_disconnected cause screen distortions.
The attached patch cures the problem by disabling the
generation of hotplug events in those cases. That should
be safe for everybody as
Le jeudi 2 août 2012 09:35:58 Hans Verkuil, vous avez écrit :
> On Wed August 1 2012 22:49:57 Rémi Denis-Courmont wrote:
> > > What about using the CREATE_BUFS ioctl to add new MMAP buffers at
> > > runtime ?
> >
> > Does CREATE_BUFS always work while already streaming has already started?
> > If
On 07/04/2012 01:56 AM, Sascha Hauer wrote:
> This patch adds a helper function for parsing videomodes from the devicetree.
> The videomode can be either converted to a struct drm_display_mode or a
> struct fb_videomode.
> diff --git a/Documentation/devicetree/bindings/video/displaymode
> b/Docum
On 07/05/2012 08:51 AM, Rob Herring wrote:
> On 07/04/2012 02:56 AM, Sascha Hauer wrote:
>> This patch adds a helper function for parsing videomodes from the devicetree.
>> The videomode can be either converted to a struct drm_display_mode or a
>> struct fb_videomode.
>> diff --git a/Documentation
https://bugs.freedesktop.org/show_bug.cgi?id=45018
--- Comment #84 from Anthony Waters 2012-08-03 01:28:25
UTC ---
I randomly saw it when I was playing a game of Warcraft 3, the terrain textures
would blink. I'll check the piglit tests and mesa demos to see if I can
reproduce the issue with the
On Thu, Aug 2, 2012 at 9:40 PM, Zhang Rui wrote:
> On 四, 2012-08-02 at 15:46 +0200, Luca Tettamanti wrote:
>> On Thu, Aug 02, 2012 at 08:45:30AM +0800, Zhang Rui wrote:
>> > On 三, 2012-08-01 at 15:49 +0200, Luca Tettamanti wrote:
>> > > AMD ACPI interface may overload the standard event
>> > > ACP
https://bugs.freedesktop.org/show_bug.cgi?id=45018
--- Comment #85 from Anthony Waters 2012-08-03 02:07:06
UTC ---
I found a demo that has the issue, in the demos repository for mesa within the
src/demo folder the program 'reflect'. After I start it up and press 's' to
see the stencil buffer th
https://bugs.freedesktop.org/show_bug.cgi?id=45018
--- Comment #86 from Alexandre Demers 2012-08-03
03:00:00 UTC ---
(In reply to comment #85)
> I found a demo that has the issue, in the demos repository for mesa within the
> src/demo folder the program 'reflect'. After I start it up and press
https://bugs.freedesktop.org/show_bug.cgi?id=45018
--- Comment #80 from Anthony Waters 2012-08-02 00:41:23
UTC ---
I tried both patches, the one from comment 76 and the one from comment 70,
neither fixed the issue with the rendering regression or the va conflict.
--
Configure bugmail: https://
https://bugs.freedesktop.org/show_bug.cgi?id=45018
--- Comment #81 from Anthony Waters 2012-08-02 00:47:06
UTC ---
Created attachment 65051
--> https://bugs.freedesktop.org/attachment.cgi?id=65051
fixes to wait on the bo and to free the va after the kernel
These are the changes I made to make
https://bugs.freedesktop.org/show_bug.cgi?id=45018
--- Comment #82 from Alexandre Demers
2012-08-02 01:02:42 UTC ---
(In reply to comment #80)
> I tried both patches, the one from comment 76 and the one from comment 70,
> neither fixed the issue with the rendering regression or the va conflict.
https://bugs.freedesktop.org/show_bug.cgi?id=45018
--- Comment #83 from Jerome Glisse 2012-08-02
03:46:43 UTC ---
How do you trigger the va issue ? piglit ? I was not able to reproduce. It's
kind of painful to debug in the dark.
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?
On ?, 2012-08-01 at 15:49 +0200, Luca Tettamanti wrote:
> AMD ACPI interface may overload the standard event
> ACPI_VIDEO_NOTIFY_PROBE (0x81) to signal AMD-specific events. In such
> cases we don't want to send the keypress (KEY_SWITCHVIDEOMODE) to the
> userspace because the user did not press the
Hi, Lucas, sorry for so long a delay because I have a holiday for one month.
I found Loongson-3 must turn on SWIOTLB if the system memory has
addresses above 4G. As I know, there are two ways to get a DMA addr,
the first way is use dma_alloc_coherent(), and the other one is use
map_page()/map_sg()
On Wed August 1 2012 22:49:57 R?mi Denis-Courmont wrote:
> Le mercredi 1 ao?t 2012 14:35:03 Laurent Pinchart, vous avez ?crit :
> > > But in general, the V4L element in the pipeline does not know how fast
> > > the downstream element(s) will consume the buffers. Thus it has to copy
> > > from the M
On Thu August 2 2012 08:56:43 R?mi Denis-Courmont wrote:
> Le jeudi 2 ao?t 2012 09:35:58 Hans Verkuil, vous avez ?crit :
> > On Wed August 1 2012 22:49:57 R?mi Denis-Courmont wrote:
> > > > What about using the CREATE_BUFS ioctl to add new MMAP buffers at
> > > > runtime ?
> > >
> > > Does CREATE_
ttachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20120802/7f7e4611/attachment-0001.pgp>
On Wed, 2012-08-01 at 22:08 -0700, bwidawsk wrote:
> On 2012-08-01 03:06, Chris Wilson wrote:
> > On Wed, 01 Aug 2012 10:38:36 +0100, James Bottomley
> > wrote:
> >> On Wed, 2012-08-01 at 09:58 +0100, Chris Wilson wrote:
> >> > On Wed, 01 Aug 2012 09:45:04 +0100, James Bottomley
> >> wrote:
> >>
On 2012-08-02 00:20, James Bottomley wrote:
> On Wed, 2012-08-01 at 22:08 -0700, bwidawsk wrote:
>> On 2012-08-01 03:06, Chris Wilson wrote:
>> > On Wed, 01 Aug 2012 10:38:36 +0100, James Bottomley
>> > wrote:
>> >> On Wed, 2012-08-01 at 09:58 +0100, Chris Wilson wrote:
>> >> > On Wed, 01 Aug 2012
On Thu, Aug 2, 2012 at 2:13 AM, Tomi Valkeinen wrote:
> On Wed, 2012-08-01 at 09:25 -0500, Rob Clark wrote:
>> On Wed, Aug 1, 2012 at 4:21 AM, Tomi Valkeinen
>> wrote:
>
>> > I guess the fact is that DRM concepts do not really match the OMAP DSS
>> > hardware, and we'll have to use whatever give
her (we didn't have it in
earlier versions of omapdss), but I still don't see an option to it if
we want to support all the stuff we have.
Tomi
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20120802/ca1d188c/attachment.pgp>
On Thu, Aug 02, 2012 at 08:45:30AM +0800, Zhang Rui wrote:
> On ?, 2012-08-01 at 15:49 +0200, Luca Tettamanti wrote:
> > AMD ACPI interface may overload the standard event
> > ACPI_VIDEO_NOTIFY_PROBE (0x81) to signal AMD-specific events. In such
> > cases we don't want to send the keypress (KEY_SWI
On Thu, Aug 2, 2012 at 8:15 AM, Tomi Valkeinen wrote:
> On Thu, 2012-08-02 at 07:45 -0500, Rob Clark wrote:
>> On Thu, Aug 2, 2012 at 2:13 AM, Tomi Valkeinen
>> wrote:
>> > On Wed, 2012-08-01 at 09:25 -0500, Rob Clark wrote:
>> >> On Wed, Aug 1, 2012 at 4:21 AM, Tomi Valkeinen
>> >> wrote:
>>
I admit I'm not really an ACPI expert, but thinking about this more,
I'm wondering if maybe we should just send the appropriate brightness
change, switch display, etc. event to userspace rather than handling
it directly in the radeon driver, then let userspace callback down via
the bl interface, et
From: Jerome Glisse
Lock/unlock mutex in proper order to avoid deadlock in case
of GPU reset triggered from VM code path.
Cc: stable at vger.kernel.org [3.5]
Signed-off-by: Jerome Glisse
---
drivers/gpu/drm/radeon/radeon_gart.c | 11 +--
1 file changed, 9 insertions(+), 2 deletions(-
On Thu, Aug 2, 2012 at 12:05 PM, wrote:
> From: Jerome Glisse
>
> Lock/unlock mutex in proper order to avoid deadlock in case
> of GPU reset triggered from VM code path.
>
> Cc: stable at vger.kernel.org [3.5]
> Signed-off-by: Jerome Glisse
Reviewed-by: Alex Deucher
> ---
> drivers/gpu/drm/
Hi Laurent, Hi Dima,
On 06/27/2012 10:40 PM, Laurent Pinchart wrote:
> Hi Dima,
>
> On Tuesday 26 June 2012 13:53:34 Dima Zavin wrote:
>> On Tue, Jun 26, 2012 at 2:40 AM, Hans Verkuil wrote:
>>> On Tue 26 June 2012 11:11:06 Laurent Pinchart wrote:
On Tuesday 26 June 2012 10:40:44 Tomasz Sta
On Thu, Aug 2, 2012 at 5:03 PM, Alex Deucher wrote:
> I admit I'm not really an ACPI expert, but thinking about this more,
> I'm wondering if maybe we should just send the appropriate brightness
> change, switch display, etc. event to userspace rather than handling
> it directly in the radeon driv
On Thu, Aug 2, 2012 at 12:31 PM, Luca Tettamanti wrote:
> On Thu, Aug 2, 2012 at 5:03 PM, Alex Deucher wrote:
>> I admit I'm not really an ACPI expert, but thinking about this more,
>> I'm wondering if maybe we should just send the appropriate brightness
>> change, switch display, etc. event to u
On Thu, Aug 02, 2012 at 01:26:55PM +0200, Ortwin Gl?ck wrote:
> I have managed to turn the crash into a WARN_ON, by adding this to the
> begin of nouveau_software_vblank():
>
> if (!psw) {
> WARN_ON(1);
> return;
> }
Yes, I know about it, but t
On Thu, Aug 2, 2012 at 12:33 PM, Alex Deucher wrote:
> On Thu, Aug 2, 2012 at 12:31 PM, Luca Tettamanti
> wrote:
>> On Thu, Aug 2, 2012 at 5:03 PM, Alex Deucher
>> wrote:
>>> I admit I'm not really an ACPI expert, but thinking about this more,
>>> I'm wondering if maybe we should just send the
Hi R?mi,
On Thursday 02 August 2012 09:56:43 R?mi Denis-Courmont wrote:
> Le jeudi 2 ao?t 2012 09:35:58 Hans Verkuil, vous avez ?crit :
> > On Wed August 1 2012 22:49:57 R?mi Denis-Courmont wrote:
> > > > What about using the CREATE_BUFS ioctl to add new MMAP buffers at
> > > > runtime ?
> > >
>
Hi Hans,
On Thursday 02 August 2012 09:08:18 Hans Verkuil wrote:
> On Thu August 2 2012 08:56:43 R?mi Denis-Courmont wrote:
> > Le jeudi 2 ao?t 2012 09:35:58 Hans Verkuil, vous avez ?crit :
> > > On Wed August 1 2012 22:49:57 R?mi Denis-Courmont wrote:
> > > > > What about using the CREATE_BUFS io
https://bugs.freedesktop.org/show_bug.cgi?id=51787
--- Comment #2 from almos 2012-08-02 22:04:09 UTC ---
It might not help in fixing this, but I found that the framerate is much more
consistent if I load all cpu cores with something while playing ut2004.
Normally, the framerate counter is green,
https://bugs.freedesktop.org/show_bug.cgi?id=51787
--- Comment #3 from Andy Furniss 2012-08-02
22:32:43 UTC ---
(In reply to comment #2)
> It might not help in fixing this, but I found that the framerate is much more
> consistent if I load all cpu cores with something while playing ut2004.
> Nor
Le jeudi 2 ao?t 2012 09:35:58 Hans Verkuil, vous avez ?crit :
> On Wed August 1 2012 22:49:57 R?mi Denis-Courmont wrote:
> > > What about using the CREATE_BUFS ioctl to add new MMAP buffers at
> > > runtime ?
> >
> > Does CREATE_BUFS always work while already streaming has already started?
> > If
ttp://lists.freedesktop.org/archives/dri-devel/attachments/20120802/eb35539b/attachment-0001.bin>
I have managed to turn the crash into a WARN_ON, by adding this to the
begin of nouveau_software_vblank():
if (!psw) {
WARN_ON(1);
return;
}
And I have also managed to load the module manually instead by udev. So
I am happy to attach a full lo
On 07/04/2012 01:56 AM, Sascha Hauer wrote:
> This patch adds a helper function for parsing videomodes from the devicetree.
> The videomode can be either converted to a struct drm_display_mode or a
> struct fb_videomode.
> diff --git a/Documentation/devicetree/bindings/video/displaymode
> b/Docum
On 07/05/2012 08:51 AM, Rob Herring wrote:
> On 07/04/2012 02:56 AM, Sascha Hauer wrote:
>> This patch adds a helper function for parsing videomodes from the devicetree.
>> The videomode can be either converted to a struct drm_display_mode or a
>> struct fb_videomode.
>> diff --git a/Documentation
On Thu, Aug 2, 2012 at 9:40 PM, Zhang Rui wrote:
> On ?, 2012-08-02 at 15:46 +0200, Luca Tettamanti wrote:
>> On Thu, Aug 02, 2012 at 08:45:30AM +0800, Zhang Rui wrote:
>> > On ?, 2012-08-01 at 15:49 +0200, Luca Tettamanti wrote:
>> > > AMD ACPI interface may overload the standard event
>> > > ACP
64 matches
Mail list logo
