Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754984AbcDBAR7 (ORCPT ); Fri, 1 Apr 2016 20:17:59 -0400 Received: from muru.com ([72.249.23.125]:49654 "EHLO muru.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752095AbcDBAR5 (ORCPT ); Fri, 1 Apr 2016 20:17:57 -0400 Date: Fri, 1 Apr 2016 17:17:53 -0700 From: Tony Lindgren To: Peter Ujfalusi Cc: Paul Walmsley , jarkko.nikula@bitmer.com, t-kristo@ti.com, linux-omap@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, devicetree@vger.kernel.org Subject: Re: [PATCH v2 0/3] ARM: OMAP3: Fix McBSP2/3 hwmod setup for sidetone Message-ID: <20160402001753.GR9329@atomide.com> References: <1458311007-19168-1-git-send-email-peter.ujfalusi@ti.com> <56EFB794.5010505@ti.com> <56FE407E.9030803@ti.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <56FE407E.9030803@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: 2700 Lines: 63 Hi, * Peter Ujfalusi [160401 02:34]: > So what shall we do with the OMAP3 McBSP2/3 sidetone? It has been broken in DT > boot since the first time we booted OMAP3 with DT... Only in legacy mode we > can have properly working ST. Grr. > I have the second level of patches based on this set (I think I need to resend > this series since I might have changed it, can not recall) for both arch/arm > and ASoC to have working ST in legacy and DT boot. We will no longer have > warning regarding to broken hwmod data in DT boot. > But all is based on the assumption that we agree at some point that the ST > block is part of the McBSP module ;) The sidetone module is a separate target from the McBSP on the interconnect but there are also direct lines between sidetone and McBSP devices :) Here's what I'm seeing looking at the AP table on dm3730 hardware. McBSP target module: 0x49022000, ap 5 06.0, McBSP2 0x49024000, ap 7 08.0, McBSP3 Sidetone target modules: 0x49028000, ap 39 0a.0, mcbsp2_sidetone 0x4902a000, ap 41 12.0, mcbsp3_sidetone And that seems to match TRM "21.6.4 SIDETONE Register Description", "Table 2-5. L4-Peripheral Memory Space Mapping", and "Table 9-114. Region Allocation for L4-Per Interconnect". > If I need to write separate driver for the McBSP module's ST block, it would > mean some sort of API between the McBSP and ST driver. This is not straight > forward since there are registers both in McBSP block and ST block that needs > to be configured in specific order -> simple enable_st() would not work > (probably enable_st_stage1(), enable_st_stage2()) and callbacks from McBSP to > ST, ST to McBSP also going to be needed. As far as I can see it is going to be > a huge mess. The McBSP and sidetone don't have parent child relationship at the interconnect level. So I think the best option would be to have the McBSP driver implement mcbsp_sidetone_register/unregister() etc functions. That can then set up the necessary callbacks. Then the sidetone driver can call them on probe/exit and set up the necessary callbacks and whatever might be needed. If they are currently handled in a single driver, you you need to pm_runtime_get both modules. So having two separate drivers might make things a lot simpler. If you don't treat the McBSP and sidetone as separate modules, things can easily fail. For example, doing a read-back to flush of posted write to sidetone registers flushes nothing for McBSP and the other way around. > Other option would be to deprecate the ST support as such, but that would > leave the n900 guys in trouble as they need ST to be functional... That does not sound like a nice option at all :( Regards, Tony