From: Mark Brown <broonie@kernel.org> To: Dmitry Osipenko <digetx@gmail.com> Cc: Rob Herring <robh@kernel.org>, Thierry Reding <thierry.reding@gmail.com>, Jonathan Hunter <jonathanh@nvidia.com>, Takashi Iwai <tiwai@suse.com>, Jaroslav Kysela <perex@perex.cz>, Ion Agorria <ion@agorria.com>, Svyatoslav Ryhel <clamor95@gmail.com>, Frank Rowand <frowand.list@gmail.com>, Liam Girdwood <lgirdwood@gmail.com>, linux-tegra@vger.kernel.org, devicetree@vger.kernel.org, alsa-devel@alsa-project.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH v1 2/2] ASoC: tegra: Unify ASoC machine drivers Date: Wed, 19 May 2021 21:09:02 +0100 [thread overview] Message-ID: <20210519200902.GJ4224@sirena.org.uk> (raw) In-Reply-To: <b924f76a-56dd-5ca3-229d-293f7ff1e81a@gmail.com> [-- Attachment #1: Type: text/plain, Size: 987 bytes --] On Tue, May 18, 2021 at 11:16:48PM +0300, Dmitry Osipenko wrote: > 18.05.2021 21:34, Mark Brown пишет: > > It's generally the clocking configuration, things with fancy clock trees > > don't play so nicely with generic systems where we want to configure > > them at runtime, or things with complex routing in the CPU where we > > only recently started getting bindings that were functional enough to > > use. Tegra is fairly complex internally. > This is true, but still it's more optimal to use flags in a single > common driver for the minor differences rather than to duplicate 90% of > the code. In practice majority of tegra boards are derived from the same > reference design, thus the h/w configurations are mostly the same. If you can do it yes, though some of the CODECs can have sufficiently interesting clocking to make it useful to do something different - not sure if any of those are upstream though, WM8903 ought to with the right board I think. [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 488 bytes --]
WARNING: multiple messages have this Message-ID (diff)
From: Mark Brown <broonie@kernel.org> To: Dmitry Osipenko <digetx@gmail.com> Cc: Rob Herring <robh@kernel.org>, alsa-devel@alsa-project.org, Liam Girdwood <lgirdwood@gmail.com>, linux-kernel@vger.kernel.org, Svyatoslav Ryhel <clamor95@gmail.com>, Takashi Iwai <tiwai@suse.com>, devicetree@vger.kernel.org, Thierry Reding <thierry.reding@gmail.com>, Ion Agorria <ion@agorria.com>, linux-tegra@vger.kernel.org, Jonathan Hunter <jonathanh@nvidia.com>, Frank Rowand <frowand.list@gmail.com> Subject: Re: [PATCH v1 2/2] ASoC: tegra: Unify ASoC machine drivers Date: Wed, 19 May 2021 21:09:02 +0100 [thread overview] Message-ID: <20210519200902.GJ4224@sirena.org.uk> (raw) In-Reply-To: <b924f76a-56dd-5ca3-229d-293f7ff1e81a@gmail.com> [-- Attachment #1: Type: text/plain, Size: 987 bytes --] On Tue, May 18, 2021 at 11:16:48PM +0300, Dmitry Osipenko wrote: > 18.05.2021 21:34, Mark Brown пишет: > > It's generally the clocking configuration, things with fancy clock trees > > don't play so nicely with generic systems where we want to configure > > them at runtime, or things with complex routing in the CPU where we > > only recently started getting bindings that were functional enough to > > use. Tegra is fairly complex internally. > This is true, but still it's more optimal to use flags in a single > common driver for the minor differences rather than to duplicate 90% of > the code. In practice majority of tegra boards are derived from the same > reference design, thus the h/w configurations are mostly the same. If you can do it yes, though some of the CODECs can have sufficiently interesting clocking to make it useful to do something different - not sure if any of those are upstream though, WM8903 ought to with the right board I think. [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 488 bytes --]
next prev parent reply other threads:[~2021-05-19 20:09 UTC|newest] Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top 2021-05-18 0:13 [PATCH v1 0/2] Unify NVIDIA Tegra ASoC machine drivers Dmitry Osipenko 2021-05-18 0:13 ` Dmitry Osipenko 2021-05-18 0:13 ` [PATCH v1 1/2] of: base: Export of_device_compatible_match() Dmitry Osipenko 2021-05-18 0:13 ` Dmitry Osipenko 2021-05-18 18:14 ` Rob Herring 2021-05-18 18:14 ` Rob Herring 2021-05-18 0:13 ` [PATCH v1 2/2] ASoC: tegra: Unify ASoC machine drivers Dmitry Osipenko 2021-05-18 0:13 ` Dmitry Osipenko 2021-05-18 18:09 ` Rob Herring 2021-05-18 18:09 ` Rob Herring 2021-05-18 18:34 ` Mark Brown 2021-05-18 18:34 ` Mark Brown 2021-05-18 20:16 ` Dmitry Osipenko 2021-05-18 20:16 ` Dmitry Osipenko 2021-05-19 20:09 ` Mark Brown [this message] 2021-05-19 20:09 ` Mark Brown 2021-05-18 22:31 ` Question about Tegra UCMs Dmitry Osipenko 2021-05-18 22:31 ` Dmitry Osipenko 2021-05-19 11:13 ` Jaroslav Kysela 2021-05-19 11:13 ` Jaroslav Kysela 2021-05-19 13:15 ` Dmitry Osipenko 2021-05-19 13:15 ` Dmitry Osipenko 2021-05-19 11:38 ` Mark Brown 2021-05-19 11:38 ` Mark Brown 2021-05-19 13:19 ` Dmitry Osipenko 2021-05-19 13:19 ` Dmitry Osipenko 2021-05-18 20:11 ` [PATCH v1 2/2] ASoC: tegra: Unify ASoC machine drivers Dmitry Osipenko 2021-05-18 20:11 ` Dmitry Osipenko
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=20210519200902.GJ4224@sirena.org.uk \ --to=broonie@kernel.org \ --cc=alsa-devel@alsa-project.org \ --cc=clamor95@gmail.com \ --cc=devicetree@vger.kernel.org \ --cc=digetx@gmail.com \ --cc=frowand.list@gmail.com \ --cc=ion@agorria.com \ --cc=jonathanh@nvidia.com \ --cc=lgirdwood@gmail.com \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-tegra@vger.kernel.org \ --cc=perex@perex.cz \ --cc=robh@kernel.org \ --cc=thierry.reding@gmail.com \ --cc=tiwai@suse.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: linkBe 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.