From mboxrd@z Thu Jan 1 00:00:00 1970 From: Pavel Herrmann Date: Mon, 24 Sep 2012 14:23:33 +0200 Subject: [U-Boot] [PATCH 01/11] DM: add block device core In-Reply-To: <11833909.5A4CSeYhUS@bloomfield> References: <1348169867-2917-1-git-send-email-morpheus.ibis@gmail.com> <201209221533.11129.marex@denx.de> <11833909.5A4CSeYhUS@bloomfield> Message-ID: <2441557.SaKVGKQHGS@merom> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de On Saturday 22 September 2012 15:59:46 Pavel Herrmann wrote: > On Saturday 22 of September 2012 15:33:10 Marek Vasut wrote: > > Dear Pavel Herrmann, > > > > > On Saturday 22 of September 2012 02:09:15 Marek Vasut wrote: > > > > Dear Pavel Herrmann, > > > > > > > > [...] > > > > > > > > > > > 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) > > > > > > > > block_device instance (aka. partition/disk) directly connected to USB > > > > hub > > > > instance does not seem right. > > > > > > why? > > > > It doesn't make sense ... you need some kind of interim controller (like > > the chip between the USB and NAND in the thumbdrive. > > yes, but you dont make drivers for every chip there is, instead the chips > understand a common language, where you describe block operations by USB > transfers, and that is exactly what saib block_device_usb_flash would do. > > > > > > > > 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" > > > > > > > > So my generic partition implementation (BDd) would have to implement > > > > USB > > > > flashdisc stuff, correct? This makes no sense. > > > > > > no. your generic USB flash would have to implement USB flashdisc stuff, > > > your generic partition implements block_device operations on top of > > > other > > > block_device (aka diosk, memory card, USB flash) > > > > Ok, so in your parlance, the block_device is either "partition/disc" or a > > "SD card controller driver" or "USB flashdisc driver" ? You are mixing > > these two things together? > > > > > please read the letters you came up with right. (maybe after getting > > > some > > > sleep by the looks of it) > > > > I'd prefer to read some documented code. > > im missing the point of this. you stateted that you have a partition "BDp" > and a disk "BDd". i said your "BDd" will sit above USB API, and you stared > ranting about partitions implementing USB stuff, which was totaly off. > > > > the point you are not getting is that there should be more block_device > > > drivers than there is now - one for partitions, one for disk, one for > > > USB > > > flash, one for SD and so on, each one using a different parent API > > > > Ok, now I understand your intention. Split it -- make partitions separate, > > since this is flat out confusing! > > > > Make partitions / whole disc a separate thing ... > > Make USB flash driver / SD card driver / etc. another thing ... > > > > You can not mix these two together, it makes no sense. > > well, disks, SD cards and USB flashes are one thing at the moment (see > struct block_dev_desc). i am only adding partitions to the mix. > > > > > > (a driver that has blockdev API on one end, USB on the other) > > > > > > > > Ok, so how would this work, every partition implementation implements > > > > upcalls for all USB, SCSI, SATA, IDE, SD, ... and gazilion other types > > > > of > > > > drive it can sit on? > > > > > > no, partition only implements call onto another block device > > > > > > > > > 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 you would have a specific partition implementation for SD, SATA, > > > > IDE, > > > > SCSI, USB ... ? This is flawed. > > > > > > no, read above > > > > > > > The partition should be a generic "thing" which knows nothing about > > > > where > > > > it's sitting at. So is the whole drive, same thing, it just has > > > > partitions hooked under it. > > > > > > > > I'd expect a "block_controller" to be the proxy object under which the > > > > block_device representing the disc is connected. And this > > > > "block_controller" to be proxifying the requests to the respective > > > > drivers (be it SD, SATA, whatever). > > > > > > your idea is wrong - you expect there will always be only one > > > block_device > > > representig a "disk", and all the proxy would be done by the > > > block_controller above it. this is not true > > > > Any amount of "block_device" can be connected under the > > "block_controller". > > Given that "block_device" is a partition/disc _only_ and > > "block_controller" > > is the interface driver ... which is probably not true, so you lost me > > again. > > block controller muxes several disks onto one device (like a SATA controller > does). you dont need this on USB drives and MMC cards, because you have a > controller that can access multiple devices already (like the USB root hub) > > if you took a look at the code you might see the point - the only thing you > add by haveing a block_controller is a "port" parameter to every function, > which you dont need in SD cards or USB flashes For all who are reading this, I have been enlightened with the knowledge that there can be multiple MMC/SD cards on one MMC controller, as there can be multiple hard drives behind one USB device. This is something this code was indeed not designed for, and i apologize for the misunderstanding. Pavel Herrmann