All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ben Dooks <ben@simtec.co.uk>
To: linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH v3 05/12] s3c-fb: Add support for display panning
Date: Fri, 02 Jul 2010 11:24:11 +0000	[thread overview]
Message-ID: <4C2DCC5B.2000100@simtec.co.uk> (raw)
In-Reply-To: <1277712538-23188-6-git-send-email-p.osciak@samsung.com>

On 28/06/10 09:08, Pawel Osciak wrote:
> Supports all bpp modes.
> 
> The PRTCON register is used to disable in-hardware updates of registers
> that store start and end addresses of framebuffer memory. This prevents
> display corruption in case we do not make it before VSYNC with updating
> them atomically. With this feature there is no need to wait for a VSYNC
> interrupt before each such update.
> 
> Signed-off-by: Pawel Osciak <p.osciak@samsung.com>
> Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
> ---
>  arch/arm/plat-samsung/include/plat/regs-fb.h |    5 ++
>  drivers/video/s3c-fb.c                       |   71 ++++++++++++++++++++++++++
>  2 files changed, 76 insertions(+), 0 deletions(-)
> 
> diff --git a/arch/arm/plat-samsung/include/plat/regs-fb.h b/arch/arm/plat-samsung/include/plat/regs-fb.h
> index ac10013..f454e32 100644
> --- a/arch/arm/plat-samsung/include/plat/regs-fb.h
> +++ b/arch/arm/plat-samsung/include/plat/regs-fb.h
> @@ -112,6 +112,11 @@
>  #define VIDCON2_ORGYCbCr			(1 << 8)
>  #define VIDCON2_YUVORDCrCb			(1 << 7)
>  
> +/* PRTCON (S3C6410, S5PC100) */

Not listed in my S3C6410 manual?

> +#define PRTCON					(0x0c)
> +#define PRTCON_PROTECT				(1 << 11)
> +
>  /* VIDTCON0 */
>  
>  #define VIDTCON0_VBPDE_MASK			(0xff << 24)
> diff --git a/drivers/video/s3c-fb.c b/drivers/video/s3c-fb.c
> index 59ac76a..4f3680d 100644
> --- a/drivers/video/s3c-fb.c
> +++ b/drivers/video/s3c-fb.c
> @@ -71,6 +71,7 @@ struct s3c_fb;
>   * @buf_end: Offset of buffer end registers.
>   * @osd: The base for the OSD registers.
>   * @palette: Address of palette memory, or 0 if none.
> + * @has_prtcon: Set if has PRTCON register.
>   */
>  struct s3c_fb_variant {
>  	unsigned int	is_2443:1;
> @@ -85,6 +86,8 @@ struct s3c_fb_variant {
>  	unsigned short	osd;
>  	unsigned short	osd_stride;
>  	unsigned short	palette[S3C_FB_MAX_WIN];
> +
> +	unsigned int	has_prtcon:1;
>  };
>  
>  /**
> @@ -379,6 +382,9 @@ static int s3c_fb_set_par(struct fb_info *info)
>  
>  	info->fix.line_length = (var->xres_virtual * var->bits_per_pixel) / 8;
>  
> +	info->fix.xpanstep = info->var.xres_virtual > info->var.xres ? 1 : 0;
> +	info->fix.ypanstep = info->var.yres_virtual > info->var.yres ? 1 : 0;
> +
>  	/* disable the window whilst we update it */
>  	writel(0, regs + WINCON(win_no));
>  
> @@ -735,6 +741,66 @@ static int s3c_fb_blank(int blank_mode, struct fb_info *info)
>  	return 0;
>  }
>  
> +/**
> + * s3c_fb_pan_display() - Pan the display.
> + *
> + * Note that the offsets can be written to the device at any time, as their
> + * values are latched at each vsync automatically. This also means that only
> + * the last call to this function will have any effect on next vsync, but
> + * there is no need to sleep waiting for it to prevent tearing.
> + *
> + * @var: The screen information to verify.
> + * @info: The framebuffer device.
> + */
> +static int s3c_fb_pan_display(struct fb_var_screeninfo *var,
> +			      struct fb_info *info)
> +{
> +	struct s3c_fb_win *win	= info->par;
> +	struct s3c_fb *sfb	= win->parent;
> +	void __iomem *buf	= sfb->regs + win->index * 8;
> +	unsigned int start_byte_offset, end_byte_offset;

could have shortened to start and end, might have made some of the
calculation easier.

> +	/* Offset in bytes to the start of the displayed area */
> +	start_byte_offset = var->yoffset * info->fix.line_length;
> +	/* X offset depends on the current bpp */
> +	if (info->var.bits_per_pixel >= 8) {
> +		start_byte_offset +> +			var->xoffset * (info->var.bits_per_pixel >> 3);
> +	} else {
> +		switch (info->var.bits_per_pixel) {
> +		case 4:
> +			start_byte_offset += var->xoffset >> 1;
> +			break;
> +		case 2:
> +			start_byte_offset += var->xoffset >> 2;
> +			break;
> +		case 1:
> +			start_byte_offset += var->xoffset >> 3;
> +			break;
> +		default:
> +			dev_err(sfb->dev, "invalid bpp\n");
> +			return -EINVAL;
> +		}
> +	}

this could have been done by changing it to
start_byte_offset += var->xoffset / (8 / info->var.bits_per_pixel);

note, you always set pan step to 1, evne if the case of bpp less than 8.

> +	/* Offset in bytes to the end of the displayed area */
> +	end_byte_offset = start_byte_offset + var->yres * info->fix.line_length;
> +
> +	/* Temporarily turn off per-vsync update from shadow registers until
> +	 * both start and end addresses are updated to prevent corruption */
> +	if (sfb->variant.has_prtcon)
> +		writel(PRTCON_PROTECT, sfb->regs + PRTCON);
> +
> +	writel(info->fix.smem_start + start_byte_offset,
> +		buf + sfb->variant.buf_start);
> +	writel(info->fix.smem_start + end_byte_offset,
> +		buf + sfb->variant.buf_end);
> +
> +	if (sfb->variant.has_prtcon)
> +		writel(0, sfb->regs + PRTCON);
> +
> +	return 0;
> +}
> +
>  static struct fb_ops s3c_fb_ops = {
>  	.owner		= THIS_MODULE,
>  	.fb_check_var	= s3c_fb_check_var,
> @@ -744,6 +810,7 @@ static struct fb_ops s3c_fb_ops = {
>  	.fb_fillrect	= cfb_fillrect,
>  	.fb_copyarea	= cfb_copyarea,
>  	.fb_imageblit	= cfb_imageblit,
> +	.fb_pan_display	= s3c_fb_pan_display,
>  };
>  
>  /**
> @@ -1243,6 +1310,8 @@ static struct s3c_fb_driverdata s3c_fb_data_64xx __devinitdata = {
>  			[3] = 0x320,
>  			[4] = 0x340,
>  		},
> +
> +		.has_prtcon	= 1,
>  	},
>  	.win[0]	= &s3c_fb_data_64xx_wins[0],
>  	.win[1]	= &s3c_fb_data_64xx_wins[1],
> @@ -1271,6 +1340,8 @@ static struct s3c_fb_driverdata s3c_fb_data_s5pc100 __devinitdata = {
>  			[3] = 0x3000,
>  			[4] = 0x3400,
>  		},
> +
> +		.has_prtcon	= 1,
>  	},
>  	.win[0]	= &s3c_fb_data_64xx_wins[0],
>  	.win[1]	= &s3c_fb_data_64xx_wins[1],


WARNING: multiple messages have this Message-ID (diff)
From: Ben Dooks <ben@simtec.co.uk>
To: Pawel Osciak <p.osciak@samsung.com>
Cc: linux-fbdev@vger.kernel.org, linux-samsung-soc@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org, kyungmin.park@samsung.com,
	ben-linux@fluff.org, m.szyprowski@samsung.com
Subject: Re: [PATCH v3 05/12] s3c-fb: Add support for display panning
Date: Fri, 02 Jul 2010 12:24:11 +0100	[thread overview]
Message-ID: <4C2DCC5B.2000100@simtec.co.uk> (raw)
In-Reply-To: <1277712538-23188-6-git-send-email-p.osciak@samsung.com>

On 28/06/10 09:08, Pawel Osciak wrote:
> Supports all bpp modes.
> 
> The PRTCON register is used to disable in-hardware updates of registers
> that store start and end addresses of framebuffer memory. This prevents
> display corruption in case we do not make it before VSYNC with updating
> them atomically. With this feature there is no need to wait for a VSYNC
> interrupt before each such update.
> 
> Signed-off-by: Pawel Osciak <p.osciak@samsung.com>
> Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
> ---
>  arch/arm/plat-samsung/include/plat/regs-fb.h |    5 ++
>  drivers/video/s3c-fb.c                       |   71 ++++++++++++++++++++++++++
>  2 files changed, 76 insertions(+), 0 deletions(-)
> 
> diff --git a/arch/arm/plat-samsung/include/plat/regs-fb.h b/arch/arm/plat-samsung/include/plat/regs-fb.h
> index ac10013..f454e32 100644
> --- a/arch/arm/plat-samsung/include/plat/regs-fb.h
> +++ b/arch/arm/plat-samsung/include/plat/regs-fb.h
> @@ -112,6 +112,11 @@
>  #define VIDCON2_ORGYCbCr			(1 << 8)
>  #define VIDCON2_YUVORDCrCb			(1 << 7)
>  
> +/* PRTCON (S3C6410, S5PC100) */

Not listed in my S3C6410 manual?

> +#define PRTCON					(0x0c)
> +#define PRTCON_PROTECT				(1 << 11)
> +
>  /* VIDTCON0 */
>  
>  #define VIDTCON0_VBPDE_MASK			(0xff << 24)
> diff --git a/drivers/video/s3c-fb.c b/drivers/video/s3c-fb.c
> index 59ac76a..4f3680d 100644
> --- a/drivers/video/s3c-fb.c
> +++ b/drivers/video/s3c-fb.c
> @@ -71,6 +71,7 @@ struct s3c_fb;
>   * @buf_end: Offset of buffer end registers.
>   * @osd: The base for the OSD registers.
>   * @palette: Address of palette memory, or 0 if none.
> + * @has_prtcon: Set if has PRTCON register.
>   */
>  struct s3c_fb_variant {
>  	unsigned int	is_2443:1;
> @@ -85,6 +86,8 @@ struct s3c_fb_variant {
>  	unsigned short	osd;
>  	unsigned short	osd_stride;
>  	unsigned short	palette[S3C_FB_MAX_WIN];
> +
> +	unsigned int	has_prtcon:1;
>  };
>  
>  /**
> @@ -379,6 +382,9 @@ static int s3c_fb_set_par(struct fb_info *info)
>  
>  	info->fix.line_length = (var->xres_virtual * var->bits_per_pixel) / 8;
>  
> +	info->fix.xpanstep = info->var.xres_virtual > info->var.xres ? 1 : 0;
> +	info->fix.ypanstep = info->var.yres_virtual > info->var.yres ? 1 : 0;
> +
>  	/* disable the window whilst we update it */
>  	writel(0, regs + WINCON(win_no));
>  
> @@ -735,6 +741,66 @@ static int s3c_fb_blank(int blank_mode, struct fb_info *info)
>  	return 0;
>  }
>  
> +/**
> + * s3c_fb_pan_display() - Pan the display.
> + *
> + * Note that the offsets can be written to the device at any time, as their
> + * values are latched at each vsync automatically. This also means that only
> + * the last call to this function will have any effect on next vsync, but
> + * there is no need to sleep waiting for it to prevent tearing.
> + *
> + * @var: The screen information to verify.
> + * @info: The framebuffer device.
> + */
> +static int s3c_fb_pan_display(struct fb_var_screeninfo *var,
> +			      struct fb_info *info)
> +{
> +	struct s3c_fb_win *win	= info->par;
> +	struct s3c_fb *sfb	= win->parent;
> +	void __iomem *buf	= sfb->regs + win->index * 8;
> +	unsigned int start_byte_offset, end_byte_offset;

could have shortened to start and end, might have made some of the
calculation easier.

> +	/* Offset in bytes to the start of the displayed area */
> +	start_byte_offset = var->yoffset * info->fix.line_length;
> +	/* X offset depends on the current bpp */
> +	if (info->var.bits_per_pixel >= 8) {
> +		start_byte_offset +=
> +			var->xoffset * (info->var.bits_per_pixel >> 3);
> +	} else {
> +		switch (info->var.bits_per_pixel) {
> +		case 4:
> +			start_byte_offset += var->xoffset >> 1;
> +			break;
> +		case 2:
> +			start_byte_offset += var->xoffset >> 2;
> +			break;
> +		case 1:
> +			start_byte_offset += var->xoffset >> 3;
> +			break;
> +		default:
> +			dev_err(sfb->dev, "invalid bpp\n");
> +			return -EINVAL;
> +		}
> +	}

this could have been done by changing it to
start_byte_offset += var->xoffset / (8 / info->var.bits_per_pixel);

note, you always set pan step to 1, evne if the case of bpp less than 8.

> +	/* Offset in bytes to the end of the displayed area */
> +	end_byte_offset = start_byte_offset + var->yres * info->fix.line_length;
> +
> +	/* Temporarily turn off per-vsync update from shadow registers until
> +	 * both start and end addresses are updated to prevent corruption */
> +	if (sfb->variant.has_prtcon)
> +		writel(PRTCON_PROTECT, sfb->regs + PRTCON);
> +
> +	writel(info->fix.smem_start + start_byte_offset,
> +		buf + sfb->variant.buf_start);
> +	writel(info->fix.smem_start + end_byte_offset,
> +		buf + sfb->variant.buf_end);
> +
> +	if (sfb->variant.has_prtcon)
> +		writel(0, sfb->regs + PRTCON);
> +
> +	return 0;
> +}
> +
>  static struct fb_ops s3c_fb_ops = {
>  	.owner		= THIS_MODULE,
>  	.fb_check_var	= s3c_fb_check_var,
> @@ -744,6 +810,7 @@ static struct fb_ops s3c_fb_ops = {
>  	.fb_fillrect	= cfb_fillrect,
>  	.fb_copyarea	= cfb_copyarea,
>  	.fb_imageblit	= cfb_imageblit,
> +	.fb_pan_display	= s3c_fb_pan_display,
>  };
>  
>  /**
> @@ -1243,6 +1310,8 @@ static struct s3c_fb_driverdata s3c_fb_data_64xx __devinitdata = {
>  			[3] = 0x320,
>  			[4] = 0x340,
>  		},
> +
> +		.has_prtcon	= 1,
>  	},
>  	.win[0]	= &s3c_fb_data_64xx_wins[0],
>  	.win[1]	= &s3c_fb_data_64xx_wins[1],
> @@ -1271,6 +1340,8 @@ static struct s3c_fb_driverdata s3c_fb_data_s5pc100 __devinitdata = {
>  			[3] = 0x3000,
>  			[4] = 0x3400,
>  		},
> +
> +		.has_prtcon	= 1,
>  	},
>  	.win[0]	= &s3c_fb_data_64xx_wins[0],
>  	.win[1]	= &s3c_fb_data_64xx_wins[1],

WARNING: multiple messages have this Message-ID (diff)
From: ben@simtec.co.uk (Ben Dooks)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v3 05/12] s3c-fb: Add support for display panning
Date: Fri, 02 Jul 2010 12:24:11 +0100	[thread overview]
Message-ID: <4C2DCC5B.2000100@simtec.co.uk> (raw)
In-Reply-To: <1277712538-23188-6-git-send-email-p.osciak@samsung.com>

On 28/06/10 09:08, Pawel Osciak wrote:
> Supports all bpp modes.
> 
> The PRTCON register is used to disable in-hardware updates of registers
> that store start and end addresses of framebuffer memory. This prevents
> display corruption in case we do not make it before VSYNC with updating
> them atomically. With this feature there is no need to wait for a VSYNC
> interrupt before each such update.
> 
> Signed-off-by: Pawel Osciak <p.osciak@samsung.com>
> Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
> ---
>  arch/arm/plat-samsung/include/plat/regs-fb.h |    5 ++
>  drivers/video/s3c-fb.c                       |   71 ++++++++++++++++++++++++++
>  2 files changed, 76 insertions(+), 0 deletions(-)
> 
> diff --git a/arch/arm/plat-samsung/include/plat/regs-fb.h b/arch/arm/plat-samsung/include/plat/regs-fb.h
> index ac10013..f454e32 100644
> --- a/arch/arm/plat-samsung/include/plat/regs-fb.h
> +++ b/arch/arm/plat-samsung/include/plat/regs-fb.h
> @@ -112,6 +112,11 @@
>  #define VIDCON2_ORGYCbCr			(1 << 8)
>  #define VIDCON2_YUVORDCrCb			(1 << 7)
>  
> +/* PRTCON (S3C6410, S5PC100) */

Not listed in my S3C6410 manual?

> +#define PRTCON					(0x0c)
> +#define PRTCON_PROTECT				(1 << 11)
> +
>  /* VIDTCON0 */
>  
>  #define VIDTCON0_VBPDE_MASK			(0xff << 24)
> diff --git a/drivers/video/s3c-fb.c b/drivers/video/s3c-fb.c
> index 59ac76a..4f3680d 100644
> --- a/drivers/video/s3c-fb.c
> +++ b/drivers/video/s3c-fb.c
> @@ -71,6 +71,7 @@ struct s3c_fb;
>   * @buf_end: Offset of buffer end registers.
>   * @osd: The base for the OSD registers.
>   * @palette: Address of palette memory, or 0 if none.
> + * @has_prtcon: Set if has PRTCON register.
>   */
>  struct s3c_fb_variant {
>  	unsigned int	is_2443:1;
> @@ -85,6 +86,8 @@ struct s3c_fb_variant {
>  	unsigned short	osd;
>  	unsigned short	osd_stride;
>  	unsigned short	palette[S3C_FB_MAX_WIN];
> +
> +	unsigned int	has_prtcon:1;
>  };
>  
>  /**
> @@ -379,6 +382,9 @@ static int s3c_fb_set_par(struct fb_info *info)
>  
>  	info->fix.line_length = (var->xres_virtual * var->bits_per_pixel) / 8;
>  
> +	info->fix.xpanstep = info->var.xres_virtual > info->var.xres ? 1 : 0;
> +	info->fix.ypanstep = info->var.yres_virtual > info->var.yres ? 1 : 0;
> +
>  	/* disable the window whilst we update it */
>  	writel(0, regs + WINCON(win_no));
>  
> @@ -735,6 +741,66 @@ static int s3c_fb_blank(int blank_mode, struct fb_info *info)
>  	return 0;
>  }
>  
> +/**
> + * s3c_fb_pan_display() - Pan the display.
> + *
> + * Note that the offsets can be written to the device at any time, as their
> + * values are latched at each vsync automatically. This also means that only
> + * the last call to this function will have any effect on next vsync, but
> + * there is no need to sleep waiting for it to prevent tearing.
> + *
> + * @var: The screen information to verify.
> + * @info: The framebuffer device.
> + */
> +static int s3c_fb_pan_display(struct fb_var_screeninfo *var,
> +			      struct fb_info *info)
> +{
> +	struct s3c_fb_win *win	= info->par;
> +	struct s3c_fb *sfb	= win->parent;
> +	void __iomem *buf	= sfb->regs + win->index * 8;
> +	unsigned int start_byte_offset, end_byte_offset;

could have shortened to start and end, might have made some of the
calculation easier.

> +	/* Offset in bytes to the start of the displayed area */
> +	start_byte_offset = var->yoffset * info->fix.line_length;
> +	/* X offset depends on the current bpp */
> +	if (info->var.bits_per_pixel >= 8) {
> +		start_byte_offset +=
> +			var->xoffset * (info->var.bits_per_pixel >> 3);
> +	} else {
> +		switch (info->var.bits_per_pixel) {
> +		case 4:
> +			start_byte_offset += var->xoffset >> 1;
> +			break;
> +		case 2:
> +			start_byte_offset += var->xoffset >> 2;
> +			break;
> +		case 1:
> +			start_byte_offset += var->xoffset >> 3;
> +			break;
> +		default:
> +			dev_err(sfb->dev, "invalid bpp\n");
> +			return -EINVAL;
> +		}
> +	}

this could have been done by changing it to
start_byte_offset += var->xoffset / (8 / info->var.bits_per_pixel);

note, you always set pan step to 1, evne if the case of bpp less than 8.

> +	/* Offset in bytes to the end of the displayed area */
> +	end_byte_offset = start_byte_offset + var->yres * info->fix.line_length;
> +
> +	/* Temporarily turn off per-vsync update from shadow registers until
> +	 * both start and end addresses are updated to prevent corruption */
> +	if (sfb->variant.has_prtcon)
> +		writel(PRTCON_PROTECT, sfb->regs + PRTCON);
> +
> +	writel(info->fix.smem_start + start_byte_offset,
> +		buf + sfb->variant.buf_start);
> +	writel(info->fix.smem_start + end_byte_offset,
> +		buf + sfb->variant.buf_end);
> +
> +	if (sfb->variant.has_prtcon)
> +		writel(0, sfb->regs + PRTCON);
> +
> +	return 0;
> +}
> +
>  static struct fb_ops s3c_fb_ops = {
>  	.owner		= THIS_MODULE,
>  	.fb_check_var	= s3c_fb_check_var,
> @@ -744,6 +810,7 @@ static struct fb_ops s3c_fb_ops = {
>  	.fb_fillrect	= cfb_fillrect,
>  	.fb_copyarea	= cfb_copyarea,
>  	.fb_imageblit	= cfb_imageblit,
> +	.fb_pan_display	= s3c_fb_pan_display,
>  };
>  
>  /**
> @@ -1243,6 +1310,8 @@ static struct s3c_fb_driverdata s3c_fb_data_64xx __devinitdata = {
>  			[3] = 0x320,
>  			[4] = 0x340,
>  		},
> +
> +		.has_prtcon	= 1,
>  	},
>  	.win[0]	= &s3c_fb_data_64xx_wins[0],
>  	.win[1]	= &s3c_fb_data_64xx_wins[1],
> @@ -1271,6 +1340,8 @@ static struct s3c_fb_driverdata s3c_fb_data_s5pc100 __devinitdata = {
>  			[3] = 0x3000,
>  			[4] = 0x3400,
>  		},
> +
> +		.has_prtcon	= 1,
>  	},
>  	.win[0]	= &s3c_fb_data_64xx_wins[0],
>  	.win[1]	= &s3c_fb_data_64xx_wins[1],

  parent reply	other threads:[~2010-07-02 11:24 UTC|newest]

Thread overview: 99+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-06-28  8:08 [PATCH v3 0/12] Various s3c-fb updates Pawel Osciak
2010-06-28  8:08 ` Pawel Osciak
2010-06-28  8:08 ` Pawel Osciak
2010-06-28  8:08 ` [PATCH v3 01/12] s3c-fb: Fix various null references on framebuffer Pawel Osciak
2010-06-28  8:08   ` [PATCH v3 01/12] s3c-fb: Fix various null references on framebuffer memory alloc failure Pawel Osciak
2010-06-28  8:08   ` Pawel Osciak
2010-07-02  9:51   ` [PATCH v3 01/12] s3c-fb: Fix various null references on framebuffer Ben Dooks
2010-07-02  9:51     ` [PATCH v3 01/12] s3c-fb: Fix various null references on framebuffer memory alloc failure Ben Dooks
2010-07-02  9:51     ` Ben Dooks
2010-07-02 12:56     ` [PATCH v3 01/12] s3c-fb: Fix various null references on Pawel Osciak
2010-07-02 12:56       ` [PATCH v3 01/12] s3c-fb: Fix various null references on framebuffer memory alloc failure Pawel Osciak
2010-07-02 12:56       ` Pawel Osciak
2010-07-06 16:16     ` [PATCH v3 01/12] s3c-fb: Fix various null references on framebuffer James Simmons
2010-07-06 16:16       ` [PATCH v3 01/12] s3c-fb: Fix various null references on framebuffer memory alloc failure James Simmons
2010-07-06 16:16       ` James Simmons
2010-06-28  8:08 ` [PATCH v3 02/12] s3c-fb: Correct FRAMESEL1 bitfield defines for Pawel Osciak
2010-06-28  8:08   ` [PATCH v3 02/12] s3c-fb: Correct FRAMESEL1 bitfield defines for VIDINTCON0 register Pawel Osciak
2010-06-28  8:08   ` Pawel Osciak
2010-07-02 10:51   ` [PATCH v3 02/12] s3c-fb: Correct FRAMESEL1 bitfield defines for Ben Dooks
2010-07-02 10:51     ` [PATCH v3 02/12] s3c-fb: Correct FRAMESEL1 bitfield defines for VIDINTCON0 register Ben Dooks
2010-07-02 10:51     ` Ben Dooks
2010-06-28  8:08 ` [PATCH v3 03/12] s3c-fb: Separate S5PC100 and S5PV210 framebuffer Pawel Osciak
2010-06-28  8:08   ` [PATCH v3 03/12] s3c-fb: Separate S5PC100 and S5PV210 framebuffer driver data structures Pawel Osciak
2010-06-28  8:08   ` Pawel Osciak
2010-07-02 11:12   ` [PATCH v3 03/12] s3c-fb: Separate S5PC100 and S5PV210 framebuffer Ben Dooks
2010-07-02 11:12     ` [PATCH v3 03/12] s3c-fb: Separate S5PC100 and S5PV210 framebuffer driver data structures Ben Dooks
2010-07-02 11:12     ` Ben Dooks
2010-07-02 13:05     ` [PATCH v3 03/12] s3c-fb: Separate S5PC100 and S5PV210 framebuffer Pawel Osciak
2010-07-02 13:05       ` [PATCH v3 03/12] s3c-fb: Separate S5PC100 and S5PV210 framebuffer driver data structures Pawel Osciak
2010-07-02 13:05       ` Pawel Osciak
2010-06-28  8:08 ` [PATCH v3 04/12] s3c-fb: Add device name initialization Pawel Osciak
2010-06-28  8:08   ` Pawel Osciak
2010-06-28  8:08   ` Pawel Osciak
2010-07-02 11:13   ` Ben Dooks
2010-07-02 11:13     ` Ben Dooks
2010-07-02 11:13     ` Ben Dooks
2010-06-28  8:08 ` [PATCH v3 05/12] s3c-fb: Add support for display panning Pawel Osciak
2010-06-28  8:08   ` Pawel Osciak
2010-06-28  8:08   ` Pawel Osciak
2010-06-28 11:28   ` Maurus Cuelenaere
2010-06-28 11:28     ` Maurus Cuelenaere
2010-06-28 11:28     ` Maurus Cuelenaere
2010-07-02 11:25     ` Ben Dooks
2010-07-02 11:25       ` Ben Dooks
2010-07-02 11:25       ` Ben Dooks
2010-07-02 11:33       ` Maurus Cuelenaere
2010-07-02 11:33         ` Maurus Cuelenaere
2010-07-02 11:33         ` Maurus Cuelenaere
2010-07-02 11:52       ` Mark Brown
2010-07-02 11:52         ` Mark Brown
2010-07-02 11:52         ` Mark Brown
2010-07-02 11:24   ` Ben Dooks [this message]
2010-07-02 11:24     ` Ben Dooks
2010-07-02 11:24     ` Ben Dooks
2010-07-02 13:29     ` Pawel Osciak
2010-07-02 13:29       ` Pawel Osciak
2010-07-02 13:29       ` Pawel Osciak
2010-07-04 13:50       ` Jamie Lokier
2010-07-04 13:50         ` Jamie Lokier
2010-07-04 13:50         ` Jamie Lokier
2010-06-28  8:08 ` [PATCH v3 06/12] s3c-fb: Add wait for VSYNC ioctl Pawel Osciak
2010-06-28  8:08   ` Pawel Osciak
2010-06-28  8:08   ` Pawel Osciak
2010-07-02 11:37   ` Ben Dooks
2010-07-02 11:37     ` Ben Dooks
2010-07-02 11:37     ` Ben Dooks
2010-07-02 14:39     ` Pawel Osciak
2010-07-02 14:39       ` Pawel Osciak
2010-07-02 14:39       ` Pawel Osciak
2010-06-28  8:08 ` [PATCH v3 07/12] s3c-fb: window 3 of 64xx+ does not have an osd_d Pawel Osciak
2010-06-28  8:08   ` [PATCH v3 07/12] s3c-fb: window 3 of 64xx+ does not have an osd_d register Pawel Osciak
2010-06-28  8:08   ` Pawel Osciak
2010-06-28  8:08 ` [PATCH v3 08/12] s3c-fb: Add SHADOWCON shadow register locking support Pawel Osciak
2010-06-28  8:08   ` [PATCH v3 08/12] s3c-fb: Add SHADOWCON shadow register locking support for S5PV210 Pawel Osciak
2010-06-28  8:08   ` Pawel Osciak
2010-07-02 13:11   ` [PATCH v3 08/12] s3c-fb: Add SHADOWCON shadow register locking Ben Dooks
2010-07-02 13:11     ` [PATCH v3 08/12] s3c-fb: Add SHADOWCON shadow register locking support for S5PV210 Ben Dooks
2010-07-02 13:11     ` Ben Dooks
2010-07-02 14:45     ` [PATCH v3 08/12] s3c-fb: Add SHADOWCON shadow register locking Pawel Osciak
2010-07-02 14:45       ` [PATCH v3 08/12] s3c-fb: Add SHADOWCON shadow register locking support for S5PV210 Pawel Osciak
2010-07-02 14:45       ` Pawel Osciak
2010-06-28  8:08 ` [PATCH v3 09/12] s3c-fb: Correct window osd size and alpha register Pawel Osciak
2010-06-28  8:08   ` [PATCH v3 09/12] s3c-fb: Correct window osd size and alpha register handling Pawel Osciak
2010-06-28  8:08   ` Pawel Osciak
2010-07-02 13:16   ` [PATCH v3 09/12] s3c-fb: Correct window osd size and alpha register Ben Dooks
2010-07-02 13:16     ` [PATCH v3 09/12] s3c-fb: Correct window osd size and alpha register handling Ben Dooks
2010-07-02 13:16     ` Ben Dooks
2010-07-02 14:53     ` [PATCH v3 09/12] s3c-fb: Correct window osd size and alpha Pawel Osciak
2010-07-02 14:53       ` [PATCH v3 09/12] s3c-fb: Correct window osd size and alpha register handling Pawel Osciak
2010-07-02 14:53       ` Pawel Osciak
2010-06-28  8:08 ` [PATCH v3 10/12] s3c-fb: Protect window-specific registers during Pawel Osciak
2010-06-28  8:08   ` [PATCH v3 10/12] s3c-fb: Protect window-specific registers during updates Pawel Osciak
2010-06-28  8:08   ` Pawel Osciak
2010-06-28  8:08 ` [PATCH v3 11/12] s3c-fb: fix section mismatch Pawel Osciak
2010-06-28  8:08   ` Pawel Osciak
2010-06-28  8:08   ` Pawel Osciak
2010-06-28  8:08 ` [PATCH v3 12/12] s3c-fb: Add support for DMA channel control on S5PV210 Pawel Osciak
2010-06-28  8:08   ` Pawel Osciak
2010-06-28  8:08   ` Pawel Osciak

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4C2DCC5B.2000100@simtec.co.uk \
    --to=ben@simtec.co.uk \
    --cc=linux-arm-kernel@lists.infradead.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.