>>>>> "Jordan" == Jordan Crouse <jordan.crouse@xxxxxxx> writes: Jordan> That should work on any AMD VSA derivatives. There are some Jordan> who may have rolled their own, and they don't support the same Jordan> virtual registers. in that case, you can check if SMIs are Jordan> enabled - that would be a reasonable indication that there is Jordan> something VSAish out there. I'll try this later and see what comes up. But I'm not sure I see the advantage of having two ways to configure the 5536. I was simply interested in getting things configured correctly. I agree that ideally all platforms would simply Do The Right Thing. However, I took the pragmatic/safe approach and used the MSRs to configure the beast. The only reason I even tried is that this is a setup issue exclusively. Had the actual I/O interface been hiding in a similar fashion I wouldn't have bothered. Early on I also had some funny results with PIO so another reason I wrote pata_cs5536 was to use the values specified in the databook. It seemed cleaner to have a tiny separate driver than to wedge another set of timings into pata_amd.c. I agree that it would be silly to have two drivers if there was actual functionality lurking in them. But as it stands most of the pata_* drivers are simply configuration templates and nothing more. Anyway. That's my personal take on it. If there's a general consensus that the timings should be in pata_amd.c then so be it. Jordan> But you bring up another point - I'm not sure that Martin Jordan> _doesn't_ have VSA. He is initializing this as a PCI driver, Jordan> so he has something out there listening to CF8/CFC, or he's Jordan> emulating the OLPC spoof mechanism [1]. The board I'm using has a BIOS which exposes the IDE registers in PCI space but doesn't appear to listen when they are written to. I'm hoping that will get fixed eventually. PS. So what's the story wrt. a PRD length of 0? -- Martin K. Petersen http://mkp.net/ - To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
