On Fri, 2011-09-23 at 11:22 +0530, K, Mythri P wrote:
- What is dcofreq? Looking at the code, it tells if the pixel clock is
1000MHz. Why is such a field needed, can't the HDMI driver manage that
itself? And if it's needed, why is it called dcofreq, the name doesn't
make much sense to
+ Benoît
Hi,
On Thu, 22 Sep 2011, Keerthy wrote:
From: Benoit Cousson b-cous...@ti.com
Adding the system control module hwmod.
Have the autogeneration scripts been updated ?
Signed-off-by: Benoit Cousson b-cous...@ti.com
Signed-off-by: Keerthy j-keer...@ti.com
- Paul
On Thu, 22 Sep 2011, Paul Walmsley wrote:
On Thu, 22 Sep 2011, Kevin Hilman wrote:
Now that we have OPP layer, and OMAP CPUfreq driver is using it, we no
longer need/use the clock framework code for filling up CPUfreq
tables. Remove it.
Signed-off-by: Kevin Hilman khil...@ti.com
Hi
On Thu, 22 Sep 2011, Keerthy wrote:
The patch series adds support of system control module device and adds support
temperature sensor. The patch series adds hwmod for system control module
and enables the clocks for temperature sensor. The OMAP4460 specific register
set data for the on
Hi,
On Fri, Sep 23, 2011 at 11:31 AM, Tomi Valkeinen tomi.valkei...@ti.com wrote:
On Fri, 2011-09-23 at 11:22 +0530, K, Mythri P wrote:
- What is dcofreq? Looking at the code, it tells if the pixel clock is
1000MHz. Why is such a field needed, can't the HDMI driver manage that
itself?
Hi
some comments:
On Thu, 22 Sep 2011, Keerthy wrote:
The system control module has several components. On die temperature is a part
of system control module. The system control module driver registers the
temperature sensor as a client. A hwmon driver for temperature sensor to
route the
On Fri, 2011-09-23 at 12:10 +0530, K, Mythri P wrote:
Hi,
On Fri, Sep 23, 2011 at 11:31 AM, Tomi Valkeinen tomi.valkei...@ti.com
wrote:
On Fri, 2011-09-23 at 11:22 +0530, K, Mythri P wrote:
- What is dcofreq? Looking at the code, it tells if the pixel clock is
1000MHz. Why is such
On Thu, Sep 22, 2011 at 09:48:27AM -0400, Felipe Contreras wrote:
On Tue, Sep 20, 2011 at 1:54 PM, Laurent Pinchart
laurent.pinch...@ideasonboard.com wrote:
On Tuesday 20 September 2011 12:01:46 Roedel, Joerg wrote:
On Sat, Sep 17, 2011 at 08:02:22PM -0400, Laurent Pinchart wrote:
On
Kevin,
-Original Message-
From: linux-arm-kernel-boun...@lists.infradead.org [mailto:linux-
arm-kernel-boun...@lists.infradead.org] On Behalf Of Kevin Hilman
Sent: Friday, September 23, 2011 2:37 AM
To: cpuf...@vger.kernel.org; Dave Jones
Cc: Nishanth Menon;
Hi Tony,
[...]
I've applied these into dmtimer branch with some changes to simplify
things further. I've also merged it into linux-omap master branch
for further testing.
I'll reply to your patches with the changes I've done. Care give the
dmtimer branch a try and see if I've missed
From: Mythri P K mythr...@ti.com
Add support to dump the HDMI PLL dividers such as regm, regn etc
and other clock dumps such as pixel clock rate, TMDS clock rate.
changes since V2:
Add pixel clock and TMDS clock dump and remove dcofreq and DISPC clock source
print.
Signed-off-by: Mythri P K
On Thu, Sep 22, 2011 at 11:31 PM, Paul Walmsley p...@pwsan.com wrote:
Hi
a few comments
On Thu, 22 Sep 2011, Keshava Munegowda wrote:
following 4 hwmod structures are added
1. usb_host_hs hwmod of usbhs with uhh base address and functional clock,
2. usb_ehci_hs hwmod with irq and base
On Fri, 2011-09-23 at 15:02 +0530, mythr...@ti.com wrote:
From: Mythri P K mythr...@ti.com
Add support to dump the HDMI PLL dividers such as regm, regn etc
and other clock dumps such as pixel clock rate, TMDS clock rate.
changes since V2:
Add pixel clock and TMDS clock dump and remove
On Friday 23 September 2011 01:15 AM, Kevin Hilman wrote:
Deepthi Dharwar deep...@linux.vnet.ibm.com writes:
The following patch series implements global registration of cpuidle
states, and also has the necessary data structure changes to
accommodate the per-cpu writable members of the
Hi,
On Fri, Sep 23, 2011 at 4:15 PM, Tomi Valkeinen tomi.valkei...@ti.com wrote:
On Fri, 2011-09-23 at 15:02 +0530, mythr...@ti.com wrote:
From: Mythri P K mythr...@ti.com
Add support to dump the HDMI PLL dividers such as regm, regn etc
and other clock dumps such as pixel clock rate, TMDS
From: Mythri P K mythr...@ti.com
Add support to dump the HDMI wrapper, core, PLL and PHY registers
through debugfs.
Signed-off-by: Mythri P K mythr...@ti.com
---
drivers/video/omap2/dss/core.c|4 +
drivers/video/omap2/dss/dss.h |1 +
So I'd suggest one of two approaches:
1. If the pin muxing can follow the PM runtime status of the UHH IP block,
then the pin mux data should be associated with the UHH hwmod.
No, the mux is applicable only to ehci and ohci , where as
sysconfig is applicable to uhh ( usb_host_hs class).
From: Laurent Pinchart [laurent.pinch...@ideasonboard.com]
Sent: Wednesday, September 21, 2011 2:36 PM
To: Ravi, Deepthy
Cc: mche...@infradead.org; t...@atomide.com; Hiremath, Vaibhav;
linux-me...@vger.kernel.org; li...@arm.linux.org.uk;
hi Kevin
On Fri, Sep 23, 2011 at 4:00 AM, Hilman, Kevin wrote:
Hi Abhilash,
Abhilash K V abhilash...@ti.com writes:
This patch adds the basic initialization of voltage layer
for AM35x. Since AM35x doesn't support voltage scaling,
I must admit to still being confused by this series.
This
Hello,
Following set contains the version 9 of this work. This patch set contains
a number of patches tagged as 'TEMP', they are only meant for testing
purposes and to provide proof of concept. Most of the 'TEMP' patches are
related to UART runtime handling and they will be replaced by work done
From: R, Govindraj govindraj.r...@ti.com
Add API to enable IO pad wakeup capability based on mux dynamic pad and
wake_up enable flag available from hwmod_mux initialization.
Use the wakeup_enable flag and enable wakeup capability
for the given pads. Wakeup capability will be enabled/disabled
From: R, Govindraj govindraj.r...@ti.com
Add API to determine IO-PAD wakeup event status for a given
hwmod dynamic_mux pad.
Signed-off-by: Govindraj.R govindraj.r...@ti.com
---
arch/arm/mach-omap2/mux.c| 30 ++
arch/arm/mach-omap2/mux.h
Introduce a chained interrupt handler mechanism for the PRCM
interrupt, so that individual PRCM event can cleanly be handled by
handlers in separate drivers. We do this by introducing PRCM event
names, which are then matched to the particular PRCM interrupt bit
depending on the specific OMAP SoC
PM interrupt handling is now done through the PRCM chain handler. The
interrupt handling logic is also split in two parts, to server IO and
WKUP events separately. This allows us to handle IO chain events in a
clean way.
Signed-off-by: Tero Kristo t-kri...@ti.com
---
arch/arm/mach-omap2/pm34xx.c
Temporary testing related patch, not meant for integration.
Signed-off-by: Tero Kristo t-kri...@ti.com
---
arch/arm/mach-omap2/board-4430sdp.c | 12 +---
1 files changed, 1 insertions(+), 11 deletions(-)
diff --git a/arch/arm/mach-omap2/board-4430sdp.c
This is handled automatically by the PRCM chain interrupt mechanism now.
Signed-off-by: Tero Kristo t-kri...@ti.com
---
arch/arm/mach-omap2/pm34xx.c |4
1 files changed, 0 insertions(+), 4 deletions(-)
diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
index
Prevents a hang when omap_device would want to print something for
serial console device while enabling / disabling its clocks.
Should be handled properly by serial runtime PM support.
Signed-off-by: Tero Kristo t-kri...@ti.com
Cc: Govindraj.R govindraj.r...@ti.com
---
These are no longer needed as omap_hwmod takes care of multiplexing of pads.
Should be handled properly with serial runtime PM support patches.
Signed-off-by: Tero Kristo t-kri...@ti.com
Cc: Govindraj.R govindraj.r...@ti.com
---
arch/arm/mach-omap2/serial.c | 25 +
1
This patch is just a temporary hack to allow serial to work properly with
the PRCM chain handler. Should be replaced with a proper implementation
by serial runtime PM support.
Signed-off-by: Tero Kristo t-kri...@ti.com
Cc: Govindraj.R govindraj.r...@ti.com
---
arch/arm/mach-omap2/serial.c |
This is no longer needed as it will be handled within serial driver itself.
This part should be properly handled with serial runtime support.
Signed-off-by: Tero Kristo t-kri...@ti.com
Cc: Govindraj.R govindraj.r...@ti.com
---
arch/arm/mach-omap2/pm34xx.c | 19 ---
1 files
Just for PRCM chain handler testing purposes. This should be replaced with
a proper implementation.
Signed-off-by: Tero Kristo t-kri...@ti.com
---
arch/arm/mach-omap2/serial.c | 71 -
1 files changed, 69 insertions(+), 2 deletions(-)
diff --git
OMAP PRM driver is initialized based on availability of PRM hwmods.
This patch will sequentially check for a list of known PRM hwmods and
will add an omap device if any is found.
Signed-off-by: Tero Kristo t-kri...@ti.com
---
arch/arm/mach-omap2/devices.c | 46
Temporary patch for testing purposes, not meant for integration.
Signed-off-by: Tero Kristo t-kri...@ti.com
---
arch/arm/mach-omap2/mux.c |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/mux.c b/arch/arm/mach-omap2/mux.c
index b27c061..642fe3f 100644
These are needed because runtime PM is disabled during suspend, and
it is bad if we get interrupts from the PRCM chain handler during it.
Now, PRCM interrupt forwarding is disabled until the suspend-complete,
which makes sure that all the needed drivers are up.
Signed-off-by: Tero Kristo
This driver will eventually support OMAP soc PRM module features, e.g. PRCM
chain interrupts and voltage processor / controller. This patch only adds
basic skeleton for the driver that can be probed for omap3 and omap4.
Signed-off-by: Tero Kristo t-kri...@ti.com
Cc: Paul Walmsley p...@pwsan.com
OMAP mux now provides a service routine to parse pending wakeup events
and to call registered ISR whenever active wakeups are detected. This
routine is called directly from PRCM interrupt handler.
Signed-off-by: Tero Kristo t-kri...@ti.com
---
arch/arm/mach-omap2/mux.c | 38
This patch is temporary until Paul can provide a final version.
Signed-off-by: Tero Kristo t-kri...@ti.com
Cc: Paul Walmsley p...@pwsan.com
---
arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 56
1 files changed, 56 insertions(+), 0 deletions(-)
diff --git
hi Kevin,
On Fri, Sep 23, 2011 at 3:05 PM, Hilman, Kevin wrote:
Abhilash K V abhilash...@ti.com writes:
In case of AM3517 AM3505, SmartReflex is not applicable so
we must not enable it.
This part is fine, but...
So omap3_twl_init() is now not called when the processor does not
support
This patch is temporary until Benoit can provide final version.
Signed-off-by: Tero Kristo t-kri...@ti.com
Cc: Benoit Cousson b-cous...@ti.com
---
arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 65
1 files changed, 65 insertions(+), 0 deletions(-)
diff --git
On Fri, Sep 23, 2011 at 11:28 AM, Paul Walmsley p...@pwsan.com wrote:
On Fri, 23 Sep 2011, J, KEERTHY wrote:
On Fri, Sep 23, 2011 at 10:48 AM, Paul Walmsley p...@pwsan.com wrote:
On Thu, 22 Sep 2011, Keerthy wrote:
---
arch/arm/mach-omap2/clock44xx_data.c | 4 ++--
1 files
hi Kevin
Thanks for reviewing the patch.
On Fri, Sep 23, 2011 at 3:25 AM, Hilman, Kevin wrote:
Abhilash K V abhilash...@ti.com writes:
This patch-set adds support for suspension to RAM and
resumption on the AM3517. This includes:
1. Patch to disable dynamic sleep (as it is not supported
On Fri, Sep 23, 2011 at 11:33 AM, Paul Walmsley p...@pwsan.com wrote:
Hi
some comments
On Thu, 22 Sep 2011, Keerthy wrote:
The register set and the
bit fields might vary across OMAP versions. Hence
creating a structure comprising of all the registers
and bit fields to make the driver
On Fri, Sep 23, 2011 at 11:45 AM, Paul Walmsley p...@pwsan.com wrote:
+ Benoît
Hi,
On Thu, 22 Sep 2011, Keerthy wrote:
From: Benoit Cousson b-cous...@ti.com
Adding the system control module hwmod.
Have the autogeneration scripts been updated ?
The hwmod is autogenerated. I have taken
Paul Walmsley p...@pwsan.com writes:
On Thu, 22 Sep 2011, Paul Walmsley wrote:
On Thu, 22 Sep 2011, Kevin Hilman wrote:
Now that we have OPP layer, and OMAP CPUfreq driver is using it, we no
longer need/use the clock framework code for filling up CPUfreq
tables. Remove it.
Vishwanath Sripathy vishwanath...@ti.com writes:
[...]
+#ifdef CONFIG_CPU_FREQ_DEBUG
+pr_info(cpufreq-omap: transition: %u -- %u\n, freqs.old,
freqs.new);
+#endif
+
+ret = clk_set_rate(mpu_clk, freqs.new * 1000);
Do you plan to post follow up patches to scale voltage along with
Now that we have OPP layer, and OMAP CPUfreq driver is using it, we no
longer need/use the clock framework code for filling up CPUfreq
tables. Remove it.
Signed-off-by: Kevin Hilman khil...@ti.com
---
arch/arm/mach-omap2/clkt2xxx_virt_prcm_set.c | 80 --
Koyamangalath, Abhilash abhilash...@ti.com writes:
[...]
@@ -485,6 +489,8 @@ console_still_active:
int omap3_can_sleep(void)
{
+ if (cpu_is_omap3505() || cpu_is_omap3517())
+ return 0;
This needs to be a separate patch with a descriptive changelog and
justification as
Hi Abhilash,
Koyamangalath, Abhilash abhilash...@ti.com writes:
On Fri, Sep 23, 2011 at 4:00 AM, Hilman, Kevin wrote:
Hi Abhilash, Abhilash K V abhilash...@ti.com writes:
This patch adds the basic initialization of voltage layer for
AM35x. Since AM35x doesn't support voltage scaling,
I must
Munegowda, Keshava keshava_mgo...@ti.com writes:
On Thu, Sep 22, 2011 at 7:02 PM, Ming Lei tom.leim...@gmail.com wrote:
Hi,
On Thu, Sep 22, 2011 at 7:37 PM, Keshava Munegowda
keshava_mgo...@ti.com wrote:
From: Keshava Munegowda keshava_mgo...@ti.com
The Hwmod structures and Runtime PM
Hi,
On Thu, Sep 22 2011, Yong Zhang wrote:
Since commit [e58aa3d2: genirq: Run irq handlers with interrupts disabled],
We run all interrupt handlers with interrupts disabled
and we even check and yell when an interrupt handler
returns with interrupts enabled (see commit [b738a50a:
genirq:
Hi
On Thu, 22 Sep 2011, Paul Walmsley wrote:
On Thu, 22 Sep 2011, Keerthy wrote:
From: Vishwanath BS vishwanath...@ti.com
OMAP4460 specific clocks are not getting added as the
cpu_is_omap44xx is choosing only OMAP4430 specific clock nodes.
Changing it to add to OMAP4460 specific
Hi Tony, Grant,
Here is the first set of patches to add device-tree support for OMAP3+
platforms.
That series mainly adds a minimal OMAP2+ generic board file for basic
DT support on OMAP2420, OMAP2430, OMAP3, OMAP4 and beyond. The goal is
to remove even the minimal static devices init in order
Add initial device-tree support for OMAP4 SoC.
This is based on the original panda board patch done by Manju:
http://permalink.gmane.org/gmane.linux.ports.arm.omap/60393
Add the generic GIC interrupt-controller from ARM.
Add an empty soc node to contain non memory mapped IPs
(DSP, MPU, IPU...).
Add SoC specific map_io function to be used by the generic DT
board file. This is an intermediate step before having some
generic DT aware map_io function.
Signed-off-by: Benoit Cousson b-cous...@ti.com
Cc: Tony Lindgren t...@atomide.com
---
arch/arm/mach-omap2/common.c | 18
Based on the original omap4-panda.dts file from Manju.
http://www.spinics.net/lists/linux-omap/msg55836.html
Add memory information and a default bootargs to allow
a boot from RAMDISK.
Signed-off-by: Benoit Cousson b-cous...@ti.com
Cc: Grant Likely grant.lik...@secretlab.ca
Cc: G, Manjunath
Add initial OMAP3 soc file with empty ocp bus.
Based on initial patch from Manju:
http://www.spinics.net/lists/linux-omap/msg55830.html
Signed-off-by: Benoit Cousson b-cous...@ti.com
Cc: Grant Likely grant.lik...@secretlab.ca
Cc: G, Manjunath Kondaiah manj...@ti.com
---
Add OMAP3 beagleboard DTS file to use the omap3.dtsi
SoC file.
Add a default bootargs line to allow a boot from RAMDISK
Add memory node information.
Signed-off-by: Benoit Cousson b-cous...@ti.com
Cc: G, Manjunath Kondaiah manj...@ti.com
---
arch/arm/boot/dts/omap3-beagle.dts | 29
Add the SDP/Blaze (Software Development Board) support with
device tree.
That file is based on the omap4-panda.dts.
Signed-off-by: Benoit Cousson b-cous...@ti.com
Cc: Grant Likely grant.lik...@secretlab.ca
Cc: G, Manjunath Kondaiah manj...@ti.com
---
arch/arm/boot/dts/omap4-sdp.dts | 29
Still needed to boot until the i2c twl driver is adapted to
device-tree. Otherwise the voltage control code will try to
access the twl and crash.
Signed-off-by: Benoit Cousson b-cous...@ti.com
Cc: Tony Lindgren t...@atomide.com
---
arch/arm/mach-omap2/board-generic.c | 41
Re-cycle the original board-generic file to support Device Tree
for every OMAP2+ variants.
Note: Since it is a completely new content in the existing file
I removed the original copyright.
The current approach is an intermediate step before having only
one machine descriptor that will use some
Add device-tree support for the l3-noc driver.
Use platform_driver_register to defer the probing at device init
time.
Add documentation for the l3-noc bindings.
Signed-off-by: Benoit Cousson b-cous...@ti.com
Cc: Tony Lindgren t...@atomide.com
Cc: Santosh Shilimkar santosh.shilim...@ti.com
---
Used the main OCP node to add bindings with the l3_noc driver.
Remove l3_noc static device creation if DT is populated.
Signed-off-by: Benoit Cousson b-cous...@ti.com
Cc: Tony Lindgren t...@atomide.com
Cc: Santosh Shilimkar santosh.shilim...@ti.com
---
arch/arm/boot/dts/omap4.dtsi |3 ++-
Add nodes for devices used by PM code (mpu, dsp, iva).
Add an empty cpus node as well as recommended in the DT spec.
Remove mpu, dsp, iva devices init if dt is populated.
Signed-off-by: Benoit Cousson b-cous...@ti.com
Cc: Grant Likely grant.lik...@secretlab.ca
Cc: Kevin Hilman khil...@ti.com
Hi Arnd,
Please pull omap cleanup branch again from:
git://github.com/tmlind/linux.git cleanup
This contains a fix for earlier cleanup patches and has omap_device
cleanup and PM cleanup merged in.
As some of the later cleanup was based on a -rc6 while the
earlier branch was based on -rc4, the
On Fri, 23 Sep 2011 15:46:08 +0300, Tero Kristo said:
Following set contains the version 9 of this work. This patch set contains
a number of patches tagged as 'TEMP', they are only meant for testing
purposes and to provide proof of concept. Most of the 'TEMP' patches are
related to UART
* Benoit Cousson b-cous...@ti.com [110923 12:50]:
Used the main OCP node to add bindings with the l3_noc driver.
Remove l3_noc static device creation if DT is populated.
--- a/arch/arm/mach-omap2/devices.c
+++ b/arch/arm/mach-omap2/devices.c
@@ -16,6 +16,7 @@
#include linux/clk.h
#include
* Benoit Cousson b-cous...@ti.com [110923 12:50]:
Add SoC specific map_io function to be used by the generic DT
board file. This is an intermediate step before having some
generic DT aware map_io function.
Thanks, I'll apply this into cleanup branch and with the related
conversion of board
* Benoit Cousson b-cous...@ti.com [110923 12:50]:
Re-cycle the original board-generic file to support Device Tree
for every OMAP2+ variants.
Note: Since it is a completely new content in the existing file
I removed the original copyright.
I'd suggest just keeping it, maybe just update the
* Benoit Cousson b-cous...@ti.com [110923 12:50]:
Still needed to boot until the i2c twl driver is adapted to
device-tree. Otherwise the voltage control code will try to
access the twl and crash.
That sounds OK to me for now. For merging these patches, how
about the following:
- Kevin queues
On Fri, Sep 23, 2011 at 10:23:11PM +0200, Benoit Cousson wrote:
Based on the original omap4-panda.dts file from Manju.
http://www.spinics.net/lists/linux-omap/msg55836.html
Add memory information and a default bootargs to allow
a boot from RAMDISK.
Signed-off-by: Benoit Cousson
On Fri, Sep 23, 2011 at 10:23:19PM +0200, Benoit Cousson wrote:
Add nodes for devices used by PM code (mpu, dsp, iva).
Add an empty cpus node as well as recommended in the DT spec.
Remove mpu, dsp, iva devices init if dt is populated.
Signed-off-by: Benoit Cousson b-cous...@ti.com
Cc:
On Fri, Sep 23, 2011 at 04:12:08PM -0700, Tony Lindgren wrote:
* Benoit Cousson b-cous...@ti.com [110923 12:50]:
Still needed to boot until the i2c twl driver is adapted to
device-tree. Otherwise the voltage control code will try to
access the twl and crash.
That sounds OK to me for
[...]
After debugging this myself a bit, here's what I think may be going on.
This may not be the only problem but here's at least one of them.
First, debounce clocks are disabled in the runtime_suspend callback.
When a GPIO is freed and it's the last one in the bank, bank-mod_usage
goes to
Hi Valdis.Kletnieks,
On Sat, Sep 24, 2011 at 3:53 AM, valdis.kletni...@vt.edu wrote:
On Fri, 23 Sep 2011 15:46:08 +0300, Tero Kristo said:
Following set contains the version 9 of this work. This patch set contains
a number of patches tagged as 'TEMP', they are only meant for testing
purposes
On Sat, 24 Sep 2011 10:54:29 +0530, Sripathy, Vishwanath said:
UART Runtime patches are already posted for review and it's also
targeted for next merge window. Our intention is to push both the
features together for next merge window.
Oh, OK. That should work then. Thanks for the
75 matches
Mail list logo
