linux-kernel - Re: [PATCHv4] DMAEngine: Define interleaved transfer request api

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Tue, 18 Oct 2011 00:59:30 +0530
From:	Jassi Brar <jaswinder.singh@...aro.org>
To:	"Bounine, Alexandre" <Alexandre.Bounine@....com>
Cc:	"Williams, Dan J" <dan.j.williams@...el.com>,
	Vinod Koul <vinod.koul@...el.com>,
	Russell King <rmk@....linux.org.uk>,
	Barry Song <21cnbao@...il.com>, linux-kernel@...r.kernel.org,
	DL-SHA-WorkGroupLinux <workgroup.linux@....com>,
	Dave Jiang <dave.jiang@...el.com>
Subject: Re: [PATCHv4] DMAEngine: Define interleaved transfer request api

On 17 October 2011 23:30, Bounine, Alexandre <Alexandre.Bounine@....com> wrote:
>> >> >> But doesn't the info, pointed to by this (void *), remain same
>> for
>> >> >> every
>> >> >> transfer to a particular target/remote device ?
>> >> > No. An address within the target may (and most likely will) be
>> > changed for
>> >> > every transfer. Target destination ID will be the same for given
>> > virtual channel.
>> >> >
>> >> Thanks for the info.
>> >>
>> >> > Virtual channel may bring the same challenge and I may need a
>> > channel locking
>> >> > if more than one requester try to read/write data to the same
>> target
>> > RIO device.
>> >> >
>> >> One can't avoid taking care of locking, but using virtual channels
>> >> keeps the dma_chan usage consistent.
>> >>
>> > Using virtual channels adds layers of complexity
>> Perhaps you didn't get me ... I suggest the dma controller driver
>> (not client drivers) create virtual channels corresponding to each
>> device it can talk to. A bunch of virtual channels could be served
>> by a single appropriate physical channel.
>> It is actually quite common, see amba-pl08x.c or pl330.c for example.
>>
> This is a source of the problem for RIO - DMA controller driver creates
> virtual channels statically. RapidIO may use 8- or 16-bit destID.
> In this case we need to create 256 or 64K virtual channels if we
> want to cover all possible targets on single RIO port. Adding an extra
> controller/net multiplies that number. Considering that not every
> device will need a data transfer from a given node static allocation
> will
> create even more wasted resources.
>
Please excuse my rudimentary knowledge of RapidIO but I am tempted
to ask why not register channels only for those targets that are actually
detected and enumerated?

>>
>> 1) The role of the 'extra' 2bits ?
>>
> Just upper bits of the RIO address.
>
I assume you mean any transfer could be targeted at any of 2^66 bits
on the remote device.

> There is nothing that absence of full 66-bit addressing blocks now.
> So far we are not aware about implementations that use 66-bit address.
>
Thanks for the important info.
If I were you, I would postpone enabling support for 66-bit addressing
esp when it soo affects the dmaengine API.
Otherwise, you don't just code unused feature, but also put constraints
on development/up-gradation of the API in future, possibly, nearer than
real need of the feature.

If we postpone 66-bit addressing to when it arrives, we can
1) Attach destID to the virtual channel's identity
2) Use device_prep_dma_memcpy so as to be able to change
    target address for every transfer. Or use prep_slave, depending
    upon nature of address at target endpoint.
3) Use slave_config to set wr_type if it remains same for enough
    consecutive transfers to the same target (only you could strike
    the balance between idealism and pragmatism).

> This does not prevent someone from designing RIO compliant endpoint
> device which gives interpretation to these two bits in addition to full 64-bit
> addressing of their platform.
>
It sounds as if the 2bits are 'Vendor-Specific' ?

>> We should try our best to avoid opening the can of worms by adding
>> (void *) hook to each transfer, because any client driver could want
> to
>> pass its own private data to dmac and there would be no way for a dmac
>> driver to know what to cast the void pointer to.
>
> Do we really expect that clients will jump to use an extra parameter
> without a valid reason and without knowing their hardware specifics?
>
The long term plan for dmaengine is to be able to have client drivers
shared across dmac drivers. And that requires clients making no
assumptions about the underlying dmac and the dmac driver expecting
nothing from client via outside of common APIs.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/