From: "Luis R. Rodriguez" <[email protected]>
If and when this gets enabled the driver could should split
up IO memory space properly and that is quite a bit of work.
Just remove the uncommented dead MTRR code then.
There are a few motivations for this:
a) Take advantage of PAT when available
b) Help bury MTRR code away, MTRR is architecture specific and on
x86 its replaced by PAT
c) Help with the goal of eventually using _PAGE_CACHE_UC over
_PAGE_CACHE_UC_MINUS on x86 on ioremap_nocache() (see commit
de33c442e titled "x86 PAT: fix performance drop for glx,
use UC minus for ioremap(), ioremap_nocache() and
pci_mmap_page_range()")
Cc: Toshi Kani <[email protected]>
Cc: Christoph Hellwig <[email protected]>
Cc: Nagalakshmi Nandigama <[email protected]>
Cc: Praveen Krishnamoorthy <[email protected]>
Cc: Sreekanth Reddy <[email protected]>
Cc: Abhijit Mahajan <[email protected]>
Cc: [email protected]
Cc: Andy Lutomirski <[email protected]>
Cc: Suresh Siddha <[email protected]>
Cc: Ingo Molnar <[email protected]>
Cc: Thomas Gleixner <[email protected]>
Cc: Juergen Gross <[email protected]>
Cc: Daniel Vetter <[email protected]>
Cc: Juergen Gross <[email protected]>
Cc: Dave Airlie <[email protected]>
Cc: Antonino Daplas <[email protected]>
Cc: Tomi Valkeinen <[email protected]>
Cc: Ville Syrjälä <[email protected]>
Cc: Mel Gorman <[email protected]>
Cc: Vlastimil Babka <[email protected]>
Cc: Borislav Petkov <[email protected]>
Cc: Davidlohr Bueso <[email protected]>
Cc: Jean-Christophe Plagniol-Villard <[email protected]>
Cc: [email protected]
Cc: [email protected]
Cc: [email protected]
Signed-off-by: Luis R. Rodriguez <[email protected]>
---
drivers/message/fusion/mptbase.c | 24 ------------------------
drivers/message/fusion/mptbase.h | 1 -
2 files changed, 25 deletions(-)
diff --git a/drivers/message/fusion/mptbase.c b/drivers/message/fusion/mptbase.c
index 187f836..5dcc031 100644
--- a/drivers/message/fusion/mptbase.c
+++ b/drivers/message/fusion/mptbase.c
@@ -59,10 +59,6 @@
#include <linux/delay.h>
#include <linux/interrupt.h> /* needed for in_interrupt() proto */
#include <linux/dma-mapping.h>
-#include <asm/io.h>
-#ifdef CONFIG_MTRR
-#include <asm/mtrr.h>
-#endif
#include <linux/kthread.h>
#include <scsi/scsi_host.h>
@@ -2820,13 +2816,6 @@ mpt_adapter_dispose(MPT_ADAPTER *ioc)
pci_disable_device(ioc->pcidev);
pci_release_selected_regions(ioc->pcidev, ioc->bars);
-#if defined(CONFIG_MTRR) && 0
- if (ioc->mtrr_reg > 0) {
- mtrr_del(ioc->mtrr_reg, 0, 0);
- dprintk(ioc, printk(MYIOC_s_INFO_FMT "MTRR region de-registered\n", ioc->name));
- }
-#endif
-
/* Zap the adapter lookup ptr! */
list_del(&ioc->list);
@@ -4512,19 +4501,6 @@ PrimeIocFifos(MPT_ADAPTER *ioc)
ioc->req_frames_low_dma = (u32) (alloc_dma & 0xFFFFFFFF);
-#if defined(CONFIG_MTRR) && 0
- /*
- * Enable Write Combining MTRR for IOC's memory region.
- * (at least as much as we can; "size and base must be
- * multiples of 4 kiB"
- */
- ioc->mtrr_reg = mtrr_add(ioc->req_frames_dma,
- sz,
- MTRR_TYPE_WRCOMB, 1);
- dprintk(ioc, printk(MYIOC_s_DEBUG_FMT "MTRR region registered (base:size=%08x:%x)\n",
- ioc->name, ioc->req_frames_dma, sz));
-#endif
-
for (i = 0; i < ioc->req_depth; i++) {
alloc_dma += ioc->req_sz;
mem += ioc->req_sz;
diff --git a/drivers/message/fusion/mptbase.h b/drivers/message/fusion/mptbase.h
index 8f14090..813d463 100644
--- a/drivers/message/fusion/mptbase.h
+++ b/drivers/message/fusion/mptbase.h
@@ -671,7 +671,6 @@ typedef struct _MPT_ADAPTER
u8 *HostPageBuffer; /* SAS - host page buffer support */
u32 HostPageBuffer_sz;
dma_addr_t HostPageBuffer_dma;
- int mtrr_reg;
struct pci_dev *pcidev; /* struct pci_dev pointer */
int bars; /* bitmask of BAR's that must be configured */
int msi_enable;
--
2.3.2.209.gd67f9d5.dirty
On Tue, Apr 21, 2015 at 1:46 PM, Luis R. Rodriguez
<[email protected]> wrote:
> From: "Luis R. Rodriguez" <[email protected]>
>
> If and when this gets enabled the driver could should split
> up IO memory space properly and that is quite a bit of work.
> Just remove the uncommented dead MTRR code then.
>
> There are a few motivations for this:
>
> a) Take advantage of PAT when available
>
> b) Help bury MTRR code away, MTRR is architecture specific and on
> x86 its replaced by PAT
>
> c) Help with the goal of eventually using _PAGE_CACHE_UC over
> _PAGE_CACHE_UC_MINUS on x86 on ioremap_nocache() (see commit
> de33c442e titled "x86 PAT: fix performance drop for glx,
> use UC minus for ioremap(), ioremap_nocache() and
> pci_mmap_page_range()")
Hey folks, who's tree should this go through if agreeable?
Luis
On Wed, Apr 29, 2015 at 12:50:40PM -0700, Luis R. Rodriguez wrote:
> On Tue, Apr 21, 2015 at 1:46 PM, Luis R. Rodriguez
> <[email protected]> wrote:
> > From: "Luis R. Rodriguez" <[email protected]>
> >
> > If and when this gets enabled the driver could should split
> > up IO memory space properly and that is quite a bit of work.
> > Just remove the uncommented dead MTRR code then.
> >
> > There are a few motivations for this:
> >
> > a) Take advantage of PAT when available
> >
> > b) Help bury MTRR code away, MTRR is architecture specific and on
> > x86 its replaced by PAT
> >
> > c) Help with the goal of eventually using _PAGE_CACHE_UC over
> > _PAGE_CACHE_UC_MINUS on x86 on ioremap_nocache() (see commit
> > de33c442e titled "x86 PAT: fix performance drop for glx,
> > use UC minus for ioremap(), ioremap_nocache() and
> > pci_mmap_page_range()")
>
> Hey folks, who's tree should this go through if agreeable?
Hey folks, can this be applied? Thanks.
Luis
On Fri, May 29, 2015 at 1:23 PM, Luis R. Rodriguez <[email protected]> wrote:
> On Wed, Apr 29, 2015 at 12:50 PM, Luis R. Rodriguez <[email protected]> wrote:
>> On Tue, Apr 21, 2015 at 1:46 PM, Luis R. Rodriguez
>> <[email protected]> wrote:
>>> From: "Luis R. Rodriguez" <[email protected]>
>>>
>>> If and when this gets enabled the driver could should split
>>> up IO memory space properly and that is quite a bit of work.
>>> Just remove the uncommented dead MTRR code then.
>>>
>>> There are a few motivations for this:
>>>
>>> a) Take advantage of PAT when available
>>>
>>> b) Help bury MTRR code away, MTRR is architecture specific and on
>>> x86 its replaced by PAT
>>>
>>> c) Help with the goal of eventually using _PAGE_CACHE_UC over
>>> _PAGE_CACHE_UC_MINUS on x86 on ioremap_nocache() (see commit
>>> de33c442e titled "x86 PAT: fix performance drop for glx,
>>> use UC minus for ioremap(), ioremap_nocache() and
>>> pci_mmap_page_range()")
>>
>> Hey folks, who's tree should this go through if agreeable?
>
> OK its been over 1 month without any replies on this patch which just
> removes commented out code.
>
> All the maintainers below bounce and the only e-mail not bouncing is
> for Sreekanth Reddy <[email protected]>, he hasn't been
> seen active on linux-next since Jan 12 2015 when he did a driver bump
> for mpt2sas to 20.100.00.00.
>
> What's going on folks? And can this patch go in?
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index aca2886..73dbc02 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -6205,10 +6205,7 @@ S: Maintained
> F: arch/arm/mach-lpc32xx/
>
> LSILOGIC MPT FUSION DRIVERS (FC/SAS/SPI)
> -M: Nagalakshmi Nandigama <[email protected]>
> -M: Praveen Krishnamoorthy <[email protected]>
> M: Sreekanth Reddy <[email protected]>
> -M: Abhijit Mahajan <[email protected]>
> L: [email protected]
> L: [email protected]
> W: http://www.lsilogic.com/support
OK so Avago bought Broadcom.
Does that impact how Avago will contribute to the Linux kernel? It has
been well over 1 month and I haven't seen any reply from Avago folks.
Andrew, is the silence sufficient enough reason for this patch to go
instead through your tree?
Luis
Hi Luis,
Sorry for delay in response. Actually I was looking for the history of
this section of code but I couldn't find it. Anyway this is dead code
and we are fine with removing this dead code.
James,
Please consider this patch as Acked-by: "Sreekanth Reddy"
<[email protected]>
Regards,
Sreekanth
On Wed, Apr 22, 2015 at 2:16 AM, Luis R. Rodriguez
<[email protected]> wrote:
> From: "Luis R. Rodriguez" <[email protected]>
>
> If and when this gets enabled the driver could should split
> up IO memory space properly and that is quite a bit of work.
> Just remove the uncommented dead MTRR code then.
>
> There are a few motivations for this:
>
> a) Take advantage of PAT when available
>
> b) Help bury MTRR code away, MTRR is architecture specific and on
> x86 its replaced by PAT
>
> c) Help with the goal of eventually using _PAGE_CACHE_UC over
> _PAGE_CACHE_UC_MINUS on x86 on ioremap_nocache() (see commit
> de33c442e titled "x86 PAT: fix performance drop for glx,
> use UC minus for ioremap(), ioremap_nocache() and
> pci_mmap_page_range()")
>
> Cc: Toshi Kani <[email protected]>
> Cc: Christoph Hellwig <[email protected]>
> Cc: Nagalakshmi Nandigama <[email protected]>
> Cc: Praveen Krishnamoorthy <[email protected]>
> Cc: Sreekanth Reddy <[email protected]>
> Cc: Abhijit Mahajan <[email protected]>
> Cc: [email protected]
> Cc: Andy Lutomirski <[email protected]>
> Cc: Suresh Siddha <[email protected]>
> Cc: Ingo Molnar <[email protected]>
> Cc: Thomas Gleixner <[email protected]>
> Cc: Juergen Gross <[email protected]>
> Cc: Daniel Vetter <[email protected]>
> Cc: Juergen Gross <[email protected]>
> Cc: Dave Airlie <[email protected]>
> Cc: Antonino Daplas <[email protected]>
> Cc: Tomi Valkeinen <[email protected]>
> Cc: Ville Syrjälä <[email protected]>
> Cc: Mel Gorman <[email protected]>
> Cc: Vlastimil Babka <[email protected]>
> Cc: Borislav Petkov <[email protected]>
> Cc: Davidlohr Bueso <[email protected]>
> Cc: Jean-Christophe Plagniol-Villard <[email protected]>
> Cc: [email protected]
> Cc: [email protected]
> Cc: [email protected]
> Signed-off-by: Luis R. Rodriguez <[email protected]>
> ---
> drivers/message/fusion/mptbase.c | 24 ------------------------
> drivers/message/fusion/mptbase.h | 1 -
> 2 files changed, 25 deletions(-)
>
> diff --git a/drivers/message/fusion/mptbase.c b/drivers/message/fusion/mptbase.c
> index 187f836..5dcc031 100644
> --- a/drivers/message/fusion/mptbase.c
> +++ b/drivers/message/fusion/mptbase.c
> @@ -59,10 +59,6 @@
> #include <linux/delay.h>
> #include <linux/interrupt.h> /* needed for in_interrupt() proto */
> #include <linux/dma-mapping.h>
> -#include <asm/io.h>
> -#ifdef CONFIG_MTRR
> -#include <asm/mtrr.h>
> -#endif
> #include <linux/kthread.h>
> #include <scsi/scsi_host.h>
>
> @@ -2820,13 +2816,6 @@ mpt_adapter_dispose(MPT_ADAPTER *ioc)
> pci_disable_device(ioc->pcidev);
> pci_release_selected_regions(ioc->pcidev, ioc->bars);
>
> -#if defined(CONFIG_MTRR) && 0
> - if (ioc->mtrr_reg > 0) {
> - mtrr_del(ioc->mtrr_reg, 0, 0);
> - dprintk(ioc, printk(MYIOC_s_INFO_FMT "MTRR region de-registered\n", ioc->name));
> - }
> -#endif
> -
> /* Zap the adapter lookup ptr! */
> list_del(&ioc->list);
>
> @@ -4512,19 +4501,6 @@ PrimeIocFifos(MPT_ADAPTER *ioc)
>
> ioc->req_frames_low_dma = (u32) (alloc_dma & 0xFFFFFFFF);
>
> -#if defined(CONFIG_MTRR) && 0
> - /*
> - * Enable Write Combining MTRR for IOC's memory region.
> - * (at least as much as we can; "size and base must be
> - * multiples of 4 kiB"
> - */
> - ioc->mtrr_reg = mtrr_add(ioc->req_frames_dma,
> - sz,
> - MTRR_TYPE_WRCOMB, 1);
> - dprintk(ioc, printk(MYIOC_s_DEBUG_FMT "MTRR region registered (base:size=%08x:%x)\n",
> - ioc->name, ioc->req_frames_dma, sz));
> -#endif
> -
> for (i = 0; i < ioc->req_depth; i++) {
> alloc_dma += ioc->req_sz;
> mem += ioc->req_sz;
> diff --git a/drivers/message/fusion/mptbase.h b/drivers/message/fusion/mptbase.h
> index 8f14090..813d463 100644
> --- a/drivers/message/fusion/mptbase.h
> +++ b/drivers/message/fusion/mptbase.h
> @@ -671,7 +671,6 @@ typedef struct _MPT_ADAPTER
> u8 *HostPageBuffer; /* SAS - host page buffer support */
> u32 HostPageBuffer_sz;
> dma_addr_t HostPageBuffer_dma;
> - int mtrr_reg;
> struct pci_dev *pcidev; /* struct pci_dev pointer */
> int bars; /* bitmask of BAR's that must be configured */
> int msi_enable;
> --
> 2.3.2.209.gd67f9d5.dirty
>
On Thu, Jun 04, 2015 at 10:20:23AM +0530, Sreekanth Reddy wrote:
> Hi Luis,
>
> Sorry for delay in response. Actually I was looking for the history of
> this section of code but I couldn't find it. Anyway this is dead code
> and we are fine with removing this dead code.
>
> James,
>
> Please consider this patch as:
>
> Acked-by: Sreekanth Reddy <[email protected]>
Great thanks, now who's tree should this patch go through? Last patch for this
driver was in 2014 and went through Christoph, but if Christoph doesn't want to
take it can it go through Andrew's tree?
Sreekanth, can you also update the MAINTAINERS file to reflect recent changes
at your company ?
Luis
On Thu, Jun 4, 2015 at 11:11 PM, Luis R. Rodriguez <[email protected]> wrote:
> On Thu, Jun 04, 2015 at 10:20:23AM +0530, Sreekanth Reddy wrote:
>> Hi Luis,
>>
>> Sorry for delay in response. Actually I was looking for the history of
>> this section of code but I couldn't find it. Anyway this is dead code
>> and we are fine with removing this dead code.
>>
>> James,
>>
>> Please consider this patch as:
>>
>> Acked-by: Sreekanth Reddy <[email protected]>
>
> Great thanks, now who's tree should this patch go through? Last patch for this
> driver was in 2014 and went through Christoph, but if Christoph doesn't want to
> take it can it go through Andrew's tree?
>
> Sreekanth, can you also update the MAINTAINERS file to reflect recent changes
> at your company ?
Sure I will do this.
>
> Luis
Thanks,
Sreekanth
On Fri, Jun 05, 2015 at 05:17:08PM +0530, Sreekanth Reddy wrote:
> On Thu, Jun 4, 2015 at 11:11 PM, Luis R. Rodriguez <[email protected]> wrote:
> > On Thu, Jun 04, 2015 at 10:20:23AM +0530, Sreekanth Reddy wrote:
> >> Hi Luis,
> >>
> >> Sorry for delay in response. Actually I was looking for the history of
> >> this section of code but I couldn't find it. Anyway this is dead code
> >> and we are fine with removing this dead code.
> >>
> >> James,
> >>
> >> Please consider this patch as:
> >>
> >> Acked-by: Sreekanth Reddy <[email protected]>
> >
> > Great thanks, now who's tree should this patch go through? Last patch for this
> > driver was in 2014 and went through Christoph, but if Christoph doesn't want to
> > take it can it go through Andrew's tree?
> >
> > Sreekanth, can you also update the MAINTAINERS file to reflect recent changes
> > at your company ?
>
> Sure I will do this.
Christoph, do you mind this going through Andrew's tree? Or do you want to take it?
Luis