[PATCH RESEND 2 1/5] staging: sm750fb: Use memset_io instead of memset

[PATCH RESEND 2 1/5] staging: sm750fb: Use memset_io instead of memset

[Lorenzo Stoakes]

This patch takes into account that cursor->vstart, crtc->vScreen and
share->pvMem are pointers to memory-mapped I/O and thus we should use memset_io
to make this explicit. In addition, some architectures require special treatment
of memory-mapped I/O so the previous code could actually break without this
change.

This fixes the following sparse warnings:-

drivers/staging/sm750fb/sm750.c:489:17: warning: incorrect type in argument 1 (different address spaces)
drivers/staging/sm750fb/sm750.c:490:17: warning: incorrect type in argument 1 (different address spaces)
drivers/staging/sm750fb/sm750.c:501:17: warning: incorrect type in argument 1 (different address spaces)
drivers/staging/sm750fb/sm750.c:502:17: warning: incorrect type in argument 1 (different address spaces)
drivers/staging/sm750fb/sm750.c:833:5: warning: incorrect type in argument 1 (different address spaces)
drivers/staging/sm750fb/sm750.c:1154:9: warning: incorrect type in argument 1 (different address spaces)

Signed-off-by: Lorenzo Stoakes <lstoakes@gmail.com>
---
 drivers/staging/sm750fb/sm750.c | 12 ++++++------
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/drivers/staging/sm750fb/sm750.c b/drivers/staging/sm750fb/sm750.c
index aa0888c..3e36b6a 100644
--- a/drivers/staging/sm750fb/sm750.c
+++ b/drivers/staging/sm750fb/sm750.c
@@ -486,8 +486,8 @@ static int lynxfb_resume(struct pci_dev* pdev)
 		par = info->par;
 		crtc = &par->crtc;
 		cursor = &crtc->cursor;
-		memset(cursor->vstart, 0x0, cursor->size);
-		memset(crtc->vScreen,0x0,crtc->vidmem_size);
+		memset_io(cursor->vstart, 0x0, cursor->size);
+		memset_io(crtc->vScreen, 0x0, crtc->vidmem_size);
 		lynxfb_ops_set_par(info);
 		fb_set_suspend(info, 0);
 	}
@@ -498,8 +498,8 @@ static int lynxfb_resume(struct pci_dev* pdev)
 		par = info->par;
 		crtc = &par->crtc;
 		cursor = &crtc->cursor;
-		memset(cursor->vstart, 0x0, cursor->size);
-		memset(crtc->vScreen,0x0,crtc->vidmem_size);
+		memset_io(cursor->vstart, 0x0, cursor->size);
+		memset_io(crtc->vScreen, 0x0, crtc->vidmem_size);
 		lynxfb_ops_set_par(info);
 		fb_set_suspend(info, 0);
 	}
@@ -830,7 +830,7 @@ static int lynxfb_set_fbinfo(struct fb_info* info,int index)


     crtc->cursor.share = share;
-    memset(crtc->cursor.vstart, 0, crtc->cursor.size);
+	memset_io(crtc->cursor.vstart, 0, crtc->cursor.size);
     if(!g_hwcursor){
         lynxfb_ops.fb_cursor = NULL;
         crtc->cursor.disable(&crtc->cursor);
@@ -1151,7 +1151,7 @@ static int lynxfb_pci_probe(struct pci_dev * pdev,
 	}
 #endif

-	memset(share->pvMem,0,share->vidmem_size);
+	memset_io(share->pvMem, 0, share->vidmem_size);

 	pr_info("sm%3x mmio address = %p\n",share->devid,share->pvReg);

--
2.3.2

[PATCH RESEND 2 2/5] staging: sm750fb: Make internal functions static

[Lorenzo Stoakes]

This patch declares externally unavailable functions static. This fixes
the following sparse warnings:-

drivers/staging/sm750fb/ddk750_hwi2c.c:63:6: warning: symbol 'hwI2CWaitTXDone' was not declared. Should it be static?
drivers/staging/sm750fb/ddk750_hwi2c.c:93:14: warning: symbol 'hwI2CWriteData' was not declared. Should it be static?
drivers/staging/sm750fb/ddk750_hwi2c.c:160:14: warning: symbol 'hwI2CReadData' was not declared. Should it be static?

Signed-off-by: Lorenzo Stoakes <lstoakes@gmail.com>
---
 drivers/staging/sm750fb/ddk750_hwi2c.c |  6 +++---
 1 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/staging/sm750fb/ddk750_hwi2c.c b/drivers/staging/sm750fb/ddk750_hwi2c.c
index 84dfb6f..7826376 100644
--- a/drivers/staging/sm750fb/ddk750_hwi2c.c
+++ b/drivers/staging/sm750fb/ddk750_hwi2c.c
@@ -60,7 +60,7 @@ void hwI2CClose(void)
 }


-long hwI2CWaitTXDone(void)
+static long hwI2CWaitTXDone(void)
 {
     unsigned int timeout;

@@ -90,7 +90,7 @@ long hwI2CWaitTXDone(void)
  *  Return Value:
  *      Total number of bytes those are actually written.
  */
-unsigned int hwI2CWriteData(
+static unsigned int hwI2CWriteData(
     unsigned char deviceAddress,
     unsigned int length,
     unsigned char *pBuffer
@@ -157,7 +157,7 @@ unsigned int hwI2CWriteData(
  *  Return Value:
  *      Total number of actual bytes read from the slave device
  */
-unsigned int hwI2CReadData(
+static unsigned int hwI2CReadData(
     unsigned char deviceAddress,
     unsigned int length,
     unsigned char *pBuffer
--
2.3.2

[PATCH RESEND 2 3/5] staging: sm750fb: Remove unused function

This patch removes the unused hw712_fillrect function. This patch fixes
the following sparse warning:-

drivers/staging/sm750fb/sm750_accel.c:95:5: warning: symbol 'hw712_fillrect' was not declared. Should it be static?

Signed-off-by: Lorenzo Stoakes <lstoakes@gmail.com>
---
 drivers/staging/sm750fb/sm750_accel.c | 78 -----------------------------------
 1 file changed, 78 deletions(-)

diff --git a/drivers/staging/sm750fb/sm750_accel.c b/drivers/staging/sm750fb/sm750_accel.c
index 6521c3b..c5a3726 100644
--- a/drivers/staging/sm750fb/sm750_accel.c
+++ b/drivers/staging/sm750fb/sm750_accel.c
@@ -89,84 +89,6 @@ void hw_set2dformat(struct lynx_accel * accel,int fmt)
 	write_dpr(accel,DE_STRETCH_FORMAT,reg);
 }

-/* seems sm712 RectFill command is broken,so need use BitBlt to
- * replace it. */
-
-int hw712_fillrect(struct lynx_accel * accel,
-				u32 base,u32 pitch,u32 Bpp,
-				u32 x,u32 y,u32 width,u32 height,
-				u32 color,u32 rop)
-{
-	u32 deCtrl;
-	if(accel->de_wait() != 0)
-	{
-		/* int time wait and always busy,seems hardware
-		 * got something error */
-		pr_debug("%s:De engine always bussy\n",__func__);
-		return -1;
-	}
-	/* 24bpp 2d acceleration still not work,we already support 2d on
-	 * both 8/16/32 bpp now, so there is no harm if we disable 2d on
-	 * 24bpp for current stage. */
-#if 0
-	if(Bpp == 3){
-		width *= 3;
-		x *= 3;
-		write_dpr(accel,DE_PITCH,
-			FIELD_VALUE(0,DE_PITCH,DESTINATION,pitch)|
-			FIELD_VALUE(0,DE_PITCH,SOURCE,pitch));//dpr10
-	}
-	else
-#endif
-	{
-		write_dpr(accel,DE_PITCH,
-			FIELD_VALUE(0,DE_PITCH,DESTINATION,pitch/Bpp)|
-			FIELD_VALUE(0,DE_PITCH,SOURCE,pitch/Bpp));//dpr10
-
-	}
-
-	write_dpr(accel,DE_FOREGROUND,color);//DPR14
-	write_dpr(accel,DE_MONO_PATTERN_HIGH,~0);//DPR34
-	write_dpr(accel,DE_MONO_PATTERN_LOW,~0);//DPR38
-
-	write_dpr(accel,DE_WINDOW_SOURCE_BASE,base);//dpr44
-	write_dpr(accel,DE_WINDOW_DESTINATION_BASE,base);//dpr40
-
-
-	write_dpr(accel,DE_WINDOW_WIDTH,
-			FIELD_VALUE(0,DE_WINDOW_WIDTH,DESTINATION,pitch/Bpp)|
-			FIELD_VALUE(0,DE_WINDOW_WIDTH,SOURCE,pitch/Bpp));//dpr3c
-
-
-	write_dpr(accel,DE_DESTINATION,
-			FIELD_SET(0,DE_DESTINATION,WRAP,DISABLE)|
-			FIELD_VALUE(0,DE_DESTINATION,X,x)|
-			FIELD_VALUE(0,DE_DESTINATION,Y,y));//dpr4
-
-	write_dpr(accel,DE_DIMENSION,
-			FIELD_VALUE(0,DE_DIMENSION,X,width)|
-			FIELD_VALUE(0,DE_DIMENSION,Y_ET,height));//dpr8
-
-	deCtrl =
-		FIELD_SET(0,DE_CONTROL,STATUS,START)|
-		FIELD_SET(0,DE_CONTROL,COMMAND,BITBLT)|
-		FIELD_SET(0,DE_CONTROL,ROP2_SOURCE,PATTERN)|
-		FIELD_SET(0,DE_CONTROL,ROP_SELECT,ROP2)|
-		FIELD_VALUE(0,DE_CONTROL,ROP,rop);//dpr0xc
-#if 0
-		/* dump registers */
-		int i;
-		inf_msg("x,y,w,h = %d,%d,%d,%d\n",x,y,width,height);
-		for(i=0x04;i<=0x44;i+=4){
-			inf_msg("dpr%02x = %08x\n",i,read_dpr(accel,i));
-		}
-		inf_msg("deCtrl = %08x\n",deCtrl);
-#endif
-
-	write_dpr(accel,DE_CONTROL,deCtrl);
-	return 0;
-}
-
 int hw_fillrect(struct lynx_accel * accel,
 				u32 base,u32 pitch,u32 Bpp,
 				u32 x,u32 y,u32 width,u32 height,
--
2.3.2

[PATCH RESEND 2 3/5] staging: sm750fb: Remove unused function

[Lorenzo Stoakes]

This patch removes the unused hw712_fillrect function. This patch fixes
the following sparse warning:-

drivers/staging/sm750fb/sm750_accel.c:95:5: warning: symbol 'hw712_fillrect' was not declared. Should it be static?

Signed-off-by: Lorenzo Stoakes <lstoakes@gmail.com>
---
 drivers/staging/sm750fb/sm750_accel.c | 78 -----------------------------------
 1 file changed, 78 deletions(-)

diff --git a/drivers/staging/sm750fb/sm750_accel.c b/drivers/staging/sm750fb/sm750_accel.c
index 6521c3b..c5a3726 100644
--- a/drivers/staging/sm750fb/sm750_accel.c
+++ b/drivers/staging/sm750fb/sm750_accel.c
@@ -89,84 +89,6 @@ void hw_set2dformat(struct lynx_accel * accel,int fmt)
 	write_dpr(accel,DE_STRETCH_FORMAT,reg);
 }

-/* seems sm712 RectFill command is broken,so need use BitBlt to
- * replace it. */
-
-int hw712_fillrect(struct lynx_accel * accel,
-				u32 base,u32 pitch,u32 Bpp,
-				u32 x,u32 y,u32 width,u32 height,
-				u32 color,u32 rop)
-{
-	u32 deCtrl;
-	if(accel->de_wait() != 0)
-	{
-		/* int time wait and always busy,seems hardware
-		 * got something error */
-		pr_debug("%s:De engine always bussy\n",__func__);
-		return -1;
-	}
-	/* 24bpp 2d acceleration still not work,we already support 2d on
-	 * both 8/16/32 bpp now, so there is no harm if we disable 2d on
-	 * 24bpp for current stage. */
-#if 0
-	if(Bpp = 3){
-		width *= 3;
-		x *= 3;
-		write_dpr(accel,DE_PITCH,
-			FIELD_VALUE(0,DE_PITCH,DESTINATION,pitch)|
-			FIELD_VALUE(0,DE_PITCH,SOURCE,pitch));//dpr10
-	}
-	else
-#endif
-	{
-		write_dpr(accel,DE_PITCH,
-			FIELD_VALUE(0,DE_PITCH,DESTINATION,pitch/Bpp)|
-			FIELD_VALUE(0,DE_PITCH,SOURCE,pitch/Bpp));//dpr10
-
-	}
-
-	write_dpr(accel,DE_FOREGROUND,color);//DPR14
-	write_dpr(accel,DE_MONO_PATTERN_HIGH,~0);//DPR34
-	write_dpr(accel,DE_MONO_PATTERN_LOW,~0);//DPR38
-
-	write_dpr(accel,DE_WINDOW_SOURCE_BASE,base);//dpr44
-	write_dpr(accel,DE_WINDOW_DESTINATION_BASE,base);//dpr40
-
-
-	write_dpr(accel,DE_WINDOW_WIDTH,
-			FIELD_VALUE(0,DE_WINDOW_WIDTH,DESTINATION,pitch/Bpp)|
-			FIELD_VALUE(0,DE_WINDOW_WIDTH,SOURCE,pitch/Bpp));//dpr3c
-
-
-	write_dpr(accel,DE_DESTINATION,
-			FIELD_SET(0,DE_DESTINATION,WRAP,DISABLE)|
-			FIELD_VALUE(0,DE_DESTINATION,X,x)|
-			FIELD_VALUE(0,DE_DESTINATION,Y,y));//dpr4
-
-	write_dpr(accel,DE_DIMENSION,
-			FIELD_VALUE(0,DE_DIMENSION,X,width)|
-			FIELD_VALUE(0,DE_DIMENSION,Y_ET,height));//dpr8
-
-	deCtrl -		FIELD_SET(0,DE_CONTROL,STATUS,START)|
-		FIELD_SET(0,DE_CONTROL,COMMAND,BITBLT)|
-		FIELD_SET(0,DE_CONTROL,ROP2_SOURCE,PATTERN)|
-		FIELD_SET(0,DE_CONTROL,ROP_SELECT,ROP2)|
-		FIELD_VALUE(0,DE_CONTROL,ROP,rop);//dpr0xc
-#if 0
-		/* dump registers */
-		int i;
-		inf_msg("x,y,w,h = %d,%d,%d,%d\n",x,y,width,height);
-		for(i=0x04;i<=0x44;i+=4){
-			inf_msg("dpr%02x = %08x\n",i,read_dpr(accel,i));
-		}
-		inf_msg("deCtrl = %08x\n",deCtrl);
-#endif
-
-	write_dpr(accel,DE_CONTROL,deCtrl);
-	return 0;
-}
-
 int hw_fillrect(struct lynx_accel * accel,
 				u32 base,u32 pitch,u32 Bpp,
 				u32 x,u32 y,u32 width,u32 height,
--
2.3.2

[PATCH RESEND 2 4/5] staging: sm750fb: Fix __iomem pointer types

[Lorenzo Stoakes]

This patch annotates pointers as referring to I/O mapped memory where they ought
to be, removes now unnecessary ugly casts, eliminates an incorrect deref on I/O
mapped memory by using iowrite16 instead, and updates the pointer arithmetic
accordingly to take into account that the pointers are now byte-sized. This
fixes the following sparse warnings:-

drivers/staging/sm750fb/sm750_cursor.c:113:19: warning: cast removes address space of expression
drivers/staging/sm750fb/sm750_cursor.c:204:19: warning: cast removes address space of expression

Signed-off-by: Lorenzo Stoakes <lstoakes@gmail.com>
---

 drivers/staging/sm750fb/sm750_cursor.c | 24 ++++++++++++------------
 1 file changed, 12 insertions(+), 12 deletions(-)

diff --git a/drivers/staging/sm750fb/sm750_cursor.c b/drivers/staging/sm750fb/sm750_cursor.c
index 6cceef1..c2ff3bd 100644
--- a/drivers/staging/sm750fb/sm750_cursor.c
+++ b/drivers/staging/sm750fb/sm750_cursor.c
@@ -98,7 +98,7 @@ void hw_cursor_setData(struct lynx_cursor * cursor,
 	int i,j,count,pitch,offset;
 	u8 color,mask,opr;
 	u16 data;
-	u16 * pbuffer,*pstart;
+	void __iomem *pbuffer, *pstart;

 	/*  in byte*/
 	pitch = cursor->w >> 3;
@@ -106,11 +106,11 @@ void hw_cursor_setData(struct lynx_cursor * cursor,
 	/* in byte	*/
 	count = pitch * cursor->h;

-	/* in ushort */
-	offset = cursor->maxW * 2 / 8 / 2;
+	/* in byte */
+	offset = cursor->maxW * 2 / 8;

 	data = 0;
-	pstart = (u16 *)cursor->vstart;
+	pstart = cursor->vstart;
 	pbuffer = pstart;

 /*
@@ -161,7 +161,7 @@ void hw_cursor_setData(struct lynx_cursor * cursor,
 			}
 		}
 #endif
-		*pbuffer = data;
+		iowrite16(data, pbuffer);

 		/* assume pitch is 1,2,4,8,...*/
 #if 0
@@ -174,7 +174,7 @@ void hw_cursor_setData(struct lynx_cursor * cursor,
 			pstart += offset;
 			pbuffer = pstart;
 		}else{
-			pbuffer++;
+			pbuffer += sizeof(u16);
 		}

 	}
@@ -189,7 +189,7 @@ void hw_cursor_setData2(struct lynx_cursor * cursor,
 	int i,j,count,pitch,offset;
 	u8 color, mask;
 	u16 data;
-	u16 * pbuffer,*pstart;
+	void __iomem *pbuffer, *pstart;

 	/*  in byte*/
 	pitch = cursor->w >> 3;
@@ -197,11 +197,11 @@ void hw_cursor_setData2(struct lynx_cursor * cursor,
 	/* in byte	*/
 	count = pitch * cursor->h;

-	/* in ushort */
-	offset = cursor->maxW * 2 / 8 / 2;
+	/* in byte */
+	offset = cursor->maxW * 2 / 8;

 	data = 0;
-	pstart = (u16 *)cursor->vstart;
+	pstart = cursor->vstart;
 	pbuffer = pstart;

 	for(i=0;i<count;i++)
@@ -234,7 +234,7 @@ void hw_cursor_setData2(struct lynx_cursor * cursor,
 				data |= ((color & (1<<j))?1:2)<<(j*2);
 		}
 #endif
-		*pbuffer = data;
+		iowrite16(data, pbuffer);

 		/* assume pitch is 1,2,4,8,...*/
 		if(!(i&(pitch-1)))
@@ -244,7 +244,7 @@ void hw_cursor_setData2(struct lynx_cursor * cursor,
 			pstart += offset;
 			pbuffer = pstart;
 		}else{
-			pbuffer++;
+			pbuffer += sizeof(u16);
 		}

 	}
--
2.3.2

[PATCH RESEND 2 5/5] staging: sm750fb: Remove spinlock helper function

[Lorenzo Stoakes]

This patch removes the unnecessary spinlock helper function and instead
calls spin_lock and spin_unlock directly.

This does *not* resolve sparse warnings about context imbalances but these are
spurious.

Signed-off-by: Lorenzo Stoakes <lstoakes@gmail.com>
---
 drivers/staging/sm750fb/sm750.c | 53 +++++++++++++++++++++++------------------
 1 file changed, 30 insertions(+), 23 deletions(-)

diff --git a/drivers/staging/sm750fb/sm750.c b/drivers/staging/sm750fb/sm750.c
index be35429..a6658e1 100644
--- a/drivers/staging/sm750fb/sm750.c
+++ b/drivers/staging/sm750fb/sm750.c
@@ -56,23 +56,6 @@ static char * g_settings = NULL;
 static int g_dualview;
 static char * g_option = NULL;

-/* if not use spin_lock,system will die if user load driver
- * and immediatly unload driver frequently (dual)*/
-static inline void myspin_lock(spinlock_t * sl){
-	struct lynx_share * share;
-	share = container_of(sl,struct lynx_share,slock);
-	if(share->dual){
-		spin_lock(sl);
-	}
-}
-
-static inline void myspin_unlock(spinlock_t * sl){
-	struct lynx_share * share;
-	share = container_of(sl,struct lynx_share,slock);
-	if(share->dual){
-		spin_unlock(sl);
-	}
-}
 static const struct fb_videomode lynx750_ext[] = {
 	/*  	1024x600-60 VESA 	[1.71:1]	*/
 	{NULL,  60, 1024, 600, 20423, 144,  40, 18, 1, 104, 3,
@@ -209,13 +192,21 @@ static void lynxfb_ops_fillrect(struct fb_info* info,const struct fb_fillrect* r
 	color = (Bpp == 1)?region->color:((u32*)info->pseudo_palette)[region->color];
 	rop = ( region->rop != ROP_COPY ) ? HW_ROP2_XOR:HW_ROP2_COPY;

-	myspin_lock(&share->slock);
+	/*
+	 * If not use spin_lock,system will die if user load driver
+	 * and immediatly unload driver frequently (dual)
+	 */
+	if (share->dual)
+		spin_lock(&share->slock);
+
 	share->accel.de_fillrect(&share->accel,
 							base,pitch,Bpp,
 							region->dx,region->dy,
 							region->width,region->height,
 							color,rop);
-	myspin_unlock(&share->slock);
+
+	if (share->dual)
+		spin_unlock(&share->slock);
 }

 static void lynxfb_ops_copyarea(struct fb_info * info,const struct fb_copyarea * region)
@@ -233,12 +224,20 @@ static void lynxfb_ops_copyarea(struct fb_info * info,const struct fb_copyarea *
 	pitch = info->fix.line_length;
 	Bpp = info->var.bits_per_pixel >> 3;

-	myspin_lock(&share->slock);
+	/*
+	 * If not use spin_lock, system will die if user load driver
+	 * and immediatly unload driver frequently (dual)
+	 */
+	if (share->dual)
+		spin_lock(&share->slock);
+
 	share->accel.de_copyarea(&share->accel,
 							base,pitch,region->sx,region->sy,
 							base,pitch,Bpp,region->dx,region->dy,
 							region->width,region->height,HW_ROP2_COPY);
-	myspin_unlock(&share->slock);
+
+	if (share->dual)
+		spin_unlock(&share->slock);
 }

 static void lynxfb_ops_imageblit(struct fb_info*info,const struct fb_image* image)
@@ -272,14 +271,22 @@ static void lynxfb_ops_imageblit(struct fb_info*info,const struct fb_image* imag
 	}
 	return;
 _do_work:
-	myspin_lock(&share->slock);
+	/*
+	 * If not use spin_lock, system will die if user load driver
+	 * and immediatly unload driver frequently (dual)
+	 */
+	if (share->dual)
+		spin_lock(&share->slock);
+
 	share->accel.de_imageblit(&share->accel,
 					image->data,image->width>>3,0,
 					base,pitch,Bpp,
 					image->dx,image->dy,
 					image->width,image->height,
 					fgcol,bgcol,HW_ROP2_COPY);
-	myspin_unlock(&share->slock);
+
+	if (share->dual)
+		spin_unlock(&share->slock);
 }

 static int lynxfb_ops_pan_display(struct fb_var_screeninfo *var,
--
2.3.3

[PATCH RESEND 2 5/5] staging: sm750fb: Remove spinlock helper function

[Lorenzo Stoakes]

This patch removes the unnecessary spinlock helper function and instead
calls spin_lock and spin_unlock directly.

This does *not* resolve sparse warnings about context imbalances but these are
spurious.

Signed-off-by: Lorenzo Stoakes <lstoakes@gmail.com>
---
 drivers/staging/sm750fb/sm750.c | 53 +++++++++++++++++++++++------------------
 1 file changed, 30 insertions(+), 23 deletions(-)

diff --git a/drivers/staging/sm750fb/sm750.c b/drivers/staging/sm750fb/sm750.c
index be35429..a6658e1 100644
--- a/drivers/staging/sm750fb/sm750.c
+++ b/drivers/staging/sm750fb/sm750.c
@@ -56,23 +56,6 @@ static char * g_settings = NULL;
 static int g_dualview;
 static char * g_option = NULL;

-/* if not use spin_lock,system will die if user load driver
- * and immediatly unload driver frequently (dual)*/
-static inline void myspin_lock(spinlock_t * sl){
-	struct lynx_share * share;
-	share = container_of(sl,struct lynx_share,slock);
-	if(share->dual){
-		spin_lock(sl);
-	}
-}
-
-static inline void myspin_unlock(spinlock_t * sl){
-	struct lynx_share * share;
-	share = container_of(sl,struct lynx_share,slock);
-	if(share->dual){
-		spin_unlock(sl);
-	}
-}
 static const struct fb_videomode lynx750_ext[] = {
 	/*  	1024x600-60 VESA 	[1.71:1]	*/
 	{NULL,  60, 1024, 600, 20423, 144,  40, 18, 1, 104, 3,
@@ -209,13 +192,21 @@ static void lynxfb_ops_fillrect(struct fb_info* info,const struct fb_fillrect* r
 	color = (Bpp = 1)?region->color:((u32*)info->pseudo_palette)[region->color];
 	rop = ( region->rop != ROP_COPY ) ? HW_ROP2_XOR:HW_ROP2_COPY;

-	myspin_lock(&share->slock);
+	/*
+	 * If not use spin_lock,system will die if user load driver
+	 * and immediatly unload driver frequently (dual)
+	 */
+	if (share->dual)
+		spin_lock(&share->slock);
+
 	share->accel.de_fillrect(&share->accel,
 							base,pitch,Bpp,
 							region->dx,region->dy,
 							region->width,region->height,
 							color,rop);
-	myspin_unlock(&share->slock);
+
+	if (share->dual)
+		spin_unlock(&share->slock);
 }

 static void lynxfb_ops_copyarea(struct fb_info * info,const struct fb_copyarea * region)
@@ -233,12 +224,20 @@ static void lynxfb_ops_copyarea(struct fb_info * info,const struct fb_copyarea *
 	pitch = info->fix.line_length;
 	Bpp = info->var.bits_per_pixel >> 3;

-	myspin_lock(&share->slock);
+	/*
+	 * If not use spin_lock, system will die if user load driver
+	 * and immediatly unload driver frequently (dual)
+	 */
+	if (share->dual)
+		spin_lock(&share->slock);
+
 	share->accel.de_copyarea(&share->accel,
 							base,pitch,region->sx,region->sy,
 							base,pitch,Bpp,region->dx,region->dy,
 							region->width,region->height,HW_ROP2_COPY);
-	myspin_unlock(&share->slock);
+
+	if (share->dual)
+		spin_unlock(&share->slock);
 }

 static void lynxfb_ops_imageblit(struct fb_info*info,const struct fb_image* image)
@@ -272,14 +271,22 @@ static void lynxfb_ops_imageblit(struct fb_info*info,const struct fb_image* imag
 	}
 	return;
 _do_work:
-	myspin_lock(&share->slock);
+	/*
+	 * If not use spin_lock, system will die if user load driver
+	 * and immediatly unload driver frequently (dual)
+	 */
+	if (share->dual)
+		spin_lock(&share->slock);
+
 	share->accel.de_imageblit(&share->accel,
 					image->data,image->width>>3,0,
 					base,pitch,Bpp,
 					image->dx,image->dy,
 					image->width,image->height,
 					fgcol,bgcol,HW_ROP2_COPY);
-	myspin_unlock(&share->slock);
+
+	if (share->dual)
+		spin_unlock(&share->slock);
 }

 static int lynxfb_ops_pan_display(struct fb_var_screeninfo *var,
--
2.3.3

Re: [PATCH RESEND 2 1/5] staging: sm750fb: Use memset_io instead of memset

[Dan Carpenter]

Sorry I wasn't clear on this before.  Please, stop putting RESEND in the
subject.  That's only for if you think we are screwing up or ignoring
you.  Just put v2, and put what changed under the --- cut off.
---
v2: changed the commit message

https://www.google.com/#q=how+to+send+a+v2+patch

Otherwise this set looks ok.  Thanks!

Reviewed-by: Dan Carpenter <dan.carpenter@oracle.com>

regards,
dan carpenter

Re: [PATCH RESEND 2 1/5] staging: sm750fb: Use memset_io instead of memset

[Dan Carpenter]

Sorry I wasn't clear on this before.  Please, stop putting RESEND in the
subject.  That's only for if you think we are screwing up or ignoring
you.  Just put v2, and put what changed under the --- cut off.
---
v2: changed the commit message

https://www.google.com/#q=how+to+send+a+v2+patch

Otherwise this set looks ok.  Thanks!

Reviewed-by: Dan Carpenter <dan.carpenter@oracle.com>

regards,
dan carpenter

Re: [PATCH RESEND 2 1/5] staging: sm750fb: Use memset_io instead of memset

[Lorenzo Stoakes]

On 23 March 2015 at 10:53, Dan Carpenter <dan.carpenter@oracle.com> wrote:
> Sorry I wasn't clear on this before.  Please, stop putting RESEND in the
> subject.  That's only for if you think we are screwing up or ignoring
> you.  Just put v2, and put what changed under the --- cut off.
> ---
> v2: changed the commit message
>
> https://www.google.com/#q=how+to+send+a+v2+patch
>

I have to say I'm quite massively confused on this :) and the linux
newbies link at the top of the results for that google search doesn't
seem to clear it up for me. May I be so cheeky as to ask you to help
me understand so I can do this better in future?:-

* Greg has asked me to send again because it wasn't clear which set
was applicable. This is why I appended RESEND 2 (the original RESEND
was the same deal but *also* containing fixups to apply to the latest
staging-testing) since I wasn't changing anything, just resending to
make clear which patch set is valid right now. In this case should I
simply append a version number to each patch in the series and resend?
* Which leads on to the next point of confusion - previously when I
changed *one* patch in a series then resent *all* patches in that
series with v2, I had complaints that 'this patch hasn't changed' on
the unchanged patches, leading me to think that you should only resend
patches that have actually changed (which fits the pattern of putting
a change message under the '---' - though of course you could say v2:
resend patchset or similar) - however this seems to be what causes the
confusion that leads to needing a resend in the first instance (maybe
a problem with options I'm passing to git send-email, perhaps I need
to use in-reply-to to make the v2's replies to the v1's.)
* If the former point is correct and I should only resend patches that
have actually changed, but I'm asked for a resend - what is the
correct course of action? And of course we end up with some patches at
v>1, some at v1, so should all patches then be updated to v(MAX(v)+1)?

> Otherwise this set looks ok.  Thanks!
>
> Reviewed-by: Dan Carpenter <dan.carpenter@oracle.com>
>

Thanks for that, appreciated!

Best,

-- 
Lorenzo Stoakes
https:/ljs.io

Re: [PATCH RESEND 2 1/5] staging: sm750fb: Use memset_io instead of memset

[Dan Carpenter]

Oh hm...  This is an actual RESEND patch.

RESEND is a flag to show a mess up in the system.  I like to take a look
at those to see what went wrong.  The process failure was that you
messed up the threading earlier.  Take a look at the --in-reply-to flag.

regards,
dan carpenter

Re: [PATCH RESEND 2 1/5] staging: sm750fb: Use memset_io instead of memset

[Dan Carpenter]

Oh hm...  This is an actual RESEND patch.

RESEND is a flag to show a mess up in the system.  I like to take a look
at those to see what went wrong.  The process failure was that you
messed up the threading earlier.  Take a look at the --in-reply-to flag.

regards,
dan carpenter

Re: [PATCH RESEND 2 1/5] staging: sm750fb: Use memset_io instead of memset

[Lorenzo Stoakes]

On 23 March 2015 at 11:51, Dan Carpenter <dan.carpenter@oracle.com> wrote:
> Oh hm...  This is an actual RESEND patch.
>
> RESEND is a flag to show a mess up in the system.  I like to take a look
> at those to see what went wrong.  The process failure was that you
> messed up the threading earlier.  Take a look at the --in-reply-to flag.

Will do, apologies for the mess up, it makes sense that the v2's
should be replies to their respective v1s.

Best,

-- 
Lorenzo Stoakes
https:/ljs.io

Re: [PATCH RESEND 2 1/5] staging: sm750fb: Use memset_io instead of memset

[Sudip Mukherjee]

On Mon, Mar 23, 2015 at 12:43:28PM +0000, Lorenzo Stoakes wrote:
> On 23 March 2015 at 11:51, Dan Carpenter <dan.carpenter@oracle.com> wrote:
> > Oh hm...  This is an actual RESEND patch.
> >
> > RESEND is a flag to show a mess up in the system.  I like to take a look
> > at those to see what went wrong.  The process failure was that you
> > messed up the threading earlier.  Take a look at the --in-reply-to flag.
> 
> Will do, apologies for the mess up, it makes sense that the v2's
> should be replies to their respective v1s.

and you need to send v3 now :( 
your series is not applying. Please refresh it against staging-testing

regards
sudip
> 
> Best,
> 
> -- 
> Lorenzo Stoakes
> https:/ljs.io

Re: [PATCH RESEND 2 1/5] staging: sm750fb: Use memset_io instead of memset

[Sudip Mukherjee]

On Mon, Mar 23, 2015 at 12:43:28PM +0000, Lorenzo Stoakes wrote:
> On 23 March 2015 at 11:51, Dan Carpenter <dan.carpenter@oracle.com> wrote:
> > Oh hm...  This is an actual RESEND patch.
> >
> > RESEND is a flag to show a mess up in the system.  I like to take a look
> > at those to see what went wrong.  The process failure was that you
> > messed up the threading earlier.  Take a look at the --in-reply-to flag.
> 
> Will do, apologies for the mess up, it makes sense that the v2's
> should be replies to their respective v1s.

and you need to send v3 now :( 
your series is not applying. Please refresh it against staging-testing

regards
sudip
> 
> Best,
> 
> -- 
> Lorenzo Stoakes
> https:/ljs.io

Re: [PATCH RESEND 2 1/5] staging: sm750fb: Use memset_io instead of memset

[Lorenzo Stoakes]

On 23 March 2015 at 12:55, Sudip Mukherjee <sudipm.mukherjee@gmail.com> wrote:

> and you need to send v3 now :(
> your series is not applying. Please refresh it against staging-testing

Applies to staging-testing for me. Are you sure you're applying the
correct 'RESEND 2' patches?

-- 
Lorenzo Stoakes
https:/ljs.io

Re: [PATCH RESEND 2 1/5] staging: sm750fb: Use memset_io instead of memset

[Sudip Mukherjee]

On Mon, Mar 23, 2015 at 01:02:52PM +0000, Lorenzo Stoakes wrote:
> On 23 March 2015 at 12:55, Sudip Mukherjee <sudipm.mukherjee@gmail.com> wrote:
> 
> > and you need to send v3 now :(
> > your series is not applying. Please refresh it against staging-testing
> 
> Applies to staging-testing for me. Are you sure you're applying the
> correct 'RESEND 2' patches?
i think. if you do git log drivers/staging/sm750fb/
are you getting the first patch author as
Ragavendra Nagraj <ragavendra.bn@gmail.com> ?

regards
sudip

> 
> -- 
> Lorenzo Stoakes
> https:/ljs.io

Re: [PATCH RESEND 2 1/5] staging: sm750fb: Use memset_io instead of memset

[Lorenzo Stoakes]

On 23 March 2015 at 13:14, Sudip Mukherjee <sudipm.mukherjee@gmail.com> wrote:
> On Mon, Mar 23, 2015 at 01:02:52PM +0000, Lorenzo Stoakes wrote:
>> On 23 March 2015 at 12:55, Sudip Mukherjee <sudipm.mukherjee@gmail.com> wrote:
>>
>> > and you need to send v3 now :(
>> > your series is not applying. Please refresh it against staging-testing
>>
>> Applies to staging-testing for me. Are you sure you're applying the
>> correct 'RESEND 2' patches?
> i think. if you do git log drivers/staging/sm750fb/
> are you getting the first patch author as
> Ragavendra Nagraj <ragavendra.bn@gmail.com> ?

Yep:-

commit de99befd18c10d8085182a1facbb4b8760b2b6fe
Author: Ragavendra Nagraj <ragavendra.bn@gmail.com>
Date:   Wed Mar 18 02:37:42 2015 -0700

    staging: sm750fb: Fixed no space and indent warns

I've tried applying resend 2 patches to both linux-next and
staging-testing in Greg's staging.git tree, they apply in both places.

-- 
Lorenzo Stoakes
https:/ljs.io

Re: [PATCH RESEND 2 1/5] staging: sm750fb: Use memset_io instead of memset

[Lorenzo Stoakes]

On 23 March 2015 at 13:16, Lorenzo Stoakes <lstoakes@gmail.com> wrote:
> I've tried applying resend 2 patches to both linux-next and
> staging-testing in Greg's staging.git tree, they apply in both places.

Sigh. Checking the emails I actually sent, I seem to *somehow* have
sent old files in this resend :S I really don't know how this
happened. My copies of the patches all apply perfectly correctly, but
these are not the ones I sent.

I'll bump versions using the correct --in-reply-to to fix this. Apologies again!

Best,

-- 
Lorenzo Stoakes
https:/ljs.io

Re: [PATCH RESEND 2 1/5] staging: sm750fb: Use memset_io instead of memset

[Lorenzo Stoakes]

On 23 March 2015 at 13:21, Lorenzo Stoakes <lstoakes@gmail.com> wrote:
> Sigh. Checking the emails I actually sent, I seem to *somehow* have
> sent old files in this resend :S I really don't know how this
> happened. My copies of the patches all apply perfectly correctly, but
> these are not the ones I sent.

And just to add to my embarrassment, this is actually *not* the case,
they DO all apply, gmail mangled the patches. So they seem fine after
all!

Sudip - could you try to carefully grab each of the 5 patches with
[RESEND 2] in the subject to make sure you are applying them
correctly?

Best,

-- 
Lorenzo Stoakes
https:/ljs.io

Re: [PATCH RESEND 2 1/5] staging: sm750fb: Use memset_io instead of memset

[Sudip Mukherjee]

On Mon, Mar 23, 2015 at 01:02:52PM +0000, Lorenzo Stoakes wrote:
> On 23 March 2015 at 12:55, Sudip Mukherjee <sudipm.mukherjee@gmail.com> wrote:
> 
> > and you need to send v3 now :(
> > your series is not applying. Please refresh it against staging-testing
> 
> Applies to staging-testing for me. Are you sure you're applying the
> correct 'RESEND 2' patches?
i think. if you do git log drivers/staging/sm750fb/
are you getting the first patch author as
Ragavendra Nagraj <ragavendra.bn@gmail.com> ?

regards
sudip

> 
> -- 
> Lorenzo Stoakes
> https:/ljs.io

Re: [PATCH RESEND 2 1/5] staging: sm750fb: Use memset_io instead of memset

[Sudip Mukherjee]

On Mon, Mar 23, 2015 at 01:25:37PM +0000, Lorenzo Stoakes wrote:
> On 23 March 2015 at 13:21, Lorenzo Stoakes <lstoakes@gmail.com> wrote:
> > Sigh. Checking the emails I actually sent, I seem to *somehow* have
> > sent old files in this resend :S I really don't know how this
> > happened. My copies of the patches all apply perfectly correctly, but
> > these are not the ones I sent.
> 
> And just to add to my embarrassment, this is actually *not* the case,
> they DO all apply, gmail mangled the patches. So they seem fine after
> all!
> 
> Sudip - could you try to carefully grab each of the 5 patches with
> [RESEND 2] in the subject to make sure you are applying them
> correctly?
my apologies. they are applying properly. i had them already applied
for testing that hardware change, and again i tried to apply them.
sorry for the confusion. :(

regards
sudip
> 
> Best,
> 
> -- 
> Lorenzo Stoakes
> https:/ljs.io

Re: [PATCH RESEND 2 1/5] staging: sm750fb: Use memset_io instead of memset

[Sudip Mukherjee]

On Mon, Mar 23, 2015 at 01:25:37PM +0000, Lorenzo Stoakes wrote:
> On 23 March 2015 at 13:21, Lorenzo Stoakes <lstoakes@gmail.com> wrote:
> > Sigh. Checking the emails I actually sent, I seem to *somehow* have
> > sent old files in this resend :S I really don't know how this
> > happened. My copies of the patches all apply perfectly correctly, but
> > these are not the ones I sent.
> 
> And just to add to my embarrassment, this is actually *not* the case,
> they DO all apply, gmail mangled the patches. So they seem fine after
> all!
> 
> Sudip - could you try to carefully grab each of the 5 patches with
> [RESEND 2] in the subject to make sure you are applying them
> correctly?
my apologies. they are applying properly. i had them already applied
for testing that hardware change, and again i tried to apply them.
sorry for the confusion. :(

regards
sudip
> 
> Best,
> 
> -- 
> Lorenzo Stoakes
> https:/ljs.io

Re: [PATCH RESEND 2 1/5] staging: sm750fb: Use memset_io instead of memset

[Sudip Mukherjee]

On Fri, Mar 20, 2015 at 03:22:11PM +0000, Lorenzo Stoakes wrote:
> This patch takes into account that cursor->vstart, crtc->vScreen and
> share->pvMem are pointers to memory-mapped I/O and thus we should use memset_io
> to make this explicit. In addition, some architectures require special treatment
> of memory-mapped I/O so the previous code could actually break without this
> change.
sorry for the confusion.
tested the whole series on hardware.

Tested-by: Sudip Mukherjee <sudip@vectorindia.org>

sudip

Re: [PATCH RESEND 2 1/5] staging: sm750fb: Use memset_io instead of memset

[Sudip Mukherjee]

On Fri, Mar 20, 2015 at 03:22:11PM +0000, Lorenzo Stoakes wrote:
> This patch takes into account that cursor->vstart, crtc->vScreen and
> share->pvMem are pointers to memory-mapped I/O and thus we should use memset_io
> to make this explicit. In addition, some architectures require special treatment
> of memory-mapped I/O so the previous code could actually break without this
> change.
sorry for the confusion.
tested the whole series on hardware.

Tested-by: Sudip Mukherjee <sudip@vectorindia.org>

sudip