On Tue, 06 Dec 2016, Manasi Navare wrote:
> If link training at a link rate optimal for a particular
> mode fails during modeset's atomic commit phase, then we
> let the modeset complete and then retry. We save the link rate
> value at which link training failed, update the link status property
>
On Tue, 06 Dec 2016, Manasi Navare wrote:
> If link training fails, then we need to fallback to lower
> link rate first and if link training fails at RBR, then
> fallback to lower lane count.
> This function finds the next lower link rate/lane count
> value after link training failure and limits t
ss/drm/card1/device/pp_dpm_sclk
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161208/d019211f/attachment.html>
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161208/7c3010ef/attachment.html>
On Tue, 06 Dec 2016, Manasi Navare wrote:
> Sink's capabilities are advertised through DPCD registers and get
> updated only on hotplug. So they should be computed only once in the
> long pulse handler and saved off in intel_dp structure for the use
> later. For this reason two new fields max_sink
attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161208/f74f844f/attachment-0001.html>
xt part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161208/1caa301d/attachment.html>
There has been no comments to these patches, so I guess there are no
major objections. I can go forward with this, and I think a similar job
should be done for drm_panel too. But I wonder if this should be done
for 4.10 any more?
Best regards,
Jyri
On 12/01/16 17:52, Jyri Sarha wrote:
> Note! Thi
but looks promising.
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161208/e6415f16/attachment.html>
On Wednesday 23 November 2016 09:12 AM, Tomi Valkeinen wrote:
> On 23/11/16 10:52, Greg Kroah-Hartman wrote:
>> On Wed, Nov 23, 2016 at 10:03:10AM +0200, Tomi Valkeinen wrote:
>>> Hi,
>>>
>>> Since the fbdev framework is in maintenance mode and all new display drivers
>>> should be made with the DR
ou are right about texture streaming, the cso commit might fix it.
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161208
with LLVM 3.9 and only use Mesa git.
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161208/267edb3e/attachment.html>
On 2016-12-08 15:33, Marek Vasut wrote:
> On 12/08/2016 11:52 PM, Stefan Agner wrote:
>> The LCD bus width does not need to align with the pixel format. The
>> LCDIF controller automatically converts between pixel formats and
>> bus width by padding or dropping LSBs.
>>
>> The DRM subsystem has the
was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161208/a584b733/attachment.html>
tps://lists.freedesktop.org/archives/dri-devel/attachments/20161208/55a03bed/attachment-0001.html>
If link training fails, then we need to fallback to lower
link rate first and if link training fails at RBR, then
fallback to lower lane count.
This function finds the next lower link rate/lane count
value after link training failure and limits the max
link_rate and lane_count values to these fallb
.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161208/ee7d730a/attachment.html>
The intel_dp_autotest_video_pattern() function gets invoked through the
compliance test handler on a HPD short pulse if the test type is
set to DP_TEST_VIDEO_PATTERN. This performs the DPCD registers
reads to read the requested test pattern, video pattern resolution,
frame rate and bits per color v
v2:
* Add all the other DP Complianec TEST register defs (Jani Nikula)
Cc: dri-devel at lists.freedesktop.org
Cc: Jani Nikula
Cc: Daniel Vetter
Cc: Ville Syrjala
Signed-off-by: Manasi Navare
---
include/drm/drm_dp_helper.h | 58 +
1 file changed, 58
This patch addresses a few issues from the original patch for
DP Compliance EDID test support submitted by
Todd Previte
Video Mode requested in the EDID test handler for the EDID Read
test (CTS 4.2.2.3) should be set to PREFERRED as per the CTS spec.
Signed-off-by: Manasi Navare
Cc: Jani Nikula
This patch adds support to handle automated DP compliance
link training test requests. This patch has been tested with
Unigraf DPR-120 DP Compliance device for testing Link
Training Compliance.
After we get a short pulse Compliance test request, test
request values are read and hotplug uevent is se
This patch does not change anything functionally, just cleans up
the DP compliance related variables and stores them all together
in a separate struct intel_dp_compliance. There is another struct
intel_dp_compliance_data to store all the test data. This makes it easy to
reset the compliance variabl
This addresses all the review comments from the earlier patch series:
https://patchwork.freedesktop.org/series/15771/
DP 1.2 compliance testing can be acheived using DPR-120's CTS suite.
This compliance unit sends a short pulse to initiate link training
and video pattern generation compliance test
On Thu, Dec 08, 2016 at 06:38:11AM +, Bart Van Assche wrote:
> On 12/07/16 21:54, Michael S. Tsirkin wrote:
> > On Thu, Dec 08, 2016 at 05:21:47AM +, Bart Van Assche wrote:
> >> Additionally, there are notable exceptions to the rule that most drivers
> >> are endian-clean, e.g. drivers/scsi
On Thu, Dec 08, 2016 at 11:12:41AM +0800, Shawn Guo wrote:
> +static void zx_vl_plane_atomic_update(struct drm_plane *plane,
> + struct drm_plane_state *old_state)
> +{
> + struct zx_plane *zplane = to_zx_plane(plane);
> + struct drm_framebuffer *fb = plan
tps://lists.freedesktop.org/archives/dri-devel/attachments/20161208/d9b22fd3/attachment.html>
Add user interface to provide channel mapping.
In a first step this control is read only.
As TLV type, the control provides all configurations available for
HDMI sink(ELD), and provides current channel mapping selected by codec
based on ELD and number of channels specified by user on open.
When co
Add helper to allow users to retrieve the speaker allocations without
knowledge of the ELD structure.
Signed-off-by: Arnaud Pouliquen
---
include/drm/drm_edid.h | 13 +
1 file changed, 13 insertions(+)
diff --git a/include/drm/drm_edid.h b/include/drm/drm_edid.h
index 919933d..0706c
Aim of this patch is to add 'Playback Channel Map' control to export
audio capabilities in term of HDMI sink speakers allocation.
This patch follow discussion initiates here:
[RFC] ASOC: HDMI audio info frame speaker allocation
http://www.spinics.net/lists/alsa-devel/msg57363.html
The code is f
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161208/0868c983/attachment.html>
On Tue, 06 Dec 2016, Manasi Navare wrote:
> At the time userspace does setcrtc, we've already promised the mode
> would work. The promise is based on the theoretical capabilities of
> the link, but it's possible we can't reach this in practice. The DP
> spec describes how the link should be reduce
Hi Dave,
Misc fixes and cleanups for 4.10. Highlights:
- Cursor fixes for radeon and amdgpu
- DPM fixes for some new SI variants
- Powerplay fixes
- Clock and powergating fixes
The following changes since commit 197aa6ed522cc44710687d3b02dd4e4573991416:
Merge branch 'exynos-drm-next' of
git:/
On Thu, 08 Dec 2016, Geert Uytterhoeven wrote:
> On Thu, Dec 8, 2016 at 3:02 PM, Daniel Vetter wrote:
>> If you're this good at mainting gpu and display subsystems, maybe you
>> want to take over?
>
> No please ;-)
Now that is indeed the right answer, and the attitude we're looking for!
Being ab
On Thu, Dec 08, 2016 at 04:41:52PM +0100, Christian König wrote:
> Am 08.12.2016 um 16:34 schrieb Daniel Vetter:
> > On Thu, Dec 08, 2016 at 09:33:25AM -0500, Harry Wentland wrote:
> > > Hi Daniel,
> > >
> > > just a quick clarification in-line about "validation" inside
> > > atomic_commit.
> >
--
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161208/e7923314/attachment.html>
On Thu, Dec 08, 2016 at 02:45:27PM +0100, Maarten Lankhorst wrote:
> The current api doesn't take into account that whenever properties like
> rotation or z-pos change we have to wait for vblank. To make sure
> that we wait correctly, err on the side of caution and wait whenever
> a plane is added
Am 08.12.2016 um 16:34 schrieb Daniel Vetter:
> On Thu, Dec 08, 2016 at 09:33:25AM -0500, Harry Wentland wrote:
>> Hi Daniel,
>>
>> just a quick clarification in-line about "validation" inside atomic_commit.
>>
>> On 2016-12-08 04:59 AM, Daniel Vetter wrote:
>>> Hi Harry,
>>>
>>> On Wed, Dec 07, 20
On Thu, Dec 08, 2016 at 02:45:25PM +0100, Maarten Lankhorst wrote:
> Atomic drivers may set properties like rotation on the same fb, which
> may require a call to prepare_fb even when framebuffer stays identical.
>
> Instead of handling all the special cases in the core, let the driver
> decide wh
On Thu, Dec 08, 2016 at 02:45:26PM +0100, Maarten Lankhorst wrote:
> Stop relying on a per crtc_state last_vblank_count, we know in advance
> how many there can be. Also stop re-using new_crtc_state->enable,
> we can now simply set a bitmask with crtc_crtc_mask.
> ---
> drivers/gpu/drm/drm_atomic_
On Thu, Dec 08, 2016 at 02:45:24PM +0100, Maarten Lankhorst wrote:
> When DPMS was introduced to atomic, vblanks only worked when the crtc
> was enabled and active. wait_for_vblanks were not converted to check for
> crtc_state->active, which may cause an attempt for vblank_get to fail.
>
> This is
hment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161208/ab0dd888/attachment.html>
On Thu, Dec 08, 2016 at 09:33:25AM -0500, Harry Wentland wrote:
> Hi Daniel,
>
> just a quick clarification in-line about "validation" inside atomic_commit.
>
> On 2016-12-08 04:59 AM, Daniel Vetter wrote:
> > Hi Harry,
> >
> > On Wed, Dec 07, 2016 at 09:02:13PM -0500, Harry Wentland wrote:
> >
bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161208/85522ad9/attachment.html>
bugs.
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161208/cbe29737/attachment-0001.html>
On Thu, Dec 08, 2016 at 05:05:54PM +0200, Jani Nikula wrote:
> On Tue, 06 Dec 2016, Manasi Navare wrote:
> > At the time userspace does setcrtc, we've already promised the mode
> > would work. The promise is based on the theoretical capabilities of
> > the link, but it's possible we can't reach th
[back from my walk, the sunset here is stellar ;-)]
On Thu, Dec 08, 2016 at 03:44:30PM +0100, Geert Uytterhoeven wrote:
> Hi Thomas,
>
> On Thu, Dec 8, 2016 at 3:37 PM, Thomas Petazzoni
> wrote:
> > On Thu, 8 Dec 2016 15:22:09 +0100, Geert Uytterhoeven wrote:
> >> > Wut. We have like 20+ small a
--
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161208/d6c92ded/attachment.html>
Hi Thomas,
On Thu, Dec 8, 2016 at 3:37 PM, Thomas Petazzoni
wrote:
> On Thu, 8 Dec 2016 15:22:09 +0100, Geert Uytterhoeven wrote:
>> > Wut. We have like 20+ small atomic drivers nowdays.
>>
>> That's fast! Only two weeks ago you said:
>>
>> | Bummer, they still haven't landed. But afaik there's a
Hello,
On Thu, 8 Dec 2016 15:22:09 +0100, Geert Uytterhoeven wrote:
> > Wut. We have like 20+ small atomic drivers nowdays.
>
> That's fast! Only two weeks ago you said:
>
> | Bummer, they still haven't landed. But afaik there's at least 4 of
> | them floating around in various places ...
Yo
r the help and it's nice to know that this is still used.
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161208/38c086e4/attachment.html>
10.1WXGA is a color active matrix TFT LCD module using amorphous silicon
TFT's as an active switching devices. It can be supported by the
simple-panel driver.
Read the panel edid information;
EDID MODE DETAILS
name =
pixel_clock = 71900
lvds_dual_c
The BOE 10.1" NV101WXMN51 panel is an WXGA TFT LCD panel.
Signed-off-by: Caesar Wang
---
Changes in v2: None
.../devicetree/bindings/display/panel/boe,nv101wxmn51.txt | 7 +++
1 file changed, 7 insertions(+)
create mode 100644
Documentation/devicetree/bindings/display/panel/boe,
Dear dri-devel folks,
My sincere apologies for hitting send on that mail. I got real mad and
angry and typed a mail I shouldn't have submitted - pouring oil into
flames for shit and giggles just doesn't help anyone, and it detracts from
moving things forward and improving the code and drivers and
Hi Daniel,
On Thu, Dec 8, 2016 at 3:02 PM, Daniel Vetter wrote:
> On Thu, Dec 08, 2016 at 01:15:56PM +0100, Geert Uytterhoeven wrote:
>> On Thu, Dec 8, 2016 at 11:10 AM, Daniel Vetter wrote:
>> > On Thu, Dec 08, 2016 at 12:01:19PM +1100, Benjamin Herrenschmidt wrote:
>> >> On Wed, 2016-11-23 at
On Thu, Dec 08, 2016 at 03:03:29PM +0200, Joonas Lahtinen wrote:
> On ke, 2016-12-07 at 21:45 +, Chris Wilson wrote:
> > Currently the reference for the dmabuf->obj is incremented for the
> > dmabuf in drm_gem_prime_handle_to_fd() (at the high level userspace
> > interface), but is released in
On Thu, Dec 08, 2016 at 11:57:25AM +, Robert Bragg wrote:
> On Thu, Dec 8, 2016 at 12:17 AM, Daniel Vetter wrote:
> >
> > On Wed, Dec 07, 2016 at 06:35:29PM +, Robert Bragg wrote:
> > > This is still missing corresponding documentation changes, and I haven't
> > > moved anything to drm_pri
On ke, 2016-12-07 at 21:45 +, Chris Wilson wrote:
> Currently the reference for the dmabuf->obj is incremented for the
> dmabuf in drm_gem_prime_handle_to_fd() (at the high level userspace
> interface), but is released in drm_gem_dmabuf_release() (the lowlevel
> handler). Improve the symmetry o
On Thu, Dec 08, 2016 at 01:15:56PM +0100, Geert Uytterhoeven wrote:
> On Thu, Dec 8, 2016 at 11:10 AM, Daniel Vetter wrote:
> > On Thu, Dec 08, 2016 at 12:01:19PM +1100, Benjamin Herrenschmidt wrote:
> >> On Wed, 2016-11-23 at 10:03 +0200, Tomi Valkeinen wrote:
> >> > Since the fbdev framework is
.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161208/78b48604/attachment.html>
The display has a 18-Bit parallel LCD interface, require DE to be
active high and data driven by the controller on falling pixel
clock edge (display samples on rising edge).
Signed-off-by: Stefan Agner
---
drivers/gpu/drm/panel/panel-simple.c | 4
1 file changed, 4 insertions(+)
diff --git
The LCD bus width does not need to align with the pixel format. The
LCDIF controller automatically converts between pixel formats and
bus width by padding or dropping LSBs.
The DRM subsystem has the notion of bus_format which allows to
determine what bus_formats are supported by the display. Choos
back to "signed i;" which is enough to repair this regression.
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/2016
Do something similar to vc4, only allow updating the cursor state
in-place through a fastpath when the watermarks are unaffected. This
will allow cursor movement to be smooth, but changing cursor size or
showing/hiding cursor will still fall back so watermarks can be updated.
Only moving and chang
This function is now completely unused, zap it.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/drm_atomic_helper.c | 35 ---
include/drm/drm_atomic_helper.h | 3 ---
2 files changed, 38 deletions(-)
diff --git a/drivers/gpu/drm/drm_atomic_helper.c
b/d
The current api doesn't take into account that whenever properties like
rotation or z-pos change we have to wait for vblank. To make sure
that we wait correctly, err on the side of caution and wait whenever
a plane is added to state.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/drm_atomi
Stop relying on a per crtc_state last_vblank_count, we know in advance
how many there can be. Also stop re-using new_crtc_state->enable,
we can now simply set a bitmask with crtc_crtc_mask.
---
drivers/gpu/drm/drm_atomic_helper.c | 29 +++--
include/drm/drm_crtc.h
Atomic drivers may set properties like rotation on the same fb, which
may require a call to prepare_fb even when framebuffer stays identical.
Instead of handling all the special cases in the core, let the driver
decide when prepare_fb and cleanup_fb are noops.
Signed-off-by: Maarten Lankhorst
--
When DPMS was introduced to atomic, vblanks only worked when the crtc
was enabled and active. wait_for_vblanks were not converted to check for
crtc_state->active, which may cause an attempt for vblank_get to fail.
This is probably harmless, but convert from enable to active anyway.
Signed-off-by:
drm_atomic_helpers use framebuffer_changed to skip some vblank waits
in case properties don't change. This may skip vblank waits also when
properties like rotation are changed. Fix this by always waiting for
vblank if planes are added to the state, and always calling prepare_fb
even when fb stays t
Hardware|Other |x86-64 (AMD64)
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161208/07f867c3/attachment.html>
.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161208/74a34ee1/attachment.html>
> diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
> index 72fa5b2..34eddb9 100644
> --- a/drivers/gpu/drm/drm_atomic.c
> +++ b/drivers/gpu/drm/drm_atomic.c
> @@ -1087,6 +1087,22 @@ int drm_atomic_connector_set_property(struct
> drm_connector *connector,
>
sertions(+), 17 deletions(-)
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161208/a00641ed/attachment.sig>
It's common to share screens within CI labs, and it's also common for
KVM switches to alter the contents of the CEA block but leave the
checksum outdated.
So in this case, print a debug message instead of an error.
References: https://bugs.freedesktop.org/show_bug.cgi?id=98228
Cc: Chris Wilson
C
On Thu, Dec 08, 2016 at 11:51:30PM +0200, Jani Nikula wrote:
> On Tue, 06 Dec 2016, Manasi Navare wrote:
> > If link training at a link rate optimal for a particular
> > mode fails during modeset's atomic commit phase, then we
> > let the modeset complete and then retry. We save the link rate
> >
On 8 December 2016 at 13:45, Maarten Lankhorst
wrote:
> Do something similar to vc4, only allow updating the cursor state
> in-place through a fastpath when the watermarks are unaffected. This
> will allow cursor movement to be smooth, but changing cursor size or
> showing/hiding cursor will still
On Thu, Dec 08, 2016 at 11:46:02PM +0200, Jani Nikula wrote:
> On Tue, 06 Dec 2016, Manasi Navare wrote:
> > If link training fails, then we need to fallback to lower
> > link rate first and if link training fails at RBR, then
> > fallback to lower lane count.
> > This function finds the next lowe
10.1WXGA is a color active matrix TFT LCD module using amorphous silicon
TFT's as an active switching devices. It can be supported by the
simple-panel driver.
Signed-off-by: Caesar Wang
---
drivers/gpu/drm/panel/panel-simple.c | 31 +++
1 file changed, 31 insertions(
The BOE 10.1" NV101WXMN51 panel is an WXGA TFT LCD panel.
Signed-off-by: Caesar Wang
---
.../devicetree/bindings/display/panel/boe,nv101wxmn51.txt | 7 +++
1 file changed, 7 insertions(+)
create mode 100644
Documentation/devicetree/bindings/display/panel/boe,nv101wxmn51.txt
diff
Resend the missing document.
Sorry for the noise.
å¨ 2016å¹´12æ08æ¥ 13:26, Caesar Wang åé:
> 10.1WXGA is a color active matrix TFT LCD module using amorphous silicon
> TFT's as an active switching devices. It can be supported by the
> simple-panel driver.
>
> Signed-off-by: Caesar Wang
>
Daniel, can we merge this patch?
It has no dependency on other link train patches,
it is just a clean up for the existing driver code that
uses max link rate and lane count values.
Other link train patches have dependency on this thats why
it was part of the series.
But it would be great if this ge
On Thu, Dec 08, 2016 at 11:23:39PM +0200, Jani Nikula wrote:
> On Tue, 06 Dec 2016, Manasi Navare wrote:
> > Sink's capabilities are advertised through DPCD registers and get
> > updated only on hotplug. So they should be computed only once in the
> > long pulse handler and saved off in intel_dp s
option I've tried also feels bad =). I think the only good solution is
to rewrite the init parts, but I don't want to do that for a fix.
Tomi
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161208/6eaa6384/attachment.sig>
10.1WXGA is a color active matrix TFT LCD module using amorphous silicon
TFT's as an active switching devices. It can be supported by the
simple-panel driver.
Signed-off-by: Caesar Wang
---
drivers/gpu/drm/panel/panel-simple.c | 31 +++
1 file changed, 31 insertions(
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161208/ddef16be/attachment.html>
Hi,
On 07/12/2016 18:35, Robert Bragg wrote:
> This is still missing corresponding documentation changes, and I haven't
> moved anything to drm_print.h yet, as suggested.
>
> Sending out with a few functional improvements first to get agreement
> before documenting anything (changes summarised in
On Thu, Dec 8, 2016 at 11:10 AM, Daniel Vetter wrote:
> On Thu, Dec 08, 2016 at 12:01:19PM +1100, Benjamin Herrenschmidt wrote:
>> On Wed, 2016-11-23 at 10:03 +0200, Tomi Valkeinen wrote:
>> > Since the fbdev framework is in maintenance mode and all new display
>> > drivers
>> > should be made wi
this card being one of those needing a DPM quirk in
si_dpm.c.
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161208/c31a8bef/attachment.html>
On Thu, Dec 08, 2016 at 10:50:48AM +, Chris Wilson wrote:
> On Thu, Dec 08, 2016 at 11:28:47AM +0100, Daniel Vetter wrote:
> > It's supported now! Spotted while reviewing Chris' patch to add a
> > release hook.
> >
> > Cc: Chris Wilson
> > Signed-off-by: Daniel Vetter
> > ---
> > drivers/gp
On 2016-12-07 18:37, Marek Vasut wrote:
> On 12/08/2016 02:26 AM, Stefan Agner wrote:
>> On 2016-12-07 16:59, Stefan Agner wrote:
>>> On 2016-12-07 16:49, Marek Vasut wrote:
On 12/08/2016 01:27 AM, Stefan Agner wrote:
> The DRM subsystem specifies the pixel clock polarity from a
> cont
On Thu, Dec 8, 2016 at 10:34 AM, Daniel Vetter wrote:
> On Thu, Dec 08, 2016 at 09:33:25AM -0500, Harry Wentland wrote:
>> Hi Daniel,
>>
>> just a quick clarification in-line about "validation" inside atomic_commit.
>>
>> On 2016-12-08 04:59 AM, Daniel Vetter wrote:
>> > Hi Harry,
>> >
>> > On Wed
On Thu, 8 Dec 2016 04:29:39 +0200
"Michael S. Tsirkin" wrote:
> By now, linux is mostly endian-clean. Enabling endian-ness
> checks for everyone produces about 200 new sparse warnings for me -
> less than 10% over the 2000 sparse warnings already there.
Out of curiousity: Where do most of those
putation code between check and commit doesn't get out of sync.
> >
> >> As for the rest, I hear you and appreciate your feedback. Let me get back
> >> to
> >> you on that later.
> > Just an added note on that: I do think that there's some driver teams
> > who've managed to pull a shared cod
On Thu, Dec 08, 2016 at 06:38:11AM +, Bart Van Assche wrote:
> On 12/07/16 21:54, Michael S. Tsirkin wrote:
> > On Thu, Dec 08, 2016 at 05:21:47AM +, Bart Van Assche wrote:
> >> Additionally, there are notable exceptions to the rule that most drivers
> >> are endian-clean, e.g. drivers/scsi
On Thu, Dec 08, 2016 at 12:53:07PM +0100, Daniel Vetter wrote:
> On Thu, Dec 08, 2016 at 10:50:48AM +, Chris Wilson wrote:
> > On Thu, Dec 08, 2016 at 11:28:47AM +0100, Daniel Vetter wrote:
> > > It's supported now! Spotted while reviewing Chris' patch to add a
> > > release hook.
> > >
> > >
vc4 already has a proper load sequence, but the unload one needed some
fixups: First unregister, and last drop the final ref.
Cc: Eric Anholt
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/vc4/vc4_drv.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/vc4
fsl is already fully demidlayered in the probe function, but for
convenience stuck with drm_put_dev. Call the unregister/unref parts
separately, to make sure this driver works correct.
Cc: Philipp Zabel
Cc: CK Hu
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/mediatek/mtk_drm_drv.c | 3 ++-
fsl is already fully demidlayered in the probe function, but for
convenience stuck with drm_put_dev. Call the unregister/unref parts
separately, to make sure this driver works correct.
Cc: Stefan Agner
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c | 3 ++-
1 file ch
drm_put_dev is the old midlayer-broken device cleanup function, but
etnaviv has a proper unbind function which first unregisters and then
drops the final reference. No functional change since
drm_dev_unregister happens to be idempotent.
Cc: Lucas Stach
Cc: Russell King
Cc: Christian Gmeiner
Sig
On Wed, 2016-11-23 at 10:03 +0200, Tomi Valkeinen wrote:
> Hi,
>
> Since the fbdev framework is in maintenance mode and all new display drivers
> should be made with the DRM framework, remove the fbdev drivers from staging.
>
> Note: the patches are created with git format-patch -D, so they can't
1 - 100 of 154 matches
Mail list logo