On 6/16/2023 8:54 AM, Ceraolo Spurio, Daniele wrote:
On 6/15/2023 2:19 PM, Alan Previn wrote:
intel_gsc_uc_fw_proxy_init_done is used by a few code paths
and usages. However, certain paths need a wakeref while others
can't take a wakeref such as from the runtime_pm_resume callstack.
Add a
Hi Simon,
Thank you for the patch.
On Tue, Jun 20, 2023 at 05:55:09PM +, Simon Ser wrote:
> This adds more information to the hotplug uevent and lets user-space
> know that it's about a particular connector only.
>
> Signed-off-by: Simon Ser
> Cc: Dmitry Baryshkov
> Cc: Paul Cercueil
>
On 20/06/2023 14:40, Dmitry Baryshkov wrote:
This looks like a boilerplate being added to all aYxx drivers (and
then these fields are also set in adreno_gpu_init()). Can we remove
duplication somehow?
Sorry, I missed this comment prior to sending v2.
Maybe a simpler fix for a2xx_gpu would
Hi Simon,
On Tue, Jun 20, 2023 at 05:55:09PM +, Simon Ser wrote:
> This adds more information to the hotplug uevent and lets user-space
> know that it's about a particular connector only.
Will this change have impact on user space?
They will start to see CONNECTOR=n where they did not occur
Hm, I suppose it's not -impossible- for this to return NULL, but if it does
return NULL that absolutely means something broke well before this point in
the code. More comments below:
On Wed, 2023-06-14 at 09:09 -0700, Chenyuan Mi wrote:
> The drm_atomic_get_mst_payload_state() function may
>
On martedì 20 giugno 2023 20:01:48 CEST Sumitra Sharma wrote:
> Remove unnecessary calls to kmap{,_atomic}() when acquiring
> pages using GFP_DMA32.
>
> The GFP_DMA32 uses the DMA32 zone to satisfy the allocation
> requests. Therefore, pages allocated with GFP_DMA32 cannot
> come from Highmem.
>
On 20/06/2023 20:33, Fabio Estevam wrote:
From: Fabio Estevam
Commit cc943f43ece7 ("drm/msm/adreno: warn if chip revn is verified
before being set") exposes the need of setting the GPU revision fields
prior to using the adreno_is_xxx() functions.
Pass the GPU revision information to avoid
On Tue, Jun 20, 2023 at 10:25:21AM -0700, Lucas De Marchi wrote:
> On Tue, Jun 20, 2023 at 05:55:19PM +0300, Andy Shevchenko wrote:
> > On Tue, Jun 20, 2023 at 05:47:34PM +0300, Jani Nikula wrote:
> > > On Thu, 15 Jun 2023, Andy Shevchenko
> > > wrote:
> > > > On Fri, May 12, 2023 at 02:45:19PM
This adds more information to the hotplug uevent and lets user-space
know that it's about a particular connector only.
Signed-off-by: Simon Ser
Cc: Dmitry Baryshkov
Cc: Paul Cercueil
Cc: Laurent Pinchart
Cc: Sam Ravnborg
---
drivers/gpu/drm/drm_bridge_connector.c | 2 +-
1 file changed, 1
From: Ivan Orlov
Now that the driver core allows for struct class to be in read-only
memory, move the accel_class structure to be declared at build time
placing it into read-only memory, instead of having to be dynamically
allocated at boot time.
Cc: Oded Gabbay
Cc:
[Public]
You've got an A-b from Evan already on this. It looks fine to me too.
Reviewed-by: Mario Limonciello
> -Original Message-
> From: Yang, WenYou
> Sent: Sunday, June 11, 2023 12:53 AM
> To: Yang, WenYou ; Deucher, Alexander
> ; Limonciello, Mario
> ; Koenig, Christian
> ; Pan,
Also since I forgot, so patchwork picks this up:
Reviewed-by: Lyude Paul
On Tue, 2023-06-20 at 15:50 -0400, Lyude Paul wrote:
> Eek - this might have been a situation where everyone involved assumed someone
> else would push it, whoops. I'll make sure this is pushed upstream :).
>
> FWIW: You
Hi,
This is a new version of the documentation for DRM device resets. As I dived
more in the subject, I started to believe that part of the problem was the lack
of a DRM API to get reset information from the driver. With an API, we can
better standardize reset queries, increase common code from
Create a section that specifies how to deal with DRM device resets for
kernel and userspace drivers.
Signed-off-by: André Almeida
---
Documentation/gpu/drm-uapi.rst | 65 ++
1 file changed, 65 insertions(+)
diff --git a/Documentation/gpu/drm-uapi.rst
Create a new DRM ioctl operation to get the numbers of resets for a
given context. The numbers reflect just the resets that happened after
the context was created, and not since the machine was booted.
Create a debugfs interface to make easier to test the API without real
resets.
Signed-off-by:
Implement get_reset ioctl for amdgpu
Signed-off-by: André Almeida
---
drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c | 4 ++-
drivers/gpu/drm/amd/amdgpu/amdgpu_ctx.c | 35 +
drivers/gpu/drm/amd/amdgpu/amdgpu_ctx.h | 5
drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 1 +
Implement get_reset ioctl for i915.
Signed-off-by: André Almeida
---
drivers/gpu/drm/i915/gem/i915_gem_context.c| 18 ++
drivers/gpu/drm/i915/gem/i915_gem_context.h| 2 ++
.../gpu/drm/i915/gem/i915_gem_context_types.h | 2 ++
drivers/gpu/drm/i915/i915_driver.c
msm/adreno/adreno_gpu.h:171
a2xx_gpu_init+0x138/0x184
Modules linked in:
CPU: 0 PID: 1 Comm: swapper/0 Not tainted 6.4.0-rc7-next-20230620 #993
Pass the GPU revision information to avoid run-time warning.
Tested on a imx53-qsb board.
Signed-off-by: Fabio Estevam
---
Changes since v1:
- Ma
From: Fabio Estevam
Commit cc943f43ece7 ("drm/msm/adreno: warn if chip revn is verified
before being set") exposes the need of setting the GPU revision fields
prior to using the adreno_is_xxx() functions.
Pass the GPU revision information to avoid run-time warning.
Signed-off-by: Fabio Estevam
[AMD Official Use Only - General]
> -Original Message-
> From: Limonciello, Mario
> Sent: Monday, June 19, 2023 10:04 AM
> To: Quan, Evan
> Cc: linux-ker...@vger.kernel.org; linux-a...@vger.kernel.org; amd-
> g...@lists.freedesktop.org; dri-devel@lists.freedesktop.org; linux-
>
Hi Simon.
On Tue, Jun 20, 2023 at 05:42:42PM +, Simon Ser wrote:
> Rename drm_sysfs_connector_status_event() to
> drm_sysfs_connector_property_event(). Indeed, "status" is a bit
> vague: it can easily be confused with the connected/disconnected
> status of the connector. This function has
Hi Su,
kernel test robot noticed the following build warnings:
[auto build test WARNING on drm-misc/drm-misc-next]
[also build test WARNING on linus/master v6.4-rc7 next-20230620]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use
Eek - this might have been a situation where everyone involved assumed someone
else would push it, whoops. I'll make sure this is pushed upstream :).
FWIW: You could definitely send an MR to the fedora kernel's gitlab to get
this included earlier. If you don't get to it before me I'll try to do
[AMD Official Use Only - General]
> -Original Message-
> From: Limonciello, Mario
> Sent: Monday, June 19, 2023 10:17 AM
> To: Quan, Evan
> Cc: linux-ker...@vger.kernel.org; linux-a...@vger.kernel.org; amd-
> g...@lists.freedesktop.org; dri-devel@lists.freedesktop.org; linux-
>
The scenario being fixed here is depicted in the following sequence-
modprobe i915
echo 1 > /sys/class/drm/card0/gt/gt0/slpc_ignore_eff_freq
echo 300 > /sys/class/drm/card0/gt_min_freq_mhz (RPn)
cat /sys/class/drm/card0/gt_cur_freq_mhz --> cur == RPn as expected
echo 1 >
On Tue, Jun 20, 2023 at 08:41:10PM +0300, Andy Shevchenko wrote:
On Tue, Jun 20, 2023 at 10:25:21AM -0700, Lucas De Marchi wrote:
On Tue, Jun 20, 2023 at 05:55:19PM +0300, Andy Shevchenko wrote:
> On Tue, Jun 20, 2023 at 05:47:34PM +0300, Jani Nikula wrote:
> > On Thu, 15 Jun 2023, Andy
On Sun, Jun 18, 2023 at 11:28:20AM +0300, Oded Gabbay wrote:
On Thu, Jun 15, 2023 at 7:34 PM Matt Roper wrote:
On Thu, Jun 15, 2023 at 04:04:18PM +0300, Oded Gabbay wrote:
> On Thu, Jun 15, 2023 at 3:01 AM Matt Roper wrote:
> >
> > On Mon, Jun 12, 2023 at 06:31:57PM +0200, Francois Dugast
From: Fabio Estevam
The adreno_is_a20x() and adreno_is_a225() functions rely on the
GPU revision, but such information is retrieved inside adreno_gpu_init(),
which is called afterwards.
Fix this problem by caling adreno_gpu_init() earlier, so that
the GPU information revision is available when
On 6/20/2023 3:11 PM, Dmitry Baryshkov wrote:
On Wed, 21 Jun 2023 at 00:37, Jessica Zhang wrote:
On 6/16/2023 5:37 PM, Dmitry Baryshkov wrote:
On 17/06/2023 00:10, Abhinav Kumar wrote:
On 6/14/2023 1:43 PM, Dmitry Baryshkov wrote:
On 14/06/2023 23:39, Abhinav Kumar wrote:
On
Hi Su,
kernel test robot noticed the following build warnings:
[auto build test WARNING on drm-misc/drm-misc-next]
[also build test WARNING on linus/master v6.4-rc7 next-20230620]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use
From: Fabio Estevam
Commit cc943f43ece7 ("drm/msm/adreno: warn if chip revn is verified
before being set") exposes the need of setting the GPU revision fields
prior to using the adreno_is_xxx() functions.
Pass the GPU revision information to avoid run-time warning.
Signed-off-by: Fabio Estevam
From: Fabio Estevam
Commit cc943f43ece7 ("drm/msm/adreno: warn if chip revn is verified
before being set") exposes the need of setting the GPU revision fields
prior to using the adreno_is_xxx() functions.
Pass the GPU revision information to avoid run-time warning.
Signed-off-by: Fabio Estevam
On Tue, Jun 20, 2023 at 06:23:38AM -0700, Ira Weiny wrote:
> Sumitra Sharma wrote:
> > On Sun, Jun 18, 2023 at 11:11:08AM -0700, Ira Weiny wrote:
> > > Sumitra Sharma wrote:
> > > > kmap() has been deprecated in favor of the kmap_local_page()
> > > > due to high cost, restricted mapping space,
[AMD Official Use Only - General]
> -Original Message-
> From: Johannes Berg
> Sent: Monday, June 19, 2023 4:24 PM
> To: Limonciello, Mario ; Quan, Evan
>
> Cc: linux-ker...@vger.kernel.org; linux-a...@vger.kernel.org; amd-
> g...@lists.freedesktop.org; dri-devel@lists.freedesktop.org;
From: Fabio Estevam
Commit cc943f43ece7 ("drm/msm/adreno: warn if chip revn is verified
before being set") exposes the need of setting the GPU revision fields
prior to using the adreno_is_xxx() functions.
Pass the GPU revision information to avoid run-time warning.
Signed-off-by: Fabio Estevam
Rename drm_sysfs_connector_status_event() to
drm_sysfs_connector_property_event(). Indeed, "status" is a bit
vague: it can easily be confused with the connected/disconnected
status of the connector. This function has nothing to do with
connected/disconnected: it merely sends a notification that a
On Tuesday, June 20th, 2023 at 20:58, Sam Ravnborg wrote:
> On Tue, Jun 20, 2023 at 05:55:09PM +, Simon Ser wrote:
>
> > This adds more information to the hotplug uevent and lets user-space
> > know that it's about a particular connector only.
>
> Will this change have impact on user
On Tue, 20 Jun 2023 at 21:14, Fabio Estevam wrote:
>
> On 20/06/2023 14:40, Dmitry Baryshkov wrote:
>
> > This looks like a boilerplate being added to all aYxx drivers (and
> > then these fields are also set in adreno_gpu_init()). Can we remove
> > duplication somehow?
>
> Sorry, I missed this
From: Fabio Estevam
Commit cc943f43ece7 ("drm/msm/adreno: warn if chip revn is verified
before being set") exposes the need of setting the GPU revision fields
prior to using the adreno_is_xxx() functions.
Pass the GPU revision information to avoid run-time warning.
Signed-off-by: Fabio Estevam
From: Fabio Estevam
Commit cc943f43ece7 ("drm/msm/adreno: warn if chip revn is verified
before being set") exposes the need of setting the GPU revision fields
prior to using the adreno_is_xxx() functions.
Pass the GPU revision information to avoid run-time warning.
Signed-off-by: Fabio Estevam
Remove unnecessary calls to kmap{,_atomic}() when acquiring
pages using GFP_DMA32.
The GFP_DMA32 uses the DMA32 zone to satisfy the allocation
requests. Therefore, pages allocated with GFP_DMA32 cannot
come from Highmem.
Avoid using calls to kmap_local_page() / kunmap_local() and
kmap() /
On Tue, 20 Jun 2023, Andy Shevchenko wrote:
> So, what does prevent you from using GENMASK_ULL()?
>
> Another point, you may teach GENMASK() to issue a warning if hi and/or lo
> bigger than BITS_PER_LONG.
What good does that do if you want the warning for a fixed size
different from unsigned
[AMD Official Use Only - General]
> -Original Message-
> From: Lazar, Lijo
> Sent: Monday, June 19, 2023 10:55 PM
> To: Quan, Evan ; raf...@kernel.org; l...@kernel.org;
> Deucher, Alexander ; Koenig, Christian
> ; Pan, Xinhui ;
> airl...@gmail.com; dan...@ffwll.ch; kv...@kernel.org;
Hi Simon,
On Tue, Jun 20, 2023 at 07:01:59PM +, Simon Ser wrote:
> On Tuesday, June 20th, 2023 at 20:58, Sam Ravnborg wrote:
>
> > On Tue, Jun 20, 2023 at 05:55:09PM +, Simon Ser wrote:
> >
> > > This adds more information to the hotplug uevent and lets user-space
> > > know that it's
On 6/16/2023 5:37 PM, Dmitry Baryshkov wrote:
On 17/06/2023 00:10, Abhinav Kumar wrote:
On 6/14/2023 1:43 PM, Dmitry Baryshkov wrote:
On 14/06/2023 23:39, Abhinav Kumar wrote:
On 6/14/2023 12:54 PM, Abhinav Kumar wrote:
On 6/14/2023 12:35 PM, Abhinav Kumar wrote:
On 6/14/2023
On 6/16/2023 5:35 PM, Dmitry Baryshkov wrote:
On 17/06/2023 00:54, Marijn Suijten wrote:
On 2023-06-16 14:18:39, Abhinav Kumar wrote:
On 6/14/2023 12:56 AM, Dmitry Baryshkov wrote:
On 14/06/2023 04:57, Jessica Zhang wrote:
Add a DPU INTF op to set the DATABUS_WIDEN register to enable
On Wed, 21 Jun 2023 at 00:37, Jessica Zhang wrote:
>
>
>
> On 6/16/2023 5:37 PM, Dmitry Baryshkov wrote:
> > On 17/06/2023 00:10, Abhinav Kumar wrote:
> >>
> >>
> >> On 6/14/2023 1:43 PM, Dmitry Baryshkov wrote:
> >>> On 14/06/2023 23:39, Abhinav Kumar wrote:
>
>
> On 6/14/2023
On Wed, 21 Jun 2023 at 00:38, Jessica Zhang wrote:
>
>
>
> On 6/16/2023 5:35 PM, Dmitry Baryshkov wrote:
> > On 17/06/2023 00:54, Marijn Suijten wrote:
> >> On 2023-06-16 14:18:39, Abhinav Kumar wrote:
> >>>
> >>>
> >>> On 6/14/2023 12:56 AM, Dmitry Baryshkov wrote:
> On 14/06/2023 04:57,
Hi Jason-JH.Lin,
kernel test robot noticed the following build errors:
[auto build test ERROR on drm-misc/drm-misc-next]
[also build test ERROR on linus/master v6.4-rc7 next-20230620]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest
From: Mario Limonciello
Due to electrical and mechanical constraints in certain platform designs
there may be likely interference of relatively high-powered harmonics of
the (G-)DDR memory clocks with local radio module frequency bands used
by Wifi 6/6e/7.
To mitigate this, AMD has introduced
To support AMD's WBRF interference mitigation mechanism, Wifi adapters
utilized in the system must register the frequencies in use(or unregister
those frequencies no longer used) via the dedicated APCI calls. So that,
other drivers responding to the frequencies can take proper actions to
mitigate
The newly added WBRF feature needs this interface for channel
width calculation.
Signed-off-by: Evan Quan
---
include/net/cfg80211.h | 8
net/wireless/chan.c| 3 ++-
2 files changed, 10 insertions(+), 1 deletion(-)
diff --git a/include/net/cfg80211.h b/include/net/cfg80211.h
index
Due to electrical and mechanical constraints in certain platform designs there
may
be likely interference of relatively high-powered harmonics of the (G-)DDR
memory
clocks with local radio module frequency bands used by Wifi 6/6e/7. To mitigate
possible RFI interference producers can advertise
With WBRF feature supported, as a driver responding to the frequencies,
amdgpu driver is able to do shadow pstate switching to mitigate possible
interference(between its (G-)DDR memory clocks and local radio module
frequency bands used by Wifi 6/6e/7).
To make WBRF feature functional, the kernel
Fulfill the SMU13.0.0 support for Wifi RFI mitigation feature.
Signed-off-by: Evan Quan
Reviewed-by: Mario Limonciello
---
drivers/gpu/drm/amd/pm/swsmu/inc/amdgpu_smu.h | 3 +
drivers/gpu/drm/amd/pm/swsmu/inc/smu_types.h | 3 +-
drivers/gpu/drm/amd/pm/swsmu/inc/smu_v13_0.h | 3 +
Add those data structures to support Wifi RFI mitigation feature.
Signed-off-by: Evan Quan
Reviewed-by: Mario Limonciello
---
.../pm/swsmu/inc/pmfw_if/smu13_driver_if_v13_0_0.h | 14 +-
.../pm/swsmu/inc/pmfw_if/smu13_driver_if_v13_0_7.h | 14 +-
To protect PMFW from being overloaded.
Signed-off-by: Evan Quan
Reviewed-by: Mario Limonciello
---
drivers/gpu/drm/amd/pm/swsmu/amdgpu_smu.c | 28 ---
drivers/gpu/drm/amd/pm/swsmu/inc/amdgpu_smu.h | 7 +
2 files changed, 31 insertions(+), 4 deletions(-)
diff --git
Hi Rob,
Thanks for your comments,
> -Original Message-
> From: Rob Herring
> Sent: 2023年6月20日 23:49
> To: Sandor Yu
> Cc: andrzej.ha...@intel.com; neil.armstr...@linaro.org;
> robert.f...@linaro.org; laurent.pinch...@ideasonboard.com;
> jo...@kwiboo.se; jernej.skra...@gmail.com;
Hi Danilo,
kernel test robot noticed the following build errors:
[auto build test ERROR on dcb0775d36de28992f56455ab3967b30d380]
url:
https://github.com/intel-lab-lkp/linux/commits/Danilo-Krummrich/drm-execution-context-for-GEM-buffers-v4/20230620-084448
base
Am 20.06.23 um 17:58 schrieb Dmitry Osipenko:
On 5/31/23 22:58, Dmitry Osipenko wrote:
On 5/30/23 01:39, Dmitry Osipenko wrote:
Change locking policy of mmap() callback, making exporters responsible
for handling dma-buf reservation locking. Previous locking policy stated
that dma-buf is locked
On Fri, 16 Jun 2023 15:14:16 -0700 Justin Chen wrote:
> Add support for the Broadcom ASP 2.0 Ethernet controller which is first
> introduced with 72165. This controller features two distinct Ethernet
> ports that can be independently operated.
First of all - thanks for splitting the patches up.
Fulfill the SMU13.0.7 support for Wifi RFI mitigation feature.
Signed-off-by: Evan Quan
Reviewed-by: Mario Limonciello
---
.../drm/amd/pm/swsmu/smu13/smu_v13_0_7_ppt.c | 59 +++
1 file changed, 59 insertions(+)
diff --git a/drivers/gpu/drm/amd/pm/swsmu/smu13/smu_v13_0_7_ppt.c
[AMD Official Use Only - General]
Could you add the expected units of voltage/current in 2.4 metrics structure?
Is it mV/mA or mV/A?
Thanks,
Lijo
-Original Message-
From: amd-gfx On Behalf Of Wenyou Yang
Sent: Thursday, June 1, 2023 7:08 AM
To: Deucher, Alexander ; Limonciello, Mario
Hi Gerd,
>
> On Mon, May 15, 2023 at 10:04:42AM -0700, Mike Kravetz wrote:
> > On 05/12/23 16:29, Mike Kravetz wrote:
> > > On 05/12/23 14:26, James Houghton wrote:
> > > > On Fri, May 12, 2023 at 12:20 AM Junxiao Chang
> wrote:
> > > >
> > > > This alone doesn't fix mapcounting for PTE-mapped
On 6/15/23 23:19, Cyril Brulebois wrote:
Hi Rob,
Rob Herring (2023-06-15):
On Thu, Jun 15, 2023 at 03:21:07PM +0200, Michal Suchánek wrote:
At the time this was proposed it was said that "of-display", is wrong,
and that "of-display.0" must be used for the first device instead, and
if
On Mon, 19 Jun 2023 14:29:23 +0200
Boris Brezillon wrote:
> On Mon, 19 Jun 2023 12:44:06 +0200
> Christian König wrote:
>
> > Am 19.06.23 um 12:12 schrieb Boris Brezillon:
> > > [SNIP]
> > > Note that the drm_exec_until_all_locked() helper I introduced is taking
> > > an expression, so in
It's possible for users to try to duplicate the CRTC state even when the
state doesn't exist. drm_atomic_helper_crtc_duplicate_state() (and other
users of __drm_atomic_helper_crtc_duplicate_state()) already guard this
with a WARN_ON() instead of crashing, so let's do that here too.
Fixes:
vop_plane_destroy and vop_crtc_destroy are plain wrappers around
drm_plane_cleanup and drm_crtc_cleanup. Use them directly as plane and
crtc funcs to closer match VOP2 driver.
Signed-off-by: Jonas Karlman
---
drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 16 +++-
1 file changed, 3
This series fixes a reset of state in duplicate state crtc funcs for VOP
driver, a possible crash and ensure crtc reset helper is called in VOP2
driver.
Patch 1 use kmemdup instead of kzalloc to duplicate the crtc state.
Patch 2 change to use crtc and plane cleanup helpers directly.
Patch 3 adds
struct rockchip_crtc_state members such as output_type, output_bpc and
enable_afbc is always reset to zero in the atomic_duplicate_state crtc
funcs.
Fix this by using kmemdup on the subclass rockchip_crtc_state struct.
Fixes: 4e257d9eee23 ("drm/rockchip: get rid of
Add missing call to crtc reset helper to properly vblank reset.
Also move vop2_crtc_reset and call vop2_crtc_destroy_state to simplify
and remove duplicated code.
Fixes: 604be85547ce ("drm/rockchip: Add VOP2 driver")
Signed-off-by: Jonas Karlman
---
drivers/gpu/drm/rockchip/rockchip_drm_vop2.c
Hi Maxime,
CC sfr
On Mon, Jun 19, 2023 at 2:51 PM Maxime Ripard wrote:
> On Mon, Jun 19, 2023 at 12:53:42PM +0200, Uwe Kleine-König wrote:
> > On Mon, Jun 19, 2023 at 11:45:37AM +0200, Maxime Ripard wrote:
> > > On Sun, Jun 18, 2023 at 06:29:50PM +0200, Uwe Kleine-König wrote:
> > > > On Sun,
Use zero as the return value instead of the unused variable ret
Signed-off-by: Li Dong
---
drivers/gpu/drm/panel/panel-samsung-s6d7aa0.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/panel/panel-samsung-s6d7aa0.c
Hello Maxime,
On Mon, Jun 19, 2023 at 02:47:09PM +0200, Maxime Ripard wrote:
> On Mon, Jun 19, 2023 at 12:53:42PM +0200, Uwe Kleine-König wrote:
> > IMHO you still should ensure that only commits make it into any next
> > snapshot via your tree before X-rc1 for some X (e.g. v6.5) that you
> >
It would be better to replace the traditional ternary conditional operator with
max()
Signed-off-by: Li Dong
---
drivers/gpu/drm/amd/display/modules/freesync/freesync.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/modules/freesync/freesync.c
Hi Maxime,
On Mon, Jun 19, 2023 at 4:02 PM Maxime Ripard wrote:
> On Mon, Jun 19, 2023 at 03:25:28PM +0200, Geert Uytterhoeven wrote:
> > On Mon, Jun 19, 2023 at 2:51 PM Maxime Ripard wrote:
> > > On Mon, Jun 19, 2023 at 12:53:42PM +0200, Uwe Kleine-König wrote:
> > > > On Mon, Jun 19, 2023 at
On Mon, Jun 19, 2023 at 03:25:28PM +0200, Geert Uytterhoeven wrote:
> Hi Maxime,
>
> CC sfr
>
> On Mon, Jun 19, 2023 at 2:51 PM Maxime Ripard wrote:
> > On Mon, Jun 19, 2023 at 12:53:42PM +0200, Uwe Kleine-König wrote:
> > > On Mon, Jun 19, 2023 at 11:45:37AM +0200, Maxime Ripard wrote:
> > > >
The led_access lock must be held when calling led_sysfs_enable() and
led_sysfs_disable(). This fixes warnings such as this:
[2.432495] [ cut here ]
[2.437316] WARNING: CPU: 0 PID: 22 at drivers/leds/led-core.c:349
led_sysfs_disable+0x54/0x58
[2.446105]
Hi Konrad,
kernel test robot noticed the following build errors:
[auto build test ERROR on 47045630bc409ce6606d97b790895210dd1d517d]
url:
https://github.com/intel-lab-lkp/linux/commits/Konrad-Dybcio/drm-msm-a6xx-Add-some-missing-header-definitions/20230620-004639
base
On Tue, Jun 20, 2023 at 12:59:19PM +0800, Su Hui wrote:
> Smatch error:
> gpu/drm/amd/amdgpu/amdgv_sriovmsg.h:316:49: error:
> static assertion failed: "amd_sriov_msg_pf2vf_info must be 1 KB"
> static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
>
I doubt that moving the
Clear all assignments of struct drm_driver's fd/handle callbacks to
drm_gem_prime_fd_to_handle() and drm_gem_prime_handle_to_fd(). These
functions are called by default. Add a TODO item to convert vmwgfx
to the defaults as well.
v2:
* remove TODO item (Zack)
* also update amdgpu's
Set drm_gem_prime_handle_to_fd() and drm_gem_prime_fd_to_handle()
for all DRM drivers. Even drivers that do not support PRIME import
or export of dma-bufs can now import their own buffer objects. This
is required by some userspace, such as wlroots-based compositors, to
share buffers among
Unexport drm_gem_prime_fd_to_handle() and drm_gem_prime_handle_to_fd().
Both are only used internally within the PRIME code.
v2:
* reword docs as functions are now unexported (Simon)
Signed-off-by: Thomas Zimmermann
Reviewed-by: Simon Ser
Acked-by: Alex Deucher
---
Call drm_gem_prime_handle_to_fd() and drm_gem_prime_fd_to_handle() by
default if no PRIME import/export helpers have been set. Both functions
are the default for almost all drivers.
DRM drivers implement struct drm_driver.gem_prime_import_sg_table
to import dma-buf objects from other drivers.
Am 20.06.23 um 06:14 schrieb Tatsuyuki Ishi:
On 6/20/23 13:07, Tatsuyuki Ishi wrote:
@@ -1296,9 +1271,8 @@ static int amdgpu_cs_submit(struct
amdgpu_cs_parser *p,
*/
r = 0;
amdgpu_bo_list_for_each_userptr_entry(e, p->bo_list) {
- struct amdgpu_bo *bo =
On Tue, Jun 20, 2023 at 7:05 AM Dave Airlie wrote:
>
> Since this is feature is nouveau only currently and doesn't disturb
> the current nouveau code paths, I'd like to try and get this work in
> tree so other drivers can work from it.
>
> If there are any major objections to this, I'm happy to
On Tue, Jun 20, 2023 at 10:37:59AM +0300, Dan Carpenter wrote:
> "Mark the associated types properly packed individually, rather than
> use the disgusting "pragma pack()" that should never be used."
>
>
On Tue, Jun 20, 2023 at 08:24:34AM +0200, Helge Deller wrote:
> On 6/15/23 23:19, Cyril Brulebois wrote:
> > Hi Rob,
> >
> > Rob Herring (2023-06-15):
> > > On Thu, Jun 15, 2023 at 03:21:07PM +0200, Michal Suchánek wrote:
> > > > At the time this was proposed it was said that "of-display", is
The module loads firmware so add a MODULE_FIRMWARE macro to provide that
information via modinfo.
Signed-off-by: Juerg Haefliger
Reviewed-by: Robert Foss
---
v2:
- Introduce FW_FILE macro
- Add Rob's r-b
---
drivers/gpu/drm/bridge/lontium-lt9611uxc.c | 6 +-
1 file changed, 5
On Tue, Jun 20, 2023 at 10:13 AM Dave Airlie wrote:
>
> On Tue, 20 Jun 2023 at 17:06, Oded Gabbay wrote:
> >
> > On Tue, Jun 20, 2023 at 7:05 AM Dave Airlie wrote:
> > >
> > > Since this is feature is nouveau only currently and doesn't disturb
> > > the current nouveau code paths, I'd like to
Hi Danilo,
sorry for the delayed reply. I've trying to dig myself out of a hole at
the moment.
Am 20.06.23 um 02:42 schrieb Danilo Krummrich:
[SNIP]
diff --git a/include/drm/drm_gem.h b/include/drm/drm_gem.h
index bbc721870c13..5ec8148a30ee 100644
--- a/include/drm/drm_gem.h
+++
Am 20.06.23 um 08:47 schrieb Boris Brezillon:
On Mon, 19 Jun 2023 14:29:23 +0200
Boris Brezillon wrote:
On Mon, 19 Jun 2023 12:44:06 +0200
Christian König wrote:
Am 19.06.23 um 12:12 schrieb Boris Brezillon:
[SNIP]
Note that the drm_exec_until_all_locked() helper I introduced is taking
an
On 6/20/23 17:12, Christian König wrote:
Am 20.06.23 um 06:07 schrieb Tatsuyuki Ishi:
+Boris and +Matthew in case you want to take over this patch set.
Here are some review / testing comments, including those I posted before to
ease tracking.
On 5/4/23 20:51, Christian König wrote:
Use the
On 2023/6/20 15:37, Dan Carpenter wrote:
On Tue, Jun 20, 2023 at 12:59:19PM +0800, Su Hui wrote:
Smatch error:
gpu/drm/amd/amdgpu/amdgv_sriovmsg.h:316:49: error:
static assertion failed: "amd_sriov_msg_pf2vf_info must be 1 KB"
static assertion failed: "amd_sriov_msg_vf2pf_info
From: Rob Herring
Etnaviv doesn't use anything from of_platform.h, but depends on
of.h, of_device.h, and platform_device.h which are all implicitly
included, but that is going to be removed soon.
Signed-off-by: Rob Herring
Reviewed-by: Sui Jingfeng
Tested-by: Sui Jingfeng
---
On 2023-06-19 23:57:22, Dmitry Baryshkov wrote:
> On 16/06/2023 15:25, Marijn Suijten wrote:
> > On 2023-06-16 12:41:52, Dmitry Baryshkov wrote:
> >> Provide actual documentation for the pclk and hdisplay calculations in
> >> the case of DSC compression being used.
> >>
> >> Signed-off-by: Dmitry
Hi,
On 2023/6/20 19:06, Bjorn Helgaas wrote:
On Tue, Jun 20, 2023 at 12:04:40PM +0800, Sui Jingfeng wrote:
Where is the formal(unstream) PCI git branch where we could see the latest
patch ?
Here's the "misc" branch:
https://git.kernel.org/pub/scm/linux/kernel/git/pci/pci.git/log/?h=misc
And
This helper has been introduced to avoid programmer errors (missing
_put calls leading to dangling refcnt) when using pm_runtime_get, use it.
While at it, start checking the return value.
Signed-off-by: Konrad Dybcio
---
drivers/gpu/drm/msm/dsi/phy/dsi_phy.c | 4 +++-
1 file changed, 3
Some devices power the DSI PHY/PLL through a power rail that we model
as a GENPD. Enable runtime PM to make it suspendable.
Signed-off-by: Konrad Dybcio
---
drivers/gpu/drm/msm/dsi/phy/dsi_phy.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/gpu/drm/msm/dsi/phy/dsi_phy.c
:
https://lore.kernel.org/r/20230620-topic-dsiphy_rpm-v1-0-446a7fd0c...@linaro.org
---
Konrad Dybcio (2):
drm/msm/dsi: Use pm_runtime_resume_and_get to prevent refcnt leaks
drm/msm/dsi: Enable runtime PM
drivers/gpu/drm/msm/dsi/phy/dsi_phy.c | 8 +++-
1 file changed, 7 insertions
1 - 100 of 192 matches
Mail list logo
