[PATCH] patch to OpenCrypto framework

[Kennedy, Brendan]

>-----Original Message-----
>From: Pyun YongHyeon [mailto:pyunyh at gmail.com]
>
>On Mon, Mar 01, 2010 at 08:08:54PM +0000, Kennedy, Brendan wrote:
>>
>> >-----Original Message-----
>> >From: Pyun YongHyeon [mailto:pyunyh at gmail.com]
>> >
>> >> I think it is best to do this check at allocation time, rather than
>> >forcing drivers to do it. It would be a serious overhead for them to
>> >have to do another allocation and memory copy in the data path.
>> >>
>> >
>> >If hardware can handle non-contiguous memory region, this change
>> >may add more overheads to those hardwares. Couldn't this be
>> >handled in hardware driver?
>>
>> Hmm, when it comes to memory allocations and data copies, the less
>that are done in the data path the better!
>> Not adding code to handle this case outside drivers could end with
>vendors having to patch supported frameworks as best they can.
>>
>> Another way would be for drivers to support breaking virtually
>contiguous memory into scatter gather lists of physically contiguous
>memory before sending to hardware.
>
>I believe bus_dma(9) can handle this. New drivers should always use
>bus_dma(9).
>

I don’t think this solution suits EP80579 driver, since it does not handle shared memory directly (there is an API/hardware specific group of modules being used under the hood).
However it is an EP80579 driver specific complaint!

>> It sounds like something that could be done from a kernel function,
>but I'm not sure what the overhead would be vs contigmalloc (probably
>less overhead and maybe sturdier when there's a high level of memory
>fragmentation).
>>
>
>It may depends on hardware. If hardware support multiple DMA read
>for SG list, there would be no overhead at all. bus_dma(9) has
>slight overhead but most cases it's negligible, I think.
>

This is probably a good idea for our driver code as the API supports SG lists.

>> > I guess cheap hardware may have other
>> >limitation as well(alignment restrictions, size limitation etc).
>> >Just changing contigmalloc(9) wouldn't solve other limitation of
>> >hardware.
>>
>> Changing the kernel based on the possibly lesser capabilities of some
>hardware is probably not a good idea.
>> However I think most external hardware drivers have to handle the
>issue of non contiguous physical memory in some way.
>>
>
>I agree, this is the reason why I think handling some limitation in
>driver would be better thing. As I said, bus_dma(9) can take care
>of non contiguous physical memory limitation of hardware.
>

This is interesting even if it might not help our driver, thanks.

>> >Alternatively can we add some capability flag to driver such that
>> >framework can do required action(contigmalloc or malloc) based on
>> >the capability?
>> >
>>
>> That sounds like a good method!
>>
>> Best Regards,
>> Brendan
>> --------------------------------------------------------------
>> Intel Shannon Limited
>> Registered in Ireland
>> Registered Office: Collinstown Industrial Park, Leixlip, County
>Kildare
>> Registered Number: 308263
>> Business address: Dromore House, East Park, Shannon, Co. Clare
>>
>> This e-mail and any attachments may contain confidential material for
>the sole use of the intended recipient(s). Any review or distribution by
>others is strictly prohibited. If you are not the intended recipient,
>please contact the sender and delete all copies.
>>
--------------------------------------------------------------
Intel Shannon Limited
Registered in Ireland
Registered Office: Collinstown Industrial Park, Leixlip, County Kildare
Registered Number: 308263
Business address: Dromore House, East Park, Shannon, Co. Clare

This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies.