On Tue, 2012-03-13 at 11:37 -0700, Kevin Hilman wrote:
> Hi Tomi,
>
> Tomi Valkeinen writes:
>
> > Hi Kevin, Paul,
> >
> > I know you're busy, but I'd appreciate a comment/ack on these two small
> > patches, so I could get them in to next merge window. Otherwise using
> > any other OPP than OPP1
On Tue, Mar 13, 2012 at 7:04 PM, Arjan van de Ven wrote:
> On 3/13/2012 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?
>
> this indeed is the trick
On 3/13/2012 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?
this indeed is the tricky part (which I warned about earlier);
I've spent quite a lot of t
On Tue, Mar 13, 2012 at 9:57 PM, Kevin Hilman wrote:
> "DebBarma, Tarun Kanti" writes:
>
>> On Tue, Mar 13, 2012 at 12:03 PM, DebBarma, Tarun Kanti
>> wrote:
>>> On Tue, Mar 13, 2012 at 11:33 AM, DebBarma, Tarun Kanti
>>> wrote:
On Tue, Mar 13, 2012 at 3:24 AM, Kevin Hilman wrote:
> T
On Tue, Mar 13, 2012 at 5:28 PM, Colin Cross wrote:
> On Tue, Mar 13, 2012 at 4:52 PM, Kevin Hilman wrote:
>> Hi Colin,
>>
>> On 12/21/2011 01:09 AM, Colin Cross wrote:
>>
>>> To use coupled cpuidle states, a cpuidle driver must:
>>
>> [...]
>>
>>> Provide a struct cpuidle_state.enter functio
On Wed, Dec 21, 2011 at 4:12 AM, Arjan van de Ven wrote:
> On 12/21/2011 10:55 AM, Colin Cross wrote:
>> On Wed, Dec 21, 2011 at 1:44 AM, Arjan van de Ven
>> wrote:
>>> On 12/21/2011 10:40 AM, Colin Cross wrote:
>>>
> this smells fundamentally racey to me; you can get an interrupt one
>
On Tue, Mar 13, 2012 at 4:52 PM, Kevin Hilman wrote:
> Hi Colin,
>
> On 12/21/2011 01:09 AM, Colin Cross wrote:
>
>> To use coupled cpuidle states, a cpuidle driver must:
>
> [...]
>
>> Provide a struct cpuidle_state.enter function for each state
>> that affects multiple cpus. This functi
On Wed, Feb 01, 2012 at 03:03:47AM +0200, Felipe Contreras wrote:
> We enable power, but don't disable it in case of an error.
>
> Signed-off-by: Felipe Contreras
> ---
Applied, thanks!
--
Anton Vorontsov
Email: cbouatmai...@gmail.com
--
To unsubscribe from this list: send the line "unsubscrib
On Tue, Mar 13, 2012 at 11:33 AM, Tony Lindgren wrote:
> Hi Olof,
>
> Here's one more kernel panic fix that I dropped from last weeks
> fixes as it was still being discussed.
>
> This is a fix for the regression caused by fixing an earlier
> regression for smsc911x fixed regulators :(
>
> Turns ou
+ devicetree list and Mike T. for the clock aspect
Hi Tomi,
On 3/12/2012 2:45 PM, Tomi Valkeinen wrote:
Hi,
I'm struggling with the design of the DT data for OMAP display subsystem
driver, and any thoughts and ideas are welcome. This mail is a rather
long one, where I'm trying to show the diff
On 3/13/2012 6:07 PM, Tony Lindgren wrote:
* Benoit Cousson [120302 08:19]:
With the introduction of dynamically allocated IRQ in the twl6030 driver,
the board files can no longer rely of static IRQ defines like before.
Retrieve the value dynamically allocated from the mmc -> twl6030 init
cal
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.
Signed-off-by: Andy Gross
Signed-off-by: Rob Clark
---
arch/arm/mach-omap2/Makefile |4 ++
arch/arm/mach
Hi Olof,
Here's one more kernel panic fix that I dropped from last weeks
fixes as it was still being discussed.
This is a fix for the regression caused by fixing an earlier
regression for smsc911x fixed regulators :(
Turns out that we have more than one smsc911x on some boards,
and the earlier f
On Tue, Mar 13, 2012 at 05:26, wrote:
>
> diff --git a/arch/arm/mach-omap2/smartreflex.c
> b/arch/arm/mach-omap2/smartreflex.c
> index 7977018..dfe8075 100644
> --- a/arch/arm/mach-omap2/smartreflex.c
> +++ b/arch/arm/mach-omap2/smartreflex.c
...
> + switch (sr->ip_type) {
> + case SR_
* jean.pi...@newoldbits.com [120313 03:29]:
> From: Jean Pihet
>
> Add the class support so that various classes of operation can be
> implemented (class 1p5 etc.).
>
> Based on linux-omap's master branch (3.3.0-rc6), commit
> 85244e0edd240da2004bb2ab7cbcbc67a336f20d
We need to move smartrefle
omap_hwmod_softreset() does not seem to wait for reset status
after doing a softreset. Make it use _ocp_softreset() instead
which does this correctly.
Signed-off-by: Rajendra Nayak
Cc: Benoit Cousson
Cc: Paul Walmsley
Cc: Anand Gadiyar
Cc: Shubhrajyoti D
---
arch/arm/mach-omap2/omap_hwmod.c
After a softreset, make sure the sysc settings are correctly
restored.
Reported-by: Anand Gadiyar
Signed-off-by: Rajendra Nayak
Cc: Benoit Cousson
Cc: Paul Walmsley
Cc: Shubhrajyoti D
---
arch/arm/mach-omap2/omap_hwmod.c |4
1 files changed, 4 insertions(+), 0 deletions(-)
diff --g
This fixes a couple of issues around hwmod reset
APIs'.
Patches are based on 'hwmod_enable_remaining_hwmods_devel_3.4'
of git://git.pwsan.com/linux-2.6
Rajendra Nayak (2):
ARM: omap: hwmod: Restore sysc after a reset
ARM: omap: hwmod: Make omap_hwmod_softreset wait for reset status
arch/arm/
Hi Paul,
On Tuesday 13 March 2012 07:52 PM, Paul Walmsley wrote:
Hi Rajendra
On Tue, 13 Mar 2012, Rajendra Nayak wrote:
This fixes a couple of issues around hwmod reset
APIs'.
Patches are based on 3.3.-rc7.
Rajendra Nayak (2):
ARM: omap: hwmod: Restore sysc after a reset
ARM: omap: hwm
* Benoit Cousson [120302 08:19]:
> With the introduction of dynamically allocated IRQ in the twl6030 driver,
> the board files can no longer rely of static IRQ defines like before.
>
> Retrieve the value dynamically allocated from the mmc -> twl6030 init
> callback.
>
> Note: The Panda board doe
On Tue, Mar 13, 2012 at 10:01 PM, Kevin Hilman wrote:
> Santosh Shilimkar writes:
>
>> On Monday 12 March 2012 10:21 PM, Kevin Hilman wrote:
>>> Santosh Shilimkar writes:
>>>
On OMAP4, recently a synchronisation bug is discovered by hardware
team, which leads to incorrect timer value r
Santosh Shilimkar writes:
> On Monday 12 March 2012 10:21 PM, Kevin Hilman wrote:
>> Santosh Shilimkar writes:
>>
>>> On OMAP4, recently a synchronisation bug is discovered by hardware
>>> team, which leads to incorrect timer value read from 32K sync timer
>>> IP when the IP is comming out of i
"DebBarma, Tarun Kanti" writes:
> On Tue, Mar 13, 2012 at 12:03 PM, DebBarma, Tarun Kanti
> wrote:
>> On Tue, Mar 13, 2012 at 11:33 AM, DebBarma, Tarun Kanti
>> wrote:
>>> On Tue, Mar 13, 2012 at 3:24 AM, Kevin Hilman wrote:
Tarun Kanti DebBarma writes:
> In the existing _set_gp
On Mon, Mar 12, 2012 at 8:32 PM, 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
hi yang,
在 2012年3月10日 下午10:37，yang gqyang 写道：
> Thanks for your comment.
> Finally, i find out that i made a mistake. The uart(8250) have not been
> restore after resume, instead, it use the configuration got from boot. The
> uart have not been restored correctly, so that "ls" can not output
Hi Rajendra
On Tue, 13 Mar 2012, Rajendra Nayak wrote:
> This fixes a couple of issues around hwmod reset
> APIs'.
> Patches are based on 3.3.-rc7.
>
> Rajendra Nayak (2):
> ARM: omap: hwmod: Restore sysc after a reset
> ARM: omap: hwmod: Make omap_hwmod_softreset wait for reset status
>
>
After a softreset, make sure the sysc settings are correctly
restored.
Reported-by: Anand Gadiyar
Signed-off-by: Rajendra Nayak
Cc: Benoit Cousson
Cc: Paul Walmsley
Cc: Shubhrajyoti D
---
arch/arm/mach-omap2/omap_hwmod.c |4
1 files changed, 4 insertions(+), 0 deletions(-)
diff --g
This fixes a couple of issues around hwmod reset
APIs'.
Patches are based on 3.3.-rc7.
Rajendra Nayak (2):
ARM: omap: hwmod: Restore sysc after a reset
ARM: omap: hwmod: Make omap_hwmod_softreset wait for reset status
arch/arm/mach-omap2/omap_hwmod.c | 18 ++
1 files change
omap_hwmod_softreset() does not seem to wait for reset status
after doing a softreset. Make it use _ocp_softreset() instead
which does this correctly.
Signed-off-by: Rajendra Nayak
Cc: Benoit Cousson
Cc: Paul Walmsley
Cc: Anand Gadiyar
Cc: Shubhrajyoti D
---
arch/arm/mach-omap2/omap_hwmod.c
On Tuesday 13 March 2012 07:25 PM, Rajendra Nayak wrote:
omap_hwmod_softreset() does not seem to wait for reset status
after doing a softreset. Make it use _ocp_softreset() instead
which does this correctly.
Signed-off-by: Rajendra Nayak
Cc: Benoit Cousson
Cc: Paul Walmsley
Cc: Anand Gadiyar
Cc:
This fixes a couple of issues around hwmod reset
APIs'.
Patches are based on 3.3.-rc7.
Rajendra Nayak (2):
ARM: omap: hwmod: Restore sysc after a reset
ARM: omap: hwmod: Make omap_hwmod_softreset wait for reset status
arch/arm/mach-omap2/omap_hwmod.c | 18 +++---
1 files change
After a softreset, make sure the sysc settings are correctly
restored.
Reported-by: Anand Gadiyar
Signed-off-by: Rajendra Nayak
Cc: Benoit Cousson
Cc: Paul Walmsley
Cc: Shubhrajyoti D
---
arch/arm/mach-omap2/omap_hwmod.c |4
1 files changed, 4 insertions(+), 0 deletions(-)
diff --g
omap_hwmod_softreset() does not seem to wait for reset status
after doing a softreset. Make it use _ocp_softreset() instead
which does this correctly.
Signed-off-by: Rajendra Nayak
Cc: Benoit Cousson
Cc: Paul Walmsley
Cc: Anand Gadiyar
Cc: Shubhrajyoti D
---
arch/arm/mach-omap2/omap_hwmod.c
Hi Kevin, Paul,
I know you're busy, but I'd appreciate a comment/ack on these two small
patches, so I could get them in to next merge window. Otherwise using
any other OPP than OPP100 will most likely break the DSS.
This looks quite straightforward fix for me, but I'm not sure if there
could be a
On Monday 12 March 2012 04:57 PM, 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.
Signed-off-by: Grazvydas Ignotas
---
drivers/video/oma
Hi,
On Tue, Jan 24, 2012 at 7:38 AM, Kevin Hilman wrote:
> Vaibhav Hiremath writes:
>
>> OMAP device has 32k-sync timer which is currently used as a
>> clocksource in the kernel (omap2plus_defconfig).
>> The current implementation uses compile time selection between
>> gp-timer and 32k-sync time
> -Original Message-
> From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
> ow...@vger.kernel.org] On Behalf Of jean.pi...@newoldbits.com
> Sent: Tuesday, March 13, 2012 3:56 PM
> To: linux-omap@vger.kernel.org; linux-arm-
> ker...@lists.infradead.org; Kevin Hilman
> Cc: Nishanth Me
From: Nishanth Menon
Introduce private data for class drivers to operate on per
voltage domain. This removes the necessity for drivers such
as SmartReflex AVS Class 1.5 drivers from maintaining
a special lookup table which does not scale when number of
voltage domains change depending on silicon.
From: Nishanth Menon
Use SmartReflex AVS Class3 initialization only for OMAP343x family of
processors.
Signed-off-by: Nishanth Menon
Signed-off-by: Jean Pihet
---
arch/arm/mach-omap2/smartreflex-class3.c |5 +
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mac
From: Nishanth Menon
At times with bad SR configurations, especially during silicon bring-ups,
we could get continuous spurious interrupts which end up hanging the
platform in the form of an ISR call for status bits that are
automatically enabled by the hardware without any software clearing
opti
From: Nishanth Menon
We need some mechanism from class drivers to control when notifiers
should be triggered and when not, currently we have none, which makes
Class driver usage of the interrupt events almost impossible.
We also ensure that disable/enable or irq is always guarenteed to be
paired
From: Nishanth Menon
Certain class drivers such as class 1.5 drivers, will need specific
notification that they have to be inited up or deinited independent
of smart reflex operation. They also may need private data to be
used for operations of their own, provide the same.
This allows the class d
From: Nishanth Menon
SmartReflex IP V1 and V2 have different registers and offsets.
Currently, we pass the status as is to the class driver. However,
since we don't pass the version of the underlying SR hardware
to the Class driver, it will not be unable to make consistent
sense of the status bit
From: Jean Pihet
Add the class support so that various classes of operation can be
implemented (class 1p5 etc.).
Based on linux-omap's master branch (3.3.0-rc6), commit
85244e0edd240da2004bb2ab7cbcbc67a336f20d
Nishanth Menon (6):
ARM: OMAP3+: SmartReflex: introduce class init, deinit and pri
On Monday 12 March 2012 10:21 PM, Kevin Hilman wrote:
> Santosh Shilimkar writes:
>
>> On OMAP4, recently a synchronisation bug is discovered by hardware
>> team, which leads to incorrect timer value read from 32K sync timer
>> IP when the IP is comming out of idle.
>>
>> The issue is due to the
Resolve some warnings identified by cppcheck in arch/arm/mach-omap2:
[arch/arm/mach-omap2/usb-tusb6010.c:129]: (style) Checking if unsigned
variable 'tmp' is less than zero.
[arch/arm/mach-omap2/prm_common.c:241]: (error) Possible null pointer
dereference: irq_setup - otherwise it is re
On Tue, Mar 13, 2012 at 13:42, Paul Walmsley wrote:
>
>
> Resolve some warnings identified by cppcheck in arch/arm/mach-omap2:
>
> [arch/arm/mach-omap2/usb-tusb6010.c:129]: (style) Checking if unsigned
> variable 'tmp' is less than zero.
> [arch/arm/mach-omap2/prm_common.c:241]: (error) Poss
Resolve some warnings identified by cppcheck in arch/arm/mach-omap2:
[arch/arm/mach-omap2/usb-tusb6010.c:129]: (style) Checking if unsigned
variable 'tmp' is less than zero.
[arch/arm/mach-omap2/prm_common.c:241]: (error) Possible null pointer
dereference: irq_setup - otherwise it is re
On Tue, 13 Mar 2012, Jarkko Nikula wrote:
> On 03/13/2012 12:43 AM, Paul Walmsley wrote:
> > Resolve some warnings identified by cppcheck in arch/arm/mach-omap2:
> ...
> > [arch/arm/mach-omap2/mcbsp.c:133]: (warning) scanf without field width
> > limits can crash with huge input data
> ...
>
On Tue, Mar 13, 2012 at 4:12 AM, Paul Walmsley wrote:
> Several function declarations used only in the files in which they're
> declared should include the static keyboard, but don't:
>
> arch/arm/mach-omap2/serial.c:248:6: warning: symbol 'cmdline_find_option'
> was not declared. Should it be
On 03/13/2012 12:43 AM, Paul Walmsley wrote:
> Resolve some warnings identified by cppcheck in arch/arm/mach-omap2:
...
> [arch/arm/mach-omap2/mcbsp.c:133]: (warning) scanf without field width
> limits can crash with huge input data
...
> diff --git a/arch/arm/mach-omap2/mcbsp.c b/arch/arm/mac
On Tue, Mar 13, 2012 at 4:12 AM, Paul Walmsley wrote:
>
> Several C files in arch/arm/mach-omap2 declare functions that are used
> by other files, but don't include the header file where the prototype is
> declared. This results in the following warnings from sparse:
>
> arch/arm/mach-omap2/ir
52 matches
Mail list logo
