On 08/05/17 19:21, Laurent Pinchart wrote:
> Hi Tomi,
>
> On Monday 08 May 2017 17:35:50 Tomi Valkeinen wrote:
>> On 08/05/17 17:21, Laurent Pinchart wrote:
>>> On Thursday 27 Apr 2017 13:27:49 Tomi Valkeinen wrote:
We have been using DRM_MODE_CONNECTOR_Unknown for many of our outputs
be
Hi Jordan,
[auto build test ERROR on robclark/msm-next]
[also build test ERROR on v4.11 next-20170509]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci/linux/commits/Jordan-Crouse/drm-msm-gpu-Enable-zap-shader-
https://bugs.freedesktop.org/show_bug.cgi?id=99553
--- Comment #10 from M. Edward (Ed) Borasky ---
clpeak - various symptoms over the past months but now a solid crash:
https://bugzilla.redhat.com/show_bug.cgi?id=1433632
https://github.com/krrishnarraj/clpeak/issues/32
https://bugs.fr
Hello Markus,
On 8 May 2017 at 14:40, SF Markus Elfring wrote:
> From: Markus Elfring
> Date: Mon, 8 May 2017 11:05:05 +0200
>
> A few update suggestions were taken into account
> from static source code analysis.
>
> Markus Elfring (4):
> Combine two function calls into one in dma_buf_debug_s
https://bugs.freedesktop.org/show_bug.cgi?id=100919
--- Comment #2 from Thomas R. ---
Created attachment 131274
--> https://bugs.freedesktop.org/attachment.cgi?id=131274&action=edit
Relevant dmesg
--
You are receiving this mail because:
You are the assignee for the bug.___
https://bugs.freedesktop.org/show_bug.cgi?id=100919
--- Comment #1 from Thomas R. ---
I arrived here by way of having a similar problem and bisecting it down to the
very same commit. When running a kernel containing it, on my R9 285,
modesetting on my two DVI monitors takes very long and results
On 4 May 2017 at 18:16, Chris Wilson wrote:
> 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?
not sure, if drm_file is out there yet. I'll find out when I rebase
this onto something ne
On Wed, 2017-05-03 at 17:28 -0700, Puthikorn Voravootivat wrote:
> intel_dp_aux_enable_backlight() assumed that the register
> BACKLIGHT_BRIGHTNESS_CONTROL_MODE can only has value 01
> (DP_EDP_BACKLIGHT_CONTROL_MODE_PRESET) when initialize.
>
> This patch fixed that by handling all cases of that r
On 17-05-08 11:30 AM, Florian Fainelli wrote:
On 05/08/2017 11:18 AM, Eric Anholt wrote:
With the Cygnus port, we needed to add at least "|| ARCH_BCM_CYGNUS"
to let the module get built on a cygnus-only kernel. However, I
anticipate having a port for Kona soon, so just present the module on
al
On 05/08/2017 11:18 AM, Eric Anholt wrote:
> With the Cygnus port, we needed to add at least "|| ARCH_BCM_CYGNUS"
> to let the module get built on a cygnus-only kernel. However, I
> anticipate having a port for Kona soon, so just present the module on
> all of BCM.
This seems reasonable, but by r
* Laurent Pinchart [170508 04:36]:
> The omapdrm driver doesn't need the omapdss device anymore. Although it
> can't be removed completely as the fbdev driver still requires it, we
> can condition its registration to the usage of the omapfb driver.
>
> Signed-off-by: Laurent Pinchart
This too:
On Wed, 2017-05-03 at 17:28 -0700, Puthikorn Voravootivat wrote:
> intel_dp_aux_backlight driver should check for the
> DP_EDP_BACKLIGHT_BRIGHTNESS_AUX_SET_CAP before enable the driver.
>
> Signed-off-by: Puthikorn Voravootivat
> ---
> drivers/gpu/drm/i915/intel_dp_aux_backlight.c | 5 ++---
> 1
* Laurent Pinchart [170508 04:36]:
> The next step is to remove the omapdss platform driver (for the virtual
> omapdss platform device, also known as core code, not to be confused with the
> omapdss_dss driver for the DSS hardware device). Patches 21/28 to 23/28 move
> the useful features of the c
The last goto looks spurious because it releases less resources than the
previous one.
Also free 'img->sig' if 'ls_ucode_img_build()' fails.
Fixes: 9d896f3e41a6 ("drm/nouveau/secboot: abstract LS firmware loading
functions")
Signed-off-by: Christophe JAILLET
---
v2: update topic
only free '
On Mon, 2017-05-08 at 10:49 -0700, Puthikorn Voravootivat wrote:
> This is not related to brightness control. This calculation is used to
> set the PWM frequency.
> Frequency = 27 Mhz / (F * 2^ Pn)
>
> Lower Pn means higher value for F which mean more accuracy for this
> calculation.
I am not sur
The last goto looks spurious because it releases less resources than the
previous one.
Add a new label in order to free the memory allocated by the 'kmemdup'
call.
Fixes: 9d896f3e41a6 ("drm/nouveau/secboot: abstract LS firmware loading
functions")
Signed-off-by: Christophe JAILLET
---
This fix
Hi Daniel,
On 08-05-2017 08:50, Daniel Vetter wrote:
> 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
On 05/07/2017 11:56 AM, Daniel Vetter wrote:
> On Sun, May 7, 2017 at 7:46 PM, Jens Axboe wrote:
>> On 05/07/2017 11:12 AM, ville.syrj...@linux.intel.com wrote:
>>> From: Ville Syrjälä
>>>
>>> Add a new Kconfig option to enable/disable the extra warnings
>>> from the vblank evade code. For now we
Local variable use_doorbell is assigned to a constant value and it is never
updated again. Remove this variable and the dead code it guards.
Addresses-Coverity-ID: 1401837
Signed-off-by: Gustavo A. R. Silva
---
drivers/gpu/drm/amd/amdgpu/gfx_v7_0.c | 20 ++--
1 file changed, 6 in
On Thu, 2017-05-04 at 10:11 -0700, Eric Anholt wrote:
> "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 Int
I added the option to choose to prioritized AUX or PWM before in last
version of this patch set.
But comment from Jani said that it is better to separate the patch.
The option to prioritized the PWM in now in patch #4
On Mon, May 8, 2017 at 10:55 AM, Pandiyan, Dhinakaran <
dhinakaran.pandi...@inte
Actually you are right. Sorry it's my mistake.
I was focusing on make the actual frequency match the desired frequency as
much as possible.
But more granularity in backlight adjustment probably more important than
that.
Will submit new version of this patch to fix this.
On Mon, May 8, 2017 at 11:
Local variable use_doorbell is assigned to a constant value and it is never
updated again. Remove this variable and the dead code it guards.
Addresses-Coverity-ID: 1401828
Signed-off-by: Gustavo A. R. Silva
---
drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c | 53 +--
1 fil
This is not related to brightness control. This calculation is used to set
the PWM frequency.
Frequency = 27 Mhz / (F * 2^ Pn)
Lower Pn means higher value for F which mean more accuracy for this
calculation.
On Sat, May 6, 2017 at 1:35 AM, Pandiyan, Dhinakaran <
dhinakaran.pandi...@intel.com> wro
On Mon, 2017-05-08 at 11:06 -0700, Puthikorn Voravootivat wrote:
> I added the option to choose to prioritized AUX or PWM before in last
> version of this patch set.
> But comment from Jani said that it is better to separate the patch.
> The option to prioritized the PWM in now in patch #4
You are
* Laurent Pinchart [170508 04:36]:
> The omapdrm platform device is unused, as a replacement is now
> registered in the omapdss driver. Remove it.
>
> Signed-off-by: Laurent Pinchart
This should be OK to merge via the drm patches as long as things
have been properly tested to not cause regressi
On Wed, 2017-05-03 at 17:28 -0700, Puthikorn Voravootivat wrote:
> We should set backlight mode register before set register to
> enable the backlight.
>
Sounds reasonable, although I did not find anything in the spec. that
says we should do this. If you've tested and it works,
Reviewed-by: Dhin
On 05/08/2017 01:25 AM, Daniel Vetter wrote:
> On Sun, May 07, 2017 at 07:52:14PM -0600, Jens Axboe wrote:
>> On 05/07/2017 11:56 AM, Daniel Vetter wrote:
>>> On Sun, May 7, 2017 at 7:46 PM, Jens Axboe wrote:
On 05/07/2017 11:12 AM, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjä
On Wed, 2017-05-03 at 17:28 -0700, Puthikorn Voravootivat wrote:
> Some panel will default to zero brightness when turning the
> panel off and on again. This patch restores last brightness
> level back when panel is turning back on.
>
> Signed-off-by: Puthikorn Voravootivat
Looks correct and all
The omapdrm driver uses a custom API to synchronize with the SGX GPU.
This is unusable as such in the mainline kernel as the API is only
partially implemented and requires additional out-of-tree patches.
Furthermore, as no SGX driver is available in the mainline kernel, the
API can't be considered
Create a standard zpos property for every plane as an alias to the
omapdrm-specific zorder property. Unlike the zorder property that has to
be instantiated for both planes and CRTCs due to backward compatibility,
the zpos property is only instantiated for planes. When userspace will
have switched t
Hello,
This patch series is the third version of the omapdrm fences and zpos support.
It contains two completely unrelated features that just happen to have been
developed one right after the other.
Patches 1/6 to 3/6 implement explicit fences support. The first patch fixes
event handling in the
The custom plane state only encapsulates the standard plane state with
adding any custom field. Remove it and use the atomic plane helpers
directly.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/omapdrm/omap_plane.c | 58
1 file changed, 6 insertions(+)
The DRM core implements a standard "zpos" property to control planes
ordering. The omapdrm driver implements a similar property named
"zorder". Although we can't switch to DRM core handling of the "zpos"
property for backward compatibility reasons, we can store the zorder
value in the drm_plane_sta
The DRM core atomic helper now supports asynchronous commits natively.
The custom omapdrm implementation isn't needed anymore, remove it.
Signed-off-by: Laurent Pinchart
Reviewed-by: Tomi Valkeinen
---
drivers/gpu/drm/omapdrm/omap_drv.c | 112 +
drivers/gpu/d
The driver currently handles vblank events only when updating planes on
an already enabled CRTC. The atomic update API however allows requesting
an event when enabling or disabling a CRTC. This currently leads to
event objects being leaked in the kernel and to events not being sent
out. Fix it.
Si
On Mon, May 8, 2017 at 9:33 PM, Eric Anholt wrote:
> This is required for the panel to work on bcm911360, where CLCDCLK is
> the fixed 200Mhz AXI41 clock. The rate set is still passed up to the
> CLCDCLK, for platforms that have a settable rate on that one.
>
> v2: Set SET_RATE_PARENT (caught by
https://bugs.freedesktop.org/show_bug.cgi?id=100437
--- Comment #6 from Gjorgji Jankovski ---
Indeed it doesn't happen on reboots and it's definitely not related to the
graphics error as I'm pretty sure i had the exact one in an sandy bridge system
with the same GPU.
--
You are receiving this m
This patch replaces the symbolic permissions with the numeric ones.
Signed-off-by: Oscar Salvador
Reviewed-by: Martin Peres
---
drivers/gpu/drm/nouveau/nouveau_hwmon.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_hwmon.c
b/drive
This patch removes old code related to the old api and transforms the
functions for the new api. It also adds the .write and .read operations.
Signed-off-by: Oscar Salvador
Reviewed-by: Martin Peres
---
drivers/gpu/drm/nouveau/nouveau_hwmon.c | 777
1 file chang
This is a preparation for the next patches. It just adds the sensors with
their possible configurable settings and then fills the struct
hwmon_channel_info
with all this information.
Signed-off-by: Oscar Salvador
Reviewed-by: Martin Peres
---
drivers/gpu/drm/nouveau/nouveau_hwmon.c | 72 ++
This patch introduces the nouveau_hwmon_ops structure, sets up
.is_visible and .read_string operations and adds all the functions
for these operations.
This is also a preparation for the next patches, where most of the
work is being done.
This code doesn't interacture with the old one.
It's just to
This v6 fixes some comments pointed out by Martin Peres.
Versions:
v1 -> v2:
* Keep temp attrs as read only
v2 -> v3:
* Code fix-ups: struct and string as const and add return within switch
due to fallthrough
* Add Signed-off-by to all commits
v3 -> v4:
* R
This patch creates a special group attributes for attrs like "*auto_point*".
We check if we have support for them, and if we do, we gather them all in
an attribute_group's structure which is the parameter regarding special groups
of hwmon_device_register_with_info
We also do the same for pwm_min/ma
On Mon, May 8, 2017 at 4:34 PM, Jordan Crouse wrote:
> Amongst its other duties, msm_gem_new_impl adds the newly created
> GEM object to the shared inactive list which may also be actively
> modifiying the list during submission. All the paths to modify
> the list are protected by the mutex excep
Implement preemption for A5XX targets - this allows multiple
ringbuffers for different priorities with automatic preemption
of a lower priority ringbuffer if a higher one is ready.
Signed-off-by: Jordan Crouse
---
drivers/gpu/drm/msm/Makefile | 1 +
drivers/gpu/drm/msm/adreno/a5xx
Add a shadow pointer to track the current command being written into
the ring. Don't commit it as 'cur' until the command is submitted.
Because 'cur' is used to construct the software copy of the wptr this
ensures that somebody peeking in on the ring doesn't assume that a
command is inflight while
Add the infrastructure to support the idea of multiple ringbuffers.
Assign each ringbuffer an id and use that as an index for the various
ring specific operations.
The biggest delta is to support legacy fences. Each fence gets its own
sequence number but the legacy functions expect to use a unique
memptrs->wptr seems to be unused. Remove it to avoid
confusing the upcoming preemption code.
Signed-off-by: Jordan Crouse
---
drivers/gpu/drm/msm/adreno/adreno_gpu.c | 3 ---
drivers/gpu/drm/msm/adreno/adreno_gpu.h | 1 -
2 files changed, 4 deletions(-)
diff --git a/drivers/gpu/drm/msm/adreno/a
Currently the priority and other behavior of a command stream
is provided by the user application during submission and
the application is expected to internally maintain the settings
for each 'context' or 'rendering queue' and specify the correct
ones.
This works okay for simple cases but as appl
The ioctl array is sparsely populated but the compiler will make sure
that it is sufficiently sized for all the values that we have so we
can safely use ARRAY_SIZE() instead of having a constantly changing
#define in the uapi header.
Signed-off-by: Jordan Crouse
---
drivers/gpu/drm/msm/msm_drv.c
We use a global ringbuffer size and block size for all targets and
at least for 5XX preemption we need to know the value the RB_CNTL
in several locations so it makes sense to caculate it once and use
it everywhere.
The only monkey wrench is that we need to disable the RPTR shadow
for A430 targets
There isn't any generic code that uses ->idle so remove it.
Signed-off-by: Jordan Crouse
---
drivers/gpu/drm/msm/adreno/a3xx_gpu.c | 4 ++--
drivers/gpu/drm/msm/adreno/a4xx_gpu.c | 4 ++--
drivers/gpu/drm/msm/adreno/a5xx_gpu.c | 9 -
drivers/gpu/drm/msm/adreno/a5xx_gpu.h | 1 +
d
In the future we won't have a fixed set of addresses spaces.
Instead of going through the effort of assigning a ID for each
address space just use the address space itself as a token for
getting / putting an iova.
This forces a few changes in the gem object however: instead
of using a simple index
The overrun check for the size of submitted commands is off by one.
It should allow the offset plus the size to be equal to the
size of the memory object when the command stream is very tightly
constructed.
Signed-off-by: Jordan Crouse
---
drivers/gpu/drm/msm/msm_gem_submit.c | 5 +++--
1 file c
The amount of information that we need to pass into msm_gpu_init()
is steadily increasing, so add a new struct to stabilize the function
call and make it easier to add new configuration down the line.
Signed-off-by: Jordan Crouse
---
drivers/gpu/drm/msm/adreno/adreno_gpu.c | 12 ++--
dri
Modify the 'pad' member of struct drm_msm_gem_info to 'hint'. If the
user sets 'hint' to non-zero it means that they want a IOVA for the
GEM object instead of a mmap() offset. Return the iova in the 'offset'
member.
Signed-off-by: Jordan Crouse
---
drivers/gpu/drm/msm/msm_drv.c | 23
Hey Rob, here is a newly refreshed chunk of my active stack starting with
some bug fixes and cleanups and culminating in A5XX preemption. Not everything
here is 100% production ready - I would definately like a comment on the
drawqueue idea (like for example, is drawqueue a stupid name?). There are
Amongst its other duties, msm_gem_new_impl adds the newly created
GEM object to the shared inactive list which may also be actively
modifiying the list during submission. All the paths to modify
the list are protected by the mutex except for the one through
msm_gem_import which can end up causing
The A5XX GPU powers on in "secure" mode. In secure mode the GPU can
only render to buffers that are marked as secure and inaccessible
to the kernel and user through a series of hardware protections. In
practice secure mode is used to draw things like a UI on a secure
video frame.
In order to switc
On 2017-05-08 03:07 PM, Dave Airlie wrote:
On 9 May 2017 at 04:54, Harry Wentland wrote:
Hi Daniel,
Thanks for taking the time to look at DC.
I had a couple more questions/comments in regard to the patch you posted on
IRC: http://paste.debian.net/plain/930704
My impression is that this ite
Mike Galbraith writes:
> Greetings,
>
> I'm meeting this splat in master, call io_mapping_map_atomic_wc(),
> then do something sleepy. In master-rt, I meet a variant of this
> doing read_lock() in find_next_iomem_res(), due to rwlocks being
> sleepy in RT.
>
Hi Mike,
Thanks for reporting this.
This is required for the panel to work on bcm911360, where CLCDCLK is
the fixed 200Mhz AXI41 clock. The rate set is still passed up to the
CLCDCLK, for platforms that have a settable rate on that one.
v2: Set SET_RATE_PARENT (caught by Linus Walleij), depend on
COMMON_CLK.
Signed-off-by: Eri
https://bugs.freedesktop.org/show_bug.cgi?id=95015
--- Comment #12 from raulvior@gmail.com ---
(In reply to raulvior.bcn from comment #11)
> When I mean the same exact error I mean the same address too.
This:
may 08 19:13:31 username-portatil kernel: [drm:r600_ring_test [radeon]]
*ERROR* rad
https://bugs.freedesktop.org/show_bug.cgi?id=95015
--- Comment #11 from raulvior@gmail.com ---
When I mean the same exact error I mean the same address too.
--
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mail
https://bugs.freedesktop.org/show_bug.cgi?id=95015
--- Comment #10 from raulvior@gmail.com ---
Created attachment 131264
--> https://bugs.freedesktop.org/attachment.cgi?id=131264&action=edit
Ubuntu 16.04.2 LTS apport-cli output from a Toshiba P200 laptop
I am having the exact same error in
Hi Daniel,
Thanks for taking the time to look at DC.
I had a couple more questions/comments in regard to the patch you posted
on IRC: http://paste.debian.net/plain/930704
My impression is that this item is the most important next step for us:
From a quick glance I think what we want ins
On 9 May 2017 at 04:54, Harry Wentland wrote:
> Hi Daniel,
>
> Thanks for taking the time to look at DC.
>
> I had a couple more questions/comments in regard to the patch you posted on
> IRC: http://paste.debian.net/plain/930704
>
> My impression is that this item is the most important next step f
Florian Fainelli writes:
> On 05/08/2017 11:18 AM, Eric Anholt wrote:
>> With the Cygnus port, we needed to add at least "|| ARCH_BCM_CYGNUS"
>> to let the module get built on a cygnus-only kernel. However, I
>> anticipate having a port for Kona soon, so just present the module on
>> all of BCM.
I'm currently trying to render an V4L2 image with OpenGL
on an Intel Apollo Lake using Linux 4.10 and Mesa 13.
Supprisingly I noticed that importing a DMABUF with format
DRM_FORMAT_YUYV into OpenGL using
eglCreateImage/glEGLImageTargetTexture2DOES
worked out of the box. But I noticed that there s
To ensure that neither the GEM object nor the DRM device goes away while
a GEM object exported through dma-buf is still accessible, references
must be taken to both the GEM object and the DRM device at export time.
The dma-buf release handler already releases the GEM object, but the
export handler
On Mon, May 08, 2017 at 09:33:37AM -0700, Eric Anholt wrote:
> Alexandru Gheorghe writes:
>
> > 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
On Mon, May 08, 2017 at 11:13:37AM +0100, Jose Abreu wrote:
> Hi Daniel,
>
>
> On 08-05-2017 08:50, Daniel Vetter wrote:
> > 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_v
With the Cygnus port, we needed to add at least "|| ARCH_BCM_CYGNUS"
to let the module get built on a cygnus-only kernel. However, I
anticipate having a port for Kona soon, so just present the module on
all of BCM.
Signed-off-by: Eric Anholt
---
I would be sending this through drm-misc-next, as
On Mon, May 08, 2017 at 10:11:53PM +0530, Sharma, Shashank wrote:
> Regards
>
> Shashank
>
>
> On 5/8/2017 9:54 PM, Ville Syrjälä wrote:
> > On Fri, Apr 07, 2017 at 07:39:20PM +0300, Shashank Sharma wrote:
> >> From: Jose Abreu
> >>
> >> HDMI 2.0 spec adds support for ycbcr420 subsampled output
On Fri, Apr 07, 2017 at 07:39:21PM +0300, Shashank Sharma wrote:
> HDMI 2.0 spec adds support for ycbcr420 subsampled output.
> CEA-861-F adds two new blocks in EDID, to provide information about
> sink's support for ycbcr420 output.
>
> One of these new blocks is: ycbcr420 vcb
> - ycbcr420 video
https://bugs.freedesktop.org/show_bug.cgi?id=100964
--- Comment #4 from HV ---
Not at the moment. Maybe some cheapo PSU lying around, but i'm not sure
it's gonna be able to handle the draw.
I currently have an Antec VP500P (500w) and the GPU works on Windows 7
on the same PC (installed along Deb
Regards
Shashank
On 5/8/2017 9:52 PM, Ville Syrjälä wrote:
On Fri, Apr 07, 2017 at 07:39:19PM +0300, Shashank Sharma wrote:
CEA-861-F specs defines new video modes to be used with
HDMI 2.0 EDIDs. The VIC range has been extended from 1-64 to
1-107.
Our existing CEA modedb contains only 64 mod
Regards
Shashank
On 5/8/2017 9:54 PM, Ville Syrjälä wrote:
On Fri, Apr 07, 2017 at 07:39:20PM +0300, Shashank Sharma wrote:
From: Jose Abreu
HDMI 2.0 spec adds support for ycbcr420 subsampled output.
CEA-861-F adds two new blocks in EDID, to provide information about
sink's support for ycbc
Signed-off-by: Jeff Smith
---
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_types.c | 14 ++
1 file changed, 6 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_types.c
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_types.c
index a4d5536
Signed-off-by: Jeff Smith
---
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_types.c | 2 +-
drivers/gpu/drm/amd/display/dc/dce110/dce110_timing_generator.c | 4
2 files changed, 1 insertion(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_types.c
b/
Signed-off-by: Jeff Smith
---
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_types.c | 17 -
1 file changed, 16 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_types.c
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_types.c
index 96f3
Changes: I have broken one patch into three.
Note: this only covers the display (not amdgpu) portion and does not
include the code to make it work over the card's DVI port.
I only have one Stereo-3D-capable display to test this on, an LG TV from
about 2014. All 3 modes (side-by-side half,
Alexandru Gheorghe writes:
> 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 c
Hans de Goede writes:
> HI,
>
> On 08-05-17 14:27, Chris Wilson wrote:
>> On Sun, May 07, 2017 at 11:10:56AM +0200, Hans de Goede wrote:
>>> On some (Bay Trail) devices the LCD panel is mounted upside-down.
>>>
>>> This commit uses the code to read back the initial rotation of the
>>> primary pla
Since the introduction of kernel 4.8 I've been experiencing color
banding on my Lenovo G50-80 notebook. I also had reports of the same
symptoms on the G50-70 model.
I figured out that the problem had been introduced by commit
210a021dab639694600450c14b877bf3e3240adc
The G50-80's LCD panel su
On Wed, May 03, 2017 at 01:59:54PM +0200, Maxime Ripard wrote:
> The Allwinner Timings Controller has two, mutually exclusive, channels.
> When the binding has been introduced, it was assumed that there would be
> only a single user per channel in the system.
>
> While this is likely for the chann
On Fri, Apr 07, 2017 at 07:39:20PM +0300, Shashank Sharma wrote:
> From: Jose Abreu
>
> HDMI 2.0 spec adds support for ycbcr420 subsampled output.
> CEA-861-F adds two new blocks in EDID, to provide information about
> sink's support for ycbcr420 output.
>
> These new blocks are:
> - ycbcr420 vi
On Mon, May 8, 2017 at 11:25 AM, Dieter Nützel wrote:
> Hello Alex,
>
> got mine Sapphire Nitro+ RX 580, 8 GB (of course) up and _flying_. ;-)
> Sadly 'only' with PCIe 2.0 x8 (cutted server mobo slot).
> With kernel 4.11 I've the below in dmesg:
>
> [3.714150] [drm] amdgpu kernel modesetting e
On Fri, Apr 07, 2017 at 07:39:19PM +0300, Shashank Sharma wrote:
> CEA-861-F specs defines new video modes to be used with
> HDMI 2.0 EDIDs. The VIC range has been extended from 1-64 to
> 1-107.
>
> Our existing CEA modedb contains only 64 modes (VIC=1 to VIC=64). Now
> to be able to parse new CEA
Hi Tomi,
On Monday 08 May 2017 17:35:50 Tomi Valkeinen wrote:
> On 08/05/17 17:21, Laurent Pinchart wrote:
> > On Thursday 27 Apr 2017 13:27:49 Tomi Valkeinen wrote:
> >> We have been using DRM_MODE_CONNECTOR_Unknown for many of our outputs
> >> because there has not been a proper connector type f
On Wed, May 03, 2017 at 01:59:53PM +0200, Maxime Ripard wrote:
> One of the possible output of the display pipeline, on the SoCs that have
> it, is the HDMI controller.
>
> Add a binding for it.
>
> Acked-by: Chen-Yu Tsai
> Signed-off-by: Maxime Ripard
> ---
> Documentation/devicetree/bindings
"Ong, Hean Loong" writes:
> On Thu, 2017-05-04 at 10:11 -0700, Eric Anholt wrote:
>> "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
>> > > >
https://bugs.freedesktop.org/show_bug.cgi?id=100972
Bug ID: 100972
Summary: r600g: vaapi encoder SIGFPE
Product: Mesa
Version: git
Hardware: Other
OS: All
Status: NEW
Severity: normal
Priority: m
Hello Alex,
got mine Sapphire Nitro+ RX 580, 8 GB (of course) up and _flying_. ;-)
Sadly 'only' with PCIe 2.0 x8 (cutted server mobo slot).
With kernel 4.11 I've the below in dmesg:
[3.714150] [drm] amdgpu kernel modesetting enabled.
[3.721233] fb: switching to amdgpudrmfb from VESA VGA
Pekka Paalanen writes:
> I forget if I mentioned this to you personally yet:
> https://gist.github.com/ppaalanen/e0d2744ff71188e9a294726a37ca83c2
Thanks, that's a helpful bit of thinking. It looks like most of that is
still relevant, the only piece we'd swap out is how the bits actually
get to t
Hi Markus,
On May 8, 2017 14:40, "SF Markus Elfring"
wrote:
From: Markus Elfring
Date: Mon, 8 May 2017 11:05:05 +0200
A few update suggestions were taken into account
from static source code analysis.
Thanks much for your patches; will where them up now.
Markus Elfring (4):
Combine two fu
The cache synchronisation may be a time consuming operation and thus not
best performed in an interrupt which is a typical context for
vb2_buffer_done() calls. This may consume up to tens of ms on some
machines, depending on the buffer size.
Signed-off-by: Sakari Ailus
Acked-by: Hans Verkuil
---
Rename __qbuf_*() functions which are specific to a buffer type as
__prepare_*() which matches with what they do. The naming was there for
historical reasons; the purpose of the functions was changed without
renaming them.
Signed-off-by: Sakari Ailus
Acked-by: Hans Verkuil
Reviewed-by: Laurent P
The alloc() and put() ops are for MMAP buffers only. Document it.
Signed-off-by: Sakari Ailus
Acked-by: Hans Verkuil
Reviewed-by: Laurent Pinchart
---
include/media/videobuf2-core.h | 20 ++--
1 file changed, 10 insertions(+), 10 deletions(-)
diff --git a/include/media/videobu
1 - 100 of 208 matches
Mail list logo
