On 25/02/2019 21:11, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.14.104 release.
> There are 71 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know.
>
> Responses
On 25/02/2019 21:11, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.9.161 release.
> There are 63 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know.
>
> Responses
On 25/02/2019 21:03, Trond Myklebust wrote:
> On Mon, 2019-02-25 at 20:25 +0000, Jon Hunter wrote:
>> Hi Trond,
>>
>> Starting in next-20190222 I have observed a regression with NFS
>> causing
>> some of our boards to fail to boot. Bisect point
Hi Trond,
Starting in next-20190222 I have observed a regression with NFS causing
some of our boards to fail to boot. Bisect points to your commit ...
commit 0ffe86f48026b7f34db22d1004bc9992f0db8b33
Author: Trond Myklebust
Date: Wed Jan 30 14:51:26 2019 -0500
SUNRPC: Use poll() to fix up
On 21/02/2019 14:35, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.19.25 release.
> There are 30 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know.
>
> Responses
On 21/02/2019 14:35, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.14.103 release.
> There are 23 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know.
>
> Responses
On 21/02/2019 14:35, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.9.160 release.
> There are 20 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know.
>
> Responses
On 21/02/2019 14:35, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.4.176 release.
> There are 20 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know.
>
> Responses
On 12/02/2019 19:06, Sowjanya Komatineni wrote:
> This patch adds DMA support for Tegra I2C.
>
> Tegra I2C TX and RX FIFO depth is 8 words. PIO mode is used for
> transfer size of the max FIFO depth and DMA mode is used for
> transfer size higher than max FIFO depth to save CPU overhead.
>
>
dding a new field to struct device_link,
> but I coulnd't find a cleaner way to address the issue that would
> work in all cases.]
>
> Fixes: 4c06c4e6cf63 ("driver core: Fix possible supplier PM-usage counter
> imbalance")
> Reported-by: Jon Hunter
> Signed-of
On 18/02/2019 13:43, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.14.102 release.
> There are 62 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know.
>
> Responses
On 18/02/2019 13:43, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.9.159 release.
> There are 58 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know.
>
> Responses
On 18/02/2019 13:42, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.4.175 release.
> There are 143 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know.
>
> Responses
On 18/02/2019 12:12, Rafael J. Wysocki wrote:
> On Fri, Feb 15, 2019 at 5:44 PM Jon Hunter wrote:
>>
>>
>> On 15/02/2019 14:37, Ulf Hansson wrote:
>>> On Fri, 15 Feb 2019 at 12:00, Jon Hunter wrote:
>>>>
>>>> Hi Rafael,
>>>
eq->dev.parent);
>>
>> switch (event) {
>> case DEVFREQ_GOV_START:
>> @@ -600,7 +597,7 @@ static int tegra_governor_event_handler(struct devfreq
>> *devfreq,
>> break;
>> }
>>
>> -return ret;
>> +return 0;
>> }
>>
>> static struct devfreq_governor tegra_devfreq_governor = {
>>
>
> Reviewed-by: Chanwoo Choi
>
Acked-by: Jon Hunter
Thanks!
Jon
--
nvpublic
On 18/02/2019 08:42, Thierry Reding wrote:
> On Sat, Feb 16, 2019 at 08:33:07AM -0800, Sowjanya Komatineni wrote:
>> Tegra186 does not support multi-master mode and also there is no
>> master fifo control register.
>>
>> This patch fixes supported features of Tegra186 and prevents
>> crashing
On 15/02/2019 14:37, Ulf Hansson wrote:
> On Fri, 15 Feb 2019 at 12:00, Jon Hunter wrote:
>>
>> Hi Rafael,
>>
>> On 12/02/2019 12:08, Rafael J. Wysocki wrote:
>>> From: Rafael J. Wysocki
>>>
>>> If a stateless device link to a certain
On 15/02/2019 13:21, Jon Hunter wrote:
>
> On 15/02/2019 12:06, Rafael J. Wysocki wrote:
>> On Friday, February 15, 2019 12:00:27 PM CET Jon Hunter wrote:
>>> Hi Rafael,
>>>
>>> On 12/02/2019 12:08, Rafael J. Wysocki wrote:
>>>> From: Rafa
On 15/02/2019 12:06, Rafael J. Wysocki wrote:
> On Friday, February 15, 2019 12:00:27 PM CET Jon Hunter wrote:
>> Hi Rafael,
>>
>> On 12/02/2019 12:08, Rafael J. Wysocki wrote:
>>> From: Rafael J. Wysocki
>>>
>>> If a stateless device link to a
Hi Rafael,
On 12/02/2019 12:08, Rafael J. Wysocki wrote:
> From: Rafael J. Wysocki
>
> If a stateless device link to a certain supplier with
> DL_FLAG_PM_RUNTIME set in the flags is added and then removed by the
> consumer driver's probe callback, the supplier's PM-runtime usage
> counter will
On 13/02/2019 18:37, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.14.100 release.
> There are 35 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know.
>
> Responses
On 13/02/2019 18:37, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.9.157 release.
> There are 24 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know.
>
> Responses
On 11/02/2019 14:16, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.14.99 release.
> There are 205 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know.
>
> Responses
On 11/02/2019 14:18, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.9.156 release.
> There are 137 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know.
>
> Responses
On 07/02/2019 11:41, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.4.174 release.
> There are 34 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know.
>
> Responses
On 04/02/2019 10:36, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.9.155 release.
> There are 30 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know.
>
> Responses
On 04/02/2019 10:36, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.14.98 release.
> There are 46 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know.
>
> Responses
On 04/02/2019 10:35, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.4.173 release.
> There are 65 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know.
>
> Responses
On 04/02/2019 08:16, Sameer Pujar wrote:
...
> Objective is to have things working with or without CONFIG_PM enabled.
> From previous comments and discussions it appears that there is mixed
> response
> for calling hda_tegra_runtime_resume() or runtime PM APIs in probe()
> call. Need
> to have
On 04/02/2019 08:45, Thierry Reding wrote:
...
> The idea was, as I was saying below, to reuse dev_pm_ops even if
> !CONFIG_PM. So pm_runtime_enable() could be something like this:
>
> pm_runtime_enable(dev)
> {
> if (!CONFIG_PM)
> if
r CPUPORESET signal. So it can't be a wake-up
> source when CPU suspends in power down state.
>
> Also convert the original driver to use timer-of API.
>
> Cc: Daniel Lezcano
> Cc: Thomas Gleixner
> Cc: linux-kernel@vger.kernel.org
> Signed-off-by: Joseph Lo
> Ac
On 01/02/2019 14:39, Joseph Lo wrote:
> On 2/1/19 8:44 PM, Jon Hunter wrote:
>>
>> On 01/02/2019 03:36, Joseph Lo wrote:
>>> Add support for the Tegra210 timer that runs at oscillator clock
>>> (TMR10-TMR13). We need these timers to work as clock event de
On 01/02/2019 13:11, Dmitry Osipenko wrote:
> 01.02.2019 16:06, Dmitry Osipenko пишет:
>> 01.02.2019 6:36, Joseph Lo пишет:
>>> Add support for the Tegra210 timer that runs at oscillator clock
>>> (TMR10-TMR13). We need these timers to work as clock event device and to
>>> replace the ARMv8
On 01/02/2019 03:36, Joseph Lo wrote:
> Add support for the Tegra210 timer that runs at oscillator clock
> (TMR10-TMR13). We need these timers to work as clock event device and to
> replace the ARMv8 architected timer due to it can't survive across the
> power cycle of the CPU core or CPUPORESET
On 30/01/2019 12:50, Jon Hunter wrote:
>
> On 29/01/2019 11:35, Greg Kroah-Hartman wrote:
>> This is the start of the stable review cycle for the 4.9.154 release.
>> There are 44 patches in this series, all will be posted as a response
>> to this one. If anyone has any
On 29/01/2019 11:35, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.14.97 release.
> There are 68 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know.
>
> Responses
On 29/01/2019 11:35, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.9.154 release.
> There are 44 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know.
>
> Responses
IG_PM check
>
> Signed-off-by: Sameer Pujar
> Reviewed-by: Ravindra Lokhande
> Reviewed-by: Jon Hunter
> ---
> sound/pci/hda/hda_tegra.c | 26 +-
> 1 file changed, 17 insertions(+), 9 deletions(-)
>
> diff --git a/sound/pci/hda/hda_tegra.c b/sou
On 30/01/2019 10:56, Sameer Pujar wrote:
>
> On 1/30/2019 4:09 PM, Takashi Iwai wrote:
>> On Wed, 30 Jan 2019 10:35:35 +0100,
>> Jon Hunter wrote:
>>>
>>> On 28/01/2019 06:06, Sameer Pujar wrote:
>>>> On 1/25/2019 7:34 PM, Jon Hunter wrot
On 28/01/2019 06:06, Sameer Pujar wrote:
>
> On 1/25/2019 7:34 PM, Jon Hunter wrote:
>> On 25/01/2019 13:58, Takashi Iwai wrote:
>>> On Fri, 25 Jan 2019 14:26:27 +0100,
>>> Jon Hunter wrote:
>>>>
>>>> On 25/01/2019 12:40, Takashi Iwai wrot
On 29/01/2019 03:35, Joseph Lo wrote:
> On 1/28/19 11:09 PM, Thierry Reding wrote:
>> On Mon, Jan 28, 2019 at 05:18:11PM +0800, Joseph Lo wrote:
>>> Add support for the Tegra210 timer that runs at oscillator clock
>>> (TMR10-TMR13). We need these timers to work as clock event device and to
>>>
On 24/01/2019 19:19, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.14.96 release.
> There are 63 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know.
>
> Responses
On 24/01/2019 19:20, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.9.153 release.
> There are 39 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know.
>
> Responses
On 24/01/2019 19:18, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.4.172 release.
> There are 104 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know.
>
> Responses
On 25/01/2019 13:58, Takashi Iwai wrote:
> On Fri, 25 Jan 2019 14:26:27 +0100,
> Jon Hunter wrote:
>>
>>
>> On 25/01/2019 12:40, Takashi Iwai wrote:
>>> On Fri, 25 Jan 2019 12:36:00 +0100,
>>> Jon Hunter wrote:
>>>>
>>>>
>>
On 25/01/2019 12:40, Takashi Iwai wrote:
> On Fri, 25 Jan 2019 12:36:00 +0100,
> Jon Hunter wrote:
>>
>>
>> On 24/01/2019 19:08, Takashi Iwai wrote:
>>> On Thu, 24 Jan 2019 18:36:43 +0100,
>>> Sameer Pujar wrote:
>>>>
>>>> If C
On 25/01/2019 12:19, Sameer Pujar wrote:
>
> On 1/25/2019 5:12 PM, Jon Hunter wrote:
>> On 25/01/2019 11:06, Sameer Pujar wrote:
>>> If CONFIG_PM is disabled or runtime PM calls are forbidden, the clocks
>>> will not be ON. This could cause issue during probe, wh
On 25/01/2019 12:01, Jon Hunter wrote:
>
> On 25/01/2019 03:23, Joseph Lo wrote:
>> Hi Jon,
>>
>> Thanks for reviewing.
>>
>> On 1/24/19 6:30 PM, Jon Hunter wrote:
>>>
>>> On 07/01/2019 03:28, Joseph Lo wrote:
>>>> The Tegra210
On 25/01/2019 03:23, Joseph Lo wrote:
> Hi Jon,
>
> Thanks for reviewing.
>
> On 1/24/19 6:30 PM, Jon Hunter wrote:
>>
>> On 07/01/2019 03:28, Joseph Lo wrote:
>>> The Tegra210 timer provides fourteen 29-bit timer counters and one
>>> 32-bit
IG_PM check
>
> Signed-off-by: Sameer Pujar
> Reviewed-by: Ravindra Lokhande
> Reviewed-by: Jon Hunter
> ---
> sound/pci/hda/hda_tegra.c | 26 +-
> 1 file changed, 17 insertions(+), 9 deletions(-)
>
> diff --git a/sound/pci/hda/hda_tegra.c b/sou
t; and exit gracefully.
>> * In remove path runtime PM is disabled before calling snd_card_free().
>> * hda_tegra_disable_clocks() is moved out of CONFIG_PM_SLEEP check.
>> * runtime PM callbacks moved out of CONFIG_PM check
>>
>> Signed-off-by: Sameer Pujar
&g
On 07/01/2019 03:28, Joseph Lo wrote:
> Add support for the Tegra210 timer that runs at oscillator clock
> (TMR10-TMR13). We need these timers to work as clock event device and to
> replace the ARMv8 architected timer due to it can't survive across the
> power cycle of the CPU core or CPUPORESET
On 07/01/2019 03:28, Joseph Lo wrote:
> The Tegra210 timer provides fourteen 29-bit timer counters and one 32-bit
> timestamp counter. The TMRs run at either a fixed 1 MHz clock rate derived
> from the oscillator clock (TMR0-TMR9) or directly at the oscillator clock
> (TMR10-TMR13). Each TMR can
On 21/01/2019 13:43, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.14.95 release.
> There are 59 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know.
>
> Responses
On 21/01/2019 13:43, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.9.152 release.
> There are 51 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know.
>
> Responses
On 17/01/2019 20:39, Sowjanya Komatineni wrote:
> increase transfer timeout to 10s to allow enough time during max
> transfer size.
>
> Signed-off-by: Sowjanya Komatineni
> ---
> drivers/i2c/busses/i2c-tegra.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git
On 16/01/2019 17:11, Greg Kroah-Hartman wrote:
> On Wed, Jan 16, 2019 at 04:56:08PM +0000, Jon Hunter wrote:
>>
>> On 16/01/2019 16:02, Greg Kroah-Hartman wrote:
>>> On Wed, Jan 16, 2019 at 09:25:12AM +, Jon Hunter wrote:
>>>>
>>>&g
On 16/01/2019 16:02, Greg Kroah-Hartman wrote:
> On Wed, Jan 16, 2019 at 09:25:12AM +0000, Jon Hunter wrote:
>>
>> On 15/01/2019 16:35, Greg Kroah-Hartman wrote:
>>> This is the start of the stable review cycle for the 4.14.94 release.
>>> There are 27 patches i
On 15/01/2019 21:25, Mark Brown wrote:
> On Tue, Jan 15, 2019 at 09:58:55PM +0100, Martin Sperl wrote:
>
>> Maybe a bigger change to the reduce the complexity of
>> the state machine would solve that problem and also
>> reduce code complexity...
>
> Yeah, that's where I was getting to with
On 15/01/2019 17:39, ker...@martin.sperl.org wrote:
> Hi John!
>
>> On 15.01.2019, at 15:26, Jon Hunter wrote:
>>> Looks as if there is something missing in spi_stop_queue that
>>> would wake the worker thread one last time without any delays
>>>
On 15/01/2019 16:35, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.14.94 release.
> There are 27 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know.
>
> Responses
On 15/01/2019 16:35, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.9.151 release.
> There are 16 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know.
>
> Responses
On 15/01/2019 15:10, Mark Brown wrote:
> On Tue, Jan 15, 2019 at 02:26:02PM +0000, Jon Hunter wrote:
>
>> It seems that __spi_pump_messages() is getting called several times
>> during boot when registering the spi-flash, then after the spi-flash has
>> been registe
On 14/01/2019 23:02, Mark Brown wrote:
> On Fri, Jan 11, 2019 at 09:15:42AM +0000, Jon Hunter wrote:
>> On 11/01/2019 08:51, Kuninori Morimoto wrote:
>
>>> So, can you agree about these ?
>>> 1) Add enough information/documentation about legacy/modern style and i
Hi Martin,
On 14/01/2019 22:01, Martin Sperl wrote:
> Hi Jon,
>
> On 14.01.2019, at 16:35, Jon Hunter <mailto:jonath...@nvidia.com>> wrote:
>
>> Hi Martin, Mark,
>>
>> [ 58.222033] spi_master spi1: could not stop message queue
>> [
Hi Martin, Mark,
I have noticed that system suspend has started failing consistently on a
couple Tegra boards over the last few days with the linux-next branch.
The following error is seen on on entering suspend ...
[ 58.222033] spi_master spi1: could not stop message queue
[ 58.222038]
On 11/01/2019 08:51, Kuninori Morimoto wrote:
>>> Indeed there is such case so far, but my understanding is that current
>>> driver should select "legacy style" or "modern style".
>>> If driver setup it as "legacy", but access to "modern" member,
>>> it is driver side bug, right ?
>>
>> Yes
On 10/01/2019 16:48, Mark Brown wrote:
> On Thu, Jan 10, 2019 at 12:13:36PM +0000, Jon Hunter wrote:
>> On 09/01/2019 18:36, Mark Brown wrote:
>>> On Tue, Jan 08, 2019 at 05:28:14PM +, Jon Hunter wrote:
>
>>>> - struct snd_soc_dai_link_co
On 11/01/2019 00:52, Kuninori Morimoto wrote:
...
>> It is still fragile. Again the machine driver could have incorrectly set
>> these 'allocated_platform/codecs' members as they are exposed to the
>> machine driver. You have no way to determine if the machine driver is
>> doing the correct
On 09/01/2019 18:36, Mark Brown wrote:
> On Tue, Jan 08, 2019 at 05:28:14PM +0000, Jon Hunter wrote:
>
>> --- a/include/sound/soc.h
>> +++ b/include/sound/soc.h
>> @@ -925,7 +925,7 @@ struct snd_soc_dai_link {
>> */
>> const char *platf
On 10/01/2019 01:16, Kuninori Morimoto wrote:
...
> As I mentioned above, I think we have same issue on codec side too.
Actually no. Looking at snd_soc_init_multicodec() it always allocates
memory if any of the 'legacy' codec members
(codec_name/codec_of_node/codec_dai_name) are populated.
On 09/01/2019 12:53, Mark Brown wrote:
...
>> Yes that is an alternative and I can convert all the Tegra machine
>> drivers to use this now. However, that will not solve the problem for
>> non-Tegra devices and everyone will have to do this.
>
> We're going to have to go through another round
On 09/01/2019 01:51, Kuninori Morimoto wrote:
>
> Hi Jon
>
> Thank you for your help
>
>>> Yes so this does workaround the problem. However, per my previous
>>> comments, I would like to explore whether it is necessary to allocate
>>> the platform link component or if it can be static.
>
>
mponent structure, make it a
>> static member of the snd_soc_dai_link to fix the problem.
>>
>> It should be noted that if the platform_name of platform_of_node members
>> of the snd_soc_dai_link structure are populated, these will always be
>> used regardless of if the new pl
On 08/01/2019 12:19, Greg Kroah-Hartman wrote:
> On Mon, Jan 07, 2019 at 01:31:48PM +0100, Greg Kroah-Hartman wrote:
>> This is the start of the stable review cycle for the 4.14.92 release.
>> There are 101 patches in this series, all will be posted as a response
>> to this one. If anyone has
On 08/01/2019 12:19, Greg Kroah-Hartman wrote:
> On Tue, Jan 08, 2019 at 01:18:22PM +0100, Greg Kroah-Hartman wrote:
>> On Mon, Jan 07, 2019 at 01:32:29PM +0100, Greg Kroah-Hartman wrote:
>>> This is the start of the stable review cycle for the 4.9.149 release.
>>> There are 71 patches in this
: soc-core: use snd_soc_dai_link_component for
platform")
Reported-by: Marcel Ziswiler
Signed-off-by: Jon Hunter
---
include/sound/simple_card_utils.h | 2 +-
include/sound/soc.h | 2 +-
sound/soc/generic/audio-graph-card.c | 4 +++-
sound/soc/generic/simple-card-util
On 08/01/2019 12:03, Jon Hunter wrote:
>
> On 08/01/2019 10:50, Jon Hunter wrote:
>> Hi Kuninori,
>>
>> On 08/01/2019 02:25, Kuninori Morimoto wrote:
>>>
>>> Hi Jon
>>>
>>>> I have been looking at this again recently. I see this iss
On 08/01/2019 10:50, Jon Hunter wrote:
> Hi Kuninori,
>
> On 08/01/2019 02:25, Kuninori Morimoto wrote:
>>
>> Hi Jon
>>
>>> I have been looking at this again recently. I see this issue occurring
>>> all the time when the sound drivers are built as
Hi Kuninori,
On 08/01/2019 02:25, Kuninori Morimoto wrote:
>
> Hi Jon
>
>> I have been looking at this again recently. I see this issue occurring
>> all the time when the sound drivers are built as kernel modules and
>> probing the sound card is deferred until the codec driver has been loaded.
Hi Mark, Kuninori
On 18/12/2018 17:40, Matthias Reichl wrote:
> Hi Mark,
>
> On Sun, Oct 21, 2018 at 12:23:01PM +0100, Mark Brown wrote:
>> On Fri, Oct 19, 2018 at 11:22:46AM +0100, Jon Hunter wrote:
>>
>>> Looking at snd_soc_init_platform(), it seems tha
On 20/12/2018 09:17, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.14.90 release.
> There are 72 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know.
>
> Responses
On 20/12/2018 09:18, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.9.147 release.
> There are 61 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know.
>
> Responses
: 61866523ed6e ("clk: tegra30: Use Tegra CPU powergate helper function")
Reported-by: Arnd Bergmann
Signed-off-by: Jon Hunter
---
drivers/soc/tegra/pmc.c | 2 --
include/soc/tegra/pmc.h | 2 --
2 files changed, 4 deletions(-)
diff --git a/drivers/soc/tegra/pmc.c b/drivers/soc/tegra/pmc.c
index 8c
On 12/12/2018 13:31, Thierry Reding wrote:
> On Wed, Dec 12, 2018 at 11:47:32AM +0000, Jon Hunter wrote:
>>
>> On 11/12/2018 17:21, Stephen Boyd wrote:
>>> Quoting Arnd Bergmann (2018-12-11 06:35:07)
>>>> When CONFIG_SMP is disabled, the tegra clk driver now f
On 11/12/2018 17:21, Stephen Boyd wrote:
> Quoting Arnd Bergmann (2018-12-11 06:35:07)
>> When CONFIG_SMP is disabled, the tegra clk driver now fails to build:
>>
>> drivers/clk/tegra/clk-tegra30.c: In function 'tegra30_cpu_rail_off_ready':
>> drivers/clk/tegra/clk-tegra30.c:1151:19: error:
On 06/12/2018 14:38, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.14.87 release.
> There are 55 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know.
>
> Responses
On 06/12/2018 14:38, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.14.87 release.
> There are 55 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know.
>
> Responses
On 06/12/2018 14:37, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.9.144 release.
> There are 101 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know.
>
> Responses
On 06/12/2018 14:37, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.9.144 release.
> There are 101 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know.
>
> Responses
On 04/12/2018 10:48, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.14.86 release.
> There are 146 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know.
>
> Responses
On 04/12/2018 10:48, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.14.86 release.
> There are 146 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know.
>
> Responses
On 04/12/2018 10:49, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.9.143 release.
> There are 50 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know.
>
> Responses
On 04/12/2018 10:49, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.9.143 release.
> There are 50 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know.
>
> Responses
On 30/11/2018 15:29, Greg Kroah-Hartman wrote:
> On Thu, Nov 29, 2018 at 03:11:30PM +0100, Greg Kroah-Hartman wrote:
>> This is the start of the stable review cycle for the 4.14.85 release.
>> There are 100 patches in this series, all will be posted as a response
>> to this one. If anyone has
On 30/11/2018 15:29, Greg Kroah-Hartman wrote:
> On Thu, Nov 29, 2018 at 03:11:30PM +0100, Greg Kroah-Hartman wrote:
>> This is the start of the stable review cycle for the 4.14.85 release.
>> There are 100 patches in this series, all will be posted as a response
>> to this one. If anyone has
instead.
Signed-off-by: Jon Hunter
Acked-by: Thierry Reding
---
Resending with Thierry's ACK and CC'ing clock maintainers.
drivers/clk/tegra/clk-audio-sync.c | 3 +--
drivers/clk/tegra/clk-tegra-audio.c | 7 ++-
drivers/clk/tegra/clk-tegra114.c| 9 -
drivers/clk/tegra/clk-tegra124
instead.
Signed-off-by: Jon Hunter
Acked-by: Thierry Reding
---
Resending with Thierry's ACK and CC'ing clock maintainers.
drivers/clk/tegra/clk-audio-sync.c | 3 +--
drivers/clk/tegra/clk-tegra-audio.c | 7 ++-
drivers/clk/tegra/clk-tegra114.c| 9 -
drivers/clk/tegra/clk-tegra124
clock driver is the only public user of
tegra_powergate_is_powered() and so by updating the Tegra30 clock
driver to use tegra_pmc_cpu_is_powered(), we can then make
tegra_powergate_is_powered() a non-public function.
Signed-off-by: Jon Hunter
Acked-by: Thierry Reding
---
Resending with Thierry's ACK
clock driver is the only public user of
tegra_powergate_is_powered() and so by updating the Tegra30 clock
driver to use tegra_pmc_cpu_is_powered(), we can then make
tegra_powergate_is_powered() a non-public function.
Signed-off-by: Jon Hunter
Acked-by: Thierry Reding
---
Resending with Thierry's ACK
701 - 800 of 3084 matches
Mail list logo
