**** BEGIN LOGGING AT Sun Oct 16 02:59:58 2016 Oct 16 09:01:28 Hey guys, anyone tried to use McASP unit as ordinary SPI device under linux? Oct 16 09:41:50 why the fuck am i in #beagle Oct 16 10:05:47 beer goggles? Oct 16 16:01:50 overlord_tm: its output can't really be considered spi at all Oct 16 16:02:26 overlord_tm: mostly due to lack of chip select though, so I suppose it's possible if you use mcasp burst mode combined with gpio chip select Oct 16 16:04:50 never tried it myself, but it should be straightforward enough to map mcasp via uio and try it Oct 16 16:33:18 zmatt, I am writing custom driver to achieve that, but I am quite lost :D Oct 16 16:35:52 hehe Oct 16 17:13:07 If device is enabled in device tree, do I need to starts its clock manually, of is this handled by kernel somewhere? Oct 16 17:24:46 this is handled by the kernel, the ti,hwmods property associates the device with platform data Oct 16 17:54:44 device tree stuff just uses the dt driver model and bindings to the drivers Oct 16 17:55:16 obviously creating dt node is useless without a proper binding/driver Oct 16 17:59:57 if the right stuff is in place then &foo_bar {status = "okay";} should enable it Oct 16 19:05:39 nerdboy: " zmatt, I am writing custom driver" Oct 16 19:06:41 not a path I would choose personally unless absolutely necessary, but well Oct 16 19:46:56 make a DT binding for it and hook 'er up... Oct 16 23:56:59 hi, is it possible to run a vm on beaglebone Oct 16 23:57:07 qemu or vmware? Oct 17 00:04:25 Schnitzelmacher: you can always run qemu, but there's no hardware virtualization support so it'll be very slow Oct 17 00:04:37 looking to run OpenBSD Oct 17 00:04:49 nothing insane. Oct 17 00:05:03 you think qemu is best? Oct 17 00:05:10 why use a vm at all? Oct 17 00:05:30 also, if you're going to run it in a vm, why bother running it on a beaglebone instead of using beefier hardware? Oct 17 00:05:53 i got it to boot on my beagle Oct 17 00:05:54 however Oct 17 00:06:05 I cant ssh to it Oct 17 00:06:07 or serial over usb Oct 17 00:07:34 I know there are more people running openbsd on beaglebone, but it is very rare, maybe try some openbsd-related irc or mailing list to see if you can find anyone who can help Oct 17 00:07:45 personally I don't really know anything about openbsd, so :) Oct 17 00:07:50 okay Oct 17 00:07:58 there was someone here who did, kremlin, but evidently he's not here now Oct 17 00:08:41 http://openbsd-archive.7691.n7.nabble.com/armv7-introducing-tipru-4-td299789.html <-- him Oct 17 00:09:35 yea looks like I need a USB to Serial initially Oct 17 00:09:37 to setup openbsd Oct 17 00:09:58 soo I will have to use qemu til i get one Oct 17 01:42:14 zmatt: hello Oct 17 01:43:17 do you know if it is possible to capture audio on McAsp1 interface? Oct 17 01:44:31 you know you can just ask questions without addressing me specifically, I'm not your personal assistant Oct 17 01:44:47 sorry Oct 17 01:45:09 but your are the audio expert and alreday helped me to fix the audio playback ;-) Oct 17 01:46:48 and yes, audio capture and playback is what mcasp peripherals are for; the only limitation of mcasp1 is that it can only be used in slave mode (if you want to use it at sensible audio frequencies) due to inability to reach its hclk on the beaglebone Oct 17 01:47:14 well, and it doesn't support async mode, but then neither does the linux driver anyway Oct 17 01:48:59 ok Oct 17 01:49:32 in fact I am trying to use a microphone now SPH0645LM4H-B Oct 17 01:49:48 got some troubles of course... Oct 17 01:50:48 for some unexpected reason the McASP interface actally does something only if I register S16_LE in my driver Oct 17 01:51:30 uh, I know it also supports S24_LE and S32_LE Oct 17 01:51:34 (and S24_3LE) Oct 17 01:51:56 which is not supported by the microphone -> should be S24_BE or S32_BE Oct 17 01:52:11 no, the _LE refers to the memory format, not the bit order on wire Oct 17 01:53:17 ah yes I was wondering about it Oct 17 01:53:41 btw that microphone also operates in slave mode, so if you want to hook that up to mcasp1 you'll need to somehow provide clk (bclk) and fs (ws/lrck) to both mcasp1 and microphone Oct 17 01:54:05 the very odd thing is when I have a look on davinci-mcasp.c Oct 17 01:54:27 it is registering playback and capture for mcasp0 Oct 17 01:54:39 and only playback for mcasp1 Oct 17 01:54:54 uhh, that makes no sense, how did you configure it in DT ? Oct 17 01:57:30 note that you can still operate mcasp1 in master mode, but it can then only generate a clock by dividing the 24 MHz system clock, which yields very weird clock speeds Oct 17 01:57:38 http://pastebin.com/YLd1smB8 Oct 17 01:58:06 e.g. 46875 Hz sample rate Oct 17 01:58:38 it shows only capture because you configured it only for capture Oct 17 01:58:44 in serial-dir Oct 17 01:59:19 also you configured it in master mode, which will have the above-mentioned problem Oct 17 01:59:35 yes I noticed this is why I applied your comments for the codec / speaker WM8974 Oct 17 02:00:12 the McAsp is slave and output AHCLK 24MHz Oct 17 02:00:44 WM8974 is master + deviding MCLK with the PLL Oct 17 02:01:09 another thing I was wondering Oct 17 02:01:50 it is also providing the clk and fs to mcasp1 ? since if so, then you need to configure DT to make the codec master (since that's what it'll seem like from the driver's perspective) Oct 17 02:02:23 you said I can use CLKX even if McASP is slave right Oct 17 02:03:21 ok, I'm starting to lose you now... what are we talking about? how did the WM8974 enter in this conversation about the microphone, since it's clearly not part of this overlay? Oct 17 02:03:51 you always need clkx, either as input (slave mode) or output (master mode) Oct 17 02:03:54 I mean you can use CLKX or CLKR does not matter? Oct 17 02:04:05 clkr is basically never used since the linux driver doesn't support async mode Oct 17 02:04:35 ok Oct 17 02:04:47 in async mode, clkx/fsx is used for playback and clkr/fsr for capture Oct 17 02:05:06 in sync mode, clkx/fsx is used for both playback and capture Oct 17 02:11:12 ok sorry I was diverging Oct 17 02:11:48 what I see with my current device tree overlay for the microphone + the kernel driver Oct 17 02:12:35 it only does something if I register SNDRV_PCM_FMTBIT_S16_LE in my driver Oct 17 02:13:06 probably userspace is asking to record in 16-bit Oct 17 02:13:38 really there is some kludgy stuff going on there with memory format being conflated with wire format Oct 17 02:13:44 it's a mess Oct 17 02:14:06 with the logic analyser I see it can generate a frame signal as 44.2 kHz Oct 17 02:15:05 but the BCLK is FRAME / 16 *2 Oct 17 02:15:34 yes I am thinking alsa config enforce S16_LE someway Oct 17 02:15:48 S32_LE you mean Oct 17 02:16:30 there is a beagle with a suitable alsa config file for it somewhere in this building, unfortunately I have no idea where Oct 17 02:16:39 actually I'm also not sure it's in this building, hmm Oct 17 02:16:49 it's somewhere on planet earth anyhow Oct 17 02:17:03 I should find out someday Oct 17 02:17:16 it wasn't hard in retrospect Oct 17 02:17:26 I have just a default / prestine config from alsa lib Oct 17 02:17:44 usually there's no /etc/asound.conf at all Oct 17 02:18:47 but you should make your codec only support S32_LE, since the microphone requires 32 bits per slot (64 bits per frame) Oct 17 02:19:08 or, there might be a way to force it in device tree, now that I think of it Oct 17 02:19:19 no but I tried to make one th check if I could back specific settings or this audio card Oct 17 02:19:39 probably if you force it via DT you can make the codec accept anything Oct 17 02:19:42 > about alsa config / .asoundrc Oct 17 02:19:47 lemme see if I can find it Oct 17 02:20:03 (how to force the number of bits per slot via DT) Oct 17 02:20:35 speficy a format in the DT? Oct 17 02:26:46 dai-tdm-slot-width = <32>; though not sure yet where that needs to be specified Oct 17 02:28:52 ah on the simple-audio-card,codec node Oct 17 02:28:57 I think Oct 17 02:29:04 yeah Oct 17 02:29:32 along with dai-tdm-slot-num = <2>; Oct 17 02:32:15 I try but it looks very odd... Oct 17 02:32:26 ? Oct 17 02:33:17 on the simple-card,codec whereas the codec itself is slave? Oct 17 02:34:27 well the requirement is imposed by the codec Oct 17 02:35:09 maybe it should be put on the cpu node, the docs are really not very clear Oct 17 02:36:07 ok, found at least one example putting it on cpu Oct 17 02:36:12 I guess it goes there then Oct 17 02:36:40 I honestly don't understand how alsa-for-socs works, I usually just fiddle until it works Oct 17 02:38:23 (while simultaneously toying with the thought of bypassing the kernel entirely) Oct 17 02:41:48 ok on the codec side it has no effect Oct 17 02:41:54 on the cpu side Oct 17 02:42:33 it just says "Slave PCM not usable" "Broken configuration for this PCM: no configurations available" Oct 17 02:42:37 that's pretty idiotic... it should either work, or give an error if the properties aren't appropriate there Oct 17 02:42:48 yay, sounds like alsa being alsa Oct 17 02:42:53 I am very tempted to give up for now Oct 17 02:43:48 I think ALSA is forcing S16_LE even if I provide explictely another format in the command line Oct 17 02:43:55 it definitely is not Oct 17 02:44:19 I think Oct 17 02:44:37 at least part of the mess is also in the mcasp driver I think Oct 17 02:45:00 yes Oct 17 02:45:25 by the way I had to change something in there to have the speaker working Oct 17 02:46:16 I think it might need to split into a multifunction driver to allow its clock generation capabilities to be used independently of actual audio links Oct 17 02:48:06 I also have some patches, though mostly to get DIT mode working: https://github.com/dutchanddutch/bb-kernel/tree/am33x-v4.8/patches/local Oct 17 02:48:13 some of them however also apply to tdm Oct 17 02:50:06 ok I keep you posted, thnaks again Oct 17 02:58:21 geepers 100,000 parts per reel Oct 17 02:58:31 0402's on a 12" reel **** ENDING LOGGING AT Mon Oct 17 02:59:58 2016