Hi Rob,
(CC'ing linux-media, as I believe this is very on-topic)
On Sunday 18 September 2011 18:14:26 Rob Clark wrote:
> On Sat, Sep 17, 2011 at 6:12 PM, Laurent Pinchart wrote:
> > On Thursday 15 September 2011 20:39:21 Florian Tobias Schandinat wrote:
> >> On 09/15/2011 05:52 PM, Alex Deucher w
On Mon, 19 Sep 2011 09:33:34 +0300, Tomi Valkeinen
wrote:
> I think it's a bit more complex than that. True, there are MIPI
> standards, for the video there are DPI, DBI, DSI, and for the commands
> there is DCS. And, as you mentioned, many panels need custom
> initialization, or support only pa
was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20110918/4bde2b56/attachment.pgp>
On Sun, Sep 18, 2011 at 5:23 PM, Alan Cox wrote:
>> This would leave us with the issue of controlling formats and other
>> parameters
>> on the pipelines. We could keep separate DRM, KMS, FB and V4L APIs for that,
>
> There are some other differences that matter. The exact state and
> behaviour o
On Tue, 13 Sep 2011 10:12:47 -0400
Konrad Rzeszutek Wilk wrote:
> As a mechanism to detect whether SWIOTLB is enabled or not.
> And as such, we might as well wrap it within an 'swiotlb_enabled()'
> function that will call the swiotlb_nr_tlb.
>
> We also fix the spelling - it was swioltb instead
Samuel Thibault, le Fri 16 Sep 2011 18:30:50 +0200, a écrit :
> Keith Packard, le Thu 15 Sep 2011 09:22:48 -0500, a écrit :
> > On Thu, 15 Sep 2011 10:12:59 +0200, Samuel Thibault
> > wrote:
> >
> > > At home only. At work, with a different VGA screen, I'm still getting
> > > the issue.
> >
> >
On Fri, 2011-09-16 at 17:53 +0100, Alan Cox wrote:
> > I'm not sure a common interface to all of these different
> > channels makes sense, but surely a DSI library and an aux channel
> > library would fit nicely alongside the existing DDC library.
>
> DSI and the various other MIPI bits tend to be
> This would leave us with the issue of controlling formats and other
> parameters
> on the pipelines. We could keep separate DRM, KMS, FB and V4L APIs for that,
There are some other differences that matter. The exact state and
behaviour of memory, sequencing of accesses, cache control and mana
On 09/18/2011 10:15 PM, Rob Clark wrote:
> On Sun, Sep 18, 2011 at 3:00 PM, Thomas Hellstrom
> wrote:
>
>> On 09/18/2011 09:50 PM, Rob Clark wrote:
>>
>>> On Sun, Sep 18, 2011 at 2:36 PM, Thomas Hellstrom
>>> wrote:
>>>
>>>
On 09/17/2011 11:32 PM, Rob Clark wrote:
>>
On 09/18/2011 09:50 PM, Rob Clark wrote:
> On Sun, Sep 18, 2011 at 2:36 PM, Thomas Hellstrom
> wrote:
>
>> On 09/17/2011 11:32 PM, Rob Clark wrote:
>>
>>> From: Rob Clark
>>>
>>> A DRM display driver for TI OMAP platform. Similar to omapfb (fbdev)
>>> and omap_vout (v4l2 display) drive
On 09/17/2011 11:32 PM, Rob Clark wrote:
> From: Rob Clark
>
> A DRM display driver for TI OMAP platform. Similar to omapfb (fbdev)
> and omap_vout (v4l2 display) drivers in the past, this driver uses the
> DSS2 driver to access the display hardware, including support for
> HDMI, DVI, and various
On Sun, Sep 18, 2011 at 5:23 PM, Alan Cox wrote:
>> This would leave us with the issue of controlling formats and other
>> parameters
>> on the pipelines. We could keep separate DRM, KMS, FB and V4L APIs for that,
>
> There are some other differences that matter. The exact state and
> behaviour o
https://bugs.freedesktop.org/show_bug.cgi?id=36554
--- Comment #7 from Tom Stellard 2011-09-18 18:27:04 PDT
---
Is this still a problem with the latest code from git. If it is, can you post
your glxinfo and kernel version?
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=e
https://bugs.freedesktop.org/show_bug.cgi?id=36554
--- Comment #7 from Tom Stellard 2011-09-18 18:27:04
PDT ---
Is this still a problem with the latest code from git. If it is, can you post
your glxinfo and kernel version?
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=e
I need to nak this in its current form.
The TTM design without timeout is intentional.
The fencing system (or the sync objects) is what should control the
progress of the GPU and if it detects a hang, all fences should be
signaled and the gpu should be reset if possible. Error propagation
could
https://bugs.freedesktop.org/show_bug.cgi?id=35861
--- Comment #2 from Tom Stellard 2011-09-18 18:21:44 PDT
---
Is this still an issue with the latest version from git, and if so can you post
the output of RADEON_DEBUG=vp ?
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=e
https://bugs.freedesktop.org/show_bug.cgi?id=35861
--- Comment #2 from Tom Stellard 2011-09-18 18:21:44
PDT ---
Is this still an issue with the latest version from git, and if so can you post
the output of RADEON_DEBUG=vp ?
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=e
https://bugs.freedesktop.org/show_bug.cgi?id=29951
--- Comment #6 from Tom Stellard 2011-09-18 18:18:07 PDT
---
(In reply to comment #5)
> (In reply to comment #4)
> > Is this issue still present with the current Mesa master branch?
>
> Unfortunately, yes. Although it does seem to happen a lot
https://bugs.freedesktop.org/show_bug.cgi?id=29951
--- Comment #6 from Tom Stellard 2011-09-18 18:18:07
PDT ---
(In reply to comment #5)
> (In reply to comment #4)
> > Is this issue still present with the current Mesa master branch?
>
> Unfortunately, yes. Although it does seem to happen a lot
https://bugs.freedesktop.org/show_bug.cgi?id=40062
Tom Stellard changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
https://bugs.freedesktop.org/show_bug.cgi?id=40062
Tom Stellard changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
https://bugs.freedesktop.org/show_bug.cgi?id=36939
Tom Stellard changed:
What|Removed |Added
Status|REOPENED|RESOLVED
Resolution|
https://bugs.freedesktop.org/show_bug.cgi?id=36939
Tom Stellard changed:
What|Removed |Added
Status|REOPENED|RESOLVED
Resolution|
On Sun, Sep 18, 2011 at 10:31:45AM -0500, Rob Clark wrote:
> On Sun, Sep 18, 2011 at 5:23 AM, Daniel Vetter wrote:
> > On Sat, Sep 17, 2011 at 04:32:09PM -0500, Rob Clark wrote:
> On Sun, Sep 18, 2011 at 5:23 AM, Daniel Vetter wrote:
> >> +struct drm_omap_gem_cpu_fini {
> >> + uint32_t handle
On Sun, Sep 18, 2011 at 04:30:04PM +0200, Marcin Slusarz wrote:
> On Sun, Sep 18, 2011 at 03:59:50PM +0200, Daniel Vetter wrote:
> > On Sun, Sep 18, 2011 at 03:18:57PM +0200, Marcin Slusarz wrote:
> > > Currently DRM_NOUVEAU_GEM_CPU_PREP ioctl is broken WRT handling of
> > > signals.
> > >
> > >
On Sun, Sep 18, 2011 at 03:59:50PM +0200, Daniel Vetter wrote:
> On Sun, Sep 18, 2011 at 03:18:57PM +0200, Marcin Slusarz wrote:
> > Currently DRM_NOUVEAU_GEM_CPU_PREP ioctl is broken WRT handling of signals.
> >
> > nouveau_gem_ioctl_cpu_prep calls ttm_bo_wait which waits for fence to
> > "signal
On Sun, Sep 18, 2011 at 3:31 PM, Thomas Hellstrom
wrote:
> On 09/18/2011 10:15 PM, Rob Clark wrote:
>>
>> On Sun, Sep 18, 2011 at 3:00 PM, Thomas Hellstrom
>> ?wrote:
>>
>>>
>>> On 09/18/2011 09:50 PM, Rob Clark wrote:
>>>
On Sun, Sep 18, 2011 at 2:36 PM, Thomas Hellstrom
?wrote:
>
On Sun, Sep 18, 2011 at 03:18:57PM +0200, Marcin Slusarz wrote:
> Currently DRM_NOUVEAU_GEM_CPU_PREP ioctl is broken WRT handling of signals.
>
> nouveau_gem_ioctl_cpu_prep calls ttm_bo_wait which waits for fence to
> "signal" or 3 seconds timeout pass.
> But if it detects pending signal, it retur
> This would leave us with the issue of controlling formats and other
> parameters
> on the pipelines. We could keep separate DRM, KMS, FB and V4L APIs for that,
There are some other differences that matter. The exact state and
behaviour of memory, sequencing of accesses, cache control and mana
New ioctl is used internally by nouveau_bo_wait to properly handle
timeouts with signals.
---
include/drm/nouveau_drm.h | 33 ++
nouveau/nouveau_bo.c | 66 ++---
2 files changed, 77 insertions(+), 22 deletions(-)
diff --git a/in
Currently DRM_NOUVEAU_GEM_CPU_PREP ioctl is broken WRT handling of signals.
nouveau_gem_ioctl_cpu_prep calls ttm_bo_wait which waits for fence to
"signal" or 3 seconds timeout pass.
But if it detects pending signal, it returns ERESTARTSYS and goes back
to userspace. After signal handler, userspace
On Sun, Sep 18, 2011 at 3:00 PM, Thomas Hellstrom
wrote:
> On 09/18/2011 09:50 PM, Rob Clark wrote:
>>
>> On Sun, Sep 18, 2011 at 2:36 PM, Thomas Hellstrom
>> ?wrote:
>>
>>>
>>> On 09/17/2011 11:32 PM, Rob Clark wrote:
>>>
From: Rob Clark
A DRM display driver for TI OMAP platf
Hi Rob,
(CC'ing linux-media, as I believe this is very on-topic)
On Sunday 18 September 2011 18:14:26 Rob Clark wrote:
> On Sat, Sep 17, 2011 at 6:12 PM, Laurent Pinchart wrote:
> > On Thursday 15 September 2011 20:39:21 Florian Tobias Schandinat wrote:
> >> On 09/15/2011 05:52 PM, Alex Deucher w
On Sun, Sep 18, 2011 at 2:36 PM, Thomas Hellstrom
wrote:
> On 09/17/2011 11:32 PM, Rob Clark wrote:
>>
>> From: Rob Clark
>>
>> A DRM display driver for TI OMAP platform. ?Similar to omapfb (fbdev)
>> and omap_vout (v4l2 display) drivers in the past, this driver uses the
>> DSS2 driver to access
From: Rob Clark
If an older userspace passes in a smaller arg than the current kernel
ioctl arg struct, then extra fields should be initialized to zero
rather than passing random data to the DRM driver.
Signed-off-by: Rob Clark
---
A potential issue that Daniel Vetter spotted. It isn't current
On Sun, Sep 18, 2011 at 3:31 PM, Thomas Hellstrom wrote:
> On 09/18/2011 10:15 PM, Rob Clark wrote:
>>
>> On Sun, Sep 18, 2011 at 3:00 PM, Thomas Hellstrom
>> wrote:
>>
>>>
>>> On 09/18/2011 09:50 PM, Rob Clark wrote:
>>>
On Sun, Sep 18, 2011 at 2:36 PM, Thomas Hellstrom
wrote:
>>
On Sun, Sep 18, 2011 at 10:55 AM, Daniel Vetter wrote:
> There's the little funny caveat though that if userspace passes in less
> data than the kernel expects, it's not being cleared. But that can be
> fixed.
oh, heh, good catch.. I'll send a patch for that shortly, before I
forget and spend a b
On 09/18/2011 10:15 PM, Rob Clark wrote:
On Sun, Sep 18, 2011 at 3:00 PM, Thomas Hellstrom wrote:
On 09/18/2011 09:50 PM, Rob Clark wrote:
On Sun, Sep 18, 2011 at 2:36 PM, Thomas Hellstrom
wrote:
On 09/17/2011 11:32 PM, Rob Clark wrote:
From: Rob Clark
A DRM
On Sun, Sep 18, 2011 at 3:00 PM, Thomas Hellstrom wrote:
> On 09/18/2011 09:50 PM, Rob Clark wrote:
>>
>> On Sun, Sep 18, 2011 at 2:36 PM, Thomas Hellstrom
>> wrote:
>>
>>>
>>> On 09/17/2011 11:32 PM, Rob Clark wrote:
>>>
From: Rob Clark
A DRM display driver for TI OMAP platfo
On 09/18/2011 09:50 PM, Rob Clark wrote:
On Sun, Sep 18, 2011 at 2:36 PM, Thomas Hellstrom wrote:
On 09/17/2011 11:32 PM, Rob Clark wrote:
From: Rob Clark
A DRM display driver for TI OMAP platform. Similar to omapfb (fbdev)
and omap_vout (v4l2 display) drivers in the past, this dri
On Sun, Sep 18, 2011 at 2:36 PM, Thomas Hellstrom wrote:
> On 09/17/2011 11:32 PM, Rob Clark wrote:
>>
>> From: Rob Clark
>>
>> A DRM display driver for TI OMAP platform. Similar to omapfb (fbdev)
>> and omap_vout (v4l2 display) drivers in the past, this driver uses the
>> DSS2 driver to access t
On 09/17/2011 11:32 PM, Rob Clark wrote:
From: Rob Clark
A DRM display driver for TI OMAP platform. Similar to omapfb (fbdev)
and omap_vout (v4l2 display) drivers in the past, this driver uses the
DSS2 driver to access the display hardware, including support for
HDMI, DVI, and various types of
From: Rob Clark
If an older userspace passes in a smaller arg than the current kernel
ioctl arg struct, then extra fields should be initialized to zero
rather than passing random data to the DRM driver.
Signed-off-by: Rob Clark
---
A potential issue that Daniel Vetter spotted. It isn't current
On Sat, Sep 17, 2011 at 04:32:09PM -0500, Rob Clark wrote:
> From: Rob Clark
>
> A DRM display driver for TI OMAP platform. Similar to omapfb (fbdev)
> and omap_vout (v4l2 display) drivers in the past, this driver uses the
> DSS2 driver to access the display hardware, including support for
> HDM
On Sun, Sep 18, 2011 at 10:55 AM, Daniel Vetter wrote:
> There's the little funny caveat though that if userspace passes in less
> data than the kernel expects, it's not being cleared. But that can be
> fixed.
oh, heh, good catch.. I'll send a patch for that shortly, before I
forget and spend a b
On Sat, Sep 17, 2011 at 6:12 PM, Laurent Pinchart
wrote:
> Hi everybody,
>
> On Thursday 15 September 2011 20:39:21 Florian Tobias Schandinat wrote:
>> On 09/15/2011 05:52 PM, Alex Deucher wrote:
>> >
>> > Please don't claim that the DRM developers do not want to cooperate.
>> > I realize that peo
On Sun, Sep 18, 2011 at 5:23 AM, Daniel Vetter wrote:
> On Sat, Sep 17, 2011 at 04:32:09PM -0500, Rob Clark wrote:
>> From: Rob Clark
>>
>> A DRM display driver for TI OMAP platform. ?Similar to omapfb (fbdev)
>> and omap_vout (v4l2 display) drivers in the past, this driver uses the
>> DSS2 drive
I need to nak this in its current form.
The TTM design without timeout is intentional.
The fencing system (or the sync objects) is what should control the
progress of the GPU and if it detects a hang, all fences should be
signaled and the gpu should be reset if possible. Error propagation
coul
On Sat, Sep 17, 2011 at 6:12 PM, Laurent Pinchart
wrote:
> Hi everybody,
>
> On Thursday 15 September 2011 20:39:21 Florian Tobias Schandinat wrote:
>> On 09/15/2011 05:52 PM, Alex Deucher wrote:
>> >
>> > Please don't claim that the DRM developers do not want to cooperate.
>> > I realize that peo
On Sun, Sep 18, 2011 at 10:31:45AM -0500, Rob Clark wrote:
> On Sun, Sep 18, 2011 at 5:23 AM, Daniel Vetter wrote:
> > On Sat, Sep 17, 2011 at 04:32:09PM -0500, Rob Clark wrote:
> On Sun, Sep 18, 2011 at 5:23 AM, Daniel Vetter wrote:
> >> +struct drm_omap_gem_cpu_fini {
> >> + uint32_t handle
On Sun, Sep 18, 2011 at 5:23 AM, Daniel Vetter wrote:
> On Sat, Sep 17, 2011 at 04:32:09PM -0500, Rob Clark wrote:
>> From: Rob Clark
>>
>> A DRM display driver for TI OMAP platform. Similar to omapfb (fbdev)
>> and omap_vout (v4l2 display) drivers in the past, this driver uses the
>> DSS2 drive
On Sun, Sep 18, 2011 at 04:30:04PM +0200, Marcin Slusarz wrote:
> On Sun, Sep 18, 2011 at 03:59:50PM +0200, Daniel Vetter wrote:
> > On Sun, Sep 18, 2011 at 03:18:57PM +0200, Marcin Slusarz wrote:
> > > Currently DRM_NOUVEAU_GEM_CPU_PREP ioctl is broken WRT handling of
> > > signals.
> > >
> > >
On Sun, Sep 18, 2011 at 03:59:50PM +0200, Daniel Vetter wrote:
> On Sun, Sep 18, 2011 at 03:18:57PM +0200, Marcin Slusarz wrote:
> > Currently DRM_NOUVEAU_GEM_CPU_PREP ioctl is broken WRT handling of signals.
> >
> > nouveau_gem_ioctl_cpu_prep calls ttm_bo_wait which waits for fence to
> > "signal
On Sun, Sep 18, 2011 at 03:18:57PM +0200, Marcin Slusarz wrote:
> Currently DRM_NOUVEAU_GEM_CPU_PREP ioctl is broken WRT handling of signals.
>
> nouveau_gem_ioctl_cpu_prep calls ttm_bo_wait which waits for fence to
> "signal" or 3 seconds timeout pass.
> But if it detects pending signal, it retur
New ioctl is used internally by nouveau_bo_wait to properly handle
timeouts with signals.
---
include/drm/nouveau_drm.h | 33 ++
nouveau/nouveau_bo.c | 66 ++---
2 files changed, 77 insertions(+), 22 deletions(-)
diff --git a/in
Currently DRM_NOUVEAU_GEM_CPU_PREP ioctl is broken WRT handling of signals.
nouveau_gem_ioctl_cpu_prep calls ttm_bo_wait which waits for fence to
"signal" or 3 seconds timeout pass.
But if it detects pending signal, it returns ERESTARTSYS and goes back
to userspace. After signal handler, userspace
https://bugs.freedesktop.org/show_bug.cgi?id=38488
--- Comment #12 from Harald Judt 2011-09-18 06:02:30 PDT ---
I'm still using 3.1-rc2, but this issue seems solved after applying some
patches I grabbed from the DRI mailing list, though I don't know exactly which
one(s).
So everything looks fine
https://bugs.freedesktop.org/show_bug.cgi?id=38488
--- Comment #12 from Harald Judt 2011-09-18 06:02:30 PDT ---
I'm still using 3.1-rc2, but this issue seems solved after applying some
patches I grabbed from the DRI mailing list, though I don't know exactly which
one(s).
So everything looks fine
https://bugs.freedesktop.org/show_bug.cgi?id=40986
Summary: xorg-r600: graphical glitches on cursor display
Product: Mesa
Version: git
Platform: x86-64 (AMD64)
OS/Version: Linux (All)
Status: NEW
Severity: normal
Pr
https://bugs.freedesktop.org/show_bug.cgi?id=40986
Summary: xorg-r600: graphical glitches on cursor display
Product: Mesa
Version: git
Platform: x86-64 (AMD64)
OS/Version: Linux (All)
Status: NEW
Severity: normal
Pr
On Sat, Sep 17, 2011 at 04:32:09PM -0500, Rob Clark wrote:
> From: Rob Clark
>
> A DRM display driver for TI OMAP platform. Similar to omapfb (fbdev)
> and omap_vout (v4l2 display) drivers in the past, this driver uses the
> DSS2 driver to access the display hardware, including support for
> HDM
https://bugs.freedesktop.org/show_bug.cgi?id=40062
--- Comment #8 from almos 2011-09-18 01:52:26 PDT ---
The patch fixed this one and #36939. Thanks.
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assig
https://bugs.freedesktop.org/show_bug.cgi?id=40062
--- Comment #8 from almos 2011-09-18 01:52:26 PDT ---
The patch fixed this one and #36939. Thanks.
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assig
Hi everybody,
On Thursday 15 September 2011 20:39:21 Florian Tobias Schandinat wrote:
> On 09/15/2011 05:52 PM, Alex Deucher wrote:
> >
> > Please don't claim that the DRM developers do not want to cooperate.
> > I realize that people have strong opinions about existing APIs, put
> > there has bee
64 matches
Mail list logo
