rton <[EMAIL PROTECTED]>,
Jeff Garzik <[EMAIL PROTECTED]>, [EMAIL PROTECTED]
Subject: Re: [RFC] pata_icside driver
On Sun, Apr 08, 2007 at 11:18:26AM +0100, Russell King wrote:
> Below is an initial attempt at converting the ICS IDE driver to fit
> into the PATA infrastruc
On Sun, Apr 08, 2007 at 11:18:26AM +0100, Russell King wrote:
> Below is an initial attempt at converting the ICS IDE driver to fit
> into the PATA infrastructure.
>
> There's a number of FIXMEs in there: due to the hardware missing
> resistors on the interrupt signals from the drives, a port
> wi
Russell King wrote:
On Mon, Apr 09, 2007 at 07:13:05AM -0400, Jeff Garzik wrote:
It should be noted, mainly for russell's benefit, that the ->irq_ack()
hook is only called if a debug define is manually enabled in libata.h,
in a single callsite.
The number of people that actually use the hook
On Mon, Apr 09, 2007 at 07:13:05AM -0400, Jeff Garzik wrote:
> It should be noted, mainly for russell's benefit, that the ->irq_ack()
> hook is only called if a debug define is manually enabled in libata.h,
> in a single callsite.
>
> The number of people that actually use the hook -- kernel hac
On Mon, Apr 09, 2007 at 11:25:06AM +0100, Alan Cox wrote:
> > When you quantise those figures using a clock period of 62.5ns (16MHz)
> > you end up with: 2 clocks active (2*62.5 > 70), 1 clock recovery
> > (1*62.5 > 25) and 2 clocks cycle (2*62.5 > 120).
> >
> > Last time I checked, active + recov
It should be noted, mainly for russell's benefit, that the ->irq_ack()
hook is only called if a debug define is manually enabled in libata.h,
in a single callsite.
The number of people that actually use the hook -- kernel hackers
debugging screaming interrupts -- can probably be counted on one
Alan Cox wrote:
Then no SFF hardware can use ata_irq_ack. Not one card: Because in every
OK
We should just rename ata_irq_ack(). It is in libata-sff, so it's either
wrong (missing a test), or in the wrong file completely.
There is plenty of BMDMA-specific stuff in libata-sff, so neither
a
> The timings the drive sees clearly are not based upon a 16MHz clock
> period. Therefore, I'd prefer to get the nanoseconds from the
> calculation and work from that.
Makes sense.
> Obviously I can demonstrate a bug. 8)
>
> Lets say that we want to do MW DMA mode 2. This has the minimum timin
On Sun, 08 Apr 2007 21:03:10 -0400
Jeff Garzik <[EMAIL PROTECTED]> wrote:
> > ata_irq_ack is part of the SFF layer so its fine that it assumes SFF but
> > its wrong that it is used unconditionally and it shouldn't be used this
> > way. It just needs a (!ap->ioaddr.bmdma_addr) test adding (assuming
On Mon, Apr 09, 2007 at 01:24:45AM -0700, Roland Dreier wrote:
> > Lets say that we want to do MW DMA mode 2. This has the minimum timing
> > of 70ns active, 25ns recovery, 120ns cycle time.
> >
> > When you quantise those figures using a clock period of 62.5ns (16MHz)
> > you end up with: 2
> Lets say that we want to do MW DMA mode 2. This has the minimum timing
> of 70ns active, 25ns recovery, 120ns cycle time.
>
> When you quantise those figures using a clock period of 62.5ns (16MHz)
> you end up with: 2 clocks active (2*62.5 > 70), 1 clock recovery
> (1*62.5 > 25) and 2 clo
On Sun, Apr 08, 2007 at 09:09:17PM +0100, Alan Cox wrote:
> > + /*
> > +* DMA is based on a 16MHz clock
> > +*/
> > + if (ata_timing_compute(adev, adev->dma_mode, &t, 1000, 1))
> > + return;
>
> This seems strange for a 16MHz clock.
We do this because, although the underlyin
Alan Cox wrote:
The second FIXME area is ata_irq_ack - it is unconditionally coded
for SFF-type interfaces. I believe that using this function in
non-BMDMA interfaces is wrong - it attempts to read from the BMDMA
registers irrespective of whether ap->ioaddr.bmdma_addr is set or
not. The questio
> + /*
> + * DMA is based on a 16MHz clock
> + */
> + if (ata_timing_compute(adev, adev->dma_mode, &t, 1000, 1))
> + return;
This seems strange for a 16MHz clock.
> +
> + /*
> + * Now, properly adjust the timings. If we have a 62.5ns clock
> + * period
> The second FIXME area is ata_irq_ack - it is unconditionally coded
> for SFF-type interfaces. I believe that using this function in
> non-BMDMA interfaces is wrong - it attempts to read from the BMDMA
> registers irrespective of whether ap->ioaddr.bmdma_addr is set or
> not. The question this p
Below is an initial attempt at converting the ICS IDE driver to fit
into the PATA infrastructure.
There's a number of FIXMEs in there: due to the hardware missing
resistors on the interrupt signals from the drives, a port
without any drives attached results in spurious interrupts being
generated.
16 matches
Mail list logo
