https://bugs.freedesktop.org/show_bug.cgi?id=64201
--- Comment #3 from Tom Stellard ---
Created attachment 78831
--> https://bugs.freedesktop.org/attachment.cgi?id=78831&action=edit
Possible fix
This patch should fix the error you were seeing with pyrit. However, it's
possible you will now se
l/attachments/20130503/27fee9c6/attachment.html>
se:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130503/07374dc8/attachment.html>
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130503/d9c81eca/attachment-0001.html>
On Fri, May 3, 2013 at 10:31 PM, Josh Boyer wrote:
> OK. Git bisect tells me this:
>
> 57c219633275c7e7413f8bc7be250dc092887458 is the first bad commit
> commit 57c219633275c7e7413f8bc7be250dc092887458
> Author: Daniel Vetter
> Date: Thu Apr 4 17:19:37 2013 +0200
>
> drm/i915: revert eDP b
https://bugs.freedesktop.org/show_bug.cgi?id=63973
Bryan Quigley changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130503/f8840e92/attachment.html>
||spamjunkeater at gmail.com
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130503/6b0b0eeb/attachment.html>
|normal |critical
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130503/983c20cf/attachment-0001.html>
ing this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130503/d401ebf7/attachment.html>
On Fri, May 03, 2013 at 10:40:17PM +0200, Daniel Vetter wrote:
>On Fri, May 3, 2013 at 10:31 PM, Josh Boyer wrote:
>> OK. Git bisect tells me this:
>>
>> 57c219633275c7e7413f8bc7be250dc092887458 is the first bad commit
>> commit 57c219633275c7e7413f8bc7be250dc092887458
>> Author: Daniel Vetter
>
--
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130503/4191ee90/attachment.html>
assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130503/4f74316f/attachment.html>
ing this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130503/52ebd64b/attachment.html>
part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130503/3c89e615/attachment.html>
radeon currently uses a drm function to get the speed capabilities for
the bus, drm_pcie_get_speed_cap_mask. However, this is a non-standard
method of performing this detection and this patch changes it to use
the max_bus_speed attribute.
From: Lucas Kannebley Tavares
Signed-off-by: Kleber Sacilo
On pseries machines the detection for max_bus_speed should be done
through an OpenFirmware property. This patch adds a function to perform
this detection and a hook to perform dynamic adding of the function only
for pseries. This is done by overwriting the weak
pcibios_root_bridge_prepare function
This v5 of the patch series is based on v4 sent by Lucas Kannebley Tavares
with a few changes:
1. Fix a compilation warning on the code from the first patch, where it was
missing a declaration of struct pci_host_bridge, used on the definition of
the function pointer pcibios_root_bridge_prepare()
assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130503/e646a8a7/attachment.html>
On Fri, May 03, 2013 at 03:03:37PM +0300, Jani Nikula wrote:
> On Fri, 03 May 2013, Daniel Vetter wrote:
> > On Fri, May 03, 2013 at 11:17:42AM +0200, dl9pf at gmx.de wrote:
> >> From: Jan-Simon M?ller
> >>
> >> Description:
> >> intel_gmbus_is_forced_bit is no extern as its body is right below.
On Fri, May 3, 2013 at 4:39 PM, Josh Boyer wrote:
> On Fri, May 03, 2013 at 02:25:57AM +0100, Dave Airlie wrote:
>>The following changes since commit b6a9b7f6b1f21735a7456d534dc0e68e61359d2c:
>>
>> mm: prevent mmap_cache race in find_vma() (2013-04-04 11:46:28 -0700)
>>
>>are available in the git
ttp://lists.freedesktop.org/archives/dri-devel/attachments/20130503/2e0be31d/attachment.html>
On Fri, 2013-05-03 at 19:43 -0300, Kleber Sacilotto de Souza wrote:
> This patch series does:
> 1. max_bus_speed is used to set the device to gen2 speeds
> 2. on power there's no longer a conflict between the pseries call and other
> architectures, because the overwrite is done via a ppc_md ho
node_put(pdn);
I think you need the of_node_put() in the body of the loop, otherwise
aren't you leaking refcounts?
Yours Tony
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL:
On Fri, May 03, 2013 at 12:57:20PM -0400, Josh Boyer wrote:
>On Fri, May 03, 2013 at 06:08:52PM +0200, Daniel Vetter wrote:
>>On Fri, May 3, 2013 at 4:39 PM, Josh Boyer wrote:
>>> On Fri, May 03, 2013 at 02:25:57AM +0100, Dave Airlie wrote:
The following changes since commit b6a9b7f6b1f21735a7
https://bugs.freedesktop.org/show_bug.cgi?id=64201
--- Comment #2 from Tom Stellard ---
For pyrit it looks like we aren't handling one of the intrinsics produced by
the AMDILPeephole optimizer, but can you still post the output with the
RADEON_DEBUG=cs env variable set.
Do you have a link to whe
attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130503/0fd86375/attachment.html>
The old code allowed very strange memory types. Now it works like
all the other video drivers: ioremap_wc is used unconditionally,
and MTRRs are set if PAT is unavailable (unless MTRR is disabled
by a module parameter).
UC, WB, and WT support is gone. If there are MTRR conflicts that prevent
add
Signed-off-by: Andy Lutomirski
---
drivers/gpu/drm/radeon/radeon_object.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_object.c
b/drivers/gpu/drm/radeon/radeon_object.c
index d3aface..01d4906 100644
--- a/drivers/gpu/drm/radeon/radeon_obj
i915 open-coded logic that was essentially equivalent to the new
drm_mtrr_{add,del}_wc.
Signed-off-by: Andy Lutomirski
---
drivers/gpu/drm/i915/i915_dma.c | 43 ++---
1 file changed, 6 insertions(+), 37 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_dma.
Signed-off-by: Andy Lutomirski
---
drivers/gpu/drm/drm_pci.c | 8
drivers/gpu/drm/drm_stub.c | 10 ++
2 files changed, 6 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/drm_pci.c b/drivers/gpu/drm/drm_pci.c
index bd719e9..3628683 100644
--- a/drivers/gpu/drm/drm_pc
Signed-off-by: Andy Lutomirski
---
This needs careful review. I don't really know what this code does, nor
do I have the hardware. (I don't understand AGP and the associated
caching implications.)
drivers/gpu/drm/drm_bufs.c | 11 ---
drivers/gpu/drm/drm_vm.c | 13 +++--
2 fi
This replaces drm_mtrr_{add,del} with drm_mtrr_{add,del}_wc. The
interface is simplified (because the base and size parameters to
drm_mtrr_del never did anything) and it uses
mtrr_{add,del}_wc_if_needed to avoid allocating MTRRs on systems
that don't need them.
Signed-off-by: Andy Lutomirski
---
These MTRR helpers add a WC MTRR if PAT is disabled. Modern drivers should
be using ioremap_wc, etc. to get WC memory; the MTRR is just a fallback
if the system doesn't have PAT. So, rather than allocating an unnecessary
MTRR even on PAT systems and having error handling spread out and handled
di
A fair number of drivers (mostly graphics) add write-combining MTRRs.
Most ignore errors and most add the MTRR even on PAT systems which don't
need to use MTRRs.
This series adds new functions mtrr_{add,del}_wc_if_needed and
drm_mtrr_{add,del}_wc that report errors and do nothing if PAT is
enabled
https://bugs.freedesktop.org/show_bug.cgi?id=64193
--- Comment #3 from Andy Furniss ---
Created attachment 78828
--> https://bugs.freedesktop.org/attachment.cgi?id=78828&action=edit
R600_DEBUG=vs,ps,fs glxgears rendering dark on packetize commit
--
You are receiving this mail because:
You are
https://bugs.freedesktop.org/show_bug.cgi?id=64193
--- Comment #2 from Andy Furniss ---
Created attachment 78827
--> https://bugs.freedesktop.org/attachment.cgi?id=78827&action=edit
R600_DEBUG=vs,ps,fs glxgears working before packetize commit
--
You are receiving this mail because:
You are th
radeon currently uses a drm function to get the speed capabilities for
the bus, drm_pcie_get_speed_cap_mask. However, this is a non-standard
method of performing this detection and this patch changes it to use
the max_bus_speed attribute.
From: Lucas Kannebley Tavares
Signed-off-by: Kleber Sacilo
On pseries machines the detection for max_bus_speed should be done
through an OpenFirmware property. This patch adds a function to perform
this detection and a hook to perform dynamic adding of the function only
for pseries. This is done by overwriting the weak
pcibios_root_bridge_prepare function
This v5 of the patch series is based on v4 sent by Lucas Kannebley Tavares
with a few changes:
1. Fix a compilation warning on the code from the first patch, where it was
missing a declaration of struct pci_host_bridge, used on the definition of
the function pointer pcibios_root_bridge_prepare()
--
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130503/3731aa77/attachment.html>
https://bugs.freedesktop.org/show_bug.cgi?id=64201
--- Comment #1 from vincent ---
Can you post the output with R600_DEBUG=cs env var set ?
--
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@
https://bugs.freedesktop.org/show_bug.cgi?id=64201
Erdem U. Altinyurt changed:
What|Removed |Added
Severity|critical|blocker
CC|
On Fri, 03 May 2013, Daniel Vetter wrote:
> On Fri, May 03, 2013 at 11:17:42AM +0200, dl9pf at gmx.de wrote:
>> From: Jan-Simon M?ller
>>
>> Description:
>> intel_gmbus_is_forced_bit is no extern as its body is right below.
>> Likewise for intel_gmbus_is_port_valid.
>>
>> This fixes a compilati
https://bugs.freedesktop.org/show_bug.cgi?id=64201
Erdem U. Altinyurt changed:
What|Removed |Added
OS|other |Linux (All)
Severity|norm
https://bugs.freedesktop.org/show_bug.cgi?id=64201
Priority: medium
Bug ID: 64201
Assignee: dri-devel@lists.freedesktop.org
Summary: OpenCL usage result segmentation fault on r600g with
HD6850.
Severity: normal
Classifica
https://bugs.freedesktop.org/show_bug.cgi?id=62976
--- Comment #8 from Alex Deucher ---
This should be fixed in 3.10 and the patches will show up in the 3.9 stable
series shortly thereafter.
--
You are receiving this mail because:
You are the assignee for the bug.
__
https://bugs.freedesktop.org/show_bug.cgi?id=52360
David "okias" Heidelberger changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution
https://bugs.freedesktop.org/show_bug.cgi?id=62976
--- Comment #7 from David "okias" Heidelberger ---
(In reply to comment #6)
> Can you try attachment 77441 [details] [review] as well?
is that or similiar patch pushed into kernel mainline 3.9.0?
Thank you
--
You are receiving this mail becau
Hi Sean,
On Mon, Apr 29, 2013 at 10:28 PM, Sean Paul wrote:
> On Mon, Apr 29, 2013 at 10:50 AM, Rahul Sharma
> wrote:
>> hdmiphy hardware block is a physically separate device. Hdmiphy driver
>> is glued inside hdmi driver and acessed through hdmi callbacks. With
>> increasing diversities in th
On Fri, May 3, 2013 at 10:31 PM, Josh Boyer wrote:
> OK. Git bisect tells me this:
>
> 57c219633275c7e7413f8bc7be250dc092887458 is the first bad commit
> commit 57c219633275c7e7413f8bc7be250dc092887458
> Author: Daniel Vetter
> Date: Thu Apr 4 17:19:37 2013 +0200
>
> drm/i915: revert eDP b
https://bugs.freedesktop.org/show_bug.cgi?id=64193
--- Comment #1 from vincent ---
Can you post the output of glxgears with R600_DEBUG=vs,ps,fs environment
variable, before and after this commit ?
--
You are receiving this mail because:
You are the assignee for the bug.
On Fri, May 03, 2013 at 06:08:52PM +0200, Daniel Vetter wrote:
>On Fri, May 3, 2013 at 4:39 PM, Josh Boyer wrote:
>> On Fri, May 03, 2013 at 02:25:57AM +0100, Dave Airlie wrote:
>>>The following changes since commit b6a9b7f6b1f21735a7456d534dc0e68e61359d2c:
>>>
>>> mm: prevent mmap_cache race in
On Fri, May 3, 2013 at 4:25 AM, Rahul Sharma wrote:
> Hi Sean,
>
> On Mon, Apr 29, 2013 at 10:28 PM, Sean Paul wrote:
>> On Mon, Apr 29, 2013 at 10:50 AM, Rahul Sharma
>> wrote:
>>> hdmiphy hardware block is a physically separate device. Hdmiphy driver
>>> is glued inside hdmi driver and acesse
On Fri, May 3, 2013 at 2:04 AM, Rahul Sharma wrote:
> On Mon, Apr 29, 2013 at 10:06 PM, Sean Paul wrote:
>> On Mon, Apr 29, 2013 at 10:50 AM, Rahul Sharma
>> wrote:
>>> Exynos hdmi sub-system consists of mixer, hdmi ip, hdmi-phy and hdmi-ddc
>>> components. Currently, drivers for these componen
On Mon, Apr 29, 2013 at 10:06 PM, Sean Paul wrote:
> On Mon, Apr 29, 2013 at 10:50 AM, Rahul Sharma
> wrote:
>> Exynos hdmi sub-system consists of mixer, hdmi ip, hdmi-phy and hdmi-ddc
>> components. Currently, drivers for these components are getting registered
>> in exynos_drm_drv.c, which is
https://bugs.freedesktop.org/show_bug.cgi?id=64193
Priority: medium
Bug ID: 64193
CC: v...@ovi.com
Assignee: dri-devel@lists.freedesktop.org
Summary: LLVM RV670 regression since R600: Packetize
instructions
Se
On Fri, May 03, 2013 at 11:17:42AM +0200, dl9pf at gmx.de wrote:
> From: Jan-Simon M?ller
>
> Description:
> intel_gmbus_is_forced_bit is no extern as its body is right below.
> Likewise for intel_gmbus_is_port_valid.
>
> This fixes a compilation issue with clang. An initial version of this patc
From: Jan-Simon M?ller
Description:
intel_gmbus_is_forced_bit is no extern as its body is right below.
Likewise for intel_gmbus_is_port_valid.
This fixes a compilation issue with clang. An initial version of this patch
was developed by PaX Team .
This is respin of this patch.
Signed-off-by: Jan
On Fri, May 03, 2013 at 02:25:57AM +0100, Dave Airlie wrote:
>The following changes since commit b6a9b7f6b1f21735a7456d534dc0e68e61359d2c:
>
> mm: prevent mmap_cache race in find_vma() (2013-04-04 11:46:28 -0700)
>
>are available in the git repository at:
>
> git://people.freedesktop.org/~airlied
K?nig ---
Thx for testing.
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130503/d4efd132/attachment.html>
org/archives/dri-devel/attachments/20130503/efe4bf86/attachment.html>
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130503/7f05c41c/attachment.html>
for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130503/6874f8d0/attachment.html>
https://bugs.freedesktop.org/show_bug.cgi?id=48694
Andreas Boll changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
On Thu, 2 May 2013 21:29:36 -0400, Dennis New wrote:
> I'm currently running 3.9.0, and the bootup process hangs/locks my
> machine before the init stage is reached, unless I specify
> radeon.modeset=0. But modesetting /does/ work if I load the radeon
> module with modeset=1 after the kernel loads.
On Fri, May 3, 2013 at 4:25 AM, Rahul Sharma wrote:
> Hi Sean,
>
> On Mon, Apr 29, 2013 at 10:28 PM, Sean Paul wrote:
>> On Mon, Apr 29, 2013 at 10:50 AM, Rahul Sharma
>> wrote:
>>> hdmiphy hardware block is a physically separate device. Hdmiphy driver
>>> is glued inside hdmi driver and acesse
|--- |FIXED
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130503/7355ebf8/attachment.html>
|--- |FIXED
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130503/a3041e34/attachment.html>
On Fri, May 03, 2013 at 03:03:37PM +0300, Jani Nikula wrote:
> On Fri, 03 May 2013, Daniel Vetter wrote:
> > On Fri, May 03, 2013 at 11:17:42AM +0200, dl...@gmx.de wrote:
> >> From: Jan-Simon Möller
> >>
> >> Description:
> >> intel_gmbus_is_forced_bit is no extern as its body is right below.
>
On Fri, May 3, 2013 at 4:39 PM, Josh Boyer wrote:
> On Fri, May 03, 2013 at 02:25:57AM +0100, Dave Airlie wrote:
>>The following changes since commit b6a9b7f6b1f21735a7456d534dc0e68e61359d2c:
>>
>> mm: prevent mmap_cache race in find_vma() (2013-04-04 11:46:28 -0700)
>>
>>are available in the git
https://bugs.freedesktop.org/show_bug.cgi?id=43829
--- Comment #24 from Alex Deucher ---
(In reply to comment #23)
> I had a similar problem with my x700 (rv410) radeon, and fixed it with:
> radeontool light off
> radeonreg regset 0x0284 0x1bd34208
> radeonreg regset 0x02d0 0x003c
On 05/03/2013 03:40 AM, Tony Breeds wrote:
> On Thu, May 02, 2013 at 12:21:37PM -0300, Kleber Sacilotto de Souza wrote:
>
>> Hi Tony,
>>
>> It seems Lucas' change is a bit incomplete and is not handling the reference
>> counter to
>> the device_node correctly. Is the following change what you had
On Mon, Apr 29, 2013 at 9:54 PM, Sean Paul wrote:
> On Mon, Apr 29, 2013 at 7:14 AM, Rahul Sharma
> wrote:
>> Exynos hdmi driver is using drm_display_mode for setting timing values
>> for a supported resolution. Conversion to fb_videomode and then comparing
>> with the mixer/hdmi/phy limits is n
https://bugs.freedesktop.org/show_bug.cgi?id=43829
--- Comment #23 from Dennis Nezic ---
I had a similar problem with my x700 (rv410) radeon, and fixed it with:
radeontool light off
radeonreg regset 0x0284 0x1bd34208
radeonreg regset 0x02d0 0x003c00a1
radeonreg regset CL:03 0x0
:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130503/04e8252a/attachment.html>
because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130503/36ac152b/attachment.html>
On Thu, 2 May 2013 21:29:36 -0400, Dennis New wrote:
> I'm currently running 3.9.0, and the bootup process hangs/locks my
> machine before the init stage is reached, unless I specify
> radeon.modeset=0. But modesetting /does/ work if I load the radeon
> module with modeset=1 after the kernel loads.
On Fri, 03 May 2013, Daniel Vetter wrote:
> On Fri, May 03, 2013 at 11:17:42AM +0200, dl...@gmx.de wrote:
>> From: Jan-Simon Möller
>>
>> Description:
>> intel_gmbus_is_forced_bit is no extern as its body is right below.
>> Likewise for intel_gmbus_is_port_valid.
>>
>> This fixes a compilation
On 05/03/2013 03:40 AM, Tony Breeds wrote:
> On Thu, May 02, 2013 at 12:21:37PM -0300, Kleber Sacilotto de Souza wrote:
>
>> Hi Tony,
>>
>> It seems Lucas' change is a bit incomplete and is not handling the reference
>> counter to
>> the device_node correctly. Is the following change what you had
scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130503/642c5a8c/attachment.html>
https://bugs.freedesktop.org/show_bug.cgi?id=64143
Christian König changed:
What|Removed |Added
Status|RESOLVED|CLOSED
--- Comment #3 from Christian K
https://bugs.freedesktop.org/show_bug.cgi?id=56918
--- Comment #11 from madbiologist ---
Any update on this?
--
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://li
https://bugs.freedesktop.org/show_bug.cgi?id=48694
--- Comment #6 from Andreas Boll ---
Created attachment 78804
--> https://bugs.freedesktop.org/attachment.cgi?id=78804&action=edit
Possible patch for removing nouveau build
I could also remove the i915 build if it's requested.
--
You are rec
https://bugs.freedesktop.org/show_bug.cgi?id=48694
--- Comment #5 from Andreas Boll ---
Created attachment 78803
--> https://bugs.freedesktop.org/attachment.cgi?id=78803&action=edit
Possible patch for removing radeon build
--
You are receiving this mail because:
You are the assignee for the b
https://bugs.freedesktop.org/show_bug.cgi?id=64143
Andy Furniss changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://bugs.freedesktop.org/show_bug.cgi?id=64096
Andy Furniss changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
From: Jan-Simon Möller
Description:
intel_gmbus_is_forced_bit is no extern as its body is right below.
Likewise for intel_gmbus_is_port_valid.
This fixes a compilation issue with clang. An initial version of this patch
was developed by PaX Team .
This is respin of this patch.
Signed-off-by: Jan
Hi Linus,
this is the main drm pull request for 3.10.
Wierd bits:
OMAP drm changes required OMAP dss changes, in drivers/video, so I took them in
here.
one more fbcon fix for font handover
VT switch avoidance in pm code
scatterlist helpers for gpu drivers - have acks from akpm
Highlights:
qxl
On Fri, May 03, 2013 at 11:17:42AM +0200, dl...@gmx.de wrote:
> From: Jan-Simon Möller
>
> Description:
> intel_gmbus_is_forced_bit is no extern as its body is right below.
> Likewise for intel_gmbus_is_port_valid.
>
> This fixes a compilation issue with clang. An initial version of this patch
>
Hi Sean,
On Mon, Apr 29, 2013 at 10:28 PM, Sean Paul wrote:
> On Mon, Apr 29, 2013 at 10:50 AM, Rahul Sharma
> wrote:
>> hdmiphy hardware block is a physically separate device. Hdmiphy driver
>> is glued inside hdmi driver and acessed through hdmi callbacks. With
>> increasing diversities in th
https://bugs.freedesktop.org/show_bug.cgi?id=56918
Patrick Ohly changed:
What|Removed |Added
Depends on|63471 |
--
You are receiving this mail because:
https://bugs.freedesktop.org/show_bug.cgi?id=56918
Patrick Ohly changed:
What|Removed |Added
Depends on||63471
--
You are receiving this mail bec
On Thu, May 02, 2013 at 12:21:37PM -0300, Kleber Sacilotto de Souza wrote:
> Hi Tony,
>
> It seems Lucas' change is a bit incomplete and is not handling the reference
> counter to
> the device_node correctly. Is the following change what you had in mind?
Ahh Sorry I expected there would be a fo
Sorry for the following crappy message. I came travelling without my laptop.
Please note that one of my patches implement one shot shrinkers onto of
vmpressure mechanism. It can still be called frequently, because right now it
is called every time userspace would get an event. But at least it wo
Hi Dave,
Here are a few omapdss fixes for 3.10. These are based on top of the earlier
pull request I sent.
The first patch is a compilation fix, the rest implement basic support for
deferred probing. Support for deferred probing is needed when booting with
device tree, as the probing order with D
On Tue, Apr 30, 2013 at 03:00:50PM -0700, Kent Overstreet wrote:
> On Tue, Apr 30, 2013 at 10:53:55PM +0100, Mel Gorman wrote:
> > On Sat, Apr 27, 2013 at 03:19:13AM +0400, Glauber Costa wrote:
> > > diff --git a/drivers/md/bcache/btree.c b/drivers/md/bcache/btree.c
> > > index 03e44c1..8b9c1a6 100
On Wed, May 01, 2013 at 05:26:38PM +0200, Daniel Vetter wrote:
> On Tue, Apr 30, 2013 at 11:53 PM, Mel Gorman wrote:
> > On Sat, Apr 27, 2013 at 03:19:13AM +0400, Glauber Costa wrote:
> >> diff --git a/drivers/gpu/drm/i915/i915_gem.c
> >> b/drivers/gpu/drm/i915/i915_gem.c
> >> index 6be940e..2e44
98 matches
Mail list logo
