On Sat, Sep 17, 2011 at 4:17 PM, Eugeni Dodonov wrote:
> On Thu, Sep 15, 2011 at 22:37, Keith Packard wrote:
>>
>> I've got this nice patch from Akshay Joshi that removes almost all of
>> the checkpatch.pl warnings from drm/i915. If I don't merge it now, it's
>> going to go stale and be useless;
Hi,
Am Donnerstag, 15. September 2011, 14:07:05 schrieb Tomi Valkeinen:
> Now, I'm quite sure the above framework could work quite well with any
> OMAP like hardware, with unified memory (i.e. the video buffers are in
> SDRAM) and 3D chips and similar components are separate. But what I'm
> not su
Hello,
On Wednesday, September 14, 2011 11:53 PM Rob Clark wrote:
> On Wed, Sep 14, 2011 at 2:57 AM, Thomas Hellstrom wrote:
(snipped)
> > Yes, that is true. A root client may be assumed to have AUTH permissions,
> > but the inverse does not hold, meaning that an AUTH client may *not* be
> > a
Whilst working on my failing Radeon GPU:
Subject: Re: Curious experiences with a Radeon on the fritz
Date: Wed, 21 Sep 2011 18:52:19 -
Message-ID:
http://lists.freedesktop.org/archives/dri-devel/2011-September/014506.html
I made the following trivial improvements to the DRM/Radeon co
Date: Wed, 21 Sep 2011 02:10:43 +
Signed-off-by: Michael Witten
---
drivers/gpu/drm/radeon/radeon_combios.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_combios.c
b/drivers/gpu/drm/radeon/radeon_combios.c
index 6367524..b0549aa 1006
Date: Thu, 15 Sep 2011 14:43:00 +
Signed-off-by: Michael Witten
---
drivers/gpu/drm/drm_proc.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/gpu/drm/drm_proc.c b/drivers/gpu/drm/drm_proc.c
index 9e5b07e..13df242 100644
--- a/drivers/gpu/drm/drm_proc.c
+++
Date: Fri, 16 Sep 2011 20:09:22 +
Signed-off-by: Michael Witten
---
drivers/gpu/drm/radeon/radeon_bios.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_bios.c
b/drivers/gpu/drm/radeon/radeon_bios.c
index 229a20f..af62082 100644
--- a/
Date: Fri, 16 Sep 2011 20:45:30 +
The value of RADEON_DEBUGFS_MAX_NUM_FILES has been used to
specify the size of an array, each element of which looks
like this:
struct radeon_debugfs {
struct drm_info_list*files;
unsignednum_files;
};
Consequently
Date: Thu, 15 Sep 2011 21:12:19 +
Signed-off-by: Michael Witten
---
drivers/gpu/drm/drm_fb_helper.c |3 ---
1 files changed, 0 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
index f7c6854..9a9107a 100644
--- a/drivers/gpu/drm
Date: Thu, 15 Sep 2011 21:07:26 +
Signed-off-by: Michael Witten
---
drivers/gpu/drm/drm_irq.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/drm_irq.c b/drivers/gpu/drm/drm_irq.c
index 3830e9e..61cb85d 100644
--- a/drivers/gpu/drm/drm_irq.c
+++ b/
Date: Thu, 15 Sep 2011 21:06:24 +
Signed-off-by: Michael Witten
---
drivers/gpu/drm/drm_crtc_helper.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/gpu/drm/drm_crtc_helper.c
b/drivers/gpu/drm/drm_crtc_helper.c
index f88a9b2..8ec3447 100644
--- a/drivers/g
On Wed, Sep 21, 2011 at 8:01 AM, Tomi Valkeinen wrote:
> I don't know what MCS is.
MCS is manufacturer specific commands (Manufacturer Command Set).
> But DSI is just a bi-directional transfer
> protocol between the SoC and the peripheral, you can send arbitrary data
> over it.
>
> Normally the S
Hello, Konrad Rzeszutek Wilk.
> -Original Message-
> From: Konrad Rzeszutek Wilk [mailto:konrad.w...@oracle.com]
> Sent: Thursday, September 22, 2011 3:53 AM
> To: Inki Dae
> Cc: airl...@linux.ie; dri-devel@lists.freedesktop.org;
> sw0312@samsung.com; kyungmin.p...@samsung.com; linux-a
On Mon, 12 Sep 2011 18:13:46 -, Michael Witten wrote:
> I hope you find this adventure interesting, and I hope you
> provide me with some insight.
>
> Recently, I booted my computer, a Dell Latitude D810 that has a
> Radeon Mobility x600 (R300); all systems were waking up as normal:
>
> * Th
So I did a cursory look and stopped at omap_drv.h
due to the lack of time.
Some comments below.
> +++ b/drivers/staging/omapdrm/Kconfig
> @@ -0,0 +1,24 @@
> +
> +config DRM_OMAP
> + tristate "OMAP DRM (EXPERIMENTAL)"
> + depends on DRM && !CONFIG_FB_OMAP2
Since it says EXPERIMENTAL shoul
On Sat, Sep 17, 2011 at 4:17 PM, Eugeni Dodonov wrote:
> On Thu, Sep 15, 2011 at 22:37, Keith Packard wrote:
>>
>> I've got this nice patch from Akshay Joshi that removes almost all of
>> the checkpatch.pl warnings from drm/i915. If I don't merge it now, it's
>> going to go stale and be useless;
Date: Wed, 21 Sep 2011 02:10:43 +
Signed-off-by: Michael Witten
---
drivers/gpu/drm/radeon/radeon_combios.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_combios.c
b/drivers/gpu/drm/radeon/radeon_combios.c
index 6367524..b0549aa 1006
Date: Fri, 16 Sep 2011 20:45:30 +
The value of RADEON_DEBUGFS_MAX_NUM_FILES has been used to
specify the size of an array, each element of which looks
like this:
struct radeon_debugfs {
struct drm_info_list*files;
unsignednum_files;
};
Consequently
Date: Fri, 16 Sep 2011 20:09:22 +
Signed-off-by: Michael Witten
---
drivers/gpu/drm/radeon/radeon_bios.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_bios.c
b/drivers/gpu/drm/radeon/radeon_bios.c
index 229a20f..af62082 100644
--- a/
Date: Thu, 15 Sep 2011 14:43:00 +
Signed-off-by: Michael Witten
---
drivers/gpu/drm/drm_proc.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/gpu/drm/drm_proc.c b/drivers/gpu/drm/drm_proc.c
index 9e5b07e..13df242 100644
--- a/drivers/gpu/drm/drm_proc.c
+++
Date: Thu, 15 Sep 2011 21:12:19 +
Signed-off-by: Michael Witten
---
drivers/gpu/drm/drm_fb_helper.c |3 ---
1 files changed, 0 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
index f7c6854..9a9107a 100644
--- a/drivers/gpu/drm
Date: Thu, 15 Sep 2011 21:07:26 +
Signed-off-by: Michael Witten
---
drivers/gpu/drm/drm_irq.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/drm_irq.c b/drivers/gpu/drm/drm_irq.c
index 3830e9e..61cb85d 100644
--- a/drivers/gpu/drm/drm_irq.c
+++ b/
Date: Thu, 15 Sep 2011 21:06:24 +
Signed-off-by: Michael Witten
---
drivers/gpu/drm/drm_crtc_helper.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/gpu/drm/drm_crtc_helper.c
b/drivers/gpu/drm/drm_crtc_helper.c
index f88a9b2..8ec3447 100644
--- a/drivers/g
Whilst working on my failing Radeon GPU:
Subject: Re: Curious experiences with a Radeon on the fritz
Date: Wed, 21 Sep 2011 18:52:19 -
Message-ID:
http://lists.freedesktop.org/archives/dri-devel/2011-September/014506.html
I made the following trivial improvements to the DRM/Radeon co
Hi,
Am Donnerstag, 15. September 2011, 14:07:05 schrieb Tomi Valkeinen:
> Now, I'm quite sure the above framework could work quite well with any
> OMAP like hardware, with unified memory (i.e. the video buffers are in
> SDRAM) and 3D chips and similar components are separate. But what I'm
> not su
On Wed, 21 Sep 2011 16:56:12 -0400, Akshay Joshi wrote:
> Have we reached a consensus on this? Just curious.
Your patch was merged to Dave Airlie's drm-core-next branch.
--
keith.pack...@intel.com
pgpDbfVeNrjh4.pgp
Description: PGP signature
___
dr
ame: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20110921/c4917ca0/attachment.pgp>
> > > > > + DRM_ERROR("desired size is bigger then real
> size.\n");
> > > >
> > > > So .. you can't continue by just using the real size instead?
> > > >
> > >
> > > I am afraid I don't understand what you mean but I think that condition
> > is
> > > fine. size is a vm area to user-des
Hello,
On Wednesday, September 14, 2011 11:53 PM Rob Clark wrote:
> On Wed, Sep 14, 2011 at 2:57 AM, Thomas Hellstrom
> wrote:
(snipped)
> > Yes, that is true. A root client may be assumed to have AUTH permissions,
> > but the inverse does not hold, meaning that an AUTH client may *not* be
>
On Mon, 12 Sep 2011 18:13:46 -, Michael Witten wrote:
> I hope you find this adventure interesting, and I hope you
> provide me with some insight.
>
> Recently, I booted my computer, a Dell Latitude D810 that has a
> Radeon Mobility x600 (R300); all systems were waking up as normal:
>
> * Th
> > > > > + DRM_ERROR("desired size is bigger then real
> size.\n");
> > > >
> > > > So .. you can't continue by just using the real size instead?
> > > >
> > >
> > > I am afraid I don't understand what you mean but I think that condition
> > is
> > > fine. size is a vm area to user-des
Desc: This is a digitally signed message part
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20110921/0efd656f/attachment.pgp>
On Wed, Sep 21, 2011 at 10:12 AM, Adam Jackson wrote:
> If hardware does require composite sync for a mode, it's out of luck
> with current drivers, since none support that. ?Just skip the mode
> instead, there'll be others in the EDID. ?(Unless there's not, in which
> case, failing is correct any
On Wed, Sep 21, 2011 at 8:01 AM, Tomi Valkeinen wrote:
> I don't know what MCS is.
MCS is manufacturer specific commands (Manufacturer Command Set).
> But DSI is just a bi-directional transfer
> protocol between the SoC and the peripheral, you can send arbitrary data
> over it.
>
> Normally the S
If hardware does require composite sync for a mode, it's out of luck
with current drivers, since none support that. Just skip the mode
instead, there'll be others in the EDID. (Unless there's not, in which
case, failing is correct anyway.)
While we're at it, hush the other mode support messages
https://bugs.freedesktop.org/show_bug.cgi?id=33399
--- Comment #2 from Andy Furniss 2011-09-21
09:59:04 PDT ---
(In reply to comment #1)
> Hi,
>
> could I have at least a hint to know if it's to be supported soon, or one day,
> or never ?
>
> Thanks,
> Xav
I am not a dev - but nothing
https://bugs.freedesktop.org/show_bug.cgi?id=33399
--- Comment #2 from Andy Furniss 2011-09-21
09:59:04 PDT ---
(In reply to comment #1)
> Hi,
>
> could I have at least a hint to know if it's to be supported soon, or one day,
> or never ?
>
> Thanks,
> Xav
I am not a dev - but nothing
On Mon, 19 Sep 2011 15:22:03 -0700
Keith Packard wrote:
> There's no good reason to turn off the eDP force VDD bit synchronously
> while probing devices; that just sticks a huge delay into all mode
> setting paths. Instead, queue a delayed work proc to disable the VDD
> force bit and then remembe
On Mon, 19 Sep 2011 15:22:00 -0700
Keith Packard wrote:
> The eDP panel may not be able to respond to aux channel communications
> unless it has power supplied. During mode setting, power may be
> cut-off during panel power sequencing. Make sure that any aux channel
> communications will work by
On Tue, 2011-09-20 at 23:20 +0200, Patrik Jakobsson wrote:
> Ok, not sure I understand the complexity of DSI. Can overlay composition
> occur after/at the DSI stage (through MCS perhaps)? Or is it a matter of
> panels requiring special scanout buffer formats that for instance V4L needs
> to know a
On Wed, 2011-09-21 at 11:29 -0400, Alex Deucher wrote:
> On Wed, Sep 21, 2011 at 10:12 AM, Adam Jackson wrote:
> > If hardware does require composite sync for a mode, it's out of luck
> > with current drivers, since none support that. Just skip the mode
> > instead, there'll be others in the EDID
On Wed, Sep 21, 2011 at 7:41 AM, Marek Szyprowski
wrote:
>> I'm not entirely sure what will happen w/ dma_alloc_coherent, etc, if
>> the global CMA pool is exhausted.
>>
>> Marek? ?I guess you know what would happen?
>
> The allocation will simply fail and dma_alloc_coherent will return NULL.
>
O
On Wed, Sep 21, 2011 at 10:12 AM, Adam Jackson wrote:
> If hardware does require composite sync for a mode, it's out of luck
> with current drivers, since none support that. Just skip the mode
> instead, there'll be others in the EDID. (Unless there's not, in which
> case, failing is correct any
https://bugs.freedesktop.org/show_bug.cgi?id=33399
--- Comment #1 from Xavier Bestel 2011-09-21 08:19:25
PDT ---
Hi,
could I have at least a hint to know if it's to be supported soon, or one day,
or never ?
Thanks,
Xav
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?
https://bugs.freedesktop.org/show_bug.cgi?id=33399
--- Comment #1 from Xavier Bestel 2011-09-21
08:19:25 PDT ---
Hi,
could I have at least a hint to know if it's to be supported soon, or one day,
or never ?
Thanks,
Xav
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?
https://bugs.freedesktop.org/show_bug.cgi?id=41086
Summary: [r600] Screen update problems when scrolling to the
right in Java applications
Product: DRI
Version: XOrg CVS
Platform: x86-64 (AMD64)
OS/Version: Linux (All)
https://bugs.freedesktop.org/show_bug.cgi?id=41086
Summary: [r600] Screen update problems when scrolling to the
right in Java applications
Product: DRI
Version: XOrg CVS
Platform: x86-64 (AMD64)
OS/Version: Linux (All)
https://bugs.freedesktop.org/show_bug.cgi?id=39308
--- Comment #2 from almos 2011-09-21 07:18:34 PDT ---
Now I tried it again with a freshly updated mesa (rev
4ef82cee6d297684bc178dc243e4d3b6c5704955), and it renders the picture
correctly. Decode is still broken (#39309) though.
It has these rem
https://bugs.freedesktop.org/show_bug.cgi?id=39308
--- Comment #2 from almos 2011-09-21 07:18:34 PDT ---
Now I tried it again with a freshly updated mesa (rev
4ef82cee6d297684bc178dc243e4d3b6c5704955), and it renders the picture
correctly. Decode is still broken (#39309) though.
It has these rem
If hardware does require composite sync for a mode, it's out of luck
with current drivers, since none support that. Just skip the mode
instead, there'll be others in the EDID. (Unless there's not, in which
case, failing is correct anyway.)
While we're at it, hush the other mode support messages
On Wed, Sep 21, 2011 at 7:41 AM, Marek Szyprowski
wrote:
>> I'm not entirely sure what will happen w/ dma_alloc_coherent, etc, if
>> the global CMA pool is exhausted.
>>
>> Marek? I guess you know what would happen?
>
> The allocation will simply fail and dma_alloc_coherent will return NULL.
>
O
https://bugs.freedesktop.org/show_bug.cgi?id=41079
Summary: xorg-r600: display (sometimes) doesn't get updated or
only partially
Product: Mesa
Version: git
Platform: Other
OS/Version: All
Status: NEW
Sever
https://bugs.freedesktop.org/show_bug.cgi?id=41079
Summary: xorg-r600: display (sometimes) doesn't get updated or
only partially
Product: Mesa
Version: git
Platform: Other
OS/Version: All
Status: NEW
Sever
https://bugs.freedesktop.org/show_bug.cgi?id=40986
--- Comment #1 from Kai 2011-09-21 04:03:51 PDT ---
With the latest Mesa Git snapshot (4a96a02d) there is some improvement: the
blue overlay is gone, now I've a distorted (too long) cursor. It looks like
there is some interleaving problem, becaus
https://bugs.freedesktop.org/show_bug.cgi?id=40986
--- Comment #1 from Kai 2011-09-21 04:03:51 PDT
---
With the latest Mesa Git snapshot (4a96a02d) there is some improvement: the
blue overlay is gone, now I've a distorted (too long) cursor. It looks like
there is some interleaving problem, becau
Hi Alan and Rob,
On Monday 19 September 2011 02:09:36 Rob Clark wrote:
> 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,
> >
56 matches
Mail list logo
