LKML Archive on
help / color / mirror / Atom feed
From: Sergei Shtylyov <>
To: Bartlomiej Zolnierkiewicz <>
Subject: Re: [PATCH 2/5] ide: ->ide_dma_clear_irq() -> ->clear_irq()
Date: Tue, 16 Sep 2008 13:16:54 +0400	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>


Bartlomiej Zolnierkiewicz wrote:

>>>> * Rename ->ide_dma_clear_irq method to ->clear_irq
>>>>   and move it from ide_hwif_t to struct ide_port_ops.
>>>> * Move ->waiting_for_dma check inside ->clear_irq method.
>>>> * Move ->dma_base check inside ->clear_irq method.
>>>> piix.c:
>>>> * Add ich_port_ops and remove init_hwif_ich() wrapper.
>>>> There should be no functional changes caused by this patch.
>>>   Good. I think it's worth implementing this method in at least 
>>> cmd64x.c which actually reads the IDE interrupt latch bits 
>>> (independent from the DMA interrupt status) in the dma_test_irq() 
>>> methods but never clears them, so the latches may reflect a 
>>> non-current state of the IDE interrupt...
>>    I forgot that it does clear them in its dma_end() methods (which I 
>> myself have reworked :-).
>>    It seems however that at least for SFF-8038 compatibles, it makes 
>> sense to leave it that way since INTRQ might be asserted while BMIDE 
>> interrupt bit is not, so the interrupt latch would need clearing even on 
>> DMA timeout...
>>>   It may also be worth considering turning this method into 
>>> test-and-clear, so that we can get the actual IDE interrupt state on 
>>> the chips that implement this...
>>    Probably might add the test_irq() method to be called on 
>> !hwif->waiting_for_dma. Cleraing the status at once seems impractical...
> Or we can test for ->waiting_for_dma inside ->test_irq.

   That also will do...

>>>> Signed-off-by: Bartlomiej Zolnierkiewicz <>
>>> Acked-by: Sergei Shtylyov <>
>>    Not feeling sure about this patch -- ->waiting_for_dma probably 
>> should've been left where it was...
> Well, it doesn't change behavior and I think having ->clear_irq method
> independent from the transfer mode is a preffered approach.

   But its implementations will have to depend on it anyway. And 
clearing the IDE interrupt in general already depends on the transfer 
mode -- the BMIDE interrupt which is a (delayed) reflection of INTRQ is 
cleared implicitly by the dma_end() method -- except in at least sgiioc4 
   BTW, sgiioc4 seems another candidate for clear_irq() implementation 
-- currently clearing is done implicitly by the read_status() method (I 
don't quite understand why it clears DMA error interrupt there). 
However, since there's no documentation, I'm not sure how the IDE 
interrupt is latched by IOC4.

> Thanks,
> Bart

MBR, Sergei

  reply	other threads:[~2008-09-16  9:17 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-08-19 18:31 Bartlomiej Zolnierkiewicz
2008-08-19 22:22 ` Sergei Shtylyov
2008-09-15 22:11   ` Sergei Shtylyov
2008-09-15 22:29     ` Bartlomiej Zolnierkiewicz
2008-09-16  9:16       ` Sergei Shtylyov [this message]
2008-11-12  2:01         ` Jeremy Higdon
2009-05-21 14:07     ` Sergei Shtylyov
2009-05-22 18:44       ` ->ack_intr in m68k IDE drivers [was: Re: [PATCH 2/5] ide: ->ide_dma_clear_irq() -> ->clear_irq()] Bartlomiej Zolnierkiewicz
2009-05-22 19:19         ` Sergei Shtylyov
2009-05-22 19:19         ` Sergei Shtylyov

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \ \ \
    --subject='Re: [PATCH 2/5] ide: ->ide_dma_clear_irq() -> ->clear_irq()' \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

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).