[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <950622.87676.qm@web37605.mail.mud.yahoo.com>
Date: Tue, 10 Aug 2010 00:53:43 -0700 (PDT)
From: Alex Dubov <oakad@...oo.com>
To: Maxim Levitsky <maximlevitsky@...il.com>
Cc: LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 2/2] MEMSTICK: Add driver for Ricoh R5C592 Card reader.
> About INT bits, I still don't
> understand them exactly.
>
> First of all we have 4 meaningful bits.
> In parallel mode these are exposed on data lines, in serial
> mode only
> MEMSTICK_INT_CED is.
> And I can always send MS_TPC_GET_INT or just read the
> registers.
>
> #define MEMSTICK_INT_CMDNAK 0x01
This bit means command was not acknowledged by the media (media not ready).
> #define MEMSTICK_INT_BREQ 0x20
This bit means media is ready for long data transfer (either in or out).
> #define MEMSTICK_INT_ERR 0x40
This bit means that some error had occurred during command execution.
> #define MEMSTICK_INT_CED 0x80
This bit marks a completion of the command, but it may switch value in
between, so it is not that reliable by itself.
>
>
> Now, I send a command to device, say MS_CMD_BLOCK_READ.
> What bits I need to poll until I can be sure that command
> is completed?
All of them.
>
> Also the MEMSTICK_INT_BREQ tells that input is available in
> firmware
> buffer (to read using TPC_READ_LONG_DATA)?
>
Not exactly. BREQ signal indicated that media's state machine is in the
mode to pump data in or out. You wait for it, than you do the data
transfer (it works the same with READ and WRITE).
>
>
> Is that true that MEMSTICK_INT_BREQ is a summary of fifo
> full/empty bits
> in status0?
This can not be relied upon. Sony states, that only BREQ bit must be used
in block transfer operations. BE/BF bits are probably of more use in
memstick IO cards (there exists such a beast).
>
> And same about MEMSTICK_INT_ERR and status1.
status1 errors apply only to data errors (bit flips).
There are errors in command execution that do not result in bit flips,
rather data can not be delivered at all or command/parameters are invalid.
>
> I try my best to create a driver that actually works,
> simple, and error
> free, even in unusual conditions.
> Thats why I am asking all these questions.
>
> Thanks for help,
> 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