Date: Sat, 6 Sep 2014 14:20:51 -0600 From: Warner Losh <imp@bsdimp.com> To: Ian Lepore <ian@FreeBSD.org> Cc: "freebsd-arm@freebsd.org" <freebsd-arm@freebsd.org>, ticso@cicely.de Subject: Re: Cubieboard: Spurious interrupt detected Message-ID: <AEEF4E90-27E9-43C7-8437-C593BE886846@bsdimp.com> In-Reply-To: <1410015268.1150.351.camel@revolution.hippie.lan> References: <2279481.3MX4OEDuCl@quad> <20140905215702.GL3196@cicely7.cicely.de> <1409958716.1150.321.camel@revolution.hippie.lan> <CAJ-Vmo=EJVFqNnMo_dzevGvFWLSR6LVfYbYmOot1bLZbCvVMTQ@mail.gmail.com> <20140906011526.GT82175@funkthat.com> <1409967197.1150.339.camel@revolution.hippie.lan> <20140906045403.GU82175@funkthat.com> <CAJ-VmonPttv58SGziDda--GooyLJdCcsGXCzP-UyGkO5oO2i=Q@mail.gmail.com> <1410015268.1150.351.camel@revolution.hippie.lan>
next in thread | previous in thread | raw e-mail | index | archive | help
--Apple-Mail=_699FFA10-C065-44E0-B38E-7E259302D757 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On Sep 6, 2014, at 8:54 AM, Ian Lepore <ian@FreeBSD.org> wrote: > On Fri, 2014-09-05 at 23:45 -0700, Adrian Chadd wrote: >> The device itself may have FIFOs and internal busses that also need = to >> be flushed. >>=20 >=20 > The question isn't whether or not it's sufficient, because it's > necessary. The device driver knows what its hardware requirements are > and should meet them. It doesn't not know what its parent bus > requirements are, and that's why it must call bus_space_barrier() to > handle architecture needs above the level of the device itself. Yea, all that bus_space_barrier() does is say =93We=92ve made sure that the CPU and all other bridges between the CPU and the device have any buffered writes pushed to the device.=94 If the device has = additional FIFOs and other things, that=92s 100% on the device writer. >>> I was just looking at i386's implementation of bus_space_barrier and >>> it just does a stack access... This won't be sufficient to clear = any >>> PCI bridges that may have the write still pending... >>=20 >> Right. The memory barrier semantics right now don't at all guarantee >> that bus and device FIFOs have actually been flushed. >>=20 > The fact that some architectures don't implement bus_space_barrier() = in > a way that's useful for that architecture is just a bug. It doesn't > change the fact that bus_space_barrier() is currently our only defined > MI interface to barriers in device space. Agreed. But PCI defines that reads flush out all prior writes. >> So I don't think doing it using the existing bus space barrier >> semantics is 'right'. For interrupts, it's highly likely that we do >> actually need device drivers to read from their interrupt register to >> ensure the update has been posted before returning. That's better = than >> causing entire L2 cache flushes. >>=20 >=20 > Where did you see code that does an "entire L2 cache flush"? You > didn't, you just saw a function name and made assumptions about what = it > does. The fact is, it does what is necessary for the architecture. = It > also happens to do what a write-then-read does on armv6, but that's > exactly the sort of assumption that should NOT be written into MI > code. =20 Yea, a bus barrier just means a temporal ordering. The exact strength of that guarantee is a bit fuzzy, but generally it means we know things are done. L2 is usually not an issue, because we have the devices mapped uncached. As for reading the ISR, that is device dependent. When using MSI things = are different because the status is pushed to the host and you get the info = from reading the host memory. Ideally, you=92d want to write to ack them without = having to do a read over PCIe, but even that=92s not always required (and on such = devices they would correct without bus barriers). Newer devices have been = designed to avoid round-trips over the PCIe bus and having semantics that matter. >> Question is - can we expose this somehow as a generic device method, >> so the higher bus layers can actually do something with it, or should >> we just leave it to device drivers to correctly do? >>=20 >=20 > In what way is that not EXACTLY whas bus_space_barrier() is defined to > do? >=20 > I've got to say, I don't understand all this pushback. We have one > function defined already that's intended to be the machine-independant > way to ensure that any previous access to hardware using bus_space = reads > and writes has completed, so why all this argument that it is not the > function to use? I agree with Ian here. If we=92ve messed up, we need to fix that. But = for the most part, devices that are in embedded land actually do the right thing = (more often than not). If we=92re doing something wrong on coherent architectures = that accidentally works, we should fix that. I may disagree with Ian about the need for some of the flushing based on = the notion that we should fix the drivers. I feel it just makes the problem = persist. Things should be more visibly broken. Ian thinks things should work, and I have a hard = time arguing with that position even if I disagree :). Warner --Apple-Mail=_699FFA10-C065-44E0-B38E-7E259302D757 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJUC2yjAAoJEGwc0Sh9sBEAjnEP/Rtr/UOfDdL2MoI1GNT8NzPf S15PjHdUHT2ucH/Iv+3hp9Az8ZKPzl+Phmvf7Jaf6mPBCvW0TXDVCxGYs5m3CMpR zNQiuS1cSNZreDjVQhiW39qmqIIKJ0xJYyHTdqq4iNh+9KVsGQpSQ3l493Xg4IFS SnbzO8Fia7lmypiIz/HDbEo8u9jtSqDBCIEeNyU7BEZezeNJ3TinvFsB1u3SgWDc YyHf4s64W6qKzzuWYTTQQ6QbjCImESvGJhvgx8FToUW2Mp350maqY1ivVfkF5l5p 3e1rLhQGNkDK1XUZLBja4BggtJxNrid3AlBM0si+k8/y9V32VSpQ5lG/i/2HyCQR E1Y/eItljaOeNaustVUZsU1MqNvQS/PYs8WKHEh/X52/JOw0nOiWz3E8uihzAxcZ SRg3s7xxBrvvQPKVkC1x+cH+OBi5NJACHrfSxF8rwzLl2W1qQsJmasTqn8H/Djsi EgojcbB3iJvP6BnrOVXlqAcmxdudjEAt2c5/mQPAzyc7xmMuZJ0DMeE+YJxHKdeX 7n1bJplwsNwmcW/w3ZHTmg8tr1c9ruIogaBbyY5d8YFoGrW6erIIoDuJ3p1A3GZI zm73d2piiG7e948FUtXXnkCBYQ9Ozvz+RJyoRW2VGAaPtsDvDbVgwBxjhmDpNVgC Ky3hCOw5O/reIlDSBlg4 =Jo1+ -----END PGP SIGNATURE----- --Apple-Mail=_699FFA10-C065-44E0-B38E-7E259302D757--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?AEEF4E90-27E9-43C7-8437-C593BE886846>