soc: Introduce drivers/soc and add Keystone QMSS driver
cover soc: Introduce drivers/soc and add Keystone QMSS driver
Based on earlier thread "https://lkml.org/lkml/2013/10/7/662" and further discussion at Kernel Summit'2013, series creates 'driver/soc' for drivers which are very SOC specific.
Then we add the Keystone QMSS (Queue Manager SubSystem) driver. The QMSS found on Keystone SOCs is one of the main hardware sub system which forms the backbone of the Keystone Multi-core Navigator. QMSS consist of queue managers, packed-data structure processors(PDSP), linking RAM, descriptor pools and infrastructure DMA.
Sandeep Nair (2):
soc: keystone: add QMSS driver
firmware: add Keystone QMSS PDSP accumulator firmware blob
Santosh Shilimkar (1):
soc: Introduce drivers/soc place-holder for SOC specific drivers
.../devicetree/bindings/soc/keystone-qmss.txt | 209 +++ drivers/Kconfig | 4 + drivers/Makefile | 7 + drivers/soc/Kconfig | 5 + drivers/soc/Makefile | 5 + drivers/soc/keystone/Kconfig | 15 + drivers/soc/keystone/Makefile | 5 + drivers/soc/keystone/qmss_acc.c | 591 ++++++++ drivers/soc/keystone/qmss_queue.c | 1533 ++++++++++++++++++++ drivers/soc/keystone/qmss_queue.h | 236 +++ firmware/Makefile | 1 + .../keystone/qmss_pdsp_acc48_k2_le_1_0_0_8.fw.ihex | 110 ++ include/linux/soc/keystone_qmss.h | 390 +++++ 13 files changed, 3111 insertions(+) create mode 100644 Documentation/devicetree/bindings/soc/keystone-qmss.txt create mode 100644 drivers/soc/Kconfig create mode 100644 drivers/soc/Makefile create mode 100644 drivers/soc/keystone/Kconfig create mode 100644 drivers/soc/keystone/Makefile create mode 100644 drivers/soc/keystone/qmss_acc.c create mode 100644 drivers/soc/keystone/qmss_queue.c create mode 100644 drivers/soc/keystone/qmss_queue.h create mode 100644 firmware/keystone/qmss_pdsp_acc48_k2_le_1_0_0_8.fw.ihex create mode 100644 include/linux/soc/keystone_qmss.h
Signature · 1 line
1.7.9.5
PATCH 1/3 soc: Introduce drivers/soc place-holder for SOC specific drivers
Based on earlier thread "https://lkml.org/lkml/2013/10/7/662" and further discussion at Kernel Summit'2013, it was agreed to create 'driver/soc' for drivers which are quite SOC specific.
Lets take the discussion forward with this patch.
--- drivers/Kconfig | 2 ++ drivers/Makefile | 4 ++++ drivers/soc/Kconfig | 3 +++ 3 files changed, 9 insertions(+) create mode 100644 drivers/soc/Kconfig
drivers/Kconfig +2 -0
@@ -130,6 +130,8 @@ source "drivers/staging/Kconfig" source "drivers/platform/Kconfig" +source "drivers/soc/Kconfig" + source "drivers/clk/Kconfig" source "drivers/hwspinlock/Kconfig"
drivers/Makefile +4 -0
@@ -132,6 +132,10 @@ obj-$(CONFIG_VHOST_RING) += vhost/ obj-$(CONFIG_VLYNQ) += vlynq/ obj-$(CONFIG_STAGING) += staging/ obj-y += platform/ + +# SOC specific drivers +obj-y += soc/ + #common clk code obj-y += clk/
drivers/soc/Kconfig new file +3 -0
@@ -0,0 +1,3 @@ +menu "SOC specific Drivers" + +endmenu
Signature · 1 line
1.7.9.5
Re: [PATCH 1/3] soc: Introduce drivers/soc place-holder for SOC specific drivers
Quoted 5 lines · On Fri, 28 Feb 2014 18:18:38 -0500 Santosh Shilimkar…
Based on earlier thread "https://lkml.org/lkml/2013/10/7/662" and further discussion at Kernel Summit'2013, it was agreed to create 'driver/soc' for drivers which are quite SOC specific.
Lets take the discussion forward with this patch.
So what happens if you put something in say soc/banana and 3 months later the same IP block shows up in two other devices both of which have their own soc/ directory already ?
What happens when the same blocks shows up on both a SoC and later externally ?
Where does a soc specifc gpio driver go ?
It seems to me we've got a lot of confusion here because drivers/ is split by type, and we've also got arch/* machine specific drivers and we've got drivers/platform which is intended as far as I can see for everything you'd put in drivers/soc except for that which goes in arch/* anyway.
If QMSS is arm specific why isn't it in arch/arm, if it's not why isn't it in drivers/platform ?
Just trying to understand the point of drivers/soc.
Alan
Re: [PATCH 1/3] soc: Introduce drivers/soc place-holder for SOC specific drivers
Quoted 7 lines · One Thousand Gnomes
Quoted 4 lines · On Fri, 28 Feb 2014 18:18:38 -0500 Santosh Shilimkar…
Based on earlier thread "https://lkml.org/lkml/2013/10/7/662" and further discussion at Kernel Summit'2013, it was agreed to create 'driver/soc' for drivers which are quite SOC specific.
Quoted 5 lines
Quoted 1 line
Lets take the discussion forward with this patch.
So what happens if you put something in say soc/banana and 3 months later the same IP block shows up in two other devices both of which have their own soc/ directory already ?
This isn't so much about IP blocks as about all the other glue logic and management functions that vendors so far seem to implement in their own ways.
I don't remember the name we agreed on, I don't think it was drivers/soc -- partly because naming it that brings up the kinds of questions you have. Paul took it upon himself to start sorting this out (and merge through us on arm-soc), so he hopefully remembers better than me. :)
Quoted 4 lines
What happens when the same blocks shows up on both a SoC and later externally ?
Where does a soc specifc gpio driver go ?
drivers/gpio, of course. This isn't changing that.
Quoted 8 lines
It seems to me we've got a lot of confusion here because
drivers/is split by type, and we've also gotarch/*machine specific drivers and we've gotdrivers/platformwhich is intended as far as I can see for everything you'd put indrivers/socexcept for that which goes inarch/*anyway.If QMSS is arm specific why isn't it in
arch/arm, if it's not why isn't it indrivers/platform?
drivers/platform are for specific vendor platforms. I.e. various laptop vendors, a few server vendors, etc. Code for a whole silicon vendor's driver does not belong there.
Quoted 2 lines
Just trying to understand the point of
drivers/soc.
Shortcutting most of the discussion by focusing on this question. ;)
We've been struggling to find a home for some of the code that we want to keep in the kernel tree, and we sat down to talk with (among others) Greg at KS to try to figure out how to move forward.
The code isn't the pure drivers. Those we find homes for. GPIO, for example, is a clear choice: they go under drivers/gpio. IRQ controllers under drivers/irqchip, etc. We've been good at finding the places for these, including making new homes for them where none was before (pinctrl and clk subsystems come to mind).
The type of code we were still looking for a home for is the glue code that tends to be shared between drivers. For example, on a communication chip it might be queue managers that are shared between SATA, DMA engine, Ethernet controllers, crypto engines, etc. There's no obvious place for us to locate that today. Most of this code is handled like a library with the drivers calling into it.
So, again, it's not for drivers as much as for shared management code. It will not be used for drivers (the Keystone patch adds an actual driver, so we need to talk about that as well :).
And as with all other code in the kernel: If we find that more than one vendor has something compatible, we make them refactor and share the code when we discover it. It's a method we use now and it's working pretty well.
Finally, your question on why we're not locating this under arch/*? It's not architecture-dependent code, some vendors have several SoCs that are very similar but with different cores of different architectures (MIPS, ARM, PowerPC, ARM64, etc). So a location outside of arch/ is needed.
-Olof
Re: [PATCH 1/3] soc: Introduce drivers/soc place-holder for SOC specific drivers
Quoted 14 lines · Olof Johansson
Quoted 7 lines · One Thousand Gnomes
Quoted 4 lines · On Fri, 28 Feb 2014 18:18:38 -0500 Santosh Shilimkar…
Based on earlier thread "https://lkml.org/lkml/2013/10/7/662" and further discussion at Kernel Summit'2013, it was agreed to create 'driver/soc' for drivers which are quite SOC specific.
Quoted 5 lines
Quoted 1 line
Lets take the discussion forward with this patch.
So what happens if you put something in say soc/banana and 3 months later the same IP block shows up in two other devices both of which have their own soc/ directory already ?
Quoted 7 lines
This isn't so much about IP blocks as about all the other glue logic and management functions that vendors so far seem to implement in their own ways.
I don't remember the name we agreed on, I don't think it was
drivers/soc-- partly because naming it that brings up the kinds of questions you have. Paul took it upon himself to start sorting this out (and merge through us on arm-soc), so he hopefully remembers better than me. :)
I think it was drivers/soc for the case that Paul was going to look at. I?d expect we?d go with drivers/soc/<VENDOR> to reduce churn between newer SoC families from a company sharing something with an older one, etc.
Quoted 21 lines
Quoted 5 lines
What happens when the same blocks shows up on both a SoC and later externally ?
Where does a soc specifc gpio driver go ?
drivers/gpio, of course. This isn't changing that.Quoted 8 lines
It seems to me we've got a lot of confusion here because
drivers/is split by type, and we've also gotarch/*machine specific drivers and we've gotdrivers/platformwhich is intended as far as I can see for everything you'd put indrivers/socexcept for that which goes inarch/*anyway.If QMSS is arm specific why isn't it in
arch/arm, if it's not why isn't it indrivers/platform?
drivers/platformare for specific vendor platforms. I.e. various laptop vendors, a few server vendors, etc. Code for a whole silicon vendor's driver does not belong there.Quoted 1 line
Quoted 7 lines
Quoted 1 line
Just trying to understand the point of
drivers/soc.Shortcutting most of the discussion by focusing on this question. ;)
We've been struggling to find a home for some of the code that we want to keep in the kernel tree, and we sat down to talk with (among others) Greg at KS to try to figure out how to move forward.
We talked about drivers/lib and drivers/soc back at KS. Greg was going to start of drivers/lib and Paul was going to look at drivers/soc.
Quoted 22 lines
The code isn't the pure drivers. Those we find homes for. GPIO, for example, is a clear choice: they go under
drivers/gpio. IRQ controllers underdrivers/irqchip, etc. We've been good at finding the places for these, including making new homes for them where none was before (pinctrl and clk subsystems come to mind).The type of code we were still looking for a home for is the glue code that tends to be shared between drivers. For example, on a communication chip it might be queue managers that are shared between SATA, DMA engine, Ethernet controllers, crypto engines, etc. There's no obvious place for us to locate that today. Most of this code is handled like a library with the drivers calling into it.
So, again, it's not for drivers as much as for shared management code. It will not be used for drivers (the Keystone patch adds an actual driver, so we need to talk about that as well :).
And as with all other code in the kernel: If we find that more than one vendor has something compatible, we make them refactor and share the code when we discover it. It's a method we use now and it's working pretty well.
Quoted 7 lines
Finally, your question on why we're not locating this under
arch/*? It's not architecture-dependent code, some vendors have several SoCs that are very similar but with different cores of different architectures (MIPS, ARM, PowerPC, ARM64, etc). So a location outside ofarch/is needed.-Olof
- k
Signature · 2 lines
Employee of Qualcomm Innovation Center, Inc. Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation
PATCH 1/3 soc: Introduce drivers/soc place-holder for SOC specific drivers
Quoted 52 lines · Kumar Gala
Quoted 14 lines · Olof Johansson
Quoted 7 lines · One Thousand Gnomes
Quoted 4 lines · On Fri, 28 Feb 2014 18:18:38 -0500 Santosh Shilimkar…
Based on earlier thread "https://lkml.org/lkml/2013/10/7/662" and further discussion at Kernel Summit'2013, it was agreed to create 'driver/soc' for drivers which are quite SOC specific.
Quoted 5 lines
Quoted 1 line
Lets take the discussion forward with this patch.
So what happens if you put something in say soc/banana and 3 months later the same IP block shows up in two other devices both of which have their own soc/ directory already ?
Quoted 7 lines
This isn't so much about IP blocks as about all the other glue logic and management functions that vendors so far seem to implement in their own ways.
I don't remember the name we agreed on, I don't think it was
drivers/soc-- partly because naming it that brings up the kinds of questions you have. Paul took it upon himself to start sorting this out (and merge through us on arm-soc), so he hopefully remembers better than me. :)I think it was
drivers/socfor the case that Paul was going to look at. I?d expect we?d go with drivers/soc/<VENDOR> to reduce churn between newer SoC families from a company sharing something with an older one, etc.Quoted 25 lines
Quoted 5 lines
What happens when the same blocks shows up on both a SoC and later externally ?
Where does a soc specifc gpio driver go ?
drivers/gpio, of course. This isn't changing that.Quoted 8 lines
It seems to me we've got a lot of confusion here because
drivers/is split by type, and we've also gotarch/*machine specific drivers and we've gotdrivers/platformwhich is intended as far as I can see for everything you'd put indrivers/socexcept for that which goes inarch/*anyway.If QMSS is arm specific why isn't it in
arch/arm, if it's not why isn't it indrivers/platform?
drivers/platformare for specific vendor platforms. I.e. various laptop vendors, a few server vendors, etc. Code for a whole silicon vendor's driver does not belong there.Quoted 2 lines
Just trying to understand the point of
drivers/soc.Shortcutting most of the discussion by focusing on this question. ;)
Quoted 7 lines
Quoted 3 lines
We've been struggling to find a home for some of the code that we want to keep in the kernel tree, and we sat down to talk with (among others) Greg at KS to try to figure out how to move forward.
We talked about
drivers/libanddrivers/socback at KS. Greg was going to start ofdrivers/liband Paul was going to look atdrivers/soc.
Yes, drivers/lib/ is still on my TODO list, unfortunatly way down it... I'll get to it "soon" with some variation of "soon" :(
greg "my inbox is full" k-h
Re: [PATCH 1/3] soc: Introduce drivers/soc place-holder for SOC specific drivers
In reply to Santosh ShilimkarQuoted 59 lines · Santosh Shilimkar
Based on earlier thread "https://lkml.org/lkml/2013/10/7/662" and further discussion at Kernel Summit'2013, it was agreed to create 'driver/soc' for drivers which are quite SOC specific.
Lets take the discussion forward with this patch.
Cc Greg Kroah-Hartman <[email protected]>Cc Kumar Gala <[email protected]>Cc Paul Walmsley <[email protected]>Cc Olof Johansson <[email protected]>Cc Arnd Bergmann <[email protected]>Signed-off-by Sandeep Nair <[email protected]>Signed-off-by Santosh Shilimkar <[email protected]>---
drivers/Kconfig | 2 ++ drivers/Makefile | 4 ++++ drivers/soc/Kconfig | 3 +++ 3 files changed, 9 insertions(+)create mode 100644
drivers/soc/Kconfigdrivers/Kconfig +0
-0@@ -130,6 +130,8 @@ source "drivers/staging/Kconfig"source "
drivers/platform/Kconfig"drivers/Kconfig +2
-0+source "drivers/soc/Kconfig" +source "
drivers/clk/Kconfig"source "
drivers/hwspinlock/Kconfig"drivers/Makefile +0
-0@@ -132,6 +132,10 @@ obj-$(CONFIG_VHOST_RING) += vhost/obj-$(CONFIG_VLYNQ) += vlynq/
obj-$(CONFIG_STAGING) += staging/
obj-y += platform/drivers/Makefile +4
-0+ +# SOC specific drivers +obj-y += soc/ +#common clk code
obj-y += clk/drivers/soc/Kconfig new file +3
-0@@ -0,0 +1,3 @@ +menu "SOC specific Drivers" + +endmenuSignature · 1 line
1.7.9.5
Is there a follow up patch that populates this with something real?
- k
Signature · 2 lines
Employee of Qualcomm Innovation Center, Inc. Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation
PATCH 2/3 soc: keystone: add QMSS driver
In reply to Santosh ShilimkarFrom: Sandeep Nair <[email protected]>
The QMSS (Queue Manager Sub System) found on Keystone SOCs is one of the main hardware sub system which forms the backbone of the Keystone Multi-core Navigator. QMSS consist of queue managers, packed-data structure processors(PDSP), linking RAM, descriptor pools and infrastructure Packet DMA.
The Queue Manager is a hardware module that is responsible for accelerating management of the packet queues. Packets are queued/de-queued by writing or reading descriptor address to a particular memory mapped location. The PDSPs perform QMSS related functions like accumulation, QoS, or event management. Linking RAM registers are used to link the descriptors which are stored in descriptor RAM. Descriptor RAM is configurable as internal or external memory.
The QMSS driver manages the PDSP setups, linking RAM regions, queue pool management (allocation, push, pop and notify) and descriptor pool management. The specifics on the device tree bindings for QMSS can be found in:
Documentation/devicetree/bindings/soc/keystone-qmss.txt
--- .../devicetree/bindings/soc/keystone-qmss.txt | 209 +++ drivers/Kconfig | 2 + drivers/Makefile | 3 + drivers/soc/Kconfig | 2 + drivers/soc/Makefile | 5 + drivers/soc/keystone/Kconfig | 15 + drivers/soc/keystone/Makefile | 5 + drivers/soc/keystone/qmss_acc.c | 591 ++++++++ drivers/soc/keystone/qmss_queue.c | 1533 ++++++++++++++++++++ drivers/soc/keystone/qmss_queue.h | 236 +++ include/linux/soc/keystone_qmss.h | 390 +++++ 11 files changed, 2991 insertions(+) create mode 100644 Documentation/devicetree/bindings/soc/keystone-qmss.txt create mode 100644 drivers/soc/Makefile create mode 100644 drivers/soc/keystone/Kconfig create mode 100644 drivers/soc/keystone/Makefile create mode 100644 drivers/soc/keystone/qmss_acc.c create mode 100644 drivers/soc/keystone/qmss_queue.c create mode 100644 drivers/soc/keystone/qmss_queue.h create mode 100644 include/linux/soc/keystone_qmss.h
Documentation/devicetree/bindings/soc/keystone-qmss.txt new file +209 -0
@@ -0,0 +1,209 @@ +* Texas Instruments Keystone QMSS driver + +Required properties: +- compatible : Must be "ti,keystone-qmss"; +- clocks : phandle to the reference clock for this device. +- queue-range : <start number> total range of queue numbers for the device. +- linkram0 : <address size> for internal link ram, where size is the total + link ram entries. +- linkram1 : <address size> for external link ram, where size is the total + external link ram entries. If the address is specified as "0" + driver will allocate memory. +- qmgrs : the number of individual queue managers in the device. On + keystone 1 range of devices there should be only one node. + On keystone 2 devices there can be more than 1 node. + -- managed-queues : the actual queues managed by each queue manager + instance, specified as <"base queue #" "# of queues">. + -- reg : Address and length of the register set for the device + for peek, status, config, region, push, pop regions. + -- reg-names : Names for the above register regions. The name to be + used is as follows: + - "config" : Queue configuration region. + - "status" : Queue status RAM. + - "region" : Descriptor memory setup region. + - "push" : Queue Management/Queue Proxy region. + - "pop" : Queue Management/Queue Proxy region. + - "peek" : Queue Peek region. +- queue-pools : Queue ranges are grouped into 3 type of pools: + - qpend : pool of qpend(interruptible) queues + - general-purpose : pool of general queues, primarly used + as free descriptor queues or the + transmit DMA queues. + - accumulator : pool of queues on accumulator channel + Each range can have the following properties: + -- values : number of queues to use per queue range, specified as + <"base queue #" "# of queues">. + -- interrupts : Optional property to specify the interrupt mapping + for interruptible queues. The driver additionaly sets + the interrupt affinity based on the cpu mask. + -- reserved : Optional property used to reserve the range. Queues + in a reserved range can only be allocated by id. + -- accumulator : Accumulator channel property specified as: + <pdsp-id, channel, entries, pacing mode, latency> + pdsp-id : QMSS PDSP running accumulator firmware + on which the channel has to be + configured + channel : Accumulator channel number + entries : Size of the accumulator descriptor list + pacing mode : Interrupt pacing mode + 0 : None, i.e interrupt on list full + 1 : Time delay since last interrupt + 2 : Time delay since first new packet + 3 : Time delay since last new packet + latency : time to delay the interrupt, specified + in microseconds. + -- multi-queue : Optional property to specify that the channel has to + monitor upto 32 queues starting at the base queue #. +- descriptor-regions : Descriptor memory region specification. + -- id : region number. + -- values : number of descriptors in the region, + specified as + <"# of descriptors" "descriptor size">. + -- link-index : start index, i.e. index of the first + descriptor in the region. + +Optional properties: +- dma-coherent : Present if DMA operations are coherent. +- pdsps : PDSP configuration, if any. + -- firmware : firmware to be loaded on the PDSP. + -- id : the qmss pdsp that will run the firmware. + -- reg : Address and length of the register set of the PDSP + for iram, intd, region, command regions. + -- reg-names : Names for the above register regions. The name to be + used is as follows: + - "iram" : PDSP internal RAM region. + - "reg" : PDSP control/status region registers. + - "intd" : QMSS interrupt distributor registers. + - "cmd" : PDSP command interface region. + +Example: + +qmss: qmss at 2a40000 { + compatible = "ti,keystone-qmss"; + dma-coherent; + #address-cells = <1>; + #size-cells = <1>; + clocks = <&chipclk13>; + ranges; + queue-range = <0 0x4000>; + linkram0 = <0x100000 0x8000>; + linkram1 = <0x0 0x10000>; + + qmgrs { + #address-cells = <1>; + #size-cells = <1>; + ranges; + qmgr0 { + managed-queues = <0 0x2000>; + reg = <0x2a40000 0x20000>, + <0x2a06000 0x400>, + <0x2a02000 0x1000>, + <0x2a03000 0x1000>, + <0x2a80000 0x20000>, + <0x2a80000 0x20000>; + reg-names = "peek", "status", "config", + "region", "push", "pop"; + }; + + qmgr1 { + managed-queues = <0x2000 0x2000>; + reg = <0x2a60000 0x20000>, + <0x2a06400 0x400>, + <0x2a04000 0x1000>, + <0x2a05000 0x1000>, + <0x2aa0000 0x20000>, + <0x2aa0000 0x20000>; + reg-names = "peek", "status", "config", + "region", "push", "pop"; + }; + }; + queue-pools { + qpend { + qpend-0 { + values = <658 8>; + interrupts =<0 40 0xf04 0 41 0xf04 0 42 0xf04 + 0 43 0xf04 0 44 0xf04 0 45 0xf04 + 0 46 0xf04 0 47 0xf04>; + }; + qpend-1 { + values = <8704 16>; + interrupts = <0 48 0xf04 0 49 0xf04 0 50 0xf04 + 0 51 0xf04 0 52 0xf04 0 53 0xf04 + 0 54 0xf04 0 55 0xf04 0 56 0xf04 + 0 57 0xf04 0 58 0xf04 0 59 0xf04 + 0 60 0xf04 0 61 0xf04 0 62 0xf04 + 0 63 0xf04>; + reserved; + }; + qpend-2 { + values = <8720 16>; + interrupts = <0 64 0xf04 0 65 0xf04 0 66 0xf04 + 0 59 0xf04 0 68 0xf04 0 69 0xf04 + 0 70 0xf04 0 71 0xf04 0 72 0xf04 + 0 73 0xf04 0 74 0xf04 0 75 0xf04 + 0 76 0xf04 0 77 0xf04 0 78 0xf04 + 0 79 0xf04>; + }; + }; + general-purpose { + gp-0 { + values = <4000 64>; + }; + netcp-tx { + values = <640 9>; + reserved; + }; + }; + accumulator { + acc-0 { + values = <128 32>; + accumulator = <0 36 16 2 50>; + interrupts = <0 215 0xf01>; + multi-queue; + reserved; + }; + acc-1 { + values = <160 32>; + accumulator = <0 37 16 2 50>; + interrupts = <0 216 0xf01>; + multi-queue; + }; + acc-2 { + values = <192 32>; + accumulator = <0 38 16 2 50>; + interrupts = <0 217 0xf01>; + multi-queue; + }; + acc-3 { + values = <224 32>; + accumulator = <0 39 16 2 50>; + interrupts = <0 218 0xf01>; + multi-queue; + }; + }; + }; + descriptor-regions { + #address-cells = <1>; + #size-cells = <1>; + ranges; + region-12 { + id = <12>; + values = <8192 128>; /* num_desc desc_size */ + link-index = <0x4000>; + }; + }; + pdsps { + #address-cells = <1>; + #size-cells = <1>; + ranges; + pdsp0 at 0x2a10000 { + firmware = "keystone/qmss_pdsp_acc48_k2_le_1_0_0_8.fw"; + reg = <0x2a10000 0x1000>, + <0x2a0f000 0x100>, + <0x2a0c000 0x3c8>, + <0x2a20000 0x4000>; + reg-names = "iram", "reg", "intd", "cmd"; + id = <0>; + }; + }; +}; /* qmss */
drivers/Kconfig +2 -0
@@ -146,6 +146,8 @@ source "drivers/remoteproc/Kconfig" source "drivers/rpmsg/Kconfig" +source "drivers/soc/Kconfig" + source "drivers/devfreq/Kconfig" source "drivers/extcon/Kconfig"
drivers/Makefile +3 -0
@@ -146,6 +146,9 @@ obj-$(CONFIG_IOMMU_SUPPORT) += iommu/ obj-$(CONFIG_REMOTEPROC) += remoteproc/ obj-$(CONFIG_RPMSG) += rpmsg/ +# SOC specific drivers +obj-y += soc/ + # Virtualization drivers obj-$(CONFIG_VIRT_DRIVERS) += virt/ obj-$(CONFIG_HYPERV) += hv/
drivers/soc/Kconfig +2 -0
@@ -1,3 +1,5 @@ menu "SOC specific Drivers" +source "drivers/soc/keystone/Kconfig" + endmenu
drivers/soc/Makefile new file +5 -0
@@ -0,0 +1,5 @@ +# +# Makefile for the Linux kernel SOC specific device drivers. +# + +obj-$(CONFIG_ARCH_KEYSTONE) += keystone/
drivers/soc/keystone/Kconfig new file +15 -0
@@ -0,0 +1,15 @@ +# +# TI Keystone Soc drivers +# + +config KEYSTONE_QMSS + tristate "Keystone Queue Manager Sub System" + depends on ARCH_KEYSTONE + help + Say y here to support the Keystone Hardware Queue Manager support. + The Queue Manager is a hardware module that is responsible for + accelerating management of the packet queues. Packets are queued/ + de-queued by writing/reading descriptor address to a particular + memory mapped location in the Queue Manager module. + + If unsure, say N.
drivers/soc/keystone/Makefile new file +5 -0
@@ -0,0 +1,5 @@ +# +# TI Keystone SOC drivers +# + +obj-$(CONFIG_KEYSTONE_QMSS) += qmss_queue.o qmss_acc.o
drivers/soc/keystone/qmss_acc.c new file +591 -0
591 lines not on this page · raw message
drivers/soc/keystone/qmss_queue.c new file +1533 -0
1,533 lines not on this page · raw message
drivers/soc/keystone/qmss_queue.h new file +236 -0
236 lines not on this page · raw message
include/linux/soc/keystone_qmss.h new file +390 -0
384 lines not on this page · raw message
The rest of this diff is not shown. View the raw message.
Signature · 1 line
1.7.9.5
Part of the diff is not shown here. View the raw message.
Re: [PATCH 2/3] soc: keystone: add QMSS driver
Quoted 31 lines · Santosh Shilimkar
From: Sandeep Nair <[email protected]>
The QMSS (Queue Manager Sub System) found on Keystone SOCs is one of the main hardware sub system which forms the backbone of the Keystone Multi-core Navigator. QMSS consist of queue managers, packed-data structure processors(PDSP), linking RAM, descriptor pools and infrastructure Packet DMA.
The Queue Manager is a hardware module that is responsible for accelerating management of the packet queues. Packets are queued/de-queued by writing or reading descriptor address to a particular memory mapped location. The PDSPs perform QMSS related functions like accumulation, QoS, or event management. Linking RAM registers are used to link the descriptors which are stored in descriptor RAM. Descriptor RAM is configurable as internal or external memory.
The QMSS driver manages the PDSP setups, linking RAM regions, queue pool management (allocation, push, pop and notify) and descriptor pool management. The specifics on the device tree bindings for QMSS can be found in:
Documentation/devicetree/bindings/soc/keystone-qmss.txtCc Greg Kroah-Hartman <[email protected]>Cc Kumar Gala <[email protected]>Cc Olof Johansson <[email protected]>Cc Arnd Bergmann <[email protected]>Cc Grant Likely <[email protected]>Cc Rob Herring <[email protected]>Cc Mark Rutland <[email protected]>Signed-off-by Sandeep Nair <[email protected]>Signed-off-by Santosh Shilimkar <[email protected]>---
Quoted 10 lines
.../devicetree/bindings/soc/keystone-qmss.txt | 209 +++ drivers/Kconfig | 2 + drivers/Makefile | 3 + drivers/soc/Kconfig | 2 + drivers/soc/Makefile | 5 + drivers/soc/keystone/Kconfig | 15 + drivers/soc/keystone/Makefile | 5 + drivers/soc/keystone/qmss_acc.c | 591 ++++++++ drivers/soc/keystone/qmss_queue.c | 1533 ++++++++++++++++++++ drivers/soc/keystone/qmss_queue.h | 236 +++
So this should be drivers/soc/ti, much like we use vendor in drivers/net/ethernet
Quoted 1 line
include/linux/soc/keystone_qmss.h| 390 +++++
include/linux/soc/ti/
Quoted 9 lines
11 files changed, 2991 insertions(+)create mode 100644
Documentation/devicetree/bindings/soc/keystone-qmss.txtcreate mode 100644drivers/soc/Makefile
create mode 100644drivers/soc/keystone/Kconfig
create mode 100644drivers/soc/keystone/Makefile
create mode 100644drivers/soc/keystone/qmss_acc.c
create mode 100644drivers/soc/keystone/qmss_queue.c
create mode 100644drivers/soc/keystone/qmss_queue.h
create mode 100644include/linux/soc/keystone_qmss.h
[snip]
Quoted 54 lines
drivers/Kconfig +0
-0@@ -146,6 +146,8 @@ source "drivers/remoteproc/Kconfig"source "
drivers/rpmsg/Kconfig"drivers/Kconfig +2
-0+source "drivers/soc/Kconfig" +source "
drivers/devfreq/Kconfig"source "
drivers/extcon/Kconfig"drivers/Makefile +0
-0@@ -146,6 +146,9 @@ obj-$(CONFIG_IOMMU_SUPPORT) += iommu/obj-$(CONFIG_REMOTEPROC) += remoteproc/
obj-$(CONFIG_RPMSG) += rpmsg/drivers/Makefile +3
-0+# SOC specific drivers +obj-y += soc/ +# Virtualization drivers
obj-$(CONFIG_VIRT_DRIVERS) +=virt/
obj-$(CONFIG_HYPERV) += hv/drivers/soc/Kconfig +0
-0@@ -1,3 +1,5 @@menu "SOC specific Drivers"
drivers/soc/Kconfig +2
-0+source "drivers/soc/keystone/Kconfig" +endmenu
drivers/soc/Makefile new file +5
-0@@ -0,0 +1,5 @@ +# +# Makefile for the Linux kernel SOC specific device drivers. +# + +obj-$(CONFIG_ARCH_KEYSTONE) += keystone/drivers/soc/keystone/Kconfig new file +0
-0
drivers/soc/keystone/Kconfig line 4
Quoted 4 lines
drivers/soc/keystone/Kconfig new file +4
-0@@ -0,0 +1,15 @@ +# +# TI Keystone Soc drivers +# +
We should have this be something like:
menuconfig SOC_TI
bool ?TI SoC support?
if SOC_TI
drivers/soc/keystone/Kconfig line 15
Quoted 11 lines
drivers/soc/keystone/Kconfig new file +11
-0+config KEYSTONE_QMSS + tristate "Keystone Queue Manager Sub System" + depends on ARCH_KEYSTONE + help + Say y here to support the Keystone Hardware Queue Manager support. + The Queue Manager is a hardware module that is responsible for + accelerating management of the packet queues. Packets are queued/ + de-queued by writing/reading descriptor address to a particular + memory mapped location in the Queue Manager module. + + If unsure, say N.
endif # SOC_TI
[snip]
- k
Signature · 2 lines
Employee of Qualcomm Innovation Center, Inc. Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation
Re: [PATCH 2/3] soc: keystone: add QMSS driver
Quoted 45 lines · Kumar Gala
Quoted 31 lines · Santosh Shilimkar
From: Sandeep Nair <[email protected]>
The QMSS (Queue Manager Sub System) found on Keystone SOCs is one of the main hardware sub system which forms the backbone of the Keystone Multi-core Navigator. QMSS consist of queue managers, packed-data structure processors(PDSP), linking RAM, descriptor pools and infrastructure Packet DMA.
The Queue Manager is a hardware module that is responsible for accelerating management of the packet queues. Packets are queued/de-queued by writing or reading descriptor address to a particular memory mapped location. The PDSPs perform QMSS related functions like accumulation, QoS, or event management. Linking RAM registers are used to link the descriptors which are stored in descriptor RAM. Descriptor RAM is configurable as internal or external memory.
The QMSS driver manages the PDSP setups, linking RAM regions, queue pool management (allocation, push, pop and notify) and descriptor pool management. The specifics on the device tree bindings for QMSS can be found in:
Documentation/devicetree/bindings/soc/keystone-qmss.txtCc Greg Kroah-Hartman <[email protected]>Cc Kumar Gala <[email protected]>Cc Olof Johansson <[email protected]>Cc Arnd Bergmann <[email protected]>Cc Grant Likely <[email protected]>Cc Rob Herring <[email protected]>Cc Mark Rutland <[email protected]>Signed-off-by Sandeep Nair <[email protected]>Signed-off-by Santosh Shilimkar <[email protected]>---
Quoted 10 lines
.../devicetree/bindings/soc/keystone-qmss.txt | 209 +++ drivers/Kconfig | 2 + drivers/Makefile | 3 + drivers/soc/Kconfig | 2 + drivers/soc/Makefile | 5 + drivers/soc/keystone/Kconfig | 15 + drivers/soc/keystone/Makefile | 5 + drivers/soc/keystone/qmss_acc.c | 591 ++++++++ drivers/soc/keystone/qmss_queue.c | 1533 ++++++++++++++++++++ drivers/soc/keystone/qmss_queue.h | 236 +++
Quoted 2 lines
So this should be
drivers/soc/ti, much like we use vendor indrivers/net/ethernet
Agree. I will change that.
Quoted 83 lines
Quoted 1 line
include/linux/soc/keystone_qmss.h| 390 +++++
include/linux/soc/ti/Quoted 9 lines
11 files changed, 2991 insertions(+)create mode 100644
Documentation/devicetree/bindings/soc/keystone-qmss.txtcreate mode 100644drivers/soc/Makefile
create mode 100644drivers/soc/keystone/Kconfig
create mode 100644drivers/soc/keystone/Makefile
create mode 100644drivers/soc/keystone/qmss_acc.c
create mode 100644drivers/soc/keystone/qmss_queue.c
create mode 100644drivers/soc/keystone/qmss_queue.h
create mode 100644include/linux/soc/keystone_qmss.h[snip]
Quoted 54 lines
drivers/Kconfig +0
-0@@ -146,6 +146,8 @@ source "drivers/remoteproc/Kconfig"source "
drivers/rpmsg/Kconfig"drivers/Kconfig +2
-0+source "drivers/soc/Kconfig" +source "
drivers/devfreq/Kconfig"source "
drivers/extcon/Kconfig"drivers/Makefile +0
-0@@ -146,6 +146,9 @@ obj-$(CONFIG_IOMMU_SUPPORT) += iommu/obj-$(CONFIG_REMOTEPROC) += remoteproc/
obj-$(CONFIG_RPMSG) += rpmsg/drivers/Makefile +3
-0+# SOC specific drivers +obj-y += soc/ +# Virtualization drivers
obj-$(CONFIG_VIRT_DRIVERS) +=virt/
obj-$(CONFIG_HYPERV) += hv/drivers/soc/Kconfig +0
-0@@ -1,3 +1,5 @@menu "SOC specific Drivers"
drivers/soc/Kconfig +2
-0+source "drivers/soc/keystone/Kconfig" +endmenu
drivers/soc/Makefile new file +5
-0@@ -0,0 +1,5 @@ +# +# Makefile for the Linux kernel SOC specific device drivers. +# + +obj-$(CONFIG_ARCH_KEYSTONE) += keystone/drivers/soc/keystone/Kconfig new file +0
-0drivers/soc/keystone/Kconfig line 4
Quoted 4 lines
drivers/soc/keystone/Kconfig new file +4
-0@@ -0,0 +1,15 @@ +# +# TI Keystone Soc drivers +# +We should have this be something like:
menuconfig
SOC_TI
bool ?TI SoC support?if
SOC_TI
Quoted 14 lines
drivers/soc/keystone/Kconfig line 15
Quoted 11 lines
drivers/soc/keystone/Kconfig new file +11
-0+config KEYSTONE_QMSS + tristate "Keystone Queue Manager Sub System" + depends on ARCH_KEYSTONE + help + Say y here to support the Keystone Hardware Queue Manager support. + The Queue Manager is a hardware module that is responsible for + accelerating management of the packet queues. Packets are queued/ + de-queued by writing/reading descriptor address to a particular + memory mapped location in the Queue Manager module. + + If unsure, say N.endif #
SOC_TI
Make sense.Will update the patch accordingly.
Regards,
Santosh
Re: [PATCH 2/3] soc: keystone: add QMSS driver
In reply to Santosh ShilimkarQuoted 43 lines · Santosh Shilimkar
From: Sandeep Nair <[email protected]>
The QMSS (Queue Manager Sub System) found on Keystone SOCs is one of the main hardware sub system which forms the backbone of the Keystone Multi-core Navigator. QMSS consist of queue managers, packed-data structure processors(PDSP), linking RAM, descriptor pools and infrastructure Packet DMA.
The Queue Manager is a hardware module that is responsible for accelerating management of the packet queues. Packets are queued/de-queued by writing or reading descriptor address to a particular memory mapped location. The PDSPs perform QMSS related functions like accumulation, QoS, or event management. Linking RAM registers are used to link the descriptors which are stored in descriptor RAM. Descriptor RAM is configurable as internal or external memory.
The QMSS driver manages the PDSP setups, linking RAM regions, queue pool management (allocation, push, pop and notify) and descriptor pool management. The specifics on the device tree bindings for QMSS can be found in:
Documentation/devicetree/bindings/soc/keystone-qmss.txtCc Greg Kroah-Hartman <[email protected]>Cc Kumar Gala <[email protected]>Cc Olof Johansson <[email protected]>Cc Arnd Bergmann <[email protected]>Cc Grant Likely <[email protected]>Cc Rob Herring <[email protected]>Cc Mark Rutland <[email protected]>Signed-off-by Sandeep Nair <[email protected]>Signed-off-by Santosh Shilimkar <[email protected]>---
.../devicetree/bindings/soc/keystone-qmss.txt | 209 +++ drivers/Kconfig | 2 + drivers/Makefile | 3 + drivers/soc/Kconfig | 2 + drivers/soc/Makefile | 5 + drivers/soc/keystone/Kconfig | 15 + drivers/soc/keystone/Makefile | 5 + drivers/soc/keystone/qmss_acc.c | 591 ++++++++ drivers/soc/keystone/qmss_queue.c | 1533 ++++++++++++++++++++ drivers/soc/keystone/qmss_queue.h | 236 +++ include/linux/soc/keystone_qmss.h | 390 +++++ 11 files changed, 2991 insertions(+)
Quoted 8 lines
create mode 100644
Documentation/devicetree/bindings/soc/keystone-qmss.txtcreate mode 100644drivers/soc/Makefile
create mode 100644drivers/soc/keystone/Kconfig
create mode 100644drivers/soc/keystone/Makefile
create mode 100644drivers/soc/keystone/qmss_acc.c
create mode 100644drivers/soc/keystone/qmss_queue.c
create mode 100644drivers/soc/keystone/qmss_queue.h
create mode 100644include/linux/soc/keystone_qmss.h
Do you see qmss being able to provide HW support for a qdisc or doing processor to processor communication over something like rpmsg?
I ask because I do wondering if we should be looking at a drivers/hwqueue as other vendors have similar hardware.
- k
Signature · 2 lines
Employee of Qualcomm Innovation Center, Inc. Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation
Re: [PATCH 2/3] soc: keystone: add QMSS driver
Quoted 55 lines · Kumar Gala
Quoted 43 lines · Santosh Shilimkar
From: Sandeep Nair <[email protected]>
The QMSS (Queue Manager Sub System) found on Keystone SOCs is one of the main hardware sub system which forms the backbone of the Keystone Multi-core Navigator. QMSS consist of queue managers, packed-data structure processors(PDSP), linking RAM, descriptor pools and infrastructure Packet DMA.
The Queue Manager is a hardware module that is responsible for accelerating management of the packet queues. Packets are queued/de-queued by writing or reading descriptor address to a particular memory mapped location. The PDSPs perform QMSS related functions like accumulation, QoS, or event management. Linking RAM registers are used to link the descriptors which are stored in descriptor RAM. Descriptor RAM is configurable as internal or external memory.
The QMSS driver manages the PDSP setups, linking RAM regions, queue pool management (allocation, push, pop and notify) and descriptor pool management. The specifics on the device tree bindings for QMSS can be found in:
Documentation/devicetree/bindings/soc/keystone-qmss.txtCc Greg Kroah-Hartman <[email protected]>Cc Kumar Gala <[email protected]>Cc Olof Johansson <[email protected]>Cc Arnd Bergmann <[email protected]>Cc Grant Likely <[email protected]>Cc Rob Herring <[email protected]>Cc Mark Rutland <[email protected]>Signed-off-by Sandeep Nair <[email protected]>Signed-off-by Santosh Shilimkar <[email protected]>---
.../devicetree/bindings/soc/keystone-qmss.txt | 209 +++ drivers/Kconfig | 2 + drivers/Makefile | 3 + drivers/soc/Kconfig | 2 + drivers/soc/Makefile | 5 + drivers/soc/keystone/Kconfig | 15 + drivers/soc/keystone/Makefile | 5 + drivers/soc/keystone/qmss_acc.c | 591 ++++++++ drivers/soc/keystone/qmss_queue.c | 1533 ++++++++++++++++++++ drivers/soc/keystone/qmss_queue.h | 236 +++ include/linux/soc/keystone_qmss.h | 390 +++++ 11 files changed, 2991 insertions(+)Quoted 8 lines
create mode 100644
Documentation/devicetree/bindings/soc/keystone-qmss.txtcreate mode 100644drivers/soc/Makefile
create mode 100644drivers/soc/keystone/Kconfig
create mode 100644drivers/soc/keystone/Makefile
create mode 100644drivers/soc/keystone/qmss_acc.c
create mode 100644drivers/soc/keystone/qmss_queue.c
create mode 100644drivers/soc/keystone/qmss_queue.h
create mode 100644include/linux/soc/keystone_qmss.h
Quoted 4 lines
Do you see qmss being able to provide HW support for a qdisc or doing processor to processor communication over something like rpmsg?
I ask because I do wondering if we should be looking at a
drivers/hwqueueas other vendors have similar hardware.
QMSS just provides the programming interfaces so that certain queues can be configured to achieve QOS tree. The actual qdisc should be part of the network driver as such. The queues are such a generic hardware that it can be used for wide variety of usecases and supporting that through one driver will be really hard. We did talk of hwqueue last year but looks like the usecase variety is too much because of generic nature of them.
QMSS isn't used as such for message passing but queue hardware can be used as done by APM hardware which Arnd pointed me on the other thread. As Arnd recommended, the processor to processor communication related drivers should go under drivers/mailbox. One example, was the APM QMTM patchset [1]
Quoted 1 line
From first look the QMSS(APM) and QMTM(APM) looked very similar but they actually differ largely the way it works. Thanks to Arnd
for useful discussion here at connect, I better understood how the QMTM works.
If you know any other hardware, which needs similar interfaces as QMSS, we can surely think of another subsystem. QMSS is largely network usecase dominated but not limited to only those usecases. It is also used by pure drivers/crypto/ or can also be used for data movement for video etc.
Regards,
Santosh
Re: [PATCH 2/3] soc: keystone: add QMSS driver
Quoted 72 lines · Santosh Shilimkar
Quoted 55 lines · Kumar Gala
Quoted 43 lines · Santosh Shilimkar
From: Sandeep Nair <[email protected]>
The QMSS (Queue Manager Sub System) found on Keystone SOCs is one of the main hardware sub system which forms the backbone of the Keystone Multi-core Navigator. QMSS consist of queue managers, packed-data structure processors(PDSP), linking RAM, descriptor pools and infrastructure Packet DMA.
The Queue Manager is a hardware module that is responsible for accelerating management of the packet queues. Packets are queued/de-queued by writing or reading descriptor address to a particular memory mapped location. The PDSPs perform QMSS related functions like accumulation, QoS, or event management. Linking RAM registers are used to link the descriptors which are stored in descriptor RAM. Descriptor RAM is configurable as internal or external memory.
The QMSS driver manages the PDSP setups, linking RAM regions, queue pool management (allocation, push, pop and notify) and descriptor pool management. The specifics on the device tree bindings for QMSS can be found in:
Documentation/devicetree/bindings/soc/keystone-qmss.txtCc Greg Kroah-Hartman <[email protected]>Cc Kumar Gala <[email protected]>Cc Olof Johansson <[email protected]>Cc Arnd Bergmann <[email protected]>Cc Grant Likely <[email protected]>Cc Rob Herring <[email protected]>Cc Mark Rutland <[email protected]>Signed-off-by Sandeep Nair <[email protected]>Signed-off-by Santosh Shilimkar <[email protected]>---
.../devicetree/bindings/soc/keystone-qmss.txt | 209 +++ drivers/Kconfig | 2 + drivers/Makefile | 3 + drivers/soc/Kconfig | 2 + drivers/soc/Makefile | 5 + drivers/soc/keystone/Kconfig | 15 + drivers/soc/keystone/Makefile | 5 + drivers/soc/keystone/qmss_acc.c | 591 ++++++++ drivers/soc/keystone/qmss_queue.c | 1533 ++++++++++++++++++++ drivers/soc/keystone/qmss_queue.h | 236 +++ include/linux/soc/keystone_qmss.h | 390 +++++ 11 files changed, 2991 insertions(+)Quoted 8 lines
create mode 100644
Documentation/devicetree/bindings/soc/keystone-qmss.txtcreate mode 100644drivers/soc/Makefile
create mode 100644drivers/soc/keystone/Kconfig
create mode 100644drivers/soc/keystone/Makefile
create mode 100644drivers/soc/keystone/qmss_acc.c
create mode 100644drivers/soc/keystone/qmss_queue.c
create mode 100644drivers/soc/keystone/qmss_queue.h
create mode 100644include/linux/soc/keystone_qmss.hQuoted 4 lines
Do you see qmss being able to provide HW support for a qdisc or doing processor to processor communication over something like rpmsg?
I ask because I do wondering if we should be looking at a
drivers/hwqueueas other vendors have similar hardware.QMSS just provides the programming interfaces so that certain queues can be configured to achieve QOS tree. The actual qdisc should be part of the network driver as such. The queues are such a generic hardware that it can be used for wide variety of usecases and supporting that through one driver will be really hard. We did talk of hwqueue last year but looks like the usecase variety is too much because of generic nature of them.
QMSS isn't used as such for message passing but queue hardware can be used as done by APM hardware which Arnd pointed me on the other thread. As Arnd recommended, the processor to processor communication related drivers should go under
drivers/mailbox. One example, was the APM QMTM patchset [1]From first look the QMSS(APM) and QMTM(APM) looked very similar but they actually differ largely the way it works. Thanks to Arnd for useful discussion here at connect, I better understood how the QMTM works.
Quoted 8 lines
If you know any other hardware, which needs similar interfaces as QMSS, we can surely think of another subsystem. QMSS is largely network usecase dominated but not limited to only those usecases. It is also used by pure
drivers/crypto/or can also be used for data movement for video etc.Regards,
Santosh
The Freescale QorIQ Devices have a Queue Manager (QMan) as part of their Data Path Architecture (DPAA). I haven?t looked at the QMTM from APM, but not sure if mailbox is the best place for these things. They seem so much more involved than what I?m guessing most people are thinking with mailbox.
- k
Signature · 2 lines
Employee of Qualcomm Innovation Center, Inc. Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation
Re: [PATCH 2/3] soc: keystone: add QMSS driver
Quoted 79 lines · Kumar Gala
Quoted 76 lines · Santosh Shilimkar
Quoted 55 lines · Kumar Gala
Quoted 43 lines · Santosh Shilimkar
From: Sandeep Nair <[email protected]>
The QMSS (Queue Manager Sub System) found on Keystone SOCs is one of the main hardware sub system which forms the backbone of the Keystone Multi-core Navigator. QMSS consist of queue managers, packed-data structure processors(PDSP), linking RAM, descriptor pools and infrastructure Packet DMA.
The Queue Manager is a hardware module that is responsible for accelerating management of the packet queues. Packets are queued/de-queued by writing or reading descriptor address to a particular memory mapped location. The PDSPs perform QMSS related functions like accumulation, QoS, or event management. Linking RAM registers are used to link the descriptors which are stored in descriptor RAM. Descriptor RAM is configurable as internal or external memory.
The QMSS driver manages the PDSP setups, linking RAM regions, queue pool management (allocation, push, pop and notify) and descriptor pool management. The specifics on the device tree bindings for QMSS can be found in:
Documentation/devicetree/bindings/soc/keystone-qmss.txtCc Greg Kroah-Hartman <[email protected]>Cc Kumar Gala <[email protected]>Cc Olof Johansson <[email protected]>Cc Arnd Bergmann <[email protected]>Cc Grant Likely <[email protected]>Cc Rob Herring <[email protected]>Cc Mark Rutland <[email protected]>Signed-off-by Sandeep Nair <[email protected]>Signed-off-by Santosh Shilimkar <[email protected]>---
.../devicetree/bindings/soc/keystone-qmss.txt | 209 +++ drivers/Kconfig | 2 + drivers/Makefile | 3 + drivers/soc/Kconfig | 2 + drivers/soc/Makefile | 5 + drivers/soc/keystone/Kconfig | 15 + drivers/soc/keystone/Makefile | 5 + drivers/soc/keystone/qmss_acc.c | 591 ++++++++ drivers/soc/keystone/qmss_queue.c | 1533 ++++++++++++++++++++ drivers/soc/keystone/qmss_queue.h | 236 +++ include/linux/soc/keystone_qmss.h | 390 +++++ 11 files changed, 2991 insertions(+)Quoted 8 lines
create mode 100644
Documentation/devicetree/bindings/soc/keystone-qmss.txtcreate mode 100644drivers/soc/Makefile
create mode 100644drivers/soc/keystone/Kconfig
create mode 100644drivers/soc/keystone/Makefile
create mode 100644drivers/soc/keystone/qmss_acc.c
create mode 100644drivers/soc/keystone/qmss_queue.c
create mode 100644drivers/soc/keystone/qmss_queue.h
create mode 100644include/linux/soc/keystone_qmss.hQuoted 4 lines
Do you see qmss being able to provide HW support for a qdisc or doing processor to processor communication over something like rpmsg?
I ask because I do wondering if we should be looking at a
drivers/hwqueueas other vendors have similar hardware.QMSS just provides the programming interfaces so that certain queues can be configured to achieve QOS tree. The actual qdisc should be part of the network driver as such. The queues are such a generic hardware that it can be used for wide variety of usecases and supporting that through one driver will be really hard. We did talk of hwqueue last year but looks like the usecase variety is too much because of generic nature of them.
QMSS isn't used as such for message passing but queue hardware can be used as done by APM hardware which Arnd pointed me on the other thread. As Arnd recommended, the processor to processor communication related drivers should go under
drivers/mailbox. One example, was the APM QMTM patchset [1]From first look the QMSS(APM) and QMTM(APM) looked very similar but they actually differ largely the way it works. Thanks to Arnd for useful discussion here at connect, I better understood how the QMTM works.
If you know any other hardware, which needs similar interfaces as QMSS, we can surely think of another subsystem. QMSS is largely network usecase dominated but not limited to only those usecases. It is also used by pure
drivers/crypto/or can also be used for data movement for video etc.
[..]
Quoted 4 lines
Quoted 1 line
The Freescale QorIQ Devices have a Queue Manager (QMan) as part of their Data Path Architecture (DPAA). I haven?t looked at the QMTM from APM, but not sure if mailbox is the best place for these things. They seem so much more involved than what I?m guessing most people are thinking with mailbox.
I also felt that even for APM case mailbox may not be the right subsystem but seems like the whole QMTM is based on message passing and thats why Arnd suggested the drives/mailbox
At least for TI QMSS, we didn't find any suitable existing subsystem so far. Arnd also agreed that we can't fit the QMSS in mailbox subsystem. If there are more hardware which would like to have similar subsystem interfaces like QMSS, am more than happy to work with them on common interfaces. As you know, I tried this last year as well but heard none. Arnd also suggested that we look at interfaces are geared towards more sophisticated cases like Open VSwitch.
So my current plan is stick to drivers/soc/ and focus more and getting interfaces and bindings right. So any help reviewing those would be greatly appreciated.
Regards,
Santosh
Re: [PATCH 2/3] soc: keystone: add QMSS driver
In reply to Santosh ShilimkarQuoted 15 lines · Santosh Shilimkar
From: Sandeep Nair <[email protected]>
The QMSS (Queue Manager Sub System) found on Keystone SOCs is one of the main hardware sub system which forms the backbone of the Keystone Multi-core Navigator. QMSS consist of queue managers, packed-data structure processors(PDSP), linking RAM, descriptor pools and infrastructure Packet DMA.
The Queue Manager is a hardware module that is responsible for accelerating management of the packet queues. Packets are queued/de-queued by writing or reading descriptor address to a particular memory mapped location. The PDSPs perform QMSS related functions like accumulation, QoS, or event management. Linking RAM registers are used to link the descriptors which are stored in descriptor RAM. Descriptor RAM is configurable as internal or external memory.
Quoted 5 lines
The QMSS driver manages the PDSP setups, linking RAM regions, queue pool management (allocation, push, pop and notify) and descriptor pool management. The specifics on the device tree bindings for QMSS can be found in:
Documentation/devicetree/bindings/soc/keystone-qmss.txt
You are telling me where I can find a file that is added in this commit?
All this description of what the h/w block does should go into the binding doc.
Quoted 54 lines
Cc Greg Kroah-Hartman <[email protected]>Cc Kumar Gala <[email protected]>Cc Olof Johansson <[email protected]>Cc Arnd Bergmann <[email protected]>Cc Grant Likely <[email protected]>Cc Rob Herring <[email protected]>Cc Mark Rutland <[email protected]>Signed-off-by Sandeep Nair <[email protected]>Signed-off-by Santosh Shilimkar <[email protected]>--- .../devicetree/bindings/soc/keystone-qmss.txt | 209 +++ drivers/Kconfig | 2 + drivers/Makefile | 3 + drivers/soc/Kconfig | 2 + drivers/soc/Makefile | 5 + drivers/soc/keystone/Kconfig | 15 + drivers/soc/keystone/Makefile | 5 + drivers/soc/keystone/qmss_acc.c | 591 ++++++++ drivers/soc/keystone/qmss_queue.c | 1533 ++++++++++++++++++++ drivers/soc/keystone/qmss_queue.h | 236 +++ include/linux/soc/keystone_qmss.h | 390 +++++ 11 files changed, 2991 insertions(+) create mode 100644 Documentation/devicetree/bindings/soc/keystone-qmss.txt create mode 100644 drivers/soc/Makefile create mode 100644 drivers/soc/keystone/Kconfig create mode 100644 drivers/soc/keystone/Makefile create mode 100644 drivers/soc/keystone/qmss_acc.c create mode 100644 drivers/soc/keystone/qmss_queue.c create mode 100644 drivers/soc/keystone/qmss_queue.h create mode 100644 include/linux/soc/keystone_qmss.hDocumentation/devicetree/bindings/soc/keystone-qmss.txt new file +16
-0@@ -0,0 +1,209 @@ +* Texas Instruments Keystone QMSS driver + +Required properties: +- compatible : Must be "ti,keystone-qmss"; +- clocks : phandle to the reference clock for this device. +- queue-range : <start number> total range of queue numbers for the device. +- linkram0 : <address size> for internal link ram, where size is the total + link ram entries. +- linkram1 : <address size> for external link ram, where size is the total + external link ram entries. If the address is specified as "0" + driver will allocate memory. +- qmgrs : the number of individual queue managers in the device. On + keystone 1 range of devices there should be only one node. + On keystone 2 devices there can be more than 1 node. + -- managed-queues : the actual queues managed by each queue manager + instance, specified as <"base queue #" "# of queues">.
Documentation/devicetree/bindings/soc/keystone-qmss.txt line 26
Quoted 10 lines
Documentation/devicetree/bindings/soc/keystone-qmss.txt new file +10
-0+ -- reg : Address and length of the register set for the device + for peek, status, config, region, push, pop regions. + -- reg-names : Names for the above register regions. The name to be + used is as follows: + - "config" : Queue configuration region. + - "status" : Queue status RAM. + - "region" : Descriptor memory setup region. + - "push" : Queue Management/Queue Proxy region. + - "pop" : Queue Management/Queue Proxy region. + - "peek" : Queue Peek region.
reg-names should be optional. Also you have the order different from reg. Be consistent as to what is the correct order.
Documentation/devicetree/bindings/soc/keystone-qmss.txt line 35
Quoted 9 lines
Documentation/devicetree/bindings/soc/keystone-qmss.txt new file +9
-0+- queue-pools : Queue ranges are grouped into 3 type of pools: + - qpend : pool of qpend(interruptible) queues + - general-purpose : pool of general queues, primarly used + as free descriptor queues or the + transmit DMA queues. + - accumulator : pool of queues on accumulator channel + Each range can have the following properties: + -- values : number of queues to use per queue range, specified as + <"base queue #" "# of queues">.
values of what? This needs a better name.
Documentation/devicetree/bindings/soc/keystone-qmss.txt line 40
Quoted 5 lines
Documentation/devicetree/bindings/soc/keystone-qmss.txt new file +5
-0+ -- interrupts : Optional property to specify the interrupt mapping + for interruptible queues. The driver additionaly sets + the interrupt affinity based on the cpu mask. + -- reserved : Optional property used to reserve the range. Queues + in a reserved range can only be allocated by id.
reserved what? This needs a better name and description.
Quoted 6 lines
Documentation/devicetree/bindings/soc/keystone-qmss.txt new file +6
-0+ -- accumulator : Accumulator channel property specified as: + <pdsp-id, channel, entries, pacing mode, latency> + pdsp-id : QMSS PDSP running accumulator firmware + on which the channel has to be + configured + channel : Accumulator channel number
Documentation/devicetree/bindings/soc/keystone-qmss.txt line 56
Quoted 10 lines
Documentation/devicetree/bindings/soc/keystone-qmss.txt new file +10
-0+ entries : Size of the accumulator descriptor list + pacing mode : Interrupt pacing mode + 0 : None, i.e interrupt on list full + 1 : Time delay since last interrupt + 2 : Time delay since first new packet + 3 : Time delay since last new packet + latency : time to delay the interrupt, specified + in microseconds. + -- multi-queue : Optional property to specify that the channel has to + monitor upto 32 queues starting at the base queue #.
What does the property contain? What's a channel in this context?
Documentation/devicetree/bindings/soc/keystone-qmss.txt line 57
Quoted 1 line
Documentation/devicetree/bindings/soc/keystone-qmss.txt new file +1
-0+- descriptor-regions : Descriptor memory region specification.
huh?
Documentation/devicetree/bindings/soc/keystone-qmss.txt line 67
Quoted 10 lines
Documentation/devicetree/bindings/soc/keystone-qmss.txt new file +10
-0+ -- id : region number. + -- values : number of descriptors in the region, + specified as + <"# of descriptors" "descriptor size">. + -- link-index : start index, i.e. index of the first + descriptor in the region. + +Optional properties: +- dma-coherent : Present if DMA operations are coherent. +- pdsps : PDSP configuration, if any.
This is a child node? Make that clear and separate the description for each node.
Documentation/devicetree/bindings/soc/keystone-qmss.txt line 79
Quoted 12 lines
Documentation/devicetree/bindings/soc/keystone-qmss.txt new file +12
-0+ -- firmware : firmware to be loaded on the PDSP. + -- id : the qmss pdsp that will run the firmware. + -- reg : Address and length of the register set of the PDSP + for iram, intd, region, command regions. + -- reg-names : Names for the above register regions. The name to be + used is as follows: + - "iram" : PDSP internal RAM region. + - "reg" : PDSP control/status region registers. + - "intd" : QMSS interrupt distributor registers. + - "cmd" : PDSP command interface region. + +Example:
I probably have other comments, but address the above first.
Rob
Re: [PATCH 2/3] soc: keystone: add QMSS driver
Quoted 23 lines · Rob Herring
Quoted 15 lines · Santosh Shilimkar
From: Sandeep Nair <[email protected]>
The QMSS (Queue Manager Sub System) found on Keystone SOCs is one of the main hardware sub system which forms the backbone of the Keystone Multi-core Navigator. QMSS consist of queue managers, packed-data structure processors(PDSP), linking RAM, descriptor pools and infrastructure Packet DMA.
The Queue Manager is a hardware module that is responsible for accelerating management of the packet queues. Packets are queued/de-queued by writing or reading descriptor address to a particular memory mapped location. The PDSPs perform QMSS related functions like accumulation, QoS, or event management. Linking RAM registers are used to link the descriptors which are stored in descriptor RAM. Descriptor RAM is configurable as internal or external memory.
Quoted 5 lines
The QMSS driver manages the PDSP setups, linking RAM regions, queue pool management (allocation, push, pop and notify) and descriptor pool management. The specifics on the device tree bindings for QMSS can be found in:
Documentation/devicetree/bindings/soc/keystone-qmss.txt
Quoted 4 lines
You are telling me where I can find a file that is added in this commit?
All this description of what the h/w block does should go into the binding doc.
Sure. Will do.
Quoted 59 lines
Quoted 59 lines
Cc Greg Kroah-Hartman <[email protected]>Cc Kumar Gala <[email protected]>Cc Olof Johansson <[email protected]>Cc Arnd Bergmann <[email protected]>Cc Grant Likely <[email protected]>Cc Rob Herring <[email protected]>Cc Mark Rutland <[email protected]>Signed-off-by Sandeep Nair <[email protected]>Signed-off-by Santosh Shilimkar <[email protected]>--- .../devicetree/bindings/soc/keystone-qmss.txt | 209 +++ drivers/Kconfig | 2 + drivers/Makefile | 3 + drivers/soc/Kconfig | 2 + drivers/soc/Makefile | 5 + drivers/soc/keystone/Kconfig | 15 + drivers/soc/keystone/Makefile | 5 + drivers/soc/keystone/qmss_acc.c | 591 ++++++++ drivers/soc/keystone/qmss_queue.c | 1533 ++++++++++++++++++++ drivers/soc/keystone/qmss_queue.h | 236 +++ include/linux/soc/keystone_qmss.h | 390 +++++ 11 files changed, 2991 insertions(+) create mode 100644 Documentation/devicetree/bindings/soc/keystone-qmss.txt create mode 100644 drivers/soc/Makefile create mode 100644 drivers/soc/keystone/Kconfig create mode 100644 drivers/soc/keystone/Makefile create mode 100644 drivers/soc/keystone/qmss_acc.c create mode 100644 drivers/soc/keystone/qmss_queue.c create mode 100644 drivers/soc/keystone/qmss_queue.h create mode 100644 include/linux/soc/keystone_qmss.hDocumentation/devicetree/bindings/soc/keystone-qmss.txt new file +21
-0@@ -0,0 +1,209 @@ +* Texas Instruments Keystone QMSS driver + +Required properties: +- compatible : Must be "ti,keystone-qmss"; +- clocks : phandle to the reference clock for this device. +- queue-range : <start number> total range of queue numbers for the device. +- linkram0 : <address size> for internal link ram, where size is the total + link ram entries. +- linkram1 : <address size> for external link ram, where size is the total + external link ram entries. If the address is specified as "0" + driver will allocate memory. +- qmgrs : the number of individual queue managers in the device. On + keystone 1 range of devices there should be only one node. + On keystone 2 devices there can be more than 1 node. + -- managed-queues : the actual queues managed by each queue manager + instance, specified as <"base queue #" "# of queues">. + -- reg : Address and length of the register set for the device + for peek, status, config, region, push, pop regions. + -- reg-names : Names for the above register regions. The name to be + used is as follows: + - "config" : Queue configuration region.
Quoted 9 lines
Documentation/devicetree/bindings/soc/keystone-qmss.txt line 26
Quoted 5 lines
Documentation/devicetree/bindings/soc/keystone-qmss.txt new file +5
-0+ - "status" : Queue status RAM. + - "region" : Descriptor memory setup region. + - "push" : Queue Management/Queue Proxy region. + - "pop" : Queue Management/Queue Proxy region. + - "peek" : Queue Peek region.reg-names should be optional. Also you have the order different from reg. Be consistent as to what is the correct order.
We thought of using reg-names to remove the ordering to index the regs. So if we make the reg-names optional, then indexing by order will be used. We can do that.
Quoted 11 lines
Documentation/devicetree/bindings/soc/keystone-qmss.txt line 35
Quoted 9 lines
Documentation/devicetree/bindings/soc/keystone-qmss.txt new file +9
-0+- queue-pools : Queue ranges are grouped into 3 type of pools: + - qpend : pool of qpend(interruptible) queues + - general-purpose : pool of general queues, primarly used + as free descriptor queues or the + transmit DMA queues. + - accumulator : pool of queues on accumulator channel + Each range can have the following properties: + -- values : number of queues to use per queue range, specified as + <"base queue #" "# of queues">.values of what? This needs a better name.
ok. Will use 'qrange-values'
Quoted 9 lines
Documentation/devicetree/bindings/soc/keystone-qmss.txt line 40
Quoted 6 lines
Documentation/devicetree/bindings/soc/keystone-qmss.txt new file +5
-0+ -- interrupts : Optional property to specify the interrupt mapping + for interruptible queues. The driver additionaly sets + the interrupt affinity based on the cpu mask. + -- reserved : Optional property used to reserve the range. Queues + in a reserved range can only be allocated by id.reserved what? This needs a better name and description.
'qrange-reserved'. Will update the description.
Quoted 17 lines
Quoted 6 lines
Documentation/devicetree/bindings/soc/keystone-qmss.txt new file +6
-0+ -- accumulator : Accumulator channel property specified as: + <pdsp-id, channel, entries, pacing mode, latency> + pdsp-id : QMSS PDSP running accumulator firmware + on which the channel has to be + configured + channel : Accumulator channel numberDocumentation/devicetree/bindings/soc/keystone-qmss.txt line 56
Quoted 10 lines
Documentation/devicetree/bindings/soc/keystone-qmss.txt new file +10
-0+ entries : Size of the accumulator descriptor list + pacing mode : Interrupt pacing mode + 0 : None, i.e interrupt on list full + 1 : Time delay since last interrupt + 2 : Time delay since first new packet + 3 : Time delay since last new packet + latency : time to delay the interrupt, specified + in microseconds. + -- multi-queue : Optional property to specify that the channel has to + monitor upto 32 queues starting at the base queue #.
Quoted 2 lines
What does the property contain? What's a channel in this context?
Its accumulator channel who can monitor multiple queues. Its a hardware off-load feature to monitor and accumulate the traffic on multiple queues.
Quoted 3 lines
Documentation/devicetree/bindings/soc/keystone-qmss.txt line 57
Quoted 1 line
Documentation/devicetree/bindings/soc/keystone-qmss.txt new file +1
-0+- descriptor-regions : Descriptor memory region specification.huh?
Ok. We will make the description bit more verbose to make it clear.
Quoted 15 lines
Documentation/devicetree/bindings/soc/keystone-qmss.txt line 67
Quoted 11 lines
Documentation/devicetree/bindings/soc/keystone-qmss.txt new file +10
-0+ -- id : region number. + -- values : number of descriptors in the region, + specified as + <"# of descriptors" "descriptor size">. + -- link-index : start index, i.e. index of the first + descriptor in the region. + +Optional properties: +- dma-coherent : Present if DMA operations are coherent. +- pdsps : PDSP configuration, if any.This is a child node? Make that clear and separate the description for each node.
Sure.
Quoted 6 lines
Quoted 6 lines
Documentation/devicetree/bindings/soc/keystone-qmss.txt new file +6
-0+ -- firmware : firmware to be loaded on the PDSP. + -- id : the qmss pdsp that will run the firmware. + -- reg : Address and length of the register set of the PDSP + for iram, intd, region, command regions. + -- reg-names : Names for the above register regions. The name to be + used is as follows:
Quoted 9 lines
Documentation/devicetree/bindings/soc/keystone-qmss.txt line 79
Quoted 6 lines
Documentation/devicetree/bindings/soc/keystone-qmss.txt new file +6
-0+ - "iram" : PDSP internal RAM region. + - "reg" : PDSP control/status region registers. + - "intd" : QMSS interrupt distributor registers. + - "cmd" : PDSP command interface region. + +Example:I probably have other comments, but address the above first.
Thanks for the comments. We will address these in next version.
Regards,
Santosh
Re: [PATCH 2/3] soc: keystone: add QMSS driver
Quoted 9 lines · Santosh Shilimkar
Quoted 9 lines
Quoted 8 lines
Documentation/devicetree/bindings/soc/keystone-qmss.txt new file +8
-0+ -- reg-names : Names for the above register regions. The name to be + used is as follows: + - "config" : Queue configuration region. + - "status" : Queue status RAM. + - "region" : Descriptor memory setup region. + - "push" : Queue Management/Queue Proxy region. + - "pop" : Queue Management/Queue Proxy region. + - "peek" : Queue Peek region.
Quoted 6 lines
Quoted 3 lines
reg-names should be optional. Also you have the order different from reg. Be consistent as to what is the correct order.
We thought of using reg-names to remove the ordering to index the regs. So if we make the reg-names optional, then indexing by order will be used. We can do that.
We keep having this conversation, why does reg-names need to be optional for new bindings?
- k
Signature · 2 lines
Employee of Qualcomm Innovation Center, Inc. Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation
Re: [PATCH 2/3] soc: keystone: add QMSS driver
Quoted 12 lines · Kumar Gala
Quoted 9 lines · Santosh Shilimkar
Quoted 9 lines
Quoted 8 lines
Documentation/devicetree/bindings/soc/keystone-qmss.txt new file +8
-0+ -- reg-names : Names for the above register regions. The name to be + used is as follows: + - "config" : Queue configuration region. + - "status" : Queue status RAM. + - "region" : Descriptor memory setup region. + - "push" : Queue Management/Queue Proxy region. + - "pop" : Queue Management/Queue Proxy region. + - "peek" : Queue Peek region.
Quoted 9 lines
Quoted 6 lines
Quoted 3 lines
reg-names should be optional. Also you have the order different from reg. Be consistent as to what is the correct order.
We thought of using reg-names to remove the ordering to index the regs. So if we make the reg-names optional, then indexing by order will be used. We can do that.
We keep having this conversation, why does reg-names need to be optional for new bindings?
I guess the question is for Rob.
Regards,
Santosh
Re: [PATCH 2/3] soc: keystone: add QMSS driver
In reply to Kumar GalaQuoted 12 lines · Kumar Gala
Quoted 9 lines · Santosh Shilimkar
Quoted 9 lines
Quoted 8 lines
Documentation/devicetree/bindings/soc/keystone-qmss.txt new file +8
-0+ -- reg-names : Names for the above register regions. The name to be + used is as follows: + - "config" : Queue configuration region. + - "status" : Queue status RAM. + - "region" : Descriptor memory setup region. + - "push" : Queue Management/Queue Proxy region. + - "pop" : Queue Management/Queue Proxy region. + - "peek" : Queue Peek region.
Quoted 8 lines
Quoted 6 lines
Quoted 3 lines
reg-names should be optional. Also you have the order different from reg. Be consistent as to what is the correct order.
We thought of using reg-names to remove the ordering to index the regs. So if we make the reg-names optional, then indexing by order will be used. We can do that.
We keep having this conversation, why does reg-names need to be optional for new bindings?
Because order is a fundamental part of the reg and interrupts properties and has been since the beginning of DT. Adding auxiliary data does not change that. We just discussed this in our weekly DT meeting[1]. In many cases defining the order is not a burden. For the exceptions, the binding needs to spell out why the order can't be fixed.
Rob
[1] http://irclogs.linaro.org/meeting-logs/devicetree/2014/devicetree.2014-03-11-14.09.log.html
PATCH 3/3 firmware: add Keystone QMSS PDSP accumulator firmware blob
In reply to Santosh ShilimkarFrom: Sandeep Nair <[email protected]>
QMSS(Queue Manager Sub System) uses PDSPs to implement various QM related functions like packet accumulation, QoS or event management.
Patch adds firmware blob for the QMSS accumulator
functionality.
--- firmware/Makefile | 1 + .../keystone/qmss_pdsp_acc48_k2_le_1_0_0_8.fw.ihex | 110 ++++++++++++++++++++ 2 files changed, 111 insertions(+) create mode 100644 firmware/keystone/qmss_pdsp_acc48_k2_le_1_0_0_8.fw.ihex
firmware/Makefile +1 -0
@@ -29,6 +29,7 @@ endif fw-shipped-$(CONFIG_ACENIC) += $(acenic-objs) fw-shipped-$(CONFIG_ADAPTEC_STARFIRE) += adaptec/starfire_rx.bin \ adaptec/starfire_tx.bin +fw-shipped-$(CONFIG_ARCH_KEYSTONE) += keystone/qmss_pdsp_acc48_k2_le_1_0_0_8.fw fw-shipped-$(CONFIG_ATARI_DSP56K) += dsp56k/bootstrap.bin fw-shipped-$(CONFIG_ATM_AMBASSADOR) += atmsar11.fw fw-shipped-$(CONFIG_BNX2X) += bnx2x/bnx2x-e1-6.2.9.0.fw \
firmware/keystone/qmss_pdsp_acc48_k2_le_1_0_0_8.fw.ihex new file +110 -0
110 lines not on this page · raw message
Signature · 1 line
1.7.9.5