On Mon, 2011-06-06 at 17:28 +0200, Cousson, Benoit wrote:
> Before doing that, could you maybe just try something to make OMAP4
> looks a little bit more like OMAP3?
>
> dss_fck -> ick
> dss_dss_fck -> main_clk
>
> That should ensure that both modulemode and the PRCM fclk will be
> managed by
On Mon, 2011-06-06 at 14:56 +0200, Cousson, Benoit wrote:
> That terminology in the PRCM just means that an opt clock will not be
> handled automatically by the PRCM and will require SW control.
> This is not the case for mandatory clock. Upon module enable the PRCM
> will ensure that all mandat
OMAP4's PRM_VC_CFG_CHANNEL register allows for flexibility of configuring
for various PMIC configurations. In combinations where we'd like to
use the default VC channel's voltage_reg address in a particular non-default
VC channel, we allow the use of USE_DEFAULT_CHANNEL_I2C_PARAM.
Since 0 is a val
Every PMIC has it's own eccentricities, For example, one of the
PMIC has MSB set to 1 for a specific function - voltage enable!
using an hardcoded value specific for TWL when copied over to
such an implementation causes the system to crash as the MSB bit
was 0 and the voltage got disabled!.
Instea
OPP functions as described in Documentation/power/opp.txt
should be accessed under rcu_locks.
Signed-off-by: Nishanth Menon
---
arch/arm/mach-omap2/pm.c |3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/pm.c b/arch/arm/mach-omap2/pm.c
index d085f29..7
Since we are starting to use multiple PMICs in various combinations,
use the existing .omap_chip = OMAP_CHIP_INIT() to mark the
structures we are interested in using per OMAP device we
are currently running on. This mapping is based on the default
device recommendations from TI. Boards using custom
Many simpler PMICs such as TPS65023 as discussed in [1] with a single
I2C interface do still have configuration registers that
may need population. Typical being slew rate, thermal shutdown
configuration etc. These devices are typically hooked on Application
Processor's(AP) standard I2C busses. Unf
OMAP4's PRM_VC_CFG_CHANNEL register allows for flexibility of configuring
for various PMIC configurations. In combinations where we'd like to
use the default VC channel's cmd_reg address in a particular non-default
VC channel, we allow the use of USE_DEFAULT_CHANNEL_I2C_PARAM.
Since 0 is a valid r
OMAP4's PRM_VC_CFG_CHANNEL register allows for flexibility of configuring
for various PMIC configurations. In combinations where the same slave address
is used for all domains, it is possible to setup the VC channel for the
dependent channels to use the same slave address as the default channel.
S
if volt_reg and cmd_reg are the same from PMIC configuration,
we can use the cmd reg by using racen - this is valid for
voltage commands, however, in most cases, we'd like to retain
voltage reg configuration as well for vfsm commands going thru
from h/w.
Signed-off-by: Nishanth Menon
---
arch/ar
"OMAP3+: PM: VC: handle mutant channel config for OMAP4 MPU channel"
handles the mutant channel flags, however since vc_cfg_bits is static
file wide variable, it makes better sense to update this based on
the specific channel using mutant or not. else if we have a initial
registration of mutant cha
Bunch of fixes for VC, VP incorporating previous comments
merges two series of PMIC and voltage cleanups I send previously.
Applies on:
git://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-omap-pm.git
voltdm_nm 3c217ab OMAP3+: PM: VC: handle mutant channel config for OMAP4
MPU channel
Since we do module_init, cpufreq initializes before power late_init
where many of the required data structures are registered. Move
cpufreq init to late_initcall instead. Further CONFIG_CPU_FREQ
on which the build depends is bool and does'nt support modules yet.
Signed-off-by: Nishanth Menon
---
From: Colin Cross
Sometimes, bootloaders starts up with a frequency which is not
in the OPP table. At cpu_init, policy->cur contains the frequency
we pick at boot. It is possible that system might have fixed
it's boot frequency later on as part of power initialization.
After this condition, the
Probably should be squashed to:
"OMAP2+: cpufreq: fix freq_table leak"
Looks like I've been lazy and added up a useless else case!
Signed-off-by: Nishanth Menon
---
arch/arm/mach-omap2/omap2plus-cpufreq.c |6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/arm/mac
Hi,
Here are a set of fixes on cpufreq based.
Basic tests with ondemand, userspace governors on:
SDP3630
SDP4430
Applies on:
git://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-omap-pm.git
cpufreq 8651d1b OMAP2+: cpufreq: fix freq_table leak
Colin Cross (1):
OMAP2+: cpuf
Commit 6d3163ce86dd386b4f7bda80241d7fea2bc0bb1d, "mm: check if any
page in a pageblock is reserved before marking it MIGRATE_RESERVE",
exhibited a bug on my Amstrad Delta resulting in reading
/sys/device/platform/*/uevent for selected devices, namely "omap-
keypad", "lcd_ams_delta", "ams-delta-l
On Mon, Jun 6, 2011 at 5:18 PM, Kevin Hilman wrote:
> Hi Colin,
>
> Colin Cross writes:
>
>> Setting the IRQWAKEN bit was overwriting previous IRQWAKEN bits,
>> causing only the last bit set to take effect, resulting in lost
>> wakeups when the GPIO controller is in idle.
>>
>> Replace direct wri
Tony,
Please pull the following fixes for v3.0-rc. Looks like I just missed
your pull request, so you can add this to the next one.
Note that I split the section mismatch patch from Russell into two. One
to go through you for OMAP core and the other (GPIO) to go through that
driver tree.
Kevin
Todd Poynor writes:
> On Mon, Jun 06, 2011 at 03:32:29PM -0700, Kevin Hilman wrote:
>> Colin Cross writes:
>>
>> > On Sat, Jun 4, 2011 at 12:03 PM, Colin Cross wrote:
>> >> Setting the IRQWAKEN bit was overwriting previous IRQWAKEN bits,
>> >> causing only the last bit set to take effect, resu
Hi Colin,
Colin Cross writes:
> Setting the IRQWAKEN bit was overwriting previous IRQWAKEN bits,
> causing only the last bit set to take effect, resulting in lost
> wakeups when the GPIO controller is in idle.
>
> Replace direct writes to IRQWAKEN with MOD_REG_BIT calls to
> perform a read-modif
On Mon, Jun 06, 2011 at 03:32:29PM -0700, Kevin Hilman wrote:
> Colin Cross writes:
>
> > On Sat, Jun 4, 2011 at 12:03 PM, Colin Cross wrote:
> >> Setting the IRQWAKEN bit was overwriting previous IRQWAKEN bits,
> >> causing only the last bit set to take effect, resulting in lost
> >> wakeups wh
"Menon, Nishanth" writes:
> On Fri, Jun 3, 2011 at 07:16, Santosh Shilimkar
> wrote:
>> Current OMAP2PLUS CPUfreq tagret() functions returns when all
>> the CPU's are not online. This breaks CPUfreq when secondary CPUs
>> are offlined on SMP system.
>>
>> The intention of that check was just avo
"Rafael J. Wysocki" writes:
[..]
> While it is tempting to try to get away with only two PM callbacks per
> driver instead of four (or even more), it generally is not doable, simply
> because driver callbacks are not executed directly by the core.
>
> The only way to address the problem of code
_set_gpio_triggering uses read-modify-write on bank registers,
lock bank->lock around all calls to it to prevent register
corruption if two cpus access gpios in the same bank at the
same time.
Signed-off-by: Colin Cross
---
drivers/gpio/gpio-omap.c |9 +
1 files changed, 9 insertions
Setting the IRQWAKEN bit was overwriting previous IRQWAKEN bits,
causing only the last bit set to take effect, resulting in lost
wakeups when the GPIO controller is in idle.
Replace direct writes to IRQWAKEN with MOD_REG_BIT calls to
perform a read-modify-write on the register.
Signed-off-by: Col
On Mon, Jun 6, 2011 at 10:20 PM, Roedel, Joerg wrote:
> Well, it certainly makes sense to have a single implementation for this.
> But I want to hide this complexity to the user of the IOMMU-API. The
> best choice is to put this into the layer between the IOMMU-API and the
> backend implementation
On Mon, Jun 06, 2011 at 02:57:08PM -0400, gr...@linuxhacker.ru wrote:
> From: Oleg Drokin
>
> CC: Mark Brown
> CC: Mike Rapoport
> CC: Nishant Kamat
> CC: Steve Sakoman
> CC: Felipe Balbi
> Signed-off-by: Oleg Drokin
Acked-by: Felipe Balbi
compile tested with omap2plus_defconfig.
--
ba
On Mon, Jun 06, 2011 at 02:57:07PM -0400, gr...@linuxhacker.ru wrote:
> From: Oleg Drokin
>
> to use REGULATOR_SUPPLY arrays.
>
> CC: Mark Brown
> CC: Mike Rapoport
> CC: Nishant Kamat
> CC: Steve Sakoman
> CC: Felipe Balbi
> CC: Santosh Shilimkar
> CC: peter.bar...@logicpd.com
> Signed-of
On Mon, Jun 06, 2011 at 12:36:13PM -0400, Ohad Ben-Cohen wrote:
> On Mon, Jun 6, 2011 at 6:35 PM, Roedel, Joerg wrote:
> > On Mon, Jun 06, 2011 at 11:15:30AM -0400, Ohad Ben-Cohen wrote:
> >
> >> This is insufficient; users need somehow to tell what page sizes are
> >> supported by the underlying
On Mon 06 Jun 2011 at 19:47:36 Rafael J. Wysocki wrote:
> Hi,
>
> On Sunday, June 05, 2011, Janusz Krzysztofik wrote:
> > In its current form, pm_runtime_clk_notify() iterates through sub-
> > strings of pm_clk_notifier_block.con_ids[0] rather than consecutive
> > pm_clk_notifier_block.con_ids[] e
On Mon, 6 Jun 2011, Rafael J. Wysocki wrote:
> > In a nutshell, what I'm after is for any pm_runtime_forbid() calls to be
> > cancelled during system PM, thus allowing pending runtime PM events to
> > occur during system PM.
> >
> > Basically, what I have is several drivers who don't really need
From: Oleg Drokin
to use REGULATOR_SUPPLY arrays.
CC: Mark Brown
CC: Mike Rapoport
CC: Nishant Kamat
CC: Steve Sakoman
CC: Felipe Balbi
CC: Santosh Shilimkar
CC: peter.bar...@logicpd.com
Signed-off-by: Oleg Drokin
---
arch/arm/mach-omap2/board-4430sdp.c | 13 ++
arch/arm/m
From: Oleg Drokin
CC: Mark Brown
CC: Mike Rapoport
CC: Nishant Kamat
CC: Steve Sakoman
CC: Felipe Balbi
Signed-off-by: Oleg Drokin
---
arch/arm/mach-omap2/board-cm-t35.c |4
arch/arm/mach-omap2/board-ldp.c |2 --
arch/arm/mach-omap2/board-omap3beagle.c
Hello!
This is yet another attempt at some regulator cleanups in mach-omap2 code:
Convert all users to REGULATOR_SUPPLY init style and drop the old-style
.dev assignment common ins hs_mmc init.
I made a test compile and all the individual board files changed compile
(I don't have the de
Hi,
Sorry for the delay. After returning from Japan I found my cable modem
basically dead, so I have no Internet access from home at the moment, which is
a bit inconvenient, so to speak.
On Thursday, June 02, 2011, Kevin Hilman wrote:
> Alan Stern writes:
>
> > On Wed, 1 Jun 2011, Kevin Hilman
On Mon, 6 Jun 2011, Felipe Balbi wrote:
> > But what is the "right thing"? Suppose you want to have conditional
> > support for dev_pm_ops whenever CONFIG_PM is enabled and you _also_
> > want to have conditional support for runtime PM whenever
> > CONFIG_PM_RUNTIME is enabled?
>
> we don't h
On Thursday, June 02, 2011, Kevin Hilman wrote:
> Hi Rafael,
Hi,
> Once again, I'm back to some problems with using runtime PM from system
> PM methods. On OMAP, many drivers don't need to do anything different
> for runtime PM compared to system PM, so the system PM methods can
> simply use run
On Mon, Jun 06, 2011 at 06:54:10PM +0200, Laurent Pinchart wrote:
> Of course not, but if the scatterlist is only touched by kernel code, it
> doesn't need to be contiguous in memory. It could be allocated with vmalloc().
Except vmalloc has a higher latency and a more restrictive API than
other a
Hi,
On Sunday, June 05, 2011, Janusz Krzysztofik wrote:
> In its current form, pm_runtime_clk_notify() iterates through sub-
> strings of pm_clk_notifier_block.con_ids[0] rather than consecutive
> pm_clk_notifier_block.con_ids[] elements. As a noticeable result, McBSP1
> port no longer worked fo
Hello!
On Jun 6, 2011, at 1:28 PM, Felipe Balbi wrote:
>> Ok, I get the idea. Do you think it would be best to convert every supply
>> definition to an array then just in case?
> I think that while you're doing this big conversion, why not ?
Well, ok then. I'll redo this patch.
Bye,
Oleg
--
On Mon, Jun 06, 2011 at 01:18:41PM -0400, Oleg Drokin wrote:
> Hello!
>
> On Jun 6, 2011, at 1:13 PM, Felipe Balbi wrote:
> > On Mon, Jun 06, 2011 at 11:45:29AM -0400, Oleg Drokin wrote:
> -static struct regulator_consumer_supply sdp4430_vaux_supply[] = {
> -{
> -
Hi,
On Mon, Jun 06, 2011 at 12:06:44PM -0400, Alan Stern wrote:
> > > > So, something like:
> > > >
> > > > #define __pm_ops__section(.pm.ops)
> > > >
> > > > static const struct dev_pm_ops my_driver_pm_ops __pm_ops = {
> > > > .suspend= my_driver_suspend,
> > > >
Hello!
On Jun 6, 2011, at 1:13 PM, Felipe Balbi wrote:
> On Mon, Jun 06, 2011 at 11:45:29AM -0400, Oleg Drokin wrote:
-static struct regulator_consumer_supply sdp4430_vaux_supply[] = {
- {
- .supply = "vmmc",
- .dev_name = "omap_hsmmc.1",
- },
-};
Hi,
On Mon, Jun 06, 2011 at 11:45:29AM -0400, Oleg Drokin wrote:
> >> -static struct regulator_consumer_supply sdp4430_vaux_supply[] = {
> >> - {
> >> - .supply = "vmmc",
> >> - .dev_name = "omap_hsmmc.1",
> >> - },
> >> -};
> >> +static struct regulator_consumer_supply sdp4430
On Fri, Jun 3, 2011 at 07:16, Santosh Shilimkar
wrote:
> Current OMAP2PLUS CPUfreq tagret() functions returns when all
> the CPU's are not online. This breaks CPUfreq when secondary CPUs
> are offlined on SMP system.
>
> The intention of that check was just avoid CPU frequency change
> during the
Hi Russell,
On Monday 06 June 2011 18:44:00 Russell King - ARM Linux wrote:
> On Mon, Jun 06, 2011 at 06:23:18PM +0200, Laurent Pinchart wrote:
> > Hi Russell,
> >
> > On Friday 03 June 2011 08:32:12 Russell King - ARM Linux wrote:
> > > SG chaining has _nothing_ to do with hardware. It's all to
On Mon, Jun 06, 2011 at 06:23:18PM +0200, Laurent Pinchart wrote:
> Hi Russell,
>
> On Friday 03 June 2011 08:32:12 Russell King - ARM Linux wrote:
> > SG chaining has _nothing_ to do with hardware. It's all to do with software
> > and hitting the SG table limit.
>
> What's the reason for limiti
On Mon, Jun 6, 2011 at 6:35 PM, Roedel, Joerg wrote:
> On Mon, Jun 06, 2011 at 11:15:30AM -0400, Ohad Ben-Cohen wrote:
>
>> This is insufficient; users need somehow to tell what page sizes are
>> supported by the underlying hardware (we can't assume host page-sizes,
>> and we want to use bigger pa
Hi Russell,
On Friday 03 June 2011 08:32:12 Russell King - ARM Linux wrote:
> On Fri, Jun 03, 2011 at 02:12:47AM +0200, Laurent Pinchart wrote:
> > On Wednesday 01 June 2011 16:03:06 Russell King - ARM Linux wrote:
> > > On Wed, Jun 01, 2011 at 03:50:50PM +0200, Laurent Pinchart wrote:
> > > > In
"Manuel, Lesly Arackal" writes:
> Hi Kevin,
>
> On Thu, Jun 2, 2011 at 11:59 PM, Kevin Hilman wrote:
>> Lesly A M writes:
>>
>>> Power bus message sequence for TWL4030 to enter sleep/wakeup/warm_reset.
>>>
>>> TWL4030 power scripts which can be used by different OMAP3 boards
>>> with the power
On Sun, 5 Jun 2011, Felipe Balbi wrote:
> Hi,
>
> On Sun, Jun 05, 2011 at 03:30:55PM -0400, Alan Stern wrote:
> > > > > good point. BTW, do we need this #ifdef CONFIG_PM stuff which has been
> > > > > popping on most drivers recently ? To me it looks like driver.pm field
> > > > > is always avail
Hello!
On Jun 6, 2011, at 5:21 AM, Felipe Balbi wrote:
>> -static struct regulator_consumer_supply sdp4430_vaux_supply[] = {
>> -{
>> -.supply = "vmmc",
>> -.dev_name = "omap_hsmmc.1",
>> -},
>> -};
>> +static struct regulator_consumer_supply sdp4430_vaux_supply =
>
On Mon, Jun 06, 2011 at 11:15:30AM -0400, Ohad Ben-Cohen wrote:
> This is insufficient; users need somehow to tell what page sizes are
> supported by the underlying hardware (we can't assume host page-sizes,
> and we want to use bigger pages whenever possible, to relax the TLB
> pressure).
/
What
On 6/6/2011 3:55 PM, Valkeinen, Tomi wrote:
On Mon, 2011-06-06 at 15:46 +0200, Cousson, Benoit wrote:
On 6/6/2011 3:21 PM, Valkeinen, Tomi wrote:
On Mon, 2011-06-06 at 15:15 +0200, Cousson, Benoit wrote:
On 6/6/2011 3:01 PM, Valkeinen, Tomi wrote:
On Mon, 2011-06-06 at 14:56 +0200, Cousson, B
On Mon, Jun 6, 2011 at 12:10 PM, Arnd Bergmann wrote:
>> I'd still prefer us to take small steps here, and not gate the omap
>> iommu cleanups with Marek's generic dma_map_ops work though. Let's go
>> forward and migrate omap's iommu to the generic iommu API, so new code
>> will be able to use it
Hi Joerg,
On Mon, Jun 6, 2011 at 1:09 PM, Roedel, Joerg wrote:
> The IOMMU-API already supports multiple page-sizes. See the
> 'order'-parameter of the map/unmap functions.
This is insufficient; users need somehow to tell what page sizes are
supported by the underlying hardware (we can't assume
Hi Kevin,
On Fri, Jun 3, 2011 at 6:01 AM, Kevin Hilman wrote:
> Lesly A M writes:
>
>> Patch series for TWL4030 power scripts for OMAP3 boards and
>> workaround for TWL erratum 27.
>>
>> Changes for implementing TWL4030 power scripts recommended by hardware team.
>> Introduced a new TWL4030 powe
Hi Kevin,
On Thu, Jun 2, 2011 at 11:59 PM, Kevin Hilman wrote:
> Lesly A M writes:
>
>> Power bus message sequence for TWL4030 to enter sleep/wakeup/warm_reset.
>>
>> TWL4030 power scripts which can be used by different OMAP3 boards
>> with the power companion chip (TWL4030 series).
>>
>> The tw
On Mon, Jun 06, 2011 at 07:09:26PM +0530, Trinabh Gupta wrote:
> diff --git a/arch/arm/mach-at91/cpuidle.c b/arch/arm/mach-at91/cpuidle.c
> index 1cfeac1..4696a0d 100644
> --- a/arch/arm/mach-at91/cpuidle.c
> +++ b/arch/arm/mach-at91/cpuidle.c
> @@ -41,10 +41,10 @@ static int at91_enter_idle(struct
On Mon, 2011-06-06 at 15:46 +0200, Cousson, Benoit wrote:
> On 6/6/2011 3:21 PM, Valkeinen, Tomi wrote:
> > On Mon, 2011-06-06 at 15:15 +0200, Cousson, Benoit wrote:
> >> On 6/6/2011 3:01 PM, Valkeinen, Tomi wrote:
> >>> On Mon, 2011-06-06 at 14:56 +0200, Cousson, Benoit wrote:
> >
> >>> In this lo
On Mon, Jun 06, 2011 at 07:12:19PM +0530, Keshava Munegowda wrote:
> From: Keshava Munegowda
>
> Oops are produced during initialization of ehci and ohci
> drivers. This is because the run time pm apis are used by
> the driver but the corresponding hwmod structures and
> initialization is not mer
On 6/6/2011 3:21 PM, Valkeinen, Tomi wrote:
On Mon, 2011-06-06 at 15:15 +0200, Cousson, Benoit wrote:
On 6/6/2011 3:01 PM, Valkeinen, Tomi wrote:
On Mon, 2011-06-06 at 14:56 +0200, Cousson, Benoit wrote:
In this long term solution, if the dss_fclk is the main_clk, how does
the framework hand
From: Keshava Munegowda
Oops are produced during initialization of ehci and ohci
drivers. This is because the run time pm apis are used by
the driver but the corresponding hwmod structures and
initialization is not merged. hence revering back the
commit id 7e6502d577106fb5b202bbaac64c5f1b065e6da
This is the first step towards global registration of cpuidle
states. The statistics used primarily by the governor are per-cpu
and have to be split from rest of the fields inside cpuidle_state,
which would be made global i.e. single copy. The driver_data field
is also per-cpu and moved.
Signed-of
The cpuidle_device->prepare() mechanism causes updates to the
cpuidle_state[].flags, setting and clearing CPUIDLE_FLAG_IGNORE
to tell the governor not to chose a state on a per-cpu basis at
run-time. State demotion is now handled by the driver and it returns
the actual state entered. Hence, this me
This patch makes the cpuidle_states structure global (single copy)
instead of per-cpu. The statistics needed on per-cpu basis
by the governor are kept per-cpu. This simplifies the cpuidle
subsystem as state registration is done by single cpu only.
Having single copy of cpuidle_states saves memory.
Cpuidle governor only suggests the state to enter using the
governor->select() interface, but allows the low level driver to
override the recommended state. The actual entered state
may be different because of software or hardware demotion. Software
demotion is done by the back-end cpuidle driver a
The following patch series implements global registration of cpuidle
states, and also has the necessary data structure changes to
accommodate the per-cpu writable members of the cpuidle_states
structure.
Previous version of the series (V4) is at https://lkml.org/lkml/2011/4/28/312
This series appl
On Mon, 2011-06-06 at 15:15 +0200, Cousson, Benoit wrote:
> On 6/6/2011 3:01 PM, Valkeinen, Tomi wrote:
> > On Mon, 2011-06-06 at 14:56 +0200, Cousson, Benoit wrote:
> > In this long term solution, if the dss_fclk is the main_clk, how does
> > the framework handle the situation when we want to swi
On 6/6/2011 3:01 PM, Valkeinen, Tomi wrote:
On Mon, 2011-06-06 at 14:56 +0200, Cousson, Benoit wrote:
Hi Tomi,
On 6/4/2011 10:01 AM, Valkeinen, Tomi wrote:
On Fri, 2011-06-03 at 15:53 -0700, Kevin Hilman wrote:
Tomi Valkeinen writes:
Hi Kevin,
On Fri, 2011-06-03 at 09:45 -0700, Kevin Hil
On Mon, 2011-06-06 at 14:56 +0200, Cousson, Benoit wrote:
> Hi Tomi,
>
> On 6/4/2011 10:01 AM, Valkeinen, Tomi wrote:
> > On Fri, 2011-06-03 at 15:53 -0700, Kevin Hilman wrote:
> >> Tomi Valkeinen writes:
> >>
> >>> Hi Kevin,
> >>>
> >>> On Fri, 2011-06-03 at 09:45 -0700, Kevin Hilman wrote:
> >>
Hi Tomi,
On 6/4/2011 10:01 AM, Valkeinen, Tomi wrote:
On Fri, 2011-06-03 at 15:53 -0700, Kevin Hilman wrote:
Tomi Valkeinen writes:
Hi Kevin,
On Fri, 2011-06-03 at 09:45 -0700, Kevin Hilman wrote:
Tomi Valkeinen writes:
Use PM runtime and HWMOD support to handle enabling and disabling o
On Sat, Apr 30, 2011 at 06:23:57PM +0200, Sebastian Reichel wrote:
> I'm currently trying to get a mainline based kernel running on my pandaboard.
> The problem is, that it's crashing very early during the init phase because of
> "undefined instruction" exceptions:
>
> [1.867980] udevd (56): u
* S, Venkatraman [110605 21:08]:
> Here is one attached which was known to be working (a few months ago,
> I haven't tested recently)
>
> On Mon, Jun 6, 2011 at 3:45 AM, Nicolau Werneck wrote:
> > Hello. I wanted to try the latest cbus patches in my N800. I
> > downloaded the branch from
> >
> >
On Mon, 2011-06-06 at 14:02 +0300, Felipe Balbi wrote:
> On Mon, Jun 06, 2011 at 01:44:18PM +0300, Felipe Balbi wrote:
> > looks like this is resulting from the missing hwmod conversion in
> > mainlnie. Check if reverting 7e6502d577106fb5b202bbaac64c5f1b065e6daa
> > helps.
>
> I verified off-list
Hi,
On Mon, Jun 06, 2011 at 01:44:18PM +0300, Felipe Balbi wrote:
> > [3.821197] ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver
> > [3.841735] Unhandled fault: imprecise external abort (0x1406) at
> > 0x
> > [3.863464] Internal error: : 1406 [#1] SMP
> > [3.876
hi,
On Mon, Jun 06, 2011 at 01:37:23PM +0300, Luciano Coelho wrote:
> I'm getting this kernel oops when trying to boot 3.0.0-rc2 on my
> pandaboard. Does anyone know what could be causing it?
>
> The full kernel log and my .config are attached.
>
> [3.821197] ehci_hcd: USB 2.0 'Enhanced' Ho
Hi Linus,
Please pull omap fixes from:
git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap-2.6.git fixes
This contains build and warning related fixes, mux and mmc init fixes, and
some board related fixes. Also included is one patch to remove duplicate
defines of NAND_BLOCK_SIZE.
Re
On Mon, Jun 6, 2011 at 9:46 AM, wrote:
> From: Oleg Drokin
>
> CC: Mark Brown
> CC: Mike Rapoport
> CC: Nishant Kamat
> CC: Steve Sakoman
> CC: Felipe Balbi
> Signed-off-by: Oleg Drokin
> ---
> arch/arm/mach-omap2/board-cm-t35.c | 2 --
> arch/arm/mach-omap2/board-ldp.c
Hi,
On Thu, Jun 02, 2011 at 06:27:37PM -0400, Ohad Ben-Cohen wrote:
> First stab at iommu consolidation:
>
> - Migrate OMAP's iommu driver to the generic iommu API. With this in hand,
> users can now start using the generic iommu layer instead of calling
> omap-specific iommu API.
>
> New
* Peter Ujfalusi [110603 16:34]:
> On Friday 03 June 2011 11:08:22 Tony Lindgren wrote:
> > Yeah if it gets big then a separate file is better. Also, if we have
> > a common init function for twl, then it's easy to add the board specific
> > device tree initialization to that too and just leave ou
On Sun, Jun 05, 2011 at 03:30:55PM -0400, Alan Stern wrote:
> On Sun, 5 Jun 2011, Felipe Balbi wrote:
> > that would mean changes to all linker scripts, though and a utility call
> > that only does anything ifndef CONFIG_PM to free the .pm.ops section.
> In my opinion this would make programming
Hi,
On Sun, Jun 05, 2011 at 04:05:55PM -0400, Oleg Drokin wrote:
> On Apr 29, 2011, at 5:21 AM, Felipe Balbi wrote:
> >> On Apr 28, 2011, at 2:14 AM, Mike Rapoport wrote:
> >> +static struct omap_musb_board_data musb_board_data = {
> >> + .interface_type = MUSB_INTERFACE_ULPI,
On Mon, Jun 06, 2011 at 02:46:02AM -0400, gr...@linuxhacker.ru wrote:
> From: Oleg Drokin
>
> CC: Mark Brown
> CC: Mike Rapoport
> CC: Nishant Kamat
> CC: Steve Sakoman
> CC: Felipe Balbi
> Signed-off-by: Oleg Drokin
Reviewed-by: Felipe Balbi
--
balbi
signature.asc
Description: Digita
Hi,
On Mon, Jun 06, 2011 at 02:46:01AM -0400, gr...@linuxhacker.ru wrote:
> From: Oleg Drokin
>
> CC: Mark Brown
> CC: Mike Rapoport
> CC: Nishant Kamat
> CC: Steve Sakoman
> CC: Felipe Balbi
> CC: Santosh Shilimkar
> Signed-off-by: Oleg Drokin
> ---
> arch/arm/mach-omap2/board-4430sdp.c
On Sunday 05 June 2011, Ohad Ben-Cohen wrote:
> > As far as I can tell, once we have that in
> > place, we you can migrate omap3isp from iovmm to dma-mapping and
> > remove iovmm.
>
> Sounds like a plan.
>
> I'd still prefer us to take small steps here, and not gate the omap
> iommu cleanups with
On Fri, 2011-06-03 at 09:32 -0700, Kevin Hilman wrote:
> Tomi Valkeinen writes:
>
> > get_context_loss_count functions return context loss count as u32, and
> > zero means an error. However, zero is also returned when context has
> > never been lost and could also be returned when the context los
> -Original Message-
> From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
> ow...@vger.kernel.org] On Behalf Of Shilimkar, Santosh
> Sent: Monday, June 06, 2011 12:32 PM
> To: Colin Cross
> Cc: linux-omap@vger.kernel.org; Tony Lindgren; Russell King; linux-
> ker...@vger.kernel.org;
On Mon, 2011-06-06 at 11:11 +0530, Archit Taneja wrote:
> Hi,
>
> On Friday 03 June 2011 03:30 PM, Valkeinen, Tomi wrote:
> > LANEx_ULPS_SIG2 bits are left on after entering ULPS. This doesn't cause
> > any problems currently, as DSI HW is reset when it is enabled. However,
> > if the reset is not
On 6/5/2011 12:33 AM, Colin Cross wrote:
Setting the IRQWAKEN bit was overwriting previous IRQWAKEN bits,
causing only the last bit set to take effect, resulting in lost
wakeups when the GPIO controller is in idle.
Replace direct writes to IRQWAKEN with writes to SETWKUENA and
CLEARWKUEN.
Signe
91 matches
Mail list logo
