Re: [PATCH v2 8/8] DT:omap3+ads7846: use new common touchscreen bindings

[Grazvydas Ignotas]

Hi,

On Fri, Nov 13, 2015 at 10:35 PM, H. Nikolaus Schaller
 wrote:
> The standard touch screen bindings [1] replace the private ti,swap-xy
> with touchscreen-swaped-x-y. And for the Openpandora we use
> touchscreen-size etc. to match the LCD screen size.
>
> [1]: Documentation/devicetree/bindings/input/touchscreen/touchscreen.txt
>
> Signed-off-by: H. Nikolaus Schaller 
> ---
>  arch/arm/boot/dts/omap3-lilly-a83x.dtsi  |  2 +-
>  arch/arm/boot/dts/omap3-pandora-common.dtsi  | 17 +
>  arch/arm/boot/dts/omap3-panel-sharp-ls037v7dw01.dtsi |  2 +-
>  3 files changed, 15 insertions(+), 6 deletions(-)
>
> diff --git a/arch/arm/boot/dts/omap3-lilly-a83x.dtsi 
> b/arch/arm/boot/dts/omap3-lilly-a83x.dtsi
> index d0dd036..01dae66 100644
> --- a/arch/arm/boot/dts/omap3-lilly-a83x.dtsi
> +++ b/arch/arm/boot/dts/omap3-lilly-a83x.dtsi
> @@ -325,7 +325,7 @@
> ti,y-max = /bits/ 16 <3600>;
> ti,x-plate-ohms = /bits/ 16 <80>;
> ti,pressure-max = /bits/ 16 <255>;
> -   ti,swap-xy;
> +   touchscreen-swapped-x-y;
>
> linux,wakeup;
> };
> diff --git a/arch/arm/boot/dts/omap3-pandora-common.dtsi 
> b/arch/arm/boot/dts/omap3-pandora-common.dtsi
> index f672a04..9497cc6 100644
> --- a/arch/arm/boot/dts/omap3-pandora-common.dtsi
> +++ b/arch/arm/boot/dts/omap3-pandora-common.dtsi
> @@ -696,10 +696,19 @@
> pendown-gpio = < 30 0>;
> vcc-supply = <>;
>
> -   ti,x-min = /bits/ 16 <0>;
> -   ti,x-max = /bits/ 16 <8000>;
> -   ti,y-min = /bits/ 16 <0>;
> -   ti,y-max = /bits/ 16 <4800>;
> +   touchscreen-size-x = <800>;
> +   touchscreen-size-y = <480>;
> +   touchscreen-max-pressure = <1000>;
> +   touchscreen-fuzz-x = <16>;
> +   touchscreen-fuzz-y = <16>;
> +   touchscreen-fuzz-pressure = <10>;
> +   touchscreen-inverted-x;
> +   touchscreen-inverted-y;
> +
> +   ti,x-min = /bits/ 16 <160>;
> +   ti,x-max = /bits/ 16 <3900>;
> +   ti,y-min = /bits/ 16 <220>;
> +   ti,y-max = /bits/ 16 <3750>;

I'm not sure this is a good idea, there have been at least 3 different
batches of LCDs which slightly different touchscreens attached, with
such thresholds we might end up with unreachable touchscreen points on
some units. If I understand right, calibration won't help if for some
screen locations ADC reading goes below/above these min/max thresholds
on some specific units? If so there should probably be at least 10%
margin in either case to make calibration useful.

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

Re: [PATCH 2/2] ARM: dts: Fix WLAN regression on omap5-uevm

[Grazvydas Ignotas]

On Fri, Sep 18, 2015 at 9:39 PM, Robert Nelson  wrote:
> On Fri, Sep 18, 2015 at 11:51 AM, Tony Lindgren  wrote:
>> * Robert Nelson  [150918 09:45]:
>>> On Fri, Sep 18, 2015 at 11:29 AM, Tony Lindgren  wrote:
>>> > Commit 99f84cae43df ("ARM: dts: add wl12xx/wl18xx bindings") added
>>> > device tree bindings for the TI WLAN SDIO on many omap variants.
>>> >
>>> > I recall wondering how come omap5-uevm did not have the WLAN
>>> > added and this issue has been bugging me for a while now, and
>>> > I finally tracked it down to a bad pinmux regression, and a missing
>>> > deferred probe handling for the 32k clock from palmas that's
>>> > requested by twl6040.
>>> >
>>> > Basically 392adaf796b9 ("ARM: dts: omap5-evm: Add mcspi data")
>>> > added pin muxing for mcspi4 that conflicts with the onboard
>>> > WLAN. While the omap5-uevm docs say the WLAN is not populated,
>>> > this was probably only the case for initial prototypes. Both
>>> > omap5-uevm boards I have have WLAN populated.
>>>
>>> Production boards from svtronics don't populate the wlan..
>>>
>>> http://www.svtronics.com/EVM/OMAP5432/5432
>>>
>>> quote: "WiFi not available on this model"
>
> Okay, got an email back from svtronics, there was a special omap5_uevm
> + wlan order option for production units.

The boards we bought came without wlan, so that seems to be the
"default" configuration.

I vote for using separate DT overlay for the wlan version to avoid
unnecessary probing. OTOH the pins are not exposed on expansion
connectors and should not conflict with custom peripherals, so no
strong opinion here.

Gražvydas
--
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: omap2plus_defconfig: enable GPIO_PCA953X

[Grazvydas Ignotas]

This enables tca6424a GPIO expander driver that in turn enables
TPD12S015 HDMI ESD protection and level shifter on OMAP5 uevm.
In other words, it makes HDMI work on OMAP5 uevm.

Signed-off-by: Grazvydas Ignotas <nota...@gmail.com>
---
 arch/arm/configs/omap2plus_defconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/configs/omap2plus_defconfig 
b/arch/arm/configs/omap2plus_defconfig
index 1860f51..13dcd01 100644
--- a/arch/arm/configs/omap2plus_defconfig
+++ b/arch/arm/configs/omap2plus_defconfig
@@ -240,6 +240,7 @@ CONFIG_SSI_PROTOCOL=m
 CONFIG_PINCTRL_SINGLE=y
 CONFIG_DEBUG_GPIO=y
 CONFIG_GPIO_SYSFS=y
+CONFIG_GPIO_PCA953X=m
 CONFIG_GPIO_PCF857X=y
 CONFIG_GPIO_TWL4030=y
 CONFIG_GPIO_PALMAS=y
-- 
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] ARM: dts: omap5-uevm.dts: fix i2c5 pinctrl offsets

[Grazvydas Ignotas]

The i2c5 pinctrl offsets are wrong. If the bootloader doesn't set the
pins up, communication with tca6424a doesn't work (controller timeouts)
and it is not possible to enable HDMI.

Fixes: 9be495c42609 ("ARM: dts: omap5-evm: Add I2c pinctrl data")
Signed-off-by: Grazvydas Ignotas <nota...@gmail.com>
---
 arch/arm/boot/dts/omap5-uevm.dts | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm/boot/dts/omap5-uevm.dts b/arch/arm/boot/dts/omap5-uevm.dts
index 3cc8f35..3cb030f 100644
--- a/arch/arm/boot/dts/omap5-uevm.dts
+++ b/arch/arm/boot/dts/omap5-uevm.dts
@@ -174,8 +174,8 @@
 
i2c5_pins: pinmux_i2c5_pins {
pinctrl-single,pins = <
-   0x184 (PIN_INPUT | MUX_MODE0)   /* i2c5_scl */
-   0x186 (PIN_INPUT | MUX_MODE0)   /* i2c5_sda */
+   0x186 (PIN_INPUT | MUX_MODE0)   /* i2c5_scl */
+   0x188 (PIN_INPUT | MUX_MODE0)   /* i2c5_sda */
>;
};
 
-- 
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

Re: mysterious crashes on OMAP5 uevm

[Grazvydas Ignotas]

On Mon, Sep 14, 2015 at 10:35 PM, Dr. H. Nikolaus Schaller
<h...@goldelico.com> wrote:
>
> Am 14.09.2015 um 21:02 schrieb Tony Lindgren <t...@atomide.com>:
>
>> * Russell King - ARM Linux <li...@arm.linux.org.uk> [150914 05:16]:
>>> On Fri, Sep 11, 2015 at 03:03:07PM +0100, Russell King - ARM Linux wrote:
>>>>
>>>> Merely changing __LINUX_ARM_ARCH__ >= 7 to >= 6 should fix the problem,
>>>> and I doubt there's any ARMv6 non-T2 systems out there that would be
>>>> affected by clearing the IT state bits.
>>>
>>> Please test the following patch:
>>
>> While we're waiting for Grazvydas to test.. Looks good to me:
>>
>> Acked-by: Tony Lindgren <t...@atomide.com>
>
> I have tested on:
> * GTA04 with DM3730 (OMAP3)
> * Pyra prototype with OMAP5432
> No X server crashes seen any more.
>
> Tested-by: H. Nikolaus Schaller <h...@goldelico.com>

Tested-by: Grazvydas Ignotas <nota...@gmail.com>
on OMAP5 uevm running v4.2 built with omap2plus_defconfig.
On v4.3-rc1 hsmmc controller probe is deferred for whatever reason and
never reprobes, so my rootfs is never mounted and I could not test,
but that looks unrelated.

I guess it's worth marking this one for stable.

Gražvydas
--
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: mysterious crashes on OMAP5 uevm

[Grazvydas Ignotas]

On Thu, Sep 10, 2015 at 10:30 AM, Russell King - ARM Linux
 wrote:
> On Thu, Sep 10, 2015 at 08:42:57AM +0200, Dr. H. Nikolaus Schaller wrote:
>> ...
>>
>> Now, disabling CONFIG_ARCH_MULTI_V6 also makes the bug go away and adding the
>> >> #if 0 //__LINUX_ARM_ARCH__ >= 7
>> makes it re-appear.
>>
>> A while ago I tried to debug running the x-server under strace and could 
>> find that it also has
>> something to do with SIGALRM.
>>
>> And that is very consistent with “enable/disable” by modifying 
>> arch/arm/kernel/signal.c
>
> It would be really nice if someone could diagnose what's going on here.
> What exception is causing the X server to be killed (someone said a
> segfault)?  What is the register state at the point that happens?  What
> does the code look like  Is it happening inside the SIGALRM handler, or
> when the SIGALRM handler has returned?
>
> I'd suggest attaching gdb to the X server, but remember to set gdb to
> ignore SIGPIPEs.

It's actually pretty random, see some debug sessions in [1].
The first one is the most useful one, but I haven't though of checking
what pixman_rasterize_edges() was doing when the signal arrived, and
most often the "less useful" segfaults occur. However from the
disassembly (see debug1_libpixman.gz) it can be seen that the signal
arrived right after IT.

[1] http://notaz.gp2x.de/tmp/thumb_segfault/

Gražvydas
--
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

mysterious crashes on OMAP5 uevm

[Grazvydas Ignotas]

Hi,

this is a longstanding problem I'm seeing since the very beginning,
which was around 3.12 or so (when I've first got the hardware) and it
seems 4.2 is affected by it still. Basically what happens is Xorg
randomly segfaults at some "impossible" location. I don't have the
details at the moment (could get them is needed), but from what I
examined with gdb some time ago the situation did not make any sense.

There are 2 workarounds that I know which make the problem go away
(one is enough):
- recompile Xorg with -marm (I'm using Debian armhf so it's thumb2 by default)
- disable ARCH_MULTI_V6 in the kernel config

Because of the above workarounds I have forgotten about it several
times, but it regularly comes back and bites again. It would look like
some missing erratum workaround, but I have all of them enabled in the
kernel.

Does anyone know about this? Perhaps some missing erratum workaround
in the bootloader? u-boot isn't too old here (2015.07).

Gražvydas
--
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: mysterious crashes on OMAP5 uevm

[Grazvydas Ignotas]

On Tue, Sep 8, 2015 at 4:38 PM, Tony Lindgren <t...@atomide.com> wrote:
> * Grazvydas Ignotas <nota...@gmail.com> [150908 05:50]:
>> Hi,
>>
>> this is a longstanding problem I'm seeing since the very beginning,
>> which was around 3.12 or so (when I've first got the hardware) and it
>> seems 4.2 is affected by it still. Basically what happens is Xorg
>> randomly segfaults at some "impossible" location. I don't have the
>> details at the moment (could get them is needed), but from what I
>> examined with gdb some time ago the situation did not make any sense.
>>
>> There are 2 workarounds that I know which make the problem go away
>> (one is enough):
>> - recompile Xorg with -marm (I'm using Debian armhf so it's thumb2 by 
>> default)
>> - disable ARCH_MULTI_V6 in the kernel config
>>
>> Because of the above workarounds I have forgotten about it several
>> times, but it regularly comes back and bites again. It would look like
>> some missing erratum workaround, but I have all of them enabled in the
>> kernel.
>>
>> Does anyone know about this? Perhaps some missing erratum workaround
>> in the bootloader? u-boot isn't too old here (2015.07).
>
> Seems like some incorrect handling with CONFIG_CPU_V6 compiled in..
> Maybe try to narrow it down by commenting out some CONFIG_CPU_V6 and
> __LINUX_ARM_ARCH__ = 6 ifdefs in the git grep CONFIG_CPU_V6
> places ignoring uncompress and davinci code.

ok with that it was quite easy to find. On a kernel with ARCH_MULTI_V6
disabled, it is enough to just do this:

--- a/arch/arm/kernel/signal.c
+++ b/arch/arm/kernel/signal.c
@@ -340,13 +340,13 @@ setup_return(struct pt_regs *regs, struct ksignal *ksig,
/*
 * The LSB of the handler determines if we're going to
 * be using THUMB or ARM mode for this signal handler.
 */
thumb = handler & 1;

-#if __LINUX_ARM_ARCH__ >= 7
+#if 0 //__LINUX_ARM_ARCH__ >= 7
/*
 * Clear the If-Then Thumb-2 execution state
 * ARM spec requires this to be all 000s in ARM mode
 * Snapdragon S4/Krait misbehaves on a Thumb=>ARM
 * signal transition without this.
 */

... and the problem appears, so I guess this needs some real
multiplatform handling,.

> Do you have some easy way to reproduce this issue?

Just moving a browser window around with mouse usually triggers it
within a minute.

>
> Regards,
>
> Tony

Gražvydas
--
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] twl4030_charger: fix another compile error

[Grazvydas Ignotas]

When CONFIG_CHARGER_TWL4030=y and CONFIG_TWL4030_MADC=m we get a
compile error:

drivers/built-in.o: In function `twl4030_charger_update_current':
twl4030_charger.c:(.text+0x504681): undefined reference to
`twl4030_get_madc_conversion'

Use IS_REACHABLE to fix it.

Cc: NeilBrown <n...@brown.name>
Reported-by: Randy Dunlap <rdun...@infradead.org>
Signed-off-by: Grazvydas Ignotas <nota...@gmail.com>
---
 drivers/power/twl4030_charger.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/power/twl4030_charger.c b/drivers/power/twl4030_charger.c
index f4f2c1f..5bcc76f 100644
--- a/drivers/power/twl4030_charger.c
+++ b/drivers/power/twl4030_charger.c
@@ -91,7 +91,7 @@
 #define TWL4030_MSTATEC_COMPLETE1  0x0b
 #define TWL4030_MSTATEC_COMPLETE4  0x0e
 
-#if IS_ENABLED(CONFIG_TWL4030_MADC)
+#if IS_REACHABLE(CONFIG_TWL4030_MADC)
 /*
  * If AC (Accessory Charger) voltage exceeds 4.5V (MADC 11)
  * then AC is available.
-- 
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 4/4] ARM: OMAP2+: omap3-pandora: add wifi support

[Grazvydas Ignotas]

Add wl1251 support via pdata-quirks as it's driver lacks DT
support. MMC3 is marked disabled in DT so that MMC3 instance of
hsmmc driver is probed using platform data with special card init
callback.

Signed-off-by: Grazvydas Ignotas nota...@gmail.com
---
 arch/arm/boot/dts/omap3-pandora-common.dtsi |   5 ++
 arch/arm/mach-omap2/pdata-quirks.c  | 101 
 2 files changed, 106 insertions(+)

diff --git a/arch/arm/boot/dts/omap3-pandora-common.dtsi 
b/arch/arm/boot/dts/omap3-pandora-common.dtsi
index 6e82c4a..f2084e6 100644
--- a/arch/arm/boot/dts/omap3-pandora-common.dtsi
+++ b/arch/arm/boot/dts/omap3-pandora-common.dtsi
@@ -514,6 +514,11 @@
/*wp-gpios = gpio4 31 GPIO_ACTIVE_HIGH;*//* GPIO_127 */
 };
 
+/* mmc3 is probed using pdata-quirks to pass wl1251 card data */
+mmc3 {
+   status = disabled;
+};
+
 /* bluetooth*/
 uart1 {
 };
diff --git a/arch/arm/mach-omap2/pdata-quirks.c 
b/arch/arm/mach-omap2/pdata-quirks.c
index 3c97aa49..95f6724 100644
--- a/arch/arm/mach-omap2/pdata-quirks.c
+++ b/arch/arm/mach-omap2/pdata-quirks.c
@@ -14,6 +14,11 @@
 #include linux/kernel.h
 #include linux/of_platform.h
 #include linux/ti_wilink_st.h
+#include linux/wl12xx.h
+#include linux/mmc/card.h
+#include linux/mmc/host.h
+#include linux/regulator/machine.h
+#include linux/regulator/fixed.h
 
 #include linux/platform_data/pinctrl-single.h
 #include linux/platform_data/iommu-omap.h
@@ -25,6 +30,7 @@
 #include omap_device.h
 #include omap-secure.h
 #include soc.h
+#include hsmmc.h
 
 struct pdata_init {
const char *compatible;
@@ -269,14 +275,109 @@ static void __init omap3_tao3530_legacy_init(void)
hsmmc2_internal_input_clk();
 }
 
+/* omap3pandora legacy devices */
+#define PANDORA_WIFI_IRQ_GPIO  21
+#define PANDORA_WIFI_NRESET_GPIO   23
+
 static struct platform_device pandora_backlight = {
.name   = pandora-backlight,
.id = -1,
 };
 
+static struct regulator_consumer_supply pandora_vmmc3_supply[] = {
+   REGULATOR_SUPPLY(vmmc, omap_hsmmc.2),
+};
+
+static struct regulator_init_data pandora_vmmc3 = {
+   .constraints = {
+   .valid_ops_mask = REGULATOR_CHANGE_STATUS,
+   },
+   .num_consumer_supplies  = ARRAY_SIZE(pandora_vmmc3_supply),
+   .consumer_supplies  = pandora_vmmc3_supply,
+};
+
+static struct fixed_voltage_config pandora_vwlan = {
+   .supply_name= vwlan,
+   .microvolts = 180, /* 1.8V */
+   .gpio   = PANDORA_WIFI_NRESET_GPIO,
+   .startup_delay  = 5, /* 50ms */
+   .enable_high= 1,
+   .init_data  = pandora_vmmc3,
+};
+
+static struct platform_device pandora_vwlan_device = {
+   .name   = reg-fixed-voltage,
+   .id = 1,
+   .dev = {
+   .platform_data = pandora_vwlan,
+   },
+};
+
+static void pandora_wl1251_init_card(struct mmc_card *card)
+{
+   /*
+* We have TI wl1251 attached to MMC3. Pass this information to
+* SDIO core because it can't be probed by normal methods.
+*/
+   if (card-type == MMC_TYPE_SDIO || card-type == MMC_TYPE_SD_COMBO) {
+   card-quirks |= MMC_QUIRK_NONSTD_SDIO;
+   card-cccr.wide_bus = 1;
+   card-cis.vendor = 0x104c;
+   card-cis.device = 0x9066;
+   card-cis.blksize = 512;
+   card-cis.max_dtr = 2400;
+   card-ocr = 0x80;
+   }
+}
+
+static struct omap2_hsmmc_info pandora_mmc3[] = {
+   {
+   .mmc= 3,
+   .caps   = MMC_CAP_4_BIT_DATA | MMC_CAP_POWER_OFF_CARD,
+   .gpio_cd= -EINVAL,
+   .gpio_wp= -EINVAL,
+   .init_card  = pandora_wl1251_init_card,
+   },
+   {}  /* Terminator */
+};
+
+static void __init pandora_wl1251_init(void)
+{
+   struct wl1251_platform_data pandora_wl1251_pdata;
+   int ret;
+
+   memset(pandora_wl1251_pdata, 0, sizeof(pandora_wl1251_pdata));
+
+   pandora_wl1251_pdata.power_gpio = -1;
+
+   ret = gpio_request_one(PANDORA_WIFI_IRQ_GPIO, GPIOF_IN, wl1251 irq);
+   if (ret  0)
+   goto fail;
+
+   pandora_wl1251_pdata.irq = gpio_to_irq(PANDORA_WIFI_IRQ_GPIO);
+   if (pandora_wl1251_pdata.irq  0)
+   goto fail_irq;
+
+   pandora_wl1251_pdata.use_eeprom = true;
+   ret = wl1251_set_platform_data(pandora_wl1251_pdata);
+   if (ret  0)
+   goto fail_irq;
+
+   return;
+
+fail_irq:
+   gpio_free(PANDORA_WIFI_IRQ_GPIO);
+fail:
+   pr_err(wl1251 board initialisation failed\n);
+}
+
 static void __init omap3_pandora_legacy_init(void)
 {
platform_device_register(pandora_backlight);
+   platform_device_register(pandora_vwlan_device);
+   omap_hsmmc_init(pandora_mmc3);
+   omap_hsmmc_late_init(pandora_mmc3);
+   pandora_wl1251_init

[PATCH 1/4] ARM: dts: omap3-pandora: miscellaneous corrections

[Grazvydas Ignotas]

- add pandora specific compatible name
- fix mmc2 card detect polarity
- fix mmc1 and mmc2 write protect polarity
- disable write protect pins because of production issue and add an
  explanation why they are disabled
- fix NAND partition name to reflect the correct address

Signed-off-by: Grazvydas Ignotas nota...@gmail.com
---
 arch/arm/boot/dts/omap3-pandora-1ghz.dts|  2 +-
 arch/arm/boot/dts/omap3-pandora-600mhz.dts  |  2 +-
 arch/arm/boot/dts/omap3-pandora-common.dtsi | 13 +
 3 files changed, 11 insertions(+), 6 deletions(-)

diff --git a/arch/arm/boot/dts/omap3-pandora-1ghz.dts 
b/arch/arm/boot/dts/omap3-pandora-1ghz.dts
index 9619a28..25498f7 100644
--- a/arch/arm/boot/dts/omap3-pandora-1ghz.dts
+++ b/arch/arm/boot/dts/omap3-pandora-1ghz.dts
@@ -19,7 +19,7 @@
 / {
model = Pandora Handheld Console 1GHz;
 
-   compatible = ti,omap36xx, ti,omap3;
+   compatible = openpandora,omap3-pandora-1ghz, ti,omap36xx, 
ti,omap3;
 };
 
 omap3_pmx_core2 {
diff --git a/arch/arm/boot/dts/omap3-pandora-600mhz.dts 
b/arch/arm/boot/dts/omap3-pandora-600mhz.dts
index fb803a7..8775897 100644
--- a/arch/arm/boot/dts/omap3-pandora-600mhz.dts
+++ b/arch/arm/boot/dts/omap3-pandora-600mhz.dts
@@ -19,7 +19,7 @@
 / {
model = Pandora Handheld Console;
 
-   compatible = ti,omap3;
+   compatible = openpandora,omap3-pandora-600mhz, ti,omap3430, 
ti,omap3;
 };
 
 omap3_pmx_core2 {
diff --git a/arch/arm/boot/dts/omap3-pandora-common.dtsi 
b/arch/arm/boot/dts/omap3-pandora-common.dtsi
index 782ab1f..f6363bc 100644
--- a/arch/arm/boot/dts/omap3-pandora-common.dtsi
+++ b/arch/arm/boot/dts/omap3-pandora-common.dtsi
@@ -459,13 +459,18 @@
power = 50;
 };
 
+/*
+ * Many pandora boards have been produced with defective write-protect switches
+ * on either slot, so it was decided not to use this feature. If you know
+ * your board has good switches, feel free to uncomment wp-gpios below.
+ */
 mmc1 {
pinctrl-names = default;
pinctrl-0 = mmc1_pins;
vmmc-supply = vmmc1;
bus-width = 4;
cd-gpios = twl_gpio 0 GPIO_ACTIVE_LOW;
-   wp-gpios = gpio4 30 GPIO_ACTIVE_LOW; /* GPIO_126 */
+   /*wp-gpios = gpio4 30 GPIO_ACTIVE_HIGH;*//* GPIO_126 */
 };
 
 mmc2 {
@@ -473,8 +478,8 @@
pinctrl-0 = mmc2_pins;
vmmc-supply = vmmc2;
bus-width = 4;
-   cd-gpios = twl_gpio 1 GPIO_ACTIVE_HIGH;
-   wp-gpios = gpio4 31 GPIO_ACTIVE_LOW; /* GPIO_127 */
+   cd-gpios = twl_gpio 1 GPIO_ACTIVE_LOW;
+   /*wp-gpios = gpio4 31 GPIO_ACTIVE_HIGH;*//* GPIO_127 */
 };
 
 /* bluetooth*/
@@ -545,7 +550,7 @@
reg = 0x28 0xa0;
};
 
-   filesystem@68 {
+   filesystem@c8 {
label = rootfs;
reg = 0xc8 0; /* 0 = MTDPART_SIZ_FULL */
};
-- 
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 2/4] ARM: dts: omap3-pandora: add support for usb host and 32k buffer

[Grazvydas Ignotas]

This adds missing bits for EHCI HS USB host support and 32k clock
buffer control for the wg7210 bt+wifi module.

Signed-off-by: Grazvydas Ignotas nota...@gmail.com
---
 arch/arm/boot/dts/omap3-pandora-common.dtsi | 36 +
 1 file changed, 36 insertions(+)

diff --git a/arch/arm/boot/dts/omap3-pandora-common.dtsi 
b/arch/arm/boot/dts/omap3-pandora-common.dtsi
index f6363bc..6e82c4a 100644
--- a/arch/arm/boot/dts/omap3-pandora-common.dtsi
+++ b/arch/arm/boot/dts/omap3-pandora-common.dtsi
@@ -199,6 +199,38 @@
gpios = gpio4 12 GPIO_ACTIVE_HIGH;   /* GPIO_108 */
};
};
+
+   /* HS USB Host PHY on PORT 2 */
+   hsusb2_phy: hsusb2_phy {
+   compatible = usb-nop-xceiv;
+   reset-gpios = gpio1 16 GPIO_ACTIVE_LOW; /* GPIO_16 */
+   vcc-supply = vaux2;
+   };
+
+   /* HS USB Host VBUS supply
+* disabling this regulator causes current leakage, and LCD flicker
+* on earlier (CC) board revisions, so keep it always on */
+   usb_host_5v: fixed-regulator-usb_host_5v {
+   compatible = regulator-fixed;
+   regulator-name = usb_host_5v;
+   regulator-min-microvolt = 500;
+   regulator-max-microvolt = 500;
+   regulator-always-on;
+   regulator-boot-on;
+   enable-active-high;
+   gpio = gpio6 4 0;/* GPIO_164 */
+   };
+
+   /* wg7210 (wifi+bt module) 32k clock buffer */
+   wg7210_32k: fixed-regulator-wg7210_32k {
+   compatible = regulator-fixed;
+   regulator-name = wg7210_32k;
+   regulator-min-microvolt = 180;
+   regulator-max-microvolt = 180;
+   regulator-always-on;
+   enable-active-high;
+   gpio = twl_gpio 13 GPIO_ACTIVE_HIGH;
+   };
 };
 
 omap3_pmx_core {
@@ -501,6 +533,10 @@
port2-mode = ehci-phy;
 };
 
+usbhsehci {
+   phys = 0 hsusb2_phy;
+};
+
 gpmc {
ranges = 0 0 0x3000 0x100; /* CS0: 16MB for 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 3/4] ARM: OMAP2+: omap3-pandora: add backlight support

[Grazvydas Ignotas]

Add backlight support via pdata-quirks as it's driver lacks DT support.

Signed-off-by: Grazvydas Ignotas nota...@gmail.com
---
 arch/arm/mach-omap2/pdata-quirks.c | 12 
 1 file changed, 12 insertions(+)

diff --git a/arch/arm/mach-omap2/pdata-quirks.c 
b/arch/arm/mach-omap2/pdata-quirks.c
index 821171c..3c97aa49 100644
--- a/arch/arm/mach-omap2/pdata-quirks.c
+++ b/arch/arm/mach-omap2/pdata-quirks.c
@@ -268,6 +268,16 @@ static void __init omap3_tao3530_legacy_init(void)
 {
hsmmc2_internal_input_clk();
 }
+
+static struct platform_device pandora_backlight = {
+   .name   = pandora-backlight,
+   .id = -1,
+};
+
+static void __init omap3_pandora_legacy_init(void)
+{
+   platform_device_register(pandora_backlight);
+}
 #endif /* CONFIG_ARCH_OMAP3 */
 
 #if defined(CONFIG_ARCH_OMAP4) || defined(CONFIG_SOC_OMAP5)
@@ -381,6 +391,8 @@ static struct pdata_init pdata_quirks[] __initdata = {
{ ti,omap3-evm-37xx, omap3_evm_legacy_init, },
{ ti,am3517-evm, am3517_evm_legacy_init, },
{ technexion,omap3-tao3530, omap3_tao3530_legacy_init, },
+   { openpandora,omap3-pandora-600mhz, omap3_pandora_legacy_init, },
+   { openpandora,omap3-pandora-1ghz, omap3_pandora_legacy_init, },
 #endif
 #ifdef CONFIG_SOC_OMAP5
{ ti,omap5-uevm, omap5_uevm_legacy_init, },
-- 
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

Re: [PATCH 2/2] ARM: OMAP2+: Remove legacy booting support for Pandora

[Grazvydas Ignotas]

On Fri, Jul 17, 2015 at 7:54 AM, Tony Lindgren t...@atomide.com wrote:
 * Tony Lindgren t...@atomide.com [150716 09:28]:
 * Grazvydas Ignotas nota...@gmail.com [150716 07:16]:
  Hi,
 
  On Thu, Jul 16, 2015 at 2:59 PM, Tony Lindgren t...@atomide.com wrote:
   We've been moving all omap2+ based systems to boot in device tree only
   mode for a few years now. Only omap3 has legacy booting support
   remaining. Most omap3 boards already have related arch/arm/boot/*.dts*
   files for booting with device tree.
  
   This board has support for device tree based booting, and we've been
   printing warnings about the legacy booting being deprecated for a
   few merge cycles now. Let's attempt to remove the legacy booting
   for it.
  
   The reason for removing the legacy booting support now rather than
   later is we can simply revert this patch if necessary if we run
   into some unexpected issues that are not trivial to fix for the
   device tree based booting.
 
  It seems we lose wifi, backlight, audio and usb host mainline support
  with this as pandora's .dts currently lacks all that stuff.

 More on that later on, but a question on the vendor kernel first..

  That said I'm not aware of any mainline users (everyone seems to be on
  our vendor kernel), so maybe we can add those later.

 What all is keeping people from using mainline kernel on pandora?
 Is it the sgx or are there other reasons too remaining?

There are multiple things, besides SGX:
- lack of 1GHz support due to lack of ABB/AVS. Meanwhile we have been
running all pandoras at 1GHz for years without ABB/AVS on our kernel
and no problems have been reported by users.
- overclocking support. It seems most DM3730s can do 1.2GHz and all
can do 1.1GHz, running the device at that clock noticeably speeds up
things, so we provide that functionality out of the box. No instances
of SoC damage were reported over the years.
- using aufs for software packages, aufs wasn't merged and probably
will never be
- keypad Fn key handling in the driver to simulate hardware Fn (not
allowed in mainline)
- lack of driver for analog nubs

That said there probably are some people who can live without the
above and prefer new features of new mainline kernels.

 Hmm wifi should be easy, isn't that just libertas_sdio?

 Nope wl1251, we can initialize with pdata-quirks.c for now if it
 does not yet support device tree except for the SPI version.
 The same goes for the other devices too if needed, I'd assume
 the the EHCI is similar to beagle though.

Yeah maybe I should try to come up with a patch...

 And of course we can still wait on removing the pandora board file
 if you want to. Sounds like that may not be needed though because of
 people using vendor kernel in this case even with the legacy
 booting?

Yes if it interferes with other mainline work just go ahead and remove it.


 Regards,

 Tony

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

Re: [PATCH 2/2] ARM: OMAP2+: Remove legacy booting support for Pandora

[Grazvydas Ignotas]

Hi,

On Thu, Jul 16, 2015 at 2:59 PM, Tony Lindgren t...@atomide.com wrote:
 We've been moving all omap2+ based systems to boot in device tree only
 mode for a few years now. Only omap3 has legacy booting support
 remaining. Most omap3 boards already have related arch/arm/boot/*.dts*
 files for booting with device tree.

 This board has support for device tree based booting, and we've been
 printing warnings about the legacy booting being deprecated for a
 few merge cycles now. Let's attempt to remove the legacy booting
 for it.

 The reason for removing the legacy booting support now rather than
 later is we can simply revert this patch if necessary if we run
 into some unexpected issues that are not trivial to fix for the
 device tree based booting.

It seems we lose wifi, backlight, audio and usb host mainline support
with this as pandora's .dts currently lacks all that stuff.
That said I'm not aware of any mainline users (everyone seems to be on
our vendor kernel), so maybe we can add those later.


 Cc: Signed-off-by: Grazvydas Ignotas nota...@gmail.com

I have not signed this off...

 Signed-off-by: Tony Lindgren t...@atomide.com
 ---
  arch/arm/mach-omap2/Makefile |   1 -
  arch/arm/mach-omap2/board-omap3pandora.c | 633 
 ---
  2 files changed, 634 deletions(-)
  delete mode 100644 arch/arm/mach-omap2/board-omap3pandora.c



Gražvydas
--
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: [RFC] Fix omap3 booting with thumb2 compiled kernel

[Grazvydas Ignotas]

On Thu, May 28, 2015 at 1:55 AM, Tony Lindgren t...@atomide.com wrote:
 8 --
 From: Tony Lindgren t...@atomide.com
 Date: Wed, 27 May 2015 15:33:57 -0700
 Subject: [PATCH] ARM: OMAP3: Fix booting with thumb2 kernel

 We get a NULL pointer dereference on omap3 for thumb2 compiled kernels:

 Internal error: Oops: 8005 [#1] SMP THUMB2
 ...
 [c046497b] (_raw_spin_unlock_irqrestore) from [c0024375]
 (omap3_enter_idle_bm+0xc5/0x178)
 [c0024375] (omap3_enter_idle_bm) from [c0374e63]
 (cpuidle_enter_state+0x77/0x27c)
 [c0374e63] (cpuidle_enter_state) from [c00627f1]
 (cpu_startup_entry+0x155/0x23c)
 [c00627f1] (cpu_startup_entry) from [c06b9a47]
 (start_kernel+0x32f/0x338)
 [c06b9a47] (start_kernel) from [8000807f] (0x8000807f)

 The power management related assembly on moaps needs to interact with

moaps - omaps


Gražvydas
--
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] thermal: ti-soc-thermal: dra7: Implement Workaround for Errata i813

[Grazvydas Ignotas]

On Thu, Apr 16, 2015 at 1:18 PM, Keerthy j-keer...@ti.com wrote:
 DESCRIPTION

 Spurious Thermal Alert: Talert can happen randomly while the device remains 
 under the temperature limit
 defined for this event to trig. This spurious event is caused by a incorrect 
 re-synchronization between
 clock domains. The comparison between configured threshold and current 
 temperature value can happen
 while the value is transitioning (metastable), thus causing inappropriate 
 event generation.
 No spurious event occurs as long as the threshold value stays unchanged. 
 Spurious event can be
 generated while a thermal alert threshold is modified in
 CONTROL_BANDGAP_THRESHOLD_MPU/GPU/CORE/DSPEVE/IVA_n.
 WORKAROUND

 Spurious event generation can be avoided by performing following sequence 
 when the threshold is
 modified:
 1. Mask the hot/cold events at the thermal IP level.
 2. Modify Threshold.
 3. Unmask the hot/cold events at the thermal IP level.

 Signed-off-by: Keerthy j-keer...@ti.com
 ---
  .../thermal/ti-soc-thermal/dra752-thermal-data.c   |  3 +-
  drivers/thermal/ti-soc-thermal/ti-bandgap.c| 41 
 +-
  drivers/thermal/ti-soc-thermal/ti-bandgap.h|  4 ++-
  3 files changed, 45 insertions(+), 3 deletions(-)

 ...

 diff --git a/drivers/thermal/ti-soc-thermal/ti-bandgap.h 
 b/drivers/thermal/ti-soc-thermal/ti-bandgap.h
 index b2da3fc..0c52f7a 100644
 --- a/drivers/thermal/ti-soc-thermal/ti-bandgap.h
 +++ b/drivers/thermal/ti-soc-thermal/ti-bandgap.h
 @@ -320,7 +320,8 @@ struct ti_temp_sensor {
   *
   * TI_BANDGAP_FEATURE_ERRATA_814 - used to workaorund when the bandgap device
   * has Errata 814
 - *
 + * TI_BANDGAP_FEATURE_ERRATA_813 - used to workaorund when the bandgap device
 + * has Errata 813

workaorund?


--
Gražvydas
--
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: ARM errata 430973 on multi platform kernels

[Grazvydas Ignotas]

On Fri, Apr 10, 2015 at 1:44 AM, Tony Lindgren t...@atomide.com wrote:
 * Grazvydas Ignotas nota...@gmail.com [150409 15:37]:
 On Tue, Apr 7, 2015 at 5:23 AM, Tony Lindgren t...@atomide.com wrote:
  * Matthijs van Duin matthijsvand...@gmail.com [150406 11:15]:
 
  On 6 April 2015 at 19:42, Tony Lindgren t...@atomide.com wrote:
   Hmm but it still seems to do something also on cortex-a8 r3p2 that
   is supposedly not affected by 430973.. Based on my tests so far, at 
   least
   armhf running cpuburn-a8 in the background and doing apt-get update
   segfaults constantly without flush BTAC/BTB. This seems to be the case
   no matter how the aux ctrl reg bits are set..
 
  That sounds really odd.  The TRM is fairly explicit about BTB
  flush executing as nop when IBE is not set. Of course the TRM is not
  exactly flawless, but still...
 
  Oops, sorry user error.. I was trying to clear IBE as a banked register
  like L2 enable bit and of course it did not get cleared.. Clearing it
  with a smc call really clears it. And in that case my test case seems to
  work reliably on r3p2 without erratum 430973 enabled.

 May I ask how do you perform the smc call? I wanted to clear IBE too
 to experiment, but it just hangs my board, even if I just write back
 the same value. Here is what I do:

 asm (mrc p15, 0, %0, c1, c0, 1 : =r(val));

 asm (.arch_extension sec\n\t
  mov r0,  %0\n
  mov r12, #3\n
  smc #0\n
  :: r(val) : r0, r12);

 I just run this from a sysfs write handler, does it need to be run on
 SRAM or something?

 Best done in the bootloader.. I just hacked it into the restore from
 off-idle to test, see below. But for that you naturally need to have
 a device with working idle and it's usable for just testing for lazy
 people.

 Regards,

 Tony

 --- a/arch/arm/mach-omap2/sleep34xx.S
 +++ b/arch/arm/mach-omap2/sleep34xx.S
 @@ -516,6 +516,7 @@ l2_inv_gp:
 ldr r4, scratchpad_base
 ldr r3, [r4,#0xBC]
 ldr r0, [r3,#4]
 +   bic r0, r1, #(1  6)

Hmm did you mean r0 instead of r1 here? I hope your test results
didn't come from some other random bit from r1 being written to
aux_ctrl.
And according to readback this doesn't seem to work for me, even when
my board has idle working. Or is it not supposed to be visible in
readback?

Anyway I've managed to clear that damn bit in the bootloader, but
failed to measure any performance impact from clearing this bit and
getting rid of BTB flush mcr in cpu_v7_switch_mm() (this is on DM3730
with r3p2 A8). My test was to simply run 2 processes that would spin a
counter (running more processes doesn't seem to increase context
switches per second, so running 2 seemed enough).


Gražvydas
--
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] ti-soc-thermal: implement omap3 support

[Grazvydas Ignotas]

On Tue, Mar 31, 2015 at 11:42 AM, Pavel Machek pa...@ucw.cz wrote:

 This adds support for OMAP3 chips to ti-soc-thermal. As requested by
 TI people, it is marked unreliable and warning is printed.

 Signed-off-by: Pavel Machek pa...@ucw.cz

 ---
 ...
 --- /dev/null
 +++ b/drivers/thermal/ti-soc-thermal/omap3-thermal-data.c
 @@ -0,0 +1,103 @@
 +/*
 + * OMAP3 thermal driver.
 + *
 + * Copyright (C) 2011-2012 Texas Instruments Inc.
 + * Copyright (C) 2014 Pavel Machek pa...@ucw.cz
 + *
 + * This software is licensed under the terms of the GNU General Public
 + * License version 2, as published by the Free Software Foundation, and
 + * may be copied, distributed, and modified under those terms.
 + *
 + * This program is distributed in the hope that it will be useful,
 + * but WITHOUT ANY WARRANTY; without even the implied warranty of
 + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
 + * GNU General Public License for more details.
 + *
 + * Note
 + * http://www.ti.com/lit/er/sprz278f/sprz278f.pdf Advisory
 + * 3.1.1.186 MMC OCP Clock Not Gated When Thermal Sensor Is Used
 + *
 + * Also TI says:
 + * Just be careful when you try to make thermal policy like decisions
 + * based on this sensor. Placement of the sensor w.r.t the actual logic
 + * generating heat has to be a factor as well. If you are just looking
 + * for an approximation temperature (thermometerish kind), you might be
 + * ok with this. I am not sure we'd find any TI data around this.. just a
 + * heads up.
 + */
 +
 +#include ti-thermal.h
 +#include ti-bandgap.h
 +
 +/*
 + * OMAP34XX has one instance of thermal sensor for MPU
 + * need to describe the individual bit fields
 + */
 +static struct temp_sensor_registers
 +omap34xx_mpu_temp_sensor_registers = {
 +   .temp_sensor_ctrl = 0,
 +   .bgap_soc_mask = BIT(8),
 +   .bgap_eocz_mask = BIT(7),
 +   .bgap_dtemp_mask = 0x7f,
 +
 +   .bgap_mode_ctrl = 0,
 +   .mode_ctrl_mask = BIT(9),
 +};
 +
 +/* Thresholds and limits for OMAP34XX MPU temperature sensor */
 +static struct temp_sensor_data omap34xx_mpu_temp_sensor_data = {
 +   .min_freq = 32768,
 +   .max_freq = 32768,
 +   .max_temp = -99000,
 +   .min_temp = 99000,

This looks mixed up. Also, perhaps use -4 to 125000 to match the
table below?

 +   .hyst_val = 5000,
 +};
 +
 +/*
 + * Temperature values in milli degree celsius
 + */
 +static const int
 +omap34xx_adc_to_temp[128] = {
 +   -4, -4, -4, -4, -4, -39000, -38000, -36000,
 +   -34000, -32000, -31000, -29000, -28000, -26000, -25000, -24000,
 +   -22000, -21000, -19000, -18000, -17000, -15000, -14000, -12000,
 +   -11000, -9000, -8000, -7000, -5000, -4000, -2000, -1000, ,
 +   1000, 3000, 4000, 5000, 7000, 8000, 1, 11000, 13000, 14000,
 +   15000, 17000, 18000, 2, 21000, 22000, 24000, 25000, 27000,
 +   28000, 3, 31000, 32000, 34000, 35000, 37000, 38000, 39000,
 +   41000, 42000, 44000, 45000, 47000, 48000, 49000, 51000, 52000,
 +   53000, 55000, 56000, 58000, 59000, 6, 62000, 63000, 65000,
 +   66000, 67000, 69000, 7, 72000, 73000, 74000, 76000, 77000,
 +   79000, 8, 81000, 83000, 84000, 85000, 87000, 88000, 89000,
 +   91000, 92000, 94000, 95000, 96000, 98000, 99000, 10,
 +   102000, 103000, 105000, 106000, 107000, 109000, 11, 111000,
 +   113000, 114000, 116000, 117000, 118000, 12, 121000, 122000,
 +   124000, 124000, 125000, 125000, 125000, 125000, 125000
 +};


Gražvydas
--
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: twl4030_charger: need changes to get probed?

[Grazvydas Ignotas]

On Sat, Mar 7, 2015 at 12:56 AM, Pali Rohár pali.ro...@gmail.com wrote:
 On Friday 06 March 2015 23:40:34 Pavel Machek wrote:
 On Sat 2015-03-07 00:12:07, Grazvydas Ignotas wrote:
  On Fri, Mar 6, 2015 at 11:57 PM, Pali Rohár
  pali.ro...@gmail.com wrote:
   On Friday 06 March 2015 22:24:17 Pavel Machek wrote:
   Hi!
  
   According to n900 dts, twl4030-bci (aka charger) should
   be included.
  
   AFAIK it is not present on n900...
 
  Right, it uses twl5030 variant without the charger, charging
  on n900 is provided by separate chip and for a good reason
  as twl's charger is not that good. Forcing the driver to
  load just ends up with it accessing non-existent registers
  over i2c.

 Ok, but:

 1) Why is the twl4030-bci enabled in n900's dts, then


 maybe it is bug in n900 dts...

 Grazvydas, is there some runtime check if twl4030/twl5030 chip
 has charger or not? or do we need to explicitly disable device
 twl4030-bci in DT?

Actually from looking at the schematics, it looks like the charger
pins are still there but all connected to ground. So it probably has
the charger after all, it's just not connected or used.

I'm not aware or any registers for direct detection, and indirect
detection is difficult because BCI mostly disables itself when no
charger is connected and most registers read as 0 or have old values
from last charging session (which will never happen on n900).

There is IDCODE register on twl4030 itself, but it's documented as not
meaningful when accessed over i2c (when is it meaningful then??).

drivers/mfd/twl-core.c has a i2c_device_id table of various twl4030
variants, some of which have no charger. N900 has GAIA/twl5030, which
differs from twl4030 only by vaux2 regulator according to that file.
N900's old board files specify 5030, but .dts does not.


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

Re: [PATCH 13/15] twl4030_charger: add ac/mode to match usb/mode

[Grazvydas Ignotas]

On Tue, Feb 24, 2015 at 6:33 AM, NeilBrown ne...@suse.de wrote:
 This allows AC charging to be turned off, much like usb charging.

 continuous (aka linear) mode maps to the CVENAC (constant voltage)
 feature of the twl4030.

Are you sure? Before your patches CVENAC was set at all times and and
charger still worked in automatic mode.


 Signed-off-by: NeilBrown ne...@suse.de
 ---
  drivers/power/twl4030_charger.c |   40 
 +--
  1 file changed, 30 insertions(+), 10 deletions(-)

 diff --git a/drivers/power/twl4030_charger.c b/drivers/power/twl4030_charger.c
 index 6c53f0b601a4..e5a0225ea87e 100644
 --- a/drivers/power/twl4030_charger.c
 +++ b/drivers/power/twl4030_charger.c
 @@ -112,7 +112,7 @@ struct twl4030_bci {
 int ichg_eoc, ichg_lo, ichg_hi;
 int usb_cur, ac_cur;
 boolac_is_active;
 -   int usb_mode; /* charging mode requested */
 +   int usb_mode, ac_mode; /* charging mode requested 
 */
  #defineCHARGE_OFF  0
  #defineCHARGE_AUTO 1
  #defineCHARGE_LINEAR   2
 @@ -449,12 +449,18 @@ static int twl4030_charger_enable_usb(struct 
 twl4030_bci *bci, bool enable)
  /*
   * Enable/Disable AC Charge funtionality.
   */
 -static int twl4030_charger_enable_ac(bool enable)
 +static int twl4030_charger_enable_ac(struct twl4030_bci *bci, bool enable)
  {
 int ret;

 -   if (enable)
 -   ret = twl4030_clear_set_boot_bci(0, TWL4030_BCIAUTOAC);
 +   if (bci-ac_mode == CHARGE_OFF)
 +   enable = false;
 +
 +   if (enable  bci-ac_mode == CHARGE_LINEAR)
 +   ret = twl4030_clear_set_boot_bci(0, (TWL4030_CVENAC |
 +TWL4030_BCIAUTOAC));
 +   else if (enable)
 +   ret = twl4030_clear_set_boot_bci(TWL4030_CVENAC, 
 TWL4030_BCIAUTOAC);
 else
 ret = twl4030_clear_set_boot_bci(TWL4030_BCIAUTOAC, 0);

CVENAC is required to be set for operation on AC without battery
(which works fine on most pandora boards). After this patch, when
booted without battery,  the board will reset before there is a chance
to set the linear mode by userspace, because this is called on
probe...


Gražvydas
--
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: twl4030_charger: need changes to get probed?

[Grazvydas Ignotas]

On Fri, Mar 6, 2015 at 11:57 PM, Pali Rohár pali.ro...@gmail.com wrote:
 On Friday 06 March 2015 22:24:17 Pavel Machek wrote:
 Hi!

 According to n900 dts, twl4030-bci (aka charger) should be
 included.


 AFAIK it is not present on n900...

Right, it uses twl5030 variant without the charger, charging on n900
is provided by separate chip and for a good reason as twl's charger is
not that good. Forcing the driver to load just ends up with it
accessing non-existent registers over i2c.


Gražvydas
--
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: Enabling DBGEN signal in GP OMAP3

[Grazvydas Ignotas]

On Thu, Feb 26, 2015 at 5:14 AM, Matthijs van Duin
matthijsvand...@gmail.com wrote:
 Thinking of it... unless the control module and relevant GPIO module
 are connected to the same L4 interconnect (which they aren't in my
 test case) I should actually perform at least a dummy read (aka OCP
 barrier) from the control module before accessing GPIO since
 otherwise it's not even guaranteed that all writes to the control
 module have completed. Joy.

 If you want guaranteed reliability, modify tck_pulse() to insert
 aforementioned barrier + an actual delay at all three points where I
 put comments about them.  usleep(50) or so should do the job.

Adding just the barrier works reliably for me, even at 1GHz.

 I guess I'll still connect TDO as it's not so much fun without it,
 going to try connecting to EMU0 too, hopefully it doesn't mess up the
 boot modes.

 Note that you can use *any* gpio. I just used one of the EMU pins
 because the am335x lets you reconfigure those to GPIO and it was
 conveniently nearby.

Same here for me, this allowed to avoid adding a long wire which could
interfere with case parts, etc.
I've already performed the mod (just a solder bridge) and it works fine.

On Thu, Feb 26, 2015 at 6:01 AM, Matthijs van Duin
matthijsvand...@gmail.com wrote:
 On 26 February 2015 at 02:09, Grazvydas Ignotas nota...@gmail.com wrote:

 Anyway I'm attaching my code too

 Ah, if this works then apparently the omap3 control module doesn't
 check privilege.

Yeah, even OMAP5 doesn't do it for me.

 BTW, is this comment in hw-omap3.h true?

 0x23'002100, // assert cortex-a8 DBGEN

 My impression was that bit 13 of DAP's tap control register either
 does nothing or at most enables the DAPCTL registers to be written,
 but that setting bit 13 of the DAP_PC_FER register would still be
 needed to assert DBGEN.

Yes you're right, I've cleared bit 13 and everything works same way as
before, and in all cases additional ap_write() is needed to actually
set DBGEN.


 Also,

 // address of cortex-a8 debug regs on debug APB
 constexpr u32 a8_debug = 0x54011'000;

 If bit 31 isn't set, then these writes should (afaik) be equivalent to
 just performing them directly through the interconnect instead of
 using JTAG.

I don't know about that... To enable DBGEN, I just do:
ap_write( 0x5401d030, 0x2000 );
and it works. Using 0xd401d030 seems to work too.


Thanks again,
Gražvydas
--
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: Enabling DBGEN signal in GP OMAP3

[Grazvydas Ignotas]

On Mon, Feb 23, 2015 at 1:52 PM, Matthijs van Duin
matthijsvand...@gmail.com wrote:
 At least on the am335x, the trick actually works!  I have a working
 demo which configures ICEPick registers and even performs transactions
 on the debug interconnect.

Nice!

 I've been lazy and imported a bunch of files from my baremetal
 projects so I could easily mess with the hardware, rudely bypassing
 the kernel.  The whole implementation is hideous in all sorts of ways,
 but it gets the job done: https://github.com/dutchanddutch/jbang

 The key part, how to bitbang JTAG, is reasonably isolated from all
 this in src/jbang.cc and glues onto the device-specific part via
 hw-subarctic.h.  You could probably also turn jbang.cc into plain C
 without too much effort and discard the rest... I accept that my code
 style is probably a bit of an acquired taste ;-)

 For the omap3, apart from the differences in padconf details, you'll
 want to change icepick_init_regs[] to just { 0x23002100 } I think and
 hopefully you can then write the DAPCTL regs using ap_write().

I've finally got rid of nTRST pulldown (haven't connected TDO though),
created hw-omap3.{h,cc}, but couldn't get it to do anything, until it
came to my mind that you may be running ARM on your BBB slower that
1GHz that I'm using on my DM3730. So lowered the clock to 500MHz and
voila, it worked!

I guess I'll still connect TDO as it's not so much fun without it,
going to try connecting to EMU0 too, hopefully it doesn't mess up the
boot modes.

Before I could get it all to work a coworker lent me an Altera USB
Blaster, which I've connected to a pandora prototype board I still
have from a long time ago and wasn't that afraid to kill with bad
soldering job. And hey, it worked too with your code modified to use
USB Blaster in it's bitbang mode over libftdi. This setup also works
with openocd, but somewhat unreliably (only occasionally gets through
init, often gets register values it doesn't like).

My main goal is to have hardware watchpoints on the cased production
unit without extra hardware, and it looks like I can finally have
that, thanks!

 I hope this example is of any help.

It sure is! The only thing I do not understand is why are you using
that process_vm_readv() call, mmap() already makes unprivileged user
mode writable mappings.

Anyway I'm attaching my code too, feel free to incorporate it too
and/or ultra-modernize to your c++ dialect.

Gražvydas
#include defs.h
#include map-phys.h
#include hw-omap3.h

static u16 *padconf_regs;

//-- JTAG pin i/o //

// JTAG inputs controlled by toggling receiver-enable (pins must be pulled high
// externally or left floating to allow internal pull-up to work).
//
let static sim_input( uint offset, bool level )
{
	padconf_regs[offset  1] = 0x0018 | (level ? 0x0100 : 0x);
}

// JTAG inputs controlled via padconf
let trst( bool level ) - void {  sim_input( 0x0a1c, level );  }
let tck(  bool level ) - void {  sim_input( 0x0a1e, level );  }
let tms(  bool level ) - void {  sim_input( 0x0a20, level );  }
let tdi(  bool level ) - void {  sim_input( 0x0a22, level );  }

// JTAG output (TDO) monitored via gpio
let tdo() - bool {
	return 0;
}

// TDO unavailable
let static tdo_init()
{
}

// RTCK unavailable
let rtck() - bool {  return false;  }

let hw_init() - void
{
	padconf_regs = (u16 *)map_phys( 0x4800'2000, 0x1000 );

	if( has_tdo )
		tdo_init();
}
#pragma once
#include defs.h


let hw_init() - void;


//-- JTAG pin i/o //

// control JTAG inputs
let trst( bool out ) - void;
let tck(  bool out ) - void;
let tms(  bool out ) - void;
let tdi(  bool out ) - void;

// monitor JTAG output
let tdo() - bool;
let rtck() - bool;

let constexpr has_tdo = false;
let constexpr has_rtck = false;


//-- Debug hw config -//

constexpr u32 idcode_mask  = 0x0''fff;
constexpr u32 idcode_match = 0x0'b7ae'02f;

// initialization of icepick registers
constexpr u32 icepick_init_regs[] = {
	0x23'002100,  // assert cortex-a8 DBGEN
};

// address of cortex-a8 debug regs on debug APB
constexpr u32 a8_debug = 0x54011'000;
#include defs.h
#include hw-omap3.h
#include die.h

#include ftdi.h

/* see usb-blaster-protocol.txt */
#define BLASTER_TCK	(1  0)
#define BLASTER_TMS	(1  1)
#define BLASTER_NCE	(1  2)
#define BLASTER_TDI	(1  4)
#define BLASTER_LED	(1  5)
#define BLASTER_READ	(1  6)

static struct ftdi_context ftdic;
static u8 blaster_byte;

//-- JTAG pin i/o //

let static sim_input( u8 mask, bool level )
{
	int ret;

	if (level)
		blaster_byte |= mask;
	else
		blaster_byte = ~mask;

	ret = ftdi_write_data(ftdic, blaster_byte, 1);
	if (ret != 1)
		die(ftdi_write_data %d\n, ret);
}

// JTAG inputs
let trst( bool level ) - void {  sim_input( BLASTER_NCE, level );  }
let tck(  bool level ) - void {  sim_input( 

Re: [PATCH v2 1/3] ARM: dts: omap3-pandora: add common device tree

[Grazvydas Ignotas]

On Tue, Feb 17, 2015 at 9:52 PM, Marek Belisko ma...@goldelico.com wrote:
 From: H. Nikolaus Schaller h...@goldelico.com

 This device tree allows to boot, supports the panel,
 framebuffer, touch screen, as well as some more peripherals.
 Since there is a OMAP3530 based 600 MHz variant and a DM3730 based
 1 GHz variant we must include this common device tree code
 in one of two CPU specific device trees.

 Signed-off-by: H. Nikolaus Schaller h...@goldelico.com
 Signed-off-by: Marek Belisko ma...@goldelico.com
 ---
  arch/arm/boot/dts/omap3-pandora-common.dtsi | 640 
 
  1 file changed, 640 insertions(+)
  create mode 100644 arch/arm/boot/dts/omap3-pandora-common.dtsi

 diff --git a/arch/arm/boot/dts/omap3-pandora-common.dtsi 
 b/arch/arm/boot/dts/omap3-pandora-common.dtsi
 new file mode 100644
 index 000..78ef1ee
 --- /dev/null
 +++ b/arch/arm/boot/dts/omap3-pandora-common.dtsi
 ...
 +
 +   penirq_pins: pinmux_penirq_pins {
 +   pinctrl-single,pins = 
 +   /* here we could enable to wakeup the cpu from 
 suspend by a pen touch */
 +   OMAP3_CORE1_IOPAD(0x210c, MUX_MODE4)/* GPIO_94 */

We need PIN_INPUT here, otherwise the touchscreen doesn't react to pen down.
(Sorry missed it last time).


Gražvydas
--
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 0/3] ARM: dts: add openpandora device support

[Grazvydas Ignotas]

On Tue, Feb 17, 2015 at 9:52 PM, Marek Belisko ma...@goldelico.com wrote:
 changes from v1:
 - add new boards to makefile in patch 2,3 (don't add them
 in separate commit together), fix gpmc issues (reported by Tony Lindgren)

 - fix various issues reported by Grazvydas Ignotas
 (drop internal pullups from pinmux as external are in place,
 fix gpio buttons active state ...)

 This series of patches adds initial device tree support for the
 OpenPandora. The most important parts are working (display, keyboard,
 touch, charging, fuel gauge, musb port, sd/mmc ports, leds, buttons).

All of these have been tested to be working, after adding missing
input flag for touchscreen. Well except musb, but I often have trouble
with that in mainline, probably not a problem with this dts.
Tested-by: Grazvydas Ignotas nota...@gmail.com

And FWIW, the patches have been
Reviewed-by: Grazvydas Ignotas nota...@gmail.com
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Enabling DBGEN signal in GP OMAP3

[Grazvydas Ignotas]

On Wed, Feb 18, 2015 at 5:00 AM, Matthijs van Duin
matthijsvand...@gmail.com wrote:

 030-040 are the core debug control regs... in fact, judging by their
 values and the fact you mentioned bit 13 controls DBGEN, these regs
 look very much like the ICEPick-D core debug control regs, which
 themselves are simplified versions of debug TAP control registers (for
 which you can find the layout in the dm3730 TRM's debug chapter).

 050 and 054 are unknown, but 058 reads 0x2000 which suggests it
 may have an ownership claim command register there. Try writing
 0x4000 to it, if that succeeds and it reads back 0x7000 then
 you're successfully claimed ownership which hopefully means you can
 then write to other regs too, although they may not take effect unless
 you enable the module by writing 0x8000 to the ownership claim
 command register, after which it should read back 0xb000. Of
 course it's also possible it only covers registers 050 and 054,
 whatever they may be... (or it might be something else altogether)

It turns out 050, 054 and 058 (but only them) are actually documented
in dm3730 manual and are part of Emulation Pin Manager. 058 works as
you (and the manual) describe, however claiming and enabling EPM
registers still doesn't enable writing to 030 :(


 RXEN == INPUTENABLE

 At least on the am335x, disabling it causes the processor to perceive
 the input as being low regardless of its actual level. Since the line
 itself doesn't have to change level, this can be toggled pretty fast
 probably. Using this to simulate an input does require the actual line
 level to be high obviously.

OK thanks for all the info. I've tested a spare floating pin by muxing
it as a GPIO on my dm3730 and it works as you describe, nice.
Hopefully this also applies to jtag pins there.

 I could try the bitbang method if you think it can work, although my
 board (openpandora) has a 10K pulldown resistor on nTRST that I'm not
 sure OMAP's internal pullup would win over.

 It won't, you'll need to externally drive it up, e.g. by connecting it
 to the Vref pin that's also on the jtag connector.

 Is there any way to check if anything works from the CPU?
 Maybe I could modify my board, I could connect some spare GPIO pads to
 jtag pads, but I don't know if it's even worth trying.

 If the ownership claim register doesn't work it may be worth a try, if
 you're comfortable doing that. Connecting them to GPIOs will
 definitely work, though just driving the inputs high and toggling
 INPUTENABLE via padconf *may* also work and be simpler.

Ok, sounds like I need to find and get rid of that 10k resistor, or
connect the pad to 1.8V. It's just a shame that there doesn't seem to
be a way to do it purely in software so that other pandora users could
have hardware watchpoints.

If you could share the programming sequence it would be great.

Thanks again,
Gražvydas
--
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: Enabling DBGEN signal in GP OMAP3

[Grazvydas Ignotas]

On Mon, Feb 16, 2015 at 8:43 PM, Matthijs van Duin
matthijsvand...@gmail.com wrote:

 This really sucks since without it you can't use debug monitor
 functionality such as hardware breakpoints and watchpoints, or have an
 aux core (e.g. a cortex-m3) perform halting debug on the main core.
 I've actually considered asking for a hardware patch on our board to
 allow it to self-jtag via gpio just to enable that stupid bit
 (basically everything else is memory-mapped).

I absolutely agree.

 (As a random note, on the am335x the JTAG pins have pinconf registers,
 in that case it may suffice to externally pull/drive all pins up and
 then toggle the RXEN bit in software, given that even the (warm) reset
 pin responds to such manipulation.)

DM3730 (equivalent to OMAP3630) that I'm using also has pinconf
registers on all JTAG pins, and there are external pullups on my
board. So I guess you mean performing I/O by quickly
enabling/disabling the pulldowns? Would that satisfy any timing
requirements? I doubt pinmux register access would be fast from the
CPU (OMAP3 is known not to be a good GPIO bitbanger even).

And what is RXEN bit? I can't find it referenced anywhere (and I'll
admit I don't have experience with hardware debuggers).

On Mon, Feb 16, 2015 at 10:09 PM, Matthijs van Duin
matthijsvand...@gmail.com wrote:
 On 15 February 2015 at 22:30, Grazvydas Ignotas nota...@gmail.com wrote:
 The DBGEM signal on the Cortex-A8 is driven by setting bit 13 at
 address 0x5401 D030 in the DAP-APB address space.

 The register is apparently, for some reason, called DAP_PC_FER
 according to some notes of mine (I have no idea anymore where I got
 these from) listing a few DAPCTL registers:

 //  dap_pc_fer  APB 0xd401d030  ;DAP_PC for Cortex-A8
 //  dap_pc_ime  APB 0xd401d034  ;DAP_PC for IME
 //  dap_pc_ilf  APB 0xd401d038  ;DAP_PC for ILF
 //  dap_pc_vlc  APB 0xd401d03c  ;DAP_PC for VLC
 //  dap_pc_core APB 0xd401d040  ;DAP_PC for Core

Interesting.

 However regardless of how hard I try the writes to that register seem
 to be ignored.

 Just checking... it's possible of course that DAPCTL tries to be
 coresight-compatible and has a lock_access register at 0x5401dfb0 to
 which you need to write 0xc5acces5. To be safe you can first check
 whether 0x5401dfb4 (lock_status) reads 3 before doing so (and it
 should then become 1).

It doesn't seem to be, trying to access these registers (tried reading
and writing) results in data abort..

 Debuggers generally don't need to worry about
 it since access via APB-AP (with bit 31 / MReqDebug set) bypasses such
 locks.

 A dump of all non-zero registers in DAPCTL (the 4KB block at
 0x5401d000) might be interesting.

Attached, fault means external data abort (or at least that's what
Linux kernel calls it).
Note that it was done with Linux kernel running, with chip low power
states enabled and everything.

 It seems others had this problem too, and TI is as helpful as ever:
 http://e2e.ti.com/support/dsp/omap_applications_processors/f/447/p/30011/104527

 (The reply post is weird though, since you don't need DBGEN for
 performance counters, but I'm not gonna bump a thread from 2009)

Yes, the performance counters are working fine already.

 0x5401D030 is referenced by some OpenOCD scripts, so I guess it's
 writeable over jtag, but not by the CPU(s).

 If a write is done to that address as-is (via either AHB-AP or
 APB-AP), rather than an APB-AP write with bit 31 set, then I think you
 should be able to write it from the processor too.  If so, it means
 access is unlocked by some previous step such as my main worry, bit 13
 (DEBUGENABLE) of ICEPick debug tap 3 control.

 You can try writing it from the cortex-a8 while a debugger is
 connected (if using CCS you can connect to DAP without connecting to
 the Cortex-A8, in which case it shouldn't get confused if you mess
 with DBGEN. OpenOCD doesn't support this afaik so it'll probably get
 confused... well so be it)

 If you have an FTDI-based debugger (preferably an XDS100v2) I can
 provide a little test tool to directly manipulate ICEPick registers to
 futher test this theory. (Alternatively, driving nTRST high and
 bit-banging TMS and TDI can do the job too, the sequence isn't very
 long I think)

Unfortunately I don't have any hardware debuggers.
I could try the bitbang method if you think it can work, although my
board (openpandora) has a 10K pulldown resistor on nTRST that I'm not
sure OMAP's internal pullup would win over. Is there any way to check
if anytihng works from the CPU?
Maybe I could modify my board, I could connect some spare GPIO pads to
jtag pads, but I don't know if it's even worth trying.


Gražvydas
5401d000 0010
5401d004 fault
5401d008 fault
5401d00c fault
5401d010 
5401d014 fault
...
5401d02c fault
5401d030 00200026
5401d034 00220002
5401d038 00220002
5401d03c 00220002
5401d040 00200024
5401d044 fault
5401d048 fault
5401d04c

Enabling DBGEN signal in GP OMAP3

[Grazvydas Ignotas]

Hi,

Does anyone know if there is a way to make DBGEN signal high on
OMAP3530 and/or DM3730 without using a hardware debugger? My goal is
to make use of hardware watchpoints in Cortex-A8, but that requires
DBGEN to be high.

The TRM states:
The DBGEM signal on the Cortex-A8 is driven by setting bit 13 at
address 0x5401 D030 in the DAP-APB address space.
However regardless of how hard I try the writes to that register seem
to be ignored. I even tried to do it from IVA/C64x with no success.
(I assume DBGEM is a typo since Cortex-A8 manuals have no mention of
it, and they meant DBGEN there).

It seems others had this problem too, and TI is as helpful as ever:
http://e2e.ti.com/support/dsp/omap_applications_processors/f/447/p/30011/104527

DBGEN is mentioned by Will Deacon's commit
8954bb0da99b76c7ce5edf2f314807cff68b6ea8 , but I guess he mixed NIDEN
with DBGEN there (DBGAUTHSTATUS returns 0x00ae so NIDEN is indeed
set here, and I have tried old kernel where OMAP3_EMU was still
available).

0x5401D030 is referenced by some OpenOCD scripts, so I guess it's
writeable over jtag, but not by the CPU(s). It's quite a mysterious
otherwise undocumented register, I've noticed it's bit21 is some
status bit related to Cortex-A8's low power states.


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

Re: [PATCH 3/4] ARM: dts: omap3-pandora: add DM3730 1 GHz version

[Grazvydas Ignotas]

On Thu, Feb 12, 2015 at 3:03 PM, Marek Belisko ma...@goldelico.com wrote:
 From: H. Nikolaus Schaller h...@goldelico.com

 Signed-off-by: H. Nikolaus Schaller h...@goldelico.com
 ---
  arch/arm/boot/dts/omap3-pandora-1ghz.dts | 65 
 
  1 file changed, 65 insertions(+)
  create mode 100644 arch/arm/boot/dts/omap3-pandora-1ghz.dts

 diff --git a/arch/arm/boot/dts/omap3-pandora-1ghz.dts 
 b/arch/arm/boot/dts/omap3-pandora-1ghz.dts
 new file mode 100644
 index 000..6286f41
 --- /dev/null
 +++ b/arch/arm/boot/dts/omap3-pandora-1ghz.dts
...
 +
 +   control_pins: pinmux_control_pins {
 +   pinctrl-single,pins = 
 +   OMAP3630_CORE2_IOPAD(0x25dc, PIN_INPUT_PULLDOWN | 
 MUX_MODE4)/* etk_d0.gpio_14 =  HP_SHUTDOWN */
 +   OMAP3630_CORE2_IOPAD(0x25de, PIN_OUTPUT | MUX_MODE4)  
   /* etk_d1.gpio_15 =  BT_SHUTDOWN */
 +   OMAP3630_CORE2_IOPAD(0x25e0, PIN_OUTPUT | MUX_MODE4)  
   /* etk_d2.gpio_16 =  RESET_USB_HOST */
 +   OMAP3630_CORE2_IOPAD(0x25ea, PIN_INPUT_PULLUP | 
 MUX_MODE4)  /* etk_d7.gpio_21 =  WIFI IRQ */

The WG7210 document claims that no pulldown/pullup is needed, and we
always had it disabled. The mainline wl1251 driver also reconfigures
that signal to be active high on wl1251 side, and uses rising edge
interrupts (I don't know why it does that).

 +   OMAP3630_CORE2_IOPAD(0x25ec, PIN_OUTPUT | MUX_MODE4)  
   /* etk_d8.gpio_22 =  MSECURE */
 +   OMAP3630_CORE2_IOPAD(0x25ee, PIN_OUTPUT | MUX_MODE4)  
   /* etk_d9.gpio_23 =  WIFI_POWER */

I think we also need these here:
  OMAP3_WKUP_IOPAD(0x2a54, PIN_INPUT | MUX_MODE4)   /*
reserved.gpio_127 = MMC2_WP */
  OMAP3_WKUP_IOPAD(0x2a56, PIN_INPUT | MUX_MODE4)   /*
reserved.gpio_126 = MMC1_WP */
  OMAP3_WKUP_IOPAD(0x2a58, PIN_OUTPUT | MUX_MODE4)   /*
reserved.gpio_128 = LED_MMC1 */
  OMAP3_WKUP_IOPAD(0x2a5a, PIN_OUTPUT | MUX_MODE4)   /*
reserved.gpio_129 = LED_MMC2 */


Gražvydas
--
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] add openpandora device support

[Grazvydas Ignotas]

On Thu, Feb 12, 2015 at 3:03 PM, Marek Belisko ma...@goldelico.com wrote:
 This series of patches adds initial device tree support for the
 OpenPandora. The most important parts are working (display, keyboard,
 touch, charging, fuel gauge, musb port, sd/mmc ports, leds, buttons).
 Not yet supported are: usb host port, nubs, wifi, bluetooth, audio.

 First patch add common dtsi file which is then used in 600mhz and 1ghz
 variants of openpandora which support is added in patches 2 and 3.

Nice, thanks for those patches.
There is also a OMAP3530 variant with 256MB of RAM (otherwise
identical to 512MB OMAP3530) that the legacy board file supports, over
1000 such units were made. Could we also have support for that? I
guess that will make 4 pandora related .dts files...


Gražvydas
--
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] ARM: dts: omap3-pandora: add common device tree

[Grazvydas Ignotas]

On Thu, Feb 12, 2015 at 3:03 PM, Marek Belisko ma...@goldelico.com wrote:
 From: H. Nikolaus Schaller h...@goldelico.com

 This device tree allows to boot, supports the panel,
 framebuffer, touch screen, as well as some more peripherals.
 Since there is a OMAP3530 based 600 MHz variant and a DM3730 based
 1 GHz variant we must include this common device tree code
 in one of two CPU specific device trees.

 Signed-off-by: H. Nikolaus Schaller h...@goldelico.com
 Signed-off-by: Marek Belisko ma...@goldelico.com
 ---
  arch/arm/boot/dts/omap3-pandora-common.dtsi | 641 
 
  1 file changed, 641 insertions(+)
  create mode 100644 arch/arm/boot/dts/omap3-pandora-common.dtsi

 diff --git a/arch/arm/boot/dts/omap3-pandora-common.dtsi 
 b/arch/arm/boot/dts/omap3-pandora-common.dtsi
 new file mode 100644
 index 000..0a2a878
 --- /dev/null
 +++ b/arch/arm/boot/dts/omap3-pandora-common.dtsi
 @@ -0,0 +1,641 @@

...

 +
 +   gpio-leds {
 +
 +   compatible = gpio-leds;
 +
 +   pinctrl-names = default;
 +   pinctrl-0 = led_pins;
 +
 +   led@1 {
 +   label = pandora::sd1;
 +   gpios = gpio5 0 GPIO_ACTIVE_HIGH;/* GPIO_128 */
 +   linux,default-trigger = mmc0;
 +   default-state = off;
 +   };
 +
 +   led@2 {
 +   label = pandora::sd2;
 +   gpios = gpio5 1 GPIO_ACTIVE_HIGH;/* GPIO_129 */
 +   linux,default-trigger = mmc1;
 +   default-state = off;
 +   };
 +
 +   led@3 {
 +   label = pandora::bluetooth;
 +   gpios = gpio5 30 GPIO_ACTIVE_HIGH;   /* GPIO_158 */
 +   linux,default-trigger = heartbeat;

I'd prefer this had no trigger, but no strong feelings here.

 +   default-state = off;
 +   };
 +
 +   led@4 {
 +   label = pandora::wifi;
 +   gpios = gpio5 31 GPIO_ACTIVE_HIGH;   /* GPIO_159 */
 +   linux,default-trigger = mmc2;
 +   default-state = off;
 +   };
 +   };
 +
 +   gpio-keys {
 +   compatible = gpio-keys;
 +
 +   pinctrl-names = default;
 +   pinctrl-0 = button_pins;
 +
 +   up-button {
 +   label = up;
 +   linux,code = KEY_UP;
 +   gpios = gpio4 14 GPIO_ACTIVE_HIGH;   /* GPIO_110 */
 +   gpio-key,wakeup;
 +   };
 +
 +   down-button {
 +   label = down;
 +   linux,code = KEY_DOWN;
 +   gpios = gpio4 7 GPIO_ACTIVE_HIGH;/* GPIO_103 */
 +   gpio-key,wakeup;
 +   };
 +
 +   left-button {
 +   label = left;
 +   linux,code = KEY_LEFT;
 +   gpios = gpio4 0 GPIO_ACTIVE_HIGH;/* GPIO_96 */
 +   gpio-key,wakeup;
 +   };
 +
 +   right-button {
 +   label = right;
 +   linux,code = KEY_RIGHT;
 +   gpios = gpio4 2 GPIO_ACTIVE_HIGH;/* GPIO_98 */
 +   gpio-key,wakeup;
 +   };
 +
 +   pageup-button {
 +   label = game 1;
 +   linux,code = KEY_PAGEUP;
 +   gpios = gpio4 13 GPIO_ACTIVE_HIGH;   /* GPIO_109 */
 +   gpio-key,wakeup;
 +   };
 +
 +   pagedown-button {
 +   label = game 3;
 +   linux,code = KEY_PAGEDOWN;
 +   gpios = gpio4 10 GPIO_ACTIVE_HIGH;   /* GPIO_106 */
 +   gpio-key,wakeup;
 +   };
 +
 +   home-button {
 +   label = game 4;
 +   linux,code = KEY_HOME;
 +   gpios = gpio4 5 GPIO_ACTIVE_HIGH;/* GPIO_101 */
 +   gpio-key,wakeup;
 +   };
 +
 +   end-button {
 +   label = game 2;
 +   linux,code = KEY_END;
 +   gpios = gpio4 15 GPIO_ACTIVE_HIGH;   /* GPIO_111 */
 +   gpio-key,wakeup;
 +   };
 +
 +   right-shift {
 +   label = l;
 +   linux,code = KEY_RIGHTSHIFT;
 +   gpios = gpio4 6 GPIO_ACTIVE_HIGH;/* GPIO_102 */
 +   gpio-key,wakeup;
 +   };
 +
 +   kp-plus {
 +   label = l2;
 +   linux,code = KEY_KPPLUS;
 +   gpios = gpio4 1 GPIO_ACTIVE_HIGH;/* GPIO_97 */
 + 

Re: [PATCH 2/3] hwmon: Driver for OMAP3 temperature sensor

[Grazvydas Ignotas]

On Fri, Dec 26, 2014 at 2:34 PM, Sebastian Reichel s...@kernel.org wrote:
 OMAP34xx and OMAP36xx processors contain a register in the syscon area,
 which can be used to determine the SoCs temperature. This patch provides
 a DT based driver for the temperature sensor based on an older driver
 written by Peter De Schrijver for the Nokia N900 and N9.

The sensor looks like an earlier iteration of sensors used in newer
OMAPs, which are already supported by maybe
drivers/thermal/ti-soc-thermal/ , maybe it would make sense to update
that driver instead?

--
Grazvydas
--
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] arm: dts: omap3-gta04: Add static configuration for devconf1 register

[Grazvydas Ignotas]

On Fri, Nov 14, 2014 at 1:58 AM, Tony Lindgren t...@atomide.com wrote:
 * Paul Walmsley p...@pwsan.com [141113 15:01]:
 Hi

 On Thu, 13 Nov 2014, Tony Lindgren wrote:

  * Tomi Valkeinen tomi.valkei...@ti.com [141113 03:33]:
   On 12/11/14 17:02, Tony Lindgren wrote:
  
And, with a quick grep, I see CONTROL_DEVCONF1 touched in multiple
places in the kernel. I wonder if adding a pinmux entry for it could
cause some rather odd problems.
   
They can all use pinctrl-single no problem.
  
   Can, but don't. That's my worry. If we touch the DEVCONF1 via pinmux,
   and we have code in mach-omap2 that also touch DEVCONF1, without any
   knowledge (and locking) between those...
 
  Hmm yeah the McBSP clock mux could be racy as the mux register for
  McBSP is treated as a clock. This register muxes the clock between
  external pin and internal clock. Considering that this should be
  selectable at board level as the external clock probably needs to be
  used if level shifters are being used, it should be really handled by
  pinctrl-single.
 
  The other use for hsmmc.c and pdata-quirks.c for the one time mux for
  MMC clock from the MMC clock pin. That can be done with pinctrl-single
  from the MMC driver too for DT based booting.
 
  Then we just have the save and restore of the registers for
  off-idle.
 
   So _maybe_ that's not an issue, as the pinmux config we have here is
   fixed, and done once at boot time, and maybe the code in mach-omap2 that
   touch DEVCONF1 is also ran just once and not at the same time as the
   pinmux. But I don't know if that's so.
 
  It seems we could just do a read-only check for McBSP in the clock
  code for the mux register, or even completely drop that code from
  cclock3xxx_data.c and start using the pinctrl for that mux.
 
  Paul  Tero, got any comments here?

 It's best to move all of the SCM register reads/writes to an SCM IP block
 driver.  This driver would be the only entity that would touch the SCM IP
 block registers - no other code on the system would touch it (perhaps
 aside from anything needed for early init).  The SCM driver would enforce
 mutual exclusion via a spinlock, so concurrent SCM register modifications
 wouldn't flake out.  Then the SCM driver would register clocks with the
 CCF, register pins with the pinctrl subsystem, etc. etc.

 We actually do have that with pinctrl-single + syscon. We certainly
 need to implement more Linux framework drivers for the SCM registers.
 Things like regulators, clocks, and PHYs, but they should use
 pinctrl-single + syscon. See the the pbias-regulator.c for example.

 Looking at the McBSP clock handling, threre's yet more handling of
 the same DEVCONF1 mux register in omap2_mcbsp_set_clks_src that gets
 alled from omap_mcbsp_dai_set_dai_sysclk.

 To me it seems that if we handle the DEVCONF with pinctrl-single, we
 don't need most of the McBSP fck code or the omap2_mcbsp_set_clks_src.
 Having the mux register as the clock enable register is not nice..
 Who knows what the clock coming from the external pin might be :)

How will audio do dynamic muxing without that code?
The pin must be remuxed back to internal clock when audio stops, or
else PM breaks.


Gražvydas
--
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

[Grazvydas Ignotas]

On Tue, Nov 4, 2014 at 5:42 PM, Tony Lindgren t...@atomide.com wrote:
 * Igor Grinberg grinb...@compulab.co.il [141104 05:22]:
 Hi Tony,

 On 11/02/14 20:07, 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.

 What about devices that really need to start once VBUS or CHG is connected?

 More handling can be added for some cases. With this patch the
 poweron bits will clear to defaults if power is completely removed.
 So start-up with VBUS and CHG works in that case.

 However, if you have a battery connected, and you poweroff, with
 this patch the device won't power up with VBUS or CHG connected.

 Note that most battery operated devices are not using the charger
 on twl4030 because it has issues charging a completely empty
 battery AFAIK. So most battery powered devices have been using an
 external USB charger chip that's not affected by this patch.

Pandora does, as well as GTA04 AFAIK, but that's not most devices I
guess.. At least pandora was booting up on charger connect up until
now. I don't know why shutdown used to work for Russell in legacy boot
and it changed for DT, the device would always start up when there was
AC power here.


Grazvydas


 We could consider exporting a function for the charger driver to
 configure the poweron mask. And we could also consider passing a
 mask in ti,use_poweroff = 0xff.

 It seems to me that forcing these bits on power off can break that kind of
 devices and these settings should really be board specific.
 What do you think?

 There's a patch series for [RFC,01/16] kernel: Add support for
 poweroff handler call chain that should help with that. For sure
 the poweroff handling needs to be board specific as some systems
 may need to use a GPIO to shut off a regulator powering something
 before powering off the SoC.

 Regards,

 Tony
 --
 To unsubscribe from this list: send the line unsubscribe linux-omap in
 the body of a message to majord...@vger.kernel.org
 More majordomo info at  http://vger.kernel.org/majordomo-info.html
--
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 07/10] ARM: OMAP5 / DRA7: Enable CPU RET on suspend

[Grazvydas Ignotas]

Hi,

On Sat, Sep 6, 2014 at 12:15 AM, Nishanth Menon n...@ti.com wrote:

 Hi,

 Updated patch below:
 Do let me know if this is ok with folks.

 ---8
 From 1b9e11834dac2bd75c396aa7495c806b027653fe Mon Sep 17 00:00:00 2001
 From: Rajendra Nayak rna...@ti.com
 Date: Mon, 27 May 2013 15:46:44 +0530
 Subject: [PATCH V2 7/10] ARM: OMAP5 / DRA7: Enable CPU RET on suspend

 On OMAP5 / DRA7, prevent a CPU powerdomain OFF and resulting MPU OSWR
 and instead attempt a CPU RET and side effect, MPU RET in suspend.

 NOTE: the hardware was originally designed to be capable of achieving
 deep power states such as OFF and OSWR, however due to various issues
 and risks, deepest valid state was determined to be CSWR - hence we use

Would be great to have some more details here..
So there is no hope for OFF mode on OMAP5?


-- 
Gražvydas
--
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] usb: phy: twl4030-usb: Fix lost interrupts after ID pin goes down

[Grazvydas Ignotas]

Hi,

On Thu, Aug 21, 2014 at 7:48 PM, Tony Lindgren t...@atomide.com wrote:
 Commit 249751f22380 (usb: phy: twl4030-usb: poll for ID disconnect)
 added twl4030_id_workaround_work() to deal with lost interrupts
 after ID pin goes down. However, this currently only works for the
 insertion. The PHY interrupts are not working after disconnecting
 an USB-A device from the board, and the deeper idle states for
 omap are blocked as the USB controller stays busy.

 The issue can be solved by calling delayed work from twl4030_usb_irq()
 when ID pin is down and the PHY is not asleep like we already do
 in twl4030_id_workaround_work().

The way it is supposed to work is that after plugging in the cable
twl4030_phy_power_on() sees ID_GROUND and kicks off id_workaround_work
every second. When cable is unplugged, twl4030_id_workaround_work()
sees changes in STS_HW_CONDITIONS register and triggers events.
Doesn't that work for you, why do you need to trigger it from
twl4030_usb_irq() too?

 But as both twl4030_usb_irq() and twl4030_id_workaround_work()
 already do pretty much the same thing, let's call twl4030_usb_irq()
 from twl4030_id_workaround_work() instead of adding some more
 duplicate code.

The difference is the sysfs_notify() call, so now every time
id_workaround_work triggers (around once per second while the cable is
plugged) userspace will now get useless uevent. Haven't actually
checked if it really happens though, so I might be wrong.


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

Re: [PATCH 1/3] mtd: nand: omap: Revert to using software ECC by default

[Grazvydas Ignotas]

On Wed, Aug 6, 2014 at 11:02 AM, Roger Quadros rog...@ti.com wrote:
 Hi Gražvydas,

 On 08/05/2014 07:15 PM, Grazvydas Ignotas wrote:
 On Tue, Aug 5, 2014 at 1:11 PM, Roger Quadros rog...@ti.com wrote:
 For v3.12 and prior, 1-bit Hamming code ECC via software was the
 default choice. Commit c66d039197e4 in v3.13 changed the behaviour
 to use 1-bit Hamming code via Hardware using a different ECC layout
 i.e. (ROM code layout) than what is used by software ECC.

 This ECC layout change causes NAND filesystems created in v3.12
 and prior to be unusable in v3.13 and later. So revert back to
 using software ECC by default if an ECC scheme is not explicitely
 specified.

 This defect can be observed on the following boards during legacy boot

 -omap3beagle
 -omap3touchbook
 -overo
 -am3517crane
 -devkit8000
 -ldp
 -3430sdp

 omap3pandora is also using sw ecc, with ubifs. Some time ago I tried
 booting mainline (I think it was 3.14) with rootfs on NAND, and while
 it did boot and reached a shell, there were lots of ubifs errors, fs
 got corrupted and I lost all my data. I used to be able to boot
 mainline this way fine sometime ~3.8 release. It's interesting that
 3.14 was able to read the data, even with wrong ecc setup.

 This is due to another bug introduced in 3.7 by commit 
 65b97cf6b8deca3ad7a3e00e8316bb89617190fb.
 Because of that bug (i.e. inverted CS_MASK in omap_calculate_ecc), 
 omap_calculate_ecc() always fails with -EINVAL and calculated ECC bytes are 
 always 0. I'll be sending a patch to fix that as well. But that will only 
 affect the cases where OMAP_ECC_HAM1_CODE_HW is used which happened for 
 pandora from 3.13 onwards.


 Do you think it's safe again to boot ubifs created on 3.2 after
 applying this series?


 Yes. If you boot pandora using legacy boot (non DT method), it passes 0 for 
 .ecc_opt in pandora_nand_data. This used to mean 
 OMAP_ECC_HAMMING_CODE_DEFAULT which is software ecc. i.e. NAND_ECC_SOFT with 
 default ECC layout. Until the above mentioned commits changed the meaning. We 
 now call that option OMAP_ECC_HAM1_CODE_SW.

 Please let me know if it works for you. Thanks.

Yes it does, thank you.
Tested-by: Grazvydas Ignotas nota...@gmail.com

Found something new in dmesg though:
[1.542755] nand: device found, Manufacturer ID: 0x2c, Chip ID: 0xbc
[1.549621] nand: Micron MT29F4G16ABBDA3W
[1.553894] nand: 512MiB, SLC, page size: 2048, OOB size: 64
[1.560058] nand: WARNING: omap2-nand.0: the ECC used on your
system is too weak compared to the one required by the NAND chip

Do you think it's best to migrate to different ECC scheme? It would be
better to avoid that so that users can freely change kernels and the
bootloader wouldn't have to be changed..

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

Re: [PATCH 1/3] mtd: nand: omap: Revert to using software ECC by default

[Grazvydas Ignotas]

On Tue, Aug 5, 2014 at 1:11 PM, Roger Quadros rog...@ti.com wrote:
 For v3.12 and prior, 1-bit Hamming code ECC via software was the
 default choice. Commit c66d039197e4 in v3.13 changed the behaviour
 to use 1-bit Hamming code via Hardware using a different ECC layout
 i.e. (ROM code layout) than what is used by software ECC.

 This ECC layout change causes NAND filesystems created in v3.12
 and prior to be unusable in v3.13 and later. So revert back to
 using software ECC by default if an ECC scheme is not explicitely
 specified.

 This defect can be observed on the following boards during legacy boot

 -omap3beagle
 -omap3touchbook
 -overo
 -am3517crane
 -devkit8000
 -ldp
 -3430sdp

omap3pandora is also using sw ecc, with ubifs. Some time ago I tried
booting mainline (I think it was 3.14) with rootfs on NAND, and while
it did boot and reached a shell, there were lots of ubifs errors, fs
got corrupted and I lost all my data. I used to be able to boot
mainline this way fine sometime ~3.8 release. It's interesting that
3.14 was able to read the data, even with wrong ecc setup.

Do you think it's safe again to boot ubifs created on 3.2 after
applying this series?

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

Re: [PATCH V2 2/2] power: twl4030_charger: attempt to power off in case of critical events

[Grazvydas Ignotas]

On Thu, May 29, 2014 at 12:46 AM, Nishanth Menon n...@ti.com wrote:
 Attempt to power off in case of critical events such as battery removal,
 over voltage events.

 There is no guarentee that we'd be in a safe scenario here, but the very
 least we can try to do is to power off the device to prevent damage to
 the system instead of just printing a message and hoping for the best.

At least battery temperature out of range does seem to happen quite
often while charging on hot summer day. I'd prefer my pandora to not
shutdown in such case, it could just stop charging instead.


 NOTE: twl4030 should attempt some form of recovery, but just depending
 on that is never a safe alternative.

 Signed-off-by: Nishanth Menon n...@ti.com
 ---
 new patch. original attempt was: https://patchwork.kernel.org/patch/4002371/

 NOTE: we dont have poweroff support yet enabled on LDP, but it just needs
 relevant dts entry.

  drivers/power/twl4030_charger.c |   26 +-
  1 file changed, 21 insertions(+), 5 deletions(-)

 diff --git a/drivers/power/twl4030_charger.c b/drivers/power/twl4030_charger.c
 index 2598c58..ed0dbd2 100644
 --- a/drivers/power/twl4030_charger.c
 +++ b/drivers/power/twl4030_charger.c
 @@ -22,6 +22,7 @@
  #include linux/power_supply.h
  #include linux/notifier.h
  #include linux/usb/otg.h
 +#include linux/reboot.h
  #include linux/regulator/machine.h

  #define TWL4030_BCIMSTATEC 0x02
 @@ -332,6 +333,7 @@ static irqreturn_t twl4030_bci_interrupt(int irq, void 
 *arg)
 struct twl4030_bci *bci = arg;
 u8 irqs1, irqs2;
 int ret;
 +   bool power_off = false;

 ret = twl_i2c_read_u8(TWL4030_MODULE_INTERRUPTS, irqs1,
   TWL4030_INTERRUPTS_BCIISR1A);
 @@ -352,20 +354,34 @@ static irqreturn_t twl4030_bci_interrupt(int irq, void 
 *arg)
 }

 /* various monitoring events, for now we just log them here */
 -   if (irqs1  (TWL4030_TBATOR2 | TWL4030_TBATOR1))
 +   if (irqs1  (TWL4030_TBATOR2 | TWL4030_TBATOR1)) {
 dev_warn(bci-dev, battery temperature out of range\n);
 +   power_off = true;
 +   }

 -   if (irqs1  TWL4030_BATSTS)
 +   if (irqs1  TWL4030_BATSTS) {
 dev_crit(bci-dev, battery disconnected\n);
 +   power_off = true;
 +   }

 -   if (irqs2  TWL4030_VBATOV)
 +   if (irqs2  TWL4030_VBATOV) {
 dev_crit(bci-dev, VBAT overvoltage\n);
 +   power_off = true;
 +   }

 -   if (irqs2  TWL4030_VBUSOV)
 +   if (irqs2  TWL4030_VBUSOV) {
 dev_crit(bci-dev, VBUS overvoltage\n);
 +   power_off = true;
 +   }

 -   if (irqs2  TWL4030_ACCHGOV)
 +   if (irqs2  TWL4030_ACCHGOV) {
 dev_crit(bci-dev, Ac charger overvoltage\n);
 +   power_off = true;
 +   }
 +
 +   /* Try to shutdown the system */
 +   if (power_off)
 +   orderly_poweroff(true);

 return IRQ_HANDLED;
  }
 --
 1.7.9.5


 ___
 linux-arm-kernel mailing list
 linux-arm-ker...@lists.infradead.org
 http://lists.infradead.org/mailman/listinfo/linux-arm-kernel



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

Re: [PATCH V2 2/2] power: twl4030_charger: attempt to power off in case of critical events

[Grazvydas Ignotas]

On Wed, Jun 4, 2014 at 4:01 PM, Nishanth Menon n...@ti.com wrote:
 On 06/04/2014 05:04 AM, Grazvydas Ignotas wrote:
 On Thu, May 29, 2014 at 12:46 AM, Nishanth Menon n...@ti.com wrote:
 Attempt to power off in case of critical events such as battery removal,
 over voltage events.

 There is no guarentee that we'd be in a safe scenario here, but the very
 least we can try to do is to power off the device to prevent damage to
 the system instead of just printing a message and hoping for the best.

 At least battery temperature out of range does seem to happen quite
 often while charging on hot summer day. I'd prefer my pandora to not
 shutdown in such case, it could just stop charging instead.
 Yeah, We could call
   twl4030_charger_enable_ac(false);
   twl4030_charger_enable_usb(bci, false);

 But then, is that sufficient?
 From the TRM:
 7.5.8 Battery Temperature Out-of-Range Detection
 Battery temperature out-of-range detection detects whether the battery
 temperature is within a specific
 range. Detection is possible for two temperature ranges. When the
 battery temperature is not in the
 2–50°C range or is in the 3–43°C range, the TBATOR1 and TBATOR2 status
 bits rise and an interrupt is
 generated.
 This MADC monitoring function can be enabled by writing to the
 TBATOR1EN (BCIMFEN2[3]) and
 TBATOR2EN (BCIMFEN2[1]) fields.

 Battery pack at high temperature is a risk, no? and it may not be just
 charger that might be causing such a condition. Is'nt it safer to shut
 the device down in such a case?

I don't know, so far nobody has complained about the battery exploding
and anybody getting hurt, but it would make the device unusable for
people in hot climates. From what I remember the automatic charge is
stopped automatically on this condition, as some people complained
they couldn't charge their device and saw these messages in dmesg. I
guess mainline could choose the safer option and shutdown, no strong
opinion about this.

-- 
Gražvydas
--
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 02/11] ARM: OMAP3: Fix idle mode signaling for sys_clkreq and sys_off_mode

[Grazvydas Ignotas]

On Wed, Apr 16, 2014 at 1:56 AM, Tony Lindgren t...@atomide.com wrote:
 * Grazvydas Ignotas nota...@gmail.com [140414 15:51]:
 On Fri, Apr 11, 2014 at 2:47 AM, Tony Lindgren t...@atomide.com wrote:
  @@ -282,6 +283,7 @@ void omap_sram_idle(void)
 
  /* CORE */
  if (core_next_state  PWRDM_POWER_ON) {
  +   omap3_vc_set_pmic_signaling(core_next_state);

 I wonder how is it going to affect latencies, adding stuff to suspend
 path hurts things like NAND transfers, which consist of lots of small
 blocks with an interrupt after each..

 For most part this is the completely idle path, so there should
 not be much of hurry. Most devices should already block the deeper
 idle states for the devices listed in cm_idlest_per, cm_idlest1_core
 and cm_idlest3_core registers. So it should be mostly automatic with
 runtime PM.

 No idea what happens with GPMC though for NAND transfers :) Might
 be worth checking.

What happens there is that the interrupt arrives shortly after the
transfer was issued, but arm_pm_idle() would already be entered and
interrupts disabled, so it then has to go through all those slow
register accesses in omap_sram_idle(), which is just useless work in
such particular case (WFI will just return) and cause interrupt
response latency and loss of throughput. But this is mostly a problem
caused by pwrdm_pre_transition() and pwrdm_post_transition() calls
(they were optimized a bit at one point but later reverted),
core_next_state would probably stay ON and your function wouldn't be
called here, yes.


-- 
Gražvydas
--
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 02/11] ARM: OMAP3: Fix idle mode signaling for sys_clkreq and sys_off_mode

[Grazvydas Ignotas]

On Fri, Apr 11, 2014 at 2:47 AM, Tony Lindgren t...@atomide.com wrote:
 While debugging legacy mode vs device tree booted PM regressions,
 I noticed that omap3 is not toggling sys_clkreq and sys_off_mode
 pins like it should.

 The sys_clkreq and sys_off_mode pins are not toggling because of
 the following issues:

 1. The default polarity for the sys_off_mode pin is wrong.
OFFMODE_POL needs to be cleared for sys_off_mode to go down when
hitting off-idle, while CLKREQ_POL needs to be set so sys_clkreq
goes down when hitting retention.

 2. The values for voltctrl register need to be updated dynamically.
We need to set either the retention idle bits, or off idle bits
in the voltctrl register depending the idle mode we're targeting
to hit.

 Let's fix these two issues as otherwise the system will just
 hang if any twl4030 PMIC idle scripts are loaded. The only case
 where the system does not hang is if only retention idle over I2C4
 is configured by the bootloader.

 Note that even without the twl4030 PMIC scripts, these fixes will
 do the proper signaling of sys_clkreq and sys_off_mode pins, so
 the fixes are needed to fix monitoring of PM states with LEDs or
 an oscilloscope.

 Cc: Kevin Hilman khil...@linaro.org
 Cc: Nishanth Menon n...@ti.com
 Cc: Paul Walmsley p...@pwsan.com
 Cc: Tero Kristo t-kri...@ti.com
 Signed-off-by: Tony Lindgren t...@atomide.com
 ---
  arch/arm/mach-omap2/pm34xx.c   |  2 +
  arch/arm/mach-omap2/prm-regbits-34xx.h | 11 -
  arch/arm/mach-omap2/vc.c   | 75 
 +-
  arch/arm/mach-omap2/vc.h   |  2 +
  4 files changed, 87 insertions(+), 3 deletions(-)

 diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
 index 87099bb..3119ec2 100644
 --- a/arch/arm/mach-omap2/pm34xx.c
 +++ b/arch/arm/mach-omap2/pm34xx.c
 @@ -50,6 +50,7 @@
  #include sdrc.h
  #include sram.h
  #include control.h
 +#include vc.h

  /* pm34xx errata defined in pm.h */
  u16 pm34xx_errata;
 @@ -282,6 +283,7 @@ void omap_sram_idle(void)

 /* CORE */
 if (core_next_state  PWRDM_POWER_ON) {
 +   omap3_vc_set_pmic_signaling(core_next_state);

I wonder how is it going to affect latencies, adding stuff to suspend
path hurts things like NAND transfers, which consist of lots of small
blocks with an interrupt after each..

 if (core_next_state == PWRDM_POWER_OFF) {
 omap3_core_save_context();
 omap3_cm_save_context();
 diff --git a/arch/arm/mach-omap2/prm-regbits-34xx.h 
 b/arch/arm/mach-omap2/prm-regbits-34xx.h
 index cebad56..106132d 100644
 --- a/arch/arm/mach-omap2/prm-regbits-34xx.h
 +++ b/arch/arm/mach-omap2/prm-regbits-34xx.h
 @@ -123,8 +123,15 @@
  #define OMAP3430_GLOBAL_SW_RST_SHIFT   1
  #define OMAP3430_GLOBAL_COLD_RST_SHIFT 0
  #define OMAP3430_GLOBAL_COLD_RST_MASK  (1  0)
 -#define OMAP3430_SEL_OFF_MASK  (1  3)
 -#define OMAP3430_AUTO_OFF_MASK (1  2)
 +#define OMAP3430_PRM_VOLTCTRL_SEL_VMODE(1  4)
 +#define OMAP3430_PRM_VOLTCTRL_SEL_OFF  (1  3)
 +#define OMAP3430_PRM_VOLTCTRL_AUTO_OFF (1  2)
 +#define OMAP3430_PRM_VOLTCTRL_AUTO_RET (1  1)
 +#define OMAP3430_PRM_VOLTCTRL_AUTO_SLEEP   (1  0)
  #define OMAP3430_SETUP_TIME2_MASK  (0x  16)
  #define OMAP3430_SETUP_TIME1_MASK  (0x  0)
 +#define OMAP3430_PRM_POLCTRL_OFFMODE_POL   (1  3)
 +#define OMAP3430_PRM_POLCTRL_CLKOUT_POL(1  2)
 +#define OMAP3430_PRM_POLCTRL_CLKREQ_POL(1  1)
 +#define OMAP3430_PRM_POLCTRL_EXTVOL_POL(1  0)
  #endif
 diff --git a/arch/arm/mach-omap2/vc.c b/arch/arm/mach-omap2/vc.c
 index 49ac797..3d5ba5d 100644
 --- a/arch/arm/mach-omap2/vc.c
 +++ b/arch/arm/mach-omap2/vc.c
 @@ -220,6 +220,78 @@ static inline u32 omap_usec_to_32k(u32 usec)
 return DIV_ROUND_UP_ULL(32768ULL * (u64)usec, 100ULL);
  }

 +void omap3_vc_set_pmic_signaling(int core_next_state)
 +{
 +   u32 voltctrl;
 +
 +   voltctrl = omap2_prm_read_mod_reg(OMAP3430_GR_MOD,
 + OMAP3_PRM_VOLTCTRL_OFFSET);
 +   switch (core_next_state) {
 +   case PWRDM_POWER_OFF:
 +   voltctrl = ~(OMAP3430_PRM_VOLTCTRL_AUTO_RET |
 + OMAP3430_PRM_VOLTCTRL_AUTO_SLEEP);
 +   voltctrl |= OMAP3430_PRM_VOLTCTRL_AUTO_OFF;
 +   break;
 +   case PWRDM_POWER_RET:
 +   voltctrl = ~(OMAP3430_PRM_VOLTCTRL_AUTO_OFF |
 + OMAP3430_PRM_VOLTCTRL_AUTO_SLEEP);
 +   voltctrl |= OMAP3430_PRM_VOLTCTRL_AUTO_RET;
 +   break;
 +   default:
 +   voltctrl = ~(OMAP3430_PRM_VOLTCTRL_AUTO_OFF |
 +

Re: [PATCH V3] usb: musb: Fix unstable init of OTG_INTERFSEL.

[Grazvydas Ignotas]

On Wed, Dec 18, 2013 at 9:41 AM, Andreas Naumann d...@andin.de wrote:
 Am 17.12.2013 18:22, schrieb David Cohen:

 On Tue, Dec 17, 2013 at 05:48:33PM +0100, anaum...@ultratronik.de wrote:

 From: Andreas Naumann anaum...@ultratronik.de

 This is a hard to reproduce problem which leads to non-functional
 USB-OTG port in 0.1%-1% of all boots. Tracked it down to commit
 e25bec160158abe86c276d7d206264afc3646281, which introduces save/restore
 of OTG_INTERFSEL over suspend.
 Since the resume function is also called early in driver init, it uses a
 non-initialized value (which is 0 and a non-supported setting in DM37xx
 for INTERFSEL). Shortly after the correct value is set. Apparently this
 works most time, but not always.

 Fix it by not writing the value on runtime resume if it has not been
 initialized yet.

 Signed-off-by: Andreas Naumann anaum...@ultratronik.de
 ---
 Even though I find the implementation a bit awkward this should fix
 the issue without breaking anything else. Hope everyone is happy
 with this.

   drivers/usb/musb/omap2430.c | 6 +-
   1 file changed, 5 insertions(+), 1 deletion(-)

 diff --git a/drivers/usb/musb/omap2430.c b/drivers/usb/musb/omap2430.c
 index 4315d35..fbe2c08 100644
 --- a/drivers/usb/musb/omap2430.c
 +++ b/drivers/usb/musb/omap2430.c
 @@ -48,6 +48,7 @@ struct omap2430_glue {
 enum omap_musb_vbus_id_status status;
 struct work_struct  omap_musb_mailbox_work;
 struct device   *control_otghs;
 +   u8  initialized;
   };
   #define glue_to_musb(g)   platform_get_drvdata(g-musb)

 @@ -383,6 +384,7 @@ static int omap2430_musb_init(struct musb *musb)
 }

 musb_writel(musb-mregs, OTG_INTERFSEL, l);
 +   glue-initialized = 1;

 pr_debug(HS USB OTG: revision 0x%x, sysconfig 0x%02x, 
 sysstatus 0x%x, intrfsel 0x%x, simenable
 0x%x\n,
 @@ -509,6 +511,7 @@ static int omap2430_probe(struct platform_device
 *pdev)
 glue-dev   = pdev-dev;
 glue-musb  = musb;
 glue-status= OMAP_MUSB_UNKNOWN;
 +   glue-initialized   = 0;


 You don't need to do this. 'glue' was already allocated with kzalloc().


 ok




 if (np) {
 pdata = devm_kzalloc(pdev-dev, sizeof(*pdata),
 GFP_KERNEL);
 @@ -646,7 +649,8 @@ static int omap2430_runtime_resume(struct device
 *dev)

 if (musb) {
 omap2430_low_level_init(musb);
 -   musb_writel(musb-mregs, OTG_INTERFSEL,
 +   if(glue-initialized)


 Are you sure this is thread safe?
 If you're sending this patch it means runtime_resume can be called
 before omap2430_must_init(), but how about at the same time?

No, the problem is that omap2430_runtime_resume() is called _during_
omap2430_must_init(), when pm_runtime_get_sync() is called. We can't
read the initial register value before pm_runtime_get_sync() returns
because the hardware is not powered up, and from pm_runtime_get_sync()
omap2430_runtime_resume() is called, where the cached register value
is needed.

 You defined 'initialized' as u8 type, then read/write operations won't
 be atomic in ARM.

We would only have problems if runtime_suspend() and runtime_resume()
are called at the same time, can this really happed?

Grazvydas
--
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] usb: musb: Fix unstable init of OTG_INTERFSEL.

[Grazvydas Ignotas]

On Wed, Dec 18, 2013 at 5:35 PM, Felipe Balbi ba...@ti.com wrote:
 Hi,

 On Tue, Dec 17, 2013 at 05:48:33PM +0100, anaum...@ultratronik.de wrote:
 From: Andreas Naumann anaum...@ultratronik.de

 This is a hard to reproduce problem which leads to non-functional
 USB-OTG port in 0.1%-1% of all boots. Tracked it down to commit
 e25bec160158abe86c276d7d206264afc3646281, which introduces save/restore
 of OTG_INTERFSEL over suspend.
 Since the resume function is also called early in driver init, it uses a
 non-initialized value (which is 0 and a non-supported setting in DM37xx
 for INTERFSEL). Shortly after the correct value is set. Apparently this
 works most time, but not always.

 yeah, but the problem is not on the glue layer. The bug is omap_device
 and pm_runtime not agreeing on device's state. I suppose there was a fix
 for that recently in linux-omap@vger mailing list.

You mean this: http://marc.info/?t=13844488263r=1w=2 ?

This looks like a different issue during suspend, this problem is at
startup. Both musb_core and omap2430.c expect hardware to be disabled
on startup, and that works as expected. The problem is on first
pm_runtime_get_sync(), which results in first runtime_resume() call,
musb_core checks for first resume and doesn't load yet-unset context
in that case, however glue does and breaks things. We have this
problem since 3.2.


Gražvydas
--
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: WG: [PATCH] usb: musb: omap2430: fix occasional musb breakage on boot

[Grazvydas Ignotas]

On Fri, Dec 13, 2013 at 6:27 PM, Andreas Naumann d...@andin.de wrote:
 On 13.12.2013 13:34, Grazvydas Ignotas wrote:

 Hmm I don't know about that, this would be inconsistent with what all
 other OMAP drivers do. Maybe we should do what musb_core.c does just

 Ok, thats cool.

 to be consistent and add a similar comment. Only the static variable
 could be avoided in favor of struct omap2430_glue member.

 Whats wrong with the static?

Well besides minor memory wastage when the driver is compiled in but
not used, you'd cause problems if TI makes a SoC with multiple musb
instances. Yes this driver already contains global variables, but
still we can avoid adding more easily.

Gražvydas
--
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: WG: [PATCH] usb: musb: omap2430: fix occasional musb breakage on boot

[Grazvydas Ignotas]

On Thu, Dec 12, 2013 at 11:29 PM, Andreas Naumann d...@andin.de wrote:
 Hi Grazvydas,

 Von: Grazvydas Ignotas [mailto:nota...@gmail.com]
 Gesendet: Donnerstag, 12. Dezember 2013 01:21
 An: linux-...@vger.kernel.org
 Cc: Felipe Balbi; linux-omap@vger.kernel.org; Naumann Andreas; Grazvydas
 Ignotas; sta...@vger.kernel.org
 Betreff: [PATCH] usb: musb: omap2430: fix occasional musb breakage on boot


 This is a hard to reproduce problem which leads to non-functional
 USB-OTG port in 0.1%-1% of all boots. Tracked it down to commit
 e25bec160158abe86c omap2+: save and restore OTG_INTERFSEL,
 which introduces save/restore of OTG_INTERFSEL over suspend.

 Since the resume function is also called early in driver init, it uses a
 non-initialized value (which is 0 and a non-supported setting in DM37xx
 for INTERFSEL). Shortly after the correct value is set. Apparently this
 works most time, but not always.

 Fix it by not writing the value on runtime resume if it is 0
 (0 should never be saved in the context as it's invalid value,
 so we use it as an indicator that context hasn't been saved yet).

 This issue was originally found by Andreas Naumann:
 http://marc.info/?l=linux-usbm=138562574719654w=2

 Reported-and-bisected-by: Andreas Naumann anaum...@ultratronik.de
 Signed-off-by: Grazvydas Ignotas nota...@gmail.com
 Cc: sta...@vger.kernel.org
 ---
 This is a regression from 3.2, so should go to -rc and stable, IMO.
 It's really annoying issue if you want to have a stable OTG behavior,
 I've burned quite a lot of time on it myself over a year ago and gave up
 eventually. Good thing Andreas finally found it, many thanks to him!

   drivers/usb/musb/omap2430.c |3 ++-
   1 file changed, 2 insertions(+), 1 deletion(-)

 diff --git a/drivers/usb/musb/omap2430.c b/drivers/usb/musb/omap2430.c
 index 2a408cd..737b3da 100644
 --- a/drivers/usb/musb/omap2430.c
 +++ b/drivers/usb/musb/omap2430.c
 @@ -672,7 +672,8 @@ static int omap2430_runtime_resume(struct device *dev)

 if (musb) {
 omap2430_low_level_init(musb);
 -   musb_writel(musb-mregs, OTG_INTERFSEL,
 +   if (musb-context.otg_interfsel != 0)
 +   musb_writel(musb-mregs, OTG_INTERFSEL,
 musb-context.otg_interfsel);
 phy_power_on(musb-phy);
 }


 Oh, easy way out. I like it but I've also been thinking about your comment
 on my original post, which was that initializing otg_interfsel to the PHYSEL
 bits only might be dangerous because we cant be sure that there are other
 bits in the register.
 However, isnt assuming that 0 is invalid on all OMAPs just as dangerous?

Well I was trying to do a minimal fix so that it could be suitable for
merging to stable kernels. But yes you're right, I've just checked
OMAP4 TRM and 0 is actually valid value there..

 After thinking about my patch again, I would propose to change otg_interfsel
 into otg_physel and read-modify-write only those bits in resume() as you
 suggested in your first answer. That way I could discard the problematic
 first read in probe() while leaving other bits untouched. If you agree I
 post a patch for this tomorrow.

Hmm I don't know about that, this would be inconsistent with what all
other OMAP drivers do. Maybe we should do what musb_core.c does just
to be consistent and add a similar comment. Only the static variable
could be avoided in favor of struct omap2430_glue member.

Gražvydas
--
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] usb: musb: omap2430: fix occasional musb breakage on boot

[Grazvydas Ignotas]

This is a hard to reproduce problem which leads to non-functional
USB-OTG port in 0.1%-1% of all boots. Tracked it down to commit
e25bec160158abe86c omap2+: save and restore OTG_INTERFSEL,
which introduces save/restore of OTG_INTERFSEL over suspend.

Since the resume function is also called early in driver init, it uses a
non-initialized value (which is 0 and a non-supported setting in DM37xx
for INTERFSEL). Shortly after the correct value is set. Apparently this
works most time, but not always.

Fix it by not writing the value on runtime resume if it is 0
(0 should never be saved in the context as it's invalid value,
so we use it as an indicator that context hasn't been saved yet).

This issue was originally found by Andreas Naumann:
http://marc.info/?l=linux-usbm=138562574719654w=2

Reported-and-bisected-by: Andreas Naumann anaum...@ultratronik.de
Signed-off-by: Grazvydas Ignotas nota...@gmail.com
Cc: sta...@vger.kernel.org
---
This is a regression from 3.2, so should go to -rc and stable, IMO.
It's really annoying issue if you want to have a stable OTG behavior,
I've burned quite a lot of time on it myself over a year ago and gave up
eventually. Good thing Andreas finally found it, many thanks to him!

 drivers/usb/musb/omap2430.c |3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/usb/musb/omap2430.c b/drivers/usb/musb/omap2430.c
index 2a408cd..737b3da 100644
--- a/drivers/usb/musb/omap2430.c
+++ b/drivers/usb/musb/omap2430.c
@@ -672,7 +672,8 @@ static int omap2430_runtime_resume(struct device *dev)
 
if (musb) {
omap2430_low_level_init(musb);
-   musb_writel(musb-mregs, OTG_INTERFSEL,
+   if (musb-context.otg_interfsel != 0)
+   musb_writel(musb-mregs, OTG_INTERFSEL,
musb-context.otg_interfsel);
phy_power_on(musb-phy);
}
-- 
1.7.9.5

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

Re: [PATCH V2] usb: musb: Fix unstable init of OTG_INTERFSEL.

[Grazvydas Ignotas]

On Fri, Nov 29, 2013 at 10:34 AM, Andreas Naumann d...@andin.de wrote:
 Nice find, I think I'm also affected by this. However this crashes on
 OMAP3530 pandora because you now access INTERFSEL before interface
 clock is enabled.. This is not a problem on DM37xx because it uses
 different interconnects. You should probably use context_valid
 variable in omap2430_glue or similar to decide to write to register or
 not.

 Grazvydas


 You mean introducing a context_value? I'm not sure if i want to add more
 code.

What I meant is to have a flag that would be set after
omap2430_runtime_suspend() is called, and only write to INTERFSEL in
omap2430_runtime_resume() if that flag is set.

Drivers like drivers/tty/serial/omap-serial.c or
drivers/gpio/gpio-omap.c use get_context_loss_count() callbacks for
this, but it looks unnecessarily complicated.. Maybe Felipe has some
ideas on this?

 Do you think simple removing the first read is an option? So far we read
 back 0 anyway because the first write to INTERFSEL in resume() set it to
 uninitialized / 0 anyway.

It should be fine but I don't know if all OMAPs only have PHY
interface bits, there could be some that have some more bits there..
Yes current code is broken and writes 0 anyway, so any solution is
better, but ideally it should read-modify-write the register and only
change PHYSEL bits at probe.
--
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] usb: musb: Fix unstable init of OTG_INTERFSEL.

[Grazvydas Ignotas]

On Thu, Nov 28, 2013 at 9:51 AM,  anaum...@ultratronik.de wrote:
 From: Andreas Naumann anaum...@ultratronik.de

 This is a hard to reproduce problem which leads to non-functional
 USB-OTG port in 0.1%-1% of all boots. Tracked it down to commit
 e25bec160158abe86c276d7d206264afc3646281, which introduces save/restore
 of OTG_INTERFSEL over suspend.
 Since the resume function is also called early in driver init, it uses a
 non-initialized value (which is 0 and a non-supported setting in DM37xx
 for INTERFSEL). Shortly after the correct value is set. Apparently this
 works most time, but not always.

 The fix is to initialize the value, BEFORE being written in the resume
 function.

Nice find, I think I'm also affected by this. However this crashes on
OMAP3530 pandora because you now access INTERFSEL before interface
clock is enabled.. This is not a problem on DM37xx because it uses
different interconnects. You should probably use context_valid
variable in omap2430_glue or similar to decide to write to register or
not.

Gražvydas
--
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/12 diet] ARM: OMAP2+: Remove legacy omap3 board-*.c files and make mach-omap2 DT only for booting

[Grazvydas Ignotas]

On Tue, Nov 26, 2013 at 3:17 AM, Tony Lindgren t...@atomide.com wrote:
 We can now boot all mach-omap2 related boards using appended device
 tree by creating a related .dts file with pretty much the same
 functionality as booted in the legacy platform data mode.

Not really the same, quite some drivers are still missing, and it
makes pandora unusable :( . For example, SDIO variation of wl1251,
that one is non-probeable and used to be detected by using
MMC_QUIRK_NONSTD_SDIO quirk (see pandora_wl1251_init_card() in
board-omap3pandora.c). Also there are at least pandora-backlight,
twl4030_keypad and panel drivers that are not converted yet.

Can pdata-quirks.c be used for SDIO wl1251 at least, as I have no idea
how to express it using device tree?

--
Gražvydas
--
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] wl1251: spi: add device tree support

[Grazvydas Ignotas]

On Mon, Oct 28, 2013 at 8:37 AM, Kumar Gala ga...@codeaurora.org wrote:
 On Oct 27, 2013, at 11:14 AM, Sebastian Reichel wrote:
  +++ b/Documentation/devicetree/bindings/net/wireless/ti,wl1251.txt
  @@ -0,0 +1,36 @@
  +* Texas Instruments wl1251 controller
  +
  +The wl1251 chip can be connected via SPI or via SDIO. The linux
  +kernel currently only supports device tree for the SPI variant.
  +

 From the binding I have no idea what this chip actually does, also we don't 
 normally reference linux kernel support in bindings specs (so please remove 
 it).

 However, what would expect the SDIO binding to look like?  Or more 
 specifically, how would you distinguish the SPI vs SDIO binding/connection?  
 I'm wondering if the compatible should be something like ti,wl1251-spi and 
 than the sdio can be ti,wl1251-sdio

When connected to SDIO, it doesn't act as standard SDIO device and
can't be probed (standard SDIO registers missing), so information has
to come some other way. That used to partially come through
platform_data and partially through a callback from mmc subsystem (see
pandora_wl1251_init_card() in
arch/arm/mach-omap2/board-omap3pandora.c). I don't know much about DT,
but maybe the information that comes from SDIO registers on normal
SDIO devices should come through DT in this case too? I don't really
know how that should be integrated with mmc subsystem though..

  +Required properties:
  +- compatible : Should be ti,wl1251

 reg is not listed as a required prop.

  +- interrupts : Should contain interrupt line
  +- interrupt-parent : Should be the phandle for the interrupt
  +  controller that services interrupts for this device
  +- vio-supply : phandle to regulator providing VIO
  +- power-gpio : GPIO connected to chip's PMEN pin

 should be vendor prefixed: ti,power-gpio

  +- For additional required properties on SPI, please consult
  +  Documentation/devicetree/bindings/spi/spi-bus.txt
  +
  +Optional properties:
  +- ti,use-eeprom : If found, configuration will be loaded from eeprom.

 can you be a bit more specific on what cfg will be loaded.  Also, is this 
 property a boolean, if so how do I know which eeprom the cfg is loaded from 
 (is it one that is directly connected to the wl1251?

wl1251 is a wifi chip that can have an optional eeprom connected to it
to store things like calibration stuff and MAC address, and that
eeprom is usually inside a single module with some additional radio
related chips. If the eeprom is connected (like the module on pandora
board has), the driver can issue command to the firmware running on
chip to load that data on it's startup, alternatively the driver can
load calibration from other storage (like it happens on N900).


Gražvydas
--
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] wl1251: move power GPIO handling into the driver

[Grazvydas Ignotas]

On Sun, Oct 27, 2013 at 10:12 PM, Sebastian Reichel s...@debian.org wrote:
 On Sun, Oct 27, 2013 at 08:24:16PM +0400, Alexander Shiyan wrote:
  Move the power GPIO handling from the board code into
  the driver. This is a dependency for device tree support.
 
  Signed-off-by: Sebastian Reichel s...@debian.org
  ---
   arch/arm/mach-omap2/board-omap3pandora.c |  2 ++
   arch/arm/mach-omap2/board-rx51-peripherals.c | 11 ++
   drivers/net/wireless/ti/wl1251/sdio.c| 21 +-
   drivers/net/wireless/ti/wl1251/spi.c | 33 
  ++--
   drivers/net/wireless/ti/wl1251/wl1251.h  |  2 +-
   include/linux/wl12xx.h   |  2 +-
   6 files changed, 43 insertions(+), 28 deletions(-)
 ...
  diff --git a/include/linux/wl12xx.h b/include/linux/wl12xx.h
  index b516b4f..a9c723b 100644
  --- a/include/linux/wl12xx.h
  +++ b/include/linux/wl12xx.h
  @@ -49,7 +49,7 @@ enum {
   };
 
   struct wl1251_platform_data {
  -   void (*set_power)(bool enable);
  +   int power_gpio;
  /* SDIO only: IRQ number if WLAN_IRQ line is used, 0 for SDIO IRQs */
  int irq;
  bool use_eeprom;
  --

 What a reason for not using regulator API here with GPIO-based
 regulator?

 I think this pin is not used as power supply, but like an enable pin
 for low power states. Of course the regulator API could still be
 (mis?)used for this, but I think it would be the first linux device
 driver doing this.

 Note: I don't have wl1251 documentation.

When wl12xx family of chips is connected through SDIO, we already have
that pin set up as a regulator controlled with the help of mmc
subsystem. When time comes to communicate with the chip, mmc subsystem
sees this as yet another SD card and looks for associated regulator
for it, and the board file has that set up as a fixed regulator
controlling that pin (see pandora_vmmc3 in
arch/arm/mach-omap2/board-omap3pandora.c). To prevent poweroff after
first SDIO communications are over, pm_runtime calls are used in
drivers/net/wireless/ti/wl1251/sdio.c .

I don't know if something similar can be done done in SPI case, but
I'm sure this is not the first your-so-called regulator misuse.

Gražvydas
--
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 0/9] wilink: add device tree support

[Grazvydas Ignotas]

Hi,

On Tue, Jul 2, 2013 at 5:55 PM, Luciano Coelho coe...@ti.com wrote:
 Hi,

 This is a follow-up on a previous patch set that had a smaller
 audience.  This time, I added the lists and people who were involved
 in the review of the bindings documentation, since most of my changes
 in v2 are coming from discussions there.

 This patch series adds device tree support to the wlcore_sdio driver,
 which is used by WiLink6, WiLink7 and WiLink8.

Could you perhaps consider doing device tree conversion for wl1251
too? With the knowledge you have from working on this series, it would
be much easier for you to do it than for someone else, and I don't
have much hope someone will do it at all. It's WiLink series chip
after all. Without this pandora and N900 are going to lose wifi
support after the switch to dt-only kernel.

I can offer you my help testing things on pandora and I'm sure someone
here could try it on N900.


--
Gražvydas
--
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: Request for OMAPDSS testing

[Grazvydas Ignotas]

Hello,

On Tue, Jun 4, 2013 at 10:40 AM, Tomi Valkeinen tomi.valkei...@ti.com wrote:
 I've made some big changes on the omapdss device model, which involves
 converting all the panel drivers. I've got only a bunch of boards, so I
 hope some of you can perhaps do some minimal tests on some other boards.

Doesn't work on pandora (legacy boardfile boot):

[1.418823] OMAP DSS rev 2.0
[1.447448] omapfb omapfb: no displays
[1.454101] omapfb omapfb: failed to setup omapfb
[1.459106] platform omapfb: Driver omapfb requests probe deferral
...
[2.156860] panel-tpo-td043mtea1 spi1.1: failed to get LCD VCC regulator
[2.164093] spi spi1.1: Driver panel-tpo-td043mtea1 requests probe deferral
...

Needs this small patch:

--- a/arch/arm/mach-omap2/board-omap3pandora.c
+++ b/arch/arm/mach-omap2/board-omap3pandora.c
@@ -335,7 +338,7 @@ static struct regulator_consumer_supply
pandora_vdds_supplies[] = {
 };

 static struct regulator_consumer_supply pandora_vcc_lcd_supply[] = {
-   REGULATOR_SUPPLY(vcc, display0),
+   REGULATOR_SUPPLY(vcc, spi1.1),
 };

 static struct regulator_consumer_supply pandora_usb_phy_supply[] = {

With that it shows Tux and fb console fine, so with above hunk:
Tested-by: Grazvydas Ignotas nota...@gmail.com


--
Gražvydas
--
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: USB ehci suspend/resume on beagleboard

[Grazvydas Ignotas]

On Thu, Apr 4, 2013 at 2:50 PM, Roger Quadros rog...@ti.com wrote:
 correcting misleading subject line.
 was (Re: MUSB regression in linux next at least for pandboard)

 On 04/04/2013 02:36 PM, Roger Quadros wrote:
 Hi,

 On 02/07/2013 04:10 PM, Grazvydas Ignotas wrote:
 On Thu, Feb 7, 2013 at 11:16 AM, Roger Quadros rog...@ti.com wrote:
 snip
 It seems the beagleboard problem is related to OMAP silicon errata [1].
 Apparently, remote wakeup as well as host issued wakeup break omap-ehci 
 and have
 nothing to do with the hub or it's driver.

 I'll work on this issue after I'm done with device tree migration.

 Looking forward to this, mainline has been suffering from this since
 almost forever..



 Unfortunately, there is another errata [2] that makes it impossible to
 support suspend/resume on the beagleboard.

You could fix it for BeagleBoard-xM at least, I think it is not
affected by this as it has DM3730 (only early revisions with 1.0
silicon of that are affected with [2]). This would also fix it for
DM3730-based pandoras.


 cheers,
 -roger

 [2] Advisory 3.1.1.195 HSUSB Interoperability Issue With SMSC USB3320 PHY
 http://www.ti.com/general/docs/lit/getliterature.tsp?literatureNumber=sprz278ffileType=pdf



--
Gražvydas
--
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] Revert OMAP/serial: Fix incorrect Rx FIFO threshold setting, LSR validation on Tx, and Tx FIFO IRQ generation

[Grazvydas Ignotas]

On Thu, Apr 4, 2013 at 12:06 AM, Alexey Pelykh alexey.pel...@gmail.com wrote:

 Is it possible to check behavior on 3.0-3.2 kernels?

We use 3.2 on pandora as production kernel and it doesn't have this
issue that 3.9 had. 3.2 serial PM code is vastly different from what's
in later ones though.


 On Wed, Apr 3, 2013 at 11:57 PM, Paul Walmsley p...@pwsan.com wrote:
 Hi Alexey,

 On Wed, 3 Apr 2013, Alexey Pelykh wrote:

 But, since we've found the issue, I suggest that we should look at it
 closer, especially since at this moment only you can reproduce it.

 Well probably no one else is testing it :-)

 As far as I understand, but I may be wrong, this comment is wrong, since
 if to specify OMAP_UART_SCR_RX_TRIG_GRANU1_MASK, it effectively sets Rx
 threshold to 1 character, instead of 16. /* Set receive FIFO threshold
 to 16 characters and
  * transmit FIFO threshold to 16 spaces
  */

 Again it certainly would not surprise me... that UART IP block seems to be
 poorly understood :-(  Bizarre, I know.

 - Paul

--
Gražvydas
--
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] Revert OMAP/serial: Fix incorrect Rx FIFO threshold setting, LSR validation on Tx, and Tx FIFO IRQ generation

[Grazvydas Ignotas]

Hi,

On Wed, Apr 3, 2013 at 12:19 AM, Alexey Pelykh alexey.pel...@gmail.com wrote:

 But, since we've found the issue, I suggest that we should look at it
 closer, especially since at this moment only you can reproduce it. As

FWIW I was also affected by it, maybe because my console is on UART3
and that is on different power (or was is clock?) domain than UART1.


--
Gražvydas
--
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

[PATCHv3 0/3] usb: phy: remaining twl4030-usb/omap fixes

[Grazvydas Ignotas]

These are the last 3 patches of earlier twl4030-usb/omap fix series:
http://marc.info/?l=linux-usbm=136354462519052w=2

Changed since v2:
- simplified patch 5/7 (now 1/3) according to Felipe's suggestion
- changed vbus_supplied to be always set to true when VBUS_PRES is set,
  even when ID is grounded at the same time (like it was before the patch).

Grazvydas Ignotas (3):
  usb: phy: twl4030-usb: check if vbus is driven by twl itself
  usb: musb: omap2430: turn off vbus on cable disconnect
  usb: musb: gadget: use platform callback to enable vbus

 drivers/usb/musb/musb_gadget.c|5 ++---
 drivers/usb/musb/omap2430.c   |1 +
 drivers/usb/phy/phy-twl4030-usb.c |   31 ---
 3 files changed, 31 insertions(+), 6 deletions(-)

-- 
1.7.9.5

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

[PATCHv3 1/3] usb: phy: twl4030-usb: check if vbus is driven by twl itself

[Grazvydas Ignotas]

At least on pandora, STS_VBUS gets set even when VBUS is driven by twl
itself. Reporting VBUS in this case confuses OMAP musb glue and charger
driver, so check if OTG VBUS charge pump is on before reporting VBUS
event to avoid this problem.

Signed-off-by: Grazvydas Ignotas nota...@gmail.com
---
 drivers/usb/phy/phy-twl4030-usb.c |   31 ---
 1 file changed, 28 insertions(+), 3 deletions(-)

diff --git a/drivers/usb/phy/phy-twl4030-usb.c 
b/drivers/usb/phy/phy-twl4030-usb.c
index 61fe7e2..3f9858f 100644
--- a/drivers/usb/phy/phy-twl4030-usb.c
+++ b/drivers/usb/phy/phy-twl4030-usb.c
@@ -248,6 +248,25 @@ twl4030_usb_clear_bits(struct twl4030_usb *twl, u8 reg, u8 
bits)
 
 /*-*/
 
+static bool twl4030_is_driving_vbus(struct twl4030_usb *twl)
+{
+   int ret;
+
+   ret = twl4030_usb_read(twl, PHY_CLK_CTRL_STS);
+   if (ret  0 || !(ret  PHY_DPLL_CLK))
+   /*
+* if clocks are off, registers are not updated,
+* but we can assume we don't drive VBUS in this case
+*/
+   return false;
+
+   ret = twl4030_usb_read(twl, ULPI_OTG_CTRL);
+   if (ret  0)
+   return false;
+
+   return (ret  (ULPI_OTG_DRVVBUS | ULPI_OTG_CHRGVBUS)) ? true : false;
+}
+
 static enum omap_musb_vbus_id_status
twl4030_usb_linkstat(struct twl4030_usb *twl)
 {
@@ -270,13 +289,19 @@ static enum omap_musb_vbus_id_status
if (status  0)
dev_err(twl-dev, USB link status err %d\n, status);
else if (status  (BIT(7) | BIT(2))) {
-   if (status  (BIT(7)))
-twl-vbus_supplied = true;
+   if (status  BIT(7)) {
+   if (twl4030_is_driving_vbus(twl))
+   status = ~BIT(7);
+   else
+   twl-vbus_supplied = true;
+   }
 
if (status  BIT(2))
linkstat = OMAP_MUSB_ID_GROUND;
-   else
+   else if (status  BIT(7))
linkstat = OMAP_MUSB_VBUS_VALID;
+   else
+   linkstat = OMAP_MUSB_VBUS_OFF;
} else {
if (twl-linkstat != OMAP_MUSB_UNKNOWN)
linkstat = OMAP_MUSB_VBUS_OFF;
-- 
1.7.9.5

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

[PATCHv3 3/3] usb: musb: gadget: use platform callback to enable vbus

[Grazvydas Ignotas]

On some platform configurations (like OMAP3+twl4030) it's the platform
code that enables VBUS, not OTG transceiver, so call vbus platform
callback instead, it will then call the transceiver if needed.

This fixes a use case where USB cable is plugged first and gadget
driver is loaded later after that.

Signed-off-by: Grazvydas Ignotas nota...@gmail.com
---
 drivers/usb/musb/musb_gadget.c |5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/drivers/usb/musb/musb_gadget.c b/drivers/usb/musb/musb_gadget.c
index ff6ba3a..4be4865 100644
--- a/drivers/usb/musb/musb_gadget.c
+++ b/drivers/usb/musb/musb_gadget.c
@@ -1848,9 +1848,8 @@ static int musb_gadget_start(struct usb_gadget *g,
goto err;
}
 
-   if ((musb-xceiv-last_event == USB_EVENT_ID)
-otg-set_vbus)
-   otg_set_vbus(otg, 1);
+   if (musb-xceiv-last_event == USB_EVENT_ID)
+   musb_platform_set_vbus(musb, 1);
 
hcd-self.uses_pio_for_control = 1;
 
-- 
1.7.9.5

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

[PATCHv3 2/3] usb: musb: omap2430: turn off vbus on cable disconnect

[Grazvydas Ignotas]

On USB_EVENT_ID event the musb glue enables VBUS by calling
omap2430_musb_set_vbus(musb, 1) that sets the session bit, but on
USB_EVENT_NONE reverse action is never made, and that breaks PM.

Disable VBUS on USB_EVENT_NONE to be sure musb session is ended
on cable unplug so that PM works.

Signed-off-by: Grazvydas Ignotas nota...@gmail.com
---
 drivers/usb/musb/omap2430.c |1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/usb/musb/omap2430.c b/drivers/usb/musb/omap2430.c
index 798e029..3551f1a 100644
--- a/drivers/usb/musb/omap2430.c
+++ b/drivers/usb/musb/omap2430.c
@@ -291,6 +291,7 @@ static void omap_musb_set_mailbox(struct omap2430_glue 
*glue)
 
musb-xceiv-last_event = USB_EVENT_NONE;
if (musb-gadget_driver) {
+   omap2430_musb_set_vbus(musb, 0);
pm_runtime_mark_last_busy(dev);
pm_runtime_put_autosuspend(dev);
}
-- 
1.7.9.5

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

Re: [PATCHv2 5/7] usb: phy: twl4030-usb: check if vbus is driven by twl itself

[Grazvydas Ignotas]

On Wed, Mar 20, 2013 at 3:07 PM, Felipe Balbi ba...@ti.com wrote:
 On Sun, Mar 17, 2013 at 08:23:25PM +0200, Grazvydas Ignotas wrote:
 At least on pandora, STS_VBUS gets set even when VBUS is driven by twl
 itself. Reporting VBUS in this case confuses OMAP musb glue and charger
 driver, so check if OTG VBUS charge pump is on before reporting VBUS
 event to avoid this problem.

 Signed-off-by: Grazvydas Ignotas nota...@gmail.com
 ---
  drivers/usb/phy/phy-twl4030-usb.c |   36 
 +++-
  1 file changed, 31 insertions(+), 5 deletions(-)

 diff --git a/drivers/usb/phy/phy-twl4030-usb.c 
 b/drivers/usb/phy/phy-twl4030-usb.c
 index 425c18a..87bf11d 100644
 --- a/drivers/usb/phy/phy-twl4030-usb.c
 +++ b/drivers/usb/phy/phy-twl4030-usb.c
 @@ -248,11 +248,31 @@ twl4030_usb_clear_bits(struct twl4030_usb *twl, u8 
 reg, u8 bits)

  
 /*-*/

 +static bool twl4030_is_driving_vbus(struct twl4030_usb *twl)
 +{
 + int ret;
 +
 + ret = twl4030_usb_read(twl, PHY_CLK_CTRL_STS);
 + if (ret  0 || !(ret  PHY_DPLL_CLK))
 + /*
 +  * if clocks are off, registers are not updated,
 +  * but we can assume we don't drive VBUS in this case
 +  */
 + return false;
 +
 + ret = twl4030_usb_read(twl, ULPI_OTG_CTRL);
 + if (ret  0)
 + return false;
 +
 + return (ret  (ULPI_OTG_DRVVBUS | ULPI_OTG_CHRGVBUS)) ? true : false;
 +}
 +
  static enum omap_musb_vbus_id_status
   twl4030_usb_linkstat(struct twl4030_usb *twl)
  {
   int status;
   enum omap_musb_vbus_id_status linkstat = OMAP_MUSB_UNKNOWN;
 + booldriving_vbus = false;

   twl-vbus_supplied = false;

 @@ -270,20 +290,26 @@ static enum omap_musb_vbus_id_status
   if (status  0)
   dev_err(twl-dev, USB link status err %d\n, status);
   else if (status  (BIT(7) | BIT(2))) {
 - if (status  (BIT(7)))
 -twl-vbus_supplied = true;
 + if (status  BIT(7)) {
 + driving_vbus = twl4030_is_driving_vbus(twl);
 + if (driving_vbus)

 how about just:

 if (twl4030_is_driving_vbus(twl))
 status = ~BIT(7);

 

I'm logging driving_vbus below with dev_dbg(), so that it's easier to
see what going on..


 --
 balbi

-- 
Gražvydas
--
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

[PATCHv2 0/7] usb: phy: twl4030-usb fixes

[Grazvydas Ignotas]

I have a pandora board which has similar musb setup to beagleboard
(OMAP3530 + TWL4030) and musb never worked well on it for me in mainline.
Well it usually works if you plug the cable once, but as soon as you start
replugging cables and mixing host adapter into the game it totally breaks
and reboot is then needed. Host mode is especially broken, any replugs
after musb has been in host mode result in dead port that needs reboot
to recover.

With this series I can switch host/peripheral cables any way I like and
even suspend works with cable plugged with musb in peripheral mode!
(ARM: OMAP3: hwmod data: keep MIDLEMODE in force-standby for musb is
needed that was sent separately). This also fixes power drain when cable
is plugged an no gadget driver is loaded.

Changed since v1:
- rebased on Felipe's testing branch
- added locking for patch 4 to take care of possible races
  between work item and IRQ
- changed patch 6 to only disable VBUS if not runtime suspended,
  otherwise we get data abort on OMAP3

Grazvydas Ignotas (7):
  usb: phy: twl4030-usb: don't enable PHY during init
  usb: phy: twl4030-usb: ignore duplicate events
  usb: phy: twl4030-usb: don't switch the phy on/off needlessly
  usb: phy: twl4030-usb: poll for ID disconnect
  usb: phy: twl4030-usb: check if vbus is driven by twl itself
  usb: musb: omap2430: turn off vbus on cable disconnect
  usb: musb: gadget: use platform callback to enable vbus

 drivers/usb/musb/musb_gadget.c|5 +-
 drivers/usb/musb/omap2430.c   |1 +
 drivers/usb/phy/phy-twl4030-usb.c |  123 +
 3 files changed, 99 insertions(+), 30 deletions(-)

-- 
1.7.9.5

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

[PATCHv2 1/7] usb: phy: twl4030-usb: don't enable PHY during init

[Grazvydas Ignotas]

There is no need to do it, otg.set_suspend(false) (which itself
comes from runtime_pm OMAP glue calls) will enable it later anyway.
This used to be the place where things were enabled if booted with
cable connected before runtime_pm conversion, but now can be dropped.

Signed-off-by: Grazvydas Ignotas nota...@gmail.com
---
 drivers/usb/phy/phy-twl4030-usb.c |   20 +---
 1 file changed, 9 insertions(+), 11 deletions(-)

diff --git a/drivers/usb/phy/phy-twl4030-usb.c 
b/drivers/usb/phy/phy-twl4030-usb.c
index a994715..9e47118 100644
--- a/drivers/usb/phy/phy-twl4030-usb.c
+++ b/drivers/usb/phy/phy-twl4030-usb.c
@@ -522,19 +522,17 @@ static void twl4030_usb_phy_init(struct twl4030_usb *twl)
 {
enum omap_musb_vbus_id_status status;
 
-   status = twl4030_usb_linkstat(twl);
-   if (status  0) {
-   if (status == OMAP_MUSB_VBUS_OFF ||
-   status == OMAP_MUSB_ID_FLOAT) {
-   __twl4030_phy_power(twl, 0);
-   twl-asleep = 1;
-   } else {
-   __twl4030_phy_resume(twl);
-   twl-asleep = 0;
-   }
+   /*
+* Start in sleep state, we'll get called through set_suspend()
+* callback when musb is runtime resumed and it's time to start.
+*/
+   __twl4030_phy_power(twl, 0);
+   twl-asleep = 1;
 
+   status = twl4030_usb_linkstat(twl);
+   if (status  0)
omap_musb_mailbox(twl-linkstat);
-   }
+
sysfs_notify(twl-dev-kobj, NULL, vbus);
 }
 
-- 
1.7.9.5

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

[PATCHv2 2/7] usb: phy: twl4030-usb: ignore duplicate events

[Grazvydas Ignotas]

In some rare cases we may get multiple interrupts that will generate
duplicate omap_musb_mailbox() calls. This is a problem because each
VBUS/ID event generates runtime_pm call in OMAP glue code, causing
unbalanced gets or puts and breaking PM.

The same goes for initial state, glue already defaults to no cable
state, so only bother it if we have VBUS or ID.

Signed-off-by: Grazvydas Ignotas nota...@gmail.com
Reviewed-by: Kishon Vijay Abraham I kis...@ti.com
---
 drivers/usb/phy/phy-twl4030-usb.c |5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/usb/phy/phy-twl4030-usb.c 
b/drivers/usb/phy/phy-twl4030-usb.c
index 9e47118..305463b 100644
--- a/drivers/usb/phy/phy-twl4030-usb.c
+++ b/drivers/usb/phy/phy-twl4030-usb.c
@@ -491,9 +491,10 @@ static irqreturn_t twl4030_usb_irq(int irq, void *_twl)
 {
struct twl4030_usb *twl = _twl;
enum omap_musb_vbus_id_status status;
+   enum omap_musb_vbus_id_status status_prev = twl-linkstat;
 
status = twl4030_usb_linkstat(twl);
-   if (status  0) {
+   if (status  0  status != status_prev) {
/* FIXME add a set_power() method so that B-devices can
 * configure the charger appropriately.  It's not always
 * correct to consume VBUS power, and how much current to
@@ -530,7 +531,7 @@ static void twl4030_usb_phy_init(struct twl4030_usb *twl)
twl-asleep = 1;
 
status = twl4030_usb_linkstat(twl);
-   if (status  0)
+   if (status == OMAP_MUSB_ID_GROUND || status == OMAP_MUSB_VBUS_VALID)
omap_musb_mailbox(twl-linkstat);
 
sysfs_notify(twl-dev-kobj, NULL, vbus);
-- 
1.7.9.5

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

[PATCHv2 3/7] usb: phy: twl4030-usb: don't switch the phy on/off needlessly

[Grazvydas Ignotas]

With runtime_pm in place there is no longer need to turn the phy
on/off in OTG layer on cable connect/disconnect, OMAP glue does
this through otg.set_suspend() callback after it's called through
omap_musb_mailbox() on VBUS/ID interrupt. Not doing this will save
power when cable is connected but no gadget driver is loaded.

This will also have side effect of automatic USB charging no longer
working without twl4030_charger driver, because a regulator needed
for charging will no longer be enabled, so be sure to enable charger
driver if charging is needed.

Signed-off-by: Grazvydas Ignotas nota...@gmail.com
---
 drivers/usb/phy/phy-twl4030-usb.c |6 --
 1 file changed, 6 deletions(-)

diff --git a/drivers/usb/phy/phy-twl4030-usb.c 
b/drivers/usb/phy/phy-twl4030-usb.c
index 305463b..b53a2a2 100644
--- a/drivers/usb/phy/phy-twl4030-usb.c
+++ b/drivers/usb/phy/phy-twl4030-usb.c
@@ -506,12 +506,6 @@ static irqreturn_t twl4030_usb_irq(int irq, void *_twl)
 * USB_LINK_VBUS state.  musb_hdrc won't care until it
 * starts to handle softconnect right.
 */
-   if (status == OMAP_MUSB_VBUS_OFF ||
-   status == OMAP_MUSB_ID_FLOAT)
-   twl4030_phy_suspend(twl, 0);
-   else
-   twl4030_phy_resume(twl);
-
omap_musb_mailbox(twl-linkstat);
}
sysfs_notify(twl-dev-kobj, NULL, vbus);
-- 
1.7.9.5

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

[PATCHv2 4/7] usb: phy: twl4030-usb: poll for ID disconnect

[Grazvydas Ignotas]

On pandora, STS_USB interrupt doesn't arrive on USB host cable disconnect
for some reason while VBUS is driven by twl itself, but STS_HW_CONDITIONS
is updated correctly. It does work fine when PHY is powered down though.
To work around that we have to poll.

This patch also moves twl-linkstat update code to callers so that
changes can be handled in thread safe way (as polling work can trigger
at the same time as real irq now).

TI PSP kernels have similar workarounds, so (many?) more boards are likely
affected.

Signed-off-by: Grazvydas Ignotas nota...@gmail.com
---
 drivers/usb/phy/phy-twl4030-usb.c |   64 +
 1 file changed, 57 insertions(+), 7 deletions(-)

diff --git a/drivers/usb/phy/phy-twl4030-usb.c 
b/drivers/usb/phy/phy-twl4030-usb.c
index b53a2a2..425c18a 100644
--- a/drivers/usb/phy/phy-twl4030-usb.c
+++ b/drivers/usb/phy/phy-twl4030-usb.c
@@ -163,6 +163,8 @@ struct twl4030_usb {
boolvbus_supplied;
u8  asleep;
boolirq_enabled;
+
+   struct delayed_work id_workaround_work;
 };
 
 /* internal define on top of container_of */
@@ -287,10 +289,6 @@ static enum omap_musb_vbus_id_status
 * are registered, and that both are active...
 */
 
-   spin_lock_irq(twl-lock);
-   twl-linkstat = linkstat;
-   spin_unlock_irq(twl-lock);
-
return linkstat;
 }
 
@@ -412,6 +410,16 @@ static void twl4030_phy_resume(struct twl4030_usb *twl)
__twl4030_phy_resume(twl);
twl-asleep = 0;
dev_dbg(twl-dev, %s\n, __func__);
+
+   /*
+* XXX When VBUS gets driven after musb goes to A mode,
+* ID_PRES related interrupts no longer arrive, why?
+* Register itself is updated fine though, so we must poll.
+*/
+   if (twl-linkstat == OMAP_MUSB_ID_GROUND) {
+   cancel_delayed_work(twl-id_workaround_work);
+   schedule_delayed_work(twl-id_workaround_work, HZ);
+   }
 }
 
 static int twl4030_usb_ldo_init(struct twl4030_usb *twl)
@@ -491,10 +499,18 @@ static irqreturn_t twl4030_usb_irq(int irq, void *_twl)
 {
struct twl4030_usb *twl = _twl;
enum omap_musb_vbus_id_status status;
-   enum omap_musb_vbus_id_status status_prev = twl-linkstat;
+   bool status_changed = false;
 
status = twl4030_usb_linkstat(twl);
-   if (status  0  status != status_prev) {
+
+   spin_lock_irq(twl-lock);
+   if (status = 0  status != twl-linkstat) {
+   twl-linkstat = status;
+   status_changed = true;
+   }
+   spin_unlock_irq(twl-lock);
+
+   if (status_changed) {
/* FIXME add a set_power() method so that B-devices can
 * configure the charger appropriately.  It's not always
 * correct to consume VBUS power, and how much current to
@@ -506,13 +522,42 @@ static irqreturn_t twl4030_usb_irq(int irq, void *_twl)
 * USB_LINK_VBUS state.  musb_hdrc won't care until it
 * starts to handle softconnect right.
 */
-   omap_musb_mailbox(twl-linkstat);
+   omap_musb_mailbox(status);
}
sysfs_notify(twl-dev-kobj, NULL, vbus);
 
return IRQ_HANDLED;
 }
 
+static void twl4030_id_workaround_work(struct work_struct *work)
+{
+   struct twl4030_usb *twl = container_of(work, struct twl4030_usb,
+   id_workaround_work.work);
+   enum omap_musb_vbus_id_status status;
+   bool status_changed = false;
+
+   status = twl4030_usb_linkstat(twl);
+
+   spin_lock_irq(twl-lock);
+   if (status = 0  status != twl-linkstat) {
+   twl-linkstat = status;
+   status_changed = true;
+   }
+   spin_unlock_irq(twl-lock);
+
+   if (status_changed) {
+   dev_dbg(twl-dev, handle missing status change to %d\n,
+   status);
+   omap_musb_mailbox(status);
+   }
+
+   /* don't schedule during sleep - irq works right then */
+   if (status == OMAP_MUSB_ID_GROUND  !twl-asleep) {
+   cancel_delayed_work(twl-id_workaround_work);
+   schedule_delayed_work(twl-id_workaround_work, HZ);
+   }
+}
+
 static void twl4030_usb_phy_init(struct twl4030_usb *twl)
 {
enum omap_musb_vbus_id_status status;
@@ -525,6 +570,8 @@ static void twl4030_usb_phy_init(struct twl4030_usb *twl)
twl-asleep = 1;
 
status = twl4030_usb_linkstat(twl);
+   twl-linkstat = status;
+
if (status == OMAP_MUSB_ID_GROUND || status == OMAP_MUSB_VBUS_VALID)
omap_musb_mailbox(twl-linkstat);
 
@@ -613,6 +660,8 @@ static int twl4030_usb_probe(struct platform_device *pdev)
/* init spinlock for workqueue */
spin_lock_init(twl-lock);
 
+   INIT_DELAYED_WORK(twl-id_workaround_work, twl4030_id_workaround_work);
+
err = twl4030_usb_ldo_init(twl

[PATCHv2 6/7] usb: musb: omap2430: turn off vbus on cable disconnect

[Grazvydas Ignotas]

On USB_EVENT_ID event the musb glue enables VBUS by calling
omap2430_musb_set_vbus(musb, 1) that sets the session bit, but on
USB_EVENT_NONE reverse action is never made, and that breaks PM.

Disable VBUS on USB_EVENT_NONE to be sure musb session is ended
on cable unplug so that PM works.

Signed-off-by: Grazvydas Ignotas nota...@gmail.com
---
 drivers/usb/musb/omap2430.c |1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/usb/musb/omap2430.c b/drivers/usb/musb/omap2430.c
index ec460ea..780a750 100644
--- a/drivers/usb/musb/omap2430.c
+++ b/drivers/usb/musb/omap2430.c
@@ -291,6 +291,7 @@ static void omap_musb_set_mailbox(struct omap2430_glue 
*glue)
 
musb-xceiv-last_event = USB_EVENT_NONE;
if (musb-gadget_driver) {
+   omap2430_musb_set_vbus(musb, 0);
pm_runtime_mark_last_busy(dev);
pm_runtime_put_autosuspend(dev);
}
-- 
1.7.9.5

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

[PATCHv2 7/7] usb: musb: gadget: use platform callback to enable vbus

[Grazvydas Ignotas]

On some platform configurations (like OMAP3+twl4030) it's the platform
code that enables VBUS, not OTG transceiver, so call vbus platform
callback instead, it will then call the transceiver if needed.

This fixes a use case where USB cable is plugged first and gadget
driver is loaded later after that.

Signed-off-by: Grazvydas Ignotas nota...@gmail.com
---
 drivers/usb/musb/musb_gadget.c |5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/drivers/usb/musb/musb_gadget.c b/drivers/usb/musb/musb_gadget.c
index ae59ee6..60eef20 100644
--- a/drivers/usb/musb/musb_gadget.c
+++ b/drivers/usb/musb/musb_gadget.c
@@ -1799,9 +1799,8 @@ static int musb_gadget_start(struct usb_gadget *g,
goto err;
}
 
-   if ((musb-xceiv-last_event == USB_EVENT_ID)
-otg-set_vbus)
-   otg_set_vbus(otg, 1);
+   if (musb-xceiv-last_event == USB_EVENT_ID)
+   musb_platform_set_vbus(musb, 1);
 
hcd-self.uses_pio_for_control = 1;
 
-- 
1.7.9.5

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

[PATCHv2 5/7] usb: phy: twl4030-usb: check if vbus is driven by twl itself

[Grazvydas Ignotas]

At least on pandora, STS_VBUS gets set even when VBUS is driven by twl
itself. Reporting VBUS in this case confuses OMAP musb glue and charger
driver, so check if OTG VBUS charge pump is on before reporting VBUS
event to avoid this problem.

Signed-off-by: Grazvydas Ignotas nota...@gmail.com
---
 drivers/usb/phy/phy-twl4030-usb.c |   36 +++-
 1 file changed, 31 insertions(+), 5 deletions(-)

diff --git a/drivers/usb/phy/phy-twl4030-usb.c 
b/drivers/usb/phy/phy-twl4030-usb.c
index 425c18a..87bf11d 100644
--- a/drivers/usb/phy/phy-twl4030-usb.c
+++ b/drivers/usb/phy/phy-twl4030-usb.c
@@ -248,11 +248,31 @@ twl4030_usb_clear_bits(struct twl4030_usb *twl, u8 reg, 
u8 bits)
 
 /*-*/
 
+static bool twl4030_is_driving_vbus(struct twl4030_usb *twl)
+{
+   int ret;
+
+   ret = twl4030_usb_read(twl, PHY_CLK_CTRL_STS);
+   if (ret  0 || !(ret  PHY_DPLL_CLK))
+   /*
+* if clocks are off, registers are not updated,
+* but we can assume we don't drive VBUS in this case
+*/
+   return false;
+
+   ret = twl4030_usb_read(twl, ULPI_OTG_CTRL);
+   if (ret  0)
+   return false;
+
+   return (ret  (ULPI_OTG_DRVVBUS | ULPI_OTG_CHRGVBUS)) ? true : false;
+}
+
 static enum omap_musb_vbus_id_status
twl4030_usb_linkstat(struct twl4030_usb *twl)
 {
int status;
enum omap_musb_vbus_id_status linkstat = OMAP_MUSB_UNKNOWN;
+   booldriving_vbus = false;
 
twl-vbus_supplied = false;
 
@@ -270,20 +290,26 @@ static enum omap_musb_vbus_id_status
if (status  0)
dev_err(twl-dev, USB link status err %d\n, status);
else if (status  (BIT(7) | BIT(2))) {
-   if (status  (BIT(7)))
-twl-vbus_supplied = true;
+   if (status  BIT(7)) {
+   driving_vbus = twl4030_is_driving_vbus(twl);
+   if (driving_vbus)
+   status = ~BIT(7);
+   }
 
if (status  BIT(2))
linkstat = OMAP_MUSB_ID_GROUND;
-   else
+   else if (status  BIT(7)) {
linkstat = OMAP_MUSB_VBUS_VALID;
+   twl-vbus_supplied = true;
+   } else
+   linkstat = OMAP_MUSB_VBUS_OFF;
} else {
if (twl-linkstat != OMAP_MUSB_UNKNOWN)
linkstat = OMAP_MUSB_VBUS_OFF;
}
 
-   dev_dbg(twl-dev, HW_CONDITIONS 0x%02x/%d; link %d\n,
-   status, status, linkstat);
+   dev_dbg(twl-dev, HW_CONDITIONS 0x%02x; link %d, driving_vbus %d\n,
+   status, linkstat, driving_vbus);
 
/* REVISIT this assumes host and peripheral controllers
 * are registered, and that both are active...
-- 
1.7.9.5

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

Re: [PATCH v2 2/4] usb: otg: twl4030: use devres API for regulator get and request irq

[Grazvydas Ignotas]

On Thu, Mar 14, 2013 at 5:48 PM, Felipe Balbi ba...@ti.com wrote:
 On Thu, Mar 14, 2013 at 11:53:57AM +0530, Kishon Vijay Abraham I wrote:
 Used devres APIs devm_request_threaded_irq and devm_regulator_get for
 requesting irq and for getting regulator respectively.

 Signed-off-by: Kishon Vijay Abraham I kis...@ti.com

 please refresh this on top of my testing branch, you should be patching
 drivers/usb/phy/phy-twl4030-usb.c

Does that mean I need to rebase my series on your testing branch too?


 --
 balbi

-- 
Gražvydas
--
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/5] usb: musb: omap: always glue have the correct vbus/id status

[Grazvydas Ignotas]

On Wed, Mar 13, 2013 at 10:47 AM, Kishon Vijay Abraham I kis...@ti.com wrote:
 In the case where omap glue is loaded and musb core is not, glue-status
 wont have a valid status if the phy drivers call omap_musb_mailbox. So
 fixed the conditions here.

There already seems to be another patch named usb: musb: omap2430:
fix omap_musb_mailbox glue check again on it's way to mainline that
does mostly the same as first part of this patch.


 Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
 ---
  drivers/usb/musb/omap2430.c |   11 +--
  1 file changed, 5 insertions(+), 6 deletions(-)

 diff --git a/drivers/usb/musb/omap2430.c b/drivers/usb/musb/omap2430.c
 index 78bfc50..28a0220 100644
 --- a/drivers/usb/musb/omap2430.c
 +++ b/drivers/usb/musb/omap2430.c
 @@ -236,13 +236,10 @@ void omap_musb_mailbox(enum omap_musb_vbus_id_status 
 status)
  {
 struct omap2430_glue*glue = _glue;

 -   if (glue  glue_to_musb(glue)) {
 -   glue-status = status;
 -   } else {
 -   pr_err(%s: musb core is not yet ready\n, __func__);
 +   if (!glue)
 return;
 -   }

 +   glue-status = status;
 schedule_work(glue-omap_musb_mailbox_work);
  }
  EXPORT_SYMBOL_GPL(omap_musb_mailbox);
 @@ -307,7 +304,9 @@ static void omap_musb_mailbox_work(struct work_struct 
 *mailbox_work)
  {
 struct omap2430_glue *glue = container_of(mailbox_work,
 struct omap2430_glue, omap_musb_mailbox_work);
 -   omap_musb_set_mailbox(glue);
 +
 +   if (glue_to_musb(glue))
 +   omap_musb_set_mailbox(glue);
  }

  static irqreturn_t omap2430_musb_interrupt(int irq, void *__hci)
 --
 1.7.10.4


-- 
Gražvydas
--
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/7] usb: otg: twl4030-usb: ignore duplicate events

[Grazvydas Ignotas]

On Tue, Mar 12, 2013 at 3:32 PM, kishon kis...@ti.com wrote:
 Hi,


 On Sunday 10 March 2013 06:37 AM, Grazvydas Ignotas wrote:

 In some rare cases we may get multiple interrupts that will generate
 duplicate omap_musb_mailbox() calls. This is a problem because each
 VBUS/ID event generates runtime_pm call in OMAP glue code, causing
 unbalanced gets or puts and breaking PM.


 Did you actually observed multiple interrupts? Actually we thought
 debouncing should be handled in hardware.

I think I saw it a few times, although it might have been something
else. In any case the software check is very cheap and there is no
reason not to have it, IMO.



 The same goes for initial state, glue already defaults to no cable
 state, so only bother it if we have VBUS or ID.

 Signed-off-by: Grazvydas Ignotas nota...@gmail.com

 Reviewed-by: Kishon Vijay Abraham I kis...@ti.com

 Thanks
 Kishon

-- 
Gražvydas
--
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 6/7] usb: musb: omap2430: turn off vbus on cable disconnect

[Grazvydas Ignotas]

On Tue, Mar 12, 2013 at 3:37 PM, kishon kis...@ti.com wrote:
 Hi,


 On Sunday 10 March 2013 06:38 AM, Grazvydas Ignotas wrote:

 On USB_EVENT_ID event the musb glue enables VBUS by calling
 omap2430_musb_set_vbus(musb, 1) that sets the session bit, but on
 USB_EVENT_NONE reverse action is never made, and that breaks PM.

 Disable VBUS unconditionally on USB_EVENT_NONE to be sure musb
 session is ended on cable unplug so that PM works.

 Signed-off-by: Grazvydas Ignotas nota...@gmail.com
 ---
   drivers/usb/musb/omap2430.c |1 +
   1 file changed, 1 insertion(+)

 diff --git a/drivers/usb/musb/omap2430.c b/drivers/usb/musb/omap2430.c
 index 2a39c11..d430677 100644
 --- a/drivers/usb/musb/omap2430.c
 +++ b/drivers/usb/musb/omap2430.c
 @@ -296,6 +296,7 @@ static void omap_musb_set_mailbox(struct omap2430_glue
 *glue)
 pm_runtime_put_autosuspend(dev);
 }

 +   omap2430_musb_set_vbus(musb, 0);
 if (data-interface_type == MUSB_INTERFACE_UTMI) {
 if (musb-xceiv-otg-set_vbus)
 otg_set_vbus(musb-xceiv-otg, 0);

 Shouldn't this otg_set_vbus be done inside omap2430_musb_set_vbus? Any idea
 why they were doing this only for UTMI?

I would think so too, there is otg_set_vbus() in
omap2430_musb_set_vbus() for enable but not for disable.
I don't know history of this code and didn't want to break existing
functionality.


 Thanks
 Kishon



-- 
Gražvydas
--
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: OMAP3: hwmod data: disable MIDLEMODE control for musb

[Grazvydas Ignotas]

On Mon, Mar 11, 2013 at 1:15 AM, Paul Walmsley p...@pwsan.com wrote:
 Hi Gražvydas,

 On Sun, 10 Mar 2013, Grazvydas Ignotas wrote:

 For some unknown reason, allowing hwmod to control MIDLEMODE causes
 core_pwrdm to not hit idle states for musb in DM3730 at least.
 I've verified that setting any MIDLEMODE value other than force
 standby before enabling the device causes subsequent suspend
 attempts to fail with core_pwrdm not entering idle states, even
 if the driver is unloaded and force standby is restored before
 suspend attempt.

 Ugh sounds like a broken bootloader/previous OS could easily block full
 chip idle in this case :-( Does that match your understanding?  That, even
 if the new kernel does everything right in terms of initialization and
 reset, the PRCM's perception of whether the device is in STANDBY is
 permanently stuck?

Soft reset seems to recover from this so there is no problem, but you
can't reset before every suspend so a workaround is still needed..

 Keeping the register set at force standby (reset value) makes it work
 and device still functions properly. musb has driver-controlled
 OTG_FORCESTDBY register that controls MSTANDBY signal, so perhaps
 MIDLEMODE is not even needed? Note that TI PSP kernels also have
 similar workarounds.

 Would like to get your opinion on a different implementation.  For other
 situations where IP blocks don't work in the standard, expected way, we've
 defined hwmod flags for those situations, like HWMOD_SWSUP_*, and
 HWMOD_NO_OCP_AUTOIDLE.  The motivation is to affirmatively mark IP
 blocks that don't work as expected, rather than changing the existing,
 documented hardware bits, which are ideally autogenerated.

 So what do you think about adding a hwmod flag, HWMOD_FORCE_MSTDBY, and
 using that in the hwmod code to program the MSTDBYMODE to FORCE_STANDBY
 and then skipping all other attempts to write to it?

Well as long as it works it's good for me, although it'll bloat the
code a bit compared to just changing the data. Should I attempt an
implementation?


-- 
Gražvydas
--
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] usb: musb: log VBUS error

[Grazvydas Ignotas]

On Mon, Mar 11, 2013 at 6:24 PM, Tony Lindgren t...@atomide.com wrote:
 * Grazvydas Ignotas nota...@gmail.com [130309 16:53]:
 VBUS_ERROR is a serious error that the driver often doesn't recover from
 in my tests, so we should at least inform the user about it.

 Patch makes sens to me, just a related question..

 Do you get this when trying to enable the host mode, right? Or have you seen
 this in other situations too?

I sometimes see it when booting with cable connected to PC or
connecting cable to PC after using a host adapter. In those cases OTG
port dies completely until a powercycle :(

 If the error happens when enabling the host mode, my experience is that
 the VBUS_ERROR is caused by the musb trying to be too smart and doing the
 timeouts automatically. If the VBUS on the hardware does not raise fast
 enough to the right range for whatever reason, musb can produce this
 error.

Yeah the driver seems to expect that and has a ignore variable, I
use KERN_DEBUG level in case it's set.


 Regards,

 Tony


-- 
Gražvydas
--
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: OMAP3: hwmod data: keep MIDLEMODE in force-standby for musb

[Grazvydas Ignotas]

For some unknown reason, allowing hwmod to control MIDLEMODE causes
core_pwrdm to not hit idle states for musb in DM3730 at least.
I've verified that setting any MIDLEMODE value other than force
standby before enabling the device causes subsequent suspend
attempts to fail with core_pwrdm not entering idle states, even
if the driver is unloaded and force standby is restored before
suspend attempt. To recover from this, soft reset can be used, but
that's not suitable solution for suspend.

Keeping the register set at force standby (reset value) makes it work
and device still functions properly, as musb has driver-controlled
OTG_FORCESTDBY register that controls MSTANDBY signal.
Note that TI PSP kernels also have similar workarounds.

This patch also fixes HWMOD_SWSUP_MSTANDBY documentation to match the
actual flag name.

Signed-off-by: Grazvydas Ignotas nota...@gmail.com
---
 arch/arm/mach-omap2/omap_hwmod.c   |7 +--
 arch/arm/mach-omap2/omap_hwmod.h   |9 +++--
 arch/arm/mach-omap2/omap_hwmod_3xxx_data.c |7 ++-
 3 files changed, 18 insertions(+), 5 deletions(-)

diff --git a/arch/arm/mach-omap2/omap_hwmod.c b/arch/arm/mach-omap2/omap_hwmod.c
index c2c798c..a202a47 100644
--- a/arch/arm/mach-omap2/omap_hwmod.c
+++ b/arch/arm/mach-omap2/omap_hwmod.c
@@ -1368,7 +1368,9 @@ static void _enable_sysc(struct omap_hwmod *oh)
}
 
if (sf  SYSC_HAS_MIDLEMODE) {
-   if (oh-flags  HWMOD_SWSUP_MSTANDBY) {
+   if (oh-flags  HWMOD_FORCE_MSTANDBY) {
+   idlemode = HWMOD_IDLEMODE_FORCE;
+   } else if (oh-flags  HWMOD_SWSUP_MSTANDBY) {
idlemode = HWMOD_IDLEMODE_NO;
} else {
if (sf  SYSC_HAS_ENAWAKEUP)
@@ -1440,7 +1442,8 @@ static void _idle_sysc(struct omap_hwmod *oh)
}
 
if (sf  SYSC_HAS_MIDLEMODE) {
-   if (oh-flags  HWMOD_SWSUP_MSTANDBY) {
+   if ((oh-flags  HWMOD_SWSUP_MSTANDBY) ||
+   (oh-flags  HWMOD_FORCE_MSTANDBY)) {
idlemode = HWMOD_IDLEMODE_FORCE;
} else {
if (sf  SYSC_HAS_ENAWAKEUP)
diff --git a/arch/arm/mach-omap2/omap_hwmod.h b/arch/arm/mach-omap2/omap_hwmod.h
index d43d9b6..d5dc935 100644
--- a/arch/arm/mach-omap2/omap_hwmod.h
+++ b/arch/arm/mach-omap2/omap_hwmod.h
@@ -427,8 +427,8 @@ struct omap_hwmod_omap4_prcm {
  *
  * HWMOD_SWSUP_SIDLE: omap_hwmod code should manually bring module in and out
  * of idle, rather than relying on module smart-idle
- * HWMOD_SWSUP_MSTDBY: omap_hwmod code should manually bring module in and out
- * of standby, rather than relying on module smart-standby
+ * HWMOD_SWSUP_MSTANDBY: omap_hwmod code should manually bring module in and
+ * out of standby, rather than relying on module smart-standby
  * HWMOD_INIT_NO_RESET: don't reset this module at boot - important for
  * SDRAM controller, etc. XXX probably belongs outside the main hwmod file
  * XXX Should be HWMOD_SETUP_NO_RESET
@@ -459,6 +459,10 @@ struct omap_hwmod_omap4_prcm {
  * correctly, or this is being abused to deal with some PM latency
  * issues -- but we're currently suffering from a shortage of
  * folks who are able to track these issues down properly.
+ * HWMOD_FORCE_MSTANDBY: Always keep MIDLEMODE bits cleared so that device
+ * is kept in force-standby mode. Failing to do so causes PM problems
+ * with musb on OMAP3630 at least. Note that musb has a dedicated register
+ * to control MSTANDBY signal when MIDLEMODE is set to force-standby.
  */
 #define HWMOD_SWSUP_SIDLE  (1  0)
 #define HWMOD_SWSUP_MSTANDBY   (1  1)
@@ -471,6 +475,7 @@ struct omap_hwmod_omap4_prcm {
 #define HWMOD_16BIT_REG(1  8)
 #define HWMOD_EXT_OPT_MAIN_CLK (1  9)
 #define HWMOD_BLOCK_WFI(1  10)
+#define HWMOD_FORCE_MSTANDBY   (1  11)
 
 /*
  * omap_hwmod._int_flags definitions
diff --git a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c 
b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
index ac7e03e..5112d04 100644
--- a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
@@ -1707,9 +1707,14 @@ static struct omap_hwmod omap3xxx_usbhsotg_hwmod = {
 * Erratum ID: i479  idle_req / idle_ack mechanism potentially
 * broken when autoidle is enabled
 * workaround is to disable the autoidle bit at module level.
+*
+* Enabling the device in any other MIDLEMODE setting but force-idle
+* causes core_pwrdm not enter idle states at least on OMAP3630.
+* Note that musb has OTG_FORCESTDBY register that controls MSTANDBY
+* signal when MIDLEMODE is set to force-idle.
 */
.flags  = HWMOD_NO_OCP_AUTOIDLE | HWMOD_SWSUP_SIDLE
-   | HWMOD_SWSUP_MSTANDBY

Re: [PATCH 4/7] usb: otg: twl4030-usb: poll for ID disconnect

[Grazvydas Ignotas]

On Sun, Mar 10, 2013 at 1:03 PM, Michael Trimarchi
mich...@amarulasolutions.com wrote:
 Hi

 just one comment.

 On 10/03/13 02:07, Grazvydas Ignotas wrote:
 On pandora, STS_USB interrupt doesn't arrive on USB host cable disconnect
 for some reason while VBUS is driven by twl itself, but STS_HW_CONDITIONS
 is updated correctly. It does work fine when PHY is powered down though.
 To work around that we have to poll.

 TI PSP kernels have similar workarounds, so (many?) more boards are likely
 affected.

 Signed-off-by: Grazvydas Ignotas nota...@gmail.com
 ---
  drivers/usb/otg/twl4030-usb.c |   37 +
  1 file changed, 37 insertions(+)

 diff --git a/drivers/usb/otg/twl4030-usb.c b/drivers/usb/otg/twl4030-usb.c
 index 90a19ff..2c1c27e 100644
 --- a/drivers/usb/otg/twl4030-usb.c
 +++ b/drivers/usb/otg/twl4030-usb.c
...
 @@ -513,6 +525,28 @@ static irqreturn_t twl4030_usb_irq(int irq, void *_twl)
   return IRQ_HANDLED;
  }

 +static void twl4030_id_workaround_work(struct work_struct *work)
 +{
 + struct twl4030_usb *twl = container_of(work, struct twl4030_usb,
 + id_workaround_work.work);
 + enum omap_musb_vbus_id_status status_prev = twl-linkstat;
 + enum omap_musb_vbus_id_status status;
 +
 + status = twl4030_usb_linkstat(twl);
 + if (status != status_prev) {
 + dev_dbg(twl-dev, handle missing status change: %d-%d\n,
 + status_prev, status);
 + twl-linkstat = status_prev;
 + twl4030_usb_irq(0, twl);

 As I understand from the subject this happen in Pandora board and
 many boards can be affected.
 do you need any protection between the worker and the irq when
 the irq arrive as expected?

Hmm I guess i do, I'll add some locking in v2, which I'll send after
collecting more feedback.


 Michael



-- 
Gražvydas
--
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: OMAP3: hwmod data: disable MIDLEMODE control for musb

[Grazvydas Ignotas]

For some unknown reason, allowing hwmod to control MIDLEMODE causes
core_pwrdm to not hit idle states for musb in DM3730 at least.
I've verified that setting any MIDLEMODE value other than force
standby before enabling the device causes subsequent suspend
attempts to fail with core_pwrdm not entering idle states, even
if the driver is unloaded and force standby is restored before
suspend attempt.

Keeping the register set at force standby (reset value) makes it work
and device still functions properly. musb has driver-controlled
OTG_FORCESTDBY register that controls MSTANDBY signal, so perhaps
MIDLEMODE is not even needed? Note that TI PSP kernels also have
similar workarounds.

Signed-off-by: Grazvydas Ignotas nota...@gmail.com
---
 arch/arm/mach-omap2/omap_hwmod_3xxx_data.c |   14 +-
 1 file changed, 9 insertions(+), 5 deletions(-)

diff --git a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c 
b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
index ac7e03e..0388bba 100644
--- a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
@@ -1666,11 +1666,15 @@ static struct omap_hwmod_class_sysconfig 
omap3xxx_usbhsotg_sysc = {
.rev_offs   = 0x0400,
.sysc_offs  = 0x0404,
.syss_offs  = 0x0408,
-   .sysc_flags = (SYSC_HAS_SIDLEMODE | SYSC_HAS_MIDLEMODE|
- SYSC_HAS_ENAWAKEUP | SYSC_HAS_SOFTRESET |
- SYSC_HAS_AUTOIDLE),
-   .idlemodes  = (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART |
- MSTANDBY_FORCE | MSTANDBY_NO | MSTANDBY_SMART),
+   /*
+* musb has MMIDLEMODE, but if we ever enable the device not in force
+* idle mode, core_pwrdm does not enter idle states at least on 36xx.
+* Note that musb also has OTG_FORCESTDBY register that the driver
+* uses to control MSTANDBY signal manually.
+*/
+   .sysc_flags = (SYSC_HAS_SIDLEMODE | SYSC_HAS_ENAWAKEUP |
+ SYSC_HAS_SOFTRESET | SYSC_HAS_AUTOIDLE),
+   .idlemodes  = (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART),
.sysc_fields= omap_hwmod_sysc_type1,
 };
 
-- 
1.7.9.5

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

[PATCH] usb: musb: honour initial transceiver state

[Grazvydas Ignotas]

As the OTG transceiver driver usually starts first, it should already
have default_a variable set according to ID pin state, so don't
override it. In case default_a was not changed by trasceiver, it will
default to 0 and this code will work as before.

Signed-off-by: Grazvydas Ignotas nota...@gmail.com
---
 drivers/usb/musb/musb_core.c |   10 +++---
 1 file changed, 7 insertions(+), 3 deletions(-)

diff --git a/drivers/usb/musb/musb_core.c b/drivers/usb/musb/musb_core.c
index 60b41cc..f95404e 100644
--- a/drivers/usb/musb/musb_core.c
+++ b/drivers/usb/musb/musb_core.c
@@ -1955,9 +1955,13 @@ musb_init_controller(struct device *dev, int nIrq, void 
__iomem *ctrl)
musb_write_ulpi_buscontrol(musb-mregs, busctl);
}
 
-   MUSB_DEV_MODE(musb);
-   musb-xceiv-otg-default_a = 0;
-   musb-xceiv-state = OTG_STATE_B_IDLE;
+   if (musb-xceiv-otg-default_a) {
+   MUSB_HST_MODE(musb);
+   musb-xceiv-state = OTG_STATE_A_IDLE;
+   } else {
+   MUSB_DEV_MODE(musb);
+   musb-xceiv-state = OTG_STATE_B_IDLE;
+   }
 
status = musb_gadget_setup(musb);
 
-- 
1.7.9.5

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

[PATCH] usb: musb: gadget: clear gadget_driver when gadget is stopped

[Grazvydas Ignotas]

Some musb glue drivers use gadget_driver pointer to know if any gadget
drivers are loaded at some moment and base further decisions on it,
like to do runtime suspend/resume or not. Right now the pointer is
left alone on stop and OMAP musb glue later does wrong runtime_pm
decisions because of it.

Clear the gadget_driver pointer on remove, it's invalid after stop
anyway.

Signed-off-by: Grazvydas Ignotas nota...@gmail.com
---
 drivers/usb/musb/musb_gadget.c |1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/usb/musb/musb_gadget.c b/drivers/usb/musb/musb_gadget.c
index 19998e9..1ddb889 100644
--- a/drivers/usb/musb/musb_gadget.c
+++ b/drivers/usb/musb/musb_gadget.c
@@ -2057,6 +2057,7 @@ static int musb_gadget_stop(struct usb_gadget *g,
dev_dbg(musb-controller, unregistering driver %s\n, 
driver-function);
 
musb-is_active = 0;
+   musb-gadget_driver = NULL;
musb_platform_try_idle(musb, 0);
spin_unlock_irqrestore(musb-lock, flags);
 
-- 
1.7.9.5

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

[PATCH] usb: musb: log VBUS error

[Grazvydas Ignotas]

VBUS_ERROR is a serious error that the driver often doesn't recover from
in my tests, so we should at least inform the user about it.

Signed-off-by: Grazvydas Ignotas nota...@gmail.com
---
 drivers/usb/musb/musb_core.c |3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/usb/musb/musb_core.c b/drivers/usb/musb/musb_core.c
index f95404e..df6a54e 100644
--- a/drivers/usb/musb/musb_core.c
+++ b/drivers/usb/musb/musb_core.c
@@ -602,7 +602,8 @@ static irqreturn_t musb_stage0_irq(struct musb *musb, u8 
int_usb,
break;
}
 
-   dev_dbg(musb-controller, VBUS_ERROR in %s (%02x, %s), retry 
#%d, port1 %08x\n,
+   dev_printk(ignore ? KERN_DEBUG : KERN_ERR, musb-controller,
+  VBUS_ERROR in %s (%02x, %s), retry #%d, port1 
%08x\n,
otg_state_string(musb-xceiv-state),
devctl,
({ char *s;
-- 
1.7.9.5

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

[PATCH 0/7] usb: otg: twl4030-usb fixes

[Grazvydas Ignotas]

I have a pandora board which has similar musb setup to beagleboard
(OMAP3530 + TWL4030) and musb never worked well on it for me in mainline.
Well it usually works if you plug the cable once, but as soon as you start
replugging cables and mixing host adapter into the game it totally breaks
and reboot is then needed. Host mode is especially broken, any replugs
after musb has been in host mode result in dead port that needs reboot
to recover.

With this series I can switch host/peripheral cables any way I like and
even suspend works with cable plugged with musb in peripheral mode!
(ARM: OMAP3: hwmod data: disable MIDLEMODE control for musb is needed
that was sent separately). This also fixes power drain when cable is
plugged an no gadget driver is loaded.

Grazvydas Ignotas (7):
  usb: otg: twl4030-usb: don't enable PHY during init
  usb: otg: twl4030-usb: ignore duplicate events
  usb: otg: twl4030-usb: don't switch the phy on/off needlessly
  usb: otg: twl4030-usb: poll for ID disconnect
  usb: otg: twl4030-usb: check if vbus is driven by twl itself
  usb: musb: omap2430: turn off vbus on cable disconnect
  usb: musb: gadget: use platform callback to enable vbus

 drivers/usb/musb/musb_gadget.c |5 +-
 drivers/usb/musb/omap2430.c|1 +
 drivers/usb/otg/twl4030-usb.c  |  105 ++--
 3 files changed, 82 insertions(+), 29 deletions(-)

-- 
1.7.9.5

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

[PATCH 2/7] usb: otg: twl4030-usb: ignore duplicate events

[Grazvydas Ignotas]

In some rare cases we may get multiple interrupts that will generate
duplicate omap_musb_mailbox() calls. This is a problem because each
VBUS/ID event generates runtime_pm call in OMAP glue code, causing
unbalanced gets or puts and breaking PM.

The same goes for initial state, glue already defaults to no cable
state, so only bother it if we have VBUS or ID.

Signed-off-by: Grazvydas Ignotas nota...@gmail.com
---
 drivers/usb/otg/twl4030-usb.c |5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/usb/otg/twl4030-usb.c b/drivers/usb/otg/twl4030-usb.c
index 1515c0b..0ea576a 100644
--- a/drivers/usb/otg/twl4030-usb.c
+++ b/drivers/usb/otg/twl4030-usb.c
@@ -491,9 +491,10 @@ static irqreturn_t twl4030_usb_irq(int irq, void *_twl)
 {
struct twl4030_usb *twl = _twl;
enum omap_musb_vbus_id_status status;
+   enum omap_musb_vbus_id_status status_prev = twl-linkstat;
 
status = twl4030_usb_linkstat(twl);
-   if (status  0) {
+   if (status  0  status != status_prev) {
/* FIXME add a set_power() method so that B-devices can
 * configure the charger appropriately.  It's not always
 * correct to consume VBUS power, and how much current to
@@ -530,7 +531,7 @@ static void twl4030_usb_phy_init(struct twl4030_usb *twl)
twl-asleep = 1;
 
status = twl4030_usb_linkstat(twl);
-   if (status  0)
+   if (status == OMAP_MUSB_ID_GROUND || status == OMAP_MUSB_VBUS_VALID)
omap_musb_mailbox(twl-linkstat);
 
sysfs_notify(twl-dev-kobj, NULL, vbus);
-- 
1.7.9.5

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

[PATCH 3/7] usb: otg: twl4030-usb: don't switch the phy on/off needlessly

[Grazvydas Ignotas]

With runtime_pm in place there is no longer need to turn the phy
on/off in OTG layer on cable connect/disconnect, OMAP glue does
this through otg.set_suspend() callback after it's called through
omap_musb_mailbox() on VBUS/ID interrupt. Not doing this will save
power when cable is connected but no gadget driver is loaded.

This will also have side effect of automatic USB charging no longer
working without twl4030_charger driver, so be sure to enable it if
charging is needed.

Signed-off-by: Grazvydas Ignotas nota...@gmail.com
---
 drivers/usb/otg/twl4030-usb.c |6 --
 1 file changed, 6 deletions(-)

diff --git a/drivers/usb/otg/twl4030-usb.c b/drivers/usb/otg/twl4030-usb.c
index 0ea576a..90a19ff 100644
--- a/drivers/usb/otg/twl4030-usb.c
+++ b/drivers/usb/otg/twl4030-usb.c
@@ -506,12 +506,6 @@ static irqreturn_t twl4030_usb_irq(int irq, void *_twl)
 * USB_LINK_VBUS state.  musb_hdrc won't care until it
 * starts to handle softconnect right.
 */
-   if (status == OMAP_MUSB_VBUS_OFF ||
-   status == OMAP_MUSB_ID_FLOAT)
-   twl4030_phy_suspend(twl, 0);
-   else
-   twl4030_phy_resume(twl);
-
omap_musb_mailbox(twl-linkstat);
}
sysfs_notify(twl-dev-kobj, NULL, vbus);
-- 
1.7.9.5

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

[PATCH 5/7] usb: otg: twl4030-usb: check if vbus is driven by twl itself

[Grazvydas Ignotas]

At least on pandora, STS_VBUS gets set even when VBUS is driven by twl
itself. Reporting VBUS in this case confuses OMAP musb glue and charger
driver, so check if OTG VBUS charge pump is on before reporting VBUS
event to avoid this problem.

Signed-off-by: Grazvydas Ignotas nota...@gmail.com
---
 drivers/usb/otg/twl4030-usb.c |   36 +++-
 1 file changed, 31 insertions(+), 5 deletions(-)

diff --git a/drivers/usb/otg/twl4030-usb.c b/drivers/usb/otg/twl4030-usb.c
index 2c1c27e..8f0d6cf 100644
--- a/drivers/usb/otg/twl4030-usb.c
+++ b/drivers/usb/otg/twl4030-usb.c
@@ -248,11 +248,31 @@ twl4030_usb_clear_bits(struct twl4030_usb *twl, u8 reg, 
u8 bits)
 
 /*-*/
 
+static bool twl4030_is_driving_vbus(struct twl4030_usb *twl)
+{
+   int ret;
+
+   ret = twl4030_usb_read(twl, PHY_CLK_CTRL_STS);
+   if (ret  0 || !(ret  PHY_DPLL_CLK))
+   /*
+* if clocks are off, registers are not updated,
+* but we can assume we don't drive VBUS in this case
+*/
+   return false;
+
+   ret = twl4030_usb_read(twl, ULPI_OTG_CTRL);
+   if (ret  0)
+   return false;
+
+   return (ret  (ULPI_OTG_DRVVBUS | ULPI_OTG_CHRGVBUS)) ? true : false;
+}
+
 static enum omap_musb_vbus_id_status
twl4030_usb_linkstat(struct twl4030_usb *twl)
 {
int status;
enum omap_musb_vbus_id_status linkstat = OMAP_MUSB_UNKNOWN;
+   booldriving_vbus = false;
 
twl-vbus_supplied = false;
 
@@ -270,20 +290,26 @@ static enum omap_musb_vbus_id_status
if (status  0)
dev_err(twl-dev, USB link status err %d\n, status);
else if (status  (BIT(7) | BIT(2))) {
-   if (status  (BIT(7)))
-twl-vbus_supplied = true;
+   if (status  BIT(7)) {
+   driving_vbus = twl4030_is_driving_vbus(twl);
+   if (driving_vbus)
+   status = ~BIT(7);
+   }
 
if (status  BIT(2))
linkstat = OMAP_MUSB_ID_GROUND;
-   else
+   else if (status  BIT(7)) {
linkstat = OMAP_MUSB_VBUS_VALID;
+   twl-vbus_supplied = true;
+   } else
+   linkstat = OMAP_MUSB_VBUS_OFF;
} else {
if (twl-linkstat != OMAP_MUSB_UNKNOWN)
linkstat = OMAP_MUSB_VBUS_OFF;
}
 
-   dev_dbg(twl-dev, HW_CONDITIONS 0x%02x/%d; link %d\n,
-   status, status, linkstat);
+   dev_dbg(twl-dev, HW_CONDITIONS 0x%02x; link %d, driving_vbus %d\n,
+   status, linkstat, driving_vbus);
 
/* REVISIT this assumes host and peripheral controllers
 * are registered, and that both are active...
-- 
1.7.9.5

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

[PATCH 4/7] usb: otg: twl4030-usb: poll for ID disconnect

[Grazvydas Ignotas]

On pandora, STS_USB interrupt doesn't arrive on USB host cable disconnect
for some reason while VBUS is driven by twl itself, but STS_HW_CONDITIONS
is updated correctly. It does work fine when PHY is powered down though.
To work around that we have to poll.

TI PSP kernels have similar workarounds, so (many?) more boards are likely
affected.

Signed-off-by: Grazvydas Ignotas nota...@gmail.com
---
 drivers/usb/otg/twl4030-usb.c |   37 +
 1 file changed, 37 insertions(+)

diff --git a/drivers/usb/otg/twl4030-usb.c b/drivers/usb/otg/twl4030-usb.c
index 90a19ff..2c1c27e 100644
--- a/drivers/usb/otg/twl4030-usb.c
+++ b/drivers/usb/otg/twl4030-usb.c
@@ -163,6 +163,8 @@ struct twl4030_usb {
boolvbus_supplied;
u8  asleep;
boolirq_enabled;
+
+   struct delayed_work id_workaround_work;
 };
 
 /* internal define on top of container_of */
@@ -412,6 +414,16 @@ static void twl4030_phy_resume(struct twl4030_usb *twl)
__twl4030_phy_resume(twl);
twl-asleep = 0;
dev_dbg(twl-dev, %s\n, __func__);
+
+   /*
+* XXX When VBUS gets driven after musb goes to A mode,
+* ID_PRES related interrupts no longer arrive, why?
+* Register itself is updated fine though, so we must poll.
+*/
+   if (twl-linkstat == OMAP_MUSB_ID_GROUND) {
+   cancel_delayed_work(twl-id_workaround_work);
+   schedule_delayed_work(twl-id_workaround_work, HZ);
+   }
 }
 
 static int twl4030_usb_ldo_init(struct twl4030_usb *twl)
@@ -513,6 +525,28 @@ static irqreturn_t twl4030_usb_irq(int irq, void *_twl)
return IRQ_HANDLED;
 }
 
+static void twl4030_id_workaround_work(struct work_struct *work)
+{
+   struct twl4030_usb *twl = container_of(work, struct twl4030_usb,
+   id_workaround_work.work);
+   enum omap_musb_vbus_id_status status_prev = twl-linkstat;
+   enum omap_musb_vbus_id_status status;
+
+   status = twl4030_usb_linkstat(twl);
+   if (status != status_prev) {
+   dev_dbg(twl-dev, handle missing status change: %d-%d\n,
+   status_prev, status);
+   twl-linkstat = status_prev;
+   twl4030_usb_irq(0, twl);
+   }
+
+   /* don't schedule during sleep - irq works right then */
+   if (status == OMAP_MUSB_ID_GROUND  !twl-asleep) {
+   cancel_delayed_work(twl-id_workaround_work);
+   schedule_delayed_work(twl-id_workaround_work, HZ);
+   }
+}
+
 static void twl4030_usb_phy_init(struct twl4030_usb *twl)
 {
enum omap_musb_vbus_id_status status;
@@ -613,6 +647,8 @@ static int twl4030_usb_probe(struct platform_device *pdev)
/* init spinlock for workqueue */
spin_lock_init(twl-lock);
 
+   INIT_DELAYED_WORK(twl-id_workaround_work, twl4030_id_workaround_work);
+
err = twl4030_usb_ldo_init(twl);
if (err) {
dev_err(pdev-dev, ldo init failed\n);
@@ -653,6 +689,7 @@ static int __exit twl4030_usb_remove(struct platform_device 
*pdev)
struct twl4030_usb *twl = platform_get_drvdata(pdev);
int val;
 
+   cancel_delayed_work(twl-id_workaround_work);
free_irq(twl-irq, twl);
device_remove_file(twl-dev, dev_attr_vbus);
 
-- 
1.7.9.5

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

[PATCH 6/7] usb: musb: omap2430: turn off vbus on cable disconnect

[Grazvydas Ignotas]

On USB_EVENT_ID event the musb glue enables VBUS by calling
omap2430_musb_set_vbus(musb, 1) that sets the session bit, but on
USB_EVENT_NONE reverse action is never made, and that breaks PM.

Disable VBUS unconditionally on USB_EVENT_NONE to be sure musb
session is ended on cable unplug so that PM works.

Signed-off-by: Grazvydas Ignotas nota...@gmail.com
---
 drivers/usb/musb/omap2430.c |1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/usb/musb/omap2430.c b/drivers/usb/musb/omap2430.c
index 2a39c11..d430677 100644
--- a/drivers/usb/musb/omap2430.c
+++ b/drivers/usb/musb/omap2430.c
@@ -296,6 +296,7 @@ static void omap_musb_set_mailbox(struct omap2430_glue 
*glue)
pm_runtime_put_autosuspend(dev);
}
 
+   omap2430_musb_set_vbus(musb, 0);
if (data-interface_type == MUSB_INTERFACE_UTMI) {
if (musb-xceiv-otg-set_vbus)
otg_set_vbus(musb-xceiv-otg, 0);
-- 
1.7.9.5

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

[PATCH 7/7] usb: musb: gadget: use platform callback to enable vbus

[Grazvydas Ignotas]

On some platform configurations (like OMAP3+twl4030) it's the platform
code that enables VBUS, not OTG transceiver, so call vbus platform
callback instead, it will then call the transceiver if needed.

This fixes a use case where USB cable is plugged first and gadget
driver is loaded later after that.

Signed-off-by: Grazvydas Ignotas nota...@gmail.com
---
 drivers/usb/musb/musb_gadget.c |5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/drivers/usb/musb/musb_gadget.c b/drivers/usb/musb/musb_gadget.c
index be18537..19998e9 100644
--- a/drivers/usb/musb/musb_gadget.c
+++ b/drivers/usb/musb/musb_gadget.c
@@ -1972,9 +1972,8 @@ static int musb_gadget_start(struct usb_gadget *g,
goto err;
}
 
-   if ((musb-xceiv-last_event == USB_EVENT_ID)
-otg-set_vbus)
-   otg_set_vbus(otg, 1);
+   if (musb-xceiv-last_event == USB_EVENT_ID)
+   musb_platform_set_vbus(musb, 1);
 
hcd-self.uses_pio_for_control = 1;
 
-- 
1.7.9.5

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

[PATCH 1/7] usb: otg: twl4030-usb: don't enable PHY during init

[Grazvydas Ignotas]

There is no need to do it, otg.set_suspend(false) (which itself
comes from runtime_pm OMAP glue calls) will enable it later anyway.
This used to be the place where things were enabled if booted with
cable connected before runtime_pm conversion, but now can be dropped.

Signed-off-by: Grazvydas Ignotas nota...@gmail.com
---
 drivers/usb/otg/twl4030-usb.c |   23 +--
 1 file changed, 9 insertions(+), 14 deletions(-)

diff --git a/drivers/usb/otg/twl4030-usb.c b/drivers/usb/otg/twl4030-usb.c
index a994715..1515c0b 100644
--- a/drivers/usb/otg/twl4030-usb.c
+++ b/drivers/usb/otg/twl4030-usb.c
@@ -522,19 +522,17 @@ static void twl4030_usb_phy_init(struct twl4030_usb *twl)
 {
enum omap_musb_vbus_id_status status;
 
-   status = twl4030_usb_linkstat(twl);
-   if (status  0) {
-   if (status == OMAP_MUSB_VBUS_OFF ||
-   status == OMAP_MUSB_ID_FLOAT) {
-   __twl4030_phy_power(twl, 0);
-   twl-asleep = 1;
-   } else {
-   __twl4030_phy_resume(twl);
-   twl-asleep = 0;
-   }
+   /*
+* Start in sleep state, we'll get called through set_suspend()
+* callback when musb is runtime resumed and it's time to start.
+*/
+   __twl4030_phy_power(twl, 0);
+   twl-asleep = 1;
 
+   status = twl4030_usb_linkstat(twl);
+   if (status  0)
omap_musb_mailbox(twl-linkstat);
-   }
+
sysfs_notify(twl-dev-kobj, NULL, vbus);
 }
 
@@ -649,9 +647,6 @@ static int twl4030_usb_probe(struct platform_device *pdev)
return status;
}
 
-   /* Power down phy or make it work according to
-* current link state.
-*/
twl4030_usb_phy_init(twl);
 
dev_info(pdev-dev, Initialized TWL4030 USB module\n);
-- 
1.7.9.5

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

Re: [PATCH 1/2] ARM: OMAP2+: Prevent potential crash if GPMC probe fails

[Grazvydas Ignotas]

On Thu, Feb 14, 2013 at 2:04 PM, Philip, Avinash avinashphi...@ti.com wrote:
 Hi Tony,

 On Sat, Feb 09, 2013 at 21:25:49, Ezequiel Garcia wrote:
 On Fri, Feb 08, 2013 at 04:56:19PM -0600, Jon Hunter wrote:
 Without this patch, GPMC is currently broken on my igep board setup,
 if initialized through a device tree.

 Tested-by: Ezequiel Garcia ezequiel.gar...@free-electrons.com

 Without this patch GPMC is not working in am335x-evm.

 Tested-by: Philip Avinash avinashphi...@ti.com

 See Jon's comments.

 JON  Hi Tony, this one appears to be merged incorrectly. The unreserve ended
 JON  up in the gpmc_calc_timings() function. Here is a patch to fix.

Just wasted a hour or a few trying to figure out this problem, can we
get this merged now? Maybe Jon can resend this with all the tested-bys
to catch Tony's attention?

Tested-by: Grazvydas Ignotas nota...@gmail.com


-- 
Gražvydas
--
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] OMAPDSS: tpo-td043 panel: fix data passing between SPI/DSS parts

[Grazvydas Ignotas]

This driver uses omap_dss_device that it gets from a board file through
SPI platfrom_data pointer to pass data from SPI to DSS portion of the
driver by using dev_set_drvdata(). However this trick no longer works,
as DSS core no longer uses omap_dss_device from a board file to create
the real device, so use a global pointer to accomplish this instead,
like other SPI panel drivers do.

Signed-off-by: Grazvydas Ignotas nota...@gmail.com
---
 .../video/omap2/displays/panel-tpo-td043mtea1.c|   13 +++--
 1 file changed, 11 insertions(+), 2 deletions(-)

diff --git a/drivers/video/omap2/displays/panel-tpo-td043mtea1.c 
b/drivers/video/omap2/displays/panel-tpo-td043mtea1.c
index 6b66439..048c983 100644
--- a/drivers/video/omap2/displays/panel-tpo-td043mtea1.c
+++ b/drivers/video/omap2/displays/panel-tpo-td043mtea1.c
@@ -63,6 +63,9 @@ struct tpo_td043_device {
u32 power_on_resume:1;
 };
 
+/* used to pass spi_device from SPI to DSS portion of the driver */
+static struct tpo_td043_device *g_tpo_td043;
+
 static int tpo_td043_write(struct spi_device *spi, u8 addr, u8 data)
 {
struct spi_message  m;
@@ -403,7 +406,7 @@ static void tpo_td043_disable(struct omap_dss_device 
*dssdev)
 
 static int tpo_td043_probe(struct omap_dss_device *dssdev)
 {
-   struct tpo_td043_device *tpo_td043 = dev_get_drvdata(dssdev-dev);
+   struct tpo_td043_device *tpo_td043 = g_tpo_td043;
int nreset_gpio = dssdev-reset_gpio;
int ret = 0;
 
@@ -440,6 +443,8 @@ static int tpo_td043_probe(struct omap_dss_device *dssdev)
if (ret)
dev_warn(dssdev-dev, failed to create sysfs files\n);
 
+   dev_set_drvdata(dssdev-dev, tpo_td043);
+
return 0;
 
 fail_gpio_req:
@@ -505,6 +510,9 @@ static int tpo_td043_spi_probe(struct spi_device *spi)
return -ENODEV;
}
 
+   if (g_tpo_td043 != NULL)
+   return -EBUSY;
+
spi-bits_per_word = 16;
spi-mode = SPI_MODE_0;
 
@@ -521,7 +529,7 @@ static int tpo_td043_spi_probe(struct spi_device *spi)
tpo_td043-spi = spi;
tpo_td043-nreset_gpio = dssdev-reset_gpio;
dev_set_drvdata(spi-dev, tpo_td043);
-   dev_set_drvdata(dssdev-dev, tpo_td043);
+   g_tpo_td043 = tpo_td043;
 
omap_dss_register_driver(tpo_td043_driver);
 
@@ -534,6 +542,7 @@ static int tpo_td043_spi_remove(struct spi_device *spi)
 
omap_dss_unregister_driver(tpo_td043_driver);
kfree(tpo_td043);
+   g_tpo_td043 = NULL;
 
return 0;
 }
-- 
1.7.9.5

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

Re: MUSB regression in linux next at least for pandboard

[Grazvydas Ignotas]

On Thu, Feb 7, 2013 at 11:16 AM, Roger Quadros rog...@ti.com wrote:
snip
 It seems the beagleboard problem is related to OMAP silicon errata [1].
 Apparently, remote wakeup as well as host issued wakeup break omap-ehci and 
 have
 nothing to do with the hub or it's driver.

 I'll work on this issue after I'm done with device tree migration.

Looking forward to this, mainline has been suffering from this since
almost forever..


-- 
Gražvydas
--
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: MUSB-HDRC Gadget driving VBUS inappropriately

[Grazvydas Ignotas]

On Fri, Dec 14, 2012 at 11:53 AM, Ian Coolidge iancooli...@gmail.com wrote:
 we find that with about a 2% chance, the gadget comes up in some kind of 
 firmware failed state, driving VBUS.
 In this condition, we found that MUSB_DEVCTL_SESSION bit was set.
 I understand this to be indicative of MUSB thinking it is in host mode, which 
 agrees with the driven VBUS.
 Further, in this state, I found that usually, there was one interrupt from 
 twl4030_usb, but NO interrupts from musb-hdrc.

I'm also also often seeing this and don't know any workaround except
powercycling the board :(
This was kind or relieved for me after I changed it to deinit musb on
shutdown/reset (3.3 should have that patch merged), however if you
randomly reset the board, there is still something like 30-50% chance
musb will come up dead, and on proper reset it's still something like
5% chance like you reported.


-- 
Gražvydas
--
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 00/16] OMAP USB Host cleanup

[Grazvydas Ignotas]

On Tue, Nov 27, 2012 at 6:30 PM, Felipe Balbi ba...@ti.com wrote:
 On Tue, Nov 27, 2012 at 04:42:47PM +0200, Roger Quadros wrote:
 Kevin,

 I gave a quick look at the issue. It seems that the High Speed USB Host
 module is kept in Software forced wakeup mode as a quick fix workaround
 to a bunch of silicon erratas. And we do nothing on USB global suspend.
 That's why CORE does not hit retention.

 If we runtime_suspend the USB host module on USB global suspend then it
 will be put in Force Idle mode. This will allow CORE to hit retention
 but then we will no longer be able to detect USB device connect events.

 So, till we have a better solution I will suggest to keep EHCI_HCD as a
 module in omap2plus_defconfig.

 I guess that better solution would be I/O pads wakeup interrupts ? But
 I don't think that's already in mainline, is it ?

I believe there was attempt to mainline that but it was rejected by Tony:
http://marc.info/?l=linux-omapm=134727428329745w=2

Hopefully someone can come up with a suitable solution, not being able
to suspend and broken power saving with EHCI sucks :(

-- 
Gražvydas
--
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/5] OMAPFB: use dma_alloc instead of omap's vram

[Grazvydas Ignotas]

Hi,

On Mon, Nov 12, 2012 at 12:25 PM, Tomi Valkeinen tomi.valkei...@ti.com wrote:
 This series changes omapfb to use standard dma_alloc funcs instead of omap
 specific vram allocator. This let's us remove the omap vram allocator, making
 omapfb platform independent.

 However, note that using standard dma funcs causes the following downsides:

 ...

 3) OMAPFB_GET_VRAM_INFO ioctl cannot return real values anymore. I
 changed the ioctl to return 64M for all the values, which, I hope, the
 applications will interpret as there's enough vram.

Do at least OMAPFB_QUERY_MEM/OMAPFB_SETUP_MEM still work?

 4) vram kernel parameter to define how much ram to reserve for video use no
 longer works. The user needs to enable CMA and use cma parameter.

That's a significant change, you should update Documentation/ .
What about omapfb.vram, is it still there?
Perhaps we also need to select/depend on CMA?


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

Re: [PATCH 2/3] pwm: New driver to support PWMs on TWL4030/6030 series of PMICs

[Grazvydas Ignotas]

On Thu, Nov 8, 2012 at 9:14 AM, Péter Ujfalusi peter.ujfal...@ti.com wrote:
 On 11/07/2012 06:50 PM, Grazvydas Ignotas wrote:
 +   if (pwm-hwpwm) {
 +   /* PWM 1 */
 +   mask = TWL4030_GPIO7_VIBRASYNC_PWM1_MASK;
 +   bits = TWL4030_GPIO7_VIBRASYNC_PWM1_PWM1;
 +   } else {
 +   /* PWM 0 */
 +   mask = TWL4030_GPIO6_PWM0_MUTE_MASK;
 +   bits = TWL4030_GPIO6_PWM0_MUTE_PWM0;
 +   }
 +
 +   /* Save the current MUX configuration for the PWM */
 +   twl-twl4030_pwm_mux = ~mask;
 +   twl-twl4030_pwm_mux |= (val  mask);

 Do we really need this mask clearing here? After probe twl4030_pwm_mux
 should be zero, and if twl4030_pwm_request is called twice you don't
 clear the important bits before |=, I think 'twl4030_pwm_mux = val 
 mask' would be better here.

 I'm storing both PWM's state in the same variable, but in different offsets:
 PWM0: bits 2-3
 PWM1: bits 4-5
 Probably it is over engineering to clear the relevant bits in the backup
 storage, but better to be safe IMHO.
 I would leave this part as it is.

Oh, it should be good then.


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

Re: [PATCH 3/3] pwm: New driver to support PWM driven LEDs on TWL4030/6030 series of PMICs

[Grazvydas Ignotas]

On Thu, Nov 8, 2012 at 9:34 AM, Péter Ujfalusi peter.ujfal...@ti.com wrote:
 On 11/07/2012 07:12 PM, Grazvydas Ignotas wrote:
 +static int twl4030_pwmled_config(struct pwm_chip *chip, struct pwm_device 
 *pwm,
 + int duty_ns, int period_ns)
 +{
 +   int duty_cycle = (duty_ns * TWL4030_LED_MAX) / period_ns;
 +   u8 on_time;
 +   u8 pwm_config[2];
 +   int base, ret;
 +
 +   if (duty_cycle = TWL4030_LED_MAX)
 +   on_time = TWL4030_LED_MAX;
 +   else if (!duty_cycle)
 +   on_time = TWL4030_LED_MAX - 1;
 +   else
 +   on_time = TWL4030_LED_MAX - duty_cycle;
 +
 +   base = pwm-hwpwm * 2 + TWL4030_PWMA_REG;
 +
 +   pwm_config[0] = on_time;
 +   pwm_config[1] = TWL4030_LED_MAX;
 +
 +   ret = twl_i2c_write(TWL4030_MODULE_LED, pwm_config, base, 2);

 Shouldn't this use TWL4030_MODULE_PWMA and TWL4030_MODULE_PWMB as
 first argument? I can guess it works your way too, but
 TWL4030_MODULE_PWMx would match the TRM better.

 I don't have strong opinion regarding to this. You mean changing from:

 base = pwm-hwpwm * 2 + TWL4030_PWMA_REG;
 ret = twl_i2c_write(TWL4030_MODULE_LED, pwm_config, base, 2);

 to:

 if (pwm-hwpwm)
 module = TWL4030_MODULE_PWMB;
 else
 module = TWL4030_MODULE_PWMA;
 ret = twl_i2c_write(module, pwm_config, 0, 2);

 But I want to note that I'm currently trying to clean up the mess around
 twl-core. In my view we have quite a bit of redundancy in there. The PWM A/B
 is for driving the LED A/B outputs. We should have only these modules for
 PWM/LED in twl-core:
 TWL_MODULE_PWM - offset for PWM0ON register in twl4030 and PWM1ON for twl6030
 TWL_MODULE_LED - offset for LEDEN register in twl4030 and LED_PWM_CTRL1
  for twl6030

 From here the driver can figure out what to do IMHO.

 There's no need to have separate TWL 'modules' for:
 TWL4030_BASEADD_PWM0
 TWL4030_BASEADD_PWM1
 TWL4030_BASEADD_PWMA
 TWL4030_BASEADD_PWMB

Well all these seem to come from TRM, no hard feelings here too but if
you are going to remove them, probably worth adding a comment.

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

Re: [PATCH 2/3] pwm: New driver to support PWMs on TWL4030/6030 series of PMICs

[Grazvydas Ignotas]

On Wed, Nov 7, 2012 at 4:44 PM, Peter Ujfalusi peter.ujfal...@ti.com wrote:
 The driver supports the following PWM outputs:
 TWL4030 PWM0 and PWM1
 TWL6030 PWM1 and PWM2

 On TWL4030 the PWM signals are muxed. Upon requesting the PWM the driver
 will select the correct mux so the PWM can be used. When the PWM has been
 freed the original configuration going to be restored.

 Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
 ---
  drivers/pwm/Kconfig   |  10 ++
  drivers/pwm/Makefile  |   1 +
  drivers/pwm/pwm-twl.c | 304 
 ++
  3 files changed, 315 insertions(+)
  create mode 100644 drivers/pwm/pwm-twl.c


snip

 --- /dev/null
 +++ b/drivers/pwm/pwm-twl.c

snip

 +
 +static int twl4030_pwm_enable(struct pwm_chip *chip, struct pwm_device *pwm)
 +{
 +   int ret;
 +   u8 val;
 +
 +   ret = twl_i2c_read_u8(TWL4030_MODULE_INTBR, val, TWL4030_GPBR1_REG);
 +   if (ret  0) {
 +   dev_err(chip-dev, %s: Failed to read GPBR1\n, pwm-label);
 +   return ret;
 +   }
 +
 +   val |= TWL4030_PWM_TOGGLE(pwm-hwpwm, TWL4030_PWMX_BITS);

In my experience doing it like this doesn't work reliably, i.e.
sometimes it just won't enable. I had to first set CLK_ENABLE bit, and
then ENABLE bit with separate i2c write. Perhaps it needs a cycle or
two of 32k clock or something (that doesn't seem to be documented
though).

 +
 +   ret = twl_i2c_write_u8(TWL4030_MODULE_INTBR, val, TWL4030_GPBR1_REG);
 +   if (ret  0)
 +   dev_err(chip-dev, %s: Failed to enable PWM\n, pwm-label);
 +
 +   return ret;
 +}
 +
 +static void twl4030_pwm_disable(struct pwm_chip *chip, struct pwm_device 
 *pwm)
 +{
 +   int ret;
 +   u8 val;
 +
 +   ret = twl_i2c_read_u8(TWL4030_MODULE_INTBR, val, TWL4030_GPBR1_REG);
 +   if (ret  0) {
 +   dev_err(chip-dev, %s: Failed to read GPBR1\n, pwm-label);
 +   return;
 +   }
 +
 +   val = ~TWL4030_PWM_TOGGLE(pwm-hwpwm, TWL4030_PWMX_BITS);

Same problem here, I would sometimes get LED stuck at full brightness
after this, first clearing ENABLE and then CLK_ENABLE fixed it (we
have charger LED connected to PWM1 on pandora).

 +
 +   ret = twl_i2c_write_u8(TWL4030_MODULE_INTBR, val, TWL4030_GPBR1_REG);
 +   if (ret  0)
 +   dev_err(chip-dev, %s: Failed to disable PWM\n, pwm-label);
 +}
 +
 +static int twl4030_pwm_request(struct pwm_chip *chip, struct pwm_device *pwm)
 +{
 +   struct twl_pwm_chip *twl = container_of(chip, struct twl_pwm_chip,
 +   chip);
 +   int ret;
 +   u8 val, mask, bits;
 +
 +   ret = twl_i2c_read_u8(TWL4030_MODULE_INTBR, val, TWL4030_PMBR1_REG);
 +   if (ret  0) {
 +   dev_err(chip-dev, %s: Failed to read PMBR1\n, pwm-label);
 +   return ret;
 +   }
 +
 +   if (pwm-hwpwm) {
 +   /* PWM 1 */
 +   mask = TWL4030_GPIO7_VIBRASYNC_PWM1_MASK;
 +   bits = TWL4030_GPIO7_VIBRASYNC_PWM1_PWM1;
 +   } else {
 +   /* PWM 0 */
 +   mask = TWL4030_GPIO6_PWM0_MUTE_MASK;
 +   bits = TWL4030_GPIO6_PWM0_MUTE_PWM0;
 +   }
 +
 +   /* Save the current MUX configuration for the PWM */
 +   twl-twl4030_pwm_mux = ~mask;
 +   twl-twl4030_pwm_mux |= (val  mask);

Do we really need this mask clearing here? After probe twl4030_pwm_mux
should be zero, and if twl4030_pwm_request is called twice you don't
clear the important bits before |=, I think 'twl4030_pwm_mux = val 
mask' would be better here.


-- 
Gražvydas
--
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