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 wit
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, 21 Sep 2011 09:47:59 +0530, Jesse Barnes
wrote:
> I'm worried this makes our PPS even more complex and hard to follow.
> I'd rather see VDD AUX applied only when we need it (dpms, mode set and
> detect; for hotplug we can assume the panel is alive) and that we
> carefully disable it afte
n/pgp-signature
Size: 189 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20110920/ce37d482/attachment.pgp>
On Wed, 21 Sep 2011 09:20:01 +0530, Jesse Barnes
wrote:
> This one mixes up lots of cleanups plus the EDID read with the power
> changes.
I think the cleanups are;
1) edp checks inside vdd_on and vdd_off to make the other code a bit
easier to read.
2) Hold VDD on until the end of dp_com
--- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20110920/d1df6f2b/attachment-0001.pgp>
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, 20 Sep 2011 08:47:21 -0700, Keith Packard wrote:
> We were relying on the BIOS to set these bits, which doesn't always
> happen.
Do we need to clear IRQ bits on uninstall, for example to prevent
"Interrupt 19: no one cared!" or is that due to a different cause?
More of a general question
https://bugs.freedesktop.org/show_bug.cgi?id=41060
--- Comment #1 from Marek Olšák 2011-09-20 16:41:44 PDT ---
That usually means the kernel cannot relocate all the buffers for the submitted
command stream due to lack of available memory.
--
Configure bugmail: https://bugs.freedesktop.org/userp
https://bugs.freedesktop.org/show_bug.cgi?id=41060
--- Comment #1 from Marek Ol??k 2011-09-20 16:41:44 PDT
---
That usually means the kernel cannot relocate all the buffers for the submitted
command stream due to lack of available memory.
--
Configure bugmail: https://bugs.freedesktop.org/user
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,
> >
https://bugs.freedesktop.org/show_bug.cgi?id=41060
Summary: r600g: "Failed to parse relocation -12!" followed by
widespread texture corruption
Product: Mesa
Version: 7.11
Platform: Other
OS/Version: All
Status: NEW
https://bugs.freedesktop.org/show_bug.cgi?id=41060
Summary: r600g: "Failed to parse relocation -12!" followed by
widespread texture corruption
Product: Mesa
Version: 7.11
Platform: Other
OS/Version: All
Status: NEW
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 wit
https://bugs.freedesktop.org/show_bug.cgi?id=22030
Matt Turner changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
https://bugs.freedesktop.org/show_bug.cgi?id=22030
Matt Turner changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
On Tue, Sep 20, 2011 at 10:22 AM, Ilija Hadzic
wrote:
> Enabling pcie gen2 speed was skipped for Northern Islands
> AISCs, although it looks like it works just fine with the same
> initialization sequence used for evergreen.
>
> According to Alex D. gen2 init was skipped to prevent a crash
> that
https://bugs.freedesktop.org/show_bug.cgi?id=41051
Summary: Portal hard locks the machine on rv350.
Product: Mesa
Version: git
Platform: x86 (IA32)
OS/Version: Linux (All)
Status: NEW
Severity: normal
Priority: medi
https://bugs.freedesktop.org/show_bug.cgi?id=41051
Summary: Portal hard locks the machine on rv350.
Product: Mesa
Version: git
Platform: x86 (IA32)
OS/Version: Linux (All)
Status: NEW
Severity: normal
Priority: medi
https://bugs.freedesktop.org/show_bug.cgi?id=36554
--- Comment #9 from Scott Moreau 2011-09-20 11:31:03 PDT ---
Also, I've upgraded my system ram to 4GB and it did not make a difference.
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this ma
https://bugs.freedesktop.org/show_bug.cgi?id=36554
--- Comment #9 from Scott Moreau 2011-09-20 11:31:03 PDT
---
Also, I've upgraded my system ram to 4GB and it did not make a difference.
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this m
https://bugs.freedesktop.org/show_bug.cgi?id=36554
--- Comment #8 from Scott Moreau 2011-09-20 11:29:44 PDT ---
Created an attachment (id=51418)
--> (https://bugs.freedesktop.org/attachment.cgi?id=51418)
glxinfo
(In reply to comment #7)
> Is this still a problem with the latest code from git.
https://bugs.freedesktop.org/show_bug.cgi?id=36554
--- Comment #8 from Scott Moreau 2011-09-20 11:29:44 PDT
---
Created an attachment (id=51418)
--> (https://bugs.freedesktop.org/attachment.cgi?id=51418)
glxinfo
(In reply to comment #7)
> Is this still a problem with the latest code from git.
On Mon, Sep 19, 2011 at 9:29 AM, Tomi Valkeinen wrote:
>> So DSI is more like i2c than the DisplayPort aux channel or DDC. That
>
> Well, not quite. DSI is like DisplayPort and DisplayPort aux combined;
> there's only one bus, DSI, which is used to transfer video data and
> commands.
>
> For DSI vi
Looks like the same pcie gen2 speed initialization for
Evergreen also works on Cayman and seems to come up fine,
so enable it if the module parameter says so
Signed-off-by: Ilija Hadzic
---
drivers/gpu/drm/radeon/evergreen.c |4 ++--
drivers/gpu/drm/radeon/ni.c|4
2 files ch
Enabling pcie gen2 speed was skipped for Northern Islands
AISCs, although it looks like it works just fine with the same
initialization sequence used for evergreen.
According to Alex D. gen2 init was skipped to prevent a crash
that has been caused by some other bug that has been
fixed in the meant
On Tue, 20 Sep 2011 17:24:21 +0100, Chris Wilson
wrote:
> On Tue, 20 Sep 2011 08:47:21 -0700, Keith Packard wrote:
> > We were relying on the BIOS to set these bits, which doesn't always
> > happen.
>
> Do we need to clear IRQ bits on uninstall, for example to prevent
> "Interrupt 19: no one ca
next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20110920/a5773bbe/attachment.pgp>
On Tue, 20 Sep 2011 08:47:21 -0700, Keith Packard wrote:
> We were relying on the BIOS to set these bits, which doesn't always
> happen.
Do we need to clear IRQ bits on uninstall, for example to prevent
"Interrupt 19: no one cared!" or is that due to a different cause?
More of a general question
On Tue, 20 Sep 2011 10:29:23 +0200, Patrik Jakobsson
wrote:
> It would be nice to have a model that fits both DSI and SDVO, and the option
> to configure some of it from userspace.
> I thought the purpose of drm_encoder was to abstract hardware like this?
SDVO is entirely hidden by the drm_enc
y both DRM and other
parts of the kernel.
--
keith.packard at intel.com
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/att
We were relying on the BIOS to set these bits, which doesn't always
happen.
Signed-off-by: Keith Packard
---
v2: set the hotplug bits in the irq post-install hook, just
like we do for pre-PCH hardware.
drivers/gpu/drm/i915/i915_irq.c | 24
drivers/gpu/drm/i915/i915_r
We were relying on the BIOS to set these bits, which doesn't always
happen.
Signed-off-by: Keith Packard
---
v2: set the hotplug bits in the irq post-install hook, just
like we do for pre-PCH hardware.
drivers/gpu/drm/i915/i915_irq.c | 24
drivers/gpu/drm/i915/i915_r
On Tue, Sep 20, 2011 at 10:22 AM, Ilija Hadzic
wrote:
> Enabling pcie gen2 speed was skipped for Northern Islands
> AISCs, although it looks like it works just fine with the same
> initialization sequence used for evergreen.
>
> According to Alex D. gen2 init was skipped to prevent a crash
> that
Looks like the same pcie gen2 speed initialization for
Evergreen also works on Cayman and seems to come up fine,
so enable it if the module parameter says so
Signed-off-by: Ilija Hadzic
---
drivers/gpu/drm/radeon/evergreen.c |4 ++--
drivers/gpu/drm/radeon/ni.c|4
2 files ch
Enabling pcie gen2 speed was skipped for Northern Islands
AISCs, although it looks like it works just fine with the same
initialization sequence used for evergreen.
According to Alex D. gen2 init was skipped to prevent a crash
that has been caused by some other bug that has been
fixed in the meant
https://bugs.freedesktop.org/show_bug.cgi?id=26345
--- Comment #138 from Daniel Vetter 2011-09-20 06:00:31 PDT
---
Created an attachment (id=51401)
View: https://bugs.freedesktop.org/attachment.cgi?id=51401
Review: https://bugs.freedesktop.org/review?bug=26345&attachment=51401
New stab at wor
https://bugs.freedesktop.org/show_bug.cgi?id=26345
--- Comment #138 from Daniel Vetter 2011-09-20 06:00:31
PDT ---
Created an attachment (id=51401)
View: https://bugs.freedesktop.org/attachment.cgi?id=51401
Review: https://bugs.freedesktop.org/review?bug=26345&attachment=51401
New stab at wor
https://bugs.freedesktop.org/show_bug.cgi?id=39320
--- Comment #11 from Marek Olšák 2011-09-20 01:55:38 PDT ---
Can you send me the trace file that glretrace crashes with?
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
https://bugs.freedesktop.org/show_bug.cgi?id=39320
--- Comment #11 from Marek Ol??k 2011-09-20 01:55:38 PDT
---
Can you send me the trace file that glretrace crashes with?
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: --
On Mon, Sep 19, 2011 at 9:29 AM, Tomi Valkeinen wrote:
>> So DSI is more like i2c than the DisplayPort aux channel or DDC. That
>
> Well, not quite. DSI is like DisplayPort and DisplayPort aux combined;
> there's only one bus, DSI, which is used to transfer video data and
> commands.
>
> For DSI vi
42 matches
Mail list logo
