From: Tony Lindgren <tony@atomide.com>
To: Mark Brown <broonie@kernel.org>
Cc: alsa-devel@alsa-project.org, Liam Girdwood <lgirdwood@gmail.com>,
linux-kernel@vger.kernel.org, Merlijn Wajer <merlijn@wizzup.org>,
Takashi Iwai <tiwai@suse.com>,
Peter Ujfalusi <peter.ujfalusi@ti.com>,
Pavel Machek <pavel@ucw.cz>,
linux-omap@vger.kernel.org, "Arthur D ." <spinal.by@gmail.com>,
Sebastian Reichel <sebastian.reichel@collabora.com>,
Jarkko Nikula <jarkko.nikula@bitmer.com>
Subject: Re: [PATCH] ASoC: cpcap: Implement set_tdm_slot for voice call support
Date: Wed, 19 Feb 2020 09:39:02 -0800 [thread overview]
Message-ID: <20200219173902.GA37466@atomide.com> (raw)
In-Reply-To: <20200218174258.GK4232@sirena.org.uk>
* Mark Brown <broonie@kernel.org> [200218 17:43]:
> On Tue, Feb 18, 2020 at 06:06:28PM +0100, Sebastian Reichel wrote:
>
> > simple-graph-card is the current machine driver. We might have to
> > introduce a Droid 4 specific driver instead. I used simple(-graph)-card
> > instead of introducing a new driver, since the setup was simple enough
> > without modem and bluetooth. The simple card was perfect to test the CPCAP
> > codec driver. The TDM things might be complex enough to create
> > a new machine driver (as I mentioned in the original patchset
> > adding CPCAP codec support).
>
> I tend to agree here, phones are generally one of the most complicated
> classes of system for clocking and interconnects and the CODECs they use
> often the most complex too so they're really stretching the generic
> cards. It'd be nice to be able to handle things with generic cards but
> it's likely you'll run into issues that it'd be unreasonable to force
> you to address for system enablement. OTOH if you manage to get one of
> the generic cards working well that'd be excellent!
Well to me it seems that we just already have all the data needed with
the graph binding and snd-soc-audio-graph-card + codec2codec support.
I don't think we have cases where the cpcap codec is not the master,
so as long as the cpcap codec knows what's going on then there
may not be a need for machine driver.
I guess the the bluetooth to modem path is the one to check to see
what provides the clocks..
Regards,
Tony
WARNING: multiple messages have this Message-ID (diff)
From: Tony Lindgren <tony@atomide.com>
To: Mark Brown <broonie@kernel.org>
Cc: Sebastian Reichel <sebastian.reichel@collabora.com>,
Peter Ujfalusi <peter.ujfalusi@ti.com>,
Liam Girdwood <lgirdwood@gmail.com>,
Jaroslav Kysela <perex@perex.cz>, Takashi Iwai <tiwai@suse.com>,
alsa-devel@alsa-project.org, linux-kernel@vger.kernel.org,
linux-omap@vger.kernel.org, "Arthur D ." <spinal.by@gmail.com>,
Merlijn Wajer <merlijn@wizzup.org>, Pavel Machek <pavel@ucw.cz>,
Jarkko Nikula <jarkko.nikula@bitmer.com>
Subject: Re: [PATCH] ASoC: cpcap: Implement set_tdm_slot for voice call support
Date: Wed, 19 Feb 2020 09:39:02 -0800 [thread overview]
Message-ID: <20200219173902.GA37466@atomide.com> (raw)
In-Reply-To: <20200218174258.GK4232@sirena.org.uk>
* Mark Brown <broonie@kernel.org> [200218 17:43]:
> On Tue, Feb 18, 2020 at 06:06:28PM +0100, Sebastian Reichel wrote:
>
> > simple-graph-card is the current machine driver. We might have to
> > introduce a Droid 4 specific driver instead. I used simple(-graph)-card
> > instead of introducing a new driver, since the setup was simple enough
> > without modem and bluetooth. The simple card was perfect to test the CPCAP
> > codec driver. The TDM things might be complex enough to create
> > a new machine driver (as I mentioned in the original patchset
> > adding CPCAP codec support).
>
> I tend to agree here, phones are generally one of the most complicated
> classes of system for clocking and interconnects and the CODECs they use
> often the most complex too so they're really stretching the generic
> cards. It'd be nice to be able to handle things with generic cards but
> it's likely you'll run into issues that it'd be unreasonable to force
> you to address for system enablement. OTOH if you manage to get one of
> the generic cards working well that'd be excellent!
Well to me it seems that we just already have all the data needed with
the graph binding and snd-soc-audio-graph-card + codec2codec support.
I don't think we have cases where the cpcap codec is not the master,
so as long as the cpcap codec knows what's going on then there
may not be a need for machine driver.
I guess the the bluetooth to modem path is the one to check to see
what provides the clocks..
Regards,
Tony
next prev parent reply other threads:[~2020-02-19 17:40 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-02-11 18:10 [alsa-devel] [PATCH] ASoC: cpcap: Implement set_tdm_slot for voice call support Tony Lindgren
2020-02-11 18:10 ` Tony Lindgren
2020-02-12 9:17 ` [alsa-devel] " Peter Ujfalusi
2020-02-12 9:17 ` Peter Ujfalusi
2020-02-12 9:17 ` Peter Ujfalusi
2020-02-12 14:46 ` [alsa-devel] " Tony Lindgren
2020-02-12 14:46 ` Tony Lindgren
2020-02-14 13:29 ` [alsa-devel] " Peter Ujfalusi
2020-02-14 13:29 ` Peter Ujfalusi
2020-02-17 23:23 ` Tony Lindgren
2020-02-17 23:23 ` Tony Lindgren
2020-02-18 15:15 ` Peter Ujfalusi
2020-02-18 15:15 ` Peter Ujfalusi
2020-02-18 15:32 ` Tony Lindgren
2020-02-18 15:32 ` Tony Lindgren
2020-02-18 16:44 ` Mark Brown
2020-02-18 16:44 ` Mark Brown
2020-02-18 17:06 ` Sebastian Reichel
2020-02-18 17:06 ` Sebastian Reichel
2020-02-18 17:42 ` Mark Brown
2020-02-18 17:42 ` Mark Brown
2020-02-19 17:39 ` Tony Lindgren [this message]
2020-02-19 17:39 ` Tony Lindgren
2020-02-19 17:46 ` Mark Brown
2020-02-19 17:46 ` Mark Brown
2020-02-19 18:49 ` Tony Lindgren
2020-02-19 18:49 ` Tony Lindgren
2020-02-19 18:53 ` Tony Lindgren
2020-02-19 18:53 ` Tony Lindgren
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=20200219173902.GA37466@atomide.com \
--to=tony@atomide.com \
--cc=alsa-devel@alsa-project.org \
--cc=broonie@kernel.org \
--cc=jarkko.nikula@bitmer.com \
--cc=lgirdwood@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-omap@vger.kernel.org \
--cc=merlijn@wizzup.org \
--cc=pavel@ucw.cz \
--cc=peter.ujfalusi@ti.com \
--cc=sebastian.reichel@collabora.com \
--cc=spinal.by@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: 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.