* [PATCH] mach64 atari patch
@ 2005-08-07 2:27 James Simmons
2005-08-07 11:39 ` Geert Uytterhoeven
2005-08-08 19:49 ` Alexander Kern
0 siblings, 2 replies; 21+ messages in thread
From: James Simmons @ 2005-08-07 2:27 UTC (permalink / raw)
To: Andrew Morton
Cc: Linux Fbdev development list, Geert Uytterhoeven,
Antonino A. Daplas
This patch makes the mach64 chip a platform device so sysfs can work with
it.
Signed-off-by: James Simmons <jsimmons@infradead.org>
diff -urN -X /home/jsimmons/dontdiff linus-2.6/drivers/video/aty/atyfb_base.c fbdev-2.6/drivers/video/aty/atyfb_base.c
--- linus-2.6/drivers/video/aty/atyfb_base.c 2005-07-11 10:07:21.000000000 -0700
+++ fbdev-2.6/drivers/video/aty/atyfb_base.c 2005-07-27 08:41:24.000000000 -0700
@@ -244,9 +244,6 @@
*/
static int aty_init(struct fb_info *info, const char *name);
-#ifdef CONFIG_ATARI
-static int store_video_par(char *videopar, unsigned char m64_num);
-#endif
static struct crtc saved_crtc;
static union aty_pll saved_pll;
@@ -321,10 +318,8 @@
#endif
#ifdef CONFIG_ATARI
-static unsigned int mach64_count __initdata = 0;
-static unsigned long phys_vmembase[FB_MAX] __initdata = { 0, };
-static unsigned long phys_size[FB_MAX] __initdata = { 0, };
-static unsigned long phys_guiregbase[FB_MAX] __initdata = { 0, };
+static struct mach64_device* __init store_video_par(char *video_str, unsigned char m64_num)
+static LIST_HEAD(mach64_list);
#endif
/* top -> down is an evolution of mach64 chipset, any corrections? */
@@ -2170,8 +2165,6 @@
* Initialisation
*/
-static struct fb_info *fb_list = NULL;
-
static int __init aty_init(struct fb_info *info, const char *name)
{
struct atyfb_par *par = (struct atyfb_par *) info->par;
@@ -2562,8 +2555,6 @@
if (register_framebuffer(info) < 0)
goto aty_init_exit;
- fb_list = info;
-
PRINTKI("fb%d: %s frame buffer device on %s\n",
info->node, info->fix.id, name);
return 0;
@@ -2587,10 +2578,13 @@
}
#ifdef CONFIG_ATARI
-static int __init store_video_par(char *video_str, unsigned char m64_num)
+static struct mach64_device* __init store_video_par(char *video_str, unsigned char m64_num)
{
- char *p;
unsigned long vmembase, size, guiregbase;
+ struct platform_device *atyfb_device;
+ struct mach64_device *device;
+ struct resource io[2];
+ char *p;
PRINTKI("store_video_par() '%s' \n", video_str);
@@ -2604,16 +2598,18 @@
goto mach64_invalid;
guiregbase = simple_strtoul(p, NULL, 0);
- phys_vmembase[m64_num] = vmembase;
- phys_size[m64_num] = size;
- phys_guiregbase[m64_num] = guiregbase;
- PRINTKI("stored them all: $%08lX $%08lX $%08lX \n", vmembase, size,
- guiregbase);
- return 0;
+ io[0] = request_mem_region(vmembase, size, "atyfb");
+ io[1] = request_mem_region(guiregbase, 0x10000, "atyfb");
- mach64_invalid:
- phys_vmembase[m64_num] = 0;
- return -1;
+ atyfb_device = platform_device_register_simple("atyfb", m64_num, io, 2);
+ if (IS_ERR(atyfb_device))
+ return PTR_ERR(atyfb_device);
+
+ device = kmalloc(sizeof(struct mach64_device), GFP_KERNEL);
+ PRINTKI("stored them all: $%08lX $%08lX $%08lX \n", vmembase, size, guiregbase);
+ return device;
+mach64_invalid:
+ return NULL;
}
#endif /* CONFIG_ATARI */
@@ -2679,17 +2675,10 @@
static void aty_st_pal(u_int regno, u_int red, u_int green, u_int blue,
const struct atyfb_par *par)
{
-#ifdef CONFIG_ATARI
- out_8(&par->aty_cmap_regs->windex, regno);
- out_8(&par->aty_cmap_regs->lut, red);
- out_8(&par->aty_cmap_regs->lut, green);
- out_8(&par->aty_cmap_regs->lut, blue);
-#else
writeb(regno, &par->aty_cmap_regs->windex);
writeb(red, &par->aty_cmap_regs->lut);
writeb(green, &par->aty_cmap_regs->lut);
writeb(blue, &par->aty_cmap_regs->lut);
-#endif
}
/*
@@ -3456,47 +3445,43 @@
#ifdef CONFIG_ATARI
-static int __devinit atyfb_atari_probe(void)
+static int __devinit atyfb_atari_probe(struct device *device)
{
- struct aty_par *par;
+ struct platform_device *dev = to_platform_device(device);
struct fb_info *info;
- int m64_num;
+ struct aty_par *par;
+ int size = 0;
u32 clock_r;
- for (m64_num = 0; m64_num < mach64_count; m64_num++) {
- if (!phys_vmembase[m64_num] || !phys_size[m64_num] ||
- !phys_guiregbase[m64_num]) {
- PRINTKI("phys_*[%d] parameters not set => returning early. \n", m64_num);
- continue;
- }
-
- info = framebuffer_alloc(sizeof(struct atyfb_par), NULL);
- if (!info) {
- PRINTKE("atyfb_atari_probe() can't alloc fb_info\n");
- return -ENOMEM;
- }
- par = info->par;
+ info = framebuffer_alloc(sizeof(struct atyfb_par), &dev->dev);
+ if (!info) {
+ PRINTKE("atyfb_atari_probe() can't alloc fb_info\n");
+ return -ENOMEM;
+ }
+ par = info->par;
- info->fix = atyfb_fix;
+ info->fix = atyfb_fix;
- par->irq = (unsigned int) -1; /* something invalid */
+ par->irq = (unsigned int) -1; /* something invalid */
- /*
- * Map the video memory (physical address given) to somewhere in the
- * kernel address space.
- */
- info->screen_base = ioremap(phys_vmembase[m64_num], phys_size[m64_num]);
- info->fix.smem_start = (unsigned long)info->screen_base; /* Fake! */
- par->ati_regbase = ioremap(phys_guiregbase[m64_num], 0x10000) +
- 0xFC00ul;
- info->fix.mmio_start = (unsigned long)par->ati_regbase; /* Fake! */
-
- aty_st_le32(CLOCK_CNTL, 0x12345678, par);
- clock_r = aty_ld_le32(CLOCK_CNTL, par);
-
- switch (clock_r & 0x003F) {
- case 0x12:
- par->clk_wr_offset = 3; /* */
+ /*
+ * Map the video memory (physical address given) to somewhere in the
+ * kernel address space.
+ */
+ size = dev->resource[0].start - dev->resource[0].end;
+ info->fix.smem_start = dev->resource[0].start;
+ info->screen_base = ioremap(dev->resource[0], size);
+
+ size = 0x10000;
+ info->fix.mmio_start = dev->resource[1].start + 0xFC00ul;
+ par->ati_regbase = ioremap(dev->resource[1], size) + 0xFC00ul;
+
+ aty_st_le32(CLOCK_CNTL, 0x12345678, par);
+ clock_r = aty_ld_le32(CLOCK_CNTL, par);
+
+ switch (clock_r & 0x003F) {
+ case 0x12:
+ par->clk_wr_offset = 3; /* */
break;
case 0x34:
par->clk_wr_offset = 2; /* Medusa ST-IO ISA Adapter etc. */
@@ -3595,6 +3580,23 @@
#endif /* CONFIG_PCI */
+#ifdef CONFIG_ATARI
+
+static struct device_driver atyfb_driver = {
+ .name = "atyfb",
+ .probe = atyfb_atari_probe,
+ .remove = __devexit_p(atyfb_atari_remove),
+}
+
+static void __devexit atyfb_atari_remove(struct device *dev)
+{
+ struct fb_info *info = dev_get_drvdata(dev);
+
+ atyfb_remove(info);
+}
+
+#endif /* CONFIG_ATARI */
+
#ifndef MODULE
static int __init atyfb_setup(char *options)
{
@@ -3650,15 +3652,15 @@
* Why do we need this silly Mach64 argument?
* We are already here because of mach64= so its redundant.
*/
- else if (MACH_IS_ATARI
- && (!strncmp(this_opt, "Mach64:", 7))) {
- static unsigned char m64_num;
- static char mach64_str[80];
+ else if (MACH_IS_ATARI && (!strncmp(this_opt, "Mach64:", 7))) {
+ struct mach64_device *dev;
+ unsigned char m64_num = 0;
+ char mach64_str[80];
+
strlcpy(mach64_str, this_opt + 7, sizeof(mach64_str));
- if (!store_video_par(mach64_str, m64_num)) {
- m64_num++;
- mach64_count = m64_num;
- }
+ dev = store_video_par(mach64_str, m64_num++);
+ if (dev != null)
+ list_add_tail(dev->node, &mach64_list);
}
#endif
else
@@ -3670,6 +3672,8 @@
static int __init atyfb_init(void)
{
+ int retval = 0;
+
#ifndef MODULE
char *option = NULL;
@@ -3679,16 +3683,34 @@
#endif
#ifdef CONFIG_PCI
- pci_register_driver(&atyfb_driver);
+ retval = pci_register_driver(&atyfb_driver);
#endif
#ifdef CONFIG_ATARI
- atyfb_atari_probe();
+ retval = driver_register(&atyfb_driver);
+ if (retval < 0) {
+ struct platform_device *device;
+
+ list_for_each_safe(device, &mach64_list, node) {
+ platform_device_unregister(&device->dev);
+ kfree(device);
+ }
+ }
#endif
- return 0;
+ return retval;
}
static void __exit atyfb_exit(void)
{
+#ifdef CONFIG_ATARI
+ struct platform_device *device;
+
+ list_for_each_safe(device, &mach64_list, node) {
+ platform_device_unregister(&device->dev);
+ kfree(device);
+ }
+ driver_unregister(&atyfb_driver);
+#endif
+
#ifdef CONFIG_PCI
pci_unregister_driver(&atyfb_driver);
#endif
diff -urN -X /home/jsimmons/dontdiff linus-2.6/drivers/video/aty/atyfb.h fbdev-2.6/drivers/video/aty/atyfb.h
--- linus-2.6/drivers/video/aty/atyfb.h 2005-07-11 10:07:21.000000000 -0700
+++ fbdev-2.6/drivers/video/aty/atyfb.h 2005-07-22 15:36:41.000000000 -0700
@@ -187,6 +187,13 @@
#endif
};
+#ifdef CONFIG_ATARI
+struct mach64_device {
+ struct list_head node;
+ struct platform_device *dev;
+};
+#endif
+
/*
* ATI Mach64 features
*/
-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [PATCH] mach64 atari patch
2005-08-07 2:27 [PATCH] mach64 atari patch James Simmons
@ 2005-08-07 11:39 ` Geert Uytterhoeven
2005-08-07 16:46 ` Andrew Morton
2005-08-12 17:47 ` James Simmons
2005-08-08 19:49 ` Alexander Kern
1 sibling, 2 replies; 21+ messages in thread
From: Geert Uytterhoeven @ 2005-08-07 11:39 UTC (permalink / raw)
To: James Simmons
Cc: Andrew Morton, Linux Fbdev development list, Antonino A. Daplas
On Sun, 7 Aug 2005, James Simmons wrote:
> This patch makes the mach64 chip a platform device so sysfs can work with
> it.
>
> Signed-off-by: James Simmons <jsimmons@infradead.org>
>
> --- linus-2.6/drivers/video/aty/atyfb_base.c 2005-07-11 10:07:21.000000000 -0700
> +++ fbdev-2.6/drivers/video/aty/atyfb_base.c 2005-07-27 08:41:24.000000000 -0700
> @@ -321,10 +318,8 @@
> #endif
>
> #ifdef CONFIG_ATARI
> -static unsigned int mach64_count __initdata = 0;
> -static unsigned long phys_vmembase[FB_MAX] __initdata = { 0, };
> -static unsigned long phys_size[FB_MAX] __initdata = { 0, };
> -static unsigned long phys_guiregbase[FB_MAX] __initdata = { 0, };
> +static struct mach64_device* __init store_video_par(char *video_str, unsigned char m64_num)
Missing semicolumn at end of line.
> @@ -2587,10 +2578,13 @@
> }
>
> #ifdef CONFIG_ATARI
> -static int __init store_video_par(char *video_str, unsigned char m64_num)
> +static struct mach64_device* __init store_video_par(char *video_str, unsigned char m64_num)
> {
> - char *p;
> unsigned long vmembase, size, guiregbase;
> + struct platform_device *atyfb_device;
> + struct mach64_device *device;
> + struct resource io[2];
> + char *p;
>
> PRINTKI("store_video_par() '%s' \n", video_str);
>
> @@ -2604,16 +2598,18 @@
> goto mach64_invalid;
> guiregbase = simple_strtoul(p, NULL, 0);
>
> - phys_vmembase[m64_num] = vmembase;
> - phys_size[m64_num] = size;
> - phys_guiregbase[m64_num] = guiregbase;
> - PRINTKI("stored them all: $%08lX $%08lX $%08lX \n", vmembase, size,
> - guiregbase);
> - return 0;
> + io[0] = request_mem_region(vmembase, size, "atyfb");
> + io[1] = request_mem_region(guiregbase, 0x10000, "atyfb");
1. request_mem_region(0 returns a pointer to a struct resource, not a struct
resource.
2. What if request_mem_region() fails and returns NULL?
> - mach64_invalid:
> - phys_vmembase[m64_num] = 0;
> - return -1;
> + atyfb_device = platform_device_register_simple("atyfb", m64_num, io, 2);
> + if (IS_ERR(atyfb_device))
> + return PTR_ERR(atyfb_device);
^^^^^^^
PTR_ERR() returns a long, but we should return a struct mach64_device *.
> @@ -2679,17 +2675,10 @@
> static void aty_st_pal(u_int regno, u_int red, u_int green, u_int blue,
> const struct atyfb_par *par)
> {
> -#ifdef CONFIG_ATARI
> - out_8(&par->aty_cmap_regs->windex, regno);
> - out_8(&par->aty_cmap_regs->lut, red);
> - out_8(&par->aty_cmap_regs->lut, green);
> - out_8(&par->aty_cmap_regs->lut, blue);
> -#else
> writeb(regno, &par->aty_cmap_regs->windex);
> writeb(red, &par->aty_cmap_regs->lut);
> writeb(green, &par->aty_cmap_regs->lut);
> writeb(blue, &par->aty_cmap_regs->lut);
> -#endif
Why? writeb() does not exist, because there's no PCI bus.
> }
>
> /*
> @@ -3456,47 +3445,43 @@
>
> #ifdef CONFIG_ATARI
>
> -static int __devinit atyfb_atari_probe(void)
> +static int __devinit atyfb_atari_probe(struct device *device)
> {
> - struct aty_par *par;
> + struct platform_device *dev = to_platform_device(device);
> struct fb_info *info;
> - int m64_num;
> + struct aty_par *par;
> + int size = 0;
> u32 clock_r;
>
> - for (m64_num = 0; m64_num < mach64_count; m64_num++) {
> - if (!phys_vmembase[m64_num] || !phys_size[m64_num] ||
> - !phys_guiregbase[m64_num]) {
The for-loop was removed....
> - PRINTKI("phys_*[%d] parameters not set => returning early. \n", m64_num);
> - continue;
> - }
> -
> - info = framebuffer_alloc(sizeof(struct atyfb_par), NULL);
> - if (!info) {
> - PRINTKE("atyfb_atari_probe() can't alloc fb_info\n");
> - return -ENOMEM;
> - }
> - par = info->par;
> + info = framebuffer_alloc(sizeof(struct atyfb_par), &dev->dev);
> + if (!info) {
> + PRINTKE("atyfb_atari_probe() can't alloc fb_info\n");
> + return -ENOMEM;
> + }
> + par = info->par;
>
> - info->fix = atyfb_fix;
> + info->fix = atyfb_fix;
>
> - par->irq = (unsigned int) -1; /* something invalid */
> + par->irq = (unsigned int) -1; /* something invalid */
>
> - /*
> - * Map the video memory (physical address given) to somewhere in the
> - * kernel address space.
> - */
> - info->screen_base = ioremap(phys_vmembase[m64_num], phys_size[m64_num]);
> - info->fix.smem_start = (unsigned long)info->screen_base; /* Fake! */
> - par->ati_regbase = ioremap(phys_guiregbase[m64_num], 0x10000) +
> - 0xFC00ul;
> - info->fix.mmio_start = (unsigned long)par->ati_regbase; /* Fake! */
> -
> - aty_st_le32(CLOCK_CNTL, 0x12345678, par);
> - clock_r = aty_ld_le32(CLOCK_CNTL, par);
> -
> - switch (clock_r & 0x003F) {
> - case 0x12:
> - par->clk_wr_offset = 3; /* */
> + /*
> + * Map the video memory (physical address given) to somewhere in the
> + * kernel address space.
> + */
> + size = dev->resource[0].start - dev->resource[0].end;
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
dev->resource[0].start - dev->resource[0].end + 1;
> + info->fix.smem_start = dev->resource[0].start;
> + info->screen_base = ioremap(dev->resource[0], size);
^^^^^^^^^^^^^^^^
dev->resource[0].start
> +
> + size = 0x10000;
> + info->fix.mmio_start = dev->resource[1].start + 0xFC00ul;
> + par->ati_regbase = ioremap(dev->resource[1], size) + 0xFC00ul;
^^^^^^^^^^^^^^^^
dev->resource[1].start
> +
> + aty_st_le32(CLOCK_CNTL, 0x12345678, par);
> + clock_r = aty_ld_le32(CLOCK_CNTL, par);
> +
> + switch (clock_r & 0x003F) {
> + case 0x12:
> + par->clk_wr_offset = 3; /* */
> break;
> case 0x34:
> par->clk_wr_offset = 2; /* Medusa ST-IO ISA Adapter etc. */
... but the closing brace for the for-loop is still there.
> @@ -3595,6 +3580,23 @@
>
> #endif /* CONFIG_PCI */
>
> +#ifdef CONFIG_ATARI
> +
> +static struct device_driver atyfb_driver = {
> + .name = "atyfb",
> + .probe = atyfb_atari_probe,
> + .remove = __devexit_p(atyfb_atari_remove),
Initialization from incompatible pointer type,
and atyfb_atari_remove is used before its definition, ...
> +}
Missing semicolumn
> +
> +static void __devexit atyfb_atari_remove(struct device *dev)
> +{
> + struct fb_info *info = dev_get_drvdata(dev);
> +
> + atyfb_remove(info);
> +}
... so you better move this one up.
> @@ -3650,15 +3652,15 @@
> * Why do we need this silly Mach64 argument?
> * We are already here because of mach64= so its redundant.
> */
> - else if (MACH_IS_ATARI
> - && (!strncmp(this_opt, "Mach64:", 7))) {
> - static unsigned char m64_num;
> - static char mach64_str[80];
> + else if (MACH_IS_ATARI && (!strncmp(this_opt, "Mach64:", 7))) {
> + struct mach64_device *dev;
> + unsigned char m64_num = 0;
> + char mach64_str[80];
> +
> strlcpy(mach64_str, this_opt + 7, sizeof(mach64_str));
> - if (!store_video_par(mach64_str, m64_num)) {
> - m64_num++;
> - mach64_count = m64_num;
> - }
> + dev = store_video_par(mach64_str, m64_num++);
> + if (dev != null)
^^^^
NULL
> + list_add_tail(dev->node, &mach64_list);
incompatible type for argument 1 of `list_add_tail'
> @@ -3679,16 +3683,34 @@
> #endif
>
> #ifdef CONFIG_PCI
> - pci_register_driver(&atyfb_driver);
> + retval = pci_register_driver(&atyfb_driver);
> #endif
> #ifdef CONFIG_ATARI
> - atyfb_atari_probe();
> + retval = driver_register(&atyfb_driver);
> + if (retval < 0) {
> + struct platform_device *device;
> +
> + list_for_each_safe(device, &mach64_list, node) {
`node' undeclared
> + platform_device_unregister(&device->dev);
^^^^^^^^^^^^
device ??
> + kfree(device);
> + }
> + }
> #endif
> - return 0;
> + return retval;
> }
>
> static void __exit atyfb_exit(void)
> {
> +#ifdef CONFIG_ATARI
> + struct platform_device *device;
> +
> + list_for_each_safe(device, &mach64_list, node) {
`node' undeclared
> + platform_device_unregister(&device->dev);
> + kfree(device);
> + }
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [PATCH] mach64 atari patch
2005-08-07 11:39 ` Geert Uytterhoeven
@ 2005-08-07 16:46 ` Andrew Morton
2005-08-07 23:09 ` James Simmons
2005-08-12 17:47 ` James Simmons
1 sibling, 1 reply; 21+ messages in thread
From: Andrew Morton @ 2005-08-07 16:46 UTC (permalink / raw)
To: Geert Uytterhoeven; +Cc: jsimmons, linux-fbdev-devel, adaplas
Geert Uytterhoeven <geert@linux-m68k.org> wrote:
>
> On Sun, 7 Aug 2005, James Simmons wrote:
> > This patch makes the mach64 chip a platform device so sysfs can work with
> > it.
> >
> > Signed-off-by: James Simmons <jsimmons@infradead.org>
> >
> > --- linus-2.6/drivers/video/aty/atyfb_base.c 2005-07-11 10:07:21.000000000 -0700
> > +++ fbdev-2.6/drivers/video/aty/atyfb_base.c 2005-07-27 08:41:24.000000000 -0700
> > @@ -321,10 +318,8 @@
> > #endif
> >
> > #ifdef CONFIG_ATARI
> > -static unsigned int mach64_count __initdata = 0;
> > -static unsigned long phys_vmembase[FB_MAX] __initdata = { 0, };
> > -static unsigned long phys_size[FB_MAX] __initdata = { 0, };
> > -static unsigned long phys_guiregbase[FB_MAX] __initdata = { 0, };
> > +static struct mach64_device* __init store_video_par(char *video_str, unsigned char m64_num)
>
> Missing semicolumn at end of line.
>
> [etc]
>
Thanks, Geert.
James, I'll drop this one - it seems to need version 2.
I'll also drop fbdev-dont-allow-softcursor-use-from-userland.patch as there
seems to be quite a bit of controversy there.
-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Re: [PATCH] mach64 atari patch
2005-08-07 16:46 ` Andrew Morton
@ 2005-08-07 23:09 ` James Simmons
2005-08-07 23:31 ` Antonino A. Daplas
0 siblings, 1 reply; 21+ messages in thread
From: James Simmons @ 2005-08-07 23:09 UTC (permalink / raw)
To: Linux Fbdev development list
Cc: Geert Uytterhoeven, Antonino A. Daplas, Andrew Morton
>
> Thanks, Geert.
>
> James, I'll drop this one - it seems to need version 2.
Yeah!!! I got no response earlier. Now I can fix the patch up.
> I'll also drop fbdev-dont-allow-softcursor-use-from-userland.patch as there
> seems to be quite a bit of controversy there.
The disagreement was how much to change it at one time. Some patches where
just huge and did massive changes to all drivers. I wanted to break the patch
up into little pieces. Please apply this patch otherwise we will be stuck
where we are.
-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Re: [PATCH] mach64 atari patch
2005-08-07 23:09 ` James Simmons
@ 2005-08-07 23:31 ` Antonino A. Daplas
2005-08-07 23:48 ` Jon Smirl
2005-08-09 0:04 ` James Simmons
0 siblings, 2 replies; 21+ messages in thread
From: Antonino A. Daplas @ 2005-08-07 23:31 UTC (permalink / raw)
To: linux-fbdev-devel; +Cc: Geert Uytterhoeven, Antonino A. Daplas, Andrew Morton
James Simmons wrote:
>
>> I'll also drop fbdev-dont-allow-softcursor-use-from-userland.patch as there
>> seems to be quite a bit of controversy there.
>
> The disagreement was how much to change it at one time. Some patches where
> just huge and did massive changes to all drivers. I wanted to break the patch
> up into little pieces. Please apply this patch otherwise we will be stuck
> where we are.
>
Please, my patch (based from Jon's) is huge because it's removing > 200 lines
and it's moving softcursor.c from drivers/video to drivers/video/console where
it belongs. But it is _not_ intrusive. In fact, the majority of the patch consists
of a single logical change which removes the line below from each driver
- .fb_cursor = softcursor;
and removes the line below from drivers/video/Kconfig.
- select FB_SOFT_CURSOR
Our proposal aims to make complex code simpler and big code smaller. Your patch,
on the other hand, although small, introduces another flag FB_HWCURSOR_SOFTCURSOR,
which is redundant, and adds yet another level of complexity to an already too
complex code.
I already have the patch, but I'm not pushing it yet because of an ongoing
disagreement, in courtesy to other developers such as yourself.
Tony
-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Re: [PATCH] mach64 atari patch
2005-08-07 23:31 ` Antonino A. Daplas
@ 2005-08-07 23:48 ` Jon Smirl
2005-08-08 17:30 ` James Simmons
2005-08-09 0:04 ` James Simmons
1 sibling, 1 reply; 21+ messages in thread
From: Jon Smirl @ 2005-08-07 23:48 UTC (permalink / raw)
To: linux-fbdev-devel, James Simmons
Cc: Geert Uytterhoeven, Antonino A. Daplas, Andrew Morton
On 8/7/05, Antonino A. Daplas <adaplas@gmail.com> wrote:
> James Simmons wrote:
> >
> >> I'll also drop fbdev-dont-allow-softcursor-use-from-userland.patch as there
> >> seems to be quite a bit of controversy there.
> >
> > The disagreement was how much to change it at one time. Some patches where
> > just huge and did massive changes to all drivers. I wanted to break the patch
> > up into little pieces. Please apply this patch otherwise we will be stuck
> > where we are.
> >
James, if you are really worried about our patch to move softcursor
into fbcon, why don't we put it into the -mm tree for a month without
moving it to the main kernel and see if anyone complains.
I am definitely of the belief that since softcursor can only be used
by fbcon then it should be moved into fbcon and all support for it be
dropped from fbdev. We can't leave the code as is since it interferes
with the use of the hardware cursors from user space.
I just don't think this patch is as complex as you are making it out
to be. It is large simply because the same action has been repeated
for each of the 65 drivers. The action is only a simple deletion of
two lines.
> Please, my patch (based from Jon's) is huge because it's removing > 200 lines
> and it's moving softcursor.c from drivers/video to drivers/video/console where
> it belongs. But it is _not_ intrusive. In fact, the majority of the patch consists
> of a single logical change which removes the line below from each driver
>
> - .fb_cursor = softcursor;
>
> and removes the line below from drivers/video/Kconfig.
>
> - select FB_SOFT_CURSOR
>
> Our proposal aims to make complex code simpler and big code smaller. Your patch,
> on the other hand, although small, introduces another flag FB_HWCURSOR_SOFTCURSOR,
> which is redundant, and adds yet another level of complexity to an already too
> complex code.
>
> I already have the patch, but I'm not pushing it yet because of an ongoing
> disagreement, in courtesy to other developers such as yourself.
>
> Tony
--
Jon Smirl
jonsmirl@gmail.com
-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Re: [PATCH] mach64 atari patch
2005-08-07 23:48 ` Jon Smirl
@ 2005-08-08 17:30 ` James Simmons
2005-08-08 17:56 ` Jon Smirl
0 siblings, 1 reply; 21+ messages in thread
From: James Simmons @ 2005-08-08 17:30 UTC (permalink / raw)
To: Jon Smirl
Cc: linux-fbdev-devel, Geert Uytterhoeven, Antonino A. Daplas,
Andrew Morton
> James, if you are really worried about our patch to move softcursor
> into fbcon, why don't we put it into the -mm tree for a month without
> moving it to the main kernel and see if anyone complains.
>
> I am definitely of the belief that since softcursor can only be used
> by fbcon then it should be moved into fbcon and all support for it be
> dropped from fbdev. We can't leave the code as is since it interferes
> with the use of the hardware cursors from user space.
>
> I just don't think this patch is as complex as you are making it out
> to be. It is large simply because the same action has been repeated
> for each of the 65 drivers. The action is only a simple deletion of
> two lines.
I'm not arguing over this. What is wrong with breaking this patch up!!!!!
I still have no answer to this!!!! I'm using the hardware flag because
sometimes the driver that does have a hardware cursor wants to turn
support off for it.
-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Re: [PATCH] mach64 atari patch
2005-08-08 17:30 ` James Simmons
@ 2005-08-08 17:56 ` Jon Smirl
2005-08-08 18:15 ` James Simmons
0 siblings, 1 reply; 21+ messages in thread
From: Jon Smirl @ 2005-08-08 17:56 UTC (permalink / raw)
To: James Simmons
Cc: linux-fbdev-devel, Geert Uytterhoeven, Antonino A. Daplas,
Andrew Morton
On 8/8/05, James Simmons <jsimmons@infradead.org> wrote:
>
> > James, if you are really worried about our patch to move softcursor
> > into fbcon, why don't we put it into the -mm tree for a month without
> > moving it to the main kernel and see if anyone complains.
> >
> > I am definitely of the belief that since softcursor can only be used
> > by fbcon then it should be moved into fbcon and all support for it be
> > dropped from fbdev. We can't leave the code as is since it interferes
> > with the use of the hardware cursors from user space.
> >
> > I just don't think this patch is as complex as you are making it out
> > to be. It is large simply because the same action has been repeated
> > for each of the 65 drivers. The action is only a simple deletion of
> > two lines.
>
> I'm not arguing over this. What is wrong with breaking this patch up!!!!!
> I still have no answer to this!!!! I'm using the hardware flag because
> sometimes the driver that does have a hardware cursor wants to turn
> support off for it.
Set .fb_cursor = NULL; to turn off the support.
--
Jon Smirl
jonsmirl@gmail.com
-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Re: [PATCH] mach64 atari patch
2005-08-08 17:56 ` Jon Smirl
@ 2005-08-08 18:15 ` James Simmons
2005-08-08 18:34 ` Jon Smirl
2005-08-08 23:55 ` Antonino A. Daplas
0 siblings, 2 replies; 21+ messages in thread
From: James Simmons @ 2005-08-08 18:15 UTC (permalink / raw)
To: Jon Smirl
Cc: linux-fbdev-devel, Geert Uytterhoeven, Antonino A. Daplas,
Andrew Morton
> > > I just don't think this patch is as complex as you are making it out
> > > to be. It is large simply because the same action has been repeated
> > > for each of the 65 drivers. The action is only a simple deletion of
> > > two lines.
> >
> > I'm not arguing over this. What is wrong with breaking this patch up!!!!!
> > I still have no answer to this!!!! I'm using the hardware flag because
> > sometimes the driver that does have a hardware cursor wants to turn
> > support off for it.
>
> Set .fb_cursor = NULL; to turn off the support.
So forbid hardware drivers that support hware cursors to never turn off
there hardware cursor support!!!!!
Let see what drivers have a flag to control using the hardware cursor.
au1100fb int nohwcursor
intelfb int hwcursor
nvidia int hwcur
cyberfb
You need to remove this!!!!
What I am arguing is that drivers with hardware cursor support should be
able to turn off and on hardware cursor support. That is why the
HWACCEL_CURSOR flag. Your test the fb_cursor field prevents this!!!
-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Re: [PATCH] mach64 atari patch
2005-08-08 18:15 ` James Simmons
@ 2005-08-08 18:34 ` Jon Smirl
2005-08-08 18:44 ` James Simmons
2005-08-08 23:55 ` Antonino A. Daplas
1 sibling, 1 reply; 21+ messages in thread
From: Jon Smirl @ 2005-08-08 18:34 UTC (permalink / raw)
To: James Simmons
Cc: linux-fbdev-devel, Geert Uytterhoeven, Antonino A. Daplas,
Andrew Morton
On 8/8/05, James Simmons <jsimmons@infradead.org> wrote:
>
> > > > I just don't think this patch is as complex as you are making it out
> > > > to be. It is large simply because the same action has been repeated
> > > > for each of the 65 drivers. The action is only a simple deletion of
> > > > two lines.
> > >
> > > I'm not arguing over this. What is wrong with breaking this patch up!!!!!
> > > I still have no answer to this!!!! I'm using the hardware flag because
> > > sometimes the driver that does have a hardware cursor wants to turn
> > > support off for it.
> >
> > Set .fb_cursor = NULL; to turn off the support.
>
> So forbid hardware drivers that support hware cursors to never turn off
> there hardware cursor support!!!!!
>
> Let see what drivers have a flag to control using the hardware cursor.
>
> au1100fb int nohwcursor
> intelfb int hwcursor
> nvidia int hwcur
> cyberfb
>
> You need to remove this!!!!
>
> What I am arguing is that drivers with hardware cursor support should be
> able to turn off and on hardware cursor support. That is why the
> HWACCEL_CURSOR flag. Your test the fb_cursor field prevents this!!!
If you want fbconsole to use the software cusor instead of the
hardware cursor, that's between you and fbconsole to decide. Control
over that choice needs to be in fbconsole, not the base fbdev.
The fbdev drivers should just unconditionally offer the hardware
cursor if they support it. It is up to the user of the cursor to
choose whether to use it or ignore it.
--
Jon Smirl
jonsmirl@gmail.com
-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Re: [PATCH] mach64 atari patch
2005-08-08 18:34 ` Jon Smirl
@ 2005-08-08 18:44 ` James Simmons
2005-08-08 19:01 ` Jon Smirl
0 siblings, 1 reply; 21+ messages in thread
From: James Simmons @ 2005-08-08 18:44 UTC (permalink / raw)
To: Jon Smirl
Cc: linux-fbdev-devel, Geert Uytterhoeven, Antonino A. Daplas,
Andrew Morton
> > au1100fb int nohwcursor
> > intelfb int hwcursor
> > nvidia int hwcur
> > cyberfb
> >
> > You need to remove this!!!!
> >
> > What I am arguing is that drivers with hardware cursor support should be
> > able to turn off and on hardware cursor support. That is why the
> > HWACCEL_CURSOR flag. Your test the fb_cursor field prevents this!!!
>
> If you want fbconsole to use the software cusor instead of the
> hardware cursor, that's between you and fbconsole to decide. Control
> over that choice needs to be in fbconsole, not the base fbdev.
>
> The fbdev drivers should just unconditionally offer the hardware
> cursor if they support it. It is up to the user of the cursor to
> choose whether to use it or ignore it.
Finally you see the point I was making. I wanted it be very clear to every
one here the implications of your changes. You remove the power to control
the use of a hardware cursor from the driver. At this point driver writers
need to speak up if they have no problem with this.
P.S
The patch still needs to broken into smaller pieces.
-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Re: [PATCH] mach64 atari patch
2005-08-08 18:44 ` James Simmons
@ 2005-08-08 19:01 ` Jon Smirl
2005-08-08 19:07 ` Jon Smirl
0 siblings, 1 reply; 21+ messages in thread
From: Jon Smirl @ 2005-08-08 19:01 UTC (permalink / raw)
To: James Simmons
Cc: linux-fbdev-devel, Geert Uytterhoeven, Antonino A. Daplas,
Andrew Morton
On 8/8/05, James Simmons <jsimmons@infradead.org> wrote:
>
> > > au1100fb int nohwcursor
> > > intelfb int hwcursor
> > > nvidia int hwcur
> > > cyberfb
> > >
> > > You need to remove this!!!!
> > >
> > > What I am arguing is that drivers with hardware cursor support should be
> > > able to turn off and on hardware cursor support. That is why the
> > > HWACCEL_CURSOR flag. Your test the fb_cursor field prevents this!!!
> >
> > If you want fbconsole to use the software cusor instead of the
> > hardware cursor, that's between you and fbconsole to decide. Control
> > over that choice needs to be in fbconsole, not the base fbdev.
> >
> > The fbdev drivers should just unconditionally offer the hardware
> > cursor if they support it. It is up to the user of the cursor to
> > choose whether to use it or ignore it.
>
> Finally you see the point I was making. I wanted it be very clear to every
> one here the implications of your changes. You remove the power to control
> the use of a hardware cursor from the driver. At this point driver writers
> need to speak up if they have no problem with this.
I'm not working on fbconsole so it did not occur to me what your
issues was. My user space apps have always had control of whether they
used the hardware cursor or not.
You will need to ask Tony for a switch. Easiest way is to make it a
module parameter on fbconsole. That way it will appear in
/sys/module/fbconsole/parameters and you can use echo to set it from a
script. There is no need for an ioctl.
It only takes about five lines of code to implement this, something like this...
fbconsole.c
int use_hw_cursor = 0;
module_parm(use_hw_cursor);
if (fb_info->fb_cursor && use_hw_cursor)
fb_info->fb_cursor(...)
else
softcursor
>
> P.S
> The patch still needs to broken into smaller pieces.
>
>
>
--
Jon Smirl
jonsmirl@gmail.com
-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Re: [PATCH] mach64 atari patch
2005-08-08 19:01 ` Jon Smirl
@ 2005-08-08 19:07 ` Jon Smirl
0 siblings, 0 replies; 21+ messages in thread
From: Jon Smirl @ 2005-08-08 19:07 UTC (permalink / raw)
To: James Simmons
Cc: linux-fbdev-devel, Geert Uytterhoeven, Antonino A. Daplas,
Andrew Morton
On 8/8/05, Jon Smirl <jonsmirl@gmail.com> wrote:
> On 8/8/05, James Simmons <jsimmons@infradead.org> wrote:
> >
> > > > au1100fb int nohwcursor
> > > > intelfb int hwcursor
> > > > nvidia int hwcur
> > > > cyberfb
> > > >
> > > > You need to remove this!!!!
> > > >
> > > > What I am arguing is that drivers with hardware cursor support should be
> > > > able to turn off and on hardware cursor support. That is why the
> > > > HWACCEL_CURSOR flag. Your test the fb_cursor field prevents this!!!
> > >
> > > If you want fbconsole to use the software cusor instead of the
> > > hardware cursor, that's between you and fbconsole to decide. Control
> > > over that choice needs to be in fbconsole, not the base fbdev.
> > >
> > > The fbdev drivers should just unconditionally offer the hardware
> > > cursor if they support it. It is up to the user of the cursor to
> > > choose whether to use it or ignore it.
> >
> > Finally you see the point I was making. I wanted it be very clear to every
> > one here the implications of your changes. You remove the power to control
> > the use of a hardware cursor from the driver. At this point driver writers
> > need to speak up if they have no problem with this.
>
> I'm not working on fbconsole so it did not occur to me what your
> issues was. My user space apps have always had control of whether they
> used the hardware cursor or not.
>
> You will need to ask Tony for a switch. Easiest way is to make it a
> module parameter on fbconsole. That way it will appear in
> /sys/module/fbconsole/parameters and you can use echo to set it from a
> script. There is no need for an ioctl.
Personally I am not in favor of building hundreds of switches like
this into the kernel. If the hardware cursor doesn't work it should
either be fixed or disabled in the fbdev driver. If you take that
philosophy there is no need for a switch on fbconsole.
I really don't like the "if it doesn't work for you here's how to turn
if off" switches. All they do is hide bugs.
>
> It only takes about five lines of code to implement this, something like this...
>
> fbconsole.c
>
> int use_hw_cursor = 0;
> module_parm(use_hw_cursor);
>
> if (fb_info->fb_cursor && use_hw_cursor)
> fb_info->fb_cursor(...)
> else
> softcursor
>
> >
> > P.S
> > The patch still needs to broken into smaller pieces.
> >
> >
> >
>
>
> --
> Jon Smirl
> jonsmirl@gmail.com
>
--
Jon Smirl
jonsmirl@gmail.com
-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [PATCH] mach64 atari patch
2005-08-07 2:27 [PATCH] mach64 atari patch James Simmons
2005-08-07 11:39 ` Geert Uytterhoeven
@ 2005-08-08 19:49 ` Alexander Kern
1 sibling, 0 replies; 21+ messages in thread
From: Alexander Kern @ 2005-08-08 19:49 UTC (permalink / raw)
To: linux-fbdev-devel; +Cc: James Simmons
Am Sonntag, 7. August 2005 04:27 schrieb James Simmons:
As long it not breaks PCI based Mach64, I am happy
Acked-by: Alexander Kern <alex.kern@gmx.de>
> This patch makes the mach64 chip a platform device so sysfs can work with
> it.
>
> Signed-off-by: James Simmons <jsimmons@infradead.org>
>
> diff -urN -X /home/jsimmons/dontdiff
> linus-2.6/drivers/video/aty/atyfb_base.c
> fbdev-2.6/drivers/video/aty/atyfb_base.c ---
> linus-2.6/drivers/video/aty/atyfb_base.c 2005-07-11 10:07:21.000000000
> -0700 +++ fbdev-2.6/drivers/video/aty/atyfb_base.c 2005-07-27
> 08:41:24.000000000 -0700 @@ -244,9 +244,6 @@
> */
>
> static int aty_init(struct fb_info *info, const char *name);
> -#ifdef CONFIG_ATARI
> -static int store_video_par(char *videopar, unsigned char m64_num);
> -#endif
>
> static struct crtc saved_crtc;
> static union aty_pll saved_pll;
> @@ -321,10 +318,8 @@
> #endif
>
> #ifdef CONFIG_ATARI
> -static unsigned int mach64_count __initdata = 0;
> -static unsigned long phys_vmembase[FB_MAX] __initdata = { 0, };
> -static unsigned long phys_size[FB_MAX] __initdata = { 0, };
> -static unsigned long phys_guiregbase[FB_MAX] __initdata = { 0, };
> +static struct mach64_device* __init store_video_par(char *video_str,
> unsigned char m64_num) +static LIST_HEAD(mach64_list);
> #endif
>
> /* top -> down is an evolution of mach64 chipset, any corrections? */
> @@ -2170,8 +2165,6 @@
> * Initialisation
> */
>
> -static struct fb_info *fb_list = NULL;
> -
> static int __init aty_init(struct fb_info *info, const char *name)
> {
> struct atyfb_par *par = (struct atyfb_par *) info->par;
> @@ -2562,8 +2555,6 @@
> if (register_framebuffer(info) < 0)
> goto aty_init_exit;
>
> - fb_list = info;
> -
> PRINTKI("fb%d: %s frame buffer device on %s\n",
> info->node, info->fix.id, name);
> return 0;
> @@ -2587,10 +2578,13 @@
> }
>
> #ifdef CONFIG_ATARI
> -static int __init store_video_par(char *video_str, unsigned char m64_num)
> +static struct mach64_device* __init store_video_par(char *video_str,
> unsigned char m64_num) {
> - char *p;
> unsigned long vmembase, size, guiregbase;
> + struct platform_device *atyfb_device;
> + struct mach64_device *device;
> + struct resource io[2];
> + char *p;
>
> PRINTKI("store_video_par() '%s' \n", video_str);
>
> @@ -2604,16 +2598,18 @@
> goto mach64_invalid;
> guiregbase = simple_strtoul(p, NULL, 0);
>
> - phys_vmembase[m64_num] = vmembase;
> - phys_size[m64_num] = size;
> - phys_guiregbase[m64_num] = guiregbase;
> - PRINTKI("stored them all: $%08lX $%08lX $%08lX \n", vmembase, size,
> - guiregbase);
> - return 0;
> + io[0] = request_mem_region(vmembase, size, "atyfb");
> + io[1] = request_mem_region(guiregbase, 0x10000, "atyfb");
>
> - mach64_invalid:
> - phys_vmembase[m64_num] = 0;
> - return -1;
> + atyfb_device = platform_device_register_simple("atyfb", m64_num, io, 2);
> + if (IS_ERR(atyfb_device))
> + return PTR_ERR(atyfb_device);
> +
> + device = kmalloc(sizeof(struct mach64_device), GFP_KERNEL);
> + PRINTKI("stored them all: $%08lX $%08lX $%08lX \n", vmembase, size,
> guiregbase); + return device;
> +mach64_invalid:
> + return NULL;
> }
> #endif /* CONFIG_ATARI */
>
> @@ -2679,17 +2675,10 @@
> static void aty_st_pal(u_int regno, u_int red, u_int green, u_int blue,
> const struct atyfb_par *par)
> {
> -#ifdef CONFIG_ATARI
> - out_8(&par->aty_cmap_regs->windex, regno);
> - out_8(&par->aty_cmap_regs->lut, red);
> - out_8(&par->aty_cmap_regs->lut, green);
> - out_8(&par->aty_cmap_regs->lut, blue);
> -#else
> writeb(regno, &par->aty_cmap_regs->windex);
> writeb(red, &par->aty_cmap_regs->lut);
> writeb(green, &par->aty_cmap_regs->lut);
> writeb(blue, &par->aty_cmap_regs->lut);
> -#endif
> }
>
> /*
> @@ -3456,47 +3445,43 @@
>
> #ifdef CONFIG_ATARI
>
> -static int __devinit atyfb_atari_probe(void)
> +static int __devinit atyfb_atari_probe(struct device *device)
> {
> - struct aty_par *par;
> + struct platform_device *dev = to_platform_device(device);
> struct fb_info *info;
> - int m64_num;
> + struct aty_par *par;
> + int size = 0;
> u32 clock_r;
>
> - for (m64_num = 0; m64_num < mach64_count; m64_num++) {
> - if (!phys_vmembase[m64_num] || !phys_size[m64_num] ||
> - !phys_guiregbase[m64_num]) {
> - PRINTKI("phys_*[%d] parameters not set => returning early. \n",
> m64_num); - continue;
> - }
> -
> - info = framebuffer_alloc(sizeof(struct atyfb_par), NULL);
> - if (!info) {
> - PRINTKE("atyfb_atari_probe() can't alloc fb_info\n");
> - return -ENOMEM;
> - }
> - par = info->par;
> + info = framebuffer_alloc(sizeof(struct atyfb_par), &dev->dev);
> + if (!info) {
> + PRINTKE("atyfb_atari_probe() can't alloc fb_info\n");
> + return -ENOMEM;
> + }
> + par = info->par;
>
> - info->fix = atyfb_fix;
> + info->fix = atyfb_fix;
>
> - par->irq = (unsigned int) -1; /* something invalid */
> + par->irq = (unsigned int) -1; /* something invalid */
>
> - /*
> - * Map the video memory (physical address given) to somewhere in the
> - * kernel address space.
> - */
> - info->screen_base = ioremap(phys_vmembase[m64_num], phys_size[m64_num]);
> - info->fix.smem_start = (unsigned long)info->screen_base; /* Fake! */
> - par->ati_regbase = ioremap(phys_guiregbase[m64_num], 0x10000) +
> - 0xFC00ul;
> - info->fix.mmio_start = (unsigned long)par->ati_regbase; /* Fake! */
> -
> - aty_st_le32(CLOCK_CNTL, 0x12345678, par);
> - clock_r = aty_ld_le32(CLOCK_CNTL, par);
> -
> - switch (clock_r & 0x003F) {
> - case 0x12:
> - par->clk_wr_offset = 3; /* */
> + /*
> + * Map the video memory (physical address given) to somewhere in the
> + * kernel address space.
> + */
> + size = dev->resource[0].start - dev->resource[0].end;
> + info->fix.smem_start = dev->resource[0].start;
> + info->screen_base = ioremap(dev->resource[0], size);
> +
> + size = 0x10000;
> + info->fix.mmio_start = dev->resource[1].start + 0xFC00ul;
> + par->ati_regbase = ioremap(dev->resource[1], size) + 0xFC00ul;
> +
> + aty_st_le32(CLOCK_CNTL, 0x12345678, par);
> + clock_r = aty_ld_le32(CLOCK_CNTL, par);
> +
> + switch (clock_r & 0x003F) {
> + case 0x12:
> + par->clk_wr_offset = 3; /* */
> break;
> case 0x34:
> par->clk_wr_offset = 2; /* Medusa ST-IO ISA Adapter etc. */
> @@ -3595,6 +3580,23 @@
>
> #endif /* CONFIG_PCI */
>
> +#ifdef CONFIG_ATARI
> +
> +static struct device_driver atyfb_driver = {
> + .name = "atyfb",
> + .probe = atyfb_atari_probe,
> + .remove = __devexit_p(atyfb_atari_remove),
> +}
> +
> +static void __devexit atyfb_atari_remove(struct device *dev)
> +{
> + struct fb_info *info = dev_get_drvdata(dev);
> +
> + atyfb_remove(info);
> +}
> +
> +#endif /* CONFIG_ATARI */
> +
> #ifndef MODULE
> static int __init atyfb_setup(char *options)
> {
> @@ -3650,15 +3652,15 @@
> * Why do we need this silly Mach64 argument?
> * We are already here because of mach64= so its redundant.
> */
> - else if (MACH_IS_ATARI
> - && (!strncmp(this_opt, "Mach64:", 7))) {
> - static unsigned char m64_num;
> - static char mach64_str[80];
> + else if (MACH_IS_ATARI && (!strncmp(this_opt, "Mach64:", 7))) {
> + struct mach64_device *dev;
> + unsigned char m64_num = 0;
> + char mach64_str[80];
> +
> strlcpy(mach64_str, this_opt + 7, sizeof(mach64_str));
> - if (!store_video_par(mach64_str, m64_num)) {
> - m64_num++;
> - mach64_count = m64_num;
> - }
> + dev = store_video_par(mach64_str, m64_num++);
> + if (dev != null)
> + list_add_tail(dev->node, &mach64_list);
> }
> #endif
> else
> @@ -3670,6 +3672,8 @@
>
> static int __init atyfb_init(void)
> {
> + int retval = 0;
> +
> #ifndef MODULE
> char *option = NULL;
>
> @@ -3679,16 +3683,34 @@
> #endif
>
> #ifdef CONFIG_PCI
> - pci_register_driver(&atyfb_driver);
> + retval = pci_register_driver(&atyfb_driver);
> #endif
> #ifdef CONFIG_ATARI
> - atyfb_atari_probe();
> + retval = driver_register(&atyfb_driver);
> + if (retval < 0) {
> + struct platform_device *device;
> +
> + list_for_each_safe(device, &mach64_list, node) {
> + platform_device_unregister(&device->dev);
> + kfree(device);
> + }
> + }
> #endif
> - return 0;
> + return retval;
> }
>
> static void __exit atyfb_exit(void)
> {
> +#ifdef CONFIG_ATARI
> + struct platform_device *device;
> +
> + list_for_each_safe(device, &mach64_list, node) {
> + platform_device_unregister(&device->dev);
> + kfree(device);
> + }
> + driver_unregister(&atyfb_driver);
> +#endif
> +
> #ifdef CONFIG_PCI
> pci_unregister_driver(&atyfb_driver);
> #endif
> diff -urN -X /home/jsimmons/dontdiff linus-2.6/drivers/video/aty/atyfb.h
> fbdev-2.6/drivers/video/aty/atyfb.h ---
> linus-2.6/drivers/video/aty/atyfb.h 2005-07-11 10:07:21.000000000 -0700 +++
> fbdev-2.6/drivers/video/aty/atyfb.h 2005-07-22 15:36:41.000000000 -0700 @@
> -187,6 +187,13 @@
> #endif
> };
>
> +#ifdef CONFIG_ATARI
> +struct mach64_device {
> + struct list_head node;
> + struct platform_device *dev;
> +};
> +#endif
> +
> /*
> * ATI Mach64 features
> */
>
>
> -------------------------------------------------------
> SF.Net email is Sponsored by the Better Software Conference & EXPO
> September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
> Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
> Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
> _______________________________________________
> Linux-fbdev-devel mailing list
> Linux-fbdev-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/linux-fbdev-devel
--
Best Wishes
Mit freundlichen Grüßen
Alex Kern
-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Re: [PATCH] mach64 atari patch
2005-08-08 18:15 ` James Simmons
2005-08-08 18:34 ` Jon Smirl
@ 2005-08-08 23:55 ` Antonino A. Daplas
1 sibling, 0 replies; 21+ messages in thread
From: Antonino A. Daplas @ 2005-08-08 23:55 UTC (permalink / raw)
To: linux-fbdev-devel
Cc: Jon Smirl, Geert Uytterhoeven, Antonino A. Daplas, Andrew Morton
James Simmons wrote:
>>>> I just don't think this patch is as complex as you are making it out
>>>> to be. It is large simply because the same action has been repeated
>>>> for each of the 65 drivers. The action is only a simple deletion of
>>>> two lines.
>>> I'm not arguing over this. What is wrong with breaking this patch up!!!!!
>>> I still have no answer to this!!!! I'm using the hardware flag because
>>> sometimes the driver that does have a hardware cursor wants to turn
>>> support off for it.
>> Set .fb_cursor = NULL; to turn off the support.
>
> So forbid hardware drivers that support hware cursors to never turn off
> there hardware cursor support!!!!!
>
> Let see what drivers have a flag to control using the hardware cursor.
>
> au1100fb int nohwcursor
> intelfb int hwcursor
> nvidia int hwcur
> cyberfb
>
> You need to remove this!!!!
>
Majority of the drivers that does support hardware cursors are written by myself.
If the driver does not want to turn on the hardware cursor, just return -ENODEV.
No need to fudge with pointers.
Tony
-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Re: [PATCH] mach64 atari patch
2005-08-07 23:31 ` Antonino A. Daplas
2005-08-07 23:48 ` Jon Smirl
@ 2005-08-09 0:04 ` James Simmons
2005-08-09 0:59 ` Antonino A. Daplas
2005-08-09 1:04 ` Jon Smirl
1 sibling, 2 replies; 21+ messages in thread
From: James Simmons @ 2005-08-09 0:04 UTC (permalink / raw)
To: linux-fbdev-devel; +Cc: Geert Uytterhoeven, Antonino A. Daplas, Andrew Morton
> Please, my patch (based from Jon's) is huge because it's removing > 200 lines
> and it's moving softcursor.c from drivers/video to drivers/video/console where
> it belongs. But it is _not_ intrusive. In fact, the majority of the patch consists
> of a single logical change which removes the line below from each driver
>
> - .fb_cursor = softcursor;
>
> and removes the line below from drivers/video/Kconfig.
>
> - select FB_SOFT_CURSOR
>
> Our proposal aims to make complex code simpler and big code smaller. Your patch,
> on the other hand, although small, introduces another flag FB_HWCURSOR_SOFTCURSOR,
> which is redundant, and adds yet another level of complexity to an already too
> complex code.
I ask you the same question as Jon. Currently several fbdev drivers have a
optional flag to turn on and off the hardware cursor. Should this functionality
be removed and force all fbdev drivers to always have the hardware cursor
avaiable. Thus leaving fbcon to control when to use the hardware cursor
or the software cursor. It all comes down to who controls when the
hardware driver will use the hardware cursor. As noted several drivers
have such a flag. You would have to strip that flag out of the drivers as
well.
-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Re: [PATCH] mach64 atari patch
2005-08-09 0:04 ` James Simmons
@ 2005-08-09 0:59 ` Antonino A. Daplas
2005-08-09 1:08 ` Antonino A. Daplas
2005-08-09 8:05 ` Geert Uytterhoeven
2005-08-09 1:04 ` Jon Smirl
1 sibling, 2 replies; 21+ messages in thread
From: Antonino A. Daplas @ 2005-08-09 0:59 UTC (permalink / raw)
To: James Simmons
Cc: linux-fbdev-devel, Geert Uytterhoeven, Antonino A. Daplas,
Andrew Morton
James Simmons wrote:
>> Please, my patch (based from Jon's) is huge because it's removing > 200 lines
>> and it's moving softcursor.c from drivers/video to drivers/video/console where
>> it belongs. But it is _not_ intrusive. In fact, the majority of the patch consists
>> of a single logical change which removes the line below from each driver
>>
>> - .fb_cursor = softcursor;
>>
>> and removes the line below from drivers/video/Kconfig.
>>
>> - select FB_SOFT_CURSOR
>>
>> Our proposal aims to make complex code simpler and big code smaller. Your patch,
>> on the other hand, although small, introduces another flag FB_HWCURSOR_SOFTCURSOR,
>> which is redundant, and adds yet another level of complexity to an already too
>> complex code.
>>
>
> I ask you the same question as Jon. Currently several fbdev drivers have a
> optional flag to turn on and off the hardware cursor. Should this functionality
> be removed and force all fbdev drivers to always have the hardware cursor
> avaiable. Thus leaving fbcon to control when to use the hardware cursor
> or the software cursor. It all comes down to who controls when the
> hardware driver will use the hardware cursor. As noted several drivers
> have such a flag. You would have to strip that flag out of the drivers as
> well.
>
> .
>
>
BTW, the only drivers that have working hardware cursor support are
rivafb, intelfb,
nvidiafb, and i810fb. Except for intelfb, I wrote all of them, if not
the driver, the
hardware cursor support. And intelfb's cursor support was based on i810fb.
To answer your question, drivers can do either of two things:
1. If they don't want to use the hardware cursor, set
info->fbops->fb_cursor = NULL
in fb_set_par();
2. Or, they can keep info->fbops->fb_cursor() as is, but the function
will return
-ENODEV instead.
The end result is if info->fbops->fb_cursor == NULL, fbcon will call
soft_cursor.
Or if the return value of info->fb_ops->fb_cursor is not equal to zero,
fbcon will
call soft_cursor.
Either way, control remains with the driver, not fbcon.
Tony
-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Re: [PATCH] mach64 atari patch
2005-08-09 0:04 ` James Simmons
2005-08-09 0:59 ` Antonino A. Daplas
@ 2005-08-09 1:04 ` Jon Smirl
1 sibling, 0 replies; 21+ messages in thread
From: Jon Smirl @ 2005-08-09 1:04 UTC (permalink / raw)
To: linux-fbdev-devel; +Cc: Geert Uytterhoeven, Antonino A. Daplas, Andrew Morton
On 8/8/05, James Simmons <jsimmons@infradead.org> wrote:
>
> > Please, my patch (based from Jon's) is huge because it's removing > 200 lines
> > and it's moving softcursor.c from drivers/video to drivers/video/console where
> > it belongs. But it is _not_ intrusive. In fact, the majority of the patch consists
> > of a single logical change which removes the line below from each driver
> >
> > - .fb_cursor = softcursor;
> >
> > and removes the line below from drivers/video/Kconfig.
> >
> > - select FB_SOFT_CURSOR
> >
> > Our proposal aims to make complex code simpler and big code smaller. Your patch,
> > on the other hand, although small, introduces another flag FB_HWCURSOR_SOFTCURSOR,
> > which is redundant, and adds yet another level of complexity to an already too
> > complex code.
>
> I ask you the same question as Jon. Currently several fbdev drivers have a
> optional flag to turn on and off the hardware cursor. Should this functionality
In the current code I don't view that flag as turning the hardware
cursor on/off. Instead I view it as choosing to use the software or
hardware cursor. In my view the flag should be eliminated form fbdev.
If a driver has a hardware cursor it is always exposed.
fbconsole is then free to implement the flag if it chooses.
> be removed and force all fbdev drivers to always have the hardware cursor
> avaiable. Thus leaving fbcon to control when to use the hardware cursor
> or the software cursor. It all comes down to who controls when the
> hardware driver will use the hardware cursor. As noted several drivers
> have such a flag. You would have to strip that flag out of the drivers as
> well.
--
Jon Smirl
jonsmirl@gmail.com
-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Re: [PATCH] mach64 atari patch
2005-08-09 0:59 ` Antonino A. Daplas
@ 2005-08-09 1:08 ` Antonino A. Daplas
2005-08-09 8:05 ` Geert Uytterhoeven
1 sibling, 0 replies; 21+ messages in thread
From: Antonino A. Daplas @ 2005-08-09 1:08 UTC (permalink / raw)
To: Antonino A. Daplas
Cc: James Simmons, linux-fbdev-devel, Geert Uytterhoeven,
Antonino A. Daplas, Andrew Morton
Antonino A. Daplas wrote:
> James Simmons wrote:
>>> Please, my patch (based from Jon's) is huge because it's removing >
>>> 200 lines
>>> and it's moving softcursor.c from drivers/video to
>>> drivers/video/console where
>>> it belongs. But it is _not_ intrusive. In fact, the majority of the
>>> patch consists
>>> of a single logical change which removes the line below from each
>>> driver
>>>
>>> - .fb_cursor = softcursor;
>>>
>>> and removes the line below from drivers/video/Kconfig.
>>>
>>> - select FB_SOFT_CURSOR
>>>
>>> Our proposal aims to make complex code simpler and big code smaller.
>>> Your patch,
>>> on the other hand, although small, introduces another flag
>>> FB_HWCURSOR_SOFTCURSOR,
>>> which is redundant, and adds yet another level of complexity to an
>>> already too
>>> complex code.
>>
>> I ask you the same question as Jon. Currently several fbdev drivers
>> have a optional flag to turn on and off the hardware cursor. Should
>> this functionality
>> be removed and force all fbdev drivers to always have the hardware
>> cursor avaiable. Thus leaving fbcon to control when to use the
>> hardware cursor or the software cursor. It all comes down to who
>> controls when the hardware driver will use the hardware cursor. As
>> noted several drivers have such a flag. You would have to strip that
>> flag out of the drivers as well.
>>
>> .
>>
> BTW, the only drivers that have working hardware cursor support are
> rivafb, intelfb,
> nvidiafb, and i810fb. Except for intelfb, I wrote all of them, if not
> the driver, the
> hardware cursor support. And intelfb's cursor support was based on
> i810fb.
Erratum: Mach64 also has hardware cursor support, which looks like is
working. So
I take the above statement back.
Tony
-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Re: [PATCH] mach64 atari patch
2005-08-09 0:59 ` Antonino A. Daplas
2005-08-09 1:08 ` Antonino A. Daplas
@ 2005-08-09 8:05 ` Geert Uytterhoeven
1 sibling, 0 replies; 21+ messages in thread
From: Geert Uytterhoeven @ 2005-08-09 8:05 UTC (permalink / raw)
To: Antonino A. Daplas
Cc: James Simmons, Linux Frame Buffer Device Development,
Antonino A. Daplas, Andrew Morton
On Tue, 9 Aug 2005, Antonino A. Daplas wrote:
> James Simmons wrote:
> 1. If they don't want to use the hardware cursor, set info->fbops->fb_cursor =
> NULL
> in fb_set_par();
Hence that fbops cannot be shared between multiple instances of the same
frame buffer device that need different values for fbops->fb_cursor.
> 2. Or, they can keep info->fbops->fb_cursor() as is, but the function will
> return
> -ENODEV instead.
So this one looks better to me, since it doesn't suffer from the limitation of
1.
(I'm thinking of hardware where the availability of a hardware cursor depends
on the video mode, e.g. the good old Amiga graphics)
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [PATCH] mach64 atari patch
2005-08-07 11:39 ` Geert Uytterhoeven
2005-08-07 16:46 ` Andrew Morton
@ 2005-08-12 17:47 ` James Simmons
1 sibling, 0 replies; 21+ messages in thread
From: James Simmons @ 2005-08-12 17:47 UTC (permalink / raw)
To: Geert Uytterhoeven; +Cc: Linux Fbdev development list, Antonino A. Daplas
Give this patch a try. It includes your fixes.
diff -urN -X /home/jsimmons/dontdiff linus-2.6/drivers/video/aty/atyfb_base.c fbdev-2.6/drivers/video/aty/atyfb_base.c
--- linus-2.6/drivers/video/aty/atyfb_base.c 2005-07-11 10:07:21.000000000 -0700
+++ fbdev-2.6/drivers/video/aty/atyfb_base.c 2005-08-12 10:37:08.000000000 -0700
@@ -244,9 +244,6 @@
*/
static int aty_init(struct fb_info *info, const char *name);
-#ifdef CONFIG_ATARI
-static int store_video_par(char *videopar, unsigned char m64_num);
-#endif
static struct crtc saved_crtc;
static union aty_pll saved_pll;
@@ -321,10 +318,8 @@
#endif
#ifdef CONFIG_ATARI
-static unsigned int mach64_count __initdata = 0;
-static unsigned long phys_vmembase[FB_MAX] __initdata = { 0, };
-static unsigned long phys_size[FB_MAX] __initdata = { 0, };
-static unsigned long phys_guiregbase[FB_MAX] __initdata = { 0, };
+static struct mach64_device* __init store_video_par(char *video_str, unsigned char m64_num);
+static LIST_HEAD(mach64_list);
#endif
/* top -> down is an evolution of mach64 chipset, any corrections? */
@@ -2170,8 +2165,6 @@
* Initialisation
*/
-static struct fb_info *fb_list = NULL;
-
static int __init aty_init(struct fb_info *info, const char *name)
{
struct atyfb_par *par = (struct atyfb_par *) info->par;
@@ -2562,8 +2555,6 @@
if (register_framebuffer(info) < 0)
goto aty_init_exit;
- fb_list = info;
-
PRINTKI("fb%d: %s frame buffer device on %s\n",
info->node, info->fix.id, name);
return 0;
@@ -2586,37 +2577,6 @@
return -1;
}
-#ifdef CONFIG_ATARI
-static int __init store_video_par(char *video_str, unsigned char m64_num)
-{
- char *p;
- unsigned long vmembase, size, guiregbase;
-
- PRINTKI("store_video_par() '%s' \n", video_str);
-
- if (!(p = strsep(&video_str, ";")) || !*p)
- goto mach64_invalid;
- vmembase = simple_strtoul(p, NULL, 0);
- if (!(p = strsep(&video_str, ";")) || !*p)
- goto mach64_invalid;
- size = simple_strtoul(p, NULL, 0);
- if (!(p = strsep(&video_str, ";")) || !*p)
- goto mach64_invalid;
- guiregbase = simple_strtoul(p, NULL, 0);
-
- phys_vmembase[m64_num] = vmembase;
- phys_size[m64_num] = size;
- phys_guiregbase[m64_num] = guiregbase;
- PRINTKI("stored them all: $%08lX $%08lX $%08lX \n", vmembase, size,
- guiregbase);
- return 0;
-
- mach64_invalid:
- phys_vmembase[m64_num] = 0;
- return -1;
-}
-#endif /* CONFIG_ATARI */
-
/*
* Blank the display.
*/
@@ -2771,6 +2731,48 @@
return 0;
}
+static void __devexit atyfb_remove(struct fb_info *info)
+{
+ struct atyfb_par *par = (struct atyfb_par *) info->par;
+
+ /* restore video mode */
+ aty_set_crtc(par, &saved_crtc);
+ par->pll_ops->set_pll(info, &saved_pll);
+
+ unregister_framebuffer(info);
+
+#ifdef CONFIG_MTRR
+ if (par->mtrr_reg >= 0) {
+ mtrr_del(par->mtrr_reg, 0, 0);
+ par->mtrr_reg = -1;
+ }
+ if (par->mtrr_aper >= 0) {
+ mtrr_del(par->mtrr_aper, 0, 0);
+ par->mtrr_aper = -1;
+ }
+#endif
+#ifndef __sparc__
+ if (par->ati_regbase)
+ iounmap(par->ati_regbase);
+ if (info->screen_base)
+ iounmap(info->screen_base);
+#ifdef __BIG_ENDIAN
+ if (info->sprite.addr)
+ iounmap(info->sprite.addr);
+#endif
+#endif
+#ifdef __sparc__
+ kfree(par->mmap_map);
+#endif
+ if (par->aux_start)
+ release_mem_region(par->aux_start, par->aux_size);
+
+ if (par->res_start)
+ release_mem_region(par->res_start, par->res_size);
+
+ framebuffer_release(info);
+}
+
#ifdef CONFIG_PCI
#ifdef __sparc__
@@ -3452,49 +3454,115 @@
return rc;
}
+static void __devexit atyfb_pci_remove(struct pci_dev *pdev)
+{
+ struct fb_info *info = pci_get_drvdata(pdev);
+
+ atyfb_remove(info);
+}
+
+/*
+ * This driver uses its own matching table. That will be more difficult
+ * to fix, so for now, we just match against any ATI ID and let the
+ * probe() function find out what's up. That also mean we don't have
+ * a module ID table though.
+ */
+static struct pci_device_id atyfb_pci_tbl[] = {
+ { PCI_VENDOR_ID_ATI, PCI_ANY_ID, PCI_ANY_ID, PCI_ANY_ID,
+ PCI_BASE_CLASS_DISPLAY << 16, 0xff0000, 0 },
+ { 0, }
+};
+
+static struct pci_driver atyfb_driver = {
+ .name = "atyfb",
+ .id_table = atyfb_pci_tbl,
+ .probe = atyfb_pci_probe,
+ .remove = __devexit_p(atyfb_pci_remove),
+#ifdef CONFIG_PM
+ .suspend = atyfb_pci_suspend,
+ .resume = atyfb_pci_resume,
+#endif /* CONFIG_PM */
+};
+
#endif /* CONFIG_PCI */
#ifdef CONFIG_ATARI
-static int __devinit atyfb_atari_probe(void)
+static struct mach64_device* __init store_video_par(char *video_str, unsigned char m64_num)
{
- struct aty_par *par;
+ unsigned long vmembase, size, guiregbase;
+ struct platform_device *atyfb_device;
+ struct mach64_device *device;
+ struct resource *io[2];
+ char *p;
+
+ PRINTKI("store_video_par() '%s' \n", video_str);
+
+ if (!(p = strsep(&video_str, ";")) || !*p)
+ goto mach64_invalid;
+ vmembase = simple_strtoul(p, NULL, 0);
+ if (!(p = strsep(&video_str, ";")) || !*p)
+ goto mach64_invalid;
+ size = simple_strtoul(p, NULL, 0);
+ if (!(p = strsep(&video_str, ";")) || !*p)
+ goto mach64_invalid;
+ guiregbase = simple_strtoul(p, NULL, 0);
+
+ io[0] = request_mem_region(vmembase, size, "atyfb");
+ if (!io[0])
+ return NULL;
+ io[1] = request_mem_region(guiregbase, 0x10000, "atyfb");
+ if (!io[1]) {
+ release_resource(io[0]);
+ return NULL;
+ }
+
+ atyfb_device = platform_device_register_simple("atyfb", m64_num, io, 2);
+ if (IS_ERR(atyfb_device))
+ return NULL;
+
+ device = kmalloc(sizeof(struct mach64_device), GFP_KERNEL);
+ PRINTKI("stored them all: $%08lX $%08lX $%08lX \n", vmembase, size, guiregbase);
+ return device;
+mach64_invalid:
+ return NULL;
+}
+
+static int __devinit atyfb_atari_probe(struct device *device)
+{
+ struct platform_device *dev = to_platform_device(device);
struct fb_info *info;
- int m64_num;
+ struct aty_par *par;
+ int size = 0;
u32 clock_r;
- for (m64_num = 0; m64_num < mach64_count; m64_num++) {
- if (!phys_vmembase[m64_num] || !phys_size[m64_num] ||
- !phys_guiregbase[m64_num]) {
- PRINTKI("phys_*[%d] parameters not set => returning early. \n", m64_num);
- continue;
- }
-
- info = framebuffer_alloc(sizeof(struct atyfb_par), NULL);
- if (!info) {
- PRINTKE("atyfb_atari_probe() can't alloc fb_info\n");
- return -ENOMEM;
- }
- par = info->par;
+ info = framebuffer_alloc(sizeof(struct atyfb_par), &dev->dev);
+ if (!info) {
+ PRINTKE("atyfb_atari_probe() can't alloc fb_info\n");
+ return -ENOMEM;
+ }
+ par = info->par;
- info->fix = atyfb_fix;
+ info->fix = atyfb_fix;
- par->irq = (unsigned int) -1; /* something invalid */
+ par->irq = (unsigned int) -1; /* something invalid */
- /*
- * Map the video memory (physical address given) to somewhere in the
- * kernel address space.
- */
- info->screen_base = ioremap(phys_vmembase[m64_num], phys_size[m64_num]);
- info->fix.smem_start = (unsigned long)info->screen_base; /* Fake! */
- par->ati_regbase = ioremap(phys_guiregbase[m64_num], 0x10000) +
- 0xFC00ul;
- info->fix.mmio_start = (unsigned long)par->ati_regbase; /* Fake! */
+ /*
+ * Map the video memory (physical address given) to somewhere in the
+ * kernel address space.
+ */
+ size = dev->resource[0].start - dev->resource[0].end + 1;
+ info->fix.smem_start = dev->resource[0].start;
+ info->screen_base = ioremap(dev->resource[0].start, size);
+
+ size = 0x10000;
+ info->fix.mmio_start = dev->resource[1].start + 0xFC00ul;
+ par->ati_regbase = ioremap(dev->resource[1].start, size) + 0xFC00ul;
- aty_st_le32(CLOCK_CNTL, 0x12345678, par);
- clock_r = aty_ld_le32(CLOCK_CNTL, par);
+ aty_st_le32(CLOCK_CNTL, 0x12345678, par);
+ clock_r = aty_ld_le32(CLOCK_CNTL, par);
- switch (clock_r & 0x003F) {
+ switch (clock_r & 0x003F) {
case 0x12:
par->clk_wr_offset = 3; /* */
break;
@@ -3508,92 +3576,29 @@
par->clk_wr_offset = 0; /* Panther 1 ISA Adapter (Gerald) */
break;
}
-
- if (aty_init(info, "ISA bus")) {
- framebuffer_release(info);
- /* This is insufficient! kernel_map has added two large chunks!! */
- return -ENXIO;
- }
}
-}
-
-#endif /* CONFIG_ATARI */
-
-static void __devexit atyfb_remove(struct fb_info *info)
-{
- struct atyfb_par *par = (struct atyfb_par *) info->par;
- /* restore video mode */
- aty_set_crtc(par, &saved_crtc);
- par->pll_ops->set_pll(info, &saved_pll);
-
- unregister_framebuffer(info);
-
-#ifdef CONFIG_MTRR
- if (par->mtrr_reg >= 0) {
- mtrr_del(par->mtrr_reg, 0, 0);
- par->mtrr_reg = -1;
- }
- if (par->mtrr_aper >= 0) {
- mtrr_del(par->mtrr_aper, 0, 0);
- par->mtrr_aper = -1;
+ if (aty_init(info, "ISA bus")) {
+ framebuffer_release(info);
+ /* This is insufficient! kernel_map has added two large chunks!! */
+ return -ENXIO;
}
-#endif
-#ifndef __sparc__
- if (par->ati_regbase)
- iounmap(par->ati_regbase);
- if (info->screen_base)
- iounmap(info->screen_base);
-#ifdef __BIG_ENDIAN
- if (info->sprite.addr)
- iounmap(info->sprite.addr);
-#endif
-#endif
-#ifdef __sparc__
- kfree(par->mmap_map);
-#endif
- if (par->aux_start)
- release_mem_region(par->aux_start, par->aux_size);
-
- if (par->res_start)
- release_mem_region(par->res_start, par->res_size);
-
- framebuffer_release(info);
}
-#ifdef CONFIG_PCI
-
-static void __devexit atyfb_pci_remove(struct pci_dev *pdev)
+static void __devexit atyfb_atari_remove(struct device *dev)
{
- struct fb_info *info = pci_get_drvdata(pdev);
+ struct fb_info *info = dev_get_drvdata(dev);
atyfb_remove(info);
}
-/*
- * This driver uses its own matching table. That will be more difficult
- * to fix, so for now, we just match against any ATI ID and let the
- * probe() function find out what's up. That also mean we don't have
- * a module ID table though.
- */
-static struct pci_device_id atyfb_pci_tbl[] = {
- { PCI_VENDOR_ID_ATI, PCI_ANY_ID, PCI_ANY_ID, PCI_ANY_ID,
- PCI_BASE_CLASS_DISPLAY << 16, 0xff0000, 0 },
- { 0, }
-};
-
-static struct pci_driver atyfb_driver = {
+static struct device_driver atyfb_driver = {
.name = "atyfb",
- .id_table = atyfb_pci_tbl,
- .probe = atyfb_pci_probe,
- .remove = __devexit_p(atyfb_pci_remove),
-#ifdef CONFIG_PM
- .suspend = atyfb_pci_suspend,
- .resume = atyfb_pci_resume,
-#endif /* CONFIG_PM */
+ .probe = atyfb_atari_probe,
+ .remove = __devexit_p(atyfb_atari_remove),
};
-#endif /* CONFIG_PCI */
+#endif /* CONFIG_ATARI */
#ifndef MODULE
static int __init atyfb_setup(char *options)
@@ -3650,15 +3655,15 @@
* Why do we need this silly Mach64 argument?
* We are already here because of mach64= so its redundant.
*/
- else if (MACH_IS_ATARI
- && (!strncmp(this_opt, "Mach64:", 7))) {
- static unsigned char m64_num;
- static char mach64_str[80];
+ else if (MACH_IS_ATARI && (!strncmp(this_opt, "Mach64:", 7))) {
+ struct mach64_device *dev;
+ unsigned char m64_num = 0;
+ char mach64_str[80];
+
strlcpy(mach64_str, this_opt + 7, sizeof(mach64_str));
- if (!store_video_par(mach64_str, m64_num)) {
- m64_num++;
- mach64_count = m64_num;
- }
+ dev = store_video_par(mach64_str, m64_num++);
+ if (dev != NULL)
+ list_add_tail(&dev->node, &mach64_list);
}
#endif
else
@@ -3670,6 +3675,8 @@
static int __init atyfb_init(void)
{
+ int retval = 0;
+
#ifndef MODULE
char *option = NULL;
@@ -3679,16 +3686,38 @@
#endif
#ifdef CONFIG_PCI
- pci_register_driver(&atyfb_driver);
+ retval = pci_register_driver(&atyfb_driver);
#endif
#ifdef CONFIG_ATARI
- atyfb_atari_probe();
+ retval = driver_register(&atyfb_driver);
+ if (retval < 0) {
+ struct mach64_device *device;
+ struct list_head *p, *q;
+
+ list_for_each_safe(p, q, &mach64_list) {
+ device = list_entry(p, struct mach64_device, node);
+ platform_device_unregister(&device->dev);
+ kfree(device);
+ }
+ }
#endif
- return 0;
+ return retval;
}
static void __exit atyfb_exit(void)
{
+#ifdef CONFIG_ATARI
+ struct mach64_device *device;
+ struct list_head *p, *q;
+
+ list_for_each_safe(p, q, &mach64_list) {
+ device = list_entry(p, struct mach64_device, node);
+ platform_device_unregister(&device->dev);
+ kfree(device);
+ }
+ driver_unregister(&atyfb_driver);
+#endif
+
#ifdef CONFIG_PCI
pci_unregister_driver(&atyfb_driver);
#endif
@@ -3718,3 +3747,4 @@
module_param(nomtrr, bool, 0);
MODULE_PARM_DESC(nomtrr, "bool: disable use of MTRR registers");
#endif
+
diff -urN -X /home/jsimmons/dontdiff linus-2.6/drivers/video/aty/atyfb.h fbdev-2.6/drivers/video/aty/atyfb.h
--- linus-2.6/drivers/video/aty/atyfb.h 2005-07-11 10:07:21.000000000 -0700
+++ fbdev-2.6/drivers/video/aty/atyfb.h 2005-08-12 10:34:13.000000000 -0700
@@ -187,6 +187,13 @@
#endif
};
+#ifdef CONFIG_ATARI
+struct mach64_device {
+ struct list_head node;
+ struct platform_device *dev;
+};
+#endif
+
/*
* ATI Mach64 features
*/
-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
^ permalink raw reply [flat|nested] 21+ messages in thread
end of thread, other threads:[~2005-08-12 17:47 UTC | newest]
Thread overview: 21+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2005-08-07 2:27 [PATCH] mach64 atari patch James Simmons
2005-08-07 11:39 ` Geert Uytterhoeven
2005-08-07 16:46 ` Andrew Morton
2005-08-07 23:09 ` James Simmons
2005-08-07 23:31 ` Antonino A. Daplas
2005-08-07 23:48 ` Jon Smirl
2005-08-08 17:30 ` James Simmons
2005-08-08 17:56 ` Jon Smirl
2005-08-08 18:15 ` James Simmons
2005-08-08 18:34 ` Jon Smirl
2005-08-08 18:44 ` James Simmons
2005-08-08 19:01 ` Jon Smirl
2005-08-08 19:07 ` Jon Smirl
2005-08-08 23:55 ` Antonino A. Daplas
2005-08-09 0:04 ` James Simmons
2005-08-09 0:59 ` Antonino A. Daplas
2005-08-09 1:08 ` Antonino A. Daplas
2005-08-09 8:05 ` Geert Uytterhoeven
2005-08-09 1:04 ` Jon Smirl
2005-08-12 17:47 ` James Simmons
2005-08-08 19:49 ` Alexander Kern
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).