Re: rts7751r2d cf_ide rework

[Magnus D. <mag...@gm...>]

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