2012/11/22 Thierry Reding thierry.red...@avionic-design.de:
On Wed, Nov 21, 2012 at 05:08:12PM +0100, Daniel Vetter wrote:
On Wed, Nov 21, 2012 at 4:47 PM, Thierry Reding
thierry.red...@avionic-design.de wrote:
Oh great, so I copied that table for nothing. Thanks for Cc'ing, I can
reuse
On Thu, Nov 22, 2012 at 09:00:24AM +0100, Rafał Miłecki wrote:
2012/11/22 Thierry Reding thierry.red...@avionic-design.de:
On Wed, Nov 21, 2012 at 05:08:12PM +0100, Daniel Vetter wrote:
On Wed, Nov 21, 2012 at 4:47 PM, Thierry Reding
thierry.red...@avionic-design.de wrote:
Oh great, so I
[ 245.003823] handlers:
[ 245.003838] [a0267050] azx_interrupt [snd_hda_intel]
[ 245.003841] Disabling IRQ #16
Does /proc/interrupts show IRQ 16 being shared between snd_hda_intel
and radeon? If not, this looks like a snd_hda_intel (or another driver
sharing the IRQ) issue.
On 21 November 2012 20:42, Sachin Kamat sachin.ka...@linaro.org wrote:
Hi Dave,
Please ignore this patch.
Please ignore this mail. Sorry for the noise.
--
With warm regards,
Sachin
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
Hi Inki,
On 19 November 2012 15:32, Sachin Kamat sachin.ka...@linaro.org wrote:
On 19 November 2012 15:30, Inki Dae inki@samsung.com wrote:
-Original Message-
From: Sachin Kamat [mailto:sachin.ka...@linaro.org]
Sent: Monday, November 19, 2012 6:56 PM
To: Inki Dae
Cc:
-Original Message-
From: Sachin Kamat [mailto:sachin.ka...@linaro.org]
Sent: Thursday, November 22, 2012 3:13 PM
To: Inki Dae
Cc: dri-devel@lists.freedesktop.org; jy0922.s...@samsung.com;
patc...@linaro.org
Subject: Re: [PATCH 1/1] drm/exynos: Fix potential NULL pointer
-Original Message-
From: Sachin Kamat [mailto:sachin.ka...@linaro.org]
Sent: Thursday, November 22, 2012 5:19 PM
To: Inki Dae
Cc: dri-devel@lists.freedesktop.org; jy0922.s...@samsung.com;
patc...@linaro.org
Subject: Re: [PATCH 1/1] drm/exynos: Fix potential NULL pointer
https://bugzilla.kernel.org/show_bug.cgi?id=43751
--- Comment #4 from wmo...@gmail.com 2012-11-22 08:34:19 ---
Same problem here with 3.6.6 kernel
--
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are watching
Hi Sascha,
On Thursday 22 November 2012 07:20:00 Sascha Hauer wrote:
On Wed, Nov 21, 2012 at 11:02:44PM +0100, Laurent Pinchart wrote:
Hi Steffen,
+
+ htotal = vm-hactive + vm-hfront_porch + vm-hback_porch +
+ vm-hsync_len;
+ vtotal = vm-vactive + vm-vfront_porch +
Those tend to be totally not interesting for end-users, and for
debugging we tend to dump the entire noise anyway by enabling all
debug messages.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=57388
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
drivers/gpu/drm/drm_edid.c |2
On Thu, Nov 22, 2012 at 09:50:10AM +0100, Laurent Pinchart wrote:
Hi Sascha,
On Thursday 22 November 2012 07:20:00 Sascha Hauer wrote:
On Wed, Nov 21, 2012 at 11:02:44PM +0100, Laurent Pinchart wrote:
Hi Steffen,
+
+ htotal = vm-hactive + vm-hfront_porch + vm-hback_porch
On Thursday 22 November 2012 09:53:42 Sascha Hauer wrote:
On Thu, Nov 22, 2012 at 09:50:10AM +0100, Laurent Pinchart wrote:
On Thursday 22 November 2012 07:20:00 Sascha Hauer wrote:
On Wed, Nov 21, 2012 at 11:02:44PM +0100, Laurent Pinchart wrote:
Hi Steffen,
+
+
Hi!
On Wed, Nov 21, 2012 at 09:03:38AM -0600, Rob Herring wrote:
On 11/21/2012 05:52 AM, Thierry Reding wrote:
On Wed, Nov 21, 2012 at 12:48:43PM +0100, Steffen Trumtrar wrote:
Hi!
On Wed, Nov 21, 2012 at 10:12:43AM +, Manjunathappa, Prakash wrote:
Hi Steffen,
On Tue, Nov 20,
The patches have been reordered and the changes suggested by
Takashi Iwai have been worked in.
Egbert Eich (18):
1. Make error handling of EDID extension blocks a bit more fault
tolorant:
* Don't fail when EDID extension blocks cannot be read or memory
cannot be allocated.
* Don't
When we fail to allocate space for EDID extensions we should just
warn, fix up the EDID block count and return the base block instead
of failing.
Signed-off-by: Egbert Eich e...@suse.com
---
drivers/gpu/drm/drm_edid.c |7 +--
1 files changed, 5 insertions(+), 2 deletions(-)
diff --git
There are displays which announce EDID extension blocks in the
Extension Flag of the EDID base block although they are not EDDC
capable (ie. take a segment address at I2C slave address 0x30).
We test this by looking for an EDID header which is only possible
in the base block.
If the segment
EEDID v1.3 mandates map blogs if more than one EDID extension block
is used while in v1.4 they are optional.
If the extension count has been changed (because some extension
blocks were not readable) those map blocks need fixing.
In case of v1.4 or higher we simply eliminate all map blogs as
this
valid_extensions (the number of EDID extensions found to be valid)
can never be block[EDID_EXTENSION_FLAG_OFFSET].
There is no point of reallocating the block in this case: the
extra blocks at the end of the EDID structure will not hurt,
also the implementation of krealloc() will just return the
Signed-off-by: Egbert Eich e...@suse.com
---
drivers/gpu/drm/ast/ast_mode.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/ast/ast_mode.c b/drivers/gpu/drm/ast/ast_mode.c
index 7fc9f72..c27aa8d 100644
--- a/drivers/gpu/drm/ast/ast_mode.c
+++
Consolidate the null_edid_counter and the bad_edid_counter
into EDID error state flags which for the last EDID read
are accessible from user.
Errors are looged it the same error has not been present
in the previous read of the EDID. This will reset the
EDID error status for example when the
Signed-off-by: Egbert Eich e...@suse.com
---
drivers/gpu/drm/mgag200/mgag200_mode.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/mgag200/mgag200_mode.c
b/drivers/gpu/drm/mgag200/mgag200_mode.c
index d3d99a2..f89a0c1 100644
---
Signed-off-by: Egbert Eich e...@suse.com
---
drivers/gpu/drm/gma500/cdv_intel_dp.c|1 +
drivers/gpu/drm/gma500/oaktrail_lvds.c |1 +
drivers/gpu/drm/gma500/psb_intel_modes.c |1 +
3 files changed, 3 insertions(+), 0 deletions(-)
diff --git
EDIDs are an integral concept of connectors, connectors are a concept
of drm core also drm_edid.o is already part of this drm core.
Overridden, 'firmware-supplied' EDIDs should be treated exactly the
same as device supplied ones.
Therefore move drm_edid_load from the helper level to the drm core.
v2: Use offsetof().
Signed-off-by: Egbert Eich e...@suse.com
---
drivers/gpu/drm/drm_edid.c | 16 +---
1 files changed, 9 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 049fa52..9e64069 100644
---
According the the VESA specs there can be up to 254 EEDID extension blocks.
Since we may read the EDID (including extensions) in 10 second intervals to
probe for display hotplugging (at least in cases where no hardware hotplug
detection exists) and I2C transfer is rather slow we may end up
So far it was only possible to load an EDID for a single connector (unless
no connector was specified at all in which case the same EDID file was used
for all).
This patch extends the EDID loader so that EDID files can be specified for
more than one connector. A semicolon is used to separate the
Signed-off-by: Egbert Eich e...@suse.com
---
include/drm/drm_crtc.h |8
include/drm/drm_edid.h |9 +
2 files changed, 9 insertions(+), 8 deletions(-)
diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
index d402b3b..7eed9bd 100644
--- a/include/drm/drm_crtc.h
This patch is a bit cosmetic as the variable size will truncate
the start address anyway but for readability it should be made
explicite that the lowest bit in the EDID block number determines
the I2C start address.
Signed-off-by: Egbert Eich e...@suse.com
---
drivers/gpu/drm/drm_edid.c |2
Firmware supplied EDIDs where fed in in
drm_helper_probe_single_connector_modes()
in place of calling the driver supplied get_modes() function.
This has two problems:
1. Drivers don't call drm_get_edid() only from within get_modes().
2. The get_modes() replacement in drm_load_edid_firmware()
If I2C readout fails for an extension block but we have read a
valid base block, don't fail completely but at least return the
base block.
v2: Make goto target names more telling.
Signed-off-by: Egbert Eich e...@suse.com
---
drivers/gpu/drm/drm_edid.c |7 +--
1 files changed, 5
in drm_edid.c there's now code to fix extension blockmaps if the number
of extensions has changed. This code also rearranges the EDID blocks.
Replace the exisiting EDID rearrange code with a call to this code.
v2: Make adjustments required by patch reordering, add missing memcpy().
On Thu, Nov 22, 2012 at 2:50 PM, Linus Torvalds
torva...@linux-foundation.org wrote:
On Wed, Nov 21, 2012 at 6:34 PM, Dave Airlie airl...@linux.ie wrote:
its vmware/nouveua/radeon/intel/ttm scattered.
Hmm. That's not what I see. I just see nouveau and soem PCI ID addition.
21 files
On Thu, Nov 22, 2012 at 05:22:55AM -0500, Egbert Eich wrote:
There are displays which announce EDID extension blocks in the
Extension Flag of the EDID base block although they are not EDDC
capable (ie. take a segment address at I2C slave address 0x30).
We test this by looking for an EDID
On Thu, Nov 22, 2012 at 10:07:07AM +0100, Laurent Pinchart wrote:
On Thursday 22 November 2012 09:53:42 Sascha Hauer wrote:
On Thu, Nov 22, 2012 at 09:50:10AM +0100, Laurent Pinchart wrote:
On Thursday 22 November 2012 07:20:00 Sascha Hauer wrote:
On Wed, Nov 21, 2012 at 11:02:44PM
On Thu, Nov 22, 2012 at 01:07:28PM +0100, Egbert Eich wrote:
Ville Syrj�l� writes:
On Thu, Nov 22, 2012 at 05:22:55AM -0500, Egbert Eich wrote:
There are displays which announce EDID extension blocks in the
Extension Flag of the EDID base block although they are not EDDC
capable
On Thu, Nov 22, 2012 at 12:18 PM, Henrik Rydberg rydb...@bitmath.se wrote:
My apologies for the long delay in answering, I've somehow mixed up
different bugreports and thought I've sent you a patch to test
already. Anyway, please test
https://patchwork.kernel.org/patch/1728111/
Ville Syrj?l? writes:
Me neither. I just figured it might reduce the chance of false
positives. But if you say that can't happen, I'll take your word
for it.
Regarding memcmp() you are definitely right, I will change the code.
Also the comment is somehow misleading.
On Thu, Nov 22, 2012 at 12:06 PM, 김승우 sw0312@samsung.com wrote:
On 2012년 11월 21일 20:36, Rahul Sharma wrote:
Hi Seung Woo,
Thanks for your inputs. Please find my response below.
On Wed, Nov 21, 2012 at 2:12 PM, 김승우 sw0312@samsung.com wrote:
Hi Rahul,
Control part seems good, and my
Just add the definition according the kernel's copy of drm.h
Signed-off-by: Imre Deak imre.d...@intel.com
---
include/drm/drm.h |1 +
1 file changed, 1 insertion(+)
diff --git a/include/drm/drm.h b/include/drm/drm.h
index a847689..d14b973 100644
--- a/include/drm/drm.h
+++
On Thu, Nov 22, 2012 at 05:23:03AM -0500, Egbert Eich wrote:
According the the VESA specs there can be up to 254 EEDID extension blocks.
Since we may read the EDID (including extensions) in 10 second intervals to
probe for display hotplugging (at least in cases where no hardware hotplug
Ville Syrj?l? writes:
On Thu, Nov 22, 2012 at 05:23:03AM -0500, Egbert Eich wrote:
- /* if there's no extensions, we're done */
+ /* if there are no extensions, we're done - don't bother caching */
if (block[EDID_EXTENSION_FLAG_OFFSET] == 0)
return block;
https://bugzilla.kernel.org/show_bug.cgi?id=50881
Alan a...@lxorguk.ukuu.org.uk changed:
What|Removed |Added
CC||a...@lxorguk.ukuu.org.uk
There are displays which announce EDID extension blocks in the
Extension Flag of the EDID base block although they are not EDDC
capable (ie. take a segment address at I2C slave address 0x30).
We test this by looking for an EDID header which is only possible
in the base block.
If the segment
According the the VESA specs there can be up to 254 EEDID extension blocks.
Since we may read the EDID (including extensions) in 10 second intervals to
probe for display hotplugging (at least in cases where no hardware hotplug
detection exists) and I2C transfer is rather slow we may end up
Consolidate the null_edid_counter and the bad_edid_counter
into EDID error state flags which for the last EDID read
are accessible from user.
Errors are looged it the same error has not been present
in the previous read of the EDID. This will reset the
EDID error status for example when the
Op 21-11-12 14:27, Thomas Hellstrom schreef:
On 11/21/2012 02:12 PM, Maarten Lankhorst wrote:
Op 21-11-12 13:42, Thomas Hellstrom schreef:
On 11/21/2012 12:38 PM, Maarten Lankhorst wrote:
Hey,
Op 20-11-12 16:08, Thomas Hellstrom schreef:
On 11/20/2012 02:13 PM, Maarten Lankhorst wrote:
Op
Add conversion from videomode to drm_display_mode
Signed-off-by: Steffen Trumtrar s.trumt...@pengutronix.de
Reviewed-by: Thierry Reding thierry.red...@avionic-design.de
Acked-by: Thierry Reding thierry.red...@avionic-design.de
Tested-by: Thierry Reding thierry.red...@avionic-design.de
Tested-by:
The struct display_timing is specific to the via subsystem. The naming leads to
collisions with the new struct display_timing, that is supposed to be a shared
struct between different subsystems.
To clean this up, prepend the existing struct with the subsystem it is specific
to.
Signed-off-by:
Add helper to get fb_videomode from devicetree.
Signed-off-by: Steffen Trumtrar s.trumt...@pengutronix.de
Reviewed-by: Thierry Reding thierry.red...@avionic-design.de
Acked-by: Thierry Reding thierry.red...@avionic-design.de
Tested-by: Thierry Reding thierry.red...@avionic-design.de
Tested-by:
Add display_timing structure and the according helper functions. This allows
the description of a display via its supported timing parameters.
Also, add helper functions to convert from display timings to a generic
videomode
structure.
The struct display_timing specifies all needed parameters
Hi!
Changes since v12:
- rename struct display_timing to via_display_timing in via subsystem
- fix refreshrate calculation
- fix const struct * warnings
(reported by: Manjunathappa, Prakash prakash...@ti.com)
- some CodingStyle fixes
-
Add helper to get drm_display_mode from devicetree.
Signed-off-by: Steffen Trumtrar s.trumt...@pengutronix.de
Reviewed-by: Thierry Reding thierry.red...@avionic-design.de
Acked-by: Thierry Reding thierry.red...@avionic-design.de
Tested-by: Thierry Reding thierry.red...@avionic-design.de
Add a function to convert from the generic videomode to a fb_videomode.
Signed-off-by: Steffen Trumtrar s.trumt...@pengutronix.de
Reviewed-by: Thierry Reding thierry.red...@avionic-design.de
Acked-by: Thierry Reding thierry.red...@avionic-design.de
Tested-by: Thierry Reding
This adds support for reading display timings from DT into a struct
display_timings. The of_display_timing implementation supports multiple
subnodes. All children are read into an array, that can be queried.
If no native mode is specified, the first subnode will be used.
For cases, where the
On Thu, Nov 22, 2012 at 09:44:42AM -0500, Egbert Eich wrote:
Consolidate the null_edid_counter and the bad_edid_counter
into EDID error state flags which for the last EDID read
are accessible from user.
Errors are looged it the same error has not been present
in the previous read of the EDID.
Hi Steffen,
On Thursday 22 November 2012 17:00:13 Steffen Trumtrar wrote:
Add helper to get fb_videomode from devicetree.
Signed-off-by: Steffen Trumtrar s.trumt...@pengutronix.de
Reviewed-by: Thierry Reding thierry.red...@avionic-design.de
Acked-by: Thierry Reding
Hi Daniel,
My apologies for the long delay in answering, I've somehow mixed up
different bugreports and thought I've sent you a patch to test
already. Anyway, please test
https://patchwork.kernel.org/patch/1728111/
Tested-by: Henrik Rydberg rydb...@euromail.se
Can you please
Hi Steffen,
On Thursday 22 November 2012 17:00:12 Steffen Trumtrar wrote:
Add a function to convert from the generic videomode to a fb_videomode.
Signed-off-by: Steffen Trumtrar s.trumt...@pengutronix.de
Reviewed-by: Thierry Reding thierry.red...@avionic-design.de
Acked-by: Thierry Reding
Ville Syrj?l? writes:
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index dd0df60..aa9b34d 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -157,6 +157,17 @@ int drm_edid_header_is_valid(const u8 *raw_edid)
}
On Thu, Nov 22, 2012 at 07:28:44PM +0100, Egbert Eich wrote:
Ville Syrj�l� writes:
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index dd0df60..aa9b34d 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -157,6 +157,17 @@ int
Consolidate the null_edid_counter and the bad_edid_counter
into EDID error state flags which for the last EDID read
are accessible from user.
Errors are looged it the same error has not been present
in the previous read of the EDID. This will reset the
EDID error status for example when the
On Fri, Nov 09, 2012 at 09:51:04PM +0530, Rahul Sharma wrote:
This patch set adds provision for composing and sending AVI and AUI
infoframes by exynos drm hdmi driver.
It also adds provision to get CEA Video ID Code through the display mode
which is required for making AVI infoframe.
v2: Adjusted to apply cleanly.
Signed-off-by: Egbert Eich e...@suse.com
---
include/drm/drm_crtc.h |8
include/drm/drm_edid.h |9 +
2 files changed, 9 insertions(+), 8 deletions(-)
diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
index 7a3ccbf..7eed9bd
Instead of using the stride derived from the display mode, use the pitch
associated with the currently active framebuffer. This fixes a bug where
the LCD display content would be skewed when enabling HDMI with a video
mode different from that of the LCD.
Signed-off-by: Thierry Reding
https://bugs.freedesktop.org/show_bug.cgi?id=56405
--- Comment #32 from Michael Dressel mdrs...@t-online.de ---
Created attachment 70453
-- https://bugs.freedesktop.org/attachment.cgi?id=70453action=edit
new bisect log
I started bisecting from the second last bad commit.
I could verify it's
https://bugs.freedesktop.org/show_bug.cgi?id=56405
--- Comment #33 from Michael Dressel mdrs...@t-online.de ---
Created attachment 70454
-- https://bugs.freedesktop.org/attachment.cgi?id=70454action=edit
the patch I used lately
This is a patch I need to apply in order to get at least
Ville Syrj?l? writes:
On Thu, Nov 22, 2012 at 07:28:44PM +0100, Egbert Eich wrote:
Something similar should be done for drm_edid_is_valid() - even if the
driver doesn't bother (for instance because this function is only called
once when the device structures are initialized).
On Thu, Nov 22, 2012 at 7:23 PM, Henrik Rydberg rydb...@euromail.se wrote:
My apologies for the long delay in answering, I've somehow mixed up
different bugreports and thought I've sent you a patch to test
already. Anyway, please test
https://patchwork.kernel.org/patch/1728111/
On 11/22/2012 04:51 PM, Maarten Lankhorst wrote:
Op 21-11-12 14:27, Thomas Hellstrom schreef:
On 11/21/2012 02:12 PM, Maarten Lankhorst wrote:
Op 21-11-12 13:42, Thomas Hellstrom schreef:
On 11/21/2012 12:38 PM, Maarten Lankhorst wrote:
Hey,
Op 20-11-12 16:08, Thomas Hellstrom schreef:
On
Yeah, the utter lack of a vbt fits very nicely, thanks for checking,
I've merged the patch into drm-intel-fixes and will forward it for
inclusion into 3.7 rsn.
Great, thanks. One thing about that patch: if we would ever encounter
a non-zero edp.bpp 3, display_bpc would not be clamped. I
Consolidate the null_edid_counter and the bad_edid_counter
into EDID error state flags which for the last EDID read
are accessible from user.
Errors are looged it the same error has not been present
in the previous read of the EDID. This will reset the
EDID error status for example when the
tree: git://people.freedesktop.org/~danvet/drm-intel.git drm-intel-next-queued
head: 9352dce341352e32a221aabf03f8b7c7b141c96a
commit: 9352dce341352e32a221aabf03f8b7c7b141c96a [31/31] drm/i915: Report the
origin of the LVDS fixed panel mode
config: make ARCH=x86_64 allmodconfig
All
On Thu, Nov 22, 2012 at 10:35:22PM +0100, Krzysztof Mazur wrote:
On Thu, Nov 22, 2012 at 09:17:54PM +0100, Daniel Vetter wrote:
Hi,
Since a dpms ioctl call tends to follow a modeset, this likely only
results in that dpms call enabling the hw again. Can you please add
drm.debug=0xe
https://bugzilla.kernel.org/show_bug.cgi?id=49121
--- Comment #3 from Joseph D. Wagner j...@josephdwagner.info 2012-11-22
21:43:33 ---
Issue appears to be resolved in 3.6.6-1.fc17.x86_64 (gcc version 4.7.2 20120921
(Red Hat 4.7.2-2) (GCC) ).
--
Configure bugmail:
From: Laurent Pinchart laurent.pinchart+rene...@ideasonboard.com
Hi everybody,
Here's the second RFC of what was previously known as the Generic Panel
Framework.
I won't repeat all the background information from the first version here, you
can read it at http://lwn.net/Articles/512363/.
Many
From: Laurent Pinchart laurent.pinchart+rene...@ideasonboard.com
Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
---
drivers/video/Kconfig|1 +
drivers/video/Makefile |1 +
drivers/video/display/Kconfig|4 +
From: Laurent Pinchart laurent.pinchart+rene...@ideasonboard.com
Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
---
drivers/video/display/Kconfig | 13 +++
drivers/video/display/Makefile|1 +
drivers/video/display/panel-dpi.c | 147
From: Laurent Pinchart laurent.pinchart+rene...@ideasonboard.com
Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
---
drivers/video/display/Kconfig|4 +
drivers/video/display/Makefile |1 +
drivers/video/display/mipi-dbi-bus.c | 228
From: Laurent Pinchart laurent.pinchart+rene...@ideasonboard.com
The R61505 is a SYS-80 bus panel controller from Renesas.
Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
---
drivers/video/display/Kconfig|9 +
drivers/video/display/Makefile |1 +
From: Laurent Pinchart laurent.pinchart+rene...@ideasonboard.com
The R61517 is a MIPI DBI panel controller from Renesas.
Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
---
drivers/video/display/Kconfig|9 +
drivers/video/display/Makefile |1 +
[snip]
And NULL pointer checking was already done above like below,
if (overlay_ops overlay_ops-disable)
overlay_ops-disable(manager-dev, zpos);
Correct. But that check is applicable only for that one statement
(overlay_ops-disable(manager-dev, zpos);).
Hi Daniel,
My apologies for the long delay in answering, I've somehow mixed up
different bugreports and thought I've sent you a patch to test
already. Anyway, please test
https://patchwork.kernel.org/patch/1728111/
Tested-by: Henrik Rydberg rydb...@euromail.se
Thanks,
Henrik
This patch adds code for composing AVI and AUI info frames
and send them every VSYNC.
This patch is important for hdmi certification.
Based on exynos-drm-fixes branch of
git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos.git
Signed-off-by: Rahul Sharma rahul.sha...@samsung.com
Hi,
since Linux 3.1 I'm having some problems with i915 driver on HP nc6120
with 915GM chipset. The display goes black after the kernel tries to
blank screen while LID is closed (see steps to reproduce to more detailed
description).
Currently I'm using Linux 3.7-rc6 with KMS enabled and disabled
On Thu, Nov 22, 2012 at 09:17:54PM +0100, Daniel Vetter wrote:
Hi,
Thanks for the report. Now this smells like something which could take
a bit longer to track down, so can you please file this on
bugs.freedesktop.org against DRM - DRI/Intel to ensure that we dont'
loose track of it?
Yes,
On Thu, Nov 22, 2012 at 09:17:54PM +0100, Daniel Vetter wrote:
Hi,
Since a dpms ioctl call tends to follow a modeset, this likely only
results in that dpms call enabling the hw again. Can you please add
drm.debug=0xe to your kernel cmdline and boot into a 3.6 with this
hack applied,
On Thu, Nov 22, 2012 at 07:31:39PM +0100, Laurent Pinchart wrote:
Hi Steffen,
On Thursday 22 November 2012 17:00:12 Steffen Trumtrar wrote:
Add a function to convert from the generic videomode to a fb_videomode.
Signed-off-by: Steffen Trumtrar s.trumt...@pengutronix.de
Reviewed-by:
On Friday 23 November 2012 00:09:49 Steffen Trumtrar wrote:
On Thu, Nov 22, 2012 at 07:31:39PM +0100, Laurent Pinchart wrote:
On Thursday 22 November 2012 17:00:12 Steffen Trumtrar wrote:
Add a function to convert from the generic videomode to a fb_videomode.
Signed-off-by: Steffen
Hi Rahul,
I think this patch is almost ready just except few trivial check.
On 2012년 11월 22일 23:12, Rahul Sharma wrote:
This patch adds code for composing AVI and AUI info frames
and send them every VSYNC.
This patch is important for hdmi certification.
Based on exynos-drm-fixes branch
2012/11/10 Rahul Sharma rahul.sha...@samsung.com
This patch set adds provision for composing and sending AVI and AUI
infoframes by exynos drm hdmi driver.
It also adds provision to get CEA Video ID Code through the display mode
which is required for making AVI infoframe.
Based on
devm_clk_get is device managed and makes error handling and exit code
simpler.
Signed-off-by: Sachin Kamat sachin.ka...@linaro.org
---
drivers/gpu/drm/exynos/exynos_mixer.c | 20 +---
1 files changed, 5 insertions(+), 15 deletions(-)
diff --git
On 22.11.2012 21:37, Thierry Reding wrote:
Instead of using the stride derived from the display mode, use the pitch
associated with the currently active framebuffer. This fixes a bug where
the LCD display content would be skewed when enabling HDMI with a video
mode different from that of the
First 4 patches use devm_* APIs for simpler code and cleanup.
Last one fixes a potential bug.
Series is build tested and based on the exynos-drm-next branch of the
following tree:
git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos.git
Sachin Kamat (5):
drm/exynos: Use
devm_clk_get is device managed and makes error handling and exit code
simpler.
Signed-off-by: Sachin Kamat sachin.ka...@linaro.org
---
drivers/gpu/drm/exynos/exynos_drm_fimd.c |9 ++---
1 files changed, 2 insertions(+), 7 deletions(-)
diff --git
devm_gpio_request is device managed and makes error handling and exit code
simpler.
Signed-off-by: Sachin Kamat sachin.ka...@linaro.org
---
drivers/gpu/drm/exynos/exynos_hdmi.c |8 ++--
1 files changed, 2 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c
devm_clk_get is device managed and makes error handling and exit code
simpler.
Signed-off-by: Sachin Kamat sachin.ka...@linaro.org
---
drivers/gpu/drm/exynos/exynos_drm_g2d.c |4 +---
1 files changed, 1 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_g2d.c
Pointer was being dereferenced after freeing.
Fixes the following error:
drivers/gpu/drm/exynos/exynos_drm_g2d.c:323 g2d_userptr_put_dma_addr() error:
dereferencing freed memory 'g2d_userptr'
Signed-off-by: Sachin Kamat sachin.ka...@linaro.org
---
drivers/gpu/drm/exynos/exynos_drm_g2d.c |2
-Original Message-
From: Sachin Kamat [mailto:sachin.ka...@linaro.org]
Sent: Friday, November 23, 2012 12:42 PM
To: dri-devel@lists.freedesktop.org
Cc: inki@samsung.com; jy0922.s...@samsung.com; airl...@linux.ie;
sachin.ka...@linaro.org; patc...@linaro.org
Subject: [PATCH 1/5]
-Original Message-
From: Sachin Kamat [mailto:sachin.ka...@linaro.org]
Sent: Friday, November 23, 2012 12:42 PM
To: dri-devel@lists.freedesktop.org
Cc: inki@samsung.com; jy0922.s...@samsung.com; airl...@linux.ie;
sachin.ka...@linaro.org; patc...@linaro.org
Subject: [PATCH 2/5]
-Original Message-
From: Sachin Kamat [mailto:sachin.ka...@linaro.org]
Sent: Friday, November 23, 2012 12:42 PM
To: dri-devel@lists.freedesktop.org
Cc: inki@samsung.com; jy0922.s...@samsung.com; airl...@linux.ie;
sachin.ka...@linaro.org; patc...@linaro.org
Subject: [PATCH 3/5]
1 - 100 of 199 matches
Mail list logo
