From: shinkoi2005 <shi...@gm...> - 2007-09-01 11:41:19
|
Hi all. I have a problem about rts7751r2d. I think that rts7751r2d's cf_ide resister mapped area is Area5. And Area5's access size is 16bit width (see manual http://tree.celinuxforum.org/CelfPubWiki/RTS7751R2DHandlingManual?action=AttachFile&do=get&target=R2DHWmanual.pdf p.27). But libata-core.c uses ioread8()/iowrite8() that access size is 8bit width. So we need to change access size. ------ diff --git a/arch/sh/boards/renesas/rts7751r2d/setup.c b/arch/sh/boards/renesas/rts7751r2d/setup.c index e62107d..d9fbdc2 100644 --- a/arch/sh/boards/renesas/rts7751r2d/setup.c +++ b/arch/sh/boards/renesas/rts7751r2d/setup.c @@ -45,12 +45,12 @@ static void __init voyagergx_serial_init(void) static struct resource cf_ide_resources[] = { [0] = { .start = PA_AREA5_IO + 0x1000, - .end = PA_AREA5_IO + 0x1000 + 0x08 - 1, + .end = PA_AREA5_IO + 0x1000 + 0x10 - 0x2, .flags = IORESOURCE_MEM, }, [1] = { .start = PA_AREA5_IO + 0x80c, - .end = PA_AREA5_IO + 0x80c + 0x16 - 1, + .end = PA_AREA5_IO + 0x80c, .flags = IORESOURCE_MEM, }, [2] = { @@ -141,19 +141,12 @@ static struct platform_device *rts7751r2d_devices[] __initdata = { &uart_device, &sm501_device, #endif + &cf_ide_device, &heartbeat_device, }; static int __init rts7751r2d_devices_setup(void) { - int ret; - - if (ctrl_inw(PA_BVERREG) == 0x10) { /* R2D-PLUS */ - ret = platform_device_register(&cf_ide_device); - if (ret) - return ret; - } - return platform_add_devices(rts7751r2d_devices, ARRAY_SIZE(rts7751r2d_devices)); } @@ -182,6 +175,36 @@ static void __init rts7751r2d_setup(char **cmdline_p) voyagergx_serial_init(); } +static inline unsigned char is_ide_ioaddr(unsigned long addr) { + if ((cf_ide_resources[0].start <= addr && + addr <= cf_ide_resources[0].end) || + (cf_ide_resources[1].start <= addr && + addr <= cf_ide_resources[1].end)) { + return 1; + } + return 0; +} + +void rts7751r2d_writeb(u8 b, void __iomem *addr) +{ + unsigned long tmp = (unsigned long __force)addr; + + if (is_ide_ioaddr(tmp)) + ctrl_outw((u16)b, tmp); + else + ctrl_outb(b, tmp); +} + +u8 rts7751r2d_readb(void __iomem *addr) +{ + unsigned long tmp = (unsigned long __force)addr; + + if (is_ide_ioaddr(tmp)) + return 0xff & ctrl_inw(tmp); + else + return ctrl_inb(tmp); +} + /* * The Machine Vector */ @@ -191,6 +214,8 @@ static struct sh_machine_vector mv_rts7751r2d __initmv = { .mv_init_irq = init_rts7751r2d_IRQ, .mv_irq_demux = rts7751r2d_irq_demux, + .mv_writeb = rts7751r2d_writeb, + .mv_readb = rts7751r2d_readb, #if defined(CONFIG_MFD_SM501) && defined(CONFIG_USB_OHCI_HCD) .mv_consistent_alloc = voyagergx_consistent_alloc, |
From: Magnus D. <mag...@gm...> - 2007-09-06 02:56:24
|
Hi there, On 9/1/07, shinkoi2005 <shi...@gm...> wrote: > Hi all. > > I have a problem about rts7751r2d. First of all, which board version are you using? It looks like your patch is targeted for R2D-1. I think CF support is disabled for R2D-1 just because of the problem your patch is trying to solve. The code that your patch modifies is used by both R2D-PLUS and R2D-1. I suspect that your current patch breaks R2D-PLUS. Or at least degrades it to 8 bit read. If these board versions doesn't make any sense to you then please read the help text for the new R2D specific board code available in the git tree that now is targeted for 2.6.24: http://git.kernel.org/?p=linux/kernel/git/lethal/sh-2.6.git;a=summary A few random hints: Please wrap your changes with CONFIG_RTS7751R2D_1 and make sure that CONFIG_RTS7751R2D_PLUS still compiles. Also, please add a signed-off line and make sure your patch applies to the tree above, not 2.6.23-rc. But I think you are already working against the sh-2.6 tree, right? Besides that I'm not sure if your patch is 100% correct. I know Paul is busy this week but maybe he has some comments later on. Is the libata code working properly with 8 bit reads? Is this patch all it takes to get CF working on R2D-1? Thanks for your help. / magnus |
From: shinkoi2005 <shi...@gm...> - 2007-09-15 02:00:57
|
> First of all, which board version are you using? It looks like your > patch is targeted for R2D-1. I think CF support is disabled for R2D-1 > just because of the problem your patch is trying to solve. I think R2D-PLUS has the same problem. Please see R2D-PLUS datasheet P.16. <http://documentation.renesas.com/eng/products/tool/rej10j1470_r0p751rlc0011rl_g.pdf> > Is the libata code working properly with 8 bit reads? Is this patch > all it takes to get CF working on R2D-1? At least, cf_ide_resources[](register map) is also incorrect with R2D-PLUS. Please check follow kernel which support P2D-PLUS and AT/PC arch's ATA register map. <http://www.superh-linux.org/archive/bsp/sh7751r_r2d/linux-2.6.14.4-R2D+_20060906.tar.bz2> R2D* board's ide register map is compatible without register access size. Here is the same patch... I can boot R2D-1 from IDE's rootfs with this patch. Signed-off-by: Aoi Shinkai <shi...@gm...> --- a/arch/sh/boards/renesas/rts7751r2d/setup.c | 45 +++++++++++++++++++++++++++++++++++---------- 1 file changed, 35 insertions(+), 10 deletions(-) --- a/arch/sh/boards/renesas/rts7751r2d/setup.c +++ b/arch/sh/boards/renesas/rts7751r2d/setup.c @@ -45,12 +45,12 @@ static void __init voyagergx_serial_init(void) static struct resource cf_ide_resources[] = { [0] = { .start = PA_AREA5_IO + 0x1000, - .end = PA_AREA5_IO + 0x1000 + 0x08 - 1, + .end = PA_AREA5_IO + 0x1000 + 0x10 - 0x2, .flags = IORESOURCE_MEM, }, [1] = { .start = PA_AREA5_IO + 0x80c, - .end = PA_AREA5_IO + 0x80c + 0x16 - 1, + .end = PA_AREA5_IO + 0x80c, .flags = IORESOURCE_MEM, }, [2] = { @@ -141,19 +141,12 @@ static struct platform_device *rts7751r2d_devices[] __initdata = { &uart_device, &sm501_device, #endif + &cf_ide_device, &heartbeat_device, }; static int __init rts7751r2d_devices_setup(void) { - int ret; - - if (ctrl_inw(PA_BVERREG) == 0x10) { /* R2D-PLUS */ - ret = platform_device_register(&cf_ide_device); - if (ret) - return ret; - } - return platform_add_devices(rts7751r2d_devices, ARRAY_SIZE(rts7751r2d_devices)); } @@ -182,6 +175,36 @@ static void __init rts7751r2d_setup(char **cmdline_p) voyagergx_serial_init(); } +static inline unsigned char is_ide_ioaddr(unsigned long addr) { + if ((cf_ide_resources[0].start <= addr && + addr <= cf_ide_resources[0].end) || + (cf_ide_resources[1].start <= addr && + addr <= cf_ide_resources[1].end)) { + return 1; + } + return 0; +} + +void rts7751r2d_writeb(u8 b, void __iomem *addr) +{ + unsigned long tmp = (unsigned long __force)addr; + + if (is_ide_ioaddr(tmp)) + ctrl_outw((u16)b, tmp); + else + ctrl_outb(b, tmp); +} + +u8 rts7751r2d_readb(void __iomem *addr) +{ + unsigned long tmp = (unsigned long __force)addr; + + if (is_ide_ioaddr(tmp)) + return 0xff & ctrl_inw(tmp); + else + return ctrl_inb(tmp); +} + /* * The Machine Vector */ @@ -191,6 +214,8 @@ static struct sh_machine_vector mv_rts7751r2d __initmv = { .mv_init_irq = init_rts7751r2d_IRQ, .mv_irq_demux = rts7751r2d_irq_demux, + .mv_writeb = rts7751r2d_writeb, + .mv_readb = rts7751r2d_readb, #if defined(CONFIG_MFD_SM501) && defined(CONFIG_USB_OHCI_HCD) .mv_consistent_alloc = voyagergx_consistent_alloc, -- |
From: Paul M. <le...@li...> - 2007-09-21 06:07:52
|
On Sat, Sep 15, 2007 at 11:00:46AM +0900, shinkoi2005 wrote: > > Is the libata code working properly with 8 bit reads? Is this patch > > all it takes to get CF working on R2D-1? > > At least, cf_ide_resources[](register map) is also incorrect with R2D-PLUS. > Please check follow kernel which support P2D-PLUS and AT/PC arch's ATA register map. > <http://www.superh-linux.org/archive/bsp/sh7751r_r2d/linux-2.6.14.4-R2D+_20060906.tar.bz2> > R2D* board's ide register map is compatible without register access size. > > Here is the same patch... > I can boot R2D-1 from IDE's rootfs with this patch. > I suppose we can do this, I'll tidy up the patch a bit and apply it, thanks. It's probably worth doing the same thing for R7780RP, at least for the 2 or 3 people that have one of those antiquated things :-) |
From: shinkoi2005 <shi...@gm...> - 2007-11-12 15:15:37
|
> I'm glad that it works on your R2D-1. Both my R2D-1 boards do not have > working CF. Just to double-check - are using a R2D with one or two pci > slots? My R2D-1 has two pci slots. The picture is the following. <http://tree.celinuxforum.org/pubwiki/moin.cgi/RTS7751R2DHandlingManual> > Can you please post the BVERREG and VERREG register values from your > R2D-1? Then I'll post mine when I get back into the office. My R2D-1's VERREG and BVERREG is the folloing. R2D VERREG:0x0033, BVERREG:0x0011 diff a/arch/sh/boards/renesas/rts7751r2d/irq.c b/arch/sh/boards/renesas/rts7751r2d/irq.c --- a/arch/sh/boards/renesas/rts7751r2d/irq.c +++ b/arch/sh/boards/renesas/rts7751r2d/irq.c @@ -129,8 +129,12 @@ int rts7751r2d_irq_demux(int irq) void __init init_rts7751r2d_IRQ(void) { struct intc_desc *d; + unsigned short ver = ctrl_inw(PA_VERREG); /* FPGA Revision */ + unsigned short bver = ctrl_inw(PA_BVERREG); /* Board Revision */ - switch (ctrl_inw(PA_VERREG) & 0xf0) { + printk(KERN_INFO "R2D VERREG:0x%04x, BVERREG:0x%04x\n", ver, bver); + + switch (ver & 0xf0) { #ifdef CONFIG_RTS7751R2D_PLUS case 0x10: printk(KERN_INFO "Using R2D-PLUS interrupt controller.\n"); @@ -148,7 +152,7 @@ void __init init_rts7751r2d_IRQ(void) #endif default: printk(KERN_INFO "Unknown R2D interrupt controller 0x%04x\n", - ctrl_inw(PA_VERREG)); + ver); return; } |
From: Magnus D. <mag...@gm...> - 2007-11-06 11:43:22
|
On Sep 21, 2007 3:07 PM, Paul Mundt <le...@li...> wrote: > On Sat, Sep 15, 2007 at 11:00:46AM +0900, shinkoi2005 wrote: > > > Is the libata code working properly with 8 bit reads? Is this patch > > > all it takes to get CF working on R2D-1? > > > > At least, cf_ide_resources[](register map) is also incorrect with R2D-PLUS. > > Please check follow kernel which support P2D-PLUS and AT/PC arch's ATA register map. > > <http://www.superh-linux.org/archive/bsp/sh7751r_r2d/linux-2.6.14.4-R2D+_20060906.tar.bz2> > > R2D* board's ide register map is compatible without register access size. > > > > Here is the same patch... > > I can boot R2D-1 from IDE's rootfs with this patch. > > > I suppose we can do this, I'll tidy up the patch a bit and apply it, > thanks. It's probably worth doing the same thing for R7780RP, at least > for the 2 or 3 people that have one of those antiquated things :-) I happen to have two of these R2D-1 boards and I can't get CF working using the latest kernel (latest sh-2.6 git, post 2.6.24-rc1) : ... irq 107: nobody cared (try booting with the "irqpoll" option) [stack dump] [call trace] handlers: [<8c24f660>] (ata_interrupt+0x0/0x240) Disabling IRQ #107 ... I can get things working by hacking in code to enable polling in pata_platform.c though, so I assume that the IO-ports are ok. The CF seems just fine on my R2D-PLUS board. CF on R2D-1 is broken for me. / magnus |
From: Rafael I. Z. <riz...@ya...> - 2007-11-07 14:36:41
|
Hello, We have not fixed a problem with CF and libata on old sh3 hp machines (620lx and 660lx at least) which gives us a "qc timeout" on boot time. I know that the patch below fixes that one, but I don't know how we should solve that problem in the correct way. Any idea? Regards --- a/drivers/ata/libata-core.c 2007-11-07 11:07:18.000000000 -0300 +++ b/drivers/ata/libata-core.c 2007-11-07 11:11:23.000000000 -0300 @@ -327,7 +327,7 @@ int ata_build_rw_tf(struct ata_taskfile u64 block, u32 n_block, unsigned int tf_flags, unsigned int tag) { - tf->flags |= ATA_TFLAG_ISADDR | ATA_TFLAG_DEVICE; + tf->flags |= ATA_TFLAG_ISADDR | ATA_TFLAG_DEVICE | ATA_TFLAG_POLLING; tf->flags |= tf_flags; if (ata_ncq_enabled(dev) && likely(tag != ATA_TAG_INTERNAL)) { @@ -4502,7 +4502,7 @@ static unsigned int ata_dev_init_params( ata_tf_init(dev, &tf); tf.command = ATA_CMD_INIT_DEV_PARAMS; - tf.flags |= ATA_TFLAG_ISADDR | ATA_TFLAG_DEVICE; + tf.flags |= ATA_TFLAG_ISADDR | ATA_TFLAG_DEVICE | ATA_TFLAG_POLLING; tf.protocol = ATA_PROT_NODATA; tf.nsect = sectors; tf.device |= (heads - 1) & 0x0f; /* max head = num. of heads - 1 */ __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com |
From: Paul M. <le...@li...> - 2007-11-07 15:17:22
|
On Wed, Nov 07, 2007 at 06:36:32AM -0800, Rafael Ignacio Zurita wrote: > Hello, > We have not fixed a problem with CF and libata on > old sh3 hp machines (620lx and 660lx at least) which > gives us a "qc timeout" on boot time. > > I know that the patch below fixes that one, > but I don't know how we should solve that problem > in the correct way. > For starters, this is horribly line wrapped. Please fix your mailer. |
From: Magnus D. <mag...@gm...> - 2007-11-08 08:21:12
|
Hi there, On Nov 7, 2007 11:36 PM, Rafael Ignacio Zurita <riz...@ya...> wrote: > Hello, > We have not fixed a problem with CF and libata on > old sh3 hp machines (620lx and 660lx at least) which > gives us a "qc timeout" on boot time. > > I know that the patch below fixes that one, > but I don't know how we should solve that problem > in the correct way. > > Any idea? Yes, I suspect this is because IRQs are not configured properly on your platform. I may be wrong, but I think older kernels may have used PINT for CF IRQs. The SH3 PINT code was removed a while ago since it didn't compile anymore. So now you are most likely without working interrupt support for devices that are hooked up to the PINT controller. Enabling polling in the ata code is of course one option, but fixing up the interrupts sounds like the proper way to fix this imo... I'd like to help you guys and add working PINT support to the kernel, but first someone has to figure out how the CF interrupt is connected to the processor. Which pin basically. If someone can find that then we have something to work with. I don't have any such HP hardware myself, so it's kind of difficult for me to solve this alone. If CF support used to work at some point then a complete working kernel with source would help as well. Thanks, / magnus |
From: Paul M. <le...@li...> - 2007-11-06 23:49:58
|
On Tue, Nov 06, 2007 at 08:43:16PM +0900, Magnus Damm wrote: > On Sep 21, 2007 3:07 PM, Paul Mundt <le...@li...> wrote: > > On Sat, Sep 15, 2007 at 11:00:46AM +0900, shinkoi2005 wrote: > > > > Is the libata code working properly with 8 bit reads? Is this patch > > > > all it takes to get CF working on R2D-1? > > > > > > At least, cf_ide_resources[](register map) is also incorrect with R2D-PLUS. > > > Please check follow kernel which support P2D-PLUS and AT/PC arch's ATA register map. > > > <http://www.superh-linux.org/archive/bsp/sh7751r_r2d/linux-2.6.14.4-R2D+_20060906.tar.bz2> > > > R2D* board's ide register map is compatible without register access size. > > > > > > Here is the same patch... > > > I can boot R2D-1 from IDE's rootfs with this patch. > > > > > I suppose we can do this, I'll tidy up the patch a bit and apply it, > > thanks. It's probably worth doing the same thing for R7780RP, at least > > for the 2 or 3 people that have one of those antiquated things :-) > > I happen to have two of these R2D-1 boards and I can't get CF working > using the latest kernel (latest sh-2.6 git, post 2.6.24-rc1) : > > ... > irq 107: nobody cared (try booting with the "irqpoll" option) > [stack dump] > [call trace] > handlers: > [<8c24f660>] (ata_interrupt+0x0/0x240) > Disabling IRQ #107 > ... > Did R2D-1 CF work for you with IRQs prior to this change? And does reverting it fix get R2D-1 CF working again? The nobody cared thing is curious, if you can provide the stack dump/call trace and register state it might shed some light on why ata_interrupt isn't handling it. You may also want to hack up some debug stuff that dumps out the IRQ desc state for IRQ #107, to make sure that nothing is being clobbered. > I can get things working by hacking in code to enable polling in > pata_platform.c though, so I assume that the IO-ports are ok. > It might be worthwhile making the polling configurable, if you want to tidy up a patch for that we can see if it's something work abstracting. It's handy for debugging, at least. |
From: Magnus D. <mag...@gm...> - 2007-11-07 02:38:47
|
On Nov 7, 2007 8:49 AM, Paul Mundt <le...@li...> wrote: > On Tue, Nov 06, 2007 at 08:43:16PM +0900, Magnus Damm wrote: > > On Sep 21, 2007 3:07 PM, Paul Mundt <le...@li...> wrote: > > > On Sat, Sep 15, 2007 at 11:00:46AM +0900, shinkoi2005 wrote: > > > > > Is the libata code working properly with 8 bit reads? Is this patch > > > > > all it takes to get CF working on R2D-1? > > > > > > > > At least, cf_ide_resources[](register map) is also incorrect with R2D-PLUS. > > > > Please check follow kernel which support P2D-PLUS and AT/PC arch's ATA register map. > > > > <http://www.superh-linux.org/archive/bsp/sh7751r_r2d/linux-2.6.14.4-R2D+_20060906.tar.bz2> > > > > R2D* board's ide register map is compatible without register access size. > > > > > > > > Here is the same patch... > > > > I can boot R2D-1 from IDE's rootfs with this patch. > > > > > > > I suppose we can do this, I'll tidy up the patch a bit and apply it, > > > thanks. It's probably worth doing the same thing for R7780RP, at least > > > for the 2 or 3 people that have one of those antiquated things :-) > > > > I happen to have two of these R2D-1 boards and I can't get CF working > > using the latest kernel (latest sh-2.6 git, post 2.6.24-rc1) : > > > > ... > > irq 107: nobody cared (try booting with the "irqpoll" option) > > [stack dump] > > [call trace] > > handlers: > > [<8c24f660>] (ata_interrupt+0x0/0x240) > > Disabling IRQ #107 > > ... > > > Did R2D-1 CF work for you with IRQs prior to this change? And does > reverting it fix get R2D-1 CF working again? The nobody cared thing is > curious, if you can provide the stack dump/call trace and register state > it might shed some light on why ata_interrupt isn't handling it. The CF for R2D-1 was disabled without this patch - mainly because I had trouble trying to use it. I thought it had something to do with the access size and this patch would solve it, but apparently not. I wonder if CF support in 2.6.24-rc2 works on R2D-1 for other people... I played around with trying to move the enable-bit in the R2D-specific IRLMON register to see if we are enabling the wrong interrupt, but it seems like we are using the correct bit. It's the same bit used for CF IDE as on R2D-PLUS btw. The interrupt documentation for R2D is pretty vague though. I'm guessing that something is wrong with trigger level. The R2D-1 documentation does say something about the CF IDE interrupt level to be H while the rest of the sources are L what ever that means. I don't think we can control it in the FPGA either. Again, R2D-PLUS works just fine. I'm using the same CF card for the test too. > You may also want to hack up some debug stuff that dumps out the IRQ desc > state for IRQ #107, to make sure that nothing is being clobbered. I've disabled all other interrupts in the fpga and just using the single CF IDE source still makes the code bomb out. If I keep the IRQ 107 source but assigns it to a non-existing mask bit then no interrupts are delivered and no crash - just as expected. The ata code takes forever and eventually times out. Adding polling makes things work again. > > I can get things working by hacking in code to enable polling in > > pata_platform.c though, so I assume that the IO-ports are ok. > > > It might be worthwhile making the polling configurable, if you want to > tidy up a patch for that we can see if it's something work abstracting. > It's handy for debugging, at least. The generic ata code needed an IRQ last time i checked. Otherwise i'd prefer to not set the interrupt in the platform data to enable polling. In the end the only thing required is this (mangled patch hunk): +++ work/drivers/ata/pata_platform.c 2007-10-03 09:22:17.000000000 +0900 @@ -188,6 +188,10 @@ static int __devinit pata_platform_probe ap->pio_mask = pio_mask; ap->flags |= ATA_FLAG_SLAVE_POSS; +#ifdef CONFIG_PATA_PLATFORM_POLLING + ap->flags |= ATA_FLAG_PIO_POLLING; +#endif + /* * Handle the MMIO case */ / magnus |
From: Paul M. <le...@li...> - 2007-11-07 03:06:44
|
On Wed, Nov 07, 2007 at 11:38:42AM +0900, Magnus Damm wrote: > On Nov 7, 2007 8:49 AM, Paul Mundt <le...@li...> wrote: > > On Tue, Nov 06, 2007 at 08:43:16PM +0900, Magnus Damm wrote: > > > I happen to have two of these R2D-1 boards and I can't get CF working > > > using the latest kernel (latest sh-2.6 git, post 2.6.24-rc1) : > > > > > > ... > > > irq 107: nobody cared (try booting with the "irqpoll" option) > > > [stack dump] > > > [call trace] > > > handlers: > > > [<8c24f660>] (ata_interrupt+0x0/0x240) > > > Disabling IRQ #107 > > > ... > > > > > Did R2D-1 CF work for you with IRQs prior to this change? And does > > reverting it fix get R2D-1 CF working again? The nobody cared thing is > > curious, if you can provide the stack dump/call trace and register state > > it might shed some light on why ata_interrupt isn't handling it. > > The CF for R2D-1 was disabled without this patch - mainly because I > had trouble trying to use it. I thought it had something to do with > the access size and this patch would solve it, but apparently not. I > wonder if CF support in 2.6.24-rc2 works on R2D-1 for other people... > The access size problem causes a bus lock, so that's still a problem, even if IRQs are hosed. > I'm guessing that something is wrong with trigger level. The R2D-1 > documentation does say something about the CF IDE interrupt level to > be H while the rest of the sources are L what ever that means. I don't > think we can control it in the FPGA either. > That suggestions that R2D-1 is using level high. It's possible to set the sense selection on this already at request_irq() time, blackfin ended up having to do this, and so added the ability to pass on IRQ flags via private data. See pata_platform_info->irq_flags in linux/pata_platform.h. I suppose we should be setting the sense selection level high for all of the R2D boards, in that case. > > > I can get things working by hacking in code to enable polling in > > > pata_platform.c though, so I assume that the IO-ports are ok. > > > > > It might be worthwhile making the polling configurable, if you want to > > tidy up a patch for that we can see if it's something work abstracting. > > It's handy for debugging, at least. > > The generic ata code needed an IRQ last time i checked. Otherwise i'd > prefer to not set the interrupt in the platform data to enable > polling. In the end the only thing required is this (mangled patch > hunk): > That's easy enough to fix. How about this? --- drivers/ata/libata-core.c | 7 +++++++ drivers/ata/pata_platform.c | 26 ++++++++++++++++++++------ 2 files changed, 27 insertions(+), 6 deletions(-) diff --git a/drivers/ata/libata-core.c b/drivers/ata/libata-core.c index ec3ce12..a0cd6bb 100644 --- a/drivers/ata/libata-core.c +++ b/drivers/ata/libata-core.c @@ -7178,6 +7178,9 @@ int ata_host_register(struct ata_host *host, struct scsi_host_template *sht) * request IRQ and register it. This helper takes necessasry * arguments and performs the three steps in one go. * + * A NULL @irq_handler or invalid IRQ skips the IRQ registration + * and expects the host to have set polling mode on the port. + * * LOCKING: * Inherited from calling layer (may sleep). * @@ -7194,6 +7197,10 @@ int ata_host_activate(struct ata_host *host, int irq, if (rc) return rc; + /* Special case for polling mode */ + if (!irq_handler || irq < 0) + return ata_host_register(host, sht); + rc = devm_request_irq(host->dev, irq, irq_handler, irq_flags, dev_driver_string(host->dev), host); if (rc) diff --git a/drivers/ata/pata_platform.c b/drivers/ata/pata_platform.c index fc72a96..1d712ec 100644 --- a/drivers/ata/pata_platform.c +++ b/drivers/ata/pata_platform.c @@ -1,7 +1,7 @@ /* * Generic platform device PATA driver * - * Copyright (C) 2006 Paul Mundt + * Copyright (C) 2006 - 2007 Paul Mundt * * Based on pata_pcmcia: * @@ -22,7 +22,7 @@ #include <linux/pata_platform.h> #define DRV_NAME "pata_platform" -#define DRV_VERSION "1.1" +#define DRV_VERSION "1.2" static int pio_mask = 1; @@ -137,11 +137,12 @@ static int __devinit pata_platform_probe(struct platform_device *pdev) struct ata_port *ap; struct pata_platform_info *pp_info; unsigned int mmio; + int irq; /* * Simple resource validation .. */ - if (unlikely(pdev->num_resources != 3)) { + if ((pdev->num_resources != 3) && (pdev->num_resources != 2)) { dev_err(&pdev->dev, "invalid number of resources\n"); return -EINVAL; } @@ -173,6 +174,11 @@ static int __devinit pata_platform_probe(struct platform_device *pdev) (ctl_res->flags == IORESOURCE_MEM)); /* + * And the IRQ + */ + irq = platform_get_irq(pdev, 0); + + /* * Now that that's out of the way, wire up the port.. */ host = ata_host_alloc(&pdev->dev, 1); @@ -185,6 +191,14 @@ static int __devinit pata_platform_probe(struct platform_device *pdev) ap->flags |= ATA_FLAG_SLAVE_POSS; /* + * Use polling mode if there's no IRQ + */ + if (irq < 0) { + ap->flags |= ATA_FLAG_PIO_POLLING; + ata_port_desc(ap, "no IRQ, using PIO polling"); + } + + /* * Handle the MMIO case */ if (mmio) { @@ -213,9 +227,9 @@ static int __devinit pata_platform_probe(struct platform_device *pdev) (unsigned long long)ctl_res->start); /* activate */ - return ata_host_activate(host, platform_get_irq(pdev, 0), - ata_interrupt, pp_info ? pp_info->irq_flags - : 0, &pata_platform_sht); + return ata_host_activate(host, irq, ata_interrupt, + pp_info ? pp_info->irq_flags : 0, + &pata_platform_sht); } /** |
From: Magnus D. <mag...@gm...> - 2007-11-08 08:30:13
|
On Nov 7, 2007 12:06 PM, Paul Mundt <le...@li...> wrote: > On Wed, Nov 07, 2007 at 11:38:42AM +0900, Magnus Damm wrote: > > On Nov 7, 2007 8:49 AM, Paul Mundt <le...@li...> wrote: > > > On Tue, Nov 06, 2007 at 08:43:16PM +0900, Magnus Damm wrote: > > > > I happen to have two of these R2D-1 boards and I can't get CF working > > > > using the latest kernel (latest sh-2.6 git, post 2.6.24-rc1) : > > > > > > > > ... > > > > irq 107: nobody cared (try booting with the "irqpoll" option) > > > > [stack dump] > > > > [call trace] > > > > handlers: > > > > [<8c24f660>] (ata_interrupt+0x0/0x240) > > > > Disabling IRQ #107 > > > > ... > > > > > > > Did R2D-1 CF work for you with IRQs prior to this change? And does > > > reverting it fix get R2D-1 CF working again? The nobody cared thing is > > > curious, if you can provide the stack dump/call trace and register state > > > it might shed some light on why ata_interrupt isn't handling it. > > > > The CF for R2D-1 was disabled without this patch - mainly because I > > had trouble trying to use it. I thought it had something to do with > > the access size and this patch would solve it, but apparently not. I > > wonder if CF support in 2.6.24-rc2 works on R2D-1 for other people... > > > The access size problem causes a bus lock, so that's still a problem, > even if IRQs are hosed. Sure. But the author of this patch - Aoi Shinkai - claims that he could use a root file system on CF so I assume that he had something working there. Aoi Shinkai, are you there? Does CF work for you with rc2 on R2D-1? > > I'm guessing that something is wrong with trigger level. The R2D-1 > > documentation does say something about the CF IDE interrupt level to > > be H while the rest of the sources are L what ever that means. I don't > > think we can control it in the FPGA either. > > > That suggestions that R2D-1 is using level high. It's possible to set the > sense selection on this already at request_irq() time, blackfin ended up > having to do this, and so added the ability to pass on IRQ flags via > private data. See pata_platform_info->irq_flags in linux/pata_platform.h. > I suppose we should be setting the sense selection level high for all of > the R2D boards, in that case. But does setting these flags really change anything in the interrupt code? There are unfortunately no registers to set the actual sense configuration in the fpga so whatever you pass to request_irq() will be ignored since we have no means to change the sense settings. > > > > I can get things working by hacking in code to enable polling in > > > > pata_platform.c though, so I assume that the IO-ports are ok. > > > > > > > It might be worthwhile making the polling configurable, if you want to > > > tidy up a patch for that we can see if it's something work abstracting. > > > It's handy for debugging, at least. > > > > The generic ata code needed an IRQ last time i checked. Otherwise i'd > > prefer to not set the interrupt in the platform data to enable > > polling. In the end the only thing required is this (mangled patch > > hunk): > > > That's easy enough to fix. How about this? Looks good. I have not tested your patch, but I'd be happy to see such a feature go in. I happen to know a few different boards that would be more than happy to make use of this kind of feature... Thanks. / magnus |
From: Paul M. <le...@li...> - 2007-11-08 08:43:08
|
On Thu, Nov 08, 2007 at 05:30:08PM +0900, Magnus Damm wrote: > On Nov 7, 2007 12:06 PM, Paul Mundt <le...@li...> wrote: > > On Wed, Nov 07, 2007 at 11:38:42AM +0900, Magnus Damm wrote: > > > I'm guessing that something is wrong with trigger level. The R2D-1 > > > documentation does say something about the CF IDE interrupt level to > > > be H while the rest of the sources are L what ever that means. I don't > > > think we can control it in the FPGA either. > > > > > That suggestions that R2D-1 is using level high. It's possible to set the > > sense selection on this already at request_irq() time, blackfin ended up > > having to do this, and so added the ability to pass on IRQ flags via > > private data. See pata_platform_info->irq_flags in linux/pata_platform.h. > > I suppose we should be setting the sense selection level high for all of > > the R2D boards, in that case. > > But does setting these flags really change anything in the interrupt > code? There are unfortunately no registers to set the actual sense > configuration in the fpga so whatever you pass to request_irq() will > be ignored since we have no means to change the sense settings. > No, if the IRQ controller has no ability to change the sense selection, there's not a lot we can do with it. FPGAs being uselessly implemented are unfortunately nothing new, and neither are hardware designers screwing up IRQ assignments. We already have plenty of cases where edge-only SuperIOs are interfaced to level-only pins, leading to ethernet performance comparable to SLIP on a broken serial cable. At least we can fix the FPGAs. Fixing the hardware designers is generally socially frowned upon ;-) |
From: shinkoi2005 <shi...@gm...> - 2007-11-08 11:35:39
|
> Aoi Shinkai, are you there? Does CF work for you with rc2 on R2D-1? CF works fine with vanilla 2.6.24-rc2 on R2D-1. (R2D-1 can boot from CF's rootfs with vanilla 2.6.24-rc2.) I suspect that your R2D-1 is fpga rev1.0. rev1.0 and rev1.1 IRL table is following. (That is taken from old include/asm-sh/rts7751r2d.h.) ------ #if defined(CONFIG_RTS7751R2D_REV11) #define IRQ_PCIETH 0 /* PCI Ethernet IRQ */ #define IRQ_CFCARD 1 /* CF Card IRQ */ #define IRQ_CFINST 2 /* CF Card Insert IRQ */ #define IRQ_PCMCIA 3 /* PCMCIA IRQ */ #define IRQ_VOYAGER 4 /* VOYAGER IRQ */ #define IRQ_ONETH 5 /* On board Ethernet IRQ */ #else #define IRQ_KEYIN 0 /* Key Input IRQ */ #define IRQ_PCIETH 1 /* PCI Ethernet IRQ */ #define IRQ_CFCARD 2 /* CF Card IRQ */ #define IRQ_CFINST 3 /* CF Card Insert IRQ */ #define IRQ_PCMCIA 4 /* PCMCIA IRQ */ #define IRQ_VOYAGER 5 /* VOYAGER IRQ */ #endif #define IRQ_RTCALM 6 /* RTC Alarm IRQ */ #define IRQ_RTCTIME 7 /* RTC Timer IRQ */ #define IRQ_SDCARD 8 /* SD Card IRQ */ #define IRQ_PCISLOT1 9 /* PCI Slot #1 IRQ */ #define IRQ_PCISLOT2 10 /* PCI Slot #2 IRQ */ #define IRQ_EXTENTION 11 /* EXTn IRQ */ ------- And I guess that recent implementation is only for rev1.1. arch/sh/boards/renesas/rts7751r2d/irq.c:L65 ------- /* IRLn to IRQ table for R2D-1 */ static unsigned char irl2irq_r2d_1[R2D_NR_IRL] __initdata = { IRQ_PCI_INTD, IRQ_CF_IDE, IRQ_CF_CD, IRQ_PCI_INTC, IRQ_VOYAGER, IRQ_AX88796, IRQ_RTC_A, IRQ_RTC_T, IRQ_SDCARD, IRQ_PCI_INTA, IRQ_PCI_INTB, IRQ_EXT, IRQ_TP, }; ------- I think that it's worth changing IRL table for rev1.0.... |
From: Magnus D. <mag...@gm...> - 2007-11-09 12:36:43
|
Hi there, Thanks for the reply! On Nov 8, 2007 8:34 PM, shinkoi2005 <shi...@gm...> wrote: > > Aoi Shinkai, are you there? Does CF work for you with rc2 on R2D-1? > CF works fine with vanilla 2.6.24-rc2 on R2D-1. > (R2D-1 can boot from CF's rootfs with vanilla 2.6.24-rc2.) I'm glad that it works on your R2D-1. Both my R2D-1 boards do not have working CF. Just to double-check - are using a R2D with one or two pci slots? > I suspect that your R2D-1 is fpga rev1.0. > rev1.0 and rev1.1 IRL table is following. Yeah, maybe it is related to fpga version. I sort of assumed that the option CONFIG_RTS7751R2D_REV11 was a complicated way of switching between R2D-PLUS and R2D-1. But maybe it's related to fpga version as you suggest. I have no idea. > (That is taken from old include/asm-sh/rts7751r2d.h.) > > ------ > #if defined(CONFIG_RTS7751R2D_REV11) > #define IRQ_PCIETH 0 /* PCI Ethernet IRQ */ > #define IRQ_CFCARD 1 /* CF Card IRQ */ > #define IRQ_CFINST 2 /* CF Card Insert IRQ */ > #define IRQ_PCMCIA 3 /* PCMCIA IRQ */ > #define IRQ_VOYAGER 4 /* VOYAGER IRQ */ > #define IRQ_ONETH 5 /* On board Ethernet IRQ */ > #else > #define IRQ_KEYIN 0 /* Key Input IRQ */ > #define IRQ_PCIETH 1 /* PCI Ethernet IRQ */ > #define IRQ_CFCARD 2 /* CF Card IRQ */ > #define IRQ_CFINST 3 /* CF Card Insert IRQ */ > #define IRQ_PCMCIA 4 /* PCMCIA IRQ */ > #define IRQ_VOYAGER 5 /* VOYAGER IRQ */ > #endif Right. It looks like the IRL level should differ, but I get the same IRL level for both R2D-1 and R2D-PLUS. Maybe my R2D-1 boards are special... > And I guess that recent implementation is only for rev1.1. Not sure which revision, but everything except CF works for my R2D-1 and R2D-PLUS boards... > I think that it's worth changing IRL table for rev1.0.... Sure, if that what it takes. I need to look into this more. Can you please post the BVERREG and VERREG register values from your R2D-1? Then I'll post mine when I get back into the office. Have a nice weekend! / magnus |
From: Paul M. <le...@li...> - 2007-11-10 03:41:46
|
On Fri, Nov 09, 2007 at 09:36:38PM +0900, Magnus Damm wrote: > On Nov 8, 2007 8:34 PM, shinkoi2005 <shi...@gm...> wrote: > > I suspect that your R2D-1 is fpga rev1.0. > > rev1.0 and rev1.1 IRL table is following. > > Yeah, maybe it is related to fpga version. I sort of assumed that the > option CONFIG_RTS7751R2D_REV11 was a complicated way of switching > between R2D-PLUS and R2D-1. But maybe it's related to fpga version as > you suggest. I have no idea. > This config option predates the creation of the R2D+ board completely, so it being FPGA-relative would seem logical. Anyways, mapping out the differing IRL tables depending on FPGA version at boot time isn't much more of a hassle than the current R2D-1 and R2D+ decoupling. |
From: Magnus D. <mag...@gm...> - 2007-11-13 10:46:33
|
On Nov 13, 2007 12:15 AM, shinkoi2005 <shi...@gm...> wrote: > > I'm glad that it works on your R2D-1. Both my R2D-1 boards do not have > > working CF. Just to double-check - are using a R2D with one or two pci > > slots? > My R2D-1 has two pci slots. > The picture is the following. > <http://tree.celinuxforum.org/pubwiki/moin.cgi/RTS7751R2DHandlingManual> Ok, that looks like the same model as I have. > > Can you please post the BVERREG and VERREG register values from your > > R2D-1? Then I'll post mine when I get back into the office. > My R2D-1's VERREG and BVERREG is the folloing. > R2D VERREG:0x0033, BVERREG:0x0011 My two R2D-1 boards say: R2D VERREG:0x0033, BVERREG:0x0011 (00:00:e1:6b:5f:c2) R2D VERREG:0x0034, BVERREG:0x0011 (00:00:87:6b:af:69) The boards do not work with the only CF card we have in the office at the moment. I'll bring a pile of different CF cards from home tomorrow to check if the actual CF card is strange. I've seen interrupt problems with certain older CF cards on other platforms earlier so this wouldn't surprise me at all. Thanks for your help! / magnus |
From: Magnus D. <mag...@gm...> - 2007-11-14 08:33:49
|
On Nov 13, 2007 7:46 PM, Magnus Damm <mag...@gm...> wrote: > On Nov 13, 2007 12:15 AM, shinkoi2005 <shi...@gm...> wrote: > > > I'm glad that it works on your R2D-1. Both my R2D-1 boards do not have > > > working CF. Just to double-check - are using a R2D with one or two pci > > > slots? > > My R2D-1 has two pci slots. > > The picture is the following. > > <http://tree.celinuxforum.org/pubwiki/moin.cgi/RTS7751R2DHandlingManual> > > Ok, that looks like the same model as I have. > > > > Can you please post the BVERREG and VERREG register values from your > > > R2D-1? Then I'll post mine when I get back into the office. > > My R2D-1's VERREG and BVERREG is the folloing. > > R2D VERREG:0x0033, BVERREG:0x0011 > > My two R2D-1 boards say: > R2D VERREG:0x0033, BVERREG:0x0011 (00:00:e1:6b:5f:c2) > R2D VERREG:0x0034, BVERREG:0x0011 (00:00:87:6b:af:69) > > The boards do not work with the only CF card we have in the office at > the moment. I'll bring a pile of different CF cards from home tomorrow > to check if the actual CF card is strange. I've seen interrupt > problems with certain older CF cards on other platforms earlier so > this wouldn't surprise me at all. Ok, so i've tested with a bunch of different CF cards and the R2D-1 FPGA seems to support fewer CF models than R2D-PLUS. Here it goes, just booting - tested with 2.6.24-rc2-git: Mitsubishi 22.5 MB - R2D-PLUS: bad, R2D-1: bad Viking 24 MB - R2D-PLUS: ok, R2D-1:ok SanDisk 128MB - R2D-PLUS: ok, R2D-1: ok PQI 40x 128MB - R2D-PLUS: ok, R2D-1: bad SanDisk Ultra II 512 MB - R2D-PLUS: ok, R2D-1: ok I-O DATA x115 512 MB - R2D-PLUS: ok, R2D-1: ok IBM Microdrive 1 GB - R2D-PLUS: ok, R2D-1: ok I'll post a patch that enables polling on R2D-1. / magnus |