From mboxrd@z Thu Jan 1 00:00:00 1970 From: Tony Lindgren Subject: Re: [PATCH] ARM: OMAP2+: Fix populating the hwmod data from device tree Date: Thu, 5 Dec 2013 16:25:48 -0800 Message-ID: <20131206002547.GK26766@atomide.com> References: <20131120025620.GF10317@atomide.com> <20131120181255.GG10317@atomide.com> <20131120192209.GI10317@atomide.com> <20131121000533.GJ10317@atomide.com> <20131121014555.GL10317@atomide.com> <20131121204814.GC10023@atomide.com> <20131205172909.GB26766@atomide.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Received: from mho-03-ewr.mailhop.org ([204.13.248.66]:49921 "EHLO mho-01-ewr.mailhop.org" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1757063Ab3LFAZx (ORCPT ); Thu, 5 Dec 2013 19:25:53 -0500 Content-Disposition: inline In-Reply-To: Sender: linux-omap-owner@vger.kernel.org List-Id: linux-omap@vger.kernel.org To: Paul Walmsley Cc: linux-arm-kernel@lists.infradead.org, linux-omap@vger.kernel.org, =?utf-8?Q?Beno=C3=AEt?= Cousson * Paul Walmsley [131205 16:09]: > On Thu, 5 Dec 2013, Tony Lindgren wrote: > > > * Tony Lindgren [131121 12:49]: > > > * Tony Lindgren [131120 17:46]: > > > > * Tony Lindgren [131120 16:06]: > > > > > > > > > > They at least had interrupts listed looking at commit 3b9b10. Probably > > > > > the thing to do for now is to revert those changes, and see if we can > > > > > just remove the L3 entries from the .dtsi files. > > > > > > > > Actually the patch I posted should be able to handle also the > > > > ti,hwmods = "l3_main_1", "l3_main_2", "l3_main_3" property in omap4.dtsi, > > > > but we're not currently parsing that as we only look at the children > > > > and not the properties of the OCP bus. Should be fixable, will take a look > > > > tomorrow if this approach makes sense to you. > > > > > > OK this one seems to do the right thing for me. > > > > No comments? I'll queue the patch below to the fixes, please yell > > if you see any issues with that. > > Looks reasonable to me based on a quick glance: > > Acked-by: Paul Walmsley > > Have not tested it though. OK thanks for looking. I've used it with my mach-omap2 DT patches for past few weeks on various boards without issues. > I like the warning message for the bad data. :) Tony From mboxrd@z Thu Jan 1 00:00:00 1970 From: tony@atomide.com (Tony Lindgren) Date: Thu, 5 Dec 2013 16:25:48 -0800 Subject: [PATCH] ARM: OMAP2+: Fix populating the hwmod data from device tree In-Reply-To: References: <20131120025620.GF10317@atomide.com> <20131120181255.GG10317@atomide.com> <20131120192209.GI10317@atomide.com> <20131121000533.GJ10317@atomide.com> <20131121014555.GL10317@atomide.com> <20131121204814.GC10023@atomide.com> <20131205172909.GB26766@atomide.com> Message-ID: <20131206002547.GK26766@atomide.com> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org * Paul Walmsley [131205 16:09]: > On Thu, 5 Dec 2013, Tony Lindgren wrote: > > > * Tony Lindgren [131121 12:49]: > > > * Tony Lindgren [131120 17:46]: > > > > * Tony Lindgren [131120 16:06]: > > > > > > > > > > They at least had interrupts listed looking at commit 3b9b10. Probably > > > > > the thing to do for now is to revert those changes, and see if we can > > > > > just remove the L3 entries from the .dtsi files. > > > > > > > > Actually the patch I posted should be able to handle also the > > > > ti,hwmods = "l3_main_1", "l3_main_2", "l3_main_3" property in omap4.dtsi, > > > > but we're not currently parsing that as we only look at the children > > > > and not the properties of the OCP bus. Should be fixable, will take a look > > > > tomorrow if this approach makes sense to you. > > > > > > OK this one seems to do the right thing for me. > > > > No comments? I'll queue the patch below to the fixes, please yell > > if you see any issues with that. > > Looks reasonable to me based on a quick glance: > > Acked-by: Paul Walmsley > > Have not tested it though. OK thanks for looking. I've used it with my mach-omap2 DT patches for past few weeks on various boards without issues. > I like the warning message for the bad data. :) Tony