From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932118AbbKBPhg (ORCPT ); Mon, 2 Nov 2015 10:37:36 -0500 Received: from mga14.intel.com ([192.55.52.115]:20510 "EHLO mga14.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753027AbbKBPha (ORCPT ); Mon, 2 Nov 2015 10:37:30 -0500 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.20,234,1444719600"; d="scan'208";a="809743993" Date: Mon, 2 Nov 2015 21:10:57 +0530 From: Vinod Koul To: Peter Ujfalusi , Olof Johansson Cc: Sekhar Nori , "linux-arm-kernel@lists.infradead.org" , "linux-kernel@vger.kernel.org" , linux-omap , "dmaengine@vger.kernel.org" , "devicetree@vger.kernel.org" , Tony Lindgren , Robert Schwebel , "arm@kernel.org" , "Kristo, Tero" Subject: Re: [PATCH v2 13/14] ARM: DTS: am33xx: Use the new DT bindings for the eDMA3 Message-ID: <20151102154057.GQ21326@localhost> References: <1444979892-31626-1-git-send-email-peter.ujfalusi@ti.com> <1444979892-31626-14-git-send-email-peter.ujfalusi@ti.com> <20151102100405.GJ21326@localhost> <5637534D.2020304@ti.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5637534D.2020304@ti.com> User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Nov 02, 2015 at 02:13:01PM +0200, Peter Ujfalusi wrote: > Vinod, > > On 11/02/2015 12:04 PM, Vinod Koul wrote: > > On Mon, Nov 02, 2015 at 01:21:19AM -0800, Olof Johansson wrote: > >> Hi, > >> > >> 1) This seems to have broken BBB in -next for me, bisected down to this patch. > >> > >> For bootlog: > >> http://arm-soc.lixom.net/bootlogs/next/next-20151102/bbb-arm-omap2plus_defconfig.html > >> > >> 2) Please avoid merging DT/platform code in your driver tree, Vinod, > >> at least without an ack from the platform maintainer. It can be a a > >> huge mess if they end up causing conflicts, so we always ask to merge > >> the DT changes through the platform maintainer (Tony in this case) by > >> default. > > > > I did warn when applying that I am doing so without ACK on ARM code, noone > > said a thing! > > > > I knew Tony was following the work by Peter so assumed he must have been okay > > with it otherwise would have spoken for ~couple of weeks these were in > > review > > > > Anyway now that we have a regression, I can revert this patch if that fixes, > > please confirm, but might break edma... peter? > > Can you revert or drop the last two DTS patches? > > I think I will try a different route to get the split of the tpcc and tptc. > Without the DT patches the driver will fall back to the legacy mode so things > will work in a same way they did before. > Or I can send a followup patch for edma.c, with that there is no need to add > the HWMOD_INIT_NO_IDLE to hwmod and power management looks better. > Basically I'm registering a 'dummy' driver for the edma3-tptc so omap hwmod > code will not shut it down but we will keep the possibility to manage the > power state still. Okay I have reverted the two and applied the edma patch sent, can you please verify topic/edma_fix before I merge it and send my PULL request. Would appreciate any tested-by Thanks -- ~Vinod From mboxrd@z Thu Jan 1 00:00:00 1970 From: Vinod Koul Subject: Re: [PATCH v2 13/14] ARM: DTS: am33xx: Use the new DT bindings for the eDMA3 Date: Mon, 2 Nov 2015 21:10:57 +0530 Message-ID: <20151102154057.GQ21326@localhost> References: <1444979892-31626-1-git-send-email-peter.ujfalusi@ti.com> <1444979892-31626-14-git-send-email-peter.ujfalusi@ti.com> <20151102100405.GJ21326@localhost> <5637534D.2020304@ti.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Content-Disposition: inline In-Reply-To: <5637534D.2020304-l0cyMroinI0@public.gmane.org> Sender: devicetree-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org To: Peter Ujfalusi , Olof Johansson Cc: Sekhar Nori , "linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org" , "linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" , linux-omap , "dmaengine-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" , "devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" , Tony Lindgren , Robert Schwebel , "arm-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org" , "Kristo, Tero" List-Id: devicetree@vger.kernel.org On Mon, Nov 02, 2015 at 02:13:01PM +0200, Peter Ujfalusi wrote: > Vinod, > > On 11/02/2015 12:04 PM, Vinod Koul wrote: > > On Mon, Nov 02, 2015 at 01:21:19AM -0800, Olof Johansson wrote: > >> Hi, > >> > >> 1) This seems to have broken BBB in -next for me, bisected down to this patch. > >> > >> For bootlog: > >> http://arm-soc.lixom.net/bootlogs/next/next-20151102/bbb-arm-omap2plus_defconfig.html > >> > >> 2) Please avoid merging DT/platform code in your driver tree, Vinod, > >> at least without an ack from the platform maintainer. It can be a a > >> huge mess if they end up causing conflicts, so we always ask to merge > >> the DT changes through the platform maintainer (Tony in this case) by > >> default. > > > > I did warn when applying that I am doing so without ACK on ARM code, noone > > said a thing! > > > > I knew Tony was following the work by Peter so assumed he must have been okay > > with it otherwise would have spoken for ~couple of weeks these were in > > review > > > > Anyway now that we have a regression, I can revert this patch if that fixes, > > please confirm, but might break edma... peter? > > Can you revert or drop the last two DTS patches? > > I think I will try a different route to get the split of the tpcc and tptc. > Without the DT patches the driver will fall back to the legacy mode so things > will work in a same way they did before. > Or I can send a followup patch for edma.c, with that there is no need to add > the HWMOD_INIT_NO_IDLE to hwmod and power management looks better. > Basically I'm registering a 'dummy' driver for the edma3-tptc so omap hwmod > code will not shut it down but we will keep the possibility to manage the > power state still. Okay I have reverted the two and applied the edma patch sent, can you please verify topic/edma_fix before I merge it and send my PULL request. Would appreciate any tested-by Thanks -- ~Vinod -- To unsubscribe from this list: send the line "unsubscribe devicetree" in 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: vinod.koul@intel.com (Vinod Koul) Date: Mon, 2 Nov 2015 21:10:57 +0530 Subject: [PATCH v2 13/14] ARM: DTS: am33xx: Use the new DT bindings for the eDMA3 In-Reply-To: <5637534D.2020304@ti.com> References: <1444979892-31626-1-git-send-email-peter.ujfalusi@ti.com> <1444979892-31626-14-git-send-email-peter.ujfalusi@ti.com> <20151102100405.GJ21326@localhost> <5637534D.2020304@ti.com> Message-ID: <20151102154057.GQ21326@localhost> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org On Mon, Nov 02, 2015 at 02:13:01PM +0200, Peter Ujfalusi wrote: > Vinod, > > On 11/02/2015 12:04 PM, Vinod Koul wrote: > > On Mon, Nov 02, 2015 at 01:21:19AM -0800, Olof Johansson wrote: > >> Hi, > >> > >> 1) This seems to have broken BBB in -next for me, bisected down to this patch. > >> > >> For bootlog: > >> http://arm-soc.lixom.net/bootlogs/next/next-20151102/bbb-arm-omap2plus_defconfig.html > >> > >> 2) Please avoid merging DT/platform code in your driver tree, Vinod, > >> at least without an ack from the platform maintainer. It can be a a > >> huge mess if they end up causing conflicts, so we always ask to merge > >> the DT changes through the platform maintainer (Tony in this case) by > >> default. > > > > I did warn when applying that I am doing so without ACK on ARM code, noone > > said a thing! > > > > I knew Tony was following the work by Peter so assumed he must have been okay > > with it otherwise would have spoken for ~couple of weeks these were in > > review > > > > Anyway now that we have a regression, I can revert this patch if that fixes, > > please confirm, but might break edma... peter? > > Can you revert or drop the last two DTS patches? > > I think I will try a different route to get the split of the tpcc and tptc. > Without the DT patches the driver will fall back to the legacy mode so things > will work in a same way they did before. > Or I can send a followup patch for edma.c, with that there is no need to add > the HWMOD_INIT_NO_IDLE to hwmod and power management looks better. > Basically I'm registering a 'dummy' driver for the edma3-tptc so omap hwmod > code will not shut it down but we will keep the possibility to manage the > power state still. Okay I have reverted the two and applied the edma patch sent, can you please verify topic/edma_fix before I merge it and send my PULL request. Would appreciate any tested-by Thanks -- ~Vinod