Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752121AbcCVT35 (ORCPT ); Tue, 22 Mar 2016 15:29:57 -0400 Received: from muru.com ([72.249.23.125]:49084 "EHLO muru.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751842AbcCVT3z (ORCPT ); Tue, 22 Mar 2016 15:29:55 -0400 Date: Tue, 22 Mar 2016 12:29:52 -0700 From: Tony Lindgren To: Peter Ujfalusi Cc: Paul Walmsley , Liam Girdwood , Mark Brown , Jarkko Nikula , Tero Kristo , linux-omap@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, devicetree@vger.kernel.org, alsa-devel@alsa-project.org Subject: Re: [PATCH 0/3] ARM: OMAP3: Fix McBSP2/3 hwmod setup for sidetone Message-ID: <20160322192951.GP9329@atomide.com> References: <1458296929-718-1-git-send-email-peter.ujfalusi@ti.com> <56EFB31C.9090103@ti.com> <20160321202107.GO9329@atomide.com> <56F107FF.8080006@ti.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <56F107FF.8080006@ti.com> User-Agent: Mutt/1.5.24 (2015-08-30) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1103 Lines: 33 * Peter Ujfalusi [160322 01:54]: > Tony, > > On 03/21/16 22:21, Tony Lindgren wrote: > > Hi, > > > > * Peter Ujfalusi [160321 01:39]: > >> > >> This is also interesting: > >> McBSP2 sidetone is in region 39 and 40 (module and L4 interconnect) which is > >> unique in case of OMAP34xx and OMAP35xx, but it is overlapping with GPIO6 on > >> OMAP36xx. Not sure what are the implications. > > > > Hmm GPIO6 is in a different L4 segment though? Maybe > > you did not account for the segments? > > > > 0x49000000 + 0x20000 + 0x2000/0x4000/0x6000 for McBSP > > 0x49000000 + 0x50000 + 0x8000 for GPIO6 > > > > Or maybe I don't understand at which physical address the > > overlap is? :) > > The addresses are not overlapping, but the Region Numbers for GPIO6 and McBSP2 > sidetone in Table 9-114 "Region Allocation for > L4-Per Interconnect". But only in case of OMAP36xx Oh OK, yeah the TRM region numbers are wrong, they skip unused entries compared to the hardware AP table :) Basically the TRM AP region numbering is useless and wrong. Regards, Tony