--- On Tue, 12/7/10, Dave Martin wrote:
> From: Dave Martin
> Subject: [PATCH] ARM: Thumb-2: Make CONFIG_THUMB2_KERNEL depend on !CPU_V6...
> This makes sense, because Thumb-2
> code can't execute on anything
> prior to ARMv7.
WRONG ... but you may be overlooking the
fact that there are at le
This patch adds omap_reserve functionality to board-omap4panda.c.
Helps in the reserving boot time memory in SDRAM, used here for
framebuffer allocation.
This patch is in similar lines to commit id 71ee7dad9b6991, from
Russell king
Cc: Russell King
Cc: linux-arm-ker...@lists.infradead.org
Signed
This patch adds omap_reserve functionality to board-omap4panda.c.
Helps in the reserving boot time memory in SDRAM, used here for
framebuffer allocation.
This patch is in similar lines to commit id 71ee7dad9b6991, from
Russell king
Cc: Russell King
Cc: linux-...@lists.arm.linux.org.uk
Signed-off
Salut Benoît,
On Tue, 7 Dec 2010, Cousson, Benoit wrote:
> Salut Paul,
>
> On 12/7/2010 2:25 AM, Paul Walmsley wrote:
> > Split the existing cm44xx.h file into cm1_44xx.h and cm2_44xx.h files
> > so they match their underlying OMAP hardware modules. Add clockdomain
> > offset information.
> >
> -Original Message-
> From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
> ow...@vger.kernel.org] On Behalf Of Datta, Shubhrajyoti
> Sent: Monday, December 06, 2010 6:30 PM
> To: Kevin Hilman; Arce, Abraham
> Cc: linux-in...@vger.kernel.org; linux-omap@vger.kernel.org
> Subject:
On Tue, 7 Dec 2010, Cousson, Benoit wrote:
> On 12/7/2010 2:25 AM, Paul Walmsley wrote:
>
> [...]
>
> > + *
> > + * XXX This file needs to be updated to align on one of "OMAP4",
> > "OMAP44XX",
> > + * or "OMAP4430".
>
> Yep, I was thinking to change that as well. My first thought was OMAP4
On Tue, 7 Dec 2010, Kevin Hilman wrote:
> Paul Walmsley writes:
>
> > This patch series, intended for 2.6.38:
>
> [...]
>
> > Kevin, I'd appreciate review and acks, if appropriate, on the patches
> > that touch code that you maintain.
>
> Reviewed-by: Kevin Hilman
> Tested-by: Kevin Hilman
Reverse some of the effects of commit
84c0c39aec31a09571fc08a752a2f4da0fe9fcf2 ("ARM: OMAP4: PM: Make OMAP3
Clock-domain framework compatible for OMAP4"). On OMAP2/3, the
CM_CLKSTCTRL register is at a constant offset from the powerdomain's
CM instance.
Also, remove some of the direct CM register
Add PRCM partition, CM instance register address offset, and clockdomain
register address offset to each OMAP4 struct clockdomain record. Add OMAP4
clockdomain code to use this new data to access registers properly.
While here, clean up some nearby clockdomain code to allocate auto variables
in m
Split _omap2_clkdm_set_hwsup() into _disable_hwsup() and _enable_hwsup().
While here, also document that the autodeps are deprecated and that they
should be removed at the earliest opportunity.
Signed-off-by: Paul Walmsley
---
arch/arm/mach-omap2/clockdomain.c | 67 +++
Move the padconf save code from pm34xx.c to the System Control Module
code in mach-omap2/control.c. This is part of the general push to
move direct register access from middle-layer core code to low-level
core code, so the middle-layer code can be abstracted to work on
multiple platforms and clean
The OMAP powerdomain code and data is all OMAP2+-specific. This seems
unlikely to change any time soon. Move plat-omap/include/plat/powerdomain.h
to mach-omap2/powerdomain.h. The primary point of doing this is to remove
the temptation for unrelated upper-layer code to access powerdomain code
and
The OMAP clockdomain code and data is all OMAP2+-specific. This seems
unlikely to change any time soon. Move plat-omap/include/plat/clockdomain.h
to mach-omap2/clockdomain.h. The primary point of doing this is to remove
the temptation for unrelated upper-layer code to access clockdomain code
and
OMAP4 powerdomain control registers are split between the PRM hardware
module and the PRCM_MPU local PRCM. Add this PRCM partition
information to each OMAP4 powerdomain record, and convert the OMAP4
powerdomain function implementations to use the OMAP4 PRM instance
functions.
Also fixes a potenti
In OMAP4 CM instances, some registers (CM_CLKSTCTRL, CM_STATICDEP,
CM_DYNAMICDEP, and the module-specific registers underneath) are
organized by clockdomain. Add the clockdomain offset macros to the
appropriate PRCM module header files.
This data was almost completely autogenerated from the TI ha
Move the OMAP4 global software reset function to the OMAP4-specific
prm44xx.c file, where it belongs. Part of the long-term process of
moving all of the direct PRCM register writes into lower-layer code.
Also add OCP barriers on OMAP2/3/4 to reduce the chance that the MPU
will continue executing
In some ways, the OMAP4 PRCM register layout is quite different than
the OMAP2/3 PRCM register layout. For example, on OMAP2/3, from a
register layout point of view, all CM instances were located in the CM
subsystem, and all PRM instances were located in the PRM subsystem.
OMAP4 changes this. Now
This patch series, intended for 2.6.38:
- adds OMAP4-specific PRM and CM instance functions, which are capable
of writing to PRM/CM instances, no matter what PRCM partition they
appear in;
- renames the old OMAP2/3 PRM and CM functions to prefix them with
'omap2_';
- adds OMAP4 clockdomain
Please ignore this series of patches.
I sent the older version the patches by mistake. I will send new versions again.
Sorry for cluttering ..
Regards,
Hema
On Wed, Dec 8, 2010 at 5:39 AM, Hema HK wrote:
> This patch series has the support for TWL6030-usb
> transceiver driver and changes i
Dave,
> -Original Message-
> From: Santosh Shilimkar [mailto:santosh.shilim...@ti.com]
> Sent: Wednesday, December 08, 2010 11:27 AM
> To: Dave Martin
> Cc: linux-arm-ker...@lists.infradead.org; Tony Lindgren; linux-
> o...@vger.kernel.org; linaro-...@lists.linaro.org
> Subject: RE: [PATCH
> -Original Message-
> From: Dave Martin [mailto:dave.mar...@linaro.org]
> Sent: Tuesday, December 07, 2010 10:21 PM
> To: Santosh Shilimkar
> Cc: linux-arm-ker...@lists.infradead.org; Tony Lindgren; linux-
> o...@vger.kernel.org; linaro-...@lists.linaro.org
> Subject: Re: [PATCH v2 2/3] AR
musb device registration during board initialization of OMAP4430SDP
and OMAP4430 PANDA.Enable the musb OTG mode.
Signed-off-by: Hema HK
Cc: Felipe Balbi
Cc: Tony Lindgren
---
arch/arm/mach-omap2/board-4430sdp.c|6 ++
arch/arm/mach-omap2/board-omap4panda.c |2 +-
2 files changed
OMAP4430 supports UTMI and ULPI types of transceiver interface.
In UTMI mode: The PHY is embedded within OMAP4430. The transceiver functionality
is split between the twl6030 PMIC chip and OMAP4430. The VBUS, ID pin
sensing and OTG SRP generation part is integrated in TWL6030 and UTMI PHY
function
Selecting the twl6030-usb for OMAP4430SDP and OMAP4 PANDA board and
adding OMAP4 internal phy code for compilation
Signed-off-by: Hema HK
Cc: Felipe Balbi
Cc: Tony Lindgren
---
arch/arm/mach-omap2/Makefile |1 +
drivers/usb/musb/Kconfig |1 +
2 files changed, 2 insertions(+)
Index
Registering the twl6030-usb transceiver device as a child to twl6030 core.
Removed the NOP transceiver init call from board file.
Populated twl4030_usb_data platform data structure with the function
pointers for OMAP4430 internal PHY operation to be used twl630-usb driver.
Signed-off-by: Hema HK
Added the TWL6030-usb transceiver option in the Kconfig
Signed-off-by: Hema HK
Cc: Felipe Balbi
Cc: David Brownell
---
drivers/usb/otg/Kconfig | 12
1 file changed, 12 insertions(+)
Index: linux-2.6/drivers/usb/otg/Kconfig
===
Adding the twl6030-usb transceiver support for OMAP4 musb driver.
OMAP4 supports 2 types of transceiver interface.
1. UTMI: The PHY is embedded within OMAP4. The transceiver functionality
is split between the twl6030 PMIC chip and OMAP4430. The VBUS, ID pin
sensing and OTG SRP generation part is
This patch series has the support for TWL6030-usb
transceiver driver and changes in the musb driver to make it functional
with OMAP4430.
OMAP4 musb support UTMI and ULPI transceiver interfaces.
In UTMI mode, the transceiver functionality is split between
the TWL6030 PMIC chip and OMAP4 embedded P
With TWL6030-usb, VBUS SESS_VLD and SESS_END events are not generated
as expected. When these interrupts are enabled, charger VBUS detection
interrupt does not get generated. So USBOTG has to be dependent on charger
VBUS interrupts.
So added one bit for USBOTG and changed the handler to call the
U
Tony,
On Wed, Dec 8, 2010 at 04:53, Tony Lindgren wrote:
> * Tony Lindgren [101204 13:16]:
>> * Varadarajan, Charulatha [101202 06:08]:
>> > On Thu, Dec 2, 2010 at 15:28, Kevin Hilman
>> > wrote:
>> >
>> > >
>> > > Tony, you can also add
>> > >
>> > > Acked-by: Kevin Hilman
>>
>> OK, updated
* Tony Lindgren [101207 17:32]:
> * Tony Lindgren [101204 13:27]:
> > These should be now long gone and break multi-omap support for omap1
> > as the cpu_class_is_omap1() won't work until the SOC is detected.
> >
> > So just disable and warn for omap2+ in case somebody still attampts
> > to use
On Tue, 7 Dec 2010, Paul Walmsley wrote:
> I do have a LDP3430 here though. It doesn't boot past:
>
> [0.00] Linux version 2.6.37-rc5 (p...@twilight) (gcc version 4.3.2
> (Sourcery G++ Lite 2008q3-72) ) #68 SMP Tue Dec 7 17:42:20
> [0.00] CPU: ARMv7 Processor [411fc083] revision
Fix the following section mismatch warning when building omap2plus_defconfig:
WARNING: vmlinux.o(.data+0x47d7c): Section mismatch in reference from the
variable twl_driver to the function .init.text:twl_probe()
Signed-off-by: Bryan Wu
Signed-off-by: Paul Walmsley
---
drivers/mfd/twl-core.c |
This patch will kill following section mismatch warnings:
WARNING: vmlinux.o(.text+0x24a00): Section mismatch in reference from the
function zoom_twl_gpio_setup() to the (unknown reference) .init.data:(unknown)
The function zoom_twl_gpio_setup() references
the (unknown reference) __initdata (unkn
Hema,
On Tue, Dec 7, 2010 at 6:11 PM, Hema HK wrote:
> Adding the twl6030-usb transceiver support for OMAP4 musb driver.
>
> OMAP4 supports 2 types of transceiver interface.
> +}
> +
> +int omap4430_phy_set_clk(struct device *dev, int on)
> +{
> + static int state;
probably good to initia
* Felipe Contreras [101207 04:28]:
> On Sat, Dec 4, 2010 at 11:36 PM, Tony Lindgren wrote:
> > The omap1_defconfig this should be eventually usable for booting
> > all omap1 machines. Generated based on:
> >
> > $ grep ARCH_OMAP1=y arch/arm/configs/* | cut -d: -f1 | xargs cat | \
> > sort | u
This way we can use the generic omap SoC detection code instead.
Signed-off-by: Tony Lindgren
diff --git a/arch/arm/mach-omap2/include/mach/entry-macro.S
b/arch/arm/mach-omap2/include/mach/entry-macro.S
index 06e64e1..6032941 100644
--- a/arch/arm/mach-omap2/include/mach/entry-macro.S
+++ b/arc
* Tony Lindgren [101204 19:00]:
> * Nicolas Pitre [101204 18:26]:
> > On Sat, 4 Dec 2010, Tony Lindgren wrote:
> >
> > My only problem with your approach is the global addition of
> > asm_irq_base and asm_irq_flags in generic code which might not be useful
> > and/or appropriate for all target
This saves some cycles for multiple interrupts case.
Signed-off-by: Tony Lindgren
diff --git a/arch/arm/mach-omap1/include/mach/entry-macro.S
b/arch/arm/mach-omap1/include/mach/entry-macro.S
index c9be6d4..584bf7b 100644
--- a/arch/arm/mach-omap1/include/mach/entry-macro.S
+++ b/arch/arm/mach-o
Initialize asm_irq_flags in omap_init_irq and use it in
get_irqnr_and_base to detect between omap7xx and omap15xx/16xx.
Note that both INT_1510_IH2_IRQ and INT_1510_IH2_IRQ are defined
as 0, so use INT_1510_IH2_IRQ for both of them.
Signed-off-by: Tony Lindgren
diff --git a/arch/arm/mach-omap1/
* Tony Lindgren [101204 13:27]:
> These should be now long gone and break multi-omap support for omap1
> as the cpu_class_is_omap1() won't work until the SOC is detected.
>
> So just disable and warn for omap2+ in case somebody still attampts
> to use these.
Heh this was totally not working and
On Wed, Dec 8, 2010 at 12:12 AM, Paul Walmsley wrote:
> Hello Samuel,
>
> On Tue, 7 Dec 2010, Samuel Ortiz wrote:
>
>> On Mon, Dec 06, 2010 at 06:40:38PM -0700, Paul Walmsley wrote:
>> >
>> > That's fine with me. Samuel et al, Bryan's already done a patch
>> > for this stuff:
>> >
>> > https://pa
Kernel was failing to boot on omap1611 based OSK boards due to
mis-configured SRAM size. Existing code was using a hard-coded value
for 250k, which was then rounded down by PAGE_SIZE. Increasing this to
256k allows kernel to boot on omap1611 SoCs.
Problem reported by and initial fix suggested by
Hi Jean,
Jean Pihet writes:
> Some bad interaction between the idle and the suspend paths has been
> noticed: the idle code is called during the suspend enter and exit
> sequences. This could cause corruption or lock-up of resources.
>
> The solution is to move the call to disable_hlt at the ver
* Tony Lindgren [101207 15:13]:
>
> Note that this will cause omap-keypad.c driver to not work on 7xx.
> However, the right fix there is to move over to gpio-keys instead as
> suggested by Cory Maccarrone and
> Janusz Krzysztofik .
Updated that to say matrix-keypad instead of gpio-keys as point
* Varadarajan, Charulatha [101125 04:39]:
> Implement OMAP GPIO module in platform device model. OMAP2+ specific GPIO
> module uses hwmod FW.
I'll add the following patch underneath this series as otherwise some
gpio_request calls will fail after this series.
Regards,
Tony
From: Tony Lindgren
On Tue, 7 Dec 2010, Russell King - ARM Linux wrote:
> So LDP will remain unusable until after the 2.6.38 merge window?
I don't think that Tony or I realized that LDP3430 was broken until your
E-mail. Usually I use a BeagleBoard 35xx for OMAP3430 testing, and I
think Tony uses an Overo. The Be
Paul Walmsley writes:
> This patch series, intended for 2.6.38:
[...]
> Kevin, I'd appreciate review and acks, if appropriate, on the patches
> that touch code that you maintain.
Reviewed-by: Kevin Hilman
Tested-by: Kevin Hilman
I did some PM testing of this series on 34xx/n900 and 35xx/b
On Tuesday 07 December 2010 23:29:59 Luca Ceresoli wrote:
> Luca Ceresoli wrote:
> > While I thank you for you proposed solution, I see it does not work here.
> > In fact I commented the #define CONFIG_MTD_NAND_OMAP_HWECC and left
> > MTD_NAND_OMAP_PREFETCH disabled as it previously was, and got co
On Sun, 5 Dec 2010 12:06:03 +0200
Ohad Ben-Cohen wrote:
> Introduce BUG_ON_MAPPABLE_NULL in order to eliminate redundant BUG_ON
> code, checking for NULL addresses, on architectures where the zero
> address can never be mapped.
>
> Originally proposed by Russell King
>
> Signed-off-by: Ohad B
commit 0d8e2d0dad98a693bad88aea6876ac8b94ad95c6 (OMAP2+: PM/serial:
hold console semaphore while OMAP UARTs are disabled) added use of the
console semaphore to protect UARTs from being accessed after disabled
during idle, but this causes problems in suspend.
During suspend, the console semaphore i
Hi,
> Looks like 0xfa09c014 is the MMC SYSSTATUS register... maybe there's
> something wrong with the clock control.
Just sent a patch for this one, it's relatively minor.
After applying it and the 'brutal context save/restore test' patch, HSMMC
off-mode indeed seems to work much better.
Are
In the OMAP HSMMC driver, the code path entered via mmc_host_enable() can
include register accesses to the HSMMC IP block. For this to work, both
the device interface clock and functional clock need to be enabled before
mmc_host_enable() is called. However, omap_hsmmc_probe() calls
mmc_host_
* Tony Lindgren [101204 13:16]:
> * Varadarajan, Charulatha [101202 06:08]:
> > On Thu, Dec 2, 2010 at 15:28, Kevin Hilman
> > wrote:
> >
> > >
> > > Tony, you can also add
> > >
> > > Acked-by: Kevin Hilman
>
> OK, updated. Also made one more GPIO patch to allow us to deal
> with the 7xx vs
Hi,
On Tue, 7 Dec 2010, Chikkature Rajashekar, Madhusudhan wrote:
> On Tue, Dec 7, 2010 at 1:51 PM, Adrian Hunter wrote:
> >
> > It is at least because omap_pm_get_dev_context_loss_count() is not
> > implemented. Tero Kristo was looking at that recently.
> >
>
> Yes. I agree that is the proble
Hi,
Two comments:
On Tue, 7 Dec 2010, Kevin Hilman wrote:
> commit 0d8e2d0dad98a693bad88aea6876ac8b94ad95c6 (OMAP2+: PM/serial:
> hold console semaphore while OMAP UARTs are disabled) added use of the
> console semaphore to protect UARTs from being accessed after disabled
> during idle, but this
Marek Belisko writes:
> Fix following compilation warning:
> arch/arm/mach-omap1/pm_bus.c: In function 'omap1_pm_runtime_resume':
> arch/arm/mach-omap1/pm_bus.c:51: warning: unused variable 'ret'
>
> Signed-off-by: Marek Belisko
Acked-by: Kevin Hilman
> ---
> arch/arm/mach-omap1/pm_bus.c |
Benoit Cousson writes:
> Hi All,
>
> In order to enforce a little bit of consistency in the omap devices name,
> the convention for omap devices name will be now omap_XXX. All the drivers
> adapted to hwmod will be named like that during the on-going adaptations.
>
> The I2C and UART drivers are
* Varadarajan, Charulatha [101206 22:58]:
> On Tue, Dec 7, 2010 at 11:05, Varadarajan, Charulatha wrote:
> >
> > On Tue, Dec 7, 2010 at 10:49, Cory Maccarrone
> > wrote:
> >>
> >> omap_gpio omap_gpio.5: Could not get gpio dbck
> >> omap_gpio omap_gpio.6: Could not get gpio dbck
> >>
> >>
Paul Walmsley writes:
> On Mon, 22 Nov 2010, Kevin Hilman wrote:
>
>> Paul Walmsley writes:
>>
>> > On Tue, 16 Nov 2010, Paul Walmsley wrote:
>> >
>> >> This patch series contains upgrades for the OMAP2+ hwmod core
>> >> code, intended for 2.6.38. Most of these patches were developed
>> >> in
Paul Walmsley writes:
> Hi Kevin
>
> On Thu, 2 Dec 2010, Kevin Hilman wrote:
>
>> I guess this hasn't been seen before since we haven't tested the sysfs
>> wakeup interface for the omap-serial driver. For on-chip OMAP UARTs,
>> using the sysfs interface isn't needed as the serial core is already
On Tue, 7 Dec 2010, Kevin Hilman wrote:
> commit 0d8e2d0dad98a693bad88aea6876ac8b94ad95c6 (OMAP2+: PM/serial:
> hold console semaphore while OMAP UARTs are disabled) added use of the
> console semaphore to protect UARTs from being accessed after disabled
> during idle, but this causes problems in
On Tue, Dec 7, 2010 at 9:50 PM, Kevin Hilman
wrote:
> commit 0d8e2d0dad98a693bad88aea6876ac8b94ad95c6 (OMAP2+: PM/serial:
> hold console semaphore while OMAP UARTs are disabled) added use of the
> console semaphore to protect UARTs from being accessed after disabled
> during idle, but this causes
Sourav Poddar writes:
> Fix the following build error by including linux/err.h
> arch/arm/plat-omap/counter_32k.c: In function 'omap_init_clocksource_32k':
> arch/arm/plat-omap/counter_32k.c:167: error: implicit declaration of
> function 'IS_ERR'
>
> The abov
Hi,
What should I do to change the output frequency of mmc2_clk signal to
48Mhz for the OMAP35xx processor?
Right now it is giving an output of 96MHz and the signal output looks more like
a sine wave than a square wave clock output signal.
Elvis Dowson
--
To unsubscribe from this list
Tony Lindgren writes:
> * Kevin Hilman [101124 16:32]:
>> Paul Walmsley writes:
>
>
>
>> Acked-by: Kevin Hilman
>>
>> Very nice. I've been exploring various solutions to this problem as
>> well, but this one is much cleaner. Also, I hadn't discovered the 'try'
>> version of the console sem
On Tue, Dec 7, 2010 at 1:51 PM, Adrian Hunter wrote:
> On 07/12/10 20:21, ext Paul Walmsley wrote:
>>
>> Madhusudhan,
>>
>> On my OMAP35xx BeagleBoard here, HSMMC is non-functional after returning
>> from dynamic off-mode. The MMC LED turns on and stays on, and the process
>> hangs, although the
commit 0d8e2d0dad98a693bad88aea6876ac8b94ad95c6 (OMAP2+: PM/serial:
hold console semaphore while OMAP UARTs are disabled) added use of the
console semaphore to protect UARTs from being accessed after disabled
during idle, but this causes problems in suspend.
During suspend, the console semaphore i
On 12/7/2010 2:25 AM, Paul Walmsley wrote:
[...]
+ *
+ * XXX This file needs to be updated to align on one of "OMAP4", "OMAP44XX",
+ * or "OMAP4430".
Yep, I was thinking to change that as well. My first thought was OMAP4
to get a shorter name, but when we will introduce OMAP4440, we migh
On Fri, Nov 05, 2010 at 02:29:02PM -0700, Tony Lindgren wrote:
> Hi Greg,
>
> Considering below..
>
> * Peter Ujfalusi [101021 02:56]:
> > Sorry, I did missed this mail...
> >
> > On Saturday 09 October 2010 01:17:46 ext Tony Lindgren wrote:
> >
> > > Guys, as we're so late into getting 2.6.36
On 07/12/10 20:21, ext Paul Walmsley wrote:
Madhusudhan,
On my OMAP35xx BeagleBoard here, HSMMC is non-functional after returning
from dynamic off-mode. The MMC LED turns on and stays on, and the process
hangs, although the rest of the system still seems to run. Looks like
you're listed as th
On Tue, Dec 07, 2010 at 04:50:50PM +, Dave Martin wrote:
> I'll follow up shortly with a patch to the generic ARM Kconfig to make
> this explicit, so that ARCH_OMAP2 and THUMB2_KERNEL can't accidentally
> be configured together.
That's a rubbish dependency. You may have an ARCH_OMAP2 platform
On Tue, 7 Dec 2010, Dave Martin wrote:
> On Tue, Dec 7, 2010 at 2:53 PM, Dave Martin wrote:
> [...]
> > Note that converting to C doesn't mean that code which attempts to
> > copy function bodies will work: you still need to handle the fact that
> > if f() is a C function symbol, then the value o
On Tue, Dec 07, 2010 at 07:11:39PM +0100, Hans Verkuil wrote:
> Ah, now I understand what you mean. Would 'activated' be better than 'active'?
Better, yes, though it still sounds a bit like something should be
actively (IYSWIM) happening. In the absence of better ideas I could go
with this.
>
Hello Madhusudhan,
On Tue, 7 Dec 2010, Chikkature Rajashekar, Madhusudhan wrote:
> Last I tested OFF mode was after Adrian's power saving series was merged. I
> tested it on Kevin PM branch then and it was functional on my omap3 board.
>
> I need to check on the latest commit.
>
> Did you see th
Paul,
Last I tested OFF mode was after Adrian's power saving series was merged. I
tested it on Kevin PM branch then and it was functional on my omap3 board.
I need to check on the latest commit.
Did you see this problem in suspend/resume path or the cpuidle path?
Regards,
Madhu
On Tue, Dec 7, 2
Madhusudhan,
On my OMAP35xx BeagleBoard here, HSMMC is non-functional after returning
from dynamic off-mode. The MMC LED turns on and stays on, and the process
hangs, although the rest of the system still seems to run. Looks like
you're listed as the maintainer for this code. Do you know wh
On Tuesday, December 07, 2010 18:55:05 Mark Brown wrote:
> On Tue, Dec 07, 2010 at 06:13:35PM +0100, Hans Verkuil wrote:
>
> > Personally I think this is perfectly clear. The original confusion came from
> > the word 'active', which I understand means 'streaming' in alsa. By adding
> > a 'streamin
On Tue, Dec 07, 2010 at 06:13:35PM +0100, Hans Verkuil wrote:
> Personally I think this is perfectly clear. The original confusion came from
> the word 'active', which I understand means 'streaming' in alsa. By adding
> a 'streaming' flag in addition to the active flag I think it will be clear
> t
On Friday, December 03, 2010 15:54:08 Mark Brown wrote:
> On Fri, Dec 03, 2010 at 02:50:58PM +0100, Laurent Pinchart wrote:
> > On Friday 03 December 2010 13:06:18 Hans Verkuil wrote:
>
> > > > Just to confirm thinks, Mark's proposal is to replace 'connected' by
> > > > 'linked' and 'active' by 'c
This makes sense, because Thumb-2 code can't execute on anything
prior to ARMv7.
This will avoid accidentally configuring a broken kernel where the
config otherwise would allow multiple architecture versions to
coexist in the same kernel.
Not adding !CPU_V5 etc., because the chance of anyone tryi
Hi,
On Tue, Dec 7, 2010 at 6:28 AM, Santosh Shilimkar
wrote:
> Dave,
>> -Original Message-
>> From: linaro-dev-boun...@lists.linaro.org [mailto:linaro-dev-
>> boun...@lists.linaro.org] On Behalf Of Dave Martin
>> Sent: Monday, December 06, 2010 11:06 PM
>> To: linux-arm-ker...@lists.infra
On Tue, Dec 07, 2010 at 07:25:12PM +0530, Gupta, Ajay Kumar wrote:
Hi,
>> Is AM35x that different ? Can't you just write to MUSB_INTRRX
>> MUSB_INTRTX and MUSB_INTRUSB ??
>Writing to MUSB_INTRRX/TX/USB wouldn't help. We have to clear interrupt
>Bit in control register INTR_LVL_CLR.
I see, thank
Hi Paul,
On 12/7/2010 5:04 PM, Paul Walmsley wrote:
Hello,
On Tue, 7 Dec 2010, MING ZHOU wrote:
Since we need to reconfigure Reset time for OMAP4, we found the OMAP4
register definition for reset time is wrong according to spec of
OMAP4. And we verified this by reading default value of regist
Hello Samuel,
On Tue, 7 Dec 2010, Samuel Ortiz wrote:
> On Mon, Dec 06, 2010 at 06:40:38PM -0700, Paul Walmsley wrote:
> >
> > That's fine with me. Samuel et al, Bryan's already done a patch
> > for this stuff:
> >
> > https://patchwork.kernel.org/patch/367011/
> >
> > so we should use that
Hello,
On Tue, 7 Dec 2010, MING ZHOU wrote:
> Since we need to reconfigure Reset time for OMAP4, we found the OMAP4
> register definition for reset time is wrong according to spec of
> OMAP4. And we verified this by reading default value of register. We
> found the offset definition of Reset time
On Tue, Dec 7, 2010 at 2:53 PM, Dave Martin wrote:
[...]
> Note that converting to C doesn't mean that code which attempts to
> copy function bodies will work: you still need to handle the fact that
> if f() is a C function symbol, then the value of the symbol f is
> actually the function's base a
Hi,
On Tue, Dec 7, 2010 at 11:59 AM, Jean Pihet wrote:
> Hi Dave,
>
> On Tue, Dec 7, 2010 at 11:16 AM, Dave Martin wrote:
>> On Tue, Dec 7, 2010 at 6:31 AM, Santosh Shilimkar
>> wrote:
>>> Dave,
-Original Message-
From: linaro-dev-boun...@lists.linaro.org [mailto:linaro-dev-
>
Hi,
> >> Is AM35x that different ? Can't you just write to MUSB_INTRRX
> >> MUSB_INTRTX and MUSB_INTRUSB ??
> >Writing to MUSB_INTRRX/TX/USB wouldn't help. We have to clear interrupt
> >Bit in control register INTR_LVL_CLR.
>
> I see, thanks for the info :-)
Felipe,
I have recreated this patch (
Raghuveer Murthy had written, on 12/07/2010 06:25 AM, the following:
This patch adds omap_reserve functionality to board-omap4panda.c.
Helps in the reserving boot time memory in SDRAM, used here for
framebuffer allocation.
Signed-off-by: Russell King
Since Russell did not directly contribute to
musb device registration during board initialization of OMAP4430SDP
and OMAP4430 PANDA.Enable the musb OTG mode.
Signed-off-by: Hema HK
Cc: Felipe Balbi
Cc: Tony Lindgren
---
arch/arm/mach-omap2/board-4430sdp.c|6 ++
arch/arm/mach-omap2/board-omap4panda.c |2 +-
2 files changed
OMAP4430 supports UTMI and ULPI types of transceiver interface.
In UTMI mode: The PHY is embedded within OMAP4430. The transceiver functionality
is split between the twl6030 PMIC chip and OMAP4430. The VBUS, ID pin
sensing and OTG SRP generation part is integrated in TWL6030 and UTMI PHY
function
Selecting the twl6030-usb for OMAP4430SDP and OMAP4 PANDA board and
adding OMAP4 internal phy code for compilation
Signed-off-by: Hema HK
Cc: Felipe Balbi
Cc: Tony Lindgren
---
arch/arm/mach-omap2/Makefile |1 +
drivers/usb/musb/Kconfig |1 +
2 files changed, 2 insertions(+)
Index
Registering the twl6030-usb transceiver device as a child to twl6030 core.
Removed the NOP transceiver init call from board file.
Populated twl4030_usb_data platform data structure with the function
pointers for OMAP4430 internal PHY operation to be used twl630-usb driver.
Signed-off-by: Hema HK
Added the TWL6030-usb transceiver option in the Kconfig
Signed-off-by: Hema HK
Cc: Felipe Balbi
Cc: David Brownell
---
drivers/usb/otg/Kconfig | 12
1 file changed, 12 insertions(+)
Index: linux-2.6/drivers/usb/otg/Kconfig
===
Adding the twl6030-usb transceiver support for OMAP4 musb driver.
OMAP4 supports 2 types of transceiver interface.
1. UTMI: The PHY is embedded within OMAP4. The transceiver functionality
is split between the twl6030 PMIC chip and OMAP4430. The VBUS, ID pin
sensing and OTG SRP generation part is
With TWL6030-usb, VBUS SESS_VLD and SESS_END events are not generated
as expected. When these interrupts are enabled, charger VBUS detection
interrupt does not get generated. So USBOTG has to be dependent on charger
VBUS interrupts.
So added one bit for USBOTG and changed the handler to call the
U
This patch series has the support for TWL6030-usb
transceiver driver and changes in the musb driver to make it functional
with OMAP4430.
OMAP4 musb support UTMI and ULPI transceiver interfaces.
In UTMI mode, the transceiver functionality is split between
the TWL6030 PMIC chip and OMAP4 embedded P
On Mon, Dec 06, 2010 at 06:25:17PM -0700, Paul Walmsley wrote:
> In preparation for adding OMAP4-specific PRCM accessor/mutator
> functions, split the existing OMAP2/3 PRCM code into OMAP2/3-specific
> files. Most of what was in mach-omap2/{cm,prm}.{c,h} has now been
> moved into mach-omap2/{cm,pr
Hello.
On 06-12-2010 20:54, Tony Lindgren wrote:
As the control.h have been moved to new location and it's
uses are not allowed to drivers directly so moving the phy
control, interrupt clear and reset functionality to board
files.
I'm not fond of the whole approach. I'm not sure why acce
1 - 100 of 130 matches
Mail list logo
