All of lore.kernel.org
 help / color / mirror / Atom feed
From: Tomasz Figa <tomasz.figa@gmail.com>
To: Padma Venkat <padma.kvr@gmail.com>
Cc: devicetree@vger.kernel.org, alsa-devel@alsa-project.org,
	linux-samsung-soc <linux-samsung-soc@vger.kernel.org>,
	Padmavathi Venna <padma.v@samsung.com>,
	abrestic@chromium.org, Tomasz Figa <t.figa@samsung.com>,
	"broonie@kernel.org" <broonie@kernel.org>,
	Kukjin Kim <kgene.kim@samsung.com>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>
Subject: Re: [PATCH V3 2/3] ASoC: Samsung: I2S: Add quirks as driver data in I2S
Date: Thu, 08 Aug 2013 10:10:27 +0200	[thread overview]
Message-ID: <3759902.V2gf68Lg3g@flatron> (raw)
In-Reply-To: <CAAgF-BdpsgQk8myq7OOk5zJ8Zxy+J6LUPb3-d40+iE2aNwdwDw@mail.gmail.com>

On Thursday 08 of August 2013 13:13:02 Padma Venkat wrote:
> Hi Tomasz,
> 
> On Wed, Aug 7, 2013 at 4:43 PM, Tomasz Figa <t.figa@samsung.com> wrote:
> > Ahh, one more thing inline.
> 
> [snip]
> 
> >> +static struct samsung_i2s_dai_data i2sv3_dai_type = {
> >> +     .dai_type = TYPE_PRI,
> >> +     .quirks = QUIRK_NO_MUXPSR,
> >> +};
> >> +
> >> +static struct samsung_i2s_dai_data i2sv4_dai_type = {
> >> +     .dai_type = TYPE_PRI,
> >> +     .quirks = QUIRK_PRI_6CHAN | QUIRK_NO_MUXPSR,
> >> +};
> >> +
> >> +static struct samsung_i2s_dai_data i2sv5_c100_dai_type = {
> >> +     .dai_type = TYPE_PRI,
> >> +     .quirks = QUIRK_PRI_6CHAN | QUIRK_NO_MUXPSR | QUIRK_SEC_DAI |
> >> +                     QUIRK_NEED_RSTCLR,
> >> +};
> >> +
> >> +static struct samsung_i2s_dai_data i2sv5_dai_type = {
> >> +     .dai_type = TYPE_PRI,
> >> +     .quirks = QUIRK_PRI_6CHAN | QUIRK_SEC_DAI | QUIRK_NEED_RSTCLR,
> >> +};
> >> +
> >> +static struct samsung_i2s_dai_data samsung_dai_type_sec = {
> >> +     .dai_type = TYPE_SEC,
> >> +};
> >> +
> >> 
> >>  static struct platform_device_id samsung_i2s_driver_ids[] = {
> >>  
> >>       {
> >> 
> >> -             .name           = "samsung-i2s",
> >> -             .driver_data    = TYPE_PRI,
> >> +             .name           = "samsung,s3c6410-i2s",
> >> +             .driver_data    = (kernel_ulong_t)&i2sv3_dai_type,
> >> +     }, {
> >> +             .name           = "samsung,s3c6410-i2s-multi",
> >> +             .driver_data    = (kernel_ulong_t)&i2sv4_dai_type,
> >> +     }, {
> >> +             .name           = "samsung,s5pc100-i2s",
> >> +             .driver_data    = (kernel_ulong_t)&i2sv5_c100_dai_type,
> >> 
> >>       }, {
> >> 
> >> -             .name           = "samsung-i2s-sec",
> >> -             .driver_data    = TYPE_SEC,
> >> +             .name           = "samsung,s5pv210-i2s",
> >> +             .driver_data    = (kernel_ulong_t)&i2sv5_dai_type,
> >> +     }, {
> >> +             .name           = "samsung-i2s-sec",
> >> +             .driver_data    =
> >> (kernel_ulong_t)&samsung_dai_type_sec,
> > 
> > I don't think you need to change the legacy platform IDs at all.
> 
> If legacy platforms not required to change then I need to introduce a
> new samsung_i2s_dai_data structure which holds only dai_type for
> non-dt platforms. If I change legacy platforms it breaks the older
> platforms now. Is it okay adding a samsung_i2s_dai_data structure for
> non-dt platforms which will be removed later?

Sorry, I don't understand the problem here.

Original contents of samsung_i2s_driver_ids[] array already conveyed 
information about dai type inside driver_data field of each 
platform_device_id entry.

If you really need to have samsung_i2s_dai_data struct for both DT and 
non-DT cases you can create dummy dai_data for both platform ID entries, 
which would have only dai type field initialized. This would be fine, 
because the non-DT probe path takes anything else from platform_data and 
would not need samsung_i2s_dai_data struct in any other way than getting 
dai_type in probe.

Best regards,
Tomasz

> > IMHO it would be better to keep the old way of quirk retrieval from
> > platform_data (which I think this patch does anyway, because the probe
> > path without DT is unchanged), as it will be dropped in some point in
> > time anyway.
> > 
> > This would also eliminate the need for patch 1.
> > 
> > Best regards,
> > Tomasz
> 
> Thanks
> Padma

WARNING: multiple messages have this Message-ID (diff)
From: tomasz.figa@gmail.com (Tomasz Figa)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH V3 2/3] ASoC: Samsung: I2S: Add quirks as driver data in I2S
Date: Thu, 08 Aug 2013 10:10:27 +0200	[thread overview]
Message-ID: <3759902.V2gf68Lg3g@flatron> (raw)
In-Reply-To: <CAAgF-BdpsgQk8myq7OOk5zJ8Zxy+J6LUPb3-d40+iE2aNwdwDw@mail.gmail.com>

On Thursday 08 of August 2013 13:13:02 Padma Venkat wrote:
> Hi Tomasz,
> 
> On Wed, Aug 7, 2013 at 4:43 PM, Tomasz Figa <t.figa@samsung.com> wrote:
> > Ahh, one more thing inline.
> 
> [snip]
> 
> >> +static struct samsung_i2s_dai_data i2sv3_dai_type = {
> >> +     .dai_type = TYPE_PRI,
> >> +     .quirks = QUIRK_NO_MUXPSR,
> >> +};
> >> +
> >> +static struct samsung_i2s_dai_data i2sv4_dai_type = {
> >> +     .dai_type = TYPE_PRI,
> >> +     .quirks = QUIRK_PRI_6CHAN | QUIRK_NO_MUXPSR,
> >> +};
> >> +
> >> +static struct samsung_i2s_dai_data i2sv5_c100_dai_type = {
> >> +     .dai_type = TYPE_PRI,
> >> +     .quirks = QUIRK_PRI_6CHAN | QUIRK_NO_MUXPSR | QUIRK_SEC_DAI |
> >> +                     QUIRK_NEED_RSTCLR,
> >> +};
> >> +
> >> +static struct samsung_i2s_dai_data i2sv5_dai_type = {
> >> +     .dai_type = TYPE_PRI,
> >> +     .quirks = QUIRK_PRI_6CHAN | QUIRK_SEC_DAI | QUIRK_NEED_RSTCLR,
> >> +};
> >> +
> >> +static struct samsung_i2s_dai_data samsung_dai_type_sec = {
> >> +     .dai_type = TYPE_SEC,
> >> +};
> >> +
> >> 
> >>  static struct platform_device_id samsung_i2s_driver_ids[] = {
> >>  
> >>       {
> >> 
> >> -             .name           = "samsung-i2s",
> >> -             .driver_data    = TYPE_PRI,
> >> +             .name           = "samsung,s3c6410-i2s",
> >> +             .driver_data    = (kernel_ulong_t)&i2sv3_dai_type,
> >> +     }, {
> >> +             .name           = "samsung,s3c6410-i2s-multi",
> >> +             .driver_data    = (kernel_ulong_t)&i2sv4_dai_type,
> >> +     }, {
> >> +             .name           = "samsung,s5pc100-i2s",
> >> +             .driver_data    = (kernel_ulong_t)&i2sv5_c100_dai_type,
> >> 
> >>       }, {
> >> 
> >> -             .name           = "samsung-i2s-sec",
> >> -             .driver_data    = TYPE_SEC,
> >> +             .name           = "samsung,s5pv210-i2s",
> >> +             .driver_data    = (kernel_ulong_t)&i2sv5_dai_type,
> >> +     }, {
> >> +             .name           = "samsung-i2s-sec",
> >> +             .driver_data    =
> >> (kernel_ulong_t)&samsung_dai_type_sec,
> > 
> > I don't think you need to change the legacy platform IDs at all.
> 
> If legacy platforms not required to change then I need to introduce a
> new samsung_i2s_dai_data structure which holds only dai_type for
> non-dt platforms. If I change legacy platforms it breaks the older
> platforms now. Is it okay adding a samsung_i2s_dai_data structure for
> non-dt platforms which will be removed later?

Sorry, I don't understand the problem here.

Original contents of samsung_i2s_driver_ids[] array already conveyed 
information about dai type inside driver_data field of each 
platform_device_id entry.

If you really need to have samsung_i2s_dai_data struct for both DT and 
non-DT cases you can create dummy dai_data for both platform ID entries, 
which would have only dai type field initialized. This would be fine, 
because the non-DT probe path takes anything else from platform_data and 
would not need samsung_i2s_dai_data struct in any other way than getting 
dai_type in probe.

Best regards,
Tomasz

> > IMHO it would be better to keep the old way of quirk retrieval from
> > platform_data (which I think this patch does anyway, because the probe
> > path without DT is unchanged), as it will be dropped in some point in
> > time anyway.
> > 
> > This would also eliminate the need for patch 1.
> > 
> > Best regards,
> > Tomasz
> 
> Thanks
> Padma

  reply	other threads:[~2013-08-08  8:10 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-08-07  8:45 [PATCH V3 0/3] Add audio support on smdk5420 Padmavathi Venna
2013-08-07  8:45 ` Padmavathi Venna
2013-08-07  8:45 ` [PATCH V3 1/3] platform: Increase platform name size Padmavathi Venna
2013-08-07  8:45   ` Padmavathi Venna
2013-08-07 14:00   ` Mark Brown
2013-08-07 14:00     ` Mark Brown
2013-08-07  8:45 ` [PATCH V3 2/3] ASoC: Samsung: I2S: Add quirks as driver data in I2S Padmavathi Venna
2013-08-07  8:45   ` Padmavathi Venna
2013-08-07 11:02   ` Tomasz Figa
2013-08-07 11:02     ` Tomasz Figa
2013-08-07 12:03     ` Padma Venkat
2013-08-07 12:03       ` Padma Venkat
2013-08-07 11:13   ` Tomasz Figa
2013-08-07 11:13     ` Tomasz Figa
2013-08-08  7:43     ` Padma Venkat
2013-08-08  7:43       ` Padma Venkat
2013-08-08  8:10       ` Tomasz Figa [this message]
2013-08-08  8:10         ` Tomasz Figa
2013-08-08 10:31       ` Mark Brown
2013-08-08 10:31         ` Mark Brown
2013-08-07  8:45 ` [PATCH V3 3/3] ASoC: Samsung: I2S: Modify the I2S driver to support I2S on Exynos5420 Padmavathi Venna
2013-08-07  8:45   ` Padmavathi Venna
2013-08-08 23:05   ` Tomasz Figa
2013-08-08 23:05     ` Tomasz Figa

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=3759902.V2gf68Lg3g@flatron \
    --to=tomasz.figa@gmail.com \
    --cc=abrestic@chromium.org \
    --cc=alsa-devel@alsa-project.org \
    --cc=broonie@kernel.org \
    --cc=devicetree@vger.kernel.org \
    --cc=kgene.kim@samsung.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-samsung-soc@vger.kernel.org \
    --cc=padma.kvr@gmail.com \
    --cc=padma.v@samsung.com \
    --cc=t.figa@samsung.com \
    /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
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.