On Wed, 22 Jan 2020, Chen Zhou wrote:
> Fixes coccicheck warning:
> ./drivers/video/backlight/qcom-wled.c:1104:5-15:
> WARNING: Unsigned expression compared with zero: string_len > 0
>
> The unsigned variable string_len is assigned a return value from the call
> to
s ->atomic_get_output_bus_fmts() it
* should also implement the atomic state hooks.
*/
- if (WARN_ON(last_bridge_state))
+ if (WARN_ON(!last_bridge_state))
return -EINVAL;
out_bus_fmts = funcs->atomic_get_output_bus_fmts(last_bridge,
Regards,
Jonas
>
>>
>> [1] https://github.com/Kwiboo/linux-rockchip/commits/next-20200122-bus-format
>>
>> Regards,
>> Jonas
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Hi Sam,
On Mon, Jan 20, 2020 at 8:02 PM Sam Ravnborg wrote:
> From 6b54fb0a071c0732cd4bd5b88f456b5a85bcf4f2 Mon Sep 17 00:00:00 2001
> From: Sam Ravnborg
> Date: Mon, 20 Jan 2020 19:55:04 +0100
> Subject: [PATCH] dt-bindings: restrict properties for sitronix,st7735r
>
> David Lechner noticed
606772] drm_atomic_check_only+0x464/0x708
> [6.606777] drm_atomic_commit+0x18/0x58
Add
const drm_bridge_funcs ... = {
...
.atomic_reset = drm_atomic_helper_bridge_reset,
.atomic_duplicate_state = drm_atomic_helper_bridge_duplicate_state,
.atomic_destroy_state = drm_atomic_he
On Wed, 22 Jan 2020 12:16:49 +0100
Boris Brezillon wrote:
> +
> +/**
> + * drm_atomic_get_bridge_state - get bridge state
> + * @state: global atomic state object
> + * @bridge: bridge to get state object for
> + *
> + * This function returns the bridge state for the given bridge, allocating it
On Mon, Jan 20, 2020 at 08:02:49PM +0100, Sam Ravnborg wrote:
> Hi David.
>
> > > +allOf:
> > > + - $ref: panel/panel-common.yaml#
> >
> > not all of these properties are applicable.
> >
>
> > > +required:
> > > + - compatible
> > > + - reg
> > > + - dc-gpios
> > > + - reset-gpios
> >
>
This patch adds support for enabling Graphics Bus Interface(GBIF)
used in multiple A6xx series chipets. Also makes changes to the
PDC/RSC sequencing specifically required for A618. This is needed
for proper interfacing with RPMH.
Signed-off-by: Sharat Masetty
---
Add the relevant GBIF registers and the debug bus to the a6xx gpu
state. This comes in pretty handy when debugging GPU bus related
issues.
Signed-off-by: Sharat Masetty
---
drivers/gpu/drm/msm/adreno/a6xx_gpu_state.c | 52 +++--
This patch adds Adreno 618 entry and its associated properties
to the gpulist entries.
Signed-off-by: Sharat Masetty
---
drivers/gpu/drm/msm/adreno/adreno_device.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/drivers/gpu/drm/msm/adreno/adreno_device.c
On 2020.01.22 20:10:24 +, Igor Druzhinin wrote:
> If the module happens to be loaded later at runtime there is a chance
> memory is already fragmented enough to fail allocation of firmware
> blob storage and consequently GVT init. Since it doesn't seem to be
> necessary to have the blob
[AMD Official Use Only - Internal Distribution Only]
Hi Lyude,
I also notice one thing that I was not aware of before. Since we're clearing
payloads here, maybe we should also call drm_dp_mst_put_port_malloc() to put
malloc refcounts here?
Appreciate for all your help! :)
This is consistent with what I have.
I did a clean benchmark run, but this time everything to low/off, but still
1920x1080:
avg fps ~250fps
min fps ~200fps
max fps ~350fps
Still getting gpu vm faults in dmesg.
I run everything git and amd-staging-drm-next no older than 1 week.
--
Sylvain
https://bugzilla.kernel.org/show_bug.cgi?id=206231
--- Comment #30 from Sylvain BERTRAND (sylvain.bertr...@gmail.com) ---
This is consistent with what I have.
I did a clean benchmark run, but this time everything to low/off, but still
1920x1080:
avg fps ~250fps
min fps ~200fps
max fps ~350fps
From: Colin Ian King
There is a spelling mistake in a DRM_ERROR message. Fix it.
Signed-off-by: Colin Ian King
---
drivers/gpu/drm/amd/amdgpu/amdgpu_vce.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vce.c
https://bugzilla.kernel.org/show_bug.cgi?id=206231
--- Comment #29 from Jacques Belosoukinski (kentos...@whiteninjastudio.com) ---
Indeed Dirt Rally is an OpenGL game. I thought it was Vulkan, because I didn't
see the HUD from Gallium, but it was an error in the settings.
The result benchmark in
https://bugzilla.kernel.org/show_bug.cgi?id=206231
--- Comment #28 from Sylvain BERTRAND (sylvain.bertr...@gmail.com) ---
Actually I should have restarted the game.
I did reboot in a clean state and did set "performance" on the gpu as well.
Here are the results of "clean" benchmark run:
avg fps
Actually I should have restarted the game.
I did reboot in a clean state and did set "performance" on the gpu as well.
Here are the results of "clean" benchmark run:
avg fps ~ 20fps
min fps ~ 15fps
max fps ~ 40fps
Still getting gpu vm faults in dmesg.
--
Sylvain
On Wed, 2020-01-22 at 22:51 +0200, Ville Syrjälä wrote:
> On Wed, Jan 22, 2020 at 02:43:20PM -0500, Lyude Paul wrote:
> > The issues caused by:
> >
> > 64e62bdf04ab ("drm/dp_mst: Remove VCPI while disabling topology mgr")
> >
> > Prompted me to take a closer look at how we clear the payload
struct drm_bridge_funcs *funcs = last_bridge->funcs;
> +
> + /*
> + * If the driver implements ->atomic_get_output_bus_fmts() it
> + * should also implement the atomic state hooks.
> + */
> + if (WARN_ON(last_
Adds DRM_IOCTL_MODE_GETFB2
Taken from drm-next-misc:
commit 3ff4c24bdb1f494c217c80348f9db4896043ed81
Author: Lyude Paul
Date: Fri Jan 17 17:47:48 2020 -0500
drm/dp_mst: Fix indenting in drm_dp_mst_topology_mgr_set_mst()
Signed-off-by: Juston Li
---
From: Daniel Stone
Add a wrapper around the getfb2 ioctl, which returns extended
framebuffer information mirroring addfb2, including multiple planes and
modifiers.
Changes since v2:
- getfb2 ioctl has been merged upstream
- sync include/drm/drm.h in a seperate patch
Changes since v1:
-
Dirt Rally is a GL game, not a vulkan game.
It happens I have it in my library even though I don't recall to buy
it.
Anyway I did run the included benchmark:
- cpu governor to performance
- monitor refresh rate 144Hz
- 1920x1080
- 8xmsaa
- _no_ vsync
- everything to max
avg fps:
https://bugzilla.kernel.org/show_bug.cgi?id=206231
--- Comment #27 from Sylvain BERTRAND (sylvain.bertr...@gmail.com) ---
Dirt Rally is a GL game, not a vulkan game.
It happens I have it in my library even though I don't recall to buy
it.
Anyway I did run the included benchmark:
- cpu
Hey Dave,
Just a couple of fixes to GP10x ACR support after the work, and a
(fairly severe if you're running piglit a lot) memory leak fix.
Ben.
The following changes since commit afa3b96b058d87c2c44d1c83dadb2ba6998d03ce:
drm/nouveau/gr/tu10x: initial support (2020-01-15 10:50:30 +1000)
are
On 1/22/20 11:00 PM, Chris Wilson wrote:
Quoting Thomas Hellström (VMware) (2020-01-22 21:52:23)
Hi, Chris,
On 1/22/20 4:56 PM, Chris Wilson wrote:
The file is not part of the global drm resource and can be released
prior to take the global mutex to drop the open_count (and potentially
close)
https://bugzilla.kernel.org/show_bug.cgi?id=206231
--- Comment #26 from Jacques Belosoukinski (kentos...@whiteninjastudio.com) ---
Yes !
I forgot to check the output of dmesg | err!
Here are lots of nice messages while playing Tomb Raider :
80456.046410] amdgpu :01:00.0: GPU fault
Quoting Thomas Hellström (VMware) (2020-01-22 21:52:23)
> Hi, Chris,
>
> On 1/22/20 4:56 PM, Chris Wilson wrote:
> > The file is not part of the global drm resource and can be released
> > prior to take the global mutex to drop the open_count (and potentially
> > close) the drm device.
> >
> >
Hi, Chris,
On 1/22/20 4:56 PM, Chris Wilson wrote:
The file is not part of the global drm resource and can be released
prior to take the global mutex to drop the open_count (and potentially
close) the drm device.
However, inside drm_close_helper() there are a number of dev->driver
callbacks
Hi Dave and Daniel,
Back with what might be my last -misc pull request :-(
Just a couple fixes. We have our customary MST fix from AMD and a panfrost fix.
Please pull!
drm-misc-fixes-2020-01-22-1:
-mst: Fix SST branch device handling (Wayne)
-panfrost: Fix mapping of globally visible BO's
[Why]
we need to load SRM before we start HDCP. Because for S3 case the sysfs call
will be
after we have already enabled HDCP, so we might not be using the latest SRM
[How]
Set srm before starting HDCP.
Signed-off-by: Bhawanpreet Lakha
Reviewed-by: Rodrigo Siqueira
---
[Why]
We need to support SRM(System Renewability Message)
As per hdcp spec (5.Renewability) SRM needs to be storage in a non-volatile
memory.
PSP owns the checking of SRM but doesn't have the ability to store it in a
non-volatile memory. So we need the kernel driver to facilitate it using the
These patches adds support for SRM loading. SRM has to be saved in a
non-volatile memory(spec) and PSP can't do that directly so we need to
use the driver to do this
Since the kernel cannot directly write to system storage we need to provide an
interface so that the usermode can do it for us
v2
This is just a reference for the patches. not to be merged
Signed-off-by: Bhawanpreet Lakha
---
REFERENCE | 49 +
1 file changed, 49 insertions(+)
create mode 100644 REFERENCE
diff --git a/REFERENCE b/REFERENCE
new file mode 100644
index
Call the cmd ids for set/get srm according to the sysfs call
v2: Use define for the magic number
Signed-off-by: Bhawanpreet Lakha
Reviewed-by: Rodrigo Siqueira
---
.../amd/display/amdgpu_dm/amdgpu_dm_hdcp.c| 50 ++-
1 file changed, 49 insertions(+), 1 deletion(-)
diff
[Why]
PSP doesn't have the ability to store SRM in a non-volatile memory. And since
the kernel cannot write to the storage directly, we need usermode to facilitate
this
As per spec the SRM needs to be persistent so this interface is to be
called by the usermode anytime the system goes
[Why]
We need this to create sysfs (followup patch)
[How]
Change the parameter
Signed-off-by: Bhawanpreet Lakha
Reviewed-by: Rodrigo Siqueira
---
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 2 +-
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_hdcp.c | 4 ++--
On Wed, Jan 22, 2020 at 02:43:20PM -0500, Lyude Paul wrote:
> The issues caused by:
>
> 64e62bdf04ab ("drm/dp_mst: Remove VCPI while disabling topology mgr")
>
> Prompted me to take a closer look at how we clear the payload state in
> general when disabling the topology, and it turns out there's
On Wed, Jan 22, 2020 at 3:22 AM Zheng Bin wrote:
>
> From: zhengbin
>
> Fixes coccicheck warning:
>
> drivers/gpu/drm/amd/powerplay/hwmgr/smu7_hwmgr.c:723:2-50: WARNING:
> Assignment of 0/1 to bool variable
> drivers/gpu/drm/amd/powerplay/hwmgr/smu7_hwmgr.c:733:3-52: WARNING:
> Assignment of
Hi changzhu,
FYI, the error/warning still remains.
tree: git://people.freedesktop.org/~agd5f/linux.git amd-19.50
head: f9a0b7ad3447d7766dda9923e63a5f4d0be7ce47
commit: 8aff76ca3bf3120204c9ec521ebe96a5133e92f3 [2094/2713] drm/amdkcl: Test
whether mmgrab is available
config: i386-allyesconfig
On Tue, Jan 21, 2020 at 11:08 AM Chen Zhou wrote:
>
> This patch series remove unnecessary conversion to bool in dir
> drivers/gpu/drm/amd/amdgpu/, which is detected by coccicheck.
Thanks for the patches. Already applied this patch:
https://patchwork.freedesktop.org/series/72281/#rev2
which
On Wed, 2020-01-22 at 04:48 +, Lin, Wayne wrote:
> [AMD Public Use]
>
> Sorry for any inconvenience I brought.
Nothing to be sorry about! This happens from time to time, it's my fault for
not noticing it in the first place anyway :P. Ville from Intel is able to
review it, so there's no rush
On Wed, Jan 22, 2020 at 02:43:21PM -0500, Lyude Paul wrote:
> Mention that the size of these two structs is determined by
> max_payloads. Suggested by Ville Syrjälä.
>
> Signed-off-by: Lyude Paul
> Cc: Ville Syrjälä
> ---
> include/drm/drm_dp_mst_helper.h | 6 --
> 1 file changed, 4
Small nitpick that I noticed a second ago - we can save some space in
the struct by making this a bitfield and sticking it with the rest of
the bitfields. Also, some small cleanup to the kdocs for this member.
There should be no functional changes in this patch.
Signed-off-by: Lyude Paul
Cc:
Mention that the size of these two structs is determined by
max_payloads. Suggested by Ville Syrjälä.
Signed-off-by: Lyude Paul
Cc: Ville Syrjälä
---
include/drm/drm_dp_mst_helper.h | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/include/drm/drm_dp_mst_helper.h
The issues caused by:
64e62bdf04ab ("drm/dp_mst: Remove VCPI while disabling topology mgr")
Prompted me to take a closer look at how we clear the payload state in
general when disabling the topology, and it turns out there's actually
two subtle issues here.
The first is that we're not grabbing
On Fri, Jan 17, 2020 at 05:47:49PM -0500, Lyude Paul wrote:
> The issues caused by:
>
> 64e62bdf04ab ("drm/dp_mst: Remove VCPI while disabling topology mgr")
>
> Prompted me to take a closer look at how we clear the payload state in
> general when disabling the topology, and it turns out there's
On Fri, Jan 17, 2020 at 05:47:48PM -0500, Lyude Paul wrote:
> This has always bugged me but somehow I've never remembered to actually
> fix it. So let's do that.
>
> Signed-off-by: Lyude Paul
> ---
> drivers/gpu/drm/drm_dp_mst_topology.c | 4 +++-
> 1 file changed, 3 insertions(+), 1
https://bugzilla.kernel.org/show_bug.cgi?id=206231
--- Comment #25 from Jacques Belosoukinski (kentos...@whiteninjastudio.com) ---
I tried to compile the kernel "amd-staging-drm-next" but it's a horror, nothing
works during compilation.
I just tried Dirt Rally which a Vulkan game, the
On Wed, 2020-01-22 at 18:49 +0530, Anshuman Gupta wrote:
> On 2020-01-21 at 12:13:14 -0800, José Roberto de Souza wrote:
> > A recent change in BSpec allow us to change EXTLINE while
> > transcoder
> > is enabled so this allow us to change it even when doing the first
> > fastset after taking over
On Wed, 15 Jan 2020, Pankaj Bharadiya
wrote:
> Device specific dev_WARN and dev_WARN_ONCE macros available in kernel
> include device information in the backtrace, so we know what device
> the warnings originate from.
>
> Similar to this, add new struct drm_device based drm_WARN* macros. These
>
On 30/12/2019 10:04, Enric Balletbo i Serra wrote:
> Hi all,
>
> This is another version of the driver. Note that the driver changed
> significally and is a more simply because now is using the panel_bridge
> helpers. Apart from this, I addressed the comments from Maxime, Laurent
> and Ezequiel.
Hi
Am 22.01.20 um 16:50 schrieb Jani Nikula:
> Use drm_core_check_all_features() to ensure both the driver features and
> the per-device driver features are taken into account when registering
> debugfs files.
>
> v2:
> - use drm_core_check_all_features()
>
> Cc: Ville Syrjälä
> Cc: Thomas
Hi
Am 22.01.20 um 16:50 schrieb Jani Nikula:
> Add new drm_core_check_all_features() function to check for a mask of
> features. All features in the mask are required.
>
> Redefine existing drm_core_check_feature() in terms of this function,
> using the drm_driver_feature enum for the parameter.
Hi Prike,
FYI, the error/warning still remains.
tree: git://people.freedesktop.org/~agd5f/linux.git amd-19.50
head: f9a0b7ad3447d7766dda9923e63a5f4d0be7ce47
commit: 3ba40228e28c15ca2dfec398cd7e5ebebdb5a9c2 [2082/2713] drm/amdkcl: Test
whether vmf_insert_*() functions are available
config:
On 1/22/20 4:54 AM, Andy Shevchenko wrote:
The spi_register_driver() will set the ->owner member to THIS_MODULE.
Signed-off-by: Andy Shevchenko
---
Reviewed-by: David Lechner
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
On 1/22/20 4:54 AM, Andy Shevchenko wrote:
The spi_register_driver() will set the ->owner member to THIS_MODULE.
Signed-off-by: Andy Shevchenko
---
Reviewed-by: David Lechner
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
On 1/22/20 4:54 AM, Andy Shevchenko wrote:
There is one OF call in the driver that limits its area of use.
Replace it to generic device_get_match_data() and get rid of OF dependency.
Signed-off-by: Andy Shevchenko
---
Acked-by: David Lechner
___
The file is not part of the global drm resource and can be released
prior to take the global mutex to drop the open_count (and potentially
close) the drm device.
However, inside drm_close_helper() there are a number of dev->driver
callbacks that take the drm_device as the first parameter...
Use drm_core_check_all_features() to ensure both the driver features and
the per-device driver features are taken into account when registering
debugfs files.
v2:
- use drm_core_check_all_features()
Cc: Ville Syrjälä
Cc: Thomas Zimmermann
Signed-off-by: Jani Nikula
---
Add new drm_core_check_all_features() function to check for a mask of
features. All features in the mask are required.
Redefine existing drm_core_check_feature() in terms of this function,
using the drm_driver_feature enum for the parameter.
v3:
- add drm_core_check_all_features() (Thomas)
v2:
On Wed, Jan 22, 2020 at 6:51 AM Sean Paul wrote:
>
> On Tue, Jan 21, 2020 at 11:26:05AM -0800, Rob Clark wrote:
> > On Tue, Jan 21, 2020 at 11:19 AM Douglas Anderson
> > wrote:
> > >
> > > From: Sean Paul
> > >
> > > Turning on CONFIG_DMA_API_DEBUG_SG results in the following error:
> > >
> >
On Wed, Jan 22, 2020 at 3:06 AM Daniel Vetter wrote:
>
> On Mon, Jan 20, 2020 at 01:56:21PM -0500, Steven Rostedt wrote:
> > On Thu, 16 Jan 2020 07:27:22 +0100
> > Daniel Vetter wrote:
> >
> > > On Tue, Jan 14, 2020 at 12:21:43PM -0500, Sean Paul wrote:
> > > > From: Sean Paul
> > > >
> > > >
On Wed, 22 Jan 2020, Sean Paul wrote:
> On Tue, Jan 14, 2020 at 10:49 PM Pankaj Bharadiya
> wrote:
>>
>> Add new struct drm_device based WARN* macros. These are modeled after
>> the core kernel device based WARN* macros. These would be preferred
>> over the regular WARN* macros, where possible.
Hi
Am 22.01.20 um 15:27 schrieb Jani Nikula:
> On Wed, 22 Jan 2020, Thomas Zimmermann wrote:
>> Hi Jani
>>
>> Am 22.01.20 um 15:02 schrieb Jani Nikula:
>>> Allow a mask of features to be passed to drm_core_check_feature(). All
>>> features in the mask are required.
>>>
>>> v2:
>>> - fix
Hi Maarten/Maxime,
Please pull the drm_device based drm_WARN* macros from the topic
branch. I'll pull the same to drm-intel-next-queued.
I like to use the topic branch here, because due to timing it'll take
forever for the full feature route through drm-next and backmerges.
The baseline was
On Tue, Jan 21, 2020 at 11:26:05AM -0800, Rob Clark wrote:
> On Tue, Jan 21, 2020 at 11:19 AM Douglas Anderson
> wrote:
> >
> > From: Sean Paul
> >
> > Turning on CONFIG_DMA_API_DEBUG_SG results in the following error:
> >
> > [ 12.078665] msm ae0.mdss: DMA-API: mapping sg segment longer
On Wed, 22 Jan 2020, Thomas Zimmermann wrote:
> Hi Jani
>
> Am 22.01.20 um 15:02 schrieb Jani Nikula:
>> Allow a mask of features to be passed to drm_core_check_feature(). All
>> features in the mask are required.
>>
>> v2:
>> - fix kernel-doc (Ville)
>> - add an extra variable for clarity
On Tue, Jan 21, 2020 at 12:39:55PM +0530, Ramalingam C wrote:
> As we are not using the sysfs infrastructure anymore, link to it is
> removed. And global srm data and mutex to protect it are removed,
> with required handling at revocation check function.
>
Hi Ram,
Thanks for taking this on. A
Hi Jani
Am 22.01.20 um 15:02 schrieb Jani Nikula:
> Allow a mask of features to be passed to drm_core_check_feature(). All
> features in the mask are required.
>
> v2:
> - fix kernel-doc (Ville)
> - add an extra variable for clarity (Ville)
>
> Reviewed-by: Ville Syrjälä
> Signed-off-by: Jani
Allow a mask of features to be passed to drm_core_check_feature(). All
features in the mask are required.
v2:
- fix kernel-doc (Ville)
- add an extra variable for clarity (Ville)
Reviewed-by: Ville Syrjälä
Signed-off-by: Jani Nikula
---
include/drm/drm_drv.h | 12
1 file changed,
Use drm_core_check_feature() to ensure both the driver features and the
per-device driver features are taken into account when registering
debugfs files.
Reviewed-by: Ville Syrjälä
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/drm_debugfs.c | 5 +
1 file changed, 1 insertion(+), 4
This patch converts various instances of the printk based logging macros
into the struct drm_device based macros. This was achieved using the
following coccinelle script for matching existing struct
drm_i915_private devices:
@rule1@
identifier fn, T;
@@
fn(...,struct drm_i915_private *T,...) {
This converts various instances of printk based logging macros in
i915/display/intel_dp.c with the new struct drm_device based logging
macros using the following coccinelle script:
@rule1@
identifier fn, T;
@@
fn(...,struct drm_i915_private *T,...) {
<+...
(
-DRM_INFO(
+drm_info(>drm,
...)
|
This series continues the ongoing conversion to the new struct
drm_device based logging macros for debug in i915.
v2: address merge conflict in i915/display/intel_dp.c due to newer
changes in file.
Wambui Karuga (6):
drm/i915/dsi: conversion to struct drm_device log macros
drm/i915/ddi:
First pass of conversion to the new struct drm_based device logging
macros in the drm/i915/gem directory. This conversion was achieved using
the following coccinelle script that transforms based on the existence
of a straightforward struct drm_i915_private device:
@rule1@
identifier fn, T;
@@
Convert most of the remaining uses of the printk based logging macros to
the new struct drm_device based logging macros in drm/i915/gem.
This also involves extracting the struct drm_i915_private device
from various types, and using it in the various macros.
Signed-off-by: Wambui Karuga
---
Converts various instances of the printk based logging macros in
i915/display/intel_display_power.c to the struct drm_device based
logging macros using the following coccinelle script:
@rule1@
identifier fn, T;
@@
fn(...,struct drm_i915_private *T,...) {
<+...
(
-DRM_INFO(
+drm_info(>drm,
...)
|
This converts the more straightforward instances of the printk based
logging macros with the struct drm_device based logging macros.
This transformation was achieved using coccinelle and the following
script for matching an existing struct drm_i915_private device:
@rule1@
identifier fn, T;
@@
This converts various instances of the printk based logging macros in
i915/display/intel_opregion.c with the new struct drm_device based
logging macros using the following coccinelle script:
@rule1@
identifier fn, T;
@@
fn(...,struct drm_i915_private *T,...) {
<+...
(
-DRM_INFO(
+drm_info(>drm,
Converts various instances of the printk based logging macros in
i915/display/intel_hdcp.c with the struct drm_device based macros using
coccinelle. The script matches based on the existence of an existing
struct drm_i915_private device:
@rule1@
identifier fn, T;
@@
fn(...,struct drm_i915_private
This series is a part of the conversion to the new struct drm_device
based logging macros in drm/i915.
This series focuses on the drm/i915/gem directory and converts all
straightforward instances of the printk based logging macros to the new
macros.
Wambui Karuga (2):
drm/i915/gem: initial
The tegra driver can be compiled without CONFIG_PM_SLEEP enabled.
In this case the compilation triggers the warning below:
drivers/gpu/drm/tegra/sor.c:3984:12: warning: ‘tegra_sor_resume’
defined but not used [-Wunused-function]
3984 | static int tegra_sor_resume(struct device *dev)
|
The VBT fields match the DPCD data, so use the same helper.
Cc: Manasi Navare
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/display/intel_bios.c | 11 +++
1 file changed, 3 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_bios.c
Stop overriding the VBT defined value for rc_model_size.
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/display/icl_dsi.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/icl_dsi.c
b/drivers/gpu/drm/i915/display/icl_dsi.c
index 2ca4b0382eb9..a7457303c62e
Move the intialization of the rc_model_size from the common code into
encoder code, allowing different encoders to specify the size according
to their needs. Keep using the hard coded value in the encoders for now
to make this a non-functional change.
Cc: Manasi Navare
Signed-off-by: Jani Nikula
The rc_model_size is specified in the DSC config, and the hardware
programming should respect that instead of hard coding a value of 8192.
Regardless, the rc_model_size in DSC config is currently hard coded to
the same value, so this should have no impact, other than allowing the
use of other
Use the new drm_dsc_dp_rc_buffer_size() helper to simplify rc buffer
size computation. No functional changes.
Cc: Alex Deucher
Cc: Harry Wentland
Cc: Manasi Navare
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/amd/display/dc/dsc/dc_dsc.c | 37 -
1 file changed, 7
Make it possible to adjust the rc_model_size parameter instead of
hardcoding it all over the place. Only actually change the size for i915
DSI DSC.
Patch 3 for AMD isn't really required, but it felt like a natural
cleanup to incorporate.
Vandita, please check if this helps with the DSI DSC woes.
The PPS is supposed to reflect the DSC config instead of hard coding the
rc_model_size. Make it so.
Currently all users of drm_dsc_pps_payload_pack() hard code the size to
8192 also in the DSC config, so this change should have no impact, other
than allowing the drivers to use other sizes as
Add a helper for calculating the rc buffer size from the DCPD offsets
DP_DSC_RC_BUF_BLK_SIZE and DP_DSC_RC_BUF_SIZE.
Cc: Alex Deucher
Cc: Harry Wentland
Cc: Manasi Navare
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/drm_dsc.c | 27 +++
include/drm/drm_dsc.h | 1
On 21/01/2020 04:37, Nicolas Boichat wrote:
On Tue, Jan 14, 2020 at 10:16 PM Mark Brown wrote:
On Tue, Jan 14, 2020 at 03:15:59PM +0800, Nicolas Boichat wrote:
- I couldn't find a way to detect the number of regulators in the
device tree, if we wanted to refuse to probe the device if
On Tue, Jan 14, 2020 at 10:49 PM Pankaj Bharadiya
wrote:
>
> Add new struct drm_device based WARN* macros. These are modeled after
> the core kernel device based WARN* macros. These would be preferred
> over the regular WARN* macros, where possible.
>
> These macros include device information in
On 2020-01-21 at 12:13:14 -0800, José Roberto de Souza wrote:
> A recent change in BSpec allow us to change EXTLINE while transcoder
> is enabled so this allow us to change it even when doing the first
> fastset after taking over previous hardware state set by BIOS.
> BIOS don't enable PSR, so if
Some DPI -> LVDS encoders might support several input bus width. Add a
DT property to describe the bus width used on a specific design.
Signed-off-by: Boris Brezillon
---
Changes in v7:
* Fix a use-after-release problem
* Get rid of the data-mapping parsing
* Use kmalloc instead of kcalloc.
This is needed to pass a bridge state to all atomic hooks, if we don't
do that, the core can't duplicate/create bridge states.
Signed-off-by: Boris Brezillon
---
Changes in v7:
* New patch
---
drivers/gpu/drm/rcar-du/rcar_lvds.c | 3 +++
1 file changed, 3 insertions(+)
diff --git
The current definition does not represent the exact display pipeline we
have on the board: the LVDS panel is actually connected through a
parallel -> LVDS bridge. Let's fix that so the driver can select the
proper bus format on the CRTC end.
Signed-off-by: Boris Brezillon
---
Changes in v7:
*
This is needed to pass a bridge state to all atomic hooks, if we don't
do that, the core can't duplicate/create bridge states.
Signed-off-by: Boris Brezillon
---
Changes in v7:
* New patch
---
drivers/gpu/drm/bridge/analogix/analogix_dp_core.c | 3 +++
1 file changed, 3 insertions(+)
diff
One of the last remaining objects to not have its atomic state.
This is being motivated by our attempt to support runtime bus-format
negotiation between elements of the bridge chain.
This patch just paves the road for such a feature by adding a new
drm_bridge_state object inheriting from
Now that bridges can expose the bus format/flags they expect, we can
use those instead of the relying on the display_info provided by the
connector (which is only valid if the encoder is directly connected
to bridge element driving the panel/display).
We also explicitly expose the bus formats
So that bridge drivers have a way to check/reject an atomic operation.
The drm_atomic_bridge_chain_check() (which is just a wrapper around
the ->atomic_check() hook) is called in place of
drm_bridge_chain_mode_fixup() (when ->atomic_check() is not implemented,
the core falls back on
1 - 100 of 199 matches
Mail list logo
