Hello, Sergei. Sergei Shtylyov wrote: > Tejun Heo wrote: >> This is the first take of separate-out-SFF-and-BMDMA patchset. > > If BMDMA means the well known Intel BMIDE spec (also known as > SFF-8038i) this separation starts to sound funny. :-) Heh.. we had this discussion before. SFF is TF ATA in libata. >> Historically, ATA meant SFF (or TASKFILE interface) plus BMDMA and >> > ATA means the taskfile interface plus the command set -- and nothing > else. SFF couldn't mean taskfile interface because SFF ATAPI specs > refers to ATA in this part -- it could only mean either ATAPI > command set or BMDMA (BMIDE) interface which is spec'ed by > SFF-8038i. Yeah, I know now. We can either do s/sff/tf/ or just accept that SFF is TF in libata for whatever reason. Maybe it's not Small Form Factor but something like Strange Form of tF. :-) >> that holds true for many modern SATA controllers. This was reflected >> in libata implementation and libata core layer and SFF/BMDMA support >> used to be all tangled in one piece. > > The "all tangled" expression describes this mess quite well. :-) So, the above is actually about the tangledness between ATA SFF and BMDMA. >> Another issue which surpassed with the addition of all the legacy, >> platform and somewhat peculiar PATA drivers is that now there are >> enough drivers which use SFF interface but use its own DMA interface >> or don't support DMA at all. This, in similar fashion, led those >> drivers to fake certain level of BMDMA functionality to please the >> libata SFF/BMDMA layer. This led to the following interesting >> solutions in low level drivers. >> >> 1. For BMDMA drivers which don't use traditional BMDMA register, >> ata_bmdma_mode_filter() incorrectly inhibits DMA modes. Those >> drivers either have to inherit from ata_sff_port_ops or clear >> ->mode_filter explicitly. >> >> 2. non-BMDMA drivers call into BMDMA PRD table allocation. It doesn't >> actually allocate PRD table if bmdma_addr is not initialized but is >> still confusing. >> >> 3. For BMDMA drivers which don't use traditional BMDMA register, some >> methods might not be invoked as expected (e.g. bmdma_stop from >> ata_sff_post_internal_cmd()). >> > > What do you mean by BMDMA here? I'm now at a loss... Rephrased: Drivers which inherit from bmdma_port_ops as they share many similar characteristics with the standard BMDMA interface but uses different register format. >> 4. SFF drivers w/ custom DMA interface implement noop BMDMA ops >> worrying libata core might call into one of them. > > Are those drivers not the same as "BMDMA drivers which don't use > traditional BMDMA register"? Rephrased: Drivers which uses ATA TF interface but uses completely custom DMA interface instead of BMDMA or something similar to it. Thanks. -- tejun -- 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
