Re: remap_file_pages regression

[Grazvydas Ignotas]

On Mon, Feb 15, 2016 at 12:26 PM, Kirill A. Shutemov
 wrote:
> On Mon, Feb 15, 2016 at 03:32:55AM +0200, Grazvydas Ignotas wrote:
>> Hi,
>>
>> since remap_file_pages() rework the following simple program fails.
>> I haven't actually bisected this, only know it worked on 3.19 at least
>> (I bought a new system now and need 4.2+ for hardware support).
>
> The patch below should fix the issue. Please test.

It works, thanks.
Tested-by: Grazvydas Ignotas 

>
>> If you are curious, the program is an emulator and is using
>> remap_file_pages() to implement memory mirroring efficiently (and to
>> remap things during run time).
>
> Could you elaborate on this?
>
> Why creating file on tmpfs/shmem (using memfd_create() for example) plus
> plain mmap()s wouldn't work for you?

It works, but remap_file_pages() is just more convenient, you don't
need many mmap()/munmap() calls (less syscalls), and as the emulator
needs to reconfigure the mappings during runtime (it's not a one time
init thing), remap_file_pages() makes more sense. The reduced number
of VMAs of the past was also a benefit I guess.

Actually I'm not the author of the emulator in question, so I've asked
the author to comment:
--- quote ---
One of the things we do with remap_file_pages is a mapping for the
emulated system's VRAM.  The system allows many different
configurations of several differently sized VRAM banks to a 16MB area
of address space. The banks are multiples of 16KB in size and their
allocations are also 16KB aligned. With remap_file_pages we can map
that entire space to an (in-memory) file and then arbitrarily map
chunks of it as desired. We have an mmap-based fallback, but it
requires us to manage a separate mmap for each 16KB region."
--- end of quote ---
Apparently the mentioned fallback was a compile time option, so I was
hit with the issue after upgrading my machine.

> 
>
> Signed-off-by: Kirill A. Shutemov 

Cc: stable?
Fixes: c8d78c182 (I guess?)

> Reported-by: Grazvydas Ignotas 
> ---
>  mm/mmap.c | 34 +-
>  1 file changed, 29 insertions(+), 5 deletions(-)
>
> diff --git a/mm/mmap.c b/mm/mmap.c
> index 2f2415a7a688..76d1ec29149b 100644
> --- a/mm/mmap.c
> +++ b/mm/mmap.c
> @@ -2664,12 +2664,29 @@ SYSCALL_DEFINE5(remap_file_pages, unsigned long, 
> start, unsigned long, size,
> if (!vma || !(vma->vm_flags & VM_SHARED))
> goto out;
>
> -   if (start < vma->vm_start || start + size > vma->vm_end)
> +   if (start < vma->vm_start)
> goto out;
>
> -   if (pgoff == linear_page_index(vma, start)) {
> -   ret = 0;
> -   goto out;
> +   if (start + size > vma->vm_end) {
> +   struct vm_area_struct *next;
> +
> +   for (next = vma->vm_next; next; next = next->vm_next) {
> +   /* hole between vmas ? */
> +   if (next->vm_start != next->vm_prev->vm_end)
> +   goto out;
> +
> +   if (next->vm_file != vma->vm_file)
> +   goto out;
> +
> +   if (next->vm_flags != vma->vm_flags)
> +   goto out;
> +
> +   if (start + size <= next->vm_end)
> +   break;
> +   }
> +
> +   if (!next)
> +   goto out;
> }
>
> prot |= vma->vm_flags & VM_READ ? PROT_READ : 0;
> @@ -2679,9 +2696,16 @@ SYSCALL_DEFINE5(remap_file_pages, unsigned long, 
> start, unsigned long, size,
> flags &= MAP_NONBLOCK;
> flags |= MAP_SHARED | MAP_FIXED | MAP_POPULATE;
> if (vma->vm_flags & VM_LOCKED) {
> +   struct vm_area_struct *tmp;
> flags |= MAP_LOCKED;
> +
> /* drop PG_Mlocked flag for over-mapped range */
> -   munlock_vma_pages_range(vma, start, start + size);
> +   for (tmp = vma; tmp->vm_start >= start + size;
> +   tmp = tmp->vm_next) {
> +   munlock_vma_pages_range(tmp,
> +   max(tmp->vm_start, start),
> +   min(tmp->vm_end, start + size));
> +   }
> }
>
> file = get_file(vma->vm_file);
> --
>  Kirill A. Shutemov

Gražvydas

remap_file_pages regression

[Grazvydas Ignotas]

Hi,

since remap_file_pages() rework the following simple program fails.
I haven't actually bisected this, only know it worked on 3.19 at least
(I bought a new system now and need 4.2+ for hardware support). If you
are curious, the program is an emulator and is using remap_file_pages()
to implement memory mirroring efficiently (and to remap things during
run time).

Grazvydas

%<===

#define _GNU_SOURCE
#include 
#include 
#include 
#include 

#define SIZE(4096 * 3)

int main(int argc, char **argv)
{
unsigned long *p;
long i;

p = mmap(NULL, SIZE, PROT_READ | PROT_WRITE,
MAP_SHARED | MAP_ANONYMOUS, -1, 0);
if (p == MAP_FAILED) {
perror("mmap");
return -1;
}

for (i = 0; i < SIZE / 4096; i++)
p[i * 4096 / sizeof(*p)] = i;

if (remap_file_pages(p, 4096, 0, 1, 0)) {
perror("remap_file_pages");
return -1;
}

if (remap_file_pages(p, 4096 * 2, 0, 1, 0)) {
perror("remap_file_pages");
return -1;
}

assert(p[0] == 1);

munmap(p, SIZE);

return 0;
}

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 = <&gpio3 30 0>;
> vcc-supply = <&vaux4>;
>
> -   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-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: linux-next: Tree for Sep 2 (power/twl4030_charger.c)

[Grazvydas Ignotas]

CCing author of the regression.

On Wed, Sep 2, 2015 at 7:52 PM, Randy Dunlap  wrote:
> On 09/02/15 01:17, Stephen Rothwell wrote:
>> Hi all,
>>
>> There will be no linux-next release this Friday or Monday.
>>
>> Please do not add material for v4.4 until after v4.3-rc1 is out.
>>
>> Changes since 20150901:
>>
>
> on x86_64:
>
> drivers/built-in.o: In function `twl4030_charger_update_current':
> twl4030_charger.c:(.text+0x504681): undefined reference to 
> `twl4030_get_madc_conversion'
>
>
> Full randconfig file is attached.
>
>
> --
> ~Randy


config-r5923
Description: Binary data

Re: [PATCH] ti-soc-thermal: implement omap3 support

[Grazvydas Ignotas]

On Tue, Mar 31, 2015 at 11:42 AM, Pavel Machek  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 
>
> ---
> ...
> --- /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 
> + *
> + * 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-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: twl4030_charger: need changes to get probed?

[Grazvydas Ignotas]

On Sat, Mar 7, 2015 at 12:56 AM, Pali Rohár  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
>> >  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-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: twl4030_charger: need changes to get probed?

[Grazvydas Ignotas]

On Fri, Mar 6, 2015 at 11:57 PM, Pali Rohár  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-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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  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 
> ---
>  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-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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  wrote:
> From: "H. Nikolaus Schaller" 
>
> Signed-off-by: H. Nikolaus Schaller 
> ---
>  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-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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  wrote:
> From: "H. Nikolaus Schaller" 
>
> 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 
> Signed-off-by: Marek Belisko 
> ---
>  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 = ;
> +   gpios = <&gpio4 14 GPIO_ACTIVE_HIGH>;   /* GPIO_110 */
> +   gpio-key,wakeup;
> +   };
> +
> +   down-button {
> +   label = "down";
> +   linux,code = ;
> +   gpios = <&gpio4 7 GPIO_ACTIVE_HIGH>;/* GPIO_103 */
> +   gpio-key,wakeup;
> +   };
> +
> +   left-button {
> +   label = "left";
> +   linux,code = ;
> +   gpios = <&gpio4 0 GPIO_ACTIVE_HIGH>;/* GPIO_96 */
> +   gpio-key,wakeup;
> +   };
> +
> +   right-button {
> +   label = "right";
> +   linux,code = ;
> +   gpios = <&gpio4 2 GPIO_ACTIVE_HIGH>;/* GPIO_98 */
> +   gpio-key,wakeup;
> +   };
> +
> +   pageup-button {
> +   label = "game 1";
> +   linux,code = ;
> +   gpios = <&gpio4 13 GPIO_ACTIVE_HIGH>;   /* GPIO_109 */
> +   gpio-key,wakeup;
> +   };
> +
> +   pagedown-button {
> +   label = "game 3";
> +   linux,code = ;
> +   gpios = <&gpio4 10 GPIO_ACTIVE_HIGH>;   /* GPIO_106 */
> +   gpio-key,wakeup;
> +   };
> +
> +   home-button {
> +   label = "game 4";
> +   linux,code = ;
> +   gpios = <&gpio4 5 GPIO_ACTIVE_HIGH>;/* GPIO_101 */
> +   gpio-key,wakeup;
> +   };
> +
> +   end-button {
> +   label = "game 2";
> +   linux,code = ;
> +   gpios = <&gpio4 15 GPIO_ACTIVE_HIGH>;   /* GPIO_111 */
> +   gpio-key,wakeup;
> +   };
> +
> +   right-shift {
> +   label = "l";
> +   linux,code = ;
> +   gpios = <&gpio4 6 GPIO_ACTIVE_HIGH>;/* GPIO_102 */
> +   gpio-key,wakeup;
> +   };
> +
> +   kp-plus {
> +   label = "l2";
> +   linux,code = ;
> +   gpio

Re: [PATCH 0/4] add openpandora device support

[Grazvydas Ignotas]

On Thu, Feb 12, 2015 at 3:03 PM, Marek Belisko  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-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Grazvydas Ignotas]

On Fri, Dec 26, 2014 at 2:34 PM, Sebastian Reichel  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-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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  wrote:
> * Paul Walmsley  [141113 15:01]:
>> Hi
>>
>> On Thu, 13 Nov 2014, Tony Lindgren wrote:
>>
>> > * Tomi Valkeinen  [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-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] mfd: twl4030-power: Fix poweroff with PM configuration enabled

[Grazvydas Ignotas]

On Tue, Nov 4, 2014 at 5:42 PM, Tony Lindgren  wrote:
> * Igor Grinberg  [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-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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  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 
> 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-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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  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-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

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-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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  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-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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  wrote:
> On 06/04/2014 05:04 AM, Grazvydas Ignotas wrote:
>> On Thu, May 29, 2014 at 12:46 AM, Nishanth Menon  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-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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  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 
> ---
> 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 
>  #include 
>  #include 
> +#include 
>  #include 
>
>  #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-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH V2 0/5] Huge pages for short descriptors on ARM

[Grazvydas Ignotas]

On Thu, Apr 24, 2014 at 2:03 PM, Russell King - ARM Linux
 wrote:
> On Thu, Apr 24, 2014 at 11:55:56AM +0100, Steve Capper wrote:
>> On 24 April 2014 11:42, Russell King - ARM Linux  
>> wrote:
>> > On Thu, Apr 24, 2014 at 11:36:39AM +0100, Will Deacon wrote:
>> >> I guess I'm after some commitment that this is (a) useful to somebody and
>> >> (b) going to be tested regularly, otherwise it will go the way of things
>> >> like big-endian, where we end up carrying around code which is broken more
>> >> often than not (although big-endian is more self-contained).
>> >
>> > It may be something worth considering adding to my nightly builder/boot
>> > testing, but I suspect that's impractical as it probably requires a BE
>> > userspace, which would then mean that the platform can't boot LE.
>> >
>> > I suspect that we will just have to rely on BE users staying around and
>> > reporting problems when they occur.
>>
>> The huge page support is for standard LE, I think Will was saying that
>> this will be like BE if no-one uses it.
>
> We're not saying that.
>
> What we're asking is this: *Who* is using hugepages today?

We are using it on opanpandora handheld, it's really useful for doing
graphics in software. Here are some benchmarks I did some time ago:
http://lists.infradead.org/pipermail/linux-arm-kernel/2013-February/148835.html
For example Cortex-A8 only has 32 dTLB entries so they run out pretty
fast while drawing vertical lines on linear images. And it's not so
rare thing to do, like for drawing vertical scrollbars.

Other people find use for it too, like to get more consistent results
between benchmark runs:
http://ssvb.github.io/2013/06/27/fullhd-x11-desktop-performance-of-the-allwinner-a10.html

Yes in my case this is niche device and I can keep patching in the
hugepage support, but mainline support would make life easier and
would be very much appreciated.


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

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  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 
>> > ---
>> >  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-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 4/4] wl1251: spi: add device tree support

[Grazvydas Ignotas]

On Mon, Oct 28, 2013 at 8:37 AM, Kumar Gala  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-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 0/1] (Was: Linux 3.11-rc4)

[Grazvydas Ignotas]

On Tue, Aug 6, 2013 at 6:43 PM, Oleg Nesterov  wrote:
> Felipe, thanks a lot. Yes fab840f is wrong, this "bug" is already
> used as a feature.
>
> Grazvydas, I cc'ed you because I do not really understand
> set_thread_context(). It does a couple of extra PTRACE_POKEUSER's
> with the "Linux 2.6.33+ needs ..." comment. It would be nice if you
> can check if 3.11 still needs this, in this case we probably need
> some more minor fixes in this area.
>
> In fact the first comment doesn't look right, when I look at 2.6.33
> it seems that POKEUSER(DR0-DR6) should be fine without POKEUSER(DR7),
> but this doesn't really matter and I can be easily wrong. Anyway
> this looks like a workaround to hide kernel bugs, I will appreciate
> it if you can tell if wine still needs it or not.

It's not that wine needs all this, it's the Windows games that use
debug registers to store random values to them for their copy
protection stuff. Older Linux kernels used to not care, but newer ones
started validating what's written to debug registers, and those games
started to break under wine. My wine commits try to sidestep these
kernel restrictions/sanity checking.

Personally I'd say the kernel should not limit what's written to debug
registers. Why can't I write insane values to registers in _my_
hardware? It's not like it's going to break the hardware or anything.

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

Re: [PATCH v2 0/9] wilink: add device tree support

[Grazvydas Ignotas]

Hi,

On Tue, Jul 2, 2013 at 5:55 PM, Luciano Coelho  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-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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  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 
>
> 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-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 0/5] usb: musb/otg: cleanup and fixes

[Grazvydas Ignotas]

On Wed, Mar 13, 2013 at 10:47 AM, Kishon Vijay Abraham I  wrote:
> This series has some misc cleanup and fixes. The fix solves the cold
> plug issue in omap3 which some have reported. Developed these patches on
> Linux 3.9-rc2 after applying 
> http://www.spinics.net/lists/linux-usb/msg81563.html
> (Grazvydas Ignotas patch series)
>
> Tested for g_zero enumeration in pandaboard and beagleboard in both
> cold plug and hot plug case. Any kind of testing for this series is welcome.
>
> Kishon Vijay Abraham I (5):
>   usb: musb: omap: remove the check before calling otg_set_vbus
>   usb: musb: omap: always glue have the correct vbus/id status
>   usb: otg: twl4030: use devres API for regulator get and request irq
>   usb: musb: omap: add usb_phy_init in omap2430_musb_init
>   usb: otg: twl4030: fix cold plug on OMAP3

Looks and works good for me on pandora.
Tested-by: Grazvydas Ignotas 

>  drivers/usb/musb/omap2430.c   |   22 ++
>  drivers/usb/otg/twl4030-usb.c |   35 ---
>  2 files changed, 22 insertions(+), 35 deletions(-)
>
> --
> 1.7.10.4
>



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

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  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 
> ---
>  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-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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  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-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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  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-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Grazvydas Ignotas]

On Wed, Nov 7, 2012 at 4:44 PM, Peter Ujfalusi  wrote:
> The driver supports the following LED outputs as generic PWM driver:
> TWL4030 LEDA and LEDB (PWMA and PWMB)
> TWL6030 Charging indicator LED (PWM LED)
>
> On TWL6030 when the PWM requested LED is configured to be controlled by SW.
> In this case the user can enable/disable and set the duty period freely.
> When the PWM has been freed, the LED driver is put back to HW control.
>
> Signed-off-by: Peter Ujfalusi 
> ---
>  drivers/pwm/Kconfig   |  10 ++
>  drivers/pwm/Makefile  |   1 +
>  drivers/pwm/pwm-twl-led.c | 287 
> ++
>  3 files changed, 298 insertions(+)
>  create mode 100644 drivers/pwm/pwm-twl-led.c
>
> diff --git a/drivers/pwm/Kconfig b/drivers/pwm/Kconfig
> index c577db9..49c2082 100644
> --- a/drivers/pwm/Kconfig
> +++ b/drivers/pwm/Kconfig
> @@ -152,6 +152,16 @@ config PWM_TWL
>   To compile this driver as a module, choose M here: the module
>   will be called pwm-twl.
>
> +config PWM_TWL_LED
> +   tristate "TWL4030/6030 PWM support for LED drivers"
> +   select HAVE_PWM
> +   depends on TWL4030_CORE
> +   help
> + Generic PWM framework driver for TWL4030/6030 LED.
> +
> + To compile this driver as a module, choose M here: the module
> + will be called pwm-twl-led.
> +
>  config PWM_VT8500
> tristate "vt8500 pwm support"
> depends on ARCH_VT8500
> diff --git a/drivers/pwm/Makefile b/drivers/pwm/Makefile
> index 3324c06..5f26134 100644
> --- a/drivers/pwm/Makefile
> +++ b/drivers/pwm/Makefile
> @@ -12,4 +12,5 @@ obj-$(CONFIG_PWM_TEGRA)   += pwm-tegra.o
>  obj-$(CONFIG_PWM_TIECAP)   += pwm-tiecap.o
>  obj-$(CONFIG_PWM_TIEHRPWM) += pwm-tiehrpwm.o
>  obj-$(CONFIG_PWM_TWL)  += pwm-twl.o
> +obj-$(CONFIG_PWM_TWL_LED)  += pwm-twl-led.o
>  obj-$(CONFIG_PWM_VT8500)   += pwm-vt8500.o
> diff --git a/drivers/pwm/pwm-twl-led.c b/drivers/pwm/pwm-twl-led.c
> new file mode 100644
> index 000..4d6ddc9
> --- /dev/null
> +++ b/drivers/pwm/pwm-twl-led.c
> @@ -0,0 +1,287 @@
> +/*
> + * Driver for TWL4030/6030 Pulse Width Modulator used as LED driver
> + *
> + * Copyright (C) 2012 Texas Instruments
> + * Author: Peter Ujfalusi 
> + *
> + * This driver is a complete rewrite of the former pwm-twl6030.c authorded 
> by:
> + * Hemanth V 
> + *
> + * This program is free software; you can redistribute it and/or modify it
> + * under the terms of the GNU General Public License version 2 as published 
> by
> + * the Free Software Foundation.
> + *
> + * 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.
> + *
> + * You should have received a copy of the GNU General Public License along 
> with
> + * this program.  If not, see .
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#define TWL4030_LED_MAX0x7f
> +#define TWL6030_LED_MAX0xff
> +
> +/* Registers, bits and macro for TWL4030 */
> +#define TWL4030_LEDEN_REG  0x00
> +#define TWL4030_PWMA_REG   0x01
> +
> +#define TWL4030_LEDXON (1 << 0)
> +#define TWL4030_LEDXPWM(1 << 4)
> +#define TWL4030_LED_PINS   (TWL4030_LEDXON | TWL4030_LEDXPWM)
> +#define TWL4030_LED_TOGGLE(led, x) ((x) << (led))
> +
> +/* Register, bits and macro for TWL6030 */
> +#define TWL6030_LED_PWM_CTRL1  0xf4
> +#define TWL6030_LED_PWM_CTRL2  0xf5
> +
> +#define TWL6040_LED_MODE_HW0x00
> +#define TWL6040_LED_MODE_ON0x01
> +#define TWL6040_LED_MODE_OFF   0x02
> +#define TWL6040_LED_MODE_MASK  0x03
> +
> +struct twl_pwmled_chip {
> +   struct pwm_chip chip;
> +};
> +
> +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.


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

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



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



> +
> +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-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFT/PATCH] serial: omap: prevent resume if device is not suspended.

[Grazvydas Ignotas]

On Tue, Sep 18, 2012 at 5:02 PM, Felipe Balbi  wrote:
> On Tue, Sep 18, 2012 at 06:10:50PM +0530, Sourav Poddar wrote:
>> Greg's tty-next is not booting on 2420 based N800. The failure is
>> observed at serial init itself. The reason might be that n800 tries to
>> resume even though it is not suspended before.
>>
>> Reported-by: Paul Walmsley 
>> Signed-off-by: Sourav Poddar 
>
> FWIW:
>
> Reviewed-by: Felipe Balbi 
>
> Paul does this fix the issue for you ? Note that it depends on a
> previous patch Sourav sent [1]
>
> [1] http://marc.info/?l=linux-omap&m=134796819607889&w=2
>
> There's one thing that gets my attention, though, why only n800 would
> fail here ?
>
> I wonder if we should be using:
>
> pm_runtime_set_active(dev);
> pm_runtime_get_enable(dev);
>
> to prevent our runtime_resume() to be called from probe, but Sourav
> tested and it doesn't work on BeagleBoard, but it works on PandaBoard.
>
> Does it ring any bell ??

Well I guess it's normal resume callback is called during probe as
pm_runtime_get_sync() is called there, and according to documentation
[1], devices are assumed to be suspended before probe is called.

According to [1], pm_runtime_set_active() should be called before
pm_runtime_enable() to indicate to the core that device is active
during probe if that's the case, I guess this means
pm_runtime_get_sync() is not needed in that case, but I'm not sure
what's the actual serial state during probe nowadays.

[1] chapter 5 of Documentation/power/runtime_pm.txt:
The initial runtime PM status of all devices is 'suspended', but it
need not reflect the actual physical state of the device. Thus, if the
device is initially active (i.e. it is able to process I/O), its
runtime PM status must be changed to 'active', with the help of
pm_runtime_set_active(), before pm_runtime_enable() is called for the
device.

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