Hi Tony,
Please pull from:
git://github.com/ohadbc/omap-iommu.git for-tony
To receive trivial iommu/iovmm fixes (iommu clk name fix, pte fix and
a fix for iovmm's erroneous
usage of sg_dma_len as reported by Russell).
All three patches were submitted to linux-omap and linux-arm-kernel for revie
* Rajendra Nayak [110630 19:03]:
> For 4460sdp/blaze/panda, GPIO-7 of bank1 is used for controlling
> the TPS modes, hence GPIO1 should not be reset
> during init as reset will cause the TPS voltage to
> drop to 0.9 V preventing the system from continuing the boot.
NAK for this patch. We don't wa
* Rajendra Nayak [110630 19:03]:
> --- a/arch/arm/mach-omap2/id.c
> +++ b/arch/arm/mach-omap2/id.c
> @@ -331,8 +331,8 @@ static void __init omap3_check_revision(void)
> static void __init omap4_check_revision(void)
> {
> u32 idcode;
> - u16 hawkeye;
> u8 rev;
> + u16 hawkeye;
On Fri, Jul 1, 2011 at 1:06 AM, Cousson, Benoit wrote:
> Hi Balaji,
>
> On 6/30/2011 9:04 PM, Krishnamoorthy, Balaji T wrote:
>>
>> Removing the custom state machine - lazy disable framework in omap_hsmmc
>> to make way for runtime pm to handle host controller
>> power states.
>> This allows mmc_h
On Fri, Jul 1, 2011 at 3:33 AM, Rafael J. Wysocki wrote:
> In theory it is possible that a subsystem (e.g. bus type) will enable
> runtime PM for devices without drivers and will (for example) put them
> into low power states until the drivers are loaded. Then, it makes
> sense for the core to pr
On Friday 01 July 2011 08:11 AM, Todd Poynor wrote:
On Fri, Jul 01, 2011 at 07:37:56AM +0530, Rajendra Nayak wrote:
From: Aneesh V
Macros for identifying the max frequency supported by various
OMAP4 variants - Expanding along the lines of OMAP3's feature
handling.
[n...@ti.com: minor fixes f
On Fri, Jul 1, 2011 at 2:37 AM, wrote:
> From: Madhusudhan Chikkature
>
> Removing the OMAP HS MMC entry from the MAINTAINERS file as I will
> no longer be able to maintain this driver.
>
> Signed-off-by: Madhusudhan Chikkature
> ---
> MAINTAINERS | 6 --
> 1 files changed, 0 insertions
Kevin,
On Fri, Jul 1, 2011 at 5:03 AM, Kevin Hilman wrote:
> +Tero
>
> Mohan V writes:
>
>> Hello all,
>>
>> I am trying to correct the implementation of the enabling/disabling IO
>> daisy chain in omap3.
>
> Thanks for doing the investigation and proposing a fix!
>
>> I am following the steps a
On Fri, Jul 01, 2011 at 07:37:56AM +0530, Rajendra Nayak wrote:
> From: Aneesh V
>
> Macros for identifying the max frequency supported by various
> OMAP4 variants - Expanding along the lines of OMAP3's feature
> handling.
>
> [n...@ti.com: minor fixes for checks that should only for 443x|446x]
For 4460sdp/blaze/panda, GPIO-7 of bank1 is used for controlling
the TPS modes, hence GPIO1 should not be reset
during init as reset will cause the TPS voltage to
drop to 0.9 V preventing the system from continuing the boot.
Signed-off-by: Nishanth Menon
Signed-off-by: Moiz Sonasath
Signed-off-b
The 4460 platform has no difference in the clockdomains as compared
to the 4430 platform. Hence just update the .omap_chip field to make
sure the same clockdomain data can be reused on the 4460 platform.
Signed-off-by: Rajendra Nayak
Signed-off-by: Nishanth Menon
Signed-off-by: Benoit Cousson
-
The 4460 platform has no difference in the powerdomains as compared
to the 4430 platform. Hence just update the .omap_chip field to make
sure the same powerdomain data can be reused on the 4460 platform.
Signed-off-by: Rajendra Nayak
Signed-off-by: Nishanth Menon
Signed-off-by: Benoit Cousson
-
This patch adds additional register bitshifts for
registers added in OMAP4460 platform.
Signed-off-by: Rajendra Nayak
Signed-off-by: Nishanth Menon
Signed-off-by: Benoit Cousson
---
arch/arm/mach-omap2/cm-regbits-44xx.h | 36
arch/arm/mach-omap2/prm-regbits-
Add the new clock nodes (bandgap_ts_fclk, div_ts_ck) for omap4460.
Handle these nodes using the clock flags (CK_*).
Signed-off-by: Rajendra Nayak
Signed-off-by: Nishanth Menon
Signed-off-by: Benoit Cousson
---
arch/arm/mach-omap2/clock44xx_data.c | 39 +
arch
From: Aneesh V
Macros for identifying the max frequency supported by various
OMAP4 variants - Expanding along the lines of OMAP3's feature
handling.
[n...@ti.com: minor fixes for checks that should only for 443x|446x]
Signed-off-by: Nishanth Menon
Signed-off-by: Aneesh V
---
arch/arm/mach-oma
From: Aneesh V
Add support for detecting the latest in the OMAP4 family: OMAP4460
Among other changes, the new chip also can support 1.5GHz A9s,
1080p stereoscopic 3D and 12 MP stereo (dual camera). In addition,
we have changes to OPPs supported, clock tree etc, hence having a
chip detection is r
This series adds base support needed to be able
to boot on a OMAP4460 device.
Patches are based on Benoit's for_3.0.1/7_hwmod_modulemode
branch and boot tested on both 4460sdp as well as 4430sdp.
Aneesh V (2):
OMAP: ID: introduce chip detection for OMAP4460
OMAP4: ID: add omap_has_feature for
On Fri, 1 Jul 2011, Silesh C V wrote:
> On Thu, Jun 30, 2011 at 9:06 PM, Felipe Balbi wrote:
> > That might have been correct on some ancient
> > dead language, but I like better when things
> > are recent.
> >
> > Fix the alphabetical order.
> >
> > Signed-off-by: Felipe Balbi
> > ---
> >
> > F
On Thu, Jun 30, 2011 at 9:06 PM, Felipe Balbi wrote:
> That might have been correct on some ancient
> dead language, but I like better when things
> are recent.
>
> Fix the alphabetical order.
>
> Signed-off-by: Felipe Balbi
> ---
>
> Fixed missing comma after Richard's name and removed
> comma a
On Friday, July 01, 2011, Kevin Hilman wrote:
> Kevin Hilman writes:
>
> > Continuing on the theme of runtime PM interactions with other parts of
> > the driver core...
> >
> > In drivers/base/dd.c:driver_probe_device(), the driver core increments
> > the usage count around ->probe():
> >
> >
Kevin Hilman writes:
> Continuing on the theme of runtime PM interactions with other parts of
> the driver core...
>
> In drivers/base/dd.c:driver_probe_device(), the driver core increments
> the usage count around ->probe():
>
> [...]
> pm_runtime_get_noresume(dev);
> pm_runt
Hi Benoît,
On Thu, 23 Jun 2011, Benoit Cousson wrote:
> Hi Paul & Rajendra,
>
> Here are a couple of fixes on PRCM header files and powerdomain data.
>
> The series is based on v3.0-rc4 and tested on OMAP4430 ES2.1 + SDP.
>
> The patches are available here:
> git://gitorious.org/omap-pm/linux.
On Thu, 23 Jun 2011, Benoit Cousson wrote:
> Since ES2.0, the core ocmram does not support a different state
> than the main power domain anymore during both ON and RET power
> domain state.
> Since PM is not supported at all in ES1.0, update the common
> structure.
>
> LOWPOWERSTATECHANGE is sup
+Tero
Mohan V writes:
> Hello all,
>
> I am trying to correct the implementation of the enabling/disabling IO
> daisy chain in omap3.
Thanks for doing the investigation and proposing a fix!
> I am following the steps as listed in the OMAP36xx TRM Sec. 3.5.7.2.2
> for the same.
Please add the
Balaji T K writes:
> add runtime pm support to HSMMC host controller
> Use runtime pm API to enable/disable HSMMC clock
> Use runtime autosuspend APIs to enable auto suspend delay
>
> Based on OMAP HSMMC runtime implementation by Kevin Hilman, Kishore Kadiyala
>
> Signed-off-by: Balaji T K
Mino
On Thu, 23 Jun 2011, Benoit Cousson wrote:
> The following commit introduced new macros to define an offset
> per clock domain in an instance.
>
> commit e4156ee52fe617c2c2d80b5db993ff4bf07d7c3c
>
> OMAP4: CM instances: add clockdomain register offsets
>
> The PRM contains only two clock co
Hi,
just FYI the subject of this message should read "prcm" rather than "pcrm"
On Thu, 23 Jun 2011, Benoit Cousson wrote:
> A couple of macros were wrongly changed during the _MOD to _INST
> rename done in the following commit:
>
> OMAP4: PRCM: rename _MOD macros to _INST
> cdb54c4457d68994
"DebBarma, Tarun Kanti" writes:
> Kevin,
> [...]
>> > -#endif
>> > - default:
>> > - continue;
>> > - }
>> > + if (!bank->suspend_support)
>> > + return 0;
>>
>> Rather than check the flag here in every suspend, don't add a suspend
>>
Shubhrajyoti writes:
> On Thursday 30 June 2011 04:53 AM, Kevin Hilman wrote:
>> Shubhrajyoti D writes:
>>
>>> Currently the fifo depth is set to zero for OMAP4 which disables
>>> the FIFO usage. This patch enables the FIFO usage for I2C transactions
>>> on OMAP4 also.
>> Do you know the history
Continuing on the theme of runtime PM interactions with other parts of
the driver core...
In drivers/base/dd.c:driver_probe_device(), the driver core increments
the usage count around ->probe():
[...]
pm_runtime_get_noresume(dev);
pm_runtime_barrier(dev);
ret = rea
From: Madhusudhan Chikkature
Removing the OMAP HS MMC entry from the MAINTAINERS file as I will
no longer be able to maintain this driver.
Signed-off-by: Madhusudhan Chikkature
---
MAINTAINERS |6 --
1 files changed, 0 insertions(+), 6 deletions(-)
diff --git a/MAINTAINERS b/MAINTAINE
Hi Balaji,
On 6/30/2011 9:04 PM, Krishnamoorthy, Balaji T wrote:
Removing the custom state machine - lazy disable framework in omap_hsmmc
to make way for runtime pm to handle host controller
power states.
This allows mmc_host_enable/mmc_host_disable to be replaced by
runtime get_sync and put_syn
lazy_disable framework in OMAP HSMMC manages multiple low power states
and Card is powered off after inactivity time of 8 seconds.
Based on previous discussion on the list, card power (regulator)
handling (when to power OFF/ON) should ideally be handled by core layer.
Remove usage of lazy disable t
add runtime pm support to HSMMC host controller
Use runtime pm API to enable/disable HSMMC clock
Use runtime autosuspend APIs to enable auto suspend delay
Based on OMAP HSMMC runtime implementation by Kevin Hilman, Kishore Kadiyala
Signed-off-by: Balaji T K
---
changes since v2
Change autosuspen
Removing the custom state machine - lazy disable framework in omap_hsmmc
to make way for runtime pm to handle host controller
power states.
This allows mmc_host_enable/mmc_host_disable to be replaced by
runtime get_sync and put_sync at host controller driver.
Enable runtime PM in omap_hsmmc
Rebas
After runtime conversion to handle clk,
iclk node is not used
However fclk node is still used to get clock rate.
Signed-off-by: Balaji T K
---
drivers/mmc/host/omap_hsmmc.c | 10 --
1 files changed, 0 insertions(+), 10 deletions(-)
diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/
Hi Tomi,
On Wed, Jun 29, 2011 at 9:51 PM, Tomi Valkeinen wrote:
> Hi,
>
> On Wed, 2011-06-29 at 19:08 +0530, K, Mythri P wrote:
>> Hi Tomi,
>
>> As the HDMI PLL , PHY and video blocks are logical blocks it would
>> make sense to have the API's for all and the DSS HDMI (interface
>> driver - user
On Wed, Jun 29, 2011 at 2:34 PM, Tero Kristo wrote:
> PRCM interrupt handler will now parse registered pads to see whether there
> is an active wakeup event. If there is a pending wakeup event, the registered
> ISR will be called.
>
> Signed-off-by: Tero Kristo
> ---
> arch/arm/mach-omap2/prcm.c
On Wed, Jun 29, 2011 at 2:34 PM, Tero Kristo wrote:
> This is no longer needed as it will be handled within serial driver itself.
>
Can be marked as tmp same is done with uart runtime
https://patchwork.kernel.org/patch/862332/
--
Thanks,
Govindraj.R
> Signed-off-by: Tero Kristo
> ---
> arch/
On 6/30/2011 6:11 AM, Russell King - ARM Linux wrote:
> On Wed, Jun 29, 2011 at 11:31:39AM -0700, Stephen Boyd wrote:
>> void __init platform_smp_prepare_cpus(unsigned int max_cpus)
>> {
>> -int i;
>> -
>> /*
>> * Initialise the present map, which describes the set of CPUs
>>
I just had a closer look with a magnifier, it's Class 6.
Regards
Sid.
On 30/06/11 15:43, Gregoire Gentil wrote:
Is your card labeled SDHC or SDXC? Can you give the specs of your card?
Have you tried on Pandaboard?
Grégoire
On Thu, 2011-06-30 at 10:50 +0100, Sid Boyce wrote:
I'm not really lo
It's marked Sandisk microSD HC 32GB. The only view and description of
how it's put together is at
http://www.androidcentral.com/finger-32gb-sandisk-microsd-card where one
reply reckons it's Class 2.
http://www.jigsaw24.com/product-details/x946axa/sandisk-32gb-micro-sd-card
for a much clear phot
From: Jean Pihet
Since cpuidle is a CPU centric framework it decides the MPU
next power state based on the MPU exit_latency and target_residency
figures.
The rest of the power domains get their next power state programmed
from the PM_QOS_DEV_WAKEUP_LATENCY class of the PM QoS framework,
via the
From: Jean Pihet
Implement the devices wake-up latency constraints using a PM QoS
notification handler which applies the constraints to the
underlying layer by calling the corresponding function at hwmod level.
Note: the bus throughput function is implemented but currently is
a no-op. A new PM Q
From: Jean Pihet
Hwmod is queried from the OMAP_PM layer to manage the power domains
wake-up latency constraints. Hwmod retrieves the correct power domain
and if it exists it calls the corresponding power domain function.
Tested on OMAP3 Beagleboard and OMAP4 Pandaboard in RET/OFF using wake-up
From: Vishwanath BS
This patch adds wake up latency numbers for OMAP4. Note that these are
preliminary numbers and need to be relooked.
Signed-off-by: Vishwanath BS
The INACTIVE state is added as unsupported.
Tested on OMAP4 Pandaboard in RET/OFF using wake-up latency constraints on
MPU, CORE
From: Jean Pihet
The powerdomains next states are initialized in pwrdms_setup as a
late_initcall. Because the wake-up constraint can be requested
early in the boot sequence, the power domains next states can be
overwritten by pwrdms_setup.
This patch fixes it by initializing the power domains ne
From: Jean Pihet
Figures are added to the power domains structs.
Note: the figures are preliminary figures. More accurate measurements
are needed. Also the conditions of measurements shall be investigated
and described.
Tested on OMAP3 Beagleboard in RET/OFF using wake-up latency constraints
on
From: Jean Pihet
When a wake-up latency constraint is requested or removed the PM QoS
layer notifies the underlying layer with the updated strongest constraint
value. The constraint is stored in the powerdomain constraints list
and then applied to the corresponding power domain.
The power domains
From: Jean Pihet
Created arch/arm/plat-omap/omap-pm-constraints.c file from
arch/arm/plat-omap/omap-pm-noop.c and the associated Kconfig option
OMAP_PM_CONSTRAINTS.
Signed-off-by: Jean Pihet
---
arch/arm/plat-omap/Kconfig |7 +
arch/arm/plat-omap/Makefile |1
From: Jean Pihet
This patch set is in an RFC state, for review and comments.
In order to implement the new class in PM QoS the following changes have been
made:
1. Add a new PM QoS class for device wake-up constraints
(PM_QOS_DEV_WAKEUP_LATENCY).
Due to the per-device nature of the new class th
From: Jean Pihet
The devices wake-up latency constraints class of PM QoS is
storing the constraints list using the device pm_info struct.
This patch adds the init and de-init of the per-device constraints
list in order to support the dynamic insertion and removal
of the devices in the system.
S
From: Jean Pihet
- add a new PM QoS class PM_QOS_DEV_WAKEUP_LATENCY for device wake-up
constraints. Due to the per-device nature of the new class the constraints
list is stored inside the device dev_pm_info struct instead of the internal
per-class constraints lists.
The new class is only availabl
From: Jean Pihet
Add the field wakeup_lat_plist_head in the struct dev_pm_info
and the initialization of the plist in device_pm_init.
This enables the implementation of per-device constraints in
PM QoS.
Signed-off-by: Jean Pihet
---
drivers/base/power/main.c |3 +++
include/linux/pm.h
On Mon, Jun 27, 2011 at 8:33 PM, Todd Poynor wrote:
> On Fri, Jun 24, 2011 at 04:38:05PM +0200, jean.pi...@newoldbits.com wrote:
> ...
>> + /* Find the associated omap_device for dev */
>> + od = container_of(pdev, struct omap_device, pdev);
>> + if (!od || (od->hwmods_cnt != 1)) {
>>
Hi Mark,
On Mon, Jun 27, 2011 at 3:40 PM, mark gross wrote:
> On Fri, Jun 24, 2011 at 04:37:57PM +0200, jean.pi...@newoldbits.com wrote:
>> From: Jean Pihet
>>
>> This patch set is in an RFC state, for review and comments.
>>
>> In order to implement the new class in PM QoS the following changes
Is your card labeled SDHC or SDXC? Can you give the specs of your card?
Have you tried on Pandaboard?
Grégoire
On Thu, 2011-06-30 at 10:50 +0100, Sid Boyce wrote:
> I'm not really looking for a solution, just supplying some information
> in case anyone is contemplating a >16GB card.
>
> Using
Hi,
Few comments on the .dts data layout below.
* G, Manjunath Kondaiah [110630 02:44]:
> --- a/arch/arm/boot/dts/omap3-beagle-nunchuck.dts
> +++ b/arch/arm/boot/dts/omap3-beagle-nunchuck.dts
> @@ -2,11 +2,6 @@
>
> / {
> i2c@48072000 {
> - compatible = "ti,omap3-i2c";
> -
On Thu, Jun 30, 2011 at 10:01 AM, T Krishnamoorthy, Balaji
wrote:
> On Wed, Jun 29, 2011 at 11:26 PM, Kevin Hilman wrote:
>> "T Krishnamoorthy, Balaji" writes:
>>
>>> On Wed, Jun 29, 2011 at 5:02 AM, Kevin Hilman wrote:
+Rajendra
Balaji T K writes:
> add runtime pm supp
Kevin,
[...]
> > -#endif
> > - default:
> > - continue;
> > - }
> > + if (!bank->suspend_support)
> > + return 0;
>
> Rather than check the flag here in every suspend, don't add a suspend
> method in dev_pm_ops for banks that don't
* gr...@linuxhacker.ru [110614 08:42]:
> From: Oleg Drokin
>
> Machine database already updated:
> http://www.arm.linux.org.uk/developer/machines/list.php?id=3284
>
> Signed-off-by: Oleg Drokin
Russell, do have some immutable branch containing the mach-types changes
that I could pull for my d
* Premi, Sanjeev [110616 06:22]:
> >
> > Hmm, we don't seem to have these in the mainline kernel?
> > Maybe take a look if something still needs to patched
> > there?
>
> [sp] Yes. these don't apply on mainline.
> I believe the kernel is using this patch I submitted [1],
> (or derived
On Wed, Jun 29, 2011 at 11:31:39AM -0700, Stephen Boyd wrote:
> void __init platform_smp_prepare_cpus(unsigned int max_cpus)
> {
> - int i;
> -
> /*
>* Initialise the present map, which describes the set of CPUs
>* actually populated at the present time.
>*/
> -
On Thu, Jun 30, 2011 at 12:50 AM, Kevin Hilman wrote:
> "Munegowda, Keshava" writes:
>
>> On Wed, Jun 29, 2011 at 8:52 PM, Munegowda, Keshava
>> wrote:
>>> On Thu, Jun 2, 2011 at 5:36 AM, Kevin Hilman wrote:
Keshava Munegowda writes:
> From: Keshava Munegowda
>
> The glo
* Arnd Bergmann [110630 04:20]:
> On Thursday 30 June 2011, Tony Lindgren wrote:
>
> The cleanups all look great, with one exception (see below). In the
> future, I'd prefer to get separate pull requests for cleanups and
> bug fixes, but no need to worry about it this time.
Sure no problem.
>
That might have been correct on some ancient
dead language, but I like better when things
are recent.
Fix the alphabetical order.
Signed-off-by: Felipe Balbi
---
Fixed missing comma after Richard's name and removed
comma after Vikram's name.
Thanks Charulatha Varadarajan for spotting those two
That might have been correct on some ancient
dead language, but I like better when things
are recent.
Fix the alphabetical order.
Signed-off-by: Felipe Balbi
---
arch/arm/plat-omap/include/plat/omap_device.h |7 +++
1 files changed, 3 insertions(+), 4 deletions(-)
diff --git a/arch/arm
On Thursday 30 June 2011, Tony Lindgren wrote:
> Hi Arnd & Nico,
>
> Please pull omap clean-up patches from:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap-2.6.git
> devel-cleanup
>
> This branch contains little bit more of omap code shrinkage
> for regulators and PM debug.
I'm not really looking for a solution, just supplying some information
in case anyone is contemplating a >16GB card.
Using Ubuntu 11.04 ARM or x86_64, I cannot create an ext4 partition that
will mount. Doing fsck.ext4 appears to fix the filesystem, but rerunning
fsck.ext4 a second time gives t
simple trivial conversion to threaded_irq.
Signed-off-by: Felipe Balbi
---
drivers/rtc/rtc-twl.c | 10 +-
1 files changed, 1 insertions(+), 9 deletions(-)
diff --git a/drivers/rtc/rtc-twl.c b/drivers/rtc/rtc-twl.c
index f9a2799..eca0502 100644
--- a/drivers/rtc/rtc-twl.c
+++ b/drivers
threads from twl4030's children will be called
nested in the context of the demultiplexing
handler on twl4030-irq.c.
Signed-off-by: Felipe Balbi
---
drivers/mfd/twl4030-irq.c | 11 ++-
1 files changed, 6 insertions(+), 5 deletions(-)
diff --git a/drivers/mfd/twl4030-irq.c b/drivers/mf
... we can do the synchronization with the
hardware when calling bus_sync_unlock as
we're supposed to. While at that, also make
variable names uniform on all functions.
Signed-off-by: Felipe Balbi
---
drivers/mfd/twl4030-irq.c | 82 ++--
1 files changed,
... and do all the synchronization with the
hardware during bus_sync_unlock. We can now
remove all the workqueues.
Signed-off-by: Felipe Balbi
---
drivers/mfd/twl4030-irq.c | 124 +++--
1 files changed, 52 insertions(+), 72 deletions(-)
diff --git a/driv
... and use threaded IRQ infrastructure. Later
patches will come dropping both workqueues and
setting the nested thread flag.
Signed-off-by: Felipe Balbi
---
drivers/mfd/twl4030-irq.c | 94 ++---
1 files changed, 21 insertions(+), 73 deletions(-)
diff -
for doing that, drop the locking and change that
to a mutex.
Signed-off-by: Felipe Balbi
---
drivers/mfd/twl4030-irq.c | 37 +
1 files changed, 21 insertions(+), 16 deletions(-)
diff --git a/drivers/mfd/twl4030-irq.c b/drivers/mfd/twl4030-irq.c
index 7be97c
trivial patch, no functional changes.
Signed-off-by: Felipe Balbi
---
drivers/mfd/twl4030-irq.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/mfd/twl4030-irq.c b/drivers/mfd/twl4030-irq.c
index 8a7ee31..7be97cb 100644
--- a/drivers/mfd/twl4030-irq.c
+++ b/driv
Hi,
the following patches where boot-tested on beagle xM
and everything seems fine. MMC root filesystem still
mounts, /proc/interrupts looks like ps aux | grep irq
shows our threads, etc.
please give it a thorough review as there are places
where I was confused of what to do.
Later patches could
The OMAP I2C driver is modified to use platform_device data from
device tree data structures.
Signed-off-by: G, Manjunath Kondaiah
---
drivers/i2c/busses/i2c-omap.c | 30 +-
1 files changed, 29 insertions(+), 1 deletions(-)
diff --git a/drivers/i2c/busses/i2c-omap
The OMAP4 panda board file is updated to use i2c nodes from device
tree data structures.
Signed-off-by: G, Manjunath Kondaiah
---
arch/arm/mach-omap2/board-omap4panda.c | 22 ++
1 files changed, 22 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/board-omap4
The beagle board file is updated to use i2c nodes from device
tree data structures.
Signed-off-by: G, Manjunath Kondaiah
---
arch/arm/mach-omap2/board-omap3beagle.c | 24
1 files changed, 20 insertions(+), 4 deletions(-)
diff --git a/arch/arm/mach-omap2/board-omap3be
Add I2C and it's child device nodes for beagle board.
The I2C1 controller child devices are not populated and it
should be handled along with OMAP clock changes.
Signed-off-by: G, Manjunath Kondaiah
---
arch/arm/boot/dts/omap4-panda.dts | 57 +
1 files chan
Add I2C and it's child device nodes for beagle board.
The I2C1 controller child devices are not populated and it
should be handled along with OMAP clock changes.
Signed-off-by: G, Manjunath Kondaiah
---
arch/arm/boot/dts/omap3-beagle-nunchuck.dts |5 ---
arch/arm/boot/dts/omap3-beagle.dts
As a part of arm consolidation activity, the OMAP board files needs to
be converted to use device tree.
To begin with, two board files are selected to use device tree for I2C
device registration. The I2C and it's child devices existing on beagle
and panda boards are modified in order to use devic
Hi Samuel,
On Thursday 30 June 2011 10:04:43 Samuel Ortiz wrote:
> I will do that very soon, no worries.
Thank you very much, I'm going to have another series on top of this one
coming, and want to make sure that I'm in the right track.
Thanks,
Péter
--
To unsubscribe from this list: send the l
Hi,
On Thu, Jun 30, 2011 at 08:51:39AM +0300, Tero Kristo wrote:
> On Wed, 2011-06-29 at 18:53 +0200, Balbi, Felipe wrote:
> > Hi,
> >
> > On Wed, Jun 29, 2011 at 12:04:55PM +0300, Tero Kristo wrote:
> > > diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
> > > index 96a762
Hi Arnd & Nico,
Please pull omap clean-up patches from:
git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap-2.6.git
devel-cleanup
This branch contains little bit more of omap code shrinkage
for regulators and PM debug.
It also contains cleanup of irq and timer init code, and some
f
> +/*
> + * This function implements the erratum ID i581 WA:
> + * SDRC state restore before accessing the SDRAM
> + *
> + * Only used at return from non-OFF mode. For OFF
> + * mode the ROM code configures the SDRC and
> + * the DPLL before calling the restore code directly
> + * from DDR.
> + */
Hi Péter,
On Thu, Jun 30, 2011 at 09:15:08AM +0300, Péter Ujfalusi wrote:
> Hi Samuel,
>
> Would you be able to take a look at this series?
> I already have the rebased version on top of linux-omap/devel-cleanup branch
> as Tony requested, and I'm now waiting for your comments.
I will do that ve
On Thursday 30 June 2011 04:53 AM, Kevin Hilman wrote:
Shubhrajyoti D writes:
Currently the fifo depth is set to zero for OMAP4 which disables
the FIFO usage. This patch enables the FIFO usage for I2C transactions
on OMAP4 also.
Do you know the history of why the FIFO depth was set to zero?
Break from dma channel search when a free one is found.
Signed-off-by: Scott Ellis
---
arch/arm/plat-omap/dma.c |5 ++---
1 files changed, 2 insertions(+), 3 deletions(-)
diff --git a/arch/arm/plat-omap/dma.c b/arch/arm/plat-omap/dma.c
index c22217c..3d36fcf 100644
--- a/arch/arm/plat-omap/
Hello all,
I am trying to correct the implementation of the enabling/disabling IO
daisy chain in omap3. I am
following the steps as listed in the OMAP36xx TRM Sec. 3.5.7.2.2 for the same.
Branch: linux-omap-pm: "pm" branch
config: omap2plus_defconfig
Please find the below patch for the same.
---
91 matches
Mail list logo
