Hi,
On Tue, 2012-02-21 at 15:40 -0800, Tony Lindgren wrote:
Otherwise we cannot move most of plat/io.h to be a local
iomap.h for mach-omap2.
Cc: Tomi Valkeinen tomi.valkei...@ti.com
Cc: linux-fb...@vger.kernel.org
Signed-off-by: Tony Lindgren t...@atomide.com
---
On Tue, 2012-02-21 at 15:40 -0800, Tony Lindgren wrote:
Drivers should no longer use omap_read/write functions
but instead use ioremap + read/write functions.
As some USB legacy code is still shared between omap1 and
omap2420, let's limit the omap_read/write to plat/usb.h.
Also, let's
On Tue, 2012-02-21 at 19:36 +0530, Archit Taneja wrote:
These are some minor Display Controller fixes.
Tested on 4430sdp and 3430sdp on the tree:
git://gitorious.org/linux-omap-dss2/linux.git dev
Lajos Molnar (3):
OMAPDSS: DISPC: Fix OMAP4 supported color formats
OMAPDSS: DISPC:
Hi Kevin / Paul,
I have tested this on beagle board as well as on OMAP3630 based
propriatory phone using SDTI serial trace interface.
Also you can test it by just observing the
CM_EMU (48005100) clkstctrl register
48 = 0001
Across MPU OFF alone
[root@beagleboard /]# echo 0
arch/arm/mach-omap2/mailbox.c: In function 'omap2_mbox_probe':
arch/arm/mach-omap2/mailbox.c:354: error: 'omap2_mboxes' undeclared (first use
in this function)
arch/arm/mach-omap2/mailbox.c:354: error: (Each undeclared identifier is
reported only once
arch/arm/mach-omap2/mailbox.c:354: error:
Adapt omap-iommu-debug to the latest omap-iommu API changes, which
were introduced by commit fabdbca iommu/omap: eliminate the public
omap_find_iommu_device() method.
In a nutshell, iommu users are not expected to provide the omap_iommu
handle anymore - instead, iommus are attached using their
Fix this:
root@omap4430-panda:~# cat /debug/iommu/ducati/mem
[ 62.725708] Unable to handle kernel NULL pointer dereference at virtual addre
ss 001c
[ 62.725708] pgd = e624
[ 62.737091] [001c] *pgd=a7168831, *pte=, *ppte=
[ 62.743682] Internal error: Oops: 17
On Wed, Feb 22, 2012 at 10:52:52AM +0200, Ohad Ben-Cohen wrote:
@@ -274,7 +274,7 @@ static ssize_t debug_read_mem(struct file *file, char
__user *userbuf,
mutex_lock(iommu_debug_lock);
area = omap_find_iovm_area(dev, (u32)ppos);
- if (IS_ERR(area)) {
+ if
On Wed, Feb 22, 2012 at 10:56 AM, Russell King - ARM Linux
li...@arm.linux.org.uk wrote:
There's something else which needs fixing here - the return code. If
omap_find_iovm_area() returns an error code that needs propagating.
Otherwise it might as well just return NULL for all errors.
Seems
Fix this:
root@omap4430-panda:~# cat /debug/iommu/ducati/mem
[ 62.725708] Unable to handle kernel NULL pointer dereference at virtual addre
ss 001c
[ 62.725708] pgd = e624
[ 62.737091] [001c] *pgd=a7168831, *pte=, *ppte=
[ 62.743682] Internal error: Oops: 17
On Wed, Feb 22, 2012 at 11:10:38AM +0200, Ohad Ben-Cohen wrote:
On Wed, Feb 22, 2012 at 10:56 AM, Russell King - ARM Linux
li...@arm.linux.org.uk wrote:
There's something else which needs fixing here - the return code. If
omap_find_iovm_area() returns an error code that needs propagating.
On Wednesday 22 February 2012 12:19 PM, Tomi Valkeinen wrote:
On Wed, 2012-02-22 at 11:15 +0530, Archit Taneja wrote:
On Tuesday 21 February 2012 09:38 PM, Tomi Valkeinen wrote:
On Tue, 2012-02-21 at 19:36 +0530, Archit Taneja wrote:
From: Lajos Molnarla...@ti.com
If DSS is suspended during
+ Tony, Suman
On Wed, Feb 22, 2012 at 10:51 AM, Russell King - ARM Linux
li...@arm.linux.org.uk wrote:
arch/arm/mach-omap2/mailbox.c: In function 'omap2_mbox_probe':
arch/arm/mach-omap2/mailbox.c:354: error: 'omap2_mboxes' undeclared (first
use in this function)
On Tue, 2012-02-21 at 16:00 -0800, Kevin Hilman wrote:
Tero Kristo t-kri...@ti.com writes:
VDD1 and VDD2 are the core voltage regulators on OMAP3. VDD1 is used
to control MPU/IVA voltage, and VDD2 is used for CORE. These regulators
are needed by DVFS.
Voltage ranges for VDD1 and VDD2
On 01/27/2012 06:29 PM, Cousson, Benoit :
Add some basic helpers to retrieve a DMA controller device_node
and the DMA request line number.
For legacy reason another API will export the DMA request number
into a Linux resource of type IORESOURCE_DMA.
This API is usable only on system with an
Hi!
Current kernel: linux-3.0.17-r115c
Download speed: 745kB/sec
Previous kernel: 2.6.32-r78
Download speed: 1MB/sec
I noticed the regression in speed for ks8851 driver (Micrel
KSZ8851-SNL). I used this part with kernel 2.6.32 and the speed was
1MB/s. Then the driver code was changed and for
Hi!
I use Angstrom Linux with devkit8000 where TPS65930 is installed.
Current kernel version is linux-3.0.17-r115c.
I can't enable MIC working while it worked in 2.6.28-omap and
2.6.32-r78. I suspect the MIC Bias control does not function because I
can't see any voltage level at a microphone
Hi,
I'd like to get some feedback for the DSS DT work.
I have currently this in omap4.dtsi, under ocp. It's still a hack, for
example there's sdi for testing even though omap4 doesn't have SDI
output.
dss {
compatible = ti,omap4-dss;
ti,hwmods = dss_core;
On 02/15/2012 10:04 AM, Benoit Cousson wrote:
Adapt the GPIO driver to retrieve information from a DT file.
Allocate the irq_base dynamically and rename bank-virtual_irq_start
to bank-irq_base.
Change irq_base type to int instead of u16 to match irq_alloc_descs
output.
Add documentation
On 2/22/2012 3:23 PM, Rob Herring wrote:
On 02/15/2012 10:04 AM, Benoit Cousson wrote:
Adapt the GPIO driver to retrieve information from a DT file.
Allocate the irq_base dynamically and rename bank-virtual_irq_start
to bank-irq_base.
Change irq_base type to int instead of u16 to match
On Tue, Feb 14, 2012 at 11:08:36AM +, Russell King - ARM Linux wrote:
Two more points:
On Mon, Feb 13, 2012 at 11:43:42AM -0500, Matt Porter wrote:
This fixes smsc911x support on platforms using gpmc_smsc911x_init().
Commit c7e963f616f04d1f5da0e07bec4e0092f227 added the requirement
This fixes smsc911x support on platforms using gpmc_smsc911x_init().
Commit c7e963f616 (net/smsc911x: Add regulator support) added
the requirement that platforms provide vdd33a and vddvario supplies.
Signed-off-by: Matt Porter mpor...@ti.com
---
Changes for v2:
- temporary fix to avoid
On Thu, Feb 09, 2012 at 03:16:24PM -0500, Matt Porter wrote:
This series enables all current am35xx boards and the on-chip Ethernet
driver in omap2plus_defconfig. It will help users of these boards to
have a working defconfig out of the box.
Matt Porter (2):
omap: enable davinci_emac in
Hi Arnd,
Please pull:
git://git.kernel.org/pub/scm/linux/kernel/git/ohad/remoteproc.git rpmsg-for-3.4
To get the very basic rpmsg+remoteproc core functionality for 3.4.
This is basically the same stuff I sent for 3.3, with an additional
fix and cleanup which were reported by Grant (and of
On Wed, Feb 22, 2012 at 12:31 AM, Kevin Hilman khil...@ti.com wrote:
While both level- and edge-triggered GPIOs are capable of generating
interrupts, only edge-triggered GPIOs are capable of generating a
module-level wakeup to the PRCM (c.f. 34xx NDA TRM section 25.5.3.2.)
In order to ensure
On 02/22/2012 08:31 AM, Cousson, Benoit wrote:
On 2/22/2012 3:23 PM, Rob Herring wrote:
On 02/15/2012 10:04 AM, Benoit Cousson wrote:
Adapt the GPIO driver to retrieve information from a DT file.
Allocate the irq_base dynamically and rename bank-virtual_irq_start
to bank-irq_base.
Change
* Ohad Ben-Cohen o...@wizery.com [120222 01:30]:
+ Tony, Suman
On Wed, Feb 22, 2012 at 10:51 AM, Russell King - ARM Linux
li...@arm.linux.org.uk wrote:
arch/arm/mach-omap2/mailbox.c: In function 'omap2_mbox_probe':
arch/arm/mach-omap2/mailbox.c:354: error: 'omap2_mboxes' undeclared (first
* DebBarma, Tarun Kanti tarun.ka...@ti.com [120222 08:46]:
On Wed, Feb 22, 2012 at 12:31 AM, Kevin Hilman khil...@ti.com wrote:
While both level- and edge-triggered GPIOs are capable of generating
interrupts, only edge-triggered GPIOs are capable of generating a
module-level wakeup to the
* Tomi Valkeinen tomi.valkei...@ti.com [120124 01:30]:
OMAP SRAM can be used as video memory on OMAP1 and 2. However, there
usually is very little SRAM available, thus limiting its use, and no
board supported by the kernel currently uses it.
This patch removes the use of SRAM as video ram
* Tomi Valkeinen tomi.valkei...@ti.com [120124 01:30]:
OMAP SRAM can be used as video memory on OMAP1 and 2. However, there
usually is very little SRAM available, thus limiting its use, and no
board supported by the kernel currently uses it.
This patch removes the use of SRAM as video ram
* Tomi Valkeinen tomi.valkei...@ti.com [120124 01:30]:
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
arch/arm/mach-omap2/io.c |1 -
1 files changed, 0 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/io.c b/arch/arm/mach-omap2/io.c
index 3f174d5..7fee69c 100644
* Tomi Valkeinen tomi.valkei...@ti.com [120124 01:30]:
In an effort to clean up the old omapfb driver, this patch removes
HWA742 (the display chip used in N770) platform data. This can be done
as N770 is the only user of HWA742, and the platform data contains only
one field, te_connected,
* Tomi Valkeinen tomi.valkei...@ti.com [120124 01:30]:
omapfb_set_ctrl_platform_data() is no longer used, so it can be removed.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
Acked-by: Tony Lindgren t...@atomide.com
--
To unsubscribe from this list: send the line unsubscribe linux-omap
* Tomi Valkeinen tomi.valkei...@ti.com [120124 01:30]:
arch/arm/plat-omap/fb.c contains code to alloc omapfb buffers at early
boot time according to information given from the bootloader or board
file.
This code isn't currently used by any board, and is anyway something
that the newer
* Tomi Valkeinen tomi.valkei...@ti.com [120124 01:30]:
omapfb_set_platform_data() is no longer used, so remove it.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
Acked-by: Tony Lindgren t...@atomide.com
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of
* Tomi Valkeinen tomi.valkei...@ti.com [120124 01:30]:
LCD config for old omapfb driver is passed with OMAP_TAG_LCD from board
files or from the bootloader. In an effort to remove OMAP_TAG_LCD, this
patch adds omapfb_set_lcd_config() function that the board files can
call to set the LCD
* Tomi Valkeinen tomi.valkei...@ti.com [120124 01:30]:
These tags are no longer used and can be removed.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
Acked-by: Tony Lindgren t...@atomide.com
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message
* Tomi Valkeinen tomi.valkei...@ti.com [120124 01:30]:
Some OMAP1 board files define LCD platform_devices, but there are no
corresponding LCD drivers for those in the kernel. Thus remove these LCD
devices.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
Acked-by: Tony Lindgren
* Tomi Valkeinen tomi.valkei...@ti.com [120124 01:30]:
Now that the old omapfb driver is only omap1 display driver, there's no
need to check if the arch is omap1. This patch removes the few remaining
checks for the arch.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
Acked-by: Tony
Rob Herring wrote at Wednesday, February 22, 2012 10:23 AM:
On 02/22/2012 08:31 AM, Cousson, Benoit wrote:
On 2/22/2012 3:23 PM, Rob Herring wrote:
On 02/15/2012 10:04 AM, Benoit Cousson wrote:
Adapt the GPIO driver to retrieve information from a DT file.
Allocate the irq_base
Mohammed, Afzal af...@ti.com writes:
Hi Kevin,
On Wed, Feb 22, 2012 at 05:36:12, Hilman, Kevin wrote:
In this case, volt comes from the OPP table, and was requested using a
rounding call into the OPP table, so the resolution problem is handled
there. If 'volt' cannot be set by the
* Tomi Valkeinen tomi.valkei...@ti.com [120214 03:21]:
Hi Tony,
On Tue, 2012-01-24 at 12:00 +0200, Tomi Valkeinen wrote:
Now that all omap2+ boards have been changed to use the newer omapdss
driver,
this patch series removes omap2+ support from the old omapfb driver
* Tomi Valkeinen tomi.valkei...@ti.com [120221 23:42]:
On Tue, 2012-02-21 at 15:40 -0800, Tony Lindgren wrote:
Drivers should no longer use omap_read/write functions
but instead use ioremap + read/write functions.
As some USB legacy code is still shared between omap1 and
omap2420,
* Tomi Valkeinen tomi.valkei...@ti.com [120221 23:38]:
Hi,
On Tue, 2012-02-21 at 15:40 -0800, Tony Lindgren wrote:
Otherwise we cannot move most of plat/io.h to be a local
iomap.h for mach-omap2.
Cc: Tomi Valkeinen tomi.valkei...@ti.com
Cc: linux-fb...@vger.kernel.org
Tero Kristo t-kri...@ti.com writes:
On Tue, 2012-02-21 at 16:00 -0800, Kevin Hilman wrote:
Tero Kristo t-kri...@ti.com writes:
VDD1 and VDD2 are the core voltage regulators on OMAP3. VDD1 is used
to control MPU/IVA voltage, and VDD2 is used for CORE. These regulators
are needed by DVFS.
On Wed, Feb 22, 2012 at 11:58 AM, Tony Lindgren t...@atomide.com wrote:
* Ohad Ben-Cohen o...@wizery.com [120222 01:30]:
+ Tony, Suman
On Wed, Feb 22, 2012 at 10:51 AM, Russell King - ARM Linux
li...@arm.linux.org.uk wrote:
arch/arm/mach-omap2/mailbox.c: In function 'omap2_mbox_probe':
On Wed, Feb 22, 2012 at 7:58 PM, Tony Lindgren t...@atomide.com wrote:
2430 is like omap3 for the mailbox.
Gotcha, thanks.
This one below isn't pretty, but it should satisfy all build
permutations and still be correct hw-wise.
If it looks good to you I'll submit it properly.
diff --git
On Wed, Feb 22, 2012 at 09:55:56PM +0200, Ohad Ben-Cohen wrote:
On Wed, Feb 22, 2012 at 7:58 PM, Tony Lindgren t...@atomide.com wrote:
2430 is like omap3 for the mailbox.
Gotcha, thanks.
This one below isn't pretty, but it should satisfy all build
permutations and still be correct
On Wed, Feb 22, 2012 at 10:12 PM, Russell King - ARM Linux
li...@arm.linux.org.uk wrote:
+#ifdef CONFIG_ARCH_OMAP2
+struct omap_mbox *omap2_mboxes[] = {
+ mbox_dsp_info,
+#ifdef CONFIG_SOC_OMAP2420
+ mbox_iva_info,
+#endif
+ NULL
+};
#endif
Beautiful. Thanks!
--
To
Hi Tarun,
DebBarma, Tarun Kanti tarun.ka...@ti.com writes:
On Wed, Feb 22, 2012 at 12:31 AM, Kevin Hilman khil...@ti.com wrote:
While both level- and edge-triggered GPIOs are capable of generating
interrupts, only edge-triggered GPIOs are capable of generating a
module-level wakeup to the
Peter Ujfalusi peter.ujfal...@ti.com writes:
Hi,
I hoped that time will solve this, but so far no luck. I just can not
get the ethernet port (along with the USB host ports) working on my xM RevC.
What is the trick to get it working on 3.3-rc3?
There seams to be some configuration issue:
* Tony Lindgren t...@atomide.com [120222 10:18]:
* Tomi Valkeinen tomi.valkei...@ti.com [120214 03:21]:
Tony, do you have any feedback on this? I think the arch/arm changes are
quite clean as such, but are you ok with (possibly) breaking N770's
display? The other OMAP1 boards should, at
From 54c4785b8d274f8d282b4243945ae0b17edf4686 Mon Sep 17 00:00:00 2001
From: Tony Lindgren t...@atomide.com
Date: Wed, 22 Feb 2012 13:03:07 -0800
Subject: [PATCH] cbus: Fix lines for Nokia 770
This makes retu and tahvo work again on Nokia 770 so it
stays running.
Signed-off-by: Tony Lindgren
* Tony Lindgren t...@atomide.com [120222 10:34]:
* Tomi Valkeinen tomi.valkei...@ti.com [120221 23:38]:
Hi,
On Tue, 2012-02-21 at 15:40 -0800, Tony Lindgren wrote:
Otherwise we cannot move most of plat/io.h to be a local
iomap.h for mach-omap2.
Cc: Tomi Valkeinen
Tero Kristo t-kri...@ti.com writes:
On Thu, 2012-02-16 at 09:31 -0800, Kevin Hilman wrote:
Tero Kristo t-kri...@ti.com writes:
On Thu, 2012-02-16 at 21:15 +0530, Shilimkar, Santosh wrote:
On Thu, Feb 16, 2012 at 8:53 PM, Tero Kristo t-kri...@ti.com wrote:
On Thu, 2012-02-16 at 15:15
Hi Grant,
Any objections to this series? Can we get this queued and into linux-next?
I'll have an additional pull request for Benoit's GPIO DT stuff that
depends on this for v3.4 too after that series is finalized.
Thanks,
Kevin
On 02/16/2012 12:43 PM, Kevin Hilman wrote:
Hi Grant,
I've
* Tony Lindgren t...@atomide.com [120222 10:27]:
* Tomi Valkeinen tomi.valkei...@ti.com [120221 23:42]:
On Tue, 2012-02-21 at 15:40 -0800, Tony Lindgren wrote:
Drivers should no longer use omap_read/write functions
but instead use ioremap + read/write functions.
As some USB legacy
* Ohad Ben-Cohen o...@wizery.com [120222 11:51]:
On Wed, Feb 22, 2012 at 10:12 PM, Russell King - ARM Linux
li...@arm.linux.org.uk wrote:
+#ifdef CONFIG_ARCH_OMAP2
+struct omap_mbox *omap2_mboxes[] = {
+ mbox_dsp_info,
+#ifdef CONFIG_SOC_OMAP2420
+ mbox_iva_info,
+#endif
* Peter Ujfalusi peter.ujfal...@ti.com [120210 01:34]:
The board has two fixed voltage regulator. Correct the
device ID for the vbat, which used -1.
Create defines for the fixed regulator IDs so when adding new
regulators we know the next available ID to use for them.
Signed-off-by: Peter
* Peter Ujfalusi peter.ujfal...@ti.com [120210 01:34]:
V1V8 supply from twl6030 commonly used as VIO for the machine.
V2V1 is adviced to supply the twl6040, and also to feed the twl6030's
VCXIO_IN, and VDAC_IN inputs.
Create the common regulator configurations for these regulators:
Make the
* Peter Ujfalusi peter.ujfal...@ti.com [120210 01:34]:
These supplies going to be needed for the twl6040 driver.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
Acked-by: Tony Lindgren t...@atomide.com
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a
* Peter Ujfalusi peter.ujfal...@ti.com [120210 01:34]:
These supplies going to be needed for the twl6040 driver.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
Acked-by: Tony Lindgren t...@atomide.com
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a
* Peter Ujfalusi peter.ujfal...@ti.com [120217 00:56]:
The cpu_is_omap4430() macro always return with 0. Use the correct
cpu_is_omap443x() to check for Panda revision.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
Hi,
Since the depending patches are going via Liam's tree it
* Peter Ujfalusi peter.ujfal...@ti.com [120217 00:54]:
CCDN is the last common channel register in all OMAP4 versions. Use
cpu_is_omap44xx() instead of the cpu_is_omap4430() - which is anyway not
doing what it supposed to do.
This is a bit unclear.. Which is not doing what is supposed to do?
* Matt Porter mpor...@ti.com [120222 08:13]:
This fixes smsc911x support on platforms using gpmc_smsc911x_init().
Commit c7e963f616 (net/smsc911x: Add regulator support) added
the requirement that platforms provide vdd33a and vddvario supplies.
Signed-off-by: Matt Porter mpor...@ti.com
On Wed, Feb 22, 2012 at 02:41:05PM -0800, Kevin Hilman wrote:
Hi Grant,
Any objections to this series? Can we get this queued and into linux-next?
I'll have an additional pull request for Benoit's GPIO DT stuff that
depends on this for v3.4 too after that series is finalized.
The diffstat
On Tue, Feb 21, 2012 at 08:04, Tero Kristo t-kri...@ti.com wrote:
[...]
diff --git a/arch/arm/mach-omap2/voltage.h b/arch/arm/mach-omap2/voltage.h
index 949938d..940a0d6 100644
--- a/arch/arm/mach-omap2/voltage.h
+++ b/arch/arm/mach-omap2/voltage.h
[...]
@@ -171,6 +169,18 @@ struct
TWL6030 family of PMIC use a shadow interrupt status register
while kernel processes the current interrupt event.
However, any write(0 or 1) to register INT_STS_A, INT_STS_B or
INT_STS_C clears all 3 interrupt status registers.
Since clear of the interrupt is done on 32k clk, depending on I2C
bus
twl6030_irq_set_wake is not used anywhere else in the kernel
except as irq_chip.irq_set_wake. No reason for it to be exported.
Also fixes build warning:
drivers/mfd/twl6030-irq.c:230:5: warning: symbol 'twl6030_irq_set_wake' was not
declared. Should it be static?
Signed-off-by: Nishanth Menon
Hello Gowda,
A few questions...
On Wed, 22 Feb 2012, madhusudhan.go...@elektrobit.com wrote:
I have tested this on beagle board as well as on OMAP3630 based
propriatory phone using SDTI serial trace interface.
What driver are you using for SDTI? Does it use pm_runtime* or call
clk_enable()
Hi Kevin,
On Thu, Feb 23, 2012 at 00:12:06, Hilman, Kevin wrote:
And in my patch plus - minus was not used as regulator framework will
try to set voltage for the least voltage which sometimes corresponds
to exact OPP required value.
sometimes?
I was not clear in my previous statement,
WARNING: arch/arm/mach-omap2/built-in.o(.text+0x8b80):
Section mismatch in reference from the function omap4_hotplug_cpu() to
the function .cpuinit.text:omap_secondary_startup()
The function omap4_hotplug_cpu() references
the function __cpuinit omap_secondary_startup().
This is often because
Tony,
Below are couple of section mismatch warning fixes for v3.3-rc5
Santosh Shilimkar (2):
ARM: OMAP: fix section mismatch warning for omap4_hotplug_cpu()
ARM: OMAP: Fix section mismatch warning for platform_cpu_die()
arch/arm/mach-omap2/omap-hotplug.c|2 +-
WARNING: vmlinux.o(.text+0x226d0):
Section mismatch in reference from the function
platform_cpu_die() to the function .cpuinit.text:omap4_hotplug_cpu()
The function platform_cpu_die() references
the function __cpuinit omap4_hotplug_cpu().
This is often because platform_cpu_die lacks a __cpuinit
Hi Kevin,
On Thu, Feb 23, 2012 at 10:58:57, Mohammed, Afzal wrote:
Using your example above, what if the closest value was 1.259V?
Wouldn't you then need +/- range?
In that case, it will set to next step after 1.259V.
If +/- is used, it may happen that SoC will work for a particular
Hi,
This is an old issue, and I've mentioned earlier, but I think we should
finally do something about this. Or perhaps this can already be done,
but I don't know the solution.
The problem is that various DSS clocks have max frequencies that depend
on whether we are at OPP100 or OPP50 (e.g.
Hi Tony,
On 02/23/2012 01:07 AM, Tony Lindgren wrote:
* Peter Ujfalusi peter.ujfal...@ti.com [120217 00:54]:
CCDN is the last common channel register in all OMAP4 versions. Use
cpu_is_omap44xx() instead of the cpu_is_omap4430() - which is anyway not
doing what it supposed to do.
This is a
CCDN is the last common channel register in all OMAP4 versions. Use
cpu_is_omap44xx() instead of the cpu_is_omap4430().
cpu_is_omap4430() returns 0 unconditionally. This causes that the
dma_common_ch_end register variable is not configured correctly on OMAP4, not
even for OMAP4430.
Because of
Hello,
On Thu, Feb 23, 2012 at 12:28:30PM +0530, Santosh Shilimkar wrote:
WARNING: vmlinux.o(.text+0x226d0):
Section mismatch in reference from the function
platform_cpu_die() to the function .cpuinit.text:omap4_hotplug_cpu()
The function platform_cpu_die() references
the function __cpuinit
79 matches
Mail list logo
