Re: [PATCH v9 5/6] PCI: generic: Make pci-host-generic driver numa aware
On Mon, Jan 18, 2016 at 11:11 PM, David Daney wrote:
> On 01/18/2016 08:36 AM, Ganapatrao Kulkarni wrote:
>>
>> update numa_node of device associated with pci bus.
>> moved down devm_kzalloc to allocate from node memory.
>>
>> Signed-off-by: Ganapatrao Kulkarni
>> ---
>> drivers/pci/host/pci-host-generic.c | 9 ++---
>> 1 file changed, 6 insertions(+), 3 deletions(-)
>>
>> diff --git a/drivers/pci/host/pci-host-generic.c
>> b/drivers/pci/host/pci-host-generic.c
>> index 5434c90..0e1ce06 100644
>> --- a/drivers/pci/host/pci-host-generic.c
>> +++ b/drivers/pci/host/pci-host-generic.c
>> @@ -215,11 +215,9 @@ static int gen_pci_probe(struct platform_device
>> *pdev)
>> const struct of_device_id *of_id;
>> struct device *dev = &pdev->dev;
>> struct device_node *np = dev->of_node;
>> - struct gen_pci *pci = devm_kzalloc(dev, sizeof(*pci), GFP_KERNEL);
>> + struct gen_pci *pci;
>> struct pci_bus *bus, *child;
>>
>> - if (!pci)
>> - return -ENOMEM;
>>
>> type = of_get_property(np, "device_type", NULL);
>> if (!type || strcmp(type, "pci")) {
>> @@ -230,6 +228,11 @@ static int gen_pci_probe(struct platform_device
>> *pdev)
>> of_pci_check_probe_only();
>>
>> of_id = of_match_node(gen_pci_of_match, np);
>> + set_dev_node(dev, of_node_to_nid(np));
>
>
> This shouldn't be done in individual platform_drivers, but instead in the
> device probing code.
>
> There is code that does this in drivers/of/platform.c and
> drivers/of/device.c Is that not being called for the pci-host-gweneric
> devices? If not, we should figure out why, and perhaps attempt to fix it
> rather than doing it here.
is it more appropriate to call of_platform_device_create ?
--- a/drivers/pci/host/pci-host-generic.c
+++ b/drivers/pci/host/pci-host-generic.c
@@ -24,6 +24,7 @@
#include
#include
#include
+#include
struct gen_pci;
@@ -466,7 +467,7 @@ static int gen_pci_probe(struct platform_device *pdev)
of_pci_check_probe_only();
of_id = of_match_node(gen_pci_of_match, np);
- set_dev_node(dev, of_node_to_nid(np));
+ of_platform_device_create(np, NULL, NULL);
pci = devm_kzalloc(dev, sizeof(*pci), GFP_KERNEL);
if (!pci)
return -ENOMEM;
>
>
>
>> + pci = devm_kzalloc(dev, sizeof(*pci), GFP_KERNEL);
>> + if (!pci)
>> + return -ENOMEM;
>> +
>> pci->cfg.ops = (struct gen_pci_cfg_bus_ops *)of_id->data;
>> pci->host.dev.parent = dev;
>> INIT_LIST_HEAD(&pci->host.windows);
>>
>
thanks
Ganapat
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH 1/3][v2] net: phy: introduce 1000BASE-KX and 10GBASE-KR
> -Original Message- > From: Andrew Lunn [mailto:and...@lunn.ch] > Sent: Monday, January 18, 2016 11:15 PM > To: Shaohui Xie > Cc: Sebastian Hesselbarth; Florian Fainelli; shh@gmail.com; > devicet...@vger.kernel.org; net...@vger.kernel.org; linuxppc- > d...@lists.ozlabs.org; da...@davemloft.net; Shaohui Xie > Subject: Re: [PATCH 1/3][v2] net: phy: introduce 1000BASE-KX and 10GBASE-KR > > > [S.H] the fsl backplane, e.g. 10GBASE-KR, needs software to handle > > link training, It's to train link partner, and trained by link partner > parallel. > > > > But if media type is not copper, e.g. optical module, we won't need this. > > So what we actually need to know is copper vs fibre? Copper is not enough to indicate backplane, since backplane is always copper, but copper is not always backplane. Thank you! Shaohui ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [RFC PATCH kernel] powerpc/ioda: Set "read" permission when "write" is set
On 01/13/2016 01:24 PM, Douglas Miller wrote:
On 01/12/2016 05:07 PM, Benjamin Herrenschmidt wrote:
On Tue, 2016-01-12 at 15:40 +1100, Alexey Kardashevskiy wrote:
Quite often drivers set only "write" permission assuming that this
includes "read" permission as well and this works on plenty
platforms.
However IODA2 is strict about this and produces an EEH when "read"
permission is not and reading happens.
This adds a workaround in IODA code to always add the "read" bit when
the "write" bit is set.
Cc: Benjamin Herrenschmidt
Signed-off-by: Alexey Kardashevskiy
---
Ben, what was the driver which did not set "read" and caused EEH?
aacraid
Cheers,
Ben.
Just to be precise, the driver wasn't responsible for setting READ. The
driver called scsi_dma_map() and the scsicmd was set (by scsi layer) as
DMA_FROM_DEVICE so the current code would set the permissions to
WRITE-ONLY. Previously, and in other architectures, this scsicmd would have
resulted in READ+WRITE permissions on the DMA map.
Does the patch fix the issue? Thanks.
---
arch/powerpc/platforms/powernv/pci.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/arch/powerpc/platforms/powernv/pci.c
b/arch/powerpc/platforms/powernv/pci.c
index f2dd772..c7dcae5 100644
--- a/arch/powerpc/platforms/powernv/pci.c
+++ b/arch/powerpc/platforms/powernv/pci.c
@@ -601,6 +601,9 @@ int pnv_tce_build(struct iommu_table *tbl, long
index, long npages,
u64 rpn = __pa(uaddr) >> tbl->it_page_shift;
long i;
+if (proto_tce & TCE_PCI_WRITE)
+proto_tce |= TCE_PCI_READ;
+
for (i = 0; i < npages; i++) {
unsigned long newtce = proto_tce |
((rpn + i) << tbl->it_page_shift);
@@ -622,6 +625,9 @@ int pnv_tce_xchg(struct iommu_table *tbl, long
index,
BUG_ON(*hpa & ~IOMMU_PAGE_MASK(tbl));
+if (newtce & TCE_PCI_WRITE)
+newtce |= TCE_PCI_READ;
+
oldtce = xchg(pnv_tce(tbl, idx), cpu_to_be64(newtce));
*hpa = be64_to_cpu(oldtce) & ~(TCE_PCI_READ |
TCE_PCI_WRITE);
*direction = iommu_tce_direction(oldtce);
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
--
Alexey
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH 3/6] QE: Add uqe_serial document to bindings
On Fri, Jan 19, 2016 at 07:08 PM, Scott Wood wrote: > -Original Message- > From: Scott Wood [mailto:o...@buserror.net] > Sent: Tuesday, January 19, 2016 7:08 AM > To: Qiang Zhao ; Li Yang > Cc: devicet...@vger.kernel.org; lkml ; > linuxppc-dev ; priyanka.j...@freescale.com > Subject: Re: [PATCH 3/6] QE: Add uqe_serial document to bindings > > On Mon, 2016-01-18 at 09:24 +, Qiang Zhao wrote: > > On Fri, Jan 18, 2016 at 05:10 PM, Li Yang wrote: > > > -Original Message- > > > From: pku@gmail.com [mailto:pku@gmail.com] On Behalf Of Li > > > Yang > > > Sent: Monday, January 18, 2016 5:10 PM > > > To: Qiang Zhao > > > Cc: devicet...@vger.kernel.org; lkml ; > > > linuxppc-dev ; > > > priyanka.j...@freescale.com; o...@buserror.net > > > Subject: Re: [PATCH 3/6] QE: Add uqe_serial document to bindings > > > > > > On Fri, Jan 8, 2016 at 10:18 AM, Zhao Qiang wrote: > > > > Add uqe_serial document to > > > > Documentation/devicetree/bindings/powerpc/fsl/cpm_qe/uqe_serial.tx > > > > t > > > > > > As you have submitted patch to move QE code from arch/powerpc into > > > drivers/soc/fsl for the reuse of ARM and powerpc, you should also > > > move the binding documents out of the powerpc folder into a more > > > common place and add new bindings in the new location. > > > > Thank you for your recommendation. > > How about create a new directory named qe under > > "Documentation/devicetree/bindings/"? > > Or you have a better suggestion? > > Documentation/devicetree/bindings/soc/fsl/cpm_qe Thank you very much! Best Regards Zhao Qiang ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v4 2/9] ppc64le FTRACE_WITH_REGS implementation
On Mon, 2016-01-18 at 23:22 +0100, Jiri Kosina wrote: > On Tue, 5 Jan 2016, Torsten Duwe wrote: > > > > I (still) haven't had a chance to have a good look at it, but I won't > > > this week > > > anyway. So post v5 and hopefully I can review that and it will be perfect > > > :) > > > > The perfect v5 is there now, for 4 weeks minus the holiday season, and > > no further problems arose. Independently verified by Petr Mladek -- > > don't forget his high-level fix. > > Hi everybody, > > so what are the current plans with this one, please? Is this going through > ppc tree, ftrace tree, or does it have issues that need to be worked on > before merging? Anton and I need to review it and then it will be merged via the powerpc tree. We just haven't had the spare cycles to do it. cheers ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 3/6] QE: Add uqe_serial document to bindings
On Mon, 2016-01-18 at 09:24 +, Qiang Zhao wrote: > On Fri, Jan 18, 2016 at 05:10 PM, Li Yang wrote: > > -Original Message- > > From: pku@gmail.com [mailto:pku@gmail.com] On Behalf Of Li Yang > > Sent: Monday, January 18, 2016 5:10 PM > > To: Qiang Zhao > > Cc: devicet...@vger.kernel.org; lkml ; > > linuxppc-dev ; priyanka.j...@freescale.com; > > o...@buserror.net > > Subject: Re: [PATCH 3/6] QE: Add uqe_serial document to bindings > > > > On Fri, Jan 8, 2016 at 10:18 AM, Zhao Qiang wrote: > > > Add uqe_serial document to > > > Documentation/devicetree/bindings/powerpc/fsl/cpm_qe/uqe_serial.txt > > > > As you have submitted patch to move QE code from arch/powerpc into > > drivers/soc/fsl for the reuse of ARM and powerpc, you should also move > > the > > binding documents out of the powerpc folder into a more common place and > > add new bindings in the new location. > > Thank you for your recommendation. > How about create a new directory named qe under > "Documentation/devicetree/bindings/"? > Or you have a better suggestion? Documentation/devicetree/bindings/soc/fsl/cpm_qe -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v4 2/9] ppc64le FTRACE_WITH_REGS implementation
On Tue, 5 Jan 2016, Torsten Duwe wrote: > > I (still) haven't had a chance to have a good look at it, but I won't this > > week > > anyway. So post v5 and hopefully I can review that and it will be perfect :) > > The perfect v5 is there now, for 4 weeks minus the holiday season, and > no further problems arose. Independently verified by Petr Mladek -- > don't forget his high-level fix. Hi everybody, so what are the current plans with this one, please? Is this going through ppc tree, ftrace tree, or does it have issues that need to be worked on before merging? Thanks! -- Jiri Kosina SUSE Labs ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] ASoC: fsl_ssi: remove explicit register defaults
On Mon, Jan 18, 2016 at 5:07 PM, Maciej S. Szmigiero
wrote:
> There is no guarantee that on fsl_ssi module load
> SSI registers will have their power-on-reset values.
>
> In fact, if the driver is reloaded the values in
> registers will be whatever they were set to previously.
>
> However, the cache needs to be fully populated at probe
> time to avoid non-atomic allocations during register
> access.
>
> Special case here is imx21-class SSI, since
> according to datasheet it don't have SACC{ST,EN,DIS}
> regs.
>
> This fixes hard lockup on fsl_ssi module reload,
> at least in AC'97 mode.
>
> Fixes: 05cf237972fe ("ASoC: fsl_ssi: Add driver suspend and resume to support
> MEGA Fast")
>
> Signed-off-by: Maciej S. Szmigiero
Tested-by: Fabio Estevam
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] ASoC: fsl_ssi: Set watermark and maxburst settings to eliminate DMA xruns on imx processors
On Mon, Jan 18, 2016 at 10:59 AM, kbuild test robot wrote: > Hi Caleb, > > [auto build test ERROR on asoc/for-next] > [also build test ERROR on v4.4 next-20160118] > [if your patch is applied to the wrong git tree, please drop us a note to > help improving the system] > > url: > https://github.com/0day-ci/linux/commits/Caleb-Crome/ASoC-fsl_ssi-Set-watermark-and-maxburst-settings-to-eliminate-DMA-xruns-on-imx-processors/20160119-024143 > base: https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git > for-next > config: x86_64-randconfig-x019-01180513 (attached as .config) > reproduce: Doh, sorry sent the wrong patch file. Will re-submit shortly. -Caleb ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] ASoC: fsl_ssi: Set watermark and maxburst settings to eliminate DMA xruns on imx processors
Change watermark settings for imx processors. The previous setting
was fifo_depth-2, which causes silent but deadly xruns when using more
than 2 channels. This patch sets the watermark & maxburst
settings to
DMA, imx processors: 4
DMA, mpc8610 : fifo_depth - 2
FIQ, all : fifo_depth
This leaves mpc8610 with identically the same settings as before this
patch, and changes the IMX processors to have a watermark setting of
4, meaning when there are 4 or more empty spaces in the TX FIFO, to
start a DMA burst. And similarly, when there are 4 or more
filled spaces in the RX fifo, to start a DMA burst.
The tradeoff with this patch is that on IMX processors, the DMA will
be more reliable (not have DMA slips), epseically when running more
than 2 channels, at the expense of more DMA transactions. Interrupt
frequency is unaffected.
Signed-off-by: Caleb Crome
---
sound/soc/fsl/fsl_ssi.c | 54 ++---
1 file changed, 33 insertions(+), 21 deletions(-)
diff --git a/sound/soc/fsl/fsl_ssi.c b/sound/soc/fsl/fsl_ssi.c
index 95d2392..5080c29 100644
--- a/sound/soc/fsl/fsl_ssi.c
+++ b/sound/soc/fsl/fsl_ssi.c
@@ -220,6 +220,10 @@ struct fsl_ssi_soc_data {
* @dbg_stats: Debugging statistics
*
* @soc: SoC specific data
+ *
+ * @fifo_watermark: the fifo level to signal the DMA for more words
+ * @dma_maxburst:the maximum number of words to send to the fifo
+ * in a DMA burst
*/
struct fsl_ssi_private {
struct regmap *regs;
@@ -257,6 +261,9 @@ struct fsl_ssi_private {
struct fsl_ssi_dbg dbg_stats;
const struct fsl_ssi_soc_data *soc;
+
+ u32 fifo_watermark;
+ u32 dma_maxburst;
};
/*
@@ -985,21 +992,7 @@ static int _fsl_ssi_set_dai_fmt(struct device *dev,
regmap_write(regs, CCSR_SSI_SRCR, srcr);
regmap_write(regs, CCSR_SSI_SCR, scr);
- /*
-* Set the watermark for transmit FIFI 0 and receive FIFO 0. We don't
-* use FIFO 1. We program the transmit water to signal a DMA transfer
-* if there are only two (or fewer) elements left in the FIFO. Two
-* elements equals one frame (left channel, right channel). This value,
-* however, depends on the depth of the transmit buffer.
-*
-* We set the watermark on the same level as the DMA burstsize. For
-* fiq it is probably better to use the biggest possible watermark
-* size.
-*/
- if (ssi_private->use_dma)
- wm = ssi_private->fifo_depth - 2;
- else
- wm = ssi_private->fifo_depth;
+ wm = ssi_private->soc.fifo_watermark;
regmap_write(regs, CCSR_SSI_SFCSR,
CCSR_SSI_SFCSR_TFWM0(wm) | CCSR_SSI_SFCSR_RFWM0(wm) |
@@ -1307,12 +1300,8 @@ static int fsl_ssi_imx_probe(struct platform_device
*pdev,
dev_dbg(&pdev->dev, "could not get baud clock: %ld\n",
PTR_ERR(ssi_private->baudclk));
- /*
-* We have burstsize be "fifo_depth - 2" to match the SSI
-* watermark setting in fsl_ssi_startup().
-*/
- ssi_private->dma_params_tx.maxburst = ssi_private->fifo_depth - 2;
- ssi_private->dma_params_rx.maxburst = ssi_private->fifo_depth - 2;
+ ssi_private->dma_params_tx.maxburst = ssi_private->dma_maxburst;
+ ssi_private->dma_params_rx.maxburst = ssi_private->dma_maxburst;
ssi_private->dma_params_tx.addr = ssi_private->ssi_phys + CCSR_SSI_STX0;
ssi_private->dma_params_rx.addr = ssi_private->ssi_phys + CCSR_SSI_SRX0;
@@ -1465,6 +1454,29 @@ static int fsl_ssi_probe(struct platform_device *pdev)
/* Older 8610 DTs didn't have the fifo-depth property */
ssi_private->fifo_depth = 8;
+ if (ssi_private->use_dma) {
+ /*
+* using DMA, set both watermark & maxburst
+* imx parts need a value of 4 to keep up with the
+* fastest data rates.
+* older non-imx parts keep the old values of
+* fifo_depth-2.
+* maxburst must be <= fifo_watermark;
+* and must be even if dual fifo is used.
+*/
+ if (ssi_private->soc->imx) {
+ ssi_private->fifo_watermark = 4;
+ ssi_private->dma_maxburst = 4;
+ } else {
+ ssi_private->fifo_watermark =
+ ssi_private->fifo_depth - 2;
+ ssi_private->dma_maxburst =
+ ssi_private->fifo_depth - 2;
+ }
+ } else
+ /* using FIQ. Keep settings what they were originally */
+ ssi_private->fifo_watermark = ssi_private->fifo_depth;
+
dev_set_drvdata(&pdev->dev, ssi_private);
if (ssi_private->soc->imx) {
--
2.1.4
___
Linuxppc-dev ma
[PATCH v9 0/6] arm64, numa: Add numa support for arm64 platforms
v9: - Added cleanup patch to reuse and avoid redefinition of cpumask_of_pcibus as suggested from Will Deacon and Bjorn Helgaas. - Including patch to Make pci-host-generic driver numa aware. - Incorporated comment from Shannon Zhao. v8: - Incorporated review comments of Mark Rutland and Will Deacon. - Added pci helper function and macro for numa. v7: - managing numa memory mapping using memblock. - Incorporated review comments of Mark Rutland. v6: - defined and implemented the numa dt binding using node property proximity and device node distance-map. - renamed dt_numa to of_numa v5: - created base verion of numa.c which creates dummy numa without using dt on single socket platforms. Then added patches for dt support. - Incorporated review comments from Hanjun Guo. v4: done changes as per Arnd review comments. v3: Added changes to support numa on arm64 based platforms. Tested these patches on cavium's multinode(2 node topology) platform. In this patchset, defined and implemented dt bindings for numa mapping for core and memory using device node property arm,associativity. v2: Defined and implemented numa map for memory, cores to node and proximity distance matrix of nodes. v1: Initial patchset to support numa on arm64 platforms. Note: 1. This patchset is tested for numa with dt on thunderx single socket and dual socket boards. 2. Numa DT booting needs the dt memory nodes, which are deleted in current efi-stub, hence to try numa with dt, you need to rebase with ard's patchset. http://git.linaro.org/people/ard.biesheuvel/linux-arm.git/shortlog/refs/heads/arm64-uefi-early-fdt-handling 3. PATCH 6 is not tested for other architectures. Ganapatrao Kulkarni (6): arm64, numa: adding numa support for arm64 platforms. Documentation, dt, arm64/arm: dt bindings for numa. arm64/arm, numa, dt: adding numa dt binding implementation for arm64 platforms. arm64, dt, thunderx: Add initial dts for Cavium Thunderx in 2 node topology. PCI: generic: Make pci-host-generic driver numa aware topology, cleanup: Avoid redefinition of cpumask_of_pcibus in asm header files. Documentation/devicetree/bindings/arm/numa.txt | 272 arch/arm64/Kconfig | 35 + arch/arm64/boot/dts/cavium/Makefile | 2 +- arch/arm64/boot/dts/cavium/thunder-88xx-2n.dts | 83 +++ arch/arm64/boot/dts/cavium/thunder-88xx-2n.dtsi | 806 arch/arm64/include/asm/mmzone.h | 18 + arch/arm64/include/asm/numa.h | 50 ++ arch/arm64/include/asm/topology.h | 7 + arch/arm64/kernel/Makefile | 1 + arch/arm64/kernel/of_numa.c | 257 arch/arm64/kernel/pci.c | 8 + arch/arm64/kernel/setup.c | 4 + arch/arm64/kernel/smp.c | 4 + arch/arm64/mm/Makefile | 1 + arch/arm64/mm/init.c| 31 +- arch/arm64/mm/mmu.c | 1 + arch/arm64/mm/numa.c| 395 arch/ia64/include/asm/topology.h| 4 - arch/metag/include/asm/topology.h | 3 - arch/powerpc/include/asm/topology.h | 4 - arch/s390/include/asm/pci.h | 2 +- arch/s390/include/asm/topology.h| 1 + arch/sh/include/asm/topology.h | 3 - arch/x86/include/asm/pci.h | 2 +- arch/x86/include/asm/topology.h | 1 + drivers/pci/host/pci-host-generic.c | 9 +- include/asm-generic/topology.h | 4 +- 27 files changed, 1981 insertions(+), 27 deletions(-) create mode 100644 Documentation/devicetree/bindings/arm/numa.txt create mode 100644 arch/arm64/boot/dts/cavium/thunder-88xx-2n.dts create mode 100644 arch/arm64/boot/dts/cavium/thunder-88xx-2n.dtsi create mode 100644 arch/arm64/include/asm/mmzone.h create mode 100644 arch/arm64/include/asm/numa.h create mode 100644 arch/arm64/kernel/of_numa.c create mode 100644 arch/arm64/mm/numa.c -- 1.8.1.4 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH v9 3/6] arm64/arm, numa, dt: adding numa dt binding implementation for arm64 platforms.
Adding numa dt binding support for arm64 based platforms.
dt node parsing for numa topology is done using device property
numa-node-id and device node distance-map.
Reviewed-by: Robert Richter
Signed-off-by: Ganapatrao Kulkarni
---
arch/arm64/Kconfig| 10 ++
arch/arm64/include/asm/numa.h | 10 ++
arch/arm64/kernel/Makefile| 1 +
arch/arm64/kernel/of_numa.c | 257 ++
arch/arm64/kernel/smp.c | 2 +
arch/arm64/mm/numa.c | 10 +-
6 files changed, 289 insertions(+), 1 deletion(-)
create mode 100644 arch/arm64/kernel/of_numa.c
diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index 74f5d73..775cf4a 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -515,6 +515,16 @@ config NUMA
local memory of the CPU and add some more
NUMA awareness to the kernel.
+config OF_NUMA
+ bool "Device Tree NUMA support"
+ depends on NUMA
+ depends on OF
+ default y
+ help
+ Enable Device Tree NUMA support.
+ This enables the numa mapping of cpu, memory, io and
+ inter node distances using dt bindings.
+
config NODES_SHIFT
int "Maximum NUMA Nodes (as a power of 2)"
range 1 10
diff --git a/arch/arm64/include/asm/numa.h b/arch/arm64/include/asm/numa.h
index f28f15b0..54deb38 100644
--- a/arch/arm64/include/asm/numa.h
+++ b/arch/arm64/include/asm/numa.h
@@ -37,4 +37,14 @@ void numa_store_cpu_info(unsigned int cpu);
static inline void numa_store_cpu_info(unsigned int cpu) { }
static inline void arm64_numa_init(void) { }
#endif /* CONFIG_NUMA */
+
+struct device_node;
+#ifdef CONFIG_OF_NUMA
+int __init arm64_of_numa_init(void);
+void __init of_numa_set_node_info(unsigned int cpu, struct device_node *dn);
+#else
+static inline void of_numa_set_node_info(unsigned int cpu,
+ struct device_node *dn) { }
+#endif
+
#endif /* __ASM_NUMA_H */
diff --git a/arch/arm64/kernel/Makefile b/arch/arm64/kernel/Makefile
index 474691f..7987763 100644
--- a/arch/arm64/kernel/Makefile
+++ b/arch/arm64/kernel/Makefile
@@ -41,6 +41,7 @@ arm64-obj-$(CONFIG_EFI) += efi.o
efi-entry.stub.o
arm64-obj-$(CONFIG_PCI)+= pci.o
arm64-obj-$(CONFIG_ARMV8_DEPRECATED) += armv8_deprecated.o
arm64-obj-$(CONFIG_ACPI) += acpi.o
+arm64-obj-$(CONFIG_OF_NUMA)+= of_numa.o
obj-y += $(arm64-obj-y) vdso/
obj-m += $(arm64-obj-m)
diff --git a/arch/arm64/kernel/of_numa.c b/arch/arm64/kernel/of_numa.c
new file mode 100644
index 000..2f9e34b
--- /dev/null
+++ b/arch/arm64/kernel/of_numa.c
@@ -0,0 +1,257 @@
+/*
+ * OF NUMA Parsing support.
+ *
+ * Copyright (C) 2015 Cavium Inc.
+ * Author: Ganapatrao Kulkarni
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program. If not, see
[PATCH v9 2/6] Documentation, dt, arm64/arm: dt bindings for numa.
DT bindings for numa mapping of memory, cores and IOs.
Reviewed-by: Robert Richter
Signed-off-by: Ganapatrao Kulkarni
---
Documentation/devicetree/bindings/arm/numa.txt | 272 +
1 file changed, 272 insertions(+)
create mode 100644 Documentation/devicetree/bindings/arm/numa.txt
diff --git a/Documentation/devicetree/bindings/arm/numa.txt
b/Documentation/devicetree/bindings/arm/numa.txt
new file mode 100644
index 000..734e5b4
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/numa.txt
@@ -0,0 +1,272 @@
+==
+NUMA binding description.
+==
+
+==
+1 - Introduction
+==
+
+Systems employing a Non Uniform Memory Access (NUMA) architecture contain
+collections of hardware resources including processors, memory, and I/O buses,
+that comprise what is commonly known as a NUMA node.
+Processor accesses to memory within the local NUMA node is generally faster
+than processor accesses to memory outside of the local NUMA node.
+DT defines interfaces that allow the platform to convey NUMA node
+topology information to OS.
+
+==
+2 - numa-node-id
+==
+
+For the purpose of identification, each NUMA node is associated with a unique
+token known as a node id. For the purpose of this binding
+a node id is a 32-bit integer.
+
+A device node is associated with a NUMA node by the presence of a
+numa-node-id property which contains the node id of the device.
+
+Example:
+ /* numa node 0 */
+ numa-node-id = <0>;
+
+ /* numa node 1 */
+ numa-node-id = <1>;
+
+==
+3 - distance-map
+==
+
+The device tree node distance-map describes the relative
+distance (memory latency) between all numa nodes.
+
+- compatible : Should at least contain "numa-distance-map-v1".
+
+- distance-matrix
+ This property defines a matrix to describe the relative distances
+ between all numa nodes.
+ It is represented as a list of node pairs and their relative distance.
+
+ Note:
+ 1. Each entry represents distance from first node to second node.
+ The distances are equal in either direction.
+ 2. The distance from a node to self (local distance) is represented
+ with value 10 and all internode distance should be represented with
+ a value greater than 10.
+ 3. distance-matrix should have entries in lexicographical ascending
+ order of nodes.
+ 4. There must be only one device node distance-map which must reside in
the root node.
+
+Example:
+ 4 nodes connected in mesh/ring topology as below,
+
+ 0___20__1
+ | |
+ | |
+ 20 20
+ | |
+ | |
+ |___|
+ 3 20 2
+
+ if relative distance for each hop is 20,
+ then internode distance would be,
+ 0 -> 1 = 20
+ 1 -> 2 = 20
+ 2 -> 3 = 20
+ 3 -> 0 = 20
+ 0 -> 2 = 40
+ 1 -> 3 = 40
+
+ and dt presentation for this distance matrix is,
+
+ distance-map {
+compatible = "numa-distance-map-v1";
+distance-matrix = <0 0 10>,
+ <0 1 20>,
+ <0 2 40>,
+ <0 3 20>,
+ <1 0 20>,
+ <1 1 10>,
+ <1 2 20>,
+ <1 3 40>,
+ <2 0 40>,
+ <2 1 20>,
+ <2 2 10>,
+ <2 3 20>,
+ <3 0 20>,
+ <3 1 40>,
+ <3 2 20>,
+ <3 3 10>;
+ };
+
+==
+4 - Example dts
+==
+
+2 sockets system consists of 2 boards connected through ccn bus and
+each board having one socket/soc of 8 cpus, memory and pci bus.
+
+ memory
[PATCH v9 1/6] arm64, numa: adding numa support for arm64 platforms.
Adding numa support for arm64 based platforms.
This patch adds by default the dummy numa node and
maps all memory and cpus to node 0.
using this patch, numa can be simulated on single node arm64 platforms.
Tested-by: Shannon Zhao
Reviewed-by: Robert Richter
Signed-off-by: Ganapatrao Kulkarni
---
arch/arm64/Kconfig| 25 +++
arch/arm64/include/asm/mmzone.h | 18 ++
arch/arm64/include/asm/numa.h | 40
arch/arm64/include/asm/topology.h | 10 +
arch/arm64/kernel/pci.c | 8 +
arch/arm64/kernel/setup.c | 4 +
arch/arm64/kernel/smp.c | 2 +
arch/arm64/mm/Makefile| 1 +
arch/arm64/mm/init.c | 31 ++-
arch/arm64/mm/mmu.c | 1 +
arch/arm64/mm/numa.c | 387 ++
11 files changed, 522 insertions(+), 5 deletions(-)
create mode 100644 arch/arm64/include/asm/mmzone.h
create mode 100644 arch/arm64/include/asm/numa.h
create mode 100644 arch/arm64/mm/numa.c
diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index 871f217..74f5d73 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -71,6 +71,7 @@ config ARM64
select HAVE_GENERIC_DMA_COHERENT
select HAVE_HW_BREAKPOINT if PERF_EVENTS
select HAVE_MEMBLOCK
+ select HAVE_MEMBLOCK_NODE_MAP if NUMA
select HAVE_PATA_PLATFORM
select HAVE_PERF_EVENTS
select HAVE_PERF_REGS
@@ -503,6 +504,30 @@ config HOTPLUG_CPU
Say Y here to experiment with turning CPUs off and on. CPUs
can be controlled through /sys/devices/system/cpu.
+# Common NUMA Features
+config NUMA
+ bool "Numa Memory Allocation and Scheduler Support"
+ depends on SMP
+ help
+ Enable NUMA (Non Uniform Memory Access) support.
+
+ The kernel will try to allocate memory used by a CPU on the
+ local memory of the CPU and add some more
+ NUMA awareness to the kernel.
+
+config NODES_SHIFT
+ int "Maximum NUMA Nodes (as a power of 2)"
+ range 1 10
+ default "2"
+ depends on NEED_MULTIPLE_NODES
+ help
+ Specify the maximum number of NUMA Nodes available on the target
+ system. Increases memory reserved to accommodate various tables.
+
+config USE_PERCPU_NUMA_NODE_ID
+ def_bool y
+ depends on NUMA
+
source kernel/Kconfig.preempt
source kernel/Kconfig.hz
diff --git a/arch/arm64/include/asm/mmzone.h b/arch/arm64/include/asm/mmzone.h
new file mode 100644
index 000..2cd804d
--- /dev/null
+++ b/arch/arm64/include/asm/mmzone.h
@@ -0,0 +1,18 @@
+#ifndef __ASM_MMZONE_H
+#define __ASM_MMZONE_H
+
+#ifdef CONFIG_NUMA
+
+#include
+#include
+
+#include
+#include
+
+extern struct pglist_data *node_data[];
+
+#define NODE_DATA(nid) (node_data[(nid)])
+
+#endif /* CONFIG_NUMA */
+
+#endif /* __ASM_MMZONE_H */
diff --git a/arch/arm64/include/asm/numa.h b/arch/arm64/include/asm/numa.h
new file mode 100644
index 000..f28f15b0
--- /dev/null
+++ b/arch/arm64/include/asm/numa.h
@@ -0,0 +1,40 @@
+#ifndef __ASM_NUMA_H
+#define __ASM_NUMA_H
+
+#include
+#include
+
+#ifdef CONFIG_NUMA
+
+/* currently, arm64 implements flat NUMA topology */
+#define parent_node(node) (node)
+
+extern int __node_distance(int from, int to);
+#define node_distance(a, b) __node_distance(a, b)
+
+extern int cpu_to_node_map[NR_CPUS];
+extern nodemask_t numa_nodes_parsed __initdata;
+
+/* Mappings between node number and cpus on that node. */
+extern cpumask_var_t node_to_cpumask_map[MAX_NUMNODES];
+extern void numa_clear_node(unsigned int cpu);
+#ifdef CONFIG_DEBUG_PER_CPU_MAPS
+extern const struct cpumask *cpumask_of_node(int node);
+#else
+/* Returns a pointer to the cpumask of CPUs on Node 'node'. */
+static inline const struct cpumask *cpumask_of_node(int node)
+{
+ return node_to_cpumask_map[node];
+}
+#endif
+
+void __init arm64_numa_init(void);
+int __init numa_add_memblk(int nodeid, u64 start, u64 end);
+void __init numa_set_distance(int from, int to, int distance);
+void __init numa_reset_distance(void);
+void numa_store_cpu_info(unsigned int cpu);
+#else /* CONFIG_NUMA */
+static inline void numa_store_cpu_info(unsigned int cpu) { }
+static inline void arm64_numa_init(void) { }
+#endif /* CONFIG_NUMA */
+#endif /* __ASM_NUMA_H */
diff --git a/arch/arm64/include/asm/topology.h
b/arch/arm64/include/asm/topology.h
index a3e9d6f..8b57339 100644
--- a/arch/arm64/include/asm/topology.h
+++ b/arch/arm64/include/asm/topology.h
@@ -22,6 +22,16 @@ void init_cpu_topology(void);
void store_cpu_topology(unsigned int cpuid);
const struct cpumask *cpu_coregroup_mask(int cpu);
+#ifdef CONFIG_NUMA
+
+struct pci_bus;
+int pcibus_to_node(struct pci_bus *bus);
+#define cpumask_of_pcibus(bus) (pcibus_to_node(bus) == -1 ?\
+cpu_all_mask : \
+cpumask_of_node(pcibus_to_node(bus
[PATCH v9 4/6] arm64, dt, thunderx: Add initial dts for Cavium Thunderx in 2 node topology.
Adding dt file for Cavium's Thunderx dual socket platform.
Signed-off-by: Ganapatrao Kulkarni
---
arch/arm64/boot/dts/cavium/Makefile | 2 +-
arch/arm64/boot/dts/cavium/thunder-88xx-2n.dts | 83 +++
arch/arm64/boot/dts/cavium/thunder-88xx-2n.dtsi | 806
3 files changed, 890 insertions(+), 1 deletion(-)
create mode 100644 arch/arm64/boot/dts/cavium/thunder-88xx-2n.dts
create mode 100644 arch/arm64/boot/dts/cavium/thunder-88xx-2n.dtsi
diff --git a/arch/arm64/boot/dts/cavium/Makefile
b/arch/arm64/boot/dts/cavium/Makefile
index e34f89d..7fe7067 100644
--- a/arch/arm64/boot/dts/cavium/Makefile
+++ b/arch/arm64/boot/dts/cavium/Makefile
@@ -1,4 +1,4 @@
-dtb-$(CONFIG_ARCH_THUNDER) += thunder-88xx.dtb
+dtb-$(CONFIG_ARCH_THUNDER) += thunder-88xx.dtb thunder-88xx-2n.dtb
always := $(dtb-y)
subdir-y := $(dts-dirs)
diff --git a/arch/arm64/boot/dts/cavium/thunder-88xx-2n.dts
b/arch/arm64/boot/dts/cavium/thunder-88xx-2n.dts
new file mode 100644
index 000..5601e87
--- /dev/null
+++ b/arch/arm64/boot/dts/cavium/thunder-88xx-2n.dts
@@ -0,0 +1,83 @@
+/*
+ * Cavium Thunder DTS file - Thunder board description
+ *
+ * Copyright (C) 2014, Cavium Inc.
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ * a) This library is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of the
+ * License, or (at your option) any later version.
+ *
+ * This library is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public
+ * License along with this library; if not, write to the Free
+ * Software Foundation, Inc., 51 Franklin St, Fifth Floor, Boston,
+ * MA 02110-1301 USA
+ *
+ * Or, alternatively,
+ *
+ * b) Permission is hereby granted, free of charge, to any person
+ * obtaining a copy of this software and associated documentation
+ * files (the "Software"), to deal in the Software without
+ * restriction, including without limitation the rights to use,
+ * copy, modify, merge, publish, distribute, sublicense, and/or
+ * sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following
+ * conditions:
+ *
+ * The above copyright notice and this permission notice shall be
+ * included in all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
+ * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ * OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+/dts-v1/;
+
+/include/ "thunder-88xx-2n.dtsi"
+
+/ {
+ model = "Cavium ThunderX CN88XX board";
+ compatible = "cavium,thunder-88xx";
+
+ aliases {
+ serial0 = &uaa0;
+ serial1 = &uaa1;
+ };
+
+ memory@ {
+ device_type = "memory";
+ reg = <0x0 0x0140 0x3 0xFEC0>;
+ /* socket 0 */
+ numa-node-id = <0>;
+ };
+
+ memory@100 {
+ device_type = "memory";
+ reg = <0x100 0x0040 0x3 0xFFC0>;
+/* socket 1 */
+ numa-node-id = <1>;
+ };
+
+ distance-map {
+ compatible = "numa-distance-map-v1";
+ distance-matrix = <0 0 10>,
+ <0 1 20>,
+ <1 1 10>;
+ };
+};
diff --git a/arch/arm64/boot/dts/cavium/thunder-88xx-2n.dtsi
b/arch/arm64/boot/dts/cavium/thunder-88xx-2n.dtsi
new file mode 100644
index 000..b58e5c7
--- /dev/null
+++ b/arch/arm64/boot/dts/cavium/thunder-88xx-2n.dtsi
@@ -0,0 +1,806 @@
+/*
+ * Cavium Thunder DTS file - Thunder SoC description
+ *
+ * Copyright (C) 2014, Cavium Inc.
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ * a) This library is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Genera
[RFC PATCH v9 6/6] topology, cleanup: Avoid redefinition of cpumask_of_pcibus in asm header files.
At present cpumask_of_pcibus is defined for !CONFIG_NUMA and moving out
to common will allow to use for numa too. This also avoids
redefinition of this macro in respective architecture header files.
Signed-off-by: Ganapatrao Kulkarni
---
arch/arm64/include/asm/topology.h | 3 ---
arch/ia64/include/asm/topology.h| 4
arch/metag/include/asm/topology.h | 3 ---
arch/powerpc/include/asm/topology.h | 4
arch/s390/include/asm/pci.h | 2 +-
arch/s390/include/asm/topology.h| 1 +
arch/sh/include/asm/topology.h | 3 ---
arch/x86/include/asm/pci.h | 2 +-
arch/x86/include/asm/topology.h | 1 +
include/asm-generic/topology.h | 4 ++--
10 files changed, 6 insertions(+), 21 deletions(-)
diff --git a/arch/arm64/include/asm/topology.h
b/arch/arm64/include/asm/topology.h
index 8b57339..6e1f62c 100644
--- a/arch/arm64/include/asm/topology.h
+++ b/arch/arm64/include/asm/topology.h
@@ -26,9 +26,6 @@ const struct cpumask *cpu_coregroup_mask(int cpu);
struct pci_bus;
int pcibus_to_node(struct pci_bus *bus);
-#define cpumask_of_pcibus(bus) (pcibus_to_node(bus) == -1 ?\
-cpu_all_mask : \
-cpumask_of_node(pcibus_to_node(bus)))
#endif /* CONFIG_NUMA */
diff --git a/arch/ia64/include/asm/topology.h b/arch/ia64/include/asm/topology.h
index 3ad8f69..2778eb6 100644
--- a/arch/ia64/include/asm/topology.h
+++ b/arch/ia64/include/asm/topology.h
@@ -58,10 +58,6 @@ void build_cpu_to_node_map(void);
extern void arch_fix_phys_package_id(int num, u32 slot);
-#define cpumask_of_pcibus(bus) (pcibus_to_node(bus) == -1 ?\
-cpu_all_mask : \
-cpumask_of_node(pcibus_to_node(bus)))
-
#include
#endif /* _ASM_IA64_TOPOLOGY_H */
diff --git a/arch/metag/include/asm/topology.h
b/arch/metag/include/asm/topology.h
index e95f874..b285196 100644
--- a/arch/metag/include/asm/topology.h
+++ b/arch/metag/include/asm/topology.h
@@ -9,9 +9,6 @@
#define cpumask_of_node(node) ((void)node, cpu_online_mask)
#define pcibus_to_node(bus)((void)(bus), -1)
-#define cpumask_of_pcibus(bus) (pcibus_to_node(bus) == -1 ? \
- cpu_all_mask : \
- cpumask_of_node(pcibus_to_node(bus)))
#endif
diff --git a/arch/powerpc/include/asm/topology.h
b/arch/powerpc/include/asm/topology.h
index 8b3b46b..eee025d 100644
--- a/arch/powerpc/include/asm/topology.h
+++ b/arch/powerpc/include/asm/topology.h
@@ -32,10 +32,6 @@ static inline int pcibus_to_node(struct pci_bus *bus)
}
#endif
-#define cpumask_of_pcibus(bus) (pcibus_to_node(bus) == -1 ?\
-cpu_all_mask : \
-cpumask_of_node(pcibus_to_node(bus)))
-
extern int __node_distance(int, int);
#define node_distance(a, b) __node_distance(a, b)
diff --git a/arch/s390/include/asm/pci.h b/arch/s390/include/asm/pci.h
index c873e68..539fb2d 100644
--- a/arch/s390/include/asm/pci.h
+++ b/arch/s390/include/asm/pci.h
@@ -205,7 +205,7 @@ static inline int __pcibus_to_node(const struct pci_bus
*bus)
}
static inline const struct cpumask *
-cpumask_of_pcibus(const struct pci_bus *bus)
+__cpumask_of_pcibus(const struct pci_bus *bus)
{
return cpu_online_mask;
}
diff --git a/arch/s390/include/asm/topology.h b/arch/s390/include/asm/topology.h
index 94fc55f..280eafc 100644
--- a/arch/s390/include/asm/topology.h
+++ b/arch/s390/include/asm/topology.h
@@ -78,6 +78,7 @@ static inline const struct cpumask *cpumask_of_node(int node)
#define parent_node(node) (node)
#define pcibus_to_node(bus) __pcibus_to_node(bus)
+#define cpumask_of_pcibus(bus) __cpumask_of_pcibus(bus)
#define node_distance(a, b) __node_distance(a, b)
diff --git a/arch/sh/include/asm/topology.h b/arch/sh/include/asm/topology.h
index b0a282d..357983d 100644
--- a/arch/sh/include/asm/topology.h
+++ b/arch/sh/include/asm/topology.h
@@ -9,9 +9,6 @@
#define cpumask_of_node(node) ((void)node, cpu_online_mask)
#define pcibus_to_node(bus)((void)(bus), -1)
-#define cpumask_of_pcibus(bus) (pcibus_to_node(bus) == -1 ? \
- cpu_all_mask : \
- cpumask_of_node(pcibus_to_node(bus)))
#endif
diff --git a/arch/x86/include/asm/pci.h b/arch/x86/include/asm/pci.h
index 4625943..4a6f358 100644
--- a/arch/x86/include/asm/pci.h
+++ b/arch/x86/include/asm/pci.h
@@ -121,7 +121,7 @@ static inline int __pcibus_to_node(const struct pci_bus
*bus)
}
static inline const struct cpumask *
-cpumask_of_pcibus(const struct pci_bus *bus)
+__cpumask_of_pcibus(const struct pci_bus *bus)
{
int node;
diff --git a/arch/x86/include/asm/topology.h b/arch/x86/include/asm/topology.h
index 0fb4648..980f6ee 100644
--- a/arch/x86/include/asm/topology.h
+++ b/a
[PATCH v9 5/6] PCI: generic: Make pci-host-generic driver numa aware
update numa_node of device associated with pci bus.
moved down devm_kzalloc to allocate from node memory.
Signed-off-by: Ganapatrao Kulkarni
---
drivers/pci/host/pci-host-generic.c | 9 ++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/drivers/pci/host/pci-host-generic.c
b/drivers/pci/host/pci-host-generic.c
index 5434c90..0e1ce06 100644
--- a/drivers/pci/host/pci-host-generic.c
+++ b/drivers/pci/host/pci-host-generic.c
@@ -215,11 +215,9 @@ static int gen_pci_probe(struct platform_device *pdev)
const struct of_device_id *of_id;
struct device *dev = &pdev->dev;
struct device_node *np = dev->of_node;
- struct gen_pci *pci = devm_kzalloc(dev, sizeof(*pci), GFP_KERNEL);
+ struct gen_pci *pci;
struct pci_bus *bus, *child;
- if (!pci)
- return -ENOMEM;
type = of_get_property(np, "device_type", NULL);
if (!type || strcmp(type, "pci")) {
@@ -230,6 +228,11 @@ static int gen_pci_probe(struct platform_device *pdev)
of_pci_check_probe_only();
of_id = of_match_node(gen_pci_of_match, np);
+ set_dev_node(dev, of_node_to_nid(np));
+ pci = devm_kzalloc(dev, sizeof(*pci), GFP_KERNEL);
+ if (!pci)
+ return -ENOMEM;
+
pci->cfg.ops = (struct gen_pci_cfg_bus_ops *)of_id->data;
pci->host.dev.parent = dev;
INIT_LIST_HEAD(&pci->host.windows);
--
1.8.1.4
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 3/3] ASoC: fsl_ssi: remove register defaults
Hi Fabio, On 18.01.2016 13:51, Fabio Estevam wrote: > Hi Maciej, > > On Sun, Jan 17, 2016 at 8:02 PM, Maciej S. Szmigiero > wrote: > >> Patch updated according to Timur's suggestions (needs regmap fix): >> diff --git a/sound/soc/fsl/fsl_ssi.c b/sound/soc/fsl/fsl_ssi.c > > Tested your patch against linux-next and it did not give me any warnings: > > Tested-by: Fabio Estevam Thanks for testing, I have submitted this version now. Maciej ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] ASoC: fsl_ssi: remove explicit register defaults
There is no guarantee that on fsl_ssi module load
SSI registers will have their power-on-reset values.
In fact, if the driver is reloaded the values in
registers will be whatever they were set to previously.
However, the cache needs to be fully populated at probe
time to avoid non-atomic allocations during register
access.
Special case here is imx21-class SSI, since
according to datasheet it don't have SACC{ST,EN,DIS}
regs.
This fixes hard lockup on fsl_ssi module reload,
at least in AC'97 mode.
Fixes: 05cf237972fe ("ASoC: fsl_ssi: Add driver suspend and resume to support
MEGA Fast")
Signed-off-by: Maciej S. Szmigiero
---
sound/soc/fsl/fsl_ssi.c | 42 ++
1 file changed, 22 insertions(+), 20 deletions(-)
This replaces "ASoC: fsl_ssi: remove register defaults"
submission.
It may be good to delay merging this until commit
d51fe1f393a6 ("regmap: pass buffer size to regmap_raw_read() in
regcache_hw_init()")
reaches ASoC tree since without that regmap fix
fsl_ssi will report error at probe time.
diff --git a/sound/soc/fsl/fsl_ssi.c b/sound/soc/fsl/fsl_ssi.c
index 40dfd8a36484..ed8de1035cda 100644
--- a/sound/soc/fsl/fsl_ssi.c
+++ b/sound/soc/fsl/fsl_ssi.c
@@ -112,20 +112,6 @@ struct fsl_ssi_rxtx_reg_val {
struct fsl_ssi_reg_val tx;
};
-static const struct reg_default fsl_ssi_reg_defaults[] = {
- {CCSR_SSI_SCR, 0x},
- {CCSR_SSI_SIER,0x3003},
- {CCSR_SSI_STCR,0x0200},
- {CCSR_SSI_SRCR,0x0200},
- {CCSR_SSI_STCCR, 0x0004},
- {CCSR_SSI_SRCCR, 0x0004},
- {CCSR_SSI_SACNT, 0x},
- {CCSR_SSI_STMSK, 0x},
- {CCSR_SSI_SRMSK, 0x},
- {CCSR_SSI_SACCEN, 0x},
- {CCSR_SSI_SACCDIS, 0x},
-};
-
static bool fsl_ssi_readable_reg(struct device *dev, unsigned int reg)
{
switch (reg) {
@@ -190,8 +176,7 @@ static const struct regmap_config fsl_ssi_regconfig = {
.val_bits = 32,
.reg_stride = 4,
.val_format_endian = REGMAP_ENDIAN_NATIVE,
- .reg_defaults = fsl_ssi_reg_defaults,
- .num_reg_defaults = ARRAY_SIZE(fsl_ssi_reg_defaults),
+ .num_reg_defaults_raw = CCSR_SSI_SACCDIS / sizeof(uint32_t) + 1,
.readable_reg = fsl_ssi_readable_reg,
.volatile_reg = fsl_ssi_volatile_reg,
.precious_reg = fsl_ssi_precious_reg,
@@ -201,6 +186,7 @@ static const struct regmap_config fsl_ssi_regconfig = {
struct fsl_ssi_soc_data {
bool imx;
+ bool imx21regs; /* imx21-class SSI - no SACC{ST,EN,DIS} regs */
bool offline_config;
u32 sisr_write_mask;
};
@@ -303,6 +289,7 @@ static struct fsl_ssi_soc_data fsl_ssi_mpc8610 = {
static struct fsl_ssi_soc_data fsl_ssi_imx21 = {
.imx = true,
+ .imx21regs = true,
.offline_config = true,
.sisr_write_mask = 0,
};
@@ -586,8 +573,12 @@ static void fsl_ssi_setup_ac97(struct fsl_ssi_private
*ssi_private)
*/
regmap_write(regs, CCSR_SSI_SACNT,
CCSR_SSI_SACNT_AC97EN | CCSR_SSI_SACNT_FV);
- regmap_write(regs, CCSR_SSI_SACCDIS, 0xff);
- regmap_write(regs, CCSR_SSI_SACCEN, 0x300);
+
+ /* no SACC{ST,EN,DIS} regs on imx21-class SSI */
+ if (!ssi_private->soc->imx21regs) {
+ regmap_write(regs, CCSR_SSI_SACCDIS, 0xff);
+ regmap_write(regs, CCSR_SSI_SACCEN, 0x300);
+ }
/*
* Enable SSI, Transmit and Receive. AC97 has to communicate with the
@@ -1397,6 +1388,7 @@ static int fsl_ssi_probe(struct platform_device *pdev)
struct resource *res;
void __iomem *iomem;
char name[64];
+ struct regmap_config regconfig = fsl_ssi_regconfig;
of_id = of_match_device(fsl_ssi_ids, &pdev->dev);
if (!of_id || !of_id->data)
@@ -1444,15 +1436,25 @@ static int fsl_ssi_probe(struct platform_device *pdev)
return PTR_ERR(iomem);
ssi_private->ssi_phys = res->start;
+ if (ssi_private->soc->imx21regs) {
+ /*
+* According to datasheet imx21-class SSI
+* don't have SACC{ST,EN,DIS} regs.
+*/
+ regconfig.max_register = CCSR_SSI_SRMSK;
+ regconfig.num_reg_defaults_raw =
+ CCSR_SSI_SRMSK / sizeof(uint32_t) + 1;
+ }
+
ret = of_property_match_string(np, "clock-names", "ipg");
if (ret < 0) {
ssi_private->has_ipg_clk_name = false;
ssi_private->regs = devm_regmap_init_mmio(&pdev->dev, iomem,
- &fsl_ssi_regconfig);
+ ®config);
} else {
ssi_private->has_ipg_clk_name = true;
ssi_private->regs = devm_regmap_init_mmio_clk(&pdev->dev,
- "ipg", iomem, &fsl_ssi_regconfig);
+ "ipg", iomem, ®config);
}
if (IS_ERR(ssi_private->regs))
Re: [PATCH] ASoC: fsl_ssi: Set watermark and maxburst settings to eliminate DMA xruns on imx processors
Hi Caleb, [auto build test ERROR on asoc/for-next] [also build test ERROR on v4.4 next-20160118] [if your patch is applied to the wrong git tree, please drop us a note to help improving the system] url: https://github.com/0day-ci/linux/commits/Caleb-Crome/ASoC-fsl_ssi-Set-watermark-and-maxburst-settings-to-eliminate-DMA-xruns-on-imx-processors/20160119-024143 base: https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git for-next config: x86_64-randconfig-x019-01180513 (attached as .config) reproduce: # save the attached .config to linux build tree make ARCH=x86_64 All errors (new ones prefixed by >>): sound/soc/fsl/fsl_ssi.c: In function '_fsl_ssi_set_dai_fmt': >> sound/soc/fsl/fsl_ssi.c:1012:23: error: request for member 'fifo_watermark' >> in something not a structure or union wm = ssi_private->soc.fifo_watermark; ^ vim +/fifo_watermark +1012 sound/soc/fsl/fsl_ssi.c 1006 } 1007 1008 regmap_write(regs, CCSR_SSI_STCR, stcr); 1009 regmap_write(regs, CCSR_SSI_SRCR, srcr); 1010 regmap_write(regs, CCSR_SSI_SCR, scr); 1011 > 1012 wm = ssi_private->soc.fifo_watermark; 1013 1014 regmap_write(regs, CCSR_SSI_SFCSR, 1015 CCSR_SSI_SFCSR_TFWM0(wm) | CCSR_SSI_SFCSR_RFWM0(wm) | --- 0-DAY kernel test infrastructureOpen Source Technology Center https://lists.01.org/pipermail/kbuild-all Intel Corporation .config.gz Description: Binary data ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v9 4/6] arm64, dt, thunderx: Add initial dts for Cavium Thunderx in 2 node topology.
On 01/18/2016 08:36 AM, Ganapatrao Kulkarni wrote: Adding dt file for Cavium's Thunderx dual socket platform. Signed-off-by: Ganapatrao Kulkarni --- arch/arm64/boot/dts/cavium/Makefile | 2 +- arch/arm64/boot/dts/cavium/thunder-88xx-2n.dts | 83 +++ arch/arm64/boot/dts/cavium/thunder-88xx-2n.dtsi | 806 3 files changed, 890 insertions(+), 1 deletion(-) create mode 100644 arch/arm64/boot/dts/cavium/thunder-88xx-2n.dts create mode 100644 arch/arm64/boot/dts/cavium/thunder-88xx-2n.dtsi These files are useless, they don't contain device nodes for anything other than the UARTs. There is no existing system that has only UARTs and no other devices, so these files cannot be (and can never be) used anywhere. Since the boot firmware in all real, and emulated, systems is supplying correct DTBs, we should consider not merging these files, and removing the likewise useless thunder-88xx.dts thunder-88xx.dtsi David Daney [...] ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v9 5/6] PCI: generic: Make pci-host-generic driver numa aware
On 01/18/2016 08:36 AM, Ganapatrao Kulkarni wrote:
update numa_node of device associated with pci bus.
moved down devm_kzalloc to allocate from node memory.
Signed-off-by: Ganapatrao Kulkarni
---
drivers/pci/host/pci-host-generic.c | 9 ++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/drivers/pci/host/pci-host-generic.c
b/drivers/pci/host/pci-host-generic.c
index 5434c90..0e1ce06 100644
--- a/drivers/pci/host/pci-host-generic.c
+++ b/drivers/pci/host/pci-host-generic.c
@@ -215,11 +215,9 @@ static int gen_pci_probe(struct platform_device *pdev)
const struct of_device_id *of_id;
struct device *dev = &pdev->dev;
struct device_node *np = dev->of_node;
- struct gen_pci *pci = devm_kzalloc(dev, sizeof(*pci), GFP_KERNEL);
+ struct gen_pci *pci;
struct pci_bus *bus, *child;
- if (!pci)
- return -ENOMEM;
type = of_get_property(np, "device_type", NULL);
if (!type || strcmp(type, "pci")) {
@@ -230,6 +228,11 @@ static int gen_pci_probe(struct platform_device *pdev)
of_pci_check_probe_only();
of_id = of_match_node(gen_pci_of_match, np);
+ set_dev_node(dev, of_node_to_nid(np));
This shouldn't be done in individual platform_drivers, but instead in
the device probing code.
There is code that does this in drivers/of/platform.c and
drivers/of/device.c Is that not being called for the pci-host-gweneric
devices? If not, we should figure out why, and perhaps attempt to fix
it rather than doing it here.
+ pci = devm_kzalloc(dev, sizeof(*pci), GFP_KERNEL);
+ if (!pci)
+ return -ENOMEM;
+
pci->cfg.ops = (struct gen_pci_cfg_bus_ops *)of_id->data;
pci->host.dev.parent = dev;
INIT_LIST_HEAD(&pci->host.windows);
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [v3,11/41] mips: reuse asm-generic/barrier.h
On Mon, Jan 18, 2016 at 04:19:29PM +0800, Herbert Xu wrote: > Paul E. McKenney wrote: > > > > You could use SYNC_ACQUIRE() to implement read_barrier_depends() and > > smp_read_barrier_depends(), but SYNC_RMB probably does not suffice. > > The reason for this is that smp_read_barrier_depends() must order the > > pointer load against any subsequent read or write through a dereference > > of that pointer. For example: > > > >p = READ_ONCE(gp); > >smp_rmb(); > >r1 = p->a; /* ordered by smp_rmb(). */ > >p->b = 42; /* NOT ordered by smp_rmb(), BUG!!! */ > >r2 = x; /* ordered by smp_rmb(), but doesn't need to be. */ > > > > In contrast: > > > >p = READ_ONCE(gp); > >smp_read_barrier_depends(); > >r1 = p->a; /* ordered by smp_read_barrier_depends(). */ > >p->b = 42; /* ordered by smp_read_barrier_depends(). */ > >r2 = x; /* not ordered by smp_read_barrier_depends(), which is OK. */ > > > > Again, if your hardware maintains local ordering for address > > and data dependencies, you can have read_barrier_depends() and > > smp_read_barrier_depends() be no-ops like they are for most > > architectures. > > > > Does that help? > > This is crazy! smp_rmb started out being strictly stronger than > smp_read_barrier_depends, when did this stop being the case? Hello, Herbert! It is true that most Linux kernel code relies only on the read-read properties of dependencies, but the read-write properties are useful. Admittedly relatively rarely, but useful. The better comparison for smp_read_barrier_depends(), especially in its rcu_dereference*() form, is smp_load_acquire(). Thanx, Paul ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 1/3][v2] net: phy: introduce 1000BASE-KX and 10GBASE-KR
> [S.H] the fsl backplane, e.g. 10GBASE-KR, needs software to handle link > training, > It's to train link partner, and trained by link partner parallel. > > But if media type is not copper, e.g. optical module, we won't need this. So what we actually need to know is copper vs fibre? Andrew ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 3/3] ASoC: fsl_ssi: remove register defaults
Hi Maciej, On Sun, Jan 17, 2016 at 8:02 PM, Maciej S. Szmigiero wrote: > Patch updated according to Timur's suggestions (needs regmap fix): > diff --git a/sound/soc/fsl/fsl_ssi.c b/sound/soc/fsl/fsl_ssi.c Tested your patch against linux-next and it did not give me any warnings: Tested-by: Fabio Estevam ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] Fix: PowerNV crash with 4.4.0-rc8 at sched_init_numa
- Original Message -
> From: "Raghavendra K T"
> To: mi...@redhat.com, pet...@infradead.org, b...@kernel.crashing.org,
> pau...@samba.org, m...@ellerman.id.au,
> an...@samba.org, a...@linux-foundation.org
> Cc: jstan...@redhat.com, gk...@linux.vnet.ibm.com, "grant likely"
> ,
> nik...@linux.vnet.ibm.com, vdavy...@parallels.com, "raghavendra kt"
> ,
> linuxppc-dev@lists.ozlabs.org, linux-ker...@vger.kernel.org,
> linux...@kvack.org
> Sent: Friday, 15 January, 2016 8:01:23 PM
> Subject: [PATCH] Fix: PowerNV crash with 4.4.0-rc8 at sched_init_numa
>
> Commit c118baf80256 ("arch/powerpc/mm/numa.c: do not allocate bootmem
> memory for non existing nodes") avoided bootmem memory allocation for
> non existent nodes.
>
> When DEBUG_PER_CPU_MAPS enabled, powerNV system failed to boot because
> in sched_init_numa, cpumask_or operation was done on unallocated nodes.
> Fix that by making cpumask_or operation only on existing nodes.
>
> [ Tested with and w/o DEBUG_PER_CPU_MAPS on x86 and powerpc ]
>
> Reported-by: Jan Stancek
Tested-by: Jan Stancek
I also verified with my setup, that this made the crash go away.
Report mail thread for reference:
https://lists.ozlabs.org/pipermail/linuxppc-dev/2016-January/137691.html
Regards,
Jan
> Signed-off-by: Raghavendra K T
> ---
> kernel/sched/core.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/kernel/sched/core.c b/kernel/sched/core.c
> index 44253ad..474658b 100644
> --- a/kernel/sched/core.c
> +++ b/kernel/sched/core.c
> @@ -6840,7 +6840,7 @@ static void sched_init_numa(void)
>
> sched_domains_numa_masks[i][j] = mask;
>
> - for (k = 0; k < nr_node_ids; k++) {
> + for_each_node(k) {
> if (node_distance(j, k) >
> sched_domains_numa_distance[i])
> continue;
>
> --
> 1.7.11.7
>
>
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH 3/6] QE: Add uqe_serial document to bindings
On Fri, Jan 18, 2016 at 05:10 PM, Li Yang wrote: > -Original Message- > From: pku@gmail.com [mailto:pku@gmail.com] On Behalf Of Li Yang > Sent: Monday, January 18, 2016 5:10 PM > To: Qiang Zhao > Cc: devicet...@vger.kernel.org; lkml ; > linuxppc-dev ; priyanka.j...@freescale.com; > o...@buserror.net > Subject: Re: [PATCH 3/6] QE: Add uqe_serial document to bindings > > On Fri, Jan 8, 2016 at 10:18 AM, Zhao Qiang wrote: > > Add uqe_serial document to > > Documentation/devicetree/bindings/powerpc/fsl/cpm_qe/uqe_serial.txt > > As you have submitted patch to move QE code from arch/powerpc into > drivers/soc/fsl for the reuse of ARM and powerpc, you should also move the > binding documents out of the powerpc folder into a more common place and > add new bindings in the new location. Thank you for your recommendation. How about create a new directory named qe under "Documentation/devicetree/bindings/"? Or you have a better suggestion? Regards -Zhao Qiang ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [POWERPC] Add QUICC Engine (QE) infrastructure
On Wed, Jan 6, 2016 at 5:27 PM, Dan Carpenter wrote:
> Hello Li Yang,
>
> The patch 986585385131: "[POWERPC] Add QUICC Engine (QE)
> infrastructure" from Oct 3, 2006, leads to the following static
> checker warning:
>
> drivers/soc/fsl/qe/qe_ic.c:412 qe_ic_set_priority()
> error: buffer overflow 'qe_ic_info' 44 <= 127
>
> drivers/soc/fsl/qe/qe_ic.c
>401 /* Set Priority level within its group, from 1 to 8 */
>402 int qe_ic_set_priority(unsigned int virq, unsigned int priority)
>403 {
>404 struct qe_ic *qe_ic = qe_ic_from_irq(virq);
>405 unsigned int src = virq_to_hw(virq);
>406 u32 temp;
>407
>408 if (priority > 8 || priority == 0)
>409 return -EINVAL;
>410 if (src > 127)
>
> The 127 isn't right here, I'm not sure where that value comes from. It
> should be >= ARRAY_SIZE(qe_ic_info).
Hi Dan,
Thanks for pointing this out. 127 should be the theoretical up
boundary of QEIC. You are right that we should have a stricter check.
And maybe a more serious issue is that we didn't check the overflow at
the host_map() stage.
Regards,
Leo
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 3/6] QE: Add uqe_serial document to bindings
On Fri, Jan 8, 2016 at 10:18 AM, Zhao Qiang wrote: > Add uqe_serial document to > Documentation/devicetree/bindings/powerpc/fsl/cpm_qe/uqe_serial.txt As you have submitted patch to move QE code from arch/powerpc into drivers/soc/fsl for the reuse of ARM and powerpc, you should also move the binding documents out of the powerpc folder into a more common place and add new bindings in the new location. Regards, Leo ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH 1/3][v2] net: phy: introduce 1000BASE-KX and 10GBASE-KR
> -Original Message- > From: Sebastian Hesselbarth [mailto:sebastian.hesselba...@gmail.com] > Sent: Monday, January 18, 2016 4:06 PM > To: Shaohui Xie; Florian Fainelli; Andrew Lunn; shh@gmail.com > Cc: devicet...@vger.kernel.org; net...@vger.kernel.org; linuxppc- > d...@lists.ozlabs.org; da...@davemloft.net; Shaohui Xie > Subject: Re: [PATCH 1/3][v2] net: phy: introduce 1000BASE-KX and 10GBASE-KR > > On 18.01.2016 08:23, Shaohui Xie wrote: > >>> If you look at the list of possible values for "phy-mode" you'd see > >>> that none of it describes a PHY-to-PHY connection but all are for > >>> MAC-to-PHY connections. Also, names above suggest it already: MII is > >>> short for media _independent_ interface. > >>> > >>> I copy Andrew's concerns and think that neither 1base-kx nor > >>> 10gbase-kr belong in the list of phy-mode properties. > >> > >> I concur with that as well, if the phy connection does not really > >> matter here, or does not seem like a good fit, maybe we should have a > >> different property, or just define the hardware interface a little > differently? > > Right, 'phy-mode' is not a good fit for backplanes, how about a new > > property like 'backplane-mode' or something, like below: > > Hmm. We already have a speed property for that you can use for 1000, 1, > 4. Leaves the media-type, e.g. copper or whatever. [S.H] You mean the property 'max-speed'? the problem is the media-type matters. Please see below. > > Currently, you fail to convince me that it is required to describe the media > type at all. We have come a long way with different media without describing > the > PHY-to-PHY media type. > > What makes the backplane setup so special? [S.H] the fsl backplane, e.g. 10GBASE-KR, needs software to handle link training, It's to train link partner, and trained by link partner parallel. But if media type is not copper, e.g. optical module, we won't need this. Thank you! Shaohui ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH 1/3][v2] net: phy: introduce 1000BASE-KX and 10GBASE-KR
> > If you look at the list of possible values for "phy-mode" you'd see
> > that none of it describes a PHY-to-PHY connection but all are for
> > MAC-to-PHY connections. Also, names above suggest it already: MII is
> > short for media _independent_ interface.
> >
> > I copy Andrew's concerns and think that neither 1base-kx nor
> > 10gbase-kr belong in the list of phy-mode properties.
>
> I concur with that as well, if the phy connection does not really matter here,
> or does not seem like a good fit, maybe we should have a different property,
> or
> just define the hardware interface a little differently?
Right, 'phy-mode' is not a good fit for backplanes, how about a new property
like
'backplane-mode' or something, like below:
--- a/Documentation/devicetree/bindings/net/phy.txt
+++ b/Documentation/devicetree/bindings/net/phy.txt
@@ -33,6 +33,9 @@ Optional Properties:
- broken-turn-around: If set, indicates the PHY device does not correctly
release the turn around line low at the end of a MDIO transaction.
+- backplane-mode: string, operation mode of the backplane PHY;
+ must be "1000base-kx" for 1000BASE-KX, or "10gbase-kr" for 10GBASE-KR.
+
Example:
ethernet-phy@0 {
Thank you!
Shaohui
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [v3,11/41] mips: reuse asm-generic/barrier.h
Paul E. McKenney wrote: > > You could use SYNC_ACQUIRE() to implement read_barrier_depends() and > smp_read_barrier_depends(), but SYNC_RMB probably does not suffice. > The reason for this is that smp_read_barrier_depends() must order the > pointer load against any subsequent read or write through a dereference > of that pointer. For example: > >p = READ_ONCE(gp); >smp_rmb(); >r1 = p->a; /* ordered by smp_rmb(). */ >p->b = 42; /* NOT ordered by smp_rmb(), BUG!!! */ >r2 = x; /* ordered by smp_rmb(), but doesn't need to be. */ > > In contrast: > >p = READ_ONCE(gp); >smp_read_barrier_depends(); >r1 = p->a; /* ordered by smp_read_barrier_depends(). */ >p->b = 42; /* ordered by smp_read_barrier_depends(). */ >r2 = x; /* not ordered by smp_read_barrier_depends(), which is OK. */ > > Again, if your hardware maintains local ordering for address > and data dependencies, you can have read_barrier_depends() and > smp_read_barrier_depends() be no-ops like they are for most > architectures. > > Does that help? This is crazy! smp_rmb started out being strictly stronger than smp_read_barrier_depends, when did this stop being the case? -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 1/3][v2] net: phy: introduce 1000BASE-KX and 10GBASE-KR
On 18.01.2016 08:23, Shaohui Xie wrote:
If you look at the list of possible values for "phy-mode" you'd see
that none of it describes a PHY-to-PHY connection but all are for
MAC-to-PHY connections. Also, names above suggest it already: MII is
short for media _independent_ interface.
I copy Andrew's concerns and think that neither 1base-kx nor
10gbase-kr belong in the list of phy-mode properties.
I concur with that as well, if the phy connection does not really matter here,
or does not seem like a good fit, maybe we should have a different property, or
just define the hardware interface a little differently?
Right, 'phy-mode' is not a good fit for backplanes, how about a new property
like
'backplane-mode' or something, like below:
Hmm. We already have a speed property for that you can use for
1000, 1, 4. Leaves the media-type, e.g. copper or whatever.
Currently, you fail to convince me that it is required to describe
the media type at all. We have come a long way with different media
without describing the PHY-to-PHY media type.
What makes the backplane setup so special?
Sebastian
--- a/Documentation/devicetree/bindings/net/phy.txt
+++ b/Documentation/devicetree/bindings/net/phy.txt
@@ -33,6 +33,9 @@ Optional Properties:
- broken-turn-around: If set, indicates the PHY device does not correctly
release the turn around line low at the end of a MDIO transaction.
+- backplane-mode: string, operation mode of the backplane PHY;
+ must be "1000base-kx" for 1000BASE-KX, or "10gbase-kr" for 10GBASE-KR.
+
Example:
ethernet-phy@0 {
Thank you!
Shaohui
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
