On Thu, Sep 22, 2011 at 6:12 AM, Tony Lindgren t...@atomide.com wrote:
* Tarun Kanti DebBarma tarun.ka...@ti.com [110920 03:57]:
The request functions now verify the success of omap_dm_timer_prepare() call
after a timer is acquired. If *_prepare() fails then we have to release the
timer. In
On Thu, Sep 22, 2011 at 6:30 AM, Tony Lindgren t...@atomide.com wrote:
* Tarun Kanti DebBarma tarun.ka...@ti.com [110920 03:57]:
@@ -514,10 +514,23 @@ static int __devinit omap_dm_timer_probe(struct
platform_device *pdev)
timer-irq = irq-start;
timer-pdev = pdev;
- /* Skip
On Thu, Sep 22, 2011 at 6:29 AM, Tony Lindgren t...@atomide.com wrote:
Hi Tarun,
* Tarun Kanti DebBarma tarun.ka...@ti.com [110920 03:57]:
Adaptation of dmtimer code to platform driver using omap_device and
omap_hwmod abstraction. It also include pm-runtime and off-mode support.
I've
Hi,
On Wednesday 21 September 2011 07:04 PM, Hiremath, Vaibhav wrote:
-Original Message-
From: Taneja, Archit
Sent: Friday, September 16, 2011 3:31 PM
To: Hiremath, Vaibhav
Cc: Valkeinen, Tomi; linux-omap@vger.kernel.org; Semwal, Sumit; linux-
me...@vger.kernel.org; Taneja, Archit
On Thu, Sep 22, 2011 at 6:30 AM, Tony Lindgren t...@atomide.com wrote:
* Tarun Kanti DebBarma tarun.ka...@ti.com [110920 03:57]:
Clock is enabled only when timer is started and disabled when the the timer
is stopped. Therefore before accessing registers in functions clock is
enabled
and then
Hi,
On Wed, Sep 21, 2011 at 8:13 PM, Govindraj.R govindraj.r...@ti.com wrote:
Adapts omap-serial driver to use pm_runtime API's.
console_unlock();
- if ((cpu_is_omap34xx() bdata-pads) ||
- (pdata-wk_en pdata-wk_mask))
+ if ((cpu_is_omap34xx()
On Thu, Sep 22, 2011 at 1:18 PM, Ming Lei tom.leim...@gmail.com wrote:
Hi,
On Wed, Sep 21, 2011 at 8:13 PM, Govindraj.R govindraj.r...@ti.com wrote:
Adapts omap-serial driver to use pm_runtime API's.
console_unlock();
- if ((cpu_is_omap34xx() bdata-pads) ||
-
From: Mythri P K mythr...@ti.com
Move the comments in AVI infoframe structure above each parameter
to align with other comments in the header file
Signed-off-by: Mythri P K mythr...@ti.com
---
drivers/video/omap2/dss/ti_hdmi_4xxx_ip.h | 34 ++--
1 files changed, 17
From: Mythri P K mythr...@ti.com
Remove usage of hdmi_reg struct to use u16 instead in the
HDMI IP header file.
Signed-off-by: Mythri P K mythr...@ti.com
---
drivers/video/omap2/dss/ti_hdmi_4xxx_ip.c | 10 +-
drivers/video/omap2/dss/ti_hdmi_4xxx_ip.h | 262 ++---
2
From: Mythri P K mythr...@ti.com
Add some of the missing register definitions, which are h/w indexable.
Signed-off-by: Mythri P K mythr...@ti.com
---
drivers/video/omap2/dss/ti_hdmi_4xxx_ip.h |8
1 files changed, 4 insertions(+), 4 deletions(-)
diff --git
From: Mythri P K mythr...@ti.com
Add support to dump the HDMI regm, regn, and other clock parameters.
Signed-off-by: Mythri P K mythr...@ti.com
---
drivers/video/omap2/dss/dss.c |3 +++
drivers/video/omap2/dss/dss.h |1 +
drivers/video/omap2/dss/hdmi.c | 35
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 +
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 cpuidle_states
structure.
This patch series had been in discussion earlier and
following are the links to the previous
The cpuidle_device-prepare() mechanism causes updates to the
cpuidle_state[].flags, setting and clearing CPUIDLE_FLAG_IGNORE
to tell the governor not to chose a state on a per-cpu basis at
run-time. State demotion is now handled by the driver and it returns
the actual state entered. Hence, this
Cpuidle governor only suggests the state to enter using the
governor-select() interface, but allows the low level driver to
override the recommended state. The actual entered state
may be different because of software or hardware demotion. Software
demotion is done by the back-end cpuidle driver
This is the first step towards global registration of cpuidle
states. The statistics used primarily by the governor are per-cpu
and have to be split from rest of the fields inside cpuidle_state,
which would be made global i.e. single copy. The driver_data field
is also per-cpu and moved.
This patch makes the cpuidle_states structure global (single copy)
instead of per-cpu. The statistics needed on per-cpu basis
by the governor are kept per-cpu. This simplifies the cpuidle
subsystem as state registration is done by single cpu only.
Having single copy of cpuidle_states saves memory.
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: Warn when handler enables interrupts]).
So now
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: Warn when handler enables interrupts]).
So now
From: Mythri P K mythr...@ti.com
With AVI infoframe various parameters of video stream such as
aspect ratio, quantization range, videocode etc will be indicated
from source to sink.Thus AVI information needs to be set/accessed
by the middle ware based on the video content.
Thus this parameter is
From: Mythri P K mythr...@ti.com
Configure the IP to support the limited range and full range quantization
mode. If the full range is configured HDMI transmitter will expand the range
of pixel data from 16-235 to full 8 bit 0-235.
Signed-off-by: Mythri P K mythr...@ti.com
---
From: Mythri P K mythr...@ti.com
Add sysfs support for the uset space to configure limited range or full range
quantization for HDMI.
Signed-off-by: Mythri P K mythr...@ti.com
---
drivers/video/omap2/dss/dss.h |2 +
drivers/video/omap2/dss/dss_features.c |1 +
The hwmod structure of uhh, ohci, ehci and tll are
retrieved and registered with omap device
Signed-off-by: Keshava Munegowda keshava_mgo...@ti.com
Reviewed-by: Partha Basak part...@india.ti.com
---
arch/arm/mach-omap2/usb-host.c | 116 +---
1 files changed,
From: Keshava Munegowda keshava_mgo...@ti.com
The Hwmod structures and Runtime PM features are implemented
For EHCI and OHCI drivers of OMAP3 and OMAP4.
The global suspend/resume of EHCI and OHCI
is validated on OMAP3430 sdp board with these patches.
These patches are re-based to Kevin's pm
From: Benoit Cousson b-cous...@ti.com
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 address,
3. usb_ohci_hs hwmod with irq and base address,
- The ehci and ohci hwmods does not require
From: Keshava Munegowda keshava_mgo...@ti.com
device name usbhs clocks are changed from
usbhs-omap.0 to usbhs_omap; this is because
in the hwmod registration the device name is set
as usbhs_omap; The redudant clock nodes are removed.
Signed-off-by: Keshava Munegowda keshava_mgo...@ti.com
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 address,
3. usb_ohci_hs hwmod with irq and base address,
- the ehci and ohci hwmods does not require functional clock
because
From: Keshava Munegowda keshava_mgo...@ti.com
The usbhs core driver does not enable/disable the interface and
functional clocks; These clocks are handled by hwmod and runtime pm,
hence instead of the clock enable/disable, the runtime pm APIS are
used. however,the port clocks are handled by the
From: Benoit Cousson b-cous...@ti.com
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 address,
3. usb_ohci_hs hwmod with irq and base address,
- The ehci and ohci hwmods does not require
On Thu, 2011-09-22 at 13:37 +0530, mythr...@ti.com wrote:
From: Mythri P K mythr...@ti.com
Add support to dump the HDMI regm, regn, and other clock parameters.
The subjects of this and previous patch seem to be still broken. And
while at it, you could fix missing periods and misplaced spaces
This patch-set gets the kernel booting up on a AM3517 EVM.
The board is able to boot with ramdisk after this,but the MMC and Ethernet
drivers are not up yet. Lots of warnings remain which will be addressed in
subsequent patches.
The patches are tested on master of
In case of AM3517 AM3505, SmartReflex is not applicable so
we must not enable it. So omap3_twl_init() is now not called
when the processor does not support SR.
Signed-off-by: Vaibhav Hiremath hvaib...@ti.com
Signed-off-by: Abhilash K V abhilash...@ti.com
---
arch/arm/mach-omap2/id.c
This patch enables AM35x SoCs to use generic OMAP3 hwmods
(i,e. omap3xxx_hwmods) by allowing am35xx_init_early() to
disable the modules which are not present in AM3517.
Reviewed-by: Sanjeev Premi pr...@ti.com
Signed-off-by: Abhilash K V abhilash...@ti.com
---
arch/arm/mach-omap2/io.c
If PMIC info is not available in omap_vp_init(), abort.
Signed-off-by: Abhilash K V abhilash...@ti.com
---
arch/arm/mach-omap2/vp.c |7 +++
1 files changed, 7 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/vp.c b/arch/arm/mach-omap2/vp.c
index 66bd700..2c99837 100644
---
This patch adds the basic initialization of voltage layer
for AM35x. Since AM35x doesn't support voltage scaling,
Many functions have been defined to plug into existing
voltage layer.
Signed-off-by: Sanjeev Premi pr...@ti.com
Signed-off-by: Abhilash K V abhilash...@ti.com
---
This patch-set fixes the power and voltage management initialization sequence
for AM35x.
These patches are dependent on the following patch-set
[PATCH v4 0/3] AM3517: Booting up
which gets the AM3517 EVM booting.
The patches are tested on master of git://github.com/tmlind/linux.git
Kernel
The current implementation almost assumes that only
TWL4030/TWL5030/TWl6030 are (or can be) used with the
OMAP processors. This is, however, not true.
This patch removes the automatic selection of the PMIC
from Kconfig.
All currently used PMICs are now added to omap2plus_defconfig;
any new PMIC
From: Sanjeev Premi pr...@ti.com
This patch adds support for TPS65023 used with
OMAP3 devices. The PMIC is currently hooked to
AM35x devices, but can easily be extended for
other OMAP3 devices.
Signed-off-by: Sanjeev Premi pr...@ti.com
Signed-off-by: Abhilash K V abhilash...@ti.com
---
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 features are implemented
For EHCI and OHCI drivers of OMAP3 and OMAP4.
The global suspend/resume of EHCI and OHCI
is
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 features are implemented
For EHCI and OHCI drivers of
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 Wednesday 14 September 2011 16:07:39 Joerg Roedel wrote:
Without this
On Wednesday 21 September 2011, Kevin Hilman wrote:
Found. Patch below.
If this one is OK, I'll push to my for_3.2/voltage-cleanup branch (which
is already pulled into arm-soc/next/voltage) so just re-pulling will
pick up the fix.
Looks good to me, it's always nice when a bug fix is also a
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi all,
I would like to clone the linux-omap git tree but git.kernel.org is down.
Is there any backup somewhere ?
Thanks
-- Daniel
- --
http://www.linaro.org/ Linaro.org │ Open source software for ARM SoCs
Follow Linaro:
On Wed, Sep 21, 2011 at 2:58 PM, Yong Zhang yong.zha...@gmail.com wrote:
Since commit [c58543c8: 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
Hi,
You can use https://github.com/tmlind/linux/commits/master.
Regards,
Jean
On Thu, Sep 22, 2011 at 4:47 PM, Daniel Lezcano
daniel.lezc...@linaro.org wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi all,
I would like to clone the linux-omap git tree but git.kernel.org is down.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 09/22/2011 04:53 PM, Jean Pihet wrote:
Hi,
You can use https://github.com/tmlind/linux/commits/master.
Thank you Jean !
- --
http://www.linaro.org/ Linaro.org │ Open source software for ARM SoCs
Follow Linaro:
On Tue, Sep 13, 2011 at 6:32 PM, Tarun Kanti DebBarma
tarun.ka...@ti.com wrote:
This series is continuation of cleanup of OMAP GPIO driver and fixes.
The cleanup include getting rid of cpu_is_* checks wherever possible,
use of gpio_bank list instead of static array, use of unique platform
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 die mpu temperature sensor is also part of this
div_ts_ck feeds only the temperature sensor functional clock
and also has a clksel associated (for divider selection). Mapping this
as well as the bandgap_ts_fclk the fclk of temperature sensor in clkdev table,
so a clk_set_rate() on the div_ts_ck in the driver would have the effect of
changing
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 uniform for all the
versions with different register sets. The data file
contains the structure populated with register offsets
and bit
OMAP4460 specific temperature sensor register bit fields are added.
Existing OMAP4 entries are renamed to OMAP4430.
Signed-off-by: Keerthy j-keer...@ti.com
Cc: t...@atomide.com
---
.../include/mach/ctrl_module_core_44xx.h | 70
1 files changed, 57 insertions(+),
The device file adds the device support for OMAP4 system control module.
Signed-off-by: Keerthy j-keer...@ti.com
Cc: t...@atomide.com
---
arch/arm/mach-omap2/Makefile |1 +
arch/arm/mach-omap2/scm_device.c | 125 ++
arch/arm/plat-omap/Kconfig |
From: Benoit Cousson b-cous...@ti.com
Adding the system control module hwmod.
Signed-off-by: Benoit Cousson b-cous...@ti.com
Signed-off-by: Keerthy j-keer...@ti.com
---
arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 71
1 files changed, 71 insertions(+), 0
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 clocks also.
This is clocks are required of temperature sensor.
Signed-off-by: Vishwanath BS
Arnd Bergmann a...@arndb.de writes:
On Wednesday 21 September 2011, Kevin Hilman wrote:
Found. Patch below.
If this one is OK, I'll push to my for_3.2/voltage-cleanup branch (which
is already pulled into arm-soc/next/voltage) so just re-pulling will
pick up the fix.
Looks good to me,
Tony Lindgren t...@atomide.com writes:
* Kevin Hilman khil...@ti.com [110915 16:23]:
Kevin Hilman khil...@ti.com writes:
Please pull this omap_device cleanup series for v3.2. This sets the
groundwork for Benoit's DT infrastructure work.
Turns out this series has a dependency on a
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 temperature and the thresholds to the user space.
The system
On 9/22/2011 1:28 AM, Deepthi Dharwar wrote:
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 cpuidle_states
structure.
you can consider this series Acked-by:
On chip temperature sensor driver. The driver monitors the temperature of
on die subsystems. It sends notifications to the user space if
the temperature crosses user defined thresholds via kobject_uevent interface.
The user is allowed to configure the temperature thresholds vis sysfs nodes
exposed
On Thu, 2011-09-22 at 13:36 -0400, Keerthy wrote:
On chip temperature sensor driver. The driver monitors the temperature of
on die subsystems. It sends notifications to the user space if
the temperature crosses user defined thresholds via kobject_uevent interface.
The user is allowed to
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 address,
3. usb_ohci_hs hwmod with irq and base address,
- the ehci
Hi
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 address,
3. usb_ohci_hs hwmod with irq and base address,
- The ehci and ohci hwmods
* Pedanekar, Hemant hema...@ti.com [110921 17:00]:
Tony Lindgren wrote on Thursday, September 22, 2011 2:11 AM:
* Hemant Pedanekar hema...@ti.com [110921 10:05]:
--- a/arch/arm/mach-omap2/board-ti8168evm.c
+++ b/arch/arm/mach-omap2/board-ti8168evm.c
@@ -37,16 +37,16 @@ static void
+ Chase
Hi
On Thu, 22 Sep 2011, Abhilash K V wrote:
This patch enables AM35x SoCs to use generic OMAP3 hwmods
(i,e. omap3xxx_hwmods) by allowing am35xx_init_early() to
disable the modules which are not present in AM3517.
Reviewed-by: Sanjeev Premi pr...@ti.com
Signed-off-by: Abhilash K V
Hi Paul,
On 9/22/2011 8:14 PM, Paul Walmsley wrote:
Hi
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 address,
3. usb_ohci_hs hwmod with irq
Hi,
On Thu, Sep 22, 2011 at 10:28 AM, Deepthi Dharwar
deep...@linux.vnet.ibm.com wrote:
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 cpuidle_states
structure.
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 cpuidle_states
structure.
I reviewed earlier versions of the
Hi Tarun,
DebBarma, Tarun Kanti tarun.ka...@ti.com writes:
On Tue, Sep 13, 2011 at 6:32 PM, Tarun Kanti DebBarma
tarun.ka...@ti.com wrote:
This series is continuation of cleanup of OMAP GPIO driver and fixes.
The cleanup include getting rid of cpu_is_* checks wherever possible,
use of
Hi Kevin,
This is the updated version of the initial series that introduced a
notifier in order to create an omap_device from a platform_device bound
to DT node as suggested by Grant.
For the moment, the informations are all extracted from the hwmod data.
The idea is to focus first on the
Split the omap_device_build_ss into two smaller functions
that will allow to populate a platform_device already allocated by
device-tree.
The functionality of the omap_device_build_ss is still the same, but
the omap_device_alloc will be usable with devices already built by
device-tree.
Add a notifier called during device_add phase. If an of_node is present,
retrieve the hwmod entry in order to populate properly the omap_device
structure.
For the moment the resource from the device-tree are overloaded.
DT does not support named resource yet, and thus, most driver
will not work
This series moves the OMAP CPUfreq driver into drivers/cpufreq, add
support for SMP devices (OMAP4+) and includes several cleanups and
fixes from Nishanth Menon.
This series applies to v3.1-rc6, and is available here:
git://github.com/khilman/linux-omap-pm.git for_3.2/omap-cpufreq
Kevin
From: Santosh Shilimkar santosh.shilim...@ti.com
Move OMAP cpufreq driver from arch/arm/mach-omap2 into
drivers/cpufreq, along with a few cleanups:
- generalize support for better handling of different SoCs in the OMAP
- use OPP layer instead of OMAP clock internals for frequency table init
From: Todd Poynor toddpoy...@google.com
Enable all CPUs in the shared policy in the CPU init callback.
Otherwise, the governor CPUFREQ_GOV_START event is invoked with
a policy that only includes the first CPU, leaving other CPUs
uninitialized by the governor.
Signed-off-by: Todd Poynor
From: Russell King rmk+ker...@arm.linux.org.uk
On OMAP SMP configuartion, both processors share the voltage
and clock. So both CPUs needs to be scaled together and hence
needs software co-ordination.
Also, update lpj with reference value to avoid progressive error.
Adjust _both_ the per-cpu
From: Nishanth Menon n...@ti.com
Clk name does'nt need to dynamically detected during clk init.
move them off to driver initialization, if we dont have a clk name,
there is no point in registering the driver anyways. The actual clk
get and put is left at cpu_init and exit functions.
From: Nishanth Menon n...@ti.com
if we do not have mpu_dev we normally fail in cpu_init. It is better
to fail driver registration if the devices are not available.
Signed-off-by: Nishanth Menon n...@ti.com
Signed-off-by: Kevin Hilman khil...@ti.com
---
drivers/cpufreq/omap-cpufreq.c | 15
From: Nishanth Menon n...@ti.com
OMAP2+ all have frequency tables, hence the hacks we had for older
silicon do not need to be carried forward. As part of this change,
use cpufreq_frequency_table_target to find the best match for
frequency requested.
Signed-off-by: Nishanth Menon n...@ti.com
From: Nishanth Menon n...@ti.com
OMAP2 is the only family using clk_[init|exit]_cpufreq_table, however,
the cpufreq code does not currently use clk_init_cpufreq_table. As a
result, it is unusuable for OMAP2 and only usable only on platforms
using OPP library.
Remove the unbalanced
From: Nishanth Menon n...@ti.com
We use a single frequency table for multiple CPUs. But, with
OMAP4, since we have multiple CPUs, the cpu_init call for CPU1
causes freq_table previously allocated for CPU0 to be overwritten.
In addition, we dont free the table on exit path.
We solve this by
From: Colin Cross ccr...@google.com
Sometimes, bootloaders starts up with a frequency which is not
in the OPP table. At cpu_init, policy-cur contains the frequency
we pick at boot. It is possible that system might have fixed
it's boot frequency later on as part of power initialization.
After
From: Nishanth Menon n...@ti.com
Release the mpu_clk in fail paths.
Reported-by: Todd Poynor toddpoy...@google.com
Signed-off-by: Nishanth Menon n...@ti.com
Signed-off-by: Kevin Hilman khil...@ti.com
---
drivers/cpufreq/omap-cpufreq.c | 14 +++---
1 files changed, 11 insertions(+), 3
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
---
Paul, this patch has a dependency on the OMAP CPUFreq driver
move/cleanup series just posted.
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 SR.
...I don't think this is right. DVFS using the PMIC is still
Abhilash K V abhilash...@ti.com writes:
If PMIC info is not available in omap_vp_init(), abort.
Signed-off-by: Abhilash K V abhilash...@ti.com
Looks good, some minor nitpicking below...
---
arch/arm/mach-omap2/vp.c |7 +++
1 files changed, 7 insertions(+), 0 deletions(-)
diff
* Kevin Hilman khil...@ti.com [110922 13:35]:
From: Santosh Shilimkar santosh.shilim...@ti.com
Move OMAP cpufreq driver from arch/arm/mach-omap2 into
drivers/cpufreq, along with a few cleanups:
- generalize support for better handling of different SoCs in the OMAP
- use OPP layer instead
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 AM35xx).
This should still be a separate patch, with justification. More on this
below.
2.
Abhilash K V abhilash...@ti.com writes:
The current implementation almost assumes that only
almost? ;)
TWL4030/TWL5030/TWl6030 are (or can be) used with the
OMAP processors. This is, however, not true.
This patch removes the automatic selection of the PMIC
from Kconfig.
All currently
* Kevin Hilman khil...@ti.com [110922 14:30]:
Abhilash K V abhilash...@ti.com writes:
The current implementation almost assumes that only
almost? ;)
TWL4030/TWL5030/TWl6030 are (or can be) used with the
OMAP processors. This is, however, not true.
This patch removes the
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 patch says AM35x doesn't support voltage scaling, and the next
Kevin Hilman khil...@ti.com writes:
From: Russell King rmk+ker...@arm.linux.org.uk
On OMAP SMP configuartion, both processors share the voltage
and clock. So both CPUs needs to be scaled together and hence
needs software co-ordination.
[...]
diff --git a/drivers/cpufreq/omap-cpufreq.c
Hi
On Thu, 22 Sep 2011, Cousson, Benoit wrote:
ADDR_TYPE_RT is mainly use for sysconfig access inside hwmod core today, so
why should we use it in this case?
Just for consistency, since the flag isn't defined to be
SYSCONFIG-specific.
That way, if there's another need -- other than
Hi Keshava
so based on a closer look at how the EHCI/OHCI IP blocks are actually
implemented on OMAP, they should not have hwmod entries associated with
them. Please take a look at
http://marc.info/?l=linux-omapm=131673433121673w=2
- Paul
--
To unsubscribe from this list: send the line
Hi
so as
http://marc.info/?l=linux-omapm=131673433121673w=2
mentions, these should either be associated with the UHH IP block, or
handled by code in arch/arm/mach-omap2/usb-host.c, since the EHCI and OHCI
IP blocks are created by the OMAP USB host MFD driver.
- Paul
--
To unsubscribe
Hi Kevin
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
---
Paul, this patch has a dependency on
Tarun Kanti DebBarma tarun.ka...@ti.com writes:
This series is continuation of cleanup of OMAP GPIO driver and fixes.
The cleanup include getting rid of cpu_is_* checks wherever possible,
use of gpio_bank list instead of static array, use of unique platform
specific value associated data
Hi
On Thu, 22 Sep 2011, Paul Walmsley wrote:
On Thu, 22 Sep 2011, Cousson, Benoit wrote:
ADDR_TYPE_RT is mainly use for sysconfig access inside hwmod core today, so
why should we use it in this case?
Just for consistency, since the flag isn't defined to be
SYSCONFIG-specific.
That
Tony Lindgren wrote on Thursday, September 22, 2011 11:51 PM:
* Pedanekar, Hemant hema...@ti.com [110921 17:00]:
Tony Lindgren wrote on Thursday, September 22, 2011 2:11 AM:
* Hemant Pedanekar hema...@ti.com [110921 10:05]:
--- a/arch/arm/mach-omap2/board-ti8168evm.c
+++
Hi Guenter,
Thanks for your quick review comments.
On Thu, Sep 22, 2011 at 11:20 PM, Guenter Roeck
guenter.ro...@ericsson.com wrote:
On Thu, 2011-09-22 at 13:36 -0400, Keerthy wrote:
On chip temperature sensor driver. The driver monitors the temperature of
on die subsystems. It sends
[...]
This series is continuation of cleanup of OMAP GPIO driver and fixes.
The cleanup include getting rid of cpu_is_* checks wherever possible,
use of gpio_bank list instead of static array, use of unique platform
specific value associated data member to OMAP platforms to avoid
cpu_is_*
1 - 100 of 109 matches
Mail list logo
