Hello,
does any one know how to disable spread spectrum on the DP outputs
of a AMD RX 470?
I tried to call the funktion amdgpu_atombios_crtc_program_ss(), but
this seems to do not work any more.
Are there any other solutions?
--
Mit freundlichen Grüßen / kind regards
On Tue, Jun 27, 2017 at 05:50:38AM +1000, Dave Airlie wrote:
> >
> > I'm traveling and cannot make progress this week. The merge window is
> > also real close so this series will therefore probably miss it unless
> > something unexpected happens...
>
> Don't worry you missed the merge window for d
From: Colin Ian King
Trivial fix to spelling mistake in DRM_DEBUG_KMS message
Signed-off-by: Colin Ian King
---
drivers/gpu/drm/i915/i915_drv.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index ee2325b180
On Mon, Jun 26, 2017 at 03:44:07PM -0400, Harry Wentland wrote:
> On 2017-06-20 01:57 PM, Andrey Grodzovsky wrote:
> > Problem : While running IGT kms_atomic_transition test suite i encountered
> > a hang in drmHandleEvent immediately following an atomic_commit.
> > After dumping the atomic state
https://bugs.freedesktop.org/show_bug.cgi?id=100242
--- Comment #10 from Nicolai Hähnle ---
Created attachment 132275
--> https://bugs.freedesktop.org/attachment.cgi?id=132275&action=edit
likely fix
It is a silly bug. The attached patch should fix the crash you're seeing.
Please let me know if
On Mon, Jun 26, 2017 at 06:19:49PM +0200, Daniel Vetter wrote:
> There's no reason for drivers to call this, and all the ones I've
> removed looked very fishy:
> - Proper quiescenting of the vblank machinery should be done by
> calling drm_crtc_vblank_off(), which is best done by shutting down
>
From: Colin Ian King
Array thresolds should be named thresholds, rename it. Also make it static
static const char * const
Signed-off-by: Colin Ian King
---
drivers/gpu/drm/nouveau/nvkm/subdev/therm/temp.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm
https://bugs.freedesktop.org/show_bug.cgi?id=101499
--- Comment #18 from Carlo Caione ---
We have found another laptop with exactly the same issue (and again 32MB of
VRAM for the embedded video controller). We have also requested to ACER a new
BIOS with a bigger size of VRAM, waiting to receive i
On 27/06/17 07:29 AM, John Brooks wrote:
> On Mon, Jun 26, 2017 at 06:44:30PM +0900, Michel Dänzer wrote:
>> On 24/06/17 02:39 AM, John Brooks wrote:
>>> The BO move throttling code is designed to allow VRAM to fill quickly if it
>>> is relatively empty. However, this does not take into account sit
Hi Dave,
A bit earlier than usual since you're going on vacations. Nothing scary at
all.
drm-intel-fixes-2017-06-27:
Just a few minor fixes. Important one is the execbuf async fix (aka
ANDROID_native_sync). There was another patch for a display coherency
corner case on APL, but we've random-walke
Hi Dave,
drm-intel-next-fixes-2017-06-27:
Just three minor fixups for stuff in -next.
Aside: Backmerge of -rc7 or 4.12 final into drm-next might be good, the
cherry-pick conflicts in i915 are getting a bit much fun.
Cheers, Daniel
The following changes since commit 047b8e21e3bfa9faa4ed9a0c337f
https://bugs.freedesktop.org/show_bug.cgi?id=101499
--- Comment #19 from Michel Dänzer ---
No news I'm afraid.
(In reply to Carlo Caione from comment #17)
> In attachment what I get when using AMDGPU_GEM_DOMAIN_GTT.
[...]
> [drm:dm_plane_helper_prepare_fb [amdgpu]] *ERROR* Failed to pin framebuf
On 26/06/17 13:07, Tony Lindgren wrote:
> Tomi,
>
> * Tomi Valkeinen [170428 04:15]:
>> On 14/04/17 13:25, Hans Verkuil wrote:
>>> From: Hans Verkuil
>>>
>>> The CEC pin was always pulled up, making it impossible to use it.
> ...
>
>> Tony, can you queue this? It's safe to apply separately from
https://bugzilla.kernel.org/show_bug.cgi?id=196197
Bug ID: 196197
Summary: [drm:r600_ring_test [radeon]] *ERROR* radeon: ring 0
test failed (scratch(0x8504)=0xCAFEDEAD)
Product: Drivers
Version: 2.5
Kernel Version: linux-image-4.
https://bugzilla.kernel.org/show_bug.cgi?id=196197
--- Comment #1 from Michel Dänzer (mic...@daenzer.net) ---
Can you bisect between 4.10 and 4.11?
--
You are receiving this mail because:
You are watching the assignee of the bug.
___
dri-devel mailing
https://bugs.freedesktop.org/show_bug.cgi?id=101484
--- Comment #12 from Mika ---
Hi,
I tried with both clang and gcc on Haswell / Pitcairn with "-O2 -march=native",
and I obtained the very same broken display
clang version 5.0.0 (trunk 306114)
gcc version 7.1.1 20170528 (GCC)
--
You are recei
https://bugs.freedesktop.org/show_bug.cgi?id=98619
--- Comment #9 from Nicolai Hähnle ---
Since this is almost certainly an entirely different problem -- looks like
you're using Vulkan -- could you please open a separate bug report? Thanks.
--
You are receiving this mail because:
You are the as
https://bugs.freedesktop.org/show_bug.cgi?id=101572
Nicolai Hähnle changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
Hi Andrzej,
2017년 06월 26일 16:02에 Andrzej Hajda 이(가) 쓴 글:
> Hi Shuah,
>
>
> On 24.06.2017 02:56, Shuah Khan wrote:
>> Fix to call of_node_put() right after of_drm_find_bridge() instead of
>> holding on to it until exynos_dsi_remove().
>
> I think the current implementation is OK, node is get in
On 06/27/17 12:14, Tony Lindgren wrote:
> * Hans Verkuil [170627 01:39]:
>> On 26/06/17 13:07, Tony Lindgren wrote:
>>> Tomi,
>>>
>>> * Tomi Valkeinen [170428 04:15]:
On 14/04/17 13:25, Hans Verkuil wrote:
> From: Hans Verkuil
>
> The CEC pin was always pulled up, making it impo
On 27/06/17 11:14, Tony Lindgren wrote:
> * Hans Verkuil [170627 01:39]:
>> On 26/06/17 13:07, Tony Lindgren wrote:
>>> Tomi,
>>>
>>> * Tomi Valkeinen [170428 04:15]:
On 14/04/17 13:25, Hans Verkuil wrote:
> From: Hans Verkuil
>
> The CEC pin was always pulled up, making it impo
On Tue, Jun 27, 2017 at 08:30:09AM +0100, Colin King wrote:
> From: Colin Ian King
>
> Trivial fix to spelling mistake in DRM_DEBUG_KMS message
>
> Signed-off-by: Colin Ian King
I have this already queued for 4.14, from Ville. I'll show up in
linux-next after 4.13-rc1.
Thanks anyway.
-Daniel
On 06/27/17 12:27, Hans Verkuil wrote:
> On 27/06/17 11:14, Tony Lindgren wrote:
>> * Hans Verkuil [170627 01:39]:
>>> On 26/06/17 13:07, Tony Lindgren wrote:
Tomi,
* Tomi Valkeinen [170428 04:15]:
> On 14/04/17 13:25, Hans Verkuil wrote:
>> From: Hans Verkuil
>>
>
On Fri, Jun 23, 2017 at 09:42:44AM +0200, Hans de Goede wrote:
> On Bay Trail devices either the Crystal Cove PMIC's pwm or the LPSS'
> pwm is used to control the backlight. Other drivers take core of
> providing a backlight_pwm alias through pwm_add_table, but it is
> still useful to know which pw
On 27/06/17 11:08, Colin King wrote:
From: Colin Ian King
Array thresolds should be named thresholds, rename it. Also make it static
static const char * const
Signed-off-by: Colin Ian King
Thanks for doing this,
Reviewed-by: Martin Peres
---
drivers/gpu/drm/nouveau/nvkm/subdev/therm/t
On 27.06.2017 11:13, Inki Dae wrote:
> Hi Andrzej,
>
> 2017년 06월 26일 16:02에 Andrzej Hajda 이(가) 쓴 글:
>> Hi Shuah,
>>
>>
>> On 24.06.2017 02:56, Shuah Khan wrote:
>>> Fix to call of_node_put() right after of_drm_find_bridge() instead of
>>> holding on to it until exynos_dsi_remove().
>> I think the c
Hi, Dave:
This include new color format support and some fixups.
Please kindly let me know if there is any problem.
Regards,
CK
The following changes since commit
6d61e70ccc21606ffb8a0a03bd3aba24f659502b:
Backmerge tag 'v4.12-rc7' into drm-next (2017-06-27 08:28:30 +1000)
are available in th
https://bugs.freedesktop.org/show_bug.cgi?id=101499
Carlo Caione changed:
What|Removed |Added
Attachment #132130|0 |1
is obsolete|
On Wed, Jun 21, 2017 at 04:04:01PM +0530, 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
On Wed, Jun 21, 2017 at 04:04:02PM +0530, Shashank Sharma wrote:
> HDMI 2.0 spec adds support for YCBCR420 sub-sampled output.
> CEA-861-F adds two new blocks in EDID's CEA extension blocks,
> to provide information about sink's YCBCR420 output capabilities.
>
> These blocks are:
>
> - YCBCR420vd
On Wed, Jun 21, 2017 at 04:04:03PM +0530, Shashank Sharma wrote:
> CEA-861-F spec adds ycbcr420 deep color support information
> in hf-vsdb block. This patch extends the existing hf-vsdb parsing
> function by adding parsing of ycbcr420 deep color support from the
> EDID and adding it into display i
On Wed, Jun 21, 2017 at 04:04:04PM +0530, Shashank Sharma wrote:
> CEA-861-F adds ycbcr capability map block, for HDMI 2.0 sinks.
> This block contains a map of indexes of CEA modes, which can
> support YCBCR 420 output also. To avoid multiple parsing of same
> CEA block, let's parse the sink infor
On Wed, Jun 21, 2017 at 10:30:51AM -0400, Sean Paul wrote:
> On Wed, Jun 21, 2017 at 11:16:27AM +0200, Daniel Vetter wrote:
> > The crtc->commit_lock only protects commit_list and commit_entry. If
> > we chase the pointer from the drm_atomic_state update structure, then
> > we don't need any locks
On Wed, Jun 21, 2017 at 04:04:13PM +0530, Shashank Sharma wrote:
> HDMI displays can support various output types, based on
> the color space and subsampling type. The possible
> outputs from a HDMI 2.0 monitor could be:
> - RGB
> - YCBCR 444
> - YCBCR 422
> - YCBCR 420
>
> This patch adds a d
On Wed, 2017-06-21 at 16:04 +0530, Shashank Sharma wrote:
> To get a YCBCR420 output from intel platforms, we need one
> scaler to scale down YCBCR444 samples to YCBCR420 samples.
>
> This patch:
> - Does scaler allocation for HDMI ycbcr420 outputs.
> - Programs PIPE_MISC register for ycbcr420 out
Hi guys,
Note: I was a total DRM newbie at the beginning of this exercise. Now I would
say I'm just newbie. ;)
I am trying to implement our lvds panel using xilinx_drm on zynqmp. We are
composing our pipeline starting with the xilinx-vdma, then a few logic parts
from the ALI3 on zedboard ref d
On Mon, Jun 26, 2017 at 05:18:19PM +0300, David Weinehall wrote:
> On Thu, Jun 22, 2017 at 12:03:39PM -0700, Puthikorn Voravootivat wrote:
> > This patch adds option to enable dynamic backlight for eDP
> > panel that supports this feature via DPCD register and
> > set minimum / maximum brightness t
Hi,
On 06/27/2017 11:52 AM, Ville Syrjälä wrote:
On Fri, Jun 23, 2017 at 09:42:44AM +0200, Hans de Goede wrote:
On Bay Trail devices either the Crystal Cove PMIC's pwm or the LPSS'
pwm is used to control the backlight. Other drivers take core of
providing a backlight_pwm alias through pwm_add_t
Quoting Christophe JAILLET (2017-06-27 06:38:54)
> 'dma_buf_vmap' returns NULL on error, not an error pointer.
>
> Fixes: 6cca22ede8a4 ("drm/i915: Add some mock tests for dmabuf interop")
> Signed-off-by: Christophe JAILLET
Thanks for the fix, reviewed and pushed.
-Chris
https://bugs.freedesktop.org/show_bug.cgi?id=92715
Elizabeth changed:
What|Removed |Added
Status|NEEDINFO|REOPENED
--
You are receiving this mail bec
https://bugs.freedesktop.org/show_bug.cgi?id=92715
Elizabeth changed:
What|Removed |Added
Status|NEW |NEEDINFO
--- Comment #26 from Elizabeth ---
4.11-stable review patch. If anyone has any objections, please let me know.
--
From: Daniel Vetter
commit e94ac3510b6a0f696f2c442c4fc4051c8101ef12 upstream.
In
commit 91eefc05f0ac71902906b2058360e61bd25137fe
Author: Daniel Vetter
Date: Wed Dec 14 00:08:10 2016 +0100
d
Op 27-06-17 om 09:37 schreef Daniel Vetter:
> On Mon, Jun 26, 2017 at 03:44:07PM -0400, Harry Wentland wrote:
>> On 2017-06-20 01:57 PM, Andrey Grodzovsky wrote:
>>> Problem : While running IGT kms_atomic_transition test suite i encountered
>>> a hang in drmHandleEvent immediately following an ato
Hi all,
Thanks to Liviu's help I realized that I fumbled the locking rework completely.
This one here should be better, but somehow I'm having a real bad day today and
I spent all day typing shit code, and then making it worse.
This here seems to work at first glance, but please test and review c
From: Thierry Reding
Introduce a new top-level lock for the FB helper code. This will allow
better locking granularity and avoid the need to abuse modeset locking
for this purpose instead.
This patch just adds the new lock everywhere we currently grab
mode_config->mutex (explicitly, or through d
Since
commit a03fdcb1863297481a4b817c2a759cafcbdfa0ae
Author: Archit Taneja
Date: Wed Aug 5 12:28:57 2015 +0530
drm: Add top level Kconfig option for DRM fbdev emulation
this is properly handled using dummy functions. This essentially
undoes
commit 7296c849bf2eca2bd7d34a4686a53e3089150ac
Like with the drm-native vblank wait ioctl we can entirely rely on the
spinlocks in drm_vblank.c, no need at all to take expensive mutexes.
The only reason we had to take mode_config.mutex was to protect the
fbdev helper's data-structures, but that's now done by
fb_helper->lock.
Cc: John Stultz
C
From: Thierry Reding
Move the modeset locking from drivers into FB helpers.
v2: Also handle intel_connector_add_to_fbdev.
Tested-by: John Stultz
Signed-off-by: Thierry Reding (v1)
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_fb_helper.c| 40 +-
That function only needs to take the individual crtc locks, not all
the kms locks. Push down the locking and then minimize it.
Cc: John Stultz
Cc: Thierry Reding
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_fb_helper.c | 24 +---
1 file changed, 9 insertions(+), 15
For the legacy path we'll keep drm_modeset_lock_all, for the atomic
one we drop the use of the magic implicit context and wire it up
properly.
Cc: John Stultz
Cc: Thierry Reding
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_fb_helper.c | 28 ++--
1 file changed,
Like with panning and modesetting, and like with those, stick with
simple drm_modeset_locking_all for the legacy path, and the full
atomic dance for atomic drivers.
This means a bit more boilerplate since setting up the atomic state
machinery is rather verbose, but then this is shared code for 30+
Same game as with the panning function, use drm_modeset_lock_all for
legacy paths, and a proper acquire ctx w/w mutex dance for atomic.
Cc: John Stultz
Cc: Thierry Reding
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_fb_helper.c | 48 +
1 file cha
Too jarring.
Fixes: f869a6ecf254 ("drm/atomic: Add target_vblank support in atomic helpers
(v2)")
Cc: Andrey Grodzovsky
Cc: Alex Deucher
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_atomic_helper.c | 24 +++-
1 file changed, 11 insertions(+), 13 deletions(-)
diff
FB helper code falls back to a 1024x768 mode if no outputs are connected
or don't report back any modes upon initialization. This can be annoying
because outputs that are added to FB helper later on can't be used with
FB helper if they don't support a matching mode.
The fallback is in place becaus
From: Thierry Reding
The FB helper core now supports deferred setup, so the driver's custom
implementation can be removed.
Cc: Xinliang Liu
Cc: Rongrong Zou
Cc: Xinwei Kong
Cc: Chen Feng
Reviewed-by: Daniel Vetter
Signed-off-by: Thierry Reding
Signed-off-by: Daniel Vetter
---
drivers/gpu
Those are now all protected using fb_helper->lock.
v2: We still need to hold mode_config.mutex right around calling
connector->fill_modes.
v3: I forgot to hold mode_config.mutex while looking at
connector->status and the mode list. Also, we need to patch up the
i915 ->initial_config callback to g
On Tue, Jun 27, 2017 at 04:29:44PM +0200, Maarten Lankhorst wrote:
> Op 27-06-17 om 09:37 schreef Daniel Vetter:
> > On Mon, Jun 26, 2017 at 03:44:07PM -0400, Harry Wentland wrote:
> >> On 2017-06-20 01:57 PM, Andrey Grodzovsky wrote:
> >>> Problem : While running IGT kms_atomic_transition test sui
From: Thierry Reding
The FB helper core now supports deferred setup, so the driver's custom
implementation can be removed.
v2: Drop NULL check, drm_fb_helper_hotplug_event handles that already.
Cc: Inki Dae
Cc: Joonyoung Shim
Cc: Seung-Woo Kim
Cc: Kyungmin Park
Signed-off-by: Thierry Reding
https://bugs.freedesktop.org/show_bug.cgi?id=100242
--- Comment #11 from tnmailingli...@gmail.com ---
The game starts up fine without a crash now and handles the out of memory error
gracefully like before. Thanks!
--
You are receiving this mail because:
You are the assignee for the bug._
https://bugs.freedesktop.org/show_bug.cgi?id=100289
--- Comment #11 from omegap...@startmail.com ---
Wow, thats one hell of a lot of output :) I'll keep running with
'drm.debug=0x01' until I get the problem next, thanks.
I'm on Devuan Testing rather than Ubuntu (RE the Padoka PPA) - looking at
ht
https://bugs.freedesktop.org/show_bug.cgi?id=101594
--- Comment #1 from Vedran Miletić ---
Can you post your clinfo?
--
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
ht
> -Original Message-
> From: Daniel Vetter [mailto:daniel.vet...@ffwll.ch]
> Sent: Tuesday, June 27, 2017 11:00 AM
> To: DRI Development
> Cc: Intel Graphics Development; Daniel Vetter; Grodzovsky, Andrey;
> Deucher, Alexander; Daniel Vetter
> Subject: [PATCH 13/13] drm/atomic-helper: Reali
https://bugs.freedesktop.org/show_bug.cgi?id=101572
--- Comment #2 from Matias N. Goldberg ---
That can't be right.
You're suggesting that in order to synchronize writes from FBO with a Compute
Shader I am going to dispatch (which btw the Compute Shader is accessing this
fbo as a regular sample
https://bugs.freedesktop.org/show_bug.cgi?id=101572
--- Comment #3 from Matias N. Goldberg ---
I rather be told that I am wrong in how to interpret glMemoryBarrier, and that
I should be calling glMemoryBarrier( GL_FRAMEBUFFER_BARRIER_BIT ); because this
and that.
--
You are receiving this mail
https://bugs.freedesktop.org/show_bug.cgi?id=101572
--- Comment #4 from Matias N. Goldberg ---
After careful thought; I realized I don't need to switch to a dummy FBO; just
unset the current one.
That DOES make sense to me as while the FBO is bound and I'm executing the
compute shader that reads
https://bugs.freedesktop.org/show_bug.cgi?id=101572
--- Comment #5 from Matias N. Goldberg ---
(btw unsetting the FBO indeed fixes the issue)
--
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel
On 2017-06-27 10:59 AM, Daniel Vetter wrote:
> Too jarring.
>
> Fixes: f869a6ecf254 ("drm/atomic: Add target_vblank support in atomic helpers
> (v2)")
> Cc: Andrey Grodzovsky
> Cc: Alex Deucher
> Signed-off-by: Daniel Vetter
Reviewed-by: Harry Wentland
Harry
> ---
> drivers/gpu/drm/drm_at
https://bugzilla.kernel.org/show_bug.cgi?id=196197
--- Comment #2 from Andreas Brogle (an...@ok.de) ---
Hello,
Sorry, I've read the git dokumentation half the day, anyway I don't understand
how bisect works and how to use it.
Is the following what you need ?
# git bisect log
git bisect start
#
On 20 June 2017 at 18:49, Daniel Vetter wrote:
> On Wed, Jun 07, 2017 at 01:07:33AM +, Brown, Aaron F wrote:
>> > From: Intel-wired-lan [mailto:intel-wired-lan-boun...@osuosl.org] On Behalf
>> > Of Jeff Kirsher
>> > Sent: Tuesday, June 6, 2017 1:46 PM
>> > To: David Miller ; Nikula, Jani
>> >
This will let drivers reduce the error cleanup they need, in
particular the "is_panel_bridge" flag.
Signed-off-by: Eric Anholt
---
drivers/gpu/drm/bridge/panel.c | 30 ++
include/drm/drm_bridge.h | 3 +++
2 files changed, 33 insertions(+)
diff --git a/drivers/
The DPHY spec requires a much larger T_INIT than I was specifying
before. In the absence of clear specs from the slave of what their
timing is, just use the value that the firmware was using.
Signed-off-by: Eric Anholt
---
drivers/gpu/drm/vc4/vc4_dsi.c | 12 +++-
1 file changed, 11 inse
The logic was all right in the end, the name was just backwards.
Signed-off-by: Eric Anholt
---
drivers/gpu/drm/vc4/vc4_dsi.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/vc4/vc4_dsi.c b/drivers/gpu/drm/vc4/vc4_dsi.c
index 15f6d5005ab9..629d372633e6
The review for v3 was basically "no, the panel should probe first so
that we have the connector by the time KMS is done initializing." To
do this, I needed to be able to register the custom (non-OF-generated)
DSI device without the host being present (patch 6). Also check out
patch 4 for a new cl
This doesn't yet cover input, but the driver does get the display
working when the firmware is disabled from talking to our I2C lines.
Signed-off-by: Eric Anholt
Acked-by: Rob Herring
---
.../panel/raspberrypi,7inch-touchscreen.txt| 49 ++
1 file changed, 49 insertio
I'm not sure what changed where I started getting vrefresh=0 from the
mode to be fixed up.
Signed-off-by: Eric Anholt
---
drivers/gpu/drm/vc4/vc4_dsi.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/vc4/vc4_dsi.c b/drivers/gpu/drm/vc4/vc4_dsi.c
index 629d3
This driver communicates with the Atmel microcontroller for sequencing
the poweron of the TC358762 DSI-DPI bridge and controlling the
backlight PWM.
v2: Set the same default orientation as the closed source firmware
used, which is the best for viewing angle.
v3: Rewrite as an i2c client driver
When a mipi_dsi_host is registered, the DT is walked to find any child
nodes with compatible strings. Those get registered as DSI devices,
and most DSI panel drivers are mipi_dsi_drivers that attach to those nodes.
There is one special case currently, the adv7533 bridge, where the
bridge probes o
The vc4 driver was unusual in that it was delaying the panel lookup
until the attach step, while most DSI hosts will -EPROBE_DEFER until
they get a panel.
Signed-off-by: Eric Anholt
---
drivers/gpu/drm/vc4/vc4_dsi.c | 40
1 file changed, 16 insertions(+),
The CRTC helper .commit() operation is legacy code, the atomic helpers
prefer the .enable() operation. As the arcpgu driver implements the
.enable() operation, .commit() is never used and can be removed.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/arc/arcpgu_crtc.c | 1 -
1 file changed,
The CRTC .dpms() helper operation is called by the atomic helpers only
when no .prepare(), .atomic_disable() or .disable() operation is
provided. As the qxl driver provides a .disable() operation, the .dpms()
operation is unused and can be removed.
Signed-off-by: Laurent Pinchart
---
drivers/gpu
The CRTC .prepare() helper operation is part of the legacy helpers and
is deprecated in favour of the .disable() helper operation. As the
vmwgfx driver provides a .disable() helper operation, and as the
.prepare() helper operation implementation is empty, we can remove it.
Signed-off-by: Laurent P
Hello,
The atomic helpers favour the .enable() and .atomic_disable() CRTC helper
operations, but still support the legacy .prepare(), .commit(), .disable() and
.dpms() operations. Some drivers have been updated, but most still use various
combination of new and legacy operations, leading to confus
The CRTC helper .prepare() operation is legacy code, the atomic helpers
prefer the .disable() operation. As the arcpgu driver implements the
.disable() and .prepare() operations identicallly, .prepare() can be
removed.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/arc/arcpgu_crtc.c | 1 -
The CRTC helper .commit() operation is legacy code, the atomic helpers
prefer the .enable() operation. Replace the .commit() helper operation
with .enable() in the driver.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/vmwgfx/vmwgfx_ldu.c | 6 +++---
drivers/gpu/drm/vmwgfx/vmwgfx_scrn.c |
The CRTC helper .commit() operation is legacy code, the atomic helpers
prefer the .enable() operation. Replace the .commit() helper operation
with .enable() in the driver.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/qxl/qxl_display.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions
The CRTC .disable() helper operation is deprecated for atomic drivers,
the new .atomic_disable() helper operation being preferred. Convert all
atomic drivers to .atomic_disable() to avoid cargo-cult use of
.disable() in new drivers.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/arc/arcpgu_
The old state is useful for drivers that need to perform operations at
enable time that depend on the transition between the old and new
states.
While at it, rename the operation to .atomic_enable() to be consistent
with .atomic_disable(), as the .enable() operation is used by atomic
helpers only.
On Mon, Jun 26, 2017 at 6:26 PM, Logan Gunthorpe wrote:
> Hi Jyri,
>
> Thanks for the ack. However, I'm reworking this patch set to use the
> include/linux/io-64-nonatomic* headers which will explicitly devolve
> into two 32-bit transfers. It's not clear whether this is appropriate
> for the tilcd
On Wed, 2017-06-28 at 05:28 +1000, Dave Airlie wrote:
> On 20 June 2017 at 18:49, Daniel Vetter wrote:
> > On Wed, Jun 07, 2017 at 01:07:33AM +, Brown, Aaron F wrote:
> > > > From: Intel-wired-lan [mailto:intel-wired-lan-boun...@osuosl.org]
> > > > On Behalf
> > > > Of Jeff Kirsher
> > > > Sen
Hi Dave,
When I said I had ~6 changes yesterday, I was lying. 3 of those changes were
included in the final misc-next pull and already exist in your tree. So then
there were 3. All quite simple, nothing to write home about.
You'll notice the unsightly backmerges below, this was due to the rockchip
The CRTC helper .commit() operation is legacy code, the atomic helpers
prefer the .enable() operation. Replace the .commit() helper operation
with .enable() in the driver.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/qxl/qxl_display.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions
The CRTC helper .commit() operation is legacy code, the atomic helpers
prefer the .enable() operation. As the arcpgu driver implements the
.enable() operation, .commit() is never used and can be removed.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/arc/arcpgu_crtc.c | 1 -
1 file changed,
The CRTC helper .commit() operation is legacy code, the atomic helpers
prefer the .enable() operation. Replace the .commit() helper operation
with .enable() in the driver.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/vmwgfx/vmwgfx_ldu.c | 6 +++---
drivers/gpu/drm/vmwgfx/vmwgfx_scrn.c |
The CRTC helper .prepare() operation is legacy code, the atomic helpers
prefer the .disable() operation. As the arcpgu driver implements the
.disable() and .prepare() operations identicallly, .prepare() can be
removed.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/arc/arcpgu_crtc.c | 1 -
The CRTC .dpms() helper operation is called by the atomic helpers only
when no .prepare(), .atomic_disable() or .disable() operation is
provided. As the qxl driver provides a .disable() operation, the .dpms()
operation is unused and can be removed.
Signed-off-by: Laurent Pinchart
---
drivers/gpu
The CRTC .disable() helper operation is deprecated for atomic drivers,
the new .atomic_disable() helper operation being preferred. Convert all
atomic drivers to .atomic_disable() to avoid cargo-cult use of
.disable() in new drivers.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/arc/arcpgu_
The CRTC .prepare() helper operation is part of the legacy helpers and
is deprecated in favour of the .disable() helper operation. As the
vmwgfx driver provides a .disable() helper operation, and as the
.prepare() helper operation implementation is empty, we can remove it.
Signed-off-by: Laurent P
The old state is useful for drivers that need to perform operations at
enable time that depend on the transition between the old and new
states.
While at it, rename the operation to .atomic_enable() to be consistent
with .atomic_disable(), as the .enable() operation is used by atomic
helpers only.
On Tue, 2017-06-27 at 16:23 +0300, David Weinehall wrote:
> On Mon, Jun 26, 2017 at 05:18:19PM +0300, David Weinehall wrote:
> > On Thu, Jun 22, 2017 at 12:03:39PM -0700, Puthikorn Voravootivat wrote:
> > > This patch adds option to enable dynamic backlight for eDP
> > > panel that supports this
Dave Airlie writes:
> From: Dave Airlie
>
> These ioctls are now in drm next so add the first set of libdrm APIs.
>
> Signed-off-by: Dave Airlie
It took me a bit of digging to understand the functional difference
between drmSyncobjHandleToFD() and drmSyncobjExportSyncFile(), but the
wrappers f
1 - 100 of 117 matches
Mail list logo
