LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: Guenter Roeck <groeck@google.com>
To: shreyas.nc@intel.com
Cc: pierre-louis.bossart@linux.intel.com,
	alsa-devel@alsa-project.org,
	linux-kernel <linux-kernel@vger.kernel.org>,
	Takashi Iwai <tiwai@suse.com>,
	Liam Girdwood <lgirdwood@gmail.com>,
	Mark Brown <broonie@kernel.org>,
	"Patel, Chintan M" <chintan.m.patel@intel.com>,
	Guenter Roeck <groeck@chromium.org>
Subject: Re: [alsa-devel] [RFC/RFT PATCH] ASoC: topology: Improve backwards compatibility with v4 topology files
Date: Fri, 25 May 2018 10:41:46 -0700	[thread overview]
Message-ID: <CABXOdTem0f5zgZ+DvOVtWZ4Zw0JRak+oSOJyxHgMXCEEJ292Cg@mail.gmail.com> (raw)
In-Reply-To: <CABXOdTcrAoh_uhA=6AggUPFiGdFqwuFAHej50vK9gRMU9waUAQ@mail.gmail.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

      reply	other threads:[~2018-05-25 17:42 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-05-22 16:58 Guenter Roeck
2018-05-22 17:14 ` Mark Brown
2018-05-22 19:59 ` [alsa-devel] " Pierre-Louis Bossart
2018-05-23  8:24   ` Mark Brown
2018-05-23 13:42     ` Pierre-Louis Bossart
2018-05-23 13:56       ` Takashi Iwai
     [not found]         ` <CABXOdTdGyfBdZUzG-DzGgfr0Afrh9dtgdXibQreOZm7nb4z3=w@mail.gmail.com>
2018-05-23 14:58           ` Takashi Iwai
2018-05-23 15:52           ` Mark Brown
     [not found]   ` <CABXOdTd5+QJHOZ6BcSO-TfJCqcLzdd+Gbnf4HYh9i9cG+UH+1g@mail.gmail.com>
2018-05-23  9:49     ` Mark Brown
2018-05-23 13:54 ` Takashi Iwai
2018-05-23 13:56   ` Mark Brown
     [not found]     ` <CABXOdTeCr-ExO9O3XAHK-DnNf5yLGO0TPkXgs60TB90jGNB2_Q@mail.gmail.com>
2018-05-23 15:58       ` Mark Brown
2018-05-23 16:17         ` Guenter Roeck
2018-05-24  9:52           ` Takashi Iwai
2018-05-24 14:18           ` Mark Brown
2018-05-24 14:55             ` Guenter Roeck
2018-05-24 15:11               ` Mark Brown
2018-05-25  9:04                 ` [alsa-devel] " Lin, Mengdong
2018-05-25 13:20                   ` Guenter Roeck
2018-05-23 16:29   ` Guenter Roeck
2018-05-23 20:28 ` [alsa-devel] " Pierre-Louis Bossart
2018-05-23 21:22   ` Guenter Roeck
2018-05-24  3:38     ` Pierre-Louis Bossart
2018-05-25 13:40     ` Shreyas NC
2018-05-25 14:09       ` Guenter Roeck
2018-05-25 17:41         ` Guenter Roeck [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CABXOdTem0f5zgZ+DvOVtWZ4Zw0JRak+oSOJyxHgMXCEEJ292Cg@mail.gmail.com \
    --to=groeck@google.com \
    --cc=alsa-devel@alsa-project.org \
    --cc=broonie@kernel.org \
    --cc=chintan.m.patel@intel.com \
    --cc=groeck@chromium.org \
    --cc=lgirdwood@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=pierre-louis.bossart@linux.intel.com \
    --cc=shreyas.nc@intel.com \
    --cc=tiwai@suse.com \
    --subject='Re: [alsa-devel] [RFC/RFT PATCH] ASoC: topology: Improve backwards compatibility with v4 topology files' \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).