| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Message-Id: <1188639327.5992.3.camel@localhost.localdomain> Date: Sat, 01 Sep 2007 10:35:27 +0100 From: Adrian McMenamin <adrian@...golddream.dyndns.info> To: Mike Frysinger <vapier@...too.org> Cc: linuxsh-dev@...ts.sourceforge.net, Adrian McMenamin <lkmladrian@...il.com>, Paul Mundt <lethal@...ux-sh.org>, linux-kernel@...r.kernel.org, Mike Frysinger <vapier.adi@...il.com> Subject: Re: [PATCH] Patch pvr2 driver to allow development of maple bus driver On Fri, 2007-08-31 at 23:02 -0400, Mike Frysinger wrote: > i really dont know how the maple bus works or what piece of hardware is wired > up to the same interrupt line. my point is that if the other device fires an > interrupt, the pvr interrupt handler may be executed and attempt to do work > when in reality the pvr was not the source of the interrupt. > -mike The interrupt is *always* fired by the PVR - it is the VBLANK - ie essentially screen refresh. It is *never* generated by the maple bus. However, the maple bus is/can be hardware synced - which means once that setting is made then the hardware will *always* be polled on the VBLANK. In other words there is no need to check which device is interrupt is for, because it is *always* going to be for both of them. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists