From: David S. Miller Date: Tue, 8 Jul 2014 22:30:37 +0000 (-0700) Subject: Merge branch 'defxx-next' X-Git-Url: https://git.stricted.de/?a=commitdiff_plain;h=284a83a0766101933250437f373c4886ff87e8a4;p=GitHub%2Fmoto-9609%2Fandroid_kernel_motorola_exynos9610.git Merge branch 'defxx-next' Maciej W. Rozycki says: ==================== defxx: Fixes for 64-bit host support This mini patch series addresses issues with 64-bit host support for FDDI interface boards supported by the defxx driver where DMA mapping synchronisation is required on swiotlb systems. While PDQ, the DMA engine chip used with these boards, supports 48-bit addressing that would normally suffice for typical 64-bit systems in existence, the host bus interface chips used by individual implementations have their limitations as follows: * DEFTA or DEC FDDIcontroller/TURBOchannel -- there's no host bus interface chip, the PDQ connects to TURBOchannel directly; TURBOchannel supports DMA addressing of up to 16GB (34-bit addressing), however no TURBOchannel system has ever been made that supports more than 1GB of RAM, so in reality no remapping is ever required, * DEFEA or DEC FDDIcontroller/EISA -- the ESIC EISA interface chip only supports 32-bit addressing, all accesses beyond 4GB have to be remapped, * DEFPA or DEC FDDIcontroller/PCI -- the PFI PCI interface chip rev. 1 & 2 only support 32-bit addressing, they have 32 AD lines only both on the PDQ and the PCI side, and consequently no Dual Address Cycle support, so all accesses beyond 4GB have to be remapped; the range of addressing supported by PFI rev. 3 is currently not certain, however the chip is backwards compatible with earlier revisions and will work with code that supports them. Some other issues discovered in the course of correcting 64-bit support have been fixed as well. Each of the patches is functionally self-contained and can be applied independentely, although there may be mechanical dependencies making it necessary to apply patches in order. The driver suffers from non-standard formatting and while I did my best with these bug fixes to follow our coding style, I found some pieces hopeless, checkpatch.pl will complain. I plan to reformat the whole driver, that will inevitably require factoring out some pieces into separate functions, but that's going to be a major effort and therefore I want to do this separately, with no functional changes made at the same time. If anyone has specific suggestions as to how to reformat any of the pieces submitted here for a better layout, then I'll be happy to take them into account. And last but not least many thanks to Robert Coerver, who was the most recent person to report this problem with the driver and was kind enough to patiently try a few revisions of the driver update on his system as I was finding and addressing issues. ==================== Signed-off-by: David S. Miller --- 284a83a0766101933250437f373c4886ff87e8a4