Re: [RFC PATCHv2 1/4] drivers/otp: add initial support for OTP memory

[Mike Frysinger]

On Fri, Mar 25, 2011 at 06:08, Jamie Iles wrote:
> On Thu, Mar 24, 2011 at 05:33:25PM -0400, Mike Frysinger wrote:
>> On Thu, Mar 24, 2011 at 16:35, Jamie Iles wrote:
>> > The way I was thinking that this sort of thing could be handled would be
>> > for the ECC to be transparent to the user. ÂPerhaps for bfin the OTP
>> > could be registered as 4 regions, otpa1-otpa4 which default to
>> > "single-ended". ÂWriting "ecc" as the format would generate the ecc and
>> > program it for that region then check the ECC when reading back.
>>
>> reads and writes atm always have ECC enabled, and the driver restricts
>> writes to the full half page (64bits). Âif you wanted to be crafty,
>> you could blow individual bits in a single half page over multiple
>> writes before writing out the final ECC, but that isnt supported, and
>> no one has complained.
>
> The current version I have will do read-modify-write if the file offset
> isn't OTP word aligned so it sounds like I need to add a flag that says
> only do full word writes.

yes, only full 64bit writes are allowed.

> I guess in this framework we could make the OTP look like a single
> region of the 0x80 data pages concatenated or provide separate regions
> for each group of 0x80 pages but the control and ECC pages aren't
> directly accessible by the user.

well, in the current driver, i let people dump the ECC.  for
debugging, i think that's valuable.

> The other question that brings up is whether any compatibility with the
> old driver is required.

it's already going to be changing names ;).  but what other
compatibility are you thinking of ?  the requirements are you have to
be able to:
 - read it
 - write in full/aligned 64bit chunks
 - do an OTPLOCK ioctl (the drivers uses this to manage the first few
pages which flags all other pages as "locked")
-mike
--
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/