Re: [RFC 1/5] soundwire: bus_type: add sdw_master_device support

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




On 4/28/2020 3:51 PM, Vinod Koul wrote:
On 28-04-20, 08:55, Greg KH wrote:
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.
Yes removing platform devices is the goal for Intel now :) Pierre & Bard
have been diligently trying to solve this.

Only difference is the means to end goal. I am not convinced that this
should be in soundwire subsystem.

Looks like folks are trying to review and port to use this bus. Makes
sense to me..
https://lore.kernel.org/netdev/c5197d2f-3840-d304-6b09-d334cae81294@xxxxxxxxxxxxxxx/

A platform device better not be being used here, I'm afraid to look at
the code now...
Well if the plan for 'virtual-bus' goes well, it should be  a simple
replacement of platform->virtual for Intel driver. Rest of the driver
should not be impacted :)

We can't expect when will 'virtual-bus' be upstream and it's not feasible
to wait forever. Can we move forward with current solution and switch to
'virtual-bus' whenever it is upstream?

Thanks



[Index of Archives]     [ALSA User]     [Linux Audio Users]     [Pulse Audio]     [Kernel Archive]     [Asterisk PBX]     [Photo Sharing]     [Linux Sound]     [Video 4 Linux]     [Gimp]     [Yosemite News]

  Powered by Linux