2015-10-15 Mikko Rapeli :
> Fixes userspace compilation error:
>
> drm/exynos_drm.h:30:2: error: unknown type name âuint64_tâ
>
> Signed-off-by: Mikko Rapeli
> ---
> include/uapi/drm/exynos_drm.h | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
Reviewed-by: Gustavo Padovan
Hi Liviu,
[auto build test ERROR on drm/drm-next -- if it's inappropriate base, please
suggest rules for selecting the more suitable base]
url:
https://github.com/0day-ci/linux/commits/Liviu-Dudau/drm-Introduce-generic-probe-function-for-component-based-masters/20151016-001417
config
On 12 October 2015 at 23:02, Frediano Ziglio wrote:
> Instead of relaying on surface type use the actual placement.
> This allow to have different placement for a single type of
> surface.
These two look fine, just 2 things,
a) missing Signed-off-by
b) no prefix - please prefix qxl kernel patche
receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20151016/7bd4d5e8/attachment.html>
Hi Linus,
two MAINTAINERS entries that I didn't see the point in delaying.
one drm mst fix to stop sending uninitialised data to monitors
two amdgpu fixes
one radeon mst tiling fix
one vmwgfx regression fix
one virtio warning fix.
Nothing two crazy or exciting.
I have found one locking problem
Hi Dave -
i915 fixes for v4.3.
The revert dance could use some explanation: we had stuff fixed in
-next, and initially backported one commit to v4.3. Now, turns out we
need more fixes, and we could cherry-pick them all without conflicts if
we reverted the backported one first. So did that to not
On Thu, Oct 15, 2015 at 05:32:12PM -0700, Matt Roper wrote:
> On Thu, Oct 15, 2015 at 08:40:01PM +0300, ville.syrjala at linux.intel.com
> wrote:
> > From: Ville Syrjälä
> >
> > On atomic drivers we can dig out the primary plane rotation from the
> > plane state instead of looking at the legac
Hi,
Here are the virtio-gpu updates for the next merge window.
Highlight is support for 3d accelerated rendering. Initial host side
support for this (gtk ui only, more will follow) just landed in qemu
master branch and will be available in qemu 2.5.
Also noteworthy is page flipping support.
On Tue, Sep 29, 2015 at 03:39:03PM +0100, Robert Bragg wrote:
> - We're bridging two complex architectures
>
> To review this work I think it will be relevant to have a good
> general familiarity with Gen graphics (e.g. thinking about the OA
> unit's interaction with the command stream
- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20151016/46c3cf7b/attachment.html>
On Mon, 22 Jun 2015, Daniel Vetter wrote:
> On Mon, Jun 22, 2015 at 02:40:44PM +1000, Dave Airlie wrote:
>> From: Dave Airlie
>>
>> If we are doing an MST transaction and we've gotten HPD and we
>> lookup the device from the incoming msg, we should take the mgr
>> lock around it, so that mst_pri
with DRI3 and GLAMOR.)
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20151016/65d5cf0e/attachment.html>
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20151016/4d9d84b1/attachment-0001.html>
On Fri, Oct 16, 2015 at 12:02:28PM +0200, Ingo Molnar wrote:
>
> * Peter Zijlstra wrote:
>
> > > - We may be making some technical compromises a.t.m for the sake of
> > > using perf.
> > >
> > > perf_event_open() requires events to either relate to a pid or a
> > > specific cpu core,
anyway as you had a look at it and as it is not your fault personally.
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20151
After reading the ELCE Audio mini conf minutes [1] I gather that HDMI
audio was not discussed after all.
My conclusion from the Lars-Peter's latest mail [2] related to the
subject is that the wind is currently blowing slightly in favour of my
version of the hdmi codec [3], or at least not in favou
On Fri, Oct 16, 2015 at 11:33 AM, Peter Zijlstra
wrote:
> On Fri, Oct 16, 2015 at 12:02:28PM +0200, Ingo Molnar wrote:
>>
>> * Peter Zijlstra wrote:
>>
>> > > - We may be making some technical compromises a.t.m for the sake of
>> > > using perf.
>> > >
>> > > perf_event_open() requires eve
si
Mesa 11.1 (<-- Problem also exists on Mesa 10.6)
Fedora 22 x86_64
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20151016/5f1de7aa/attachment.html>
xt part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20151016/b5579384/attachment-0001.html>
From: Jitao Shi
This patch adds drm_bridge driver for parade DSI
to eDP bridge chip.
Signed-off-by: Jitao Shi
---
drivers/gpu/drm/bridge/Kconfig |9 +
drivers/gpu/drm/bridge/Makefile|1 +
drivers/gpu/drm/bridge/parade-ps8640.c | 489
3
From: Jitao Shi
Add documentation for DT properties supported by ps8640
DSI-eDP converter.
Signed-off-by: Jitao Shi
---
.../devicetree/bindings/video/bridge/ps8640.txt| 48
1 file changed, 48 insertions(+)
create mode 100644 Documentation/devicetree/bindings/video/b
part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20151016/14ea8d02/attachment.html>
On 10/16/2015 01:50 PM, Jyri Sarha wrote:
> After reading the ELCE Audio mini conf minutes [1] I gather that HDMI
> audio was not discussed after all.
It was discussed, but rather shortly and only in the context of the HDA.
(Adding Vinod to Cc, who presented yet another approach to the problem las
ttp://lists.freedesktop.org/archives/dri-devel/attachments/20151016/eee4a25f/attachment-0001.html>
On Fri, 16 Oct 2015 14:31:43 +0200,
Lars-Peter Clausen wrote:
>
> On 10/16/2015 01:50 PM, Jyri Sarha wrote:
> > After reading the ELCE Audio mini conf minutes [1] I gather that HDMI
> > audio was not discussed after all.
>
> It was discussed, but rather shortly and only in the context of the HDA.
an remote
device.
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20151016/caf9459e/attachment.html>
On 10/15/2015 02:05 AM, Stephen Boyd wrote:
> On 10/14, Archit Taneja wrote:
>> diff --git a/drivers/gpu/drm/msm/dsi/pll/dsi_pll_28nm_8960.c
>> b/drivers/gpu/drm/msm/dsi/pll/dsi_pll_28nm_8960.c
>> new file mode 100644
>> index 000..e71b4ee
>> --- /dev/null
>> +++ b/drivers/gpu/drm/msm/dsi/pl
Hi CK,
there is a typo in the subject: s/Dcumentation/Documentation/.
Am Freitag, den 16.10.2015, 20:15 +0800 schrieb CK Hu:
> From: Jitao Shi
>
> Add documentation for DT properties supported by ps8640
> DSI-eDP converter.
>
> Signed-off-by: Jitao Shi
[...]
> + - ps8640-1v2-supply: OF de
On Fri, Oct 16, 2015 at 02:31:43PM +0200, Lars-Peter Clausen wrote:
> On 10/16/2015 01:50 PM, Jyri Sarha wrote:
> > After reading the ELCE Audio mini conf minutes [1] I gather that HDMI
> > audio was not discussed after all.
>
> It was discussed, but rather shortly and only in the context of the H
<http://lists.freedesktop.org/archives/dri-devel/attachments/20151016/32c78e7e/attachment.html>
ou are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20151016/15f69a77/attachment-0001.html>
drivers/gpu/drm/bridge/parade-ps8640.c:480:3-8: No need to set .owner here. The
core will do it.
Remove .owner field if calls are used which set it automatically
Generated by: scripts/coccinelle/api/platform_no_drv_owner.cocci
CC: Jitao Shi
Signed-off-by: Fengguang Wu
---
parade-ps8640.c |
Hi Jitao,
[auto build test WARNING on drm-exynos/exynos-drm/for-next -- if it's
inappropriate base, please suggest rules for selecting the more suitable base]
url:
https://github.com/0day-ci/linux/commits/CK-Hu/Dcumentation-bridge-Add-documentation-for-ps8640-DT-properties/20151016-2
This patch set adds Color Manager implementation in DRM layer. Color Manager
is an extension in DRM framework to support color correction/enhancement.
Various Hardware platforms can support several color correction capabilities.
Color Manager provides abstraction of these capabilities and allows a
Color Management is an extension to DRM framework. It allows
abstraction of hardware color correction and enhancement capabilities
by virtue of DRM properties.
There are two major types of color correction supported by DRM
color manager:
- CTM: color transformation matrix, properties where a corre
DRM color management is written to extract the color correction
capabilities of various platforms, and every platform can showcase
its capabilities using the query properties.
Different hardwares can have different no of coefficients for palette
correction. Also the correction can be applied after
This patch adds new variables in CRTC state, to hold respective color
correction blobs. These blobs will be required during the atomic commit
for writing the color correction values in correction registers.
Signed-off-by: Shashank Sharma
Signed-off-by: Kausal Malladi
---
drivers/gpu/drm/drm_ato
As per DRM color manager design, if a userspace wants to set a correction
blob, it prepares it and sends the blob_id to kernel via set_property
call. DRM framework takes this blob_id, gets the blob, and saves it
in the CRTC state, so that, during the atomic_commit, the color correction
values from
As per the DRM get_property implementation for a blob, framework
is supposed to return the blob_id to the caller. All the color
management blobs are saved in CRTC state during the set call.
This patch adds get_property support for color management
properties, by referring to the existing blob for
This patch adds new structures in DRM layer for Palette color
correction.These structures will be used by user space agents
to configure appropriate number of samples and Palette LUT for
a platform.
Signed-off-by: Shashank Sharma
Signed-off-by: Kausal Malladi
---
include/uapi/drm/drm.h | 20 +++
Color Manager framework defines a DRM property for color
space transformation and Gamut mapping. This property is called
CTM (Color Transformation Matrix).
This patch adds a new structure in DRM layer for CTM.
This structure can be used by all user space agents to
configure CTM coefficients for co
This patch adds set property interface for intel CRTC. This
interface will be used for set operation on any DRM properties.
Signed-off-by: Shashank Sharma
Signed-off-by: Kausal Malladi
---
drivers/gpu/drm/i915/intel_display.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/i
This patch create new files intel_color_manager.c which
will contain the core color correction code for I915 driver
and its header intel_color_manager.h
The per color property patches coming up in this patch series
will fill the appropriate functions in this file.
Signed-off-by: Shashank Sharma
>From DRM color management:
DRM color manager supports these color properties:
1. "ctm": Color transformation matrix property, where a
color transformation matrix of 9 correction values gets
applied as correction.
2. "palette_before_ctm": for corrections which get
DRM color manager allows the driver to showcase its best color
correction capabilities using the specific query property
cm_coeff_after_ctm_property. The driver must loads the no. of
coefficients for color correction as per the platform capability
during the init time.
This patch adds no of coeffi
DRM color manager allows the driver to showcase its best color
correction capabilities using the specific query property
cm_coeff_before_ctm_property. The driver must loads the no. of
coefficients for color correction as per the platform capability
during the init time.
This patch adds no of coeff
CHV/BSW platform supports two different pipe level gamma
correction modes, which are:
1. Legacy 8-bit mode
2. 10-bit CGM (Color Gamut Mapping) mode
This patch does the following:
1. Attaches Gamma property to CRTC
3. Adds the core Gamma correction function for CHV/BSW
4. Adds Gamma correction macr
CHV/BSW supports Degamma color correction, which linearizes all
the non-linear color values. This will be applied before Color
Transformation.
This patch does the following:
1. Attach deGamma property to CRTC
2. Add the core function to program DeGamma correction values for
CHV/BSW platform
2.
CHV/BSW supports Color Space Conversion (CSC) using a 3x3 matrix
that needs to be programmed into CGM (Color Gamut Mapping) registers.
This patch does the following:
1. Attaches CSC property to CRTC
2. Adds the core function to program CSC correction values
3. Adds CSC correction macros
Signed-of
The color correction blob values are loaded during set_property
calls. This patch adds a function to find the blob and apply the
correction values to the display registers, during the atomic
commit call.
Signed-off-by: Shashank Sharma
Signed-off-by: Kausal Malladi
---
drivers/gpu/drm/i915/intel
Function intel_attach_color_properties_to_crtc attaches a
color property to its CRTC object. This patch calls this
function from crtc initialization sequence.
Signed-off-by: Shashank Sharma
Signed-off-by: Kausal Malladi
---
drivers/gpu/drm/i915/intel_display.c | 1 +
1 file changed, 1 insertion
I915 color manager registers pipe gamma correction as palette
correction after CTM property.
For BDW and higher platforms, split gamma correction is the best
gamma correction. This patch adds the no of coefficients(512) for
split gamma correction as "num_samples_after_ctm" parameter in device
info
BDW/SKL/BXT platforms support various Gamma correction modes
which are:
1. Legacy 8-bit mode
2. 10-bit mode
3. Split mode
4. 12-bit mode
This patch does the following:
1. Adds the core function to program Gamma correction values
for BDW/SKL/BXT platforms
2. Adds Gamma correction macros/defines
I915 color manager registers pipe degamma correction as palette
correction before CTM, DRM property.
This patch adds the no of coefficients(512) for degamma correction
as "num_samples_before_ctm" parameter in device info structures,
for BDW and higher platforms.
Signed-off-by: Shashank Sharma
Si
BDW/SKL/BXT supports Degamma color correction feature, which
linearizes the non-linearity due to gamma encoded color values.
This will be applied before Color Transformation.
This patch does the following:
1. Adds the core function to program DeGamma correction values for
BDW/SKL/BXT platform
2
BDW/SKL/BXT support Color Space Conversion (CSC) using a 3x3 matrix
that needs to be programmed into respective CSC registers.
This patch does the following:
1. Adds the core function to program CSC correction values for
BDW/SKL/BXT platform
2. Adds CSC correction macros/defines
Signed-off-by:
In plane enabling sequence, plane gamma bit is by default enabled.
Plane gamma gets higher priority than pipe gamma, if both enabled.
This patch disables plane gamma from sequence. If required, plane
gamma can be enabled via the color manager drm interface.
signed-off-by: Kumar, Kiran S
---
dri
On Thu, Oct 15, 2015 at 08:14:20PM +0200, Lukas Wunner wrote:
> Hi Daniel,
>
> On Tue, Oct 13, 2015 at 09:28:13AM +0200, Daniel Vetter wrote:
> > On Mon, Oct 12, 2015 at 12:09:53PM -0400, Alex Deucher wrote:
> > > On Fri, Aug 28, 2015 at 7:30 AM, Lukas Wunner wrote:
> > > > Signed-off-by: Lukas W
On Fri, Oct 16, 2015 at 08:54:20AM +, Daniel, Thomas wrote:
> Hi,
>
> > -Original Message-
> > From: Intel-gfx [mailto:intel-gfx-bounces at lists.freedesktop.org] On
> > Behalf Of
> > David Herrmann
> > Sent: Wednesday, October 7, 2015 11:23 AM
> > To: Chris Wilson; Daniel Vetter; Int
On Fri, Oct 16, 2015 at 11:38:18AM +0300, Ville Syrjälä wrote:
> On Thu, Oct 15, 2015 at 05:32:12PM -0700, Matt Roper wrote:
> > On Thu, Oct 15, 2015 at 08:40:01PM +0300, ville.syrjala at linux.intel.com
> > wrote:
> > > From: Ville Syrjälä
> > >
> > > On atomic drivers we can dig out the pr
ttp://lists.freedesktop.org/archives/dri-devel/attachments/20151016/01be5c4e/attachment.html>
vel/attachments/20151016/142bab3f/attachment.html>
t was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20151016/e94d2e63/attachment.html>
On Fri, Oct 16, 2015 at 04:35:02PM +0200, Daniel Vetter wrote:
> On Fri, Oct 16, 2015 at 11:38:18AM +0300, Ville Syrjälä wrote:
> > On Thu, Oct 15, 2015 at 05:32:12PM -0700, Matt Roper wrote:
> > > On Thu, Oct 15, 2015 at 08:40:01PM +0300, ville.syrjala at
> > > linux.intel.com wrote:
> > > > Fr
are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20151016/a629dfd3/attachment.html>
On Fri, Oct 16, 2015 at 06:10:20PM +0300, Ville Syrjälä wrote:
> On Fri, Oct 16, 2015 at 04:35:02PM +0200, Daniel Vetter wrote:
> > On Fri, Oct 16, 2015 at 11:38:18AM +0300, Ville Syrjälä wrote:
> > > On Thu, Oct 15, 2015 at 05:32:12PM -0700, Matt Roper wrote:
> > > > On Thu, Oct 15, 2015 at 08
From: Ville Syrjälä
On atomic drivers we can dig out the primary plane rotation from the
plane state instead of looking at the legacy crtc->invert_dimensions
flag. The flag is not set by anyone except omapdrm, and it would be
racy to set it the same way in the atomic helpers.
v2: Kill crtc->in
Hi,
> -Original Message-
> From: Intel-gfx [mailto:intel-gfx-bounces at lists.freedesktop.org] On Behalf
> Of
> David Herrmann
> Sent: Wednesday, October 7, 2015 11:23 AM
> To: Chris Wilson; Daniel Vetter; Intel Graphics Development; dri-
> devel at lists.freedesktop.org
> Subject: Re: [I
On Fri, Oct 16, 2015 at 08:15:08PM +0800, CK Hu wrote:
> From: Jitao Shi
>
> Add documentation for DT properties supported by ps8640
> DSI-eDP converter.
>
> Signed-off-by: Jitao Shi
> ---
> .../devicetree/bindings/video/bridge/ps8640.txt| 48
>
> 1 file changed, 48
> + /* FIXME - use of_graph_get_port_by_id(np, 1) on newer kernels */
> + in_ep = of_graph_get_next_endpoint(np, NULL);
Huh?
> + edidp = of_get_property(np, "edid", &size);
This property wasn't mentioned in the binding document.
Please describe it. If it's from a more generic bindin
On Fri, Oct 16, 2015 at 7:15 AM, CK Hu wrote:
> From: Jitao Shi
>
> Add documentation for DT properties supported by ps8640
> DSI-eDP converter.
>
> Signed-off-by: Jitao Shi
> ---
> .../devicetree/bindings/video/bridge/ps8640.txt| 48
>
Please move to bindings/displa
* Peter Zijlstra wrote:
> > - We may be making some technical compromises a.t.m for the sake of
> > using perf.
> >
> > perf_event_open() requires events to either relate to a pid or a
> > specific cpu core, while our device pmu relates to neither. Events
> > opened with a pid wi
In Linux 4.3-rc5, there is an error case in drm_dp_get_branch_device
that returns without releasing mgr->lock, resulting a spew of kernel
messages about a kernel work function possibly having leaked a mutex
and presumably more serious adverse consequences later. This patch
changes the error to "go
arg is long int, so arg = (arg << 22) >> 22 makes the upper 22 bits of
arg equal to bit 9 (or bit 41). But we then mask away all but bits 0-9, so
this is entirely redundant.
Signed-off-by: Rasmus Villemoes
---
gcc seems to be smart enough to realize this - the generated code is
the same. This is
On Fri, Oct 16, 2015 at 8:06 AM, Mark Rutland wrote:
>> + /* FIXME - use of_graph_get_port_by_id(np, 1) on newer kernels */
>> + in_ep = of_graph_get_next_endpoint(np, NULL);
>
> Huh?
>
>> + edidp = of_get_property(np, "edid", &size);
>
> This property wasn't mentioned in the binding d
> After reading the ELCE Audio mini conf minutes [1] I gather that HDMI
> audio was not discussed after all.
>
> My conclusion from the Lars-Peter's latest mail [2] related to the
> subject is that the wind is currently blowing slightly in favour of my
> version of the hdmi codec [3], or at least n
have when I'm not
sure we're even travelling in the right direction.
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20151016/5745edd0/attachment-0001.sig>
ext attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20151016/8978a1f1/attachment-0001.sig>
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20151016/f0469e68/attachment.sig>
The point behind standardizing properties into core drm state
structures is also that internal code looks prettiers. Take advantage
of that and set rotation directly in the fbdev atomic code.
Cc: Rob Clark
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_fb_helper.c | 6 +-
1 file chang
In
commit bbb1e52402b2a288b09ae37e8182599931c7e9df
Author: Rob Clark
Date: Tue Aug 25 15:35:58 2015 -0400
drm/fb-helper: atomic restore_fbdev_mode()..
we've forgotten to do the plane->old_fb refcount dance for
pan_display_atomic, which can result in refcount leaks if the current
configura
On Thu, Oct 15, 2015 at 08:40:02PM +0300, ville.syrjala at linux.intel.com
wrote:
> From: Ville Syrjälä
>
> Instead of relying on the old crtc-{x,y,mode} gunk, dig out the primary
> plane coordinates from the plane state when checking them against the
> new framebuffer during page flip.
>
> C
On Fri, Oct 16, 2015 at 12:23 PM, Daniel Vetter
wrote:
> In
>
> commit bbb1e52402b2a288b09ae37e8182599931c7e9df
> Author: Rob Clark
> Date: Tue Aug 25 15:35:58 2015 -0400
>
> drm/fb-helper: atomic restore_fbdev_mode()..
>
> we've forgotten to do the plane->old_fb refcount dance for
> pan_d
drm_framebuffer_reference(new_fb);
> > + plane->fb = new_fb;
> > + plane->crtc = plane->state->crtc;
> > +
> > + if (plane->old_fb)
> > +
> drm_framebuffer_unreference(plane-&
On Fri, Oct 16, 2015 at 06:23:14PM +0200, Daniel Vetter wrote:
> In
>
> commit bbb1e52402b2a288b09ae37e8182599931c7e9df
> Author: Rob Clark
> Date: Tue Aug 25 15:35:58 2015 -0400
>
> drm/fb-helper: atomic restore_fbdev_mode()..
>
> we've forgotten to do the plane->old_fb refcount dance fo
https://bugzilla.kernel.org/show_bug.cgi?id=104881
Jeff Nelson changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20151016/45769eac/attachment-0001.html>
scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20151016/fd716713/attachment.html>
In
commit bbb1e52402b2a288b09ae37e8182599931c7e9df
Author: Rob Clark
Date: Tue Aug 25 15:35:58 2015 -0400
drm/fb-helper: atomic restore_fbdev_mode()..
we've forgotten to do the plane->old_fb refcount dance for
pan_display_atomic, which can result in refcount leaks if the current
configura
On Fri, Oct 16, 2015 at 07:48:37PM +0300, Ville Syrjälä wrote:
> On Fri, Oct 16, 2015 at 06:23:14PM +0200, Daniel Vetter wrote:
> > In
> >
> > commit bbb1e52402b2a288b09ae37e8182599931c7e9df
> > Author: Rob Clark
> > Date: Tue Aug 25 15:35:58 2015 -0400
> >
> > drm/fb-helper: atomic rest
On Fri, Oct 16, 2015 at 05:40:59PM +0100, Tvrtko Ursulin wrote:
>
> On 16/10/15 17:27, Matt Roper wrote:
> >On Thu, Oct 15, 2015 at 08:40:02PM +0300, ville.syrjala at linux.intel.com
> >wrote:
> >>From: Ville Syrjälä
> >>
> >>Instead of relying on the old crtc-{x,y,mode} gunk, dig out the prim
On Fri, Oct 16, 2015 at 03:33:02AM -0700, Adam Richter wrote:
> In Linux 4.3-rc5, there is an error case in drm_dp_get_branch_device
> that returns without releasing mgr->lock, resulting a spew of kernel
> messages about a kernel work function possibly having leaked a mutex
> and presumably more se
On Fri, Oct 16, 2015 at 04:48:12PM +, Rodrigo Vivi wrote:
> Thanks!
>
> Tested-by: Rodrigo Vivi
>
>
> On Fri, Oct 16, 2015 at 9:35 AM Rob Clark wrote:
>
> > On Fri, Oct 16, 2015 at 12:23 PM, Daniel Vetter
> > wrote:
> > > In
> > >
> > > commit bbb1e52402b2a288b09ae37e8182599931c7e9df
> >
On Fri, Oct 16, 2015 at 07:17:31PM +0200, Daniel Vetter wrote:
> On Fri, Oct 16, 2015 at 05:40:59PM +0100, Tvrtko Ursulin wrote:
> >
> > On 16/10/15 17:27, Matt Roper wrote:
> > >On Thu, Oct 15, 2015 at 08:40:02PM +0300, ville.syrjala at linux.intel.com
> > >wrote:
> > >>From: Ville Syrjälä
>
On 16/10/15 17:27, Matt Roper wrote:
> On Thu, Oct 15, 2015 at 08:40:02PM +0300, ville.syrjala at linux.intel.com
> wrote:
>> From: Ville Syrjälä
>>
>> Instead of relying on the old crtc-{x,y,mode} gunk, dig out the primary
>> plane coordinates from the plane state when checking them against t
On 10/16, Archit Taneja wrote:
>
>
> On 10/15/2015 02:05 AM, Stephen Boyd wrote:
> >On 10/14, Archit Taneja wrote:
> >>+ bytediv->hw.init = &bytediv_init;
> >>+ bytediv->reg = pll_28nm->mmio + REG_DSI_28nm_8960_PHY_PLL_CTRL_9;
> >>+
> >>+ snprintf(parent, 32, "dsi%dvco_clk", pll_28nm->id);
Add a new drm_debug bit for turning on DPCD logging, to aid debugging
with troublesome monitors.
v2: don't try to hexdump the universe if driver returns -errno, and
change the "too many retries" traces to DRM_ERROR()
Signed-off-by: Rob Clark
---
drivers/gpu/drm/drm_dp_helper.c | 69
1) don't let other threads trying to bang on aux channel interrupt the
defer timeout/logic
2) don't let other threads interrupt the i2c over aux logic
---
This wasn't actually fixing things w/ problematic monitor, but seems
like generally a good idea. At least AFAIU you shouldn't allow the
sequen
Fixes regression from
commit afcd950cafea6e27b739fe7772cbbeed37d05b8b
Author: Chris Wilson
Date: Wed Jun 10 15:58:01 2015 +0100
drm: Avoid the double clflush on the last cache line in
drm_clflush_virt_range()
I'm stumped. Looking at the loop we should be iterating over every cache
line u
1 - 100 of 125 matches
Mail list logo
