Unfortunately the patches are already comitted (with a better commit
message IIRC).
But the variable name sounds just like a style nit pick to me we can fix
in a separate patch as well.
Thanks,
Christian.
Am 25.01.2018 um 00:24 schrieb Sinclair Yeh:
Hi,
Sorry, I've been on a leave. Catchi
https://bugs.freedesktop.org/show_bug.cgi?id=104762
--- Comment #7 from Christoph Haag ---
(In reply to Timothy Arceri from comment #5)
> Created attachment 136950 [details] [review]
> possible fix
>
> I wasn't able to reproduce the issue, but can you give this patch a try?
Preliminary result:
Op 24-01-18 om 22:47 schreef Ville Syrjala:
> From: Ville Syrjälä
>
> We use 32bit bitmasks to track planes/crtcs/encoders/connectors.
> Naturally we can only do that if the index of those objects stays
> below 32. Issue a warning whenever we exceed that limit, hopefully
> prompting someone to fix
Am Mittwoch, den 24.01.2018, 14:49 -0600 schrieb Rob Herring:
> On Wed, Jan 24, 2018 at 9:37 AM, Lucas Stach
> wrote:
> > The module autoloading can be triggered through the GPU core nodes
> > and the necessary platform device for the DRM toplevel device will
> > be instantiated on module init.
>
https://bugs.freedesktop.org/show_bug.cgi?id=104723
Petri Latvala changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
there is a scheduling balance issue about get node like:
a. process A allocates full memory and use it for submission.
b. process B tries to allocates memory, will wait for process A BO idle in
eviction.
c. process A completes the job, process B eviction will put process A BO node,
but in the mean
https://bugs.freedesktop.org/show_bug.cgi?id=87172
--- Comment #2 from Paolo Devoti ---
Same issue on Ubuntu 17.10 AMD RX480 and an UHD tv
see also
https://bugs.launchpad.net/ubuntu/+bug/1725395
--
You are receiving this mail because:
You are the assignee for the bug.__
Am 25.01.2018 um 10:59 schrieb Chunming Zhou:
there is a scheduling balance issue about get node like:
a. process A allocates full memory and use it for submission.
b. process B tries to allocates memory, will wait for process A BO idle in
eviction.
c. process A completes the job, process B evic
On Wednesday, 2018-01-24 14:31:08 -0800, Dylan Baker wrote:
> ping
Both patches are correct:
Reviewed-by: Eric Engestrom
>
> Quoting Dylan Baker (2018-01-12 11:57:34)
> > Here's a few things I've caught as I've started trying to add the meson
> > build to our CI system.
> >
> > Dylan Baker (2)
Hi Dylan,
To make it easier to spot these, do set the git subject prefix to PATCH libdrm.
See autogen.sh for an example.
On 12 January 2018 at 19:57, Dylan Baker wrote:
> Copy and paste error from exynos.
>
> Signed-off-by: Dylan Baker
> ---
> freedreno/meson.build | 2 +-
> 1 file changed, 1
https://bugs.freedesktop.org/show_bug.cgi?id=104762
--- Comment #8 from Dieter Nützel ---
Sometimes I wiped this, too.
.cache/plasmashell/qmlcache/
.cache/ksycoca5_de_***
.cache/plasma-svgelements-***
.cache/plasma_theme_***
.cache/icon-cache.kcache
All above files would be regenerated automati
Add a fix & a warning in the dsi_host_transfer().
Version 2:
- Simplify the 2 patches following comments from Brian Norris.
- Swap the 2 patches as the return value is only on tx and
in case of rx requests the warning is there.
Version 1:
- Initial commit
Philippe Cornu (2):
drm/bridge/synop
The dw_mipi_dsi_host_transfer() must return the number of
bytes transmitted/received on success instead of 0.
Note: As the read feature is not implemented, only the
transmitted number of bytes is returned for the moment.
Signed-off-by: Philippe Cornu
---
drivers/gpu/drm/bridge/synopsys/dw-mipi-d
The dcs/generic dsi read feature is not yet implemented so it
is important to warn the host_transfer() caller in case of
read operation requests.
Signed-off-by: Philippe Cornu
---
drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/gpu/
https://bugs.freedesktop.org/show_bug.cgi?id=104762
--- Comment #9 from Mike Lothian ---
It might be worth keeping these somewhere rather than deleting. Once everything
is working, copy them back see if they issue can be reproduced that way
--
You are receiving this mail because:
You are the as
On Sun, Dec 17, 2017 at 02:17:21AM +0200, Laurent Pinchart wrote:
> Color keying is the action of replacing pixels matching a given color
> (or range of colors) with transparent pixels in an overlay when
> performing blitting. Depending on the hardware capabilities, the
> matching pixel can either
Hi,
On Sun, Dec 17, 2017 at 02:17:24AM +0200, Laurent Pinchart wrote:
> +static const struct drm_prop_enum_list colorkey_modes[] = {
> + { 0, "disabled" },
> + { 1, "source" },
> +};
> +
> int rcar_du_vsp_init(struct rcar_du_vsp *vsp, struct device_node *np,
>unsigned
On 24.01.2018 10:51, Philippe CORNU wrote:
> Hi Brian,
>
> On 01/23/2018 10:15 PM, Brian Norris wrote:
>> Hi Philippe,
>>
>> On Thu, Jan 18, 2018 at 11:40:48AM +, Philippe CORNU wrote:
>>> On 01/11/2018 12:16 PM, Philippe CORNU wrote:
To be honest, I do not really like the memcpy here too
On Wed, Jan 24, 2018 at 02:26:48PM -0500, Sean Paul wrote:
> So,
>
> Reviewed-by: Sean Paul
>
> I think every other patch has R-b, so if no one objects in the next day or so,
> I'll apply this to drm-misc-next
No problems on my side... but please make sure Lee J. gets a PR.
Daniel.
__
On Wed, 24 Jan 2018, Tvrtko Ursulin wrote:
> On 24/01/2018 16:23, Chris Wilson wrote:
>> Quoting Tvrtko Ursulin (2018-01-24 16:18:15)
>>> From: Tvrtko Ursulin
>>>
>>> This series tries to solve a few issues in the current DRM logging code to
>>> primarily make it clearer which messages belong to
On Thu, Jan 25, 2018 at 10:17:21AM +0100, Maarten Lankhorst wrote:
> Op 24-01-18 om 22:47 schreef Ville Syrjala:
> > From: Ville Syrjälä
> >
> > We use 32bit bitmasks to track planes/crtcs/encoders/connectors.
> > Naturally we can only do that if the index of those objects stays
> > below 32. Issu
Hi Brian,
On 01/24/2018 07:09 PM, Brian Norris wrote:
> On Wed, Jan 24, 2018 at 09:24:06AM +, Philippe CORNU wrote:
>> On 01/23/2018 09:49 PM, Brian Norris wrote:
>>> On Tue, Jan 23, 2018 at 06:08:06PM +0100, Philippe Cornu wrote:
--- a/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
+
Hi Andrzej,
On 01/25/2018 12:07 PM, Andrzej Hajda wrote:
> On 24.01.2018 10:51, Philippe CORNU wrote:
>> Hi Brian,
>>
>> On 01/23/2018 10:15 PM, Brian Norris wrote:
>>> Hi Philippe,
>>>
>>> On Thu, Jan 18, 2018 at 11:40:48AM +, Philippe CORNU wrote:
On 01/11/2018 12:16 PM, Philippe CORNU
On 24.01.2018 19:37, Brian Norris wrote:
> Hi Philippe,
>
> On Wed, Jan 24, 2018 at 01:33:54PM +, Philippe CORNU wrote:
>> On 01/23/2018 10:38 PM, Brian Norris wrote:
>>> Hi Philippe,
>>>
>>> On Tue, Jan 23, 2018 at 6:26 AM, Philippe Cornu
>>> wrote:
The dw_mipi_dsi_host_transfer() must
On Thu, Jan 25, 2018 at 01:27:27PM +0200, Ville Syrjälä wrote:
> On Thu, Jan 25, 2018 at 10:17:21AM +0100, Maarten Lankhorst wrote:
> > Op 24-01-18 om 22:47 schreef Ville Syrjala:
> > > From: Ville Syrjälä
> > >
> > > We use 32bit bitmasks to track planes/crtcs/encoders/connectors.
> > > Naturally
From: Ville Syrjälä
We use 32bit bitmasks to track planes/crtcs/encoders/connectors.
Naturally we can only do that if the index of those objects stays
below 32. Issue a warning whenever we exceed that limit, hopefully
prompting someone to fix the problem.
For connectors the issue is a bit more c
On 25/01/2018 11:32, Jani Nikula wrote:
On Wed, 24 Jan 2018, Tvrtko Ursulin wrote:
On 24/01/2018 16:23, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2018-01-24 16:18:15)
From: Tvrtko Ursulin
This series tries to solve a few issues in the current DRM logging code to
primarily make it clearer
https://bugs.freedesktop.org/show_bug.cgi?id=87172
--- Comment #3 from Alex Deucher ---
(In reply to Paolo Devoti from comment #2)
> Same issue on Ubuntu 17.10 AMD RX480 and an UHD tv
> see also
> https://bugs.launchpad.net/ubuntu/+bug/1725395
Your chip is supported by a different driver (radeo
https://bugs.freedesktop.org/show_bug.cgi?id=87172
Alex Deucher changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
On Wed, Jan 24, 2018 at 07:26:11PM +, Russell King - ARM Linux wrote:
> On Wed, Jan 24, 2018 at 10:45:28AM -0800, Gurchetan Singh wrote:
> > On Wed, Jan 24, 2018 at 4:45 AM, Russell King - ARM Linux <
> > li...@armlinux.org.uk> wrote:
> > > So no, this is not an acceptable approach.
> > >
> > >
On Wed, Jan 24, 2018 at 04:39:27PM +, Meghana Madhyastha wrote:
> Use backlight_enable/disable helpers instead of changing
> the property and calling backlight_update_status for cleaner
> and simpler code and also to avoid repetitions.
>
> Reviewed-by: Noralf Trønnes
> Reviewed-by: Sean Paul
On Wed, Jan 24, 2018 at 04:40:51PM +, Meghana Madhyastha wrote:
> Replace of_find_backlight_by_node and of the code around it
> with of_find_backlight helper to avoid repetition of code.
>
> Reviewed-by: Noralf Trønnes
> Reviewed-by: Sean Paul
> Signed-off-by: Meghana Madhyastha
> ---
> dri
On Thu, Jan 25, 2018 at 02:37:26PM +0100, Hans de Goede wrote:
> So far models of the Dell Venue 8 Pro, with a panel with MIPI panel
> index = 3, one of which has been kindly provided to me by Jan Brummer,
> where not working with the i915 driver, giving a black screen on the
> first modeset.
>
>
On Wed, Jan 24, 2018 at 04:35:30PM +, Meghana Madhyastha wrote:
> Add of_find_backlight, a helper function which is a generic version
> of tinydrm_of_find_backlight that can be used by other drivers to avoid
> repetition of code and simplify things.
>
> Acked-by: Daniel Thompson
> Reviewed-by
On Wed, Jan 24, 2018 at 04:32:26PM +, Meghana Madhyastha wrote:
> Move drm helper functions from tinydrm-helpers to linux/backlight for
> ease of use by callers in other drivers.
>
> Changes in v19:
> -Changed to devm version of of_find_backlight in omapdrm (patch 10)
> -removed assigning pde
Instead of re-implementing the drm_atomic_helper_check() locally with just
adding drm_atomic_normalize_zpos() into it, set the
drm_mode_config->normalize_zpos.
Signed-off-by: Peter Ujfalusi
CC: Inki Dae
CC: Joonyoung Shim
CC: Seung-Woo Kim
CC: Kyungmin Park
Acked-by: Daniel Vetter
---
drive
Hi,
Changes since v2:
- Fixed commit messages (s/drm_device/drm_mode_config)
- Added ack from Benjamin Gaignard to drm/sti patch
Changes since v1:
- normalize_zpos flag moved to drm_mode_config
- Added comment to note the side effect of normalization and updated the comment
for normalized_zpos
Instead of re-implementing the drm_atomic_helper_check() locally with just
adding drm_atomic_normalize_zpos() into it, set the
drm_mode_config->normalize_zpos.
Signed-off-by: Peter Ujfalusi
CC: Thierry Reding
Acked-by: Daniel Vetter
---
drivers/gpu/drm/tegra/drm.c | 27 +++-
Planes with identical zpos value will result undefined behavior:
disappearing planes, screen flickering and it is not supported by the
hardware.
Use normalized zpos to make sure that we don't encounter invalid
configuration.
Signed-off-by: Peter Ujfalusi
CC: Tomi Valkeinen
Acked-by: Daniel Vett
Instead of drivers duplicating the drm_atomic_helper_check() code to be
able to normalize the zpos they can use the normalize_zpos flag to let the
drm core to do it.
Signed-off-by: Peter Ujfalusi
---
drivers/gpu/drm/drm_atomic_helper.c | 11 +++
include/drm/drm_mode_config.h | 8 +
Instead of re-implementing the drm_atomic_helper_check() locally with just
adding drm_atomic_normalize_zpos() into it, set the
drm_mode_config->normalize_zpos.
Signed-off-by: Peter Ujfalusi
CC: Benjamin Gaignard
CC: Vincent Abriou
Acked-by: Daniel Vetter
Acked-by: Benjamin Gaignard
---
drive
Set the drm_mode_config->normalize_zpos and call drm_atomic_helper_check()
from rcar_du_atomic_check() instead of re implementing the function locally.
Signed-off-by: Peter Ujfalusi
CC: Laurent Pinchart
Acked-by: Daniel Vetter
---
drivers/gpu/drm/rcar-du/rcar_du_kms.c | 11 ++-
1 file
On Thu, Jan 25, 2018 at 04:26:25PM +0200, Peter Ujfalusi wrote:
> Instead of drivers duplicating the drm_atomic_helper_check() code to be
> able to normalize the zpos they can use the normalize_zpos flag to let the
> drm core to do it.
>
> Signed-off-by: Peter Ujfalusi
> ---
> drivers/gpu/drm/dr
https://bugs.freedesktop.org/show_bug.cgi?id=104736
Christian König changed:
What|Removed |Added
Status|RESOLVED|CLOSED
--
You are receiving this mai
On Thu, Jan 25, 2018 at 04:40:48PM +0200, Ville Syrjälä wrote:
> On Thu, Jan 25, 2018 at 04:26:25PM +0200, Peter Ujfalusi wrote:
> > Instead of drivers duplicating the drm_atomic_helper_check() code to be
> > able to normalize the zpos they can use the normalize_zpos flag to let the
> > drm core to
On 01/25/2018 10:59 AM, Chunming Zhou wrote:
there is a scheduling balance issue about get node like:
a. process A allocates full memory and use it for submission.
b. process B tries to allocates memory, will wait for process A BO idle in
eviction.
c. process A completes the job, process B evict
On 2018-01-25 08:30 AM, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> We use 32bit bitmasks to track planes/crtcs/encoders/connectors.
> Naturally we can only do that if the index of those objects stays
> below 32. Issue a warning whenever we exceed that limit, hopefully
> prompting someone to f
Hi,
On Wed, Jan 24, 2018 at 08:37:28PM +0100, Giulio Benetti wrote:
> Hi,
>
> Il 24/01/2018 18:38, Giulio Benetti ha scritto:
> > Hi,
> >
> > Il 22/01/2018 21:27, Giulio Benetti ha scritto:
> > > Hi,
> > >
> > > Il 22/01/2018 09:51, Maxime Ripard ha scritto:
> > > > On Sat, Jan 20, 2018 at 07:5
https://bugs.freedesktop.org/show_bug.cgi?id=104790
Bug ID: 104790
Summary: When using OpenGL 4.x some applications crash
Product: Mesa
Version: git
Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: NEW
Sev
The "adjusted_mode" clock value (ie the real pixel clock) is more
accurate than "mode" clock value (ie the panel/bridge requested
clock value). It offers a better preciseness for timing
computations and allows to reduce the extra dsi bandwidth in
burst mode (from ~20% to ~10-12%, hw platform depend
There is a difference between the panel/bridge requested pixel clock
value and the real one due to the hw platform clock preciseness (pll,
dividers...). This patch updates the adjusted_mode clock value with
the real hw clock value so then attached encoder & connector can use
it for precise timing c
Hi,
in short: this patch is "CANCELLED" : )
Thanks to comments from some of you, I managed to use adjusted_mode.
Please have a look to the patch "drm/bridge/synopsys: dsi: use
adjusted_mode in mode_set".
Hope it is better, comments are welcome
Many thanks,
Philippe :-)
On 01/23/2018 06:08 PM
Hi,
in short: this patch is "CANCELLED" : )
There is no need to add the pixel clock as a mandatory property because
now the clock value is ajusted in adjusted_mode.
Please have a look to patches:
- drm/stm: ltdc: use crtc_mode_fixup to update adjusted_mode clock
- drm/bridge/synopsys: dsi: use
On 01/25/2018 03:57 PM, Thomas Hellstrom wrote:
On 01/25/2018 10:59 AM, Chunming Zhou wrote:
there is a scheduling balance issue about get node like:
a. process A allocates full memory and use it for submission.
b. process B tries to allocates memory, will wait for process A BO
idle in eviction
Am 25.01.2018 um 17:47 schrieb Thomas Hellstrom:
On 01/25/2018 03:57 PM, Thomas Hellstrom wrote:
On 01/25/2018 10:59 AM, Chunming Zhou wrote:
there is a scheduling balance issue about get node like:
a. process A allocates full memory and use it for submission.
b. process B tries to allocates me
Hi,
On 01/25/2018 06:30 PM, Christian König wrote:
Am 25.01.2018 um 17:47 schrieb Thomas Hellstrom:
On 01/25/2018 03:57 PM, Thomas Hellstrom wrote:
On 01/25/2018 10:59 AM, Chunming Zhou wrote:
there is a scheduling balance issue about get node like:
a. process A allocates full memory and use
Kernel will abort jobs for guilty (causing GPU hang) context
with -ECANCELED don't assert if that the case.
Signed-off-by: Andrey Grodzovsky
---
tests/amdgpu/deadlock_tests.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/tests/amdgpu/deadlock_tests.c b/tests/amdgpu/dead
If amdgpu_cs_query_fence_status terminates prematurely the BO
sometimes is unmapped before helper thread writes a vlaue
into it causing a segfault.
Signed-off-by: Andrey Grodzovsky
---
tests/amdgpu/deadlock_tests.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/tests/amd
Am 25.01.2018 um 19:10 schrieb Andrey Grodzovsky:
Kernel will abort jobs for guilty (causing GPU hang) context
with -ECANCELED don't assert if that the case.
Signed-off-by: Andrey Grodzovsky
Acked-by: Christian König
---
tests/amdgpu/deadlock_tests.c | 4 ++--
1 file changed, 2 insertio
https://bugs.freedesktop.org/show_bug.cgi?id=103900
--- Comment #3 from r...@tehno.ee ---
After turning off shader optimization with R600_DEBUG=nosb
War Thunder works and doesn't crash.
--
You are receiving this mail because:
You are the assignee for the bug.
The parentheses are in the wrong place here so we pass the bits per
pixel as zero.
Fixes: abbee6238775 ("drm/mgag200: Added resolution and bandwidth limits for
various G200e products.")
Signed-off-by: Dan Carpenter
---
Static analysis. Not tested.
diff --git a/drivers/gpu/drm/mgag200/mgag200_m
Hi Volodymyr,
My apologies for the silence on this thread, but it has not been ignored.
I believe Laurent has investigated this issue, and prepared a patch
locally on his tree. However, he is currently out-of-office with travel and may
not find time to reply to this thread this week or next.
I s
For a while we've been having issues with seemingly random interrupts
coming from nvidia cards when resuming them. Originally the fix for this
was thought to be just re-arming the MSI interrupt registers right after
re-allocating our IRQs, however it seems a lot of what we do is both
wrong and not
For a while we've been having issues with seemingly random interrupts
coming from nvidia cards when resuming them. Originally the fix for this
was thought to be just re-arming the MSI interrupt registers right after
re-allocating our IRQs, however it seems a lot of what we do is both
wrong and not
https://bugs.freedesktop.org/show_bug.cgi?id=104790
--- Comment #1 from Dieter Nützel ---
Are you running Wine-Nine?
I remember such 'red'ich' colors with Nine.
Then it could be the current Mesa git Nine bug.
--
You are receiving this mail because:
You are the assignee for the bug._
On Thu, Jan 25, 2018 at 7:55 AM, Philippe Cornu wrote:
> The "adjusted_mode" clock value (ie the real pixel clock) is more
> accurate than "mode" clock value (ie the panel/bridge requested
> clock value). It offers a better preciseness for timing
> computations and allows to reduce the extra dsi b
On Thu, Jan 25, 2018 at 4:16 AM, Andrzej Hajda wrote:
> On 24.01.2018 19:37, Brian Norris wrote:
>> With your current patch, you're returning the 'mipi_dsi_packet::size',
>> which is the sum of both TX and RX.
>
> I did not found docs saying mipi_dsi_packet::size is a sum of tx and rx.
> tx and rx
https://bugs.freedesktop.org/show_bug.cgi?id=104790
--- Comment #2 from lei.p...@gmail.com ---
(In reply to Dieter Nützel from comment #1)
> Are you running Wine-Nine?
> I remember such 'red'ich' colors with Nine.
> Then it could be the current Mesa git Nine bug.
No, this glitch is under Wine CSM
Am 03.01.2018 16:03, schrieb Harry Wentland:
On 2017-12-27 04:04 AM, Michel Dänzer wrote:
On 2017-12-27 05:43 AM, Dieter Nützel wrote:
Hello AMD team,
I got this since latest 'amd-staging-drm-next' git update
(#b956c586e58a) during boot with Polaris RX580 DC on:
[ 3.586342] [drm:dal_bios_p
https://bugs.freedesktop.org/show_bug.cgi?id=104790
--- Comment #3 from Dieter Nützel ---
(In reply to lei.pero from comment #2)
> (In reply to Dieter Nützel from comment #1)
> > Are you running Wine-Nine?
> > I remember such 'red'ich' colors with Nine.
> > Then it could be the current Mesa git N
://github.com/0day-ci/linux/commits/Maciej-Purski/drm-bridge-sii8620-fix-display-modes-validation/20180125-174703
base: git://people.freedesktop.org/~airlied/linux.git drm-next
config: i386-randconfig-sb0-01260635 (attached as .config)
compiler: gcc-4.9 (Debian 4.9.4-2) 4.9.4
reproduce
For a while we've been having issues with seemingly random interrupts
coming from nvidia cards when resuming them. Originally the fix for this
was thought to be just re-arming the MSI interrupt registers right after
re-allocating our IRQs, however it seems a lot of what we do is both
wrong and not
https://bugs.freedesktop.org/show_bug.cgi?id=104790
--- Comment #4 from lei.p...@gmail.com ---
(In reply to Dieter Nützel from comment #3)
> (In reply to lei.pero from comment #2)
> > (In reply to Dieter Nützel from comment #1)
> > > Are you running Wine-Nine?
> > > I remember such 'red'ich' color
On Thu, Jan 25, 2018 at 11:37:59AM +0100, Philippe Cornu wrote:
> The dcs/generic dsi read feature is not yet implemented so it
> is important to warn the host_transfer() caller in case of
> read operation requests.
>
> Signed-off-by: Philippe Cornu
Awesome, thanks.
Reviewed-by: Brian Norris
On Thu, Jan 25, 2018 at 11:38:00AM +0100, Philippe Cornu wrote:
> The dw_mipi_dsi_host_transfer() must return the number of
> bytes transmitted/received on success instead of 0.
> Note: As the read feature is not implemented, only the
> transmitted number of bytes is returned for the moment.
>
> S
https://bugs.freedesktop.org/show_bug.cgi?id=104762
--- Comment #10 from Timothy Arceri ---
I was able to reproduce the problem. Fix sent to list:
https://patchwork.freedesktop.org/series/37147/
--
You are receiving this mail because:
You are the assignee for the bug.__
https://bugs.freedesktop.org/show_bug.cgi?id=98974
John changed:
What|Removed |Added
CC||bugs.freedesktop@johnthomso
|
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 soft logics in FPGA.
The Xilinx DRM KMS module is to integrate multip
Xilinx ZynqMP has a hardened display pipeline. The pipeline can
be logically partitioned into 2 parts: display controller and
DisplayPort encoder / transmitter. This driver handles the display
controller part of the pipeline that handles buffer management and
blending.
Signed-off-by: Hyun Kwon
Ac
This is a wrapper around the ZynqMP Display and DisplayPort drivers.
Signed-off-by: Hyun Kwon
Acked-by: Daniel Vetter
---
v4
- Use the newly added xlnx pipeline calls to initialize drm device
v2
- Change the SPDX identifier format
---
---
drivers/gpu/drm/xlnx/Kconfig| 11 +++
drivers/g
This add a dt binding for ZynqMP DP subsystem.
Signed-off-by: Hyun Kwon
---
v4
- Specify phy related descriptions
- Specify dma related descriptions
- Remove ports
- Remove child nodes for layers
- Update the example accordingly
v2
- Group multiple ports under 'ports'
- Replace linux specific ter
This driver creates DRM encoder and connector for ZynqMP DisplayPort.
Signed-off-by: Hyun Kwon
Acked-by: Daniel Vetter
---
v2
- Change the SPDX identifier format
- Split drm properties into a separate patch
---
---
drivers/gpu/drm/xlnx/zynqmp_dp.c | 1738 ++
Hi Daniel,
> -Original Message-
> From: Daniel Vetter [mailto:daniel.vet...@ffwll.ch] On Behalf Of Daniel
> Vetter
> Sent: Wednesday, January 17, 2018 12:20 AM
> To: Hyun Kwon
> Cc: dri-devel@lists.freedesktop.org; devicet...@vger.kernel.org; Michal
> Simek ; Rob Herring ; Daniel
> Vetter
In order to handle non byte aligned formats, use
drm_format_plane_width_bytes(). Use of 'cpp' can result in
incorrect number of bytes from bit level rounding.
Signed-off-by: Hyun Kwon
---
v2
- This patch is added.
---
---
drivers/gpu/drm/drm_fb_cma_helper.c | 3 ++-
1 file changed, 2 insertions(
From: Jeffrey Mouroux
The Xilinx Video Mixer andn Xilinx Video Framebuffer DMA IP
support video memory formats that are not represented in the
current DRM fourcc library. This patch adds those missing
fourcc codes.
Signed-off-by: Jeffrey Mouroux
Signed-off-by: Hyun Kwon
---
v2
- Add detailed
This adds packed YUV and grey scale format fourccs.
Signed-off-by: Hyun Kwon
---
v2
- Split from the previous patch
---
---
include/uapi/drm/drm_fourcc.h | 7 +++
1 file changed, 7 insertions(+)
diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h
index 6ac5282..7014a3
Signed-off-by: Hyun Kwon
---
drivers/gpu/drm/xlnx/zynqmp_disp.c | 18 ++
1 file changed, 18 insertions(+)
diff --git a/drivers/gpu/drm/xlnx/zynqmp_disp.c
b/drivers/gpu/drm/xlnx/zynqmp_disp.c
index fd6ddfe..b1aaa71 100644
--- a/drivers/gpu/drm/xlnx/zynqmp_disp.c
+++ b/drivers/gpu
This adds new formats (packed YUV and grey scale) to
the drm format table.
Signed-off-by: Hyun Kwon
---
v2
- Split from previous patch
---
---
drivers/gpu/drm/drm_fourcc.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/gpu/drm/drm_fourcc.c b/drivers/gpu/drm/drm_fourcc.c
index 2
'cpp' doesn't work for any format where component size is not byte aligned.
Add 'bpp' to have a bit level information. Add a meesage to
drm_format_plane_cpp() to indicate that the returned cpp would be
rounded for non byte aligned formats.
Signed-off-by: Hyun Kwon
---
v2
- Introduce bpp
---
---
Signed-off-by: Hyun Kwon
---
drivers/gpu/drm/xlnx/zynqmp_disp.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/xlnx/zynqmp_disp.c
b/drivers/gpu/drm/xlnx/zynqmp_disp.c
index d2e1034..fd6ddfe 100644
--- a/drivers/gpu/drm/xlnx/zynqmp_disp.c
+++ b/drivers/gpu/
Multiple pixels can be grouped as a single unit and form a 'macro-pixel'.
This is to model formats where multiple pixels are stored together
in a specific way, likely byte-algined. For example, if 3 - 10 bit
pixels are stored in 32 bit, the 32 bit stroage can be treated as
a single macro-pixel with
drm_format_plane_width_bytes() calculates and returns
the number of bytes for given width of specified format.
The calculation uses the macro pixel information to avoid
bit level rounding.
Signed-off-by: Hyun Kwon
---
v2
- This function is added
---
---
drivers/gpu/drm/drm_fourcc.c | 22
Hi,
This is RFC to follow up on adding new formats to DRM core. Previous discussion
can be found in [1].
These new formats are not byte addressable, whereas in many places in DRM core,
the assumption is that format bpp is byte aligned. Thus, in order to support
these formats correctly, additiona
Add information for DRM_FORMAT_XV15 and DRM_FORMAT_XV20 to
the drm format table.
Signed-off-by: Hyun Kwon
---
v2
- Accomodate macro pixel changes
---
---
drivers/gpu/drm/drm_fourcc.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/drm_fourcc.c b/drivers/gpu/drm/drm_fourcc.c
https://bugs.freedesktop.org/show_bug.cgi?id=99353
--- Comment #19 from Bong Cosca ---
If I may add, compositing works by setting DRI_PRIME=1 with KMS and AccelMethod
"none" despite having only the APU.
--
You are receiving this mail because:
You are the assignee for the bug.___
Next version of my patchseries for adding clockgating support for
kepler1 and 2 on nouveau. The first version of this series can be found
here:
https://patchwork.freedesktop.org/series/36504/
Some minor changes:
- Clarified that SLCG stands for 'secondary level clockgating', thanks
for the sm
This adds support for enabling automatic clockgating on nvidia GPUs for
Kepler1. While this is not technically a clockgating level, it does
enable clockgating using the clockgating values initially set by the
vbios (which should be safe to use).
This introduces two therm helpers for controlling ba
This enables BLCG optimization for kepler1. When using clockgating,
nvidia's firmware has a set of registers which are initially programmed
by the vbios with various engine delays and other mysterious settings
that are safe enough to bring up the GPU. However, the values used by
the vbios are more
That's right, there's still more power saving to go! Starting with
kepler 2, nvidia hardware has an additional level of clockgating known
as second level clockgating. The details of this are not exact, but it
seems to work by waiting for a collection of dependent hardware blocks
to be gated before
Same as the previous patch, but for Kepler2 now
Signed-off-by: Lyude Paul
---
drivers/gpu/drm/nouveau/include/nvkm/subdev/fb.h | 1 +
drivers/gpu/drm/nouveau/nvkm/engine/device/base.c | 8 +--
drivers/gpu/drm/nouveau/nvkm/engine/gr/gk110.c| 62
drivers/gpu/drm/nouveau
1 - 100 of 106 matches
Mail list logo
