On Tuesday 07 August 2012 07:50 PM, Tomi Valkeinen wrote:
On Wed, 2012-08-01 at 16:01 +0530, Archit Taneja wrote:
Create function omapdss_sdi_set_timings(), this can be used by a SDI panel
driver without disabling/enabling the SDI interface. This is similar to the
set_timings op of the DPI
On Wed, 2012-08-08 at 11:27 +0530, Archit Taneja wrote:
I am a bit unclear about resolution when it comes to command mode panels.
Right, it's a bit confusing. And I'm not 100% sure how to manage the
rotation.
For command mode panels, we can perform rotation at the panel side. That
is, the
On Wed, 2012-08-08 at 11:35 +0530, Archit Taneja wrote:
On Tuesday 07 August 2012 08:02 PM, Tomi Valkeinen wrote:
On Wed, 2012-08-01 at 16:01 +0530, Archit Taneja wrote:
This series tries to make interface drivers less dependent on
omap_dss_device
which represents a panel/device
* Kevin Hilman khil...@ti.com [120807 11:21]:
Jon Hunter jon-hun...@ti.com writes:
Calling the dmtimer function omap_dm_timer_set_source() fails if following a
call to pm_runtime_put() to disable the timer. For example the following
sequence would fail to set the parent clock ...
On Wednesday 08 August 2012 11:55 AM, Tomi Valkeinen wrote:
On Wed, 2012-08-08 at 11:35 +0530, Archit Taneja wrote:
On Tuesday 07 August 2012 08:02 PM, Tomi Valkeinen wrote:
On Wed, 2012-08-01 at 16:01 +0530, Archit Taneja wrote:
This series tries to make interface drivers less dependent on
On Wed, 2012-08-08 at 12:17 +0530, Archit Taneja wrote:
On Wednesday 08 August 2012 11:55 AM, Tomi Valkeinen wrote:
On Wed, 2012-08-08 at 11:35 +0530, Archit Taneja wrote:
On Tuesday 07 August 2012 08:02 PM, Tomi Valkeinen wrote:
On Wed, 2012-08-01 at 16:01 +0530, Archit Taneja wrote:
On Wednesday 08 August 2012 12:40 PM, Tomi Valkeinen wrote:
On Wed, 2012-08-08 at 11:59 +0530, Archit Taneja wrote:
I tried out rotation on Taal, and it only works for 180 degrees(and 0 of
course), 90 and 270 result in no output. I'll add a
dss_mgr_set_timings() in omap_dsi_update, that should
On Wed, 2012-08-08 at 13:29 +0530, Archit Taneja wrote:
Okay, one thing which I want to align on is that most of these functions
don't really do the actual configurations. That is, they'll just update
the private data, and the actual configuration will only happen on enable.
We would want
On Wednesday 08 August 2012 01:43 PM, Tomi Valkeinen wrote:
On Wed, 2012-08-08 at 13:29 +0530, Archit Taneja wrote:
Okay, one thing which I want to align on is that most of these functions
don't really do the actual configurations. That is, they'll just update
the private data, and the actual
On Wed, 2012-08-08 at 14:08 +0530, Archit Taneja wrote:
On Wednesday 08 August 2012 01:43 PM, Tomi Valkeinen wrote:
On Wed, 2012-08-08 at 13:29 +0530, Archit Taneja wrote:
Okay, one thing which I want to align on is that most of these functions
don't really do the actual configurations.
Hello,
in order to be able to add DT support for the McBSP driver which is used on all
OMAP platforms (OMAP1/2/3/4/5) I needed to make some cleanups to the stack:
- Removing callbacks used by the driver for
- clock re-parenting (code moved to sound driver)
- FSR/CLKR mux configuration (from now
Only create the devices in a legacy way if we do not have the DT data.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
arch/arm/mach-omap2/mcbsp.c |4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/mcbsp.c b/arch/arm/mach-omap2/mcbsp.c
index
Move the McBSP CLKS re-parenting code to ASoC driver from
arch/arm/mach-omap2.
The call fort the re-parenting has been already limited to OMAP2+ SoC in
the ASoC driver. There is no longer need to have callback function for it.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
On OMAP2430 all McBSP ports have 128 word long buffer, enable the use of
the FIFO for the audio stack.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
arch/arm/mach-omap2/mcbsp.c |5 -
1 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/mcbsp.c
The muxing is done at board level, no need to do it in the ASoC machine
driver.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
sound/soc/omap/am3517evm.c | 20 ++--
1 files changed, 2 insertions(+), 18 deletions(-)
diff --git a/sound/soc/omap/am3517evm.c
Remove the feature to configure the CLKR/FSR mux on McBSP port with 6pin
configuration.
When moving to devicetree these callback can no longer be used in a clean
way anymore.
If a board require to change the 6pin port to work in 4pin setup it needs
to set up the mux in the board file.
For OMAP2/3:
Instead of the callback (which modifies control module register) use the
McBSP module's SYSCONFIG register to disable smart-idle mode when the
sidetone is enabled.
Store the original SIDLEMODE configuration and restore it when the sidetone
has been disabled.
Signed-off-by: Peter Ujfalusi
We can achieve the same result with SIDLEMODE field within McBSP SYSCONFIG
register.
The ASoC driver has been modified to use this method and we can now remove
the workaround using the control module register.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
arch/arm/mach-omap2/mcbsp.c
We can use the has_ccr flag to replace the cpu_is_omap* checks.
This provides future proof implementation and we do not need to update the
code if new OMAP revision starts to use the McBSP driver.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
sound/soc/omap/omap-mcbsp.c |8 +---
Device tree support for McBSP modules on OMAP2+ SoC.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
.../devicetree/bindings/sound/omap-mcbsp.txt | 45 +
sound/soc/omap/omap-mcbsp.c| 66 +++-
2 files changed, 110
NUM_LINKS is no longer in use by the code.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
sound/soc/omap/omap-mcbsp.h | 16
1 files changed, 0 insertions(+), 16 deletions(-)
diff --git a/sound/soc/omap/omap-mcbsp.h b/sound/soc/omap/omap-mcbsp.h
index baebcee..ba8386a
am3517evm board uses McBSP1 for audio with 4pin configuration.
The CLKR/FSR signals need to be connected to CLKX/FSX pin of the SoC in
this case.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
arch/arm/mach-omap2/board-am3517evm.c | 13 +
1 files changed, 13 insertions(+),
Hi Kaehlcke,
On Wed, Aug 08, 2012 at 02:13:06, Matthias Kaehlcke wrote:
Hi AnilKumar,
thanks for your comments
El Tue, Aug 07, 2012 at 08:59:17AM + AnilKumar, Chimata ha dit:
Can you re-submit the patch based on linux-next tree?
will do
Cross check with mfd/master also.
On Wednesday 08 August 2012 02:18 PM, Tomi Valkeinen wrote:
On Wed, 2012-08-08 at 14:08 +0530, Archit Taneja wrote:
On Wednesday 08 August 2012 01:43 PM, Tomi Valkeinen wrote:
On Wed, 2012-08-08 at 13:29 +0530, Archit Taneja wrote:
Okay, one thing which I want to align on is that most of
Place the MODULE_* lines in the same block and add MODULE_DESCRIPTION.
Rearange the platform_driver structure at the same time.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
drivers/mfd/twl4030-audio.c |8
1 files changed, 4 insertions(+), 4 deletions(-)
diff --git
Allocate the private data with devm_kzalloc.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
sound/soc/codecs/twl4030.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/sound/soc/codecs/twl4030.c b/sound/soc/codecs/twl4030.c
index 1247c4a..6a00c01 100644
---
Access the pdata via a pointer within the twl4030_priv structure.
In preparation for DeviceTree support.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
sound/soc/codecs/twl4030.c | 14 +++---
1 files changed, 7 insertions(+), 7 deletions(-)
diff --git
When the kernel has been booted with DT blob the platform data is NULL for
the driver.
We need to construct the pdata based on the DT information for runtime use.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
sound/soc/codecs/twl4030.c | 67 ++-
Hello,
The following series adds DT support for the twl4030 audio submodule which
provides audio codec and vibra functionality.
The MFD core driver is probed via DT, it will create the needed child devices
based on the provided information in the DT blob.
Child drivers (vibra, ASoC codec) will
Support for loading the twl4030 audio module via devicetree.
Sub devices for codec and vibra will be created as mfd devices once the
core MFD driver is loaded when the kernel is booted with a DT blob.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
The external mute (if it is in use) is handled by a GPIO line. Prepare to
remove the set_hs_extmute callback and replace it with two sets of platform
data:
hs_extmute_gpio: the GPIO number to use for external mute
hs_extmute_disable_level: the GPIO level to use when the external mute is
not
We no longer have users for the set_hs_extmute callback which has been
replaced by hs_extmute_gpio/hs_extmute_disable_level parameters so the
codec driver can handle the external mute if it is needed by the board.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
include/linux/i2c/twl.h
Remove the use of set_hs_extmute callback and let the codec driver to
handle the extmute GPIO.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
arch/arm/mach-omap2/board-zoom-peripherals.c |9 ++---
arch/arm/mach-omap2/include/mach/board-zoom.h |2 --
sound/soc/omap/zoom2.c
Add support when the kernel has been booted with DT blob. In this case the
pdata is NULL, we need to reach up to the core node and check if the codec
part has been enabled to determine if we need to coexist with the codec or
not.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
To facilitate the device tree support the probe function need to be rearanged.
Small cleanup in the APLL frequency selection part as well.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
drivers/mfd/twl4030-audio.c | 34 --
1 files changed, 16
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
drivers/mfd/twl4030-audio.c | 15 ++-
1 files changed, 6 insertions(+), 9 deletions(-)
diff --git a/drivers/mfd/twl4030-audio.c b/drivers/mfd/twl4030-audio.c
index ac04b4f..efa2d42 100644
--- a/drivers/mfd/twl4030-audio.c
+++
Hello,
Create new unified ASoC machine driver (with DT support) for boards using simple
configuration for audio and using the twl4030 codec.
This driver will replace the following machine drivers (since they are basically
the same):
igep0020, omap3beagle, omap3evm and overo.
This series will
Machine driver to handle simple devices using twl4030 as audio codec.
The driver supports the following boards:
- Beagleboard or Devkit8000
- Gumstix Overo or CompuLab CM-T35/CM-T3730
- IGEP v2
- OMAP3EVM
All of these boards can be switched to use this driver since their setup is
identical.
Since several OMAP3 based boards will be using the unified simple audio
driver it is better to not have duplicated code in the board files for this
purpose.
Board files can call omap_twl4030_audio_init(); to set up the needed device
for the audio support.
For example:
These boards have similar audio setup and they can all use the same driver
for audio support if it is enabled in the kernel config.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
arch/arm/mach-omap2/board-cm-t35.c |1 +
arch/arm/mach-omap2/board-devkit8000.c |1 +
The new omap-twl4030 handles the boards used the following drivers:
igep0020, omap3beagle, omap3evm and overo.
Remove these drivers since they are mostly identical and we already have
drop in replacement for all of them.
Note: Earlier patch added the needed code for the board files to retain the
If no match is found for a hwmod class, omap_hwmod_for_each_by_class()
currently does not spit out any error messages. To make debugging
issues related to non-existent hwmod classes simpler make this function
print an error message in case no match is found for the supplied hwmod
class.
Hi Kevin,
While testing cpufreq on 3.6-rc1, I noticed strange issues on OMAP4,
like a lockup when booting with 'performace' governer as default,
and crashes when using 'usespace' (which booted up) and switching
to higher OPPs.
It took me a while to realise I was using a 4460 device. The OPPs
On OMAP4, if the first CPU fails to get a valid frequency table (this
could happen if the platform does not register any OPP table), the
subsequent CPU instances end up dealing with a NULL freq_table and
crash. Add a check for a NULL freq_table to help error the rest
of the CPU instances out.
The 4430 OPP table was being registered for all other OMAP4 variants
too, like 4460 and 4470 causing issues with cpufreq driver
enabled. 4460 and 4470 devices have different OPPs as compared to
4430, and they should be populated seperately. As long as that
happens, let the OPP table registeration
On Wed, Aug 8, 2012 at 1:47 AM, Kevin Hilman khil...@ti.com wrote:
This reverts commit 58f0829b7186150318c79515f0e0850c5e7a9c89.
Converstion to per-pwrdm per/post transition calls was a bit
premature. Only tracking MPU, PER CORE in the idle path means we
lose the accounting for all the
On Tue, May 22, 2012 at 10:54 PM, Siarhei Siamashka
siarhei.siamas...@gmail.com wrote:
Needed for remapping pages with write-through cacheable
attribute. May be useful for framebuffers.
With this series applied, some of my framebuffer programs get over 70%
performance improvement, could we get
On Wed, Aug 08, 2012 at 12:11:30PM +0300, Peter Ujfalusi wrote:
The series changes McBSP related files mostly. It would be great if the whole
series could go via audio tree (if the patches are OK and it is fine by Tony).
I'm OK with all the patches, if Tony's happy with me applying them then
Hi Marc,
Thanks for the review
On Tue, Aug 07, 2012 at 17:27:05, Marc Kleine-Budde wrote:
On 08/07/2012 01:20 PM, AnilKumar Ch wrote:
Add Runtime PM support to C_CAN/D_CAN controller. The runtime PM
APIs control clocks for C_CAN/D_CAN IP and prevent access to the
register of C_CAN/D_CAN
On Wed, Aug 8, 2012 at 4:24 PM, Rajendra Nayak rna...@ti.com wrote:
On OMAP4, if the first CPU fails to get a valid frequency table (this
could happen if the platform does not register any OPP table), the
subsequent CPU instances end up dealing with a NULL freq_table and
crash. Add a check
All the cpu_is checks have been moved to dispc_init_features function providing
a much more generic and cleaner interface. The OMAP version and revision
specific functions are initialized by dispc_features structure local to dispc.c.
Signed-off-by: Chandrabhanu Mahapatra cmahapa...@ti.com
---
All the cpu_is checks have been moved to dss_init_features function providing a
much more generic and cleaner interface. The OMAP version and revision specific
functions are initialized by dss_features structure local to dss.c.
Signed-off-by: Chandrabhanu Mahapatra cmahapa...@ti.com
---
On Wed, Aug 08, 2012 at 07:38:01, Rob Herring wrote:
On 08/07/2012 10:53 AM, Hiremath, Vaibhav wrote:
On Tue, Aug 07, 2012 at 20:49:48, Rob Herring wrote:
On 08/07/2012 08:37 AM, Vaibhav Hiremath wrote:
If the module requires only one clocksource to function, then
driver can very well
Hi Peter,
On 08/08/2012 11:41 AM, Peter Ujfalusi wrote:
Support for loading the twl4030 audio module via devicetree.
Sub devices for codec and vibra will be created as mfd devices once the
core MFD driver is loaded when the kernel is booted with a DT blob.
Signed-off-by: Peter Ujfalusi
On 08/07/2012 02:10 PM, Tony Lindgren wrote:
You need to also consider that CONTROL_DEVCONF0 has the MMC/SDIO module input
clock selection. So pinctrl-single binding would have to be expanded to also
support one-bit-per-mux type registers in addition to one-register-per-mux
registers. And then
On 07/31/2012 04:37 PM, AnilKumar, Chimata wrote:
I'm just curious about the size here: how it ended up as 0x0338?
While looking at the TRM of AM335x I can come up with 0x0238 (0x44e10800 -
0x44e10a38), but I don't see any sings of the remaining 0x0100 to be
documented at least.
No, pinmux
Hi Peter,
Thank you very much for the patch series.
I probably will have some time to look into it more deeply on the next week.
Currently, only a small comment, please see below.
On 08/08/12 12:54, Peter Ujfalusi wrote:
These boards have similar audio setup and they can all use the same driver
Hi Igor,
On 08/08/2012 03:24 PM, Igor Grinberg wrote:
diff --git a/arch/arm/mach-omap2/board-cm-t35.c
b/arch/arm/mach-omap2/board-cm-t35.c
index 97d7190..b73fa5c 100644
--- a/arch/arm/mach-omap2/board-cm-t35.c
+++ b/arch/arm/mach-omap2/board-cm-t35.c
@@ -731,6 +731,7 @@ static void __init
On Wed, 2012-08-08 at 17:07 +0530, Chandrabhanu Mahapatra wrote:
All the cpu_is checks have been moved to dispc_init_features function
providing
a much more generic and cleaner interface. The OMAP version and revision
specific functions are initialized by dispc_features structure local to
Hi Benoit,
On 08/08/2012 02:50 PM, Benoit Cousson wrote:
+Required properties:
+- compatible : must be ti,twl4030-audio
+- ti,audio_mclk: Master clock frequency used on the board. Supported
+ frequencies: 1920, 2600 and 3840
Since you care about the frequency only
On Wed, Aug 08, 2012 at 01:50:53PM +0200, Benoit Cousson wrote:
That being said, since we do have the clock binding now, maybe we should
create a clock provider at board level for the sys_clk and thus you will
just have to create a phandle to it in your audio description.
Yes, we should be
On Wed, Aug 8, 2012 at 6:06 PM, Tomi Valkeinen tomi.valkei...@ti.com wrote:
On Wed, 2012-08-08 at 17:07 +0530, Chandrabhanu Mahapatra wrote:
All the cpu_is checks have been moved to dispc_init_features function
providing
a much more generic and cleaner interface. The OMAP version and revision
On 08/08/12 15:29, Peter Ujfalusi wrote:
Hi Igor,
On 08/08/2012 03:24 PM, Igor Grinberg wrote:
diff --git a/arch/arm/mach-omap2/board-cm-t35.c
b/arch/arm/mach-omap2/board-cm-t35.c
index 97d7190..b73fa5c 100644
--- a/arch/arm/mach-omap2/board-cm-t35.c
+++
On Wed, Aug 08, 2012 at 12:41:20PM +0300, Peter Ujfalusi wrote:
+Required properties:
+- compatible : must be ti,twl4030-audio
So, as I mentioned before I find this sort of direct mapping of the
Linux device representation into the device tree really troubling.
I'm just way too aware of the
On Wed, 2012-08-08 at 17:08 +0530, Chandrabhanu Mahapatra wrote:
All the cpu_is checks have been moved to dss_init_features function providing
a
much more generic and cleaner interface. The OMAP version and revision
specific
functions are initialized by dss_features structure local to
On Wed, 2012-08-08 at 18:31 +0530, Mahapatra, Chandrabhanu wrote:
Yes, this sounds good, but I was just following general order of
structure and function declarations, structures initializations
followed by functions.
Yep, it's a good rule. But there are exceptions when we'll get bloated
code
On Wed, Aug 08, 2012 at 12:54:06PM +0300, Peter Ujfalusi wrote:
Changes under arch/arm/mach-omap2/ are trivial, I don't expect merge issues
later. If it is OK for the maintainers I would like this to go via audio tree
(with the McBSP and the twl4030-audio stack DT support).
This all looks OK
On 08/08/2012 04:13 PM, Mark Brown wrote:
On Wed, Aug 08, 2012 at 12:41:20PM +0300, Peter Ujfalusi wrote:
+Required properties:
+- compatible : must be ti,twl4030-audio
So, as I mentioned before I find this sort of direct mapping of the
Linux device representation into the device tree
* Konstantin Baydarov kbaida...@dev.rtsoft.ru [120627 11:09]:
+
+/* TODO: Add helpers for 16bit and byte access */
+#ifdef CONFIG_MFD_OMAP_CONTROL
+u32 omap_control_status_read(u16 offset);
+#else
+static inline u32 omap_control_status_read(u16 offset)
+{
+ return 0;
+}
+#endif
This
On 08/08/2012 12:11 PM, Peter Ujfalusi wrote:
We can achieve the same result with SIDLEMODE field within McBSP SYSCONFIG
register.
The ASoC driver has been modified to use this method and we can now remove
the workaround using the control module register.
Are you sure it works without any
* Konstantin Baydarov kbaida...@dev.rtsoft.ru [120627 11:09]:
--- a/arch/arm/mach-omap2/id.c
+++ b/arch/arm/mach-omap2/id.c
@@ -18,6 +18,7 @@
#include linux/kernel.h
#include linux/init.h
#include linux/io.h
+#include linux/mfd/omap_control.h
#include asm/cputype.h
@@ -43,13
On Wed, Aug 08, 2012 at 04:43:16PM +0300, Peter Ujfalusi wrote:
On 08/08/2012 04:13 PM, Mark Brown wrote:
This doesn't seem like something that should be in the CODEC driver
really, there's a general need for something which can unmute controls
at the end of the power up sequence and mute
* Konstantin Baydarov kbaida...@dev.rtsoft.ru [120627 11:09]:
+
+module_platform_driver(omap_bandgap_sensor_driver);
+early_platform_init(early_omap_temperature, omap_bandgap_sensor_driver);
Why does this need to be early_platform_init?
Tony
--
To unsubscribe from this list: send the line
Add *remove* callback so that necessary cleanup operations are
performed when device is unregistered. The device is deleted
from the list and associated clock handle is released by
calling clk_put() and irq descriptor is released using the
irq_free_desc() api.
Signed-off-by: Tarun Kanti DebBarma
Hi Jarkko,
On 08/08/2012 04:25 PM, Jarkko Nikula wrote:
On 08/08/2012 12:11 PM, Peter Ujfalusi wrote:
We can achieve the same result with SIDLEMODE field within McBSP SYSCONFIG
register.
The ASoC driver has been modified to use this method and we can now remove
the workaround using the
On Wed, Aug 8, 2012 at 7:28 PM, Tarun Kanti DebBarma tarun.ka...@ti.com wrote:
Add *remove* callback so that necessary cleanup operations are
performed when device is unregistered. The device is deleted
from the list and associated clock handle is released by
calling clk_put() and irq
* Konstantin Baydarov kbaida...@dev.rtsoft.ru [120725 04:10]:
+
+u32 omap_control_status_read(void)
+{
+ return __raw_readl(omap_control_base);
+}
Ah OK it's changed here.. Sorry I was looking at the older
version.
+void __init of_omap_control_init(const struct of_device_id *matches)
Hello Vaibhav,
On Wed, 8 Aug 2012, Vaibhav Bedia wrote:
If no match is found for a hwmod class, omap_hwmod_for_each_by_class()
currently does not spit out any error messages. To make debugging
issues related to non-existent hwmod classes simpler make this function
print an error message in
On Wed, Aug 8, 2012 at 7:33 PM, Shilimkar, Santosh
santosh.shilim...@ti.com wrote:
On Wed, Aug 8, 2012 at 7:28 PM, Tarun Kanti DebBarma tarun.ka...@ti.com
wrote:
Add *remove* callback so that necessary cleanup operations are
performed when device is unregistered. The device is deleted
from
* Tony Lindgren t...@atomide.com [120808 07:05]:
* Konstantin Baydarov kbaida...@dev.rtsoft.ru [120725 04:10]:
+
+u32 omap_control_status_read(void)
+{
+ return __raw_readl(omap_control_base);
+}
Ah OK it's changed here.. Sorry I was looking at the older
version.
+void __init
On 08/08/2012 04:52 PM, Mark Brown wrote:
The hs_extmute is used for reducing pop noise on the headset. The sequence is
described in the TRM and it need to be done within the codec driver since it
is within the sequence.
Is the point it's at in the sequence the end?
On both ends :o
On HS
On Wed, Aug 08, 2012 at 05:16:58PM +0300, Peter Ujfalusi wrote:
On 08/08/2012 04:52 PM, Mark Brown wrote:
Is the point it's at in the sequence the end?
On both ends :o
On HS enable: the extmute has to be enabled, run the power on sequence for the
HS, wait for ramp, disable the HS extmute.
* Jan Luebbe j...@pengutronix.de [120807 09:30]:
When only ARCH_OMAP3 (or -2,-4,...) and SOC_AM33XX are selected, multi.h
doesn't set MULTI_OMAP2. In this case, cpu.h will simply define
cpu_is_omap24xx() as 1.
This causes problems for example for omap_hwmod.c:omap_hwmod_init which
checks
* Vaibhav Hiremath hvaib...@ti.com [120807 07:15]:
AM33XX device falls under omap2 class, so make cpu_class_is_omap2()
macro true by adding soc_is_am33xx() to existing list of cpu/soc
check.
This is required to unblock the basic boot support on AM335x platform.
Having done that, we still
On 08/08/2012 05:18 PM, Mark Brown wrote:
I'm struggling to see any reason not to just hold the external mute on
for the entire time the headset is powered off?
I think because it would mean in most cases that we keep a GPIO line enabled
during the time the HS is not in use, which burns power.
On 08/08/2012 03:52 PM, Mark Brown wrote:
On Wed, Aug 08, 2012 at 01:50:53PM +0200, Benoit Cousson wrote:
That being said, since we do have the clock binding now, maybe we should
create a clock provider at board level for the sys_clk and thus you will
just have to create a phandle to it in
* Tony Lindgren t...@atomide.com [120808 07:11]:
* Tony Lindgren t...@atomide.com [120808 07:05]:
* Konstantin Baydarov kbaida...@dev.rtsoft.ru [120725 04:10]:
+
+u32 omap_control_status_read(void)
+{
+ return __raw_readl(omap_control_base);
+}
Ah OK it's changed here..
On Wed, Aug 08, 2012 at 05:35:34PM +0300, Peter Ujfalusi wrote:
Does this needs the common clock framework on the platform? OMAP3 certainly
does not have it enabled since it has not been adopted.
I'd hope at least the binding code for finding clocks has been done at
the clkdev level so it can
On Wed, Jul 25, 2012 at 11:50:29, Datta, Shubhrajyoti wrote:
In case there are dma errors currently the driver exits.
Make the spi driver fall back to pio mode in case of dma errors.
If the DMA engine is not selected the driver
exits.This patch makes the spi fall back to pio in that case.
On Wed, Aug 08, 2012 at 05:31:19PM +0300, Peter Ujfalusi wrote:
On 08/08/2012 05:18 PM, Mark Brown wrote:
I'm struggling to see any reason not to just hold the external mute on
for the entire time the headset is powered off?
I think because it would mean in most cases that we keep a GPIO
Hi, Tony.
On 08/08/2012 06:39 PM, Tony Lindgren wrote:
* Tony Lindgren t...@atomide.com [120808 07:11]:
* Tony Lindgren t...@atomide.com [120808 07:05]:
* Konstantin Baydarov kbaida...@dev.rtsoft.ru [120725 04:10]:
+
+u32 omap_control_status_read(void)
+{
+ return
On 08/08/2012 04:35 PM, Peter Ujfalusi wrote:
On 08/08/2012 03:52 PM, Mark Brown wrote:
On Wed, Aug 08, 2012 at 01:50:53PM +0200, Benoit Cousson wrote:
That being said, since we do have the clock binding now, maybe we should
create a clock provider at board level for the sys_clk and thus you
Hi Paul,
On Wed, Aug 08, 2012 at 19:35:50, Paul Walmsley wrote:
[...]
It doesn't seem to me that this would necessarily always be an error.
Suppose some init code to create cpsw devices is running on an OMAP3430.
Then a omap_hwmod_for_each_by_class() that doesn't locate anything
wouldn't
Grazvydas Ignotas nota...@gmail.com writes:
On Wed, Aug 8, 2012 at 1:47 AM, Kevin Hilman khil...@ti.com wrote:
This reverts commit 58f0829b7186150318c79515f0e0850c5e7a9c89.
Converstion to per-pwrdm per/post transition calls was a bit
premature. Only tracking MPU, PER CORE in the idle path
Tarun Kanti DebBarma tarun.ka...@ti.com writes:
Add *remove* callback so that necessary cleanup operations are
performed when device is unregistered. The device is deleted
from the list and associated clock handle is released by
calling clk_put() and irq descriptor is released using the
Santosh Shilimkar santosh.shilim...@ti.com writes:
OMAP4 sleep entry code even though itself don't use many CPU registers
makes call to the v7_flush_dcache_all() which uses them. Since
v7_flush_dcache_all() doesn't make use of stack, the caller must take
care of the stack frame. Otherwise it
Rajendra Nayak rna...@ti.com writes:
The 4430 OPP table was being registered for all other OMAP4 variants
too, like 4460 and 4470 causing issues with cpufreq driver
enabled. 4460 and 4470 devices have different OPPs as compared to
4430, and they should be populated seperately. As long as that
Shilimkar, Santosh santosh.shilim...@ti.com writes:
On Wed, Aug 8, 2012 at 4:24 PM, Rajendra Nayak rna...@ti.com wrote:
On OMAP4, if the first CPU fails to get a valid frequency table (this
could happen if the platform does not register any OPP table), the
subsequent CPU instances end up
Hi Vaibhav
On Wed, 8 Aug 2012, Bedia, Vaibhav wrote:
On Wed, Aug 08, 2012 at 19:35:50, Paul Walmsley wrote:
It doesn't seem to me that this would necessarily always be an error.
Suppose some init code to create cpsw devices is running on an OMAP3430.
Then a
Hi AnilKumar,
El Wed, Aug 08, 2012 at 09:25:29AM + AnilKumar, Chimata ha dit:
Cross check with mfd/master also.
ok
+ if (!of_property_read_u32(np, fdim, val)) {
+ if (val == 100) {
+
1 - 100 of 111 matches
Mail list logo
