On Tue, Jun 19, 2012 at 11:32 PM, Kevin Hilman khil...@ti.com wrote:
Munegowda, Keshava keshava_mgo...@ti.com writes:
On Fri, Jun 15, 2012 at 7:17 PM, Jean Pihet jean.pi...@newoldbits.com
wrote:
Hi Keshava,
On Fri, Jun 15, 2012 at 2:04 PM, Munegowda, Keshava
keshava_mgo...@ti.com wrote:
Hi Jean,
On Friday 01 June 2012 08:41 PM, Jean Pihet wrote:
For a power domain to idle all the clock domains in it must idle.
This patch implements an optimization of the cpuidle code by
denying and later allowing only the first registered clock domain
of a power domain, and so optimizes the
Hi Rajendra,
On Wed, Jun 20, 2012 at 10:19 AM, Rajendra Nayak rna...@ti.com wrote:
Hi Jean,
On Friday 01 June 2012 08:41 PM, Jean Pihet wrote:
For a power domain to idle all the clock domains in it must idle.
This patch implements an optimization of the cpuidle code by
denying and later
On Tue, Jun 19, 2012 at 04:51:07PM +0530, Gupta, Ramesh wrote:
From 785a1f2854002ce7c1c8880bc5d8d92a7868bf1c Mon Sep 17 00:00:00 2001
From: Ramesh Gupta G grgu...@ti.com
Date: Fri, 15 Jun 2012 16:37:20 +0530
Subject: [PATCH v2 1/4] ARM: new cache maintenance api for iommu mem flush
On Tue, Jun 19, 2012 at 04:51:16PM +0530, Gupta, Ramesh wrote:
From 630a3a8f341eb7f58f9a63bf786d732b5bdfd01e Mon Sep 17 00:00:00 2001
From: Ramesh Gupta G grgu...@ti.com
Date: Fri, 15 Jun 2012 16:39:21 +0530
Subject: [PATCH v2 2/4] ARM: add flush_mem api for ARMv6
Added flush_mem cache
On Wednesday 20 June 2012 02:01 PM, Jean Pihet wrote:
Hi Rajendra,
On Wed, Jun 20, 2012 at 10:19 AM, Rajendra Nayakrna...@ti.com wrote:
Hi Jean,
On Friday 01 June 2012 08:41 PM, Jean Pihet wrote:
For a power domain to idle all the clock domains in it must idle.
This patch implements an
Extends the maximum number of UART ports to 6 from 4 because AM335X
device have six UART ports.
Signed-off-by: AnilKumar Ch anilku...@ti.com
---
arch/arm/plat-omap/include/plat/omap-serial.h |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
Hi Jean,
On Wednesday 20 June 2012 02:16 PM, Rajendra Nayak wrote:
On Wednesday 20 June 2012 02:01 PM, Jean Pihet wrote:
Hi Rajendra,
On Wed, Jun 20, 2012 at 10:19 AM, Rajendra Nayakrna...@ti.com wrote:
Hi Jean,
On Friday 01 June 2012 08:41 PM, Jean Pihet wrote:
For a power domain to
Jean,
On Wednesday 20 June 2012 02:22 PM, Rajendra Nayak wrote:
Hi Jean,
On Wednesday 20 June 2012 02:16 PM, Rajendra Nayak wrote:
On Wednesday 20 June 2012 02:01 PM, Jean Pihet wrote:
Hi Rajendra,
On Wed, Jun 20, 2012 at 10:19 AM, Rajendra Nayakrna...@ti.com wrote:
Hi Jean,
On Friday 01
Hi Russell,
On Wed, Jun 20, 2012 at 2:13 PM, Russell King - ARM Linux
li...@arm.linux.org.uk wrote:
On Tue, Jun 19, 2012 at 04:51:07PM +0530, Gupta, Ramesh wrote:
From 785a1f2854002ce7c1c8880bc5d8d92a7868bf1c Mon Sep 17 00:00:00 2001
From: Ramesh Gupta G grgu...@ti.com
Date: Fri, 15 Jun 2012
Hi Russell,
On Wed, Jun 20, 2012 at 2:15 PM, Russell King - ARM Linux
li...@arm.linux.org.uk wrote:
On Tue, Jun 19, 2012 at 04:51:16PM +0530, Gupta, Ramesh wrote:
From 630a3a8f341eb7f58f9a63bf786d732b5bdfd01e Mon Sep 17 00:00:00 2001
From: Ramesh Gupta G grgu...@ti.com
Date: Fri, 15 Jun
Signed-off-by: Vaibhav Hiremath hvaib...@ti.com
Tested-by: Zumeng Chen zumeng.c...@windriver.com
---
arch/arm/mach-omap2/board-omap3evm.c | 39 ++
1 files changed, 39 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/board-omap3evm.c
The series is based upon the latest linux-omap master branch from
Tony (3.5-rc2).
V3 Changes :
1. [patch 5/5] Leave driver/input/touchscreen as-is. some changes
on arch/arm/mach-omap2/common-board-devices.c, please see the
shortlog for more information.
2. For the first patch, I
EHCI PHY requires these regulators:
EVM Rev =E -- VAUX2
EVM Rev E -- VUSB1V5, VUSB1V8
Adding USB internal LDOs (vusb1v5 vusb1v8) and VAUX2 to omap3evm
board file. Also removing vaux2_{1/2/3} supplies as they are not
used on omap3 evm.
But we need not to add vaux2 in
This was chosen by following the trace on the schematic from component U131
and U134 to the CPEN pin on the USB3320 device.
TWL4030.GPIO2-...-(T2_GPIO2_3V3)U131-..nUSB2_EN-..U134-..EXP_nUSB2_1V8
which starts EHCI tranceiver USB3320.
This will set TWL4030.GPIO2 as output pin to drive EHCI
Since it's no more sense to set parent for dummy clock,
so we can just ignore it to mute failed message.
Signed-off-by: Jon Hunter jon-hun...@ti.com
Signed-off-by: Zumeng Chen zumeng.c...@gmail.com
---
arch/arm/plat-omap/clock.c |4
drivers/mfd/omap-usb-host.c |2 +-
2 files
Currently most ads7846 config definitions for OMAP3 series boards have
been moved to common-board-devices.c, and it is transparent for init.
And it's no very proper to do gpio_request based on get_pendown_state
since omap_ads7846_init knows everything about ads7846_config.
So it's more fit to
On Thursday 14 June 2012 08:23 PM, Jean Pihet wrote:
omap_set_pwrdm_state is intented to be the only API for changing
a power domain state.
Yes, but there are others which are used to _read_ the power domain
state. Shouldn't those be protected too?
This patch protects the power domains
On Wed, Jun 20, 2012 at 11:53 AM, Munegowda, Keshava
keshava_mgo...@ti.com wrote:
On Tue, Jun 19, 2012 at 11:32 PM, Kevin Hilman khil...@ti.com wrote:
Munegowda, Keshava keshava_mgo...@ti.com writes:
On Fri, Jun 15, 2012 at 7:17 PM, Jean Pihet jean.pi...@newoldbits.com
wrote:
Hi Keshava,
[PATCH] Fix OMAP EHCI suspend/resume failure (i693) '354ab856' causes
an oops on boot for all omap3xxx platforms that use usbhs_omap for
EHCI. The actual oops seems to come from faulty ehci-omap cleanup, but
the failure caused by the change is evidenced here:
[3.655059] ehci-omap ehci-omap.0:
* Konstantin Baydarov kbaida...@dev.rtsoft.ru [120618 04:36]:
This patch exposes the definitions under control.h to
drivers outside the machine code.
As discussed earlier, this will likely lead into misuse of these
registers that will be a big mess to clean up.
Can't you make these private to
* Konstantin Baydarov kbaida...@dev.rtsoft.ru [120618 04:36]:
This patch introduces a MFD core device driver for
OMAP system control module.
The control module allows software control of
various static modes supported by the device. It is
composed of two control submodules: general control
* Konstantin Baydarov kbaida...@dev.rtsoft.ru [120618 04:36]:
OMAP system control module can be probed early, then
omap_type is safe to use its APIs.
TODO: add support for other omap versions
Signed-off-by: Konstantin Baydarov kbaida...@dev.rtsoft.ru
---
arch/arm/mach-omap2/id.c |
* Konstantin Baydarov kbaida...@dev.rtsoft.ru [120618 04:36]:
OMAP4460 specific temperature sensor register bit fields are added.
Existing OMAP4 entries are renamed to OMAP4430.
Signed-off-by: Keerthy j-keer...@ti.com
Signed-off-by: Eduardo Valentin eduardo.valen...@ti.com
---
* Shubhrajyoti D shubhrajy...@ti.com [120618 07:35]:
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
On Thursday 14 June 2012 08:35 PM, Jean Pihet wrote:
Call the per-device PM QoS functions of the power domain code from the
hwmod layer, in order to apply the constraints requested to a device.
While at it, correct the functions kerneldoc.
Shouldn't this patch be just merged with PATCH 02/10?
* Shubhrajyoti D shubhrajy...@ti.com [120618 07:35]:
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
On Thursday 14 June 2012 08:35 PM, Jean Pihet wrote:
Implement the devices wake-up latency constraints using the global
device PM QoS notification handler which applies the constraints to the
underlying layer by calling the corresponding function at hwmod level.
Tested on OMAP3 Beagleboard and
* Kishon Vijay Abraham I kis...@ti.com [120530 07:38]:
All the unnessary functions in omap-phy-internal is removed.
These functionality are now handled by omap-usb2 phy driver.
Glad to see these move to live under drivers. Up to Felipe
to merge via linux-usb once the driver parts are finished:
On Thursday 14 June 2012 08:35 PM, Jean Pihet wrote:
{
.enter= omap3_enter_idle_bm,
- .exit_latency = 3000 + 8500,
- .target_residency = 15000,
+ .exit_latency = 4080 +
Hi Rajendra,
On Wed, Jun 20, 2012 at 10:57 AM, Rajendra Nayak rna...@ti.com wrote:
Jean,
On Wednesday 20 June 2012 02:22 PM, Rajendra Nayak wrote:
Hi Jean,
On Wednesday 20 June 2012 02:16 PM, Rajendra Nayak wrote:
On Wednesday 20 June 2012 02:01 PM, Jean Pihet wrote:
Hi Rajendra,
On
Rajendra,
On Wed, Jun 20, 2012 at 12:29 PM, Rajendra Nayak rna...@ti.com wrote:
On Thursday 14 June 2012 08:35 PM, Jean Pihet wrote:
Call the per-device PM QoS functions of the power domain code from the
hwmod layer, in order to apply the constraints requested to a device.
While at it,
* Rajendra Nayak rna...@ti.com [120606 22:33]:
Hi Tony,
On Tuesday 05 June 2012 12:12 PM, Tony Lindgren wrote:
* Rajendra Nayakrna...@ti.com [120601 05:13]:
The data is autogenerated using the OMAP autogeneration scripts (python
scripts). Thanks to Mike Turquette for the initial efforts in
On Wed, Jun 20, 2012 at 1:01 PM, Rajendra Nayak rna...@ti.com wrote:
On Thursday 14 June 2012 08:35 PM, Jean Pihet wrote:
{
.enter = omap3_enter_idle_bm,
- .exit_latency = 3000 + 8500,
-
* Rajendra Nayak rna...@ti.com [120614 22:01]:
On Friday 15 June 2012 12:41 AM, Mike Turquette wrote:
On 20120614-18:16, Rajendra Nayak wrote:
As we move to Common clk framework use clk_prepare_enable()
instead of clk_enable() and similarly clk_disable_unprepare()
instead of clk_disable()
The TLL configuration is removed from the UHH driver and implemented as
a seperate platform driver. Now, the UHH driver configures the TLL
through API's exported by the TLL platform driver. The TLL is an
has independent hardware mod structure for in OMAP3 and later chips,
hence an dedicated
The TLL specific code such as channels clocks enable/disable,
initialization functions are removed from the USBHS core
driver.
Signed-off-by: Keshava Munegowda keshava_mgo...@ti.com
Reviewed-by: Partha Basak part...@india.ti.com
---
drivers/mfd/omap-usb-host.c | 231
The hwmod of the usb tll is retrieved and omap device build is
performed to created the platform device for the usb tll component.
Signed-off-by: Keshava Munegowda keshava_mgo...@ti.com
Reviewed-by: Partha Basak part...@india.ti.com
---
arch/arm/mach-omap2/usb-host.c | 31
The platform driver for the TLL component of the OMAP USB host controller
is implemented. Depending on the TLL hardware revision , the TLL channels
are configured. The USB HS core driver uses this driver through exported
APIs from the TLL platform driver.
usb_tll_enable and usb_tll_disble are the
The platform device name for the functional, interface and
channel clocks of the TLL module is changed from usbhs device
to usb tll platform device name.
Signed-off-by: Keshava Munegowda keshava_mgo...@ti.com
Reviewed-by: Partha Basak part...@india.ti.com
---
arch/arm/mach-omap2/clock3xxx_data.c
The usbhs driver invokes the enable/disable APIs of the
usb tll driver in the runtime resume/suspend callbacks
of the runtime get sync and put sync of the usbhs driver.
Signed-off-by: Keshava Munegowda keshava_mgo...@ti.com
Reviewed-by: Partha Basak part...@india.ti.com
---
The TLL configuration is removed from the UHH driver and implemented as
a seperate platform driver. Now, the UHH driver configures the TLL
through API's exported by the TLL platform driver. The TLL is an
has independent hardware mod structure for in OMAP3 and later chips,
hence an dedicated
The usbhs driver invokes the enable/disable APIs of the
usb tll driver in the runtime resume/suspend callbacks
of the runtime get sync and put sync of the usbhs driver.
Signed-off-by: Keshava Munegowda keshava_mgo...@ti.com
Reviewed-by: Partha Basak part...@india.ti.com
---
The hwmod of the usb tll is retrieved and omap device build is
performed to created the platform device for the usb tll component.
Signed-off-by: Keshava Munegowda keshava_mgo...@ti.com
Reviewed-by: Partha Basak part...@india.ti.com
---
arch/arm/mach-omap2/usb-host.c | 31
The TLL specific code such as channels clocks enable/disable,
initialization functions are removed from the USBHS core
driver.
Signed-off-by: Keshava Munegowda keshava_mgo...@ti.com
Reviewed-by: Partha Basak part...@india.ti.com
---
drivers/mfd/omap-usb-host.c | 231
The platform driver for the TLL component of the OMAP USB host controller
is implemented. Depending on the TLL hardware revision , the TLL channels
are configured. The USB HS core driver uses this driver through exported
APIs from the TLL platform driver.
usb_tll_enable and usb_tll_disble are the
The platform device name for the functional, interface and
channel clocks of the TLL module is changed from usbhs device
to usb tll platform device name.
Signed-off-by: Keshava Munegowda keshava_mgo...@ti.com
Reviewed-by: Partha Basak part...@india.ti.com
---
arch/arm/mach-omap2/clock3xxx_data.c
Hello.
On 20-06-2012 13:14, Zumeng Chen wrote:
This was chosen by following the trace on the schematic from component U131
and U134 to the CPEN pin on the USB3320 device.
TWL4030.GPIO2-...-(T2_GPIO2_3V3)U131-..nUSB2_EN-..U134-..EXP_nUSB2_1V8
which starts EHCI tranceiver USB3320.
This
The TLL configuration is removed from the UHH driver and implemented as
a seperate platform driver. Now, the UHH driver configures the TLL
through API's exported by the TLL platform driver. The TLL is an
has independent hardware mod structure for in OMAP3 and later chips,
hence an dedicated
The platform driver for the TLL component of the OMAP USB host controller
is implemented. Depending on the TLL hardware revision , the TLL channels
are configured. The USB HS core driver uses this driver through exported
APIs from the TLL platform driver.
usb_tll_enable and usb_tll_disble are the
The usbhs driver invokes the enable/disable APIs of the
usb tll driver in the runtime resume/suspend callbacks
of the runtime get sync and put sync of the usbhs driver.
Signed-off-by: Keshava Munegowda keshava_mgo...@ti.com
Reviewed-by: Partha Basak part...@india.ti.com
---
The TLL specific code such as channels clocks enable/disable,
initialization functions are removed from the USBHS core
driver.
Signed-off-by: Keshava Munegowda keshava_mgo...@ti.com
Reviewed-by: Partha Basak part...@india.ti.com
---
drivers/mfd/omap-usb-host.c | 231
The platform device name for the functional, interface and
channel clocks of the TLL module is changed from usbhs device
to usb tll platform device name.
Signed-off-by: Keshava Munegowda keshava_mgo...@ti.com
Reviewed-by: Partha Basak part...@india.ti.com
---
arch/arm/mach-omap2/clock3xxx_data.c
The hwmod of the usb tll is retrieved and omap device build is
performed to created the platform device for the usb tll component.
Signed-off-by: Keshava Munegowda keshava_mgo...@ti.com
Reviewed-by: Partha Basak part...@india.ti.com
---
arch/arm/mach-omap2/usb-host.c | 31
On Wednesday 20 June 2012 04:02 PM, Tony Lindgren wrote:
* Shubhrajyoti D shubhrajy...@ti.com [120618 07:35]:
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
* Jon Hunter jon-hun...@ti.com [120612 17:45]:
When booting with device-tree on an OMAP2420H4, the kernel is hanging when
initialising the interrupts and following kernel dumps is seen ...
[0.00] [ cut here ]
[0.00] WARNING: at
* DebBarma, Tarun Kanti tarun.ka...@ti.com [120606 04:15]:
On Wed, May 30, 2012 at 2:51 AM, Kevin Hilman khil...@ti.com wrote:
Tarun Kanti DebBarma tarun.ka...@ti.com writes:
Timers in PER domain periodically report old time from TCRR in
posted mode if ick 4*fck. Therefore, set timer to
Tony,
On Wed, Jun 20, 2012 at 6:43 PM, Tony Lindgren t...@atomide.com wrote:
* DebBarma, Tarun Kanti tarun.ka...@ti.com [120606 04:15]:
On Wed, May 30, 2012 at 2:51 AM, Kevin Hilman khil...@ti.com wrote:
Tarun Kanti DebBarma tarun.ka...@ti.com writes:
Timers in PER domain
* mathieu.poir...@linaro.org mathieu.poir...@linaro.org [120607 17:55]:
From: Arnd Bergmann a...@arndb.de
There is no way to build OMAP kernels without an MMU
at this point because of dependencies on MMU-only functions.
As long as nobody is interested in fixing this, let's just disable
* Mohammed, Afzal af...@ti.com [120616 02:19]:
Hi Tony,
On Fri, Jun 15, 2012 at 18:15:20, Tony Lindgren wrote:
* Mohammed, Afzal af...@ti.com [120615 03:26]:
Here clock is required even before driver is probed, i.e for platform to
calculate timings, that has to be passed through
* Ruslan Bilovol ruslan.bilo...@ti.com [120612 10:42]:
If the clocks are enabled and we want to enable them again
omap4430_phy_set_clk disables them.
Fix this - so now if we try to enable already enabled clocks
it works correctly.
Sounds like Felipe is on vacation. Trying to figure out if
* Tomi Valkeinen tomi.valkei...@ti.com [120614 05:25]:
On Thu, 2012-06-14 at 04:40 -0700, Russ Dill wrote:
On Thu, Jun 14, 2012 at 1:13 AM, Tomi Valkeinen tomi.valkei...@ti.com
wrote:
On Thu, 2012-06-14 at 00:59 -0700, Russ Dill wrote:
On Thu, Jun 14, 2012 at 12:18 AM, Tomi Valkeinen
Hi, Tony.
On 06/20/2012 02:22 PM, Tony Lindgren wrote:
* Konstantin Baydarov kbaida...@dev.rtsoft.ru [120618 04:36]:
This patch introduces a MFD core device driver for
OMAP system control module.
The control module allows software control of
various static modes supported by the device.
* Shubhrajyoti shubhrajy...@ti.com [120620 06:06]:
On Wednesday 20 June 2012 04:02 PM, Tony Lindgren wrote:
* Shubhrajyoti D shubhrajy...@ti.com [120618 07:35]:
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
* Shilimkar, Santosh santosh.shilim...@ti.com [120620 06:21]:
Tony,
On Wed, Jun 20, 2012 at 6:43 PM, Tony Lindgren t...@atomide.com wrote:
* DebBarma, Tarun Kanti tarun.ka...@ti.com [120606 04:15]:
On Wed, May 30, 2012 at 2:51 AM, Kevin Hilman khil...@ti.com wrote:
Tarun Kanti
Munegowda, Keshava keshava_mgo...@ti.com writes:
On Wed, Jun 20, 2012 at 11:53 AM, Munegowda, Keshava
keshava_mgo...@ti.com wrote:
On Tue, Jun 19, 2012 at 11:32 PM, Kevin Hilman khil...@ti.com wrote:
Munegowda, Keshava keshava_mgo...@ti.com writes:
On Fri, Jun 15, 2012 at 7:17 PM, Jean
* Joe Woodward j...@terrafix.co.uk [120615 05:51]:
Someone may have spotted this already...
But if you build todays linux-next (next-20120615) without
CONFIG_MTD_ONENAND_OMAP2 or
CONFIG_MTD_ONENAND_OMAP2_MODULE then board_onenand_init() is defined in two
places
(in board-flash.c:102 as
* Peter Ujfalusi peter.ujfal...@ti.com [120615 06:38]:
If the kernel is built only for OMAP2 the following warning will show up:
arch/arm/mach-omap2/twl-common.c:52: warning: ‘twl_set_voltage’ defined but
not used
arch/arm/mach-omap2/twl-common.c:58: warning: ‘twl_get_voltage’ defined but
* Brian Austin brian.aus...@cirrus.com [120619 07:29]:
The beagleboard USB Host Port that is used is Port 2. The platform driver
sets MODE_PHY for port 1 causing pin muxing to override the pins on the
expansion
connector P17 when using board_mux[]. Since USBHS Port 1 is not connected
Hi Tony,
On Wed, Jun 20, 2012 at 18:58:49, Tony Lindgren wrote:
* Mohammed, Afzal af...@ti.com [120616 02:19]:
On Fri, Jun 15, 2012 at 18:15:20, Tony Lindgren wrote:
By gpmc registration, if you meant registering platform device for
gpmc peripherals, for a board that uses the new gpmc
* Mohammed, Afzal af...@ti.com [120620 07:57]:
Hi Tony,
On Wed, Jun 20, 2012 at 18:58:49, Tony Lindgren wrote:
* Mohammed, Afzal af...@ti.com [120616 02:19]:
On Fri, Jun 15, 2012 at 18:15:20, Tony Lindgren wrote:
By gpmc registration, if you meant registering platform device for
On 06/20/2012 04:14 AM, Zumeng Chen wrote:
Since it's no more sense to set parent for dummy clock,
so we can just ignore it to mute failed message.
Signed-off-by: Jon Hunter jon-hun...@ti.com
Signed-off-by: Zumeng Chen zumeng.c...@gmail.com
---
arch/arm/plat-omap/clock.c |4
Hi Afzal,
On 06/19/2012 12:57 AM, Mohammed, Afzal wrote:
Hi Jon,
On Mon, Jun 18, 2012 at 21:31:46, Hunter, Jon wrote:
@@ -95,10 +89,6 @@ static int omap2_onenand_set_async_mode(int cs, void
__iomem *onenand_base)
if (err)
return err;
- /* Ensure sync read and sync
As per the OMAP4 documentation, audio over HDMI should be transmitted in
no-idle mode. This patch adds the HWMOD_SWSUP_SIDLE so that omap_hwmode uses
no-idle/force-idle settings instead of smart-idle mode.
This is required as the DSS interface clock is used as functional clock
for the HDMI
On 06/20/2012 10:12 AM, Tony Lindgren wrote:
* Mohammed, Afzal af...@ti.com [120620 07:57]:
Hi Tony,
On Wed, Jun 20, 2012 at 18:58:49, Tony Lindgren wrote:
* Mohammed, Afzal af...@ti.com [120616 02:19]:
On Fri, Jun 15, 2012 at 18:15:20, Tony Lindgren wrote:
By gpmc registration, if you
于 2012年06月20日 20:05, Sergei Shtylyov 写道:
Hello.
On 20-06-2012 13:14, Zumeng Chen wrote:
This was chosen by following the trace on the schematic from
component U131
and U134 to the CPEN pin on the USB3320 device.
TWL4030.GPIO2-...-(T2_GPIO2_3V3)U131-..nUSB2_EN-..U134-..EXP_nUSB2_1V8
于 2012年06月21日 00:00, Jon Hunter 写道:
On 06/20/2012 04:14 AM, Zumeng Chen wrote:
Since it's no more sense to set parent for dummy clock,
so we can just ignore it to mute failed message.
Signed-off-by: Jon Hunterjon-hun...@ti.com
Signed-off-by: Zumeng Chenzumeng.c...@gmail.com
---
On Thu, 14 Jun 2012 23:24:10 +0530 DebBarma, Tarun Kanti
tarun.ka...@ti.com wrote:
On Thu, Jun 14, 2012 at 5:45 AM, NeilBrown ne...@suse.de wrote:
On Fri, 11 May 2012 17:30:48 -0700 Kevin Hilman khil...@ti.com wrote:
Hi Grant,
Here's the final round of GPIO cleanups for v3.5. This
On 06/14/2012 09:26 AM, Alex Shi wrote:
On 06/14/2012 09:10 AM, Alex Shi wrote:
On 06/13/2012 10:56 PM, Andi Kleen wrote:
On Tue, Jun 12, 2012 at 05:06:45PM +0800, Alex Shi wrote:
This patch do flush_tlb_kernel_range by 'invlpg'. The performance pay
and gain was analysed in my patch
On Wednesday 20 June 2012 05:11 PM, Tony Lindgren wrote:
* Rajendra Nayakrna...@ti.com [120614 22:01]:
On Friday 15 June 2012 12:41 AM, Mike Turquette wrote:
On 20120614-18:16, Rajendra Nayak wrote:
As we move to Common clk framework use clk_prepare_enable()
instead of clk_enable() and
On Thu, 21 Jun 2012, Rajendra Nayak wrote:
Paul, are you ok to look at them as preparatory patches for CCF
conversion too?
Yes. Also it looks like some of these patches should go through Mike
since they add features to the CCF, so it's probably best to break those
out into a separate series
On Thursday 21 June 2012 11:13 AM, Paul Walmsley wrote:
On Thu, 21 Jun 2012, Rajendra Nayak wrote:
Paul, are you ok to look at them as preparatory patches for CCF
conversion too?
Yes. Also it looks like some of these patches should go through Mike
since they add features to the CCF, so it's
82 matches
Mail list logo