On Fri, 23 Nov 2012 14:51:08 +0100
leroy christophe <christophe.leroy@xxxxxx> wrote:
> Le 26/09/2012 02:47, Kim Phillips a écrit :
> > On Tue, 25 Sep 2012 10:45:17 +0200
> > leroy christophe <christophe.leroy@xxxxxx> wrote:
> >
> >> I'm trying to use the Talitos crypto driver with the MPC885
> >> microcontroller. For the time being, it doesn't work.
> > yes, they're not exactly compatible...
> >
> >> The kernel startup blocks at the test of the DES function.
> >>
> >> I have added the following definition in the DTS file:
> >>
> >> crypto@20000 {
> >> compatible = "fsl,sec2.0";
> > interesting, its called "SEC Lite" and its version register does
> > indeed say 2. I see it has a single channel FIFO instead of a ring,
> > that the SEC v1.x (MPC185) used, so you probably don't have to
> > rewrite talitos_submit.
> Good news, it was also my understanding.
> >
> >> reg = <0x20000 0x8000>;
> >> interrupts = <1 1>;
> > I couldn't find the IRQ line in the MPC855RM - if there's no IRQ
> > line, then that's a problem.
> Neither do I on the drawing, however in Table 52-1, there are 3 bits in
> the CPTR register for defining the interrupt level of the SEC lite, just
> like you do for the CPM and for the FEC.
not sure how interrupt _level_ is relevant, but I'm going to assume
you're saying the SEC's IRQ line is integrated into that of the CPM
and/or FEC.
> So I believe this should be ok ?
Assuming the above, the 'interrupts' property above should
equal that of the CPM and/or FEC, and the IRQ_SHARED flag set in
request_irq (in both talitos and the CPM and/or FEC drivers). The
talitos IRQ handler will return IRQ_NONE if none of the channel
done/error bits are set in the SEC.
> >> interrupt-parent = <&PIC>;
> >> fsl,num-channels = <1>;
> >> fsl,channel-fifo-len = <24>;
> >> fsl,exec-units-mask = <0x4c>;
> >> fsl,descriptor-types-mask = <0x301f>;
> > the descriptor type enumeration isn't uniform across into the mpc8xx
> > SEC version, e.g., the SEC Lite doesn't support the ipsec_esp
> > descriptor type, represented in mpc8xxx SEC versions as the second
> > bit, so this descriptor-types-mask setting should be fixed to at
> > least omit that since the driver checks for, and uses it if
> > available.
> >
> >> Is there anything wrong in what I did ? Or is there something else I
> >> should do ?
> > might want to go through the defines in talitos.h, e.g,
> > TALITOS_MCR_SWR is 0x1 on mpc8xxx vs. 0x10000000 on
> > mpc8xx (I suppose CONFIG_PPC_8xx can be used as the ifdef, btw).
> I'm surprised about this, I didn't check the talitos.h file, but had
> checked the Reference Manual of the MPC 8272.
> I rechecked yesterday and the SWR bit is at the same place as on the
> MPC885 which is different from what is defined in talitos.h
right, for some odd reason the h/w designers decided to scramble
the bitfield definitions.
> > Descriptor header and pointer formats, along with field locations,
> > sizes, and enumerations may also be different.
> >
> > It also appears the SEC Lite doesn't support scatter-gather tables,
> > which will make performance hurt for fragmented (large) packet sizes.
> Does it mean something has to be modified if the SW ?
yes, s/w will have to allocate a new contiguous memory buffer and
sg_copy_to_buffer() prior to crypto request submission to the h/w,
and sg_copy_from_buffer() after h/w completion.
Kim
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
