**** BEGIN LOGGING AT Sun Oct 23 02:59:58 2016
Oct 23 07:55:01 <jamesaxl> ayjay_t, I manage to update the kernel and everything works :)
Oct 23 08:06:12 <ayjay_t> yeah jamesaxl good for you
Oct 23 08:06:29 <ayjay_t> the best thing about 4+ are some of the lower-level tools that come with it
Oct 23 08:06:37 <ayjay_t> did you update the kernel from 4.4 image?
Oct 23 08:07:29 <jamesaxl> ayjay_t, of course I have now Linux beaglebone 4.4.24
Oct 23 08:07:55 <ayjay_t> because well if you use the latest image it comes with some pinmux utilities that are really nice
Oct 23 08:08:14 <ayjay_t> its like a command line that lets you alter the function of each pin @ runtime as opposed to needing to mux with which device trees are loaded
Oct 23 08:08:30 <ayjay_t> or something like that actually its been a while i just remember it being really nice
Oct 23 08:08:38 <ayjay_t> i really like the SPI driver, despite the no DMA
Oct 23 08:08:46 <ayjay_t> being able to set wordsize is a huge benefit
Oct 23 08:08:59 <nahtsoslimshady> are there any drivers that exist already that would allow me to interpret this data
Oct 23 08:09:09 <nahtsoslimshady> whoops
Oct 23 08:09:13 <ayjay_t> lol wrong channel
Oct 23 08:09:13 <jamesaxl> ayjay_t, that good news , thanks a lot
Oct 23 08:10:18 <nahtsoslimshady> i am trying to communicate with an external accelerometer module that uses i2c
Oct 23 08:10:26 <nahtsoslimshady> i am using a seeed beaglebone board
Oct 23 08:10:38 <nahtsoslimshady> and i know which mode and which pins i will be using
Oct 23 08:11:02 <nahtsoslimshady> but i dont know if there are any examples or drivers available for talking to the sensor over i2c
Oct 23 08:11:05 <nahtsoslimshady> halp
Oct 23 08:11:06 <nahtsoslimshady> pls
Oct 23 11:44:09 <Rocky123321> hello
Oct 23 11:44:13 <Rocky123321> everyone
Oct 23 11:44:21 <Rocky123321> iam rangith from india
Oct 23 11:44:31 <Rocky123321> i would to like to know about begalbone
Oct 23 16:06:04 <overlord_tm> anyone here ever worked with McASP on deaglebone black?
Oct 23 16:22:55 <zmatt> sure
Oct 23 16:23:57 <zmatt> tip: unless you're polling for statistics, include an actual question :P
Oct 23 16:26:08 <zmatt> ayjay_t: "despite the no DMA" .. eh what? the spi driver most definitely does support dma
Oct 23 16:40:51 <overlord_tm> zmatt, I do not even know how to ask :). Right after mcasp initialization is finished, i get one RDATA flag in interrupt and that a lot of receive buffer overflows. But XDATA in TX interrupt is never set, so I cannot send anything. Everything is done in loopback mode
Oct 23 16:41:24 <overlord_tm> The code, if it helps https://github.com/overlordtm/mcasp-spi
Oct 23 16:45:07 <overlord_tm> If I got the logic right, when I get RDATA flag in rx interrupt, I should read from RBUF for receiver serializer. When I get XDATA in tx interrupt, I should write to XBUF for tx serializer?
Oct 23 16:46:47 <zmatt> lemme see... typically mcasp would be used with dma of course, although I've also used it interrupt-driven (with and without fifo) on other SoCs
Oct 23 16:47:15 <overlord_tm> yeah, i am (ab)using it for non audio stuff
Oct 23 16:47:25 <overlord_tm> so DMA is not an option :)
Oct 23 16:47:49 <zmatt> then maybe "ti,am33xx-mcasp-audio" isn't quite appropriate as compatible string? :)  given that it's not am33xx-specific nor used for audio
Oct 23 16:48:01 <zmatt> and I don't see why using it in burst mode would preclude dma
Oct 23 16:48:39 <overlord_tm> also, i get DMAERR in (X/R)STAT, but I think I did not enable DMA mode
Oct 23 16:49:22 <overlord_tm> it is "ti,am33xx-mcasp-audio", so i can use existing devicetree :D
Oct 23 16:49:29 <zmatt> iirc that means the wrong amount of data was transferred in response to an interrupt or dma event
Oct 23 16:49:47 <zmatt> don't use a compatible-string that conflicts with the existing driver
Oct 23 16:50:09 <overlord_tm> have existing driver blacklisted, so i do not think it is a problem
Oct 23 16:50:22 <overlord_tm> I just need it for POC :)
Oct 23 16:51:07 <zmatt> it's still not nice, and it's a triviality to change the compatible-string of the mcasp node (either in the main dts or in an overlay if you use one to enable it)
Oct 23 16:52:26 <zmatt> btw there's a bug in mcasp_set_ctl_reg() in the kernel driver and yours: the comment above it is correct: you need to read back from GBLCTL (not from ctl_reg)
Oct 23 16:53:54 <overlord_tm> so, after each mcasp_set_ctl_reg I need to read back (even if the fucntion already do that)?
Oct 23 16:54:20 <zmatt> no you should just replace ctl_reg by GBLCTL in lines 94 and 98
Oct 23 16:55:15 <zmatt> or add a line  ctl_reg = GBLCTL;  after line 91 for example
Oct 23 16:56:10 <overlord_tm> do not see how would that have any impact? I always call mcasp_set_ctl_reg with GBLCTL. Maybe it would help only in cases when RGBLCTL and XGBLCTL are used?
Oct 23 16:56:18 <zmatt> yes
Oct 23 16:56:34 <zmatt> I hadn't checked whether you did or not, the original mcasp driver does
Oct 23 16:56:43 <overlord_tm> understood. But i use only GBLCTL
Oct 23 16:57:19 <overlord_tm> fixed :D
Oct 23 17:00:06 <overlord_tm> also fixed the compatible string :D
Oct 23 17:12:04 <overlord_tm> zmatt, was it possible that IRQ handlers were too slow since I used threader handlers in kernel?
Oct 23 17:12:24 <zmatt> that sounds entirely plausible yes
Oct 23 17:12:36 <overlord_tm> I changed the irq setup, and now I get send and receive irq-s, but it stops after few ping/pongs :D
Oct 23 17:12:54 <zmatt> printing debug messages there probably also doesn't help
Oct 23 17:13:10 <overlord_tm> I know, but i just want some confirmation something happened :D
Oct 23 17:13:34 <zmatt> I didn't think burst mode really knows the concept of overrun though?
Oct 23 17:13:41 <zmatt> *underrun
Oct 23 17:13:51 <overlord_tm> it is not burst mode, it is TDM, 16bit word, 8 slots
Oct 23 17:14:06 <zmatt> oh ok, in that case yes McASP has a zero-tolerance policy
Oct 23 17:14:15 <zmatt> that's why you normally at least enable the FIFO
Oct 23 17:14:24 <zmatt> and typically use dma
Oct 23 17:15:05 <zmatt> receive overruns aren't fatal, but transmit underruns are
Oct 23 17:15:19 <overlord_tm> Have to tahe a look into DMA and figure out if i can use it. Because the signal will be half audio/half control signal
Oct 23 17:18:13 <overlord_tm> zmatt, what actually happens on transmit underrun? Does mcasp stops?
Oct 23 17:18:33 <zmatt> yeah, you need to reset and restart the transmit section
Oct 23 17:19:04 <zmatt> note btw it's generally never necessary to reset the clock generators after initial setup
Oct 23 17:22:01 <overlord_tm> heh, no i removed all prints for data send/received in IRQ handlers, no more over/underruns :D
Oct 23 17:22:15 <overlord_tm> also, moved handlers from threaded to primary :D
Oct 23 17:22:49 <overlord_tm> but now I need to put it to osciloscope to confirm that it is actualy sending stuff :D
Oct 23 17:29:34 <overlord_tm> zmatt, if I understood correctyly, it is possible to use FIFOs independently from DMA? Because all FIFO stuff in reference manual is DMA related
Oct 23 17:29:44 <zmatt> sure
Oct 23 17:30:10 <zmatt> the fifo doesn't care whether it's serviced by dma or by an interrupt handler
Oct 23 17:31:05 <overlord_tm> so in IRQ handler i read from RBUF and write to RFIFO? Or is this handled in HW, so I just need to read from RFIFO?
Oct 23 17:32:20 <zmatt> uhh what
Oct 23 17:33:54 <zmatt> you read from the same register location as normal
Oct 23 17:34:07 <zmatt> the fifo is basically transparent
Oct 23 17:34:11 <overlord_tm> no idea how to use fifos, but i guess i can figure out from davicni-mcasp.c in kernel :D
Oct 23 17:34:43 <overlord_tm> so fifo just buffers received data, i case i am too slow in my code?
Oct 23 17:34:57 <overlord_tm> i just need to enable them?
Oct 23 17:35:25 <zmatt> yeah, and configure how much you will read/write per event/irq
Oct 23 17:39:20 <overlord_tm> tnx for now, gotta go home or GF will kill me :D
Oct 23 17:39:47 <zmatt> hehe
Oct 24 01:20:31 <tlab> laurittr, ok so I had to modify your DT/overlay a little bit, I changed or irq.h line to #include <dt-bindings/interrupt-controller/irq.h>
Oct 24 01:21:34 <tlab> after that it compiles ok for me, it loads, to mcp251x module gives me a clock frequency, which mine was not
Oct 24 01:22:02 <tlab> to=the
Oct 24 01:22:47 <tlab> I setup the can port without an errors
Oct 24 01:23:00 <tlab> I can use can-utils to send data, but the data doesn't show up on the bus
Oct 24 01:24:27 <tlab> show-pins lists the irq for spi2, which doesn't seem right
Oct 24 01:24:29 <tlab> P9.25 / audio osc                107 fast rx  up  7 gpio 3.21        1@spi2 (mcp2515_pins)
Oct 24 01:25:02 <tlab> the 3.8 working kernel shows:
Oct 24 01:25:03 <tlab> P9.25 / audio osc                107 fast rx  up  7 gpio 3.21 << hi  mcp251x-irq (pinmux_bone_tt3201_1_mcp2515_pins)
Oct 24 01:25:22 <tlab> I'm not sure what the << hi means
**** BEGIN LOGGING AT Mon Oct 24 01:30:16 2016
Oct 24 02:02:38 <zmatt> input that's currently high
Oct 24 02:02:56 <zmatt> the arrow indicates direction, << for input, >> for output
Oct 24 02:03:05 <zmatt> hi/lo indicates the level
Oct 24 02:37:21 <zmatt> the fact this info shows up means the pin has actually been requested as gpio by the driver, i.e. the driver requested its irq
Oct 24 02:38:05 <zmatt> the line you're showing for the non-working kernel merely indicates it has been muxed correctly, but so far the driver doesn't seem interested in it
**** ENDING LOGGING AT Mon Oct 24 02:59:57 2016