<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel/linux.git/drivers/gpu/drm/arm, branch v4.17.5</title>
<subtitle>Linux kernel stable tree (mirror)</subtitle>
<id>https://git.radix-linux.su/kernel/linux.git/atom?h=v4.17.5</id>
<link rel='self' href='https://git.radix-linux.su/kernel/linux.git/atom?h=v4.17.5'/>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/'/>
<updated>2018-03-14T11:41:01+00:00</updated>
<entry>
<title>drm: mali-dp: Add YUV-&gt;RGB conversion support for video layers</title>
<updated>2018-03-14T11:41:01+00:00</updated>
<author>
<name>Mihail Atanassov</name>
<email>mihail.atanassov@arm.com</email>
</author>
<published>2017-11-07T15:30:46+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=6e810eb508f4b937bc2a718bd4e5cd74cca55500'/>
<id>urn:sha1:6e810eb508f4b937bc2a718bd4e5cd74cca55500</id>
<content type='text'>
Internally Mali DP uses an RGB pipeline so video layers that support
YUV input buffers need to convert the input data to RGB. The YUV
buffers can have various encodings and this patch introduces support
for BT.601, BT.709 and BT.2020 encodings, both limited and full ranges.

This patch adds support for specifying the color encoding of the
input buffers for the planes that are backed by the video layers
and programs the YUV2RGB coefficients into hardware based on the
selected encoding.

Signed-off-by: Mihail Atanassov &lt;mihail.atanassov@arm.com&gt;
[updated to use standard properties]
Signed-off-by: Liviu Dudau &lt;liviu.dudau@arm.com&gt;
</content>
</entry>
<entry>
<title>drm: mali-dp: Turn off CRTC vblank when removing module.</title>
<updated>2018-03-14T11:38:03+00:00</updated>
<author>
<name>Liviu Dudau</name>
<email>Liviu.Dudau@arm.com</email>
</author>
<published>2018-02-27T18:23:06+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=57085dca982bd042f64aa23f5e03747595b2c8c0'/>
<id>urn:sha1:57085dca982bd042f64aa23f5e03747595b2c8c0</id>
<content type='text'>
When unbinding the mali-dp driver the drm_vblank_cleanup() function
warns us that the vblanks are still enabled. Fix that by calling
drm_crtc_vblank_off() in the malidp_unbind() function.

Signed-off-by: Liviu Dudau &lt;liviu.dudau@arm.com&gt;
</content>
</entry>
<entry>
<title>drm: arm: malidp: Use drm_atomic_helper_shutdown() to disable planes on removal</title>
<updated>2018-03-14T11:38:03+00:00</updated>
<author>
<name>Laurent Pinchart</name>
<email>laurent.pinchart+renesas@ideasonboard.com</email>
</author>
<published>2018-01-17T21:55:30+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=828f207077c699a8363415efbcb2a6d8a11bb100'/>
<id>urn:sha1:828f207077c699a8363415efbcb2a6d8a11bb100</id>
<content type='text'>
The plane cleanup handler currently calls drm_plane_helper_disable(),
which is a legacy helper function. Replace it with a call to
drm_atomic_helper_shutdown() at removal time.

Signed-off-by: Laurent Pinchart &lt;laurent.pinchart+renesas@ideasonboard.com&gt;
Signed-off-by: Liviu Dudau &lt;liviu.dudau@arm.com&gt;
</content>
</entry>
<entry>
<title>drm: arm: malidp: Don't destroy planes manually in error handlers</title>
<updated>2018-03-14T11:38:02+00:00</updated>
<author>
<name>Laurent Pinchart</name>
<email>laurent.pinchart+renesas@ideasonboard.com</email>
</author>
<published>2018-01-17T21:55:29+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=084ffbd7fd147ce6e114d82298c84f143d4fff7f'/>
<id>urn:sha1:084ffbd7fd147ce6e114d82298c84f143d4fff7f</id>
<content type='text'>
The top-level error handler calls drm_mode_config_cleanup() which will
destroy all planes. There's no need to destroy them manually in lower
error handlers.

As plane cleanup is now handled entirely by drm_mode_config_cleanup(),
we must ensure that the plane .destroy() handler frees allocated memory
for the plane object that was freed by malidp_de_planes_destroy(). Do so
by replacing the call to devm_kfree() in the .destroy() handler by
kfree(). devm_kfree() is currently a no-op as the plane memory is
allocated with kzalloc(), not devm_kzalloc().

Signed-off-by: Laurent Pinchart &lt;laurent.pinchart+renesas@ideasonboard.com&gt;
Signed-off-by: Liviu Dudau &lt;liviu.dudau@arm.com&gt;
</content>
</entry>
<entry>
<title>drm/mali-dp: Fix malidp_atomic_commit_hw_done() for event sending.</title>
<updated>2018-03-14T11:38:02+00:00</updated>
<author>
<name>Liviu Dudau</name>
<email>Liviu.Dudau@arm.com</email>
</author>
<published>2018-03-01T16:38:02+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=d862b2d622530d14072f3ae417a0525fb7361410'/>
<id>urn:sha1:d862b2d622530d14072f3ae417a0525fb7361410</id>
<content type='text'>
Mali DP hardware has a 'go' bit (config_valid) for making the new scene
parameters active at the next page flip. The problem with the current
code is that the driver first sets this bit and then proceeds to wait
for confirmation from the hardware that the configuration has been
updated before arming the vblank event. As config_valid is actually
asserted by the hardware after the vblank event, during the prefetch
phase, when we get to arming the vblank event we are going to send it
at the next vblank, in effect halving the vblank rate from the userspace
perspective.

Fix it by sending the userspace event from the IRQ handler, when we
handle the config_valid interrupt, which syncs with the time when the
hardware is active with the new parameters.

Reported-by: Alexandru-Cosmin Gheorghe &lt;alexandru-cosmin.gheorghe@arm.com&gt;
Signed-off-by: Liviu Dudau &lt;liviu.dudau@arm.com&gt;
</content>
</entry>
<entry>
<title>drm/arm/malidp: Disable pixel alpha blending for colors that do not have alpha</title>
<updated>2018-03-14T11:38:02+00:00</updated>
<author>
<name>Ayan Halder</name>
<email>ayan.halder@arm.com</email>
</author>
<published>2018-01-23T16:49:29+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=f0437819ad82088d4a07732222912345b5b98767'/>
<id>urn:sha1:f0437819ad82088d4a07732222912345b5b98767</id>
<content type='text'>
Mali dp needs to disable pixel alpha blending (use layer alpha blending) to
display color formats that do not contain alpha bits per pixel

This patch depends on:

"[PATCH v2 01/19] drm/fourcc: Add a alpha field to drm_format_info"

Signed-off-by: Ayan Kumar Halder &lt;ayan.halder@arm.com&gt;
Signed-off-by: Liviu Dudau &lt;liviu.dudau@arm.com&gt;
</content>
</entry>
<entry>
<title>drm: mali-dp: Fix bug on scaling with rotation</title>
<updated>2018-03-14T11:38:02+00:00</updated>
<author>
<name>Ayan Halder</name>
<email>ayan.halder@arm.com</email>
</author>
<published>2017-12-19T16:20:16+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=6cc3a505dcd60894a3ecefcbb40058873924bcf0'/>
<id>urn:sha1:6cc3a505dcd60894a3ecefcbb40058873924bcf0</id>
<content type='text'>
In the case, when the user wants to scale and rotate a layer by 90/270
degrees, the scaling engine input dimensions' parameters ie width and
height needs to be swapped with respect to the layer's input dimensions.
This means scaling engine input height should be set to layer's input
width and scaling engine input width should be set to
layer's input height.

Signed-off-by: Ayan Halder &lt;ayan.halder@arm.com&gt;
Signed-off-by: Liviu Dudau &lt;liviu.dudau@arm.com&gt;
</content>
</entry>
<entry>
<title>drm/mali-dp: Don't enable scaling engine for planes that only rotate.</title>
<updated>2018-03-14T11:38:02+00:00</updated>
<author>
<name>Liviu Dudau</name>
<email>Liviu.Dudau@arm.com</email>
</author>
<published>2017-12-15T16:42:19+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=e0521c05c13cca593d386533c61a646ab3dbcfd9'/>
<id>urn:sha1:e0521c05c13cca593d386533c61a646ab3dbcfd9</id>
<content type='text'>
Currently the scaling engine gets enabled for a plane where the input
size differs from the composition size. As rotation is done natively
by the plane's hardware layer, we don't need the scaling engine to be
enabled.

Signed-off-by: Liviu Dudau &lt;liviu.dudau@arm.com&gt;
</content>
</entry>
<entry>
<title>drm: mali-dp: Uninitialized variable in malidp_se_check_scaling()</title>
<updated>2018-03-14T11:38:02+00:00</updated>
<author>
<name>Dan Carpenter</name>
<email>dan.carpenter@oracle.com</email>
</author>
<published>2017-12-09T11:46:13+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=f2f2c85c66202edcb623626b3babce7850d8b4fb'/>
<id>urn:sha1:f2f2c85c66202edcb623626b3babce7850d8b4fb</id>
<content type='text'>
We use "mc" without initializing it if scaling is not necessary.

Fixes: 28ce675b7474 ("drm: mali-dp: Add plane upscaling support")
Signed-off-by: Dan Carpenter &lt;dan.carpenter@oracle.com&gt;
Reviewed-by: Mihail Atanassov &lt;Mihail.Atanassov@arm.com&gt;
Signed-off-by: Liviu Dudau &lt;liviu.dudau@arm.com&gt;
</content>
</entry>
<entry>
<title>drm/mali-dp: Align pitch size to be multiple of bus burst read size.</title>
<updated>2018-03-14T11:38:02+00:00</updated>
<author>
<name>Liviu Dudau</name>
<email>Liviu.Dudau@arm.com</email>
</author>
<published>2017-12-05T15:29:00+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=5ed4fdfa58f091a65cb533cc6b8f47ade4cc4475'/>
<id>urn:sha1:5ed4fdfa58f091a65cb533cc6b8f47ade4cc4475</id>
<content type='text'>
Mali DP hardware needs pitch line sizes aligned to the bus burst
size for reads, so take that into consideration when allocating dumb
buffers. If the layer is rotated then the stride size requirement is
even larger for some hardware versions, so allocate for the worst case
scenario. Update the -&gt;dumb_create() hook to a driver specific function
that sets the correct pitch size.

Reported-by: Ayan Halder &lt;ayan.halder@arm.com&gt;
Signed-off-by: Liviu Dudau &lt;liviu.dudau@arm.com&gt;
</content>
</entry>
</feed>
