This patch set brings a number of fixes and the option to control
the QMan portal interrupt coalescing.
Changes from v1:
- change CPU 0 with any online CPU to allow CPU 0 to be taken offline
- move common code in a function
- address all places in the code where the portal interrupt was affined
to CPU 0
- remove unrelated change from patch adding 64 bit DMA addressing
requirement
Madalin Bucur (2):
soc/fsl/qbman: replace CPU 0 with any online CPU in hotplug handlers
soc/fsl_qbman: export coalesce change API
Roy Pledge (3):
soc/fsl/qbman: Check if CPU is offline when initializing portals
soc/fsl/qbman: Add 64 bit DMA addressing requirement to QBMan
soc/fsl/qbman: Use last response to determine valid bit
drivers/soc/fsl/qbman/Kconfig | 2 +-
drivers/soc/fsl/qbman/bman.c | 6 ++---
drivers/soc/fsl/qbman/bman_portal.c | 4 ++-
drivers/soc/fsl/qbman/dpaa_sys.h | 20 ++++++++++++++
drivers/soc/fsl/qbman/qman.c | 53 ++++++++++++++++++++++++++++++++-----
drivers/soc/fsl/qbman/qman_portal.c | 6 +++--
include/soc/fsl/qman.h | 27 +++++++++++++++++++
7 files changed, 104 insertions(+), 14 deletions(-)
--
2.1.0
From: Roy Pledge <redacted>
The QBMan block is memory mapped on SoCs above a 32 bit (4 Gigabyte)
boundary so enabling 64 bit DMA addressing is needed for QBMan to
be usuable.
Signed-off-by: Roy Pledge <redacted>
Signed-off-by: Madalin Bucur <madalin.bucur@nxp.com>
---
drivers/soc/fsl/qbman/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
From: Roy Pledge <redacted>
Use the last valid response when determining what valid bit
to use next for management commands. This is needed in the
case that the portal was previously used by other software
like a bootloader or if the kernel is restarted without a
hardware reset.
Signed-off-by: Roy Pledge <redacted>
Signed-off-by: Madalin Bucur <madalin.bucur@nxp.com>
---
drivers/soc/fsl/qbman/qman.c | 16 ++++++++++++++--
1 file changed, 14 insertions(+), 2 deletions(-)
From: Roy Pledge <redacted>
If the CPU to affine the portal interrupt is offline at boot time
affine the portal interrupt to another online CPU. If the CPU is later
brought online the hotplug handler will correctly adjust the affinity.
Moved common code in a function.
Signed-off-by: Roy Pledge <redacted>
Signed-off-by: Madalin Bucur <madalin.bucur@nxp.com>
---
drivers/soc/fsl/qbman/bman.c | 6 ++----
drivers/soc/fsl/qbman/dpaa_sys.h | 20 ++++++++++++++++++++
drivers/soc/fsl/qbman/qman.c | 6 ++----
3 files changed, 24 insertions(+), 8 deletions(-)
@@ -562,11 +562,9 @@ static int bman_create_portal(struct bman_portal *portal,dev_err(c->dev,"request_irq() failed\n");gotofail_irq;}-if(c->cpu!=-1&&irq_can_set_affinity(c->irq)&&-irq_set_affinity(c->irq,cpumask_of(c->cpu))){-dev_err(c->dev,"irq_set_affinity() failed\n");++if(dpaa_set_portal_irq_affinity(c->dev,c->irq,c->cpu))gotofail_affinity;-}/* Need RCR to be empty before continuing */ret=bm_rcr_get_fill(p);
@@ -111,4 +111,24 @@ int qbman_init_private_mem(struct device *dev, int idx, dma_addr_t *addr,#define QBMAN_MEMREMAP_ATTR MEMREMAP_WC#endif+staticinlineintdpaa_set_portal_irq_affinity(structdevice*dev,+intirq,intcpu)+{+intret=0;++if(!irq_can_set_affinity(irq)){+dev_err(dev,"unable to set IRQ affinity\n");+return-EINVAL;+}++if(cpu==-1||!cpu_online(cpu))+cpu=cpumask_any(cpu_online_mask);++ret=irq_set_affinity(irq,cpumask_of(cpu));+if(ret)+dev_err(dev,"irq_set_affinity() on CPU %d failed\n",cpu);++returnret;+}+#endif /* __DPAA_SYS_H */
@@ -1210,11 +1210,9 @@ static int qman_create_portal(struct qman_portal *portal,dev_err(c->dev,"request_irq() failed\n");gotofail_irq;}-if(c->cpu!=-1&&irq_can_set_affinity(c->irq)&&-irq_set_affinity(c->irq,cpumask_of(c->cpu))){-dev_err(c->dev,"irq_set_affinity() failed\n");++if(dpaa_set_portal_irq_affinity(c->dev,c->irq,c->cpu))gotofail_affinity;-}/* Need EQCR to be empty before continuing */isdr&=~QM_PIRQ_EQCI;
The existing code sets portal IRQ affinity to CPU 0 in the
offline hotplug handler. If CPU 0 is offline this is invalid.
Use a different online CPU instead.
Signed-off-by: Madalin Bucur <madalin.bucur@nxp.com>
---
drivers/soc/fsl/qbman/bman_portal.c | 4 +++-
drivers/soc/fsl/qbman/qman_portal.c | 6 ++++--
2 files changed, 7 insertions(+), 3 deletions(-)
@@ -65,7 +65,9 @@ static int bman_offline_cpu(unsigned int cpu)if(!pcfg)return0;-irq_set_affinity(pcfg->irq,cpumask_of(0));+/* use any other online CPU */+cpu=cpumask_any_but(cpu_online_mask,cpu);+irq_set_affinity(pcfg->irq,cpumask_of(cpu));return0;}
@@ -195,8 +195,10 @@ static int qman_offline_cpu(unsigned int cpu)if(p){pcfg=qman_get_qm_portal_config(p);if(pcfg){-irq_set_affinity(pcfg->irq,cpumask_of(0));-qman_portal_update_sdest(pcfg,0);+/* select any other online CPU */+cpu=cpumask_any_but(cpu_online_mask,cpu);+irq_set_affinity(pcfg->irq,cpumask_of(cpu));+qman_portal_update_sdest(pcfg,cpu);}}return0;
On Fri, Sep 28, 2018 at 3:45 AM Madalin Bucur [off-list ref] wrote:
Export the API required to control the QMan portal interrupt coalescing
settings.
These are new APIs not just old APIs being exported. What is the user
of these APIs? Is the user being submitted? We cannot have APIs in
kernel that has no users.
On Fri, Sep 28, 2018 at 3:44 AM Madalin Bucur [off-list ref] wrote:
Applied 1-4 to for-next while waiting for clarification on 5/5. And
updated the prefix to "soc: fsl:" style to be aligned with arm-soc
convention. Please try to use that style in the future for soc/fsl
patches.
This patch set brings a number of fixes and the option to control
the QMan portal interrupt coalescing.
Changes from v1:
- change CPU 0 with any online CPU to allow CPU 0 to be taken offline
- move common code in a function
- address all places in the code where the portal interrupt was affined
to CPU 0
- remove unrelated change from patch adding 64 bit DMA addressing
requirement
Madalin Bucur (2):
soc/fsl/qbman: replace CPU 0 with any online CPU in hotplug handlers
soc/fsl_qbman: export coalesce change API
Roy Pledge (3):
soc/fsl/qbman: Check if CPU is offline when initializing portals
soc/fsl/qbman: Add 64 bit DMA addressing requirement to QBMan
soc/fsl/qbman: Use last response to determine valid bit
drivers/soc/fsl/qbman/Kconfig | 2 +-
drivers/soc/fsl/qbman/bman.c | 6 ++---
drivers/soc/fsl/qbman/bman_portal.c | 4 ++-
drivers/soc/fsl/qbman/dpaa_sys.h | 20 ++++++++++++++
drivers/soc/fsl/qbman/qman.c | 53 ++++++++++++++++++++++++++++++++-----
drivers/soc/fsl/qbman/qman_portal.c | 6 +++--
include/soc/fsl/qman.h | 27 +++++++++++++++++++
7 files changed, 104 insertions(+), 14 deletions(-)
--
2.1.0
-----Original Message-----
From: Li Yang [mailto:leoyang.li@nxp.com]
Sent: Tuesday, October 2, 2018 12:50 AM
To: Madalin-cristian Bucur <madalin.bucur@nxp.com>
Cc: Roy Pledge <redacted>; Claudiu Manoil
[off-list ref]; Catalin Marinas [off-list ref]; Scott
Wood [off-list ref]; moderated list:ARM/FREESCALE IMX / MXC ARM
ARCHITECTURE [off-list ref]; linuxppc-dev
[off-list ref]; lkml [off-list ref]
Subject: Re: [PATCH v2 5/5] soc/fsl_qbman: export coalesce change API
On Fri, Sep 28, 2018 at 3:45 AM Madalin Bucur [off-list ref]
wrote:
quoted
Export the API required to control the QMan portal interrupt coalescing
settings.
These are new APIs not just old APIs being exported. What is the user
of these APIs? Is the user being submitted? We cannot have APIs in
kernel that has no users.
Hi,
These are new APIs that will be used in the DPAA Ethernet driver.
Changes for the DPAA QBMan and DPAA Ethernet follow different paths upstream
so the Ethernet driver patch that makes use of these APIs will be sent when
these changes reach the net-next/master tree.
Regards,
Madalin
-----Original Message-----
From: Li Yang [mailto:leoyang.li@nxp.com]
Sent: Tuesday, October 2, 2018 1:30 AM
To: Madalin-cristian Bucur <madalin.bucur@nxp.com>
Cc: Roy Pledge <redacted>; Claudiu Manoil
[off-list ref]; Catalin Marinas [off-list ref]; Scott
Wood [off-list ref]; moderated list:ARM/FREESCALE IMX / MXC ARM
ARCHITECTURE [off-list ref]; linuxppc-dev
[off-list ref]; lkml [off-list ref]
Subject: Re: [PATCH v2 0/5] soc/fsl/qbman: DPAA QBMan fixes and additions
On Fri, Sep 28, 2018 at 3:44 AM Madalin Bucur [off-list ref]
wrote:
quoted
Applied 1-4 to for-next while waiting for clarification on 5/5. And
updated the prefix to "soc: fsl:" style to be aligned with arm-soc
convention. Please try to use that style in the future for soc/fsl
patches.
Thank you, I've sent an email about the APIs.
I'm not sure we need to align the prefix to arm-soc as the soc/fsl does not
service only ARM but also PPC based SoCs and historically we've been using
the soc/* format.
Regards,
Madalin
On Tue, Oct 2, 2018 at 1:29 AM Madalin-cristian Bucur
[off-list ref] wrote:
quoted
-----Original Message-----
From: Li Yang [mailto:leoyang.li@nxp.com]
Sent: Tuesday, October 2, 2018 1:30 AM
To: Madalin-cristian Bucur <madalin.bucur@nxp.com>
Cc: Roy Pledge <redacted>; Claudiu Manoil
[off-list ref]; Catalin Marinas [off-list ref]; Scott
Wood [off-list ref]; moderated list:ARM/FREESCALE IMX / MXC ARM
ARCHITECTURE [off-list ref]; linuxppc-dev
[off-list ref]; lkml [off-list ref]
Subject: Re: [PATCH v2 0/5] soc/fsl/qbman: DPAA QBMan fixes and additions
On Fri, Sep 28, 2018 at 3:44 AM Madalin Bucur [off-list ref]
wrote:
quoted
Applied 1-4 to for-next while waiting for clarification on 5/5. And
updated the prefix to "soc: fsl:" style to be aligned with arm-soc
convention. Please try to use that style in the future for soc/fsl
patches.
Thank you, I've sent an email about the APIs.
I'm not sure we need to align the prefix to arm-soc as the soc/fsl does not
service only ARM but also PPC based SoCs and historically we've been using
the soc/* format.
There is no kernel wide guideline about the format of subsystem prefix
in the patch subject. Different subsystems have their own
preferrences. Soc is not considered as a separate subsystem, so we
followed the convention of the architectural subsystem that we merge
patches through. Since we normally get soc patches through the
arm-soc tree right now, I think it would be better to follow the
convention of arm-soc to make them not looking too different in the
arm-soc pull requests. Not sure how sensetive ARM-SOC maintainers
feel about this though.
Regards,
Leo
On Tue, Oct 2, 2018 at 1:08 AM Madalin-cristian Bucur
[off-list ref] wrote:
quoted
-----Original Message-----
From: Li Yang [mailto:leoyang.li@nxp.com]
Sent: Tuesday, October 2, 2018 12:50 AM
To: Madalin-cristian Bucur <madalin.bucur@nxp.com>
Cc: Roy Pledge <redacted>; Claudiu Manoil
[off-list ref]; Catalin Marinas [off-list ref]; Scott
Wood [off-list ref]; moderated list:ARM/FREESCALE IMX / MXC ARM
ARCHITECTURE [off-list ref]; linuxppc-dev
[off-list ref]; lkml [off-list ref]
Subject: Re: [PATCH v2 5/5] soc/fsl_qbman: export coalesce change API
On Fri, Sep 28, 2018 at 3:45 AM Madalin Bucur [off-list ref]
wrote:
quoted
Export the API required to control the QMan portal interrupt coalescing
settings.
These are new APIs not just old APIs being exported. What is the user
of these APIs? Is the user being submitted? We cannot have APIs in
kernel that has no users.
Hi,
These are new APIs that will be used in the DPAA Ethernet driver.
Changes for the DPAA QBMan and DPAA Ethernet follow different paths upstream
so the Ethernet driver patch that makes use of these APIs will be sent when
these changes reach the net-next/master tree.
Applied for next after changing from "export API" to "add API" in the
introduction and updated the subsystem prefix.
Regards,
Leo