**** BEGIN LOGGING AT Fri Jul 22 02:59:58 2016 Jul 22 04:24:34 is there a "best" way to change the pinmux from userspace? C++ program atm Jul 22 04:35:40 as in unload/load another dt overlay? Jul 22 04:36:25 probably better answer in beagle channel... Jul 22 04:37:08 but if you can't load a single overlay/pinmux then the eval board might be a bust Jul 22 04:37:10 doesn't need to be. I don't need to grab any new pins, just change the direction of some already used Jul 22 04:37:57 although does a dt overlay lock the config of used pins? Jul 22 04:38:22 i think it sets a default and makes them exclusive Jul 22 04:38:57 in that case, can I just write to the pinctrl file? Jul 22 04:39:08 no idea Jul 22 04:39:25 try it and see... Jul 22 04:40:08 is that what beaglelogic/prudaq does? Jul 22 04:41:03 does prudaq change direction of pins? didn't look to me like that on first glance Jul 22 04:41:27 haven't looked that hard at beaglelogic implementation Jul 22 04:41:39 i didn't see it, but didn't look through everything yet... Jul 22 04:42:01 they have firmware "extension" => https://github.com/abhishek-kakkar/BeagleLogic/wiki/Firmware-Extensions:-Custom-firmware-for-BeagleLogic Jul 22 04:42:23 wanna try that? might be relatively quick... Jul 22 04:47:41 i'm pretty sure the config-pin tool does that ^^ so i guess you'd need a signal or just read the config register? Jul 22 04:48:34 *config-pin ~= /sys/foo Jul 22 04:51:14 I was thinking just use rpmsg. setup the userspace side to take/respond to msgs. pru can signal what the userspace is to do and receive msg when it's done Jul 22 04:55:37 and do you mean write a firmware extention for beaglelogic? Jul 22 04:58:28 just curious if it can talk to the eval board... Jul 22 04:58:53 not sure how much work it would be Jul 22 04:59:45 would the pin mode changing req go away if you had the adc by itself? Jul 22 04:59:51 no Jul 22 05:00:33 so it's not the eval board interface that's weird? Jul 22 05:00:35 it's just how the adc works. they could have split it on the eval board I guess, but it would mean 12 more pins Jul 22 05:01:06 well, the eval board is kind of weird but the adc is too Jul 22 05:01:17 there should be 12 pins free without hdmi/audio Jul 22 05:01:28 12 more... Jul 22 05:01:36 yeah, 12 more Jul 22 05:01:45 how many are you using now? Jul 22 05:02:05 er... 15 unless I"m forgetting something Jul 22 05:02:24 and that's with tying a couple pins on the chip straight to high/low Jul 22 05:02:43 prudaq uses 13 input and 6 ouput Jul 22 05:02:56 2 more free if you disable emmc Jul 22 05:03:55 so with adc pins split you would need 15 plus 12? Jul 22 05:06:55 yeah Jul 22 05:10:35 so just go with your message thing i guess Jul 22 05:14:50 the register thing seems like a good idea Jul 22 05:15:09 not sure if that works as inline asm... try it and see? Jul 22 05:18:14 I'm not sure it's needed for this. BeagleLogic is up at 100MHz. this is down at 6 Jul 22 05:18:39 it's also not as simple, because both PRUs need to be working with the adc in a timely manner Jul 22 05:20:34 depends on rmpsg/userspace latency and other stuff, no? Jul 22 05:21:10 might need a little extra headroom Jul 22 05:21:43 nah. the reads for a run can fit in the PRU RAM, so the only latency issue is going to be whatever we might hit there Jul 22 05:21:58 then we can wait for rpmsg to shuttle everything off, then go again Jul 22 05:22:58 the FIFO on the adc is 16 deep, so we do have some headroom if there is potential latency going to PRU RAM Jul 22 05:23:01 can give priority to user stuff but pru timing is kinda tight Jul 22 05:23:31 there are potential bus stalls in system ram according to ^^ Jul 22 05:24:48 yeah. do we know how long they can be? Jul 22 05:25:21 i don't Jul 22 05:26:26 I'm hoping at 6MSPS with a 16 deep FIFO we have enough headroom to mostly ignore bus stalls Jul 22 05:27:18 the faster you move data out the better Jul 22 05:27:22 otherwise it's kind of a tight spot. one PRU is the clock, the other is doing the reads Jul 22 05:27:40 if the stalls are too long, there isn't really one PRU can sacrifice to them Jul 22 05:29:19 well, see how fast it goes and then try the register moves if needed Jul 22 05:29:32 register moves will make it worse, actually Jul 22 05:29:41 the clock is more sensitive to stalls than the reader is Jul 22 05:29:46 the reader at least as the FIFO as a buffer Jul 22 05:30:56 i don't get the worse part if it takes less cycles Jul 22 05:31:03 it won't take less cycles Jul 22 05:31:31 the register move just gets data from one PRU to the other Jul 22 05:31:37 at least as I understand it Jul 22 05:31:53 if you have a PRU that isn't time sensitive then that's great Jul 22 05:32:17 but both PRUs have timing requirements for this Jul 22 05:33:19 so does beaglelogic if the external clock is optional Jul 22 05:34:41 I'd have to look at it, but I don't think it has to be that way. if the PRU is just running full bore taking reads and moving them off then that would get you to 100Mhz sample if both are 1 cycles ops Jul 22 05:35:23 it runs both triggered and continuous Jul 22 05:35:53 but i haven't looked at the code in much detail yet Jul 22 05:39:18 go forth and collect some data Jul 22 05:42:57 since your thing is wireless now you can calibrate the imu Jul 22 05:44:31 not really any less wireless than before, considering it still needs usb power and the non-wireless one was using network-over-usb :) Jul 22 05:44:40 or rather any /more/ wireless Jul 22 05:45:17 got a battery? Jul 22 05:45:51 the little stick schwag batteries should go at least an hour Jul 22 05:46:12 2200 mAhrs i think, give or take Jul 22 05:46:30 nothing really on hand that'll take usb Jul 22 05:47:46 prehaps someone needs to make a Qi cape Jul 22 05:50:36 battery pack? Jul 22 05:53:02 once you calibrate and it writes the settings you have to move the .ini file to wherever you run from Jul 22 05:54:44 looking at the beaglelogic firmware, it looks like it's just using static timing from instruction times. an external clock might be used with a DELAY instruction (just a guess) Jul 22 05:55:04 fancy imu needs fancy userspace code i guess... Jul 22 05:55:09 the PRU0 stuff is certainly free of timing reqs at least Jul 22 05:55:15 *beaglelogic PRU0 Jul 22 05:57:36 I mean, obviously if ARM is too slow to gather in time it's a problem, but PRU0 isn't trying to shuttle data and manage a separate time sensitive thing Jul 22 07:48:04 Wormo: nerdboy there ? Jul 22 07:48:20 hi Jul 22 07:48:26 Hey ! Jul 22 07:48:41 So the firmware is ready. and very well tuned. Jul 22 07:48:55 Michael tested it Jul 22 07:49:03 great! Jul 22 07:49:04 using scope Jul 22 07:49:26 the output is exactly according to the configuration Jul 22 07:49:30 now .. the driver Jul 22 07:49:46 so .. its will register to iio Jul 22 07:51:01 1 /sys/bus/iio/devices/iio:deviceX Jul 22 07:51:02 2 /sys/bus/iio/devices/triggerX Jul 22 07:51:02 3 /sys/bus/iio/devices/iio:deviceX/buffer Jul 22 07:51:02 4 /sys/bus/iio/devices/iio:deviceX/name Jul 22 07:51:02 5 /sys/bus/iio/devices/iio:deviceX/sampling_frequency Jul 22 07:51:02 6 /sys/bus/iio/devices/iio:deviceX/in_voltageY_raw Jul 22 07:51:04 7 /sys/bus/iio/devices/iio:deviceX/in_X_mean_raw Jul 22 07:51:06 8 /sys/bus/iio/devices/iio:deviceX/events Jul 22 07:51:08 9 /sys/bus/iio/devices/iio:deviceX/trigger/current_trigger Jul 22 07:51:10 10 /sys/bus/iio/devices/iio:deviceX/buffer/length Jul 22 07:51:13 these are the sysfs entries I need to get done Jul 22 07:52:15 ok have you been looking at other iio drivers yet? Jul 22 07:52:32 yes ... I have done some part of it Jul 22 07:52:42 https://github.com/ZeekHuge/BeagleScope/blob/port_to_4.4.12-ti-r31%2B/driver/beaglescope_driver.c Jul 22 07:53:25 now these sysfs entries are created by the IIO subsystem right ? but to tell the subsystem this DS is used Jul 22 07:53:26 https://github.com/ZeekHuge/BeagleScope/blob/port_to_4.4.12-ti-r31%2B/driver/beaglescope_driver.c#L40 Jul 22 07:53:38 is that correct ? Jul 22 07:54:04 pulling your code... Jul 22 07:54:07 this structure that basically defines the channel will be used to get these sysfs created Jul 22 07:56:02 Wormo: triggers are generated by the external events ? or by the CPU/ processor ? Jul 22 07:56:53 What: /sys/bus/iio/devices/triggerX Jul 22 07:56:54 KernelVersion: 2.6.35 Jul 22 07:56:54 Contact: linux-iio@vger.kernel.org Jul 22 07:56:54 Description: Jul 22 07:56:54 An event driven driver of data capture to an in kernel buffer. Jul 22 07:56:54 May be provided by a device driver that also has an IIO device Jul 22 07:56:56 based on hardware generated events (e.g. data ready) or Jul 22 07:56:58 provided by a separate driver for other hardware (e.g. Jul 22 07:57:00 periodic timer, GPIO or high resolution timer). Jul 22 07:57:02 Contains trigger type specific elements. These do not Jul 22 07:57:04 generalize well and hence are not documented in this file. Jul 22 07:57:06 X is the IIO index of the trigger. Jul 22 07:57:41 I mean what is the use of this sysfs ? if a trigger is an external event ? Jul 22 07:58:41 I think it is to configure the trigger Jul 22 07:59:02 set it up, rather than set off trigger events Jul 22 07:59:55 actually there is a way to use sysfs as triggers in place of external events Jul 22 08:00:34 https://wiki.analog.com/software/linux/docs/iio/iio-trig-sysfs Jul 22 08:02:00 and here is an example of configuring timers to be hardware triggers Jul 22 08:02:04 https://wiki.analog.com/software/linux/docs/iio/iio-trig-bfin-timer Jul 22 08:02:58 so I guess the specifics really do depend on what iio-trig- driver is in use Jul 22 08:03:19 the specifics on trigger sysfs file Jul 22 08:04:14 what were you wanting to use to trigger capturing? Jul 22 08:04:37 software or external gpio or something Jul 22 08:05:55 here's another example of software vs hardware trigger usage Jul 22 08:06:36 for Atmel SOC which have bultin ADC: http://www.at91.com/linux4sam/bin/view/Linux4SAM/IioAdcDriver Jul 22 08:12:46 Its all just flying away Jul 22 08:12:55 Wormo: How long before you leave ? Jul 22 08:19:34 heading out soon actually Jul 22 08:21:55 Okay Jul 22 08:26:24 what measurements will be used for the averaged channel? Smoothed version of your other channel? Jul 22 08:26:55 measurements ? ahh .. voltage ? Jul 22 08:27:43 so same as in_voltageY_raw only the smoothed version? Jul 22 08:27:59 (by averaging some number of adjacent samples) Jul 22 08:28:13 yes Jul 22 08:28:52 What: /sys/bus/iio/devices/iio:deviceX/in_X_mean_raw Jul 22 08:28:52 KernelVersion: 3.5 Jul 22 08:28:53 Contact: linux-iio@vger.kernel.org Jul 22 08:28:53 Description: Jul 22 08:28:53 Averaged raw measurement from channel X. The number of values Jul 22 08:28:53 used for averaging is device specific. The converting rules for Jul 22 08:28:55 normal raw values also applies to the averaged raw values. Jul 22 09:08:02 Just received the package from seed studio. Jul 22 09:58:22 ZeekHuge: bleh just finished catching up my work emails... yay for getting seed studio packages! Jul 22 09:58:27 gnight Jul 22 12:26:32 nerdboy: bradfa anyone there ? Jul 22 12:26:40 quite sure others are not .. Jul 22 12:33:49 hi ZeekHuge I'm here for now Jul 22 12:34:24 ZeekHuge: what's up? Jul 22 12:34:38 okay ... so here is the driver that I need to work on Jul 22 12:35:00 https://github.com/ZeekHuge/BeagleScope/blob/port_to_4.4.12-ti-r31%2B/driver/beaglescope_driver.c#L109 Jul 22 12:35:04 bradfa: ^^ Jul 22 12:35:20 its a combination of IIO and rpmsg client driver Jul 22 12:35:32 now as i have pointed in the link Jul 22 12:35:56 this callback method is called each time the PRU sends data to this driver Jul 22 12:36:13 I am trying to implement it like a bus driver Jul 22 12:36:29 so is it a good idea to save the data from PRUs in a FIFO ? Jul 22 12:36:35 like i have done there in the code ? Jul 22 12:37:56 ZeekHuge: userspace is responsible for pulling data out of your driver, effectively from the FIFO, right? Jul 22 12:38:07 yes Jul 22 12:38:27 you are asking with respect to my code right ? Jul 22 12:38:39 ZeekHuge: since you're making a scope, what's the maximum number of samples you want to hold in memory for a given trigger? Jul 22 12:38:54 ZeekHuge: yes, in respect to your code Jul 22 12:39:36 bradfa: well, its not to be implemented in that sense. It needs to be implemented like a bus. just like an SPI or I2C bus. Jul 22 12:39:52 so .. the other methods sit on these functions Jul 22 12:40:00 and then it will register itself to IIO Jul 22 12:40:14 ZeekHuge: ok, sorry, I haven't been keeping up with your status as well as I could have Jul 22 12:41:17 so .. does that make sense ? what i said above ? Jul 22 12:42:25 ZeekHuge: a fifo could work. But what happens if userspace cannot keep up? My quick look at your code appears that you'll drop samples in the middle of the capture rather than evicting the oldest (or any other strategy) Jul 22 12:43:09 yes that is true. But as I will work further .. I will use ring buffer Jul 22 12:43:17 so that will do the task Jul 22 12:43:20 right > Jul 22 12:43:21 ? Jul 22 12:43:38 ZeekHuge: yes, some kind of circular buffer could evict the oldest easily Jul 22 12:43:51 but my question is ? is it okay to have a buffer inside a bus driver ? Jul 22 12:43:59 I mean what if i need only one data value ? Jul 22 12:44:26 since I am using a buffer , the single data will actually be stale and not the current value . Jul 22 12:45:01 ZeekHuge: can you have a way to evict all stale data? Jul 22 12:45:15 resetting the fifo ? Jul 22 12:45:24 but is it the way how it is done > Jul 22 12:45:25 ? Jul 22 12:46:42 ZeekHuge: I'm afraid you might be getting beyond my technical knowhow :( Jul 22 12:47:01 ahh .. okay. Jul 22 12:47:50 mdp, panto-cloud, m_w: any advice for ZeekHuge here ^^^^ Jul 22 12:48:47 ZeekHuge: iio subsystem should have the answer Jul 22 12:48:57 I think mranostay knows about the details Jul 22 12:49:11 who ? Jul 22 12:49:40 mranostay ? Jul 22 12:50:08 panto-cloud: ^^ Jul 22 12:50:34 ZeekHuge: /msg mranostay if you're not in a channel with him Jul 22 12:50:48 ZeekHuge: he may be traveling right now but he usually is pretty good about checking IRC Jul 22 12:51:07 ZeekHuge: he's on the west coast of the USA, so probably asleep right now still Jul 22 12:51:29 okay I am awake-ish Jul 22 12:51:39 whats the question? Jul 22 12:52:09 how should i accept the data from the PRUs in the driver i am developing Jul 22 12:52:28 SO .. there is a callback method that gets called each time PRU send some data Jul 22 12:52:50 Now, as of now, I am saving that data in a kfifo Jul 22 12:53:11 and that is how a character device implementation of rpmsg client driver does it Jul 22 12:53:15 ZeekHuge: err, what kind of device are we talking about? Jul 22 12:53:22 https://wiki.analog.com/software/linux/docs/iio/iio#iio_ring_bufferkfifo Jul 22 12:53:32 its not about IIO Jul 22 12:53:43 its about the bus driver implementation Jul 22 12:54:12 ZeekHuge: fill me in the details Jul 22 12:54:33 ahh .. Jul 22 12:54:51 Imagine I have a device connected to parallel bus. Jul 22 12:55:10 parallel bus is controlled by parallel bus driver Jul 22 12:55:35 someething like GPMC? Jul 22 12:55:59 now the device driver has registered itself on this bus . Jul 22 12:56:47 Now, my question is, how do I implement this bus driver using PRUs ? Jul 22 12:56:55 yes, somewhat like GPMC Jul 22 12:57:30 basically , this parallel bus driver is an rpmsg-client driver Jul 22 12:58:02 what is that device do? does it fall into any kind of already present device class? Jul 22 12:58:07 *what dos Jul 22 12:58:14 IIO Jul 22 12:58:22 its basically ADC Jul 22 12:59:03 now, whenever the PRUs send some data to this parallel_bus_Driver Jul 22 12:59:24 the callback method, defined inside the parallel)bus_driver gets called Jul 22 12:59:53 Now, I am using a buffer in this callback method to save data Jul 22 12:59:55 you need to interface then with the IIO subsystem Jul 22 13:00:10 you have to a way to do so with minimal overhead Jul 22 13:00:33 yeah .. so no buffer . right ? Jul 22 13:03:03 I'm not intimately familiar with the IIO subsystem Jul 22 13:03:31 in a nutshell you have to 'fake dma' directly from/to the IIO buffers Jul 22 13:04:10 like .. a similar question will be, does the SPI core subsystem has a buffer to save the data in it ? (assuming SPI core driver manages the bus and spidev is used for userspace interface) Jul 22 13:04:25 ZeekHuge: SPI core doesn't interface to IIO typically Jul 22 13:04:51 ??????? Jul 22 13:05:24 m_w: am I wrong? My uses of SPI via protocol drivers in-kernel don't deal with IIO, last I knew Jul 22 13:05:38 m_w:hi Michael I have a problem with DMA channel request. Jul 22 13:06:22 bradfa: https://docs.google.com/document/d/1GfnoWusWUeH2VsLbt1qJaRi20uNxCC8O_Xw1CHoGY9A/edit?usp=sharing Jul 22 13:06:26 bradfa: page 4 Jul 22 13:06:36 bradfa: I think I misunderstood your statement Jul 22 13:06:42 m_w:https://github.com/pmezydlo/SPI_slave_driver_implementation/blob/DMA_transfer/driver/spi-mcspi-slave.c#L677 Jul 22 13:06:55 pmezydlo: lemme take a look Jul 22 13:06:55 bradfa: see that diagram Jul 22 13:07:12 m_w: spidev is its own beast, on top of the SPI bus APIs, afaik Jul 22 13:07:25 bradfa: neither that paralle_bus is going to interface IIO. Jul 22 13:07:52 SPI : yes so I am asking about those SPI bus driver Jul 22 13:08:11 that parallel bus driver will be like an SPi or I2C bus .. Jul 22 13:08:42 bradfa: there are plenty of IIO drivers for SPI based devices Jul 22 13:08:55 ZeekHuge: iirc, a SPI bus driver does not buffer anything beyond the current transaction and even that uses memory which is handed to it by the caller Jul 22 13:09:30 m_w: I added if statement whether the get channel. And unfortunately it does not get Jul 22 13:10:05 pmezydlo: so you are not getting the DMA channel? Jul 22 13:10:13 no Jul 22 13:10:20 ZeekHuge: it seems like you have a lot of layers... Jul 22 13:10:30 ZeekHuge: do you need that many layers at this point? Jul 22 13:11:05 m_w: kernel version (uname -r) 4.4.8-ti-r22 Jul 22 13:11:10 well .. In my above statements I was talking about only one driver. Jul 22 13:11:25 so, no ... I am implementing all that in one Jul 22 13:11:28 for now Jul 22 13:12:18 pmezydlo: you may have to do it the old way Jul 22 13:12:37 http://lxr.free-electrons.com/source/drivers/spi/spi-omap2-mcspi.c#L1436 Jul 22 13:12:58 I thought so Jul 22 13:13:48 ok which version will be new dma? Jul 22 13:14:05 of the kernel? Jul 22 13:14:35 yes Jul 22 13:14:36 I can compile custom image Jul 22 13:15:56 it is very new Jul 22 13:16:27 I will do it the old way? Jul 22 13:16:54 sorry ^^ no a questions Jul 22 13:18:16 the latest is sitting in linux-next Jul 22 13:21:42 https://github.com/ZeekHuge/BeagleScope/blob/port_to_4.4.12-ti-r31%2B/driver/beaglescope_driver.c#L109 Jul 22 13:35:28 pmezydlo: if you use the 4.4 kernel use the old way Jul 22 13:39:40 ok no problem Jul 22 13:39:43 thanks Jul 22 16:05:01 ds2: there ? Jul 22 18:05:36 Abhishek_: you there ? Jul 22 18:06:51 Hi Jul 22 18:07:07 Hey ! Jul 22 18:07:25 I was trying to test the clock. Jul 22 18:07:39 I was actually using an arduino for it. Jul 22 18:08:07 using that common emitter Jul 22 18:08:11 mode. Jul 22 18:08:36 but, the clock for the board needs to be under 2.5V Jul 22 19:05:33 > Jul 22 19:13:48 translation: hmmmmm Jul 22 19:23:04 :) Jul 22 19:23:23 ZeekHuge: do you have access to a function generator? Jul 22 19:23:37 Or signal generator? Jul 22 19:24:10 If yes, try to calibrate it's Vpp using a scope and feed it in Jul 22 21:53:23 ds2: there ? Jul 22 22:14:20 hmmm quiet Jul 22 22:21:38 ahh still there ? Jul 22 22:21:41 ds2: ^^ Jul 22 22:22:02 okay I will put the question Jul 22 22:22:17 I was trying to get the ADC working Jul 22 22:22:46 this is the schematic : http://www.digikey.com/schemeit/project/newproject-2JAIU48200RG/ Jul 22 22:22:54 and? Jul 22 22:23:01 question is? Jul 22 22:23:08 I shunt the cap on the ADC Jul 22 22:23:36 but then the output of the clk driver circuit is not behaving as expected Jul 22 22:24:06 the output of the clk driver is about 2.5V when it is not connected to the ADC Jul 22 22:24:21 and is 0.5-0.7V when it is connected to ADC Jul 22 22:24:24 ds2: ^^ Jul 22 22:24:32 which cap? Jul 22 22:24:51 whoa Jul 22 22:24:52 C12 Jul 22 22:24:55 R2 Jul 22 22:24:57 just a sec Jul 22 22:24:58 do not use 10K Jul 22 22:25:19 the output impedence of an emitter follower is very roughly the value of Re Jul 22 22:25:25 schematic http://cds.linear.com/docs/en/demo-board-manual/dc782A.pdf Jul 22 22:25:39 try about 100ohm Jul 22 22:25:42 for R2 Jul 22 22:25:59 that should give you a very rough ball park in the same order as 50ohm Jul 22 22:28:00 okay .. just to add to this ... my initial circuit was without that R2 resistor. ie R2= infinity Jul 22 22:28:12 ZeekHuge: that won't work at all Jul 22 22:28:16 okay. Jul 22 22:28:33 ZeekHuge: it would be teh same as if you put the BB inline with a diode Jul 22 22:29:12 if you're still stuck, prehaps a quick 10min review of a common collector NPN transistor circuit is in order Jul 22 22:29:31 R2 acts as "negative" feedback. voltage gain is <~1 but you have current gain Jul 22 22:29:55 okay Jul 22 22:47:54 ds2, there? Jul 22 22:49:41 Can you take a look at the code I have written so far, its not complete. But if you could take a look at the transfer function? Jul 22 22:49:43 https://github.com/chanakya-vc/PRU-I2C_SPI_master/blob/wip_on_spi/SPI_Driver/pru0_spi-subsystem.c Jul 22 22:49:56 m_w, ^^ Jul 22 22:50:40 I have used ioremap to write the data to the shared memory of the pru. Jul 22 22:52:20 ioremap? Jul 22 22:52:32 I suppose that can work Jul 22 22:53:48 The exact logic is worked in the char driver that I wrote Jul 22 22:53:50 ds2 Jul 22 22:54:10 that wasn't my concern but for now, just leave it Jul 22 22:54:14 what's your question? Jul 22 22:54:52 I have already tested the method before. I am just not sure whether the way I am writing to tx_buf and rx_buf will work or not Jul 22 22:55:38 ds2 Also I am picking up mosi and miso from two different 8 bit memory locations Jul 22 22:56:04 Will that be a problem. Because theoritically SPI should have only one register Jul 22 22:56:37 should be fine Jul 22 22:56:55 as long as your firmware handles it Jul 22 22:57:09 if it was pure HW - you can use RD and WR strobe to map to differnet locations Jul 22 22:57:55 Okay ds2. Also I am not able to understand how to set the CS from here Jul 22 22:58:15 from "WHERE"? Jul 22 22:58:20 Like I am a bit confused how CS is actually set Jul 22 22:58:22 The driver Jul 22 22:58:41 I think the protocol driver would tell the controller Jul 22 22:58:42 it is up to you - for an initial pass, I'd recommend: Jul 22 22:58:57 have the firmware do it Jul 22 22:59:14 the firmware can assert /CS before sending a block and deassert it when it is done Jul 22 22:59:24 the driver doesn't need to do it Jul 22 22:59:37 Okay ds2. Got it. Jul 22 23:00:31 I was actually getting confused by this function:http://lxr.free-electrons.com/source/drivers/spi/spi-omap2-mcspi.c#L247 Jul 22 23:00:42 ds2, It is setting the CS for mcspi i guess Jul 22 23:01:43 that is an extra feature Jul 22 23:02:01 by default, /CS is driven by McSPI but there are a limited number of them Jul 22 23:02:11 there is an extra feature to let you have more /CS's driven by GPIOs Jul 22 23:02:15 you can ignore that feature for now Jul 22 23:03:26 Okay ds2, another doubt I am not able to understand the function, prepare_message() Jul 22 23:03:28 http://lxr.free-electrons.com/source/drivers/spi/spi-omap2-mcspi.c#L1222 Jul 22 23:03:48 What is this Force bit it keeps talking about? Jul 22 23:04:16 let me look Jul 22 23:05:10 it looks like it is trying to override the default handling of /CS Jul 22 23:05:28 for some devices, /CS needs to be constantly asserted Jul 22 23:05:40 for your stuff, I would suggest dropping that functionality out for now Jul 22 23:06:40 Okay ds2 Jul 22 23:08:00 I guess I donot require any other function in my driver for the basic needs. I just need to complete my probe function. Jul 22 23:08:22 think that's right Jul 22 23:09:02 So all my SPI driver does now is allows the spi core to call transfer_one function and write to the memory locations Jul 22 23:09:49 ds2, Just one more question is how do I send in parameters(CPOL and CPHA) from the userland? Jul 22 23:10:33 I am not sure which function in spi core allows to send in parameters ds? Jul 22 23:11:49 *ds2 Jul 23 00:07:18 chanakya_vc: from userland? the spidev IOCTL do that **** ENDING LOGGING AT Sat Jul 23 02:59:58 2016