All of lore.kernel.org
 help / color / mirror / Atom feed
From: Johan Hovold <jhovold@gmail.com>
To: linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH 1/3] atmel_lcdfb: fix 16-bpp modes on older SOCs
Date: Wed, 30 Jan 2013 13:26:37 +0000	[thread overview]
Message-ID: <20130130132637.GA29440@localhost> (raw)
In-Reply-To: <20130129135435.GN7360@game.jcrosoft.org>

On Tue, Jan 29, 2013 at 02:54:35PM +0100, Jean-Christophe PLAGNIOL-VILLARD wrote:
> On 13:28 Mon 10 Dec     , Johan Hovold wrote:
> > Fix regression introduced by commit 787f9fd23283 ("atmel_lcdfb: support
> > 16bit BGR:565 mode, remove unsupported 15bit modes") which broke 16-bpp
> > modes for older SOCs which use IBGR:555 (msb is intensity) rather
> > than BGR:565.
> > 
> > Use SOC-type to determine the pixel layout.
> > 
> > Tested on custom at91sam9263-board.
> > 
> > Cc: <stable@vger.kernel.org>
> > Signed-off-by: Johan Hovold <jhovold@gmail.com>
> > ---
> >  drivers/video/atmel_lcdfb.c | 22 +++++++++++++++-------
> >  include/video/atmel_lcdc.h  |  1 +
> >  2 files changed, 16 insertions(+), 7 deletions(-)
> > 
> > diff --git a/drivers/video/atmel_lcdfb.c b/drivers/video/atmel_lcdfb.c
> > index 1505539..1f68fa6 100644
> > --- a/drivers/video/atmel_lcdfb.c
> > +++ b/drivers/video/atmel_lcdfb.c
> > @@ -422,17 +422,22 @@ static int atmel_lcdfb_check_var(struct fb_var_screeninfo *var,
> >  			= var->bits_per_pixel;
> >  		break;
> >  	case 16:
> > +		/* Older SOCs use IBGR:555 rather than BGR:565. */
> > +		if (sinfo->have_intensity_bit)
> > +			var->green.length = 5;
> > +		else
> > +			var->green.length = 6;
> > +
> >  		if (sinfo->lcd_wiring_mode = ATMEL_LCDC_WIRING_RGB) {
> > -			/* RGB:565 mode */
> > -			var->red.offset = 11;
> > +			/* RGB:5X5 mode */
> > +			var->red.offset = var->green.length + 5;
> >  			var->blue.offset = 0;
> >  		} else {
> > -			/* BGR:565 mode */
> > +			/* BGR:5X5 mode */
> >  			var->red.offset = 0;
> > -			var->blue.offset = 11;
> > +			var->blue.offset = var->green.length + 5;
> >  		}
> >  		var->green.offset = 5;
> > -		var->green.length = 6;
> >  		var->red.length = var->blue.length = 5;
> >  		break;
> >  	case 32:
> > @@ -679,8 +684,7 @@ static int atmel_lcdfb_setcolreg(unsigned int regno, unsigned int red,
> >  
> >  	case FB_VISUAL_PSEUDOCOLOR:
> >  		if (regno < 256) {
> > -			if (cpu_is_at91sam9261() || cpu_is_at91sam9263()
> > -			    || cpu_is_at91sam9rl()) {
> > +			if (sinfo->have_intensity_bit) {
> >  				/* old style I+BGR:555 */
> >  				val  = ((red   >> 11) & 0x001f);
> >  				val |= ((green >>  6) & 0x03e0);
> > @@ -870,6 +874,10 @@ static int __init atmel_lcdfb_probe(struct platform_device *pdev)
> >  	}
> >  	sinfo->info = info;
> >  	sinfo->pdev = pdev;
> > +	if (cpu_is_at91sam9261() || cpu_is_at91sam9263() ||
> > +							cpu_is_at91sam9rl()) {
> > +		sinfo->have_intensity_bit = true;
> > +	}
> nack
> 
> you need to drop the cpu_is as this can only be use now for the core
> 
> use platform_device_id to indetify the IP as done on at91-i2c as we can not
> detect the IP version

If this was a new feature and not a regression, fix I'd fully agree. There
are however currently four places in atmel_lcdfb where cpu_is macros are
used, and my patch only refactors one of them.

I can submit a follow up patch which add platform_device_id support, but
such a patch will be quite invasive and thus not 3.8-rc or stable material.

How about accepting this patch as it is, considering that it fixes an
obvious regression and also facilitate the move to platform_device_id by
introducing the intensity-bit flag?

Thanks,
Johan

WARNING: multiple messages have this Message-ID (diff)
From: jhovold@gmail.com (Johan Hovold)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 1/3] atmel_lcdfb: fix 16-bpp modes on older SOCs
Date: Wed, 30 Jan 2013 14:26:37 +0100	[thread overview]
Message-ID: <20130130132637.GA29440@localhost> (raw)
In-Reply-To: <20130129135435.GN7360@game.jcrosoft.org>

On Tue, Jan 29, 2013 at 02:54:35PM +0100, Jean-Christophe PLAGNIOL-VILLARD wrote:
> On 13:28 Mon 10 Dec     , Johan Hovold wrote:
> > Fix regression introduced by commit 787f9fd23283 ("atmel_lcdfb: support
> > 16bit BGR:565 mode, remove unsupported 15bit modes") which broke 16-bpp
> > modes for older SOCs which use IBGR:555 (msb is intensity) rather
> > than BGR:565.
> > 
> > Use SOC-type to determine the pixel layout.
> > 
> > Tested on custom at91sam9263-board.
> > 
> > Cc: <stable@vger.kernel.org>
> > Signed-off-by: Johan Hovold <jhovold@gmail.com>
> > ---
> >  drivers/video/atmel_lcdfb.c | 22 +++++++++++++++-------
> >  include/video/atmel_lcdc.h  |  1 +
> >  2 files changed, 16 insertions(+), 7 deletions(-)
> > 
> > diff --git a/drivers/video/atmel_lcdfb.c b/drivers/video/atmel_lcdfb.c
> > index 1505539..1f68fa6 100644
> > --- a/drivers/video/atmel_lcdfb.c
> > +++ b/drivers/video/atmel_lcdfb.c
> > @@ -422,17 +422,22 @@ static int atmel_lcdfb_check_var(struct fb_var_screeninfo *var,
> >  			= var->bits_per_pixel;
> >  		break;
> >  	case 16:
> > +		/* Older SOCs use IBGR:555 rather than BGR:565. */
> > +		if (sinfo->have_intensity_bit)
> > +			var->green.length = 5;
> > +		else
> > +			var->green.length = 6;
> > +
> >  		if (sinfo->lcd_wiring_mode == ATMEL_LCDC_WIRING_RGB) {
> > -			/* RGB:565 mode */
> > -			var->red.offset = 11;
> > +			/* RGB:5X5 mode */
> > +			var->red.offset = var->green.length + 5;
> >  			var->blue.offset = 0;
> >  		} else {
> > -			/* BGR:565 mode */
> > +			/* BGR:5X5 mode */
> >  			var->red.offset = 0;
> > -			var->blue.offset = 11;
> > +			var->blue.offset = var->green.length + 5;
> >  		}
> >  		var->green.offset = 5;
> > -		var->green.length = 6;
> >  		var->red.length = var->blue.length = 5;
> >  		break;
> >  	case 32:
> > @@ -679,8 +684,7 @@ static int atmel_lcdfb_setcolreg(unsigned int regno, unsigned int red,
> >  
> >  	case FB_VISUAL_PSEUDOCOLOR:
> >  		if (regno < 256) {
> > -			if (cpu_is_at91sam9261() || cpu_is_at91sam9263()
> > -			    || cpu_is_at91sam9rl()) {
> > +			if (sinfo->have_intensity_bit) {
> >  				/* old style I+BGR:555 */
> >  				val  = ((red   >> 11) & 0x001f);
> >  				val |= ((green >>  6) & 0x03e0);
> > @@ -870,6 +874,10 @@ static int __init atmel_lcdfb_probe(struct platform_device *pdev)
> >  	}
> >  	sinfo->info = info;
> >  	sinfo->pdev = pdev;
> > +	if (cpu_is_at91sam9261() || cpu_is_at91sam9263() ||
> > +							cpu_is_at91sam9rl()) {
> > +		sinfo->have_intensity_bit = true;
> > +	}
> nack
> 
> you need to drop the cpu_is as this can only be use now for the core
> 
> use platform_device_id to indetify the IP as done on at91-i2c as we can not
> detect the IP version

If this was a new feature and not a regression, fix I'd fully agree. There
are however currently four places in atmel_lcdfb where cpu_is macros are
used, and my patch only refactors one of them.

I can submit a follow up patch which add platform_device_id support, but
such a patch will be quite invasive and thus not 3.8-rc or stable material.

How about accepting this patch as it is, considering that it fixes an
obvious regression and also facilitate the move to platform_device_id by
introducing the intensity-bit flag?

Thanks,
Johan

  reply	other threads:[~2013-01-30 13:26 UTC|newest]

Thread overview: 42+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-12-10 12:28 [PATCH 0/3] atmel_lcdfb: fix 16-bpp regression Johan Hovold
2012-12-10 12:28 ` Johan Hovold
2012-12-10 12:28 ` [PATCH 1/3] atmel_lcdfb: fix 16-bpp modes on older SOCs Johan Hovold
2012-12-10 12:28   ` Johan Hovold
2012-12-10 12:50   ` Peter Korsgaard
2012-12-10 12:50     ` Peter Korsgaard
2013-01-29 13:54   ` Jean-Christophe PLAGNIOL-VILLARD
2013-01-29 13:54     ` Jean-Christophe PLAGNIOL-VILLARD
2013-01-30 13:26     ` Johan Hovold [this message]
2013-01-30 13:26       ` Johan Hovold
2013-02-05 13:35     ` [PATCH 0/5] atmel_lcdfb: regression fixes and cpu_is removal Johan Hovold
2013-02-05 13:35       ` Johan Hovold
2013-02-05 13:35       ` [PATCH 1/5] atmel_lcdfb: fix 16-bpp modes on older SOCs Johan Hovold
2013-02-05 13:35         ` Johan Hovold
2013-02-05 13:35       ` [PATCH 2/5] ARM: at91/neocore926: fix LCD-wiring mode Johan Hovold
2013-02-05 13:35         ` Johan Hovold
2013-02-05 13:35       ` [PATCH 3/5] atmel_lcdfb: remove unsupported 15-bpp mode Johan Hovold
2013-02-05 13:35         ` Johan Hovold
2013-02-05 13:35       ` [PATCH 4/5] atmel_lcdfb: move lcdcon2 register access to compute_hozval Johan Hovold
2013-02-05 13:35         ` Johan Hovold
2013-02-05 13:35       ` [PATCH 5/5] ARM: at91/avr32/atmel_lcdfb: replace cpu_is macros with device-id table Johan Hovold
2013-02-05 13:35         ` Johan Hovold
2013-02-05 20:11         ` Jean-Christophe PLAGNIOL-VILLARD
2013-02-05 20:11           ` Jean-Christophe PLAGNIOL-VILLARD
2013-02-07 15:31           ` [PATCH v2 0/3] ARM: at91/avr32/atmel_lcdfb: remove cpu_is macros Johan Hovold
2013-02-07 15:31             ` Johan Hovold
2013-02-07 15:31             ` [PATCH v2 1/3] ARM: at91/avr32/atmel_lcdfb: add bus-clock entry Johan Hovold
2013-02-07 15:31               ` Johan Hovold
2013-02-07 15:31             ` [PATCH v2 2/3] atmel_lcdfb: move lcdcon2 register access to compute_hozval Johan Hovold
2013-02-07 15:31               ` Johan Hovold
2013-02-07 15:31             ` [PATCH v2 3/3] ARM: at91/avr32/atmel_lcdfb: add platform device-id table Johan Hovold
2013-02-07 15:31               ` Johan Hovold
2012-12-10 12:28 ` [PATCH 2/3] ARM: at91/neocore926: fix LCD-wiring mode Johan Hovold
2012-12-10 12:28   ` Johan Hovold
2012-12-10 12:50   ` Peter Korsgaard
2012-12-10 12:50     ` Peter Korsgaard
2012-12-10 12:28 ` [PATCH 3/3] atmel_lcdfb: remove unsupported 15-bpp mode Johan Hovold
2012-12-10 12:28   ` Johan Hovold
2012-12-10 12:51   ` Peter Korsgaard
2012-12-10 12:51     ` Peter Korsgaard
2013-01-26 15:44 ` [PATCH 0/3] atmel_lcdfb: fix 16-bpp regression Johan Hovold
2013-01-26 15:44   ` Johan Hovold

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=20130130132637.GA29440@localhost \
    --to=jhovold@gmail.com \
    --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.