"Miguel Ángel Álvarez" <gotzoncabanes@gmail.com> writes:

quoted text
>> The FIFOs are some internal property of HDLC controller (it isn't
>> documented but they probably connect the bus master DMA controller to
>> the bit-stuffer and transmitter (and bit-destuffer and receiver in the
>> RX path)). You just need to send a message to HSS to tell it the
>> correct value.
>>
> ¿The message is the HSS_CONFIG_CORE_CR containing the
> CCR_NPE_HFIFO_3_OR_4HDLC flag?

Well right, this one, too. I missed this one.

So it seems the following are needed (and 128-bit LUT):

#define PKT_NUM_PIPES           1 /* 1, 2 or 4 */
#define PKT_NUM_PIPES_WRITE             0x52

#define PKT_PIPE_FIFO_SIZEW     4 /* total 4 dwords per HSS */
(= 1 word for 4E1, 2 words for 2E1, 4 for 1E1)
#define PKT_PIPE_FIFO_SIZEW_WRITE       0x53

#define CCR_NPE_HFIFO_2_HDLC            0x04000000
#define CCR_NPE_HFIFO_3_OR_4HDLC        0x08000000
(to be set in the CORE register).

quoted text
> I understand this, but I do not know exactly how to use it. I mean...
> - I have seen that more queues are added for tx and rxfree, but not rx
> or txdone... Are they not require?

The HSS uses 4 TX queues (each for 1 HDLC/packetized stream), and it
sends all used descriptors back to TXDONE queue (all 4 streams).

The same with RX, you have 4 RXFREE queues (= "RX empty" descriptors,
waiting for RX data), but when the data is ready, they are going back
to the CPU in a single RX queue. There is a stream# in the descriptor.

quoted text
> - Must we use different txreadyq for each hdlc?

Yes, otherwise one HSS could grab all descriptors thus making the
other HSS (temporarily) unusable. Actually we need a TXREADY queues
per HDLC stream (4 per 4E1 port).

quoted text
> - The values you have chosen for txreadyq are 2 and 19. Does it not
> conflict with HSS0_PKT_RXFREE1_QUEUE and HSS1_PKT_RXFREE1_QUEUE.

It does certainly conflict. For now there are no problems because MVIP
isn't supported. I guess we need 64-queue support. Fortunately, Karl
Hiramoto already has a patch for 64 queues, almost ready for merge.

We also have to make sure the queues don't conflict with the Ethernet
driver and (if used) with the crypto code.

quoted text
> - I am not sure which documentation did you use for this (great)
> implementation of eth and hss. The intel manuals lack all information
> about this, so I am trying to check differences with Intel's software
> library (a nightmare),

I was using the library, though I processed it first with some custom
scripts to make it easier to read. Christian Hohnstaedt's code was
also a great help to understand what's going on.

quoted text
> and have found that in "ixHssAccPktTxInternal"
> they add the hdlc port to the entry (which at last seemed to me that
> they were accessing consecutive memory positions from the entry for
> hdlc0).

Do you mean this?
/* Set the least significant 2 bits of the queue entry to the HDLC port number. */
qEntry |= (hdlcPortId & IX_HSSACC_QM_Q_CHAN_NUM_MASK);

They want it when the packet is back in TXDONE queue.

quoted text
> So that is why I thought acc represented the same thing.

No, acc is a private thing of queue manager. HSS code don't know about
it.

quoted text
> What you are saying is that if I send the data to the correct
> tx queue, it will reach the correct FIFO... OK.

Yes.

quoted text
> And reception? If I
> have only one reception queue how could I manage to know to which
> channel have I received the data?

The descriptor will have an ID in it.

quoted text
> - Do you know where can it be found more information about this
> relation between queues, dmas and FIFOs? You are helping me greatly,
> but I do not want to make you loose so much time.

We only have ixp4xx library code. Few small minutes of my time are
not a problem when spent to help implement a useful feature.

I wonder what should I do now with all this. Perhaps integrating
Karl's 64-queue patch and making the HDLC part of HSS driver able to
be merged upstream... I will look if it does make sense.
-- 
Krzysztof Halasa
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html