* [PATCH v4 0/3]
@ 2015-10-14 14:17 ` Murali Karicheri
0 siblings, 0 replies; 28+ messages in thread
From: Murali Karicheri @ 2015-10-14 14:17 UTC (permalink / raw)
To: corbet, ssantosh, linux-doc, linux-kernel, linux-arm-kernel,
robh+dt, pawel.moll, mark.rutland, ijc+devicetree, galak, linux,
devicetree, arnd
This patch series enable accumulator queue support for K2 SoCs. Accumulator
queues are a type of qmss queue that is monitored by the PDSP firmware and
accumulated. Host is interrupted by PDSP firmware when packets become
available in a ring buffer shared between the host and PDSP.
There was an issue raised when merging the original patch set at
(1) https://lkml.org/lkml/2015/9/4/681
[PATCH v1 1/2] soc: ti: display firmware file name as part of boot log
(2) https://lkml.org/lkml/2015/9/4/680
[PATCH v1 2/2] ARM: dts: keystone: enable accumulator channels
This series fixes the issues raised against v3. Maintainer, could you please
apply this series to v4.4 next please at your earliest opportunity.
Change Log
==========
v4
- collected Acked-by from Arnd Bergmann against 1/3
v3
- Added Arnd's Acked-by against 2/4
- 1/4 modified not to touch the DT documentation per Rob's comment.
- Removed DTS update from the series per Santosh. Will send the same
as a separate patch
v2
- Remove the firmware filename from DT and add it to the driver.
Use a name ks2_qmss_pdsp_acc48.bin. The idea is this can be a
soft link pointing to the real firmware file in file system.
- Move the description of the driver design from DT document to one
under Documentation/arm/keystone/knav-qmss.txt. Update the this
document with location of acc firmware available under
linux-firmware.git.
- Additionally added accumulator queue support optional so that lack
of firmware in the file system will not cause other queue types not
available due to driver probe failure.
Murali Karicheri (3):
Documentation: dt: soc: Add description for knav qmss driver
soc: ti: add firmware file name as part of the driver
soc: ti: qmss: make acc queue support optional in the driver
Documentation/arm/keystone/knav-qmss.txt | 56 ++++++++++++++++++
.../bindings/soc/ti/keystone-navigator-qmss.txt | 1 -
drivers/soc/ti/knav_qmss.h | 3 +-
drivers/soc/ti/knav_qmss_acc.c | 10 +++-
drivers/soc/ti/knav_qmss_queue.c | 67 ++++++++++++++--------
5 files changed, 109 insertions(+), 28 deletions(-)
create mode 100644 Documentation/arm/keystone/knav-qmss.txt
--
1.9.1
^ permalink raw reply [flat|nested] 28+ messages in thread
* [PATCH v4 0/3]
@ 2015-10-14 14:17 ` Murali Karicheri
0 siblings, 0 replies; 28+ messages in thread
From: Murali Karicheri @ 2015-10-14 14:17 UTC (permalink / raw)
To: linux-arm-kernel
This patch series enable accumulator queue support for K2 SoCs. Accumulator
queues are a type of qmss queue that is monitored by the PDSP firmware and
accumulated. Host is interrupted by PDSP firmware when packets become
available in a ring buffer shared between the host and PDSP.
There was an issue raised when merging the original patch set at
(1) https://lkml.org/lkml/2015/9/4/681
[PATCH v1 1/2] soc: ti: display firmware file name as part of boot log
(2) https://lkml.org/lkml/2015/9/4/680
[PATCH v1 2/2] ARM: dts: keystone: enable accumulator channels
This series fixes the issues raised against v3. Maintainer, could you please
apply this series to v4.4 next please at your earliest opportunity.
Change Log
==========
v4
- collected Acked-by from Arnd Bergmann against 1/3
v3
- Added Arnd's Acked-by against 2/4
- 1/4 modified not to touch the DT documentation per Rob's comment.
- Removed DTS update from the series per Santosh. Will send the same
as a separate patch
v2
- Remove the firmware filename from DT and add it to the driver.
Use a name ks2_qmss_pdsp_acc48.bin. The idea is this can be a
soft link pointing to the real firmware file in file system.
- Move the description of the driver design from DT document to one
under Documentation/arm/keystone/knav-qmss.txt. Update the this
document with location of acc firmware available under
linux-firmware.git.
- Additionally added accumulator queue support optional so that lack
of firmware in the file system will not cause other queue types not
available due to driver probe failure.
Murali Karicheri (3):
Documentation: dt: soc: Add description for knav qmss driver
soc: ti: add firmware file name as part of the driver
soc: ti: qmss: make acc queue support optional in the driver
Documentation/arm/keystone/knav-qmss.txt | 56 ++++++++++++++++++
.../bindings/soc/ti/keystone-navigator-qmss.txt | 1 -
drivers/soc/ti/knav_qmss.h | 3 +-
drivers/soc/ti/knav_qmss_acc.c | 10 +++-
drivers/soc/ti/knav_qmss_queue.c | 67 ++++++++++++++--------
5 files changed, 109 insertions(+), 28 deletions(-)
create mode 100644 Documentation/arm/keystone/knav-qmss.txt
--
1.9.1
^ permalink raw reply [flat|nested] 28+ messages in thread
* [PATCH v4 0/3]
@ 2015-10-14 14:17 ` Murali Karicheri
0 siblings, 0 replies; 28+ messages in thread
From: Murali Karicheri @ 2015-10-14 14:17 UTC (permalink / raw)
To: corbet, ssantosh, linux-doc, linux-kernel, linux-arm-kernel,
robh+dt, pawel.moll, mark.rutland, ijc+devicetree, galak, linux,
devicetree, arnd
This patch series enable accumulator queue support for K2 SoCs. Accumulator
queues are a type of qmss queue that is monitored by the PDSP firmware and
accumulated. Host is interrupted by PDSP firmware when packets become
available in a ring buffer shared between the host and PDSP.
There was an issue raised when merging the original patch set at
(1) https://lkml.org/lkml/2015/9/4/681
[PATCH v1 1/2] soc: ti: display firmware file name as part of boot log
(2) https://lkml.org/lkml/2015/9/4/680
[PATCH v1 2/2] ARM: dts: keystone: enable accumulator channels
This series fixes the issues raised against v3. Maintainer, could you please
apply this series to v4.4 next please at your earliest opportunity.
Change Log
==========
v4
- collected Acked-by from Arnd Bergmann against 1/3
v3
- Added Arnd's Acked-by against 2/4
- 1/4 modified not to touch the DT documentation per Rob's comment.
- Removed DTS update from the series per Santosh. Will send the same
as a separate patch
v2
- Remove the firmware filename from DT and add it to the driver.
Use a name ks2_qmss_pdsp_acc48.bin. The idea is this can be a
soft link pointing to the real firmware file in file system.
- Move the description of the driver design from DT document to one
under Documentation/arm/keystone/knav-qmss.txt. Update the this
document with location of acc firmware available under
linux-firmware.git.
- Additionally added accumulator queue support optional so that lack
of firmware in the file system will not cause other queue types not
available due to driver probe failure.
Murali Karicheri (3):
Documentation: dt: soc: Add description for knav qmss driver
soc: ti: add firmware file name as part of the driver
soc: ti: qmss: make acc queue support optional in the driver
Documentation/arm/keystone/knav-qmss.txt | 56 ++++++++++++++++++
.../bindings/soc/ti/keystone-navigator-qmss.txt | 1 -
drivers/soc/ti/knav_qmss.h | 3 +-
drivers/soc/ti/knav_qmss_acc.c | 10 +++-
drivers/soc/ti/knav_qmss_queue.c | 67 ++++++++++++++--------
5 files changed, 109 insertions(+), 28 deletions(-)
create mode 100644 Documentation/arm/keystone/knav-qmss.txt
--
1.9.1
^ permalink raw reply [flat|nested] 28+ messages in thread
* [PATCH v4 1/3] Documentation: dt: soc: Add description for knav qmss driver
2015-10-14 14:17 ` Murali Karicheri
(?)
@ 2015-10-14 14:17 ` Murali Karicheri
-1 siblings, 0 replies; 28+ messages in thread
From: Murali Karicheri @ 2015-10-14 14:17 UTC (permalink / raw)
To: corbet, ssantosh, linux-doc, linux-kernel, linux-arm-kernel,
robh+dt, pawel.moll, mark.rutland, ijc+devicetree, galak, linux,
devicetree, arnd
Add a documentation for knav qmss driver.
Signed-off-by: Murali Karicheri <m-karicheri2@ti.com>
---
v4: added Arnd's Acked-by
Documentation/arm/keystone/knav-qmss.txt | 24 ++++++++++++++++++++++++
1 file changed, 24 insertions(+)
create mode 100644 Documentation/arm/keystone/knav-qmss.txt
diff --git a/Documentation/arm/keystone/knav-qmss.txt b/Documentation/arm/keystone/knav-qmss.txt
new file mode 100644
index 0000000..79946d1
--- /dev/null
+++ b/Documentation/arm/keystone/knav-qmss.txt
@@ -0,0 +1,24 @@
+* Texas Instruments Keystone Navigator Queue Management SubSystem driver
+
+Driver source code path
+ drivers/soc/ti/knav_qmss.c
+ drivers/soc/ti/knav_qmss_acc.c
+
+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.
+
+knav qmss driver provides a set of APIs to drivers to open/close qmss queues,
+allocate descriptor pools, map the descriptors, push/pop to queues etc. For
+details of the available APIs, please refers to include/linux/soc/ti/knav_qmss.h
--
1.9.1
^ permalink raw reply related [flat|nested] 28+ messages in thread
* [PATCH v4 1/3] Documentation: dt: soc: Add description for knav qmss driver
@ 2015-10-14 14:17 ` Murali Karicheri
0 siblings, 0 replies; 28+ messages in thread
From: Murali Karicheri @ 2015-10-14 14:17 UTC (permalink / raw)
To: linux-arm-kernel
Add a documentation for knav qmss driver.
Signed-off-by: Murali Karicheri <m-karicheri2@ti.com>
---
v4: added Arnd's Acked-by
Documentation/arm/keystone/knav-qmss.txt | 24 ++++++++++++++++++++++++
1 file changed, 24 insertions(+)
create mode 100644 Documentation/arm/keystone/knav-qmss.txt
diff --git a/Documentation/arm/keystone/knav-qmss.txt b/Documentation/arm/keystone/knav-qmss.txt
new file mode 100644
index 0000000..79946d1
--- /dev/null
+++ b/Documentation/arm/keystone/knav-qmss.txt
@@ -0,0 +1,24 @@
+* Texas Instruments Keystone Navigator Queue Management SubSystem driver
+
+Driver source code path
+ drivers/soc/ti/knav_qmss.c
+ drivers/soc/ti/knav_qmss_acc.c
+
+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.
+
+knav qmss driver provides a set of APIs to drivers to open/close qmss queues,
+allocate descriptor pools, map the descriptors, push/pop to queues etc. For
+details of the available APIs, please refers to include/linux/soc/ti/knav_qmss.h
--
1.9.1
^ permalink raw reply related [flat|nested] 28+ messages in thread
* [PATCH v4 1/3] Documentation: dt: soc: Add description for knav qmss driver
@ 2015-10-14 14:17 ` Murali Karicheri
0 siblings, 0 replies; 28+ messages in thread
From: Murali Karicheri @ 2015-10-14 14:17 UTC (permalink / raw)
To: corbet, ssantosh, linux-doc, linux-kernel, linux-arm-kernel,
robh+dt, pawel.moll, mark.rutland, ijc+devicetree, galak, linux,
devicetree, arnd
Add a documentation for knav qmss driver.
Signed-off-by: Murali Karicheri <m-karicheri2@ti.com>
---
v4: added Arnd's Acked-by
Documentation/arm/keystone/knav-qmss.txt | 24 ++++++++++++++++++++++++
1 file changed, 24 insertions(+)
create mode 100644 Documentation/arm/keystone/knav-qmss.txt
diff --git a/Documentation/arm/keystone/knav-qmss.txt b/Documentation/arm/keystone/knav-qmss.txt
new file mode 100644
index 0000000..79946d1
--- /dev/null
+++ b/Documentation/arm/keystone/knav-qmss.txt
@@ -0,0 +1,24 @@
+* Texas Instruments Keystone Navigator Queue Management SubSystem driver
+
+Driver source code path
+ drivers/soc/ti/knav_qmss.c
+ drivers/soc/ti/knav_qmss_acc.c
+
+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.
+
+knav qmss driver provides a set of APIs to drivers to open/close qmss queues,
+allocate descriptor pools, map the descriptors, push/pop to queues etc. For
+details of the available APIs, please refers to include/linux/soc/ti/knav_qmss.h
--
1.9.1
^ permalink raw reply related [flat|nested] 28+ messages in thread
* [PATCH v4 2/3] soc: ti: add firmware file name as part of the driver
2015-10-14 14:17 ` Murali Karicheri
(?)
@ 2015-10-14 14:17 ` Murali Karicheri
-1 siblings, 0 replies; 28+ messages in thread
From: Murali Karicheri @ 2015-10-14 14:17 UTC (permalink / raw)
To: corbet, ssantosh, linux-doc, linux-kernel, linux-arm-kernel,
robh+dt, pawel.moll, mark.rutland, ijc+devicetree, galak, linux,
devicetree, arnd
Currently firmware file name is included in the DTS. This is not scalable
as user has to change the DTS if they need upgrade to a new firmware.
Instead, add the firmware file name in the driver itself. As long as there
is no API change, new firmware upgrade is easy and require no driver
change. User is expected to copy the firmware image to the file system
and add a sym link to the new firmware for doing an upgrade. Driver add
a array of firmware file names to search for the available firmware blobs.
This scheme also prepare the driver for future changes to API if ever
happens. In such case it is assumed that driver needs to change to
accommodate the new firmware and new firmware file name will get added to
the array.
Also update the DT document to remove the firmware attribute and add
description about firmware in the driver documentation.
Signed-off-by: Murali Karicheri <m-karicheri2@ti.com>
Acked-by: Arnd Bergmann <arnd@arndb.de>
---
v4: no change from v3
Documentation/arm/keystone/knav-qmss.txt | 26 ++++++++++++
.../bindings/soc/ti/keystone-navigator-qmss.txt | 1 -
drivers/soc/ti/knav_qmss.h | 1 -
drivers/soc/ti/knav_qmss_queue.c | 47 +++++++++++++---------
4 files changed, 54 insertions(+), 21 deletions(-)
diff --git a/Documentation/arm/keystone/knav-qmss.txt b/Documentation/arm/keystone/knav-qmss.txt
index 79946d1..da34a5b 100644
--- a/Documentation/arm/keystone/knav-qmss.txt
+++ b/Documentation/arm/keystone/knav-qmss.txt
@@ -22,3 +22,29 @@ pool management.
knav qmss driver provides a set of APIs to drivers to open/close qmss queues,
allocate descriptor pools, map the descriptors, push/pop to queues etc. For
details of the available APIs, please refers to include/linux/soc/ti/knav_qmss.h
+
+DT documentation is available at
+Documentation/devicetree/bindings/soc/ti/keystone-navigator-qmss.txt
+
+Accumulator QMSS queues using PDSP firmware
+============================================
+The QMSS PDSP firmware support accumulator channel that can monitor a single
+queue or multiple contiguous queues. drivers/soc/ti/knav_qmss_acc.c is the
+driver that interface with the accumulator PDSP. This configures
+accumulator channels defined in DTS (example in DT documentation) to monitor
+1 or 32 queues per channel. More description on the firmware is available in
+CPPI/QMSS Low Level Driver document (docs/CPPI_QMSS_LLD_SDS.pdf) at
+ git://git.ti.com/keystone-rtos/qmss-lld.git
+
+k2_qmss_pdsp_acc48_k2_le_1_0_0_9.bin firmware supports upto 48 accumulator
+channels. This firmware is available under ti-keystone folder of
+firmware.git at
+ git://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git
+
+To use copy the firmware image to lib/firmware folder of the initramfs or
+ubifs file system and provide a sym link to k2_qmss_pdsp_acc48_k2_le_1_0_0_9.bin
+in the file system and boot up the kernel. User would see
+
+ "firmware file ks2_qmss_pdsp_acc48.bin downloaded for PDSP"
+
+in the boot up log if loading of firmware to PDSP is successful.
diff --git a/Documentation/devicetree/bindings/soc/ti/keystone-navigator-qmss.txt b/Documentation/devicetree/bindings/soc/ti/keystone-navigator-qmss.txt
index d8e8cdb..d1ce21a 100644
--- a/Documentation/devicetree/bindings/soc/ti/keystone-navigator-qmss.txt
+++ b/Documentation/devicetree/bindings/soc/ti/keystone-navigator-qmss.txt
@@ -221,7 +221,6 @@ qmss: qmss@2a40000 {
#size-cells = <1>;
ranges;
pdsp0@0x2a10000 {
- firmware = "keystone/qmss_pdsp_acc48_k2_le_1_0_0_8.fw";
reg = <0x2a10000 0x1000>,
<0x2a0f000 0x100>,
<0x2a0c000 0x3c8>,
diff --git a/drivers/soc/ti/knav_qmss.h b/drivers/soc/ti/knav_qmss.h
index 51da234..c31b8d8 100644
--- a/drivers/soc/ti/knav_qmss.h
+++ b/drivers/soc/ti/knav_qmss.h
@@ -135,7 +135,6 @@ struct knav_pdsp_info {
};
void __iomem *intd;
u32 __iomem *iram;
- const char *firmware;
u32 id;
struct list_head list;
};
diff --git a/drivers/soc/ti/knav_qmss_queue.c b/drivers/soc/ti/knav_qmss_queue.c
index 6d8646d..06d9de8 100644
--- a/drivers/soc/ti/knav_qmss_queue.c
+++ b/drivers/soc/ti/knav_qmss_queue.c
@@ -68,6 +68,12 @@ static DEFINE_MUTEX(knav_dev_lock);
idx < (kdev)->num_queues_in_use; \
idx++, inst = knav_queue_idx_to_inst(kdev, idx))
+/* All firmware file names end up here. List the firmware file names below.
+ * Newest followed by older ones. Search is done from start of the array
+ * until a firmware file is found.
+ */
+const char *knav_acc_firmwares[] = {"ks2_qmss_pdsp_acc48.bin"};
+
/**
* knav_queue_notify: qmss queue notfier call
*
@@ -1439,7 +1445,6 @@ static int knav_queue_init_pdsps(struct knav_device *kdev,
struct device *dev = kdev->dev;
struct knav_pdsp_info *pdsp;
struct device_node *child;
- int ret;
for_each_child_of_node(pdsps, child) {
pdsp = devm_kzalloc(dev, sizeof(*pdsp), GFP_KERNEL);
@@ -1448,17 +1453,6 @@ static int knav_queue_init_pdsps(struct knav_device *kdev,
return -ENOMEM;
}
pdsp->name = knav_queue_find_name(child);
- ret = of_property_read_string(child, "firmware",
- &pdsp->firmware);
- if (ret < 0 || !pdsp->firmware) {
- dev_err(dev, "unknown firmware for pdsp %s\n",
- pdsp->name);
- devm_kfree(dev, pdsp);
- continue;
- }
- dev_dbg(dev, "pdsp name %s fw name :%s\n", pdsp->name,
- pdsp->firmware);
-
pdsp->iram =
knav_queue_map_reg(kdev, child,
KNAV_QUEUE_PDSP_IRAM_REG_INDEX);
@@ -1489,9 +1483,9 @@ static int knav_queue_init_pdsps(struct knav_device *kdev,
}
of_property_read_u32(child, "id", &pdsp->id);
list_add_tail(&pdsp->list, &kdev->pdsps);
- dev_dbg(dev, "added pdsp %s: command %p, iram %p, regs %p, intd %p, firmware %s\n",
+ dev_dbg(dev, "added pdsp %s: command %p, iram %p, regs %p, intd %p\n",
pdsp->name, pdsp->command, pdsp->iram, pdsp->regs,
- pdsp->intd, pdsp->firmware);
+ pdsp->intd);
}
return 0;
}
@@ -1518,14 +1512,29 @@ static int knav_queue_load_pdsp(struct knav_device *kdev,
{
int i, ret, fwlen;
const struct firmware *fw;
+ bool found = false;
u32 *fwdata;
- ret = request_firmware(&fw, pdsp->firmware, kdev->dev);
- if (ret) {
- dev_err(kdev->dev, "failed to get firmware %s for pdsp %s\n",
- pdsp->firmware, pdsp->name);
- return ret;
+ for (i = 0; i < ARRAY_SIZE(knav_acc_firmwares); i++) {
+ if (knav_acc_firmwares[i]) {
+ ret = request_firmware(&fw,
+ knav_acc_firmwares[i],
+ kdev->dev);
+ if (!ret) {
+ found = true;
+ break;
+ }
+ }
+ }
+
+ if (!found) {
+ dev_err(kdev->dev, "failed to get firmware for pdsp\n");
+ return -ENODEV;
}
+
+ dev_info(kdev->dev, "firmware file %s downloaded for PDSP\n",
+ knav_acc_firmwares[i]);
+
writel_relaxed(pdsp->id + 1, pdsp->command + 0x18);
/* download the firmware */
fwdata = (u32 *)fw->data;
--
1.9.1
^ permalink raw reply related [flat|nested] 28+ messages in thread
* [PATCH v4 2/3] soc: ti: add firmware file name as part of the driver
@ 2015-10-14 14:17 ` Murali Karicheri
0 siblings, 0 replies; 28+ messages in thread
From: Murali Karicheri @ 2015-10-14 14:17 UTC (permalink / raw)
To: linux-arm-kernel
Currently firmware file name is included in the DTS. This is not scalable
as user has to change the DTS if they need upgrade to a new firmware.
Instead, add the firmware file name in the driver itself. As long as there
is no API change, new firmware upgrade is easy and require no driver
change. User is expected to copy the firmware image to the file system
and add a sym link to the new firmware for doing an upgrade. Driver add
a array of firmware file names to search for the available firmware blobs.
This scheme also prepare the driver for future changes to API if ever
happens. In such case it is assumed that driver needs to change to
accommodate the new firmware and new firmware file name will get added to
the array.
Also update the DT document to remove the firmware attribute and add
description about firmware in the driver documentation.
Signed-off-by: Murali Karicheri <m-karicheri2@ti.com>
Acked-by: Arnd Bergmann <arnd@arndb.de>
---
v4: no change from v3
Documentation/arm/keystone/knav-qmss.txt | 26 ++++++++++++
.../bindings/soc/ti/keystone-navigator-qmss.txt | 1 -
drivers/soc/ti/knav_qmss.h | 1 -
drivers/soc/ti/knav_qmss_queue.c | 47 +++++++++++++---------
4 files changed, 54 insertions(+), 21 deletions(-)
diff --git a/Documentation/arm/keystone/knav-qmss.txt b/Documentation/arm/keystone/knav-qmss.txt
index 79946d1..da34a5b 100644
--- a/Documentation/arm/keystone/knav-qmss.txt
+++ b/Documentation/arm/keystone/knav-qmss.txt
@@ -22,3 +22,29 @@ pool management.
knav qmss driver provides a set of APIs to drivers to open/close qmss queues,
allocate descriptor pools, map the descriptors, push/pop to queues etc. For
details of the available APIs, please refers to include/linux/soc/ti/knav_qmss.h
+
+DT documentation is available at
+Documentation/devicetree/bindings/soc/ti/keystone-navigator-qmss.txt
+
+Accumulator QMSS queues using PDSP firmware
+============================================
+The QMSS PDSP firmware support accumulator channel that can monitor a single
+queue or multiple contiguous queues. drivers/soc/ti/knav_qmss_acc.c is the
+driver that interface with the accumulator PDSP. This configures
+accumulator channels defined in DTS (example in DT documentation) to monitor
+1 or 32 queues per channel. More description on the firmware is available in
+CPPI/QMSS Low Level Driver document (docs/CPPI_QMSS_LLD_SDS.pdf) at
+ git://git.ti.com/keystone-rtos/qmss-lld.git
+
+k2_qmss_pdsp_acc48_k2_le_1_0_0_9.bin firmware supports upto 48 accumulator
+channels. This firmware is available under ti-keystone folder of
+firmware.git at
+ git://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git
+
+To use copy the firmware image to lib/firmware folder of the initramfs or
+ubifs file system and provide a sym link to k2_qmss_pdsp_acc48_k2_le_1_0_0_9.bin
+in the file system and boot up the kernel. User would see
+
+ "firmware file ks2_qmss_pdsp_acc48.bin downloaded for PDSP"
+
+in the boot up log if loading of firmware to PDSP is successful.
diff --git a/Documentation/devicetree/bindings/soc/ti/keystone-navigator-qmss.txt b/Documentation/devicetree/bindings/soc/ti/keystone-navigator-qmss.txt
index d8e8cdb..d1ce21a 100644
--- a/Documentation/devicetree/bindings/soc/ti/keystone-navigator-qmss.txt
+++ b/Documentation/devicetree/bindings/soc/ti/keystone-navigator-qmss.txt
@@ -221,7 +221,6 @@ qmss: qmss at 2a40000 {
#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>,
diff --git a/drivers/soc/ti/knav_qmss.h b/drivers/soc/ti/knav_qmss.h
index 51da234..c31b8d8 100644
--- a/drivers/soc/ti/knav_qmss.h
+++ b/drivers/soc/ti/knav_qmss.h
@@ -135,7 +135,6 @@ struct knav_pdsp_info {
};
void __iomem *intd;
u32 __iomem *iram;
- const char *firmware;
u32 id;
struct list_head list;
};
diff --git a/drivers/soc/ti/knav_qmss_queue.c b/drivers/soc/ti/knav_qmss_queue.c
index 6d8646d..06d9de8 100644
--- a/drivers/soc/ti/knav_qmss_queue.c
+++ b/drivers/soc/ti/knav_qmss_queue.c
@@ -68,6 +68,12 @@ static DEFINE_MUTEX(knav_dev_lock);
idx < (kdev)->num_queues_in_use; \
idx++, inst = knav_queue_idx_to_inst(kdev, idx))
+/* All firmware file names end up here. List the firmware file names below.
+ * Newest followed by older ones. Search is done from start of the array
+ * until a firmware file is found.
+ */
+const char *knav_acc_firmwares[] = {"ks2_qmss_pdsp_acc48.bin"};
+
/**
* knav_queue_notify: qmss queue notfier call
*
@@ -1439,7 +1445,6 @@ static int knav_queue_init_pdsps(struct knav_device *kdev,
struct device *dev = kdev->dev;
struct knav_pdsp_info *pdsp;
struct device_node *child;
- int ret;
for_each_child_of_node(pdsps, child) {
pdsp = devm_kzalloc(dev, sizeof(*pdsp), GFP_KERNEL);
@@ -1448,17 +1453,6 @@ static int knav_queue_init_pdsps(struct knav_device *kdev,
return -ENOMEM;
}
pdsp->name = knav_queue_find_name(child);
- ret = of_property_read_string(child, "firmware",
- &pdsp->firmware);
- if (ret < 0 || !pdsp->firmware) {
- dev_err(dev, "unknown firmware for pdsp %s\n",
- pdsp->name);
- devm_kfree(dev, pdsp);
- continue;
- }
- dev_dbg(dev, "pdsp name %s fw name :%s\n", pdsp->name,
- pdsp->firmware);
-
pdsp->iram =
knav_queue_map_reg(kdev, child,
KNAV_QUEUE_PDSP_IRAM_REG_INDEX);
@@ -1489,9 +1483,9 @@ static int knav_queue_init_pdsps(struct knav_device *kdev,
}
of_property_read_u32(child, "id", &pdsp->id);
list_add_tail(&pdsp->list, &kdev->pdsps);
- dev_dbg(dev, "added pdsp %s: command %p, iram %p, regs %p, intd %p, firmware %s\n",
+ dev_dbg(dev, "added pdsp %s: command %p, iram %p, regs %p, intd %p\n",
pdsp->name, pdsp->command, pdsp->iram, pdsp->regs,
- pdsp->intd, pdsp->firmware);
+ pdsp->intd);
}
return 0;
}
@@ -1518,14 +1512,29 @@ static int knav_queue_load_pdsp(struct knav_device *kdev,
{
int i, ret, fwlen;
const struct firmware *fw;
+ bool found = false;
u32 *fwdata;
- ret = request_firmware(&fw, pdsp->firmware, kdev->dev);
- if (ret) {
- dev_err(kdev->dev, "failed to get firmware %s for pdsp %s\n",
- pdsp->firmware, pdsp->name);
- return ret;
+ for (i = 0; i < ARRAY_SIZE(knav_acc_firmwares); i++) {
+ if (knav_acc_firmwares[i]) {
+ ret = request_firmware(&fw,
+ knav_acc_firmwares[i],
+ kdev->dev);
+ if (!ret) {
+ found = true;
+ break;
+ }
+ }
+ }
+
+ if (!found) {
+ dev_err(kdev->dev, "failed to get firmware for pdsp\n");
+ return -ENODEV;
}
+
+ dev_info(kdev->dev, "firmware file %s downloaded for PDSP\n",
+ knav_acc_firmwares[i]);
+
writel_relaxed(pdsp->id + 1, pdsp->command + 0x18);
/* download the firmware */
fwdata = (u32 *)fw->data;
--
1.9.1
^ permalink raw reply related [flat|nested] 28+ messages in thread
* [PATCH v4 2/3] soc: ti: add firmware file name as part of the driver
@ 2015-10-14 14:17 ` Murali Karicheri
0 siblings, 0 replies; 28+ messages in thread
From: Murali Karicheri @ 2015-10-14 14:17 UTC (permalink / raw)
To: corbet, ssantosh, linux-doc, linux-kernel, linux-arm-kernel,
robh+dt, pawel.moll, mark.rutland, ijc+devicetree, galak, linux,
devicetree, arnd
Currently firmware file name is included in the DTS. This is not scalable
as user has to change the DTS if they need upgrade to a new firmware.
Instead, add the firmware file name in the driver itself. As long as there
is no API change, new firmware upgrade is easy and require no driver
change. User is expected to copy the firmware image to the file system
and add a sym link to the new firmware for doing an upgrade. Driver add
a array of firmware file names to search for the available firmware blobs.
This scheme also prepare the driver for future changes to API if ever
happens. In such case it is assumed that driver needs to change to
accommodate the new firmware and new firmware file name will get added to
the array.
Also update the DT document to remove the firmware attribute and add
description about firmware in the driver documentation.
Signed-off-by: Murali Karicheri <m-karicheri2@ti.com>
Acked-by: Arnd Bergmann <arnd@arndb.de>
---
v4: no change from v3
Documentation/arm/keystone/knav-qmss.txt | 26 ++++++++++++
.../bindings/soc/ti/keystone-navigator-qmss.txt | 1 -
drivers/soc/ti/knav_qmss.h | 1 -
drivers/soc/ti/knav_qmss_queue.c | 47 +++++++++++++---------
4 files changed, 54 insertions(+), 21 deletions(-)
diff --git a/Documentation/arm/keystone/knav-qmss.txt b/Documentation/arm/keystone/knav-qmss.txt
index 79946d1..da34a5b 100644
--- a/Documentation/arm/keystone/knav-qmss.txt
+++ b/Documentation/arm/keystone/knav-qmss.txt
@@ -22,3 +22,29 @@ pool management.
knav qmss driver provides a set of APIs to drivers to open/close qmss queues,
allocate descriptor pools, map the descriptors, push/pop to queues etc. For
details of the available APIs, please refers to include/linux/soc/ti/knav_qmss.h
+
+DT documentation is available at
+Documentation/devicetree/bindings/soc/ti/keystone-navigator-qmss.txt
+
+Accumulator QMSS queues using PDSP firmware
+============================================
+The QMSS PDSP firmware support accumulator channel that can monitor a single
+queue or multiple contiguous queues. drivers/soc/ti/knav_qmss_acc.c is the
+driver that interface with the accumulator PDSP. This configures
+accumulator channels defined in DTS (example in DT documentation) to monitor
+1 or 32 queues per channel. More description on the firmware is available in
+CPPI/QMSS Low Level Driver document (docs/CPPI_QMSS_LLD_SDS.pdf) at
+ git://git.ti.com/keystone-rtos/qmss-lld.git
+
+k2_qmss_pdsp_acc48_k2_le_1_0_0_9.bin firmware supports upto 48 accumulator
+channels. This firmware is available under ti-keystone folder of
+firmware.git at
+ git://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git
+
+To use copy the firmware image to lib/firmware folder of the initramfs or
+ubifs file system and provide a sym link to k2_qmss_pdsp_acc48_k2_le_1_0_0_9.bin
+in the file system and boot up the kernel. User would see
+
+ "firmware file ks2_qmss_pdsp_acc48.bin downloaded for PDSP"
+
+in the boot up log if loading of firmware to PDSP is successful.
diff --git a/Documentation/devicetree/bindings/soc/ti/keystone-navigator-qmss.txt b/Documentation/devicetree/bindings/soc/ti/keystone-navigator-qmss.txt
index d8e8cdb..d1ce21a 100644
--- a/Documentation/devicetree/bindings/soc/ti/keystone-navigator-qmss.txt
+++ b/Documentation/devicetree/bindings/soc/ti/keystone-navigator-qmss.txt
@@ -221,7 +221,6 @@ qmss: qmss@2a40000 {
#size-cells = <1>;
ranges;
pdsp0@0x2a10000 {
- firmware = "keystone/qmss_pdsp_acc48_k2_le_1_0_0_8.fw";
reg = <0x2a10000 0x1000>,
<0x2a0f000 0x100>,
<0x2a0c000 0x3c8>,
diff --git a/drivers/soc/ti/knav_qmss.h b/drivers/soc/ti/knav_qmss.h
index 51da234..c31b8d8 100644
--- a/drivers/soc/ti/knav_qmss.h
+++ b/drivers/soc/ti/knav_qmss.h
@@ -135,7 +135,6 @@ struct knav_pdsp_info {
};
void __iomem *intd;
u32 __iomem *iram;
- const char *firmware;
u32 id;
struct list_head list;
};
diff --git a/drivers/soc/ti/knav_qmss_queue.c b/drivers/soc/ti/knav_qmss_queue.c
index 6d8646d..06d9de8 100644
--- a/drivers/soc/ti/knav_qmss_queue.c
+++ b/drivers/soc/ti/knav_qmss_queue.c
@@ -68,6 +68,12 @@ static DEFINE_MUTEX(knav_dev_lock);
idx < (kdev)->num_queues_in_use; \
idx++, inst = knav_queue_idx_to_inst(kdev, idx))
+/* All firmware file names end up here. List the firmware file names below.
+ * Newest followed by older ones. Search is done from start of the array
+ * until a firmware file is found.
+ */
+const char *knav_acc_firmwares[] = {"ks2_qmss_pdsp_acc48.bin"};
+
/**
* knav_queue_notify: qmss queue notfier call
*
@@ -1439,7 +1445,6 @@ static int knav_queue_init_pdsps(struct knav_device *kdev,
struct device *dev = kdev->dev;
struct knav_pdsp_info *pdsp;
struct device_node *child;
- int ret;
for_each_child_of_node(pdsps, child) {
pdsp = devm_kzalloc(dev, sizeof(*pdsp), GFP_KERNEL);
@@ -1448,17 +1453,6 @@ static int knav_queue_init_pdsps(struct knav_device *kdev,
return -ENOMEM;
}
pdsp->name = knav_queue_find_name(child);
- ret = of_property_read_string(child, "firmware",
- &pdsp->firmware);
- if (ret < 0 || !pdsp->firmware) {
- dev_err(dev, "unknown firmware for pdsp %s\n",
- pdsp->name);
- devm_kfree(dev, pdsp);
- continue;
- }
- dev_dbg(dev, "pdsp name %s fw name :%s\n", pdsp->name,
- pdsp->firmware);
-
pdsp->iram =
knav_queue_map_reg(kdev, child,
KNAV_QUEUE_PDSP_IRAM_REG_INDEX);
@@ -1489,9 +1483,9 @@ static int knav_queue_init_pdsps(struct knav_device *kdev,
}
of_property_read_u32(child, "id", &pdsp->id);
list_add_tail(&pdsp->list, &kdev->pdsps);
- dev_dbg(dev, "added pdsp %s: command %p, iram %p, regs %p, intd %p, firmware %s\n",
+ dev_dbg(dev, "added pdsp %s: command %p, iram %p, regs %p, intd %p\n",
pdsp->name, pdsp->command, pdsp->iram, pdsp->regs,
- pdsp->intd, pdsp->firmware);
+ pdsp->intd);
}
return 0;
}
@@ -1518,14 +1512,29 @@ static int knav_queue_load_pdsp(struct knav_device *kdev,
{
int i, ret, fwlen;
const struct firmware *fw;
+ bool found = false;
u32 *fwdata;
- ret = request_firmware(&fw, pdsp->firmware, kdev->dev);
- if (ret) {
- dev_err(kdev->dev, "failed to get firmware %s for pdsp %s\n",
- pdsp->firmware, pdsp->name);
- return ret;
+ for (i = 0; i < ARRAY_SIZE(knav_acc_firmwares); i++) {
+ if (knav_acc_firmwares[i]) {
+ ret = request_firmware(&fw,
+ knav_acc_firmwares[i],
+ kdev->dev);
+ if (!ret) {
+ found = true;
+ break;
+ }
+ }
+ }
+
+ if (!found) {
+ dev_err(kdev->dev, "failed to get firmware for pdsp\n");
+ return -ENODEV;
}
+
+ dev_info(kdev->dev, "firmware file %s downloaded for PDSP\n",
+ knav_acc_firmwares[i]);
+
writel_relaxed(pdsp->id + 1, pdsp->command + 0x18);
/* download the firmware */
fwdata = (u32 *)fw->data;
--
1.9.1
^ permalink raw reply related [flat|nested] 28+ messages in thread
* [PATCH v4 3/3] soc: ti: qmss: make acc queue support optional in the driver
2015-10-14 14:17 ` Murali Karicheri
(?)
@ 2015-10-14 14:17 ` Murali Karicheri
-1 siblings, 0 replies; 28+ messages in thread
From: Murali Karicheri @ 2015-10-14 14:17 UTC (permalink / raw)
To: corbet, ssantosh, linux-doc, linux-kernel, linux-arm-kernel,
robh+dt, pawel.moll, mark.rutland, ijc+devicetree, galak, linux,
devicetree, arnd
acc channels are available only if accumulator PDSP is loaded and
running in the SoC. As this requires firmware and user may not have
firmware in the file system, make the accumulator queue support
available in qmss driver optional. To use accumulator queus user needs
to add firmware to the file system and boot up kernel.
Signed-off-by: Murali Karicheri <m-karicheri2@ti.com>
---
v4: no change from v3
Documentation/arm/keystone/knav-qmss.txt | 6 ++++++
drivers/soc/ti/knav_qmss.h | 2 ++
drivers/soc/ti/knav_qmss_acc.c | 10 ++++++++--
drivers/soc/ti/knav_qmss_queue.c | 20 +++++++++++++++-----
4 files changed, 31 insertions(+), 7 deletions(-)
diff --git a/Documentation/arm/keystone/knav-qmss.txt b/Documentation/arm/keystone/knav-qmss.txt
index da34a5b..fcdb9fd 100644
--- a/Documentation/arm/keystone/knav-qmss.txt
+++ b/Documentation/arm/keystone/knav-qmss.txt
@@ -48,3 +48,9 @@ in the file system and boot up the kernel. User would see
"firmware file ks2_qmss_pdsp_acc48.bin downloaded for PDSP"
in the boot up log if loading of firmware to PDSP is successful.
+
+Use of accumulated queues requires the firmware image to be present in the
+file system. The driver doesn't acc queues to the supported queue range if
+PDSP is not running in the SoC. The API call fails if there is a queue open
+request to an acc queue and PDSP is not running. So make sure to copy firmware
+to file system before using these queue types.
diff --git a/drivers/soc/ti/knav_qmss.h b/drivers/soc/ti/knav_qmss.h
index c31b8d8..6ff936c 100644
--- a/drivers/soc/ti/knav_qmss.h
+++ b/drivers/soc/ti/knav_qmss.h
@@ -137,6 +137,8 @@ struct knav_pdsp_info {
u32 __iomem *iram;
u32 id;
struct list_head list;
+ bool loaded;
+ bool started;
};
struct knav_qmgr_info {
diff --git a/drivers/soc/ti/knav_qmss_acc.c b/drivers/soc/ti/knav_qmss_acc.c
index b98fe56..d2d48f2 100644
--- a/drivers/soc/ti/knav_qmss_acc.c
+++ b/drivers/soc/ti/knav_qmss_acc.c
@@ -486,8 +486,8 @@ struct knav_range_ops knav_acc_range_ops = {
* Return 0 on success or error
*/
int knav_init_acc_range(struct knav_device *kdev,
- struct device_node *node,
- struct knav_range_info *range)
+ struct device_node *node,
+ struct knav_range_info *range)
{
struct knav_acc_channel *acc;
struct knav_pdsp_info *pdsp;
@@ -530,6 +530,12 @@ int knav_init_acc_range(struct knav_device *kdev,
return -EINVAL;
}
+ if (!pdsp->started) {
+ dev_err(kdev->dev, "pdsp id %d not started for range %s\n",
+ info->pdsp_id, range->name);
+ return -ENODEV;
+ }
+
info->pdsp = pdsp;
channels = range->num_queues;
if (of_get_property(node, "multi-queue", NULL)) {
diff --git a/drivers/soc/ti/knav_qmss_queue.c b/drivers/soc/ti/knav_qmss_queue.c
index 06d9de8..f3a0b6a 100644
--- a/drivers/soc/ti/knav_qmss_queue.c
+++ b/drivers/soc/ti/knav_qmss_queue.c
@@ -1504,6 +1504,8 @@ static int knav_queue_stop_pdsp(struct knav_device *kdev,
dev_err(kdev->dev, "timed out on pdsp %s stop\n", pdsp->name);
return ret;
}
+ pdsp->loaded = false;
+ pdsp->started = false;
return 0;
}
@@ -1592,16 +1594,24 @@ static int knav_queue_start_pdsps(struct knav_device *kdev)
int ret;
knav_queue_stop_pdsps(kdev);
- /* now load them all */
+ /* now load them all. We return success even if pdsp
+ * is not loaded as acc channels are optional on having
+ * firmware availability in the system. We set the loaded
+ * and stated flag and when initialize the acc range, check
+ * it and init the range only if pdsp is started.
+ */
for_each_pdsp(kdev, pdsp) {
ret = knav_queue_load_pdsp(kdev, pdsp);
- if (ret < 0)
- return ret;
+ if (!ret)
+ pdsp->loaded = true;
}
for_each_pdsp(kdev, pdsp) {
- ret = knav_queue_start_pdsp(kdev, pdsp);
- WARN_ON(ret);
+ if (pdsp->loaded) {
+ ret = knav_queue_start_pdsp(kdev, pdsp);
+ if (!ret)
+ pdsp->started = true;
+ }
}
return 0;
}
--
1.9.1
^ permalink raw reply related [flat|nested] 28+ messages in thread
* [PATCH v4 3/3] soc: ti: qmss: make acc queue support optional in the driver
@ 2015-10-14 14:17 ` Murali Karicheri
0 siblings, 0 replies; 28+ messages in thread
From: Murali Karicheri @ 2015-10-14 14:17 UTC (permalink / raw)
To: linux-arm-kernel
acc channels are available only if accumulator PDSP is loaded and
running in the SoC. As this requires firmware and user may not have
firmware in the file system, make the accumulator queue support
available in qmss driver optional. To use accumulator queus user needs
to add firmware to the file system and boot up kernel.
Signed-off-by: Murali Karicheri <m-karicheri2@ti.com>
---
v4: no change from v3
Documentation/arm/keystone/knav-qmss.txt | 6 ++++++
drivers/soc/ti/knav_qmss.h | 2 ++
drivers/soc/ti/knav_qmss_acc.c | 10 ++++++++--
drivers/soc/ti/knav_qmss_queue.c | 20 +++++++++++++++-----
4 files changed, 31 insertions(+), 7 deletions(-)
diff --git a/Documentation/arm/keystone/knav-qmss.txt b/Documentation/arm/keystone/knav-qmss.txt
index da34a5b..fcdb9fd 100644
--- a/Documentation/arm/keystone/knav-qmss.txt
+++ b/Documentation/arm/keystone/knav-qmss.txt
@@ -48,3 +48,9 @@ in the file system and boot up the kernel. User would see
"firmware file ks2_qmss_pdsp_acc48.bin downloaded for PDSP"
in the boot up log if loading of firmware to PDSP is successful.
+
+Use of accumulated queues requires the firmware image to be present in the
+file system. The driver doesn't acc queues to the supported queue range if
+PDSP is not running in the SoC. The API call fails if there is a queue open
+request to an acc queue and PDSP is not running. So make sure to copy firmware
+to file system before using these queue types.
diff --git a/drivers/soc/ti/knav_qmss.h b/drivers/soc/ti/knav_qmss.h
index c31b8d8..6ff936c 100644
--- a/drivers/soc/ti/knav_qmss.h
+++ b/drivers/soc/ti/knav_qmss.h
@@ -137,6 +137,8 @@ struct knav_pdsp_info {
u32 __iomem *iram;
u32 id;
struct list_head list;
+ bool loaded;
+ bool started;
};
struct knav_qmgr_info {
diff --git a/drivers/soc/ti/knav_qmss_acc.c b/drivers/soc/ti/knav_qmss_acc.c
index b98fe56..d2d48f2 100644
--- a/drivers/soc/ti/knav_qmss_acc.c
+++ b/drivers/soc/ti/knav_qmss_acc.c
@@ -486,8 +486,8 @@ struct knav_range_ops knav_acc_range_ops = {
* Return 0 on success or error
*/
int knav_init_acc_range(struct knav_device *kdev,
- struct device_node *node,
- struct knav_range_info *range)
+ struct device_node *node,
+ struct knav_range_info *range)
{
struct knav_acc_channel *acc;
struct knav_pdsp_info *pdsp;
@@ -530,6 +530,12 @@ int knav_init_acc_range(struct knav_device *kdev,
return -EINVAL;
}
+ if (!pdsp->started) {
+ dev_err(kdev->dev, "pdsp id %d not started for range %s\n",
+ info->pdsp_id, range->name);
+ return -ENODEV;
+ }
+
info->pdsp = pdsp;
channels = range->num_queues;
if (of_get_property(node, "multi-queue", NULL)) {
diff --git a/drivers/soc/ti/knav_qmss_queue.c b/drivers/soc/ti/knav_qmss_queue.c
index 06d9de8..f3a0b6a 100644
--- a/drivers/soc/ti/knav_qmss_queue.c
+++ b/drivers/soc/ti/knav_qmss_queue.c
@@ -1504,6 +1504,8 @@ static int knav_queue_stop_pdsp(struct knav_device *kdev,
dev_err(kdev->dev, "timed out on pdsp %s stop\n", pdsp->name);
return ret;
}
+ pdsp->loaded = false;
+ pdsp->started = false;
return 0;
}
@@ -1592,16 +1594,24 @@ static int knav_queue_start_pdsps(struct knav_device *kdev)
int ret;
knav_queue_stop_pdsps(kdev);
- /* now load them all */
+ /* now load them all. We return success even if pdsp
+ * is not loaded as acc channels are optional on having
+ * firmware availability in the system. We set the loaded
+ * and stated flag and when initialize the acc range, check
+ * it and init the range only if pdsp is started.
+ */
for_each_pdsp(kdev, pdsp) {
ret = knav_queue_load_pdsp(kdev, pdsp);
- if (ret < 0)
- return ret;
+ if (!ret)
+ pdsp->loaded = true;
}
for_each_pdsp(kdev, pdsp) {
- ret = knav_queue_start_pdsp(kdev, pdsp);
- WARN_ON(ret);
+ if (pdsp->loaded) {
+ ret = knav_queue_start_pdsp(kdev, pdsp);
+ if (!ret)
+ pdsp->started = true;
+ }
}
return 0;
}
--
1.9.1
^ permalink raw reply related [flat|nested] 28+ messages in thread
* [PATCH v4 3/3] soc: ti: qmss: make acc queue support optional in the driver
@ 2015-10-14 14:17 ` Murali Karicheri
0 siblings, 0 replies; 28+ messages in thread
From: Murali Karicheri @ 2015-10-14 14:17 UTC (permalink / raw)
To: corbet, ssantosh, linux-doc, linux-kernel, linux-arm-kernel,
robh+dt, pawel.moll, mark.rutland, ijc+devicetree, galak, linux,
devicetree, arnd
acc channels are available only if accumulator PDSP is loaded and
running in the SoC. As this requires firmware and user may not have
firmware in the file system, make the accumulator queue support
available in qmss driver optional. To use accumulator queus user needs
to add firmware to the file system and boot up kernel.
Signed-off-by: Murali Karicheri <m-karicheri2@ti.com>
---
v4: no change from v3
Documentation/arm/keystone/knav-qmss.txt | 6 ++++++
drivers/soc/ti/knav_qmss.h | 2 ++
drivers/soc/ti/knav_qmss_acc.c | 10 ++++++++--
drivers/soc/ti/knav_qmss_queue.c | 20 +++++++++++++++-----
4 files changed, 31 insertions(+), 7 deletions(-)
diff --git a/Documentation/arm/keystone/knav-qmss.txt b/Documentation/arm/keystone/knav-qmss.txt
index da34a5b..fcdb9fd 100644
--- a/Documentation/arm/keystone/knav-qmss.txt
+++ b/Documentation/arm/keystone/knav-qmss.txt
@@ -48,3 +48,9 @@ in the file system and boot up the kernel. User would see
"firmware file ks2_qmss_pdsp_acc48.bin downloaded for PDSP"
in the boot up log if loading of firmware to PDSP is successful.
+
+Use of accumulated queues requires the firmware image to be present in the
+file system. The driver doesn't acc queues to the supported queue range if
+PDSP is not running in the SoC. The API call fails if there is a queue open
+request to an acc queue and PDSP is not running. So make sure to copy firmware
+to file system before using these queue types.
diff --git a/drivers/soc/ti/knav_qmss.h b/drivers/soc/ti/knav_qmss.h
index c31b8d8..6ff936c 100644
--- a/drivers/soc/ti/knav_qmss.h
+++ b/drivers/soc/ti/knav_qmss.h
@@ -137,6 +137,8 @@ struct knav_pdsp_info {
u32 __iomem *iram;
u32 id;
struct list_head list;
+ bool loaded;
+ bool started;
};
struct knav_qmgr_info {
diff --git a/drivers/soc/ti/knav_qmss_acc.c b/drivers/soc/ti/knav_qmss_acc.c
index b98fe56..d2d48f2 100644
--- a/drivers/soc/ti/knav_qmss_acc.c
+++ b/drivers/soc/ti/knav_qmss_acc.c
@@ -486,8 +486,8 @@ struct knav_range_ops knav_acc_range_ops = {
* Return 0 on success or error
*/
int knav_init_acc_range(struct knav_device *kdev,
- struct device_node *node,
- struct knav_range_info *range)
+ struct device_node *node,
+ struct knav_range_info *range)
{
struct knav_acc_channel *acc;
struct knav_pdsp_info *pdsp;
@@ -530,6 +530,12 @@ int knav_init_acc_range(struct knav_device *kdev,
return -EINVAL;
}
+ if (!pdsp->started) {
+ dev_err(kdev->dev, "pdsp id %d not started for range %s\n",
+ info->pdsp_id, range->name);
+ return -ENODEV;
+ }
+
info->pdsp = pdsp;
channels = range->num_queues;
if (of_get_property(node, "multi-queue", NULL)) {
diff --git a/drivers/soc/ti/knav_qmss_queue.c b/drivers/soc/ti/knav_qmss_queue.c
index 06d9de8..f3a0b6a 100644
--- a/drivers/soc/ti/knav_qmss_queue.c
+++ b/drivers/soc/ti/knav_qmss_queue.c
@@ -1504,6 +1504,8 @@ static int knav_queue_stop_pdsp(struct knav_device *kdev,
dev_err(kdev->dev, "timed out on pdsp %s stop\n", pdsp->name);
return ret;
}
+ pdsp->loaded = false;
+ pdsp->started = false;
return 0;
}
@@ -1592,16 +1594,24 @@ static int knav_queue_start_pdsps(struct knav_device *kdev)
int ret;
knav_queue_stop_pdsps(kdev);
- /* now load them all */
+ /* now load them all. We return success even if pdsp
+ * is not loaded as acc channels are optional on having
+ * firmware availability in the system. We set the loaded
+ * and stated flag and when initialize the acc range, check
+ * it and init the range only if pdsp is started.
+ */
for_each_pdsp(kdev, pdsp) {
ret = knav_queue_load_pdsp(kdev, pdsp);
- if (ret < 0)
- return ret;
+ if (!ret)
+ pdsp->loaded = true;
}
for_each_pdsp(kdev, pdsp) {
- ret = knav_queue_start_pdsp(kdev, pdsp);
- WARN_ON(ret);
+ if (pdsp->loaded) {
+ ret = knav_queue_start_pdsp(kdev, pdsp);
+ if (!ret)
+ pdsp->started = true;
+ }
}
return 0;
}
--
1.9.1
^ permalink raw reply related [flat|nested] 28+ messages in thread
* Re: [PATCH v4 0/3]
2015-10-14 14:17 ` Murali Karicheri
@ 2015-10-14 15:41 ` santosh shilimkar
-1 siblings, 0 replies; 28+ messages in thread
From: santosh shilimkar @ 2015-10-14 15:41 UTC (permalink / raw)
To: Murali Karicheri, corbet, ssantosh, linux-doc, linux-kernel,
linux-arm-kernel, robh+dt, pawel.moll, mark.rutland,
ijc+devicetree, galak, linux, devicetree, arnd
10/14/2015 7:17 AM, Murali Karicheri wrote:
> This patch series enable accumulator queue support for K2 SoCs. Accumulator
> queues are a type of qmss queue that is monitored by the PDSP firmware and
> accumulated. Host is interrupted by PDSP firmware when packets become
> available in a ring buffer shared between the host and PDSP.
>
> There was an issue raised when merging the original patch set at
> (1) https://lkml.org/lkml/2015/9/4/681
> [PATCH v1 1/2] soc: ti: display firmware file name as part of boot log
> (2) https://lkml.org/lkml/2015/9/4/680
> [PATCH v1 2/2] ARM: dts: keystone: enable accumulator channels
>
> This series fixes the issues raised against v3. Maintainer, could you please
> apply this series to v4.4 next please at your earliest opportunity.
>
I have picked up the series. Thanks for quick turnaround.
Regards,
Santosh
^ permalink raw reply [flat|nested] 28+ messages in thread
* [PATCH v4 0/3]
@ 2015-10-14 15:41 ` santosh shilimkar
0 siblings, 0 replies; 28+ messages in thread
From: santosh shilimkar @ 2015-10-14 15:41 UTC (permalink / raw)
To: linux-arm-kernel
10/14/2015 7:17 AM, Murali Karicheri wrote:
> This patch series enable accumulator queue support for K2 SoCs. Accumulator
> queues are a type of qmss queue that is monitored by the PDSP firmware and
> accumulated. Host is interrupted by PDSP firmware when packets become
> available in a ring buffer shared between the host and PDSP.
>
> There was an issue raised when merging the original patch set at
> (1) https://lkml.org/lkml/2015/9/4/681
> [PATCH v1 1/2] soc: ti: display firmware file name as part of boot log
> (2) https://lkml.org/lkml/2015/9/4/680
> [PATCH v1 2/2] ARM: dts: keystone: enable accumulator channels
>
> This series fixes the issues raised against v3. Maintainer, could you please
> apply this series to v4.4 next please at your earliest opportunity.
>
I have picked up the series. Thanks for quick turnaround.
Regards,
Santosh
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [PATCH v4 0/3]
2015-10-14 15:41 ` santosh shilimkar
(?)
@ 2015-10-15 16:02 ` Murali Karicheri
-1 siblings, 0 replies; 28+ messages in thread
From: Murali Karicheri @ 2015-10-15 16:02 UTC (permalink / raw)
To: santosh shilimkar, corbet, ssantosh, linux-doc, linux-kernel,
linux-arm-kernel, robh+dt, pawel.moll, mark.rutland,
ijc+devicetree, galak, linux, devicetree, arnd
On 10/14/2015 11:41 AM, santosh shilimkar wrote:
> 10/14/2015 7:17 AM, Murali Karicheri wrote:
>> This patch series enable accumulator queue support for K2 SoCs.
>> Accumulator
>> queues are a type of qmss queue that is monitored by the PDSP firmware
>> and
>> accumulated. Host is interrupted by PDSP firmware when packets become
>> available in a ring buffer shared between the host and PDSP.
>>
>> There was an issue raised when merging the original patch set at
>> (1) https://lkml.org/lkml/2015/9/4/681
>> [PATCH v1 1/2] soc: ti: display firmware file name as part of boot
>> log
>> (2) https://lkml.org/lkml/2015/9/4/680
>> [PATCH v1 2/2] ARM: dts: keystone: enable accumulator channels
>>
>> This series fixes the issues raised against v3. Maintainer, could you
>> please
>> apply this series to v4.4 next please at your earliest opportunity.
>>
> I have picked up the series. Thanks for quick turnaround.
Thanks Santosh. Could you send this pull request for v4.4 next. We want
this merged to our internal release and if this is on next branch it
will help.
Thanks
Murali
>
> Regards,
> Santosh
>
>
--
Murali Karicheri
Linux Kernel, Keystone
^ permalink raw reply [flat|nested] 28+ messages in thread
* [PATCH v4 0/3]
@ 2015-10-15 16:02 ` Murali Karicheri
0 siblings, 0 replies; 28+ messages in thread
From: Murali Karicheri @ 2015-10-15 16:02 UTC (permalink / raw)
To: linux-arm-kernel
On 10/14/2015 11:41 AM, santosh shilimkar wrote:
> 10/14/2015 7:17 AM, Murali Karicheri wrote:
>> This patch series enable accumulator queue support for K2 SoCs.
>> Accumulator
>> queues are a type of qmss queue that is monitored by the PDSP firmware
>> and
>> accumulated. Host is interrupted by PDSP firmware when packets become
>> available in a ring buffer shared between the host and PDSP.
>>
>> There was an issue raised when merging the original patch set at
>> (1) https://lkml.org/lkml/2015/9/4/681
>> [PATCH v1 1/2] soc: ti: display firmware file name as part of boot
>> log
>> (2) https://lkml.org/lkml/2015/9/4/680
>> [PATCH v1 2/2] ARM: dts: keystone: enable accumulator channels
>>
>> This series fixes the issues raised against v3. Maintainer, could you
>> please
>> apply this series to v4.4 next please at your earliest opportunity.
>>
> I have picked up the series. Thanks for quick turnaround.
Thanks Santosh. Could you send this pull request for v4.4 next. We want
this merged to our internal release and if this is on next branch it
will help.
Thanks
Murali
>
> Regards,
> Santosh
>
>
--
Murali Karicheri
Linux Kernel, Keystone
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [PATCH v4 0/3]
@ 2015-10-15 16:02 ` Murali Karicheri
0 siblings, 0 replies; 28+ messages in thread
From: Murali Karicheri @ 2015-10-15 16:02 UTC (permalink / raw)
To: santosh shilimkar, corbet, ssantosh, linux-doc, linux-kernel,
linux-arm-kernel, robh+dt, pawel.moll, mark.rutland,
ijc+devicetree, galak, linux, devicetree, arnd
On 10/14/2015 11:41 AM, santosh shilimkar wrote:
> 10/14/2015 7:17 AM, Murali Karicheri wrote:
>> This patch series enable accumulator queue support for K2 SoCs.
>> Accumulator
>> queues are a type of qmss queue that is monitored by the PDSP firmware
>> and
>> accumulated. Host is interrupted by PDSP firmware when packets become
>> available in a ring buffer shared between the host and PDSP.
>>
>> There was an issue raised when merging the original patch set at
>> (1) https://lkml.org/lkml/2015/9/4/681
>> [PATCH v1 1/2] soc: ti: display firmware file name as part of boot
>> log
>> (2) https://lkml.org/lkml/2015/9/4/680
>> [PATCH v1 2/2] ARM: dts: keystone: enable accumulator channels
>>
>> This series fixes the issues raised against v3. Maintainer, could you
>> please
>> apply this series to v4.4 next please at your earliest opportunity.
>>
> I have picked up the series. Thanks for quick turnaround.
Thanks Santosh. Could you send this pull request for v4.4 next. We want
this merged to our internal release and if this is on next branch it
will help.
Thanks
Murali
>
> Regards,
> Santosh
>
>
--
Murali Karicheri
Linux Kernel, Keystone
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [PATCH v4 0/3]
@ 2015-10-15 16:21 ` santosh shilimkar
0 siblings, 0 replies; 28+ messages in thread
From: santosh shilimkar @ 2015-10-15 16:21 UTC (permalink / raw)
To: Murali Karicheri, corbet, ssantosh, linux-doc, linux-kernel,
linux-arm-kernel, robh+dt, pawel.moll, mark.rutland,
ijc+devicetree, galak, linux, devicetree, arnd
On 10/15/2015 9:02 AM, Murali Karicheri wrote:
> On 10/14/2015 11:41 AM, santosh shilimkar wrote:
>> 10/14/2015 7:17 AM, Murali Karicheri wrote:
>>> This patch series enable accumulator queue support for K2 SoCs.
>>> Accumulator
>>> queues are a type of qmss queue that is monitored by the PDSP firmware
>>> and
>>> accumulated. Host is interrupted by PDSP firmware when packets become
>>> available in a ring buffer shared between the host and PDSP.
>>>
>>> There was an issue raised when merging the original patch set at
>>> (1) https://lkml.org/lkml/2015/9/4/681
>>> [PATCH v1 1/2] soc: ti: display firmware file name as part of boot
>>> log
>>> (2) https://lkml.org/lkml/2015/9/4/680
>>> [PATCH v1 2/2] ARM: dts: keystone: enable accumulator channels
>>>
>>> This series fixes the issues raised against v3. Maintainer, could you
>>> please
>>> apply this series to v4.4 next please at your earliest opportunity.
>>>
>> I have picked up the series. Thanks for quick turnaround.
>
> Thanks Santosh. Could you send this pull request for v4.4 next. We want
> this merged to our internal release and if this is on next branch it
> will help.
>
It should be already in linux-next and pull request was sent before I
replied yesterday. Its late for the merge window with usual norms
so lets see if it makes it.
Regards,
Santosh
^ permalink raw reply [flat|nested] 28+ messages in thread
* [PATCH v4 0/3]
@ 2015-10-15 16:21 ` santosh shilimkar
0 siblings, 0 replies; 28+ messages in thread
From: santosh shilimkar @ 2015-10-15 16:21 UTC (permalink / raw)
To: linux-arm-kernel
On 10/15/2015 9:02 AM, Murali Karicheri wrote:
> On 10/14/2015 11:41 AM, santosh shilimkar wrote:
>> 10/14/2015 7:17 AM, Murali Karicheri wrote:
>>> This patch series enable accumulator queue support for K2 SoCs.
>>> Accumulator
>>> queues are a type of qmss queue that is monitored by the PDSP firmware
>>> and
>>> accumulated. Host is interrupted by PDSP firmware when packets become
>>> available in a ring buffer shared between the host and PDSP.
>>>
>>> There was an issue raised when merging the original patch set at
>>> (1) https://lkml.org/lkml/2015/9/4/681
>>> [PATCH v1 1/2] soc: ti: display firmware file name as part of boot
>>> log
>>> (2) https://lkml.org/lkml/2015/9/4/680
>>> [PATCH v1 2/2] ARM: dts: keystone: enable accumulator channels
>>>
>>> This series fixes the issues raised against v3. Maintainer, could you
>>> please
>>> apply this series to v4.4 next please at your earliest opportunity.
>>>
>> I have picked up the series. Thanks for quick turnaround.
>
> Thanks Santosh. Could you send this pull request for v4.4 next. We want
> this merged to our internal release and if this is on next branch it
> will help.
>
It should be already in linux-next and pull request was sent before I
replied yesterday. Its late for the merge window with usual norms
so lets see if it makes it.
Regards,
Santosh
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [PATCH v4 0/3]
@ 2015-10-15 16:21 ` santosh shilimkar
0 siblings, 0 replies; 28+ messages in thread
From: santosh shilimkar @ 2015-10-15 16:21 UTC (permalink / raw)
To: Murali Karicheri, corbet-T1hC0tSOHrs,
ssantosh-DgEjT+Ai2ygdnm+yROfE0A,
linux-doc-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A, pawel.moll-5wv7dgnIgG8,
mark.rutland-5wv7dgnIgG8, ijc+devicetree-KcIKpvwj1kUDXYZnReoRVg,
galak-sgV2jX0FEOL9JmXXK+q4OQ, linux-lFZ/pmaqli7XmaaqVzeoHQ,
devicetree-u79uwXL29TY76Z2rM5mHXA, arnd-r2nGTMty4D4
On 10/15/2015 9:02 AM, Murali Karicheri wrote:
> On 10/14/2015 11:41 AM, santosh shilimkar wrote:
>> 10/14/2015 7:17 AM, Murali Karicheri wrote:
>>> This patch series enable accumulator queue support for K2 SoCs.
>>> Accumulator
>>> queues are a type of qmss queue that is monitored by the PDSP firmware
>>> and
>>> accumulated. Host is interrupted by PDSP firmware when packets become
>>> available in a ring buffer shared between the host and PDSP.
>>>
>>> There was an issue raised when merging the original patch set at
>>> (1) https://lkml.org/lkml/2015/9/4/681
>>> [PATCH v1 1/2] soc: ti: display firmware file name as part of boot
>>> log
>>> (2) https://lkml.org/lkml/2015/9/4/680
>>> [PATCH v1 2/2] ARM: dts: keystone: enable accumulator channels
>>>
>>> This series fixes the issues raised against v3. Maintainer, could you
>>> please
>>> apply this series to v4.4 next please at your earliest opportunity.
>>>
>> I have picked up the series. Thanks for quick turnaround.
>
> Thanks Santosh. Could you send this pull request for v4.4 next. We want
> this merged to our internal release and if this is on next branch it
> will help.
>
It should be already in linux-next and pull request was sent before I
replied yesterday. Its late for the merge window with usual norms
so lets see if it makes it.
Regards,
Santosh
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [PATCH v4 0/3]
2015-10-15 16:21 ` santosh shilimkar
(?)
@ 2015-10-15 16:29 ` Murali Karicheri
-1 siblings, 0 replies; 28+ messages in thread
From: Murali Karicheri @ 2015-10-15 16:29 UTC (permalink / raw)
To: santosh shilimkar, corbet, ssantosh, linux-doc, linux-kernel,
linux-arm-kernel, robh+dt, pawel.moll, mark.rutland,
ijc+devicetree, galak, linux, devicetree, arnd
On 10/15/2015 12:21 PM, santosh shilimkar wrote:
> On 10/15/2015 9:02 AM, Murali Karicheri wrote:
>> On 10/14/2015 11:41 AM, santosh shilimkar wrote:
>>> 10/14/2015 7:17 AM, Murali Karicheri wrote:
>>>> This patch series enable accumulator queue support for K2 SoCs.
>>>> Accumulator
>>>> queues are a type of qmss queue that is monitored by the PDSP firmware
>>>> and
>>>> accumulated. Host is interrupted by PDSP firmware when packets become
>>>> available in a ring buffer shared between the host and PDSP.
>>>>
>>>> There was an issue raised when merging the original patch set at
>>>> (1) https://lkml.org/lkml/2015/9/4/681
>>>> [PATCH v1 1/2] soc: ti: display firmware file name as part of boot
>>>> log
>>>> (2) https://lkml.org/lkml/2015/9/4/680
>>>> [PATCH v1 2/2] ARM: dts: keystone: enable accumulator channels
>>>>
>>>> This series fixes the issues raised against v3. Maintainer, could you
>>>> please
>>>> apply this series to v4.4 next please at your earliest opportunity.
>>>>
>>> I have picked up the series. Thanks for quick turnaround.
>>
>> Thanks Santosh. Could you send this pull request for v4.4 next. We want
>> this merged to our internal release and if this is on next branch it
>> will help.
>>
> It should be already in linux-next and pull request was sent before I
> replied yesterday. Its late for the merge window with usual norms
> so lets see if it makes it.
Santosh,
I see both driver and DTS. Thanks once again for your support
Regards,
Murali
>
> Regards,
> Santosh
>
>
--
Murali Karicheri
Linux Kernel, Keystone
^ permalink raw reply [flat|nested] 28+ messages in thread
* [PATCH v4 0/3]
@ 2015-10-15 16:29 ` Murali Karicheri
0 siblings, 0 replies; 28+ messages in thread
From: Murali Karicheri @ 2015-10-15 16:29 UTC (permalink / raw)
To: linux-arm-kernel
On 10/15/2015 12:21 PM, santosh shilimkar wrote:
> On 10/15/2015 9:02 AM, Murali Karicheri wrote:
>> On 10/14/2015 11:41 AM, santosh shilimkar wrote:
>>> 10/14/2015 7:17 AM, Murali Karicheri wrote:
>>>> This patch series enable accumulator queue support for K2 SoCs.
>>>> Accumulator
>>>> queues are a type of qmss queue that is monitored by the PDSP firmware
>>>> and
>>>> accumulated. Host is interrupted by PDSP firmware when packets become
>>>> available in a ring buffer shared between the host and PDSP.
>>>>
>>>> There was an issue raised when merging the original patch set at
>>>> (1) https://lkml.org/lkml/2015/9/4/681
>>>> [PATCH v1 1/2] soc: ti: display firmware file name as part of boot
>>>> log
>>>> (2) https://lkml.org/lkml/2015/9/4/680
>>>> [PATCH v1 2/2] ARM: dts: keystone: enable accumulator channels
>>>>
>>>> This series fixes the issues raised against v3. Maintainer, could you
>>>> please
>>>> apply this series to v4.4 next please at your earliest opportunity.
>>>>
>>> I have picked up the series. Thanks for quick turnaround.
>>
>> Thanks Santosh. Could you send this pull request for v4.4 next. We want
>> this merged to our internal release and if this is on next branch it
>> will help.
>>
> It should be already in linux-next and pull request was sent before I
> replied yesterday. Its late for the merge window with usual norms
> so lets see if it makes it.
Santosh,
I see both driver and DTS. Thanks once again for your support
Regards,
Murali
>
> Regards,
> Santosh
>
>
--
Murali Karicheri
Linux Kernel, Keystone
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [PATCH v4 0/3]
@ 2015-10-15 16:29 ` Murali Karicheri
0 siblings, 0 replies; 28+ messages in thread
From: Murali Karicheri @ 2015-10-15 16:29 UTC (permalink / raw)
To: santosh shilimkar, corbet, ssantosh, linux-doc, linux-kernel,
linux-arm-kernel, robh+dt, pawel.moll, mark.rutland,
ijc+devicetree, galak, linux, devicetree, arnd
On 10/15/2015 12:21 PM, santosh shilimkar wrote:
> On 10/15/2015 9:02 AM, Murali Karicheri wrote:
>> On 10/14/2015 11:41 AM, santosh shilimkar wrote:
>>> 10/14/2015 7:17 AM, Murali Karicheri wrote:
>>>> This patch series enable accumulator queue support for K2 SoCs.
>>>> Accumulator
>>>> queues are a type of qmss queue that is monitored by the PDSP firmware
>>>> and
>>>> accumulated. Host is interrupted by PDSP firmware when packets become
>>>> available in a ring buffer shared between the host and PDSP.
>>>>
>>>> There was an issue raised when merging the original patch set at
>>>> (1) https://lkml.org/lkml/2015/9/4/681
>>>> [PATCH v1 1/2] soc: ti: display firmware file name as part of boot
>>>> log
>>>> (2) https://lkml.org/lkml/2015/9/4/680
>>>> [PATCH v1 2/2] ARM: dts: keystone: enable accumulator channels
>>>>
>>>> This series fixes the issues raised against v3. Maintainer, could you
>>>> please
>>>> apply this series to v4.4 next please at your earliest opportunity.
>>>>
>>> I have picked up the series. Thanks for quick turnaround.
>>
>> Thanks Santosh. Could you send this pull request for v4.4 next. We want
>> this merged to our internal release and if this is on next branch it
>> will help.
>>
> It should be already in linux-next and pull request was sent before I
> replied yesterday. Its late for the merge window with usual norms
> so lets see if it makes it.
Santosh,
I see both driver and DTS. Thanks once again for your support
Regards,
Murali
>
> Regards,
> Santosh
>
>
--
Murali Karicheri
Linux Kernel, Keystone
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [PATCH v3 1/3] ref-filter: add worktreepath atom
@ 2018-12-20 14:59 Jeff King
2018-12-24 8:47 ` [PATCH v4 0/3] nbelakovski
0 siblings, 1 reply; 28+ messages in thread
From: Jeff King @ 2018-12-20 14:59 UTC (permalink / raw)
To: Nickolai Belakovski
Cc: git, Rafael Ascensão, Junio C Hamano,
Ævar Arnfjörð Bjarmason
On Wed, Dec 19, 2018 at 11:09:59PM -0800, Nickolai Belakovski wrote:
> > Also, why are we replacing it with a single space? Wouldn't the empty
> > string be more customary (and work with the other "if empty, then do
> > this" formatting options)?
>
> I was just following what was done for HEAD, but overall I agree that
> empty is preferable to single space, will change.
Ah, right, that makes more sense. I do still think for %(HEAD) it's a
little different because it is "+" or a single space, so always one
character. Here we have some value or not, and in the "not" case for
such things we usually give an empty string (e.g., for %(push),
%(upstream), etc).
> To sum up the hashmap comments:
> -I hadn't thought to re-use the head_ref of worktree as the key.
> That's clever. I like the readability of having separate entries for
> key and value, but I can see the benefit of not having to do an extra
> allocation. I can make up for the readability hit with a comment.
Thanks, that makes sense.
> -Actually, for any valid use case there will only be one instance of
> the map since the entries of used_atom are cached, but regardless it
> makes sense to keep per-atom info in used_atom and global context
> somewhere else, so I'll make that change to make it a static variable
> outside of used_atom.
Ah, right, I forgot there was some magic around used_atom. I do still
agree that the separate static global makes things a little simpler.
> -Will change the lookup logic to remove the extra allocation. Since
> I'm letting the hashmap use its internal comparison function on the
> hash, I don't need to provide a comparison function.
I don't think that works. The default function is always_equal(), which
will treat two entries equal if they have the same hash value. I.e., any
collisions would be considered a match.
> Thanks for all the feedback, will try to turn these around quickly.
Great, thanks! I'll be on vacation for the next two weeks, so I may be
very slow to look at the next iteration. :)
-Peff
^ permalink raw reply [flat|nested] 28+ messages in thread
* [PATCH v4 0/3]
2018-12-20 14:59 [PATCH v3 1/3] ref-filter: add worktreepath atom Jeff King
@ 2018-12-24 8:47 ` nbelakovski
2019-01-03 5:22 ` Jeff King
0 siblings, 1 reply; 28+ messages in thread
From: nbelakovski @ 2018-12-24 8:47 UTC (permalink / raw)
To: git; +Cc: peff, rafa.almas, gitster, avarab, Nickolai Belakovski
From: Nickolai Belakovski <nbelakovski@gmail.com>
> I don't think that works. The default function is always_equal(), which
> will treat two entries equal if they have the same hash value. I.e., any
> collisions would be considered a match.
You're absolutely right. I've added a compare function, but I left out the
functionality for it to work with an entry passed in as a key. Doing so would
mean the user would have to allocate a worktree struct, which just seems silly
when the ref is all that's needed (and also defeats the purpose of avoiding
extra allocations).
And while most of the hashmap API seems OK, yea, this is definitely awful. It
feels like it should just be able to take a key and return either an entry or
NULL, and do away with entry_or_key and equals_function_data.
Travis-CI results: https://travis-ci.org/nbelakovski/git/builds/471787317
Nickolai Belakovski (3):
ref-filter: add worktreepath atom
branch: Mark and color a branch differently if it is checked out in a
linked worktree
branch: Add an extra verbose output displaying worktree path for refs
checked out in a linked worktree
Documentation/git-for-each-ref.txt | 5 +++
builtin/branch.c | 16 ++++++---
ref-filter.c | 72 +++++++++++++++++++++++++++++++++++++-
t/t3200-branch.sh | 8 ++---
t/t3203-branch-output.sh | 21 +++++++++++
t/t6302-for-each-ref-filter.sh | 15 ++++++++
6 files changed, 128 insertions(+), 9 deletions(-)
--
2.14.2
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [PATCH v4 0/3]
2018-12-24 8:47 ` [PATCH v4 0/3] nbelakovski
@ 2019-01-03 5:22 ` Jeff King
0 siblings, 0 replies; 28+ messages in thread
From: Jeff King @ 2019-01-03 5:22 UTC (permalink / raw)
To: nbelakovski; +Cc: git, rafa.almas, gitster, avarab
On Mon, Dec 24, 2018 at 12:47:53AM -0800, nbelakovski@gmail.com wrote:
> From: Nickolai Belakovski <nbelakovski@gmail.com>
>
> > I don't think that works. The default function is always_equal(), which
> > will treat two entries equal if they have the same hash value. I.e., any
> > collisions would be considered a match.
>
> You're absolutely right. I've added a compare function, but I left out the
> functionality for it to work with an entry passed in as a key. Doing so would
> mean the user would have to allocate a worktree struct, which just seems silly
> when the ref is all that's needed (and also defeats the purpose of avoiding
> extra allocations).
Unfortunately, that doesn't quite work. :)
Your compare function has to handle _both_ cases: two keys, or one key
and a keydata.
The former may be called when the hashmap has to compare two entries
internally (e.g., when it has to re-bucket all of the entries after a
resize). Your tests likely wouldn't run into this case in practice,
since you'd only have a handful of worktrees. But if you added, say,
thousands of worktrees and we had to grow the hash midway through the
process, it would segfault. So you do need to handle the case when your
keydata is NULL.
In theory it would also be used for comparisons if we used a more clever
data structure to hold entries within a bucket. But since we just use a
linked list and linear search for now, we don't.
> And while most of the hashmap API seems OK, yea, this is definitely awful. It
> feels like it should just be able to take a key and return either an entry or
> NULL, and do away with entry_or_key and equals_function_data.
In your case, yeah, equals_function_data is not used at all (but there
are a few call-sites which need it to avoid relying on global data).
But the entry_or_key (coupled with keydata) is the magic that lets the
same function be used for both lookups as well as internal entry
comparisons.
I think having two separate comparison functions would make this a lot
more clear, though likely at the cost of having more boilerplate.
-Peff
^ permalink raw reply [flat|nested] 28+ messages in thread
* [PATCH v4 0/3]
@ 2018-11-02 22:26 Jeykumar Sankaran
0 siblings, 0 replies; 28+ messages in thread
From: Jeykumar Sankaran @ 2018-11-02 22:26 UTC (permalink / raw)
To: dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW,
freedreno-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW,
linux-arm-msm-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA
Cc: robh-DgEjT+Ai2ygdnm+yROfE0A, dianders-F7+t8E8rja9g9hUCZPvPmw,
robdclark-Re5JQEeQqe8AvxtiuMwx3w, mka-F7+t8E8rja9g9hUCZPvPmw,
hoegsberg-hpIqsD4AKlfQT0dZR+AlfA,
seanpaul-F7+t8E8rja9g9hUCZPvPmw, Jeykumar Sankaran
Reviving the patch posted by Sean initially.
This patch set adds MDSS and DSI nodes to SDM845 dtsi to enable display. The
patches are tested on SDM845 MTP platform using the kernel based on [1].
Part of the dependent drivers are already posted on list. Rest of the
dependencies are met using using downstream version of the driver(s) which are
yet to make it to the list.
References to the driver patches used for testing:
display controller: https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/arch/arm64/boot/dts/qcom/sdm845.dtsi?id=40019e8452fe76867bdb2e7
WLED: https://patchwork.kernel.org/project/linux-arm-msm/list/?series=11023&archive=both&state=*
Panel: https://patchwork.freedesktop.org/series/50657/
iommu: https://patchwork.kernel.org/patch/10534999/
[1] https://git.linaro.org/landing-teams/working/qualcomm/kernel.git/log/?h=integration-linux-qcomlt
Thanks and Regards,
Jeykumar S.
Changes in v4:
- changes to add pinctrl nodes to SoC dts and display nodes to MTP
are included in the series
- clock name clean up in dsi nodes
- move around added nodes to maintain naming orders
Jeykumar Sankaran (3):
arm64: dts: qcom: sdm845: Add dpu to sdm845 dts file
arm64: dts: sdm845: Add dsi pinctrl nodes
arm64: dts: sdm845: Add display nodes to MTP dts
arch/arm64/boot/dts/qcom/sdm845-mtp.dts | 124 +++++++++++++++++++
arch/arm64/boot/dts/qcom/sdm845.dtsi | 205 ++++++++++++++++++++++++++++++++
2 files changed, 329 insertions(+)
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
_______________________________________________
Freedreno mailing list
Freedreno@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/freedreno
^ permalink raw reply [flat|nested] 28+ messages in thread
* [PATCH v4 0/3]
@ 2015-07-15 12:40 Tomeu Vizoso
0 siblings, 0 replies; 28+ messages in thread
From: Tomeu Vizoso @ 2015-07-15 12:40 UTC (permalink / raw)
To: linux-pm, Alan Stern, Rafael J. Wysocki
Cc: Tomeu Vizoso, linux-usb, linux-kernel, Len Brown,
Greg Kroah-Hartman, Pavel Machek
Hi,
this is v4 of an attempt to make easier for devices to remain in runtime
PM when the system ges to sleep, mainly to reduce the time spent
resuming devices.
In this version there's a patch from Alan that relaxes the conditions
that allow a device to go directly to the complete phase, thus allowing
its ancestors to do the same.
Also, we interpret the absence of all PM callback implementations as
being safe to do direct_complete as well.
With these changes, a uvcvideo device (for example) stays in runtime
suspend when the system goes to sleep and is left in that state when the
system resumes, not delaying it unnecessarily.
Thanks,
Tomeu
Alan Stern (1):
PM / sleep: Allow devices without runtime PM to do direct-complete
Tomeu Vizoso (2):
PM / sleep: Go direct_complete if driver has no callbacks
USB / PM: Allow USB devices to remain runtime-suspended when sleeping
Documentation/power/devices.txt | 7 +++++++
Documentation/power/runtime_pm.txt | 4 ----
drivers/base/power/main.c | 19 ++++++++++++++++++-
drivers/usb/core/port.c | 6 ++++++
drivers/usb/core/usb.c | 11 ++++++++++-
include/linux/pm_runtime.h | 6 ------
6 files changed, 41 insertions(+), 12 deletions(-)
--
2.4.3
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [PATCH/v3] bundle.c: added --stdin option to git-bundle
@ 2008-07-05 18:15 Junio C Hamano
2008-07-05 20:40 ` [PATCH v4 0/3] Adam Brewster
0 siblings, 1 reply; 28+ messages in thread
From: Junio C Hamano @ 2008-07-05 18:15 UTC (permalink / raw)
To: Adam Brewster
Cc: git, Johannes Schindelin, Mark Levedahl, Junio C Hamano, Jakub Narebski
"Adam Brewster" <adambrewster@gmail.com> writes:
> Subject: Re: [PATCH/v3] bundle.c: added --stdin option to git-bundle
When the change is not about implementation detail (in which case you do
want to name the source file and perhaps even a function name), but about
a new feature that is visible to the end-users of a command, we'd want the
message talk in terms of what the new feature does, not how the new
feature is invoked nor where it is implemented. In other words, something
like these are preferred:
git-bundle: add --stdin
Teach git-bundle to read tips and basis from standard input
and don't say "You did" in past tense --- say things in imperative mood
instead, as if you are commanding the person who applies the patch to make
it happen. Older log entries in our history (e.g. "git log -n 20 v0.99")
may give you a better feel.
And give a few lines of obvious justfication in the body of the commit log
message, e.g.
This patch allows the caller to feed the revision parameters to
git-bundle from its standard input. This way, a script do not
have to worry about limitation of the length of command line.
to explain why this is good. In order to explain that you may have to
talk about other things (like what it does and how it does it), but keep
in mind that the primary thing you should talk about is _why_.
> ... because it already implies that this option is available.
If that is the case, please mention in the commit log message something
like "Even though the documentation said "bundle --stdin" is accepted it
didn't. This patch teaches the option to the command".
But I do not think there is no such implication. "bundle create" may take
list of positive and negative refs as arguments or --branches, but it does
not take (and it shouldn't -- I do not think it should take --bisect
option, for example) artibrary options that rev-list command accepts.
> bundle.c | 22 ++++++++++++++++++++--
> 1 files changed, 20 insertions(+), 2 deletions(-)
>
> diff --git a/bundle.c b/bundle.c
> index 0ba5df1..b44a4af 100644
> --- a/bundle.c
> +++ b/bundle.c
> @@ -227,8 +227,26 @@ int create_bundle(struct bundle_header *header,
> const char *path,
Wrapped.
> /* write references */
> argc = setup_revisions(argc, argv, &revs, NULL);
> - if (argc > 1)
> - return error("unrecognized argument: %s'", argv[1]);
> +
> + for (i = 1; i < argc; i++) {
> + if ( !strcmp(argv[i], "--stdin") ) {
Style.
> + char line[1000];
> + while (fgets(line, sizeof(line),
> stdin) != NULL) {
Too deep indentation. Wrapped.
> + int len = strlen(line);
> + if (len && line[len - 1] == '\n')
> + line[--len] = '\0';
> + if (!len)
> + break;
> + if (line[0] == '-')
> + die("options not supported in
> --stdin mode");
> + if (handle_revision_arg(line, &revs, 0, 1))
> + die("bad revision '%s'", line);
> + }
> + continue;
> + }
> +
> + return error("unrecognized argument: %s'", argv[i]);
> + }
Having said that, I think copying and pasting read_revisions_from_stdin()
in bundle.c is a wrong approach to take. Probably the function can easily
be split out of builtin-rev-list.c and moved to revision.c or somewhere
(which will be the first patch), and then a separate patch can add a few
lines to call it from bundle.c.
^ permalink raw reply [flat|nested] 28+ messages in thread
* [PATCH v4 0/3]
2008-07-05 18:15 [PATCH/v3] bundle.c: added --stdin option to git-bundle Junio C Hamano
@ 2008-07-05 20:40 ` Adam Brewster
0 siblings, 0 replies; 28+ messages in thread
From: Adam Brewster @ 2008-07-05 20:40 UTC (permalink / raw)
To: git; +Cc: gitster, mdl123, Johannes.Schindelin, jnareb, adambrewster
Sorry for the idiotic wrapping problems in my last email.
Previously, I was trying to keep from changing any of the important stuff,
like git-rev-list, but I should know better than cut-and-pasting code.
As requested, I've broken the change into a multiple of patches. First moving
read_revisions_from_stdin to revision.c, next modifying git-bundle to handle
--stdin, and finally a patch adding my old git-basis to contrib.
I think I've corrected all of the style issues you pointed out, and I've also
tried to craft more informative commit messages.
^ permalink raw reply [flat|nested] 28+ messages in thread
end of thread, other threads:[~2019-01-03 5:23 UTC | newest]
Thread overview: 28+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2015-10-14 14:17 [PATCH v4 0/3] Murali Karicheri
2015-10-14 14:17 ` Murali Karicheri
2015-10-14 14:17 ` Murali Karicheri
2015-10-14 14:17 ` [PATCH v4 1/3] Documentation: dt: soc: Add description for knav qmss driver Murali Karicheri
2015-10-14 14:17 ` Murali Karicheri
2015-10-14 14:17 ` Murali Karicheri
2015-10-14 14:17 ` [PATCH v4 2/3] soc: ti: add firmware file name as part of the driver Murali Karicheri
2015-10-14 14:17 ` Murali Karicheri
2015-10-14 14:17 ` Murali Karicheri
2015-10-14 14:17 ` [PATCH v4 3/3] soc: ti: qmss: make acc queue support optional in " Murali Karicheri
2015-10-14 14:17 ` Murali Karicheri
2015-10-14 14:17 ` Murali Karicheri
2015-10-14 15:41 ` [PATCH v4 0/3] santosh shilimkar
2015-10-14 15:41 ` santosh shilimkar
2015-10-15 16:02 ` Murali Karicheri
2015-10-15 16:02 ` Murali Karicheri
2015-10-15 16:02 ` Murali Karicheri
2015-10-15 16:21 ` santosh shilimkar
2015-10-15 16:21 ` santosh shilimkar
2015-10-15 16:21 ` santosh shilimkar
2015-10-15 16:29 ` Murali Karicheri
2015-10-15 16:29 ` Murali Karicheri
2015-10-15 16:29 ` Murali Karicheri
-- strict thread matches above, loose matches on Subject: below --
2018-12-20 14:59 [PATCH v3 1/3] ref-filter: add worktreepath atom Jeff King
2018-12-24 8:47 ` [PATCH v4 0/3] nbelakovski
2019-01-03 5:22 ` Jeff King
2018-11-02 22:26 Jeykumar Sankaran
2015-07-15 12:40 Tomeu Vizoso
2008-07-05 18:15 [PATCH/v3] bundle.c: added --stdin option to git-bundle Junio C Hamano
2008-07-05 20:40 ` [PATCH v4 0/3] Adam Brewster
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.