**** BEGIN LOGGING AT Sat Dec 29 02:59:58 2018
Dec 29 03:12:26 <suprothunderbolt> any idea what the oscillator clock output on the i2s pin should look like voltage wise? It doesn't look like a digital signal to me and the voltage is quite low...
Dec 29 03:13:31 <zmatt> all digital i/o is 3.3v
Dec 29 03:14:18 <zmatt> are you using it with a custom dt overlay or simply as part of the hdmi audio output?
Dec 29 03:14:29 <suprothunderbolt> mmm.... this 100% isn't
Dec 29 03:16:23 <zmatt> since in the former case, it's easy to make a mistake that causes the pin on the am335x to be configured as output and create a drive conflict
Dec 29 03:19:50 <suprothunderbolt> custom overlay
Dec 29 03:20:28 <suprothunderbolt> though I'm not sure how it should be correctly configured, there is a signal there but it's low voltage and quite analog looking...
Dec 29 03:20:40 <suprothunderbolt> it's pulses though
Dec 29 03:21:11 <zmatt> a 24 MHz clock and a 24.576 MHz clock being driven onto the same pad by two different ICs is a great way to produce an utter mess of a signal
Dec 29 03:21:22 <zmatt> it's also a great way to damage one or both of the ICs
Dec 29 03:24:33 <zmatt> make sure you don't use the "system-clock-direction-out" property nor the "mclk-fs" property
Dec 29 03:25:23 <zmatt> see https://pastebin.com/VmHHXagD
Dec 29 03:26:42 <set_> is the bb-beaglebone-io-installer from this npmjs page: https://www.npmjs.com/package/beaglebone-io?
Dec 29 03:29:46 <zmatt> it appears to be a debian wrapper for installing that npm package
Dec 29 03:30:01 <suprothunderbolt> zmatt: If I enable the gpio1_27 with enable-gpios = <&gpio1 27 0>; will that be an issue?
Dec 29 03:31:09 <set_> Okay.
Dec 29 03:32:50 <suprothunderbolt> basically I'm trying to get the crystals signal to the codec as the master clock
Dec 29 03:32:52 <zmatt> suprothunderbolt: that enables the audio oscillator clock, which is one of the two parties of the drive conflict (the other being the pin of the am335x)
Dec 29 03:33:28 <zmatt> assuming a drive conflict is the reason for the problem you're seeing
Dec 29 03:33:47 <zmatt> if the codec is connected, be sure to try it without having the codec connected to exclude it being the cause
Dec 29 03:33:54 <zmatt> what does your DT fragment look like?
Dec 29 03:35:03 <suprothunderbolt> if the codec is disconnected and I force the audio oscillator on I should still see something on that pin then?
Dec 29 03:35:59 <zmatt> my DT example supports both mcasp0 in master and in slave mode (depending on whether AUDIO_MASTER is defined or not), and either the on-board oscillator or an external master clock (depending on what audio_osc_ck points to)
Dec 29 03:37:01 <suprothunderbolt> zmatt: here's the full dts: https://paste.debian.net/1057858/
Dec 29 03:38:08 <suprothunderbolt> the PCM3168 codec doesn't appear to I2C until it's got a certain number of master clock cycles,
Dec 29 03:38:08 <zmatt> okay, so it looks like it isn't a drive conflict between the cpu and the audio osc
Dec 29 03:38:19 <zmatt> lol
Dec 29 03:38:28 <suprothunderbolt> so currently I can't see it on i2c.
Dec 29 03:38:51 <suprothunderbolt> but I'm not sure if that's because if it's not found it isn't enabled...
Dec 29 03:39:16 <suprothunderbolt> or if I've soldered / layed out the board wrong
Dec 29 03:39:37 <zmatt> disconnect the codec, check the audio master clock signal again on the beaglebone side
Dec 29 03:39:57 <zmatt> (while the audio osc is forced-on)
Dec 29 03:40:37 <suprothunderbolt> okay, so if nothing is connected and that dts is loaded then the audio osc should be present on p9.25?
Dec 29 03:41:08 <suprothunderbolt> by forced-on I'm not sure how to do that, other than specify something with gpio1_27 in the DTS
Dec 29 03:46:21 <zmatt> yeah you can just make the gpio user-controllable like this: https://pastebin.com/Jdz5Lzxk  (this will also enable the gpio by default) and replace the contents of the clk_mcasp0 node with that of the clk_mcasp0_fixed node
Dec 29 03:47:04 <zmatt> (or put the clk_mcasp0: label on the clk_mcasp0_fixed node)
Dec 29 03:48:25 <zmatt> oh sorry, ACTIVE_HIGH in my dt snippet should be GPIO_ACTIVE_HIGH
Dec 29 03:56:07 <suprothunderbolt> should i still specify the mode of that pin in the pinmux section or does this cover that too?
Dec 29 03:57:15 <zmatt> you can attach it to the gpio-of-helper node instead.  it's not terribly important though, since all pins default to gpio mode
Dec 29 04:04:07 <suprothunderbolt> zmatt: !!!
Dec 29 04:04:26 <suprothunderbolt> that has enabled the clock on that pin where as previously my enable-thing didn't
Dec 29 04:04:34 <suprothunderbolt> and now the codec comes up on i2c
Dec 29 04:05:06 <suprothunderbolt> so i just wasn't enabling the oscillator correctly...
Dec 29 04:09:35 <set_> https://pastebin.com/Zgkcp1gJ has this idea: donkey$ source <some_file>. What does source mean or where can I get it?
Dec 29 04:10:44 <set_> my bbb/debian machine does not compute this source idea.
Dec 29 04:13:24 <set_> Does <some_file> in "donkey$ source <some_file> need to be a .sh file only?
Dec 29 04:13:56 <zmatt> well the instructions are telling you to source that gpio_setup.sh file specifically
Dec 29 04:13:59 <zmatt> whatever it might be
Dec 29 04:14:28 <set_> Okay. I get that part. I tried and then I tried to apt install source. I am missing something I know nothing about.
Dec 29 04:14:30 <zmatt> and yes you use "source" on files containing shell commands.  it basically acts like you typed in the commands that are in that file
Dec 29 04:14:39 <set_> Oh. Okay.
Dec 29 04:14:40 <zmatt> source is a built-in shell command
Dec 29 04:14:46 <set_> I got it now. Aw!
Dec 29 04:14:56 <zmatt> what error were you getting?
Dec 29 04:15:07 <suprothunderbolt> so my codec still isn't loading in alsa but this is progress! :)
Dec 29 04:15:10 <set_> Hold on, let me check.
Dec 29 04:15:34 <zmatt> suprothunderbolt: hmm?
Dec 29 04:16:29 <suprothunderbolt> zmatt: it appears now when I do i2cdetect
Dec 29 04:16:45 <suprothunderbolt> but it isn't actually loading / working yet
Dec 29 04:17:27 <zmatt> "now" as in when you force-enable the clock?
Dec 29 04:17:59 <suprothunderbolt> yes
Dec 29 04:18:02 <zmatt> so whatever you were seeing previously on the master clock pin was just noise pickup?
Dec 29 04:18:07 <suprothunderbolt> yes
Dec 29 04:18:13 <zmatt> and the kernel driver is buggy
Dec 29 04:18:43 <suprothunderbolt> that why I was suprised it looked really noise and low voltage, it had a period but then I noticed other pins did too... it was just noise from the power supply
Dec 29 04:18:53 <zmatt> or your dt declaration for the codec is wrong
Dec 29 04:20:02 <zmatt> hmm, the driver does enable the "scki" clock at the start of its probe function
Dec 29 04:20:55 <suprothunderbolt> oh so it should find it without the forcing?
Dec 29 04:21:53 <zmatt> yeah the master clock should be enabled automatically, and remain active as long as the driver is attached to the device
Dec 29 04:22:39 <zmatt> hmm, or maybe it's also disabled if the audio port is idle
Dec 29 04:23:04 <zmatt> but it should be enabled during initialization and when in use regardless
Dec 29 04:23:34 <zmatt> did you check kernel log for errors?
Dec 29 04:23:46 <zmatt> the fact that you can use i2cdetect to find the device is a bad sign
Dec 29 04:23:49 <suprothunderbolt> which log should they appear in? syslog?
Dec 29 04:23:55 <suprothunderbolt> oh?
Dec 29 04:24:10 <zmatt> if a kernel driver is attached to a device, i2cdetect will normally skip it
Dec 29 04:24:25 <zmatt> so this suggests the driver failed to attach to it
Dec 29 04:24:44 <zmatt> you can view kernel log with "dmesg" or "journalctl -k -b"
Dec 29 04:24:50 <suprothunderbolt> oh! So maybe earlier I assumed it wasn't be detected when it was
Dec 29 04:25:06 <zmatt> i2cdetect clearly marks devices that are skipped
Dec 29 04:25:32 <suprothunderbolt> ahh okay with UU?
Dec 29 04:25:34 <zmatt> yes
Dec 29 04:25:37 <suprothunderbolt> it wasn't being skipped then
Dec 29 04:26:04 <zmatt> i.e. no kernel driver, either because it wasn't loaded or because probe failed
Dec 29 04:26:12 <zmatt> if probe failed, there should be an error in the kernel log
Dec 29 04:26:19 <suprothunderbolt> the module for the codec isn't being loaded at the moment
Dec 29 04:26:29 <suprothunderbolt>  mean, it isn't showing up in lsmod
Dec 29 04:26:36 <zmatt> that's not a good sign
Dec 29 04:26:54 <set_> Hey!
Dec 29 04:27:39 <zmatt> suprothunderbolt: that's weird
Dec 29 04:28:07 <suprothunderbolt> I searched in dmesg for alsa, snd and pcm and no hits
Dec 29 04:28:09 <zmatt> oh
Dec 29 04:28:16 <zmatt> $ grep PCM3168 /boot/config-4.14.49-ti-r54
Dec 29 04:28:16 <zmatt> # CONFIG_SND_SOC_PCM3168A_I2C is not set
Dec 29 04:28:30 <zmatt> that doesn't help
Dec 29 04:28:56 <zmatt> maybe ask rcn to include the kernel module for it in his kernels
Dec 29 04:29:16 <suprothunderbolt> I compiled the kernel myself.
Dec 29 04:29:41 <zmatt> did you compile the driver as module or as built-in?
Dec 29 04:30:14 <suprothunderbolt> modue.... oh I think I might have done something stupid.
Dec 29 04:30:14 <zmatt> (CONFIG_SND_SOC_PCM3168A_I2C=m vs CONFIG_SND_SOC_PCM3168A_I2C=y)
Dec 29 04:30:23 <suprothunderbolt> This might all be because I've done something stupid ;)
Dec 29 04:30:23 <zmatt> namely?
Dec 29 04:30:57 <suprothunderbolt> I think I might have copied the wrong kernel debs across...
Dec 29 04:31:20 <suprothunderbolt> because when I just ran grep PCM3168 /boot/config-4 it said not set...
Dec 29 04:31:38 <suprothunderbolt> which would make a lot of sense why it wasn't finding it... arg!
Dec 29 04:33:31 <suprothunderbolt> so the clock probably was correct before and doesn't need to be forced on?
Dec 29 04:33:44 <zmatt> probably
Dec 29 04:33:49 <suprothunderbolt> I assumed given it wasn't in i2cdetect it wasn't working :)
Dec 29 04:36:26 <suprothunderbolt> is there any downside to leaving clocks forced on like that?
Dec 29 04:54:31 <zmatt> not really. slightly more power consumption
Dec 29 04:54:35 <set_> I am stuck in translation right now. usleep in a .c file means what? I cannot find anything relating to usleep in my book on C programming.
Dec 29 04:54:47 <zmatt> set_: man usleep
Dec 29 04:54:52 <set_> Good idea!
Dec 29 05:06:54 <set_> The damn book fell shy of usleep. Sheesh.
Dec 29 05:14:58 <set_> zmatt: Will you please look at line 53 at https://github.com/MarkAYoder/PRUCookbook/blob/master/docs/01case/code/servo-test.c?
Dec 29 05:15:14 <set_> I had an idea on what to do but I have failed so far. I am receiving errors.
Dec 29 05:16:40 <set_> forget it. i will move on. It is too much for this hour.
Dec 29 05:16:47 <set_> I need to rest soon.
Dec 29 05:36:33 <suprothunderbolt> mmm now the module is loading! :) and I'm getting pcm3168a 2-0044: ASoC: Failed to set DAI format: -22 :)
Dec 29 05:40:22 <zmatt> btw, your code calls it simply "pcm3168" but TI includes the "a" in the part number with such a high degree of consistency (including even in the name of the evm) that I suspect the "pcm3168" is actually a discontinued older chip :P  (I've seen that before with a different part)
Dec 29 05:41:14 <suprothunderbolt> compatible = "ti,pcm3168a";
Dec 29 05:41:21 <zmatt> yeah it's in the driver name too
Dec 29 05:41:26 <suprothunderbolt> oh yeah mean in my name for the module... yeah
Dec 29 05:42:19 <suprothunderbolt> I'm running a pcm3168a. I quite catchy name by TI codec standards :)
Dec 29 05:44:09 <zmatt> the error is probably due to "frame-inversion;"  it doesn't seem the codec supports it (or at least the driver doesn't)
Dec 29 05:45:14 <suprothunderbolt> oh! I copied that part from an example using this chip with a different CPU, so I assumed the dac and ADC parts of the chip had something flipped
Dec 29 05:46:17 <zmatt> that's odd
Dec 29 05:47:55 <zmatt> https://github.com/beagleboard/linux/blob/4.14.79-ti-r86/sound/soc/codecs/pcm3168a.c#L357-L362
Dec 29 05:48:36 <zmatt> this seems to imply it doesn't support inverting the frame clock or bit clock, and this part of the function is used for both the adc and dac functions
Dec 29 05:49:10 <zmatt> frame sync I mean
Dec 29 05:49:21 <zmatt> (NB NF = normal bitclock, normal frame sync)
Dec 29 05:50:21 <suprothunderbolt> yeah, and I'm not getting the other logging so it's not "unsupported dai format" above that
Dec 29 05:50:29 <zmatt> indeed
Dec 29 05:50:54 <zmatt> and -22 == -EINVAL
Dec 29 05:50:55 <suprothunderbolt> guess I'll just disable that... I only enabled it because it was in the other example
Dec 29 05:51:14 <suprothunderbolt> the joys of not understanding things you cut and paste...
Dec 29 05:52:17 <zmatt> see https://www.kernel.org/doc/Documentation/devicetree/bindings/sound/simple-card.txt
Dec 29 05:52:38 <zmatt> although I guess that the descriptions there are not very detailed
Dec 29 05:52:54 <suprothunderbolt> yeah, and then you have to check what the board actually needs
Dec 29 05:56:36 <suprothunderbolt> that error is gone after I change that
Dec 29 05:57:19 <suprothunderbolt> asoc-simple-card sound: ASoC: no DMI vendor name! is the only negative sounding logging, and that sounds okay...
Dec 29 05:59:03 <zmatt> that sounds weird, I don't think I've ever seen that
Dec 29 06:01:35 <suprothunderbolt> oh I think things are somewhat working. I don't have anything in alsa mixer, but i'm not sure what this codec actually has in the way of mixer anyway.
Dec 29 06:01:42 <zmatt> it's dependent on CONFIG_DMI, why do you have that set?
Dec 29 06:01:44 <suprothunderbolt> and arecord hw:0,0 doesn't work
Dec 29 06:02:03 <suprothunderbolt> zmatt: I don't even know what that is :)
Dec 29 06:02:20 <zmatt> a pc bios thing
Dec 29 06:03:08 <suprothunderbolt> oh... I might have accidently turned that option on in my kernel build?
Dec 29 06:03:56 <suprothunderbolt> or it is enabled automatically by the pcm3168a module?
Dec 29 06:04:33 <zmatt> no, it's not related to that driver at all
Dec 29 06:04:50 <zmatt> basically it's an alternative to DT, when booting using UEFI
Dec 29 06:05:18 <zmatt> so really not relevant I'd say
Dec 29 06:05:46 <zmatt> oh, rcn has it enabled in its -ti kernels too, so it's not your fault
Dec 29 06:05:49 <zmatt> weird
Dec 29 06:06:23 <zmatt> anyway, that's generating that warning in ASoC, but you can ignore it
Dec 29 06:14:42 <suprothunderbolt> arecord is letting me record stuff
Dec 29 06:14:54 <suprothunderbolt> it doesn't seem to work yet but that's progress!
Dec 29 06:15:24 <suprothunderbolt> alsamixer doesn't work which I'm a little surprised about
Dec 29 06:15:54 <zmatt> well the card should show up, but it probably won't have any controls
Dec 29 06:16:02 <zmatt> or maybe it does, dunno, I'd need to check the driver
Dec 29 06:16:54 <suprothunderbolt> cannot load mixer controls: Device or resource busy
Dec 29 06:17:04 <zmatt> okay that's weird
Dec 29 06:17:10 <zmatt> never seen that
Dec 29 06:17:11 <suprothunderbolt> so not sure if the driver just doesn't expose any
Dec 29 06:17:15 <suprothunderbolt> :D
Dec 29 06:17:30 <suprothunderbolt> btw zmatt, as always, thanks for your help
Dec 29 06:19:02 <zmatt> your widget routing looks wrong
Dec 29 06:19:16 <zmatt> maybe that's the cause
Dec 29 06:19:52 <suprothunderbolt> ahh... In my wisdom I just copied that from the blog post about it...
Dec 29 06:21:02 <zmatt> if I remember right, each route is a (destination, source) pair, so for inputs you currently have those the wrong way around
Dec 29 06:21:04 <suprothunderbolt> should they all line up to names specified by the codec driver?
Dec 29 06:21:11 <suprothunderbolt> ahh okay
Dec 29 06:21:38 <zmatt> i.e. the microphone "Channel1in" is connected to the codec input "AIN1L"
Dec 29 06:23:49 <zmatt> see here for the list of widgets declared by the codec: https://github.com/beagleboard/linux/blob/4.14.79-ti-r86/sound/soc/codecs/pcm3168a.c#L200-L232
Dec 29 06:24:04 <suprothunderbolt> just looking at that now
Dec 29 06:25:28 <zmatt> your own widgets and routes are added to those of the codec
Dec 29 06:26:45 <zmatt> e.g. the codec's routes declare that DAC1 sends data to the AOUT1L/R outputs, and the AIN1L/R inputs connect to ADC1
Dec 29 06:27:15 <suprothunderbolt> oh so I can have none specified?
Dec 29 06:28:18 <zmatt> the codec's own routes are not sufficient, at least if the codec supports power management
Dec 29 06:28:36 <zmatt> basically you'd be declaring nothing is connected to the codec's inputs and outputs
Dec 29 06:29:10 <suprothunderbolt> ok, so I've just swapped around the AIN1L to Channel1in part.
Dec 29 06:29:22 <suprothunderbolt> the widgets all look correct though?
Dec 29 06:29:27 <zmatt> https://www.kernel.org/doc/Documentation/devicetree/bindings/sound/widgets.txt   is the documentation for the widgets you can declare
Dec 29 06:30:25 <suprothunderbolt> yep
Dec 29 06:30:34 <zmatt> unless you actually have a whole bunch of microphones and speakers, you should probably use Line type
Dec 29 06:31:01 <suprothunderbolt> what's actually the difference? Is it just for visualisation in the mixer or does it actually change something?
Dec 29 06:31:31 <zmatt> it's probably just to inform user interfaces, but I'm not sure
Dec 29 06:34:35 <suprothunderbolt> that doesn't appear to change anything as far as the mixer goes..
Dec 29 07:42:55 <suprothunderbolt> ahh, so it only has card controls acccesible but no simple controls.  "amixer -d -D hw:CARD=cardPCM3168 controls" returns all the simple controls
Dec 29 07:43:13 <suprothunderbolt> but any other control says device or resource busy
Dec 29 07:43:39 <zmatt> that's still weird
Dec 29 07:45:57 <suprothunderbolt> yeah
Dec 29 07:46:02 <zmatt> I can run amixer and alsamixer just fine. I don't have any controls (since my codec indeed doesn't have any) but it doesn't give any error
Dec 29 07:46:18 <suprothunderbolt> Controls      : 45
Dec 29 07:46:28 <suprothunderbolt> Components    : ''
Dec 29 07:46:31 <suprothunderbolt> so
Dec 29 07:47:19 <suprothunderbolt> it doesn't expose simple controls so I guess either I work out how to change these ones or work out how to add simple controls
Dec 29 07:47:46 <suprothunderbolt> I'm not sure if mute is turned on because at the moment I'm getting zero on all recording channels.
Dec 29 08:12:59 <suprothunderbolt> changed all the values I could find an still not getting any input signal...
Dec 29 13:02:52 <jibran> Hello
Dec 29 13:03:22 <jibran> From where I get the code because I want to contribute in your projects
Dec 29 13:06:00 <jibran> Hello
Dec 29 13:06:37 <jibran> From where I get the code of your projects because I want to contribute in it
Dec 29 13:06:55 <jibran> Please help me and resolve my query
Dec 29 13:09:48 <jibran[m]> Hello
Dec 29 13:10:42 <jibran[m]> From where I will get code of your projects because I wanted to contribute in your projects
**** BEGIN LOGGING AT Sat Dec 29 19:18:43 2018
**** ENDING LOGGING AT Sat Dec 29 20:17:59 2018

**** BEGIN LOGGING AT Tue Jan 01 01:50:10 2019
**** ENDING LOGGING AT Tue Jan 01 01:52:48 2019

**** BEGIN LOGGING AT Wed Jan 02 12:40:08 2019
Jan 02 15:53:41 <kremlin> m
Jan 02 19:10:42 <Hongxin> When I run olsr_start.sh in command line, I can find the olsrd process is running (ps -ef | grep olsr), but when i run it in systemd, there isn't the olsr process. I check the systemd log(journalctl -u olsr-start.service), get the following infomation: Jan 02 13:51:55 beaglebone2 olsrd[2650]: olsr.org -  0.6.6.2-git_0000000-hash_f349c738ff80f24cf05f404d0c75ba5e successfully started Jan 02 13:51:55 beaglebone2 olsrd[2650]: olsr.org -
Jan 02 19:11:21 <Hongxin> When I run olsr_start.sh in command line, I can find the olsrd process is running (ps -ef | grep olsr), but when i run it in systemd, there isn't the olsr process. I check the systemd log(journalctl -u olsr-start.service), get the following infomation: Jan 02 13:51:55 beaglebone2 olsrd[2650]: olsr.org -  0.6.6.2-git_0000000-hash_f349c738ff80f24cf05f404d0c75ba5e successfully started
Jan 02 19:11:27 <Hongxin> Jan 02 13:51:55 beaglebone2 olsrd[2650]: olsr.org -  0.6.6.2-git_0000000-hash_f349c738ff80f24cf05f404d0c75ba5e stopped   // olsrd auto stopped !!! I have no idea about it. Who can help me?
Jan 02 19:37:52 <tbr> wth is olsr?
Jan 02 19:48:05 <Hongxin> oslrd is a binary. I install it with "apt-get install olsr"
Jan 02 19:52:09 <tbr> my best guess is that you need to configure this
Jan 02 19:52:17 <tbr> and this is not really BBB specific
Jan 02 19:52:37 <tbr> best to ask somewhere where people with knowledge of oslrd hang out
Jan 02 19:57:35 <Hongxin> Thank you, <tbr>
Jan 02 20:06:47 <Hongxin> <tbr> You are right, I modify the olsr config file. It works. Thanks again
Jan 02 20:07:11 <tbr> :)
Jan 02 20:52:41 <thinkfat> tbr: you going to fosdem this year?
Jan 02 20:54:20 <tbr> thinkfat: quite likely, yeah
Jan 02 20:54:39 <thinkfat> tbr: any recommendation for hotel or something?
Jan 02 20:55:35 <tbr> thinkfat: most of "the trolls™" stay downtown usually. Most commonly at the Hotel Saint Nicholas
Jan 02 21:12:39 <thinkfat> tbr: not exactly cheap, but I guess that's normal for downtown...
**** ENDING LOGGING AT Thu Jan 03 02:59:57 2019