| 00:02.49 | *** join/#openezx Fosforo (n=Fosforo@20151135116.user.veloxzone.com.br) |
| 01:56.23 | *** join/#openezx Fosforo (n=Fosforo@20151053025.user.veloxzone.com.br) |
| 05:26.27 | *** join/#openezx rettichschnidi (n=reto@129-169.203-62.cust.bluewin.ch) |
| 06:17.41 | *** join/#openezx drath_ (i=vmaster@p5B07F887.dip.t-dialin.net) |
| 06:17.52 | *** join/#openezx nooop (n=noop@219.239.105.29) |
| 06:28.59 | Hopscotch | good morning |
| 06:32.25 | *** join/#openezx THE (n=M_VIP_N@62.120.23.15) |
| 06:35.53 | *** part/#openezx VIP (n=M_VIP_N@62.120.23.15) |
| 06:48.52 | *** join/#openezx yansa_ (n=yans@host-89-230-209-7.lublin.mm.pl) |
| 07:12.01 | *** join/#openezx VIP (n=M_VIP_N@62.120.23.15) |
| 07:12.12 | *** part/#openezx VIP (n=M_VIP_N@62.120.23.15) |
| 08:20.11 | *** join/#openezx Marex (n=marex@vasut.kolej.mff.cuni.cz) |
| 11:01.56 | *** join/#openezx ao2 (n=u@2001:1418:117:0:0:0:0:1) |
| 11:15.15 | *** join/#openezx jannu (n=jannu@hoas-fe20dd00-223.dhcp.inet.fi) |
| 11:25.08 | *** join/#openezx rettichschnidi (n=reto@129-169.203-62.cust.bluewin.ch) |
| 11:45.26 | *** join/#openezx Juvenal_Antena (n=Juvenal_@189.21.62.2) |
| 11:45.30 | *** part/#openezx Juvenal_Antena (n=Juvenal_@189.21.62.2) |
| 13:45.34 | *** join/#openezx rettichschnidi (n=reto@129-169.203-62.cust.bluewin.ch) |
| 13:53.10 | *** join/#openezx yansa_ (n=yans@host-89-230-208-118.lublin.mm.pl) |
| 15:00.16 | *** join/#openezx TimRiker (n=timr@99-204-170-164.area1.spcsdns.net) |
| 15:17.40 | *** join/#openezx blkhawk- (i=blkhawk@IP-213157024141.static.heagmedianet.de) |
| 15:17.44 | *** part/#openezx blkhawk- (i=blkhawk@IP-213157024141.static.heagmedianet.de) |
| 15:41.29 | *** join/#openezx Marex (n=marex@vasut.kolej.mff.cuni.cz) |
| 17:23.58 | *** join/#openezx Dominus (n=SuN@82-170-225-106.ip.telfort.nl) |
| 18:10.15 | *** join/#openezx pH5 (n=ph5@e178200130.adsl.alicedsl.de) |
| 18:16.22 | ao2 | hi pH5, I tried to solve my issue with this code, not very clean indeed: http://rafb.net/p/5htzSw65.html |
| 18:16.42 | ao2 | an in the user code I just have a cpu_dai->dai_ops.set_fmt(cpu_dai, SND_SOC_DAIFMT_MSB_OVERRIDE); |
| 18:18.01 | pH5 | ao2: doesn't SND_SOC_DAIFMT_MSB work? |
| 18:18.19 | pH5 | to me it looks like all you do is set SSCR0_EDSS | SSCR0_TISSP | SSCR0_DataSize(16) into SSCR0 |
| 18:18.51 | ao2 | the problems are the other settings, if I use your code the other port settings are reset |
| 18:19.23 | pH5 | __raw_writel(SSCR0_EDSS | SSCR0_TISSP | SSCR0_DataSize(16), mmio_base + SSCR0); |
| 18:19.41 | pH5 | this is two lines after the FIXME comment I told you about |
| 18:19.46 | pH5 | looks exactly the same to me |
| 18:20.06 | pH5 | or is the SSCR0 &= ~SSCR0_DSS the important bit? |
| 18:20.35 | pH5 | shouldn't be, because pxa2xx_ssp_set_dai_fmt starts out with writing 0 to SSCR0 |
| 18:22.30 | pH5 | ao2: what exactly happens when you just remove your patch and use SND_SOC_DAIFMT_MSB instead of _OVERRIDE? |
| 18:23.52 | ao2 | buzzy sound, that because SSCR1 and SSPSP are zeroed as well, and just using SND_SOC_DAIFMT_MSB does not set them again to the right values |
| 18:24.35 | ao2 | so I have to find the right format settings, just using SND_SOC_DAIFMT_MSB alone can't work without my dirty hack |
| 18:24.59 | pH5 | ah, now I understand why it works :) |
| 18:26.05 | pH5 | it'd be great if you could check out the correct SSCR1 and SSPSP settings and then we can see how they could be generated in pxa2xx_ssp_set_dai_fmt |
| 18:31.51 | ao2 | let's see if I get to something cleaner |
| 20:04.02 | *** join/#openezx flo_lap (n=fuchs@dslb-088-073-016-203.pools.arcor-ip.net) |
| 20:59.05 | ao2 | pH5, it looks like the problem is that I need fmt = (... | SND_SOC_DAIFMT_DSP_B | SND_SOC_DAIFMT_MSB) but the SND_SOC_DAIFMT_* constants are supposed to be mutually exclusive (they are defined as increasing numbers) |
| 21:00.22 | ao2 | should we redefine them as non overlapping constants and turn the code to detect them with logical operator rather than equality? |
| 21:13.31 | pH5 | so the only wrong part when you set DAIFMT_MSB are the SSPSP_SCMODE bits? |
| 21:19.17 | pH5 | hm, certainly there's more to it SSPSP is ignored if you're not in PSP mode |
| 21:19.47 | pH5 | so setting the frame format to TISSP in SSCR0 seems to be wrong? |
| 21:20.04 | pH5 | ao2: are the correct register values (SSCR0, SSCR1 and SSPSP) documented somewhere? |
| 21:28.44 | ao2 | pH5, for the latest question, I don't know |
| 21:29.37 | pH5 | ao2: you could use your early-return patch and printk the current values for the working case |
| 21:30.43 | ao2 | sure |
| 21:30.48 | pH5 | I think the wolfson people defined the dai formats as exclusive for a reason, so you should rather add a new format than change them to a bitfield (MSB | I2S wouldn't make much sense) |
| 21:31.31 | pH5 | if it is needed at all, but I can't say anything about that without knowing the settings. |
| 21:45.04 | ao2 | these are the values I get with a working config: |
| 21:45.05 | ao2 | <7>pxa2xx_ssp_set_dai_fmt: sscr0: 0x0010007f |
| 21:45.06 | ao2 | <7>pxa2xx_ssp_set_dai_fmt: sscr1: 0x43c03400 |
| 21:45.06 | ao2 | <7>pxa2xx_ssp_set_dai_fmt: sspsp: 0x00000002 |
| 21:56.56 | *** join/#openezx shoragan (n=shoragan@debian/developer/shoragan) |
| 21:58.24 | ao2 | ok, gotta go, will try something else tomorrow. Thanks pH5. Bye. |
| 23:20.49 | *** join/#openezx flyhorse|linux (n=flyhorse@219.130.57.234) |