Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1758047Ab0KORxm (ORCPT ); Mon, 15 Nov 2010 12:53:42 -0500 Received: from va3ehsobe004.messaging.microsoft.com ([216.32.180.14]:23252 "EHLO VA3EHSOBE004.bigfish.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756323Ab0KORxl (ORCPT ); Mon, 15 Nov 2010 12:53:41 -0500 X-SpamScore: -20 X-BigFish: VS-20(zz1432N98dN9371Pzz1202hzz8275dhz2dh2a8h668h61h) X-Spam-TCS-SCL: 0:0 X-Forefront-Antispam-Report: KIP:(null);UIP:(null);IPVD:NLI;H:de01egw02.freescale.net;RD:de01egw02.freescale.net;EFVD:NLI Date: Mon, 15 Nov 2010 11:53:11 -0600 From: Scott Wood To: Kumar Gala CC: Timur Tabi , , , Subject: Re: [PATCH v2] fsldma: add support to 36-bit physical address Message-ID: <20101115115311.72429aa9@udp111988uds.am.freescale.net> In-Reply-To: <72D46FED-AFC8-4599-ADB0-2A2B634CCE48@kernel.crashing.org> References: <1289477789-10651-1-git-send-email-leoli@freescale.com> <54AAF9B7-9533-45B8-9C49-A964203AF707@kernel.crashing.org> <3B38AD35-39A2-4A54-8109-65D6DE436227@kernel.crashing.org> <72D46FED-AFC8-4599-ADB0-2A2B634CCE48@kernel.crashing.org> X-Mailer: Claws Mail 3.7.4 (GTK+ 2.20.1; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 15 Nov 2010 17:54:10.0951 (UTC) FILETIME=[1B8D2970:01CB84EE] X-OriginatorOrg: freescale.com Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1408 Lines: 31 On Mon, 15 Nov 2010 11:43:12 -0600 Kumar Gala wrote: > > On Nov 15, 2010, at 10:13 AM, Timur Tabi wrote: > > > On Mon, Nov 15, 2010 at 9:16 AM, Kumar Gala wrote: > > > >> The programming model (if you look at the free-space in the registers and data structures) supports a 64-bit address. I'm trying to avoid changing the driver in the future if we have >36-bit. However this is such a minor worry that I'll stop and just ack the patch as is. > > > > I must still be missing something. I'm looking at the description of > > the SATR register in the MPC8572 RM, and it shows this: > > > > 0 - 3 | 4 - 5 | 6 | 7 | 8 - 11 | 12 - 15 | 16-21 | 22-31 > > --- | STFLOWLVL | SPCIORDER | SSME | STRANSINT | SREADTTYPE | --- | ESAD > > > > The most that we can extend ESAD to is 16 bits, for a total of a > > 48-bit physical address. Where are the other 16 bits supposed to go? > > I was looking at the link addresses. I stand corrected so our max is 48-bits. Looks like 42 bits -- just because bits 16-21 could be used to extend ESAD doesn't mean that they have been. -Scott -- 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/