On Mon, Jun 6, 2011 at 3:12 AM, FUJITA Tomonori <fujita.tomonori@xxxxxxxxxxxxx> wrote: > On Mon, 6 Jun 2011 10:47:51 +0100 > Russell King - ARM Linux <linux@xxxxxxxxxxxxxxxx> wrote: > >> On Mon, Jun 06, 2011 at 06:41:09PM +0900, FUJITA Tomonori wrote: >> > On Mon, 6 Jun 2011 10:14:10 +0100 >> > Russell King - ARM Linux <linux@xxxxxxxxxxxxxxxx> wrote: >> > >> > > On Mon, Jun 06, 2011 at 05:06:03PM +0900, FUJITA Tomonori wrote: >> > > > max_segs isn't unrelated with the dma mapping API. I explained above, >> > > > IOMMUs doesn't increase the number of segments (could decrease the >> > > > number of segments by merging). >> > > > >> > > > The limitation about the number of segment already lives elsewhere >> > > > (e.g. queue's limits.max_segments). >> > > >> > > I think you're missing the point entirely. >> > > >> > > Lets take the problem at hand: you have two devices. One of them is >> > > handled by the DMA engine code. One of them is a block device. >> > > >> > > The block layer needs to know the various parameters of what is >> > > allowable for DMA, including such things as the maximum size of a >> > > segment, and the _number_ of segments that can be placed into any >> > > one request. >> > > >> > > As the DMA provider is _entirely_ separate and unknown to the block >> > > device driver, the block device driver has no way to sanely provide >> > > these parameters to the block layer - they are not a property of the >> > > block device driver, but of the DMA provider. >> > >> > struct device_dma_parameters is used for a property of the block >> > device drivers (and scsi HBA drivers, etc). Not DMA provider. Right? >> >> Wrong. struct device_dma_parameters is a property of the _DMA_ _provider_. >> It has to be. Read what I said above and think about it. > > I think that it's up to your definition of DMA provider. > >> In many cases, it so happens that the DMA provider and the block device >> driver are the same entity, and so it may appear that device_dma_parameters > > But could be the different entities, right? If so, the value should be > smaller one? Who is responsible for setting the correct value? The > proposed API blindly set the value (just overwrite). The API would be > better to set a new value only when the new value is smaller? Or > having a separate structure and selecting the smallest value? > > struct device_dma_parameters assumes that the DMA provider and the > block (and SCSI, etc) device driver are the same entity. > >> is a property of the block device driver. As soon as you have to start >> dealing with DMA providers being separate from the block device driver >> then your eyes will be opened and you'll see that it can't work the way >> you seem to want it to. >> >> The DMA parameters have to come from the DMA provider or they're a total >> nonsense. > > I don't think that I claim that the DMA parameters don't come from the > DMA provider. It depends on the definition of the DMA provider, > though. dmaengine expands the class of dma providers to include standalone dma agents on a host bus (or elsewhere) in addition to the traditional bus mastering host-bus-adapters that the existing api understands. So in the case of slave dma the dma capabilities of the block-device are irrelevant because another agent will do the transfer on behalf of the block-device driver. So the value should be whatever the dma device driver says it is. -- Dan -- To unsubscribe from this list: send the line "unsubscribe linux-mmc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
