Re: [PATCH 3/3] ASoC: fsl_ssi: remove register defaults

Hi Maciej, On Sun, Jan 17, 2016 at 8:02 PM, Maciej S. Szmigiero wrote: > Patch updated according to Timur's suggestions (needs regmap fix): > diff --git a/sound/soc/fsl/fsl_ssi.c b/sound/soc/fsl/fsl_ssi.c Tested your patch against linux-next and it did not give me

Re: [PATCH 3/3] ASoC: fsl_ssi: remove register defaults

Hi Fabio, On 18.01.2016 13:51, Fabio Estevam wrote: > Hi Maciej, > > On Sun, Jan 17, 2016 at 8:02 PM, Maciej S. Szmigiero > wrote: > >> Patch updated according to Timur's suggestions (needs regmap fix): >> diff --git a/sound/soc/fsl/fsl_ssi.c

Re: [PATCH 3/3] ASoC: fsl_ssi: remove register defaults

On 17.01.2016 19:38, Timur Tabi wrote: > Maciej S. Szmigiero wrote: >> On 17.01.2016 15:16, Maciej S. Szmigiero wrote: >>> On 17.01.2016 06:16, Timur Tabi wrote: Maciej S. Szmigiero wrote: > This is because (at least according to the datasheet) imx21-class SSI > registers end at

Re: [PATCH 3/3] ASoC: fsl_ssi: remove register defaults

Maciej S. Szmigiero wrote: On 17.01.2016 15:16, Maciej S. Szmigiero wrote: On 17.01.2016 06:16, Timur Tabi wrote: Maciej S. Szmigiero wrote: This is because (at least according to the datasheet) imx21-class SSI registers end at CCSR_SSI_SRMSK (no SACC{ST,EN,DIS} regs), so reading them for

Re: [PATCH 3/3] ASoC: fsl_ssi: remove register defaults

On 17.01.2016 06:16, Timur Tabi wrote: > Maciej S. Szmigiero wrote: >> This is because (at least according to the datasheet) imx21-class SSI >> registers end at CCSR_SSI_SRMSK (no SACC{ST,EN,DIS} regs), so >> reading them for cache initialization may not be safe. >> >> Also, a "MXC 91221 only"

Re: [PATCH 3/3] ASoC: fsl_ssi: remove register defaults

On 17.01.2016 15:16, Maciej S. Szmigiero wrote: > On 17.01.2016 06:16, Timur Tabi wrote: >> Maciej S. Szmigiero wrote: >>> This is because (at least according to the datasheet) imx21-class SSI >>> registers end at CCSR_SSI_SRMSK (no SACC{ST,EN,DIS} regs), so >>> reading them for cache

Re: [PATCH 3/3] ASoC: fsl_ssi: remove register defaults

Maciej S. Szmigiero wrote: +static const struct regmap_config fsl_ssi_regconfig_imx21 = { + .max_register = CCSR_SSI_SRMSK, + .reg_bits = 32, + .val_bits = 32, + .reg_stride = 4, + .val_format_endian = REGMAP_ENDIAN_NATIVE, + .num_reg_defaults_raw =

Re: [PATCH 3/3] ASoC: fsl_ssi: remove register defaults

Hi Fabio, On 11.01.2016 15:05, Fabio Estevam wrote: > Hi Maciej, > > On Mon, Jan 11, 2016 at 11:57 AM, Maciej S. Szmigiero > wrote: >> Hi Fabio, > >> This will disable register cache so it isn't right. >> Could you try REGCACHE_FLAT instead, please? > > Yes, with

Re: [PATCH 3/3] ASoC: fsl_ssi: remove register defaults

On 17.01.2016 01:10, Timur Tabi wrote: > Maciej S. Szmigiero wrote: >> +static const struct regmap_config fsl_ssi_regconfig_imx21 = { >> +.max_register = CCSR_SSI_SRMSK, >> +.reg_bits = 32, >> +.val_bits = 32, >> +.reg_stride = 4, >> +.val_format_endian = REGMAP_ENDIAN_NATIVE,

Re: [PATCH 3/3] ASoC: fsl_ssi: remove register defaults

Maciej S. Szmigiero wrote: This is because (at least according to the datasheet) imx21-class SSI registers end at CCSR_SSI_SRMSK (no SACC{ST,EN,DIS} regs), so reading them for cache initialization may not be safe. Also, a "MXC 91221 only" comment before these regs in FSL tree

Re: [PATCH 3/3] ASoC: fsl_ssi: remove register defaults

On Mon, Jan 11, 2016 at 07:23:54PM -0600, Timur Tabi wrote: > Mark Brown wrote: > >regcache handles this fine, it's perfectly happy to just go and allocate > >the cache as registers get used (this is why the code that's doing the > >allocation exists...). What is causing problems here is that

Re: [PATCH 3/3] ASoC: fsl_ssi: remove register defaults

Mark Brown wrote: regcache handles this fine, it's perfectly happy to just go and allocate the cache as registers get used (this is why the code that's doing the allocation exists...). What is causing problems here is that the first access to the register is happening in interrupt context so we

Re: [PATCH 3/3] ASoC: fsl_ssi: remove register defaults

Mark Brown wrote: Quite possibly (it'll be more efficient and it's intended for such use cases) but as I said in my other reply that then has the issue that it implicitly gives default values to all the registers so I'd expect we still need to handle the cache initialisation explicitly (or

Re: [PATCH 3/3] ASoC: fsl_ssi: remove register defaults

Hi Fabio, Thanks for testing. On 11.01.2016 13:10, Fabio Estevam wrote: > On Mon, Jan 11, 2016 at 10:04 AM, Fabio Estevam wrote: > >> This patch causes the following issue in linux-next: >> >> [2.526984] [ cut here ] >> [2.531632] WARNING:

Re: [PATCH 3/3] ASoC: fsl_ssi: remove register defaults

Hi Maciej, On Sun, Dec 20, 2015 at 6:33 PM, Maciej S. Szmigiero wrote: > There is no guarantee that on fsl_ssi module load > SSI registers will have their power-on-reset values. > > In fact, if the driver is reloaded the values in > registers will be whatever they

Re: [PATCH 3/3] ASoC: fsl_ssi: remove register defaults

On 11.01.2016 15:00, Mark Brown wrote: > On Mon, Jan 11, 2016 at 10:10:56AM -0200, Fabio Estevam wrote: >> On Mon, Jan 11, 2016 at 10:04 AM, Fabio Estevam wrote: > >>> [2.526984] [ cut here ] >>> [2.531632] WARNING: CPU: 1 PID: 1 at

Re: [PATCH 3/3] ASoC: fsl_ssi: remove register defaults

On Mon, Jan 11, 2016 at 10:04 AM, Fabio Estevam wrote: > This patch causes the following issue in linux-next: > > [2.526984] [ cut here ] > [2.531632] WARNING: CPU: 1 PID: 1 at kernel/locking/lockdep.c:2755 > lockdep_trace_alloc+0xf4/0x124() >

Re: [PATCH 3/3] ASoC: fsl_ssi: remove register defaults

Hi Maciej, On Mon, Jan 11, 2016 at 11:57 AM, Maciej S. Szmigiero wrote: > Hi Fabio, > This will disable register cache so it isn't right. > Could you try REGCACHE_FLAT instead, please? Yes, with REGCACHE_FLAT I don't get the warning. Regards, Fabio Estevam

Re: [PATCH 3/3] ASoC: fsl_ssi: remove register defaults

On Mon, Jan 11, 2016 at 09:45:37AM -0600, Timur Tabi wrote: > Ok, I'm confused. Granted, all of this regcache stuff was added after I > stopped working on this driver, so I'm out of the loop. But it appears that > the regcache cannot properly handle an uninitialized cache. I would expect > it

Re: [PATCH 3/3] ASoC: fsl_ssi: remove register defaults

On Mon, Jan 11, 2016 at 10:10:56AM -0200, Fabio Estevam wrote: > On Mon, Jan 11, 2016 at 10:04 AM, Fabio Estevam wrote: > > [2.526984] [ cut here ] > > [2.531632] WARNING: CPU: 1 PID: 1 at kernel/locking/lockdep.c:2755 > >

Re: [PATCH 3/3] ASoC: fsl_ssi: remove register defaults

On Mon, Jan 11, 2016 at 03:10:20PM +0100, Maciej S. Szmigiero wrote: > On 11.01.2016 15:00, Mark Brown wrote: > > I suspect not, it looks like the driver is using the cache for > > suspend/resume handling. I've dropped the patch for now. Either the > > driver should explicitly write to the

Re: [PATCH 3/3] ASoC: fsl_ssi: remove register defaults

Mark Brown wrote: That's possibly problematic because the flat cache will of necessity end up with defaults (of 0 from the kzalloc()) for all the registers. You'll still have default values in the cache, though some of the behaviour around optimising syncs does change without them explicitly

Re: [PATCH 3/3] ASoC: fsl_ssi: remove register defaults

Maciej S. Szmigiero wrote: There is no guarantee that on fsl_ssi module load SSI registers will have their power-on-reset values. In fact, if the driver is reloaded the values in registers will be whatever they were set to previously. This fixes hard lockup on fsl_ssi module reload, at least

Re: [PATCH 3/3] ASoC: fsl_ssi: remove register defaults

On Sun, Dec 20, 2015 at 6:33 PM, Maciej S. Szmigiero wrote: > There is no guarantee that on fsl_ssi module load > SSI registers will have their power-on-reset values. > > In fact, if the driver is reloaded the values in > registers will be whatever they were set to

[PATCH 3/3] ASoC: fsl_ssi: remove register defaults

There is no guarantee that on fsl_ssi module load SSI registers will have their power-on-reset values. In fact, if the driver is reloaded the values in registers will be whatever they were set to previously. This fixes hard lockup on fsl_ssi module reload, at least in AC'97 mode. Fixes: