[U-Boot] [PATCH 01/11] DM: add block device core

[Pavel Herrmann]

On Friday 21 of September 2012 23:11:57 Marek Vasut wrote:
> Dear Pavel Herrmann,
> 
> [...]
> 
> > > I mean the particular block_controller_driver instance routes the
> > > "read/write block" request from downstream block_device through
> > > SATA/SD/SCSI/whatever "library" or "layer" back into itself. But the
> > > later "itself" is the implementation of the "library" or "layer" API.
> > > Once the library call returns, the "read/write block" operation is
> > > complete and the result can be passed back to the downstream
> > > "block_device". Yes?
> > 
> > in that case no, the block controller should directly take care of the
> > call, without it being translated into some form it likes better for its
> > particular interface.
> 
> This is entirely wrong. This would mean for example for SD drivers, to
> implement whole SD stack.

no one is forbiding you from having a shared library of common routines, but 
you should not force anyone to use it.

> > the translation is udes as a mechanism to support old code, but eventually
> > there should be none, and the drivers should take a request from
> > block_device and take care of it (probably by using memory-mapped access,
> > or however you communicate with that chip).
> > 
> > there might be a shared library for old IDE drivers though, as they are
> > more like a shared code with driver (and board)-specific hooks.
> > 
> > > > > Now block_device (blockdev) is either a whole disc, partition, or
> > > > > subpartition. It exports read/write block operations, but to
> > > > > complete
> > > > > them, it uses upcalls into it's parent, yes?
> > > > 
> > > > yes
> > > > 
> > > > > These upcalls stop at first block_controller_driver, correct?
> > > > 
> > > > in case of a hard disk, yes. in case of a USB flash, it uses USB calls
> > > > to its parent (USB hub or whatever) to complete the task at hand
> > > 
> > > Let me reformulate -- there is only single block_controller_driver
> > > instance the request crosses on it's way up the driver tree. Yes?
> > 
> > one or none - requests on USB flashes should not pass through
> > block_controller_driver.
> 
> Uh, what do they pass into then ?

their parent (an USB hub)

> > every child of block_controller should be a block_device (not necessarily
> > the other way around
> 
> I doubt it's even possible to be the other way around.
> 
> > ), so there is no way you pass more instances
> > block_controller on your way up.
> 
> Ok, let me explain again. Let's look at the USB case to make it more
> real-world- ish. Imagine you have a thumb drive with 2 partitions. Thus you
> have two instances of struct block_device [denote BDp] for the partitions
> and one more for the whole disc [denote BDd]. When you read from partition,
> you end up poking BDp, which pushes the request up into BDd. This in turn
> calls USB-flashdisc- block_controller_driver [call it UFc]. For flash disc
> to read data, it needs to do some USB transfers. These are provided by USB
> host controller [UHC]. Thus you need some glue between UHC and UFc ... this
> is what I'm talking about.

there should be no "UFc", your "BDd" driver should talk directly to your "UHC" 
(a driver that has blockdev API on one end, USB on the other)

> Ok, I see the issue at hand. In case of a "regular drive", this implements
> the IO directly. In case of SD, this is a proxy object which interfaces
> with some SD-library and prepares the SD commands and then pushes that up
> into the controller to do the job? Same thing for USB flashes ?

not every block device will have a block controller as a parent (or parent-of-
parent in case of a partition). there would be a blockdev-usb that has a USB 
hub as a parent, and a blockdev-mmc, that has a mmc/sdio controller as a 
parent.

so basically what you mean, without the block_controller in the middle - 
please note that the block_device API is actually richer than the 
block_controller API (has erase) for exactly this reason.

Pavel Herrmann