The Linux Kernel Mailing List
 help / color / mirror / Atom feed
From: Vinod Koul <vkoul@kernel.org>
To: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Cc: alsa-devel@alsa-project.org, linux-kernel@vger.kernel.org,
	tiwai@suse.de, broonie@kernel.org, gregkh@linuxfoundation.org,
	jank@cadence.com, srinivas.kandagatla@linaro.org,
	slawomir.blauciak@intel.com,
	Bard liao <yung-chuan.liao@linux.intel.com>,
	Rander Wang <rander.wang@linux.intel.com>,
	Ranjani Sridharan <ranjani.sridharan@linux.intel.com>,
	Hui Wang <hui.wang@canonical.com>,
	Sanyog Kale <sanyog.r.kale@intel.com>
Subject: Re: [PATCH 2/8] soundwire: intel: transition to sdw_master_device/driver support
Date: Tue, 3 Mar 2020 11:35:47 +0530	[thread overview]
Message-ID: <20200303060547.GQ4148@vkoul-mobl> (raw)
In-Reply-To: <20200227223206.5020-3-pierre-louis.bossart@linux.intel.com>

On 27-02-20, 16:32, Pierre-Louis Bossart wrote:

> +static struct sdw_intel_ctx
> +*sdw_intel_probe_controller(struct sdw_intel_res *res)
> +{
> +	struct sdw_intel_link_res *link;
> +	struct sdw_intel_ctx *ctx;
> +	struct acpi_device *adev;
> +	struct sdw_master_device *md;
> +	unsigned long time;
> +	u32 link_mask;
> +	int count;
> +	int i;
> +
> +	if (!res)
> +		return NULL;
> +
> +	if (acpi_bus_get_device(res->handle, &adev))
> +		return NULL;
> +
> +	if (!res->count)
> +		return NULL;
> +
> +	count = res->count;
>  	dev_dbg(&adev->dev, "Creating %d SDW Link devices\n", count);
>  
>  	ctx = kzalloc(sizeof(*ctx), GFP_KERNEL);
>  	if (!ctx)
>  		return NULL;
>  
> -	ctx->count = count;
> -	ctx->links = kcalloc(ctx->count, sizeof(*ctx->links), GFP_KERNEL);
> +	ctx->links = kcalloc(count, sizeof(*ctx->links), GFP_KERNEL);
>  	if (!ctx->links)
>  		goto link_err;
>  
> +	ctx->count = count;
> +	ctx->mmio_base = res->mmio_base;
> +	ctx->link_mask = res->link_mask;
> +	ctx->handle = res->handle;
> +
>  	link = ctx->links;
> +	link_mask = ctx->link_mask;
>  
>  	/* Create SDW Master devices */
> -	for (i = 0; i < count; i++) {
> -		if (link_mask && !(link_mask & BIT(i))) {
> -			dev_dbg(&adev->dev,
> -				"Link %d masked, will not be enabled\n", i);
> -			link++;
> +	for (i = 0; i < count; i++, link++) {
> +		if (link_mask && !(link_mask & BIT(i)))
>  			continue;
> -		}
>  
> +		link->mmio_base = res->mmio_base;
>  		link->registers = res->mmio_base + SDW_LINK_BASE
> -					+ (SDW_LINK_SIZE * i);
> +			+ (SDW_LINK_SIZE * i);
>  		link->shim = res->mmio_base + SDW_SHIM_BASE;
>  		link->alh = res->mmio_base + SDW_ALH_BASE;
> -
> +		link->irq = res->irq;
>  		link->ops = res->ops;
>  		link->dev = res->dev;
> +		link->clock_stop_quirks = res->clock_stop_quirks;
>  
> -		memset(&pdevinfo, 0, sizeof(pdevinfo));
> +		md = sdw_master_device_add("intel-master",
> +					   res->parent,
> +					   acpi_fwnode_handle(adev),
> +					   i,
> +					   link);

So we add the device in intel layer

>  
> -		pdevinfo.parent = res->parent;
> -		pdevinfo.name = "int-sdw";
> -		pdevinfo.id = i;
> -		pdevinfo.fwnode = acpi_fwnode_handle(adev);
> +		if (IS_ERR(md)) {
> +			dev_err(&adev->dev, "Could not create link %d\n", i);
> +			goto err;
> +		}
>  
> -		pdev = platform_device_register_full(&pdevinfo);
> -		if (IS_ERR(pdev)) {
> -			dev_err(&adev->dev,
> -				"platform device creation failed: %ld\n",
> -				PTR_ERR(pdev));
> -			goto pdev_err;
> +		/*
> +		 * we need to wait for the bus to be probed so that we
> +		 * can report ACPI information to the upper layers
> +		 */
> +		time = wait_for_completion_timeout(&md->probe_complete,
> +				msecs_to_jiffies(SDW_INTEL_MASTER_PROBE_TIMEOUT));

Then wait for probe to complete..

> +static int
> +sdw_intel_startup_controller(struct sdw_intel_ctx *ctx)
> +{
> +	struct acpi_device *adev;
> +	struct sdw_intel_link_res *link;
> +	struct sdw_master_device *md;
> +	u32 caps;
> +	u32 link_mask;
> +	int i;
> +
> +	if (acpi_bus_get_device(ctx->handle, &adev))
> +		return -EINVAL;
> +
> +	/* Check SNDWLCAP.LCOUNT */
> +	caps = ioread32(ctx->mmio_base + SDW_SHIM_BASE + SDW_SHIM_LCAP);
> +	caps &= GENMASK(2, 0);
> +
> +	/* Check HW supported vs property value */
> +	if (caps < ctx->count) {
> +		dev_err(&adev->dev,
> +			"BIOS master count is larger than hardware capabilities\n");
> +		return -EINVAL;
> +	}
> +
> +	if (!ctx->links)
> +		return -EINVAL;
> +
> +	link = ctx->links;
> +	link_mask = ctx->link_mask;
> +
> +	/* Startup SDW Master devices */
> +	for (i = 0; i < ctx->count; i++, link++) {
> +		if (link_mask && !(link_mask & BIT(i)))
> +			continue;
> +
> +		md = link->md;
> +
> +		sdw_master_device_startup(md);

And finally start the device.

If i look at bigger picture:

PCI SOF driver scans the capabilities and finds SoundWire supported:
 - Invokes sdw_intel_probe_controller() 
        - This adds sdw_master_device and waits till the probe is
          complete.
 - Invokes sdw_intel_startup_controller()
        - It starts up the controller by calling
          sdw_master_device_startup()

Now, I guess at the peril of repeating myself again:

Why not do:

- PCI SOF driver scans the capabilities and finds SoundWire supported:
  - Invokes sdw_intel_probe_controller()
        - This adds sdw_master_device
        - Does rest of device init and context init
  - Invoked sdw_intel_startup_controller()
        - Calls sdw_master_device_startup() to start

You will get more fine grained control of the sequencing, no need to
wait for dummy probe to be over. The device for these would be parent
PCI SOF device and driver PCI SOF driver.

So in summary I do not see a reason for even Intel to have a dummy
soundwire_master_driver.

-- 
~Vinod

  parent reply	other threads:[~2020-03-03  6:05 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-02-27 22:31 [PATCH 0/8] soundwire: remove platform devices, add SOF interfaces Pierre-Louis Bossart
2020-02-27 22:31 ` [PATCH 1/8] soundwire: bus_type: add master_device/driver support Pierre-Louis Bossart
2020-02-28  7:32   ` Greg KH
2020-02-28 15:53     ` Pierre-Louis Bossart
2020-03-03  5:41   ` Vinod Koul
2020-03-03 15:23     ` Pierre-Louis Bossart
2020-03-04  9:53       ` Vinod Koul
2020-03-04 15:17         ` Pierre-Louis Bossart
2020-03-04 16:28           ` Greg KH
2020-03-05  6:46             ` Vinod Koul
2020-03-05  6:36           ` Vinod Koul
2020-03-05 12:46             ` Pierre-Louis Bossart
2020-03-06  5:01               ` Vinod Koul
2020-03-06 15:40                 ` Pierre-Louis Bossart
2020-03-11  6:36                   ` Vinod Koul
2020-03-11 14:44                     ` Pierre-Louis Bossart
2020-03-13 11:50                       ` Vinod Koul
2020-03-13 16:54                         ` Pierre-Louis Bossart
2020-03-14  9:49                           ` Vinod Koul
2020-03-16 19:15                             ` Pierre-Louis Bossart
2020-03-20 15:33                               ` Vinod Koul
2020-03-20 16:36                                 ` Pierre-Louis Bossart
2020-03-23 12:16                                   ` Vinod Koul
2020-02-27 22:32 ` [PATCH 2/8] soundwire: intel: transition to sdw_master_device/driver support Pierre-Louis Bossart
2020-02-28  7:34   ` Greg KH
2020-02-28 16:01     ` Pierre-Louis Bossart
2020-03-03  6:05   ` Vinod Koul [this message]
2020-02-27 22:32 ` [PATCH 3/8] soundwire: intel_init: add implementation of sdw_intel_enable_irq() Pierre-Louis Bossart
2020-02-27 22:32 ` [PATCH 4/8] soundwire: intel_init: use EXPORT_SYMBOL_NS Pierre-Louis Bossart
2020-02-27 22:32 ` [PATCH 5/8] soundwire: intel/cadence: merge Soundwire interrupt handlers/threads Pierre-Louis Bossart
2020-02-27 22:32 ` [PATCH 6/8] soundwire: intel: add helpers for link power down and shim wake Pierre-Louis Bossart
2020-02-27 22:32 ` [PATCH 7/8] soundwire: intel: add wake interrupt support Pierre-Louis Bossart
2020-02-27 22:32 ` [PATCH 8/8] soundwire: intel_init: save Slave(s) _ADR info in sdw_intel_ctx Pierre-Louis Bossart
2020-02-28  7:32 ` [PATCH 0/8] soundwire: remove platform devices, add SOF interfaces Greg KH

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=20200303060547.GQ4148@vkoul-mobl \
    --to=vkoul@kernel.org \
    --cc=alsa-devel@alsa-project.org \
    --cc=broonie@kernel.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=hui.wang@canonical.com \
    --cc=jank@cadence.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=pierre-louis.bossart@linux.intel.com \
    --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=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