Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755064AbbESIe4 (ORCPT ); Tue, 19 May 2015 04:34:56 -0400 Received: from mail1.bemta3.messagelabs.com ([195.245.230.167]:42510 "EHLO mail1.bemta3.messagelabs.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753121AbbESIev convert rfc822-to-8bit (ORCPT ); Tue, 19 May 2015 04:34:51 -0400 X-Env-Sender: stwiss.opensource@diasemi.com X-Msg-Ref: server-7.tower-38.messagelabs.com!1432024486!25630981!1 X-Originating-IP: [94.185.165.51] X-StarScan-Received: X-StarScan-Version: 6.13.15; banners=-,-,- X-VirusChecked: Checked From: "Opensource [Steve Twiss]" To: Alexandre Belloni CC: LINUXKERNEL , Lee Jones , Samuel Ortiz , "Alessandro Zummo" , DEVICETREE , "David Dajun Chen" , Dmitry Torokhov , Ian Campbell , Kumar Gala , LINUXINPUT , LINUXWATCHDOG , Liam Girdwood , Mark Brown , Mark Rutland , Pawel Moll , RTCLINUX , Rob Herring , "Support Opensource" , Wim Van Sebroeck Subject: RE: [rtc-linux] [PATCH V2 1/4] mfd: da9062: DA9062 MFD core driver Thread-Topic: [rtc-linux] [PATCH V2 1/4] mfd: da9062: DA9062 MFD core driver Thread-Index: AQHQjmZ+03XfnOdY0EeISKdOkxXc7Z1+PfwAgAOvGiA= Date: Tue, 19 May 2015 08:34:45 +0000 Message-ID: <6ED8E3B22081A4459DAC7699F3695FB7014B22B961@SW-EX-MBX02.diasemi.com> References: <20150516085328.GI3338@piout.net> In-Reply-To: <20150516085328.GI3338@piout.net> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.20.26.77] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 8BIT MIME-Version: 1.0 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 3294 Lines: 90 On 16 May 2015 09:53 Alexandre Belloni wrote: Hi Alexandre, > On 14/05/2015 at 17:43:52 +0100, S Twiss wrote : [...] > > + { > > + .name = "da9062-watchdog", > > + .num_resources = ARRAY_SIZE(da9062_wdt_resources), > > + .resources = da9062_wdt_resources, > > + .of_compatible = "dlg,da9062-wdt", > > + }, > > + { > > + .name = "da9062-onkey", > > + .num_resources = ARRAY_SIZE(da9062_onkey_resources), > > + .resources = da9062_onkey_resources, > > + .of_compatible = "dlg,da9062-onkey", > > + }, > > + { > > + .name = "da9062-thermal", > > + .num_resources = ARRAY_SIZE(da9062_thermal_resources), > > + .resources = da9062_thermal_resources, > > + .of_compatible = "dlg,da9062-thermal", > > + }, > > + { > > + .name = "da9062-rtc", > > + .num_resources = ARRAY_SIZE(da9062_rtc_resources), > > + .resources = da9062_rtc_resources, > > + .of_compatible = "dlg,da9062-rtc", > > Did you try to use "da9063-rtc"? The register set seems to be exactly > the same. Unfortunately, the datasheet are not available on the diasemi > website... I will remove the DA9062 OnKey and RTC parts with a view to putting them back when I do the work for the DA9063 alterations. > Also, the .of_compatibles are not necessary because you don't add any of > bindings to the underlying drivers. The match happens on .name. > > > diff --git a/include/linux/mfd/da9062/registers.h > b/include/linux/mfd/da9062/registers.h > > new file mode 100644 > > index 0000000..d07c2bc > > --- /dev/null > > +++ b/include/linux/mfd/da9062/registers.h > > Comparing that file with da9063/registers.h, It really seems that > DA062AA, DA9063AD and DA9063BB are register compatible, apart from a > few > differences in the regulator and the gpio count. > > Also, at least the watchdog and rtc driver are duplicating their da9063 > counterpart. I'm not trying to annoy you, I just want you to understand > that the less code is duplicated, the easiest it will be to maintain > later. This has come up a lot lately. https://lkml.org/lkml/2015/4/24/304 https://lkml.org/lkml/2015/5/13/383 https://lkml.org/lkml/2015/5/6/505 https://lkml.org/lkml/2015/5/18/511 The short answer is that the DA9062 and DA9063 chips are not identical. Although their numbers are sequential and there are functional similarities for some of the components, this is not the norm for the two chips. In some cases re-using driver components from DA9063 is a good way forward, but making all components part of a monolithic driver would make both DA9062 and DA9063 over complicated and unmaintainable -- in my opinion. However it's not just my opinion we have to consider here I think. The RTC and OnKey in this case can be done fairly easily I think -- there can be some re-use in those components -- although there are fairly important RTC differences between the DA9063 AD and DA9063 BB silicon revisions (in the form of a new register, different functionality in the alarm and a register shift). So even that is not a straight-forward "swap" to run DA9062. Regards, Steve -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/