On 08/01/18 13:07, Laurent Pinchart wrote:
>> Yes, this is a subject I have complained a few times: DRM keeping the
>> state. I think that will be a problem with many other properties too. An
>> app could change a platform specific property, which no other app is
>> aware of, and after that no oth
It was only checking the divider when determing the closest match if
it could not match the requested rate exactly.
For a projector connected to an Olimex A20-OLinuXino-LIME using HDMI
with a native resolution of 1280x800 and pixel clock of 83.5 MHz, this
resulted in 1280x800 mode not being availa
It is possible that if there is no exact rate match and
"rounded = clk_hw_round_rate(parent, ideal)" gives high enough values
(e.g. if rounded is 2 * ideal) that the condition
"abs(rate - rounded / i) < abs(rate - best_parent / best_div)" is never
met and best_parent is never set. This results in r
On 08.01.2018 15:39, Thierry Reding wrote:
> On Mon, Jan 08, 2018 at 08:42:50AM +0100, Thierry Reding wrote:
>> On Fri, Jan 05, 2018 at 05:58:17PM +0300, Dmitry Osipenko wrote:
>>> On 05.01.2018 17:17, Thierry Reding wrote:
Hi Dave,
The following changes since commit
9428088c90
It seems wrong to define PHYS_OFFSET here in a gpu driver.
Is there an actual ARC system using vivante?
The bit of code that uses PHYS_OFFSET looks pretty ARM specific.
If not, then at least maybe
+#if !define (PHYS_OFFSET) && defined (COMPILE_TEST)
+#define PHY_OFFSET 0
+#endif
would be more ap
On 08.01.2018 18:47, Thierry Reding wrote:
> On Mon, Jan 08, 2018 at 04:47:32PM +0300, Dmitry Osipenko wrote:
>> On 08.01.2018 10:42, Thierry Reding wrote:
>>> On Fri, Jan 05, 2018 at 05:58:17PM +0300, Dmitry Osipenko wrote:
On 05.01.2018 17:17, Thierry Reding wrote:
> Hi Dave,
>
>
On 08.01.2018 10:42, Thierry Reding wrote:
> On Fri, Jan 05, 2018 at 05:58:17PM +0300, Dmitry Osipenko wrote:
>> On 05.01.2018 17:17, Thierry Reding wrote:
>>> Hi Dave,
>>>
>>> The following changes since commit 9428088c90b6f7d5edd2a1b0d742c75339b36f6e:
>>>
>>> drm/qxl: reapply cursor after reset
best_div is set to i which corresponds to rate halving when it should be
set to j which corresponds to the divider.
Fixes: 9c5681011a0c ("drm/sun4i: Add HDMI support")
Signed-off-by: Jonathan Liu
---
drivers/gpu/drm/sun4i/sun4i_hdmi_tmds_clk.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-
On 08.01.2018 18:49, Thierry Reding wrote:
> On Mon, Jan 08, 2018 at 04:47:42PM +0300, Dmitry Osipenko wrote:
>> On 08.01.2018 15:39, Thierry Reding wrote:
>>> On Mon, Jan 08, 2018 at 08:42:50AM +0100, Thierry Reding wrote:
On Fri, Jan 05, 2018 at 05:58:17PM +0300, Dmitry Osipenko wrote:
>
Sean,
On Mon, Jan 8, 2018 at 4:50 PM, Sean Paul wrote:
> This patch adds the framework required to add HDCP support to intel
> connectors. It implements Aksv loading from fuse, and parts 1/2/3
> of the HDCP authentication scheme.
>
> Note that without shim implementations, this does not actually
This patchset fixes several issues in sun4i_tmds_determine_rate that I
discovered while trying to get a projector connected to an Olimex
A20-OLinuXino-LIME using HDMI with a native resolution of 1280x800 and
pixel clock of 83.5 MHz to display at its native resolution.
Changes for v3:
- Improve com
On Fri, Dec 22, 2017 at 08:38:38AM +0200, Peter Ujfalusi wrote:
>
>
> On 2017-12-21 15:17, Daniel Vetter wrote:
> > On Thu, Dec 21, 2017 at 02:11:01PM +0200, Peter Ujfalusi wrote:
> >> To avoid zpos collision, use the normalized_zpos when configuring the
> >> zorder of the plane.
> >>
> >> Signed
On Sun, Dec 24, 2017 at 10:45:24PM +0100, Stefan Brüns wrote:
> The ACK/NACK implementation as found in e.g. the G965 has the falling
> clock edge and the release of the data line to ACK the received byte
> happen at the same time.
>
> Some HDMI-to-VGA converters apparently read the ACK not in the
On Sun, Dec 31, 2017 at 01:40:46PM -0500, Ilia Mirkin wrote:
> On Sun, Dec 31, 2017 at 1:15 PM, Ilia Mirkin wrote:
> > Currently there's no way to allow a driver to reimplement any ioctls
> > from the drm core. This can be desirable to, e.g., override fixed format
> > selection logic, without turn
On Sun, Dec 31, 2017 at 11:34:54PM +0100, Stefan Brüns wrote:
> The ACK/NACK implementation as found in e.g. the G965 has the falling
> clock edge and the release of the data line after the ACK for the received
> byte happen at the same time.
>
> This is conformant with the I2C specification, whic
2017-12-23 12:01 GMT+01:00 Yisheng Xie :
> Default ioremap is ioremap_nocache, so devm_ioremap has the same
> function with devm_ioremap_nocache, which can just be killed to
> save the size of devres.o
That looks true for arm and arm64 architectures but not, for exemple, for ia64:
https://elixir.f
On Fri, Jan 05, 2018 at 10:16:04AM +0100, Christian König wrote:
> Am 04.01.2018 um 22:12 schrieb Samuel Li:
> > Change-Id: I03c22a890d2305f3243d88019d1a28bddd4ddda7
> > Signed-off-by: Samuel Li
>
> Reviewed-by: Christian König
Want to push to drm-misc or some other plan with this?
-Daniel
>
On Thu, Jan 04, 2018 at 06:05:52PM -0800, Hyun Kwon wrote:
> Helpers for framebuffers backed by cma allocator.
>
> Signed-off-by: Hyun Kwon
Please take a look at the very new drm_gem_framebuffer_helper.c file.
There's lots of helpers in there that you can use to remove almost the
entire file her
On Thu, Jan 04, 2018 at 06:05:51PM -0800, Hyun Kwon wrote:
> xlnx_crtc is a part of Xilinx DRM KMS and a layer that
> provides some interface between the Xilinx DRM KMS and
> crtc drivers.
>
> Signed-off-by: Hyun Kwon
Personal style, but I don't see much value in these small helpers.
Splitting t
On Thu, Jan 04, 2018 at 06:05:56PM -0800, Hyun Kwon wrote:
> Xilinx ZynqMP has a hardened display pipeline. The pipeline can
> be logically partitioned into 2 parts: display and DisplayPort.
> This driver handles the display part of the pipeline that handles
> buffer management and blending.
>
> S
On Thu, Jan 04, 2018 at 06:05:54PM -0800, Hyun Kwon wrote:
> Xilinx has various platforms for display, where users can create
> using multiple IPs in the programmable FPGA fabric, or where
> some hardened piepline is available on the chip. Furthermore,
> hardened pipeline can also interact with sof
On Thu, Jan 04, 2018 at 06:05:59PM -0800, Hyun Kwon wrote:
> Debugfs can be used to exploit some specific setting. Main purpose
> is for testing and debug diagnostic.
>
> Signed-off-by: Tejas Upadhyay
> Signed-off-by: Hyun Kwon
Hm, not sure what's the use, it seems to just be for setting/gettin
On Thu, Jan 04, 2018 at 06:05:49PM -0800, Hyun Kwon wrote:
> Hi,
>
> This patchset adds the DRM KMS driver for Xilinx ZynqMP DisplayPort
> subsystem. The Xilinx ZynqMP SoC has a hardened full display pipeline
> which supports blending of up to 2 planes, and the encoder is
> DisplayPort v1.2 compat
https://bugs.freedesktop.org/show_bug.cgi?id=104549
Bug ID: 104549
Summary: [radeonsi] [wine] [apitrace] Silent Hunter 3 2D
texture artifacts / corrupted 3D redering on Polaris
Product: Mesa
Version: 17.3
Hardware: x86-64 (
Am Montag, den 08.01.2018, 11:16 -0700 schrieb Joshua Clayton:
> It seems wrong to define PHYS_OFFSET here in a gpu driver.
> Is there an actual ARC system using vivante?
Yes.
> The bit of code that uses PHYS_OFFSET looks pretty ARM specific.
>
> If not, then at least maybe
>
> +#if !define (PH
On Mon, Jan 08, 2018 at 07:46:27PM -0600, David Lechner wrote:
> On 01/07/2018 11:44 AM, Noralf Trønnes wrote:
> > Embed the mode in tinydrm_connector instead of doing an devm_ allocation.
> > Remove unnecessary use of ret variable at the end of
> > tinydrm_display_pipe_init().
> >
> > Signed-off-
In some cases, the display engine needs to apply some quirks during the
VBLANK event. In the Display Engine 1.0 case for example, we can only
disable the frontend once the backend has been, which is at VBLANK.
Let's introduce a callback that can be implemented by the various engines.
Reviewed-by:
Hi,
This is a first serie to enable the display engine frontend.
This hardware block is found in the first generation Display Engine from
Allwinner. Its role is to implement more advanced features that the
associated backend, even though the backend alone can be used (and was used
so far) for bas
Setup the line stride in the buffer setup function, since it's tied to the
buffer itself, and is not needed when we do not set the buffer in the
backend.
This is for example the case when using the frontend and then routing its
output to the backend.
Reviewed-by: Chen-Yu Tsai
Reviewed-by: Neil A
Our operations were missing some documentation to explain what was expected
from them.
Let's make that clearer.
Reviewed-by: Chen-Yu Tsai
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/sun4i/sunxi_engine.h | 46 +-
1 file changed, 46 insertions(+)
diff --git a/dr
The function converting the DRM format to its equivalent in the backend
registers was assuming that we were having a plane.
However, we might want to use that function when setting up a plane using
the frontend, in which case we will not have a plane associated to the
backend's layer. Yet, we stil
We have some restrictions on what the planes and CRTC can provide that are
tied to only one generation of display engines.
For example, on the first generation, we can only have one YUV plane or one
plane that uses the frontend output.
Let's allow our engines to provide an atomic_check callback t
We have to implement some display engine specific behaviours in
atomic_begin. Let's add a function for that.
Reviewed-by: Chen-Yu Tsai
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/sun4i/sun4i_crtc.c | 6 +-
drivers/gpu/drm/sun4i/sunxi_engine.h | 13 +
2 files changed, 18
We will need to store some additional data in the future to the state.
Create a custom plane state that will embed those data, in order to store
the pipe or whether or not that plane should use the frontend.
Reviewed-by: Chen-Yu Tsai
Reviewed-by: Neil Armstrong
Signed-off-by: Maxime Ripard
---
Now that we have everything in place, we can start enabling the frontend.
This is more difficult than one would assume since there can only be one
plane using the frontend per-backend.
We therefore need to make sure that the userspace will not try to setup
multiple planes using it, since that woul
During a hardware commit, the commit bit in the backend will only be
cleared if the TCON is enabled. Use the runtime_pm variant of the
atomic_commit_tail hook that makes sure that the CRTC, our TCON, is enabled
when we perform an atomic_commit.
Reviewed-by: Chen-Yu Tsai
Signed-off-by: Maxime Ripa
If we try to read the backend registers while it fetches the new values, we
end up with the value of some random register instead of the one we asked
for.
In order to prevent that, let's make sure that the very first thing we do
during our atomic modesetting is to let the commit bit come to a rest
The display frontend can be used to do hardware scaling, colorspaces
conversion or to implement the buffer format output by the Cedar VPU.
Since we're starting to have some support for it in the DRM driver, let's
enable its DT node.
Reviewed-by: Chen-Yu Tsai
Signed-off-by: Maxime Ripard
---
ar
The display frontend is an hardware block that can be used to implement
some more advanced features like hardware scaling or colorspace
conversions. It can also be used to implement the output format of the VPU.
Let's create a minimal driver for it that will only enable the hardware
scaling featur
Now that we have a driver, we can make use of it. This is done by
adding a flag to our custom plane state that will trigger whether we should
use the frontend on that particular plane or not.
The rest is just plumbing to set up the backend to not perform the DMA but
receive its data from the front
On Wed, Jan 03, 2018 at 11:21:05PM +0100, Noralf Trønnes wrote:
> Export the following functions so in-kernel users can allocate
> dumb buffers:
> - drm_file_alloc
> - drm_file_free
> - drm_prime_handle_to_fd_ioctl
> - drm_mode_addfb2
> - drm_mode_create_dumb_ioctl
> - drm_dropmaster_ioctl
>
> Sig
On Wed, Jan 03, 2018 at 11:21:06PM +0100, Noralf Trønnes wrote:
> If struct fb_ops is defined in a library like cma, fb_open() and fbcon
> takes a ref on the library instead of the driver module. Use
> fb_ops.fb_open/fb_release to ensure that the driver module is pinned.
>
> Signed-off-by: Noralf
On Wed, Jan 03, 2018 at 11:21:04PM +0100, Noralf Trønnes wrote:
> Remove a couple of trailing spaces.
>
> Signed-off-by: Noralf Trønnes
Reviewed-by: Daniel Vetter
> ---
> drivers/gpu/drm/drm_ioctl.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/
On Wed, Jan 03, 2018 at 11:21:03PM +0100, Noralf Trønnes wrote:
> From: David Herrmann
>
> Rather than doing drm_file allocation/destruction right in the fops, lets
> provide separate helpers. This decouples drm_file management from the
> still-mandatory drm-fops. It prepares for use of drm_file
On Wed, Jan 03, 2018 at 11:21:06PM +0100, Noralf Trønnes wrote:
> If struct fb_ops is defined in a library like cma, fb_open() and fbcon
> takes a ref on the library instead of the driver module. Use
> fb_ops.fb_open/fb_release to ensure that the driver module is pinned.
>
> Signed-off-by: Noralf
On Wed, Jan 03, 2018 at 11:21:07PM +0100, Noralf Trønnes wrote:
> Keep track of fbdev users and only restore fbdev in
> drm_fb_helper_restore_fbdev_mode_unlocked() when in use. This avoids
> fbdev being restored in drm_driver.last_close when nothing uses it.
> Additionally fbdev is turned off when
Hi
On Tue, Jan 9, 2018 at 11:16 AM, Daniel Vetter wrote:
> On Wed, Jan 03, 2018 at 11:21:05PM +0100, Noralf Trønnes wrote:
>> Export the following functions so in-kernel users can allocate
>> dumb buffers:
>> - drm_file_alloc
>> - drm_file_free
>> - drm_prime_handle_to_fd_ioctl
>> - drm_mode_addf
Hi
On Tue, Jan 9, 2018 at 11:20 AM, Daniel Vetter wrote:
> On Wed, Jan 03, 2018 at 11:21:03PM +0100, Noralf Trønnes wrote:
>> From: David Herrmann
>>
>> Rather than doing drm_file allocation/destruction right in the fops, lets
>> provide separate helpers. This decouples drm_file management from
On Wed, Jan 03, 2018 at 11:21:08PM +0100, Noralf Trønnes wrote:
> Prepare for generic fbdev emulation by letting DRM core work directly
> with the fbdev compatibility layer. This is done by adding new fbdev
> helper vtable callbacks for restore, hotplug_event, unregister and
> release.
>
> Signed-
On 12/31/2017 02:31 AM, Jernej Skrabec wrote:
Parts of PHY code could be useful also for custom PHYs. For example,
Allwinner A83T has custom PHY which is probably Synopsys gen2 PHY
with few additional memory mapped registers, so most of the Synopsys PHY
related code could be reused.
It turns o
On Wed, Jan 03, 2018 at 11:21:09PM +0100, Noralf Trønnes wrote:
> Add generic fbdev emulation which uses a drm_file to get a dumb_buffer
> and drm_framebuffer. The buffer is exported and vmap/mmap called on
> the dma-buf.
>
> Signed-off-by: Noralf Trønnes
> ---
> drivers/gpu/drm/drm_fb_helper.c
Hi Brian,
And many thanks for implementing these TODOs.
On 01/06/2018 01:38 AM, Brian Norris wrote:
> This takes care of 2 TODOs in this driver, by using the common DSI
> packet-marshalling code instead of our custom short/long write code.
> This both saves us some duplicated code and gets us fre
There was a typo in the width spelling of the (unused)
SUN4I_BACKEND_IYUVLINEWITDTH_REG macro. Fix it.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/sun4i/sun4i_backend.h | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/sun4i/sun4i_backend.h
b/drivers/gp
The function supposed to update a plane's coordinates is called in both
branches of our function. Let's move it out the if statement.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/sun4i/sun4i_layer.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/sun4i/s
In order to support normalized zpos, we need to call
drm_atomic_normalize_zpos in our driver's drm_mode_config_funcs'
atomic_check.
Let's duplicate the definition of drm_atomic_helper_check for now.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/sun4i/sun4i_framebuffer.c | 14 +-
Hi,
This serie aims at enhancing the support for our planes in the current drm
driver on the first generation of Allwinner's display engine.
This also introduces a few generic stuff, as well as some conversion for
some other drivers.
This series basically implements three things that look orthog
Now that the core has a drm format helper to tell if a format embeds an
alpha component in it, let's use it.
Cc: Inki Dae
Cc: Joonyoung Shim
Cc: Kyungmin Park
Cc: Seung-Woo Kim
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/exynos/exynos_mixer.c | 14 +-
1 file changed, 1 inser
Now that the core has a drm format helper to tell if a format embeds an
alpha component in it, let's use it.
Cc: Eric Anholt
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/vc4/vc4_plane.c | 19 +--
1 file changed, 9 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/
Now that the core has a drm format helper to tell if a format embeds an
alpha component in it, let's use it.
Cc: Mark Yao
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 13 +
1 file changed, 1 insertion(+), 12 deletions(-)
diff --git a/drivers/gpu/dr
Our various planes have a configurable zpos, that combined with the pipes
allow to configure the composition.
Since the interaction between the pipes, zpos and alphas framebuffers are
not trivials, let's just enable the zpos as an immutable property for now,
and use that zpos in our atomic_update
There's a bunch of drivers that duplicate the same function to know if a
particular format embeds an alpha component or not.
Let's create a helper to avoid duplicating that logic.
Cc: Boris Brezillon
Cc: Eric Anholt
Cc: Inki Dae
Cc: Joonyoung Shim
Cc: Kyungmin Park
Cc: Laurent Pinchart
Cc:
Now that we have support for per-plane alpha in the core, let's use it.
Cc: Boris Brezillon
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.h| 13 +---
drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c | 89 ++
2 files changed, 14 insertions(+), 88
Some drivers duplicate the logic to create a property to store a per-plane
alpha.
Let's create a helper in order to move that to the core.
Cc: Boris Brezillon
Cc: Laurent Pinchart
Signed-off-by: Maxime Ripard
---
Documentation/gpu/kms-properties.csv | 2 +-
drivers/gpu/drm/drm_atomic.c
The sun4i_plane_desc structure was somehow indented to two tabulations
instead of one as we shoud do. Fix that.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/sun4i/sun4i_layer.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/sun4i/sun4i_layer.c
b/
Now that the core has a drm format helper to tell if a format embeds an
alpha component in it, let's use it.
Cc: Boris Brezillon
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c | 20 ++
1 file changed, 3 insertions(+), 17 deletions(-)
diff --git
Now that we have support for per-plane alpha in the core, let's use it.
Cc: Laurent Pinchart
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/rcar-du/rcar_du_drv.h | 1 +-
drivers/gpu/drm/rcar-du/rcar_du_kms.c | 5 +---
drivers/gpu/drm/rcar-du/rcar_du_plane.c | 15 +++--
drivers/gpu/d
Since we now have a way to enforce the zpos, check for the number of alpha
planes, the only missing part is to assign our pipe automatically instead
of hardcoding it.
The algorithm is quite simple, but requires two iterations over the list of
planes.
In the first one (which is the same one that w
Now that we have everything in place, we can make zpos configurable now.
Change the zpos property from an immutable one to a regular.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/sun4i/sun4i_layer.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/sun4
Our backend supports a per-plane alpha property. Support it through our new
helper.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/sun4i/sun4i_backend.c | 18 +++---
drivers/gpu/drm/sun4i/sun4i_backend.h | 3 +++
drivers/gpu/drm/sun4i/sun4i_layer.c | 2 ++
3 files changed, 20 i
The our plane state zpos value will be set only if there's an existing
state attached to the plane when creating the property.
However, this is not the case during the probe, and we therefore need to
put our default value in our reset hook.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/sun4i
Due to the way the composition is done in hardware, we can only have a
single alpha-enabled plane active at a time, placed in the second (highest
priority) pipe.
Make sure of that in our atomic_check to not end up in an impossible
scenario.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/sun4i
We've had some code for quite some time to prevent the alpha bug from
happening on the lowest primary plane. Since we now check for this in our
atomic_check, we can simply remove it.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/sun4i/sun4i_backend.c | 12 +++-
1 file changed, 3 inser
On Tuesday, January 9, 2018 11:01:43 AM CET Vivek Gautam wrote:
> This series provides the support for turning on the arm-smmu's
> clocks/power domains using runtime pm. This is done using the
> recently introduced device links patches, which lets the smmu's
> runtime to follow the master's runtime
Hi all,
Do you think the patch is "acceptable" or should I change it somehow?
Any opinion is welcomed : )
Many thanks,
Philippe :-)
On 11/24/2017 02:54 PM, Philippe CORNU wrote:
> Hi Peter,
>
> On 11/13/2017 11:40 AM, Philippe CORNU wrote:
>> Hi Peter,
>>
>> On 11/12/2017 01:31 PM, Peter Rosin
Use the plane index as default zpos for all planes. Even if the
application is not setting zpos/zorder explicitly we will have unique zpos
for each plane.
Planes with identical zpos value will result undefined behavior:
disappearing planes, screen flickering and it is not supported by the
hardware
https://bugs.freedesktop.org/show_bug.cgi?id=104555
Bug ID: 104555
Summary: RX 560 DPM auto - driver doesn't reliably set high
clocks, causing stutter in mpv
Product: DRI
Version: unspecified
Hardware: x86-64 (AMD64)
On Tue, 9 Jan 2018 11:56:20 +0100
Maxime Ripard wrote:
> There's a bunch of drivers that duplicate the same function to know if a
> particular format embeds an alpha component or not.
>
> Let's create a helper to avoid duplicating that logic.
>
> Cc: Boris Brezillon
Reviewed-by: Boris Brezil
On Tue, 9 Jan 2018 11:56:21 +0100
Maxime Ripard wrote:
> Now that the core has a drm format helper to tell if a format embeds an
> alpha component in it, let's use it.
>
> Cc: Boris Brezillon
Acked-by: Boris Brezillon
> Signed-off-by: Maxime Ripard
> ---
> drivers/gpu/drm/atmel-hlcdc/atme
Hi Maxime,
Thank you for the patch.
On Tuesday, 9 January 2018 12:56:20 EET Maxime Ripard wrote:
> There's a bunch of drivers that duplicate the same function to know if a
> particular format embeds an alpha component or not.
>
> Let's create a helper to avoid duplicating that logic.
>
> Cc: Bo
On Tue, 9 Jan 2018 11:56:25 +0100
Maxime Ripard wrote:
> Some drivers duplicate the logic to create a property to store a per-plane
> alpha.
>
> Let's create a helper in order to move that to the core.
>
> Cc: Boris Brezillon
Reviewed-by: Boris Brezillon
> Cc: Laurent Pinchart
> Signed-of
On Tue, 9 Jan 2018 11:56:26 +0100
Maxime Ripard wrote:
> Now that we have support for per-plane alpha in the core, let's use it.
>
> Cc: Boris Brezillon
Acked-by: Boris Brezillon
> Signed-off-by: Maxime Ripard
> ---
> drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.h| 13 +---
> drivers/gp
On Tue, Jan 09, 2018 at 11:56:25AM +0100, Maxime Ripard wrote:
> Some drivers duplicate the logic to create a property to store a per-plane
> alpha.
>
> Let's create a helper in order to move that to the core.
>
> Cc: Boris Brezillon
> Cc: Laurent Pinchart
> Signed-off-by: Maxime Ripard
Do we
Hi Maxime,
Thank you for the patch.
On Tuesday, 9 January 2018 12:56:25 EET Maxime Ripard wrote:
> Some drivers duplicate the logic to create a property to store a per-plane
> alpha.
>
> Let's create a helper in order to move that to the core.
>
> Cc: Boris Brezillon
> Cc: Laurent Pinchart
>
On Tue, Jan 09, 2018 at 11:56:24AM +0100, Maxime Ripard wrote:
> Now that the core has a drm format helper to tell if a format embeds an
> alpha component in it, let's use it.
>
> Cc: Eric Anholt
> Signed-off-by: Maxime Ripard
On patches 1-5:
Reviewed-by: Daniel Vetter
> ---
> drivers/gpu/d
Hi Maxime,
Thank you for the patch.
On Tuesday, 9 January 2018 12:56:27 EET Maxime Ripard wrote:
> Now that we have support for per-plane alpha in the core, let's use it.
>
> Cc: Laurent Pinchart
> Signed-off-by: Maxime Ripard
Reviewed-by: Laurent Pinchart
> ---
> drivers/gpu/drm/rcar-du/r
On Fri, Dec 22, 2017 at 05:15:05PM +0200, Peter Ujfalusi wrote:
> Hi,
>
> On 2017-12-22 12:12, Ville Syrjälä wrote:
> > On Fri, Dec 22, 2017 at 11:16:47AM +0200, Tomi Valkeinen wrote:
> >> On 21/12/17 17:12, Ville Syrjälä wrote:
> >>
> If the userspace knows this, then it knows which primary
On Tue, Jan 09, 2018 at 01:45:56PM +0200, Peter Ujfalusi wrote:
> Use the plane index as default zpos for all planes. Even if the
> application is not setting zpos/zorder explicitly we will have unique zpos
> for each plane.
>
> Planes with identical zpos value will result undefined behavior:
> di
First of all a Happy New Year for all of you!
And secondly: can this v5 patch series be reviewed/merged? It's been waiting
for that for a very long time now...
Regards,
Hans
On 12/11/17 09:57, Hans Verkuil wrote:
> Ping again. Added a CC to Ville whom I inexplicably forgot to add when
>
Hi Peter,
Thank you for the patch.
On Tuesday, 9 January 2018 13:45:56 EET Peter Ujfalusi wrote:
> Use the plane index as default zpos for all planes. Even if the
> application is not setting zpos/zorder explicitly we will have unique zpos
> for each plane.
>
> Planes with identical zpos value w
https://bugs.freedesktop.org/show_bug.cgi?id=104556
Bug ID: 104556
Summary: WARNING: CPU: 1 PID: 7288 at mm/slab_common.c:971
kmalloc_slab+0x5e/0x70
Product: DRI
Version: XOrg git
Hardware: Other
OS: All
https://bugs.freedesktop.org/show_bug.cgi?id=104556
--- Comment #1 from Paul Menzel ---
```
$ dmesg
[0.00] Linux version 4.14.12.mx64.200 (r...@orpheus.molgen.mpg.de) (gcc
version 5.3.0 (GCC)) #1 SMP Mon Jan 8 12:53:28 CET 2018
[0.00] Command line: BOOT_IMAGE=/boot/bzImage-4.14.12
Hi Jernej,
Thank you for the patch.
On Saturday, 30 December 2017 23:01:55 EET Jernej Skrabec wrote:
> Allwinner SoCs have dw hdmi controller v1.32a which exhibits same
> magenta line issue as i.MX6Q and i.MX6DL. Enable workaround for it.
>
> Tests show that one iteration is enough.
>
> Signed-
https://bugs.freedesktop.org/show_bug.cgi?id=104556
--- Comment #2 from Paul Menzel ---
The system seems to hang afterward, even after killing the test. The X.Org X
server doesn’t start, and it doesn’t shut down.
--
You are receiving this mail because:
You are the assignee for the bug._
On 28 December 2017 at 12:53, Tomeu Vizoso wrote:
> This is to allow clients running within VMs to be able to communicate
> with a compositor in the host. Clients will use the communication
> protocol that the compositor supports, and virtio-gpu will assist with
> making buffers available in both
Hi Archit, Andrzej & Laurent,
Regarding this patch from Brian, I think it could be nice to merge it
(1xAcked-by, 2xReviewed-by).
Could you please have a look?
Only the small "typo" in the headline needs to be changed.
Many thanks,
Philippe :-)
On 11/28/2017 10:34 AM, Philippe CORNU wrote:
> H
2018-01-09 12:56 GMT+01:00 Peter Rosin :
> On 2018-01-09 12:28, Philippe CORNU wrote:
>> Hi all,
>>
>> Do you think the patch is "acceptable" or should I change it somehow?
>> Any opinion is welcomed : )
>
> Maybe you should try Daniel Vetter? He was very helpful (thanks) when
> I worked on the clu
Hi Laurent,
On Tue, Jan 09, 2018 at 02:29:58PM +0200, Laurent Pinchart wrote:
> On Tuesday, 9 January 2018 12:56:20 EET Maxime Ripard wrote:
> > There's a bunch of drivers that duplicate the same function to know if a
> > particular format embeds an alpha component or not.
> >
> > Let's create a
Hi Jernej,
Thank you for the patch.
On Saturday, 30 December 2017 23:01:56 EET Jernej Skrabec wrote:
> Parts of PHY code could be useful also for custom PHYs. For example,
> Allwinner A83T has custom PHY which is probably Synopsys gen2 PHY
> with few additional memory mapped registers, so most of
Hi Brian,
On Tuesday, 28 November 2017 20:21:23 EET Brian Norris wrote:
> On Tue, Nov 28, 2017 at 02:51:46PM +0200, Laurent Pinchart wrote:
> > Hi Brian,
> >
> > Thank you for the patch.
> >
> > I'd mention dw-mipi-dsi in the subject line as the directory contains the
> > dw-hdmi driver as well
Hi Philippe,
On Tuesday, 9 January 2018 15:01:02 EET Philippe CORNU wrote:
> Hi Archit, Andrzej & Laurent,
>
> Regarding this patch from Brian, I think it could be nice to merge it
> (1xAcked-by, 2xReviewed-by).
>
> Could you please have a look?
>
> Only the small "typo" in the headline needs
1 - 100 of 148 matches
Mail list logo
