From: Mythri P K mythr...@ti.com
HDMI IP block is common between TI OMAP4 Procerssor and Netra processor although
the Display subsytem is different.Also the IP block in future OMAP may differ
from the one existing in OMAP4. Thus to reuse the code between these two
processors , and maintain the
From: Mythri P K mythr...@ti.com
Define new HDMI timings structure to replace the OMAP DSS timing strucutre in
hdmi.c to have the HDMI include defintion out of DSS.
Signed-off-by: Mythri P K mythr...@ti.com
---
drivers/video/omap2/dss/hdmi.c | 22 +++---
From: Mythri P K mythr...@ti.com
As the pll and the video configuration info are part of the ip_data those
structures are moved to the ip_data strtucure.Also the functions are modified
accordingly to take care of this movement.
Signed-off-by: Mythri P K mythr...@ti.com
---
From: Mythri P K mythr...@ti.com
Clean up to move the EDID definition to hdmi.c from the header file which is IP
dependent.
Signed-off-by: Mythri P K mythr...@ti.com
---
drivers/video/omap2/dss/hdmi.c | 10 ++
drivers/video/omap2/dss/hdmi.h | 10 --
2 files changed, 10
From: Mythri P K mythr...@ti.com
Some of the header file definitions of HDMI IP are needed by audio driver thus
moving the common defintion to more generic Include/video.
Signed-off-by: Mythri P K mythr...@ti.com
---
drivers/video/omap2/dss/dss.h | 10 -
drivers/video/omap2/dss/hdmi.c |
From: Mythri P K mythr...@ti.com
Instead of DSS knowing of the interior IP driver function provide
a wrapper API to configure.
Signed-off-by: Mythri P K mythr...@ti.com
---
drivers/video/omap2/dss/hdmi.c|8
drivers/video/omap2/dss/hdmi_ti_4xxx_ip.c | 11 ---
From: Mythri P K mythr...@ti.com
As the base_address of the HDMI might differ across SoC's, offset of the HDMI
logical blocks and base address got from the platform data are passed
dynamically to the functions that modify HDMI IP registers.
Signed-off-by: Mythri P K mythr...@ti.com
---
From: Mythri P K mythr...@ti.com
Functions that are included in the generic video include of HDMI TI OMAP4, TI8xx
etc IP library is renamed to have IP specific names so that it will not conflict
with similar function from other IP.
Signed-off-by: Mythri P K mythr...@ti.com
---
From: Mythri P K mythr...@ti.com
To make the current hdmi DSS driver compatible with future OMAP with different
IP blocks , add HDMI as a feature in dss_features and abstract the internal
function in hdmi dss driver.
Signed-off-by: Mythri P K mythr...@ti.com
---
From: Mythri P K mythr...@ti.com
As the panel driver will remain generic across OMAP's renaming it to
hdmi_panel.c
Signed-off-by: Mythri P K mythr...@ti.com
---
drivers/video/omap2/dss/Makefile |2 +-
.../omap2/dss/{hdmi_omap4_panel.c = hdmi_panel.c} |0
2 files
From: Mythri P K mythr...@ti.com
Splitting HDMI IP dependent IP configuring code from HDMI DSS dependent code and
moving to a new IP file.
Signed-off-by: Mythri P K mythr...@ti.com
---
drivers/video/omap2/dss/Makefile |2 +-
drivers/video/omap2/dss/hdmi.c
Hi Kevin,
Sorry for bit late reply, I've been on holiday during last 3 weeks.
On Sat, 2011-08-06 at 01:37 +0200, Hilman, Kevin wrote:
Tero Kristo t-kri...@ti.com writes:
All voltagedomains that have support for vc and vp are now automatically
registered with SMPS regulator driver.
On Fri, 2011-08-05 at 23:54 +0200, Hilman, Kevin wrote:
Tero Kristo t-kri...@ti.com writes:
All voltagedomains that have support for vc and vp are now automatically
registered with SMPS regulator driver. Voltage.c builds a platform device
structure for this purpose during late init.
On Fri, 2011-08-05 at 23:52 +0200, Hilman, Kevin wrote:
Tero Kristo t-kri...@ti.com writes:
All voltagedomains that have support for vc and vp are now automatically
registered with SMPS regulator driver. Voltage.c builds a platform device
structure for this purpose during late init.
Hi,
On Mon, Aug 29, 2011 at 11:01:54AM +0530, Gupta, Ajay Kumar wrote:
diff --git a/drivers/usb/musb/musb_core.c
b/drivers/usb/musb/musb_core.c index 20a2873..07f3faf 100644
--- a/drivers/usb/musb/musb_core.c
+++ b/drivers/usb/musb/musb_core.c
@@ -1014,7 +1014,9 @@ static void
On Sun, Aug 28, 2011 at 09:51:10PM -0400, Alan Stern wrote:
Hmmm. Although the semantics of the various mb() macros were
originally defined only for inter-CPU synchronization, I believe they
are also supposed to work for guaranteeing the order of accesses to
DMA-coherent memory. If that's
On Saturday 27 August 2011 04:36 AM, Kevin Hilman wrote:
Shubhrajyoti Dshubhrajy...@ti.com writes:
Under some error conditions the i2c driver may do a reset.
Adding a reset field and support in the device-specific code.
Signed-off-by: Shubhrajyoti Dshubhrajy...@ti.com
Needs update/rebase to
On Saturday 27 August 2011 04:41 AM, Kevin Hilman wrote:
Shubhrajyoti Dshubhrajy...@ti.com writes:
- The reset in the driver at init is not needed anymore as the
hwmod framework takes care of reseting it.
- Reset is removed from omap_i2c_init, which was called
not only during probe,
Hi,
we really need to find a better way to handle this :-(
How about passing the mode info from musb_config (musb-config-
fifo_mode),
same way as musb-config-fifo_cfg
not sure... Ideally we wouldn't really need those fifo tables,
Yes, if all the board files provide their own
Hi,
I tried booting OMAP3EVM with the updated linux-omap kernel .
The last commit details on the kernel are :
Author: Tony Lindgren t...@atomide.com
commit b148d763841161894ed6629794064065a834aa2b
Linux-omap rebuilt: Updated to use omap_sdrc_init
It hangs at one point.
Following is the boot
On Mon, Aug 29, 2011 at 4:18 PM, Ravi, Deepthy deepthy.r...@ti.com wrote:
Hi,
I tried booting OMAP3EVM with the updated linux-omap kernel .
The last commit details on the kernel are :
Author: Tony Lindgren t...@atomide.com
commit b148d763841161894ed6629794064065a834aa2b
Linux-omap rebuilt:
On Mon, Aug 29, 2011 at 4:18 PM, Ravi, Deepthy deepthy.r...@ti.com wrote:
Hi,
I tried booting OMAP3EVM with the updated linux-omap kernel .
The last commit details on the kernel are :
Author: Tony Lindgren t...@atomide.com
commit b148d763841161894ed6629794064065a834aa2b
Linux-omap rebuilt:
Hi Govindraj,
With this commit added, it is booting up.Thanks for the info.
Thanks,
Deepthy Ravi.
From: Govindraj [govindraj...@gmail.com]
Sent: Monday, August 29, 2011 4:59 PM
To: Ravi, Deepthy
Cc: linux-omap@vger.kernel.org
Subject: Re: Booting hangs
[...]
void omap2_gpio_prepare_for_idle(int off_mode)
{
- int i, c = 0;
- int min = 0;
-
- if (cpu_is_omap34xx())
- min = 1;
+ int c = 0;
+ struct gpio_bank *bank;
- for (i = min; i gpio_bank_count; i++) {
- struct gpio_bank *bank
From: Vaibhav Hiremath hvaib...@ti.com
This patch set adds support for AM335x device having
Cortex-A8 MPU.
AM335X is treated as another OMAP3 variant, where,
along with existing cpu class OMAP34XX, new cpu class AM33XX is created
and the respective type is AM335X, which is newly added device in
From: Afzal Mohammed af...@ti.com
This patch adds minimal support and build configuration for
AM335X EVM.
Signed-off-by: Vaibhav Hiremath hvaib...@ti.com
Signed-off-by: Afzal Mohammed af...@ti.com
---
arch/arm/mach-omap2/Kconfig |5 +++
arch/arm/mach-omap2/Makefile |2
From: Afzal Mohammed af...@ti.com
Add support for low level debugging on AM335X EVM. Currently only
support for UART1 console, which is used on AM335X EVM is added.
Signed-off-by: Vaibhav Hiremath hvaib...@ti.com
Signed-off-by: Afzal Mohammed af...@ti.com
---
From: Afzal Mohammed af...@ti.com
This patch updates the common platform files with AM335X device
support.
The approach taken in this patch is,
AM33XX device will be considered as OMAP3 variant, and a separate
SoC class created for AM33XX family of devices with a subclass type
for AM335X device
From: Afzal Mohammed af...@ti.com
This patch updates the common machine specific source files for
support for AM335x with cpu type, macros for identification of
AM335X device.
Signed-off-by: Vaibhav Hiremath hvaib...@ti.com
Signed-off-by: Afzal Mohammed af...@ti.com
---
On Mon, 29 Aug 2011, Russell King - ARM Linux wrote:
You know better than I do what is needed to resolve the ordering issue.
However, contrary to what the original patch description said, this
isn't entirely a matter of making the write visible to the host
controller: No doubt in time
Hi,
On Mon, Aug 29, 2011 at 1:00 AM, Alan Stern st...@rowland.harvard.edu wrote:
On Sun, 28 Aug 2011, Ming Lei wrote:
I've been following this whole discussion. I didn't understand the
idea behind the original patch, and I don't understand this. What
reason is there for adding a memory
On Mon, 29 Aug 2011, Ming Lei wrote:
IMO, the dummy has been linked into queue pointed by qh-hw-hw_qtd_next,
so EHCI will fetch dummy qtd and execute the transaction and will not have
any delay on the transaction.
Let me explain the problem again: On ARM, the wmb() before
'dummy-hw_token =
Hi,
On Mon, Aug 29, 2011 at 11:03 PM, Alan Stern st...@rowland.harvard.edu wrote:
On Mon, 29 Aug 2011, Ming Lei wrote:
IMO, the dummy has been linked into queue pointed by qh-hw-hw_qtd_next,
so EHCI will fetch dummy qtd and execute the transaction and will not have
any delay on the
Hi,
On Mon, Aug 29, 2011 at 9:57 PM, Alan Stern st...@rowland.harvard.edu wrote:
On Mon, 29 Aug 2011, Russell King - ARM Linux wrote:
You know better than I do what is needed to resolve the ordering issue.
However, contrary to what the original patch description said, this
isn't entirely
Vishwanath Sripathy vishwanath...@ti.com writes:
[...]
diff --git a/arch/arm/mach-omap2/opp3xxx_data.c b/arch/arm/mach-
omap2/opp3xxx_data.c
index d95f3f9..b5d8294 100644
--- a/arch/arm/mach-omap2/opp3xxx_data.c
+++ b/arch/arm/mach-omap2/opp3xxx_data.c
@@ -26,6 +26,16 @@
#include
On Mon, 2011-08-29 at 23:55 +0800, Ming Lei wrote:
If writing to coherent memory can't reach physical memory immediately on
other ARCHs, the problem can still happen on these ARCHs. But I am
not sure if there are these kind of ARCHs except for ARM.
If there is write buffering which prevents
On Mon, 29 Aug 2011, Ming Lei wrote:
Suppose HC can see the old value in hw_token, which has the ACTIVE bit clear.
The qtd transaction will not be executed until the new token is
flushed into memory.
From view of CPU, the irq is still be delayed because ioc irq is generated
after the qtd
This is the first phase of the OMAP voltage layer cleanup. The
primary goal is to cleanup/reorganize data structures to facilitate
splitting apart the voltage processor (VP) and voltage controller (VC)
into separate layers.
Benoit Cousson (1):
OMAP4: powerdomain data: add voltage domains
On Saturday 27 August 2011, Paul Walmsley wrote:
On Sat, 27 Aug 2011, Arnd Bergmann wrote:
Right, and I guess we can simply ignore DMA and ioport resources because
they are extremely rare, right?
DMA resources are quite widely used.
For example, looking at the SoCs with some
On Sunday 28 August 2011, David Gibson wrote:
Right, and I guess we can simply ignore DMA and ioport resources because
they
are extremely rare, right?
Well, remember it's where resources can appear in the DT node that
matters, not what the types are in the platform device. ioports will
This is the first phase of the OMAP voltage layer cleanup. The
primary goal is to cleanup/reorganize data structures to facilitate
splitting apart the voltage processor (VP) and voltage controller (VC)
into separate layers.
Based on v3.1-rc3
Series available in branch pm-wip/voltdm_a in my
The voltage domain pointer currently in struct omap_hwmod is not used
and does not belong here. Instead, voltage domains will be associated
with powerdomains in forthcoming patches.
Acked-by: Paul Walmsley p...@pwsan.com
Signed-off-by: Kevin Hilman khil...@ti.com
---
Eliminate need for global variables for the various PRM module offsets by
making them part of the VP/VC common structures
Eventually, these will likely be moved again, or more likely removed
when VP/VC code is isolated, but for now just getting rid of them as
global variabes so that the voltage
The prm_irqst_reg is not part of the VP. Move it up into the common
voltage domain struct.
Signed-off-by: Kevin Hilman khil...@ti.com
---
arch/arm/mach-omap2/voltage.c | 15 +++
arch/arm/mach-omap2/voltage.h |1 +
Start cleaning up the voltage layer to have a voltage domain layer
that resembles the structure of the existing clock and power domain
layers. To that end:
- move the 'struct voltagedomain' out of 'struct omap_vdd_info' to
become the primary data structure.
- convert any functions taking a
Add wakeup voltage domain so that the wakeup powerdomain can have an
associated powerdomain. Note that the scalable flat is not set for
the this voltagedomain, so it will not be fully initialized like
scalable voltage domains.
Signed-off-by: Kevin Hilman khil...@ti.com
---
From: Benoit Cousson b-cous...@ti.com
Add voltage domain name to indicate which voltagedomain each
powerdomain is in.
The fixed voltage domain like ldo_wakeup for emu and wkup power
domain is added too.
Update the TI copyright date to 2011.
Signed-off-by: Benoit Cousson b-cous...@ti.com
Cc:
When a powerdomain is registered, lookup the voltage domain by name
and keep a pointer to the containing voltagedomain in the powerdomain
structure.
Modeled after similar method between powerdomain and clockdomain layers.
Signed-off-by: Kevin Hilman khil...@ti.com
---
As part of the voltage layer cleanup, split out VC specific code into
a dedicated VC layer. This patch primarily just moves VC code from
voltage.c into vc.c, and adds prototypes to vc.h.
No functional changes.
For readability, each function was given a local 'vc' pointer:
struct
This voltage domain (a.k.a. VDD1) contains both the MPU and the IVA, so
rename appropriately.
Also fixup any users of the mpu name to use mpu_iva
Signed-off-by: Kevin Hilman khil...@ti.com
---
arch/arm/mach-omap2/omap_hwmod_3xxx_data.c|4 ++--
arch/arm/mach-omap2/omap_twl.c
When a powerdomain is registered and it has an associated voltage domain,
add the powerdomain to the voltagedomain using voltdm_add_pwrdm().
Also add voltagedomain iterator helper functions to iterate over all
registered voltagedomains and all powerdomains associated with a
voltagedomain.
Move the VC instance struct from omap_vdd_info into struct voltagedomain.
While moving, perform some misc. renames for readability.
No functional changes.
Summary of renames:
- rename omap_vc_instance to omap_vc_channel, since there is only
one instance of the VC IP and this actually
VC is initialized first, set default scaling method to VC bypass.
If/when VP is initialized, default scaling method will be changed to
VP force-update.
Enabling VC bypass as default as soon as VC is initialized allows for
VC bypass scaling to work when no VP is configured/initialized for a
given
This patch is primarily a move of VP specific code from voltage.c into
its own code in vp.c and adds prototypes to vp.h
No functional changes, except debugfs...
VP debugfs moved to 'vp' subdir of debugfs/voltage/ and 'vp_'
prefixes removed from all debugfs filenames.
Signed-off-by: Kevin Hilman
Add SoC specific PRM VP helper functions for checking and clearing
the VP transaction done status.
Longer term, these events should be handled by the forthcoming PRCM
interrupt handler.
Signed-off-by: Kevin Hilman khil...@ti.com
---
arch/arm/mach-omap2/prm2xxx_3xxx.c | 41
Replace the VP tranxdone check/clear with helper functions from the
PRM layer.
In the process, remove prm_irqst_* voltage structure fields for IRQ
status checking which are no longer needed.
Since these reads/writes of the IRQ status bits were the only PRM
accesses that were not to VC/VP
The VC layer can support PMICs with separate voltage and command
registers by putting the different registers in the PRM_VC_SMPS_VOL_RA
and PRCM_VC_SMPS_CMD_RA registers respectively.
The PMIC data must supply at least a voltage register address
(volt_reg_addr). The command register address
Add a 'bool scalable' flag to the struct powerdomain and set it for
the scalable domains on OMAP3 and OMAP4.
Signed-off-by: Kevin Hilman khil...@ti.com
---
arch/arm/mach-omap2/voltage.c |3 +++
arch/arm/mach-omap2/voltage.h |2 ++
Each powerdomain is associated with a voltage domain. Add an entry to
struct powerdomain where the enclosing voltagedomain can be
referenced.
Modeled after similar relationship between clockdomains and powerdomains.
Signed-off-by: Kevin Hilman khil...@ti.com
---
On OMAP3+, the voltage controller (VC) and voltage processor (VP) are
inside the PRM. Add some PRM helper functions for register access to
these module registers.
Signed-off-by: Kevin Hilman khil...@ti.com
---
arch/arm/mach-omap2/prm2xxx_3xxx.c | 15 +++
Convert VC/VP register access to use PRM VC/VP accessor functions. In
the process, move the read/write function pointers from vdd_info into
struct voltagedomain.
No functional changes.
Additional cleanup:
- remove prm_mod field from VC/VP data structures, the PRM register
access functions
Add voltage domain name to indicate which voltagedomain each
powerdomain is in.
Signed-off-by: Kevin Hilman khil...@ti.com
---
arch/arm/mach-omap2/powerdomains2xxx_3xxx_data.c |2 ++
arch/arm/mach-omap2/powerdomains3xxx_data.c | 16
2 files changed, 18 insertions(+),
Create basic voltagedomains for OMAP2 and associate OMAP2 powerdomains
with the newly created voltage domains.
Signed-off-by: Kevin Hilman khil...@ti.com
---
arch/arm/mach-omap2/Makefile |3 +-
arch/arm/mach-omap2/io.c |2 +
This series focuses on cleanup and better abstraction in the voltage
controller (VC) layer.
Available in the pm-wip/voltdm_b branch of my linux-omap-pm tree
git://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-omap-pm.git
Applies on v3.1-rc3 + the part A series (pm-wip/voltdm_a branch)
- Add an i2c_slave_address field to the omap_vc_channel
- use VC/VP read/modify/write helper instead of open-coding
- remove smps_sa_shift, use __ffs(mask) for shift value
- I2C addresses 10-bit, change size to u16
Special thanks to Shweta Gulati shweta.gul...@ti.com for suggesting
the use of
- support both voltage register address and command register address
for each VC channel
- add fields for voltage register address (volra) and command register
address (cmdra) to struct omap_vc_channel
- use VC/VP register access read/modify/write helper
- remove volra_shift field (use
This series focuses on cleanup and better abstraction in the voltage
processor (VP) layer.
Available in the pm-wip/voltdm_c branch of my linux-omap-pm tree
git://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-omap-pm.git
Applies on v3.1-rc3 + the part A B series.
Kevin
Kevin Hilman
- move VP instance struct from vdd_info into struct voltage domain
- remove _data suffix from structure name
- rename vp_ prefix from vp_common field: accesses are now vp-common
- move vp_enabled bool from vdd_info into VP instance
- remove remaining references to omap_vdd_info
No functional
Remove read-only debugfs interface to VP values. Most of the values
are init-time only and never change. Current voltage value should be
retreived from the (eventual) regulator framework interface to the
voltage domain.
Fixes to original version provided by Nishanth Menon n...@ti.com
In struct omap_vp_common, the shift value can be derived from the mask
value by using __ffs(), so remove the shift value for the various
VPCONFIG bitfields, and use __ffs() in the code for the shift value.
While here, rename field names in kerneldoc comment to match actual
field names in
Add sys clock name and rate to struct voltage domain. SoC specific
voltagedomain init code initializes sys clock name. After clock
framework is initialized, voltage late init will then use use the
sys_clk rate to calculate the various timing that depend on that rate.
Signed-off-by: Kevin Hilman
Move VP timing calcluation (based on sys clock) and register programming
into VP init.
Signed-off-by: Kevin Hilman khil...@ti.com
---
arch/arm/mach-omap2/voltage.c | 22 --
arch/arm/mach-omap2/vp.c | 23 ++-
2 files changed, 22 insertions(+), 23
Create new helper function in VP layer for updating VP error gain.
Currently used during pre-scale for VP force update and VC bypass.
TODO: determine if this can be removed from the pre-scale path and
moved to VP enable path.
Signed-off-by: Kevin Hilman khil...@ti.com
---
Remove the runtime VP data in favor of direct programming of VP registers.
The VP is in the PRM, which is in the wakeup powerdomain, so there is no
need to keep the state dynamically.
Fixes to original version from Nishanth Menon n...@ti.com
Signed-off-by: Kevin Hilman khil...@ti.com
---
From: Todd Poynor toddpoy...@google.com
Reading the VPVOLTAGE field of PRM_VP_*_VOLTAGE registers currently
relies on a u32 - u8 conversion to mask off the FORCEUPDATEWAIT field
in the upper bits. Make this explicit using the mask symbol
already defined, added as a new field in struct
Function pointer used for actual voltage scaling (e.g. VP force update
or VC bypass) is moved from omap_vdd_info into struct voltagedomain,
resulting in renames s/vdd-volt_scale/voltdm-scale/
No functional changes.
Signed-off-by: Kevin Hilman khil...@ti.com
---
arch/arm/mach-omap2/voltage.c |
Add check for valid VP in omap_vp_update_errorgain()
Signed-off-by: Kevin Hilman khil...@ti.com
---
arch/arm/mach-omap2/vp.c |3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/vp.c b/arch/arm/mach-omap2/vp.c
index 3807620..29698ac 100644
---
combine VPCONFIG init voltage setup into common function and use from
both vp_enable and from vp_forceupdate_scale().
NOTE: this patch changes the sequence of when the initVDD bit is
cleared. The bit is now cleared immediately after it was written.
Since only the rising edge of this bit has any
Signed-off-by: Kevin Hilman khil...@ti.com
---
arch/arm/mach-omap2/vp.c | 34 --
arch/arm/mach-omap2/vp.h |1 -
2 files changed, 0 insertions(+), 35 deletions(-)
diff --git a/arch/arm/mach-omap2/vp.c b/arch/arm/mach-omap2/vp.c
index 29698ac..24020ea 100644
Remove last remaining member (volt_data) from omap_vdd_info into
struct voltagedomain and removal remaining usage and reference to
omap_vdd_info.
Signed-off-by: Kevin Hilman khil...@ti.com
---
arch/arm/mach-omap2/voltage.c | 54
Currently, the nominal voltage is updated in the VC post-scale function
which is common to both scaling methods. However, this has readabiliy
problems as this update is not where it might be expected. Instead, move
the updated into voltdm_scale() upon a successful return of voltdm-scale()
Use preferred voltdm_ naming for getting current nominal voltage.
No functional changes.
Signed-off-by: Kevin Hilman khil...@ti.com
---
arch/arm/mach-omap2/smartreflex-class3.c |2 +-
arch/arm/mach-omap2/voltage.c| 14 --
arch/arm/mach-omap2/voltage.h|
Starting with OMAP5, the following registers are per-channel and not
common to a all VC channels:
- SMPS I2C slave address
- SMPS voltage register address offset
- SMPS cmd/value register address offset
- VC channel configuration register
Move these from the channel-common struct into the
From: Tero Kristo t-kri...@ti.com
Needed as some of the voltage layer functionality is accessed from the
SMPS regulator driver.
Signed-off-by: Tero Kristo t-kri...@ti.com
Signed-off-by: Kevin Hilman khil...@ti.com
---
arch/arm/plat-omap/include/plat/voltage.h | 20
1
Track current nominal voltage as part of struct voltagedomain instead
of omap_vdd_info, which will soon be removed.
Also renames field from curr_volt to nominal_volt.
No functional changes.
Signed-off-by: Kevin Hilman khil...@ti.com
---
arch/arm/mach-omap2/vc.c |5 ++---
This series focuses on cleanup of the remaining voltage domain layer
(non-VC/VP code)
Available in the pm-wip/voltdm_d branch of my linux-omap-pm tree
git://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-omap-pm.git
Applies on v3.1-rc3 + the part A, B C series.
Kevin
Kevin Hilman
Hello everyone,
Greetings. I have tried the following kernels and found the problem
to occur on all of them with high resolution timer enabled
(1) mainline stable 3.0.1 kernel but with Hemant Pedanekar's patch
(http://www.spinics.net/lists/linux-omap/msg50742.html) and by
disabling 32KHz Timer
This series focuses on cleanups and fixes in support of the TWL6030 PMIC.
Available in the pm-wip/voltdm_e branch of my linux-omap-pm tree
git://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-omap-pm.git
Applies on v3.1-rc3 + the part A, B, C D series.
Kevin
Nishanth Menon (3):
From: Nishanth Menon n...@ti.com
using 1.35V as a check is not correct, we know that beyond 0x39,
voltages are non linear - hence use the conversion iff uV greater
than that for 0x39. For example, with 709mV as the smps offset,
the max linear is actually 1.41V(0x39vsel)!
Signed-off-by: Nishanth
From: Nishanth Menon n...@ti.com
0V conversions should be mapped to 0 as it is meant to denote
off voltages.
Signed-off-by: Nishanth Menon n...@ti.com
---
arch/arm/mach-omap2/omap_twl.c |4
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_twl.c
From: Patrick Titiano p-titi...@ti.com
According to latest OMAP4430 Data Manual v0.4 dated March 2011:
- Retention voltage shall be set to 0.83V. See tables 2.2, 2.4 and 2.6 in DM.
This allows saving a little more power in retention states.
- OPP100 IVA nominal voltage is 1.188V. See table
From: Nishanth Menon n...@ti.com
Without the command register, ON/ONLP/RET/OFF voltages are
useless. and TWL will be unable to use these
Signed-off-by: Nishanth Menon n...@ti.com
---
arch/arm/mach-omap2/omap_twl.c |6 ++
1 files changed, 6 insertions(+), 0 deletions(-)
diff --git
From: Patrick Titiano p-titi...@ti.com
omap_twl_vsel_to_uv() and omap_twl_uv_to_vsel() functions used to convert
voltages to TWL6030 SMPS commands (a.k.a vsel) implement incorrect conversion
formula.
It uses legacy OMAP3 formula, but OMAP4 Power IC has different offset and
voltage step:
-
Russell King - ARM Linux li...@arm.linux.org.uk writes:
Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk
Acked-by: Kevin Hilman khil...@ti.com
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info
Russell King - ARM Linux li...@arm.linux.org.uk writes:
Consolidate 24 trivial gpiolib implementions out of mach/gpio.h
into asm/gpio.h. This is basically the include of asm-generic/gpio.h
and the definition of gpio_get_value, gpio_set_value, and gpio_cansleep
as described in
Todd Poynor toddpoy...@google.com writes:
On Fri, Aug 12, 2011 at 12:20:21PM +0530, Munegowda, Keshava wrote:
On Wed, Aug 10, 2011 at 10:01 PM, Todd Poynor toddpoy...@google.com wrote:
@@ -913,12 +598,15 @@ static int usbhs_enable(struct device *dev)
From: Randy Dunlap rdun...@xenotime.net
Combine MFD_SUPPORT (which only enabled the remainder of the MFD
menu) and MFD_CORE. This allows other drivers to select MFD_CORE
without needing to also select MFD_SUPPORT, which fixes some
kconfig unmet dependency warnings. Modeled after I2C kconfig.
Keshava Munegowda keshava_mgo...@ti.com writes:
From: Keshava Munegowda keshava_mgo...@ti.com
The usbhs core driver does not enable/disable the intefrace and
fucntional clocks; These clocks are handled by hwmod and runtime pm,
hence insted of the clock enable/disable, the runtime pm APIS are
On Mon, Aug 29, 2011 at 12:41 PM, Luciano Coelho coe...@ti.com wrote:
From: Randy Dunlap rdun...@xenotime.net
Combine MFD_SUPPORT (which only enabled the remainder of the MFD
menu) and MFD_CORE. This allows other drivers to select MFD_CORE
without needing to also select MFD_SUPPORT, which
From: Laurent Pinchart laurent.pinch...@ideasonboard.com
omap_iovmm requires page-aligned buffers, and that sometimes causes
omap3isp failures (i.e. whenever the buffer passed from userspace is not
page-aligned).
Remove this limitation by rounding the address of the first page entry
down, and
1 - 100 of 111 matches
Mail list logo
