On Fri, Aug 10, 2012 at 05:19:48PM -0500, Seth Forshee wrote:
> First, I don't have a solution for the ordering of initialization. It
> just happens to work out for me right now.
Okay, I've got a proof-of-concept implementation of delaying secondary
GPU initialization until the i2c can be muxed ov
During graphics driver initialization its useful to be able to mux only
the DDC to the inactive client in order to read the EDID. Add a
switch_ddc callback to allow capable handlers to provide this
functionality, and add vga_switcheroo_switch_ddc() to allow DRM to mux
only the DDC.
Signed-off-by:
Add vga_switcheroo_get_active_client() to allow drivers to get the
active video client. This will be used by drivers wishing to temporarily
mux only the DDC to the inactive client.
Signed-off-by: Seth Forshee
---
drivers/gpu/vga/vga_switcheroo.c | 14 ++
include/linux/vga_switchero
DRM needs to be notified of client and handler registration in order to
defer initialization of the secondary GPU until the EDID can be read
from the LVDS panel. To support this add a notifier call chain to
vga_switcheroo for subscribing to switcheroo events. Events are
generated for registration a
The gmux allows muxing the DDC independently from the display, so
support this functionality. This will allow reading the EDID for the
inactive GPU, fixing issues with machines that either don't have a VBT
or have invalid mode data in the VBT.
Signed-off-by: Seth Forshee
---
drivers/platform/x86
Some dual graphics machines support muxing the DDC separately from the
display, so make use of this functionality when reading the EDID on the
inactive GPU. Also serialize drm_get_edid() with a mutex to avoid races
on the DDC mux state.
Signed-off-by: Seth Forshee
---
drivers/gpu/drm/drm_edid.c
When deferred initialization support for pci devices is added some
additional cleanup will be needed. Add a pci-specific put function to
serve this purpose, and convert the pci drivers over to using it. For
now it just calls drm_put_dev(), so this commit has no functional
change.
Signed-off-by: Se
Deferring initiailzation of the secondary GPU until switcheroo is ready
will allow successfully reading the EDID in systems which support muxing
the DDC seperately from the display.
Signed-off-by: Seth Forshee
---
drivers/gpu/drm/drm_drv.c |3 +
drivers/gpu/drm/drm_pci.c | 141 +
On Mon, Aug 20, 2012 at 04:36:40PM +0100, Matthew Garrett wrote:
> On Mon, Aug 20, 2012 at 10:31:04AM -0500, Seth Forshee wrote:
> > + /*
> > +* For secondary graphics devices shouldn't be initialized
> > +* until the handler and primary graphics device have been
> > +* registered wit
On Mon, Aug 20, 2012 at 04:57:41PM +0100, Matthew Garrett wrote:
> On Mon, Aug 20, 2012 at 10:56:33AM -0500, Seth Forshee wrote:
> > On Mon, Aug 20, 2012 at 04:36:40PM +0100, Matthew Garrett wrote:
> > > Won't this break the multiple cards with independent outputs case?
> >
> > Yes, if they don't
Fix config warning:
warning: ( ... && DRM_USB) selects USB which has unmet direct dependencies
(USB_SUPPORT && USB_ARCH_HAS_HCD)
and build error:
ERROR: "usb_speed_string" [drivers/usb/core/usbcore.ko] undefined!
by adding the missing dependency on USB_ARCH_HAS_HCD to DRM_UDL and DRM_USB.
This
On Mon, Aug 20, 2012 at 11:23:16AM -0700, Guenter Roeck wrote:
> Fix config warning:
>
> warning: ( ... && DRM_USB) selects USB which has unmet direct dependencies
> (USB_SUPPORT && USB_ARCH_HAS_HCD)
>
> and build error:
> ERROR: "usb_speed_string" [drivers/usb/core/usbcore.ko] undefined!
>
> by
The current logic for probing ddc is limited to
2 blocks (256 bytes), this patch adds support
for the 4 block (512) data.
To do this, a single 8-bit segment index is
passed to the display via the I2C address 30h.
Data from the selected segment is then immediately
read via the regular DDC2 address
This patch adds support in probing 4 block edid data, for E-DDC.
This is the first test case in CTS, for HDMI compliance.
Based on drm-next branch
Shirish S (1):
drm: edid: add support for E-DDC
drivers/gpu/drm/drm_edid.c | 17 -
1 files changed, 12 insertions(+), 5 deletion
On Tue, 2012-08-21 at 01:29 +0200, Laurent Pinchart wrote:
> Hi Tomi,
>
> On Monday 20 August 2012 14:39:30 Tomi Valkeinen wrote:
> > On Sat, 2012-08-18 at 03:16 +0200, Laurent Pinchart wrote:
> > > Hi Tomi,
> > >
> > > mipi-dbi-bus might not belong to include/video/panel/ though, as it can be
>
So we've had a fair few reports of fbcon handover breakage between
efi/vesafb and i915 surface recently, so I dedicated a couple of
days to finding the problem.
Essentially the last thing we saw was the conflicting framebuffer
message and that was all.
So after much tracing with direct netconsole
On Fre, 2012-07-13 at 07:54 +0200, Michel Dänzer wrote:
> On Don, 2012-07-12 at 18:23 -0400, j.gli...@gmail.com wrote:
> > From: Jerome Glisse
> >
> > Retry label was at wrong place in function leading to memory
> > leak.
> >
> > Cc:
> > Signed-off-by: Jerome Glisse
> > ---
> > drivers/gpu/
https://bugzilla.kernel.org/show_bug.cgi?id=31862
--- Comment #4 from Michel Dänzer 2012-08-21 08:14:28 ---
(In reply to comment #1)
> My active graphics card is the Intel one of these:
Alan, I think you picked the wrong component.
--
Configure bugmail: https://bugzilla.kernel.org/userpre
https://bugzilla.kernel.org/show_bug.cgi?id=31862
Alan changed:
What|Removed |Added
Component|Video(DRI - non Intel) |Video(DRI - Intel)
AssignedTo|drivers_vid
Hi Tomi,
On Tuesday 21 August 2012 08:49:57 Tomi Valkeinen wrote:
> On Tue, 2012-08-21 at 01:29 +0200, Laurent Pinchart wrote:
> > On Monday 20 August 2012 14:39:30 Tomi Valkeinen wrote:
> > > On Sat, 2012-08-18 at 03:16 +0200, Laurent Pinchart wrote:
> > > > Hi Tomi,
> > > >
> > > > mipi-dbi-bus
> So after much tracing with direct netconsole writes (printks
> under console_lock not so useful), I think I found the race.
Direct netconsole write would be a useful patch to have mainline I think
8)
> Hopefully this fixes the problem for anyone seeing vesafb->kms
> driver handoff.
Not really
Hi Tomasz,
Thanks for the patch.
Just a couple of small comments below.
On Tuesday 14 August 2012 17:34:50 Tomasz Stanislawski wrote:
> This patch adds support for exporting a dma-contig buffer using
> DMABUF interface.
>
> Signed-off-by: Tomasz Stanislawski
> Signed-off-by: Kyungmin Park
> -
Am Dienstag, den 21.08.2012, 12:40 +0530 schrieb Shirish S:
> The current logic for probing ddc is limited to
> 2 blocks (256 bytes), this patch adds support
> for the 4 block (512) data.
>
> To do this, a single 8-bit segment index is
> passed to the display via the I2C address 30h.
> Data from t
On Tue, Aug 21, 2012 at 9:10 AM, Shirish S wrote:
> The current logic for probing ddc is limited to
> 2 blocks (256 bytes), this patch adds support
> for the 4 block (512) data.
>
> To do this, a single 8-bit segment index is
> passed to the display via the I2C address 30h.
> Data from the selecte
On Tue, Aug 21, 2012 at 12:40:48PM +0530, Shirish S wrote:
> The current logic for probing ddc is limited to
> 2 blocks (256 bytes), this patch adds support
> for the 4 block (512) data.
A patch for this was already sent a long time ago:
http://lists.freedesktop.org/archives/dri-devel/2011-Decembe
Hi Dave,
Nothing too major:
- A few fixes around the edid handling from Jani, also fixing a regression
in 3.5 due to us using gmbus by default.
- Fixup hsw uncached pte flags.
- Fix suspend/resume crash when using hw contexts, from Ben.
- Try to tune gpu turbo a bit better, seems to help with so
On 20.08.2012 20:58, Alex Deucher wrote:
On Mon, Aug 20, 2012 at 4:08 AM, Christian König
wrote:
Second and hopefully last round for this patchset.
v2: Fix suspend/resume, and incorporate Jeromes comments.
Looks good to me. Can you put up a git branch somewhere?
Sure: git://people.freedeskto
Hi Laurent,
Thank you for your comments.
On 08/21/2012 12:03 PM, Laurent Pinchart wrote:
> Hi Tomasz,
>
> Thanks for the patch.
>
> Just a couple of small comments below.
>
> On Tuesday 14 August 2012 17:34:50 Tomasz Stanislawski wrote:
>> This patch adds support for exporting a dma-contig buff
On Mon, Aug 20, 2012 at 3:30 PM, Luca Tettamanti wrote:
> On Mon, Aug 20, 2012 at 10:24:01AM -0400, Alex Deucher wrote:
>> > I just tested the rebased acpi_patches branch: ACPI part works fine, but
>> > I see a big slow down during radeon driver initialization when the
>> > screen goes black for a
Hello Daniel,
On Tue, Aug 21, 2012 at 4:18 AM, Daniel Vetter wrote:
> On Tue, Aug 21, 2012 at 9:10 AM, Shirish S wrote:
> > The current logic for probing ddc is limited to
> > 2 blocks (256 bytes), this patch adds support
> > for the 4 block (512) data.
> >
> > To do this, a single 8-bit segmen
Hello Ville Syrjälä,
On Tue, Aug 21, 2012 at 4:26 AM, Ville Syrjälä <
ville.syrj...@linux.intel.com> wrote:
> On Tue, Aug 21, 2012 at 12:40:48PM +0530, Shirish S wrote:
> > The current logic for probing ddc is limited to
> > 2 blocks (256 bytes), this patch adds support
> > for the 4 block (512)
Hi Tomasz,
On Tuesday 21 August 2012 15:47:13 Tomasz Stanislawski wrote:
> On 08/21/2012 12:03 PM, Laurent Pinchart wrote:
> > On Tuesday 14 August 2012 17:34:50 Tomasz Stanislawski wrote:
> >> This patch adds support for exporting a dma-contig buffer using
> >> DMABUF interface.
> >>
> >> Signed
Hi,
Any comments on this series?
On 1 August 2012 17:15, Sachin Kamat wrote:
> Fixes the following sparse warning:
> drivers/gpu/drm/drm_proc.c:92:5:
> warning: symbol 'drm_proc_create_files' was not declared. Should it be static?
> drivers/gpu/drm/drm_proc.c:175:5:
> warning: symbol 'drm_proc_r
On Tue, Aug 21, 2012 at 1:01 AM, Tomi Valkeinen wrote:
> On Mon, 2012-08-20 at 20:47 -0500, Ricardo Neri wrote:
>> Hello!
>>
>> I have been working on prototypes for the ASoC OMAP HDMI audio driver to
>> propagate events from the HDMI output (e.g., display getting
>> enabled/disabled/suspended). T
On Tue, Aug 21, 2012 at 07:39:55AM -0500, Clark, Rob wrote:
> Does ASoC support 'hotplug' of audio devices? If so, maybe it makes
> some sense to have some support in drm core. At least all the edid
> parsing stuff to determine if the display supports audio should be
> generic and not driver spe
On Tue, Aug 21, 2012 at 3:03 AM, Michel Dänzer wrote:
> On Fre, 2012-07-13 at 07:54 +0200, Michel Dänzer wrote:
>> On Don, 2012-07-12 at 18:23 -0400, j.gli...@gmail.com wrote:
>> > From: Jerome Glisse
>> >
>> > Retry label was at wrong place in function leading to memory
>> > leak.
>> >
>> > Cc:
On 21.08.2012 15:51, Alex Deucher wrote:
On Mon, Aug 20, 2012 at 3:30 PM, Luca Tettamanti wrote:
On Mon, Aug 20, 2012 at 10:24:01AM -0400, Alex Deucher wrote:
I just tested the rebased acpi_patches branch: ACPI part works fine, but
I see a big slow down during radeon driver initialization when
On Tue, 2012-08-21 at 10:15 +0100, Alan Cox wrote:
> > So after much tracing with direct netconsole writes (printks
> > under console_lock not so useful), I think I found the race.
>
> Direct netconsole write would be a useful patch to have mainline I think
> 8)
could we make that use the earlyp
On Tue, 2012-08-21 at 16:40 +1000, Dave Airlie wrote:
> So after much tracing with direct netconsole writes (printks
> under console_lock not so useful)
I always use earlyprintk on serial..
--
Live Security Virtual Conf
https://bugs.freedesktop.org/show_bug.cgi?id=53884
Bug #: 53884
Summary: gl_FragCoord gets corrupted in some camera angles
Classification: Unclassified
Product: Mesa
Version: 8.0
Platform: x86-64 (AMD64)
OS/Version: Linux (All)
https://bugs.freedesktop.org/show_bug.cgi?id=53884
--- Comment #1 from Lauri Kasanen 2012-08-21 14:43:19
UTC ---
Created attachment 65892
--> https://bugs.freedesktop.org/attachment.cgi?id=65892
Same scene, good camera angle
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?ta
https://bugs.freedesktop.org/show_bug.cgi?id=53884
--- Comment #2 from Lauri Kasanen 2012-08-21 14:46:53
UTC ---
Apitrace (60mb):
http://www.ziddu.com/download/20164691/fragcoord.trace.zip.html
Renamed as a zip to let it be uploaded.
--
Configure bugmail: https://bugs.freedesktop.org/userpre
Any objections from the ACPI folks to this patch going into 3.6 and stable?
Alex
On Mon, Aug 20, 2012 at 11:19 AM, wrote:
> From: Alex Deucher
>
> We need it in the radeon drm module to fetch
> and verify the vbios image on UEFI systems.
>
> Signed-off-by: Alex Deucher
> Cc: sta...@vger.kerne
On Tue, Aug 21, 2012 at 10:50:35AM -0400, Alex Deucher wrote:
> Any objections from the ACPI folks to this patch going into 3.6 and stable?
Looks good to me.
--
Matthew Garrett | mj...@srcf.ucam.org
___
dri-devel mailing list
dri-devel@lists.freedeskto
On Tue, Aug 21, 2012 at 06:55:53AM -0700, Shirish S wrote:
> Hello Ville Syrjälä,
>
> On Tue, Aug 21, 2012 at 4:26 AM, Ville Syrjälä <
> ville.syrj...@linux.intel.com> wrote:
>
> > On Tue, Aug 21, 2012 at 12:40:48PM +0530, Shirish S wrote:
> > > The current logic for probing ddc is limited to
> >
https://bugs.freedesktop.org/show_bug.cgi?id=53884
Ian Romanick changed:
What|Removed |Added
AssignedTo|dri-devel@lists.freedesktop |mesa-dev@lists.freedesktop.
On Tue, Aug 21, 2012 at 09:51:46AM -0400, Alex Deucher wrote:
> On Mon, Aug 20, 2012 at 3:30 PM, Luca Tettamanti wrote:
> > Any printk between evergreen_mc_stop and evergreen_mc_resume locks up
> > the machine. The likely culprit is commit 023e188e:
>
> yeah, vram is locked out at that point. I
On Tue, Aug 21, 2012 at 4:33 PM, Luca Tettamanti wrote:
> On Tue, Aug 21, 2012 at 09:51:46AM -0400, Alex Deucher wrote:
>> On Mon, Aug 20, 2012 at 3:30 PM, Luca Tettamanti wrote:
>> > Any printk between evergreen_mc_stop and evergreen_mc_resume locks up
>> > the machine. The likely culprit is com
From: Alex Deucher
Hi Dave,
This is the current set of radeon fixes for 3.6. Nothing too major.
Highlights:
- fix vbios fetch on pure uefi systems
- fix vbios fetch on thunderbolt systems
- MSAA fixes
- lockup timeout fix
- modesetting fix
The following changes since commit 2e26c73a1e410448fb
Hi all,
After Dave Airlie blew through a few days to track down a deadlock at boot-up
when handing over from the firmware fb to the kms/drm framebuffer driver (1),
I've
figured that lockdep /should/ have caught this.
And indeed, by adding proper annotations to the console_lock it complains about
Instead of BUG_ON(in_interrupt()), since that doesn't check for all
the newfangled stuff like preempt.
Note that this is valid since the console_sem is essentially used like
a real mutex with only two twists:
- we allow trylock from hardirq context
- across suspend/resume we lock the logical conso
Dave Airlie recently discovered a locking bug in the fbcon layer,
where a timer_del_sync (for the blinking cursor) deadlocks with the
timer itself, since both (want to) hold the console_lock:
https://lkml.org/lkml/2012/8/21/36
Unfortunately the console_lock isn't a plain mutex and hence has no
lo
On additional small fix I just pushed:
drm/radeon/ss: use num_crtc rather than hardcoded 6
On Tue, Aug 21, 2012 at 4:53 PM, wrote:
> From: Alex Deucher
>
> Hi Dave,
>
> This is the current set of radeon fixes for 3.6. Nothing too major.
>
> Highlights:
> - fix vbios fetch on pure uefi systems
On Tue, Aug 21, 2012 at 7:56 AM, Ville Syrjälä <
ville.syrj...@linux.intel.com> wrote:
> On Tue, Aug 21, 2012 at 06:55:53AM -0700, Shirish S wrote:
> > Hello Ville Syrjälä,
> >
> > On Tue, Aug 21, 2012 at 4:26 AM, Ville Syrjälä <
> > ville.syrj...@linux.intel.com> wrote:
> >
> > > On Tue, Aug 21,
https://bugs.freedesktop.org/show_bug.cgi?id=53111
--- Comment #17 from Alexandre Demers 2012-08-22
03:02:45 UTC ---
(In reply to comment #13)
> (In reply to comment #12)
> > I tried to trace RenderFeatTest (one of the other applications locking my
> > system). It did as with the piglit test: i
On Tue, Aug 21, 2012 at 7:15 PM, Alan Cox wrote:
>> So after much tracing with direct netconsole writes (printks
>> under console_lock not so useful), I think I found the race.
>
> Direct netconsole write would be a useful patch to have mainline I think
> 8)
Well I used a one line wrapper around
Hi Linus,
Intel: edid fixes, power consumption fix, s/r fix, haswell fix
radeon: BIOS loading fixes for UEFI and Thunderbolt machines, better MSAA
validation, lockup timeout fixes, modesetting fixes
one udl dpms fix,
one vmwgfx fix,
couple of trivial core changes
There is an export added to ACP
2012/8/15 Jani Nikula :
> The EDID returned by drm_get_edid() was never freed.
>
> Signed-off-by: Jani Nikula
> ---
> drivers/gpu/drm/exynos/exynos_hdmi.c |1 +
> 1 files changed, 1 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c
> b/drivers/gpu/drm/exynos
Acked-by: Inki Dae
2012/8/15 Jani Nikula :
> Neither the drm core nor any of the drivers really need the raw_edid field
> of struct drm_display_info for anything. Instead of being useful, it
> creates confusion about who is responsible for freeing the memory it points
> to and setting the field t
https://bugs.freedesktop.org/show_bug.cgi?id=53111
--- Comment #18 from Alexandre Demers 2012-08-22
05:32:58 UTC ---
(In reply to comment #16)
> (In reply to comment #15)
> > (In reply to comment #10)
> > > Well, it seems running it through qapitrace doesn't lock.
> >
> > The apitrace looks inc
On Wed, Aug 22, 2012 at 2:06 PM, Dave Airlie wrote:
>
> Hi Linus,
>
> Intel: edid fixes, power consumption fix, s/r fix, haswell fix
> radeon: BIOS loading fixes for UEFI and Thunderbolt machines, better MSAA
> validation, lockup timeout fixes, modesetting fixes
> one udl dpms fix,
> one vmwgfx fi
Applied, Thanks.
2012/8/14 Sachin Kamat :
> Select Exynos DRM based G2D only if non-DRM based Exynos G2D driver
> is not selected.
>
> Signed-off-by: Sachin Kamat
> ---
> drivers/gpu/drm/exynos/Kconfig |2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/gpu/drm
On Tue, Aug 21, 2012 at 2:40 AM, Dave Airlie wrote:
> So we've had a fair few reports of fbcon handover breakage between
> efi/vesafb and i915 surface recently, so I dedicated a couple of
> days to finding the problem.
>
> Essentially the last thing we saw was the conflicting framebuffer
> message
--
Matthew Garrett | mj...@srcf.ucam.org
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
On 08/21/2012 07:39 AM, Clark, Rob wrote:
On Tue, Aug 21, 2012 at 1:01 AM, Tomi Valkeinen wrote:
On Mon, 2012-08-20 at 20:47 -0500, Ricardo Neri wrote:
Hello!
I have been working on prototypes for the ASoC OMAP HDMI audio driver to
propagate events from the HDMI output (e.g., display gettin
Hi Tomi,
On Monday 20 August 2012 14:39:30 Tomi Valkeinen wrote:
> On Sat, 2012-08-18 at 03:16 +0200, Laurent Pinchart wrote:
> > Hi Tomi,
> >
> > mipi-dbi-bus might not belong to include/video/panel/ though, as it can be
> > used for non-panel devices (at least in theory). The future mipi-dsi-bu
On Tue, Aug 21, 2012 at 8:45 AM, Randy Dunlap wrote:
> On 08/19/2012 10:22 PM, Dave Airlie wrote:
>
>> On Mon, Aug 20, 2012 at 3:13 PM, Randy Dunlap
>> wrote:
>>> On 08/17/12 15:55, Dave Airlie wrote:
>>>
On Sat, Aug 18, 2012 at 8:54 AM, Dave Airlie wrote:
> On Sat, Aug 18, 2012 at 8:2
Changelog v2:
fixed comments.
Changelog v1:
this interface can be used to make sure that hardware overlay is disabled
to avoid that memory region is accessed by dma after gem buffer was released.
Signed-off-by: Inki Dae
Signed-off-by: Kyungmin Park
---
drivers/gpu/drm/exynos/exynos_drm_drv.h
Changelog v2:
fixed the issue that when sub driver is probed, no kms drivers such as
fimd or hdmi are failed. no kms drivers have no manager so if manager is
null then encoder and connector creation should be ignored.
Changelog v1:
this patch separates exynos_drm_subdrv_probe function into sub dri
to use
the bus they provide.
Did you just mean we should have a separate directory for them, while
still part of the same framework, or...?
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/20120821/4be56086/attachment.pgp>
So we've had a fair few reports of fbcon handover breakage between
efi/vesafb and i915 surface recently, so I dedicated a couple of
days to finding the problem.
Essentially the last thing we saw was the conflicting framebuffer
message and that was all.
So after much tracing with direct netconsole
The current logic for probing ddc is limited to
2 blocks (256 bytes), this patch adds support
for the 4 block (512) data.
To do this, a single 8-bit segment index is
passed to the display via the I2C address 30h.
Data from the selected segment is then immediately
read via the regular DDC2 address
This patch adds support in probing 4 block edid data, for E-DDC.
This is the first test case in CTS, for HDMI compliance.
Based on drm-next branch
Shirish S (1):
drm: edid: add support for E-DDC
drivers/gpu/drm/drm_edid.c | 17 -
1 files changed, 12 insertions(+), 5 deletion
On Fre, 2012-07-13 at 07:54 +0200, Michel D?nzer wrote:
> On Don, 2012-07-12 at 18:23 -0400, j.glisse at gmail.com wrote:
> > From: Jerome Glisse
> >
> > Retry label was at wrong place in function leading to memory
> > leak.
> >
> > Cc:
> > Signed-off-by: Jerome Glisse
> > ---
> > drivers/g
https://bugzilla.kernel.org/show_bug.cgi?id=31862
--- Comment #4 from Michel D?nzer 2012-08-21 08:14:28
---
(In reply to comment #1)
> My active graphics card is the Intel one of these:
Alan, I think you picked the wrong component.
--
Configure bugmail: https://bugzilla.kernel.org/userpr
https://bugzilla.kernel.org/show_bug.cgi?id=31862
Alan changed:
What|Removed |Added
Component|Video(DRI - non Intel) |Video(DRI - Intel)
AssignedTo|drivers_vid
Hi Tomi,
On Tuesday 21 August 2012 08:49:57 Tomi Valkeinen wrote:
> On Tue, 2012-08-21 at 01:29 +0200, Laurent Pinchart wrote:
> > On Monday 20 August 2012 14:39:30 Tomi Valkeinen wrote:
> > > On Sat, 2012-08-18 at 03:16 +0200, Laurent Pinchart wrote:
> > > > Hi Tomi,
> > > >
> > > > mipi-dbi-bus
> So after much tracing with direct netconsole writes (printks
> under console_lock not so useful), I think I found the race.
Direct netconsole write would be a useful patch to have mainline I think
8)
> Hopefully this fixes the problem for anyone seeing vesafb->kms
> driver handoff.
Not really
Hi Tomasz,
Thanks for the patch.
Just a couple of small comments below.
On Tuesday 14 August 2012 17:34:50 Tomasz Stanislawski wrote:
> This patch adds support for exporting a dma-contig buffer using
> DMABUF interface.
>
> Signed-off-by: Tomasz Stanislawski
> Signed-off-by: Kyungmin Park
> -
ned message part
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20120821/b4d7be94/attachment.pgp>
On Tue, Aug 21, 2012 at 9:10 AM, Shirish S wrote:
> The current logic for probing ddc is limited to
> 2 blocks (256 bytes), this patch adds support
> for the 4 block (512) data.
>
> To do this, a single 8-bit segment index is
> passed to the display via the I2C address 30h.
> Data from the selecte
On Tue, Aug 21, 2012 at 12:40:48PM +0530, Shirish S wrote:
> The current logic for probing ddc is limited to
> 2 blocks (256 bytes), this patch adds support
> for the 4 block (512) data.
A patch for this was already sent a long time ago:
http://lists.freedesktop.org/archives/dri-devel/2011-Decembe
Hi Dave,
Nothing too major:
- A few fixes around the edid handling from Jani, also fixing a regression
in 3.5 due to us using gmbus by default.
- Fixup hsw uncached pte flags.
- Fix suspend/resume crash when using hw contexts, from Ben.
- Try to tune gpu turbo a bit better, seems to help with so
.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/dri-devel
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20120821/0f6526f4/attachment.html>
Hi Laurent,
Thank you for your comments.
On 08/21/2012 12:03 PM, Laurent Pinchart wrote:
> Hi Tomasz,
>
> Thanks for the patch.
>
> Just a couple of small comments below.
>
> On Tuesday 14 August 2012 17:34:50 Tomasz Stanislawski wrote:
>> This patch adds support for exporting a dma-contig buff
On Mon, Aug 20, 2012 at 3:30 PM, Luca Tettamanti wrote:
> On Mon, Aug 20, 2012 at 10:24:01AM -0400, Alex Deucher wrote:
>> > I just tested the rebased acpi_patches branch: ACPI part works fine, but
>> > I see a big slow down during radeon driver initialization when the
>> > screen goes black for a
___
> > dri-devel mailing list
> > dri-devel at lists.freedesktop.org
> > http://lists.freedesktop.org/mailman/listinfo/dri-devel
>
>
>
> --
> Daniel Vetter
> daniel.vetter at ffwll.ch - +41 (0) 79 364 57 48 - http://blog.ffwll.ch
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>
Regards,
Shirish S
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20120821/4dff7d91/attachment-0001.html>
mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>
Regards,
Shirish S
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20120821/c0b7ae13/attachment.html>
Hi Tomasz,
On Tuesday 21 August 2012 15:47:13 Tomasz Stanislawski wrote:
> On 08/21/2012 12:03 PM, Laurent Pinchart wrote:
> > On Tuesday 14 August 2012 17:34:50 Tomasz Stanislawski wrote:
> >> This patch adds support for exporting a dma-contig buffer using
> >> DMABUF interface.
> >>
> >> Signed
Hi,
Any comments on this series?
On 1 August 2012 17:15, Sachin Kamat wrote:
> Fixes the following sparse warning:
> drivers/gpu/drm/drm_proc.c:92:5:
> warning: symbol 'drm_proc_create_files' was not declared. Should it be static?
> drivers/gpu/drm/drm_proc.c:175:5:
> warning: symbol 'drm_proc_r
On Tue, Aug 21, 2012 at 1:01 AM, Tomi Valkeinen
wrote:
> On Mon, 2012-08-20 at 20:47 -0500, Ricardo Neri wrote:
>> Hello!
>>
>> I have been working on prototypes for the ASoC OMAP HDMI audio driver to
>> propagate events from the HDMI output (e.g., display getting
>> enabled/disabled/suspended).
scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20120821/3900444c/attachment.pgp>
On Tue, Aug 21, 2012 at 3:03 AM, Michel D?nzer wrote:
> On Fre, 2012-07-13 at 07:54 +0200, Michel D?nzer wrote:
>> On Don, 2012-07-12 at 18:23 -0400, j.glisse at gmail.com wrote:
>> > From: Jerome Glisse
>> >
>> > Retry label was at wrong place in function leading to memory
>> > leak.
>> >
>> > C
On 21.08.2012 15:51, Alex Deucher wrote:
> On Mon, Aug 20, 2012 at 3:30 PM, Luca Tettamanti
> wrote:
>> On Mon, Aug 20, 2012 at 10:24:01AM -0400, Alex Deucher wrote:
I just tested the rebased acpi_patches branch: ACPI part works fine, but
I see a big slow down during radeon driver initi
On Tue, 2012-08-21 at 10:15 +0100, Alan Cox wrote:
> > So after much tracing with direct netconsole writes (printks
> > under console_lock not so useful), I think I found the race.
>
> Direct netconsole write would be a useful patch to have mainline I think
> 8)
could we make that use the earlyp
On Tue, 2012-08-21 at 16:40 +1000, Dave Airlie wrote:
> So after much tracing with direct netconsole writes (printks
> under console_lock not so useful)
I always use earlyprintk on serial..
--
Live Security Virtual Conf
https://bugs.freedesktop.org/show_bug.cgi?id=53884
Bug #: 53884
Summary: gl_FragCoord gets corrupted in some camera angles
Classification: Unclassified
Product: Mesa
Version: 8.0
Platform: x86-64 (AMD64)
OS/Version: Linux (All)
https://bugs.freedesktop.org/show_bug.cgi?id=53884
--- Comment #1 from Lauri Kasanen 2012-08-21 14:43:19
UTC ---
Created attachment 65892
--> https://bugs.freedesktop.org/attachment.cgi?id=65892
Same scene, good camera angle
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?ta
https://bugs.freedesktop.org/show_bug.cgi?id=53884
--- Comment #2 from Lauri Kasanen 2012-08-21 14:46:53
UTC ---
Apitrace (60mb):
http://www.ziddu.com/download/20164691/fragcoord.trace.zip.html
Renamed as a zip to let it be uploaded.
--
Configure bugmail: https://bugs.freedesktop.org/userpre
Any objections from the ACPI folks to this patch going into 3.6 and stable?
Alex
On Mon, Aug 20, 2012 at 11:19 AM, wrote:
> From: Alex Deucher
>
> We need it in the radeon drm module to fetch
> and verify the vbios image on UEFI systems.
>
> Signed-off-by: Alex Deucher
> Cc: stable at vger.ke
1 - 100 of 111 matches
Mail list logo
