All of lore.kernel.org
 help / color / mirror / Atom feed
From: Alex Dubov <oakad@yahoo.com>
To: Maxim Levitsky <maximlevitsky@gmail.com>
Cc: LKML <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 2/2] MEMSTICK: Add driver for Ricoh R5C592 Card reader.
Date: Tue, 10 Aug 2010 01:12:47 -0700 (PDT)	[thread overview]
Message-ID: <749211.91566.qm@web37603.mail.mud.yahoo.com> (raw)
In-Reply-To: <1281367801.22777.19.camel@maxim-laptop>

> Received: Monday, 9 August, 2010, 8:30 AM
> I have another question.
> 
> Looking at ms_block.c, I see that it sometimes changes
> register window.
> This doesn't look good.
> I see it does put the register window back, but still its a
> bit obscure.

It looks very good, in fact, it is the Sony specified way to operate
the media. MS Pro works quite the same, it just needs fewer operations
to actually access data.

> 
> I added tracking of current register window, so every time
> I send
> MS_TPC_SET_RW_REG_ADRS I note the ranges.
> And read/write functions now always attempt to send
> MS_TPC_SET_RW_REG_ADRS. If the window is same as was 
> set last time, TPC
> is skipped.

Sure it is. The media will remember the window set.
Media has all its registers in a sort of flat file. SET_RW_REG_ADDR
selects the subset of the registers that will receive the data delivered
within TPC. This subset is remembered until power off or until changed.


> 
> However, I am thinking, that maybe I should always write
> both param and
> extra register? I just write 0xFF to extra register and
> thats all.

You should write into a param register when you want to alter the command
parameters. You cannot do so during auto incrementing block access, for
example.

But, if you're using the auto incrementing write, you will have to write
extra register for every page transferred.

That's where changing RW_REG_ADDR comes handy.

> Windows driver does that partially. It writes 0xFF to
> managmemt and
> 0xF8 to overwrite flag (why???)

It's a factory default.
Try to read it from some empty block. :-)
(My theory is that missing bits contain invisible ECC data).


> I don't
> think that matters.
> It also always sends the MS_TPC_SET_RW_REG_ADRS, which I
> don't like.
> 

This only reduces the performance slightly. SET_RW_REG_ADDR does not
influence the media's state machine as far as I can tell, unless you try
to push it during the data transfer cycle (whereupon you will end up
having a literal value of the tpc in the media data buffer).



      

  reply	other threads:[~2010-08-10  8:12 UTC|newest]

Thread overview: 40+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-08-05  8:30 [PATCH 2/2] MEMSTICK: Add driver for Ricoh R5C592 Card reader Alex Dubov
2010-08-05 11:20 ` Maxim Levitsky
2010-08-05 11:48   ` Alex Dubov
2010-08-05 12:30     ` Maxim Levitsky
2010-08-05 17:47       ` Maxim Levitsky
2010-08-06  7:43         ` Alex Dubov
2010-08-06 10:56           ` Maxim Levitsky
2010-08-07 13:15             ` Alex Dubov
2010-08-07 15:58               ` Maxim Levitsky
2010-08-08 13:31                 ` Alex Dubov
2010-08-06  8:01       ` Alex Dubov
2010-08-05 12:46 ` Maxim Levitsky
2010-08-06  7:59   ` Alex Dubov
2010-08-06 10:59     ` Maxim Levitsky
2010-08-07 13:12       ` Alex Dubov
2010-08-07 16:03         ` Maxim Levitsky
2010-08-08 13:33           ` Alex Dubov
2010-08-07 20:22 ` Maxim Levitsky
2010-08-08 14:26   ` Alex Dubov
2010-08-08 15:07     ` Maxim Levitsky
2010-08-08 20:08       ` Maxim Levitsky
2010-08-09  6:31         ` Alex Dubov
2010-08-09  6:56           ` Maxim Levitsky
2010-08-09 15:30           ` Maxim Levitsky
2010-08-10  8:12             ` Alex Dubov [this message]
2010-08-10  9:47               ` Maxim Levitsky
2010-08-11  8:08                 ` Alex Dubov
2010-08-11  8:32                   ` Maxim Levitsky
2010-08-12  7:22                     ` Alex Dubov
2010-08-12  7:58                       ` Maxim Levitsky
2010-08-12  7:27                     ` JMicron chipset update Alex Dubov
2010-08-09 19:19           ` [PATCH 2/2] MEMSTICK: Add driver for Ricoh R5C592 Card reader Maxim Levitsky
2010-08-10  7:53             ` Alex Dubov
2010-08-10  9:50               ` Maxim Levitsky
2010-08-11  8:16                 ` Alex Dubov
  -- strict thread matches above, loose matches on Subject: below --
2010-12-09  2:39 MEMSTICK: Add my 2 drivers Maxim Levitsky
2010-12-09  2:42 ` [PATCH 2/2] memstick: Add driver for Ricoh R5C592 card reader Maxim Levitsky
2010-08-03 14:53 [PATCH 0/2] Driver for Ricoh cardreader Maxim Levitsky
2010-08-03 14:53 ` [PATCH 2/2] MEMSTICK: Add driver for Ricoh R5C592 Card reader Maxim Levitsky
2010-08-04  7:57   ` Alex Dubov
2010-08-04 16:48     ` Maxim Levitsky
2010-08-04 19:31       ` Maxim Levitsky

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=749211.91566.qm@web37603.mail.mud.yahoo.com \
    --to=oakad@yahoo.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=maximlevitsky@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.