https://bugs.freedesktop.org/show_bug.cgi?id=64201
--- Comment #55 from Tom Stellard ---
(In reply to comment #54)
> No sorry but it doesn't help.
Sorry, I should have mentioned this will only help with pre-SI GPUs.
--
You are receiving this mail because:
You are the assignee for the bug.
https://bugs.freedesktop.org/show_bug.cgi?id=64201
--- Comment #54 from darkbasic ---
No sorry but it doesn't help.
--
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
ht
https://bugs.freedesktop.org/show_bug.cgi?id=64225
--- Comment #6 from Tom Stellard ---
Created attachment 86763
--> https://bugs.freedesktop.org/attachment.cgi?id=86763&action=edit
Possible Fix
Can you try this patch?
--
You are receiving this mail because:
You are the assignee for the bug.
https://bugzilla.kernel.org/show_bug.cgi?id=61811
--- Comment #20 from Dieter Nützel ---
(In reply to Bjorn Helgaas from comment #17)
> Bruno or Dieter, can you try Jean's patch from the email mentioned in
> comment #16? If v3.12-rc2 + Jean's patch solves the problem, it might save
> you a lot o
https://bugs.freedesktop.org/show_bug.cgi?id=64201
Tom Stellard changed:
What|Removed |Added
Attachment #86004|0 |1
is obsolete|
https://bugs.freedesktop.org/show_bug.cgi?id=69897
--- Comment #5 from Tom Stellard ---
Created attachment 86761
--> https://bugs.freedesktop.org/attachment.cgi?id=86761&action=edit
Fix part 3
Can you try this patch with the other two?
--
You are receiving this mail because:
You are the assi
https://bugzilla.kernel.org/show_bug.cgi?id=61811
--- Comment #19 from Bruno Wolff III ---
I tested the referenced patch on top of vanilla 3.12-rc2 and things work
correctly.
--
You are receiving this mail because:
You are watching the assignee of the bug.
__
https://bugs.freedesktop.org/show_bug.cgi?id=69897
--- Comment #4 from Grigori Goronzy ---
Still fails, but it's getting even further:
LLVM ERROR: Not supported instr:>
--
You are receiving this mail because:
You are the assignee for the bug.
___
https://bugs.freedesktop.org/show_bug.cgi?id=69897
--- Comment #3 from Tom Stellard ---
Created attachment 86760
--> https://bugs.freedesktop.org/attachment.cgi?id=86760&action=edit
Possible Fix Part 2
Try applying this patch along with the first fix.
--
You are receiving this mail because:
https://bugs.freedesktop.org/show_bug.cgi?id=69897
--- Comment #2 from Grigori Goronzy ---
It seems to fix the initial problem, but now I'm getting something else:
PRT: /home/greg/build/llvm/include/llvm/Support/Casting.h:239: typename
cast_retty::ret_type llvm::cast(Y *) [X = llvm::BranchInst,
https://bugs.freedesktop.org/show_bug.cgi?id=69897
--- Comment #1 from Tom Stellard ---
Created attachment 86759
--> https://bugs.freedesktop.org/attachment.cgi?id=86759&action=edit
Possible Fix
Does this patch help?
--
You are receiving this mail because:
You are the assignee for the bug.
_
https://bugs.freedesktop.org/show_bug.cgi?id=69897
Priority: medium
Bug ID: 69897
Assignee: dri-devel@lists.freedesktop.org
Summary: OpenCL kernel fails to compile with R600 LLVM backend
Severity: normal
Classification: Unclassified
https://bugs.freedesktop.org/show_bug.cgi?id=69675
--- Comment #19 from Anssi Hannula ---
(In reply to comment #16)
> + u64 n, d;
> +
> + if (*CTS == 0) {
> + n = (u64)clock * N;
> + d = 128ULL * (u64)freq;
> + *CTS = div64_u64(n, d);
> + *C
https://bugzilla.kernel.org/show_bug.cgi?id=62231
Stuart Foster changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
Return -ENOMEM if the allocation fails.
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/drm_edid.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 1688ff5..830f750 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/dr
https://bugs.freedesktop.org/show_bug.cgi?id=69675
--- Comment #18 from Alex Deucher ---
Created attachment 86741
--> https://bugs.freedesktop.org/attachment.cgi?id=86741&action=edit
patch 3/3
--
You are receiving this mail because:
You are the assignee for the bug.
__
https://bugs.freedesktop.org/show_bug.cgi?id=69675
--- Comment #17 from Alex Deucher ---
Created attachment 86740
--> https://bugs.freedesktop.org/attachment.cgi?id=86740&action=edit
patch 2/3
--
You are receiving this mail because:
You are the assignee for the bug.
__
https://bugs.freedesktop.org/show_bug.cgi?id=69675
Alex Deucher changed:
What|Removed |Added
Attachment #86598|0 |1
is obsolete|
https://bugzilla.kernel.org/show_bug.cgi?id=60791
--- Comment #32 from Alex Deucher ---
It's already upstream:
http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=91f3a6aaf280294b07c05dfe606e6c27b7ba3c72
--
You are receiving this mail because:
You are watching the assignee
https://bugzilla.kernel.org/show_bug.cgi?id=60791
--- Comment #31 from Brian Hall ---
Since we have a patch that fixes the problem, can we get it submitted for 3.12,
or at least 3.12.1?
--
You are receiving this mail because:
You are watching the assignee of the bug.
___
https://bugs.freedesktop.org/show_bug.cgi?id=65611
--- Comment #3 from Pierre Ossman ---
I tried this patch:
diff -up ./src/gallium/drivers/radeon/radeon_uvd.c.vc1
./src/gallium/drivers/radeon/radeon_uvd.c
--- ./src/gallium/drivers/radeon/radeon_uvd.c.vc12013-09-27
23:10:44.292867514 +0200
+
On Fri, Sep 27, 2013 at 7:48 AM, Jani Nikula wrote:
> Detailed cap info at address 80h is not available with DPCD ver
> 1.0. Whether such devices exist in the wild I don't know, but there
> should be no harm done in having the defines for downstream port 0 in
> address 05h.
>
> Signed-off-by: Jani
On Fri, Sep 27, 2013 at 12:01 PM, Jani Nikula wrote:
> None of the DP DPCD helpers need to modify the DPCD.
>
> Signed-off-by: Jani Nikula
Reviewed-by: Alex Deucher
> ---
> drivers/gpu/drm/drm_dp_helper.c | 16
> include/drm/drm_dp_helper.h | 16
> 2
On Fri, Sep 27, 2013 at 1:21 PM, * SAMÍ * wrote:
> Hi Alex,
>
>
> could you just point me to the right location in the driver code to play
> with?
> I am less afraid to play with the driver than to flash my vbios...
> Even though, I promise I won't bother you or complain if I break something
> :-)
On Sat, Sep 28, 2013 at 6:17 AM, Dan Carpenter wrote:
> The test here should be ">= ARRAY_SIZE()" instead of "> ARRAY_SIZE()".
>
> Signed-off-by: Dan Carpenter
> Acked-by: Maarten Lankhorst
> ---
> Somehow this wasn't applied when I sent it earlier.
Sorry about this slipping through the cracks.
On Fri, Sep 27, 2013 at 3:08 PM, Christian König
wrote:
>
> A different story is backing buffers with anonymous system memory. I was
> told that Jerome just recently did a very interesting talk at XDC about it
> (didn't have time to look at it myself).
note that this requires a gpu which can pag
It should be ">=" instead of ">" here. The table->mc_reg_address[]
array has SMC_EVERGREEN_MC_REGISTER_ARRAY_SIZE (16) elements.
Signed-off-by: Dan Carpenter
---
Resend.
diff --git a/drivers/gpu/drm/radeon/btc_dpm.c b/drivers/gpu/drm/radeon/btc_dpm.c
index bab0185..55491e7 100644
--- a/drivers/
The test here should be ">= ARRAY_SIZE()" instead of "> ARRAY_SIZE()".
Signed-off-by: Dan Carpenter
Acked-by: Maarten Lankhorst
---
Somehow this wasn't applied when I sent it earlier.
diff --git a/drivers/gpu/drm/nouveau/nouveau_drm.c
b/drivers/gpu/drm/nouveau/nouveau_drm.c
index c95decf..e11f
On Fri, Sep 27, 2013 at 06:36:05PM +0300, Ville Syrjälä wrote:
> On Fri, Sep 27, 2013 at 12:11:47PM +0100, Damien Lespiau wrote:
> > Daniel noticed that it wasn't very smart to keep using one bit per stereo
> > layout now that we don't have to or them. It's a nice final touch to the new
> > stereo
https://bugs.freedesktop.org/show_bug.cgi?id=65611
--- Comment #2 from Pierre Ossman ---
(In reply to bug 65611 comment #1)
> Well known problem, only VC-1 advanced profile (as found on Blueray disks)
> is supported by the hardware.
If that is the case, wouldn't it be an obvious first fix to rem
Hi Dmitry,
I can't speak for the Intel hardware, but you have a very basic
misunderstanding of how the AMD GPU MMU works.
The MMU just hides the real address of the buffer, so that switching
between different clients just becomes switching between different page
tables. But the memory for ba
Looks good.
Reviewed-by: Todd Previte
On Fri, Sep 27, 2013 at 4:48 AM, Jani Nikula wrote:
> Detailed cap info at address 80h is not available with DPCD ver
> 1.0. Whether such devices exist in the wild I don't know, but there
> should be no harm done in having the defines for downstream port
---
arch/arm/boot/dts/rtsm_ve-motherboard.dtsi | 46
arch/arm/boot/dts/rtsm_ve-v2p-ca15x1-ca7x1.dts |4 +++
2 files changed, 50 insertions(+)
diff --git a/arch/arm/boot/dts/rtsm_ve-motherboard.dtsi
b/arch/arm/boot/dts/rtsm_ve-motherboard.dtsi
index 6d12566..b4e
---
drivers/video/vexpress-dvi.c | 94 +-
1 file changed, 83 insertions(+), 11 deletions(-)
diff --git a/drivers/video/vexpress-dvi.c b/drivers/video/vexpress-dvi.c
index cbcb443..ca0e5bd 100644
--- a/drivers/video/vexpress-dvi.c
+++ b/drivers/video/vexpr
---
drivers/gpu/drm/pl111/pl111_drm.h| 23 +-
drivers/gpu/drm/pl111/pl111_drm_device.c | 374 --
2 files changed, 370 insertions(+), 27 deletions(-)
diff --git a/drivers/gpu/drm/pl111/pl111_drm.h
b/drivers/gpu/drm/pl111/pl111_drm.h
index faf88cb..f81f79e 10
Hi all,
This series patches base on Tom's "Initial drm/kms driver for pl111"[1]
with linaro release 13.07 and migrate the CDFv3 for evaluation.
please notes that I set VGA as default output and tested on RTSM only.
[1] http://lwn.net/Articles/561344/
Cheers,
Show Liu
Show Liu (3):
Add displa
https://bugs.freedesktop.org/show_bug.cgi?id=65611
Christian König changed:
What|Removed |Added
CC||pierre-bugzi...@ossman.eu
--- Comment
https://bugs.freedesktop.org/show_bug.cgi?id=69889
Christian König changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
Hello
I'm new in linux dri development, so please please forgive me if I dont
understand something.
I'm working on my opensource gpu project. I've already implemented software
simulator, and implementation in verilog is 40% complete. Right now I've only 2
problems: LLVM needs to be patched an
https://bugs.freedesktop.org/show_bug.cgi?id=69889
Priority: medium
Bug ID: 69889
Assignee: dri-devel@lists.freedesktop.org
Summary: WMV3/VC-1 garbled output with VDPAU
Severity: normal
Classification: Unclassified
OS: All
On Fri, 2013-09-27 at 14:48 +0300, Jani Nikula wrote:
> We haven't read the downstream port caps for DPCD 1.0, so don't use
> them.
>
> v2: use defines for DPCD 1.0 downstream port types
>
> Signed-off-by: Jani Nikula
I don't know if I've ever seen a DPCD 1.0 device, but the changes make
sense.
On Fri, 27 Sep 2013, Yves-Alexis Perez wrote:
> On ven., 2013-09-27 at 12:20 -0300, Henrique de Moraes Holschuh wrote:
> > Some testing on a *60 (T60,X60...) would also be best, I cannot test
> > this on
> > my T43.
> >
> > Anyway, the code itself looks fine, so:
>
> I can test on T61, would that
https://bugzilla.kernel.org/show_bug.cgi?id=61811
--- Comment #18 from Bruno Wolff III ---
I'll be able to try it tonight or tomorrow.
--
You are receiving this mail because:
You are watching the assignee of the bug.
___
dri-devel mailing list
dri-dev
https://bugs.freedesktop.org/show_bug.cgi?id=69675
--- Comment #15 from Pierre Ossman ---
(In reply to comment #4)
> Something like this:
>
> diff --git a/drivers/gpu/drm/radeon/r600_hdmi.c
> b/drivers/gpu/drm/radeon/r600_hdmi.c
> index b0fa600..f7d2766 100644
> --- a/drivers/gpu/drm/radeon/r600
https://bugs.freedesktop.org/show_bug.cgi?id=69675
--- Comment #14 from Pierre Ossman ---
(In reply to comment #3)
> Created attachment 86598 [details] [review]
> use hw generated cts and n values rather than the sw programmed values
>
> Does this patch help? If not, it may be worth adding some
https://bugzilla.kernel.org/show_bug.cgi?id=62231
--- Comment #3 from Stuart Foster ---
(In reply to Alex Deucher from comment #2)
> In 3.12, hdmi audio is exposed as a connector property so you can enable
> audio on the fly rather than needing to pass radeon.audio=1 to force it on.
> E.g.,
>
>
On Fri, Sep 27, 2013 at 07:01:01PM +0300, Jani Nikula wrote:
> None of the DP DPCD helpers need to modify the DPCD.
>
> Signed-off-by: Jani Nikula
Reviewed-by: Ville Syrjälä
> ---
> drivers/gpu/drm/drm_dp_helper.c | 16
> include/drm/drm_dp_helper.h | 16 -
None of the DP DPCD helpers need to modify the DPCD.
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/drm_dp_helper.c | 16
include/drm/drm_dp_helper.h | 16
2 files changed, 16 insertions(+), 16 deletions(-)
diff --git a/drivers/gpu/drm/drm_dp_helper.c b
Hi Rob,
On Fri, Sep 27, 2013 at 11:28:36AM -0400, Rob Clark wrote:
> But I am not the right one to merge this one. And, well, if there is
> a way to make this work without msm_iommu_get_ctx(), I am interested
> in some hints ;-)
>
> Of the other two, 1/3 looks fine and I'll pull that in. And I'
https://bugzilla.kernel.org/show_bug.cgi?id=61811
Bjorn Helgaas changed:
What|Removed |Added
CC||kh...@linux-fr.org
--- Comment #17 from B
On Fri, Sep 27, 2013 at 12:11:47PM +0100, Damien Lespiau wrote:
> Daniel noticed that it wasn't very smart to keep using one bit per stereo
> layout now that we don't have to or them. It's a nice final touch to the new
> stereo mode API extension that we should fix before committing to it.
Assumin
On Wed, Sep 25, 2013 at 10:49 AM, Joerg Roedel wrote:
> The function msm_iommu_get_ctx() is needed buy the MSM-GPU
> driver with and wiithout IOMMU compiled in. Make the
> function available when no IOMMU driver is there.
>
For this one,
Reviewed-by: Rob Clark
But I am not the right one to mer
On Tue, 24 Sep 2013, Aaron Lu wrote:
> The tpacpi_acpi_handle_locate function makes use of acpi_get_devices to
> locate handle for ACPI video by HID, the problem is, ACPI video node
> doesn't really have HID defined(i.e. no _HID control method is defined
> for video device), so.. that function woul
On Thu, 26 Sep 2013, Aaron Lu wrote:
> I checked the git log for the commit to use tpacpi_acpi_handle_locate to
> locate video controller's ACPI handle, it's:
>
> commit 122f26726b5e16174bf8a707df14be1d93c49d62
> Author: Henrique de Moraes Holschuh
> Date: Mon Aug 9 23:48:18 2010 -0300
Yeah...
https://bugzilla.kernel.org/show_bug.cgi?id=61811
--- Comment #16 from Michel Dänzer ---
Someone who has the necessary powers please reassign according to
https://lists.ozlabs.org/pipermail/linuxppc-dev/2013-September/111758.html .
--
You are receiving this mail because:
You are watching the as
https://bugzilla.kernel.org/show_bug.cgi?id=62231
Alex Deucher changed:
What|Removed |Added
CC||alexdeuc...@gmail.com
--- Comment #2 from
https://bugs.freedesktop.org/show_bug.cgi?id=60182
Michel Dänzer changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://bugs.freedesktop.org/show_bug.cgi?id=69341
--- Comment #10 from Fredrik Höglund ---
The raster backend does all its rendering in an xshm image, so it's likely that
the problem is in the ShmPutImage path.
--
You are receiving this mail because:
You are the assignee for the bug.
_
https://bugs.freedesktop.org/show_bug.cgi?id=60929
Johannes Obermayr changed:
What|Removed |Added
See Also||http://llvm.org/bugs/show_b
On Fri, Sep 27, 2013 at 12:26:59PM +0100, Thomas Wood wrote:
> Signed-off-by: Thomas Wood
Thanks for the series, all pushed with the virtual nod from Ajax on
IRC.
--
Damien
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freede
https://bugzilla.kernel.org/show_bug.cgi?id=62231
--- Comment #1 from Stuart Foster ---
*** Bug 61981 has been marked as a duplicate of this bug. ***
--
You are receiving this mail because:
You are watching the assignee of the bug.
___
dri-devel maili
https://bugzilla.kernel.org/show_bug.cgi?id=62231
Bug ID: 62231
Summary: No HDMI audio (pass through) on ASUS F2A55-M (ATI
Trinity Aruba GPU)
Product: Drivers
Version: 2.5
Kernel Version: 3.12-rc2
Hardware: All
https://bugs.freedesktop.org/show_bug.cgi?id=69805
vincent changed:
What|Removed |Added
Assignee|dri-devel@lists.freedesktop |v...@ovi.com
|.org
https://bugs.freedesktop.org/show_bug.cgi?id=66738
--- Comment #15 from lh ---
linux 3.11.2 without radeon dpm, seems stable now. But still have randomly
freeze problem with dpm on.
--
You are receiving this mail because:
You are the assignee for the bug.
___
On Fri, Sep 27, 2013 at 03:08:27PM +0300, Jani Nikula wrote:
> We have some code duplication related to EDID duplication. Add a helper.
git grep kmemdup.*edid drivers/gpu/drm/ also returns 3 hits in nouveau
here, should anyone be bored.
--
Damien
___
d
https://bugzilla.kernel.org/show_bug.cgi?id=61811
--- Comment #15 from Bruno Wolff III ---
So far I have 26935fb06ee88f1188789807687c03041f3c70d9 as the last known good
commit and 48efe453e6b29561f78a1df55c7f58375259cb8c as the first known bad
commit.
Of the commits there, the most suspicious one
On Fri, Sep 27, 2013 at 12:26:59PM +0100, Thomas Wood wrote:
> Signed-off-by: Thomas Wood
For the series (that fixes 2 embarassing bugs from me and 1 long
standing one that wasn't parsing the last CEA VIC):
Reviewed-by: Damien Lespiau
--
Damien
___
On Fri, Sep 27, 2013 at 03:08:27PM +0300, Jani Nikula wrote:
> We have some code duplication related to EDID duplication. Add a helper.
Lgtm, debated the merits of assuming GFP_KERNEL and inlining, then thought
better of it.
All 3, Reviewed-by: Chris Wilson
-Chris
--
Chris Wilson, Intel Open S
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/intel_dp.c |8 +---
1 file changed, 1 insertion(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 95a3159..aed9d67 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/exynos/exynos_drm_vidi.c |8 ++--
1 file changed, 2 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_vidi.c
b/drivers/gpu/drm/exynos/exynos_drm_vidi.c
index 4400330..26e089f 100644
--- a/drivers/gpu/drm/exynos/ex
We have some code duplication related to EDID duplication. Add a helper.
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/drm_edid.c | 12
include/drm/drm_crtc.h |1 +
2 files changed, 13 insertions(+)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
ind
We haven't read the downstream port caps for DPCD 1.0, so don't use
them.
v2: use defines for DPCD 1.0 downstream port types
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/intel_dp.c | 20 ++--
1 file changed, 14 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm
Detailed cap info at address 80h is not available with DPCD ver
1.0. Whether such devices exist in the wild I don't know, but there
should be no harm done in having the defines for downstream port 0 in
address 05h.
Signed-off-by: Jani Nikula
---
include/drm/drm_dp_helper.h |8
1 fil
Signed-off-by: Thomas Wood
---
edid-decode.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/edid-decode.c b/edid-decode.c
index b710bb5..4265843 100644
--- a/edid-decode.c
+++ b/edid-decode.c
@@ -715,10 +715,11 @@ cea_video_block(unsigned char *x)
unsigned char
Signed-off-by: Thomas Wood
---
edid-decode.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/edid-decode.c b/edid-decode.c
index d3e3118..3830e0c 100644
--- a/edid-decode.c
+++ b/edid-decode.c
@@ -649,7 +649,7 @@ static const char *edid_cea_modes[] = {
"1440x240@60Hz",
Signed-off-by: Thomas Wood
---
edid-decode.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/edid-decode.c b/edid-decode.c
index 3830e0c..b710bb5 100644
--- a/edid-decode.c
+++ b/edid-decode.c
@@ -711,7 +711,7 @@ cea_video_block(unsigned char *x)
int i;
int length =
The kernel shouldn't accept invalid modes, just say No.
Signed-off-by: Damien Lespiau
---
drivers/gpu/drm/drm_crtc.c | 3 +++
include/drm/drm_crtc.h | 2 ++
include/uapi/drm/drm_mode.h | 4
3 files changed, 9 insertions(+)
diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm
Now that the coding of stereo layout has changed from a bit field to an
enum, we need remove that check.
Signed-off-by: Damien Lespiau
---
drivers/gpu/drm/drm_crtc.c | 4
1 file changed, 4 deletions(-)
diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index 807309f..2ce8
This allows us to use fewer bits in the mode structure, leaving room for
future work while allowing more stereo layouts types than we could have
ever dreamt of.
I also exposed the previously private DRM_MODE_FLAG_3D_MASK to set in
stone that we are using 5 bits for the stereo layout enum, reservin
Daniel noticed that it wasn't very smart to keep using one bit per stereo
layout now that we don't have to or them. It's a nice final touch to the new
stereo mode API extension that we should fix before committing to it.
--
Damien
___
dri-devel mailing
On Fri, 27 Sep 2013, Patrik Jakobsson wrote:
>> +#ifdef CONFIG_BACKLIGHT_CLASS_DEVICE
Hi, while at it, you should probably let backlight be built as module:
#if IS_ENABLED(CONFIG_BACKLIGHT_CLASS_DEVICE)
Cheers,
Jani.
--
Jani Nikula, Intel Open Source Technology Center
__
https://bugs.freedesktop.org/show_bug.cgi?id=43829
--- Comment #38 from Vladimir Mityukov ---
I'm not sure if I have the same issue. In particular, I could not find this
error in my dmesg:
..
[drm:radeon_acpi_init] *ERROR* Cannot find a backlight controller
..
But I do have the issue that my lap
Hi Dave,
First feature pull request for 3.13. Highlights:
drm-intel-next-2013-09-21:
- clock state handling rework from Ville
- l3 parity handling fixes for hsw from Ben
- some more watermark improvements from Ville
- ban badly behaved context from Mika
- a few vlv improvements from Jesse
- VGA p
83 matches
Mail list logo
