Re: GPIO abort on 3630/Zoom3

[Shilimkar, Santosh]

On Thu, Mar 15, 2012 at 8:43 AM, DebBarma, Tarun Kanti
 wrote:
> On Thu, Mar 15, 2012 at 3:35 AM, Kevin Hilman  wrote:
>> Tarun,
>>
>> Can you investigate an abort during boot on 3630/Zoom3?
>>
>> Both Tony and I are seeing the abort below on 3630/Zoom3.  I'm using
>> arm-soc/for-next and Tony is using linux-next, but we see the same abort.
> The crash looks very similar to what we fixed yesterday. The problem was
> basically due to usage of OMAP_GPIO_IRQ macro instead of gpio_to_irq()
> which came as part of Benoit's dynamic irq allocation change. The fix is to
> replace those macros in the board files.
> (The same problem is seen on OMAP3430 SDP as well.)
> Anyways, I will confirm.
>
>>
>> Adding in your latest fixes series doesn't make the problem go away, but
>> backing out the GPIO runtime PM series does make the problem go away.
> Because of dynamic irq allocation we end up into wrong GPIO Bank unless
> we use the new gpio_to_irq(). As a result _set_gpio_triggering() tries
> to operate
> on a GPIO Bank whose clock was not turned on using omap_gpio_request().
> Probably, that is why we do not see the problem when the runtime PM series
> is removed because in this case all the GPIO banks are turned on.
>
To be clear, the issue which we saw was wiith Grant's tree which has
GPIO sparce IRQ conversion. So if the issue is seen with linux for-next,
it must be the same issue.

There are many board files which are still using static OMAP_GPIO_IRQ
macro to retrieve the IRQ number which won't work anymore after
the gpio sparce irq conversion series. We will post a patch against
Grant's tree to fix those board files.

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

Re: [PATCH v2 5/8] ARM: OMAP2+: hwmod: ensure that SYSCONFIG bits are reprogrammed after a reset

[Paul Walmsley]

Hola Omar,

On Wed, 14 Mar 2012, Ramirez Luna, Omar wrote:

> If we reached here the reset lines will be asserted, and then the code
> below touches sysc registers on a module under reset.

Do you know of any case where this would be a problem?  Seems like it 
would only affect IP blocks that have both hard reset lines and SYSCONFIG 
registers, and as far as I know, we don't have any of those defined?


- Paul
--
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: GPIO abort on 3630/Zoom3

[DebBarma, Tarun Kanti]

On Thu, Mar 15, 2012 at 3:35 AM, Kevin Hilman  wrote:
> Tarun,
>
> Can you investigate an abort during boot on 3630/Zoom3?
>
> Both Tony and I are seeing the abort below on 3630/Zoom3.  I'm using
> arm-soc/for-next and Tony is using linux-next, but we see the same abort.
The crash looks very similar to what we fixed yesterday. The problem was
basically due to usage of OMAP_GPIO_IRQ macro instead of gpio_to_irq()
which came as part of Benoit's dynamic irq allocation change. The fix is to
replace those macros in the board files.
(The same problem is seen on OMAP3430 SDP as well.)
Anyways, I will confirm.

>
> Adding in your latest fixes series doesn't make the problem go away, but
> backing out the GPIO runtime PM series does make the problem go away.
Because of dynamic irq allocation we end up into wrong GPIO Bank unless
we use the new gpio_to_irq(). As a result _set_gpio_triggering() tries
to operate
on a GPIO Bank whose clock was not turned on using omap_gpio_request().
Probably, that is why we do not see the problem when the runtime PM series
is removed because in this case all the GPIO banks are turned on.
--
Tarun

>
> Kevin
>
>
> Uncompressing Linux... done, booting the kernel.
> [    0.00] Booting Linux on physical CPU 0
> [    0.00] Linux version 3.3.0-rc7-pm+debug+initramfs-01079-g405139c 
> (khilman@paris) (gcc version 4.6.1 (Ubuntu/Linaro 4.6.1-9ubuntu3) ) #15 SMP 
> Wed Mar 14 13:06:34 PDT 2012
> [    0.00] CPU: ARMv7 Processor [413fc082] revision 2 (ARMv7), cr=10c53c7d
> [    0.00] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing 
> instruction cache
> [    0.00] Machine: OMAP Zoom3 board
> [    0.00] bootconsole [earlycon0] enabled
> [    0.00] Memory policy: ECC disabled, Data cache writeback
> [    0.00] On node 0 totalpages: 32512
> [    0.00] free_area_init_node: node 0, pgdat c094f580, node_mem_map 
> c0ea7000
> [    0.00]   Normal zone: 256 pages used for memmap
> [    0.00]   Normal zone: 0 pages reserved
> [    0.00]   Normal zone: 32256 pages, LIFO batch:7
> [    0.00] OMAP3630 ES1.0 (l2cache iva sgx neon isp 192mhz_clk )
> [    0.00] Clocking rate (Crystal/Core/MPU): 26.0/400/600 MHz
> [    0.00] PERCPU: Embedded 9 pages/cpu @c0fab000 s12864 r8192 d15808 
> u36864
> [    0.00] pcpu-alloc: s12864 r8192 d15808 u36864 alloc=9*4096
> [    0.00] pcpu-alloc: [0] 0
> [    0.00] Built 1 zonelists in Zone order, mobility grouping on.  Total 
> pages: 32256
> [    0.00] Kernel command line: mem=128M console=ttyS0,115200n8 ip=dhcp 
> debug earlyprintk user_debug=0x
> [    0.00] PID hash table entries: 512 (order: -1, 2048 bytes)
> [    0.00] Dentry cache hash table entries: 16384 (order: 4, 65536 bytes)
> [    0.00] Inode-cache hash table entries: 8192 (order: 3, 32768 bytes)
> [    0.00] Memory: 127MB = 127MB total
> [    0.00] Memory: 113868k/113868k available, 17204k reserved, 0K highmem
> [    0.00] Virtual kernel memory layout:
> [    0.00]     vector  : 0x - 0x1000   (   4 kB)
> [    0.00]     fixmap  : 0xfff0 - 0xfffe   ( 896 kB)
> [    0.00]     vmalloc : 0xc880 - 0xff00   ( 872 MB)
> [    0.00]     lowmem  : 0xc000 - 0xc800   ( 128 MB)
> [    0.00]     modules : 0xbf00 - 0xc000   (  16 MB)
> [    0.00]       .text : 0xc0008000 - 0xc0605560   (6134 kB)
> [    0.00]       .init : 0xc0606000 - 0xc08c2240   (2801 kB)
> [    0.00]       .data : 0xc08c4000 - 0xc0950ff0   ( 564 kB)
> [    0.00]        .bss : 0xc0951014 - 0xc0ea6c9c   (5464 kB)
> [    0.00] Hierarchical RCU implementation.
> [    0.00] NR_IRQS:474
> [    0.00] IRQ: Found an INTC at 0xfa20 (revision 4.0) with 96 
> interrupts
> [    0.00] Total of 96 interrupts on 1 active controller
> [    0.00] OMAP clockevent source: GPTIMER1 at 32768 Hz
> [    0.00] sched_clock: 32 bits at 32kHz, resolution 30517ns, wraps every 
> 131071999ms
> [    0.00] Console: colour dummy device 80x30
> [    0.00] Lock dependency validator: Copyright (c) 2006 Red Hat, Inc., 
> Ingo Molnar
> [    0.00] ... MAX_LOCKDEP_SUBCLASSES:  8
> [    0.00] ... MAX_LOCK_DEPTH:          48
> [    0.00] ... MAX_LOCKDEP_KEYS:        8191
> [    0.00] ... CLASSHASH_SIZE:          4096
> [    0.00] ... MAX_LOCKDEP_ENTRIES:     16384
> [    0.00] ... MAX_LOCKDEP_CHAINS:      32768
> [    0.00] ... CHAINHASH_SIZE:          16384
> [    0.00]  memory used by lock dependency info: 3695 kB
> [    0.00]  per task-struct memory footprint: 1152 bytes
> [    0.056732] Calibrating delay loop... 597.64 BogoMIPS (lpj=2334720)
> [    0.098571] pid_max: default: 32768 minimum: 301
> [    0.104125] Security Framework initialized
> [    0.108673] Mount-cache hash table entries: 512
> [    0.118377] CPU: Testing write buffer coherency: ok
> [    0.124389] CPU0: thread -1, cpu 0, socket -1, mpidr 0
> [    0.129852] Setting up stat

Re: [GIT PULL] ARM: OMAP: i2c, gpio, spi, regulator and mmc DTS updates

[Tony Lindgren]

Hi,

* Cousson, Benoit  [120314 16:41]:
> Hi Tony,
> 
> Here are the remaining DTS patches for 3.4.
> 
> On top of the previous pull request, I just added the MMC DTS since the 
> driver adaptation just got queued.
> 
> It will be still be good to have that for 3.4 if possible, otherwise we will 
> have a bunch of drivers DT adapted but no DTS file to use them :-(

This might be doable as a follow-up patch series at the end
of the merge window or at -rc1 when the related driver changes
have been merged.

Arnd and Olof, what do you guys think?

Regards,

Tony

 
> This series is based on your lo/dt-part2 branch.
> 
> Thanks,
> Benoit
> 
> 
> The following changes since commit 328ae2cb50af2f96b6061eb462aa92966a462bbc:
>   Ilya Yanok (1):
> arm/dts: mt_ventoux: very basic support for TeeJet Mt.Ventoux board
> 
> are available in the git repository at:
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/bcousson/linux-omap-dt.git 
> for_3.4/dts/all
> 
> Benoit Cousson (11):
>   arm/dts: twl6030: Add DTS file for twl6030 PMIC
>   arm/dts: twl4030: Add DTS file for twl4030 PM + Audio IC
>   arm/dts: omap4-panda: Add twl6030 and i2c EEPROM
>   arm/dts: omap4-sdp: Add twl6030, i2c3 and i2c4 devices
>   arm/dts: omap3-beagle: Add twl4030 and i2c EEPROM
>   ARM: OMAP2+: board-generic: Remove i2c static init
>   arm/dts: OMAP4: Add gpio nodes
>   arm/dts: OMAP3: Add gpio nodes
>   arm/dts: OMAP4: Add SPI controller nodes
>   arm/dts: OMAP3: Add SPI controller nodes
>   arm/dts: omap4-sdp: Add ks8851 ethernet SPI device
> 
> Rajendra Nayak (3):
>   arm/dts: twl: Pass regulator data from dt
>   arm/dts: OMAP4: Add mmc controller nodes and board data
>   arm/dts: OMAP3: Add mmc controller nodes and board data
> 
>  arch/arm/boot/dts/omap3-beagle.dts  |   49 +++
>  arch/arm/boot/dts/omap3.dtsi|  102 ++
>  arch/arm/boot/dts/omap4-panda.dts   |   56 +
>  arch/arm/boot/dts/omap4-sdp.dts |   97 +
>  arch/arm/boot/dts/omap4.dtsi|  117 
> +++
>  arch/arm/boot/dts/twl4030.dtsi  |   39 
>  arch/arm/boot/dts/twl6030.dtsi  |   86 +
>  arch/arm/mach-omap2/board-generic.c |   37 +--
>  arch/arm/mach-omap2/devices.c   |4 +-
>  arch/arm/mach-omap2/gpio.c  |8 ++-
>  10 files changed, 557 insertions(+), 38 deletions(-)
>  create mode 100644 arch/arm/boot/dts/twl4030.dtsi
>  create mode 100644 arch/arm/boot/dts/twl6030.dtsi
> 
--
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/8] ARM: OMAP2+: hwmod: ensure that SYSCONFIG bits are reprogrammed after a reset

[Ramirez Luna, Omar]

Hi Paul,

2012/2/27 Paul Walmsley :
> diff --git a/arch/arm/mach-omap2/omap_hwmod.c 
> b/arch/arm/mach-omap2/omap_hwmod.c
> index db4ad41..aeb6f4c 100644
> --- a/arch/arm/mach-omap2/omap_hwmod.c
> +++ b/arch/arm/mach-omap2/omap_hwmod.c
> @@ -1490,13 +1490,22 @@ static int _reset(struct omap_hwmod *oh)
>        pr_debug("omap_hwmod: %s: resetting\n", oh->name);
>
>        if (oh->class->reset)
> -               return oh->class->reset(oh);
> -
> -       if (!oh->rst_lines_cnt)
> -               return _ocp_softreset(oh);
> +               oh->class->reset(oh);
> +       else if (!oh->rst_lines_cnt)
> +               _ocp_softreset(oh);
> +       else
> +               for (i = 0; i < oh->rst_lines_cnt; i++)
> +                       _assert_hardreset(oh, oh->rst_lines[i].name);

If we reached here the reset lines will be asserted, and then the code
below touches sysc registers on a module under reset.

This would crash on _setup->_setup_reset->_reset.

Adding a 'return 0' I believe fixes the behavior, boots the board and
leaves the hwmod under reset.

-   else
+   } else {
for (i = 0; i < oh->rst_lines_cnt; i++)
_assert_hardreset(oh, oh->rst_lines[i].name);
+   return 0;
+   }

>
> -       for (i = 0; i < oh->rst_lines_cnt; i++)
> -               _assert_hardreset(oh, oh->rst_lines[i].name);
> +       /*
> +        * OCP_SYSCONFIG bits need to be reprogrammed after a
> +        * softreset.  The _enable() function should be split to avoid
> +        * the rewrite of the OCP_SYSCONFIG register.
> +        */
> +       if (oh->class->sysc) {
> +               _update_sysc_cache(oh);
> +               _enable_sysc(oh);
> +       }

Best Regards,

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

[GIT PULL] ARM: OMAP: i2c, gpio, spi, regulator and mmc DTS updates

[Cousson, Benoit]

Hi Tony,

Here are the remaining DTS patches for 3.4.

On top of the previous pull request, I just added the MMC DTS since the driver 
adaptation just got queued.

It will be still be good to have that for 3.4 if possible, otherwise we will 
have a bunch of drivers DT adapted but no DTS file to use them :-(

This series is based on your lo/dt-part2 branch.

Thanks,
Benoit


The following changes since commit 328ae2cb50af2f96b6061eb462aa92966a462bbc:
  Ilya Yanok (1):
arm/dts: mt_ventoux: very basic support for TeeJet Mt.Ventoux board

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/bcousson/linux-omap-dt.git 
for_3.4/dts/all

Benoit Cousson (11):
  arm/dts: twl6030: Add DTS file for twl6030 PMIC
  arm/dts: twl4030: Add DTS file for twl4030 PM + Audio IC
  arm/dts: omap4-panda: Add twl6030 and i2c EEPROM
  arm/dts: omap4-sdp: Add twl6030, i2c3 and i2c4 devices
  arm/dts: omap3-beagle: Add twl4030 and i2c EEPROM
  ARM: OMAP2+: board-generic: Remove i2c static init
  arm/dts: OMAP4: Add gpio nodes
  arm/dts: OMAP3: Add gpio nodes
  arm/dts: OMAP4: Add SPI controller nodes
  arm/dts: OMAP3: Add SPI controller nodes
  arm/dts: omap4-sdp: Add ks8851 ethernet SPI device

Rajendra Nayak (3):
  arm/dts: twl: Pass regulator data from dt
  arm/dts: OMAP4: Add mmc controller nodes and board data
  arm/dts: OMAP3: Add mmc controller nodes and board data

 arch/arm/boot/dts/omap3-beagle.dts  |   49 +++
 arch/arm/boot/dts/omap3.dtsi|  102 ++
 arch/arm/boot/dts/omap4-panda.dts   |   56 +
 arch/arm/boot/dts/omap4-sdp.dts |   97 +
 arch/arm/boot/dts/omap4.dtsi|  117 +++
 arch/arm/boot/dts/twl4030.dtsi  |   39 
 arch/arm/boot/dts/twl6030.dtsi  |   86 +
 arch/arm/mach-omap2/board-generic.c |   37 +--
 arch/arm/mach-omap2/devices.c   |4 +-
 arch/arm/mach-omap2/gpio.c  |8 ++-
 10 files changed, 557 insertions(+), 38 deletions(-)
 create mode 100644 arch/arm/boot/dts/twl4030.dtsi
 create mode 100644 arch/arm/boot/dts/twl6030.dtsi

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

Re: [GIT PULL] ARM: OMAP: i2c, gpio, spi and regulator DTS updates

[Cousson, Benoit]

On 3/15/2012 12:21 AM, Tony Lindgren wrote:

* Cousson, Benoit  [120314 16:06]:

On 3/14/2012 11:57 PM, Tony Lindgren wrote:

* Cousson, Benoit   [120314 15:52]:

Hi Tony,

It looks like Chris Ball just queued  the HSMMC DT stuff from
Rajendra, so I can add as well the MMC DTS for OMAP3 and OMAP4 as
well.

It is fine for an update?


Sure, I'm not planning to pull this until after the merge
window.


OK, so we will not have the DTS support for the new drivers for 3.4 :-(


Well you said this one has driver dependencies :)


Well, this is not a strong dependency, but it is still better to have 
the driver adapted to use the DTS node.


What is really unfair is that I did remove the DTS from the driver 
series to avoid conflict during merge of the various driver series. So 
next time, I guess I'd rather let the DTS along with the driver, but 
this is really a pity.



Well, if you pull that in a lo branch, that will be enough to base
the further work on it.


Right we got something like seven branches ready to go for
early merging after the merge window.. We should have patches
sitting in linux-next for at least a week before the merge
window opens.


I know that, but since it is just a bunch of DTS, none of them will 
break anything in linux-next anyway...



Than I can add as Kevin's patch for twl irq_base removal.


Hmm I don't follow. That's needed first as a fix for the
merge window?


No, not that one. It is just some more cleanup on top of the one
Felipe already did in the twl series I've just sent to Samuel.
But if you do not plan to pull that series for 3.4, that does not
really matter.


Ah OK. In that case feel free to update. Also check if some
of these can be sent as fixes during the -rc cycle?


No, that should be fine, this one can wait 3.5.

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

Re: [GIT PULL] ARM: OMAP: i2c, gpio, spi and regulator DTS updates

[Tony Lindgren]

* Cousson, Benoit  [120314 16:06]:
> On 3/14/2012 11:57 PM, Tony Lindgren wrote:
> >* Cousson, Benoit  [120314 15:52]:
> >>Hi Tony,
> >>
> >>It looks like Chris Ball just queued  the HSMMC DT stuff from
> >>Rajendra, so I can add as well the MMC DTS for OMAP3 and OMAP4 as
> >>well.
> >>
> >>It is fine for an update?
> >
> >Sure, I'm not planning to pull this until after the merge
> >window.
> 
> OK, so we will not have the DTS support for the new drivers for 3.4 :-(

Well you said this one has driver dependencies :)

> Well, if you pull that in a lo branch, that will be enough to base
> the further work on it.

Right we got something like seven branches ready to go for
early merging after the merge window.. We should have patches
sitting in linux-next for at least a week before the merge
window opens.

> >>Than I can add as Kevin's patch for twl irq_base removal.
> >
> >Hmm I don't follow. That's needed first as a fix for the
> >merge window?
> 
> No, not that one. It is just some more cleanup on top of the one
> Felipe already did in the twl series I've just sent to Samuel.
> But if you do not plan to pull that series for 3.4, that does not
> really matter.

Ah OK. In that case feel free to update. Also check if some
of these can be sent as fixes during the -rc cycle?

Regards,

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

Re: [GIT PULL] ARM: OMAP: i2c, gpio, spi and regulator DTS updates

[Cousson, Benoit]

On 3/14/2012 11:57 PM, Tony Lindgren wrote:

* Cousson, Benoit  [120314 15:52]:

Hi Tony,

It looks like Chris Ball just queued  the HSMMC DT stuff from
Rajendra, so I can add as well the MMC DTS for OMAP3 and OMAP4 as
well.

It is fine for an update?


Sure, I'm not planning to pull this until after the merge
window.


OK, so we will not have the DTS support for the new drivers for 3.4 :-(

Well, if you pull that in a lo branch, that will be enough to base the 
further work on it.



Than I can add as Kevin's patch for twl irq_base removal.


Hmm I don't follow. That's needed first as a fix for the
merge window?


No, not that one. It is just some more cleanup on top of the one Felipe 
already did in the twl series I've just sent to Samuel.
But if you do not plan to pull that series for 3.4, that does not really 
matter.


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

Re: [GIT PULL] ARM: OMAP: i2c, gpio, spi and regulator DTS updates

[Tony Lindgren]

* Cousson, Benoit  [120314 15:52]:
> Hi Tony,
> 
> It looks like Chris Ball just queued  the HSMMC DT stuff from
> Rajendra, so I can add as well the MMC DTS for OMAP3 and OMAP4 as
> well.
> 
> It is fine for an update?

Sure, I'm not planning to pull this until after the merge
window.
 
> Than I can add as Kevin's patch for twl irq_base removal.

Hmm I don't follow. That's needed first as a fix for the
merge window?

Regards,

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

Re: [GIT PULL] ARM: OMAP: i2c, gpio, spi and regulator DTS updates

[Cousson, Benoit]

Hi Tony,

It looks like Chris Ball just queued  the HSMMC DT stuff from Rajendra, 
so I can add as well the MMC DTS for OMAP3 and OMAP4 as well.


It is fine for an update?

Than I can add as Kevin's patch for twl irq_base removal.

Thanks,
Benoit

On 3/13/2012 12:41 AM, Cousson, Benoit wrote:

Hi Tony,

Here are the remaining DTS patches for 3.4.

Ideally all the driver DT adaptation should have been merged before that one.

This series is based on your lo/dt-part2 branch.

Thanks,
Benoit


The following changes since commit 328ae2cb50af2f96b6061eb462aa92966a462bbc:
   Ilya Yanok (1):
 arm/dts: mt_ventoux: very basic support for TeeJet Mt.Ventoux board

are available in the git repository at:

   git://git.kernel.org/pub/scm/linux/kernel/git/bcousson/linux-omap-dt.git 
for_3.4/dts/all

Benoit Cousson (11):
   arm/dts: twl6030: Add DTS file for twl6030 PMIC
   arm/dts: twl4030: Add DTS file for twl4030 PM + Audio IC
   arm/dts: omap4-panda: Add twl6030 and i2c EEPROM
   arm/dts: omap4-sdp: Add twl6030, i2c3 and i2c4 devices
   arm/dts: omap3-beagle: Add twl4030 and i2c EEPROM
   ARM: OMAP2+: board-generic: Remove i2c static init
   arm/dts: OMAP4: Add gpio nodes
   arm/dts: OMAP3: Add gpio nodes
   arm/dts: OMAP4: Add SPI controller nodes
   arm/dts: OMAP3: Add SPI controller nodes
   arm/dts: omap4-sdp: Add ks8851 ethernet SPI device

Rajendra Nayak (1):
   arm/dts: twl: Pass regulator data from dt

  arch/arm/boot/dts/omap3-beagle.dts  |   35 ++
  arch/arm/boot/dts/omap3.dtsi|   86 +++
  arch/arm/boot/dts/omap4-panda.dts   |   34 ++
  arch/arm/boot/dts/omap4-sdp.dts |   73 +
  arch/arm/boot/dts/omap4.dtsi|   86 +++
  arch/arm/boot/dts/twl4030.dtsi  |   39 
  arch/arm/boot/dts/twl6030.dtsi  |   86 +++
  arch/arm/mach-omap2/board-generic.c |   37 +--
  arch/arm/mach-omap2/devices.c   |4 +-
  arch/arm/mach-omap2/gpio.c  |8 +++-
  10 files changed, 450 insertions(+), 38 deletions(-)
  create mode 100644 arch/arm/boot/dts/twl4030.dtsi
  create mode 100644 arch/arm/boot/dts/twl6030.dtsi



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

Re: [PATCH 01/12] mfd: twl-core: don't depend on pdata->irq_base/end

[Tony Lindgren]

* Kevin Hilman  [120314 14:02]:
> From: Kevin Hilman 
> Date: Wed, 14 Mar 2012 13:56:01 -0700
> Subject: [PATCH 2/2] ARM: OMAP2+: TWL: remove usage of pdata->irq_base/_end
> 
> The driver has been converted to use SPARSE_IRQ and no longer needs to
> be passed IRQ base/end.  The driver no longer uses these fields, so
> remove them from the reamaining users.
> 
> Signed-off-by: Kevin Hilman 
> ---
>  arch/arm/mach-omap2/board-2430sdp.c|3 ---
>  arch/arm/mach-omap2/board-omap3logic.c |3 ---
>  arch/arm/mach-omap2/twl-common.c   |9 -
>  3 files changed, 15 deletions(-)
> 
> diff --git a/arch/arm/mach-omap2/board-2430sdp.c 
> b/arch/arm/mach-omap2/board-2430sdp.c
> index c8bda62..b8b3700 100644
> --- a/arch/arm/mach-omap2/board-2430sdp.c
> +++ b/arch/arm/mach-omap2/board-2430sdp.c
> @@ -218,9 +218,6 @@ static struct twl4030_gpio_platform_data 
> sdp2430_gpio_data = {
>  };
>  
>  static struct twl4030_platform_data sdp2430_twldata = {
> - .irq_base   = TWL4030_IRQ_BASE,
> - .irq_end= TWL4030_IRQ_END,
> -
>   /* platform_data for children goes here */
>   .gpio   = &sdp2430_gpio_data,
>   .vmmc1  = &sdp2430_vmmc1,
> diff --git a/arch/arm/mach-omap2/board-omap3logic.c 
> b/arch/arm/mach-omap2/board-omap3logic.c
> index 4a7d8c8..f145935 100644
> --- a/arch/arm/mach-omap2/board-omap3logic.c
> +++ b/arch/arm/mach-omap2/board-omap3logic.c
> @@ -85,9 +85,6 @@ static struct twl4030_gpio_platform_data 
> omap3logic_gpio_data = {
>  };
>  
>  static struct twl4030_platform_data omap3logic_twldata = {
> - .irq_base   = TWL4030_IRQ_BASE,
> - .irq_end= TWL4030_IRQ_END,
> -
>   /* platform_data for children goes here */
>   .gpio   = &omap3logic_gpio_data,
>   .vmmc1  = &omap3logic_vmmc1,
> diff --git a/arch/arm/mach-omap2/twl-common.c 
> b/arch/arm/mach-omap2/twl-common.c
> index 1cddcb2..5c9aa3f 100644
> --- a/arch/arm/mach-omap2/twl-common.c
> +++ b/arch/arm/mach-omap2/twl-common.c
> @@ -184,10 +184,6 @@ static struct twl_regulator_driver_data 
> omap3_vdd2_drvdata = {
>  void __init omap3_pmic_get_config(struct twl4030_platform_data *pmic_data,
> u32 pdata_flags, u32 regulators_flags)
>  {
> - if (!pmic_data->irq_base)
> - pmic_data->irq_base = TWL4030_IRQ_BASE;
> - if (!pmic_data->irq_end)
> - pmic_data->irq_end = TWL4030_IRQ_END;
>   if (!pmic_data->vdd1) {
>   omap3_vdd1.driver_data = &omap3_vdd1_drvdata;
>   omap3_vdd1_drvdata.data = voltdm_lookup("mpu_iva");
> @@ -415,11 +411,6 @@ static struct twl_regulator_driver_data 
> omap4_vdd3_drvdata = {
>  void __init omap4_pmic_get_config(struct twl4030_platform_data *pmic_data,
> u32 pdata_flags, u32 regulators_flags)
>  {
> - if (!pmic_data->irq_base)
> - pmic_data->irq_base = TWL6030_IRQ_BASE;
> - if (!pmic_data->irq_end)
> - pmic_data->irq_end = TWL6030_IRQ_END;
> -
>   if (!pmic_data->vdd1) {
>   omap4_vdd1.driver_data = &omap4_vdd1_drvdata;
>   omap4_vdd1_drvdata.data = voltdm_lookup("mpu");
> -- 

Looks right to me:

Acked-by: Tony Lindgren 
--
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] OMAP3: OPP: Test for IVA subsystem before attempting to add IVA OPP

[Kevin Hilman]

"Menon, Nishanth"  writes:

> On Wed, Mar 14, 2012 at 16:15, Kevin Hilman  wrote:
>> Maximilian Schwerin  writes:
>>
>>> From: Steve Sakoman 
>>>
>>> Don't try to add IVA OPPs for OMAP3 versions not containing an IVA
>>> subsystem, as this would make omap_init_opp_table fail.
>>>
>>> Signed-off-by: Steve Sakoman 
>>> Signed-off-by: Maximilian Schwerin 
>>
>> Minor: patch subjects for arch/arm/* core code need to have the ARM:
>> prefix also.
>>
>> Also, please run scripts/checkpatch.pl on your patch and fix the
>> warnings.
>>
>>> ---
>>>  arch/arm/mach-omap2/opp.c |    4 
>>>  1 files changed, 4 insertions(+), 0 deletions(-)
>>>
>>> diff --git a/arch/arm/mach-omap2/opp.c b/arch/arm/mach-omap2/opp.c
>>> index 9262a6b..414f2ec 100644
>>> --- a/arch/arm/mach-omap2/opp.c
>>> +++ b/arch/arm/mach-omap2/opp.c
>>> @@ -62,6 +62,10 @@ int __init omap_init_opp_table(struct omap_opp_def 
>>> *opp_def,
>>>                               __func__, i);
>>>                       return -EINVAL;
>>>               }
>>> +
>>> +             if ((strcmp(opp_def->hwmod_name,"iva") == 0) && 
>>> !omap3_has_iva())
>>> +                     continue;
>>> +
>>>               oh = omap_hwmod_lookup(opp_def->hwmod_name);
>>>               if (!oh || !oh->od) {
>>>                       pr_warn("%s: no hwmod or odev for %s, [%d] "
>>
>> Wouldn't the one-liner below do the same thing?
>>
>> Actually, your patch makes it less noisy at boot time, avoiding the
>> pr_warn(), so is probably better.
>
> The only issue i have with current patch is that it focusses to solve
> a specific device IVA.
> we could have similar variances if we had SGX/AESS device etc
> registered in the common
> table. a generic solution might be preferable - could we reduce the
> severity of pr_warn to pr_debug and do a continue instead?

I agree, that would be a better generic solution.

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

GPIO abort on 3630/Zoom3

[Kevin Hilman]

Tarun,

Can you investigate an abort during boot on 3630/Zoom3?

Both Tony and I are seeing the abort below on 3630/Zoom3.  I'm using
arm-soc/for-next and Tony is using linux-next, but we see the same abort.

Adding in your latest fixes series doesn't make the problem go away, but
backing out the GPIO runtime PM series does make the problem go away.

Kevin


Uncompressing Linux... done, booting the kernel.
[0.00] Booting Linux on physical CPU 0
[0.00] Linux version 3.3.0-rc7-pm+debug+initramfs-01079-g405139c 
(khilman@paris) (gcc version 4.6.1 (Ubuntu/Linaro 4.6.1-9ubuntu3) ) #15 SMP Wed 
Mar 14 13:06:34 PDT 2012
[0.00] CPU: ARMv7 Processor [413fc082] revision 2 (ARMv7), cr=10c53c7d
[0.00] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing 
instruction cache
[0.00] Machine: OMAP Zoom3 board
[0.00] bootconsole [earlycon0] enabled
[0.00] Memory policy: ECC disabled, Data cache writeback
[0.00] On node 0 totalpages: 32512
[0.00] free_area_init_node: node 0, pgdat c094f580, node_mem_map 
c0ea7000
[0.00]   Normal zone: 256 pages used for memmap
[0.00]   Normal zone: 0 pages reserved
[0.00]   Normal zone: 32256 pages, LIFO batch:7
[0.00] OMAP3630 ES1.0 (l2cache iva sgx neon isp 192mhz_clk )
[0.00] Clocking rate (Crystal/Core/MPU): 26.0/400/600 MHz
[0.00] PERCPU: Embedded 9 pages/cpu @c0fab000 s12864 r8192 d15808 u36864
[0.00] pcpu-alloc: s12864 r8192 d15808 u36864 alloc=9*4096
[0.00] pcpu-alloc: [0] 0 
[0.00] Built 1 zonelists in Zone order, mobility grouping on.  Total 
pages: 32256
[0.00] Kernel command line: mem=128M console=ttyS0,115200n8 ip=dhcp 
debug earlyprintk user_debug=0x
[0.00] PID hash table entries: 512 (order: -1, 2048 bytes)
[0.00] Dentry cache hash table entries: 16384 (order: 4, 65536 bytes)
[0.00] Inode-cache hash table entries: 8192 (order: 3, 32768 bytes)
[0.00] Memory: 127MB = 127MB total
[0.00] Memory: 113868k/113868k available, 17204k reserved, 0K highmem
[0.00] Virtual kernel memory layout:
[0.00] vector  : 0x - 0x1000   (   4 kB)
[0.00] fixmap  : 0xfff0 - 0xfffe   ( 896 kB)
[0.00] vmalloc : 0xc880 - 0xff00   ( 872 MB)
[0.00] lowmem  : 0xc000 - 0xc800   ( 128 MB)
[0.00] modules : 0xbf00 - 0xc000   (  16 MB)
[0.00]   .text : 0xc0008000 - 0xc0605560   (6134 kB)
[0.00]   .init : 0xc0606000 - 0xc08c2240   (2801 kB)
[0.00]   .data : 0xc08c4000 - 0xc0950ff0   ( 564 kB)
[0.00].bss : 0xc0951014 - 0xc0ea6c9c   (5464 kB)
[0.00] Hierarchical RCU implementation.
[0.00] NR_IRQS:474
[0.00] IRQ: Found an INTC at 0xfa20 (revision 4.0) with 96 
interrupts
[0.00] Total of 96 interrupts on 1 active controller
[0.00] OMAP clockevent source: GPTIMER1 at 32768 Hz
[0.00] sched_clock: 32 bits at 32kHz, resolution 30517ns, wraps every 
131071999ms
[0.00] Console: colour dummy device 80x30
[0.00] Lock dependency validator: Copyright (c) 2006 Red Hat, Inc., 
Ingo Molnar
[0.00] ... MAX_LOCKDEP_SUBCLASSES:  8
[0.00] ... MAX_LOCK_DEPTH:  48
[0.00] ... MAX_LOCKDEP_KEYS:8191
[0.00] ... CLASSHASH_SIZE:  4096
[0.00] ... MAX_LOCKDEP_ENTRIES: 16384
[0.00] ... MAX_LOCKDEP_CHAINS:  32768
[0.00] ... CHAINHASH_SIZE:  16384
[0.00]  memory used by lock dependency info: 3695 kB
[0.00]  per task-struct memory footprint: 1152 bytes
[0.056732] Calibrating delay loop... 597.64 BogoMIPS (lpj=2334720)
[0.098571] pid_max: default: 32768 minimum: 301
[0.104125] Security Framework initialized
[0.108673] Mount-cache hash table entries: 512
[0.118377] CPU: Testing write buffer coherency: ok
[0.124389] CPU0: thread -1, cpu 0, socket -1, mpidr 0
[0.129852] Setting up static identity map for 0x8043ac18 - 0x8043ac88
[0.138244] Brought up 1 CPUs
[0.141387] SMP: Total of 1 processors activated (597.64 BogoMIPS).
[0.170501] print_constraints: dummy: 
[0.17] NET: Registered protocol family 16
[0.182525] GPMC revision 5.0
[0.196075] gpiochip_add: registered GPIOs 0 to 31 on device: gpio
[0.203277] OMAP GPIO hardware version 2.5
[0.208831] gpiochip_add: registered GPIOs 32 to 63 on device: gpio
[0.217071] gpiochip_add: registered GPIOs 64 to 95 on device: gpio
[0.225128] gpiochip_add: registered GPIOs 96 to 127 on device: gpio
[0.233367] gpiochip_add: registered GPIOs 128 to 159 on device: gpio
[0.241546] gpiochip_add: registered GPIOs 160 to 191 on device: gpio
[0.254821] omap_mux_init: Add partition: #1: core, flags: 0
[0.267486] error setting wl12xx data: -38
[0.283905] Reprogramming SDRC clock to 4 Hz
[0.294250

Re: [PATCH 01/12] mfd: twl-core: don't depend on pdata->irq_base/end

[Kevin Hilman]

Kevin Hilman  writes:

> Benoit Cousson  writes:
>
>> From: Felipe Balbi 
>>
>> With sparse IRQs the driver shouldn't depend at all on
>> any IRQ values coming from board-file.
>>
>> Remove every occurences of pdata->irq_base/end.
>
> Well, not quite *every*. :)
>
> If the driver isn't going to use those fields anymore, they should also
> be removed from the pdata struct too[1].  Also, the remaining board/init
> code that is initializing those fields should be removed as well[2], since
> it obviously has no effect.
>
> The first patch below should probably be folded into this one, and then
> the 2nd patch removes all the users.

Below is a correct version of the 2nd patch which removes all the users.

The previous version wouldn't apply cleanly because I generated it on
top of a local branch that also included some other changes to
twl-common.c from the SMPS regulator series (which seems to have missed
the window for v3.4.)

This one applies cleanly on your for_3.4/twl_irq_gpio_mmc_fix branch.

Kevin

>From b59a4754fb66f6f729ebbd0563c4cd2bd2cda56e Mon Sep 17 00:00:00 2001
From: Kevin Hilman 
Date: Wed, 14 Mar 2012 13:56:01 -0700
Subject: [PATCH] ARM: OMAP2+: TWL: remove usage of pdata->irq_base/_end

The driver has been converted to use SPARSE_IRQ and no longer needs to
be passed IRQ base/end.  The driver no longer uses these fields, so
remove them from the reamaining users.

Signed-off-by: Kevin Hilman 
---
 arch/arm/mach-omap2/board-2430sdp.c|3 ---
 arch/arm/mach-omap2/board-omap3logic.c |3 ---
 arch/arm/mach-omap2/twl-common.c   |   10 --
 3 files changed, 16 deletions(-)

diff --git a/arch/arm/mach-omap2/board-2430sdp.c 
b/arch/arm/mach-omap2/board-2430sdp.c
index 7370983..7dfcb96 100644
--- a/arch/arm/mach-omap2/board-2430sdp.c
+++ b/arch/arm/mach-omap2/board-2430sdp.c
@@ -218,9 +218,6 @@ static struct twl4030_gpio_platform_data sdp2430_gpio_data 
= {
 };
 
 static struct twl4030_platform_data sdp2430_twldata = {
-   .irq_base   = TWL4030_IRQ_BASE,
-   .irq_end= TWL4030_IRQ_END,
-
/* platform_data for children goes here */
.gpio   = &sdp2430_gpio_data,
.vmmc1  = &sdp2430_vmmc1,
diff --git a/arch/arm/mach-omap2/board-omap3logic.c 
b/arch/arm/mach-omap2/board-omap3logic.c
index 4198dd0..0b053b4 100644
--- a/arch/arm/mach-omap2/board-omap3logic.c
+++ b/arch/arm/mach-omap2/board-omap3logic.c
@@ -85,9 +85,6 @@ static struct twl4030_gpio_platform_data omap3logic_gpio_data 
= {
 };
 
 static struct twl4030_platform_data omap3logic_twldata = {
-   .irq_base   = TWL4030_IRQ_BASE,
-   .irq_end= TWL4030_IRQ_END,
-
/* platform_data for children goes here */
.gpio   = &omap3logic_gpio_data,
.vmmc1  = &omap3logic_vmmc1,
diff --git a/arch/arm/mach-omap2/twl-common.c b/arch/arm/mach-omap2/twl-common.c
index 10b20c6..ce349ac 100644
--- a/arch/arm/mach-omap2/twl-common.c
+++ b/arch/arm/mach-omap2/twl-common.c
@@ -129,11 +129,6 @@ static struct regulator_init_data omap3_vpll2_idata = {
 void __init omap3_pmic_get_config(struct twl4030_platform_data *pmic_data,
  u32 pdata_flags, u32 regulators_flags)
 {
-   if (!pmic_data->irq_base)
-   pmic_data->irq_base = TWL4030_IRQ_BASE;
-   if (!pmic_data->irq_end)
-   pmic_data->irq_end = TWL4030_IRQ_END;
-
/* Common platform data configurations */
if (pdata_flags & TWL_COMMON_PDATA_USB && !pmic_data->usb)
pmic_data->usb = &omap3_usb_pdata;
@@ -287,11 +282,6 @@ static struct regulator_init_data omap4_clk32kg_idata = {
 void __init omap4_pmic_get_config(struct twl4030_platform_data *pmic_data,
  u32 pdata_flags, u32 regulators_flags)
 {
-   if (!pmic_data->irq_base)
-   pmic_data->irq_base = TWL6030_IRQ_BASE;
-   if (!pmic_data->irq_end)
-   pmic_data->irq_end = TWL6030_IRQ_END;
-
/* Common platform data configurations */
if (pdata_flags & TWL_COMMON_PDATA_USB && !pmic_data->usb)
pmic_data->usb = &omap4_usb_pdata;
-- 
1.7.9.2

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

Re: [PATCH] OMAP3: OPP: Test for IVA subsystem before attempting to add IVA OPP

[Menon, Nishanth]

On Wed, Mar 14, 2012 at 16:15, Kevin Hilman  wrote:
> Maximilian Schwerin  writes:
>
>> From: Steve Sakoman 
>>
>> Don't try to add IVA OPPs for OMAP3 versions not containing an IVA
>> subsystem, as this would make omap_init_opp_table fail.
>>
>> Signed-off-by: Steve Sakoman 
>> Signed-off-by: Maximilian Schwerin 
>
> Minor: patch subjects for arch/arm/* core code need to have the ARM:
> prefix also.
>
> Also, please run scripts/checkpatch.pl on your patch and fix the
> warnings.
>
>> ---
>>  arch/arm/mach-omap2/opp.c |    4 
>>  1 files changed, 4 insertions(+), 0 deletions(-)
>>
>> diff --git a/arch/arm/mach-omap2/opp.c b/arch/arm/mach-omap2/opp.c
>> index 9262a6b..414f2ec 100644
>> --- a/arch/arm/mach-omap2/opp.c
>> +++ b/arch/arm/mach-omap2/opp.c
>> @@ -62,6 +62,10 @@ int __init omap_init_opp_table(struct omap_opp_def 
>> *opp_def,
>>                               __func__, i);
>>                       return -EINVAL;
>>               }
>> +
>> +             if ((strcmp(opp_def->hwmod_name,"iva") == 0) && 
>> !omap3_has_iva())
>> +                     continue;
>> +
>>               oh = omap_hwmod_lookup(opp_def->hwmod_name);
>>               if (!oh || !oh->od) {
>>                       pr_warn("%s: no hwmod or odev for %s, [%d] "
>
> Wouldn't the one-liner below do the same thing?
>
> Actually, your patch makes it less noisy at boot time, avoiding the
> pr_warn(), so is probably better.

The only issue i have with current patch is that it focusses to solve
a specific device IVA.
we could have similar variances if we had SGX/AESS device etc
registered in the common
table. a generic solution might be preferable - could we reduce the
severity of pr_warn to pr_debug and do a continue instead?

>
> Kevin
>
> diff --git a/arch/arm/mach-omap2/opp.c b/arch/arm/mach-omap2/opp.c
> index 9262a6b..d3d4fa2 100644
> --- a/arch/arm/mach-omap2/opp.c
> +++ b/arch/arm/mach-omap2/opp.c
> @@ -67,7 +67,7 @@ int __init omap_init_opp_table(struct omap_opp_def *opp_def,
>                        pr_warn("%s: no hwmod or odev for %s, [%d] "
>                                "cannot add OPPs.\n", __func__,
>                                opp_def->hwmod_name, i);
> -                       return -EINVAL;
> +                       continue;
>                }
>                dev = &oh->od->pdev->dev;


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

Re: [PATCH 00/12] mfd: twl: Fix for irqdomain/next + SPARSE_IRQ + MMC card detect

[Kevin Hilman]

"Cousson, Benoit"  writes:

> Hi Kevin,
>
> On 3/14/2012 9:50 PM, Kevin Hilman wrote:
>> Hi Benoit,
>>
>> Benoit Cousson  writes:
>>
>> [...]
>>
>>> This is not for pull-request, becasue it is based on irqdomain + OMAP
>>> IRQ DT series + OMAP twl DT series yet to be pushed.
>>
>> What's the status of this series?
>
> I sent earlier today the pull request to Samuel.
>
> Here is the branch for information: for_3.4/twl_irq_gpio_mmc_fix
>
>> At least 'gpio/twl: Allocate irq_desc dynamically for SPARSE_IRQ
>> support' is needed in mainline (linux-next) now since without it, non-DT
>> boots will dump a big fat warning trace[2].
>
> Yeah, I know :-(
>
>> Also FYI, I needed the patch below[1] in order to build this series.
>
> That's weird, this include was added by the following commit
> a7cbb9b15d55dff0488b1a6d93929c2386d8632b at 3.2 time frame.

OK.

> What branch are you using?

I was using your for_3.4/twl_irq_gpio_cleanup, but had some merge
conflicts.  Maybe I mis-merged something and dropped that include.

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

Re: [PATCH 01/12] mfd: twl-core: don't depend on pdata->irq_base/end

[Kevin Hilman]

"Cousson, Benoit"  writes:

> On 3/14/2012 9:59 PM, Kevin Hilman wrote:
>> Benoit Cousson  writes:
>>
>>> From: Felipe Balbi
>>>
>>> With sparse IRQs the driver shouldn't depend at all on
>>> any IRQ values coming from board-file.
>>>
>>> Remove every occurences of pdata->irq_base/end.
>>
>> Well, not quite *every*. :)
>
> Hehe, good catch, thanks.
>
>> If the driver isn't going to use those fields anymore, they should also
>> be removed from the pdata struct too[1].  Also, the remaining board/init
>> code that is initializing those fields should be removed as well[2], since
>> it obviously has no effect.
>>
>> The first patch below should probably be folded into this one, and then
>> the 2nd patch removes all the users.
>
> We should probably remove all the users before removing the attribute?
> It looks like your patches are ordered in the opposite way.

Agreed.

> I'll add that in the series and repost the pull request.

Great, thanks.

Kevin
--
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] OMAP3: OPP: Test for IVA subsystem before attempting to add IVA OPP

[Kevin Hilman]

Maximilian Schwerin  writes:

> From: Steve Sakoman 
>
> Don't try to add IVA OPPs for OMAP3 versions not containing an IVA
> subsystem, as this would make omap_init_opp_table fail.
>
> Signed-off-by: Steve Sakoman 
> Signed-off-by: Maximilian Schwerin 

Minor: patch subjects for arch/arm/* core code need to have the ARM:
prefix also.

Also, please run scripts/checkpatch.pl on your patch and fix the
warnings.

> ---
>  arch/arm/mach-omap2/opp.c |4 
>  1 files changed, 4 insertions(+), 0 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/opp.c b/arch/arm/mach-omap2/opp.c
> index 9262a6b..414f2ec 100644
> --- a/arch/arm/mach-omap2/opp.c
> +++ b/arch/arm/mach-omap2/opp.c
> @@ -62,6 +62,10 @@ int __init omap_init_opp_table(struct omap_opp_def 
> *opp_def,
>   __func__, i);
>   return -EINVAL;
>   }
> +
> + if ((strcmp(opp_def->hwmod_name,"iva") == 0) && 
> !omap3_has_iva())
> + continue;
> +
>   oh = omap_hwmod_lookup(opp_def->hwmod_name);
>   if (!oh || !oh->od) {
>   pr_warn("%s: no hwmod or odev for %s, [%d] "

Wouldn't the one-liner below do the same thing?

Actually, your patch makes it less noisy at boot time, avoiding the
pr_warn(), so is probably better.

Kevin

diff --git a/arch/arm/mach-omap2/opp.c b/arch/arm/mach-omap2/opp.c
index 9262a6b..d3d4fa2 100644
--- a/arch/arm/mach-omap2/opp.c
+++ b/arch/arm/mach-omap2/opp.c
@@ -67,7 +67,7 @@ int __init omap_init_opp_table(struct omap_opp_def *opp_def,
pr_warn("%s: no hwmod or odev for %s, [%d] "
"cannot add OPPs.\n", __func__,
opp_def->hwmod_name, i);
-   return -EINVAL;
+   continue;
}
dev = &oh->od->pdev->dev;
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 01/12] mfd: twl-core: don't depend on pdata->irq_base/end

[Cousson, Benoit]

On 3/14/2012 9:59 PM, Kevin Hilman wrote:

Benoit Cousson  writes:


From: Felipe Balbi

With sparse IRQs the driver shouldn't depend at all on
any IRQ values coming from board-file.

Remove every occurences of pdata->irq_base/end.


Well, not quite *every*. :)


Hehe, good catch, thanks.


If the driver isn't going to use those fields anymore, they should also
be removed from the pdata struct too[1].  Also, the remaining board/init
code that is initializing those fields should be removed as well[2], since
it obviously has no effect.

The first patch below should probably be folded into this one, and then
the 2nd patch removes all the users.


We should probably remove all the users before removing the attribute? 
It looks like your patches are ordered in the opposite way.


I'll add that in the series and repost the pull request.

Regards,
Benoit



Kevin

[1]
 From 70a1833ca20142ef5b6b96dbc92a63c7f8ef9a04 Mon Sep 17 00:00:00 2001
From: Kevin Hilman
Date: Wed, 14 Mar 2012 13:55:31 -0700
Subject: [PATCH 1/2] mfd: twl-core: remove pdata->irq_base/end

Signed-off-by: Kevin Hilman
---
  include/linux/i2c/twl.h |1 -
  1 file changed, 1 deletion(-)

diff --git a/include/linux/i2c/twl.h b/include/linux/i2c/twl.h
index 2463b61..fa76006 100644
--- a/include/linux/i2c/twl.h
+++ b/include/linux/i2c/twl.h
@@ -697,7 +697,6 @@ struct twl4030_audio_data {
  };

  struct twl4030_platform_data {
-   unsignedirq_base, irq_end;
struct twl4030_clock_init_data  *clock;
struct twl4030_bci_platform_data*bci;
struct twl4030_gpio_platform_data   *gpio;


--
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/12] mfd: twl: Fix for irqdomain/next + SPARSE_IRQ + MMC card detect

[Cousson, Benoit]

Hi Kevin,

On 3/14/2012 9:50 PM, Kevin Hilman wrote:

Hi Benoit,

Benoit Cousson  writes:

[...]


This is not for pull-request, becasue it is based on irqdomain + OMAP
IRQ DT series + OMAP twl DT series yet to be pushed.


What's the status of this series?


I sent earlier today the pull request to Samuel.

Here is the branch for information: for_3.4/twl_irq_gpio_mmc_fix


At least 'gpio/twl: Allocate irq_desc dynamically for SPARSE_IRQ
support' is needed in mainline (linux-next) now since without it, non-DT
boots will dump a big fat warning trace[2].


Yeah, I know :-(


Also FYI, I needed the patch below[1] in order to build this series.


That's weird, this include was added by the following commit 
a7cbb9b15d55dff0488b1a6d93929c2386d8632b at 3.2 time frame.


What branch are you using?

Regards,
Benoit



Kevin

[1]
diff --git a/arch/arm/mach-omap2/board-generic.c 
b/arch/arm/mach-omap2/board-generic.c
index b8c74c7..8db1d64 100644
--- a/arch/arm/mach-omap2/board-generic.c
+++ b/arch/arm/mach-omap2/board-generic.c
@@ -15,6 +15,7 @@
  #include
  #include
  #include
+#include

  #include
  #include


[2]
[0.495117] twl4030: PIH (irq 7) chaining IRQs 368..401
[0.501190] twl4030: power (irq 373) chaining IRQs 402..409
[0.509429] twl4030: gpio (irq 368) chaining IRQs 410..427
[0.515319] [ cut here ]
[0.520202] WARNING: at /work/kernel/omap/pm/drivers/gpio/gpio-twl4030.c:410 
gpio_twl4030_probe+0x44/0x214()
[0.530395] Modules linked in:
[0.533691] [] (unwind_backtrace+0x0/0xf0) from [] 
(warn_slowpath_common+0x4c/0x64)
[0.543640] [] (warn_slowpath_common+0x4c/0x64) from [] 
(warn_slowpath_null+0x1c/0x24)
[0.553680] [] (warn_slowpath_null+0x1c/0x24) from [] 
(gpio_twl4030_probe+0x44/0x214)
[0.563629] [] (gpio_twl4030_probe+0x44/0x214) from [] 
(platform_drv_probe+0x18/0x1c)
[0.573577] [] (platform_drv_probe+0x18/0x1c) from [] 
(really_probe+0x60/0x15c)
[0.583007] [] (really_probe+0x60/0x15c) from [] 
(driver_probe_device+0x48/0x60)
[0.592498] [] (driver_probe_device+0x48/0x60) from [] 
(bus_for_each_drv+0x5c/0x88)
[0.602264] [] (bus_for_each_drv+0x5c/0x88) from [] 
(device_attach+0x98/0xbc)
[0.611480] [] (device_attach+0x98/0xbc) from [] 
(bus_probe_device+0x88/0xac)
[0.620727] [] (bus_probe_device+0x88/0xac) from [] 
(device_add+0x278/0x358)
[0.629882] [] (device_add+0x278/0x358) from [] 
(platform_device_add+0xf8/0x1a4)
[0.639373] [] (platform_device_add+0xf8/0x1a4) from [] 
(add_numbered_child.constprop.0+0xb8/0xfc)
[0.650451] [] (add_numbered_child.constprop.0+0xb8/0xfc) from 
[] (add_children+0x44/0x6d0)
[0.660949] [] (add_children+0x44/0x6d0) from [] 
(twl_probe+0x354/0x3bc)
[0.669738] [] (twl_probe+0x354/0x3bc) from [] 
(i2c_device_probe+0xc0/0x100)
[0.678863] [] (i2c_device_probe+0xc0/0x100) from [] 
(really_probe+0x60/0x15c)
[0.688171] [] (really_probe+0x60/0x15c) from [] 
(driver_probe_device+0x48/0x60)
[0.697692] [] (driver_probe_device+0x48/0x60) from [] 
(bus_for_each_drv+0x5c/0x88)
[0.707458] [] (bus_for_each_drv+0x5c/0x88) from [] 
(device_attach+0x98/0xbc)
[0.716674] [] (device_attach+0x98/0xbc) from [] 
(bus_probe_device+0x88/0xac)
[0.725921] [] (bus_probe_device+0x88/0xac) from [] 
(device_add+0x278/0x358)
[0.735076] [] (device_add+0x278/0x358) from [] 
(i2c_new_device+0xec/0x160)
[0.744354] [] (i2c_new_device+0xec/0x160) from [] 
(i2c_register_adapter+0x168/0x220)
[0.754302] [] (i2c_register_adapter+0x168/0x220) from 
[] (i2c_add_numbered_adapter+0xd4/0xf0)
[0.765045] [] (i2c_add_numbered_adapter+0xd4/0xf0) from 
[] (omap_i2c_probe+0x334/0x424)
[0.775268] [] (omap_i2c_probe+0x334/0x424) from [] 
(platform_drv_probe+0x18/0x1c)
[0.784942] [] (platform_drv_probe+0x18/0x1c) from [] 
(really_probe+0x60/0x15c)
[0.794342] [] (really_probe+0x60/0x15c) from [] 
(driver_probe_device+0x48/0x60)
[0.803863] [] (driver_probe_device+0x48/0x60) from [] 
(__driver_attach+0x94/0x98)
[0.813537] [] (__driver_attach+0x94/0x98) from [] 
(bus_for_each_dev+0x50/0x7c)
[0.822937] [] (bus_for_each_dev+0x50/0x7c) from [] 
(bus_add_driver+0x184/0x248)
[0.832427] [] (bus_add_driver+0x184/0x248) from [] 
(driver_register+0x78/0x12c)
[0.841949] [] (driver_register+0x78/0x12c) from [] 
(do_one_initcall+0x34/0x178)
[0.851440] [] (do_one_initcall+0x34/0x178) from [] 
(kernel_init+0x8c/0x130)
[0.860565] [] (kernel_init+0x8c/0x130) from [] 
(kernel_thread_exit+0x0/0x8)
[0.870117] ---[ end trace 1b75b31a2719ed1c ]---


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

Re: [PATCH 01/12] mfd: twl-core: don't depend on pdata->irq_base/end

[Kevin Hilman]

Benoit Cousson  writes:

> From: Felipe Balbi 
>
> With sparse IRQs the driver shouldn't depend at all on
> any IRQ values coming from board-file.
>
> Remove every occurences of pdata->irq_base/end.

Well, not quite *every*. :)

If the driver isn't going to use those fields anymore, they should also
be removed from the pdata struct too[1].  Also, the remaining board/init
code that is initializing those fields should be removed as well[2], since
it obviously has no effect.

The first patch below should probably be folded into this one, and then
the 2nd patch removes all the users.

Kevin

[1]
>From 70a1833ca20142ef5b6b96dbc92a63c7f8ef9a04 Mon Sep 17 00:00:00 2001
From: Kevin Hilman 
Date: Wed, 14 Mar 2012 13:55:31 -0700
Subject: [PATCH 1/2] mfd: twl-core: remove pdata->irq_base/end

Signed-off-by: Kevin Hilman 
---
 include/linux/i2c/twl.h |1 -
 1 file changed, 1 deletion(-)

diff --git a/include/linux/i2c/twl.h b/include/linux/i2c/twl.h
index 2463b61..fa76006 100644
--- a/include/linux/i2c/twl.h
+++ b/include/linux/i2c/twl.h
@@ -697,7 +697,6 @@ struct twl4030_audio_data {
 };
 
 struct twl4030_platform_data {
-   unsignedirq_base, irq_end;
struct twl4030_clock_init_data  *clock;
struct twl4030_bci_platform_data*bci;
struct twl4030_gpio_platform_data   *gpio;
-- 
1.7.9.2


[2]
>From d2b7b518b4c66beb99fccfcb898001c11a2f6dc9 Mon Sep 17 00:00:00 2001
From: Kevin Hilman 
Date: Wed, 14 Mar 2012 13:56:01 -0700
Subject: [PATCH 2/2] ARM: OMAP2+: TWL: remove usage of pdata->irq_base/_end

The driver has been converted to use SPARSE_IRQ and no longer needs to
be passed IRQ base/end.  The driver no longer uses these fields, so
remove them from the reamaining users.

Signed-off-by: Kevin Hilman 
---
 arch/arm/mach-omap2/board-2430sdp.c|3 ---
 arch/arm/mach-omap2/board-omap3logic.c |3 ---
 arch/arm/mach-omap2/twl-common.c   |9 -
 3 files changed, 15 deletions(-)

diff --git a/arch/arm/mach-omap2/board-2430sdp.c 
b/arch/arm/mach-omap2/board-2430sdp.c
index c8bda62..b8b3700 100644
--- a/arch/arm/mach-omap2/board-2430sdp.c
+++ b/arch/arm/mach-omap2/board-2430sdp.c
@@ -218,9 +218,6 @@ static struct twl4030_gpio_platform_data sdp2430_gpio_data 
= {
 };
 
 static struct twl4030_platform_data sdp2430_twldata = {
-   .irq_base   = TWL4030_IRQ_BASE,
-   .irq_end= TWL4030_IRQ_END,
-
/* platform_data for children goes here */
.gpio   = &sdp2430_gpio_data,
.vmmc1  = &sdp2430_vmmc1,
diff --git a/arch/arm/mach-omap2/board-omap3logic.c 
b/arch/arm/mach-omap2/board-omap3logic.c
index 4a7d8c8..f145935 100644
--- a/arch/arm/mach-omap2/board-omap3logic.c
+++ b/arch/arm/mach-omap2/board-omap3logic.c
@@ -85,9 +85,6 @@ static struct twl4030_gpio_platform_data omap3logic_gpio_data 
= {
 };
 
 static struct twl4030_platform_data omap3logic_twldata = {
-   .irq_base   = TWL4030_IRQ_BASE,
-   .irq_end= TWL4030_IRQ_END,
-
/* platform_data for children goes here */
.gpio   = &omap3logic_gpio_data,
.vmmc1  = &omap3logic_vmmc1,
diff --git a/arch/arm/mach-omap2/twl-common.c b/arch/arm/mach-omap2/twl-common.c
index 1cddcb2..5c9aa3f 100644
--- a/arch/arm/mach-omap2/twl-common.c
+++ b/arch/arm/mach-omap2/twl-common.c
@@ -184,10 +184,6 @@ static struct twl_regulator_driver_data omap3_vdd2_drvdata 
= {
 void __init omap3_pmic_get_config(struct twl4030_platform_data *pmic_data,
  u32 pdata_flags, u32 regulators_flags)
 {
-   if (!pmic_data->irq_base)
-   pmic_data->irq_base = TWL4030_IRQ_BASE;
-   if (!pmic_data->irq_end)
-   pmic_data->irq_end = TWL4030_IRQ_END;
if (!pmic_data->vdd1) {
omap3_vdd1.driver_data = &omap3_vdd1_drvdata;
omap3_vdd1_drvdata.data = voltdm_lookup("mpu_iva");
@@ -415,11 +411,6 @@ static struct twl_regulator_driver_data omap4_vdd3_drvdata 
= {
 void __init omap4_pmic_get_config(struct twl4030_platform_data *pmic_data,
  u32 pdata_flags, u32 regulators_flags)
 {
-   if (!pmic_data->irq_base)
-   pmic_data->irq_base = TWL6030_IRQ_BASE;
-   if (!pmic_data->irq_end)
-   pmic_data->irq_end = TWL6030_IRQ_END;
-
if (!pmic_data->vdd1) {
omap4_vdd1.driver_data = &omap4_vdd1_drvdata;
omap4_vdd1_drvdata.data = voltdm_lookup("mpu");
-- 
1.7.9.2

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

Re: [PATCH 00/12] mfd: twl: Fix for irqdomain/next + SPARSE_IRQ + MMC card detect

[Kevin Hilman]

Hi Benoit,

Benoit Cousson  writes:

[...]

> This is not for pull-request, becasue it is based on irqdomain + OMAP
> IRQ DT series + OMAP twl DT series yet to be pushed.

What's the status of this series?

At least 'gpio/twl: Allocate irq_desc dynamically for SPARSE_IRQ
support' is needed in mainline (linux-next) now since without it, non-DT
boots will dump a big fat warning trace[2].  

Also FYI, I needed the patch below[1] in order to build this series.

Kevin

[1]
diff --git a/arch/arm/mach-omap2/board-generic.c 
b/arch/arm/mach-omap2/board-generic.c
index b8c74c7..8db1d64 100644
--- a/arch/arm/mach-omap2/board-generic.c
+++ b/arch/arm/mach-omap2/board-generic.c
@@ -15,6 +15,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 


[2]
[0.495117] twl4030: PIH (irq 7) chaining IRQs 368..401
[0.501190] twl4030: power (irq 373) chaining IRQs 402..409
[0.509429] twl4030: gpio (irq 368) chaining IRQs 410..427
[0.515319] [ cut here ]
[0.520202] WARNING: at /work/kernel/omap/pm/drivers/gpio/gpio-twl4030.c:410 
gpio_twl4030_probe+0x44/0x214()
[0.530395] Modules linked in:
[0.533691] [] (unwind_backtrace+0x0/0xf0) from [] 
(warn_slowpath_common+0x4c/0x64)
[0.543640] [] (warn_slowpath_common+0x4c/0x64) from [] 
(warn_slowpath_null+0x1c/0x24)
[0.553680] [] (warn_slowpath_null+0x1c/0x24) from [] 
(gpio_twl4030_probe+0x44/0x214)
[0.563629] [] (gpio_twl4030_probe+0x44/0x214) from [] 
(platform_drv_probe+0x18/0x1c)
[0.573577] [] (platform_drv_probe+0x18/0x1c) from [] 
(really_probe+0x60/0x15c)
[0.583007] [] (really_probe+0x60/0x15c) from [] 
(driver_probe_device+0x48/0x60)
[0.592498] [] (driver_probe_device+0x48/0x60) from [] 
(bus_for_each_drv+0x5c/0x88)
[0.602264] [] (bus_for_each_drv+0x5c/0x88) from [] 
(device_attach+0x98/0xbc)
[0.611480] [] (device_attach+0x98/0xbc) from [] 
(bus_probe_device+0x88/0xac)
[0.620727] [] (bus_probe_device+0x88/0xac) from [] 
(device_add+0x278/0x358)
[0.629882] [] (device_add+0x278/0x358) from [] 
(platform_device_add+0xf8/0x1a4)
[0.639373] [] (platform_device_add+0xf8/0x1a4) from [] 
(add_numbered_child.constprop.0+0xb8/0xfc)
[0.650451] [] (add_numbered_child.constprop.0+0xb8/0xfc) from 
[] (add_children+0x44/0x6d0)
[0.660949] [] (add_children+0x44/0x6d0) from [] 
(twl_probe+0x354/0x3bc)
[0.669738] [] (twl_probe+0x354/0x3bc) from [] 
(i2c_device_probe+0xc0/0x100)
[0.678863] [] (i2c_device_probe+0xc0/0x100) from [] 
(really_probe+0x60/0x15c)
[0.688171] [] (really_probe+0x60/0x15c) from [] 
(driver_probe_device+0x48/0x60)
[0.697692] [] (driver_probe_device+0x48/0x60) from [] 
(bus_for_each_drv+0x5c/0x88)
[0.707458] [] (bus_for_each_drv+0x5c/0x88) from [] 
(device_attach+0x98/0xbc)
[0.716674] [] (device_attach+0x98/0xbc) from [] 
(bus_probe_device+0x88/0xac)
[0.725921] [] (bus_probe_device+0x88/0xac) from [] 
(device_add+0x278/0x358)
[0.735076] [] (device_add+0x278/0x358) from [] 
(i2c_new_device+0xec/0x160)
[0.744354] [] (i2c_new_device+0xec/0x160) from [] 
(i2c_register_adapter+0x168/0x220)
[0.754302] [] (i2c_register_adapter+0x168/0x220) from 
[] (i2c_add_numbered_adapter+0xd4/0xf0)
[0.765045] [] (i2c_add_numbered_adapter+0xd4/0xf0) from 
[] (omap_i2c_probe+0x334/0x424)
[0.775268] [] (omap_i2c_probe+0x334/0x424) from [] 
(platform_drv_probe+0x18/0x1c)
[0.784942] [] (platform_drv_probe+0x18/0x1c) from [] 
(really_probe+0x60/0x15c)
[0.794342] [] (really_probe+0x60/0x15c) from [] 
(driver_probe_device+0x48/0x60)
[0.803863] [] (driver_probe_device+0x48/0x60) from [] 
(__driver_attach+0x94/0x98)
[0.813537] [] (__driver_attach+0x94/0x98) from [] 
(bus_for_each_dev+0x50/0x7c)
[0.822937] [] (bus_for_each_dev+0x50/0x7c) from [] 
(bus_add_driver+0x184/0x248)
[0.832427] [] (bus_add_driver+0x184/0x248) from [] 
(driver_register+0x78/0x12c)
[0.841949] [] (driver_register+0x78/0x12c) from [] 
(do_one_initcall+0x34/0x178)
[0.851440] [] (do_one_initcall+0x34/0x178) from [] 
(kernel_init+0x8c/0x130)
[0.860565] [] (kernel_init+0x8c/0x130) from [] 
(kernel_thread_exit+0x0/0x8)
[0.870117] ---[ end trace 1b75b31a2719ed1c ]---
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC PATCH] of: DMA helpers: manage generic requests specification

[Stephen Warren]

On 03/14/2012 11:47 AM, Nicolas Ferre wrote:
...
> I do have the will to avoid the treats of memory corruption in case of
> malformed DT data, as Stephen was saying. But, on the other hand I do
> not know really if this can happen: if the .xlate() function which is
> provided by the DMA controller is well written, it should check for
> proper args_count or maximum string size. I do not have the feeling that
> adding an enum will enforce the security here.
> 
> Do you know a way to enforce security of this "void *" parameter or the
> check of number of cells + the due diligence of .xlate() function
> writers will be enough?

I guess if the only source of the data is a driver's of_xlate function,
and it's only being passed back to that same driver and never
interpreted elsewhere, then its probably reasonable to assume that's
enough for safety.
--
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] usbnet: fix spinlock recursion

[Albert Herranz]

On 03/14/2012 04:42 PM, Greg KH wrote:
> On Wed, Mar 14, 2012 at 02:45:27PM +0100, Maximilian Schwerin wrote:
>> From: Albert Herranz 
>>
>> This patch fixes the following spinlock recursion bug seen when bringing down
>> the ethernet interface.
>>
[...]
> Hint, use scripts/get_maintainer.pl to find the right person to send
> this patch to (you missed a list, and because of that, the patch will
> never get applied...)
> 
> thanks,
> 
> greg k-h
> 

Hi,

I think that David Miller already picked up a similar patch recently (with a 
different approach).

http://marc.info/?l=linux-netdev&m=133115161606222&w=2

Cheers,
Albert


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

Re: [RFC PATCH] of: DMA helpers: manage generic requests specification

[Nicolas Ferre]

On 03/05/2012 04:36 PM, Grant Likely :
> On Wed, Feb 29, 2012 at 03:54:08PM +0100, Nicolas Ferre wrote:
>> By making DMA controllers register a generic translation
>> function, we allow the management of any type of DMA requests
>> specification.
>> The void * output of an of_dma_xlate() function that will be implemented
>> by the DMA controller can carry any type of "dma-request" argument.
>>
>> The DMA client will search its associated DMA controller in the list
>> and call the registered of_dam_xlate() function to retrieve the
>> request values.
>>
>> One simple xlate function is provided for the "single number" type
>> of request biding.
>>
>> This implementation is independent from dmaengine so it can also be
>> used by legacy drivers.
>>
>> Signed-off-by: Nicolas Ferre 
>> Cc: Benoit Cousson 
>> Cc: Stephen Warren 
>> Cc: Grant Likely 
>> Cc: Russell King 
>> Cc: Rob Herring 
>> ---
>> Hi all,
>>
>> Here are my thoughts about the DMA helpers for device tree.
>> This patch goes on top of Benoit's ones. My goal was to keep this separated
>> from any DMA infrastructure (dmaengine not needed, nor any other DMA
>> implementation).
>>
>> It is to keep the ball rolling, so do not hesitate to comment.
>>
>> Best regards,
>>
>>
>>  Documentation/devicetree/bindings/dma/dma.txt |   29 +++--
>>  drivers/of/dma.c  |  161 
>> ++---
>>  include/linux/of_dma.h|   33 +-
>>  3 files changed, 186 insertions(+), 37 deletions(-)
>>
>> diff --git a/Documentation/devicetree/bindings/dma/dma.txt 
>> b/Documentation/devicetree/bindings/dma/dma.txt
>> index 7f2a301..c49e98d 100644
>> --- a/Documentation/devicetree/bindings/dma/dma.txt
>> +++ b/Documentation/devicetree/bindings/dma/dma.txt
>> @@ -6,9 +6,8 @@ DMA request line that goes from an IP to a DMA controller.
>>  
>>  * DMA controller
>>  
>> -Required properties:
>> -- dma-controller: Mark the device as a DMA controller
>> -- #dma-cells: Number of cell for each DMA line, must be one.
>> +Required property:
>> +- #dma-cells: Number of cells for each DMA line.
>>  
>>  
>>  Example:
>> @@ -17,7 +16,6 @@ Example:
>>  compatible = "ti,sdma-omap4"
>>  reg = <0x4800 0x1000>;
>>  interrupts = <12>;
>> -dma-controller;
>>  #dma-cells = <1>;
>>  };
>>  
>> @@ -25,20 +23,23 @@ Example:
>>  
>>  * DMA client
>>  
>> -Client drivers should specify the DMA request numbers using a phandle to
>> -the controller + the DMA request number on that controller.
>> +Client drivers should specify the DMA request property using a phandle to
>> +the controller. If needed, the DMA request identity on that controller is 
>> then
>> +added followed by optional request specifications.
>>  
>> -Required properties:
>> -- dma-request: List of pair phandle + dma-request per line
>> +Required property:
>> +- dma-request: List of phandle + dma-request + request specifications,
>> +  one group per request "line".
>> +Optional property:
>>  - dma-request-names: list of strings in the same order as the 
>> dma-request
>>in the dma-request property.
>>  
>>  
>>  Example:
>>  
>> -i2c1: i2c@1 {
>> -...
>> -dma-request = <&sdma 2 &sdma 3>;
>> -dma-request-names = "tx", "rx";
>> -...
>> -};
>> +i2c1: i2c@1 {
>> +...
>> +dma-request = <&sdma 2 &sdma 3>;
>> +dma-request-names = "tx", "rx";
>> +...
>> +};
>> diff --git a/drivers/of/dma.c b/drivers/of/dma.c
>> index d4927e2..e0c6fd9 100644
>> --- a/drivers/of/dma.c
>> +++ b/drivers/of/dma.c
>> @@ -13,41 +13,145 @@
>>  #include 
>>  #include 
>>  #include 
>> +#include 
>> +#include 
>>  #include 
>>  #include 
>>  
>> +static LIST_HEAD(of_dma_list);
>> +
>> +/**
>> + * of_dma_find_controller() - Find a DMA controller in DT DMA helpers list
>> + * @np: device node of DMA controller
>> + */
>> +static struct of_dma *of_dma_find_controller(struct device_node *np)
>> +{
>> +struct of_dma   *ofdma;
>> +
>> +list_for_each_entry_rcu(ofdma, &of_dma_list, of_dma_controllers) {
>> +if (ofdma->of_node == np)
>> +return ofdma;
>> +}
>> +
>> +return NULL;
>> +}
>> +
>>  /**
>> - * of_get_dma_request() - Get a DMA request number and dma-controller node
>> + * of_dma_controller_register() - Register a DMA controller to DT DMA 
>> helpers
>> + * @np: device node of DMA controller
>> + * @of_dma_xlate:   generic translation function which converts a phandle
>> + *  arguments list into a generic output value
>> + *
>> + * Returns 0 on success or appropriate errno value on error.
>> + *
>> + * If #dma-cells is not specified in DMA controller device tree node, we 
>> assume
>> + * that the DMA controller phandle will come without argument.
>> + *
>> + * Allocated memory sould be freed with apropriate of_dma_controller_f

[PATCH] OMAP3: OPP: Test for IVA subsystem before attempting to add IVA OPP

[Maximilian Schwerin]

From: Steve Sakoman 

Don't try to add IVA OPPs for OMAP3 versions not containing an IVA
subsystem, as this would make omap_init_opp_table fail.

Signed-off-by: Steve Sakoman 
Signed-off-by: Maximilian Schwerin 
---
 arch/arm/mach-omap2/opp.c |4 
 1 files changed, 4 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-omap2/opp.c b/arch/arm/mach-omap2/opp.c
index 9262a6b..414f2ec 100644
--- a/arch/arm/mach-omap2/opp.c
+++ b/arch/arm/mach-omap2/opp.c
@@ -62,6 +62,10 @@ int __init omap_init_opp_table(struct omap_opp_def *opp_def,
__func__, i);
return -EINVAL;
}
+
+   if ((strcmp(opp_def->hwmod_name,"iva") == 0) && 
!omap3_has_iva())
+   continue;
+
oh = omap_hwmod_lookup(opp_def->hwmod_name);
if (!oh || !oh->od) {
pr_warn("%s: no hwmod or odev for %s, [%d] "
-- 
1.7.0.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: [GIT PULL] cpufreq: OMAP updates for v3.4

[Grazvydas Ignotas]

On Wed, Mar 14, 2012 at 7:22 PM, Kevin Hilman  wrote:
> Grazvydas Ignotas  writes:
>
> [...]
>
>>> Russell King (1):
>>>      cpufreq: OMAP driver depends CPUfreq tables
>>
>> It seems this one got messed up, it says "default ARCH_OMAP2PLUS"
>> instead of depends.
>
> That was intentional.  What do you think is messed up about it?
>
> It's the same as saying:
>
>     depends on ARCH_OMAP2PLUS
>     default y

Hm, somehow I've never encountered this syntax, but it more looks like
it means "default y if ARCH_OMAP2PLUS" instead of that.

Checked this with menuconfig now:
  default ARCH_OMAP2PLUS
resolves to:
  ARCH_HAS_CPUFREQ [=y] && CPU_FREQ [=y] && ARM [=y]

..which might cause build break when OMAP is not selected, and

  depends on ARCH_OMAP2PLUS
  default y
resolves to:
  ARCH_HAS_CPUFREQ [=y] && CPU_FREQ [=y] && ARM [=y] && ARCH_OMAP2PLUS [=y]

..which should be randconfig friendly.

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

Re: [GIT PULL 1/7] non-critical fixes part3 for upcoming merge window

[Tony Lindgren]

* Arnd Bergmann  [120314 10:00]:
> On Wednesday 14 March 2012, Tony Lindgren wrote:
> > * Olof Johansson  [120310 10:26]:
> > > On Thu, Mar 08, 2012 at 12:53:29PM -0800, Tony Lindgren wrote:
> > > > Hi Olof,
> > > > 
> > > > Here are two more pre-emptive fixes for upcoming merge
> > > > window to pull into arm-soc/next/fixes-non-critical.
> > > > 
> > > > Now with the fixes finallny out of the way after all
> > > > the cleanup related changes, as a reply to this pull
> > > > request I'm posting some more pull requests for cleanup
> > > > and some minor board changes.
> > > 
> > > Pulled request 1-7.
> > 
> > Now with another -rc, can you please pull in also
> > 2 - 7 in this series?
> 
> Hi Tony,
> 
> I'm pretty sure that Olof pulled all the branches the first time
> around, i.e. 1-7, not just 1/7. Please check the for-next
> branch and tell us if there is anything still missing.

Indeed, all seven are there! Thanks,

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

Re: [GIT PULL] cpufreq: OMAP updates for v3.4

[Kevin Hilman]

Grazvydas Ignotas  writes:

[...]

>> Russell King (1):
>>      cpufreq: OMAP driver depends CPUfreq tables
>
> It seems this one got messed up, it says "default ARCH_OMAP2PLUS"
> instead of depends.

That was intentional.  What do you think is messed up about it?

It's the same as saying:

 depends on ARCH_OMAP2PLUS
 default y

Kevin

--
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] omap: opp: test for iva before attempting to set iva opp

[Kevin Hilman]

Maximilian Schwerin  writes:

> From: Steve Sakoman 

Thanks for the patch.

Please add a descriptive changelog here.

Also, please Cc linux-arm-ker...@lists.infradead.org for all
upstream-bound patches.

Kevin

> Signed-off-by: Steve Sakoman 
> Signed-off-by: Maximilian Schwerin 
> ---
>  arch/arm/mach-omap2/opp.c |4 
>  1 files changed, 4 insertions(+), 0 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/opp.c b/arch/arm/mach-omap2/opp.c
> index 9262a6b..414f2ec 100644
> --- a/arch/arm/mach-omap2/opp.c
> +++ b/arch/arm/mach-omap2/opp.c
> @@ -62,6 +62,10 @@ int __init omap_init_opp_table(struct omap_opp_def 
> *opp_def,
>   __func__, i);
>   return -EINVAL;
>   }
> +
> + if ((strcmp(opp_def->hwmod_name,"iva") == 0) && 
> !omap3_has_iva())
> + continue;
> +
>   oh = omap_hwmod_lookup(opp_def->hwmod_name);
>   if (!oh || !oh->od) {
>   pr_warn("%s: no hwmod or odev for %s, [%d] "
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [GIT PULL 1/7] non-critical fixes part3 for upcoming merge window

[Arnd Bergmann]

On Wednesday 14 March 2012, Tony Lindgren wrote:
> * Olof Johansson  [120310 10:26]:
> > On Thu, Mar 08, 2012 at 12:53:29PM -0800, Tony Lindgren wrote:
> > > Hi Olof,
> > > 
> > > Here are two more pre-emptive fixes for upcoming merge
> > > window to pull into arm-soc/next/fixes-non-critical.
> > > 
> > > Now with the fixes finallny out of the way after all
> > > the cleanup related changes, as a reply to this pull
> > > request I'm posting some more pull requests for cleanup
> > > and some minor board changes.
> > 
> > Pulled request 1-7.
> 
> Now with another -rc, can you please pull in also
> 2 - 7 in this series?

Hi Tony,

I'm pretty sure that Olof pulled all the branches the first time
around, i.e. 1-7, not just 1/7. Please check the for-next
branch and tell us if there is anything still missing.

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

Re: [GIT PULL] cpufreq: OMAP updates for v3.4

[Dave Jones]

On Wed, Mar 14, 2012 at 06:41:51PM +0200, Grazvydas Ignotas wrote:

 > > Afzal Mohammed (1):
 > >      cpufreq: OMAP: specify range for voltage scaling
 > >
 > > Kevin Hilman (1):
 > >      cpufreq: OMAP: scale voltage along with frequency
 > >
 > > Russell King (1):
 > >      cpufreq: OMAP driver depends CPUfreq tables
 > 
 > It seems this one got messed up, it says "default ARCH_OMAP2PLUS"
 > instead of depends.
 > Can it be dropped and resent, or do we need a fixup patch?

Please send a follow-up patch if necessary.

Dave

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

Re: [GIT PULL] cpufreq: OMAP updates for v3.4

[Grazvydas Ignotas]

On Wed, Mar 7, 2012 at 10:20 PM, Kevin Hilman  wrote:
> Dave,
>
> Please pull the following OMAP CPUfreq driver changes for v3.4.
>
> Thanks,
>
> Kevin
>
>
>
> The following changes since commit b01543dfe67bb1d191998e90d20534dc354de059:
>
>  Linux 3.3-rc4 (2012-02-18 15:53:33 -0800)
>
> are available in the git repository at:
>
>  git://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-omap-pm.git 
> for_3.4/cpufreq
>
> for you to fetch changes up to 42daffd2d6c665716d442d518022ecaad17ddf64:
>
>  cpufreq: OMAP: specify range for voltage scaling (2012-03-02 13:55:57 -0800)
>
> 
> Afzal Mohammed (1):
>      cpufreq: OMAP: specify range for voltage scaling
>
> Kevin Hilman (1):
>      cpufreq: OMAP: scale voltage along with frequency
>
> Russell King (1):
>      cpufreq: OMAP driver depends CPUfreq tables

It seems this one got messed up, it says "default ARCH_OMAP2PLUS"
instead of depends.
Can it be dropped and resent, or do we need a fixup patch?

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

Re: [GIT PULL 1/7] non-critical fixes part3 for upcoming merge window

[Tony Lindgren]

Hi Olof,

* Olof Johansson  [120310 10:26]:
> On Thu, Mar 08, 2012 at 12:53:29PM -0800, Tony Lindgren wrote:
> > Hi Olof,
> > 
> > Here are two more pre-emptive fixes for upcoming merge
> > window to pull into arm-soc/next/fixes-non-critical.
> > 
> > Now with the fixes finallny out of the way after all
> > the cleanup related changes, as a reply to this pull
> > request I'm posting some more pull requests for cleanup
> > and some minor board changes.
> 
> Pulled request 1-7.

Now with another -rc, can you please pull in also
2 - 7 in this series?

Regards,

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

Re: [PATCH v2] OMAPDSS: provide default timings functions for panels

[Grazvydas Ignotas]

On Wed, Mar 14, 2012 at 1:22 PM, Tomi Valkeinen  wrote:
> Hi,
>
> On Mon, 2012-03-12 at 13:27 +0200, Grazvydas Ignotas wrote:
>> With this we can eliminate some duplicate code in panel drivers.
>> Also lgphilips-lb035q02, nec-nl8048hl11-01b, picodlp and
>> tpo-td043mtea1 gain support of timings control over sysfs.
>
> I don't like this patch.
>
> Panels usually have a single, fixed timing configuration that should be
> used, like the ones you mention above. There's no need to alter the
> timings.

But they often have a range of timings they can tolerate, and that can
be used to alter refresh rate, for example. We do that on pandora to
match graphics drawing rate (or multiples of it) to create a feeling
smoothness.

> But it's true that there's some duplicate code currently in the panel
> drivers. However, adding just simple funcs like you did in this patch
> doesn't work quite properly. There should be locking (for example to
> prevent disabling the panel while timings are being set), and currently
> the locking is panel driver specific.

ok, what about a version of this with .get_timings only then?
This should not need a lock unless panel has a set function, but in
that case panel will be expected to provide safe version of .get and
.set itself.

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

Re: [PATCH] usbnet: fix spinlock recursion

[Greg KH]

On Wed, Mar 14, 2012 at 02:45:27PM +0100, Maximilian Schwerin wrote:
> From: Albert Herranz 
> 
> This patch fixes the following spinlock recursion bug seen when bringing down
> the ethernet interface.
> 
> [   87.354683] BUG: spinlock recursion on CPU#0, ifconfig/1722
> [   87.360899]  lock: d2e01cd0, .magic: dead4ead, .owner: ifconfig/1722, 
> .owner_cpu: 0
> [   87.373410] Call Trace:
> [   87.379546] [d2f13c30] [c0008394] show_stack+0x3c/0x160 (unreliable)
> [   87.386227] [d2f13c60] [c0169dd8] spin_bug+0x8c/0xd0
> [   87.392858] [d2f13c80] [c016a0e4] _raw_spin_lock+0xb4/0xb8
> [   87.399570] [d2f13c90] [c02c855c] _spin_lock_irqsave+0x30/0x48
> [   87.406258] [d2f13cb0] [c01aa5d4] defer_bh+0x28/0xfc
> [   87.412726] [d2f13cd0] [c01c32e8] usb_hcd_giveback_urb+0x5c/0xdc
> [   87.419209] [d2f13ce0] [c01d2cec] sthcd_giveback_urb+0x30/0x50
> [   87.425762] [d2f13d00] [c01d488c] sthcd_urb_dequeue+0x7c/0xac
> [   87.432318] [d2f13d30] [c01c3478] unlink1+0x3c/0x4c
> [   87.438960] [d2f13d40] [c01c45c8] usb_hcd_unlink_urb+0x88/0xa4
> [   87.445629] [d2f13d60] [c01c49ac] usb_unlink_urb+0x54/0x5c
> [   87.452210] [d2f13d70] [c01aa170] unlink_urbs+0x40/0xb0
> [   87.458762] [d2f13d90] [c01ab470] usbnet_stop+0xdc/0x1a0
> [   87.465320] [d2f13df0] [c023bf18] dev_close+0xa0/0xdc
> [   87.471639] [d2f13e00] [c023bc98] dev_change_flags+0x84/0x1b4
> [   87.477908] [d2f13e20] [c0283f50] devinet_ioctl+0x5ec/0x6b8
> [   87.484222] [d2f13e90] [c0284cbc] inet_ioctl+0x98/0xbc
> [   87.490450] [d2f13ea0] [c022a300] sock_ioctl+0x60/0x284
> [   87.496566] [d2f13ec0] [c00a2714] vfs_ioctl+0x44/0xa8
> [   87.502657] [d2f13ee0] [c00a2d24] do_vfs_ioctl+0x88/0x24c
> [   87.508707] [d2f13f10] [c00a2f28] sys_ioctl+0x40/0x74
> [   87.514728] [d2f13f40] [c0011bbc] ret_from_syscall+0x0/0x38
> [   87.520780] --- Exception: c01 at 0xff59878
> [   87.520783] LR = 0xff597dc
> 
> unlink_urbs() takes the sk_buff queue lock &q->lock before removing the
> queued URBs via usb_unlink_urb().
> The issue here is that the completion handler of a queued TX URB will
> get called when the URB is unlinked, then tx_complete() will call defer_bh()
> which will try to take the queue lock again and fail.
> 
> The fix here is to release the list lock before unlinking a URB.
> 
> Signed-off-by: Albert Herranz 
> Signed-off-by: Maximilian Schwerin 
> ---
>  drivers/net/usb/usbnet.c |2 ++
>  1 files changed, 2 insertions(+), 0 deletions(-)

Hint, use scripts/get_maintainer.pl to find the right person to send
this patch to (you missed a list, and because of that, the patch will
never get applied...)

thanks,

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

Re: [PATCH v2 0/4] omap hsmmc device tree support

[Chris Ball]

Hi,

On Mon, Mar 12 2012, Rajendra Nayak wrote:
> The series adds device tree support for OMAP hsmmc
> driver.
>
> Changes in V2:
> -1- Minor fixes based on comments from Grant.
> -2- Added a seperate compatible for omap3.
> -3- Added a new binding "ti,needs-special-reset"
> to handle some mmc modules which need special
> softreset sequence.
> -4- Updated board dts files with "status = disable;"
> for unused mmc modules.
>
> Rob,
> I retained your ack on patch 1 despite the additional
> binding that I added to handle the special softreset
> sequence. Let me know if you have any issues with it.
>
> Chris.
> Patch 1 and Patch 2 apply cleanly on mmc-next and can
> be taken in from the mmc tree after relevent acks from
> DT folks.
> Patch 3 and Patch 4 which update dts files, I plan to
> push via linux-omap/Tony's tree.

Thanks, I've pushed patches 1 and 2 to mmc-next for 3.4, with Balaji's
Tested-by.

- Chris.
-- 
Chris Ball  
One Laptop Per Child
--
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] omap_vout: Fix "DMA transaction error" issue when rotation is enabled

[Laurent Pinchart]

Hi Vaibhav,

On Friday 09 March 2012 17:41:57 Vaibhav Hiremath wrote:
> When rotation is enabled and driver is configured in USERPTR
> buffer exchange mechanism, in specific use-case driver reports
> an error,
>"DMA transaction error with device 0".
> 
> In driver _buffer_prepare funtion, we were using
> "vout->buf_phy_addr[vb->i]" for buffer physical address to
> configure SDMA channel, but this variable does get updated
> only during init.
> And the issue will occur when driver allocates less number
> of buffers during init and application requests more buffers
> through REQBUF ioctl; this variable will lead to invalid
> configuration of SDMA channel leading to DMA transaction error.
> 
> Signed-off-by: Vaibhav Hiremath 
> ---
> Archit/Laurent,
> Can you help me to validate this patch on your platform/usecase?

I've tested the patch by rotating the omap_vout overlay by 90 degrees and 
starting a video stream with 4 buffers. There's no crash, but the kernel 
prints

[77.877807] omapdss DISPC error: FIFO UNDERFLOW on gfx, disabling the overlay
[77.928344] omapdss DISPC error: FIFO UNDERFLOW on vid1, disabling the overlay

The same problem occurs with 3 buffers, which is what the omap_vout driver 
allocates by default.

Without your patch applied I get the same behaviour. Is my test procedure 
wrong ?

>  drivers/media/video/omap/omap_vout_vrfb.c |2 +-
>  1 files changed, 1 insertions(+), 1 deletions(-)
> 
> diff --git a/drivers/media/video/omap/omap_vout_vrfb.c
> b/drivers/media/video/omap/omap_vout_vrfb.c index 4be26ab..240d36d 100644
> --- a/drivers/media/video/omap/omap_vout_vrfb.c
> +++ b/drivers/media/video/omap/omap_vout_vrfb.c
> @@ -225,7 +225,7 @@ int omap_vout_prepare_vrfb(struct omap_vout_device
> *vout, if (!is_rotation_enabled(vout))
>   return 0;
> 
> - dmabuf = vout->buf_phy_addr[vb->i];
> + dmabuf = (dma_addr_t) vout->queued_buf_addr[vb->i];
>   /* If rotation is enabled, copy input buffer into VRFB
>* memory space using DMA. We are copying input buffer
>* into VRFB memory space of desired angle and DSS will

-- 
Regards,

Laurent Pinchart

--
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+: add drm device

[Rob Clark]

On Wed, Mar 14, 2012 at 8:43 AM, Tomi Valkeinen  wrote:
> On Wed, 2012-03-14 at 08:16 -0500, Rob Clark wrote:
>> On Wed, Mar 14, 2012 at 8:07 AM, Tomi Valkeinen  
>> wrote:
>> > On Wed, 2012-03-14 at 07:55 -0500, Rob Clark wrote:
>> >> On Wed, Mar 14, 2012 at 7:38 AM, Tomi Valkeinen  
>> >> wrote:
>> >> > Hi,
>> >> >
>> >> > On Tue, 2012-03-13 at 15:34 -0500, Rob Clark wrote:
>> >> >> From: Andy Gross 
>> >> >>
>> >> >> Register OMAP DRM/KMS platform device, and reserve a CMA region for
>> >> >> the device to use for buffer allocation.  DMM is split into a
>> >> >> separate device using hwmod.
>> >> >
>> >> > What's the diff with this and the previous one?
>> >>
>> >> Moving drm.c to mach-omap2 (header could not move because
>> >> omap_reserve() is in plat-omap.. but this seems to be the same as what
>> >> is done for dspbridge).
>> >>
>> >> > I see you still have the platform data there. You didn't comment on
>> >> > that. Where is it used after the board files are gone when we use DT?
>> >>
>> >> I was kind-of thinking that there would be some DT<->data-structure
>> >> glue somewhere.. not sure if this goes in mach-omap2 or in the driver
>> >> itself, but presumably it is needed somewhere.
>> >>
>> >> It is only really special cases where some board specific device-tree
>> >> data is needed, so it seems like this is ok to handle later.
>> >
>> > Afaik DT data should only contain information about the hardware. This
>> > is SW configuration, so I think DT people won't accept things like that.
>>
>> hmm, then where *does* it go.. it is a bit too much for bootargs..
>
> I have no idea =). And I may be wrong, but my understanding is the the
> only thing DT data should have is information about the HW
> configuration.
>
> But is that kind of configuration needed at boot time? Why cannot the
> userspace do the config? What configs are actually needed at boot time,
> before userspace takes control? The only thing coming to my mind is to
> define the display used for the console.

drm builds up list of resources at startup, and attempts to light up
any connected displays at boot..  the decision about what resources to
use must be taken before userspace starts.

Anyways, if it is too controversial, maybe I just remove it.  It is
really only very special cases (possibly multi-seat setups) where you
might want to do something other than the default (which is for a
single omapdrm instance to use all dss video pipes).  It is just code
I had written previously for a certain product, and it seemed
potentially useful enough to not strip out of the upstream driver.

>> >> > And how about the size of the contiguous memory area, it was left a bit
>> >> > unclear to me why it cannot be dynamic.
>> >>
>> >> I don't think there is anything preventing adding a bootarg, but I
>> >> think it is not essential so ok to add later
>> >
>> > Well, maybe not essential to you =). But you are reserving 32MB memory,
>> > which is quite a big amount. Even if the reserved memory can be used for
>> > some other purposes, it's still a big chunk of "special" memory being
>> > reserved even if the user doesn't use or have a display at all.
>>
>> If you didn't have display, and were tight on memory, wouldn't you
>> just disable the display device in your kernel config?
>
> Sure, if you want to modify your kernel. But you could as well use the
> same kernel binary, and just say vram=0M which disables the vram
> allocation. For DRM you would _have_ to modify your kernel.
>
> Actually, I just realized vram=0M doesn't work, as the code checks for !
> = 0, and just skips the vram argument when it's 0 =). So my code sucks
> also...

well, I suppose there is always something somewhere to improve..

anyways, at this point omapdrm isn't enabled by default in
omap2plus_defconfig.. I just want to get the platform device
registration merged in some form so folks don't have to go poking
around to find some out of tree patch in order to enable it.

>> > Well, it's not an issue for me either, but I just feel that doing things
>> > like that without allowing the user to avoid it is a bit bad thing.
>> >
>> > Btw, do you know why the dma_declare_contiguous() takes a dev pointer as
>> > an argument, if the memory is not private to that device? (at least I
>> > understood from you that the memory can be used for other purposes).
>>
>> contiguous use of the memory is private to the device.  There is also
>> a global CMA pool, from which all dma_alloc_xyz() which is not
>> associated w/ a per-device pool comes from.. but the advantage of a
>> per-device-pool is it puts an upper limit on how much dma memory that
>> device can allocate so that it cannot starve other devices.
>
> Ah, I see. So the 32MB you reserve there is not visible as contiguous
> memory to anyone else than omapdrm, but userspace can still use the 32MB
> area for pages that can be moved out as needed.
>
> But then, if it's private, it's also rather bad. If I have a kernel with
> omapfb and omapdrm 

Re: [PATCH] omap_vout: Fix the build warning and section miss-match warning

[Laurent Pinchart]

Hi Vaibhav,

Thanks for the patch.

On Friday 09 March 2012 17:44:03 Vaibhav Hiremath wrote:
> Patch fixes below build warning and section miss-match warning
> from omap_vout driver -

You should probably not refer to "patch below" in a commit message, as there 
this won't be a patch anymore after it gets applied (and "below" is 
meaningless in a git log).

> Build warnings:
> =
> drivers/media/video/omap/omap_vout.c: In function 'omapvid_setup_overlay':
> drivers/media/video/omap/omap_vout.c:381:17: warning: 'mode' may be used
> uninitialized in this function
> 
> Section Mis-Match warnings:
> ==
> WARNING: drivers/media/video/omap/omap-vout.o(.data+0x0): Section mismatch
> in reference from the variable
> omap_vout_driver to the function .init.text:omap_vout_probe()
> The variable omap_vout_driver references
> the function __init omap_vout_probe()
> If the reference is valid then annotate the
> variable with __init* or __refdata (see linux/init.h) or name the variable:
> *_template, *_timer, *_sht, *_ops, *_probe, *_probe_one, *_console

There are 3 fixes in this patch: compilation warning, section mismatch 
warning, and addition of .owner = THIS_MODULE. I would have split the patch in 
3.

> Signed-off-by: Vaibhav Hiremath 
>
> ---
>  drivers/media/video/omap/omap_vout.c |9 +
>  1 files changed, 5 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/media/video/omap/omap_vout.c
> b/drivers/media/video/omap/omap_vout.c index dffcf66..0fb0437 100644
> --- a/drivers/media/video/omap/omap_vout.c
> +++ b/drivers/media/video/omap/omap_vout.c
> @@ -328,7 +328,7 @@ static int video_mode_to_dss_mode(struct
> omap_vout_device *vout) struct omap_overlay *ovl;
>   struct omapvideo_info *ovid;
>   struct v4l2_pix_format *pix = &vout->pix;
> - enum omap_color_mode mode;
> + enum omap_color_mode mode = -EINVAL;

What about removing "case 0" below ? The default case would then set mode to -
EINVAL.

> 
>   ovid = &vout->vid_info;
>   ovl = ovid->overlays[0];
> @@ -2108,7 +2108,7 @@ static void omap_vout_cleanup_device(struct
> omap_vout_device *vout) kfree(vout);
>  }
> 
> -static int omap_vout_remove(struct platform_device *pdev)
> +static int __devexit omap_vout_remove(struct platform_device *pdev)
>  {
>   int k;
>   struct v4l2_device *v4l2_dev = platform_get_drvdata(pdev);
> @@ -2129,7 +2129,7 @@ static int omap_vout_remove(struct platform_device
> *pdev) return 0;
>  }
> 
> -static int __init omap_vout_probe(struct platform_device *pdev)
> +static int __devinit omap_vout_probe(struct platform_device *pdev)
>  {
>   int ret = 0, i;
>   struct omap_overlay *ovl;
> @@ -2241,9 +2241,10 @@ probe_err0:
>  static struct platform_driver omap_vout_driver = {
>   .driver = {
>   .name = VOUT_NAME,
> + .owner = THIS_MODULE,
>   },
>   .probe = omap_vout_probe,
> - .remove = omap_vout_remove,
> + .remove = __devexit_p(omap_vout_remove),
>  };
> 
>  static int __init omap_vout_init(void)

-- 
Regards,

Laurent Pinchart

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

[Kevin Hilman]

Colin Cross  writes:

> On Tue, Mar 13, 2012 at 5:28 PM, Colin Cross  wrote:
>> On Tue, Mar 13, 2012 at 4:52 PM, Kevin Hilman  wrote:

[...]

>>>
>>> Checking the ready_count seemed like an easy way to do this, but did you
>>> have any other mechanisms in mind for CPUs to communicate that they've
>>> exited/aborted?
>>
>> Why not set a flag from CPU1 when it exits the low power state, and
>> have CPU0 spin on the powerdomain register or the flag?  You can then
>> use the parallel barrier function to ensure both cpus have seen the
>> flag and reset it to 0 before returning.
>
> I realized the parallel barrier helper was not included in the patch
> set I posted, it will be in the next patch set.  

Do you have an ETA for the next patchset?  I'll be glad to give it a
spin on OMAP4.

> Short version, no caller to cpuidle_coupled_parallel_barrier will
> return before all cpus in the coupled set have called it.  It allows
> you to resynchronize the cpus after an abort to ensure they have all
> seen the abort flag before clearing it and returning, leaving
> everything in the correct state for the next idle attempt.

OK, this sounds like it will work well for what I need.

Kevin
--
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] omap: opp: test for iva before attempting to set iva opp

[Maximilian Schwerin]

From: Steve Sakoman 

Signed-off-by: Steve Sakoman 
Signed-off-by: Maximilian Schwerin 
---
 arch/arm/mach-omap2/opp.c |4 
 1 files changed, 4 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-omap2/opp.c b/arch/arm/mach-omap2/opp.c
index 9262a6b..414f2ec 100644
--- a/arch/arm/mach-omap2/opp.c
+++ b/arch/arm/mach-omap2/opp.c
@@ -62,6 +62,10 @@ int __init omap_init_opp_table(struct omap_opp_def *opp_def,
__func__, i);
return -EINVAL;
}
+
+   if ((strcmp(opp_def->hwmod_name,"iva") == 0) && 
!omap3_has_iva())
+   continue;
+
oh = omap_hwmod_lookup(opp_def->hwmod_name);
if (!oh || !oh->od) {
pr_warn("%s: no hwmod or odev for %s, [%d] "
-- 
1.7.0.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] usbnet: fix spinlock recursion

[Maximilian Schwerin]

From: Albert Herranz 

This patch fixes the following spinlock recursion bug seen when bringing down
the ethernet interface.

[   87.354683] BUG: spinlock recursion on CPU#0, ifconfig/1722
[   87.360899]  lock: d2e01cd0, .magic: dead4ead, .owner: ifconfig/1722, 
.owner_cpu: 0
[   87.373410] Call Trace:
[   87.379546] [d2f13c30] [c0008394] show_stack+0x3c/0x160 (unreliable)
[   87.386227] [d2f13c60] [c0169dd8] spin_bug+0x8c/0xd0
[   87.392858] [d2f13c80] [c016a0e4] _raw_spin_lock+0xb4/0xb8
[   87.399570] [d2f13c90] [c02c855c] _spin_lock_irqsave+0x30/0x48
[   87.406258] [d2f13cb0] [c01aa5d4] defer_bh+0x28/0xfc
[   87.412726] [d2f13cd0] [c01c32e8] usb_hcd_giveback_urb+0x5c/0xdc
[   87.419209] [d2f13ce0] [c01d2cec] sthcd_giveback_urb+0x30/0x50
[   87.425762] [d2f13d00] [c01d488c] sthcd_urb_dequeue+0x7c/0xac
[   87.432318] [d2f13d30] [c01c3478] unlink1+0x3c/0x4c
[   87.438960] [d2f13d40] [c01c45c8] usb_hcd_unlink_urb+0x88/0xa4
[   87.445629] [d2f13d60] [c01c49ac] usb_unlink_urb+0x54/0x5c
[   87.452210] [d2f13d70] [c01aa170] unlink_urbs+0x40/0xb0
[   87.458762] [d2f13d90] [c01ab470] usbnet_stop+0xdc/0x1a0
[   87.465320] [d2f13df0] [c023bf18] dev_close+0xa0/0xdc
[   87.471639] [d2f13e00] [c023bc98] dev_change_flags+0x84/0x1b4
[   87.477908] [d2f13e20] [c0283f50] devinet_ioctl+0x5ec/0x6b8
[   87.484222] [d2f13e90] [c0284cbc] inet_ioctl+0x98/0xbc
[   87.490450] [d2f13ea0] [c022a300] sock_ioctl+0x60/0x284
[   87.496566] [d2f13ec0] [c00a2714] vfs_ioctl+0x44/0xa8
[   87.502657] [d2f13ee0] [c00a2d24] do_vfs_ioctl+0x88/0x24c
[   87.508707] [d2f13f10] [c00a2f28] sys_ioctl+0x40/0x74
[   87.514728] [d2f13f40] [c0011bbc] ret_from_syscall+0x0/0x38
[   87.520780] --- Exception: c01 at 0xff59878
[   87.520783] LR = 0xff597dc

unlink_urbs() takes the sk_buff queue lock &q->lock before removing the
queued URBs via usb_unlink_urb().
The issue here is that the completion handler of a queued TX URB will
get called when the URB is unlinked, then tx_complete() will call defer_bh()
which will try to take the queue lock again and fail.

The fix here is to release the list lock before unlinking a URB.

Signed-off-by: Albert Herranz 
Signed-off-by: Maximilian Schwerin 
---
 drivers/net/usb/usbnet.c |2 ++
 1 files changed, 2 insertions(+), 0 deletions(-)

diff --git a/drivers/net/usb/usbnet.c b/drivers/net/usb/usbnet.c
index fae0fbd..b06bfd8 100644
--- a/drivers/net/usb/usbnet.c
+++ b/drivers/net/usb/usbnet.c
@@ -591,7 +591,9 @@ static int unlink_urbs (struct usbnet *dev, struct 
sk_buff_head *q)
 
// during some PM-driven resume scenarios,
// these (async) unlinks complete immediately
+   spin_unlock(&q->lock);
retval = usb_unlink_urb (urb);
+   spin_lock(&q->lock);
if (retval != -EINPROGRESS && retval != 0)
netdev_dbg(dev->net, "unlink urb err, %d\n", retval);
else
-- 
1.7.0.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+: add drm device

[Tomi Valkeinen]

On Wed, 2012-03-14 at 08:16 -0500, Rob Clark wrote:
> On Wed, Mar 14, 2012 at 8:07 AM, Tomi Valkeinen  wrote:
> > On Wed, 2012-03-14 at 07:55 -0500, Rob Clark wrote:
> >> On Wed, Mar 14, 2012 at 7:38 AM, Tomi Valkeinen  
> >> wrote:
> >> > Hi,
> >> >
> >> > On Tue, 2012-03-13 at 15:34 -0500, Rob Clark wrote:
> >> >> From: Andy Gross 
> >> >>
> >> >> Register OMAP DRM/KMS platform device, and reserve a CMA region for
> >> >> the device to use for buffer allocation.  DMM is split into a
> >> >> separate device using hwmod.
> >> >
> >> > What's the diff with this and the previous one?
> >>
> >> Moving drm.c to mach-omap2 (header could not move because
> >> omap_reserve() is in plat-omap.. but this seems to be the same as what
> >> is done for dspbridge).
> >>
> >> > I see you still have the platform data there. You didn't comment on
> >> > that. Where is it used after the board files are gone when we use DT?
> >>
> >> I was kind-of thinking that there would be some DT<->data-structure
> >> glue somewhere.. not sure if this goes in mach-omap2 or in the driver
> >> itself, but presumably it is needed somewhere.
> >>
> >> It is only really special cases where some board specific device-tree
> >> data is needed, so it seems like this is ok to handle later.
> >
> > Afaik DT data should only contain information about the hardware. This
> > is SW configuration, so I think DT people won't accept things like that.
> 
> hmm, then where *does* it go.. it is a bit too much for bootargs..

I have no idea =). And I may be wrong, but my understanding is the the
only thing DT data should have is information about the HW
configuration.

But is that kind of configuration needed at boot time? Why cannot the
userspace do the config? What configs are actually needed at boot time,
before userspace takes control? The only thing coming to my mind is to
define the display used for the console.

> >> > And how about the size of the contiguous memory area, it was left a bit
> >> > unclear to me why it cannot be dynamic.
> >>
> >> I don't think there is anything preventing adding a bootarg, but I
> >> think it is not essential so ok to add later
> >
> > Well, maybe not essential to you =). But you are reserving 32MB memory,
> > which is quite a big amount. Even if the reserved memory can be used for
> > some other purposes, it's still a big chunk of "special" memory being
> > reserved even if the user doesn't use or have a display at all.
> 
> If you didn't have display, and were tight on memory, wouldn't you
> just disable the display device in your kernel config?

Sure, if you want to modify your kernel. But you could as well use the
same kernel binary, and just say vram=0M which disables the vram
allocation. For DRM you would _have_ to modify your kernel.

Actually, I just realized vram=0M doesn't work, as the code checks for !
= 0, and just skips the vram argument when it's 0 =). So my code sucks
also...

> > Well, it's not an issue for me either, but I just feel that doing things
> > like that without allowing the user to avoid it is a bit bad thing.
> >
> > Btw, do you know why the dma_declare_contiguous() takes a dev pointer as
> > an argument, if the memory is not private to that device? (at least I
> > understood from you that the memory can be used for other purposes).
> 
> contiguous use of the memory is private to the device.  There is also
> a global CMA pool, from which all dma_alloc_xyz() which is not
> associated w/ a per-device pool comes from.. but the advantage of a
> per-device-pool is it puts an upper limit on how much dma memory that
> device can allocate so that it cannot starve other devices.

Ah, I see. So the 32MB you reserve there is not visible as contiguous
memory to anyone else than omapdrm, but userspace can still use the 32MB
area for pages that can be moved out as needed.

But then, if it's private, it's also rather bad. If I have a kernel with
omapfb and omapdrm enabled as modules, but I never use omapdrm, the 32MB
is still always reserver and away from other contiguous memory use.

Also, I just realized that besides the memory reservation being fixed,
it's also hidden. If I enable omapdrm in the kernel config, I get no
indication that 32MB of mem is being reserved. Perhaps a Kconfig option
for it, like with OMAP VRAM, and then a boot arg which will override the
Kconfig value.

Well, as I said, it's not an issue for me and from my side it can be
improved later.

 Tomi


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

[GIT PULL] mfd: twl: Fix for irqdomain/next + SPARSE_IRQ + MMC card detect

[Cousson, Benoit]

Hi Samuel,

Here is a fix + cleanup + SPARSE_IRQ series for TWL4030 and TWL6030.

I added the patch from Peter as well.

Please note that this series does depend on the irqdomain/next series
from Grant.

It is based on your current for-next branch + Grant's series merged on top.

Regards,
Benoit


The following changes since commit 81d14f4516578ca71d7f97612cb2b9cd4db0e7dd:
  Benoit Cousson (1):
Merge remote branch 'grant/irqdomain/next' into HEAD

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/bcousson/linux-omap-dt.git 
for_3.4/twl_irq_gpio_mmc_fix

Benoit Cousson (8):
  mfd: twl6030-irq: Return twl6030_mmc_card_detect IRQ for board setup
  ARM: OMAP2+: board-omap4-*: Do not use anymore TWL6030_IRQ_BASE in board 
files
  mfd: twl-core: Remove references already defined in header file
  mfd: twl-core: Move IRQ allocation into twl[4030|6030]-irq files
  mfd: twl4030-irq: Make SIH SPARSE_IRQ capable
  mfd: twl-*: Replace pr_ macros by the dev_ equivalent and do various 
cleanups
  gpio/twl: Allocate irq_desc dynamically for SPARSE_IRQ support
  gpio/twl: Add DT support to gpio-twl4030 driver

Felipe Balbi (3):
  mfd: twl-core: don't depend on pdata->irq_base/end
  mfd: twl-core: remove unneeded header
  mfd: twl4030-irq: micro-optimization on IRQ handler

Peter Ujfalusi (1):
  mfd: twl-core: Detach twl6040 from the pmic mfd driver

 .../devicetree/bindings/gpio/gpio-twl4030.txt  |   23 +++
 arch/arm/mach-omap2/board-4430sdp.c|   13 +-
 arch/arm/mach-omap2/board-omap4panda.c |   15 +-
 drivers/gpio/gpio-twl4030.c|  111 +--
 drivers/mfd/twl-core.c |  154 +---
 drivers/mfd/twl-core.h |4 +-
 drivers/mfd/twl4030-irq.c  |   83 ++-
 drivers/mfd/twl6030-irq.c  |   71 ++
 include/linux/i2c/twl.h|2 +-
 9 files changed, 267 insertions(+), 209 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/gpio/gpio-twl4030.txt

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

Re: [PATCH] omap2+: add drm device

[Rob Clark]

On Wed, Mar 14, 2012 at 8:07 AM, Tomi Valkeinen  wrote:
> On Wed, 2012-03-14 at 07:55 -0500, Rob Clark wrote:
>> On Wed, Mar 14, 2012 at 7:38 AM, Tomi Valkeinen  
>> wrote:
>> > Hi,
>> >
>> > On Tue, 2012-03-13 at 15:34 -0500, Rob Clark wrote:
>> >> From: Andy Gross 
>> >>
>> >> Register OMAP DRM/KMS platform device, and reserve a CMA region for
>> >> the device to use for buffer allocation.  DMM is split into a
>> >> separate device using hwmod.
>> >
>> > What's the diff with this and the previous one?
>>
>> Moving drm.c to mach-omap2 (header could not move because
>> omap_reserve() is in plat-omap.. but this seems to be the same as what
>> is done for dspbridge).
>>
>> > I see you still have the platform data there. You didn't comment on
>> > that. Where is it used after the board files are gone when we use DT?
>>
>> I was kind-of thinking that there would be some DT<->data-structure
>> glue somewhere.. not sure if this goes in mach-omap2 or in the driver
>> itself, but presumably it is needed somewhere.
>>
>> It is only really special cases where some board specific device-tree
>> data is needed, so it seems like this is ok to handle later.
>
> Afaik DT data should only contain information about the hardware. This
> is SW configuration, so I think DT people won't accept things like that.

hmm, then where *does* it go.. it is a bit too much for bootargs..

>> > And how about the size of the contiguous memory area, it was left a bit
>> > unclear to me why it cannot be dynamic.
>>
>> I don't think there is anything preventing adding a bootarg, but I
>> think it is not essential so ok to add later
>
> Well, maybe not essential to you =). But you are reserving 32MB memory,
> which is quite a big amount. Even if the reserved memory can be used for
> some other purposes, it's still a big chunk of "special" memory being
> reserved even if the user doesn't use or have a display at all.

If you didn't have display, and were tight on memory, wouldn't you
just disable the display device in your kernel config?

> Well, it's not an issue for me either, but I just feel that doing things
> like that without allowing the user to avoid it is a bit bad thing.
>
> Btw, do you know why the dma_declare_contiguous() takes a dev pointer as
> an argument, if the memory is not private to that device? (at least I
> understood from you that the memory can be used for other purposes).

contiguous use of the memory is private to the device.  There is also
a global CMA pool, from which all dma_alloc_xyz() which is not
associated w/ a per-device pool comes from.. but the advantage of a
per-device-pool is it puts an upper limit on how much dma memory that
device can allocate so that it cannot starve other devices.

BR,
-R

>  Tomi
>
>
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
--
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+: add drm device

[Tomi Valkeinen]

On Wed, 2012-03-14 at 07:55 -0500, Rob Clark wrote:
> On Wed, Mar 14, 2012 at 7:38 AM, Tomi Valkeinen  wrote:
> > Hi,
> >
> > On Tue, 2012-03-13 at 15:34 -0500, Rob Clark wrote:
> >> From: Andy Gross 
> >>
> >> Register OMAP DRM/KMS platform device, and reserve a CMA region for
> >> the device to use for buffer allocation.  DMM is split into a
> >> separate device using hwmod.
> >
> > What's the diff with this and the previous one?
> 
> Moving drm.c to mach-omap2 (header could not move because
> omap_reserve() is in plat-omap.. but this seems to be the same as what
> is done for dspbridge).
> 
> > I see you still have the platform data there. You didn't comment on
> > that. Where is it used after the board files are gone when we use DT?
> 
> I was kind-of thinking that there would be some DT<->data-structure
> glue somewhere.. not sure if this goes in mach-omap2 or in the driver
> itself, but presumably it is needed somewhere.
> 
> It is only really special cases where some board specific device-tree
> data is needed, so it seems like this is ok to handle later.

Afaik DT data should only contain information about the hardware. This
is SW configuration, so I think DT people won't accept things like that.

> > And how about the size of the contiguous memory area, it was left a bit
> > unclear to me why it cannot be dynamic.
> 
> I don't think there is anything preventing adding a bootarg, but I
> think it is not essential so ok to add later

Well, maybe not essential to you =). But you are reserving 32MB memory,
which is quite a big amount. Even if the reserved memory can be used for
some other purposes, it's still a big chunk of "special" memory being
reserved even if the user doesn't use or have a display at all.

Well, it's not an issue for me either, but I just feel that doing things
like that without allowing the user to avoid it is a bit bad thing.

Btw, do you know why the dma_declare_contiguous() takes a dev pointer as
an argument, if the memory is not private to that device? (at least I
understood from you that the memory can be used for other purposes).

 Tomi


--
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+: add drm device

[Rob Clark]

On Wed, Mar 14, 2012 at 7:38 AM, Tomi Valkeinen  wrote:
> Hi,
>
> On Tue, 2012-03-13 at 15:34 -0500, Rob Clark wrote:
>> From: Andy Gross 
>>
>> Register OMAP DRM/KMS platform device, and reserve a CMA region for
>> the device to use for buffer allocation.  DMM is split into a
>> separate device using hwmod.
>
> What's the diff with this and the previous one?

Moving drm.c to mach-omap2 (header could not move because
omap_reserve() is in plat-omap.. but this seems to be the same as what
is done for dspbridge).

> I see you still have the platform data there. You didn't comment on
> that. Where is it used after the board files are gone when we use DT?

I was kind-of thinking that there would be some DT<->data-structure
glue somewhere.. not sure if this goes in mach-omap2 or in the driver
itself, but presumably it is needed somewhere.

It is only really special cases where some board specific device-tree
data is needed, so it seems like this is ok to handle later.

> And how about the size of the contiguous memory area, it was left a bit
> unclear to me why it cannot be dynamic.

I don't think there is anything preventing adding a bootarg, but I
think it is not essential so ok to add later

BR,
-R

>  Tomi
>
--
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+: add drm device

[Tomi Valkeinen]

Hi,

On Tue, 2012-03-13 at 15:34 -0500, Rob Clark wrote:
> From: Andy Gross 
> 
> Register OMAP DRM/KMS platform device, and reserve a CMA region for
> the device to use for buffer allocation.  DMM is split into a
> separate device using hwmod.

What's the diff with this and the previous one?

I see you still have the platform data there. You didn't comment on
that. Where is it used after the board files are gone when we use DT?

And how about the size of the contiguous memory area, it was left a bit
unclear to me why it cannot be dynamic.

 Tomi



signature.asc
Description: This is a digitally signed message part

Re: OMAP DSS device tree design problems

[Tomi Valkeinen]

On Tue, 2012-03-13 at 23:47 +0100, Cousson, Benoit wrote:

> I'm just wondering if the multiple panels is something supported by the 
> DSI protocol or it is a HW hacks done on TI board only?

In theory both, but the driver doesn't support multiple panels connected
to single DSI output at the same time. And that is, in a way, easier
regarding DT, as all the configuration parameters are specific to DSI
and the panel.

But the case at hand is that two panels are connected to single DSI
output, but there's an external switch/mux between the DSI output or
GPIO lines and the panels. It's not a HW hack on TI development boards
only. The means to switch between the two displays can be anything, from
setting a single GPIO to, say, sending i2c commands to some mux chip.

> > However, here the problem is that while ultimately we're interested in
> > the ddr-clk rate, calculation of the rate is non-trivial and may need
> > customizations at times. So instead of the clock rate we actually need
> > to define a bunch of dividers/multipliers.
> 
> Well, in theory you should not. This is up to the clock provider to 
> convert the clock rate in the proper n/m value. This is how it is done 
> for the regular OMAP DPLLs.

Right. But it's a non trivial problem. There are multiple
dividers/multipliers in the path, and the clocks from different points
at that path are used for different purposes. Some of the div/mul fields
are quite wide, so there are a lot of numbers to iterate. 

And in many cases it's important to get sometimes exact, and sometimes
almost exact, clock rate, but still at times go with a less exact clock
rate if that gives you lower power consumption, or some other similar
side effect.

So we currently calculate the dividers manually in most cases.

> > and the Taal driver would ignore those, but dsi driver would use them?
> > This looks like quite easy solution to this, but also doesn't feel
> > right. So my current idea is to have clk-div tables in the dsi node,
> > something like this:
> >
> > dsi1 {
> > omap-specific-clk-divs =<
> > 250 1 2 3 4 5 6 7 /* divs that produce 250MHz clk */
> > 350 7 6 5 4 3 2 1 /* divs that produce 350MHz clk */
> > >;
> 
> That's the idea, except that this will represent the clock provider.

Hmm... So. Should I have something like:

dsi1 {
dsi1-pll: dsipll {
clk-table = <
250 1 2 3 4 5 6 7 /* 250MHz clk */
350 7 6 5 4 3 2 1 /* 350MHz clk */
>;
};

taal {
dsi-clk-src = <&dsi1-pll>;
dsi-clk-rate = <25000>;
};
}

But no, I don't think that's correct. The panel is not using the DSI
PLL. DSI protocol engine and DSI PHY are using the DSI PLL, and they
produce the output on the DSI bus, with the speed that the panel wants.

> > taal {
> > dsi-ddr-clk =<25000>;
> 
> And here you will have a phandle to the clock provider. And use it to 
> set the proper clock rate.

I'm not sure if a "clock provider" is correct here. It's not really a
clock, in the strict sense, that goes to the panel from OMAP. It's the
speed of the DSI bus we are talking about here.

> > lanes =<
> > /* pad-pair number, polarity */
> > 1 0 /* DSI pad pair 1 is used for clk, pol +/-  */
> > 2 1 /* DSI pad pair 2 is used for data1, pol -/+ */
> > 0 0 /* DSI pad pair 0 is used for data2, pol +/- */
> >> ;
> >
> > Now, I don't quite know where this data should be. If it's in the
> > dsi-node, it doesn't work with multiple panels.
> 
> Is the lane configuration only dependent of the panel?

If you mean, is the lane config the same on every board that uses the
panel, then no. The lane config tells which pin on OMAP is used for
which purpose in the DSI bus.

So if the DSI panel supports two datalanes, it means it has 6 DSI pins:
2 for clk +/-, 2 for data1, 2 for data2. The HW designed then connects,
say, the panel's CLK+ pin to one of OMAPs DSI pins. The OMAP pin has to
be configured in the system config level for DSI operation, and also we
need to configure the function of the pin to CLK+ in the DSI HW module.

> > But then, it's quite
> > OMAP specific thing. While other platforms probably need some kind of
> > pad configuration also, it may be something totally different. And so it
> > doesn't feel right in the taal-node either.
> >
> > And a look-up table like in the clock case doesn't make much sense
> > either, as we don't have a key here, as we had in the clock case (the
> > dsi-ddr-clk).
> 
> The lane configuration code will belong to the DSI driver. The data will 
> belong to the panel. The panel might use some phandle to the various DSI 
> lane config a provide the needed information.
> 
> This look pretty similar to the pinmux device tree binding that is 
> currently under discussion.
> 
> > So basically the only option I've come up with is to define the lane
> > configuration in the panel

Re: [PATCH v2] OMAPDSS: provide default timings functions for panels

[Tomi Valkeinen]

Hi,

On Mon, 2012-03-12 at 13:27 +0200, Grazvydas Ignotas wrote:
> With this we can eliminate some duplicate code in panel drivers.
> Also lgphilips-lb035q02, nec-nl8048hl11-01b, picodlp and
> tpo-td043mtea1 gain support of timings control over sysfs.

I don't like this patch.

Panels usually have a single, fixed timing configuration that should be
used, like the ones you mention above. There's no need to alter the
timings.

But it's true that there's some duplicate code currently in the panel
drivers. However, adding just simple funcs like you did in this patch
doesn't work quite properly. There should be locking (for example to
prevent disabling the panel while timings are being set), and currently
the locking is panel driver specific.

 Tomi



signature.asc
Description: This is a digitally signed message part

[GIT PULL] ARM: OMAP4: hwmod data: add almost all remaining IP blocks

[Paul Walmsley]

Hi Tony

The following changes since commit afce19b152eedea0402561087dd939b23b53f3cb:

  ARM: OMAP2xxx: hwmod data: start to fix the IVA1, IVA2 and DSP (2012-03-08 
21:04:50 -0700)

are available in the git repository at:

  git://git.pwsan.com/linux-2.6 hwmod_enable_remaining_hwmods_devel_3.4

for you to fetch changes up to de028b2eb97649d82ebb1ca1f6fabc932ca98354:

  ARM: OMAP4: hwmod data: add DEBUGSS skeleton (2012-03-08 21:29:05 -0700)

This series has a dependency on the 'hwmod_remove_link_arrays_cleanup_3.4' 
branch.


- Paul


Benoît Cousson (6):
  ARM: OMAP4: hwmod data: add GPMC
  ARM: OMAP4: hwmod data: add the Slimbus IP blocks
  ARM: OMAP4: hwmod data: add McASP
  ARM: OMAP4: hwmod data: add remaining USB-related IP blocks
  ARM: OMAP4: hwmod data: add the OCP-WP IP block
  ARM: OMAP4: hwmod data: add DEBUGSS skeleton

Ming Lei (1):
  ARM: OMAP4: hwmod data: introduce fdif(face detect module) hwmod

Paul Walmsley (8):
  ARM: OMAP2+: clockdomains: make {prm,cm}_clkdm common
  ARM: OMAP4: hwmod data: add HDQ/1-wire
  ARM: OMAP4: hwmod data: add EMIF1 and 2
  ARM: OMAP4: hwmod data: add GPU
  ARM: OMAP4: hwmod data: add some interconnect-related IP blocks
  ARM: OMAP4: hwmod data: add OCM RAM IP block
  ARM: OMAP4: hwmod data: add System Control Module
  ARM: OMAP4: hwmod data: add PRCM and related IP blocks

 arch/arm/mach-omap2/Makefile |8 +-
 arch/arm/mach-omap2/clockdomain44xx.c|6 +
 arch/arm/mach-omap2/clockdomains2xxx_3xxx_data.c |   10 -
 arch/arm/mach-omap2/clockdomains44xx_data.c  |2 +
 arch/arm/mach-omap2/clockdomains_common_data.c   |   24 +
 arch/arm/mach-omap2/omap_hwmod_44xx_data.c   | 1473 +-
 arch/arm/plat-omap/include/plat/omap_hwmod.h |1 +
 7 files changed, 1443 insertions(+), 81 deletions(-)
 create mode 100644 arch/arm/mach-omap2/clockdomains_common_data.c

[GIT PULL] ARM: OMAP2+: hwmod: remove link arrays

[Paul Walmsley]

Hi Tony

The following changes since commit 5f43ef65748c19b954756485ddaef657ac71b649:

  Merge branch 'hwmod_misc_devel_3.4' into MERGE_sr_and_hwmod_data (2012-03-08 
21:03:17 -0700)

are available in the git repository at:

  git://git.pwsan.com/linux-2.6 hwmod_remove_link_arrays_cleanup_3.4

for you to fetch changes up to afce19b152eedea0402561087dd939b23b53f3cb:

  ARM: OMAP2xxx: hwmod data: start to fix the IVA1, IVA2 and DSP (2012-03-08 
21:04:50 -0700)

The base commit for this pull request is a merge of your SR branch with 
the 'hwmod_misc_devel_3.4' branch, since this series has dependencies on 
both of those.


- Paul


Paul Walmsley (12):
  ARM: OMAP2+: hwmod: add _find_mpu_rt_port()
  ARM: OMAP2+: hwmod: add function to iterate over struct omap_hwmod_ocp_if
  ARM: OMAP2+: hwmod: consolidate finding the MPU port index and storing it
  ARM: OMAP2+: hwmod: add support for link registration
  ARM: OMAP2+: hwmod data: convert to link registration
  ARM: OMAP: hwmod: remove code support for direct hwmod registration
  ARM: OMAP2+: hwmod data: remove forward declarations, reorganize
  ARM: OMAP2xxx: hwmod data: share common hwmods between OMAP2420 and 
OMAP2430
  ARM: OMAP2xxx: hwmod data: share common interface data
  ARM: OMAP3: hwmod data: fix IVA interface clock
  ARM: OMAP3: hwmod data: add IVA hard reset lines, main clock, clockdomain
  ARM: OMAP2xxx: hwmod data: start to fix the IVA1, IVA2 and DSP

 arch/arm/mach-omap2/omap_hwmod.c   |  410 ++-
 arch/arm/mach-omap2/omap_hwmod_2420_data.c | 1563 +-
 arch/arm/mach-omap2/omap_hwmod_2430_data.c | 2316 +++---
 .../mach-omap2/omap_hwmod_2xxx_interconnect_data.c |  266 +-
 arch/arm/mach-omap2/omap_hwmod_2xxx_ipblock_data.c |  562 +++
 arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 5081 +---
 arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 4882 ---
 arch/arm/mach-omap2/omap_hwmod_common_data.h   |   71 +-
 arch/arm/plat-omap/include/plat/omap_hwmod.h   |   31 +-
 9 files changed, 6341 insertions(+), 8841 deletions(-)
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html