We use __fls() to find the most significant bit. Using that, the
loop can be avoided. A second trick is to use the behaviour of the
rotate instructions to expand the range of the unsigned int to float
conversion to the full 32 bits in a branchless way.
The routine is now exact up to 2^24. Above
This allows gcc to fold duplicate calls into a single call. Since
the current users do actually call it multiple times with the
same arguments, this is an obvious win.
Signed-off-by: Steven Fuerst
---
drivers/gpu/drm/radeon/r600_blit.c |2 +-
drivers/gpu/drm/radeon/r600_blit_shaders
Hi,
Any comments on this series?
Regards
Sachin
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: sy
On Mit, 2012-08-15 at 15:07 -0700, Steven Fuerst wrote:
> Remove the copy of i2f() in r600_blit_kms.c
> We rename the function to something longer now that it is a global
> symbol. This reduces the likelyhood of unintended clashes later.
>
> This might be a candidate for inclusion inside general
On Mon, Jul 30, 2012 at 02:06:55PM +1000, Dave Airlie wrote:
> From: Dave Airlie
>
> We need to call these before we transfer the damaged areas to the device
> not before/after we setup the long lived vmaps.
>
> Signed-off-by: Dave Airlie
As discussed on irc, I've applied this patch here and t
https://bugs.freedesktop.org/show_bug.cgi?id=41265
--- Comment #35 from gy...@gmx.de 2012-08-16 08:39:35 UTC ---
Function radeon_atrm_call() would not be called, because
if (!radeon_atrm_supported(rdev->pdev))
returns false.
Thats because this is returns null:
(!radeon_atpx_priv.atpx_detected)
Signed-off-by: Jakob Bornecrantz
---
drivers/gpu/drm/drm_crtc.c |2 +-
include/drm/drm_mode.h |5 +++--
2 files changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index 08a7aa7..6fbfc24 100644
--- a/drivers/gpu/drm/drm_crtc.c
https://bugs.freedesktop.org/show_bug.cgi?id=41265
--- Comment #36 from Alexander E. Patrakov 2012-08-16
09:26:59 UTC ---
OK. So the bug is that the Sony BIOS provides ATRM, but not ATPX.
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this
https://bugs.freedesktop.org/show_bug.cgi?id=41265
--- Comment #37 from gy...@gmx.de 2012-08-16 10:08:23 UTC ---
I am not sure. In function radeon_atpx_pci_probe_handle() do get the
DEVICE_ACPI_HANDLE:
dhandle = DEVICE_ACPI_HANDLE(&pdev->dev);
It fails with
status = acpi_get_handle(dhandle, "AT
https://bugzilla.kernel.org/show_bug.cgi?id=29372
Alan changed:
What|Removed |Added
Status|NEW |RESOLVED
CC|
https://bugzilla.kernel.org/show_bug.cgi?id=29572
Alan changed:
What|Removed |Added
Status|NEW |RESOLVED
CC|
On Wed, Aug 15, 2012 at 03:18:02PM -0500, Rob Clark wrote:
> From: Andre Renaud
>
> Added support for zorder changes through DRM plane properties
>
> Signed-off-by: Andre Renaud
> Signed-off-by: Rob Clark
> ---
> drivers/staging/omapdrm/omap_drv.h |1 +
> drivers/staging/omapdrm/omap_pl
On Thu, Aug 16, 2012 at 8:00 AM, Ville Syrjälä
wrote:
> On Wed, Aug 15, 2012 at 03:18:02PM -0500, Rob Clark wrote:
>> From: Andre Renaud
>>
>> Added support for zorder changes through DRM plane properties
>>
>> Signed-off-by: Andre Renaud
>> Signed-off-by: Rob Clark
>> ---
>> drivers/staging/o
https://bugs.freedesktop.org/show_bug.cgi?id=41265
--- Comment #38 from Alex Deucher 2012-08-16 14:31:38 UTC ---
Please try the acpi_patches branch of my git tree:
http://cgit.freedesktop.org/~agd5f/linux/
Specifically this patch:
http://cgit.freedesktop.org/~agd5f/linux/commit/?h=acpi_patches&id
On Mon, Aug 13, 2012 at 01:22:35PM +0300, Jani Nikula wrote:
> GMBUS was enabled over bit-banging as the default in commits:
>
> commit c3dfefa0a6d235bd465309e12f4c56ea16e7
> Author: Daniel Vetter
> Date: Tue Feb 14 22:37:25 2012 +0100
>
> drm/i915: reenable gmbus on gen3+ again
>
> a
From: Ville Syrjälä
Make sure we don't access beyond the extension block when parsing CEA
detailed timing descriptors.
Signed-off-by: Ville Syrjälä
Reviewed-by: Alex Deucher
---
drivers/gpu/drm/drm_edid.c |3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/d
From: Ville Syrjälä
There are two slightly different pieces of code for HDMI VSDB
detection. Unify the code into a single helper function.
Also fix a bug where drm_detect_hdmi_monitor() would stop looking
for the HDMI VSDB after the first vendor specific block is found,
whether or not that block
I found these EDID/CEA patches sitting in a branch in my tree. I worked on
them at some point, but forgot about them when something more urgent
came up.
They haven't been tested all that well, mainly because currently there
is no way to test this code, apart from trying on real hardware. If
someon
From: Ville Syrjälä
Make sure drm_detect_hdmi_monitor() and drm_detect_monitor_audio() don't
access beyond the extension block.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/drm_edid.c | 99 ---
1 files changed, 73 insertions(+), 26 deletions(-)
di
From: Ville Syrjälä
The length of HDMI VSDB must be at least 5 bytes. Other than the minimum,
nothing else about the length is specified. Check the length before
accessing any additional field beyond the minimum length.
---
drivers/gpu/drm/drm_edid.c | 33 +
1 f
There's a bug [1] where the faster GMBUS transmissions fail with some
CRTs, and the fix [2] is to fallback to GPIO bit-banging upon errors. As
noted in the bug, the fix still leaves plenty of EDID dumps in dmesg, so
some measures to reduce the EDID error messages would be most welcome.
[1] https:
https://bugs.freedesktop.org/show_bug.cgi?id=41265
--- Comment #39 from Alexander E. Patrakov 2012-08-16
15:16:18 UTC ---
Unfortunately, your specific patch does not apply to the 3.5 kernel, so I
cannot test this quickly. Now downloading your tree.
--
Configure bugmail: https://bugs.freedeskto
https://bugs.freedesktop.org/show_bug.cgi?id=50389
Michel Dänzer changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
https://bugs.freedesktop.org/show_bug.cgi?id=45018
--- Comment #121 from Alexandre Demers
2012-08-16 15:35:45 UTC ---
(In reply to comment #120)
> (In reply to comment #119)
> > (In reply to comment #118)
> >
> > Try the Mesa patches from
> > http://lists.freedesktop.org/archives/mesa-dev/2012-
I've gathered up the various outstanding radeon patches and put them
up in a tree for testing:
http://cgit.freedesktop.org/~agd5f/linux/log/?h=drm-next-3.7-wip
Some of these may end up in -fixes, but most of them are -next
material. I haven't had a chance to go through Christian's last set
of VM p
On Thu, Aug 16, 2012 at 11:13 AM, Jani Nikula
wrote:
>
> There's a bug [1] where the faster GMBUS transmissions fail with some
> CRTs, and the fix [2] is to fallback to GPIO bit-banging upon errors. As
> noted in the bug, the fix still leaves plenty of EDID dumps in dmesg, so
> some measures to re
https://bugs.freedesktop.org/show_bug.cgi?id=53291
Thomas Rohloff changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
https://bugs.freedesktop.org/show_bug.cgi?id=53291
Alex Deucher changed:
What|Removed |Added
Resolution|WORKSFORME |DUPLICATE
--- Comment #3 from Alex Deuche
https://bugs.freedesktop.org/show_bug.cgi?id=45018
Alex Deucher changed:
What|Removed |Added
CC||v10la...@myway.de
--- Comment #122 from A
https://bugs.freedesktop.org/show_bug.cgi?id=41265
--- Comment #40 from Alexander E. Patrakov 2012-08-16
17:05:27 UTC ---
I have built the kernel from your source tree. It found the card, found the
HDMI-connected monitor and displayed boot text messages over it for some time
(until it decided to
https://bugs.freedesktop.org/show_bug.cgi?id=41265
--- Comment #41 from Alexander E. Patrakov 2012-08-16
17:21:59 UTC ---
X works on radeon, too
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee
https://bugzilla.kernel.org/show_bug.cgi?id=44341
Christopher Frömmel changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Kernel Version|3.5.0-
https://bugs.freedesktop.org/show_bug.cgi?id=41265
Alexander E. Patrakov changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
https://bugzilla.kernel.org/show_bug.cgi?id=44341
Christopher Frömmel changed:
What|Removed |Added
Attachment #75071|0 |1
is obsolete|
https://bugzilla.kernel.org/show_bug.cgi?id=44341
Christopher Frömmel changed:
What|Removed |Added
Attachment #75081|0 |1
is obsolete|
https://bugzilla.kernel.org/show_bug.cgi?id=44341
Christopher Frömmel changed:
What|Removed |Added
Attachment #75091|0 |1
is obsolete|
https://bugzilla.kernel.org/show_bug.cgi?id=44341
Christopher Frömmel changed:
What|Removed |Added
Attachment #75121|0 |1
is obsolete|
https://bugs.freedesktop.org/show_bug.cgi?id=41265
--- Comment #42 from Varban 2012-08-16 17:29:16 UTC ---
What settings did you use for the X server config or do the additional monitors
just show as part of the intel card?
Any ideas when this patch will make it in the main line?
Did you try ho
https://bugs.freedesktop.org/show_bug.cgi?id=41265
--- Comment #43 from Alexander E. Patrakov 2012-08-16
17:37:28 UTC ---
The card is a completely separate card. One can create a very old-fashioned
Xinerama-based dual-head setup using this (save as
/etc/X11/xorg.conf.d/60-dualhead.conf):
Secti
https://bugs.freedesktop.org/show_bug.cgi?id=41265
--- Comment #44 from Alexander E. Patrakov 2012-08-16
17:39:18 UTC ---
(In reply to comment #42)
> Any ideas when this patch will make it in the main line?
No idea.
> Did you try hotplugging the media dock rather than boot with it attached?
N
https://bugs.freedesktop.org/show_bug.cgi?id=41265
--- Comment #45 from Alex Deucher 2012-08-16 17:41:59 UTC ---
(In reply to comment #42)
> Any ideas when this patch will make it in the main line?
I've got it tentatively set for 3.7, but if I have time, I'll try and respin
the patches for stabl
From: David L
This is required for pure UEFI systems. The vbios is stored
in ACPI rather than at the legacy vga location.
Fixes:
https://bugs.freedesktop.org/show_bug.cgi?id=26891
Signed-off-by: Alex Deucher
Cc: sta...@vger.kernel.org
---
drivers/gpu/drm/radeon/radeon_bios.c | 59 +
From: Alex Deucher
There are systems that use ATRM, but not ATPX.
Fixes:
https://bugs.freedesktop.org/show_bug.cgi?id=41265
Signed-off-by: Alex Deucher
Cc: sta...@vger.kernel.org
---
drivers/gpu/drm/radeon/radeon.h | 15 -
drivers/gpu/drm/radeon/radeon_atpx_handler.c | 56
https://bugs.freedesktop.org/show_bug.cgi?id=41265
--- Comment #46 from Alex Deucher 2012-08-16 18:23:52 UTC ---
Created attachment 65659
--> https://bugs.freedesktop.org/attachment.cgi?id=65659
fix for all kernels
Here's the patch broken out which should apply to all recent kernels.
--
Conf
On Thu, Aug 16, 2012 at 1:54 PM, wrote:
> From: David L
>
> This is required for pure UEFI systems. The vbios is stored
> in ACPI rather than at the legacy vga location.
>
> Fixes:
> https://bugs.freedesktop.org/show_bug.cgi?id=26891
>
> Signed-off-by: Alex Deucher
Reviewed-by: Jerome Glisse
https://bugs.freedesktop.org/show_bug.cgi?id=41265
--- Comment #47 from Varban 2012-08-16 18:59:13 UTC ---
(In reply to comment #44)
> No, and with the static config above it doesn't make sense. Besides, GPU
> hotplug is not in the current X server.
If the card is separate then I'll probably pla
From: David L
This is required for pure UEFI systems. The vbios is stored
in ACPI rather than at the legacy vga location.
Fixes:
https://bugs.freedesktop.org/show_bug.cgi?id=26891
V2: fix #ifdefs as per Greg's comments
Signed-off-by: Alex Deucher
Cc: sta...@vger.kernel.org
---
drivers/gpu/d
From: Alex Deucher
There are systems that use ATRM, but not ATPX.
Fixes:
https://bugs.freedesktop.org/show_bug.cgi?id=41265
V2: fix #ifdefs as per Greg's comments
Signed-off-by: Alex Deucher
Cc: sta...@vger.kernel.org
---
drivers/gpu/drm/radeon/radeon.h | 15 -
drivers/gpu
On Thu, Aug 16, 2012 at 3:25 PM, Greg KH wrote:
> On Thu, Aug 16, 2012 at 03:13:46PM -0400, alexdeuc...@gmail.com wrote:
>> From: David L
>>
>> This is required for pure UEFI systems. The vbios is stored
>> in ACPI rather than at the legacy vga location.
>>
>> Fixes:
>> https://bugs.freedesktop.
From: David Lamparter
This is required for pure UEFI systems. The vbios is stored
in ACPI rather than at the legacy vga location.
Fixes:
https://bugs.freedesktop.org/show_bug.cgi?id=26891
V2: fix #ifdefs as per Greg's comments
V3: fix it harder
Signed-off-by: Alex Deucher
Reviewed-by: Jerome
From: Alex Deucher
There are systems that use ATRM, but not ATPX.
Fixes:
https://bugs.freedesktop.org/show_bug.cgi?id=41265
V2: fix #ifdefs as per Greg's comments
V3: fix it harder
Signed-off-by: Alex Deucher
Cc: sta...@vger.kernel.org
---
drivers/gpu/drm/radeon/radeon.h | 15
On Thu, Aug 16, 2012 at 3:40 PM, David Lamparter wrote:
> On Thu, Aug 16, 2012 at 03:13:46PM -0400, alexdeuc...@gmail.com wrote:
>> From: David L
> From: David Lamparter
>
> There are still two rough edges left in here, I didn't get around to
> clean it up, other stuff came up -- sorry...
>
>> T
On Thu, Aug 16, 2012 at 03:13:46PM -0400, alexdeuc...@gmail.com wrote:
> From: David L
From: David Lamparter
There are still two rough edges left in here, I didn't get around to
clean it up, other stuff came up -- sorry...
> This is required for pure UEFI systems. The vbios is stored
> in ACPI
https://bugs.freedesktop.org/show_bug.cgi?id=45018
--- Comment #123 from Thomas Rohloff 2012-08-16 20:10:32
UTC ---
(In reply to comment #119)
> (In reply to comment #118)
>
> Try the Mesa patches from
> http://lists.freedesktop.org/archives/mesa-dev/2012-August/025715.html .
Not sure if this
https://bugs.freedesktop.org/show_bug.cgi?id=45018
--- Comment #124 from Thomas Rohloff 2012-08-16 21:03:39
UTC ---
And there are some random rendering issues that wasn't there before the
patches, like using the wrong texture.
Good: http://img713.imageshack.us/img713/492/mcgood.png
Bad: http://
https://bugs.freedesktop.org/show_bug.cgi?id=42373
--- Comment #24 from Erik Hardesty 2012-08-16 21:44:57
UTC ---
I am also experiencing complete display corruption with KMS and my Radeon 6450
HD.
Building an updated kernel with the following commit did not help:
http://git.kernel.org/?p=linux/k
https://bugs.freedesktop.org/show_bug.cgi?id=42373
--- Comment #25 from Alex Deucher 2012-08-16 21:59:05 UTC ---
You might try the 5 patches starting with this one:
http://lists.freedesktop.org/archives/dri-devel/2012-August/026498.html
--
Configure bugmail: https://bugs.freedesktop.org/userpre
Hi Leela.
2012/8/16 Leela Krishna Amudala :
> The name of the exynos drm fimd device is renamed to exynos-drm-fimd
> and two device ids are created for exynos4-fb and exynos5-drm-fimd.
> Also, added driver data for exynos5 to pick the fimd version at runtime and
> to choose the VIDTCON register of
Signed-off-by: Laurent Pinchart
---
drivers/video/Kconfig|1 +
drivers/video/Makefile |1 +
drivers/video/panel/Kconfig |4 +
drivers/video/panel/Makefile |1 +
drivers/video/panel/panel.c | 269 ++
include/video/panel.h
Hi everybody,
While working on DT bindings for the Renesas Mobile SoC display controller
(a.k.a. LCDC) I quickly realized that display panel implementation based on
board code callbacks would need to be replaced by a driver-based panel
framework.
Several driver-based panel support solution alread
Signed-off-by: Laurent Pinchart
---
drivers/video/panel/Kconfig | 11
drivers/video/panel/Makefile |1 +
drivers/video/panel/panel-dummy.c | 103 +
include/video/panel-dummy.h | 25 +
4 files changed, 140 insertions(+), 0
Signed-off-by: Laurent Pinchart
---
drivers/video/panel/Kconfig |4 +
drivers/video/panel/Makefile|1 +
drivers/video/panel/panel-dbi.c | 217 +++
include/video/panel-dbi.h | 92 +
4 files changed, 314 insertions(+), 0 d
The R61505 is a SYS-80 bus panel controller from Renesas.
Signed-off-by: Laurent Pinchart
---
drivers/video/panel/Kconfig|9 +
drivers/video/panel/Makefile |1 +
drivers/video/panel/panel-r61505.c | 520
include/video/panel-r61505.h
The R61517 is a MIPI DBI panel controller from Renesas.
Signed-off-by: Laurent Pinchart
---
drivers/video/panel/Kconfig|9 +
drivers/video/panel/Makefile |1 +
drivers/video/panel/panel-r61517.c | 408
include/video/panel-r61517.h
Hi,
2012/8/16 Leela Krishna Amudala :
> Add device tree based discovery support for DRM-FIMD driver.
>
> Signed-off-by: Leela Krishna Amudala
> ---
> Documentation/devicetree/bindings/fb/drm-fimd.txt | 80 +
> drivers/gpu/drm/exynos/exynos_drm_fimd.c | 95
>
From: Dave Airlie
This turns off the crtc when its been disabled,
fixes it not turning off properly the whole time.
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/udl/udl_modeset.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/udl/udl_modeset.c
b/driver
https://bugs.freedesktop.org/show_bug.cgi?id=45018
--- Comment #125 from Alexandre Demers
2012-08-17 03:00:53 UTC ---
(In reply to comment #124)
> And there are some random rendering issues that wasn't there before the
> patches, like using the wrong texture.
>
> Good: http://img713.imageshack.
https://bugs.freedesktop.org/show_bug.cgi?id=45018
--- Comment #126 from Alexandre Demers
2012-08-17 03:18:27 UTC ---
Good news on my side: I was unable to recreate the bug until now. So I went
with running pilit tests. Sadly, for that part, it still locks (now tracked
under bug 53111).
I won't
https://bugs.freedesktop.org/show_bug.cgi?id=53111
--- Comment #8 from Alexandre Demers 2012-08-17
03:49:31 UTC ---
Is there a way to use apitrace in combination with piglit? I'd like to trace
the problematic test.
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
(Cross post. Yes, I know this is short notice and a short window to
reply. My apologies on that.)
X.Org Book Sprint 2012
Monday Sept 17 & Tuesday Sept 18.
Nürnberg (Nuremberg), Germany.
The X.Org Consortium will hold a book sprint on the Monday and
Tuesday before the Developers Conference
On Mon, Aug 13, 2012 at 09:34:45PM -0700, Keith Packard wrote:
> This is left over from the old PLL sharing code and isn't useful now
> that PLLs are shared when possible.
>
> Signed-off-by: Keith Packard
Queued for -next, thanks for the patch. I'll hold off a bit on the others
until it's a bit c
On Wed, Aug 15, 2012 at 12:32:36PM +0300, Jani Nikula wrote:
> The EDID returned by drm_get_edid() was never freed.
>
> Signed-off-by: Jani Nikula
Picked up for -fixes, thanks for the patch.
-Daniel
--
Daniel Vetter
Mail: daniel at ffwll.ch
Mobile: +41 (0)79 365 57 48
Hi Maarten,
Ok, here comes the promised review (finally!), but it's rather a
high-level thingy. I've mostly thought about how we could create a neat
api with the following points. For a bit of clarity, I've grouped the
different considerations a bit.
Easy Integration
Where I mea
From: Dave Airlie
In order for udl vmap to work properly, we need to push the object
into the CPU domain before we start copying the data to the USB device.
This along with the udl change avoids userspace explicit mapping to
be used.
v2: add a flag for userspace to query to know if Intel kernel
https://bugs.freedesktop.org/show_bug.cgi?id=45018
--- Comment #120 from Alexandre Demers
2012-08-16 00:38:42 UTC ---
(In reply to comment #119)
> (In reply to comment #118)
>
> Try the Mesa patches from
> http://lists.freedesktop.org/archives/mesa-dev/2012-August/025715.html .
Testing right n
On Thu, Aug 16, 2012 at 5:31 AM, Ralf Baechle wrote:
> On Sat, Aug 11, 2012 at 05:32:18PM +0800, Huacai Chen wrote:
>
>> Subject: [PATCH V5 13/18] drm: Define SAREA_MAX for Loongson (PageSize =
>> 16KB).
>
> But your code doesn't define it just for Loongsson as the log message claims
> but rather
On Thu, Aug 16, 2012 at 9:58 AM, Matt Turner wrote:
> On Sat, Aug 11, 2012 at 2:32 AM, Huacai Chen wrote:
>> Signed-off-by: Huacai Chen
>> Signed-off-by: Hongliang Tao
>> Signed-off-by: Hua Yan
>> Cc: dri-devel at lists.freedesktop.org
>> ---
>> include/drm/drm_sarea.h |2 ++
>> 1 files c
Just some intel and nouveau ones this time, intel has more edp panel fixes
for macbooks and nouveau has a suspend/resume regression fix in there.
Dave.
The following changes since commit 7bac6b46607f2f44075cb45dd5b0b4d2e7c80695:
Merge branch 'drm-fixes-3.6' of git://people.freedesktop.org/~a
https://bugs.freedesktop.org/show_bug.cgi?id=41265
--- Comment #34 from Alexander E. Patrakov 2012-08-16
05:34:28 UTC ---
In the acpidump output, there is ATRM method. I will try to add debug printks
to radeon_atrm_call() and report back.
--
Configure bugmail: https://bugs.freedesktop.org/use
Hi,
Any comments on this series?
Regards
Sachin
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: sy
On Mit, 2012-08-15 at 15:07 -0700, Steven Fuerst wrote:
> Remove the copy of i2f() in r600_blit_kms.c
> We rename the function to something longer now that it is a global
> symbol. This reduces the likelyhood of unintended clashes later.
>
> This might be a candidate for inclusion inside general
On Mon, Jul 30, 2012 at 02:06:55PM +1000, Dave Airlie wrote:
> From: Dave Airlie
>
> We need to call these before we transfer the damaged areas to the device
> not before/after we setup the long lived vmaps.
>
> Signed-off-by: Dave Airlie
As discussed on irc, I've applied this patch here and t
https://bugs.freedesktop.org/show_bug.cgi?id=41265
--- Comment #35 from gyhor at gmx.de 2012-08-16 08:39:35 UTC ---
Function radeon_atrm_call() would not be called, because
if (!radeon_atrm_supported(rdev->pdev))
returns false.
Thats because this is returns null:
(!radeon_atpx_priv.atpx_detecte
Signed-off-by: Jakob Bornecrantz
---
drivers/gpu/drm/drm_crtc.c |2 +-
include/drm/drm_mode.h |5 +++--
2 files changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index 08a7aa7..6fbfc24 100644
--- a/drivers/gpu/drm/drm_crtc.c
https://bugs.freedesktop.org/show_bug.cgi?id=41265
--- Comment #36 from Alexander E. Patrakov 2012-08-16
09:26:59 UTC ---
OK. So the bug is that the Sony BIOS provides ATRM, but not ATPX.
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this
https://bugs.freedesktop.org/show_bug.cgi?id=41265
--- Comment #37 from gyhor at gmx.de 2012-08-16 10:08:23 UTC ---
I am not sure. In function radeon_atpx_pci_probe_handle() do get the
DEVICE_ACPI_HANDLE:
dhandle = DEVICE_ACPI_HANDLE(&pdev->dev);
It fails with
status = acpi_get_handle(dhandle,
https://bugzilla.kernel.org/show_bug.cgi?id=29372
Alan changed:
What|Removed |Added
Status|NEW |RESOLVED
CC|
https://bugzilla.kernel.org/show_bug.cgi?id=29572
Alan changed:
What|Removed |Added
Status|NEW |RESOLVED
CC|
On Wed, Aug 15, 2012 at 03:18:02PM -0500, Rob Clark wrote:
> From: Andre Renaud
>
> Added support for zorder changes through DRM plane properties
>
> Signed-off-by: Andre Renaud
> Signed-off-by: Rob Clark
> ---
> drivers/staging/omapdrm/omap_drv.h |1 +
> drivers/staging/omapdrm/omap_pl
On Thu, Aug 16, 2012 at 8:00 AM, Ville Syrj?l?
wrote:
> On Wed, Aug 15, 2012 at 03:18:02PM -0500, Rob Clark wrote:
>> From: Andre Renaud
>>
>> Added support for zorder changes through DRM plane properties
>>
>> Signed-off-by: Andre Renaud
>> Signed-off-by: Rob Clark
>> ---
>> drivers/staging/o
https://bugs.freedesktop.org/show_bug.cgi?id=41265
--- Comment #38 from Alex Deucher 2012-08-16 14:31:38 UTC
---
Please try the acpi_patches branch of my git tree:
http://cgit.freedesktop.org/~agd5f/linux/
Specifically this patch:
http://cgit.freedesktop.org/~agd5f/linux/commit/?h=acpi_patches&i
On Mon, Aug 13, 2012 at 01:22:35PM +0300, Jani Nikula wrote:
> GMBUS was enabled over bit-banging as the default in commits:
>
> commit c3dfefa0a6d235bd465309e12f4c56ea16e7
> Author: Daniel Vetter
> Date: Tue Feb 14 22:37:25 2012 +0100
>
> drm/i915: reenable gmbus on gen3+ again
>
> a
From: Ville Syrj?l?
Make sure we don't access beyond the extension block when parsing CEA
detailed timing descriptors.
Signed-off-by: Ville Syrj?l?
Reviewed-by: Alex Deucher
---
drivers/gpu/drm/drm_edid.c |3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/d
From: Ville Syrj?l?
There are two slightly different pieces of code for HDMI VSDB
detection. Unify the code into a single helper function.
Also fix a bug where drm_detect_hdmi_monitor() would stop looking
for the HDMI VSDB after the first vendor specific block is found,
whether or not that block
I found these EDID/CEA patches sitting in a branch in my tree. I worked on
them at some point, but forgot about them when something more urgent
came up.
They haven't been tested all that well, mainly because currently there
is no way to test this code, apart from trying on real hardware. If
someon
From: Ville Syrj?l?
Make sure drm_detect_hdmi_monitor() and drm_detect_monitor_audio() don't
access beyond the extension block.
Signed-off-by: Ville Syrj?l?
---
drivers/gpu/drm/drm_edid.c | 99 ---
1 files changed, 73 insertions(+), 26 deletions(-)
di
From: Ville Syrj?l?
The length of HDMI VSDB must be at least 5 bytes. Other than the minimum,
nothing else about the length is specified. Check the length before
accessing any additional field beyond the minimum length.
---
drivers/gpu/drm/drm_edid.c | 33 +
1 f
There's a bug [1] where the faster GMBUS transmissions fail with some
CRTs, and the fix [2] is to fallback to GPIO bit-banging upon errors. As
noted in the bug, the fix still leaves plenty of EDID dumps in dmesg, so
some measures to reduce the EDID error messages would be most welcome.
[1] https:
https://bugs.freedesktop.org/show_bug.cgi?id=41265
--- Comment #39 from Alexander E. Patrakov 2012-08-16
15:16:18 UTC ---
Unfortunately, your specific patch does not apply to the 3.5 kernel, so I
cannot test this quickly. Now downloading your tree.
--
Configure bugmail: https://bugs.freedeskto
https://bugs.freedesktop.org/show_bug.cgi?id=50389
Michel D?nzer changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
1 - 100 of 143 matches
Mail list logo
