From mboxrd@z Thu Jan 1 00:00:00 1970 From: Peter Ujfalusi Subject: Re: [PATCH v2 0/3] ARM: OMAP3: Fix McBSP2/3 hwmod setup for sidetone Date: Mon, 21 Mar 2016 10:57:56 +0200 Message-ID: <56EFB794.5010505@ti.com> References: <1458311007-19168-1-git-send-email-peter.ujfalusi@ti.com> Mime-Version: 1.0 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: QUOTED-PRINTABLE Return-path: In-Reply-To: Sender: devicetree-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org To: Paul Walmsley Cc: tony-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org, jarkko.nikula-FVTvWyuFUl3QT0dZR+AlfA@public.gmane.org, t-kristo-l0cyMroinI0@public.gmane.org, linux-omap-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org, linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org List-Id: linux-omap@vger.kernel.org Paul, On 03/19/16 21:38, Paul Walmsley wrote: > On Fri, 18 Mar 2016, Peter Ujfalusi wrote: >=20 >> Hi, >> >> Chanes since v1: >> - removed the ASoC patch as Mark has applied it already >> - Added my signed-off to the hwmod patch >> - New patch to handle the case when the sidetone hwmod has been remo= ved for >> legacy boot. >> >> The series addresses a long standing issue with McBSP2/3 regarding t= o hwmod >> setup. When booting with DT a warning is printed that mcbsp2/3 is us= ing two >> hwmod. >> The root of the issue is the way how the hwmod data was constructed = in the first >> place for OMAP3 McBSP2/3. >> After re-reading the TRM it is clear that the sidetone should not ha= ve it's >> own hwmod data as it is not a separate IP, it is part of the McBSP m= odule. It >> can not affect PRCM either since it's SYSCONFIG register's AUTOIDLE = bit is only >> sets the autoidle from the internal McBSP_iclk clock to the sidetone= block of >> the same McBSP. >=20 > NAK, at least without further discussion - see my comments on the v1 = 0/3=20 > introduction. Yes, I could have sent the first series as RFC, but I believe(d) that t= his is the correct way to fix the McBSP sidetone integration. --=20 P=E9ter -- To unsubscribe from this list: send the line "unsubscribe devicetree" i= n the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html From mboxrd@z Thu Jan 1 00:00:00 1970 From: peter.ujfalusi@ti.com (Peter Ujfalusi) Date: Mon, 21 Mar 2016 10:57:56 +0200 Subject: [PATCH v2 0/3] ARM: OMAP3: Fix McBSP2/3 hwmod setup for sidetone In-Reply-To: References: <1458311007-19168-1-git-send-email-peter.ujfalusi@ti.com> Message-ID: <56EFB794.5010505@ti.com> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org Paul, On 03/19/16 21:38, Paul Walmsley wrote: > On Fri, 18 Mar 2016, Peter Ujfalusi wrote: > >> Hi, >> >> Chanes since v1: >> - removed the ASoC patch as Mark has applied it already >> - Added my signed-off to the hwmod patch >> - New patch to handle the case when the sidetone hwmod has been removed for >> legacy boot. >> >> The series addresses a long standing issue with McBSP2/3 regarding to hwmod >> setup. When booting with DT a warning is printed that mcbsp2/3 is using two >> hwmod. >> The root of the issue is the way how the hwmod data was constructed in the first >> place for OMAP3 McBSP2/3. >> After re-reading the TRM it is clear that the sidetone should not have it's >> own hwmod data as it is not a separate IP, it is part of the McBSP module. It >> can not affect PRCM either since it's SYSCONFIG register's AUTOIDLE bit is only >> sets the autoidle from the internal McBSP_iclk clock to the sidetone block of >> the same McBSP. > > NAK, at least without further discussion - see my comments on the v1 0/3 > introduction. Yes, I could have sent the first series as RFC, but I believe(d) that this is the correct way to fix the McBSP sidetone integration. -- P?ter From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753691AbcCUI6v (ORCPT ); Mon, 21 Mar 2016 04:58:51 -0400 Received: from bear.ext.ti.com ([192.94.94.41]:52835 "EHLO bear.ext.ti.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751819AbcCUI6e (ORCPT ); Mon, 21 Mar 2016 04:58:34 -0400 Subject: Re: [PATCH v2 0/3] ARM: OMAP3: Fix McBSP2/3 hwmod setup for sidetone To: Paul Walmsley References: <1458311007-19168-1-git-send-email-peter.ujfalusi@ti.com> CC: , , , , , , From: Peter Ujfalusi Message-ID: <56EFB794.5010505@ti.com> Date: Mon, 21 Mar 2016 10:57:56 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Paul, On 03/19/16 21:38, Paul Walmsley wrote: > On Fri, 18 Mar 2016, Peter Ujfalusi wrote: > >> Hi, >> >> Chanes since v1: >> - removed the ASoC patch as Mark has applied it already >> - Added my signed-off to the hwmod patch >> - New patch to handle the case when the sidetone hwmod has been removed for >> legacy boot. >> >> The series addresses a long standing issue with McBSP2/3 regarding to hwmod >> setup. When booting with DT a warning is printed that mcbsp2/3 is using two >> hwmod. >> The root of the issue is the way how the hwmod data was constructed in the first >> place for OMAP3 McBSP2/3. >> After re-reading the TRM it is clear that the sidetone should not have it's >> own hwmod data as it is not a separate IP, it is part of the McBSP module. It >> can not affect PRCM either since it's SYSCONFIG register's AUTOIDLE bit is only >> sets the autoidle from the internal McBSP_iclk clock to the sidetone block of >> the same McBSP. > > NAK, at least without further discussion - see my comments on the v1 0/3 > introduction. Yes, I could have sent the first series as RFC, but I believe(d) that this is the correct way to fix the McBSP sidetone integration. -- Péter