Olof Johansson writes:
> On Wed, Apr 10, 2013 at 11:14:52AM -0700, Tony Lindgren wrote:
>> Hi,
>>
>> Added Olof to cc, I suggest Olof pull this directly as we're starting
>> to run out of time.
>
> Hi,
>
> I'm terribly sorry for dropping this one on the floor, in spite of repeated
> pings from T
jp.franc...@cynove.com writes:
> _enable_preprogram is marked as __init, but is called from _enable which is
> not.
> This results in oops once init is freed.
> Fix this by removing the __init marker.
>
> Signed-off-by: Jean-Philippe François
Acked-by: Kevin Hilman
Tony, th
> Doing aes-128-cbc for 3s on 1024 size blocks: 11538 aes-128-cbc's in 0.05s
> Doing aes-128-cbc for 3s on 8192 size blocks: 4857 aes-128-cbc's in 0.03s
>
> While at it, also drop enter and exit pr_debugs, in related code. tracers
> can be used for that.
>
> Teste
are for OMAP5? The changelog should probably describe
which bits are for which platforms for those of us not intimate with
USB.
> CONFIG_USB_GADGET=y
> CONFIG_USB_GADGET_DEBUG=y
> CONFIG_USB_GADGET_DEBUG_FILES=y
Kevin
[1]
commit 06b4ba529528fbf9c24ce37b7618f4b0264750e2
Author: Kevin Hilman
Date: Fri
v Hiremath
Minor nit below, otherwise...
Reviewed-by: Kevin Hilman
> ---
> arch/arm/mach-omap2/control.h |5 +
> arch/arm/mach-omap2/id.c | 13 +
> arch/arm/mach-omap2/io.c |2 +-
> arch/arm/mach-omap2/soc.h |1 +
> 4 files ch
Hi Joel,
"Fernandes, Joel A" writes:
> Hi Kevin,
> Thanks for your review.
>
>> -Original Message-----
>> From: Kevin Hilman [mailto:khil...@linaro.org]
>> Sent: Monday, May 13, 2013 11:36 AM
>> To: Fernandes, Joel A
>> Cc: linux-cry...@vg
Salut Jean-philippe,
jean-philippe francois writes:
> Hi list,
>
> Launching program using I2C after init leads to an oops with 3.9 on a
> custom dm3730 based board.
>
> Looking at the disassembly of the _enable function in omap_hwmod.o, I
> noticed the call to _enable_preprogram was a direct br
Joel A Fernandes writes:
> Calling runtime PM API for every block causes serious perf hit to
> crypto operations that are done on a long buffer.
> As crypto is performed on a page boundary, encrypting large buffers can
> cause a series of crypto operations divided by page. The runtime PM API
> is
.
Reported-by: Tony Lindgren
Signed-off-by: Kevin Hilman
---
Based on v3.9-rc8
arch/arm/mach-omap2/omap_device.c | 2 +-
arch/arm/mach-omap2/soc.h | 1 +
2 files changed, 2 insertions(+), 1 deletion(-)
diff --git a/arch/arm/mach-omap2/omap_device.c
b/arch/arm/mach-omap2/omap_device.c
Hi Alan,
Alan Stern writes:
> Felipe and Kevin:
>
> While removing the remaining usages of USB_SUSPEND (things that I
> missed in the original patch), I noticed that
> arch/arm/configs/omap2plus_defconfig does not enable PM_RUNTIME -- even
> though it currently does enable USB_SUSPEND, which dep
Sourav Poddar writes:
> The driver manages "no_console_suspend" by preventing runtime PM
> during the suspend path, which forces the console UART to stay awake.
>
> Signed-off-by: Sourav Poddar
> Reviewed-by: Felipe Balbi
> ---
> drivers/tty/serial/omap-serial.c | 28
handling.
>
> The series tries to address the issue and tries to remove complete
> sysc handling from serial driver.
Other than the minor nit about the order of the series for bisect,
Reviewed-by: Kevin Hilman
Also tested this on OMAP4/Panda where I was having the sluggish console
is
Rajendra Nayak writes:
> From: Santosh Shilimkar
>
> UART IP slave idle handling now taken care by runtime pm backend(hwmod layer)
> so remove the hackery from the driver.
>
> As discussed on the list, in future if dma mode needs to be brought
> back to this driver, UART sysc handling needs to b
Hi Sourav,
Sourav Poddar writes:
> Hi Kevin,
> On Thursday 25 April 2013 03:45 AM, Kevin Hilman wrote:
>> Sourav Poddar writes:
>>
>>> Remove "no_idle_on_suspend" check, since respective
>>> driver should be able to prevent idling of a
>>
Tony Lindgren writes:
> * Santosh Shilimkar [130419 10:56]:
>> On Friday 19 April 2013 11:14 PM, Tony Lindgren wrote:
>> > * Santosh Shilimkar [130419 10:43]:
>> >> On Friday 19 April 2013 10:43 PM, Tony Lindgren wrote:
>> >>> Hi all,
>> >>>
>> >>> Here's a list of breakage I've noticed so far
Sourav Poddar writes:
> Remove "no_idle_on_suspend" check, since respective
> driver should be able to prevent idling of a
> device whenever required.
>
> Driver's can get same behavior by just returning -EBUSY
> from their ->runtime_suspend only during suspend.
>
> Cc: Santosh Shilimkar
> Cc: F
Sourav Poddar writes:
> The driver manages "no_console_suspend" by preventing runtime PM
> during the suspend path, which forces the console UART to stay awake.
>
> Signed-off-by: Sourav Poddar
> ---
> drivers/tty/serial/omap-serial.c | 29 -
> 1 files changed, 28
Andreas Fenkart writes:
> When a gpio interrupt is masked, the gpio event will still be latched in
> the interrupt status register so when you unmask it later you may get an
> interrupt straight away. However, if the interrupt is disabled then gpio
> events occurring will not be latched/stored.
>
Olof Johansson writes:
> On Wed, Apr 10, 2013 at 11:14:52AM -0700, Tony Lindgren wrote:
>> Hi,
>>
>> Added Olof to cc, I suggest Olof pull this directly as we're starting
>> to run out of time.
>
> Hi,
>
> I'm terribly sorry for dropping this one on the floor, in spite of repeated
> pings from T
Grygorii Strashko writes:
> On 04/22/2013 04:43 PM, Sourav Poddar wrote:
>> Remove the "OMAP_DEVICE_NO_IDLE_ON_SUSPEND" check, since
>> driver should be able to prevent idling of an omap device
>> whenever required.
>>
>> Cc: Santosh Shilimkar
>> Cc: Felipe Balbi
>> Cc: Rajendra nayak
>> Cc: G
Grygorii Strashko writes:
> On 04/22/2013 04:43 PM, Sourav Poddar wrote:
>> The driver manages "no_console_suspend" by preventing runtime PM
>> during the suspend path, which forces the console UART to stay awake.
>>
>> Signed-off-by: Sourav Poddar
>> ---
>> drivers/tty/serial/omap-serial.c |
Sourav Poddar writes:
[...]
> Yes, got your point. omap_device_idle should not be called only
> for console uart.
>
> Just did a quick testing by including the following hunk on top of my
> patch series..
>
> diff --git a/arch/arm/mach-omap2/omap_device.c
> b/arch/arm/mach-omap2/omap_device.c
>
Santosh Shilimkar writes:
> On Friday 19 April 2013 06:19 AM, Jon Hunter wrote:
>>
>> On 04/18/2013 07:34 PM, Jon Hunter wrote:
>>>
>>> On 04/18/2013 06:10 PM, Jon Hunter wrote:
>>>> On 04/18/2013 04:34 PM, Kevin Hilman wrote:
>>>
>>
Sourav Poddar writes:
> On Thursday 18 April 2013 11:35 PM, Kevin Hilman wrote:
>> Sourav Poddar writes:
>>
>>> Remove the "OMAP_DEVICE_NO_IDLE_ON_SUSPEND" check, since UART was the only
>>> one making
>>> use of it. Now serial core/driver
Sourav Poddar writes:
> Hi Kevin,
> On Thursday 18 April 2013 11:26 PM, Kevin Hilman wrote:
>> Sourav Poddar writes:
>>
>>> The patch adapt the serial core/driver to take care of the case when
>>> "no_console_suspend"
>>> is used in t
Hi Jon,
Jon Hunter writes:
> Commit a2797be (gpio/omap: force restore if context loss is not
> detectable) broke gpio support for OMAP when booting with device-tree
> because a restore of the gpio context being performed without ever
> initialising the gpio context. In other words, the context r
Hi Sourav,
Sourav Poddar writes:
> Hi,
>
> This patch series contains fixes and cleanups around the issue that
> the console UART should not idled on suspend while using "no_console_suspend"
> in bootargs.
>
The direction of the series is right, thanks for the updated approach.
I had a comple
Sourav Poddar writes:
> Since the omap serial driver is now adapted to handle the
> case where you dont need to cut the clock on suspend while
> using "no_console_suspend" in the bootargs.
>
> We can get rid of the previous implementation of setting the od->flags to
> "OMAP_DEVICE_NO_IDLE_ON_SUSP
Sourav Poddar writes:
> Since the omap serial driver is now adapted to handle the
> case where you dont need to cut the clock on suspend while
> using "no_console_suspend" in the bootargs.
>
> We can get rid of the previous implementation of setting the od->flags to
> "OMAP_DEVICE_NO_IDLE_ON_SUSP
Sourav Poddar writes:
> Remove the "OMAP_DEVICE_NO_IDLE_ON_SUSPEND" check, since UART was the only
> one making
> use of it. Now serial core/driver takes care of the case when
> "no_console_suspend"
> is used in the bootargs and you need to keep the clock enable for console
> even while suspe
Sourav Poddar writes:
> The patch adapt the serial core/driver to take care of the case when
> "no_console_suspend"
> is used in the bootargs. The patch will remove dependency to set od->flags to
> "OMAP_DEVICE_NO_IDLE_ON_SUSPEND" in serial.c(non dt case) and
> omap_device.c(dt case).
>
> Prepa
Andrii Tseglytskyi writes:
> Hi Kevin,
>
> On 04/16/2013 12:53 AM, Kevin Hilman wrote:
>> Andrii Tseglytskyi writes:
>>
>>> From: "Andrii.Tseglytskyi"
>>>
>>> Following patch series introduces the Adaptive Body-Bias
>>&g
vly lifting here and should
be the maintainer going forward, IMO. Patch below.
Linus, do you want to queue this up?
Kevin
>From 00d19c10c02c3a3aa99ca7ae75bc88a932437abd Mon Sep 17 00:00:00 2001
From: Kevin Hilman
Date: Mon, 15 Apr 2013 15:02:26 -0700
Subject: [PATCH] MAINTAINERS: update OMAP GPIO driver: Jon
Andrii Tseglytskyi writes:
> From: "Andrii.Tseglytskyi"
>
> Following patch series introduces the Adaptive Body-Bias
> LDO driver, which handles LDOs voltage during OPP change routine.
> Current implementation is based on patch series from
> Mike Turquette:
>
> http://marc.info/?l=linux-omap&m=1
Hi Vaibhav,
"Bedia, Vaibhav" writes:
[...]
>> So, my proposal is that Sourav remove that flag from the AM33xx hwmod
>> when he removes this feature.
>
> Apologies for the delayed response. I was out of office for a couple of
> days.
>
> I don't recall the exact kernel version in which I ended u
Kevin Hilman writes:
> "Bedia, Vaibhav" writes:
>
>> Hi Sourav,
>>
>> On Wed, Apr 10, 2013 at 15:13:44, Poddar, Sourav wrote:
>> [...]
>>> Yes, had a look at that and found your situation similar to UART.
>>>
>>> But how e
"Bedia, Vaibhav" writes:
> Hi Sourav,
>
> On Wed, Apr 10, 2013 at 15:13:44, Poddar, Sourav wrote:
> [...]
>> Yes, had a look at that and found your situation similar to UART.
>>
>> But how exactly this gets used, I mean I don't see any drivers/ in mainline
>> making use of this compatible strin
[resend with correct address for linux-pm]
Rafael,
Please pull the following OMAP CPUidle changes for v3.10.
Due to dependencies on other CPUidle changes that are already in your
linux-next branch, this branch is based on the commit where you merged
your pm-cpuidle-next branch into linux-next.
ver which is used on OMAP platforms when
device tree nodes are present.
Inspired by commit 5553f9e26f6f49a93ba732fd222eac6973a4cf35
(cpufreq: instantiate cpufreq-cpu0 as a platform_driver)
Cc: Kevin Hilman
Cc: Rajendra Nayak
Cc: Paul Walmsley
Cc: "Benoît Cousson"
Cc: Jon Hunter
Cc:
Rafael,
Please pull the following OMAP CPUidle changes for v3.10.
Due to dependencies on other CPUidle changes that are already in your
linux-next branch, this branch is based on the commit where you merged
your pm-cpuidle-next branch into linux-next.
Kevin
The following changes since commit f6
Tony,
Here's the final set of OMAP PM cleanups for v3.10. This is a small set
of cleanups from Santosh to consolidate and prepare for OMAP5 PM additions.
It's based on your cleanup-v2 branch.
Kevin
The following changes since commit c309f7f46167e85d1aae2fd31f23e7d2b5cdfbe0:
Merge branch 'f
Daniel Lezcano writes:
[...]
>>>>>>
>>>>>> PM cleanup to prepare for omap5 PM via Kevin Hilman :
>>>>>>
>>>>>> OMAP3/4 CPUidle cleanups for v3.10
>>>>>
>>>>> Adding Daniel and Rafael to Cc.
&
Sourav Poddar writes:
> Hi Kevin,
> On Friday 05 April 2013 11:10 PM, Kevin Hilman wrote:
>> Sourav Poddar writes:
>>
>>> With dt boot, uart wakeup after suspend is non functional while using
>>> "no_console_suspend" in the bootargs. With "
Tony Lindgren writes:
> * Kevin Hilman [130409 09:43]:
>> Arnd Bergmann writes:
>>
>> > On Tuesday 09 April 2013, Tony Lindgren wrote:
>> >> The following changes since commit
>> >> 07961ac7c0ee8b546658717034fe692fd12eefa9:
>>
git://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-omap-pm
>> into omap-for-v3.10/cleanup-pm (2013-04-08 09:51:00 -0700)
>>
>> --------
>>
>> PM cleanup to prepare for omap5 PM via Kevin Hilman :
>>
Tony,
Please pull the following changes for OMAP CPUidle for v3.10.
Kevin
The following changes since commit 07961ac7c0ee8b546658717034fe692fd12eefa9:
Linux 3.9-rc5 (2013-03-31 15:12:43 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/khilman/l
Tony,
This OMAP PM fixes tag is based on your cleanup-v2 branch due to some
dependencies in the series from Santosh you already merged.
Kevin
The following changes since commit c309f7f46167e85d1aae2fd31f23e7d2b5cdfbe0:
Merge branch 'for_3.10/omap_generic_cleanup_v2' of
git://git.kernel.org/
Santosh Shilimkar writes:
> As discussed on list, I split the v2 [1] series into cleanup and OMAP5
> support.
Thanks.
> This series contains the clean-up patches. I have rebased on top of Tony's
> pull request and your 3.10/* branches. Series is tested on OMAP4430 SDP
> with CPUIDLE and suspen
pufreq".
>> > b) Since the platform_device is registered only when device tree nodes
>> >are *not* populated, omap-cpufreq driver does not conflict with
>> >the usage of cpufreq-cpu0 driver which is used on OMAP platforms when
>> >device tree nodes a
Santosh Shilimkar writes:
> The OMAP5 idle driver can re-use most of OMAP4 CPUidle driver
> implementation. Also the next derivative SOCs are going to re-use
> the MPUSS so, same driver with minor updates can be re-used.
>
> Prepare the code so that its easier to add CPUidle support for
> OMAP5 d
are always powered
>
> Tarun Kanti DebBarma (1):
> gpio/omap: remove extra context restores in *_runtime_resume()
For the gpio/omap patches
Reviewed-by: Kevin Hilman
--
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
Sourav Poddar writes:
> With dt boot, uart wakeup after suspend is non functional while using
> "no_console_suspend" in the bootargs. With "no_console_suspend" used, we
> should prevent the runtime suspend of the uart port which is getting used
> as an console.
>
> Cc: Santosh Shilimkar
> Cc: Fel
Santosh Shilimkar writes:
> On Thursday 04 April 2013 08:04 PM, Santosh Shilimkar wrote:
>> On Thursday 04 April 2013 04:22 AM, Kevin Hilman wrote:
>>> Hi Santosh,
>>>
>>> Santosh Shilimkar writes:
>>>
>>>> Here is the refreshed version(v
Santosh Shilimkar writes:
> On Thursday 04 April 2013 02:55 AM, Kevin Hilman wrote:
>> Santosh Shilimkar writes:
>>
>>> The OMAP5 idle driver can re-use OMAP4 CPUidle driver implementation thanks
>>> to compatible MPUSS design.
>>>
>>> Thoug
Santosh Shilimkar writes:
> On Thursday 04 April 2013 02:24 AM, Kevin Hilman wrote:
>> Santosh Shilimkar writes:
>>
>>> While waking up CPU from off state using clock domain force wakeup, restore
>>> the CPU power state to ON state before putting CPU clock
Santosh Shilimkar writes:
> On Thursday 04 April 2013 02:19 AM, Kevin Hilman wrote:
>> Santosh Shilimkar writes:
>>
>>> Add power management code to handle the CPU off mode to enable CPUP hotplug
>>> mode for OMAP5 devices. Separate suspend finisher
Hi Santosh,
Santosh Shilimkar writes:
> Here is the refreshed version(v2) of the OMAP5 PM suspport which was posted
> earlier (March 1st 2013). Patch-set incorporates comments from Nishant
> Menon (Thanks for review NM) and his acked-by tags. I would like to get this
> queued for 3.10 merge wind
to drivers/idle/*
once the PRM/CM code gets moved to drivers. This patch also reduces one
dependency with platform code for idle driver movement.
Acked-by: Nishanth Menon
Signed-off-by: Santosh Shilimkar
[khil...@linaro.org: minor changelog edits]
Signed-off-by: Kevin Hilman
---
arch/arm/mach-o
Santosh Shilimkar writes:
> The OMAP5 idle driver can re-use OMAP4 CPUidle driver implementation thanks
> to compatible MPUSS design.
>
> Though unlike OMAP4, on OMAP5 devices, MPUSS CSWR (Close Switch
> Retention) power states can be achieved with respective power states
> on CPU0 and CPU1 power
Santosh Shilimkar writes:
> The OMAP5 idle driver can re-use most of OMAP4 CPUidle driver
> implementation. Also the next derivative SOCs are going to re-use
> the MPUSS so, same driver with minor updates can be re-used.
>
> Prepare the code so that its easier to add CPUidle support for
> OMAP5 d
Santosh Shilimkar writes:
> It is useful to know the CPU power state along with MPUSS power state
> in a supported C-state. Since the data is available via sysfs, one can
> avoid scrolling the source code for precise construction of C-state.
>
> Reported-by: Nishanth Menon
> Acked-by: Nishanth M
Santosh Shilimkar writes:
> If the CPUidle device registration fails for some reason, we should
> unregister the driver on error path.
>
> Fix the code accordingly. Also when at it, check of the driver registration
> failure too.
>
> Acked-by: Nishanth Menon
> Signed-off-by: Santosh Shilimkar
Santosh Shilimkar writes:
> OMAP4 CPUidle driver registration call is under a loop which leads
> to calling cpuidle_register_driver twice which is not intended.
>
> Fix it by moving the driver registration outside the loop.
>
> Reported-by: Nishanth Menon
> Acked-by: Nishanth Menon
> Signed-off
Santosh Shilimkar writes:
> When the entire MPUSS cluster is powered down in device off state, L2 cache
> memory looses it's content and hence while targetting such a state,
> l2 cache needs to be flushed to main memory.
>
> Add the necessary low power code support for the same.
>
> Acked-by: Nis
Santosh Shilimkar writes:
> While waking up CPU from off state using clock domain force wakeup, restore
> the CPU power state to ON state before putting CPU clock domain under
> hardware control. Otherwise CPU wakeup might fail. The change is recommended
> for all OMAP4+ devices though the PRCM w
Santosh Shilimkar writes:
> Add power management code to handle the CPU off mode to enable CPUP hotplug
> mode for OMAP5 devices. Separate suspend finisher is used for
> OMAP5(Cortex-A15)
> because it doesn't use SCU power status register and external PL310 L2 cache
> which makes code flow bit d
Santosh Shilimkar writes:
> With consolidated code, now we can add the .init_late hook for
> OMAP5 to enable power management and mux initialization.
>
> Acked-by: Nishanth Menon
> Signed-off-by: Santosh Shilimkar
> ---
> arch/arm/mach-omap2/board-generic.c |1 +
> arch/arm/mach-omap2/comm
Santosh Shilimkar writes:
> In addition to the standard power-management technique, the OMAP5
> MPU subsystem also employs an SR3-APG (mercury) power management
> technology to reduce leakage.
>
> It allows for full logic and memories retention on MPU_C0 and MPU_C1 and
> is controlled by the PRCM
Santosh Shilimkar writes:
> Enables MPUSS ES2 power management mode using ES2_PM_MODE in
> AMBA_IF_MODE register.
>
> 0x0: ES1 behavior, CPU cores would enter and exit OFF mode together. Broken
What is broken?
> 0x1: ES2 behavior, CPU cores are allowed to enter/exit OFF mode independently.
>
>
Santosh Shilimkar writes:
> OMAP5 has backward compatible PRCM block and it's programming
> model is mostly similar to OMAP4. Same is going to be maintained
> for future OMAP4 based SOCs. Hence consolidate the OMAP4 power
> management code so that it can be re-used on OMAP5 and later devices.
>
>
Hi Santosh,
Santosh Shilimkar writes:
> OMAP5 and future OMAP based SOCs has backward compatible MPUSS
> IP block with OMAP4. It's programming model is mostly similar.
> Hence consolidate the OMAP MPUSS code so that it can be re-used
> on OMAP5 and future SOCs.
>
> No functional change.
>
> Acke
atch/2067841/
> now made generic.
>
> Cc: Kevin Hilman
> Cc: Rajendra Nayak
> Cc: Paul Walmsley
> Cc: "Benoît Cousson"
> Cc: Jon Hunter
> Cc: Keerthy
> Cc: Santosh Shilimkar
> Cc: Shawn Guo
> Signed-off-by: Nishanth Menon
One more thought on this
Sourav Poddar writes:
> Hi Kevin,
> On Wednesday 20 March 2013 05:36 PM, Sourav Poddar wrote:
>> Realised the list to whom the patch was send got dropped. Ccing
>> them all..
>> On Wednesday 20 March 2013 05:18 PM, Sourav Poddar wrote:
>>> Hi Kevin,
>>>
Nishanth Menon writes:
> The following version 3 of the series arose from trying to use BeagleBoard-XM
> (OMAP3 variant) for doing CPU DVFS using cpufreq-cpu0. This series enables the
> generic cpufreq-cpu0 driver to be used in device tree enabled boot while
> maintaining support of the legacy om
Santosh Shilimkar writes:
> On Thursday 28 March 2013 01:39 AM, Shilimkar, Santosh wrote:
>> Sorry for top posting ...
>> I will pick the ack and update commit log to prepare new pull request
>> for you.
>>
> I have updated the branch picking acks and updating changelogs and same
> is available
Hi Nishanth,
Nishanth Menon writes:
> Hi,
> The following version 2 of the series arose from trying to use BeagleBoard-XM
> (OMAP3 variant) for doing CPU DVFS using cpufreq-cpu0. This series enables the
> generic cpufreq-cpu0 driver to be used in device tree enabled boot while
> maintaining supp
Santosh Shilimkar writes:
> On Thursday 28 March 2013 12:15 AM, Kevin Hilman wrote:
>> Santosh Shilimkar writes:
>>
>>> Move the secondary CPU wakeup prepare code under smp_prepare_cpus().
>>
>> Why?
>>
> Because that code belongs to smp_prepa
OMAP4 SOCs.
>
> Cc: Kevin Hilman
>
> Signed-off-by: Santosh Shilimkar
Nice.
Acked-by: Kevin Hilman
> ---
> arch/arm/mach-omap2/pm44xx.c |6 ++
> 1 file changed, 2 insertions(+), 4 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/pm44xx.c b/arch/arm/mach-omap2/pm4
of the proposed workaround but from
> power savings perspective, it isn't an ideal workaround.
>
> Cc: Jon Hunter
> Cc: Kevin Hilman
>
> Signed-off-by: Santosh Shilimkar
Nice.
Acked-by: Kevin Hilman
--
To unsubscribe from this list: send the line "unsubscribe lin
Santosh Shilimkar writes:
> Move the secondary CPU wakeup prepare code under smp_prepare_cpus().
Why?
> While at
> it drop the un-necessary sev() and barrier which was under prepare code.
>
> Signed-off-by: Santosh Shilimkar
> ---
> arch/arm/mach-omap2/omap-smp.c | 51
> --
Santosh Shilimkar writes:
> This was added with intial port where OMAP PM support wasn't existing
> and only simple WFI based hooks were used.
>
> This should have been cleaned up while adding the PM support but some
> how fall through cracks.
Changelog describes a bit of history, but does not i
Santosh Shilimkar writes:
> From: Tero Kristo
>
> Simplifies code and also allows the re-use as is on OMAP5 devices.
nit: changelog here is rather weak. It claims "simplifies code" but
it's not obvious from the patch how changing a few #defines does that.
Kevin
> Signed-off-by: Tero Kristo
eq.
>
> In the case of (2), we will not have the cpufreq-cpu0 device, hence
> only omap-cpufreq will be active.
>
> So, to acommodate both these usage conditions, we fail init of
> omap-cpufreq when we boot with device tree.
>
> Cc: Kevin Hilman
> Cc: Jon Hunter
> Cc:
Santosh Shilimkar writes:
> On OMAP platform, FIQ is reserved for secure environment only. If at all
> the FIQ needs to be disabled, it involves going through security
> API call. Hence the local_fiq_[enable/disable]() in the OMAP code is bogus.
>
> So just get rid of it.
What about GP devices?
Sourav Poddar writes:
> OMAP_MAX_HSUART_PORTS is moved to omap_serial header file.
Why?
You started to explain it in the cover letter, but a full description
belongs here for the permanent git history.
Kevin
> Cc: Santosh Shilimkar
> Cc: Felipe Balbi
> Cc: Rajendra nayak
> Signed-off-by:
just noticed this on my Panda boards with CPUidle enabled, and
$SUBJECT patch fixes it.
FWIW,
Tested-by: Kevin Hilman
I agree that this should get queued for v3.9-rc.
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
and OMAP5430(with few out of tree
>> patches)
>> devices for suspend and CPUidle.
>>
>> Cc: Kevin Hilman
>>
>> Reported-by: Richard Woodruff
>> Signed-off-by: Santosh Shilimkar
>> ---
>> Update changelog to include testing details as suggeste
Jon Hunter writes:
> Summary of updates:
> - Convert OMAP GPIO driver to use linear mapping for IRQ domains
> - Avoid crashes seen if a gpio bank is not enabled when requesting an IRQ.
Acked-by: Kevin Hilman
--
To unsubscribe from this list: send the line "unsubscribe linux-oma
Santosh Shilimkar writes:
> UART IP slave idle handling now taken care by runtime pm backend(hwmod layer)
> so remove the hackery from the driver.
>
> Tested-by: Vaibhav Bedia
> Tested-by: Sourav Poddar
> Signed-off-by: Rajendra nayak
> Signed-off-by: Santosh Shilimkar
>
> ---
> drivers/tty/
"Bedia, Vaibhav" writes:
[...]
>> IMO, this would be a much cleaner implementation if you just created a
>> small driver for the wkup_m3. You're already doing a bunch of
>> driver-like stuff for it (requesting base/IRQs, mapping regions,
>> firmware, etc.) I think this should separated out int
Felipe Balbi writes:
> Hi,
>
> On Tue, Feb 19, 2013 at 11:50:37AM -0800, Kevin Hilman wrote:
>> >> The other problem is the where reset is need during runtime. Again,
>> >> what are the specific examples here? The one I can think of off the top
>> >
Felipe Balbi writes:
> Hi,
>
> On Tue, Feb 19, 2013 at 11:16:38AM -0800, Kevin Hilman wrote:
>
> [ ... ]
>
>> The other problem is the where reset is need during runtime. Again,
>> what are the specific examples here? The one I can think of off the top
>>
[...]
>> > Just to recap what we've discussed earlier, the reasons why we want
>> > reset and idle functions should be in the driver specific header are:
>> >
>> > 1. There's often driver specific logic needed in addition to the
>> >syconfig tinkering in the reset/idle functions.
>>
>> It's
Philip Avinash writes:
> With GPMC converted to platform driver recently, adds low power
> transition support in driver itself.
>
> Signed-off-by: Philip Avinash
> ---
> Changes since v1:
> Module disable & enable added using pm_runtime support.
>
> arch/arm/mach-omap2/gpmc.c | 20 +
"Bedia, Vaibhav" writes:
> Hi Kevin,
>
> On Tue, Feb 12, 2013 at 06:57:50, Kevin Hilman wrote:
> [...]
>> > +
>> > +void (*am33xx_do_wfi_sram)(void);
>>
>> static?
>
> Will fix.
>
> [...]
>
>> > +
>> > + /*
&
Felipe Balbi writes:
> Hi,
>
> On Sat, Feb 16, 2013 at 11:31:21AM +0530, Santosh Shilimkar wrote:
>> >>The main goal is to avoid duplicating data both in hwmod and DT.
>> >>That's pretty much solved as we can have the driver probe populate
>> >>the common data for hwmod from DT as Santosh has alr
Santosh Shilimkar writes:
> On Friday 15 February 2013 09:10 PM, Kevin Hilman wrote:
>> Felipe Balbi writes:
>>
>>> Currently the omap-serial driver will not
>>> work properly if booted via DT with CPUIDLE
>>> enabled because it depends on function po
Roger Quadros writes:
> On 02/15/2013 05:54 PM, Kevin Hilman wrote:
>> Roger Quadros writes:
>>
>>> Hi Kevin,
>>>
>>> On 02/15/2013 12:50 AM, Kevin Hilman wrote:
>>>> Felipe, Roger,
>>>>
>>>> Using Tony'
Roger Quadros writes:
> Hi Kevin,
>
> On 02/15/2013 12:50 AM, Kevin Hilman wrote:
>> Felipe, Roger,
>>
>> Using Tony's current master branch, and enabling EHCI support, I see
>> the clock framework spitting loudly about the EHCI driver (full boot log
>&
sn't address the
context_loss or enable_wakeup func pointers), but at least gets rid of
the need for any SYSCONFIG access in the driver for the idle modes.
Needs more thorough testing.
Kevin
>From 3d3956472d2375b5ed939d1d0165e439aa47262f Mon Sep 17 00:00:00 2001
From: Kevin Hilma
301 - 400 of 5500 matches
Mail list logo
