RE: [PATCH 13/14] ARM: AM33XX: hwmod data: irq, dma and addr info clean up

2013-06-12 Thread Hiremath, Vaibhav

 -Original Message-
 From: Vutla, Lokesh
 Sent: Tuesday, June 11, 2013 9:45 AM
 To: Kevin Hilman
 Cc: Paul Walmsley; Shilimkar, Santosh; t...@atomide.com; linux-arm-
 ker...@lists.infradead.org; linux-omap@vger.kernel.org; Hiremath,
 Vaibhav; R, Sricharan; Nayak, Rajendra
 Subject: Re: [PATCH 13/14] ARM: AM33XX: hwmod data: irq, dma and addr
 info clean up
 
 Hi Kevin,
 On Monday 10 June 2013 10:33 PM, Kevin Hilman wrote:
  Hi Lokesh,
 
  Lokesh Vutla lokeshvu...@ti.com writes:
 
  Hi Kevin,
 
  On Friday 07 June 2013 03:57 AM, Kevin Hilman wrote:
  Paul Walmsley p...@pwsan.com writes:
 
  On Wed, 29 May 2013, Santosh Shilimkar wrote:
 
  From: Vaibhav Hiremath hvaib...@ti.com
 
  AM33XX only supports DT boot mode and with addition of
  extracting module resources like, irq, dma and address space
  from DT block, so now we can remove duplicate information from
  hwmod data file.
 
  OK, guess I'll take your word for it that it all works.  The
  BeagleBone-white with appended DTB hasn't booted here since v3.7.
  And the BeagleBone-black with discrete DTB doesn't boot at all
 with
  current mainline, only with the TI vendor kernel  DTB...
 
  Anyone care to shed light on what's missing for BeagleBone boot
 with
  mainline currently?
  I have tested BeagleBone boot with today's mainline bootloader and
  kernel. It boots perfectly fine.
 
  Can you post git trees + branch names (and/or commit IDs) and also
  kernel config please?
 Following are the details:
 U-Boot:
 url:  git://git.denx.de/u-boot.git
 branch :  master
 config:   am335x_evm
 Top commit:   842033e pci: introduce CONFIG_PCI_INDIRECT_BRIDGE
 option
 
 Kernel:
 url:
   git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-
 2.6.git
 branch:   master
 config:   omap2plus_defocnfig
 dtb file: am335x-bone.dtb
 Top commit:   317ddd2 Linux 3.10-rc5 (On top of this I have a local
 patch for appending dtb)
 You can find the logs here: http://pastebin.com/vcBr0UhM
 

Paul/Kevin/Santosh,

AM335x is booting up from Mainline, starting from v3.7, that’s where HWMOD data 
got merged to
Mainline.

We have discussed on this in the past as well, let me explain the issue here in 
detail
again for everybody -

In case of Am335x we have only two possible options, as AM335x only boots up
With DTB (Tested in BBB) -

1. Mainline u-boot + mainline Kernel:
=

1.a. Appended DTB method


Here you __must__ enabled below config options in order to get kernel booting,

CONFIG_ARM_APPENDED_DTB=y
CONFIG_ARM_ATAG_DTB_COMPAT=y
CONFIG_ARM_ATAG_DTB_COMPAT_CMDLINE_FROM_BOOTLOADER=y

And, I have used below command to append DTB to kernel image

# cat arch/arm/boot/zImage arch/arm/boot/dts/am335x-bone.dtb  zImage-append  
mkimage -A arm -O linux -T kernel -C none -a 0x80008000 -e 0x80008000 -n 
Linux -d zImage-append uImage-append


I have attached complete log here with this mail for reference
http://pastebin.com/82duFh78


1.b. Discrete DTB and uImage method:


Here you don’t need to enable any extra config options. Plain 
omap2plus_defconfig
Should work without any issues.

I have attached complete log here with this mail for reference
http://pastebin.com/Nqr0PiwW


2. Older U-Boot (without DTB) + Mainline Kernel:


This is same as #OPTION-1.a above.


Thanks,
Vaibhav
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


RE: [PATCH 13/14] ARM: AM33XX: hwmod data: irq, dma and addr info clean up

2013-06-12 Thread Hiremath, Vaibhav

 -Original Message-
 From: Kevin Hilman [mailto:khil...@linaro.org]
 Sent: Friday, June 07, 2013 3:57 AM
 To: Paul Walmsley
 Cc: Shilimkar, Santosh; t...@atomide.com; linux-arm-
 ker...@lists.infradead.org; linux-omap@vger.kernel.org; Hiremath,
 Vaibhav; R, Sricharan
 Subject: Re: [PATCH 13/14] ARM: AM33XX: hwmod data: irq, dma and addr
 info clean up
 
 Paul Walmsley p...@pwsan.com writes:
 
  On Wed, 29 May 2013, Santosh Shilimkar wrote:
 
  From: Vaibhav Hiremath hvaib...@ti.com
 
  AM33XX only supports DT boot mode and with addition of
  extracting module resources like, irq, dma and address space
  from DT block, so now we can remove duplicate information from
  hwmod data file.
 
  OK, guess I'll take your word for it that it all works.  The
  BeagleBone-white with appended DTB hasn't booted here since v3.7.
  And the BeagleBone-black with discrete DTB doesn't boot at all with
  current mainline, only with the TI vendor kernel  DTB...
 
 Anyone care to shed light on what's missing for BeagleBone boot with
 mainline currently?
 
 I've also not been able to boot a mainline kernel on the BeagleBone for
 some time.
 

Sorry for delayed response, as I was on vacation for almost for a week.

I have just responded to this thread on complete analysis of the issue.

http://www.mail-archive.com/linux-omap@vger.kernel.org/msg90309.html

Thanks,
Vaibhav
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH] omap2 dss: omap_display_init: Dont allow more than the maximum number of displays.

2013-06-12 Thread Tomi Valkeinen
Hi,

On 10/06/13 10:57, Andreas Naumann wrote:
 Currently the maximum number of display is hardcoded in the array 
 omapfb2_device. Made the number a #define and check it in init routine.
 
 Signed-off-by: Andreas Naumann anaum...@ultratronik.de
 ---
 Our board supports a lot of panels and we could probably solve this more 
 effectively, but arrays shouldnt silently overflow when using more than 10 
 displays. Created the patch on 3.1 and tested it there. This one is rebased 
 on todays linux-omap.git
  arch/arm/mach-omap2/display.c   |  5 +
  drivers/video/omap2/omapfb/omapfb.h | 10 +-
  include/video/omapdss.h |  2 ++
  3 files changed, 12 insertions(+), 5 deletions(-)

This is an omapfb change, so it should only change omapfb files, not
omapdss.

 Tomi




signature.asc
Description: OpenPGP digital signature


RE: [PATCH 13/14] ARM: AM33XX: hwmod data: irq, dma and addr info clean up

2013-06-12 Thread Hiremath, Vaibhav

 -Original Message-
 From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
 ow...@vger.kernel.org] On Behalf Of Hiremath, Vaibhav
 Sent: Wednesday, June 12, 2013 11:34 AM
 To: Kevin Hilman; Paul Walmsley
 Cc: Shilimkar, Santosh; t...@atomide.com; linux-arm-
 ker...@lists.infradead.org; linux-omap@vger.kernel.org; R, Sricharan
 Subject: RE: [PATCH 13/14] ARM: AM33XX: hwmod data: irq, dma and addr
 info clean up
 
 
  -Original Message-
  From: Kevin Hilman [mailto:khil...@linaro.org]
  Sent: Friday, June 07, 2013 3:57 AM
  To: Paul Walmsley
  Cc: Shilimkar, Santosh; t...@atomide.com; linux-arm-
  ker...@lists.infradead.org; linux-omap@vger.kernel.org; Hiremath,
  Vaibhav; R, Sricharan
  Subject: Re: [PATCH 13/14] ARM: AM33XX: hwmod data: irq, dma and addr
  info clean up
 
  Paul Walmsley p...@pwsan.com writes:
 
   On Wed, 29 May 2013, Santosh Shilimkar wrote:
  
   From: Vaibhav Hiremath hvaib...@ti.com
  
   AM33XX only supports DT boot mode and with addition of
   extracting module resources like, irq, dma and address space
   from DT block, so now we can remove duplicate information from
   hwmod data file.
  
   OK, guess I'll take your word for it that it all works.  The
   BeagleBone-white with appended DTB hasn't booted here since v3.7.
   And the BeagleBone-black with discrete DTB doesn't boot at all with
   current mainline, only with the TI vendor kernel  DTB...
 
  Anyone care to shed light on what's missing for BeagleBone boot with
  mainline currently?
 
  I've also not been able to boot a mainline kernel on the BeagleBone
 for
  some time.
 
 
 Sorry for delayed response, as I was on vacation for almost for a week.
 
 I have just responded to this thread on complete analysis of the issue.
 
 http://www.mail-archive.com/linux-omap@vger.kernel.org/msg90309.html
 

I have also pushed the branch to github,

https://github.com/hvaibhav/am335x-linux.git  linus-master

OR

https://github.com/hvaibhav/am335x-linux/tree/linus-master


NOTE: Tested on BeagleBone-Black platform.

Thanks,
Vaibhav
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH] ARM: dts: Protect pinctrl headers against multiple inclusions

2013-06-12 Thread Florian Vaussard

Hello Grant,

On 06/11/2013 11:57 PM, Grant Likely wrote:

On Tue, 11 Jun 2013 16:50:50 +0200, Florian Vaussard florian.vauss...@epfl.ch 
wrote:

Pinctrl headers were not protected with #ifndef.

Signed-off-by: Florian Vaussard florian.vauss...@epfl.ch


Obviously this needs to go in via whatever tree added the modified
header files.



I authored these files, sorry for this stupid omission. Benoit, can you
take this patch?

Regards,

Florian


Acked-by: Grant Likely grant.lik...@secretlab.ca


---
  include/dt-bindings/pinctrl/am33xx.h |5 +
  include/dt-bindings/pinctrl/omap.h   |5 +
  2 files changed, 10 insertions(+), 0 deletions(-)

diff --git a/include/dt-bindings/pinctrl/am33xx.h 
b/include/dt-bindings/pinctrl/am33xx.h
index a3fddd4..469e032 100644
--- a/include/dt-bindings/pinctrl/am33xx.h
+++ b/include/dt-bindings/pinctrl/am33xx.h
@@ -2,6 +2,9 @@
   * This header provides constants specific to AM33XX pinctrl bindings.
   */

+#ifndef _DT_BINDINGS_PINCTRL_AM33XX_H
+#define _DT_BINDINGS_PINCTRL_AM33XX_H
+
  #include include/dt-bindings/pinctrl/omap.h

  /* am33xx specific mux bit defines */
@@ -35,3 +38,5 @@
  #undef PIN_OFF_INPUT_PULLDOWN
  #undef PIN_OFF_WAKEUPENABLE

+#endif
+
diff --git a/include/dt-bindings/pinctrl/omap.h 
b/include/dt-bindings/pinctrl/omap.h
index 370df3f..edbd250 100644
--- a/include/dt-bindings/pinctrl/omap.h
+++ b/include/dt-bindings/pinctrl/omap.h
@@ -5,6 +5,9 @@
   * Copyright (C) 2009-2010 Texas Instruments
   */

+#ifndef _DT_BINDINGS_PINCTRL_OMAP_H
+#define _DT_BINDINGS_PINCTRL_OMAP_H
+
  /* 34xx mux mode options for each pin. See TRM for options */
  #define MUX_MODE0 0
  #define MUX_MODE1 1
@@ -48,3 +51,5 @@
  #define PIN_OFF_INPUT_PULLDOWN(OFF_EN | OFF_PULL_EN)
  #define PIN_OFF_WAKEUPENABLE  WAKEUP_EN

+#endif
+
--
1.7.5.4

___
devicetree-discuss mailing list
devicetree-disc...@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss




--
Florian Vaussard
EPFL - STI - IMT - LSRO1
MEB330 - Station 9
1015 Lausanne / Switzerland

tel: +41 21 693 78 39
fax: +41 21 693 78 07
http://lsro.epfl.ch
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH] extcon: Add an API to get extcon device from dt node

2013-06-12 Thread Kishon Vijay Abraham I

Hi Chanwoo Choi,

On Wednesday 12 June 2013 07:09 AM, Chanwoo Choi wrote:

From: Kishon Vijay Abraham I kis...@ti.com

Added an API of_extcon_get_extcon_dev() to be used by drivers to get
extcon device in the case of dt boot (this can be used instead of
extcon_get_extcon_dev()).

Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
Signed-off-by: Chanwoo Choi cw00.c...@samsung.com
Signed-off-by: Myungjoo Ham myungjoo@samsung.com
---
  drivers/extcon/Makefile  |  3 +++
  drivers/extcon/of-extcon.c   | 56 
  include/linux/extcon/of-extcon.h | 30 +
  3 files changed, 89 insertions(+)
  create mode 100644 drivers/extcon/of-extcon.c
  create mode 100644 include/linux/extcon/of-extcon.h

diff --git a/drivers/extcon/Makefile b/drivers/extcon/Makefile
index 540e2c3..39cdf95 100644
--- a/drivers/extcon/Makefile
+++ b/drivers/extcon/Makefile
@@ -2,9 +2,12 @@
  # Makefile for external connector class (extcon) devices
  #

+obj-$(CONFIG_OF)   += of-extcon.o
+
  obj-$(CONFIG_EXTCON)  += extcon-class.o
  obj-$(CONFIG_EXTCON_GPIO) += extcon-gpio.o
  obj-$(CONFIG_EXTCON_ADC_JACK) += extcon-adc-jack.o
+
  obj-$(CONFIG_EXTCON_MAX77693) += extcon-max77693.o
  obj-$(CONFIG_EXTCON_MAX8997)  += extcon-max8997.o
  obj-$(CONFIG_EXTCON_ARIZONA)  += extcon-arizona.o
diff --git a/drivers/extcon/of-extcon.c b/drivers/extcon/of-extcon.c
new file mode 100644
index 000..29f82b4
--- /dev/null
+++ b/drivers/extcon/of-extcon.c
@@ -0,0 +1,56 @@
+/*
+ * OF helpers for External connector (extcon) framework
+ *
+ * Copyright (C) 2013 Texas Instruments, Inc.
+ * Kishon Vijay Abraham I kis...@ti.com
+ *
+ * Copyright (C) 2013 Samsung Electronics
+ * Chanwoo Choi cw00.c...@samsung.com
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ */
+
+#include linux/module.h
+#include linux/slab.h
+#include linux/extcon.h
+#include linux/of.h
+#include linux/of_platform.h
+#include linux/extcon/of-extcon.h
+
+struct extcon_dev *of_extcon_get_extcon_dev(struct device *dev, int index)
+{
+   struct device_node *node;
+   struct extcon_dev *edev;
+   struct platform_device *extcon_parent_dev;
+
+   if (!dev-of_node) {
+   dev_dbg(dev, device does not have a device node entry\n);
+   return ERR_PTR(-EINVAL);
+   }
+
+   node = of_parse_phandle(dev-of_node, extcon, index);
+   if (!node) {
+   dev_dbg(dev, failed to get phandle in %s node\n,
+   dev-of_node-full_name);
+   return ERR_PTR(-ENODEV);
+   }
+
+   extcon_parent_dev = of_find_device_by_node(node);
+   if (!extcon_parent_dev) {
+   dev_dbg(dev, unable to find device by node\n);
+   return ERR_PTR(-EPROBE_DEFER);
+   }
+
+   edev = extcon_get_extcon_dev(dev_name(extcon_parent_dev-dev));


In order to get this working, I needed a small fix in extcon_dev_register

-   dev_set_name(edev-dev, edev-name ? edev-name : dev_name(dev));
+   edev-name = edev-name ? edev-name : dev_name(dev);
+   dev_set_name(edev-dev, edev-name);

Also using extcon_get_extcon_dev here requires the extcon driver not to 
set edev.name since we use *dev_name* here. Hence I recommend using my 
initial class iterative approach. Anyway its your call. Let me know if 
have to float a new version of the patch (either the iterative approach 
or having the fix I mentioned in extcon_dev_register).


Thanks
Kishon
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


RE: [PATCH v3] ARM: dts: OMAP5: Add palmas MFD node and regulator nodes

2013-06-12 Thread J, KEERTHY


 -Original Message-
 From: Stephen Warren [mailto:swar...@wwwdotorg.org]
 Sent: Tuesday, June 11, 2013 9:32 PM
 To: J, KEERTHY
 Cc: Cousson, Benoit; devicetree-disc...@lists.ozlabs.org; linux-
 o...@vger.kernel.org; linux-ker...@vger.kernel.org;
 ldewan...@nvidia.com; grant.lik...@secretlab.ca; swar...@nvidia.com;
 sa...@linux.intel.com; g...@slimlogic.co.uk; lee.jo...@linaro.org
 Subject: Re: [PATCH v3] ARM: dts: OMAP5: Add palmas MFD node and
 regulator nodes
 
 On 06/10/2013 11:30 PM, J Keerthy wrote:
  This patch adds Palmas MFD node and the regulator nodes for OMAP5.
 
  The node definitions are based on: https://lkml.org/lkml/2013/6/6/25
 
  Boot tested on omap5-uevm board.
 
  diff --git a/arch/arm/boot/dts/omap5-uevm.dts
  b/arch/arm/boot/dts/omap5-uevm.dts
 
  +   palmas: palmas@48 {
  +   reg = 0x48;
  +   interrupts = GIC_SPI 7 IRQ_TYPE_LEVEL_HIGH; /* IRQ_SYS_1N
 */
  +   interrupt-parent = gic;
  +   };
  +};
  +
  +palmas {
  +   compatible = ti,palmas;
  +   interrupt-controller;
  +   #interrupt-cells = 2;
 
 I don't really see the point of splitting the node into two parts if
 it's all going into a single file. It made sense if part of the node
 came from a common .dtsi file, but not so much when it doesn't.

The intent was to reduce indentation and to declare its sub-nodes outside
of i2c1. I will club it and resend.

Regards,
Keerthy
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH v4] ARM: dts: OMAP5: Add palmas MFD node and regulator nodes

2013-06-12 Thread J Keerthy
This patch adds Palmas MFD node and the regulator nodes for OMAP5.

The node definitions are based on: https://lkml.org/lkml/2013/6/6/25

Boot tested on omap5-uevm board.

Signed-off-by: Graeme Gregory g...@slimlogic.co.uk
Signed-off-by: J Keerthy j-keer...@ti.com

---
 arch/arm/boot/dts/omap5-uevm.dts |  167 ++
 1 files changed, 167 insertions(+), 0 deletions(-)

diff --git a/arch/arm/boot/dts/omap5-uevm.dts b/arch/arm/boot/dts/omap5-uevm.dts
index 927db1e..3d0b7b6 100644
--- a/arch/arm/boot/dts/omap5-uevm.dts
+++ b/arch/arm/boot/dts/omap5-uevm.dts
@@ -8,6 +8,8 @@
 /dts-v1/;
 
 #include omap5.dtsi
+#include dt-bindings/interrupt-controller/irq.h
+#include dt-bindings/interrupt-controller/arm-gic.h
 
 / {
model = TI OMAP5 uEVM board;
@@ -254,6 +256,171 @@
pinctrl-0 = i2c1_pins;
 
clock-frequency = 40;
+
+   palmas: palmas@48 {
+   reg = 0x48;
+   interrupts = GIC_SPI 7 IRQ_TYPE_LEVEL_HIGH; /* IRQ_SYS_1N */
+   interrupt-parent = gic;
+   compatible = ti,palmas;
+   interrupt-controller;
+   #interrupt-cells = 2;
+
+   palmas_pmic {
+   compatible = ti,palmas-pmic;
+   interrupt-parent = palmas;
+   interrupts = 14 IRQ_TYPE_NONE;
+   interrupt-name = short-irq;
+
+   ti,ldo6-vibrator;
+
+   regulators {
+   smps123_reg: smps123 {
+   regulator-name = smps123;
+   regulator-min-microvolt =  60;
+   regulator-max-microvolt = 150;
+   regulator-always-on;
+   regulator-boot-on;
+   };
+
+   smps45_reg: smps45 {
+   regulator-name = smps45;
+   regulator-min-microvolt =  60;
+   regulator-max-microvolt = 131;
+   regulator-always-on;
+   regulator-boot-on;
+   };
+
+   smps6_reg: smps6 {
+   regulator-name = smps6;
+   regulator-min-microvolt = 120;
+   regulator-max-microvolt = 120;
+   regulator-always-on;
+   regulator-boot-on;
+   };
+
+   smps7_reg: smps7 {
+   regulator-name = smps7;
+   regulator-min-microvolt = 180;
+   regulator-max-microvolt = 180;
+   regulator-always-on;
+   regulator-boot-on;
+   };
+
+   smps8_reg: smps8 {
+   regulator-name = smps8;
+   regulator-min-microvolt =  60;
+   regulator-max-microvolt = 131;
+   regulator-always-on;
+   regulator-boot-on;
+   };
+
+   smps9_reg: smps9 {
+   regulator-name = smps9;
+   regulator-min-microvolt = 210;
+   regulator-max-microvolt = 210;
+   regulator-always-on;
+   regulator-boot-on;
+   ti,smps-range = 0x80;
+   };
+
+   smps10_reg: smps10 {
+   regulator-name = smps10;
+   regulator-min-microvolt = 500;
+   regulator-max-microvolt = 500;
+   regulator-always-on;
+   regulator-boot-on;
+   };
+
+   ldo1_reg: ldo1 {
+   regulator-name = ldo1;
+   regulator-min-microvolt = 280;
+   regulator-max-microvolt = 280;
+   regulator-always-on;
+   regulator-boot-on;
+   };
+
+   ldo2_reg: ldo2 {
+

[PATCH v2 1/3] usb: dwc3: omap: Adding am437x specific register map changes

2013-06-12 Thread George Cherian
AM437x and OMAP5 dwc3 subsytem have different register map.
Major differences are as follows.

OMAP5 has one main interrupt and one misc interrupt
Aegis has four main interrupts and one misc interrupt.

Miscellanous Interrupt offsets are changed.
UTMI OTG Control and Status Registers offsets are changed.
DEBUG Configuration and Status Registers are changed.

The main intend of the patch is to re-use the same wrapper driver
for both OMAP5 and AM437x, by using the x_major in revision
register and adjusting the offsets.

This patch adds the register map offsets and adds offset variables
in struct dwc3_omap to cache the offsets

Signed-off-by: George Cherian george.cher...@ti.com
---
 drivers/usb/dwc3/dwc3-omap.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/drivers/usb/dwc3/dwc3-omap.c b/drivers/usb/dwc3/dwc3-omap.c
index 34638b9..a354b4c 100644
--- a/drivers/usb/dwc3/dwc3-omap.c
+++ b/drivers/usb/dwc3/dwc3-omap.c
@@ -122,6 +122,12 @@ struct dwc3_omap {
void __iomem*base;
 
u32 utmi_otg_status;
+   u32 utmi_otg_offset;
+   u32 irqmisc_offset;
+   u32 irq_eoi_offset;
+   u32 debug_offset;
+   u32 irq0_offset;
+   u32 revision;
 
u32 dma_status:1;
 };
-- 
1.8.1.4

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH v2 3/3] usb: dwc3: omap: Adds dwc3_omap_readl/writel wrappers

2013-06-12 Thread George Cherian
This patch adds wrappers to dwc3_omap_readl/writel calls to accomodate
both OMAP5 and AM437x reg maps (It uses the cached register offsets).
Also renames OMAP5 IRQ1 as IRQMISC and IRQ1 bits as IRQMISC bits.

Signed-off-by: George Cherian george.cher...@ti.com
---
 drivers/usb/dwc3/dwc3-omap.c | 173 +--
 1 file changed, 116 insertions(+), 57 deletions(-)

diff --git a/drivers/usb/dwc3/dwc3-omap.c b/drivers/usb/dwc3/dwc3-omap.c
index f204d18..4f565d7 100644
--- a/drivers/usb/dwc3/dwc3-omap.c
+++ b/drivers/usb/dwc3/dwc3-omap.c
@@ -67,10 +67,18 @@
 #define USBOTGSS_IRQENABLE_SET_0   0x002c
 #define USBOTGSS_IRQENABLE_CLR_0   0x0030
 #define USBOTGSS_IRQ0_OFFSET   0x0004
-#define USBOTGSS_IRQSTATUS_RAW_1   0x0034
-#define USBOTGSS_IRQSTATUS_1   0x0038
-#define USBOTGSS_IRQENABLE_SET_1   0x003c
-#define USBOTGSS_IRQENABLE_CLR_1   0x0040
+#define USBOTGSS_IRQSTATUS_RAW_1   0x0030
+#define USBOTGSS_IRQSTATUS_1   0x0034
+#define USBOTGSS_IRQENABLE_SET_1   0x0038
+#define USBOTGSS_IRQENABLE_CLR_1   0x003c
+#define USBOTGSS_IRQSTATUS_RAW_2   0x0040
+#define USBOTGSS_IRQSTATUS_2   0x0044
+#define USBOTGSS_IRQENABLE_SET_2   0x0048
+#define USBOTGSS_IRQENABLE_CLR_2   0x004c
+#define USBOTGSS_IRQSTATUS_RAW_3   0x0050
+#define USBOTGSS_IRQSTATUS_3   0x0054
+#define USBOTGSS_IRQENABLE_SET_3   0x0058
+#define USBOTGSS_IRQENABLE_CLR_3   0x005c
 #define USBOTGSS_IRQSTATUS_EOI_MISC0x0030
 #define USBOTGSS_IRQSTATUS_RAW_MISC0x0034
 #define USBOTGSS_IRQSTATUS_MISC0x0038
@@ -102,17 +110,17 @@
 /* IRQS0 BITS */
 #define USBOTGSS_IRQO_COREIRQ_ST   (1  0)
 
-/* IRQ1 BITS */
-#define USBOTGSS_IRQ1_DMADISABLECLR(1  17)
-#define USBOTGSS_IRQ1_OEVT (1  16)
-#define USBOTGSS_IRQ1_DRVVBUS_RISE (1  13)
-#define USBOTGSS_IRQ1_CHRGVBUS_RISE(1  12)
-#define USBOTGSS_IRQ1_DISCHRGVBUS_RISE (1  11)
-#define USBOTGSS_IRQ1_IDPULLUP_RISE(1  8)
-#define USBOTGSS_IRQ1_DRVVBUS_FALL (1  5)
-#define USBOTGSS_IRQ1_CHRGVBUS_FALL(1  4)
-#define USBOTGSS_IRQ1_DISCHRGVBUS_FALL (1  3)
-#define USBOTGSS_IRQ1_IDPULLUP_FALL(1  0)
+/* IRQMISC BITS */
+#define USBOTGSS_IRQMISC_DMADISABLECLR (1  17)
+#define USBOTGSS_IRQMISC_OEVT  (1  16)
+#define USBOTGSS_IRQMISC_DRVVBUS_RISE  (1  13)
+#define USBOTGSS_IRQMISC_CHRGVBUS_RISE (1  12)
+#define USBOTGSS_IRQMISC_DISCHRGVBUS_RISE  (1  11)
+#define USBOTGSS_IRQMISC_IDPULLUP_RISE (1  8)
+#define USBOTGSS_IRQMISC_DRVVBUS_FALL  (1  5)
+#define USBOTGSS_IRQMISC_CHRGVBUS_FALL (1  4)
+#define USBOTGSS_IRQMISC_DISCHRGVBUS_FALL  (1  3)
+#define USBOTGSS_IRQMISC_IDPULLUP_FALL (1  0)
 
 /* UTMI_OTG_CTRL REGISTER */
 #define USBOTGSS_UTMI_OTG_CTRL_DRVVBUS (1  5)
@@ -161,6 +169,58 @@ static inline void dwc3_omap_writel(void __iomem *base, 
u32 offset, u32 value)
writel(value, base + offset);
 }
 
+static u32 dwc3_omap_read_utmi_status(struct dwc3_omap *omap)
+{
+   return dwc3_omap_readl(omap-base, USBOTGSS_UTMI_OTG_STATUS +
+   omap-utmi_otg_offset);
+}
+
+static void dwc3_omap_write_utmi_status(struct dwc3_omap *omap, u32 value)
+{
+   dwc3_omap_writel(omap-base, USBOTGSS_UTMI_OTG_STATUS +
+   omap-utmi_otg_offset, value);
+
+}
+
+static u32 dwc3_omap_read_irq0_status(struct dwc3_omap *omap)
+{
+   return dwc3_omap_readl(omap-base, USBOTGSS_IRQSTATUS_0 -
+   omap-irq0_offset);
+}
+
+static void dwc3_omap_write_irq0_status(struct dwc3_omap *omap, u32 value)
+{
+   dwc3_omap_writel(omap-base, USBOTGSS_IRQSTATUS_0 -
+   omap-irq0_offset, value);
+
+}
+
+static u32 dwc3_omap_read_irqmisc_status(struct dwc3_omap *omap)
+{
+   return dwc3_omap_readl(omap-base, USBOTGSS_IRQSTATUS_MISC +
+   omap-irqmisc_offset);
+}
+
+static void dwc3_omap_write_irqmisc_status(struct dwc3_omap *omap, u32 value)
+{
+   dwc3_omap_writel(omap-base, USBOTGSS_IRQSTATUS_MISC +
+   omap-irqmisc_offset, value);
+
+}
+
+static void dwc3_omap_write_irqmisc_set(struct dwc3_omap *omap, u32 value)
+{
+   dwc3_omap_writel(omap-base, USBOTGSS_IRQENABLE_SET_MISC +
+   omap-irqmisc_offset, value);
+
+}
+
+static void dwc3_omap_write_irq0_set(struct dwc3_omap *omap, u32 value)
+{
+   dwc3_omap_writel(omap-base, USBOTGSS_IRQENABLE_SET_0 -
+   

[PATCH v2 0/3] Adding AM437x support to dwc3-omap glue

2013-06-12 Thread George Cherian
Initial patch set to add support for dwc3 in am437x platform.
This patch series addresses the regiter map differences between
OMAP5 and AM437x, to re-use the same driver.

AM437x and OMAP5 dwc3 subsytem have different register map.
Major differences are as follows.

OMAP5 has one main interrupt and one misc interrupt
Aegis has four main interrupts and one misc interrupt.

Miscellanous Interrupt offsets are changed.
UTMI OTG Control and Status Registers offsets are changed.
DEBUG Configuration and Status Registers are changed.

The main intend of the patch is to re-use the same wrapper driver
for both OMAP5 and AM437x, by using the x_major in revision
register and adjusting the offsets.

changes from v1:
- Added compatible for AM437X since x_major is same for OMAP5 and AM437x
- Added proper wrappers to dwc3_omap_readl/writel 


George Cherian (3):
  usb: dwc3: omap: Adding am437x specific register map changes
  usb: dwc3: omap: Intialize the register offset values for OMAP5 and
AM437x
  usb: dwc3: omap: Adds dwc3_omap_readl/writel wrappers

 drivers/usb/dwc3/dwc3-omap.c | 234 ---
 1 file changed, 178 insertions(+), 56 deletions(-)

-- 
1.8.1.4

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH v2 2/3] usb: dwc3: omap: Intialize the register offset values for OMAP5 and AM437x

2013-06-12 Thread George Cherian
This patch Initializes the register offset values depending
on the X_MAJOR of USBOTGSS_REVISION register. Also adds register
offset defines and new debug register defines.

X_MAJOR is 2 for both OMAP5 and AM437x. But both have different glue register
layout. Differentiate AM437x using dt compatible.
Register offsets are cached in dwc3_omap struct for reg reads and writes.

Signed-off-by: George Cherian george.cher...@ti.com
---
 drivers/usb/dwc3/dwc3-omap.c | 57 
 1 file changed, 57 insertions(+)

diff --git a/drivers/usb/dwc3/dwc3-omap.c b/drivers/usb/dwc3/dwc3-omap.c
index a354b4c..f204d18 100644
--- a/drivers/usb/dwc3/dwc3-omap.c
+++ b/drivers/usb/dwc3/dwc3-omap.c
@@ -61,21 +61,38 @@
 #define USBOTGSS_REVISION  0x
 #define USBOTGSS_SYSCONFIG 0x0010
 #define USBOTGSS_IRQ_EOI   0x0020
+#define USBOTGSS_EOI_OFFSET0x0008
 #define USBOTGSS_IRQSTATUS_RAW_0   0x0024
 #define USBOTGSS_IRQSTATUS_0   0x0028
 #define USBOTGSS_IRQENABLE_SET_0   0x002c
 #define USBOTGSS_IRQENABLE_CLR_0   0x0030
+#define USBOTGSS_IRQ0_OFFSET   0x0004
 #define USBOTGSS_IRQSTATUS_RAW_1   0x0034
 #define USBOTGSS_IRQSTATUS_1   0x0038
 #define USBOTGSS_IRQENABLE_SET_1   0x003c
 #define USBOTGSS_IRQENABLE_CLR_1   0x0040
+#define USBOTGSS_IRQSTATUS_EOI_MISC0x0030
+#define USBOTGSS_IRQSTATUS_RAW_MISC0x0034
+#define USBOTGSS_IRQSTATUS_MISC0x0038
+#define USBOTGSS_IRQENABLE_SET_MISC0x003c
+#define USBOTGSS_IRQENABLE_CLR_MISC0x0040
+#define USBOTGSS_IRQMISC_OFFSET0x03fc
 #define USBOTGSS_UTMI_OTG_CTRL 0x0080
 #define USBOTGSS_UTMI_OTG_STATUS   0x0084
+#define USBOTGSS_UTMI_OTG_OFFSET   0x0480
+#define USBOTGSS_TXFIFO_DEPTH  0x0508
+#define USBOTGSS_RXFIFO_DEPTH  0x050c
 #define USBOTGSS_MMRAM_OFFSET  0x0100
 #define USBOTGSS_FLADJ 0x0104
 #define USBOTGSS_DEBUG_CFG 0x0108
 #define USBOTGSS_DEBUG_DATA0x010c
+#define USBOTGSS_DEV_EBC_EN0x0110
+#define USBOTGSS_DEBUG_OFFSET  0x0600
 
+/* REVISION REGISTER */
+#define USBOTGSS_REVISION_XMAJOR(reg)  ((reg  8)  0x7)
+#define USBOTGSS_REVISION_XMAJOR1  1
+#define USBOTGSS_REVISION_XMAJOR2  2
 /* SYSCONFIG REGISTER */
 #define USBOTGSS_SYSCONFIG_DMADISABLE  (1  16)
 
@@ -300,6 +317,7 @@ static int dwc3_omap_probe(struct platform_device *pdev)
int irq;
 
int utmi_mode = 0;
+   int x_major;
 
u32 reg;
 
@@ -356,6 +374,42 @@ static int dwc3_omap_probe(struct platform_device *pdev)
return ret;
}
 
+   reg = dwc3_omap_readl(omap-base, USBOTGSS_REVISION);
+   omap-revision = reg;
+   x_major = USBOTGSS_REVISION_XMAJOR(reg);
+
+   /* Differentiate between OMAP5,AM437x and others*/
+   switch (x_major) {
+   case USBOTGSS_REVISION_XMAJOR1:
+   case USBOTGSS_REVISION_XMAJOR2:
+   omap-irq_eoi_offset = 0;
+   omap-irq0_offset = 0;
+   omap-irqmisc_offset = 0;
+   omap-utmi_otg_offset = 0;
+   omap-debug_offset = 0;
+   break;
+   default:
+   /* Default to the latest revision */
+   omap-irq_eoi_offset = USBOTGSS_EOI_OFFSET;
+   omap-irq0_offset = USBOTGSS_IRQ0_OFFSET;
+   omap-irqmisc_offset = USBOTGSS_IRQMISC_OFFSET;
+   omap-utmi_otg_offset = USBOTGSS_UTMI_OTG_OFFSET;
+   omap-debug_offset = USBOTGSS_DEBUG_OFFSET;
+   break;
+   }
+
+   /* For OMAP5(ES2.0) and AM437x x_major is 2 even though there are
+* changes in wrapper registers, Using dt compatible for aegis
+*/
+
+   if (of_device_is_compatible(node, ti,am437x-dwc3)) {
+   omap-irq_eoi_offset = USBOTGSS_EOI_OFFSET;
+   omap-irq0_offset = USBOTGSS_IRQ0_OFFSET;
+   omap-irqmisc_offset = USBOTGSS_IRQMISC_OFFSET;
+   omap-utmi_otg_offset = USBOTGSS_UTMI_OTG_OFFSET;
+   omap-debug_offset = USBOTGSS_DEBUG_OFFSET;
+   }
+
reg = dwc3_omap_readl(omap-base, USBOTGSS_UTMI_OTG_STATUS);
 
of_property_read_u32(node, utmi-mode, utmi_mode);
@@ -412,6 +466,9 @@ static const struct of_device_id of_dwc3_match[] = {
{
.compatible =   ti,dwc3
},
+   {
+   .compatible =   ti,am437x-dwc3
+   },
{ },
 };
 MODULE_DEVICE_TABLE(of, of_dwc3_match);
-- 
1.8.1.4

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the 

Re: [PATCH 3/5] gpio/omap: Add DT support to GPIO driver

2013-06-12 Thread Linus Walleij
On Tue, Jun 11, 2013 at 11:25 PM, Grant Likely
grant.lik...@secretlab.ca wrote:
 On Fri, 26 Apr 2013 16:31:24 -0500, Jon Hunter jon-hun...@ti.com wrote:

 On 04/26/2013 02:31 AM, Linus Walleij wrote:
  On Wed, Apr 17, 2013 at 2:41 AM, Javier Martinez Canillas
  martinez.jav...@gmail.com wrote:
 
  So:
 
  +static int omap_gpio_irq_domain_xlate(struct irq_domain *d,
  + struct device_node *ctrlr,
  + const u32 *intspec, unsigned int 
  intsize,
  + irq_hw_number_t *out_hwirq,
  + unsigned int *out_type)
  +{
  +   int ret;
  +   struct gpio_bank *bank = d-host_data;
  +   int gpio = bank-chip.base + intspec[0];
  +
  +   if (WARN_ON(intsize  2))
  +   return -EINVAL;
  +
  +   ret = gpio_request_one(gpio, GPIOF_IN, ctrlr-full_name);
  +   if (ret)
  +   return ret;
 
  So how to figure out if a device is already requesting this GPIO
  on some orthogonal axis?

 I really don't think that is necessary. Hopefully, my other email [1]
 elaborates on why. Let me know if this makes sense.

 I would agree here. If the irq specified happens to be a GPIO; then the
 onus is on the GPIO/IRQ controller driver to make sure that GPIO is
 actually set up to work as an IRQ.

Hm, re-reading this I guess the gpio_request_one() will block
others from using the pin for anything else.

Isn't that the answer to my actual question...?

It seems more like I was asking a pretty stupid question
actually.

Yours,
Linus Walleij
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[v4 0/3] suspend/resume support for OMAP nand driver

2013-06-12 Thread Pekon Gupta
This patch series adds low power transition support for OMAP NAND driver.
[Patch 1/3]: Adds pm_runtime calls to handle GPMC module probe and remove
[Patch 2/3]: Adds GPMC suspend/resume support.
[Patch 3/3]: Adds ELM suspend/resume support.

Tested on am335x-evm with NAND flash support, using following:
echo devices /sys/power/pm_test
echo mem /sys/power/state

echo core/sys/power/pm_test
echo mem /sys/power/state

Changes Since v3:
- CONFIG_PM - CONFIG_PM_SLEEP
- using struct dev_pm_ops via driver-pm, instead of struct platform_driver
- rebased to 3.10-rc5

Changes Since v2:
- Remove calll back of nand_suspend from omap2 nand driver, as the same call
  already done from suspend activity mtd class driver.

[1] http://comments.gmane.org/gmane.linux.ports.arm.omap/91405


avinash philip (3):
  arm: gpmc: Converts GPMC driver to pm_runtime capable
  arm: gpmc: Low power transition support
  mtd: devices: elm: Low power transition support

 arch/arm/mach-omap2/gpmc.c | 27 +--
 drivers/mtd/devices/elm.c  | 19 +++
 2 files changed, 44 insertions(+), 2 deletions(-)

-- 
1.8.1

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[v4 1/3] arm: gpmc: Converts GPMC driver to pm_runtime capable

2013-06-12 Thread Pekon Gupta
From: avinash philip avinashphi...@ti.com

Support for pm_runtime add to GPMC driver.

Signed-off-by: Philip Avinash avinashphi...@ti.com
Signed-off-by: Pekon Gupta pe...@ti.com
---
 arch/arm/mach-omap2/gpmc.c | 8 ++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/arch/arm/mach-omap2/gpmc.c b/arch/arm/mach-omap2/gpmc.c
index fb6f241..1380cee 100644
--- a/arch/arm/mach-omap2/gpmc.c
+++ b/arch/arm/mach-omap2/gpmc.c
@@ -30,6 +30,7 @@
 #include linux/of_mtd.h
 #include linux/of_device.h
 #include linux/mtd/nand.h
+#include linux/pm_runtime.h
 
 #include linux/platform_data/mtd-nand-omap2.h
 
@@ -1594,7 +1595,8 @@ static int gpmc_probe(struct platform_device *pdev)
return PTR_ERR(gpmc_l3_clk);
}
 
-   clk_prepare_enable(gpmc_l3_clk);
+   pm_runtime_enable(pdev-dev);
+   pm_runtime_get_sync(pdev-dev);
 
gpmc_dev = pdev-dev;
 
@@ -1634,7 +1636,7 @@ static int gpmc_probe(struct platform_device *pdev)
 
rc = gpmc_probe_dt(pdev);
if (rc  0) {
-   clk_disable_unprepare(gpmc_l3_clk);
+   pm_runtime_put_sync(pdev-dev);
clk_put(gpmc_l3_clk);
dev_err(gpmc_dev, failed to probe DT parameters\n);
return rc;
@@ -1647,6 +1649,8 @@ static int gpmc_remove(struct platform_device *pdev)
 {
gpmc_free_irq();
gpmc_mem_exit();
+   pm_runtime_put_sync(pdev-dev);
+   pm_runtime_disable(pdev-dev);
gpmc_dev = NULL;
return 0;
 }
-- 
1.8.1

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[v4 2/3] arm: gpmc: Low power transition support

2013-06-12 Thread Pekon Gupta
From: avinash philip avinashphi...@ti.com

With GPMC converted to platform driver recently, adds low power
transition support in driver itself.

Signed-off-by: Philip Avinash avinashphi...@ti.com
Signed-off-by: Pekon Gupta pe...@ti.com
---
 arch/arm/mach-omap2/gpmc.c | 19 +++
 1 file changed, 19 insertions(+)

diff --git a/arch/arm/mach-omap2/gpmc.c b/arch/arm/mach-omap2/gpmc.c
index 1380cee..b5c4752 100644
--- a/arch/arm/mach-omap2/gpmc.c
+++ b/arch/arm/mach-omap2/gpmc.c
@@ -1655,6 +1655,24 @@ static int gpmc_remove(struct platform_device *pdev)
return 0;
 }
 
+#ifdef CONFIG_PM_SLEEP
+static int gpmc_suspend(struct device *dev)
+{
+   omap3_gpmc_save_context();
+   pm_runtime_put_sync(dev);
+   return 0;
+}
+
+static int gpmc_resume(struct device *dev)
+{
+   pm_runtime_get_sync(dev);
+   omap3_gpmc_restore_context();
+   return 0;
+}
+#endif
+
+static SIMPLE_DEV_PM_OPS(gpmc_pm_ops, gpmc_suspend, gpmc_resume);
+
 static struct platform_driver gpmc_driver = {
.probe  = gpmc_probe,
.remove = gpmc_remove,
@@ -1662,6 +1680,7 @@ static struct platform_driver gpmc_driver = {
.name   = DEVICE_NAME,
.owner  = THIS_MODULE,
.of_match_table = of_match_ptr(gpmc_dt_ids),
+   .pm = gpmc_pm_ops,
},
 };
 
-- 
1.8.1

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[v4 3/3] mtd: devices: elm: Low power transition support

2013-06-12 Thread Pekon Gupta
From: avinash philip avinashphi...@ti.com

In low power modes of AM335X platforms, peripherals power is cut off.
This patch supports low power sleep transition support for ELM driver.

Signed-off-by: Philip Avinash avinashphi...@ti.com
Signed-off-by: Pekon Gupta pe...@ti.com
---
 drivers/mtd/devices/elm.c | 19 +++
 1 file changed, 19 insertions(+)

diff --git a/drivers/mtd/devices/elm.c b/drivers/mtd/devices/elm.c
index dccef9f..171efcd 100644
--- a/drivers/mtd/devices/elm.c
+++ b/drivers/mtd/devices/elm.c
@@ -20,6 +20,7 @@
 #include linux/interrupt.h
 #include linux/io.h
 #include linux/of.h
+#include linux/sched.h
 #include linux/pm_runtime.h
 #include linux/platform_data/elm.h
 
@@ -385,6 +386,23 @@ static int elm_remove(struct platform_device *pdev)
return 0;
 }
 
+static int elm_suspend(struct device *dev)
+{
+   pm_runtime_put_sync(dev);
+   return 0;
+}
+
+static int elm_resume(struct device *dev)
+{
+   struct elm_info *info = dev_get_drvdata(dev);
+
+   pm_runtime_get_sync(dev);
+   elm_config(dev, info-bch_type);
+   return 0;
+}
+
+static SIMPLE_DEV_PM_OPS(elm_pm_ops, elm_suspend, elm_resume);
+
 #ifdef CONFIG_OF
 static const struct of_device_id elm_of_match[] = {
{ .compatible = ti,am3352-elm },
@@ -398,6 +416,7 @@ static struct platform_driver elm_driver = {
.name   = elm,
.owner  = THIS_MODULE,
.of_match_table = of_match_ptr(elm_of_match),
+   .pm = elm_pm_ops,
},
.probe  = elm_probe,
.remove = elm_remove,
-- 
1.8.1

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH 0/3] ARM: OMAP: add corrected DSS regulator supplies

2013-06-12 Thread Tomi Valkeinen
On 31/05/13 10:37, Tomi Valkeinen wrote:
 Hi Tony,
 
 Here are a few patches adding corrected DSS regulator supplies. The current
 ones in the board files are not really correct, although the dss driver works
 ok with them.
 
 So these patches add new regulator supply entries. When these are merged, I'll
 change omapdss driver to use the new ones, instead of the old ones. After 
 that,
 we can remove the old ones from the board files.
 
 Note that these patches were also present in the big DSS series I sent
 yesterday. There's no reason for these patches to be there, so I'm sending 
 them
 separately, and will drop these from my DSS series.

Ping.

 Tomi




signature.asc
Description: OpenPGP digital signature


[PATCH v5] ARM: dts: OMAP5: Add Palmas MFD node and regulator nodes

2013-06-12 Thread J Keerthy
This patch adds Palmas MFD node and the regulator nodes for OMAP5.

The node definitions are based on: https://lkml.org/lkml/2013/6/6/25

Boot tested on omap5-uevm board.

Signed-off-by: Graeme Gregory g...@slimlogic.co.uk
Signed-off-by: J Keerthy j-keer...@ti.com
---
V5:
Corrected the IRQ_TYPE flag for OMAP5 board.

V4:
Removed splitting Palmas node.

V3:
Moved the entire Palmas device tree node to board file.

 arch/arm/boot/dts/omap5-uevm.dts |  167 ++
 1 files changed, 167 insertions(+), 0 deletions(-)

diff --git a/arch/arm/boot/dts/omap5-uevm.dts b/arch/arm/boot/dts/omap5-uevm.dts
index 927db1e..3d0b7b6 100644
--- a/arch/arm/boot/dts/omap5-uevm.dts
+++ b/arch/arm/boot/dts/omap5-uevm.dts
@@ -8,6 +8,8 @@
 /dts-v1/;
 
 #include omap5.dtsi
+#include dt-bindings/interrupt-controller/irq.h
+#include dt-bindings/interrupt-controller/arm-gic.h
 
 / {
model = TI OMAP5 uEVM board;
@@ -254,6 +256,171 @@
pinctrl-0 = i2c1_pins;
 
clock-frequency = 40;
+
+   palmas: palmas@48 {
+   reg = 0x48;
+   interrupts = GIC_SPI 7 IRQ_TYPE_NONE; /* IRQ_SYS_1N */
+   interrupt-parent = gic;
+   compatible = ti,palmas;
+   interrupt-controller;
+   #interrupt-cells = 2;
+
+   palmas_pmic {
+   compatible = ti,palmas-pmic;
+   interrupt-parent = palmas;
+   interrupts = 14 IRQ_TYPE_NONE;
+   interrupt-name = short-irq;
+
+   ti,ldo6-vibrator;
+
+   regulators {
+   smps123_reg: smps123 {
+   regulator-name = smps123;
+   regulator-min-microvolt =  60;
+   regulator-max-microvolt = 150;
+   regulator-always-on;
+   regulator-boot-on;
+   };
+
+   smps45_reg: smps45 {
+   regulator-name = smps45;
+   regulator-min-microvolt =  60;
+   regulator-max-microvolt = 131;
+   regulator-always-on;
+   regulator-boot-on;
+   };
+
+   smps6_reg: smps6 {
+   regulator-name = smps6;
+   regulator-min-microvolt = 120;
+   regulator-max-microvolt = 120;
+   regulator-always-on;
+   regulator-boot-on;
+   };
+
+   smps7_reg: smps7 {
+   regulator-name = smps7;
+   regulator-min-microvolt = 180;
+   regulator-max-microvolt = 180;
+   regulator-always-on;
+   regulator-boot-on;
+   };
+
+   smps8_reg: smps8 {
+   regulator-name = smps8;
+   regulator-min-microvolt =  60;
+   regulator-max-microvolt = 131;
+   regulator-always-on;
+   regulator-boot-on;
+   };
+
+   smps9_reg: smps9 {
+   regulator-name = smps9;
+   regulator-min-microvolt = 210;
+   regulator-max-microvolt = 210;
+   regulator-always-on;
+   regulator-boot-on;
+   ti,smps-range = 0x80;
+   };
+
+   smps10_reg: smps10 {
+   regulator-name = smps10;
+   regulator-min-microvolt = 500;
+   regulator-max-microvolt = 500;
+   regulator-always-on;
+   regulator-boot-on;
+   };
+
+   ldo1_reg: ldo1 {
+   regulator-name = ldo1;
+   regulator-min-microvolt = 280;
+   regulator-max-microvolt = 280;
+   regulator-always-on;
+ 

[PATCH v4 0/3] suspend/resume support for OMAP nand driver

2013-06-12 Thread Pekon Gupta
This patch series adds low power transition support for OMAP NAND driver.
[Patch 1/3]: Adds pm_runtime calls to handle GPMC module probe and remove
[Patch 2/3]: Adds GPMC suspend/resume support.
[Patch 3/3]: Adds ELM suspend/resume support.

Tested on am335x-evm with NAND flash support, using following:
echo devices /sys/power/pm_test
echo mem /sys/power/state

echo core/sys/power/pm_test
echo mem /sys/power/state

Changes Since v3:
- CONFIG_PM - CONFIG_PM_SLEEP
- using struct dev_pm_ops via driver-pm, instead of struct platform_driver
- rebased to 3.10-rc5

Changes Since v2:
- Remove calll back of nand_suspend from omap2 nand driver, as the same call
  already done from suspend activity mtd class driver.

[1] http://comments.gmane.org/gmane.linux.ports.arm.omap/91405


avinash philip (3):
  arm: gpmc: Converts GPMC driver to pm_runtime capable
  arm: gpmc: Low power transition support
  mtd: devices: elm: Low power transition support

 arch/arm/mach-omap2/gpmc.c | 27 +--
 drivers/mtd/devices/elm.c  | 19 +++
 2 files changed, 44 insertions(+), 2 deletions(-)

-- 
1.8.1

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH v4 3/3] mtd: devices: elm: Low power transition support

2013-06-12 Thread Pekon Gupta
From: avinash philip avinashphi...@ti.com

In low power modes of AM335X platforms, peripherals power is cut off.
This patch supports low power sleep transition support for ELM driver.

Signed-off-by: Philip Avinash avinashphi...@ti.com
Signed-off-by: Pekon Gupta pe...@ti.com
---
 drivers/mtd/devices/elm.c | 19 +++
 1 file changed, 19 insertions(+)

diff --git a/drivers/mtd/devices/elm.c b/drivers/mtd/devices/elm.c
index dccef9f..171efcd 100644
--- a/drivers/mtd/devices/elm.c
+++ b/drivers/mtd/devices/elm.c
@@ -20,6 +20,7 @@
 #include linux/interrupt.h
 #include linux/io.h
 #include linux/of.h
+#include linux/sched.h
 #include linux/pm_runtime.h
 #include linux/platform_data/elm.h
 
@@ -385,6 +386,23 @@ static int elm_remove(struct platform_device *pdev)
return 0;
 }
 
+static int elm_suspend(struct device *dev)
+{
+   pm_runtime_put_sync(dev);
+   return 0;
+}
+
+static int elm_resume(struct device *dev)
+{
+   struct elm_info *info = dev_get_drvdata(dev);
+
+   pm_runtime_get_sync(dev);
+   elm_config(dev, info-bch_type);
+   return 0;
+}
+
+static SIMPLE_DEV_PM_OPS(elm_pm_ops, elm_suspend, elm_resume);
+
 #ifdef CONFIG_OF
 static const struct of_device_id elm_of_match[] = {
{ .compatible = ti,am3352-elm },
@@ -398,6 +416,7 @@ static struct platform_driver elm_driver = {
.name   = elm,
.owner  = THIS_MODULE,
.of_match_table = of_match_ptr(elm_of_match),
+   .pm = elm_pm_ops,
},
.probe  = elm_probe,
.remove = elm_remove,
-- 
1.8.1

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH v4 1/3] arm: gpmc: Converts GPMC driver to pm_runtime capable

2013-06-12 Thread Pekon Gupta
From: avinash philip avinashphi...@ti.com

Support for pm_runtime add to GPMC driver.

Signed-off-by: Philip Avinash avinashphi...@ti.com
Signed-off-by: Pekon Gupta pe...@ti.com 
---
 arch/arm/mach-omap2/gpmc.c | 8 ++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/arch/arm/mach-omap2/gpmc.c b/arch/arm/mach-omap2/gpmc.c
index fb6f241..1380cee 100644
--- a/arch/arm/mach-omap2/gpmc.c
+++ b/arch/arm/mach-omap2/gpmc.c
@@ -30,6 +30,7 @@
 #include linux/of_mtd.h
 #include linux/of_device.h
 #include linux/mtd/nand.h
+#include linux/pm_runtime.h
 
 #include linux/platform_data/mtd-nand-omap2.h
 
@@ -1594,7 +1595,8 @@ static int gpmc_probe(struct platform_device *pdev)
return PTR_ERR(gpmc_l3_clk);
}
 
-   clk_prepare_enable(gpmc_l3_clk);
+   pm_runtime_enable(pdev-dev);
+   pm_runtime_get_sync(pdev-dev);
 
gpmc_dev = pdev-dev;
 
@@ -1634,7 +1636,7 @@ static int gpmc_probe(struct platform_device *pdev)
 
rc = gpmc_probe_dt(pdev);
if (rc  0) {
-   clk_disable_unprepare(gpmc_l3_clk);
+   pm_runtime_put_sync(pdev-dev);
clk_put(gpmc_l3_clk);
dev_err(gpmc_dev, failed to probe DT parameters\n);
return rc;
@@ -1647,6 +1649,8 @@ static int gpmc_remove(struct platform_device *pdev)
 {
gpmc_free_irq();
gpmc_mem_exit();
+   pm_runtime_put_sync(pdev-dev);
+   pm_runtime_disable(pdev-dev);
gpmc_dev = NULL;
return 0;
 }
-- 
1.8.1

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH v4 2/3] arm: gpmc: Low power transition support

2013-06-12 Thread Pekon Gupta
From: avinash philip avinashphi...@ti.com

With GPMC converted to platform driver recently, adds low power
transition support in driver itself.

Signed-off-by: Philip Avinash avinashphi...@ti.com
Signed-off-by: Pekon Gupta pe...@ti.com
---
 arch/arm/mach-omap2/gpmc.c | 19 +++
 1 file changed, 19 insertions(+)

diff --git a/arch/arm/mach-omap2/gpmc.c b/arch/arm/mach-omap2/gpmc.c
index 1380cee..b5c4752 100644
--- a/arch/arm/mach-omap2/gpmc.c
+++ b/arch/arm/mach-omap2/gpmc.c
@@ -1655,6 +1655,24 @@ static int gpmc_remove(struct platform_device *pdev)
return 0;
 }
 
+#ifdef CONFIG_PM_SLEEP
+static int gpmc_suspend(struct device *dev)
+{
+   omap3_gpmc_save_context();
+   pm_runtime_put_sync(dev);
+   return 0;
+}
+
+static int gpmc_resume(struct device *dev)
+{
+   pm_runtime_get_sync(dev);
+   omap3_gpmc_restore_context();
+   return 0;
+}
+#endif
+
+static SIMPLE_DEV_PM_OPS(gpmc_pm_ops, gpmc_suspend, gpmc_resume);
+
 static struct platform_driver gpmc_driver = {
.probe  = gpmc_probe,
.remove = gpmc_remove,
@@ -1662,6 +1680,7 @@ static struct platform_driver gpmc_driver = {
.name   = DEVICE_NAME,
.owner  = THIS_MODULE,
.of_match_table = of_match_ptr(gpmc_dt_ids),
+   .pm = gpmc_pm_ops,
},
 };
 
-- 
1.8.1

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH 1/3] ARM: dts: Add headers with constants for MTD partitions

2013-06-12 Thread Grant Likely
On Tue, 11 Jun 2013 16:48:56 +0200, Florian Vaussard florian.vauss...@epfl.ch 
wrote:
 These constants can be used to easily declare MTD partitions inside
 DTS.
 
 The constants MTDPART_OFS_* are purposely not included. Indeed,
 parse_ofpart_partitions() is expecting u64, but a DT cell is u32.
 Negative constants, as defined by MTDPART_OFS_*, would be wrongly

The DT binding uses the number of cells defined by #address-cells. It is
not fixed to a u32 or a u64

 interpreted by parse_ofpart_partitions(). Two cells should be
 used to correctly encode the negative constants, but this breaks
 current usage.

The binding doesn't even allow for shortcuts like MTDPART_SIZ_FULL. If a
partition fills the whole device, then the reg property should include
the actual size. If the code is allowing '0' to be used to mean
MTDPART_SIZ_FULL, then that is a bug that needs to be fixed.

Please drop the mtd/partitions.h hunk from this patch.

g.

 
 Signed-off-by: Florian Vaussard florian.vauss...@epfl.ch
 ---
  include/dt-bindings/mtd/partitions.h |   12 
  include/dt-bindings/sizes.h  |   52 
 ++
  2 files changed, 64 insertions(+), 0 deletions(-)
  create mode 100644 include/dt-bindings/mtd/partitions.h
  create mode 100644 include/dt-bindings/sizes.h
 
 diff --git a/include/dt-bindings/mtd/partitions.h 
 b/include/dt-bindings/mtd/partitions.h
 new file mode 100644
 index 000..7dfa676
 --- /dev/null
 +++ b/include/dt-bindings/mtd/partitions.h
 @@ -0,0 +1,12 @@
 +/*
 + * This header provides constants used with MTD partitions.
 + */
 +
 +#ifndef _DT_BINDINGS_MTD_PARTITIONS_H
 +#define _DT_BINDINGS_MTD_PARTITIONS_H
 +
 +/* Partition size */
 +#define MTDPART_SIZ_FULL 0
 +
 +#endif
 +
 diff --git a/include/dt-bindings/sizes.h b/include/dt-bindings/sizes.h
 new file mode 100644
 index 000..995f2de
 --- /dev/null
 +++ b/include/dt-bindings/sizes.h
 @@ -0,0 +1,52 @@
 +/*
 + * This header provides size constants.
 + *
 + * Original version:
 + *   include/linux/sizes.h
 + *
 + * This program is free software; you can redistribute it and/or modify
 + * it under the terms of the GNU General Public License version 2 as
 + * published by the Free Software Foundation.
 + */
 +
 +#ifndef _DT_BINDINGS_SIZES_H
 +#define _DT_BINDINGS_SIZES_H
 +
 +#define SZ_1 0x0001
 +#define SZ_2 0x0002
 +#define SZ_4 0x0004
 +#define SZ_8 0x0008
 +#define SZ_160x0010
 +#define SZ_320x0020
 +#define SZ_640x0040
 +#define SZ_128   0x0080
 +#define SZ_256   0x0100
 +#define SZ_512   0x0200
 +
 +#define SZ_1K0x0400
 +#define SZ_2K0x0800
 +#define SZ_4K0x1000
 +#define SZ_8K0x2000
 +#define SZ_16K   0x4000
 +#define SZ_32K   0x8000
 +#define SZ_64K   0x0001
 +#define SZ_128K  0x0002
 +#define SZ_256K  0x0004
 +#define SZ_512K  0x0008
 +
 +#define SZ_1M0x0010
 +#define SZ_2M0x0020
 +#define SZ_4M0x0040
 +#define SZ_8M0x0080
 +#define SZ_16M   0x0100
 +#define SZ_32M   0x0200
 +#define SZ_64M   0x0400
 +#define SZ_128M  0x0800
 +#define SZ_256M  0x1000
 +#define SZ_512M  0x2000
 +
 +#define SZ_1G0x4000
 +#define SZ_2G0x8000
 +
 +#endif
 +
 -- 
 1.7.5.4
 
 ___
 devicetree-discuss mailing list
 devicetree-disc...@lists.ozlabs.org
 https://lists.ozlabs.org/listinfo/devicetree-discuss

-- 
Grant Likely, B.Sc, P.Eng.
Secret Lab Technologies, Ltd.
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH 3/3] ARM: dts: OMAP3: Use MTD constants for OMAP3 boards

2013-06-12 Thread Grant Likely
On Tue, 11 Jun 2013 17:29:43 +0200, Javier Martinez Canillas 
javier.marti...@collabora.co.uk wrote:
 On 06/11/2013 04:48 PM, Florian Vaussard wrote:
  Use the MTD constants for NAND and OneNAND nodes used in OMAP3
  DTS.
  
  Signed-off-by: Florian Vaussard florian.vauss...@epfl.ch
  ---
   arch/arm/boot/dts/omap3-devkit8000.dts |   10 +-
   arch/arm/boot/dts/omap3-igep0020.dts   |   10 +-
   arch/arm/boot/dts/omap3-igep0030.dts   |   10 +-
   arch/arm/boot/dts/omap3430-sdp.dts |   28 ++--
   4 files changed, 29 insertions(+), 29 deletions(-)
  
  diff --git a/arch/arm/boot/dts/omap3-devkit8000.dts 
  b/arch/arm/boot/dts/omap3-devkit8000.dts
  index 5be71b1..08699cb 100644
  --- a/arch/arm/boot/dts/omap3-devkit8000.dts
  +++ b/arch/arm/boot/dts/omap3-devkit8000.dts
  @@ -143,27 +143,27 @@
   
  x-loader@0 {
  label = X-Loader;
  -   reg = 0 0x8;
  +   reg = (0 * SZ_128K) (4 * SZ_128K);
  };
   
  bootloaders@8 {
  label = U-Boot;
  -   reg = 0x8 0x1e;
  +   reg = (4 * SZ_128K) (15 * SZ_128K);
  };
   
  bootloaders_env@26 {
  label = U-Boot Env;
  -   reg = 0x26 0x2;
  +   reg = (19 * SZ_128K) (1 * SZ_128K);
  };
   
  kernel@28 {
  label = Kernel;
  -   reg = 0x28 0x40;
  +   reg = (20 * SZ_128K) (32 * SZ_128K);
  };
   
  filesystem@68 {
  label = File System;
  -   reg = 0x68 0xf98;
  +   reg = (52 * SZ_128K) MTDPART_SIZ_FULL;
  };
  };
   };
  diff --git a/arch/arm/boot/dts/omap3-igep0020.dts 
  b/arch/arm/boot/dts/omap3-igep0020.dts
  index e8c4828..3476b3c 100644
  --- a/arch/arm/boot/dts/omap3-igep0020.dts
  +++ b/arch/arm/boot/dts/omap3-igep0020.dts
  @@ -97,23 +97,23 @@
   
  partition@0 {
  label = SPL;
  -   reg = 0 0x10;
  +   reg = (0 * SZ_256K) (4 * SZ_256K);
  };
  partition@0x8 {
  label = U-Boot;
  -   reg = 0x10 0x18;
  +   reg = (4 * SZ_256K) (6 * SZ_256K);
  };
  partition@0x1c {
  label = Environment;
  -   reg = 0x28 0x10;
  +   reg = (10 * SZ_256K) (4 * SZ_256K);
  };
  partition@0x28 {
  label = Kernel;
  -   reg = 0x38 0x30;
  +   reg = (14 * SZ_256K) (12 * SZ_256K);
  };
  partition@0x78 {
  label = Filesystem;
  -   reg = 0x68 0x1f98;
  +   reg = (26 * SZ_256K) MTDPART_SIZ_FULL;
  };
  };
   
  diff --git a/arch/arm/boot/dts/omap3-igep0030.dts 
  b/arch/arm/boot/dts/omap3-igep0030.dts
  index 644d053..e4f078c 100644
  --- a/arch/arm/boot/dts/omap3-igep0030.dts
  +++ b/arch/arm/boot/dts/omap3-igep0030.dts
  @@ -72,23 +72,23 @@
   
  partition@0 {
  label = SPL;
  -   reg = 0 0x10;
  +   reg = (0 * SZ_256K) (4 * SZ_256K);
  };
  partition@0x8 {
  label = U-Boot;
  -   reg = 0x10 0x18;
  +   reg = (4 * SZ_256K) (6 * SZ_256K);
  };
  partition@0x1c {
  label = Environment;
  -   reg = 0x28 0x10;
  +   reg = (10 * SZ_256K) (4 * SZ_256K);
  };
  partition@0x28 {
  label = Kernel;
  -   reg = 0x38 0x30;
  +   reg = (14 * SZ_256K) (12 * SZ_256K);
  };
  partition@0x78 {
  label = Filesystem;
  -   reg = 0x68 0x1f98;
  +   reg = (26 * SZ_256K) MTDPART_SIZ_FULL;
  };
  };
   };
 
 Hi Florian,
 
 I don't have access to my IGEP board so I can test it right now but the patch
 looks good to me.
 
 In fact I wanted to use MTDPART_SIZ_FULL when added the NAND nodes since not 
 all
 IGEP boards have 512MB flash but I didn't know that a value of 0 meant that.
 
 So thanks a lot for doing this!
 
 Acked-by: Javier Martinez Canillas javier.marti...@collabora.co.uk

However, the binding doesn't allow for that and so it is a bug in the
parser. Relying on '0' is not safe. Nor does it match device tree
convention for the reg property, so don't count on getting an extension
added to allow it.

NAK

--
To unsubscribe from this list: send the line unsubscribe linux-omap 

Re: [PATCH 3/4] mmc: omap_hsmmc: Remux pins to support SDIO interrupt and PM runtime

2013-06-12 Thread Tony Lindgren
* Linus Walleij linus.wall...@linaro.org [130611 01:00]:
 On Mon, Jun 10, 2013 at 6:23 PM, Tony Lindgren t...@atomide.com wrote:
 
  We only should remux the pins that need remuxing as that's done
  every time hitting idle. So I think we should have the following
  default groups:
 
  default Static pins that don't change, no need to remux
  configured in consumer driver probe like we already
  do
 
  active  Optional dynamic pins remuxed for runtime, can be
  configured and selected in consumer driver probe.
  The consumer driver may also want to select this
  state in PM runtime resume.
 
  idleOptional dynamic pins remuxed for idle. The consumer
  driver may also want to select this state in PM
  runtime suspend depending on device_can_wakeup()
  and driver specific needs.
 
 The one thing I don't understand is why a driver would select the
 active state in probe(), unless it's a driver that does not support
 runtime PM. (But maybe that's what you mean.)

Yes you're right, there should not be any need to select active state
in probe, that should be selected by PM runtime.
 
 Compare this to linus/pinctrl/pinctrl-state.h:
 
 /**
  * @PINCTRL_STATE_DEFAULT: the state the pinctrl handle shall be put
  *  into as default, usually this means the pins are up and ready to
  *  be used by the device driver. This state is commonly used by
  *  hogs to configure muxing and pins at boot, and also as a state
  *  to go into when returning from sleep and idle in
  *  .pm_runtime_resume() or ordinary .resume() for example.
  * @PINCTRL_STATE_IDLE: the state the pinctrl handle shall be put into
  *  when the pins are idle. This is a state where the system is relaxed
  *  but not fully sleeping - some power may be on but clocks gated for
  *  example. Could typically be set from a pm_runtime_suspend() or
  *  pm_runtime_idle() operation.
  * @PINCTRL_STATE_SLEEP: the state the pinctrl handle shall be put into
  *  when the pins are sleeping. This is a state where the system is in
  *  its lowest sleep state. Could typically be set from an
  *  ordinary .suspend() function.
  */
 #define PINCTRL_STATE_DEFAULT default
 #define PINCTRL_STATE_IDLE idle
 #define PINCTRL_STATE_SLEEP sleep
 
 The way I currently use these in e.g.
 drivers/spi/spi-pl022 is:
 
 probe:
  - default
 
 runtime_suspend:
  - idle
 
 runtime_resume:
  - default
 
 suspend:
  - sleep
 
 resume:
   - default
   - idle
 
 Notice that we go to default then idle on probe and
 runtime resume. This is because the idle state is
 optional (as is the sleep state).
 
 So I guess if we should extend this terminology to match
 what you are using for the OMAP it would rather be like
 this:
 
 probe:
  - default
 
 runtime_suspend:
  - idle
 
 runtime_resume:
  - default
  - active

At least for omaps, there's no need to select default in
runtime_resume as the default pins stay that way.
 
 suspend:
  - sleep

For omaps, we would just select idle pins again in the
suspend case.
 
 resume:
   - default
   - idle

And for omaps, there's no need to select default in resume
either. Just selecting active would do the trick for resume.

So for omaps, the sequence would be:

probe:
 - default (typically all device pins except rx pin)

runtime_suspend:
suspend:
 - idle (remux rx pin from device to gpio input for wake)
 
runtime_resume:
resume:
 - active (remux rx pin from gpio input to device)
 
 Just one more optional active state in runtime resume.
 Correct?

Yes the active is needed, but sleep would be unused for
omaps.
 
 If we can agree on this I will add the active state to the
 state table and add a container in the core for this as well
 as pinctrl_pm_select_active_state() so we can skip all the
 pointless boilerplate also in the OMAP drivers, plus increase
 the readability and portability quite a bit.

Sounds good to me as long as we don't always need to select
the default pins over and over in PM runtime_resume.
 
  However in this case I *suspect* that what you really want
  to do it to rename the state called default to sleep
  (it appears the default state is sleepy) and then rename
  the active state to default (as this is the defined semantic
  meaning of default from linux/pinctrl/pinctrl-state.h.
 
  The idle state above could also be called sleep instead of idle
  if you prefer that.
 
 No I think we should reserve that name for the pin state
 associated with suspend(). Let's leave it like this.

OK
 
  I think the confusion is caused by the fact that we need three
  mux groups, not just two :) The toggling between active and idle
  is the hotpath as that can potentially happen for multiple drivers
  every time we enter and exit idle.
 
 Actually we have the same thing, it's just that our default
 and active are the same thing. But it seems we need to
 

Re: am335x: TSC ADC reworking including DT pieces, take 4

2013-06-12 Thread Sebastian Andrzej Siewior
On 06/11/2013 07:55 PM, Samuel Ortiz wrote:
 Hi Jonathan,

Hi Samuel,

 Sebastian, please address the commit log and cosmetic issues I pointed out,
 keep the regmap code and I'll pull this patchset in.

By keep the regmap code you mean I am allowed to remove the regmap
usage in mfd (keep patch #1) or do you insist on adding its usage in
iio and input?

 Cheers,
 Samuel.

Sebastian
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH 3/4] pinctrl: single: omap: Add SoC specific module for wake-up events

2013-06-12 Thread Tony Lindgren
* Roger Quadros rog...@ti.com [130611 05:57]:
 On 06/10/2013 06:21 PM, Tony Lindgren wrote:
  * Quadros, Roger rog...@ti.com [130610 03:09]:
  +
  +static int __init pcs_omap_init(void)
  +{
  +   platform_driver_register(pcs_omap_soc_driver);
  +   platform_driver_register(pcs_omap_driver);
  +
  +   return 0;
  +}
  +module_init(pcs_omap_init);
 
  It seems this has to be moved to an earlier place (e.g. subsys_initcall)
  else the pinctrl core fails to find the pinctrl device at the device 
  creation
  time and bails out with -EPROBE_DEFER. Also, that device is never
  created again, so -EPROBE_DEFER doesn't seem to work there.
  
  Ah here, found your other comment :)
  
  That's not needed, the real fix is to make twl-core.c and friends to
  be regular module_init. There are already patches queued for that.
 
 OK. I was testing with USB host driver and it seems to be loaded as 
 fs_initcall() which
 is the root of the problem. I will fix up the usb host driver to be loaded as 
 module_init()

OK good to hear.

Regards,

Tony
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH v2 2/2] PM / AVS: SmartReflex/class3: Fix order of initialization of SR class and SR driver

2013-06-12 Thread Tony Lindgren
* Kevin Hilman khil...@linaro.org [130610 10:58]:
 Andrii Tseglytskyi andrii.tseglyts...@ti.com writes:
 
  SmartReflex consists of three entities: SR device, SR class and
  SR driver. SmartReflex driver depends on SmartReflex class, but
  order of their initialization is not clear. They both use
  late_initcall(), and order depends on Makefile calls.
  Patch moves initialization of SR class to device_initcall(),
  and removes redundant call of sr_late_init().
 
  This provides predictable order of SmartReflex initcalls:
  1. device_initcall() - SmartReflex class init
  2. late_initcall() - SmartReflex driver init
 
  Signed-off-by: Andrii Tseglytskyi andrii.tseglyts...@ti.com
 
 Tony will have to decide on whether he's OK with the initcall changes.
 
 I can queue this with the rest of the AVS changes with Tony's ack.

I'd rather not make anything earlier, relying on the Makefile is just
fine here. These pieces are always compiled in too. The reason why
we should only minimal things initialized earlier than module_init
is that this way we have a proper console initialized and see real
error messages without having to have DEBUG_LL + earlyprintk enabled.

If anything else is needed, you have have just one late_initcall
that checks the return values of the various SR related init functions
to make sure all the dependencies are met.

Regards,

Tony
 
   arch/arm/mach-omap2/smartreflex-class3.c |2 +-
   drivers/power/avs/smartreflex.c  |9 -
   2 files changed, 1 insertion(+), 10 deletions(-)
 
  diff --git a/arch/arm/mach-omap2/smartreflex-class3.c 
  b/arch/arm/mach-omap2/smartreflex-class3.c
  index aee3c89..50523b8 100644
  --- a/arch/arm/mach-omap2/smartreflex-class3.c
  +++ b/arch/arm/mach-omap2/smartreflex-class3.c
  @@ -59,4 +59,4 @@ static int __init sr_class3_init(void)
  pr_info(SmartReflex Class3 initialized\n);
  return sr_register_class(class3_data);
   }
  -omap_late_initcall(sr_class3_init);
  +omap_device_initcall(sr_class3_init);
  diff --git a/drivers/power/avs/smartreflex.c 
  b/drivers/power/avs/smartreflex.c
  index fd71d5a..42eed34 100644
  --- a/drivers/power/avs/smartreflex.c
  +++ b/drivers/power/avs/smartreflex.c
  @@ -650,8 +650,6 @@ void sr_disable(struct voltagedomain *voltdm)
*/
   int sr_register_class(struct omap_sr_class_data *class_data)
   {
  -   struct omap_sr *sr_info;
  -
  if (!class_data) {
  pr_warning(%s:, Smartreflex class data passed is NULL\n,
  __func__);
  @@ -666,13 +664,6 @@ int sr_register_class(struct omap_sr_class_data 
  *class_data)
   
  sr_class = class_data;
   
  -   /*
  -* Call into late init to do intializations that require
  -* both sr driver and sr class driver to be initiallized.
  -*/
  -   list_for_each_entry(sr_info, sr_list, node)
  -   sr_late_init(sr_info);
  -
  return 0;
   }
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: am335x: TSC ADC reworking including DT pieces, take 4

2013-06-12 Thread Samuel Ortiz
Hi Sebastian,

On Wed, Jun 12, 2013 at 03:29:43PM +0200, Sebastian Andrzej Siewior wrote:
 On 06/11/2013 07:55 PM, Samuel Ortiz wrote:
  Hi Jonathan,
 
 Hi Samuel,
 
  Sebastian, please address the commit log and cosmetic issues I pointed out,
  keep the regmap code and I'll pull this patchset in.

 By keep the regmap code you mean I am allowed to remove the regmap
 usage in mfd (keep patch #1) or do you insist on adding its usage in
 iio and input?
I insist on keeping it on the MFD driver, i.e. _not_ keeping patch #1.

Cheers,
Samuel.

-- 
Intel Open Source Technology Centre
http://oss.intel.com/
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH V2 14/14] ARM: OMAP4: hwmod data: Clean up the data file

2013-06-12 Thread Tony Lindgren
* Tomi Valkeinen tomi.valkei...@iki.fi [130611 00:49]:
 On 10/06/13 17:14, Tony Lindgren wrote:
  * Tomi Valkeinen tomi.valkei...@iki.fi [130610 03:44]:
 
  DSS does not have DT bindings, and removing DSS from hwmod data will
  break DSS for omap4.
  
  Ah that's right. Care to post a patch reverting the minimal parts that
  you need for omap4 against omap-for-v3.11/cleanup?
 
 This one adds back the DSS data.

OK thanks, applying into omap-for-v3.11/cleanup.

Regards,

Tony
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: am335x: TSC ADC reworking including DT pieces, take 4

2013-06-12 Thread Sebastian Andrzej Siewior
On 06/12/2013 03:50 PM, Samuel Ortiz wrote:
 Hi Sebastian,

Hi Samuel,

 By keep the regmap code you mean I am allowed to remove the regmap
 usage in mfd (keep patch #1) or do you insist on adding its usage in
 iio and input?
 I insist on keeping it on the MFD driver, i.e. _not_ keeping patch #1.

This forces me redo a few things and most likely adding it to the
iio and input driver to be consistent here.

Could you please give a reason why using the regmap here is a good
thing? I mentioned a few why it is not and why is better to leave it
out.

 Cheers,
 Samuel.

Sebastian
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH 0/3] ARM: OMAP: add corrected DSS regulator supplies

2013-06-12 Thread Tony Lindgren
* Tomi Valkeinen tomi.valkei...@ti.com [130612 03:44]:
 On 31/05/13 10:37, Tomi Valkeinen wrote:
  Hi Tony,
  
  Here are a few patches adding corrected DSS regulator supplies. The current
  ones in the board files are not really correct, although the dss driver 
  works
  ok with them.
  
  So these patches add new regulator supply entries. When these are merged, 
  I'll
  change omapdss driver to use the new ones, instead of the old ones. After 
  that,
  we can remove the old ones from the board files.
  
  Note that these patches were also present in the big DSS series I sent
  yesterday. There's no reason for these patches to be there, so I'm sending 
  them
  separately, and will drop these from my DSS series.
 
 Ping.

Thanks, applying into omap-for-v.311/fixes-non-critical.

Regards,

Tony
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH 0/3] ARM: OMAP2+: devices: Silence hwmod lookup failures (dmic/mcpdm)

2013-06-12 Thread Tony Lindgren
* Peter Ujfalusi peter.ujfal...@ti.com [130611 01:37]:
 Hi,
 
 Small patches to silence the hwmod lookup failures in case when we boot the
 kernel on boards where the IPs are not present (OMAP2/3 vs McPDM, DMIC,
 HDMI audio).

Thanks applying into omap-for-v3.11/fixes-non-critical.

Regards,

Tony

 Peter Ujfalusi (3):
   ARM: OMAP2+: devices: Do not print error when McPDM hwmod lookup fails
   ARM: OMAP2+: devices: Do not print error when DMIC hwmod lookup fails
   ARM: OMAP2+: devices: Do not print error when dss_hdmi hwmod lookup
 fails
 
  arch/arm/mach-omap2/devices.c | 12 +++-
  1 file changed, 3 insertions(+), 9 deletions(-)
 
 -- 
 1.8.2.1
 
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH] arm/omap: use const char properly

2013-06-12 Thread Tony Lindgren
* Ruslan Bilovol ruslan.bilo...@ti.com [130606 06:48]:
 Hi Sebastian,
 
 On Thu, Jun 6, 2013 at 4:24 PM, Sebastian Andrzej Siewior
 bige...@linutronix.de wrote:
  The itention was probably to make both pointers const but as it is now,
  it is just const used twice.
 
 Yes, it's a typo I did accidentally. Good catch!

Thanks applying into omap-for-v3.11/fixes-non-critical.

Regards,

Tony
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH v2 01/10] ARM: OMAP2+: add needs_vmmc to hsmmc_info

2013-06-12 Thread Tony Lindgren
* Balaji T K balaj...@ti.com [130606 12:20]:
 Add needs_vmmc and needs_vmmc_aux to indicate whether regulator is
 applicable so that omap_hsmmc can handle deferred probe error
 properly for regulators.
 Remove the assumption that vmmc_aux regulator to be available only if vmmc is
 present. Platforms can have fixed-always-ON regulator for vmmc and/or vmmc_aux
 in such cases regulator needed not be specified in board file.

Looks good to me, I suggest you resend this again a bit later once the
other changes are merged so we can avoid a dependency between 
arch/arm/mach-omap2
and MMC changes.

Regards,

Tony
 
 Signed-off-by: Balaji T K balaj...@ti.com
 ---
  arch/arm/mach-omap2/board-2430sdp.c  |1 +
  arch/arm/mach-omap2/board-3430sdp.c  |3 +++
  arch/arm/mach-omap2/board-cm-t35.c   |2 ++
  arch/arm/mach-omap2/board-devkit8000.c   |1 +
  arch/arm/mach-omap2/board-igep0020.c |3 +++
  arch/arm/mach-omap2/board-ldp.c  |1 +
  arch/arm/mach-omap2/board-omap3beagle.c  |2 ++
  arch/arm/mach-omap2/board-omap3evm.c |3 +++
  arch/arm/mach-omap2/board-omap3logic.c   |1 +
  arch/arm/mach-omap2/board-omap3pandora.c |3 +++
  arch/arm/mach-omap2/board-omap3stalker.c |2 ++
  arch/arm/mach-omap2/board-omap3touchbook.c   |2 ++
  arch/arm/mach-omap2/board-overo.c|1 +
  arch/arm/mach-omap2/board-rm680.c|1 +
  arch/arm/mach-omap2/board-rx51-peripherals.c |3 +++
  arch/arm/mach-omap2/board-zoom-peripherals.c |4 
  arch/arm/mach-omap2/hsmmc.c  |2 ++
  arch/arm/mach-omap2/hsmmc.h  |2 ++
  include/linux/platform_data/mmc-omap.h   |2 ++
  19 files changed, 39 insertions(+), 0 deletions(-)
 
 diff --git a/arch/arm/mach-omap2/board-2430sdp.c 
 b/arch/arm/mach-omap2/board-2430sdp.c
 index 244d8a5..eba8593 100644
 --- a/arch/arm/mach-omap2/board-2430sdp.c
 +++ b/arch/arm/mach-omap2/board-2430sdp.c
 @@ -211,6 +211,7 @@ static struct omap2_hsmmc_info mmc[] __initdata = {
   .gpio_cd= -EINVAL,
   .gpio_wp= -EINVAL,
   .ext_clock  = 1,
 + .needs_vmmc = 1,
   },
   {}  /* Terminator */
  };
 diff --git a/arch/arm/mach-omap2/board-3430sdp.c 
 b/arch/arm/mach-omap2/board-3430sdp.c
 index 23b004a..9438c54 100644
 --- a/arch/arm/mach-omap2/board-3430sdp.c
 +++ b/arch/arm/mach-omap2/board-3430sdp.c
 @@ -184,12 +184,15 @@ static struct omap2_hsmmc_info mmc[] = {
   .caps   = MMC_CAP_4_BIT_DATA | MMC_CAP_8_BIT_DATA,
   .gpio_wp= 4,
   .deferred   = true,
 + .needs_vmmc = 1,
 + .needs_vmmc_aux = 1,
   },
   {
   .mmc= 2,
   .caps   = MMC_CAP_4_BIT_DATA | MMC_CAP_8_BIT_DATA,
   .gpio_wp= 7,
   .deferred   = true,
 + .needs_vmmc = 1,
   },
   {}  /* Terminator */
  };
 diff --git a/arch/arm/mach-omap2/board-cm-t35.c 
 b/arch/arm/mach-omap2/board-cm-t35.c
 index ee6218c..207ea13 100644
 --- a/arch/arm/mach-omap2/board-cm-t35.c
 +++ b/arch/arm/mach-omap2/board-cm-t35.c
 @@ -364,6 +364,8 @@ static struct omap2_hsmmc_info mmc[] = {
   .gpio_cd= -EINVAL,
   .gpio_wp= -EINVAL,
   .deferred   = true,
 + .needs_vmmc = 1,
 + .needs_vmmc_aux = 1,
   },
   {
   .mmc= 2,
 diff --git a/arch/arm/mach-omap2/board-devkit8000.c 
 b/arch/arm/mach-omap2/board-devkit8000.c
 index 5764205..63fd8827 100644
 --- a/arch/arm/mach-omap2/board-devkit8000.c
 +++ b/arch/arm/mach-omap2/board-devkit8000.c
 @@ -99,6 +99,7 @@ static struct omap2_hsmmc_info mmc[] = {
   .caps   = MMC_CAP_4_BIT_DATA | MMC_CAP_8_BIT_DATA,
   .gpio_wp= 29,
   .deferred   = true,
 + .needs_vmmc = 1,
   },
   {}  /* Terminator */
  };
 diff --git a/arch/arm/mach-omap2/board-igep0020.c 
 b/arch/arm/mach-omap2/board-igep0020.c
 index b54562d..a2a8a80 100644
 --- a/arch/arm/mach-omap2/board-igep0020.c
 +++ b/arch/arm/mach-omap2/board-igep0020.c
 @@ -284,6 +284,7 @@ static struct omap2_hsmmc_info mmc[] = {
   .gpio_cd= -EINVAL,
   .gpio_wp= -EINVAL,
   .deferred   = true,
 + .needs_vmmc = 1,
   },
  #if defined(CONFIG_LIBERTAS_SDIO) || defined(CONFIG_LIBERTAS_SDIO_MODULE)
   {
 @@ -291,6 +292,8 @@ static struct omap2_hsmmc_info mmc[] = {
   .caps   = MMC_CAP_4_BIT_DATA,
   .gpio_cd= -EINVAL,
   .gpio_wp= -EINVAL,
 + .needs_vmmc = 1,
 + .needs_vmmc_aux = 1,
   },
  #endif
   {}  /* Terminator */
 diff --git a/arch/arm/mach-omap2/board-ldp.c 

Re: [PATCH v2 02/10] mmc: omap_hsmmc: make vcc and vcc_aux independent

2013-06-12 Thread Tony Lindgren
* Balaji T K balaj...@ti.com [130606 12:20]:
 handle vcc and vcc_aux independently
 
 Signed-off-by: Balaji T K balaj...@ti.com
 ---
  drivers/mmc/host/omap_hsmmc.c |9 +
  1 files changed, 5 insertions(+), 4 deletions(-)
 
 diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
 index 1865321..bda1a42 100644
 --- a/drivers/mmc/host/omap_hsmmc.c
 +++ b/drivers/mmc/host/omap_hsmmc.c
 @@ -253,7 +253,7 @@ static int omap_hsmmc_set_power(struct device *dev, int 
 slot, int power_on,
* If we don't see a Vcc regulator, assume it's a fixed
* voltage always-on regulator.
*/
 - if (!host-vcc)
 + if (!host-vcc  !host-vcc_aux)
   return 0;
   /*
* With DT, never turn OFF the regulator for MMC1. This is because

Doesn't the above change break MMC for most boards that only pass
one regulator and no aux regulator?

Regards,

Tony

 @@ -280,11 +280,12 @@ static int omap_hsmmc_set_power(struct device *dev, int 
 slot, int power_on,
* chips/cards need an interface voltage rail too.
*/
   if (power_on) {
 - ret = mmc_regulator_set_ocr(host-mmc, host-vcc, vdd);
 + if (host-vcc)
 + ret = mmc_regulator_set_ocr(host-mmc, host-vcc, vdd);
   /* Enable interface voltage rail, if needed */
   if (ret == 0  host-vcc_aux) {
   ret = regulator_enable(host-vcc_aux);
 - if (ret  0)
 + if (ret  0  host-vcc)
   ret = mmc_regulator_set_ocr(host-mmc,
   host-vcc, 0);
   }
 @@ -292,7 +293,7 @@ static int omap_hsmmc_set_power(struct device *dev, int 
 slot, int power_on,
   /* Shut down the rail */
   if (host-vcc_aux)
   ret = regulator_disable(host-vcc_aux);
 - if (!ret) {
 + if (host-vcc) {
   /* Then proceed to shut down the local regulator */
   ret = mmc_regulator_set_ocr(host-mmc,
   host-vcc, 0);
 -- 
 1.7.5.4
 
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH v2 02/10] mmc: omap_hsmmc: make vcc and vcc_aux independent

2013-06-12 Thread Balaji T K

On Wednesday 12 June 2013 07:55 PM, Tony Lindgren wrote:

* Balaji T K balaj...@ti.com [130606 12:20]:

handle vcc and vcc_aux independently

Signed-off-by: Balaji T K balaj...@ti.com
---
  drivers/mmc/host/omap_hsmmc.c |9 +
  1 files changed, 5 insertions(+), 4 deletions(-)

diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index 1865321..bda1a42 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -253,7 +253,7 @@ static int omap_hsmmc_set_power(struct device *dev, int 
slot, int power_on,
 * If we don't see a Vcc regulator, assume it's a fixed
 * voltage always-on regulator.
 */
-   if (!host-vcc)
+   if (!host-vcc  !host-vcc_aux)
return 0;
/*
 * With DT, never turn OFF the regulator for MMC1. This is because


Doesn't the above change break MMC for most boards that only pass
one regulator and no aux regulator?



No, I want to skip regulator operation in set_power function iff both
regulator are not present.

Earlier vcc was assumed/mandatory if vcc_aux is present.
Now, regulator operation will be handled if either one of vcc/vcc_aux is 
present,


Regards,

Tony


@@ -280,11 +280,12 @@ static int omap_hsmmc_set_power(struct device *dev, int 
slot, int power_on,
 * chips/cards need an interface voltage rail too.
 */
if (power_on) {
-   ret = mmc_regulator_set_ocr(host-mmc, host-vcc, vdd);
+   if (host-vcc)
+   ret = mmc_regulator_set_ocr(host-mmc, host-vcc, vdd);
/* Enable interface voltage rail, if needed */
if (ret == 0  host-vcc_aux) {
ret = regulator_enable(host-vcc_aux);
-   if (ret  0)
+   if (ret  0  host-vcc)
ret = mmc_regulator_set_ocr(host-mmc,
host-vcc, 0);
}
@@ -292,7 +293,7 @@ static int omap_hsmmc_set_power(struct device *dev, int 
slot, int power_on,
/* Shut down the rail */
if (host-vcc_aux)
ret = regulator_disable(host-vcc_aux);
-   if (!ret) {
+   if (host-vcc) {
/* Then proceed to shut down the local regulator */
ret = mmc_regulator_set_ocr(host-mmc,
host-vcc, 0);
--
1.7.5.4



--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH v2 08/10] ARM: dts: omap3: split omap3_pmx_core

2013-06-12 Thread Tony Lindgren
* Balaji T K balaj...@ti.com [130606 12:20]:
 omap3_pmx_core: padconf register are in two banks 0x48003000 to 0x48002268
 and 0x480025c0 to 0x480025f8.
 
 split omap3_pmx_core into 2 banks as register between 0x48002270 and 
 0x48002564
 belongs to type pinctrl-single,bit-per-mux with access to certain bit
 fields with bit field mask.

Is this the right patch for the description? THe patch seems to deal with
USB pins.

Also, let's not hog any pins under the pinmux controllers, those make
unloading pinctrl-single impossible which is not nice for distros and
development.

Instead, the pins should be under mmc1 in omap[345].dtsi files.

Regards,

Tony
 
 Signed-off-by: Balaji T K balaj...@ti.com
 ---
  arch/arm/boot/dts/omap3-beagle.dts |   28 
  arch/arm/boot/dts/omap3.dtsi   |   11 ++-
  2 files changed, 30 insertions(+), 9 deletions(-)
 
 diff --git a/arch/arm/boot/dts/omap3-beagle.dts 
 b/arch/arm/boot/dts/omap3-beagle.dts
 index 6eec699..7da9979 100644
 --- a/arch/arm/boot/dts/omap3-beagle.dts
 +++ b/arch/arm/boot/dts/omap3-beagle.dts
 @@ -76,17 +76,11 @@
  omap3_pmx_core {
   pinctrl-names = default;
   pinctrl-0 = 
 - hsusbb2_pins
 + hsusbb2_pins1
   ;
  
 - hsusbb2_pins: pinmux_hsusbb2_pins {
 + hsusbb2_pins1: pinmux_hsusbb2_pins1 {
   pinctrl-single,pins = 
 - 0x5c0 0x3  /* 
 USBB2_ULPITLL_CLK_MUXMODE.usbb1_ulpiphy_clk OUTPUT */
 - 0x5c2 0x3  /* 
 USBB2_ULPITLL_CLK_MUXMODE.usbb1_ulpiphy_stp OUTPUT */
 - 0x5c4 0x10b  /* 
 USBB2_ULPITLL_CLK_MUXMODE.usbb1_ulpiphy_dir INPUT | PULLDOWN */
 - 0x5c6 0x10b  /* 
 USBB2_ULPITLL_CLK_MUXMODE.usbb1_ulpiphy_nxt INPUT | PULLDOWN */
 - 0x5c8 0x10b  /* 
 USBB2_ULPITLL_CLK_MUXMODE.usbb1_ulpiphy_dat0 INPUT | PULLDOWN */
 - 0x5cA 0x10b  /* 
 USBB2_ULPITLL_CLK_MUXMODE.usbb1_ulpiphy_dat1 INPUT | PULLDOWN */
   0x1a4 0x10b  /* 
 USBB2_ULPITLL_CLK_MUXMODE.usbb1_ulpiphy_dat2 INPUT | PULLDOWN */
   0x1a6 0x10b  /* 
 USBB2_ULPITLL_CLK_MUXMODE.usbb1_ulpiphy_dat3 INPUT | PULLDOWN */
   0x1a8 0x10b  /* 
 USBB2_ULPITLL_CLK_MUXMODE.usbb1_ulpiphy_dat4 INPUT | PULLDOWN */
 @@ -97,6 +91,24 @@
   };
  };
  
 +omap3_pmx_core2 {
 + pinctrl-names = default;
 + pinctrl-0 = 
 + hsusbb2_pins2
 + ;
 +
 + hsusbb2_pins2: pinmux_hsusbb2_pins2 {
 + pinctrl-single,pins = 
 + 0x50 0x3  /* 
 USBB2_ULPITLL_CLK_MUXMODE.usbb1_ulpiphy_clk OUTPUT */
 + 0x52 0x3  /* 
 USBB2_ULPITLL_CLK_MUXMODE.usbb1_ulpiphy_stp OUTPUT */
 + 0x54 0x10b  /* 
 USBB2_ULPITLL_CLK_MUXMODE.usbb1_ulpiphy_dir INPUT | PULLDOWN */
 + 0x56 0x10b  /* 
 USBB2_ULPITLL_CLK_MUXMODE.usbb1_ulpiphy_nxt INPUT | PULLDOWN */
 + 0x58 0x10b  /* 
 USBB2_ULPITLL_CLK_MUXMODE.usbb1_ulpiphy_dat0 INPUT | PULLDOWN */
 + 0x5A 0x10b  /* 
 USBB2_ULPITLL_CLK_MUXMODE.usbb1_ulpiphy_dat1 INPUT | PULLDOWN */
 + ;
 + };
 +};
 +
  i2c1 {
   clock-frequency = 260;
  
 diff --git a/arch/arm/boot/dts/omap3.dtsi b/arch/arm/boot/dts/omap3.dtsi
 index 82a404d..caaa708 100644
 --- a/arch/arm/boot/dts/omap3.dtsi
 +++ b/arch/arm/boot/dts/omap3.dtsi
 @@ -95,7 +95,16 @@
  
   omap3_pmx_core: pinmux@48002030 {
   compatible = ti,omap3-padconf, pinctrl-single;
 - reg = 0x48002030 0x05cc;
 + reg = 0x48002030 0x238;
 + #address-cells = 1;
 + #size-cells = 0;
 + pinctrl-single,register-width = 16;
 + pinctrl-single,function-mask = 0x7f1f;
 + };
 +
 + omap3_pmx_core2: pinmux@480025a0 {
 + compatible = ti,omap3-padconf, pinctrl-single;
 + reg = 0x480025a0 0x5c;
   #address-cells = 1;
   #size-cells = 0;
   pinctrl-single,register-width = 16;
 -- 
 1.7.5.4
 
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH v2 09/10] ARM: dts: omap3: add pbias and mmc_init pinctrl states

2013-06-12 Thread Tony Lindgren
* Balaji T K balaj...@ti.com [130606 12:20]:
 add pbias states for pbias 0, 1.8V, 3V
 add omap3 sd/mmc2 loop back clock config for devconf1 in mmc2_init pinctrl 
 state
 add OMAP3430 sd/mmc1 loop back clock config for devconf0 in mmc1_init pinctrl 
 state
 add OMAP3630 sd/mmc1 speed mode config for prog_io1 in mmc1_init pinctrl state

Looks OK to me, except these should be under mmc1 for omap[345].dtsi files.

Regards,

Tony
 
 Signed-off-by: Balaji T K balaj...@ti.com
 ---
  arch/arm/boot/dts/omap3-beagle-xm.dts |   42 
 +
  arch/arm/boot/dts/omap3-beagle.dts|   42 
 +
  arch/arm/boot/dts/omap3.dtsi  |   10 
  3 files changed, 94 insertions(+), 0 deletions(-)
 
 diff --git a/arch/arm/boot/dts/omap3-beagle-xm.dts 
 b/arch/arm/boot/dts/omap3-beagle-xm.dts
 index 3046d1f..45d1642 100644
 --- a/arch/arm/boot/dts/omap3-beagle-xm.dts
 +++ b/arch/arm/boot/dts/omap3-beagle-xm.dts
 @@ -59,6 +59,40 @@
   };
  };
  
 +omap3_pmx_general {
 + pinctrl-names = default;
 + pinctrl-0 = ;
 + pbias_off: pinmux_pbias_off {
 + pinctrl-single,bits = 
 + 0x2b0 0x1 0x3   /* pbias */
 + ;
 + };
 +
 + pbias_1v8: pinmux_pbias_1v8 {
 + pinctrl-single,bits = 
 + 0x2b0 0x2 0x3   /* pbias */
 + ;
 + };
 +
 + pbias_3v: pinmux_pbias_3v {
 + pinctrl-single,bits = 
 + 0x2b0 0x3 0x3   /* pbias */
 + ;
 + };
 +
 + mmc1_init: pinmux_mmc1_init {
 + pinctrl-single,bits = 
 + 0x1d8 0x10 0x10 /* prog_io1 */
 + ;
 + };
 +
 + mmc2_init: pinmux_mmc2_init {
 + pinctrl-single,bits = 
 + 0x68 0x40 0x40  /* devconf1 */
 + ;
 + };
 +};
 +
  i2c1 {
   clock-frequency = 260;
  
 @@ -95,12 +129,20 @@
  };
  
  mmc1 {
 + pinctrl-names = default, mmc_init, pbias_off, pbias_1v8, 
 pbias_3v;
 + pinctrl-0 = ;
 + pinctrl-1 = mmc1_init;
 + pinctrl-2 = pbias_off;
 + pinctrl-3 = pbias_1v8;
 + pinctrl-4 = pbias_3v;
   vmmc-supply = vmmc1;
   vmmc_aux-supply = vsim;
   bus-width = 8;
  };
  
  mmc2 {
 + pinctrl-names = mmc_init;
 + pinctrl-1 = mmc2_init;
   status = disabled;
  };
  
 diff --git a/arch/arm/boot/dts/omap3-beagle.dts 
 b/arch/arm/boot/dts/omap3-beagle.dts
 index 7da9979..14e251f 100644
 --- a/arch/arm/boot/dts/omap3-beagle.dts
 +++ b/arch/arm/boot/dts/omap3-beagle.dts
 @@ -109,6 +109,40 @@
   };
  };
  
 +omap3_pmx_general {
 + pinctrl-names = default;
 + pinctrl-0 = ;
 + pbias_off: pinmux_pbias_off {
 + pinctrl-single,bits = 
 + 0x2b0 0x5 0x7   /* pbias */
 + ;
 + };
 +
 + pbias_1v8: pinmux_pbias_1v8 {
 + pinctrl-single,bits = 
 + 0x2b0 0x6 0x7   /* pbias */
 + ;
 + };
 +
 + pbias_3v: pinmux_pbias_3v {
 + pinctrl-single,bits = 
 + 0x2b0 0x7 0x7   /* pbias */
 + ;
 + };
 +
 + mmc1_init: pinmux_mmc1_init {
 + pinctrl-single,bits = 
 + 0x4 0x0100 0x0100   /* devconf0 */
 + ;
 + };
 +
 + mmc2_init: pinmux_mmc2_init {
 + pinctrl-single,bits = 
 + 0x68 0x40 0x40  /* devconf1 */
 + ;
 + };
 +};
 +
  i2c1 {
   clock-frequency = 260;
  
 @@ -122,12 +156,20 @@
  /include/ twl4030.dtsi
  
  mmc1 {
 + pinctrl-names = default, mmc_init, pbias_off, pbias_1v8, 
 pbias_3v;
 + pinctrl-0 = ;
 + pinctrl-1 = mmc1_init;
 + pinctrl-2 = pbias_off;
 + pinctrl-3 = pbias_1v8;
 + pinctrl-4 = pbias_3v;
   vmmc-supply = vmmc1;
   vmmc_aux-supply = vsim;
   bus-width = 8;
  };
  
  mmc2 {
 + pinctrl-names = mmc_init;
 + pinctrl-1 = mmc2_init;
   status = disabled;
  };
  
 diff --git a/arch/arm/boot/dts/omap3.dtsi b/arch/arm/boot/dts/omap3.dtsi
 index caaa708..de2940d 100644
 --- a/arch/arm/boot/dts/omap3.dtsi
 +++ b/arch/arm/boot/dts/omap3.dtsi
 @@ -111,6 +111,16 @@
   pinctrl-single,function-mask = 0x7f1f;
   };
  
 + omap3_pmx_general: pinmux@48002270 {
 + compatible = ti,omap3-padconf, pinctrl-single;
 + reg = 0x48002270 0x2f4;
 + #address-cells = 1;
 + #size-cells = 0;
 + pinctrl-single,bit-per-mux;
 + pinctrl-single,register-width = 32;
 + pinctrl-single,function-mask = 0x;
 + };
 +
   omap3_pmx_wkup: pinmux@0x48002a00 {
   compatible = ti,omap3-padconf, pinctrl-single;
   reg = 0x48002a00 0x5c;
 -- 
 1.7.5.4
 
--
To unsubscribe from this list: send the line unsubscribe 

Re: [PATCH v2 10/10] ARM: dts: omap4: add pbias and mmc_init pinctrl states

2013-06-12 Thread Tony Lindgren
* Balaji T K balaj...@ti.com [130606 12:20]:
 add pbias states for pbias 0, 1.8V, 3V
 add sd/mmc1 pull strength values for control_mmc1 in mmc_init pinctrl state

This too should be under mmc1 in the omap4.dtsi file.

Tony
 
 Signed-off-by: Balaji T K balaj...@ti.com
 ---
  arch/arm/boot/dts/omap4-panda-common.dtsi |   34 
 +
  arch/arm/boot/dts/omap4-sdp.dts   |   34 
 +
  arch/arm/boot/dts/omap4.dtsi  |   11 +
  3 files changed, 79 insertions(+), 0 deletions(-)
 
 diff --git a/arch/arm/boot/dts/omap4-panda-common.dtsi 
 b/arch/arm/boot/dts/omap4-panda-common.dtsi
 index 03bd60d..d6ffbb1 100644
 --- a/arch/arm/boot/dts/omap4-panda-common.dtsi
 +++ b/arch/arm/boot/dts/omap4-panda-common.dtsi
 @@ -137,6 +137,34 @@
   };
  };
  
 +omap4_padconf_global {
 + pinctrl-names = default;
 + pinctrl-0 = ;
 + pbias_off: pinmux_pbias_off {
 + pinctrl-single,bits = 
 + 0x60 0x 0x07e0  /* pbias */
 + ;
 + };
 +
 + pbias_1v8: pinmux_pbias_1v8 {
 + pinctrl-single,bits = 
 + 0x60 0x0440 0x07e0  /* pbias */
 + ;
 + };
 +
 + pbias_3v: pinmux_pbias_3v {
 + pinctrl-single,bits = 
 + 0x60 0x0460 0x07e0  /* pbias */
 + ;
 + };
 +
 + mmc1_init: pinmux_mmc1_init {
 + pinctrl-single,bits = 
 + 0x88 0xce00 0xfe00  /* control_mmc1 */
 + ;
 + };
 +};
 +
  i2c1 {
   pinctrl-names = default;
   pinctrl-0 = i2c1_pins;
 @@ -197,6 +225,12 @@
  };
  
  mmc1 {
 + pinctrl-names = default, mmc_init, pbias_off, pbias_1v8, 
 pbias_3v;
 + pinctrl-0 = ;
 + pinctrl-1 = mmc1_init;
 + pinctrl-2 = pbias_off;
 + pinctrl-3 = pbias_1v8;
 + pinctrl-4 = pbias_3v;
   vmmc-supply = vmmc;
   bus-width = 8;
  };
 diff --git a/arch/arm/boot/dts/omap4-sdp.dts b/arch/arm/boot/dts/omap4-sdp.dts
 index a35d9cd..b1c0e86 100644
 --- a/arch/arm/boot/dts/omap4-sdp.dts
 +++ b/arch/arm/boot/dts/omap4-sdp.dts
 @@ -142,6 +142,34 @@
   };
  };
  
 +omap4_padconf_global {
 + pinctrl-names = default;
 + pinctrl-0 = ;
 + pbias_off: pinmux_pbias_off {
 + pinctrl-single,bits = 
 + 0x60 0x 0x07e0  /* pbias */
 + ;
 + };
 +
 + pbias_1v8: pinmux_pbias_1v8 {
 + pinctrl-single,bits = 
 + 0x60 0x0440 0x07e0  /* pbias */
 + ;
 + };
 +
 + pbias_3v: pinmux_pbias_3v {
 + pinctrl-single,bits = 
 + 0x60 0x0460 0x07e0  /* pbias */
 + ;
 + };
 +
 + mmc1_init: pinmux_mmc1_init {
 + pinctrl-single,bits = 
 + 0x88 0xce00 0xfe00  /* control_mmc1 */
 + ;
 + };
 +};
 +
  omap4_pmx_core {
   pinctrl-names = default;
   pinctrl-0 = 
 @@ -381,6 +409,12 @@
  };
  
  mmc1 {
 + pinctrl-names = default, mmc_init, pbias_off, pbias_1v8, 
 pbias_3v;
 + pinctrl-0 = ;
 + pinctrl-1 = mmc1_init;
 + pinctrl-2 = pbias_off;
 + pinctrl-3 = pbias_1v8;
 + pinctrl-4 = pbias_3v;
   vmmc-supply = vmmc;
   bus-width = 8;
  };
 diff --git a/arch/arm/boot/dts/omap4.dtsi b/arch/arm/boot/dts/omap4.dtsi
 index 2a56428..41f575d 100644
 --- a/arch/arm/boot/dts/omap4.dtsi
 +++ b/arch/arm/boot/dts/omap4.dtsi
 @@ -114,6 +114,17 @@
   pinctrl-single,register-width = 16;
   pinctrl-single,function-mask = 0x7fff;
   };
 +
 + omap4_padconf_global: pinmux@4a100600 {
 + compatible = ti,omap4-padconf, pinctrl-single;
 + reg = 0x4a1005a0 0x170;
 + #address-cells = 1;
 + #size-cells = 0;
 + pinctrl-single,bit-per-mux;
 + pinctrl-single,register-width = 32;
 + pinctrl-single,function-mask = 0x;
 + };
 +
   omap4_pmx_wkup: pinmux@4a31e040 {
   compatible = ti,omap4-padconf, pinctrl-single;
   reg = 0x4a31e040 0x0038;
 -- 
 1.7.5.4
 
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH v2 06/10] mmc: omap_hsmmc: add support for pbias configuration in dt

2013-06-12 Thread Tony Lindgren
* Balaji T K balaj...@ti.com [130606 12:20]:
 PBIAS register configuration is based on the regulator voltage
 which supplies these pbias cells, sd i/o pads.
 With PBIAS register address and bit definitions different across
 omap[3,4,5], Simplify PBIAS configuration under three different
 regulator voltage levels - O V, 1.8 V, 3 V. Corresponding pinctrl states
 are defined as pbias_off, pbias_1v8, pbias_3v.
 
 pinctrl state mmc_init is used for configuring speed mode, loopback clock
 (in devconf0/devconf1/prog_io1 register for omap3) and pull strength
 configuration (in control_mmc1 for omap4)
 
 Signed-off-by: Balaji T K balaj...@ti.com
 ---
  drivers/mmc/host/omap_hsmmc.c |   83 ++--
  1 files changed, 78 insertions(+), 5 deletions(-)
 
 diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
 index 533ced2..8dd1cd3 100644
 --- a/drivers/mmc/host/omap_hsmmc.c
 +++ b/drivers/mmc/host/omap_hsmmc.c
 @@ -182,6 +182,9 @@ struct omap_hsmmc_host {
   int req_in_progress;
   struct omap_hsmmc_next  next_data;
  
 + struct pinctrl  *pinctrl;
 + struct pinctrl_state*pbias_off, *pbias_1v8, *pbias_3v, *mmc_init;
 +
   struct  omap_mmc_platform_data  *pdata;
   int needs_vmmc:1;
   int needs_vmmc_aux:1;
 @@ -267,6 +270,12 @@ static int omap_hsmmc_set_power(struct device *dev, int 
 slot, int power_on,
   if (mmc_slot(host).before_set_reg)
   mmc_slot(host).before_set_reg(dev, slot, power_on, vdd);
  
 + if (host-pinctrl  host-pbias_off) {
 + ret = pinctrl_select_state(host-pinctrl, host-pbias_off);
 + if (ret  0)
 + dev_err(host-dev, pinctrl pbias_off select error\n);
 + }
 +
   /*
* Assume Vcc regulator is used only to power the card ... OMAP
* VDDS is used to power the pins, optionally with a transceiver to
 @@ -304,6 +313,25 @@ static int omap_hsmmc_set_power(struct device *dev, int 
 slot, int power_on,
   if (mmc_slot(host).after_set_reg)
   mmc_slot(host).after_set_reg(dev, slot, power_on, vdd);
  
 + /* 100ms delay required for PBIAS configuration */
 + msleep(100);

Hmm, why is the delay needed before the configuration? Is this something
you could avoid by reading the pinconf state maybe?

 + if (!vdd  host-pinctrl  host-pbias_off) {
 + ret = pinctrl_select_state(host-pinctrl, host-pbias_off);
 + if (ret  0)
 + dev_err(host-dev, pinctrl pbias_off select error\n);
 + } else if (((1  vdd) = MMC_VDD_165_195)  host-pinctrl 
 + host-pbias_1v8) {
 + ret = pinctrl_select_state(host-pinctrl, host-pbias_1v8);
 + if (ret  0)
 + dev_err(host-dev, pinctrl pbias_1v8 select error\n);
 + } else if (((1  vdd)  MMC_VDD_165_195)  host-pinctrl 
 + host-pbias_3v) {
 + ret = pinctrl_select_state(host-pinctrl, host-pbias_3v);
 + if (ret  0)
 + dev_err(host-dev, pinctrl pbias_3v select error\n);
 + }
 + usleep_range(350, 400);
 +
   return ret;
  }

Maybe add some macro for doing the if (((1  vdd) = MMC_VDD_165_195)... tests?

 @@ -1775,6 +1803,52 @@ static inline struct omap_mmc_platform_data
  }
  #endif
  
 +static int omap_hsmmc_pinctrl_init(struct omap_hsmmc_host *host)
 +{
 + int ret = 0;
 +
 + host-pinctrl = devm_pinctrl_get(host-dev);
 + if (IS_ERR(host-pinctrl)) {
 + host-pinctrl = NULL;
 + dev_warn(host-dev,
 +  pins are not configured from the driver\n);
 + return 0;
 + }
 +
 + host-mmc_init = pinctrl_lookup_state(host-pinctrl, mmc_init);
 + if (IS_ERR(host-mmc_init)) {
 + dev_vdbg(host-dev, optional: mmc_init lookup error);
 + host-mmc_init = NULL;
 + } else {
 + ret = pinctrl_select_state(host-pinctrl, host-mmc_init);
 + if (ret  0) {
 + dev_err(host-dev, pinctrl mmc_init select error\n);
 + goto err_pinctrl;
 + }
 + }
 +
 + host-pbias_off = pinctrl_lookup_state(host-pinctrl, pbias_off);
 + if (IS_ERR(host-pbias_off)) {
 + dev_vdbg(host-dev, optional: pbias_off lookup error);
 + host-pbias_off = NULL;
 + }
 +
 + host-pbias_1v8 = pinctrl_lookup_state(host-pinctrl, pbias_1v8);
 + if (IS_ERR(host-pbias_1v8)) {
 + dev_vdbg(host-dev, optional: pbias_1v8 lookup error);
 + host-pbias_1v8 = NULL;
 + }
 +
 + host-pbias_3v = pinctrl_lookup_state(host-pinctrl, pbias_3v);
 + if (IS_ERR(host-pbias_3v)) {
 + dev_vdbg(host-dev, optional: pbias_3v lookup error);
 + host-pbias_3v = NULL;
 + }
 +
 +err_pinctrl:
 + return ret;
 +}

Linus W may have some comments on this, although this is not the standard
muxing stuff. The 

Re: [PATCH v2 02/10] mmc: omap_hsmmc: make vcc and vcc_aux independent

2013-06-12 Thread Tony Lindgren
* Balaji T K balaj...@ti.com [130612 07:39]:
 On Wednesday 12 June 2013 07:55 PM, Tony Lindgren wrote:
 * Balaji T K balaj...@ti.com [130606 12:20]:
 handle vcc and vcc_aux independently
 
 Signed-off-by: Balaji T K balaj...@ti.com
 ---
   drivers/mmc/host/omap_hsmmc.c |9 +
   1 files changed, 5 insertions(+), 4 deletions(-)
 
 diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
 index 1865321..bda1a42 100644
 --- a/drivers/mmc/host/omap_hsmmc.c
 +++ b/drivers/mmc/host/omap_hsmmc.c
 @@ -253,7 +253,7 @@ static int omap_hsmmc_set_power(struct device *dev, int 
 slot, int power_on,
  * If we don't see a Vcc regulator, assume it's a fixed
  * voltage always-on regulator.
  */
 -   if (!host-vcc)
 +   if (!host-vcc  !host-vcc_aux)
 return 0;
 /*
  * With DT, never turn OFF the regulator for MMC1. This is because
 
 Doesn't the above change break MMC for most boards that only pass
 one regulator and no aux regulator?
 
 
 No, I want to skip regulator operation in set_power function iff both
 regulator are not present.
 
 Earlier vcc was assumed/mandatory if vcc_aux is present.
 Now, regulator operation will be handled if either one of vcc/vcc_aux is 
 present,

Ah OK yes sorry I misread your patch.

Regards,

Tony
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: am335x: TSC ADC reworking including DT pieces, take 4

2013-06-12 Thread Samuel Ortiz
On Wed, Jun 12, 2013 at 04:02:00PM +0200, Sebastian Andrzej Siewior wrote:
  By keep the regmap code you mean I am allowed to remove the regmap
  usage in mfd (keep patch #1) or do you insist on adding its usage in
  iio and input?
  I insist on keeping it on the MFD driver, i.e. _not_ keeping patch #1.
 
 This forces me redo a few things and most likely adding it to the
 iio and input driver to be consistent here.
I'm not asking for that. The current MFD code uses regmap fine without
the iio and input using it, I don't see why you would have to add regmap
support there.

 Could you please give a reason why using the regmap here is a good
 thing? I mentioned a few why it is not and why is better to leave it
 out.
Yes, and I'm not convinced obviously. regmap prevents you from open
coding your MMIO access, and this is the right approach.

Cheers,
Samuel.

-- 
Intel Open Source Technology Centre
http://oss.intel.com/
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: am335x: TSC ADC reworking including DT pieces, take 4

2013-06-12 Thread Sebastian Andrzej Siewior
On 06/12/2013 04:41 PM, Samuel Ortiz wrote:
 This forces me redo a few things and most likely adding it to the
 iio and input driver to be consistent here.
 I'm not asking for that. The current MFD code uses regmap fine without
 the iio and input using it, I don't see why you would have to add regmap
 support there.

Right. Since no reg-cache is used then this should be fine then.

 Could you please give a reason why using the regmap here is a good
 thing? I mentioned a few why it is not and why is better to leave it
 out.
 Yes, and I'm not convinced obviously. regmap prevents you from open
 coding your MMIO access, and this is the right approach.

I am not convinced that adding another layer of indirection for doing
the same thing is a good approach. Pointer chasing _is_ expensive.
_None_ of the regmap features are used here.
I would understand if I would re-implement register caching or a
wrapper across multiple buses but nothing of this is the case.
The current code even ignores the return value.

So, are we going to convert all drivers to use regmap now?

 Cheers,
 Samuel.
 

Sebastian
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH 2/3] USB: OMAP: add omap-otg

2013-06-12 Thread Felipe Balbi
Hi,

On Mon, Jun 10, 2013 at 01:40:05AM +0300, Aaro Koskinen wrote:
 +void omap_otg_set_mode(enum omap_otg_mode mode)
 +{
 + if (!otg_dev) {
 + WARN(1, %s: controller not present\n, __func__);
 + return;
 + }
 + mutex_lock(otg_dev-serialize);
 + switch (mode) {
 + case OMAP_OTG_MODE_DEVICE:
 + /*
 +  * Set B-session valid.
 +  */
 + omap_otg_ctrl(OMAP_OTG_ID | OMAP_OTG_BSESSVLD);
 + break;
 + case OMAP_OTG_MODE_HOST:
 + /*
 +  * Set A-session valid.
 +  */
 + omap_otg_ctrl(OMAP_OTG_ASESSVLD);
 + break;
 + case OMAP_OTG_MODE_DISCONNECT:
 + /*
 +  * Set B-session end to indicate no VBUS.
 +  */
 + omap_otg_ctrl(OMAP_OTG_ID | OMAP_OTG_BSESSEND);
 + break;
 + default:
 + WARN(1, %s: unknown mode: %d\n, __func__, mode);
 + }
 + mutex_unlock(otg_dev-serialize);
 +}
 +EXPORT_SYMBOL_GPL(omap_otg_set_mode);

looks like this should provide a extcon interface for its users.

-- 
balbi


signature.asc
Description: Digital signature


Re: [PATCH v2 2/2] PM / AVS: SmartReflex/class3: Fix order of initialization of SR class and SR driver

2013-06-12 Thread Andrii Tseglytskyi

On 06/12/2013 04:32 PM, Tony Lindgren wrote:

* Kevin Hilman khil...@linaro.org [130610 10:58]:

Andrii Tseglytskyi andrii.tseglyts...@ti.com writes:


SmartReflex consists of three entities: SR device, SR class and
SR driver. SmartReflex driver depends on SmartReflex class, but
order of their initialization is not clear. They both use
late_initcall(), and order depends on Makefile calls.
Patch moves initialization of SR class to device_initcall(),
and removes redundant call of sr_late_init().

This provides predictable order of SmartReflex initcalls:
1. device_initcall() - SmartReflex class init
2. late_initcall() - SmartReflex driver init

Signed-off-by: Andrii Tseglytskyi andrii.tseglyts...@ti.com

Tony will have to decide on whether he's OK with the initcall changes.

I can queue this with the rest of the AVS changes with Tony's ack.

I'd rather not make anything earlier, relying on the Makefile is just
fine here. These pieces are always compiled in too. The reason why
we should only minimal things initialized earlier than module_init
is that this way we have a proper console initialized and see real
error messages without having to have DEBUG_LL + earlyprintk enabled.

If anything else is needed, you have have just one late_initcall
that checks the return values of the various SR related init functions
to make sure all the dependencies are met.

Regards,

Tony
  


Hi Tony,

Thank you for your comment - it sounds reasonable.
Patch can be dropped from this patch series.

Regards,
Andrii


--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH v2 2/2] spi: omap2-mcspi: Add FIFO buffer support

2013-06-12 Thread Mark Brown
On Tue, Jun 11, 2013 at 08:09:15PM +0300, Illia Smyrnov wrote:
 The MCSPI controller has a built-in FIFO buffer to unload the DMA or interrupt
 handler and improve data throughput. This patch adds FIFO buffer support for 
 SPI
 transfers in DMA mode.

 The FIFO could be enabled for SPI module by setting up the 
 ti,spi-fifo-enabled
 configuration parameter in DT.
 If FIFO enabled, the largest possible FIFO buffer size will be calculated and
 setup for each SPI transfer. Even if the FIFO is enabled in DT, it won't be 
 used
 for the SPI transfers when: calculated FIFO buffer size is less then 2 bytes 
 or
 the FIFO buffer size isn't multiple of the SPI word length.

Why is the default to disable the FIFO?


signature.asc
Description: Digital signature


Re: [PATCH v4] ARM: dts: OMAP5: Add palmas MFD node and regulator nodes

2013-06-12 Thread Stephen Warren
On 06/12/2013 02:19 AM, J Keerthy wrote:
 This patch adds Palmas MFD node and the regulator nodes for OMAP5.
 
 The node definitions are based on: https://lkml.org/lkml/2013/6/6/25
 
 Boot tested on omap5-uevm board.

Reviewed-by: Stephen Warren swar...@nvidia.com

 diff --git a/arch/arm/boot/dts/omap5-uevm.dts 
 b/arch/arm/boot/dts/omap5-uevm.dts

 + palmas: palmas@48 {
 + reg = 0x48;
 + interrupts = GIC_SPI 7 IRQ_TYPE_LEVEL_HIGH; /* IRQ_SYS_1N */
 + interrupt-parent = gic;
 + compatible = ti,palmas;

... although personally I prefer the compatible property to be right at
the top of each node, since it's what implies the schema for the rest of
the node. That's a tiny nit though; feel free to ignore it if the OMAP
files don't follow that convention.
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH 2/4] ARM: dts: AM33XX: Add PWMSS device tree nodes

2013-06-12 Thread Sebastian Andrzej Siewior
On 06/06/2013 03:52 PM, Sebastian Andrzej Siewior wrote:
 From: Philip Avinash avinashphi...@ti.com
 
 Add PWMSS device tree nodes in relation with ECAP  EHRPWM DT nodes to
 AM33XX SoC family. Also populates device tree nodes for ECAP  EHRPWM by
 adding necessary properties like pwm-cells, base reg  set disabled as
 status.
 
 Signed-off-by: Philip Avinash avinashphi...@ti.com
 Reviewed-by: Thierry Reding thierry.red...@avionic-design.de
 Signed-off-by: Sebastian Andrzej Siewior bige...@linutronix.de

Can someone please grab #2 till #4? Paul took just #1 as far as I can
tell.

Sebastian
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH] ARM: dts: Protect pinctrl headers against multiple inclusions

2013-06-12 Thread Cousson, Benoit

Hi Florian,

On 6/12/2013 8:42 AM, Florian Vaussard wrote:

Hello Grant,

On 06/11/2013 11:57 PM, Grant Likely wrote:

On Tue, 11 Jun 2013 16:50:50 +0200, Florian Vaussard
florian.vauss...@epfl.ch wrote:

Pinctrl headers were not protected with #ifndef.

Signed-off-by: Florian Vaussard florian.vauss...@epfl.ch


Obviously this needs to go in via whatever tree added the modified
header files.



I authored these files, sorry for this stupid omission. Benoit, can you
take this patch?


Yes, sure, I'll take it with Grant's ack.

Benoit



Regards,

Florian


Acked-by: Grant Likely grant.lik...@secretlab.ca


---
  include/dt-bindings/pinctrl/am33xx.h |5 +
  include/dt-bindings/pinctrl/omap.h   |5 +
  2 files changed, 10 insertions(+), 0 deletions(-)

diff --git a/include/dt-bindings/pinctrl/am33xx.h
b/include/dt-bindings/pinctrl/am33xx.h
index a3fddd4..469e032 100644
--- a/include/dt-bindings/pinctrl/am33xx.h
+++ b/include/dt-bindings/pinctrl/am33xx.h
@@ -2,6 +2,9 @@
   * This header provides constants specific to AM33XX pinctrl bindings.
   */

+#ifndef _DT_BINDINGS_PINCTRL_AM33XX_H
+#define _DT_BINDINGS_PINCTRL_AM33XX_H
+
  #include include/dt-bindings/pinctrl/omap.h

  /* am33xx specific mux bit defines */
@@ -35,3 +38,5 @@
  #undef PIN_OFF_INPUT_PULLDOWN
  #undef PIN_OFF_WAKEUPENABLE

+#endif
+
diff --git a/include/dt-bindings/pinctrl/omap.h
b/include/dt-bindings/pinctrl/omap.h
index 370df3f..edbd250 100644
--- a/include/dt-bindings/pinctrl/omap.h
+++ b/include/dt-bindings/pinctrl/omap.h
@@ -5,6 +5,9 @@
   * Copyright (C) 2009-2010 Texas Instruments
   */

+#ifndef _DT_BINDINGS_PINCTRL_OMAP_H
+#define _DT_BINDINGS_PINCTRL_OMAP_H
+
  /* 34xx mux mode options for each pin. See TRM for options */
  #define MUX_MODE00
  #define MUX_MODE11
@@ -48,3 +51,5 @@
  #define PIN_OFF_INPUT_PULLDOWN(OFF_EN | OFF_PULL_EN)
  #define PIN_OFF_WAKEUPENABLEWAKEUP_EN

+#endif
+
--
1.7.5.4

___
devicetree-discuss mailing list
devicetree-disc...@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss






--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH 2/6] ARM: OMAP2+: Remove board-omap4panda.c

2013-06-12 Thread Tony Lindgren
* Ming Lei tom.leim...@gmail.com [130603 08:34]:
 Hi,
 
 On Sat, May 18, 2013 at 3:17 AM, Tony Lindgren t...@atomide.com wrote:
  We can now boot with device tree. If you don't want to update u-boot,
  you can boot with appended DTB with the following instructions:
 
  1. Make sure you have the appended DTB support in .config
 
 CONFIG_ARM_APPENDED_DTB=y
 CONFIG_ARM_ATAG_DTB_COMPAT=y
 CONFIG_ARM_ATAG_DTB_COMPAT_CMDLINE_EXTEND=y
 
  2. Build the zImage
 
 $ ARCH=arm CROSS_COMPILE=... make zImage
 
  3. Build the device tree blobs
 
 $ ARCH=arm CROSS_COMPILE=... make dtbs
 
  4. Append the correct panda dtb to zImage
 
 Depending on your hardware it's omap4-panda.dtb, omap4-panda-a4.dtb
 or omap4-panda-es.dtb.
 
 $ cat arch/arm/boot/zImage arch/arm/boot/dts/omap4-panda-es.dtb  
  /tmp/appended
 
  5. Use mkimage to produce the appended device tree uImage
 
 $ mkimage -A arm -O linux -T kernel -C none -a 0x80008000 -e 0x80008000 \
   -n Linux -d /tmp/appended /tmp/uImage
 
 I followed the above steps and tried devicetree on Pandaboard against
 3.10.0-rc3-next-20130528, and the board will hang during boot, but works
 well with legacy mode.
 
  Hardware: Pandaboard A1
  dtb: omap4-panda.dtb
 
 See 'dmesg' on below link:
 
  http://kernel.ubuntu.com/~ming/up/panda-dts.dmesg
 

Hmm looks like it boots to init. Maybe add initcall_debug to the cmdline in
case there's some late_initcall that causes the issue. It's probably some
trivial issue causing it.

Regards,

Tony
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH 2/4] ARM: dts: AM33XX: Add PWMSS device tree nodes

2013-06-12 Thread Felipe Balbi
Hi,

On Wed, Jun 12, 2013 at 06:10:32PM +0200, Sebastian Andrzej Siewior wrote:
 On 06/06/2013 03:52 PM, Sebastian Andrzej Siewior wrote:
  From: Philip Avinash avinashphi...@ti.com
  
  Add PWMSS device tree nodes in relation with ECAP  EHRPWM DT nodes to
  AM33XX SoC family. Also populates device tree nodes for ECAP  EHRPWM by
  adding necessary properties like pwm-cells, base reg  set disabled as
  status.
  
  Signed-off-by: Philip Avinash avinashphi...@ti.com
  Reviewed-by: Thierry Reding thierry.red...@avionic-design.de
  Signed-off-by: Sebastian Andrzej Siewior bige...@linutronix.de
 
 Can someone please grab #2 till #4? Paul took just #1 as far as I can
 tell.

DTS should be Benoit Cousson

-- 
balbi


signature.asc
Description: Digital signature


Re: [PATCH 1/2] ARM: OMAP2+: gpmc: get number of useable GPMC chip-selects via DT

2013-06-12 Thread Tony Lindgren
* Gupta, Pekon pe...@ti.com [130531 05:07]:
 From: Gupta, Pekon pe...@ti.com
 
 This patch enables usage of DT property 'gpmc,num-cs' as already documented in
 Documentation/devicetree/bindings/bus/ti-gpmc.txt
 
 Though GPMC hardware supports upto 8 chip-selects, but all chip-selects may
 not be available for use because:
 - chip-select pin may not be bonded out at SoC device boundary.
 - chip-select pin-mux may conflict with other pins usage.
 - board level constrains.
 
 gpmc,num-cs allows user to configure maximum number of GPMC chip-selects
 available for use on any given platform. This ensures:
 - GPMC child nodes having chip-selects within allowed range are only probed.
 - And un-used GPMC chip-selects remain blocked.(may be for security reasons).

Thanks applying this patch into omap-for-v3.11/gpmc.

Regards,

Tony
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


am335x: TSC ADC reworking including DT pieces, take 5

2013-06-12 Thread Sebastian Andrzej Siewior
Hi Samuel,

I did the cosmetic changes of the subject line and removed the changes
from within the sob lines in each patch. I dropped the #define XPP
STEPCONFIG_XPP thingy and patch #1 which removed regmap from mfd. Not
that I agree with it, I just do not want to miss the merge window due to
this.

The following changes since commit d683b96b072dc4680fc74964eca77e6a23d1fa6e:

  Linux 3.10-rc4 (2013-06-02 17:11:17 +0900)

are available in the git repository at:

  git://breakpoint.cc/bigeasy/linux tags/am335x_tsc-adc

for you to fetch changes up to 1460c152c53335b5403045d056502eda1204c33a:

  iio: ti_am335x_adc: check if we found the value (2013-06-12 18:50:23 +0200)


A complete refurbished series inclunding:
- DT support for the MFD, TSC and ADC driver  platform device support,
  which has no users, has been killed.
- iio_map from last series is gone and replaced by proper nodes in the
  device tree.
- suspend fixes which means correct data structs are taken and no
  interrupt storm
- fifo split which should problem with TSC  ADC beeing used at the same
  time
- The ADC channels are now checked before blindly applied. That means the
  touch part reads X, Y and Z coordinates and does not mix them up. Same
  goes for the IIO ADC driver.
- The IIO ADC driver now creates files named in_voltageX_raw where X
  represents the ADC line instead of a number starting at 0. A read from
  this file can return -EBUSY in case touch is busy and the ADC didn't
  collect a value.


Pantelis Antoniou (2):
  iio: ti_tscadc: provide datasheet_name and scan_type
  mfd: ti_tscadc: deal with partial activation

Patil, Rachna (7):
  input: ti_am33x_tsc: Step enable bits made configurable
  input: ti_am33x_tsc: Order of TSC wires, made configurable
  input: ti_am33x_tsc: remove unwanted fifo flush
  input: ti_am33x_tsc: Add DT support
  iio: ti_am335x_adc: Add DT support
  mfd: ti_am335x_tscadc: Add DT support
  arm: am33xx: add TSC/ADC mfd device support

Sebastian Andrzej Siewior (12):
  mfd: input: iio: ti_am335x_adc: use one structure for ti_tscadc_dev
  input: ti_am33x_tsc: remove platform_data support
  iio: ti_am335x_adc: remove platform_data support
  mfd: ti_am335x_tscadc: remove platform_data support
  input: mfd: ti_am335x_tsc remove remaining platform data pieces
  mfd: input: ti_am335x_tsc: rename device from tsc to TI-am335x-tsc
  mfd: iio: ti_am335x_adc: rename device from tiadc to TI-am335x-adc
  input: ti_am335x_adc: use only FIFO0 and clean up a little
  input: ti_am335x_tsc: ACK the HW_PEN irq in ISR
  input: ti_am335x_tsc: return IRQ_NONE if there was no IRQ for us
  iio: ti_am335x_adc: Allow to specify input line
  iio: ti_am335x_adc: check if we found the value

 .../bindings/input/touchscreen/ti-tsc-adc.txt  |   44 +++
 arch/arm/boot/dts/am335x-evm.dts   |   14 +
 arch/arm/boot/dts/am33xx.dtsi  |   18 ++
 drivers/iio/adc/ti_am335x_adc.c|  132 ++---
 drivers/input/touchscreen/ti_am335x_tsc.c  |  288 ++--
 drivers/mfd/ti_am335x_tscadc.c |  112 ++--
 include/linux/input/ti_am335x_tsc.h|   23 --
 include/linux/mfd/ti_am335x_tscadc.h   |   35 +--
 include/linux/platform_data/ti_am335x_adc.h|   14 -
 9 files changed, 486 insertions(+), 194 deletions(-)
 create mode 100644 
Documentation/devicetree/bindings/input/touchscreen/ti-tsc-adc.txt
 delete mode 100644 include/linux/input/ti_am335x_tsc.h
 delete mode 100644 include/linux/platform_data/ti_am335x_adc.h

Sebastian

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH 08/21] iio: ti_am335x_adc: remove platform_data support

2013-06-12 Thread Sebastian Andrzej Siewior
This patch removes access to platform data mfd_tscadc_board because the
platform is DT only.

Acked-by: Jonathan Cameron ji...@kernel.org
Signed-off-by: Sebastian Andrzej Siewior bige...@linutronix.de
---
 drivers/iio/adc/ti_am335x_adc.c |   21 +++--
 1 file changed, 7 insertions(+), 14 deletions(-)

diff --git a/drivers/iio/adc/ti_am335x_adc.c b/drivers/iio/adc/ti_am335x_adc.c
index b24402c..2868c0c 100644
--- a/drivers/iio/adc/ti_am335x_adc.c
+++ b/drivers/iio/adc/ti_am335x_adc.c
@@ -26,7 +26,6 @@
 #include linux/of_device.h
 
 #include linux/mfd/ti_am335x_tscadc.h
-#include linux/platform_data/ti_am335x_adc.h
 
 struct tiadc_device {
struct ti_tscadc_dev *mfd_tscadc;
@@ -153,14 +152,12 @@ static int tiadc_probe(struct platform_device *pdev)
 {
struct iio_dev  *indio_dev;
struct tiadc_device *adc_dev;
-   struct ti_tscadc_dev*tscadc_dev = ti_tscadc_dev_get(pdev);
-   struct mfd_tscadc_board *pdata = tscadc_dev-dev-platform_data;
struct device_node  *node = pdev-dev.of_node;
int err;
u32 val32;
 
-   if (!pdata  !node) {
-   dev_err(pdev-dev, Could not find platform data\n);
+   if (!node) {
+   dev_err(pdev-dev, Could not find valid DT data.\n);
return -EINVAL;
}
 
@@ -174,15 +171,11 @@ static int tiadc_probe(struct platform_device *pdev)
 
adc_dev-mfd_tscadc = ti_tscadc_dev_get(pdev);
 
-   if (pdata)
-   adc_dev-channels = pdata-adc_init-adc_channels;
-   else {
-   err = of_property_read_u32(node,
-   ti,adc-channels, val32);
-   if (err  0)
-   goto err_free_device;
-   adc_dev-channels = val32;
-   }
+   err = of_property_read_u32(node,
+   ti,adc-channels, val32);
+   if (err  0)
+   goto err_free_device;
+   adc_dev-channels = val32;
 
indio_dev-dev.parent = pdev-dev;
indio_dev-name = dev_name(pdev-dev);
-- 
1.7.10.4

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH 2/2] ARM: OMAP2+: gpmc: removed 'gpmc,device-nand'. type determined from node-name

2013-06-12 Thread Tony Lindgren
* Gupta, Pekon pe...@ti.com [130531 05:07]:
 From: Gupta, Pekon pe...@ti.com
 
 GPMC supports multiple types of child devices like NAND, NOR, OneNand, 
 Ethernet
 This patch removes 'gpmc,device-nand', used explicitely to specify NAND type
 gpmc-child. Instead gpmc-child type can be inferred from gpmc-child-name.

This does not seem to apply. Also please break into a gpmc.c patch and
then the .dts patch for Benoit. And make sure you consider if removing
this binding might break something. If it does, we need to maintain the
support for the old binding.

Regards,

Tony
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH 06/21] input: ti_am33x_tsc: remove platform_data support

2013-06-12 Thread Sebastian Andrzej Siewior
This patch removes access to platform data mfd_tscadc_board because the
platform is DT only.

Acked-by: Dmitry Torokhov dmitry.torok...@gmail.com
Signed-off-by: Sebastian Andrzej Siewior bige...@linutronix.de
---
 drivers/input/touchscreen/ti_am335x_tsc.c |   25 +
 1 file changed, 1 insertion(+), 24 deletions(-)

diff --git a/drivers/input/touchscreen/ti_am335x_tsc.c 
b/drivers/input/touchscreen/ti_am335x_tsc.c
index 449c0fb..a1db55d 100644
--- a/drivers/input/touchscreen/ti_am335x_tsc.c
+++ b/drivers/input/touchscreen/ti_am335x_tsc.c
@@ -24,7 +24,6 @@
 #include linux/clk.h
 #include linux/platform_device.h
 #include linux/io.h
-#include linux/input/ti_am335x_tsc.h
 #include linux/delay.h
 #include linux/of.h
 #include linux/of_device.h
@@ -347,24 +346,6 @@ static int titsc_parse_dt(struct platform_device *pdev,
ts_dev-config_inp, ARRAY_SIZE(ts_dev-config_inp));
 }
 
-static int titsc_parse_pdata(struct ti_tscadc_dev *tscadc_dev,
-   struct titsc *ts_dev)
-{
-   struct mfd_tscadc_board *pdata = tscadc_dev-dev-platform_data;
-
-   if (!pdata)
-   return -EINVAL;
-
-   ts_dev-wires = pdata-tsc_init-wires;
-   ts_dev-x_plate_resistance =
-   pdata-tsc_init-x_plate_resistance;
-   ts_dev-steps_to_configure =
-   pdata-tsc_init-steps_to_configure;
-   memcpy(ts_dev-config_inp, pdata-tsc_init-wire_config,
-   sizeof(pdata-tsc_init-wire_config));
-   return 0;
-}
-
 /*
  * The functions for inserting/removing driver as a module.
  */
@@ -390,11 +371,7 @@ static int titsc_probe(struct platform_device *pdev)
ts_dev-input = input_dev;
ts_dev-irq = tscadc_dev-irq;
 
-   if (tscadc_dev-dev-platform_data)
-   err = titsc_parse_pdata(tscadc_dev, ts_dev);
-   else
-   err = titsc_parse_dt(pdev, ts_dev);
-
+   err = titsc_parse_dt(pdev, ts_dev);
if (err) {
dev_err(pdev-dev, Could not find valid DT data.\n);
goto err_free_mem;
-- 
1.7.10.4

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH 03/21] input: ti_am33x_tsc: Order of TSC wires, made configurable

2013-06-12 Thread Sebastian Andrzej Siewior
From: Patil, Rachna rac...@ti.com

The current driver expected touchscreen input
wires(XP,XN,YP,YN) to be connected in a particular order.
Making changes to accept this as platform data.

Sebastian reworked the original patch and removed a lot of the not
required pieces.

Signed-off-by: Patil, Rachna rac...@ti.com
Signed-off-by: Felipe Balbi ba...@ti.com
Signed-off-by: Sebastian Andrzej Siewior bige...@linutronix.de
---
 drivers/input/touchscreen/ti_am335x_tsc.c |  102 -
 include/linux/input/ti_am335x_tsc.h   |   12 
 include/linux/mfd/ti_am335x_tscadc.h  |3 -
 3 files changed, 98 insertions(+), 19 deletions(-)

diff --git a/drivers/input/touchscreen/ti_am335x_tsc.c 
b/drivers/input/touchscreen/ti_am335x_tsc.c
index 23d6a4d..2bdd66c 100644
--- a/drivers/input/touchscreen/ti_am335x_tsc.c
+++ b/drivers/input/touchscreen/ti_am335x_tsc.c
@@ -33,6 +33,13 @@
 #define SEQ_SETTLE 275
 #define MAX_12BIT  ((1  12) - 1)
 
+static const int config_pins[] = {
+   STEPCONFIG_XPP,
+   STEPCONFIG_XNN,
+   STEPCONFIG_YPP,
+   STEPCONFIG_YNN,
+};
+
 struct titsc {
struct input_dev*input;
struct ti_tscadc_dev*mfd_tscadc;
@@ -41,6 +48,9 @@ struct titsc {
unsigned intx_plate_resistance;
boolpen_down;
int steps_to_configure;
+   u32 config_inp[4];
+   u32 bit_xp, bit_xn, bit_yp, bit_yn;
+   u32 inp_xp, inp_xn, inp_yp, inp_yn;
 };
 
 static unsigned int titsc_readl(struct titsc *ts, unsigned int reg)
@@ -54,6 +64,58 @@ static void titsc_writel(struct titsc *tsc, unsigned int reg,
writel(val, tsc-mfd_tscadc-tscadc_base + reg);
 }
 
+static int titsc_config_wires(struct titsc *ts_dev)
+{
+   u32 analog_line[4];
+   u32 wire_order[4];
+   int i, bit_cfg;
+
+   for (i = 0; i  4; i++) {
+   /*
+* Get the order in which TSC wires are attached
+* w.r.t. each of the analog input lines on the EVM.
+*/
+   analog_line[i] = (ts_dev-config_inp[i]  0xF0)  4;
+   wire_order[i] = ts_dev-config_inp[i]  0x0F;
+   if (WARN_ON(analog_line[i]  7))
+   return -EINVAL;
+   if (WARN_ON(wire_order[i]  ARRAY_SIZE(config_pins)))
+   return -EINVAL;
+   }
+
+   for (i = 0; i  4; i++) {
+   int an_line;
+   int wi_order;
+
+   an_line = analog_line[i];
+   wi_order = wire_order[i];
+   bit_cfg = config_pins[wi_order];
+   if (bit_cfg == 0)
+   return -EINVAL;
+   switch (wi_order) {
+   case 0:
+   ts_dev-bit_xp = bit_cfg;
+   ts_dev-inp_xp = an_line;
+   break;
+
+   case 1:
+   ts_dev-bit_xn = bit_cfg;
+   ts_dev-inp_xn = an_line;
+   break;
+
+   case 2:
+   ts_dev-bit_yp = bit_cfg;
+   ts_dev-inp_yp = an_line;
+   break;
+   case 3:
+   ts_dev-bit_yn = bit_cfg;
+   ts_dev-inp_yn = an_line;
+   break;
+   }
+   }
+   return 0;
+}
+
 static void titsc_step_config(struct titsc *ts_dev)
 {
unsigned intconfig;
@@ -64,18 +126,18 @@ static void titsc_step_config(struct titsc *ts_dev)
total_steps = 2 * ts_dev-steps_to_configure;
 
config = STEPCONFIG_MODE_HWSYNC |
-   STEPCONFIG_AVG_16 | STEPCONFIG_XPP;
+   STEPCONFIG_AVG_16 | ts_dev-bit_xp;
switch (ts_dev-wires) {
case 4:
-   config |= STEPCONFIG_INP_AN2 | STEPCONFIG_XNN;
+   config |= STEPCONFIG_INP(ts_dev-inp_yp) | ts_dev-bit_xn;
break;
case 5:
-   config |= STEPCONFIG_YNN |
-   STEPCONFIG_INP_AN4 | STEPCONFIG_XNN |
-   STEPCONFIG_YPP;
+   config |= ts_dev-bit_yn |
+   STEPCONFIG_INP_AN4 | ts_dev-bit_xn |
+   ts_dev-bit_yp;
break;
case 8:
-   config |= STEPCONFIG_INP_AN2 | STEPCONFIG_XNN;
+   config |= STEPCONFIG_INP(ts_dev-inp_yp) | ts_dev-bit_xn;
break;
}
 
@@ -86,18 +148,18 @@ static void titsc_step_config(struct titsc *ts_dev)
 
config = 0;
config = STEPCONFIG_MODE_HWSYNC |
-   STEPCONFIG_AVG_16 | STEPCONFIG_YNN |
+   STEPCONFIG_AVG_16 | ts_dev-bit_yn |
STEPCONFIG_INM_ADCREFM | STEPCONFIG_FIFO1;
switch (ts_dev-wires) {
case 4:
-

[PATCH 09/21] mfd: ti_am335x_tscadc: Add DT support

2013-06-12 Thread Sebastian Andrzej Siewior
From: Patil, Rachna rac...@ti.com

Add DT support in the MFD core driver. The node name is am3359 because
it was tested on this platform.

Signed-off-by: Pantelis Antoniou pa...@antoniou-consulting.com
Signed-off-by: Patil, Rachna rac...@ti.com
Signed-off-by: Felipe Balbi ba...@ti.com
Signed-off-by: Sebastian Andrzej Siewior bige...@linutronix.de
---
 drivers/mfd/ti_am335x_tscadc.c |   32 ++--
 1 file changed, 26 insertions(+), 6 deletions(-)

diff --git a/drivers/mfd/ti_am335x_tscadc.c b/drivers/mfd/ti_am335x_tscadc.c
index 1d6c740..292d34e 100644
--- a/drivers/mfd/ti_am335x_tscadc.c
+++ b/drivers/mfd/ti_am335x_tscadc.c
@@ -22,6 +22,8 @@
 #include linux/regmap.h
 #include linux/mfd/core.h
 #include linux/pm_runtime.h
+#include linux/of.h
+#include linux/of_device.h
 
 #include linux/mfd/ti_am335x_tscadc.h
 #include linux/input/ti_am335x_tsc.h
@@ -90,20 +92,31 @@ static  int ti_tscadc_probe(struct platform_device 
*pdev)
struct resource *res;
struct clk  *clk;
struct mfd_tscadc_board *pdata = pdev-dev.platform_data;
+   struct device_node  *node = pdev-dev.of_node;
struct mfd_cell *cell;
int err, ctrl;
int clk_value, clock_rate;
-   int tsc_wires, adc_channels = 0, total_channels;
+   int tsc_wires = 0, adc_channels = 0, total_channels;
 
-   if (!pdata) {
+   if (!pdata  !pdev-dev.of_node) {
dev_err(pdev-dev, Could not find platform data\n);
return -EINVAL;
}
 
-   if (pdata-adc_init)
-   adc_channels = pdata-adc_init-adc_channels;
+   if (pdev-dev.platform_data) {
+   if (pdata-tsc_init)
+   tsc_wires = pdata-tsc_init-wires;
+
+   if (pdata-adc_init)
+   adc_channels = pdata-adc_init-adc_channels;
+   } else {
+   node = of_get_child_by_name(pdev-dev.of_node, tsc);
+   of_property_read_u32(node, ti,wires, tsc_wires);
+
+   node = of_get_child_by_name(pdev-dev.of_node, adc);
+   of_property_read_u32(node, ti,adc-channels, adc_channels);
+   }
 
-   tsc_wires = pdata-tsc_init-wires;
total_channels = tsc_wires + adc_channels;
 
if (total_channels  8) {
@@ -285,11 +298,18 @@ static const struct dev_pm_ops tscadc_pm_ops = {
 #define TSCADC_PM_OPS NULL
 #endif
 
+static const struct of_device_id ti_tscadc_dt_ids[] = {
+   { .compatible = ti,am3359-tscadc, },
+   { }
+};
+MODULE_DEVICE_TABLE(of, ti_tscadc_dt_ids);
+
 static struct platform_driver ti_tscadc_driver = {
.driver = {
-   .name   = ti_tscadc,
+   .name   = ti_am3359-tscadc,
.owner  = THIS_MODULE,
.pm = TSCADC_PM_OPS,
+   .of_match_table = of_match_ptr(ti_tscadc_dt_ids),
},
.probe  = ti_tscadc_probe,
.remove = ti_tscadc_remove,
-- 
1.7.10.4

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH 07/21] iio: ti_am335x_adc: Add DT support

2013-06-12 Thread Sebastian Andrzej Siewior
From: Patil, Rachna rac...@ti.com

Add DT support for client ADC driver.

Acked-by: Jonathan Cameron ji...@kernel.org
Signed-off-by: Patil, Rachna rac...@ti.com
Signed-off-by: Pantelis Antoniou pa...@antoniou-consulting.com
Signed-off-by: Felipe Balbi ba...@ti.com
Signed-off-by: Sebastian Andrzej Siewior bige...@linutronix.de
---
 drivers/iio/adc/ti_am335x_adc.c |   29 -
 drivers/mfd/ti_am335x_tscadc.c  |1 +
 2 files changed, 25 insertions(+), 5 deletions(-)

diff --git a/drivers/iio/adc/ti_am335x_adc.c b/drivers/iio/adc/ti_am335x_adc.c
index 543b9c4..b24402c 100644
--- a/drivers/iio/adc/ti_am335x_adc.c
+++ b/drivers/iio/adc/ti_am335x_adc.c
@@ -22,6 +22,8 @@
 #include linux/platform_device.h
 #include linux/io.h
 #include linux/iio/iio.h
+#include linux/of.h
+#include linux/of_device.h
 
 #include linux/mfd/ti_am335x_tscadc.h
 #include linux/platform_data/ti_am335x_adc.h
@@ -152,11 +154,12 @@ static int tiadc_probe(struct platform_device *pdev)
struct iio_dev  *indio_dev;
struct tiadc_device *adc_dev;
struct ti_tscadc_dev*tscadc_dev = ti_tscadc_dev_get(pdev);
-   struct mfd_tscadc_board *pdata;
+   struct mfd_tscadc_board *pdata = tscadc_dev-dev-platform_data;
+   struct device_node  *node = pdev-dev.of_node;
int err;
+   u32 val32;
 
-   pdata = tscadc_dev-dev-platform_data;
-   if (!pdata || !pdata-adc_init) {
+   if (!pdata  !node) {
dev_err(pdev-dev, Could not find platform data\n);
return -EINVAL;
}
@@ -169,8 +172,17 @@ static int tiadc_probe(struct platform_device *pdev)
}
adc_dev = iio_priv(indio_dev);
 
-   adc_dev-mfd_tscadc = tscadc_dev;
-   adc_dev-channels = pdata-adc_init-adc_channels;
+   adc_dev-mfd_tscadc = ti_tscadc_dev_get(pdev);
+
+   if (pdata)
+   adc_dev-channels = pdata-adc_init-adc_channels;
+   else {
+   err = of_property_read_u32(node,
+   ti,adc-channels, val32);
+   if (err  0)
+   goto err_free_device;
+   adc_dev-channels = val32;
+   }
 
indio_dev-dev.parent = pdev-dev;
indio_dev-name = dev_name(pdev-dev);
@@ -260,11 +272,18 @@ static const struct dev_pm_ops tiadc_pm_ops = {
 #define TIADC_PM_OPS NULL
 #endif
 
+static const struct of_device_id ti_adc_dt_ids[] = {
+   { .compatible = ti,am3359-adc, },
+   { }
+};
+MODULE_DEVICE_TABLE(of, ti_adc_dt_ids);
+
 static struct platform_driver tiadc_driver = {
.driver = {
.name   = tiadc,
.owner  = THIS_MODULE,
.pm = TIADC_PM_OPS,
+   .of_match_table = of_match_ptr(ti_adc_dt_ids),
},
.probe  = tiadc_probe,
.remove = tiadc_remove,
diff --git a/drivers/mfd/ti_am335x_tscadc.c b/drivers/mfd/ti_am335x_tscadc.c
index f509766..1d6c740 100644
--- a/drivers/mfd/ti_am335x_tscadc.c
+++ b/drivers/mfd/ti_am335x_tscadc.c
@@ -210,6 +210,7 @@ static  int ti_tscadc_probe(struct platform_device 
*pdev)
/* ADC Cell */
cell = tscadc-cells[ADC_CELL];
cell-name = tiadc;
+   cell-of_compatible = ti,am3359-adc;
cell-platform_data = tscadc;
cell-pdata_size = sizeof(tscadc);
 
-- 
1.7.10.4

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH v2 01/10] ARM: OMAP2+: add needs_vmmc to hsmmc_info

2013-06-12 Thread Balaji T K

On Wednesday 12 June 2013 07:54 PM, Tony Lindgren wrote:

* Balaji T K balaj...@ti.com [130606 12:20]:

Add needs_vmmc and needs_vmmc_aux to indicate whether regulator is
applicable so that omap_hsmmc can handle deferred probe error
properly for regulators.
Remove the assumption that vmmc_aux regulator to be available only if vmmc is
present. Platforms can have fixed-always-ON regulator for vmmc and/or vmmc_aux
in such cases regulator needed not be specified in board file.


Looks good to me, I suggest you resend this again a bit later once the
other changes are merged so we can avoid a dependency between 
arch/arm/mach-omap2
and MMC changes.



Ok, will separate the board changes and send the rest via mmc tree


Regards,

Tony


Signed-off-by: Balaji T K balaj...@ti.com
---
  arch/arm/mach-omap2/board-2430sdp.c  |1 +
  arch/arm/mach-omap2/board-3430sdp.c  |3 +++
  arch/arm/mach-omap2/board-cm-t35.c   |2 ++
  arch/arm/mach-omap2/board-devkit8000.c   |1 +
  arch/arm/mach-omap2/board-igep0020.c |3 +++
  arch/arm/mach-omap2/board-ldp.c  |1 +
  arch/arm/mach-omap2/board-omap3beagle.c  |2 ++
  arch/arm/mach-omap2/board-omap3evm.c |3 +++
  arch/arm/mach-omap2/board-omap3logic.c   |1 +
  arch/arm/mach-omap2/board-omap3pandora.c |3 +++
  arch/arm/mach-omap2/board-omap3stalker.c |2 ++
  arch/arm/mach-omap2/board-omap3touchbook.c   |2 ++
  arch/arm/mach-omap2/board-overo.c|1 +
  arch/arm/mach-omap2/board-rm680.c|1 +
  arch/arm/mach-omap2/board-rx51-peripherals.c |3 +++
  arch/arm/mach-omap2/board-zoom-peripherals.c |4 
  arch/arm/mach-omap2/hsmmc.c  |2 ++
  arch/arm/mach-omap2/hsmmc.h  |2 ++
  include/linux/platform_data/mmc-omap.h   |2 ++
  19 files changed, 39 insertions(+), 0 deletions(-)


--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH 01/21] mfd: input: iio: ti_am335x_adc: use one structure for ti_tscadc_dev

2013-06-12 Thread Sebastian Andrzej Siewior
The mfd driver creates platform data for the child devices and it is the
ti_tscadc_dev struct. This struct is copied for the two devices.
The copy of the structure makes a common lock in this structure a little
less usefull. Therefore the platform data is not a pointer to the
structure and the same structure is used.
While doing the change I noticed that the suspend/resume code assumes
the wrong pointer for ti_tscadc_dev and this has been fixed as well.

Signed-off-by: Sebastian Andrzej Siewior bige...@linutronix.de
---
 drivers/iio/adc/ti_am335x_adc.c   |5 +++--
 drivers/input/touchscreen/ti_am335x_tsc.c |   16 +---
 drivers/mfd/ti_am335x_tscadc.c|8 
 include/linux/mfd/ti_am335x_tscadc.h  |7 +++
 4 files changed, 23 insertions(+), 13 deletions(-)

diff --git a/drivers/iio/adc/ti_am335x_adc.c b/drivers/iio/adc/ti_am335x_adc.c
index 5f9a7e7..9db352e 100644
--- a/drivers/iio/adc/ti_am335x_adc.c
+++ b/drivers/iio/adc/ti_am335x_adc.c
@@ -140,7 +140,7 @@ static int tiadc_probe(struct platform_device *pdev)
 {
struct iio_dev  *indio_dev;
struct tiadc_device *adc_dev;
-   struct ti_tscadc_dev*tscadc_dev = pdev-dev.platform_data;
+   struct ti_tscadc_dev*tscadc_dev = ti_tscadc_dev_get(pdev);
struct mfd_tscadc_board *pdata;
int err;
 
@@ -205,9 +205,10 @@ static int tiadc_suspend(struct device *dev)
 {
struct iio_dev *indio_dev = dev_get_drvdata(dev);
struct tiadc_device *adc_dev = iio_priv(indio_dev);
-   struct ti_tscadc_dev *tscadc_dev = dev-platform_data;
+   struct ti_tscadc_dev *tscadc_dev;
unsigned int idle;
 
+   tscadc_dev = ti_tscadc_dev_get(to_platform_device(dev));
if (!device_may_wakeup(tscadc_dev-dev)) {
idle = tiadc_readl(adc_dev, REG_CTRL);
idle = ~(CNTRLREG_TSCSSENB);
diff --git a/drivers/input/touchscreen/ti_am335x_tsc.c 
b/drivers/input/touchscreen/ti_am335x_tsc.c
index 51e7b87..16077d3 100644
--- a/drivers/input/touchscreen/ti_am335x_tsc.c
+++ b/drivers/input/touchscreen/ti_am335x_tsc.c
@@ -262,7 +262,7 @@ static int titsc_probe(struct platform_device *pdev)
 {
struct titsc *ts_dev;
struct input_dev *input_dev;
-   struct ti_tscadc_dev *tscadc_dev = pdev-dev.platform_data;
+   struct ti_tscadc_dev *tscadc_dev = ti_tscadc_dev_get(pdev);
struct mfd_tscadc_board *pdata;
int err;
 
@@ -329,8 +329,8 @@ static int titsc_probe(struct platform_device *pdev)
 
 static int titsc_remove(struct platform_device *pdev)
 {
-   struct ti_tscadc_dev *tscadc_dev = pdev-dev.platform_data;
-   struct titsc *ts_dev = tscadc_dev-tsc;
+   struct titsc *ts_dev = platform_get_drvdata(pdev);
+   u32 steps;
 
free_irq(ts_dev-irq, ts_dev);
 
@@ -344,10 +344,11 @@ static int titsc_remove(struct platform_device *pdev)
 #ifdef CONFIG_PM
 static int titsc_suspend(struct device *dev)
 {
-   struct ti_tscadc_dev *tscadc_dev = dev-platform_data;
-   struct titsc *ts_dev = tscadc_dev-tsc;
+   struct titsc *ts_dev = dev_get_drvdata(dev);
+   struct ti_tscadc_dev *tscadc_dev;
unsigned int idle;
 
+   tscadc_dev = ti_tscadc_dev_get(to_platform_device(dev));
if (device_may_wakeup(tscadc_dev-dev)) {
idle = titsc_readl(ts_dev, REG_IRQENABLE);
titsc_writel(ts_dev, REG_IRQENABLE,
@@ -359,9 +360,10 @@ static int titsc_suspend(struct device *dev)
 
 static int titsc_resume(struct device *dev)
 {
-   struct ti_tscadc_dev *tscadc_dev = dev-platform_data;
-   struct titsc *ts_dev = tscadc_dev-tsc;
+   struct titsc *ts_dev = dev_get_drvdata(dev);
+   struct ti_tscadc_dev *tscadc_dev;
 
+   tscadc_dev = ti_tscadc_dev_get(to_platform_device(dev));
if (device_may_wakeup(tscadc_dev-dev)) {
titsc_writel(ts_dev, REG_IRQWAKEUP,
0x00);
diff --git a/drivers/mfd/ti_am335x_tscadc.c b/drivers/mfd/ti_am335x_tscadc.c
index e9f3fb5..772ea2a 100644
--- a/drivers/mfd/ti_am335x_tscadc.c
+++ b/drivers/mfd/ti_am335x_tscadc.c
@@ -176,14 +176,14 @@ staticint ti_tscadc_probe(struct platform_device 
*pdev)
/* TSC Cell */
cell = tscadc-cells[TSC_CELL];
cell-name = tsc;
-   cell-platform_data = tscadc;
-   cell-pdata_size = sizeof(*tscadc);
+   cell-platform_data = tscadc;
+   cell-pdata_size = sizeof(tscadc);
 
/* ADC Cell */
cell = tscadc-cells[ADC_CELL];
cell-name = tiadc;
-   cell-platform_data = tscadc;
-   cell-pdata_size = sizeof(*tscadc);
+   cell-platform_data = tscadc;
+   cell-pdata_size = sizeof(tscadc);
 
err = mfd_add_devices(pdev-dev, pdev-id, tscadc-cells,
TSCADC_CELLS, NULL, 0, NULL);
diff --git a/include/linux/mfd/ti_am335x_tscadc.h 
b/include/linux/mfd/ti_am335x_tscadc.h
index c79ad5d..8114e4e 100644
--- 

[PATCH 02/21] input: ti_am33x_tsc: Step enable bits made configurable

2013-06-12 Thread Sebastian Andrzej Siewior
From: Patil, Rachna rac...@ti.com

Current code has hard coded value written to
step enable bits. Now the bits are updated based
on how many steps are needed to be configured got
from platform data.

The user needs to take care not to exceed
the count more than 16. While using ADC and TSC
one should take care to set this parameter correctly.

Sebastian added the common lock and moved the code, that manipulates the
steps, from into the mfd module.

Signed-off-by: Patil, Rachna rac...@ti.com
Signed-off-by: Felipe Balbi ba...@ti.com
Signed-off-by: Sebastian Andrzej Siewior bige...@linutronix.de
---
 drivers/iio/adc/ti_am335x_adc.c   |   20 ++--
 drivers/input/touchscreen/ti_am335x_tsc.c |   12 ++--
 drivers/mfd/ti_am335x_tscadc.c|   29 -
 include/linux/mfd/ti_am335x_tscadc.h  |8 ++--
 4 files changed, 62 insertions(+), 7 deletions(-)

diff --git a/drivers/iio/adc/ti_am335x_adc.c b/drivers/iio/adc/ti_am335x_adc.c
index 9db352e..543b9c4 100644
--- a/drivers/iio/adc/ti_am335x_adc.c
+++ b/drivers/iio/adc/ti_am335x_adc.c
@@ -42,10 +42,20 @@ static void tiadc_writel(struct tiadc_device *adc, unsigned 
int reg,
writel(val, adc-mfd_tscadc-tscadc_base + reg);
 }
 
+static u32 get_adc_step_mask(struct tiadc_device *adc_dev)
+{
+   u32 step_en;
+
+   step_en = ((1  adc_dev-channels) - 1);
+   step_en = TOTAL_STEPS - adc_dev-channels + 1;
+   return step_en;
+}
+
 static void tiadc_step_config(struct tiadc_device *adc_dev)
 {
unsigned int stepconfig;
int i, channels = 0, steps;
+   u32 step_en;
 
/*
 * There are 16 configurable steps and 8 analog input
@@ -69,7 +79,8 @@ static void tiadc_step_config(struct tiadc_device *adc_dev)
STEPCONFIG_OPENDLY);
channels++;
}
-   tiadc_writel(adc_dev, REG_SE, STPENB_STEPENB);
+   step_en = get_adc_step_mask(adc_dev);
+   am335x_tsc_se_set(adc_dev-mfd_tscadc, step_en);
 }
 
 static int tiadc_channel_init(struct iio_dev *indio_dev, int channels)
@@ -127,7 +138,7 @@ static int tiadc_read_raw(struct iio_dev *indio_dev,
if (i == chan-channel)
*val = readx1  0xfff;
}
-   tiadc_writel(adc_dev, REG_SE, STPENB_STEPENB);
+   am335x_tsc_se_update(adc_dev-mfd_tscadc);
 
return IIO_VAL_INT;
 }
@@ -191,10 +202,15 @@ static int tiadc_probe(struct platform_device *pdev)
 static int tiadc_remove(struct platform_device *pdev)
 {
struct iio_dev *indio_dev = platform_get_drvdata(pdev);
+   struct tiadc_device *adc_dev = iio_priv(indio_dev);
+   u32 step_en;
 
iio_device_unregister(indio_dev);
tiadc_channels_remove(indio_dev);
 
+   step_en = get_adc_step_mask(adc_dev);
+   am335x_tsc_se_clr(adc_dev-mfd_tscadc, step_en);
+
iio_device_free(indio_dev);
 
return 0;
diff --git a/drivers/input/touchscreen/ti_am335x_tsc.c 
b/drivers/input/touchscreen/ti_am335x_tsc.c
index 16077d3..23d6a4d 100644
--- a/drivers/input/touchscreen/ti_am335x_tsc.c
+++ b/drivers/input/touchscreen/ti_am335x_tsc.c
@@ -57,6 +57,7 @@ static void titsc_writel(struct titsc *tsc, unsigned int reg,
 static void titsc_step_config(struct titsc *ts_dev)
 {
unsigned intconfig;
+   unsigned intstepenable = 0;
int i, total_steps;
 
/* Configure the Step registers */
@@ -128,7 +129,9 @@ static void titsc_step_config(struct titsc *ts_dev)
titsc_writel(ts_dev, REG_STEPDELAY(total_steps + 2),
STEPCONFIG_OPENDLY);
 
-   titsc_writel(ts_dev, REG_SE, STPENB_STEPENB_TC);
+   /* The steps1 … end and bit 0 for TS_Charge */
+   stepenable = (1  (total_steps + 2)) - 1;
+   am335x_tsc_se_set(ts_dev-mfd_tscadc, stepenable);
 }
 
 static void titsc_read_coordinates(struct titsc *ts_dev,
@@ -250,7 +253,7 @@ static irqreturn_t titsc_irq(int irq, void *dev)
 
titsc_writel(ts_dev, REG_IRQSTATUS, irqclr);
 
-   titsc_writel(ts_dev, REG_SE, STPENB_STEPENB_TC);
+   am335x_tsc_se_update(ts_dev-mfd_tscadc);
return IRQ_HANDLED;
 }
 
@@ -334,6 +337,11 @@ static int titsc_remove(struct platform_device *pdev)
 
free_irq(ts_dev-irq, ts_dev);
 
+   /* total steps followed by the enable mask */
+   steps = 2 * ts_dev-steps_to_configure + 2;
+   steps = (1  steps) - 1;
+   am335x_tsc_se_clr(ts_dev-mfd_tscadc, steps);
+
input_unregister_device(ts_dev-input);
 
platform_set_drvdata(pdev, NULL);
diff --git a/drivers/mfd/ti_am335x_tscadc.c b/drivers/mfd/ti_am335x_tscadc.c
index 772ea2a..90ccfc0 100644
--- a/drivers/mfd/ti_am335x_tscadc.c
+++ b/drivers/mfd/ti_am335x_tscadc.c
@@ -48,6 +48,32 @@ static const struct regmap_config tscadc_regmap_config = {
.val_bits = 32,
 };
 
+void am335x_tsc_se_update(struct ti_tscadc_dev *tsadc)
+{
+   tscadc_writel(tsadc, REG_SE, tsadc-reg_se_cache);
+}

[PATCH 04/21] input: ti_am33x_tsc: remove unwanted fifo flush

2013-06-12 Thread Sebastian Andrzej Siewior
From: Patil, Rachna rac...@ti.com

When touchscreen and ADC are used together, this
unwanted fifo flush leads to loss of ADC data.

Signed-off-by: Patil, Rachna rac...@ti.com
Signed-off-by: Felipe Balbi ba...@ti.com
Signed-off-by: Sebastian Andrzej Siewior bige...@linutronix.de
---
 drivers/input/touchscreen/ti_am335x_tsc.c |   10 --
 1 file changed, 10 deletions(-)

diff --git a/drivers/input/touchscreen/ti_am335x_tsc.c 
b/drivers/input/touchscreen/ti_am335x_tsc.c
index 2bdd66c..7b7de60 100644
--- a/drivers/input/touchscreen/ti_am335x_tsc.c
+++ b/drivers/input/touchscreen/ti_am335x_tsc.c
@@ -252,8 +252,6 @@ static irqreturn_t titsc_irq(int irq, void *dev)
unsigned int x = 0, y = 0;
unsigned int z1, z2, z;
unsigned int fsm;
-   unsigned int fifo1count, fifo0count;
-   int i;
 
status = titsc_readl(ts_dev, REG_IRQSTATUS);
if (status  IRQENB_FIFO0THRES) {
@@ -262,14 +260,6 @@ static irqreturn_t titsc_irq(int irq, void *dev)
z1 = titsc_readl(ts_dev, REG_FIFO0)  0xfff;
z2 = titsc_readl(ts_dev, REG_FIFO1)  0xfff;
 
-   fifo1count = titsc_readl(ts_dev, REG_FIFO1CNT);
-   for (i = 0; i  fifo1count; i++)
-   titsc_readl(ts_dev, REG_FIFO1);
-
-   fifo0count = titsc_readl(ts_dev, REG_FIFO0CNT);
-   for (i = 0; i  fifo0count; i++)
-   titsc_readl(ts_dev, REG_FIFO0);
-
if (ts_dev-pen_down  z1 != 0  z2 != 0) {
/*
 * Calculate pressure using formula
-- 
1.7.10.4

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH v4 2/3] arm: gpmc: Low power transition support

2013-06-12 Thread Tony Lindgren
* Pekon Gupta pe...@ti.com [130612 04:07]:
 From: avinash philip avinashphi...@ti.com
 
 With GPMC converted to platform driver recently, adds low power
 transition support in driver itself.

Applying the first two patches of this series into omap-for-v3.11/gpmc.
Not taking the MTD patch, if it has dependencies to the first two
patches please let me know and also get an ack from Artem if you
want me to take it.

Regards,

Tony
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH] ARM: OMAP2+: omap-usb-host: Fix memory leaks

2013-06-12 Thread Tony Lindgren
* Roger Quadros rog...@ti.com [130531 00:23]:
 Hi Tony,
 
 On 05/31/2013 12:00 AM, Tony Lindgren wrote:
  Hi Roger,
  
  * Roger Quadros rog...@ti.com [130524 06:12]:
  Fix memory leaks in the error path.
  Also, use platform_device_register_full() to allocate
  the platform devices and set platform data.
  
  If you need this for the v3.10-rc, you should describe why this patch
  is needed and ideally have some oops or regression causing commit
  listed. Care to update the description for that?
 
 There is no oops or regression happening. Just that there will be a
 small memory leak if any of the memory allocations fail or if the
 platform device is destroyed.
 
 If it doesn't look that serious to you then it can wait.
 But if we move to device tree only boot then this patch and the file
 usb-host.c might not be required at all.

OK, applying into omap-for-v3.11/fixes-non-critical as we cannot
remove it yet.

Regards,

Tony
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCHv3 2/6] arm: introduce config HAS_BANDGAP

2013-06-12 Thread Tony Lindgren
* Eduardo Valentin eduardo.valen...@ti.com [130607 13:53]:
 Bandgap is a device used to measure temperature on
 electronic equipments. It is widely used in digital
 integrated circuits. It is based on the dependency
 between silicon voltage and temperature.
 
 This patch introduce HAS_BANDGAP config entry.
 This config is a boolean value so that arch
 code can flag if they feature a bandgap device.
 
 This config entry follows the same idea behind
 ARCH_HAS_CPUFREQ.

I suggest you add this to Russell's patch system:

Acked-by: Tony Lindgren t...@atomide.com
 
 Cc: Russell King li...@arm.linux.org.uk
 Cc: Tony Lindgren t...@atomide.com
 Cc: linux-arm-ker...@lists.infradead.org
 Cc: linux-omap@vger.kernel.org
 Cc: linux-ker...@vger.kernel.org
 Cc: Fabio Stevam feste...@gmail.com
 Signed-off-by: Eduardo Valentin eduardo.valen...@ti.com
 ---
  arch/arm/Kconfig| 3 +++
  arch/arm/mach-omap2/Kconfig | 1 +
  2 files changed, 4 insertions(+)
 
 diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
 index d423d58..bcbdec9 100644
 --- a/arch/arm/Kconfig
 +++ b/arch/arm/Kconfig
 @@ -174,6 +174,9 @@ config ARCH_HAS_CPUFREQ
 and that the relevant menu configurations are displayed for
 it.
  
 +config ARCH_HAS_BANDGAP
 + bool
 +
  config GENERIC_HWEIGHT
   bool
   default y
 diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig
 index f49cd51..8620ab5 100644
 --- a/arch/arm/mach-omap2/Kconfig
 +++ b/arch/arm/mach-omap2/Kconfig
 @@ -4,6 +4,7 @@ config ARCH_OMAP
  config ARCH_OMAP2PLUS
   bool TI OMAP2/3/4/5 SoCs with device tree support if (ARCH_MULTI_V6 
 || ARCH_MULTI_V7)
   select ARCH_HAS_CPUFREQ
 + select ARCH_HAS_BANDGAP
   select ARCH_HAS_HOLES_MEMORYMODEL
   select ARCH_OMAP
   select ARCH_REQUIRE_GPIOLIB
 -- 
 1.8.2.1.342.gfa7285d
 
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH 05/21] input: ti_am33x_tsc: Add DT support

2013-06-12 Thread Sebastian Andrzej Siewior
From: Patil, Rachna rac...@ti.com

This patch adds DT support to touch driver. It also provides a binding
document which is used by the MFD and IIO part of the device.
This patch also renames steps_to_configure to coordinate_readouts
because the original name misleads the purpose of the variable.

Signed-off-by: Pantelis Antoniou pa...@antoniou-consulting.com
Signed-off-by: Patil, Rachna rac...@ti.com
Signed-off-by: Felipe Balbi ba...@ti.com
Signed-off-by: Sebastian Andrzej Siewior bige...@linutronix.de
---
 .../bindings/input/touchscreen/ti-tsc-adc.txt  |   44 
 drivers/input/touchscreen/ti_am335x_tsc.c  |  105 +++-
 drivers/mfd/ti_am335x_tscadc.c |1 +
 3 files changed, 127 insertions(+), 23 deletions(-)
 create mode 100644 
Documentation/devicetree/bindings/input/touchscreen/ti-tsc-adc.txt

diff --git a/Documentation/devicetree/bindings/input/touchscreen/ti-tsc-adc.txt 
b/Documentation/devicetree/bindings/input/touchscreen/ti-tsc-adc.txt
new file mode 100644
index 000..491c97b
--- /dev/null
+++ b/Documentation/devicetree/bindings/input/touchscreen/ti-tsc-adc.txt
@@ -0,0 +1,44 @@
+* TI - TSC ADC (Touschscreen and analog digital converter)
+~~
+
+Required properties:
+- child tsc
+   ti,wires: Wires refer to application modes i.e. 4/5/8 wire touchscreen
+ support on the platform.
+   ti,x-plate-resistance: X plate resistance
+   ti,coordiante-readouts: The sequencer supports a total of 16
+   programmable steps each step is used to
+   read a single coordinate. A single
+readout is enough but multiple reads can
+   increase the quality.
+   A value of 5 means, 5 reads for X, 5 for
+   Y and 2 for Z (always). This utilises 12
+   of the 16 software steps available. The
+   remaining 4 can be used by the ADC.
+   ti,wire-config: Different boards could have a different order for
+   connecting wires on touchscreen. We need to provide an
+   8 bit number where in the 1st four bits represent the
+   analog lines and the next 4 bits represent positive/
+   negative terminal on that input line. Notations to
+   represent the input lines and terminals resoectively
+   is as follows:
+   AIN0 = 0, AIN1 = 1 and so on till AIN7 = 7.
+   XP  = 0, XN = 1, YP = 2, YN = 3.
+- child adc
+   ti,adc-channels: List of analog inputs available for ADC.
+AIN0 = 0, AIN1 = 1 and so on till AIN7 = 7.
+
+Example:
+   tscadc: tscadc@44e0d000 {
+   compatible = ti,am3359-tscadc;
+   tsc {
+   ti,wires = 4;
+   ti,x-plate-resistance = 200;
+   ti,coordiante-readouts = 5;
+   ti,wire-config = 0x00 0x11 0x22 0x33;
+   };
+
+   adc {
+   ti,adc-channels = 4 5 6 7;
+   };
+   }
diff --git a/drivers/input/touchscreen/ti_am335x_tsc.c 
b/drivers/input/touchscreen/ti_am335x_tsc.c
index 7b7de60..449c0fb 100644
--- a/drivers/input/touchscreen/ti_am335x_tsc.c
+++ b/drivers/input/touchscreen/ti_am335x_tsc.c
@@ -26,6 +26,8 @@
 #include linux/io.h
 #include linux/input/ti_am335x_tsc.h
 #include linux/delay.h
+#include linux/of.h
+#include linux/of_device.h
 
 #include linux/mfd/ti_am335x_tscadc.h
 
@@ -47,7 +49,7 @@ struct titsc {
unsigned intwires;
unsigned intx_plate_resistance;
boolpen_down;
-   int steps_to_configure;
+   int coordinate_readouts;
u32 config_inp[4];
u32 bit_xp, bit_xn, bit_yp, bit_yn;
u32 inp_xp, inp_xn, inp_yp, inp_yn;
@@ -123,7 +125,7 @@ static void titsc_step_config(struct titsc *ts_dev)
int i, total_steps;
 
/* Configure the Step registers */
-   total_steps = 2 * ts_dev-steps_to_configure;
+   total_steps = 2 * ts_dev-coordinate_readouts;
 
config = STEPCONFIG_MODE_HWSYNC |
STEPCONFIG_AVG_16 | ts_dev-bit_xp;
@@ -141,7 +143,7 @@ static void titsc_step_config(struct titsc *ts_dev)
break;
}
 
-   for (i = 1; i = ts_dev-steps_to_configure; i++) {
+   for (i = 1; i = ts_dev-coordinate_readouts; i++) {
titsc_writel(ts_dev, REG_STEPCONFIG(i), config);
titsc_writel(ts_dev, REG_STEPDELAY(i), STEPCONFIG_OPENDLY);
}
@@ -163,7 +165,7 @@ static void titsc_step_config(struct titsc *ts_dev)

Re: [PATCH v2 08/10] ARM: dts: omap3: split omap3_pmx_core

2013-06-12 Thread Balaji T K

On Wednesday 12 June 2013 08:05 PM, Tony Lindgren wrote:

* Balaji T K balaj...@ti.com [130606 12:20]:

omap3_pmx_core: padconf register are in two banks 0x48003000 to 0x48002268
and 0x480025c0 to 0x480025f8.

split omap3_pmx_core into 2 banks as register between 0x48002270 and 0x48002564
belongs to type pinctrl-single,bit-per-mux with access to certain bit
fields with bit field mask.


Is this the right patch for the description? THe patch seems to deal with
USB pins.

Also, let's not hog any pins under the pinmux controllers, those make
unloading pinctrl-single impossible which is not nice for distros and
development.


omap3_pmx_core is not continuous, so had to split into two and
updated the only user in second bank (omap3_pmx_core2) which happened to be usb,
CC Roger for USB dynamic pin mux selection.



Instead, the pins should be under mmc1 in omap[345].dtsi files.

Regards,

Tony


Signed-off-by: Balaji T K balaj...@ti.com
---
  arch/arm/boot/dts/omap3-beagle.dts |   28 
  arch/arm/boot/dts/omap3.dtsi   |   11 ++-
  2 files changed, 30 insertions(+), 9 deletions(-)

diff --git a/arch/arm/boot/dts/omap3-beagle.dts 
b/arch/arm/boot/dts/omap3-beagle.dts
index 6eec699..7da9979 100644
--- a/arch/arm/boot/dts/omap3-beagle.dts
+++ b/arch/arm/boot/dts/omap3-beagle.dts
@@ -76,17 +76,11 @@
  omap3_pmx_core {
pinctrl-names = default;
pinctrl-0 = 
-   hsusbb2_pins
+   hsusbb2_pins1
;

-   hsusbb2_pins: pinmux_hsusbb2_pins {
+   hsusbb2_pins1: pinmux_hsusbb2_pins1 {
pinctrl-single,pins = 
-   0x5c0 0x3  /* 
USBB2_ULPITLL_CLK_MUXMODE.usbb1_ulpiphy_clk OUTPUT */
-   0x5c2 0x3  /* 
USBB2_ULPITLL_CLK_MUXMODE.usbb1_ulpiphy_stp OUTPUT */
-   0x5c4 0x10b  /* 
USBB2_ULPITLL_CLK_MUXMODE.usbb1_ulpiphy_dir INPUT | PULLDOWN */
-   0x5c6 0x10b  /* 
USBB2_ULPITLL_CLK_MUXMODE.usbb1_ulpiphy_nxt INPUT | PULLDOWN */
-   0x5c8 0x10b  /* 
USBB2_ULPITLL_CLK_MUXMODE.usbb1_ulpiphy_dat0 INPUT | PULLDOWN */
-   0x5cA 0x10b  /* 
USBB2_ULPITLL_CLK_MUXMODE.usbb1_ulpiphy_dat1 INPUT | PULLDOWN */
0x1a4 0x10b  /* 
USBB2_ULPITLL_CLK_MUXMODE.usbb1_ulpiphy_dat2 INPUT | PULLDOWN */
0x1a6 0x10b  /* 
USBB2_ULPITLL_CLK_MUXMODE.usbb1_ulpiphy_dat3 INPUT | PULLDOWN */
0x1a8 0x10b  /* 
USBB2_ULPITLL_CLK_MUXMODE.usbb1_ulpiphy_dat4 INPUT | PULLDOWN */
@@ -97,6 +91,24 @@
};
  };

+omap3_pmx_core2 {
+   pinctrl-names = default;
+   pinctrl-0 = 
+   hsusbb2_pins2
+   ;
+
+   hsusbb2_pins2: pinmux_hsusbb2_pins2 {
+   pinctrl-single,pins = 
+   0x50 0x3  /* 
USBB2_ULPITLL_CLK_MUXMODE.usbb1_ulpiphy_clk OUTPUT */
+   0x52 0x3  /* 
USBB2_ULPITLL_CLK_MUXMODE.usbb1_ulpiphy_stp OUTPUT */
+   0x54 0x10b  /* 
USBB2_ULPITLL_CLK_MUXMODE.usbb1_ulpiphy_dir INPUT | PULLDOWN */
+   0x56 0x10b  /* 
USBB2_ULPITLL_CLK_MUXMODE.usbb1_ulpiphy_nxt INPUT | PULLDOWN */
+   0x58 0x10b  /* 
USBB2_ULPITLL_CLK_MUXMODE.usbb1_ulpiphy_dat0 INPUT | PULLDOWN */
+   0x5A 0x10b  /* 
USBB2_ULPITLL_CLK_MUXMODE.usbb1_ulpiphy_dat1 INPUT | PULLDOWN */
+   ;
+   };
+};
+
  i2c1 {
clock-frequency = 260;

diff --git a/arch/arm/boot/dts/omap3.dtsi b/arch/arm/boot/dts/omap3.dtsi
index 82a404d..caaa708 100644
--- a/arch/arm/boot/dts/omap3.dtsi
+++ b/arch/arm/boot/dts/omap3.dtsi
@@ -95,7 +95,16 @@

omap3_pmx_core: pinmux@48002030 {
compatible = ti,omap3-padconf, pinctrl-single;
-   reg = 0x48002030 0x05cc;
+   reg = 0x48002030 0x238;
+   #address-cells = 1;
+   #size-cells = 0;
+   pinctrl-single,register-width = 16;
+   pinctrl-single,function-mask = 0x7f1f;
+   };
+
+   omap3_pmx_core2: pinmux@480025a0 {
+   compatible = ti,omap3-padconf, pinctrl-single;
+   reg = 0x480025a0 0x5c;
#address-cells = 1;
#size-cells = 0;
pinctrl-single,register-width = 16;
--
1.7.5.4



--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH 13/21] arm: am33xx: add TSC/ADC mfd device support

2013-06-12 Thread Sebastian Andrzej Siewior
From: Patil, Rachna rac...@ti.com

Add support for core multifunctional device along
with its clients touchscreen and ADC.

Signed-off-by: Pantelis Antoniou pa...@antoniou-consulting.com
Signed-off-by: Patil, Rachna rac...@ti.com
Signed-off-by: Felipe Balbi ba...@ti.com
Signed-off-by: Sebastian Andrzej Siewior sebast...@breakpoint.cc
---
 arch/arm/boot/dts/am335x-evm.dts |   14 ++
 arch/arm/boot/dts/am33xx.dtsi|   18 ++
 2 files changed, 32 insertions(+)

diff --git a/arch/arm/boot/dts/am335x-evm.dts b/arch/arm/boot/dts/am335x-evm.dts
index 0423298..26fea97 100644
--- a/arch/arm/boot/dts/am335x-evm.dts
+++ b/arch/arm/boot/dts/am335x-evm.dts
@@ -244,3 +244,17 @@
 cpsw_emac1 {
phy_id = davinci_mdio, 1;
 };
+
+tscadc {
+   status = okay;
+   tsc {
+   ti,wires = 4;
+   ti,x-plate-resistance = 200;
+   ti,coordiante-readouts = 5;
+   ti,wire-config = 0x00 0x11 0x22 0x33;
+   };
+
+   adc {
+   ti,adc-channels = 4;
+   };
+};
diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
index 1460d9b..4ad7797 100644
--- a/arch/arm/boot/dts/am33xx.dtsi
+++ b/arch/arm/boot/dts/am33xx.dtsi
@@ -404,6 +404,24 @@
ti,hwmods = wkup_m3;
};
 
+   tscadc: tscadc@44e0d000 {
+   compatible = ti,am3359-tscadc;
+   reg = 0x44e0d000 0x1000;
+   interrupt-parent = intc;
+   interrupts = 16;
+   ti,hwmods = adc_tsc;
+   status = disabled;
+
+   tsc {
+   compatible = ti,am3359-tsc;
+   };
+   am335x_adc: adc {
+   #io-channel-cells = 1;
+   compatible = ti,am3359-adc;
+   };
+
+   };
+
gpmc: gpmc@5000 {
compatible = ti,am3352-gpmc;
ti,hwmods = gpmc;
-- 
1.7.10.4

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH 11/21] iio: ti_tscadc: provide datasheet_name and scan_type

2013-06-12 Thread Sebastian Andrzej Siewior
From: Pantelis Antoniou pa...@antoniou-consulting.com

This patch provides the members datasheet_name and scan_type. This is
the remaining part of the earlier patch where I (bigeasy) removed iio_map
because it is now supplied by the device tree. It also static names as
suggested by Jonathan.

Acked-by: Jonathan Cameron ji...@kernel.org
Signed-off-by: Pantelis Antoniou pa...@antoniou-consulting.com
Signed-off-by: Felipe Balbi ba...@ti.com
Signed-off-by: Sebastian Andrzej Siewior bige...@linutronix.de
---
 drivers/iio/adc/ti_am335x_adc.c |   29 -
 1 file changed, 24 insertions(+), 5 deletions(-)

diff --git a/drivers/iio/adc/ti_am335x_adc.c b/drivers/iio/adc/ti_am335x_adc.c
index 2868c0c..9939810 100644
--- a/drivers/iio/adc/ti_am335x_adc.c
+++ b/drivers/iio/adc/ti_am335x_adc.c
@@ -24,6 +24,8 @@
 #include linux/iio/iio.h
 #include linux/of.h
 #include linux/of_device.h
+#include linux/iio/machine.h
+#include linux/iio/driver.h
 
 #include linux/mfd/ti_am335x_tscadc.h
 
@@ -84,29 +86,46 @@ static void tiadc_step_config(struct tiadc_device *adc_dev)
am335x_tsc_se_set(adc_dev-mfd_tscadc, step_en);
 }
 
+static const char * const chan_name_ain[] = {
+   AIN0,
+   AIN1,
+   AIN2,
+   AIN3,
+   AIN4,
+   AIN5,
+   AIN6,
+   AIN7,
+};
+
 static int tiadc_channel_init(struct iio_dev *indio_dev, int channels)
 {
+   struct tiadc_device *adc_dev = iio_priv(indio_dev);
struct iio_chan_spec *chan_array;
+   struct iio_chan_spec *chan;
int i;
 
indio_dev-num_channels = channels;
-   chan_array = kcalloc(indio_dev-num_channels,
+   chan_array = kcalloc(channels,
sizeof(struct iio_chan_spec), GFP_KERNEL);
-
if (chan_array == NULL)
return -ENOMEM;
 
-   for (i = 0; i  (indio_dev-num_channels); i++) {
-   struct iio_chan_spec *chan = chan_array + i;
+   chan = chan_array;
+   for (i = 0; i  channels; i++, chan++) {
+
chan-type = IIO_VOLTAGE;
chan-indexed = 1;
chan-channel = i;
chan-info_mask_separate = BIT(IIO_CHAN_INFO_RAW);
+   chan-datasheet_name = chan_name_ain[i];
+   chan-scan_type.sign = 'u';
+   chan-scan_type.realbits = 12;
+   chan-scan_type.storagebits = 32;
}
 
indio_dev-channels = chan_array;
 
-   return indio_dev-num_channels;
+   return 0;
 }
 
 static void tiadc_channels_remove(struct iio_dev *indio_dev)
-- 
1.7.10.4

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH 18/21] input: ti_am335x_tsc: ACK the HW_PEN irq in ISR

2013-06-12 Thread Sebastian Andrzej Siewior
The interrupt source IRQENB_HW_PEN is enabled in suspend and suposed to
be used as a wake up source. Once this interrupt source is unmaksed, the
devices ends up in ISR and never continues.
This change ACKs the interrupt and disables it so the system does not
freeze.

Signed-off-by: Sebastian Andrzej Siewior bige...@linutronix.de
---
 drivers/input/touchscreen/ti_am335x_tsc.c |6 ++
 1 file changed, 6 insertions(+)

diff --git a/drivers/input/touchscreen/ti_am335x_tsc.c 
b/drivers/input/touchscreen/ti_am335x_tsc.c
index 1bceb25..2ba7703 100644
--- a/drivers/input/touchscreen/ti_am335x_tsc.c
+++ b/drivers/input/touchscreen/ti_am335x_tsc.c
@@ -308,6 +308,12 @@ static irqreturn_t titsc_irq(int irq, void *dev)
irqclr |= IRQENB_PENUP;
}
 
+   if (status  IRQENB_HW_PEN) {
+
+   titsc_writel(ts_dev, REG_IRQWAKEUP, 0x00);
+   titsc_writel(ts_dev, REG_IRQCLR, IRQENB_HW_PEN);
+   }
+
titsc_writel(ts_dev, REG_IRQSTATUS, irqclr);
 
am335x_tsc_se_update(ts_dev-mfd_tscadc);
-- 
1.7.10.4

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH 12/21] mfd: ti_tscadc: deal with partial activation

2013-06-12 Thread Sebastian Andrzej Siewior
From: Pantelis Antoniou pa...@antoniou-consulting.com

Fix the mfd device in the case where a subdevice might not be activated.

Signed-off-by: Pantelis Antoniou pa...@antoniou-consulting.com
Signed-off-by: Felipe Balbi ba...@ti.com
Signed-off-by: Sebastian Andrzej Siewior bige...@linutronix.de
---
 drivers/mfd/ti_am335x_tscadc.c   |   38 ++
 include/linux/mfd/ti_am335x_tscadc.h |8 +++
 2 files changed, 28 insertions(+), 18 deletions(-)

diff --git a/drivers/mfd/ti_am335x_tscadc.c b/drivers/mfd/ti_am335x_tscadc.c
index e78b9df..d05fcba 100644
--- a/drivers/mfd/ti_am335x_tscadc.c
+++ b/drivers/mfd/ti_am335x_tscadc.c
@@ -107,11 +107,14 @@ staticint ti_tscadc_probe(struct platform_device 
*pdev)
of_property_read_u32(node, ti,adc-channels, adc_channels);
 
total_channels = tsc_wires + adc_channels;
-
if (total_channels  8) {
dev_err(pdev-dev, Number of i/p channels more than 8\n);
return -EINVAL;
}
+   if (total_channels == 0) {
+   dev_err(pdev-dev, Need atleast one channel.\n);
+   return -EINVAL;
+   }
 
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
if (!res) {
@@ -202,28 +205,37 @@ staticint ti_tscadc_probe(struct platform_device 
*pdev)
ctrl |= CNTRLREG_TSCSSENB;
tscadc_writel(tscadc, REG_CTRL, ctrl);
 
+   tscadc-used_cells = 0;
+   tscadc-tsc_cell = -1;
+   tscadc-adc_cell = -1;
+
/* TSC Cell */
-   cell = tscadc-cells[TSC_CELL];
-   cell-name = tsc;
-   cell-of_compatible = ti,am3359-tsc;
-   cell-platform_data = tscadc;
-   cell-pdata_size = sizeof(tscadc);
+   if (tsc_wires  0) {
+   tscadc-tsc_cell = tscadc-used_cells;
+   cell = tscadc-cells[tscadc-used_cells++];
+   cell-name = tsc;
+   cell-of_compatible = ti,am3359-tsc;
+   cell-platform_data = tscadc;
+   cell-pdata_size = sizeof(tscadc);
+   }
 
/* ADC Cell */
-   cell = tscadc-cells[ADC_CELL];
-   cell-name = tiadc;
-   cell-of_compatible = ti,am3359-adc;
-   cell-platform_data = tscadc;
-   cell-pdata_size = sizeof(tscadc);
+   if (adc_channels  0) {
+   tscadc-adc_cell = tscadc-used_cells;
+   cell = tscadc-cells[tscadc-used_cells++];
+   cell-name = tiadc;
+   cell-of_compatible = ti,am3359-adc;
+   cell-platform_data = tscadc;
+   cell-pdata_size = sizeof(tscadc);
+   }
 
err = mfd_add_devices(pdev-dev, pdev-id, tscadc-cells,
-   TSCADC_CELLS, NULL, 0, NULL);
+   tscadc-used_cells, NULL, 0, NULL);
if (err  0)
goto err_disable_clk;
 
device_init_wakeup(pdev-dev, true);
platform_set_drvdata(pdev, tscadc);
-
return 0;
 
 err_disable_clk:
diff --git a/include/linux/mfd/ti_am335x_tscadc.h 
b/include/linux/mfd/ti_am335x_tscadc.h
index e36ae41..fe54ba4 100644
--- a/include/linux/mfd/ti_am335x_tscadc.h
+++ b/include/linux/mfd/ti_am335x_tscadc.h
@@ -120,11 +120,6 @@
 
 #define TSCADC_CELLS   2
 
-enum tscadc_cells {
-   TSC_CELL,
-   ADC_CELL,
-};
-
 struct mfd_tscadc_board {
struct tsc_data *tsc_init;
struct adc_data *adc_init;
@@ -135,6 +130,9 @@ struct ti_tscadc_dev {
struct regmap *regmap_tscadc;
void __iomem *tscadc_base;
int irq;
+   int used_cells; /* 1-2 */
+   int tsc_cell;   /* -1 if not used */
+   int adc_cell;   /* -1 if not used */
struct mfd_cell cells[TSCADC_CELLS];
u32 reg_se_cache;
spinlock_t reg_lock;
-- 
1.7.10.4

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH 17/21] input: ti_am335x_adc: use only FIFO0 and clean up a little

2013-06-12 Thread Sebastian Andrzej Siewior
The driver programs a threshold of coordinate_readouts say 5. The
REG_FIFO0THR registers says it should it be programmed to threshold
minus one. The driver does not expect just 5 coordinates but 5 * 2 + 2.
Multiplied by two because 5 for X and 5 for Y and plus 2 because we have
two Z.
The whole thing kind of works because It reads the 5 coordinates for X
and Y from FIFO0 and FIFO1 and the last element in each FIFO is ignored
within the loop and read later.
Nothing guaranties that FIFO1 is ready by the time it is read. In fact I
could see that that FIFO1 reaturns for Y channels 8,9, 10, 12, 6 and for
Y channel 7 for Z. The problem is that channel 7 and channel 12 got
somehow mixed up.
The other Problem is that FIFO1 is also used by the IIO part leading to
wrong results if both (tsc  adc) are used.

The patch tries to clean up the whole thing a little:
- Remove the +1 and -1 in REG_STEPCONFIG, REG_STEPDELAY and its counter
  part in the for loop. This is just confusing.

- Use only FIFO0 in TSC. The fifo has space for 64 entries so should be
  fine.

- Read the whole FIFO in one function and check the channel.

- in case we dawdle around, make sure we only read a multiple of our
  coordinate set. On the second interrupt we will cleanup the remaining
  enties.

Acked-by: Dmitry Torokhov dmitry.torok...@gmail.com
Signed-off-by: Sebastian Andrzej Siewior bige...@linutronix.de
---
 drivers/iio/adc/ti_am335x_adc.c   |2 +-
 drivers/input/touchscreen/ti_am335x_tsc.c |   78 +++--
 include/linux/mfd/ti_am335x_tscadc.h  |4 +-
 3 files changed, 44 insertions(+), 40 deletions(-)

diff --git a/drivers/iio/adc/ti_am335x_adc.c b/drivers/iio/adc/ti_am335x_adc.c
index 4bec91e..307a7c0 100644
--- a/drivers/iio/adc/ti_am335x_adc.c
+++ b/drivers/iio/adc/ti_am335x_adc.c
@@ -75,7 +75,7 @@ static void tiadc_step_config(struct tiadc_device *adc_dev)
 
stepconfig = STEPCONFIG_AVG_16 | STEPCONFIG_FIFO1;
 
-   for (i = (steps + 1); i = TOTAL_STEPS; i++) {
+   for (i = steps; i  TOTAL_STEPS; i++) {
tiadc_writel(adc_dev, REG_STEPCONFIG(i),
stepconfig | STEPCONFIG_INP(channels));
tiadc_writel(adc_dev, REG_STEPDELAY(i),
diff --git a/drivers/input/touchscreen/ti_am335x_tsc.c 
b/drivers/input/touchscreen/ti_am335x_tsc.c
index ff3215d..1bceb25 100644
--- a/drivers/input/touchscreen/ti_am335x_tsc.c
+++ b/drivers/input/touchscreen/ti_am335x_tsc.c
@@ -120,11 +120,9 @@ static int titsc_config_wires(struct titsc *ts_dev)
 static void titsc_step_config(struct titsc *ts_dev)
 {
unsigned intconfig;
-   unsigned intstepenable = 0;
-   int i, total_steps;
-
-   /* Configure the Step registers */
-   total_steps = 2 * ts_dev-coordinate_readouts;
+   int i;
+   int end_step;
+   u32 stepenable;
 
config = STEPCONFIG_MODE_HWSYNC |
STEPCONFIG_AVG_16 | ts_dev-bit_xp;
@@ -142,7 +140,9 @@ static void titsc_step_config(struct titsc *ts_dev)
break;
}
 
-   for (i = 1; i = ts_dev-coordinate_readouts; i++) {
+   /* 1 … coordinate_readouts is for X */
+   end_step = ts_dev-coordinate_readouts;
+   for (i = 0; i  end_step; i++) {
titsc_writel(ts_dev, REG_STEPCONFIG(i), config);
titsc_writel(ts_dev, REG_STEPDELAY(i), STEPCONFIG_OPENDLY);
}
@@ -150,7 +150,7 @@ static void titsc_step_config(struct titsc *ts_dev)
config = 0;
config = STEPCONFIG_MODE_HWSYNC |
STEPCONFIG_AVG_16 | ts_dev-bit_yn |
-   STEPCONFIG_INM_ADCREFM | STEPCONFIG_FIFO1;
+   STEPCONFIG_INM_ADCREFM;
switch (ts_dev-wires) {
case 4:
config |= ts_dev-bit_yp | STEPCONFIG_INP(ts_dev-inp_xp);
@@ -164,12 +164,13 @@ static void titsc_step_config(struct titsc *ts_dev)
break;
}
 
-   for (i = (ts_dev-coordinate_readouts + 1); i = total_steps; i++) {
+   /* coordinate_readouts … coordinate_readouts * 2 is for Y */
+   end_step = ts_dev-coordinate_readouts * 2;
+   for (i = ts_dev-coordinate_readouts; i  end_step; i++) {
titsc_writel(ts_dev, REG_STEPCONFIG(i), config);
titsc_writel(ts_dev, REG_STEPDELAY(i), STEPCONFIG_OPENDLY);
}
 
-   config = 0;
/* Charge step configuration */
config = ts_dev-bit_xp | ts_dev-bit_yn |
STEPCHARGE_RFP_XPUL | STEPCHARGE_RFM_XNUR |
@@ -178,35 +179,39 @@ static void titsc_step_config(struct titsc *ts_dev)
titsc_writel(ts_dev, REG_CHARGECONFIG, config);
titsc_writel(ts_dev, REG_CHARGEDELAY, CHARGEDLY_OPENDLY);
 
-   config = 0;
-   /* Configure to calculate pressure */
+   /* coordinate_readouts * 2 … coordinate_readouts * 2 + 2 is for Z */
config = STEPCONFIG_MODE_HWSYNC |
STEPCONFIG_AVG_16 | ts_dev-bit_yp |
 

Re: [PATCH v2 02/14] ARM: OMAP2+: AM43x: Kconfig

2013-06-12 Thread Tony Lindgren
* Afzal Mohammed af...@ti.com [130527 07:41]:
 --- a/arch/arm/mach-omap2/Kconfig
 +++ b/arch/arm/mach-omap2/Kconfig
 @@ -149,6 +149,16 @@ config SOC_AM33XX
   select MULTI_IRQ_HANDLER
   select COMMON_CLK
  
 +config SOC_AM43XX
 + bool TI AM43x
 + depends on ARCH_OMAP2PLUS
 + default y
 + select CPU_V7
 + select MULTI_IRQ_HANDLER
 + select ARM_GIC
 + select COMMON_CLK
 + select MACH_OMAP_GENERIC
 +
  config OMAP_PACKAGE_ZAF
 bool

I've updated this patch to remove the default y and
depends on ARCH_OMAP2PLUS entries for the usual reasons
and applied the first ten patches into omap-for-v3.11/soc.

Regards,

Tony
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH 20/21] iio: ti_am335x_adc: Allow to specify input line

2013-06-12 Thread Sebastian Andrzej Siewior
The TSC part allows to specify the input lines. The IIO part assumes
that it usues always the last few, that means if IIO has adc-channels
set to 2 it will use channel 6 and 7. However it might make sense to use
only 6.
This patch changes the device property (which was introduced recently
and was never in an official release) in a way that the user can specify
which of the AIN lines should be used. In Addition to this, the name is
now AINx where x is the channel number i.e. for AIN6 we would have 6.
Prior this, it always started counting at 0 which is confusing. In
addition to this, it also checks for correct step number during reading
and does not rely on proper FIFO depth.

Acked-by: Jonathan Cameron ji...@kernel.org
Signed-off-by: Sebastian Andrzej Siewior bige...@linutronix.de
---
 arch/arm/boot/dts/am335x-evm.dts |2 +-
 drivers/iio/adc/ti_am335x_adc.c  |   57 +-
 drivers/mfd/ti_am335x_tscadc.c   |   20 +++--
 3 files changed, 56 insertions(+), 23 deletions(-)

diff --git a/arch/arm/boot/dts/am335x-evm.dts b/arch/arm/boot/dts/am335x-evm.dts
index 26fea97..0fa4c7f 100644
--- a/arch/arm/boot/dts/am335x-evm.dts
+++ b/arch/arm/boot/dts/am335x-evm.dts
@@ -255,6 +255,6 @@
};
 
adc {
-   ti,adc-channels = 4;
+   ti,adc-channels = 4 5 6 7;
};
 };
diff --git a/drivers/iio/adc/ti_am335x_adc.c b/drivers/iio/adc/ti_am335x_adc.c
index 307a7c0..8ffe52d 100644
--- a/drivers/iio/adc/ti_am335x_adc.c
+++ b/drivers/iio/adc/ti_am335x_adc.c
@@ -32,6 +32,8 @@
 struct tiadc_device {
struct ti_tscadc_dev *mfd_tscadc;
int channels;
+   u8 channel_line[8];
+   u8 channel_step[8];
 };
 
 static unsigned int tiadc_readl(struct tiadc_device *adc, unsigned int reg)
@@ -57,7 +59,7 @@ static u32 get_adc_step_mask(struct tiadc_device *adc_dev)
 static void tiadc_step_config(struct tiadc_device *adc_dev)
 {
unsigned int stepconfig;
-   int i, channels = 0, steps;
+   int i, steps;
u32 step_en;
 
/*
@@ -71,16 +73,18 @@ static void tiadc_step_config(struct tiadc_device *adc_dev)
 */
 
steps = TOTAL_STEPS - adc_dev-channels;
-   channels = TOTAL_CHANNELS - adc_dev-channels;
-
stepconfig = STEPCONFIG_AVG_16 | STEPCONFIG_FIFO1;
 
-   for (i = steps; i  TOTAL_STEPS; i++) {
-   tiadc_writel(adc_dev, REG_STEPCONFIG(i),
-   stepconfig | STEPCONFIG_INP(channels));
-   tiadc_writel(adc_dev, REG_STEPDELAY(i),
+   for (i = 0; i  adc_dev-channels; i++) {
+   int chan;
+
+   chan = adc_dev-channel_line[i];
+   tiadc_writel(adc_dev, REG_STEPCONFIG(steps),
+   stepconfig | STEPCONFIG_INP(chan));
+   tiadc_writel(adc_dev, REG_STEPDELAY(steps),
STEPCONFIG_OPENDLY);
-   channels++;
+   adc_dev-channel_step[i] = steps;
+   steps++;
}
step_en = get_adc_step_mask(adc_dev);
am335x_tsc_se_set(adc_dev-mfd_tscadc, step_en);
@@ -115,9 +119,9 @@ static int tiadc_channel_init(struct iio_dev *indio_dev, 
int channels)
 
chan-type = IIO_VOLTAGE;
chan-indexed = 1;
-   chan-channel = i;
+   chan-channel = adc_dev-channel_line[i];
chan-info_mask_separate = BIT(IIO_CHAN_INFO_RAW);
-   chan-datasheet_name = chan_name_ain[i];
+   chan-datasheet_name = chan_name_ain[chan-channel];
chan-scan_type.sign = 'u';
chan-scan_type.realbits = 12;
chan-scan_type.storagebits = 32;
@@ -139,7 +143,8 @@ static int tiadc_read_raw(struct iio_dev *indio_dev,
 {
struct tiadc_device *adc_dev = iio_priv(indio_dev);
int i;
-   unsigned int fifo1count, readx1;
+   unsigned int fifo1count, read;
+   u32 step = UINT_MAX;
 
/*
 * When the sub-system is first enabled,
@@ -152,11 +157,20 @@ static int tiadc_read_raw(struct iio_dev *indio_dev,
 * Hence we need to flush out this data.
 */
 
+   for (i = 0; i  ARRAY_SIZE(adc_dev-channel_step); i++) {
+   if (chan-channel == adc_dev-channel_line[i]) {
+   step = adc_dev-channel_step[i];
+   break;
+   }
+   }
+   if (WARN_ON_ONCE(step == UINT_MAX))
+   return -EINVAL;
+
fifo1count = tiadc_readl(adc_dev, REG_FIFO1CNT);
for (i = 0; i  fifo1count; i++) {
-   readx1 = tiadc_readl(adc_dev, REG_FIFO1);
-   if (i == chan-channel)
-   *val = readx1  0xfff;
+   read = tiadc_readl(adc_dev, REG_FIFO1);
+   if (read  16 == step)
+   *val = read  0xfff;
}
am335x_tsc_se_update(adc_dev-mfd_tscadc);
 
@@ -172,8 +186,11 @@ static int tiadc_probe(struct 

[PATCH 16/21] mfd: iio: ti_am335x_adc: rename device from tiadc to TI-am335x-adc

2013-06-12 Thread Sebastian Andrzej Siewior
TI-adc reads a little better compared to tiadc. And if we add am335x to
it then we have the same naming scheme as the tsc side.

Acked-by: Jonathan Cameron ji...@kernel.org
Signed-off-by: Sebastian Andrzej Siewior bige...@linutronix.de
---
 drivers/iio/adc/ti_am335x_adc.c |3 +--
 drivers/mfd/ti_am335x_tscadc.c  |2 +-
 2 files changed, 2 insertions(+), 3 deletions(-)

diff --git a/drivers/iio/adc/ti_am335x_adc.c b/drivers/iio/adc/ti_am335x_adc.c
index 9939810..4bec91e 100644
--- a/drivers/iio/adc/ti_am335x_adc.c
+++ b/drivers/iio/adc/ti_am335x_adc.c
@@ -292,7 +292,7 @@ MODULE_DEVICE_TABLE(of, ti_adc_dt_ids);
 
 static struct platform_driver tiadc_driver = {
.driver = {
-   .name   = tiadc,
+   .name   = TI-am335x-adc,
.owner  = THIS_MODULE,
.pm = TIADC_PM_OPS,
.of_match_table = of_match_ptr(ti_adc_dt_ids),
@@ -300,7 +300,6 @@ static struct platform_driver tiadc_driver = {
.probe  = tiadc_probe,
.remove = tiadc_remove,
 };
-
 module_platform_driver(tiadc_driver);
 
 MODULE_DESCRIPTION(TI ADC controller driver);
diff --git a/drivers/mfd/ti_am335x_tscadc.c b/drivers/mfd/ti_am335x_tscadc.c
index 5fb8b1d..2532339 100644
--- a/drivers/mfd/ti_am335x_tscadc.c
+++ b/drivers/mfd/ti_am335x_tscadc.c
@@ -223,7 +223,7 @@ static  int ti_tscadc_probe(struct platform_device 
*pdev)
if (adc_channels  0) {
tscadc-adc_cell = tscadc-used_cells;
cell = tscadc-cells[tscadc-used_cells++];
-   cell-name = tiadc;
+   cell-name = TI-am335x-adc;
cell-of_compatible = ti,am3359-adc;
cell-platform_data = tscadc;
cell-pdata_size = sizeof(tscadc);
-- 
1.7.10.4

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH 21/21] iio: ti_am335x_adc: check if we found the value

2013-06-12 Thread Sebastian Andrzej Siewior
Usually we get all the values we wanted but it is possible, that te ADC
unit is busy performing the conversation for the HW events. In that case
-EBUSY is returned and the user may re-call the function.

Acked-by: Jonathan Cameron ji...@kernel.org
Signed-off-by: Sebastian Andrzej Siewior bige...@linutronix.de
---
 drivers/iio/adc/ti_am335x_adc.c |8 ++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/drivers/iio/adc/ti_am335x_adc.c b/drivers/iio/adc/ti_am335x_adc.c
index 8ffe52d..4427e8e 100644
--- a/drivers/iio/adc/ti_am335x_adc.c
+++ b/drivers/iio/adc/ti_am335x_adc.c
@@ -145,6 +145,7 @@ static int tiadc_read_raw(struct iio_dev *indio_dev,
int i;
unsigned int fifo1count, read;
u32 step = UINT_MAX;
+   bool found = false;
 
/*
 * When the sub-system is first enabled,
@@ -169,11 +170,14 @@ static int tiadc_read_raw(struct iio_dev *indio_dev,
fifo1count = tiadc_readl(adc_dev, REG_FIFO1CNT);
for (i = 0; i  fifo1count; i++) {
read = tiadc_readl(adc_dev, REG_FIFO1);
-   if (read  16 == step)
+   if (read  16 == step) {
*val = read  0xfff;
+   found = true;
+   }
}
am335x_tsc_se_update(adc_dev-mfd_tscadc);
-
+   if (found == false)
+   return -EBUSY;
return IIO_VAL_INT;
 }
 
-- 
1.7.10.4

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH 10/21] mfd: ti_am335x_tscadc: remove platform_data support

2013-06-12 Thread Sebastian Andrzej Siewior
This patch removes access to platform data mfd_tscadc_board because the
platform is DT only.

Signed-off-by: Sebastian Andrzej Siewior bige...@linutronix.de
---
 drivers/mfd/ti_am335x_tscadc.c |   23 ++-
 1 file changed, 6 insertions(+), 17 deletions(-)

diff --git a/drivers/mfd/ti_am335x_tscadc.c b/drivers/mfd/ti_am335x_tscadc.c
index 292d34e..e78b9df 100644
--- a/drivers/mfd/ti_am335x_tscadc.c
+++ b/drivers/mfd/ti_am335x_tscadc.c
@@ -26,8 +26,6 @@
 #include linux/of_device.h
 
 #include linux/mfd/ti_am335x_tscadc.h
-#include linux/input/ti_am335x_tsc.h
-#include linux/platform_data/ti_am335x_adc.h
 
 static unsigned int tscadc_readl(struct ti_tscadc_dev *tsadc, unsigned int reg)
 {
@@ -91,31 +89,22 @@ static  int ti_tscadc_probe(struct platform_device 
*pdev)
struct ti_tscadc_dev*tscadc;
struct resource *res;
struct clk  *clk;
-   struct mfd_tscadc_board *pdata = pdev-dev.platform_data;
struct device_node  *node = pdev-dev.of_node;
struct mfd_cell *cell;
int err, ctrl;
int clk_value, clock_rate;
int tsc_wires = 0, adc_channels = 0, total_channels;
 
-   if (!pdata  !pdev-dev.of_node) {
-   dev_err(pdev-dev, Could not find platform data\n);
+   if (!pdev-dev.of_node) {
+   dev_err(pdev-dev, Could not find valid DT data.\n);
return -EINVAL;
}
 
-   if (pdev-dev.platform_data) {
-   if (pdata-tsc_init)
-   tsc_wires = pdata-tsc_init-wires;
+   node = of_get_child_by_name(pdev-dev.of_node, tsc);
+   of_property_read_u32(node, ti,wires, tsc_wires);
 
-   if (pdata-adc_init)
-   adc_channels = pdata-adc_init-adc_channels;
-   } else {
-   node = of_get_child_by_name(pdev-dev.of_node, tsc);
-   of_property_read_u32(node, ti,wires, tsc_wires);
-
-   node = of_get_child_by_name(pdev-dev.of_node, adc);
-   of_property_read_u32(node, ti,adc-channels, adc_channels);
-   }
+   node = of_get_child_by_name(pdev-dev.of_node, adc);
+   of_property_read_u32(node, ti,adc-channels, adc_channels);
 
total_channels = tsc_wires + adc_channels;
 
-- 
1.7.10.4

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH 2/6] ARM: OMAP2+: Remove board-omap4panda.c

2013-06-12 Thread Tony Lindgren
* Tony Lindgren t...@atomide.com [130612 09:37]:
 * Ming Lei tom.leim...@gmail.com [130603 08:34]:
  Hi,
  
  On Sat, May 18, 2013 at 3:17 AM, Tony Lindgren t...@atomide.com wrote:
   We can now boot with device tree. If you don't want to update u-boot,
   you can boot with appended DTB with the following instructions:
  
   1. Make sure you have the appended DTB support in .config
  
  CONFIG_ARM_APPENDED_DTB=y
  CONFIG_ARM_ATAG_DTB_COMPAT=y
  CONFIG_ARM_ATAG_DTB_COMPAT_CMDLINE_EXTEND=y
  
   2. Build the zImage
  
  $ ARCH=arm CROSS_COMPILE=... make zImage
  
   3. Build the device tree blobs
  
  $ ARCH=arm CROSS_COMPILE=... make dtbs
  
   4. Append the correct panda dtb to zImage
  
  Depending on your hardware it's omap4-panda.dtb, omap4-panda-a4.dtb
  or omap4-panda-es.dtb.
  
  $ cat arch/arm/boot/zImage arch/arm/boot/dts/omap4-panda-es.dtb  
   /tmp/appended
  
   5. Use mkimage to produce the appended device tree uImage
  
  $ mkimage -A arm -O linux -T kernel -C none -a 0x80008000 -e 
   0x80008000 \
-n Linux -d /tmp/appended /tmp/uImage
  
  I followed the above steps and tried devicetree on Pandaboard against
  3.10.0-rc3-next-20130528, and the board will hang during boot, but works
  well with legacy mode.
  
   Hardware: Pandaboard A1
   dtb: omap4-panda.dtb
  
  See 'dmesg' on below link:
  
   http://kernel.ubuntu.com/~ming/up/panda-dts.dmesg
  
 
 Hmm looks like it boots to init. Maybe add initcall_debug to the cmdline in
 case there's some late_initcall that causes the issue. It's probably some
 trivial issue causing it.

Sricharan, maybe give this a quick try if you have the original pandaboard?
I only have pandaboard es.

Regards,

Tony 
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH 15/21] mfd: input: ti_am335x_tsc: rename device from tsc to TI-am335x-tsc

2013-06-12 Thread Sebastian Andrzej Siewior
tsc is a very generic name. This patch adds a TI and HW prefix to it
less generic.

Signed-off-by: Sebastian Andrzej Siewior bige...@linutronix.de
---
 drivers/input/touchscreen/ti_am335x_tsc.c |2 +-
 drivers/mfd/ti_am335x_tscadc.c|2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/input/touchscreen/ti_am335x_tsc.c 
b/drivers/input/touchscreen/ti_am335x_tsc.c
index a1db55d..ff3215d 100644
--- a/drivers/input/touchscreen/ti_am335x_tsc.c
+++ b/drivers/input/touchscreen/ti_am335x_tsc.c
@@ -491,7 +491,7 @@ static struct platform_driver ti_tsc_driver = {
.probe  = titsc_probe,
.remove = titsc_remove,
.driver = {
-   .name   = tsc,
+   .name   = TI-am335x-tsc,
.owner  = THIS_MODULE,
.pm = TITSC_PM_OPS,
.of_match_table = of_match_ptr(ti_tsc_dt_ids),
diff --git a/drivers/mfd/ti_am335x_tscadc.c b/drivers/mfd/ti_am335x_tscadc.c
index d05fcba..5fb8b1d 100644
--- a/drivers/mfd/ti_am335x_tscadc.c
+++ b/drivers/mfd/ti_am335x_tscadc.c
@@ -213,7 +213,7 @@ static  int ti_tscadc_probe(struct platform_device 
*pdev)
if (tsc_wires  0) {
tscadc-tsc_cell = tscadc-used_cells;
cell = tscadc-cells[tscadc-used_cells++];
-   cell-name = tsc;
+   cell-name = TI-am335x-tsc;
cell-of_compatible = ti,am3359-tsc;
cell-platform_data = tscadc;
cell-pdata_size = sizeof(tscadc);
-- 
1.7.10.4

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH v2 07/14] ARM: OMAP2+: AM43x: early init

2013-06-12 Thread Tony Lindgren
* Afzal Mohammed af...@ti.com [130527 07:42]:
 --- a/arch/arm/mach-omap2/io.c
 +++ b/arch/arm/mach-omap2/io.c
 @@ -586,6 +586,20 @@ void __init am33xx_init_early(void)
  }
  #endif
  
 +#ifdef CONFIG_SOC_AM43XX
 +void __init am43xx_init_early(void)
 +{
 + omap2_set_globals_tap(AM335X_CLASS,
 +   AM33XX_L4_WK_IO_ADDRESS(AM33XX_TAP_BASE));
 + omap2_set_globals_control(AM33XX_L4_WK_IO_ADDRESS(AM33XX_CTRL_BASE),
 +   NULL);
 + omap2_set_globals_prm(AM33XX_L4_WK_IO_ADDRESS(AM43XX_PRCM_BASE));
 + omap2_set_globals_cm(AM33XX_L4_WK_IO_ADDRESS(AM43XX_PRCM_BASE), NULL);
 + omap3xxx_check_revision();
 + am33xx_check_features();
 +}
 +#endif
 +
  #ifdef CONFIG_ARCH_OMAP4
  void __init omap4430_init_early(void)
  {

I've updated this to remove am33xx_check_features() that we don't
seem to have in the mainline yet.

Tony
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH 19/21] input: ti_am335x_tsc: return IRQ_NONE if there was no IRQ for us

2013-06-12 Thread Sebastian Andrzej Siewior
The previous patch (input/ti_am335x_tsc: ACK the HW_PEN irq in ISR)
acked the interrupt so we don't freeze if we don't handle an enabled
interrupt source. The interrupt core has a mechanism for this and to get
it work one should only say that it handled an interrupt if it is
actually the case.

Signed-off-by: Sebastian Andrzej Siewior bige...@linutronix.de
---
 drivers/input/touchscreen/ti_am335x_tsc.c |   10 ++
 1 file changed, 6 insertions(+), 4 deletions(-)

diff --git a/drivers/input/touchscreen/ti_am335x_tsc.c 
b/drivers/input/touchscreen/ti_am335x_tsc.c
index 2ba7703..0e9f02a 100644
--- a/drivers/input/touchscreen/ti_am335x_tsc.c
+++ b/drivers/input/touchscreen/ti_am335x_tsc.c
@@ -314,10 +314,12 @@ static irqreturn_t titsc_irq(int irq, void *dev)
titsc_writel(ts_dev, REG_IRQCLR, IRQENB_HW_PEN);
}
 
-   titsc_writel(ts_dev, REG_IRQSTATUS, irqclr);
-
-   am335x_tsc_se_update(ts_dev-mfd_tscadc);
-   return IRQ_HANDLED;
+   if (irqclr) {
+   titsc_writel(ts_dev, REG_IRQSTATUS, irqclr);
+   am335x_tsc_se_update(ts_dev-mfd_tscadc);
+   return IRQ_HANDLED;
+   }
+   return IRQ_NONE;
 }
 
 static int titsc_parse_dt(struct platform_device *pdev,
-- 
1.7.10.4

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH 14/21] input: mfd: ti_am335x_tsc remove remaining platform data pieces

2013-06-12 Thread Sebastian Andrzej Siewior
The two header files removed here are unused and have no users as this
platform was never used with platform devices.

Signed-off-by: Sebastian Andrzej Siewior bige...@linutronix.de
---
 include/linux/input/ti_am335x_tsc.h |   35 ---
 include/linux/mfd/ti_am335x_tscadc.h|5 
 include/linux/platform_data/ti_am335x_adc.h |   14 ---
 3 files changed, 54 deletions(-)
 delete mode 100644 include/linux/input/ti_am335x_tsc.h
 delete mode 100644 include/linux/platform_data/ti_am335x_adc.h

diff --git a/include/linux/input/ti_am335x_tsc.h 
b/include/linux/input/ti_am335x_tsc.h
deleted file mode 100644
index 6a66b4d..000
--- a/include/linux/input/ti_am335x_tsc.h
+++ /dev/null
@@ -1,35 +0,0 @@
-#ifndef __LINUX_TI_AM335X_TSC_H
-#define __LINUX_TI_AM335X_TSC_H
-
-/**
- * struct tsc_data Touchscreen wire configuration
- * @wires: Wires refer to application modes
- * i.e. 4/5/8 wire touchscreen support
- * on the platform.
- * @x_plate_resistance:X plate resistance.
- * @steps_to_configure:The sequencer supports a total of
- * 16 programmable steps.
- * A step configured to read a single
- * co-ordinate value, can be applied
- * more number of times for better results.
- * @wire_config:   Different EVM's could have a different order
- * for connecting wires on touchscreen.
- * We need to provide an 8 bit number where in
- * the 1st four bits represent the analog lines
- * and the next 4 bits represent positive/
- * negative terminal on that input line.
- * Notations to represent the input lines and
- * terminals resoectively is as follows:
- * AIN0 = 0, AIN1 = 1 and so on till AIN7 = 7.
- * XP  = 0, XN = 1, YP = 2, YN = 3.
- *
- */
-
-struct tsc_data {
-   int wires;
-   int x_plate_resistance;
-   int steps_to_configure;
-   int wire_config[10];
-};
-
-#endif
diff --git a/include/linux/mfd/ti_am335x_tscadc.h 
b/include/linux/mfd/ti_am335x_tscadc.h
index fe54ba4..533f200 100644
--- a/include/linux/mfd/ti_am335x_tscadc.h
+++ b/include/linux/mfd/ti_am335x_tscadc.h
@@ -120,11 +120,6 @@
 
 #define TSCADC_CELLS   2
 
-struct mfd_tscadc_board {
-   struct tsc_data *tsc_init;
-   struct adc_data *adc_init;
-};
-
 struct ti_tscadc_dev {
struct device *dev;
struct regmap *regmap_tscadc;
diff --git a/include/linux/platform_data/ti_am335x_adc.h 
b/include/linux/platform_data/ti_am335x_adc.h
deleted file mode 100644
index e41d583..000
--- a/include/linux/platform_data/ti_am335x_adc.h
+++ /dev/null
@@ -1,14 +0,0 @@
-#ifndef __LINUX_TI_AM335X_ADC_H
-#define __LINUX_TI_AM335X_ADC_H
-
-/**
- * struct adc_data ADC Input information
- * @adc_channels:  Number of analog inputs
- * available for ADC.
- */
-
-struct adc_data {
-   unsigned int adc_channels;
-};
-
-#endif
-- 
1.7.10.4

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH] ARM: OMAP4: hwmod data: Remove irq entries from mcspi, mmc hwmods

2013-06-12 Thread Tony Lindgren
* Sricharan R r.sricha...@ti.com [130609 23:51]:
 Commit '3b9b10151c6838af52244cec4af41a938bb5b7ec' cleaned up the
 data file to remove all irq and dma entries for all hwmods, which
 are now populated by DT. But mcspi and mmc irq, dma entries were
 retained since MMC, NFS boot was not working. Since it is root caused
 to be an issue with only DMA entries [1], irq can be safely removed.
 
 [1] http://www.mail-archive.com/linux-omap@vger.kernel.org/msg90115.html

Thanks applying into omap-for-v3.11/cleanup.

Regards,

Tony
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH v4 2/3] arm: gpmc: Low power transition support

2013-06-12 Thread Tony Lindgren
* Tony Lindgren t...@atomide.com [130612 10:08]:
 * Pekon Gupta pe...@ti.com [130612 04:07]:
  From: avinash philip avinashphi...@ti.com
  
  With GPMC converted to platform driver recently, adds low power
  transition support in driver itself.
 
 Applying the first two patches of this series into omap-for-v3.11/gpmc.
 Not taking the MTD patch, if it has dependencies to the first two
 patches please let me know and also get an ack from Artem if you
 want me to take it.

Oops, dropping the second patch in this series as it causes the
following if only omap4 is selected for example:

arch/arm/mach-omap2/built-in.o: In function `gpmc_resume':
dss-common.c:(.text+0x9a8): undefined reference to `omap3_gpmc_restore_context'
arch/arm/mach-omap2/built-in.o: In function `gpmc_suspend':
dss-common.c:(.text+0x9c8): undefined reference to `omap3_gpmc_save_context'

Can you please take a lok and fix that?

Regards,

Tony
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH v2 09/10] ARM: dts: omap3: add pbias and mmc_init pinctrl states

2013-06-12 Thread Balaji T K

On Wednesday 12 June 2013 08:05 PM, Tony Lindgren wrote:

* Balaji T K balaj...@ti.com [130606 12:20]:

add pbias states for pbias 0, 1.8V, 3V
add omap3 sd/mmc2 loop back clock config for devconf1 in mmc2_init pinctrl state
add OMAP3430 sd/mmc1 loop back clock config for devconf0 in mmc1_init pinctrl 
state
add OMAP3630 sd/mmc1 speed mode config for prog_io1 in mmc1_init pinctrl state


Looks OK to me, except these should be under mmc1 for omap[345].dtsi files.



I think I can move omap3_pmx_general to omap3.dtsi and override
pbias_1v8, pbias_3v in omap36xx.dtsi, but I doubt pinctrl-[0,1,2,3,4]
since pull up setting can vary between boards.


Regards,

Tony


Signed-off-by: Balaji T K balaj...@ti.com
---
  arch/arm/boot/dts/omap3-beagle-xm.dts |   42 +
  arch/arm/boot/dts/omap3-beagle.dts|   42 +
  arch/arm/boot/dts/omap3.dtsi  |   10 
  3 files changed, 94 insertions(+), 0 deletions(-)

diff --git a/arch/arm/boot/dts/omap3-beagle-xm.dts 
b/arch/arm/boot/dts/omap3-beagle-xm.dts
index 3046d1f..45d1642 100644
--- a/arch/arm/boot/dts/omap3-beagle-xm.dts
+++ b/arch/arm/boot/dts/omap3-beagle-xm.dts
@@ -59,6 +59,40 @@
};
  };

+omap3_pmx_general {
+   pinctrl-names = default;
+   pinctrl-0 = ;
+   pbias_off: pinmux_pbias_off {
+   pinctrl-single,bits = 
+   0x2b0 0x1 0x3   /* pbias */
+   ;
+   };
+
+   pbias_1v8: pinmux_pbias_1v8 {
+   pinctrl-single,bits = 
+   0x2b0 0x2 0x3   /* pbias */
+   ;
+   };
+
+   pbias_3v: pinmux_pbias_3v {
+   pinctrl-single,bits = 
+   0x2b0 0x3 0x3   /* pbias */
+   ;
+   };
+
+   mmc1_init: pinmux_mmc1_init {
+   pinctrl-single,bits = 
+   0x1d8 0x10 0x10 /* prog_io1 */
+   ;
+   };
+
+   mmc2_init: pinmux_mmc2_init {
+   pinctrl-single,bits = 
+   0x68 0x40 0x40  /* devconf1 */
+   ;
+   };
+};
+
  i2c1 {
clock-frequency = 260;



--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH v2 06/10] mmc: omap_hsmmc: add support for pbias configuration in dt

2013-06-12 Thread Balaji T K

On Wednesday 12 June 2013 08:07 PM, Tony Lindgren wrote:

* Balaji T K balaj...@ti.com [130606 12:20]:

PBIAS register configuration is based on the regulator voltage
which supplies these pbias cells, sd i/o pads.
With PBIAS register address and bit definitions different across
omap[3,4,5], Simplify PBIAS configuration under three different
regulator voltage levels - O V, 1.8 V, 3 V. Corresponding pinctrl states
are defined as pbias_off, pbias_1v8, pbias_3v.

pinctrl state mmc_init is used for configuring speed mode, loopback clock
(in devconf0/devconf1/prog_io1 register for omap3) and pull strength
configuration (in control_mmc1 for omap4)

Signed-off-by: Balaji T K balaj...@ti.com
---
  drivers/mmc/host/omap_hsmmc.c |   83 ++--
  1 files changed, 78 insertions(+), 5 deletions(-)

diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index 533ced2..8dd1cd3 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -182,6 +182,9 @@ struct omap_hsmmc_host {
int req_in_progress;
struct omap_hsmmc_next  next_data;

+   struct pinctrl  *pinctrl;
+   struct pinctrl_state*pbias_off, *pbias_1v8, *pbias_3v, *mmc_init;
+
struct  omap_mmc_platform_data  *pdata;
int needs_vmmc:1;
int needs_vmmc_aux:1;
@@ -267,6 +270,12 @@ static int omap_hsmmc_set_power(struct device *dev, int 
slot, int power_on,
if (mmc_slot(host).before_set_reg)
mmc_slot(host).before_set_reg(dev, slot, power_on, vdd);

+   if (host-pinctrl  host-pbias_off) {
+   ret = pinctrl_select_state(host-pinctrl, host-pbias_off);
+   if (ret  0)
+   dev_err(host-dev, pinctrl pbias_off select error\n);
+   }
+
/*
 * Assume Vcc regulator is used only to power the card ... OMAP
 * VDDS is used to power the pins, optionally with a transceiver to
@@ -304,6 +313,25 @@ static int omap_hsmmc_set_power(struct device *dev, int 
slot, int power_on,
if (mmc_slot(host).after_set_reg)
mmc_slot(host).after_set_reg(dev, slot, power_on, vdd);

+   /* 100ms delay required for PBIAS configuration */
+   msleep(100);


Hmm, why is the delay needed before the configuration? Is this something
you could avoid by reading the pinconf state maybe?


This delay is needed for regulator voltage to stabilize.




+   if (!vdd  host-pinctrl  host-pbias_off) {
+   ret = pinctrl_select_state(host-pinctrl, host-pbias_off);
+   if (ret  0)
+   dev_err(host-dev, pinctrl pbias_off select error\n);
+   } else if (((1  vdd) = MMC_VDD_165_195)  host-pinctrl 
+   host-pbias_1v8) {
+   ret = pinctrl_select_state(host-pinctrl, host-pbias_1v8);
+   if (ret  0)
+   dev_err(host-dev, pinctrl pbias_1v8 select error\n);
+   } else if (((1  vdd)  MMC_VDD_165_195)  host-pinctrl 
+   host-pbias_3v) {
+   ret = pinctrl_select_state(host-pinctrl, host-pbias_3v);
+   if (ret  0)
+   dev_err(host-dev, pinctrl pbias_3v select error\n);
+   }
+   usleep_range(350, 400);
+
return ret;
  }


Maybe add some macro for doing the if (((1  vdd) = MMC_VDD_165_195)... tests?


OK




@@ -1775,6 +1803,52 @@ static inline struct omap_mmc_platform_data
  }
  #endif

+static int omap_hsmmc_pinctrl_init(struct omap_hsmmc_host *host)
+{
+   int ret = 0;
+
+   host-pinctrl = devm_pinctrl_get(host-dev);
+   if (IS_ERR(host-pinctrl)) {
+   host-pinctrl = NULL;
+   dev_warn(host-dev,
+pins are not configured from the driver\n);
+   return 0;
+   }
+
+   host-mmc_init = pinctrl_lookup_state(host-pinctrl, mmc_init);
+   if (IS_ERR(host-mmc_init)) {
+   dev_vdbg(host-dev, optional: mmc_init lookup error);
+   host-mmc_init = NULL;
+   } else {
+   ret = pinctrl_select_state(host-pinctrl, host-mmc_init);
+   if (ret  0) {
+   dev_err(host-dev, pinctrl mmc_init select error\n);
+   goto err_pinctrl;
+   }
+   }
+
+   host-pbias_off = pinctrl_lookup_state(host-pinctrl, pbias_off);
+   if (IS_ERR(host-pbias_off)) {
+   dev_vdbg(host-dev, optional: pbias_off lookup error);
+   host-pbias_off = NULL;
+   }
+
+   host-pbias_1v8 = pinctrl_lookup_state(host-pinctrl, pbias_1v8);
+   if (IS_ERR(host-pbias_1v8)) {
+   dev_vdbg(host-dev, optional: pbias_1v8 lookup error);
+   host-pbias_1v8 = NULL;
+   }
+
+   host-pbias_3v = pinctrl_lookup_state(host-pinctrl, pbias_3v);
+   if (IS_ERR(host-pbias_3v)) {
+   dev_vdbg(host-dev, optional: pbias_3v lookup error);
+   

Re: OMAP v3.10-rc regressions that no one's fixed

2013-06-12 Thread Tony Lindgren
* Paul Walmsley p...@pwsan.com [130610 00:27]:
 
 Hi folks -- particularly TIers working on mainline,
 
 There are several regressions that started with v3.10-rc that no one's 
 fixed for over a month.  Some of them should be quite easy:
 
 * 37xx EVM: boot fails
   - as of v3.10-rc1
   - Cause unknown

This one is probably because of broken GPIO numbering in
the board file that uses hardcoded GPIOs for what are probably
twl GPIOs.

Does commenting out omap3_evm_display_init() in the board file
fix the booting for you?

If so, we should probably mark omap3_evm_display_init() with
CONFIG_BROKEN for now rather than add more late init callback
functions for the twl code.

Regards,

Tony
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH v2 09/10] ARM: dts: omap3: add pbias and mmc_init pinctrl states

2013-06-12 Thread Tony Lindgren
* Balaji T K balaj...@ti.com [130612 10:50]:
 On Wednesday 12 June 2013 08:05 PM, Tony Lindgren wrote:
 * Balaji T K balaj...@ti.com [130606 12:20]:
 add pbias states for pbias 0, 1.8V, 3V
 add omap3 sd/mmc2 loop back clock config for devconf1 in mmc2_init pinctrl 
 state
 add OMAP3430 sd/mmc1 loop back clock config for devconf0 in mmc1_init 
 pinctrl state
 add OMAP3630 sd/mmc1 speed mode config for prog_io1 in mmc1_init pinctrl 
 state
 
 Looks OK to me, except these should be under mmc1 for omap[345].dtsi files.
 
 
 I think I can move omap3_pmx_general to omap3.dtsi and override
 pbias_1v8, pbias_3v in omap36xx.dtsi, but I doubt pinctrl-[0,1,2,3,4]
 since pull up setting can vary between boards.

OK makes sense to me if it's board specific.

Regards,

Tony
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH v2 08/10] ARM: dts: omap3: split omap3_pmx_core

2013-06-12 Thread Tony Lindgren
* Balaji T K balaj...@ti.com [130612 10:14]:
 On Wednesday 12 June 2013 08:05 PM, Tony Lindgren wrote:
 * Balaji T K balaj...@ti.com [130606 12:20]:
 omap3_pmx_core: padconf register are in two banks 0x48003000 to 0x48002268
 and 0x480025c0 to 0x480025f8.
 
 split omap3_pmx_core into 2 banks as register between 0x48002270 and 
 0x48002564
 belongs to type pinctrl-single,bit-per-mux with access to certain bit
 fields with bit field mask.
 
 Is this the right patch for the description? THe patch seems to deal with
 USB pins.
 
 Also, let's not hog any pins under the pinmux controllers, those make
 unloading pinctrl-single impossible which is not nice for distros and
 development.
 
 omap3_pmx_core is not continuous, so had to split into two and
 updated the only user in second bank (omap3_pmx_core2) which happened to be 
 usb,
 CC Roger for USB dynamic pin mux selection.

I see. OK yes we can split it as that saves memory too for the unused
registers. While at it, please move remove the hogs from the pmx
entries and move the pins to the drivers claiming them.

Regards,

TOny
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH v5] i2c: omap: correct usage of the interrupt enable register

2013-06-12 Thread Wolfram Sang
On Mon, Jun 03, 2013 at 10:37:20AM +0300, Oleksandr Dmytryshyn wrote:
 We've been lucky not to have any interrupts fire during the suspend
 path, otherwise we would have unpredictable behaviour in the kernel.
 
 Based on the logic of the kernel code interrupts from i2c should be
 prohibited during suspend. Kernel writes 0 to the I2C_IE register in
 the omap_i2c_runtime_suspend() function. In the other side kernel
 writes saved interrupt flags to the I2C_IE register in
 omap_i2c_runtime_resume() function. I.e. interrupts should be disabled
 during suspend.
 
 This works for chips with version1 registers scheme. Interrupts are
 disabled during suspend. For chips with version2 scheme registers
 writting 0 to the I2C_IE register does nothing (because now the
 I2C_IRQENABLE_SET register is located at this address). This register
 is used to enable interrupts. For disabling interrupts
 I2C_IRQENABLE_CLR register should be used.
 
 Because the registers I2C_IRQENABLE_SET and I2C_IE have the same
 addresses, the interrupt enabling procedure is unchanged.
 
 I've checked that interrupts in the i2c controller are still enabled
 after writting 0 to the I2C_IRQENABLE_SET register. With this patch
 interrupts are disabled in the omap_i2c_runtime_suspend() function.
 
 Patch is based on:
 git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
 tag: v3.10-rc2
 
 Verified on OMAP4430.
 
 Signed-off-by: Oleksandr Dmytryshyn oleksandr.dmytrys...@ti.com

Kevin, I think you are fine with this patch now?



signature.asc
Description: Digital signature


[GIT PULL 1/6] non-critical omap fixes for v3.11 merge window

2013-06-12 Thread Tony Lindgren
The following changes since commit 317ddd256b9c24b0d78fa8018f80f1e495481a10:

  Linux 3.10-rc5 (2013-06-08 17:41:04 -0700)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap 
tags/omap-for-v3.11/fixes-non-critical-signed

for you to fetch changes up to e41a5f88b374f7b1d87a72740d186be20cae4aa8:

  ARM: OMAP2+: omap-usb-host: Fix memory leaks (2013-06-12 10:04:10 -0700)


Non-critical fixes for omaps for v3.11 merge window.


Peter Ujfalusi (3):
  ARM: OMAP2+: devices: Do not print error when McPDM hwmod lookup fails
  ARM: OMAP2+: devices: Do not print error when DMIC hwmod lookup fails
  ARM: OMAP2+: devices: Do not print error when dss_hdmi hwmod lookup fails

Roger Quadros (1):
  ARM: OMAP2+: omap-usb-host: Fix memory leaks

Sebastian Andrzej Siewior (1):
  arm/omap: use const char properly

Suman Anna (1):
  ARM: OMAP2+: control: add OMAP5 support for dsp boot programming

Tomi Valkeinen (3):
  ARM: OMAP: fix dsi regulator names
  ARM: OMAP: add vdds_dsi supply for omapdss_dpi.0
  ARM: OMAP: add vdds_sdi supply for omapdss_sdi.0

Tony Lindgren (2):
  Merge branch 'dss-regulator' into omap-for-v3.11/fixes-non-critical
  ARM: OMAP2+: Fix serial init for device tree based booting

 arch/arm/mach-omap2/board-cm-t35.c   |   3 +-
 arch/arm/mach-omap2/board-devkit8000.c   |   1 +
 arch/arm/mach-omap2/board-ldp.c  |   3 +-
 arch/arm/mach-omap2/board-omap3pandora.c |   1 +
 arch/arm/mach-omap2/board-rx51-peripherals.c |   1 +
 arch/arm/mach-omap2/control.c|   1 +
 arch/arm/mach-omap2/devices.c|  12 +--
 arch/arm/mach-omap2/id.c |   2 +-
 arch/arm/mach-omap2/serial.c |   3 +
 arch/arm/mach-omap2/twl-common.c |   1 +
 arch/arm/mach-omap2/usb-host.c   | 106 ++-
 11 files changed, 72 insertions(+), 62 deletions(-)
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [GIT PULL 6/6] omap5 data for v3.11 merge window

2013-06-12 Thread Santosh Shilimkar
On Wednesday 12 June 2013 02:24 PM, Tony Lindgren wrote:
 The following changes since commit 317ddd256b9c24b0d78fa8018f80f1e495481a10:
 
   Linux 3.10-rc5 (2013-06-08 17:41:04 -0700)
 
 are available in the git repository at:
 
   git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap 
 tags/omap-for-v3.11/omap5-signed
 
 for you to fetch changes up to 6503a8e109a639760408f874c1251060d563942e:
 
   ARM: OMAP5: Remove unused include for ocp2scp (2013-06-09 21:17:15 -0700)
 
 

[..]

 Basic test logs are available here, although not for OMAP5,
 since I don't have an OMAP5 board:
You happen to mention that you got one OMAP5 board form David A ?

Regards,
Santosh

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH] ARM: multi_v7: Add OMAP with ramdisk config bits

2013-06-12 Thread Santosh Shilimkar
Add ramdisk fileystem related options which lets OMAP5 and Keystone
SOCs to boot till shell with multi_v7_config.

Cc: Olof Johansson o...@lixom.net
Cc: Arnd Bergmann a...@arndb.de

Signed-off-by: Sricharan R r.sricha...@ti.com
Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
---
The ARCH_SIRF related fix is already in arm-soc as pointed by Olof on
IRC. So just sending the defconfig bits only. I didn't sync the
multi_v7_config with usual method since it was adding some unnecessary
delta to the $subject patch.

 arch/arm/configs/multi_v7_defconfig |9 +
 1 file changed, 9 insertions(+)

diff --git a/arch/arm/configs/multi_v7_defconfig 
b/arch/arm/configs/multi_v7_defconfig
index 2e67a27..efd12f4 100644
--- a/arch/arm/configs/multi_v7_defconfig
+++ b/arch/arm/configs/multi_v7_defconfig
@@ -1,11 +1,14 @@
 CONFIG_EXPERIMENTAL=y
 CONFIG_NO_HZ=y
 CONFIG_HIGH_RES_TIMERS=y
+CONFIG_BLK_DEV_INITRD=y
 CONFIG_ARCH_MVEBU=y
 CONFIG_MACH_ARMADA_370=y
 CONFIG_ARCH_SIRF=y
 CONFIG_MACH_ARMADA_XP=y
 CONFIG_ARCH_HIGHBANK=y
+CONFIG_ARCH_OMAP2PLUS=y
+CONFIG_SOC_OMAP5=y
 CONFIG_ARCH_SOCFPGA=y
 CONFIG_ARCH_SUNXI=y
 CONFIG_ARCH_WM8850=y
@@ -25,6 +28,9 @@ CONFIG_ARM_APPENDED_DTB=y
 CONFIG_VFP=y
 CONFIG_NEON=y
 CONFIG_NET=y
+CONFIG_DEVTMPFS=y
+CONFIG_DEVTMPFS_MOUNT=y
+CONFIG_BLK_DEV_RAM=y
 CONFIG_BLK_DEV_SD=y
 CONFIG_ATA=y
 CONFIG_SATA_HIGHBANK=y
@@ -38,6 +44,8 @@ CONFIG_SERIO_AMBAKMI=y
 CONFIG_SERIAL_8250=y
 CONFIG_SERIAL_8250_CONSOLE=y
 CONFIG_SERIAL_8250_DW=y
+CONFIG_SERIAL_OMAP=y
+CONFIG_SERIAL_OMAP_CONSOLE=y
 CONFIG_KEYBOARD_SPEAR=y
 CONFIG_SERIAL_AMBA_PL011=y
 CONFIG_SERIAL_AMBA_PL011_CONSOLE=y
@@ -81,3 +89,4 @@ CONFIG_DMADEVICES=y
 CONFIG_PL330_DMA=y
 CONFIG_SIRF_DMA=y
 CONFIG_DW_DMAC=y
+CONFIG_EXT2_FS=y
-- 
1.7.9.5

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[GIT PULL] move omap mailbox to drivers for v3.11

2013-06-12 Thread Suman Anna
The following changes since commit 317ddd256b9c24b0d78fa8018f80f1e495481a10:

  Linux 3.10-rc5 (2013-06-08 17:41:04 -0700)

are available in the git repository at:

  g...@github.com:sumananna/mailbox.git tags/omap-mailbox-for-v3.11

for you to fetch changes up to c869c75c16b3d1ffcf64fb2fd63ba0c4a369071c:

  mailbox/omap: move the OMAP mailbox framework to drivers (2013-06-11 11:41:51 
-0500)


Move OMAP Mailbox framework to drivers

The OMAP Mailbox driver framework is moved out of arch/arm folder
into drivers/mailbox folder, to re-enable building it and also serve
as a baseline for adapting to the new mailbox driver framework. The
changes mainly contain:
  - a minor bug fix and cleanup of mach-specific mailbox code
  - remove any header dependencies from plat-omap for multi-platform
support
  - represent mailbox device data through platform data/hwmod attrs
  - move the omap mailbox code out of plat-omap/mach-omapX to
drivers/mailbox folder.


Suman Anna (6):
  omap: mailbox: check iomem resource before dereferencing it
  omap: mailbox: call request_irq after mbox queues are allocated
  omap: mailbox: correct the argument type for irq ops
  ARM: OMAP2+: mbox: remove dependencies with soc.h
  ARM: OMAP2+: add user and fifo info to mailbox platform data
  mailbox/omap: move the OMAP mailbox framework to drivers

 arch/arm/configs/omap1_defconfig   |   3 +-
 arch/arm/mach-omap1/Makefile   |   4 -
 arch/arm/mach-omap2/Makefile   |   3 -
 arch/arm/mach-omap2/devices.c  |  13 +-
 arch/arm/mach-omap2/omap_hwmod_2420_data.c |  14 ++
 arch/arm/mach-omap2/omap_hwmod_2430_data.c |  13 +
 arch/arm/mach-omap2/omap_hwmod_3xxx_data.c |  13 +
 arch/arm/plat-omap/Kconfig |  16 --
 arch/arm/plat-omap/Makefile|   3 -
 drivers/mailbox/Kconfig|  34 +++
 drivers/mailbox/Makefile   |   6 +
 .../mailbox.c = drivers/mailbox/mailbox-omap1.c   |  12 +-
 .../mailbox.c = drivers/mailbox/mailbox-omap2.c   | 276 -
 .../mailbox.c = drivers/mailbox/omap-mailbox.c|  54 +++-
 .../plat/mailbox.h = drivers/mailbox/omap-mbox.h  |  70 ++
 drivers/remoteproc/Kconfig |   3 +-
 drivers/remoteproc/omap_remoteproc.c   |   2 +-
 drivers/staging/tidspbridge/Kconfig|   3 +-
 .../tidspbridge/include/dspbridge/host_os.h|   2 +-
 include/linux/omap-mailbox.h   |  29 +++
 include/linux/platform_data/mailbox-omap.h |  58 +
 21 files changed, 355 insertions(+), 276 deletions(-)
 rename arch/arm/mach-omap1/mailbox.c = drivers/mailbox/mailbox-omap1.c (94%)
 rename arch/arm/mach-omap2/mailbox.c = drivers/mailbox/mailbox-omap2.c (59%)
 rename arch/arm/plat-omap/mailbox.c = drivers/mailbox/omap-mailbox.c (92%)
 rename arch/arm/plat-omap/include/plat/mailbox.h = 
drivers/mailbox/omap-mbox.h (54%)
 create mode 100644 include/linux/omap-mailbox.h
 create mode 100644 include/linux/platform_data/mailbox-omap.h
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH 13/14] ARM: AM33XX: hwmod data: irq, dma and addr info clean up

2013-06-12 Thread Kevin Hilman
Hi Vaibhav,

Hiremath, Vaibhav hvaib...@ti.com writes:

[...]

 Paul/Kevin/Santosh,

 AM335x is booting up from Mainline, starting from v3.7, that’s where HWMOD 
 data got merged to
 Mainline.

 We have discussed on this in the past as well, let me explain the issue here 
 in detail
 again for everybody -

Thanks for the detail.

In my case, after more debug, it appears that where I was putting the
DTB in memory from u-boot was not working.   Using the addresses you
used gets things working again.  Thanks.

u-boot mainline (v2013.04) for BeagleBone has defaults that don't work
appear together:

U-Boot# printenv loadaddr
loadaddr=0x8020
U-Boot# printenv fdtaddr
fdtaddr=0x80F8

Changing fdtaddr around got things working again.  It's probably a good
idea to change the u-boot defaults to values that work, since that's a
likely starting point for people.

I'm now back to mainline booting well on both my original BeagleBone and
my BeagleBone black.

Thanks,

Kevin

 In case of Am335x we have only two possible options, as AM335x only boots up
 With DTB (Tested in BBB) -

 1. Mainline u-boot + mainline Kernel:
 =

 1.a. Appended DTB method
 

 Here you __must__ enabled below config options in order to get kernel booting,

 CONFIG_ARM_APPENDED_DTB=y
 CONFIG_ARM_ATAG_DTB_COMPAT=y
 CONFIG_ARM_ATAG_DTB_COMPAT_CMDLINE_FROM_BOOTLOADER=y

 And, I have used below command to append DTB to kernel image

 # cat arch/arm/boot/zImage arch/arm/boot/dts/am335x-bone.dtb 
 zImage-append  mkimage -A arm -O linux -T kernel -C none -a
 0x80008000 -e 0x80008000 -n Linux -d zImage-append uImage-append


 I have attached complete log here with this mail for reference
 http://pastebin.com/82duFh78


 1.b. Discrete DTB and uImage method:
 

 Here you don’t need to enable any extra config options. Plain 
 omap2plus_defconfig
 Should work without any issues.

 I have attached complete log here with this mail for reference
 http://pastebin.com/Nqr0PiwW


 2. Older U-Boot (without DTB) + Mainline Kernel:
 

 This is same as #OPTION-1.a above.


 Thanks,
 Vaibhav
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [GIT PULL] move omap mailbox to drivers for v3.11

2013-06-12 Thread Felipe Balbi
Hi,

On Wed, Jun 12, 2013 at 04:58:26PM -0500, Suman Anna wrote:
 The following changes since commit 317ddd256b9c24b0d78fa8018f80f1e495481a10:
 
   Linux 3.10-rc5 (2013-06-08 17:41:04 -0700)
 
 are available in the git repository at:
 
   g...@github.com:sumananna/mailbox.git tags/omap-mailbox-for-v3.11

Tony might not have an ssh account on github, when sending pull requests
make sure to use the git read-only URL.

We even have separate url and pushurl attributes for the repository.
Should be enough to just edit .git/config and fix it up.

-- 
balbi


signature.asc
Description: Digital signature


RE: [PATCH v4] ARM: dts: OMAP5: Add palmas MFD node and regulator nodes

2013-06-12 Thread J, KEERTHY
Hi Stephen,

 -Original Message-
 From: Stephen Warren [mailto:swar...@wwwdotorg.org]
 Sent: Wednesday, June 12, 2013 9:22 PM
 To: J, KEERTHY
 Cc: Cousson, Benoit; devicetree-disc...@lists.ozlabs.org; linux-
 o...@vger.kernel.org; linux-ker...@vger.kernel.org;
 ldewan...@nvidia.com; grant.lik...@secretlab.ca; swar...@nvidia.com;
 sa...@linux.intel.com; g...@slimlogic.co.uk; lee.jo...@linaro.org
 Subject: Re: [PATCH v4] ARM: dts: OMAP5: Add palmas MFD node and
 regulator nodes
 
 On 06/12/2013 02:19 AM, J Keerthy wrote:
  This patch adds Palmas MFD node and the regulator nodes for OMAP5.
 
  The node definitions are based on: https://lkml.org/lkml/2013/6/6/25
 
  Boot tested on omap5-uevm board.
 
 Reviewed-by: Stephen Warren swar...@nvidia.com

Thanks..

 
  diff --git a/arch/arm/boot/dts/omap5-uevm.dts
  b/arch/arm/boot/dts/omap5-uevm.dts
 
  +   palmas: palmas@48 {
  +   reg = 0x48;
  +   interrupts = GIC_SPI 7 IRQ_TYPE_LEVEL_HIGH; /* IRQ_SYS_1N
 */
  +   interrupt-parent = gic;
  +   compatible = ti,palmas;
 
 ... although personally I prefer the compatible property to be right at
 the top of each node, since it's what implies the schema for the rest
 of the node. That's a tiny nit though; feel free to ignore it if the
 OMAP files don't follow that convention.

Sure. I will send hopefully the last version incorporating this :-).

Regards,
Keerthy
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


  1   2   >