[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-Id: <20190916212342.12578-1-pierre-louis.bossart@linux.intel.com>
Date: Mon, 16 Sep 2019 16:23:33 -0500
From: Pierre-Louis Bossart <pierre-louis.bossart@...ux.intel.com>
To: alsa-devel@...a-project.org
Cc: linux-kernel@...r.kernel.org, tiwai@...e.de, broonie@...nel.org,
vkoul@...nel.org, gregkh@...uxfoundation.org, jank@...ence.com,
srinivas.kandagatla@...aro.org, slawomir.blauciak@...el.com,
Bard liao <yung-chuan.liao@...ux.intel.com>,
Rander Wang <rander.wang@...ux.intel.com>,
Ranjani Sridharan <ranjani.sridharan@...ux.intel.com>,
Pierre-Louis Bossart <pierre-louis.bossart@...ux.intel.com>
Subject: [RFC PATCH 0/9] soundwire: add Master device support, GreyBus style
The current use of platform devices leads to limitations in terms of
API and problematic reference counts flagged during the review of
sysfs patches.
As suggested by Greg KH, this patch series introduces a 'Master
device' and gets rid of platform devices. The code is inspired by
GreyBus, e.g. 'gb_hd_driver' is translated for the SoundWire context
as 'sdw_md_driver' and likewise 'gb_host_device' is translated as
'sdw_master_device'. There are differences in the way devices are
created, using device_register instead of the multiple steps used in
GreyBus.
All I know about GreyBus is that it's based on Unipro, so the
code updates are based on a first-order analysis, it could very well
be I missed concepts while trying to reverse-engineer the code in
staging/greybus/. I focused on the concepts mainly and it's also
possible that the dual-license for new files or plan-vanilla
EXPORT_SYMBOL are not appropriate for all the changes in this
series. Please don't take errors as deliberate intent to work-around
GPL but rather as an indicator of maturity of the code only developed
in the last few days.
These changes make it possible to provide new callbacks, e.g splitting
the bus startup from the initializations in probe, which is very much
desired on Intel platforms to detect the machine driver as early as
possible before the hardware is fully powered/enable. These patches
will be provided as a separate RFC later today to illustrate the
benefit of these changes.
To make the code more consistent the first series of patches are
renames. I did not rename 'sdw_slave' or 'module_sdw_driver' to avoid
compatibility issues since there are codec drivers almost ready for
integration. I don't have any specific opinion on if/when additional
renames should be done, as long as there is a means to clearly
identify what is specific to a SoundWire Master I am fine.
Feedback and reviews welcome.
Bard Liao (1):
soundwire: add device driver to sdw_md_driver
Pierre-Louis Bossart (8):
soundwire: renames to prepare support for master drivers/devices
soundwire: rename dev_to_sdw_dev macro
soundwire: rename drv_to_sdw_slave_driver macro
soundwire: bus_type: rename sdw_drv_ to sdw_slave_drv
soundwire: intel: rename res field as link_res
soundwire: add support for sdw_slave_type
soundwire: add initial definitions for sdw_master_device
soundwire: intel: remove platform devices and provide new interface
drivers/base/regmap/regmap-sdw.c | 4 +-
drivers/soundwire/Makefile | 2 +-
drivers/soundwire/bus.c | 2 +-
drivers/soundwire/bus_type.c | 60 +++---
drivers/soundwire/intel.c | 117 ++++++-----
drivers/soundwire/intel.h | 22 +--
drivers/soundwire/intel_init.c | 293 +++++++++++++++++++---------
drivers/soundwire/master.c | 80 ++++++++
drivers/soundwire/slave.c | 9 +-
include/linux/soundwire/sdw.h | 39 +++-
include/linux/soundwire/sdw_intel.h | 86 +++++++-
include/linux/soundwire/sdw_type.h | 34 +++-
12 files changed, 551 insertions(+), 197 deletions(-)
create mode 100644 drivers/soundwire/master.c
--
2.20.1
Powered by blists - more mailing lists