| Message ID | 20190430230934.4321-1-pierre-louis.bossart@linux.intel.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | ASoC: SOF: improvements for ABI checks and Intel code | expand |
On 5/3/19 12:40 AM, Mark Brown wrote: > On Tue, Apr 30, 2019 at 06:09:15PM -0500, Pierre-Louis Bossart wrote: >> This series is a set of relatively small SOF changes after the big >> batch merged last week (Thanks!). Since we are very close to the merge >> window and in May where most of the world takes time off, it'd be >> perfectly understandable if those patches were queued for 5.3, after >> feedback and corrections as needed. > > The headline thing I see when this pops up in my inbox is yet another 20 > patch series for these DSPs, I'm not going to notice the size of the > patches on a first pass. As I think you've noticed there's a lot of > reviewer fatigue setting in with this stuff, one thing that'd really > help here is if there were some help from Intel people with review for > the DPCM code. I can certainly understand reviewer fatigue, i've had to put a time limit on daily reviews to keep my sanity, but I don't get your last point. These patches were submitted and reviewed by Intel people on GitHub, what you see here is the result of multiple iterations precisely to make sure the patches are acceptable for upstream. we've set the goal of having two Intel aprovers for each patch. Can you elaborate on how we can make your life simpler? FYI we are going to have a number of fixes coming in the next 2 months for HDaudio support, changes to IPC/power flows to support D0ix states and SoundWire, 3rd party firmware module support, etc, so I really want to make sure you are comfortable with SOF-related patches, their level of maturity and the submission rate. Thanks! -Pierre
On 5/5/19 10:51 PM, Mark Brown wrote: > On Fri, May 03, 2019 at 09:47:39AM -0500, Pierre-Louis Bossart wrote: >> On 5/3/19 12:40 AM, Mark Brown wrote: > >>> reviewer fatigue setting in with this stuff, one thing that'd really >>> help here is if there were some help from Intel people with review for >>> the DPCM code. > >> I can certainly understand reviewer fatigue, i've had to put a time limit on >> daily reviews to keep my sanity, but I don't get your last point. These >> patches were submitted and reviewed by Intel people on GitHub, what you see >> here is the result of multiple iterations precisely to make sure the patches >> are acceptable for upstream. we've set the goal of having two Intel aprovers >> for each patch. Can you elaborate on how we can make your life simpler? > > The last point there is that Intel only write patches, nobody from Intel > is reviewing other people's patches especially in areas of the code like > DPCM which are complex, fragile and where Intel is by far the most > active user. It's a valid point, and for now we indeed only check for non-regressions and provide point solutions without looking at the bigger picture. We have a couple of people ramping up (Ranjani, Libin, Guennadi, Jaska) and hopefully at some point we'll be able to review and improve.
On Mon, May 06, 2019 at 09:59:24AM -0500, Pierre-Louis Bossart wrote: > On 5/5/19 10:51 PM, Mark Brown wrote: > > The last point there is that Intel only write patches, nobody from Intel > > is reviewing other people's patches especially in areas of the code like > > DPCM which are complex, fragile and where Intel is by far the most > > active user. > It's a valid point, and for now we indeed only check for non-regressions and > provide point solutions without looking at the bigger picture. We have a > couple of people ramping up (Ranjani, Libin, Guennadi, Jaska) and hopefully > at some point we'll be able to review and improve. Even just testing (rather than reviewing, though obviously reviewing would be good!) patches off the list would be very helpful and is close to the regression testing stuff you're already doing.
This series is a set of relatively small SOF changes after the big batch merged last week (Thanks!). Since we are very close to the merge window and in May where most of the world takes time off, it'd be perfectly understandable if those patches were queued for 5.3, after feedback and corrections as needed. First we added optional stricter ABI checks when the firmware, topology and kernel ABI levels differ, which can happen when patches are merged at different times on Github. This is mainly for developers and the Github CI to track disconnects, should they happen despite our new process to keep evolutions under control. This option has no impact on the usual problem of updating the kernel without updating the firmware files. The Intel changes are mainly a) fixes for the slave mode suppport b) clean-ups such as removal of a static index for HDAudio support or removal of unneeded include file c) use of a workqueue to defer period elapsed events after the IPC completion. d) simplification of the IRQ code e) fixes to deal with resume on HDaudio links. In the previous patchset we removed the RESUME_INFO flag but missed the need to explicitly set the hw_params on resume. f) a set of routines to dump the Intel IPC registers, mainly for early platform enablement. Keyon Jie (7): ASoC: SOF: Intel: cnl: add pointer ops to use DPIB position ASoC: SOF: PCM: add period_elapsed work to fix race condition in interrupt context ASoC: SOF: Intel: use snd_sof_pcm_period_elapsed ASoC: SOF: ipc: use snd_sof_pcm_period_elapsed ASoC: SOF: Intel: hda-ipc: simplify handling of IPC IRQ ASoC: SOF: Intel: hda-stream: store stream capabilities ASoC: SOF: Intel: hda-stream: handle real stream interrupts only Pan Xiuli (3): ASoC: SOF: IPC: add ipc dump function ASoC: SOF: Intel: APL: add ipc dump function ASoC: SOF: Intel: CNL: add ipc dump function Pierre-Louis Bossart (4): ASoC: SOF: add Kconfig option for strict ABI checks ASOC: SOF: ipc: add support for stricter ABI checks ASoC: SOF: topology: add support for stricter ABI checks ASoC: SOF: Intel: hda-pcm: remove useless dependency on hdac_ext Ranjani Sridharan (1): ASoC: SOF: intel: hda: add hw_params_upon_resume flag for hda stream Zhu Yingjiang (4): ASoC: SOF: Intel: hda: add the SSP Host Device memory space ASoC: SOF: Intel: hda: add SSP info to the chip info struct ASoC: SOF: Intel: hda: set I2S slave before enabling DSP ASoC: SOF: Intel: hda: set bus->idx as 0 sound/soc/sof/Kconfig | 15 ++++++++++ sound/soc/sof/intel/apl.c | 4 +++ sound/soc/sof/intel/cnl.c | 27 +++++++++++++++--- sound/soc/sof/intel/hda-bus.c | 9 ++++-- sound/soc/sof/intel/hda-dai.c | 23 +++++++++------ sound/soc/sof/intel/hda-dsp.c | 16 +++++++++++ sound/soc/sof/intel/hda-ipc.c | 13 ++++----- sound/soc/sof/intel/hda-loader.c | 11 ++++++++ sound/soc/sof/intel/hda-pcm.c | 1 - sound/soc/sof/intel/hda-stream.c | 15 ++++++++-- sound/soc/sof/intel/hda.c | 18 ++++++++++++ sound/soc/sof/intel/hda.h | 23 +++++++++++++++ sound/soc/sof/intel/shim.h | 2 ++ sound/soc/sof/ipc.c | 12 +++++++- sound/soc/sof/ops.h | 12 ++++++++ sound/soc/sof/pcm.c | 48 ++++++++++++++++++++++++++++++++ sound/soc/sof/pm.c | 3 ++ sound/soc/sof/sof-priv.h | 5 +++- sound/soc/sof/topology.c | 43 +++++++++++++++++++--------- 19 files changed, 257 insertions(+), 43 deletions(-)