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

[Pavel Herrmann]

On Friday 21 of September 2012 21:17:43 Marek Vasut wrote:
> Dear Pavel Herrmann,
> 
> > On Friday 21 of September 2012 20:00:10 Marek Vasut wrote:
> > > Dear Pavel Herrmann,
> > > 
> > > [...]
> > > 
> > > > > > you should have a blockdev driver for USB flash and SD, but not
> > > > > > blockctrl
> > > > > 
> > > > > I'm lost again. Do I also need a blockdev driver for SATA controller
> > > > > now that I need a blockdev driver for SD card controller ?
> > > > 
> > > > you need a blockdev for a blockctrl (see [5/11]), and you need a
> > > > blockctrl driver for your SATA controller
> > > 
> > > So "blockctrl" == The controller driver? Viva abbrevs. Rename it to
> > > block_controller_driver .
> > 
> > thats far too long, dont you think? we only have 80 cols in code...
> 
> So what? You can abbrev. the variable name, so it won't get in the way. As
> you can see, I was confused by the name, do you expect others not to be?
> > > > you can either implement your SD as a blockctrl and use that blockdev
> > > 
> > > SD as in ... SD card or SD host controller ? Use what blockdev ?
> > 
> > either we say we only have SD memory (and will never ever have other SDIO
> > cards), implement SD controller with blockctrl API (and change it
> > slightly,
> > because SD is inherently flash and therefore has an erase operation)
> > 
> > on the other hand, we could have a separate API for SD controllers (richer
> > than the blockctrl, to eventually suport non-memory SD cards), and then
> > have a device that provides blockdev API on one end, and uses this SD API
> > on the other (much like blockdev_ata in [5/11] does for blockctrl API).
> > this is the original idea; for this reason, blockdev API already has an
> > erase operation, even though blockctrl does not support it.
> > 
> > > > , or
> > > > implement a separate blockdev for your SD card (this is the original
> > > > intention)
> > > 
> > > Ok, so the general abstration is to have a block_controller_driver
> > > (blockctrl in your parlance) for each and every driver in drivers/block
> > 
> > yes
> > 
> > > _and_ which provides only basic read/write block for the downstream
> > > drivers (block_device) attached to it
> > 
> > yes
> > 
> > > _and_ proxifies them for particular device type handlers?
> > 
> > not sure what you mean there. what device type handlers? is that
> > SATA/SCSI/PATA? that should disappear, only reason i have it in code is
> > because i am wrapping old APIs into the new one.
> 
> 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.

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.

every child of block_controller should be a block_device (not necessarily the 
other way around), so there is no way you pass more instances block_controller 
on your way up.