date:20111221

Re: [PATCH 0/3] coupled cpuidle state support

2011-12-21 Thread Arjan van de Ven

On 12/21/2011 1:09 AM, Colin Cross wrote:
 On some ARM SMP SoCs (OMAP4460, Tegra 2, and probably more), the
 cpus cannot be independently powered down, either due to
 sequencing restrictions (on Tegra 2, cpu 0 must be the last to
 power down), or due to HW bugs (on OMAP4460, a cpu powering up
 will corrupt the gic state unless the other cpu runs a work
 around).  Each cpu has a power state that it can enter without
 coordinating with the other cpu (usually Wait For Interrupt, or
 WFI), and one or more coupled power states that affect blocks
 shared between the cpus (L2 cache, interrupt controller, and
 sometimes the whole SoC).  Entering a coupled power state must
 be tightly controlled on both cpus.
 
 The easiest solution to implementing coupled cpu power states is
 to hotplug all but one cpu whenever possible, usually using a
 cpufreq governor that looks at cpu load to determine when to
 enable the secondary cpus.  This causes problems, as hotplug is an
 expensive operation, so the number of hotplug transitions must be
 minimized, leading to very slow response to loads, often on the
 order of seconds.
 
 This patch series implements an alternative solution, where each
 cpu will wait in the WFI state until all cpus are ready to enter
 a coupled state, at which point the coupled state function will
 be called on all cpus at approximately the same time.
 
 Once all cpus are ready to enter idle, they are woken by an smp
 cross call.  At this point, there is a chance that one of the
 cpus will find work to do, and choose not to enter suspend.  A
 final pass is needed to guarantee that all cpus will call the
 power state enter function at the same time.  During this pass,
 each cpu will increment the ready counter, and continue once the
 ready counter matches the number of online coupled cpus.  If any
 cpu exits idle, the other cpus will decrement their counter and
 retry.

this smells fundamentally racey to me; you can get an interrupt one
cycle after you think you're done, but before the last guy enters WFI...

how do you solve that issue ?


--
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] am35xx-emac: move generic EMAC init to separate file

2011-12-21 Thread Ilya Yanok

Hi,

On 21.12.2011 10:07, Hiremath, Vaibhav wrote:
 +static struct resource am35xx_mdio_resources[] = {
 +{
 +.start  = AM35XX_IPSS_EMAC_BASE + AM35XX_EMAC_MDIO_OFFSET,
 +.end= AM35XX_IPSS_EMAC_BASE + AM35XX_EMAC_MDIO_OFFSET +
 +  SZ_4K - 1,
 +.flags  = IORESOURCE_MEM,
 +},
 +};
 This will not be board independent, using AM35xx everywhere.

Why? It will work for any AM35XX based board. Probably we can try and
make it work with EMACs on other AM3XXXs but I don't have these devices.

 To make it completely board independent, you should get all this platform 
 specific data from board file. Probably have emac_init() function here and 
 pass the data.

Hm.. This data is SoC-dependent not board-dependent, what's the reason
to move it to the board file?

 Do you know any other platform or device using this IP?

Yes, I have a couple of AM3517 based boards that use this IP.

Regards, Ilya.
--
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] mcx: support for HTKW mcx board

2011-12-21 Thread Igor Grinberg

Hi Ilya,

On 12/20/11 22:07, Ilya Yanok wrote:
 Hi Igor,
 
 +static struct omap2_hsmmc_info mmc[] = {
 +   {
 +   .mmc= 1,
 +   .caps   = MMC_CAP_4_BIT_DATA,
 +   .gpio_cd= SD_CARD_CD,
 +   .gpio_wp= SD_CARD_WP,
 +   .ocr_mask   = MMC_VDD_32_33 | MMC_VDD_33_34 |
 +   MMC_VDD_165_195,

 The ocr_mask will be overridden, by the following patch:
 -
 commit e89715a7e48d505f42813a4e3ee0f0efb49832ba
 Author: Abhilash K V abhilash...@ti.com
 Date:   Fri Dec 9 12:27:36 2011 -0800

 ARM: OMAP: hsmmc: Support for AM3517 MMC1 voltages
 --

 in Tony's hsmmc branch.

 IMO it should be fixed, by adding a check if the ocr_mask is
 already set...
 I can't send a patch for this right now...
 
 Well, I think I should just drop the .ocr_mask field then. Everything
 works fine for me with the above mentioned patch.

Yes, for your patch, it is correct - just remove it.

My concern is for the common code - it will override any
board special setting (e.g. you want smaller range supported).

 +static void __init mcx_init(void)
 +{
 +   int err;
 +
 +   omap3_mux_init(board_mux, OMAP_PACKAGE_CBB);
 +   mcx_i2c_init();
 +   platform_add_devices(mcx_devices, ARRAY_SIZE(mcx_devices));
 +   omap_serial_init();

 Shouldn't this one be before the mcx_i2c_init() call?
 
 Well, I think I've taken this order from some other board init... I
 think the idea was to bring up regulator chip earlier. But I can move
 serial up with no problem.

I see, no problem.
My concern was about the pr_err() inside the mcx_i2c_init()
and the mcx_ts_init() functions.

Also, IMO, mcx_ts_init() can be done at a later stage, than along
with I2C buses initialization, but it does not really meter...


-- 
Regards,
Igor.
--
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

Is Pandaboard cpuhotplug working stably?

2011-12-21 Thread Barry Song

Hi guys,
i tried cpuhotplug on pandaboard for both
Pandroid_Froyo_L27.8.2_release_pkg and Linaro 11.11. It has failed to
work stably.
On Pandroid_Froyo_L27.8.2_release_pkg, unplugging cpu1 works well:
# echo 0  /sys/devices/system/cpu/cpu1/online
CPU1: shutdown

if i enable the cpu1 again by echo 1 
/sys/devices/system/cpu/cpu1/online, the system will restore to 3
random status: hang, normal, panic.

Using  Linaro 11.11 release, echo 0 
/sys/devices/system/cpu/cpu1/online will make system hang and the
whole system will not be able to reset by pressing reset key, the only
way to reset system is pulling out AV power.

i am sorry i can't get more time to debug and find more clues. just
want to ask people whether this is a version the cpuhotplug works
normal on?

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

Re: [PATCH 0/3] coupled cpuidle state support

2011-12-21 Thread Colin Cross

On Wed, Dec 21, 2011 at 1:02 AM, Arjan van de Ven ar...@linux.intel.com wrote:
 On 12/21/2011 1:09 AM, Colin Cross wrote:
 On some ARM SMP SoCs (OMAP4460, Tegra 2, and probably more), the
 cpus cannot be independently powered down, either due to
 sequencing restrictions (on Tegra 2, cpu 0 must be the last to
 power down), or due to HW bugs (on OMAP4460, a cpu powering up
 will corrupt the gic state unless the other cpu runs a work
 around).  Each cpu has a power state that it can enter without
 coordinating with the other cpu (usually Wait For Interrupt, or
 WFI), and one or more coupled power states that affect blocks
 shared between the cpus (L2 cache, interrupt controller, and
 sometimes the whole SoC).  Entering a coupled power state must
 be tightly controlled on both cpus.

 The easiest solution to implementing coupled cpu power states is
 to hotplug all but one cpu whenever possible, usually using a
 cpufreq governor that looks at cpu load to determine when to
 enable the secondary cpus.  This causes problems, as hotplug is an
 expensive operation, so the number of hotplug transitions must be
 minimized, leading to very slow response to loads, often on the
 order of seconds.

 This patch series implements an alternative solution, where each
 cpu will wait in the WFI state until all cpus are ready to enter
 a coupled state, at which point the coupled state function will
 be called on all cpus at approximately the same time.

 Once all cpus are ready to enter idle, they are woken by an smp
 cross call.  At this point, there is a chance that one of the
 cpus will find work to do, and choose not to enter suspend.  A
 final pass is needed to guarantee that all cpus will call the
 power state enter function at the same time.  During this pass,
 each cpu will increment the ready counter, and continue once the
 ready counter matches the number of online coupled cpus.  If any
 cpu exits idle, the other cpus will decrement their counter and
 retry.

 this smells fundamentally racey to me; you can get an interrupt one
 cycle after you think you're done, but before the last guy enters WFI...

 how do you solve that issue ?

All the cpus have interrupts off when they increment the counter, so
they cannot receive an interrupt.  If an interrupt is pending on one
of those cpus, it will be handled later when WFI aborts due to the
pending interrupt.
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 0/3] coupled cpuidle state support

2011-12-21 Thread Arjan van de Ven

On 12/21/2011 10:40 AM, Colin Cross wrote:

 this smells fundamentally racey to me; you can get an interrupt one
 cycle after you think you're done, but before the last guy enters WFI...

 how do you solve that issue ?
 
 All the cpus have interrupts off when they increment the counter, so
 they cannot receive an interrupt.  If an interrupt is pending on one
 of those cpus, it will be handled later when WFI aborts due to the
 pending interrupt.

... but this leads to cases where you're aborting before other cpus are
entering. so your last guy in doesn't really work, since while cpu
0 thinks it's the last guy, cpu 1 is already on the way out/out
already...  (heck it might already be going back to sleep if your idle
code can run fast, like in the size of a cache miss)
--
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: Is Pandaboard cpuhotplug working stably?

2011-12-21 Thread Russell King - ARM Linux

On Wed, Dec 21, 2011 at 05:23:48PM +0800, Barry Song wrote:
 Hi guys,
 i tried cpuhotplug on pandaboard for both
 Pandroid_Froyo_L27.8.2_release_pkg and Linaro 11.11. It has failed to
 work stably.
 On Pandroid_Froyo_L27.8.2_release_pkg, unplugging cpu1 works well:
 # echo 0  /sys/devices/system/cpu/cpu1/online
 CPU1: shutdown
 
 if i enable the cpu1 again by echo 1 
 /sys/devices/system/cpu/cpu1/online, the system will restore to 3
 random status: hang, normal, panic.
 
 Using  Linaro 11.11 release, echo 0 
 /sys/devices/system/cpu/cpu1/online will make system hang and the
 whole system will not be able to reset by pressing reset key, the only
 way to reset system is pulling out AV power.
 
 i am sorry i can't get more time to debug and find more clues. just
 want to ask people whether this is a version the cpuhotplug works
 normal on?

cpu hotplug is basically totally buggered - the preconditions placed
upon the bringup code path are basically impossible to satisfy in any
shape or form at the moment.

There's the requirement that the secondary CPU is marked online and
active before interrupts are enabled for the thread migration stuff
to behave correctly.  However, this is incompatible with smp_call_function()
which will wait for online CPUs to respond to an IPI - which this one
won't because interrupts are disabled.

I think there was some discussion about how to fix this but I don't
recall the details.
--
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] am35xx-emac: move generic EMAC init to separate file

2011-12-21 Thread Hiremath, Vaibhav

 -Original Message-
 From: Ilya Yanok [mailto:ya...@emcraft.com]
 Sent: Wednesday, December 21, 2011 2:45 PM
 To: Hiremath, Vaibhav
 Cc: linux-omap@vger.kernel.org; sash...@emcraft.com
 Subject: Re: [PATCH V2] am35xx-emac: move generic EMAC init to separate
 file

 Hi,

 On 21.12.2011 10:07, Hiremath, Vaibhav wrote:
  +static struct resource am35xx_mdio_resources[] = {
  +  {
  +  .start  = AM35XX_IPSS_EMAC_BASE + AM35XX_EMAC_MDIO_OFFSET,
  +  .end= AM35XX_IPSS_EMAC_BASE + AM35XX_EMAC_MDIO_OFFSET +
  +SZ_4K - 1,
  +  .flags  = IORESOURCE_MEM,
  +  },
  +};
  This will not be board independent, using AM35xx everywhere.

 Why? It will work for any AM35XX based board. Probably we can try and
 make it work with EMACs on other AM3XXXs but I don't have these devices.

  To make it completely board independent, you should get all this
 platform
  specific data from board file. Probably have emac_init() function here
 and
  pass the data.

 Hm.. This data is SoC-dependent not board-dependent, what's the reason
 to move it to the board file?

[Hiremath, Vaibhav] My bad. I got confused between 3530 and AM35x...
Yeup, this is SoC specific thing for AM3517/05 device.

Thanks,
Vaibhav

  Do you know any other platform or device using this IP?

 Yes, I have a couple of AM3517 based boards that use this IP.

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

Re: [PATCH 0/3] coupled cpuidle state support

2011-12-21 Thread Colin Cross

On Wed, Dec 21, 2011 at 1:44 AM, Arjan van de Ven ar...@linux.intel.com wrote:
 On 12/21/2011 10:40 AM, Colin Cross wrote:

 this smells fundamentally racey to me; you can get an interrupt one
 cycle after you think you're done, but before the last guy enters WFI...

 how do you solve that issue ?

 All the cpus have interrupts off when they increment the counter, so
 they cannot receive an interrupt.  If an interrupt is pending on one
 of those cpus, it will be handled later when WFI aborts due to the
 pending interrupt.

 ... but this leads to cases where you're aborting before other cpus are
 entering. so your last guy in doesn't really work, since while cpu
 0 thinks it's the last guy, cpu 1 is already on the way out/out
 already...  (heck it might already be going back to sleep if your idle
 code can run fast, like in the size of a cache miss)

Once a cpu has incremented the counter, it has no way out unless either
1: another cpu (that hasn't incremented the counter yet) receives an
interrupt, aborts idle, and clears its idle flag
or
2: all cpus enter the ready counter, and call the cpuidle driver's
enter function.

In your example, cpu 1 has incremented the counter, so it cannot be on
the way out unless cpu 0 aborts (in which case it will not increment
the counter, and the counter will never be equal to the number of
cpus), or unless cpu 0 turns off its interrupts and incrementes the
counter (in which case neither cpu can return until after the cpuidle
driver's enter function has been called on all cpus).
--
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: Is Pandaboard cpuhotplug working stably?

2011-12-21 Thread Barry Song

2011/12/21 Russell King - ARM Linux li...@arm.linux.org.uk:
 On Wed, Dec 21, 2011 at 05:23:48PM +0800, Barry Song wrote:
 Hi guys,
 i tried cpuhotplug on pandaboard for both
 Pandroid_Froyo_L27.8.2_release_pkg and Linaro 11.11. It has failed to
 work stably.
 On Pandroid_Froyo_L27.8.2_release_pkg, unplugging cpu1 works well:
 # echo 0  /sys/devices/system/cpu/cpu1/online
 CPU1: shutdown

 if i enable the cpu1 again by echo 1 
 /sys/devices/system/cpu/cpu1/online, the system will restore to 3
 random status: hang, normal, panic.

 Using  Linaro 11.11 release, echo 0 
 /sys/devices/system/cpu/cpu1/online will make system hang and the
 whole system will not be able to reset by pressing reset key, the only
 way to reset system is pulling out AV power.

 i am sorry i can't get more time to debug and find more clues. just
 want to ask people whether this is a version the cpuhotplug works
 normal on?

 cpu hotplug is basically totally buggered - the preconditions placed
 upon the bringup code path are basically impossible to satisfy in any
 shape or form at the moment.

 There's the requirement that the secondary CPU is marked online and
 active before interrupts are enabled for the thread migration stuff
 to behave correctly.  However, this is incompatible with smp_call_function()
 which will wait for online CPUs to respond to an IPI - which this one
 won't because interrupts are disabled.

 I think there was some discussion about how to fix this but I don't
 recall the details.

thanks, Russell. then could i think this is an ARM-kernel-specific bug
which exists on all ARM SMP chips for the moment?
and that bug doesn't happen on x86:
root@ubuntu:~/simple-rootfs/initrd/bin# echo 0 
/sys/devices/system/cpu/cpu3/online
root@ubuntu:~/simple-rootfs/initrd/bin# echo 1 
/sys/devices/system/cpu/cpu3/online
root@ubuntu:~/simple-rootfs/initrd/bin# echo 0 
/sys/devices/system/cpu/cpu2/online
root@ubuntu:~/simple-rootfs/initrd/bin# echo 1 
/sys/devices/system/cpu/cpu2/online

-barry
--
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: Is Pandaboard cpuhotplug working stably?

2011-12-21 Thread Russell King - ARM Linux

On Wed, Dec 21, 2011 at 05:59:07PM +0800, Barry Song wrote:
 2011/12/21 Russell King - ARM Linux li...@arm.linux.org.uk:
  cpu hotplug is basically totally buggered - the preconditions placed
  upon the bringup code path are basically impossible to satisfy in any
  shape or form at the moment.
 
  There's the requirement that the secondary CPU is marked online and
  active before interrupts are enabled for the thread migration stuff
  to behave correctly.  However, this is incompatible with smp_call_function()
  which will wait for online CPUs to respond to an IPI - which this one
  won't because interrupts are disabled.
 
  I think there was some discussion about how to fix this but I don't
  recall the details.
 
 thanks, Russell. then could i think this is an ARM-kernel-specific bug
 which exists on all ARM SMP chips for the moment?
 and that bug doesn't happen on x86:

I don't think so.  There's nothing ARM specific about it.
--
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: ZOOM2 doesn't boot on upstream kernel

2011-12-21 Thread Deepthi Kiran

Thanks for ur response,

Iam using omap 3430 processor for the custom board, for 32 kernel  tty port of 
console was ttyO3 only, I have enabled DEBUG_LL also, and I am using putc 
function of uncompress.h file to print early prints. Iam suppose to work on the 
custom board in which UART address and data lines are made reverse, so if the 
address is 0x01 then I need to send address as 0x04 and simillary data, so I 
can not use direct early prink . So in the putc function, Iam reversing the 
address and data and trying to print. Control is not even coming up to 
start_kernel of init/main.c,I think after uncompressing and relocating of the 
kernel, it is struck..
I tried directly on zoom2 board also, noting was happening. One more thing I 
observed was I used Panda configuration and changed MACH_ZOOM3 and tried on 
zoom3 board, kernel at least booted on zoom3 board.
Do we have any specific 35 kernel tested for zoom2 or zoom3, if so please let 
me know the path..


-Original Message-
From: Tony Lindgren [mailto:t...@atomide.com]
Sent: Saturday, December 17, 2011 2:23 AM
To: Deepthi Kiran
Cc: linux-omap@vger.kernel.org
Subject: Re: ZOOM2 doesn't boot on upstream kernel

Hi,

* deepthi deepthi_ki...@mindtree.com [111215 23:03]:

 Hi,

 We are trying to boot 35 kernel on zoom2,I tried with android_zoom3
 config and choosing MACH as zoom2 and also with omap_zoom2_defconfig,
 kernel is not booting at all,it is struck after Starting kernel ...

 Uncompressing Linux...
  done, booting the kernel.

 I have taken the omap4 panda release kernel for gingerbread.
 Image name it is showing as Linux-2.6.35.7-00371-gcfb80c7-di

 Please let me know Which kernel we have to take for zoom2 35.
 I have tried with following bootargs
 setenv bootargs console=ttyS3,115200n8 mem=256M  root=/dev/mmcblk0p2
 rootdelay=1 init=/init omap_vout.video1_numbuffers=6
 omap_vout.vid1_static_vrfb_alloc=y
 omapfb.vram=0:4M

Can you please enable CONFIG_DEBUG_LL and CONFIG_EARLY_PRINTK in your .config? 
Then also append earlyprintk to the bootargs above. Then you should see more 
info on what goes wrong.

 I even tried with ttyO3 also.
 What should be the exact console should it be ttyO0?

I'm suspecting you should use ttyS0 as the console instead of ttyS3? That's at 
least what I have on my zoom3 board with the extra debug board.

You should use ttyO for the omap ports, but zoom debug board has external 8250 
ftdi ports, so those show up as ttyS and not ttyO.

Regards,

Tony



http://www.mindtree.com/email/disclaimer.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 0/3] coupled cpuidle state support

2011-12-21 Thread Arjan van de Ven

On 12/21/2011 10:55 AM, Colin Cross wrote:
 On Wed, Dec 21, 2011 at 1:44 AM, Arjan van de Ven ar...@linux.intel.com 
 wrote:
 On 12/21/2011 10:40 AM, Colin Cross wrote:

 this smells fundamentally racey to me; you can get an interrupt one
 cycle after you think you're done, but before the last guy enters WFI...

 how do you solve that issue ?

 All the cpus have interrupts off when they increment the counter, so
 they cannot receive an interrupt.  If an interrupt is pending on one
 of those cpus, it will be handled later when WFI aborts due to the
 pending interrupt.

 ... but this leads to cases where you're aborting before other cpus are
 entering. so your last guy in doesn't really work, since while cpu
 0 thinks it's the last guy, cpu 1 is already on the way out/out
 already...  (heck it might already be going back to sleep if your idle
 code can run fast, like in the size of a cache miss)
 
 Once a cpu has incremented the counter, it has no way out unless either
 1: another cpu (that hasn't incremented the counter yet) receives an
 interrupt, aborts idle, and clears its idle flag
 or
 2: all cpus enter the ready counter, and call the cpuidle driver's
 enter function.

.. or it enters WFI, and a physical device sends it an interrupt,
at which point it exits.
--
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 V3 0/2] Support for HTKW mcx

2011-12-21 Thread Ilya Yanok

plit into two parts:
 1. Device tree only to be used with board-generic (only serial works)
 2. Full board support via custom machine file for board-testing

Ilya Yanok (2):
  mcx: very basic support for HTKW mcx board
  mcx: support for HTKW mcx board

 arch/arm/boot/dts/mcx.dts|   27 ++
 arch/arm/mach-omap2/Kconfig  |6 +
 arch/arm/mach-omap2/Makefile |1 +
 arch/arm/mach-omap2/board-mcx.c  |  500 ++
 arch/arm/plat-omap/include/plat/uncompress.h |1 +
 5 files changed, 535 insertions(+), 0 deletions(-)
 create mode 100644 arch/arm/boot/dts/mcx.dts
 create mode 100644 arch/arm/mach-omap2/board-mcx.c

-- 
1.7.6.4

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

[PATCH V3 1/2] mcx: very basic support for HTKW mcx board

2011-12-21 Thread Ilya Yanok

Very basic support for HTKW mcx board. Able to boot via board-generic
and ramdisk/initramfs, however most of peripherals is unsupported.
Produces tons of twl4030 related errors as this board doesn't have
twl4030 installed.

Signed-off-by: Ilya Yanok ya...@emcraft.com

---
Changes from V2:

 - None

Changes from V1:

 - device tree move to the separate patch
 - iva node is disabled instead of using custom includes
 - removed bootargs entry

 arch/arm/boot/dts/mcx.dts |   27 +++
 1 files changed, 27 insertions(+), 0 deletions(-)
 create mode 100644 arch/arm/boot/dts/mcx.dts

diff --git a/arch/arm/boot/dts/mcx.dts b/arch/arm/boot/dts/mcx.dts
new file mode 100644
index 000..66b81bd
--- /dev/null
+++ b/arch/arm/boot/dts/mcx.dts
@@ -0,0 +1,27 @@
+/*
+ * Copyright (C) 2011 Ilya Yanok, EmCraft Systems
+ *
+ * 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.
+ */
+/dts-v1/;
+
+/include/ omap3.dtsi
+
+/ {
+   model = HTKW mcx;
+   compatible = htkw,mcx, ti,omap3;
+
+   memory {
+   device_type = memory;
+   reg = 0x8000 0x1000; /* 256 MB */
+   };
+
+   /* AM35xx doesn't have IVA */
+   soc {
+   iva {
+   status = disabled;
+   };
+   };
+};
-- 
1.7.6.4

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

[PATCH V3 2/2] mcx: support for HTKW mcx board

2011-12-21 Thread Ilya Yanok

Support for the HTKW mcx board (TI AM3517 based) including serial,
Ethernet, I2C, USB host, HSMMC, DSS and RTC.

Signed-off-by: Ilya Yanok ya...@emcraft.com

---
Requires updated machine-type file, recently posted AM35xx-EMAC patch
and Disable PM init on AM35{05,17} patch.

Changes from V2:
 - Rebased onto the current linux-omap/master
  - Added common.h include
  - Added .handle_irq field to machine description
  - Added omap_sdrc_init() call
 - Removed unneeded pullup from output pins
 - Moved pin muxing before GPIO accesses
 - Removed .ocr_mask field (it's overwritten anyway)
 - Moved touchscreen init out of I2C init
 - some readability improvements (empty lines, comments)

Changes from V1:
 - Kconfig option name fixed
 - Makefile entry sanitized
 - Unneeded headers removed
 - EMAC initialization moved to separate file/patch
 - Use gpio_{request,free}_{array,one} where possible
 - don't use platform data for touchscreen, we only need to pass
   irq number, do it via client.irq
 - check mcx_ts_init return value
 - Moved DEBUG_LL_OMAP3 entry to be in aplhabetical order
 - check return value of gpio_request for USB pwr pin
 - use pr_err instead of printk for error printing
 - added a fixed regulator for vdds_dsi
 - added SDcard card-detect pin

 arch/arm/mach-omap2/Kconfig  |6 +
 arch/arm/mach-omap2/Makefile |1 +
 arch/arm/mach-omap2/board-mcx.c  |  500 ++
 arch/arm/plat-omap/include/plat/uncompress.h |1 +
 4 files changed, 508 insertions(+), 0 deletions(-)
 create mode 100644 arch/arm/mach-omap2/board-mcx.c

diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig
index 0eb27b2..fd9b8c0 100644
--- a/arch/arm/mach-omap2/Kconfig
+++ b/arch/arm/mach-omap2/Kconfig
@@ -231,6 +231,12 @@ config MACH_OMAP_3430SDP
default y
select OMAP_PACKAGE_CBB
 
+config MACH_MCX
+   bool HTKW mcx (AM3517 based) board
+   depends on ARCH_OMAP3
+   select OMAP_PACKAGE_CBB
+   select REGULATOR_FIXED_VOLTAGE
+
 config MACH_NOKIA_N800
bool
 
diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index 5d75cb5..9405dfc 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -238,6 +238,7 @@ obj-$(CONFIG_MACH_CRANEBOARD)   += 
board-am3517crane.o
 obj-$(CONFIG_MACH_SBC3530) += board-omap3stalker.o
 obj-$(CONFIG_MACH_TI8168EVM)   += board-ti8168evm.o
 obj-$(CONFIG_MACH_TI8148EVM)   += board-ti8168evm.o
+obj-$(CONFIG_MACH_MCX) += board-mcx.o
 
 # Platform specific device init code
 
diff --git a/arch/arm/mach-omap2/board-mcx.c b/arch/arm/mach-omap2/board-mcx.c
new file mode 100644
index 000..70c4339
--- /dev/null
+++ b/arch/arm/mach-omap2/board-mcx.c
@@ -0,0 +1,500 @@
+/*
+ * Copyright (C) 2011 Ilya Yanok, Emcraft Systems
+ *
+ * Modified from mach-omap2/board-omap3beagle.c
+ *
+ * Initial code: Syed Mohammed Khasim
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include linux/gpio.h
+#include linux/mtd/partitions.h
+#include linux/mtd/nand.h
+#include linux/mmc/host.h
+#include linux/regulator/fixed.h
+#include linux/regulator/machine.h
+
+#include asm/mach-types.h
+#include asm/mach/arch.h
+
+#include plat/common.h
+#include video/omapdss.h
+#include video/omap-panel-generic-dpi.h
+#include plat/usb.h
+
+#include am35xx-emac.h
+#include mux.h
+#include control.h
+#include hsmmc.h
+#include common-board-devices.h
+#include common.h
+
+#define MCX_MDIO_FREQUENCY (100)
+
+static struct mtd_partition mcx_nand_partitions[] = {
+   /* All the partition sizes are listed in terms of NAND block size */
+   {
+   .name   = X-Loader,
+   .offset = 0,
+   .size   = 4 * NAND_BLOCK_SIZE,
+   .mask_flags = MTD_WRITEABLE,/* force read-only */
+   },
+   {
+   .name   = U-Boot,
+   .offset = MTDPART_OFS_APPEND,   /* Offset = 0x8 */
+   .size   = 15 * NAND_BLOCK_SIZE,
+   .mask_flags = MTD_WRITEABLE,/* force read-only */
+   },
+   {
+   .name   = U-Boot Env,
+   .offset = MTDPART_OFS_APPEND,   /* Offset = 0x26 */
+   .size   = 1 * NAND_BLOCK_SIZE,
+   },
+   {
+   .name   = Kernel,
+   .offset = MTDPART_OFS_APPEND,   /* Offset = 0x28 */
+   .size   = 32 * NAND_BLOCK_SIZE,
+   },
+   {
+   .name   = File System,
+   .offset = MTDPART_OFS_APPEND,   /* Offset = 0x68 */
+   .size   = MTDPART_SIZ_FULL,
+   },
+};
+
+#define LCD_PWR_ENn131
+#define

[PATCH V3 0/2] Support for HTKW mcx

2011-12-21 Thread Ilya Yanok

Split into two parts:
 1. Device tree only to be used with board-generic (only serial works)
 2. Full board support via custom machine file for board-testing

Sorry for double-posting: I've put wrong linux-arm-kernel address in
the first post.

Ilya Yanok (2):
  mcx: very basic support for HTKW mcx board
  mcx: support for HTKW mcx board

 arch/arm/boot/dts/mcx.dts|   27 ++
 arch/arm/mach-omap2/Kconfig  |6 +
 arch/arm/mach-omap2/Makefile |1 +
 arch/arm/mach-omap2/board-mcx.c  |  500 ++
 arch/arm/plat-omap/include/plat/uncompress.h |1 +
 5 files changed, 535 insertions(+), 0 deletions(-)
 create mode 100644 arch/arm/boot/dts/mcx.dts
 create mode 100644 arch/arm/mach-omap2/board-mcx.c

-- 
1.7.6.4

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

[PATCH V3 2/2] mcx: support for HTKW mcx board

2011-12-21 Thread Ilya Yanok

Support for the HTKW mcx board (TI AM3517 based) including serial,
Ethernet, I2C, USB host, HSMMC, DSS and RTC.

Signed-off-by: Ilya Yanok ya...@emcraft.com

---
Requires updated machine-type file, recently posted AM35xx-EMAC patch
and Disable PM init on AM35{05,17} patch.

Changes from V2:
 - Rebased onto the current linux-omap/master
  - Added common.h include
  - Added .handle_irq field to machine description
  - Added omap_sdrc_init() call
 - Removed unneeded pullup from output pins
 - Moved pin muxing before GPIO accesses
 - Removed .ocr_mask field (it's overwritten anyway)
 - Moved touchscreen init out of I2C init
 - some readability improvements (empty lines, comments)

Changes from V1:
 - Kconfig option name fixed
 - Makefile entry sanitized
 - Unneeded headers removed
 - EMAC initialization moved to separate file/patch
 - Use gpio_{request,free}_{array,one} where possible
 - don't use platform data for touchscreen, we only need to pass
   irq number, do it via client.irq
 - check mcx_ts_init return value
 - Moved DEBUG_LL_OMAP3 entry to be in aplhabetical order
 - check return value of gpio_request for USB pwr pin
 - use pr_err instead of printk for error printing
 - added a fixed regulator for vdds_dsi
 - added SDcard card-detect pin

 arch/arm/mach-omap2/Kconfig  |6 +
 arch/arm/mach-omap2/Makefile |1 +
 arch/arm/mach-omap2/board-mcx.c  |  500 ++
 arch/arm/plat-omap/include/plat/uncompress.h |1 +
 4 files changed, 508 insertions(+), 0 deletions(-)
 create mode 100644 arch/arm/mach-omap2/board-mcx.c

diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig
index 0eb27b2..fd9b8c0 100644
--- a/arch/arm/mach-omap2/Kconfig
+++ b/arch/arm/mach-omap2/Kconfig
@@ -231,6 +231,12 @@ config MACH_OMAP_3430SDP
default y
select OMAP_PACKAGE_CBB
 
+config MACH_MCX
+   bool HTKW mcx (AM3517 based) board
+   depends on ARCH_OMAP3
+   select OMAP_PACKAGE_CBB
+   select REGULATOR_FIXED_VOLTAGE
+
 config MACH_NOKIA_N800
bool
 
diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index 5d75cb5..9405dfc 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -238,6 +238,7 @@ obj-$(CONFIG_MACH_CRANEBOARD)   += 
board-am3517crane.o
 obj-$(CONFIG_MACH_SBC3530) += board-omap3stalker.o
 obj-$(CONFIG_MACH_TI8168EVM)   += board-ti8168evm.o
 obj-$(CONFIG_MACH_TI8148EVM)   += board-ti8168evm.o
+obj-$(CONFIG_MACH_MCX) += board-mcx.o
 
 # Platform specific device init code
 
diff --git a/arch/arm/mach-omap2/board-mcx.c b/arch/arm/mach-omap2/board-mcx.c
new file mode 100644
index 000..70c4339
--- /dev/null
+++ b/arch/arm/mach-omap2/board-mcx.c
@@ -0,0 +1,500 @@
+/*
+ * Copyright (C) 2011 Ilya Yanok, Emcraft Systems
+ *
+ * Modified from mach-omap2/board-omap3beagle.c
+ *
+ * Initial code: Syed Mohammed Khasim
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include linux/gpio.h
+#include linux/mtd/partitions.h
+#include linux/mtd/nand.h
+#include linux/mmc/host.h
+#include linux/regulator/fixed.h
+#include linux/regulator/machine.h
+
+#include asm/mach-types.h
+#include asm/mach/arch.h
+
+#include plat/common.h
+#include video/omapdss.h
+#include video/omap-panel-generic-dpi.h
+#include plat/usb.h
+
+#include am35xx-emac.h
+#include mux.h
+#include control.h
+#include hsmmc.h
+#include common-board-devices.h
+#include common.h
+
+#define MCX_MDIO_FREQUENCY (100)
+
+static struct mtd_partition mcx_nand_partitions[] = {
+   /* All the partition sizes are listed in terms of NAND block size */
+   {
+   .name   = X-Loader,
+   .offset = 0,
+   .size   = 4 * NAND_BLOCK_SIZE,
+   .mask_flags = MTD_WRITEABLE,/* force read-only */
+   },
+   {
+   .name   = U-Boot,
+   .offset = MTDPART_OFS_APPEND,   /* Offset = 0x8 */
+   .size   = 15 * NAND_BLOCK_SIZE,
+   .mask_flags = MTD_WRITEABLE,/* force read-only */
+   },
+   {
+   .name   = U-Boot Env,
+   .offset = MTDPART_OFS_APPEND,   /* Offset = 0x26 */
+   .size   = 1 * NAND_BLOCK_SIZE,
+   },
+   {
+   .name   = Kernel,
+   .offset = MTDPART_OFS_APPEND,   /* Offset = 0x28 */
+   .size   = 32 * NAND_BLOCK_SIZE,
+   },
+   {
+   .name   = File System,
+   .offset = MTDPART_OFS_APPEND,   /* Offset = 0x68 */
+   .size   = MTDPART_SIZ_FULL,
+   },
+};
+
+#define LCD_PWR_ENn131
+#define

[PATCH V3 1/2] mcx: very basic support for HTKW mcx board

2011-12-21 Thread Ilya Yanok

Very basic support for HTKW mcx board. Able to boot via board-generic
and ramdisk/initramfs, however most of peripherals is unsupported.
Produces tons of twl4030 related errors as this board doesn't have
twl4030 installed.

Signed-off-by: Ilya Yanok ya...@emcraft.com

---
Changes from V2:

 - None

Changes from V1:

 - device tree move to the separate patch
 - iva node is disabled instead of using custom includes
 - removed bootargs entry

 arch/arm/boot/dts/mcx.dts |   27 +++
 1 files changed, 27 insertions(+), 0 deletions(-)
 create mode 100644 arch/arm/boot/dts/mcx.dts

diff --git a/arch/arm/boot/dts/mcx.dts b/arch/arm/boot/dts/mcx.dts
new file mode 100644
index 000..66b81bd
--- /dev/null
+++ b/arch/arm/boot/dts/mcx.dts
@@ -0,0 +1,27 @@
+/*
+ * Copyright (C) 2011 Ilya Yanok, EmCraft Systems
+ *
+ * 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.
+ */
+/dts-v1/;
+
+/include/ omap3.dtsi
+
+/ {
+   model = HTKW mcx;
+   compatible = htkw,mcx, ti,omap3;
+
+   memory {
+   device_type = memory;
+   reg = 0x8000 0x1000; /* 256 MB */
+   };
+
+   /* AM35xx doesn't have IVA */
+   soc {
+   iva {
+   status = disabled;
+   };
+   };
+};
-- 
1.7.6.4

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

[PATCH] OMAP2+: ads7846_init: put gpio_pendown into pdata if it's provided

2011-12-21 Thread Ilya Yanok

If platform data is provided by the caller gpio_pendown is put into
unused static ads7846_config structure and effectively has no effect.
Of course caller can set gpio_pendown field in platform data himself
but it seems natural to do this in ads7846_init to remove duplication.

Signed-off-by: Ilya Yanok ya...@emcraft.com
---
 arch/arm/mach-omap2/common-board-devices.c |5 -
 1 files changed, 4 insertions(+), 1 deletions(-)

diff --git a/arch/arm/mach-omap2/common-board-devices.c 
b/arch/arm/mach-omap2/common-board-devices.c
index 2d1d775..eb408dd 100644
--- a/arch/arm/mach-omap2/common-board-devices.c
+++ b/arch/arm/mach-omap2/common-board-devices.c
@@ -75,7 +75,10 @@ void __init omap_ads7846_init(int bus_num, int gpio_pendown, 
int gpio_debounce,
gpio_set_debounce(gpio_pendown, gpio_debounce);
}
 
-   ads7846_config.gpio_pendown = gpio_pendown;
+   if (!board_pdata)
+   ads7846_config.gpio_pendown = gpio_pendown;
+   else
+   board_pdata-gpio_pendown = gpio_pendown;
 
spi_bi-bus_num = bus_num;
spi_bi-irq = OMAP_GPIO_IRQ(gpio_pendown);
-- 
1.7.6.4

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

Re: [PATCH] OMAP2+: ads7846_init: put gpio_pendown into pdata if it's provided

2011-12-21 Thread Igor Grinberg

Hi Ilya,

Please, Cc the linux-arm-ker...@lists.infradead.org for patches,
so Tony, or whoever will not need to resend them...

On 12/21/11 18:31, Ilya Yanok wrote:
 If platform data is provided by the caller gpio_pendown is put into
 unused static ads7846_config structure and effectively has no effect.
 Of course caller can set gpio_pendown field in platform data himself
 but it seems natural to do this in ads7846_init to remove duplication.
 
 Signed-off-by: Ilya Yanok ya...@emcraft.com
 ---
  arch/arm/mach-omap2/common-board-devices.c |5 -
  1 files changed, 4 insertions(+), 1 deletions(-)
 
 diff --git a/arch/arm/mach-omap2/common-board-devices.c 
 b/arch/arm/mach-omap2/common-board-devices.c
 index 2d1d775..eb408dd 100644
 --- a/arch/arm/mach-omap2/common-board-devices.c
 +++ b/arch/arm/mach-omap2/common-board-devices.c
 @@ -75,7 +75,10 @@ void __init omap_ads7846_init(int bus_num, int 
 gpio_pendown, int gpio_debounce,
   gpio_set_debounce(gpio_pendown, gpio_debounce);
   }
  
 - ads7846_config.gpio_pendown = gpio_pendown;
 + if (!board_pdata)
 + ads7846_config.gpio_pendown = gpio_pendown;
 + else
 + board_pdata-gpio_pendown = gpio_pendown;
  
   spi_bi-bus_num = bus_num;
   spi_bi-irq = OMAP_GPIO_IRQ(gpio_pendown);

The fact that the ads7846_config has no effect in case
the board_pdata is provided does not really meter...
How about reusing the existing if instead of adding another one?
Like in the attached patch?


-- 
Regards,
Igor.
diff --git a/arch/arm/mach-omap2/common-board-devices.c b/arch/arm/mach-omap2/common-board-devices.c
index 94ccf46..e8a7368 100644
--- a/arch/arm/mach-omap2/common-board-devices.c
+++ b/arch/arm/mach-omap2/common-board-devices.c
@@ -102,8 +102,10 @@ void __init omap_ads7846_init(int bus_num, int gpio_pendown, int gpio_debounce,
 	spi_bi-bus_num	= bus_num;
 	spi_bi-irq	= OMAP_GPIO_IRQ(gpio_pendown);
 
-	if (board_pdata)
+	if (board_pdata) {
+		board_pdata-gpio_pendown = gpio_pendown;
 		spi_bi-platform_data = board_pdata;
+	}
 
 	spi_register_board_info(ads7846_spi_board_info, 1);
 }

Re: Adding remoteproc/rpmsg to linux-next

2011-12-21 Thread Ohad Ben-Cohen

Hi Arnd,

On Mon, Dec 12, 2011 at 1:33 AM, Stephen Rothwell s...@canb.auug.org.au wrote:
 On Fri, 9 Dec 2011 16:55:27 +0200 Ohad Ben-Cohen o...@wizery.com wrote:

 Can you please add the following remoteproc tree to linux-next ?

 git://git.kernel.org/pub/scm/linux/kernel/git/ohad/remoteproc.git for-next

 I have added that from today.

Would you like rpmsg/remoteproc to go through arm-soc or do you prefer
me to send a pull request directly to Linus ?

If you prefer the former (IIRC you told me you might consider it in a
random ELCE hallway conversation :) then I'll send you a pull request.

I'm happy either way.

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

Re: [PATCH] OMAP2+: ads7846_init: put gpio_pendown into pdata if it's provided

2011-12-21 Thread Ilya Yanok

Hi Igor,

On 21.12.2011 21:22, Igor Grinberg wrote:
 Please, Cc the linux-arm-ker...@lists.infradead.org for patches,
 so Tony, or whoever will not need to resend them...

Uh.. Actually I thought that linux-omap ML is a good place for really
OMAP-specific patches like this one and there is no much sense posting
such patches into the main ARM list...

Ok, I will Cc linux-arm-kernel in future.

 If platform data is provided by the caller gpio_pendown is put into
 unused static ads7846_config structure and effectively has no effect.
 Of course caller can set gpio_pendown field in platform data himself
 but it seems natural to do this in ads7846_init to remove duplication.

 Signed-off-by: Ilya Yanok ya...@emcraft.com
 ---
  arch/arm/mach-omap2/common-board-devices.c |5 -
  1 files changed, 4 insertions(+), 1 deletions(-)

 diff --git a/arch/arm/mach-omap2/common-board-devices.c 
 b/arch/arm/mach-omap2/common-board-devices.c
 index 2d1d775..eb408dd 100644
 --- a/arch/arm/mach-omap2/common-board-devices.c
 +++ b/arch/arm/mach-omap2/common-board-devices.c
 @@ -75,7 +75,10 @@ void __init omap_ads7846_init(int bus_num, int 
 gpio_pendown, int gpio_debounce,
  gpio_set_debounce(gpio_pendown, gpio_debounce);
  }
  
 -ads7846_config.gpio_pendown = gpio_pendown;
 +if (!board_pdata)
 +ads7846_config.gpio_pendown = gpio_pendown;
 +else
 +board_pdata-gpio_pendown = gpio_pendown;
  
  spi_bi-bus_num = bus_num;
  spi_bi-irq = OMAP_GPIO_IRQ(gpio_pendown);
 
 The fact that the ads7846_config has no effect in case
 the board_pdata is provided does not really meter...
 How about reusing the existing if instead of adding another one?
 Like in the attached patch?

Yes, I think your version is a bit clearer. Probably it makes to add
else clause and move ads7846_config.gpio_pendown assignment under it.

Regards, Ilya.
--
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/10] OMAP4: ASoC: Support for PandaBoard family

2011-12-21 Thread Liam Girdwood

On Wed, 2011-12-14 at 11:46 +0200, Peter Ujfalusi wrote:
 Hello,
 
 the following series will add ASoC support for PandaBoards.
 PandaBoards have different audio routings compared to SDP4430/Blaze boards, 
 but
 the differences not that big to justify a new ASoC machine driver.
 
 Main changes:
 - Rename the sdp4430 ASoC machine driver to use generic name: omap-abe-twl6040
 - Convert the ASoC machine driver to platform driver
 - The type of the board, and the desired sound card name is passed via 
 platform
   data to the ASoC machine driver
 - Based on the board type the driver selects different audio routings
 - Registration of the needed platform devices in board files (sdp4403, panda)
 
 After this series the sound card names will be different for easier UCM
 integration:
 OMAP4-SDP4430 for SDP4430/Blaze boards
 OMAP4-Panda for PandaBoard 4430
 OMAP4-PandaES for PandaBoard ES (4460)
 

1,2,3 Applied.

5  8 depend on the others so best to resend with Acks if unchanged.

Thanks

Liam

--
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] ASoC: OMAP: ams-delta: Drive modem/codec pins over GPIO API

2011-12-21 Thread Liam Girdwood

On Sun, 2011-12-11 at 21:12 +0100, Janusz Krzysztofik wrote:
 Don't use Amstrad Delta custom I/O functions any longer, replace them
 with GPIO. Old pin definitions, no longer used by the modem bits either,
 can be dropped.
 
 Depends on patch 2/10 ARM: OMAP1: Convert Amstrad E3 latches to
 basic_mmio_gpio.
 
 Signed-off-by: Janusz Krzysztofik jkrzy...@tis.icnet.pl

Applied.

Thanks

Liam

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

Re: [PATCH 0/3] coupled cpuidle state support

2011-12-21 Thread Colin Cross

On Wed, Dec 21, 2011 at 4:12 AM, Arjan van de Ven ar...@linux.intel.com wrote:
 On 12/21/2011 10:55 AM, Colin Cross wrote:
 On Wed, Dec 21, 2011 at 1:44 AM, Arjan van de Ven ar...@linux.intel.com 
 wrote:
 On 12/21/2011 10:40 AM, Colin Cross wrote:

 this smells fundamentally racey to me; you can get an interrupt one
 cycle after you think you're done, but before the last guy enters WFI...

 how do you solve that issue ?

 All the cpus have interrupts off when they increment the counter, so
 they cannot receive an interrupt.  If an interrupt is pending on one
 of those cpus, it will be handled later when WFI aborts due to the
 pending interrupt.

 ... but this leads to cases where you're aborting before other cpus are
 entering. so your last guy in doesn't really work, since while cpu
 0 thinks it's the last guy, cpu 1 is already on the way out/out
 already...  (heck it might already be going back to sleep if your idle
 code can run fast, like in the size of a cache miss)

 Once a cpu has incremented the counter, it has no way out unless either
 1: another cpu (that hasn't incremented the counter yet) receives an
 interrupt, aborts idle, and clears its idle flag
 or
 2: all cpus enter the ready counter, and call the cpuidle driver's
 enter function.

 .. or it enters WFI, and a physical device sends it an interrupt,
 at which point it exits.

None of the cpus will return to the idle loop until all cpus have
decremented the ready counter back to 0, so they can't wrap around
again.
--
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 1/7 v2] ARM: OMAP1: ams-delta: register latch dependent devices later

2011-12-21 Thread Tony Lindgren

* Janusz Krzysztofik jkrzy...@tis.icnet.pl [111220 13:23]:
 In preparation to converting Amstrad Delta on-board latches to
 basic_mmio_gpio devices, registration of platform devices which depend
 on latches and will require initialization of their GPIO pins first,
 should be moved out of .machine_init down to late_initcall level, as the
 gpio-generic driver is not available until device_initcall time.  The
 latch reset operation, which will be replaced with GPIO initialization,
 must also be moved to late_initcall for the same reason.
 
 Since there was already another, separate arch_initcall function for
 setting up one of those latch dependent devices, the on-board modem
 device, reuse that function, i.e., rename it to a name that matches the
 new purpose, extend with other device setup relocated from
 .machine_init, and move down to the late_initcall level.
 
 While being at it, add missing gpio_free() in case the modem platform
 device registration fails.
 
 Thanks to Tony Lindgren t...@atomide.com who suggested this approach
 instead of shifting up the gpio-generic driver initialization.
 
 In addition, defer registration of the Amstrad Delta ASoC and serio
 devices, done from their device driver files, until late_initcall time,
 as those drivers will depend on their GPIO pins already requested from
 the board late_init() function until updated to register their GPIO pins
 themselves.
 
 Created and tested against linux-3.2-rc6.
 
 Signed-off-by: Janusz Krzysztofik jkrzy...@tis.icnet.pl

Planning to apply this series. Dmitry, care to ack the drivers/input/serio/
related change?

Regards,

Tony

 ---
 Changes since the initial version of this patch:
 * use late_initcall() unconditionally in modules, requested by Russell
   King (thanks!); an updated patch 7/7 will follow,
 * in the changelog message, move credits to Tony up a bit, since the
   person responsible for other changes (he might not necessarily like)
   is me, not him ;).
 
 Comments copied from this patch initial submission:
 This patch was not present in the initial submission, it replaces the
 old patch 1/10, providing an alternative solution not touching the
 gpio-generic driver.
 
  arch/arm/mach-omap1/board-ams-delta.c |   28 
  drivers/input/serio/ams_delta_serio.c |2 +-
  sound/soc/omap/ams-delta.c|2 +-
  3 files changed, 22 insertions(+), 10 deletions(-)
 
 diff --git a/arch/arm/mach-omap1/board-ams-delta.c 
 b/arch/arm/mach-omap1/board-ams-delta.c
 index b0f15d2..50987c9 100644
 --- a/arch/arm/mach-omap1/board-ams-delta.c
 +++ b/arch/arm/mach-omap1/board-ams-delta.c
 @@ -275,11 +275,14 @@ static struct omap1_cam_platform_data 
 ams_delta_camera_platform_data = {
  };
  
  static struct platform_device *ams_delta_devices[] __initdata = {
 - ams_delta_nand_device,
   ams_delta_kp_device,
 + ams_delta_camera_device,
 +};
 +
 +static struct platform_device *late_devices[] __initdata = {
 + ams_delta_nand_device,
   ams_delta_lcd_device,
   ams_delta_led_device,
 - ams_delta_camera_device,
  };
  
  static void __init ams_delta_init(void)
 @@ -307,9 +310,6 @@ static void __init ams_delta_init(void)
   omap_serial_init();
   omap_register_i2c_bus(1, 100, NULL, 0);
  
 - /* Clear latch2 (NAND, LCD, modem enable) */
 - ams_delta_latch2_write(~0, 0);
 -
   omap1_usb_init(ams_delta_usb_config);
   omap1_set_camera_info(ams_delta_camera_platform_data);
  #ifdef CONFIG_LEDS_TRIGGERS
 @@ -345,13 +345,18 @@ static struct platform_device ams_delta_modem_device = {
   },
  };
  
 -static int __init ams_delta_modem_init(void)
 +static int __init late_init(void)
  {
   int err;
  
   if (!machine_is_ams_delta())
   return -ENODEV;
  
 + /* Clear latch2 (NAND, LCD, modem enable) */
 + ams_delta_latch2_write(~0, 0);
 +
 + platform_add_devices(late_devices, ARRAY_SIZE(late_devices));
 +
   omap_cfg_reg(M14_1510_GPIO2);
   ams_delta_modem_ports[0].irq =
   gpio_to_irq(AMS_DELTA_GPIO_PIN_MODEM_IRQ);
 @@ -367,9 +372,16 @@ static int __init ams_delta_modem_init(void)
   AMS_DELTA_LATCH2_MODEM_NRESET | AMS_DELTA_LATCH2_MODEM_CODEC,
   AMS_DELTA_LATCH2_MODEM_NRESET | AMS_DELTA_LATCH2_MODEM_CODEC);
  
 - return platform_device_register(ams_delta_modem_device);
 + err = platform_device_register(ams_delta_modem_device);
 + if (err)
 + goto gpio_free;
 + return 0;
 +
 +gpio_free:
 + gpio_free(AMS_DELTA_GPIO_PIN_MODEM_IRQ);
 + return err;
  }
 -arch_initcall(ams_delta_modem_init);
 +late_initcall(late_init);
  
  static void __init ams_delta_map_io(void)
  {
 diff --git a/drivers/input/serio/ams_delta_serio.c 
 b/drivers/input/serio/ams_delta_serio.c
 index d4d08bd..835d37a 100644
 --- a/drivers/input/serio/ams_delta_serio.c
 +++ b/drivers/input/serio/ams_delta_serio.c
 @@ -165,7 +165,7 @@ serio:
   kfree(ams_delta_serio);
   return

Re: [PATCH] input: serio: ams-delta: toggle keyboard power over GPIO

2011-12-21 Thread Tony Lindgren

* Janusz Krzysztofik jkrzy...@tis.icnet.pl [111220 13:39]:
 Don't use Amstrad Delta custom I/O functions once GPIO interface is
 available for the underlying hardware.
 
 While requesting and initializing GPIO pins used, also take care of one
 extra pin KEYBRD_DATAOUT which, even if not used by the driver, belongs
 to the device and affects its functioning.
 
 Once done, move the driver initialization back to the device_initcall
 level, reverting the temporary chane introduced with patch 1/7 ARM:
 OMAP1: ams-delta: register latch dependent devices later.  That change
 is no longer required once the driver takes care of registering used
 GPIO pins, and it's better to initialize the device before others using
 the latch2 based GPIO pins, otherwise a garbage is reported on boot,
 perhaps due to random data already captured by the FIQ handler while the
 keyboard related latch bits are written with random values during
 initialization of those other latch2 dependent devices.
 
 Depends on patch 2/7 ARM: OMAP1: ams-delta: convert latches to
 basic_mmio_gpio
 
 Signed-off-by: Janusz Krzysztofik jkrzy...@tis.icnet.pl

I'm assuming Dmitry's ack for an earlier version of this patch also
covers this one when applying.

Regards,

Tony

 ---
 Hi,
 I'm submitting only this one refreshed on top of updated 1/7. All others
 (2/7-6/7) don't require any refresh, can be rebased smoothly.
 
 Thanks,
 Janusz
 
 
 Changes against version 2:
 * refreshed on top of updated patch 1/7 v2,
 * changelog: corrected patch 1/7 summary (was inaccurate).
 
 Changes against initial version:
 * was 9/10,
 * rebased on top of v2 of patch 2/7, just in case,
 * moved AMS_DELTA_GPIO_PIN_KEYBRD_DATAOUT pin handling from the board
   code to the driver,
 * reverted a temporary change to the driver initcall level, introduced
   by the new solution provided with patch 1/7.
 
 
  arch/arm/mach-omap1/board-ams-delta.c |   10 
  arch/arm/plat-omap/include/plat/board-ams-delta.h |2 -
  drivers/input/serio/ams_delta_serio.c |   53 
 :x 3 files changed, 32 insertions(+), 33 deletions(-)
 
 diff --git a/arch/arm/mach-omap1/board-ams-delta.c 
 b/arch/arm/mach-omap1/board-ams-delta.c
 index 3aba8f9..673cf21 100644
 --- a/arch/arm/mach-omap1/board-ams-delta.c
 +++ b/arch/arm/mach-omap1/board-ams-delta.c
 @@ -227,16 +227,6 @@ static struct gpio latch_gpios[] __initconst = {
   .label  = dockit2,
   },
   {
 - .gpio   = AMS_DELTA_GPIO_PIN_KEYBRD_PWR,
 - .flags  = GPIOF_OUT_INIT_LOW,
 - .label  = keybrd_pwr,
 - },
 - {
 - .gpio   = AMS_DELTA_GPIO_PIN_KEYBRD_DATAOUT,
 - .flags  = GPIOF_OUT_INIT_LOW,
 - .label  = keybrd_dataout,
 - },
 - {
   .gpio   = AMS_DELTA_GPIO_PIN_SCARD_RSTIN,
   .flags  = GPIOF_OUT_INIT_LOW,
   .label  = scard_rstin,
 diff --git a/arch/arm/plat-omap/include/plat/board-ams-delta.h 
 b/arch/arm/plat-omap/include/plat/board-ams-delta.h
 index e9ad673..027e79e 100644
 --- a/arch/arm/plat-omap/include/plat/board-ams-delta.h
 +++ b/arch/arm/plat-omap/include/plat/board-ams-delta.h
 @@ -28,8 +28,6 @@
  
  #if defined (CONFIG_MACH_AMS_DELTA)
  
 -#define AMD_DELTA_LATCH2_KEYBRD_PWR  0x0100
 -#define AMD_DELTA_LATCH2_KEYBRD_DATA 0x0200
  #define AMD_DELTA_LATCH2_SCARD_RSTIN 0x0400
  #define AMD_DELTA_LATCH2_SCARD_CMDVCC0x0800
  #define AMS_DELTA_LATCH2_MODEM_NRESET0x1000
 diff --git a/drivers/input/serio/ams_delta_serio.c 
 b/drivers/input/serio/ams_delta_serio.c
 index 835d37a..ef1ec40 100644
 --- a/drivers/input/serio/ams_delta_serio.c
 +++ b/drivers/input/serio/ams_delta_serio.c
 @@ -92,8 +92,7 @@ static irqreturn_t ams_delta_serio_interrupt(int irq, void 
 *dev_id)
  static int ams_delta_serio_open(struct serio *serio)
  {
   /* enable keyboard */
 - ams_delta_latch2_write(AMD_DELTA_LATCH2_KEYBRD_PWR,
 - AMD_DELTA_LATCH2_KEYBRD_PWR);
 + gpio_set_value(AMS_DELTA_GPIO_PIN_KEYBRD_PWR, 1);
  
   return 0;
  }
 @@ -101,9 +100,32 @@ static int ams_delta_serio_open(struct serio *serio)
  static void ams_delta_serio_close(struct serio *serio)
  {
   /* disable keyboard */
 - ams_delta_latch2_write(AMD_DELTA_LATCH2_KEYBRD_PWR, 0);
 + gpio_set_value(AMS_DELTA_GPIO_PIN_KEYBRD_PWR, 0);
  }
  
 +static struct gpio _gpios[] __initconst_or_module = {
 + {
 + .gpio   = AMS_DELTA_GPIO_PIN_KEYBRD_DATA,
 + .flags  = GPIOF_DIR_IN,
 + .label  = serio-data,
 + },
 + {
 + .gpio   = AMS_DELTA_GPIO_PIN_KEYBRD_CLK,
 + .flags  = GPIOF_DIR_IN,
 + .label  = serio-clock,
 + },
 + {
 + .gpio   = AMS_DELTA_GPIO_PIN_KEYBRD_PWR,
 + .flags  = GPIOF_OUT_INIT_LOW,
 + .label  = serio-power,
 + },
 + {
 + .gpio   = AMS_DELTA_GPIO_PIN_KEYBRD_DATAOUT,
 + .flags  =

Re: [PATCH v2 5/7] MTD: NAND: ams-delta: use GPIO instead of custom I/O

2011-12-21 Thread Tony Lindgren

* Janusz Krzysztofik jkrzy...@tis.icnet.pl [111219 14:41]:
 Don't use Amstrad Delta custom I/O functions for controlling the device,
 use GPIO API instead.
 
 While being at it, add missing gpio_free(AMS_DELTA_GPIO_PIN_NAND_RB).
 
 Depends on patch 2/7 ARM: OMAP1: ams-delta: convert latches to
 basic_mmio_gpio
 
 Signed-off-by: Janusz Krzysztofik jkrzy...@tis.icnet.pl
 Cc: David Woodhouse dw...@infradead.org
 Cc: Tony Lindgren t...@atomide.com

Artem, care to ack this one?

Regards,

Tony


 ---
 Changes against initial version:
 * no functional changes,
 * rebased on top of v2 of patch 2/7, just in case.
 
 Comments copied from initial submission:
 
 Hi,
 I considered dropping the Amstrad Delta NAND driver and moving to either
 gpio-nand or gen_nand, but finally decided to keep it for now.
 
 The problem with the gpio-nand is that it seems to match a different
 hardware interface model. Having no knowledge about the original
 hardware that driver was designed in mind, I'd rather not try to
 modify it, and creating another GPIO based NAND driver also seems not
 a really good idea.
 
 If I decided to use gen_nand instead, I would have to move virtually all
 of the old driver callback functions somewhere under arch, either to the
 board file or to a new one, and still use some hacks unless either
 nand_base.c or plat_nand.c is modified.
 
 I'm willing to take one of those two approaches in a follow up series if
 I get a positive feedback.
 
 Thanks,
 Janusz
 
 
  arch/arm/mach-omap1/board-ams-delta.c |   30 
  arch/arm/plat-omap/include/plat/board-ams-delta.h |6 --
  drivers/mtd/nand/ams-delta.c  |   74 ++--
  3 files changed, 52 insertions(+), 58 deletions(-)
 
 diff --git a/arch/arm/mach-omap1/board-ams-delta.c 
 b/arch/arm/mach-omap1/board-ams-delta.c
 index 034d009..cc6f962 100644
 --- a/arch/arm/mach-omap1/board-ams-delta.c
 +++ b/arch/arm/mach-omap1/board-ams-delta.c
 @@ -237,36 +237,6 @@ static struct gpio latch_gpios[] __initconst = {
   .label  = lcd_ndisp,
   },
   {
 - .gpio   = AMS_DELTA_GPIO_PIN_NAND_NCE,
 - .flags  = GPIOF_OUT_INIT_LOW,
 - .label  = nand_nce,
 - },
 - {
 - .gpio   = AMS_DELTA_GPIO_PIN_NAND_NRE,
 - .flags  = GPIOF_OUT_INIT_LOW,
 - .label  = nand_nre,
 - },
 - {
 - .gpio   = AMS_DELTA_GPIO_PIN_NAND_NWP,
 - .flags  = GPIOF_OUT_INIT_LOW,
 - .label  = nand_nwp,
 - },
 - {
 - .gpio   = AMS_DELTA_GPIO_PIN_NAND_NWE,
 - .flags  = GPIOF_OUT_INIT_LOW,
 - .label  = nand_nwe,
 - },
 - {
 - .gpio   = AMS_DELTA_GPIO_PIN_NAND_ALE,
 - .flags  = GPIOF_OUT_INIT_LOW,
 - .label  = nand_ale,
 - },
 - {
 - .gpio   = AMS_DELTA_GPIO_PIN_NAND_CLE,
 - .flags  = GPIOF_OUT_INIT_LOW,
 - .label  = nand_cle,
 - },
 - {
   .gpio   = AMS_DELTA_GPIO_PIN_KEYBRD_PWR,
   .flags  = GPIOF_OUT_INIT_LOW,
   .label  = keybrd_pwr,
 diff --git a/arch/arm/plat-omap/include/plat/board-ams-delta.h 
 b/arch/arm/plat-omap/include/plat/board-ams-delta.h
 index a0f86ca..3e57833 100644
 --- a/arch/arm/plat-omap/include/plat/board-ams-delta.h
 +++ b/arch/arm/plat-omap/include/plat/board-ams-delta.h
 @@ -30,12 +30,6 @@
  
  #define AMS_DELTA_LATCH2_LCD_VBLEN   0x0001
  #define AMS_DELTA_LATCH2_LCD_NDISP   0x0002
 -#define AMS_DELTA_LATCH2_NAND_NCE0x0004
 -#define AMS_DELTA_LATCH2_NAND_NRE0x0008
 -#define AMS_DELTA_LATCH2_NAND_NWP0x0010
 -#define AMS_DELTA_LATCH2_NAND_NWE0x0020
 -#define AMS_DELTA_LATCH2_NAND_ALE0x0040
 -#define AMS_DELTA_LATCH2_NAND_CLE0x0080
  #define AMD_DELTA_LATCH2_KEYBRD_PWR  0x0100
  #define AMD_DELTA_LATCH2_KEYBRD_DATA 0x0200
  #define AMD_DELTA_LATCH2_SCARD_RSTIN 0x0400
 diff --git a/drivers/mtd/nand/ams-delta.c b/drivers/mtd/nand/ams-delta.c
 index 9e6b498..5769bd2 100644
 --- a/drivers/mtd/nand/ams-delta.c
 +++ b/drivers/mtd/nand/ams-delta.c
 @@ -26,7 +26,7 @@
  #include asm/io.h
  #include mach/hardware.h
  #include asm/sizes.h
 -#include asm/gpio.h
 +#include linux/gpio.h
  #include plat/board-ams-delta.h
  
  /*
 @@ -34,8 +34,6 @@
   */
  static struct mtd_info *ams_delta_mtd = NULL;
  
 -#define NAND_MASK (AMS_DELTA_LATCH2_NAND_NRE | AMS_DELTA_LATCH2_NAND_NWE | 
 AMS_DELTA_LATCH2_NAND_CLE | AMS_DELTA_LATCH2_NAND_ALE | 
 AMS_DELTA_LATCH2_NAND_NCE | AMS_DELTA_LATCH2_NAND_NWP)
 -
  /*
   * Define partitions for flash devices
   */
 @@ -68,10 +66,9 @@ static void ams_delta_write_byte(struct mtd_info *mtd, 
 u_char byte)
  
   writew(0, io_base + OMAP_MPUIO_IO_CNTL);
   writew(byte, this-IO_ADDR_W);
 - ams_delta_latch2_write(AMS_DELTA_LATCH2_NAND_NWE, 0);
 + gpio_set_value(AMS_DELTA_GPIO_PIN_NAND_NWE, 0);
   ndelay(40);
 - ams_delta_latch2_write(AMS_DELTA_LATCH2_NAND_NWE,
 -

Re: [PATCH 3/3] ARM: OMAP2+: board-generic: Replace #if defined by #ifdef for consistency

2011-12-21 Thread Tony Lindgren

* Cousson, Benoit b-cous...@ti.com [111220 04:48]:
 Hi Tony,
 
 What about that patch?
 
 This is the only one that is missing in lo.
 I know it is not a big deal, but it will make things a little bit cleaner.

I think we should wait on this one and combine it later on into
some other clean-up patch.

Regards,

Tony
 
 Thanks,
 Benoit
 
 On 12/6/2011 5:49 PM, Benoit Cousson wrote:
 The file contains a mix of #ifdef and #if defined().
 Replace the #if... by #ifdef.
 
 Signed-off-by: Benoit Coussonb-cous...@ti.com
 Cc: Tony Lindgrent...@atomide.com
 ---
   arch/arm/mach-omap2/board-generic.c |8 
   1 files changed, 4 insertions(+), 4 deletions(-)
 
 diff --git a/arch/arm/mach-omap2/board-generic.c 
 b/arch/arm/mach-omap2/board-generic.c
 index fb55fa3..09f44e0 100644
 --- a/arch/arm/mach-omap2/board-generic.c
 +++ b/arch/arm/mach-omap2/board-generic.c
 @@ -92,7 +92,7 @@ static void __init omap3_init(void)
   }
   #endif
 
 -#if defined(CONFIG_SOC_OMAP2420)
 +#ifdef CONFIG_SOC_OMAP2420
   static const char *omap242x_boards_compat[] __initdata = {
  ti,omap2420,
  NULL,
 @@ -110,7 +110,7 @@ DT_MACHINE_START(OMAP242X_DT, Generic OMAP2420 
 (Flattened Device Tree))
   MACHINE_END
   #endif
 
 -#if defined(CONFIG_SOC_OMAP2430)
 +#ifdef CONFIG_SOC_OMAP2430
   static const char *omap243x_boards_compat[] __initdata = {
  ti,omap2430,
  NULL,
 @@ -128,7 +128,7 @@ DT_MACHINE_START(OMAP243X_DT, Generic OMAP2430 
 (Flattened Device Tree))
   MACHINE_END
   #endif
 
 -#if defined(CONFIG_ARCH_OMAP3)
 +#ifdef CONFIG_ARCH_OMAP3
   static const char *omap3_boards_compat[] __initdata = {
  ti,omap3,
  NULL,
 @@ -146,7 +146,7 @@ DT_MACHINE_START(OMAP3_DT, Generic OMAP3 (Flattened 
 Device Tree))
   MACHINE_END
   #endif
 
 -#if defined(CONFIG_ARCH_OMAP4)
 +#ifdef CONFIG_ARCH_OMAP4
   static const char *omap4_boards_compat[] __initdata = {
  ti,omap4,
  NULL,
 
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 0/3] coupled cpuidle state support

2011-12-21 Thread Arjan van de Ven


 .. or it enters WFI, and a physical device sends it an interrupt,
 at which point it exits.
 
 None of the cpus will return to the idle loop until all cpus have
 decremented the ready counter back to 0, so they can't wrap around
 again.


yikes, so you IPI all the cpus on the first exit.
that must burn power ;-(
--
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: [linux-pm] [PATCH 0/3] coupled cpuidle state support

2011-12-21 Thread Colin Cross

On Wed, Dec 21, 2011 at 11:36 AM, Arjan van de Ven
ar...@linux.intel.com wrote:

 .. or it enters WFI, and a physical device sends it an interrupt,
 at which point it exits.

 None of the cpus will return to the idle loop until all cpus have
 decremented the ready counter back to 0, so they can't wrap around
 again.


 yikes, so you IPI all the cpus on the first exit.
 that must burn power ;-(

No, you're not understanding the point of this series.

If your cpus can go in and out of idle independently, you don't use
this code at all.  Each cpu can call WFI and come back out without
talking to the other cpu.

However, if you have two cpus that share some part of the SoC that can
be turned off in idle, like the L2 cache controller or the system bus,
the two cpus need to go to idle together, and they will both boot
together when either one receives an interrupt (although one will
likely immediately go back to a shallower state that doesn't require
coordination with the other cpu).  There is no way around this, it's
how the hardware works on some ARM platforms.
--
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 5/7] MTD: NAND: ams-delta: use GPIO instead of custom I/O

2011-12-21 Thread Janusz Krzysztofik

On Wednesday 21 of December 2011 at 20:12:12, Tony Lindgren wrote:
 * Janusz Krzysztofik jkrzy...@tis.icnet.pl [111219 14:41]:
  Don't use Amstrad Delta custom I/O functions for controlling the device,
  use GPIO API instead.
  
  While being at it, add missing gpio_free(AMS_DELTA_GPIO_PIN_NAND_RB).
  
  Depends on patch 2/7 ARM: OMAP1: ams-delta: convert latches to
  basic_mmio_gpio
  
  Signed-off-by: Janusz Krzysztofik jkrzy...@tis.icnet.pl
  Cc: David Woodhouse dw...@infradead.org
  Cc: Tony Lindgren t...@atomide.com
 
 Artem, care to ack this one?


BTW, following the get_maintainer.pl script suggestions, I tried to 
include Artem in the Cc: list, but that script provided me with an 
invalid Artem's email address at nokia.com, and I gave up once my email 
gateway refused to accept that message. Now I've verified that several 
half or more year old commits signed by Artem were the sources of that 
apparently outdated information. Looks like the get_maintainer.pl script 
needs improvement, or should be used with care by people who don't 
follow all email address changes ;).

Thanks,
Janusz
--
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 1/7 v2] ARM: OMAP1: ams-delta: register latch dependent devices later

2011-12-21 Thread Janusz Krzysztofik

On Wednesday 21 of December 2011 at 20:08:15, Tony Lindgren wrote:
 * Janusz Krzysztofik jkrzy...@tis.icnet.pl [111220 13:23]:
  In preparation to converting Amstrad Delta on-board latches to
  basic_mmio_gpio devices, registration of platform devices which depend
  on latches and will require initialization of their GPIO pins first,
  should be moved out of .machine_init down to late_initcall level, as the
  gpio-generic driver is not available until device_initcall time.  The
  latch reset operation, which will be replaced with GPIO initialization,
  must also be moved to late_initcall for the same reason.
  
  Since there was already another, separate arch_initcall function for
  setting up one of those latch dependent devices, the on-board modem
  device, reuse that function, i.e., rename it to a name that matches the
  new purpose, extend with other device setup relocated from
  .machine_init, and move down to the late_initcall level.
  
  While being at it, add missing gpio_free() in case the modem platform
  device registration fails.
  
  Thanks to Tony Lindgren t...@atomide.com who suggested this approach
  instead of shifting up the gpio-generic driver initialization.
  
  In addition, defer registration of the Amstrad Delta ASoC and serio
  devices, done from their device driver files, until late_initcall time,
  as those drivers will depend on their GPIO pins already requested from
  the board late_init() function until updated to register their GPIO pins
  themselves.
  
  Created and tested against linux-3.2-rc6.
  
  Signed-off-by: Janusz Krzysztofik jkrzy...@tis.icnet.pl
 
 Planning to apply this series. Dmitry, care to ack the drivers/input/serio/
 related change?

Don't we need Jarkko's or Mark's or Liam's ack as well for the change to 
the sound/soc/omap/ams-delta.c file?

Thanks,
Janusz

 Regards,
 
 Tony
 
  ---
  Changes since the initial version of this patch:
  * use late_initcall() unconditionally in modules, requested by Russell
King (thanks!); an updated patch 7/7 will follow,
  * in the changelog message, move credits to Tony up a bit, since the
person responsible for other changes (he might not necessarily like)
is me, not him ;).
  
  Comments copied from this patch initial submission:
  This patch was not present in the initial submission, it replaces the
  old patch 1/10, providing an alternative solution not touching the
  gpio-generic driver.
  
   arch/arm/mach-omap1/board-ams-delta.c |   28 
   drivers/input/serio/ams_delta_serio.c |2 +-
   sound/soc/omap/ams-delta.c|2 +-
   3 files changed, 22 insertions(+), 10 deletions(-)
  
  diff --git a/arch/arm/mach-omap1/board-ams-delta.c 
  b/arch/arm/mach-omap1/board-ams-delta.c
  index b0f15d2..50987c9 100644
  --- a/arch/arm/mach-omap1/board-ams-delta.c
  +++ b/arch/arm/mach-omap1/board-ams-delta.c
  @@ -275,11 +275,14 @@ static struct omap1_cam_platform_data 
  ams_delta_camera_platform_data = {
   };
   
   static struct platform_device *ams_delta_devices[] __initdata = {
  -   ams_delta_nand_device,
  ams_delta_kp_device,
  +   ams_delta_camera_device,
  +};
  +
  +static struct platform_device *late_devices[] __initdata = {
  +   ams_delta_nand_device,
  ams_delta_lcd_device,
  ams_delta_led_device,
  -   ams_delta_camera_device,
   };
   
   static void __init ams_delta_init(void)
  @@ -307,9 +310,6 @@ static void __init ams_delta_init(void)
  omap_serial_init();
  omap_register_i2c_bus(1, 100, NULL, 0);
   
  -   /* Clear latch2 (NAND, LCD, modem enable) */
  -   ams_delta_latch2_write(~0, 0);
  -
  omap1_usb_init(ams_delta_usb_config);
  omap1_set_camera_info(ams_delta_camera_platform_data);
   #ifdef CONFIG_LEDS_TRIGGERS
  @@ -345,13 +345,18 @@ static struct platform_device ams_delta_modem_device 
  = {
  },
   };
   
  -static int __init ams_delta_modem_init(void)
  +static int __init late_init(void)
   {
  int err;
   
  if (!machine_is_ams_delta())
  return -ENODEV;
   
  +   /* Clear latch2 (NAND, LCD, modem enable) */
  +   ams_delta_latch2_write(~0, 0);
  +
  +   platform_add_devices(late_devices, ARRAY_SIZE(late_devices));
  +
  omap_cfg_reg(M14_1510_GPIO2);
  ams_delta_modem_ports[0].irq =
  gpio_to_irq(AMS_DELTA_GPIO_PIN_MODEM_IRQ);
  @@ -367,9 +372,16 @@ static int __init ams_delta_modem_init(void)
  AMS_DELTA_LATCH2_MODEM_NRESET | AMS_DELTA_LATCH2_MODEM_CODEC,
  AMS_DELTA_LATCH2_MODEM_NRESET | AMS_DELTA_LATCH2_MODEM_CODEC);
   
  -   return platform_device_register(ams_delta_modem_device);
  +   err = platform_device_register(ams_delta_modem_device);
  +   if (err)
  +   goto gpio_free;
  +   return 0;
  +
  +gpio_free:
  +   gpio_free(AMS_DELTA_GPIO_PIN_MODEM_IRQ);
  +   return err;
   }
  -arch_initcall(ams_delta_modem_init);
  +late_initcall(late_init);
   
   static void __init ams_delta_map_io(void)
   {
  diff --git

Re: [PATCH] input: serio: ams-delta: toggle keyboard power over GPIO

2011-12-21 Thread Janusz Krzysztofik

On Wednesday 21 of December 2011 at 20:09:45, Tony Lindgren wrote:
 * Janusz Krzysztofik jkrzy...@tis.icnet.pl [111220 13:39]:
  Don't use Amstrad Delta custom I/O functions once GPIO interface is
  available for the underlying hardware.
  
  While requesting and initializing GPIO pins used, also take care of one
  extra pin KEYBRD_DATAOUT which, even if not used by the driver, belongs
  to the device and affects its functioning.
  
  Once done, move the driver initialization back to the device_initcall
  level, reverting the temporary chane introduced with patch 1/7 ARM:
  OMAP1: ams-delta: register latch dependent devices later.  That change
  is no longer required once the driver takes care of registering used
  GPIO pins, and it's better to initialize the device before others using
  the latch2 based GPIO pins, otherwise a garbage is reported on boot,
  perhaps due to random data already captured by the FIQ handler while the
  keyboard related latch bits are written with random values during
  initialization of those other latch2 dependent devices.
  
  Depends on patch 2/7 ARM: OMAP1: ams-delta: convert latches to
  basic_mmio_gpio
  
  Signed-off-by: Janusz Krzysztofik jkrzy...@tis.icnet.pl
 
 I'm assuming Dmitry's ack for an earlier version of this patch also
 covers this one when applying.

Hi Dmitry,
Can we assume your ack still valid for this version?

Thanks,
Janusz

 Regards,
 
 Tony
 
  ---
  Hi,
  I'm submitting only this one refreshed on top of updated 1/7. All others
  (2/7-6/7) don't require any refresh, can be rebased smoothly.
  
  Thanks,
  Janusz
  
  
  Changes against version 2:
  * refreshed on top of updated patch 1/7 v2,
  * changelog: corrected patch 1/7 summary (was inaccurate).
  
  Changes against initial version:
  * was 9/10,
  * rebased on top of v2 of patch 2/7, just in case,
  * moved AMS_DELTA_GPIO_PIN_KEYBRD_DATAOUT pin handling from the board
code to the driver,
  * reverted a temporary change to the driver initcall level, introduced
by the new solution provided with patch 1/7.
  
  
   arch/arm/mach-omap1/board-ams-delta.c |   10 
   arch/arm/plat-omap/include/plat/board-ams-delta.h |2 -
   drivers/input/serio/ams_delta_serio.c |   53 
  
  :x 3 files changed, 32 insertions(+), 33 deletions(-)
  
  diff --git a/arch/arm/mach-omap1/board-ams-delta.c 
  b/arch/arm/mach-omap1/board-ams-delta.c
  index 3aba8f9..673cf21 100644
  --- a/arch/arm/mach-omap1/board-ams-delta.c
  +++ b/arch/arm/mach-omap1/board-ams-delta.c
  @@ -227,16 +227,6 @@ static struct gpio latch_gpios[] __initconst = {
  .label  = dockit2,
  },
  {
  -   .gpio   = AMS_DELTA_GPIO_PIN_KEYBRD_PWR,
  -   .flags  = GPIOF_OUT_INIT_LOW,
  -   .label  = keybrd_pwr,
  -   },
  -   {
  -   .gpio   = AMS_DELTA_GPIO_PIN_KEYBRD_DATAOUT,
  -   .flags  = GPIOF_OUT_INIT_LOW,
  -   .label  = keybrd_dataout,
  -   },
  -   {
  .gpio   = AMS_DELTA_GPIO_PIN_SCARD_RSTIN,
  .flags  = GPIOF_OUT_INIT_LOW,
  .label  = scard_rstin,
  diff --git a/arch/arm/plat-omap/include/plat/board-ams-delta.h 
  b/arch/arm/plat-omap/include/plat/board-ams-delta.h
  index e9ad673..027e79e 100644
  --- a/arch/arm/plat-omap/include/plat/board-ams-delta.h
  +++ b/arch/arm/plat-omap/include/plat/board-ams-delta.h
  @@ -28,8 +28,6 @@
   
   #if defined (CONFIG_MACH_AMS_DELTA)
   
  -#define AMD_DELTA_LATCH2_KEYBRD_PWR0x0100
  -#define AMD_DELTA_LATCH2_KEYBRD_DATA   0x0200
   #define AMD_DELTA_LATCH2_SCARD_RSTIN   0x0400
   #define AMD_DELTA_LATCH2_SCARD_CMDVCC  0x0800
   #define AMS_DELTA_LATCH2_MODEM_NRESET  0x1000
  diff --git a/drivers/input/serio/ams_delta_serio.c 
  b/drivers/input/serio/ams_delta_serio.c
  index 835d37a..ef1ec40 100644
  --- a/drivers/input/serio/ams_delta_serio.c
  +++ b/drivers/input/serio/ams_delta_serio.c
  @@ -92,8 +92,7 @@ static irqreturn_t ams_delta_serio_interrupt(int irq, 
  void *dev_id)
   static int ams_delta_serio_open(struct serio *serio)
   {
  /* enable keyboard */
  -   ams_delta_latch2_write(AMD_DELTA_LATCH2_KEYBRD_PWR,
  -   AMD_DELTA_LATCH2_KEYBRD_PWR);
  +   gpio_set_value(AMS_DELTA_GPIO_PIN_KEYBRD_PWR, 1);
   
  return 0;
   }
  @@ -101,9 +100,32 @@ static int ams_delta_serio_open(struct serio *serio)
   static void ams_delta_serio_close(struct serio *serio)
   {
  /* disable keyboard */
  -   ams_delta_latch2_write(AMD_DELTA_LATCH2_KEYBRD_PWR, 0);
  +   gpio_set_value(AMS_DELTA_GPIO_PIN_KEYBRD_PWR, 0);
   }
   
  +static struct gpio _gpios[] __initconst_or_module = {
  +   {
  +   .gpio   = AMS_DELTA_GPIO_PIN_KEYBRD_DATA,
  +   .flags  = GPIOF_DIR_IN,
  +   .label  = serio-data,
  +   },
  +   {
  +   .gpio   = AMS_DELTA_GPIO_PIN_KEYBRD_CLK,
  +   .flags  = GPIOF_DIR_IN,
  +   .label  = serio-clock,
  +   },
  +   {
  +   .gpio   =

Re: [PATCH v2 1/7 v2] ARM: OMAP1: ams-delta: register latch dependent devices later

2011-12-21 Thread Tony Lindgren

* Janusz Krzysztofik jkrzy...@tis.icnet.pl [111221 11:20]:
 On Wednesday 21 of December 2011 at 20:08:15, Tony Lindgren wrote:
  * Janusz Krzysztofik jkrzy...@tis.icnet.pl [111220 13:23]:
   In preparation to converting Amstrad Delta on-board latches to
   basic_mmio_gpio devices, registration of platform devices which depend
   on latches and will require initialization of their GPIO pins first,
   should be moved out of .machine_init down to late_initcall level, as the
   gpio-generic driver is not available until device_initcall time.  The
   latch reset operation, which will be replaced with GPIO initialization,
   must also be moved to late_initcall for the same reason.
   
   Since there was already another, separate arch_initcall function for
   setting up one of those latch dependent devices, the on-board modem
   device, reuse that function, i.e., rename it to a name that matches the
   new purpose, extend with other device setup relocated from
   .machine_init, and move down to the late_initcall level.
   
   While being at it, add missing gpio_free() in case the modem platform
   device registration fails.
   
   Thanks to Tony Lindgren t...@atomide.com who suggested this approach
   instead of shifting up the gpio-generic driver initialization.
   
   In addition, defer registration of the Amstrad Delta ASoC and serio
   devices, done from their device driver files, until late_initcall time,
   as those drivers will depend on their GPIO pins already requested from
   the board late_init() function until updated to register their GPIO pins
   themselves.
   
   Created and tested against linux-3.2-rc6.
   
   Signed-off-by: Janusz Krzysztofik jkrzy...@tis.icnet.pl
  
  Planning to apply this series. Dmitry, care to ack the drivers/input/serio/
  related change?
 
 Don't we need Jarkko's or Mark's or Liam's ack as well for the change to 
 the sound/soc/omap/ams-delta.c file?

Yes, you're right.

Tony

   Changes since the initial version of this patch:
   * use late_initcall() unconditionally in modules, requested by Russell
 King (thanks!); an updated patch 7/7 will follow,
   * in the changelog message, move credits to Tony up a bit, since the
 person responsible for other changes (he might not necessarily like)
 is me, not him ;).
   
   Comments copied from this patch initial submission:
   This patch was not present in the initial submission, it replaces the
   old patch 1/10, providing an alternative solution not touching the
   gpio-generic driver.
   
arch/arm/mach-omap1/board-ams-delta.c |   28 
drivers/input/serio/ams_delta_serio.c |2 +-
sound/soc/omap/ams-delta.c|2 +-
3 files changed, 22 insertions(+), 10 deletions(-)
   
   diff --git a/arch/arm/mach-omap1/board-ams-delta.c 
   b/arch/arm/mach-omap1/board-ams-delta.c
   index b0f15d2..50987c9 100644
   --- a/arch/arm/mach-omap1/board-ams-delta.c
   +++ b/arch/arm/mach-omap1/board-ams-delta.c
   @@ -275,11 +275,14 @@ static struct omap1_cam_platform_data 
   ams_delta_camera_platform_data = {
};

static struct platform_device *ams_delta_devices[] __initdata = {
   - ams_delta_nand_device,
 ams_delta_kp_device,
   + ams_delta_camera_device,
   +};
   +
   +static struct platform_device *late_devices[] __initdata = {
   + ams_delta_nand_device,
 ams_delta_lcd_device,
 ams_delta_led_device,
   - ams_delta_camera_device,
};

static void __init ams_delta_init(void)
   @@ -307,9 +310,6 @@ static void __init ams_delta_init(void)
 omap_serial_init();
 omap_register_i2c_bus(1, 100, NULL, 0);

   - /* Clear latch2 (NAND, LCD, modem enable) */
   - ams_delta_latch2_write(~0, 0);
   -
 omap1_usb_init(ams_delta_usb_config);
 omap1_set_camera_info(ams_delta_camera_platform_data);
#ifdef CONFIG_LEDS_TRIGGERS
   @@ -345,13 +345,18 @@ static struct platform_device 
   ams_delta_modem_device = {
 },
};

   -static int __init ams_delta_modem_init(void)
   +static int __init late_init(void)
{
 int err;

 if (!machine_is_ams_delta())
 return -ENODEV;

   + /* Clear latch2 (NAND, LCD, modem enable) */
   + ams_delta_latch2_write(~0, 0);
   +
   + platform_add_devices(late_devices, ARRAY_SIZE(late_devices));
   +
 omap_cfg_reg(M14_1510_GPIO2);
 ams_delta_modem_ports[0].irq =
 gpio_to_irq(AMS_DELTA_GPIO_PIN_MODEM_IRQ);
   @@ -367,9 +372,16 @@ static int __init ams_delta_modem_init(void)
 AMS_DELTA_LATCH2_MODEM_NRESET | AMS_DELTA_LATCH2_MODEM_CODEC,
 AMS_DELTA_LATCH2_MODEM_NRESET | AMS_DELTA_LATCH2_MODEM_CODEC);

   - return platform_device_register(ams_delta_modem_device);
   + err = platform_device_register(ams_delta_modem_device);
   + if (err)
   + goto gpio_free;
   + return 0;
   +
   +gpio_free:
   + gpio_free(AMS_DELTA_GPIO_PIN_MODEM_IRQ);
   + return err;
}
   -arch_initcall(ams_delta_modem_init);

Re: [PATCH v2 5/7] MTD: NAND: ams-delta: use GPIO instead of custom I/O

2011-12-21 Thread Artem Bityutskiy

On Tue, 2011-12-20 at 00:08 +0100, Janusz Krzysztofik wrote:
 Don't use Amstrad Delta custom I/O functions for controlling the device,
 use GPIO API instead.
 
 While being at it, add missing gpio_free(AMS_DELTA_GPIO_PIN_NAND_RB).
 
 Depends on patch 2/7 ARM: OMAP1: ams-delta: convert latches to
 basic_mmio_gpio
 
 Signed-off-by: Janusz Krzysztofik jkrzy...@tis.icnet.pl
 Cc: David Woodhouse dw...@infradead.org
 Cc: Tony Lindgren t...@atomide.com

Looks good, thanks!

Reviewed-by: Artem Bityutskiy artem.bityuts...@linux.intel.com

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

Re: [PATCH 07/10] ASoC: OMAP: ams-delta: Drive modem/codec pins over GPIO API

2011-12-21 Thread Janusz Krzysztofik

On Wednesday 21 of December 2011 at 19:33:44, Liam Girdwood wrote:
 On Sun, 2011-12-11 at 21:12 +0100, Janusz Krzysztofik wrote:
  Don't use Amstrad Delta custom I/O functions any longer, replace them
  with GPIO. Old pin definitions, no longer used by the modem bits either,
  can be dropped.
  
  Depends on patch 2/10 ARM: OMAP1: Convert Amstrad E3 latches to
  basic_mmio_gpio.
  
  Signed-off-by: Janusz Krzysztofik jkrzy...@tis.icnet.pl
 
 Applied.

Hi,
I'm sorry, but I've probably missed to infrom you explicitly, i.e. other 
than in a cover letter to v2 of this series, that this particular patch 
has been dropped from the series. I've already started working on an 
alternative solution, which I intend to submit as a separate set. It 
will be free of potentail problems with two devices, a modem and the 
sound card, accessing the same GPIO pins concurrently. For the 
MODEM_NRESET pin I've already set up a virtual regulator on top of it, 
and for the MODEM_CODEC pin I'll probably choose a virtual clock (pinmux 
would match the hardware more closely here, but it looks too complicated 
to me). Moreover, I've already started to move all those GPIO pin 
related functions, i.e. bias control, digital mute and line discipline 
interaction, from the board file to the codec driver, where all those 
seem to belong.

Having this patch applied will conflict with the regultor and the clock 
solutions, taking control over those two GPIO pins. Please revert this 
patch, or reset it if still possible.

Thanks,
Janusz
--
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] OMAP3: hwmod_data: add HWMOD_INIT_NO_RESET flag for dss_dispc

2011-12-21 Thread Ilya Yanok

Resetting DISPC when a DISPC output is enabled causes the DSS to go into
an inconsistent state.

commit b923d40dd4211c4ef7d4efa2bd81b7ca1d8744c1
Author: Archit Taneja arc...@ti.com
Date:   Thu Oct 6 18:04:08 2011 -0600

ARM: OMAP2PLUS: DSS: Ensure DSS works correctly if display is
enabled in bootloader

tries to deal with this problem by checking if display is enabled and
disabling it before doing reset.

But in my setup dss_dispc is resetted from omap_hwmod_setup_all function
_before_ calling omap_dss_reset. So when dispc_disable_outputs is
executed dispc is already reset and nothing happens.

This patch and HWMOD_INIT_NO_RESET flags to dss_dispc hwmod thus leaving
DISPC untouched so that omap_dss_reset can take care of it.

This solves the l3_app_irq BUG problem on my AM3517 based board.

CC: Archit Taneja arc...@ti.com
CC: Paul Walmsley p...@pwsan.com
Signed-off-by: Ilya Yanok ya...@emcraft.com
---
 arch/arm/mach-omap2/omap_hwmod_3xxx_data.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c 
b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
index 5324e8d..226b365 100644
--- a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
@@ -1515,7 +1515,7 @@ static struct omap_hwmod omap3xxx_dss_dispc_hwmod = {
},
.slaves = omap3xxx_dss_dispc_slaves,
.slaves_cnt = ARRAY_SIZE(omap3xxx_dss_dispc_slaves),
-   .flags  = HWMOD_NO_IDLEST,
+   .flags  = HWMOD_NO_IDLEST | HWMOD_INIT_NO_RESET,
.dev_attr   = omap2_3_dss_dispc_dev_attr
 };
 
-- 
1.7.6.4

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

Re: Interesting L3 driver panic on v3.2-rc5 on 3530

2011-12-21 Thread Ilya Yanok

Hi Archit, Paul,

On 20.12.2011 16:23, Archit Taneja wrote:
 There was a patch which got into the kernel in 3.2-rc4:
 
 b923d40dd4211c4ef7d4efa2bd81b7ca1d8744c1
 ARM: OMAP2PLUS: DSS: Ensure DSS works correctly if display is enabled in
 bootloader
 
 This tries to disable any display outputs if enabled in bootloader. If
 this issue didn't happen before, we might want to look into this code.
 
 Could you share what debug prints you get from the function
 omap_dss_reset() (its in arch/arm/mach-omap2/display.c)

In my case the bottom part of dispc_disable_outputs() is never executed
as dss_dispc is reset but omap_hwmod_setup_all function and when
dispc_disable_outputs is executed it sees that the display is disabled
already.

I've just posted a patch to fix this.

Regards, Ilya.
--
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

40 matches

Mail list logo