Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752016Ab2HHFTu (ORCPT ); Wed, 8 Aug 2012 01:19:50 -0400 Received: from bear.ext.ti.com ([192.94.94.41]:43928 "EHLO bear.ext.ti.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751573Ab2HHFT2 convert rfc822-to-8bit (ORCPT ); Wed, 8 Aug 2012 01:19:28 -0400 From: "AnilKumar, Chimata" To: Daniel Mack CC: "devicetree-discuss@lists.ozlabs.org" , "eric.piel@tremplin-utc.net" , "linux-kernel@vger.kernel.org" , "rob.herring@calxeda.com" Subject: RE: [PATCH v3 1/2] lis3: add generic DT matching code Thread-Topic: [PATCH v3 1/2] lis3: add generic DT matching code Thread-Index: AQHNcyYHigTOH3VPQ0CGb64rDYCsY5dMmlKwgAG9zICAAQhKIA== Date: Wed, 8 Aug 2012 05:19:15 +0000 Message-ID: <331ABD5ECB02734CA317220B2BBEABC13EA0E257@DBDE01.ent.ti.com> References: <1343633775-6268-1-git-send-email-zonque@gmail.com> <501E9CE2.20500@gmail.com> <331ABD5ECB02734CA317220B2BBEABC13EA0B8A5@DBDE01.ent.ti.com> <5021631D.1030505@gmail.com> In-Reply-To: <5021631D.1030505@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.24.170.142] 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: 7515 Lines: 197 Hi Mack, No attachments please. On Wed, Aug 08, 2012 at 00:19:01, Daniel Mack wrote: > Hi, > > thanks for your review. > > On 06.08.2012 12:45, AnilKumar, Chimata wrote: > > On Sun, Aug 05, 2012 at 21:48:42, Daniel Mack wrote: > >> On 30.07.2012 09:36, Daniel Mack wrote: > >>> This patch adds logic to parse lis3 properties from a device tree node > >>> and store them in a freshly allocated lis3lv02d_platform_data. > >>> > >>> Note that the actual match tables are left out here. This part should > >>> happen in the drivers that bind to the individual busses (SPI/I2C/PCI). > >>> > >>> Also adds some DT bindinds documentation. > >>> > >>> Signed-off-by: Daniel Mack > >>> --- > >>> Changes from v2: > >>> - kzalloc braino > >>> > >>> Changes from v1: > >>> - some typos in properties fixed > >>> > >>> > >>> Documentation/devicetree/bindings/misc/lis302.txt | 74 ++++++++++++ > >>> drivers/misc/lis3lv02d/lis3lv02d.c | 137 ++++++++++++++++++++++ > >>> drivers/misc/lis3lv02d/lis3lv02d.h | 4 + > >>> 3 files changed, 215 insertions(+) > >>> create mode 100644 Documentation/devicetree/bindings/misc/lis302.txt > >>> > >>> diff --git a/Documentation/devicetree/bindings/misc/lis302.txt b/Documentation/devicetree/bindings/misc/lis302.txt > >>> new file mode 100644 > >>> index 0000000..66230fd > >>> --- /dev/null > >>> +++ b/Documentation/devicetree/bindings/misc/lis302.txt > >>> @@ -0,0 +1,74 @@ > >>> +LIS302 accelerometer devicetree bindings > >>> + > >>> +This device is matched via its bus drivers, and has a number of properties > >>> +that apply in on the generic device (independent from the bus). > >>> + > >>> + > >>> +Required properties for the SPI bindings: > >>> + - compatible: should be set to "st,lis3lv02d_spi" > >>> + - reg: the chipselect index > >>> + - spi-max-frequency: maximal bus speed, should be set to 1000000 unless > >>> + constrained by external circuitry > >>> + - interrupts: the interrupt generated by the device > >>> + > >>> + > >>> +Optional properties for all bus drivers: > >>> + > >>> + - st,click-single-{x,y,z}: if present, tells the device to issue an > >>> + interrupt on single click events on the > >>> + x/y/z axis. > >>> + - st,click-double-{x,y,z}: if present, tells the device to issue an > >>> + interrupt on double click events on the > >>> + x/y/z axis. > >>> + - st,click-thresh-{x,y,z}: set the x/y/z axis threshold > >>> + - st,click-click-time-limit: click time limit, from 0 to 127.5msec > >>> + with step of 0.5 msec > >>> + - st,click-latency: click latency, from 0 to 255 msec with > >>> + step of 1 msec. > >>> + - st,click-window: click window, from 0 to 255 msec with > >>> + step of 1 msec. > >>> + - st,irq{1,2}-disable: disable IRQ 1/2 > >>> + - st,irq{1,2}-ff-wu-1: raise IRQ 1/2 on FF_WU_1 condition > >>> + - st,irq{1,2}-ff-wu-2: raise IRQ 1/2 on FF_WU_2 condition > >>> + - st,irq{1,2}-data-ready: raise IRQ 1/2 on data ready contition > >>> + - st,irq{1,2}-click: raise IRQ 1/2 on click condition > >>> + - st,irq-open-drain: consider IRQ lines open-drain > >>> + - st,irq-active-low: make IRQ lines active low > >>> + - st,wu-duration-1: duration register for Free-Fall/Wake-Up > >>> + interrupt 1 > >>> + - st,wu-duration-2: duration register for Free-Fall/Wake-Up > >>> + interrupt 2 > >>> + - st,wakeup-{x,y,z}-{lo,hi}: set wakeup condition on x/y/z axis for > >>> + upper/lower limit > >>> + - st,highpass-cutoff-hz=: 1, 2, 4 or 8 for 1Hz, 2Hz, 4Hz or 8Hz of > >>> + highpass cut-off frequency > >>> + - st,hipass{1,2}-disable: disable highpass 1/2. > >>> + - st,default-rate=: set the default rate > >>> + - st,axis-{x,y,z}=: set the axis to map to the three coordinates > > > > Some more parameters missing, what about st_min_limits and st_max_limits > > required for selftest. > > Right. Added them now. > > >>> + > >>> + > >>> +Example for a SPI device node: > >>> + > >>> + lis302@0 { > >>> + compatible = "st,lis302dl-spi"; > >>> + reg = <0>; > >>> + spi-max-frequency = <1000000>; > >>> + interrupt-parent = <&gpio>; > >>> + interrupts = <104 0>; > >>> + > >>> + st,click-single-x; > >>> + st,click-single-y; > >>> + st,click-single-z; > >>> + st,click-thresh-x = <10>; > >>> + st,click-thresh-y = <10>; > >>> + st,click-thresh-z = <10>; > >>> + st,irq1-click; > >>> + st,irq2-click; > >>> + st,wakeup-x-lo; > >>> + st,wakeup-x-hi; > >>> + st,wakeup-y-lo; > >>> + st,wakeup-y-hi; > >>> + st,wakeup-z-lo; > >>> + st,wakeup-z-hi; > >>> + }; > > > > Why can't we add these flags in driver itself like below? > > Is these parameters varies from SoC to SoC or accelerometer > > - to - accelerometer? > > I don't understand, sorry. The point here is that the driver that is > probed for device initialization are the PCI/I2C/SPI drivers. The Look at the below example it has different drivers (SPI, I2C). Compatible name changes form acc-acc so that we can use different parameters corresponding to accelerometer, if it is acce specific. Like .compatible = "st,lis302dl-spi", .compatible = "st,lis331dlh-i2c", .compatible = "st,xx-spi", .compatible = "st,xx-i2c", If we do like this we can reduce lot of DT reads in driver. > generic part is not something the device tree knows about. > > Hence I put the generic parsing of common DT bindings to the generic > part of the driver, and made the SPI driver just pass through the > of_node pointer. > > > #ifdef CONFIG_OF > > static struct lis3lv02d_platform_data lis302dl_spi_pdata = { > > .click_flags = LIS3_CLICK_SINGLE_X | > > LIS3_CLICK_SINGLE_Y | > > LIS3_CLICK_SINGLE_Z, > > .irq_cfg = LIS3_IRQ1_CLICK | LIS3_IRQ2_CLICK, > > .wakeup_flags = LIS3_WAKEUP_X_LO | LIS3_WAKEUP_X_HI | > > LIS3_WAKEUP_Y_LO | LIS3_WAKEUP_Y_HI | > > LIS3_WAKEUP_Z_LO | LIS3_WAKEUP_Z_HI, > > }; > > > > static struct lis3lv02d_platform_data lis331dlh_i2c_pdata = { > > .click_flags = LIS3_CLICK_SINGLE_X | > > LIS3_CLICK_SINGLE_Y | > > LIS3_CLICK_SINGLE_Z, > > .irq_cfg = LIS3_IRQ1_CLICK | LIS3_IRQ2_CLICK, > > .wakeup_flags = LIS3_WAKEUP_X_LO | LIS3_WAKEUP_X_HI | > > LIS3_WAKEUP_Y_LO | LIS3_WAKEUP_Y_HI | > > LIS3_WAKEUP_Z_LO | LIS3_WAKEUP_Z_HI, > > }; > > > > static const struct of_device_id lis3_of_match[] = { > > { > > .compatible = "st,lis302dl-spi", > > .data = &lis302dl_spi_pdata, > > }, > > { > > .compatible = "st,lis331dlh-i2c", > > .data = &lis331dlh_i2c_pdata, > > }, > > { }, > > }; > > MODULE_DEVICE_TABLE(of, lis3_of_match); > > #endif > > > > Ignore if parameters between SoC - SoC are different. In > > probe we can add these flags to pdata. > > No. We want to expose all hardware features to DT so users can configure > the device at wish. We can't ignore that SoCs want different device configs. Is it require is my question, how many SoCs take these different parameters from platform data. Regards AnilKumar -- 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/