[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAN1v_Pv-RRTW7cr5xNgAMySQrZi9zMxNjJfnKPi8fa3GUhGpNg@mail.gmail.com>
Date: Sat, 21 Dec 2013 16:43:06 -0800
From: Ravi Patel <rapatel@....com>
To: Greg KH <gregkh@...uxfoundation.org>
Cc: Arnd Bergmann <arnd@...db.de>, davem@...emloft.net,
netdev@...r.kernel.org, linux-kernel@...r.kernel.org,
devicetree@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
jcm@...hat.com, "patches@....com" <patches@....com>,
Keyur Chudgar <kchudgar@....com>
Subject: Re: [PATCH 2/4] misc: xgene: Add base driver for APM X-Gene SoC Queue
Manager/Traffic Manager
> On Thu, Dec 19, 2013 at 07:41:13PM -0800, Ravi Patel wrote:
>> There is no need to talk to this driver from userspace.
>> It is a device which is used by other IO devices to communicate with each
>> other, including CPU.
>> For example, if CPU (software) wants to send a message to Ethernet HW (i.e.
>> send packet),
>> it used this driver to enqueue a message to Ethernet.
>> In other direction, if Ethernet HW receives a packet, it uses QM/TM device to
>> send message to
>> CPU (software) to process packet.
>
> So it's a "bus" type of thing, right?
>
> My question of "why isn't this reflected in the driver model" still
> stands.
There is no subsystem underneath QMTM, nor QMTM does any enumeration.
QMTM is a centralized resource manager which manages queues circularly
for Ethernet, PktDMA (XOR Engine) and Security Engine subsystems.
Traffic Management feature of QMTM does flow control, QoS for the subsystems.
Because of this reasons, its not obvious that QMTM can fit as a bus.
However we are doing further evalution on this.
Thanks,
Ravi
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists