On 11/04/2023 23.07, Daniel Vetter wrote:
On Sat, Apr 08, 2023 at 04:05:20PM +0900, Asahi Lina wrote:
On 04/04/2023 10.58, Matthew Brost wrote:
On Tue, Apr 04, 2023 at 10:07:48AM +0900, Asahi Lina wrote:
Hi, thanks for the Cc!
No problem.
On 04/04/2023 09.22, Matthew Brost wrote:
Hello,
On Mon, Mar 06, 2023 at 06:51:48PM +0700, Ammar Faizi wrote:
> On Mon, Mar 06, 2023 at 12:54:59PM +0200, Jani Nikula wrote:
> > Please file a bug at fdo gitlab:
> >
> > https://gitlab.freedesktop.org/drm/intel/wikis/How-to-file-i915-bugs
>
> OK, I posted it here
Add mediatek av1 decoder linux driver which use the stateless API in
MT8195.
Signed-off-by: Xiaoyong Lu
Tested-by: Nicolas Dufresne
Reviewed-by: Nicolas Dufresne
Tested-by: AngeloGioacchino Del Regno
Reviewed-by: AngeloGioacchino Del Regno
---
Changes from v8:
- remove RFC tag in subject.
-
On 4/11/2023 6:06 PM, Dmitry Baryshkov wrote:
On 12/04/2023 01:32, Abhinav Kumar wrote:
Hi Marijn
On 4/11/2023 3:24 PM, Marijn Suijten wrote:
Again, don't forget to include previous reviewers in cc, please :)
On 2023-04-11 14:09:40, Kuogee Hsieh wrote:
Perform DSC range checking to make
Quoting Pin-yen Lin (2023-03-31 02:11:39)
> diff --git
> a/Documentation/devicetree/bindings/display/bridge/analogix,anx7625.yaml
> b/Documentation/devicetree/bindings/display/bridge/analogix,anx7625.yaml
> index b42553ac505c..604c7391d74f 100644
> ---
On Sat Apr 8, 2023 at 9:07 AM CEST, Jernej Škrabec wrote:
> Dne sreda, 05. april 2023 ob 14:34:11 CEST je Roman Beranek napisal(a):
> > While simply forbidding the video0-2x mux option seems
> > to me as the right way to go because there's not much use for it with
> > non-DSI interfaces either
Hi all,
Today's linux-next merge of the drm tree got a conflict in:
drivers/gpu/drm/amd/display/Kconfig
between commit:
78f0929884d4 ("powerpc/64: Always build with 128-bit long double")
from the powerpc tree and commit:
4652ae7a51b7 ("drm/amd/display: Rename DCN config to FP")
from
On 12/04/2023 01:32, Abhinav Kumar wrote:
Hi Marijn
On 4/11/2023 3:24 PM, Marijn Suijten wrote:
Again, don't forget to include previous reviewers in cc, please :)
On 2023-04-11 14:09:40, Kuogee Hsieh wrote:
Perform DSC range checking to make sure correct DSC is requested before
reserve
This commit adds missing luminance control registers to enable a more
standard way (VESA) to deal with eDP luminance control.
Cc: Anthony Koo
Cc: Iswara Negulendran
Cc: Felipe Clark
Cc: Harry Wentland
Signed-off-by: Rodrigo Siqueira
---
include/drm/display/drm_dp.h | 3 +++
1 file changed,
On 4/11/2023 3:14 PM, Marijn Suijten wrote:
Full-caps DSC in the title, as discussed previously.
On that note, don't forget to CC those who have reviewed your patches
previously, as also brought up in earlier review.
On 2023-04-11 14:04:55, Kuogee Hsieh wrote:
In current code, the dsc
On 12/04/2023 02:32, Abhinav Kumar wrote:
On 4/11/2023 3:17 PM, Dmitry Baryshkov wrote:
On 12/04/2023 00:04, Kuogee Hsieh wrote:
In current code, the dsc active bits are set only if the cfg->dsc is
set.
However, for displays which are hot-pluggable, there can be a use-case
of disconnecting
On 4/11/2023 3:17 PM, Dmitry Baryshkov wrote:
On 12/04/2023 00:04, Kuogee Hsieh wrote:
In current code, the dsc active bits are set only if the cfg->dsc is set.
However, for displays which are hot-pluggable, there can be a use-case
of disconnecting a DSC supported sink and connecting a
Hi Mark,
kernel test robot noticed the following build warnings:
[auto build test WARNING on drm-intel/for-linux-next-fixes]
[also build test WARNING on drm/drm-next linus/master v6.3-rc6 next-20230411]
[cannot apply to drm-tip/drm-tip drm-misc/drm-misc-next
drm-intel/for-linux-next]
[If your
From: Rob Clark
Use the new helper to export stats about memory usage.
v2: Drop unintended hunk
v3: Rebase
Signed-off-by: Rob Clark
Reviewed-by: Emil Velikov
---
drivers/gpu/drm/msm/msm_gem.c | 15 +++
1 file changed, 15 insertions(+)
diff --git a/drivers/gpu/drm/msm/msm_gem.c
From: Rob Clark
Add support to dump GEM stats to fdinfo.
v2: Fix typos, change size units to match docs, use div_u64
v3: Do it in core
Signed-off-by: Rob Clark
Reviewed-by: Emil Velikov
---
Documentation/gpu/drm-usage-stats.rst | 21
drivers/gpu/drm/drm_file.c| 76
From: Rob Clark
Signed-off-by: Rob Clark
---
drivers/gpu/drm/etnaviv/etnaviv_drv.c | 10 --
1 file changed, 4 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/etnaviv/etnaviv_drv.c
b/drivers/gpu/drm/etnaviv/etnaviv_drv.c
index 44ca803237a5..17d6af94 100644
---
From: Rob Clark
Signed-off-by: Rob Clark
---
drivers/gpu/drm/i915/i915_driver.c | 3 ++-
drivers/gpu/drm/i915/i915_drm_client.c | 18 +-
drivers/gpu/drm/i915/i915_drm_client.h | 2 +-
3 files changed, 8 insertions(+), 15 deletions(-)
diff --git
From: Rob Clark
Signed-off-by: Rob Clark
---
drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c| 3 ++-
drivers/gpu/drm/amd/amdgpu/amdgpu_fdinfo.c | 16 ++--
drivers/gpu/drm/amd/amdgpu/amdgpu_fdinfo.h | 2 +-
3 files changed, 9 insertions(+), 12 deletions(-)
diff --git
From: Rob Clark
Handle a bit of the boiler-plate in a single case, and make it easier to
add some core tracked stats.
Signed-off-by: Rob Clark
---
drivers/gpu/drm/drm_file.c | 39 ++
include/drm/drm_drv.h | 7 +++
include/drm/drm_file.h | 4
From: Rob Clark
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/msm_drv.c | 11 +--
drivers/gpu/drm/msm/msm_gpu.c | 2 --
2 files changed, 5 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/msm/msm_drv.c b/drivers/gpu/drm/msm/msm_drv.c
index 5a10d28de9dd..e516a3544505
From: Rob Clark
Similar motivation to other similar recent attempt[1]. But with an
attempt to have some shared code for this. As well as documentation.
It is probably a bit UMA-centric, I guess devices with VRAM might want
some placement stats as well. But this seems like a reasonable start.
On 12/04/2023 01:43, Marijn Suijten wrote:
As I get more and more active in the drm/msm space, yet sometimes miss
out on patches (where I was involved in previous discussions), add
myself as reviewer to make this involvement clear.
Signed-off-by: Marijn Suijten
---
Note that this is only a
As I get more and more active in the drm/msm space, yet sometimes miss
out on patches (where I was involved in previous discussions), add
myself as reviewer to make this involvement clear.
Signed-off-by: Marijn Suijten
---
Note that this is only a slight commitment from my part to look at
On 11/04/2023 21:28, Rob Clark wrote:
On Tue, Apr 11, 2023 at 10:36 AM Dmitry Baryshkov
wrote:
On Tue, 11 Apr 2023 at 20:13, Rob Clark wrote:
On Tue, Apr 11, 2023 at 9:53 AM Daniel Vetter wrote:
On Tue, Apr 11, 2023 at 09:47:32AM -0700, Rob Clark wrote:
On Mon, Apr 10, 2023 at 2:06 PM
Hi Marijn
On 4/11/2023 3:24 PM, Marijn Suijten wrote:
Again, don't forget to include previous reviewers in cc, please :)
On 2023-04-11 14:09:40, Kuogee Hsieh wrote:
Perform DSC range checking to make sure correct DSC is requested before
reserve resource for it.
This isn't performing any
From: Ville Syrjälä
In order to validate LUT programming more thoroughly let's
do a state check for all color management updates as well.
Not sure we really want this outside CI. It is rather heavy
and color management updates could become rather common
with all the HDR/etc. stuff happening.
From: Ville Syrjälä
Apparently desktop gen3 parts don't support the
10bit gamma mode at all. Stop claiming otherwise.
As is the case with pipe A on gen3 mobile parts, the
PIPECONF gamma mode bit can be set but it has no
effect on the output.
PNV seems to be the only slight exception, but
From: Ville Syrjälä
VLV has a so called "wide gamut color correction" unit (WGC).
What it is is a 3x3 matrix similar to the later CHV CGM
CSC, which less precisions/range. In fact CHV also has the WGC
but using it there doesn't reall make sense when you have the
superior CGM CSC around.
Hook up
From: Ville Syrjälä
The CHV CGM CSC coefficients are in s4.12 two's complement
format. Fix the CTM->CGM conversion to handle that correctly
instead of pretending that the hw coefficients are also
in some sign-magnitude format.
Signed-off-by: Ville Syrjälä
---
From: Ville Syrjälä
The ilk/snb code is internally fully capable of handling the
CTM property, so expose it.
Note that we still choose not to expose DEGAMMA_LUT though.
The hardware is capable if degamma or gamma, but not both
similtanously due to lack of the split gamma mode. Exposing
both
From: Ville Syrjälä
Document in which order the CTM matrix elements are stored.
Signed-off-by: Ville Syrjälä
---
include/uapi/drm/drm_mode.h | 5 +
1 file changed, 5 insertions(+)
diff --git a/include/uapi/drm/drm_mode.h b/include/uapi/drm/drm_mode.h
index 46becedf5b2f..43691058d28f
From: Ville Syrjälä
Mostly some CTM stuff:
- document the uapi better
- fix CHV CSC negative coefficients
- expose CTM on ilk/snb/vlv
- a bonus gamma patch for gen3
Test-with: 20230411161555.10001-1-ville.syrj...@linux.intel.com
Ville Syrjälä (6):
drm/uapi: Document CTM matrix better
On 11/04/2023 21:26, Daniel Vetter wrote:
On Tue, Apr 11, 2023 at 08:35:48PM +0300, Dmitry Baryshkov wrote:
On Tue, 11 Apr 2023 at 20:13, Rob Clark wrote:
On Tue, Apr 11, 2023 at 9:53 AM Daniel Vetter wrote:
On Tue, Apr 11, 2023 at 09:47:32AM -0700, Rob Clark wrote:
On Mon, Apr 10, 2023
Again, don't forget to include previous reviewers in cc, please :)
On 2023-04-11 14:09:40, Kuogee Hsieh wrote:
> Perform DSC range checking to make sure correct DSC is requested before
> reserve resource for it.
This isn't performing any range checking for resource reservations /
requests: this
On 12/04/2023 00:09, Kuogee Hsieh wrote:
Perform DSC range checking to make sure correct DSC is requested before
reserve resource for it.
Fixes: c985d7bb64ff ("drm/msm/disp/dpu1: Add DSC support in RM")
$ git log -p -1 c985d7bb64ff
fatal: ambiguous argument 'c985d7bb64ff': unknown revision or
On 12/04/2023 00:04, Kuogee Hsieh wrote:
In current code, the dsc active bits are set only if the cfg->dsc is set.
However, for displays which are hot-pluggable, there can be a use-case
of disconnecting a DSC supported sink and connecting a non-DSC sink.
For those cases we need to clear DSC
Full-caps DSC in the title, as discussed previously.
On that note, don't forget to CC those who have reviewed your patches
previously, as also brought up in earlier review.
On 2023-04-11 14:04:55, Kuogee Hsieh wrote:
> In current code, the dsc active bits are set only if the cfg->dsc is set.
> Subject: Re: [Intel-gfx] [PATCH 1/8] drm/i915/mtl: Define MOCS and PAT tables
> for MTL
>
> On Mon, Apr 10, 2023 at 08:55:16PM -0700, Yang, Fei wrote:
> ...
diff --git a/drivers/gpu/drm/i915/gt/intel_gtt.h
>>
b/drivers/gpu/drm/i915/gt/intel_gtt.h
>>
index
On 4/11/2023 2:04 PM, Kuogee Hsieh wrote:
In current code, the dsc active bits are set only if the cfg->dsc is set.
However, for displays which are hot-pluggable, there can be a use-case
of disconnecting a DSC supported sink and connecting a non-DSC sink.
For those cases we need to clear DSC
On 4/11/2023 2:09 PM, Kuogee Hsieh wrote:
Perform DSC range checking to make sure correct DSC is requested before
reserve resource for it.
Fixes: c985d7bb64ff ("drm/msm/disp/dpu1: Add DSC support in RM")
I cannot find any fixes tag with this hash.
This is the right one.
Fixes:
[Public]
> -Original Message-
> From: Nikita Zhandarovich
> Sent: Monday, April 3, 2023 2:28 PM
> To: Deucher, Alexander
> Cc: Nikita Zhandarovich ; Koenig, Christian
> ; Pan, Xinhui ; David
> Airlie ; Daniel Vetter ; amd-
> g...@lists.freedesktop.org; dri-devel@lists.freedesktop.org;
Perform DSC range checking to make sure correct DSC is requested before
reserve resource for it.
Fixes: c985d7bb64ff ("drm/msm/disp/dpu1: Add DSC support in RM")
Signed-off-by: Kuogee Hsieh
---
drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c | 10 +-
1 file changed, 9 insertions(+), 1
In current code, the dsc active bits are set only if the cfg->dsc is set.
However, for displays which are hot-pluggable, there can be a use-case
of disconnecting a DSC supported sink and connecting a non-DSC sink.
For those cases we need to clear DSC active bits during teardown.
Fixes:
On 2023-04-11 14:13, Danilo Krummrich wrote:
> On 4/5/23 19:39, Luben Tuikov wrote:
>> On 2023-03-31 01:59, Christian König wrote:
>>> Am 31.03.23 um 02:06 schrieb Danilo Krummrich:
It already happend a few times that patches slipped through which
implemented access to an entity through
> Can you please share you grub config file? It seems that is set to
> GRUB_GFXMODE=1024x768x32 but the actual mode is set to 1024x768x24 ?
Okay, but you'll be sorry... The gfxmode is set to "keep" in all the
entries. https://www.panix.com/~pa/linux-6.3-simplefb/grub.cfg .
The "TEST" entry was
On Mon, Apr 10, 2023 at 08:55:16PM -0700, Yang, Fei wrote:
...
>>> diff --git a/drivers/gpu/drm/i915/gt/intel_gtt.h
>
>>> b/drivers/gpu/drm/i915/gt/intel_gtt.h
>
>>> index 69ce55f517f5..b632167eaf2e 100644
>
>>> --- a/drivers/gpu/drm/i915/gt/intel_gtt.h
>
>>> +++
From: Sean Paul
Add HDCP 1.x support to msm DP bridges using the new HDCP
helpers.
Cc: Stephen Boyd
Reviewed-by: Stephen Boyd
Signed-off-by: Sean Paul
Signed-off-by: Mark Yacoub
---
Changes in v2:
-Squash [1] into this patch with the following changes (Stephen)
-Update the sc7180 dtsi
From: Sean Paul
Add the register ranges required for HDCP key injection and
HDCP TrustZone interaction as described in the dt-bindings for the
sc7180 dp controller.
Reviewed-by: Dmitry Baryshkov
Reviewed-by: Douglas Anderson
Signed-off-by: Sean Paul
Signed-off-by: Mark Yacoub
---
Changes
From: Sean Paul
Add the bindings for the MSM DisplayPort HDCP registers
which are required to write the HDCP key into the display controller as
well as the registers to enable HDCP authentication/key
exchange/encryption.
Cc: Rob Herring
Cc: Stephen Boyd
Reviewed-by: Rob Herring
Reviewed-by:
From: Sean Paul
Now that all of the HDCP 1.x logic has been migrated to the central HDCP
helpers, use it in the i915 driver.
The majority of the driver code for HDCP 1.x will live in intel_hdcp.c,
however there are a few helper hooks which are connector-specific and
need to be partially or
From: Sean Paul
The shim functions return error codes, but they are discarded in
intel_hdcp.c. This patch plumbs the return codes through so they are
properly handled.
Acked-by: Jani Nikula
Reviewed-by: Rodrigo Vivi
Reviewed-by: Suraj Kandpal
Signed-off-by: Sean Paul
Signed-off-by: Mark
From: Sean Paul
Stick all of the setup for HDCP into a dedicated function. No functional
change, but this will facilitate moving HDCP logic into helpers.
Acked-by: Jani Nikula
Reviewed-by: Rodrigo Vivi
Signed-off-by: Sean Paul
---
Changes in v2:
-None
Changes in v3:
-None
Changes in v4:
From: Sean Paul
Expand upon the HDCP helper library to manage HDCP enable, disable, and check.
Previous to this patch, the majority of the state management and sink
interaction is tucked inside the Intel driver with the understanding
that once a new platform supported HDCP we could make good
From: Sean Paul
Update the connector's property value in 2 cases which were
previously missed:
1- Content type changes. The value should revert back to DESIRED from
ENABLED in case the driver must re-authenticate the link due to the
new content type.
2- Userspace sets value to DESIRED
From: Sean Paul
Instead of forcing a modeset in the hdcp atomic check, rename to
drm_hdcp_has_changed and return true if the content protection value
is changing and let the driver decide whether a modeset is required or not.
Acked-by: Jani Nikula
Reviewed-by: Rodrigo Vivi
Signed-off-by: Sean
From: Sean Paul
Move the hdcp atomic check from i915 to drm_hdcp so other
drivers can use it. No functional changes, just cleaned up some of the
code when moving it over.
Acked-by: Jani Nikula
Reviewed-by: Rodrigo Vivi
Reviewed-by: Dmitry Baryshkov
Signed-off-by: Sean Paul
Signed-off-by:
Hi all,
This is v7 of the HDCP patches. The patches are authored by Sean Paul.
I rebased and addressed the review comments in v6-v9.
Main change in v9 is renaming i915 priv data and moving the display type
specific init to the drm helper instead of the driver.
Patches 1-4 focus on moving the
HI, All
Just an updated here.
As the commits listed the the following link merged into the
android-mainline kernel:
https://lore.kernel.org/linux-arm-kernel/20221102180705.459294-1-dmitry.barysh...@linaro.org/T/
The problem caused by this commit with x15 build is gone now.
Thanks,
Yongqin
On Tue, Apr 11, 2023 at 12:37:23PM -0600, Jeffrey Hugo wrote:
> On 4/11/2023 12:21 PM, Daniel Vetter wrote:
> > On Tue, Apr 11, 2023 at 11:18:29AM -0600, Jeffrey Hugo wrote:
> > > On 4/11/2023 10:31 AM, Daniel Vetter wrote:
> > > > On Tue, Apr 11, 2023 at 09:29:27AM -0600, Jeffrey Hugo wrote:
> >
Quoting Dmitry Baryshkov (2023-04-11 09:19:03)
> All adreno_is_*() functions do not modify their argument in any way, so
> they can be changed to accept const struct adreno_gpu pointer.
>
> Suggested-by: Stephen Boyd
> Signed-off-by: Dmitry Baryshkov
> ---
Reviewed-by: Stephen Boyd
Quoting Dmitry Baryshkov (2023-04-11 09:19:02)
> The commit 010c8bbad2cb ("drm: msm: adreno: Disable preemption on Adreno
> 510") tried to check GPU's revn before revn being set. Add WARN_ON_ONCE
> to prevent such bugs from happening again. A separate helper is
> necessary so that the warning is
On 4/11/2023 12:21 PM, Daniel Vetter wrote:
On Tue, Apr 11, 2023 at 11:18:29AM -0600, Jeffrey Hugo wrote:
On 4/11/2023 10:31 AM, Daniel Vetter wrote:
On Tue, Apr 11, 2023 at 09:29:27AM -0600, Jeffrey Hugo wrote:
On 4/11/2023 9:26 AM, Jeffrey Hugo wrote:
On 4/11/2023 9:13 AM, Greg KH wrote:
On Tue, Apr 11, 2023 at 10:36 AM Dmitry Baryshkov
wrote:
>
> On Tue, 11 Apr 2023 at 20:13, Rob Clark wrote:
> >
> > On Tue, Apr 11, 2023 at 9:53 AM Daniel Vetter wrote:
> > >
> > > On Tue, Apr 11, 2023 at 09:47:32AM -0700, Rob Clark wrote:
> > > > On Mon, Apr 10, 2023 at 2:06 PM Rob Clark
On Tue, Apr 11, 2023 at 08:35:48PM +0300, Dmitry Baryshkov wrote:
> On Tue, 11 Apr 2023 at 20:13, Rob Clark wrote:
> >
> > On Tue, Apr 11, 2023 at 9:53 AM Daniel Vetter wrote:
> > >
> > > On Tue, Apr 11, 2023 at 09:47:32AM -0700, Rob Clark wrote:
> > > > On Mon, Apr 10, 2023 at 2:06 PM Rob Clark
On Tue, Apr 11, 2023 at 11:18:29AM -0600, Jeffrey Hugo wrote:
> On 4/11/2023 10:31 AM, Daniel Vetter wrote:
> > On Tue, Apr 11, 2023 at 09:29:27AM -0600, Jeffrey Hugo wrote:
> > > On 4/11/2023 9:26 AM, Jeffrey Hugo wrote:
> > > > On 4/11/2023 9:13 AM, Greg KH wrote:
> > > > > On Tue, Apr 11, 2023
On 4/5/23 19:39, Luben Tuikov wrote:
On 2023-03-31 01:59, Christian König wrote:
Am 31.03.23 um 02:06 schrieb Danilo Krummrich:
It already happend a few times that patches slipped through which
implemented access to an entity through a job that was already removed
from the entities queue.
Le 26/12/2021 à 17:34, Christophe JAILLET a écrit :
'priv' is a managed resource, so there is no need to free it explicitly or
there will be a double free().
Fixes: 90ad200b4cbc ("drm/armada: Use devm_drm_dev_alloc")
Signed-off-by: Christophe JAILLET
---
drivers/gpu/drm/armada/armada_drv.c |
On Fri, 2023-03-24 at 15:54 -0400, Tom Rix wrote:
> clang with W=1 reports
> drivers/gpu/drm/vmwgfx/vmwgfx_msg.c:716:21: error: unused function
> 'mksstat_init_record' [-Werror,-Wunused-function]
> static inline char *mksstat_init_record(mksstat_kern_stats_t stat_idx,
> ^
>
On Wed, 5 Apr 2023 at 21:52, Rodrigo Vivi wrote:
>
> Let’s establish a merge plan for Xe, by writing down clear pre-merge goals, in
> order to avoid unnecessary delays.
>
> This initial document starts with a TODO list containing items with clear and
> measurable key results. Xe’s initial pull
On Tue, 2023-03-21 at 14:24 -0400, Tom Rix wrote:
> clang with W=1 reports
> drivers/gpu/drm/vmwgfx/vmwgfx_overlay.c:56:35: error:
> unused function 'vmw_overlay' [-Werror,-Wunused-function]
> static inline struct vmw_overlay *vmw_overlay(struct drm_device *dev)
>
On 4/11/23 11:10, Geert Uytterhoeven wrote:
> Hi Michel,
>
> On Wed, Apr 5, 2023 at 10:50 AM Michel Dänzer
> wrote:
>> On 4/4/23 14:36, Daniel Vetter wrote:
>>> There's a few reasons the kernel should not spam dmesg on bad
>>> userspace ioctl input:
>>> - at warning level it results in CI false
On Tue, 11 Apr 2023 at 20:13, Rob Clark wrote:
>
> On Tue, Apr 11, 2023 at 9:53 AM Daniel Vetter wrote:
> >
> > On Tue, Apr 11, 2023 at 09:47:32AM -0700, Rob Clark wrote:
> > > On Mon, Apr 10, 2023 at 2:06 PM Rob Clark wrote:
> > > >
> > > > From: Rob Clark
> > > >
> > > > Similar motivation
On 4/11/2023 10:31 AM, Daniel Vetter wrote:
On Tue, Apr 11, 2023 at 09:29:27AM -0600, Jeffrey Hugo wrote:
On 4/11/2023 9:26 AM, Jeffrey Hugo wrote:
On 4/11/2023 9:13 AM, Greg KH wrote:
On Tue, Apr 11, 2023 at 09:08:39AM -0600, Jeffrey Hugo wrote:
On 4/11/2023 9:01 AM, Daniel Vetter wrote:
On Tue, Apr 11, 2023 at 9:53 AM Daniel Vetter wrote:
>
> On Tue, Apr 11, 2023 at 09:47:32AM -0700, Rob Clark wrote:
> > On Mon, Apr 10, 2023 at 2:06 PM Rob Clark wrote:
> > >
> > > From: Rob Clark
> > >
> > > Similar motivation to other similar recent attempt[1]. But with an
> > > attempt to
On Tue, Apr 11, 2023 at 09:47:32AM -0700, Rob Clark wrote:
> On Mon, Apr 10, 2023 at 2:06 PM Rob Clark wrote:
> >
> > From: Rob Clark
> >
> > Similar motivation to other similar recent attempt[1]. But with an
> > attempt to have some shared code for this. As well as documentation.
> >
> > It
On Tue, Apr 11, 2023 at 09:41:04AM -0700, John Harrison wrote:
> On 4/11/2023 07:41, Rodrigo Vivi wrote:
> > On Mon, Apr 10, 2023 at 12:25:21PM -0700, john.c.harri...@intel.com wrote:
> > > From: John Harrison
> > >
> > > Sometimes, the only effective way to debug an issue is to dump all the
> >
On Mon, Apr 10, 2023 at 2:06 PM Rob Clark wrote:
>
> From: Rob Clark
>
> Similar motivation to other similar recent attempt[1]. But with an
> attempt to have some shared code for this. As well as documentation.
>
> It is probably a bit UMA-centric, I guess devices with VRAM might want
> some
On 4/11/2023 9:38 AM, Markus Elfring wrote:
Date: Tue, 11 Apr 2023 18:24:24 +0200
The address of a data structure member was determined before
a corresponding null pointer check in the implementation of
the functions “dpu_hw_pp_enable_te” and “dpu_hw_pp_get_vsync_info”.
Thus avoid the risk
On 11/04/2023 19:38, Markus Elfring wrote:
Date: Tue, 11 Apr 2023 18:24:24 +0200
The address of a data structure member was determined before
a corresponding null pointer check in the implementation of
the functions “dpu_hw_pp_enable_te” and “dpu_hw_pp_get_vsync_info”.
Thus avoid the risk for
On 4/11/2023 07:41, Rodrigo Vivi wrote:
On Mon, Apr 10, 2023 at 12:25:21PM -0700, john.c.harri...@intel.com wrote:
From: John Harrison
Sometimes, the only effective way to debug an issue is to dump all the
interesting information at the point of failure. So add support for
doing that.
No!
Date: Tue, 11 Apr 2023 18:24:24 +0200
The address of a data structure member was determined before
a corresponding null pointer check in the implementation of
the functions “dpu_hw_pp_enable_te” and “dpu_hw_pp_get_vsync_info”.
Thus avoid the risk for undefined behaviour by removing extra
On Tue, Apr 11, 2023 at 09:29:27AM -0600, Jeffrey Hugo wrote:
> On 4/11/2023 9:26 AM, Jeffrey Hugo wrote:
> > On 4/11/2023 9:13 AM, Greg KH wrote:
> > > On Tue, Apr 11, 2023 at 09:08:39AM -0600, Jeffrey Hugo wrote:
> > > > On 4/11/2023 9:01 AM, Daniel Vetter wrote:
> > > > > On Tue, Apr 11, 2023
All adreno_is_*() functions do not modify their argument in any way, so
they can be changed to accept const struct adreno_gpu pointer.
Suggested-by: Stephen Boyd
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/adreno/adreno_gpu.h | 56 -
1 file changed, 28
The commit 010c8bbad2cb ("drm: msm: adreno: Disable preemption on Adreno
510") tried to check GPU's revn before revn being set. Add WARN_ON_ONCE
to prevent such bugs from happening again. A separate helper is
necessary so that the warning is displayed really just once instead of
being displayed
Hi Daniel,
On Tue, Apr 11, 2023 at 3:44 PM Daniel Vetter wrote:
> On Tue, Apr 04, 2023 at 09:39:34PM +0200, Daniel Vetter wrote:
> > This is an oversight from dc5bdb68b5b3 ("drm/fb-helper: Fix vt
> > restore") - I failed to realize that nasty userspace could set this.
> >
> > It's not pretty to
On Tue, Apr 11, 2023 at 8:00 AM Daniel Vetter wrote:
>
> On Tue, Apr 11, 2023 at 07:55:33AM -0700, Rob Clark wrote:
> > On Tue, Apr 11, 2023 at 3:27 AM Daniel Vetter wrote:
> > > > Konrad Dybcio (18):
> > > > drm/msm/adreno: Use OPP for every GPU generation
> > >
> > > This had a minor
"Pierre Asselin" writes:
Hello Pierre,
> Oh oh, I just reproduced the problem on a desktop tower, a Dell Precision
> T3610, probably 2019 vintage. The only thing in common with the old
> laptop, that I can think of, is that both use the legacy BIOS. The Dell
> has EFI but the graphics card
On 4/11/2023 9:26 AM, Jeffrey Hugo wrote:
On 4/11/2023 9:13 AM, Greg KH wrote:
On Tue, Apr 11, 2023 at 09:08:39AM -0600, Jeffrey Hugo wrote:
On 4/11/2023 9:01 AM, Daniel Vetter wrote:
On Tue, Apr 11, 2023 at 12:40:28PM +0200, Greg KH wrote:
On Tue, Apr 11, 2023 at 11:55:20AM +0200, Daniel
On 4/11/2023 9:13 AM, Greg KH wrote:
On Tue, Apr 11, 2023 at 09:08:39AM -0600, Jeffrey Hugo wrote:
On 4/11/2023 9:01 AM, Daniel Vetter wrote:
On Tue, Apr 11, 2023 at 12:40:28PM +0200, Greg KH wrote:
On Tue, Apr 11, 2023 at 11:55:20AM +0200, Daniel Vetter wrote:
On Tue, Apr 11, 2023 at
On 4/11/23 16:36, Daniel Vetter wrote:
On Fri, Apr 07, 2023 at 10:54:00PM +0200, Helge Deller wrote:
On 4/6/23 15:21, Thomas Zimmermann wrote:
From: Daniel Vetter
Since vgaarb has been promoted to be a core piece of the pci subsystem
we don't have to open code random guesses anymore, we
Hi,
On Mon, Apr 10, 2023 at 09:47:48AM +0100, Brandon Cheo Fusi wrote:
> This change moves DSI PHY poweron/off from the encoder to the TCON.
>
> As a consequence enabling or disabling the DSI sink can be left to the
> modeset helpers, and bridge support easily introduced without touching
> the
On Tue, Apr 11, 2023 at 09:08:39AM -0600, Jeffrey Hugo wrote:
> On 4/11/2023 9:01 AM, Daniel Vetter wrote:
> > On Tue, Apr 11, 2023 at 12:40:28PM +0200, Greg KH wrote:
> > > On Tue, Apr 11, 2023 at 11:55:20AM +0200, Daniel Vetter wrote:
> > > > On Tue, Apr 11, 2023 at 02:38:12PM +1000, Stephen
On Tue, Apr 11, 2023 at 08:02:09AM -0700, Rob Clark wrote:
> On Tue, Apr 11, 2023 at 3:43 AM Daniel Vetter wrote:
> >
> > On Mon, Apr 10, 2023 at 02:06:06PM -0700, Rob Clark wrote:
> > > From: Rob Clark
> > >
> > > Add a helper to dump memory stats to fdinfo. For the things the drm
> > > core
On 4/11/2023 9:01 AM, Daniel Vetter wrote:
On Tue, Apr 11, 2023 at 12:40:28PM +0200, Greg KH wrote:
On Tue, Apr 11, 2023 at 11:55:20AM +0200, Daniel Vetter wrote:
On Tue, Apr 11, 2023 at 02:38:12PM +1000, Stephen Rothwell wrote:
Hi all,
After merging the driver-core tree, today's linux-next
Am 11.04.23 um 15:43 schrieb Markus Elfring:
Date: Tue, 11 Apr 2023 11:39:02 +0200
The address of a data structure member was determined before
a corresponding null pointer check in the implementation of
the function “trigger_hotplug”.
Thus avoid the risk for undefined behaviour by moving the
On Tue, Apr 11, 2023 at 3:43 AM Daniel Vetter wrote:
>
> On Mon, Apr 10, 2023 at 02:06:06PM -0700, Rob Clark wrote:
> > From: Rob Clark
> >
> > Add a helper to dump memory stats to fdinfo. For the things the drm
> > core isn't aware of, use a callback.
> >
> > v2: Fix typos, change size units
On Tue, Apr 11, 2023 at 12:40:28PM +0200, Greg KH wrote:
> On Tue, Apr 11, 2023 at 11:55:20AM +0200, Daniel Vetter wrote:
> > On Tue, Apr 11, 2023 at 02:38:12PM +1000, Stephen Rothwell wrote:
> > > Hi all,
> > >
> > > After merging the driver-core tree, today's linux-next build (x86_64
> > >
On Tue, Apr 11, 2023 at 07:55:33AM -0700, Rob Clark wrote:
> On Tue, Apr 11, 2023 at 3:27 AM Daniel Vetter wrote:
> > > Konrad Dybcio (18):
> > > drm/msm/adreno: Use OPP for every GPU generation
> >
> > This had a minor conflict with refactoring from drm-misc-next, I went
> > what's in your
On Tue, Apr 11, 2023 at 3:27 AM Daniel Vetter wrote:
>
> On Mon, Apr 10, 2023 at 07:50:50AM -0700, Rob Clark wrote:
> > Hi Dave,
> >
> > This is the main pull for v6.4, see below for description. A bit big
> > this time because of (1) generated header updates and (2) dpu hw
> > catelog rework
On Sun, Apr 09, 2023 at 09:21:10PM +0800, Sui Jingfeng wrote:
> From: Sui Jingfeng
>
> We should setting the screen buffer size according to the screen's actual
> size, rather than the size of the GEM object backing the front framebuffer.
> The size of GEM buffer is page size aligned, while the
1 - 100 of 205 matches
Mail list logo
