On 11/08/2012 01:29 PM, Grazvydas Ignotas wrote:
But I want to note that I'm currently trying to clean up the mess around
twl-core. In my view we have quite a bit of redundancy in there. The PWM A/B
is for driving the LED A/B outputs. We should have only these modules for
PWM/LED in twl-core:
On 11/07/2012 06:50 PM, Grazvydas Ignotas wrote:
+static int twl4030_pwm_enable(struct pwm_chip *chip, struct pwm_device *pwm)
+{
+ int ret;
+ u8 val;
+
+ ret = twl_i2c_read_u8(TWL4030_MODULE_INTBR, val, TWL4030_GPBR1_REG);
+ if (ret 0) {
+
On 11/07/2012 07:12 PM, Grazvydas Ignotas wrote:
+static int twl4030_pwmled_config(struct pwm_chip *chip, struct pwm_device
*pwm,
+ int duty_ns, int period_ns)
+{
+ int duty_cycle = (duty_ns * TWL4030_LED_MAX) / period_ns;
+ u8 on_time;
+ u8
Hi Benoit,
On 10/31/2012 12:09 PM, Cousson, Benoit wrote:
Hi Peter,
That's great you've have done that fix.
On 10/30/2012 12:24 PM, Peter Ujfalusi wrote:
Add flags parameter for omap_hwmod_count_resources() so users can tell which
type of resources they are interested when counting them
the issue by marking the McPDM hwmod record
with the HWMOD_EXT_OPT_MAIN_CLK flag. This prevents the hwmod
code from touching the device early during boot.
Signed-off-by: Paul Walmsley p...@pwsan.com
Cc: Péter Ujfalusi peter.ujfal...@ti.com
Cc: Benoît Cousson b-cous...@ti.com
Acked-by: Peter
On 10/30/2012 11:33 AM, Peter Ujfalusi wrote:
When booting with DT the OF core can fill up the resources provided within
the DT blob.
The current way of handling the DT boot prevents us from removing hwmod data
for platforms only suppose to boot with DT (OMAP5 for example) since we need
to
On 10/30/2012 12:25 PM, Paul Walmsley wrote:
On Tue, 30 Oct 2012, Peter Ujfalusi wrote:
Tony, Benoit, Paul: Not sure if this qualify for 3.7 inclusion, but for sure
going to help us to clean up the OMAP5 hwmod database.
It's definitely not 3.7 material, but will look at it for 3.8 merge
On 10/24/2012 12:02 PM, Benoit Cousson wrote:
The interrupt-parent attribute does not have to be added in each
node since the DT framework will check for the parent as well to get it.
Create an interrupt-parent for OMAP2, OMAP3, AM33xx and remove the
attributes from every nodes that were
Hi Tony,
On 10/18/2012 12:00 PM, Benoit Cousson wrote:
On 10/18/2012 11:25 AM, Peter Ujfalusi wrote:
Fixes the following errors:
[2.318084] omap-mcbsp 49022000.mcbsp: invalid rx DMA channel
[2.324432] omap-mcbsp 49024000.mcbsp: invalid rx DMA channel
Which is because we failed to
Hi,
On 10/19/2012 01:33 AM, Russell King - ARM Linux wrote:
I would suggest getting some feedback from the ASoC people first, before
trying to invent new APIs to work around this stuff. If they can live
with having prefetch enabled on OMAP then there isn't an issue here. If
not, we need a
On 10/16/2012 03:27 AM, Ricardo Neri wrote:
Creating the accessory devices, such as audio, from the HDMI driver
allows to regard HDMI as a single entity with audio an display
functionality. This intends to follow the design of drivers such
as MFD, in which a single entity handles the creation
On 10/12/2012 06:24 PM, Tony Lindgren wrote:
twl6040-codec twl6040-codec: ASoC: Failed to create Capture debugfs file
Peter, can you take a look please?
Patch to fix this has been already sent:
http://mailman.alsa-project.org/pipermail/alsa-devel/2012-September/055684.html
The same issue has
On 10/08/2012 07:35 PM, Tony Lindgren wrote:
- omap-dma.c and omap-pcm.c can test the arch locally as
omap1 and omap2 cannot be compiled together because of
conflicting compiler flags
sound/soc/omap/omap-pcm.c |9 +++--
Tony: is this going to be included in 3.7?
On 10/06/2012 02:03 AM, Tony Lindgren wrote:
* Peter Ujfalusi peter.ujfal...@ti.com [121004 04:57]:
Hello,
u-boot recently stopped configuring 'non essential' pin mux. This change
leaves
the audio essential pins in non configured state which prevents the use of
audio.
The following
Hi Mark,
On Wednesday 14 December 2011 19:27:11 Mark Brown wrote:
This seems like we need a better system for doing this, we can't go
changing the machine name every time there's a kernel space change that
affects a UCM file, that's going to get crazy.
As of know we do not have UCM for the
On Thursday 15 December 2011 10:17:38 Péter Ujfalusi wrote:
Hi Mark,
On Wednesday 14 December 2011 19:27:11 Mark Brown wrote:
This seems like we need a better system for doing this, we can't go
changing the machine name every time there's a kernel space change that
affects a UCM file
On Wednesday 14 December 2011 17:57:47 Mark Brown wrote:
On Wed, Dec 14, 2011 at 11:46:57AM +0200, Peter Ujfalusi wrote:
+enum board_type {
+ OMAP_ABE_TWL6040_SDP4430,
+ OMAP_ABE_TWL6040_PANDA,
+ OMAP_ABE_TWL6040_PANDA_ES,
+};
It seems like it might better in the long run to
On Wednesday 14 December 2011 18:01:00 Mark Brown wrote:
On Wed, Dec 14, 2011 at 11:46:59AM +0200, Peter Ujfalusi wrote:
The card's name for OMAP4 SDP4430 has been changed:
SDP4430 - OMAP4-SDP4430
Why? The board appaers to be generally known as SDP4430...
At the moment we do not have
On Thursday 10 November 2011 15:02:04 Jarkko Nikula wrote:
On 11/10/2011 02:46 PM, Jarkko Nikula wrote:
On 11/07/2011 11:33 AM, Peter Ujfalusi wrote:
If the DMA source position has been asked before the
first actual data transfer has been done, the CSAC
register does not contain valid
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 Sunday 27 November 2011 19:50:41 Mark Brown wrote:
On Fri, Nov 25, 2011 at 02:20:33PM +0200, Peter Ujfalusi wrote:
+ /*
+* 192KHz rate is only supported with 19.2MHz/3.84MHz clock
+* configuration. The same clock configuration allows 96KHz sampling
+* rate as well.
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 Tuesday 22 November 2011 16:01:05 Mark Brown wrote:
On Tue, Nov 22, 2011 at 04:01:57PM +0200, Peter Ujfalusi wrote:
+ switch (params_rate(params)) {
+ case 96000:
+ case 192000:
+ break;
Why doesn't the driver need to tell the hardware what sample rate to run
at?
On Wednesday 23 November 2011 10:58:07 Mark Brown wrote:
This just seems like it's making the code needlessly complex - there's
no harm in holding the reference if you don't enable/disable the clock
and it makes this function much simpler.
OK.
We enable the clocks at dai_startup for the
On Wednesday 23 November 2011 14:30:50 Mark Brown wrote:
Meh, I guess. It's hard to love code-wise.
So you would prefer me to enable the OMAP DMIC's clocks at pcm_trigger:start
time, and disable them on pcm_trigger:stop?
I have seen cases when the driver did not received the pcm_trigger:stop
On Thursday 03 November 2011 14:27:56 Tony Lindgren wrote:
* Peter Ujfalusi peter.ujfal...@ti.com [111031 06:46]:
If the DMA source position has been asked before the
first actual data transfer has been done, the CSAC
register does not contain valid information.
We can identify this
On Friday 04 November 2011 15:18:05 Joe Woodward wrote:
In 3.1 sound support is broken for any boards using a TWL4030-based CODEC.
The Kconfig option for the TWL4030 CODEC used to be TWL4030_CODEC, and in
3.1 this has been changed to MFD_TWL4030_AUDIO.
I believe this has caused a problem
Hello Mark, Tony,
On Tuesday 30 August 2011 13:39:51 Ujfalusi, Peter wrote:
Hello,
Small cleanup for the tpa6130a2 driver for model handling:
Remove the model_id from platform_data, and use the device name/device_data
to distinguish between the supported models of TPA.
Would you have time
On Monday 05 September 2011 11:26:33 Thomas Weber wrote:
The codec for Devkit8000 (TWL4030) was not detected except
when build with CONFIG_SND_SOC_ALL_CODECS.
twl-core.c still uses the CONFIG_TWL4030_CODEC for
twl_has_codec().
acked-by: Peter Ujfalusi peter.ujfal...@ti.com
--
To
On Friday 19 August 2011 15:04:20 Tony Lindgren wrote:
It seems OK to me.
Thanks!
But for the -rc cycle it has potential for
fixes for features that never worked flame bait. If you guys
are OK to deal with that then go ahead.
Hrm, I have not thought about this. Not sure, if we want to go
On Tuesday 16 August 2011 15:33:09 Maximilian Schwerin wrote:
Hi,
I'm currently working on a beagle board clone.
I've got some problems getting the micbias1 output on the TPS65950 to work.
I can record audio coming from a line out or if I connect micbias1 to an
extern 1.8V supply.
Hi Tony,
On Tuesday 09 August 2011 09:27:17 Ujfalusi, Peter wrote:
Hi Tony,
On Tuesday 02 August 2011 13:34:13 Ujfalusi, Peter wrote:
Hello,
The OMAP4 McPDM driver in upstream has been broken for some time...
This series fixes that, and enables basic audio playback/capture over
the
Hi Tony,
On Tuesday 02 August 2011 13:34:13 Ujfalusi, Peter wrote:
Hello,
The OMAP4 McPDM driver in upstream has been broken for some time...
This series fixes that, and enables basic audio playback/capture over the
mcpdm interface.
Would you have time to look at this series?
Specially
Hi Russel,
On Monday 08 August 2011 13:00:56 Russell King - ARM Linux wrote:
With CONFIG_ARCH_OMAP3=y and CONFIG_ARCH_OMAP4=n, I'm getting this:
arch/arm/mach-omap2/built-in.o:(.data+0xf99c): undefined reference to
`omap4430_phy_init' arch/arm/mach-omap2/built-in.o:(.data+0xf9a0):
undefined
Hi Tony, Paul,
On Tuesday 09 August 2011 15:14:53 Tony Lindgren wrote:
* Paul Walmsley p...@pwsan.com [110808 13:31]:
Hi
On Mon, 8 Aug 2011, Daniel Morsing wrote:
Building the v3.1-rc1 kernel with ARCH_OMAP !ARCH_OMAP4 support
fails on linking with the following error
...
On Tuesday 02 August 2011 13:34:17 Ujfalusi, Peter wrote:
In order to probe, and operate correctly, the OMAP McPDM driver needs to
be converted to use hwmod.
The device name has been changed to probe the driver.
Replace the clk_* with pm_runtime_* calls to manage the clocks correctly.
Missing
Oops...
On Tuesday 02 August 2011 13:28:41 Ujfalusi, Peter wrote:
From: Misael Lopez Cruz misael.lo...@ti.com
TWL6040 IC provides analog high-end audio codec functions for
handset applications. It contains several audio analog inputs
and outputs as well as vibrator support. It's connected
Hi Felipe,
On Tuesday 02 August 2011 14:33:09 Balbi, Felipe wrote:
Hi,
On Tue, Aug 02, 2011 at 02:28:42PM +0300, Peter Ujfalusi wrote:
@@ -145,7 +143,7 @@ static int vibra_play(struct input_dev *input, void
*data,
ret = queue_work(info-workqueue, info-play_work);
if (!ret) {
On Saturday 09 July 2011 03:08:10 Mark Brown wrote:
I've got a few ideas but nothing comprehensive right now; the main thing
I can think we're missing at the minute is more fine grained hooks
around stream start in order to allow things to clock off the audio
stream. Equally well none of the
On Friday 08 July 2011 16:28:05 Mark Brown wrote:
It's not that simple in this situation. We also have a PM dependency on
the CODEC here too, it supplies our interface clock via the DAI so we
have to be very careful how we interact with the ABE and CODEC. The
critical thing here is the pop
Hello Tony,
As it has been discussed I'm sending this pull request, which includes the
following series (all patch acked-by the corresponding maintainer):
1. v6 of MFD/ASoC/Input: TWL4030/TWL60X0 changes (18 patch)
2. v3 of MFD/input/ASoC: twl6040: irq registration changes (5 patch)
3. v1 of
On Thursday 07 July 2011 18:53:29 Mark Brown wrote:
Sounds like runtime PM ought to be able to handle this, though? If you
need to sync with the ABE can the ABE take PM references to the DAIs
it's talking to?
It is not (just?) the ABE, but rather the twl6040 codec, which needs this
deferred
On Thursday 07 July 2011 20:29:47 Tony Lindgren wrote:
Thanks. Can you please add one more branch for cleanup only for me to
pull at your commit b252b0efb605b92a2f5d118e294d088d89cfd286
(OMAP3: Move common regulator configuration to twl-common)?
Do you want a separate pull request for it?
The
Hi Samuel,
On Monday 04 July 2011 19:39:35 Samuel Ortiz wrote:
That is fine with me, yes. That's why I ACK the MFD patches for Tony to take
them.
I have changed the series for Tony in my branch for the following comments:
wl6040_is_powered, twl6040_get_rev removal, since these are really small
Hi Felipe, Samuel,
On Monday 04 July 2011 14:53:30 Balbi, Felipe wrote:
+ ret = twl6040_request_irq(twl6040, TWL6040_IRQ_READY,
+ twl6040_naudint_handler, 0,
+ twl6040_irq_ready, twl6040);
why don't you use
Hi Samuel,
On Monday 04 July 2011 13:48:44 Samuel Ortiz wrote:
Hi Peter,
On Tue, Jun 21, 2011 at 04:39:06PM +0300, Peter Ujfalusi wrote:
+int twl6040_is_powered(struct twl6040 *twl6040)
+{
+ return twl6040-power_count;
+}
+EXPORT_SYMBOL(twl6040_is_powered);
Do we really need to
Hi Samuel,
On Monday 04 July 2011 13:48:44 Samuel Ortiz wrote:
I don't see the value of those 3 inline functions. Removing them would make
the code actually more understandable (especially for the 2nd one).
Is it OK for you if I fix these as a follow-up series, so I do not need to
rewrite
Hi Samuel,
Would you be able to take a look at this series?
I already have the rebased version on top of linux-omap/devel-cleanup branch
as Tony requested, and I'm now waiting for your comments.
Thank you,
Péter
On Monday 27 June 2011 11:43:57 Ujfalusi, Peter wrote:
Hi Tony, Samuel,
Would
Hi Samuel,
On Thursday 30 June 2011 10:04:43 Samuel Ortiz wrote:
I will do that very soon, no worries.
Thank you very much, I'm going to have another series on top of this one
coming, and want to make sure that I'm in the right track.
Thanks,
Péter
--
To unsubscribe from this list: send the
Hi Tony,
On Tuesday 28 June 2011 08:17:21 Tony Lindgren wrote:
OK. Assuming Samuel is fine with the patches, care to put
together a branch against devel-cleanup for me to pull?
While waiting for Samuel, I can start preparing the branch for you, since the
bulk of the conflicts are in
Hi Tony, Samuel,
Would you have time to take a look at this series?
Thanks,
Péter
On Tuesday 21 June 2011 15:38:58 Ujfalusi, Peter wrote:
Hello,
Changes since v5:
- Use alloc_workqueue in the twl6040-vibra driver (comment from Tejun Heo)
- Allow user to change the headset power mode, but
Hi Tony,
On Monday 27 June 2011 12:18:35 Tony Lindgren wrote:
* Péter Ujfalusi peter.ujfal...@ti.com [110627 02:39]:
Hi Tony, Samuel,
Would you have time to take a look at this series?
Looks good to me. If it conflicts with what we have queued
in the devel-cleanup branch, I should
Hello Dmitry,
On Tuesday 21 June 2011 22:32:01 Dmitry Torokhov wrote:
On Tue, Jun 21, 2011 at 04:39:09PM +0300, Peter Ujfalusi wrote:
From: Misael Lopez Cruz misael.lo...@ti.com
Add twl6040_vibra as a child of MFD device twl6040_codec. This
implementation covers the PCM-to-PWM mode of
Hello Mark,
On Tuesday 21 June 2011 19:35:05 Mark Brown wrote:
On Tue, Jun 21, 2011 at 04:39:13PM +0300, Peter Ujfalusi wrote:
From: Misael Lopez Cruz misael.lo...@ti.com
Remove dependency between pll (hppll, lppll) and headset power
mode (low-power, high-performance), as headset power
Hello Tejun,
On Thursday 16 June 2011 16:06:00 Ujfalusi, Peter wrote:
I suppose you meant alloc_workqueue()? :)
Oh, yes. I mean that.
Just avoid another series...
I have looked at the alloc_workqueue, and I'm not really sure what parameters
should I use.
#define
Hello Tony, Samuel, Mark, Liam.
Did you got time to check the patches for your areas?
I want to send the updated series with the change in the vibra driver
(addressing comments from Dmitry, and Tejun), but I want to address your
comments as well at the same time if any (or add you Ack).
Thank
Hello Mark,
On Friday 17 June 2011 11:39:40 Mark Brown wrote:
On Fri, Jun 17, 2011 at 01:06:19PM +0300, Péter Ujfalusi wrote:
Hello Tony, Samuel, Mark, Liam.
Did you got time to check the patches for your areas?
I reviewed the first posting, did you do anything new?
Yes I have added
On Friday 17 June 2011 11:51:28 Mark Brown wrote:
Oh, gah. I'll dig them out of my mail folders - I wasn't reading the
individual patches due to the repeated reposting.
Sorry about that, I did mentioned this in the intro mail, when I introduced
them. I should have made it more obvious for
On Friday 17 June 2011 11:43:32 Tejun Heo wrote:
Just use the default params
alloc_workqueue(twl6040-vibra, 0, 0);
Thanks.
I'll do this for the next posting
Thanks,
Péter
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to
On Friday 17 June 2011 15:27:59 Mark Brown wrote:
On Mon, Jun 13, 2011 at 07:37:47PM +0300, Peter Ujfalusi wrote:
From: Misael Lopez Cruz misael.lo...@ti.com
Remove dependency between pll (hppll, lppll) and headset power
mode (low-power, high-performance), as headset power mode can
be
On Friday 17 June 2011 15:22:27 Mark Brown wrote:
On Mon, Jun 13, 2011 at 07:37:46PM +0300, Peter Ujfalusi wrote:
From: Liam Girdwood l...@ti.com
Add other supported sample rates to LP and HP modes.
Signed-off-by: Liam Girdwood l...@ti.com
Signed-off-by: Peter Ujfalusi
On Wednesday 15 June 2011 10:23:01 Tejun Heo wrote:
On Wed, Jun 15, 2011 at 10:18:58AM +0200, Tejun Heo wrote:
No human being can feel 120usec difference and I can't see how using
HIGHPRI is justified here (which is what the code is doing
_accidentally_ by using singlethread_workqueue).
On Tuesday 14 June 2011 08:34:00 Tejun Heo wrote:
Yeap, using a separate workqueue doesn't do anything for latency
unless WQ_HIGHPRI and/or WQ_CPU_INTENSIVE is used; however, _please_
stay away from it unless absolutely sure it's necessary (ie. unless
you can pin point to where latency is
On Tuesday 14 June 2011 09:31:30 Tejun Heo wrote:
Thanks for the explanation. I have a couple more questions.
* While transferring data from I2C, I suppose the work item is fully
occupying the CPU?
Not exactly on OMAP platforms at least. We do not have busy looping in low
level driver
On Tuesday 14 June 2011 10:18:36 Tejun Heo wrote:
I see, so IIUC,
* If it's using mutex and not holding CPU for the whole duration, you
shouldn't need to do anything special for latency for other work
items. Workqueue code will start executing other work items as soon
as the I2C work
Hi Tony,
On Monday 13 June 2011 15:35:43 Tony Lindgren wrote:
Sure we can merge fixes
Can you take this patch forward?
but let's get the move done before adding
new features.
What is considered a new feature here?
Is it a new feature, if I fix the McBSP for OMAP4 (FIFO usage, and small
On Tuesday 14 June 2011 13:23:51 Jarkko Nikula wrote:
We haven't seen any use for the SPI API in McBSP driver over the years. More
over, Peter Ujfalusi peter.ujfal...@ti.com noticed that SPI mode is not
even supported since OMAP2430 so it's very unlikely that we'll see any use
for it in the
On Sunday 12 June 2011 01:18:54 Dmitry Torokhov wrote:
+static void twl6040_vibra_enable(struct vibra_info *info)
+{
+ struct twl6040 *twl6040 = info-twl6040;
+ int ret = 0;
Initialization is not needed.
True.
+static void vibra_play_work(struct work_struct *work)
+{
+
2011/6/10 Péter Ujfalusi peter.ujfal...@ti.com:
1. when use Headset:
uplink routing:HSMIC -- AVTXR2PGA AVTXL2PGA -- VDXS VDXM -- PCM_VDX
downlink routing:PCM_VDR -- VDR -- VRXPGA Fine gain -- DAC voice
-- VDL_GAIN Analog PGA -- HSOL/HSOR
Thanks
I check the loopbacks,it seems that all
On Thursday 09 June 2011 22:37:28 Arnd Bergmann wrote:
Better use the -M flag to git-format-patch when moving files, to make it
obvious what has or has not changed, and to reduce the size of the email.
I tend to forgot the -M flag, thanks.
Also, shouldn't this file go into the sound/soc/
70 matches
Mail list logo
