Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755400Ab0ANVCF (ORCPT ); Thu, 14 Jan 2010 16:02:05 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1754832Ab0ANVCD (ORCPT ); Thu, 14 Jan 2010 16:02:03 -0500 Received: from earthlight.etchedpixels.co.uk ([81.2.110.250]:45612 "EHLO www.etchedpixels.co.uk" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1754507Ab0ANVCB (ORCPT ); Thu, 14 Jan 2010 16:02:01 -0500 Date: Thu, 14 Jan 2010 21:05:15 +0000 From: Alan Cox To: Krzysztof Halasa Cc: Bartlomiej Zolnierkiewicz , linux-ide@vger.kernel.org, lkml Subject: Re: SATA_SIL on IXP425 workaround Message-ID: <20100114210515.7a477a43@lxorguk.ukuu.org.uk> In-Reply-To: References: <201001141659.19687.bzolnier@gmail.com> <20100114192210.62593ead@lxorguk.ukuu.org.uk> X-Mailer: Claws Mail 3.7.3 (GTK+ 2.18.5; x86_64-redhat-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 988 Lines: 22 > We need to use the MMIO BAR at least for starting DMA transfers, the > I/O ones are 64KB-limited. We can't just use read[bw] if reading all > 32 bits has side effects. Last time I instrumented this on x86 we never issued a > 64K linear block in our s/g lists. In fact we went for years before anyone noticed we had a bug with CS5530 and a couple of other chips that mishandled 64K segment sizes, and that was only finally noticed in a very specific and weird circumstance. > Most of the time there are no problems with MMIO on IXP4xx as modern > devices usually use 32-bit registers anyway, or at least they have no > problem with read[bw] always driving all four PCI byte enable lines > (write[bw] doesn't have this issue). Fair enough -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/