Add standard optinal property blobs for YCbCr to RGB conversion CSC
matrix and YCbCr preoffset vector in DRM planes. New enums are defined
to YCBCR_ENCODING property to activate the CSC and preoffset
properties. For simplicity the new properties are stored in the
drm_plane object, because the YCBCR
Changes since first RFC version:
- Drop already merged
- drm: drm_color_mgmt.h needs struct drm_crtc declaration
- drm: Make drm_atomic_replace_property_blob_from_id() more generic
- Drop omapdrm specific example patches
- I have updated versions, for testing buy they are not relevant here
-
Add a standard optinal property to control YCbCr conversion in DRM
planes. The property is stored to drm_plane object to allow different
set of supported conversion modes for different planes on the device.
Signed-off-by: Jyri Sarha
---
drivers/gpu/drm/drm_atomic.c | 5
drivers/gpu/drm
On 04/25/2017 04:06 AM, hean.loong@intel.com wrote:
> From: "Ong, Hean Loong"
>
> Device tree binding for Intel FPGA Video and Image
> Processing Suite. The binding involved would be generated
> from the Altera (Intel) Qsys system. The bindings would
> set the max width, max height, buts per
On Wed, 03 May 2017 19:04:38 -0700
Keith Packard wrote:
> Pekka Paalanen writes:
>
> > do you mean to list all kinds of display devices in the database? I was
> > assuming it would list only HMDs, so not in database would imply it's a
> > normal display and good for extending the desktop to.
On Wed, Apr 26, 2017 at 01:28:29PM +1000, Dave Airlie wrote:
> +#include
I wonder if Daniel has already split everything used here into its own
headers?
> +#include
> +#include
> +#include
> +
> +#include "drm_internal.h"
> +#include
> +
> +static struct drm_syncobj *drm_syncobj_get(struct d
On Wed, Apr 26, 2017 at 01:28:30PM +1000, Dave Airlie wrote:
> +/**
> + * calc_timeout - calculate jiffies timeout from absolute value
> + *
> + * @timeout_ns: timeout in ns
> + *
> + * Calculate the timeout in jiffies from an absolute timeout in ns.
> + */
> +unsigned long calc_wait_timeout(uint64
On 05/03/2017 10:00 PM, Eric Anholt wrote:
Archit Taneja writes:
Hi,
On 04/27/2017 10:06 PM, Eric Anholt wrote:
Many DRM drivers have common code to make a stub connector
implementation that wraps a drm_panel. By wrapping the panel in a DRM
bridge, all of the connector code (including cal
Am Mittwoch, den 03.05.2017, 18:15 +0100 schrieb Daniel Stone:
> Hi Lucas,
>
> On 3 May 2017 at 17:28, Lucas Stach wrote:
> > int available_pres = ipu_prg_max_active_channels();
> > int i;
> >
> > + /*
> > +* We are going over the planes in 2 passes: first we assign
Hi,
On 4 May 2017 at 09:59, Lucas Stach wrote:
> Am Mittwoch, den 03.05.2017, 18:15 +0100 schrieb Daniel Stone:
>> What about planes which aren't present in this commit, but are still
>> taking up a PRE unit? Will they have their PRE stolen, or am I missing
>> something?
>
> Yes, the plane->PRE a
https://bugs.freedesktop.org/show_bug.cgi?id=100577
--- Comment #2 from Nikola Forró ---
Same problem here. It was definitely working fine several weeks ago.
I'll try to bisect the issue if I'll find reliable reproducer.
--
You are receiving this mail because:
You are the assignee for the bug._
https://bugs.freedesktop.org/show_bug.cgi?id=100577
--- Comment #3 from Nikola Forró ---
Created attachment 131193
--> https://bugs.freedesktop.org/attachment.cgi?id=131193&action=edit
dmesg
--
You are receiving this mail because:
You are the assignee for the bug._
Am Donnerstag, den 04.05.2017, 10:02 +0100 schrieb Daniel Stone:
> Hi,
>
> On 4 May 2017 at 09:59, Lucas Stach wrote:
> > Am Mittwoch, den 03.05.2017, 18:15 +0100 schrieb Daniel Stone:
> >> What about planes which aren't present in this commit, but are still
> >> taking up a PRE unit? Will they h
On Thu, May 4, 2017 at 11:12 AM, Lucas Stach wrote:
> Am Donnerstag, den 04.05.2017, 10:02 +0100 schrieb Daniel Stone:
>> On 4 May 2017 at 09:59, Lucas Stach wrote:
>> > Am Mittwoch, den 03.05.2017, 18:15 +0100 schrieb Daniel Stone:
>> >> What about planes which aren't present in this commit, but
On Wed, May 3, 2017 at 10:28 PM, Eric Anholt wrote:
>> From: Ong Hean Loong
>>
>> Hi,
>>
>> The new Intel Arria10 SOC FPGA devkit has a Display Port IP component
>> which requires a new driver. This is a virtual driver in which the
>> FGPA hardware would enable the Display Port based on the infor
Am 26.04.2017 um 19:00 schrieb Andy Shevchenko:
[SNIP]
+ while (1) {
This raises red flag. Care to refactor?
Also do {} while () syntax allows faster to get that the loop body
goes at least once.
I've tried to refactor this, but couldn't come up with something which
works and is readab
Am Donnerstag, den 04.05.2017, 11:17 +0200 schrieb Daniel Vetter:
> On Thu, May 4, 2017 at 11:12 AM, Lucas Stach wrote:
> > Am Donnerstag, den 04.05.2017, 10:02 +0100 schrieb Daniel Stone:
> >> On 4 May 2017 at 09:59, Lucas Stach wrote:
> >> > Am Mittwoch, den 03.05.2017, 18:15 +0100 schrieb Dani
Hi Jyri,
On 05/04/17 09:14, Jyri Sarha wrote:
> Add a standard optinal property to control YCbCr conversion in DRM
> planes. The property is stored to drm_plane object to allow different
> set of supported conversion modes for different planes on the device.
>
> Signed-off-by: Jyri Sarha
> ---
>
Hi,
On 3 May 2017 at 06:14, Ben Widawsky wrote:
> Updated blob layout (Rob, Daniel, Kristian, xerpi)
In terms of the blob as uABI, we've got an implementation inside
Weston which works:
https://git.collabora.com/cgit/user/daniels/weston.git/commit/?h=wip/2017-04/atomic-v11-WIP&id=0a47cb63947e
T
-resend/20170504-003948
base: git://people.freedesktop.org/~airlied/linux.git drm-next
config: arm-allmodconfig (attached as .config)
compiler: arm-linux-gnueabi-gcc (Debian 6.1.1-9) 6.1.1 20160705
reproduce:
wget
https://raw.githubusercontent.com/01org/lkp-tests/master/sbin/make.cross -O
On Thu, May 4, 2017 at 12:23 PM, Christian König
wrote:
> Am 26.04.2017 um 19:00 schrieb Andy Shevchenko:
>>> + while (1) {
>>
>> This raises red flag. Care to refactor?
>> Also do {} while () syntax allows faster to get that the loop body
>> goes at least once.
>
>
> I've tried to refactor
omapdrm does not pass the rotation angle to dispc. We need to pass the
rotation angle to fully support TILER rotation with YUV formats.
Signed-off-by: Tomi Valkeinen
---
drivers/gpu/drm/omapdrm/omap_fb.c | 12
1 file changed, 12 insertions(+)
diff --git a/drivers/gpu/drm/omapdrm/om
In a few places the dispc driver needs to know whether the pixel format
is an YUV format. Add a helper to figure that out.
Signed-off-by: Tomi Valkeinen
---
drivers/gpu/drm/omapdrm/dss/dispc.c | 56 +++--
1 file changed, 23 insertions(+), 33 deletions(-)
diff --g
The code that sets and clears DOUBLESTRIDE is only ran when using NV12.
This is not correct, as we might first set the bith when using NV12, but
never clear it when using other formats.
Fix it so that when the bit is available (when the HW supports NV12) we
always either set or clear the bit.
Sig
The RFBI driver has not worked nor compiled for many years. There are
very few boards out there that use RFBI, and no one has stepped up to
fix it.
So let's remove the RFBI code that doesn't even compile.
Signed-off-by: Tomi Valkeinen
---
drivers/gpu/drm/omapdrm/dss/Kconfig | 13 -
drivers/
Hi,
This series has a bunch of cleanups. We drop DMA and VRFB rotation, and RFBI
output. None of those are supported.
The latter half is about getting rid of enum omap_color_mode and moving to use
fourcc pixel formats.
There should be no functional changes caused by this series.
This series is
We have three rotation methods supported by the SoCs with DSS: DMA,
VRFB and TILER.
DMA rotation works in theory on all DSS platforms, but in practice it's
unusable due to the huge amount of memory bandwidth it uses, and has
never really been used.
VRFB is available on OMAP3, but is not supported
DSS IP versions 2 and 3 support CLUT modes (color lookup table), but the
driver has never supported those. We still have had some code for CLUT
modes. As the newer DSS IP versions have dropped CLUT support, we might
as well clean up the driver by removing the CLUT related code.
Signed-off-by: Tomi
In this step we drop 'enum omap_color_mode', and use u32 instead.
Signed-off-by: Tomi Valkeinen
---
drivers/gpu/drm/omapdrm/dss/dispc.c| 48 +++---
drivers/gpu/drm/omapdrm/dss/dss_features.c | 16 +-
drivers/gpu/drm/omapdrm/dss/dss_features.h | 4 +--
dri
enum omap_color_mode is a bitmask, so at the moment we present the
supported color modes as mask. To be able to move to fourccs, we need to
use an array to present the supported color modes.
As a first step towards fourccs, this patch changes the code to use an
array to store the enums.
Signed-of
omapdss.h contains prototypes for three functions, which are also
defined in dss_features.h. Remove the extra prototypes from omapdss.h.
Signed-off-by: Tomi Valkeinen
---
drivers/gpu/drm/omapdrm/dss/omapdss.h | 5 -
1 file changed, 5 deletions(-)
diff --git a/drivers/gpu/drm/omapdrm/dss/oma
struct omap_overlay has 'supported_modes' field that is not used. Remove
it.
Signed-off-by: Tomi Valkeinen
---
drivers/gpu/drm/omapdrm/dss/omapdss.h | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/gpu/drm/omapdrm/dss/omapdss.h
b/drivers/gpu/drm/omapdrm/dss/omapdss.h
index 1fb48783ea2
We now get a fourcc array from dispc when asking for a plane's supported
pixel formats, so we can drop omap_framebuffer_get_formats() which was
used to convert between DSS and DRM pixel formats.
Signed-off-by: Tomi Valkeinen
---
drivers/gpu/drm/omapdrm/omap_drv.h | 2 --
drivers/gpu/drm/omapd
omap_fb.c has a table with DSS and DRM formats, used to convert between
them. This is no longer needed, so we can change the array to a plain
array of DRM_FORMAT_* values which contain all possible pixel formats
supported by any DSS IP version.
Signed-off-by: Tomi Valkeinen
---
drivers/gpu/drm/o
This patch changes omapdrm to use DRM_FORMAT_* values instead of
OMAP_DSS_COLOR_* enum. This patch only changes the uses of
OMAP_DSS_COLOR_*, so we still keep the enum omap_color_mode. I.e. we now
temporarily pass DRM_FORMAT_* values with enum omap_color_mode.
This causes a few compile warnings wi
Use dev_err_ratelimited() when an OCP error happens, to slightly easen
the flood.
Signed-off-by: Tomi Valkeinen
---
drivers/gpu/drm/omapdrm/omap_irq.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/omapdrm/omap_irq.c
b/drivers/gpu/drm/omapdrm/omap_irq
The code to calculate offset in dispc's calc_offset() is overly complex.
Simplify it.
Signed-off-by: Tomi Valkeinen
---
drivers/gpu/drm/omapdrm/dss/dispc.c | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/omapdrm/dss/dispc.c
b/drivers/gpu/drm/omapdrm/dss
Now that we use fourccs, we can also rename the 'color_mode' variables
to 'fourcc'.
Signed-off-by: Tomi Valkeinen
---
drivers/gpu/drm/omapdrm/dss/dispc.c| 109 ++---
drivers/gpu/drm/omapdrm/dss/dss_features.c | 5 +-
drivers/gpu/drm/omapdrm/dss/dss_features.h |
Add two new plane properties colorkey and colorkey_alpha for rcar gen3.
* colorkey:
- used for specifying the color on which the filtering is done.
- bits 0 to 23 are interpreted as RGB888 format, in case we are
dealing with an YCbCr format, only the Y componenet is
The vsp2 hw supports changing of the alpha of pixels that match a color
key, this patch adds support for this feature in order to be used by
the rcar-du driver.
The colorkey is interpreted different depending of the pixel format:
* RGB - all color components have to match.
* YCbCr
On Thu, May 4, 2017 at 12:53 PM, agheorghe
wrote:
> --- a/include/media/vsp1.h
> +++ b/include/media/vsp1.h
> @@ -32,6 +32,9 @@ struct vsp1_du_atomic_config {
> struct v4l2_rect dst;
> unsigned int alpha;
> unsigned int zpos;
> + u32 colorkey;
> + bool colorkey_
https://bugs.freedesktop.org/show_bug.cgi?id=99136
--- Comment #40 from Gregor Münch ---
I cant reproduce with Blood DLC on my Radeon HD 7970. Still an issue? Maybe its
specific a problem with Oland chips.
--
You are receiving this mail because:
You are the assignee for the bug.
Currently, rcar-du supports colorkeying only for rcar-gen2 and it uses
some hw capability of the display unit(DU) which is not available on gen3.
In order to implement colorkeying for gen3 we need to use the colorkey
capability of the VSPD, hence the need to change both drivers rcar-du and
vsp1.
On Thu, May 04, 2017 at 07:44:08AM +0200, Daniel Vetter wrote:
> On Wed, May 3, 2017 at 6:17 PM, Eric Anholt wrote:
> > Laurent Pinchart writes:
> >
> >> Hi Daniel,
> >>
> >> On Wednesday 03 May 2017 16:28:56 Daniel Vetter wrote:
> >>> On Wed, May 03, 2017 at 12:36:06PM +0300, Laurent Pinchart wr
Hi Alexandru,
On Thursday 04 May 2017 13:53:33 agheorghe wrote:
> Add two new plane properties colorkey and colorkey_alpha for rcar gen3.
> * colorkey:
> - used for specifying the color on which the filtering is done.
> - bits 0 to 23 are interpreted as RGB888 format, in case we are
>
On Thu, May 4, 2017 at 1:55 PM, Jose Abreu wrote:
> On 04-05-2017 11:21, Jose Abreu wrote:
>> Hi Daniel,
>>
>>
>> On 03-05-2017 16:00, Daniel Vetter wrote:
>>> On Wed, May 03, 2017 at 03:16:13PM +0100, Jose Abreu wrote:
Hi Daniel,
On 03-05-2017 07:19, Daniel Vetter wrote:
>
On Wed, May 3, 2017 at 5:21 PM, Ville Syrjälä
wrote:
> We don't actually want the codepaths to match exactly. In i915
> we allow the user to exceed some of the display/dongle limits
> because those things often tell us that something shouldn't work
> when in fact it does. And some users are quick
On Thu, May 04, 2017 at 07:48:47PM +0800, Icenowy Zheng wrote:
> The "Display Engine 2.0" in Allwinner newer SoCs contains a clock
> management unit for its subunits, like the DE CCU in A80.
>
> Add a sunxi-ng style driver for it.
>
> Signed-off-by: Icenowy Zheng
> ---
> Changes in v5:
> - Remov
On Thu, May 04, 2017 at 07:48:53PM +0800, Icenowy Zheng wrote:
> Allwinner have a new "Display Engine 2.0" in their new SoCs, which comes
> with mixers to do graphic processing and feed data to TCON, like the old
> backends and frontends.
>
> Add support for the mixer on Allwinner V3s SoC; it's th
On Thu, May 04, 2017 at 02:49:31PM +0200, Daniel Vetter wrote:
> On Wed, May 3, 2017 at 5:21 PM, Ville Syrjälä
> wrote:
> > We don't actually want the codepaths to match exactly. In i915
> > we allow the user to exceed some of the display/dongle limits
> > because those things often tell us that s
Am 04.05.2017 um 14:57 schrieb Nikola Pajkovsky:
Christian König writes:
Am 27.04.2017 um 18:17 schrieb Nikola Pajkovsky:
This is super simple elimination of else branch and I should
probably even use unlikely in
if (ring->count_dw < count_dw) {
However, amdgpu_ring_write() has simi
On Wed, May 03, 2017 at 05:09:08PM +0300, Ville Syrjälä wrote:
> On Wed, May 03, 2017 at 09:26:38AM +0200, Daniel Vetter wrote:
> > In the previous patch we've implemented hwmode tracking a la i915 for
> > the vblank timestamp calculations. But that was just the basic
> > semantics, i915 has some n
On Thu, May 04, 2017 at 10:14:26AM +0300, Jyri Sarha wrote:
> Add standard optinal property blobs for YCbCr to RGB conversion CSC
> matrix and YCbCr preoffset vector in DRM planes. New enums are defined
> to YCBCR_ENCODING property to activate the CSC and preoffset
> properties. For simplicity the
Am 04.05.2017 um 14:52 schrieb Nikola Pajkovsky:
else branch is pointless if it's right at the end of function and use
unlikely() on err path.
Signed-off-by: Nikola Pajkovsky
Reviewed-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu.h | 45 +++--
On Thu, May 04, 2017 at 10:14:25AM +0300, Jyri Sarha wrote:
> Add a standard optinal property to control YCbCr conversion in DRM
> planes. The property is stored to drm_plane object to allow different
> set of supported conversion modes for different planes on the device.
>
> Signed-off-by: Jyri S
On Thu, May 04, 2017 at 03:11:41PM +0100, Jose Abreu wrote:
> This patches makes use of the new mode_valid() callbacks introduced
> previously to validate the full video pipeline when modesetting.
>
> This calls the connector->mode_valid(), encoder->mode_valid(),
> bridge->mode_valid() and crtc->m
On Thu, May 04, 2017 at 03:22:45PM +0200, Daniel Vetter wrote:
> On Thu, May 04, 2017 at 10:14:26AM +0300, Jyri Sarha wrote:
> > Add standard optinal property blobs for YCbCr to RGB conversion CSC
> > matrix and YCbCr preoffset vector in DRM planes. New enums are defined
> > to YCBCR_ENCODING prope
On Thu, May 04, 2017 at 03:11:39PM +0100, Jose Abreu wrote:
> This changes the connector probe helper function to use the new
> encoder->mode_valid() and crtc->mode_valid() helper callbacks to
> validate the modes.
>
> The new callbacks are optional so the behaviour remains the same
> if they are
On 05/04/17 17:51, Ville Syrjälä wrote:
> On Thu, May 04, 2017 at 03:22:45PM +0200, Daniel Vetter wrote:
>> On Thu, May 04, 2017 at 10:14:26AM +0300, Jyri Sarha wrote:
>>> Add standard optinal property blobs for YCbCr to RGB conversion CSC
>>> matrix and YCbCr preoffset vector in DRM planes. New en
drmCompareBusInfo was almost this already, but it wasn't exported, its
name didn't match its functionality, and while it almost looks like it
was usable for sorting due to memcmp it wouldn't work if you had
multiple bus types. I don't really want to think about defining a
sensible sort order for bu
AC_HEADER_MAJOR only defines MAJOR_IN_SYSMACROS if major() is _not_
defined by alone. It is, but it warns, and that's ugly.
To fix this, push -Werror into CFLAGS when invoking AC_HEADER_MAJOR so
the warning makes the compilation test fail.
Signed-off-by: Adam Jackson
---
configure.ac | 4
On Thu, May 4, 2017 at 9:14 AM, Christian König
wrote:
> Am 04.05.2017 um 14:52 schrieb Nikola Pajkovsky:
>>
>> else branch is pointless if it's right at the end of function and use
>> unlikely() on err path.
>>
>> Signed-off-by: Nikola Pajkovsky
>
>
> Reviewed-by: Christian König
>
Applied. t
On Thu, May 4, 2017 at 1:15 PM, Andy Shevchenko
wrote:
> On Thu, May 4, 2017 at 12:23 PM, Christian König
> wrote:
>> Am 26.04.2017 um 19:00 schrieb Andy Shevchenko:
> static int ...xxx...(...)
> {
> unsigned int i;
> int ret;
>
> if (res->parent)
> release_resource(res)
On Thu, May 4, 2017 at 2:49 AM, Guenter Roeck wrote:
> alpha:allmodconfig fails to build as follows.
>
> drivers/gpu/drm/amd/amdgpu/amdgpu.h:1006:2: error:
> expected identifier before '(' token
> drivers/gpu/drm/amd/amdgpu/amdgpu.h:1011:28: error:
> 'NGG_BUF_MAX' undeclared here
>
From: Markus Elfring
Date: Thu, 4 May 2017 11:04:45 +0200
Some single characters should be put into a sequence.
Thus use the corresponding function "seq_putc".
This issue was detected by using the Coccinelle software.
Signed-off-by: Markus Elfring
---
drivers/gpu/drm/i915/i915_debugfs.c | 32
From: Markus Elfring
Date: Thu, 4 May 2017 13:17:10 +0200
Some text was put into a sequence by separate function calls.
Print the same data by two single function calls instead.
Signed-off-by: Markus Elfring
---
drivers/gpu/drm/i915/i915_debugfs.c | 7 ++-
1 file changed, 2 insertions(+),
From: Markus Elfring
Date: Thu, 4 May 2017 13:40:53 +0200
Do not use curly brackets at some source code places
where a single statement should be sufficient.
Signed-off-by: Markus Elfring
---
drivers/gpu/drm/i915/i915_debugfs.c | 19 ---
1 file changed, 8 insertions(+), 11 dele
From: Markus Elfring
Date: Thu, 4 May 2017 13:52:19 +0200
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
The script “checkpatch.pl” pointed information out like the following.
Comparison to NULL could be written …
Thus fix affected source code places.
From: Markus Elfring
Date: Thu, 4 May 2017 14:04:38 +0200
Use space characters at some source code places according to
the Linux coding style convention.
Signed-off-by: Markus Elfring
---
drivers/gpu/drm/i915/i915_debugfs.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
di
From: Markus Elfring
Date: Thu, 4 May 2017 14:15:00 +0200
The script "checkpatch.pl" pointed information out like the following.
WARNING: quoted string split across lines
Thus fix the affected source code place.
Signed-off-by: Markus Elfring
---
drivers/gpu/drm/i915/i915_debugfs.c | 4 ++--
From: Markus Elfring
Date: Thu, 4 May 2017 13:20:47 +0200
Some strings which did not contain data format specifications should be put
into a sequence. Thus use the corresponding function "seq_puts".
This issue was detected by using the Coccinelle software.
Signed-off-by: Markus Elfring
---
dr
From: Markus Elfring
Date: Thu, 4 May 2017 14:23:32 +0200
Two single characters (line breaks) should be put into a sequence.
Thus use the corresponding function "seq_putc".
This issue was detected by using the Coccinelle software.
Signed-off-by: Markus Elfring
---
drivers/gpu/drm/i915/i915_ge
From: Markus Elfring
Date: Thu, 4 May 2017 14:30:37 +0200
The script "checkpatch.pl" pointed information out like the following.
WARNING: quoted string split across lines
Thus fix the affected source code place.
Signed-off-by: Markus Elfring
---
drivers/gpu/drm/i915/i915_gem_gtt.c | 6 ++
"Ong, Hean Loong" writes:
> On Wed, 2017-05-03 at 13:28 -0700, Eric Anholt wrote:
>> hean.loong@intel.com writes:
>>
>> >
>> > From: Ong Hean Loong
>> >
>> > Hi,
>> >
>> > The new Intel Arria10 SOC FPGA devkit has a Display Port IP
>> > component
>> > which requires a new driver. This i
Adam Jackson writes:
> drmCompareBusInfo was almost this already, but it wasn't exported, its
> name didn't match its functionality, and while it almost looks like it
> was usable for sorting due to memcmp it wouldn't work if you had
> multiple bus types. I don't really want to think about defini
On Thu, May 04, 2017 at 09:26:09AM -0600, Jens Axboe wrote:
> Hi,
>
> Running current -git on my laptop (20FB, X1 Carbon gen4, skylake), I get
> a lot of the below warnings. Things seem to work fine (in fact it seems
> faster in general use than previously), but it's a lot of warning spew.
>
> [
On 4 May 2017 at 17:39, Adam Jackson wrote:
> drmCompareBusInfo was almost this already, but it wasn't exported, its
> name didn't match its functionality, and while it almost looks like it
> was usable for sorting due to memcmp it wouldn't work if you had
> multiple bus types. I don't really want
On 4 May 2017 at 17:39, Adam Jackson wrote:
> AC_HEADER_MAJOR only defines MAJOR_IN_SYSMACROS if major() is _not_
> defined by alone. It is, but it warns, and that's ugly.
> To fix this, push -Werror into CFLAGS when invoking AC_HEADER_MAJOR so
> the warning makes the compilation test fail.
>
> S
Pekka Paalanen writes:
> Ooh, a much much larger scope than I assumed. Nice.
Well, it's more out of a sense of fear than future planning. If all we
ever use it for is as a list of monitors that the desktop should ignore,
that'd be fine.
> That means you need an explicit key to denote HMDs. More
The vgem driver is currently registered independent of any actual
device. Some usage of the dmabuf APIs require an actual device structure
to do anything. Register a dummy platform device for use with dmabuf.
Reviewed-by: Chris Wilson
Signed-off-by: Laura Abbott
---
v4: Switch from the now remo
Hi,
This v4 of the series to add dma_buf import functions for vgem. This version
primarily focuses on adding a new approach for an alternate dma_buf attach
after platformdev was removed.
Thanks,
Laura
Laura Abbott (3):
drm/vgem: Add a dummy platform device
drm/prime: Introduce drm_gem_prime_
Enable the GEM dma-buf import interfaces in addition to the export
interfaces. This lets vgem be used as a test source for other allocators
(e.g. Ion).
Reviewed-by: Chris Wilson
Signed-off-by: Laura Abbott
---
v4: Use new drm_gem_prime_import_dev function
---
drivers/gpu/drm/vgem/vgem_drv.c |
The existing drm_gem_prime_import function uses the underlying
struct device of a drm_device for attaching to a dma_buf. Some drivers
(notably vgem) may not have an underlying device structure. Offer
an alternate function to attach using any available device structure.
Signed-off-by: Laura Abbott
https://bugs.freedesktop.org/show_bug.cgi?id=100936
Bug ID: 100936
Summary: Radeonsi rendering corruption in unigine heaven
(regression bissected)
Product: Mesa
Version: git
Hardware: All
OS: Linux (All)
https://bugzilla.kernel.org/show_bug.cgi?id=195659
Bug ID: 195659
Summary: nouveau fence error
Product: Drivers
Version: 2.5
Kernel Version: 4.10
Hardware: All
OS: Linux
Tree: Mainline
Status: NEW
https://bugzilla.kernel.org/show_bug.cgi?id=195659
--- Comment #1 from Michal Suchánek (msucha...@suse.de) ---
Created attachment 256205
--> https://bugzilla.kernel.org/attachment.cgi?id=256205&action=edit
kernel log excerpt
--
You are receiving this mail because:
You are watching the assignee
On Thu, May 04, 2017 at 06:54:16PM +0200, SF Markus Elfring wrote:
> From: Markus Elfring
> Date: Thu, 4 May 2017 13:20:47 +0200
>
> Some strings which did not contain data format specifications should be put
> into a sequence. Thus use the corresponding function "seq_puts".
debugfs / seq_file i
On Thu, May 04, 2017 at 06:59:23PM +0200, SF Markus Elfring wrote:
> From: Markus Elfring
> Date: Thu, 4 May 2017 14:15:00 +0200
>
> The script "checkpatch.pl" pointed information out like the following.
>
> WARNING: quoted string split across lines
>
> Thus fix the affected source code place.
On Thu, May 04, 2017 at 11:45:47AM -0700, Laura Abbott wrote:
>
> The existing drm_gem_prime_import function uses the underlying
> struct device of a drm_device for attaching to a dma_buf. Some drivers
> (notably vgem) may not have an underlying device structure. Offer
> an alternate function to a
Hi,
Numerous Asus desktops and All-in-one computers (e.g. D520MT) have a
regression on Linux 4.9 where the VGA output is shown all-white.
This is a regression caused by:
commit 0ce140d45a8398b501934ac289aef0eb7f47c596
Author: Ville Syrjälä
Date: Tue Oct 11 20:52:47 2016 +0300
drm/i915: C
On Thu, May 04, 2017 at 11:45:46AM -0700, Laura Abbott wrote:
>
> The vgem driver is currently registered independent of any actual
> device. Some usage of the dmabuf APIs require an actual device structure
> to do anything. Register a dummy platform device for use with dmabuf.
>
> Reviewed-by: C
On Thu, May 04, 2017 at 11:45:48AM -0700, Laura Abbott wrote:
>
> Enable the GEM dma-buf import interfaces in addition to the export
> interfaces. This lets vgem be used as a test source for other allocators
> (e.g. Ion).
>
> Reviewed-by: Chris Wilson
> Signed-off-by: Laura Abbott
> ---
> v4: U
On Thu, May 04, 2017 at 02:21:26PM -0600, Daniel Drake wrote:
> Hi,
>
> Numerous Asus desktops and All-in-one computers (e.g. D520MT) have a
> regression on Linux 4.9 where the VGA output is shown all-white.
>
> This is a regression caused by:
>
> commit 0ce140d45a8398b501934ac289aef0eb7f47c596
>> +++ b/drivers/gpu/drm/i915/i915_debugfs.c
>> @@ -1529,8 +1529,8 @@ static int gen6_drpc_info(struct seq_file *m)
>>
>> forcewake_count =
>> READ_ONCE(dev_priv->uncore.fw_domain[FW_DOMAIN_ID_RENDER].wake_count);
>> if (forcewake_count) {
>> -seq_puts(m, "RC information in
On Thu, May 4, 2017 at 2:37 PM, Ville Syrjälä
wrote:
> Please check if commit bb1d132935c2 ("drm/i915/vbt: split out defaults
> that are set when there is no VBT") fixes things for you.
I think this is not going to help. This would only make a difference
when there is no VBT at all at which point
https://bugs.freedesktop.org/show_bug.cgi?id=100937
Bug ID: 100937
Summary: Mesa fails to build with GCC 4.8
Product: Mesa
Version: git
Hardware: Other
OS: All
Status: NEW
Severity: normal
Priori
On Thu, May 04, 2017 at 10:48:10PM +0200, SF Markus Elfring wrote:
> >> +++ b/drivers/gpu/drm/i915/i915_debugfs.c
> >> @@ -1529,8 +1529,8 @@ static int gen6_drpc_info(struct seq_file *m)
> >>
> >>forcewake_count =
> >> READ_ONCE(dev_priv->uncore.fw_domain[FW_DOMAIN_ID_RENDER].wake_count);
>
On Thu, May 04, 2017 at 02:52:09PM -0600, Daniel Drake wrote:
> On Thu, May 4, 2017 at 2:37 PM, Ville Syrjälä
> wrote:
> > Please check if commit bb1d132935c2 ("drm/i915/vbt: split out defaults
> > that are set when there is no VBT") fixes things for you.
>
> I think this is not going to help. Th
https://bugs.freedesktop.org/show_bug.cgi?id=100892
Greg White changed:
What|Removed |Added
Priority|medium |highest
--
You are receiving this mail be
https://bugs.freedesktop.org/show_bug.cgi?id=100936
--- Comment #1 from Marek Olšák ---
Yeah I noticed that Unigine Heaven looks very gay now. :) This Samuel's patch
should fix it: "st/glsl_to_tgsi: fix the DCE pass in presence of loops"
--
You are receiving this mail because:
You are the assig
1 - 100 of 182 matches
Mail list logo
