[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20160915145857.5827a7a3@lxorguk.ukuu.org.uk>
Date: Thu, 15 Sep 2016 14:58:57 +0100
From: One Thousand Gnomes <gnomes@...rguk.ukuu.org.uk>
To: Andrey Utkin <andrey_utkin@...tmail.com>
Cc: Hans Verkuil <hverkuil@...all.nl>,
Andrey Utkin <andrey.utkin@...p.bluecherry.net>,
Krzysztof HaĆasa <khalasa@...p.pl>,
linux-kernel@...r.kernel.org, linux-media@...r.kernel.org,
Mauro Carvalho Chehab <mchehab@...nel.org>,
Hans Verkuil <hans.verkuil@...co.com>,
Ismael Luceno <ismael@...ev.co.uk>,
Bluecherry Maintainers <maintainers@...echerrydvr.com>
Subject: Re: solo6010 modprobe lockup since e1ceb25a (v4.3 regression)
On Thu, 15 Sep 2016 16:19:52 +0300
Andrey Utkin <andrey_utkin@...tmail.com> wrote:
> On Thu, Sep 15, 2016 at 03:15:53PM +0200, Hans Verkuil wrote:
> > It could be related to the fact that a PCI write may be delayed unless
> > it is followed by a read (see also the comments in drivers/media/pci/ivtv/ivtv-driver.h).
>
> Thanks for explanation!
>
> > That was probably the reason for the pci_read_config_word in the reg_write
> > code. Try putting that back (and just that).
>
> In this case reg_write becomes not atomic, thus spinlock would be
> required again here, right?
No - PCI writes are ordered but may not complete until the next read or
config access. That ordering isn't affected by things like spin locking
as it is a property of the bus.
Usually this only matters in obscure cases - timing is one of them, and
the other is when freeing memory because writes are posted both ways so
you need to write to stop the transfer, read to ensure the transfer has
completed and then free the target memory.
Alan
Powered by blists - more mailing lists