Re: ASoC: pxa: possible regressions

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi Petr,

On Wednesday, August 08, 2018 11:07 AM, Petr Cvek wrote:
Dne 8.8.2018 v 07:38 Daniel Mack napsal(a):

I was planning to send patches before I've found regressions in the
current -next.

I think I've had the first working version somewhere around 3.13, but I
was updating versions only sporadically and fixing audio had low
priority (higher priority got iwmmxt compiler, platform init source
code, charger, USB, MMC and IrDA). Some versions until now worked, some
didn't.

The last version I've used and where the sound worked was
4.14.0-rc7-next from somewhere around 3rd November 2017. The patch for
sound subsystem should be the same as the current one.

That's strange, because as I said, the SSP rework went in in 4.0, so without my regression fix (737e370a57e4e8 "ASoC: pxa-ssp: allow more flexible setup order"), I doubt SSP had worked for you.

3) setup fails

Recent changes in ASoC PXA DMA are causing a fail of a condition in
pxa_ssp_hw_params():

     if ((sscr0 & SSCR0_MOD) && !ttsa) {

What are the values of sscr0 and ttsa in your case? Can you cross-check
that with a kernel that doesn't have my recent changes?


-> full values in the attached log (the flag is set in the switch case
and ttsa is zeroed)

On 4.14 (not sure, if it is the correct SSP controller)

Hmm, why shouldn't it be the correct one? And do you hear sound with that 4.14 setup?


Idle:

SSCR0:
	# devmem 0x41000000 32
	0x4000003F <- 31 bit is SSCR0_MOD
SSCR1:
	# devmem 0x41000004 32
	0x00C01D80
SSTSA:
	# devmem 0x41000030 32
	0x00000000 <- is "ttsa" variable
SSRSA:
	# devmem 0x41000034 32
	0x00000000
SSTSS:
	# devmem 0x41000038 32
	0x00000000

Playing noise:

SSCR0:
	# devmem 0x41000000 32
	0x400000BF <- 31 bit is SSCR0_MOD
SSCR1:
	# devmem 0x41000004 32
	0x00E01D80
SSTSA:
	# devmem 0x41000030 32
	0x00000000 <- is "ttsa" variable
SSRSA:
	# devmem 0x41000034 32
	0x00000000
SSTSS:
	# devmem 0x41000038 32
	0x00000000

.. so the time slots are correctly disabled.

The idea was to compare a working against a non-working setup to spot the differences in the register settings.

If recent mainline versions have worked for you (modulo some minor modifications), I think one good way forward could be to bisect the problems and make the platform work for 4.18 again. Then, see if any of the recent ASoC/DMA related PXA patches break it again.

Sorry for the trouble, but without hardware, these things are hard to reproduce on my side.


Let me know if I can help further, but not that my resources are a bit limited in the next weeks.


Thanks,
Daniel

_______________________________________________
Alsa-devel mailing list
Alsa-devel@xxxxxxxxxxxxxxxx
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel




[Index of Archives]     [ALSA User]     [Linux Audio Users]     [Kernel Archive]     [Asterisk PBX]     [Photo Sharing]     [Linux Sound]     [Video 4 Linux]     [Gimp]     [Yosemite News]

  Powered by Linux