On Fri, 2011-11-25 at 18:48 +, Mark Brown wrote:
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
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 3630/Zoom3, UART wakeups no longer work from
suspend. That suggests that GPIO wakeups
On Mon, Nov 28, 2011 at 9:50 AM, Coelho, Luciano coe...@ti.com wrote:
On Tue, Nov 22, 2011 at 4:02 PM, Eliad Peller el...@wizery.com wrote:
Declare support for keeping the power of the wlan chip
while suspended. this is needed for Wakeup-On-Wireless.
Signed-off-by: Eliad Peller
On Mon, 2011-11-28 at 10:26 +0200, Eliad Peller wrote:
On Mon, Nov 28, 2011 at 9:50 AM, Coelho, Luciano coe...@ti.com wrote:
On Tue, Nov 22, 2011 at 4:02 PM, Eliad Peller el...@wizery.com wrote:
Declare support for keeping the power of the wlan chip
while suspended. this is needed for
Hi Tomi,
Just a question/suggestion, bellow:
On Thu, 2011-11-24 at 15:29 +0200, ext Tomi Valkeinen wrote:
Use the new lane config in dsi_set_lane_config().
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
drivers/video/omap2/dss/dsi.c | 84 +++-
Hi Eliad,
On 11/22/11 16:02, Eliad Peller wrote:
Add pm_caps field to omap2_hsmmc_info and omap_mmc_slot_data
structs, so we will be able to indicate mmc pm capabilities
in the board file.
Shouldn't this be user space runtime controllable?
Instead of being a static per board decision?
hi Igor,
On Mon, Nov 28, 2011 at 11:15 AM, Igor Grinberg grinb...@compulab.co.il wrote:
On 11/22/11 16:02, Eliad Peller wrote:
Add pm_caps field to omap2_hsmmc_info and omap_mmc_slot_data
structs, so we will be able to indicate mmc pm capabilities
in the board file.
Shouldn't this be user
Hi Luciano,
On 11/28/11 11:08, Luciano Coelho wrote:
On Mon, 2011-11-28 at 10:26 +0200, Eliad Peller wrote:
On Mon, Nov 28, 2011 at 9:50 AM, Coelho, Luciano coe...@ti.com wrote:
On Tue, Nov 22, 2011 at 4:02 PM, Eliad Peller el...@wizery.com wrote:
Declare support for keeping the power of the
On Mon, 2011-11-28 at 11:26 +0200, Igor Grinberg wrote:
Hi Luciano,
Hi Igor,
On 11/28/11 11:08, Luciano Coelho wrote:
I may do it for panda later on, if I get the time to test it. For
beagle, it doesn't really apply, because the wl12xx support is
out-of-tree, unfortunately. :(
If I
On 11/28/11 11:23, Eliad Peller wrote:
hi Igor,
On Mon, Nov 28, 2011 at 11:15 AM, Igor Grinberg grinb...@compulab.co.il
wrote:
On 11/22/11 16:02, Eliad Peller wrote:
Add pm_caps field to omap2_hsmmc_info and omap_mmc_slot_data
structs, so we will be able to indicate mmc pm capabilities
On Mon, Nov 28, 2011 at 12:01 PM, Igor Grinberg grinb...@compulab.co.il wrote:
On 11/28/11 11:23, Eliad Peller wrote:
hi Igor,
On Mon, Nov 28, 2011 at 11:15 AM, Igor Grinberg grinb...@compulab.co.il
wrote:
On 11/22/11 16:02, Eliad Peller wrote:
Add pm_caps field to omap2_hsmmc_info and
On Mon, Nov 28, 2011 at 11:58 AM, Luciano Coelho coe...@ti.com wrote:
On Mon, 2011-11-28 at 11:26 +0200, Igor Grinberg wrote:
On 11/28/11 11:08, Luciano Coelho wrote:
I may do it for panda later on, if I get the time to test it. For
beagle, it doesn't really apply, because the wl12xx
On Mon, 2011-11-28 at 12:12 +0200, Eliad Peller wrote:
On Mon, Nov 28, 2011 at 11:58 AM, Luciano Coelho coe...@ti.com wrote:
On Mon, 2011-11-28 at 11:26 +0200, Igor Grinberg wrote:
On 11/28/11 11:08, Luciano Coelho wrote:
I may do it for panda later on, if I get the time to test it. For
On 11/28/11 12:07, Eliad Peller wrote:
On Mon, Nov 28, 2011 at 12:01 PM, Igor Grinberg grinb...@compulab.co.il
wrote:
On 11/28/11 11:23, Eliad Peller wrote:
hi Igor,
On Mon, Nov 28, 2011 at 11:15 AM, Igor Grinberg grinb...@compulab.co.il
wrote:
On 11/22/11 16:02, Eliad Peller wrote:
Add
On Mon, Nov 28, 2011 at 09:49:19AM +0200, Péter Ujfalusi wrote:
On Sunday 27 November 2011 19:50:41 Mark Brown wrote:
So what happens if the user starts recording at 192kHz then goes back to
96kHz? This all feels a bit clunky and fragile.
I expect another HW param calls. The stream is
On Monday 28 November 2011 11:44:05 Mark Brown wrote:
Only if the user is using the same machine driver as you. If the user
wants a fixed clock rate for the DMIC and sets it on init rather than
resetting it every time hw_params() is called then this will break.
Ah, true. Will send the update
On 11/22/2011 07:44 AM, Rajendra Nayak wrote:
Adapt the driver to device tree and pass minimal platform
data from device tree needed for console boot.
No power management features will be suppported for now
since it requires more tweaks around OCP settings
to toggle forceidle/noidle/smaridle
On 11/22/2011 07:44 AM, Rajendra Nayak wrote:
Pass minimal data needed for console boot, from dt, for
OMAP4 panda/sdp and OMAP3 beagle boards, and get rid of the
static initialization from generic board file.
Signed-off-by: Rajendra Nayak rna...@ti.com
Acked-by: Rob Herring
On 11/28/2011 12:31 AM, Greg KH wrote:
On Mon, Nov 28, 2011 at 11:36:56AM +0530, Rajendra Nayak wrote:
On Sunday 27 November 2011 09:06 AM, Greg KH wrote:
On Tue, Nov 22, 2011 at 07:14:12PM +0530, Rajendra Nayak wrote:
v2 is based on the latest omap-serial runtime patches, which
can be found
Hello,
The following series will add support for OMAP4 DMIC interface, and enable them
on sdp4430/Blaze boards.
Changes since v3:
- dmic clk divider selection moved to hw_params phase to allow fixed rate
configuration from machine driver init.
Changes since v2:
- Use module_platform_driver
-
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 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(-)
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 | 549
sound/soc/omap/omap-dmic.h | 69
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
On OMAP4 we were writing 1 to IRQENABLE_CLR which clears only
the arbitration lost interrupt however for other than OMAP4 we clear all the
interrupts at idle. The patch intends to fix the same by writing 0 to the
IE register.
Signed-off-by: Vikram Pandita vikram.pand...@ti.com
Signed-off-by:
On OMAP4 we were writing 1 to IRQENABLE_CLR which cleared only
the arbitration lost interrupt however for other ips (not OMAP_I2C_IP_VERSION_2)
we clear all the interrupts at idle. The patch intends to fix the same by
writing 0 to the
IE register.
Signed-off-by: Vikram Pandita
Hi,
Changes compared to previous version:
- External controller support is now built in to twl-regulator.c as
an option that gets configured during probe
- Selected controller is based on option passed in platform data,
which also needs to be passed through twl-core.c (thus the change
to
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.
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
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
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 -
This way, we can add custom flags for VDD1 and VDD2 regulators that
get passed all the way to regulator init. This is needed for SMPS
regulator support to select used controller mode for these regulators
(either voltage processor or default.)
Signed-off-by: Tero Kristo t-kri...@ti.com
Cc: Samuel
TWL regulator now has two alternative control paths: the default
I2C path or an optional voltage processor path for OMAP chips.
If the voltage processor path should be used, this can be
indicated within the platform data by adding flag TWL_VP_SMPS_MODE
to regulator_init_data-driver_data.
This changes the control path for VDD1 and VDD2 regulators from
the I2C to be voltage processor.
Signed-off-by: Tero Kristo t-kri...@ti.com
---
arch/arm/mach-omap2/twl-common.c |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/twl-common.c
On Mon, Nov 28, 2011 at 04:53:24PM +0200, Tero Kristo wrote:
+++ b/drivers/regulator/twl-regulator.c
@@ -18,6 +18,7 @@
#include linux/regulator/machine.h
#include linux/i2c/twl.h
+#include plat/voltage.h
You shouldn't be including platform specific headers in generic code.
+ /*
On Sun, Nov 27, 2011 at 04:32:30AM +0100, Janusz Krzysztofik wrote:
This is required on ARM OMAP1 platform, after DPLL reprogramming has
been fixed by moving it from setup_arch() to kernel_init().
Created against linux-3.2-rc2.
Why do you need this? If you know what the original CPU clock
On Mon, 2011-11-28 at 11:08 +0200, Carlos Chinea wrote:
Hi Tomi,
Just a question/suggestion, bellow:
On Thu, 2011-11-24 at 15:29 +0200, ext Tomi Valkeinen wrote:
Use the new lane config in dsi_set_lane_config().
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
On Mon, 2011-11-28 at 14:58 +, Mark Brown wrote:
On Mon, Nov 28, 2011 at 04:53:24PM +0200, Tero Kristo wrote:
+++ b/drivers/regulator/twl-regulator.c
@@ -18,6 +18,7 @@
#include linux/regulator/machine.h
#include linux/i2c/twl.h
+#include plat/voltage.h
You shouldn't be
On Mon, Nov 28, 2011 at 05:43:41PM +0200, Tero Kristo wrote:
On Mon, 2011-11-28 at 14:58 +, Mark Brown wrote:
You shouldn't be including platform specific headers in generic code.
Hmm, should I pass the function pointers through platform data also?
Currently this does not seem to be too
On Mon, Nov 28, 2011 at 03:45:40PM +0200, Peter Ujfalusi wrote:
Add support for OMAP4 Digital Microphone interface.
Looks good - applied, thanks.
--
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 at
On Mon, Nov 28, 2011 at 03:45:43PM +0200, Peter Ujfalusi wrote:
OMAP4 SDP/Blaze boards have digital microphones.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
Applied, thanks.
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to
* Janusz Krzysztofik jkrzy...@tis.icnet.pl [26 19:06]:
According to comments in omap1_select_table_rate(), reprogramming dpll1
is tricky, and should always be done from SRAM.
While being at it, move OMAP730 special case handling inside
omap_sram_reprogram_clock().
Created on top of
* Janusz Krzysztofik jkrzy...@tis.icnet.pl [26 19:06]:
DPLL1 reprogramming to a different rate is actually blocked inside
omap1_select_table_rate(), resulting in the defalut rate of 60 MHz
always used instead of the one selected in .config. Fix it.
Created against linux-3.2-rc2, tested
Hi,
I have built a 3.1 mainline kernel with most stuff being configured as module.
I hit two errors in the musb kernel driver:
1. When loading g_ether without ohci_hcd being loaded it crashes as
in the first log.
2. When loading g_ether with ohci_hcd being loaded it crashes as
in the second log.
On Mon, Nov 28, 2011 at 04:53:19PM +0200, Tero Kristo wrote:
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
DPLL1 reprogramming to a different rate is actually blocked inside
omap1_select_table_rate(), resulting in the defalut rate of 60 MHz
always used instead of the one selected in .config. OTOH, in
omap1_defconfig we currently rely on Kconfig options for the supported
MHz rates in case of boards
On Sun, Nov 06, 2011 at 12:49:42AM +0100, Sebastian Reichel wrote:
Hi,
Please add tsc2005 to board-rx51-peripherals.c. The code should
have gone through the input queue according to [0], but only
the touchscreen driver is part of the mainline linux kernel
since 2.6.39-rc1.
I attached the
On Monday 28 of November 2011 at 16:39:00, Russell King - ARM Linux wrote:
On Sun, Nov 27, 2011 at 04:32:30AM +0100, Janusz Krzysztofik wrote:
This is required on ARM OMAP1 platform, after DPLL reprogramming has
been fixed by moving it from setup_arch() to kernel_init().
Created against
Otherwise timing is inaccurate, resulting in devices which depend on
delay(), like omap-keypad, broken.
Created and tested on top of linux-omap/fixes on Amstrad Delta.
Signed-off-by: Janusz Krzysztofik jkrzy...@tis.icnet.pl
Cc: Russell King - ARM Linux li...@arm.linux.org.uk
---
Hi,
This
The MUSB driver does not currently implment suspend/resume callbacks,
seemingly because it does not support cutting power when devices are
connected in host mode.
Without a proper suspend/resume implementation, the OMAP PM domain
layer which automatically gates non runtime-suspended devices will
On Monday 28 November 2011 07:09 PM, Rob Herring wrote:
On 11/22/2011 07:44 AM, Rajendra Nayak wrote:
Adapt the driver to device tree and pass minimal platform
data from device tree needed for console boot.
No power management features will be suppported for now
since it requires more tweaks
-Original Message-
From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
ow...@vger.kernel.org] On Behalf Of Kristo, Tero
Sent: Monday, November 28, 2011 8:23 PM
To: linux-omap@vger.kernel.org
Cc: sa...@linux.intel.com; broo...@opensource.wolfsonmicro.com;
Girdwood, Liam;
53 matches
Mail list logo
