scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160607/c27e27e5/attachment-0001.html>
u16 end);
> > +int mipi_dsi_set_tear_scanline(struct mipi_dsi_device *dsi, u16 param);
> > int mipi_dsi_dcs_set_tear_off(struct mipi_dsi_device *dsi);
> > int mipi_dsi_dcs_set_tear_on(struct mipi_dsi_device *dsi,
> >enum mipi_dsi_dcs_tear_mode mode);
>
> --
> Jani Nikula, Intel Open Source Technology Center
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160607/3575c177/attachment.html>
Hi Eric,
On Tuesday 07 Jun 2016 17:49:20 Eric Engestrom wrote:
> On Mon, Jun 06, 2016 at 09:14:12PM +0300, Laurent Pinchart wrote:
> > The function has no side effect and its returned values are ignored,
> > don't call it.
> >
> > Signed-off-by: Laurent Pinchart
>
> Good catch! Do you have a t
Hi Dave,
As promised, piles of prep work all around:
- drm_atomic_state rework, prep for nonblocking commit helpers
- fence patches from Gustavo and Christian to prep for atomic fences and
some cool work in ttm/amdgpu from Christian
- drm event prep for both nonblocking commit and atomic fences
Hi Dave,
drm-intel-next-2016-06-06:
- some polish for the guc code (Dave Gordon)
- big refactoring of gen9 display clock handling code (Ville)
- refactoring work in the context code (Chris Wilson)
- give encoder/crtc/planes useful names for debug output (Ville)
- improvements to skl/kbl wm computa
On Tue, Jun 07, 2016 at 05:26:21PM +0200, Thierry Reding wrote:
> 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.
>
> Signed-off-by: Thierry Reding
On Tue, Jun 07, 2016 at 05:26:24PM +0200, Thierry Reding wrote:
> From: Thierry Reding
>
> The FB helper core now supports deferred setup, so the driver's custom
> implementation can be removed.
>
> Signed-off-by: Thierry Reding
> ---
> drivers/gpu/drm/exynos/exynos_drm_drv.c | 8 ++--
>
On Tue, Jun 07, 2016 at 11:21:10PM +0530, Sumit Semwal wrote:
> On 07-Jun-2016 2:32 PM, "Jani Nikula" wrote:
> >
> > On Tue, 07 Jun 2016, Vinay Simha BN wrote:
> > > Provide a small convenience wrapper that transmits
> > > a set_tear_scanline command.
> > >
> > > Cc: Archit Taneja
> > > Cc: John
On Tue, Jun 07, 2016 at 04:03:40PM +0100, Robin Murphy wrote:
> On 07/06/16 15:43, Daniel Vetter wrote:
> > On Tue, Jun 07, 2016 at 01:18:09PM +0100, Robin Murphy wrote:
> > > In the absence of an fb_mmap callback, the fbdev code falls back to a
> > > naive implementation which relies upon the DMA
On Tue, Jun 07, 2016 at 07:54:35PM +0300, Tomi Valkeinen wrote:
> On 07/06/16 15:09, Jyri Sarha wrote:
> > Add drm_crtc_enable_color_mgmt(), remove drm_helper_crtc_enable_color_mgmt()
> > and update drm/i915-driver (the only user of the old function).
> >
> > The new function is more flexible. It
On Tue, Jun 07, 2016 at 10:02:35AM +0300, Jani Nikula wrote:
> On Mon, 06 Jun 2016, Lyude Paul wrote:
> > On Mon, 2016-06-06 at 14:30 +0300, Ville Syrjälä wrote:
> >> On Thu, May 26, 2016 at 09:54:56AM +0200, Daniel Vetter wrote:
> >> >
> >> > Queued for -next, thanks for the patch.
> >> Looks
e for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160607/08b31280/attachment.html>
s up with the omapdrm patches in this
series, if no one complains.
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.freedeskto
n-r.patch
Type: text/x-patch
Size: 1407 bytes
Desc: not available
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160607/4cf9d5dc/attachment.bin>
On Mon, Jun 06, 2016 at 09:14:51PM +0300, Laurent Pinchart wrote:
> The function has no side effect and its returned values are ignored,
> don't call it.
>
> Signed-off-by: Laurent Pinchart
Reviewed-by: Eric Engestrom
> ---
> drivers/gpu/drm/qxl/qxl_fb.c | 4
> 1 file changed, 4 deletion
On Mon, Jun 06, 2016 at 09:14:12PM +0300, Laurent Pinchart wrote:
> The function has no side effect and its returned values are ignored,
> don't call it.
>
> Signed-off-by: Laurent Pinchart
Good catch! Do you have a tool that detects this, or do you just have
a really good eye?
Reviewed-by: Er
On 07/06/16 15:40, Daniel Vetter wrote:
> On Tue, Jun 07, 2016 at 01:06:00PM +0100, Robin Murphy wrote:
>> Hi Daniel, Liviu,
>>
>> Having just inadvertently merged -next into my working branch, I find
>> dev6d910bfa809e ("drm/hlcd: Use lockless gem BO free callback") adversely
>> affecting my board
From: Thierry Reding
The FB helper core now supports deferred setup, so the driver's custom
implementation can be removed.
Signed-off-by: Thierry Reding
---
drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c | 22 +++---
1 file changed, 11 insertions(+), 11 deletions(-)
diff --gi
From: Thierry Reding
The FB helper core now supports deferred setup, so the driver's custom
implementation can be removed.
Signed-off-by: Thierry Reding
---
drivers/gpu/drm/exynos/exynos_drm_drv.c | 8 ++--
drivers/gpu/drm/exynos/exynos_drm_fbdev.c | 2 --
2 files changed, 6 insertions(+
From: Thierry Reding
The FB helper core now supports deferred setup, so the driver's custom
implementation can be removed.
Signed-off-by: Thierry Reding
---
drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c | 26 +++---
1 file changed, 15 insertions(+), 11 deletions(-)
diff --g
From: Thierry Reding
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 fall
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.
Signed-off-by: Thierry Reding
---
drivers/gpu/drm/drm_fb_helper.c | 27 ++-
inclu
From: Thierry Reding
Move the modeset locking from drivers into FB helpers.
Signed-off-by: Thierry Reding
---
drivers/gpu/drm/drm_fb_helper.c| 59 +-
drivers/gpu/drm/i915/intel_dp_mst.c| 4 ---
drivers/gpu/drm/radeon/radeon_dp_mst.c | 7
3 fil
From: Thierry Reding
Add a couple of temporary variables and use shorter names for existing
variables in drm_fb_helper_add_one_connector() for better readability.
Signed-off-by: Thierry Reding
---
drivers/gpu/drm/drm_fb_helper.c | 26 --
1 file changed, 16 insertions(+)
From: Thierry Reding
An unlocked version of the drm_fb_helper_add_one_connector() function
will be added in a subsequent patch. Reshuffle the code separately to
make the diff more readable later on.
Signed-off-by: Thierry Reding
---
drivers/gpu/drm/drm_fb_helper.c | 60
From: Thierry Reding
Fix up a couple of checkpatch warnings, such as whitespace or coding
style issues.
Signed-off-by: Thierry Reding
---
drivers/gpu/drm/drm_fb_helper.c | 33 +++--
1 file changed, 19 insertions(+), 14 deletions(-)
diff --git a/drivers/gpu/drm/drm_
From: Thierry Reding
This set of patches adds support for deferring FB helper setup, which is
useful to obtain a sane configuration even when no outputs are available
during probe.
One example is HDMI, where fbdev will currently fallback to a 1024x786
resolution if no monitor is connected, and w
On Tue, Jun 07, 2016 at 01:18:09PM +0100, Robin Murphy wrote:
> In the absence of an fb_mmap callback, the fbdev code falls back to a
> naive implementation which relies upon the DMA address being the same
> as the physical address, and the buffer being physically contiguous
> from there. Whilst th
On Tue, Jun 07, 2016 at 01:06:00PM +0100, Robin Murphy wrote:
> Hi Daniel, Liviu,
>
> Having just inadvertently merged -next into my working branch, I find
> dev6d910bfa809e ("drm/hlcd: Use lockless gem BO free callback") adversely
> affecting my board's ability to boot ;)
>
> Since I (intentiona
Hi Tony, Tomi
as you have requested I have created the immutable branch containing the
mach-omap2 touching patches only from the omapdss header cleanup.
As I have mentioned in the v3 cover letter I have the other branch
containing the whole series:
https://www.mail-archive.com/linux-kernel at vge
On Tue, Jun 07, 2016 at 01:47:56PM +0200, Boris Brezillon wrote:
> Adapt drm_pick_crtcs() and update_connector_routing() to fallback to
> drm_atomic_helper_best_encoder() if funcs->best_encoder() is NULL so
> that DRM drivers can leave this hook unassigned if they know they want
> to use drm_atomic
On Tue, Jun 7, 2016 at 4:07 PM, Gustavo Padovan wrote:
> From: Gustavo Padovan
>
> Replace the legacy drm_vblank_{on,off}() with the new helper functions.
>
> Signed-off-by: Gustavo Padovan
Acked-by: Patrik Jakobsson
> ---
> drivers/gpu/drm/gma500/gma_display.c | 2 +-
> 1 file changed, 1 in
On 02.06.2016 07:27, Alex Deucher wrote:
> From: Monk Liu
>
> This help fix reloading driver hang issue of SDMA
> ring.
>
> Signed-off-by: Monk Liu
> Reviewed-by: Alex Deucher
> Reviewed-by: Christian König
> Signed-off-by: Alex Deucher
> ---
> drivers/gpu/drm/amd/amdgpu/amdgpu_ring.c | 3
Hi Daniel,
On Tuesday 07 Jun 2016 15:27:09 Daniel Vetter wrote:
> On Tue, Jun 07, 2016 at 02:33:10AM +0300, Laurent Pinchart wrote:
> > Hello,
> >
> > Various pieces of information about DRM formats (number of planes, color
> > depth, chroma subsampling, ...) are scattered across different helper
On 06/03/2016 04:21 PM, Russell King wrote:
> Convert DT component matching to use component_match_add_release().
>
> Signed-off-by: Russell King
> ---
> drivers/gpu/drm/arm/hdlcd_drv.c | 9 +++--
> drivers/gpu/drm/armada/armada_drv.c | 8 ++--
> drivers/gpu/drm
Hi Ville,
On Tuesday 07 Jun 2016 16:20:17 Ville Syrjälä wrote:
> On Tue, Jun 07, 2016 at 02:33:11AM +0300, Laurent Pinchart wrote:
> > Various pieces of information about DRM formats (number of planes, color
> > depth, chroma subsampling, ...) are scattered across different helper
> > functions
Hi Ville,
On Tuesday 07 Jun 2016 16:19:01 Ville Syrjälä wrote:
> On Tue, Jun 07, 2016 at 02:33:12AM +0300, Laurent Pinchart wrote:
> > The drm_format_plane_width() and drm_format_plane_height() helper
> > functions are not used, remove them.
>
> I have a user lined up, assuming I could get the
the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160607/2a694157/attachment-0001.html>
On Tue, Jun 07, 2016 at 02:33:11AM +0300, Laurent Pinchart wrote:
> Various pieces of information about DRM formats (number of planes, color
> depth, chroma subsampling, ...) are scattered across different helper
> functions in the DRM core. Callers of those functions often need to
> access more th
On Tue, Jun 07, 2016 at 02:33:12AM +0300, Laurent Pinchart wrote:
> The drm_format_plane_width() and drm_format_plane_height() helper
> functions are not used, remove them.
I have a user lined up, assuming I could get the dang thing reviewed.
>
> Signed-off-by: Laurent Pinchart
> ---
> drivers
On 07/06/16 15:43, Daniel Vetter wrote:
> On Tue, Jun 07, 2016 at 01:18:09PM +0100, Robin Murphy wrote:
>> In the absence of an fb_mmap callback, the fbdev code falls back to a
>> naive implementation which relies upon the DMA address being the same
>> as the physical address, and the buffer being
On Tue, Jun 07, 2016 at 04:43:05PM +0200, Daniel Vetter wrote:
> On Tue, Jun 07, 2016 at 01:18:09PM +0100, Robin Murphy wrote:
> > In the absence of an fb_mmap callback, the fbdev code falls back to a
> > naive implementation which relies upon the DMA address being the same
> > as the physical addr
On Tue, Jun 07, 2016 at 03:11:14PM +0100, Robin Murphy wrote:
> Hi Liviu,
>
> On 07/06/16 14:35, liviu.dudau at arm.com wrote:
> >On Tue, Jun 07, 2016 at 01:06:00PM +0100, Robin Murphy wrote:
> >>Having just inadvertently merged -next into my working branch, I find
> >>dev6d910bfa809e ("drm/hlcd:
On Mon, 6 Jun 2016 21:20:56 +0900 Masahiro Yamada wrote:
> The use of config_enabled() against config options is ambiguous.
> In practical terms, config_enabled() is equivalent to IS_BUILTIN(),
> but the author might have used it for the meaning of IS_ENABLED().
> Using IS_ENABLED(), IS_BUILTIN(
On Tue, Jun 07, 2016 at 02:33:10AM +0300, Laurent Pinchart wrote:
> Hello,
>
> Various pieces of information about DRM formats (number of planes, color
> depth, chroma subsampling, ...) are scattered across different helper
> functions in the DRM core. Callers of those functions often need to acce
Acked-by: Sinclair Yeh
On Tue, Jun 07, 2016 at 12:49:30PM +0200, Maarten Lankhorst wrote:
> Change return value to int to propagate errors from gamma_set,
> and remove start parameter. Updates always use the full size,
> and some drivers even ignore the start parameter altogether.
>
> This is ne
On Tue, Jun 07, 2016 at 03:14:04PM +0100, liviu.dudau at arm.com wrote:
> On Tue, Jun 07, 2016 at 03:11:14PM +0100, Robin Murphy wrote:
> > Hi Liviu,
> >
> > On 07/06/16 14:35, liviu.dudau at arm.com wrote:
> > >On Tue, Jun 07, 2016 at 01:06:00PM +0100, Robin Murphy wrote:
> > >>Having just inadve
On Tue, Jun 07, 2016 at 03:11:14PM +0100, Robin Murphy wrote:
> Hi Liviu,
>
> On 07/06/16 14:35, liviu.dudau at arm.com wrote:
> >On Tue, Jun 07, 2016 at 01:06:00PM +0100, Robin Murphy wrote:
> >>Having just inadvertently merged -next into my working branch, I find
> >>dev6d910bfa809e ("drm/hlcd:
Hi Liviu,
On 07/06/16 14:35, liviu.dudau at arm.com wrote:
> On Tue, Jun 07, 2016 at 01:06:00PM +0100, Robin Murphy wrote:
>> Having just inadvertently merged -next into my working branch, I find
>> dev6d910bfa809e ("drm/hlcd: Use lockless gem BO free callback") adversely
>> affecting my board's a
Implement gamma_lut atomic crtc properties, set crtc gamma size to 256
for all crtcs and use drm_atomic_helper_legacy_gamma_set() as
gamma_set func. The tv-out crtc has 1024 element gamma table (with
10bit precision) in HW, but current Xorg server does not accept
anything else but 256 elements so t
Workaround for errata i734 in DSS dispc
- LCD1 Gamma Correction Is Not Working When GFX Pipe Is Disabled
For gamma tables to work on LCD1 the GFX plane has to be used at least
once after DSS HW has come out of reset. The workaround sets up a
minimal LCD setup with GFX plane and waits for one vert
Add gamma table support to DSS dispc.
DSS driver initializes the default gamma table at component bind time
and holds a copy of all gamma tables in its internal data structure.
Each call to dispc_mgr_set_gamma() updates the internal table and
triggers write to the HW, if it is enabled. The tables
Add drm_crtc_enable_color_mgmt(), remove drm_helper_crtc_enable_color_mgmt()
and update drm/i915-driver (the only user of the old function).
The new function is more flexible. It allows driver to enable only the
features it has without forcing to enable all three color management
properties: degam
Implements gamma tables for OMAP4, OMAP5, and dra7xx SoCs and adds a
workaround for errata that may break LCD1 channel if gamma tables
are in use.
Also adds new drm_crtc_enable_color_mgmt() as suggested[1] by Daniel
Vetter and get rid of the old drm_helper_crtc_enable_color_mgmt(). I
have not test
Hi Tomi,
On Tuesday 07 Jun 2016 12:25:08 Tomi Valkeinen wrote:
> On 07/06/16 02:33, Laurent Pinchart wrote:
> > Various pieces of information about DRM formats (number of planes, color
> > depth, chroma subsampling, ...) are scattered across different helper
> > functions in the DRM core. Callers
assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160607/388beb4c/attachment.html>
Hi Tomi,
On Tuesday 07 Jun 2016 12:18:34 Tomi Valkeinen wrote:
> On 07/06/16 02:33, Laurent Pinchart wrote:
> > +/**
> > + * struct drm_format_info - information about a DRM format
> > + * @format: 4CC format identifier (DRM_FORMAT_*)
> > + * @depth: color depth (number of bits per pixel excluding
On Fri, Jun 03, 2016 at 03:21:25PM +0100, Russell King wrote:
> Convert DT component matching to use component_match_add_release().
>
> Signed-off-by: Russell King
> ---
> drivers/gpu/drm/arm/hdlcd_drv.c | 9 +++--
> drivers/gpu/drm/armada/armada_drv.c | 8 ++--
> d
On Tue, Jun 07, 2016 at 01:06:00PM +0100, Robin Murphy wrote:
> Hi Daniel, Liviu,
Hi Robin,
>
> Having just inadvertently merged -next into my working branch, I find
> dev6d910bfa809e ("drm/hlcd: Use lockless gem BO free callback") adversely
> affecting my board's ability to boot ;)
>
> Since I
regulator_set_voltage() may fail, so we better check its return value
and propagate it in the case of error.
Signed-off-by: Fabio Estevam
---
drivers/gpu/drm/imx/imx-tve.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/imx/imx-tve.c b/drivers/gpu/drm/imx/i
Am 07.06.2016 um 14:19 schrieb Mathieu Malaterre:
> On Tue, Jun 7, 2016 at 8:05 AM, Mathieu Malaterre wrote:
>> Hi Alex,
>>
>> On Mon, Jun 6, 2016 at 7:20 PM, Alex Deucher
>> wrote:
>>> On Mon, Jun 6, 2016 at 1:16 PM, Marek Olšák wrote:
[+ dri-devel]
On Mon, Jun 6, 2016 at 8:42
On Tue, Jun 7, 2016 at 8:05 AM, Mathieu Malaterre wrote:
> Hi Alex,
>
> On Mon, Jun 6, 2016 at 7:20 PM, Alex Deucher wrote:
>> On Mon, Jun 6, 2016 at 1:16 PM, Marek Olšák wrote:
>>> [+ dri-devel]
>>>
>>> On Mon, Jun 6, 2016 at 8:42 AM, Mathieu Malaterre
>>> wrote:
Hi,
Before r
Add Sii9022 DT bindings description.
Signed-off-by: Boris Brezillon
Acked-by: Rob Herring
---
Changes since v1:
- rename doc file
- s/sil902/sii902/
---
.../devicetree/bindings/display/bridge/sii902x.txt | 35 ++
1 file changed, 35 insertions(+)
create mode 100644 Documenta
Add basic support for the sii902x RGB -> HDMI bridge.
This driver does not support audio output yet.
Signed-off-by: Boris Brezillon
Tested-by: Nicolas Ferre
---
Hello,
This patch is only adding basic support for the sii9022 chip.
As stated in the commit log, there's no audio support, but the
dr
We have a 1:1 relationship between connectors and encoders, which means
we can rely on the drm_atomic_helper_best_encoder() behavior.
We still have to explicitly assign ->best_encoder() to
drm_atomic_helper_best_encoder(), because the automated fallback to
drm_atomic_helper_best_encoder() when ->b
We have a 1:1 relationship between connectors and encoders, and the driver
is relying on the atomic helpers: we can drop the custom ->best_encoder(),
and let the core call drm_atomic_helper_best_encoder() for us.
Signed-off-by: Boris Brezillon
---
drivers/gpu/drm/bridge/parade-ps8622.c | 10
We have a 1:1 relationship between connectors and encoders, and the driver
is relying on the atomic helpers: we can drop the custom ->best_encoder(),
and let the core call drm_atomic_helper_best_encoder() for us.
Signed-off-by: Boris Brezillon
---
drivers/gpu/drm/bridge/nxp-ptn3460.c | 8 ---
We have a 1:1 relationship between connectors and encoders, and the driver
is relying on the atomic helpers: we can drop the custom ->best_encoder(),
and let the core call drm_atomic_helper_best_encoder() for us.
Signed-off-by: Boris Brezillon
---
drivers/gpu/drm/bridge/analogix-anx78xx.c | 8 --
We have a 1:1 relationship between connectors and encoders and the
driver is relying on the atomic helpers: we can drop the custom
->best_encoder() implementation and let the core call
drm_atomic_helper_best_encoder() for us.
Signed-off-by: Boris Brezillon
Reviewed-by: Laurent Pinchart
---
driv
The virtgpu output exposes a 1:1 relationship between connectors and
encoders and the driver is relying on the atomic helpers: we can drop
the custom ->best_encoder() implementation and let the core call
drm_atomic_helper_best_encoder() for us.
Signed-off-by: Boris Brezillon
---
drivers/gpu/drm/
All outputs have a 1:1 relationship between connectors and encoders and
the driver is relying on the atomic helpers: we can drop the custom
->best_encoder() implementations and let the core call
drm_atomic_helper_best_encoder() for us.
Signed-off-by: Boris Brezillon
---
drivers/gpu/drm/vc4/vc4_d
All outputs have a 1:1 relationship between connectors and encoders
and the driver is relying on the atomic helpers: we can drop the custom
->best_encoder() implementation and let the core call
drm_atomic_helper_best_encoder() for us.
Signed-off-by: Boris Brezillon
---
drivers/gpu/drm/tegra/drm.
All outputs have a 1:1 relationship between connectors and encoders
and the driver is relying on the atomic helpers: we can drop the custom
->best_encoder() implementations and let the core call
drm_atomic_helper_best_encoder() for us.
Signed-off-by: Boris Brezillon
---
drivers/gpu/drm/sun4i/sun
All outputs have a 1:1 relationship between connectors and encoders
and the driver is relying on the atomic helpers: we can drop the custom
->best_encoder() implementations and let the core call
drm_atomic_helper_best_encoder() for us.
Signed-off-by: Boris Brezillon
---
drivers/gpu/drm/sti/sti_d
All outputs have a 1:1 relationship between connectors and encoders
and the driver is relying on the atomic helpers: we can drop the custom
->best_encoder() implementations and let the core call
drm_atomic_helper_best_encoder() for us.
Signed-off-by: Boris Brezillon
Acked-by: Mark Yao
---
driv
All outputs have a 1:1 relationship between connectors and encoders,
and the driver is relying on the atomic helpers: we can drop the custom
->best_encoder() implementations and let the core call
drm_atomic_helper_best_encoder() for us.
Signed-off-by: Boris Brezillon
Reviewed-by: Laurent Pinchart
For all outputs except DSI we have a 1:1 relationship between connectors
and encoders and the driver is relying on the atomic helpers: we can
drop the custom ->best_encoder() and let the core call
drm_atomic_helper_best_encoder() for us.
Signed-off-by: Boris Brezillon
---
drivers/gpu/drm/msm/edp
We have a 1:1 relationship between connectors and encoders and the
driver is relying on the atomic helpers: we can drop the custom
->best_encoder() implementation and let the core call
drm_atomic_helper_best_encoder() for us.
Signed-off-by: Boris Brezillon
---
drivers/gpu/drm/mediatek/mtk_dsi.c
For all outputs except dp_mst, we have a 1:1 relationship between
connectors and encoders and the driver is relying on the atomic helpers:
we can drop the custom ->best_encoder() implementation and let the core
call drm_atomic_helper_best_encoder() for us.
Signed-off-by: Boris Brezillon
---
driv
We have a 1:1 relationship between connectors and encoders and the
driver is relying on the atomic helpers: we can drop the custom
->best_encoder() and let the core call drm_atomic_helper_best_encoder()
for us.
Signed-off-by: Boris Brezillon
---
drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_rgb.c | 9
We have 1:1 relationship between connectors and encoders and the driver
is relying on the atomic helpers: we can drop the custom ->best_encoder()
implementations and let the core call drm_atomic_helper_best_encoder()
for us.
Signed-off-by: Boris Brezillon
---
drivers/gpu/drm/exynos/exynos_drm_dp
We have a 1:1 relationship between connectors and encoders and the
driver is relying on the atomic helpers: we can drop the custom
->best_encoder() and let the core call drm_atomic_helper_best_encoder()
for us.
Signed-off-by: Boris Brezillon
---
drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_output.c |
We have a 1:1 relationship between connectors and encoders and the
driver is relying on the atomic helpers: we can drop the custom
->best_encoder(), and let the core call drm_atomic_helper_best_encoder()
for us.
Signed-off-by: Boris Brezillon
---
drivers/gpu/drm/arc/arcpgu_hdmi.c | 18 --
Adapt drm_pick_crtcs() and update_connector_routing() to fallback to
drm_atomic_helper_best_encoder() if funcs->best_encoder() is NULL so
that DRM drivers can leave this hook unassigned if they know they want
to use drm_atomic_helper_best_encoder().
Update the vtables documentation accordingly.
S
Hello,
This patch series aims at replacing all dummy ->best_encoder()
implementations where we have a 1:1 relationship between encoders
and connectors.
The core already provides the drm_atomic_helper_best_encoder()
function which is taking the first encoder attached to the
connector (after making
assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160607/48b6c19c/attachment-0001.html>
-
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160607/0e0828f9/attachment.html>
On Mon, 30 May 2016 19:52:55 +0200
Daniel Vetter wrote:
> No dev->struct_mutex anywhere to be seen.
>
> Cc: Boris Brezillon
> Signed-off-by: Daniel Vetter
Acked-by: Boris Brezillon
> ---
> drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
In the absence of an fb_mmap callback, the fbdev code falls back to a
naive implementation which relies upon the DMA address being the same
as the physical address, and the buffer being physically contiguous
from there. Whilst this often holds for standard CMA allocations via
the platform's regular
Provide a small convenience wrapper that transmits
a set_tear_scanline command.
Cc: Archit Taneja
Cc: John Stultz
Cc: Thierry Reding
Cc: Sumit Semwal
Cc: Jani Nikula
Signed-off-by: Vinay Simha BN
--
v1:
* helper function suggested by Thierry
for set_tear_scanline
* Also includes sma
On Mon, 6 Jun 2016 11:41:34 -0300
Gustavo Padovan wrote:
> From: Gustavo Padovan
>
> Replace the legacy drm_send_vblank_event() with the new helper function.
>
> Signed-off-by: Gustavo Padovan
Acked-by: Boris Brezillon
> ---
> drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c | 2 +-
> 1 fi
On Mon, 6 Jun 2016 11:41:41 -0300
Gustavo Padovan wrote:
> From: Gustavo Padovan
>
> Replace the legacy drm_vblank_{get,put}() with the new helper functions.
>
> Signed-off-by: Gustavo Padovan
Acked-by: Boris Brezillon
> ---
> drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c | 2 +-
> 1 fi
Hello Yakir,
On 03/17/2016 05:47 PM, Heiko Stübner wrote:
> Split the dp core driver from exynos directory to bridge directory,
> and rename the core driver to analogix_dp_*, rename the platform
> code to exynos_dp.
>
> Beside the new analogix_dp driver would export six hooks.
> "analogix_dp_bin
Hi Daniel, Liviu,
Having just inadvertently merged -next into my working branch, I find
dev6d910bfa809e ("drm/hlcd: Use lockless gem BO free callback")
adversely affecting my board's ability to boot ;)
Since I (intentionally) don't have sufficient CMA to create a
framebuffer, drm_gem_cma_creat
On Tue, Jun 7, 2016 at 12:49 PM, Maarten Lankhorst
wrote:
> Change return value to int to propagate errors from gamma_set,
> and remove start parameter. Updates always use the full size,
> and some drivers even ignore the start parameter altogether.
>
> This is needed for atomic drivers, where an
Change return value to int to propagate errors from gamma_set,
and remove start parameter. Updates always use the full size,
and some drivers even ignore the start parameter altogether.
This is needed for atomic drivers, where an atomic commit can
fail with -EINTR or -ENOMEM and should be restarte
On 06.06.2016 23:41, Gustavo Padovan wrote:
> From: Gustavo Padovan
>
> Replace the legacy drm_vblank_{get,put}() with the new helper functions.
>
> Signed-off-by: Gustavo Padovan
[...]
> @@ -268,7 +268,7 @@ int amdgpu_crtc_page_flip(struct drm_crtc *crtc,
> return 0;
>
> vblank_clea
/
ret = radeon_kick_out_firmware_fb(pdev);
if (ret)
[...]
--
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/20160607/6d33be59
des.
Which is what they do at the moment too, but is there ever a valid
reason to do that without something being wrong?
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/20160607/efa883a2/attachment-0001.sig>
xt 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/20160607/c78c65dc/attachment.sig>
1 - 100 of 169 matches
Mail list logo