From: Sean Anderson <sean.anderson@linux.dev> To: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com> Cc: Michal Simek <michal.simek@amd.com>, David Airlie <airlied@gmail.com>, linux-kernel@vger.kernel.org, Daniel Vetter <daniel@ffwll.ch>, linux-arm-kernel@lists.infradead.org, Laurent Pinchart <laurent.pinchart@ideasonboard.com>, Maarten Lankhorst <maarten.lankhorst@linux.intel.com>, Maxime Ripard <mripard@kernel.org>, Thomas Zimmermann <tzimmermann@suse.de>, dri-devel@lists.freedesktop.org Subject: Re: [PATCH v2 5/8] drm: zynqmp_dp: Don't retrain the link in our IRQ Date: Thu, 21 Mar 2024 11:52:23 -0400 [thread overview] Message-ID: <53b2df23-d5ea-498b-a501-b64f753c0074@linux.dev> (raw) In-Reply-To: <ca4de45b-302c-4eea-bd6b-8c04e2ed89cb@ideasonboard.com> On 3/20/24 02:53, Tomi Valkeinen wrote: > On 20/03/2024 00:51, Sean Anderson wrote: >> Retraining the link can take a while, and might involve waiting for >> DPCD reads/writes to complete. This is inappropriate for an IRQ handler. >> Just schedule this work for later completion. This is racy, but will be >> fixed in the next commit. > > You should add the locks first, and use them here, rather than first > adding a buggy commit and fixing it in the next one. I didn't think I could add the locks first since I only noticed the IRQ was threaded right before sending out this series. So yeah, we could add locking, add the workqueue, and then unthread the IRQ. >> Signed-off-by: Sean Anderson <sean.anderson@linux.dev> >> --- >> Actually, on second look this IRQ is threaded. So why do we have a >> workqueue for HPD events? Maybe we should make it unthreaded? > > Indeed, there's not much work being done in the IRQ handler. I don't know why it's threaded. > > We could move the queued work to be inside the threaded irq handler, > but with a quick look, the HPD work has lines like "msleep(100)" (and > that's inside a for loop...), which is probably not a good thing to do > even in threaded irq handler. > > Although I'm not sure if that code is good to have anywhere. Why do we > even have such code in the HPD work path... We already got the HPD > interrupt. What does "It takes some delay (ex, 100 ~ 500 msec) to get > the HPD signal with some monitors" even mean... The documentation for this bit is | HPD_STATE 0 ro 0x0 Contains the raw state of the HPD pin on the DisplayPort connector. So I think the idea is to perform some debouncing. > Would it be possible to clean up the work funcs a bit (I haven't > looked a the new work func yet), to remove the worst extra sleeps, and > just do all that inside the threaded irq handler? Probably not, since a HPD IRQ results in link retraining, which can take a while. > Do we need to handle interrupts while either delayed work is being done? Probably not. > If we do need a delayed work, would just one work be enough which > handles both HPD_EVENT and HPD_IRQ, instead of two? Maybe, but then we need to determine which pending events we need to handle. I think since we have only two events it will be easier to just have separate workqueues. --Sean
WARNING: multiple messages have this Message-ID (diff)
From: Sean Anderson <sean.anderson@linux.dev> To: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com> Cc: Michal Simek <michal.simek@amd.com>, David Airlie <airlied@gmail.com>, linux-kernel@vger.kernel.org, Daniel Vetter <daniel@ffwll.ch>, linux-arm-kernel@lists.infradead.org, Laurent Pinchart <laurent.pinchart@ideasonboard.com>, Maarten Lankhorst <maarten.lankhorst@linux.intel.com>, Maxime Ripard <mripard@kernel.org>, Thomas Zimmermann <tzimmermann@suse.de>, dri-devel@lists.freedesktop.org Subject: Re: [PATCH v2 5/8] drm: zynqmp_dp: Don't retrain the link in our IRQ Date: Thu, 21 Mar 2024 11:52:23 -0400 [thread overview] Message-ID: <53b2df23-d5ea-498b-a501-b64f753c0074@linux.dev> (raw) In-Reply-To: <ca4de45b-302c-4eea-bd6b-8c04e2ed89cb@ideasonboard.com> On 3/20/24 02:53, Tomi Valkeinen wrote: > On 20/03/2024 00:51, Sean Anderson wrote: >> Retraining the link can take a while, and might involve waiting for >> DPCD reads/writes to complete. This is inappropriate for an IRQ handler. >> Just schedule this work for later completion. This is racy, but will be >> fixed in the next commit. > > You should add the locks first, and use them here, rather than first > adding a buggy commit and fixing it in the next one. I didn't think I could add the locks first since I only noticed the IRQ was threaded right before sending out this series. So yeah, we could add locking, add the workqueue, and then unthread the IRQ. >> Signed-off-by: Sean Anderson <sean.anderson@linux.dev> >> --- >> Actually, on second look this IRQ is threaded. So why do we have a >> workqueue for HPD events? Maybe we should make it unthreaded? > > Indeed, there's not much work being done in the IRQ handler. I don't know why it's threaded. > > We could move the queued work to be inside the threaded irq handler, > but with a quick look, the HPD work has lines like "msleep(100)" (and > that's inside a for loop...), which is probably not a good thing to do > even in threaded irq handler. > > Although I'm not sure if that code is good to have anywhere. Why do we > even have such code in the HPD work path... We already got the HPD > interrupt. What does "It takes some delay (ex, 100 ~ 500 msec) to get > the HPD signal with some monitors" even mean... The documentation for this bit is | HPD_STATE 0 ro 0x0 Contains the raw state of the HPD pin on the DisplayPort connector. So I think the idea is to perform some debouncing. > Would it be possible to clean up the work funcs a bit (I haven't > looked a the new work func yet), to remove the worst extra sleeps, and > just do all that inside the threaded irq handler? Probably not, since a HPD IRQ results in link retraining, which can take a while. > Do we need to handle interrupts while either delayed work is being done? Probably not. > If we do need a delayed work, would just one work be enough which > handles both HPD_EVENT and HPD_IRQ, instead of two? Maybe, but then we need to determine which pending events we need to handle. I think since we have only two events it will be easier to just have separate workqueues. --Sean _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2024-03-21 15:52 UTC|newest] Thread overview: 72+ messages / expand[flat|nested] mbox.gz Atom feed top 2024-03-19 22:51 [PATCH v2 0/8] drm: zynqmp_dp: Misc. patches and debugfs support Sean Anderson 2024-03-19 22:51 ` Sean Anderson 2024-03-19 22:51 ` [PATCH v2 1/8] drm: xlnx: Fix kerneldoc Sean Anderson 2024-03-19 22:51 ` Sean Anderson 2024-03-20 5:42 ` Tomi Valkeinen 2024-03-20 5:42 ` Tomi Valkeinen 2024-03-20 6:05 ` Randy Dunlap 2024-03-20 6:05 ` Randy Dunlap 2024-03-21 15:33 ` Sean Anderson 2024-03-21 15:33 ` Sean Anderson 2024-03-22 5:50 ` Tomi Valkeinen 2024-03-22 5:50 ` Tomi Valkeinen 2024-03-22 15:22 ` Sean Anderson 2024-03-22 15:22 ` Sean Anderson 2024-03-19 22:51 ` [PATCH v2 2/8] drm: zynqmp_dp: Downgrade log level for aux retries message Sean Anderson 2024-03-19 22:51 ` Sean Anderson 2024-03-20 5:46 ` Tomi Valkeinen 2024-03-20 5:46 ` Tomi Valkeinen 2024-03-19 22:51 ` [PATCH v2 3/8] drm: zynqmp_dp: Adjust training values per-lane Sean Anderson 2024-03-19 22:51 ` Sean Anderson 2024-03-20 5:57 ` Tomi Valkeinen 2024-03-20 5:57 ` Tomi Valkeinen 2024-03-21 15:35 ` Sean Anderson 2024-03-21 15:35 ` Sean Anderson 2024-03-19 22:51 ` [PATCH v2 4/8] drm: zynqmp_dp: Rearrange zynqmp_dp for better padding Sean Anderson 2024-03-19 22:51 ` Sean Anderson 2024-03-20 6:14 ` Tomi Valkeinen 2024-03-20 6:14 ` Tomi Valkeinen 2024-03-21 15:43 ` Sean Anderson 2024-03-21 15:43 ` Sean Anderson 2024-03-19 22:51 ` [PATCH v2 5/8] drm: zynqmp_dp: Don't retrain the link in our IRQ Sean Anderson 2024-03-19 22:51 ` Sean Anderson 2024-03-20 6:53 ` Tomi Valkeinen 2024-03-20 6:53 ` Tomi Valkeinen 2024-03-21 15:52 ` Sean Anderson [this message] 2024-03-21 15:52 ` Sean Anderson 2024-03-21 17:25 ` Tomi Valkeinen 2024-03-21 17:25 ` Tomi Valkeinen 2024-03-21 18:01 ` Sean Anderson 2024-03-21 18:01 ` Sean Anderson 2024-03-21 19:08 ` Tomi Valkeinen 2024-03-21 19:08 ` Tomi Valkeinen 2024-03-21 19:17 ` Sean Anderson 2024-03-21 19:17 ` Sean Anderson 2024-03-22 5:32 ` Tomi Valkeinen 2024-03-22 5:32 ` Tomi Valkeinen 2024-03-22 16:18 ` Sean Anderson 2024-03-22 16:18 ` Sean Anderson 2024-03-22 18:09 ` Tomi Valkeinen 2024-03-22 18:09 ` Tomi Valkeinen 2024-03-22 21:22 ` Sean Anderson 2024-03-22 21:22 ` Sean Anderson 2024-03-23 8:54 ` Tomi Valkeinen 2024-03-23 8:54 ` Tomi Valkeinen 2024-03-19 22:51 ` [PATCH v2 6/8] drm: zynqmp_dp: Add locking Sean Anderson 2024-03-19 22:51 ` Sean Anderson 2024-03-19 22:51 ` [PATCH v2 7/8] drm: zynqmp_dp: Split off several helper functions Sean Anderson 2024-03-19 22:51 ` Sean Anderson 2024-03-20 7:36 ` Tomi Valkeinen 2024-03-20 7:36 ` Tomi Valkeinen 2024-03-19 22:51 ` [PATCH v2 8/8] drm: zynqmp_dp: Add debugfs interface for compliance testing Sean Anderson 2024-03-19 22:51 ` Sean Anderson 2024-03-20 7:49 ` Tomi Valkeinen 2024-03-20 7:49 ` Tomi Valkeinen 2024-03-21 16:08 ` Sean Anderson 2024-03-21 16:08 ` Sean Anderson 2024-03-21 16:31 ` Tomi Valkeinen 2024-03-21 16:31 ` Tomi Valkeinen 2024-03-21 16:35 ` Sean Anderson 2024-03-21 16:35 ` Sean Anderson 2024-03-19 23:02 ` [PATCH v2 0/8] drm: zynqmp_dp: Misc. patches and debugfs support Sean Anderson 2024-03-19 23:02 ` Sean Anderson
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=53b2df23-d5ea-498b-a501-b64f753c0074@linux.dev \ --to=sean.anderson@linux.dev \ --cc=airlied@gmail.com \ --cc=daniel@ffwll.ch \ --cc=dri-devel@lists.freedesktop.org \ --cc=laurent.pinchart@ideasonboard.com \ --cc=linux-arm-kernel@lists.infradead.org \ --cc=linux-kernel@vger.kernel.org \ --cc=maarten.lankhorst@linux.intel.com \ --cc=michal.simek@amd.com \ --cc=mripard@kernel.org \ --cc=tomi.valkeinen@ideasonboard.com \ --cc=tzimmermann@suse.de \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.