From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <4CD74149.70406@gmx.net> Date: Mon, 8 Nov 2010 01:16:09 +0100 From: Carl-Daniel Hailfinger User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.23) Gecko/20090410 SUSE/1.1.18-0.1 SeaMonkey/1.1.18 MIME-Version: 1.0 To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> References: <4CD5F934.2080705@gmx.net> <4CD69C49.5090209@gmx.net> <9f6f706b0da2fc0b208ad49c097a823b@brasstown.quanstro.net> <4CD6D235.3030704@gmx.net> <1ab89ced7625309d8c289292c4a4086c@brasstown.quanstro.net> <4CD6FFD4.9040502@gmx.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [9fans] pcc limitation? Topicbox-Message-UUID: 78ee3084-ead6-11e9-9d60-3106f5b1d025 On 07.11.2010 20:42, erik quanstrom wrote: >> In practice: >> Right now (with incomplete support for some chips): >> writearr: 260 bytes >> readarr: 16777217 bytes >> >> In the near future (maybe 2 weeks from now): >> writearr: 1056 bytes >> readarr: 16777217 bytes >> > > so you're saying that you have > 16777217 bytes of spi data for a single > command in your program? You asked for "the largest sequence of commands in practice". That's why I assumed you wanted to know about the largest command in all environments. > i think i'm missing something. you couldn't > fit that much data in 32kb of ram. > Correct. Please see the following quote from my mail: >> we determine readarr size at runtime based on resource constraints. In hosted environments with sufficient resources (e.g. Plan 9), the largest command response can indeed be ~16 MBytes. In resource-constrained environments we limit command+response size to 260 bytes or even less. And depending on the programmer hardware, there may be additional constraints (e.g. commands having exactly 1,2,4 or 5 bytes and no other lengths) regardless of available resources. If you want to take a look at the context of the code which prompted this mail thread, please see http://www.flashrom.org/trac/flashrom/browser/trunk/spi25.c#L594 spi_chip_erase_c7, spi_block_erase_52 and spi_nbyte_program all use the spi_send_multicommand interface which takes an array of struct spi_command as parameter (submission of multiple commands at once). spi_nbyte_read uses the spi_send_command interface which takes the individual members of struct spi_command as parameters (submission of a single command). We would love to use a common interface for command submission regardless of the number of commands being sent (and we had such an interface in the past), but sadly some supported hardware enforces combined commands and other hardware enforces separate commands. The individual programmer drivers take care of translating the requests to the format usable by the programmer hardware. Hardware programming is fun. Side effects include nausea and vomiting. I hope this answers your questions. Regards, Carl-Daniel -- http://www.hailfinger.org/