alsa-devel.alsa-project.org archive mirror
 help / color / mirror / Atom feed
From: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
To: Vinod Koul <vkoul@kernel.org>
Cc: alsa-devel@alsa-project.org, tiwai@suse.de,
	gregkh@linuxfoundation.org, linux-kernel@vger.kernel.org,
	Ranjani Sridharan <ranjani.sridharan@linux.intel.com>,
	broonie@kernel.org, srinivas.kandagatla@linaro.org,
	jank@cadence.com, slawomir.blauciak@intel.com,
	Sanyog Kale <sanyog.r.kale@intel.com>,
	Bard liao <yung-chuan.liao@linux.intel.com>,
	Rander Wang <rander.wang@linux.intel.com>
Subject: Re: [alsa-devel] [PATCH v5 08/17] soundwire: add initial definitions for sdw_master_device
Date: Fri, 27 Dec 2019 17:38:44 -0600	[thread overview]
Message-ID: <1922c494-4641-8c40-192d-758b21014fbc@linux.intel.com> (raw)
In-Reply-To: <20191227071433.GL3006@vkoul-mobl>



On 12/27/19 1:14 AM, Vinod Koul wrote:
> On 17-12-19, 15:03, Pierre-Louis Bossart wrote:
>> Since we want an explicit support for the SoundWire Master device, add
>> the definitions, following the Greybus example of a 'Host Device'.
>>
>> A parent (such as the Intel audio controller) would use sdw_md_add()
>> to create the device, passing a driver as a parameter. The
>> sdw_md_release() would be called when put_device() is invoked by the
>> parent. We use the shortcut 'md' for 'master device' to avoid very
>> long function names.
> 
> I agree we should not have long name :) but md does not sound great. Can
> we drop the device and use sdw_slave and sdw_master for devices and
> append _driver when we are talking about drivers...
> 
> we dont use sd for slave and imo this would gel well with existing names

In SoundWire parlance, both 'Slave' and 'Master' are 'Devices', so yes 
we do in the standard talk about 'Slave Devices' and 'Master Devices'.

Then we have Linux 'Devices' which can be used for both.

If we use 'sdw_slave', would we be referring to the actual physical part 
or the Linux device?

FWIW the Greybus example used 'Host Device' and 'hd' as shortcut.

> 
>> --- a/drivers/soundwire/bus_type.c
>> +++ b/drivers/soundwire/bus_type.c
>> @@ -66,7 +66,10 @@ int sdw_uevent(struct device *dev, struct kobj_uevent_env *env)
>>   		 * callback is set to use this function for a
>>   		 * different device type (e.g. Master or Monitor)
>>   		 */
>> -		dev_err(dev, "uevent for unknown Soundwire type\n");
>> +		if (is_sdw_master_device(dev))
>> +			dev_err(dev, "uevent for SoundWire Master type\n");
> 
> see below [1]:
> 
>> +static void sdw_md_release(struct device *dev)
> 
> sdw_master_release() won't be too long!

yes, but there is no such operation as 'Master Release' in SoundWire.
At least the 'md' shortcut conveys the implicit convention that this is 
a Linux device only.

I really would like to avoid overloading the standard definitions with 
the Linux ones...

> 
>> +{
>> +	struct sdw_master_device *md = to_sdw_master_device(dev);
>> +
>> +	kfree(md);
>> +}
>> +
>> +struct device_type sdw_md_type = {
> 
> sdw_master_type and so on :)
> 
>> +	.name =		"soundwire_master",
>> +	.release =	sdw_md_release,
> 
> [1]:
> There is no uevent added here, so sdw_uevent() will never be called for
> this, can you check again if you see the print you added?

as explained this is to avoid errors at a later point. I don't see any 
harm in providing error checks for a routine that can only be used for 1 
of the 3 devices defined in the standard?

>>   
>> +struct sdw_master_device {
> 
> we have sdw_slave, so would be better if we call this sdw_master
> 
>> +	struct device dev;
>> +	int link_id;
>> +	struct sdw_md_driver *driver;
>> +	void *pdata;
> 
> no sdw_bus pointer and I dont see bus adding this object.. Is there no
> link between bus and master device objects?

There is currently no bus device object, see the structure definition 
it's a pointer to a device (which leads to all sorts of issues because 
we can't use container_of).

when the master device gets added, that's where the Linux device is 
created and the pointer saved in the bus structure, with IIRC 
sdw_add_bus_master().


  	ret = sdw_add_bus_master(&sdw->cdns.bus);
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
https://mailman.alsa-project.org/mailman/listinfo/alsa-devel

  reply	other threads:[~2019-12-28  0:18 UTC|newest]

Thread overview: 47+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-12-17 21:02 [alsa-devel] [PATCH v5 00/17] soundwire: intel: implement new ASoC interfaces Pierre-Louis Bossart
2019-12-17 21:02 ` [alsa-devel] [PATCH v5 01/17] soundwire: renames to prepare support for master drivers/devices Pierre-Louis Bossart
2019-12-17 21:02 ` [alsa-devel] [PATCH v5 02/17] soundwire: rename dev_to_sdw_dev macro Pierre-Louis Bossart
2019-12-27  6:54   ` Vinod Koul
2019-12-17 21:03 ` [alsa-devel] [PATCH v5 03/17] soundwire: rename drv_to_sdw_slave_driver macro Pierre-Louis Bossart
2019-12-27  7:00   ` Vinod Koul
2019-12-27 23:23     ` Pierre-Louis Bossart
2019-12-28 12:03       ` Vinod Koul
2019-12-17 21:03 ` [alsa-devel] [PATCH v5 04/17] soundwire: bus_type: rename sdw_drv_ to sdw_slave_drv Pierre-Louis Bossart
2019-12-17 21:03 ` [alsa-devel] [PATCH v5 05/17] soundwire: intel: rename res field as link_res Pierre-Louis Bossart
2019-12-17 21:03 ` [alsa-devel] [PATCH v5 06/17] soundwire: add support for sdw_slave_type Pierre-Louis Bossart
2019-12-27  7:03   ` Vinod Koul
2019-12-27 23:26     ` Pierre-Louis Bossart
2019-12-28 12:05       ` Vinod Koul
2019-12-17 21:03 ` [alsa-devel] [PATCH v5 07/17] soundwire: slave: move uevent handling to slave device level Pierre-Louis Bossart
2019-12-17 21:03 ` [alsa-devel] [PATCH v5 08/17] soundwire: add initial definitions for sdw_master_device Pierre-Louis Bossart
2019-12-27  7:14   ` Vinod Koul
2019-12-27 23:38     ` Pierre-Louis Bossart [this message]
2019-12-28 12:09       ` Vinod Koul
2020-01-02 17:36         ` Pierre-Louis Bossart
2020-01-06  5:32           ` Vinod Koul
2019-12-17 21:03 ` [alsa-devel] [PATCH v5 09/17] soundwire: intel: remove platform devices and use 'Master Devices' instead Pierre-Louis Bossart
2019-12-27  9:08   ` Vinod Koul
2019-12-28  0:13     ` Pierre-Louis Bossart
2020-01-06  5:42       ` Vinod Koul
2020-01-06 14:51         ` Pierre-Louis Bossart
2020-01-10  6:43           ` Vinod Koul
2020-01-10 16:08             ` Pierre-Louis Bossart
2020-01-13  5:18               ` Vinod Koul
2020-01-13 15:22                 ` Pierre-Louis Bossart
2020-01-14  6:09   ` Vinod Koul
2020-01-14 16:01     ` Pierre-Louis Bossart
2020-01-18  7:12       ` Vinod Koul
2020-01-21 17:31         ` Pierre-Louis Bossart
2020-01-28 10:50           ` Vinod Koul
2020-01-28 16:02             ` Pierre-Louis Bossart
2020-01-29  5:08               ` Vinod Koul
2020-01-29 14:59                 ` Pierre-Louis Bossart
2020-02-03 12:02                   ` Vinod Koul
2019-12-17 21:03 ` [alsa-devel] [PATCH v5 10/17] soundwire: register master device driver Pierre-Louis Bossart
2019-12-17 21:03 ` [alsa-devel] [PATCH v5 11/17] soundwire: intel: add prepare support in sdw dai driver Pierre-Louis Bossart
2019-12-17 21:03 ` [alsa-devel] [PATCH v5 12/17] soundwire: intel: add trigger " Pierre-Louis Bossart
2019-12-17 21:03 ` [alsa-devel] [PATCH v5 13/17] soundwire: intel: add sdw_stream_setup helper for .startup callback Pierre-Louis Bossart
2019-12-17 21:03 ` [alsa-devel] [PATCH v5 14/17] soundwire: intel: free all resources on hw_free() Pierre-Louis Bossart
2019-12-17 21:03 ` [alsa-devel] [PATCH v5 15/17] soundwire: intel_init: add implementation of sdw_intel_enable_irq() Pierre-Louis Bossart
2019-12-17 21:03 ` [alsa-devel] [PATCH v5 16/17] soundwire: intel_init: use EXPORT_SYMBOL_NS Pierre-Louis Bossart
2019-12-17 21:03 ` [alsa-devel] [PATCH v5 17/17] soundwire: intel: " Pierre-Louis Bossart

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=1922c494-4641-8c40-192d-758b21014fbc@linux.intel.com \
    --to=pierre-louis.bossart@linux.intel.com \
    --cc=alsa-devel@alsa-project.org \
    --cc=broonie@kernel.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=jank@cadence.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=rander.wang@linux.intel.com \
    --cc=ranjani.sridharan@linux.intel.com \
    --cc=sanyog.r.kale@intel.com \
    --cc=slawomir.blauciak@intel.com \
    --cc=srinivas.kandagatla@linaro.org \
    --cc=tiwai@suse.de \
    --cc=vkoul@kernel.org \
    --cc=yung-chuan.liao@linux.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;
as well as URLs for NNTP newsgroup(s).