Re: [syzbot] WARNING: locking bug in inet_autobind

2022-12-28 Thread syzbot
syzbot has found a reproducer for the following issue on:

HEAD commit:1b929c02afd3 Linux 6.2-rc1
git tree:   upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=145c6a6848
kernel config:  https://syzkaller.appspot.com/x/.config?x=2651619a26b4d687
dashboard link: https://syzkaller.appspot.com/bug?extid=94cc2a66fc228b23f360
compiler:   gcc (Debian 10.2.1-6) 10.2.1 20210110, GNU ld (GNU Binutils for 
Debian) 2.35.2
syz repro:  https://syzkaller.appspot.com/x/repro.syz?x=13e13e3248
C reproducer:   https://syzkaller.appspot.com/x/repro.c?x=13790f0848

Downloadable assets:
disk image: 
https://storage.googleapis.com/syzbot-assets/d1849f1ca322/disk-1b929c02.raw.xz
vmlinux: 
https://storage.googleapis.com/syzbot-assets/924cb8aa4ada/vmlinux-1b929c02.xz
kernel image: 
https://storage.googleapis.com/syzbot-assets/8c7330dae0a0/bzImage-1b929c02.xz

The issue was bisected to:

commit c0d9271ecbd891cdeb0fad1edcdd99ee717a655f
Author: Yong Zhao 
Date:   Fri Feb 1 23:36:21 2019 +

drm/amdgpu: Delete user queue doorbell variables

bisection log:  https://syzkaller.appspot.com/x/bisect.txt?x=1433ece4a0
final oops: https://syzkaller.appspot.com/x/report.txt?x=1633ece4a0
console output: https://syzkaller.appspot.com/x/log.txt?x=1233ece4a0

IMPORTANT: if you fix the issue, please add the following tag to the commit:
Reported-by: syzbot+94cc2a66fc228b23f...@syzkaller.appspotmail.com
Fixes: c0d9271ecbd8 ("drm/amdgpu: Delete user queue doorbell variables")

[ cut here ]
Looking for class "l2tp_sock" with key l2tp_socket_class, but found a different 
class "slock-AF_INET6" with the same key
WARNING: CPU: 0 PID: 7280 at kernel/locking/lockdep.c:937 
look_up_lock_class+0x97/0x110 kernel/locking/lockdep.c:937
Modules linked in:
CPU: 0 PID: 7280 Comm: syz-executor835 Not tainted 6.2.0-rc1-syzkaller #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 
10/26/2022
RIP: 0010:look_up_lock_class+0x97/0x110 kernel/locking/lockdep.c:937
Code: 17 48 81 fa e0 e5 f6 8f 74 59 80 3d 5d bc 57 04 00 75 50 48 c7 c7 00 4d 
4c 8a 48 89 04 24 c6 05 49 bc 57 04 01 e8 a9 42 b9 ff <0f> 0b 48 8b 04 24 eb 31 
9c 5a 80 e6 02 74 95 e8 45 38 02 fa 85 c0
RSP: 0018:c9000b5378b8 EFLAGS: 00010082
RAX:  RBX: 91c06a00 RCX: 
RDX: 8880292d RSI: 8166721c RDI: f520016a6f09
RBP:  R08: 0005 R09: 
R10: 8201 R11: 20676e696b6f6f4c R12: 
R13: 88802a5820b0 R14:  R15: 
FS:  7f1fd7a97700() GS:8880b980() knlGS:
CS:  0010 DS:  ES:  CR0: 80050033
CR2: 2100 CR3: 78ab4000 CR4: 003506f0
DR0:  DR1:  DR2: 
DR3:  DR6: fffe0ff0 DR7: 0400
Call Trace:
 
 register_lock_class+0xbe/0x1120 kernel/locking/lockdep.c:1289
 __lock_acquire+0x109/0x56d0 kernel/locking/lockdep.c:4934
 lock_acquire kernel/locking/lockdep.c:5668 [inline]
 lock_acquire+0x1e3/0x630 kernel/locking/lockdep.c:5633
 __raw_spin_lock_bh include/linux/spinlock_api_smp.h:126 [inline]
 _raw_spin_lock_bh+0x33/0x40 kernel/locking/spinlock.c:178
 spin_lock_bh include/linux/spinlock.h:355 [inline]
 lock_sock_nested+0x5f/0xf0 net/core/sock.c:3473
 lock_sock include/net/sock.h:1725 [inline]
 inet_autobind+0x1a/0x190 net/ipv4/af_inet.c:177
 inet_send_prepare net/ipv4/af_inet.c:813 [inline]
 inet_send_prepare+0x325/0x4e0 net/ipv4/af_inet.c:807
 inet6_sendmsg+0x43/0xe0 net/ipv6/af_inet6.c:655
 sock_sendmsg_nosec net/socket.c:714 [inline]
 sock_sendmsg+0xd3/0x120 net/socket.c:734
 __sys_sendto+0x23a/0x340 net/socket.c:2117
 __do_sys_sendto net/socket.c:2129 [inline]
 __se_sys_sendto net/socket.c:2125 [inline]
 __x64_sys_sendto+0xe1/0x1b0 net/socket.c:2125
 do_syscall_x64 arch/x86/entry/common.c:50 [inline]
 do_syscall_64+0x39/0xb0 arch/x86/entry/common.c:80
 entry_SYSCALL_64_after_hwframe+0x63/0xcd
RIP: 0033:0x7f1fd78538b9
Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 e1 15 00 00 90 48 89 f8 48 89 f7 48 
89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 
c3 48 c7 c1 b8 ff ff ff f7 d8 64 89 01 48
RSP: 002b:7f1fd7a971f8 EFLAGS: 0212 ORIG_RAX: 002c
RAX: ffda RBX: 7f1fd78f0038 RCX: 7f1fd78538b9
RDX:  RSI:  RDI: 0004
RBP: 7f1fd78f0030 R08: 2100 R09: 001c
R10: 04008000 R11: 0212 R12: 7f1fd78f003c
R13: 7f1fd79ffc8f R14: 7f1fd7a97300 R15: 00022000
 



[PATCH] drm: amd: display: fix dc/core/dc.c kernel-doc

2022-12-28 Thread Randy Dunlap
Fix all kernel-doc warnings in dc/core/dc.c:

dc.c:385: warning: missing initial short description on line:
 *  dc_stream_adjust_vmin_vmax:
dc.c:392: warning: contents before sections
dc.c:399: warning: No description found for return value of 
'dc_stream_adjust_vmin_vmax'
dc.c:434: warning: Excess function parameter 'adjust' description in 
'dc_stream_get_last_used_drr_vtotal'
dc.c:434: warning: No description found for return value of 
'dc_stream_get_last_used_drr_vtotal'
dc.c:574: warning: No description found for return value of 
'dc_stream_configure_crc'
dc.c:1746: warning: No description found for return value of 
'dc_commit_state_no_check'
dc.c:4991: warning: This comment starts with '/**', but isn't a kernel-doc 
comment. Refer Documentation/doc-guide/kernel-doc.rst
 * dc_extended_blank_supported 0 Decide whether extended blank is supported
dc.c:4991: warning: missing initial short description on line:
 * dc_extended_blank_supported 0 Decide whether extended blank is supported
dc.c:4723: warning: Function parameter or member 'dc' not described in 
'dc_enable_dmub_outbox'
dc.c:4926: warning: Function parameter or member 'dc' not described in 
'dc_process_dmub_dpia_hpd_int_enable'
dc.c:4926: warning: Function parameter or member 'hpd_int_enable' not described 
in 'dc_process_dmub_dpia_hpd_int_enable'
12 warnings

Signed-off-by: Randy Dunlap 
Reported-by: kernel test robot 
Cc: Rodrigo Siqueira 
Cc: Alex Deucher 
Cc: Hamza Mahfooz 
Cc: Harry Wentland 
Cc: Leo Li 
Cc: Christian König 
Cc: "Pan, Xinhui" 
Cc: amd-...@lists.freedesktop.org
---
Based on linux-next-20221226 but also applies to mainline.

 drivers/gpu/drm/amd/display/dc/core/dc.c |   40 +
 1 file changed, 25 insertions(+), 15 deletions(-)

diff -- a/drivers/gpu/drm/amd/display/dc/core/dc.c 
b/drivers/gpu/drm/amd/display/dc/core/dc.c
--- a/drivers/gpu/drm/amd/display/dc/core/dc.c
+++ b/drivers/gpu/drm/amd/display/dc/core/dc.c
@@ -382,16 +382,18 @@ static void dc_perf_trace_destroy(struct
 }
 
 /**
- *  dc_stream_adjust_vmin_vmax:
+ *  dc_stream_adjust_vmin_vmax - look up pipe context & update parts of DRR
+ *  @dc: dc reference
+ *  @stream: Initial dc stream state
+ *  @adjust: Updated parameters for vertical_total_min and vertical_total_max
  *
  *  Looks up the pipe context of dc_stream_state and updates the
  *  vertical_total_min and vertical_total_max of the DRR, Dynamic Refresh
  *  Rate, which is a power-saving feature that targets reducing panel
  *  refresh rate while the screen is static
  *
- *  @dc: dc reference
- *  @stream: Initial dc stream state
- *  @adjust: Updated parameters for vertical_total_min and vertical_total_max
+ *  Return: %true if the pipe context is found and adjusted;
+ *  %false if the pipe context is not found.
  */
 bool dc_stream_adjust_vmin_vmax(struct dc *dc,
struct dc_stream_state *stream,
@@ -419,14 +421,17 @@ bool dc_stream_adjust_vmin_vmax(struct d
 }
 
 /**
- * dc_stream_get_last_used_drr_vtotal - dc_stream_get_last_vrr_vtotal
+ * dc_stream_get_last_used_drr_vtotal - Looks up the pipe context of
+ * dc_stream_state and gets the last VTOTAL used by DRR (Dynamic Refresh Rate)
  *
  * @dc: [in] dc reference
  * @stream: [in] Initial dc stream state
- * @adjust: [in] Updated parameters for vertical_total_min and
+ * @refresh_rate: [in] new refresh_rate
  *
- * Looks up the pipe context of dc_stream_state and gets the last VTOTAL used
- * by DRR (Dynamic Refresh Rate)
+ * Return: %true if the pipe context is found and there is an associated
+ * timing_generator for the DC;
+ * %false if the pipe context is not found or there is no
+ * timing_generator for the DC.
  */
 bool dc_stream_get_last_used_drr_vtotal(struct dc *dc,
struct dc_stream_state *stream,
@@ -567,7 +572,10 @@ dc_stream_forward_crc_window(struct dc_s
  *  once.
  *
  * By default, only CRC0 is configured, and the entire frame is used to
- * calculate the crc.
+ * calculate the CRC.
+ *
+ * Return: %false if the stream is not found or CRC capture is not supported;
+ * %true if the stream has been configured.
  */
 bool dc_stream_configure_crc(struct dc *dc, struct dc_stream_state *stream,
 struct crc_params *crc_window, bool enable, bool 
continuous)
@@ -636,7 +644,7 @@ bool dc_stream_configure_crc(struct dc *
  * dc_stream_configure_crc needs to be called beforehand to enable CRCs.
  *
  * Return:
- * false if stream is not found, or if CRCs are not enabled.
+ * %false if stream is not found, or if CRCs are not enabled.
  */
 bool dc_stream_get_crc(struct dc *dc, struct dc_stream_state *stream,
   uint32_t *r_cr, uint32_t *g_y, uint32_t *b_cb)
@@ -1741,6 +1749,8 @@ void dc_z10_save_init(struct dc *dc)
  *
  * Applies given context to the hardware and copy it into current context.
  * It's up to the user to release the src context afterwards.
+ *
+ * Return: an enum dc_status result 

Re: [PATCH 2/3] arm64: dts: qcom: sm8150: Add DISPCC node

2022-12-28 Thread Marijn Suijten
On 2022-12-27 22:16:58, Bjorn Andersson wrote:
> On Mon, Dec 12, 2022 at 10:33:13AM +0100, Konrad Dybcio wrote:
> > [..]
> > +   power-domains = <&rpmhpd SM8150_MMCX>;
> > +   /* TODO: Maybe rpmhpd_opp_min_svs could work as well? */
> 
> The power-domain being not disabled should be sufficient for us to
> access the dispcc. Beyond that votes would be needed for particular
> frequencies, and that goes in the client nodes/opp-tables.
> 
> So you should be able to drop this comment and the required-opps.
> 
> Regards,
> Bjorn
> 
> > +   required-opps = <&rpmhpd_opp_low_svs>;

Tested the removal of this on Xperia 5, no regressions.

- Marijn


Re: [Intel-gfx] [RFC PATCH 04/20] drm/sched: Convert drm scheduler to use a work queue rather than kthread

2022-12-28 Thread Matthew Brost
On Fri, Dec 23, 2022 at 09:42:58AM -0800, Rob Clark wrote:
> On Thu, Dec 22, 2022 at 2:29 PM Matthew Brost  wrote:
> >
> > In XE, the new Intel GPU driver, a choice has made to have a 1 to 1
> > mapping between a drm_gpu_scheduler and drm_sched_entity. At first this
> > seems a bit odd but let us explain the reasoning below.
> >
> > 1. In XE the submission order from multiple drm_sched_entity is not
> > guaranteed to be the same completion even if targeting the same hardware
> > engine. This is because in XE we have a firmware scheduler, the GuC,
> > which allowed to reorder, timeslice, and preempt submissions. If a using
> > shared drm_gpu_scheduler across multiple drm_sched_entity, the TDR falls
> > apart as the TDR expects submission order == completion order. Using a
> > dedicated drm_gpu_scheduler per drm_sched_entity solve this problem.
> >
> > 2. In XE submissions are done via programming a ring buffer (circular
> > buffer), a drm_gpu_scheduler provides a limit on number of jobs, if the
> > limit of number jobs is set to RING_SIZE / MAX_SIZE_PER_JOB we get flow
> > control on the ring for free.
> >
> > A problem with this design is currently a drm_gpu_scheduler uses a
> > kthread for submission / job cleanup. This doesn't scale if a large
> > number of drm_gpu_scheduler are used. To work around the scaling issue,
> > use a worker rather than kthread for submission / job cleanup.
> 
> You might want to enable CONFIG_DRM_MSM in your kconfig, I think you
> missed a part
> 
> BR,
> -R
> 

Thanks for feedback Rob, yes indeed we missed updating the MSM driver. Fixed up
in our Xe repo and will be fixed in the next rev on the list.

Matt

> > Signed-off-by: Matthew Brost 
> > ---
> >  drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c |  14 +--
> >  drivers/gpu/drm/amd/amdgpu/amdgpu_device.c  |  12 +-
> >  drivers/gpu/drm/scheduler/sched_main.c  | 124 
> >  include/drm/gpu_scheduler.h |  13 +-
> >  4 files changed, 93 insertions(+), 70 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c 
> > b/drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c
> > index f60753f97ac5..9c2a10aeb0b3 100644
> > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c
> > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c
> > @@ -1489,9 +1489,9 @@ static int amdgpu_debugfs_test_ib_show(struct 
> > seq_file *m, void *unused)
> > for (i = 0; i < AMDGPU_MAX_RINGS; i++) {
> > struct amdgpu_ring *ring = adev->rings[i];
> >
> > -   if (!ring || !ring->sched.thread)
> > +   if (!ring || !ring->sched.ready)
> > continue;
> > -   kthread_park(ring->sched.thread);
> > +   drm_sched_run_wq_stop(&ring->sched);
> > }
> >
> > seq_printf(m, "run ib test:\n");
> > @@ -1505,9 +1505,9 @@ static int amdgpu_debugfs_test_ib_show(struct 
> > seq_file *m, void *unused)
> > for (i = 0; i < AMDGPU_MAX_RINGS; i++) {
> > struct amdgpu_ring *ring = adev->rings[i];
> >
> > -   if (!ring || !ring->sched.thread)
> > +   if (!ring || !ring->sched.ready)
> > continue;
> > -   kthread_unpark(ring->sched.thread);
> > +   drm_sched_run_wq_start(&ring->sched);
> > }
> >
> > up_write(&adev->reset_domain->sem);
> > @@ -1727,7 +1727,7 @@ static int amdgpu_debugfs_ib_preempt(void *data, u64 
> > val)
> >
> > ring = adev->rings[val];
> >
> > -   if (!ring || !ring->funcs->preempt_ib || !ring->sched.thread)
> > +   if (!ring || !ring->funcs->preempt_ib || !ring->sched.ready)
> > return -EINVAL;
> >
> > /* the last preemption failed */
> > @@ -1745,7 +1745,7 @@ static int amdgpu_debugfs_ib_preempt(void *data, u64 
> > val)
> > goto pro_end;
> >
> > /* stop the scheduler */
> > -   kthread_park(ring->sched.thread);
> > +   drm_sched_run_wq_stop(&ring->sched);
> >
> > /* preempt the IB */
> > r = amdgpu_ring_preempt_ib(ring);
> > @@ -1779,7 +1779,7 @@ static int amdgpu_debugfs_ib_preempt(void *data, u64 
> > val)
> >
> >  failure:
> > /* restart the scheduler */
> > -   kthread_unpark(ring->sched.thread);
> > +   drm_sched_run_wq_start(&ring->sched);
> >
> > up_read(&adev->reset_domain->sem);
> >
> > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c 
> > b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> > index 076ae400d099..9552929ccf87 100644
> > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> > @@ -4577,7 +4577,7 @@ bool amdgpu_device_has_job_running(struct 
> > amdgpu_device *adev)
> > for (i = 0; i < AMDGPU_MAX_RINGS; ++i) {
> > struct amdgpu_ring *ring = adev->rings[i];
> >
> > -   if (!ring || !ring->sched.thread)
> > +   if (!ring || !ring->sched.ready)
> > continu

Re: WARNING: CPU: 2 PID: 42 at drivers/gpu/drm/drm_modeset_lock.c:276

2022-12-28 Thread Stefan Wahren

Hi Maíra,

Am 28.12.22 um 20:49 schrieb Maíra Canal:

Hi Stefan,

I was able to reproduce this error on drm-misc-next. I bisected,
and I got into commit 6bed2ea3cb38. I noticed that the crtc->mutex is
being locked twice, and this might be causing the problem. I wrote a
patch to try to fix this issue, and after applying the patch, I wasn't
able to reproduce the error anymore.

Let me know if you were able to reproduce the warning after applying 
this patch.


the patch works as expected and avoid the warning. I tested it on top of 
v6.1 with RPi 3 B+ and RPi 4 B.


In case you send the patch please add the Fixes tag so the patch get 
backported to stable.


Thanks a lot

Stefan



Best Regards,
- Maíra Canal

---

From f6c910327d060e2314947e7e456db363a6164a49 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Ma=C3=ADra=20Canal?= 
Date: Wed, 28 Dec 2022 16:14:34 -0300
Subject: [PATCH] drm/vc4: don't lock crtc's mutex on reset link
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Current, crtc->mutex is being locked twice: first, by
vc4_hdmi_reset_link() and them, internally, by
drm_atomic_get_crtc_state(). This produces the following output when
PROVE_LOCKING is enabled:

[  825.612809] [ cut here ]
[  825.612852] WARNING: CPU: 1 PID: 116 at 
drivers/gpu/drm/drm_modeset_lock.c:276 
drm_modeset_drop_locks+0x60/0x68 [drm]

[  825.613458] Modules linked in: 8021q mrp garp stp llc
raspberrypi_cpufreq brcmfmac brcmutil crct10dif_ce hci_uart cfg80211
btqca btbcm bluetooth vc4 raspberrypi_hwmon snd_soc_hdmi_codec cec
clk_raspberrypi ecdh_generic drm_display_helper ecc rfkill
drm_dma_helper drm_kms_helper pwm_bcm2835 bcm2835_thermal bcm2835_rng
rng_core i2c_bcm2835 drm fuse ip_tables x_tables ipv6
[  825.613735] CPU: 1 PID: 116 Comm: kworker/1:2 Tainted: G W 
6.1.0-rc6-01399-g941aae326315 #3

[  825.613759] Hardware name: Raspberry Pi 3 Model B Rev 1.2 (DT)
[  825.613777] Workqueue: events output_poll_execute [drm_kms_helper]
[  825.614038] pstate: 6005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS 
BTYPE=--)

[  825.614063] pc : drm_modeset_drop_locks+0x60/0x68 [drm]
[  825.614603] lr : drm_helper_probe_detect+0x120/0x1b4 [drm_kms_helper]
[  825.614829] sp : 88313bf0
[  825.614844] x29: 88313bf0 x28: cd7778b8b000 x27: 

[  825.614883] x26: 0001 x25: 0001 x24: 
677cc35c2758
[  825.614920] x23: cd7707d01430 x22: cd7707c3edc7 x21: 
0001
[  825.614958] x20:  x19: 88313c10 x18: 
b6d3
[  825.614995] x17: cd777835e214 x16: cdcef870 x15: 
f810
[  825.615033] x14:  x13: 0099 x12: 
0002
[  825.615070] x11: 72917988020af800 x10: 72917988020af800 x9 : 
72917988020af800
[  825.615108] x8 : 677cc665e0a8 x7 : d00a8c18110c x6 : 
cd4c0054
[  825.615145] x5 :  x4 : 0001 x3 : 

[  825.615181] x2 : 677cc55e1880 x1 : cdcef8ec x0 : 
88313c10

[  825.615219] Call trace:
[  825.615232]  drm_modeset_drop_locks+0x60/0x68 [drm]
[  825.615773]  drm_helper_probe_detect+0x120/0x1b4 [drm_kms_helper]
[  825.616003]  output_poll_execute+0xe4/0x224 [drm_kms_helper]
[  825.616233]  process_one_work+0x2b4/0x618
[  825.616264]  worker_thread+0x24c/0x464
[  825.616288]  kthread+0xec/0x110
[  825.616310]  ret_from_fork+0x10/0x20
[  825.616335] irq event stamp: 7634
[  825.616349] hardirqs last  enabled at (7633): [] 
_raw_spin_unlock_irq+0x3c/0x78
[  825.616384] hardirqs last disabled at (7634): [] 
__schedule+0x134/0x9f0
[  825.616411] softirqs last  enabled at (7630): [] 
local_bh_enable+0x4/0x30 [ipv6]
[  825.617019] softirqs last disabled at (7618): [] 
local_bh_disable+0x4/0x30 [ipv6]

[  825.617586] ---[ end trace  ]---

So, don't lock crtc->mutex inside the driver and let the right lock be
automatically acquired by drm_atomic_get_crtc_state().

Reported-by: Stefan Wahren 
Signed-off-by: Maíra Canal 
---
 drivers/gpu/drm/vc4/vc4_hdmi.c | 4 
 1 file changed, 4 deletions(-)

diff --git a/drivers/gpu/drm/vc4/vc4_hdmi.c 
b/drivers/gpu/drm/vc4/vc4_hdmi.c

index 0d3313c71f2f..b3b1958b5f4d 100644
--- a/drivers/gpu/drm/vc4/vc4_hdmi.c
+++ b/drivers/gpu/drm/vc4/vc4_hdmi.c
@@ -340,10 +340,6 @@ static int vc4_hdmi_reset_link(struct 
drm_connector *connector,

 if (!crtc)
 return 0;

-    ret = drm_modeset_lock(&crtc->mutex, ctx);
-    if (ret)
-    return ret;
-
 crtc_state = crtc->state;
 if (!crtc_state->active)
 return 0;


Re: [PATCH v3 0/7] drm/bridge_connector: perform HPD enablement automatically

2022-12-28 Thread Dmitry Baryshkov

On 02/11/2022 20:06, Dmitry Baryshkov wrote:

 From all the drivers using drm_bridge_connector only iMX/dcss and OMAP
DRM driver do a proper work of calling
drm_bridge_connector_en/disable_hpd() in right places. Rather than
teaching each and every driver how to properly handle
drm_bridge_connector's HPD, make that automatic.

Add two additional drm_connector helper funcs: enable_hpd() and
disable_hpd(). Make drm_kms_helper_poll_* functions call them (as this
is the time where the drm_bridge_connector's functions are called by the
drivers too).


Since we are at the beginning of the development window, gracious ping 
for this patchset.


It would be nice to finally handle the bridge_connector's hpd properly. 
Calling drm_bridge_connector_enable_hpd() from 
drm_bridge_connector_init() is not a proper way to do this. It results 
in calling bridge->funcs->hpd_enable() before the rest of the pipeline 
was set up properly.




Changes since v2:
  - Fixed a typo in the commit message of the second patch.

Changes since v1:
  - Rebased on top of v6.1-rc1
  - Removed the drm_bridge_connector_enable_hpd() from
drm_bridge_connector_init()
  - Removed extra underscore prefix from
drm_bridge_connector_en/disable_hpd() helpers

Dmitry Baryshkov (7):
   drm/poll-helper: merge drm_kms_helper_poll_disable() and _fini()
   drm/probe-helper: enable and disable HPD on connectors
   drm/bridge_connector: rely on drm_kms_helper_poll_* for HPD enablement
   drm/imx/dcss: stop using drm_bridge_connector_en/disable_hpd()
   drm/msm/hdmi: stop using drm_bridge_connector_en/disable_hpd()
   drm/omap: stop using drm_bridge_connector_en/disable_hpd()
   drm/bridge_connector: drop drm_bridge_connector_en/disable_hpd()

  drivers/gpu/drm/drm_bridge_connector.c   | 27 +++-
  drivers/gpu/drm/drm_probe_helper.c   | 40 ++-
  drivers/gpu/drm/imx/dcss/dcss-dev.c  |  4 ---
  drivers/gpu/drm/imx/dcss/dcss-kms.c  |  2 --
  drivers/gpu/drm/msm/hdmi/hdmi.c  |  2 --
  drivers/gpu/drm/omapdrm/omap_drv.c   | 41 
  include/drm/drm_bridge_connector.h   |  2 --
  include/drm/drm_modeset_helper_vtables.h | 22 +
  8 files changed, 59 insertions(+), 81 deletions(-)



--
With best wishes
Dmitry



Re: WARNING: CPU: 2 PID: 42 at drivers/gpu/drm/drm_modeset_lock.c:276

2022-12-28 Thread Maíra Canal

Hi Stefan,

I was able to reproduce this error on drm-misc-next. I bisected,
and I got into commit 6bed2ea3cb38. I noticed that the crtc->mutex is
being locked twice, and this might be causing the problem. I wrote a
patch to try to fix this issue, and after applying the patch, I wasn't
able to reproduce the error anymore.

Let me know if you were able to reproduce the warning after applying this patch.

Best Regards,
- Maíra Canal

---

From f6c910327d060e2314947e7e456db363a6164a49 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Ma=C3=ADra=20Canal?= 
Date: Wed, 28 Dec 2022 16:14:34 -0300
Subject: [PATCH] drm/vc4: don't lock crtc's mutex on reset link
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Current, crtc->mutex is being locked twice: first, by
vc4_hdmi_reset_link() and them, internally, by
drm_atomic_get_crtc_state(). This produces the following output when
PROVE_LOCKING is enabled:

[  825.612809] [ cut here ]
[  825.612852] WARNING: CPU: 1 PID: 116 at 
drivers/gpu/drm/drm_modeset_lock.c:276 drm_modeset_drop_locks+0x60/0x68 [drm]
[  825.613458] Modules linked in: 8021q mrp garp stp llc
raspberrypi_cpufreq brcmfmac brcmutil crct10dif_ce hci_uart cfg80211
btqca btbcm bluetooth vc4 raspberrypi_hwmon snd_soc_hdmi_codec cec
clk_raspberrypi ecdh_generic drm_display_helper ecc rfkill
drm_dma_helper drm_kms_helper pwm_bcm2835 bcm2835_thermal bcm2835_rng
rng_core i2c_bcm2835 drm fuse ip_tables x_tables ipv6
[  825.613735] CPU: 1 PID: 116 Comm: kworker/1:2 Tainted: GW 
6.1.0-rc6-01399-g941aae326315 #3
[  825.613759] Hardware name: Raspberry Pi 3 Model B Rev 1.2 (DT)
[  825.613777] Workqueue: events output_poll_execute [drm_kms_helper]
[  825.614038] pstate: 6005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
[  825.614063] pc : drm_modeset_drop_locks+0x60/0x68 [drm]
[  825.614603] lr : drm_helper_probe_detect+0x120/0x1b4 [drm_kms_helper]
[  825.614829] sp : 88313bf0
[  825.614844] x29: 88313bf0 x28: cd7778b8b000 x27: 
[  825.614883] x26: 0001 x25: 0001 x24: 677cc35c2758
[  825.614920] x23: cd7707d01430 x22: cd7707c3edc7 x21: 0001
[  825.614958] x20:  x19: 88313c10 x18: b6d3
[  825.614995] x17: cd777835e214 x16: cdcef870 x15: f810
[  825.615033] x14:  x13: 0099 x12: 0002
[  825.615070] x11: 72917988020af800 x10: 72917988020af800 x9 : 72917988020af800
[  825.615108] x8 : 677cc665e0a8 x7 : d00a8c18110c x6 : cd4c0054
[  825.615145] x5 :  x4 : 0001 x3 : 
[  825.615181] x2 : 677cc55e1880 x1 : cdcef8ec x0 : 88313c10
[  825.615219] Call trace:
[  825.615232]  drm_modeset_drop_locks+0x60/0x68 [drm]
[  825.615773]  drm_helper_probe_detect+0x120/0x1b4 [drm_kms_helper]
[  825.616003]  output_poll_execute+0xe4/0x224 [drm_kms_helper]
[  825.616233]  process_one_work+0x2b4/0x618
[  825.616264]  worker_thread+0x24c/0x464
[  825.616288]  kthread+0xec/0x110
[  825.616310]  ret_from_fork+0x10/0x20
[  825.616335] irq event stamp: 7634
[  825.616349] hardirqs last  enabled at (7633): [] 
_raw_spin_unlock_irq+0x3c/0x78
[  825.616384] hardirqs last disabled at (7634): [] 
__schedule+0x134/0x9f0
[  825.616411] softirqs last  enabled at (7630): [] 
local_bh_enable+0x4/0x30 [ipv6]
[  825.617019] softirqs last disabled at (7618): [] 
local_bh_disable+0x4/0x30 [ipv6]
[  825.617586] ---[ end trace  ]---

So, don't lock crtc->mutex inside the driver and let the right lock be
automatically acquired by drm_atomic_get_crtc_state().

Reported-by: Stefan Wahren 
Signed-off-by: Maíra Canal 
---
 drivers/gpu/drm/vc4/vc4_hdmi.c | 4 
 1 file changed, 4 deletions(-)

diff --git a/drivers/gpu/drm/vc4/vc4_hdmi.c b/drivers/gpu/drm/vc4/vc4_hdmi.c
index 0d3313c71f2f..b3b1958b5f4d 100644
--- a/drivers/gpu/drm/vc4/vc4_hdmi.c
+++ b/drivers/gpu/drm/vc4/vc4_hdmi.c
@@ -340,10 +340,6 @@ static int vc4_hdmi_reset_link(struct drm_connector 
*connector,
if (!crtc)
return 0;
 
-	ret = drm_modeset_lock(&crtc->mutex, ctx);

-   if (ret)
-   return ret;
-
crtc_state = crtc->state;
if (!crtc_state->active)
return 0;
--
2.38.1

On 12/28/22 08:26, Stefan Wahren wrote:

Hi,

Am 21.12.22 um 20:46 schrieb Stefan Wahren:

Hi,

if i enable PROVE_LOCKING on the Raspberry Pi 3 B+ 
(arm/multi_v7_defconfig) using v6.1 (didn't test older versions) i'm 
getting the following warning:


[  204.043396] WARNING: CPU: 2 PID: 42 at 
drivers/gpu/drm/drm_modeset_lock.c:276 drm_modeset_drop_locks+0x6c/0x70
[  204.043426] Modules linked in: aes_arm aes_generic cmac 
bcm2835_v4l2(C) bcm2835_mmal_vchiq(C) videobuf2_vmalloc 
videobuf2_memops videobuf2_v4l2 videobuf2_common videodev mc 
snd_bcm2835(C) crc32_arm_ce brcmfmac brcmutil vc4 snd_soc_hdmi_codec 
sha256_generic l

Re: [PATCH v4 1/5] PM: domains: Allow a genpd consumer to require a synced power off

2022-12-28 Thread Bjorn Andersson
On Wed, Dec 21, 2022 at 10:43:59PM +0530, Akhil P Oommen wrote:
> From: Ulf Hansson 
> 
> Some genpd providers doesn't ensure that it has turned off at hardware.
> This is fine until the consumer really requires during some special
> scenarios that the power domain collapse at hardware before it is
> turned ON again.
> 
> An example is the reset sequence of Adreno GPU which requires that the
> 'gpucc cx gdsc' power domain should move to OFF state in hardware at
> least once before turning in ON again to clear the internal state.
> 
> Signed-off-by: Ulf Hansson 
> Signed-off-by: Akhil P Oommen 

Reviewed-by: Bjorn Andersson 

@Rafael, would you be willing to share an immutable branch with this
change? Or would you be okay with me doing so from the qcom clock tree?

Regards,
Bjorn

> ---
> 
> Changes in v4:
> - Update genpd function documentation (Ulf)
> 
> Changes in v2:
> - Minor formatting fix
> 
>  drivers/base/power/domain.c | 26 ++
>  include/linux/pm_domain.h   |  5 +
>  2 files changed, 31 insertions(+)
> 
> diff --git a/drivers/base/power/domain.c b/drivers/base/power/domain.c
> index 967bcf9d415e..84662d338188 100644
> --- a/drivers/base/power/domain.c
> +++ b/drivers/base/power/domain.c
> @@ -519,6 +519,31 @@ ktime_t dev_pm_genpd_get_next_hrtimer(struct device *dev)
>  }
>  EXPORT_SYMBOL_GPL(dev_pm_genpd_get_next_hrtimer);
>  
> +/*
> + * dev_pm_genpd_synced_poweroff - Next power off should be synchronous
> + *
> + * @dev: A device that is attached to the genpd.
> + *
> + * Allows a consumer of the genpd to notify the provider that the next power 
> off
> + * should be synchronous.
> + *
> + * It is assumed that the users guarantee that the genpd wouldn't be detached
> + * while this routine is getting called.
> + */
> +void dev_pm_genpd_synced_poweroff(struct device *dev)
> +{
> + struct generic_pm_domain *genpd;
> +
> + genpd = dev_to_genpd_safe(dev);
> + if (!genpd)
> + return;
> +
> + genpd_lock(genpd);
> + genpd->synced_poweroff = true;
> + genpd_unlock(genpd);
> +}
> +EXPORT_SYMBOL_GPL(dev_pm_genpd_synced_poweroff);
> +
>  static int _genpd_power_on(struct generic_pm_domain *genpd, bool timed)
>  {
>   unsigned int state_idx = genpd->state_idx;
> @@ -562,6 +587,7 @@ static int _genpd_power_on(struct generic_pm_domain 
> *genpd, bool timed)
>  
>  out:
>   raw_notifier_call_chain(&genpd->power_notifiers, GENPD_NOTIFY_ON, NULL);
> + genpd->synced_poweroff = false;
>   return 0;
>  err:
>   raw_notifier_call_chain(&genpd->power_notifiers, GENPD_NOTIFY_OFF,
> diff --git a/include/linux/pm_domain.h b/include/linux/pm_domain.h
> index 1cd41bdf73cf..f776fb93eaa0 100644
> --- a/include/linux/pm_domain.h
> +++ b/include/linux/pm_domain.h
> @@ -136,6 +136,7 @@ struct generic_pm_domain {
>   unsigned int prepared_count;/* Suspend counter of prepared devices 
> */
>   unsigned int performance_state; /* Aggregated max performance state */
>   cpumask_var_t cpus; /* A cpumask of the attached CPUs */
> + bool synced_poweroff;   /* A consumer needs a synced poweroff */
>   int (*power_off)(struct generic_pm_domain *domain);
>   int (*power_on)(struct generic_pm_domain *domain);
>   struct raw_notifier_head power_notifiers; /* Power on/off notifiers */
> @@ -235,6 +236,7 @@ int dev_pm_genpd_add_notifier(struct device *dev, struct 
> notifier_block *nb);
>  int dev_pm_genpd_remove_notifier(struct device *dev);
>  void dev_pm_genpd_set_next_wakeup(struct device *dev, ktime_t next);
>  ktime_t dev_pm_genpd_get_next_hrtimer(struct device *dev);
> +void dev_pm_genpd_synced_poweroff(struct device *dev);
>  
>  extern struct dev_power_governor simple_qos_governor;
>  extern struct dev_power_governor pm_domain_always_on_gov;
> @@ -300,6 +302,9 @@ static inline ktime_t 
> dev_pm_genpd_get_next_hrtimer(struct device *dev)
>  {
>   return KTIME_MAX;
>  }
> +static inline void dev_pm_genpd_synced_poweroff(struct device *dev)
> +{ }
> +
>  #define simple_qos_governor  (*(struct dev_power_governor *)(NULL))
>  #define pm_domain_always_on_gov  (*(struct dev_power_governor 
> *)(NULL))
>  #endif
> -- 
> 2.7.4
> 


Re: [PATCH v4 0/5] arm64: dts: qcom: sm8450-hdk: enable HDMI output

2022-12-28 Thread Bjorn Andersson
On Wed, 7 Dec 2022 03:27:58 +0200, Dmitry Baryshkov wrote:
> Add device tree nodes for MDSS, DPU and DSI devices on Qualcomm SM8450
> platform. Enable these devices and add the HDMI bridge configuration on
> SM8450 HDK.
> 
> Changes since v3:
> - Renamed mdss node to display-subsystem@ (Krzysztof)
> - Dropped empty line from the patch4 (Krzysztof)
> - Renamed HDMI connector endpoint to hdmi_connector_out
> 
> [...]

Applied, thanks!

[1/5] arm64: dts: qcom: sm8450: add RPMH_REGULATOR_LEVEL_LOW_SVS_D1
  commit: a5ac24ba17590866cf1ff8fe44cd2738c003d52f
[2/5] arm64: dts: qcom: sm8450: add display hardware devices
  commit: a6dd1206e45a43d7e6c46435437307b051471b69
[3/5] arm64: dts: qcom: sm8450-hdk: enable display hardware
  commit: 928a7b4269634369b152342a37b2809d18774726
[4/5] arm64: dts: qcom: sm8450-hdk: Add LT9611uxc HDMI bridge
  commit: 0cbe8e1953e083f8435bdb5548c3ba59acfcb97e
[5/5] arm64: dts: qcom: sm8450-hdk: Enable HDMI Display
  commit: 0f48b65f716b4fa806fa864ea7f750113f4bd7c9

Best regards,
-- 
Bjorn Andersson 


Re: [PATCH 12/13] drm/scheduler: rework entity flush, kill and fini

2022-12-28 Thread Rob Clark
On Wed, Dec 28, 2022 at 8:27 AM Rob Clark  wrote:
>
> On Thu, Nov 17, 2022 at 7:12 AM Dmitry Osipenko
>  wrote:
> >
> > On 11/17/22 18:09, Christian König wrote:
> > > Am 17.11.22 um 15:41 schrieb Dmitry Osipenko:
> > >> [SNIP]
> > >>> drm_sched_entity_flush() should be called from the flush callback from
> > >>> the file_operations structure of panfrost. See amdgpu_flush() and
> > >>> amdgpu_ctx_mgr_entity_flush(). This makes sure that we wait for all
> > >>> entities of the process/file descriptor to be flushed out.
> > >>>
> > >>> drm_sched_entity_fini() must be called before you free the memory the
> > >>> entity structure or otherwise we would run into an use after free.
> > >> Right, drm_sched_entity_destroy() invokes these two functions and
> > >> Panfrost uses drm_sched_entity_destroy().
> > >
> > > Than I have no idea what's going wrong here.
> > >
> > > The scheduler should trivially finish with the entity and call
> > > complete(&entity->entity_idle) in it's main loop. No idea why this
> > > doesn't happen. Can you investigate?
> >
> > I'll take a closer look. Hoped you may have a quick idea of what's wrong :)
> >
>
> As Jonathan mentioned, the same thing is happening on msm.  I can
> reproduce this by adding an assert in mesa (in this case, triggered
> after 100 draws) and running an app under gdb.  After the assert is
> hit, if I try to exit mesa, it hangs.
>
> The problem is that we somehow call drm_sched_entity_kill() twice.
> The first time completes, but now the entity_idle completion is no
> longer done, so the second call hangs forever.

Maybe we should:

--
diff --git a/drivers/gpu/drm/scheduler/sched_entity.c
b/drivers/gpu/drm/scheduler/sched_entity.c
index fe09e5be79bd..3d7c671d05e3 100644
--- a/drivers/gpu/drm/scheduler/sched_entity.c
+++ b/drivers/gpu/drm/scheduler/sched_entity.c
@@ -222,7 +226,6 @@ static void drm_sched_entity_kill(struct
drm_sched_entity *entity)
 long drm_sched_entity_flush(struct drm_sched_entity *entity, long timeout)
 {
struct drm_gpu_scheduler *sched;
-   struct task_struct *last_user;
long ret = timeout;

if (!entity->rq)
@@ -244,12 +247,6 @@ long drm_sched_entity_flush(struct
drm_sched_entity *entity, long timeout)
drm_sched_entity_is_idle(entity));
}

-   /* For killed process disable any more IBs enqueue right now */
-   last_user = cmpxchg(&entity->last_user, current->group_leader, NULL);
-   if ((!last_user || last_user == current->group_leader) &&
-   (current->flags & PF_EXITING) && (current->exit_code == SIGKILL))
-   drm_sched_entity_kill(entity);
-
return ret;
 }
 EXPORT_SYMBOL(drm_sched_entity_flush);


Maybe there is a better fix, but special handling for SIGKILL seems
dubious to me (vs just relying on the drm device fd close path).  I
wonder if that code path was tested at all?

BR,
-R


[PATCH v2 10/11] drm/amd: Request GFX11 microcode during IP discovery

2022-12-28 Thread Mario Limonciello
If GFX11 microcode is required but not available during early init, the
microcode framebuffer will have already been released and the screen will
freeze.

Move the request for GFX11 microcode into the IP discovery phase
so that if it's not available, IP discovery will fail.

Signed-off-by: Mario Limonciello 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_discovery.c | 52 +++
 drivers/gpu/drm/amd/amdgpu/gfx_v11_0.c| 64 +--
 2 files changed, 53 insertions(+), 63 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_discovery.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_discovery.c
index d31559600cae..c8c538a768fe 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_discovery.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_discovery.c
@@ -316,6 +316,29 @@ MODULE_FIRMWARE("amdgpu/gc_10_3_7_mec.bin");
 MODULE_FIRMWARE("amdgpu/gc_10_3_7_mec2.bin");
 MODULE_FIRMWARE("amdgpu/gc_10_3_7_rlc.bin");
 
+/* gfx11 */
+MODULE_FIRMWARE("amdgpu/gc_11_0_0_pfp.bin");
+MODULE_FIRMWARE("amdgpu/gc_11_0_0_me.bin");
+MODULE_FIRMWARE("amdgpu/gc_11_0_0_mec.bin");
+MODULE_FIRMWARE("amdgpu/gc_11_0_0_rlc.bin");
+MODULE_FIRMWARE("amdgpu/gc_11_0_0_toc.bin");
+MODULE_FIRMWARE("amdgpu/gc_11_0_1_pfp.bin");
+MODULE_FIRMWARE("amdgpu/gc_11_0_1_me.bin");
+MODULE_FIRMWARE("amdgpu/gc_11_0_1_mec.bin");
+MODULE_FIRMWARE("amdgpu/gc_11_0_1_rlc.bin");
+MODULE_FIRMWARE("amdgpu/gc_11_0_2_pfp.bin");
+MODULE_FIRMWARE("amdgpu/gc_11_0_2_me.bin");
+MODULE_FIRMWARE("amdgpu/gc_11_0_2_mec.bin");
+MODULE_FIRMWARE("amdgpu/gc_11_0_2_rlc.bin");
+MODULE_FIRMWARE("amdgpu/gc_11_0_3_pfp.bin");
+MODULE_FIRMWARE("amdgpu/gc_11_0_3_me.bin");
+MODULE_FIRMWARE("amdgpu/gc_11_0_3_mec.bin");
+MODULE_FIRMWARE("amdgpu/gc_11_0_3_rlc.bin");
+MODULE_FIRMWARE("amdgpu/gc_11_0_4_pfp.bin");
+MODULE_FIRMWARE("amdgpu/gc_11_0_4_me.bin");
+MODULE_FIRMWARE("amdgpu/gc_11_0_4_mec.bin");
+MODULE_FIRMWARE("amdgpu/gc_11_0_4_rlc.bin");
+
 static const char *hw_id_names[HW_ID_MAX] = {
[MP1_HWID]  = "MP1",
[MP2_HWID]  = "MP2",
@@ -2111,6 +2134,32 @@ static int amdgpu_discovery_load_gfx10(struct 
amdgpu_device *adev, char *ucode_p
r = request_firmware(&adev->gfx.mec2_fw, fw_name, adev->dev);
if (r)
return r;
+   return 0;
+}
+
+static int amdgpu_discovery_load_gfx11(struct amdgpu_device *adev, char 
*ucode_prefix)
+{
+   char fw_name[40];
+   int r;
+
+   snprintf(fw_name, sizeof(fw_name), "amdgpu/%s_pfp.bin", ucode_prefix);
+   r = request_firmware(&adev->gfx.pfp_fw, fw_name, adev->dev);
+   if (r)
+   return r;
+   snprintf(fw_name, sizeof(fw_name), "amdgpu/%s_me.bin", ucode_prefix);
+   r = request_firmware(&adev->gfx.me_fw, fw_name, adev->dev);
+   if (r)
+   return r;
+   snprintf(fw_name, sizeof(fw_name), "amdgpu/%s_mec.bin", ucode_prefix);
+   r = request_firmware(&adev->gfx.mec_fw, fw_name, adev->dev);
+   if (r)
+   return r;
+   if (adev->firmware.load_type == AMDGPU_FW_LOAD_RLC_BACKDOOR_AUTO) {
+   snprintf(fw_name, sizeof(fw_name), "amdgpu/%s_toc.bin", 
ucode_prefix);
+   r = request_firmware(&adev->psp.toc_fw, fw_name, adev->dev);
+   if (r)
+   return r;
+   }
 
return 0;
 }
@@ -2159,6 +2208,9 @@ static int amdgpu_discovery_set_gc_ip_blocks(struct 
amdgpu_device *adev)
case IP_VERSION(11, 0, 2):
case IP_VERSION(11, 0, 3):
case IP_VERSION(11, 0, 4):
+   r = amdgpu_discovery_load_gfx11(adev, ucode_prefix);
+   if (r)
+   return r;
amdgpu_device_ip_block_add(adev, &gfx_v11_0_ip_block);
break;
default:
diff --git a/drivers/gpu/drm/amd/amdgpu/gfx_v11_0.c 
b/drivers/gpu/drm/amd/amdgpu/gfx_v11_0.c
index a56c6e106d00..576fa591c6da 100644
--- a/drivers/gpu/drm/amd/amdgpu/gfx_v11_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/gfx_v11_0.c
@@ -60,27 +60,6 @@
 #define regRLC_RLCS_BOOTLOAD_STATUS_gc_11_0_1  0x4e7e
 #define regRLC_RLCS_BOOTLOAD_STATUS_gc_11_0_1_BASE_IDX 1
 
-MODULE_FIRMWARE("amdgpu/gc_11_0_0_pfp.bin");
-MODULE_FIRMWARE("amdgpu/gc_11_0_0_me.bin");
-MODULE_FIRMWARE("amdgpu/gc_11_0_0_mec.bin");
-MODULE_FIRMWARE("amdgpu/gc_11_0_0_rlc.bin");
-MODULE_FIRMWARE("amdgpu/gc_11_0_0_toc.bin");
-MODULE_FIRMWARE("amdgpu/gc_11_0_1_pfp.bin");
-MODULE_FIRMWARE("amdgpu/gc_11_0_1_me.bin");
-MODULE_FIRMWARE("amdgpu/gc_11_0_1_mec.bin");
-MODULE_FIRMWARE("amdgpu/gc_11_0_1_rlc.bin");
-MODULE_FIRMWARE("amdgpu/gc_11_0_2_pfp.bin");
-MODULE_FIRMWARE("amdgpu/gc_11_0_2_me.bin");
-MODULE_FIRMWARE("amdgpu/gc_11_0_2_mec.bin");
-MODULE_FIRMWARE("amdgpu/gc_11_0_2_rlc.bin");
-MODULE_FIRMWARE("amdgpu/gc_11_0_3_pfp.bin");
-MODULE_FIRMWARE("amdgpu/gc_11_0_3_me.bin");
-MODULE_FIRMWARE("amdgpu/gc_11_0_3_mec.bin");
-MODULE_FIRMWARE("amdgpu/gc_11_0_3_rlc.bin");
-MODULE_FIRMWARE("amdgpu/gc_11_0_4_pfp.bin");
-MODULE_FIRMWARE("amdgpu/gc_11_0_4_me.bin");
-MODULE_FIRMWARE("amdgpu/gc_11_0_4_mec.

[PATCH v2 09/11] drm/amd: Request GFX10 microcode during IP discovery

2022-12-28 Thread Mario Limonciello
If GFX10 microcode is required but not available during early init, the
microcode framebuffer will have already been released and the screen will
freeze.

Move the request for GFX10 microcode into the IP discovery phase
so that if it's not available, IP discovery will fail.

Signed-off-by: Mario Limonciello 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_discovery.c | 137 +
 drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c| 180 +-
 2 files changed, 144 insertions(+), 173 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_discovery.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_discovery.c
index 0da16abd6b24..d31559600cae 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_discovery.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_discovery.c
@@ -220,6 +220,102 @@ MODULE_FIRMWARE("amdgpu/green_sardine_mec.bin");
 MODULE_FIRMWARE("amdgpu/green_sardine_mec2.bin");
 MODULE_FIRMWARE("amdgpu/green_sardine_rlc.bin");
 
+/* gfx10 */
+MODULE_FIRMWARE("amdgpu/aldebaran_mec.bin");
+MODULE_FIRMWARE("amdgpu/aldebaran_mec2.bin");
+MODULE_FIRMWARE("amdgpu/aldebaran_rlc.bin");
+MODULE_FIRMWARE("amdgpu/aldebaran_sjt_mec.bin");
+MODULE_FIRMWARE("amdgpu/aldebaran_sjt_mec2.bin");
+
+MODULE_FIRMWARE("amdgpu/navi10_ce.bin");
+MODULE_FIRMWARE("amdgpu/navi10_pfp.bin");
+MODULE_FIRMWARE("amdgpu/navi10_me.bin");
+MODULE_FIRMWARE("amdgpu/navi10_mec.bin");
+MODULE_FIRMWARE("amdgpu/navi10_mec2.bin");
+MODULE_FIRMWARE("amdgpu/navi10_rlc.bin");
+
+MODULE_FIRMWARE("amdgpu/navi14_ce_wks.bin");
+MODULE_FIRMWARE("amdgpu/navi14_pfp_wks.bin");
+MODULE_FIRMWARE("amdgpu/navi14_me_wks.bin");
+MODULE_FIRMWARE("amdgpu/navi14_mec_wks.bin");
+MODULE_FIRMWARE("amdgpu/navi14_mec2_wks.bin");
+MODULE_FIRMWARE("amdgpu/navi14_ce.bin");
+MODULE_FIRMWARE("amdgpu/navi14_pfp.bin");
+MODULE_FIRMWARE("amdgpu/navi14_me.bin");
+MODULE_FIRMWARE("amdgpu/navi14_mec.bin");
+MODULE_FIRMWARE("amdgpu/navi14_mec2.bin");
+MODULE_FIRMWARE("amdgpu/navi14_rlc.bin");
+
+MODULE_FIRMWARE("amdgpu/navi12_ce.bin");
+MODULE_FIRMWARE("amdgpu/navi12_pfp.bin");
+MODULE_FIRMWARE("amdgpu/navi12_me.bin");
+MODULE_FIRMWARE("amdgpu/navi12_mec.bin");
+MODULE_FIRMWARE("amdgpu/navi12_mec2.bin");
+MODULE_FIRMWARE("amdgpu/navi12_rlc.bin");
+
+MODULE_FIRMWARE("amdgpu/sienna_cichlid_ce.bin");
+MODULE_FIRMWARE("amdgpu/sienna_cichlid_pfp.bin");
+MODULE_FIRMWARE("amdgpu/sienna_cichlid_me.bin");
+MODULE_FIRMWARE("amdgpu/sienna_cichlid_mec.bin");
+MODULE_FIRMWARE("amdgpu/sienna_cichlid_mec2.bin");
+MODULE_FIRMWARE("amdgpu/sienna_cichlid_rlc.bin");
+
+MODULE_FIRMWARE("amdgpu/navy_flounder_ce.bin");
+MODULE_FIRMWARE("amdgpu/navy_flounder_pfp.bin");
+MODULE_FIRMWARE("amdgpu/navy_flounder_me.bin");
+MODULE_FIRMWARE("amdgpu/navy_flounder_mec.bin");
+MODULE_FIRMWARE("amdgpu/navy_flounder_mec2.bin");
+MODULE_FIRMWARE("amdgpu/navy_flounder_rlc.bin");
+
+MODULE_FIRMWARE("amdgpu/vangogh_ce.bin");
+MODULE_FIRMWARE("amdgpu/vangogh_pfp.bin");
+MODULE_FIRMWARE("amdgpu/vangogh_me.bin");
+MODULE_FIRMWARE("amdgpu/vangogh_mec.bin");
+MODULE_FIRMWARE("amdgpu/vangogh_mec2.bin");
+MODULE_FIRMWARE("amdgpu/vangogh_rlc.bin");
+
+MODULE_FIRMWARE("amdgpu/dimgrey_cavefish_ce.bin");
+MODULE_FIRMWARE("amdgpu/dimgrey_cavefish_pfp.bin");
+MODULE_FIRMWARE("amdgpu/dimgrey_cavefish_me.bin");
+MODULE_FIRMWARE("amdgpu/dimgrey_cavefish_mec.bin");
+MODULE_FIRMWARE("amdgpu/dimgrey_cavefish_mec2.bin");
+MODULE_FIRMWARE("amdgpu/dimgrey_cavefish_rlc.bin");
+
+MODULE_FIRMWARE("amdgpu/beige_goby_ce.bin");
+MODULE_FIRMWARE("amdgpu/beige_goby_pfp.bin");
+MODULE_FIRMWARE("amdgpu/beige_goby_me.bin");
+MODULE_FIRMWARE("amdgpu/beige_goby_mec.bin");
+MODULE_FIRMWARE("amdgpu/beige_goby_mec2.bin");
+MODULE_FIRMWARE("amdgpu/beige_goby_rlc.bin");
+
+MODULE_FIRMWARE("amdgpu/yellow_carp_ce.bin");
+MODULE_FIRMWARE("amdgpu/yellow_carp_pfp.bin");
+MODULE_FIRMWARE("amdgpu/yellow_carp_me.bin");
+MODULE_FIRMWARE("amdgpu/yellow_carp_mec.bin");
+MODULE_FIRMWARE("amdgpu/yellow_carp_mec2.bin");
+MODULE_FIRMWARE("amdgpu/yellow_carp_rlc.bin");
+
+MODULE_FIRMWARE("amdgpu/cyan_skillfish2_ce.bin");
+MODULE_FIRMWARE("amdgpu/cyan_skillfish2_pfp.bin");
+MODULE_FIRMWARE("amdgpu/cyan_skillfish2_me.bin");
+MODULE_FIRMWARE("amdgpu/cyan_skillfish2_mec.bin");
+MODULE_FIRMWARE("amdgpu/cyan_skillfish2_mec2.bin");
+MODULE_FIRMWARE("amdgpu/cyan_skillfish2_rlc.bin");
+
+MODULE_FIRMWARE("amdgpu/gc_10_3_6_ce.bin");
+MODULE_FIRMWARE("amdgpu/gc_10_3_6_pfp.bin");
+MODULE_FIRMWARE("amdgpu/gc_10_3_6_me.bin");
+MODULE_FIRMWARE("amdgpu/gc_10_3_6_mec.bin");
+MODULE_FIRMWARE("amdgpu/gc_10_3_6_mec2.bin");
+MODULE_FIRMWARE("amdgpu/gc_10_3_6_rlc.bin");
+
+MODULE_FIRMWARE("amdgpu/gc_10_3_7_ce.bin");
+MODULE_FIRMWARE("amdgpu/gc_10_3_7_pfp.bin");
+MODULE_FIRMWARE("amdgpu/gc_10_3_7_me.bin");
+MODULE_FIRMWARE("amdgpu/gc_10_3_7_mec.bin");
+MODULE_FIRMWARE("amdgpu/gc_10_3_7_mec2.bin");
+MODULE_FIRMWARE("amdgpu/gc_10_3_7_rlc.bin");
+
 static const char *hw_id_names[HW_ID_MAX] = {
[MP1_HWID]  = "MP1",
[MP2_HWID]  = "MP2",
@@ -1981,6 +2077,44 @@ static int amdgp

[PATCH v2 06/11] drm/amd: Request VCN microcode during IP discovery

2022-12-28 Thread Mario Limonciello
If VCN microcode is not available during early init, the microcode
framebuffer will have already been released and the screen will
freeze.

Move the request for VCN microcode into the IP discovery phase
so that if it's not available, IP discovery will fail.

Signed-off-by: Mario Limonciello 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_discovery.c | 41 -
 drivers/gpu/drm/amd/amdgpu/amdgpu_vcn.c   | 85 +--
 2 files changed, 41 insertions(+), 85 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_discovery.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_discovery.c
index f51ff86293b3..1c26a3a60394 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_discovery.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_discovery.c
@@ -124,6 +124,27 @@ MODULE_FIRMWARE("amdgpu/sdma_6_0_1.bin");
 MODULE_FIRMWARE("amdgpu/sdma_6_0_2.bin");
 MODULE_FIRMWARE("amdgpu/sdma_6_0_3.bin");
 
+MODULE_FIRMWARE("amdgpu/raven_vcn.bin");
+MODULE_FIRMWARE("amdgpu/picasso_vcn.bin");
+MODULE_FIRMWARE("amdgpu/raven2_vcn.bin");
+MODULE_FIRMWARE("amdgpu/arcturus_vcn.bin");
+MODULE_FIRMWARE("amdgpu/renoir_vcn.bin");
+MODULE_FIRMWARE("amdgpu/green_sardine_vcn.bin");
+MODULE_FIRMWARE("amdgpu/aldebaran_vcn.bin");
+MODULE_FIRMWARE("amdgpu/navi10_vcn.bin");
+MODULE_FIRMWARE("amdgpu/navi14_vcn.bin");
+MODULE_FIRMWARE("amdgpu/navi12_vcn.bin");
+MODULE_FIRMWARE("amdgpu/sienna_cichlid_vcn.bin");
+MODULE_FIRMWARE("amdgpu/navy_flounder_vcn.bin");
+MODULE_FIRMWARE("amdgpu/vangogh_vcn.bin");
+MODULE_FIRMWARE("amdgpu/dimgrey_cavefish_vcn.bin");
+MODULE_FIRMWARE("amdgpu/beige_goby_vcn.bin");
+MODULE_FIRMWARE("amdgpu/yellow_carp_vcn.bin");
+MODULE_FIRMWARE("amdgpu/vcn_3_1_2.bin");
+MODULE_FIRMWARE("amdgpu/vcn_4_0_0.bin");
+MODULE_FIRMWARE("amdgpu/vcn_4_0_2.bin");
+MODULE_FIRMWARE("amdgpu/vcn_4_0_4.bin");
+
 static const char *hw_id_names[HW_ID_MAX] = {
[MP1_HWID]  = "MP1",
[MP2_HWID]  = "MP2",
@@ -1922,8 +1943,23 @@ static int amdgpu_discovery_set_sdma_ip_blocks(struct 
amdgpu_device *adev)
return 0;
 }
 
+static int amdgpu_discovery_load_vcn_fw(struct amdgpu_device *adev,
+   char *fname)
+{
+   char fw_name[40];
+
+   snprintf(fw_name, sizeof(fw_name), "amdgpu/%s.bin", fname);
+
+   return request_firmware(&adev->vcn.fw, fw_name, adev->dev);
+}
+
 static int amdgpu_discovery_set_mm_ip_blocks(struct amdgpu_device *adev)
 {
+   char ucode_prefix[30];
+   int r = 0;
+
+   amdgpu_ucode_ip_version_decode(adev, UVD_HWIP, ucode_prefix, 
sizeof(ucode_prefix));
+
if (adev->ip_versions[VCE_HWIP][0]) {
switch (adev->ip_versions[UVD_HWIP][0]) {
case IP_VERSION(7, 0, 0):
@@ -2001,7 +2037,10 @@ static int amdgpu_discovery_set_mm_ip_blocks(struct 
amdgpu_device *adev)
return -EINVAL;
}
}
-   return 0;
+   if (*ucode_prefix)
+   r = amdgpu_discovery_load_vcn_fw(adev, ucode_prefix);
+   return r;
+}
 }
 
 static int amdgpu_discovery_set_mes_ip_blocks(struct amdgpu_device *adev)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vcn.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_vcn.c
index a23e26b272b4..370c9644a3b3 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vcn.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vcn.c
@@ -35,55 +35,11 @@
 #include "amdgpu_vcn.h"
 #include "soc15d.h"
 
-/* Firmware Names */
-#define FIRMWARE_RAVEN "amdgpu/raven_vcn.bin"
-#define FIRMWARE_PICASSO   "amdgpu/picasso_vcn.bin"
-#define FIRMWARE_RAVEN2"amdgpu/raven2_vcn.bin"
-#define FIRMWARE_ARCTURUS  "amdgpu/arcturus_vcn.bin"
-#define FIRMWARE_RENOIR"amdgpu/renoir_vcn.bin"
-#define FIRMWARE_GREEN_SARDINE "amdgpu/green_sardine_vcn.bin"
-#define FIRMWARE_NAVI10"amdgpu/navi10_vcn.bin"
-#define FIRMWARE_NAVI14"amdgpu/navi14_vcn.bin"
-#define FIRMWARE_NAVI12"amdgpu/navi12_vcn.bin"
-#define FIRMWARE_SIENNA_CICHLID"amdgpu/sienna_cichlid_vcn.bin"
-#define FIRMWARE_NAVY_FLOUNDER "amdgpu/navy_flounder_vcn.bin"
-#define FIRMWARE_VANGOGH   "amdgpu/vangogh_vcn.bin"
-#define FIRMWARE_DIMGREY_CAVEFISH  "amdgpu/dimgrey_cavefish_vcn.bin"
-#define FIRMWARE_ALDEBARAN "amdgpu/aldebaran_vcn.bin"
-#define FIRMWARE_BEIGE_GOBY"amdgpu/beige_goby_vcn.bin"
-#define FIRMWARE_YELLOW_CARP   "amdgpu/yellow_carp_vcn.bin"
-#define FIRMWARE_VCN_3_1_2 "amdgpu/vcn_3_1_2.bin"
-#define FIRMWARE_VCN4_0_0  "amdgpu/vcn_4_0_0.bin"
-#define FIRMWARE_VCN4_0_2  "amdgpu/vcn_4_0_2.bin"
-#define FIRMWARE_VCN4_0_4  "amdgpu/vcn_4_0_4.bin"
-
-MODULE_FIRMWARE(FIRMWARE_RAVEN);
-MODULE_FIRMWARE(FIRMWARE_PICASSO);
-MODULE_FIRMWARE(FIRMWARE_RAVEN2);
-MODULE_FIRMWARE(FIRMWARE_ARCTURUS);
-MODULE_FIRMWARE(FIRMWARE_RENOIR);
-MODULE_FIRMWARE(FIRMWARE_GREEN_SARDINE);
-MODULE_FIRMWARE(FIRMWARE_ALDEBARAN);
-MODULE_FIRMWARE(FIRMWARE_NAVI10);
-MODULE_FIRMWARE(FIRMWARE_NAVI14);
-MODULE_FIRMWARE(FIRMWARE_NAVI12);
-MODULE_

[PATCH v2 08/11] drm/amd: Request GFX9 microcode during IP discovery

2022-12-28 Thread Mario Limonciello
If GFX9 microcode is required but not available during early init, the
microcode framebuffer will have already been released and the screen will
freeze.

Move the request for GFX9 microcode into the IP discovery phase
so that if it's not available, IP discovery will fail.

Signed-off-by: Mario Limonciello 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_discovery.c | 144 ++
 drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c | 143 +
 2 files changed, 152 insertions(+), 135 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_discovery.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_discovery.c
index 479266ed2b7f..0da16abd6b24 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_discovery.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_discovery.c
@@ -158,6 +158,68 @@ MODULE_FIRMWARE("amdgpu/gc_11_0_2_mes1.bin");
 MODULE_FIRMWARE("amdgpu/gc_11_0_3_mes.bin");
 MODULE_FIRMWARE("amdgpu/gc_11_0_3_mes1.bin");
 
+
+/* gfx9 */
+MODULE_FIRMWARE("amdgpu/vega10_ce.bin");
+MODULE_FIRMWARE("amdgpu/vega10_pfp.bin");
+MODULE_FIRMWARE("amdgpu/vega10_me.bin");
+MODULE_FIRMWARE("amdgpu/vega10_mec.bin");
+MODULE_FIRMWARE("amdgpu/vega10_mec2.bin");
+MODULE_FIRMWARE("amdgpu/vega10_rlc.bin");
+
+MODULE_FIRMWARE("amdgpu/vega12_ce.bin");
+MODULE_FIRMWARE("amdgpu/vega12_pfp.bin");
+MODULE_FIRMWARE("amdgpu/vega12_me.bin");
+MODULE_FIRMWARE("amdgpu/vega12_mec.bin");
+MODULE_FIRMWARE("amdgpu/vega12_mec2.bin");
+MODULE_FIRMWARE("amdgpu/vega12_rlc.bin");
+
+MODULE_FIRMWARE("amdgpu/vega20_ce.bin");
+MODULE_FIRMWARE("amdgpu/vega20_pfp.bin");
+MODULE_FIRMWARE("amdgpu/vega20_me.bin");
+MODULE_FIRMWARE("amdgpu/vega20_mec.bin");
+MODULE_FIRMWARE("amdgpu/vega20_mec2.bin");
+MODULE_FIRMWARE("amdgpu/vega20_rlc.bin");
+
+MODULE_FIRMWARE("amdgpu/raven_ce.bin");
+MODULE_FIRMWARE("amdgpu/raven_pfp.bin");
+MODULE_FIRMWARE("amdgpu/raven_me.bin");
+MODULE_FIRMWARE("amdgpu/raven_mec.bin");
+MODULE_FIRMWARE("amdgpu/raven_mec2.bin");
+MODULE_FIRMWARE("amdgpu/raven_rlc.bin");
+
+MODULE_FIRMWARE("amdgpu/picasso_ce.bin");
+MODULE_FIRMWARE("amdgpu/picasso_pfp.bin");
+MODULE_FIRMWARE("amdgpu/picasso_me.bin");
+MODULE_FIRMWARE("amdgpu/picasso_mec.bin");
+MODULE_FIRMWARE("amdgpu/picasso_mec2.bin");
+MODULE_FIRMWARE("amdgpu/picasso_rlc.bin");
+MODULE_FIRMWARE("amdgpu/picasso_rlc_am4.bin");
+
+MODULE_FIRMWARE("amdgpu/raven2_ce.bin");
+MODULE_FIRMWARE("amdgpu/raven2_pfp.bin");
+MODULE_FIRMWARE("amdgpu/raven2_me.bin");
+MODULE_FIRMWARE("amdgpu/raven2_mec.bin");
+MODULE_FIRMWARE("amdgpu/raven2_mec2.bin");
+MODULE_FIRMWARE("amdgpu/raven2_rlc.bin");
+MODULE_FIRMWARE("amdgpu/raven_kicker_rlc.bin");
+
+MODULE_FIRMWARE("amdgpu/arcturus_mec.bin");
+MODULE_FIRMWARE("amdgpu/arcturus_rlc.bin");
+
+MODULE_FIRMWARE("amdgpu/renoir_ce.bin");
+MODULE_FIRMWARE("amdgpu/renoir_pfp.bin");
+MODULE_FIRMWARE("amdgpu/renoir_me.bin");
+MODULE_FIRMWARE("amdgpu/renoir_mec.bin");
+MODULE_FIRMWARE("amdgpu/renoir_rlc.bin");
+
+MODULE_FIRMWARE("amdgpu/green_sardine_ce.bin");
+MODULE_FIRMWARE("amdgpu/green_sardine_pfp.bin");
+MODULE_FIRMWARE("amdgpu/green_sardine_me.bin");
+MODULE_FIRMWARE("amdgpu/green_sardine_mec.bin");
+MODULE_FIRMWARE("amdgpu/green_sardine_mec2.bin");
+MODULE_FIRMWARE("amdgpu/green_sardine_rlc.bin");
+
 static const char *hw_id_names[HW_ID_MAX] = {
[MP1_HWID]  = "MP1",
[MP2_HWID]  = "MP2",
@@ -1845,8 +1907,87 @@ static int amdgpu_discovery_set_display_ip_blocks(struct 
amdgpu_device *adev)
return 0;
 }
 
+static int amdgpu_discovery_load_gfx9(struct amdgpu_device *adev, char 
*ucode_prefix)
+{
+   uint32_t smu_version;
+   char fw_name[40];
+   int r;
+
+   /* No CPG in Arcturus */
+   if (adev->gfx.num_gfx_rings) {
+   snprintf(fw_name, sizeof(fw_name), "amdgpu/%s_pfp.bin", 
ucode_prefix);
+   r = request_firmware(&adev->gfx.pfp_fw, fw_name, adev->dev);
+   if (r)
+   return r;
+
+   snprintf(fw_name, sizeof(fw_name), "amdgpu/%s_me.bin", 
ucode_prefix);
+   r = request_firmware(&adev->gfx.me_fw, fw_name, adev->dev);
+   if (r)
+   return r;
+
+   snprintf(fw_name, sizeof(fw_name), "amdgpu/%s_ce.bin", 
ucode_prefix);
+   r = request_firmware(&adev->gfx.ce_fw, fw_name, adev->dev);
+   if (r)
+   return r;
+   }
+
+   if (amdgpu_sriov_vf(adev) && (adev->asic_type == CHIP_ALDEBARAN))
+   snprintf(fw_name, sizeof(fw_name), "amdgpu/%s_sjt_mec.bin", 
ucode_prefix);
+   else
+   snprintf(fw_name, sizeof(fw_name), "amdgpu/%s_mec.bin", 
ucode_prefix);
+   r = request_firmware(&adev->gfx.mec_fw, fw_name, adev->dev);
+   if (r)
+   return r;
+
+   /*
+* For Picasso && AM4 SOCKET board, we use picasso_rlc_am4.bin
+* instead of picasso_rlc.bin.
+* Judgment method:
+* PCO AM4: revision >= 0xC8 && revision <= 0xCF
+*  or revision >= 0xD8 && revisi

[PATCH v2 11/11] drm/amd: Request PSP microcode during IP discovery

2022-12-28 Thread Mario Limonciello
If PSP microcode is required but not available during early init, the
firmware framebuffer will have already been released and the screen will
freeze.

Move the request for PSP microcode into the IP discovery phase
so that if it's not available, IP discovery will fail.

Signed-off-by: Mario Limonciello 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_discovery.c | 120 -
 drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c   |   2 -
 drivers/gpu/drm/amd/amdgpu/psp_v10_0.c| 106 +++
 drivers/gpu/drm/amd/amdgpu/psp_v11_0.c| 165 --
 drivers/gpu/drm/amd/amdgpu/psp_v12_0.c| 102 +++
 drivers/gpu/drm/amd/amdgpu/psp_v13_0.c|  82 -
 drivers/gpu/drm/amd/amdgpu/psp_v13_0_4.c  |  36 
 drivers/gpu/drm/amd/amdgpu/psp_v3_1.c |  36 
 8 files changed, 202 insertions(+), 447 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_discovery.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_discovery.c
index c8c538a768fe..6199ab078bc7 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_discovery.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_discovery.c
@@ -158,6 +158,40 @@ MODULE_FIRMWARE("amdgpu/gc_11_0_2_mes1.bin");
 MODULE_FIRMWARE("amdgpu/gc_11_0_3_mes.bin");
 MODULE_FIRMWARE("amdgpu/gc_11_0_3_mes1.bin");
 
+MODULE_FIRMWARE("amdgpu/aldebaran_sos.bin");
+MODULE_FIRMWARE("amdgpu/aldebaran_ta.bin");
+MODULE_FIRMWARE("amdgpu/aldebaran_cap.bin");
+MODULE_FIRMWARE("amdgpu/green_sardine_asd.bin");
+MODULE_FIRMWARE("amdgpu/green_sardine_ta.bin");
+MODULE_FIRMWARE("amdgpu/raven_asd.bin");
+MODULE_FIRMWARE("amdgpu/picasso_asd.bin");
+MODULE_FIRMWARE("amdgpu/raven2_asd.bin");
+MODULE_FIRMWARE("amdgpu/picasso_ta.bin");
+MODULE_FIRMWARE("amdgpu/raven2_ta.bin");
+MODULE_FIRMWARE("amdgpu/raven_ta.bin");
+MODULE_FIRMWARE("amdgpu/renoir_asd.bin");
+MODULE_FIRMWARE("amdgpu/renoir_ta.bin");
+MODULE_FIRMWARE("amdgpu/yellow_carp_toc.bin");
+MODULE_FIRMWARE("amdgpu/yellow_carp_ta.bin");
+MODULE_FIRMWARE("amdgpu/vega10_sos.bin");
+MODULE_FIRMWARE("amdgpu/vega10_asd.bin");
+MODULE_FIRMWARE("amdgpu/vega10_cap.bin");
+MODULE_FIRMWARE("amdgpu/vega12_sos.bin");
+MODULE_FIRMWARE("amdgpu/vega12_asd.bin");
+MODULE_FIRMWARE("amdgpu/psp_13_0_5_toc.bin");
+MODULE_FIRMWARE("amdgpu/psp_13_0_5_ta.bin");
+MODULE_FIRMWARE("amdgpu/psp_13_0_8_toc.bin");
+MODULE_FIRMWARE("amdgpu/psp_13_0_8_ta.bin");
+MODULE_FIRMWARE("amdgpu/psp_13_0_0_sos.bin");
+MODULE_FIRMWARE("amdgpu/psp_13_0_0_ta.bin");
+MODULE_FIRMWARE("amdgpu/psp_13_0_7_sos.bin");
+MODULE_FIRMWARE("amdgpu/psp_13_0_7_ta.bin");
+MODULE_FIRMWARE("amdgpu/psp_13_0_10_sos.bin");
+MODULE_FIRMWARE("amdgpu/psp_13_0_10_ta.bin");
+MODULE_FIRMWARE("amdgpu/psp_13_0_4_toc.bin");
+MODULE_FIRMWARE("amdgpu/psp_13_0_4_ta.bin");
+MODULE_FIRMWARE("amdgpu/psp_13_0_11_toc.bin");
+MODULE_FIRMWARE("amdgpu/psp_13_0_11_ta.bin");
 
 /* gfx9 */
 MODULE_FIRMWARE("amdgpu/vega10_ce.bin");
@@ -1858,12 +1892,30 @@ static int amdgpu_discovery_set_ih_ip_blocks(struct 
amdgpu_device *adev)
 
 static int amdgpu_discovery_set_psp_ip_blocks(struct amdgpu_device *adev)
 {
+   char ucode_prefix[30];
+   int r;
+
+   amdgpu_ucode_ip_version_decode(adev, MP0_HWIP, ucode_prefix, 
sizeof(ucode_prefix));
+   adev->psp.adev = adev;
+
switch (adev->ip_versions[MP0_HWIP][0]) {
case IP_VERSION(9, 0, 0):
+   r = psp_init_sos_microcode(&adev->psp, ucode_prefix);
+   if (r)
+   return r;
+   r = psp_init_asd_microcode(&adev->psp, ucode_prefix);
+   if (r)
+   return r;
amdgpu_device_ip_block_add(adev, &psp_v3_1_ip_block);
break;
case IP_VERSION(10, 0, 0):
case IP_VERSION(10, 0, 1):
+   r = psp_init_asd_microcode(&adev->psp, ucode_prefix);
+   if (r)
+   return r;
+   r = psp_init_ta_microcode(&adev->psp, ucode_prefix);
+   if (r)
+   return r;
amdgpu_device_ip_block_add(adev, &psp_v10_0_ip_block);
break;
case IP_VERSION(11, 0, 0):
@@ -1871,11 +1923,34 @@ static int amdgpu_discovery_set_psp_ip_blocks(struct 
amdgpu_device *adev)
case IP_VERSION(11, 0, 4):
case IP_VERSION(11, 0, 5):
case IP_VERSION(11, 0, 9):
+   r = psp_init_sos_microcode(&adev->psp, ucode_prefix);
+   if (r)
+   return r;
+   r = psp_init_asd_microcode(&adev->psp, ucode_prefix);
+   if (r)
+   return r;
+   r = psp_init_ta_microcode(&adev->psp, ucode_prefix);
+   if (r)
+   return r;
+   break;
case IP_VERSION(11, 0, 7):
case IP_VERSION(11, 0, 11):
case IP_VERSION(11, 0, 12):
case IP_VERSION(11, 0, 13):
+   r = psp_init_sos_microcode(&adev->psp, ucode_prefix);
+   if (r)
+   return r;
+

[PATCH v2 05/11] drm/amd: Request SDMA microcode during IP discovery

2022-12-28 Thread Mario Limonciello
If SDMA microcode is not available during early init, the microcode
framebuffer will have already been released and the screen will
freeze.

Move the request from SDMA microcode into the IP discovery phase
so that if it's not available, IP discovery will fail.

Signed-off-by: Mario Limonciello 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_discovery.c | 57 
 drivers/gpu/drm/amd/amdgpu/amdgpu_sdma.c  |  9 +--
 drivers/gpu/drm/amd/amdgpu/amdgpu_sdma.h  |  2 +-
 drivers/gpu/drm/amd/amdgpu/sdma_v4_0.c| 61 +
 drivers/gpu/drm/amd/amdgpu/sdma_v5_0.c| 42 +---
 drivers/gpu/drm/amd/amdgpu/sdma_v5_2.c| 65 +--
 drivers/gpu/drm/amd/amdgpu/sdma_v6_0.c| 30 +
 7 files changed, 66 insertions(+), 200 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_discovery.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_discovery.c
index b719852daa07..f51ff86293b3 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_discovery.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_discovery.c
@@ -90,6 +90,40 @@ MODULE_FIRMWARE(FIRMWARE_IP_DISCOVERY);
 #define mmMM_INDEX_HI  0x6
 #define mmMM_DATA  0x1
 
+MODULE_FIRMWARE("amdgpu/navi10_sdma.bin");
+MODULE_FIRMWARE("amdgpu/navi10_sdma1.bin");
+MODULE_FIRMWARE("amdgpu/navi14_sdma.bin");
+MODULE_FIRMWARE("amdgpu/navi14_sdma1.bin");
+MODULE_FIRMWARE("amdgpu/navi12_sdma.bin");
+MODULE_FIRMWARE("amdgpu/navi12_sdma1.bin");
+MODULE_FIRMWARE("amdgpu/cyan_skillfish2_sdma.bin");
+MODULE_FIRMWARE("amdgpu/cyan_skillfish2_sdma1.bin");
+MODULE_FIRMWARE("amdgpu/vega10_sdma.bin");
+MODULE_FIRMWARE("amdgpu/vega10_sdma1.bin");
+MODULE_FIRMWARE("amdgpu/vega12_sdma.bin");
+MODULE_FIRMWARE("amdgpu/vega12_sdma1.bin");
+MODULE_FIRMWARE("amdgpu/vega20_sdma.bin");
+MODULE_FIRMWARE("amdgpu/vega20_sdma1.bin");
+MODULE_FIRMWARE("amdgpu/raven_sdma.bin");
+MODULE_FIRMWARE("amdgpu/picasso_sdma.bin");
+MODULE_FIRMWARE("amdgpu/raven2_sdma.bin");
+MODULE_FIRMWARE("amdgpu/arcturus_sdma.bin");
+MODULE_FIRMWARE("amdgpu/renoir_sdma.bin");
+MODULE_FIRMWARE("amdgpu/green_sardine_sdma.bin");
+MODULE_FIRMWARE("amdgpu/aldebaran_sdma.bin");
+MODULE_FIRMWARE("amdgpu/sienna_cichlid_sdma.bin");
+MODULE_FIRMWARE("amdgpu/navy_flounder_sdma.bin");
+MODULE_FIRMWARE("amdgpu/dimgrey_cavefish_sdma.bin");
+MODULE_FIRMWARE("amdgpu/beige_goby_sdma.bin");
+MODULE_FIRMWARE("amdgpu/vangogh_sdma.bin");
+MODULE_FIRMWARE("amdgpu/yellow_carp_sdma.bin");
+MODULE_FIRMWARE("amdgpu/sdma_5_2_6.bin");
+MODULE_FIRMWARE("amdgpu/sdma_5_2_7.bin");
+MODULE_FIRMWARE("amdgpu/sdma_6_0_0.bin");
+MODULE_FIRMWARE("amdgpu/sdma_6_0_1.bin");
+MODULE_FIRMWARE("amdgpu/sdma_6_0_2.bin");
+MODULE_FIRMWARE("amdgpu/sdma_6_0_3.bin");
+
 static const char *hw_id_names[HW_ID_MAX] = {
[MP1_HWID]  = "MP1",
[MP2_HWID]  = "MP2",
@@ -1821,8 +1855,26 @@ static int amdgpu_discovery_set_gc_ip_blocks(struct 
amdgpu_device *adev)
return 0;
 }
 
+static int amdgpu_discovery_load_sdma_fw(struct amdgpu_device *adev, u32 
instance,
+const char *chip_name)
+{
+   char fw_name[40];
+
+   if (instance == 0)
+   snprintf(fw_name, sizeof(fw_name), "amdgpu/%s.bin", chip_name);
+   else
+   snprintf(fw_name, sizeof(fw_name), "amdgpu/%s_sdma1.bin", 
chip_name);
+
+   return request_firmware(&adev->sdma.instance[instance].fw, fw_name, 
adev->dev);
+}
+
 static int amdgpu_discovery_set_sdma_ip_blocks(struct amdgpu_device *adev)
 {
+   char ucode_prefix[30];
+   int i, r;
+
+   amdgpu_ucode_ip_version_decode(adev, SDMA0_HWIP, ucode_prefix, 
sizeof(ucode_prefix));
+
switch (adev->ip_versions[SDMA0_HWIP][0]) {
case IP_VERSION(4, 0, 0):
case IP_VERSION(4, 0, 1):
@@ -1862,6 +1914,11 @@ static int amdgpu_discovery_set_sdma_ip_blocks(struct 
amdgpu_device *adev)
adev->ip_versions[SDMA0_HWIP][0]);
return -EINVAL;
}
+   for (i = 0; i < adev->sdma.num_instances; i++) {
+   r = amdgpu_discovery_load_sdma_fw(adev, i, ucode_prefix);
+   if (r)
+   return r;
+   }
return 0;
 }
 
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_sdma.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_sdma.c
index ea5278f094c0..9e46d8034c03 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_sdma.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_sdma.c
@@ -205,8 +205,7 @@ void amdgpu_sdma_destroy_inst_ctx(struct amdgpu_device 
*adev,
 }
 
 int amdgpu_sdma_init_microcode(struct amdgpu_device *adev,
-  char *fw_name, u32 instance,
-  bool duplicate)
+  u32 instance, bool duplicate)
 {
struct amdgpu_firmware_info *info = NULL;
const struct common_firmware_header *header = NULL;
@@ -214,10 +213,6 @@ int amdgpu_sdma_init_microcode(struct amdgpu_device *adev,
const struct sdma_firmware_header_v2_0 *sd

[PATCH v2 07/11] drm/amd: Request MES microcode during IP discovery

2022-12-28 Thread Mario Limonciello
If MES microcode is required but not available during early init, the
microcode framebuffer will have already been released and the screen will
freeze.

Move the request for MES microcode into the IP discovery phase
so that if it's not available, IP discovery will fail.

Signed-off-by: Mario Limonciello 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_discovery.c | 39 +++
 drivers/gpu/drm/amd/amdgpu/mes_v10_1.c| 28 -
 drivers/gpu/drm/amd/amdgpu/mes_v11_0.c| 25 +---
 3 files changed, 40 insertions(+), 52 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_discovery.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_discovery.c
index 1c26a3a60394..479266ed2b7f 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_discovery.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_discovery.c
@@ -145,6 +145,19 @@ MODULE_FIRMWARE("amdgpu/vcn_4_0_0.bin");
 MODULE_FIRMWARE("amdgpu/vcn_4_0_2.bin");
 MODULE_FIRMWARE("amdgpu/vcn_4_0_4.bin");
 
+MODULE_FIRMWARE("amdgpu/navi10_mes.bin");
+MODULE_FIRMWARE("amdgpu/sienna_cichlid_mes.bin");
+MODULE_FIRMWARE("amdgpu/sienna_cichlid_mes1.bin");
+
+MODULE_FIRMWARE("amdgpu/gc_11_0_0_mes.bin");
+MODULE_FIRMWARE("amdgpu/gc_11_0_0_mes1.bin");
+MODULE_FIRMWARE("amdgpu/gc_11_0_1_mes.bin");
+MODULE_FIRMWARE("amdgpu/gc_11_0_1_mes1.bin");
+MODULE_FIRMWARE("amdgpu/gc_11_0_2_mes.bin");
+MODULE_FIRMWARE("amdgpu/gc_11_0_2_mes1.bin");
+MODULE_FIRMWARE("amdgpu/gc_11_0_3_mes.bin");
+MODULE_FIRMWARE("amdgpu/gc_11_0_3_mes1.bin");
+
 static const char *hw_id_names[HW_ID_MAX] = {
[MP1_HWID]  = "MP1",
[MP2_HWID]  = "MP2",
@@ -2041,10 +2054,29 @@ static int amdgpu_discovery_set_mm_ip_blocks(struct 
amdgpu_device *adev)
r = amdgpu_discovery_load_vcn_fw(adev, ucode_prefix);
return r;
 }
+
+static int amdgpu_discovery_load_mes_fw(struct amdgpu_device *adev,
+   enum admgpu_mes_pipe pipe,
+   const char *ucode_prefix)
+{
+   char fw_name[40];
+
+   if (pipe == AMDGPU_MES_SCHED_PIPE)
+   snprintf(fw_name, sizeof(fw_name), "amdgpu/%s_mes.bin",
+ucode_prefix);
+   else
+   snprintf(fw_name, sizeof(fw_name), "amdgpu/%s_mes1.bin",
+ucode_prefix);
+
+   return request_firmware(&adev->mes.fw[pipe], fw_name, adev->dev);
 }
 
 static int amdgpu_discovery_set_mes_ip_blocks(struct amdgpu_device *adev)
 {
+   char ucode_prefix[30];
+   int pipe, r;
+   amdgpu_ucode_ip_version_decode(adev, GC_HWIP, ucode_prefix, 
sizeof(ucode_prefix));
+
switch (adev->ip_versions[GC_HWIP][0]) {
case IP_VERSION(10, 1, 10):
case IP_VERSION(10, 1, 1):
@@ -2077,6 +2109,13 @@ static int amdgpu_discovery_set_mes_ip_blocks(struct 
amdgpu_device *adev)
default:
break;
}
+   if (adev->enable_mes) {
+   for (pipe = 0; pipe < AMDGPU_MAX_MES_PIPES; pipe++) {
+   r = amdgpu_discovery_load_mes_fw(adev, pipe, 
ucode_prefix);
+   if (r)
+   return r;
+   }
+   }
return 0;
 }
 
diff --git a/drivers/gpu/drm/amd/amdgpu/mes_v10_1.c 
b/drivers/gpu/drm/amd/amdgpu/mes_v10_1.c
index 614394118a53..9faa9867b3c9 100644
--- a/drivers/gpu/drm/amd/amdgpu/mes_v10_1.c
+++ b/drivers/gpu/drm/amd/amdgpu/mes_v10_1.c
@@ -37,10 +37,6 @@
 #define mmRLC_CP_SCHEDULERS_Sienna_Cichlid 0x4ca1
 #define mmRLC_CP_SCHEDULERS_Sienna_Cichlid_BASE_IDX1
 
-MODULE_FIRMWARE("amdgpu/navi10_mes.bin");
-MODULE_FIRMWARE("amdgpu/sienna_cichlid_mes.bin");
-MODULE_FIRMWARE("amdgpu/sienna_cichlid_mes1.bin");
-
 static int mes_v10_1_hw_fini(void *handle);
 static int mes_v10_1_kiq_hw_init(struct amdgpu_device *adev);
 
@@ -382,34 +378,10 @@ static const struct amdgpu_mes_funcs mes_v10_1_funcs = {
 static int mes_v10_1_init_microcode(struct amdgpu_device *adev,
enum admgpu_mes_pipe pipe)
 {
-   const char *chip_name;
-   char fw_name[30];
int err;
const struct mes_firmware_header_v1_0 *mes_hdr;
struct amdgpu_firmware_info *info;
 
-   switch (adev->ip_versions[GC_HWIP][0]) {
-   case IP_VERSION(10, 1, 10):
-   chip_name = "navi10";
-   break;
-   case IP_VERSION(10, 3, 0):
-   chip_name = "sienna_cichlid";
-   break;
-   default:
-   BUG();
-   }
-
-   if (pipe == AMDGPU_MES_SCHED_PIPE)
-   snprintf(fw_name, sizeof(fw_name), "amdgpu/%s_mes.bin",
-chip_name);
-   else
-   snprintf(fw_name, sizeof(fw_name), "amdgpu/%s_mes1.bin",
-chip_name);
-
-   err = request_firmware(&adev->mes.fw[pipe], fw_name, adev->dev);
-   if (err)
-   return err;
-
err = amdgpu_ucode_validate(adev->mes.fw[pipe]);
if (err) {
 

[PATCH v2 04/11] drm/amd: Convert SMU v13 to use `amdgpu_ucode_ip_version_decode`

2022-12-28 Thread Mario Limonciello
The special case for the one dGPU has been moved into
`amdgpu_ucode_ip_version_decode`, so simplify this code.

Signed-off-by: Mario Limonciello 
---
 drivers/gpu/drm/amd/pm/swsmu/smu13/smu_v13_0.c | 12 ++--
 1 file changed, 2 insertions(+), 10 deletions(-)

diff --git a/drivers/gpu/drm/amd/pm/swsmu/smu13/smu_v13_0.c 
b/drivers/gpu/drm/amd/pm/swsmu/smu13/smu_v13_0.c
index 0ac9cac805f9..506a49a4b425 100644
--- a/drivers/gpu/drm/amd/pm/swsmu/smu13/smu_v13_0.c
+++ b/drivers/gpu/drm/amd/pm/swsmu/smu13/smu_v13_0.c
@@ -88,7 +88,6 @@ static const int link_speed[] = {25, 50, 80, 160};
 int smu_v13_0_init_microcode(struct smu_context *smu)
 {
struct amdgpu_device *adev = smu->adev;
-   const char *chip_name;
char fw_name[30];
char ucode_prefix[30];
int err = 0;
@@ -100,16 +99,9 @@ int smu_v13_0_init_microcode(struct smu_context *smu)
if (amdgpu_sriov_vf(adev))
return 0;
 
-   switch (adev->ip_versions[MP1_HWIP][0]) {
-   case IP_VERSION(13, 0, 2):
-   chip_name = "aldebaran_smc";
-   break;
-   default:
-   amdgpu_ucode_ip_version_decode(adev, MP1_HWIP, ucode_prefix, 
sizeof(ucode_prefix));
-   chip_name = ucode_prefix;
-   }
+   amdgpu_ucode_ip_version_decode(adev, MP1_HWIP, ucode_prefix, 
sizeof(ucode_prefix));
 
-   snprintf(fw_name, sizeof(fw_name), "amdgpu/%s.bin", chip_name);
+   snprintf(fw_name, sizeof(fw_name), "amdgpu/%s.bin", ucode_prefix);
 
err = request_firmware(&adev->pm.fw, fw_name, adev->dev);
if (err)
-- 
2.34.1



[PATCH v2 03/11] drm/amd: Convert SMUv11 microcode init to use `amdgpu_ucode_ip_version_decode`

2022-12-28 Thread Mario Limonciello
Remove the special casing from SMU v11 code. No intended functional
changes.

Signed-off-by: Mario Limonciello 
---
 .../gpu/drm/amd/pm/swsmu/smu11/smu_v11_0.c| 35 ++-
 1 file changed, 3 insertions(+), 32 deletions(-)

diff --git a/drivers/gpu/drm/amd/pm/swsmu/smu11/smu_v11_0.c 
b/drivers/gpu/drm/amd/pm/swsmu/smu11/smu_v11_0.c
index ad66d57aa102..d4756bd30830 100644
--- a/drivers/gpu/drm/amd/pm/swsmu/smu11/smu_v11_0.c
+++ b/drivers/gpu/drm/amd/pm/swsmu/smu11/smu_v11_0.c
@@ -93,7 +93,7 @@ static void smu_v11_0_poll_baco_exit(struct smu_context *smu)
 int smu_v11_0_init_microcode(struct smu_context *smu)
 {
struct amdgpu_device *adev = smu->adev;
-   const char *chip_name;
+   char ucode_prefix[30];
char fw_name[SMU_FW_NAME_LEN];
int err = 0;
const struct smc_firmware_header_v1_0 *hdr;
@@ -105,38 +105,9 @@ int smu_v11_0_init_microcode(struct smu_context *smu)
 (adev->ip_versions[MP1_HWIP][0] == IP_VERSION(11, 0, 7
return 0;
 
-   switch (adev->ip_versions[MP1_HWIP][0]) {
-   case IP_VERSION(11, 0, 0):
-   chip_name = "navi10";
-   break;
-   case IP_VERSION(11, 0, 5):
-   chip_name = "navi14";
-   break;
-   case IP_VERSION(11, 0, 9):
-   chip_name = "navi12";
-   break;
-   case IP_VERSION(11, 0, 7):
-   chip_name = "sienna_cichlid";
-   break;
-   case IP_VERSION(11, 0, 11):
-   chip_name = "navy_flounder";
-   break;
-   case IP_VERSION(11, 0, 12):
-   chip_name = "dimgrey_cavefish";
-   break;
-   case IP_VERSION(11, 0, 13):
-   chip_name = "beige_goby";
-   break;
-   case IP_VERSION(11, 0, 2):
-   chip_name = "arcturus";
-   break;
-   default:
-   dev_err(adev->dev, "Unsupported IP version 0x%x\n",
-   adev->ip_versions[MP1_HWIP][0]);
-   return -EINVAL;
-   }
+   amdgpu_ucode_ip_version_decode(adev, MP1_HWIP, ucode_prefix, 
sizeof(ucode_prefix));
 
-   snprintf(fw_name, sizeof(fw_name), "amdgpu/%s_smc.bin", chip_name);
+   snprintf(fw_name, sizeof(fw_name), "amdgpu/%s.bin", ucode_prefix);
 
err = request_firmware(&adev->pm.fw, fw_name, adev->dev);
if (err)
-- 
2.34.1



[PATCH v2 02/11] drm/amd: Add a legacy mapping to "amdgpu_ucode_ip_version_decode"

2022-12-28 Thread Mario Limonciello
This will allow other parts of the driver that currently special
case firmware file names to before IP version style naming to just
have a single call to `amdgpu_ucode_ip_version_decode`.

Signed-off-by: Mario Limonciello 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_ucode.c | 208 ++
 1 file changed, 208 insertions(+)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ucode.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_ucode.c
index 5cb62e6249c2..5392c1fe434b 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ucode.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ucode.c
@@ -1059,12 +1059,220 @@ int amdgpu_ucode_init_bo(struct amdgpu_device *adev)
return 0;
 }
 
+static const char *amdgpu_ucode_legacy_naming(struct amdgpu_device *adev, int 
block_type)
+{
+   if (block_type == MP0_HWIP) {
+   switch (adev->ip_versions[MP0_HWIP][0]) {
+   case IP_VERSION(9, 0, 0):
+   switch (adev->asic_type) {
+   case CHIP_VEGA10:
+   return "vega10";
+   case CHIP_VEGA12:
+   return "vega12";
+   default:
+   return NULL;
+   }
+   break;
+   case IP_VERSION(10, 0, 0):
+   case IP_VERSION(10, 0, 1):
+   if (adev->asic_type == CHIP_RAVEN) {
+   if (adev->apu_flags & AMD_APU_IS_RAVEN2)
+   return "raven2";
+   else if (adev->apu_flags & AMD_APU_IS_PICASSO)
+   return "picasso";
+   else
+   return "raven";
+   }
+   break;
+   case IP_VERSION(11, 0, 0):
+   return "navi10";
+   case IP_VERSION(11, 0, 2):
+   return "vega20";
+   case IP_VERSION(11, 0, 4):
+   return "arcturus";
+   case IP_VERSION(11, 0, 5):
+   return "navi14";
+   case IP_VERSION(11, 0, 7):
+   return "sienna_cichlid";
+   case IP_VERSION(11, 0, 9):
+   return "navi12";
+   case IP_VERSION(11, 0, 11):
+   return "navy_flounder";
+   case IP_VERSION(11, 0, 12):
+   return "dimgrey_cavefish";
+   case IP_VERSION(11, 0, 13):
+   return "beige_goby";
+   case IP_VERSION(11, 5, 0):
+   return "vangogh";
+   case IP_VERSION(12, 0, 1):
+   if (adev->asic_type == CHIP_RENOIR) {
+   if (adev->apu_flags & AMD_APU_IS_RENOIR)
+   return "renoir";
+   else
+   return "green_sardine";
+   }
+   break;
+   case IP_VERSION(13, 0, 2):
+   return "aldebaran";
+   case IP_VERSION(13, 0, 1):
+   case IP_VERSION(13, 0, 3):
+   return "yellow_carp";
+   }
+   } else if (block_type == MP1_HWIP) {
+   switch (adev->ip_versions[MP1_HWIP][0]) {
+   case IP_VERSION(9, 0, 0):
+   case IP_VERSION(10, 0, 0):
+   case IP_VERSION(10, 0, 1):
+   case IP_VERSION(11, 0, 2):
+   if (adev->asic_type == CHIP_ARCTURUS)
+   return "arcturus_smc";
+   return NULL;
+   case IP_VERSION(11, 0, 0):
+   return "navi10_smc";
+   case IP_VERSION(11, 0, 5):
+   return "navi14_smc";
+   case IP_VERSION(11, 0, 9):
+   return "navi12_smc";
+   case IP_VERSION(11, 0, 7):
+   return "sienna_cichlid_smc";
+   case IP_VERSION(11, 0, 11):
+   return "navy_flounder_smc";
+   case IP_VERSION(11, 0, 12):
+   return "dimgrey_cavefish_smc";
+   case IP_VERSION(11, 0, 13):
+   return "beige_goby_smc";
+   case IP_VERSION(13, 0, 2):
+   return "aldebaran_smc";
+   }
+   } else if (block_type == SDMA0_HWIP) {
+   switch (adev->ip_versions[SDMA0_HWIP][0]) {
+   case IP_VERSION(4, 0, 0):
+   return "vega10";
+   case IP_VERSION(4, 0, 1):
+   return "vega12";
+   case IP_VERSION(4, 1, 0):
+   case IP_VERSION(4, 1, 1):
+   if (adev->apu_flags & AMD_APU_IS_RAVEN2)
+   return "raven2";
+

[PATCH v2 01/11] drm/amd: Delay removal of the firmware framebuffer

2022-12-28 Thread Mario Limonciello
Removing the firmware framebuffer from the driver means that even
if the driver doesn't support the IP blocks in a GPU it will no
longer be functional after the driver fails to initialize.

This change will ensure that unsupported IP blocks at least cause
the driver to work with the EFI framebuffer.

Cc: sta...@vger.kernel.org
Suggested-by: Alex Deucher 
Signed-off-by: Mario Limonciello 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 8 
 drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c| 6 --
 2 files changed, 8 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
index 9a1a5c2864a0..84d83be2087c 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
@@ -37,6 +37,7 @@
 #include 
 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -89,6 +90,8 @@ MODULE_FIRMWARE("amdgpu/navi12_gpu_info.bin");
 #define AMDGPU_MAX_RETRY_LIMIT 2
 #define AMDGPU_RETRY_SRIOV_RESET(r) ((r) == -EBUSY || (r) == -ETIMEDOUT || (r) 
== -EINVAL)
 
+static const struct drm_driver amdgpu_kms_driver;
+
 const char *amdgpu_asic_name[] = {
"TAHITI",
"PITCAIRN",
@@ -2140,6 +2143,11 @@ static int amdgpu_device_ip_early_init(struct 
amdgpu_device *adev)
break;
}
 
+   /* Get rid of things like offb */
+   r = drm_aperture_remove_conflicting_pci_framebuffers(adev->pdev, 
&amdgpu_kms_driver);
+   if (r)
+   return r;
+
if (amdgpu_has_atpx() &&
(amdgpu_is_atpx_hybrid() ||
 amdgpu_has_atpx_dgpu_power_cntl()) &&
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
index db7e34eacc35..b9f14ec9edb2 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
@@ -23,7 +23,6 @@
  */
 
 #include 
-#include 
 #include 
 #include 
 #include 
@@ -2096,11 +2095,6 @@ static int amdgpu_pci_probe(struct pci_dev *pdev,
}
 #endif
 
-   /* Get rid of things like offb */
-   ret = drm_aperture_remove_conflicting_pci_framebuffers(pdev, 
&amdgpu_kms_driver);
-   if (ret)
-   return ret;
-
adev = devm_drm_dev_alloc(&pdev->dev, &amdgpu_kms_driver, 
typeof(*adev), ddev);
if (IS_ERR(adev))
return PTR_ERR(adev);
-- 
2.34.1



[PATCH v2 00/11] Recover from failure to probe GPU

2022-12-28 Thread Mario Limonciello
One of the first thing that KMS drivers do during initialization is
destroy the system firmware framebuffer by means of
`drm_aperture_remove_conflicting_pci_framebuffers`

This means that if for any reason the GPU failed to probe the user
will be stuck with at best a screen frozen at the last thing that
was shown before the KMS driver continued it's probe.

The problem is most pronounced when new GPU support is introduced
because users will need to have a recent linux-firmware snapshot
on their system when they boot a kernel with matching support.

However the problem is further exaggerated in the case of amdgpu because
it has migrated to "IP discovery" where amdgpu will attempt to load
on "ALL" AMD GPUs even if the driver is missing support for IP blocks
contained in that GPU.

IP discovery requires some probing and isn't run until after the
framebuffer has been destroyed.

This means a situation can occur where a user purchases a new GPU not
yet supported by a distribution and when booting the installer it will
"freeze" even if the distribution doesn't have the matching kernel support
for those IP blocks.

The perfect example of this is Ubuntu 22.10 and the new dGPUs just
launched by AMD.  The installation media ships with kernel 5.19 (which
has IP discovery) but the amdgpu support for those IP blocks landed in
kernel 6.0. The matching linux-firmware was released after 22.10's launch.
The screen will freeze without nomodeset. Even if a user manages to install
and then upgrades to kernel 6.0 after install they'll still have the
problem of missing firmware, and the same experience.

This is quite jarring for users, particularly if they don't know
that they have to use "nomodeset" to install.

To help the situation make changes to GPU discovery:
1) Delay releasing the firmware framebuffer until after IP discovery has
completed.  This will help the situation of an older kernel that doesn't
yet support the IP blocks probing a new GPU.
2) Request loading all PSP, VCN, SDMA, MES and GC microcode into memory
during IP discovery. This will help the situation of new enough kernel for
the IP discovery phase to otherwise pass but missing microcode from
linux-firmware.git.

Not all requested firmware will be loaded during IP discovery as some of it
will require larger driver architecture changes. For example SMU firmware
isn't loaded on certain products, but that's not known until later on when
the early_init phase of the SMU load occurs.

v1->v2:
 * Take the suggestion from v1 thread to delay the framebuffer release until
   ip discovery is done. This patch is CC to stable to that older stable
   kernels with IP discovery won't try to probe unknown IP.
 * Drop changes to drm aperature.
 * Fetch SDMA, VCN, MES, GC and PSP microcode during IP discovery.

Mario Limonciello (11):
  drm/amd: Delay removal of the firmware framebuffer
  drm/amd: Add a legacy mapping to "amdgpu_ucode_ip_version_decode"
  drm/amd: Convert SMUv11 microcode init to use
`amdgpu_ucode_ip_version_decode`
  drm/amd: Convert SMU v13 to use `amdgpu_ucode_ip_version_decode`
  drm/amd: Request SDMA microcode during IP discovery
  drm/amd: Request VCN microcode during IP discovery
  drm/amd: Request MES microcode during IP discovery
  drm/amd: Request GFX9 microcode during IP discovery
  drm/amd: Request GFX10 microcode during IP discovery
  drm/amd: Request GFX11 microcode during IP discovery
  drm/amd: Request PSP microcode during IP discovery

 drivers/gpu/drm/amd/amdgpu/amdgpu_device.c|   8 +
 drivers/gpu/drm/amd/amdgpu/amdgpu_discovery.c | 590 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c   |   6 -
 drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c   |   2 -
 drivers/gpu/drm/amd/amdgpu/amdgpu_sdma.c  |   9 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_sdma.h  |   2 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_ucode.c | 208 ++
 drivers/gpu/drm/amd/amdgpu/amdgpu_vcn.c   |  85 +--
 drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c| 180 +-
 drivers/gpu/drm/amd/amdgpu/gfx_v11_0.c|  64 +-
 drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c | 143 +
 drivers/gpu/drm/amd/amdgpu/mes_v10_1.c|  28 -
 drivers/gpu/drm/amd/amdgpu/mes_v11_0.c|  25 +-
 drivers/gpu/drm/amd/amdgpu/psp_v10_0.c| 106 +---
 drivers/gpu/drm/amd/amdgpu/psp_v11_0.c| 165 +
 drivers/gpu/drm/amd/amdgpu/psp_v12_0.c| 102 +--
 drivers/gpu/drm/amd/amdgpu/psp_v13_0.c|  82 ---
 drivers/gpu/drm/amd/amdgpu/psp_v13_0_4.c  |  36 --
 drivers/gpu/drm/amd/amdgpu/psp_v3_1.c |  36 --
 drivers/gpu/drm/amd/amdgpu/sdma_v4_0.c|  61 +-
 drivers/gpu/drm/amd/amdgpu/sdma_v5_0.c|  42 +-
 drivers/gpu/drm/amd/amdgpu/sdma_v5_2.c|  65 +-
 drivers/gpu/drm/amd/amdgpu/sdma_v6_0.c|  30 +-
 .../gpu/drm/amd/pm/swsmu/smu11/smu_v11_0.c|  35 +-
 .../gpu/drm/amd/pm/swsmu/smu13/smu_v13_0.c|  12 +-
 25 files changed, 919 insertions(+), 1203 deletions(-)


base-commit: de9a71e391a92841582ca3008e7b1

[PATCH 6.1 0760/1146] fbdev: uvesafb: dont build on UML

2022-12-28 Thread Greg Kroah-Hartman
From: Randy Dunlap 

[ Upstream commit 35b4f4d4a725cf8f8c10649163cd12aed509b953 ]

The uvesafb fbdev driver uses memory management information that is not
available on ARCH=um, so don't allow this driver to be built on UML.

Prevents these build errors:

../drivers/video/fbdev/uvesafb.c: In function ‘uvesafb_vbe_init’:
../drivers/video/fbdev/uvesafb.c:807:21: error: ‘__supported_pte_mask’ 
undeclared (first use in this function)
  807 | if (__supported_pte_mask & _PAGE_NX) {
../drivers/video/fbdev/uvesafb.c:807:44: error: ‘_PAGE_NX’ undeclared (first 
use in this function)
  807 | if (__supported_pte_mask & _PAGE_NX) {

Fixes: 68f5d3f3b654 ("um: add PCI over virtio emulation driver")
Signed-off-by: Randy Dunlap 
Cc: Johannes Berg 
Cc: Richard Weinberger 
Cc: linux...@lists.infradead.org
Cc: Daniel Vetter 
Cc: Helge Deller 
Cc: linux-fb...@vger.kernel.org
Cc: dri-devel@lists.freedesktop.org
Cc: Michal Januszewski 
Signed-off-by: Helge Deller 
Signed-off-by: Sasha Levin 
---
 drivers/video/fbdev/Kconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/video/fbdev/Kconfig b/drivers/video/fbdev/Kconfig
index 9497fe929162..974e862cd20d 100644
--- a/drivers/video/fbdev/Kconfig
+++ b/drivers/video/fbdev/Kconfig
@@ -601,6 +601,7 @@ config FB_TGA
 config FB_UVESA
tristate "Userspace VESA VGA graphics support"
depends on FB && CONNECTOR
+   depends on !UML
select FB_CFB_FILLRECT
select FB_CFB_COPYAREA
select FB_CFB_IMAGEBLIT
-- 
2.35.1





[PATCH 6.1 0759/1146] fbdev: geode: dont build on UML

2022-12-28 Thread Greg Kroah-Hartman
From: Randy Dunlap 

[ Upstream commit 71c53e19226b0166ba387d3c590d0509f541a0a1 ]

The geode fbdev driver uses struct cpuinfo fields that are not present
on ARCH=um, so don't allow this driver to be built on UML.

Prevents these build errors:

In file included from ../arch/x86/include/asm/olpc.h:7:0,
 from ../drivers/mfd/cs5535-mfd.c:17:
../arch/x86/include/asm/geode.h: In function ‘is_geode_gx’:
../arch/x86/include/asm/geode.h:16:24: error: ‘struct cpuinfo_um’ has no member 
named ‘x86_vendor’
  return ((boot_cpu_data.x86_vendor == X86_VENDOR_NSC) &&
../arch/x86/include/asm/geode.h:16:39: error: ‘X86_VENDOR_NSC’ undeclared 
(first use in this function); did you mean ‘X86_VENDOR_ANY’?
  return ((boot_cpu_data.x86_vendor == X86_VENDOR_NSC) &&
../arch/x86/include/asm/geode.h:17:17: error: ‘struct cpuinfo_um’ has no member 
named ‘x86’
   (boot_cpu_data.x86 == 5) &&
../arch/x86/include/asm/geode.h:18:17: error: ‘struct cpuinfo_um’ has no member 
named ‘x86_model’
   (boot_cpu_data.x86_model == 5));
../arch/x86/include/asm/geode.h: In function ‘is_geode_lx’:
../arch/x86/include/asm/geode.h:23:24: error: ‘struct cpuinfo_um’ has no member 
named ‘x86_vendor’
  return ((boot_cpu_data.x86_vendor == X86_VENDOR_AMD) &&
../arch/x86/include/asm/geode.h:23:39: error: ‘X86_VENDOR_AMD’ undeclared 
(first use in this function); did you mean ‘X86_VENDOR_ANY’?
  return ((boot_cpu_data.x86_vendor == X86_VENDOR_AMD) &&
../arch/x86/include/asm/geode.h:24:17: error: ‘struct cpuinfo_um’ has no member 
named ‘x86’
   (boot_cpu_data.x86 == 5) &&
../arch/x86/include/asm/geode.h:25:17: error: ‘struct cpuinfo_um’ has no member 
named ‘x86_model’
   (boot_cpu_data.x86_model == 10));

Fixes: 68f5d3f3b654 ("um: add PCI over virtio emulation driver")
Signed-off-by: Randy Dunlap 
Cc: Johannes Berg 
Cc: Richard Weinberger 
Cc: linux...@lists.infradead.org
Cc: Daniel Vetter 
Cc: Helge Deller 
Cc: linux-fb...@vger.kernel.org
Cc: dri-devel@lists.freedesktop.org
Cc: Andres Salomon 
Cc: linux-ge...@lists.infradead.org
Signed-off-by: Helge Deller 
Signed-off-by: Sasha Levin 
---
 drivers/video/fbdev/geode/Kconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/video/fbdev/geode/Kconfig 
b/drivers/video/fbdev/geode/Kconfig
index ac9c860592aa..85bc14b6faf6 100644
--- a/drivers/video/fbdev/geode/Kconfig
+++ b/drivers/video/fbdev/geode/Kconfig
@@ -5,6 +5,7 @@
 config FB_GEODE
bool "AMD Geode family framebuffer support"
depends on FB && PCI && (X86_32 || (X86 && COMPILE_TEST))
+   depends on !UML
help
  Say 'Y' here to allow you to select framebuffer drivers for
  the AMD Geode family of processors.
-- 
2.35.1





Re: [PATCH 12/13] drm/scheduler: rework entity flush, kill and fini

2022-12-28 Thread Rob Clark
On Thu, Nov 17, 2022 at 7:12 AM Dmitry Osipenko
 wrote:
>
> On 11/17/22 18:09, Christian König wrote:
> > Am 17.11.22 um 15:41 schrieb Dmitry Osipenko:
> >> [SNIP]
> >>> drm_sched_entity_flush() should be called from the flush callback from
> >>> the file_operations structure of panfrost. See amdgpu_flush() and
> >>> amdgpu_ctx_mgr_entity_flush(). This makes sure that we wait for all
> >>> entities of the process/file descriptor to be flushed out.
> >>>
> >>> drm_sched_entity_fini() must be called before you free the memory the
> >>> entity structure or otherwise we would run into an use after free.
> >> Right, drm_sched_entity_destroy() invokes these two functions and
> >> Panfrost uses drm_sched_entity_destroy().
> >
> > Than I have no idea what's going wrong here.
> >
> > The scheduler should trivially finish with the entity and call
> > complete(&entity->entity_idle) in it's main loop. No idea why this
> > doesn't happen. Can you investigate?
>
> I'll take a closer look. Hoped you may have a quick idea of what's wrong :)
>

As Jonathan mentioned, the same thing is happening on msm.  I can
reproduce this by adding an assert in mesa (in this case, triggered
after 100 draws) and running an app under gdb.  After the assert is
hit, if I try to exit mesa, it hangs.

The problem is that we somehow call drm_sched_entity_kill() twice.
The first time completes, but now the entity_idle completion is no
longer done, so the second call hangs forever.

BR,
-R


[PATCH 6.0 0735/1073] fbdev: uvesafb: dont build on UML

2022-12-28 Thread Greg Kroah-Hartman
From: Randy Dunlap 

[ Upstream commit 35b4f4d4a725cf8f8c10649163cd12aed509b953 ]

The uvesafb fbdev driver uses memory management information that is not
available on ARCH=um, so don't allow this driver to be built on UML.

Prevents these build errors:

../drivers/video/fbdev/uvesafb.c: In function ‘uvesafb_vbe_init’:
../drivers/video/fbdev/uvesafb.c:807:21: error: ‘__supported_pte_mask’ 
undeclared (first use in this function)
  807 | if (__supported_pte_mask & _PAGE_NX) {
../drivers/video/fbdev/uvesafb.c:807:44: error: ‘_PAGE_NX’ undeclared (first 
use in this function)
  807 | if (__supported_pte_mask & _PAGE_NX) {

Fixes: 68f5d3f3b654 ("um: add PCI over virtio emulation driver")
Signed-off-by: Randy Dunlap 
Cc: Johannes Berg 
Cc: Richard Weinberger 
Cc: linux...@lists.infradead.org
Cc: Daniel Vetter 
Cc: Helge Deller 
Cc: linux-fb...@vger.kernel.org
Cc: dri-devel@lists.freedesktop.org
Cc: Michal Januszewski 
Signed-off-by: Helge Deller 
Signed-off-by: Sasha Levin 
---
 drivers/video/fbdev/Kconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/video/fbdev/Kconfig b/drivers/video/fbdev/Kconfig
index 9497fe929162..974e862cd20d 100644
--- a/drivers/video/fbdev/Kconfig
+++ b/drivers/video/fbdev/Kconfig
@@ -601,6 +601,7 @@ config FB_TGA
 config FB_UVESA
tristate "Userspace VESA VGA graphics support"
depends on FB && CONNECTOR
+   depends on !UML
select FB_CFB_FILLRECT
select FB_CFB_COPYAREA
select FB_CFB_IMAGEBLIT
-- 
2.35.1





[PATCH 6.0 0734/1073] fbdev: geode: dont build on UML

2022-12-28 Thread Greg Kroah-Hartman
From: Randy Dunlap 

[ Upstream commit 71c53e19226b0166ba387d3c590d0509f541a0a1 ]

The geode fbdev driver uses struct cpuinfo fields that are not present
on ARCH=um, so don't allow this driver to be built on UML.

Prevents these build errors:

In file included from ../arch/x86/include/asm/olpc.h:7:0,
 from ../drivers/mfd/cs5535-mfd.c:17:
../arch/x86/include/asm/geode.h: In function ‘is_geode_gx’:
../arch/x86/include/asm/geode.h:16:24: error: ‘struct cpuinfo_um’ has no member 
named ‘x86_vendor’
  return ((boot_cpu_data.x86_vendor == X86_VENDOR_NSC) &&
../arch/x86/include/asm/geode.h:16:39: error: ‘X86_VENDOR_NSC’ undeclared 
(first use in this function); did you mean ‘X86_VENDOR_ANY’?
  return ((boot_cpu_data.x86_vendor == X86_VENDOR_NSC) &&
../arch/x86/include/asm/geode.h:17:17: error: ‘struct cpuinfo_um’ has no member 
named ‘x86’
   (boot_cpu_data.x86 == 5) &&
../arch/x86/include/asm/geode.h:18:17: error: ‘struct cpuinfo_um’ has no member 
named ‘x86_model’
   (boot_cpu_data.x86_model == 5));
../arch/x86/include/asm/geode.h: In function ‘is_geode_lx’:
../arch/x86/include/asm/geode.h:23:24: error: ‘struct cpuinfo_um’ has no member 
named ‘x86_vendor’
  return ((boot_cpu_data.x86_vendor == X86_VENDOR_AMD) &&
../arch/x86/include/asm/geode.h:23:39: error: ‘X86_VENDOR_AMD’ undeclared 
(first use in this function); did you mean ‘X86_VENDOR_ANY’?
  return ((boot_cpu_data.x86_vendor == X86_VENDOR_AMD) &&
../arch/x86/include/asm/geode.h:24:17: error: ‘struct cpuinfo_um’ has no member 
named ‘x86’
   (boot_cpu_data.x86 == 5) &&
../arch/x86/include/asm/geode.h:25:17: error: ‘struct cpuinfo_um’ has no member 
named ‘x86_model’
   (boot_cpu_data.x86_model == 10));

Fixes: 68f5d3f3b654 ("um: add PCI over virtio emulation driver")
Signed-off-by: Randy Dunlap 
Cc: Johannes Berg 
Cc: Richard Weinberger 
Cc: linux...@lists.infradead.org
Cc: Daniel Vetter 
Cc: Helge Deller 
Cc: linux-fb...@vger.kernel.org
Cc: dri-devel@lists.freedesktop.org
Cc: Andres Salomon 
Cc: linux-ge...@lists.infradead.org
Signed-off-by: Helge Deller 
Signed-off-by: Sasha Levin 
---
 drivers/video/fbdev/geode/Kconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/video/fbdev/geode/Kconfig 
b/drivers/video/fbdev/geode/Kconfig
index ac9c860592aa..85bc14b6faf6 100644
--- a/drivers/video/fbdev/geode/Kconfig
+++ b/drivers/video/fbdev/geode/Kconfig
@@ -5,6 +5,7 @@
 config FB_GEODE
bool "AMD Geode family framebuffer support"
depends on FB && PCI && (X86_32 || (X86 && COMPILE_TEST))
+   depends on !UML
help
  Say 'Y' here to allow you to select framebuffer drivers for
  the AMD Geode family of processors.
-- 
2.35.1





[PATCH 5.15 509/731] fbdev: uvesafb: dont build on UML

2022-12-28 Thread Greg Kroah-Hartman
From: Randy Dunlap 

[ Upstream commit 35b4f4d4a725cf8f8c10649163cd12aed509b953 ]

The uvesafb fbdev driver uses memory management information that is not
available on ARCH=um, so don't allow this driver to be built on UML.

Prevents these build errors:

../drivers/video/fbdev/uvesafb.c: In function ‘uvesafb_vbe_init’:
../drivers/video/fbdev/uvesafb.c:807:21: error: ‘__supported_pte_mask’ 
undeclared (first use in this function)
  807 | if (__supported_pte_mask & _PAGE_NX) {
../drivers/video/fbdev/uvesafb.c:807:44: error: ‘_PAGE_NX’ undeclared (first 
use in this function)
  807 | if (__supported_pte_mask & _PAGE_NX) {

Fixes: 68f5d3f3b654 ("um: add PCI over virtio emulation driver")
Signed-off-by: Randy Dunlap 
Cc: Johannes Berg 
Cc: Richard Weinberger 
Cc: linux...@lists.infradead.org
Cc: Daniel Vetter 
Cc: Helge Deller 
Cc: linux-fb...@vger.kernel.org
Cc: dri-devel@lists.freedesktop.org
Cc: Michal Januszewski 
Signed-off-by: Helge Deller 
Signed-off-by: Sasha Levin 
---
 drivers/video/fbdev/Kconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/video/fbdev/Kconfig b/drivers/video/fbdev/Kconfig
index 5050a9f8e879..26531aa19428 100644
--- a/drivers/video/fbdev/Kconfig
+++ b/drivers/video/fbdev/Kconfig
@@ -606,6 +606,7 @@ config FB_TGA
 config FB_UVESA
tristate "Userspace VESA VGA graphics support"
depends on FB && CONNECTOR
+   depends on !UML
select FB_CFB_FILLRECT
select FB_CFB_COPYAREA
select FB_CFB_IMAGEBLIT
-- 
2.35.1





[PATCH 5.15 508/731] fbdev: geode: dont build on UML

2022-12-28 Thread Greg Kroah-Hartman
From: Randy Dunlap 

[ Upstream commit 71c53e19226b0166ba387d3c590d0509f541a0a1 ]

The geode fbdev driver uses struct cpuinfo fields that are not present
on ARCH=um, so don't allow this driver to be built on UML.

Prevents these build errors:

In file included from ../arch/x86/include/asm/olpc.h:7:0,
 from ../drivers/mfd/cs5535-mfd.c:17:
../arch/x86/include/asm/geode.h: In function ‘is_geode_gx’:
../arch/x86/include/asm/geode.h:16:24: error: ‘struct cpuinfo_um’ has no member 
named ‘x86_vendor’
  return ((boot_cpu_data.x86_vendor == X86_VENDOR_NSC) &&
../arch/x86/include/asm/geode.h:16:39: error: ‘X86_VENDOR_NSC’ undeclared 
(first use in this function); did you mean ‘X86_VENDOR_ANY’?
  return ((boot_cpu_data.x86_vendor == X86_VENDOR_NSC) &&
../arch/x86/include/asm/geode.h:17:17: error: ‘struct cpuinfo_um’ has no member 
named ‘x86’
   (boot_cpu_data.x86 == 5) &&
../arch/x86/include/asm/geode.h:18:17: error: ‘struct cpuinfo_um’ has no member 
named ‘x86_model’
   (boot_cpu_data.x86_model == 5));
../arch/x86/include/asm/geode.h: In function ‘is_geode_lx’:
../arch/x86/include/asm/geode.h:23:24: error: ‘struct cpuinfo_um’ has no member 
named ‘x86_vendor’
  return ((boot_cpu_data.x86_vendor == X86_VENDOR_AMD) &&
../arch/x86/include/asm/geode.h:23:39: error: ‘X86_VENDOR_AMD’ undeclared 
(first use in this function); did you mean ‘X86_VENDOR_ANY’?
  return ((boot_cpu_data.x86_vendor == X86_VENDOR_AMD) &&
../arch/x86/include/asm/geode.h:24:17: error: ‘struct cpuinfo_um’ has no member 
named ‘x86’
   (boot_cpu_data.x86 == 5) &&
../arch/x86/include/asm/geode.h:25:17: error: ‘struct cpuinfo_um’ has no member 
named ‘x86_model’
   (boot_cpu_data.x86_model == 10));

Fixes: 68f5d3f3b654 ("um: add PCI over virtio emulation driver")
Signed-off-by: Randy Dunlap 
Cc: Johannes Berg 
Cc: Richard Weinberger 
Cc: linux...@lists.infradead.org
Cc: Daniel Vetter 
Cc: Helge Deller 
Cc: linux-fb...@vger.kernel.org
Cc: dri-devel@lists.freedesktop.org
Cc: Andres Salomon 
Cc: linux-ge...@lists.infradead.org
Signed-off-by: Helge Deller 
Signed-off-by: Sasha Levin 
---
 drivers/video/fbdev/geode/Kconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/video/fbdev/geode/Kconfig 
b/drivers/video/fbdev/geode/Kconfig
index ac9c860592aa..85bc14b6faf6 100644
--- a/drivers/video/fbdev/geode/Kconfig
+++ b/drivers/video/fbdev/geode/Kconfig
@@ -5,6 +5,7 @@
 config FB_GEODE
bool "AMD Geode family framebuffer support"
depends on FB && PCI && (X86_32 || (X86 && COMPILE_TEST))
+   depends on !UML
help
  Say 'Y' here to allow you to select framebuffer drivers for
  the AMD Geode family of processors.
-- 
2.35.1





[PATCH 6.1 0199/1146] drm/atomic-helper: Dont allocate new plane state in CRTC check

2022-12-28 Thread Greg Kroah-Hartman
From: Thomas Zimmermann 

[ Upstream commit dbbf933d365da1a76a540211bee3d57bde520194 ]

In drm_atomic_helper_check_crtc_state(), do not add a new plane state
to the global state if it does not exist already. Adding a new plane
state will result in overhead for the plane during the atomic-commit
step.

For the test in drm_atomic_helper_check_crtc_state() to succeed, it
is important that the CRTC has an enabled primary plane after the
commit. Simply testing the CRTC state's plane_mask for a primary plane
is sufficient.

Note that the helper still only tests for an attached primary plane.
Drivers have to ensure that the plane contains valid pixel information.

v5:
* fix commit description (Javier)
v3:
* test for a primary plane in plane_mask (Ville)
v2:
* remove unnecessary test for plane->crtc (Ville)
* inline drm_atomic_get_next_plane_state() (Ville)
* acquire plane lock before accessing plane->state (Ville)

Signed-off-by: Thomas Zimmermann 
Reviewed-by: Javier Martinez Canillas 
Fixes: d6b9af1097fe ("drm/atomic-helper: Add helper 
drm_atomic_helper_check_crtc_state()")
Cc: Thomas Zimmermann 
Cc: Jocelyn Falempe 
Cc: Maarten Lankhorst 
Cc: Maxime Ripard 
Cc: David Airlie 
Cc: Daniel Vetter 
Cc: dri-devel@lists.freedesktop.org
Link: 
https://patchwork.freedesktop.org/patch/msgid/20221007124338.24152-2-tzimmerm...@suse.de
Signed-off-by: Sasha Levin 
---
 drivers/gpu/drm/drm_atomic_helper.c | 10 +-
 1 file changed, 1 insertion(+), 9 deletions(-)

diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
b/drivers/gpu/drm/drm_atomic_helper.c
index 98cc3137c062..02b4a7dc92f5 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -945,7 +945,6 @@ int drm_atomic_helper_check_crtc_state(struct 
drm_crtc_state *crtc_state,
   bool can_disable_primary_planes)
 {
struct drm_device *dev = crtc_state->crtc->dev;
-   struct drm_atomic_state *state = crtc_state->state;
 
if (!crtc_state->enable)
return 0;
@@ -956,14 +955,7 @@ int drm_atomic_helper_check_crtc_state(struct 
drm_crtc_state *crtc_state,
struct drm_plane *plane;
 
drm_for_each_plane_mask(plane, dev, crtc_state->plane_mask) {
-   struct drm_plane_state *plane_state;
-
-   if (plane->type != DRM_PLANE_TYPE_PRIMARY)
-   continue;
-   plane_state = drm_atomic_get_plane_state(state, plane);
-   if (IS_ERR(plane_state))
-   return PTR_ERR(plane_state);
-   if (plane_state->fb && plane_state->crtc) {
+   if (plane->type == DRM_PLANE_TYPE_PRIMARY) {
has_primary_plane = true;
break;
}
-- 
2.35.1





[PATCH 6.0 0192/1073] drm/atomic-helper: Dont allocate new plane state in CRTC check

2022-12-28 Thread Greg Kroah-Hartman
From: Thomas Zimmermann 

[ Upstream commit dbbf933d365da1a76a540211bee3d57bde520194 ]

In drm_atomic_helper_check_crtc_state(), do not add a new plane state
to the global state if it does not exist already. Adding a new plane
state will result in overhead for the plane during the atomic-commit
step.

For the test in drm_atomic_helper_check_crtc_state() to succeed, it
is important that the CRTC has an enabled primary plane after the
commit. Simply testing the CRTC state's plane_mask for a primary plane
is sufficient.

Note that the helper still only tests for an attached primary plane.
Drivers have to ensure that the plane contains valid pixel information.

v5:
* fix commit description (Javier)
v3:
* test for a primary plane in plane_mask (Ville)
v2:
* remove unnecessary test for plane->crtc (Ville)
* inline drm_atomic_get_next_plane_state() (Ville)
* acquire plane lock before accessing plane->state (Ville)

Signed-off-by: Thomas Zimmermann 
Reviewed-by: Javier Martinez Canillas 
Fixes: d6b9af1097fe ("drm/atomic-helper: Add helper 
drm_atomic_helper_check_crtc_state()")
Cc: Thomas Zimmermann 
Cc: Jocelyn Falempe 
Cc: Maarten Lankhorst 
Cc: Maxime Ripard 
Cc: David Airlie 
Cc: Daniel Vetter 
Cc: dri-devel@lists.freedesktop.org
Link: 
https://patchwork.freedesktop.org/patch/msgid/20221007124338.24152-2-tzimmerm...@suse.de
Signed-off-by: Sasha Levin 
---
 drivers/gpu/drm/drm_atomic_helper.c | 10 +-
 1 file changed, 1 insertion(+), 9 deletions(-)

diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
b/drivers/gpu/drm/drm_atomic_helper.c
index 8bf41aa24068..6526d6ade04b 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -899,7 +899,6 @@ int drm_atomic_helper_check_crtc_state(struct 
drm_crtc_state *crtc_state,
   bool can_disable_primary_planes)
 {
struct drm_device *dev = crtc_state->crtc->dev;
-   struct drm_atomic_state *state = crtc_state->state;
 
if (!crtc_state->enable)
return 0;
@@ -910,14 +909,7 @@ int drm_atomic_helper_check_crtc_state(struct 
drm_crtc_state *crtc_state,
struct drm_plane *plane;
 
drm_for_each_plane_mask(plane, dev, crtc_state->plane_mask) {
-   struct drm_plane_state *plane_state;
-
-   if (plane->type != DRM_PLANE_TYPE_PRIMARY)
-   continue;
-   plane_state = drm_atomic_get_plane_state(state, plane);
-   if (IS_ERR(plane_state))
-   return PTR_ERR(plane_state);
-   if (plane_state->fb && plane_state->crtc) {
+   if (plane->type == DRM_PLANE_TYPE_PRIMARY) {
has_primary_plane = true;
break;
}
-- 
2.35.1





[REGRESSION] GM20B probe fails after commit 2541626cfb79

2022-12-28 Thread Diogo Ivo
Hello,

Commit 2541626cfb79 breaks GM20B probe with
the following kernel log:

[2.153892] [ cut here ]
[2.153897] WARNING: CPU: 1 PID: 36 at 
drivers/gpu/drm/nouveau/nvkm/subdev/mmu/vmmgf100.c:273 
gf100_vmm_valid+0x2c4/0x390
[2.153916] Modules linked in:
[2.153922] CPU: 1 PID: 36 Comm: kworker/u8:1 Not tainted 6.1.0+ #1
[2.153929] Hardware name: Google Pixel C (DT)
[2.153933] Workqueue: events_unbound deferred_probe_work_func
[2.153943] pstate: 8005 (Nzcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
[2.153950] pc : gf100_vmm_valid+0x2c4/0x390
[2.153959] lr : gf100_vmm_valid+0xb4/0x390
[2.153966] sp : ffc009e134b0
[2.153969] x29: ffc009e134b0 x28:  x27: ffc008fd44c8
[2.153979] x26: ffea x25: ffc0087b98d0 x24: ff8080f89038
[2.153987] x23: ff8081fadc08 x22:  x21: 
[2.153995] x20: ff8080f8a000 x19: ffc009e13678 x18: 
[2.154003] x17: f37a8b93418958e6 x16: ffc009f0d000 x15: 
[2.154011] x14: 0002 x13: 0003a020 x12: ffc00800
[2.154019] x11: 000102913000 x10:  x9 : 
[2.154026] x8 : ffc009e136d8 x7 : ffc008fd44c8 x6 : ff80803d0f00
[2.154034] x5 :  x4 : ff8080f88c00 x3 : 0010
[2.154041] x2 : 000c x1 : ffea x0 : ffea
[2.154050] Call trace:
[2.154053]  gf100_vmm_valid+0x2c4/0x390
[2.154061]  nvkm_vmm_map_valid+0xd4/0x204
[2.154069]  nvkm_vmm_map_locked+0xa4/0x344
[2.154076]  nvkm_vmm_map+0x50/0x84
[2.154083]  nvkm_firmware_mem_map+0x84/0xc4
[2.154094]  nvkm_falcon_fw_oneinit+0xc8/0x320
[2.154101]  nvkm_acr_oneinit+0x428/0x5b0
[2.154109]  nvkm_subdev_oneinit_+0x50/0x104
[2.154114]  nvkm_subdev_init_+0x3c/0x12c
[2.154119]  nvkm_subdev_init+0x60/0xa0
[2.154125]  nvkm_device_init+0x14c/0x2a0
[2.154133]  nvkm_udevice_init+0x60/0x9c
[2.154140]  nvkm_object_init+0x48/0x1b0
[2.154144]  nvkm_ioctl_new+0x168/0x254
[2.154149]  nvkm_ioctl+0xd0/0x220
[2.154153]  nvkm_client_ioctl+0x10/0x1c
[2.154162]  nvif_object_ctor+0xf4/0x22c
[2.154168]  nvif_device_ctor+0x28/0x70
[2.154174]  nouveau_cli_init+0x150/0x590
[2.154180]  nouveau_drm_device_init+0x60/0x2a0
[2.154187]  nouveau_platform_device_create+0x90/0xd0
[2.154193]  nouveau_platform_probe+0x3c/0x9c
[2.154200]  platform_probe+0x68/0xc0
[2.154207]  really_probe+0xbc/0x2dc
[2.154211]  __driver_probe_device+0x78/0xe0
[2.154216]  driver_probe_device+0xd8/0x160
[2.154221]  __device_attach_driver+0xb8/0x134
[2.154226]  bus_for_each_drv+0x78/0xd0
[2.154230]  __device_attach+0x9c/0x1a0
[2.154234]  device_initial_probe+0x14/0x20
[2.154239]  bus_probe_device+0x98/0xa0
[2.154243]  deferred_probe_work_func+0x88/0xc0
[2.154247]  process_one_work+0x204/0x40c
[2.154256]  worker_thread+0x230/0x450
[2.154261]  kthread+0xc8/0xcc
[2.154266]  ret_from_fork+0x10/0x20
[2.154273] ---[ end trace  ]---
[2.154278] nouveau 5700.gpu: pmu: map -22
[2.154285] nouveau 5700.gpu: acr: one-time init failed, -22
[2.154559] nouveau 5700.gpu: init failed with -22
[2.154564] nouveau: DRM-master::0080: init failed with -22
[2.154574] nouveau 5700.gpu: DRM-master: Device allocation failed: -22
[2.162905] nouveau: probe of 5700.gpu failed with error -22

#regzbot introduced: 2541626cfb79

Thanks,

Diogo Ivo


Re: [PATCH] drm/v3d: replace open-coded implementation of drm_gem_object_lookup

2022-12-28 Thread Melissa Wen
On 12/27, Maíra Canal wrote:
> As v3d_submit_tfu_ioctl() performs the same steps as drm_gem_object_lookup(),
> replace the open-code implementation in v3d with its DRM core equivalent.
> 
> Signed-off-by: Maíra Canal 
> ---
>  drivers/gpu/drm/v3d/v3d_gem.c | 7 +--
>  1 file changed, 1 insertion(+), 6 deletions(-)
> 
> diff --git a/drivers/gpu/drm/v3d/v3d_gem.c b/drivers/gpu/drm/v3d/v3d_gem.c
> index 6e152ef26358..5da1806f3969 100644
> --- a/drivers/gpu/drm/v3d/v3d_gem.c
> +++ b/drivers/gpu/drm/v3d/v3d_gem.c
> @@ -861,7 +861,6 @@ v3d_submit_tfu_ioctl(struct drm_device *dev, void *data,
>  
>   job->args = *args;
>  
> - spin_lock(&file_priv->table_lock);
>   for (job->base.bo_count = 0;
>job->base.bo_count < ARRAY_SIZE(args->bo_handles);
>job->base.bo_count++) {
> @@ -870,20 +869,16 @@ v3d_submit_tfu_ioctl(struct drm_device *dev, void *data,
>   if (!args->bo_handles[job->base.bo_count])
>   break;
>  
> - bo = idr_find(&file_priv->object_idr,
> -   args->bo_handles[job->base.bo_count]);
> + bo = drm_gem_object_lookup(file_priv, 
> args->bo_handles[job->base.bo_count]);
>   if (!bo) {
>   DRM_DEBUG("Failed to look up GEM BO %d: %d\n",
> job->base.bo_count,
> args->bo_handles[job->base.bo_count]);
>   ret = -ENOENT;
> - spin_unlock(&file_priv->table_lock);
>   goto fail;
>   }
> - drm_gem_object_get(bo);
>   job->base.bo[job->base.bo_count] = bo;
>   }
> - spin_unlock(&file_priv->table_lock);

Hi Maíra,

Thanks for you patch.

LGTM

Reviewed-by: Melissa Wen 

>  
>   ret = v3d_lock_bo_reservations(&job->base, &acquire_ctx);
>   if (ret)
> -- 
> 2.38.1
> 


signature.asc
Description: PGP signature


Re: [PATCH] drm/tegra: submit: No need for Null pointer check before kfree

2022-12-28 Thread Deepak R Varma
On Wed, Dec 28, 2022 at 03:48:05PM +0200, Mikko Perttunen wrote:
> On 12/28/22 15:34, Deepak R Varma wrote:
> > On Wed, Dec 28, 2022 at 03:17:59PM +0200, Mikko Perttunen wrote:
> > > On 12/28/22 15:08, Deepak R Varma wrote:
> > >
> > > Hi,
> > >
> > > it gets rid of visual hints on code paths indicating the possible liveness
> > > of pointer variables. I.e., after the change, whether the pointer can be
> > > NULL or not is more difficult to reason about locally, instead requiring
> > > more global reasoning which is mentally more taxing.
> > >
> > > Since C's type system doesn't help with tracking these kinds of things, I
> > > believe it is important to have these kinds of local contextual cues to 
> > > help
> > > the programmer.
> >
> > Hello Mikko,
> > That really helps. Thank you for the detailed explanation. I do have an 
> > extended
> > question though. In this context, when we are ready to release the memory, 
> > how
> > is it useful to know if it is NULL or not this late in the flow when the 
> > scope
> > is about to end?
>
> In the current code it doesn't matter, but if someone went to change this
> code (for example to add another release step), and we just had
> 'kfree(job_data)', they would have to remember that kfree works with NULL
> pointers, and would have to go looking elsewhere in the code to see if it is
> in fact possible to assume that job_data cannot be NULL here, or not. If
> they forget about kfree working with NULL pointers, which wouldn't be that
> surprising since it is almost always only called with non-NULL pointers,
> they might instead introduce a bug.
>
> In this particular instance it's probably not that bad since immediately
> above we have another 'if' block that checks if job_data is NULL, which
> serves as a hint to the programmer; however, as a general principle it
> stands that having the NULL check here makes it obvious to any reading
> programmer that they any changes they make have to consider if the pointer
> is NULL or not.

Sounds good. Thanks again. Would like to see if other experts have any further
guidance on this patch.

Regards,
./drv

>
> >
> > > Mikko
> >
> >
>




Re: [PATCH v3 0/3] Add generic framebuffer support to EFI earlycon driver

2022-12-28 Thread Andy Shevchenko
On Fri, Dec 23, 2022 at 03:42:33PM +0100, Ard Biesheuvel wrote:
> (cc Andy)

I believe there are two reasons I'm Cc'ed now:
- the Cc was forgotten. because I remember reviewing some parts
  of this contribution
- this conflicts (to some extent) with my patch that speeds up
  the scrolling

For the first it's obvious what to do, I think Markuss can include me
in his v4.

For the second I don't see the functional clash. The scrolling in this
series is not anyhow optimized. I think my patch should go first as
- it is less intrusive
- it has been tested, or can be tested easily

Tell me if I'm missing something here.

> On Wed, 21 Dec 2022 at 11:54, Markuss Broks  wrote:
> >
> > Make the EFI earlycon driver be suitable for any linear framebuffers.
> > This should be helpful for early porting of boards with no other means of
> > output, like smartphones/tablets. There seems to be an issue with 
> > early_ioremap
> > function on ARM32, but I am unable to find the exact cause. It appears the 
> > mappings
> > returned by it are somehow incorrect, thus the driver is disabled on ARM.
> 
> The reason that this driver is disabled on ARM is because the struct
> screen_info is not populated early enough, as it is retrieved from a
> UEFI configuration table.
> 
> early_ioremap() works fine on ARM as long as they mapping is torn down
> before paging_init()
> 
> > EFI early
> > console was disabled on IA64 previously because of missing 
> > early_memremap_prot,
> > and this is inherited to this driver.
> >
> > This patch also changes
> 
> "This patch also changes ..." is usually a strong hint to self that
> the patches need to be split up.
> 
> > behavior on EFI systems, by selecting the mapping type
> > based on if the framebuffer region intersects with system RAM. If it does, 
> > it's
> > common sense that it should be in RAM as a whole, and so the system RAM 
> > mapping is
> > used. It was tested to be working on my PC (Intel Z490 platform), as well 
> > as several
> > ARM64 boards (Samsung Galaxy S9 (Exynos), iPad Air 2, Xiaomi Mi Pad 4, ...).

-- 
With Best Regards,
Andy Shevchenko




Re: [PATCH] drm/tegra: submit: No need for Null pointer check before kfree

2022-12-28 Thread Mikko Perttunen

On 12/28/22 15:34, Deepak R Varma wrote:

On Wed, Dec 28, 2022 at 03:17:59PM +0200, Mikko Perttunen wrote:

On 12/28/22 15:08, Deepak R Varma wrote:

On Wed, Dec 28, 2022 at 02:28:54PM +0200, Mikko Perttunen wrote:

On 12/27/22 19:14, Deepak R Varma wrote:

kfree() & vfree() internally perform NULL check on the pointer handed
to it and take no action if it indeed is NULL. Hence there is no need
for a pre-check of the memory pointer before handing it to
kfree()/vfree().

Issue reported by ifnullfree.cocci Coccinelle semantic patch script.

Signed-off-by: Deepak R Varma 
---
drivers/gpu/drm/tegra/submit.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/tegra/submit.c b/drivers/gpu/drm/tegra/submit.c
index 066f88564169..06f836db99d0 100644
--- a/drivers/gpu/drm/tegra/submit.c
+++ b/drivers/gpu/drm/tegra/submit.c
@@ -680,8 +680,8 @@ int tegra_drm_ioctl_channel_submit(struct drm_device *drm, 
void *data,
kfree(job_data->used_mappings);
}

-   if (job_data)
-   kfree(job_data);
+   kfree(job_data);
+
put_bo:
gather_bo_put(&bo->base);
unlock:
--
2.34.1





It continues to be the case that I think this transform is bad. Same applies
to the host1x patch.


Hello Mikko,
Thank you for responding to the patch proposal. Could you please explain why is
this bad?

Regards,
./drv



Mikko





Hi,

it gets rid of visual hints on code paths indicating the possible liveness
of pointer variables. I.e., after the change, whether the pointer can be
NULL or not is more difficult to reason about locally, instead requiring
more global reasoning which is mentally more taxing.

Since C's type system doesn't help with tracking these kinds of things, I
believe it is important to have these kinds of local contextual cues to help
the programmer.


Hello Mikko,
That really helps. Thank you for the detailed explanation. I do have an extended
question though. In this context, when we are ready to release the memory, how
is it useful to know if it is NULL or not this late in the flow when the scope
is about to end?


In the current code it doesn't matter, but if someone went to change 
this code (for example to add another release step), and we just had 
'kfree(job_data)', they would have to remember that kfree works with 
NULL pointers, and would have to go looking elsewhere in the code to see 
if it is in fact possible to assume that job_data cannot be NULL here, 
or not. If they forget about kfree working with NULL pointers, which 
wouldn't be that surprising since it is almost always only called with 
non-NULL pointers, they might instead introduce a bug.


In this particular instance it's probably not that bad since immediately 
above we have another 'if' block that checks if job_data is NULL, which 
serves as a hint to the programmer; however, as a general principle it 
stands that having the NULL check here makes it obvious to any reading 
programmer that they any changes they make have to consider if the 
pointer is NULL or not.




Thanks again!
./drv



Thanks!
Mikko







Mikko







Re: [PATCH] drm/tegra: submit: No need for Null pointer check before kfree

2022-12-28 Thread Deepak R Varma
On Wed, Dec 28, 2022 at 03:17:59PM +0200, Mikko Perttunen wrote:
> On 12/28/22 15:08, Deepak R Varma wrote:
> > On Wed, Dec 28, 2022 at 02:28:54PM +0200, Mikko Perttunen wrote:
> > > On 12/27/22 19:14, Deepak R Varma wrote:
> > > > kfree() & vfree() internally perform NULL check on the pointer handed
> > > > to it and take no action if it indeed is NULL. Hence there is no need
> > > > for a pre-check of the memory pointer before handing it to
> > > > kfree()/vfree().
> > > >
> > > > Issue reported by ifnullfree.cocci Coccinelle semantic patch script.
> > > >
> > > > Signed-off-by: Deepak R Varma 
> > > > ---
> > > >drivers/gpu/drm/tegra/submit.c | 4 ++--
> > > >1 file changed, 2 insertions(+), 2 deletions(-)
> > > >
> > > > diff --git a/drivers/gpu/drm/tegra/submit.c 
> > > > b/drivers/gpu/drm/tegra/submit.c
> > > > index 066f88564169..06f836db99d0 100644
> > > > --- a/drivers/gpu/drm/tegra/submit.c
> > > > +++ b/drivers/gpu/drm/tegra/submit.c
> > > > @@ -680,8 +680,8 @@ int tegra_drm_ioctl_channel_submit(struct 
> > > > drm_device *drm, void *data,
> > > > kfree(job_data->used_mappings);
> > > > }
> > > >
> > > > -   if (job_data)
> > > > -   kfree(job_data);
> > > > +   kfree(job_data);
> > > > +
> > > >put_bo:
> > > > gather_bo_put(&bo->base);
> > > >unlock:
> > > > --
> > > > 2.34.1
> > > >
> > > >
> > > >
> > >
> > > It continues to be the case that I think this transform is bad. Same 
> > > applies
> > > to the host1x patch.
> >
> > Hello Mikko,
> > Thank you for responding to the patch proposal. Could you please explain 
> > why is
> > this bad?
> >
> > Regards,
> > ./drv
> >
> > >
> > > Mikko
> >
> >
>
> Hi,
>
> it gets rid of visual hints on code paths indicating the possible liveness
> of pointer variables. I.e., after the change, whether the pointer can be
> NULL or not is more difficult to reason about locally, instead requiring
> more global reasoning which is mentally more taxing.
>
> Since C's type system doesn't help with tracking these kinds of things, I
> believe it is important to have these kinds of local contextual cues to help
> the programmer.

Hello Mikko,
That really helps. Thank you for the detailed explanation. I do have an extended
question though. In this context, when we are ready to release the memory, how
is it useful to know if it is NULL or not this late in the flow when the scope
is about to end?

Thanks again!
./drv




>
> Mikko




Re: [PATCH] drm/tegra: submit: No need for Null pointer check before kfree

2022-12-28 Thread Mikko Perttunen

On 12/28/22 15:08, Deepak R Varma wrote:

On Wed, Dec 28, 2022 at 02:28:54PM +0200, Mikko Perttunen wrote:

On 12/27/22 19:14, Deepak R Varma wrote:

kfree() & vfree() internally perform NULL check on the pointer handed
to it and take no action if it indeed is NULL. Hence there is no need
for a pre-check of the memory pointer before handing it to
kfree()/vfree().

Issue reported by ifnullfree.cocci Coccinelle semantic patch script.

Signed-off-by: Deepak R Varma 
---
   drivers/gpu/drm/tegra/submit.c | 4 ++--
   1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/tegra/submit.c b/drivers/gpu/drm/tegra/submit.c
index 066f88564169..06f836db99d0 100644
--- a/drivers/gpu/drm/tegra/submit.c
+++ b/drivers/gpu/drm/tegra/submit.c
@@ -680,8 +680,8 @@ int tegra_drm_ioctl_channel_submit(struct drm_device *drm, 
void *data,
kfree(job_data->used_mappings);
}

-   if (job_data)
-   kfree(job_data);
+   kfree(job_data);
+
   put_bo:
gather_bo_put(&bo->base);
   unlock:
--
2.34.1





It continues to be the case that I think this transform is bad. Same applies
to the host1x patch.


Hello Mikko,
Thank you for responding to the patch proposal. Could you please explain why is
this bad?

Regards,
./drv



Mikko





Hi,

it gets rid of visual hints on code paths indicating the possible 
liveness of pointer variables. I.e., after the change, whether the 
pointer can be NULL or not is more difficult to reason about locally, 
instead requiring more global reasoning which is mentally more taxing.


Since C's type system doesn't help with tracking these kinds of things, 
I believe it is important to have these kinds of local contextual cues 
to help the programmer.


Mikko


[PATCH v2 1/1] dt-bindings: msm: dsi-phy-28nm: Add missing qcom, dsi-phy-regulator-ldo-mode

2022-12-28 Thread Bryan O'Donoghue
Add in missing qcom,dsi-phy-regulator-ldo-mode to the 28nm DSI PHY.
When converting from .txt to .yaml we missed this one.

Fixes: 4dbe55c97741 ("dt-bindings: msm: dsi: add yaml schemas for DSI bindings")
Reviewed-by: Dmitry Baryshkov 
Signed-off-by: Bryan O'Donoghue 
---
 .../devicetree/bindings/display/msm/dsi-phy-28nm.yaml | 4 
 1 file changed, 4 insertions(+)

diff --git a/Documentation/devicetree/bindings/display/msm/dsi-phy-28nm.yaml 
b/Documentation/devicetree/bindings/display/msm/dsi-phy-28nm.yaml
index 3d8540a06fe22..95076c90ea171 100644
--- a/Documentation/devicetree/bindings/display/msm/dsi-phy-28nm.yaml
+++ b/Documentation/devicetree/bindings/display/msm/dsi-phy-28nm.yaml
@@ -25,6 +25,10 @@ properties:
   - description: dsi phy register set
   - description: dsi phy regulator register set
 
+  qcom,dsi-phy-regulator-ldo-mode:
+type: boolean
+description: Indicates if the LDO mode PHY regulator is wanted.
+
   reg-names:
 items:
   - const: dsi_pll
-- 
2.34.1



[PATCH v2 0/1] Fixup documentation for dsi-phy-28nm

2022-12-28 Thread Bryan O'Donoghue
This is the one remaining patch I had from a previous series for
mdss-dsi-ctrl and the dsi-phy. The mdss-dsi-ctrl set became a bigger so I
split out the 28nm phy fixes.

I'm resubmitting with Dmitry's RB as a standalone.

Old: 
https://lore.kernel.org/all/20220630120845.3356144-1-bryan.odonog...@linaro.org/

Bryan O'Donoghue (1):
  dt-bindings: msm: dsi-phy-28nm: Add missing
qcom,dsi-phy-regulator-ldo-mode

 .../devicetree/bindings/display/msm/dsi-phy-28nm.yaml | 4 
 1 file changed, 4 insertions(+)

-- 
2.34.1



Re: [PATCH] drm/tegra: submit: No need for Null pointer check before kfree

2022-12-28 Thread Deepak R Varma
On Wed, Dec 28, 2022 at 02:28:54PM +0200, Mikko Perttunen wrote:
> On 12/27/22 19:14, Deepak R Varma wrote:
> > kfree() & vfree() internally perform NULL check on the pointer handed
> > to it and take no action if it indeed is NULL. Hence there is no need
> > for a pre-check of the memory pointer before handing it to
> > kfree()/vfree().
> >
> > Issue reported by ifnullfree.cocci Coccinelle semantic patch script.
> >
> > Signed-off-by: Deepak R Varma 
> > ---
> >   drivers/gpu/drm/tegra/submit.c | 4 ++--
> >   1 file changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/tegra/submit.c b/drivers/gpu/drm/tegra/submit.c
> > index 066f88564169..06f836db99d0 100644
> > --- a/drivers/gpu/drm/tegra/submit.c
> > +++ b/drivers/gpu/drm/tegra/submit.c
> > @@ -680,8 +680,8 @@ int tegra_drm_ioctl_channel_submit(struct drm_device 
> > *drm, void *data,
> > kfree(job_data->used_mappings);
> > }
> >
> > -   if (job_data)
> > -   kfree(job_data);
> > +   kfree(job_data);
> > +
> >   put_bo:
> > gather_bo_put(&bo->base);
> >   unlock:
> > --
> > 2.34.1
> >
> >
> >
>
> It continues to be the case that I think this transform is bad. Same applies
> to the host1x patch.

Hello Mikko,
Thank you for responding to the patch proposal. Could you please explain why is
this bad?

Regards,
./drv

>
> Mikko




Re: [PATCH] drm/tegra: submit: No need for Null pointer check before kfree

2022-12-28 Thread Mikko Perttunen

On 12/27/22 19:14, Deepak R Varma wrote:

kfree() & vfree() internally perform NULL check on the pointer handed
to it and take no action if it indeed is NULL. Hence there is no need
for a pre-check of the memory pointer before handing it to
kfree()/vfree().

Issue reported by ifnullfree.cocci Coccinelle semantic patch script.

Signed-off-by: Deepak R Varma 
---
  drivers/gpu/drm/tegra/submit.c | 4 ++--
  1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/tegra/submit.c b/drivers/gpu/drm/tegra/submit.c
index 066f88564169..06f836db99d0 100644
--- a/drivers/gpu/drm/tegra/submit.c
+++ b/drivers/gpu/drm/tegra/submit.c
@@ -680,8 +680,8 @@ int tegra_drm_ioctl_channel_submit(struct drm_device *drm, 
void *data,
kfree(job_data->used_mappings);
}

-   if (job_data)
-   kfree(job_data);
+   kfree(job_data);
+
  put_bo:
gather_bo_put(&bo->base);
  unlock:
--
2.34.1





It continues to be the case that I think this transform is bad. Same 
applies to the host1x patch.


Mikko


Re: [PATCH 03/14] drm/panel-sitronix-st7703: Drop custom DSI write macros

2022-12-28 Thread Guido Günther
Hi Javier,
Could you please also cc maintainers on the actual macro addition since
it's hard to review without seeing what the code gets changed to
(especially when there's multiple revisions). I assume

   
https://lore.kernel.org/dri-devel/20221228014757.3170486-2-javi...@redhat.com/

is the right one?
Cheers,
 -- Guido

On Wed, Dec 28, 2022 at 02:47:46AM +0100, Javier Martinez Canillas wrote:
> There are macros for these already in the  header, use
> that instead and delete the custom DSI write macros defined in the driver.
> 
> Signed-off-by: Javier Martinez Canillas 
> ---
> 
>  drivers/gpu/drm/panel/panel-sitronix-st7703.c | 83 ---
>  1 file changed, 33 insertions(+), 50 deletions(-)
> 
> diff --git a/drivers/gpu/drm/panel/panel-sitronix-st7703.c 
> b/drivers/gpu/drm/panel/panel-sitronix-st7703.c
> index 86a472b01360..3e6655c2727e 100644
> --- a/drivers/gpu/drm/panel/panel-sitronix-st7703.c
> +++ b/drivers/gpu/drm/panel/panel-sitronix-st7703.c
> @@ -73,14 +73,6 @@ static inline struct st7703 *panel_to_st7703(struct 
> drm_panel *panel)
>   return container_of(panel, struct st7703, panel);
>  }
>  
> -#define dsi_generic_write_seq(dsi, seq...) do {  
> \
> - static const u8 d[] = { seq };  \
> - int ret;\
> - ret = mipi_dsi_generic_write(dsi, d, ARRAY_SIZE(d));\
> - if (ret < 0)\
> - return ret; \
> - } while (0)
> -
>  static int jh057n_init_sequence(struct st7703 *ctx)
>  {
>   struct mipi_dsi_device *dsi = to_mipi_dsi_device(ctx->dev);
> @@ -90,27 +82,27 @@ static int jh057n_init_sequence(struct st7703 *ctx)
>* resemble the ST7703 but the number of parameters often don't match
>* so it's likely a clone.
>*/
> - dsi_generic_write_seq(dsi, ST7703_CMD_SETEXTC,
> + mipi_dsi_generic_write_seq(dsi, ST7703_CMD_SETEXTC,
> 0xF1, 0x12, 0x83);
> - dsi_generic_write_seq(dsi, ST7703_CMD_SETRGBIF,
> + mipi_dsi_generic_write_seq(dsi, ST7703_CMD_SETRGBIF,
> 0x10, 0x10, 0x05, 0x05, 0x03, 0xFF, 0x00, 0x00,
> 0x00, 0x00);
> - dsi_generic_write_seq(dsi, ST7703_CMD_SETSCR,
> + mipi_dsi_generic_write_seq(dsi, ST7703_CMD_SETSCR,
> 0x73, 0x73, 0x50, 0x50, 0x00, 0x00, 0x08, 0x70,
> 0x00);
> - dsi_generic_write_seq(dsi, ST7703_CMD_SETVDC, 0x4E);
> - dsi_generic_write_seq(dsi, ST7703_CMD_SETPANEL, 0x0B);
> - dsi_generic_write_seq(dsi, ST7703_CMD_SETCYC, 0x80);
> - dsi_generic_write_seq(dsi, ST7703_CMD_SETDISP, 0xF0, 0x12, 0x30);
> - dsi_generic_write_seq(dsi, ST7703_CMD_SETEQ,
> + mipi_dsi_generic_write_seq(dsi, ST7703_CMD_SETVDC, 0x4E);
> + mipi_dsi_generic_write_seq(dsi, ST7703_CMD_SETPANEL, 0x0B);
> + mipi_dsi_generic_write_seq(dsi, ST7703_CMD_SETCYC, 0x80);
> + mipi_dsi_generic_write_seq(dsi, ST7703_CMD_SETDISP, 0xF0, 0x12, 0x30);
> + mipi_dsi_generic_write_seq(dsi, ST7703_CMD_SETEQ,
> 0x07, 0x07, 0x0B, 0x0B, 0x03, 0x0B, 0x00, 0x00,
> 0x00, 0x00, 0xFF, 0x00, 0xC0, 0x10);
> - dsi_generic_write_seq(dsi, ST7703_CMD_SETBGP, 0x08, 0x08);
> + mipi_dsi_generic_write_seq(dsi, ST7703_CMD_SETBGP, 0x08, 0x08);
>   msleep(20);
>  
> - dsi_generic_write_seq(dsi, ST7703_CMD_SETVCOM, 0x3F, 0x3F);
> - dsi_generic_write_seq(dsi, ST7703_CMD_UNKNOWN_BF, 0x02, 0x11, 0x00);
> - dsi_generic_write_seq(dsi, ST7703_CMD_SETGIP1,
> + mipi_dsi_generic_write_seq(dsi, ST7703_CMD_SETVCOM, 0x3F, 0x3F);
> + mipi_dsi_generic_write_seq(dsi, ST7703_CMD_UNKNOWN_BF, 0x02, 0x11, 
> 0x00);
> + mipi_dsi_generic_write_seq(dsi, ST7703_CMD_SETGIP1,
> 0x82, 0x10, 0x06, 0x05, 0x9E, 0x0A, 0xA5, 0x12,
> 0x31, 0x23, 0x37, 0x83, 0x04, 0xBC, 0x27, 0x38,
> 0x0C, 0x00, 0x03, 0x00, 0x00, 0x00, 0x0C, 0x00,
> @@ -119,7 +111,7 @@ static int jh057n_init_sequence(struct st7703 *ctx)
> 0x64, 0x20, 0x88, 0x88, 0x88, 0x88, 0x88, 0x88,
> 0x02, 0x88, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
> 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00);
> - dsi_generic_write_seq(dsi, ST7703_CMD_SETGIP2,
> + mipi_dsi_generic_write_seq(dsi, ST7703_CMD_SETGIP2,
> 0x02, 0x21, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
> 0x00, 0x00, 0x00, 0x00, 0x02, 0x46, 0x02, 0x88,
> 0x88, 0x88, 0x88, 0x88, 0x88, 0x64, 0x88, 0x13,
> @@ -128,7 +120,7 @@ static int jh057n_init_sequence(struct st7703 *ctx)
> 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
>

Re: WARNING: CPU: 2 PID: 42 at drivers/gpu/drm/drm_modeset_lock.c:276

2022-12-28 Thread Stefan Wahren

Hi,

Am 21.12.22 um 20:46 schrieb Stefan Wahren:

Hi,

if i enable PROVE_LOCKING on the Raspberry Pi 3 B+ 
(arm/multi_v7_defconfig) using v6.1 (didn't test older versions) i'm 
getting the following warning:


[  204.043396] WARNING: CPU: 2 PID: 42 at 
drivers/gpu/drm/drm_modeset_lock.c:276 drm_modeset_drop_locks+0x6c/0x70
[  204.043426] Modules linked in: aes_arm aes_generic cmac 
bcm2835_v4l2(C) bcm2835_mmal_vchiq(C) videobuf2_vmalloc 
videobuf2_memops videobuf2_v4l2 videobuf2_common videodev mc 
snd_bcm2835(C) crc32_arm_ce brcmfmac brcmutil vc4 snd_soc_hdmi_codec 
sha256_generic libsha256 snd_soc_core ac97_bus snd_pcm_dmaengine 
snd_pcm sha256_arm snd_timer cfg80211 onboard_usb_hub snd hci_uart 
raspberrypi_hwmon soundcore drm_dma_helper btbcm bluetooth 
ecdh_generic bcm2835_thermal ecc libaes vchiq(C) microchip lan78xx
[  204.043820] CPU: 2 PID: 42 Comm: kworker/2:1 Tainted: G C 
6.1.0-7-g22fada783b9f #31

[  204.043833] Hardware name: BCM2835
[  204.043842] Workqueue: events output_poll_execute
[  204.043866]  unwind_backtrace from show_stack+0x10/0x14
[  204.043886]  show_stack from dump_stack_lvl+0x58/0x70
[  204.043903]  dump_stack_lvl from __warn+0xc8/0x1e8
[  204.043920]  __warn from warn_slowpath_fmt+0x5c/0xb8
[  204.043936]  warn_slowpath_fmt from drm_modeset_drop_locks+0x6c/0x70
[  204.043952]  drm_modeset_drop_locks from 
drm_helper_probe_detect_ctx+0xd4/0x124
[  204.043969]  drm_helper_probe_detect_ctx from 
output_poll_execute+0x154/0x230

[  204.043986]  output_poll_execute from process_one_work+0x288/0x708
[  204.044004]  process_one_work from worker_thread+0x54/0x50c
[  204.044020]  worker_thread from kthread+0xe8/0x104
[  204.044034]  kthread from ret_from_fork+0x14/0x2c
[  204.044048] Exception stack(0xf0915fb0 to 0xf0915ff8)
[  204.044059] 5fa0:  
  
[  204.044070] 5fc0:      
  
[  204.044080] 5fe0:     0013 


[  204.044090] irq event stamp: 33189
[  204.044100] hardirqs last  enabled at (33195): [] 
__up_console_sem+0x50/0x60
[  204.044120] hardirqs last disabled at (33200): [] 
__up_console_sem+0x3c/0x60
[  204.044136] softirqs last  enabled at (32836): [] 
process_one_work+0x288/0x708
[  204.044152] softirqs last disabled at (32832): [] 
neigh_managed_work+0x18/0xa4

[  204.044168] ---[ end trace  ]---


here are my intermediate results. I'm stuck during bisecting. For the 
skipped steps either vc4 throw compile errors or X doesn't come up 
(display goes black before X and says no connection).


$ git bisect log
git bisect start
# good: [4fe89d07dcc2804c8b562f6c7896a45643d34b2f] Linux 6.0
git bisect good 4fe89d07dcc2804c8b562f6c7896a45643d34b2f
# bad: [33e591dee915832c618cf68bb1058c8e7d296128] Merge tag 
'phy-for-6.1' of git://git.kernel.org/pub/scm/linux/kernel/git/phy/linux-phy

git bisect bad 33e591dee915832c618cf68bb1058c8e7d296128
# good: [a47e60729d9624e931f988709ab76e043e2ee8b9] Merge tag 
'backlight-next-6.1' of 
git://git.kernel.org/pub/scm/linux/kernel/git/lee/backlight

git bisect good a47e60729d9624e931f988709ab76e043e2ee8b9
# bad: [ff6862c23d2e83d12d1759bf4337d41248fb4dc8] Merge tag 
'arm-drivers-6.1' of git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc

git bisect bad ff6862c23d2e83d12d1759bf4337d41248fb4dc8
# good: [95d8c67187bcfaa519bafcdef9091cd906505454] Merge tag 
'drm-msm-next-2022-09-22' of https://gitlab.freedesktop.org/drm/msm into 
drm-next

git bisect good 95d8c67187bcfaa519bafcdef9091cd906505454
# good: [86a4d29e75540e20f991e72f17aa51d0e775a397] Merge tag 'asoc-v6.1' 
of https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound into 
for-linus

git bisect good 86a4d29e75540e20f991e72f17aa51d0e775a397
# bad: [65898687cf7392c372ea8d04a88617e2cb794465] Merge tag 
'amd-drm-next-6.1-2022-09-30' of 
https://gitlab.freedesktop.org/agd5f/linux into drm-next

git bisect bad 65898687cf7392c372ea8d04a88617e2cb794465
# good: [2d89e2ddfd00ca569dd73883c7c70badbd57f4ac] drm/amdgpu: fix 
compiler warning for amdgpu_gfx_cp_init_microcode

git bisect good 2d89e2ddfd00ca569dd73883c7c70badbd57f4ac
# bad: [1637c315282e97efcb95cc7dfafbb15efa9fa27f] drm/mediatek: dp: Fix 
compiler warning in mtk_dp_video_mute()

git bisect bad 1637c315282e97efcb95cc7dfafbb15efa9fa27f
# skip: [b78e5d830f0db8e6d998cdc5a2b7b807cf463f99] drm/tests: Set also 
mock plane src_x, src_y, src_w and src_h

git bisect skip b78e5d830f0db8e6d998cdc5a2b7b807cf463f99
# skip: [213cb76ddc8b875e772f9f4d173feefa122716af] Merge tag 
'drm-intel-gt-next-2022-09-09' of 
git://anongit.freedesktop.org/drm/drm-intel into drm-next

git bisect skip 213cb76ddc8b875e772f9f4d173feefa122716af
# good: [4f96b1bc156e7076f6efedc2a76a8c7e897c7977] drm/todo: Add entry 
about dealing with brightness control on devices with > 1 panel

git bisect good 4f96b1bc156e7076f6efedc2a76a8c7e897c7977
# skip: [165ba1aad164b7d5d5bc327fa

Re: [PATCH] drm/i915/fbc: Avoid full proxy f_ops for FBC debug attributes

2022-12-28 Thread Rodrigo Vivi
On Tue, Dec 27, 2022 at 11:36:13PM +0530, Deepak R Varma wrote:
> On Tue, Dec 27, 2022 at 12:13:56PM -0500, Rodrigo Vivi wrote:
> > On Tue, Dec 27, 2022 at 01:30:53PM +0530, Deepak R Varma wrote:
> > > Using DEFINE_SIMPLE_ATTRIBUTE macro with the debugfs_create_file()
> > > function adds the overhead of introducing a proxy file operation
> > > functions to wrap the original read/write inside file removal protection
> > > functions. This adds significant overhead in terms of introducing and
> > > managing the proxy factory file operations structure and function
> > > wrapping at runtime.
> > > As a replacement, a combination of DEFINE_DEBUGFS_ATTRIBUTE macro paired
> > > with debugfs_create_file_unsafe() is suggested to be used instead.  The
> > > DEFINE_DEBUGFS_ATTRIBUTE utilises debugfs_file_get() and
> > > debugfs_file_put() wrappers to protect the original read and write
> > > function calls for the debug attributes. There is no need for any
> > > runtime proxy file operations to be managed by the debugfs core.
> > >
> > > This Change is reported by the debugfs_simple_attr.cocci Coccinelle
> > > semantic patch.
> >
> > I just checked here with
> > $ make coccicheck M=drivers/gpu/drm/i915/ MODE=context 
> > COCCI=./scripts/coccinelle/api/debugfs/debugfs_simple_attr.cocci
> 
> Hello Rodrigo,
> Thank you so much for your review and feedback on the patch proposal.
> 
> >
> > The part reported by the this script is the s/SIMPLE/DEBUGFS
> > but the change to the unsafe option is not.
> 
> If you look at the original commit of this coccinelle file, it calls out the
> need for pairing debugfs_create_file_unsafe() as well. Please review this
> 
> commitID: 5103068eaca2: ("debugfs, coccinelle: check for obsolete 
> DEFINE_SIMPLE_ATTRIBUTE() usage")

+Nicolai and Julia.

It looks like coccinelle got right the
- DEFINE_SIMPLE_ATTRIBUTE(dsa_fops, dsa_get, dsa_set, dsa_fmt);
+ DEFINE_DEBUGFS_ATTRIBUTE(dsa_fops, dsa_get, dsa_set, dsa_fmt);

but it failed badly on
- debugfs_create_file(name, mode, parent, data, &dsa_fops)
+ debugfs_create_file_unsafe(name, mode, parent, data, &dsa_fops)

> 
> Based on my review of the code, the functions debugfs_create_file() and
> debugfs_create_file_unsafe(), both internally call __debugfs_create_file().
> However, they pass debugfs_full_proxy_file_operations and
> debugfs_open_proxy_file_operations respectively to it. The former represents 
> the
> full proxy factory, where as the later one is lightweight open proxy
> implementation of the file operations structure.
> 
> >
> > This commit message is not explaining why the unsafe is the suggested
> > or who suggested it.
> 
> If you find the response above accurate, I will include these details about
> the _unsafe() function in my commit message in v2.
> 
> >
> > If you remove the unsafe part feel free to resend adding:
> 
> Please confirm you still believe switching to _unsafe() is not necessary.

Based on the coccinelle commit it looks like you are right, but cocinelle
just failed to detect the case. Let's see what Nicolai and Julia respond
before we move with any patch here.

> 
> >
> > Reviewed-by: Rodrigo Vivi 
> > (to both patches, this and the drrs one.
> >
> > Also, it looks like you could contribute with other 2 patches:
> > drivers/gpu/drm/i915/pxp/intel_pxp_debugfs.c:64:0-23: WARNING: 
> > pxp_terminate_fops should be defined with DEFINE_DEBUGFS_ATTRIBUTE
> > drivers/gpu/drm/i915/gvt/debugfs.c:150:0-23: WARNING: 
> > vgpu_scan_nonprivbb_fops should be defined with DEFINE_DEBUGFS_ATTRIBUTE
> 
> Yes, these are on my list. Was waiting for a feedback on the first submission
> before I send more similar patches.
> 
> Appreciate your time and the feedback.
> 
> 
> Regards,
> ./drv
> 
> >
> > >
> > > Signed-off-by: Deepak R Varma 
> > > ---
> > >  drivers/gpu/drm/i915/display/intel_fbc.c | 12 ++--
> > >  1 file changed, 6 insertions(+), 6 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/i915/display/intel_fbc.c 
> > > b/drivers/gpu/drm/i915/display/intel_fbc.c
> > > index b5ee5ea0d010..4b481e2f908b 100644
> > > --- a/drivers/gpu/drm/i915/display/intel_fbc.c
> > > +++ b/drivers/gpu/drm/i915/display/intel_fbc.c
> > > @@ -1809,10 +1809,10 @@ static int intel_fbc_debugfs_false_color_set(void 
> > > *data, u64 val)
> > >   return 0;
> > >  }
> > >
> > > -DEFINE_SIMPLE_ATTRIBUTE(intel_fbc_debugfs_false_color_fops,
> > > - intel_fbc_debugfs_false_color_get,
> > > - intel_fbc_debugfs_false_color_set,
> > > - "%llu\n");
> > > +DEFINE_DEBUGFS_ATTRIBUTE(intel_fbc_debugfs_false_color_fops,
> > > +  intel_fbc_debugfs_false_color_get,
> > > +  intel_fbc_debugfs_false_color_set,
> > > +  "%llu\n");
> > >
> > >  static void intel_fbc_debugfs_add(struct intel_fbc *fbc,
> > > struct dentry *parent)
> > > @@ -1821,8 +1821,8 @@ static void intel_fbc_debugfs_add(struct intel_fbc 
> > > *fbc,
> > >   

[PATCH v3 07/10] drm: Remove usage of deprecated DRM_DEBUG_KMS

2022-12-28 Thread Siddh Raman Pant
drm_print.h says DRM_DEBUG_KMS is deprecated in favor of
drm_dbg_kms().

Signed-off-by: Siddh Raman Pant 
---
 drivers/gpu/drm/drm_client_modeset.c   | 112 ++---
 drivers/gpu/drm/drm_color_mgmt.c   |   4 +-
 drivers/gpu/drm/drm_connector.c|  21 ++---
 drivers/gpu/drm/drm_crtc.c |  36 
 drivers/gpu/drm/drm_crtc_helper.c  |  54 ++--
 drivers/gpu/drm/drm_debugfs_crc.c  |   5 +-
 drivers/gpu/drm/drm_displayid.c|   4 +-
 drivers/gpu/drm/drm_edid.c |  17 ++--
 drivers/gpu/drm/drm_gem_shmem_helper.c |   4 +-
 drivers/gpu/drm/drm_lease.c|   2 +-
 drivers/gpu/drm/drm_mipi_dbi.c |   7 +-
 drivers/gpu/drm/drm_modes.c|  10 +--
 drivers/gpu/drm/drm_plane.c|  32 +++
 drivers/gpu/drm/drm_probe_helper.c |  39 -
 drivers/gpu/drm/drm_rect.c |   4 +-
 drivers/gpu/drm/drm_sysfs.c|   8 +-
 16 files changed, 189 insertions(+), 170 deletions(-)

diff --git a/drivers/gpu/drm/drm_client_modeset.c 
b/drivers/gpu/drm/drm_client_modeset.c
index e2403b8c6347..4e08ae688b83 100644
--- a/drivers/gpu/drm/drm_client_modeset.c
+++ b/drivers/gpu/drm/drm_client_modeset.c
@@ -242,8 +242,9 @@ static void drm_client_connectors_enabled(struct 
drm_connector **connectors,
for (i = 0; i < connector_count; i++) {
connector = connectors[i];
enabled[i] = drm_connector_enabled(connector, true);
-   DRM_DEBUG_KMS("connector %d enabled? %s\n", connector->base.id,
- connector->display_info.non_desktop ? "non 
desktop" : str_yes_no(enabled[i]));
+   drm_dbg_kms(connector->dev, "connector %d enabled? %s\n",
+   connector->base.id,
+   connector->display_info.non_desktop ? "non desktop" 
: str_yes_no(enabled[i]));
 
any_enabled |= enabled[i];
}
@@ -303,7 +304,7 @@ static bool drm_client_target_cloned(struct drm_device *dev,
}
 
if (can_clone) {
-   DRM_DEBUG_KMS("can clone using command line\n");
+   drm_dbg_kms(dev, "can clone using command line\n");
return true;
}
 
@@ -328,7 +329,7 @@ static bool drm_client_target_cloned(struct drm_device *dev,
}
 
if (can_clone) {
-   DRM_DEBUG_KMS("can clone using 1024x768\n");
+   drm_dbg_kms(dev, "can clone using 1024x768\n");
return true;
}
drm_info(dev, "kms: can't enable cloning when we probably wanted 
to.\n");
@@ -352,8 +353,9 @@ static int drm_client_get_tile_offsets(struct drm_connector 
**connectors,
continue;
 
if (!modes[i] && (h_idx || v_idx)) {
-   DRM_DEBUG_KMS("no modes for connector tiled %d %d\n", i,
- connector->base.id);
+   drm_dbg_kms(connector->dev,
+   "no modes for connector tiled %d %d\n",
+   i, connector->base.id);
continue;
}
if (connector->tile_h_loc < h_idx)
@@ -364,7 +366,8 @@ static int drm_client_get_tile_offsets(struct drm_connector 
**connectors,
}
offsets[idx].x = hoffset;
offsets[idx].y = voffset;
-   DRM_DEBUG_KMS("returned %d %d for %d %d\n", hoffset, voffset, h_idx, 
v_idx);
+   drm_dbg_kms(NULL, "returned %d %d for %d %d\n",
+   hoffset, voffset, h_idx, v_idx);
return 0;
 }
 
@@ -421,14 +424,16 @@ static bool drm_client_target_preferred(struct 
drm_connector **connectors,
drm_client_get_tile_offsets(connectors, 
connector_count, modes, offsets, i,
connector->tile_h_loc, 
connector->tile_v_loc);
}
-   DRM_DEBUG_KMS("looking for cmdline mode on connector %d\n",
- connector->base.id);
+   drm_dbg_kms(connector->dev,
+   "looking for cmdline mode on connector %d\n",
+   connector->base.id);
 
/* got for command line mode first */
modes[i] = drm_connector_pick_cmdline_mode(connector);
if (!modes[i]) {
-   DRM_DEBUG_KMS("looking for preferred mode on connector 
%d %d\n",
- connector->base.id, connector->tile_group 
? connector->tile_group->id : 0);
+   drm_dbg_kms(connector->dev,
+   "looking for preferred mode on connector %d 
%d\n",
+   connector->base.id, connector->tile_group ? 
connector->tile_group->id : 0);
modes[i] = drm_connector_has_preferred_mode(connector, 
width, height);
}
/* No preferred modes

[PATCH v3 05/10] drm: Remove usage of deprecated DRM_DEBUG

2022-12-28 Thread Siddh Raman Pant
drm_print.h says DRM_DEBUG is deprecated in favor of drm_dbg_core().

Signed-off-by: Siddh Raman Pant 
---
 drivers/gpu/drm/drm_agpsupport.c  |   4 +-
 drivers/gpu/drm/drm_bufs.c| 114 +++---
 drivers/gpu/drm/drm_context.c |  14 ++--
 drivers/gpu/drm/drm_dma.c |  10 +--
 drivers/gpu/drm/drm_drv.c |  10 +--
 drivers/gpu/drm/drm_file.c|  18 ++---
 drivers/gpu/drm/drm_gem.c |   5 +-
 drivers/gpu/drm/drm_hashtab.c |   6 +-
 drivers/gpu/drm/drm_ioc32.c   |  13 ++--
 drivers/gpu/drm/drm_ioctl.c   |  24 +++
 drivers/gpu/drm/drm_irq.c |   4 +-
 drivers/gpu/drm/drm_lease.c   |   2 +-
 drivers/gpu/drm/drm_legacy_misc.c |   4 +-
 drivers/gpu/drm/drm_lock.c|  20 +++---
 drivers/gpu/drm/drm_mode_object.c |   6 +-
 drivers/gpu/drm/drm_pci.c |  12 ++--
 drivers/gpu/drm/drm_plane.c   |  12 ++--
 drivers/gpu/drm/drm_scatter.c |  10 +--
 drivers/gpu/drm/drm_syncobj.c |   2 +-
 drivers/gpu/drm/drm_sysfs.c   |  14 ++--
 drivers/gpu/drm/drm_vm.c  |  43 ++-
 21 files changed, 178 insertions(+), 169 deletions(-)

diff --git a/drivers/gpu/drm/drm_agpsupport.c b/drivers/gpu/drm/drm_agpsupport.c
index a4ad6fd13abc..d27686d6e82d 100644
--- a/drivers/gpu/drm/drm_agpsupport.c
+++ b/drivers/gpu/drm/drm_agpsupport.c
@@ -315,8 +315,8 @@ int drm_legacy_agp_bind(struct drm_device *dev, struct 
drm_agp_binding *request)
if (retcode)
return retcode;
entry->bound = dev->agp->base + (page << PAGE_SHIFT);
-   DRM_DEBUG("base = 0x%lx entry->bound = 0x%lx\n",
- dev->agp->base, entry->bound);
+   drm_dbg_core(dev, "base = 0x%lx entry->bound = 0x%lx\n",
+dev->agp->base, entry->bound);
return 0;
 }
 EXPORT_SYMBOL(drm_legacy_agp_bind);
diff --git a/drivers/gpu/drm/drm_bufs.c b/drivers/gpu/drm/drm_bufs.c
index 98aaf3379a3b..feedd7c6f0d5 100644
--- a/drivers/gpu/drm/drm_bufs.c
+++ b/drivers/gpu/drm/drm_bufs.c
@@ -171,8 +171,8 @@ static int drm_addmap_core(struct drm_device *dev, 
resource_size_t offset,
kfree(map);
return -EINVAL;
}
-   DRM_DEBUG("offset = 0x%08llx, size = 0x%08lx, type = %d\n",
- (unsigned long long)map->offset, map->size, map->type);
+   drm_dbg_core(dev, "offset = 0x%08llx, size = 0x%08lx, type = %d\n",
+(unsigned long long)map->offset, map->size, map->type);
 
/* page-align _DRM_SHM maps. They are allocated here so there is no 
security
 * hole created by that and it works around various broken drivers that 
use
@@ -205,10 +205,10 @@ static int drm_addmap_core(struct drm_device *dev, 
resource_size_t offset,
list = drm_find_matching_map(dev, map);
if (list != NULL) {
if (list->map->size != map->size) {
-   DRM_DEBUG("Matching maps of type %d with "
- "mismatched sizes, (%ld vs %ld)\n",
- map->type, map->size,
- list->map->size);
+   drm_dbg_core(dev, "Matching maps of type %d 
with "
+"mismatched sizes, (%ld vs %ld)\n",
+map->type, map->size,
+list->map->size);
list->map->size = map->size;
}
 
@@ -239,9 +239,9 @@ static int drm_addmap_core(struct drm_device *dev, 
resource_size_t offset,
list = drm_find_matching_map(dev, map);
if (list != NULL) {
if (list->map->size != map->size) {
-   DRM_DEBUG("Matching maps of type %d with "
- "mismatched sizes, (%ld vs %ld)\n",
- map->type, map->size, 
list->map->size);
+   drm_dbg_core(dev, "Matching maps of type %d 
with "
+"mismatched sizes, (%ld vs %ld)\n",
+map->type, map->size, 
list->map->size);
list->map->size = map->size;
}
 
@@ -250,8 +250,8 @@ static int drm_addmap_core(struct drm_device *dev, 
resource_size_t offset,
return 0;
}
map->handle = vmalloc_user(map->size);
-   DRM_DEBUG("%lu %d %p\n",
- map->size, order_base_2(map->size), map->handle);
+   drm_dbg_core(dev, "%lu %d %p\n",
+map->size, order_base_2(map->size), map->handle);
if (!map->handle) {
kfree(map);
return -ENOMEM;
@@ -308,8 +308,8 @@ static int drm_addmap_core(st

[PATCH v3 03/10] drm: Remove usage of deprecated DRM_NOTE

2022-12-28 Thread Siddh Raman Pant
drm_print.h says DRM_INFO is deprecated in favor of drm_notice().

Signed-off-by: Siddh Raman Pant 
---
 drivers/gpu/drm/drm_displayid.c | 2 +-
 drivers/gpu/drm/drm_kms_helper_common.c | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/drm_displayid.c b/drivers/gpu/drm/drm_displayid.c
index 38ea8203df45..67fed6cee9e9 100644
--- a/drivers/gpu/drm/drm_displayid.c
+++ b/drivers/gpu/drm/drm_displayid.c
@@ -26,7 +26,7 @@ static int validate_displayid(const u8 *displayid, int 
length, int idx)
for (i = 0; i < dispid_length; i++)
csum += displayid[idx + i];
if (csum) {
-   DRM_NOTE("DisplayID checksum invalid, remainder is %d\n", csum);
+   drm_notice(NULL, "DisplayID checksum invalid, remainder is 
%d\n", csum);
return -EINVAL;
}
 
diff --git a/drivers/gpu/drm/drm_kms_helper_common.c 
b/drivers/gpu/drm/drm_kms_helper_common.c
index 0bf0fc1abf54..7a41373b67dc 100644
--- a/drivers/gpu/drm/drm_kms_helper_common.c
+++ b/drivers/gpu/drm/drm_kms_helper_common.c
@@ -41,7 +41,7 @@ MODULE_LICENSE("GPL and additional rights");
 /* Backward compatibility for drm_kms_helper.edid_firmware */
 static int edid_firmware_set(const char *val, const struct kernel_param *kp)
 {
-   DRM_NOTE("drm_kms_helper.edid_firmware is deprecated, please use 
drm.edid_firmware instead.\n");
+   drm_notice(NULL, "drm_kms_helper.edid_firmware is deprecated, please 
use drm.edid_firmware instead.\n");
 
return __drm_set_edid_firmware_path(val);
 }
-- 
2.35.1




[PATCH] drm/radeon: Fix potential null-ptr-deref

2022-12-28 Thread Nikita Zhandarovich
radeon_get_connector_for_encoder() assigns radeon_encoder->enc_priv to
mst_enc which is dereferenced later without being checked for NULL
beforehand. It is possible for radeon_encoder->enc_priv and therefore
mst_enc, to be NULL due to potential lack of memory.

This patch adds a sanity NULL-check to prevent the issue.

Found by Linux Verification Center (linuxtesting.org) with SVACE.

Fixes: 9843ead08f18 ("drm/radeon: add DisplayPort MST support (v2)")
Signed-off-by: Nikita Zhandarovich 
---
 drivers/gpu/drm/radeon/radeon_encoders.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/gpu/drm/radeon/radeon_encoders.c 
b/drivers/gpu/drm/radeon/radeon_encoders.c
index 46549d5179ee..3f68f0af443a 100644
--- a/drivers/gpu/drm/radeon/radeon_encoders.c
+++ b/drivers/gpu/drm/radeon/radeon_encoders.c
@@ -251,6 +251,9 @@ radeon_get_connector_for_encoder(struct drm_encoder 
*encoder)
continue;
 
mst_enc = radeon_encoder->enc_priv;
+   if (!mst_enc)
+   return NULL;
+
if (mst_enc->connector == radeon_connector->mst_port)
return connector;
} else if (radeon_encoder->active_device & 
radeon_connector->devices)
-- 
2.25.1



[PATCH v3 00/10] drm: Remove usage of deprecated DRM_* macros

2022-12-28 Thread Siddh Raman Pant
This patchset aims to remove usages of deprecated DRM_* macros from the
files residing in drivers/gpu/drm root.

In process, I found out that NULL as first argument of drm_dbg_* wasn't
working, but it was listed as the alternative in deprecation comment,
so I fixed that before removing usages of DRM_DEBUG_* macros. Courtesy
discussion on v1, I added support for NULL in drm_()* macros too in this
v3.

This patchset should be applied in order as changes might be dependent.


Please review and let me know if any errors are there, and hopefully
this gets accepted.

---
Changes in v3:
- Added support for NULL is __drm_printk and thus by extension to drm_()*.
- Thus, converted dropped pr_()* changes to drm_*(NULL, ...).
- Rebased to drm-misc-next and resulting appropriate changes.

Changes in v2:
- Removed conversions to pr_*() in DRM_INFO, DRM_NOTE, and DRM_ERROR changes.
- Due to above, DRM_NOTE usage cannot be removed and the patch is dropped.
- DRY: NULL support is now achieved by way of a separate function.

Siddh Raman Pant (10):
  drm/print: Fix and add support for NULL as first argument in drm_*
macros
  drm: Remove usage of deprecated DRM_INFO
  drm: Remove usage of deprecated DRM_NOTE
  drm: Remove usage of deprecated DRM_ERROR
  drm: Remove usage of deprecated DRM_DEBUG
  drm: Remove usage of deprecated DRM_DEBUG_DRIVER
  drm: Remove usage of deprecated DRM_DEBUG_KMS
  drm: Remove usage of deprecated DRM_DEBUG_PRIME
  drm/drm_blend: Remove usage of deprecated DRM_DEBUG_ATOMIC
  drm/drm_lease: Remove usage of deprecated DRM_DEBUG_LEASE

 drivers/gpu/drm/drm_agpsupport.c|   4 +-
 drivers/gpu/drm/drm_blend.c |  13 ++-
 drivers/gpu/drm/drm_bridge.c|   8 +-
 drivers/gpu/drm/drm_bufs.c  | 122 
 drivers/gpu/drm/drm_client_modeset.c| 118 +--
 drivers/gpu/drm/drm_color_mgmt.c|   4 +-
 drivers/gpu/drm/drm_connector.c |  28 +++---
 drivers/gpu/drm/drm_context.c   |  18 ++--
 drivers/gpu/drm/drm_crtc.c  |  36 ---
 drivers/gpu/drm/drm_crtc_helper.c   |  62 ++--
 drivers/gpu/drm/drm_debugfs_crc.c   |   8 +-
 drivers/gpu/drm/drm_displayid.c |   6 +-
 drivers/gpu/drm/drm_dma.c   |  10 +-
 drivers/gpu/drm/drm_drv.c   |  26 ++---
 drivers/gpu/drm/drm_edid.c  |  17 ++--
 drivers/gpu/drm/drm_file.c  |  18 ++--
 drivers/gpu/drm/drm_flip_work.c |   2 +-
 drivers/gpu/drm/drm_framebuffer.c   |   3 +-
 drivers/gpu/drm/drm_gem.c   |   7 +-
 drivers/gpu/drm/drm_gem_dma_helper.c|   6 +-
 drivers/gpu/drm/drm_gem_shmem_helper.c  |   6 +-
 drivers/gpu/drm/drm_hashtab.c   |  10 +-
 drivers/gpu/drm/drm_ioc32.c |  13 +--
 drivers/gpu/drm/drm_ioctl.c |  24 ++---
 drivers/gpu/drm/drm_irq.c   |   4 +-
 drivers/gpu/drm/drm_kms_helper_common.c |   2 +-
 drivers/gpu/drm/drm_lease.c |  68 ++---
 drivers/gpu/drm/drm_legacy_misc.c   |   4 +-
 drivers/gpu/drm/drm_lock.c  |  36 +++
 drivers/gpu/drm/drm_mipi_dbi.c  |  19 ++--
 drivers/gpu/drm/drm_mipi_dsi.c  |  12 +--
 drivers/gpu/drm/drm_mm.c|   8 +-
 drivers/gpu/drm/drm_mode_config.c   |   2 +-
 drivers/gpu/drm/drm_mode_object.c   |   6 +-
 drivers/gpu/drm/drm_modes.c |  36 +++
 drivers/gpu/drm/drm_modeset_helper.c|   2 +-
 drivers/gpu/drm/drm_pci.c   |  14 +--
 drivers/gpu/drm/drm_plane.c |  46 -
 drivers/gpu/drm/drm_probe_helper.c  |  39 
 drivers/gpu/drm/drm_rect.c  |   4 +-
 drivers/gpu/drm/drm_scatter.c   |  19 ++--
 drivers/gpu/drm/drm_syncobj.c   |   2 +-
 drivers/gpu/drm/drm_sysfs.c |  22 ++---
 drivers/gpu/drm/drm_vm.c|  45 +
 include/drm/drm_print.h |  97 +--
 45 files changed, 565 insertions(+), 491 deletions(-)

-- 
2.35.1




[PATCH v3 06/10] drm: Remove usage of deprecated DRM_DEBUG_DRIVER

2022-12-28 Thread Siddh Raman Pant
drm_print.h says DRM_DEBUG_DRIVER is deprecated.
Thus, use newer drm_dbg_driver().

Also fix the deprecation comment in drm_print.h which
mentions drm_dbg() instead of drm_dbg_driver().

Signed-off-by: Siddh Raman Pant 
---
 drivers/gpu/drm/drm_mipi_dbi.c | 10 +-
 include/drm/drm_print.h|  2 +-
 2 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/drm_mipi_dbi.c b/drivers/gpu/drm/drm_mipi_dbi.c
index 58ff9503a403..ab5dd5933a1a 100644
--- a/drivers/gpu/drm/drm_mipi_dbi.c
+++ b/drivers/gpu/drm/drm_mipi_dbi.c
@@ -70,11 +70,11 @@
 #define MIPI_DBI_DEBUG_COMMAND(cmd, data, len) \
 ({ \
if (!len) \
-   DRM_DEBUG_DRIVER("cmd=%02x\n", cmd); \
+   drm_dbg_driver(NULL, "cmd=%02x\n", cmd); \
else if (len <= 32) \
-   DRM_DEBUG_DRIVER("cmd=%02x, par=%*ph\n", cmd, (int)len, data);\
+   drm_dbg_driver(NULL, "cmd=%02x, par=%*ph\n", cmd, (int)len, 
data);\
else \
-   DRM_DEBUG_DRIVER("cmd=%02x, len=%zu\n", cmd, len); \
+   drm_dbg_driver(NULL, "cmd=%02x, len=%zu\n", cmd, len); \
 })
 
 static const u8 mipi_dbi_dcs_read_commands[] = {
@@ -708,7 +708,7 @@ bool mipi_dbi_display_is_on(struct mipi_dbi *dbi)
DCS_POWER_MODE_DISPLAY_NORMAL_MODE | DCS_POWER_MODE_SLEEP_MODE))
return false;
 
-   DRM_DEBUG_DRIVER("Display is ON\n");
+   drm_dbg_driver(NULL, "Display is ON\n");
 
return true;
 }
@@ -1256,7 +1256,7 @@ int mipi_dbi_spi_init(struct spi_device *spi, struct 
mipi_dbi *dbi,
 
mutex_init(&dbi->cmdlock);
 
-   DRM_DEBUG_DRIVER("SPI speed: %uMHz\n", spi->max_speed_hz / 100);
+   drm_dbg_driver(NULL, "SPI speed: %uMHz\n", spi->max_speed_hz / 100);
 
return 0;
 }
diff --git a/include/drm/drm_print.h b/include/drm/drm_print.h
index ae7f5e29adfd..bb6c80252104 100644
--- a/include/drm/drm_print.h
+++ b/include/drm/drm_print.h
@@ -603,7 +603,7 @@ void __drm_err(const char *format, ...);
 #define DRM_DEBUG(fmt, ...)\
__drm_dbg(DRM_UT_CORE, fmt, ##__VA_ARGS__)
 
-/* NOTE: this is deprecated in favor of drm_dbg(NULL, ...). */
+/* NOTE: this is deprecated in favor of drm_dbg_driver(NULL, ...). */
 #define DRM_DEBUG_DRIVER(fmt, ...) \
__drm_dbg(DRM_UT_DRIVER, fmt, ##__VA_ARGS__)
 
-- 
2.35.1




[PATCH v3 01/10] drm/print: Fix and add support for NULL as first argument in drm_* macros

2022-12-28 Thread Siddh Raman Pant
Comments say macros DRM_DEBUG_* are deprecated in favor of
drm_dbg_*(NULL, ...), but they have broken support for it,
as the macro will result in `(NULL) ? (NULL)->dev : NULL`.

Thus, fix them by separating logic to get dev ptr in a new
function, which will return the dev ptr if arg is not NULL.
Use it in drm_dbg_*, and also in __DRM_DEFINE_DBG_RATELIMITED,
where a similar (but correct) NULL check was in place.

Also, add support for NULL in __drm_printk, so that all the
drm_* macros will hence support NULL as the first argument.
This also means that deprecation comments mentioning pr_()*
can now be changed to the drm equivalents.

There is a need to support device pointers in __drm_printk,
as in some contexts, we may not have drm_device but just the
device ptr, such as when dealing with struct mipi_dsi_host.
Before this change, passing just host would have worked as
due to preprocessing, __drm_printk resulted in host->dev, but
now due to NULL check that cannot happen.

Signed-off-by: Siddh Raman Pant 
---
 include/drm/drm_print.h | 95 +
 1 file changed, 67 insertions(+), 28 deletions(-)

diff --git a/include/drm/drm_print.h b/include/drm/drm_print.h
index a44fb7ef257f..ae7f5e29adfd 100644
--- a/include/drm/drm_print.h
+++ b/include/drm/drm_print.h
@@ -34,6 +34,7 @@
 #include 
 
 #include 
+#include 
 
 /* Do *not* use outside of drm_print.[ch]! */
 extern unsigned long __drm_debug;
@@ -451,9 +452,46 @@ void __drm_dev_dbg(struct _ddebug *desc, const struct 
device *dev,
  * Prefer drm_device based logging over device or prink based logging.
  */
 
-/* Helper for struct drm_device based logging. */
+/**
+ * __drm_get_dev_ptr - Helper function to get device type pointer even if NULL
+ *is passed. Primarily for use in print macros, since they
+ *need to handle NULL as the first argument passed.
+ * @drm: struct drm_device pointer, struct device pointer, or NULL.
+ * @is_drm: True implies @drm is drm_device pointer, else device pointer.
+ *
+ * RETURNS:
+ * The device pointer (NULL if @drm is NULL).
+ */
+static inline struct device *__drm_get_dev_ptr(const void *ptr, bool is_drm)
+{
+   if (!ptr)
+   return NULL;
+
+   if (is_drm)
+   return ((struct drm_device *)ptr)->dev;
+
+   return (struct device *)ptr;
+}
+
+/**
+ * Helper for struct drm_device based logging (prefer this over struct device).
+ * Also supports struct device ptr as an argument for edge cases.
+ */
 #define __drm_printk(drm, level, type, fmt, ...)   \
-   dev_##level##type((drm)->dev, "[drm] " fmt, ##__VA_ARGS__)
+({ \
+   struct device *__dev_ = _Generic((drm), \
+   struct drm_device * :   \
+   __drm_get_dev_ptr((drm), true), \
+   struct device * :   \
+   __drm_get_dev_ptr((drm), false),\
+   default :   \
+   NULL\
+   );  \
+   if (__dev_) \
+   dev_##level##type(__dev_, "[drm] " fmt, ##__VA_ARGS__); \
+   else\
+   pr_##level##type("[drm] " fmt, ##__VA_ARGS__);  \
+})
 
 
 #define drm_info(drm, fmt, ...)\
@@ -487,25 +525,25 @@ void __drm_dev_dbg(struct _ddebug *desc, const struct 
device *dev,
 
 
 #define drm_dbg_core(drm, fmt, ...)\
-   drm_dev_dbg((drm) ? (drm)->dev : NULL, DRM_UT_CORE, fmt, ##__VA_ARGS__)
-#define drm_dbg_driver(drm, fmt, ...)  
\
-   drm_dev_dbg((drm) ? (drm)->dev : NULL, DRM_UT_DRIVER, fmt, 
##__VA_ARGS__)
+   drm_dev_dbg(__drm_get_dev_ptr((drm), true), DRM_UT_CORE, fmt, 
##__VA_ARGS__)
+#define drm_dbg_driver(drm, fmt, ...)  \
+   drm_dev_dbg(__drm_get_dev_ptr((drm), true), DRM_UT_DRIVER, fmt, 
##__VA_ARGS__)
 #define drm_dbg_kms(drm, fmt, ...) \
-   drm_dev_dbg((drm) ? (drm)->dev : NULL, DRM_UT_KMS, fmt, ##__VA_ARGS__)
+   drm_dev_dbg(__drm_get_dev_ptr((drm), true), DRM_UT_KMS, fmt, 
##__VA_ARGS__)
 #define drm_dbg_prime(drm, fmt, ...)   \
-   drm_dev_dbg((drm) ? (drm)->dev : NULL, DRM_UT_PRIME, fmt, ##__VA_ARGS__)
+   drm_dev_dbg(__drm_get_dev_ptr((drm), true), DRM_UT_PRIME, fmt, 
##__VA_ARGS__)
 #define drm_dbg_atomic(drm, fmt, ...)  \
-   drm_dev_dbg((drm) ? (drm)->dev : NULL, DRM_UT_ATOMIC, fmt, 
##__VA

[PATCH v3 08/10] drm: Remove usage of deprecated DRM_DEBUG_PRIME

2022-12-28 Thread Siddh Raman Pant
drm_print.h says DRM_DEBUG_PRIME is deprecated in favor of
drm_dbg_prime().

Signed-off-by: Siddh Raman Pant 
Reviewed-by: Simon Ser 
---
 drivers/gpu/drm/drm_gem_dma_helper.c   | 4 ++--
 drivers/gpu/drm/drm_gem_shmem_helper.c | 2 +-
 2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/drm_gem_dma_helper.c 
b/drivers/gpu/drm/drm_gem_dma_helper.c
index 1ba551b0ab97..0f903cc8914a 100644
--- a/drivers/gpu/drm/drm_gem_dma_helper.c
+++ b/drivers/gpu/drm/drm_gem_dma_helper.c
@@ -477,8 +477,8 @@ drm_gem_dma_prime_import_sg_table(struct drm_device *dev,
dma_obj->dma_addr = sg_dma_address(sgt->sgl);
dma_obj->sgt = sgt;
 
-   DRM_DEBUG_PRIME("dma_addr = %pad, size = %zu\n", &dma_obj->dma_addr,
-   attach->dmabuf->size);
+   drm_dbg_prime(dev, "dma_addr = %pad, size = %zu\n", &dma_obj->dma_addr,
+ attach->dmabuf->size);
 
return &dma_obj->base;
 }
diff --git a/drivers/gpu/drm/drm_gem_shmem_helper.c 
b/drivers/gpu/drm/drm_gem_shmem_helper.c
index e99426b5be93..c8780b72e4e8 100644
--- a/drivers/gpu/drm/drm_gem_shmem_helper.c
+++ b/drivers/gpu/drm/drm_gem_shmem_helper.c
@@ -760,7 +760,7 @@ drm_gem_shmem_prime_import_sg_table(struct drm_device *dev,
 
shmem->sgt = sgt;
 
-   DRM_DEBUG_PRIME("size = %zu\n", size);
+   drm_dbg_prime(dev, "size = %zu\n", size);
 
return &shmem->base;
 }
-- 
2.35.1




[PATCH] drm/radeon: Fix potential null-ptr-deref

2022-12-28 Thread Nikita Zhandarovich
Due to my rookie mistake this patch isn't necessary anymore in
upstream version. The issue was already resolved in a different
manner.

Apologies for inconvenience.


[PATCH v3 09/10] drm/drm_blend: Remove usage of deprecated DRM_DEBUG_ATOMIC

2022-12-28 Thread Siddh Raman Pant
drm_print.h says DRM_DEBUG_ATOMIC is deprecated in favor of
drm_dbg_atomic().

Signed-off-by: Siddh Raman Pant 
Reviewed-by: Simon Ser 
---
 drivers/gpu/drm/drm_blend.c | 13 ++---
 1 file changed, 6 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/drm_blend.c b/drivers/gpu/drm/drm_blend.c
index b4c8cab7158c..6e74de833466 100644
--- a/drivers/gpu/drm/drm_blend.c
+++ b/drivers/gpu/drm/drm_blend.c
@@ -450,8 +450,8 @@ static int drm_atomic_helper_crtc_normalize_zpos(struct 
drm_crtc *crtc,
int i, n = 0;
int ret = 0;
 
-   DRM_DEBUG_ATOMIC("[CRTC:%d:%s] calculating normalized zpos values\n",
-crtc->base.id, crtc->name);
+   drm_dbg_atomic(dev, "[CRTC:%d:%s] calculating normalized zpos values\n",
+  crtc->base.id, crtc->name);
 
states = kmalloc_array(total_planes, sizeof(*states), GFP_KERNEL);
if (!states)
@@ -469,9 +469,8 @@ static int drm_atomic_helper_crtc_normalize_zpos(struct 
drm_crtc *crtc,
goto done;
}
states[n++] = plane_state;
-   DRM_DEBUG_ATOMIC("[PLANE:%d:%s] processing zpos value %d\n",
-plane->base.id, plane->name,
-plane_state->zpos);
+   drm_dbg_atomic(dev, "[PLANE:%d:%s] processing zpos value %d\n",
+  plane->base.id, plane->name, plane_state->zpos);
}
 
sort(states, n, sizeof(*states), drm_atomic_state_zpos_cmp, NULL);
@@ -480,8 +479,8 @@ static int drm_atomic_helper_crtc_normalize_zpos(struct 
drm_crtc *crtc,
plane = states[i]->plane;
 
states[i]->normalized_zpos = i;
-   DRM_DEBUG_ATOMIC("[PLANE:%d:%s] normalized zpos value %d\n",
-plane->base.id, plane->name, i);
+   drm_dbg_atomic(dev, "[PLANE:%d:%s] normalized zpos value %d\n",
+  plane->base.id, plane->name, i);
}
crtc_state->zpos_changed = true;
 
-- 
2.35.1




[PATCH v3 10/10] drm/drm_lease: Remove usage of deprecated DRM_DEBUG_LEASE

2022-12-28 Thread Siddh Raman Pant
drm_print.h says DRM_DEBUG_LEASE is deprecated in favor of
drm_dbg_lease().

Signed-off-by: Siddh Raman Pant 
Reviewed-by: Simon Ser 
---
 drivers/gpu/drm/drm_lease.c | 64 -
 1 file changed, 34 insertions(+), 30 deletions(-)

diff --git a/drivers/gpu/drm/drm_lease.c b/drivers/gpu/drm/drm_lease.c
index c442d5e766d1..08b4f29f8b61 100644
--- a/drivers/gpu/drm/drm_lease.c
+++ b/drivers/gpu/drm/drm_lease.c
@@ -213,11 +213,11 @@ static struct drm_master *drm_lease_create(struct 
drm_master *lessor, struct idr
int id;
void *entry;
 
-   DRM_DEBUG_LEASE("lessor %d\n", lessor->lessee_id);
+   drm_dbg_lease(dev, "lessor %d\n", lessor->lessee_id);
 
lessee = drm_master_create(lessor->dev);
if (!lessee) {
-   DRM_DEBUG_LEASE("drm_master_create failed\n");
+   drm_dbg_lease(dev, "drm_master_create failed\n");
return ERR_PTR(-ENOMEM);
}
 
@@ -231,7 +231,7 @@ static struct drm_master *drm_lease_create(struct 
drm_master *lessor, struct idr
error = -EBUSY;
 
if (error != 0) {
-   DRM_DEBUG_LEASE("object %d failed %d\n", object, error);
+   drm_dbg_lease(dev, "object %d failed %d\n", object, 
error);
goto out_lessee;
}
}
@@ -249,7 +249,8 @@ static struct drm_master *drm_lease_create(struct 
drm_master *lessor, struct idr
 
/* Move the leases over */
lessee->leases = *leases;
-   DRM_DEBUG_LEASE("new lessee %d %p, lessor %d %p\n", lessee->lessee_id, 
lessee, lessor->lessee_id, lessor);
+   drm_dbg_lease(dev, "new lessee %d %p, lessor %d %p\n",
+ lessee->lessee_id, lessee, lessor->lessee_id, lessor);
 
mutex_unlock(&dev->mode_config.idr_mutex);
return lessee;
@@ -268,7 +269,7 @@ void drm_lease_destroy(struct drm_master *master)
 
mutex_lock(&dev->mode_config.idr_mutex);
 
-   DRM_DEBUG_LEASE("drm_lease_destroy %d\n", master->lessee_id);
+   drm_dbg_lease(dev, "drm_lease_destroy %d\n", master->lessee_id);
 
/* This master is referenced by all lessees, hence it cannot be 
destroyed
 * until all of them have been
@@ -277,7 +278,8 @@ void drm_lease_destroy(struct drm_master *master)
 
/* Remove this master from the lessee idr in the owner */
if (master->lessee_id != 0) {
-   DRM_DEBUG_LEASE("remove master %d from device list of 
lessees\n", master->lessee_id);
+   drm_dbg_lease(dev, "remove master %d from device list of 
lessees\n",
+ master->lessee_id);
idr_remove(&(drm_lease_owner(master)->lessee_idr), 
master->lessee_id);
}
 
@@ -292,7 +294,7 @@ void drm_lease_destroy(struct drm_master *master)
drm_master_put(&master->lessor);
}
 
-   DRM_DEBUG_LEASE("drm_lease_destroy done %d\n", master->lessee_id);
+   drm_dbg_lease(dev, "drm_lease_destroy done %d\n", master->lessee_id);
 }
 
 static void _drm_lease_revoke(struct drm_master *top)
@@ -308,7 +310,8 @@ static void _drm_lease_revoke(struct drm_master *top)
 * the tree is fully connected, we can do this without recursing
 */
for (;;) {
-   DRM_DEBUG_LEASE("revoke leases for %p %d\n", master, 
master->lessee_id);
+   drm_dbg_lease(master->dev, "revoke leases for %p %d\n",
+ master, master->lessee_id);
 
/* Evacuate the lease */
idr_for_each_entry(&master->leases, entry, object)
@@ -408,7 +411,7 @@ static int fill_object_idr(struct drm_device *dev,
 
ret = validate_lease(dev, object_count, objects, universal_planes);
if (ret) {
-   DRM_DEBUG_LEASE("lease validation failed\n");
+   drm_dbg_lease(dev, "lease validation failed\n");
goto out_free_objects;
}
 
@@ -418,7 +421,7 @@ static int fill_object_idr(struct drm_device *dev,
struct drm_mode_object *obj = objects[o];
u32 object_id = objects[o]->id;
 
-   DRM_DEBUG_LEASE("Adding object %d to lease\n", object_id);
+   drm_dbg_lease(dev, "Adding object %d to lease\n", object_id);
 
/*
 * We're using an IDR to hold the set of leased
@@ -430,8 +433,8 @@ static int fill_object_idr(struct drm_device *dev,
 */
ret = idr_alloc(leases, &drm_lease_idr_object , object_id, 
object_id + 1, GFP_KERNEL);
if (ret < 0) {
-   DRM_DEBUG_LEASE("Object %d cannot be inserted into 
leases (%d)\n",
-   object_id, ret);
+   drm_dbg_lease(dev, "Object %d cannot be inserted into 
leases (%d)\n",
+ object_id, ret);
goto out_free_objects;
}
  

[PATCH v3 02/10] drm: Remove usage of deprecated DRM_INFO

2022-12-28 Thread Siddh Raman Pant
drm_print.h says DRM_INFO is deprecated in favor of drm_info().

Signed-off-by: Siddh Raman Pant 
---
 drivers/gpu/drm/drm_client_modeset.c | 2 +-
 drivers/gpu/drm/drm_connector.c  | 7 ---
 drivers/gpu/drm/drm_drv.c| 2 +-
 drivers/gpu/drm/drm_pci.c| 2 +-
 4 files changed, 7 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/drm_client_modeset.c 
b/drivers/gpu/drm/drm_client_modeset.c
index 1b12a3c201a3..ae19734974b5 100644
--- a/drivers/gpu/drm/drm_client_modeset.c
+++ b/drivers/gpu/drm/drm_client_modeset.c
@@ -331,7 +331,7 @@ static bool drm_client_target_cloned(struct drm_device *dev,
DRM_DEBUG_KMS("can clone using 1024x768\n");
return true;
}
-   DRM_INFO("kms: can't enable cloning when we probably wanted to.\n");
+   drm_info(dev, "kms: can't enable cloning when we probably wanted 
to.\n");
return false;
 }
 
diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
index 8d92777e57dd..6e962ad565db 100644
--- a/drivers/gpu/drm/drm_connector.c
+++ b/drivers/gpu/drm/drm_connector.c
@@ -165,13 +165,14 @@ static void drm_connector_get_cmdline_mode(struct 
drm_connector *connector)
return;
 
if (mode->force) {
-   DRM_INFO("forcing %s connector %s\n", connector->name,
-drm_get_connector_force_name(mode->force));
+   drm_info(connector->dev, "forcing %s connector %s\n",
+connector->name, 
drm_get_connector_force_name(mode->force));
connector->force = mode->force;
}
 
if (mode->panel_orientation != DRM_MODE_PANEL_ORIENTATION_UNKNOWN) {
-   DRM_INFO("cmdline forces connector %s panel_orientation to 
%d\n",
+   drm_info(connector->dev,
+"cmdline forces connector %s panel_orientation to 
%d\n",
 connector->name, mode->panel_orientation);
drm_connector_set_panel_orientation(connector,
mode->panel_orientation);
diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
index 11748dd513c3..dfb73c9d7930 100644
--- a/drivers/gpu/drm/drm_drv.c
+++ b/drivers/gpu/drm/drm_drv.c
@@ -901,7 +901,7 @@ int drm_dev_register(struct drm_device *dev, unsigned long 
flags)
if (drm_core_check_feature(dev, DRIVER_MODESET))
drm_modeset_register_all(dev);
 
-   DRM_INFO("Initialized %s %d.%d.%d %s for %s on minor %d\n",
+   drm_info(dev, "Initialized %s %d.%d.%d %s for %s on minor %d\n",
 driver->name, driver->major, driver->minor,
 driver->patchlevel, driver->date,
 dev->dev ? dev_name(dev->dev) : "virtual device",
diff --git a/drivers/gpu/drm/drm_pci.c b/drivers/gpu/drm/drm_pci.c
index 39d35fc3a43b..7dfb837d1325 100644
--- a/drivers/gpu/drm/drm_pci.c
+++ b/drivers/gpu/drm/drm_pci.c
@@ -262,7 +262,7 @@ void drm_legacy_pci_exit(const struct drm_driver *driver,
}
mutex_unlock(&legacy_dev_list_lock);
}
-   DRM_INFO("Module unloaded\n");
+   drm_info(NULL, "Module unloaded\n");
 }
 EXPORT_SYMBOL(drm_legacy_pci_exit);
 
-- 
2.35.1




[PATCH v3 04/10] drm: Remove usage of deprecated DRM_ERROR

2022-12-28 Thread Siddh Raman Pant
drm_print.h says DRM_ERROR is deprecated in favor of drm_err().

Signed-off-by: Siddh Raman Pant 
---
 drivers/gpu/drm/drm_bridge.c |  8 
 drivers/gpu/drm/drm_bufs.c   |  8 
 drivers/gpu/drm/drm_client_modeset.c |  4 ++--
 drivers/gpu/drm/drm_context.c|  4 ++--
 drivers/gpu/drm/drm_crtc_helper.c|  8 
 drivers/gpu/drm/drm_debugfs_crc.c|  3 ++-
 drivers/gpu/drm/drm_drv.c| 14 +++---
 drivers/gpu/drm/drm_flip_work.c  |  2 +-
 drivers/gpu/drm/drm_framebuffer.c|  3 ++-
 drivers/gpu/drm/drm_gem.c|  2 +-
 drivers/gpu/drm/drm_gem_dma_helper.c |  2 +-
 drivers/gpu/drm/drm_hashtab.c|  4 ++--
 drivers/gpu/drm/drm_lock.c   | 16 
 drivers/gpu/drm/drm_mipi_dbi.c   |  2 +-
 drivers/gpu/drm/drm_mipi_dsi.c   | 12 ++--
 drivers/gpu/drm/drm_mm.c |  8 
 drivers/gpu/drm/drm_mode_config.c|  2 +-
 drivers/gpu/drm/drm_modes.c  | 26 +-
 drivers/gpu/drm/drm_modeset_helper.c |  2 +-
 drivers/gpu/drm/drm_plane.c  |  2 +-
 drivers/gpu/drm/drm_scatter.c|  9 +
 drivers/gpu/drm/drm_vm.c |  2 +-
 22 files changed, 73 insertions(+), 70 deletions(-)

diff --git a/drivers/gpu/drm/drm_bridge.c b/drivers/gpu/drm/drm_bridge.c
index c3d69af02e79..3d27f08db74d 100644
--- a/drivers/gpu/drm/drm_bridge.c
+++ b/drivers/gpu/drm/drm_bridge.c
@@ -351,11 +351,11 @@ int drm_bridge_attach(struct drm_encoder *encoder, struct 
drm_bridge *bridge,
list_del(&bridge->chain_node);
 
 #ifdef CONFIG_OF
-   DRM_ERROR("failed to attach bridge %pOF to encoder %s: %d\n",
- bridge->of_node, encoder->name, ret);
+   drm_err(encoder->dev, "failed to attach bridge %pOF to encoder %s: 
%d\n",
+   bridge->of_node, encoder->name, ret);
 #else
-   DRM_ERROR("failed to attach bridge to encoder %s: %d\n",
- encoder->name, ret);
+   drm_err(encoder->dev, "failed to attach bridge to encoder %s: %d\n",
+   encoder->name, ret);
 #endif
 
return ret;
diff --git a/drivers/gpu/drm/drm_bufs.c b/drivers/gpu/drm/drm_bufs.c
index fcca21e8efac..98aaf3379a3b 100644
--- a/drivers/gpu/drm/drm_bufs.c
+++ b/drivers/gpu/drm/drm_bufs.c
@@ -1474,15 +1474,15 @@ int drm_legacy_freebufs(struct drm_device *dev, void 
*data,
if (copy_from_user(&idx, &request->list[i], sizeof(idx)))
return -EFAULT;
if (idx < 0 || idx >= dma->buf_count) {
-   DRM_ERROR("Index %d (of %d max)\n",
- idx, dma->buf_count - 1);
+   drm_err(dev, "Index %d (of %d max)\n",
+   idx, dma->buf_count - 1);
return -EINVAL;
}
idx = array_index_nospec(idx, dma->buf_count);
buf = dma->buflist[idx];
if (buf->file_priv != file_priv) {
-   DRM_ERROR("Process %d freeing buffer not owned\n",
- task_pid_nr(current));
+   drm_err(dev, "Process %d freeing buffer not owned\n",
+   task_pid_nr(current));
return -EINVAL;
}
drm_legacy_free_buffer(dev, buf);
diff --git a/drivers/gpu/drm/drm_client_modeset.c 
b/drivers/gpu/drm/drm_client_modeset.c
index ae19734974b5..e2403b8c6347 100644
--- a/drivers/gpu/drm/drm_client_modeset.c
+++ b/drivers/gpu/drm/drm_client_modeset.c
@@ -808,7 +808,7 @@ int drm_client_modeset_probe(struct drm_client_dev *client, 
unsigned int width,
offsets = kcalloc(connector_count, sizeof(*offsets), GFP_KERNEL);
enabled = kcalloc(connector_count, sizeof(bool), GFP_KERNEL);
if (!crtcs || !modes || !enabled || !offsets) {
-   DRM_ERROR("Memory allocation failed\n");
+   drm_err(client->dev, "Memory allocation failed\n");
ret = -ENOMEM;
goto out;
}
@@ -832,7 +832,7 @@ int drm_client_modeset_probe(struct drm_client_dev *client, 
unsigned int width,
  offsets, enabled, width, height) 
&&
!drm_client_target_preferred(connectors, connector_count, 
modes,
 offsets, enabled, width, 
height))
-   DRM_ERROR("Unable to find initial modes\n");
+   drm_err(client->dev, "Unable to find initial modes\n");
 
DRM_DEBUG_KMS("picking CRTCs for %dx%d config\n",
  width, height);
diff --git a/drivers/gpu/drm/drm_context.c b/drivers/gpu/drm/drm_context.c
index c6e6a3e7219a..f6d68fad8311 100644
--- a/drivers/gpu/drm/drm_context.c
+++ b/drivers/gpu/drm/drm_context.c
@@ -276,7 +276,7 @@ int drm_legacy_setsareactx(struct drm_device *dev, void 
*data,
 static int drm_c

Re: [PATCH v2 0/9] drm: Remove usage of deprecated DRM_* macros

2022-12-28 Thread Siddh Raman Pant
On Thu, 22 Dec 2022 21:10:34 +0530, Siddh Raman Pant wrote:
> Changes in v2:
> - Removed conversions to pr_*() in DRM_INFO, DRM_NOTE, and DRM_ERROR changes.
> - Due to above, DRM_NOTE usage cannot be removed and the patch is dropped.
> - DRY: NULL support is now achieved by way of a separate function.

I just noticed I forgot to change commit message mentioning pr_*()
after squashing. Apologies for this.

I will send a v3, rebased to drm-misc-next, and also fixing the docs message
pointed out by robot, as well as supporting NULL so pr_* stuff can be moved
to drm_*(NULL, ...).

Thanks,
Siddh


Re: [PATCH v2 21/21] staging: media: tegra-video: add tegra20 variant

2022-12-28 Thread Luca Ceresoli
On Fri, 23 Dec 2022 15:35:58 +0300
Dmitry Osipenko  wrote:

> 28.11.2022 18:23, Luca Ceresoli пишет:

...

> > +static const struct tegra_vip_ops tegra20_vip_ops = {
> > +   .vip_start_streaming = tegra20_vip_start_streaming,
> > +};
> > +
> > +const struct tegra_vip_soc tegra20_vip_soc = {
> > +   .ops = &tegra20_vip_ops,
> > +};  
> 
> Shouldn't this be placed in vip.c?

Indeed. Which means tegra210_csi_soc can be moved as well, so I'm adding
a small patch to the series to do that.

> Also looks like patch #20 won't link
> because tegra20_vip_soc is defined in patch #21.

You're right, we have a chicken-egg problem here. One solution would be
leaving tegra_vip_of_id_table empty in patch 20 and fill it only in
patch 21, but that would not be bisectable as patch 20 would introduce
code that nobody uses until patch 21. So I think it's better to squash
together patches 20+21.

-- 
Luca Ceresoli, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com


Re: [PATCH v3 03/11] drm/msm/dpu: Add SM8350 to hw catalog

2022-12-28 Thread Robert Foss
On Thu, 8 Dec 2022 at 00:42, Abhinav Kumar  wrote:
>
>
>
> On 12/5/2022 8:37 AM, Robert Foss wrote:
> > Add compatibility for SM8350 display subsystem, including
> > required entries in DPU hw catalog.
> >
> > Signed-off-by: Robert Foss 
> > ---
> >   .../gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c| 196 ++
> >   .../gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h|   1 +
> >   2 files changed, 197 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c 
> > b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
> > index 4dac90ee5b8a..ba26af73be53 100644
> > --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
> > +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
> > @@ -112,6 +112,15 @@
> >BIT(MDP_INTF3_INTR) | \
> >BIT(MDP_INTF4_INTR))
> >
> > +#define IRQ_SM8350_MASK (BIT(MDP_SSPP_TOP0_INTR) | \
> > +  BIT(MDP_SSPP_TOP0_INTR2) | \
> > +  BIT(MDP_SSPP_TOP0_HIST_INTR) | \
> > +  BIT(MDP_INTF0_7xxx_INTR) | \
> > +  BIT(MDP_INTF1_7xxx_INTR) | \
> > +  BIT(MDP_INTF2_7xxx_INTR) | \
> > +  BIT(MDP_INTF3_7xxx_INTR) | \
> > +  0)
> > +
> >   #define IRQ_SC8180X_MASK (BIT(MDP_SSPP_TOP0_INTR) | \
> > BIT(MDP_SSPP_TOP0_INTR2) | \
> > BIT(MDP_SSPP_TOP0_HIST_INTR) | \
> > @@ -375,6 +384,20 @@ static const struct dpu_caps sm8250_dpu_caps = {
> >   .pixel_ram_size = DEFAULT_PIXEL_RAM_SIZE,
> >   };
> >
> > +static const struct dpu_caps sm8350_dpu_caps = {
> > + .max_mixer_width = DEFAULT_DPU_OUTPUT_LINE_WIDTH,
> > + .max_mixer_blendstages = 0xb,
> > + .qseed_type = DPU_SSPP_SCALER_QSEED3LITE,
> > + .smart_dma_rev = DPU_SSPP_SMART_DMA_V2, /* TODO: v2.5 */
> > + .ubwc_version = DPU_HW_UBWC_VER_40,
> > + .has_src_split = true,
> > + .has_dim_layer = true,
> > + .has_idle_pc = true,
> > + .has_3d_merge = true,
> > + .max_linewidth = 4096,
> > + .pixel_ram_size = DEFAULT_PIXEL_RAM_SIZE,
> > +};
> > +
> >   static const struct dpu_caps sm8450_dpu_caps = {
> >   .max_mixer_width = DEFAULT_DPU_OUTPUT_LINE_WIDTH,
> >   .max_mixer_blendstages = 0xb,
> > @@ -526,6 +549,33 @@ static const struct dpu_mdp_cfg sm8250_mdp[] = {
> >   },
> >   };
> >
> > +static const struct dpu_mdp_cfg sm8350_mdp[] = {
> > + {
> > + .name = "top_0", .id = MDP_TOP,
> > + .base = 0x0, .len = 0x494,
> > + .features = 0,
> > + .highest_bank_bit = 0x3, /* TODO: 2 for LP_DDR4 */
> > + .clk_ctrls[DPU_CLK_CTRL_VIG0] = {
> > + .reg_off = 0x2ac, .bit_off = 0},
> > + .clk_ctrls[DPU_CLK_CTRL_VIG1] = {
> > + .reg_off = 0x2b4, .bit_off = 0},
> > + .clk_ctrls[DPU_CLK_CTRL_VIG2] = {
> > + .reg_off = 0x2bc, .bit_off = 0},
> > + .clk_ctrls[DPU_CLK_CTRL_VIG3] = {
> > + .reg_off = 0x2c4, .bit_off = 0},
> > + .clk_ctrls[DPU_CLK_CTRL_DMA0] = {
> > + .reg_off = 0x2ac, .bit_off = 8},
> > + .clk_ctrls[DPU_CLK_CTRL_DMA1] = {
> > + .reg_off = 0x2b4, .bit_off = 8},
> > + .clk_ctrls[DPU_CLK_CTRL_CURSOR0] = {
> > + .reg_off = 0x2bc, .bit_off = 8},
> > + .clk_ctrls[DPU_CLK_CTRL_CURSOR1] = {
> > + .reg_off = 0x2c4, .bit_off = 8},
> > + .clk_ctrls[DPU_CLK_CTRL_REG_DMA] = {
> > + .reg_off = 0x2bc, .bit_off = 20},
> > + },
> > +};
> > +
> >   static const struct dpu_mdp_cfg sm8450_mdp[] = {
> >   {
> >   .name = "top_0", .id = MDP_TOP,
> > @@ -711,6 +761,45 @@ static const struct dpu_ctl_cfg sm8150_ctl[] = {
> >   },
> >   };
> >
> > +static const struct dpu_ctl_cfg sm8350_ctl[] = {
> > + {
> > + .name = "ctl_0", .id = CTL_0,
> > + .base = 0x15000, .len = 0x1e8,
> > + .features = BIT(DPU_CTL_SPLIT_DISPLAY) | CTL_SC7280_MASK,
> > + .intr_start = DPU_IRQ_IDX(MDP_SSPP_TOP0_INTR2, 9),
> > + },
> > + {
> > + .name = "ctl_1", .id = CTL_1,
> > + .base = 0x16000, .len = 0x1e8,
> > + .features = BIT(DPU_CTL_SPLIT_DISPLAY) | CTL_SC7280_MASK,
> > + .intr_start = DPU_IRQ_IDX(MDP_SSPP_TOP0_INTR2, 10),
> > + },
> > + {
> > + .name = "ctl_2", .id = CTL_2,
> > + .base = 0x17000, .len = 0x1e8,
> > + .features = CTL_SC7280_MASK,
> > + .intr_start = DPU_IRQ_IDX(MDP_SSPP_TOP0_INTR2, 11),
> > + },
> > + {
> > + .name = "ctl_3", .id = CTL_3,
> > + .base = 0x18000, .len = 0x1e8,
> > + .features = CTL_SC7280_MASK,
> > + .intr_start = DPU_IRQ_IDX(MDP_SSPP_TOP0_INTR2, 12),
> > + },
> > + {
> > + .name = "ctl_4", .id = CTL_4,
> > + .base = 0x19000, .len = 0x1e8,
> > + .features = CTL_SC7280_MASK,
> > + .intr_start = DPU_IRQ_IDX(MDP_SSPP_TOP0_INTR2, 13),
> > + },
> > + {
> > + .name = "ctl_5", .id = CTL_5,
> > + .b

Re: [PATCH v7 0/6] clk/qcom: Support gdsc collapse polling using 'reset' interface

2022-12-28 Thread Akhil P Oommen
On 12/27/2022 11:54 PM, Bjorn Andersson wrote:
> On Mon, Dec 12, 2022 at 04:39:09PM +0100, Ulf Hansson wrote:
>> On Fri, 9 Dec 2022 at 18:36, Ulf Hansson  wrote:
>>> On Thu, 8 Dec 2022 at 22:06, Bjorn Andersson  wrote:
 On Thu, Dec 08, 2022 at 02:40:55PM +0100, Ulf Hansson wrote:
> On Wed, 7 Dec 2022 at 17:55, Bjorn Andersson  wrote:
>> On Wed, Dec 07, 2022 at 05:00:51PM +0100, Ulf Hansson wrote:
>>> On Thu, 1 Dec 2022 at 23:57, Bjorn Andersson  
>>> wrote:
 On Wed, Oct 05, 2022 at 02:36:58PM +0530, Akhil P Oommen wrote:
 @Ulf, Akhil has a power-domain for a piece of hardware which may be
 voted active by multiple different subsystems (co-processors/execution
 contexts) in the system.

 As such, during the powering down sequence we don't wait for the
 power-domain to turn off. But in the event of an error, the recovery
 mechanism relies on waiting for the hardware to settle in a powered off
 state.

 The proposal here is to use the reset framework to wait for this state
 to be reached, before continuing with the recovery mechanism in the
 client driver.
>>> I tried to review the series (see my other replies), but I am not sure
>>> I fully understand the consumer part.
>>>
>>> More exactly, when and who is going to pull the reset and at what point?
>>>
 Given our other discussions on quirky behavior, do you have any
 input/suggestions on this?

> Some clients like adreno gpu driver would like to ensure that its gdsc
> is collapsed at hardware during a gpu reset sequence. This is because 
> it
> has a votable gdsc which could be ON due to a vote from another 
> subsystem
> like tz, hyp etc or due to an internal hardware signal. To allow
> this, gpucc driver can expose an interface to the client driver using
> reset framework. Using this the client driver can trigger a polling 
> within
> the gdsc driver.
 @Akhil, this description is fairly generic. As we've reached the state
 where the hardware has settled and we return to the client, what
 prevents it from being powered up again?

 Or is it simply a question of it hitting the powered-off state, not
 necessarily staying there?
>>> Okay, so it's indeed the GPU driver that is going to assert/de-assert
>>> the reset at some point. Right?
>>>
>>> That seems like a reasonable approach to me, even if it's a bit
>>> unclear under what conditions that could happen.
>>>
>> Generally the disable-path of the power-domain does not check that the
>> power-domain is actually turned off, because the status might indicate
>> that the hardware is voting for the power-domain to be on.
> Is there a good reason why the HW needs to vote too, when the GPU
> driver is already in control?
>
> Or perhaps that depends on the running use case?
>
>> As part of the recovery of the GPU after some fatal fault, the GPU
>> driver does something which will cause the hardware votes for the
>> power-domain to be let go, and then the driver does pm_runtime_put().
> Okay. That "something", sounds like a device specific setting for the
> corresponding gdsc, right?
>
> So somehow the GPU driver needs to manage that setting, right?
>
>> But in this case the GPU driver wants to ensure that the power-domain is
>> actually powered down, before it does pm_runtime_get() again. To ensure
>> that the hardware lost its state...
> I see.
>
>> The proposal here is to use a reset to reach into the power-domain
>> provider and wait for the hardware to be turned off, before the GPU
>> driver attempts turning the power-domain on again.
>>
>>
>> In other words, there is no reset. This is a hack to make a normally
>> asynchronous pd.power_off() to be synchronous in this particular case.
> Alright, assuming I understood your clarifications above correctly
> (thanks!), I think I have got a much better picture now.
>
> Rather than abusing the reset interface, I think we should manage this
> through the genpd's power on/off notifiers (GENPD_NOTIFY_OFF). The GPU
> driver should register its corresponding device for them
> (dev_pm_genpd_add_notifier()).
>
> The trick however, is to make the behaviour of the power-domain for
> the gdsc (the genpd->power_off() callback) conditional on whether the
> HW is configured to vote or not. If the HW can vote, it should not
> poll for the state - and vice versa when the HW can't vote.
>
 Per Akhil's description I misunderstood who the other voters are; but
 either way it's not the same "HW configured" mechanism as the one we're
 already discussing.
>>> Okay, so this is another thing then.
>>>
>>

Re: [Intel-gfx] [PATCH v2] drm/i915: dell wyse 3040 shutdown fix

2022-12-28 Thread Jani Nikula
On Tue, 27 Dec 2022, Alexey Lukyachuk  wrote:
> On Tue, 27 Dec 2022 11:39:25 -0500
> Rodrigo Vivi  wrote:
>
>> On Sun, Dec 25, 2022 at 09:55:08PM +0300, Alexey Lukyanchuk wrote:
>> > dell wyse 3040 doesn't peform poweroff properly, but instead remains in 
>> > turned power on state.
>> 
>> okay, the motivation is explained in the commit msg..
>> 
>> > Additional mutex_lock and 
>> > intel_crtc_wait_for_next_vblank 
>> > feature 6.2 kernel resolve this trouble.
>> 
>> but this why is not very clear... seems that by magic it was found,
>> without explaining what race we are really protecting here.
>> 
>> but even worse is:
>> what about those many random vblank waits in the code? what's the
>> reasoning?
>> 
> I would like to say, that this solution was found in drm-tip repository:
> link: git://anongit.freedesktop.org/drm-tip
> I will quotate original commit message from Ville Syrjälä 
> : "The spec tells us to do a bunch of 
> vblank waits in the audio enable/disable sequences. Make it so."
> So it's just a backport of accepted patch.
> Which i wanna to propagate to stable versions

This is not how stable kernel backports work. Please read [1].

Does v6.2-rc1 work for you? It has all the relevant commits. Which
stable kernel are you trying to backport them to?

Though I must say I find it surprising that these changes would fix a
poweroff issue, and it certainly was not the goal. I'm wondering if it's
just a coincidence due to timing and/or locking changes.

Have you reported an issue at fdo gitlab [2]?


BR,
Jani.



[1] https://www.kernel.org/doc/html/latest/process/stable-kernel-rules.html
[2] https://gitlab.freedesktop.org/drm/intel/wikis/How-to-file-i915-bugs


-- 
Jani Nikula, Intel Open Source Graphics Center


Re: [PATCH v3 11/11] arm64: dts: qcom: sm8350-hdk: Enable lt9611uxc dsi-hdmi bridge

2022-12-28 Thread Robert Foss
On Mon, 5 Dec 2022 at 17:47, Krzysztof Kozlowski
 wrote:
>
> On 05/12/2022 17:37, Robert Foss wrote:
> > The sm8350-hdk ships with the LT9611 UXC DSI/HDMI bridge chip.
> >
> > In order to toggle the board to enable the HDMI output,
> > switch #7 & #8 on the rightmost multi-switch package have
> > to be toggled to On.
> >
> > Signed-off-by: Robert Foss 
>
> Thank you for your patch. There is something to discuss/improve.
>
> > +
> >  &slpi {
> >   status = "okay";
> >   firmware-name = "qcom/sm8350/slpi.mbn";
> > @@ -544,4 +633,20 @@ usb_hub_enabled_state: usb-hub-enabled-state {
> >   drive-strength = <2>;
> >   output-low;
> >   };
> > +
> > + lt9611_state: lt9611-state {
> > + lt9611_rst_pin {
>
> No underscores in node names.

Ack

>
> > + pins = "gpio48";
> > + function = "normal";
> > +
> > + output-high;
> > + input-disable;
> > + };
> > +
> > + lt9611_irq_pin {
>
> Ditto

Ack

>
> > + pins = "gpio50";
> > + function = "gpio";
> > + bias-disable;
> > + };
> > + };
> >  };
>
> Best regards,
> Krzysztof
>


Re: [PATCH linux-next] fbdev: use strscpy() to instead of strncpy()

2022-12-28 Thread Helge Deller

On 12/28/22 02:44, yang.yan...@zte.com.cn wrote:

From: Xu Panda 

The implementation of strscpy() is more robust and safer.
That's now the recommended way to copy NUL-terminated strings.

Signed-off-by: Xu Panda 
Signed-off-by: Yang Yang 
---
  drivers/video/fbdev/aty/atyfb_base.c | 3 +--
  1 file changed, 1 insertion(+), 2 deletions(-)


applied.
Thanks!
Helge




diff --git a/drivers/video/fbdev/aty/atyfb_base.c 
b/drivers/video/fbdev/aty/atyfb_base.c
index 0ccf5d401ecb..851c1236fddb 100644
--- a/drivers/video/fbdev/aty/atyfb_base.c
+++ b/drivers/video/fbdev/aty/atyfb_base.c
@@ -3192,8 +3192,7 @@ static void aty_init_lcd(struct atyfb_par *par, u32 
bios_base)
 * which we print to the screen.
 */
id = *(u8 *)par->lcd_table;
-   strncpy(model, (char *)par->lcd_table+1, 24);
-   model[23] = 0;
+   strscpy(model, (char *)par->lcd_table+1, 24);

width = par->lcd_width = *(u16 *)(par->lcd_table+25);
height = par->lcd_height = *(u16 *)(par->lcd_table+27);