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. > 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 ? > 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. 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 ? Best regards, Marek Vasut _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot