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
--
Matthew Garrett | mj...@srcf.ucam.org
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
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
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 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
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 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.
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
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
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
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
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 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
https://bugs.freedesktop.org/show_bug.cgi?id=53884
Ian Romanick changed:
What|Removed |Added
AssignedTo|dri-devel at lists.freedesktop |mesa-dev at
lists.freedesktop.
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 06:55:53AM -0700, Shirish S wrote:
> Hello Ville Syrj?l?,
>
> On Tue, Aug 21, 2012 at 4:26 AM, Ville Syrj?l? <
> ville.syrjala at 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
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
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 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
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,
lected segment is then immediately read via the
regular DDC2 address using a repeated I2C 'START' signal"
--
> Ville Syrj?l?
> Intel OTC
>
Regards,
Shirish S
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20120821/d4ad3942/attachment.html>
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
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
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 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 | mjg59 at srcf.ucam.org
--
Matthew Garrett | mjg59 at srcf.ucam.org
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
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
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
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
.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>
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
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
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)
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
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, 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
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
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
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
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 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
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
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
ned message part
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20120821/b4d7be94/attachment.pgp>
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
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
> -
https://bugs.freedesktop.org/show_bug.cgi?id=53884
Ian Romanick changed:
What|Removed |Added
AssignedTo|dri-devel@lists.freedesktop |mesa-dev@lists.freedesktop.
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
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
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
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
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
> 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
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
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
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
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
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>
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
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
> >
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
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
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
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
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)
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).
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
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 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, 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 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 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
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
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
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)
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>
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
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>
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 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 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 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
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
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
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
> -
> 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 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
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
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
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/
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 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
>
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
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
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
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
1 - 100 of 111 matches
Mail list logo
