Re: [alsa-devel] [RFC/RFT PATCH] ASoC: topology: Improve backwards compatibility with v4 topology files

[Guenter Roeck <groeck@google.com>]

On Fri, May 25, 2018 at 7:09 AM Guenter Roeck <groeck@google.com> wrote:

> On Fri, May 25, 2018 at 6:42 AM Shreyas NC <shreyas.nc@intel.com> wrote:

> > > > > +struct skl_dfw_v4_pipe {
> > > > > +     u8 pipe_id;
> > > > > +     u8 pipe_priority;
> > > > > +     u16 conn_type:4;
> > > > > +     u16 rsvd:4;
> > > > > +     u16 memory_pages:8;
> > > > > +} __packed;
> > > > > +
> > > > > +struct skl_dfw_v4_module {
> > > > > +     char uuid[SKL_UUID_STR_SZ];
> > > > > +

> > Any reason to not have this as u8?
> > commit 09305da97c7808b900985526aa9198233f32fb37 had changed this to u8..

> No reason. I'll fix it.


You confused me. Commit 09305da97c7808b900985526aa9198233f32fb37 changed
the uuid format in the configuration file from 40-byte string to 16-byte
binary. This is
an ABI change. As such, yes, there is a reason for 'char'. It is because v4
of the
configuration file, at least v4 as defined up to and including upstream
kernel v4.6,
provide the uuid as string, not as 16-byte hex value.

That this ABI change was made without ABI version number change is another
issue.

Guenter

> > <snip>

> > > > > +
> > > > > +     mconfig->params_fixup = dfw->params_fixup;
> > > > > +     mconfig->converter = dfw->converter;
> > > > > +     mconfig->m_type = dfw->module_type;
> > > > > +     mconfig->vbus_id = dfw->vbus_id;
> > > > > +     mconfig->module->resources[0].is_pages = dfw->mem_pages;
> > > > > +
> > > > > +     ret = skl_tplg_add_pipe_v4(dev, mconfig, skl, &dfw->pipe);
> > > > > +     if (ret)
> > > > > +             return ret;
> > > > > +
> > > > > +     mconfig->dev_type = dfw->dev_type;
> > > > > +     mconfig->hw_conn_type = dfw->hw_conn_type;
> > > > > +     mconfig->time_slot = dfw->time_slot;
> > > > > +     mconfig->formats_config.caps_size = dfw->caps.caps_size;
> > >
> > > > chromeos-3.18 has this:
> > > >       if (dfw_config->is_loadable)
> > > >           memcpy(mconfig->guid, dfw_config->uuid,
> > > >                       ARRAY_SIZE(dfw_config->uuid));
> > >
> > > > Is this needed here?
> > >
> > >
> > > Direct memcpy doesn't work anymore since the uuid format is different.
> The
> > > above is replaced
> > > with (unconditional)
> > >
> > >          ret = guid_parse(dfw->uuid, (guid_t *)mconfig->guid);
> > >          if (ret)
> > >                  return ret;
> > >
> > > at the beginning of skl_tplg_get_pvt_data_v4(). The new code, as far
as
> I
> > > can see, loads
> > > the uuid unconditionally if it finds SND_SOC_TPLG_TUPLE_TYPE_UUID. I
> wanted
> > > to
> > > be on the safe side and decided to do the same.
> > >

> > In the new code, still does a memcpy(). So, I am not sure if I
understand
> > why memcpy() does not work.

> >          if (uuid_tkn->token == SKL_TKN_UUID) {
> >                  memcpy(guid, &uuid_tkn->uuid, 16);
> >                  return 0;
> >          }

> The new (v5) configuration files provide the uuid as binary and no longer
> as text.

> Guenter