On Sun, Jan 5, 2014 at 10:11 AM, Arnd Bergmann <a...@arndb.de> wrote:
> On Sunday 05 January 2014, Ravi Patel wrote:
>> On Sat, Dec 21, 2013 at 11:03 PM, Arnd Bergmann <a...@arndb.de> wrote:
>> > On Saturday 21 December 2013 17:00:51 Loc Ho wrote:
>> >> On Sat, Dec 21, 2013 at 12:11 PM, Arnd Bergmann <a...@arndb.de> wrote:
>> >
>> > Please describe here what the purpose of the qmtm is, as this is not
>> > entirely clear from the code or from your reply.
>> >
>> > Greg was guessing that it's a bus controller, my best guess is a DMA
>> > engine. If it's something completely different, you have to let
>> > us know what it is so we can do a proper review rather than guessing.
>> >
>> > Please provide a link to the data sheet if you are unable to explain.
>>
>> Here is URL to a text document explaining role of QMTM device with CPU,
>> Ethernet
>> subsystem.
>>
>> https://drive.google.com/file/d/0B28TgQZ3JLoRRGNnbjJoUGNHWW8/edit?usp=sharing
>>
>> For simplicity, I have shown only Ethernet.
>> PktDMA and Security subsystem interfaces with QMTM in the same way as
>> Ethernet.
>
> Thanks, that helps a lot. Please add this file to an appropriate place
> in the Documentation directory in the next version of your patches.
>
> There is still one central aspect that remains unclear to me, which is
> what the QMTM is actually good for, as opposed to how it gets used from
> the OS.
The document shows the run-time flow of messages between CPU, QMTM and Ethernet.
QMTM is a centralized resource manager/driver which exports APIs to
1. Initialize & allocate queue & pbn to the Ethernet, PktDMA and
Security subsystem.
2. Read queue state so that subsystems driver knows how much more work
it can offload
to its subsystem.
3. Apply QoS for subsystems on their queues.
> In the text description, it sounds like the ethernet is the DMA
> master and performs DMA all by itself but from that it's not clear why
> a message to and from the QMTM is needed. From your drawing on the other
> hand, it seems like the QMTM is really the DMA master and performs the
> DMA on behalf of the ethernet device, which isn't connected to the
> coherent interface itself. If this is correct, it seems that QMTM is more
> like a DMA engine after all that should use the existing slave API to
> provide services to slave drivers.
Each subsystem defines their own format of work message.
A message (or queue descriptor) has attribute fields (QMTM specific)
which is common
for all subsystem work messages.
The remaining fields of a message are specific to subsystem.
QMTM device doesn't have any knowledge of these subsystem specific
fields and the data
operation which subsystem is going to perform using these fields.
e.g.
1. Ethernet work message includes data address & length which is used
by Ethernet
DMA engine for copying the data to/from its internal FIFO
2. PktDMA work message includes multiple data addresses & lengths for
doing scatter/gather,
XOR operations and result data address/es to give back result to the
CPU (driver)
3. Security work message includes data address & length for doing
encryption or decryption,
the type of encryption or decryption and result data address to give
back result to the CPU (driver)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
