Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Thu, 13 Dec 2001 14:11:50 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Thu, 13 Dec 2001 14:11:41 -0500 Received: from mail.libertysurf.net ([213.36.80.91]:23334 "EHLO mail.libertysurf.net") by vger.kernel.org with ESMTP id convert rfc822-to-8bit; Thu, 13 Dec 2001 14:11:26 -0500 Date: Thu, 13 Dec 2001 17:17:22 +0100 (CET) From: =?ISO-8859-1?Q?G=E9rard_Roudier?= X-X-Sender: To: "David S. Miller" cc: , , , , Subject: Re: highmem, aic7xxx, and vfat: too few segs for dma mapping In-Reply-To: <20011212.162603.28785873.davem@redhat.com> Message-ID: <20011213165932.L1871-100000@gerard> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: 8BIT Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org On Wed, 12 Dec 2001, David S. Miller wrote: > From: G?rard Roudier > Date: Wed, 12 Dec 2001 21:24:59 +0100 (CET) > > A N% loss for the 99% case in order to support the 1% is close to N% > loss. So, each time we bloat or complexify the code with no relevance for > the average case, the overall difference cannot be a win. > > Do you know, you can use this N% loss to implement handling of the > very problem you have wrt. sym53c8xx hw bugs? :-) What hw bugs ? :-) The driver is very fortunate. Based on DELs, only a few known hw bugs have had to be worked-around by sym drivers. In fact, you can avoid most bugs, by taking into account usual bugs in PCI hw. When I have made sym53c8xx from ncr53c8xx, I had some clues in mind. The 16MB/32MB boundary I pointed out can only affect sym53c896 rev. 1, and only in not very likely situations. In plan to resurrect the work-around in Linux sym_glue.c if pci_map_sg() will not want to handle the issue. So, on paper, you were talking about a single unlikely to happen hw bug. :-) > To be honest all the machinery to handle the problems you have > described are there today, even with IOMMU's present. The generic > block layer today knows when IOMMU is being used, it knows what kind > of coalescing can and will be done by the IOMMU support code (via > DMA_CHUNK_SIZE), and therefore it is capable of adhering to any > restrictions you care to describe to the block layer. Will look into all these great things over the week-end and let you all know my remarks if any. > It's only a matter of coding on Jens's part :-) Jen's seems to be a great and very courageous coder, so let me trust him not to miss anything important. :) Thanks for your reply, G?rard. PS: Don't take the wrong way my statements against Sun stuff. In fact, I dislike almost everything that comes and came from them. :) - 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/