linux-fbdev-devel — linux-fbdev mailing list for project developers

[Linux-fbdev-devel] [PATCH 11/33] ps3fb: GPU memory mapping cleanup

[Geert U. <Gee...@so...>]

  - Make the IOMMU flags used for mapping main memory into the GPU's I/O space
    explicit, instead of relying on the default in the hypervisor,
  - Add missing calls to lv1_gpu_context_iomap(..., CBE_IOPTE_M) to unmap the
    memory during cleanup.

Signed-off-by: Geert Uytterhoeven <Gee...@so...>
Cc: lin...@li...
---
v2: Add CBE_ prefix

 drivers/video/ps3fb.c |   15 ++++++++++++---
 1 files changed, 12 insertions(+), 3 deletions(-)

diff --git a/drivers/video/ps3fb.c b/drivers/video/ps3fb.c
index 542ffc3..a61c1d8 100644
--- a/drivers/video/ps3fb.c
+++ b/drivers/video/ps3fb.c
@@ -32,6 +32,7 @@
 #include <linux/init.h>
 
 #include <asm/abs_addr.h>
+#include <asm/iommu.h>
 #include <asm/lv1call.h>
 #include <asm/ps3av.h>
 #include <asm/ps3fb.h>
@@ -1122,7 +1123,9 @@ static int __devinit ps3fb_probe(struct ps3_system_bus_device *dev)
 	xdr_lpar = ps3_mm_phys_to_lpar(__pa(ps3fb_videomemory.address));
 
 	status = lv1_gpu_context_iomap(ps3fb.context_handle, GPU_IOIF,
-				       xdr_lpar, ps3fb_videomemory.size, 0);
+				       xdr_lpar, ps3fb_videomemory.size,
+				       CBE_IOPTE_PP_W | CBE_IOPTE_PP_R |
+				       CBE_IOPTE_M);
 	if (status) {
 		dev_err(&dev->core, "%s: lv1_gpu_context_iomap failed: %d\n",
 			__func__, status);
@@ -1143,12 +1146,12 @@ static int __devinit ps3fb_probe(struct ps3_system_bus_device *dev)
 			"%s: lv1_gpu_context_attribute FB_SETUP failed: %d\n",
 			__func__, status);
 		retval = -ENXIO;
-		goto err_free_irq;
+		goto err_context_unmap;
 	}
 
 	info = framebuffer_alloc(sizeof(struct ps3fb_par), &dev->core);
 	if (!info)
-		goto err_free_irq;
+		goto err_context_unmap;
 
 	par = info->par;
 	par->mode_id = ~ps3fb_mode;	/* != ps3fb_mode, to trigger change */
@@ -1213,6 +1216,9 @@ err_fb_dealloc:
 	fb_dealloc_cmap(&info->cmap);
 err_framebuffer_release:
 	framebuffer_release(info);
+err_context_unmap:
+	lv1_gpu_context_iomap(ps3fb.context_handle, GPU_IOIF, xdr_lpar,
+			      ps3fb_videomemory.size, CBE_IOPTE_M);
 err_free_irq:
 	free_irq(ps3fb.irq_no, &dev->core);
 err_destroy_plug:
@@ -1232,6 +1238,7 @@ err:
 static int ps3fb_shutdown(struct ps3_system_bus_device *dev)
 {
 	struct fb_info *info = dev->core.driver_data;
+	u64 xdr_lpar = ps3_mm_phys_to_lpar(__pa(ps3fb_videomemory.address));
 
 	dev_dbg(&dev->core, " -> %s:%d\n", __func__, __LINE__);
 
@@ -1254,6 +1261,8 @@ static int ps3fb_shutdown(struct ps3_system_bus_device *dev)
 		info = dev->core.driver_data = NULL;
 	}
 	iounmap((u8 __force __iomem *)ps3fb.dinfo);
+	lv1_gpu_context_iomap(ps3fb.context_handle, GPU_IOIF, xdr_lpar,
+			      ps3fb_videomemory.size, CBE_IOPTE_M);
 	lv1_gpu_context_free(ps3fb.context_handle);
 	lv1_gpu_memory_free(ps3fb.memory_handle);
 	ps3_close_hv_device(dev);
-- 
1.6.2.4

Re: [Linux-fbdev-devel] PATCH - Add accelerated bitblt functions to s1d13xxxfb

[Andrew M. <ak...@li...>]

On Sat, 6 Jun 2009 14:10:37 +0200
Kristoffer Ericson <kri...@gm...> wrote:

> This patch adds accelerated bitblt functions to s1d13xxx based 
> video chipsets, more specificly functions copyarea and fillrect. 
> It has only been tested and activated for 13506 chipsets
> but is expected to work for the majority of s1d13xxx based chips.
> This patch also cleans up the driver with respect of whitespaces
> and other formatting issues. We update the current status
> comments.
> 

Was I sent half a patch?


drivers/video/s1d13xxxfb.c: In function 'bltbit_fifo_status':
drivers/video/s1d13xxxfb.c:470: error: 'BBLT_FIFO_EMPTY' undeclared (first use in this function)
drivers/video/s1d13xxxfb.c:470: error: (Each undeclared identifier is reported only once
drivers/video/s1d13xxxfb.c:470: error: for each function it appears in.)
drivers/video/s1d13xxxfb.c:474: error: 'BBLT_FIFO_FULL' undeclared (first use in this function)
drivers/video/s1d13xxxfb.c:478: error: 'BBLT_FIFO_NOT_FULL' undeclared (first use in this function)
drivers/video/s1d13xxxfb.c: In function 's1d13xxxfb_bitblt_solidfill':
drivers/video/s1d13xxxfb.c:640: error: 'BBLT_SOLID_FILL' undeclared (first use in this function)

Re: [Linux-fbdev-devel] [PATCH 02/20] omapfb: Add support for MIPI-DCS compatible LCDs

[Imre D. <imr...@no...>]

Hi,

On Mon, Jun 08, 2009 at 12:43:24AM +0200, ext Krzysztof Helt wrote:
> On Thu,  4 Jun 2009 20:52:27 +0300
> Imre Deak <imr...@no...> wrote:
>[...]
> > +
> > +#define to_mipid_device(p)		container_of(p, struct mipid_device, \
> > +						panel)
> > +struct mipid_device {
> > +	int		enabled;
> > +	int		model;
> 
> This one is only set and never read. A name is probably enough.

Ok, I'll remove model.

> 
> > +	int		revision;
> > +	u8		display_id[3];
> 
> This one should be a local variable.

Ok, I'll move it to the func where it's used.

> 
> > +	unsigned int	saved_bklight_level;
> > +	unsigned long	hw_guard_end;		/* next value of jiffies
> > +						   when we can issue the
> > +						   next sleep in/out command */
> > +	unsigned long	hw_guard_wait;		/* max guard time in jiffies */
> > +
> > +	struct omapfb_device	*fbdev;
> > +	struct spi_device	*spi;
> > +	struct mutex		mutex;
> > +	struct lcd_panel	panel;
> 
> How does it differ from fbdev->panel? Is it duplicated field?

fbdev->panel is a pointer to this device instance specific data. It's embedded here
so that we can get to struct mipid_device with the container_of macro when fbdev->panel
is passed to us.

> 
> I am sorry but I had not enough time to review the rest.

Thanks for the review, if there is nothing else I can post a new version with the
above changes.

--Imre

Re: [Linux-fbdev-devel] Samsung SoC Framebuffer Driver issue.

[InKi D. <da...@gm...>]

There are my comments about your answers.
And thank you for your answer.

2009/6/9 Ben Dooks <be...@si...>:
> InKi Dae wrote:
>>
>> Hello,  Ben  Dooks.
>>
>> I am trying to develop Samsung SoC Framebuffer Driver for S5PC100 but
>> I faced some problems about design. so I have some questions about those.
>>
>> there are some differences between LCD Controller registers of S3C64XX
>> and S5PC100 like the following.
>>
>> . regiters not used by S3C64XX were added to S5PC100 also BPP MODE.
>> . WindowX Palette Data Index registers were removed from lcd
>> controller of S3C64XX and Palette Memory Registers were added to one
>> of S5PC100
>>
>>
>> 1.
>> Your framebuffer driver, drivers/video/s3c-fb.c, is related to only
>> S3C64XX.
>> and I'd like to divide framebuffer driver into common logical driver
>> for supporting S3C64XX and S5PC100 and S5PC100 specific driver.
>> but your driver needs to modifying because calling register control
>> commands in s3c-fb.c directly.
>
> Actually, it should also support the s3c2443 driver. You might find some
> interesting answers to the further questions by looking at how that works
> via the architecture specific includes.
>
I missed about S3C2443.
Yes, but I think including architecture specific header files is valid
only in case that all the S3C64XX registers are same with S5PC100.
Actually, almost registers of S5PC100 are same with S3C64XX but
different from some registers as I said before.
If new features for S5PC100 would be added to your driver then we
would find #ifdef CONFIG_S5PC100 in your driver.
this reason is because your driver calls low level functions (writel and readl).
So considering S5PC100 and S5PC110, I think it is good way to call
only generic interfaces.

for example,
s3c_fb_enable() calls low level function (writel) for enabling LCD Controller.
but my proposal will call generic interface in specific file. like
this fb_enable() -> s3c_fb_enable().
fb_enable(), as generic interface, will call s3c_fb_enable() and
s3c_fb_enable() is specific code (writel and readl are used here).

In case of this, s3c-fb.c, as generic driver, could support S3C2442,
S3C64XX, S5PC100 and S5PC110.
So I would like to divide Samsung SoC Framebuffer Driver into generic
driver and specific driver.

How do you think about that and do you have any idea ?

>> How do you think about that ?
>>
>> 2.
>> S3C64XX LCD Controller's registers are similar with S5PC100's, so I
>> wouldn't modify register prefix.
>> but some registers should added to definition file
>> (arch/arm/mach-s3c6400/include/mach/regs-fb.h).
>
> I don't have documentation for any of these newer chips, so cannot make
> much of a comment without any more detailed data.
>
>> which way do you prefer adding some registers to
>> arch/arm/mach-s3c6400/include/mach/regs-fb.h or creating new
>> definition file for S5PC100 ?
>>
>> If you give me your comments for the issues above, I will modify
>> Samsung SoC Framebuffer Driver to be supported for S3C64XX and
>> S5PC100.
>> In the result, I expect that your driver will be divided into logical
>> driver and specific driver supporting S3C64XX and S5PC100 or either
>> S3C64XX or S5PC100.
>> If the driver would be completed, logical driver, s3c-fb.c, would
>> support S3C64XX, S5PC100 and also S5PC110.
>
> I'll let you have a think about this wrt to the answer supplied for #1,
> and see if you need any further information about it after that.
>
>> Please give me your comments and advices.
>>
>> Best Regards,
>> InKi Dae.
>
>
> --
> Ben Dooks, Software Engineer, Simtec Electronics
>
> http://www.simtec.co.uk/
>

Re: [Linux-fbdev-devel] [PATCH] atmel_lcdfb: Correct fifo size for some products

[Greg KH <gr...@su...>]

On Mon, Jun 08, 2009 at 05:36:20PM +0200, Nicolas Ferre wrote:
> Andrew Morton :
> > On Fri, 15 May 2009 12:34:18 +0200 Nicolas Ferre <nic...@at...> wrote:
> > 
> >> Remove wrong fifo size definition for some AT91 products.
> >>
> >> Due to a misunderstanding of some AT91 datasheets, a fifo size of 2048 (words)
> >> has been introduced by mistake. In fact, all products (AT91/AT32) are sharing
> >> the same fifo size of 512 words.
> >>
> > 
> > Changelog fails to describe the impact of the bug, so people who are
> > working out which kernel versions it should be ported into don't know
> > what to do.
> > 
> > Furthermore, people who are hitting a bug in this driver in older
> > kernel versions will have difficulty working out whether this patch
> > might fix their bug.
> 
> Ok, you are right, I will try to add some information.
> 
> In fact, if you mis-configure the fifo watermark making it too high you
> end without the capacity of issuing burst transfers on the internal AHB
> bus. This will decrease overall system performance as the LCD will ask
> for data as soon as the fifo will have one byte available (not efficient
> single accesses).
> 
> >> Can we consider this fix for .30-final ?
> > 
> > Sure, but for what reason?
> > 
> > What about 2.6.29.x, 2.6.28.x, earlier?
> 
> Indeed, should be valuable to extend this correction to stable kernel
> series. I added Greg to the loop for this purpose.

For stable stuff, please send any requested patches, with the git commit
id of the patch in Linus's tree, to st...@ke..., otherwise I might
miss it :)

Also, you can add:
	Cc: stable <st...@ke...>
to the signed-off-by area of the patch, and when it is taken into
Linus's tree, the stable team will automatically get notified of it and
include it in the next stable releases without any other work needed to
be done by you.

hope this helps,

greg k-h

Re: [Linux-fbdev-devel] Samsung SoC Framebuffer Driver issue.

[Ben D. <be...@si...>]

InKi Dae wrote:
> Hello,  Ben  Dooks.
> 
> I am trying to develop Samsung SoC Framebuffer Driver for S5PC100 but
> I faced some problems about design. so I have some questions about those.
> 
> there are some differences between LCD Controller registers of S3C64XX
> and S5PC100 like the following.
> 
> . regiters not used by S3C64XX were added to S5PC100 also BPP MODE.
> . WindowX Palette Data Index registers were removed from lcd
> controller of S3C64XX and Palette Memory Registers were added to one
> of S5PC100
> 
> 
> 1.
> Your framebuffer driver, drivers/video/s3c-fb.c, is related to only S3C64XX.
> and I'd like to divide framebuffer driver into common logical driver
> for supporting S3C64XX and S5PC100 and S5PC100 specific driver.
> but your driver needs to modifying because calling register control
> commands in s3c-fb.c directly.

Actually, it should also support the s3c2443 driver. You might find some
interesting answers to the further questions by looking at how that works
via the architecture specific includes.

> How do you think about that ?
> 
> 2.
> S3C64XX LCD Controller's registers are similar with S5PC100's, so I
> wouldn't modify register prefix.
> but some registers should added to definition file
> (arch/arm/mach-s3c6400/include/mach/regs-fb.h).

I don't have documentation for any of these newer chips, so cannot make
much of a comment without any more detailed data.

> which way do you prefer adding some registers to
> arch/arm/mach-s3c6400/include/mach/regs-fb.h or creating new
> definition file for S5PC100 ?
> 
> If you give me your comments for the issues above, I will modify
> Samsung SoC Framebuffer Driver to be supported for S3C64XX and
> S5PC100.
> In the result, I expect that your driver will be divided into logical
> driver and specific driver supporting S3C64XX and S5PC100 or either
> S3C64XX or S5PC100.
> If the driver would be completed, logical driver, s3c-fb.c, would
> support S3C64XX, S5PC100 and also S5PC110.

I'll let you have a think about this wrt to the answer supplied for #1,
and see if you need any further information about it after that.

> Please give me your comments and advices.
> 
> Best Regards,
> InKi Dae.


-- 
Ben Dooks, Software Engineer, Simtec Electronics

http://www.simtec.co.uk/

Re: [Linux-fbdev-devel] [PATCH] atmel_lcdfb: Correct fifo size for some products

[Nicolas F. <nic...@at...>]

Andrew Morton :
> On Fri, 15 May 2009 12:34:18 +0200 Nicolas Ferre <nic...@at...> wrote:
> 
>> Remove wrong fifo size definition for some AT91 products.
>>
>> Due to a misunderstanding of some AT91 datasheets, a fifo size of 2048 (words)
>> has been introduced by mistake. In fact, all products (AT91/AT32) are sharing
>> the same fifo size of 512 words.
>>
> 
> Changelog fails to describe the impact of the bug, so people who are
> working out which kernel versions it should be ported into don't know
> what to do.
> 
> Furthermore, people who are hitting a bug in this driver in older
> kernel versions will have difficulty working out whether this patch
> might fix their bug.

Ok, you are right, I will try to add some information.

In fact, if you mis-configure the fifo watermark making it too high you
end without the capacity of issuing burst transfers on the internal AHB
bus. This will decrease overall system performance as the LCD will ask
for data as soon as the fifo will have one byte available (not efficient
single accesses).

>> Can we consider this fix for .30-final ?
> 
> Sure, but for what reason?
> 
> What about 2.6.29.x, 2.6.28.x, earlier?

Indeed, should be valuable to extend this correction to stable kernel
series. I added Greg to the loop for this purpose.

>> --- a/drivers/video/atmel_lcdfb.c
>> +++ b/drivers/video/atmel_lcdfb.c
>> @@ -29,14 +29,8 @@
>>  
>>  /* configurable parameters */
>>  #define ATMEL_LCDC_CVAL_DEFAULT		0xc8
>> -#define ATMEL_LCDC_DMA_BURST_LEN	8
>> -
>> -#if defined(CONFIG_ARCH_AT91SAM9263) || defined(CONFIG_ARCH_AT91CAP9) || \
>> -	defined(CONFIG_ARCH_AT91SAM9RL)
>> -#define ATMEL_LCDC_FIFO_SIZE		2048
>> -#else
>> -#define ATMEL_LCDC_FIFO_SIZE		512
>> -#endif
>> +#define ATMEL_LCDC_DMA_BURST_LEN	8	/* words */
>> +#define ATMEL_LCDC_FIFO_SIZE		512	/* words */
>>  
>>  #if defined(CONFIG_ARCH_AT91)
>>  #define	ATMEL_LCDFB_FBINFO_DEFAULT	(FBINFO_DEFAULT \

Thanks to have taken immediately this patch into account ; even before
my late explanation ;-)

Best regards,
-- 
Nicolas Ferre

Re: [Linux-fbdev-devel] [PATCH] video: s3c_fb.c: fix build with CONFIG_HOTPLUG=n

[Ben D. <ben...@fl...>]

On Sun, Jun 07, 2009 at 03:05:39PM +0200, Peter Korsgaard wrote:
> Fixes `s3c_fb_remove' referenced in section `.data' of
> drivers/built-in.o: defined in discarded section `.devexit.text' of
> drivers/built-in.o
> 
> With CONFIG_HOTPLUG=n functions marked with __devexit gets removed, so
> make sure we use __devexit_p when referencing pointers to them.
> 
> Signed-off-by: Peter Korsgaard <ja...@su...>
Acked-by: Ben Dooks <ben...@fl...>
> ---
>  drivers/video/s3c-fb.c |    2 +-
>  1 files changed, 1 insertions(+), 1 deletions(-)
> 
> diff --git a/drivers/video/s3c-fb.c b/drivers/video/s3c-fb.c
> index d3a568e..db71de1 100644
> --- a/drivers/video/s3c-fb.c
> +++ b/drivers/video/s3c-fb.c
> @@ -1018,7 +1018,7 @@ static int s3c_fb_resume(struct platform_device *pdev)
>  
>  static struct platform_driver s3c_fb_driver = {
>  	.probe		= s3c_fb_probe,
> -	.remove		= s3c_fb_remove,
> +	.remove		= __devexit_p(s3c_fb_remove),
>  	.suspend	= s3c_fb_suspend,
>  	.resume		= s3c_fb_resume,
>  	.driver		= {
> -- 
> 1.6.2
> 
> 
> -------------------------------------------------------------------
> List admin: http://lists.arm.linux.org.uk/mailman/listinfo/linux-arm-kernel
> FAQ:        http://www.arm.linux.org.uk/mailinglists/faq.php
> Etiquette:  http://www.arm.linux.org.uk/mailinglists/etiquette.php

-- 
-- 
Ben

Q:      What's a light-year?
A:      One-third less calories than a regular year.

Re: [Linux-fbdev-devel] patch - bitblt 2D acceleration for s1d13xxxfb

[Kristoffer E. <kri...@gm...>]

Hi Andrew,

Ive sent the updated patch to you and list earlier. Is it okey to merge? 
I feel confident that it doesnt break anything and it is tested
to both compile and work. 

If needed I could run it by Russell and push it that way.

Best wishes 
Kristoffer Ericson

On Fri, 5 Jun 2009 13:59:16 -0700
Andrew Morton <ak...@li...> wrote:

> On Fri, 5 Jun 2009 19:38:53 +0200
> Kristoffer Ericson <kri...@gm...> wrote:
> 
> > Greetings,
> > 
> > Just wanted some feedback since this patch is quite large. Any comments are
> > appreciated. It patches, compiles and runs like a fox on fire.
> 
> we like firey foxes.
> 
> > This patch:
> > enables 2D rectfill and copyarea acceleration for 13506, need to look
> > at hardware sheets before I can say it works on other version but at minimal
> > 13806.
> > 
> > Also some cleans up the code.
> > 
> >
> > ...
> >
> > +/**
> > + * we make sure only one bitblt operation is running
> > + */
> > +static DEFINE_SPINLOCK(s1d13xxxfb_bitblt_lock);
> > +
> > +/**
> > + * list of card production ids
> >   */
> >  static const int s1d13xxxfb_prod_ids[] = {
> >  	S1D13505_PROD_ID,
> > @@ -59,7 +71,7 @@ static const int s1d13xxxfb_prod_ids[] = {
> >  	S1D13806_PROD_ID,
> >  };
> >  
> > -/*
> > +/**
> >   * List of card strings
> >   */
> >  static const char *s1d13xxxfb_prod_names[] = {
> > @@ -68,8 +80,8 @@ static const char *s1d13xxxfb_prod_names[] = {
> >  	"S1D13806",
> >  };
> >  
> > -/*
> > - * Here we define the default struct fb_fix_screeninfo
> > +/**
> > + * here we define the default struct fb_fix_screeninfo
> >   */
> 
> The /** token is reserved for introducing a kerneldoc-formatted
> comment, but none of the above three comments are kerneldoc comments.
> 
> > +/**
> > + *	bltbit_wait_bitset - waits for change in register value
> > + *	@info : framebuffer structure
> > + *	@bit  : value expected in register
> > + *	@timeout : ...
> > + *
> > + *	waits until value changes INTO bit
> > + */
> 
> That one is kerneldoc.
> 
> > +u8 bltbit_wait_bitset(struct fb_info *info, u8 bit, int timeout)
> 
> The patch adds lots of global functions.  Please make symbols static
> where possible.
> 
> > +{
> > +	while (!(s1d13xxxfb_readreg(info->par, S1DREG_BBLT_CTL0) & bit)) {
> > +		udelay(10);
> > +		if (!--timeout) {
> > +			dbg_blit("wait_bitset timeout\n");
> > +			break;
> > +		}
> > +	}
> > +
> > +	return timeout;
> > +}
> > +
> >
> > ...
> >
> 
> It otherwise looks OK to my inexpert eye.


-- 
Kristoffer Ericson <kri...@gm...>

[Linux-fbdev-devel] Samsung SoC Framebuffer Driver issue.

[InKi D. <da...@gm...>]

Hello,  Ben  Dooks.

I am trying to develop Samsung SoC Framebuffer Driver for S5PC100 but
I faced some problems about design. so I have some questions about those.

there are some differences between LCD Controller registers of S3C64XX
and S5PC100 like the following.

. regiters not used by S3C64XX were added to S5PC100 also BPP MODE.
. WindowX Palette Data Index registers were removed from lcd
controller of S3C64XX and Palette Memory Registers were added to one
of S5PC100


1.
Your framebuffer driver, drivers/video/s3c-fb.c, is related to only S3C64XX.
and I'd like to divide framebuffer driver into common logical driver
for supporting S3C64XX and S5PC100 and S5PC100 specific driver.
but your driver needs to modifying because calling register control
commands in s3c-fb.c directly.

How do you think about that ?

2.
S3C64XX LCD Controller's registers are similar with S5PC100's, so I
wouldn't modify register prefix.
but some registers should added to definition file
(arch/arm/mach-s3c6400/include/mach/regs-fb.h).

which way do you prefer adding some registers to
arch/arm/mach-s3c6400/include/mach/regs-fb.h or creating new
definition file for S5PC100 ?

If you give me your comments for the issues above, I will modify
Samsung SoC Framebuffer Driver to be supported for S3C64XX and
S5PC100.
In the result, I expect that your driver will be divided into logical
driver and specific driver supporting S3C64XX and S5PC100 or either
S3C64XX or S5PC100.
If the driver would be completed, logical driver, s3c-fb.c, would
support S3C64XX, S5PC100 and also S5PC110.

Please give me your comments and advices.

Best Regards,
InKi Dae.

Re: [Linux-fbdev-devel] [PATCH 02/20] omapfb: Add support for MIPI-DCS compatible LCDs

[Krzysztof H. <krz...@po...>]

On Thu,  4 Jun 2009 20:52:27 +0300
Imre Deak <imr...@no...> wrote:

> Fixed-by: Mike Wege <ext...@no...>
> Fixed-by: Arnaud Patard <arn...@rt...>
> Fixed-by: Timo Savola <ts...@mo...>
> Fixed-by: Hiroshi DOYU <Hir...@no...>
> Fixed-by: Trilok Soni <son...@gm...>
> Signed-off-by: Imre Deak <imr...@so...>
> Signed-off-by: Juha Yrjola <juh...@so...>
> ---
>  arch/arm/plat-omap/include/mach/lcd_mipid.h |    5 +
>  drivers/video/omap/Kconfig                  |    8 +
>  drivers/video/omap/Makefile                 |    1 +
>  drivers/video/omap/lcd_mipid.c              |  631 +++++++++++++++++++++++++++
>  4 files changed, 645 insertions(+), 0 deletions(-)
>  create mode 100644 drivers/video/omap/lcd_mipid.c
> 
> diff --git a/arch/arm/plat-omap/include/mach/lcd_mipid.h b/arch/arm/plat-omap/include/mach/lcd_mipid.h
> index f8fbc48..8e52c65 100644
> --- a/arch/arm/plat-omap/include/mach/lcd_mipid.h
> +++ b/arch/arm/plat-omap/include/mach/lcd_mipid.h
> @@ -16,7 +16,12 @@ enum mipid_test_result {
>  struct mipid_platform_data {
>  	int	nreset_gpio;
>  	int	data_lines;
> +
>  	void	(*shutdown)(struct mipid_platform_data *pdata);
> +	void	(*set_bklight_level)(struct mipid_platform_data *pdata,
> +				     int level);
> +	int	(*get_bklight_level)(struct mipid_platform_data *pdata);
> +	int	(*get_bklight_max)(struct mipid_platform_data *pdata);
>  };
>  
>  #endif
> diff --git a/drivers/video/omap/Kconfig b/drivers/video/omap/Kconfig
> index 4440885..574453f 100644
> --- a/drivers/video/omap/Kconfig
> +++ b/drivers/video/omap/Kconfig
> @@ -7,6 +7,14 @@ config FB_OMAP
>  	help
>            Frame buffer driver for OMAP based boards.
>  
> +config FB_OMAP_LCD_MIPID
> +	bool "MIPI DBI-C/DCS compatible LCD support"
> +	depends on FB_OMAP && SPI_MASTER
> +	help
> +	  Say Y here if you want to have support for LCDs compatible with
> +	  the Mobile Industry Processor Interface DBI-C/DCS
> +	  specification. (Supported LCDs: Philips LPH8923, Sharp LS041Y3)
> +
>  config FB_OMAP_BOOTLOADER_INIT
>  	bool "Check bootloader initialization"
>  	depends on FB_OMAP
> diff --git a/drivers/video/omap/Makefile b/drivers/video/omap/Makefile
> index d053498..d86d54a 100644
> --- a/drivers/video/omap/Makefile
> +++ b/drivers/video/omap/Makefile
> @@ -25,6 +25,7 @@ objs-$(CONFIG_ARCH_OMAP15XX)$(CONFIG_MACH_OMAP_INNOVATOR) += lcd_inn1510.o
>  objs-y$(CONFIG_MACH_OMAP_OSK) += lcd_osk.o
>  
>  objs-y$(CONFIG_MACH_OMAP_APOLLON) += lcd_apollon.o
> +objs-y$(CONFIG_FB_OMAP_LCD_MIPID) += lcd_mipid.o
>  
>  omapfb-objs := $(objs-yy)
>  
> diff --git a/drivers/video/omap/lcd_mipid.c b/drivers/video/omap/lcd_mipid.c
> new file mode 100644
> index 0000000..3165d3d
> --- /dev/null
> +++ b/drivers/video/omap/lcd_mipid.c
> @@ -0,0 +1,631 @@
> +/*
> + * LCD driver for MIPI DBI-C / DCS compatible LCDs
> + *
> + * Copyright (C) 2006 Nokia Corporation
> + * Author: Imre Deak <imr...@no...>
> + *
> + * This program is free software; you can redistribute it and/or modify it
> + * under the terms of the GNU General Public License as published by the
> + * Free Software Foundation; either version 2 of the License, or (at your
> + * option) any later version.
> + *
> + * This program is distributed in the hope that it will be useful, but
> + * WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
> + * General Public License for more details.
> + *
> + * You should have received a copy of the GNU General Public License along
> + * with this program; if not, write to the Free Software Foundation, Inc.,
> + * 59 Temple Place - Suite 330, Boston, MA  02111-1307, USA.
> + */
> +#include <linux/device.h>
> +#include <linux/delay.h>
> +#include <linux/workqueue.h>
> +#include <linux/spi/spi.h>
> +
> +#include <mach/omapfb.h>
> +#include <mach/lcd_mipid.h>
> +
> +#define MIPID_MODULE_NAME		"lcd_mipid"
> +
> +#define MIPID_CMD_READ_DISP_ID		0x04
> +#define MIPID_CMD_READ_RED		0x06
> +#define MIPID_CMD_READ_GREEN		0x07
> +#define MIPID_CMD_READ_BLUE		0x08
> +#define MIPID_CMD_READ_DISP_STATUS	0x09
> +#define MIPID_CMD_RDDSDR		0x0F
> +#define MIPID_CMD_SLEEP_IN		0x10
> +#define MIPID_CMD_SLEEP_OUT		0x11
> +#define MIPID_CMD_DISP_OFF		0x28
> +#define MIPID_CMD_DISP_ON		0x29
> +
> +#define MIPID_VER_LPH8923		3
> +#define MIPID_VER_LS041Y3		4
> +
> +#define MIPID_ESD_CHECK_PERIOD		msecs_to_jiffies(5000)
> +
> +#define to_mipid_device(p)		container_of(p, struct mipid_device, \
> +						panel)
> +struct mipid_device {
> +	int		enabled;
> +	int		model;

This one is only set and never read. A name is probably enough.

> +	int		revision;
> +	u8		display_id[3];

This one should be a local variable.

> +	unsigned int	saved_bklight_level;
> +	unsigned long	hw_guard_end;		/* next value of jiffies
> +						   when we can issue the
> +						   next sleep in/out command */
> +	unsigned long	hw_guard_wait;		/* max guard time in jiffies */
> +
> +	struct omapfb_device	*fbdev;
> +	struct spi_device	*spi;
> +	struct mutex		mutex;
> +	struct lcd_panel	panel;

How does it differ from fbdev->panel? Is it duplicated field?

I am sorry but I had not enough time to review the rest.

Regards,
Krzysztof


----------------------------------------------------------------------
Zostan dziennikarzem obywatelskim!
Sprawd¼ sie >>> http://link.interia.pl/f21b9

Re: [Linux-fbdev-devel] [PATCH 01/20] omapfb: Add support for the Apollon LCD

[Krzysztof H. <krz...@po...>]

On Thu,  4 Jun 2009 20:52:26 +0300
Imre Deak <imr...@no...> wrote:

> From: Kyungmin Park <kyu...@sa...>
> 
> Signed-off-by: Kyungmin Park <kyu...@sa...>
> Signed-off-by: Imre Deak <imr...@no...>
> ---

Acked-by: Krzysztof Helt <krz...@wp...>


----------------------------------------------------------------------
Masz juz dosc wysokich rachunkow? Wygraj nowa mozliwosc komunikacji!
Sprawdz >>> http://link.interia.pl/f21d2

[Linux-fbdev-devel] [PATCH] video: s3c_fb.c: fix build with CONFIG_HOTPLUG=n

[Peter K. <ja...@su...>]

Fixes `s3c_fb_remove' referenced in section `.data' of
drivers/built-in.o: defined in discarded section `.devexit.text' of
drivers/built-in.o

With CONFIG_HOTPLUG=n functions marked with __devexit gets removed, so
make sure we use __devexit_p when referencing pointers to them.

Signed-off-by: Peter Korsgaard <ja...@su...>
---
 drivers/video/s3c-fb.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/drivers/video/s3c-fb.c b/drivers/video/s3c-fb.c
index d3a568e..db71de1 100644
--- a/drivers/video/s3c-fb.c
+++ b/drivers/video/s3c-fb.c
@@ -1018,7 +1018,7 @@ static int s3c_fb_resume(struct platform_device *pdev)
 
 static struct platform_driver s3c_fb_driver = {
 	.probe		= s3c_fb_probe,
-	.remove		= s3c_fb_remove,
+	.remove		= __devexit_p(s3c_fb_remove),
 	.suspend	= s3c_fb_suspend,
 	.resume		= s3c_fb_resume,
 	.driver		= {
-- 
1.6.2

Re: [Linux-fbdev-devel] True color framebuffer

[amaora <nem...@ra...>]

On Sat, Jun 06, 2009 at 01:25:17AM +0400, amaora wrote:
> Hi,
> 
> I write framebuffer driver for the PCF8833, it work, but only if
> xxx_fix.visual == FB_VISUAL_PSEUDOCOLOR, TRUECOLOR/DIRECTCOLOR don't work.
> Kernel is blocked (stalled) in function register_framebuffer on line
> fb_notifier_call_chain(...), i don't know how to find stall point more deep.
> Why this happening?
> 
> Thanks,
> 
> Roman Belov
>

It seems to me should not write it here, sorry. Problem solved, it was
necessary to initialize a pointer to the pseudo palette, for true color.

[Linux-fbdev-devel] PATCH - Add accelerated bitblt functions to s1d13xxxfb

[Kristoffer E. <kri...@gm...>]

This patch adds accelerated bitblt functions to s1d13xxx based 
video chipsets, more specificly functions copyarea and fillrect. 
It has only been tested and activated for 13506 chipsets
but is expected to work for the majority of s1d13xxx based chips.
This patch also cleans up the driver with respect of whitespaces
and other formatting issues. We update the current status
comments.

Signed-off-by: Kristoffer Ericson <kri...@gm...>

diff --git a/drivers/video/s1d13xxxfb.c b/drivers/video/s1d13xxxfb.c
index 0726aec..a2a893f 100644
--- a/drivers/video/s1d13xxxfb.c
+++ b/drivers/video/s1d13xxxfb.c
@@ -2,6 +2,7 @@
  *
  * (c) 2004 Simtec Electronics
  * (c) 2005 Thibaut VARENE <va...@pa...>
+ * (c) 2009 Kristoffer Ericson <kri...@gm...>
  *
  * Driver for Epson S1D13xxx series framebuffer chips
  *
@@ -10,18 +11,10 @@
  *  linux/drivers/video/epson1355fb.c
  *  linux/drivers/video/epson/s1d13xxxfb.c (2.4 driver by Epson)
  *
- * Note, currently only tested on S1D13806 with 16bit CRT.
- * As such, this driver might still contain some hardcoded bits relating to
- * S1D13806.
- * Making it work on other S1D13XXX chips should merely be a matter of adding
- * a few switch()s, some missing glue here and there maybe, and split header
- * files.
- *
  * TODO: - handle dual screen display (CRT and LCD at the same time).
  *	 - check_var(), mode change, etc.
- *	 - PM untested.
- *	 - Accelerated interfaces.
- *	 - Probably not SMP safe :)
+ *	 - probably not SMP safe :)
+ *       - support all bitblt operations on all cards
  *
  * This file is subject to the terms and conditions of the GNU General Public
  * License. See the file COPYING in the main directory of this archive for
@@ -31,19 +24,24 @@
 #include <linux/module.h>
 #include <linux/platform_device.h>
 #include <linux/delay.h>
-
 #include <linux/types.h>
 #include <linux/errno.h>
 #include <linux/mm.h>
 #include <linux/mman.h>
 #include <linux/fb.h>
+#include <linux/spinlock_types.h>
+#include <linux/spinlock.h>
 
 #include <asm/io.h>
 
 #include <video/s1d13xxxfb.h>
 
-#define PFX "s1d13xxxfb: "
+#define PFX	"s1d13xxxfb: "
+#define BLIT	"s1d13xxxfb_bitblt: "
 
+/*
+ * set this to enable debugging on general functions
+ */
 #if 0
 #define dbg(fmt, args...) do { printk(KERN_INFO fmt, ## args); } while(0)
 #else
@@ -51,7 +49,21 @@
 #endif
 
 /*
- * List of card production ids
+ * set this to enable debugging on 2D acceleration
+ */
+#if 0
+#define dbg_blit(fmt, args...) do {printk(KERN_INFO BLIT fmt, ## args); } while(0)
+#else
+#define dbg_blit(fmt, args...) do { } while (0)
+#endif
+
+/*
+ * we make sure only one bitblt operation is running
+ */
+static DEFINE_SPINLOCK(s1d13xxxfb_bitblt_lock);
+
+/*
+ * list of card production ids
  */
 static const int s1d13xxxfb_prod_ids[] = {
 	S1D13505_PROD_ID,
@@ -69,7 +81,7 @@ static const char *s1d13xxxfb_prod_names[] = {
 };
 
 /*
- * Here we define the default struct fb_fix_screeninfo
+ * here we define the default struct fb_fix_screeninfo
  */
 static struct fb_fix_screeninfo __devinitdata s1d13xxxfb_fix = {
 	.id		= S1D_FBID,
@@ -145,8 +157,10 @@ crt_enable(struct s1d13xxxfb_par *par, int enable)
 	s1d13xxxfb_writereg(par, S1DREG_COM_DISP_MODE, mode);
 }
 
-/* framebuffer control routines */
 
+/*************************************************************
+ framebuffer control functions
+ *************************************************************/
 static inline void
 s1d13xxxfb_setup_pseudocolour(struct fb_info *info)
 {
@@ -242,13 +256,13 @@ s1d13xxxfb_set_par(struct fb_info *info)
 }
 
 /**
- *  	s1d13xxxfb_setcolreg - sets a color register.
- *      @regno: Which register in the CLUT we are programming
- *      @red: The red value which can be up to 16 bits wide
+ *	s1d13xxxfb_setcolreg - sets a color register.
+ *	@regno: Which register in the CLUT we are programming
+ *	@red: The red value which can be up to 16 bits wide
  *	@green: The green value which can be up to 16 bits wide
  *	@blue:  The blue value which can be up to 16 bits wide.
  *	@transp: If supported the alpha value which can be up to 16 bits wide.
- *      @info: frame buffer info structure
+ *	@info: frame buffer info structure
  *
  *	Returns negative errno on error, or zero on success.
  */
@@ -351,15 +365,15 @@ s1d13xxxfb_blank(int blank_mode, struct fb_info *info)
 }
 
 /**
- *      s1d13xxxfb_pan_display - Pans the display.
- *      @var: frame buffer variable screen structure
- *      @info: frame buffer structure that represents a single frame buffer
+ *	s1d13xxxfb_pan_display - Pans the display.
+ *	@var: frame buffer variable screen structure
+ *	@info: frame buffer structure that represents a single frame buffer
  *
  *	Pan (or wrap, depending on the `vmode' field) the display using the
- *  	`yoffset' field of the `var' structure (`xoffset'  not yet supported).
- *  	If the values don't fit, return -EINVAL.
+ *	`yoffset' field of the `var' structure (`xoffset'  not yet supported).
+ *	If the values don't fit, return -EINVAL.
  *
- *      Returns negative errno on error, or zero on success.
+ *	Returns negative errno on error, or zero on success.
  */
 static int
 s1d13xxxfb_pan_display(struct fb_var_screeninfo *var, struct fb_info *info)
@@ -390,8 +404,259 @@ s1d13xxxfb_pan_display(struct fb_var_screeninfo *var, struct fb_info *info)
 	return 0;
 }
 
-/* framebuffer information structures */
+/************************************************************
+ functions to handle bitblt acceleration
+ ************************************************************/
+
+/**
+ *	bltbit_wait_bitset - waits for change in register value
+ *	@info : framebuffer structure
+ *	@bit  : value expected in register
+ *	@timeout : ...
+ *
+ *	waits until value changes INTO bit
+ */
+static u8
+bltbit_wait_bitset(struct fb_info *info, u8 bit, int timeout)
+{
+	while (!(s1d13xxxfb_readreg(info->par, S1DREG_BBLT_CTL0) & bit)) {
+		udelay(10);
+		if (!--timeout) {
+			dbg_blit("wait_bitset timeout\n");
+			break;
+		}
+	}
+
+	return timeout;
+}
+
+/**
+ *	bltbit_wait_bitclear - waits for change in register value
+ *	@info : frambuffer structure
+ *	@bit  : value currently in register
+ *	@timeout : ...
+ *
+ *	waits until value changes FROM bit
+ *
+ */
+static u8
+bltbit_wait_bitclear(struct fb_info *info, u8 bit, int timeout)
+{
+	while (s1d13xxxfb_readreg(info->par, S1DREG_BBLT_CTL0) & bit) {
+		udelay(10);
+		if (!--timeout) {
+			dbg_blit("wait_bitclear timeout\n");
+			break;
+		}
+	}
+
+	return timeout;
+}
+
+/**
+ *	bltbit_fifo_status - checks the current status of the fifo
+ *	@info : framebuffer structure
+ *
+ *	returns number of free words in buffer
+ */
+static u8
+bltbit_fifo_status(struct fb_info *info)
+{
+	u8 status;
 
+	status = s1d13xxxfb_readreg(info->par, S1DREG_BBLT_CTL0);
+
+	/* its empty so room for 16 words */
+	if (status & BBLT_FIFO_EMPTY)
+		return 16;
+
+	/* its full so we dont want to add */
+	if (status & BBLT_FIFO_FULL)
+		return 0;
+
+	/* its atleast half full but we can add one atleast */
+	if (status & BBLT_FIFO_NOT_FULL)
+		return 1;
+
+	return 0;
+}
+
+/*
+ *	s1d13xxxfb_bitblt_copyarea - accelerated copyarea function
+ *	@info : framebuffer structure
+ *	@area : fb_copyarea structure
+ *
+ *	supports (atleast) S1D13506
+ *
+ */
+static void
+s1d13xxxfb_bitblt_copyarea(struct fb_info *info, const struct fb_copyarea *area)
+{
+	u32 dst, src;
+	u32 stride;
+	u16 reverse = 0;
+	u16 sx = area->sx, sy = area->sy;
+	u16 dx = area->dx, dy = area->dy;
+	u16 width = area->width, height = area->height;
+	u16 bpp;
+
+	spin_lock(&s1d13xxxfb_bitblt_lock);
+
+	/* bytes per xres line */
+	bpp = (info->var.bits_per_pixel >> 3);
+	stride = bpp * info->var.xres;
+
+	/* reverse, calculate the last pixel in rectangle */
+	if ((dy > sy) || ((dy == sy) && (dx >= sx))) {
+		dst = (((dy + height - 1) * stride) + (bpp * (dx + width - 1)));
+		src = (((sy + height - 1) * stride) + (bpp * (sx + width - 1)));
+		reverse = 1;
+	/* not reverse, calculate the first pixel in rectangle */
+	} else { /* (y * xres) + (bpp * x) */
+		dst = (dy * stride) + (bpp * dx);
+		src = (sy * stride) + (bpp * sx);
+	}
+
+	/* set source adress */
+	s1d13xxxfb_writereg(info->par, S1DREG_BBLT_SRC_START0, (src & 0xff));
+	s1d13xxxfb_writereg(info->par, S1DREG_BBLT_SRC_START1, (src >> 8) & 0x00ff);
+	s1d13xxxfb_writereg(info->par, S1DREG_BBLT_SRC_START2, (src >> 16) & 0x00ff);
+
+	/* set destination adress */
+	s1d13xxxfb_writereg(info->par, S1DREG_BBLT_DST_START0, (dst & 0xff));
+	s1d13xxxfb_writereg(info->par, S1DREG_BBLT_DST_START1, (dst >> 8) & 0x00ff);
+	s1d13xxxfb_writereg(info->par, S1DREG_BBLT_DST_START2, (dst >> 16) & 0x00ff);
+
+	/* program height and width */
+	s1d13xxxfb_writereg(info->par, S1DREG_BBLT_WIDTH0, (width & 0xff) - 1);
+	s1d13xxxfb_writereg(info->par, S1DREG_BBLT_WIDTH1, (width >> 8));
+
+	s1d13xxxfb_writereg(info->par, S1DREG_BBLT_HEIGHT0, (height & 0xff) - 1);
+	s1d13xxxfb_writereg(info->par, S1DREG_BBLT_HEIGHT1, (height >> 8));
+
+	/* negative direction ROP */
+	if (reverse == 1) {
+		dbg_blit("(copyarea) negative rop\n");
+		s1d13xxxfb_writereg(info->par, S1DREG_BBLT_OP, 0x03);
+	} else /* positive direction ROP */ {
+		s1d13xxxfb_writereg(info->par, S1DREG_BBLT_OP, 0x02);
+		dbg_blit("(copyarea) positive rop\n");
+	}
+
+	/* set for rectangel mode and not linear */
+	s1d13xxxfb_writereg(info->par, S1DREG_BBLT_CTL0, 0x0);
+
+	/* setup the bpp 1 = 16bpp, 0 = 8bpp*/
+	s1d13xxxfb_writereg(info->par, S1DREG_BBLT_CTL1, (bpp >> 1));
+
+	/* set words per xres */
+	s1d13xxxfb_writereg(info->par, S1DREG_BBLT_MEM_OFF0, (stride >> 1) & 0xff);
+	s1d13xxxfb_writereg(info->par, S1DREG_BBLT_MEM_OFF1, (stride >> 9));
+
+	dbg_blit("(copyarea) dx=%d, dy=%d\n", dx, dy);
+	dbg_blit("(copyarea) sx=%d, sy=%d\n", sx, sy);
+	dbg_blit("(copyarea) width=%d, height=%d\n", width - 1, height - 1);
+	dbg_blit("(copyarea) stride=%d\n", stride);
+	dbg_blit("(copyarea) bpp=%d=0x0%d, mem_offset1=%d, mem_offset2=%d\n", bpp, (bpp >> 1),
+		(stride >> 1) & 0xff, stride >> 9);
+
+	s1d13xxxfb_writereg(info->par, S1DREG_BBLT_CC_EXP, 0x0c);
+
+	/* initialize the engine */
+	s1d13xxxfb_writereg(info->par, S1DREG_BBLT_CTL0, 0x80);
+
+	/* wait to complete */
+	bltbit_wait_bitclear(info, 0x80, 8000);
+
+	spin_unlock(&s1d13xxxfb_bitblt_lock);
+}
+
+/**
+ *
+ *	s1d13xxxfb_bitblt_solidfill - accelerated solidfill function
+ *	@info : framebuffer structure
+ *	@rect : fb_fillrect structure
+ *
+ *	supports (atleast 13506)
+ *
+ **/
+static void
+s1d13xxxfb_bitblt_solidfill(struct fb_info *info, const struct fb_fillrect *rect)
+{
+	u32 screen_stride, dest;
+	u32 fg;
+	u16 bpp = (info->var.bits_per_pixel >> 3);
+
+	/* grab spinlock */
+	spin_lock(&s1d13xxxfb_bitblt_lock);
+
+	/* bytes per x width */
+	screen_stride = (bpp * info->var.xres);
+
+	/* bytes to starting point */
+	dest = ((rect->dy * screen_stride) + (bpp * rect->dx));
+
+	dbg_blit("(solidfill) dx=%d, dy=%d, stride=%d, dest=%d\n"
+		 "(solidfill) : rect_width=%d, rect_height=%d\n",
+				rect->dx, rect->dy, screen_stride, dest,
+				rect->width - 1, rect->height - 1);
+
+	dbg_blit("(solidfill) : xres=%d, yres=%d, bpp=%d\n",
+				info->var.xres, info->var.yres,
+				info->var.bits_per_pixel);
+	dbg_blit("(solidfill) : rop=%d\n", rect->rop);
+
+	/* We split the destination into the three registers */
+	s1d13xxxfb_writereg(info->par, S1DREG_BBLT_DST_START0, (dest & 0x00ff));
+	s1d13xxxfb_writereg(info->par, S1DREG_BBLT_DST_START1, ((dest >> 8) & 0x00ff));
+	s1d13xxxfb_writereg(info->par, S1DREG_BBLT_DST_START2, ((dest >> 16) & 0x00ff));
+
+	/* give information regarding rectangel width */
+	s1d13xxxfb_writereg(info->par, S1DREG_BBLT_WIDTH0, ((rect->width) & 0x00ff) - 1);
+	s1d13xxxfb_writereg(info->par, S1DREG_BBLT_WIDTH1, (rect->width >> 8));
+
+	/* give information regarding rectangel height */
+	s1d13xxxfb_writereg(info->par, S1DREG_BBLT_HEIGHT0, ((rect->height) & 0x00ff) - 1);
+	s1d13xxxfb_writereg(info->par, S1DREG_BBLT_HEIGHT1, (rect->height >> 8));
+
+	if (info->fix.visual == FB_VISUAL_TRUECOLOR ||
+		info->fix.visual == FB_VISUAL_DIRECTCOLOR) {
+		fg = ((u32 *)info->pseudo_palette)[rect->color];
+		dbg_blit("(solidfill) truecolor/directcolor\n");
+		dbg_blit("(solidfill) pseudo_palette[%d] = %d\n", rect->color, fg);
+	} else {
+		fg = rect->color;
+		dbg_blit("(solidfill) color = %d\n", rect->color);
+	}
+
+	/* set foreground color */
+	s1d13xxxfb_writereg(info->par, S1DREG_BBLT_FGC0, (fg & 0xff));
+	s1d13xxxfb_writereg(info->par, S1DREG_BBLT_FGC1, (fg >> 8) & 0xff);
+
+	/* set rectangual region of memory (rectangle and not linear) */
+	s1d13xxxfb_writereg(info->par, S1DREG_BBLT_CTL0, 0x0);
+
+	/* set operation mode SOLID_FILL */
+	s1d13xxxfb_writereg(info->par, S1DREG_BBLT_OP, BBLT_SOLID_FILL);
+
+	/* set bits per pixel (1 = 16bpp, 0 = 8bpp) */
+	s1d13xxxfb_writereg(info->par, S1DREG_BBLT_CTL1, (info->var.bits_per_pixel >> 4));
+
+	/* set the memory offset for the bblt in word sizes */
+	s1d13xxxfb_writereg(info->par, S1DREG_BBLT_MEM_OFF0, (screen_stride >> 1) & 0x00ff);
+	s1d13xxxfb_writereg(info->par, S1DREG_BBLT_MEM_OFF1, (screen_stride >> 9));
+
+	/* and away we go.... */
+	s1d13xxxfb_writereg(info->par, S1DREG_BBLT_CTL0, 0x80);
+
+	/* wait until its done */
+	bltbit_wait_bitclear(info, 0x80, 8000);
+
+	/* let others play */
+	spin_unlock(&s1d13xxxfb_bitblt_lock);
+}
+
+/* framebuffer information structures */
 static struct fb_ops s1d13xxxfb_fbops = {
 	.owner		= THIS_MODULE,
 	.fb_set_par	= s1d13xxxfb_set_par,
@@ -400,7 +665,7 @@ static struct fb_ops s1d13xxxfb_fbops = {
 
 	.fb_pan_display	= s1d13xxxfb_pan_display,
 
-	/* to be replaced by any acceleration we can */
+	/* gets replaced at chip detection time */
 	.fb_fillrect	= cfb_fillrect,
 	.fb_copyarea	= cfb_copyarea,
 	.fb_imageblit	= cfb_imageblit,
@@ -412,9 +677,9 @@ static int s1d13xxxfb_width_tab[2][4] __devinitdata = {
 };
 
 /**
- *      s1d13xxxfb_fetch_hw_state - Configure the framebuffer according to
+ *	s1d13xxxfb_fetch_hw_state - Configure the framebuffer according to
  *	hardware setup.
- *      @info: frame buffer structure
+ *	@info: frame buffer structure
  *
  *	We setup the framebuffer structures according to the current
  *	hardware setup. On some machines, the BIOS will have filled
@@ -569,7 +834,6 @@ s1d13xxxfb_probe(struct platform_device *pdev)
 	if (pdata && pdata->platform_init_video)
 		pdata->platform_init_video();
 
-
 	if (pdev->num_resources != 2) {
 		dev_err(&pdev->dev, "invalid num_resources: %i\n",
 		       pdev->num_resources);
@@ -655,16 +919,27 @@ s1d13xxxfb_probe(struct platform_device *pdev)
 
 	info->fix = s1d13xxxfb_fix;
 	info->fix.mmio_start = pdev->resource[1].start;
-	info->fix.mmio_len = pdev->resource[1].end - pdev->resource[1].start +1;
+	info->fix.mmio_len = pdev->resource[1].end - pdev->resource[1].start + 1;
 	info->fix.smem_start = pdev->resource[0].start;
-	info->fix.smem_len = pdev->resource[0].end - pdev->resource[0].start +1;
+	info->fix.smem_len = pdev->resource[0].end - pdev->resource[0].start + 1;
 
 	printk(KERN_INFO PFX "regs mapped at 0x%p, fb %d KiB mapped at 0x%p\n",
 	       default_par->regs, info->fix.smem_len / 1024, info->screen_base);
 
 	info->par = default_par;
-	info->fbops = &s1d13xxxfb_fbops;
 	info->flags = FBINFO_DEFAULT | FBINFO_HWACCEL_YPAN;
+	info->fbops = &s1d13xxxfb_fbops;
+
+	switch(prod_id) {
+	    case S1D13506_PROD_ID : /* activate acceleration */
+		s1d13xxxfb_fbops.fb_fillrect = s1d13xxxfb_bitblt_solidfill;
+		s1d13xxxfb_fbops.fb_copyarea = s1d13xxxfb_bitblt_copyarea;
+		info->flags = FBINFO_DEFAULT | FBINFO_HWACCEL_YPAN |
+			FBINFO_HWACCEL_FILLRECT | FBINFO_HWACCEL_COPYAREA;
+		break;
+	    default :
+		break;
+	}
 
 	/* perform "manual" chip initialization, if needed */
 	if (pdata && pdata->initregs)



-- 
Kristoffer Ericson <kri...@gm...>

Re: [Linux-fbdev-devel] [PATCH] fb: add support for handoff from firmware to hw framebuffers (v2)

[Andrew M. <ak...@li...>]

On Sat, 6 Jun 2009 11:38:32 +1000 Dave Airlie <ai...@gm...> wrote:

> On Fri, Jun 5, 2009 at 11:51 PM, Peter Jones<pj...@re...> wrote:
> > On 06/05/2009 02:07 AM, Dave Airlie wrote:
> >> From: Dave Airlie <ai...@re...>
> >>
> >> With KMS we have ran into an issue where we really want the KMS fb driver
> >> to be the one running the console, so panics etc can be shown by switching
> >> out of X etc.
> >>
> >> However with vesafb/efifb built-in, we end up with those on fb0 and the
> >> KMS fb driver on fb1, driving the same piece of hw, so this adds an fb info
> >> flag to denote a firmware fbdev, and adds a new aperture base/size range
> >> which can be compared when the hw drivers are installed to see if there
> >> is a conflict with a firmware driver, and if there is the firmware driver is
> >> unregistered and the hw driver takes over.
> >>
> >> It uses new aperture_base/size members instead of comparing on the fix
> >> smem_start/length, as smem_start/length might for example only cover the
> >> first 1MB of the PCI aperture, and we could allocate the kms fb from 8MB
> >> into the aperture, thus they would never overlap.
> >>
> >> v2: add an fb_destroy callback so the firmware fb can cleanup after itself.
> >> vesafb will now remove the region it reserves and destroy its fb info.
> >>
> >> Signed-off-by: Dave Airlie <ai...@re...>
> >
> > This version looks good to me.
> >
> > Acked-by: Peter Jones <pj...@re...>
> >
> 
> Andrew do we have an fbdev maintainer

Tony suddenly vanished nearly two years ago.  He did that once before,
then resurfaced after six months - he'd been working in a remote
village with no net connection.  Hopefully he will reappear again.

In the meanwhile I'm handling fbdev patches and Geert and Krzysztof are
doing the technical work when time permits.  I'll occasionally troll
linux-fbdev-devel looking for patches which people send.

> or can you pick this up for the next merge window?

No probs.

Re: [Linux-fbdev-devel] [PATCH] fb: add support for handoff from firmware to hw framebuffers (v2)

[Dave A. <ai...@gm...>]

On Fri, Jun 5, 2009 at 11:51 PM, Peter Jones<pj...@re...> wrote:
> On 06/05/2009 02:07 AM, Dave Airlie wrote:
>> From: Dave Airlie <ai...@re...>
>>
>> With KMS we have ran into an issue where we really want the KMS fb driver
>> to be the one running the console, so panics etc can be shown by switching
>> out of X etc.
>>
>> However with vesafb/efifb built-in, we end up with those on fb0 and the
>> KMS fb driver on fb1, driving the same piece of hw, so this adds an fb info
>> flag to denote a firmware fbdev, and adds a new aperture base/size range
>> which can be compared when the hw drivers are installed to see if there
>> is a conflict with a firmware driver, and if there is the firmware driver is
>> unregistered and the hw driver takes over.
>>
>> It uses new aperture_base/size members instead of comparing on the fix
>> smem_start/length, as smem_start/length might for example only cover the
>> first 1MB of the PCI aperture, and we could allocate the kms fb from 8MB
>> into the aperture, thus they would never overlap.
>>
>> v2: add an fb_destroy callback so the firmware fb can cleanup after itself.
>> vesafb will now remove the region it reserves and destroy its fb info.
>>
>> Signed-off-by: Dave Airlie <ai...@re...>
>
> This version looks good to me.
>
> Acked-by: Peter Jones <pj...@re...>
>

Andrew do we have an fbdev maintainer or can you pick this up for the
next merge window?

Dave.

[Linux-fbdev-devel] True color framebuffer

[amaora <nem...@ra...>]

Hi,

I write framebuffer driver for the PCF8833, it work, but only if
xxx_fix.visual == FB_VISUAL_PSEUDOCOLOR, TRUECOLOR/DIRECTCOLOR don't work.
Kernel is blocked (stalled) in function register_framebuffer on line
fb_notifier_call_chain(...), i don't know how to find stall point more deep.
Why this happening?

Thanks,

Roman Belov

Re: [Linux-fbdev-devel] patch - bitblt 2D acceleration for s1d13xxxfb

[Andrew M. <ak...@li...>]

On Fri, 5 Jun 2009 19:38:53 +0200
Kristoffer Ericson <kri...@gm...> wrote:

> Greetings,
> 
> Just wanted some feedback since this patch is quite large. Any comments are
> appreciated. It patches, compiles and runs like a fox on fire.

we like firey foxes.

> This patch:
> enables 2D rectfill and copyarea acceleration for 13506, need to look
> at hardware sheets before I can say it works on other version but at minimal
> 13806.
> 
> Also some cleans up the code.
> 
>
> ...
>
> +/**
> + * we make sure only one bitblt operation is running
> + */
> +static DEFINE_SPINLOCK(s1d13xxxfb_bitblt_lock);
> +
> +/**
> + * list of card production ids
>   */
>  static const int s1d13xxxfb_prod_ids[] = {
>  	S1D13505_PROD_ID,
> @@ -59,7 +71,7 @@ static const int s1d13xxxfb_prod_ids[] = {
>  	S1D13806_PROD_ID,
>  };
>  
> -/*
> +/**
>   * List of card strings
>   */
>  static const char *s1d13xxxfb_prod_names[] = {
> @@ -68,8 +80,8 @@ static const char *s1d13xxxfb_prod_names[] = {
>  	"S1D13806",
>  };
>  
> -/*
> - * Here we define the default struct fb_fix_screeninfo
> +/**
> + * here we define the default struct fb_fix_screeninfo
>   */

The /** token is reserved for introducing a kerneldoc-formatted
comment, but none of the above three comments are kerneldoc comments.

> +/**
> + *	bltbit_wait_bitset - waits for change in register value
> + *	@info : framebuffer structure
> + *	@bit  : value expected in register
> + *	@timeout : ...
> + *
> + *	waits until value changes INTO bit
> + */

That one is kerneldoc.

> +u8 bltbit_wait_bitset(struct fb_info *info, u8 bit, int timeout)

The patch adds lots of global functions.  Please make symbols static
where possible.

> +{
> +	while (!(s1d13xxxfb_readreg(info->par, S1DREG_BBLT_CTL0) & bit)) {
> +		udelay(10);
> +		if (!--timeout) {
> +			dbg_blit("wait_bitset timeout\n");
> +			break;
> +		}
> +	}
> +
> +	return timeout;
> +}
> +
>
> ...
>

It otherwise looks OK to my inexpert eye.

[Linux-fbdev-devel] patch - bitblt 2D acceleration for s1d13xxxfb

[Kristoffer E. <kri...@gm...>]

Greetings,

Just wanted some feedback since this patch is quite large. Any comments are
appreciated. It patches, compiles and runs like a fox on fire.

This patch:
enables 2D rectfill and copyarea acceleration for 13506, need to look
at hardware sheets before I can say it works on other version but at minimal
13806.

Also some cleans up the code.

Will give a more detailed patchlog once the comments die down :)

diff --git a/drivers/video/s1d13xxxfb.c b/drivers/video/s1d13xxxfb.c
index 0726aec..49c96d2 100644
--- a/drivers/video/s1d13xxxfb.c
+++ b/drivers/video/s1d13xxxfb.c
@@ -2,6 +2,7 @@
  *
  * (c) 2004 Simtec Electronics
  * (c) 2005 Thibaut VARENE <va...@pa...>
+ * (c) 2009 Kristoffer Ericson <kri...@gm...>
  *
  * Driver for Epson S1D13xxx series framebuffer chips
  *
@@ -10,18 +11,10 @@
  *  linux/drivers/video/epson1355fb.c
  *  linux/drivers/video/epson/s1d13xxxfb.c (2.4 driver by Epson)
  *
- * Note, currently only tested on S1D13806 with 16bit CRT.
- * As such, this driver might still contain some hardcoded bits relating to
- * S1D13806.
- * Making it work on other S1D13XXX chips should merely be a matter of adding
- * a few switch()s, some missing glue here and there maybe, and split header
- * files.
- *
  * TODO: - handle dual screen display (CRT and LCD at the same time).
  *	 - check_var(), mode change, etc.
- *	 - PM untested.
- *	 - Accelerated interfaces.
- *	 - Probably not SMP safe :)
+ *	 - probably not SMP safe :)
+ *       - support all bitblt operations on all cards
  *
  * This file is subject to the terms and conditions of the GNU General Public
  * License. See the file COPYING in the main directory of this archive for
@@ -31,27 +24,46 @@
 #include <linux/module.h>
 #include <linux/platform_device.h>
 #include <linux/delay.h>
-
 #include <linux/types.h>
 #include <linux/errno.h>
 #include <linux/mm.h>
 #include <linux/mman.h>
 #include <linux/fb.h>
+#include <linux/spinlock_types.h>
+#include <linux/spinlock.h>
 
 #include <asm/io.h>
 
 #include <video/s1d13xxxfb.h>
 
-#define PFX "s1d13xxxfb: "
+#define PFX	"s1d13xxxfb: "
+#define BLIT	"s1d13xxxfb_bitblt: "
 
+/**
+ * set this to enable debugging on general functions
+ */
 #if 0
 #define dbg(fmt, args...) do { printk(KERN_INFO fmt, ## args); } while(0)
 #else
 #define dbg(fmt, args...) do { } while (0)
 #endif
 
-/*
- * List of card production ids
+/**
+ * set this to enable debugging on 2D acceleration
+ */
+#if 0
+#define dbg_blit(fmt, args...) do {printk(KERN_INFO BLIT fmt, ## args); } while(0)
+#else
+#define dbg_blit(fmt, args...) do { } while (0)
+#endif
+
+/**
+ * we make sure only one bitblt operation is running
+ */
+static DEFINE_SPINLOCK(s1d13xxxfb_bitblt_lock);
+
+/**
+ * list of card production ids
  */
 static const int s1d13xxxfb_prod_ids[] = {
 	S1D13505_PROD_ID,
@@ -59,7 +71,7 @@ static const int s1d13xxxfb_prod_ids[] = {
 	S1D13806_PROD_ID,
 };
 
-/*
+/**
  * List of card strings
  */
 static const char *s1d13xxxfb_prod_names[] = {
@@ -68,8 +80,8 @@ static const char *s1d13xxxfb_prod_names[] = {
 	"S1D13806",
 };
 
-/*
- * Here we define the default struct fb_fix_screeninfo
+/**
+ * here we define the default struct fb_fix_screeninfo
  */
 static struct fb_fix_screeninfo __devinitdata s1d13xxxfb_fix = {
 	.id		= S1D_FBID,
@@ -145,8 +157,10 @@ crt_enable(struct s1d13xxxfb_par *par, int enable)
 	s1d13xxxfb_writereg(par, S1DREG_COM_DISP_MODE, mode);
 }
 
-/* framebuffer control routines */
 
+/*************************************************************
+ framebuffer control functions
+ *************************************************************/
 static inline void
 s1d13xxxfb_setup_pseudocolour(struct fb_info *info)
 {
@@ -242,13 +256,13 @@ s1d13xxxfb_set_par(struct fb_info *info)
 }
 
 /**
- *  	s1d13xxxfb_setcolreg - sets a color register.
- *      @regno: Which register in the CLUT we are programming
- *      @red: The red value which can be up to 16 bits wide
+ *	s1d13xxxfb_setcolreg - sets a color register.
+ *	@regno: Which register in the CLUT we are programming
+ *	@red: The red value which can be up to 16 bits wide
  *	@green: The green value which can be up to 16 bits wide
  *	@blue:  The blue value which can be up to 16 bits wide.
  *	@transp: If supported the alpha value which can be up to 16 bits wide.
- *      @info: frame buffer info structure
+ *	@info: frame buffer info structure
  *
  *	Returns negative errno on error, or zero on success.
  */
@@ -351,15 +365,15 @@ s1d13xxxfb_blank(int blank_mode, struct fb_info *info)
 }
 
 /**
- *      s1d13xxxfb_pan_display - Pans the display.
- *      @var: frame buffer variable screen structure
- *      @info: frame buffer structure that represents a single frame buffer
+ *	s1d13xxxfb_pan_display - Pans the display.
+ *	@var: frame buffer variable screen structure
+ *	@info: frame buffer structure that represents a single frame buffer
  *
  *	Pan (or wrap, depending on the `vmode' field) the display using the
- *  	`yoffset' field of the `var' structure (`xoffset'  not yet supported).
- *  	If the values don't fit, return -EINVAL.
+ *	`yoffset' field of the `var' structure (`xoffset'  not yet supported).
+ *	If the values don't fit, return -EINVAL.
  *
- *      Returns negative errno on error, or zero on success.
+ *	Returns negative errno on error, or zero on success.
  */
 static int
 s1d13xxxfb_pan_display(struct fb_var_screeninfo *var, struct fb_info *info)
@@ -390,8 +404,254 @@ s1d13xxxfb_pan_display(struct fb_var_screeninfo *var, struct fb_info *info)
 	return 0;
 }
 
-/* framebuffer information structures */
+/************************************************************
+ functions to handle bitblt acceleration
+ ************************************************************/
+
+/**
+ *	bltbit_wait_bitset - waits for change in register value
+ *	@info : framebuffer structure
+ *	@bit  : value expected in register
+ *	@timeout : ...
+ *
+ *	waits until value changes INTO bit
+ */
+u8 bltbit_wait_bitset(struct fb_info *info, u8 bit, int timeout)
+{
+	while (!(s1d13xxxfb_readreg(info->par, S1DREG_BBLT_CTL0) & bit)) {
+		udelay(10);
+		if (!--timeout) {
+			dbg_blit("wait_bitset timeout\n");
+			break;
+		}
+	}
+
+	return timeout;
+}
+
+/**
+ *	bltbit_wait_bitclear - waits for change in register value
+ *	@info : frambuffer structure
+ *	@bit  : value currently in register
+ *	@timeout : ...
+ *
+ *	waits until value changes FROM bit
+ *
+ */
+u8 bltbit_wait_bitclear(struct fb_info *info, u8 bit, int timeout)
+{
+	while (s1d13xxxfb_readreg(info->par, S1DREG_BBLT_CTL0) & bit) {
+		udelay(10);
+		if (!--timeout) {
+			dbg_blit("wait_bitclear timeout\n");
+			break;
+		}
+	}
+
+	return timeout;
+}
+
+/**
+ *	bltbit_fifo_status - checks the current status of the fifo
+ *	@info : framebuffer structure
+ *
+ *	returns number of free words in buffer
+ */
+u8 bltbit_fifo_status(struct fb_info *info)
+{
+	u8 status;
 
+	status = s1d13xxxfb_readreg(info->par, S1DREG_BBLT_CTL0);
+
+	/* its empty so room for 16 words */
+	if (status & BBLT_FIFO_EMPTY)
+		return 16;
+
+	/* its full so we dont want to add */
+	if (status & BBLT_FIFO_FULL)
+		return 0;
+
+	/* its atleast half full but we can add one atleast */
+	if (status & BBLT_FIFO_NOT_FULL)
+		return 1;
+
+	return 0;
+}
+
+/*
+ *	s1d13xxxfb_bitblt_copyarea - accelerated copyarea function
+ *	@info : framebuffer structure
+ *	@area : fb_copyarea structure
+ *
+ *	supports (atleast) S1D13506
+ *
+ */
+void s1d13xxxfb_bitblt_copyarea(struct fb_info *info, const struct fb_copyarea *area)
+{
+	u32 dst, src;
+	u32 stride;
+	u16 reverse = 0;
+	u16 sx = area->sx, sy = area->sy;
+	u16 dx = area->dx, dy = area->dy;
+	u16 width = area->width, height = area->height;
+	u16 bpp;
+
+	spin_lock(&s1d13xxxfb_bitblt_lock);
+
+	/* bytes per xres line */
+	bpp = (info->var.bits_per_pixel >> 3);
+	stride = bpp * info->var.xres;
+
+	/* reverse, calculate the last pixel in rectangle */
+	if ((dy > sy) || ((dy == sy) && (dx >= sx))) {
+		dst = (((dy + height - 1) * stride) + (bpp * (dx + width - 1)));
+		src = (((sy + height - 1) * stride) + (bpp * (sx + width - 1)));
+		reverse = 1;
+	/* not reverse, calculate the first pixel in rectangle */
+	} else { /* (y * xres) + (bpp * x) */
+		dst = (dy * stride) + (bpp * dx);
+		src = (sy * stride) + (bpp * sx);
+	}
+
+	/* set source adress */
+	s1d13xxxfb_writereg(info->par, S1DREG_BBLT_SRC_START0, (src & 0xff));
+	s1d13xxxfb_writereg(info->par, S1DREG_BBLT_SRC_START1, (src >> 8) & 0x00ff);
+	s1d13xxxfb_writereg(info->par, S1DREG_BBLT_SRC_START2, (src >> 16) & 0x00ff);
+
+	/* set destination adress */
+	s1d13xxxfb_writereg(info->par, S1DREG_BBLT_DST_START0, (dst & 0xff));
+	s1d13xxxfb_writereg(info->par, S1DREG_BBLT_DST_START1, (dst >> 8) & 0x00ff);
+	s1d13xxxfb_writereg(info->par, S1DREG_BBLT_DST_START2, (dst >> 16) & 0x00ff);
+
+	/* program height and width */
+	s1d13xxxfb_writereg(info->par, S1DREG_BBLT_WIDTH0, (width & 0xff) - 1);
+	s1d13xxxfb_writereg(info->par, S1DREG_BBLT_WIDTH1, (width >> 8));
+
+	s1d13xxxfb_writereg(info->par, S1DREG_BBLT_HEIGHT0, (height & 0xff) - 1);
+	s1d13xxxfb_writereg(info->par, S1DREG_BBLT_HEIGHT1, (height >> 8));
+
+	/* negative direction ROP */
+	if (reverse == 1) {
+		dbg_blit("(copyarea) negative rop\n");
+		s1d13xxxfb_writereg(info->par, S1DREG_BBLT_OP, 0x03);
+	} else /* positive direction ROP */ {
+		s1d13xxxfb_writereg(info->par, S1DREG_BBLT_OP, 0x02);
+		dbg_blit("(copyarea) positive rop\n");
+	}
+
+	/* set for rectangel mode and not linear */
+	s1d13xxxfb_writereg(info->par, S1DREG_BBLT_CTL0, 0x0);
+
+	/* setup the bpp 1 = 16bpp, 0 = 8bpp*/
+	s1d13xxxfb_writereg(info->par, S1DREG_BBLT_CTL1, (bpp >> 1));
+
+	/* set words per xres */
+	s1d13xxxfb_writereg(info->par, S1DREG_BBLT_MEM_OFF0, (stride >> 1) & 0xff);
+	s1d13xxxfb_writereg(info->par, S1DREG_BBLT_MEM_OFF1, (stride >> 9));
+
+	dbg_blit("(copyarea) dx=%d, dy=%d\n", dx, dy);
+	dbg_blit("(copyarea) sx=%d, sy=%d\n", sx, sy);
+	dbg_blit("(copyarea) width=%d, height=%d\n", width - 1, height - 1);
+	dbg_blit("(copyarea) stride=%d\n", stride);
+	dbg_blit("(copyarea) bpp=%d=0x0%d, mem_offset1=%d, mem_offset2=%d\n", bpp, (bpp >> 1),
+		(stride >> 1) & 0xff, stride >> 9);
+
+	s1d13xxxfb_writereg(info->par, S1DREG_BBLT_CC_EXP, 0x0c);
+
+	/* initialize the engine */
+	s1d13xxxfb_writereg(info->par, S1DREG_BBLT_CTL0, 0x80);
+
+	/* wait to complete */
+	bltbit_wait_bitclear(info, 0x80, 8000);
+
+	spin_unlock(&s1d13xxxfb_bitblt_lock);
+}
+
+/**
+ *
+ *	s1d13xxxfb_bitblt_solidfill - accelerated solidfill function
+ *	@info : framebuffer structure
+ *	@rect : fb_fillrect structure
+ *
+ *	supports (atleast 13506)
+ *
+ **/
+void s1d13xxxfb_bitblt_solidfill(struct fb_info *info, const struct fb_fillrect *rect)
+{
+	u32 screen_stride, dest;
+	u32 fg;
+	u16 bpp = (info->var.bits_per_pixel >> 3);
+
+	/* grab spinlock */
+	spin_lock(&s1d13xxxfb_bitblt_lock);
+
+	/* bytes per x width */
+	screen_stride = (bpp * info->var.xres);
+
+	/* bytes to starting point */
+	dest = ((rect->dy * screen_stride) + (bpp * rect->dx));
+
+	dbg_blit("(solidfill) dx=%d, dy=%d, stride=%d, dest=%d\n"
+		 "(solidfill) : rect_width=%d, rect_height=%d\n",
+				rect->dx, rect->dy, screen_stride, dest,
+				rect->width - 1, rect->height - 1);
+
+	dbg_blit("(solidfill) : xres=%d, yres=%d, bpp=%d\n",
+				info->var.xres, info->var.yres,
+				info->var.bits_per_pixel);
+	dbg_blit("(solidfill) : rop=%d\n", rect->rop);
+
+	/* We split the destination into the three registers */
+	s1d13xxxfb_writereg(info->par, S1DREG_BBLT_DST_START0, (dest & 0x00ff));
+	s1d13xxxfb_writereg(info->par, S1DREG_BBLT_DST_START1, ((dest >> 8) & 0x00ff));
+	s1d13xxxfb_writereg(info->par, S1DREG_BBLT_DST_START2, ((dest >> 16) & 0x00ff));
+
+	/* give information regarding rectangel width */
+	s1d13xxxfb_writereg(info->par, S1DREG_BBLT_WIDTH0, ((rect->width) & 0x00ff) - 1);
+	s1d13xxxfb_writereg(info->par, S1DREG_BBLT_WIDTH1, (rect->width >> 8));
+
+	/* give information regarding rectangel height */
+	s1d13xxxfb_writereg(info->par, S1DREG_BBLT_HEIGHT0, ((rect->height) & 0x00ff) - 1);
+	s1d13xxxfb_writereg(info->par, S1DREG_BBLT_HEIGHT1, (rect->height >> 8));
+
+	if (info->fix.visual == FB_VISUAL_TRUECOLOR ||
+		info->fix.visual == FB_VISUAL_DIRECTCOLOR) {
+		fg = ((u32 *)info->pseudo_palette)[rect->color];
+		dbg_blit("(solidfill) truecolor/directcolor\n");
+		dbg_blit("(solidfill) pseudo_palette[%d] = %d\n", rect->color, fg);
+	} else {
+		fg = rect->color;
+		dbg_blit("(solidfill) color = %d\n", rect->color);
+	}
+
+	/* set foreground color */
+	s1d13xxxfb_writereg(info->par, S1DREG_BBLT_FGC0, (fg & 0xff));
+	s1d13xxxfb_writereg(info->par, S1DREG_BBLT_FGC1, (fg >> 8) & 0xff);
+
+	/* set rectangual region of memory (rectangle and not linear) */
+	s1d13xxxfb_writereg(info->par, S1DREG_BBLT_CTL0, 0x0);
+
+	/* set operation mode SOLID_FILL */
+	s1d13xxxfb_writereg(info->par, S1DREG_BBLT_OP, BBLT_SOLID_FILL);
+
+	/* set bits per pixel (1 = 16bpp, 0 = 8bpp) */
+	s1d13xxxfb_writereg(info->par, S1DREG_BBLT_CTL1, (info->var.bits_per_pixel >> 4));
+
+	/* set the memory offset for the bblt in word sizes */
+	s1d13xxxfb_writereg(info->par, S1DREG_BBLT_MEM_OFF0, (screen_stride >> 1) & 0x00ff);
+	s1d13xxxfb_writereg(info->par, S1DREG_BBLT_MEM_OFF1, (screen_stride >> 9));
+
+	/* and away we go.... */
+	s1d13xxxfb_writereg(info->par, S1DREG_BBLT_CTL0, 0x80);
+
+	/* wait until its done */
+	bltbit_wait_bitclear(info, 0x80, 8000);
+
+	/* let others play */
+	spin_unlock(&s1d13xxxfb_bitblt_lock);
+}
+
+/* framebuffer information structures */
 static struct fb_ops s1d13xxxfb_fbops = {
 	.owner		= THIS_MODULE,
 	.fb_set_par	= s1d13xxxfb_set_par,
@@ -400,7 +660,7 @@ static struct fb_ops s1d13xxxfb_fbops = {
 
 	.fb_pan_display	= s1d13xxxfb_pan_display,
 
-	/* to be replaced by any acceleration we can */
+	/* gets replaced at chip detection time */
 	.fb_fillrect	= cfb_fillrect,
 	.fb_copyarea	= cfb_copyarea,
 	.fb_imageblit	= cfb_imageblit,
@@ -412,9 +672,9 @@ static int s1d13xxxfb_width_tab[2][4] __devinitdata = {
 };
 
 /**
- *      s1d13xxxfb_fetch_hw_state - Configure the framebuffer according to
+ *	s1d13xxxfb_fetch_hw_state - Configure the framebuffer according to
  *	hardware setup.
- *      @info: frame buffer structure
+ *	@info: frame buffer structure
  *
  *	We setup the framebuffer structures according to the current
  *	hardware setup. On some machines, the BIOS will have filled
@@ -569,7 +829,6 @@ s1d13xxxfb_probe(struct platform_device *pdev)
 	if (pdata && pdata->platform_init_video)
 		pdata->platform_init_video();
 
-
 	if (pdev->num_resources != 2) {
 		dev_err(&pdev->dev, "invalid num_resources: %i\n",
 		       pdev->num_resources);
@@ -655,16 +914,27 @@ s1d13xxxfb_probe(struct platform_device *pdev)
 
 	info->fix = s1d13xxxfb_fix;
 	info->fix.mmio_start = pdev->resource[1].start;
-	info->fix.mmio_len = pdev->resource[1].end - pdev->resource[1].start +1;
+	info->fix.mmio_len = pdev->resource[1].end - pdev->resource[1].start + 1;
 	info->fix.smem_start = pdev->resource[0].start;
-	info->fix.smem_len = pdev->resource[0].end - pdev->resource[0].start +1;
+	info->fix.smem_len = pdev->resource[0].end - pdev->resource[0].start + 1;
 
 	printk(KERN_INFO PFX "regs mapped at 0x%p, fb %d KiB mapped at 0x%p\n",
 	       default_par->regs, info->fix.smem_len / 1024, info->screen_base);
 
 	info->par = default_par;
-	info->fbops = &s1d13xxxfb_fbops;
 	info->flags = FBINFO_DEFAULT | FBINFO_HWACCEL_YPAN;
+	info->fbops = &s1d13xxxfb_fbops;
+
+	switch(prod_id) {
+	    case S1D13506_PROD_ID : /* activate acceleration */
+		s1d13xxxfb_fbops.fb_fillrect = s1d13xxxfb_bitblt_solidfill;
+		s1d13xxxfb_fbops.fb_copyarea = s1d13xxxfb_bitblt_copyarea;
+		info->flags = FBINFO_DEFAULT | FBINFO_HWACCEL_YPAN |
+			FBINFO_HWACCEL_FILLRECT | FBINFO_HWACCEL_COPYAREA;
+		break;
+	    default :
+		break;
+	}
 
 	/* perform "manual" chip initialization, if needed */
 	if (pdata && pdata->initregs)


Best wishes
Kristoffer Ericson

-- 
Kristoffer Ericson <kri...@gm...>

Re: [Linux-fbdev-devel] [PATCH 04/20] omapfb: Add support for the Amstrad Delta LCD

[Jonathan M. <no...@ea...>]

On Fri, Jun 05, 2009 at 12:38:22PM +0200, Janusz Krzysztofik wrote:
> Thursday 04 June 2009 19:52:29 Imre Deak napisał(a):
> > From: Jonathan McDowell <no...@ea...>
> >
> > This is an updated version of the LCD driver for the Amstrad Delta to
> > take into account the recent changes to the omapfb infrastructure. The
> > Delta features a 480x320 12 bit DSTN panel.
> 
> I'd really love to see the lcd_ams_delta support included in the mainline 
> kernel, but I am not sure if it is ready for submission, as I still have 
> issues with it. It does work perfectly unless power management is turned on.
> With CONFIG_PM=y, the omapfb device, after initially starting correctly, 
> breaks with the following error messages:
> 
> omapfb omapfb: resetting (status 0xffffff96,reset count 1)
> ...
> omapfb omapfb: resetting (status 0xffffff96,reset count 100)
> omapfb omapfb: too many reset attempts, giving up.
> 
> Tested with linux-2.6.30-rc5 and linux-omap revision 
> 90e758af52ba803cba233fabee81176d99589f09. Error messages do not appear when 
> CONFIG_PM=n or lcd_ams_delta.o is removed from omapfb-objs.
> 
> Please let me know what else I can do to help in resolving this issue.
 
Reporting it was a good start; it's the first I've heard of this issue.
Looking at the E3 configs I have lying around it looks like none of them
have CONFIG_PM set, so it's possible most people have just been using
the defconfig or a minor variation of it. I don't have my E3 convenient
at present to investigate however.

J.

-- 
101 things you can't have too much of : 14 - Paperclips.

Re: [Linux-fbdev-devel] [PATCH] fb: add support for handoff from firmware to hw framebuffers (v2)

[Peter J. <pj...@re...>]

On 06/05/2009 02:07 AM, Dave Airlie wrote:
> From: Dave Airlie <ai...@re...>
> 
> With KMS we have ran into an issue where we really want the KMS fb driver
> to be the one running the console, so panics etc can be shown by switching
> out of X etc.
> 
> However with vesafb/efifb built-in, we end up with those on fb0 and the
> KMS fb driver on fb1, driving the same piece of hw, so this adds an fb info
> flag to denote a firmware fbdev, and adds a new aperture base/size range
> which can be compared when the hw drivers are installed to see if there
> is a conflict with a firmware driver, and if there is the firmware driver is
> unregistered and the hw driver takes over.
> 
> It uses new aperture_base/size members instead of comparing on the fix
> smem_start/length, as smem_start/length might for example only cover the
> first 1MB of the PCI aperture, and we could allocate the kms fb from 8MB
> into the aperture, thus they would never overlap.
> 
> v2: add an fb_destroy callback so the firmware fb can cleanup after itself.
> vesafb will now remove the region it reserves and destroy its fb info.
> 
> Signed-off-by: Dave Airlie <ai...@re...>

This version looks good to me.

Acked-by: Peter Jones <pj...@re...>

> ---
>  drivers/gpu/drm/i915/intel_fb.c |    8 ++++++++
>  drivers/video/efifb.c           |    5 ++++-
>  drivers/video/fbmem.c           |   29 +++++++++++++++++++++++++++++
>  drivers/video/vesafb.c          |   15 ++++++++++++++-
>  include/linux/fb.h              |   12 +++++++++++-
>  5 files changed, 66 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_fb.c b/drivers/gpu/drm/i915/intel_fb.c
> index e4652dc..f1849d3 100644
> --- a/drivers/gpu/drm/i915/intel_fb.c
> +++ b/drivers/gpu/drm/i915/intel_fb.c
> @@ -504,6 +504,14 @@ static int intelfb_create(struct drm_device *dev, uint32_t fb_width,
>  	info->fbops = &intelfb_ops;
>  
>  	info->fix.line_length = fb->pitch;
> +
> +	/* setup aperture base/size for vesafb takeover */
> +	info->aperture_base = dev->mode_config.fb_base;
> +	if (IS_I9XX(dev))
> +		info->aperture_size = pci_resource_len(dev->pdev, 2);
> +	else
> +		info->aperture_size = pci_resource_len(dev->pdev, 0);
> +
>  	info->fix.smem_start = dev->mode_config.fb_base + obj_priv->gtt_offset;
>  	info->fix.smem_len = size;
>  
> diff --git a/drivers/video/efifb.c b/drivers/video/efifb.c
> index 8dea2bc..eb12182 100644
> --- a/drivers/video/efifb.c
> +++ b/drivers/video/efifb.c
> @@ -280,6 +280,9 @@ static int __init efifb_probe(struct platform_device *dev)
>  	info->pseudo_palette = info->par;
>  	info->par = NULL;
>  
> +	info->aperture_base = efifb_fix.smem_start;
> +	info->aperture_size = size_total;
> +
>  	info->screen_base = ioremap(efifb_fix.smem_start, efifb_fix.smem_len);
>  	if (!info->screen_base) {
>  		printk(KERN_ERR "efifb: abort, cannot ioremap video memory "
> @@ -337,7 +340,7 @@ static int __init efifb_probe(struct platform_device *dev)
>  	info->fbops = &efifb_ops;
>  	info->var = efifb_defined;
>  	info->fix = efifb_fix;
> -	info->flags = FBINFO_FLAG_DEFAULT;
> +	info->flags = FBINFO_FLAG_DEFAULT | FBINFO_MISC_FIRMWARE;
>  
>  	if ((err = fb_alloc_cmap(&info->cmap, 256, 0)) < 0) {
>  		printk(KERN_ERR "efifb: cannot allocate colormap\n");
> diff --git a/drivers/video/fbmem.c b/drivers/video/fbmem.c
> index d412a1d..67b8466 100644
> --- a/drivers/video/fbmem.c
> +++ b/drivers/video/fbmem.c
> @@ -1462,6 +1462,16 @@ static int fb_check_foreignness(struct fb_info *fi)
>  	return 0;
>  }
>  
> +static bool fb_do_apertures_overlap(struct fb_info *gen, struct fb_info *hw)
> +{
> +	/* is the generic aperture base the same as the HW one */
> +	if (gen->aperture_base == hw->aperture_base)
> +		return true;
> +	/* is the generic aperture base inside the hw base->hw base+size */
> +	if (gen->aperture_base > hw->aperture_base && gen->aperture_base <= hw->aperture_base + hw->aperture_size)
> +		return true;
> +	return false;
> +}
>  /**
>   *	register_framebuffer - registers a frame buffer device
>   *	@fb_info: frame buffer info structure
> @@ -1485,6 +1495,21 @@ register_framebuffer(struct fb_info *fb_info)
>  	if (fb_check_foreignness(fb_info))
>  		return -ENOSYS;
>  
> +	/* check all firmware fbs and kick off if the base addr overlaps */
> +	for (i = 0 ; i < FB_MAX; i++) {
> +		if (!registered_fb[i])
> +			continue;
> +
> +		if (registered_fb[i]->flags & FBINFO_MISC_FIRMWARE) {
> +			if (fb_do_apertures_overlap(registered_fb[i], fb_info)) {
> +				printk("fb: conflicting fb hw usage %s vs %s - removing generic driver\n",
> +				       fb_info->fix.id, registered_fb[i]->fix.id);
> +				unregister_framebuffer(registered_fb[i]);
> +				break;
> +			}
> +		}
> +	}
> +
>  	num_registered_fb++;
>  	for (i = 0 ; i < FB_MAX; i++)
>  		if (!registered_fb[i])
> @@ -1586,6 +1611,10 @@ unregister_framebuffer(struct fb_info *fb_info)
>  	device_destroy(fb_class, MKDEV(FB_MAJOR, i));
>  	event.info = fb_info;
>  	fb_notifier_call_chain(FB_EVENT_FB_UNREGISTERED, &event);
> +
> +	/* this may free fb info */
> +	if (fb_info->fbops->fb_destroy)
> +		fb_info->fbops->fb_destroy(fb_info);
>  done:
>  	return ret;
>  }
> diff --git a/drivers/video/vesafb.c b/drivers/video/vesafb.c
> index d6856f4..bd37ee1 100644
> --- a/drivers/video/vesafb.c
> +++ b/drivers/video/vesafb.c
> @@ -174,8 +174,17 @@ static int vesafb_setcolreg(unsigned regno, unsigned red, unsigned green,
>  	return err;
>  }
>  
> +static void vesafb_destroy(struct fb_info *info)
> +{
> +	if (info->screen_base)
> +		iounmap(info->screen_base);
> +	release_mem_region(info->aperture_base, info->aperture_size);
> +	framebuffer_release(info);
> +}
> +
>  static struct fb_ops vesafb_ops = {
>  	.owner		= THIS_MODULE,
> +	.fb_destroy     = vesafb_destroy,
>  	.fb_setcolreg	= vesafb_setcolreg,
>  	.fb_pan_display	= vesafb_pan_display,
>  	.fb_fillrect	= cfb_fillrect,
> @@ -286,6 +295,10 @@ static int __init vesafb_probe(struct platform_device *dev)
>  	info->pseudo_palette = info->par;
>  	info->par = NULL;
>  
> +	/* set vesafb aperture size for generic probing */
> +	info->aperture_base = screen_info.lfb_base;
> +	info->aperture_size = size_total;
> +
>  	info->screen_base = ioremap(vesafb_fix.smem_start, vesafb_fix.smem_len);
>  	if (!info->screen_base) {
>  		printk(KERN_ERR
> @@ -437,7 +450,7 @@ static int __init vesafb_probe(struct platform_device *dev)
>  	info->fbops = &vesafb_ops;
>  	info->var = vesafb_defined;
>  	info->fix = vesafb_fix;
> -	info->flags = FBINFO_FLAG_DEFAULT |
> +	info->flags = FBINFO_FLAG_DEFAULT | FBINFO_MISC_FIRMWARE |
>  		(ypan ? FBINFO_HWACCEL_YPAN : 0);
>  
>  	if (!ypan)
> diff --git a/include/linux/fb.h b/include/linux/fb.h
> index 330c4b1..01e9794 100644
> --- a/include/linux/fb.h
> +++ b/include/linux/fb.h
> @@ -677,6 +677,9 @@ struct fb_ops {
>  	/* get capability given var */
>  	void (*fb_get_caps)(struct fb_info *info, struct fb_blit_caps *caps,
>  			    struct fb_var_screeninfo *var);
> +
> +	/* teardown any resources to do with this framebuffer */
> +	void (*fb_destroy)(struct fb_info *info);
>  };
>  
>  #ifdef CONFIG_FB_TILEBLITTING
> @@ -786,6 +789,8 @@ struct fb_tile_ops {
>  #define FBINFO_MISC_USEREVENT          0x10000 /* event request
>  						  from userspace */
>  #define FBINFO_MISC_TILEBLITTING       0x20000 /* use tile blitting */
> +#define FBINFO_MISC_FIRMWARE           0x40000 /* a replaceable firmware 
> +						  inited framebuffer */
>  
>  /* A driver may set this flag to indicate that it does want a set_par to be
>   * called every time when fbcon_switch is executed. The advantage is that with
> @@ -854,7 +859,12 @@ struct fb_info {
>  	u32 state;			/* Hardware state i.e suspend */
>  	void *fbcon_par;                /* fbcon use-only private area */
>  	/* From here on everything is device dependent */
> -	void *par;	
> +	void *par;
> +	/* we need the PCI or similiar aperture base/size not
> +	   smem_start/size as smem_start may just be an object
> +	   allocated inside the aperture so may not actually overlap */
> +	resource_size_t aperture_base;
> +	resource_size_t aperture_size;
>  };
>  
>  #ifdef MODULE


-- 
        Peter

AIX is Unix from the universe where Spock had a beard.

Re: [Linux-fbdev-devel] [Bugme-new] [Bug 13285] New: INTELFB: Colors display incorrectly

[Michal S. <hra...@ce...>]

2009/6/4 Krzysztof Helt <krz...@po...>:
> On Wed, 3 Jun 2009 11:27:17 +0200
> Michal Suchanek <hra...@ce...> wrote:
>
>> Unfortunately I did not get to testing the patch yet.
>>
>> According to the description it is supposed to resolve some confusion
>> over what pipe is enabled or not.
>>
>> X server reports the pipes connected as follows:
>> (II) intel(0):   Pipe A is on
>> (II) intel(0):   Display plane A is now enabled and connected to pipe A.
>> (II) intel(0):   Pipe B is off
>> (II) intel(0):   Display plane B is now disabled and connected to pipe A.
>> (II) intel(0):   Output VGA is connected to pipe none
>> (II) intel(0):   Output TMDS-1 is connected to pipe A
>> (II) intel(0):   Output TV is connected to pipe none
>>
>> However, I also get this warning before the outputs are listed:
>> (WW) intel(0): Couldn't detect panel mode.  Disabling panel
>>
>> Is this a configuration that would likely be affected by the issue
>> fixed here or do I have a different problem?
>>
>
> Frankly speaking, I don't know. Please describe your problem.
>
> The panel mode I suppose is LVDS (LCD panel directly connected
> to the chip) which is possible only in laptops and tablets or other
> computers where the LCD panel is integrated with the main unit
> (e.g. "desk-lamp" like Apple computers). All other computers which you
> connect the display by external cable (DVI/HDMI or VGA) does not
> work in the "panel mode".

This is a mac mini with single TMDS display only.

Thanks

Michal

Re: [Linux-fbdev-devel] [PATCH 04/20] omapfb: Add support for the Amstrad Delta LCD

[Janusz K. <jkr...@ti...>]

TIS - Janusz Krzysztofik napisał(a):
> Thursday 04 June 2009 19:52:29 Imre Deak napisał(a):
>> From: Jonathan McDowell <no...@ea...>
>>
>> This is an updated version of the LCD driver for the Amstrad Delta to
>> take into account the recent changes to the omapfb infrastructure. The
>> Delta features a 480x320 12 bit DSTN panel.
> 
> Hi,
> 
> I'd really love to see the lcd_ams_delta support included in the mainline 
> kernel, but I am not sure if it is ready for submission, as I still have 
> issues with it. It does work perfectly unless power management is turned on.
> With CONFIG_PM=y, the omapfb device, after initially starting correctly, 
> breaks with the following error messages:
> 
> omapfb omapfb: resetting (status 0xffffff96,reset count 1)
> ...
> omapfb omapfb: resetting (status 0xffffff96,reset count 100)
> omapfb omapfb: too many reset attempts, giving up.
> 
> Tested with linux-2.6.30-rc5 and linux-omap revision 
> 90e758af52ba803cba233fabee81176d99589f09. Error messages do not appear when 
> CONFIG_PM=n or lcd_ams_delta.o is removed from omapfb-objs.

One idea for a temporary workaround: maybe we could just force PM=n in 
case of MACH_AMS_DELTA && FB_OMAP? PM already depends on !IA64_HP_SIM.

Janusz

> Please let me know what else I can do to help in resolving this issue.
> 
> Cheers,
> Janusz
> 
>> Signed-off-by: Jonathan McDowell <no...@ea...>
>> Signed-off-by: Tony Lindgren <to...@at...>
>> Signed-off-by: Imre Deak <imr...@no...>
>> ---
>>  drivers/video/omap/Makefile        |    1 +
>>  drivers/video/omap/lcd_ams_delta.c |  137
>> ++++++++++++++++++++++++++++++++++++ 2 files changed, 138 insertions(+), 0
>> deletions(-)
>>  create mode 100644 drivers/video/omap/lcd_ams_delta.c
>>
>> diff --git a/drivers/video/omap/Makefile b/drivers/video/omap/Makefile
>> index d86d54a..2bf94ad 100644
>> --- a/drivers/video/omap/Makefile
>> +++ b/drivers/video/omap/Makefile
>> @@ -15,6 +15,7 @@ objs-$(CONFIG_ARCH_OMAP2)$(CONFIG_FB_OMAP_LCDC_EXTERNAL)
>> += rfbi.o objs-y$(CONFIG_FB_OMAP_LCDC_HWA742) += hwa742.o
>>  objs-y$(CONFIG_FB_OMAP_LCDC_BLIZZARD) += blizzard.o
>>
>> +objs-y$(CONFIG_MACH_AMS_DELTA) += lcd_ams_delta.o
>>  objs-y$(CONFIG_MACH_OMAP_H4) += lcd_h4.o
>>  objs-y$(CONFIG_MACH_OMAP_H3) += lcd_h3.o
>>  objs-y$(CONFIG_MACH_OMAP_PALMTE) += lcd_palmte.o
>> diff --git a/drivers/video/omap/lcd_ams_delta.c
>> b/drivers/video/omap/lcd_ams_delta.c new file mode 100644
>> index 0000000..1f74399
>> --- /dev/null
>> +++ b/drivers/video/omap/lcd_ams_delta.c
>> @@ -0,0 +1,137 @@
>> +/*
>> + * Based on drivers/video/omap/lcd_inn1510.c
>> + *
>> + * LCD panel support for the Amstrad E3 (Delta) videophone.
>> + *
>> + * Copyright (C) 2006 Jonathan McDowell <no...@ea...>
>> + *
>> + * This program is free software; you can redistribute it and/or modify it
>> + * under the terms of the GNU General Public License as published by the
>> + * Free Software Foundation; either version 2 of the License, or (at your
>> + * option) any later version.
>> + *
>> + * This program is distributed in the hope that it will be useful, but
>> + * WITHOUT ANY WARRANTY; without even the implied warranty of
>> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
>> + * General Public License for more details.
>> + *
>> + * You should have received a copy of the GNU General Public License along
>> + * with this program; if not, write to the Free Software Foundation, Inc.,
>> + * 59 Temple Place - Suite 330, Boston, MA  02111-1307, USA.
>> + */
>> +
>> +#include <linux/module.h>
>> +#include <linux/platform_device.h>
>> +#include <linux/io.h>
>> +#include <linux/delay.h>
>> +
>> +#include <mach/board-ams-delta.h>
>> +#include <mach/hardware.h>
>> +#include <mach/omapfb.h>
>> +
>> +#define AMS_DELTA_DEFAULT_CONTRAST	112
>> +
>> +static int ams_delta_panel_init(struct lcd_panel *panel,
>> +		struct omapfb_device *fbdev)
>> +{
>> +	return 0;
>> +}
>> +
>> +static void ams_delta_panel_cleanup(struct lcd_panel *panel)
>> +{
>> +}
>> +
>> +static int ams_delta_panel_enable(struct lcd_panel *panel)
>> +{
>> +	ams_delta_latch2_write(AMS_DELTA_LATCH2_LCD_NDISP,
>> +			AMS_DELTA_LATCH2_LCD_NDISP);
>> +	ams_delta_latch2_write(AMS_DELTA_LATCH2_LCD_VBLEN,
>> +			AMS_DELTA_LATCH2_LCD_VBLEN);
>> +
>> +	omap_writeb(1, OMAP_PWL_CLK_ENABLE);
>> +	omap_writeb(AMS_DELTA_DEFAULT_CONTRAST, OMAP_PWL_ENABLE);
>> +
>> +	return 0;
>> +}
>> +
>> +static void ams_delta_panel_disable(struct lcd_panel *panel)
>> +{
>> +	ams_delta_latch2_write(AMS_DELTA_LATCH2_LCD_VBLEN, 0);
>> +	ams_delta_latch2_write(AMS_DELTA_LATCH2_LCD_NDISP, 0);
>> +}
>> +
>> +static unsigned long ams_delta_panel_get_caps(struct lcd_panel *panel)
>> +{
>> +	return 0;
>> +}
>> +
>> +static struct lcd_panel ams_delta_panel = {
>> +	.name		= "ams-delta",
>> +	.config		= 0,
>> +
>> +	.bpp		= 12,
>> +	.data_lines	= 16,
>> +	.x_res		= 480,
>> +	.y_res		= 320,
>> +	.pixel_clock	= 4687,
>> +	.hsw		= 3,
>> +	.hfp		= 1,
>> +	.hbp		= 1,
>> +	.vsw		= 1,
>> +	.vfp		= 0,
>> +	.vbp		= 0,
>> +	.pcd		= 0,
>> +	.acb		= 37,
>> +
>> +	.init		= ams_delta_panel_init,
>> +	.cleanup	= ams_delta_panel_cleanup,
>> +	.enable		= ams_delta_panel_enable,
>> +	.disable	= ams_delta_panel_disable,
>> +	.get_caps	= ams_delta_panel_get_caps,
>> +};
>> +
>> +static int ams_delta_panel_probe(struct platform_device *pdev)
>> +{
>> +	omapfb_register_panel(&ams_delta_panel);
>> +	return 0;
>> +}
>> +
>> +static int ams_delta_panel_remove(struct platform_device *pdev)
>> +{
>> +	return 0;
>> +}
>> +
>> +static int ams_delta_panel_suspend(struct platform_device *pdev,
>> +		pm_message_t mesg)
>> +{
>> +	return 0;
>> +}
>> +
>> +static int ams_delta_panel_resume(struct platform_device *pdev)
>> +{
>> +	return 0;
>> +}
>> +
>> +struct platform_driver ams_delta_panel_driver = {
>> +	.probe		= ams_delta_panel_probe,
>> +	.remove		= ams_delta_panel_remove,
>> +	.suspend	= ams_delta_panel_suspend,
>> +	.resume		= ams_delta_panel_resume,
>> +	.driver		= {
>> +		.name	= "lcd_ams_delta",
>> +		.owner	= THIS_MODULE,
>> +	},
>> +};
>> +
>> +static int ams_delta_panel_drv_init(void)
>> +{
>> +	return platform_driver_register(&ams_delta_panel_driver);
>> +}
>> +
>> +static void ams_delta_panel_drv_cleanup(void)
>> +{
>> +	platform_driver_unregister(&ams_delta_panel_driver);
>> +}
>> +
>> +module_init(ams_delta_panel_drv_init);
>> +module_exit(ams_delta_panel_drv_cleanup);
> 
> 

Re: [Linux-fbdev-devel] [PATCH 04/20] omapfb: Add support for the Amstrad Delta LCD

[Janusz K. <jkr...@ti...>]

Thursday 04 June 2009 19:52:29 Imre Deak napisał(a):
> From: Jonathan McDowell <no...@ea...>
>
> This is an updated version of the LCD driver for the Amstrad Delta to
> take into account the recent changes to the omapfb infrastructure. The
> Delta features a 480x320 12 bit DSTN panel.

Hi,

I'd really love to see the lcd_ams_delta support included in the mainline 
kernel, but I am not sure if it is ready for submission, as I still have 
issues with it. It does work perfectly unless power management is turned on.
With CONFIG_PM=y, the omapfb device, after initially starting correctly, 
breaks with the following error messages:

omapfb omapfb: resetting (status 0xffffff96,reset count 1)
...
omapfb omapfb: resetting (status 0xffffff96,reset count 100)
omapfb omapfb: too many reset attempts, giving up.

Tested with linux-2.6.30-rc5 and linux-omap revision 
90e758af52ba803cba233fabee81176d99589f09. Error messages do not appear when 
CONFIG_PM=n or lcd_ams_delta.o is removed from omapfb-objs.

Please let me know what else I can do to help in resolving this issue.

Cheers,
Janusz

> Signed-off-by: Jonathan McDowell <no...@ea...>
> Signed-off-by: Tony Lindgren <to...@at...>
> Signed-off-by: Imre Deak <imr...@no...>
> ---
>  drivers/video/omap/Makefile        |    1 +
>  drivers/video/omap/lcd_ams_delta.c |  137
> ++++++++++++++++++++++++++++++++++++ 2 files changed, 138 insertions(+), 0
> deletions(-)
>  create mode 100644 drivers/video/omap/lcd_ams_delta.c
>
> diff --git a/drivers/video/omap/Makefile b/drivers/video/omap/Makefile
> index d86d54a..2bf94ad 100644
> --- a/drivers/video/omap/Makefile
> +++ b/drivers/video/omap/Makefile
> @@ -15,6 +15,7 @@ objs-$(CONFIG_ARCH_OMAP2)$(CONFIG_FB_OMAP_LCDC_EXTERNAL)
> += rfbi.o objs-y$(CONFIG_FB_OMAP_LCDC_HWA742) += hwa742.o
>  objs-y$(CONFIG_FB_OMAP_LCDC_BLIZZARD) += blizzard.o
>
> +objs-y$(CONFIG_MACH_AMS_DELTA) += lcd_ams_delta.o
>  objs-y$(CONFIG_MACH_OMAP_H4) += lcd_h4.o
>  objs-y$(CONFIG_MACH_OMAP_H3) += lcd_h3.o
>  objs-y$(CONFIG_MACH_OMAP_PALMTE) += lcd_palmte.o
> diff --git a/drivers/video/omap/lcd_ams_delta.c
> b/drivers/video/omap/lcd_ams_delta.c new file mode 100644
> index 0000000..1f74399
> --- /dev/null
> +++ b/drivers/video/omap/lcd_ams_delta.c
> @@ -0,0 +1,137 @@
> +/*
> + * Based on drivers/video/omap/lcd_inn1510.c
> + *
> + * LCD panel support for the Amstrad E3 (Delta) videophone.
> + *
> + * Copyright (C) 2006 Jonathan McDowell <no...@ea...>
> + *
> + * This program is free software; you can redistribute it and/or modify it
> + * under the terms of the GNU General Public License as published by the
> + * Free Software Foundation; either version 2 of the License, or (at your
> + * option) any later version.
> + *
> + * This program is distributed in the hope that it will be useful, but
> + * WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
> + * General Public License for more details.
> + *
> + * You should have received a copy of the GNU General Public License along
> + * with this program; if not, write to the Free Software Foundation, Inc.,
> + * 59 Temple Place - Suite 330, Boston, MA  02111-1307, USA.
> + */
> +
> +#include <linux/module.h>
> +#include <linux/platform_device.h>
> +#include <linux/io.h>
> +#include <linux/delay.h>
> +
> +#include <mach/board-ams-delta.h>
> +#include <mach/hardware.h>
> +#include <mach/omapfb.h>
> +
> +#define AMS_DELTA_DEFAULT_CONTRAST	112
> +
> +static int ams_delta_panel_init(struct lcd_panel *panel,
> +		struct omapfb_device *fbdev)
> +{
> +	return 0;
> +}
> +
> +static void ams_delta_panel_cleanup(struct lcd_panel *panel)
> +{
> +}
> +
> +static int ams_delta_panel_enable(struct lcd_panel *panel)
> +{
> +	ams_delta_latch2_write(AMS_DELTA_LATCH2_LCD_NDISP,
> +			AMS_DELTA_LATCH2_LCD_NDISP);
> +	ams_delta_latch2_write(AMS_DELTA_LATCH2_LCD_VBLEN,
> +			AMS_DELTA_LATCH2_LCD_VBLEN);
> +
> +	omap_writeb(1, OMAP_PWL_CLK_ENABLE);
> +	omap_writeb(AMS_DELTA_DEFAULT_CONTRAST, OMAP_PWL_ENABLE);
> +
> +	return 0;
> +}
> +
> +static void ams_delta_panel_disable(struct lcd_panel *panel)
> +{
> +	ams_delta_latch2_write(AMS_DELTA_LATCH2_LCD_VBLEN, 0);
> +	ams_delta_latch2_write(AMS_DELTA_LATCH2_LCD_NDISP, 0);
> +}
> +
> +static unsigned long ams_delta_panel_get_caps(struct lcd_panel *panel)
> +{
> +	return 0;
> +}
> +
> +static struct lcd_panel ams_delta_panel = {
> +	.name		= "ams-delta",
> +	.config		= 0,
> +
> +	.bpp		= 12,
> +	.data_lines	= 16,
> +	.x_res		= 480,
> +	.y_res		= 320,
> +	.pixel_clock	= 4687,
> +	.hsw		= 3,
> +	.hfp		= 1,
> +	.hbp		= 1,
> +	.vsw		= 1,
> +	.vfp		= 0,
> +	.vbp		= 0,
> +	.pcd		= 0,
> +	.acb		= 37,
> +
> +	.init		= ams_delta_panel_init,
> +	.cleanup	= ams_delta_panel_cleanup,
> +	.enable		= ams_delta_panel_enable,
> +	.disable	= ams_delta_panel_disable,
> +	.get_caps	= ams_delta_panel_get_caps,
> +};
> +
> +static int ams_delta_panel_probe(struct platform_device *pdev)
> +{
> +	omapfb_register_panel(&ams_delta_panel);
> +	return 0;
> +}
> +
> +static int ams_delta_panel_remove(struct platform_device *pdev)
> +{
> +	return 0;
> +}
> +
> +static int ams_delta_panel_suspend(struct platform_device *pdev,
> +		pm_message_t mesg)
> +{
> +	return 0;
> +}
> +
> +static int ams_delta_panel_resume(struct platform_device *pdev)
> +{
> +	return 0;
> +}
> +
> +struct platform_driver ams_delta_panel_driver = {
> +	.probe		= ams_delta_panel_probe,
> +	.remove		= ams_delta_panel_remove,
> +	.suspend	= ams_delta_panel_suspend,
> +	.resume		= ams_delta_panel_resume,
> +	.driver		= {
> +		.name	= "lcd_ams_delta",
> +		.owner	= THIS_MODULE,
> +	},
> +};
> +
> +static int ams_delta_panel_drv_init(void)
> +{
> +	return platform_driver_register(&ams_delta_panel_driver);
> +}
> +
> +static void ams_delta_panel_drv_cleanup(void)
> +{
> +	platform_driver_unregister(&ams_delta_panel_driver);
> +}
> +
> +module_init(ams_delta_panel_drv_init);
> +module_exit(ams_delta_panel_drv_cleanup);