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
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
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
---
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;
};
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
---
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
+++
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
---
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
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:
>
> *
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
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
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
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
>
y 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
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
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
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
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.
>
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/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
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
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,
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,
> >
On Tue, Sep 20, 2011 at 5:55 PM, Keith Packard wrote:
> I'm not sure we need a new abstraction that subsumes both DSI and SDVO,
Ok. SDVO fits within the current abstraction, but I guess what I'm fishing
for is more code sharing of encoders. For instance, the SDVO code in GMA500
could be shared
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
https://bugs.freedesktop.org/show_bug.cgi?id=40986
--- Comment #1 from Kai deb...@carbon-project.org 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
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
On Wed, Sep 21, 2011 at 7:41 AM, Marek Szyprowski
m.szyprow...@samsung.com 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
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=39308
--- Comment #2 from almos aaalmo...@gmail.com 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)
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=33399
--- Comment #1 from Xavier Bestel xavier.bes...@free.fr 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:
On Wed, Sep 21, 2011 at 10:12 AM, Adam Jackson a...@redhat.com 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
On Wed, 2011-09-21 at 11:29 -0400, Alex Deucher wrote:
On Wed, Sep 21, 2011 at 10:12 AM, Adam Jackson a...@redhat.com 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
https://bugs.freedesktop.org/show_bug.cgi?id=33399
--- Comment #2 from Andy Furniss li...@andyfurniss.entadsl.com 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
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 SoC
+ 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-desired size and you could
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:
* The Dell
On Wed, 21 Sep 2011 16:56:12 -0400, Akshay Joshi m...@akshayjoshi.com 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
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: c0efd8527ff34853a23f1d706be29c67-mfwit...@gmail.com
http://lists.freedesktop.org/archives/dri-devel/2011-September/014506.html
I made the
Date: Thu, 15 Sep 2011 21:06:24 +
Signed-off-by: Michael Witten mfwit...@gmail.com
---
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
Date: Thu, 15 Sep 2011 21:07:26 +
Signed-off-by: Michael Witten mfwit...@gmail.com
---
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
---
Date: Thu, 15 Sep 2011 21:12:19 +
Signed-off-by: Michael Witten mfwit...@gmail.com
---
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
Date: Thu, 15 Sep 2011 14:43:00 +
Signed-off-by: Michael Witten mfwit...@gmail.com
---
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
---
Date: Fri, 16 Sep 2011 20:09:22 +
Signed-off-by: Michael Witten mfwit...@gmail.com
---
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
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;
};
Date: Wed, 21 Sep 2011 02:10:43 +
Signed-off-by: Michael Witten mfwit...@gmail.com
---
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
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-arm-
55 matches
Mail list logo
