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: 05cf2379
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 previously.
>
> This fixes hard
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 in
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 were set to previously.
>
> This
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()
> [2.540771] DEBUG_
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: CPU: 1 PID: 1 at kernel
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
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 kernel/locking/lockdep.c:2755
>>
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
> > lockdep_trace_alloc+0xf4/0x124()
> This f
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 relev
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
give
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 t
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
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 the
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
altern
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 REGCACHE_FLAT I don't get the
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 = CCSR_SSI_SR
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,
>
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
(drivers/mxc/ssi/re
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" comm
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 initializatio
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 cach
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 CCSR_S
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 any warnings:
Tested-by: Fabi
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 b/sound/soc/fsl/fsl_ssi.c
>
> Tested your patch aga
25 matches
Mail list logo
