Re: [PATCH] pinctrl: dra: dt-bindings: Fix output pull up/down

[Roger Quadros]

On 10/31/2014 03:50 PM, Nishanth Menon wrote:
 On 12:52-20141031, Roger Quadros wrote:
 For PIN_OUTPUT_PULLUP and PIN_OUTPUT_PULLDOWN we must not set the
 PULL_DIS bit which disables the PULLs.

 While at that get rid for the PULL_ENA defination. It is misleading
 as there is no PULL enable bit in the register. And a zero bit defination
 makes no sense.
 It was done to make it readable. Pull is enabled when that bit is 0 and
 disabled when that bit is 1. it is counter intutive enough for a macro

But you can't enable the PULL by ORing it. you have to AND it's inverted 
version with the rest.
It is confusing because it doesn't follow the logic of the other bit masks.

 to be defined. I suggest retaining that and not mixing with the current
 patch.

Agreed. I'll revise this patch to not touch that macro.

cheers,
-roger

 
 

 Fixes: 23d9cec07c58 (:pinctrl: dra: dt-bindings: Fix pull enable/disable)
 s/:pinctrl/pinctrl/ ?
 

 Signed-off-by: Roger Quadros rog...@ti.com
 ---
  include/dt-bindings/pinctrl/dra.h | 9 -
  1 file changed, 4 insertions(+), 5 deletions(-)

 diff --git a/include/dt-bindings/pinctrl/dra.h 
 b/include/dt-bindings/pinctrl/dra.h
 index 3d33794..71098e4 100644
 --- a/include/dt-bindings/pinctrl/dra.h
 +++ b/include/dt-bindings/pinctrl/dra.h
 @@ -30,7 +30,6 @@
  #define MUX_MODE14  0xe
  #define MUX_MODE15  0xf
  
 -#define PULL_ENA(0  16)
  #define PULL_DIS(1  16)
  #define PULL_UP (1  17)
  #define INPUT_EN(1  18)
 @@ -40,12 +39,12 @@
  
  /* Active pin states */
  #define PIN_OUTPUT  (0 | PULL_DIS)
 -#define PIN_OUTPUT_PULLUP   (PIN_OUTPUT | PULL_ENA | PULL_UP)
 -#define PIN_OUTPUT_PULLDOWN (PIN_OUTPUT | PULL_ENA)
 +#define PIN_OUTPUT_PULLUP   (PULL_UP)
 +#define PIN_OUTPUT_PULLDOWN (0)
  #define PIN_INPUT   (INPUT_EN | PULL_DIS)
  #define PIN_INPUT_SLEW  (INPUT_EN | SLEWCONTROL)
 -#define PIN_INPUT_PULLUP(PULL_ENA | INPUT_EN | PULL_UP)
 -#define PIN_INPUT_PULLDOWN  (PULL_ENA | INPUT_EN)
 +#define PIN_INPUT_PULLUP(INPUT_EN | PULL_UP)
 +#define PIN_INPUT_PULLDOWN  (INPUT_EN)
  
  #endif
  
 -- 
 1.8.3.2

 

--
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 01/10] ARM: dts: Fix bootloader version dependencies by muxing n900 smc91x pins

[Roger Quadros]

On 10/30/2014 05:49 PM, Tony Lindgren wrote:
 * Roger Quadros rog...@ti.com [141030 05:01]:
 On 10/30/2014 02:28 AM, Tony Lindgren wrote:
 +
 +   /*
 +* gpmc_ncs0, gpmc_nadv_ale, gpmc_noe, gpmc_nwe, 
 gpmc_wait0 not muxable
 +* according to TRM. REVISIT: why does nolo set input 
 for gpmc_clk?
 +*/
 +OMAP3_CORE1_IOPAD(0x20b0, PIN_OUTPUT | MUX_MODE0)  
  /* gpmc_ncs1.gpmc_ncs1 */
 +OMAP3_CORE1_IOPAD(0x20be, PIN_INPUT | MUX_MODE0)   
  /* gpmc_clk.gpmc_clk */

 Right about the comment. GPMC_CLK should feed the CLK input of the OneNAND.
 This needs to be an OUTPUT pin.

 Does OneNAND work when this pin is configured as output?
 
 Does not seem to work, it produces onenand_wait: ECC error = 0x.
 
 It seems the clock needs to be copied to GPMC too in some cases.
 For MMC, there's the MMCSDIO2ADPCLKISEL option to copy the clock to
 account for level shifter latencies [1]. But in the OneNAND case I
 don't think there are any level shifters, and I don't think we have
 copy clock option for GPMC either in SCM so it somehow is automatic
 in GPMC.
 
 Anyways, updated patch below with wrong guessing removed.
 
 Regards,
 
 Tony
 
 [1] 
 http://processors.wiki.ti.com/index.php/SD-MMC_Usage_Notes_on_OMAP35x_and_AM37x
 
 
 8 
 From: Tony Lindgren t...@atomide.com
 Date: Wed, 29 Oct 2014 17:16:47 -0700
 Subject: [PATCH] ARM: dts: Fix bootloader version dependencies by muxing n900 
 smc91x pins
 
 Apparently some versions of nolo don't mux the all the necessary GPMC
 pins for the smc91x probe to work properly. Let's fix this issue
 by adding mux support for GPMC to the kernel.
 
 Note that GPMC clk needs input enabled for OnenNAND to work.
 
 Cc: Kevin Hilman khil...@kernel.org
 Cc: Roger Quadros rog...@ti.com
 Signed-off-by: Tony Lindgren t...@atomide.com

Acked-by: Roger Quadros rog...@ti.com

cheers,
-roger
--
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 1/1] ARM: dts: dra72x-evm: Enable CPSW and MDIO

[Mugunthan V N]

Adding CPSW phy-id, CPSW and MDIO pinmux configuration for active and
sleep states and enable them in board evm dts file.

Signed-off-by: Mugunthan V N mugunthan...@ti.com
---

Adding device tree entry for CPSW to make it work in Switch mode.
Patches are tested on top of Nishanth's PM tree for v3.17 [1] and pushed
my tree to [2].

Did a boot test with CPSW and ping test with suspend/resume, the boot logs
on DRA72x EVM are posted at [3]

This patch depends on the DRA7xx CPSW support patch series [4] and one driver
patch (47276fc drivers: net:cpsw: fix probe_dt when only slave 1 is pinned out)
which is already present in linux-next

[1] git://github.com/nmenon/linux-2.6-playground.git 
testing/v3.17/cpu-idle-suspend-dra7-omap5-framework
[2] git://git.ti.com/~mugunthanvnm/ti-linux-kernel/linux.git 
for-v3.19/dra72-evm-cpsw
[3] http://pastebin.ubuntu.com/8800549/
[4] http://comments.gmane.org/gmane.linux.kernel/1810171

---
 arch/arm/boot/dts/dra72-evm.dts | 73 +
 1 file changed, 73 insertions(+)

diff --git a/arch/arm/boot/dts/dra72-evm.dts b/arch/arm/boot/dts/dra72-evm.dts
index 5147023..b8ebf89 100644
--- a/arch/arm/boot/dts/dra72-evm.dts
+++ b/arch/arm/boot/dts/dra72-evm.dts
@@ -22,3 +22,76 @@
 uart1 {
status = okay;
 };
+
+dra7_pmx_core {
+   cpsw_default: cpsw_default {
+   pinctrl-single,pins = 
+   /* Slave 2 */
+   0x198 (PIN_OUTPUT | MUX_MODE3)  /* vin2a_d12.rgmii1_txc 
*/
+   0x19c (PIN_OUTPUT | MUX_MODE3)  /* 
vin2a_d13.rgmii1_tctl */
+   0x1a0 (PIN_OUTPUT | MUX_MODE3)  /* vin2a_d14.rgmii1_td3 
*/
+   0x1a4 (PIN_OUTPUT | MUX_MODE3)  /* vin2a_d15.rgmii1_td2 
*/
+   0x1a8 (PIN_OUTPUT | MUX_MODE3)  /* vin2a_d16.rgmii1_td1 
*/
+   0x1ac (PIN_OUTPUT | MUX_MODE3)  /* vin2a_d17.rgmii1_td0 
*/
+   0x1b0 (PIN_INPUT | MUX_MODE3)   /* 
vin2a_d18.rgmii1_rclk */
+   0x1b4 (PIN_INPUT | MUX_MODE3)   /* 
vin2a_d19.rgmii1_rctl */
+   0x1b8 (PIN_INPUT | MUX_MODE3)   /* vin2a_d20.rgmii1_rd3 
*/
+   0x1bc (PIN_INPUT | MUX_MODE3)   /* vin2a_d21.rgmii1_rd2 
*/
+   0x1c0 (PIN_INPUT | MUX_MODE3)   /* vin2a_d22.rgmii1_rd1 
*/
+   0x1c4 (PIN_INPUT | MUX_MODE3)   /* vin2a_d23.rgmii1_rd0 
*/
+   ;
+
+   };
+
+   cpsw_sleep: cpsw_sleep {
+   pinctrl-single,pins = 
+   /* Slave 2 */
+   0x198 (MUX_MODE15)
+   0x19c (MUX_MODE15)
+   0x1a0 (MUX_MODE15)
+   0x1a4 (MUX_MODE15)
+   0x1a8 (MUX_MODE15)
+   0x1ac (MUX_MODE15)
+   0x1b0 (MUX_MODE15)
+   0x1b4 (MUX_MODE15)
+   0x1b8 (MUX_MODE15)
+   0x1bc (MUX_MODE15)
+   0x1c0 (MUX_MODE15)
+   0x1c4 (MUX_MODE15)
+   ;
+   };
+
+   davinci_mdio_default: davinci_mdio_default {
+   pinctrl-single,pins = 
+   /* MDIO */
+   0x23c (PIN_OUTPUT_PULLUP | MUX_MODE0)   /* 
mdio_d.mdio_d */
+   0x240 (PIN_INPUT_PULLUP | MUX_MODE0)/* 
mdio_clk.mdio_clk */
+   ;
+   };
+
+   davinci_mdio_sleep: davinci_mdio_sleep {
+   pinctrl-single,pins = 
+   0x23c (MUX_MODE15)
+   0x240 (MUX_MODE15)
+   ;
+   };
+};
+
+mac {
+   status = okay;
+   pinctrl-names = default, sleep;
+   pinctrl-0 = cpsw_default;
+   pinctrl-1 = cpsw_sleep;
+};
+
+cpsw_emac1 {
+   phy_id = davinci_mdio, 3;
+   phy-mode = rgmii;
+};
+
+davinci_mdio {
+   pinctrl-names = default, sleep;
+   pinctrl-0 = davinci_mdio_default;
+   pinctrl-1 = davinci_mdio_sleep;
+   active_slave = 1;
+};
-- 
2.1.2.484.g13da0fc

--
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] pinctrl: dra: dt-bindings: Fix output pull up/down

[Roger Quadros]

For PIN_OUTPUT_PULLUP and PIN_OUTPUT_PULLDOWN we must not set the
PULL_DIS bit which disables the PULLs.

PULL_ENA is a 0 and using it in an OR operation is a NOP, so don't
use it in the PIN_OUTPUT_PULLUP/DOWN macros.

Fixes: 23d9cec07c58 (pinctrl: dra: dt-bindings: Fix pull enable/disable)

Signed-off-by: Roger Quadros rog...@ti.com
---
 include/dt-bindings/pinctrl/dra.h | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/include/dt-bindings/pinctrl/dra.h 
b/include/dt-bindings/pinctrl/dra.h
index 3d33794..7448edf 100644
--- a/include/dt-bindings/pinctrl/dra.h
+++ b/include/dt-bindings/pinctrl/dra.h
@@ -40,8 +40,8 @@
 
 /* Active pin states */
 #define PIN_OUTPUT (0 | PULL_DIS)
-#define PIN_OUTPUT_PULLUP  (PIN_OUTPUT | PULL_ENA | PULL_UP)
-#define PIN_OUTPUT_PULLDOWN(PIN_OUTPUT | PULL_ENA)
+#define PIN_OUTPUT_PULLUP  (PULL_UP)
+#define PIN_OUTPUT_PULLDOWN(0)
 #define PIN_INPUT  (INPUT_EN | PULL_DIS)
 #define PIN_INPUT_SLEW (INPUT_EN | SLEWCONTROL)
 #define PIN_INPUT_PULLUP   (PULL_ENA | INPUT_EN | PULL_UP)
-- 
1.8.3.2

--
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/4] Touchscreen performance related fixes

[Sebastian Andrzej Siewior]

On 10/27/2014 08:02 PM, Griffis, Brad wrote:
 On 10/27/2014 12:34 PM, Sebastian Andrzej Siewior wrote:
 Do we really need #3 (and then #4)? Given the complexity we have already, is 
 there any benefit by decreasing this value? 
 
 I specifically requested we add ti,charge-delay to the device tree because it 
 is THE critical value to tune for a given design.  Although I think the 
 current value of 0xB000 will be suitable for a great many designs, I expect 
 that many users will need to adjust this value for their hardware.  Details 
 such as which touchscreen vendor is being used and how the touchscreen is 
 connected (header vs cable) have an effect on what's appropriate here.

Oh. That is one knob I hoped we could avoid since I haven't seen it
before on other TSCs. But okay. Please make sure that there is a
message printed if the default value is used. And lets hope the user
will do something about his.

 Would  someone want to increase it? Can we safely determine a value which 
 works for everyone?
 
 This value represents a hardware delay before checking for the pen-up event.  
 So in the scenario where someone is seeing excessive false pen-up events they 
 will want to increase this parameter.  The downsize of making this larger is 
 that it decreases the overall sampling speed of both the touchscreen as well 
 as the standalone ADC samples.  At one point I tried making it huge, but that 
 made the touchscreen overly sluggish because the sampling became too slow.  
 So there is a definite trade-off that if you make it too large the 
 touchscreen becomes sluggish, and if you make it too small then you may see 
 false pen-up events.  The optimal value will need to be tuned for a given 
 design.

I applied the patches from this series and did the following test on my
am335x-evm: A mug on the touchscreen (to make sure the events are
coming), evtest on the event node to see that the events and loop of

cat /sys/bus/iio/devices/iio\:device0/in_voltage4_raw

In the past I was able lock up the TSC/ADC HW that way (see commit
7ca6740cd1 (mfd: input: iio: ti_amm335x: Rework TSC/ADC
synchronization)) for details.
With this patches applied I don't seen any TSC events once the IIO
interface is (heavily) used. Can this be fixed?

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 v2] pinctrl: dra: dt-bindings: Fix output pull up/down

[Nishanth Menon]

On 12:09-20141103, Roger Quadros wrote:
 For PIN_OUTPUT_PULLUP and PIN_OUTPUT_PULLDOWN we must not set the
 PULL_DIS bit which disables the PULLs.
 
 PULL_ENA is a 0 and using it in an OR operation is a NOP, so don't
 use it in the PIN_OUTPUT_PULLUP/DOWN macros.
 
 Fixes: 23d9cec07c58 (pinctrl: dra: dt-bindings: Fix pull enable/disable)
 
 Signed-off-by: Roger Quadros rog...@ti.com
 ---
  include/dt-bindings/pinctrl/dra.h | 4 ++--
  1 file changed, 2 insertions(+), 2 deletions(-)
 
 diff --git a/include/dt-bindings/pinctrl/dra.h 
 b/include/dt-bindings/pinctrl/dra.h
 index 3d33794..7448edf 100644
 --- a/include/dt-bindings/pinctrl/dra.h
 +++ b/include/dt-bindings/pinctrl/dra.h
 @@ -40,8 +40,8 @@
  
  /* Active pin states */
  #define PIN_OUTPUT   (0 | PULL_DIS)
 -#define PIN_OUTPUT_PULLUP(PIN_OUTPUT | PULL_ENA | PULL_UP)
 -#define PIN_OUTPUT_PULLDOWN  (PIN_OUTPUT | PULL_ENA)
 +#define PIN_OUTPUT_PULLUP(PULL_UP)
 +#define PIN_OUTPUT_PULLDOWN  (0)
  #define PIN_INPUT(INPUT_EN | PULL_DIS)
  #define PIN_INPUT_SLEW   (INPUT_EN | SLEWCONTROL)
  #define PIN_INPUT_PULLUP (PULL_ENA | INPUT_EN | PULL_UP)

You are right, we do have an issue with using PIN_OUTPUT along with
remaining setting.

For a moment, I wondered why input was not impacted - then I realized
that INPUT_EN was being used instead of PIN_INPUT - following that
convention. With the intent being explicitly using macros that
clearly indicate what each setting combination is is, how about the
following?


diff --git a/include/dt-bindings/pinctrl/dra.h 
b/include/dt-bindings/pinctrl/dra.h
index 3d33794..d4037e7 100644
--- a/include/dt-bindings/pinctrl/dra.h
+++ b/include/dt-bindings/pinctrl/dra.h
@@ -34,14 +34,15 @@
 #define PULL_DIS   (1  16)
 #define PULL_UP(1  17)
 #define INPUT_EN   (1  18)
+#define OUTPUT_EN  (0  18)
 #define SLEWCONTROL(1  19)
 #define WAKEUP_EN  (1  24)
 #define WAKEUP_EVENT   (1  25)
 
 /* Active pin states */
-#define PIN_OUTPUT (0 | PULL_DIS)
-#define PIN_OUTPUT_PULLUP  (PIN_OUTPUT | PULL_ENA | PULL_UP)
-#define PIN_OUTPUT_PULLDOWN(PIN_OUTPUT | PULL_ENA)
+#define PIN_OUTPUT (OUTPUT_EN | PULL_DIS)
+#define PIN_OUTPUT_PULLUP  (OUTPUT_EN | PULL_ENA | PULL_UP)
+#define PIN_OUTPUT_PULLDOWN(OUTPUT_EN | PULL_ENA)
 #define PIN_INPUT  (INPUT_EN | PULL_DIS)
 #define PIN_INPUT_SLEW (INPUT_EN | SLEWCONTROL)
 #define PIN_INPUT_PULLUP   (PULL_ENA | INPUT_EN | PULL_UP)

-- 
Regards,
Nishanth Menon
--
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] pinctrl: dra: dt-bindings: Fix output pull up/down

[Roger Quadros]

On 11/03/2014 04:30 PM, Nishanth Menon wrote:
 On 12:09-20141103, Roger Quadros wrote:
 For PIN_OUTPUT_PULLUP and PIN_OUTPUT_PULLDOWN we must not set the
 PULL_DIS bit which disables the PULLs.

 PULL_ENA is a 0 and using it in an OR operation is a NOP, so don't
 use it in the PIN_OUTPUT_PULLUP/DOWN macros.

 Fixes: 23d9cec07c58 (pinctrl: dra: dt-bindings: Fix pull enable/disable)

 Signed-off-by: Roger Quadros rog...@ti.com
 ---
  include/dt-bindings/pinctrl/dra.h | 4 ++--
  1 file changed, 2 insertions(+), 2 deletions(-)

 diff --git a/include/dt-bindings/pinctrl/dra.h 
 b/include/dt-bindings/pinctrl/dra.h
 index 3d33794..7448edf 100644
 --- a/include/dt-bindings/pinctrl/dra.h
 +++ b/include/dt-bindings/pinctrl/dra.h
 @@ -40,8 +40,8 @@
  
  /* Active pin states */
  #define PIN_OUTPUT  (0 | PULL_DIS)
 -#define PIN_OUTPUT_PULLUP   (PIN_OUTPUT | PULL_ENA | PULL_UP)
 -#define PIN_OUTPUT_PULLDOWN (PIN_OUTPUT | PULL_ENA)
 +#define PIN_OUTPUT_PULLUP   (PULL_UP)
 +#define PIN_OUTPUT_PULLDOWN (0)
  #define PIN_INPUT   (INPUT_EN | PULL_DIS)
  #define PIN_INPUT_SLEW  (INPUT_EN | SLEWCONTROL)
  #define PIN_INPUT_PULLUP(PULL_ENA | INPUT_EN | PULL_UP)
 
 You are right, we do have an issue with using PIN_OUTPUT along with
 remaining setting.
 
 For a moment, I wondered why input was not impacted - then I realized
 that INPUT_EN was being used instead of PIN_INPUT - following that
 convention. With the intent being explicitly using macros that
 clearly indicate what each setting combination is is, how about the
 following?
 
 
 diff --git a/include/dt-bindings/pinctrl/dra.h 
 b/include/dt-bindings/pinctrl/dra.h
 index 3d33794..d4037e7 100644
 --- a/include/dt-bindings/pinctrl/dra.h
 +++ b/include/dt-bindings/pinctrl/dra.h
 @@ -34,14 +34,15 @@
  #define PULL_DIS (1  16)
  #define PULL_UP  (1  17)
  #define INPUT_EN (1  18)
 +#define OUTPUT_EN(0  18)
  #define SLEWCONTROL  (1  19)
  #define WAKEUP_EN(1  24)
  #define WAKEUP_EVENT (1  25)
  
  /* Active pin states */
 -#define PIN_OUTPUT   (0 | PULL_DIS)
 -#define PIN_OUTPUT_PULLUP(PIN_OUTPUT | PULL_ENA | PULL_UP)
 -#define PIN_OUTPUT_PULLDOWN  (PIN_OUTPUT | PULL_ENA)
 +#define PIN_OUTPUT   (OUTPUT_EN | PULL_DIS)
 +#define PIN_OUTPUT_PULLUP(OUTPUT_EN | PULL_ENA | PULL_UP)
 +#define PIN_OUTPUT_PULLDOWN  (OUTPUT_EN | PULL_ENA)

To me it adds more confusion and this change is a NOP as we're ORing 0 here
with OUTPUT_EN.

  #define PIN_INPUT(INPUT_EN | PULL_DIS)
  #define PIN_INPUT_SLEW   (INPUT_EN | SLEWCONTROL)
  #define PIN_INPUT_PULLUP (PULL_ENA | INPUT_EN | PULL_UP)
 

cheers,
-roger
--
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: dra7-evm: Keep all VDD rails always-on

[Roger Quadros]

Hi Nishant,

On 10/21/2014 05:38 PM, Nishanth Menon wrote:
 DRA7 Data Manual (SPRS857L - August 2014) section 4.1.1 states: All
 unused power supply balls must be supplied with the voltages specified
 in the Section 5.2, Recommended Operating Conditions.
 
 This implies that all unused voltage rails for Vayu can never be
 switched off even if the hardware blocks inside that voltage domain is
 unused. Switching off these unused rails may result in stability issues
 on other domains and increased leakage and power-on-hour impacts.
 
 J6eco-evm dts file already considers this, however j6evm-dts file needs
 to be fixed to consider this constraint of the SoC.
 
 Signed-off-by: Nishanth Menon n...@ti.com

Acked-by: Roger Quadros rog...@ti.com

I'm assuming that vddshv8 (MMC1 power group) can be switched off.

cheers,
-roger

 ---
 
 Patch is based on v3.18-rc1 tag.
 
  arch/arm/boot/dts/dra7-evm.dts |5 +
  1 file changed, 5 insertions(+)
 
 diff --git a/arch/arm/boot/dts/dra7-evm.dts b/arch/arm/boot/dts/dra7-evm.dts
 index c6ce625..4f4c469 100644
 --- a/arch/arm/boot/dts/dra7-evm.dts
 +++ b/arch/arm/boot/dts/dra7-evm.dts
 @@ -201,6 +201,7 @@
   regulator-name = smps45;
   regulator-min-microvolt =  85;
   regulator-max-microvolt = 115;
 + regulator-always-on;
   regulator-boot-on;
   };
  
 @@ -209,6 +210,7 @@
   regulator-name = smps6;
   regulator-min-microvolt = 85;
   regulator-max-microvolt = 1250;
 + regulator-always-on;
   regulator-boot-on;
   };
  
 @@ -226,6 +228,7 @@
   regulator-name = smps8;
   regulator-min-microvolt =  85;
   regulator-max-microvolt = 125;
 + regulator-always-on;
   regulator-boot-on;
   };
  
 @@ -252,6 +255,7 @@
   regulator-name = ldo2;
   regulator-min-microvolt = 330;
   regulator-max-microvolt = 330;
 + regulator-always-on;
   regulator-boot-on;
   };
  
 @@ -269,6 +273,7 @@
   regulator-name = ldo9;
   regulator-min-microvolt = 105;
   regulator-max-microvolt = 105;
 + regulator-always-on;
   regulator-boot-on;
   };
  
 

--
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] pinctrl: dra: dt-bindings: Fix output pull up/down

[Nishanth Menon]

On 11/03/2014 08:44 AM, Roger Quadros wrote:
 On 11/03/2014 04:30 PM, Nishanth Menon wrote:
 On 12:09-20141103, Roger Quadros wrote:
 For PIN_OUTPUT_PULLUP and PIN_OUTPUT_PULLDOWN we must not set the
 PULL_DIS bit which disables the PULLs.

 PULL_ENA is a 0 and using it in an OR operation is a NOP, so don't
 use it in the PIN_OUTPUT_PULLUP/DOWN macros.

 Fixes: 23d9cec07c58 (pinctrl: dra: dt-bindings: Fix pull enable/disable)

 Signed-off-by: Roger Quadros rog...@ti.com
 ---
  include/dt-bindings/pinctrl/dra.h | 4 ++--
  1 file changed, 2 insertions(+), 2 deletions(-)

 diff --git a/include/dt-bindings/pinctrl/dra.h 
 b/include/dt-bindings/pinctrl/dra.h
 index 3d33794..7448edf 100644
 --- a/include/dt-bindings/pinctrl/dra.h
 +++ b/include/dt-bindings/pinctrl/dra.h
 @@ -40,8 +40,8 @@
  
  /* Active pin states */
  #define PIN_OUTPUT (0 | PULL_DIS)
 -#define PIN_OUTPUT_PULLUP  (PIN_OUTPUT | PULL_ENA | PULL_UP)
 -#define PIN_OUTPUT_PULLDOWN(PIN_OUTPUT | PULL_ENA)
 +#define PIN_OUTPUT_PULLUP  (PULL_UP)
 +#define PIN_OUTPUT_PULLDOWN(0)
  #define PIN_INPUT  (INPUT_EN | PULL_DIS)
  #define PIN_INPUT_SLEW (INPUT_EN | SLEWCONTROL)
  #define PIN_INPUT_PULLUP   (PULL_ENA | INPUT_EN | PULL_UP)

 You are right, we do have an issue with using PIN_OUTPUT along with
 remaining setting.

 For a moment, I wondered why input was not impacted - then I realized
 that INPUT_EN was being used instead of PIN_INPUT - following that
 convention. With the intent being explicitly using macros that
 clearly indicate what each setting combination is is, how about the
 following?


 diff --git a/include/dt-bindings/pinctrl/dra.h 
 b/include/dt-bindings/pinctrl/dra.h
 index 3d33794..d4037e7 100644
 --- a/include/dt-bindings/pinctrl/dra.h
 +++ b/include/dt-bindings/pinctrl/dra.h
 @@ -34,14 +34,15 @@
  #define PULL_DIS(1  16)
  #define PULL_UP (1  17)
  #define INPUT_EN(1  18)
 +#define OUTPUT_EN   (0  18)
  #define SLEWCONTROL (1  19)
  #define WAKEUP_EN   (1  24)
  #define WAKEUP_EVENT(1  25)
  
  /* Active pin states */
 -#define PIN_OUTPUT  (0 | PULL_DIS)
 -#define PIN_OUTPUT_PULLUP   (PIN_OUTPUT | PULL_ENA | PULL_UP)
 -#define PIN_OUTPUT_PULLDOWN (PIN_OUTPUT | PULL_ENA)
 +#define PIN_OUTPUT  (OUTPUT_EN | PULL_DIS)
 +#define PIN_OUTPUT_PULLUP   (OUTPUT_EN | PULL_ENA | PULL_UP)
 +#define PIN_OUTPUT_PULLDOWN (OUTPUT_EN | PULL_ENA)
 
 To me it adds more confusion and this change is a NOP as we're ORing 0 here
 with OUTPUT_EN.

look at this this way:

PIN_OUTPUT_PULLDOWN (OUTPUT_EN | PULL_ENA)

should probably trigger in mind (what about PULLDOWN?)

PIN_OUTPUT_PULLDOWN (OUTPUT_EN | PULL_ENA | PULL_DOWN)

then verify values of each OUTPUT_EN  - 0 in bit 18, ok, etc.


if we ensure that PIN_XX macros use just the basic primitives, it is
easier to prevent the mistake like the one I made. the other option of
not defining macros whose values are 0 implies that the reviewer has
to recheck against trm to ensure all the right 1 bits are set.


just my view here.

 
  #define PIN_INPUT   (INPUT_EN | PULL_DIS)
  #define PIN_INPUT_SLEW  (INPUT_EN | SLEWCONTROL)
  #define PIN_INPUT_PULLUP(PULL_ENA | INPUT_EN | PULL_UP)

 
 cheers,
 -roger
 


-- 
Regards,
Nishanth Menon
--
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] input: touchscreen: ti_am335x_tsc: Remove udelay in interrupt handler

[Lee Jones]

On Mon, 27 Oct 2014, Vignesh R wrote:
 From: Brad Griffis bgrif...@ti.com
 
 TSC interrupt handler had udelay to avoid reporting of false pen-up
 interrupt to user space. This patch implements workaround suggesting in
 Advisory 1.0.31 of silicon errata for am335x, thus eliminating udelay
 and touchscreen lag. This also improves performance of touchscreen and
 eliminates sudden jump of cursor at touch release.
 
 IDLECONFIG and CHARGECONFIG registers are to be configured
 with same values in order to eliminate false pen-up events. This
 workaround may result in false pen-down to be detected, hence considerable
 charge step delay needs to be added. The charge delay is set to 0xB000
 (in terms of ADC clock cycles) by default.
 
 TSC steps are disabled at the end of every sampling cycle and EOS bit is
 set. Once the EOS bit is set, the TSC steps need to be re-enabled to begin
 next sampling cycle.
 
 In one shot mode, sequencer automatically disables all enabled steps at
 the end of each cycle. (both ADC steps and TSC steps) Hence these steps
 need not be saved in reg_se_cache for clearing these steps at a later
 stage.
 
 Signed-off-by: Brad Griffis bgrif...@ti.com
 [vigne...@ti.com: Ported patch from v3.12 to v3.18rc2]
 Signed-off-by: Vignesh R vigne...@ti.com
 ---
  drivers/input/touchscreen/ti_am335x_tsc.c | 56 
 ---
  drivers/mfd/ti_am335x_tscadc.c|  7 ++--
  include/linux/mfd/ti_am335x_tscadc.h  |  4 ++-
  3 files changed, 30 insertions(+), 37 deletions(-)

[...]

 diff --git a/drivers/mfd/ti_am335x_tscadc.c b/drivers/mfd/ti_am335x_tscadc.c
 index d877e777cce6..94ef8992f46b 100644
 --- a/drivers/mfd/ti_am335x_tscadc.c
 +++ b/drivers/mfd/ti_am335x_tscadc.c
 @@ -86,8 +86,12 @@ static void am335x_tscadc_need_adc(struct ti_tscadc_dev 
 *tsadc)
   spin_lock_irq(tsadc-reg_lock);
   finish_wait(tsadc-reg_se_wait, wait);
  
 + /*
 +  * Sequencer should either be idle or
 +  * busy applying the charge step.
 +  */
   reg = tscadc_readl(tsadc, REG_ADCFSM);
 - WARN_ON(reg  SEQ_STATUS);
 + WARN_ON(reg  SEQ_STATUS  (!CHARGE_STEP));
   tsadc-adc_waiting = false;
   }
   tsadc-adc_in_use = true;
 @@ -96,7 +100,6 @@ static void am335x_tscadc_need_adc(struct ti_tscadc_dev 
 *tsadc)
  void am335x_tsc_se_set_once(struct ti_tscadc_dev *tsadc, u32 val)
  {
   spin_lock_irq(tsadc-reg_lock);
 - tsadc-reg_se_cache |= val;
   am335x_tscadc_need_adc(tsadc);
  
   tscadc_writel(tsadc, REG_SE, val);

I believe all of these changes can, and therefor should live in a
separate patch.

 diff --git a/include/linux/mfd/ti_am335x_tscadc.h 
 b/include/linux/mfd/ti_am335x_tscadc.h
 index e2e70053470e..fcce182e4a35 100644
 --- a/include/linux/mfd/ti_am335x_tscadc.h
 +++ b/include/linux/mfd/ti_am335x_tscadc.h
 @@ -52,6 +52,7 @@
  
  /* IRQ enable */
  #define IRQENB_HW_PENBIT(0)
 +#define IRQENB_EOS   BIT(1)
  #define IRQENB_FIFO0THRESBIT(2)
  #define IRQENB_FIFO0OVRRUN   BIT(3)
  #define IRQENB_FIFO0UNDRFLW  BIT(4)
 @@ -107,7 +108,7 @@
  /* Charge delay */
  #define CHARGEDLY_OPEN_MASK  (0x3  0)
  #define CHARGEDLY_OPEN(val)  ((val)  0)
 -#define CHARGEDLY_OPENDLYCHARGEDLY_OPEN(1)
 +#define CHARGEDLY_OPENDLYCHARGEDLY_OPEN(0xB000)
  
  /* Control register */
  #define CNTRLREG_TSCSSENBBIT(0)
 @@ -127,6 +128,7 @@
  
  /* Sequencer Status */
  #define SEQ_STATUS BIT(5)
 +#define CHARGE_STEP  0x11
  
  #define ADC_CLK  300
  #define TOTAL_STEPS  16

The header changes should be split between the two Input and MFD
patches.

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
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] pinctrl: dra: dt-bindings: Fix output pull up/down

[Roger Quadros]

On 11/03/2014 04:59 PM, Nishanth Menon wrote:
 On 11/03/2014 08:44 AM, Roger Quadros wrote:
 On 11/03/2014 04:30 PM, Nishanth Menon wrote:
 On 12:09-20141103, Roger Quadros wrote:
 For PIN_OUTPUT_PULLUP and PIN_OUTPUT_PULLDOWN we must not set the
 PULL_DIS bit which disables the PULLs.

 PULL_ENA is a 0 and using it in an OR operation is a NOP, so don't
 use it in the PIN_OUTPUT_PULLUP/DOWN macros.

 Fixes: 23d9cec07c58 (pinctrl: dra: dt-bindings: Fix pull enable/disable)

 Signed-off-by: Roger Quadros rog...@ti.com
 ---
  include/dt-bindings/pinctrl/dra.h | 4 ++--
  1 file changed, 2 insertions(+), 2 deletions(-)

 diff --git a/include/dt-bindings/pinctrl/dra.h 
 b/include/dt-bindings/pinctrl/dra.h
 index 3d33794..7448edf 100644
 --- a/include/dt-bindings/pinctrl/dra.h
 +++ b/include/dt-bindings/pinctrl/dra.h
 @@ -40,8 +40,8 @@
  
  /* Active pin states */
  #define PIN_OUTPUT(0 | PULL_DIS)
 -#define PIN_OUTPUT_PULLUP (PIN_OUTPUT | PULL_ENA | PULL_UP)
 -#define PIN_OUTPUT_PULLDOWN   (PIN_OUTPUT | PULL_ENA)
 +#define PIN_OUTPUT_PULLUP (PULL_UP)
 +#define PIN_OUTPUT_PULLDOWN   (0)
  #define PIN_INPUT (INPUT_EN | PULL_DIS)
  #define PIN_INPUT_SLEW(INPUT_EN | SLEWCONTROL)
  #define PIN_INPUT_PULLUP  (PULL_ENA | INPUT_EN | PULL_UP)

 You are right, we do have an issue with using PIN_OUTPUT along with
 remaining setting.

 For a moment, I wondered why input was not impacted - then I realized
 that INPUT_EN was being used instead of PIN_INPUT - following that
 convention. With the intent being explicitly using macros that
 clearly indicate what each setting combination is is, how about the
 following?


 diff --git a/include/dt-bindings/pinctrl/dra.h 
 b/include/dt-bindings/pinctrl/dra.h
 index 3d33794..d4037e7 100644
 --- a/include/dt-bindings/pinctrl/dra.h
 +++ b/include/dt-bindings/pinctrl/dra.h
 @@ -34,14 +34,15 @@
  #define PULL_DIS   (1  16)
  #define PULL_UP(1  17)
  #define INPUT_EN   (1  18)
 +#define OUTPUT_EN  (0  18)
  #define SLEWCONTROL(1  19)
  #define WAKEUP_EN  (1  24)
  #define WAKEUP_EVENT   (1  25)
  
  /* Active pin states */
 -#define PIN_OUTPUT (0 | PULL_DIS)
 -#define PIN_OUTPUT_PULLUP  (PIN_OUTPUT | PULL_ENA | PULL_UP)
 -#define PIN_OUTPUT_PULLDOWN(PIN_OUTPUT | PULL_ENA)
 +#define PIN_OUTPUT (OUTPUT_EN | PULL_DIS)
 +#define PIN_OUTPUT_PULLUP  (OUTPUT_EN | PULL_ENA | PULL_UP)
 +#define PIN_OUTPUT_PULLDOWN(OUTPUT_EN | PULL_ENA)

 To me it adds more confusion and this change is a NOP as we're ORing 0 here
 with OUTPUT_EN.
 
 look at this this way:
 
 PIN_OUTPUT_PULLDOWN   (OUTPUT_EN | PULL_ENA)
 
 should probably trigger in mind (what about PULLDOWN?)
 
 PIN_OUTPUT_PULLDOWN   (OUTPUT_EN | PULL_ENA | PULL_DOWN)
 
 then verify values of each OUTPUT_EN  - 0 in bit 18, ok, etc.
 
 
 if we ensure that PIN_XX macros use just the basic primitives, it is
 easier to prevent the mistake like the one I made. the other option of
 not defining macros whose values are 0 implies that the reviewer has
 to recheck against trm to ensure all the right 1 bits are set.
 
 
 just my view here.

Aren't the macros defining the bit positions not the actual enable or 
disable actions?

If we go by what you said then you will have to add
WAKEUP_DIS, SLEWCONTROL_DIS, WAKEUP_EVENT_DIS and so on.

Which again makes no sense as you will have to define them to zero.

cheers,
-roger

 

  #define PIN_INPUT  (INPUT_EN | PULL_DIS)
  #define PIN_INPUT_SLEW (INPUT_EN | SLEWCONTROL)
  #define PIN_INPUT_PULLUP   (PULL_ENA | INPUT_EN | PULL_UP)


 cheers,
 -roger

 
 

--
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] mfd: twl4030-power: Fix poweroff with PM configuration enabled

[Lee Jones]

On Sun, 02 Nov 2014, Tony Lindgren wrote:

 Commit e7cd1d1eb16f (mfd: twl4030-power: Add generic reset
 configuration) enabled configuring the PM features for twl4030.
 
 This caused poweroff command to fail on devices that have the
 BCI charger on twl4030 wired, or have power wired for VBUS.
 Instead of powering off, the device reboots. This is because
 voltage is detected on charger or VBUS with the default bits
 enabled for the power transition registers.
 
 To fix the issue, let's just clear VBUS and CHG bits as we want
 poweroff command to keep the system powered off.
 
 Fixes: e7cd1d1eb16f (mfd: twl4030-power: Add generic reset configuration)
 Cc: sta...@vger.kernel.org # v3.16+
 Reported-by: Russell King rmk+ker...@arm.linux.org.uk

It would be good to have Russell to review this to ensure he is happy
with the implementation.

 Signed-off-by: Tony Lindgren t...@atomide.com

[...]

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
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] mfd: twl4030-power: Fix regression with missing compatible flag

[Lee Jones]

On Sun, 02 Nov 2014, Tony Lindgren wrote:

 Commit e7cd1d1eb16f (mfd: twl4030-power: Add generic reset
 configuration) accidentally removed the compatible flag for
 ti,twl4030-power that should be there as documented in the
 binding.
 
 If ti,twl4030-power only the poweroff configuration is done
 by the driver.
 
 Fixes: e7cd1d1eb16f (mfd: twl4030-power: Add generic reset configuration)
 Cc: sta...@vger.kernel.org # v3.16+
 Reported-by: Dr. H. Nikolaus Schaller h...@goldelico.com
 Signed-off-by: Tony Lindgren t...@atomide.com

Applied, thanks.

 --- a/drivers/mfd/twl4030-power.c
 +++ b/drivers/mfd/twl4030-power.c
 @@ -831,6 +831,9 @@ static struct twl4030_power_data osc_off_idle = {
  
  static struct of_device_id twl4030_power_of_match[] = {
   {
 + .compatible = ti,twl4030-power,
 + },
 + {
   .compatible = ti,twl4030-power-reset,
   .data = omap3_reset,
   },

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
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 0/2] Add DRA7xx CPSW Ethernet support in Device Tree

[Felipe Balbi]

On Tue, Oct 21, 2014 at 12:22:23PM -0500, Nishanth Menon wrote:
 On 15:37-20141021, Mugunthan V N wrote:
  Nishanth
  
  On Tuesday 21 October 2014 03:30 PM, Mugunthan V N wrote:
   Adding device tree entry for CPSW to make it work in Dual EMAC mode.
   These patches were tested with DRA7 hwmod patches on top of linux-next.
   Patches are tested on top of Nishanth's PM tree for v3.17 [1] and pushed
   my tree to [2].
   
   Did a boot test with CPSW and ping test with suspend/resume, the boot logs
   on DRA7xx EVM are posted at [3]
   
   [1] git://github.com/nmenon/linux-2.6-playground.git 
   testing/v3.17/cpu-idle-suspend-dra7-omap5-framework
   [2] git://git.ti.com/~mugunthanvnm/ti-linux-kernel/linux.git 
   v3.17/dra7-evm-cpsw-v3
   [3] http://pastebin.ubuntu.com/8613072/
   
   Changes from v2:
   * Changed pinctrl comments to hold mode0-name.mode-selected-name
   * Changes slave numbers in the pinctrl comments
   * Added cpsw and cpts clocks
   
  
  I have not added support for dra72x-evm as it has only slave no 2 pinned
  out and having issues with bringing up the interface, need some more
  time to submit the patch, in the mean time I have submitted dra7-evm
  support only so that people can use dra7-evm on linux-next.
 
 Quickly tested as well:
 http://slexy.org/raw/s2vISJxYrR
 
 Please feel free to add:
 Tested-by: Nishanth Menon n...@ti.com
 Acked-by: Nishanth Menon n...@ti.com

I've used these patches with X15 (DRA7xx-based yet-to-be-released board)
with v3.18-rc2.

Tested-by: Felipe Balbi ba...@ti.com

-- 
balbi


signature.asc
Description: Digital signature

[PATCH] arm: boot: dts: dra7: add labels to DWC3 nodes

[Felipe Balbi]

by adding labels to DWC3 nodes, it's far easier
for boards to reference them.

Signed-off-by: Felipe Balbi ba...@ti.com
---

soon we will need to reference these nodes in order
to add extcon binding, so USB can be enabled out-of-the-box.

 arch/arm/boot/dts/dra7.dtsi | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/arch/arm/boot/dts/dra7.dtsi b/arch/arm/boot/dts/dra7.dtsi
index b9bf09f..7b54d2b 100644
--- a/arch/arm/boot/dts/dra7.dtsi
+++ b/arch/arm/boot/dts/dra7.dtsi
@@ -1143,7 +1143,7 @@
};
};
 
-   omap_dwc3_1@4888 {
+   omap_dwc3_1: omap_dwc3_1@4888 {
compatible = ti,dwc3;
ti,hwmods = usb_otg_ss1;
reg = 0x4888 0x1;
@@ -1164,7 +1164,7 @@
};
};
 
-   omap_dwc3_2@488c {
+   omap_dwc3_2: omap_dwc3_2@488c {
compatible = ti,dwc3;
ti,hwmods = usb_otg_ss2;
reg = 0x488c 0x1;
@@ -1186,7 +1186,7 @@
};
 
/* IRQ for DWC3_3 and DWC3_4 need IRQ crossbar */
-   omap_dwc3_3@4890 {
+   omap_dwc3_3: omap_dwc3_3@4890 {
compatible = ti,dwc3;
ti,hwmods = usb_otg_ss3;
reg = 0x4890 0x1;
@@ -1206,7 +1206,7 @@
};
};
 
-   omap_dwc3_4@4894 {
+   omap_dwc3_4: omap_dwc3_4@4894 {
compatible = ti,dwc3;
ti,hwmods = usb_otg_ss4;
reg = 0x4894 0x1;
-- 
2.1.0.GIT

--
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 0/4] extcon: gpio: add DT support

[Felipe Balbi]

Hi,

this series has been tested with v3.18-rc2 with a
yet-to-be-released board (called X15). That board
is DT-only and we use extcon-gpio to decide which
USB mode should be used (host or peripheral).

George Cherian (4):
  extcon: gpio: Convert the driver to use gpio desc API's
  extcon: gpio: Add dt support for the driver.
  extcon: gpio: Always use gpio_get_value_cansleep
  extcon: gpio: Add support for using cable names

 .../devicetree/bindings/extcon/extcon-gpio.txt | 23 ++
 drivers/extcon/extcon-gpio.c   | 93 ++
 2 files changed, 84 insertions(+), 32 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/extcon/extcon-gpio.txt

-- 
2.1.0.GIT

--
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 1/4] extcon: gpio: Convert the driver to use gpio desc API's

[Felipe Balbi]

From: George Cherian george.cher...@ti.com

Convert the driver to use gpiod_* API's.

Reviewed-by: Roger Quadros rog...@ti.com
Signed-off-by: George Cherian george.cher...@ti.com
Signed-off-by: Sekhar Nori nsek...@ti.com
Signed-off-by: Felipe Balbi ba...@ti.com
---
 drivers/extcon/extcon-gpio.c | 16 ++--
 1 file changed, 6 insertions(+), 10 deletions(-)

diff --git a/drivers/extcon/extcon-gpio.c b/drivers/extcon/extcon-gpio.c
index 72f19a3..70e3fc7 100644
--- a/drivers/extcon/extcon-gpio.c
+++ b/drivers/extcon/extcon-gpio.c
@@ -33,8 +33,7 @@
 
 struct gpio_extcon_data {
struct extcon_dev *edev;
-   unsigned gpio;
-   bool gpio_active_low;
+   struct gpio_desc *gpiod;
const char *state_on;
const char *state_off;
int irq;
@@ -50,9 +49,7 @@ static void gpio_extcon_work(struct work_struct *work)
container_of(to_delayed_work(work), struct gpio_extcon_data,
 work);
 
-   state = gpio_get_value(data-gpio);
-   if (data-gpio_active_low)
-   state = !state;
+   state = gpiod_get_value(data-gpiod);
extcon_set_state(data-edev, state);
 }
 
@@ -106,21 +103,20 @@ static int gpio_extcon_probe(struct platform_device *pdev)
}
extcon_data-edev-name = pdata-name;
 
-   extcon_data-gpio = pdata-gpio;
-   extcon_data-gpio_active_low = pdata-gpio_active_low;
+   extcon_data-gpiod = gpio_to_desc(pdata-gpio);
extcon_data-state_on = pdata-state_on;
extcon_data-state_off = pdata-state_off;
extcon_data-check_on_resume = pdata-check_on_resume;
if (pdata-state_on  pdata-state_off)
extcon_data-edev-print_state = extcon_gpio_print_state;
 
-   ret = devm_gpio_request_one(pdev-dev, extcon_data-gpio, GPIOF_DIR_IN,
+   ret = devm_gpio_request_one(pdev-dev, pdata-gpio, GPIOF_DIR_IN,
pdev-name);
if (ret  0)
return ret;
 
if (pdata-debounce) {
-   ret = gpio_set_debounce(extcon_data-gpio,
+   ret = gpiod_set_debounce(extcon_data-gpiod,
pdata-debounce * 1000);
if (ret  0)
extcon_data-debounce_jiffies =
@@ -133,7 +129,7 @@ static int gpio_extcon_probe(struct platform_device *pdev)
 
INIT_DELAYED_WORK(extcon_data-work, gpio_extcon_work);
 
-   extcon_data-irq = gpio_to_irq(extcon_data-gpio);
+   extcon_data-irq = gpiod_to_irq(extcon_data-gpiod);
if (extcon_data-irq  0)
return extcon_data-irq;
 
-- 
2.1.0.GIT

--
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 3/4] extcon: gpio: Always use gpio_get_value_cansleep

[Felipe Balbi]

From: George Cherian george.cher...@ti.com

Some gpio's can sleep while reading, so always use gpio_get_value_cansleep
to get data. This fixes warning from gpiolib due to wrong API usage.

Reviewed-by: Roger Quadros rog...@ti.com
Signed-off-by: George Cherian george.cher...@ti.com
Signed-off-by: Sekhar Nori nsek...@ti.com
Signed-off-by: Felipe Balbi ba...@ti.com
---
 drivers/extcon/extcon-gpio.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/extcon/extcon-gpio.c b/drivers/extcon/extcon-gpio.c
index 9571e1f..7191d28 100644
--- a/drivers/extcon/extcon-gpio.c
+++ b/drivers/extcon/extcon-gpio.c
@@ -51,7 +51,7 @@ static void gpio_extcon_work(struct work_struct *work)
container_of(to_delayed_work(work), struct gpio_extcon_data,
 work);
 
-   state = gpiod_get_value(data-gpiod);
+   state = gpiod_get_value_cansleep(data-gpiod);
extcon_set_state(data-edev, state);
 }
 
-- 
2.1.0.GIT

--
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 2/4] extcon: gpio: Add dt support for the driver.

[Felipe Balbi]

From: George Cherian george.cher...@ti.com

Add device tree support to extcon-gpio driver.
Add devicetree binding documentation

Cc: devicet...@vger.kernel.org
Signed-off-by: George Cherian george.cher...@ti.com
Signed-off-by: Sekhar Nori nsek...@ti.com
Signed-off-by: Felipe Balbi ba...@ti.com
---
 .../devicetree/bindings/extcon/extcon-gpio.txt | 21 ++
 drivers/extcon/extcon-gpio.c   | 75 +++---
 2 files changed, 73 insertions(+), 23 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/extcon/extcon-gpio.txt

diff --git a/Documentation/devicetree/bindings/extcon/extcon-gpio.txt 
b/Documentation/devicetree/bindings/extcon/extcon-gpio.txt
new file mode 100644
index 000..5fe6846
--- /dev/null
+++ b/Documentation/devicetree/bindings/extcon/extcon-gpio.txt
@@ -0,0 +1,21 @@
+GPIO based EXTCON
+
+EXTCON GPIO
+---
+
+Required Properties:
+ - compatible: should be:
+   * linux,extcon-gpio
+ - gpios: specifies the gpio pin used.
+
+Optional Properties:
+ - debounce: Debounce time for GPIO IRQ in ms
+
+
+Eg:
+
+   extcon1: am43_usbid_extcon1 {
+   compatible = linux,extcon-gpio;
+   gpios = gpio3 12 GPIO_ACTIVE_HIGH;
+   debounce = 20;
+   };
diff --git a/drivers/extcon/extcon-gpio.c b/drivers/extcon/extcon-gpio.c
index 70e3fc7..9571e1f 100644
--- a/drivers/extcon/extcon-gpio.c
+++ b/drivers/extcon/extcon-gpio.c
@@ -25,8 +25,10 @@
 #include linux/gpio.h
 #include linux/init.h
 #include linux/interrupt.h
+#include linux/irq.h
 #include linux/kernel.h
 #include linux/module.h
+#include linux/of_gpio.h
 #include linux/platform_device.h
 #include linux/slab.h
 #include linux/workqueue.h
@@ -80,16 +82,12 @@ static ssize_t extcon_gpio_print_state(struct extcon_dev 
*edev, char *buf)
 
 static int gpio_extcon_probe(struct platform_device *pdev)
 {
+   struct device_node *np = pdev-dev.of_node;
struct gpio_extcon_platform_data *pdata = dev_get_platdata(pdev-dev);
struct gpio_extcon_data *extcon_data;
int ret;
-
-   if (!pdata)
-   return -EBUSY;
-   if (!pdata-irq_flags) {
-   dev_err(pdev-dev, IRQ flag is not specified.\n);
-   return -EINVAL;
-   }
+   unsigned int irq_flags;
+   unsigned int debounce = 0;
 
extcon_data = devm_kzalloc(pdev-dev, sizeof(struct gpio_extcon_data),
   GFP_KERNEL);
@@ -101,26 +99,51 @@ static int gpio_extcon_probe(struct platform_device *pdev)
dev_err(pdev-dev, failed to allocate extcon device\n);
return -ENOMEM;
}
-   extcon_data-edev-name = pdata-name;
-
-   extcon_data-gpiod = gpio_to_desc(pdata-gpio);
-   extcon_data-state_on = pdata-state_on;
-   extcon_data-state_off = pdata-state_off;
-   extcon_data-check_on_resume = pdata-check_on_resume;
-   if (pdata-state_on  pdata-state_off)
-   extcon_data-edev-print_state = extcon_gpio_print_state;
 
-   ret = devm_gpio_request_one(pdev-dev, pdata-gpio, GPIOF_DIR_IN,
-   pdev-name);
-   if (ret  0)
-   return ret;
+   if (np) {
+   int irq;
+
+   extcon_data-gpiod = devm_gpiod_get(pdev-dev, NULL);
+   if (IS_ERR(extcon_data-gpiod))
+   return PTR_ERR(extcon_data-gpiod);
+
+   extcon_data-edev-name = np-name;
+   extcon_data-edev-dev.parent = pdev-dev;
+   of_property_read_u32(np, debounce, debounce);
+   irq = gpiod_to_irq(extcon_data-gpiod);
+   irq_flags = irq_get_trigger_type(irq);
+   } else {
+   if (!pdata)
+   return -EBUSY;
+
+   if (!pdata-irq_flags) {
+   dev_err(pdev-dev, IRQ flag is not specified.\n);
+   return -EINVAL;
+   }
+
+   extcon_data-edev-name = pdata-name;
+
+   extcon_data-gpiod = gpio_to_desc(pdata-gpio);
+   extcon_data-state_on = pdata-state_on;
+   extcon_data-state_off = pdata-state_off;
+   extcon_data-check_on_resume = pdata-check_on_resume;
+   if (pdata-state_on  pdata-state_off)
+   extcon_data-edev-print_state = 
extcon_gpio_print_state;
+
+   ret = devm_gpio_request_one(pdev-dev, pdata-gpio, 
GPIOF_DIR_IN,
+   pdev-name);
+   if (ret  0)
+   return ret;
+   irq_flags = pdata-irq_flags;
+   debounce = pdata-debounce;
+   }
 
-   if (pdata-debounce) {
+   if (debounce) {
ret = gpiod_set_debounce(extcon_data-gpiod,
-   pdata-debounce * 1000);
+debounce * 1000);
if (ret  0)
extcon_data-debounce_jiffies =
- 

[PATCH 4/4] extcon: gpio: Add support for using cable names

[Felipe Balbi]

From: George Cherian george.cher...@ti.com

Add support for using cable names. Enables other drivers to register interest
and get notified using extcon provided notifier call backs.

Signed-off-by: George Cherian george.cher...@ti.com
Signed-off-by: Sekhar Nori nsek...@ti.com
---
 Documentation/devicetree/bindings/extcon/extcon-gpio.txt | 2 ++
 drivers/extcon/extcon-gpio.c | 4 
 2 files changed, 6 insertions(+)

diff --git a/Documentation/devicetree/bindings/extcon/extcon-gpio.txt 
b/Documentation/devicetree/bindings/extcon/extcon-gpio.txt
index 5fe6846..f19aeb4 100644
--- a/Documentation/devicetree/bindings/extcon/extcon-gpio.txt
+++ b/Documentation/devicetree/bindings/extcon/extcon-gpio.txt
@@ -7,6 +7,7 @@ Required Properties:
  - compatible: should be:
* linux,extcon-gpio
  - gpios: specifies the gpio pin used.
+ - cable-name: Name of the cable used.
 
 Optional Properties:
  - debounce: Debounce time for GPIO IRQ in ms
@@ -18,4 +19,5 @@ Eg:
compatible = linux,extcon-gpio;
gpios = gpio3 12 GPIO_ACTIVE_HIGH;
debounce = 20;
+   cable-name = USB-HOST;
};
diff --git a/drivers/extcon/extcon-gpio.c b/drivers/extcon/extcon-gpio.c
index 7191d28..cbe35af 100644
--- a/drivers/extcon/extcon-gpio.c
+++ b/drivers/extcon/extcon-gpio.c
@@ -42,6 +42,7 @@ struct gpio_extcon_data {
struct delayed_work work;
unsigned long debounce_jiffies;
bool check_on_resume;
+   const char *cable_name[1];
 };
 
 static void gpio_extcon_work(struct work_struct *work)
@@ -112,6 +113,9 @@ static int gpio_extcon_probe(struct platform_device *pdev)
of_property_read_u32(np, debounce, debounce);
irq = gpiod_to_irq(extcon_data-gpiod);
irq_flags = irq_get_trigger_type(irq);
+   of_property_read_string_index(np, cable-name, 0,
+ extcon_data-cable_name);
+   extcon_data-edev-supported_cable = extcon_data-cable_name;
} else {
if (!pdata)
return -EBUSY;
-- 
2.1.0.GIT

--
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 4/4] extcon: gpio: Add support for using cable names

[Felipe Balbi]

On Mon, Nov 03, 2014 at 10:32:30AM -0600, Felipe Balbi wrote:
 From: George Cherian george.cher...@ti.com
 
 Add support for using cable names. Enables other drivers to register interest
 and get notified using extcon provided notifier call backs.
 
 Signed-off-by: George Cherian george.cher...@ti.com
 Signed-off-by: Sekhar Nori nsek...@ti.com

Signed-off-by: Felipe Balbi ba...@ti.com

 ---
  Documentation/devicetree/bindings/extcon/extcon-gpio.txt | 2 ++
  drivers/extcon/extcon-gpio.c | 4 
  2 files changed, 6 insertions(+)
 
 diff --git a/Documentation/devicetree/bindings/extcon/extcon-gpio.txt 
 b/Documentation/devicetree/bindings/extcon/extcon-gpio.txt
 index 5fe6846..f19aeb4 100644
 --- a/Documentation/devicetree/bindings/extcon/extcon-gpio.txt
 +++ b/Documentation/devicetree/bindings/extcon/extcon-gpio.txt
 @@ -7,6 +7,7 @@ Required Properties:
   - compatible: should be:
 * linux,extcon-gpio
   - gpios: specifies the gpio pin used.
 + - cable-name: Name of the cable used.
  
  Optional Properties:
   - debounce: Debounce time for GPIO IRQ in ms
 @@ -18,4 +19,5 @@ Eg:
   compatible = linux,extcon-gpio;
   gpios = gpio3 12 GPIO_ACTIVE_HIGH;
   debounce = 20;
 + cable-name = USB-HOST;
   };
 diff --git a/drivers/extcon/extcon-gpio.c b/drivers/extcon/extcon-gpio.c
 index 7191d28..cbe35af 100644
 --- a/drivers/extcon/extcon-gpio.c
 +++ b/drivers/extcon/extcon-gpio.c
 @@ -42,6 +42,7 @@ struct gpio_extcon_data {
   struct delayed_work work;
   unsigned long debounce_jiffies;
   bool check_on_resume;
 + const char *cable_name[1];
  };
  
  static void gpio_extcon_work(struct work_struct *work)
 @@ -112,6 +113,9 @@ static int gpio_extcon_probe(struct platform_device *pdev)
   of_property_read_u32(np, debounce, debounce);
   irq = gpiod_to_irq(extcon_data-gpiod);
   irq_flags = irq_get_trigger_type(irq);
 + of_property_read_string_index(np, cable-name, 0,
 +   extcon_data-cable_name);
 + extcon_data-edev-supported_cable = extcon_data-cable_name;
   } else {
   if (!pdata)
   return -EBUSY;
 -- 
 2.1.0.GIT
 
 --
 To unsubscribe from this list: send the line unsubscribe linux-kernel in
 the body of a message to majord...@vger.kernel.org
 More majordomo info at  http://vger.kernel.org/majordomo-info.html
 Please read the FAQ at  http://www.tux.org/lkml/

-- 
balbi


signature.asc
Description: Digital signature

[PATCH] ARM: dts: dra7-evm: Add extcon nodes for USB

[Felipe Balbi]

From: George Cherian george.cher...@ti.com

Add extcon nodes for USB, without which USB won't
work.

EXTCON is used to tell dwc3-omap.ko that a cable
has been connected. It also passes the state of ID
pin so that can be written to UTMI_STATUS register
on dwc3-omap's address space.

Signed-off-by: George Cherian george.cher...@ti.com
Signed-off-by: Sekhar Nori nsek...@ti.com
Signed-off-by: Felipe Balbi ba...@ti.com
---

**
**  **
**  UNTESTED**
**

This patch was taken from TI's v3.14 tree available at [1],
the patch was tested there. I didn't test on v3.18-rc3 because
my DRA7 board has broken down. Working to get a replacement.

Anyway, I'd suggest Tony to wait for a Tested-by tag.

Note that in order for this to work you need following extra
patches:

http://marc.info/?l=linux-omapm=141503217215492w=2
http://marc.info/?l=linux-omapm=141503238715590w=2
http://marc.info/?l=linux-omapm=141503246515631w=2
http://marc.info/?l=linux-omapm=141503241315599w=2
http://marc.info/?l=linux-omapm=141503282815782w=2

[1] http://git.ti.com/ti-linux-kernel/ti-linux-kernel/commits/ti-linux-3.14.y

 arch/arm/boot/dts/dra7-evm.dts | 33 +
 1 file changed, 33 insertions(+)

diff --git a/arch/arm/boot/dts/dra7-evm.dts b/arch/arm/boot/dts/dra7-evm.dts
index c6ce625..7710f29 100644
--- a/arch/arm/boot/dts/dra7-evm.dts
+++ b/arch/arm/boot/dts/dra7-evm.dts
@@ -26,6 +26,18 @@
regulator-max-microvolt = 330;
};
 
+   extcon1: dra7x_usbid_extcon1 {
+   compatible = linux,extcon-gpio;
+   gpios = pcf_gpio_21 1 GPIO_ACTIVE_LOW;
+   cable-name = USB-HOST;
+   };
+
+   extcon2: dra7x_usbid_extcon2 {
+   compatible = linux,extcon-gpio;
+   gpios = pcf_gpio_21 2 GPIO_ACTIVE_LOW;
+   cable-name = USB-HOST;
+   };
+
vtt_fixed: fixedregulator-vtt {
compatible = regulator-fixed;
regulator-name = vtt_fixed;
@@ -291,6 +303,19 @@
};
};
};
+
+   pcf_gpio_21: gpio@21 {
+   compatible = ti,pcf8575;
+   reg = 0x21;
+   lines-initial-states = 0x1408;
+   gpio-controller;
+   #gpio-cells = 2;
+   interrupt-parent = gpio6;
+   interrupts = 14 IRQ_TYPE_EDGE_FALLING;
+   interrupt-controller;
+   #interrupt-cells = 2;
+   };
+
 };
 
 i2c2 {
@@ -420,6 +445,14 @@
};
 };
 
+omap_dwc3_1 {
+   extcon = extcon1;
+};
+
+omap_dwc3_2 {
+   extcon = extcon2;
+};
+
 usb1 {
dr_mode = peripheral;
pinctrl-names = default;
-- 
2.1.0.GIT

--
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] pinctrl: dra: dt-bindings: Fix output pull up/down

[Nishanth Menon]

On Mon, Nov 3, 2014 at 9:07 AM, Roger Quadros rog...@ti.com wrote:
 On 11/03/2014 04:59 PM, Nishanth Menon wrote:
 On 11/03/2014 08:44 AM, Roger Quadros wrote:
 On 11/03/2014 04:30 PM, Nishanth Menon wrote:
 On 12:09-20141103, Roger Quadros wrote:
 For PIN_OUTPUT_PULLUP and PIN_OUTPUT_PULLDOWN we must not set the
 PULL_DIS bit which disables the PULLs.

 PULL_ENA is a 0 and using it in an OR operation is a NOP, so don't
 use it in the PIN_OUTPUT_PULLUP/DOWN macros.

 Fixes: 23d9cec07c58 (pinctrl: dra: dt-bindings: Fix pull enable/disable)

 Signed-off-by: Roger Quadros rog...@ti.com
 ---
  include/dt-bindings/pinctrl/dra.h | 4 ++--
  1 file changed, 2 insertions(+), 2 deletions(-)

 diff --git a/include/dt-bindings/pinctrl/dra.h 
 b/include/dt-bindings/pinctrl/dra.h
 index 3d33794..7448edf 100644
 --- a/include/dt-bindings/pinctrl/dra.h
 +++ b/include/dt-bindings/pinctrl/dra.h
 @@ -40,8 +40,8 @@

  /* Active pin states */
  #define PIN_OUTPUT(0 | PULL_DIS)
 -#define PIN_OUTPUT_PULLUP (PIN_OUTPUT | PULL_ENA | PULL_UP)
 -#define PIN_OUTPUT_PULLDOWN   (PIN_OUTPUT | PULL_ENA)
 +#define PIN_OUTPUT_PULLUP (PULL_UP)
 +#define PIN_OUTPUT_PULLDOWN   (0)
  #define PIN_INPUT (INPUT_EN | PULL_DIS)
  #define PIN_INPUT_SLEW(INPUT_EN | SLEWCONTROL)
  #define PIN_INPUT_PULLUP  (PULL_ENA | INPUT_EN | PULL_UP)

 You are right, we do have an issue with using PIN_OUTPUT along with
 remaining setting.

 For a moment, I wondered why input was not impacted - then I realized
 that INPUT_EN was being used instead of PIN_INPUT - following that
 convention. With the intent being explicitly using macros that
 clearly indicate what each setting combination is is, how about the
 following?


 diff --git a/include/dt-bindings/pinctrl/dra.h 
 b/include/dt-bindings/pinctrl/dra.h
 index 3d33794..d4037e7 100644
 --- a/include/dt-bindings/pinctrl/dra.h
 +++ b/include/dt-bindings/pinctrl/dra.h
 @@ -34,14 +34,15 @@
  #define PULL_DIS   (1  16)
  #define PULL_UP(1  17)
  #define INPUT_EN   (1  18)
 +#define OUTPUT_EN  (0  18)
  #define SLEWCONTROL(1  19)
  #define WAKEUP_EN  (1  24)
  #define WAKEUP_EVENT   (1  25)

  /* Active pin states */
 -#define PIN_OUTPUT (0 | PULL_DIS)
 -#define PIN_OUTPUT_PULLUP  (PIN_OUTPUT | PULL_ENA | PULL_UP)
 -#define PIN_OUTPUT_PULLDOWN(PIN_OUTPUT | PULL_ENA)
 +#define PIN_OUTPUT (OUTPUT_EN | PULL_DIS)
 +#define PIN_OUTPUT_PULLUP  (OUTPUT_EN | PULL_ENA | PULL_UP)
 +#define PIN_OUTPUT_PULLDOWN(OUTPUT_EN | PULL_ENA)

 To me it adds more confusion and this change is a NOP as we're ORing 0 here
 with OUTPUT_EN.

 look at this this way:

 PIN_OUTPUT_PULLDOWN   (OUTPUT_EN | PULL_ENA)

 should probably trigger in mind (what about PULLDOWN?)

 PIN_OUTPUT_PULLDOWN   (OUTPUT_EN | PULL_ENA | PULL_DOWN)

 then verify values of each OUTPUT_EN  - 0 in bit 18, ok, etc.


 if we ensure that PIN_XX macros use just the basic primitives, it is
 easier to prevent the mistake like the one I made. the other option of
 not defining macros whose values are 0 implies that the reviewer has
 to recheck against trm to ensure all the right 1 bits are set.


 just my view here.

 Aren't the macros defining the bit positions not the actual enable or
 disable actions?

 If we go by what you said then you will have to add
 WAKEUP_DIS, SLEWCONTROL_DIS, WAKEUP_EVENT_DIS and so on.

 Which again makes no sense as you will have to define them to zero.

WAKEUP should not be defined anyways - pinctrl controls them - should
probably remove them from header.

but your point is probably a valid view w.r.t TI SoC bit definitions -
we just define the 1 states in omap.h as well.
-- 
---
Regards,
Nishanth Menon
--
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 16/47] mfd: tps6586x: Register with kernel power-off handler

[Felipe Balbi]

On Mon, Oct 27, 2014 at 08:55:23AM -0700, Guenter Roeck wrote:
 Register with kernel power-off handler instead of setting pm_power_off
 directly. Register with low priority to reflect that the original code
 only sets pm_power_off if it was not already set.
 
 Cc: Samuel Ortiz sa...@linux.intel.com
 Cc: Lee Jones lee.jo...@linaro.org
 Signed-off-by: Guenter Roeck li...@roeck-us.net

should be sent to linux-omap and lakml too

 ---
 v3:
 - Replace poweroff in all newly introduced variables and in text
   with power_off or power-off as appropriate
 - Replace POWEROFF_PRIORITY_xxx with POWER_OFF_PRIORITY_xxx
 v2:
 - Use define to specify poweroff handler priority
 - Use dev_warn instead of dev_err
 
  drivers/mfd/tps6586x.c | 31 +++
  1 file changed, 23 insertions(+), 8 deletions(-)
 
 diff --git a/drivers/mfd/tps6586x.c b/drivers/mfd/tps6586x.c
 index 8e1dbc4..1e97478 100644
 --- a/drivers/mfd/tps6586x.c
 +++ b/drivers/mfd/tps6586x.c
 @@ -21,10 +21,12 @@
  #include linux/kernel.h
  #include linux/module.h
  #include linux/mutex.h
 +#include linux/notifier.h
  #include linux/slab.h
  #include linux/err.h
  #include linux/i2c.h
  #include linux/platform_device.h
 +#include linux/pm.h
  #include linux/regmap.h
  #include linux/of.h
  
 @@ -133,6 +135,8 @@ struct tps6586x {
   u32 irq_en;
   u8  mask_reg[5];
   struct irq_domain   *irq_domain;
 +
 + struct notifier_block   power_off_nb;
  };
  
  static inline struct tps6586x *dev_to_tps6586x(struct device *dev)
 @@ -472,13 +476,18 @@ static const struct regmap_config 
 tps6586x_regmap_config = {
   .cache_type = REGCACHE_RBTREE,
  };
  
 -static struct device *tps6586x_dev;
 -static void tps6586x_power_off(void)
 +static int tps6586x_power_off(struct notifier_block *this,
 +   unsigned long unused1, void *unused2)
  {
 - if (tps6586x_clr_bits(tps6586x_dev, TPS6586X_SUPPLYENE, EXITSLREQ_BIT))
 - return;
 + struct tps6586x *tps6586x = container_of(this, struct tps6586x,
 +  power_off_nb);
 +
 + if (tps6586x_clr_bits(tps6586x-dev, TPS6586X_SUPPLYENE, EXITSLREQ_BIT))
 + return NOTIFY_DONE;
  
 - tps6586x_set_bits(tps6586x_dev, TPS6586X_SUPPLYENE, SLEEP_MODE_BIT);
 + tps6586x_set_bits(tps6586x-dev, TPS6586X_SUPPLYENE, SLEEP_MODE_BIT);
 +
 + return NOTIFY_DONE;
  }
  
  static void tps6586x_print_version(struct i2c_client *client, int version)
 @@ -575,9 +584,13 @@ static int tps6586x_i2c_probe(struct i2c_client *client,
   goto err_add_devs;
   }
  
 - if (pdata-pm_off  !pm_power_off) {
 - tps6586x_dev = client-dev;
 - pm_power_off = tps6586x_power_off;
 + if (pdata-pm_off) {
 + tps6586x-power_off_nb.notifier_call = tps6586x_power_off;
 + tps6586x-power_off_nb.priority = POWER_OFF_PRIORITY_LOW;
 + ret = register_power_off_handler(tps6586x-power_off_nb);
 + if (ret)
 + dev_warn(client-dev,
 +  failed to register power-off handler\n);
   }
  
   return 0;
 @@ -594,6 +607,8 @@ static int tps6586x_i2c_remove(struct i2c_client *client)
  {
   struct tps6586x *tps6586x = i2c_get_clientdata(client);
  
 + unregister_power_off_handler(tps6586x-power_off_nb);
 +
   tps6586x_remove_subdevs(tps6586x);
   mfd_remove_devices(tps6586x-dev);
   if (client-irq)
 -- 
 1.9.1
 
 --
 To unsubscribe from this list: send the line unsubscribe linux-kernel in
 the body of a message to majord...@vger.kernel.org
 More majordomo info at  http://vger.kernel.org/majordomo-info.html
 Please read the FAQ at  http://www.tux.org/lkml/

-- 
balbi


signature.asc
Description: Digital signature

Re: [PATCH v3 17/47] mfd: tps65910: Register with kernel power-off handler

[Felipe Balbi]

On Mon, Oct 27, 2014 at 08:55:24AM -0700, Guenter Roeck wrote:
 Register with kernel power-off handler instead of setting pm_power_off
 directly. Register with low priority to reflect that the original code
 only sets pm_power_off if it was not already set.
 
 Cc: Samuel Ortiz sa...@linux.intel.com
 Cc: Lee Jones lee.jo...@linaro.org
 Signed-off-by: Guenter Roeck li...@roeck-us.net

missed lakml and linux-omap here too

 ---
 v3:
 - Replace poweroff in all newly introduced variables and in text
   with power_off or power-off as appropriate
 - Replace POWEROFF_PRIORITY_xxx with POWER_OFF_PRIORITY_xxx
 v2:
 - Use define to specify poweroff handler priority
 - Use dev_warn instead of dev_err
 
  drivers/mfd/tps65910.c   | 27 ++-
  include/linux/mfd/tps65910.h |  3 +++
  2 files changed, 21 insertions(+), 9 deletions(-)
 
 diff --git a/drivers/mfd/tps65910.c b/drivers/mfd/tps65910.c
 index 7612d89..3c94dbf 100644
 --- a/drivers/mfd/tps65910.c
 +++ b/drivers/mfd/tps65910.c
 @@ -23,6 +23,8 @@
  #include linux/irq.h
  #include linux/irqdomain.h
  #include linux/mfd/core.h
 +#include linux/notifier.h
 +#include linux/pm.h
  #include linux/regmap.h
  #include linux/mfd/tps65910.h
  #include linux/of.h
 @@ -437,19 +439,20 @@ struct tps65910_board *tps65910_parse_dt(struct 
 i2c_client *client,
  }
  #endif
  
 -static struct i2c_client *tps65910_i2c_client;
 -static void tps65910_power_off(void)
 +static int tps65910_power_off(struct notifier_block *this,
 +   unsigned long unused1, void *unused2)
  {
 - struct tps65910 *tps65910;
 -
 - tps65910 = dev_get_drvdata(tps65910_i2c_client-dev);
 + struct tps65910 *tps65910 = container_of(this, struct tps65910,
 +  power_off_nb);
  
   if (tps65910_reg_set_bits(tps65910, TPS65910_DEVCTRL,
   DEVCTRL_PWR_OFF_MASK)  0)
 - return;
 + return NOTIFY_DONE;
  
   tps65910_reg_clear_bits(tps65910, TPS65910_DEVCTRL,
   DEVCTRL_DEV_ON_MASK);
 +
 + return NOTIFY_DONE;
  }
  
  static int tps65910_i2c_probe(struct i2c_client *i2c,
 @@ -505,9 +508,13 @@ static int tps65910_i2c_probe(struct i2c_client *i2c,
   tps65910_ck32k_init(tps65910, pmic_plat_data);
   tps65910_sleepinit(tps65910, pmic_plat_data);
  
 - if (pmic_plat_data-pm_off  !pm_power_off) {
 - tps65910_i2c_client = i2c;
 - pm_power_off = tps65910_power_off;
 + if (pmic_plat_data-pm_off) {
 + tps65910-power_off_nb.notifier_call = tps65910_power_off;
 + tps65910-power_off_nb.priority = POWER_OFF_PRIORITY_LOW;
 + ret = register_power_off_handler(tps65910-power_off_nb);
 + if (ret)
 + dev_warn(i2c-dev,
 +  failed to register power-off handler\n);
   }
  
   ret = mfd_add_devices(tps65910-dev, -1,
 @@ -527,6 +534,8 @@ static int tps65910_i2c_remove(struct i2c_client *i2c)
  {
   struct tps65910 *tps65910 = i2c_get_clientdata(i2c);
  
 + unregister_power_off_handler(tps65910-power_off_nb);
 +
   tps65910_irq_exit(tps65910);
   mfd_remove_devices(tps65910-dev);
  
 diff --git a/include/linux/mfd/tps65910.h b/include/linux/mfd/tps65910.h
 index 6483a6f..94876c4 100644
 --- a/include/linux/mfd/tps65910.h
 +++ b/include/linux/mfd/tps65910.h
 @@ -905,6 +905,9 @@ struct tps65910 {
   /* IRQ Handling */
   int chip_irq;
   struct regmap_irq_chip_data *irq_data;
 +
 + /* Power-off handling */
 + struct notifier_block power_off_nb;
  };
  
  struct tps65910_platform_data {
 -- 
 1.9.1
 
 --
 To unsubscribe from this list: send the line unsubscribe linux-kernel in
 the body of a message to majord...@vger.kernel.org
 More majordomo info at  http://vger.kernel.org/majordomo-info.html
 Please read the FAQ at  http://www.tux.org/lkml/

-- 
balbi


signature.asc
Description: Digital signature

Re: [PATCH v3 09/47] mfd: palmas: Register with kernel power-off handler

[Felipe Balbi]

On Mon, Nov 03, 2014 at 05:56:45PM +, Lee Jones wrote:
 On Mon, 27 Oct 2014, Guenter Roeck wrote:
 
  Register with kernel power-off handler instead of setting pm_power_off
  directly. Register with low priority to reflect that the original code
  only sets pm_power_off if it was not already set.
  
  Cc: Samuel Ortiz sa...@linux.intel.com
  Cc: Lee Jones lee.jo...@linaro.org
  Signed-off-by: Guenter Roeck li...@roeck-us.net
  ---
  v3:
  - Replace poweroff in all newly introduced variables and in text
with power_off or power-off as appropriate
  - Replace POWEROFF_PRIORITY_xxx with POWER_OFF_PRIORITY_xxx
  v2:
  - Use define to specify poweroff handler priority
  - Use devm_register_power_off_handler
  - Use dev_warn instead of dev_err
  
   drivers/mfd/palmas.c   | 31 +--
   include/linux/mfd/palmas.h |  3 +++
   2 files changed, 20 insertions(+), 14 deletions(-)
 
 Acked-by: Lee Jones lee.jo...@linaro.org

missed lakml and linux-omap.

 
  diff --git a/drivers/mfd/palmas.c b/drivers/mfd/palmas.c
  index 28cb048..99c488e 100644
  --- a/drivers/mfd/palmas.c
  +++ b/drivers/mfd/palmas.c
  @@ -19,6 +19,7 @@
   #include linux/i2c.h
   #include linux/interrupt.h
   #include linux/irq.h
  +#include linux/pm.h
   #include linux/regmap.h
   #include linux/err.h
   #include linux/mfd/core.h
  @@ -425,20 +426,18 @@ static void palmas_dt_to_pdata(struct i2c_client *i2c,
  ti,system-power-controller);
   }
   
  -static struct palmas *palmas_dev;
  -static void palmas_power_off(void)
  +static int palmas_power_off(struct notifier_block *this, unsigned long 
  unused1,
  +   void *unused2)
   {
  +   struct palmas *palmas = container_of(this, struct palmas, power_off_nb);
  unsigned int addr;
  int ret, slave;
   
  -   if (!palmas_dev)
  -   return;
  -
  slave = PALMAS_BASE_TO_SLAVE(PALMAS_PMU_CONTROL_BASE);
  addr = PALMAS_BASE_TO_REG(PALMAS_PMU_CONTROL_BASE, PALMAS_DEV_CTRL);
   
  ret = regmap_update_bits(
  -   palmas_dev-regmap[slave],
  +   palmas-regmap[slave],
  addr,
  PALMAS_DEV_CTRL_DEV_ON,
  0);
  @@ -446,6 +445,8 @@ static void palmas_power_off(void)
  if (ret)
  pr_err(%s: Unable to write to DEV_CTRL_DEV_ON: %d\n,
  __func__, ret);
  +
  +   return NOTIFY_DONE;
   }
   
   static unsigned int palmas_features = PALMAS_PMIC_FEATURE_SMPS10_BOOST;
  @@ -668,9 +669,16 @@ no_irq:
  ret = of_platform_populate(node, NULL, NULL, i2c-dev);
  if (ret  0) {
  goto err_irq;
  -   } else if (pdata-pm_off  !pm_power_off) {
  -   palmas_dev = palmas;
  -   pm_power_off = palmas_power_off;
  +   } else if (pdata-pm_off) {
  +   int ret2;
  +
  +   palmas-power_off_nb.notifier_call = palmas_power_off;
  +   palmas-power_off_nb.priority = POWER_OFF_PRIORITY_LOW;
  +   ret2 = devm_register_power_off_handler(palmas-dev,
  +   palmas-power_off_nb);
  +   if (ret2)
  +   dev_warn(palmas-dev,
  +Failed to register power-off 
  handler);
  }
  }
   
  @@ -698,11 +706,6 @@ static int palmas_i2c_remove(struct i2c_client *i2c)
  i2c_unregister_device(palmas-i2c_clients[i]);
  }
   
  -   if (palmas == palmas_dev) {
  -   pm_power_off = NULL;
  -   palmas_dev = NULL;
  -   }
  -
  return 0;
   }
   
  diff --git a/include/linux/mfd/palmas.h b/include/linux/mfd/palmas.h
  index fb0390a..7dbfe24 100644
  --- a/include/linux/mfd/palmas.h
  +++ b/include/linux/mfd/palmas.h
  @@ -18,6 +18,7 @@
   
   #include linux/usb/otg.h
   #include linux/leds.h
  +#include linux/notifier.h
   #include linux/regmap.h
   #include linux/regulator/driver.h
   #include linux/extcon.h
  @@ -68,6 +69,8 @@ struct palmas {
  struct i2c_client *i2c_clients[PALMAS_NUM_CLIENTS];
  struct regmap *regmap[PALMAS_NUM_CLIENTS];
   
  +   struct notifier_block power_off_nb;
  +
  /* Stored chip id */
  int id;
   
 
 -- 
 Lee Jones
 Linaro STMicroelectronics Landing Team Lead
 Linaro.org │ Open source software for ARM SoCs
 Follow Linaro: Facebook | Twitter | Blog
 --
 To unsubscribe from this list: send the line unsubscribe linux-kernel in
 the body of a message to majord...@vger.kernel.org
 More majordomo info at  http://vger.kernel.org/majordomo-info.html
 Please read the FAQ at  http://www.tux.org/lkml/

-- 
balbi


signature.asc
Description: Digital signature

Re: [PATCH v3 00/47] kernel: Add support for power-off handler call chain

[Felipe Balbi]

Hi,

On Mon, Oct 27, 2014 at 08:55:07AM -0700, Guenter Roeck wrote:
 Various drivers implement architecture and/or device specific means to
 remove power from the system.  For the most part, those drivers set the
 global variable pm_power_off to point to a function within the driver.
 
 This mechanism has a number of drawbacks.  Typically only one means
 to remove power is supported (at least if pm_power_off is used).
 At least in theory there can be multiple means to remove power, some of
 which may be less desirable.  For example, one mechanism might power off the
 entire system through an I/O port or gpio pin, while another might power off
 a board by disabling its power controller. Other mechanisms may really just
 execute a restart sequence or drop into the ROM monitor, or put the CPU into
 sleep mode.  Using pm_power_off can also be racy if the function pointer is
 set from a driver built as module, as the driver may be in the process of
 being unloaded when pm_power_off is called.  If there are multiple power-off
 handlers in the system, removing a module with such a handler may
 inadvertently reset the pointer to pm_power_off to NULL, leaving the system
 with no means to remove power.
 
 Introduce a system power-off handler call chain to solve the described
 problems.  This call chain is expected to be executed from the architecture
 specific machine_power_off() function.  Drivers providing system power-off
 functionality are expected to register with this call chain.  By using the
 priority field in the notifier block, callers can control power-off handler
 execution sequence and thus ensure that the power-off handler with the
 optimal capabilities to remove power for a given system is called first.
 A call chain instead of a single call to the highest priority handler is
 used to provide fallback: If multiple power-off handlers are installed,
 all handlers will be called until one actually succeeds to power off the
 system.
 
 Patch 01/47 implements the power-off handler API.
 
 Patches 02/47 to 04/47 are cleanup patches to prepare for the move of
 pm_power_off to a common location.
 
 Patches 05/47 to 07/47 remove references to pm_power_off from devicetree
 bindings descriptions.
 
 Patch 08/47 moves the pm_power_off variable from architecture code to
 kernel/reboot.c. 
 
 Patches 09/47 to 34/47 convert various drivers to register with the kernel
 power-off handler instead of setting pm_power_off directly.
 
 Patches 35/47 to 46/47 do the same for architecture code.
 
 Patch 47/47 finally removes pm_power_off.
 
 For the most part, the individual patches include explanations why specific
 priorities were chosen, at least if the selected priority is not the default
 priority. Subsystem and architecture maintainers are encouraged to have a look
 at the selected priorities and suggest improvements.
 
 I ran the final code through my normal build and qemu tests. Results are
 available at http://server.roeck-us.net:8010/builders in the 
 'poweroff-handler'
 column. I also built all available configurations for arm, mips, powerpc,
 m68k, and sh architectures.
 
 The series is available in branch poweroff-handler of my repository at
 git://git.kernel.org/pub/scm/linux/kernel/git/groeck/linux-staging.git.
 It is based on 3.18-rc2.
 
 A note on Cc: In the initial submission I had way too many Cc:, causing the
 patchset to be treated as spam by many mailers and mailing list handlers,
 which of course defeated the purpose. This time around I am cutting down
 the distribution list down significantly. My apologies to anyone I may have
 failed to copy this time around.

you touch every single architecture with this patchset, but you didn't
care about Ccing any of the arch-specific mailing lists, like lakml ?

Please resend with proper people in Cc, IIRC RMK had a few very
important comments about the idea behind this series.

 Important changes since v2:
 - Rebased series to v3.18-rc2.
 - Do not hold any locks while executing the power-off call chain.
   This ensures that power-off handlers are executed in the state
   selected by the machine_power_off function for a given architecture,
   ie without changing the current semantics of power-off callbacks and
   machine_power_off functions.
   Power-off handler registration and de-registration is handled in atomic
   context with interrupts disabled to ensure that those functions are not
   interrupted by code which powers off the system.
 - Use [xxx_]power_off[_xxx] instead of [xxx_]poweroff[_xxx] for newly
   introduced function and variable names.
 - Use power-off instead of poweroff in descriptive text and comments.
 - Replace POWEROFF_PRIORITY_xxx with POWER_OFF_PRIORITY_xxx
 - Use ACPI: instead of acpi: for messages in acpi code.
 
 Important changes since v1:
 - Rebased series to v3.18-rc1.
 - Use raw notifier with spinlock protection instead of atomic notifiers,
   since some power-off handlers need to have interrupts enabled.
 - Renamed API functions 

Re: [PATCH 1/4] extcon: gpio: Convert the driver to use gpio desc API's

[Guenter Roeck]

On Mon, Nov 03, 2014 at 10:32:27AM -0600, Felipe Balbi wrote:
 From: George Cherian george.cher...@ti.com
 
 Convert the driver to use gpiod_* API's.
 
 Reviewed-by: Roger Quadros rog...@ti.com
 Signed-off-by: George Cherian george.cher...@ti.com
 Signed-off-by: Sekhar Nori nsek...@ti.com
 Signed-off-by: Felipe Balbi ba...@ti.com
 ---

I think it might be useful and appropriate to explain that and why
you remove support for active-low pins, instead of hiding it in a
seemingly unrelated patch.

Also, since you don't use the platform data flag anymore, you might
as well remove it to give out-of-tree users a fair warning. Overall,
it might be easier to just revert the patch introducing it (5bfbdc9caa7)
before converting extcon to gpiod.

I am just glad that we stopped using extcon for other reasons ;-)

Guenter
--
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/4] extcon: gpio: Convert the driver to use gpio desc API's

[Felipe Balbi]

On Mon, Nov 03, 2014 at 10:01:50AM -0800, Guenter Roeck wrote:
 On Mon, Nov 03, 2014 at 10:32:27AM -0600, Felipe Balbi wrote:
  From: George Cherian george.cher...@ti.com
  
  Convert the driver to use gpiod_* API's.
  
  Reviewed-by: Roger Quadros rog...@ti.com
  Signed-off-by: George Cherian george.cher...@ti.com
  Signed-off-by: Sekhar Nori nsek...@ti.com
  Signed-off-by: Felipe Balbi ba...@ti.com
  ---
 
 I think it might be useful and appropriate to explain that and why
 you remove support for active-low pins, instead of hiding it in a
 seemingly unrelated patch.

removed ? why removed ? gpio descs handle that for you, read the source
code.

-- 
balbi


signature.asc
Description: Digital signature

Re: [PATCH 0/4] Touchscreen performance related fixes

[Richard Cochran]

On Mon, Oct 27, 2014 at 04:38:27PM +0530, Vignesh R wrote:
 This series of patches fix TSC defects related to lag in touchscreen
 performance and cursor jump at touch release. The lag was result of
 udelay in TSC interrupt handler. Cursor jump due to false pen-up event.
 The patches implement Advisory 1.0.31 in silicon errata of am335x-evm
 to avoid false pen-up events and remove udelay.

That advisory has two workarounds. You have chosen the second one?

The text of the second workaround says it only works on 4 wire setups,
so I wonder how 5 wire designs will be affected.

 The advisory says to use
 steps 1 to 4 for ADC and 5 to 16 for TSC (assuming 4 wire TSC and 4 channel
 ADC).

No, it doesn't say that. (sprz360f.pdf)

 Further the X co-ordinate must be the last one to be sampled just
 before charge step. The first two patches implement the required changes. 

FWIW, I implemented the first workaround and removed the udelay not
too long ago. Like Sebastian, I saw the TSC unit hang after about
5 interrupts when running with the workaround.

Did you test you patch for very long?

Thanks,
Richard
--
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 00/47] kernel: Add support for power-off handler call chain

[Guenter Roeck]

On Mon, Nov 03, 2014 at 11:59:35AM -0600, Felipe Balbi wrote:
 Hi,
 
 On Mon, Oct 27, 2014 at 08:55:07AM -0700, Guenter Roeck wrote:
  Various drivers implement architecture and/or device specific means to
  remove power from the system.  For the most part, those drivers set the
  global variable pm_power_off to point to a function within the driver.
  
  This mechanism has a number of drawbacks.  Typically only one means
  to remove power is supported (at least if pm_power_off is used).
  At least in theory there can be multiple means to remove power, some of
  which may be less desirable.  For example, one mechanism might power off the
  entire system through an I/O port or gpio pin, while another might power off
  a board by disabling its power controller. Other mechanisms may really just
  execute a restart sequence or drop into the ROM monitor, or put the CPU into
  sleep mode.  Using pm_power_off can also be racy if the function pointer is
  set from a driver built as module, as the driver may be in the process of
  being unloaded when pm_power_off is called.  If there are multiple power-off
  handlers in the system, removing a module with such a handler may
  inadvertently reset the pointer to pm_power_off to NULL, leaving the system
  with no means to remove power.
  
  Introduce a system power-off handler call chain to solve the described
  problems.  This call chain is expected to be executed from the architecture
  specific machine_power_off() function.  Drivers providing system power-off
  functionality are expected to register with this call chain.  By using the
  priority field in the notifier block, callers can control power-off handler
  execution sequence and thus ensure that the power-off handler with the
  optimal capabilities to remove power for a given system is called first.
  A call chain instead of a single call to the highest priority handler is
  used to provide fallback: If multiple power-off handlers are installed,
  all handlers will be called until one actually succeeds to power off the
  system.
  
  Patch 01/47 implements the power-off handler API.
  
  Patches 02/47 to 04/47 are cleanup patches to prepare for the move of
  pm_power_off to a common location.
  
  Patches 05/47 to 07/47 remove references to pm_power_off from devicetree
  bindings descriptions.
  
  Patch 08/47 moves the pm_power_off variable from architecture code to
  kernel/reboot.c. 
  
  Patches 09/47 to 34/47 convert various drivers to register with the kernel
  power-off handler instead of setting pm_power_off directly.
  
  Patches 35/47 to 46/47 do the same for architecture code.
  
  Patch 47/47 finally removes pm_power_off.
  
  For the most part, the individual patches include explanations why specific
  priorities were chosen, at least if the selected priority is not the default
  priority. Subsystem and architecture maintainers are encouraged to have a 
  look
  at the selected priorities and suggest improvements.
  
  I ran the final code through my normal build and qemu tests. Results are
  available at http://server.roeck-us.net:8010/builders in the 
  'poweroff-handler'
  column. I also built all available configurations for arm, mips, powerpc,
  m68k, and sh architectures.
  
  The series is available in branch poweroff-handler of my repository at
  git://git.kernel.org/pub/scm/linux/kernel/git/groeck/linux-staging.git.
  It is based on 3.18-rc2.
  
  A note on Cc: In the initial submission I had way too many Cc:, causing the
  patchset to be treated as spam by many mailers and mailing list handlers,
  which of course defeated the purpose. This time around I am cutting down
  the distribution list down significantly. My apologies to anyone I may have
  failed to copy this time around.
 
 you touch every single architecture with this patchset, but you didn't
 care about Ccing any of the arch-specific mailing lists, like lakml ?
 
What is lakml ? linux-ker...@vger.kernel.org was copied, if that is what you
refer to. I don't find a reference to lakml anywhere, sorry. I'll be happy to
add it manually if you provide the address.

Architecture specific mailing lists were copied on individual patches as long
as those mailing lists are reported by the MAINTAINERS file.

 Please resend with proper people in Cc, IIRC RMK had a few very
 important comments about the idea behind this series.
 
Felipe,

That doesn't work. I tried with rev 1. The result was that the patch series
was flagged as spam and got dropped by most mailing lists, as explained above,
and I got tagged as spammer by Google and several other mail servers,
preventing me from posting _anything_ for several days.

Please point me to the comments you refer to above in case I missed them.

Thanks,
Guenter
--
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 00/47] kernel: Add support for power-off handler call chain

[Felipe Balbi]

Hi,

On Mon, Nov 03, 2014 at 10:22:13AM -0800, Guenter Roeck wrote:
 On Mon, Nov 03, 2014 at 11:59:35AM -0600, Felipe Balbi wrote:
  Hi,
  
  On Mon, Oct 27, 2014 at 08:55:07AM -0700, Guenter Roeck wrote:
   Various drivers implement architecture and/or device specific means to
   remove power from the system.  For the most part, those drivers set the
   global variable pm_power_off to point to a function within the driver.
   
   This mechanism has a number of drawbacks.  Typically only one means
   to remove power is supported (at least if pm_power_off is used).
   At least in theory there can be multiple means to remove power, some of
   which may be less desirable.  For example, one mechanism might power off 
   the
   entire system through an I/O port or gpio pin, while another might power 
   off
   a board by disabling its power controller. Other mechanisms may really 
   just
   execute a restart sequence or drop into the ROM monitor, or put the CPU 
   into
   sleep mode.  Using pm_power_off can also be racy if the function pointer 
   is
   set from a driver built as module, as the driver may be in the process of
   being unloaded when pm_power_off is called.  If there are multiple 
   power-off
   handlers in the system, removing a module with such a handler may
   inadvertently reset the pointer to pm_power_off to NULL, leaving the 
   system
   with no means to remove power.
   
   Introduce a system power-off handler call chain to solve the described
   problems.  This call chain is expected to be executed from the 
   architecture
   specific machine_power_off() function.  Drivers providing system power-off
   functionality are expected to register with this call chain.  By using the
   priority field in the notifier block, callers can control power-off 
   handler
   execution sequence and thus ensure that the power-off handler with the
   optimal capabilities to remove power for a given system is called first.
   A call chain instead of a single call to the highest priority handler is
   used to provide fallback: If multiple power-off handlers are installed,
   all handlers will be called until one actually succeeds to power off the
   system.
   
   Patch 01/47 implements the power-off handler API.
   
   Patches 02/47 to 04/47 are cleanup patches to prepare for the move of
   pm_power_off to a common location.
   
   Patches 05/47 to 07/47 remove references to pm_power_off from devicetree
   bindings descriptions.
   
   Patch 08/47 moves the pm_power_off variable from architecture code to
   kernel/reboot.c. 
   
   Patches 09/47 to 34/47 convert various drivers to register with the kernel
   power-off handler instead of setting pm_power_off directly.
   
   Patches 35/47 to 46/47 do the same for architecture code.
   
   Patch 47/47 finally removes pm_power_off.
   
   For the most part, the individual patches include explanations why 
   specific
   priorities were chosen, at least if the selected priority is not the 
   default
   priority. Subsystem and architecture maintainers are encouraged to have a 
   look
   at the selected priorities and suggest improvements.
   
   I ran the final code through my normal build and qemu tests. Results are
   available at http://server.roeck-us.net:8010/builders in the 
   'poweroff-handler'
   column. I also built all available configurations for arm, mips, powerpc,
   m68k, and sh architectures.
   
   The series is available in branch poweroff-handler of my repository at
   git://git.kernel.org/pub/scm/linux/kernel/git/groeck/linux-staging.git.
   It is based on 3.18-rc2.
   
   A note on Cc: In the initial submission I had way too many Cc:, causing 
   the
   patchset to be treated as spam by many mailers and mailing list handlers,
   which of course defeated the purpose. This time around I am cutting down
   the distribution list down significantly. My apologies to anyone I may 
   have
   failed to copy this time around.
  
  you touch every single architecture with this patchset, but you didn't
  care about Ccing any of the arch-specific mailing lists, like lakml ?
  
 What is lakml ? linux-ker...@vger.kernel.org was copied, if that is what you

only the greatest mailing list of all time.

heh, Linux ARM Kernel Mailing List.

 refer to. I don't find a reference to lakml anywhere, sorry. I'll be happy to
 add it manually if you provide the address.
 
 Architecture specific mailing lists were copied on individual patches as long
 as those mailing lists are reported by the MAINTAINERS file.
 
  Please resend with proper people in Cc, IIRC RMK had a few very
  important comments about the idea behind this series.
  
 Felipe,
 
 That doesn't work. I tried with rev 1. The result was that the patch series
 was flagged as spam and got dropped by most mailing lists, as explained above,
 and I got tagged as spammer by Google and several other mail servers,
 preventing me from posting _anything_ for several days.

heh, that sucks.

-- 
balbi

Re: [PATCH v3 09/47] mfd: palmas: Register with kernel power-off handler

[Guenter Roeck]

On Mon, Nov 03, 2014 at 11:59:54AM -0600, Felipe Balbi wrote:
 On Mon, Nov 03, 2014 at 05:56:45PM +, Lee Jones wrote:
  On Mon, 27 Oct 2014, Guenter Roeck wrote:
  
   Register with kernel power-off handler instead of setting pm_power_off
   directly. Register with low priority to reflect that the original code
   only sets pm_power_off if it was not already set.
   
   Cc: Samuel Ortiz sa...@linux.intel.com
   Cc: Lee Jones lee.jo...@linaro.org
   Signed-off-by: Guenter Roeck li...@roeck-us.net
   ---
   v3:
   - Replace poweroff in all newly introduced variables and in text
 with power_off or power-off as appropriate
   - Replace POWEROFF_PRIORITY_xxx with POWER_OFF_PRIORITY_xxx
   v2:
   - Use define to specify poweroff handler priority
   - Use devm_register_power_off_handler
   - Use dev_warn instead of dev_err
   
drivers/mfd/palmas.c   | 31 +--
include/linux/mfd/palmas.h |  3 +++
2 files changed, 20 insertions(+), 14 deletions(-)
  
  Acked-by: Lee Jones lee.jo...@linaro.org
 
 missed lakml and linux-omap.
 
Felipe,

unfortunately, get_maintainer.pl doesn't give a hint that this and the
other affected patches should be sent to linux-omap. How am I supposed
to know ?

Note that linux-ker...@vger.kernel.org was copied on the entire series,
if that is what you mean with lakml. linux...@vger.kernel.org was also
copied on all patches. Additional mailing lists were only copied for
affected architectures to avoid for the patches to be tagged as spam.

If there is a list named lakml, I must have missed it, and I seem to be
unable to find a reference to it. If that is the case, my apologies,
and please provide a link to it.

Thanks,
Guenter
--
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 09/47] mfd: palmas: Register with kernel power-off handler

[Felipe Balbi]

On Mon, Nov 03, 2014 at 10:36:53AM -0800, Guenter Roeck wrote:
 On Mon, Nov 03, 2014 at 11:59:54AM -0600, Felipe Balbi wrote:
  On Mon, Nov 03, 2014 at 05:56:45PM +, Lee Jones wrote:
   On Mon, 27 Oct 2014, Guenter Roeck wrote:
   
Register with kernel power-off handler instead of setting pm_power_off
directly. Register with low priority to reflect that the original code
only sets pm_power_off if it was not already set.

Cc: Samuel Ortiz sa...@linux.intel.com
Cc: Lee Jones lee.jo...@linaro.org
Signed-off-by: Guenter Roeck li...@roeck-us.net
---
v3:
- Replace poweroff in all newly introduced variables and in text
  with power_off or power-off as appropriate
- Replace POWEROFF_PRIORITY_xxx with POWER_OFF_PRIORITY_xxx
v2:
- Use define to specify poweroff handler priority
- Use devm_register_power_off_handler
- Use dev_warn instead of dev_err

 drivers/mfd/palmas.c   | 31 +--
 include/linux/mfd/palmas.h |  3 +++
 2 files changed, 20 insertions(+), 14 deletions(-)
   
   Acked-by: Lee Jones lee.jo...@linaro.org
  
  missed lakml and linux-omap.
  
 Felipe,
 
 unfortunately, get_maintainer.pl doesn't give a hint that this and the
 other affected patches should be sent to linux-omap. How am I supposed
 to know ?

yeah, just looked and nobody bothered to patch MAINTAINERS when those
files were added. I just sent a patch adding them under OMAP SUPPORT.

 Note that linux-ker...@vger.kernel.org was copied on the entire series,
 if that is what you mean with lakml. linux...@vger.kernel.org was also
 copied on all patches. Additional mailing lists were only copied for
 affected architectures to avoid for the patches to be tagged as spam.
 
 If there is a list named lakml, I must have missed it, and I seem to be
 unable to find a reference to it. If that is the case, my apologies,
 and please provide a link to it.

here it is:

Linux ARM Kernel Mailing List linux-arm-ker...@lists.infradead.org

-- 
balbi


signature.asc
Description: Digital signature

Re: [PATCH 1/4] extcon: gpio: Convert the driver to use gpio desc API's

[Guenter Roeck]

On Mon, Nov 03, 2014 at 12:06:02PM -0600, Felipe Balbi wrote:
 On Mon, Nov 03, 2014 at 10:01:50AM -0800, Guenter Roeck wrote:
  On Mon, Nov 03, 2014 at 10:32:27AM -0600, Felipe Balbi wrote:
   From: George Cherian george.cher...@ti.com
   
   Convert the driver to use gpiod_* API's.
   
   Reviewed-by: Roger Quadros rog...@ti.com
   Signed-off-by: George Cherian george.cher...@ti.com
   Signed-off-by: Sekhar Nori nsek...@ti.com
   Signed-off-by: Felipe Balbi ba...@ti.com
   ---
  
  I think it might be useful and appropriate to explain that and why
  you remove support for active-low pins, instead of hiding it in a
  seemingly unrelated patch.
 
 removed ? why removed ? gpio descs handle that for you, read the source
 code.
 
Well, it for sure looks like it. Care to explain that in the patch,
as well as how the platform data flag is used ?

Thanks,
Guenter
--
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 09/47] mfd: palmas: Register with kernel power-off handler

[Guenter Roeck]

On Mon, Nov 03, 2014 at 12:43:12PM -0600, Felipe Balbi wrote:
 On Mon, Nov 03, 2014 at 10:36:53AM -0800, Guenter Roeck wrote:
  On Mon, Nov 03, 2014 at 11:59:54AM -0600, Felipe Balbi wrote:
   On Mon, Nov 03, 2014 at 05:56:45PM +, Lee Jones wrote:
On Mon, 27 Oct 2014, Guenter Roeck wrote:

 Register with kernel power-off handler instead of setting pm_power_off
 directly. Register with low priority to reflect that the original code
 only sets pm_power_off if it was not already set.
 
 Cc: Samuel Ortiz sa...@linux.intel.com
 Cc: Lee Jones lee.jo...@linaro.org
 Signed-off-by: Guenter Roeck li...@roeck-us.net
 ---
 v3:
 - Replace poweroff in all newly introduced variables and in text
   with power_off or power-off as appropriate
 - Replace POWEROFF_PRIORITY_xxx with POWER_OFF_PRIORITY_xxx
 v2:
 - Use define to specify poweroff handler priority
 - Use devm_register_power_off_handler
 - Use dev_warn instead of dev_err
 
  drivers/mfd/palmas.c   | 31 +--
  include/linux/mfd/palmas.h |  3 +++
  2 files changed, 20 insertions(+), 14 deletions(-)

Acked-by: Lee Jones lee.jo...@linaro.org
   
   missed lakml and linux-omap.
   
  Felipe,
  
  unfortunately, get_maintainer.pl doesn't give a hint that this and the
  other affected patches should be sent to linux-omap. How am I supposed
  to know ?
 
 yeah, just looked and nobody bothered to patch MAINTAINERS when those
 files were added. I just sent a patch adding them under OMAP SUPPORT.
 
I'll add the omap list as Cc: to the affected patches directly for now.

  Note that linux-ker...@vger.kernel.org was copied on the entire series,
  if that is what you mean with lakml. linux...@vger.kernel.org was also
  copied on all patches. Additional mailing lists were only copied for
  affected architectures to avoid for the patches to be tagged as spam.
  
  If there is a list named lakml, I must have missed it, and I seem to be
  unable to find a reference to it. If that is the case, my apologies,
  and please provide a link to it.
 
 here it is:
 
 Linux ARM Kernel Mailing List linux-arm-ker...@lists.infradead.org
 
Same problem here, though. If there are any ARM specific patches where the arm
mailing list was not copied, that was because the dependency is not listed in
the MAINTAINERS file. As mentioned before, copying the entire series to all
lists touched by one of the patches in the series just doesn't work (and may
be considered severe noise by some subscribers of those lists).

Guenter
--
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 00/47] kernel: Add support for power-off handler call chain

[Guenter Roeck]

On Mon, Nov 03, 2014 at 12:28:29PM -0600, Felipe Balbi wrote:
 Hi,
 
 On Mon, Nov 03, 2014 at 10:22:13AM -0800, Guenter Roeck wrote:
  On Mon, Nov 03, 2014 at 11:59:35AM -0600, Felipe Balbi wrote:
   Hi,
   
   On Mon, Oct 27, 2014 at 08:55:07AM -0700, Guenter Roeck wrote:
Various drivers implement architecture and/or device specific means to
remove power from the system.  For the most part, those drivers set the
global variable pm_power_off to point to a function within the driver.

This mechanism has a number of drawbacks.  Typically only one means
to remove power is supported (at least if pm_power_off is used).
At least in theory there can be multiple means to remove power, some of
which may be less desirable.  For example, one mechanism might power 
off the
entire system through an I/O port or gpio pin, while another might 
power off
a board by disabling its power controller. Other mechanisms may really 
just
execute a restart sequence or drop into the ROM monitor, or put the CPU 
into
sleep mode.  Using pm_power_off can also be racy if the function 
pointer is
set from a driver built as module, as the driver may be in the process 
of
being unloaded when pm_power_off is called.  If there are multiple 
power-off
handlers in the system, removing a module with such a handler may
inadvertently reset the pointer to pm_power_off to NULL, leaving the 
system
with no means to remove power.

Introduce a system power-off handler call chain to solve the described
problems.  This call chain is expected to be executed from the 
architecture
specific machine_power_off() function.  Drivers providing system 
power-off
functionality are expected to register with this call chain.  By using 
the
priority field in the notifier block, callers can control power-off 
handler
execution sequence and thus ensure that the power-off handler with the
optimal capabilities to remove power for a given system is called first.
A call chain instead of a single call to the highest priority handler is
used to provide fallback: If multiple power-off handlers are installed,
all handlers will be called until one actually succeeds to power off the
system.

Patch 01/47 implements the power-off handler API.

Patches 02/47 to 04/47 are cleanup patches to prepare for the move of
pm_power_off to a common location.

Patches 05/47 to 07/47 remove references to pm_power_off from devicetree
bindings descriptions.

Patch 08/47 moves the pm_power_off variable from architecture code to
kernel/reboot.c. 

Patches 09/47 to 34/47 convert various drivers to register with the 
kernel
power-off handler instead of setting pm_power_off directly.

Patches 35/47 to 46/47 do the same for architecture code.

Patch 47/47 finally removes pm_power_off.

For the most part, the individual patches include explanations why 
specific
priorities were chosen, at least if the selected priority is not the 
default
priority. Subsystem and architecture maintainers are encouraged to have 
a look
at the selected priorities and suggest improvements.

I ran the final code through my normal build and qemu tests. Results are
available at http://server.roeck-us.net:8010/builders in the 
'poweroff-handler'
column. I also built all available configurations for arm, mips, 
powerpc,
m68k, and sh architectures.

The series is available in branch poweroff-handler of my repository at
git://git.kernel.org/pub/scm/linux/kernel/git/groeck/linux-staging.git.
It is based on 3.18-rc2.

A note on Cc: In the initial submission I had way too many Cc:, causing 
the
patchset to be treated as spam by many mailers and mailing list 
handlers,
which of course defeated the purpose. This time around I am cutting down
the distribution list down significantly. My apologies to anyone I may 
have
failed to copy this time around.
   
   you touch every single architecture with this patchset, but you didn't
   care about Ccing any of the arch-specific mailing lists, like lakml ?
   
  What is lakml ? linux-ker...@vger.kernel.org was copied, if that is what you
 
 only the greatest mailing list of all time.
 
 heh, Linux ARM Kernel Mailing List.
 

Similar to linux-omap, linux-arm-kernel was copied on individual patches
if get_maintainer.pl suggested it. I'll be happy to add both lists manually
to the entire series for the next version of the patch set if the respective
maintainers (Tony and Russell) ask me to do so.

Note that this doesn't mean that the patches will actually be accepted by
those lists, especially if the lists are moderated for non-subscribers.

Guenter
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to 

Re: [PATCH 1/4] extcon: gpio: Convert the driver to use gpio desc API's

[Felipe Balbi]

Hi,

On Mon, Nov 03, 2014 at 10:51:08AM -0800, Guenter Roeck wrote:
 On Mon, Nov 03, 2014 at 12:06:02PM -0600, Felipe Balbi wrote:
  On Mon, Nov 03, 2014 at 10:01:50AM -0800, Guenter Roeck wrote:
   On Mon, Nov 03, 2014 at 10:32:27AM -0600, Felipe Balbi wrote:
From: George Cherian george.cher...@ti.com

Convert the driver to use gpiod_* API's.

Reviewed-by: Roger Quadros rog...@ti.com
Signed-off-by: George Cherian george.cher...@ti.com
Signed-off-by: Sekhar Nori nsek...@ti.com
Signed-off-by: Felipe Balbi ba...@ti.com
---
   
   I think it might be useful and appropriate to explain that and why
   you remove support for active-low pins, instead of hiding it in a
   seemingly unrelated patch.
  
  removed ? why removed ? gpio descs handle that for you, read the source
  code.
  
 Well, it for sure looks like it. Care to explain that in the patch,
 as well as how the platform data flag is used ?

I'll leave that to $author, I just cherry-picked and tested them.
Certainly that commit log needs some love.

-- 
balbi


signature.asc
Description: Digital signature

[PATCH 2/4] Documentation: DT: Add documentation for ti,opa362 bindings

[Marek Belisko]

Signed-off-by: Marek Belisko ma...@goldelico.com
---
 .../devicetree/bindings/video/ti,opa362.txt| 38 ++
 1 file changed, 38 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/video/ti,opa362.txt

diff --git a/Documentation/devicetree/bindings/video/ti,opa362.txt 
b/Documentation/devicetree/bindings/video/ti,opa362.txt
new file mode 100644
index 000..d7ed11a
--- /dev/null
+++ b/Documentation/devicetree/bindings/video/ti,opa362.txt
@@ -0,0 +1,38 @@
+OPA362 analog video amplifier
+
+Required properties:
+- compatible: ti,opa362
+- gpio: enable/disable output gpio
+
+Required node:
+- Video port 0 for opa362 input
+- Video port 1 for opa362 output
+
+Example:
+
+tv_amp: opa362 {
+compatible = ti,opa362;
+gpios = gpio1 23 0;  /* GPIO to enable video out amplifier */
+
+   label = opa362;
+ports {
+#address-cells = 1;
+#size-cells = 0;
+port@0 {
+reg = 0;
+opa_in: endpoint@0 {
+remote-endpoint = venc_out;
+};
+};
+
+port@1 {
+reg = 1;
+opa_out: endpoint@0 {
+remote-endpoint = tv_connector_in;
+};
+};
+};
+ };
+
+
+
-- 
1.9.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 0/4] omapdss: Add video output support for gta04 board

[Marek Belisko]

This patch series add support for video output on gta04 board. It consist
from opa362 video amplifier driver + DT bindings, adding venc - opa362 - 
svideo-connecor
setup in DT and finally static setup for tvbypass anc acbias bin in devconf1 
register
via pinctrl subsystem.

Marek Belisko (4):
  video: omapdss: Add opa362 driver
  Documentation: DT: Add documentation for ti,opa362 bindings
  arm: dts: omap3-gta04: Add handling for tv output
  arm: dts: omap3-gta04: Add static configuration for devconf1 register

 .../devicetree/bindings/video/ti,opa362.txt|  38 +++
 arch/arm/boot/dts/omap3-gta04.dtsi |  70 +
 drivers/video/fbdev/omap2/displays-new/Kconfig |   6 +
 drivers/video/fbdev/omap2/displays-new/Makefile|   1 +
 .../fbdev/omap2/displays-new/amplifier-opa362.c| 347 +
 5 files changed, 462 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/video/ti,opa362.txt
 create mode 100644 drivers/video/fbdev/omap2/displays-new/amplifier-opa362.c

-- 
1.9.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 1/4] video: omapdss: Add opa362 driver

[Marek Belisko]

opa362 is amplifier for videoand can be connected to the tvout pads
of the OMAP3. It has one gpio control for enable/disable of the output
(high impedance).

Signed-off-by: H. Nikolaus Schaller h...@goldelico.com
---
 drivers/video/fbdev/omap2/displays-new/Kconfig |   6 +
 drivers/video/fbdev/omap2/displays-new/Makefile|   1 +
 .../fbdev/omap2/displays-new/amplifier-opa362.c| 347 +
 3 files changed, 354 insertions(+)
 create mode 100644 drivers/video/fbdev/omap2/displays-new/amplifier-opa362.c

diff --git a/drivers/video/fbdev/omap2/displays-new/Kconfig 
b/drivers/video/fbdev/omap2/displays-new/Kconfig
index e6cfc38..211b3ec 100644
--- a/drivers/video/fbdev/omap2/displays-new/Kconfig
+++ b/drivers/video/fbdev/omap2/displays-new/Kconfig
@@ -1,6 +1,12 @@
 menu OMAP Display Device Drivers (new device model)
 depends on OMAP2_DSS
 
+config DISPLAY_AMPLIFIER_OPA362
+tristate external analog amplifier with output disable/high-Z (e.g. 
OPA362)
+   help
+ Driver to enable an external analog TV amplifier (e.g. OPA362)
+ through a GPIO.
+
 config DISPLAY_ENCODER_TFP410
 tristate TFP410 DPI to DVI Encoder
help
diff --git a/drivers/video/fbdev/omap2/displays-new/Makefile 
b/drivers/video/fbdev/omap2/displays-new/Makefile
index 0323a8a..b311542 100644
--- a/drivers/video/fbdev/omap2/displays-new/Makefile
+++ b/drivers/video/fbdev/omap2/displays-new/Makefile
@@ -1,3 +1,4 @@
+obj-$(CONFIG_DISPLAY_AMPLIFIER_OPA362) += amplifier-opa362.o
 obj-$(CONFIG_DISPLAY_ENCODER_TFP410) += encoder-tfp410.o
 obj-$(CONFIG_DISPLAY_ENCODER_TPD12S015) += encoder-tpd12s015.o
 obj-$(CONFIG_DISPLAY_CONNECTOR_DVI) += connector-dvi.o
diff --git a/drivers/video/fbdev/omap2/displays-new/amplifier-opa362.c 
b/drivers/video/fbdev/omap2/displays-new/amplifier-opa362.c
new file mode 100644
index 000..37b2443
--- /dev/null
+++ b/drivers/video/fbdev/omap2/displays-new/amplifier-opa362.c
@@ -0,0 +1,347 @@
+/*
+ * OPA362 analog video amplifier with output/power control
+ *
+ * Copyright (C) 2014 Golden Delicious Computers
+ * Author: H. Nikolaus Schaller h...@goldelico.com
+ *
+ * based on encoder-tfp410
+ *
+ * Copyright (C) 2013 Texas Instruments
+ * Author: Tomi Valkeinen tomi.valkei...@ti.com
+ *
+ * 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.
+ */
+
+#include linux/gpio.h
+#include linux/module.h
+#include linux/platform_device.h
+#include linux/slab.h
+#include linux/of_gpio.h
+
+#include video/omapdss.h
+#include video/omap-panel-data.h
+
+struct panel_drv_data {
+   struct omap_dss_device dssdev;
+   struct omap_dss_device *in;
+
+   int enable_gpio;
+   bool bypass;
+   bool acbias;
+
+   struct omap_video_timings timings;
+};
+
+#define to_panel_data(x) container_of(x, struct panel_drv_data, dssdev)
+
+static int opa362_connect(struct omap_dss_device *dssdev,
+   struct omap_dss_device *dst)
+{
+   struct panel_drv_data *ddata = to_panel_data(dssdev);
+   struct omap_dss_device *in = ddata-in;
+   int r;
+
+   dev_dbg(dssdev-dev, connect\n);
+
+   if (omapdss_device_is_connected(dssdev))
+   return -EBUSY;
+
+   r = in-ops.atv-connect(in, dssdev);
+   if (r)
+   return r;
+
+   dst-src = dssdev;
+   dssdev-dst = dst;
+
+   return 0;
+}
+
+static void opa362_disconnect(struct omap_dss_device *dssdev,
+   struct omap_dss_device *dst)
+{
+   struct panel_drv_data *ddata = to_panel_data(dssdev);
+   struct omap_dss_device *in = ddata-in;
+
+   dev_dbg(dssdev-dev, disconnect\n);
+
+   WARN_ON(!omapdss_device_is_connected(dssdev));
+   if (!omapdss_device_is_connected(dssdev))
+   return;
+
+   WARN_ON(dst != dssdev-dst);
+   if (dst != dssdev-dst)
+   return;
+
+   dst-src = NULL;
+   dssdev-dst = NULL;
+
+   in-ops.atv-disconnect(in, ddata-dssdev);
+}
+
+static int opa362_enable(struct omap_dss_device *dssdev)
+{
+   struct panel_drv_data *ddata = to_panel_data(dssdev);
+   struct omap_dss_device *in = ddata-in;
+   int r;
+
+   dev_dbg(dssdev-dev, enable\n);
+
+   if (!omapdss_device_is_connected(dssdev))
+   return -ENODEV;
+
+   if (omapdss_device_is_enabled(dssdev))
+   return 0;
+
+   in-ops.atv-set_timings(in, ddata-timings);
+   /* fixme: should we receive the invert from our consumer, i.e. the 
connector? */
+   in-ops.atv-invert_vid_out_polarity(in, true);
+
+   r = in-ops.atv-enable(in);
+   if (r)
+   return r;
+
+   if (gpio_is_valid(ddata-enable_gpio))
+   gpio_set_value_cansleep(ddata-enable_gpio, 1);
+
+   dssdev-state = OMAP_DSS_DISPLAY_ACTIVE;
+
+   return 0;
+}
+
+static void opa362_disable(struct omap_dss_device *dssdev)
+{
+

[PATCH 4/4] arm: dts: omap3-gta04: Add static configuration for devconf1 register

[Marek Belisko]

gta04 board need for tvout enabled 2 bits in devconf1 register (tvbypass and 
acbias).
Add single pinmux entry and enable it.

Signed-off-by: Marek Belisko ma...@goldelico.com
---
 arch/arm/boot/dts/omap3-gta04.dtsi | 22 ++
 1 file changed, 22 insertions(+)

diff --git a/arch/arm/boot/dts/omap3-gta04.dtsi 
b/arch/arm/boot/dts/omap3-gta04.dtsi
index e4d05f0..a456d37 100644
--- a/arch/arm/boot/dts/omap3-gta04.dtsi
+++ b/arch/arm/boot/dts/omap3-gta04.dtsi
@@ -118,6 +118,17 @@
};
};
};
+
+   /* pinmux for devconf1 */
+   control_devconf1: pinmux@480022d8 {
+   compatible = pinctrl-single;
+   reg = 0x480022d8 4;   /* single register */
+   #address-cells = 1;
+   #size-cells = 0;
+   pinctrl-single,bit-per-mux;
+   pinctrl-single,register-width = 32;
+   pinctrl-single,function-mask = 0xfc0bd5;
+   };
 };
 
 omap3_pmx_core {
@@ -497,3 +508,14 @@
};
};
 };
+
+control_devconf1 {
+   pinctrl-name = default;
+   pinctrl-0 =  tv_acbias_pins;
+
+   tv_acbias_pins: pinmux_tv_acbias_pins {
+   pinctrl-single,bits = 
+   0 0x40800 0x40800
+   ;
+   };
+};
-- 
1.9.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 3/4] arm: dts: omap3-gta04: Add handling for tv output

[Marek Belisko]

Add handling for gta04 tv out chain:
venc - opa362 - svideo

Signed-off-by: Marek Belisko ma...@goldelico.com
---
 arch/arm/boot/dts/omap3-gta04.dtsi | 48 ++
 1 file changed, 48 insertions(+)

diff --git a/arch/arm/boot/dts/omap3-gta04.dtsi 
b/arch/arm/boot/dts/omap3-gta04.dtsi
index fd34f91..e4d05f0 100644
--- a/arch/arm/boot/dts/omap3-gta04.dtsi
+++ b/arch/arm/boot/dts/omap3-gta04.dtsi
@@ -83,6 +83,41 @@
compatible = usb-nop-xceiv;
reset-gpios = gpio6 14 GPIO_ACTIVE_LOW;
};
+
+   tv0: connector@1 {
+   compatible = svideo-connector;
+   label = tv;
+
+   port {
+   tv_connector_in: endpoint {
+   remote-endpoint = opa_out;
+   };
+   };
+   };
+
+   tv_amp: opa362 {
+   compatible = ti,opa362;
+   gpios = gpio1 23 0;
+
+   label = opa362;
+   ports {
+   #address-cells = 1;
+   #size-cells = 0;
+   port@0 {
+   reg = 0;
+   opa_in: endpoint@0 {
+   remote-endpoint = venc_out;
+   };
+   };
+
+   port@1 {
+   reg = 1;
+   opa_out: endpoint@0 {
+   remote-endpoint = tv_connector_in;
+   };
+   };
+   };
+   };
 };
 
 omap3_pmx_core {
@@ -396,6 +431,19 @@
};
 };
 
+venc {
+   status = okay;
+
+   vdda-supply = vdac;
+
+   port {
+   venc_out: endpoint {
+   remote-endpoint = opa_in;
+   ti,channels = 2;
+   };
+   };
+};
+
 gpmc {
ranges = 0 0 0x3000 0x04; /* CS0: NAND */
 
-- 
1.9.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] mailbox/omap: adapt to the new mailbox framework

[Suman Anna]

The OMAP mailbox driver and its existing clients (remoteproc
for OMAP4+) are adapted to use the generic mailbox framework.

The main changes for the adaptation are:
  - The tasklet used for Tx is replaced with the state machine from
the generic mailbox framework. The workqueue used for processing
the received messages stays intact for minimizing the effects on
the OMAP mailbox clients.
  - The existing exported client API, omap_mbox_get, omap_mbox_put and
omap_mbox_send_msg are deleted, as the framework provides equivalent
functionality. A OMAP-specific omap_mbox_request_channel is added
though to support non-DT way of requesting mailboxes.
  - The OMAP mailbox driver is integrated with the mailbox framework
through the proper implementations of mbox_chan_ops, except for
.last_tx_done and .peek_data. The OMAP mailbox driver does not need
these ops, as it is completely interrupt driven.
  - The OMAP mailbox driver uses a custom of_xlate controller ops that
allows phandles for the pargs specifier instead of indexing to avoid
any channel registration order dependencies.
  - The new framework does not support multiple clients operating on a
single channel, so the reference counting logic is simplified.
  - The remoteproc driver (current client) is adapted to use the new API.
The notifier callbacks used within this client is replaced with the
regular callbacks from the newer framework.
  - The exported OMAP mailbox API are limited to omap_mbox_save_ctx,
omap_mbox_restore_ctx, omap_mbox_enable_irq  omap_mbox_disable_irq,
with the signature modified to take in the new mbox_chan handle instead
of the OMAP specific omap_mbox handle. The first 2 will be removed when
the OMAP mailbox driver is adapted to runtime_pm. The other exported
API omap_mbox_request_channel will be removed once existing legacy
users are converted to DT.

Cc: Jassi Brar jassisinghb...@gmail.com
Cc: Ohad Ben-Cohen o...@wizery.com
Signed-off-by: Suman Anna s-a...@ti.com
---
v3-v4: No code changes, switched the example to use the DSP node instead of
WkupM3 in the bindings document  minor commit description changes. Other than
that, this is a repost of the driver adaptation patch [1] from the OMAP Mailbox
framework adaptation series [2]. This patch is intended for the 3.19 merge 
window,
all the dependent patches in [2] are merged as of 3.18-rc2. The DTS patch in [2]
will be posted separately.

[1] http://marc.info/?l=linux-omapm=141038453917790w=2
[2] http://marc.info/?l=linux-omapm=141038447817775w=2

 .../devicetree/bindings/mailbox/omap-mailbox.txt   |  23 ++
 drivers/mailbox/omap-mailbox.c | 346 -
 drivers/remoteproc/omap_remoteproc.c   |  51 +--
 include/linux/omap-mailbox.h   |  16 +-
 4 files changed, 256 insertions(+), 180 deletions(-)

diff --git a/Documentation/devicetree/bindings/mailbox/omap-mailbox.txt 
b/Documentation/devicetree/bindings/mailbox/omap-mailbox.txt
index 48edc4b..d1a0433 100644
--- a/Documentation/devicetree/bindings/mailbox/omap-mailbox.txt
+++ b/Documentation/devicetree/bindings/mailbox/omap-mailbox.txt
@@ -43,6 +43,9 @@ Required properties:
device. The format is dependent on which interrupt
controller the OMAP device uses
 - ti,hwmods:   Name of the hwmod associated with the mailbox
+- #mbox-cells: Common mailbox binding property to identify the number
+   of cells required for the mailbox specifier. Should be
+   1
 - ti,mbox-num-users:   Number of targets (processor devices) that the mailbox
device can interrupt
 - ti,mbox-num-fifos:   Number of h/w fifo queues within the mailbox IP block
@@ -72,6 +75,18 @@ data that represent the following:
 Cell #3 (usr_id)  - mailbox user id for identifying the interrupt line
 associated with generating a tx/rx fifo interrupt.
 
+Mailbox Users:
+==
+A device needing to communicate with a target processor device should specify
+them using the common mailbox binding properties, mboxes and the optional
+mbox-names (please see Documentation/devicetree/bindings/mailbox/mailbox.txt
+for details). Each value of the mboxes property should contain a phandle to the
+mailbox controller device node and an args specifier that will be the phandle 
to
+the intended sub-mailbox child node to be used for communication. The 
equivalent
+mbox-names property value can be used to give a name to the communication 
channel
+to be used by the client user.
+
+
 Example:
 
 
@@ -81,6 +96,7 @@ mailbox: mailbox@4a0f4000 {
reg = 0x4a0f4000 0x200;
interrupts = GIC_SPI 26 IRQ_TYPE_LEVEL_HIGH;
ti,hwmods = mailbox;
+   #mbox-cells = 1;
ti,mbox-num-users = 3;
ti,mbox-num-fifos = 8;
mbox_ipu: mbox_ipu {
@@ -93,12 +109,19 @@ mailbox: 

[PATCH 2/2] ARM: dts: OMAP2+: Add #mbox-cells property to all mailbox nodes

[Suman Anna]

The '#mbox-cells' property is added to all the OMAP mailbox
nodes. This property is mandatory with the new mailbox framework.

Cc: Benoît Cousson bcous...@baylibre.com
Cc: Rob Herring robh...@kernel.org
Cc: Pawel Moll pawel.m...@arm.com
Cc: Mark Rutland mark.rutl...@arm.com
Cc: Ian Campbell ijc+devicet...@hellion.org.uk
Cc: Kumar Gala ga...@codeaurora.org
Signed-off-by: Suman Anna s-a...@ti.com
---
 arch/arm/boot/dts/am33xx.dtsi   |  1 +
 arch/arm/boot/dts/am4372.dtsi   |  1 +
 arch/arm/boot/dts/dra7.dtsi | 13 +
 arch/arm/boot/dts/omap2420.dtsi |  1 +
 arch/arm/boot/dts/omap2430.dtsi |  1 +
 arch/arm/boot/dts/omap3.dtsi|  1 +
 arch/arm/boot/dts/omap4.dtsi|  1 +
 arch/arm/boot/dts/omap5.dtsi|  1 +
 8 files changed, 20 insertions(+)

diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
index 8318105..41659df 100644
--- a/arch/arm/boot/dts/am33xx.dtsi
+++ b/arch/arm/boot/dts/am33xx.dtsi
@@ -356,6 +356,7 @@
reg = 0x480C8000 0x200;
interrupts = 77;
ti,hwmods = mailbox;
+   #mbox-cells = 1;
ti,mbox-num-users = 4;
ti,mbox-num-fifos = 8;
mbox_wkupm3: wkup_m3 {
diff --git a/arch/arm/boot/dts/am4372.dtsi b/arch/arm/boot/dts/am4372.dtsi
index 46660ff..4367f75 100644
--- a/arch/arm/boot/dts/am4372.dtsi
+++ b/arch/arm/boot/dts/am4372.dtsi
@@ -168,6 +168,7 @@
reg = 0x480C8000 0x200;
interrupts = GIC_SPI 77 IRQ_TYPE_LEVEL_HIGH;
ti,hwmods = mailbox;
+   #mbox-cells = 1;
ti,mbox-num-users = 4;
ti,mbox-num-fifos = 8;
mbox_wkupm3: wkup_m3 {
diff --git a/arch/arm/boot/dts/dra7.dtsi b/arch/arm/boot/dts/dra7.dtsi
index b8c9c67..2af7867 100644
--- a/arch/arm/boot/dts/dra7.dtsi
+++ b/arch/arm/boot/dts/dra7.dtsi
@@ -425,6 +425,7 @@
 GIC_SPI 135 IRQ_TYPE_LEVEL_HIGH,
 GIC_SPI 134 IRQ_TYPE_LEVEL_HIGH;
ti,hwmods = mailbox1;
+   #mbox-cells = 1;
ti,mbox-num-users = 3;
ti,mbox-num-fifos = 8;
status = disabled;
@@ -438,6 +439,7 @@
 GIC_SPI 239 IRQ_TYPE_LEVEL_HIGH,
 GIC_SPI 240 IRQ_TYPE_LEVEL_HIGH;
ti,hwmods = mailbox2;
+   #mbox-cells = 1;
ti,mbox-num-users = 4;
ti,mbox-num-fifos = 12;
status = disabled;
@@ -451,6 +453,7 @@
 GIC_SPI 243 IRQ_TYPE_LEVEL_HIGH,
 GIC_SPI 244 IRQ_TYPE_LEVEL_HIGH;
ti,hwmods = mailbox3;
+   #mbox-cells = 1;
ti,mbox-num-users = 4;
ti,mbox-num-fifos = 12;
status = disabled;
@@ -464,6 +467,7 @@
 GIC_SPI 247 IRQ_TYPE_LEVEL_HIGH,
 GIC_SPI 248 IRQ_TYPE_LEVEL_HIGH;
ti,hwmods = mailbox4;
+   #mbox-cells = 1;
ti,mbox-num-users = 4;
ti,mbox-num-fifos = 12;
status = disabled;
@@ -477,6 +481,7 @@
 GIC_SPI 251 IRQ_TYPE_LEVEL_HIGH,
 GIC_SPI 252 IRQ_TYPE_LEVEL_HIGH;
ti,hwmods = mailbox5;
+   #mbox-cells = 1;
ti,mbox-num-users = 4;
ti,mbox-num-fifos = 12;
status = disabled;
@@ -490,6 +495,7 @@
 GIC_SPI 255 IRQ_TYPE_LEVEL_HIGH,
 GIC_SPI 256 IRQ_TYPE_LEVEL_HIGH;
ti,hwmods = mailbox6;
+   #mbox-cells = 1;
ti,mbox-num-users = 4;
ti,mbox-num-fifos = 12;
status = disabled;
@@ -503,6 +509,7 @@
 GIC_SPI 259 IRQ_TYPE_LEVEL_HIGH,
 GIC_SPI 260 IRQ_TYPE_LEVEL_HIGH;
ti,hwmods = mailbox7;
+   #mbox-cells = 1;
ti,mbox-num-users = 4;
ti,mbox-num-fifos = 12;
status = disabled;
@@ -516,6 +523,7 @@
 GIC_SPI 263 IRQ_TYPE_LEVEL_HIGH,
 GIC_SPI 264 IRQ_TYPE_LEVEL_HIGH;
ti,hwmods = mailbox8;
+   #mbox-cells = 1;
ti,mbox-num-users = 4;
  

[PATCH 1/2] ARM: dts: DRA7: Add interrupts property to mailbox nodes

[Suman Anna]

Add the interrupts property to all the 13 mailbox nodes in
DRA7xx. The interrupts property information added is inline
with the expected values with the DRA7xx crossbar driver,
and is common to both DRA74x and DRA72x SoCs.

Do note that the mailbox 1 is only capable of generating out
3 interrupts, while all the remaining mailboxes have 4
interrupts each.

Signed-off-by: Suman Anna s-a...@ti.com
---
 arch/arm/boot/dts/dra7.dtsi | 51 +
 1 file changed, 51 insertions(+)

diff --git a/arch/arm/boot/dts/dra7.dtsi b/arch/arm/boot/dts/dra7.dtsi
index 9cc9843..b8c9c67 100644
--- a/arch/arm/boot/dts/dra7.dtsi
+++ b/arch/arm/boot/dts/dra7.dtsi
@@ -421,6 +421,9 @@
mailbox1: mailbox@4a0f4000 {
compatible = ti,omap4-mailbox;
reg = 0x4a0f4000 0x200;
+   interrupts = GIC_SPI 21 IRQ_TYPE_LEVEL_HIGH,
+GIC_SPI 135 IRQ_TYPE_LEVEL_HIGH,
+GIC_SPI 134 IRQ_TYPE_LEVEL_HIGH;
ti,hwmods = mailbox1;
ti,mbox-num-users = 3;
ti,mbox-num-fifos = 8;
@@ -430,6 +433,10 @@
mailbox2: mailbox@4883a000 {
compatible = ti,omap4-mailbox;
reg = 0x4883a000 0x200;
+   interrupts = GIC_SPI 237 IRQ_TYPE_LEVEL_HIGH,
+GIC_SPI 238 IRQ_TYPE_LEVEL_HIGH,
+GIC_SPI 239 IRQ_TYPE_LEVEL_HIGH,
+GIC_SPI 240 IRQ_TYPE_LEVEL_HIGH;
ti,hwmods = mailbox2;
ti,mbox-num-users = 4;
ti,mbox-num-fifos = 12;
@@ -439,6 +446,10 @@
mailbox3: mailbox@4883c000 {
compatible = ti,omap4-mailbox;
reg = 0x4883c000 0x200;
+   interrupts = GIC_SPI 241 IRQ_TYPE_LEVEL_HIGH,
+GIC_SPI 242 IRQ_TYPE_LEVEL_HIGH,
+GIC_SPI 243 IRQ_TYPE_LEVEL_HIGH,
+GIC_SPI 244 IRQ_TYPE_LEVEL_HIGH;
ti,hwmods = mailbox3;
ti,mbox-num-users = 4;
ti,mbox-num-fifos = 12;
@@ -448,6 +459,10 @@
mailbox4: mailbox@4883e000 {
compatible = ti,omap4-mailbox;
reg = 0x4883e000 0x200;
+   interrupts = GIC_SPI 245 IRQ_TYPE_LEVEL_HIGH,
+GIC_SPI 246 IRQ_TYPE_LEVEL_HIGH,
+GIC_SPI 247 IRQ_TYPE_LEVEL_HIGH,
+GIC_SPI 248 IRQ_TYPE_LEVEL_HIGH;
ti,hwmods = mailbox4;
ti,mbox-num-users = 4;
ti,mbox-num-fifos = 12;
@@ -457,6 +472,10 @@
mailbox5: mailbox@4884 {
compatible = ti,omap4-mailbox;
reg = 0x4884 0x200;
+   interrupts = GIC_SPI 249 IRQ_TYPE_LEVEL_HIGH,
+GIC_SPI 250 IRQ_TYPE_LEVEL_HIGH,
+GIC_SPI 251 IRQ_TYPE_LEVEL_HIGH,
+GIC_SPI 252 IRQ_TYPE_LEVEL_HIGH;
ti,hwmods = mailbox5;
ti,mbox-num-users = 4;
ti,mbox-num-fifos = 12;
@@ -466,6 +485,10 @@
mailbox6: mailbox@48842000 {
compatible = ti,omap4-mailbox;
reg = 0x48842000 0x200;
+   interrupts = GIC_SPI 253 IRQ_TYPE_LEVEL_HIGH,
+GIC_SPI 254 IRQ_TYPE_LEVEL_HIGH,
+GIC_SPI 255 IRQ_TYPE_LEVEL_HIGH,
+GIC_SPI 256 IRQ_TYPE_LEVEL_HIGH;
ti,hwmods = mailbox6;
ti,mbox-num-users = 4;
ti,mbox-num-fifos = 12;
@@ -475,6 +498,10 @@
mailbox7: mailbox@48844000 {
compatible = ti,omap4-mailbox;
reg = 0x48844000 0x200;
+   interrupts = GIC_SPI 257 IRQ_TYPE_LEVEL_HIGH,
+GIC_SPI 258 IRQ_TYPE_LEVEL_HIGH,
+GIC_SPI 259 IRQ_TYPE_LEVEL_HIGH,
+GIC_SPI 260 IRQ_TYPE_LEVEL_HIGH;
ti,hwmods = mailbox7;
ti,mbox-num-users = 4;
ti,mbox-num-fifos = 12;
@@ -484,6 +511,10 @@
mailbox8: mailbox@48846000 {
compatible = ti,omap4-mailbox;
reg = 0x48846000 0x200;
+   interrupts = GIC_SPI 261 IRQ_TYPE_LEVEL_HIGH,
+

[PATCH 0/2] OMAP Mailbox DTS patches for 3.19

[Suman Anna]

Hi Tony,

The following OMAP mailbox DTS patches are based on 3.18-rc3 and are
intended for the 3.19 merge window.

The first patch is new and adds the interrupts property to all the mailbox
nodes on DRA7xx now that we have the DRA7xx interrupt crossbar driver
functional and merged in the kernel.

The second patch enables the OMAP Mailbox DT users (there are none at the
moment) to use the recently merged Mailbox framework API, and is a repost
of the DTS patch [1] from the OMAP Mailbox framework adaptation series [2]
after rebasing. The driver portion of the adaptation patch is posted
separately so that Jassi can pick it up. Together, these are the last
base mailbox dependent patches for Dave's PM work on AM335x.

regards
Suman

[1] http://marc.info/?l=linux-omapm=141038449717781w=2
[2] http://marc.info/?l=linux-omapm=141038447817775w=2

Suman Anna (2):
  ARM: dts: DRA7: Add interrupts property to mailbox nodes
  ARM: dts: OMAP2+: Add #mbox-cells property to all mailbox nodes

 arch/arm/boot/dts/am33xx.dtsi   |  1 +
 arch/arm/boot/dts/am4372.dtsi   |  1 +
 arch/arm/boot/dts/dra7.dtsi | 64 +
 arch/arm/boot/dts/omap2420.dtsi |  1 +
 arch/arm/boot/dts/omap2430.dtsi |  1 +
 arch/arm/boot/dts/omap3.dtsi|  1 +
 arch/arm/boot/dts/omap4.dtsi|  1 +
 arch/arm/boot/dts/omap5.dtsi|  1 +
 8 files changed, 71 insertions(+)

-- 
2.1.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

[PATCH] MAINTAINERS: add more files under OMAP SUPPORT

[Felipe Balbi]

These files are very important to the healt
of the OMAP architecture, specially when it
comes to PM support which currently we have
working for at least OMAP3 and we'd like
to know about any changes being made to our
PMICs and IRQ controllers.

Signed-off-by: Felipe Balbi ba...@ti.com
---
 MAINTAINERS | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index 3c64271..4fc2a2c 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -6594,6 +6594,16 @@ T:   git 
git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap.git
 S: Maintained
 F: arch/arm/*omap*/
 F: drivers/i2c/busses/i2c-omap.c
+F: drivers/irqchip/irq-omap-intc.c
+F: drivers/mfd/*omap*.c
+F: drivers/mfd/menelaus.c
+F: drivers/mfd/palmas.c
+F: drivers/mfd/tps6*.c
+F: drivers/mfd/twl4030*.c
+F: drivers/regulator/palmas-regulator*.c
+F: drivers/regulator/pbias-regulator.c
+F: drivers/regulator/tps6*.c
+F: drivers/regulator/twl*.c
 F: include/linux/i2c-omap.h
 
 OMAP DEVICE TREE SUPPORT
-- 
2.1.0.GIT

--
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] MAINTAINERS: add more files under OMAP SUPPORT

[Felipe Balbi]

On Mon, Nov 03, 2014 at 06:32:53PM -0600, Felipe Balbi wrote:
 These files are very important to the healt
 of the OMAP architecture, specially when it
 comes to PM support which currently we have
 working for at least OMAP3 and we'd like
 to know about any changes being made to our
 PMICs and IRQ controllers.
 
 Signed-off-by: Felipe Balbi ba...@ti.com
 ---

I wonder if we should list file-by-file since some of hte tps devices
are rather used by NVidia and other SoCs.

If you prefer, I'll go grep around on our DTS files and list one-by-one,
no issues.

  MAINTAINERS | 10 ++
  1 file changed, 10 insertions(+)
 
 diff --git a/MAINTAINERS b/MAINTAINERS
 index 3c64271..4fc2a2c 100644
 --- a/MAINTAINERS
 +++ b/MAINTAINERS
 @@ -6594,6 +6594,16 @@ T: git 
 git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap.git
  S:   Maintained
  F:   arch/arm/*omap*/
  F:   drivers/i2c/busses/i2c-omap.c
 +F:   drivers/irqchip/irq-omap-intc.c
 +F:   drivers/mfd/*omap*.c
 +F:   drivers/mfd/menelaus.c
 +F:   drivers/mfd/palmas.c
 +F:   drivers/mfd/tps6*.c
 +F:   drivers/mfd/twl4030*.c
 +F:   drivers/regulator/palmas-regulator*.c
 +F:   drivers/regulator/pbias-regulator.c
 +F:   drivers/regulator/tps6*.c
 +F:   drivers/regulator/twl*.c
  F:   include/linux/i2c-omap.h
  
  OMAP DEVICE TREE SUPPORT
 -- 
 2.1.0.GIT
 

-- 
balbi


signature.asc
Description: Digital signature

Re: [PATCH 2/5] ARM: OMAP2+: gpmc: Error out if timings fail in gpmc_probe_generic_child()

[Tony Lindgren]

* Roger Quadros rog...@ti.com [141021 05:43]:
 gpmc_cs_set_timings() returns non-zero if there was
 an error while setting the GPMC timings. e.g. Timing was too
 large to be accomodated with current GPMC clock frequency and available
 timing range. Fail in this case, else we risk operating a NOR device
 with non compliant timings.

With the error checks now enabled properly, I noticed our
LAN9220 timings are overflowing. So we need the following
patch to switch over to use the known working u-boot timings.
Otherwise NFSroot will fail on quite a few boards.

Regards,

Tony

8 
From: Tony Lindgren t...@atomide.com
Date: Mon, 3 Nov 2014 16:33:14 -0800
Subject: [PATCH] ARM: dts: Use better omap GPMC timings for LAN9220

With the GPMC warnings now enabled, I noticed the LAN9220 timings
can overflow the GPMC registers with 200MHz L3 speed. Earlier we
were just skipping the bad timings and would continue with the
bootloader timings. Now we no longer allow to continue with bad
timings as we have the timings in the .dts files.

We could start using the GPMC clock divider, but let's instead
use the u-boot timings that are known to be working and a bit
faster. These are basically the u-boot NET_GPMC_CONFIG[1-6]
defines deciphered.

Signed-off-by: Tony Lindgren t...@atomide.com

--- a/arch/arm/boot/dts/omap-gpmc-smsc911x.dtsi
+++ b/arch/arm/boot/dts/omap-gpmc-smsc911x.dtsi
@@ -23,24 +23,30 @@
ethernet@gpmc {
compatible = smsc,lan9221, smsc,lan9115;
bank-width = 2;
-   gpmc,mux-add-data;
-   gpmc,cs-on-ns = 1;
-   gpmc,cs-rd-off-ns = 180;
-   gpmc,cs-wr-off-ns = 180;
-   gpmc,adv-rd-off-ns = 18;
-   gpmc,adv-wr-off-ns = 48;
-   gpmc,oe-on-ns = 54;
-   gpmc,oe-off-ns = 168;
-   gpmc,we-on-ns = 54;
-   gpmc,we-off-ns = 168;
-   gpmc,rd-cycle-ns = 186;
-   gpmc,wr-cycle-ns = 186;
-   gpmc,access-ns = 144;
-   gpmc,page-burst-access-ns = 24;
-   gpmc,bus-turnaround-ns = 90;
-   gpmc,cycle2cycle-delay-ns = 90;
-   gpmc,cycle2cycle-samecsen;
-   gpmc,cycle2cycle-diffcsen;
+   gpmc,device-width = 1;
+   gpmc,burst-length = 4;
+   gpmc,cycle2cycle-samecsen = 1;
+   gpmc,cycle2cycle-diffcsen = 1;
+   gpmc,cs-on-ns = 5;
+   gpmc,cs-rd-off-ns = 150;
+   gpmc,cs-wr-off-ns = 150;
+   gpmc,adv-on-ns = 0;
+   gpmc,adv-rd-off-ns = 15;
+   gpmc,adv-wr-off-ns = 40;
+   gpmc,oe-on-ns = 45;
+   gpmc,oe-off-ns = 140;
+   gpmc,we-on-ns = 45;
+   gpmc,we-off-ns = 140;
+   gpmc,rd-cycle-ns = 155;
+   gpmc,wr-cycle-ns = 155;
+   gpmc,access-ns = 120;
+   gpmc,page-burst-access-ns = 20;
+   gpmc,bus-turnaround-ns = 75;
+   gpmc,cycle2cycle-delay-ns = 75;
+   gpmc,wait-monitoring-ns = 0;
+   gpmc,clk-activation-ns = 0;
+   gpmc,wr-data-mux-bus-ns = 0;
+   gpmc,wr-access-ns = 0;
vddvario-supply = vddvario;
vdd33a-supply = vdd33a;
reg-io-width = 4;
diff --git a/arch/arm/boot/dts/omap3-sb-t35.dtsi 
b/arch/arm/boot/dts/omap3-sb-t35.dtsi
index d59e3de..fbbb455 100644
--- a/arch/arm/boot/dts/omap3-sb-t35.dtsi
+++ b/arch/arm/boot/dts/omap3-sb-t35.dtsi
@@ -22,24 +22,30 @@
interrupts = 1 IRQ_TYPE_LEVEL_LOW;
reg = 4 0 0xff;
bank-width = 2;
-   gpmc,mux-add-data;
-   gpmc,cs-on-ns = 1;
-   gpmc,cs-rd-off-ns = 180;
-   gpmc,cs-wr-off-ns = 180;
-   gpmc,adv-rd-off-ns = 18;
-   gpmc,adv-wr-off-ns = 48;
-   gpmc,oe-on-ns = 54;
-   gpmc,oe-off-ns = 168;
-   gpmc,we-on-ns = 54;
-   gpmc,we-off-ns = 168;
-   gpmc,rd-cycle-ns = 186;
-   gpmc,wr-cycle-ns = 186;
-   gpmc,access-ns = 144;
-   gpmc,page-burst-access-ns = 24;
-   gpmc,bus-turnaround-ns = 90;
-   gpmc,cycle2cycle-delay-ns = 90;
-   gpmc,cycle2cycle-samecsen;
-   gpmc,cycle2cycle-diffcsen;
+   gpmc,device-width = 1;
+   gpmc,burst-length = 4;
+   gpmc,cycle2cycle-samecsen = 1;
+   gpmc,cycle2cycle-diffcsen = 1;
+   gpmc,cs-on-ns = 5;
+   gpmc,cs-rd-off-ns = 150;
+   gpmc,cs-wr-off-ns = 150;
+   gpmc,adv-on-ns = 0;
+   gpmc,adv-rd-off-ns = 15;
+   gpmc,adv-wr-off-ns = 40;
+   gpmc,oe-on-ns = 45;
+   gpmc,oe-off-ns = 140;
+   gpmc,we-on-ns = 45;
+   gpmc,we-off-ns = 140;
+  

Re: [PATCH 2/5] ARM: OMAP2+: gpmc: Error out if timings fail in gpmc_probe_generic_child()

[Tony Lindgren]

* Tony Lindgren t...@atomide.com [141103 16:48]:
 --- a/arch/arm/boot/dts/omap-gpmc-smsc911x.dtsi
 +++ b/arch/arm/boot/dts/omap-gpmc-smsc911x.dtsi
 + gpmc,device-width = 1;
 + gpmc,burst-length = 4;

I've left out the gpmc,burst-length as that produces now
warnings about not being used and does not seem to work if
enabled.

 --- a/arch/arm/boot/dts/omap3-sb-t35.dtsi
 +++ b/arch/arm/boot/dts/omap3-sb-t35.dtsi
 + gpmc,device-width = 1;
 + gpmc,burst-length = 4;

And here too.

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] ARM: dts: Fix missing GPMC NAND device width for omap3 boards

[Tony Lindgren]

Looks like we have some GPMC NAND timings missing device
width. This fixes gpmc_cs_program_settings: invalid width 0!
errors during boot.

Signed-off-by: Tony Lindgren t...@atomide.com

--- a/arch/arm/boot/dts/omap3-evm-37xx.dts
+++ b/arch/arm/boot/dts/omap3-evm-37xx.dts
@@ -161,6 +161,7 @@
linux,mtd-name= hynix,h8kds0un0mer-4em;
reg = 0 0 4;  /* CS0, offset 0, IO size 4 */
nand-bus-width = 16;
+   gpmc,device-width = 2;
ti,nand-ecc-opt = bch8;
 
gpmc,sync-clk-ps = 0;
diff --git a/arch/arm/boot/dts/omap3-igep0020.dts 
b/arch/arm/boot/dts/omap3-igep0020.dts
index ff0b11d..cc9343e 100644
--- a/arch/arm/boot/dts/omap3-igep0020.dts
+++ b/arch/arm/boot/dts/omap3-igep0020.dts
@@ -204,6 +204,7 @@
linux,mtd-name= micron,mt29c4g96maz;
reg = 0 0 4;  /* CS0, offset 0, IO size 4 */
nand-bus-width = 16;
+   gpmc,device-width = 2;
ti,nand-ecc-opt = bch8;
 
gpmc,sync-clk-ps = 0;
diff --git a/arch/arm/boot/dts/omap3-igep0030.dts 
b/arch/arm/boot/dts/omap3-igep0030.dts
index fd7ed71..84b7452 100644
--- a/arch/arm/boot/dts/omap3-igep0030.dts
+++ b/arch/arm/boot/dts/omap3-igep0030.dts
@@ -61,6 +61,7 @@
linux,mtd-name= micron,mt29c4g96maz;
reg = 0 0 4;  /* CS0, offset 0, IO size 4 */
nand-bus-width = 16;
+   gpmc,device-width = 2;
ti,nand-ecc-opt = bch8;
 
gpmc,sync-clk-ps = 0;
diff --git a/arch/arm/boot/dts/omap3-ldp.dts b/arch/arm/boot/dts/omap3-ldp.dts
index 37d305a..202f95a 100644
--- a/arch/arm/boot/dts/omap3-ldp.dts
+++ b/arch/arm/boot/dts/omap3-ldp.dts
@@ -103,6 +103,7 @@
linux,mtd-name= micron,nand;
reg = 0 0 4;  /* CS0, offset 0, IO size 4 */
nand-bus-width = 16;
+   gpmc,device-width = 2;
ti,nand-ecc-opt = bch8;
 
gpmc,sync-clk-ps = 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: [PATCH] arm: omap: hwmod: drop unnecessary list initialization

[Felipe Balbi]

Hi,

On Mon, Jul 28, 2014 at 05:24:34AM +, Paul Walmsley wrote:
 On Tue, 15 Jul 2014, Felipe Balbi wrote:
 
  ml-node and sl-node are currently initialized
  by means of INIT_LIST_HEAD(). That initialiation
  is followed by a list_add() call.
  
  Looking at what both these functions do we will have:
  
  ml-node.next = ml-node;
  ml-node.prev = ml-node;
  oi-master-master_ports.next.prev = ml-node;
  ml-node.next = oi-master-master_ports.next;
  ml-node.prev = oi-master-master_ports;
  oi-master-master_ports.next = ml-node;
  
  from this, it's clear that both INIT_LIST_HEAD() calls
  are unnecessary and can be safely removed.
  
  Signed-off-by: Felipe Balbi ba...@ti.com
  ---
  
  found by code inspection, boot tested on am437x SK on today's
  linux-next + pending patches.
 
 Thanks, queued for v3.18.

This is not on v3.18, what happened ?

$ git log --author=ba...@ti.com linus/master ^v3.17 -- 
arch/arm/mach-omap2/omap_hwmod.c
$

-- 
balbi


signature.asc
Description: Digital signature

Re: [PATCH 0/4] extcon: gpio: add DT support

[George Cherian]

Hi Felipe et al.

Another series was posted by removing the platform support.
https://lkml.org/lkml/2014/10/14/244

I guess I forgot to copy linux-omap.



On 11/03/2014 10:02 PM, Felipe Balbi wrote:

Hi,

this series has been tested with v3.18-rc2 with a
yet-to-be-released board (called X15). That board
is DT-only and we use extcon-gpio to decide which
USB mode should be used (host or peripheral).

George Cherian (4):
   extcon: gpio: Convert the driver to use gpio desc API's
   extcon: gpio: Add dt support for the driver.
   extcon: gpio: Always use gpio_get_value_cansleep
   extcon: gpio: Add support for using cable names

  .../devicetree/bindings/extcon/extcon-gpio.txt | 23 ++
  drivers/extcon/extcon-gpio.c   | 93 ++
  2 files changed, 84 insertions(+), 32 deletions(-)
  create mode 100644 Documentation/devicetree/bindings/extcon/extcon-gpio.txt



--
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