CINXE.COM

LKML: Vitaly Wool: Re: [PATCH 2.6-git] MTD/SPI dataflash driver

<?xml version="1.0" encoding="UTF-8" standalone="yes"?> <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"><html xmlns="http://www.w3.org/1999/xhtml"><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /><title>LKML: Vitaly Wool: Re: [PATCH 2.6-git] MTD/SPI dataflash driver</title><link href="/css/message.css" rel="stylesheet" type="text/css" /><link href="/css/wrap.css" rel="alternate stylesheet" type="text/css" title="wrap" /><link href="/css/nowrap.css" rel="stylesheet" type="text/css" title="nowrap" /><link href="/favicon.ico" rel="shortcut icon" /><script src="/js/simple-calendar.js" type="text/javascript"></script><script src="/js/styleswitcher.js" type="text/javascript"></script><link rel="alternate" type="application/rss+xml" title="lkml.org : last 100 messages" href="/rss.php" /><link rel="alternate" type="application/rss+xml" title="lkml.org : last messages by Vitaly Wool" href="/groupie.php?aid=29396" /><!--Matomo--><script> var _paq = window._paq = window._paq || []; /* tracker methods like "setCustomDimension" should be called before "trackPageView" */ _paq.push(["setDoNotTrack", true]); _paq.push(["disableCookies"]); _paq.push(['trackPageView']); _paq.push(['enableLinkTracking']); (function() { var u="//m.lkml.org/"; _paq.push(['setTrackerUrl', u+'matomo.php']); _paq.push(['setSiteId', '1']); var d=document, g=d.createElement('script'), s=d.getElementsByTagName('script')[0]; g.async=true; g.src=u+'matomo.js'; s.parentNode.insertBefore(g,s); })(); </script><!--End Matomo Code--></head><body onload="es.jasper.simpleCalendar.init();" itemscope="itemscope" itemtype="http://schema.org/BlogPosting"><table border="0" cellpadding="0" cellspacing="0"><tr><td width="180" align="center"><a href="/"><img style="border:0;width:135px;height:32px" src="/images/toprowlk.gif" alt="lkml.org" /></a></td><td width="32">聽</td><td class="nb"><div><a class="nb" href="/lkml"> [lkml]</a> 聽 <a class="nb" href="/lkml/2005"> [2005]</a> 聽 <a class="nb" href="/lkml/2005/12"> [Dec]</a> 聽 <a class="nb" href="/lkml/2005/12/2"> [2]</a> 聽 <a class="nb" href="/lkml/last100"> [last100]</a> 聽 <a href="/rss.php"><img src="/images/rss-or.gif" border="0" alt="RSS Feed" /></a></div><div>Views: <a href="#" class="nowrap" onclick="setActiveStyleSheet('wrap');return false;">[wrap]</a><a href="#" class="wrap" onclick="setActiveStyleSheet('nowrap');return false;">[no wrap]</a> 聽 <a class="nb" href="/lkml/mheaders/2005/12/2/4" onclick="this.href='/lkml/headers'+'/2005/12/2/4';">[headers]</a>聽 <a href="/lkml/bounce/2005/12/2/4">[forward]</a>聽 </div></td><td width="32">聽</td></tr><tr><td valign="top"><div class="es-jasper-simpleCalendar" baseurl="/lkml/"></div><div class="threadlist">Messages in this thread</div><ul class="threadlist"><li class="root"><a href="/lkml/2005/12/1/139">First message in thread</a></li><li><a href="/lkml/2005/12/1/141">Vitaly Wool</a><ul><li><a href="/lkml/2005/12/1/187">David Brownell</a><ul><li class="origin"><a href="/lkml/2005/12/2/148">Vitaly Wool</a><ul><li><a href="/lkml/2005/12/2/148">David Brownell</a></li></ul></li></ul></li></ul></li></ul></td><td width="32" rowspan="2" class="c" valign="top"><img src="/images/icornerl.gif" width="32" height="32" alt="/" /></td><td class="c" rowspan="2" valign="top" style="padding-top: 1em"><table><tr><td><table><tr><td class="lp">Date</td><td class="rp" itemprop="datePublished">Fri, 02 Dec 2005 09:01:52 +0300</td></tr><tr><td class="lp">From</td><td class="rp" itemprop="author">Vitaly Wool &lt;&gt;</td></tr><tr><td class="lp">Subject</td><td class="rp" itemprop="name">Re: [PATCH 2.6-git] MTD/SPI dataflash driver</td></tr></table></td><td></td></tr></table><pre itemprop="articleBody">David Brownell wrote:<br /><br />&gt;On Thursday 01 December 2005 8:18 am, Vitaly Wool wrote:<br />&gt; <br />&gt; <br />&gt;<br />&gt;&gt;It took about fifteen minutes of mindwork to port the MTD dataflash driver<br />&gt;&gt;posted by David Brownell 11/23 to our SPI core from David's,<br />&gt;&gt; <br />&gt;&gt;<br />&gt;<br />&gt;Interesting and informative; +1!<br />&gt;<br />&gt;Did you have a chance to test this? There are some post-2.6.15-rc3-mm1<br />&gt;updates to this code, mostly to catch startup fauults better but also to<br />&gt;hotplug reasonably. The glitches I saw may as easily be JFFS2 integration<br />&gt;issues for the DataFlash code as bitbang adapter problems. (I think you<br />&gt;started more or less from what's in rc3-mm1.)<br />&gt;<br />&gt; <br />&gt;<br />Very basically. I've make a note that it was a mindwork.I also didn't <br />make the attempt to make it a clean MTD driver.<br />However, it would be nice if someone compared the performance of both <br />variants.<br /><br />&gt; <br />&gt;<br />&gt;&gt;reducing both <br />&gt;&gt;the size of the source code and the footprint of the object code.<br />&gt;&gt;I'd also like to mention that now it looks significatnly easier to understand<br />&gt;&gt;due to no more use of complicated SPI message structures. The number of variables<br />&gt;&gt;used was also decreased<br />&gt;&gt; <br />&gt;&gt;<br />&gt;<br />&gt;I think that's all the same issue. Other than "spi_driver" replacing<br />&gt;"device_driver" (I'd like to see a patch doing that to rc3-mm1), the<br />&gt;main changes seem to be:<br />&gt;<br />&gt; - Move from original atomic requests like this<br />&gt;<br />&gt; { write command, read response }<br />&gt;<br />&gt; over to two separate requests<br />&gt;<br />&gt; { write command, and leave CS active }<br />&gt; { read response, and leave CS off }<br />&gt;<br />&gt; - Lower the per-request performance ceiling on this driver<br />&gt;<br />&gt; * original code could be implemented in a single DMA chain on<br />&gt; at least two systems I happen to have handy ... one IRQ.<br />&gt; <br />&gt;<br />Whoops. Lemme express my thoughts here.<br />First, the DMA controller that can handle chained requests which are <br />working with different devices (i.e. write then read does that - first <br />mem2per, then per2mem) are *very* rare thing.<br />Then, what _really_ can happen in a single DMA chain? 99,9999% cases of <br />such will be "read x bytes to get aware of the length of the packet, <br />then read the data packet". Here you won't have any noticable <br />performance gain as the first transfer is to small. It's soooo small <br />that the overhead of having a linked list for DMA will probably be <br />bigger than that of having two transfers. A smart controller driver may <br />even want to have a PIO read on first x bytes (as x will be equal to 2 <br />or 4, I guess :)<br /><br />&gt; * this version requires two separate chains, with an intervening<br />&gt; task schedule. (More than twice the cost.)<br />&gt; <br />&gt;<br />See above.<br /><br />&gt; * in your framework I still can't be _sure_ it never does memcpy<br />&gt; for those buffers (the last version I looked at did so). the<br />&gt; original code just used normal DMA models, so it "obviously"<br />&gt; doesn't risk memcpy.<br />&gt; <br />&gt;<br />You can be sure if you set SPI_M_DNA flag. I'll update the Doc accordingly.<br /><br />&gt; - I might agree with this being "easier to understand" code, though<br />&gt; it's debatable. (The device sees one transaction, why should the<br />&gt; driver writer have to split it up into two?) But that doesn't<br />&gt; matter much: filesystems are better with "faster to run" code.<br />&gt; <br />&gt;<br />Your clains that the originl code is faster are arguable.<br /><br />&gt; - Chipselect works differently in your code. You're giving one<br />&gt; driver control over all the devices sharing a controller, by<br />&gt; blocking requests going to other devices until your driver yields<br />&gt; the chipselect. <br />&gt; <br />&gt;<br />The controllers we were working with are _not_ able to handle <br />simultaneous requests to different devices on the same bus.<br />Can you please tell me what specific controller you're referring to?<br /><br />&gt;So the way I see it, this is a good example of why my original I/O model<br />&gt;is better. It provides _flexibility_ in the API so that some drivers<br />&gt;can be really smart, if they want to. You haven't liked the consequence<br />&gt;of that though: controller drivers being able to choose how they<br />&gt;represent and manage I/O queues, rather than doing that in your "core".<br />&gt;<br />&gt; <br />&gt;<br />Not that I agreed to your vision, for the reasons listed above. ;-)<br /><br />Vitaly<br />-<br />To unsubscribe from this list: send the line "unsubscribe linux-kernel" in<br />the body of a message to majordomo&#64;vger.kernel.org<br />More majordomo info at <a href="http://vger.kernel.org/majordomo-info.html">http://vger.kernel.org/majordomo-info.html</a><br />Please read the FAQ at <a href="http://www.tux.org/lkml/">http://www.tux.org/lkml/</a><br /><br /></pre></td><td width="32" rowspan="2" class="c" valign="top"><img src="/images/icornerr.gif" width="32" height="32" alt="\" /></td></tr><tr><td align="right" valign="bottom"> 聽 </td></tr><tr><td align="right" valign="bottom">聽</td><td class="c" valign="bottom" style="padding-bottom: 0px"><img src="/images/bcornerl.gif" width="32" height="32" alt="\" /></td><td class="c">聽</td><td class="c" valign="bottom" style="padding-bottom: 0px"><img src="/images/bcornerr.gif" width="32" height="32" alt="/" /></td></tr><tr><td align="right" valign="top" colspan="2"> 聽 </td><td class="lm">Last update: 2005-12-02 07:05 聽聽 [from the cache]<br />漏2003-2020 <a href="http://blog.jasper.es/"><span itemprop="editor">Jasper Spaans</span></a>|hosted at <a href="https://www.digitalocean.com/?refcode=9a8e99d24cf9">Digital Ocean</a> and my Meterkast|<a href="http://blog.jasper.es/categories.html#lkml-ref">Read the blog</a></td><td>聽</td></tr></table><script language="javascript" src="/js/styleswitcher.js" type="text/javascript"></script></body></html>

Pages: 1 2 3 4 5 6 7 8 9 10