From mboxrd@z Thu Jan 1 00:00:00 1970 From: Tejun Heo Subject: Re: [PATCH linux-2.6.13-rc3] Mod15Write quirk against v2.6.13 Date: Mon, 22 Aug 2005 05:45:40 +0900 Message-ID: <4308E7F4.3000509@gmail.com> References: <1121894035.4885.15.camel@drevil.aslab.com> <20050728141242.GA10010@htj.dyndns.org> <4308D3D0.50504@pobox.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Return-path: Received: from zproxy.gmail.com ([64.233.162.203]:63623 "EHLO zproxy.gmail.com") by vger.kernel.org with ESMTP id S1750895AbVHUUpu (ORCPT ); Sun, 21 Aug 2005 16:45:50 -0400 Received: by zproxy.gmail.com with SMTP id i11so590983nzh for ; Sun, 21 Aug 2005 13:45:46 -0700 (PDT) In-Reply-To: <4308D3D0.50504@pobox.com> Sender: linux-ide-owner@vger.kernel.org List-Id: linux-ide@vger.kernel.org To: Jeff Garzik Cc: Michael Madore , linux-ide@vger.kernel.org, albertcc@tw.ibm.com Hello, Jeff. Jeff Garzik wrote: > Tejun Heo wrote: > >> Also, Jeff, I know you're very busy, but what do you think about >> taking m15w workaround into ata tree? It's been around for a while >> now and I haven't received any complaints (except for this one) yet. >> The workaround is ugly but it surely helps and I'm willing to maintain >> it. > > > I think your mod15write solution is too messy to deal with long-term. > Maintenance burden is much lower on us without it. It's not too > difficult to simply avoid certain combinations of hardware. > No problem, I'll maintain it out of tree. > Note! As Carlos @ Silicon Image points out, the blacklist should only > apply to SiI 3112, not 3512/3114/etc. That's an open FIXME that would > benefit users. > Cool, I'll submit a patch right away. > >> One thing that bothers me is how Albert's commit and the original >> ata_host_intr tell IRQ subsystem that an interrupt isn't ours when we >> know that we have generated a spurious interrupt. IMHO, we always >> should enter ata_host_intr and always tell IRQ subsystem that it's our >> interrupt if bmdma_status tells us so, regardless of ata status value. >> The current code is likely to cause "nobody cared" error which can be >> avoided. > > > If there is a mismatch between BMDMA's IRQ bit and ATA device indicating > an interrupt, that's a host state machine[1] violation that should be > addressed elsewhere. > > I wouldn't mind using BMDMA IRQ bit as an indicator of the ATA intrq > status, though. > > (for others) As linked on > > http://www.t13.org/project/d1510r1-Host-Adapter.pdf > via > http://linux.yyz.us/sata/devel.html > > you can find documentation on the BMDMA IRQ bit. > > The main problem with using BMDMA IRQ bit is that it is likely never set > unless the commands are READ/WRITE DMA commands, which means we must > have separate host state machine tracking for PIO and non-data commands, > increasing complexity. > > Jeff > > > > [1] "host state machine" These are illustrated by the state machine > diagrams in ATA/ATAPI-7 Volume 3, under the chapter headings "Bus idle > protocol", "Non-data command protocol", "DMA command protocol", "Ultra > DMA data-{in,out} command protocol". STUDY THESE. Yeap, I'll. -- tejun