All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mark Brown <broonie@kernel.org>
To: Katsuhiro Suzuki <suzuki.katsuhiro@socionext.com>
Cc: alsa-devel@alsa-project.org, "Rob Herring" <robh+dt@kernel.org>,
	devicetree@vger.kernel.org, "Yamada,
	Masahiro/山田 真弘" <yamada.masahiro@socionext.com>,
	"Masami Hiramatsu" <masami.hiramatsu@linaro.org>,
	"Jassi Brar" <jaswinder.singh@linaro.org>,
	linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH 5/8] ASoC: uniphier: add support for UniPhier AIO driver
Date: Wed, 6 Dec 2017 12:58:17 +0000	[thread overview]
Message-ID: <20171206125817.GF1827@finisterre> (raw)
In-Reply-To: <004801d36e57$ea1940d0$be4bc270$@socionext.com>

[-- Attachment #1: Type: text/plain, Size: 1799 bytes --]

On Wed, Dec 06, 2017 at 03:03:18PM +0900, Katsuhiro Suzuki wrote:

> > I'd expect this code to be structured more like a library - have a
> > driver that handles the specific IPs then have it call into a shared
> > block of code that does the generic bits.  Though in this case the
> > device specific bit looks like a couple of tiny data tables so I'm not
> > sure it's worth making it conditional or separate at all.

> Sorry... I agree your opinion, but I can't imagine the detail.

> I think my driver has structure as follows (ex. startup):
>   DAI: uniphier_aio_startup()@aio-core.c
>   Lib: uniphier_aio_init()@aio-regctrl.c
>   SoC specific: uniphier_aio_ld11_spec@aio-ld11.c

> Am I wrong? Would you mean split the functions in aio-regctl.[ch] to other
> kernel module? I wonder if you could tell me the example from existing
> drivers. I'll try to fix my driver like as it.

One example is how all the drivers that use the generic dmaengine code
instantiate their DMA drivers, or how all the drivers for CODECs that
have both I2C and SPIi control interfaces instantiate - given that the
device specific code here seems to be mostly data tables that's probably
the closest thing.

> > At least.  I do think we need to get to the bottom of how flexible the
> > hardware is first though.

> Yes, indeed. This hardware is more flexible and complex, but now I (and our
> company) don't use it. Of course, I don't want to hide some features of this
> hardware from ALSA people. I should try to upstream all features in the future,
> I think.

My main concern here is to make sure that when you decide you need to
use the more complex hardware that this can be done without too much
pain to existing machines (and that they can benefit from as much of the
enhanced functionality as is possible).

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

WARNING: multiple messages have this Message-ID (diff)
From: Mark Brown <broonie-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
To: Katsuhiro Suzuki
	<suzuki.katsuhiro-uWyLwvC0a2jby3iVrkZq2A@public.gmane.org>
Cc: alsa-devel-K7yf7f+aM1XWsZ/bQMPhNw@public.gmane.org,
	"Rob Herring" <robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>,
	devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, "Yamada,
	Masahiro/山田 真弘"
	<yamada.masahiro-uWyLwvC0a2jby3iVrkZq2A@public.gmane.org>,
	"Masami Hiramatsu"
	<masami.hiramatsu-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>,
	"Jassi Brar"
	<jaswinder.singh-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>,
	linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
	linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Subject: Re: [PATCH 5/8] ASoC: uniphier: add support for UniPhier AIO driver
Date: Wed, 6 Dec 2017 12:58:17 +0000	[thread overview]
Message-ID: <20171206125817.GF1827@finisterre> (raw)
In-Reply-To: <004801d36e57$ea1940d0$be4bc270$@socionext.com>

[-- Attachment #1: Type: text/plain, Size: 1799 bytes --]

On Wed, Dec 06, 2017 at 03:03:18PM +0900, Katsuhiro Suzuki wrote:

> > I'd expect this code to be structured more like a library - have a
> > driver that handles the specific IPs then have it call into a shared
> > block of code that does the generic bits.  Though in this case the
> > device specific bit looks like a couple of tiny data tables so I'm not
> > sure it's worth making it conditional or separate at all.

> Sorry... I agree your opinion, but I can't imagine the detail.

> I think my driver has structure as follows (ex. startup):
>   DAI: uniphier_aio_startup()@aio-core.c
>   Lib: uniphier_aio_init()@aio-regctrl.c
>   SoC specific: uniphier_aio_ld11_spec@aio-ld11.c

> Am I wrong? Would you mean split the functions in aio-regctl.[ch] to other
> kernel module? I wonder if you could tell me the example from existing
> drivers. I'll try to fix my driver like as it.

One example is how all the drivers that use the generic dmaengine code
instantiate their DMA drivers, or how all the drivers for CODECs that
have both I2C and SPIi control interfaces instantiate - given that the
device specific code here seems to be mostly data tables that's probably
the closest thing.

> > At least.  I do think we need to get to the bottom of how flexible the
> > hardware is first though.

> Yes, indeed. This hardware is more flexible and complex, but now I (and our
> company) don't use it. Of course, I don't want to hide some features of this
> hardware from ALSA people. I should try to upstream all features in the future,
> I think.

My main concern here is to make sure that when you decide you need to
use the more complex hardware that this can be done without too much
pain to existing machines (and that they can benefit from as much of the
enhanced functionality as is possible).

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

WARNING: multiple messages have this Message-ID (diff)
From: broonie@kernel.org (Mark Brown)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 5/8] ASoC: uniphier: add support for UniPhier AIO driver
Date: Wed, 6 Dec 2017 12:58:17 +0000	[thread overview]
Message-ID: <20171206125817.GF1827@finisterre> (raw)
In-Reply-To: <004801d36e57$ea1940d0$be4bc270$@socionext.com>

On Wed, Dec 06, 2017 at 03:03:18PM +0900, Katsuhiro Suzuki wrote:

> > I'd expect this code to be structured more like a library - have a
> > driver that handles the specific IPs then have it call into a shared
> > block of code that does the generic bits.  Though in this case the
> > device specific bit looks like a couple of tiny data tables so I'm not
> > sure it's worth making it conditional or separate at all.

> Sorry... I agree your opinion, but I can't imagine the detail.

> I think my driver has structure as follows (ex. startup):
>   DAI: uniphier_aio_startup()@aio-core.c
>   Lib: uniphier_aio_init()@aio-regctrl.c
>   SoC specific: uniphier_aio_ld11_spec at aio-ld11.c

> Am I wrong? Would you mean split the functions in aio-regctl.[ch] to other
> kernel module? I wonder if you could tell me the example from existing
> drivers. I'll try to fix my driver like as it.

One example is how all the drivers that use the generic dmaengine code
instantiate their DMA drivers, or how all the drivers for CODECs that
have both I2C and SPIi control interfaces instantiate - given that the
device specific code here seems to be mostly data tables that's probably
the closest thing.

> > At least.  I do think we need to get to the bottom of how flexible the
> > hardware is first though.

> Yes, indeed. This hardware is more flexible and complex, but now I (and our
> company) don't use it. Of course, I don't want to hide some features of this
> hardware from ALSA people. I should try to upstream all features in the future,
> I think.

My main concern here is to make sure that when you decide you need to
use the more complex hardware that this can be done without too much
pain to existing machines (and that they can benefit from as much of the
enhanced functionality as is possible).
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20171206/bf132a6c/attachment.sig>

  reply	other threads:[~2017-12-06 12:58 UTC|newest]

Thread overview: 73+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-11-22 11:43 [PATCH 0/8] add UniPhier audio system support Katsuhiro Suzuki
2017-11-22 11:43 ` Katsuhiro Suzuki
2017-11-22 11:43 ` [PATCH 1/8] ASoC: spdif: Add S32_LE support for S/PDIF dummy codec drivers Katsuhiro Suzuki
2017-11-22 11:43   ` Katsuhiro Suzuki
2017-11-22 11:43   ` Katsuhiro Suzuki
2017-12-04 18:48   ` Applied "ASoC: spdif: Add S32_LE support for S/PDIF dummy codec drivers" to the asoc tree Mark Brown
2017-12-04 18:48     ` Mark Brown
2017-12-04 18:48     ` Mark Brown
2017-11-22 11:43 ` [PATCH 2/8] ASoC: uniphier: add DT bindings documentation for UniPhier EVEA Katsuhiro Suzuki
2017-11-22 11:43   ` Katsuhiro Suzuki
2017-11-22 11:43   ` Katsuhiro Suzuki
2017-11-26 19:02   ` Rob Herring
2017-11-26 19:02     ` Rob Herring
2017-12-04 18:48   ` Applied "ASoC: uniphier: add DT bindings documentation for UniPhier EVEA" to the asoc tree Mark Brown
2017-12-04 18:48     ` Mark Brown
2017-12-04 18:48     ` Mark Brown
2017-11-22 11:43 ` [PATCH 3/8] ASoC: uniphier: add DT bindings documentation for UniPhier AIO Katsuhiro Suzuki
2017-11-22 11:43   ` Katsuhiro Suzuki
2017-11-22 11:43   ` Katsuhiro Suzuki
2017-11-26 19:04   ` Rob Herring
2017-11-26 19:04     ` Rob Herring
2017-11-26 19:04     ` Rob Herring
2018-02-12 12:54   ` Applied "ASoC: uniphier: add DT bindings documentation for UniPhier AIO" to the asoc tree Mark Brown
2018-02-12 12:54     ` Mark Brown
2018-02-12 12:54     ` Mark Brown
2017-11-22 11:43 ` [PATCH 4/8] ASoC: uniphier: add support for UniPhier EVEA codec Katsuhiro Suzuki
2017-11-22 11:43   ` Katsuhiro Suzuki
2017-12-04 18:20   ` Mark Brown
2017-12-04 18:20     ` Mark Brown
2017-12-04 18:20     ` Mark Brown
2017-12-05  0:58     ` Masahiro Yamada
2017-12-05  0:58       ` Masahiro Yamada
2017-12-05 11:59       ` Mark Brown
2017-12-05 11:59         ` Mark Brown
2017-12-05 11:59         ` Mark Brown
2017-12-04 18:48   ` Applied "ASoC: uniphier: add support for UniPhier EVEA codec" to the asoc tree Mark Brown
2017-12-04 18:48     ` Mark Brown
2017-12-04 18:48     ` Mark Brown
2017-11-22 11:43 ` [PATCH 5/8] ASoC: uniphier: add support for UniPhier AIO driver Katsuhiro Suzuki
2017-11-22 11:43   ` Katsuhiro Suzuki
2017-12-04 18:39   ` Mark Brown
2017-12-04 18:39     ` Mark Brown
2017-12-04 18:39     ` Mark Brown
2017-12-05  4:48     ` Katsuhiro Suzuki
2017-12-05  4:48       ` Katsuhiro Suzuki
2017-12-05  4:48       ` Katsuhiro Suzuki
2017-12-05 12:14       ` Mark Brown
2017-12-05 12:14         ` Mark Brown
2017-12-05 12:14         ` Mark Brown
2017-12-06  6:03         ` Katsuhiro Suzuki
2017-12-06  6:03           ` Katsuhiro Suzuki
2017-12-06 12:58           ` Mark Brown [this message]
2017-12-06 12:58             ` Mark Brown
2017-12-06 12:58             ` Mark Brown
2017-12-11  9:21             ` Katsuhiro Suzuki
2017-12-11  9:21               ` Katsuhiro Suzuki
2017-12-11  9:21               ` Katsuhiro Suzuki
2017-12-11 15:16               ` Mark Brown
2017-12-11 15:16                 ` Mark Brown
2017-12-11 17:48                 ` [alsa-devel] " Vinod Koul
2017-12-11 17:48                   ` Vinod Koul
2017-12-12  4:33                   ` Katsuhiro Suzuki
2017-12-12  4:33                     ` Katsuhiro Suzuki
2017-11-22 11:43 ` [PATCH 6/8] ASoC: uniphier: add support for UniPhier LD11/LD20 " Katsuhiro Suzuki
2017-11-22 11:43   ` Katsuhiro Suzuki
2017-11-22 11:43   ` Katsuhiro Suzuki
2017-11-22 11:43 ` [PATCH 7/8] MAINTAINERS: add entries for UniPhier ASoC sound drivers Katsuhiro Suzuki
2017-11-22 11:43   ` Katsuhiro Suzuki
2017-12-04 18:48   ` Applied "MAINTAINERS: add entries for UniPhier ASoC sound drivers" to the asoc tree Mark Brown
2017-12-04 18:48     ` Mark Brown
2017-12-04 18:48     ` Mark Brown
2017-11-22 11:43 ` [PATCH 8/8] arm64: dts: uniphier: add sound node for UniPhier Katsuhiro Suzuki
2017-11-22 11:43   ` Katsuhiro Suzuki

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=20171206125817.GF1827@finisterre \
    --to=broonie@kernel.org \
    --cc=alsa-devel@alsa-project.org \
    --cc=devicetree@vger.kernel.org \
    --cc=jaswinder.singh@linaro.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=masami.hiramatsu@linaro.org \
    --cc=robh+dt@kernel.org \
    --cc=suzuki.katsuhiro@socionext.com \
    --cc=yamada.masahiro@socionext.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.