Subject: Re: [-mm patch 2/5] SharpSL: Add cxx00 support to the Corgi LCD
	driver
From: Richard Purdie <rpurdie@rpsys.net>
To: Russell King <rmk+lkml@arm.linux.org.uk>
Cc: Andrew Morton <akpm@osdl.org>, LKML <linux-kernel@vger.kernel.org>
In-Reply-To: <20050908133408.F31595@flint.arm.linux.org.uk>
References: <1126007628.8338.127.camel@localhost.localdomain>
	 <20050908133408.F31595@flint.arm.linux.org.uk>
Content-Type: text/plain
Date: Thu, 08 Sep 2005 16:06:10 +0100
Message-Id: <1126191970.8147.79.camel@localhost.localdomain>
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1950
Lines: 45

On Thu, 2005-09-08 at 13:34 +0100, Russell King wrote: 
> On Tue, Sep 06, 2005 at 12:53:48PM +0100, Richard Purdie wrote:
> > +/*
> > + * Corgi/Spitz Touchscreen to LCD interface
> > + */
> > +unsigned long inline corgi_get_hsync_len(void) 
> > +{
> > +	if (machine_is_corgi() || machine_is_shepherd() || machine_is_husky()) {
> > +#ifdef CONFIG_PXA_SHARP_C7xx
> > +		return w100fb_get_hsynclen(&corgifb_device.dev);
> > +#endif
> > +	} else if (machine_is_spitz() || machine_is_akita() || machine_is_borzoi()) {
> > +#ifdef CONFIG_PXA_SHARP_Cxx00
> > +		return pxafb_get_hsync_time(&pxafb_device.dev);
> > +#endif
> 
> This means you have to force these drivers to be built (since this file
> will always be built for sharp stuff.)  This doesn't seem like a good
> solution.

It was made inline so in theory only the touchscreen drivers had the
dependency. I then moved it to another file which kind of breaks things.

Would using symbol_put and symbol_get be a better solution? I was warned
off those functions in the past but this would appear to be an ideal use
as if the framebuffer drivers aren't loaded, we don't care about this.

> > +#define SyncHS(x)   while((GPLR(x) & GPIO_bit(x)) == 0); while((GPLR(x) & GPIO_bit(x)) != 0);
> 
> That's particularly gruesome - firstly, two statements inside a macro.
> Secondly, no barrier() or cpu_relax() in there (as the kernel janitors
> like to see.)  It won't make any difference to the generated code, but
> makes other folk happier.

This needs to be a fast piece of code as its in an interrupt handler and
we go to great lengths to time things to avoid interference from the
lcd. I need to check what timing overhead those functions have...

Richard

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/