On Wed, Sep 04, 2024 at 13:47:00PM +0000, Simon Trimmer wrote: > On Wed, Sep 04, 2024 at 12:25:00PM +0000, Mark Brown wrote: > > On Wed, Sep 04, 2024 at 12:07:00PM +0000, Simon Trimmer wrote: > > > The IRQ handling in the cs35l56 driver was purely informational. It was > > > not necessary to support the HDA or ASoC driver functionality and added > > > unnecessary complexity to the drivers. > > > > > > As the IRQ signal GPIO line could be connected and shared with other > > > components the handling is replaced with a regmap patch to ensure the > > > cs35l56 IRQ sources are masked and will not generate interrupts that go > > > unhandled. > > > > Given that the code is there now and has been since the driver was > > introduced about 18 months ago what's the ongoing cost of having it? > > The information it's providing is notification of hardware faults, > > reporting those does seem useful. > > Originally we were expecting to use the IRQ mechanism for an event logging > stream that would function in a similar manner to compressed streams to be > able to get an information feed for debug and tuning tools, but those were > never created and the logging infrastructure not implemented. > > It's quite a spread of code and a lot of complexity in the regular execution > paths managing them / synchronizing the contexts, there is more going on in > the SoundWire bus variant compared to the conventional i2c/spi that it is > hard to justify maintaining it all for a couple of log messages - in the > event that someone did encounter the two situations being reported the > regmap dump would point us to the cause pretty quickly. Hi Mark and Takashi, Hold off merging this one - we should think about it a bit more and people are off on PTO. -Simon
