On Thu, Nov 24, 2011 at 8:54 PM, Tony Lindgren t...@atomide.com wrote:
We should probably pass over
the static board specific mapping as platform_data to the pinmux device
and make it be part of struct pinctrl_dev. Then new driver instances
can have their own pctldev-mapping and we can
On Thursday 24 November 2011 17:10:19 Mark Brown wrote:
On Thu, Nov 24, 2011 at 03:54:46PM +0200, Peter Ujfalusi wrote:
+ /*
+* 192KHz rate is only supported with 19.2MHz/3.84MHz clock
+* configuration. Fix the dmic clock divider for 192KHz
+*/
+ if (params_rate(params)
On Fri, Nov 4, 2011 at 2:57 PM, DebBarma, Tarun Kanti
tarun.ka...@ti.com wrote:
On Fri, Nov 4, 2011 at 3:14 AM, Kevin Hilman khil...@ti.com wrote:
Tarun Kanti DebBarma tarun.ka...@ti.com writes:
This series is continuation of cleanup of OMAP GPIO driver and fixes.
Using this series on
Hello,
The following series will add support for OMAP4 DMIC interface, and enable them
on sdp4430/Blaze boards.
Changes since v2:
- Use module_platform_driver
- convert to use devm_
- Add clk_id for the output clock
- Extend the comment to explain why the driven can change the divider for 192KHz
To be able to get the memory resources by name from
the DMIC driver (for MPU and for DMA).
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
arch/arm/mach-omap2/omap_hwmod_44xx_data.c |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git
Add support for OMAP4 Digital Microphone interface.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
sound/soc/omap/Kconfig |3 +
sound/soc/omap/Makefile|2 +
sound/soc/omap/omap-dmic.c | 511
sound/soc/omap/omap-dmic.h | 69
Add platform device registration for OMAP4 DMIC.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
arch/arm/mach-omap2/devices.c | 22 ++
1 files changed, 22 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/devices.c b/arch/arm/mach-omap2/devices.c
OMAP4 SDP/Blaze boards have onboard digital microphones.
Register the platform device for the dmic-codec to be
able to use the microphones.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
arch/arm/mach-omap2/board-4430sdp.c |6 ++
1 files changed, 6 insertions(+), 0 deletions(-)
OMAP4 SDP/Blaze boards have digital microphones.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
sound/soc/omap/Kconfig |2 +
sound/soc/omap/sdp4430.c | 85 --
2 files changed, 76 insertions(+), 11 deletions(-)
diff --git
Hi,
Changes compared to previous version:
- merged most of the voltagedomain cleanup fixes to patch 2
- moved pmic latencies to omap_voltdm_pmic struct
- renamed omap_lp_params to omap2_oscillator as it only contains
osc info now
- major changes to usecount support (patch 11+, needed for
From: Nishanth Menon n...@ti.com
Every PMIC has it's own eccentricities, For example, one of the
PMIC has MSB set to 1 for a specific function - voltage enable!
using an hardcoded value specific for TWL when copied over to
such an implementation causes the system to crash as the MSB bit
was 0 and
This is applied when PMIC is entering or leaving a sleep mode.
Signed-off-by: Tero Kristo t-kri...@ti.com
---
arch/arm/mach-omap2/voltage.h |4
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/voltage.h b/arch/arm/mach-omap2/voltage.h
index
Both startup and shutdown take 500us at maximum, value taken from
TWL6030 data manual.
Signed-off-by: Tero Kristo t-kri...@ti.com
---
arch/arm/mach-omap2/omap_twl.c |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_twl.c
Introduced two new voltage domain specific parameter structures,
omap_vp_param and omap_vc_param. These are used to describe the minimum
and maximum voltages for the voltagedomains, and also the sleep voltage
levels. Existing voltage levels are also moved into these new structures,
and the voltage
Now we select the vddmin and vddmax values based on both pmic and
voltage processor data, this allows usage of different power ICs.
Signed-off-by: Tero Kristo t-kri...@ti.com
---
arch/arm/mach-omap2/vp.c |6 --
1 files changed, 4 insertions(+), 2 deletions(-)
diff --git
This contains startup and shutdown times for the oscillator. By default
use MAX_INT. Oscillator setup is used for calculating and setting up
latencies for sleep modes that disable oscillator.
Signed-off-by: Tero Kristo t-kri...@ti.com
---
arch/arm/mach-omap2/pm.c | 27
We now use the previously defined oscillator setup / shutdown times
to calculate the register values for CLKSETUP.
Signed-off-by: Tero Kristo t-kri...@ti.com
---
arch/arm/mach-omap2/vc.c | 46 ++
1 files changed, 46 insertions(+), 0 deletions(-)
As voltdm-pmic now contains startup and shutdown times for PMIC, use
these for calculating the fields in the PMICSETUPTIME register.
Signed-off-by: Tero Kristo t-kri...@ti.com
---
arch/arm/mach-omap2/vc.c | 11 +++
1 files changed, 11 insertions(+), 0 deletions(-)
diff --git
Beagleboard rev-c4 has a speed sorted OMAP3530 chip which can run at 720MHz.
Signed-off-by: Tero Kristo t-kri...@ti.com
---
arch/arm/mach-omap2/board-omap3beagle.c | 29 +
arch/arm/mach-omap2/opp3xxx_data.c |4
2 files changed, 33 insertions(+), 0
Voltage code will now enable / disable auto_ret / auto_off dynamically
according to the voltagedomain usecounts. This is accomplished via
the usage of the voltdm callback functions for sleep / wakeup.
Signed-off-by: Tero Kristo t-kri...@ti.com
---
arch/arm/mach-omap2/vc.c | 91
Some of the clocks are marked as autoidle, as they are handled by hardware.
Namely, core and per dplls are marked as such, and also sdrc_ick.
Per clkdomain manual transitions are also disabled, as this does not work,
and attempting to do so causes problems.
mpu_iva voltdm usecounts are also now
This patch fixes the usecount tracking for omap3+, previously the
usecount numbers were rather bogus and were not really useful for
any purpose. Now usecount numbers track the number of really active
clients on each domain. This patch also adds support for usecount
tracking on powerdomain and
If we are switching the state of an idle powerdomain, we must wait for
the wakeup to complete before attempting to switch to the new state,
otherwise the powerdomain may not be ready for the switch and will fail.
Signed-off-by: Tero Kristo t-kri...@ti.com
---
arch/arm/mach-omap2/pm.c |1 +
1
Based on the oscillator datasheet for this device.
Signed-off-by: Tero Kristo t-kri...@ti.com
---
arch/arm/mach-omap2/board-omap3beagle.c |3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/board-omap3beagle.c
b/arch/arm/mach-omap2/board-omap3beagle.c
OMAP3 uses the default settings for VDD1 channel, otherwise the settings will
overlap with VDD2 and attempting to modify VDD1 voltage will actually change
VDD2 voltage.
Signed-off-by: Tero Kristo t-kri...@ti.com
---
arch/arm/mach-omap2/vc.c |5 -
Hello,
Unfortunately the previous version of this work (SMPS regulator
was a separate driver) was rejected by the omap maintainers, thus
I am sending a new version. This implementation is going somewhat
back towards the original version, we are having an external
controller that replaces the
Regulator users can now set override functions for get_voltage and
set_voltage. This is required by some regulators, which have two
alternate control paths. E.g., OMAP SMPS regulators can be controlled
either through the I2C interface or voltage processor control path,
which uses specialized
VDD1 and VDD2 are the core voltage regulators on OMAP3. VDD1 is used
to control MPU/IVA voltage, and VDD2 is used for CORE. These regulators
are needed by DVFS.
Signed-off-by: Tero Kristo t-kri...@ti.com
---
arch/arm/mach-omap2/twl-common.c | 36
1 files
Beagleboard rev-c4 has a speed sorted OMAP3530 chip which can run at 720MHz.
Signed-off-by: Tero Kristo t-kri...@ti.com
---
arch/arm/mach-omap2/board-omap3beagle.c | 29 +
arch/arm/mach-omap2/opp3xxx_data.c |4
2 files changed, 33 insertions(+), 0
OMAP3 uses the default settings for VDD1 channel, otherwise the settings will
overlap with VDD2 and attempting to modify VDD1 voltage will actually change
VDD2 voltage.
Signed-off-by: Tero Kristo t-kri...@ti.com
---
arch/arm/mach-omap2/vc.c |5 -
VDD1 and VDD2 will now use voltage controller when regulator voltage
is changed.
Signed-off-by: Tero Kristo t-kri...@ti.com
---
arch/arm/mach-omap2/omap_twl.c | 21 +
1 files changed, 21 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_twl.c
SMPS regulator voltage control differs from the one of the LDO ones.
Current TWL code was using LDO regulator ops for controlling the SMPS
regulators, which fails. This was fixed fixed by adding separate
regulator type which uses correct logic and calculations for the
voltage levels.
On Fri, Nov 25, 2011 at 06:29:17PM +0200, Tero Kristo wrote:
Why is this only on the OMAP list? Always CC the relevant discussion
list for the subsystem, especially when proposing changes to the
subsystem!
Regulator users can now set override functions for get_voltage and
set_voltage. This is
On Fri, Nov 25, 2011 at 06:29:20PM +0200, Tero Kristo wrote:
+ struct twlreg_info *info = rdev_get_drvdata(rdev);
+ int vsel = DIV_ROUND_UP(min_uV - 60, 12500);
+
+ pr_info(attempting to write: %02x\n, vsel);
There's lots of prints in the driver which are at most dev_dbg().
On Fri, 2011-11-25 at 16:55 +, Mark Brown wrote:
On Fri, Nov 25, 2011 at 06:29:20PM +0200, Tero Kristo wrote:
+ struct twlreg_info *info = rdev_get_drvdata(rdev);
+ int vsel = DIV_ROUND_UP(min_uV - 60, 12500);
+
+ pr_info(attempting to write: %02x\n, vsel);
There's lots
On Fri, 2011-11-25 at 16:52 +, Mark Brown wrote:
On Fri, Nov 25, 2011 at 06:29:17PM +0200, Tero Kristo wrote:
Why is this only on the OMAP list? Always CC the relevant discussion
list for the subsystem, especially when proposing changes to the
subsystem!
Regulator users can now set
On Fri, Nov 25, 2011 at 07:20:32PM +0200, Tero Kristo wrote:
On Fri, 2011-11-25 at 16:52 +, Mark Brown wrote:
My basic reaction to this is eew, ick. Doing this with a runtime call
just feels badly joined up, and there's nothing here which hands off the
configuration between the
On Fri, 2011-11-25 at 17:29 +, Mark Brown wrote:
On Fri, Nov 25, 2011 at 07:20:32PM +0200, Tero Kristo wrote:
On Fri, 2011-11-25 at 16:52 +, Mark Brown wrote:
My basic reaction to this is eew, ick. Doing this with a runtime call
just feels badly joined up, and there's nothing
On Fri, Nov 25, 2011 at 07:59:03PM +0200, Tero Kristo wrote:
On Fri, 2011-11-25 at 17:29 +, Mark Brown wrote:
No, that's clearly going to break multi-board kernel images. If this
is something board specific platform/device tree data sounds like the
way forwards.
Okay, so I will
On Mon, Nov 21, 2011 at 05:40:43PM -0800, Mike Turquette wrote:
The common clk framework provides clk_prepare and clk_unprepare
implementations. Create an entry for HAVE_CLK_PREPARE so that
GENERIC_CLK can select it.
Signed-off-by: Mike Turquette mturque...@linaro.org
---
Acked-by: Shawn
Hi,
These 3 patches are against -next tree and Benoit's debugss
hwmod patch, so pmu irq on OMAP4 can be routed OK to CPU
with these patches, and perf can work well on OMAP4 now.
[1], http://marc.info/?l=linux-arm-kernelm=132162120904916w=2
thanks,
--
Ming Lei
--
To unsubscribe from this
From: Ming Lei ming@canonical.com
The following modules is required to be enabled before configuring
cross trigger interface for enabling pmu irq:
l3_instr, l3_main_3, debugss
so build the arm-pmu device via the three hwmods.
Signed-off-by: Ming Lei ming@canonical.com
---
From: Ming Lei ming@canonical.com
This patch supports pmu irq routed from CTI, so
make pmu/perf working on OMAP4.
The idea is from Woodruff Richard in the disscussion
about Oprofile on Pandaboard / Omap4 on pandabo...@googlegroups.com.
Acked-by: Jean Pihet j-pi...@ti.com
Acked-by: Tony
From: Ming Lei ming@canonical.com
Signed-off-by: Ming Lei ming@canonical.com
---
arch/arm/mach-omap2/devices.c |9 -
1 files changed, 8 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/devices.c b/arch/arm/mach-omap2/devices.c
index bc791e0..ab4de0d 100644
---
Hi,
These patches(against -next tree) introduce a device driver under
drivers/misc for enabling one face detection IP[1] which is
integrated inside OMAP4 SoC currently, and have some OMAP4
platform dependent changes to make the module workable on OMAP4 SoC.
For verification purpose, I write one
From: Ming Lei ming@canonical.com
Signed-off-by: Ming Lei ming@canonical.com
---
arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 81
1 files changed, 81 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
From: Ming Lei ming@canonical.com
Signed-off-by: Ming Lei ming@canonical.com
---
arch/arm/mach-omap2/devices.c | 33 +
1 files changed, 33 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/devices.c b/arch/arm/mach-omap2/devices.c
index
From: Ming Lei ming@canonical.com
One face detection IP[1] is integared inside OMAP4 SoC, so
introduce this driver to make face detection function work
on OMAP4 SoC.
This driver is platform independent, so in theory can
be used to drive same IP module on other platforms.
[1], ch9 of OMAP4
On Mon, Nov 21, 2011 at 05:40:42PM -0800, Mike Turquette wrote:
[...]
.the most notable change is the removal of struct clk_hw.
Happy to see that.
This extra
layer of abstraction is only necessary if we want hide the definition of
struct clk from platform code. Many developers expressed
49 matches
Mail list logo
