All of lore.kernel.org
 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, tiwai@suse.de,
	gregkh@linuxfoundation.org, linux-kernel@vger.kernel.org,
	ranjani.sridharan@linux.intel.com, hui.wang@canonical.com,
	broonie@kernel.org, srinivas.kandagatla@linaro.org,
	jank@cadence.com, mengdong.lin@intel.com,
	slawomir.blauciak@intel.com, sanyog.r.kale@intel.com,
	Bard Liao <yung-chuan.liao@linux.intel.com>,
	rander.wang@linux.intel.com, bard.liao@intel.com
Subject: Re: [PATCH 3/3] soundwire: bus_type: add sdw_master_device support
Date: Wed, 13 May 2020 15:46:42 +0530	[thread overview]
Message-ID: <20200513101642.GC14092@vkoul-mobl> (raw)
In-Reply-To: <86d45af8-93db-d284-64d4-efa22ccc0908@linux.intel.com>

On 12-05-20, 12:01, Pierre-Louis Bossart wrote:
> > > > > > 
> > > > > > There isn't any known implementation with more than one controller.
> > > > > 
> > > > > But then it can come in "future" right. So lets try to make it future
> > > > > proof by not using the link_id (we can expose that as a sysfs if people
> > > > > want to know). So a global unique id needs to allocated (hint: idr or
> > > > > equivalent) and used as master_id
> > > > 
> > > > Can you clarify if you are asking for a global ID for Intel/ACPI
> > > > platforms,
> > > > or for DT as well? I can't figure out from the soundwire-controller.yaml
> > > > definitions if there is already a notion of unique ID.
> > > 
> > > If ACPI was unique, then I was planning to update the definition below
> > > to include that. Given that it is not the case, let's make it agnostic to
> > > underlying firmware.
> > 
> > I am not sure I understand how this would be done.
> > 
> > The call sequence is
> > 
> > sdw_bus_master_add(bus)
> >      sdw_master_device_add(bus, parent, fw_node)
> > 
> > At the bus level, we don't have any information on which controller the
> > bus is related to.

This should be done inside the sdw_bus. controller should not care about
this IMO.

> > We'd need to add an argument to sdw_bus_master_add() and have the
> > controller unique ID be allocated outside of the SoundWire core, hence
> > my question on whether the DT definition should not be extended.
> 
> And btw I don't think it makes sense to add a new definition for Intel. We
> already have a notion of HDaudio bus->idx that's set to zero since we don't
> have a case for multiple HDaudio controllers.
> 
> if we ever do have more than once controller, then we should rely on HDaudio
> bus->idx as the identifier and not create one specifically for SoundWire -
> which means as I mentioned above passing an argument and not defining a
> controller ID in the SoundWire core.

I was thinking of following code in bus.c

static DEFINE_IDA(sdw_ida);

static sdw_get_id(struct sdw_bus *bus)
{
        int rc = ida_alloc(&sdw_ida, GFP_KERNEL);

        if (rc < 0)
                return rc;

        bus->id = rc;
        return 0;
}

int sdw_add_bus_master(struct sdw_bus *bus)
{
        ...

        ret = sdw_get_id(bus);

        ...
}

void sdw_delete_bus_master(struct sdw_bus *bus)
{
        da_free(&sdw_ida, bus->id);
}

This way you get a unique master number across all devices and this has
nothing to do with link/of ids and is used for numbering masters in
sysfs uniquely.

HTH
-- 
~Vinod

      reply	other threads:[~2020-05-13 10:16 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-04-29 18:51 [PATCH 0/3] soundwire: bus_type: add sdw_master_device support Bard Liao
2020-04-29 18:51 ` Bard Liao
2020-04-29 18:51 ` [PATCH 1/3] soundwire: bus: rename sdw_bus_master_add/delete, add arguments Bard Liao
2020-04-29 18:51   ` Bard Liao
2020-04-29 18:51 ` [PATCH 2/3] soundwire: bus_type: introduce sdw_slave_type and sdw_master_type Bard Liao
2020-04-29 18:51   ` Bard Liao
2020-04-29 18:51 ` [PATCH 3/3] soundwire: bus_type: add sdw_master_device support Bard Liao
2020-04-29 18:51   ` Bard Liao
2020-05-11  6:32   ` Vinod Koul
2020-05-11  6:32     ` Vinod Koul
2020-05-11  8:04     ` Liao, Bard
2020-05-11  8:04       ` Liao, Bard
2020-05-11  9:00       ` Vinod Koul
2020-05-11  9:00         ` Vinod Koul
2020-05-11 11:34         ` Liao, Bard
2020-05-11 11:34           ` Liao, Bard
2020-05-11 11:41           ` Vinod Koul
2020-05-11 11:41             ` Vinod Koul
2020-05-11 19:00     ` Pierre-Louis Bossart
2020-05-12  3:30       ` Vinod Koul
2020-05-12  3:30         ` Vinod Koul
2020-05-12 14:36         ` Pierre-Louis Bossart
2020-05-12 15:59           ` Vinod Koul
2020-05-12 16:08             ` Pierre-Louis Bossart
2020-05-12 17:01               ` Pierre-Louis Bossart
2020-05-13 10:16                 ` Vinod Koul [this message]

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=20200513101642.GC14092@vkoul-mobl \
    --to=vkoul@kernel.org \
    --cc=alsa-devel@alsa-project.org \
    --cc=bard.liao@intel.com \
    --cc=broonie@kernel.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=hui.wang@canonical.com \
    --cc=jank@cadence.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mengdong.lin@intel.com \
    --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 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.