> On Fri, Aug 23, 2013 at 9:59 AM, Andreas Werner <wernera...@gmx.de> wrote: >> >> >> Hi, >> thank you for your answer. >> >> So we are two persons for now who need WT :-) >> >> Im currently working on an ethernet driver for our own ETH core. >> The problem is that one requirement is to not use DMA to transmit or >> receive the data. >> This means the that the ethernet buffer are not located in the main >> memory. They are located in >> the FPGA. >> >> To transmit or receive a frame, i have to read or write to mmio to get >> the data. >> >> Intel has introduced the command "clflush" which can flush a cache line. >> I wanted to activate the caches for those mmio (eth buffer) to speed up >> the transmit or receive. >> After that the transfer over PCIe uses burst read/write. >> >> The problem was if i set the buffer to Write-Back and call clflush on >> those mmio-addresses, the system crashed without any output. >> I found this articel >> http://software.intel.com/en-us/forums/topic/393070.[http://software.intel.com/en-us/forums/topic/393070] >> >> After that i configured the transmit buffer to be Write-Combining (only >> write to that adresses) using ioremap_wc, and >> the receive buffer to be Write-Through (ioremap_cache + mtrr Write-Back >> + my Kernel Hack :-)) everything worked fine. >> The other configuration Register on the FPGA are just mapped with >> ioremap. > > I'm curious: have you tried movntdqa on UC memory for this? > (Certainly WP or WT is easier.) > > In any case, I hope to have patches to support WP and WT without using > PAT reasonably soon. > >> >> On PCIe Tracer i can see the burst read/write on my device. >> >> Is it possible to get hits into the Kernel? >> >> My modification in arch/x86/mm/pat.c: >> >> --- pat.c.orig 2013-02-03 01:18:49.491879407 +0100 >> +++ pat.c 2013-02-03 01:19:19.053509836 +0100 >> @@ -149,10 +149,16 @@ static unsigned long pat_x_mtrr_type(u64 >> u8 mtrr_type; >> >> mtrr_type = mtrr_type_lookup(start, end); >> - if (mtrr_type != MTRR_TYPE_WRBACK) >> + >> + if (mtrr_type == MTRR_TYPE_WRTHROUGH) { >> + return _PAGE_CACHE_WB; >> + } >> + else if( mtrr_type == MTRR_TYPE_WRBACK ) >> + return _PAGE_CACHE_WB; >> + else >> return _PAGE_CACHE_UC_MINUS; >> - >> - return _PAGE_CACHE_WB; >> + >> } >> >> return req_type; >> > > That seems more or less reasonable to me. If you want it included, > send it to x...@kernel.org (cc lkml) and see what they say. > > It would be prettier if you combined the conditions into a single > if/else, though. > >> >> Best regards. >> >> >> Gesendet: Montag, 12. August 2013 um 19:53 Uhr >> Von: "Andy Lutomirski" <l...@amacapital.net> >> An: "Andreas Werner" <wernera...@gmx.de> >> Cc: linux-kernel@vger.kernel.org >> Betreff: Re: question about ioremap_cache and PAT >> On 08/11/2013 09:50 AM, Andreas Werner wrote: >>> Hi i have a question about ioremap_cache and the resulting PAT >>> attribute on X86 system. If I configure the mtrr to Write-Through for >>> an adress range, and call ioremap_cache to map the mmio, the resulting >>> PAT attribute is set to UC. >>> If I check the Intel document IA-32 SDM vol 3a, the resulting PAT >>> attribute should be WB. >>> >>> I found the function pat_x_mtrr_type in arch/x86/mm/pat.c where the >>> resulting attribute is returned. There will be always UC return expect >>> if the MTRR is set to WB. >>> >>> Why is there only WB or UC returned? In the Intel document there are a >>> lot of combinations "allowed". >>> >>> I need a Attribute of WT, so what i did is to modify the >>> pat_x_mtrr_type function to return also WB if the MTRR is set to WT. >>> >>> Is this a solution to solve that or whats the reasion why the kernel >>> doesn´t support this combination? >> >> The kernel doesn't support it because I'm apparently the only person who >> ever wanted it and I haven't implemented it yet. >> >> This stuff is handled in hardware, so modifying the kernel's idea of >> what hardware does won't do much. Also, the kernel using MTRRs is on >> its (very slow) way out. You could probably hack something up, but I >> can almost guarantee that hpa, etc won't accept the patches. >> >> That being said, I'm planning to support WT directly using PAT in the >> near future. This will work on most recent cpus (there are errata that >> will prevent use of the high PAT entries on some cpus). >> >> What do you need WT for? I want it for NVDIMMs, and all I need to get >> started now is a heatsink*, so I'll hopefully start implementing this >> stuff in the next week or so. >> >> --Andy >> >> * Damnit, Intel, it's not 2003 any more. You already figured out that >> heatsinks want screw holes. But why couldn't you make sure that all >> so-called "LGA 2011" sockets have the screw holes in the same place? >> >> >>> >>> Best regards >>> >>> B >>> B >>> B >>> B >>> B >>> B >>> B >>> B >>> B >>> B >>> B >>> B >>> B >>> B >>> B >>> B >>> B >>> B >>> A >>> A >>> A >>> A >>> A >>> A >>> A >>> A >>> A >>> A >>> A >>> A >>> A >>> A >>> A >>> B >>> B >>> B >>> Best regards >>> >> > > > > -- > Andy Lutomirski > AMA Capital Management, LLC >
-- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/