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 09/17] soundwire: intel: remove platform devices and use 'Master Devices' instead
Date: Mon, 13 Jan 2020 09:22:15 -0600 [thread overview]
Message-ID: <d77dcdfd-2b33-d533-e0b2-564c12223eec@linux.intel.com> (raw)
In-Reply-To: <20200113051800.GP2818@vkoul-mobl>
On 1/12/20 11:18 PM, Vinod Koul wrote:
> On 10-01-20, 10:08, Pierre-Louis Bossart wrote:
>>
>>>>> The "big" difference is that probe is called by core (asoc) and not by
>>>>> driver onto themselves.. IMO that needs to go away.
>>>>
>>>> What I did is not different from what existed already with platform devices.
>>>> They were manually created, weren't they?
>>>
>>> Manual creation of device based on a requirement is different, did I ask
>>> you why you are creating device :)
>>>
>>> I am simple asking you not to call probe in the driver. If you need
>>> that, move it to core! We do not want these kind of things in the
>>> drivers...
>>
>> What core are you talking about?
>
> soundwire core ofcourse! IMO All that which goes into soundwire-bus-objs is
> considered as soundwire core part and rest are drivers intel, qc, so on!
This master code was added to the bus: v
v
soundwire-bus-objs := bus_type.o bus.o master.o slave.o mipi_disco.o
stream.o
obj-$(CONFIG_SOUNDWIRE) += soundwire-bus.o
and the API is also part of the sdw.h include file. That seems to meet
exactly what you describe above, no?
git grep sdw_master_device_add (reformatted output)
drivers/soundwire/intel_init.c:
md = sdw_master_device_add(&intel_sdw_driver,
drivers/soundwire/master.c:
*sdw_master_device_add(struct sdw_master_driver *driver,
drivers/soundwire/master.c:
EXPORT_SYMBOL_GPL(sdw_master_device_add);
include/linux/soundwire/sdw.h:
*sdw_master_device_add(struct sdw_master_driver *driver,
So, what exactly is the issue?
We are not 'calling the probe in the [Intel] driver' as you state it, we
use a SoundWire core API which in turn will create a device. The device
core takes care of calling the probe, see the master.c code which is NOT
Intel-specific.
>>
>> The SOF intel driver needs to create a device, which will then be bound with
>> a SoundWire master driver.
>>
>> What I am doing is no different from what your team did with
>> platform_register_device, I am really lost on what you are asking.
>
> Again repeating myself, you call an API to do that is absolutely fine,
> but we don't do that in drivers or open code these things
That is still quite unclear, what 'open-coding' are you referring to?
I am starting to wonder if you missed the addition of the master
functionality in the previous patch:
[PATCH v5 08/17] soundwire: add initial definitions for sdw_master_device
What this patch 9 does is call the core-defined API and implement the
intel-specific master driver.
>
>>>>>> FWIW, the implementation here follows what was suggested for Greybus 'Host
>>>>>> Devices' [1] [2], so it's not like I am creating any sort of dangerous
>>>>>> precedent.
>>>>>>
>>>>>> [1]
>>>>>> https://elixir.bootlin.com/linux/latest/source/drivers/greybus/es2.c#L1275
>>>>>> [2] https://elixir.bootlin.com/linux/latest/source/drivers/greybus/hd.c#L124
>>>>>
>>>>> And if you look closely all this work is done by core not by drivers!
>>>>> Drivers _should_ never do all this, it is the job of core to do that for
>>>>> you.
>>>>
>>>> Please look at the code again, you have a USB probe that will manually call
>>>> the GreyBus device creation.
>>>>
>>>> static int ap_probe(struct usb_interface *interface,
>>>> const struct usb_device_id *id)
>>>> {
>>>> hd = gb_hd_create(&es2_driver, &udev->dev,
>>>>
>>>>
>>>> static struct usb_driver es2_ap_driver = {
>>>> .name = "es2_ap_driver",
>>>> .probe = ap_probe, <<< code above
>>>> .disconnect = ap_disconnect,
>>>> .id_table = id_table,
>>>> .soft_unbind = 1,
>>>> };
>>>
>>> Look closely the driver es2 calls into greybus core hd.c and gets the
>>> work done, subtle but a big differances in the approaches..
>>
>> I am sorry, I have absolutely no idea what you are referring to.
>>
>> The code I copy/pasted here makes no call to the greybus core, it's ap_probe
>> -> gb_hd_create. No core involved. If I am mistaken, please show me what I
>> got wrong.
>
> 1. es2_ap_driver is host controller driver
>
> 2. gb_hd_create() is an API provided by greybus core!
same in my code...
>
> es2 driver doesn't open code creation like you are doing in intel driver,
> it doesn't call probe on its own, greybus does that
>
> This is very common pattern in linux kernel subsytems, drivers dont do
> these things, the respective subsystem core does that... see about es2
> driver and implementation of gb_hd_create(). See callers of
> platform_register_device() and its implementation.
>
> I don't know how else I can explain this to you, is something wrong in
> how I conveyed this info or you... or something else, I dont know!!!
the new 'master' functionality is part of the bus code, so please
clarify what you see as problematic for the partition.
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
https://mailman.alsa-project.org/mailman/listinfo/alsa-devel
next prev parent reply other threads:[~2020-01-14 13:13 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
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 [this message]
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=d77dcdfd-2b33-d533-e0b2-564c12223eec@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).