Christer Weinigel wrote:I actually analyzed the case of the PIT in the case of the implementation of a real chipset. In our case, running the PIT at 1.19318 MHz when the rest of the chipset core was running at 100 MHz introduced a huge amount of extra complexity and we really wanted to get rid of it. As it turns out, the PIT interface is ill-defined if run at a higher frequency; you can get undefined values as a result of a write followed by a read if there is no intervening PIT clock, which of course in the standard interface never happens. So in the end, we had to build all the synchronizers, backpressure controls and other crap that went along with an additional clock domain. As a result of that experience, I really don't think you will *ever* see a PIT that runs at a modern frequency. Building a 100 MHz PIC, however, was not a problem, and being able to sink accesses at full speed meant we didn't have to implement flow control. -hpa --
| Greg KH | [GIT PATCH] driver core patches against 2.6.24 |
| debian developer | Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3 |
| Vu Pham | Re: [Scst-devel] Integration of SCST in the mainstream Linux kernel |
| Adrian Bunk | Re: Linux 2.6.21 |
git: | |
| Gerrit Renker | [PATCH 15/37] dccp: Set per-connection CCIDs via socket options |
| Jarek Poplawski | [PATCH] pkt_sched: Destroy gen estimators under rtnl_lock(). |
| Radu Rendec | Endianness problem with u32 classifier hash masks |
| Benjamin Herrenschmidt | [PATCH 0/11] ibm_newemac: Candidate patches for 2.6.25 |
