Re: PHY/FEC Network adapter failed to initialize on MPC52xx Board
On 11/27/2010 06:31 AM, Peter wrote: Hi all I got completely stuck with a network adapter problem on my ppc board (MPC52xx style). The ntwork adapter does not seem to intialize correctly when booted without 'help from uboot' The adapter works properly when I first use it with uboot. E.g. using tftp to load the kernel or just issuing a dummy sntp command. It does not get intialized if I boot linux without using any network relevant command in ubboot The difference manifests on the boot message: (working) PHY working ... mpc52xx MII bus: probed TCP cubic registered NET: Registered protocol family 17 IP-Config: Complete: device=eth0, addr=192.168.1.245, mask=255.254.0.0, gw=192.168.1.2, host=192.168.1.245, domain=, nis-domain=(none), bootserver=192.168.1.244, rootserver=192.168.1.244, rootpath= Looking up port of RPC 13/2 on 192.168.1.244 Looking up port of RPC 15/1 on 192.168.1.244 VFS: Mounted root (nfs filesystem) on device 0:11. Freeing unused kernel memory: 124k init PHY: f0003000:00 - Link is Up - 100/Full # ping 192.168.1.2 returns proper results. PHY Not working: ... mpc52xx MII bus: probed TCP cubic registered NET: Registered protocol family 17 IP-Config: Complete: device=eth0, addr=192.168.1.245, mask=255.254.0.0, gw=192.168.1.2, host=192.168.1.245, domain=, nis-domain=(none), bootserver=192.168.1.244, rootserver=192.168.1.244, rootpath= VFS: Mounted root (squashfs filesystem) readonly on device 31:3. Freeing unused kernel memory: 124k init # ping 192.168.1.2 hangs The second snipped does not have "Looking up.." messages because it boots from flash. Main difference is "PHY: f0003000:00 - Link is Up - 100/Full" which does not appear at the failing case. Linux Version is 2.6.35.7 patched with xenomai 2.5 U-Boot 2010.06 (Aug 05 2010 - 19:54:45) Linux configuration see below: ( i left most entries out that are not set) I also experimented with different settings but finally only CONFIG_FEC_MPC52xx=y and CONFIG_FEC_MPC52xx_MDIO=y seem to be of any relevance. If both are set, the adapter works when initialized by uboot. Any help or tips will be very much appreciated, There are a couple of possibilities: * Many PHY devices will have an external RESET or enable pin which is driven by GPIO. The board support package in U-Boot for your board would then enable the PHY device as part of network initialization. The Linux kernel typically does not fiddle with such things. * The actual PHY device may need some setup (adjustment of internal PHY registers) before it will come on-line, e.g. the device may not be strapped to auto-negotiate on the wire to find a link. U-Boot might be turning this on, or even forcing the link up (I've seen such devices that needed this level of hand-holding). Again, the Linux network driver typically will not be doing these sort of operations. To figure out what's going on and what else you might need, you should look at both the U-Boot code for your board and the board documentation (schematics, etc). Then you should be able to see what U-Boot does that the Linux kernel is not. In the end, you may need to add some code in your target platform support in Linux to add the additional stuff to make the PHY work. Linux .config ... # # Platform support # # CONFIG_PPC_CHRP is not set # CONFIG_MPC5121_ADS is not set # CONFIG_MPC5121_GENERIC is not set CONFIG_PPC_MPC52xx=y CONFIG_PPC_MPC5200_SIMPLE=y # CONFIG_PPC_EFIKA is not set CONFIG_PPC_LITE5200=y # CONFIG_PPC_MEDIA5200 is not set CONFIG_PPC_MPC5200_BUGFIX=y # CONFIG_PPC_MPC5200_GPIO is not set CONFIG_PPC_MPC5200_LPBFIFO=y CONFIG_PPC_BESTCOMM=y CONFIG_PPC_BESTCOMM_FEC=y CONFIG_PPC_BESTCOMM_GEN_BD=y # CONFIG_SIMPLE_GPIO is not set .. # Bus options # CONFIG_ZONE_DMA=y CONFIG_NEED_SG_DMA_LENGTH=y CONFIG_GENERIC_ISA_DMA=y CONFIG_PPC_PCI_CHOICE=y ... # # Generic Driver Options # CONFIG_STANDALONE=y CONFIG_PREVENT_FIRMWARE_BUILD=y CONFIG_MTD=y CONFIG_MTD_PARTITIONS=y CONFIG_MTD_CMDLINE_PARTS=y # # MII PHY device drivers # CONFIG_LXT_PHY=y## Does not seem to have any influence CONFIG_NET_ETHERNET=y CONFIG_MII=y CONFIG_ETHOC=y ## Does not seem to have any influence CONFIG_FEC_MPC52xx=y ## Must be Y in roder to get adapter working with uboot's init CONFIG_FEC_MPC52xx_MDIO=y ## Must be Y in roder to get adapter working with uboot's init ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev -- Gary Thomas | Consulting for the MLB Associates |Embedded world ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] powerpc: update compat_arch_ptrace
Update compat_arch_ptrace to follow recent changes in
PTRACE_GET_DEBUGREG and the addition of
PPC_PTRACE_{GETHWDBGINFO|{SET|DEL}HWDEBUG}. The latter three can be
forwarded to arch_ptrace unchanged.
Signed-off-by: Andreas Schwab
---
arch/powerpc/kernel/ptrace32.c |7 +++
1 files changed, 7 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/kernel/ptrace32.c b/arch/powerpc/kernel/ptrace32.c
index 8a6daf4..69c4be9 100644
--- a/arch/powerpc/kernel/ptrace32.c
+++ b/arch/powerpc/kernel/ptrace32.c
@@ -280,7 +280,11 @@ long compat_arch_ptrace(struct task_struct *child,
compat_long_t request,
/* We only support one DABR and no IABRS at the moment */
if (addr > 0)
break;
+#ifdef CONFIG_PPC_ADV_DEBUG_REGS
+ ret = put_user(child->thread.dac1, (u32 __user *)data);
+#else
ret = put_user(child->thread.dabr, (u32 __user *)data);
+#endif
break;
}
@@ -312,6 +316,9 @@ long compat_arch_ptrace(struct task_struct *child,
compat_long_t request,
case PTRACE_SET_DEBUGREG:
case PTRACE_SYSCALL:
case PTRACE_CONT:
+ case PPC_PTRACE_GETHWDBGINFO:
+ case PPC_PTRACE_SETHWDEBUG:
+ case PPC_PTRACE_DELHWDEBUG:
ret = arch_ptrace(child, request, addr, data);
break;
--
1.7.3.2
--
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] ucc_geth: fix ucc halt problem in half duplex mode
From: Li Yang Date: Fri, 26 Nov 2010 17:29:58 +0800 > In commit 58933c64(ucc_geth: Fix the wrong the Rx/Tx FIFO size), > the UCC_GETH_UTFTT_INIT is set to 512 based on the recommendation > of the QE Reference Manual. But that will sometimes cause tx halt > while working in half duplex mode. > > According to errata draft QE_GENERAL-A003(High Tx Virtual FIFO > threshold size can cause UCC to halt), setting UTFTT less than > [(UTFS x (M - 8)/M) - 128] will prevent this from happening > (M is the minimum buffer size). > > The patch changes UTFTT back to 256. > > Signed-off-by: Li Yang > Cc: Jean-Denis Boyer > Cc: Andreas Schmitz > Cc: Anton Vorontsov Applied, thank you. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 3/5] fpga: add basic CARMA board support
On Wed, 2010-09-08 at 09:41 -0700, Ira W. Snyder wrote:
> This adds basic support for the system controller FPGA on the OVRO CARMA
> board. This patch only adds infrastructure that will be used by later
> drivers.
One comment I have is do you really need to create a class ? Do you
provide a specific API/interface that would make it useful ?
Cheers,
Ben.
> Signed-off-by: Ira W. Snyder
> ---
> drivers/Kconfig |2 +
> drivers/Makefile|1 +
> drivers/fpga/Kconfig|1 +
> drivers/fpga/Makefile |1 +
> drivers/fpga/carma/Kconfig | 21
> drivers/fpga/carma/Makefile |1 +
> drivers/fpga/carma/carma.c | 73
> +++
> drivers/fpga/carma/carma.h | 22 +
> 8 files changed, 122 insertions(+), 0 deletions(-)
> create mode 100644 drivers/fpga/Kconfig
> create mode 100644 drivers/fpga/Makefile
> create mode 100644 drivers/fpga/carma/Kconfig
> create mode 100644 drivers/fpga/carma/Makefile
> create mode 100644 drivers/fpga/carma/carma.c
> create mode 100644 drivers/fpga/carma/carma.h
>
> diff --git a/drivers/Kconfig b/drivers/Kconfig
> index a2b902f..8945ae6 100644
> --- a/drivers/Kconfig
> +++ b/drivers/Kconfig
> @@ -111,4 +111,6 @@ source "drivers/xen/Kconfig"
> source "drivers/staging/Kconfig"
>
> source "drivers/platform/Kconfig"
> +
> +source "drivers/fpga/Kconfig"
> endmenu
> diff --git a/drivers/Makefile b/drivers/Makefile
> index ae47344..c0b05de 100644
> --- a/drivers/Makefile
> +++ b/drivers/Makefile
> @@ -115,3 +115,4 @@ obj-$(CONFIG_VLYNQ) += vlynq/
> obj-$(CONFIG_STAGING)+= staging/
> obj-y+= platform/
> obj-y+= ieee802154/
> +obj-$(CONFIG_FPGA_DRIVERS) += fpga/
> diff --git a/drivers/fpga/Kconfig b/drivers/fpga/Kconfig
> new file mode 100644
> index 000..c85c2cc
> --- /dev/null
> +++ b/drivers/fpga/Kconfig
> @@ -0,0 +1 @@
> +source "drivers/fpga/carma/Kconfig"
> diff --git a/drivers/fpga/Makefile b/drivers/fpga/Makefile
> new file mode 100644
> index 000..409a5f9
> --- /dev/null
> +++ b/drivers/fpga/Makefile
> @@ -0,0 +1 @@
> +obj-y+= carma/
> diff --git a/drivers/fpga/carma/Kconfig b/drivers/fpga/carma/Kconfig
> new file mode 100644
> index 000..448885e
> --- /dev/null
> +++ b/drivers/fpga/carma/Kconfig
> @@ -0,0 +1,21 @@
> +
> +menuconfig FPGA_DRIVERS
> + bool "FPGA Drivers"
> + default n
> + help
> + Say Y here to see options for devices used with custom FPGAs.
> + This option alone does not add any kernel code.
> +
> + If you say N, all options in this submenu will be skipped and
> disabled.
> +
> +if FPGA_DRIVERS
> +
> +config CARMA
> + tristate "CARMA System Controller FPGA support"
> + depends on FSL_SOC && PPC_83xx
> + default n
> + help
> + Say Y here to include basic support for the CARMA System Controller
> + FPGA. This option allows the other more advanced drivers to be built.
> +
> +endif # FPGA_DRIVERS
> diff --git a/drivers/fpga/carma/Makefile b/drivers/fpga/carma/Makefile
> new file mode 100644
> index 000..90d0594
> --- /dev/null
> +++ b/drivers/fpga/carma/Makefile
> @@ -0,0 +1 @@
> +obj-$(CONFIG_CARMA) += carma.o
> diff --git a/drivers/fpga/carma/carma.c b/drivers/fpga/carma/carma.c
> new file mode 100644
> index 000..97549d2
> --- /dev/null
> +++ b/drivers/fpga/carma/carma.c
> @@ -0,0 +1,73 @@
> +/*
> + * CARMA Board Utility Driver
> + *
> + * Copyright (c) 2009-2010 Ira W. Snyder
> + *
> + * This program 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.
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#include "carma.h"
> +
> +static struct class *carma_class;
> +static const char drv_name[] = "carma";
> +
> +/*
> + * CARMA Device Class Functions
> + */
> +
> +struct device *carma_device_create(struct device *parent, dev_t devno,
> +const char *fmt, ...)
> +{
> + struct device *dev;
> + va_list vargs;
> +
> + va_start(vargs, fmt);
> + dev = device_create_vargs(carma_class, parent, devno, NULL, fmt, vargs);
> + va_end(vargs);
> +
> + return dev;
> +}
> +EXPORT_SYMBOL_GPL(carma_device_create);
> +
> +void carma_device_destroy(dev_t devno)
> +{
> + device_destroy(carma_class, devno);
> +}
> +EXPORT_SYMBOL_GPL(carma_device_destroy);
> +
> +/*
> + * Module Init / Exit
> + */
> +
> +static int __init carma_init(void)
> +{
> + /* Register the CARMA device class */
> + carma_class = class_create(THIS_MODULE, "carma");
> + if (IS_ERR(carma_class)) {
> + pr_err("%s: unable to create CARMA class\n", drv_name);
> + return PTR_ERR(
Re: [PATCH 3/5] fpga: add basic CARMA board support
On Wed, 2010-09-08 at 09:41 -0700, Ira W. Snyder wrote: > This adds basic support for the system controller FPGA on the OVRO CARMA > board. This patch only adds infrastructure that will be used by later > drivers. Oh and another comment ... I'm not sure about drivers/fpga ... in the end, one would expect such a directory to contain stuff to manipulate FPGAs in the sense of downloading bitfiles, instanciating devices (device-tree manipulation ?) etc... >From what I see in your code, the fact that these are FPGAs is almost irrelevant, you are providing support for "carma" devices, and such are no different than some other platform device, they just happen to be implemented as FPGAs. Or am I missing something ? Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [RFC PATCH 3/7 v2] ppc: do not search for dma-window property on dlpar remove
On Tue, 2010-10-26 at 20:35 -0700, Nishanth Aravamudan wrote:
> The iommu_table pointer in the pci auxiliary struct of device_node has
> not been used by the iommu ops since the dma refactor of
> 12d04eef927bf61328af2c7cbe756c96f98ac3bf, however this code still uses
> it to find tables for dlpar. By only setting the PCI_DN iommu_table
> pointer on nodes with dma window properties, we will be able to quickly
> find the node for later checks, and can remove the table without looking
> for the the dma window property on dlpar remove.
The answer might well be yes but are we sure this works with busses &
devices that don't have a dma,window ? ie. we always properly look for
parents when assigning pci devices arch_data iommu table ? Did you test
it ? :-) (Best way is to find a card with a P2P bridge on it).
Cheers,
Ben.
> Signed-off-by: Milton Miller
> Signed-off-by: Nishanth Aravamudan
> ---
> arch/powerpc/platforms/pseries/iommu.c |6 +-
> 1 files changed, 1 insertions(+), 5 deletions(-)
>
> diff --git a/arch/powerpc/platforms/pseries/iommu.c
> b/arch/powerpc/platforms/pseries/iommu.c
> index 9184db3..8ab32da 100644
> --- a/arch/powerpc/platforms/pseries/iommu.c
> +++ b/arch/powerpc/platforms/pseries/iommu.c
> @@ -455,9 +455,6 @@ static void pci_dma_bus_setup_pSeriesLP(struct pci_bus
> *bus)
> ppci->iommu_table = iommu_init_table(tbl, ppci->phb->node);
> pr_debug(" created table: %p\n", ppci->iommu_table);
> }
> -
> - if (pdn != dn)
> - PCI_DN(dn)->iommu_table = ppci->iommu_table;
> }
>
> @@ -571,8 +568,7 @@ static int iommu_reconfig_notifier(struct notifier_block
> *nb, unsigned long acti
>
> switch (action) {
> case PSERIES_RECONFIG_REMOVE:
> - if (pci && pci->iommu_table &&
> - of_get_property(np, "ibm,dma-window", NULL))
> + if (pci && pci->iommu_table)
> iommu_free_table(pci->iommu_table, np->full_name);
> break;
> default:
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: PHY/FEC Network adapter failed to initialize on MPC52xx Board
Peter wrote: > Hi all > > I got completely stuck with a network adapter problem on my > ppc board (MPC52xx style). The ntwork adapter does not seem > to intialize correctly when booted without 'help from uboot' > Looks your problem is very similar to one I replied here not long ago :) That is also issued from MPC5200. And I remember there was a wrong Port Multiplex Configuration. If possible maybe you can check the email subjected "Problem Ethernet Initialization MPC5200 + LXT971A" on linuxppc-dev list. Hope its useful. Tiejun > The adapter works properly when I first use it with uboot. E.g. > using tftp to load the kernel or just issuing a dummy sntp > command. It does not get intialized if I boot linux without > using any network relevant command in ubboot > > The difference manifests on the boot message: (working) > PHY working > ... > mpc52xx MII bus: probed > TCP cubic registered > NET: Registered protocol family 17 > IP-Config: Complete: > device=eth0, addr=192.168.1.245, mask=255.254.0.0, gw=192.168.1.2, > host=192.168.1.245, domain=, nis-domain=(none), > bootserver=192.168.1.244, rootserver=192.168.1.244, rootpath= > Looking up port of RPC 13/2 on 192.168.1.244 > Looking up port of RPC 15/1 on 192.168.1.244 > VFS: Mounted root (nfs filesystem) on device 0:11. > Freeing unused kernel memory: 124k init > PHY: f0003000:00 - Link is Up - 100/Full > > # ping 192.168.1.2 returns proper results. > > PHY Not working: > ... > mpc52xx MII bus: probed > TCP cubic registered > NET: Registered protocol family 17 > IP-Config: Complete: > device=eth0, addr=192.168.1.245, mask=255.254.0.0, gw=192.168.1.2, > host=192.168.1.245, domain=, nis-domain=(none), > bootserver=192.168.1.244, rootserver=192.168.1.244, rootpath= > VFS: Mounted root (squashfs filesystem) readonly on device 31:3. > Freeing unused kernel memory: 124k init > > # ping 192.168.1.2 hangs > > > The second snipped does not have "Looking up.." messages because it > boots from flash. Main difference is "PHY: f0003000:00 - Link is Up - > 100/Full" > which does not appear at the failing case. > > Linux Version is 2.6.35.7 patched with xenomai 2.5 > U-Boot 2010.06 (Aug 05 2010 - 19:54:45) > > Linux configuration see below: ( i left most entries out that are not set) > I also experimented with different settings but finally only > CONFIG_FEC_MPC52xx=y and CONFIG_FEC_MPC52xx_MDIO=y > seem to be of any relevance. If both are set, the adapter works > when initialized by uboot. > > Any help or tips will be very much appreciated, > > Regards, Peter > > > Linux .config > > ... > # > # Platform support > # > # CONFIG_PPC_CHRP is not set > # CONFIG_MPC5121_ADS is not set > # CONFIG_MPC5121_GENERIC is not set > CONFIG_PPC_MPC52xx=y > CONFIG_PPC_MPC5200_SIMPLE=y > # CONFIG_PPC_EFIKA is not set > CONFIG_PPC_LITE5200=y > # CONFIG_PPC_MEDIA5200 is not set > CONFIG_PPC_MPC5200_BUGFIX=y > # CONFIG_PPC_MPC5200_GPIO is not set > CONFIG_PPC_MPC5200_LPBFIFO=y > > CONFIG_PPC_BESTCOMM=y > CONFIG_PPC_BESTCOMM_FEC=y > CONFIG_PPC_BESTCOMM_GEN_BD=y > # CONFIG_SIMPLE_GPIO is not set > .. > # Bus options > # > CONFIG_ZONE_DMA=y > CONFIG_NEED_SG_DMA_LENGTH=y > CONFIG_GENERIC_ISA_DMA=y > CONFIG_PPC_PCI_CHOICE=y > ... > # > # Generic Driver Options > # > CONFIG_STANDALONE=y > CONFIG_PREVENT_FIRMWARE_BUILD=y > CONFIG_MTD=y > CONFIG_MTD_PARTITIONS=y > CONFIG_MTD_CMDLINE_PARTS=y > > # > # MII PHY device drivers > # > CONFIG_LXT_PHY=y## Does not seem to have any influence > CONFIG_NET_ETHERNET=y > CONFIG_MII=y > CONFIG_ETHOC=y ## Does not seem to have any > influence > CONFIG_FEC_MPC52xx=y ## Must be Y in roder to get adapter > working with uboot's init > CONFIG_FEC_MPC52xx_MDIO=y ## Must be Y in roder to get adapter working with > uboot's init ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 14/15] ppc64 iommu: use coherent_dma_mask for alloc_coherent
On Wed, 2010-09-15 at 11:05 -0700, Nishanth Aravamudan wrote:
> The IOMMU code has been passing the dma-mask instead of the
> coherent_dma_mask to the iommu allocator. Coherent allocations should
> be made using the coherent_dma_mask.
Won't that break macio devices too ? afaik, they don't set
coherent_dma_mask. Have you tried booting on a G5 with iommu enabled ?
(It may not be broken, just asking...)
Cheers,
Ben.
> Signed-off-by: Milton Miller
> Signed-off-by: Nishanth Aravamudan
> ---
> We currently don't check the mask other than to warn when its being set,
> so I don't think this is stable material.
> ---
> arch/powerpc/kernel/dma-iommu.c |2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/arch/powerpc/kernel/dma-iommu.c b/arch/powerpc/kernel/dma-iommu.c
> index 6e54a0f..e755415 100644
> --- a/arch/powerpc/kernel/dma-iommu.c
> +++ b/arch/powerpc/kernel/dma-iommu.c
> @@ -19,7 +19,7 @@ static void *dma_iommu_alloc_coherent(struct device *dev,
> size_t size,
> dma_addr_t *dma_handle, gfp_t flag)
> {
> return iommu_alloc_coherent(dev, get_iommu_table_base(dev), size,
> - dma_handle, device_to_mask(dev), flag,
> + dma_handle, dev->coherent_dma_mask, flag,
> dev_to_node(dev));
> }
>
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 15/15] ppc/vio: ensure dma_coherent_mask is set
On Wed, 2010-09-15 at 11:05 -0700, Nishanth Aravamudan wrote:
> Without this change drivers, such as ibmvscsi, fail to load with the
> previous change.
> ---
So you broke bisection... fold the patch instead or invert them
Cheers,
Ben.
> arch/powerpc/kernel/vio.c |3 +++
> 1 files changed, 3 insertions(+), 0 deletions(-)
>
> diff --git a/arch/powerpc/kernel/vio.c b/arch/powerpc/kernel/vio.c
> index 3c3083f..e8d73de 100644
> --- a/arch/powerpc/kernel/vio.c
> +++ b/arch/powerpc/kernel/vio.c
> @@ -1259,6 +1259,9 @@ struct vio_dev *vio_register_device_node(struct
> device_node *of_node)
> viodev->dev.parent = &vio_bus_device.dev;
> viodev->dev.bus = &vio_bus_type;
> viodev->dev.release = vio_dev_release;
> +/* needed to ensure proper operation of coherent allocations
> + * later, in case driver doesn't set it explicitly */
> +dma_set_coherent_mask(&viodev->dev, DMA_BIT_MASK(64));
>
> /* register with generic device framework */
> if (device_register(&viodev->dev)) {
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH V2 2/3] powerpc: Poll VPA for topology changes and update NUMA maps
On Tue, 2010-11-09 at 16:25 -0700, Jesse Larrew wrote:
> From: Jesse Larrew
>
> This patch sets a timer during boot that will periodically poll the
> associativity change counters in the VPA. When a change in
> associativity is detected, it retrieves the new associativity domain
> information via the H_HOME_NODE_ASSOCIATIVITY hcall and updates the
> NUMA node maps and sysfs entries accordingly. Note that since the
> ibm,associativity device tree property does not exist on configurations
> with both NUMA and SPLPAR enabled, no device tree updates are necessary.
>
> Signed-off-by: Jesse Larrew
> ---
No fundamental objection, just quick nits before I merge:
> +
> +/* Vrtual Processor Home Node (VPHN) support */
> +#define VPHN_NR_CHANGE_CTRS (8)
> +static u8 vphn_cpu_change_counts[NR_CPUS][VPHN_NR_CHANGE_CTRS];
> +static cpumask_t cpu_associativity_changes_mask;
> +static void topology_work_fn(struct work_struct *work);
> +static DECLARE_WORK(topology_work, topology_work_fn);
Remove the prototype for topology_work_fn() and puts the DECLARE_WORK
right below the function itself.
> +static void topology_timer_fn(unsigned long ignored);
> +static struct timer_list topology_timer =
> + TIMER_INITIALIZER(topology_timer_fn, 0, 0);
Same deal.
> +static void set_topology_timer(void);
> +int stop_topology_update(void);
> +
> +/*
> + * Store the current values of the associativity change counters in the
> + * hypervisor.
> + */
> +static void setup_cpu_associativity_change_counters(void)
> +{
> + int cpu = 0;
> +
> + for_each_possible_cpu(cpu) {
> + int i = 0;
> + u8 *counts = vphn_cpu_change_counts[cpu];
> + volatile u8 *hypervisor_counts = lppaca[cpu].vphn_assoc_counts;
> +
> + for (i = 0; i < VPHN_NR_CHANGE_CTRS; i++) {
> + counts[i] = hypervisor_counts[i];
> + }
> + }
> +
> + return;
> +}
> +
> +/*
> + * The hypervisor maintains a set of 8 associativity change counters in
> + * the VPA of each cpu that correspond to the associativity levels in the
> + * ibm,associativity-reference-points property. When an associativity
> + * level changes, the corresponding counter is incremented.
> + *
> + * Set a bit in cpu_associativity_changes_mask for each cpu whose home
> + * node associativity levels have changed.
> + */
> +static void update_cpu_associativity_changes_mask(void)
> +{
> + int cpu = 0;
> + cpumask_t *changes = &cpu_associativity_changes_mask;
> +
> + cpumask_clear(changes);
> +
> + for_each_possible_cpu(cpu) {
> + int i;
> + u8 *counts = vphn_cpu_change_counts[cpu];
> + volatile u8 *hypervisor_counts = lppaca[cpu].vphn_assoc_counts;
> +
> + for (i = 0; i < VPHN_NR_CHANGE_CTRS; i++) {
> + if (hypervisor_counts[i] > counts[i]) {
> + counts[i] = hypervisor_counts[i];
> +
> + if (!(cpumask_test_cpu(cpu, changes)))
> + cpumask_set_cpu(cpu, changes);
> + }
> + }
This is a tad sub-optimal. I'd just set a local variable, and
after the inside loop set the cpumask bit when that variable is set.
Also, keep another variable that accumulate all bits set and return
its value so you don't have to re-check the mask in the caller.
cpumask operations can be expensive.
> + }
> +
> + return;
You don't need a return; at the end of a function.
> +}
> +
> +/* 6 64-bit registers unpacked into 12 32-bit associativity values */
> +#define VPHN_ASSOC_BUFSIZE (6*sizeof(u64)/sizeof(u32))
> +
> +/*
> + * Convert the associativity domain numbers returned from the hypervisor
> + * to the sequence they would appear in the ibm,associativity property.
> + */
> +static int vphn_unpack_associativity(const long *packed, unsigned int
> *unpacked)
> +{
> + int i = 0;
> + int nr_assoc_doms = 0;
> + const u16 *field = (const u16*) packed;
> +
> +#define VPHN_FIELD_UNUSED(0x)
> +#define VPHN_FIELD_MSB (0x8000)
> +#define VPHN_FIELD_MASK (~VPHN_FIELD_MSB)
> +
> + for (i = 0; i < VPHN_ASSOC_BUFSIZE; i++) {
> + if (*field == VPHN_FIELD_UNUSED) {
> + /* All significant fields processed, and remaining
> + * fields contain the reserved value of all 1's.
> + * Just store them.
> + */
> + unpacked[i] = *((u32*)field);
> + field += 2;
> + }
> + else if (*field & VPHN_FIELD_MSB) {
> + /* Data is in the lower 15 bits of this field */
> + unpacked[i] = *field & VPHN_FIELD_MASK;
> + field++;
> + nr_assoc_doms++;
> + }
> + else {
> + /* Data is in the lower 15 bits of this field
> + * co
Re: [PATCH 3/5] fpga: add basic CARMA board support
On Sun, Nov 28, 2010 at 4:38 PM, Benjamin Herrenschmidt < b...@kernel.crashing.org> wrote: > On Wed, 2010-09-08 at 09:41 -0700, Ira W. Snyder wrote: > > This adds basic support for the system controller FPGA on the OVRO CARMA > > board. This patch only adds infrastructure that will be used by later > > drivers. > > Oh and another comment ... > > I'm not sure about drivers/fpga ... in the end, one would expect such a > directory to contain stuff to manipulate FPGAs in the sense of > downloading bitfiles, instanciating devices (device-tree manipulation ?) > etc... > > From what I see in your code, the fact that these are FPGAs is almost > irrelevant, you are providing support for "carma" devices, and such are > no different than some other platform device, they just happen to be > implemented as FPGAs. Or am I missing something ? > > Cheers, > Ben. > > Generally, I agree with this: There doesn't seem to be anything generic about the FPGA support you are adding, it seems very specific to the CARMA hardware. I'm generally not opposed to drivers/fpga: I think that colocating drivers for things that are basically FPGA compute platforms isn't necessarily a bad idea, but I think it would be better if those devices were colocated because they shared some FPGA-oriented infrastructure, which this doesn't seem to do. Currently, generic infrastructure has been going into drivers/char, and drivers themselves have been going wherever they seem best. Really what you have is 2 character devices: one for configuration, and one for access. Steve ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] powerpc: Record vma->phys_addr in ioremap()
The vmalloc code can track the physical address of a vma, when the
vma is used for ioremap, if set it is displayed in /proc/vmallocinfo.
Because get_vm_area_caller() doesn't know it's being called for
ioremap() it's up to the arch code to set the phys_addr. A bunch
of other arch's do this, I'm not sure why powerpc doesn't?
Signed-off-by: Michael Ellerman
---
arch/powerpc/mm/pgtable_32.c |1 +
arch/powerpc/mm/pgtable_64.c |2 ++
2 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/mm/pgtable_32.c b/arch/powerpc/mm/pgtable_32.c
index a87ead0..71932d0 100644
--- a/arch/powerpc/mm/pgtable_32.c
+++ b/arch/powerpc/mm/pgtable_32.c
@@ -230,6 +230,7 @@ __ioremap_caller(phys_addr_t addr, unsigned long size,
unsigned long flags,
area = get_vm_area_caller(size, VM_IOREMAP, caller);
if (area == 0)
return NULL;
+ area->phys_addr = p;
v = (unsigned long) area->addr;
} else {
v = (ioremap_bot -= size);
diff --git a/arch/powerpc/mm/pgtable_64.c b/arch/powerpc/mm/pgtable_64.c
index 21d6dfa..88927a0 100644
--- a/arch/powerpc/mm/pgtable_64.c
+++ b/arch/powerpc/mm/pgtable_64.c
@@ -223,6 +223,8 @@ void __iomem * __ioremap_caller(phys_addr_t addr, unsigned
long size,
caller);
if (area == NULL)
return NULL;
+
+ area->phys_addr = paligned;
ret = __ioremap_at(paligned, area->addr, size, flags);
if (!ret)
vunmap(area->addr);
--
1.7.1
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] powerpc: Record vma->phys_addr in ioremap()
On Mon, 2010-11-29 at 15:26 +1100, Michael Ellerman wrote:
> The vmalloc code can track the physical address of a vma, when the
> vma is used for ioremap, if set it is displayed in /proc/vmallocinfo.
>
> Because get_vm_area_caller() doesn't know it's being called for
> ioremap() it's up to the arch code to set the phys_addr. A bunch
> of other arch's do this, I'm not sure why powerpc doesn't?
Because I never noticed ? :-)
Cheers,
Ben.
> Signed-off-by: Michael Ellerman
> ---
> arch/powerpc/mm/pgtable_32.c |1 +
> arch/powerpc/mm/pgtable_64.c |2 ++
> 2 files changed, 3 insertions(+), 0 deletions(-)
>
> diff --git a/arch/powerpc/mm/pgtable_32.c b/arch/powerpc/mm/pgtable_32.c
> index a87ead0..71932d0 100644
> --- a/arch/powerpc/mm/pgtable_32.c
> +++ b/arch/powerpc/mm/pgtable_32.c
> @@ -230,6 +230,7 @@ __ioremap_caller(phys_addr_t addr, unsigned long size,
> unsigned long flags,
> area = get_vm_area_caller(size, VM_IOREMAP, caller);
> if (area == 0)
> return NULL;
> + area->phys_addr = p;
> v = (unsigned long) area->addr;
> } else {
> v = (ioremap_bot -= size);
> diff --git a/arch/powerpc/mm/pgtable_64.c b/arch/powerpc/mm/pgtable_64.c
> index 21d6dfa..88927a0 100644
> --- a/arch/powerpc/mm/pgtable_64.c
> +++ b/arch/powerpc/mm/pgtable_64.c
> @@ -223,6 +223,8 @@ void __iomem * __ioremap_caller(phys_addr_t addr,
> unsigned long size,
> caller);
> if (area == NULL)
> return NULL;
> +
> + area->phys_addr = paligned;
> ret = __ioremap_at(paligned, area->addr, size, flags);
> if (!ret)
> vunmap(area->addr);
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] powerpc: Record vma->phys_addr in ioremap()
On Mon, 2010-11-29 at 15:56 +1100, Benjamin Herrenschmidt wrote: > On Mon, 2010-11-29 at 15:26 +1100, Michael Ellerman wrote: > > The vmalloc code can track the physical address of a vma, when the > > vma is used for ioremap, if set it is displayed in /proc/vmallocinfo. > > > > Because get_vm_area_caller() doesn't know it's being called for > > ioremap() it's up to the arch code to set the phys_addr. A bunch > > of other arch's do this, I'm not sure why powerpc doesn't? > > Because I never noticed ? :-) Yeah I figured. It seems to go back past 2.6.12 so who knows when it went in, anyway it's useful. cheers signature.asc Description: This is a digitally signed message part ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Pegasos OHCI bug (was Re: PROBLEM: memory corrupting bug,
> I have a mostly-finished patch to do the above. I'll include it below, but
> first a few words about why it's only mostly finished.
>
> The other Pegasos workarounds are in fixup_device_tree_chrp, and I don't see
> anything like an "if(machine_is_pegasos)" around them. What keeps them from
> being erroneously run on other CHRP-type machines? I made this patch mainly
> by copying pieces of other functions from prom_init.c, but couldn't find the
> "test for Pegasos before running a Pegasos workaround" piece.
Probably bcs the condition they test for really only happens on
pegasos ? :-)
I agree it's a bit gross tho.
The "ranges" property fixup is pretty harmless in any case. The other
fixup might be worth moving to a separate pegasos-only function in which
you would test for a pegasos properly and add your own stuff.
> Another issue is, since the firmware doesn't give me a "compatible" property
> with the details of the controller, I just have to assume that it's
> little-endian. I'm not sure if that's clean, since the real ohci driver
> supports both endiannesses, with at least 3 different Kconfig options(!) to
> choose between them.
If it's PCI it's LE or somebody needs to be shot :-)
> Then there's the volatile which I guess is supposed to be replaced by
> something else, but I don't know what the something else is. I believe this
> usage is extremely close to what volatile was meant for.
Yeah, it's fine, just add something like that on the next line:
asm volatile("eieio" : : : "memory");
> Finally, when I updated to a more recent upstream kernel to test the patch, I
> found that an intervening commit (3df7169e73fc1d71a39cffeacc969f6840cdf52b,
> OHCI: work around for nVidia shutdown problem) has had a major effect,
> on the appearance of my bug.
>
> Before that change, the window in which the bug could strike was from the end
> of prom_init (when the kernel believes that devices are quiescent) to the
> initialization of the ohci-hcd driver (which actually quietens the device, or
> at least directs its scribbling to a properly allocated page). After the
> change, the window ends at some point early in the PCI bus setup. That's a
> window so small that with a new kernel, I can't provoke a symptom even if I
> try.
Right but it's very fishy, ie, it may still be DMA'ing and god knows
where ... you may or may not get lucky. I'd rather you do a proper
fixup :-)
Cheers,
Ben.
> Mostly-finished patch:
>
> diff --git a/arch/powerpc/kernel/prom_init.c b/arch/powerpc/kernel/prom_init.c
> index 941ff4d..a14f21b 100644
> --- a/arch/powerpc/kernel/prom_init.c
> +++ b/arch/powerpc/kernel/prom_init.c
> @@ -2237,6 +2237,81 @@ static void __init fixup_device_tree_chrp(void)
> }
> }
> }
> +
> +/*
> + * Pegasos firmware doesn't quiesce OHCI controllers, so do it manually
> + */
> +static void __init pegasos_quiesce(void)
> +{
> + phandle node, parent_node;
> + ihandle parent_ih;
> + int rc;
> + char type[16], *path;
> + u32 prop[5], map_size;
> + prom_arg_t ohci_virt;
> +
> + for (node = 0; prom_next_node(&node); ) {
> + memset(type, 0, sizeof(type));
> + prom_getprop(node, "device_type", type, sizeof(type));
> + if (strcmp(type, RELOC("usb")) != 0)
> + continue;
> +
> + /* Parent should be a PCI bus (so class-code makes sense).
> +class-code should be 0x0C0310 */
> + parent_node = call_prom("parent", 1, 1, node);
> + if (!parent_node)
> + continue;
> + rc = prom_getprop(node, "class-code", prop, sizeof(u32));
> + if (rc != sizeof(u32) || prop[0] != 0x0c0310)
> + continue;
> +
> + rc = prom_getprop(node, "assigned-addresses",
> + prop, 5*sizeof(u32));
> + if (rc != 5*sizeof(u32))
> + continue;
> +
> + /* Open the parent and call map-in */
> +
> + /* It seems OF doesn't null-terminate the path :-( */
> + path = RELOC(prom_scratch);
> + memset(path, 0, PROM_SCRATCH_SIZE);
> +
> + if (call_prom("package-to-path", 3, 1, parent_node,
> + path, PROM_SCRATCH_SIZE-1) == PROM_ERROR)
> + continue;
> + parent_ih = call_prom("open", 1, 1, path);
> +
> + /* Get the OHCI node's pathname, for printing later */
> + memset(path, 0, PROM_SCRATCH_SIZE);
> + call_prom("package-to-path", 3, 1, node,
> + path, PROM_SCRATCH_SIZE-1);
> +
> + map_size = prop[4];
> + if (call_prom_ret("call-method", 6, 2, &ohci_virt,
> + ADDR("map-in"), parent_ih,
> + map_size, prop[0], prop[1], prop[2]) == 0) {
> + prom_printf("resetting OHCI device %s...", path);
> +
> +
Re: RFC: Mega rename of device tree routines from of_*() to dt_*()
On Fri, Nov 26, 2010 at 12:34:35AM +1100, Michael Ellerman wrote: > On Thu, 2010-11-25 at 01:03 +1100, Michael Ellerman wrote: > > Hi all, > > > > There were some murmurings on IRC last week about renaming the of_*() > > routines. > ... > > The thinking is that on many platforms that use the of_() routines > > OpenFirmware is not involved at all, this is true even on many powerpc > > platforms. Also for folks who don't know the OpenFirmware connection > > it reads as "of", as in "a can of worms". > ... > > So I'm hoping people with either say "YES this is a great idea", or "NO > > this is stupid". > > I'm still hoping, but so far it seems most people have got better things > to do, and of those that do have an opinion the balance is slightly > positive. > > So here's a first cut of a patch to add the new names. I've not touched > of_platform because that is supposed to go away. That will lead to some > odd looking code in the interim, but I think is the right approach. > > Most of these are straight renames, but some have changed more > substantially. The routines for the flat tree have all become fdt_foo(). I'm a little uneasy about using the same prefix as libfdt (fdt_foo()) for routines that have a different implementation and different names / semantics to the libfdt routines. -- David Gibson| I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_ | _way_ _around_! http://www.ozlabs.org/~dgibson signature.asc Description: Digital signature ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: RFC: Mega rename of device tree routines from of_*() to dt_*()
On Sun, Nov 28, 2010 at 10:55 PM, David Gibson wrote: > On Fri, Nov 26, 2010 at 12:34:35AM +1100, Michael Ellerman wrote: >> Most of these are straight renames, but some have changed more >> substantially. The routines for the flat tree have all become fdt_foo(). > > I'm a little uneasy about using the same prefix as libfdt (fdt_foo()) > for routines that have a different implementation and different names > / semantics to the libfdt routines. I'd also be okay with either dtflat_ or flatdt_ for the prefix on these routines. g. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: ppc_set_hwdebug vs ptrace_set_debugreg
On Sat, Nov 27, 2010 at 08:36:30PM +0100, Andreas Schwab wrote: > Why does ptrace_set_debugreg call register_user_hw_breakpoint, but > ppc_set_hwdebug doesn't? Shouldn't ppc_set_hwdebug set the > DABR_DATA_(READ|WRITE|TRANSLATION) bits in the dabr? > > Andreas. The hw-breakpoint interfaces were initially planned for the old ptrace option PTRACE_SET_DEBUGREG,while, the newer ptrace options are mostly to exploit the advanced debug features of Book3E processors. Although ppc_set_hwdebug() can set DABR through set_dabr() in arch/powerpc/kernel/process.c, it is good to have it converted to use register_user_hw_breakpoint(). This was planned to be done alongside the conversion of all ptrace options enabled by CONFIG_PPC_ADV_DEBUG_REGS, which is yet to be done. Are you looking to use debug registers through perf, or somesuch, that you need register_user_hw_breakpoint() to be used for these new ptrace flags? Thanks, K.Prasad ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
