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

[Pavel Herrmann]

On Friday 21 of September 2012 17:55:10 Marek Vasut wrote:
> Dear Pavel Herrmann,
> 
> > On Friday 21 of September 2012 17:34:27 Marek Vasut wrote:
> > > Dear Pavel Herrmann,
> > > 
> > > [...]
> > > 
> > > > > > blockctrl = AHCI, PIIX... whichever chip you have between SATA and
> > > > > > PCI (or generally disk-bus and board-bus)
> > > > > 
> > > > > So this is for sata ? Or will it also by used for SD/USB flash
> > > > > discs?
> > > > 
> > > > no, blockctrl will be used for SATA, PATA, SCSI, and anything of the
> > > > sort (device with several ports, block devices on said ports, ability
> > > > to send read/write/query commands to devices on ports - definitely not
> > > > USB, possibly also SD, but you probably want more operations from SD)
> > > 
> > > Why not USB flash ? Why not SD, what other stuff do you need for that?
> > > Is
> > > the API not misdesigned then?
> > 
> > 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

you can either implement your SD as a blockctrl and use that blockdev, or 
implement a separate blockdev for your SD card (this is the original 
intention)

I have not looked at current SD API, but i do recall seeing some non-memory 
SDIO cards (wifi for example, not sure u-boot supports this though), so i dont 
think SD should be implemented as a blockctrl

> > > > > > blockdev = disk, partition, SD card
> > > > > 
> > > > > Uh, let's say I understand (even if I don't see the correlation
> > > > > between partition and SD card)
> > > > 
> > > > they are an ordered bunch of blocks with a "conventional" filesystem
> > > > on
> > > > them
> > > 
> > > You might want to do RAW reads, so why do you put filesystem into this
> > > context?
> > 
> > yes, you can do raw reads, but in most cases you are using a filesystem.
> 
> Not true, see how env is stored to these media.
> 
> > i
> > put filesystem there to differentiate from nand devices (which have a
> > special flash- based filesystems in most cases).
> 
> Not true, raw IO on flash media is often used too.
> 
> > > > > > - something that does basic checks
> > > > > > (range, possibility of operation) and submits operations to
> > > > > > correct
> > > > > > parent (blockctrl, MMC controller, whatnot).
> > > > > 
> > > > > Ascii art might help here greatly (how these pieces fall together).
> > > > > I
> > > > > think I do understand it though.
> > > > 
> > > > current code
> > > > user -> FS -> offset calculation from partition info -> drivers/disk
> > > > 
> > > > new code
> > > > user -> FS -> blockdev -> blockctrl (or USB or SD controller)
> > > 
> > > So your "blockctrl" should do the USB/SD/whatever muxing.
> > 
> > no, blockdev shoud be the last common part, for SD/USB, you should have a
> > different blockdev driver, that uses USB/SD API for the actual works
> > 
> > blockctrl is just an unified look at whatever now resides in drivers/block
> 
> Answer my question, you are contradicting yourself in your answer. So again,
> does "blockctrl" do the muxing between the downstream drivers (SD blockdev,
> USB blockdev, SATA blockdev, IDE blockdev ... ) ?

again, no

blockctrl is a common API primarily for SATA/PATA/SCSI controllers, blockdev 
is an abstraction of any block device, therefore you should have a AHCI 
blockctrl, piix blockctrl, bfin blockctrl, sil3114 blockctrl (add anything from 
drivers/block) but a USB blockdev and SD blockdev.

see the difference?

the idea is that there would be no difference when working with SATA/PATA/SCSI 
(as the commands are almost the same currently), but working with USB drives 
and SD cards would be a little different (that is from their own separate 
commands, but not through the blockdev layer)

Pavel Herrmann