* Paul Walmsley p...@pwsan.com [120608 06:33]:
On Fri, 8 Jun 2012, Cousson, Benoit wrote:
On 6/8/2012 3:11 AM, Paul Walmsley wrote:
On Thu, 7 Jun 2012, Cousson, Benoit wrote:
Indeed, what I did not mention is that potentially the whole device
init should be done ondemand as
* Paul Walmsley p...@pwsan.com [120608 18:35]:
On Thu, 7 Jun 2012, Tony Lindgren wrote:
Oh OK yeah makes sense as that's hwmod internal function. Then the driver
specific part should use just void __iomem *base and use readl/writel and
live under include/linux/platform_data/omap-usb.h.
Hi,
Few comments below on making the platform_data work better along
with other archs.
* Paul Walmsley p...@pwsan.com [120610 17:56]:
Enable the AESS auto-gating control bit during AESS hwmod setup. This
fixes the following boot warning on OMAP4:
...
--- /dev/null
+++
Hi,
Similar comments to the asess patch on this one below.
* Paul Walmsley p...@pwsan.com [120610 17:57]:
--- /dev/null
+++ b/include/linux/platform_data/fsusb.h
This would be better as include/linux/platform_data/omap-usb.h.
+#include plat/omap_hwmod.h
This include should not be needed
* Vaibhav Hiremath hvaib...@ti.com [120609 08:00]:
Newly added AM33XX device falls under omap2 class, so
make cpu_class_is_omap2() true for AM33XX
(Add soc_is_am33xx() check).
Signed-off-by: Vaibhav Hiremath hvaib...@ti.com
---
arch/arm/plat-omap/include/plat/cpu.h |2 +-
1 files
* Felipe Balbi ba...@ti.com [120608 07:16]:
twl[46]030 have been converted to sparse IRQ
already, so we can remove the unused defines
and drop some code from board-files.
Nice :)
drivers/mtd/chips/cfi_cmdset_0001.c: In function 'cfi_intelext_write_words':
include/linux/mtd/map.h:331:11:
On 6/11/2012 12:08 PM, Tony Lindgren wrote:
* Vaibhav Hiremath hvaib...@ti.com [120609 08:00]:
Newly added AM33XX device falls under omap2 class, so
make cpu_class_is_omap2() true for AM33XX
(Add soc_is_am33xx() check).
Signed-off-by: Vaibhav Hiremath hvaib...@ti.com
---
* Vaibhav Hiremath hvaib...@ti.com [120610 23:49]:
On 6/11/2012 12:08 PM, Tony Lindgren wrote:
* Vaibhav Hiremath hvaib...@ti.com [120609 08:00]:
Newly added AM33XX device falls under omap2 class, so
make cpu_class_is_omap2() true for AM33XX
(Add soc_is_am33xx() check).
Signed-off-by:
Paul,
Ping. These could be queued for the next merge window.
Tomi
On Thu, 2012-05-10 at 13:21 +0300, Tomi Valkeinen wrote:
Hi,
These patches fix DSS hwmod data related to sysc flags. I haven't seen any
problem produced by these missing bits, but by looking at the TRM it's clear
that they
On Sun, Jun 10, 2012 at 11:34:17PM -0700, Tony Lindgren wrote:
Hi,
Similar comments to the asess patch on this one below.
* Paul Walmsley p...@pwsan.com [120610 17:57]:
--- /dev/null
+++ b/include/linux/platform_data/fsusb.h
This would be better as
* Felipe Balbi ba...@ti.com [120611 00:19]:
On Sun, Jun 10, 2012 at 11:34:17PM -0700, Tony Lindgren wrote:
Hi,
Similar comments to the asess patch on this one below.
* Paul Walmsley p...@pwsan.com [120610 17:57]:
--- /dev/null
+++ b/include/linux/platform_data/fsusb.h
This
Hi,
On Mon, Jun 11, 2012 at 12:41:33AM -0700, Tony Lindgren wrote:
This should be static inline int fsusb_reset_host_controller as it's
in a header.
why is it even in a header ? Only hwmod_fsusb_preprogram() will use it
anyway.
Well ideally it would be something that any OHCI
* Felipe Balbi ba...@ti.com [120611 00:55]:
Hi,
On Mon, Jun 11, 2012 at 12:41:33AM -0700, Tony Lindgren wrote:
This should be static inline int fsusb_reset_host_controller as it's
in a header.
why is it even in a header ? Only hwmod_fsusb_preprogram() will use it
anyway.
On Sun, 10 Jun 2012, Tony Lindgren wrote:
* Paul Walmsley p...@pwsan.com [120608 06:33]:
I don't really have a huge problem with switching to a late reset,
but there are disadvantages to it.
I think the early reset actually has more disadvantages to it compared
to driver reset. We
On Mon, Jun 11, 2012 at 10:20:49AM +0530, Vinod Koul wrote:
I think it is a good idea. And I would like to extend it even a little
bit. Do we have any users of peripheral to peripheral slave dma?
IIRC that is not the case, or does anyone know of existence or plans
for such a h/w?
If not,
Hi Paul,
So why should getting rid of some *unused* data have any testing
overhead?
Your definition of 'unused' seems to be different than mine:
$ egrep -rn 'c(lk|)-clkdm' arch/arm/
arch/arm/mach-omap2/omap_hwmod.c:560: if (oh-_clk-clkdm
oh-_clk-clkdm-flags CLKDM_NO_AUTODEPS)
On 6/8/2012 9:10 PM, Hiremath, Vaibhav wrote:
On Fri, Jun 08, 2012 at 01:33:46, Paul Walmsley wrote:
Hi
On Thu, 7 Jun 2012, Hiremath, Vaibhav wrote:
I couldn't finish my testing today, got into continuous meetings.
No worries, I understand.
Tomorrow, I will test it and update you on
On Mon, Jun 11, 2012 at 01:03:42AM -0700, Tony Lindgren wrote:
* Felipe Balbi ba...@ti.com [120611 00:55]:
Hi,
On Mon, Jun 11, 2012 at 12:41:33AM -0700, Tony Lindgren wrote:
This should be static inline int fsusb_reset_host_controller as it's
in a header.
why is it even
On 6/11/2012 6:50 AM, Paul Walmsley wrote:
Hi Vaibhav, Afzal, Tony,
On Mon, 21 May 2012, Paul Walmsley wrote:
From: Vaibhav Hiremath hvaib...@ti.com
Currently dummy voltage domain data is being created
in order to succeed boot process, nothing has been done
w.r.t actual hardware
Hi Paul,
On 6/11/2012 10:04 AM, Paul Walmsley wrote:
On Sun, 10 Jun 2012, Tony Lindgren wrote:
* Paul Walmsley p...@pwsan.com [120608 06:33]:
I don't really have a huge problem with switching to a late reset,
but there are disadvantages to it.
I think the early reset actually has more
Hey,
can anybody give me a quick wrap-up about the current state of AM33xx
based SoCs in mainline? What are the next steps to get things merged?
I'm getting involved in a project that is based on a AM3352 and would
like to provide help where necessary and wanted.
Thanks,
Daniel
--
To
On 6/11/2012 2:46 AM, Paul Walmsley wrote:
The 32k sync timer IP block target idle modes are incorrect in the
hwmod data are incorrect.
Nit: Is there too many incorrect in this sentence?
The IP block does not support any
smart-idle modes. Update the data to reflect the correct modes.
This
On Mon, Jun 11, 2012 at 10:20:49AM +0530, Vinod Koul wrote:
On Sun, 2012-06-10 at 12:22 +0100, Russell King - ARM Linux wrote:
On Sun, Jun 10, 2012 at 07:19:47PM +0800, Barry Song wrote:
2012/6/10 Russell King - ARM Linux li...@arm.linux.org.uk:
Dan, Vinod,
There's a change I
On 6/11/2012 2:46 AM, Paul Walmsley wrote:
Resolve this kernel boot message:
omap_hwmod: mcpdm: cannot be enabled for reset (3)
It appears that the McPDM on OMAP4 can only receive its functional
clock from an off-chip source. This source is not guaranteed to be
present on the board, and when
As omap1 and omap2 will never be compiled together, due to
different compiler flags, so we can simply make
cpu_class_is_omap2() = true, for all non-omap1 platforms.
Signed-off-by: Vaibhav Hiremath hvaib...@ti.com
---
arch/arm/plat-omap/include/plat/cpu.h |3 +--
1 files changed, 1
Add gpmc hwmod and associated interconnect data
HWMOD_INIT_NO_RESET can be removed once kernel is updated to
configure GPMC for all peripherals. Currently many depend on
bootloader, this facility will be removed.
(feature-removal-schedule.txt will get updated in upcoming
gpmc series).
No reset
From: Daniel Mack zon...@gmail.com
Hey,
can anybody give me a quick wrap-up about the current state of AM33xx
based SoCs in mainline? What are the next steps to get things merged?
There is a wiki page [1] that is intended to provide a summary, but I'm
confident it is not up-to-date. There is
Add one-register-per-pin type device tree based pinctrl driver.
Currently this driver only works on omap2+ series of processors,
where there is either an 8 or 16-bit padconf register for each pin.
Support for other similar pinmux controllers can be added.
Signed-off-by: Tony Lindgren
These patches fix misc problems when reflash ti-omap3530evm for
master branch on Linux-omap. Currently they have been tested on
3530evm but were not ack'ed.
Most of them are the leftovers from the great original developers
with my the latest updates for adapting to the current kernel, so
I add
Signed-off-by: Vaibhav Hiremath hvaib...@ti.com
Tested-by: Zumeng Chen zumeng.c...@gmail.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
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
A typo fix for this cosmetic change and mute a failed message from
a unnecessary setting of some parent clk for usbhs_omap on OMAP3EVM.
Signed-off-by: Zumeng Chen zumeng.c...@gmail.com
---
drivers/mfd/omap-usb-host.c |4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git
If we don't set proper debouce time for ads7846, then there are
flooded interrupt counters of ads7846 responding to one time
touch on screen, so the driver couldn't work well.
And since most OMAP3 series boards pass NULL pointer of board_pdata
to omap_ads7846_init, so it's more proper to set it
On 6/11/2012 2:58 PM, Daniel Mack wrote:
Hey,
can anybody give me a quick wrap-up about the current state of AM33xx
based SoCs in mainline? What are the next steps to get things merged?
Daniel,
We are in the process of submitting all baseport patches to the
upstream, summary would be,
Hi,
Objective of this series is to make things easy for GPMC driver
conversion series by separating out more things from driver
conversion series.
This series,
1. Unifies NAND platform initialization functions
2. Cleans up OneNAND platform code a little
3. Handles additional timings in Kernel
Helper function for updating nand platform data has been
added the capability to take timing structure arguement.
Usage of omap_nand_flash_init() has been replaced by modifed
one, omap_nand_flash_init was doing things similar to
board_nand_init except that NAND CS# were being acquired
based on
Reorganize gpmc-onenand initialization so that changes
required for gpmc driver migration can be made smooth.
Ensuring sync read/write are disabled in onenand cannot be
expect to work properly unless GPMC is setup, this has been
removed. Two instances of doing the same has been clubbed
into one
Configure busturnaround, cycle2cycledelay, waitmonitoringtime,
clkactivationtime in gpmc_cs_set_timings(). This is done so
that boards can configure these parameters of gpmc in Kernel
instead of relying on bootloader.
Signed-off-by: Afzal Mohammed af...@ti.com
---
arch/arm/mach-omap2/gpmc.c
-Original Message-
From: Jason Kridner [mailto:jkrid...@gmail.com]
Sent: Monday, June 11, 2012 9:51 AM
To: Daniel Mack; Tony Lindgren; Hilman, Kevin; Paul Walmsley; Hiremath,
Vaibhav; Hernandez, Carlos; Maupin, Chase
Cc: linux-omap@vger.kernel.org;
Hi,
This is input subsystem, add Dmitry and linux-input.
On 06/11/12 17:00, Zumeng Chen wrote:
If we don't set proper debouce time for ads7846, then there are
flooded interrupt counters of ads7846 responding to one time
touch on screen, so the driver couldn't work well.
And since most
Hi,
This series is based on 3.5-rc1, and is dependent on [1,2,3]
This series has been tested on omap3evm (smsc911x) rev G C and
beagle board(nand) using patch series which is going to be posted
shortly (this series only creates a driver out of GPMC code)
Also using private patches, nand
gpmc driver platform definitions
Signed-off-by: Afzal Mohammed af...@ti.com
---
arch/arm/plat-omap/include/plat/gpmc.h | 49
1 file changed, 49 insertions(+)
diff --git a/arch/arm/plat-omap/include/plat/gpmc.h
b/arch/arm/plat-omap/include/plat/gpmc.h
index
Create API for platforms to adapt gpmc to HWMOD
Signed-off-by: Afzal Mohammed af...@ti.com
---
arch/arm/mach-omap2/gpmc.c | 31 +++
arch/arm/plat-omap/include/plat/gpmc.h |2 ++
2 files changed, 33 insertions(+)
diff --git
A driver is being created out of GPMC code. This is being
attempted to acheive by not breaking existing interface,
necessitating requirement of GPMC peripherals being able
to work with as well as without the help of driver. To not
break existing, initcall is required as in old interface
GPMC is
Create a minimal driver out of gpmc code.
Responsibilities handled by earlier gpmc
initialization is now achieved in probe.
Signed-off-by: Afzal Mohammed af...@ti.com
---
arch/arm/mach-omap2/gpmc.c | 170
1 file changed, 123 insertions(+), 47
Helpers for propulating given resource structure
with memory interrupt information.
Signed-off-by: Afzal Mohammed af...@ti.com
---
arch/arm/mach-omap2/gpmc.c | 45
1 file changed, 45 insertions(+)
diff --git a/arch/arm/mach-omap2/gpmc.c
Helper for configuring given CS based on flags.
Signed-off-by: Afzal Mohammed af...@ti.com
---
arch/arm/mach-omap2/gpmc.c | 33
arch/arm/plat-omap/include/plat/gpmc.h |5 +
2 files changed, 38 insertions(+)
diff --git
Helper for setting GPMC timing by taking input as register values.
Signed-off-by: Afzal Mohammed af...@ti.com
---
arch/arm/mach-omap2/gpmc.c | 43 +++
1 file changed, 43 insertions(+)
diff --git a/arch/arm/mach-omap2/gpmc.c b/arch/arm/mach-omap2/gpmc.c
Some of the timing configuration like extra delay
has bool type configurations. Provide a helper so
that these too can be configured in Kernel.
Signed-off-by: Afzal Mohammed af...@ti.com
---
arch/arm/mach-omap2/gpmc.c | 55
1 file changed, 55
Some of the GPMC peripherals depend on bootloader to do the
configuration. This facility is deprecated, notify user
about the present GPMC settings inform that that relying
on bootloader for GPMC setting is deprecated.
Signed-off-by: Afzal Mohammed af...@ti.com
---
arch/arm/mach-omap2/gpmc.c |
Helper for configuring waitpin. There are two parts to it;
configuring at CS level and the other at device level.
A device embedding multiple CS has been provided the
capability to use same waitpin (different waitpins has not
been supported as presently there are no GPMC peripherals
doing so)
Platform will provide driver with configuration details for
each CS like configuration, timing, interrupts. Setup GPMC
based on it. Platform data also provides platform data
resources used for connected peripheral (eg. gpio irq).
GPMC driver tunnels those information to respective driver.
Helper for reconfiguring CS, peripheral that necessitated
it was OneNAND.
Signed-off-by: Afzal Mohammed af...@ti.com
---
arch/arm/mach-omap2/gpmc.c | 32
arch/arm/plat-omap/include/plat/gpmc.h |2 ++
2 files changed, 34 insertions(+)
diff --git
GPMC has dedicated NAND handling blocks and have a few
registers exclusively meant for NAND operations. These
registers can be handled by OMAP NAND driver as it is
meant for handling NAND on GPMC. Update OMAP NAND
platform data with GPMC-NAND register details so that
OMAP NAND driver can handle by
GPMC has a writeprotect pin that can be connected to
peripherals. If any CS wants to enable writeprotect,
writeprotect will be enabled, once CS configurations
are finished.
Signed-off-by: Afzal Mohammed af...@ti.com
---
arch/arm/mach-omap2/gpmc.c | 20
1 file changed, 20
On 06/11/2012 09:00 AM, Zumeng Chen wrote:
These patches fix misc problems when reflash ti-omap3530evm for
master branch on Linux-omap. Currently they have been tested on
3530evm but were not ack'ed.
Most of them are the leftovers from the great original developers
with my the latest
On 06/11/2012 09:00 AM, Zumeng Chen wrote:
Signed-off-by: Vaibhav Hiremath hvaib...@ti.com
Tested-by: Zumeng Chen zumeng.c...@gmail.com
I think that you need to have something in the changelog above, even if
this is a trivial change.
---
arch/arm/mach-omap2/board-omap3evm.c | 39
Tomi,
So at this point, are you OK with deferring a split of the DMM until it
necessary to do so (if ever)? I'd like to get this patch in so that people
have a working omapdrm device when they enable the config options.
Regards,
Andy
--
To unsubscribe from this list: send the line unsubscribe
On 06/11/2012 09:00 AM, Zumeng Chen wrote:
A typo fix for this cosmetic change and mute a failed message from
a unnecessary setting of some parent clk for usbhs_omap on OMAP3EVM.
Signed-off-by: Zumeng Chen zumeng.c...@gmail.com
---
drivers/mfd/omap-usb-host.c |4 +++-
1 files
On Mon, 2012-06-11 at 09:51 -0500, Gross, Andy wrote:
Tomi,
So at this point, are you OK with deferring a split of the DMM until
it necessary to do so (if ever)? I'd like to get this patch in so
that people have a working omapdrm device when they enable the config
options.
Yes, I'm ok
Hi,
This series provides new interface for GPMC peripherals that use
helper functions for initialization and configures omap3evm
beagleboard GPMC in Kernel. Existing interface would continue to
serve its purpose as before.
New interface for smsc911x has been provided the runtime timing
Currently gpmc is configured in platform for nand. As now
gpmc driver is present, populate details needed for the
driver to configure gpmc, gpmc driver would configure based
on this information. Old interface has been left as is so
that platforms can continue configuring gpmc using old
interface
Currently gpmc is configured in platform for various flash
devices. As gpmc driver is now present, populate details
needed for the driver to configure gpmc, gpmc driver would
configure based on this information. Old interface has been
left as is so that platforms can continue configuring gpmc
Currently gpmc is configured in platform for tusb6010. As
gpmc driver is now present, populate details needed for the
driver to configure gpmc, gpmc driver would configure based
on this information. Old interface has been left as is so
that platforms can continue configuring gpmc using old
Currently gpmc is configured in platform for smc91x. As now
gpmc driver is present, populate details needed for the
driver to configure gpmc, gpmc driver would configure based
on this information. Old interface has been left as is so
that platforms can continue configuring gpmc using old
interface
OMAP Peripherals using SMSC911X driver were not configured
in Kernel. Here timing has been calculated so that it is
runtime configurable. As different SMSC devices like 9115,
9220, 9221 can be used with smsc911x driver, option has been
given for the boards to provide timing as per the part used,
gpmc code has been converted to driver. Modify the board
code to provide gpmc driver with required information
Signed-off-by: Afzal Mohammed af...@ti.com
---
arch/arm/mach-omap2/board-omap3evm.c | 12 +++-
1 file changed, 11 insertions(+), 1 deletion(-)
diff --git
gpmc code has been converted to driver. Modify the board
code to provide gpmc driver with required information
Signed-off-by: Afzal Mohammed af...@ti.com
---
arch/arm/mach-omap2/board-omap3beagle.c | 16 ++--
1 file changed, 14 insertions(+), 2 deletions(-)
diff --git
Currently gpmc is configured in platform for smsc911x. As
gpmc driver is now present, populate details needed for the
driver to configure gpmc, gpmc driver would configure based
on this information. Old interface has been left as is so
that platforms can continue configuring gpmc using old
Hi,
Changes compared to previous version:
- moved basic omap4 pm errata support from dev-off set to this one
- changed ordering of patches a bit (core ret enabled at last patch)
- dropped DSP reset hack patch from set, as it is no longer needed
- added arch specific hwmod_ops support, needed for
Added similar PM errata flag support as omap3 has. This should be used
in similar manner, set the flags during init time, and check the flag
values during runtime.
Signed-off-by: Tero Kristo t-kri...@ti.com
---
arch/arm/mach-omap2/pm.h |7 +++
arch/arm/mach-omap2/pm44xx.c |1 +
2
On OMAP4 most modules/hwmods support module level context status. On
OMAP3 and earlier, we relied on the power domain level context status.
Identify all modules that don't support 'context_offs' by marking the
offset as USHRT_MAX. Rest have a valid 'context_offs' populated in
.prcm structure
From: Rajendra Nayak rna...@ti.com
OMAP4 has module specific context lost registers which makes it now
possible to have module level context loss count, instead of relying
on the powerdomain level context count.
Add 2 private hwmod api's to update/clear the hwmod/module specific
context lost
From: Santosh Shilimkar santosh.shilim...@ti.com
On OMAP4+ devices, GIC register context is lost when MPUSS hits
the OSWR(Open Switch Retention). On the CPU wakeup path, ROM code
gets executed and one of the steps in it is to restore the
saved context of the GIC. The ROM Code GIC distributor
From: Rajendra Nayak rna...@ti.com
Remove the FIXME's in the suspend sequence since
we now intend to support system level RET support.
Signed-off-by: Rajendra Nayak rna...@ti.com
Signed-off-by: Tero Kristo t-kri...@ti.com
[Jean Pihet j-pi...@ti.com: ported on top of the functional power
states]
On OMAP4, there is no support to read previous logic state
or previous memory state achieved when a power domain transitions
to RET. Instead there are module level context registers.
In order to support the powerdomain level logic/mem_off_counters
on OMAP4, instead use the previous power state
Signed-off-by: Tero Kristo t-kri...@ti.com
---
arch/arm/mach-omap2/pm44xx.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/pm44xx.c b/arch/arm/mach-omap2/pm44xx.c
index 1e845e8..eb3e073 100644
--- a/arch/arm/mach-omap2/pm44xx.c
+++
Hi Afzal,
On 06/11/2012 09:01 AM, Afzal Mohammed wrote:
Helper function for updating nand platform data has been
added the capability to take timing structure arguement.
Usage of omap_nand_flash_init() has been replaced by modifed
one, omap_nand_flash_init was doing things similar to
On Wed, May 23, 2012 at 3:08 PM, Andy Gross andy.gr...@ti.com wrote:
Register OMAP DRM/KMS platform device. DMM is split into a
separate device using hwmod.
Signed-off-by: Andy Gross andy.gr...@ti.com
Signed-off-by: Rob Clark rob.cl...@linaro.org
---
arch/arm/mach-omap2/Makefile
On Sun, Jun 10, 2012 at 11:10:47AM +0530, Shubhrajyoti Datta wrote:
On Fri, Jun 1, 2012 at 4:29 AM, Kevin Hilman khil...@ti.com wrote:
Shubhrajyoti D shubhrajy...@ti.com writes:
The patch series does the following
- Warn fixes if CONFIG_PM_RUNTIME is not selected.
- In case of i2c
On Tue, Jun 05, 2012 at 04:20:00PM +0300, Tomi Valkeinen wrote:
Hi,
On Tue, 2012-06-05 at 01:22 -0700, Tony Lindgren wrote:
* Russell King - ARM Linux li...@arm.linux.org.uk [120603 11:05]:
Looks like the DSS stuff has broken OMAP builds again during this
merge window:
On Wed, Jun 06, 2012 at 12:58:00AM -0700, Tony Lindgren wrote:
* Tomi Valkeinen tomi.valkei...@ti.com [120605 06:24]:
Hi,
On Tue, 2012-06-05 at 01:22 -0700, Tony Lindgren wrote:
* Russell King - ARM Linux li...@arm.linux.org.uk [120603 11:05]:
Looks like the DSS stuff has broken
Hi Vaibhav,
On Mon, 11 Jun 2012, Vaibhav Hiremath wrote:
I think this is not required, since Tony has already accepted the patch
which has this implementation (available on linux-omap/master).
Please refer to the commit,
commit 08f3098928c991560408e8c71d4af8b1a3ff2d67
Author: Afzal
On Mon, 11 Jun 2012, Cousson, Benoit wrote:
On 6/11/2012 10:04 AM, Paul Walmsley wrote:
But if the IP blocks are reset later, and the bootloader or previous OS
gets some register settings wrong, there's a greater risk of system
instability or unpredictable behavior during the boot
Hi Paul,
On 6/11/2012 2:46 AM, Paul Walmsley wrote:
Until the OMAP4 code is converted to disable the use of the clock
framework-based clockdomain enable/disable sequence, any clock used as
a hwmod main_clk must have a clockdomain associated with it.
But why? The clock domain information is
Hi Paul,
Here is the serie to fix wrong clkdm for the PRCM hwmods.
I did revert as well the patch to make the cm_clkdm and prm_clkdm
common since it does not exist on OMAP4.
I do not thinks it exists in OMAP2 and 3 either, and thus that series should
probably be extended with the total removal
The following commit (794b480a37e3d284d6ee7344d8a737ef60476ed5) was adding
the PRCM IPs data for PRCM, CM, PRCM_MPU and SCRM.
The clkdm entry are not the correct ones and does not exist in the system.
Replace them with the proper wkup, l4_ao and l4_cfg.
Fix as well the wrong OCP port used by the
This reverts commit 6ba5a69ee92c29c2ffc814dad6ac61c4cd49090c.
Conflicts:
arch/arm/mach-omap2/Makefile
Neither prm_clkdm nor cm_clkdm does exist on OMAP4.
Remove the common definition that does not make sense anymore
since it is not common for OMAP2+ platforms.
Please note that these
On Mon, 11 Jun 2012, Cousson, Benoit wrote:
In fact, neither prm_clkdm not cm_clkdm are valid clock domain on OMAP4
:-(.
I've just realized that you introduced that for 3.5, but this is wrong.
We should not start adding some fake clock domains just because the fmwk
is not smart enough
On Mon, 2012-06-11 at 17:06 +0100, Russell King - ARM Linux wrote:
On Tue, Jun 05, 2012 at 04:20:00PM +0300, Tomi Valkeinen wrote:
Hi,
On Tue, 2012-06-05 at 01:22 -0700, Tony Lindgren wrote:
* Russell King - ARM Linux li...@arm.linux.org.uk [120603 11:05]:
Looks like the DSS stuff
On Mon, 2012-06-11 at 17:09 +0100, Russell King - ARM Linux wrote:
On Wed, Jun 06, 2012 at 12:58:00AM -0700, Tony Lindgren wrote:
Tomi, please have your patches sitting in linux next for at least a
week before they get merged. That usually shakes down bugs like these
before the merge
On 6/11/2012 9:40 PM, Paul Walmsley wrote:
Hi Vaibhav,
On Mon, 11 Jun 2012, Vaibhav Hiremath wrote:
I think this is not required, since Tony has already accepted the patch
which has this implementation (available on linux-omap/master).
Please refer to the commit,
commit
On Mon, 11 Jun 2012, Benoit Cousson wrote:
The following commit (794b480a37e3d284d6ee7344d8a737ef60476ed5) was adding
the PRCM IPs data for PRCM, CM, PRCM_MPU and SCRM.
The clkdm entry are not the correct ones and does not exist in the system.
Replace them with the proper wkup, l4_ao and
On Mon, 11 Jun 2012, Benoit Cousson wrote:
Neither prm_clkdm nor cm_clkdm does exist on OMAP4.
Remove the common definition that does not make sense anymore
since it is not common for OMAP2+ platforms.
Please note that these clock domains are probably non existant
on OMAP 2 3 and thus
On Monday 11 June 2012 09:30 PM, Wolfram Sang wrote:
Agree,
These are only fixes can it be considered for rc3?
Baking in linux-next and considering rc3 don't match; baking needs
time, rc3 is soon. I've put the patches now into my -next branch for
more exposure.
Thanks.
I am still uncertain
On Fri, Jun 08, 2012 at 04:24:32PM +0100, Jon Hunter wrote:
Hi Will,
Hi Jon,
Here is an updated version. I was going to send out a V3, but I wanted
to wait to see if others had more comments first.
This looks better to me, so I took it for a spin on my 4460 (thanks Nicolas!)
and noticed that
Hi Afzal,
On 06/11/2012 09:01 AM, Afzal Mohammed wrote:
Reorganize gpmc-onenand initialization so that changes
required for gpmc driver migration can be made smooth.
Ensuring sync read/write are disabled in onenand cannot be
expect to work properly unless GPMC is setup, this has been
Hi Afzal,
On 06/11/2012 09:02 AM, Afzal Mohammed wrote:
Configure busturnaround, cycle2cycledelay, waitmonitoringtime,
clkactivationtime in gpmc_cs_set_timings(). This is done so
that boards can configure these parameters of gpmc in Kernel
instead of relying on bootloader.
What boards have
Hi Will,
On 06/11/2012 12:39 PM, Will Deacon wrote:
On Fri, Jun 08, 2012 at 04:24:32PM +0100, Jon Hunter wrote:
Hi Will,
Hi Jon,
Here is an updated version. I was going to send out a V3, but I wanted
to wait to see if others had more comments first.
This looks better to me, so I took
Hi Afzal,
On 06/11/2012 09:26 AM, Afzal Mohammed wrote:
Create API for platforms to adapt gpmc to HWMOD
Signed-off-by: Afzal Mohammed af...@ti.com
---
arch/arm/mach-omap2/gpmc.c | 31 +++
arch/arm/plat-omap/include/plat/gpmc.h |2 ++
2 files
1 - 100 of 110 matches
Mail list logo
