[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <63c64a2f-211e-2f62-21e7-289f0cc69df0@gmail.com>
Date: Fri, 23 Feb 2018 16:49:46 +0200
From: Oleksandr Andrushchenko <andr2000@...il.com>
To: Boris Ostrovsky <boris.ostrovsky@...cle.com>,
xen-devel@...ts.xenproject.org, linux-kernel@...r.kernel.org,
dri-devel@...ts.freedesktop.org, airlied@...ux.ie,
daniel.vetter@...el.com, seanpaul@...omium.org,
gustavo@...ovan.org, jgross@...e.com, konrad.wilk@...cle.com
Cc: Oleksandr Andrushchenko <oleksandr_andrushchenko@...m.com>
Subject: Re: [PATCH 4/9] drm/xen-front: Implement Xen event channel handling
On 02/23/2018 04:44 PM, Boris Ostrovsky wrote:
> On 02/23/2018 02:00 AM, Oleksandr Andrushchenko wrote:
>> On 02/23/2018 01:50 AM, Boris Ostrovsky wrote:
>>> On 02/21/2018 03:03 AM, Oleksandr Andrushchenko wrote:
>>>> +
>>>> +static irqreturn_t evtchnl_interrupt_ctrl(int irq, void *dev_id)
>>>> +{
>>>> + struct xen_drm_front_evtchnl *evtchnl = dev_id;
>>>> + struct xen_drm_front_info *front_info = evtchnl->front_info;
>>>> + struct xendispl_resp *resp;
>>>> + RING_IDX i, rp;
>>>> + unsigned long flags;
>>>> +
>>>> + spin_lock_irqsave(&front_info->io_lock, flags);
>>>> +
>>>> + if (unlikely(evtchnl->state != EVTCHNL_STATE_CONNECTED))
>>>> + goto out;
>>> Do you need to check the state under lock? (in other routines too).
>> not really, will move out of the lock in interrupt handlers
>> other places (I assume you refer to be_stream_do_io)
>
> I was mostly referring to evtchnl_interrupt_evt().
ah, then we are on the same page: I will move the check
in interrupt handlers
> -boris
>
>
>> it is set under lock as a part of atomic operation, e.g.
>> we get a new request pointer from the ring and reset completion
>> So, those places still seem to be ok
Powered by blists - more mailing lists