From: Charles Keepax <ckeepax@opensource.cirrus.com>
To: Vinod Koul <vinod.koul@intel.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
LKML <linux-kernel@vger.kernel.org>,
ALSA <alsa-devel@alsa-project.org>, Mark <broonie@kernel.org>,
Takashi <tiwai@suse.de>,
Pierre <pierre-louis.bossart@linux.intel.com>,
Sanyog Kale <sanyog.r.kale@intel.com>,
Shreyas NC <shreyas.nc@intel.com>, <patches.audio@intel.com>,
<alan@linux.intel.com>, Sagar Dharia <sdharia@codeaurora.org>,
<srinivas.kandagatla@linaro.org>, <plai@codeaurora.org>,
Sudheer Papothi <spapothi@codeaurora.org>
Subject: Re: [PATCH v2 04/14] soundwire: Add MIPI DisCo property helpers
Date: Thu, 23 Nov 2017 14:38:12 +0000 [thread overview]
Message-ID: <20171123143812.braw737aciq4qmb7@localhost.localdomain> (raw)
In-Reply-To: <1510314556-13002-5-git-send-email-vinod.koul@intel.com>
On Fri, Nov 10, 2017 at 05:19:06PM +0530, Vinod Koul wrote:
> MIPI Discovery And Configuration (DisCo) Specification for SoundWire
> specifies properties to be implemented for SoundWire Masters and
> Slaves. The DisCo spec doesn't mandate these properties. However,
> SDW bus cannot work without knowing these values.
>
> The helper functions read the Master and Slave properties.
> Implementers of Master or Slave drivers can use any of the below
> three mechanisms:
> a) Use these APIs here as .read_prop() callback for Master
> and Slave
> b) Implement own methods and set those as .read_prop(), but invoke
> APIs in this file for generic read and override the values with
> platform specific data
> c) Implement ones own methods which do not use anything provided
> here
>
> Signed-off-by: Sanyog Kale <sanyog.r.kale@intel.com>
> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
> ---
> 5 files changed, 733 insertions(+), 1 deletion(-)
> create mode 100644 drivers/soundwire/mipi_disco.c
> --- a/drivers/soundwire/bus_type.c
> +++ b/drivers/soundwire/bus_type.c
> @@ -135,6 +135,8 @@ static int sdw_drv_probe(struct device *dev)
> return ret;
> }
>
> + slave->ops = drv->ops;
> +
> ret = drv->probe(slave, id);
> if (ret) {
> dev_err(dev, "Probe of %s failed: %d\n", drv->name, ret);
> @@ -142,6 +144,22 @@ static int sdw_drv_probe(struct device *dev)
> return ret;
> }
>
> + /* device is probed so let's read the properties now */
> + if (slave->ops && slave->ops->read_prop)
> + slave->ops->read_prop(slave);
> +
> + /*
> + * Check for valid clk_stop_timeout, use DisCo worst case value of
> + * 300ms
> + *
> + * TODO: check the timeouts and driver removal case
> + */
> + if (slave->prop.clk_stop_timeout == 0)
> + slave->prop.clk_stop_timeout = 300;
> +
> + slave->bus->clk_stop_timeout = max_t(u32, slave->bus->clk_stop_timeout,
> + slave->prop.clk_stop_timeout);
> +
> return 0;
> }
>
This brings up something I have been struggling with a little on
both the soundwire and slimbus chains at the moment.
This happens after probe but if I am understanding right these
properties might be required to communicate with the device.
Which directly implies that probe shouldn't attempt to talk to
the device? This is also implied in both series by the fact that
probe will usually setup the things necessary for enumeration
(power, clocks, etc). But it is fairly common in probe to at
least do something like read some ID registers to check we are
probing the right device.
On the slimbus side I guess you can get round this using the fact
they have device_status callbacks to the driver so the driver can
tell when the device is actually available, and could perform
some actions when the device first becomes available on the
bus. But this SoundWire chain doesn't have an equivalent.
Apologies for the long and slightly vague comment, but I guess my
question is do you have a thought on how drivers should know when
it is safe to communicate with a SoundWire device?
Thanks,
Charles
next prev parent reply other threads:[~2017-11-23 14:38 UTC|newest]
Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-11-10 11:49 [PATCH v2 00/14] soundwire: Add a new SoundWire subsystem Vinod Koul
2017-11-10 11:49 ` [PATCH v2 01/14] Documentation: Add SoundWire summary Vinod Koul
2017-11-10 11:49 ` [PATCH v2 02/14] soundwire: Add SoundWire bus type Vinod Koul
2017-11-16 16:05 ` Srinivas Kandagatla
2017-11-16 17:02 ` Vinod Koul
2017-11-16 17:24 ` Mark Brown
2017-11-17 3:52 ` Vinod Koul
2017-11-10 11:49 ` [PATCH v2 03/14] soundwire: Add Master registration Vinod Koul
2017-11-16 16:05 ` Srinivas Kandagatla
2017-11-16 16:49 ` Vinod Koul
2017-11-16 17:30 ` Mark Brown
2017-11-17 2:06 ` [alsa-devel] " Vinod Koul
2017-11-10 11:49 ` [PATCH v2 04/14] soundwire: Add MIPI DisCo property helpers Vinod Koul
2017-11-16 16:05 ` Srinivas Kandagatla
2017-11-16 17:04 ` Vinod Koul
2017-11-23 14:38 ` Charles Keepax [this message]
2017-11-24 16:04 ` Sanyog Kale
2017-11-27 7:59 ` Charles Keepax
2017-11-27 9:18 ` Vinod Koul
2017-11-27 9:56 ` Charles Keepax
2017-11-27 10:55 ` [alsa-devel] " Vinod Koul
2017-11-10 11:49 ` [PATCH v2 05/14] soundwire: Add SoundWire MIPI defined registers Vinod Koul
2017-11-10 11:49 ` [PATCH v2 06/14] soundwire: Add IO transfer Vinod Koul
2017-11-10 11:49 ` [PATCH v2 07/14] regmap: Add SoundWire bus support Vinod Koul
2017-11-16 12:04 ` Mark Brown
2017-11-16 13:02 ` Vinod Koul
2017-11-16 14:48 ` Mark Brown
2017-11-10 11:49 ` [PATCH v2 08/14] soundwire: Add Slave status handling helpers Vinod Koul
2017-11-16 16:05 ` Srinivas Kandagatla
2017-11-16 17:08 ` Vinod Koul
2017-11-10 11:49 ` [PATCH v2 09/14] soundwire: Add slave status handling Vinod Koul
2017-11-10 11:49 ` [PATCH v2 10/14] soundwire: Add sysfs for SoundWire DisCo properties Vinod Koul
2017-11-10 11:49 ` [PATCH v2 11/14] soundwire: cdns: Add cadence library Vinod Koul
2017-11-10 11:49 ` [PATCH v2 12/14] soundwire: cdns: Add sdw_master_ops and IO transfer support Vinod Koul
2017-11-10 11:49 ` [PATCH v2 13/14] soundwire: intel: Add Intel Master driver Vinod Koul
2017-11-10 11:49 ` [PATCH v2 14/14] soundwire: intel: Add Intel init module Vinod Koul
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=20171123143812.braw737aciq4qmb7@localhost.localdomain \
--to=ckeepax@opensource.cirrus.com \
--cc=alan@linux.intel.com \
--cc=alsa-devel@alsa-project.org \
--cc=broonie@kernel.org \
--cc=gregkh@linuxfoundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=patches.audio@intel.com \
--cc=pierre-louis.bossart@linux.intel.com \
--cc=plai@codeaurora.org \
--cc=sanyog.r.kale@intel.com \
--cc=sdharia@codeaurora.org \
--cc=shreyas.nc@intel.com \
--cc=spapothi@codeaurora.org \
--cc=srinivas.kandagatla@linaro.org \
--cc=tiwai@suse.de \
--cc=vinod.koul@intel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®