Re: [PATCH 00/49] spi: davinci: re-write existing driver, DM355 DMA problem
Hi, I have tested the new driver using DMA mode on our custom DM355 board. I replaced the linux 2.6.32 spi driver by this driver and it seemed to work except for on point. The dm355 spi polling mode was correctly working but the DMA mode was causing some communication problems. It appeared that when dm355 was reading on the spi, it was actually resending received data to our slave device on the spi bus, i didn't fully checked what i am saying i am just supposing that it's what occured. Anyway the behaviour was different in DMA and polling mode. I didn't dig deep into the driver i just solved the problem (quick and dirty) by setting tx buffer to zero in the spidev driver. The problem can be caused by using SPIDAT as dma buffer when the tx buffer is empty. (If it helps i have tested before the spi patch V5 from Brian Niebuhr and the problem was already there) So is this a bug or a feature ? I don't have time right know to work on that problem but i can test solutions if anyone have. Regards. Pierre ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: [PATCH 00/49] spi: davinci: re-write existing driver, DM355 DMA problem
I took the tree version of the davinci_spi.c file after every patches have been applied ( the 49 spi patches ). I tested with the csbug on and off before and if i remember well, it was not working. I'll try again as soon as i have time. The weird thing is that the problem doesn't occur at each transfer. The details of what i noticed is: -Chipselect to the client is a GPIO, chip_sel array is a 1 byte array containing the gpio pin. -The DM355 application uses spidev char driver to read and write data to spidev0.0 -When dm355 was reading a 16 bytes buffer, the client sent the data correctly but afterwards it received a byte : the 15th byte of the sent buffer. -When I added to spidev_sync_read a tx zeroed buffer everything worked perfectly. (-The problem was there even if cshold_bug was true, but i'll check that again) -The spi was correctly working in polling mode. Pierre Le 11/23/2010 01:32 PM, Nori, Sekhar a écrit : Hi Pierre, On Tue, Nov 23, 2010 at 16:43:27, Pierre wrote: Hi, I have tested the new driver using DMA mode on our custom DM355 board. I replaced the linux 2.6.32 spi driver by this driver and it seemed to work except for on point. The dm355 spi polling mode was correctly working but the DMA mode was causing some communication problems. It appeared that when dm355 was reading on the spi, it was actually resending received data to our slave device on the spi bus, i didn't Hmm, didn't really see this before. fully checked what i am saying i am just supposing that it's what occured. Anyway the behaviour was different in DMA and polling mode. I While working on the patches I noticed that DM355 has an errata regarding behavior of CSHOLD. In the patches, I take care of it by having DM355 define cshold_bug to true. Can you please make sure you have taken care of this as well while porting to 2.6.32? http://linux.davincidsp.com/pipermail/davinci-linux-open-source/2010-November/021045.html didn't dig deep into the driver i just solved the problem (quick and dirty) by setting tx buffer to zero in the spidev driver. The problem can be caused by using SPIDAT as dma buffer when the tx buffer is empty. (If it helps i have tested before the spi patch V5 from Brian Niebuhr and the problem was already there) How about with Brian's patch applied? Thanks, Sekhar ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: [PATCH 00/49] spi: davinci: re-write existing driver, DM355 DMAproblem
You are correctly understanding my problem. Ok, So spidev should specify the out buffer in case of a read or the application should specify the out buffer. By the way, thanks for this new driver that is fully satisfying. Regards Le 11/23/2010 03:47 PM, Brian Niebuhr a écrit : -Original Message- From: davinci-linux-open-source-boun...@linux.davincidsp.com [mailto:davinci-linux-open-source-boun...@linux.davincidsp.com] On Behalf Of Pierre Sent: Tuesday, November 23, 2010 5:13 AM To: davinci-linux-open-source@linux.davincidsp.com Subject: Re: [PATCH 00/49] spi: davinci: re-write existing driver, DM355 DMAproblem Hi, I have tested the new driver using DMA mode on our custom DM355 board. I replaced the linux 2.6.32 spi driver by this driver and it seemed to work except for on point. The dm355 spi polling mode was correctly working but the DMA mode was causing some communication problems. It appeared that when dm355 was reading on the spi, it was actually resending received data to our slave device on the spi bus, i didn't fully checked what i am saying i am just supposing that it's what occured. If I understand you correctly, what you are saying is that when you are trying to read data from your SPI device, the data on the DM355 output signal (MOSI) is not what you expected, and is causing issues. If that is the case, I can say that I made no effort to make sure that the inactive portion of a half-duplex SPI transfer had any particular data pattern. In other words, if you have been getting a certain pattern of outbound data it is purely coincidence, and the different implementations of polled and DMA mode expose the fact that you had been getting lucky. I am not a SPI expert by any means, but it has been my approach that SPI is a full-duplex protocol and you need to specify outbound data if you want certain outbound data sent. As it turns out, most SPI devices have a protocol for determining when they are supposed to be sending or receiving, and if the device is sending it usually ignores whatever it is receiving. You mention in your later email that using a zeroed Tx buffer makes everything work OK. I think that's actually the most correct solution. The driver could be modified to ensure that it transmits zeros on a half-duplex read, and maybe it should, but I think the best solution is for the application to specify what it wants to be sent and not rely on non-portable behavior from a driver. If I'm misunderstanding the problem, then just ignore all of the above :-) Anyway the behaviour was different in DMA and polling mode. I didn't dig deep into the driver i just solved the problem (quick and dirty) by setting tx buffer to zero in the spidev driver. The problem can be caused by using SPIDAT as dma buffer when the tx buffer is empty. (If it helps i have tested before the spi patch V5 from Brian Niebuhr and the problem was already there) So is this a bug or a feature ? I don't have time right know to work on that problem but i can test solutions if anyone have. Regards. Pierre ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Linux Usb key and Fat buffer.
www.imajing.frHi all, I am wondering how writing to an USB key formated as FAT32 filesystem is handle by linux ( we are using linux 2.6.18 on a dm355 ). We have our embedded system that is logging binary data from different sensors, and images, our total number of files open is around 7. We have 6 files opened for writing small chunks of data (total of small chunk bitrate 8k per second ) and an avi files that we are using as a container for 5Mpx jpeg images (500k) at 5fps. When we test the key's performance we have 7MB per second (writing 100 chunks of 500k data) so the performance of the key should be enough for storing our data. The problem is that we are expriencing a peridodic slow down of the writing speed of the images. We have not mounted the key as physically synchronised. My question is : - How is handled the writing buffer to usb key ? - What is the buffer size when writing to fat ? (I didn't find an option for that in the mount option) - Should i use in my application a fifo buffer for writing data to avoid the slow down? Thanks. ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Previewer driver issues
Hi everybody, i have interface a CMOS Raw Bayer sensor with a DVEVM. I'm able to store correctly datas send by sensor in RAM with CCDC. But now i want to use previewer to convert Raw bayer vidéo in YUV 4:2:2 in order to obtain a video flow working on an encode demos-like application. To do this, i used sources and documents for LSP 1.20 DaVinci Linux previewer driver. And i am experiencing 2 problems. First, outbuf is strange. Of course, it has the good size but it seems to be overlap by other datas ( executable if we read those datas with hexedit ). A solution consists in not allocate buffer with previewer driver but use a buffer created by another module ( like codec engine ... ) Then, the previewer driver crash after encoding a random number fo frames ( generally about 25-30 ). His busy flag is always 1 and never goes down ... Do you already used previewer driver correctly ? And do you already have some datas overlapping or crash problems ? Regards. Pierre Emmanuel ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Color issue when interfacing a CMOS sensor
Hello, I try to interface a CMOS sensor on the DVEVM 6446. The sensor is an STMIcroelectronics sensor and his ISP ( STV0984 ). The ISP send to the CCDC a YUV 422 (ITU-601) video. I already have re configure the TVP5146 to send ITU 601 video, so the transmission of this format seems to be OK. The only modification i have made is to set the format in progressive. In order to validate the correct interfacing. I use an encode demo modified to directly save them to the HDD and to display it on the screen. My actual problem is that the colorspace seems to be completely fool. In fact, i obtain a video completely green ... If i modify the polarity of datas, i have a video pink and blue ( i think it's normal because of the complementary colors ). I don't know what i can modify to correct colors. Do you already have experienced this problem ? Thanks for your help. Pierre - Emmanuel GAILLARDON ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
TVP5146, DVEVM and ITU601
Hi everybody, i am trying to use the DVEVM input in ITU601, so on 8 bits with separate sync signals HD et VD. I have modified the Davinci_vpfe.c : bt656_enable = FALSE, ( for ccdc ) enablebt656sync = FALSE, ( for tvp ) If i scope my signals at the input of the Davini, they seems to be OK. Effectively, synchro and timings are good. But i have no video in my application. I had correct video in 656 mode, just before the change of the davinci_vpfe.c. Do you already have interface correctly the TVP5146 with the 6446 in 8 bits, separate sync ? Regards. Pierre - Emmanuel ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
PWM1 TI driver
The TI driver is in public domain i think. The source code is available with the DVEVM montavista linux. The solution concerning the TI driver is that it works throw pointers. When you make an ioctl on it, you have to pass pointer for your args. Thanks for your help ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
PWM1 TI driver
Hello, I tried to use the PWM1 TI driver to access the PWM1 of the DaVinci6446 with the TI kernel but it doesn't work properly. Here is some lines of the code where I configure the PWM driver via the ioctrl function : #define PWM1_DEVICE /dev/davinci_pwm1 lightlib_pwm1_device = open(PWM1_DEVICE, O_RDWR) ioctl(lightlib_pwm1_device, PWMIOC_SET_FIRST_PHASE_STATE, 0x0001) ioctl(lightlib_pwm1_device, PWMIOC_SET_INACT_OUT_STATE, 0x0001) ioctl(lightlib_pwm1_device, PWMIOC_SET_MODE, 1) ioctl(lightlib_pwm1_device, PWMIOC_SET_RPT_VAL, 0x) ioctl(lightlib_pwm1_device, PWMIOC_SET_PERIOD, 0x2000) ioctl(lightlib_pwm1_device, PWMIOC_SET_DURATION, 0x1000) ioctl(lightlib_pwm1_device, PWMIOC_START, 1) With this configuration, the PWM remains on the low level I noticed that the PWM goes High only when ioctl(lightlib_pwm1_device, PWMIOC_SET_PERIOD, 0x8000) ioctl(lightlib_pwm1_device, PWMIOC_SET_DURATION, 0x4000) but here it does act like a PWM, but more like a I/O. Has someone already used the TI PWM Drivers ? Do you have any idea ??? Thank you Thomas ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
MJPEG codec - only 14 bytes after encoding ...
Hi everybody, I am using the TI evaluation JPEG codec and having a problem when i try to encode. The app code is an encode demo modified. Actually, the first frame encoded by jpegenc is correct but after that all frames encoded are only 14 bytes in size. Frames in input are corrects. It appears that the IMGENC_process() will only encode the first frame that is sent to it. The only solution i have actually found is to delete the encoder and to recreate it after each frames. Do you already had this problem ? Thanks, Pierre ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
