Hi,
On 2018-01-15 20:55, Tony Lindgren wrote:
> * Mark Brown [180115 18:14]:
>> On Mon, Jan 15, 2018 at 10:06:26AM -0800, Tony Lindgren wrote:
>>> * Mark Brown [180115 17:56]:
>>
Sorry, I didn't actually post it - just suggested adding the
snd_soc_codec_set_regmap() call.
>>
>>> Oh I s
Hi Mark, Tony
> From tony Mon Sep 17 00:00:00 2001
> From: Tony Lindgren
> Date: Fri, 12 Jan 2018 10:24:36 -0800
> Subject: [PATCH] ASoC: Fix twl4030 and 6040 regression by adding back read
> and write
>
> Commit 3bb0f7c31b1a ("ASoC: don't use snd_soc_write/read on twl4030")
> caused regressio
* Kuninori Morimoto [180115 23:22]:
> > For the next set of changes like this,
> > please make sure you Cc the driver authors so they can test
> > and ack the changes if you can't test them, OK?
>
> Actually, I have posted "convert codec/platform to component"
> patch-set to ALSA ML, without Cc:i
* Mark Brown [180115 18:14]:
> On Mon, Jan 15, 2018 at 10:06:26AM -0800, Tony Lindgren wrote:
> > * Mark Brown [180115 17:56]:
>
> > > Sorry, I didn't actually post it - just suggested adding the
> > > snd_soc_codec_set_regmap() call.
>
> > Oh I see. Yeah that seems like a good long term soluti
On Mon, Jan 15, 2018 at 10:06:26AM -0800, Tony Lindgren wrote:
> * Mark Brown [180115 17:56]:
> > Sorry, I didn't actually post it - just suggested adding the
> > snd_soc_codec_set_regmap() call.
> Oh I see. Yeah that seems like a good long term solution after
> the regressions are fixed.
I wou
* Mark Brown [180115 17:56]:
> On Mon, Jan 15, 2018 at 09:52:20AM -0800, Tony Lindgren wrote:
> > * Mark Brown [180115 17:19]:
>
> > > Did anyone actually try testing the fix I posted yet?
>
> > Hmm I don't seem to have anything in my inbox. What might
> > be the subject for it?
>
> Sorry, I d
On Mon, Jan 15, 2018 at 09:52:20AM -0800, Tony Lindgren wrote:
> * Mark Brown [180115 17:19]:
> > Did anyone actually try testing the fix I posted yet?
> Hmm I don't seem to have anything in my inbox. What might
> be the subject for it?
Sorry, I didn't actually post it - just suggested adding t
* Mark Brown [180115 17:19]:
> On Mon, Jan 15, 2018 at 08:50:51AM -0800, Tony Lindgren wrote:
> > * Kuninori Morimoto [180115 01:46]:
>
> > > I hope your driver will be OK by using regmap.
> > > In worst case, we can back .read/.write, but it will be component driver
> > > side.
>
> > Well we
On Mon, Jan 15, 2018 at 08:50:51AM -0800, Tony Lindgren wrote:
> * Kuninori Morimoto [180115 01:46]:
> > I hope your driver will be OK by using regmap.
> > In worst case, we can back .read/.write, but it will be component driver
> > side.
> Well we have the merge window about to open in a week,
* Kuninori Morimoto [180115 01:46]:
>
> Hi all
>
> > > > Most devices have one regmap per device which can be retrieved with
> > > > dev_get_regmap(), it's the attempt to use that which I suspect is
> > > > broken. Like I said snd_soc_codec_init_regmap() ought to fix things if
> > > > that's th
Hi all
> > > Most devices have one regmap per device which can be retrieved with
> > > dev_get_regmap(), it's the attempt to use that which I suspect is
> > > broken. Like I said snd_soc_codec_init_regmap() ought to fix things if
> > > that's the issue.
>
> > OK. Adding Peter to loop as it's hi
On Fri, Jan 12, 2018 at 02:49:59PM -0800, Tony Lindgren wrote:
> * Mark Brown [180112 22:11]:
> > Most devices have one regmap per device which can be retrieved with
> > dev_get_regmap(), it's the attempt to use that which I suspect is
> > broken. Like I said snd_soc_codec_init_regmap() ought to
* Mark Brown [180112 22:11]:
> On Fri, Jan 12, 2018 at 01:50:10PM -0800, Tony Lindgren wrote:
>
> > > I rather suspect someone would've noticed by now TBH - I suspect this is
> > > more likely to be an issue with the rather baroque code that the TWL
> > > drivers have possibly coupled with the wh
On Fri, Jan 12, 2018 at 01:50:10PM -0800, Tony Lindgren wrote:
> > I rather suspect someone would've noticed by now TBH - I suspect this is
> > more likely to be an issue with the rather baroque code that the TWL
> > drivers have possibly coupled with the whole multiple I2C devices issue.
> Hmm t
* Mark Brown [180112 21:15]:
> On Fri, Jan 12, 2018 at 01:07:06PM -0800, Tony Lindgren wrote:
>
> > (twl4030_dummy_read [snd_soc_twl4030]) from []
> > (snd_soc_codec_drv_read+0x1c/0x28 [snd_soc_core])
> > (snd_soc_codec_drv_read [snd_soc_core]) from []
> > (snd_soc_dapm_new_widgets+0x29c/0x57
On Fri, Jan 12, 2018 at 01:07:06PM -0800, Tony Lindgren wrote:
> Tturns out just adding back .read = twl4030_read fixes it..
> I added a dummy function for read and am now seeing a bunch
> of reads that now don't happen:
What's supposed to happen here is that you end up with a
component->regmap s
On Fri, Jan 12, 2018 at 01:07:06PM -0800, Tony Lindgren wrote:
> (twl4030_dummy_read [snd_soc_twl4030]) from []
> (snd_soc_codec_drv_read+0x1c/0x28 [snd_soc_core])
> (snd_soc_codec_drv_read [snd_soc_core]) from []
> (snd_soc_dapm_new_widgets+0x29c/0x578 [snd_soc_core])
> (snd_soc_dapm_new_widg
* Mark Brown [180112 19:13]:
> On Fri, Jan 12, 2018 at 11:00:46AM -0800, Tony Lindgren wrote:
>
> > It's commit 3bb0f7c31b1a ("ASoC: don't use snd_soc_write/read
> > on twl4030"). And that is for the PMIC on my test system, so
> > adding Kuninori and Mark to the thread :)
>
> > Kuninori, it seem
On Fri, Jan 12, 2018 at 11:00:46AM -0800, Tony Lindgren wrote:
> It's commit 3bb0f7c31b1a ("ASoC: don't use snd_soc_write/read
> on twl4030"). And that is for the PMIC on my test system, so
> adding Kuninori and Mark to the thread :)
> Kuninori, it seems that commit 3bb0f7c31b1a causes higher
> p
* Tony Lindgren [180112 01:20]:
> * Andrew Morton [180112 00:45]:
> > On Thu, 11 Jan 2018 16:23:22 -0800 Tony Lindgren wrote:
> >
> > > * Andrew Morton [180112 00:18]:
> > > > On Thu, 11 Jan 2018 16:01:13 -0800 Tony Lindgren
> > > > wrote:
> > > >
> > > > > Hi all,
> > > > >
> > > > > I'm
* Andrew Lunn [180112 13:55]:
> > Thanks that fixes the suspend error. And I was able to confirm
> > that the suspend power consumption is OK.
> >
> > That still leaves the mystery of the runtime idle power consumption
> > being much higher with commit e130bc1d00a4.
>
> Did you re-measure the ru
> Thanks that fixes the suspend error. And I was able to confirm
> that the suspend power consumption is OK.
>
> That still leaves the mystery of the runtime idle power consumption
> being much higher with commit e130bc1d00a4.
Did you re-measure the runtime power? Do you have an unused PHY? It
co
* Andrew Lunn [180112 13:16]:
> On Fri, Jan 12, 2018 at 02:01:14PM +0100, Lars-Peter Clausen wrote:
> > On 01/12/2018 01:30 PM, Rafael J. Wysocki wrote:
> > > On Friday, January 12, 2018 1:23:54 PM CET Rafael J. Wysocki wrote:
> > >> On Friday, January 12, 2018 2:32:57 AM CET Tony Lindgren wrote:
On Fri, Jan 12, 2018 at 02:01:14PM +0100, Lars-Peter Clausen wrote:
> On 01/12/2018 01:30 PM, Rafael J. Wysocki wrote:
> > On Friday, January 12, 2018 1:23:54 PM CET Rafael J. Wysocki wrote:
> >> On Friday, January 12, 2018 2:32:57 AM CET Tony Lindgren wrote:
> >>> * Tony Lindgren [180111 17:20]:
On 01/12/2018 01:30 PM, Rafael J. Wysocki wrote:
> On Friday, January 12, 2018 1:23:54 PM CET Rafael J. Wysocki wrote:
>> On Friday, January 12, 2018 2:32:57 AM CET Tony Lindgren wrote:
>>> * Tony Lindgren [180111 17:20]:
Well I tried to measure suspend power consumption and noticed
that
On Friday, January 12, 2018 1:23:54 PM CET Rafael J. Wysocki wrote:
> On Friday, January 12, 2018 2:32:57 AM CET Tony Lindgren wrote:
> > * Tony Lindgren [180111 17:20]:
> > > Well I tried to measure suspend power consumption and noticed
> > > that system suspend fails too hand hangs the network d
On Friday, January 12, 2018 2:32:57 AM CET Tony Lindgren wrote:
> * Tony Lindgren [180111 17:20]:
> > Well I tried to measure suspend power consumption and noticed
> > that system suspend fails too hand hangs the network device:
> >
> > # echo mem > /sys/power/state
> > [ 32.577850] PM: suspend
* Tony Lindgren [180111 17:20]:
> Well I tried to measure suspend power consumption and noticed
> that system suspend fails too hand hangs the network device:
>
> # echo mem > /sys/power/state
> [ 32.577850] PM: suspend entry (deep)
> [ 32.582031] PM: Syncing filesystems ... done.
> [ 32.59
* Andrew Morton [180112 00:45]:
> On Thu, 11 Jan 2018 16:23:22 -0800 Tony Lindgren wrote:
>
> > * Andrew Morton [180112 00:18]:
> > > On Thu, 11 Jan 2018 16:01:13 -0800 Tony Lindgren wrote:
> > >
> > > > Hi all,
> > > >
> > > > I'm seeing a considerable idle power consumption regression in
>
On Thu, 11 Jan 2018 16:23:22 -0800 Tony Lindgren wrote:
> * Andrew Morton [180112 00:18]:
> > On Thu, 11 Jan 2018 16:01:13 -0800 Tony Lindgren wrote:
> >
> > > Hi all,
> > >
> > > I'm seeing a considerable idle power consumption regression in
> > > Linux next, with power consumption for my id
* Andrew Morton [180112 00:18]:
> On Thu, 11 Jan 2018 16:01:13 -0800 Tony Lindgren wrote:
>
> > Hi all,
> >
> > I'm seeing a considerable idle power consumption regression in
> > Linux next, with power consumption for my idle test system going
> > to 17.5mW compared to the usual 8mW on my test
On Thu, 11 Jan 2018 16:01:13 -0800 Tony Lindgren wrote:
> Hi all,
>
> I'm seeing a considerable idle power consumption regression in
> Linux next, with power consumption for my idle test system going
> to 17.5mW compared to the usual 8mW on my test device.
>
> Git bisect points to merge commit
Hi all,
I'm seeing a considerable idle power consumption regression in
Linux next, with power consumption for my idle test system going
to 17.5mW compared to the usual 8mW on my test device.
Git bisect points to merge commit e130bc1d00a4 ("Merge branch
'akpm-current/current'") being the first bad
33 matches
Mail list logo
