Up until now, the pata_buddha driver would only check for cards on initcall time. Now, the kernel will call its probe function as soon as a compatible card is detected. v3: Clean up devm_*, implement device removal. v2: Rename 'zdev' to 'z' to make the patch easy to analyse with git diff --ignore-space-change Tested-by: Max Staudt <max@enpas.org> Signed-off-by: Max Staudt <max@enpas.org> --- drivers/ata/pata_buddha.c | 215 ++++++++++++++++++++++++++-------------------- 1 file changed, 121 insertions(+), 94 deletions(-) diff --git a/drivers/ata/pata_buddha.c b/drivers/ata/pata_buddha.c index 11a8044ff..b68392935 100644 --- a/drivers/ata/pata_buddha.c +++ b/drivers/ata/pata_buddha.c @@ -19,6 +19,7 @@ #include <linux/libata.h> #include <linux/mm.h> #include <linux/module.h> +#include <linux/types.h> #include <linux/zorro.h> #include <scsi/scsi_cmnd.h> #include <scsi/scsi_host.h> @@ -29,7 +30,7 @@ #include <asm/setup.h> #define DRV_NAME "pata_buddha" -#define DRV_VERSION "0.1.0" +#define DRV_VERSION "0.1.1" #define BUDDHA_BASE1 0x800 #define BUDDHA_BASE2 0xa00 @@ -47,11 +48,11 @@ enum { BOARD_XSURF }; -static unsigned int buddha_bases[3] __initdata = { +static unsigned int buddha_bases[3] = { BUDDHA_BASE1, BUDDHA_BASE2, BUDDHA_BASE3 }; -static unsigned int xsurf_bases[2] __initdata = { +static unsigned int xsurf_bases[2] = { XSURF_BASE1, XSURF_BASE2 }; @@ -145,111 +146,137 @@ static struct ata_port_operations pata_xsurf_ops = { .set_mode = pata_buddha_set_mode, }; -static int __init pata_buddha_init_one(void) +static int pata_buddha_probe(struct zorro_dev *z, + const struct zorro_device_id *ent) { - struct zorro_dev *z = NULL; - - while ((z = zorro_find_device(ZORRO_WILDCARD, z))) { - static const char *board_name[] - = { "Buddha", "Catweasel", "X-Surf" }; - struct ata_host *host; - void __iomem *buddha_board; - unsigned long board; - unsigned int type, nr_ports = 2; - int i; - - if (z->id == ZORRO_PROD_INDIVIDUAL_COMPUTERS_BUDDHA) { - type = BOARD_BUDDHA; - } else if (z->id == ZORRO_PROD_INDIVIDUAL_COMPUTERS_CATWEASEL) { - type = BOARD_CATWEASEL; - nr_ports++; - } else if (z->id == ZORRO_PROD_INDIVIDUAL_COMPUTERS_X_SURF) { - type = BOARD_XSURF; - } else - continue; - - dev_info(&z->dev, "%s IDE controller\n", board_name[type]); - - board = z->resource.start; + static const char * const board_name[] + = { "Buddha", "Catweasel", "X-Surf" }; + struct ata_host *host; + void __iomem *buddha_board; + unsigned long board; + unsigned int type, nr_ports = 2; + int i; + + switch (z->id) { + case ZORRO_PROD_INDIVIDUAL_COMPUTERS_BUDDHA: + default: + type = BOARD_BUDDHA; + break; + case ZORRO_PROD_INDIVIDUAL_COMPUTERS_CATWEASEL: + type = BOARD_CATWEASEL; + nr_ports++; + break; + case ZORRO_PROD_INDIVIDUAL_COMPUTERS_X_SURF: + type = BOARD_XSURF; + break; + } + + dev_info(&z->dev, "%s IDE controller\n", board_name[type]); + + board = z->resource.start; + + if (type != BOARD_XSURF) { + if (!devm_request_mem_region(&z->dev, + board + BUDDHA_BASE1, + 0x800, DRV_NAME)) + return -ENXIO; + } else { + if (!devm_request_mem_region(&z->dev, + board + XSURF_BASE1, + 0x1000, DRV_NAME)) + return -ENXIO; + if (!devm_request_mem_region(&z->dev, + board + XSURF_BASE2, + 0x1000, DRV_NAME)) { + } + } + + /* allocate host */ + host = ata_host_alloc(&z->dev, nr_ports); + if (!host) + return -ENXIO; + + buddha_board = ZTWO_VADDR(board); + + /* enable the board IRQ on Buddha/Catweasel */ + if (type != BOARD_XSURF) + z_writeb(0, buddha_board + BUDDHA_IRQ_MR); + + for (i = 0; i < nr_ports; i++) { + struct ata_port *ap = host->ports[i]; + void __iomem *base, *irqport; + unsigned long ctl = 0; if (type != BOARD_XSURF) { - if (!devm_request_mem_region(&z->dev, - board + BUDDHA_BASE1, - 0x800, DRV_NAME)) - continue; + ap->ops = &pata_buddha_ops; + base = buddha_board + buddha_bases[i]; + ctl = BUDDHA_CONTROL; + irqport = buddha_board + BUDDHA_IRQ + i * 0x40; } else { - if (!devm_request_mem_region(&z->dev, - board + XSURF_BASE1, - 0x1000, DRV_NAME)) - continue; - if (!devm_request_mem_region(&z->dev, - board + XSURF_BASE2, - 0x1000, DRV_NAME)) - continue; + ap->ops = &pata_xsurf_ops; + base = buddha_board + xsurf_bases[i]; + /* X-Surf has no CS1* (Control/AltStat) */ + irqport = buddha_board + XSURF_IRQ; } - /* allocate host */ - host = ata_host_alloc(&z->dev, nr_ports); - if (!host) - continue; - - buddha_board = ZTWO_VADDR(board); - - /* enable the board IRQ on Buddha/Catweasel */ - if (type != BOARD_XSURF) - z_writeb(0, buddha_board + BUDDHA_IRQ_MR); - - for (i = 0; i < nr_ports; i++) { - struct ata_port *ap = host->ports[i]; - void __iomem *base, *irqport; - unsigned long ctl = 0; - - if (type != BOARD_XSURF) { - ap->ops = &pata_buddha_ops; - base = buddha_board + buddha_bases[i]; - ctl = BUDDHA_CONTROL; - irqport = buddha_board + BUDDHA_IRQ + i * 0x40; - } else { - ap->ops = &pata_xsurf_ops; - base = buddha_board + xsurf_bases[i]; - /* X-Surf has no CS1* (Control/AltStat) */ - irqport = buddha_board + XSURF_IRQ; - } - - ap->pio_mask = ATA_PIO4; - ap->flags |= ATA_FLAG_SLAVE_POSS | ATA_FLAG_NO_IORDY; - - ap->ioaddr.data_addr = base; - ap->ioaddr.error_addr = base + 2 + 1 * 4; - ap->ioaddr.feature_addr = base + 2 + 1 * 4; - ap->ioaddr.nsect_addr = base + 2 + 2 * 4; - ap->ioaddr.lbal_addr = base + 2 + 3 * 4; - ap->ioaddr.lbam_addr = base + 2 + 4 * 4; - ap->ioaddr.lbah_addr = base + 2 + 5 * 4; - ap->ioaddr.device_addr = base + 2 + 6 * 4; - ap->ioaddr.status_addr = base + 2 + 7 * 4; - ap->ioaddr.command_addr = base + 2 + 7 * 4; - - if (ctl) { - ap->ioaddr.altstatus_addr = base + ctl; - ap->ioaddr.ctl_addr = base + ctl; - } - - ap->private_data = (void *)irqport; - - ata_port_desc(ap, "cmd 0x%lx ctl 0x%lx", board, - ctl ? board + buddha_bases[i] + ctl : 0); + ap->pio_mask = ATA_PIO4; + ap->flags |= ATA_FLAG_SLAVE_POSS | ATA_FLAG_NO_IORDY; + + ap->ioaddr.data_addr = base; + ap->ioaddr.error_addr = base + 2 + 1 * 4; + ap->ioaddr.feature_addr = base + 2 + 1 * 4; + ap->ioaddr.nsect_addr = base + 2 + 2 * 4; + ap->ioaddr.lbal_addr = base + 2 + 3 * 4; + ap->ioaddr.lbam_addr = base + 2 + 4 * 4; + ap->ioaddr.lbah_addr = base + 2 + 5 * 4; + ap->ioaddr.device_addr = base + 2 + 6 * 4; + ap->ioaddr.status_addr = base + 2 + 7 * 4; + ap->ioaddr.command_addr = base + 2 + 7 * 4; + + if (ctl) { + ap->ioaddr.altstatus_addr = base + ctl; + ap->ioaddr.ctl_addr = base + ctl; } - ata_host_activate(host, IRQ_AMIGA_PORTS, ata_sff_interrupt, - IRQF_SHARED, &pata_buddha_sht); + ap->private_data = (void *)irqport; + ata_port_desc(ap, "cmd 0x%lx ctl 0x%lx", board, + ctl ? board + buddha_bases[i] + ctl : 0); } + ata_host_activate(host, IRQ_AMIGA_PORTS, ata_sff_interrupt, + IRQF_SHARED, &pata_buddha_sht); + + return 0; } -module_init(pata_buddha_init_one); +static void pata_buddha_remove(struct zorro_dev *zdev) +{ + struct ata_host *host = dev_get_drvdata(&zdev->dev); + + ata_host_detach(host); +} + +static const struct zorro_device_id pata_buddha_zorro_tbl[] = { + { ZORRO_PROD_INDIVIDUAL_COMPUTERS_BUDDHA, }, + { ZORRO_PROD_INDIVIDUAL_COMPUTERS_CATWEASEL, }, + { ZORRO_PROD_INDIVIDUAL_COMPUTERS_X_SURF, }, + { 0 } +}; + +MODULE_DEVICE_TABLE(zorro, pata_buddha_zorro_tbl); + +static struct zorro_driver pata_buddha_driver = { + .name = "pata_buddha", + .id_table = pata_buddha_zorro_tbl, + .probe = pata_buddha_probe, + .remove = pata_buddha_remove, +}; + +module_driver(pata_buddha_driver, + zorro_register_driver, + zorro_unregister_driver); MODULE_AUTHOR("Bartlomiej Zolnierkiewicz"); MODULE_DESCRIPTION("low-level driver for Buddha/Catweasel/X-Surf PATA"); -- 2.11.0
Hi Max, On Thu, Jul 25, 2019 at 8:08 PM Max Staudt <max@enpas.org> wrote: > Up until now, the pata_buddha driver would only check for cards on > initcall time. Now, the kernel will call its probe function as soon > as a compatible card is detected. > > v3: Clean up devm_*, implement device removal. > > v2: Rename 'zdev' to 'z' to make the patch easy to analyse with > git diff --ignore-space-change > > Tested-by: Max Staudt <max@enpas.org> > Signed-off-by: Max Staudt <max@enpas.org> Sorry, I only noticed v3 after I replied to v2. My comments are still valid, though. > --- a/drivers/ata/pata_buddha.c > +++ b/drivers/ata/pata_buddha.c > +static const struct zorro_device_id pata_buddha_zorro_tbl[] = { > + { ZORRO_PROD_INDIVIDUAL_COMPUTERS_BUDDHA, }, > + { ZORRO_PROD_INDIVIDUAL_COMPUTERS_CATWEASEL, }, > + { ZORRO_PROD_INDIVIDUAL_COMPUTERS_X_SURF, }, drivers/net/ethernet/8390/zorro8390.c also matches against ZORRO_PROD_INDIVIDUAL_COMPUTERS_X_SURF, while only a single zorro_driver can bind to it. Hence you can no longer use both IDE and Ethernet on X-Surf :-( Before, this worked, as the IDE driver just walked the list of devices. I think the proper solution is to create MFD devices for Zorro boards with multiple functions, and bind against the individual MFD cells. That would also get rid of the nr_ports loop in the IDE driver, as each instance would have its own cell. I played with this a long time ago, but never finished it. It worked fine for my Ariadne Ethernet card. Last state at https://git.kernel.org/pub/scm/linux/kernel/git/geert/linux-m68k.git/log/?h=zorro-mfd Oh, seems I wrote up most of this before in https://lore.kernel.org/lkml/CAMuHMdVe1KgQWYZ_BfBkSo3zr0c+TenLMEw3T=BLEQNoZ6ex7A@mail.gmail.com/ > + { 0 } > +}; 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
Hi Geert, On 07/29/2019 11:05 AM, Geert Uytterhoeven wrote: >> --- a/drivers/ata/pata_buddha.c >> +++ b/drivers/ata/pata_buddha.c > >> +static const struct zorro_device_id pata_buddha_zorro_tbl[] = { >> + { ZORRO_PROD_INDIVIDUAL_COMPUTERS_BUDDHA, }, >> + { ZORRO_PROD_INDIVIDUAL_COMPUTERS_CATWEASEL, }, >> + { ZORRO_PROD_INDIVIDUAL_COMPUTERS_X_SURF, }, > > drivers/net/ethernet/8390/zorro8390.c also matches against > ZORRO_PROD_INDIVIDUAL_COMPUTERS_X_SURF, while only > a single zorro_driver can bind to it. Hence you can no longer use both > IDE and Ethernet on X-Surf :-( > Before, this worked, as the IDE driver just walked the list of devices. Okay, now this gets dirty. The reason why I've submitted this patch is to allow pata_buddha to be built into the kernel at all. Without this patch, its initcall would be called before the Zorro structures are initialised, hence not finding any boards. That means that not only would the previous driver only make sense as a module that is manually ensured to be loaded after Zorro has started, but the X-Surf IDE support was a really ugly hack to begin with. > I think the proper solution is to create MFD devices for Zorro boards > with multiple functions, and bind against the individual MFD cells. > That would also get rid of the nr_ports loop in the IDE driver, as each > instance would have its own cell. > > I played with this a long time ago, but never finished it. > It worked fine for my Ariadne Ethernet card. > Last state at > https://git.kernel.org/pub/scm/linux/kernel/git/geert/linux-m68k.git/log/?h=zorro-mfd > > Oh, seems I wrote up most of this before in > https://lore.kernel.org/lkml/CAMuHMdVe1KgQWYZ_BfBkSo3zr0c+TenLMEw3T=BLEQNoZ6ex7A@mail.gmail.com/ This looks great! Unfortunately, I don't have any MFD hardware other than a single Buddha to test this with. I especially don't have an X-Surf, hence no good way of testing this other than the two IDE channels on my Buddha. WinUAE doesn't seem to emulate the IDE controller either. What shall I do? Maybe as a stop-gap measure, we could hard-code a module_init() again, just for X-Surf? It's been good enough until a few weeks ago, so what could go wrong ;) On another note: Maybe your MFD idea could be used to expose the clockports on the Buddhas as well? That wouldn't solve the issue of clockport *expansions* being fundamentally non-enumerable, but maybe you can think of a reasonable way to attach a driver? Thanks for your feedback, Max
Hi Max, On Mon, Jul 29, 2019 at 1:10 PM Max Staudt <max@enpas.org> wrote: > On 07/29/2019 11:05 AM, Geert Uytterhoeven wrote: > >> --- a/drivers/ata/pata_buddha.c > >> +++ b/drivers/ata/pata_buddha.c > > > >> +static const struct zorro_device_id pata_buddha_zorro_tbl[] = { > >> + { ZORRO_PROD_INDIVIDUAL_COMPUTERS_BUDDHA, }, > >> + { ZORRO_PROD_INDIVIDUAL_COMPUTERS_CATWEASEL, }, > >> + { ZORRO_PROD_INDIVIDUAL_COMPUTERS_X_SURF, }, > > > > drivers/net/ethernet/8390/zorro8390.c also matches against > > ZORRO_PROD_INDIVIDUAL_COMPUTERS_X_SURF, while only > > a single zorro_driver can bind to it. Hence you can no longer use both > > IDE and Ethernet on X-Surf :-( > > Before, this worked, as the IDE driver just walked the list of devices. > > Okay, now this gets dirty. > > The reason why I've submitted this patch is to allow pata_buddha to be built into the kernel at all. Without this patch, its initcall would be called before the Zorro structures are initialised, hence not finding any boards. IC. I wasn't aware of the new pata_buddha.c driver not working at all when builtin. > That means that not only would the previous driver only make sense as a module that is manually ensured to be loaded after Zorro has started, but the X-Surf IDE support was a really ugly hack to begin with. Right. Please note that most drivers for Zorro boards predate the device driver framework, and thus all started life using zorro_find_device(). But this did have the advantage of supporting multi-function cards out-of-the-box. Later, several drivers were converted to the new driver framework. but not all of them, due to multi-function cards. > > I think the proper solution is to create MFD devices for Zorro boards > > with multiple functions, and bind against the individual MFD cells. > > That would also get rid of the nr_ports loop in the IDE driver, as each > > instance would have its own cell. > > > > I played with this a long time ago, but never finished it. > > It worked fine for my Ariadne Ethernet card. > > Last state at > > https://git.kernel.org/pub/scm/linux/kernel/git/geert/linux-m68k.git/log/?h=zorro-mfd > > > > Oh, seems I wrote up most of this before in > > https://lore.kernel.org/lkml/CAMuHMdVe1KgQWYZ_BfBkSo3zr0c+TenLMEw3T=BLEQNoZ6ex7A@mail.gmail.com/ > > This looks great! > > Unfortunately, I don't have any MFD hardware other than a single > Buddha to test this with. I especially don't have an X-Surf, hence no > good way of testing this other than the two IDE channels on my Buddha. > WinUAE doesn't seem to emulate the IDE controller either. > > What shall I do? Maybe as a stop-gap measure, we could hard-code a > module_init() again, just for X-Surf? It's been good enough until a > few weeks ago, so what could go wrong ;) In the short run: keep on using drivers/ide/buddha.c? Your single Buddha should be sufficient to convert pata_buddha.c from a plain Zorro driver to an MFD cell driver, and test it. I expect the buddha-mfd.c MFD driver from my zorro-mfd branch to work as-is, or with very minor changes. However, to keep X-Surf working, this needs to be synchronized with a Zorro MFD conversion of the zorro8390 driver, too. > On another note: Maybe your MFD idea could be used to expose the > clockports on the Buddhas as well? That wouldn't solve the issue of > clockport *expansions* being fundamentally non-enumerable, but maybe > you can think of a reasonable way to attach a driver? Yes, the clockport could be added as an extra MFD cell. Later, drivers can be written to bind against the clockport cell. Thanks! 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
Hi, On 7/29/19 1:30 PM, Geert Uytterhoeven wrote: > Hi Max, > > On Mon, Jul 29, 2019 at 1:10 PM Max Staudt <max@enpas.org> wrote: >> On 07/29/2019 11:05 AM, Geert Uytterhoeven wrote: >>>> --- a/drivers/ata/pata_buddha.c >>>> +++ b/drivers/ata/pata_buddha.c >>> >>>> +static const struct zorro_device_id pata_buddha_zorro_tbl[] = { >>>> + { ZORRO_PROD_INDIVIDUAL_COMPUTERS_BUDDHA, }, >>>> + { ZORRO_PROD_INDIVIDUAL_COMPUTERS_CATWEASEL, }, >>>> + { ZORRO_PROD_INDIVIDUAL_COMPUTERS_X_SURF, }, >>> >>> drivers/net/ethernet/8390/zorro8390.c also matches against >>> ZORRO_PROD_INDIVIDUAL_COMPUTERS_X_SURF, while only >>> a single zorro_driver can bind to it. Hence you can no longer use both >>> IDE and Ethernet on X-Surf :-( >>> Before, this worked, as the IDE driver just walked the list of devices. >> >> Okay, now this gets dirty. >> >> The reason why I've submitted this patch is to allow pata_buddha to be built into the kernel at all. Without this patch, its initcall would be called before the Zorro structures are initialised, hence not finding any boards. > > IC. I wasn't aware of the new pata_buddha.c driver not working at all > when builtin. Isn't the same true also for old buddha.c driver? (please see below) >> That means that not only would the previous driver only make sense as a module that is manually ensured to be loaded after Zorro has started, but the X-Surf IDE support was a really ugly hack to begin with. > > Right. Please note that most drivers for Zorro boards predate the device > driver framework, and thus all started life using zorro_find_device(). > But this did have the advantage of supporting multi-function cards > out-of-the-box. > Later, several drivers were converted to the new driver framework. > but not all of them, due to multi-function cards. > >>> I think the proper solution is to create MFD devices for Zorro boards >>> with multiple functions, and bind against the individual MFD cells. >>> That would also get rid of the nr_ports loop in the IDE driver, as each >>> instance would have its own cell. >>> >>> I played with this a long time ago, but never finished it. >>> It worked fine for my Ariadne Ethernet card. >>> Last state at >>> https://git.kernel.org/pub/scm/linux/kernel/git/geert/linux-m68k.git/log/?h=zorro-mfd >>> >>> Oh, seems I wrote up most of this before in >>> https://lore.kernel.org/lkml/CAMuHMdVe1KgQWYZ_BfBkSo3zr0c+TenLMEw3T=BLEQNoZ6ex7A@mail.gmail.com/ >> >> This looks great! >> >> Unfortunately, I don't have any MFD hardware other than a single >> Buddha to test this with. I especially don't have an X-Surf, hence no >> good way of testing this other than the two IDE channels on my Buddha. >> WinUAE doesn't seem to emulate the IDE controller either. >> >> What shall I do? Maybe as a stop-gap measure, we could hard-code a >> module_init() again, just for X-Surf? It's been good enough until a >> few weeks ago, so what could go wrong ;) > > In the short run: keep on using drivers/ide/buddha.c? IDE subsystem is initialized even before libata so I cannot see how this would help? drivers/Makefile: ... obj-$(CONFIG_IDE) += ide/ obj-y += scsi/ obj-y += nvme/ obj-$(CONFIG_ATA) += ata/ ... obj-$(CONFIG_ZORRO) += zorro/ ... What am I missing? > Your single Buddha should be sufficient to convert pata_buddha.c from > a plain Zorro driver to an MFD cell driver, and test it. > I expect the buddha-mfd.c MFD driver from my zorro-mfd branch to > work as-is, or with very minor changes. > > However, to keep X-Surf working, this needs to be synchronized with > a Zorro MFD conversion of the zorro8390 driver, too. > >> On another note: Maybe your MFD idea could be used to expose the >> clockports on the Buddhas as well? That wouldn't solve the issue of >> clockport *expansions* being fundamentally non-enumerable, but maybe >> you can think of a reasonable way to attach a driver? > > Yes, the clockport could be added as an extra MFD cell. Later, drivers can > be written to bind against the clockport cell. > > Thanks! > > Gr{oetje,eeting}s, > > Geert Best regards, -- Bartlomiej Zolnierkiewicz Samsung R&D Institute Poland Samsung Electronics
Hi Bartlomiej, On Mon, Jul 29, 2019 at 1:52 PM Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com> wrote: > On 7/29/19 1:30 PM, Geert Uytterhoeven wrote: > > On Mon, Jul 29, 2019 at 1:10 PM Max Staudt <max@enpas.org> wrote: > >> On 07/29/2019 11:05 AM, Geert Uytterhoeven wrote: > >>>> --- a/drivers/ata/pata_buddha.c > >>>> +++ b/drivers/ata/pata_buddha.c > >>> > >>>> +static const struct zorro_device_id pata_buddha_zorro_tbl[] = { > >>>> + { ZORRO_PROD_INDIVIDUAL_COMPUTERS_BUDDHA, }, > >>>> + { ZORRO_PROD_INDIVIDUAL_COMPUTERS_CATWEASEL, }, > >>>> + { ZORRO_PROD_INDIVIDUAL_COMPUTERS_X_SURF, }, > >>> > >>> drivers/net/ethernet/8390/zorro8390.c also matches against > >>> ZORRO_PROD_INDIVIDUAL_COMPUTERS_X_SURF, while only > >>> a single zorro_driver can bind to it. Hence you can no longer use both > >>> IDE and Ethernet on X-Surf :-( > >>> Before, this worked, as the IDE driver just walked the list of devices. > >> > >> Okay, now this gets dirty. > >> > >> The reason why I've submitted this patch is to allow pata_buddha to be built into the kernel at all. Without this patch, its initcall would be called before the Zorro structures are initialised, hence not finding any boards. > > > > IC. I wasn't aware of the new pata_buddha.c driver not working at all > > when builtin. > > Isn't the same true also for old buddha.c driver? > (please see below) > >> What shall I do? Maybe as a stop-gap measure, we could hard-code a > >> module_init() again, just for X-Surf? It's been good enough until a > >> few weeks ago, so what could go wrong ;) > > > > In the short run: keep on using drivers/ide/buddha.c? > > IDE subsystem is initialized even before libata so I cannot see how > this would help? > > drivers/Makefile: > ... > obj-$(CONFIG_IDE) += ide/ > obj-y += scsi/ > obj-y += nvme/ > obj-$(CONFIG_ATA) += ata/ > ... > obj-$(CONFIG_ZORRO) += zorro/ > ... > > What am I missing? Oops, that might be an incorrect assumption on my side... (note to myself: never assume existing code is actually working as expected ;-) 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
Hi Max!
On 7/29/19 1:09 PM, Max Staudt wrote:
> Unfortunately, I don't have any MFD hardware other than a single Buddha to test this with. I especially don't have an X-Surf, hence no good way of testing this other than the two IDE channels on my Buddha. WinUAE doesn't seem to emulate the IDE controller either.
I have both an X-Surf100 and a Buddha and would be happy to provide an
account on the Amiga with that hardware for you. You can run any
tests you like and install any kernel you want.
If you need an older X-Surf version, you could always ask the guys on
the a1k.org forum. They are usually very kind to loan hardware for these
purposes.
Adrian
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer - glaubitz@debian.org
`. `' Freie Universitaet Berlin - glaubitz@physik.fu-berlin.de
`- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
On 07/29/2019 01:30 PM, Geert Uytterhoeven wrote: >> What shall I do? Maybe as a stop-gap measure, we could hard-code a >> module_init() again, just for X-Surf? It's been good enough until a >> few weeks ago, so what could go wrong ;) > > In the short run: keep on using drivers/ide/buddha.c? See Bartlomiej's reply to your email: It suffers from the same problem. Building it in will result in the Buddha not being recognised, as the IDE driver scans for it before Zorro si initialised. @Bartlomiej: You're not missing anything, the problem has gone unnoticed for ages ;) However, using ide/buddha would work exactly as it has before: When loaded as a module after Zorro has been initialised, it works just fine. We *could* also temporarily split off a pata_buddha_xsurf driver: pata_buddha would be auto-probed by the new framework, and pata_buddha_xsurf would do the old module_init() dance. That is, until the MFD conversion happens. > Your single Buddha should be sufficient to convert pata_buddha.c from > a plain Zorro driver to an MFD cell driver, and test it. > I expect the buddha-mfd.c MFD driver from my zorro-mfd branch to > work as-is, or with very minor changes. > > However, to keep X-Surf working, this needs to be synchronized with > a Zorro MFD conversion of the zorro8390 driver, too. Yeah, this second part is where I get caught up. I'd really like to test this with a real X-Surf, or have someone test it, before sending it upstream. > Yes, the clockport could be added as an extra MFD cell. Later, drivers can > be written to bind against the clockport cell. Yes, but how can we assign specific drivers to specific clockports? As they are non-enumerable (are they?), we can't auto-probe them. Max
On 07/29/2019 02:20 PM, John Paul Adrian Glaubitz wrote: > I have both an X-Surf100 and a Buddha and would be happy to provide an > account on the Amiga with that hardware for you. You can run any > tests you like and install any kernel you want. > > If you need an older X-Surf version, you could always ask the guys on > the a1k.org forum. They are usually very kind to loan hardware for these > purposes. Thanks for the generous offer! Unfortunately, we are really talking about the original (non-100) X-Surf here, as only that one has the stripped down Buddha style IDE ports: http://wiki.icomp.de/wiki/X-Surf Max
On 7/29/19 4:34 PM, Max wrote:
> On 07/29/2019 02:20 PM, John Paul Adrian Glaubitz wrote:
>> I have both an X-Surf100 and a Buddha and would be happy to provide an
>> account on the Amiga with that hardware for you. You can run any
>> tests you like and install any kernel you want.
>>
>> If you need an older X-Surf version, you could always ask the guys on
>> the a1k.org forum. They are usually very kind to loan hardware for these
>> purposes.
>
>
> Thanks for the generous offer!
>
> Unfortunately, we are really talking about the original (non-100) X-Surf here, as only that one has the stripped down Buddha style IDE ports:
>
> http://wiki.icomp.de/wiki/X-Surf
That's why I suggested asking the a1k.org for the older version in case
the X-Surf100 doesn't help. I'm pretty sure someone there has one.
Adrian
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer - glaubitz@debian.org
`. `' Freie Universitaet Berlin - glaubitz@physik.fu-berlin.de
`- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Hi Max, On Mon, Jul 29, 2019 at 4:31 PM Max Staudt <max@enpas.org> wrote: > On 07/29/2019 01:30 PM, Geert Uytterhoeven wrote: > >> What shall I do? Maybe as a stop-gap measure, we could hard-code a > >> module_init() again, just for X-Surf? It's been good enough until a > >> few weeks ago, so what could go wrong ;) > > > > In the short run: keep on using drivers/ide/buddha.c? > > See Bartlomiej's reply to your email: It suffers from the same problem. Building it in will result in the Buddha not being recognised, as the IDE driver scans for it before Zorro si initialised. Thanks for the confirmation. > @Bartlomiej: You're not missing anything, the problem has gone unnoticed for ages ;) > However, using ide/buddha would work exactly as it has before: When loaded as a module after Zorro has been initialised, it works just fine. > > We *could* also temporarily split off a pata_buddha_xsurf driver: pata_buddha would be auto-probed by the new framework, and pata_buddha_xsurf would do the old module_init() dance. > That is, until the MFD conversion happens. Or add temporarily a late_initcall() to find all X-Surf boards using zorro_find_device(), create fake zorro_device_id entries, and pass both to pata_buddha_probe()? A big ugly, but that should work. > > Your single Buddha should be sufficient to convert pata_buddha.c from > > a plain Zorro driver to an MFD cell driver, and test it. > > I expect the buddha-mfd.c MFD driver from my zorro-mfd branch to > > work as-is, or with very minor changes. > > > > However, to keep X-Surf working, this needs to be synchronized with > > a Zorro MFD conversion of the zorro8390 driver, too. > > Yeah, this second part is where I get caught up. I'd really like to test this with a real X-Surf, or have someone test it, before sending it upstream. Of course it should be tested ;-) Converting zorro8390.c from a zorro driver to an MFD cell driver should not require that many changes, most bugs should be caught by code review. I already have a skeleton 8390-cell.c driver in my zorro-mfd branch. > > Yes, the clockport could be added as an extra MFD cell. Later, drivers can > > be written to bind against the clockport cell. > > Yes, but how can we assign specific drivers to specific clockports? As they are non-enumerable (are they?), we can't auto-probe them. That's something the user has to configure. The Buddha MFD driver registers an "a1200-clockport" cell, which is really a separate platform device. The user writes the name of the actual driver to use to the device's driver_override file in sysfs, after which the driver is bound automatically. See Documentation/ABI/testing/sysfs-bus-platform, The alternative would be to have multiple drivers matching against "a1200-clockport", and the user modprobe'ing the correct one to use. But that won't work with http://wiki.icomp.de/wiki/A500/A1000_clockport and plugging in two different clock port boards. 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
On 07/29/2019 05:26 PM, Geert Uytterhoeven wrote: >> We *could* also temporarily split off a pata_buddha_xsurf driver: pata_buddha would be auto-probed by the new framework, and pata_buddha_xsurf would do the old module_init() dance. >> That is, until the MFD conversion happens. > > Or add temporarily a late_initcall() to find all X-Surf boards using > zorro_find_device(), create fake zorro_device_id entries, and pass both > to pata_buddha_probe()? A big ugly, but that should work. Sounds good, and it replaces modile_init() at the same time. I'll implement this. >>> Your single Buddha should be sufficient to convert pata_buddha.c from >>> a plain Zorro driver to an MFD cell driver, and test it. >>> I expect the buddha-mfd.c MFD driver from my zorro-mfd branch to >>> work as-is, or with very minor changes. >>> >>> However, to keep X-Surf working, this needs to be synchronized with >>> a Zorro MFD conversion of the zorro8390 driver, too. >> >> Yeah, this second part is where I get caught up. I'd really like to test this with a real X-Surf, or have someone test it, before sending it upstream. > > Of course it should be tested ;-) > Converting zorro8390.c from a zorro driver to an MFD cell driver should > not require that many changes, most bugs should be caught by code review. > I already have a skeleton 8390-cell.c driver in my zorro-mfd branch. Honestly, at this point I'd rather do the hack above and keep the MFD stuff for later. Let's take it step by step. I'd prefer not to touch 8390 for now, unless I can get my hands on an X-Surf. I'd like to help with the MFD stuff as a way to enable the clockport and my SilverSurfer on it, but for the moment I'd rather move that further down the road. >>> Yes, the clockport could be added as an extra MFD cell. Later, drivers can >>> be written to bind against the clockport cell. >> >> Yes, but how can we assign specific drivers to specific clockports? As they are non-enumerable (are they?), we can't auto-probe them. > > That's something the user has to configure. > The Buddha MFD driver registers an "a1200-clockport" cell, which is > really a separate platform device. > The user writes the name of the actual driver to use to the device's > driver_override file in sysfs, after which the driver is bound > automatically. See Documentation/ABI/testing/sysfs-bus-platform, That sounds just like what I was hoping for, thanks. > The alternative would be to have multiple drivers matching against > "a1200-clockport", and the user modprobe'ing the correct one to use. > But that won't work with http://wiki.icomp.de/wiki/A500/A1000_clockport > and plugging in two different clock port boards. Eeeek no, that way one can't have multiple clockports and different/no devices on some of them. I think the sysfs solution above is perfect, given the nature of the clockport. Thanks! Max
Hi Max, On Mon, Jul 29, 2019 at 5:38 PM Max <max@enpas.org> wrote: > On 07/29/2019 05:26 PM, Geert Uytterhoeven wrote: > >> We *could* also temporarily split off a pata_buddha_xsurf driver: pata_buddha would be auto-probed by the new framework, and pata_buddha_xsurf would do the old module_init() dance. > >> That is, until the MFD conversion happens. > > > > Or add temporarily a late_initcall() to find all X-Surf boards using > > zorro_find_device(), create fake zorro_device_id entries, and pass both > > to pata_buddha_probe()? A big ugly, but that should work. > > Sounds good, and it replaces modile_init() at the same time. I'll implement this. Thanks! > >>> Your single Buddha should be sufficient to convert pata_buddha.c from > >>> a plain Zorro driver to an MFD cell driver, and test it. > >>> I expect the buddha-mfd.c MFD driver from my zorro-mfd branch to > >>> work as-is, or with very minor changes. > >>> > >>> However, to keep X-Surf working, this needs to be synchronized with > >>> a Zorro MFD conversion of the zorro8390 driver, too. > >> > >> Yeah, this second part is where I get caught up. I'd really like to test this with a real X-Surf, or have someone test it, before sending it upstream. > > > > Of course it should be tested ;-) > > Converting zorro8390.c from a zorro driver to an MFD cell driver should > > not require that many changes, most bugs should be caught by code review. > > I already have a skeleton 8390-cell.c driver in my zorro-mfd branch. > > Honestly, at this point I'd rather do the hack above and keep the MFD stuff for later. Let's take it step by step. I'd prefer not to touch 8390 for now, unless I can get my hands on an X-Surf. I'd like to help with the MFD stuff as a way to enable the clockport and my SilverSurfer on it, but for the moment I'd rather move that further down the road. OK, fine for me, of course. > >>> Yes, the clockport could be added as an extra MFD cell. Later, drivers can > >>> be written to bind against the clockport cell. > >> > >> Yes, but how can we assign specific drivers to specific clockports? As they are non-enumerable (are they?), we can't auto-probe them. > > > > That's something the user has to configure. > > The Buddha MFD driver registers an "a1200-clockport" cell, which is > > really a separate platform device. > > The user writes the name of the actual driver to use to the device's > > driver_override file in sysfs, after which the driver is bound > > automatically. See Documentation/ABI/testing/sysfs-bus-platform, > > That sounds just like what I was hoping for, thanks. I'm happy you like it ;-) 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