On Mon, Apr 2, 2012 at 6:07 PM, Joe Woodward j...@terrafix.co.uk wrote:
-Original Message-
From: Raja, Govindraj govindraj.r...@ti.com
To: Joe Woodward j...@terrafix.co.uk, Kevin Hilman khil...@ti.com
Cc: Paul Walmsley p...@pwsan.com, linux-omap@vger.kernel.org, Felipe Balbi
Complete the separation of the twl6040 from the twl core since
it is a separate chip, not part of the twl6030 PMIC.
Make the needed Kconfig changes for the depending drivers at the same time to
avoid breaking the kernel build (vibra, ASoC components).
Signed-off-by: Peter Ujfalusi
From: Peter Meerwald p.meerw...@bct-electronic.com
code depending on FB_OMAP_BOOTLOADER_INIT has been removed long before
(e.g. Tomi Valkeinen, 03 Mar 2011: OMAP: DSS2: Remove FB_OMAP_BOOTLOADER_INIT
support), but the option still exists Kconfig and has no use
Signed-off-by: Peter Meerwald
Santosh,
On Wed, Jan 18, 2012 at 12:33:23PM +, Shilimkar, Santosh wrote:
On Wed, Jan 18, 2012 at 1:24 PM, Ming Lei ming@canonical.com wrote:
diff --git a/arch/arm/mach-omap2/clockdomains44xx_data.c
b/arch/arm/mach-omap2/clockdomains44xx_data.c
index 9299ac2..41d2260 100644
---
On Tue, Apr 3, 2012 at 2:55 PM, Will Deacon will.dea...@arm.com wrote:
Santosh,
On Wed, Jan 18, 2012 at 12:33:23PM +, Shilimkar, Santosh wrote:
On Wed, Jan 18, 2012 at 1:24 PM, Ming Lei ming@canonical.com wrote:
diff --git a/arch/arm/mach-omap2/clockdomains44xx_data.c
Hi Tony,
Could you please take this patch for the next merge? Thanks.
regards,
-roger
On 04/02/2012 11:59 AM, Roger Quadros wrote:
From: Chris Lalancette clalance...@gmail.com
Signed-off-by: Chris Lalancette clalance...@gmail.com
Signed-off-by: Roger Quadros rog...@ti.com
---
On Tue, Apr 3, 2012 at 3:17 PM, Will Deacon will.dea...@arm.com wrote:
On Tue, Apr 03, 2012 at 10:42:30AM +0100, Shilimkar, Santosh wrote:
On Tue, Apr 3, 2012 at 2:55 PM, Will Deacon will.dea...@arm.com wrote:
Did you ever get to the bottom of this? This change really is required in
order to
Hi Tony, Rafael,
Here is a gentle ping on this series.
Do you think this can go in the next rc?
Regards,
Jean
On Mon, Mar 19, 2012 at 5:12 PM, jean.pi...@newoldbits.com wrote:
From: Jean Pihet j-pi...@ti.com
AVS is a power management technique which controls the operating
voltage of a
The functions omap_i2c_unidle/idle are called from omap_i2c_runtime_resume
and omap_i2c_runtime_suspend which is compiled for CONFIG_PM_RUNTIME.
This patch removes the omap_i2c_unidle/idle functions and folds them
into the runtime callbacks.
This fixes the below warn when CONFIG_PM_RUNTIME is not
Use SET_RUNTIME_PM_OPS macro to set runtime functions.
Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com
---
drivers/i2c/busses/i2c-omap.c | 11 ---
1 files changed, 4 insertions(+), 7 deletions(-)
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index
The patch series does the following
- Warn fixes if CONFIG_PM_RUNTIME is not selected.
- I2C register restore only if context if the context is lost
- Bus busy recovery mechanism.
- the reset is not done in init.
v2 changes
-Adds a patch to use devm_* functions
-Also checks the return type of
From: Tasslehoff Kjappfot tasskj...@gmail.com
i2c_probe set the dev-errata flag, but omap_i2c_init cleared the flag again.
Move the errata handling to i2c_probe.
Signed-off-by: Tasslehoff Kjappfot tasskj...@gmail.com
Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com
---
If PM runtime get_sync fails return with the error
so that no further reads/writes goes through the interface.
This will avoid possible abort.
Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com
---
drivers/i2c/busses/i2c-omap.c | 13 ++---
1 files changed, 10 insertions(+), 3
Currently i2c register restore is done always.
Adding conditional restore.
The i2c register restore is done only if the context is lost.
Also remove the definition of SYSS_RESETDONE_MASK and use the
one in omap_hwmod.h.
Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com
---
The various devm_ functions allocate memory that is released when a driver
detaches. This patch uses devm_kzalloc, devm_request_mem_region and
devm_ioremap for data that is allocated in the probe function of a platform
device and is only freed in the remove function.
Signed-off-by: Shubhrajyoti D
On OMAP4 we were writing 1 to IRQENABLE_CLR which cleared only
the arbitration lost interrupt. The patch intends to fix the same by writing 0
to the IE register clearing all interrupts.
This is based on the work done by Vikram Pandita vikram.pand...@ti.com.
The changes from the original patch
In omap_i2c_remove we are accessing the I2C_CON register without
enabling the clocks. Fix the same by enabling the clocks and disabling
it.
This fixes the following crash.
[ 154.723022] [ cut here ]
[ 154.725677] WARNING: at
By definition, wait_for_completion_timeout() returns an unsigned value and
therefore, it is not necessary to check if the return value is less than zero
as this is not possible.
This is based on a patch from Jon Hunter jon-hun...@ti.com
Changes from his patch
- Declare a long as the
The reset in the driver at init is not needed anymore as the
following patch has removed the HWMOD_INIT_NO_RESET flag.
6d3c55f [OMAP: hwmod: fix the i2c-reset timeout during bootup]
This patch does the following
-removes the reset from the probe and implements a omap_i2c_reset
function to reset.
From: Vikram Pandita vikram.pand...@ti.com
In case a peripheral is driving SDA bus low (ie. a start condition), provide
a constant clock output using the test mode of the OMAP I2C controller to
try and clear the bus. Soft reset I2C controller after attempting the bus clear
to ensure that
No functional change. Makes the read ready processing a separate
function. This is to avoid extremely long level of indentation.
Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com
---
drivers/i2c/busses/i2c-omap.c | 86 +---
1 files changed, 45 insertions(+),
Currently the i2c driver calls the pm_runtime_enable and never
the disable. This may cause a warning when pm_runtime_enable
checks for the count match.Attempting to fix the same by calling
pm_runtime_disable in the error and the remove path.
Cc: Kevin Hilman khil...@ti.com
Cc: Rajendra Nayak
Restore of context is not done for OMAP4. This patch
adds the OMAP_I2C_FLAG_RESET_REGS_POSTIDLE in the OMAP4
hwmod data which activates the restore for OMAP4.
Currently the OMAP4 does not hit device off still the
driver may have support for it.
Cc: Benoit Cousson b-cous...@ti.com
Cc: Paul Wamsley
The omap_i2c_remove function may not be needed after
device exit so the memory could be freed.
Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com
---
drivers/i2c/busses/i2c-omap.c |5 ++---
1 files changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/i2c/busses/i2c-omap.c
Currently in probe
pm_runtime_put(dev-dev);
...
/* i2c device drivers may be active on return from add_adapter() */
adap-nr = pdev-id;
r = i2c_add_numbered_adapter(adap);
if (r) {
dev_err(dev-dev, failure adding adapter\n);
From: Jon Hunter jon-hun...@ti.com
The OMAP3530 is based upon the same silicon as the OMAP3430 and so the I2C
revision is the same for 3430 and 3530. However, the OMAP3630 device has the
same I2C revision as OMAP4. Correct the revision definition to reflect this.
This patch is based on work done
Currently in the 1.153 errata handling while waiting for transmitter
underflow if NACK is got the XUDF flag is also set.
Fix the same and set it after wait for the condition is over.
Cc: Alexander Shishkin virtu...@slind.org
Cc: Moiz Sonasath m-sonas...@ti.com
Signed-off-by: Shubhrajyoti D
This patch adds the support for Bosch D_CAN controller.
Bosch D_CAN controller is a full-CAN implementation compliant to
CAN protocol version 2.0 part A and B. Bosch D_CAN user manual
can be obtained from: http://www.semiconductors.bosch.de/media/
en/pdf/ipmodules_1/can/d_can_users_manual_111.pdf
On Tue, Apr 03, 2012 at 11:01:53AM +0100, Shilimkar, Santosh wrote:
On Tue, Apr 3, 2012 at 3:17 PM, Will Deacon will.dea...@arm.com wrote:
It seems that they're both needed to get reliable PMU operation. Without the
CLKDM_CAN_SWSUP fix, no interrupts are generated at all. Without the patch
Hi All,
Subject line of this patch should be
ARM: CAN: d_can: Add support for Bosch D_CAN controller
Regards
AnilKumar
--
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
On Tue, Apr 3, 2012 at 6:04 PM, Will Deacon will.dea...@arm.com wrote:
On Tue, Apr 03, 2012 at 11:01:53AM +0100, Shilimkar, Santosh wrote:
On Tue, Apr 3, 2012 at 3:17 PM, Will Deacon will.dea...@arm.com wrote:
It seems that they're both needed to get reliable PMU operation. Without
the
On 04/03/2012 02:44 PM, Wolfgang Grandegger wrote:
On 04/03/2012 02:32 PM, AnilKumar Ch wrote:
This patch adds the support for Bosch D_CAN controller.
Bosch D_CAN controller is a full-CAN implementation compliant to
CAN protocol version 2.0 part A and B. Bosch D_CAN user manual
can be
This patch series adds CM low-level api's, clockdomain data,
respective clockdomain operations and complete Clock Tree for
AM33XX family of devices.
The earlier versions of patches submitted were,
- Patch-RFC was complete set of patches adding separate
implementation for all PRM, CM,
AM33XX PRCM module consist of, various clockdomains, in all
total we have 18 clockdomains available, with following
controlling options,
- NO Sleep: sleep transition can not be initiated,
- SW Sleep: sw forced sleep transition,
- SW Wakeup: sw forced wakeup transition,
- HW Auto:
On 04/03/2012 02:32 PM, AnilKumar Ch wrote:
This patch adds the support for Bosch D_CAN controller.
Bosch D_CAN controller is a full-CAN implementation compliant to
CAN protocol version 2.0 part A and B. Bosch D_CAN user manual
can be obtained from: http://www.semiconductors.bosch.de/media/
Hi Wolfgang,
Thanks for reviewing the patch
On Tue, Apr 03, 2012 at 18:14:55, Wolfgang Grandegger wrote:
On 04/03/2012 02:32 PM, AnilKumar Ch wrote:
This patch adds the support for Bosch D_CAN controller.
Bosch D_CAN controller is a full-CAN implementation compliant to
CAN protocol
From: Govindraj.R govindraj.r...@ti.com
Currently the errata is populated based on cpu checks this can
be removed and replaced with module version check of uart ip block.
MVR reg is provided within the uart reg map use the same
to populate the errata and thus now errata population and handling
platform_device pdev can be NULL if CONFIG_MMC_OMAP_HS is not set.
Add check for NULL pointer
Fixes the following boot crash seen with omap4sdp and omap4panda
when MMC is disabled.
Unable to handle kernel NULL pointer dereference at virtual address 008c
pgd = c0004000
[008c]
On 04/03/2012 03:41 PM, AnilKumar, Chimata wrote:
Hi Wolfgang,
Thanks for reviewing the patch
On Tue, Apr 03, 2012 at 18:14:55, Wolfgang Grandegger wrote:
On 04/03/2012 02:32 PM, AnilKumar Ch wrote:
This patch adds the support for Bosch D_CAN controller.
Bosch D_CAN controller is a
On Tue, Apr 3, 2012 at 7:17 PM, Balaji T K balaj...@ti.com wrote:
platform_device pdev can be NULL if CONFIG_MMC_OMAP_HS is not set.
Add check for NULL pointer
Fixes the following boot crash seen with omap4sdp and omap4panda
when MMC is disabled.
Unable to handle kernel NULL pointer
Hi Will,
Will Deacon will.dea...@arm.com writes:
On Tue, Apr 03, 2012 at 11:01:53AM +0100, Shilimkar, Santosh wrote:
On Tue, Apr 3, 2012 at 3:17 PM, Will Deacon will.dea...@arm.com wrote:
It seems that they're both needed to get reliable PMU operation. Without
the
CLKDM_CAN_SWSUP fix,
On Tue, Apr 03, 2012 at 19:19:32, Marc Kleine-Budde wrote:
On 04/03/2012 03:41 PM, AnilKumar, Chimata wrote:
Hi Wolfgang,
Thanks for reviewing the patch
On Tue, Apr 03, 2012 at 18:14:55, Wolfgang Grandegger wrote:
On 04/03/2012 02:32 PM, AnilKumar Ch wrote:
This patch adds the
Dear mailing-list,
I am working with the 3.3 kernel on an OMAP4430 with a TWL6030.
I have many warning like the following:
twl6030_uv_to_vsel:OUT OF RANGE! non mapped vsel for 1375000 Vs max 1316660
I would like to clarify this and eventually remove this warning.
I have checked omap_twl.c
On Tuesday 03 April 2012 10:34 AM, Kevin Hilman wrote:
Hi Santosh,
Santosh Shilimkar santosh.shilim...@ti.com writes:
The series adds the coupled cpuidle support for OMAP4 based on the v2
series posted [1]. This makes OMAP4 to support SMP cpuidle and also
removes the hard dependency of
On 04/03/2012 04:29 PM, AnilKumar, Chimata wrote:
Please explain why this CAN controller cannot be handled by the existing
C_CAN driver, eventually with some extensions. The register layout seems
almost identical, at least.
Wolfgang.
These are the some of the pointers I can say, why I had
On Tue, Apr 03, 2012 at 00:05:38, Hilman, Kevin wrote:
Shilimkar, Santosh santosh.shilim...@ti.com writes:
[...]
I don't personally like to add features which hardly anybody use and
fundamentally broken with full kernel.
Let's keep sane defaults, but not make it unreasonable to tweak
On 03.04.2012 14:39, AnilKumar, Chimata wrote:
Hi All,
Subject line of this patch should be
ARM: CAN: d_can: Add support for Bosch D_CAN controller
No, the d_can IP core is generally not limited to ARM.
can: Add support for Bosch D_CAN controller
would be perfectly fine.
The
On Tue, Apr 03, 2012 at 21:03:40, Marc Kleine-Budde wrote:
On 04/03/2012 04:29 PM, AnilKumar, Chimata wrote:
Please explain why this CAN controller cannot be handled by the existing
C_CAN driver, eventually with some extensions. The register layout seems
almost identical, at least.
The functions omap_i2c_unidle/idle are called from omap_i2c_runtime_resume
and omap_i2c_runtime_suspend which is compiled for CONFIG_PM_RUNTIME.
This patch removes the omap_i2c_unidle/idle functions and folds them
into the runtime callbacks.
This fixes the below warn when CONFIG_PM_RUNTIME is not
The patch series does the following
- Warn fixes if CONFIG_PM_RUNTIME is not selected.
- I2C register restore only if context if the context is lost
- Bus busy recovery mechanism.
- the reset is not done in init.
v2 changes
-Adds a patch to use devm_* functions
-Also checks the return type of
From: Vikram Pandita vikram.pand...@ti.com
In case a peripheral is driving SDA bus low (ie. a start condition), provide
a constant clock output using the test mode of the OMAP I2C controller to
try and clear the bus. Soft reset I2C controller after attempting the bus clear
to ensure that
The reset in the driver at init is not needed anymore as the
following patch has removed the HWMOD_INIT_NO_RESET flag.
6d3c55f [OMAP: hwmod: fix the i2c-reset timeout during bootup]
This patch does the following
-removes the reset from the probe and implements a omap_i2c_reset
function to reset.
Currently i2c register restore is done always.
Adding conditional restore.
The i2c register restore is done only if the context is lost.
Also remove the definition of SYSS_RESETDONE_MASK and use the
one in omap_hwmod.h.
Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com
---
The omap_i2c_remove function may not be needed after
device exit so the memory could be freed.
Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com
---
drivers/i2c/busses/i2c-omap.c |5 ++---
1 files changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/i2c/busses/i2c-omap.c
By definition, wait_for_completion_timeout() returns an unsigned value and
therefore, it is not necessary to check if the return value is less than zero
as this is not possible.
This is based on a patch from Jon Hunter jon-hun...@ti.com
Changes from his patch
- Declare a long as the
Currently the i2c driver calls the pm_runtime_enable and never
the disable. This may cause a warning when pm_runtime_enable
checks for the count match.Attempting to fix the same by calling
pm_runtime_disable in the error and the remove path.
Cc: Kevin Hilman khil...@ti.com
Cc: Rajendra Nayak
The various devm_ functions allocate memory that is released when a driver
detaches. This patch uses devm_kzalloc, devm_request_mem_region and
devm_ioremap for data that is allocated in the probe function of a platform
device and is only freed in the remove function.
Signed-off-by: Shubhrajyoti D
If PM runtime get_sync fails return with the error
so that no further reads/writes goes through the interface.
This will avoid possible abort.
Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com
---
drivers/i2c/busses/i2c-omap.c | 13 ++---
1 files changed, 10 insertions(+), 3
Use SET_RUNTIME_PM_OPS macro to set runtime functions.
Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com
---
drivers/i2c/busses/i2c-omap.c | 11 ---
1 files changed, 4 insertions(+), 7 deletions(-)
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index
In omap_i2c_remove we are accessing the I2C_CON register without
enabling the clocks. Fix the same by enabling the clocks and disabling
it.
This fixes the following crash.
[ 154.723022] [ cut here ]
[ 154.725677] WARNING: at
No functional change. Makes the read ready processing a separate
function. This is to avoid extremely long level of indentation.
Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com
---
drivers/i2c/busses/i2c-omap.c | 86 +---
1 files changed, 45 insertions(+),
From: Tasslehoff Kjappfot tasskj...@gmail.com
i2c_probe set the dev-errata flag, but omap_i2c_init cleared the flag again.
Move the errata handling to i2c_probe.
Signed-off-by: Tasslehoff Kjappfot tasskj...@gmail.com
Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com
---
From: Jon Hunter jon-hun...@ti.com
The OMAP3530 is based upon the same silicon as the OMAP3430 and so the I2C
revision is the same for 3430 and 3530. However, the OMAP3630 device has the
same I2C revision as OMAP4. Correct the revision definition to reflect this.
This patch is based on work done
On OMAP4 we were writing 1 to IRQENABLE_CLR which cleared only
the arbitration lost interrupt. The patch intends to fix the same by writing 0
to the IE register clearing all interrupts.
This is based on the work done by Vikram Pandita vikram.pand...@ti.com.
The changes from the original patch
Currently in probe
pm_runtime_put(dev-dev);
...
/* i2c device drivers may be active on return from add_adapter() */
adap-nr = pdev-id;
r = i2c_add_numbered_adapter(adap);
if (r) {
dev_err(dev-dev, failure adding adapter\n);
Restore of context is not done for OMAP4. This patch
adds the OMAP_I2C_FLAG_RESET_REGS_POSTIDLE in the OMAP4
hwmod data which activates the restore for OMAP4.
Currently the OMAP4 does not hit device off still the
driver may have support for it.
Cc: Benoit Cousson b-cous...@ti.com
Cc: Paul Wamsley
Currently in the 1.153 errata handling while waiting for transmitter
underflow if NACK is got the XUDF flag is also set.
The flag is set after wait for the condition is over.
Cc: Alexander Shishkin virtu...@slind.org
Cc: Moiz Sonasath m-sonas...@ti.com
Signed-off-by: Shubhrajyoti D
On Tue, Apr 03, 2012 at 03:27:52PM +0100, Kevin Hilman wrote:
Hi Will,
Hi Kevin,
Will Deacon will.dea...@arm.com writes:
The problem is, trying to boot this on my pandaboard results in a hang (see
dmesg below). Even worse, the problem isn't easily bisectable since
rebuilding
a working
Hi Moiz,
Thanks for your review.
On Tuesday 03 April 2012 09:41 PM, Sonasath, Moiz wrote:
Shubhrajyoti,
On Tue, Apr 3, 2012 at 11:02 AM, Shubhrajyoti D shubhrajy...@ti.com wrote:
Currently in the 1.153 errata handling while waiting for transmitter
underflow if NACK is got the XUDF flag is
* Igor Grinberg grinb...@compulab.co.il [120330 08:26]:
On 03/28/12 19:03, Tony Lindgren wrote:
..care to see if you have OMAP_GPIO_IRQ entry for your board? If so, we're
still waiting for the cleanup-fixes branch to get merged that changes
things to use gpio_to_irq() instead.
Nope,
* Igor Grinberg grinb...@compulab.co.il [120327 23:37]:
On 03/27/12 20:32, Russ Dill wrote:
No objection.
10x Russ.
I've combined patches 5 - 12 into a single patch as they
pretty much do the same thing, and to cut down
the patch noise for fixes. Merging into fixes with the
updated patch
* R Sricharan r.sricha...@ti.com [120330 02:00]:
With CONFIG_OMAP4_ERRATA_I688 enabled, omap2+ build
was broken as below.
Thanks applying into fixes.
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
Hi Oliver,
Thanks for the comments,
On Tue, Apr 03, 2012 at 21:24:23, Oliver Hartkopp wrote:
On 03.04.2012 14:39, AnilKumar, Chimata wrote:
Hi All,
Subject line of this patch should be
ARM: CAN: d_can: Add support for Bosch D_CAN controller
No, the d_can IP core is generally not
* Felipe Balbi ba...@ti.com [120327 01:57]:
On Mon, Mar 26, 2012 at 04:51:10PM +0200, Igor Grinberg wrote:
Fix the below section mismatch warning and alike:
WARNING: vmlinux.o(.text+0x281d4): Section mismatch in reference from
the function setup_ehci_io_mux() to the function
* Govindraj.R govindraj.r...@ti.com [120321 03:06]:
From: Govindraj.R govindraj.r...@ti.com
The following commit:
(7496ba3 ARM: OMAP2+: UART: Add default mux for all uarts)
added default pads for all uarts. But not all boards tend to
use all uarts and most of unused uart pins are muxed for
Tony,
Please pull the following OMAP PM fixes for v3.4-rc1.
Thanks,
Kevin
The following changes since commit c16fa4f2ad19908a47c63d8fa436a1178438c7e7:
Linux 3.3 (2012-03-18 16:15:34 -0700)
are available in the git repository at:
* Kevin Hilman khil...@ti.com [120403 11:33]:
Tony,
Please pull the following OMAP PM fixes for v3.4-rc1.
Thanks pulling into fixes.
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
* Kevin Hilman khil...@ti.com [120312 16:30]:
Mark Brown broo...@opensource.wolfsonmicro.com writes:
On Mon, Mar 12, 2012 at 10:26:53AM -0700, Kevin Hilman wrote:
Mark Brown broo...@opensource.wolfsonmicro.com writes:
The branch itself is essentially stable but I'm not enthused about
Will Deacon will.dea...@arm.com writes:
[...]
Right. Can you confirm whether the PMU/CTI interrupts fire for you please?
Just run perf top and look at /proc/interrupts while it's running. You
should see a couple of arm-pmu entries in there and hopefully numbers 0.
Ah, I see now (I'm a perf
Hi
On Tue, 3 Apr 2012, Kevin Hilman wrote:
Indeed, like you, I have to change the EMU clock domain to SWSUP[1] in
order to see any interrupts and see anything in perf top. This isn't
really a mergeable workaround, so I'll look into this a little closer
with Santosh to see what we can do
On Mon, 12 Mar 2012, Santosh Shilimkar wrote:
Commit b1cbdb00d{OMAP: clockdomain: Wait for powerdomain to be ON
when using clockdomain force wakeup} was assuming that pwrdm_state_switch()
does wait for the powerdomain transition which is not the case.
Fix this API by adding the
On Mon, 12 Mar 2012, Santosh Shilimkar wrote:
With patch 'ARM: OMAP: powerdomain: Wait for powerdomain transition
in pwrdm_state_switch()', the pwrdm_clkdm_state_switch() API becomes
duplicate of pwrdm_state_switch().
Get rid off duplicate pwrdm_clkdm_state_switch() and update the
users of
On Tue, 3 Apr 2012, Will Deacon wrote:
I'll take JTAG for a whirl to see where we are. If anything looks wrong in
my dmesg, please shout (there are plenty of things in there that look like
they've gone awry).
Might be worth booting with initcall_debug on the kernel command line.
That will
On Wed, Apr 4, 2012 at 7:29 AM, Paul Walmsley p...@pwsan.com wrote:
Hi
On Tue, 3 Apr 2012, Kevin Hilman wrote:
Indeed, like you, I have to change the EMU clock domain to SWSUP[1] in
order to see any interrupts and see anything in perf top. This isn't
really a mergeable workaround, so I'll
-Original Message-
From: linux-can-ow...@vger.kernel.org [mailto:linux-can-
ow...@vger.kernel.org] On Behalf Of AnilKumar, Chimata
Sent: Tuesday, April 03, 2012 9:28 PM
To: Marc Kleine-Budde
Cc: Wolfgang Grandegger; socket...@hartkopp.net; m.kleine-
bu...@pengutronix.de;
Hi,
OMAP3EVM is not booting on l-o master, with default configuration, HEAD
@33fc21e Linux-omap rebuilt: Updated to v3.4-rc1, merged in most of pending
branches.
It was booting on l-o master two weeks old with same setup.
Any clues on resolving this issue ?
Regards
Afzal
Logs as follows,
86 matches
Mail list logo
