From patchwork Mon Aug 8 15:25:49 2011 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: holt@sgi.com X-Patchwork-Id: 108978 X-Patchwork-Delegate: davem@davemloft.net Return-Path: X-Original-To: patchwork-incoming@ozlabs.org Delivered-To: patchwork-incoming@ozlabs.org Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by ozlabs.org (Postfix) with ESMTP id 7339BB6F70 for ; Tue, 9 Aug 2011 01:25:56 +1000 (EST) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751144Ab1HHPZu (ORCPT ); Mon, 8 Aug 2011 11:25:50 -0400 Received: from relay2.sgi.com ([192.48.179.30]:43967 "EHLO relay.sgi.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1750973Ab1HHPZu (ORCPT ); Mon, 8 Aug 2011 11:25:50 -0400 Received: from estes.americas.sgi.com (estes.americas.sgi.com [128.162.236.10]) by relay2.corp.sgi.com (Postfix) with ESMTP id 87D9230406A; Mon, 8 Aug 2011 08:25:49 -0700 (PDT) Received: from lnx-holt.americas.sgi.com (lnx-holt.americas.sgi.com [128.162.233.109]) by estes.americas.sgi.com (Postfix) with ESMTP id 7A35D70006F0; Mon, 8 Aug 2011 10:25:49 -0500 (CDT) Received: from holt by lnx-holt.americas.sgi.com with local (Exim 4.71) (envelope-from ) id 1QqRi9-0007NZ-EG; Mon, 08 Aug 2011 10:25:49 -0500 Date: Mon, 8 Aug 2011 10:25:49 -0500 From: Robin Holt To: Wolfgang Grandegger Cc: Robin Holt , socketcan-core@lists.berlios.de, U Bhaskar-B22300 , Marc Kleine-Budde , netdev@vger.kernel.org Subject: Re: [RFC 5/5] [powerpc] Implement a p1010rdb clock source. Message-ID: <20110808152549.GB4926@sgi.com> References: <20110808113136.GS4926@sgi.com> <4E3FDFC9.7080508@grandegger.com> <20110808135630.GU4926@sgi.com> <4E3FEFBB.9050103@grandegger.com> <20110808142153.GW4926@sgi.com> <4E3FF4B8.2010603@grandegger.com> <20110808144424.GY4926@sgi.com> <4E3FF9EA.6030601@grandegger.com> <20110808150925.GA4926@sgi.com> <4E3FFE61.4090109@grandegger.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <4E3FFE61.4090109@grandegger.com> User-Agent: Mutt/1.5.20 (2009-06-14) Sender: netdev-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org On Mon, Aug 08, 2011 at 05:18:57PM +0200, Wolfgang Grandegger wrote: > On 08/08/2011 05:09 PM, Robin Holt wrote: > > On Mon, Aug 08, 2011 at 04:59:54PM +0200, Wolfgang Grandegger wrote: > >> On 08/08/2011 04:44 PM, Robin Holt wrote: > >>> On Mon, Aug 08, 2011 at 04:37:44PM +0200, Wolfgang Grandegger wrote: > >>>> On 08/08/2011 04:21 PM, Robin Holt wrote: > >>>>> On Mon, Aug 08, 2011 at 04:16:27PM +0200, Wolfgang Grandegger wrote: > >>>>>> On 08/08/2011 03:56 PM, Robin Holt wrote: > >>>>>>>> commit 65bb8b060a873fa4f5188f2951081f6011259614 > >>>>>>>> Author: Bhaskar Upadhaya > >>>>>>>> Date: Fri Mar 4 20:27:58 2011 +0530 > >>>>>>> > >>>>>>> On a side note, that commit fixes up "fsl,flexcan-v1.0" > >>>>>>> ... > >>>>>>> + do_fixup_by_compat_u32(blob, "fsl,flexcan-v1.0", > >>>>>>> + "clock_freq", gd->bus_clk, 1); > >>>>>>> > >>>>>>> Should I go back to flexcan-v1.0 in my patches? > >>>>>> > >>>>>> Well, no. Let's wait. I don't think we need it. Also, it sets > >>>>>> "clock_freq" while > >>>>>> > >>>>>> http://lxr.linux.no/#linux+v3.0.1/Documentation/devicetree/bindings/net/can/fsl-flexcan.txt > >>>>>> > >>>>>> documents "clock-frequencies"... :-(. > >>>>> > >>>>> You answered a different question that I was asking. I was asking if > >>>>> I should change fsl,flexcan back to fsl,flexcan-v1.0 as documented on > >>>>> line 5. The clock_freq looks like a uboot change will need to be made > >>>>> as well. > >>>> > >>>> Well, I wrote above: "Well, no. Let's wait. I don't think we need it." > >>>> > >>>> For the P1010 we can sinmply derive the clock frequency from > >>>> "fsl_get_sys_freq()", which is fine for the time being. No extra > >>>> properties, etc. The clk implemetation might go into > >>>> > >>>> http://lxr.linux.no/#linux+v3.0.1/arch/powerpc/platforms/85xx/clock.c > >>>> > >>>> or > >>>> > >>>> http://lxr.linux.no/#linux+v3.0.1/arch/powerpc/sysdev/fsl_soc.c > >>>> > >>>> And may depend on HAVE_CAN_FLEXCAN > >>>> > >>>> BTW, I have not found HAVE_CAN_FLEXCAN in your patch. What kernel are > >>>> you using? > >>> > >>> I am starting with the v3.0 kernel, apply one patch from the freescale BSP > >>> we receive under NDA which introduces the P1010RDB board into the QorIQ > >>> platform, and then work from there for the flexcan stuff. That patch > >>> introduces the HAVE_CAN_FLEXCAN. I do not like how freescale structured > >>> that Kconfig bit, so I have tweaked it to be selected automatically > >>> when P1010RDB, NET, and CAN are selected. That allows the CAN_FLEXCAN > >>> selection to determine is we are going to build the flexcan.c file. > >> > >> ARM boards select HAVE_CAN_FLEXCAN and I do not see a good reason why > >> we should do it differently for PowerPC. > >> > >> For mainline inclusion, you should provide your patches against the > >> David Millers "net-next-2.6" tree, which already seems to have support > >> for the P1010RDB: > >> > >> config P1010_RDB > >> bool "Freescale P1010RDB" > >> select DEFAULT_UIMAGE > >> help > >> This option enables support for the MPC85xx RDB (P1010 RDB) board > >> > >> P1010RDB contains P1010Si, which provides CPU performance up to 800 > >> MHz and 1600 DMIPS, additional functionality and faster interfaces > >> (DDR3/3L, SATA II, and PCI Express). > >> > >> > >>> Our contact with Freescale would prefer that I not post that patch until > >>> we get the OK from freescale to do so since we received it under NDA. > >> > >> I don't think we currently need it. I prefer dropping and cleaning up > >> the device tree stuff as it is not needed for the P1010 anyway. If a > >> new processor shows up with enhanced capabilities requiring > >> configuration via device tree, we or somebody else can provide a patch. > >> Marc, what do you think? > > > > I will rebase shortly and provide a newer set of patches. > > > > I do think powerpc does need the device tree support. That is how the flexcan_probe > > is getting called. How would you suggest I do it otherwise? > > Why do you think that? In patch 3/5 in this series (attached below), I made a change in how device discovery works. Without that of_match stuff, the flexcan driver was never getting its flexcan_probe function called. As soon as I added that, it worked. Looking at the driver_register path, this appeared to be the "correct" way to implement the device discovery. Did I miss something? Thanks, Robin The OpenFirmware devices are not matched without specifying an of_match array. Introduce that array as that is used for matching on the Freescale P1010 processor. Signed-off-by: Robin Holt To: Marc Kleine-Budde To: Wolfgang Grandegger To: U Bhaskar-B22300 Cc: socketcan-core@lists.berlios.de Cc: netdev@vger.kernel.org --- I kept the of_match for "fsl,flexcan-v1.0" for the time being. I will happily drop it for final submission once I have a boot loader worked up that matches on either string. --- drivers/net/can/flexcan.c | 16 +++++++++++++++- 1 files changed, 15 insertions(+), 1 deletions(-) diff --git a/drivers/net/can/flexcan.c b/drivers/net/can/flexcan.c index ecdd4e6..d4ac81b 100644 --- a/drivers/net/can/flexcan.c +++ b/drivers/net/can/flexcan.c @@ -1028,8 +1028,22 @@ static int __devexit flexcan_remove(struct platform_device *pdev) return 0; } +static struct of_device_id flexcan_of_match[] = { + { + .compatible = "fsl,flexcan-v1.0", + }, + { + .compatible = "fsl,flexcan", + }, + {}, +}; + static struct platform_driver flexcan_driver = { - .driver.name = DRV_NAME, + .driver = { + .name = DRV_NAME, + .owner = THIS_MODULE, + .of_match_table = flexcan_of_match, + }, .probe = flexcan_probe, .remove = __devexit_p(flexcan_remove), };