linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* [PATCH v2] Staging: dt3155: Cleanup memory mapped i/o access
@ 2010-06-22 23:38 H Hartley Sweeten
  2010-06-23 22:23 ` Greg KH
  0 siblings, 1 reply; 21+ messages in thread
From: H Hartley Sweeten @ 2010-06-22 23:38 UTC (permalink / raw)
  To: greg; +Cc: ss, gregkh, devel, Linux Kernel

The macros ReadMReg and WriteMReg are really just private versions of
the kernel's readl and writel functions.  Use the kernel's functions
instead.  And since ioremap returns a (void __iomem *) not a (u8 *),
change all the uses of dt3155_lbase to reflect this.

While here, make dt3155_lbase static since it is only used in the
dt3155_drv.c file.  Also, remove the global variable dt3155_bbase
since it is not used anywhere in the code.

Where is makes sense, create a local 'mmio' variable instead of using
dt3155_lbase[minor] to make the code more readable.

This change also affects the {Read|Write}I2C functions so they are
also modified as needed.

Signed-off-by: H Hartley Sweeten <hsweeten@visionengravers.com>
Cc: Greg Kroah-Hartman <gregkh@suse.de>
Cc: Scott Smedley <ss@aao.gov.au>

---

V2 - rebased to next-20100621
reposted with a different email client

diff --git a/drivers/staging/dt3155/dt3155_drv.c b/drivers/staging/dt3155/dt3155_drv.c
index dcd3849..88c9e59 100644
--- a/drivers/staging/dt3155/dt3155_drv.c
+++ b/drivers/staging/dt3155/dt3155_drv.c
@@ -64,8 +64,8 @@ extern void printques(int);
 #include <linux/poll.h>
 #include <linux/sched.h>
 #include <linux/smp_lock.h>
+#include <linux/io.h>
 
-#include <asm/io.h>
 #include <asm/uaccess.h>
 
 #include "dt3155.h"
@@ -112,14 +112,12 @@ int dt3155_major = 0;
 struct dt3155_status dt3155_status[MAXBOARDS];
 
 /* kernel logical address of the board */
-u8 *dt3155_lbase[MAXBOARDS] = { NULL
+static void __iomem *dt3155_lbase[MAXBOARDS] = { NULL
 #if MAXBOARDS == 2
 				      , NULL
 #endif
 };
-/* DT3155 registers              */
-u8 *dt3155_bbase = NULL;		  /* kernel logical address of the *
-					   * buffer region                 */
+
 u32  dt3155_dev_open[MAXBOARDS] = {0
 #if MAXBOARDS == 2
 				       , 0
@@ -139,11 +137,11 @@ static void quick_stop (int minor)
 {
   // TODO: scott was here
 #if 1
-  ReadMReg((dt3155_lbase[minor] + INT_CSR), int_csr_r.reg);
+  int_csr_r.reg = readl(dt3155_lbase[minor] + INT_CSR);
   /* disable interrupts */
   int_csr_r.fld.FLD_END_EVE_EN = 0;
   int_csr_r.fld.FLD_END_ODD_EN = 0;
-  WriteMReg((dt3155_lbase[minor] + INT_CSR), int_csr_r.reg);
+  writel(int_csr_r.reg, dt3155_lbase[minor] + INT_CSR);
 
   dt3155_status[minor].state &= ~(DT3155_STATE_STOP|0xff);
   /* mark the system stopped: */
@@ -171,6 +169,7 @@ static void dt3155_isr(int irq, void *dev_id, struct pt_regs *regs)
   int    index;
   unsigned long flags;
   u32 buffer_addr;
+  void __iomem *mmio;
 
   /* find out who issued the interrupt */
   for (index = 0; index < ndevices; index++) {
@@ -187,8 +186,10 @@ static void dt3155_isr(int irq, void *dev_id, struct pt_regs *regs)
     return;
   }
 
+  mmio = dt3155_lbase[minor];
+
   /* Check for corruption and set a flag if so */
-  ReadMReg((dt3155_lbase[minor] + CSR1), csr1_r.reg);
+  csr1_r.reg = readl(mmio + CSR1);
 
   if ((csr1_r.fld.FLD_CRPT_EVE) || (csr1_r.fld.FLD_CRPT_ODD))
     {
@@ -200,7 +201,7 @@ static void dt3155_isr(int irq, void *dev_id, struct pt_regs *regs)
       return;
     }
 
-  ReadMReg((dt3155_lbase[minor] + INT_CSR), int_csr_r.reg);
+  int_csr_r.reg = readl(mmio + INT_CSR);
 
   /* Handle the even field ... */
   if (int_csr_r.fld.FLD_END_EVE)
@@ -211,7 +212,7 @@ static void dt3155_isr(int irq, void *dev_id, struct pt_regs *regs)
 	  dt3155_fbuffer[minor]->frame_count++;
 	}
 
-      ReadI2C(dt3155_lbase[minor], EVEN_CSR, &i2c_even_csr.reg);
+      ReadI2C(mmio, EVEN_CSR, &i2c_even_csr.reg);
 
       /* Clear the interrupt? */
       int_csr_r.fld.FLD_END_EVE = 1;
@@ -231,7 +232,7 @@ static void dt3155_isr(int irq, void *dev_id, struct pt_regs *regs)
 	    }
 	}
 
-      WriteMReg((dt3155_lbase[minor] + INT_CSR), int_csr_r.reg);
+      writel(int_csr_r.reg, mmio + INT_CSR);
 
       /* Set up next DMA if we are doing FIELDS */
       if ((dt3155_status[minor].state & DT3155_STATE_MODE) ==
@@ -249,7 +250,7 @@ static void dt3155_isr(int irq, void *dev_id, struct pt_regs *regs)
 
 	  /* Set up the DMA address for the next field */
 	  local_irq_restore(flags);
-	  WriteMReg((dt3155_lbase[minor] + ODD_DMA_START), buffer_addr);
+	  writel(buffer_addr, mmio + ODD_DMA_START);
 	}
 
       /* Check for errors. */
@@ -257,7 +258,7 @@ static void dt3155_isr(int irq, void *dev_id, struct pt_regs *regs)
       if (i2c_even_csr.fld.ERROR_EVE)
 	dt3155_errno = DT_ERR_OVERRUN;
 
-      WriteI2C(dt3155_lbase[minor], EVEN_CSR, i2c_even_csr.reg);
+      WriteI2C(mmio, EVEN_CSR, i2c_even_csr.reg);
 
       /* Note that we actually saw an even field meaning  */
       /* that subsequent odd field complete the frame     */
@@ -274,7 +275,7 @@ static void dt3155_isr(int irq, void *dev_id, struct pt_regs *regs)
   /* ... now handle the odd field */
   if (int_csr_r.fld.FLD_END_ODD)
     {
-      ReadI2C(dt3155_lbase[minor], ODD_CSR, &i2c_odd_csr.reg);
+      ReadI2C(mmio, ODD_CSR, &i2c_odd_csr.reg);
 
       /* Clear the interrupt? */
       int_csr_r.fld.FLD_END_ODD = 1;
@@ -310,7 +311,7 @@ static void dt3155_isr(int irq, void *dev_id, struct pt_regs *regs)
 	    }
 	}
 
-      WriteMReg((dt3155_lbase[minor] + INT_CSR), int_csr_r.reg);
+      writel(int_csr_r.reg, mmio + INT_CSR);
 
       /* if the odd field has been acquired, then     */
       /* change the next dma location for both fields */
@@ -387,14 +388,14 @@ static void dt3155_isr(int irq, void *dev_id, struct pt_regs *regs)
       if ((dt3155_status[minor].state & DT3155_STATE_MODE) ==
 	   DT3155_STATE_FLD)
 	{
-	  WriteMReg((dt3155_lbase[minor] + EVEN_DMA_START), buffer_addr);
+	  writel(buffer_addr, mmio + EVEN_DMA_START);
 	}
       else
 	{
-	  WriteMReg((dt3155_lbase[minor] + EVEN_DMA_START), buffer_addr);
+	  writel(buffer_addr, mmio + EVEN_DMA_START);
 
-	  WriteMReg((dt3155_lbase[minor] + ODD_DMA_START), buffer_addr
-		    + dt3155_status[minor].config.cols);
+	  writel(buffer_addr + dt3155_status[minor].config.cols,
+		mmio + ODD_DMA_START);
 	}
 
       /* Do error checking */
@@ -402,7 +403,7 @@ static void dt3155_isr(int irq, void *dev_id, struct pt_regs *regs)
       if (i2c_odd_csr.fld.ERROR_ODD)
 	dt3155_errno = DT_ERR_OVERRUN;
 
-      WriteI2C(dt3155_lbase[minor], ODD_CSR, i2c_odd_csr.reg);
+      WriteI2C(mmio, ODD_CSR, i2c_odd_csr.reg);
 
       return;
     }
@@ -419,6 +420,7 @@ static void dt3155_isr(int irq, void *dev_id, struct pt_regs *regs)
 static void dt3155_init_isr(int minor)
 {
   const u32 stride =  dt3155_status[minor].config.cols;
+  void __iomem *mmio = dt3155_lbase[minor];
 
   switch (dt3155_status[minor].state & DT3155_STATE_MODE)
     {
@@ -429,12 +431,9 @@ static void dt3155_init_isr(int minor)
 	even_dma_stride_r = 0;
 	odd_dma_stride_r  = 0;
 
-	WriteMReg((dt3155_lbase[minor] + EVEN_DMA_START),
-		  even_dma_start_r);
-	WriteMReg((dt3155_lbase[minor] + EVEN_DMA_STRIDE),
-		  even_dma_stride_r);
-	WriteMReg((dt3155_lbase[minor] + ODD_DMA_STRIDE),
-		  odd_dma_stride_r);
+	writel(even_dma_start_r, mmio + EVEN_DMA_START);
+	writel(even_dma_stride_r, mmio + EVEN_DMA_STRIDE);
+	writel(odd_dma_stride_r, mmio + ODD_DMA_STRIDE);
 	break;
       }
 
@@ -447,14 +446,10 @@ static void dt3155_init_isr(int minor)
 	even_dma_stride_r =  stride;
 	odd_dma_stride_r  =  stride;
 
-	WriteMReg((dt3155_lbase[minor] + EVEN_DMA_START),
-		  even_dma_start_r);
-	WriteMReg((dt3155_lbase[minor] + ODD_DMA_START),
-		  odd_dma_start_r);
-	WriteMReg((dt3155_lbase[minor] + EVEN_DMA_STRIDE),
-		  even_dma_stride_r);
-	WriteMReg((dt3155_lbase[minor] + ODD_DMA_STRIDE),
-		  odd_dma_stride_r);
+	writel(even_dma_start_r, mmio + EVEN_DMA_START);
+	writel(odd_dma_start_r, mmio + ODD_DMA_START);
+	writel(even_dma_stride_r, mmio + EVEN_DMA_STRIDE);
+	writel(odd_dma_stride_r, mmio + ODD_DMA_STRIDE);
 	break;
       }
     }
@@ -462,9 +457,9 @@ static void dt3155_init_isr(int minor)
   /* 50/60 Hz should be set before this point but let's make sure it is */
   /* right anyway */
 
-  ReadI2C(dt3155_lbase[minor], CSR2, &i2c_csr2.reg);
+  ReadI2C(mmio, CSR2, &i2c_csr2.reg);
   i2c_csr2.fld.HZ50 = FORMAT50HZ;
-  WriteI2C(dt3155_lbase[minor], CSR2, i2c_csr2.reg);
+  WriteI2C(mmio, CSR2, i2c_csr2.reg);
 
   /* enable busmaster chip, clear flags */
 
@@ -484,7 +479,7 @@ static void dt3155_init_isr(int minor)
   csr1_r.fld.FLD_CRPT_EVE   = 1; /* writing a 1 clears flags */
   csr1_r.fld.FLD_CRPT_ODD   = 1;
 
-  WriteMReg((dt3155_lbase[minor] + CSR1),csr1_r.reg);
+  writel(csr1_r.reg, mmio + CSR1);
 
   /* Enable interrupts at the end of each field */
 
@@ -493,14 +488,14 @@ static void dt3155_init_isr(int minor)
   int_csr_r.fld.FLD_END_ODD_EN = 1;
   int_csr_r.fld.FLD_START_EN = 0;
 
-  WriteMReg((dt3155_lbase[minor] + INT_CSR), int_csr_r.reg);
+  writel(int_csr_r.reg, mmio + INT_CSR);
 
   /* start internal BUSY bits */
 
-  ReadI2C(dt3155_lbase[minor], CSR2, &i2c_csr2.reg);
+  ReadI2C(mmio, CSR2, &i2c_csr2.reg);
   i2c_csr2.fld.BUSY_ODD  = 1;
   i2c_csr2.fld.BUSY_EVE  = 1;
-  WriteI2C(dt3155_lbase[minor], CSR2, i2c_csr2.reg);
+  WriteI2C(mmio, CSR2, i2c_csr2.reg);
 
   /* Now its up to the interrupt routine!! */
 
@@ -709,7 +704,7 @@ static int dt3155_open(struct inode* inode, struct file* filep)
 
   /* Disable ALL interrupts */
   int_csr_r.reg = 0;
-  WriteMReg((dt3155_lbase[minor] + INT_CSR), int_csr_r.reg);
+  writel(int_csr_r.reg, dt3155_lbase[minor] + INT_CSR);
 
   init_waitqueue_head(&(dt3155_read_wait_queue[minor]));
 
@@ -911,7 +906,7 @@ static int find_PCI (void)
 
       /* Remap the base address to a logical address through which we
        * can access it. */
-      dt3155_lbase[pci_index - 1] = ioremap(base,PCI_PAGE_SIZE);
+      dt3155_lbase[pci_index - 1] = ioremap(base, PCI_PAGE_SIZE);
       dt3155_status[pci_index - 1].reg_addr = base;
       DT_3155_DEBUG_MSG("DT3155: New logical address is %p \n",
 			dt3155_lbase[pci_index-1]);
@@ -1036,7 +1031,7 @@ int init_module(void)
   int_csr_r.reg = 0;
   for( index = 0;  index < ndevices;  index++)
     {
-      WriteMReg((dt3155_lbase[index] + INT_CSR), int_csr_r.reg);
+      writel(int_csr_r.reg, dt3155_lbase[index] + INT_CSR);
       if(dt3155_status[index].device_installed)
 	{
 	  /*
diff --git a/drivers/staging/dt3155/dt3155_drv.h b/drivers/staging/dt3155/dt3155_drv.h
index 95e68c3..c447c61 100644
--- a/drivers/staging/dt3155/dt3155_drv.h
+++ b/drivers/staging/dt3155/dt3155_drv.h
@@ -24,12 +24,6 @@ MA 02111-1307 USA
 #ifndef DT3155_DRV_INC
 #define DT3155_DRV_INC
 
-/* kernel logical address of the frame grabbers */
-extern u8 *dt3155_lbase[MAXBOARDS];
-
-/* kernel logical address of ram buffer */
-extern u8 *dt3155_bbase;
-
 #ifdef __KERNEL__
 #include <linux/wait.h>
 
diff --git a/drivers/staging/dt3155/dt3155_io.c b/drivers/staging/dt3155/dt3155_io.c
index 7792e71..485cc5e 100644
--- a/drivers/staging/dt3155/dt3155_io.c
+++ b/drivers/staging/dt3155/dt3155_io.c
@@ -21,6 +21,8 @@
  */
 
 #include <linux/delay.h>
+#include <linux/io.h>
+
 #include "dt3155.h"
 #include "dt3155_io.h"
 #include "dt3155_drv.h"
@@ -75,13 +77,13 @@ u8 i2c_pm_lut_data;
  *
  * This function handles read/write timing and r/w timeout error
  */
-static int wait_ibsyclr(u8 *lpReg)
+static int wait_ibsyclr(void __iomem *mmio)
 {
 	/* wait 100 microseconds */
 	udelay(100L);
 	/* __delay(loops_per_sec/10000); */
 
-	ReadMReg(lpReg + IIC_CSR2, iic_csr2_r.reg);
+	iic_csr2_r.reg = readl(mmio + IIC_CSR2);
 	if (iic_csr2_r.fld.NEW_CYCLE) {
 		/* if NEW_CYCLE didn't clear */
 		/* TIMEOUT ERROR */
@@ -101,11 +103,11 @@ static int wait_ibsyclr(u8 *lpReg)
  * 2nd parameter is reg. index;
  * 3rd is value to be written
  */
-int WriteI2C(u8 *lpReg, u_short wIregIndex, u8 byVal)
+int WriteI2C(void __iomem *mmio, u_short wIregIndex, u8 byVal)
 {
 	/* read 32 bit IIC_CSR2 register data into union */
 
-	ReadMReg((lpReg + IIC_CSR2), iic_csr2_r.reg);
+	iic_csr2_r.reg = readl(mmio + IIC_CSR2);
 
 	/* for write operation */
 	iic_csr2_r.fld.DIR_RD      = 0;
@@ -117,10 +119,10 @@ int WriteI2C(u8 *lpReg, u_short wIregIndex, u8 byVal)
 	iic_csr2_r.fld.NEW_CYCLE   = 1;
 
 	/* xfer union data into 32 bit IIC_CSR2 register */
-	WriteMReg((lpReg + IIC_CSR2), iic_csr2_r.reg);
+	writel(iic_csr2_r.reg, mmio + IIC_CSR2);
 
 	/* wait for IIC cycle to finish */
-	return wait_ibsyclr(lpReg);
+	return wait_ibsyclr(mmio);
 }
 
 /*
@@ -132,12 +134,12 @@ int WriteI2C(u8 *lpReg, u_short wIregIndex, u8 byVal)
  * 2nd parameter is reg. index;
  * 3rd is adrs of value to be read
  */
-int ReadI2C(u8 *lpReg, u_short wIregIndex, u8 *byVal)
+int ReadI2C(void __iomem *mmio, u_short wIregIndex, u8 *byVal)
 {
 	int writestat;	/* status for return */
 
 	/*  read 32 bit IIC_CSR2 register data into union */
-	ReadMReg((lpReg + IIC_CSR2), iic_csr2_r.reg);
+	iic_csr2_r.reg = readl(mmio + IIC_CSR2);
 
 	/*  for read operation */
 	iic_csr2_r.fld.DIR_RD     = 1;
@@ -149,14 +151,14 @@ int ReadI2C(u8 *lpReg, u_short wIregIndex, u8 *byVal)
 	iic_csr2_r.fld.NEW_CYCLE  = 1;
 
 	/*  xfer union's data into 32 bit IIC_CSR2 register */
-	WriteMReg((lpReg + IIC_CSR2), iic_csr2_r.reg);
+	writel(iic_csr2_r.reg, mmio + IIC_CSR2);
 
 	/* wait for IIC cycle to finish */
-	writestat = wait_ibsyclr(lpReg);
+	writestat = wait_ibsyclr(mmio);
 
 	/* Next 2 commands read 32 bit IIC_CSR1 register's data into union */
 	/* first read data is in IIC_CSR1 */
-	ReadMReg((lpReg + IIC_CSR1), iic_csr1_r.reg);
+	iic_csr1_r.reg = readl(mmio + IIC_CSR1);
 
 	/* now get data u8 out of register */
 	*byVal = (u8) iic_csr1_r.fld.RD_DATA;
diff --git a/drivers/staging/dt3155/dt3155_io.h b/drivers/staging/dt3155/dt3155_io.h
index d1a2510..a9aa754 100644
--- a/drivers/staging/dt3155/dt3155_io.h
+++ b/drivers/staging/dt3155/dt3155_io.h
@@ -34,11 +34,6 @@ MA 02111-1307 USA
 #ifndef DT3155_IO_INC
 #define DT3155_IO_INC
 
-/* macros to access registers */
-
-#define WriteMReg(Address, Data)	(*((u32 *)(Address)) = Data)
-#define ReadMReg(Address, Data)		(Data = *((u32 *)(Address)))
-
 /***************** 32 bit register globals  **************/
 
 /*  offsets for 32-bit memory mapped registers */
@@ -352,7 +347,7 @@ extern u8			i2c_pm_lut_data;
 
 /* access 8-bit IIC registers */
 
-extern int ReadI2C(u8 *lpReg, u_short wIregIndex, u8 *byVal);
-extern int WriteI2C(u8 *lpReg, u_short wIregIndex, u8 byVal);
+extern int ReadI2C(void __iomem *mmio, u_short wIregIndex, u8 *byVal);
+extern int WriteI2C(void __iomem *mmio, u_short wIregIndex, u8 byVal);
 
 #endif

^ permalink raw reply related	[flat|nested] 21+ messages in thread

* Re: Staging: dt3155: Cleanup memory mapped i/o access
  2010-06-22 23:38 [PATCH v2] Staging: dt3155: Cleanup memory mapped i/o access H Hartley Sweeten
@ 2010-06-23 22:23 ` Greg KH
  0 siblings, 0 replies; 21+ messages in thread
From: Greg KH @ 2010-06-23 22:23 UTC (permalink / raw)
  To: H Hartley Sweeten; +Cc: ss, gregkh, devel, Linux Kernel

On Tue, Jun 22, 2010 at 04:38:50PM -0700, H Hartley Sweeten wrote:
> The macros ReadMReg and WriteMReg are really just private versions of
> the kernel's readl and writel functions.  Use the kernel's functions
> instead.  And since ioremap returns a (void __iomem *) not a (u8 *),
> change all the uses of dt3155_lbase to reflect this.

<snip>

Whatever you did to fix the email client issue up, it worked, thanks.

greg k-h

^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: Staging: dt3155: Cleanup memory mapped i/o access
  2010-05-06 16:59                                 ` H Hartley Sweeten
@ 2010-05-06 20:25                                   ` Greg KH
  0 siblings, 0 replies; 21+ messages in thread
From: Greg KH @ 2010-05-06 20:25 UTC (permalink / raw)
  To: H Hartley Sweeten; +Cc: devel, ss, Greg KH, Linux Kernel

On Thu, May 06, 2010 at 11:59:03AM -0500, H Hartley Sweeten wrote:
> On Tuesday, May 04, 2010 2:23 PM, H Hartley Sweeten wrote:
> >
> > The macros ReadMReg and WriteMReg are really just private versions of
> > the kernel's readl and writel functions.  Use the kernel's functions
> > instead.  And since ioremap returns a (void __iomem *) not a (u8 *),
> > change all the uses of dt3155_lbase to reflect this.
> >
> > While here, make dt3155_lbase static since it is only used in the
> > dt3155_drv.c file.  Also, remove the global variable dt3155_bbase
> > since it is not used anywhere in the code.
> >
> > Where is makes sense, create a local 'mmio' variable instead of using
> > dt3155_lbase[minor] to make the code more readable.
> >
> > This change also affects the {Read|Write}I2C functions so they are
> > also modified as needed.
> >
> > Signed-off-by: H Hartley Sweeten <hsweeten@visionengravers.com>
> > Cc: Greg Kroah-Hartman <gregkh@suse.de>
> > Cc: Scott Smedley <ss@aao.gov.au>
> >
> 
> Greg,
> 
> Did this patch fair any better when trying to merge it?

No, not at all :(

> If there is still an issue I will wait until Linus' tree, linux-next,
> and your staging-next branch appear to be more in sync.

Yes, please wait a bit, I really don't know what is going on here,
sorry.

greg k-h

^ permalink raw reply	[flat|nested] 21+ messages in thread

* RE: Staging: dt3155: Cleanup memory mapped i/o access
  2010-05-04 21:22                               ` H Hartley Sweeten
@ 2010-05-06 16:59                                 ` H Hartley Sweeten
  2010-05-06 20:25                                   ` Greg KH
  0 siblings, 1 reply; 21+ messages in thread
From: H Hartley Sweeten @ 2010-05-06 16:59 UTC (permalink / raw)
  To: Greg KH; +Cc: devel, ss, Greg KH, Linux Kernel

On Tuesday, May 04, 2010 2:23 PM, H Hartley Sweeten wrote:
>
> The macros ReadMReg and WriteMReg are really just private versions of
> the kernel's readl and writel functions.  Use the kernel's functions
> instead.  And since ioremap returns a (void __iomem *) not a (u8 *),
> change all the uses of dt3155_lbase to reflect this.
>
> While here, make dt3155_lbase static since it is only used in the
> dt3155_drv.c file.  Also, remove the global variable dt3155_bbase
> since it is not used anywhere in the code.
>
> Where is makes sense, create a local 'mmio' variable instead of using
> dt3155_lbase[minor] to make the code more readable.
>
> This change also affects the {Read|Write}I2C functions so they are
> also modified as needed.
>
> Signed-off-by: H Hartley Sweeten <hsweeten@visionengravers.com>
> Cc: Greg Kroah-Hartman <gregkh@suse.de>
> Cc: Scott Smedley <ss@aao.gov.au>
>

Greg,

Did this patch fair any better when trying to merge it?

If there is still an issue I will wait until Linus' tree, linux-next,
and your staging-next branch appear to be more in sync.

Regards,
Hartley

^ permalink raw reply	[flat|nested] 21+ messages in thread

* RE: Staging: dt3155: Cleanup memory mapped i/o access
  2010-05-04 21:02                             ` Greg KH
@ 2010-05-04 21:22                               ` H Hartley Sweeten
  2010-05-06 16:59                                 ` H Hartley Sweeten
  0 siblings, 1 reply; 21+ messages in thread
From: H Hartley Sweeten @ 2010-05-04 21:22 UTC (permalink / raw)
  To: Greg KH; +Cc: Joe Perches, Greg KH, devel, ss, Linux Kernel


The macros ReadMReg and WriteMReg are really just private versions of
the kernel's readl and writel functions.  Use the kernel's functions
instead.  And since ioremap returns a (void __iomem *) not a (u8 *),
change all the uses of dt3155_lbase to reflect this.

While here, make dt3155_lbase static since it is only used in the
dt3155_drv.c file.  Also, remove the global variable dt3155_bbase
since it is not used anywhere in the code.

Where is makes sense, create a local 'mmio' variable instead of using
dt3155_lbase[minor] to make the code more readable.

This change also affects the {Read|Write}I2C functions so they are
also modified as needed.

Signed-off-by: H Hartley Sweeten <hsweeten@visionengravers.com>
Cc: Greg Kroah-Hartman <gregkh@suse.de>
Cc: Scott Smedley <ss@aao.gov.au>

---

Greg, here is the patch rebased to your staging-next tree.
The main issue I can see is a conflict with:

commit 6536560cabab170ed2969b005bf69a496e9c45bf
    Staging: dt3155: fix 50Hz configuration

This patch modifies the same two lines that were changed by that patch.

diff --git a/drivers/staging/dt3155/dt3155_drv.c b/drivers/staging/dt3155/dt3155_drv.c
index 993ed2f..8ebfe14 100644
--- a/drivers/staging/dt3155/dt3155_drv.c
+++ b/drivers/staging/dt3155/dt3155_drv.c
@@ -75,8 +75,8 @@ MODULE_LICENSE("GPL");
 #include <linux/poll.h>
 #include <linux/sched.h>
 #include <linux/smp_lock.h>
+#include <linux/io.h>

-#include <asm/io.h>
 #include <asm/uaccess.h>

 #include "dt3155.h"
@@ -123,14 +123,12 @@ int dt3155_major = 0;
 struct dt3155_status dt3155_status[MAXBOARDS];

 /* kernel logical address of the board */
-u8 *dt3155_lbase[MAXBOARDS] = { NULL
+static void __iomem *dt3155_lbase[MAXBOARDS] = { NULL
 #if MAXBOARDS == 2
                                      , NULL
 #endif
 };
-/* DT3155 registers              */
-u8 *dt3155_bbase = NULL;                 /* kernel logical address of the *
-                                          * buffer region                 */
+
 u32  dt3155_dev_open[MAXBOARDS] = {0
 #if MAXBOARDS == 2
                                       , 0
@@ -150,11 +148,13 @@ static void quick_stop (int minor)
 {
   // TODO: scott was here
 #if 1
-  ReadMReg((dt3155_lbase[minor] + INT_CSR), int_csr_r.reg);
+  void __iomem *mmio = dt3155_lbase[minor];
+
+  int_csr_r.reg = readl(mmio + INT_CSR);
   /* disable interrupts */
   int_csr_r.fld.FLD_END_EVE_EN = 0;
   int_csr_r.fld.FLD_END_ODD_EN = 0;
-  WriteMReg((dt3155_lbase[minor] + INT_CSR), int_csr_r.reg);
+  writel(int_csr_r.reg, mmio + INT_CSR);

   dt3155_status[minor].state &= ~(DT3155_STATE_STOP|0xff);
   /* mark the system stopped: */
@@ -182,6 +182,7 @@ static void dt3155_isr(int irq, void *dev_id, struct pt_regs *regs)
   int    index;
   unsigned long flags;
   u32 buffer_addr;
+  void __iomem *mmio;

   /* find out who issued the interrupt */
   for (index = 0; index < ndevices; index++) {
@@ -198,8 +199,10 @@ static void dt3155_isr(int irq, void *dev_id, struct pt_regs *regs)
     return;
   }

+  mmio = dt3155_lbase[minor];
+
   /* Check for corruption and set a flag if so */
-  ReadMReg((dt3155_lbase[minor] + CSR1), csr1_r.reg);
+  csr1_r.reg = readl(mmio + CSR1);

   if ((csr1_r.fld.FLD_CRPT_EVE) || (csr1_r.fld.FLD_CRPT_ODD))
     {
@@ -211,7 +214,7 @@ static void dt3155_isr(int irq, void *dev_id, struct pt_regs *regs)
       return;
     }

-  ReadMReg((dt3155_lbase[minor] + INT_CSR), int_csr_r.reg);
+  int_csr_r.reg = readl(mmio + INT_CSR);

   /* Handle the even field ... */
   if (int_csr_r.fld.FLD_END_EVE)
@@ -222,7 +225,7 @@ static void dt3155_isr(int irq, void *dev_id, struct pt_regs *regs)
          dt3155_fbuffer[minor]->frame_count++;
        }

-      ReadI2C(dt3155_lbase[minor], EVEN_CSR, &i2c_even_csr.reg);
+      ReadI2C(mmio, EVEN_CSR, &i2c_even_csr.reg);

       /* Clear the interrupt? */
       int_csr_r.fld.FLD_END_EVE = 1;
@@ -242,7 +245,7 @@ static void dt3155_isr(int irq, void *dev_id, struct pt_regs *regs)
            }
        }

-      WriteMReg((dt3155_lbase[minor] + INT_CSR), int_csr_r.reg);
+      writel(int_csr_r.reg, mmio + INT_CSR);

       /* Set up next DMA if we are doing FIELDS */
       if ((dt3155_status[minor].state & DT3155_STATE_MODE) ==
@@ -260,7 +263,7 @@ static void dt3155_isr(int irq, void *dev_id, struct pt_regs *regs)

          /* Set up the DMA address for the next field */
          local_irq_restore(flags);
-         WriteMReg((dt3155_lbase[minor] + ODD_DMA_START), buffer_addr);
+         writel(buffer_addr, mmio + ODD_DMA_START);
        }

       /* Check for errors. */
@@ -268,7 +271,7 @@ static void dt3155_isr(int irq, void *dev_id, struct pt_regs *regs)
       if (i2c_even_csr.fld.ERROR_EVE)
        dt3155_errno = DT_ERR_OVERRUN;

-      WriteI2C(dt3155_lbase[minor], EVEN_CSR, i2c_even_csr.reg);
+      WriteI2C(mmio, EVEN_CSR, i2c_even_csr.reg);

       /* Note that we actually saw an even field meaning  */
       /* that subsequent odd field complete the frame     */
@@ -285,7 +288,7 @@ static void dt3155_isr(int irq, void *dev_id, struct pt_regs *regs)
   /* ... now handle the odd field */
   if (int_csr_r.fld.FLD_END_ODD)
     {
-      ReadI2C(dt3155_lbase[minor], ODD_CSR, &i2c_odd_csr.reg);
+      ReadI2C(mmio, ODD_CSR, &i2c_odd_csr.reg);

       /* Clear the interrupt? */
       int_csr_r.fld.FLD_END_ODD = 1;
@@ -321,7 +324,7 @@ static void dt3155_isr(int irq, void *dev_id, struct pt_regs *regs)
            }
        }

-      WriteMReg((dt3155_lbase[minor] + INT_CSR), int_csr_r.reg);
+      writel(int_csr_r.reg, mmio + INT_CSR);

       /* if the odd field has been acquired, then     */
       /* change the next dma location for both fields */
@@ -398,14 +401,14 @@ static void dt3155_isr(int irq, void *dev_id, struct pt_regs *regs)
       if ((dt3155_status[minor].state & DT3155_STATE_MODE) ==
           DT3155_STATE_FLD)
        {
-         WriteMReg((dt3155_lbase[minor] + EVEN_DMA_START), buffer_addr);
+         writel(buffer_addr, mmio + EVEN_DMA_START);
        }
       else
        {
-         WriteMReg((dt3155_lbase[minor] + EVEN_DMA_START), buffer_addr);
+         writel(buffer_addr, mmio + EVEN_DMA_START);

-         WriteMReg((dt3155_lbase[minor] + ODD_DMA_START), buffer_addr
-                   + dt3155_status[minor].config.cols);
+         writel(buffer_addr + dt3155_status[minor].config.cols,
+               mmio + ODD_DMA_START);
        }

       /* Do error checking */
@@ -413,7 +416,7 @@ static void dt3155_isr(int irq, void *dev_id, struct pt_regs *regs)
       if (i2c_odd_csr.fld.ERROR_ODD)
        dt3155_errno = DT_ERR_OVERRUN;

-      WriteI2C(dt3155_lbase[minor], ODD_CSR, i2c_odd_csr.reg);
+      WriteI2C(mmio, ODD_CSR, i2c_odd_csr.reg);

       return;
     }
@@ -430,6 +433,7 @@ static void dt3155_isr(int irq, void *dev_id, struct pt_regs *regs)
 static void dt3155_init_isr(int minor)
 {
   const u32 stride =  dt3155_status[minor].config.cols;
+  void __iomem *mmio = dt3155_lbase[minor];

   switch (dt3155_status[minor].state & DT3155_STATE_MODE)
     {
@@ -440,12 +444,9 @@ static void dt3155_init_isr(int minor)
        even_dma_stride_r = 0;
        odd_dma_stride_r  = 0;

-       WriteMReg((dt3155_lbase[minor] + EVEN_DMA_START),
-                 even_dma_start_r);
-       WriteMReg((dt3155_lbase[minor] + EVEN_DMA_STRIDE),
-                 even_dma_stride_r);
-       WriteMReg((dt3155_lbase[minor] + ODD_DMA_STRIDE),
-                 odd_dma_stride_r);
+       writel(even_dma_start_r, mmio + EVEN_DMA_START);
+       writel(even_dma_stride_r, mmio + EVEN_DMA_STRIDE);
+       writel(odd_dma_stride_r, mmio + ODD_DMA_STRIDE);
        break;
       }

@@ -458,14 +459,10 @@ static void dt3155_init_isr(int minor)
        even_dma_stride_r =  stride;
        odd_dma_stride_r  =  stride;

-       WriteMReg((dt3155_lbase[minor] + EVEN_DMA_START),
-                 even_dma_start_r);
-       WriteMReg((dt3155_lbase[minor] + ODD_DMA_START),
-                 odd_dma_start_r);
-       WriteMReg((dt3155_lbase[minor] + EVEN_DMA_STRIDE),
-                 even_dma_stride_r);
-       WriteMReg((dt3155_lbase[minor] + ODD_DMA_STRIDE),
-                 odd_dma_stride_r);
+       writel(even_dma_start_r, mmio + EVEN_DMA_START);
+       writel(odd_dma_start_r, mmio + ODD_DMA_START);
+       writel(even_dma_stride_r, mmio + EVEN_DMA_STRIDE);
+       writel(odd_dma_stride_r, mmio + ODD_DMA_STRIDE);
        break;
       }
     }
@@ -473,9 +470,9 @@ static void dt3155_init_isr(int minor)
   /* 50/60 Hz should be set before this point but let's make sure it is */
   /* right anyway */

-  ReadI2C(dt3155_lbase[minor], CONFIG, &i2c_csr2.reg);
+  ReadI2C(mmio, CSR2, &i2c_csr2.reg);
   i2c_csr2.fld.HZ50 = FORMAT50HZ;
-  WriteI2C(dt3155_lbase[minor], CONFIG, i2c_config.reg);
+  WriteI2C(mmio, CSR2, i2c_csr2.reg);

   /* enable busmaster chip, clear flags */

@@ -495,7 +492,7 @@ static void dt3155_init_isr(int minor)
   csr1_r.fld.FLD_CRPT_EVE   = 1; /* writing a 1 clears flags */
   csr1_r.fld.FLD_CRPT_ODD   = 1;

-  WriteMReg((dt3155_lbase[minor] + CSR1),csr1_r.reg);
+  writel(csr1_r.reg, mmio + CSR1);

   /* Enable interrupts at the end of each field */

@@ -504,14 +501,14 @@ static void dt3155_init_isr(int minor)
   int_csr_r.fld.FLD_END_ODD_EN = 1;
   int_csr_r.fld.FLD_START_EN = 0;

-  WriteMReg((dt3155_lbase[minor] + INT_CSR), int_csr_r.reg);
+  writel(int_csr_r.reg, mmio + INT_CSR);

   /* start internal BUSY bits */

-  ReadI2C(dt3155_lbase[minor], CSR2, &i2c_csr2.reg);
+  ReadI2C(mmio, CSR2, &i2c_csr2.reg);
   i2c_csr2.fld.BUSY_ODD  = 1;
   i2c_csr2.fld.BUSY_EVE  = 1;
-  WriteI2C(dt3155_lbase[minor], CSR2, i2c_csr2.reg);
+  WriteI2C(mmio, CSR2, i2c_csr2.reg);

   /* Now its up to the interrupt routine!! */

@@ -693,6 +690,8 @@ static int dt3155_mmap (struct file * file, struct vm_area_struct * vma)
 static int dt3155_open(struct inode* inode, struct file* filep)
 {
   int minor = MINOR(inode->i_rdev); /* what device are we opening? */
+  void __iomem *mmio = dt3155_lbase[minor];
+
   if (dt3155_dev_open[minor]) {
     printk ("DT3155:  Already opened by another process.\n");
     return -EBUSY;
@@ -719,7 +718,7 @@ static int dt3155_open(struct inode* inode, struct file* filep)

   /* Disable ALL interrupts */
   int_csr_r.reg = 0;
-  WriteMReg((dt3155_lbase[minor] + INT_CSR), int_csr_r.reg);
+  writel(int_csr_r.reg, mmio + INT_CSR);

   init_waitqueue_head(&(dt3155_read_wait_queue[minor]));

@@ -921,7 +920,7 @@ static int find_PCI (void)

       /* Remap the base address to a logical address through which we
        * can access it. */
-      dt3155_lbase[pci_index - 1] = ioremap(base,PCI_PAGE_SIZE);
+      dt3155_lbase[pci_index - 1] = ioremap(base, PCI_PAGE_SIZE);
       dt3155_status[pci_index - 1].reg_addr = base;
       DT_3155_DEBUG_MSG("DT3155: New logical address is %p \n",
                        dt3155_lbase[pci_index-1]);
@@ -1046,7 +1045,7 @@ int init_module(void)
   int_csr_r.reg = 0;
   for( index = 0;  index < ndevices;  index++)
     {
-      WriteMReg((dt3155_lbase[index] + INT_CSR), int_csr_r.reg);
+      writel(int_csr_r.reg, dt3155_lbase[index] + INT_CSR);
       if(dt3155_status[index].device_installed)
        {
          /*
diff --git a/drivers/staging/dt3155/dt3155_drv.h b/drivers/staging/dt3155/dt3155_drv.h
index 95e68c3..c447c61 100644
--- a/drivers/staging/dt3155/dt3155_drv.h
+++ b/drivers/staging/dt3155/dt3155_drv.h
@@ -24,12 +24,6 @@ MA 02111-1307 USA
 #ifndef DT3155_DRV_INC
 #define DT3155_DRV_INC

-/* kernel logical address of the frame grabbers */
-extern u8 *dt3155_lbase[MAXBOARDS];
-
-/* kernel logical address of ram buffer */
-extern u8 *dt3155_bbase;
-
 #ifdef __KERNEL__
 #include <linux/wait.h>

diff --git a/drivers/staging/dt3155/dt3155_io.c b/drivers/staging/dt3155/dt3155_io.c
index 7792e71..c99bd57 100644
--- a/drivers/staging/dt3155/dt3155_io.c
+++ b/drivers/staging/dt3155/dt3155_io.c
@@ -21,6 +21,8 @@
  */

 #include <linux/delay.h>
+#include <linux/io.h>
+
 #include "dt3155.h"
 #include "dt3155_io.h"
 #include "dt3155_drv.h"
@@ -75,13 +77,13 @@ u8 i2c_pm_lut_data;
  *
  * This function handles read/write timing and r/w timeout error
  */
-static int wait_ibsyclr(u8 *lpReg)
+static int wait_ibsyclr(void __iomem *mmio)
 {
        /* wait 100 microseconds */
        udelay(100L);
        /* __delay(loops_per_sec/10000); */

-       ReadMReg(lpReg + IIC_CSR2, iic_csr2_r.reg);
+       iic_csr2_r.reg = readl(mmio + IIC_CSR2);
        if (iic_csr2_r.fld.NEW_CYCLE) {
                /* if NEW_CYCLE didn't clear */
                /* TIMEOUT ERROR */
@@ -101,11 +103,10 @@ static int wait_ibsyclr(u8 *lpReg)
  * 2nd parameter is reg. index;
  * 3rd is value to be written
  */
-int WriteI2C(u8 *lpReg, u_short wIregIndex, u8 byVal)
+int WriteI2C(void __iomem *mmio, u_short wIregIndex, u8 byVal)
 {
        /* read 32 bit IIC_CSR2 register data into union */
-
-       ReadMReg((lpReg + IIC_CSR2), iic_csr2_r.reg);
+       iic_csr2_r.reg = readl(mmio + IIC_CSR2);

        /* for write operation */
        iic_csr2_r.fld.DIR_RD      = 0;
@@ -117,10 +118,10 @@ int WriteI2C(u8 *lpReg, u_short wIregIndex, u8 byVal)
        iic_csr2_r.fld.NEW_CYCLE   = 1;

        /* xfer union data into 32 bit IIC_CSR2 register */
-       WriteMReg((lpReg + IIC_CSR2), iic_csr2_r.reg);
+       writel(iic_csr2_r.reg, mmio + IIC_CSR2);

        /* wait for IIC cycle to finish */
-       return wait_ibsyclr(lpReg);
+       return wait_ibsyclr(mmio);
 }

 /*
@@ -132,12 +133,12 @@ int WriteI2C(u8 *lpReg, u_short wIregIndex, u8 byVal)
  * 2nd parameter is reg. index;
  * 3rd is adrs of value to be read
  */
-int ReadI2C(u8 *lpReg, u_short wIregIndex, u8 *byVal)
+int ReadI2C(void __iomem *mmio, u_short wIregIndex, u8 *byVal)
 {
        int writestat;  /* status for return */

        /*  read 32 bit IIC_CSR2 register data into union */
-       ReadMReg((lpReg + IIC_CSR2), iic_csr2_r.reg);
+       iic_csr2_r.reg = readl(mmio + IIC_CSR2);

        /*  for read operation */
        iic_csr2_r.fld.DIR_RD     = 1;
@@ -149,14 +150,14 @@ int ReadI2C(u8 *lpReg, u_short wIregIndex, u8 *byVal)
        iic_csr2_r.fld.NEW_CYCLE  = 1;

        /*  xfer union's data into 32 bit IIC_CSR2 register */
-       WriteMReg((lpReg + IIC_CSR2), iic_csr2_r.reg);
+       writel(iic_csr2_r.reg, mmio + IIC_CSR2);

        /* wait for IIC cycle to finish */
-       writestat = wait_ibsyclr(lpReg);
+       writestat = wait_ibsyclr(mmio);

        /* Next 2 commands read 32 bit IIC_CSR1 register's data into union */
        /* first read data is in IIC_CSR1 */
-       ReadMReg((lpReg + IIC_CSR1), iic_csr1_r.reg);
+       iic_csr1_r.reg = readl(mmio + IIC_CSR1);

        /* now get data u8 out of register */
        *byVal = (u8) iic_csr1_r.fld.RD_DATA;
diff --git a/drivers/staging/dt3155/dt3155_io.h b/drivers/staging/dt3155/dt3155_io.h
index d1a2510..1445082 100644
--- a/drivers/staging/dt3155/dt3155_io.h
+++ b/drivers/staging/dt3155/dt3155_io.h
@@ -34,11 +34,6 @@ MA 02111-1307 USA
 #ifndef DT3155_IO_INC
 #define DT3155_IO_INC

-/* macros to access registers */
-
-#define WriteMReg(Address, Data)       (*((u32 *)(Address)) = Data)
-#define ReadMReg(Address, Data)                (Data = *((u32 *)(Address)))
-
 /***************** 32 bit register globals  **************/

 /*  offsets for 32-bit memory mapped registers */
@@ -351,8 +346,7 @@ extern u8                   i2c_pm_lut_data;
 /* Functions for Global use */

 /* access 8-bit IIC registers */
-
-extern int ReadI2C(u8 *lpReg, u_short wIregIndex, u8 *byVal);
-extern int WriteI2C(u8 *lpReg, u_short wIregIndex, u8 byVal);
+extern int ReadI2C(void __iomem *mmio, u_short wIregIndex, u8 *byVal);
+extern int WriteI2C(void __iomem *mmio, u_short wIregIndex, u8 byVal);

 #endif


^ permalink raw reply related	[flat|nested] 21+ messages in thread

* Re: Staging: dt3155: Cleanup memory mapped i/o access
  2010-05-04 20:53                           ` H Hartley Sweeten
@ 2010-05-04 21:02                             ` Greg KH
  2010-05-04 21:22                               ` H Hartley Sweeten
  0 siblings, 1 reply; 21+ messages in thread
From: Greg KH @ 2010-05-04 21:02 UTC (permalink / raw)
  To: H Hartley Sweeten; +Cc: Joe Perches, Greg KH, devel, ss, Linux Kernel

On Tue, May 04, 2010 at 03:53:10PM -0500, H Hartley Sweeten wrote:
> On Tuesday, May 04, 2010 1:12 PM, Greg KH wrote:
> >>> I needed to add a git checkout origin/staging-next
> >> 
> >> That tree is still missing a couple commits that are in Linus' tree:
> >> 
> >> commit 6536560cabab170ed2969b005bf69a496e9c45bf
> >>     Staging: dt3155: fix 50Hz configuration
> >> 
> >> commit 74a920139a0f1119c5a604cef0ce5d6f591dc782
> >>     staging: fix dt3155 build
> >
> > Yes, if you look, the staging-next branch starts on Linus's tree as of
> > April 8 (just after 2.6.34-rc3).  I don't merge back to Linus's tree a
> > bunch, because that is not how it should be done.  When I am going to
> > push these to Linus, then I will merge and handle any fixups if needed.
> 
> Ok.
> 
> >> Which would probably explain the conflict that occurs in linux-next for
> >> dt3155_drv.c.
> >
> > Yes.  And how easy it is to fix up :)
> 
> Ok.
> 
> >> commit 9e1bd9a6f8c6ad8b461294a365c49b19212178d9
> >> Merge: 5382319 e595eea
> >> Author: Stephen Rothwell <sfr@canb.auug.org.au>
> >> Date:   Tue May 4 15:42:20 2010 +1000
> >> 
> >>     Merge remote branch 'staging-next/staging-next'
> >>     
> >>     Conflicts:
> >>         drivers/staging/arlan/arlan-main.c
> >>         drivers/staging/comedi/drivers/cb_das16_cs.c
> >>         drivers/staging/cx25821/cx25821-alsa.c
> >>         drivers/staging/dt3155/dt3155_drv.c
> >>         drivers/staging/netwave/netwave_cs.c
> >
> > That doesn't explain how you aren't seeing the correct stuff to base
> > your patches off of though.
> 
> I may be seeing the correct stuff now in your staging-next tree just not
> in linux-next due to the two commits above.
> 
> > Are you _sure_ you have the 'staging-next' branch of the tree checked
> > out?
> 
> Am I _sure_...  No...  Do I _think_ so...  Yes... ;-)

Ah, ok, the issue is the merge is causing your patch to not apply to my
staging-next tree.  Sorry, now I get it :)

> Would you like me to rebase the patch to staging-next to see?

Your patches, yes, I would :)

> But, will this run into a similar problem with the two commits already in
> Linus' tree?  If so I can just hold off again until everything catches up.

No, I can handle that merge when it happens, quite fine.

thanks,

greg k-h

^ permalink raw reply	[flat|nested] 21+ messages in thread

* RE: Staging: dt3155: Cleanup memory mapped i/o access
  2010-05-04 20:12                         ` Greg KH
@ 2010-05-04 20:53                           ` H Hartley Sweeten
  2010-05-04 21:02                             ` Greg KH
  0 siblings, 1 reply; 21+ messages in thread
From: H Hartley Sweeten @ 2010-05-04 20:53 UTC (permalink / raw)
  To: Greg KH; +Cc: Joe Perches, Greg KH, devel, ss, Linux Kernel

On Tuesday, May 04, 2010 1:12 PM, Greg KH wrote:
>>> I needed to add a git checkout origin/staging-next
>> 
>> That tree is still missing a couple commits that are in Linus' tree:
>> 
>> commit 6536560cabab170ed2969b005bf69a496e9c45bf
>>     Staging: dt3155: fix 50Hz configuration
>> 
>> commit 74a920139a0f1119c5a604cef0ce5d6f591dc782
>>     staging: fix dt3155 build
>
> Yes, if you look, the staging-next branch starts on Linus's tree as of
> April 8 (just after 2.6.34-rc3).  I don't merge back to Linus's tree a
> bunch, because that is not how it should be done.  When I am going to
> push these to Linus, then I will merge and handle any fixups if needed.

Ok.

>> Which would probably explain the conflict that occurs in linux-next for
>> dt3155_drv.c.
>
> Yes.  And how easy it is to fix up :)

Ok.

>> commit 9e1bd9a6f8c6ad8b461294a365c49b19212178d9
>> Merge: 5382319 e595eea
>> Author: Stephen Rothwell <sfr@canb.auug.org.au>
>> Date:   Tue May 4 15:42:20 2010 +1000
>> 
>>     Merge remote branch 'staging-next/staging-next'
>>     
>>     Conflicts:
>>         drivers/staging/arlan/arlan-main.c
>>         drivers/staging/comedi/drivers/cb_das16_cs.c
>>         drivers/staging/cx25821/cx25821-alsa.c
>>         drivers/staging/dt3155/dt3155_drv.c
>>         drivers/staging/netwave/netwave_cs.c
>
> That doesn't explain how you aren't seeing the correct stuff to base
> your patches off of though.

I may be seeing the correct stuff now in your staging-next tree just not
in linux-next due to the two commits above.

> Are you _sure_ you have the 'staging-next' branch of the tree checked
> out?

Am I _sure_...  No...  Do I _think_ so...  Yes... ;-)

Would you like me to rebase the patch to staging-next to see?

But, will this run into a similar problem with the two commits already in
Linus' tree?  If so I can just hold off again until everything catches up.

Regards,
Hartley

^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: Staging: dt3155: Cleanup memory mapped i/o access
  2010-05-04 20:02                       ` H Hartley Sweeten
@ 2010-05-04 20:12                         ` Greg KH
  2010-05-04 20:53                           ` H Hartley Sweeten
  0 siblings, 1 reply; 21+ messages in thread
From: Greg KH @ 2010-05-04 20:12 UTC (permalink / raw)
  To: H Hartley Sweeten; +Cc: Joe Perches, Greg KH, devel, ss, Linux Kernel

On Tue, May 04, 2010 at 03:02:35PM -0500, H Hartley Sweeten wrote:
> On Tuesday, May 04, 2010 12:07 PM, Joe Perches wrote:
> > On Mon, 2010-05-03 at 19:54 -0700, Greg KH wrote: 
> >>> git push?
> >> I have, and they look to be there to me:
> >>   http://git.kernel.org/?p=linux/kernel/git/gregkh/staging-next-2.6.git;a=commit;h=4f923d004396ef272600d381a365cac9d832486d
> >> So something must be odd on your side.
> >
> > Yup, sorry, my mistake.
> >
> > staging-next is the name of your repository as well as
> > a branch within your repository and git after git clone
> > doesn't by default show all remote branches.
> >
> > $ git clone --reference=linux-2.6 \
> >	git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging-next-2.6.git
> >
> > $ git branch -r
> >   origin/HEAD -> origin/master
> >   origin/master
> >   origin/staging-next
> >
> > I needed to add a git checkout origin/staging-next
> 
> That tree is still missing a couple commits that are in Linus' tree:
> 
> commit 6536560cabab170ed2969b005bf69a496e9c45bf
>     Staging: dt3155: fix 50Hz configuration
> 
> commit 74a920139a0f1119c5a604cef0ce5d6f591dc782
>     staging: fix dt3155 build

Yes, if you look, the staging-next branch starts on Linus's tree as of
April 8 (just after 2.6.34-rc3).  I don't merge back to Linus's tree a
bunch, because that is not how it should be done.  When I am going to
push these to Linus, then I will merge and handle any fixups if needed.

> Which would probably explain the conflict that occurs in linux-next for
> dt3155_drv.c.

Yes.  And how easy it is to fix up :)

> commit 9e1bd9a6f8c6ad8b461294a365c49b19212178d9
> Merge: 5382319 e595eea
> Author: Stephen Rothwell <sfr@canb.auug.org.au>
> Date:   Tue May 4 15:42:20 2010 +1000
> 
>     Merge remote branch 'staging-next/staging-next'
>     
>     Conflicts:
>         drivers/staging/arlan/arlan-main.c
>         drivers/staging/comedi/drivers/cb_das16_cs.c
>         drivers/staging/cx25821/cx25821-alsa.c
>         drivers/staging/dt3155/dt3155_drv.c
>         drivers/staging/netwave/netwave_cs.c

That doesn't explain how you aren't seeing the correct stuff to base
your patches off of though.

Are you _sure_ you have the 'staging-next' branch of the tree checked
out?

thanks,

greg k-h

^ permalink raw reply	[flat|nested] 21+ messages in thread

* RE: Staging: dt3155: Cleanup memory mapped i/o access
  2010-05-04 19:07                     ` Joe Perches
@ 2010-05-04 20:02                       ` H Hartley Sweeten
  2010-05-04 20:12                         ` Greg KH
  0 siblings, 1 reply; 21+ messages in thread
From: H Hartley Sweeten @ 2010-05-04 20:02 UTC (permalink / raw)
  To: Joe Perches, Greg KH; +Cc: devel, ss, Linux Kernel

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="utf-8", Size: 1764 bytes --]

On Tuesday, May 04, 2010 12:07 PM, Joe Perches wrote:
> On Mon, 2010-05-03 at 19:54 -0700, Greg KH wrote: 
>>> git push?
>> I have, and they look to be there to me:
>>   http://git.kernel.org/?p=linux/kernel/git/gregkh/staging-next-2.6.git;a=commit;h=4f923d004396ef272600d381a365cac9d832486d
>> So something must be odd on your side.
>
> Yup, sorry, my mistake.
>
> staging-next is the name of your repository as well as
> a branch within your repository and git after git clone
> doesn't by default show all remote branches.
>
> $ git clone --reference=linux-2.6 \
>	git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging-next-2.6.git
>
> $ git branch -r
>   origin/HEAD -> origin/master
>   origin/master
>   origin/staging-next
>
> I needed to add a git checkout origin/staging-next

That tree is still missing a couple commits that are in Linus' tree:

commit 6536560cabab170ed2969b005bf69a496e9c45bf
    Staging: dt3155: fix 50Hz configuration

commit 74a920139a0f1119c5a604cef0ce5d6f591dc782
    staging: fix dt3155 build


Which would probably explain the conflict that occurs in linux-next for
dt3155_drv.c.


commit 9e1bd9a6f8c6ad8b461294a365c49b19212178d9
Merge: 5382319 e595eea
Author: Stephen Rothwell <sfr@canb.auug.org.au>
Date:   Tue May 4 15:42:20 2010 +1000

    Merge remote branch 'staging-next/staging-next'
    
    Conflicts:
        drivers/staging/arlan/arlan-main.c
        drivers/staging/comedi/drivers/cb_das16_cs.c
        drivers/staging/cx25821/cx25821-alsa.c
        drivers/staging/dt3155/dt3155_drv.c
        drivers/staging/netwave/netwave_cs.c

Regards,
Hartley
ÿôèº{.nÇ+‰·Ÿ®‰­†+%ŠËÿ±éݶ\x17¥Šwÿº{.nÇ+‰·¥Š{±þG«éÿŠ{ayº\x1dʇڙë,j\a­¢f£¢·hšïêÿ‘êçz_è®\x03(­éšŽŠÝ¢j"ú\x1a¶^[m§ÿÿ¾\a«þG«éÿ¢¸?™¨è­Ú&£ø§~á¶iO•æ¬z·švØ^\x14\x04\x1a¶^[m§ÿÿÃ\fÿ¶ìÿ¢¸?–I¥

^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: Staging: dt3155: Cleanup memory mapped i/o access
  2010-05-04  2:54                   ` Greg KH
@ 2010-05-04 19:07                     ` Joe Perches
  2010-05-04 20:02                       ` H Hartley Sweeten
  0 siblings, 1 reply; 21+ messages in thread
From: Joe Perches @ 2010-05-04 19:07 UTC (permalink / raw)
  To: Greg KH; +Cc: H Hartley Sweeten, devel, ss, Linux Kernel

On Mon, 2010-05-03 at 19:54 -0700, Greg KH wrote: 
> > git push?
> I have, and they look to be there to me:
>   http://git.kernel.org/?p=linux/kernel/git/gregkh/staging-next-2.6.git;a=commit;h=4f923d004396ef272600d381a365cac9d832486d
> So something must be odd on your side.

Yup, sorry, my mistake.

staging-next is the name of your repository as well as
a branch within your repository and git after git clone
doesn't by default show all remote branches.

$ git clone --reference=linux-2.6 \
	git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging-next-2.6.git

$ git branch -r
  origin/HEAD -> origin/master
  origin/master
  origin/staging-next

I needed to add a git checkout origin/staging-next



^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: Staging: dt3155: Cleanup memory mapped i/o access
  2010-05-03 23:59                 ` Joe Perches
@ 2010-05-04  2:54                   ` Greg KH
  2010-05-04 19:07                     ` Joe Perches
  0 siblings, 1 reply; 21+ messages in thread
From: Greg KH @ 2010-05-04  2:54 UTC (permalink / raw)
  To: Joe Perches; +Cc: H Hartley Sweeten, devel, ss, Linux Kernel

On Mon, May 03, 2010 at 04:59:58PM -0700, Joe Perches wrote:
> On Mon, 2010-05-03 at 16:41 -0700, Greg KH wrote:
> > No, wait, I see these in my staging-next tree here.  Some of them I
> > wrote :)
> 
> There not there.
> 
> git push?

I have, and they look to be there to me:
  http://git.kernel.org/?p=linux/kernel/git/gregkh/staging-next-2.6.git;a=commit;h=4f923d004396ef272600d381a365cac9d832486d

So something must be odd on your side.

thanks,

greg k-h

^ permalink raw reply	[flat|nested] 21+ messages in thread

* RE: Staging: dt3155: Cleanup memory mapped i/o access
  2010-05-03 23:41               ` Greg KH
  2010-05-03 23:59                 ` Joe Perches
@ 2010-05-04  0:49                 ` H Hartley Sweeten
  1 sibling, 0 replies; 21+ messages in thread
From: H Hartley Sweeten @ 2010-05-04  0:49 UTC (permalink / raw)
  To: Greg KH; +Cc: Greg KH, devel, ss, Linux Kernel

On Monday, May 03, 2010 4:41 PM, Greg KH wrote:
> On Mon, May 03, 2010 at 06:33:08PM -0500, H Hartley Sweeten wrote:
>> It appears these are the patches missing in your staging-next tree that do
>> exist in the linux-next tree:
>> 
>> Staging: dt3155: remove "inline" usage
>> Staging: dt3155: rename dt3155_fbuffer_s
>> Staging: dt3155: rename dt3155_config_s
>> Staging: dt3155: rename dt3155_read_t
>> Staging: dt3155: rename dt3155_status_t
>> Staging: dt3155: remove frame_info_t
>> Staging: dt3155: remove TRUE/FALSE
>> Staging: dt3155: remove #ifdef
>> Staging: dt3155: allocator.c: sparse cleanups
>> Staging: dt3155: fix parentheses and bracket spacing style issues
>> Staging: dt3155: fix coding style issue in dt3155_isr.c
>> Staging: dt3155: fix wait_ibsyclr function
>> Staging: remove unused #include <linux/version.h>
>
> No, wait, I see these in my staging-next tree here.  Some of them I
> wrote :)
>
> Are you sure you are cloning my tree properly?

OK. I cloned your tree a different way this time.  This time I did:

$ git clone --reference ../linux-2.6 staging-2.6
Initialized empty Git repository in /home/bigguiness/src/git/z/staging-2.6/.git/
warning: You appear to have cloned an empty repository.
$ cd staging-2.6
$ git remote add staging-2.6 git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging-next-2.6.git
$ git fetch staging-2.6
remote: Counting objects: 1541325, done.
remote: Compressing objects: 100% (249801/249801), done.
remote: Total 1541325 (delta 1283336), reused 1536966 (delta 1279192)
Receiving objects: 100% (1541325/1541325), 342.86 MiB | 330 KiB/s, done.
Resolving deltas: 100% (1283336/1283336), done.
>From git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging-next-2.6
 * [new branch]      master     -> staging-2.6/master
 * [new branch]      staging-next -> staging-2.6/staging-next
 ...
$ git branch -a
  remotes/staging-2.6/master
  remotes/staging-2.6/staging-next
$ git checkout remotes/staging-2.6/staging-next
Checking out files: 100% (32340/32340), done.
Note: checking out 'remotes/staging-2.6/staging-next'.

You are in 'detached HEAD' state. You can look around, make experimental
changes and commit them, and you can discard any commits you make in this
state without impacting any branches by performing another checkout.

If you want to create a new branch to retain commits you create, you may
do so (now or later) by using -b with the checkout command again. Example:

  git checkout -b new_branch_name

HEAD is now at e595eea... Staging: comedi: __user markup on comedi_fops.c


Now it's different.  Your staging-next tree appears to be missing these patches:

Staging: dt3155: fix 50Hz configuration
staging: fix dt3155 build

Both of which change dt3155_drv.c and both of which are in Linus' tree
and the next tree.

I think this explains why you had issues with trying to merge my patch
with the dt3155_drv.c file.  But it still doesn't explain the problem
with dt3155_io.c.  All the files except dt3155_drv.c seem to match
between next-20100503 and your staging-next tree.

Argh!  git drives me nuts sometimes....

Regards,
Hartley

^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: Staging: dt3155: Cleanup memory mapped i/o access
  2010-05-03 23:41               ` Greg KH
@ 2010-05-03 23:59                 ` Joe Perches
  2010-05-04  2:54                   ` Greg KH
  2010-05-04  0:49                 ` H Hartley Sweeten
  1 sibling, 1 reply; 21+ messages in thread
From: Joe Perches @ 2010-05-03 23:59 UTC (permalink / raw)
  To: Greg KH; +Cc: H Hartley Sweeten, devel, ss, Linux Kernel

On Mon, 2010-05-03 at 16:41 -0700, Greg KH wrote:
> No, wait, I see these in my staging-next tree here.  Some of them I
> wrote :)

There not there.

git push?



^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: Staging: dt3155: Cleanup memory mapped i/o access
  2010-05-03 23:33             ` H Hartley Sweeten
  2010-05-03 23:40               ` Greg KH
@ 2010-05-03 23:41               ` Greg KH
  2010-05-03 23:59                 ` Joe Perches
  2010-05-04  0:49                 ` H Hartley Sweeten
  1 sibling, 2 replies; 21+ messages in thread
From: Greg KH @ 2010-05-03 23:41 UTC (permalink / raw)
  To: H Hartley Sweeten; +Cc: Greg KH, devel, ss, Linux Kernel

On Mon, May 03, 2010 at 06:33:08PM -0500, H Hartley Sweeten wrote:
> On Monday, May 03, 2010 3:45 PM, H Hartley Sweeten wrote:
> >>> Could the next tree be out of sync with your tree?
> >>
> >> Hm, some other tree might be doing something in those files.  But the
> >> fact that the drivers/staging/dt3155/dt3155_io.h was so wrong it thought
> >> it was a revert, makes me suspect that you did it against something
> >> else.
> >>
> >> If you make this against my staging-next tree at
> >> git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging-next-2.6.git
> >> Using the staging-next branch, does that make the patch different?
> >
> > Ok.  Pulled your staging-next (thanks Joe).
> >
> > It's way different from linux-next and matches Linus' tree exactly.  It's
> > missing all of your "Drop the "_s"..." and "The typedef is not needed." 
> > patches.
> >
> > Of course I could be on the wrong branch for your staging-next tree.  The
> > only branches listed are:
> >
> > $ git branch -a
> > * master
> >   remotes/origin/HEAD -> origin/master
> >   remotes/origin/master
> 
> It appears these are the patches missing in your staging-next tree that do
> exist in the linux-next tree:
> 
> Staging: dt3155: remove "inline" usage
> Staging: dt3155: rename dt3155_fbuffer_s
> Staging: dt3155: rename dt3155_config_s
> Staging: dt3155: rename dt3155_read_t
> Staging: dt3155: rename dt3155_status_t
> Staging: dt3155: remove frame_info_t
> Staging: dt3155: remove TRUE/FALSE
> Staging: dt3155: remove #ifdef
> Staging: dt3155: allocator.c: sparse cleanups
> Staging: dt3155: fix parentheses and bracket spacing style issues
> Staging: dt3155: fix coding style issue in dt3155_isr.c
> Staging: dt3155: fix wait_ibsyclr function
> Staging: remove unused #include <linux/version.h>

No, wait, I see these in my staging-next tree here.  Some of them I
wrote :)

Are you sure you are cloning my tree properly?

confused,

greg k-h

^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: Staging: dt3155: Cleanup memory mapped i/o access
  2010-05-03 23:33             ` H Hartley Sweeten
@ 2010-05-03 23:40               ` Greg KH
  2010-05-03 23:41               ` Greg KH
  1 sibling, 0 replies; 21+ messages in thread
From: Greg KH @ 2010-05-03 23:40 UTC (permalink / raw)
  To: H Hartley Sweeten; +Cc: Greg KH, devel, ss, Linux Kernel

On Mon, May 03, 2010 at 06:33:08PM -0500, H Hartley Sweeten wrote:
> On Monday, May 03, 2010 3:45 PM, H Hartley Sweeten wrote:
> >>> Could the next tree be out of sync with your tree?
> >>
> >> Hm, some other tree might be doing something in those files.  But the
> >> fact that the drivers/staging/dt3155/dt3155_io.h was so wrong it thought
> >> it was a revert, makes me suspect that you did it against something
> >> else.
> >>
> >> If you make this against my staging-next tree at
> >> git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging-next-2.6.git
> >> Using the staging-next branch, does that make the patch different?
> >
> > Ok.  Pulled your staging-next (thanks Joe).
> >
> > It's way different from linux-next and matches Linus' tree exactly.  It's
> > missing all of your "Drop the "_s"..." and "The typedef is not needed." 
> > patches.
> >
> > Of course I could be on the wrong branch for your staging-next tree.  The
> > only branches listed are:
> >
> > $ git branch -a
> > * master
> >   remotes/origin/HEAD -> origin/master
> >   remotes/origin/master
> 
> It appears these are the patches missing in your staging-next tree that do
> exist in the linux-next tree:
> 
> Staging: dt3155: remove "inline" usage
> Staging: dt3155: rename dt3155_fbuffer_s
> Staging: dt3155: rename dt3155_config_s
> Staging: dt3155: rename dt3155_read_t
> Staging: dt3155: rename dt3155_status_t
> Staging: dt3155: remove frame_info_t
> Staging: dt3155: remove TRUE/FALSE
> Staging: dt3155: remove #ifdef
> Staging: dt3155: allocator.c: sparse cleanups
> Staging: dt3155: fix parentheses and bracket spacing style issues
> Staging: dt3155: fix coding style issue in dt3155_isr.c
> Staging: dt3155: fix wait_ibsyclr function
> Staging: remove unused #include <linux/version.h>

Odd, what branch did they come from?

> The first one that exists in both is:
> 
> Staging: dt3155: fix 50Hz configuration
> 
> Could the others be in a staging-stable branch?

I do not know, they don't look to be something I've seen.

thanks,

greg k-h

^ permalink raw reply	[flat|nested] 21+ messages in thread

* RE: Staging: dt3155: Cleanup memory mapped i/o access
  2010-05-03 22:45           ` H Hartley Sweeten
@ 2010-05-03 23:33             ` H Hartley Sweeten
  2010-05-03 23:40               ` Greg KH
  2010-05-03 23:41               ` Greg KH
  0 siblings, 2 replies; 21+ messages in thread
From: H Hartley Sweeten @ 2010-05-03 23:33 UTC (permalink / raw)
  To: H Hartley Sweeten, Greg KH; +Cc: devel, ss, Greg KH, Linux Kernel

On Monday, May 03, 2010 3:45 PM, H Hartley Sweeten wrote:
>>> Could the next tree be out of sync with your tree?
>>
>> Hm, some other tree might be doing something in those files.  But the
>> fact that the drivers/staging/dt3155/dt3155_io.h was so wrong it thought
>> it was a revert, makes me suspect that you did it against something
>> else.
>>
>> If you make this against my staging-next tree at
>> git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging-next-2.6.git
>> Using the staging-next branch, does that make the patch different?
>
> Ok.  Pulled your staging-next (thanks Joe).
>
> It's way different from linux-next and matches Linus' tree exactly.  It's
> missing all of your "Drop the "_s"..." and "The typedef is not needed." 
> patches.
>
> Of course I could be on the wrong branch for your staging-next tree.  The
> only branches listed are:
>
> $ git branch -a
> * master
>   remotes/origin/HEAD -> origin/master
>   remotes/origin/master

It appears these are the patches missing in your staging-next tree that do
exist in the linux-next tree:

Staging: dt3155: remove "inline" usage
Staging: dt3155: rename dt3155_fbuffer_s
Staging: dt3155: rename dt3155_config_s
Staging: dt3155: rename dt3155_read_t
Staging: dt3155: rename dt3155_status_t
Staging: dt3155: remove frame_info_t
Staging: dt3155: remove TRUE/FALSE
Staging: dt3155: remove #ifdef
Staging: dt3155: allocator.c: sparse cleanups
Staging: dt3155: fix parentheses and bracket spacing style issues
Staging: dt3155: fix coding style issue in dt3155_isr.c
Staging: dt3155: fix wait_ibsyclr function
Staging: remove unused #include <linux/version.h>

The first one that exists in both is:

Staging: dt3155: fix 50Hz configuration

Could the others be in a staging-stable branch?

Regards,
Hartley

^ permalink raw reply	[flat|nested] 21+ messages in thread

* RE: Staging: dt3155: Cleanup memory mapped i/o access
  2010-05-03 21:17         ` Greg KH
  2010-05-03 22:24           ` H Hartley Sweeten
@ 2010-05-03 22:45           ` H Hartley Sweeten
  2010-05-03 23:33             ` H Hartley Sweeten
  1 sibling, 1 reply; 21+ messages in thread
From: H Hartley Sweeten @ 2010-05-03 22:45 UTC (permalink / raw)
  To: Greg KH; +Cc: Linux Kernel, devel, Greg KH, ss

On Monday, May 03, 2010 2:18 PM, Greg KH wrote:
>>> Did you rebase this on the latest linux-next tree?
>> 
>> I did.  And I just re-did is again against next-20100503 and it generated the same patch.
>
> Wierd.
>
>> But, I just noticed this:
>> 
>> $ git log drivers/staging/dt3155
>> commit 3c59b4691587b8977cc77ecf07985758a2ba0d97
>> Merge: 7f1e428 bed46a8
>> Author: Stephen Rothwell <sfr@canb.auug.org.au>
>> Date:   Mon May 3 14:17:49 2010 +1000
>> 
>>     Merge remote branch 'staging-next/staging-next'
>>     
>>     Conflicts:
>>         drivers/staging/arlan/arlan-main.c
>>         drivers/staging/comedi/drivers/cb_das16_cs.c
>>         drivers/staging/cx25821/cx25821-alsa.c
>>         drivers/staging/dt3155/dt3155_drv.c
>>         drivers/staging/netwave/netwave_cs.c
>> 
>> Could the next tree be out of sync with your tree?
>
> Hm, some other tree might be doing something in those files.  But the
> fact that the drivers/staging/dt3155/dt3155_io.h was so wrong it thought
> it was a revert, makes me suspect that you did it against something
> else.
>
> If you make this against my staging-next tree at
> git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging-next-2.6.git
> U sing the staging-next branch, does that make the patch different?

Ok.  Pulled your staging-next (thanks Joe).

It's way different from linux-next and matches Linus' tree exactly.  It's
missing all of your "Drop the "_s"..." and "The typedef is not needed." 
patches.

Of course I could be on the wrong branch for your staging-next tree.  The
only branches listed are:

$ git branch -a
* master
  remotes/origin/HEAD -> origin/master
  remotes/origin/master

Regards,
Hartley

^ permalink raw reply	[flat|nested] 21+ messages in thread

* RE: Staging: dt3155: Cleanup memory mapped i/o access
  2010-05-03 21:17         ` Greg KH
@ 2010-05-03 22:24           ` H Hartley Sweeten
  2010-05-03 22:45           ` H Hartley Sweeten
  1 sibling, 0 replies; 21+ messages in thread
From: H Hartley Sweeten @ 2010-05-03 22:24 UTC (permalink / raw)
  To: Greg KH; +Cc: Linux Kernel, devel, Greg KH, ss

On Monday, May 03, 2010 2:18 PM, Greg KH wrote:
>>> Did you rebase this on the latest linux-next tree?
>> 
>> I did.  And I just re-did is again against next-20100503 and it generated
>> the same patch.
>
> Wierd.
>
>> But, I just noticed this:
>> 
>> $ git log drivers/staging/dt3155
>> commit 3c59b4691587b8977cc77ecf07985758a2ba0d97
>> Merge: 7f1e428 bed46a8
>> Author: Stephen Rothwell <sfr@canb.auug.org.au>
>> Date:   Mon May 3 14:17:49 2010 +1000
>> 
>>     Merge remote branch 'staging-next/staging-next'
>>     
>>     Conflicts:
>>         drivers/staging/arlan/arlan-main.c
>>         drivers/staging/comedi/drivers/cb_das16_cs.c
>>         drivers/staging/cx25821/cx25821-alsa.c
>>         drivers/staging/dt3155/dt3155_drv.c
>>         drivers/staging/netwave/netwave_cs.c
>> 
>> Could the next tree be out of sync with your tree?
>
> Hm, some other tree might be doing something in those files.  But the
> fact that the drivers/staging/dt3155/dt3155_io.h was so wrong it thought
> it was a revert, makes me suspect that you did it against something
> else.

I just looked at the Next/merge.log file for next-20100503.

$ git merge origin/master
...
 drivers/staging/dt3155/dt3155_drv.c               |    4 +-
...
$ git merge staging-next/staging-next
...
Resolved 'drivers/staging/dt3155/dt3155_drv.c' using previous resolution.
...
Auto-merging drivers/staging/dt3155/dt3155_drv.c
CONFLICT (content): Merge conflict in drivers/staging/dt3155/dt3155_drv.c
...
$ git diff -M --stat --summary HEAD^..
...
 drivers/staging/dt3155/allocator.c                 |   16 +-
 drivers/staging/dt3155/allocator.h                 |    4 +-
 drivers/staging/dt3155/dt3155.h                    |   44 +-
 drivers/staging/dt3155/dt3155_drv.c                |  380 +-
 drivers/staging/dt3155/dt3155_io.c                 |   24 +-
 drivers/staging/dt3155/dt3155_isr.c                |  297 +-
 drivers/staging/dt3155/dt3155_isr.h                |    2 +-
...

Not sure if that helps...

>
> If you make this against my staging-next tree at
> git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging-next-2.6.git
> using the staging-next branch, does that make the patch different?
>
> Let me know if you need help doing that.

I just tried pulling that tree and got:

$ git pull git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging-next-2.6.git
fatal: Not a git repository (or any of the parent directories): .git

So, yes I need help doing that ;-)

Regards,
Hartley

^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: Staging: dt3155: Cleanup memory mapped i/o access
  2010-05-03 20:15       ` H Hartley Sweeten
@ 2010-05-03 21:17         ` Greg KH
  2010-05-03 22:24           ` H Hartley Sweeten
  2010-05-03 22:45           ` H Hartley Sweeten
  0 siblings, 2 replies; 21+ messages in thread
From: Greg KH @ 2010-05-03 21:17 UTC (permalink / raw)
  To: H Hartley Sweeten; +Cc: Linux Kernel, devel, Greg KH, ss

On Mon, May 03, 2010 at 03:15:42PM -0500, H Hartley Sweeten wrote:
> On Monday, May 03, 2010 12:00 PM, Greg KH wrote:
> > On Sun, May 02, 2010 at 01:00:41PM -0500, H Hartley Sweeten wrote:
> >> The macros ReadMReg and WriteMReg are really just private versions of
> >> the kernel's readl and writel functions.  Use the kernel's functions
> >> instead.  And since ioremap returns a (void __iomem *) not a (u8 *),
> >> change all the uses of dt3155_lbase to reflect this.
> >> 
> >> While here, make dt3155_lbase static since it is only used in the
> >> dt3155_drv.c file.  Also, remove the global variable dt3155_bbase
> >> since it is not used anywhere in the code.
> >> 
> >> Where is makes sense, create a local 'mmio' variable instead of using
> >> dt3155_lbase[minor] to make the code more readable.
> >> 
> >> This change also affects the {Read|Write}I2C functions so they are
> >> also modified as needed.
> >> 
> >> Signed-off-by: H Hartley Sweeten <hsweeten@visionengravers.com>
> >> Cc: Scott Smedley <ss@aao.gov.au>
> >
> > Odd, but no, this still does not apply.  I get the following errors:
> > patching file drivers/staging/dt3155/dt3155_drv.c
> > Hunk #1 succeeded at 75 (offset 11 lines).
> > Hunk #2 FAILED at 115.
> > Hunk #3 succeeded at 150 (offset 8 lines).
> > Hunk #4 succeeded at 184 (offset 8 lines).
> > Hunk #5 succeeded at 201 (offset 8 lines).
> > Hunk #6 succeeded at 216 (offset 8 lines).
> > Hunk #7 succeeded at 227 with fuzz 2 (offset 8 lines).
> > Hunk #8 succeeded at 247 with fuzz 2 (offset 8 lines).
> > Hunk #9 FAILED at 257.
> > Hunk #10 succeeded at 273 with fuzz 2 (offset 8 lines).
> > Hunk #11 succeeded at 290 (offset 8 lines).
> > Hunk #12 succeeded at 326 with fuzz 2 (offset 8 lines).
> > Hunk #13 FAILED at 395.
> > Hunk #14 succeeded at 418 with fuzz 2 (offset 8 lines).
> > Hunk #15 succeeded at 435 (offset 8 lines).
> > Hunk #16 FAILED at 438.
> > Hunk #17 FAILED at 456.
> > Hunk #18 FAILED at 471.
> > Hunk #19 succeeded at 501 (offset 8 lines).
> > Hunk #20 succeeded at 510 (offset 8 lines).
> > Hunk #21 succeeded at 699 (offset 8 lines).
> > Hunk #22 succeeded at 727 (offset 8 lines).
> > Hunk #23 succeeded at 929 with fuzz 1 (offset 8 lines).
> > Hunk #24 succeeded at 1054 with fuzz 2 (offset 8 lines).
> > 6 out of 24 hunks FAILED -- saving rejects to file drivers/staging/dt3155/dt3155_drv.c.rej
> > patching file drivers/staging/dt3155/dt3155_drv.h
> > patching file drivers/staging/dt3155/dt3155_io.c
> > Hunk #2 FAILED at 77.
> > Hunk #3 FAILED at 103.
> > Hunk #4 FAILED at 119.
> > Hunk #5 FAILED at 134.
> > Hunk #6 FAILED at 151.
> > 5 out of 6 hunks FAILED -- saving rejects to file drivers/staging/dt3155/dt3155_io.c.rej
> > patching file drivers/staging/dt3155/dt3155_io.h
> > Reversed (or previously applied) patch detected!  Assume -R? [n] 
> > Apply anyway? [n] 
> > Skipping patch.
> > 2 out of 2 hunks ignored -- saving rejects to file drivers/staging/dt3155/dt3155_io.h.rej
> > 
> > 
> > Did you rebase this on the latest linux-next tree?
> 
> I did.  And I just re-did is again against next-20100503 and it generated the same patch.

Wierd.

> But, I just noticed this:
> 
> $ git log drivers/staging/dt3155
> commit 3c59b4691587b8977cc77ecf07985758a2ba0d97
> Merge: 7f1e428 bed46a8
> Author: Stephen Rothwell <sfr@canb.auug.org.au>
> Date:   Mon May 3 14:17:49 2010 +1000
> 
>     Merge remote branch 'staging-next/staging-next'
>     
>     Conflicts:
>         drivers/staging/arlan/arlan-main.c
>         drivers/staging/comedi/drivers/cb_das16_cs.c
>         drivers/staging/cx25821/cx25821-alsa.c
>         drivers/staging/dt3155/dt3155_drv.c
>         drivers/staging/netwave/netwave_cs.c
> 
> Could the next tree be out of sync with your tree?

Hm, some other tree might be doing something in those files.  But the
fact that the drivers/staging/dt3155/dt3155_io.h was so wrong it thought
it was a revert, makes me suspect that you did it against something
else.

If you make this against my staging-next tree at
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging-next-2.6.git
using the staging-next branch, does that make the patch different?

Let me know if you need help doing that.

thanks,

greg k-h

^ permalink raw reply	[flat|nested] 21+ messages in thread

* RE: Staging: dt3155: Cleanup memory mapped i/o access
  2010-05-03 18:59     ` Greg KH
@ 2010-05-03 20:15       ` H Hartley Sweeten
  2010-05-03 21:17         ` Greg KH
  0 siblings, 1 reply; 21+ messages in thread
From: H Hartley Sweeten @ 2010-05-03 20:15 UTC (permalink / raw)
  To: Greg KH; +Cc: Linux Kernel, devel, Greg KH, ss

On Monday, May 03, 2010 12:00 PM, Greg KH wrote:
> On Sun, May 02, 2010 at 01:00:41PM -0500, H Hartley Sweeten wrote:
>> The macros ReadMReg and WriteMReg are really just private versions of
>> the kernel's readl and writel functions.  Use the kernel's functions
>> instead.  And since ioremap returns a (void __iomem *) not a (u8 *),
>> change all the uses of dt3155_lbase to reflect this.
>> 
>> While here, make dt3155_lbase static since it is only used in the
>> dt3155_drv.c file.  Also, remove the global variable dt3155_bbase
>> since it is not used anywhere in the code.
>> 
>> Where is makes sense, create a local 'mmio' variable instead of using
>> dt3155_lbase[minor] to make the code more readable.
>> 
>> This change also affects the {Read|Write}I2C functions so they are
>> also modified as needed.
>> 
>> Signed-off-by: H Hartley Sweeten <hsweeten@visionengravers.com>
>> Cc: Scott Smedley <ss@aao.gov.au>
>
> Odd, but no, this still does not apply.  I get the following errors:
> patching file drivers/staging/dt3155/dt3155_drv.c
> Hunk #1 succeeded at 75 (offset 11 lines).
> Hunk #2 FAILED at 115.
> Hunk #3 succeeded at 150 (offset 8 lines).
> Hunk #4 succeeded at 184 (offset 8 lines).
> Hunk #5 succeeded at 201 (offset 8 lines).
> Hunk #6 succeeded at 216 (offset 8 lines).
> Hunk #7 succeeded at 227 with fuzz 2 (offset 8 lines).
> Hunk #8 succeeded at 247 with fuzz 2 (offset 8 lines).
> Hunk #9 FAILED at 257.
> Hunk #10 succeeded at 273 with fuzz 2 (offset 8 lines).
> Hunk #11 succeeded at 290 (offset 8 lines).
> Hunk #12 succeeded at 326 with fuzz 2 (offset 8 lines).
> Hunk #13 FAILED at 395.
> Hunk #14 succeeded at 418 with fuzz 2 (offset 8 lines).
> Hunk #15 succeeded at 435 (offset 8 lines).
> Hunk #16 FAILED at 438.
> Hunk #17 FAILED at 456.
> Hunk #18 FAILED at 471.
> Hunk #19 succeeded at 501 (offset 8 lines).
> Hunk #20 succeeded at 510 (offset 8 lines).
> Hunk #21 succeeded at 699 (offset 8 lines).
> Hunk #22 succeeded at 727 (offset 8 lines).
> Hunk #23 succeeded at 929 with fuzz 1 (offset 8 lines).
> Hunk #24 succeeded at 1054 with fuzz 2 (offset 8 lines).
> 6 out of 24 hunks FAILED -- saving rejects to file drivers/staging/dt3155/dt3155_drv.c.rej
> patching file drivers/staging/dt3155/dt3155_drv.h
> patching file drivers/staging/dt3155/dt3155_io.c
> Hunk #2 FAILED at 77.
> Hunk #3 FAILED at 103.
> Hunk #4 FAILED at 119.
> Hunk #5 FAILED at 134.
> Hunk #6 FAILED at 151.
> 5 out of 6 hunks FAILED -- saving rejects to file drivers/staging/dt3155/dt3155_io.c.rej
> patching file drivers/staging/dt3155/dt3155_io.h
> Reversed (or previously applied) patch detected!  Assume -R? [n] 
> Apply anyway? [n] 
> Skipping patch.
> 2 out of 2 hunks ignored -- saving rejects to file drivers/staging/dt3155/dt3155_io.h.rej
> 
> 
> Did you rebase this on the latest linux-next tree?

I did.  And I just re-did is again against next-20100503 and it generated the same patch.

But, I just noticed this:

$ git log drivers/staging/dt3155
commit 3c59b4691587b8977cc77ecf07985758a2ba0d97
Merge: 7f1e428 bed46a8
Author: Stephen Rothwell <sfr@canb.auug.org.au>
Date:   Mon May 3 14:17:49 2010 +1000

    Merge remote branch 'staging-next/staging-next'
    
    Conflicts:
        drivers/staging/arlan/arlan-main.c
        drivers/staging/comedi/drivers/cb_das16_cs.c
        drivers/staging/cx25821/cx25821-alsa.c
        drivers/staging/dt3155/dt3155_drv.c
        drivers/staging/netwave/netwave_cs.c

Could the next tree be out of sync with your tree?

Regards,
Hartley

^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: Staging: dt3155: Cleanup memory mapped i/o access
  2010-05-02 18:00   ` H Hartley Sweeten
@ 2010-05-03 18:59     ` Greg KH
  2010-05-03 20:15       ` H Hartley Sweeten
  0 siblings, 1 reply; 21+ messages in thread
From: Greg KH @ 2010-05-03 18:59 UTC (permalink / raw)
  To: H Hartley Sweeten; +Cc: Linux Kernel, devel, Greg KH, ss

On Sun, May 02, 2010 at 01:00:41PM -0500, H Hartley Sweeten wrote:
> The macros ReadMReg and WriteMReg are really just private versions of
> the kernel's readl and writel functions.  Use the kernel's functions
> instead.  And since ioremap returns a (void __iomem *) not a (u8 *),
> change all the uses of dt3155_lbase to reflect this.
> 
> While here, make dt3155_lbase static since it is only used in the
> dt3155_drv.c file.  Also, remove the global variable dt3155_bbase
> since it is not used anywhere in the code.
> 
> Where is makes sense, create a local 'mmio' variable instead of using
> dt3155_lbase[minor] to make the code more readable.
> 
> This change also affects the {Read|Write}I2C functions so they are
> also modified as needed.
> 
> Signed-off-by: H Hartley Sweeten <hsweeten@visionengravers.com>
> Cc: Scott Smedley <ss@aao.gov.au>

Odd, but no, this still does not apply.  I get the following errors:
patching file drivers/staging/dt3155/dt3155_drv.c
Hunk #1 succeeded at 75 (offset 11 lines).
Hunk #2 FAILED at 115.
Hunk #3 succeeded at 150 (offset 8 lines).
Hunk #4 succeeded at 184 (offset 8 lines).
Hunk #5 succeeded at 201 (offset 8 lines).
Hunk #6 succeeded at 216 (offset 8 lines).
Hunk #7 succeeded at 227 with fuzz 2 (offset 8 lines).
Hunk #8 succeeded at 247 with fuzz 2 (offset 8 lines).
Hunk #9 FAILED at 257.
Hunk #10 succeeded at 273 with fuzz 2 (offset 8 lines).
Hunk #11 succeeded at 290 (offset 8 lines).
Hunk #12 succeeded at 326 with fuzz 2 (offset 8 lines).
Hunk #13 FAILED at 395.
Hunk #14 succeeded at 418 with fuzz 2 (offset 8 lines).
Hunk #15 succeeded at 435 (offset 8 lines).
Hunk #16 FAILED at 438.
Hunk #17 FAILED at 456.
Hunk #18 FAILED at 471.
Hunk #19 succeeded at 501 (offset 8 lines).
Hunk #20 succeeded at 510 (offset 8 lines).
Hunk #21 succeeded at 699 (offset 8 lines).
Hunk #22 succeeded at 727 (offset 8 lines).
Hunk #23 succeeded at 929 with fuzz 1 (offset 8 lines).
Hunk #24 succeeded at 1054 with fuzz 2 (offset 8 lines).
6 out of 24 hunks FAILED -- saving rejects to file drivers/staging/dt3155/dt3155_drv.c.rej
patching file drivers/staging/dt3155/dt3155_drv.h
patching file drivers/staging/dt3155/dt3155_io.c
Hunk #2 FAILED at 77.
Hunk #3 FAILED at 103.
Hunk #4 FAILED at 119.
Hunk #5 FAILED at 134.
Hunk #6 FAILED at 151.
5 out of 6 hunks FAILED -- saving rejects to file drivers/staging/dt3155/dt3155_io.c.rej
patching file drivers/staging/dt3155/dt3155_io.h
Reversed (or previously applied) patch detected!  Assume -R? [n] 
Apply anyway? [n] 
Skipping patch.
2 out of 2 hunks ignored -- saving rejects to file drivers/staging/dt3155/dt3155_io.h.rej


Did you rebase this on the latest linux-next tree?

thanks,

greg k-h

^ permalink raw reply	[flat|nested] 21+ messages in thread

end of thread, other threads:[~2010-06-23 22:28 UTC | newest]

Thread overview: 21+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2010-06-22 23:38 [PATCH v2] Staging: dt3155: Cleanup memory mapped i/o access H Hartley Sweeten
2010-06-23 22:23 ` Greg KH
  -- strict thread matches above, loose matches on Subject: below --
2010-04-28 17:23 [PATCH] " H Hartley Sweeten
2010-04-30 21:56 ` Greg KH
2010-05-02 18:00   ` H Hartley Sweeten
2010-05-03 18:59     ` Greg KH
2010-05-03 20:15       ` H Hartley Sweeten
2010-05-03 21:17         ` Greg KH
2010-05-03 22:24           ` H Hartley Sweeten
2010-05-03 22:45           ` H Hartley Sweeten
2010-05-03 23:33             ` H Hartley Sweeten
2010-05-03 23:40               ` Greg KH
2010-05-03 23:41               ` Greg KH
2010-05-03 23:59                 ` Joe Perches
2010-05-04  2:54                   ` Greg KH
2010-05-04 19:07                     ` Joe Perches
2010-05-04 20:02                       ` H Hartley Sweeten
2010-05-04 20:12                         ` Greg KH
2010-05-04 20:53                           ` H Hartley Sweeten
2010-05-04 21:02                             ` Greg KH
2010-05-04 21:22                               ` H Hartley Sweeten
2010-05-06 16:59                                 ` H Hartley Sweeten
2010-05-06 20:25                                   ` Greg KH
2010-05-04  0:49                 ` H Hartley Sweeten

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).