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: Fri, 22 Mar 2024 12:18:57 -0400 [thread overview]
Message-ID: <2dbf138f-5112-48e1-85a6-9e3ad84ec4a6@linux.dev> (raw)
In-Reply-To: <d6a8bc5c-aed9-4ef4-adb2-dc171106b44b@ideasonboard.com>
On 3/22/24 01:32, Tomi Valkeinen wrote:
> On 21/03/2024 21:17, Sean Anderson wrote:
>> On 3/21/24 15:08, Tomi Valkeinen wrote:
>>> On 21/03/2024 20:01, Sean Anderson wrote:
>>>> On 3/21/24 13:25, Tomi Valkeinen wrote:
>>>>> On 21/03/2024 17:52, Sean Anderson wrote:
>>>>>> On 3/20/24 02:53, Tomi Valkeinen wrote:
>>>>>>> On 20/03/2024 00:51, Sean Anderson wrote:
>>>>>>> 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.
>>>>>
>>>>> The less concurrency, the better...Which is why it would be nice to do it all in the threaded irq.
>>>>
>>>> Yeah, but we can use a mutex for this which means there is not too much
>>>> interesting going on.
>>>
>>> Ok. Yep, if we get (hopefully) a single mutex with clearly defined fields that it protects, I'm ok with workqueues.
>>>
>>> I'd still prefer just one workqueue, though...
>>
>> Yeah, but then we need a spinlock or something to tell the workqueue what it should do.
>
> Yep. We could also always look at the HPD (if we drop the big sleeps) in the wq, and have a flag for the HPD IRQ, which would reduce the state to a single bit.
How about something like
zynqmp_dp_irq_handler(...)
{
/* Read status and handle underflow/overflow/vblank */
status &= ZYNQMP_DP_INT_HPD_EVENT | ZYNQMP_DP_INT_HPD_IRQ;
if (status) {
atomic_or(status, &dp->status);
return IRQ_WAKE_THREAD;
}
return IRQ_HANDLED;
}
zynqmp_dp_thread_handler(...)
{
status = atomic_xchg(&dp->status, 0);
/* process HPD stuff */
}
which gets rid of the workqueue too.
--Sean
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
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: Fri, 22 Mar 2024 12:18:57 -0400 [thread overview]
Message-ID: <2dbf138f-5112-48e1-85a6-9e3ad84ec4a6@linux.dev> (raw)
In-Reply-To: <d6a8bc5c-aed9-4ef4-adb2-dc171106b44b@ideasonboard.com>
On 3/22/24 01:32, Tomi Valkeinen wrote:
> On 21/03/2024 21:17, Sean Anderson wrote:
>> On 3/21/24 15:08, Tomi Valkeinen wrote:
>>> On 21/03/2024 20:01, Sean Anderson wrote:
>>>> On 3/21/24 13:25, Tomi Valkeinen wrote:
>>>>> On 21/03/2024 17:52, Sean Anderson wrote:
>>>>>> On 3/20/24 02:53, Tomi Valkeinen wrote:
>>>>>>> On 20/03/2024 00:51, Sean Anderson wrote:
>>>>>>> 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.
>>>>>
>>>>> The less concurrency, the better...Which is why it would be nice to do it all in the threaded irq.
>>>>
>>>> Yeah, but we can use a mutex for this which means there is not too much
>>>> interesting going on.
>>>
>>> Ok. Yep, if we get (hopefully) a single mutex with clearly defined fields that it protects, I'm ok with workqueues.
>>>
>>> I'd still prefer just one workqueue, though...
>>
>> Yeah, but then we need a spinlock or something to tell the workqueue what it should do.
>
> Yep. We could also always look at the HPD (if we drop the big sleeps) in the wq, and have a flag for the HPD IRQ, which would reduce the state to a single bit.
How about something like
zynqmp_dp_irq_handler(...)
{
/* Read status and handle underflow/overflow/vblank */
status &= ZYNQMP_DP_INT_HPD_EVENT | ZYNQMP_DP_INT_HPD_IRQ;
if (status) {
atomic_or(status, &dp->status);
return IRQ_WAKE_THREAD;
}
return IRQ_HANDLED;
}
zynqmp_dp_thread_handler(...)
{
status = atomic_xchg(&dp->status, 0);
/* process HPD stuff */
}
which gets rid of the workqueue too.
--Sean
next prev parent reply other threads:[~2024-03-22 16:19 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
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 [this message]
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=2dbf138f-5112-48e1-85a6-9e3ad84ec4a6@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: link
Be 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.