mbox series

[v4,00/13] ASoC: Intel: Catpt - Lynx and Wildcat point

Message ID 20200812205753.29115-1-cezary.rojewski@intel.com (mailing list archive)
Headers show
Series ASoC: Intel: Catpt - Lynx and Wildcat point | expand

Message

Cezary Rojewski Aug. 12, 2020, 8:57 p.m. UTC
Implement support for Lynxpoint and Wildcat Point AudioDSP. Catpt
solution deprecates existing sound/soc/intel/haswell which is removed in
the following series. This cover-letter is followed by 'Developer's deep
dive' message schedding light on catpt's key concepts and areas
addressed.

Due to high range of errors and desynchronization from recommendations
set by Windows solution, re-write came as a lower-cost solution compared
to refactoring /haswell/ with several series of patches.

Special thanks go to Marcin Barlik and Piotr Papierkowski for sharing
their LPT/WPT AudioDSP architecture expertise as well as helping
backtrack its historical background.
My thanks go to Amadeusz Slawinski for reviews and improvements proposed
on and off the internal list. Most of internal diff below is his
contribution.
Krzysztof Hejmowski helped me setup my own Xtensa environment and
recompile LPT/WPT FW binary sources what sped up the development greatly.

This would not have been possible without help from these champions,
especially considering how quickly the catpt was written: 2 weeks
features, 3 weeks optimizations. Thank you.

Userspace-exposed members are compatible with what is exposed by
deprecated solution as well as FW binary being re-used thus no harm is
done. The only visible differences are: the newly added 'Loopback Mute'
kcontrol and volume support extending to quad from stereo.

On top of fixing erros and design flows, catpt also adds module reload,
dynamic SRAM memory allocation during PCM runtime and exposes missing
userspace API: 'Loopback Mute' kcontrol, quad volume controls and sysfs
fw-version entries. Event tracing is provided to easy solution
debugging.

Following are not included in this update and are scheduled as later
addition:
- fw logging
- module (library) support

Note: LPT power up/down sequences might get aligned with WPT once enough
testing is done as capabilities are shared for both DSPs.
Note #2: Both LPT and WPT power up/down sequences may get optimized in
future updates as thanks to help from the Windows team, most of nuances
behind why/what/when in regard to hw registers have been backtracked and
reviewed again.

Link to developer's deep dive message:
https://www.spinics.net/lists/alsa-devel/msg113563.html

Changes in v4:
- fixed compilation with i386 kconfig (conflicting names)
- streamlined naming for SHIM and PCI registers to match SSP ones
  (SHIM_REG -> SHIM)
- catpt_component_probe removed and kcontrols again initializzed
  statically via snd_kcontrol_new array: this is to remove
  kctl->id.device shenanigans
- renamed catpt_set_ctlvol to catpt_set_dspvol - function name wasn't
  matching its purpose

Changes in v3:
- fixed IRAM mask usage in lpt_dsp_power_up (dsp.c)
- updated dbg message formatting in catpt_restore_fwimage as suggested
  by Andy
- fixed alignment for struct catpt_ssp_device_format
- catpt_set_ctlvol now verifies all-equal scenario based on all
  channels rather than just first two as requested by Amadeo
- fixed SPDX for registers.h

Changes in v2:
- fixed SPDX formatting for all header files as well as pcm.c
- fixed size used when memcping fs.c::fw_build_read as reported by Mark
- renamed struct catpt_pdata to struct catpt_spec (cosmetic)
- fixed erroneous path in catpt_load_block: region is properly released
- trace.h events for updating registers have been removed and usages
  replaced by dev_dbg (SRAMPGE/ LPCS)

- as requested by Andy, struct resource has replaced struct catpt_mbank
  and struct catpt_mregion. This change cascaded into:

  - catpt_mbank_size and catpt_mregion_size replaced by resource_size
  - catpt_mregion_intersects replaced by resource_overlaps
  - all catpt_mbank_ and catpt_mregion_ handlers found in loader.c
    (_request, _reserve, _release, _extract, _split, _join) have been
    removed
  - __request_region and __release_region have been enlisted in their
    place
  - catpt_mregion_intersecting renamed to catpt_resource_overlapping
  - catpt_request_region helper has been provided to deal with -size
    based requests
      o haven't found direct replacements in resource.c/ ioport.h for
      both functions

  - catpt_mbank_create and catpt_mbank_remove renamed to catpt_sram_init
    and catpt_sram_free respectively
  - catpt_sram_init now returns void instead of int and has been
    converted to simple initialized. This change ultimately cascaded
    into:
      o both SRAM banks initialization being moved to catpt_dev_init
        from catpt_acpi_probe (device.c)
      o catpt_dev::spec is now initialized first, with catpt_dev_init
        following it soon after
      o catpt_acpi_probe erroneous path has been simplified as SRAM
        banks no longer need to be freed

  - catpt_sram_free now frees all resources via child -> sibling
    enumeration rather than region_list iteration
  - catpt_dsp_update_srampge and catpt_dsp_set_srampge now accept new
    argument: unsigned long mask. Caused by removal of catpt_mbank -
    mask is taken directly from catpt_dev::spec::d/iram_mask
  - trace.h events for catpt_mbank and catpt_mregion have been removed

Diff against last drop on internal list:
- replaced spinlock with mutex for mregion allocation and release to
  address sleeping in atomic context warnings
- fixed coredump fw_hash dumping
- kcontrol values are now always stored regardless of stream of interest
  is running or not
- kcontrol values are now applied after stream is prepared instead of
  ignoring what has been set by user initially
- catpt_pdata instances have been renamed from hsw_ and bdw_ to lpt_ and
  wpt_ respectively
- reordered Makefile .o(s) (cosmetic)

Cezary Rojewski (13):
  ASoC: Intel: Add catpt device
  ASoC: Intel: catpt: Define DSP operations
  ASoC: Intel: catpt: Firmware loading and context restore
  ASoC: Intel: catpt: Implement IPC protocol
  ASoC: Intel: catpt: Add IPC messages
  ASoC: Intel: catpt: PCM operations
  ASoC: Intel: catpt: Event tracing
  ASoC: Intel: catpt: Simple sysfs attributes
  ASoC: Intel: Select catpt and deprecate haswell
  ASoC: Intel: haswell: Remove haswell-solution specific code
  ASoC: Intel: broadwell: Remove haswell-solution specific code
  ASoC: Intel: bdw-5650: Remove haswell-solution specific code
  ASoC: Intel: bdw-5677: Remove haswell-solution specific code

 sound/soc/intel/Kconfig             |   22 +-
 sound/soc/intel/Makefile            |    2 +-
 sound/soc/intel/boards/Kconfig      |    8 +-
 sound/soc/intel/boards/bdw-rt5650.c |   36 -
 sound/soc/intel/boards/bdw-rt5677.c |   33 -
 sound/soc/intel/boards/broadwell.c  |   33 -
 sound/soc/intel/boards/haswell.c    |   28 +-
 sound/soc/intel/catpt/Makefile      |    6 +
 sound/soc/intel/catpt/core.h        |  187 +++++
 sound/soc/intel/catpt/device.c      |  376 +++++++++
 sound/soc/intel/catpt/dsp.c         |  596 +++++++++++++
 sound/soc/intel/catpt/fs.c          |   79 ++
 sound/soc/intel/catpt/ipc.c         |  298 +++++++
 sound/soc/intel/catpt/loader.c      |  673 +++++++++++++++
 sound/soc/intel/catpt/messages.c    |  312 +++++++
 sound/soc/intel/catpt/messages.h    |  401 +++++++++
 sound/soc/intel/catpt/pcm.c         | 1212 +++++++++++++++++++++++++++
 sound/soc/intel/catpt/registers.h   |  191 +++++
 sound/soc/intel/catpt/trace.h       |   83 ++
 19 files changed, 4434 insertions(+), 142 deletions(-)
 create mode 100644 sound/soc/intel/catpt/Makefile
 create mode 100644 sound/soc/intel/catpt/core.h
 create mode 100644 sound/soc/intel/catpt/device.c
 create mode 100644 sound/soc/intel/catpt/dsp.c
 create mode 100644 sound/soc/intel/catpt/fs.c
 create mode 100644 sound/soc/intel/catpt/ipc.c
 create mode 100644 sound/soc/intel/catpt/loader.c
 create mode 100644 sound/soc/intel/catpt/messages.c
 create mode 100644 sound/soc/intel/catpt/messages.h
 create mode 100644 sound/soc/intel/catpt/pcm.c
 create mode 100644 sound/soc/intel/catpt/registers.h
 create mode 100644 sound/soc/intel/catpt/trace.h

Comments

Amadeusz Sławiński Aug. 13, 2020, 8:30 a.m. UTC | #1
On 8/12/2020 10:57 PM, Cezary Rojewski wrote:
> Implement support for Lynxpoint and Wildcat Point AudioDSP. Catpt
> solution deprecates existing sound/soc/intel/haswell which is removed in
> the following series. This cover-letter is followed by 'Developer's deep
> dive' message schedding light on catpt's key concepts and areas
> addressed.
> 
> Due to high range of errors and desynchronization from recommendations
> set by Windows solution, re-write came as a lower-cost solution compared
> to refactoring /haswell/ with several series of patches.
> 
> Special thanks go to Marcin Barlik and Piotr Papierkowski for sharing
> their LPT/WPT AudioDSP architecture expertise as well as helping
> backtrack its historical background.
> My thanks go to Amadeusz Slawinski for reviews and improvements proposed
> on and off the internal list. Most of internal diff below is his
> contribution.
> Krzysztof Hejmowski helped me setup my own Xtensa environment and
> recompile LPT/WPT FW binary sources what sped up the development greatly.
> 
> This would not have been possible without help from these champions,
> especially considering how quickly the catpt was written: 2 weeks
> features, 3 weeks optimizations. Thank you.
> 
> Userspace-exposed members are compatible with what is exposed by
> deprecated solution as well as FW binary being re-used thus no harm is
> done. The only visible differences are: the newly added 'Loopback Mute'
> kcontrol and volume support extending to quad from stereo.
> 
> On top of fixing erros and design flows, catpt also adds module reload,
> dynamic SRAM memory allocation during PCM runtime and exposes missing
> userspace API: 'Loopback Mute' kcontrol, quad volume controls and sysfs
> fw-version entries. Event tracing is provided to easy solution
> debugging.
> 
> Following are not included in this update and are scheduled as later
> addition:
> - fw logging
> - module (library) support
> 
> Note: LPT power up/down sequences might get aligned with WPT once enough
> testing is done as capabilities are shared for both DSPs.
> Note #2: Both LPT and WPT power up/down sequences may get optimized in
> future updates as thanks to help from the Windows team, most of nuances
> behind why/what/when in regard to hw registers have been backtracked and
> reviewed again.
> 
> Link to developer's deep dive message:
> https://www.spinics.net/lists/alsa-devel/msg113563.html
> 
> Changes in v4:
> - fixed compilation with i386 kconfig (conflicting names)
> - streamlined naming for SHIM and PCI registers to match SSP ones
>    (SHIM_REG -> SHIM)
> - catpt_component_probe removed and kcontrols again initializzed
>    statically via snd_kcontrol_new array: this is to remove
>    kctl->id.device shenanigans
> - renamed catpt_set_ctlvol to catpt_set_dspvol - function name wasn't
>    matching its purpose
> 

I see nothing more, so once again:

Reviewed-by: Amadeusz Sławiński <amadeuszx.slawinski@linux.intel.com>
Liam Girdwood Aug. 13, 2020, 4 p.m. UTC | #2
On Wed, 2020-08-12 at 22:57 +0200, Cezary Rojewski wrote:
> Implement support for Lynxpoint and Wildcat Point AudioDSP. Catpt
> 
> solution deprecates existing sound/soc/intel/haswell which is removed
> in
> 
> the following series. This cover-letter is followed by 'Developer's
> deep
> 
> dive' message schedding light on catpt's key concepts and areas
> 
> addressed.

Whilst I applaud removing the old driver I do NOT support adding yet
*another* Intel audio DSP driver. Our goal is to remove DSP drivers and
unify under one codebase (and this was discussed in Lyon last year at
the audio Miniconf).

Please take all these good improvements and add them into the SOF
driver.

Please also remember that we are adding an IPC abstraction layer into
the SOF driver so it can cope with multiple IPC versions. You are most
welcome to help in this effort.

Thanks

Liam
Cezary Rojewski Aug. 13, 2020, 6:11 p.m. UTC | #3
On 2020-08-13 6:00 PM, Liam Girdwood wrote:
> On Wed, 2020-08-12 at 22:57 +0200, Cezary Rojewski wrote:
>> Implement support for Lynxpoint and Wildcat Point AudioDSP. Catpt
>>
>> solution deprecates existing sound/soc/intel/haswell which is removed
>> in
>>
>> the following series. This cover-letter is followed by 'Developer's
>> deep
>>
>> dive' message schedding light on catpt's key concepts and areas
>>
>> addressed.
> 
> Whilst I applaud removing the old driver I do NOT support adding yet
> *another* Intel audio DSP driver. Our goal is to remove DSP drivers and
> unify under one codebase (and this was discussed in Lyon last year at
> the audio Miniconf).
> 
> Please take all these good improvements and add them into the SOF
> driver.
> 
> Please also remember that we are adding an IPC abstraction layer into
> the SOF driver so it can cope with multiple IPC versions. You are most
> welcome to help in this effort.
> 
Presented catpt is created as a solution to existing problems reported 
by clients and users for WPT platforms. It is not "yet another" DSP 
driver but an update to an existing one - due to high range of problems 
found when testing it, catpt came as a lower-cost solution and /haswell/ 
is being removed soon after. So, the status quo is maintained - single 
driver for LPT/WPT architecture.

Please don't use 'our goal' term, it's misplaced: it was agreed on 
several occasions that older DSP platforms remain with closed firmware 
and are to be supported with existing DSP drivers.
SOF FW does not support BDW and instead is tasked with support of newer 
platforms. Neither SOF FW team nor Chrome support team agreed with WPT 
being moved out of closed firmware. Please, speak with management first 
before writing statements saying otherwise.

I don't see your input for any of the patches. Internal heads-up has 
been given. No review for either internal or upstream patchsets. 
Afterall, you were the author of original /haswell/ and your input could 
have proved important in speeding the progress and yielding even better 
results to our clients.

As you've given no technical points for denying LPT/WPT improvements and 
your statement disagrees with management's decision, message shall be 
discarded and ignored for the rest of the upstream process. Further 
discussion will be taken off this list.

Mark, Takashi and others,
I'm sorry for this inconvenience, such actions do not represent One 
Intel and Truth & Transparency which Intel is committed to stand by.

Czarek
Liam Girdwood Aug. 13, 2020, 7:03 p.m. UTC | #4
On Thu, 2020-08-13 at 20:11 +0200, Cezary Rojewski wrote:
> On 2020-08-13 6:00 PM, Liam Girdwood wrote:
> > On Wed, 2020-08-12 at 22:57 +0200, Cezary Rojewski wrote:
> > > Implement support for Lynxpoint and Wildcat Point AudioDSP. Catpt
> > > 
> > > solution deprecates existing sound/soc/intel/haswell which is
> > > removed
> > > in
> > > 
> > > the following series. This cover-letter is followed by
> > > 'Developer's
> > > deep
> > > 
> > > dive' message schedding light on catpt's key concepts and areas
> > > 
> > > addressed.
> > 
> > Whilst I applaud removing the old driver I do NOT support adding
> > yet
> > *another* Intel audio DSP driver. Our goal is to remove DSP drivers
> > and
> > unify under one codebase (and this was discussed in Lyon last year
> > at
> > the audio Miniconf).
> > 
> > Please take all these good improvements and add them into the SOF
> > driver.
> > 
> > Please also remember that we are adding an IPC abstraction layer
> > into
> > the SOF driver so it can cope with multiple IPC versions. You are
> > most
> > welcome to help in this effort.
> > 
> Presented catpt is created as a solution to existing problems
> reported 
> by clients and users for WPT platforms. It is not "yet another" DSP 
> driver but an update to an existing one - due to high range of
> problems 
> found when testing it, catpt came as a lower-cost solution and
> /haswell/ 
> is being removed soon after. So, the status quo is maintained -
> single 
> driver for LPT/WPT architecture.

Its a new driver. Fix the old driver or (preferred) fix the SOF driver
so we can remove the haswell driver and have one less DSP driver to
maintain.

> 
> Please don't use 'our goal' term, it's misplaced: it was agreed on 
> several occasions that older DSP platforms remain with closed
> firmware 
> and are to be supported with existing DSP drivers.

I'm not suggesting using SOF FW, but using the existing FW with the IPC
abstraction.

> SOF FW does not support BDW and instead is tasked with support of
> newer 
> platforms. Neither SOF FW team nor Chrome support team agreed with
> WPT 
> being moved out of closed firmware. Please, speak with management
> first 
> before writing statements saying otherwise.

To be clear - I'm saying fix the SOF driver to use the old FW (not the
SOF FW). You know that we need IPC abstraction here (and for other
platforms)

> 
> I don't see your input for any of the patches. Internal heads-up has 
> been given. No review for either internal or upstream patchsets. 
> Afterall, you were the author of original /haswell/ and your input
> could 
> have proved important in speeding the progress and yielding even
> better 
> results to our clients.
> 

Please don't mistake silence for my approval. I knew that updates were
forthcoming but not a new driver.

> As you've given no technical points for denying LPT/WPT improvements
> and 
> your statement disagrees with management's decision, message shall
> be 
> discarded and ignored for the rest of the upstream process. Further 
> discussion will be taken off this list.
> 
> Mark, Takashi and others,
> I'm sorry for this inconvenience, such actions do not represent One 
> Intel and Truth & Transparency which Intel is committed to stand by.
> 

Seriously ? It's really simple for anyone to understand that
introducing a new driver introduces new bugs. It's also very well
understood that fixing or extending existing drivers is always the best
path forwards over adding another new immature driver.

I hope you understand that long term **convergence** is key for
quality, maintainability and reduced effort, if not, I'm happy have a
call.

Thanks

Liam