**** BEGIN LOGGING AT Sun Jun 26 02:59:58 2016 Jun 26 05:31:30 hey Zeekhuge, run into any issues where starting a program on a PRU freezes the whole board? Jun 26 05:31:43 * Visaoni might have accomplished it Jun 26 05:31:47 many times :) Jun 26 05:32:02 its getting in an infinite while loop Jun 26 05:32:09 trying interrupts ? Jun 26 05:32:34 yeah Jun 26 05:32:56 am I just sending too much data out from the PRU? Jun 26 05:36:20 nope ! you are not clearing the status of the interrupt once its encountered Jun 26 05:37:01 https://github.com/ZeekHuge/BeagleScope/blob/port_to_4.4.12-ti-r31%2B/examples/firmware_exmples/pru1_to_pru0_to_arm/main_pru0.c#L89 Jun 26 05:37:20 I'm only sending from the PRU out, nothing is coming back in. and I'm using the rpmsg-pru channel, so it should all be handled by the kernel module right? Jun 26 05:37:34 code ? Jun 26 05:39:32 Zeekhuge: https://pastebin.mozilla.org/8879743 Jun 26 05:39:50 oh, wait... Jun 26 05:41:02 SR_init() isn't getting called. not sure why that would cause the whole system to freeze though Jun 26 05:45:18 Welcome :) Jun 26 05:45:27 haha ! happens .. Jun 26 05:51:57 ZeekHuge: indeed... although it still freezes everything up anyway Jun 26 05:52:18 initialized vrings ? Jun 26 05:52:56 Visaoni: ^ Jun 26 05:53:06 okay .. theres the code. Jun 26 05:54:54 I believe so... the only thing I'm not sure about is that OCP master port bit. it won't compile when I include that line, it can't find CT_CFG Jun 26 05:55:13 pru_rpmsg_init is initializing the vrings ? Jun 26 05:55:13 I noticed you also commented that out in some of your stuff, figured you might have had the same problem Jun 26 05:55:32 I assume so Jun 26 05:55:51 I mostly just adapted the lab 5 example a bit Jun 26 05:56:15 include pru_intc Jun 26 05:56:25 pru_intc.h that is Jun 26 05:56:31 it is included Jun 26 06:00:04 OCP must be enabled, only then it will be able to communicate. Jun 26 06:01:53 * ZeekHuge realizes he himself is using a bit older package a there are significant changes . Jun 26 06:02:47 Visaoni: you first sending something to PRU right ? Jun 26 06:03:19 ZeekHuge: no, I'm just doing strictly output Jun 26 06:03:36 where did you get that DST and SRC from ? Jun 26 06:03:42 made them up Jun 26 06:03:55 looked like they were mostly being used to differentiate between channels or something Jun 26 06:04:23 destination and source is the channel number on the two sides. Jun 26 06:04:33 so the kernel first sends the message Jun 26 06:04:48 and then PRU takes dst and src from that message Jun 26 06:04:57 whats your dmesg saying ? Jun 26 06:06:02 no idea. everything freezes basically as soon as I load the program Jun 26 06:06:09 er Jun 26 06:06:16 start the core, after loading it Jun 26 06:10:28 interestingly, on the board CT_CFG is found. not the case for Code Composer on my desktop. at any rate, that doesn't seem to fix the problem either Jun 26 06:14:07 trying to compile it. Jun 26 06:15:06 ZeekHuge: if you are going to run than do so from the fake-data branch Jun 26 06:15:24 link ? Jun 26 06:15:29 Visaoni: ^ Jun 26 06:16:04 ZeekHuge: https://github.com/Visaoni/beagle-sonic-anemometer Jun 26 06:16:20 than? then Jun 26 06:19:02 Makefiles might look familiar... haven't nicked your deploy scripts yet though Jun 26 06:21:33 Visaoni: you using https://github.com/jadonk/pru-software-support-package this package ? Jun 26 06:22:11 no, I grabbed the stuff from the actually up-to-date on on TI's git Jun 26 06:22:21 *one on Jun 26 06:32:26 back, catching up on what's been happening Jun 26 06:33:51 Visaoni: got it compiled ... unable to load though ... Jun 26 06:34:05 trying to load it .. Jun 26 06:36:21 the one from github isn't setting the CT_CFG.SYSCFG_bit.STANDBY_INIT thing right now. it won't compile on my desktop but it does on the board. you could try uncommenting that bit out (store_readings.c/SR_init()). it doesn't change anything for me though Jun 26 06:36:23 Visaoni: Its PRU1 code na ? Jun 26 06:36:29 correct Jun 26 06:36:33 its working Jun 26 06:36:38 here atleast Jun 26 06:36:43 no hangups Jun 26 06:36:44 hm Jun 26 06:36:59 though I made some changes in the makefile Jun 26 06:37:10 it wasnt compiling otherwise Jun 26 06:37:41 interesting. what did you have to change? Jun 26 06:38:03 working dmesg : http://paste.debian.net/758822/ Jun 26 06:38:37 Makefile : http://paste.debian.net/758823/ Jun 26 06:42:20 Yes the Makefile was created before he had the rpmsg stuff included Jun 26 06:42:56 and before he copied in the include files, so I was using an external copy from the examples repo Jun 26 06:43:18 so... compare 'uname -a', ZeekHuge and Visaoni ? Jun 26 06:43:30 on bbb of course Jun 26 06:43:47 Linux beaglebone 4.4.12-ti-r31 #1 SMP Thu Jun 16 18:48:27 UTC 2016 armv7l GNU/Linux Jun 26 06:44:25 its the pru-package that must be not be aligned Jun 26 06:44:28 i think Jun 26 06:44:47 Linux beaglebone 4.4.12-ti-rt-r32 Jun 26 06:45:00 but then, the source for all the files -include and -libs was from Visaoni's repo Jun 26 06:45:02 v5 of pru package should go with r32 afaik Jun 26 06:45:03 yours is rt variant visaoni Jun 26 06:45:57 rt sometimes has issues with drivers that don't occur in the normal Jun 26 06:46:13 Visaoni: download that makefile and try with that Jun 26 06:46:21 how about you apt-get the non-rt to match ZeekHuge kernel? Jun 26 06:46:57 might as well get the updated Makefile checked in, yes Jun 26 06:49:28 ZeekHuge: no dice on that. still freezes things up (had to clean because it didn't detect any differences either) Jun 26 06:49:36 I'll try r31 Jun 26 06:49:46 specifically not-rt Jun 26 06:50:10 that's more likely to matter than r31 vs r32, but yes might as well do exact match Jun 26 06:50:44 roger that Jun 26 06:51:40 https://github.com/RobertCNelson/linux-stable-rcn-ee/compare/4.4.12-ti-r32...4.4.12-ti-r31 Jun 26 06:51:54 not much difference in rproc and rmsg Jun 26 06:52:19 *rpmsg Jun 26 06:52:40 right Jun 26 06:53:35 r31 is the one RCN announce as the first having the PRU INTC support Jun 26 06:53:57 I have the announcement link in my notes Jun 26 06:54:17 https://groups.google.com/forum/#!msg/beagleboard/cYHCN3GWw_E/ZJugfuRuBQAJ Jun 26 06:54:40 yeah .. that intense discussion Jun 26 06:55:26 yep I know you were reading that one Jun 26 06:55:43 * ZeekHuge needs a cup of tea and something to eat. He's on laptop since he is up. Jun 26 06:55:51 be right back Jun 26 07:04:42 ZeekHuge is right, don't see any changes in drivers/remoteproc between those 2 tags Jun 26 07:10:27 well, on the bright side I think I found the direct issue... Jun 26 07:11:18 I've got nearly 150MB in /var/log/messages of "virtio_rpmsg_bus virtio0: msg received with no recipient" Jun 26 07:14:57 Visaoni: and that is what i said Jun 26 07:15:11 you need to get the dst and src from the kernel Jun 26 07:15:34 so, you always have to send something in to the PRU first? Jun 26 07:15:43 so kernel will have to send message atleast once and then the pru will use that dst and src Jun 26 07:16:05 well, it can be just like a start signal . Jun 26 07:16:54 as far as I know, ATLEAST once. Not sure if the channel on the kernel side changes every-time it gets loaded. Jun 26 07:17:14 if it does, then yes. alteast once for every startup Jun 26 07:18:16 and if it remains constant. We might be able to use it directly. Jun 26 07:19:12 though your code will still hangup the board. add a __delay_cycle(1000000+) now after every message u send, and remove it later Jun 26 07:19:57 so when you run it, can you read anything out of /dev/rpmsg_pru31? Jun 26 07:20:08 yes. Jun 26 07:20:25 I take you added that yourself then, if it's not hanging yours? Jun 26 07:28:39 What happens when you clear that STANDBY_INIT bit? I thought that was supposed to be cleared when sending data to kernel, which uses main memory Jun 26 07:29:02 it still fails Jun 26 07:29:20 I had(have) it commented out because it won't compile on my desktop Jun 26 07:29:21 I think it's necessary but not sufficient Jun 26 07:29:32 agreed Jun 26 07:29:54 I'll just have to start compiling stuff on the board, I guess Jun 26 07:30:06 Yep Jun 26 07:36:26 Also the delay for now was a good idea from ZeekHuge, don't flood the ARM with messages Jun 26 07:38:26 As far as dst and src, Jun 26 07:38:30 pru_rpmsg_channel(RPMSG_NS_CREATE, &transport, CHAN_NAME, CHAN_DESC, CHAN_PORT) Jun 26 07:39:03 CHAN_PORT is supposed to be the src for a channel going from PRU to ARM Jun 26 07:40:47 and dst for the ARM address seems to be 53 Jun 26 07:40:53 http://git.ti.com/pru-software-support-package/pru-software-support-package/blobs/master/lib/src/rpmsg_lib/pru_rpmsg.c#line184 Jun 26 07:42:03 ZeekHuge: when you get back, would you pastebin 'git diff' to show the changes that worked? Jun 26 07:42:12 nice catch Jun 26 07:42:17 one the bbb make a symlink for prulnkr too Jun 26 07:43:52 I'm thinking the reason things might not compile on the desktop is that CCS is going off and finding it's own pru_cfg.h elsewhere Jun 26 07:44:37 it's version is missing include guards and doesn't set CT_CFG as an attribute or some such thing Jun 26 07:46:08 my grammar is not doing well tonight Jun 26 07:48:09 Don't worry, sufficient to be understood Jun 26 07:49:23 you're probably right about the include file, but at least compiling on the board is an acceptible solution Jun 26 07:49:41 rather than spending time fighting with CCS Jun 26 07:50:03 I got it working, wasn't hard. I just changed the search path priorities Jun 26 07:50:13 Ok Jun 26 08:15:44 Wormo: hm, it doesn't seem to like a dst of 53 either Jun 26 08:15:58 at least it isn't still freezing up the board Jun 26 08:16:23 even if does eat up all the disk space with logs... Jun 26 08:19:40 or maybe it just takes longer to freeze things up Jun 26 08:22:35 :( Jun 26 08:23:28 The delay should have helped with that, it was likely CPU starved rather than deadlocked Jun 26 08:23:41 the freeze I mean Jun 26 08:29:05 Well ok try ZeekHuge suggestion, of starting with a receive and flipping dst/src to start transmitting? Jun 26 08:29:35 That was in the echo example that he was hacking on earlier Jun 26 08:31:04 it did work for him, so that's a proven strategy Jun 26 08:32:32 Perhaps the 53 ARM address is just a stub, and the real one is filled on receive Jun 26 08:40:56 Is rpmsg_pru module being loaded automatically like it should be, btw? So getting the character device created? Jun 26 08:41:05 I also might be an idiot, 1 sec... Jun 26 08:42:05 yeah, the character device is showing up Jun 26 08:43:00 ok well try the receive first, since that does work in the example Jun 26 08:43:37 the 53 in the lib could be a dummy value, with the linux side allowed to pick it's own number Jun 26 08:44:33 that *really* should be covered in the docs, but I haven't found it any more than you have Jun 26 08:45:48 I should be heading out, hope the rx before tx works so you can move on Jun 26 08:46:18 ltr Jun 26 08:51:11 back Jun 26 08:51:23 will be leaving soon .. Jun 26 08:51:46 Visaoni: got anything ? Jun 26 08:55:11 ZeekHuge: not just yet. about to try with an initial send (about meaning I still need to clean up from the last attempt) Jun 26 08:56:36 okay . remember, if you see something weird in the logs, just reboot the board. Jun 26 09:04:17 leaving good luck Visaoni Jun 26 15:47:22 Hi, anybody here for some help? Jun 26 15:47:45 henrix_: whats up? Jun 26 15:49:13 m_w, I have a problem with my ASoC kernel module. everytime when i want to play audio my kernel crashes due iommu errors Jun 26 15:49:28 [ 69.106742] omap-iommu 41502000.mmu: iommu fault: da 0xc266da80 flags 0x0 Jun 26 15:49:28 [ 69.115141] remoteproc3: crash detected in 41000000.dsp: type mmufault Jun 26 15:49:28 [ 69.123425] omap-iommu 41502000.mmu: 41502000.mmu: errs:0x00000002 da:0xc266da80 pgd:0xea817098 *pgd:px00000000 Jun 26 15:49:29 [ 69.136147] remoteproc3: handling crash #1 in 41000000.dsp Jun 26 15:49:31 [ 69.136153] remoteproc3: recovering 41000000.dsp Jun 26 15:49:57 hmmmmm Jun 26 15:50:15 i'm using kernel 4.1 with X15 Jun 26 15:50:25 could it be a bug with cmemk module? Jun 26 15:51:37 not sure Jun 26 15:51:42 moreover cmemk module is not available in my kernel, although it is the same tag as kernel in sd card image Jun 26 15:52:03 that is strange Jun 26 15:52:09 out of tree module? Jun 26 15:52:16 seems so Jun 26 15:53:10 I also have to stick to 4.1 kernel because cmemk module is not ported to 4.4 kernel yet and i need it for my dsp lib Jun 26 15:53:34 ah Jun 26 15:54:21 lemme learn a bit about it Jun 26 15:54:31 thanks Jun 26 15:54:40 what parameters are you using when loading the cmemk module? Jun 26 15:55:03 the same like in suggestion Jun 26 15:55:20 modprobe cmemk phys_start=0xa0000000 phys_end=0xc0000000 pools=1x536870912 allowOverlap=1 Jun 26 15:55:41 but my soundcard driver is in no connection with cmemk module. hmm Jun 26 15:55:56 that a different project Jun 26 16:01:47 could you post all of your kernel messages to a pastebin? Jun 26 16:03:02 cmemk seems related to opencv Jun 26 16:04:00 or dsps Jun 26 16:05:01 ok Jun 26 16:06:33 also paste the sequence of steps you are running Jun 26 16:06:51 ok Jun 26 16:14:35 http://pastebin.com/V98N8hAk Jun 26 16:15:55 snd_ctag_face_2_4 sound@2: snd_soc_register_card failed (-517) Jun 26 16:16:07 the sound card is failing to register Jun 26 16:16:53 jic23b: there? Jun 26 16:16:57 ok, I also had this error with BBB and another PCM soundcard with RPi2 but everything works fine Jun 26 16:17:04 oh wait that is a probe defer Jun 26 16:18:10 could you post the output of dmesg Jun 26 16:19:02 before starting the audio and the puke Jun 26 16:20:02 http://pastebin.com/sL0yFvVH Jun 26 16:27:42 very strange Jun 26 16:28:15 yes-.- already spent 3 days with this Jun 26 16:28:20 tried several kernel versions Jun 26 16:28:22 and so on Jun 26 16:29:28 do the other sound cards work or do they cause the failure too? Jun 26 16:29:37 the also occurs when i2s clk is triggered Jun 26 16:29:40 they work fine Jun 26 16:29:53 *only occurs Jun 26 16:30:21 if codec is clk master and clks are not connected, no crash Jun 26 16:30:32 as soon as clk signal arrives the error occurs Jun 26 16:32:11 lets take a look at the devicetree and pinmux Jun 26 16:32:18 so I think when buffer i/o is triggered this causes some mem violation Jun 26 16:32:22 ok Jun 26 16:32:38 moment, I haven't pushed the last state Jun 26 16:32:41 yet Jun 26 16:33:37 http://pastebin.com/0Zt9n6sz Jun 26 16:34:30 I added sound2 node, mcspi node, mcasp2 node and pin mux settings Jun 26 16:37:41 I really hate figuring out the pinmux on TI products Jun 26 16:38:01 I already checked it several times Jun 26 16:38:13 especially offsets Jun 26 16:38:54 Also compared with other values to ensure correct calculation Jun 26 16:43:40 Currently i have configured cpu to be clk master. So the error occurs directly after speaker-test execution Jun 26 16:44:33 okay Jun 26 16:44:51 henrix_: cmem module is part of TI linux-utils and it allows allocation of big blocks of memory for commuication between main ARM and other CPUs that can bus master the RAM Jun 26 16:45:14 for instance, the DSP Jun 26 16:45:25 yes, already used it in my DSP lib Jun 26 16:45:33 but this is another project Jun 26 16:45:47 the error occurs with my sound card driver Jun 26 16:46:06 your sound card driver trying to talk to the dsp? Jun 26 16:46:10 no Jun 26 16:46:30 so if you don't load any firmware into the DSP, the sound card driver works? Jun 26 16:46:49 driver is in no (direct) connection with dsp or remoteproc Jun 26 16:47:00 no, the soundcard driver never works Jun 26 16:47:14 have you specifically tried it without allowing the DSP to load Jun 26 16:47:46 the kernel version I use currently doesn't have cmemk module. Jun 26 16:48:05 could this be the problem? Jun 26 16:48:07 But the DSP firmware was still loading Jun 26 16:48:29 ok, but why occurs the dsp error if i doesn't use anything of this Jun 26 16:48:31 and trying to write to the memory where it expected to be given a buffer? Jun 26 16:48:33 *in my module Jun 26 16:49:41 hmm, the drivers worked fine with BBB and the digital audio interface is same like bb-x15. Jun 26 16:49:53 so i think buffer i/o should be fine also Jun 26 16:50:06 If DSP happens to start running and dumping to a buffer which was not reserved for it, because it mistakes random data for some signal it was looking for, then the memory corruption problems would be hard to predict Jun 26 16:50:34 so it's worth booting without letting that DSP firmware load to rule it out Jun 26 16:50:56 ok Jun 26 16:51:21 i just comment it out in device tree, correct? Jun 26 16:51:24 since a little area of memory could get used for something important in one circumstance, and get "lucky" in another Jun 26 16:51:27 yes Jun 26 16:51:38 or move the file aside, maybe easier Jun 26 16:51:43 firmware file Jun 26 16:51:50 ok Jun 26 16:52:34 what is the exact name of the firmware file? Jun 26 16:53:20 dsp1_cma and dsp2_cma? Jun 26 16:54:30 hm probably, unfortunately the cmem + dsp platform I have experience with has an ancient pre-devicetree kernel Jun 26 16:54:56 ok Jun 26 16:55:02 but I see that in your dmesg now Jun 26 16:55:11 think should be dra7-dsp1-fw.xe66 and dra7-dsp2-fw.xe66 Jun 26 16:55:22 moved it and will reboot now Jun 26 16:55:50 cool, it should complain about firmware loads failing if that was right Jun 26 16:55:57 ok Jun 26 16:56:22 oh it is a collision Jun 26 16:56:50 maybe Jun 26 16:57:02 have to head out ttyl Jun 26 16:57:33 oh nice! Jun 26 16:57:49 kernel no errors without dsp firmware Jun 26 16:58:10 how about the audio? Jun 26 16:58:11 *no kernel errors Jun 26 16:58:15 will check now Jun 26 16:58:44 have oscilloscope connected right now. I will decode some i2s data and then connect to the soundcard Jun 26 16:59:05 so not puking anymore Jun 26 16:59:52 yeah^^ Jun 26 17:01:00 great Jun 26 17:01:38 so the dma buffer may have overlapped perhaps Jun 26 17:02:16 yeah, I'm a lucky guy if everything works now Jun 26 17:02:45 i2s seems to be ok. will set codec to clk master now and connect the soundcard Jun 26 17:04:47 cmemk is a separate package/module build iirc Jun 26 17:05:09 edma, cmemk, several others Jun 26 17:05:47 * nerdboy hasn't played that closely with TI vendor kernel since dm8168 on 2.x Jun 26 17:32:13 it works!!! Jun 26 17:32:17 thanks so much! Jun 26 17:32:51 cool Jun 26 17:33:19 henrix_: meaning without the dsp firmware? Jun 26 17:33:26 yes Jun 26 17:34:03 but this is my next problem. I want to program a lib for DSP calculations. For this I need the firmware. Jun 26 17:34:16 any idea how to avoid this problem? Jun 26 17:34:29 yeah, you'll need to sort the memory issue Jun 26 17:35:00 ^^ that wasn't an answer, just slow typing... Jun 26 17:37:31 hmm, I will see if i find some helpful information Jun 26 17:37:42 so, this is TI stuff right? Jun 26 17:37:59 yup Jun 26 17:38:13 there are recipes in meta-ti Jun 26 17:38:30 ok, thanks, I'll check that Jun 26 17:39:26 beagleboard-bsp/poky/meta-ti/recipes-bsp/cmem/cmem_git.bb Jun 26 17:39:42 strip the first two off the path Jun 26 17:40:38 http://git.yoctoproject.org/cgit/cgit.cgi/meta-ti/tree/recipes-ti Jun 26 17:41:38 and http://git.yoctoproject.org/cgit/cgit.cgi/meta-ti/tree/recipes-bsp Jun 26 17:42:18 not sure if most of that stuff is on 4.4 yet Jun 26 17:43:46 http://processors.wiki.ti.com/index.php/DSP_MMU_Faults Jun 26 17:44:03 ok, I'm still using 4.1 because module is not ported to 4.4 yet (Robert Nelson informed) Jun 26 17:44:14 which module Jun 26 17:44:49 they have both 4.1 and 4.4 in meta-ti Jun 26 17:44:58 the older ones are gone Jun 26 17:45:17 henrix_: which module isn't ported yet? Jun 26 17:45:42 opencl Jun 26 17:46:05 don't know which exact module Jun 26 17:46:14 fyi: regarding debian, only the v4.1.x kernel has opencl working Jun 26 17:46:15 out of the box, i need to finish the port to our v4.4.x kernel. ;) Jun 26 17:46:24 by Robert Nelson Jun 26 17:46:25 what's the dependency on opencl? Jun 26 17:46:39 http://processors.wiki.ti.com/index.php/CMEM_Overview Jun 26 17:47:21 you may need to reserve the memory for cmem Jun 26 17:48:01 Q: In Linux, how do I set aside the memory carveout that CMEM uses? Jun 26 17:49:17 ook, thanks Jun 26 17:49:58 sounds about right Jun 26 17:50:18 not sure how that plays with CMA in the kernel Jun 26 17:50:27 my guess is it doesn't Jun 26 18:23:52 Visaoni: maybe now is a good time to stop and catch up on descriptive stuff Jun 26 18:47:02 not sure the adc readme is as currrnt as it could be Jun 26 18:47:38 *current even Jun 26 18:53:59 aaaand the top-level readme needs more zombie flesh... Jun 26 19:12:37 pmezydlo: hey you figure out the devicetree stuff? Jun 26 19:21:07 m_w: hi, not yet but I know how it should look like Jun 26 19:22:03 I think since we are using dt overlays more care is required Jun 26 19:24:40 yeah sure, I think that probably I will use platform device function. Jun 26 19:24:52 of_platform_populate Jun 26 19:27:42 probably this function should work and should be enough Jun 26 19:27:49 http://lxr.free-electrons.com/source/drivers/mfd/palmas.c#L668 Jun 26 19:28:20 I checked and does not work as I thought Jun 26 19:28:52 and I went back to what is in omap-McBSP Jun 26 19:28:55 m_w:^^ Jun 26 19:29:16 lemme take a look Jun 26 19:32:51 pmezydlo: not sure what you are referring to in omap-mcbsp Jun 26 19:33:06 oh sorry Jun 26 19:33:14 omap-mcspi Jun 26 19:34:56 right here: http://lxr.free-electrons.com/source/drivers/spi/spi.c#L1578 Jun 26 19:35:04 m_w:^^ Jun 26 19:35:43 yeah okay Jun 26 19:35:51 makes sense Jun 26 19:36:22 is your latest code commited so that I can pull it and try it out? Jun 26 19:37:36 yeah on github is latest code Jun 26 19:39:04 this is function which adds new device: https://github.com/pmezydlo/SPI_slave_driver_implementation/blob/master/driver/spi-mcspi-slave.c#L673 Jun 26 19:41:01 there is nothing beyond the search child node, I had to go back Jun 26 19:42:37 m_w:^^ Jun 26 19:43:16 hmmmm Jun 26 19:43:39 go back to what? Jun 26 19:48:56 spi.c uses similar functions as platform_device for registering devices Jun 26 19:49:44 at the beginning I tried to take advantage of the functions of the device platforms Jun 26 19:50:45 oh okay Jun 26 19:50:55 okay the main driver loads Jun 26 19:51:22 but it does not works probably I did something wrong Jun 26 19:51:52 now I tried to do something similar as in spi.c Jun 26 19:52:18 spislave is not getting passed init Jun 26 19:53:22 past Jun 26 19:53:24 but probe function not call Jun 26 19:53:43 so that is the problem then? Jun 26 19:56:12 most of the drivers makes it so: http://events.linuxfoundation.org/sites/events/files/slides/dt_internals.pdf page:59 Jun 26 19:58:53 m_w:and I want to do a similar way Jun 26 20:00:44 have you tried adding it to the kernel dts instead of the overlay to see if it works? Jun 26 20:01:18 not jet Jun 26 20:01:40 might be worth a try Jun 26 20:02:29 we need to remove the automatic addition of status = "okay" for McSPI Jun 26 20:08:00 after start system both spi0 and spi1 have status="okay" Jun 26 20:08:28 hmmm Jun 26 20:16:51 Now i try install new device and i use platform device function Jun 26 20:17:43 any luck? Jun 26 20:20:33 I found something: http://pastebin.com/qLakJKmg Jun 26 20:23:13 the korean chars are a little weird... Jun 26 20:24:05 yeah but code look very nice Jun 26 20:37:15 you need a struct device for every child node Jun 26 20:38:58 each child should really have its own struct Jun 26 20:39:46 like spi_device is to spi_master Jun 26 20:43:42 yes I know about that, Jun 26 20:44:13 do you have a newer version that has this? Jun 26 20:45:31 not yet Jun 26 20:46:59 you have a struct for each attached slave? Jun 26 20:48:44 until now I thought that it will be platform_device Jun 26 20:48:53 this struct for own child should be platform_device, and I want add aux_data: http://lxr.free-electrons.com/source/include/linux/of_platform.h#L42 Jun 26 20:49:02 in this structure should be pointer to master platform data Jun 26 20:50:12 what do you think about it Jun 26 20:50:26 a bit lost Jun 26 20:50:49 too much going on Jun 26 20:51:54 let's go we back to the beginning Jun 26 20:52:11 I found something: http://pastebin.com/qLakJKmg Jun 26 20:52:47 This is the way the device platform Jun 26 20:53:29 not another peanut... Jun 26 20:57:21 nerdboy: huh? Jun 26 20:58:05 so we need new bus driver Jun 26 20:58:25 nm, random humorroid Jun 26 20:58:47 http://images.simplysyndicated.com/wp-content/uploads/2015/03/national-bus-driver-2010-446x312.jpg Jun 26 20:59:04 * nerdboy used to have class 2 license for the big vans Jun 26 20:59:17 can i be bus driver? Jun 26 20:59:39 ^^ mostly for geology field trips Jun 26 20:59:44 sure Jun 26 21:00:28 http://www.makelinux.net/ldd3/chp-14-sect-4 Jun 26 21:01:18 spi_short_bus Jun 26 21:02:27 i said geology students, not *that* bus... Jun 26 21:02:53 :-( Jun 26 21:03:21 http://www.linuxjournal.com/article/6717 Jun 26 21:03:47 we need gkh's input Jun 26 21:04:52 Greg Kroah-Hartman always helpful Jun 26 21:09:33 http://lxr.free-electrons.com/source/drivers/spi/spi.c#L388 Jun 26 21:12:14 https://www.youtube.com/watch?v=DH1yM9onBkk Jun 26 21:13:53