On Wed, 6 Mar 2013 10:29:46 -0500 Akshay Saraswat akshay.s@samsung.com wrote:
I have removed "tested with" in the new set of patches. And I tested those patches with that command before mailing for review. I have tested them for various sizes this time which includes 8 MB as well. I have shared benchmark results in another mail.
thanks - the threshold looks good (although the two largest sizes looked a bit too close).
my point is other SoCs can use the same entry in the array - there's nothing h/w-vendor or model-specific about it.
Something like CONFIG_HW_SHA{1,256} ought to do it.
These instances of struct algo were created specifically for ace because we need function name different for ace to distinguish it from others. Hence, config name includes "ace" as well.
no you don't, because no u-boot instance will contain support for others. SoC vendors don't put more than one crypto unit in their parts.
But I don't think crypto units other than ACE will use the code in this patch - it is intended to implement ACE support, and put it ahead of software support in terms of priority.
the same priority that any h/w accelerated device would get - higher than that of software crypto.
Another question for Akshay wrt the timeout (since I never got a reply re: documentation): how can the h/w fault?
Regarding documentation, I have replied to that mail itself. Sorry for the delay.
Since it is obvious that in case of h/w fault all readl and writel's would result incorrectly and since we know that status register should change it's value quickly, we have a good option to depend upon 100 ms as the time more than enough for wait. And I tried to handle our concern over frequency change and early timeout with the proportional timeout calculation in the new patch. Please have a look.
I don't understand this - the question is whether the h/w can possibly experience an internal failure from submission time to result ready time.
Kim