Message-ID: <1281336964.16637.13.camel@maxim-laptop>
Date:	Mon, 09 Aug 2010 09:56:04 +0300
From:	Maxim Levitsky <maximlevitsky@...il.com>
To:	Alex Dubov <oakad@...oo.com>
Cc:	LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 2/2] MEMSTICK: Add driver for Ricoh R5C592 Card reader.

On Sun, 2010-08-08 at 23:31 -0700, Alex Dubov wrote: 
> > 
> > I currently assume that if I set req->need_card_int, the
> > driver will
> > wait till device raises MEMSTICK_INT_CED regardless of
> > serial/parallel
> > mode. This bit is always available on serial line.
> > Is that OK to assume?
> 
> I'm not quite sure about this question.
> Normally, when you wait for the media interrupt, you want to see the whole
> value of the INT register (CED by itself doesn't indicate successful
> command completion; in fact it's value is undefined in presence of other
> INT flags, like BREQ or CMDNK). In parallel mode, host is required to
> fetch all meaningful INT bits from the media bus, while in serial mode
> this is only possible, if host supports automatic INT retrieval (the host
> will issue GET_INT tpc behind the scenes before alerting the software).
Ok, maybe I didn't explain myself correctly.

Device is in serial mode.
I set need_card_int
I send a command.
<here I assume that driver waits for CED bit, which is exposed on data
line, if CED won't be set, driver/hardware will timeout>
I send GET_INT _once_, look at flags. If I see CED, no NACK, then ok,
otherwise I send error result.



> 
> > 
> > Another thing that I want to ask is about writes to
> > overwrite/managment
> > flag.
> > Common sense tells me that I can write the flash many
> > times, but write
> > can only clear bits. Therefore if I write 0xFF, this just
> > means do
> > nothing.
> > Probably same applies to data content, but that isn't much
> > of the use.
> 
> Yes, all memsticks are NAND flash, so writing 1s has no effect whatsoever.
> 
> > Thats why I see that default (good) value of bits in
> > overwrite flag is
> > 1.
> > This is correct I assume?
> 
> Yes, a direct consequence of the above.

I suspect that managment flag also has default value of 0xFF, and these
'special' features (drm, boot block, temporary table) clear bits out of
it.

> 
> > 
> > 
> > Another interesting thing I observed was that
> > MEMSTICK_INT_ERR can mean
> > a correctable error,  therefore it shouldn't
> > alone  reject read/write of
> > a sector. (I think that it means that one of
> > MEMSTICK_STATUS1_UCFG..MEMSTICK_STATUS1_DTER is set)
> > Same question about this.
> > 
> 
> There are three groups of error flags. While overwrite_flag register is
> accessible as part of extra data, being the indicator of block goodness
> it earned its own error flag:
> 
> DTER (UCDT) - error (uncorrectable) in data area
> EXER (UCEX) - error (uncorrectable) in extra data area
> FGER (UCFG) - error (uncorrectable) in overwrite_flag register
> 
> Uncorrectable error means that you've got some bit errors in the data
> you've obtained from the media. If uncorrectable flag is not set, it
> means that media's ECC circuit managed to correct the bit flip. The
> desired way of action is, of course, to reallocate the block before it
> develops an uncorrectable failure.
That I understand clearly.
I ask what the meaning of MEMSTICK_INT_ERR is.
I expect it to be set if any of (un) correctable errors are found.
Therefore if MEMSTICK_INT_ERR, I can't report error instantly, but I
need to look at status1 to see if error is correctable or not.
This is correct?


Best regards,
Maxim Levitsky

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

Powered by blists - more mailing lists