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 __cpui
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 this,
Hi Tony,
On 02/23/2012 01:07 AM, Tony Lindgren wrote:
> * Peter Ujfalusi [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..
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. table
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 particu
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
ann
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 omap4_
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 +-
arch/arm/mach-omap
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 state
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(
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
-
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
On Tue, Feb 21, 2012 at 08:04, Tero Kristo 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 omap_voltdm_pmic {
>
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 dif
* Matt Porter [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
> ---
> Changes for v2
* Peter Ujfalusi [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?
DMA driver? Or one o
* Peter Ujfalusi [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
> ---
>
> Hi,
>
> Since the depending patches are going via Liam's tree it would be best if we
> can queue thi
* Peter Ujfalusi [120210 01:34]:
> These supplies going to be needed for the twl6040 driver.
>
> Signed-off-by: Peter Ujfalusi
Acked-by: Tony Lindgren
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo i
* Peter Ujfalusi [120210 01:34]:
> These supplies going to be needed for the twl6040 driver.
>
> Signed-off-by: Peter Ujfalusi
Acked-by: Tony Lindgren
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo i
* Peter Ujfalusi [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 V2V1 as supply_reg
* Peter Ujfalusi [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 Ujfalusi
Acked-
* Ohad Ben-Cohen [120222 11:51]:
> On Wed, Feb 22, 2012 at 10:12 PM, Russell King - ARM Linux
> wrote:
> > +#ifdef CONFIG_ARCH_OMAP2
> > +struct omap_mbox *omap2_mboxes[] = {
> > + &mbox_dsp_info,
> > +#ifdef CONFIG_SOC_OMAP2420
> > + &mbox_iva_info,
> > +#endif
> > + NULL
> > +
* Tony Lindgren [120222 10:27]:
> * Tomi Valkeinen [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 be
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 g
Tero Kristo writes:
> On Thu, 2012-02-16 at 09:31 -0800, Kevin Hilman wrote:
>> Tero Kristo writes:
>>
>> > On Thu, 2012-02-16 at 21:15 +0530, Shilimkar, Santosh wrote:
>> >> On Thu, Feb 16, 2012 at 8:53 PM, Tero Kristo wrote:
>> >> > On Thu, 2012-02-16 at 15:15 +0200, Tero Kristo wrote:
>> >>
* Tony Lindgren [120222 10:34]:
> * Tomi Valkeinen [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
> > > Cc: linux-fb...@vger.kern
>From 54c4785b8d274f8d282b4243945ae0b17edf4686 Mon Sep 17 00:00:00 2001
From: Tony Lindgren
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
---
I applied th
* Tony Lindgren [120222 10:18]:
> * Tomi Valkeinen [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 least in theory, work as well
Peter Ujfalusi 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:
>
> [1.437530
Hi Tarun,
"DebBarma, Tarun Kanti" writes:
> On Wed, Feb 22, 2012 at 12:31 AM, Kevin Hilman 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 se
On Wed, Feb 22, 2012 at 10:12 PM, Russell King - ARM Linux
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 unsubscribe fro
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 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.
>
> I
On Wed, Feb 22, 2012 at 7:58 PM, Tony Lindgren 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 a/arch/arm/mach-omap2/
On Wed, Feb 22, 2012 at 11:58 AM, Tony Lindgren wrote:
> * Ohad Ben-Cohen [120222 01:30]:
>> + Tony, Suman
>>
>> On Wed, Feb 22, 2012 at 10:51 AM, Russell King - ARM Linux
>> wrote:
>> > arch/arm/mach-omap2/mailbox.c: In function 'omap2_mbox_probe':
>> > arch/arm/mach-omap2/mailbox.c:354: error:
Tero Kristo writes:
> On Tue, 2012-02-21 at 16:00 -0800, Kevin Hilman wrote:
>> Tero Kristo 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.
>> >
>> > Voltag
* Tomi Valkeinen [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
> > Cc: linux-fb...@vger.kernel.org
> > Signed-off-by: Tony Lindgren
> > ---
>
* Tomi Valkeinen [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, let's limit the
* Tomi Valkeinen [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
> > (drivers/video/omap), and thu
"Mohammed, Afzal" 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 regulator,
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 i
* Tomi Valkeinen [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
Acked-by: Tony Lindgren
--
To unsubscribe from this lis
* Tomi Valkeinen [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
Acked-by: Tony Lindgren
--
To unsubscribe from this list: send the lin
* Tomi Valkeinen [120124 01:30]:
> These tags are no longer used and can be removed.
>
> Signed-off-by: Tomi Valkeinen
Acked-by: Tony Lindgren
--
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
* Tomi Valkeinen [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 config.
>
> This has th
* Tomi Valkeinen [120124 01:30]:
> omapfb_set_platform_data() is no longer used, so remove it.
>
> Signed-off-by: Tomi Valkeinen
Acked-by: Tony Lindgren
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo
* Tomi Valkeinen [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 vram.c could handle.
* Tomi Valkeinen [120124 01:30]:
> omapfb_set_ctrl_platform_data() is no longer used, so it can be removed.
>
> Signed-off-by: Tomi Valkeinen
Acked-by: Tony Lindgren
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
M
* Tomi Valkeinen [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, which we can just pres
* Tomi Valkeinen [120124 01:30]:
> Signed-off-by: Tomi Valkeinen
> ---
> 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
> --- a/arch/arm/mach-omap2/io.c
>
* Tomi Valkeinen [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 for the old omapfb
* Tomi Valkeinen [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 for the omapdss dri
* DebBarma, Tarun Kanti [120222 08:46]:
> On Wed, Feb 22, 2012 at 12:31 AM, Kevin Hilman 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 sec
* Ohad Ben-Cohen [120222 01:30]:
> + Tony, Suman
>
> On Wed, Feb 22, 2012 at 10:51 AM, Russell King - ARM Linux
> 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 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_
On Wed, Feb 22, 2012 at 12:31 AM, Kevin Hilman 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 that devic
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 cours
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
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
---
Changes for v2:
- temporary fix to avoid platform device i
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 requi
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 irq_al
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 docum
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";
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 jack
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 cu
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 wi
On Tue, 2012-02-21 at 16:00 -0800, Kevin Hilman wrote:
> Tero Kristo 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 are
+ Tony, Suman
On Wed, Feb 22, 2012 at 10:51 AM, Russell King - ARM Linux
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)
> arch/arm/mach-omap2/mailbox.c:354: error: (Each
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 Molnar
If DSS is suspended during a wait_for_vs
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
> 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 m
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 [#1
On Wed, Feb 22, 2012 at 10:56 AM, Russell King - ARM Linux
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 like it does just ret
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 (IS_E
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 u
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 [#1
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: for
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 >
/sys/kernel/d
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: D
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
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
> Cc: linux-fb...@vger.kernel.org
> Signed-off-by: Tony Lindgren
> ---
> arch/arm/mach-omap2/display.c |3 +++
> drivers
79 matches
Mail list logo
