Re: [spi-devel-general] [PATCH v1 3/4] max3100: adds console support for MAX3100
On Tue, Mar 30, 2010 at 4:14 AM, Feng Tang feng.t...@intel.com wrote: On Mon, 29 Mar 2010 20:55:51 +0800 DW controller driver don't need max3110 driver to use big spi transfer, the early version of our max3110 is also one word per spi transfer mode, and the 2 drivers work fine, though the rx performance is not good (copy paste a bulk message to console). What I'm saying is that the reason of bad performance is that the underlying SPI driver has bad performance. A SPI master driver should do as little work as possible. For small transfers (2 bytes == 16 bits) at 5MHz (== 3.2 us) it's much better to spin in spi_transfer waiting for SPI done than scheduling anything or setting up a DMA transfer. Especially if you do *2* task schedule (spi_transfer queues a workqueue that schedules a tasklet) be prepared for *big* latency. I hope other people can comment on this if I'm saying something wrong. When the HW works at 230400 bps, when we copy bulk data to the console, max3110 will probably receive about 20K characters, so the time for handling each char is 50us. If you use one char per spi transfer, it will have to execute 20K spi_transfer in one second, and each need be done in 50us, in this 50us you'll have to deal with controller IRQ handler + spi system overhead + tty receiving overhead. Is it a little over-killing to use one char per spi transfer? while the HW does have a 8 words RX FIFO this is too hackish, max3100 wasn't conceived this way. Let me point some problems of such an approach: 1) latency on rx chars becomes very high because we can process incoming transfers only after a full 8 byte (or whatever the spi transfer dimension is). For a 9600 this is too much. 2) even worse is that we can do flow control decision only on such boundary. 3) this is not reliable: think of what happens if the actual SPI transfer speed we get will be slower that the one we requested. We won't be emptying the RX buffer fastly enough even if could. 4) for low speeds we are going to monopolize the SPI bus for ages. So I'm rather convinced that the SPI transfer has to happen as soon as possible at a SPI device driver level without any guess on how the data will be clocked out. I suggest you to improve the dw_spi driver for better performance. [[ ..00 iiuu eessoo 44rr11((eeggffnn--77 ggccvvrriinn11((bbnnuu1144bbnnuu [[ ..00 BBOO--8800 1100--8800 uuaall)) huh, here I'm seeing another kind of problem: the same char is repeated two times (for example BBOO is written instead of BIOS). I'm quite sure (but I will triple check shortly) the the console driver doesn't do this (it's quite an easy loop in max3100_console_work, I will check wit a printascii to another serial port what is sent). So I guess the problem can be in the SPI master driver: is it correctly handling the CS changes? Isn't it having problems with DMA for example (I always found DMA for small data transfer (such 2 bytes in this case) problematic (for example many platforms just do it on a 4 byte boundary))? Have you tested it with other devices? -- Christian Pellegrin, see http://www.evolware.org/chri/ Real Programmers don't play tennis, or any other sport which requires you to change clothes. Mountain climbing is OK, and Real Programmers wear their climbing boots to work in case a mountain should suddenly spring up in the middle of the computer room. -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ spi-devel-general mailing list spi-devel-general@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/spi-devel-general
Re: [spi-devel-general] [PATCH v1 3/4] max3100: adds console support for MAX3100
On Tue, 30 Mar 2010 14:49:57 +0800 christian pellegrin chrip...@fsfe.org wrote: On Tue, Mar 30, 2010 at 4:14 AM, Feng Tang feng.t...@intel.com wrote: On Mon, 29 Mar 2010 20:55:51 +0800 When the HW works at 230400 bps, when we copy bulk data to the console, max3110 will probably receive about 20K characters, so the time for handling each char is 50us. If you use one char per spi transfer, it will have to execute 20K spi_transfer in one second, and each need be done in 50us, in this 50us you'll have to deal with controller IRQ handler + spi system overhead + tty receiving overhead. Is it a little over-killing to use one char per spi transfer? while the HW does have a 8 words RX FIFO this is too hackish, max3100 wasn't conceived this way. Let me point some problems of such an approach: 1) latency on rx chars becomes very high because we can process incoming transfers only after a full 8 byte (or whatever the spi transfer dimension is). For a 9600 this is too much. 2) even worse is that we can do flow control decision only on such boundary. 3) this is not reliable: think of what happens if the actual SPI transfer speed we get will be slower that the one we requested. We won't be emptying the RX buffer fastly enough even if could. 4) for low speeds we are going to monopolize the SPI bus for ages. No words in my last email suggested to use dynamic SPI clock speed, I admited that method is brutal and not mature when my driver was reviewed. In early version of our 3110 driver, we don't use dynamic clock speed, but the maxim clock supports by 3110, while we still use 8 words buffer read for RX. Let me cut my question clear: why not use the 8 words RX HW fifo? For bulk RX in 230400 case, is 50us enough to handle controller IRQ + spi subsystem overhead + tty receive overhead for one char per spi transfer model? So I'm rather convinced that the SPI transfer has to happen as soon as possible at a SPI device driver level without any guess on how the data will be clocked out. I suggest you to improve the dw_spi driver for better performance. Will consider that, thanks [[ ..00 iiuu eessoo 44rr11((eeggffnn--77 ggccvvrriinn11((bbnnuu1144bbnnuu [[ ..00 BBOO--8800 1100--8800 uuaall)) huh, here I'm seeing another kind of problem: the same char is repeated two times (for example BBOO is written instead of BIOS). I'm quite sure (but I will triple check shortly) the the console driver doesn't do this (it's quite an easy loop in max3100_console_work, I will check wit a printascii to another serial port what is sent). So I guess the problem can be in the SPI master driver: is it correctly handling the CS changes? Isn't it having problems with DMA for example (I always found DMA for small data transfer (such 2 bytes in this case) problematic (for example many platforms just do it on a 4 byte boundary))? Have you tested it with other devices? Yes, the controller HW has a register to chose slave devices and thus the HW CS handling is transparent to software. The controller supports several slave devices connecting to it simultaneously, one is a 3G modem whose throughput is about several Mega bits. The current in-tree controller driver lacks DMA part, which is rejected as the related DMA controller driver never show up publicly. -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ spi-devel-general mailing list spi-devel-general@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/spi-devel-general
Re: [spi-devel-general] [PATCH v1 3/4] max3100: adds console support for MAX3100
On Tue, Mar 30, 2010 at 9:19 AM, Feng Tang feng.t...@intel.com wrote: No words in my last email suggested to use dynamic SPI clock speed, I admited that method is brutal and not mature when my driver was reviewed. In early version of our 3110 driver, we don't use dynamic clock speed, but the maxim clock supports by 3110, while we still use 8 words buffer read for RX. Let me cut my question clear: why not use the 8 words RX HW fifo? For bulk RX in 230400 case, is 50us enough to handle controller IRQ + spi subsystem overhead + tty receive overhead for one char per spi transfer model? For TX it's impossible. Before sending a char we have to check if T bit says that the TX buffer is empty. Otherwise if SPI bus speed UART baud rate we will loose TX chars for sure. For RX maybe it might be worth to always do 8 byte transfers and the look at R bit of transfer i to see if we have a valid char in (i+1) instead of doing single transfers. But here again we are fixing the insane latency per start of transfer of the underlying SPI master controller. And let me say that in the actual driver the 8 byte RX fifo *is* used: the loop in max3100_ist drains RX buffer at a speed greater than the chars coming (also at 115200). The 8-bytes RX buffer fills as a consequence of delays in interrupt thread being awaken. The tests I did with zmodem show that in the direction max3100 - PC has very good efficiency compared to max3100 - PC. I guess the reason is that the tx buffer is just 1 byte deep and we don't have any other way to handle the T bit other than the do loop in max3100_ist. Maybe I will try to do some instrumentation with systemtap to show this (it's always nice to find some uses for systemtap). Anyway I'm sure that it's always better to not loose chars being received than delaying transmitted one for a bit. -- Christian Pellegrin, see http://www.evolware.org/chri/ Real Programmers don't play tennis, or any other sport which requires you to change clothes. Mountain climbing is OK, and Real Programmers wear their climbing boots to work in case a mountain should suddenly spring up in the middle of the computer room. -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ spi-devel-general mailing list spi-devel-general@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/spi-devel-general
Re: [spi-devel-general] [PATCH v1 3/4] max3100: adds console support for MAX3100
1) latency on rx chars becomes very high because we can process incoming transfers only after a full 8 byte (or whatever the spi transfer dimension is). For a 9600 this is too much. There I would partly disagree. Fixing the spi driver clearly makes sense but the serial driver should be batching better. Is there a reason the driver couldn't adjust the size based upon the tty speed when getting a termios request ? 2) even worse is that we can do flow control decision only on such boundary. For serial flow control it doesn't matter, its implicitly asynchronous and if you only turn the fifo on at high speed you response time will be reasonably bounded. 3) this is not reliable: think of what happens if the actual SPI transfer speed we get will be slower that the one we requested. We won't be emptying the RX buffer fastly enough even if could. Consoles are not usually balanced for I/O. I grant you probably don't want to be using full fifo sized blocks but I'm not sure I understand why there is a problem below that ? Alan -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ spi-devel-general mailing list spi-devel-general@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/spi-devel-general
Re: [spi-devel-general] [PATCH 0/5] ARM: PrimeCell DMA patches v4
[Self] This is a fourth iteration of the PrimeCell DMA API on top of the generic DMA devices (sibling to the DMA engine). It's based on the suggestion from Russell to try and define a specific extension subset for DMA devices. Russell Grant can you give some hint on the direction you see for this patch set? The problem we're facing is that next I will start adding DMA support for the U8500 and the MMCI derivate found in that platform doesn't *have* a PIO IRQ, which means the system cannot even boot without some solid DMA framework in place. (It is currently unbootable from the released kernels.) So unless there is some outstanding issue with this approach we pretty much need this now to keep working on mainlining the U8500. I would very much like to have the DMA patches for PrimeCell support pushed through Dan's tree, but that requires your ACKs of course, and it will inevitably collide with other PrimeCell patches for the next merge window (many submitted by myself admittedly). I can feed all the PrimeCell stuff to Dan if all agree that this is a good approach. Another approach is to apply the latest patches from Dan's tree to ARM and SPI alike and then feed the PrimeCell stuff through the ARM tree. Yours, Linus Walleij -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ spi-devel-general mailing list spi-devel-general@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/spi-devel-general
Re: [spi-devel-general] [PATCH v1 3/4] max3100: adds console support for MAX3100
On Tue, Mar 30, 2010 at 10:46 AM, Alan Cox a...@lxorguk.ukuu.org.uk wrote: There I would partly disagree. Fixing the spi driver clearly makes sense but the serial driver should be batching better. Is there a reason the driver couldn't adjust the size based upon the tty speed when getting a termios request ? Just a small note for those who don't know max31x0. There are just 2 instructions to tx/rx data: simple data rx (in which we read one data from the fifo (the data is valid if R status bit is set), control lines (CTS) and status bits) and a combined tx/rx (like before but we also send one byte (if the T status bit the char will be accepted) and set control lines (RTS)). Every of these instructions is 2 bytes long. It's a full SPI message (so you have to assert CS before and de-assert it afterwards to make it work). TX buffer is just 1 byte deep, RX one is 8 bytes. Unfortunately we cannot batch TX if SPI speed (in chars going in / time unit) is higher than the baud rate of serial communication. We need to check that T bis is asserted before sending a char, otherwise it is lost. For low baud rates doing this means monopolizing the bus. And there is a subtle problem if we reduce SPI speed to the UART baud rate: we can ask only for a maximum speed on the SPI. In case this is lower the one we asked (maybe because of SPI clock divisors) and we do a TX batch big enough we could not be emptying the RX FIFO fast enough and so we risk to loose chars in a full duplex operation (*). We could do batch RX operation but perhaps we are just transferring bytes for nothing because we don't know in advance if the R bit is set. And we cannot interleave TX and RX like current drivers do because we are forced to use the simple rx operation and not the combined rx/tx. There's another point about batching: single instructions are complete SPI messages. Many SPI master drivers I worked with (S3C24xx, AT91 because of a bug in the hardware) manage CS as a normal gpio. Another problem here is that many devices require a configurable delay on CS change (see delay_usecs field of spi_transfer) which is not handle by hardware and so the drivers must somehow break a SPI messages in single transfers and do something at the end of every one of these. So even we batch 10 tx/rx instructions I really don't think many SPI master controllers will be able to do a DMA of 20 bytes. Anyway I agree that if we find a way of doing batching it's a good thing because better controllers can benefit. 2) even worse is that we can do flow control decision only on such boundary. For serial flow control it doesn't matter, its implicitly asynchronous and if you only turn the fifo on at high speed you response time will be reasonably bounded. if we somehow manage to batch a TX of n bytes and after the first one CTS changes we are going to send n-1 chars anyway. OK, maybe our peer de-asserted CTS when still having n-1 byes of buffer free and somehow higher layer protocols will recover. So I agree this could be not so worrisome. But we should keep n small enough. 3) this is not reliable: think of what happens if the actual SPI transfer speed we get will be slower that the one we requested. We won't be emptying the RX buffer fastly enough even if could. Consoles are not usually balanced for I/O. I grant you probably don't want to be using full fifo sized blocks but I'm not sure I understand why there is a problem below that ? My concern is expressed above (*). Perhaps it's me missing some point. To make it clear: I'm more than happy to test a driver that takes another approach and switch to it if it's better (but it has to have support of multiple instances and a fair usage of SPI bandwidth at least). But I really don't see a reliable way of adding batching of tx/rx. And I think it will be better to provide a patch to the current driver than to rewrite it completely. -- Christian Pellegrin, see http://www.evolware.org/chri/ Real Programmers don't play tennis, or any other sport which requires you to change clothes. Mountain climbing is OK, and Real Programmers wear their climbing boots to work in case a mountain should suddenly spring up in the middle of the computer room. -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ spi-devel-general mailing list spi-devel-general@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/spi-devel-general
[spi-devel-general] Риски и ошибк и при дроблении бизнес а
ДРОБЛЕНИЕ БИЗНЕСА: РИСКИ И ОШИБКИ. Применение льготных режимов налогообложения для налогового планирования. * 08 апреля | Москва * В программе: 1. Вывод сотрудников. Аутсорсинг. Способы разделения организации. 2. Разбор действенных легенд в обоснование дробления бизнеса (на основе практики, решений судов). 3. Переквалификация аутсорсинга, возмездного оказания услуг в трудовые отношения. 4. Основания завышения стоимости работ, услуг, получаемых от вновь созданного предприятия. 5. Разбор способа позволяющего защититься от претензий по трансфертному ценообразованию и признанию лиц недобросовестными. 6. Защита от показаний/шантажа сотрудников. 7. Обход пределов применения УСН с использованием договора простого товарищества. 8. Получение компаниями НДС при оплате работ/услуг аутсорсера на УСН. Риски и способы защиты. 9. Потеря документов, как способ максимальной защиты от возможных претензий контролирующих органов. 10. Анализ лимита выручки при применении УСН. 11. Фактическое нахождение юридического лица не по месту регистрации, либо наличие обособленных подразделений по ст. 55 ГК РФ как основание утраты права на применение УСН. 12. Сокрытие афиллированности: использование доверенных лиц, оффшоров, некоммерческих организаций. 13. Передача имущества при дроблении: реорганизация, взнос в уставный капитал, займы и т.п. Судебная практика. 14. Способы контроля доверенных лиц как элемент безопасности активов. 15. Способы управления группой компаний. 16. Презумпция недобросовестности. Проект Постановления ВАС о недобросовестности. 17. Рассмотрение методичек Минфина (ДСП) о выявлении и предъявлении претензий к компаниям, осуществившим дробление своей структуры. * Стоимость участия: 8000 рублей. Место проведения: м. Бауманская, ул. Бауманская, д.6, бизнес центр Виктория Плаза. В стоимость входит методический материал, обеды, кофе-паузы, сертификат. * Информация и регистрация: 8 (495) 921-30-17 * -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ spi-devel-general mailing list spi-devel-general@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/spi-devel-general
[spi-devel-general] Profitez de 2 mois offerts sur votre assurance sante
-- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ spi-devel-general mailing list spi-devel-general@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/spi-devel-general
