I have a patch to fix the memory leak but I haven't been able to test
it yet because I am remote right now and I accidentally bootlooped the
AMD device I am working on. I will have this tested early next week.
Here is the patch for anyone interested.
Curtis Malainey | Software Engineer |
On Thu, Jan 24, 2019 at 01:07:17PM -0600, Pierre-Louis Bossart wrote:
> Thanks for the feedback, will send a formal patch with the helper and
> machine driver changes after I test more with the legacy drivers. Do you
> have a preference for one patch that deals with multiple machines drivers in
>
changes are legitimate. To move forward, maybe it's not worth spending too
much time on a grand unification of string theory, there are simpler
solutions: the Intel machine drivers already do get the platform driver name
as an platform_data argument, so we could modify the dailinks platform
On Tue, Jan 22, 2019 at 08:01:15PM -0600, Pierre-Louis Bossart wrote:
> changes are legitimate. To move forward, maybe it's not worth spending too
> much time on a grand unification of string theory, there are simpler
> solutions: the Intel machine drivers already do get the platform driver name
On 1/22/19 7:36 PM, Curtis Malainey wrote:
Curtis Malainey | Software Engineer | cujomalai...@google.com | 650-898-3849
On Wed, Jan 23, 2019 at 4:11 AM Pierre-Louis Bossart
wrote:
The issue was that we were seeing a memory corruption bug on an AMD
chromebooks with that function already
Curtis Malainey | Software Engineer | cujomalai...@google.com | 650-898-3849
On Wed, Jan 23, 2019 at 4:11 AM Pierre-Louis Bossart
wrote:
>
>
> > The issue was that we were seeing a memory corruption bug on an AMD
> > chromebooks with that function already (not observed on Intel). I was
> >
The issue was that we were seeing a memory corruption bug on an AMD
chromebooks with that function already (not observed on Intel). I was
testing some SOF integrations and was seeing this in the kernel logs.
I had Dylan verify my logic before I sent the patch because it took so
long to
On Fri, Jan 18, 2019 at 05:02:08PM -0600, Pierre-Louis Bossart wrote:
> This PROBE_DEFER support actually breaks the topology override that we've
> been relying on for SOF (and which has been in Mark's branch for some time
> now). This override helps us reuse machine drivers between legacy and
>
On Fri, Jan 18, 2019 at 05:15:32PM -0800, Curtis Malainey wrote:
> of_node was never getting set but the pointer was becoming populated
> (outside of the probe call) which traced to soc_init_platform function
> which was not reallocating memory on a EPROBE_DEFER even though it was
> getting freed
On Fri, Jan 18, 2019 at 5:12 PM Curtis Malainey wrote:
>
>
>
> On Fri, Jan 18, 2019 at 3:02 PM Pierre-Louis Bossart
> wrote:
>>
>>
>> On 1/15/19 3:16 PM, Pierre-Louis Bossart wrote:
>> >
>> >>> Beyond the fact that the platform_name seems to be totally useless,
>> >>> additional tests show that
On 1/15/19 3:16 PM, Pierre-Louis Bossart wrote:
Beyond the fact that the platform_name seems to be totally useless,
additional tests show that the patch ('ASoC: soc-core: defer card probe
until all component is added to list') adds a new restriction which
contradicts existing error checks.
On Tue, Jan 15, 2019 at 09:41:38PM +, Mark Brown wrote:
> On Tue, Jan 15, 2019 at 03:16:57PM -0600, Pierre-Louis Bossart wrote:
>
> > > Maybe the defer card probe logic needs to be extended to also check if
> > > dai_link_name had already been registered (either cpu or cpu_dai_name
> > >
On Tue, Jan 15, 2019 at 03:16:57PM -0600, Pierre-Louis Bossart wrote:
> > Maybe the defer card probe logic needs to be extended to also check if
> > dai_link_name had already been registered (either cpu or cpu_dai_name
> > needs to be set), not 100% sure which problem the defer card probe patch
>
Beyond the fact that the platform_name seems to be totally useless,
additional tests show that the patch ('ASoC: soc-core: defer card probe
until all component is added to list') adds a new restriction which
contradicts existing error checks.
None of the Intel machine drivers set the dailink
On Tue, Jan 15, 2019 at 01:35:07PM -0600, Pierre-Louis Bossart wrote:
>
> On 1/14/19 6:06 PM, Mark Brown wrote:
> > On Fri, Jan 11, 2019 at 03:49:08PM -0600, Pierre-Louis Bossart wrote:
> >
> > > Adding some traces I can see that the the platform name we use doesn't
> > > seem
> > > compatible
On Tue, Jan 15, 2019 at 01:35:07PM -0600, Pierre-Louis Bossart wrote:
> On 1/14/19 6:06 PM, Mark Brown wrote:
> > just pushing the breakage around rather than fixing it. Can someone
> > with an x86 system take a look and confirm exactly what's going on with
> > binding these cards please?
>
On 1/14/19 6:06 PM, Mark Brown wrote:
On Fri, Jan 11, 2019 at 03:49:08PM -0600, Pierre-Louis Bossart wrote:
Adding some traces I can see that the the platform name we use doesn't seem
compatible with your logic. All the Intel boards used a constant platform
name matching the PCI ID, see e.g.
On 1/14/19 6:06 PM, Mark Brown wrote:
On Fri, Jan 11, 2019 at 03:49:08PM -0600, Pierre-Louis Bossart wrote:
Adding some traces I can see that the the platform name we use doesn't seem
compatible with your logic. All the Intel boards used a constant platform
name matching the PCI ID, see e.g.
On Fri, Jan 11, 2019 at 03:49:08PM -0600, Pierre-Louis Bossart wrote:
> Adding some traces I can see that the the platform name we use doesn't seem
> compatible with your logic. All the Intel boards used a constant platform
> name matching the PCI ID, see e.g. [1], which IIRC is used to bind
>
On Sat, 2019-01-12 at 11:37 +0530, Rohit kumar wrote:
> On 1/12/2019 3:19 AM, Pierre-Louis Bossart wrote:
> > > Thanks for the overnight fix. This update fixes the issue on my
> > > Skylake XPS13 test device (blind testing since I don't understand
> > > what the code does).
> > >
> > >
On 1/12/2019 3:19 AM, Pierre-Louis Bossart wrote:
Thanks for the overnight fix. This update fixes the issue on my
Skylake XPS13 test device (blind testing since I don't understand
what the code does).
Tested-by: Pierre-Louis Bossart
I need to take this back, this set of changes
Thanks for the overnight fix. This update fixes the issue on my
Skylake XPS13 test device (blind testing since I don't understand what
the code does).
Tested-by: Pierre-Louis Bossart
I need to take this back, this set of changes (initial+fix) causes an
error with our HDMI support
[
On 1/11/19 2:14 AM, Rohit kumar wrote:
From: Ajit Pandey
soc_find_component() may lead to null pointer exception if both
arguments i.e of_node and name is NULL. Add NULL check before
calling soc_find_component(). Also fix some typos.
Thanks for the overnight fix. This update fixes the
23 matches
Mail list logo
