We don't grab the modeset locks any more since
commit 468174f748603497e73dba9b5c6d1d9f71121486
Author: Daniel Vetter
Date: Tue Dec 11 00:09:12 2012 +0100
drm: push modeset_lock_all into ->fb_create driver callbacks
Reported-by: Ray Strode
Cc: Ray Strode
Cc: Dave Airlie
Signed-off-by: D
On Wed, Mar 27, 2013 at 10:49:10AM +0100, Laurent Pinchart wrote:
> Hi Simon,
>
> On Wednesday 27 March 2013 13:01:43 Simon Horman wrote:
> > On Thu, Mar 14, 2013 at 03:35:46PM +0100, Laurent Pinchart wrote:
> > > Only the DU0 VGA output is currently supported. Support for the DU0 LVDS
> > > and D
2013/3/21 Sachin Kamat :
> drm_add_edid_modes() returns 0 upon failure to find any modes.
> Hence check for 0 and not less than 0.
>
> Signed-off-by: Sachin Kamat
> Cc: Rahul Sharma
> ---
> drivers/gpu/drm/exynos/exynos_drm_connector.c |2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-
2013/3/20 Vikas Sajjan :
> While migrating to common clock framework (CCF), found that the FIMD clocks
> were pulled down by the CCF.
> If CCF finds any clock(s) which has NOT been claimed by any of the
> drivers, then such clock(s) are PULLed low by CCF.
>
> By calling clk_prepare_enable() for FIM
On Wed, Mar 27, 2013 at 05:57:20PM +0200, Ville Syrj?l? wrote:
> On Tue, Mar 19, 2013 at 03:55:50PM +0100, Laurent Pinchart wrote:
> > Extend the -P option to allow specifying the plane x and y offsets. The
> > position is optional, if not specified the plane will be positioned at
> > the center of
On Tue, Mar 19, 2013 at 03:55:50PM +0100, Laurent Pinchart wrote:
> Extend the -P option to allow specifying the plane x and y offsets. The
> position is optional, if not specified the plane will be positioned at
> the center of the screen as before.
>
> Signed-off-by: Laurent Pinchart
> ---
> t
From: Ville Syrj?l?
Properly clip the source when the destination gets clipped
by the pipe dimensions.
Sadly the video sprite hardware is rather limited so it can't do proper
sub-pixel postitioning. Resort to truncating the source coordinates to
(macro)pixel boundary.
The scaling checks are don
From: Ville Syrj?l?
Add a debug function to print the rectangle in a human readable format.
v2: Renamed drm_region to drm_rect, the function from drm_region_debug
to drm_rect_debug_print(), and use %+d instead of +%d in the format.
Signed-off-by: Ville Syrj?l?
---
drivers/gpu/drm/drm_rect
From: Ville Syrj?l?
These functions calculcate the scaling factor based on the source and
destination rectangles.
There are two version of the functions, the strict ones that will
return an error if the min/max scaling factor is exceeded, and the
relaxed versions that will adjust the src/dst rec
From: Ville Syrj?l?
struct drm_rect represents a simple rectangle. The utility
functions are there to help driver writers.
v2: Moved the region stuff into its own file, made the smaller funcs
static inline, used 64bit maths in the scaled clipping function to
avoid overflows (instead it w
Hi Ville,
On Wednesday 27 March 2013 17:57:20 Ville Syrjälä wrote:
> On Tue, Mar 19, 2013 at 03:55:50PM +0100, Laurent Pinchart wrote:
> > Extend the -P option to allow specifying the plane x and y offsets. The
> > position is optional, if not specified the plane will be positioned at
> > the cent
Hi Ville,
On Wednesday 27 March 2013 19:15:31 Ville Syrjälä wrote:
> On Wed, Mar 27, 2013 at 05:57:20PM +0200, Ville Syrjälä wrote:
> > On Tue, Mar 19, 2013 at 03:55:50PM +0100, Laurent Pinchart wrote:
> > > Extend the -P option to allow specifying the plane x and y offsets. The
> > > position is
ttp://lists.freedesktop.org/archives/dri-devel/attachments/20130327/c7bf0607/attachment.html>
On 27 March 2013 16:06, Inki Dae wrote:
> 2013/3/21 Sachin Kamat :
>> drm_add_edid_modes() returns 0 upon failure to find any modes.
>> Hence check for 0 and not less than 0.
>>
>> Signed-off-by: Sachin Kamat
>> Cc: Rahul Sharma
>> ---
>> drivers/gpu/drm/exynos/exynos_drm_connector.c |2 +-
drm_add_edid_modes() returns 0 upon failure to find any modes.
Hence check for 0 and not less than 0.
Signed-off-by: Sachin Kamat
Cc: Rahul Sharma
---
drivers/gpu/drm/exynos/exynos_drm_connector.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/gpu/drm/exynos/e
On Tue, 2013-03-26 at 12:39 -0600, Bjorn Helgaas wrote:
> But we also know pdev is a PCIe device, and I think a PCIe device on a
> root bus must be a "Root Complex Integrated Endpoint" (PCIe spec sec
> 1.3.2.3). Such a device does not have a link at all, so there's no
> point in fiddling with its
Hi,
On 27 March 2013 15:53, Inki Dae wrote:
> 2013/3/20 Vikas Sajjan :
>> While migrating to common clock framework (CCF), found that the FIMD clocks
>> were pulled down by the CCF.
>> If CCF finds any clock(s) which has NOT been claimed by any of the
>> drivers, then such clock(s) are PULLed low
On Wed, Mar 27, 2013 at 03:09:48PM +0100, Laurent Pinchart wrote:
> Hi Ville,
>
> On Wednesday 27 March 2013 13:06:20 Ville Syrj?l? wrote:
> > On Wed, Mar 27, 2013 at 10:19:29AM +0100, Laurent Pinchart wrote:
> > > This format is an odd beast, implemented by Renesas R-Car hardware. It
> > > stores
need remove semicolon, or always return true.
Signed-off-by: Chen Gang
---
drivers/gpu/drm/nouveau/nv50_display.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nv50_display.c
b/drivers/gpu/drm/nouveau/nv50_display.c
index 7f0e6c3..1ddc03e 1
Hi Ville,
On Wednesday 27 March 2013 16:16:26 Ville Syrj?l? wrote:
> On Wed, Mar 27, 2013 at 03:09:48PM +0100, Laurent Pinchart wrote:
> > On Wednesday 27 March 2013 13:06:20 Ville Syrj?l? wrote:
> > > On Wed, Mar 27, 2013 at 10:19:29AM +0100, Laurent Pinchart wrote:
> > > > This format is an odd
On Wed, Mar 27, 2013 at 12:56:37PM +0100, Danny Baumann wrote:
> OK, I see. And there is user space depending on that behaviour? And
> again - how is user space supposed to know about the behavioral
> differences? Is it something like 'if type is raw, don't expect
> anything'?
"Do not rely upon 0
Hi Ville,
On Wednesday 27 March 2013 13:06:20 Ville Syrj?l? wrote:
> On Wed, Mar 27, 2013 at 10:19:29AM +0100, Laurent Pinchart wrote:
> > This format is an odd beast, implemented by Renesas R-Car hardware. It
> > stores RGB 6:6:6 pixels in 32 bits as
> >
> > [31:0] x:R:x:G:x:B:x 8:6:2:6:2:6:2 li
On Wednesday 27 March 2013 01:24 PM, Tomi Valkeinen wrote:
> On 2013-03-26 15:45, Archit Taneja wrote:
>> These are misc fixes and improvements within omapdrm and omapdss. The fixes
>> do the
>> following:
>>
>> - Make omapdrm smarter to choose the right overlay managers as it's crtcs.
>> This
>>
Hi,
Well, the ACPI spec says this (section B.5.2):
"
The OEM may define the number 0 as "Zero brightness" that can mean
to turn off the lighting (e.g. LCD panel backlight) in the device.
This may be useful in the case of an output device that can still be
viewed
We don't grab the modeset locks any more since
commit 468174f748603497e73dba9b5c6d1d9f71121486
Author: Daniel Vetter
Date: Tue Dec 11 00:09:12 2012 +0100
drm: push modeset_lock_all into ->fb_create driver callbacks
Reported-by: Ray Strode
Cc: Ray Strode
Cc: Dave Airlie
Signed-off-by: D
On Wednesday 27 March 2013 01:03 PM, Tomi Valkeinen wrote:
> On 2013-03-26 15:45, Archit Taneja wrote:
>> Increase the DSS_FCLK and DSI_FCLK max supported frequencies, these come
>> because
>> some frequencies were increased from OMAP5 ES1 to OMAP5 ES2. We support only
>> OMAP5 ES2 in the kernel,
On Wed, Mar 27, 2013 at 10:19:29AM +0100, Laurent Pinchart wrote:
> This format is an odd beast, implemented by Renesas R-Car hardware. It
> stores RGB 6:6:6 pixels in 32 bits as
>
> [31:0] x:R:x:G:x:B:x 8:6:2:6:2:6:2 little endian
>
> Signed-off-by: Laurent Pinchart
> ---
>
> Hello,
>
> I cam
On Wednesday 27 March 2013 01:00 PM, Tomi Valkeinen wrote:
> On 2013-03-26 15:45, Archit Taneja wrote:
>> Each version of OMAP has a limitation on the maximum pixel clock frequency
>> supported by an overlay manager. This limit isn't checked by omapdss. Add
>> dispc feats for lcd and tv managers an
On Wednesday 27 March 2013 12:54 PM, Tomi Valkeinen wrote:
> On 2013-03-26 15:45, Archit Taneja wrote:
>> The omapdrm driver requires omapdss panel drivers to expose ops like detect,
>> set_timings and check_timings. These can be NULL for fixed panel DPI, DBI,
>> DSI
>> and SDI drivers. At some pl
On Thu, Mar 14, 2013 at 03:35:46PM +0100, Laurent Pinchart wrote:
> Only the DU0 VGA output is currently supported. Support for the DU0 LVDS
> and DU1 LVDS outputs will require information about the panels that will
> be connected to those outputs.
>
> Signed-off-by: Laurent Pinchart
> ---
> arc
Hi,
>> Well, the ACPI spec says this (section B.5.2):
>>
>> "
>> The OEM may define the number 0 as "Zero brightness" that can mean
>> to turn off the lighting (e.g. LCD panel backlight) in the device.
>> This may be useful in the case of an output device that can still be
>> viewed using only amb
Hi Laurent!
Thanks for the review:
On 27 March 2013 05:38, Laurent Pinchart
wrote:
> Hi Sumit,
>
> Thanks for the patch.
>
> On Monday 25 March 2013 16:50:46 Sumit Semwal wrote:
>> Add debugfs support to make it easier to print debug information
>> about the dma-buf buffers.
>>
>> Cc: Dave Airli
https://bugzilla.kernel.org/show_bug.cgi?id=55811
Summary: [Quadro NVS 5400M] graphic garbage/corruption/noise on
resume
Product: Drivers
Version: 2.5
Kernel Version: 3.7.10-1.1-desktop
Platform: All
OS/Version: Linux
ment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130327/4346d1cd/attachment.html>
On Wed, Mar 27, 2013 at 9:25 AM, Benjamin Herrenschmidt
wrote:
> On Tue, 2013-03-26 at 12:39 -0600, Bjorn Helgaas wrote:
>> But we also know pdev is a PCIe device, and I think a PCIe device on a
>> root bus must be a "Root Complex Integrated Endpoint" (PCIe spec sec
>> 1.3.2.3). Such a device doe
Hi Simon,
On Wednesday 27 March 2013 13:01:43 Simon Horman wrote:
> On Thu, Mar 14, 2013 at 03:35:46PM +0100, Laurent Pinchart wrote:
> > Only the DU0 VGA output is currently supported. Support for the DU0 LVDS
> > and DU1 LVDS outputs will require information about the panels that will
> > be con
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Alex Deucher (1):
radeon: add pci ids for Richland APUs
Ben Widawsky (1):
intel_chipset: Merge intel-gpu-tools chipsets
Benjamin Gaignard (2):
tests: allow tests programs to be installed
tests: allow tests programs to be insta
This format is an odd beast, implemented by Renesas R-Car hardware. It
stores RGB 6:6:6 pixels in 32 bits as
[31:0] x:R:x:G:x:B:x 8:6:2:6:2:6:2 little endian
Signed-off-by: Laurent Pinchart
---
Hello,
I came across this weird format on a Renesas SoC display controller. This is
essentially XRGB
On Wed, Mar 27, 2013 at 05:57:20PM +0200, Ville Syrjälä wrote:
> On Tue, Mar 19, 2013 at 03:55:50PM +0100, Laurent Pinchart wrote:
> > Extend the -P option to allow specifying the plane x and y offsets. The
> > position is optional, if not specified the plane will be positioned at
> > the center of
On Wed, Mar 27, 2013 at 9:25 AM, Benjamin Herrenschmidt
wrote:
> On Tue, 2013-03-26 at 12:39 -0600, Bjorn Helgaas wrote:
>> But we also know pdev is a PCIe device, and I think a PCIe device on a
>> root bus must be a "Root Complex Integrated Endpoint" (PCIe spec sec
>> 1.3.2.3). Such a device doe
> for-3.10/misc_drm_dss
Which of the fixes should go for 3.9? We need those separately, based on
the mainline.
Tomi
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 899 bytes
Desc: OpenPGP digital signature
URL
https://bugs.freedesktop.org/show_bug.cgi?id=62573
Andreas Boll changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
on't think
it's ever very clearly stated, though...
Tomi
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 899 bytes
Desc: OpenPGP digital signature
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130327/4a785c4e/attachment-0001.pgp>
6650,
> .calc_scaling = dispc_ovl_calc_scaling_24xx,
> .calc_core_clk = calc_core_clk_24xx,
> .num_fifos = 3,
OMAP2 has VENC output, but there's no max_tv_pclk above. This would make
VENC pclk check to fail always, wouldn't it?
Tomi
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 899 bytes
Desc: OpenPGP digital signature
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130327/edfa563f/attachment-0001.pgp>
ill be hardcoded, but for much less cases.
Tomi
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 899 bytes
Desc: OpenPGP digital signature
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130327/0bef7539/attachment-0001.pgp>
On Wed, Mar 27, 2013 at 8:56 AM, Danny Baumann wrote:
> Hi,
>
> Well, the ACPI spec says this (section B.5.2):
>
> "
> The OEM may define the number 0 as "Zero brightness" that can mean
> to turn off the lighting (e.g. LCD panel backlight) in the device.
> This may be usefu
On Tue, Mar 19, 2013 at 03:55:50PM +0100, Laurent Pinchart wrote:
> Extend the -P option to allow specifying the plane x and y offsets. The
> position is optional, if not specified the plane will be positioned at
> the center of the screen as before.
>
> Signed-off-by: Laurent Pinchart
> ---
> t
We currently have videomode_from_timing(), which takes one
display_timing entry from display_timings.
To make it easier to use display_timing without display_timings, this
patch renames videomode_from_timing() to videomode_from_timings(), and
adds a new videomode_from_timing() which just converts
Display timing's fields have minimum, typical and maximum values. These
can be accessed by using timing_entry_index enum, and
display_timing_get_value() function.
There's no real need for this extra complexity. The values can be
accessed more easily by just using the min/typ/max fields.
Signed-of
Instead of having plain defines for the videomode's flags, add an enum
for the flags. This makes the flags clearer to use, as the enum tells
which values can be used with the flags field.
Signed-off-by: Tomi Valkeinen
Cc: Steffen Trumtrar
---
include/video/display_timing.h | 28 ++
Both videomode and display_timing contain flags describing the modes.
These are stored in dmt_flags and data_flags. There's no need to
separate these flags, and having separate fields just makes the flags
more difficult to use.
This patch combines the fields and renames VESA_DMT_* flags to
DISPLAY
This patch simplifies videomode related Kconfig and Makefile. After this
patch, there's only one non-user selectable Kconfig option left,
VIDEOMODE_HELPERS. The reasons for the change:
* Videomode helper functions are not something that should be shown in
the kernel configuration options. The re
Hi,
Here's a v2 of the videomode series. The changes compared to v1:
* Dropped "videomode: rename fields", as it received only negative comments
* New patch: "videomode: videomode_from_timing work"
Patches 1-4 are unchanged.
Tomi
Tomi Valkeinen (5):
videomode: simplify videomode Kconfig and
From: Ville Syrjälä
Properly clip the source when the destination gets clipped
by the pipe dimensions.
Sadly the video sprite hardware is rather limited so it can't do proper
sub-pixel postitioning. Resort to truncating the source coordinates to
(macro)pixel boundary.
The scaling checks are don
From: Ville Syrjälä
Add a debug function to print the rectangle in a human readable format.
v2: Renamed drm_region to drm_rect, the function from drm_region_debug
to drm_rect_debug_print(), and use %+d instead of +%d in the format.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/drm_rect
From: Ville Syrjälä
These functions calculcate the scaling factor based on the source and
destination rectangles.
There are two version of the functions, the strict ones that will
return an error if the min/max scaling factor is exceeded, and the
relaxed versions that will adjust the src/dst rec
From: Ville Syrjälä
struct drm_rect represents a simple rectangle. The utility
functions are there to help driver writers.
v2: Moved the region stuff into its own file, made the smaller funcs
static inline, used 64bit maths in the scaled clipping function to
avoid overflows (instead it w
On Wed, Mar 27, 2013 at 7:56 AM, Danny Baumann wrote:
> Hi,
>
>>> Well, the ACPI spec says this (section B.5.2):
>>>
>>> "
>>> The OEM may define the number 0 as "Zero brightness" that can mean
>>> to turn off the lighting (e.g. LCD panel backlight) in the device.
>>> This may be useful in the cas
On Tue, 2013-03-26 at 12:39 -0600, Bjorn Helgaas wrote:
> But we also know pdev is a PCIe device, and I think a PCIe device on a
> root bus must be a "Root Complex Integrated Endpoint" (PCIe spec sec
> 1.3.2.3). Such a device does not have a link at all, so there's no
> point in fiddling with its
omi
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 899 bytes
Desc: OpenPGP digital signature
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130327/56c3da23/attachment-0001.pgp>
On Wed, Mar 27, 2013 at 12:56:37PM +0100, Danny Baumann wrote:
> OK, I see. And there is user space depending on that behaviour? And
> again - how is user space supposed to know about the behavioral
> differences? Is it something like 'if type is raw, don't expect
> anything'?
"Do not rely upon 0
Hi Ville,
On Wednesday 27 March 2013 16:16:26 Ville Syrjälä wrote:
> On Wed, Mar 27, 2013 at 03:09:48PM +0100, Laurent Pinchart wrote:
> > On Wednesday 27 March 2013 13:06:20 Ville Syrjälä wrote:
> > > On Wed, Mar 27, 2013 at 10:19:29AM +0100, Laurent Pinchart wrote:
> > > > This format is an odd
Op 26-03-13 21:29, Marcin Slusarz schreef:
> On Tue, Mar 26, 2013 at 07:29:24AM +0100, Maarten Lankhorst wrote:
>> Op 25-03-13 19:14, Marcin Slusarz schreef:
>>> On Mon, Mar 25, 2013 at 10:22:37AM +0100, Maarten Lankhorst wrote:
Fixes 100% cpu usage when the exit interrupt never got acked.
>>>
On Wed, Mar 27, 2013 at 03:09:48PM +0100, Laurent Pinchart wrote:
> Hi Ville,
>
> On Wednesday 27 March 2013 13:06:20 Ville Syrjälä wrote:
> > On Wed, Mar 27, 2013 at 10:19:29AM +0100, Laurent Pinchart wrote:
> > > This format is an odd beast, implemented by Renesas R-Car hardware. It
> > > stores
Hi Ville,
On Wednesday 27 March 2013 13:06:20 Ville Syrjälä wrote:
> On Wed, Mar 27, 2013 at 10:19:29AM +0100, Laurent Pinchart wrote:
> > This format is an odd beast, implemented by Renesas R-Car hardware. It
> > stores RGB 6:6:6 pixels in 32 bits as
> >
> > [31:0] x:R:x:G:x:B:x 8:6:2:6:2:6:2 li
On Wed, Mar 27, 2013 at 8:56 AM, Danny Baumann wrote:
> Hi,
>
> Well, the ACPI spec says this (section B.5.2):
>
> "
> The OEM may define the number 0 as "Zero brightness" that can mean
> to turn off the lighting (e.g. LCD panel backlight) in the device.
> This may be usefu
On Wed, Mar 27, 2013 at 7:56 AM, Danny Baumann wrote:
> Hi,
>
>>> Well, the ACPI spec says this (section B.5.2):
>>>
>>> "
>>> The OEM may define the number 0 as "Zero brightness" that can mean
>>> to turn off the lighting (e.g. LCD panel backlight) in the device.
>>> This may be useful in the cas
Hi,
Well, the ACPI spec says this (section B.5.2):
"
The OEM may define the number 0 as "Zero brightness" that can mean
to turn off the lighting (e.g. LCD panel backlight) in the device.
This may be useful in the case of an output device that can still be
viewed using only ambient light, for ex
On 27 March 2013 16:06, Inki Dae wrote:
> 2013/3/21 Sachin Kamat :
>> drm_add_edid_modes() returns 0 upon failure to find any modes.
>> Hence check for 0 and not less than 0.
>>
>> Signed-off-by: Sachin Kamat
>> Cc: Rahul Sharma
>> ---
>> drivers/gpu/drm/exynos/exynos_drm_connector.c |2 +-
drm_add_edid_modes() returns 0 upon failure to find any modes.
Hence check for 0 and not less than 0.
Signed-off-by: Sachin Kamat
Cc: Rahul Sharma
---
drivers/gpu/drm/exynos/exynos_drm_connector.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/gpu/drm/exynos/e
Hi,
On 27 March 2013 15:53, Inki Dae wrote:
> 2013/3/20 Vikas Sajjan :
>> While migrating to common clock framework (CCF), found that the FIMD clocks
>> were pulled down by the CCF.
>> If CCF finds any clock(s) which has NOT been claimed by any of the
>> drivers, then such clock(s) are PULLed low
On Wed, Mar 27, 2013 at 10:49:10AM +0100, Laurent Pinchart wrote:
> Hi Simon,
>
> On Wednesday 27 March 2013 13:01:43 Simon Horman wrote:
> > On Thu, Mar 14, 2013 at 03:35:46PM +0100, Laurent Pinchart wrote:
> > > Only the DU0 VGA output is currently supported. Support for the DU0 LVDS
> > > and D
https://bugzilla.kernel.org/show_bug.cgi?id=55811
Summary: [Quadro NVS 5400M] graphic garbage/corruption/noise on
resume
Product: Drivers
Version: 2.5
Kernel Version: 3.7.10-1.1-desktop
Platform: All
OS/Version: Linux
On Wed, Mar 27, 2013 at 10:19:29AM +0100, Laurent Pinchart wrote:
> This format is an odd beast, implemented by Renesas R-Car hardware. It
> stores RGB 6:6:6 pixels in 32 bits as
>
> [31:0] x:R:x:G:x:B:x 8:6:2:6:2:6:2 little endian
>
> Signed-off-by: Laurent Pinchart
> ---
>
> Hello,
>
> I cam
https://bugs.freedesktop.org/show_bug.cgi?id=62756
--- Comment #2 from Andy Furniss ---
(In reply to comment #1)
> (In reply to comment #1)
> > I tried finding a working commit going back with mesa, but I get to a point
> > where llvm renders nothing at all with anything using current llvm svn.
>
2013/3/21 Sachin Kamat :
> drm_add_edid_modes() returns 0 upon failure to find any modes.
> Hence check for 0 and not less than 0.
>
> Signed-off-by: Sachin Kamat
> Cc: Rahul Sharma
> ---
> drivers/gpu/drm/exynos/exynos_drm_connector.c |2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-
2013/3/20 Vikas Sajjan :
> While migrating to common clock framework (CCF), found that the FIMD clocks
> were pulled down by the CCF.
> If CCF finds any clock(s) which has NOT been claimed by any of the
> drivers, then such clock(s) are PULLed low by CCF.
>
> By calling clk_prepare_enable() for FIM
This format is an odd beast, implemented by Renesas R-Car hardware. It
stores RGB 6:6:6 pixels in 32 bits as
[31:0] x:R:x:G:x:B:x 8:6:2:6:2:6:2 little endian
Signed-off-by: Laurent Pinchart
---
Hello,
I came across this weird format on a Renesas SoC display controller. This is
essentially XRGB
Hi Simon,
On Wednesday 27 March 2013 13:01:43 Simon Horman wrote:
> On Thu, Mar 14, 2013 at 03:35:46PM +0100, Laurent Pinchart wrote:
> > Only the DU0 VGA output is currently supported. Support for the DU0 LVDS
> > and DU1 LVDS outputs will require information about the panels that will
> > be con
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Alex Deucher (1):
radeon: add pci ids for Richland APUs
Ben Widawsky (1):
intel_chipset: Merge intel-gpu-tools chipsets
Benjamin Gaignard (2):
tests: allow tests programs to be installed
tests: allow tests programs to be insta
On 2013-03-26 15:45, Archit Taneja wrote:
> These are misc fixes and improvements within omapdrm and omapdss. The fixes
> do the
> following:
>
> - Make omapdrm smarter to choose the right overlay managers as it's crtcs.
> This
> makes sure that omapdrm is functional for OMAP platforms with di
On 2013-03-26 15:45, Archit Taneja wrote:
> Increase the DSS_FCLK and DSI_FCLK max supported frequencies, these come
> because
> some frequencies were increased from OMAP5 ES1 to OMAP5 ES2. We support only
> OMAP5 ES2 in the kernel, so replace the ES1 values with ES2 values. Increase
> the
> DSI
On 2013-03-26 15:45, Archit Taneja wrote:
> Each version of OMAP has a limitation on the maximum pixel clock frequency
> supported by an overlay manager. This limit isn't checked by omapdss. Add
> dispc feats for lcd and tv managers and check whether the target timings can
> be supported or not.
>
On 2013-03-26 15:45, Archit Taneja wrote:
> The omapdrm driver requires omapdss panel drivers to expose ops like detect,
> set_timings and check_timings. These can be NULL for fixed panel DPI, DBI, DSI
> and SDI drivers. At some places, there are no checks to see if the panel
> driver
> has these
need remove semicolon, or always return true.
Signed-off-by: Chen Gang
---
drivers/gpu/drm/nouveau/nv50_display.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nv50_display.c
b/drivers/gpu/drm/nouveau/nv50_display.c
index 7f0e6c3..1ddc03e 1
We currently have videomode_from_timing(), which takes one
display_timing entry from display_timings.
To make it easier to use display_timing without display_timings, this
patch renames videomode_from_timing() to videomode_from_timings(), and
adds a new videomode_from_timing() which just converts
Display timing's fields have minimum, typical and maximum values. These
can be accessed by using timing_entry_index enum, and
display_timing_get_value() function.
There's no real need for this extra complexity. The values can be
accessed more easily by just using the min/typ/max fields.
Signed-of
Instead of having plain defines for the videomode's flags, add an enum
for the flags. This makes the flags clearer to use, as the enum tells
which values can be used with the flags field.
Signed-off-by: Tomi Valkeinen
Cc: Steffen Trumtrar
---
include/video/display_timing.h | 28 ++
Both videomode and display_timing contain flags describing the modes.
These are stored in dmt_flags and data_flags. There's no need to
separate these flags, and having separate fields just makes the flags
more difficult to use.
This patch combines the fields and renames VESA_DMT_* flags to
DISPLAY
This patch simplifies videomode related Kconfig and Makefile. After this
patch, there's only one non-user selectable Kconfig option left,
VIDEOMODE_HELPERS. The reasons for the change:
* Videomode helper functions are not something that should be shown in
the kernel configuration options. The re
Hi,
Here's a v2 of the videomode series. The changes compared to v1:
* Dropped "videomode: rename fields", as it received only negative comments
* New patch: "videomode: videomode_from_timing work"
Patches 1-4 are unchanged.
Tomi
Tomi Valkeinen (5):
videomode: simplify videomode Kconfig and
Hi,
On 2013-03-25 15:36, Rob Clark wrote:
> sorry, was offline for a while (moving), and missed the last email..
>
> I would guess that Tomi would send pull-req for tilcdc and omapdrm.
> Well I suppose I could do it if Tomi can't, although my
> pandas/beagles/beaglebones are not unpacked yet..
W
On Wednesday 27 March 2013 01:24 PM, Tomi Valkeinen wrote:
On 2013-03-26 15:45, Archit Taneja wrote:
These are misc fixes and improvements within omapdrm and omapdss. The fixes do
the
following:
- Make omapdrm smarter to choose the right overlay managers as it's crtcs. This
makes sure that
Hi Sumit,
Thanks for the patch.
On Monday 25 March 2013 16:50:46 Sumit Semwal wrote:
> Add debugfs support to make it easier to print debug information
> about the dma-buf buffers.
>
> Cc: Dave Airlie
> [minor fixes on init and warning fix]
> Signed-off-by: Sumit Semwal
> ---
> changes since
On Wednesday 27 March 2013 01:03 PM, Tomi Valkeinen wrote:
On 2013-03-26 15:45, Archit Taneja wrote:
Increase the DSS_FCLK and DSI_FCLK max supported frequencies, these come because
some frequencies were increased from OMAP5 ES1 to OMAP5 ES2. We support only
OMAP5 ES2 in the kernel, so replace t
On Wednesday 27 March 2013 01:00 PM, Tomi Valkeinen wrote:
On 2013-03-26 15:45, Archit Taneja wrote:
Each version of OMAP has a limitation on the maximum pixel clock frequency
supported by an overlay manager. This limit isn't checked by omapdss. Add
dispc feats for lcd and tv managers and check
On Wednesday 27 March 2013 12:54 PM, Tomi Valkeinen wrote:
On 2013-03-26 15:45, Archit Taneja wrote:
The omapdrm driver requires omapdss panel drivers to expose ops like detect,
set_timings and check_timings. These can be NULL for fixed panel DPI, DBI, DSI
and SDI drivers. At some places, there
97 matches
Mail list logo
