lkml.org 
[lkml]   [2010]   [Aug]   [8]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    SubjectRe: [PATCH 2/2] MEMSTICK: Add driver for Ricoh R5C592 Card reader.
    From
    Date
    On Sun, 2010-08-08 at 07:26 -0700, Alex Dubov wrote: 
    > > Hi,
    > >
    > > I have few more questions about memsticks.
    > >
    > > First of all, I need an explanation of overwrite flag.
    > > You already explained it to me once, but I still not sure
    > > about few
    > > things.
    >
    > Overwrite register can be accessed either as part of extra data access
    > or separately (CP_OVERWRITE access mode).
    >
    > >
    > > #define MEMSTICK_OVERWRITE_UDST 0x10
    > > This one I understand, thinking about xD again, I think it
    > > is very
    > > handy.
    > >
    > > My idea (from xD of course) is that copyonwrite is done
    > > this way:
    > >
    > > 1. read old sector
    > > 2. allocate new sector
    > > 2. write what was just read to new sector.
    > > 3. erase old sector.
    >
    > This is correct.
    >
    > >
    > > Could you explain when I need to set and reset the
    > > MEMSTICK_OVERWRITE_UDST?
    >
    > UDST flag should be set when you're marking the block for
    > reallocation during the read/modify/write cycle. You read the existing
    > physical block, mark it with UDST flag (setting it to zero), then write
    > different physical block on behalf of the same logical one, then erase the
    > original block. The UDST flag is supposed to guard against a situation,
    > whereupon power fails during the write cycle and you're left with two
    > physical blocks mapped to the same logical one (so the one marked with
    > zero UDST value is supposedly "known good").

    >
    >
    > >
    > >
    > > #define MEMSTICK_OVERWRITE_PGST1 0x20
    > > #define MEMSTICK_OVERWRITE_PGST0 0x40
    > > I suppose these indicate that page(sector) contains
    > > incorrect data, just
    > > like in xD there is page status?
    > > Again, better explanation is welcome.
    > > Also, should I touch that flag when I update sector?
    > >
    > >
    > >
    > > #define MEMSTICK_OVERWRITE_BKST 0x80
    > > This marks bad blocks?
    >
    > BKST set to zero indicates that the whole block is bad and shouldn't be
    > used.
    >
    > PGST1:0 has several values:
    > 11: default, r/w page
    > 10: reserved value, shouldn't be used
    > 01: page is read-only (soft write-protect)
    > 00: page is accessible, but the value is not guaranteed (faulty page that
    > sort-of works)
    >
    > That's what the spec says.

    Thank you very much.
    >
    > >
    > >
    > >
    > > Another question is about write of oob data.
    > > When I write it, overwrite flag is updated, or I need to
    > > use
    > > MEMSTICK_CP_OVERWRITE to update it?
    > > I think former is true.
    >
    > As I mentioned above, it can be accessed either as part of extra data
    > or separately.
    >
    > >
    > > When I write a sector, I just write 0 to management flag,
    > > right?
    >
    > You shouldn't touch management_flag at all, as far as I can tell.
    > It's only used to indicate special purpose blocks, such as factory
    > written boot blocks, volatile look-up table blocks (for systems with
    > tight RAM requirements) and DRM marked blocks which I has no info about.
    >
    > >
    > >
    > > And last question,
    > > If I use MEMSTICK_CP_BLOCK, can I start reading a block
    > > from non-zero
    > > page offset?
    >
    > Yes, it starts from the user specified page address and auto increments it
    > until the current block end is hit.
    >
    > >
    > >
    > > And surely last question, what is 'MS_CMD_BLOCK_END'
    >
    > This command is used to terminate the currently ongoing block operation.
    > If you are using one of the auto-increment modes (with CP_BLOCK set) but
    > do not want to access all the pages until the block end, you must issue
    > this command after the desired number of pages is transferred to return
    > the media's state machine to the initial state. This command never hurts,
    > as you can guess.
    That what I expected, thanks!
    >
    > >
    > >
    > > Thanks again for all help so far,
    > >
    >
    > You're welcome.

    Thank you very much!

    Best regards,
    Maxim Levitsky



    \
     
     \ /
      Last update: 2010-08-08 17:09    [W:0.027 / U:0.532 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site