On Tue, Jan 15, 2019 at 03:26:42PM +, Jon Hunter wrote:
>
> On 14/01/2019 23:02, Mark Brown wrote:
> > On Fri, Jan 11, 2019 at 09:15:42AM +, Jon Hunter wrote:
> >> On 11/01/2019 08:51, Kuninori Morimoto wrote:
> >
> >>> So, can you agree about these ?
> >>> 1) Add enough information/docum
On 14/01/2019 23:02, Mark Brown wrote:
> On Fri, Jan 11, 2019 at 09:15:42AM +, 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 its
>>> plan.
>>> 2) Add dirty po
On Fri, Jan 11, 2019 at 09:15:42AM +, 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 its
> > plan.
> > 2) Add dirty pointer fixup patch as workaround
> > 3) switch
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 absol
Hi Jon
> > 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 absolutely it is a driver bug, but looking a
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 thi
Hi Jon
> 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. However, this
> looks quite fragile to me and is susceptible to leaking memory if the
> user/machine driver alre
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. How
Hi Mark, Jon again
> My posted quick-patch can solve "dirty pointer" issue,
> but it can't solve "memory leak" issue.
> This issue will be solved if all driver can switch to
> modern style, but it needs more time.
> Are these correct ?
Sorry I was very confused.
I think the issue is only "dirty
Hi Mark, Jon
> No. Offline you had suggested using kmalloc and not devm_kzalloc and so
> I was worried in that case about a memory leak. Right now I am only
> concerned about an invalid pointer that is not being handled correctly.
I'm sorry I was confused/misunderstood, kmalloc idea was wrong.
On Wed, Jan 09, 2019 at 02:11:58PM +, Jon Hunter wrote:
> 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 d
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 Wed, Jan 09, 2019 at 11:03:44AM +, Jon Hunter wrote:
> On 09/01/2019 01:51, Kuninori Morimoto wrote:
> > "multi platform" is no plan (?).
> I would like someone to explain what multi-platform means? Even if a
> soundcard supports multiple platforms, there is only one platform you
> are usi
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.
>
> OK
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.
OK, thanks.
It *will* be static, but not yet.
Thank you for you
On Tue, Jan 08, 2019 at 03:48:27PM +, Jon Hunter wrote:
> > 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.
> To be specific, the following also
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 issue occurring
all the time when the sound drivers are built
On Tue, Dec 18, 2018 at 06:40:40PM +0100, Matthias Reichl wrote:
> 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:
> > Indeed, this is a bit of a mess. We probably shouldn't be modifying the
> > data that the drivers pass
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 kernel modules and
>>> probing the sound card is
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 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.
>
> Commit daecf46ee0e5 ("ASoC: soc-core: use snd_soc_dai_link_compo
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 that the platform pointer
>>> can be allocate
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 that the platform pointer
> > can be allocated by the machine driver and so if it is not allocated by
> > the core,
On Fri, Oct 19, 2018 at 11:22:46AM +0100, Jon Hunter wrote:
> Looking at snd_soc_init_platform(), it seems that the platform pointer
> can be allocated by the machine driver and so if it is not allocated by
> the core, then I don't think we should clear it here. Seems we need a
> way to determine
On 18/10/2018 12:18, Marcel Ziswiler wrote:
> From: Marcel Ziswiler
>
> This fixes the following error as seen post commit daecf46ee0e5
> ("ASoC: soc-core: use snd_soc_dai_link_component for platform") on
> Apalis TK1 after initial probe deferral:
>
> tegra-snd-sgtl5000 sound: ASoC: Both platf
From: Marcel Ziswiler
This fixes the following error as seen post commit daecf46ee0e5
("ASoC: soc-core: use snd_soc_dai_link_component for platform") on
Apalis TK1 after initial probe deferral:
tegra-snd-sgtl5000 sound: ASoC: Both platform name/of_node are set for
sgtl5000
tegra-snd-sgtl5000 so
26 matches
Mail list logo
