From: Greg KH <gregkh@linuxfoundation.org>
To: Vinod Koul <vkoul@kernel.org>
Cc: pierre-louis.bossart@linux.intel.com,
alsa-devel@alsa-project.org, tiwai@suse.de,
mengdong.lin@intel.com, linux-kernel@vger.kernel.org,
ranjani.sridharan@linux.intel.com, hui.wang@canonical.com,
broonie@kernel.org, srinivas.kandagatla@linaro.org,
jank@cadence.com, slawomir.blauciak@intel.com,
sanyog.r.kale@intel.com,
Bard Liao <yung-chuan.liao@linux.intel.com>,
rander.wang@linux.intel.com
Subject: Re: [RFC 1/5] soundwire: bus_type: add sdw_master_device support
Date: Tue, 28 Apr 2020 08:55:24 +0200 [thread overview]
Message-ID: <20200428065524.GA992087@kroah.com> (raw)
In-Reply-To: <20200428064951.GA56386@vkoul-mobl.Dlink>
On Tue, Apr 28, 2020 at 12:19:51PM +0530, Vinod Koul wrote:
> On 28-04-20, 08:37, Greg KH wrote:
> > On Tue, Apr 28, 2020 at 10:01:44AM +0530, Vinod Koul wrote:
> > > > > That is not true for everyone, it is only true for Intel, pls call that
> > > > > out as well...
> > > >
> > > > Why is it not true for everyone? How else do you get the pm stuff back
> > > > to your hardware?
> > >
> > > The rest of the world would do using the real controller device. For
> > > example the soundwire controller on Qualcomm devices is enumerated as a
> > > DT device and is using these...
> > >
> > > If Intel had a standalone controller or enumerated as individual
> > > functions, it would have been a PCI device and would manage as such
> >
> > If it is not a standalone controller, what exactly is it? I thought it
> > was an acpi device, am I mistaken?
> >
> > What is the device that the proper soundwire controller driver binds to
> > on an Intel-based system?
>
> The HDA controller which is a PCI device. The device represent HDA
> function, DSP and Soundwire controller instances (yes it is typically
> more than one instance)
Then those "instances" should be split up into individual devices that a
driver can bind to. See the work happening on the "virtual" bus for
examples of how that can be done.
A platform device better not be being used here, I'm afraid to look at
the code now...
greg k-h
WARNING: multiple messages have this Message-ID (diff)
From: Greg KH <gregkh@linuxfoundation.org>
To: Vinod Koul <vkoul@kernel.org>
Cc: Bard Liao <yung-chuan.liao@linux.intel.com>,
alsa-devel@alsa-project.org, linux-kernel@vger.kernel.org,
tiwai@suse.de, broonie@kernel.org, jank@cadence.com,
srinivas.kandagatla@linaro.org, rander.wang@linux.intel.com,
ranjani.sridharan@linux.intel.com, hui.wang@canonical.com,
pierre-louis.bossart@linux.intel.com, sanyog.r.kale@intel.com,
slawomir.blauciak@intel.com, mengdong.lin@intel.com
Subject: Re: [RFC 1/5] soundwire: bus_type: add sdw_master_device support
Date: Tue, 28 Apr 2020 08:55:24 +0200 [thread overview]
Message-ID: <20200428065524.GA992087@kroah.com> (raw)
In-Reply-To: <20200428064951.GA56386@vkoul-mobl.Dlink>
On Tue, Apr 28, 2020 at 12:19:51PM +0530, Vinod Koul wrote:
> On 28-04-20, 08:37, Greg KH wrote:
> > On Tue, Apr 28, 2020 at 10:01:44AM +0530, Vinod Koul wrote:
> > > > > That is not true for everyone, it is only true for Intel, pls call that
> > > > > out as well...
> > > >
> > > > Why is it not true for everyone? How else do you get the pm stuff back
> > > > to your hardware?
> > >
> > > The rest of the world would do using the real controller device. For
> > > example the soundwire controller on Qualcomm devices is enumerated as a
> > > DT device and is using these...
> > >
> > > If Intel had a standalone controller or enumerated as individual
> > > functions, it would have been a PCI device and would manage as such
> >
> > If it is not a standalone controller, what exactly is it? I thought it
> > was an acpi device, am I mistaken?
> >
> > What is the device that the proper soundwire controller driver binds to
> > on an Intel-based system?
>
> The HDA controller which is a PCI device. The device represent HDA
> function, DSP and Soundwire controller instances (yes it is typically
> more than one instance)
Then those "instances" should be split up into individual devices that a
driver can bind to. See the work happening on the "virtual" bus for
examples of how that can be done.
A platform device better not be being used here, I'm afraid to look at
the code now...
greg k-h
next prev parent reply other threads:[~2020-04-28 6:56 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-04-16 20:55 [RFC 0/5] soundwire: create master device and use it Bard Liao
2020-04-16 20:55 ` Bard Liao
2020-04-16 20:55 ` [RFC 1/5] soundwire: bus_type: add sdw_master_device support Bard Liao
2020-04-16 20:55 ` Bard Liao
2020-04-20 7:26 ` Vinod Koul
2020-04-20 7:26 ` Vinod Koul
2020-04-23 14:24 ` Greg KH
2020-04-23 14:24 ` Greg KH
2020-04-28 4:31 ` Vinod Koul
2020-04-28 4:31 ` Vinod Koul
2020-04-28 6:37 ` Greg KH
2020-04-28 6:37 ` Greg KH
2020-04-28 6:49 ` Vinod Koul
2020-04-28 6:49 ` Vinod Koul
2020-04-28 6:55 ` Greg KH [this message]
2020-04-28 6:55 ` Greg KH
2020-04-28 7:51 ` Vinod Koul
2020-04-28 7:51 ` Vinod Koul
2020-04-30 3:24 ` Bard liao
2020-04-30 4:57 ` Vinod Koul
2020-04-30 4:57 ` Vinod Koul
2020-04-16 20:55 ` [RFC 2/5] soundwire: master: use device node pointer from master device Bard Liao
2020-04-16 20:55 ` Bard Liao
2020-04-16 20:55 ` [RFC 3/5] soundwire: qcom: fix error handling in probe Bard Liao
2020-04-16 20:55 ` Bard Liao
2020-04-20 7:42 ` Srinivas Kandagatla
2020-04-20 7:42 ` Srinivas Kandagatla
2020-04-16 20:55 ` [RFC 4/5] soundwire: qcom: add sdw_master_device support Bard Liao
2020-04-16 20:55 ` Bard Liao
2020-04-16 20:55 ` [RFC 5/5] soundwire: intel: transition to sdw_master_device Bard Liao
2020-04-16 20:55 ` Bard Liao
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=20200428065524.GA992087@kroah.com \
--to=gregkh@linuxfoundation.org \
--cc=alsa-devel@alsa-project.org \
--cc=broonie@kernel.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=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 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.