Re: [PATCH] arch/tile: add arch/tile/drivers/ directory with SROMdriver

[Chris Metcalf]

On 5/21/2011 11:50 AM, Eric Biederman wrote:
> On Sat, May 21, 2011 at 6:52 AM, Chris Metcalf <cmetcalf@xxxxxxxxxx> wrote:
>> Interesting!  I did in fact assume that most tools that read or write
>> eeproms would tend to be "batch" tools, i.e. they would read or write
>> whatever it was they wanted, then exit; the tool we have that modifies this
>> EEPROM is written like that, for example.  It sounds like you're saying
>> there are (or may be) tools that open the file descriptor and do writes to
>> it, then don't exit or close the file descriptor, but expect the last write
>> to have hit the device immediately.  It's fair to say that since my
>> suggested API does defer the last sector's worth of writes until the app
>> exits, it potentially violates that assumption, so it's a bad idea.
> Plus the other gigantic difference that I have seen very few eeproms
> that can hold a sectors worth of data.
>
> My reading of this conversation is that you are confusing a configuration
> eeprom with a nor flash boot device.  That is a bit like confusing a yellow
> sticky not with the Encyclopedia Britannica.   They aren't at all the
> same thing.

Well, I don't think I'm confusing the two types of hardware, per se.  The
issue is that the hypervisor provides an API to Linux (or other operating
systems) that attempts to make them look reasonably similar.  In
particular, for the SPI ROM, the hypervisor implicitly manages background
reading of the sector data, doing a "diff" of new data to determine whether
a sector erase is required, and deferring the actual sector write until the
client attempts to write to a different sector.  (This last feature is why
an explicit "flush" is required.)

This approach (unlike mtdchar) provides a "transparent" mode for accessing
the SPI ROM.  Users of our character driver don't need to know they are
writing a flash device, don't need to worry about erasing/rewriting
sectors, etc.  We could potentially rework our boot ROM management tool to
support the mtdchar API, but it would be a modest pain, particularly since
we still have to support the normal file mode without "erase" ioctls, etc.,
for use in the "cross-compiling" mode that we offer with this tool.  And,
another Tilera tool that stores data in the SPI ROM for bootup
configuration would also have to be similarly reworked.  And, if any of our
customers have taken advantage of the part of the SPI ROM that is reserved
for applications, they'd have to make that change as well.  This seems like
a problem.  Plus, for what it's worth, it would make it impossible for us
to use our tools on top of another OS, since they'd be dependent on a
Linux-only interface.

None of this is impossible to change, but my sense is that a basically
trivial character device that makes use of the existing Tilera hypervisor's
virtualization of the flash ROM should not be particularly problematic.  It
is true that it may not be worth grouping with other flash ROM character
devices, since it has almost no "flash ROM" characteristics due to the
hypervisor virtualization, but I will leave that up to Arnd.  I'm happy to
add some comments to the driver explaining what makes it different.

I hope this adequately addresses your concerns.

-- 
Chris Metcalf, Tilera Corp.
http://www.tilera.com


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/