Re: [PATCH v6 0/8] ptp: IEEE 1588 hardware clock support
On Mon, Sep 27, 2010 at 10:14:23AM -0600, M. Warner Losh wrote:
This is a common error that I've seen repeated in this thread. The
only reason that it has historically been important is because when
you are doing timestamping in software based on an interrupt, that
stuff does matter.
Yes, thanks for your helpful explanation.
To further illustrate how small the effect of running the servo in
user space is, consider the following.
It is true that delays and jitter in the time to process the received
packet negatively affect the clock servo loop. However, the effect in
our case will be quite small.
John Eidson's book [1] presents a rigorous servo model that includes
an analysis of the delay from the time the samples (timestamps) are
taken until the corrective action is performed by the PTP software.
For PTP, the sample time is at the sender (the remote host, the master
clock). The master sends *two* packets, where the second one (the so
called follow-up packet) contains the hardware time stamp of the first
one. So, the computational delay includes the time spent by the sender
in its PTP stack preparing the second packet, the time the packet
spends in transit, and the time in the receiver's PTP stack and servo.
According to Eidson's analysis, a delay of up to 10 milliseconds would
be acceptable, even with a sample rate of 10 Hz. Therefore, saving a
few dozen microseconds by placing the servo (and PTP stack) into the
kernel is not worth the effort.
Richard
[1] title = {Measurement, control, and communication using IEEE 1588},
author ={J. C. Eidson},
year = 2006,
publisher = {Springer-Verlag},
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v6 0/8] ptp: IEEE 1588 hardware clock support
On Mon, Sep 27, 2010 at 06:05:58PM +0100, Alan Cox wrote: On Mon, 27 Sep 2010 10:56:09 -0500 (CDT) Christoph Lameter c...@linux.com wrote: On Fri, 24 Sep 2010, Alan Cox wrote: Whether you add new syscalls or do the fd passing using flags and hide the ugly bits in glibc is another question. Use device specific ioctls instead of syscalls? Some of the ioctls are probably not device specific, the job of the OS in part is to present a unified interface. We already have a mess of HPET and RTC driver ioctls. Yes, and the whole point of introducing a PTP hardare clock API was to avoid each new clock driver introducing yet another ioctl interface. I had proposed a standard ioctl interface for PTP hardware clocks, but that interface was rightly criticized for duplicating the posix clock API. It does not make sense to have multiple interfaces with the exact same functionality. It is impossible to support every last feature of every possible hardware clock with a generic interface, so there will always need to be special ioctls for such features. However, some clock functions *are* completely generic and apply to every clock: - set time - get time - adjust the frequency by N ppb - shift the time by a given offset The first two are provided by the posix clock interface, the third by the NTP adjtimex call, which also can support (by a single mode extension) the last item. Richard ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH v2 0/3] Add USB Host support for MPC5121 SoC
This is version 2 of patches to add MPC512x USB support in mainline kernel. USB OTG support is not included in this patch series, it will be submitted later. The patches have been rebased on current linux-next tree and reworked to address comments from Grant. Anatolij Gustschin (3): powerpc/fsl_soc.c: remove FSL USB platform code USB: add of_platform glue driver for FSL USB DR controller USB: add USB EHCI support for MPC5121 SoC Documentation/powerpc/dts-bindings/fsl/usb.txt | 22 ++ arch/powerpc/sysdev/fsl_soc.c | 163 - drivers/usb/Kconfig|1 + drivers/usb/gadget/Kconfig |1 + drivers/usb/host/Kconfig | 10 +- drivers/usb/host/Makefile |1 + drivers/usb/host/ehci-fsl.c| 99 ++--- drivers/usb/host/ehci-fsl.h| 13 +- drivers/usb/host/ehci-mem.c|2 +- drivers/usb/host/fsl-mph-dr-of.c | 302 include/linux/fsl_devices.h| 15 ++ 11 files changed, 434 insertions(+), 195 deletions(-) create mode 100644 drivers/usb/host/fsl-mph-dr-of.c ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH v2 1/3] powerpc/fsl_soc.c: remove FSL USB platform code
This removed code will be replaced by simple of_platform
driver for creation of FSL USB platform devices which is
added by next patch of the series.
Signed-off-by: Anatolij Gustschin ag...@denx.de
Cc: Kumar Gala ga...@kernel.crashing.org
Cc: Grant Likely grant.lik...@secretlab.ca
---
arch/powerpc/sysdev/fsl_soc.c | 163 -
1 files changed, 0 insertions(+), 163 deletions(-)
diff --git a/arch/powerpc/sysdev/fsl_soc.c b/arch/powerpc/sysdev/fsl_soc.c
index b91f7ac..49a51f1 100644
--- a/arch/powerpc/sysdev/fsl_soc.c
+++ b/arch/powerpc/sysdev/fsl_soc.c
@@ -209,169 +209,6 @@ static int __init of_add_fixed_phys(void)
arch_initcall(of_add_fixed_phys);
#endif /* CONFIG_FIXED_PHY */
-static enum fsl_usb2_phy_modes determine_usb_phy(const char *phy_type)
-{
- if (!phy_type)
- return FSL_USB2_PHY_NONE;
- if (!strcasecmp(phy_type, ulpi))
- return FSL_USB2_PHY_ULPI;
- if (!strcasecmp(phy_type, utmi))
- return FSL_USB2_PHY_UTMI;
- if (!strcasecmp(phy_type, utmi_wide))
- return FSL_USB2_PHY_UTMI_WIDE;
- if (!strcasecmp(phy_type, serial))
- return FSL_USB2_PHY_SERIAL;
-
- return FSL_USB2_PHY_NONE;
-}
-
-static int __init fsl_usb_of_init(void)
-{
- struct device_node *np;
- unsigned int i = 0;
- struct platform_device *usb_dev_mph = NULL, *usb_dev_dr_host = NULL,
- *usb_dev_dr_client = NULL;
- int ret;
-
- for_each_compatible_node(np, NULL, fsl-usb2-mph) {
- struct resource r[2];
- struct fsl_usb2_platform_data usb_data;
- const unsigned char *prop = NULL;
-
- memset(r, 0, sizeof(r));
- memset(usb_data, 0, sizeof(usb_data));
-
- ret = of_address_to_resource(np, 0, r[0]);
- if (ret)
- goto err;
-
- of_irq_to_resource(np, 0, r[1]);
-
- usb_dev_mph =
- platform_device_register_simple(fsl-ehci, i, r, 2);
- if (IS_ERR(usb_dev_mph)) {
- ret = PTR_ERR(usb_dev_mph);
- goto err;
- }
-
- usb_dev_mph-dev.coherent_dma_mask = 0xUL;
- usb_dev_mph-dev.dma_mask = usb_dev_mph-dev.coherent_dma_mask;
-
- usb_data.operating_mode = FSL_USB2_MPH_HOST;
-
- prop = of_get_property(np, port0, NULL);
- if (prop)
- usb_data.port_enables |= FSL_USB2_PORT0_ENABLED;
-
- prop = of_get_property(np, port1, NULL);
- if (prop)
- usb_data.port_enables |= FSL_USB2_PORT1_ENABLED;
-
- prop = of_get_property(np, phy_type, NULL);
- usb_data.phy_mode = determine_usb_phy(prop);
-
- ret =
- platform_device_add_data(usb_dev_mph, usb_data,
-sizeof(struct
- fsl_usb2_platform_data));
- if (ret)
- goto unreg_mph;
- i++;
- }
-
- for_each_compatible_node(np, NULL, fsl-usb2-dr) {
- struct resource r[2];
- struct fsl_usb2_platform_data usb_data;
- const unsigned char *prop = NULL;
-
- if (!of_device_is_available(np))
- continue;
-
- memset(r, 0, sizeof(r));
- memset(usb_data, 0, sizeof(usb_data));
-
- ret = of_address_to_resource(np, 0, r[0]);
- if (ret)
- goto unreg_mph;
-
- of_irq_to_resource(np, 0, r[1]);
-
- prop = of_get_property(np, dr_mode, NULL);
-
- if (!prop || !strcmp(prop, host)) {
- usb_data.operating_mode = FSL_USB2_DR_HOST;
- usb_dev_dr_host = platform_device_register_simple(
- fsl-ehci, i, r, 2);
- if (IS_ERR(usb_dev_dr_host)) {
- ret = PTR_ERR(usb_dev_dr_host);
- goto err;
- }
- } else if (prop !strcmp(prop, peripheral)) {
- usb_data.operating_mode = FSL_USB2_DR_DEVICE;
- usb_dev_dr_client = platform_device_register_simple(
- fsl-usb2-udc, i, r, 2);
- if (IS_ERR(usb_dev_dr_client)) {
- ret = PTR_ERR(usb_dev_dr_client);
- goto err;
- }
- } else if (prop !strcmp(prop, otg)) {
- usb_data.operating_mode = FSL_USB2_DR_OTG;
- usb_dev_dr_host = platform_device_register_simple(
- fsl-ehci, i, r, 2);
-
[PATCH v2 2/3] USB: add of_platform glue driver for FSL USB DR controller
The driver creates platform devices based on the information
from USB nodes in the flat device tree. This is the replacement
for old arch fsl_soc usb code removed by the previous patch.
It uses usual of-style binding, available EHCI-HCD and UDC
drivers can be bound to the created devices. The new of-style
driver additionaly instantiates USB OTG platform device, as the
appropriate USB OTG driver will be added soon.
Signed-off-by: Anatolij Gustschin ag...@denx.de
Cc: Kumar Gala ga...@kernel.crashing.org
Cc: Grant Likely grant.lik...@secretlab.ca
---
v2:
- drop unneeded PPC_OF dependency
- fix spelling bug in mode table and fix coding style
- print a warning if no valid dr_mode found
- add remove hook to unregister platform devices
created by probe. So the driver can be unbound
- fix OTG platform device creation order
- drop fs_initcall, replaced by module_init() now
- add module_exit(), MODULE_DESCRIPTION, MODULE_LICENSE
drivers/usb/gadget/Kconfig |1 +
drivers/usb/host/Kconfig |4 +
drivers/usb/host/Makefile|1 +
drivers/usb/host/fsl-mph-dr-of.c | 213 ++
4 files changed, 219 insertions(+), 0 deletions(-)
create mode 100644 drivers/usb/host/fsl-mph-dr-of.c
diff --git a/drivers/usb/gadget/Kconfig b/drivers/usb/gadget/Kconfig
index fab765d..0fe5bc8 100644
--- a/drivers/usb/gadget/Kconfig
+++ b/drivers/usb/gadget/Kconfig
@@ -158,6 +158,7 @@ config USB_GADGET_FSL_USB2
boolean Freescale Highspeed USB DR Peripheral Controller
depends on FSL_SOC || ARCH_MXC
select USB_GADGET_DUALSPEED
+ select USB_FSL_MPH_DR_OF
help
Some of Freescale PowerPC processors have a High Speed
Dual-Role(DR) USB controller, which supports device mode.
diff --git a/drivers/usb/host/Kconfig b/drivers/usb/host/Kconfig
index 2d926ce..f3a90b0 100644
--- a/drivers/usb/host/Kconfig
+++ b/drivers/usb/host/Kconfig
@@ -112,10 +112,14 @@ config XPS_USB_HCD_XILINX
support both high speed and full speed devices, or high speed
devices only.
+config USB_FSL_MPH_DR_OF
+ tristate
+
config USB_EHCI_FSL
bool Support for Freescale on-chip EHCI USB controller
depends on USB_EHCI_HCD FSL_SOC
select USB_EHCI_ROOT_HUB_TT
+ select USB_FSL_MPH_DR_OF
---help---
Variation of ARC USB block used in some Freescale chips.
diff --git a/drivers/usb/host/Makefile b/drivers/usb/host/Makefile
index b6315aa..aacbe82 100644
--- a/drivers/usb/host/Makefile
+++ b/drivers/usb/host/Makefile
@@ -33,4 +33,5 @@ obj-$(CONFIG_USB_R8A66597_HCD)+= r8a66597-hcd.o
obj-$(CONFIG_USB_ISP1760_HCD) += isp1760.o
obj-$(CONFIG_USB_HWA_HCD) += hwa-hc.o
obj-$(CONFIG_USB_IMX21_HCD)+= imx21-hcd.o
+obj-$(CONFIG_USB_FSL_MPH_DR_OF)+= fsl-mph-dr-of.o
diff --git a/drivers/usb/host/fsl-mph-dr-of.c b/drivers/usb/host/fsl-mph-dr-of.c
new file mode 100644
index 000..ee8cb94
--- /dev/null
+++ b/drivers/usb/host/fsl-mph-dr-of.c
@@ -0,0 +1,213 @@
+/*
+ * Setup platform devices needed by the Freescale multi-port host
+ * and/or dual-role USB controller modules based on the description
+ * in flat device tree.
+ *
+ * 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 linux/kernel.h
+#include linux/platform_device.h
+#include linux/fsl_devices.h
+#include linux/err.h
+#include linux/io.h
+#include linux/of_platform.h
+
+struct fsl_usb2_dev_data {
+ char *dr_mode; /* controller mode */
+ char *drivers[3]; /* drivers to instantiate for this mode */
+ enum fsl_usb2_operating_modes op_mode; /* operating mode */
+};
+
+struct fsl_usb2_dev_data dr_mode_data[] __devinitdata = {
+ {
+ .dr_mode = host,
+ .drivers = { fsl-ehci, NULL, NULL, },
+ .op_mode = FSL_USB2_DR_HOST,
+ },
+ {
+ .dr_mode = otg,
+ .drivers = { fsl-usb2-otg, fsl-ehci, fsl-usb2-udc, },
+ .op_mode = FSL_USB2_DR_OTG,
+ },
+ {
+ .dr_mode = peripheral,
+ .drivers = { fsl-usb2-udc, NULL, NULL, },
+ .op_mode = FSL_USB2_DR_DEVICE,
+ },
+};
+
+struct fsl_usb2_dev_data * __devinit get_dr_mode_data(struct device_node *np)
+{
+ const unsigned char *prop;
+ int i;
+
+ prop = of_get_property(np, dr_mode, NULL);
+ if (prop) {
+ for (i = 0; i ARRAY_SIZE(dr_mode_data); i++) {
+ if (!strcmp(prop, dr_mode_data[i].dr_mode))
+ return dr_mode_data[i];
+ }
+ }
+ pr_warn(%s: Invalid 'dr_mode' property, fallback to host mode\n,
+ np-full_name);
+ return
[PATCH v2 3/3] USB: add USB EHCI support for MPC5121 SoC
Extends FSL EHCI platform driver glue layer to support
MPC5121 USB controllers. MPC5121 Rev 2.0 silicon EHCI
registers are in big endian format. The appropriate flags
are set using the information in the platform data structure.
MPC83xx system interface registers are not available on
MPC512x, so the access to these registers is isolated in
MPC512x case. Furthermore the USB controller clocks
must be enabled before 512x register accesses which is
done by providing platform specific init callback.
The MPC512x internal USB PHY doesn't provide supply voltage.
For boards using different power switches allow specifying
DRVVBUS and PWR_FAULT signal polarity of the MPC5121 internal
PHY using fsl,invert-drvvbus and fsl,invert-pwr-fault
properties in the device tree USB nodes. Adds documentation
for this new device tree bindings.
Signed-off-by: Anatolij Gustschin ag...@denx.de
Cc: Grant Likely grant.lik...@secretlab.ca
---
v2:
- rebased on linux-next
- remove host mode setting in usb_hcd_fsl_probe() since
this is set in tdi_reset() anyway
- drop now unneeded defines previously used for host
mode setting
Documentation/powerpc/dts-bindings/fsl/usb.txt | 22 +
drivers/usb/Kconfig|1 +
drivers/usb/host/Kconfig |6 +-
drivers/usb/host/ehci-fsl.c| 99 +---
drivers/usb/host/ehci-fsl.h| 13 +++-
drivers/usb/host/ehci-mem.c|2 +-
drivers/usb/host/fsl-mph-dr-of.c | 89 +
include/linux/fsl_devices.h| 15
8 files changed, 215 insertions(+), 32 deletions(-)
diff --git a/Documentation/powerpc/dts-bindings/fsl/usb.txt
b/Documentation/powerpc/dts-bindings/fsl/usb.txt
index b001524..bd5723f 100644
--- a/Documentation/powerpc/dts-bindings/fsl/usb.txt
+++ b/Documentation/powerpc/dts-bindings/fsl/usb.txt
@@ -8,6 +8,7 @@ and additions :
Required properties :
- compatible : Should be fsl-usb2-mph for multi port host USB
controllers, or fsl-usb2-dr for dual role USB controllers
+ or fsl,mpc5121-usb2-dr for dual role USB controllers of MPC5121
- phy_type : For multi port host USB controllers, should be one of
ulpi, or serial. For dual role USB controllers, should be
one of ulpi, utmi, utmi_wide, or serial.
@@ -33,6 +34,12 @@ Recommended properties :
- interrupt-parent : the phandle for the interrupt controller that
services interrupts for this device.
+Optional properties :
+ - fsl,invert-drvvbus : boolean; for MPC5121 USB0 only. Indicates the
+ port power polarity of internal PHY signal DRVVBUS is inverted.
+ - fsl,invert-pwr-fault : boolean; for MPC5121 USB0 only. Indicates
+ the PWR_FAULT signal polarity is inverted.
+
Example multi port host USB controller device node :
u...@22000 {
compatible = fsl-usb2-mph;
@@ -57,3 +64,18 @@ Example dual role USB controller device node :
dr_mode = otg;
phy = ulpi;
};
+
+Example dual role USB controller device node for MPC5121ADS:
+
+ u...@4000 {
+ compatible = fsl,mpc5121-usb2-dr;
+ reg = 0x4000 0x1000;
+ #address-cells = 1;
+ #size-cells = 0;
+ interrupt-parent = ipic ;
+ interrupts = 44 0x8;
+ dr_mode = otg;
+ phy_type = utmi_wide;
+ fsl,invert-drvvbus;
+ fsl,invert-pwr-fault;
+ };
diff --git a/drivers/usb/Kconfig b/drivers/usb/Kconfig
index 4aa00e6..67eb377 100644
--- a/drivers/usb/Kconfig
+++ b/drivers/usb/Kconfig
@@ -59,6 +59,7 @@ config USB_ARCH_HAS_OHCI
config USB_ARCH_HAS_EHCI
boolean
default y if PPC_83xx
+ default y if PPC_MPC512x
default y if SOC_AU1200
default y if ARCH_IXP4XX
default y if ARCH_W90X900
diff --git a/drivers/usb/host/Kconfig b/drivers/usb/host/Kconfig
index f3a90b0..bf2e7d2 100644
--- a/drivers/usb/host/Kconfig
+++ b/drivers/usb/host/Kconfig
@@ -93,12 +93,14 @@ config USB_EHCI_TT_NEWSCHED
config USB_EHCI_BIG_ENDIAN_MMIO
bool
- depends on USB_EHCI_HCD (PPC_CELLEB || PPC_PS3 || 440EPX ||
ARCH_IXP4XX || XPS_USB_HCD_XILINX)
+ depends on USB_EHCI_HCD (PPC_CELLEB || PPC_PS3 || 440EPX ||
ARCH_IXP4XX || \
+ XPS_USB_HCD_XILINX || PPC_MPC512x)
default y
config USB_EHCI_BIG_ENDIAN_DESC
bool
- depends on USB_EHCI_HCD (440EPX || ARCH_IXP4XX || XPS_USB_HCD_XILINX)
+ depends on USB_EHCI_HCD (440EPX || ARCH_IXP4XX || XPS_USB_HCD_XILINX
|| \
+ PPC_MPC512x)
default y
config XPS_USB_HCD_XILINX
diff --git a/drivers/usb/host/ehci-fsl.c b/drivers/usb/host/ehci-fsl.c
index 8600317..86e4289 100644
--- a/drivers/usb/host/ehci-fsl.c
+++ b/drivers/usb/host/ehci-fsl.c
@@ -116,13 +116,33 @@ static int usb_hcd_fsl_probe(const struct hc_driver
Re: [PATCH 2/8] v2 Add section count to memory_block struct
In the next patch, you introduce a mutex for adding/removing memory blocks.
Is there really a need for this to be atomic? If you reorder the patches
so the mutex comes first, would the atomic be needed any longer?
Robin
On Mon, Sep 27, 2010 at 02:22:24PM -0500, Nathan Fontenot wrote:
Add a section count property to the memory_block struct to track the number
of memory sections that have been added/removed from a memory block. This
allows us to know when the last memory section of a memory block has been
removed so we can remove the memory block.
Signed-off-by: Nathan Fontenot nf...@austin.ibm.com
---
drivers/base/memory.c | 16 ++--
include/linux/memory.h |3 +++
2 files changed, 13 insertions(+), 6 deletions(-)
Index: linux-next/drivers/base/memory.c
===
--- linux-next.orig/drivers/base/memory.c 2010-09-27 09:17:20.0
-0500
+++ linux-next/drivers/base/memory.c 2010-09-27 09:31:35.0 -0500
@@ -478,6 +478,7 @@
mem-phys_index = __section_nr(section);
mem-state = state;
+ atomic_inc(mem-section_count);
mutex_init(mem-state_mutex);
start_pfn = section_nr_to_pfn(mem-phys_index);
mem-phys_device = arch_get_memory_phys_device(start_pfn);
@@ -505,12 +506,15 @@
struct memory_block *mem;
mem = find_memory_block(section);
- unregister_mem_sect_under_nodes(mem);
- mem_remove_simple_file(mem, phys_index);
- mem_remove_simple_file(mem, state);
- mem_remove_simple_file(mem, phys_device);
- mem_remove_simple_file(mem, removable);
- unregister_memory(mem, section);
+
+ if (atomic_dec_and_test(mem-section_count)) {
+ unregister_mem_sect_under_nodes(mem);
+ mem_remove_simple_file(mem, phys_index);
+ mem_remove_simple_file(mem, state);
+ mem_remove_simple_file(mem, phys_device);
+ mem_remove_simple_file(mem, removable);
+ unregister_memory(mem, section);
+ }
return 0;
}
Index: linux-next/include/linux/memory.h
===
--- linux-next.orig/include/linux/memory.h2010-09-27 09:17:20.0
-0500
+++ linux-next/include/linux/memory.h 2010-09-27 09:22:56.0 -0500
@@ -19,10 +19,13 @@
#include linux/node.h
#include linux/compiler.h
#include linux/mutex.h
+#include asm/atomic.h
struct memory_block {
unsigned long phys_index;
unsigned long state;
+ atomic_t section_count;
+
/*
* This serializes all state change requests. It isn't
* held during creation because the control files are
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH RFCv2 1/2] dmaengine: add support for scatterlist to scatterlist transfers
On Mon, Sep 27, 2010 at 05:23:34PM +0200, Linus Walleij wrote: 2010/9/25 Ira W. Snyder i...@ovro.caltech.edu: This adds support for scatterlist to scatterlist DMA transfers. This is a good idea, we have a local function to do this in DMA40 already, stedma40_memcpy_sg(). I think that having two devices that want to implement this functionality as part of the DMAEngine API is a good argument for making it available as part of the core API. I think it would be good to add this to struct dma_device, and add a capability (DMA_SG?) for it as well. I have looked at the stedma40_memcpy_sg() function, and I think we would want to extend it slightly for the generic API. Is there any good reason to prohibit scatterlists with different numbers of elements? No /Per ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Reserved pages in PowerPC
Hi Ben, On Fri, Sep 17, 2010 at 07:52:31AM +1000, Benjamin Herrenschmidt wrote: On Thu, 2010-09-16 at 17:38 +0530, Ankita Garg wrote: Thanks Ben for taking a look at this. So I checked the rtas messages on the serial console and see the following: instantiating rtas at 0x0f632000... done Which does not correspond to the higher addresses that I see as reserved (observation on a 16G machine). Well, I'd suggest you audit prom_init.c which builds the reserve map, and the various memblock_reserve() calls in prom.c I studied and instrumented memblock_reserve() and also reserve_mem(). However, all the reserved addresses seem to correspond to lower memory. I also observed that these reserved addresses are accessed quite rapidly when a workload is being run.. -- Regards, Ankita Garg (ank...@in.ibm.com) Linux Technology Center IBM India Systems Technology Labs, Bangalore, India ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Doubt about Linux PCIe infraestructure
Hi, I have a simple doubt about linux PCI/PCIe infraestructure. When I register a PCI driver using pci_register_driver() will the probe function be automatically called or will it just be called if PCI infraestructure match a Vendor and Device id on bus? I am loading a PCI driver that register itself using pci_register_driver() but the probe function isn't called. thanks, Carlos R. Moratelli ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v2 2/3] USB: add of_platform glue driver for FSL USB DR controller
Hi Grant,
On Tue, 28 Sep 2010 19:01:28 +0900
Grant Likely grant.lik...@secretlab.ca wrote:
...
Looks pretty good. Comments below. Main comment is that with the
recent changes in mainline, this no longer needs to be an
of_platform_driver. It can be a plain old platform_driver instead.
It gets registered as a platform_driver anyway, but of_platform_driver
is a shim that adds a bit of overhead, so it is best to avoid it.
I'll detail the changes you need to make in my comments below.
Thanks. I'll change to platform_driver. My reply below.
...
+{
+ struct device_node *np = ofdev-dev.of_node;
+ struct platform_device *usb_dev;
+ struct fsl_usb2_platform_data data, *pdata;
+ struct fsl_usb2_dev_data *dev_data;
+ const unsigned char *prop;
+ static unsigned int idx;
+ int i;
+
+ if (!of_device_is_available(np))
+ return -ENODEV;
+
+ pdata = match-data;
+ if (!pdata) {
+ memset(data, 0, sizeof(data));
+ pdata = data;
+ }
This is bad behaviour. *match-data must not be modified in probe
because multiple instances of the device can exist. The target of
pdata is modified later in the probe routine.
However, the above 4 lines can be removed entirely since none of the
fsl_usb2_mph_dr_of_match entries actually set the data pointer. The
local 'data' structure can be used directly.
A match entry for mpc5121 is added by the third patch. I'll fix
this so that only local 'data' structure is modified later in the
probe routine.
Thanks,
Anatolij
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v2 1/3] powerpc/fsl_soc.c: remove FSL USB platform code
On Tue, Sep 28, 2010 at 11:36:32AM +0200, Anatolij Gustschin wrote: This removed code will be replaced by simple of_platform driver for creation of FSL USB platform devices which is added by next patch of the series. Signed-off-by: Anatolij Gustschin ag...@denx.de Cc: Kumar Gala ga...@kernel.crashing.org Cc: Grant Likely grant.lik...@secretlab.ca --- This is not bisectable. You have to merge 1/3 and 2/3. Thanks, -- Anton Vorontsov email: cbouatmai...@gmail.com irc://irc.freenode.net/bd2 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 3/3] mpc512x_dma: add MPC8308 support
MPC8308 has pretty much the same DMA controller as MPC5121 and
this patch adds support for MPC8308 to the mpc512x_dma driver.
Signed-off-by: Ilya Yanok ya...@emcraft.com
Cc: Piotr Ziecik ko...@semihalf.com
---
drivers/dma/Kconfig |2 +-
drivers/dma/mpc512x_dma.c | 95 +---
2 files changed, 72 insertions(+), 25 deletions(-)
diff --git a/drivers/dma/Kconfig b/drivers/dma/Kconfig
index 9520cf0..5c5e95b 100644
--- a/drivers/dma/Kconfig
+++ b/drivers/dma/Kconfig
@@ -100,7 +100,7 @@ config FSL_DMA
config MPC512X_DMA
tristate Freescale MPC512x built-in DMA engine support
- depends on PPC_MPC512x
+ depends on PPC_MPC512x || PPC_MPC831x
select DMA_ENGINE
---help---
Enable support for the Freescale MPC512x built-in DMA engine.
diff --git a/drivers/dma/mpc512x_dma.c b/drivers/dma/mpc512x_dma.c
index 0717527..97b92ec 100644
--- a/drivers/dma/mpc512x_dma.c
+++ b/drivers/dma/mpc512x_dma.c
@@ -1,6 +1,7 @@
/*
* Copyright (C) Freescale Semicondutor, Inc. 2007, 2008.
* Copyright (C) Semihalf 2009
+ * Copyright (C) Ilya Yanok, Emcraft Systems 2010
*
* Written by Piotr Ziecik ko...@semihalf.com. Hardware description
* (defines, structures and comments) was taken from MPC5121 DMA driver
@@ -70,6 +71,8 @@
#define MPC_DMA_DMAES_SBE (1 1)
#define MPC_DMA_DMAES_DBE (1 0)
+#define MPC_DMA_DMAGPOR_SNOOP_ENABLE (1 6)
+
#define MPC_DMA_TSIZE_10x00
#define MPC_DMA_TSIZE_20x01
#define MPC_DMA_TSIZE_40x02
@@ -104,7 +107,10 @@ struct __attribute__ ((__packed__)) mpc_dma_regs {
/* 0x30 */
u32 dmahrsh;/* DMA hw request status high(ch63~32) */
u32 dmahrsl;/* DMA hardware request status low(ch31~0) */
- u32 dmaihsa;/* DMA interrupt high select AXE(ch63~32) */
+ union {
+ u32 dmaihsa;/* DMA interrupt high select AXE(ch63~32) */
+ u32 dmagpor;/* (General purpose register on MPC8308) */
+ };
u32 dmailsa;/* DMA interrupt low select AXE(ch31~0) */
/* 0x40 ~ 0xff */
u32 reserve0[48]; /* Reserved */
@@ -195,7 +201,9 @@ struct mpc_dma {
struct mpc_dma_regs __iomem *regs;
struct mpc_dma_tcd __iomem *tcd;
int irq;
+ int irq2;
uinterror_status;
+ int is_mpc8308;
/* Lock for error_status field in this structure */
spinlock_t error_status_lock;
@@ -307,8 +315,10 @@ static irqreturn_t mpc_dma_irq(int irq, void *data)
spin_unlock(mdma-error_status_lock);
/* Handle interrupt on each channel */
- mpc_dma_irq_process(mdma, in_be32(mdma-regs-dmainth),
+ if (mdma-dma.chancnt 32) {
+ mpc_dma_irq_process(mdma, in_be32(mdma-regs-dmainth),
in_be32(mdma-regs-dmaerrh), 32);
+ }
mpc_dma_irq_process(mdma, in_be32(mdma-regs-dmaintl),
in_be32(mdma-regs-dmaerrl), 0);
@@ -562,6 +572,7 @@ static struct dma_async_tx_descriptor *
mpc_dma_prep_memcpy(struct dma_chan *chan, dma_addr_t dst, dma_addr_t src,
size_t len, unsigned long flags)
{
+ struct mpc_dma *mdma = dma_chan_to_mpc_dma(chan);
struct mpc_dma_chan *mchan = dma_chan_to_mpc_dma_chan(chan);
struct mpc_dma_desc *mdesc = NULL;
struct mpc_dma_tcd *tcd;
@@ -590,7 +601,8 @@ mpc_dma_prep_memcpy(struct dma_chan *chan, dma_addr_t dst,
dma_addr_t src,
tcd-dsize = MPC_DMA_TSIZE_32;
tcd-soff = 32;
tcd-doff = 32;
- } else if (IS_ALIGNED(src | dst | len, 16)) {
+ } else if (!mdma-is_mpc8308 IS_ALIGNED(src | dst | len, 16)) {
+ /* MPC8308 doesn't support 16 byte transfers */
tcd-ssize = MPC_DMA_TSIZE_16;
tcd-dsize = MPC_DMA_TSIZE_16;
tcd-soff = 16;
@@ -650,6 +662,15 @@ static int __devinit mpc_dma_probe(struct platform_device
*op,
return -EINVAL;
}
+ if (of_device_is_compatible(dn, fsl,mpc8308-dma)) {
+ mdma-is_mpc8308 = 1;
+ mdma-irq2 = irq_of_parse_and_map(dn, 1);
+ if (mdma-irq2 == NO_IRQ) {
+ dev_err(dev, Error mapping IRQ!\n);
+ return -EINVAL;
+ }
+ }
+
retval = of_address_to_resource(dn, 0, res);
if (retval) {
dev_err(dev, Error parsing memory region!\n);
@@ -680,11 +701,23 @@ static int __devinit mpc_dma_probe(struct platform_device
*op,
return -EINVAL;
}
+ if (mdma-is_mpc8308) {
+ retval = devm_request_irq(dev, mdma-irq2, mpc_dma_irq, 0,
+
[PATCH 2/3] mpc512x_dma: fix the hanged transfer issue
Current code clears interrupt active status _after_ submiting new transfers. This leaves a possibility of clearing the interrupt for this new transfer (if it is triggered fast enough) and thus lose this interrupt. We want to clear interrupt active status _before_ new transfers is submited and for current channel only. Signed-off-by: Ilya Yanok ya...@emcraft.com Cc: Piotr Ziecik ko...@semihalf.com --- drivers/dma/mpc512x_dma.c |9 +++-- 1 files changed, 3 insertions(+), 6 deletions(-) diff --git a/drivers/dma/mpc512x_dma.c b/drivers/dma/mpc512x_dma.c index 1bc04aa..0717527 100644 --- a/drivers/dma/mpc512x_dma.c +++ b/drivers/dma/mpc512x_dma.c @@ -276,6 +276,9 @@ static void mpc_dma_irq_process(struct mpc_dma *mdma, u32 is, u32 es, int off) spin_lock(mchan-lock); + out_8(mdma-regs-dmacint, ch + off); + out_8(mdma-regs-dmacerr, ch + off); + /* Check error status */ if (es (1 ch)) list_for_each_entry(mdesc, mchan-active, node) @@ -309,12 +312,6 @@ static irqreturn_t mpc_dma_irq(int irq, void *data) mpc_dma_irq_process(mdma, in_be32(mdma-regs-dmaintl), in_be32(mdma-regs-dmaerrl), 0); - /* Ack interrupt on all channels */ - out_be32(mdma-regs-dmainth, 0x); - out_be32(mdma-regs-dmaintl, 0x); - out_be32(mdma-regs-dmaerrh, 0x); - out_be32(mdma-regs-dmaerrl, 0x); - /* Schedule tasklet */ tasklet_schedule(mdma-tasklet); -- 1.7.2.3 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 1/3] mpc512x_dma: scatter/gather fix
While testing mpc512x-dma driver with dmatest module I've found that I can hang the mpc512x-dma issueing request from multiple threads to the single channel. (insmod dmatest.ko max_channels=1 threads_per_chan=16) After investingating this case I've managed to find that this happens if and only if we have more than one quequed requests. In this case the driver tries to make use of hardware scatter/gather functionality. I've found two problems with scatter/gather: 1. When TCD is copied form RAM to the TCD register space with memcpy_io() e_sg bit eventually gets cleared. This results in only first TCD being executed. I've added setting of e_sg bit excplicitly in the TCD registers. BTW, what is the correct way to do this? (How can I use setbits with bitfield structure?) After that hardware loads consecutive TCDs and we hit the second issue. 2. Existing code clears int_maj bit in the last TCD so we never get an interrupt on transfefr completion. With these fixes my tests with many threads of single channel succeed but tests that use many channels simultaneously still don't work reliable. Signed-off-by: Ilya Yanok ya...@emcraft.com Cc: Piotr Ziecik ko...@semihalf.com --- drivers/dma/mpc512x_dma.c |4 +++- 1 files changed, 3 insertions(+), 1 deletions(-) diff --git a/drivers/dma/mpc512x_dma.c b/drivers/dma/mpc512x_dma.c index 4e9cbf3..1bc04aa 100644 --- a/drivers/dma/mpc512x_dma.c +++ b/drivers/dma/mpc512x_dma.c @@ -252,11 +252,13 @@ static void mpc_dma_execute(struct mpc_dma_chan *mchan) prev = mdesc; } - prev-tcd-start = 0; prev-tcd-int_maj = 1; /* Send first descriptor in chain into hardware */ memcpy_toio(mdma-tcd[cid], first-tcd, sizeof(struct mpc_dma_tcd)); + + if (first != prev) + mdma-tcd[cid].e_sg = 1; out_8(mdma-regs-dmassrt, cid); } -- 1.7.2.3 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 0/8] v2 De-Couple sysfs memory directories from memory sections
I was tasked with looking at a slowdown in similar sized SGI machines booting x86_64. Jack Steiner had already looked into the memory_dev_init. I was looking at link_mem_sections(). I made a dramatic improvement on a 16TB machine in that function by merely caching the most recent memory section and checking to see if the next memory section happens to be the subsequent in the linked list of kobjects. That simple cache reduced the time for link_mem_sections from 1 hour 27 minutes down to 46 seconds. I would like to propose we implement something along those lines also, but I am currently swamped. I can probably get you a patch tomorrow afternoon that applies at the end of this set. Thanks, Robin On Mon, Sep 27, 2010 at 02:09:31PM -0500, Nathan Fontenot wrote: This set of patches decouples the concept that a single memory section corresponds to a single directory in /sys/devices/system/memory/. On systems with large amounts of memory (1+ TB) there are perfomance issues related to creating the large number of sysfs directories. For a powerpc machine with 1 TB of memory we are creating 63,000+ directories. This is resulting in boot times of around 45-50 minutes for systems with 1 TB of memory and 8 hours for systems with 2 TB of memory. With this patch set applied I am now seeing boot times of 5 minutes or less. The root of this issue is in sysfs directory creation. Every time a directory is created a string compare is done against all sibling directories to ensure we do not create duplicates. The list of directory nodes in sysfs is kept as an unsorted list which results in this being an exponentially longer operation as the number of directories are created. The solution solved by this patch set is to allow a single directory in sysfs to span multiple memory sections. This is controlled by an optional architecturally defined function memory_block_size_bytes(). The default definition of this routine returns a memory block size equal to the memory section size. This maintains the current layout of sysfs memory directories as it appears to userspace to remain the same as it is today. For architectures that define their own version of this routine, as is done for powerpc in this patchset, the view in userspace would change such that each memoryXXX directory would span multiple memory sections. The number of sections spanned would depend on the value reported by memory_block_size_bytes. In both cases a new file 'end_phys_index' is created in each memoryXXX directory. This file will contain the physical id of the last memory section covered by the sysfs directory. For the default case, the value in 'end_phys_index' will be the same as in the existing 'phys_index' file. This version of the patch set includes an update to to properly report block_size_bytes, phys_index, and end_phys_index. Additionally, the patch that adds the end_phys_index sysfs file is now patch 5/8 instead of being patch 2/8 as in the previous version of the patches. -Nathan Fontenot -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 0/8] v2 De-Couple sysfs memory directories from memory sections
On 09/27/2010 09:09 PM, Nathan Fontenot wrote: This set of patches decouples the concept that a single memory section corresponds to a single directory in /sys/devices/system/memory/. On systems with large amounts of memory (1+ TB) there are perfomance issues related to creating the large number of sysfs directories. For a powerpc machine with 1 TB of memory we are creating 63,000+ directories. This is resulting in boot times of around 45-50 minutes for systems with 1 TB of memory and 8 hours for systems with 2 TB of memory. With this patch set applied I am now seeing boot times of 5 minutes or less. The root of this issue is in sysfs directory creation. Every time a directory is created a string compare is done against all sibling directories to ensure we do not create duplicates. The list of directory nodes in sysfs is kept as an unsorted list which results in this being an exponentially longer operation as the number of directories are created. The solution solved by this patch set is to allow a single directory in sysfs to span multiple memory sections. This is controlled by an optional architecturally defined function memory_block_size_bytes(). The default definition of this routine returns a memory block size equal to the memory section size. This maintains the current layout of sysfs memory directories as it appears to userspace to remain the same as it is today. Why not update sysfs directory creation to be fast, for example by using an rbtree instead of a linked list. This fixes an implementation problem in the kernel instead of working around it and creating a new ABI. New ABIs mean old tools won't work, and new tools need to understand both ABIs. -- error compiling committee.c: too many arguments to function ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 8/8] v2 Update memory hotplug documentation
On 09/27/2010 09:28 PM, Nathan Fontenot wrote: For example, assume 1GiB section size. A device for a memory starting at 0x1 is /sys/device/system/memory/memory4 (0x1 / 1Gib = 4) This device covers address range [0x1 ... 0x14000) -Under each section, you can see 4 files. +Under each section, you can see 5 files. Shouldn't this be, 4 or 5 files depending on kernel version? -- error compiling committee.c: too many arguments to function ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 3/3] mpc512x_dma: add MPC8308 support
Dear Ilya Yanok, In message 1285676696-5358-4-git-send-email-ya...@emcraft.com you wrote: MPC8308 has pretty much the same DMA controller as MPC5121 and this patch adds support for MPC8308 to the mpc512x_dma driver. Signed-off-by: Ilya Yanok ya...@emcraft.com Cc: Piotr Ziecik ko...@semihalf.com --- drivers/dma/Kconfig |2 +- drivers/dma/mpc512x_dma.c | 95 +--- 2 files changed, 72 insertions(+), 25 deletions(-) diff --git a/drivers/dma/Kconfig b/drivers/dma/Kconfig index 9520cf0..5c5e95b 100644 --- a/drivers/dma/Kconfig +++ b/drivers/dma/Kconfig @@ -100,7 +100,7 @@ config FSL_DMA config MPC512X_DMA tristate Freescale MPC512x built-in DMA engine support - depends on PPC_MPC512x + depends on PPC_MPC512x || PPC_MPC831x Is MPC831x correct here? My understanding is that MPC831x processors have yet other DMA cotnrollers, and we're on a MPC8308 here? Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de A little knowledge is a dangerous thing.- Doug Gwyn ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
powerpc kernel 2.6.35.6 crash with gianfar ethernet at full line rate traffic
Hi all, I have a serious problem with latest stable kernel (2.6.35.6) and gianfar ethernet driver. I'am using default SMP kernel configuration and MPC8572DS development board and also using an hardware packet generator. My test is ip forwarding between eth0 and eth1, and Hardware packet generator produces full duplex, full line rate traffic with random packet length and random payload . After 1.2 billion packet passed, kernel produces this bellow crash message. I have done same test with an intel quad core pc and sky2 gigabit ethernet controller. No errors occured yet. So that it seems that this problem may be related with gianfar. Any comment and help are appreciated. Thanks. Emre [ cut here ] kernel BUG at net/core/skbuff.c:127! Oops: Exception in kernel mode, sig: 5 [#1] SMP NR_CPUS=8 MPC8572 DS last sysfs file: /sys/devices/pci0002:03/0002:03:00.0/subsystem_device Modules linked in: NIP: c0255260 LR: c0255260 CTR: c0221f64 REGS: effebd70 TRAP: 0700 Not tainted (2.6.35.6) MSR: 00029000 EE,ME,CE CR: 24028022 XER: 2000 TASK = ef03ce10[3] 'ksoftirqd/0' THREAD: ef04a000 CPU: 0 GPR00: c0255260 effebe20 ef03ce10 007c 00021000 c0225ac0 c04364cc GPR08: c042e9ac c04364e0 effea000 c043 20028048 1001a108 ef55 ef0f6d70 GPR16: ef0f6e18 ef0f685c ef550800 0008 0001 ef0f6800 003f GPR24: ef141a80 ef0f6b60 ef550950 ef0f6b60 0420 ef3f0400 ef525600 NIP [c0255260] skb_put+0x8c/0x94 LR [c0255260] skb_put+0x8c/0x94 Call Trace: [effebe20] [c0255260] skb_put+0x8c/0x94 (unreliable) [effebe30] [c023e004] gfar_clean_rx_ring+0x10c/0x4d8 [effebe90] [c023e794] gfar_poll+0x3c4/0x5f4 [effebf60] [c0262498] net_rx_action+0xf8/0x1a4 [effebfa0] [c0049dcc] __do_softirq+0xe0/0x178 [effebff0] [c0010790] call_do_softirq+0x14/0x24 [ef04bf50] [c0004868] do_softirq+0x90/0xa0 [ef04bf70] [c004a98c] run_ksoftirqd+0xb4/0x164 [ef04bfb0] [c005dacc] kthread+0x78/0x7c [ef04bff0] [c0010b9c] kernel_thread+0x4c/0x68 Instruction dump: 81030098 2f80 409e000c 3d20c03d 3809e0d8 3c60c03d 7c8802a6 7d695b78 3863ee60 90010008 4cc63182 4bdefaa9 0fe0 4800 9421fff0 7c0802a6 Kernel panic - not syncing: Fatal exception in interrupt Call Trace: [effebb20] [c00082fc] show_stack+0x4c/0x180 (unreliable) [effebb50] [c0043720] panic+0xa0/0x11c [effebbe0] [c000db44] die+0x184/0x1d0 [effebc10] [c000dcfc] _exception+0x114/0x130 [effebd60] [c0011440] ret_from_except_full+0x0/0x4c --- Exception: 700 at skb_put+0x8c/0x94 LR = skb_put+0x8c/0x94 [effebe30] [c023e004] gfar_clean_rx_ring+0x10c/0x4d8 [effebe90] [c023e794] gfar_poll+0x3c4/0x5f4 [effebf60] [c0262498] net_rx_action+0xf8/0x1a4 [effebfa0] [c0049dcc] __do_softirq+0xe0/0x178 [effebff0] [c0010790] call_do_softirq+0x14/0x24 [ef04bf50] [c0004868] do_softirq+0x90/0xa0 [ef04bf70] [c004a98c] run_ksoftirqd+0xb4/0x164 [ef04bfb0] [c005dacc] kthread+0x78/0x7c [ef04bff0] [c0010b9c] kernel_thread+0x4c/0x68 Rebooting in 180 seconds.. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Doubt about Linux PCIe infraestructure
Carlos Roberto Moratelli wrote: When I register a PCI driver using pci_register_driver() will the probe function be automatically called or will it just be called if PCI infraestructure match a Vendor and Device id on bus? Yes, vendor and device id must match. You can find those in lspci. Micha ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Doubt about Linux PCIe infraestructure
Hi,
I have a simple doubt about linux PCI/PCIe infraestructure.
When I register a PCI driver using pci_register_driver() will the
probe function be automatically called or will it just be called if PCI
infraestructure match a Vendor and Device id on bus?
When you register your driver, you supply a list of VID/DID pairs for
which your driver is applicable, and if those devices are on the bus, your
probe will be called.
I am loading a PCI driver that register itself using
pci_register_driver() but the probe function isn't called.
If you didn't indicate your driver was for the VID/DID of the device, your
probe won't be called - why should it? As far as you told the kernel,
there's no hardware pertaining to your driver.
The old days of every driver probes every device are gone.
Here's an example code fragment:
/* define the list of devices we support */
static struct pci_device_id ppc_ep_device_ids[] =
{
{PCI_DEVICE(PCI_VENDOR_ID_FREESCALE,PCI_DEVICE_ID_MPC8641D)},
{0} /* end of list indicator */
};
MODULE_DEVICE_TABLE(pci, ppc_ep_device_ids); /* tell udev to load our
module for these devices */
pci_register_driver(ppc_ep_device_driver); /* tell the kernel we handle
these devices */
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Parsing a bus fault message?
I finally found my problems accessing the PPC OWBAR registers as an endpoint (copy/paste brown paper bag bug on my part), but I still get a bus fault trying to access the device. The problem is that I don't know if the fault is internal to the PPC (e.g. I don't have something in the chip set up) or if the fault is happening on the PCIe side of things. Are there any good how-tos on interpreting the kernel machine check error for the PPC, that might help me know where to look for the problem? Alternatively, can somebody see a hint in the message that I don't know enough to pick out? At this point, my code is trying to memcpy() from the PCIe bus (mapped via the outbound ATMU) to local memory, so the fault is either a) the ATMU is not accessible b) the ATMU is accessible but not mapped (which I would have thought the ioremap call I made would have handled) or c) the chip is not able to bus master on the PCI bus. Machine check in kernel mode. Caused by (from SRR1=149030): Transfer error ack signal Oops: Machine check, sig: 7 [#1] SMP NR_CPUS=2 EP8641A Modules linked in: Endpoint_driver rionetlink NIP: c0014e80 LR: f102d434 CTR: 0200 REGS: ef05fdf0 TRAP: 0200 Not tainted (2.6.26.2-ep1.10) MSR: 00149030 EE,ME,IR,DR CR: 24004482 XER: TASK = ef05b310[76] 'cat' THREAD: ef05e000 CPU: 0 GPR00: ef05fea0 ef05b310 eed06000 f14dfffc 1000 eed05ffc 8000 GPR08: 1000 c0014e60 1000 100a7264 0100 0001 GPR16: 004005b4 007fff00 c029 c02f ef05ff20 bfba5978 eed06000 GPR24: eed14ce0 ef02c678 eed61910 efb8d4b0 fffb 1000 NIP [c0014e80] memcpy+0x20/0x9c LR [f102d434] Endpoint_atmu_read+0x4c/0x90 [Endpoint_driver] Call Trace: [ef05fea0] [ef05609c] 0xef05609c (unreliable) [ef05feb0] [c00cf2c0] read+0xd8/0x1c8 [ef05fef0] [c007ff40] vfs_read+0xcc/0x16c [ef05ff10] [c008074c] sys_read+0x4c/0x90 [ef05ff40] [c0011174] ret_from_syscall+0x0/0x38 --- Exception: c01 at 0xff697f0 LR = 0x10007008 Instruction dump: 4200fff0 4e800020 7c032040 418100a0 54a7e8ff 38c3fffc 3884fffc 41820028 70c3 7ce903a6 40820054 80e40004 85040008 90e60004 95060008 4200fff0 ---[ end trace e0620da52f69882d ]--- ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 3/3] mpc512x_dma: add MPC8308 support
Dear Wolfgang, 28.09.2010 17:09, Wolfgang Denk wrote: config MPC512X_DMA tristate Freescale MPC512x built-in DMA engine support - depends on PPC_MPC512x + depends on PPC_MPC512x || PPC_MPC831x Is MPC831x correct here? My understanding is that MPC831x processors have yet other DMA cotnrollers, and we're on a MPC8308 here? Well, PPC_MPC831x is not correct here in the strict sense, but there are some reasons for it: 1. We don't really have PPC_MPC8308 config option for MPC8308 processor. Well, maybe that was my fault that I didn't add it when I initially introduced support for MPC8308. But I don't actually see the point for it. All the differencies from MPC831x are handled run-time based on device-tree. 2. Some of MPC831x (I believe it's MPC8315) really has the compatible DMA controller (it's called something like DMA controller of the TDM module). Well it will probably need some additional work in the driver to support this controller but hardware is mostly the same. 3. Well, it's only compilation option you need a proper device-tree node for the driver to start. Ok, you can make your kernel bigger by compiling in the driver which is useless for your CPU but you can't break it provided you have a correct device-tree. Regards, Ilya. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] powerpc: cell: Fix axion_msi irq shutdown
Calling unmask_msi_irq on irq shutdown is at least suboptimal.
Use mask_msi_irq instead.
Signed-off-by: Thomas Gleixner t...@linutronix.de
---
arch/powerpc/platforms/cell/axon_msi.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Index: linux-2.6/arch/powerpc/platforms/cell/axon_msi.c
===
--- linux-2.6.orig/arch/powerpc/platforms/cell/axon_msi.c
+++ linux-2.6/arch/powerpc/platforms/cell/axon_msi.c
@@ -312,7 +312,7 @@ static void axon_msi_teardown_msi_irqs(s
static struct irq_chip msic_irq_chip = {
.mask = mask_msi_irq,
.unmask = unmask_msi_irq,
- .shutdown = unmask_msi_irq,
+ .shutdown = mask_msi_irq,
.name = AXON-MSI,
};
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 0/8] v2 De-Couple sysfs memory directories from memory sections
On Tue, Sep 28, 2010 at 02:44:40PM +0200, Avi Kivity wrote: On 09/27/2010 09:09 PM, Nathan Fontenot wrote: This set of patches decouples the concept that a single memory section corresponds to a single directory in /sys/devices/system/memory/. On systems with large amounts of memory (1+ TB) there are perfomance issues related to creating the large number of sysfs directories. For a powerpc machine with 1 TB of memory we are creating 63,000+ directories. This is resulting in boot times of around 45-50 minutes for systems with 1 TB of memory and 8 hours for systems with 2 TB of memory. With this patch set applied I am now seeing boot times of 5 minutes or less. The root of this issue is in sysfs directory creation. Every time a directory is created a string compare is done against all sibling directories to ensure we do not create duplicates. The list of directory nodes in sysfs is kept as an unsorted list which results in this being an exponentially longer operation as the number of directories are created. The solution solved by this patch set is to allow a single directory in sysfs to span multiple memory sections. This is controlled by an optional architecturally defined function memory_block_size_bytes(). The default definition of this routine returns a memory block size equal to the memory section size. This maintains the current layout of sysfs memory directories as it appears to userspace to remain the same as it is today. Why not update sysfs directory creation to be fast, for example by using an rbtree instead of a linked list. This fixes an implementation problem in the kernel instead of working around it and creating a new ABI. Because the old ABI creates 129,000+ entries inside /sys/devices/system/memory with their associated links from /sys/devices/system/node/node*/ back to those directory entries. Thankfully things like rpm, hald, and other miscellaneous commands scan that information. On our 8 TB test machine, hald runs continuously following boot for nearly an hour mostly scanning useless information from /sys/ Robin New ABIs mean old tools won't work, and new tools need to understand both ABIs. -- error compiling committee.c: too many arguments to function -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] powerpc: cell: Fix axion_msi irq shutdown
On Tuesday 28 September 2010, Thomas Gleixner wrote: Calling unmask_msi_irq on irq shutdown is at least suboptimal. Use mask_msi_irq instead. Signed-off-by: Thomas Gleixner t...@linutronix.de Acked-by: Arnd Bergmann a...@arndb.de ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 0/8] v2 De-Couple sysfs memory directories from memory sections
On Tue, 2010-09-28 at 14:44 +0200, Avi Kivity wrote: Why not update sysfs directory creation to be fast, for example by using an rbtree instead of a linked list. This fixes an implementation problem in the kernel instead of working around it and creating a new ABI. New ABIs mean old tools won't work, and new tools need to understand both ABIs. Just to be clear _these_ patches do not change the existing ABI. They do add a new ABI: the end_phys_index file. But, it is completely redundant at the moment. It could be taken out of these patches. That said, fixing the directory creation speed is probably a worthwhile endeavor too. -- Dave ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 6/8] v2 Update node sysfs code
On Tue, 2010-09-28 at 04:29 -0500, Robin Holt wrote: Also, I don't think I much care for the weirdness that occurs if a memory block spans two nodes. I have not thought through how possible (or likely) this is, but the code certainly permits it. If that were the case, how would we know which sections need to be taken offline, etc? Since the architecture is the one doing the memory_block_size_bytes() override, I'd expect that the per-arch code knows enough to ensure that this doesn't happen. It's probably something to add to the documentation or the patch descriptions. How should an architecture define this? When should it be overridden? It's just like the question of SECTION_SIZE. What if a section spans a node? Well, they don't because the sections are a software concept and we _define_ them to not be able to cross nodes. If they do, just make them smaller. -- Dave ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Parsing a bus fault message?
On Tue, Sep 28, 2010 at 09:26:51AM -0500, david.hag...@gmail.com wrote: I finally found my problems accessing the PPC OWBAR registers as an endpoint (copy/paste brown paper bag bug on my part), but I still get a bus fault trying to access the device. The problem is that I don't know if the fault is internal to the PPC (e.g. I don't have something in the chip set up) or if the fault is happening on the PCIe side of things. Are there any good how-tos on interpreting the kernel machine check error for the PPC, that might help me know where to look for the problem? Alternatively, can somebody see a hint in the message that I don't know enough to pick out? At this point, my code is trying to memcpy() from the PCIe bus (mapped via the outbound ATMU) to local memory, so the fault is either a) the ATMU is not accessible b) the ATMU is accessible but not mapped (which I would have thought the ioremap call I made would have handled) or c) the chip is not able to bus master on the PCI bus. Machine check in kernel mode. Caused by (from SRR1=149030): Transfer error ack signal ^^^ this is the line that contains some critical info In the 86xx CPU manual, you should be able to find information about the SRR1 register. Decoding the hex SRR1=0x149030 may help. The kernel is telling you this is a TEA (transfer error acknowledge) error. I've only seen this when I get an unhandled timeout on the local bus. For example, a FPGA that has died in the middle of a request. On the PCI bus, I haven't seen this error. The 83xx PCI controller is smart enough to return 0x when reading a non-existent device. I'm only familiar with 83xx, so I can't help too much on an 86xx board. My best advice is: check your addresses. Make sure they're correct. I assume that PCI on 86xx behaves similarly to 83xx. If you read from an outbound window, your access gets translated into a PCI address and goes onto the PCI bus. A good way of testing this is with the devmem utility (part of busybox). It allows you to read/write any physical memory location. Using devmem will help you determine if the problem is in your code or in your setup procedure. I hope it helps, Ira Oops: Machine check, sig: 7 [#1] SMP NR_CPUS=2 EP8641A Modules linked in: Endpoint_driver rionetlink NIP: c0014e80 LR: f102d434 CTR: 0200 REGS: ef05fdf0 TRAP: 0200 Not tainted (2.6.26.2-ep1.10) MSR: 00149030 EE,ME,IR,DR CR: 24004482 XER: TASK = ef05b310[76] 'cat' THREAD: ef05e000 CPU: 0 GPR00: ef05fea0 ef05b310 eed06000 f14dfffc 1000 eed05ffc 8000 GPR08: 1000 c0014e60 1000 100a7264 0100 0001 GPR16: 004005b4 007fff00 c029 c02f ef05ff20 bfba5978 eed06000 GPR24: eed14ce0 ef02c678 eed61910 efb8d4b0 fffb 1000 NIP [c0014e80] memcpy+0x20/0x9c LR [f102d434] Endpoint_atmu_read+0x4c/0x90 [Endpoint_driver] Call Trace: [ef05fea0] [ef05609c] 0xef05609c (unreliable) [ef05feb0] [c00cf2c0] read+0xd8/0x1c8 [ef05fef0] [c007ff40] vfs_read+0xcc/0x16c [ef05ff10] [c008074c] sys_read+0x4c/0x90 [ef05ff40] [c0011174] ret_from_syscall+0x0/0x38 --- Exception: c01 at 0xff697f0 LR = 0x10007008 Instruction dump: 4200fff0 4e800020 7c032040 418100a0 54a7e8ff 38c3fffc 3884fffc 41820028 70c3 7ce903a6 40820054 80e40004 85040008 90e60004 95060008 4200fff0 ---[ end trace e0620da52f69882d ]--- ___ 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
Re: [PATCH 0/8] v2 De-Couple sysfs memory directories from memory sections
On 09/28/2010 05:12 PM, Robin Holt wrote: Why not update sysfs directory creation to be fast, for example by using an rbtree instead of a linked list. This fixes an implementation problem in the kernel instead of working around it and creating a new ABI. Because the old ABI creates 129,000+ entries inside /sys/devices/system/memory with their associated links from /sys/devices/system/node/node*/ back to those directory entries. Thankfully things like rpm, hald, and other miscellaneous commands scan that information. On our 8 TB test machine, hald runs continuously following boot for nearly an hour mostly scanning useless information from /sys/ I see - so the problem wasn't just kernel internal; the ABI itself was unsuitable. Too bad this wasn't considered at the time it was added. (129k entries / 1 hour = 35 entries/sec; not very impressive) -- error compiling committee.c: too many arguments to function ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 1/1 v2 ] Add kernel parameter to disable batched hcalls
This introduces a pair of kernel parameters that can be used to disable
the MULTITCE and BULK_REMOVE h-calls.
By default, those hcalls are enabled, active, and good for throughput
and performance. The ability to disable them will be useful for some of
the PREEMPT_RT related investigation and work occurring on Power.
Signed-off-by: Will Schmidt will_schm...@vnet.ibm.com
cc: Olof Johansson o...@lixom.net
cc: Anton Blanchard an...@samba.org
cc: Benjamin Herrenschmidt b...@kernel.crashing.org
---
v2 - Per feedback from Olof, the code is reworked to utilize kernel
parameter runtime checks, rather than CONFIG options.
- Added relevant change to kernel-parameters.txt
diff --git a/Documentation/kernel-parameters.txt
b/Documentation/kernel-parameters.txt
index e2c7487..5c40801 100644
--- a/Documentation/kernel-parameters.txt
+++ b/Documentation/kernel-parameters.txt
@@ -426,6 +426,10 @@ and is between 256 and 4096 characters. It is defined in
the file
bttv.pll= See Documentation/video4linux/bttv/Insmod-options
bttv.tuner= and Documentation/video4linux/bttv/CARDLIST
+ bulk_remove=off [PPC] This parameter disables the use of the pSeries
+ firmware feature for flushing multiple hpte entries
+ at a time.
+
BusLogic= [HW,SCSI]
See drivers/scsi/BusLogic.c, comment before function
BusLogic_ParseDriverOptions().
@@ -1499,6 +1503,10 @@ and is between 256 and 4096 characters. It is defined in
the file
mtdparts= [MTD]
See drivers/mtd/cmdlinepart.c.
+ multitce=off[PPC] This parameter disables the use of the pSeries
+ firmware feature for updating multiple TCE entries
+ at a time.
+
onenand.bdry= [HW,MTD] Flex-OneNAND Boundary Configuration
Format:
[die0_boundary][,die0_lock][,die1_boundary][,die1_lock]
diff --git a/arch/powerpc/platforms/pseries/iommu.c
b/arch/powerpc/platforms/pseries/iommu.c
index 902987d..e174a2f 100644
--- a/arch/powerpc/platforms/pseries/iommu.c
+++ b/arch/powerpc/platforms/pseries/iommu.c
@@ -625,3 +625,19 @@ void iommu_init_early_pSeries(void)
set_pci_dma_ops(dma_iommu_ops);
}
+static int __init disable_multitce(char *str)
+{
+ if (strcmp(str,off)==0) {
+ if (firmware_has_feature(FW_FEATURE_LPAR)) {
+ if (firmware_has_feature(FW_FEATURE_MULTITCE)) {
+ printk(KERN_INFO Disabling MULTITCE firmware
feature\n);
+ ppc_md.tce_build = tce_build_pSeriesLP;
+ ppc_md.tce_free = tce_free_pSeriesLP;
+ powerpc_firmware_features =
~FW_FEATURE_MULTITCE;
+ }
+ }
+ }
+ return 1;
+}
+
+__setup(multitce=,disable_multitce);
diff --git a/arch/powerpc/platforms/pseries/lpar.c
b/arch/powerpc/platforms/pseries/lpar.c
index 0707653..82d15e7 100644
--- a/arch/powerpc/platforms/pseries/lpar.c
+++ b/arch/powerpc/platforms/pseries/lpar.c
@@ -599,6 +599,19 @@ static void pSeries_lpar_flush_hash_range(unsigned long
number, int local)
spin_unlock_irqrestore(pSeries_lpar_tlbie_lock, flags);
}
+static int __init disable_bulk_remove(char *str)
+{
+ if (strcmp(str,off)==0) {
+ if (firmware_has_feature(FW_FEATURE_BULK_REMOVE)) {
+ printk(KERN_INFO Disabling BULK_REMOVE firmware
feature);
+ powerpc_firmware_features = ~FW_FEATURE_BULK_REMOVE;
+ }
+ }
+ return 1;
+}
+
+__setup(bulk_remove=,disable_bulk_remove);
+
void __init hpte_init_lpar(void)
{
ppc_md.hpte_invalidate = pSeries_lpar_hpte_invalidate;
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 1/1 v2 ] Add kernel parameter to disable batched hcalls
Nice. I've got minor nits below, and you might also want to run the patch
through checkpatch and fix up some of the whitespace warnings.
-Olof
On Tue, Sep 28, 2010 at 12:02:51PM -0500, Will Schmidt wrote:
This introduces a pair of kernel parameters that can be used to disable
the MULTITCE and BULK_REMOVE h-calls.
By default, those hcalls are enabled, active, and good for throughput
and performance. The ability to disable them will be useful for some of
the PREEMPT_RT related investigation and work occurring on Power.
Signed-off-by: Will Schmidt will_schm...@vnet.ibm.com
cc: Olof Johansson o...@lixom.net
cc: Anton Blanchard an...@samba.org
cc: Benjamin Herrenschmidt b...@kernel.crashing.org
---
v2 - Per feedback from Olof, the code is reworked to utilize kernel
parameter runtime checks, rather than CONFIG options.
- Added relevant change to kernel-parameters.txt
diff --git a/Documentation/kernel-parameters.txt
b/Documentation/kernel-parameters.txt
index e2c7487..5c40801 100644
--- a/Documentation/kernel-parameters.txt
+++ b/Documentation/kernel-parameters.txt
@@ -426,6 +426,10 @@ and is between 256 and 4096 characters. It is defined in
the file
bttv.pll= See Documentation/video4linux/bttv/Insmod-options
bttv.tuner= and Documentation/video4linux/bttv/CARDLIST
+ bulk_remove=off [PPC] This parameter disables the use of the pSeries
+ firmware feature for flushing multiple hpte entries
+ at a time.
+
BusLogic= [HW,SCSI]
See drivers/scsi/BusLogic.c, comment before function
BusLogic_ParseDriverOptions().
@@ -1499,6 +1503,10 @@ and is between 256 and 4096 characters. It is defined
in the file
mtdparts= [MTD]
See drivers/mtd/cmdlinepart.c.
+ multitce=off[PPC] This parameter disables the use of the pSeries
+ firmware feature for updating multiple TCE entries
+ at a time.
+
onenand.bdry= [HW,MTD] Flex-OneNAND Boundary Configuration
Format:
[die0_boundary][,die0_lock][,die1_boundary][,die1_lock]
diff --git a/arch/powerpc/platforms/pseries/iommu.c
b/arch/powerpc/platforms/pseries/iommu.c
index 902987d..e174a2f 100644
--- a/arch/powerpc/platforms/pseries/iommu.c
+++ b/arch/powerpc/platforms/pseries/iommu.c
@@ -625,3 +625,19 @@ void iommu_init_early_pSeries(void)
set_pci_dma_ops(dma_iommu_ops);
}
+static int __init disable_multitce(char *str)
+{
+ if (strcmp(str,off)==0) {
+ if (firmware_has_feature(FW_FEATURE_LPAR)) {
+ if (firmware_has_feature(FW_FEATURE_MULTITCE)) {
+ printk(KERN_INFO Disabling MULTITCE firmware
feature\n);
+ ppc_md.tce_build = tce_build_pSeriesLP;
+ ppc_md.tce_free = tce_free_pSeriesLP;
+ powerpc_firmware_features =
~FW_FEATURE_MULTITCE;
+ }
+ }
+ }
I personally prefer to keep cases like these in one if statement to save
indentation:
if (strcmp(str, off) == 0
firmware_has_feature(FW_FEATURE_LPAR)
firmware_has_feature(FW_FEATURE_MULTITCE)) {
...
}
+ return 1;
+}
+
+__setup(multitce=,disable_multitce);
diff --git a/arch/powerpc/platforms/pseries/lpar.c
b/arch/powerpc/platforms/pseries/lpar.c
index 0707653..82d15e7 100644
--- a/arch/powerpc/platforms/pseries/lpar.c
+++ b/arch/powerpc/platforms/pseries/lpar.c
@@ -599,6 +599,19 @@ static void pSeries_lpar_flush_hash_range(unsigned long
number, int local)
spin_unlock_irqrestore(pSeries_lpar_tlbie_lock, flags);
}
+static int __init disable_bulk_remove(char *str)
+{
+ if (strcmp(str,off)==0) {
+ if (firmware_has_feature(FW_FEATURE_BULK_REMOVE)) {
+ printk(KERN_INFO Disabling BULK_REMOVE firmware
feature);
+ powerpc_firmware_features = ~FW_FEATURE_BULK_REMOVE;
+ }
+ }
Same here.
+ return 1;
+}
+
+__setup(bulk_remove=,disable_bulk_remove);
+
void __init hpte_init_lpar(void)
{
ppc_md.hpte_invalidate = pSeries_lpar_hpte_invalidate;
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 4/8] v2 Allow memory block to span multiple memory sections
On 09/27/2010 06:55 PM, Dave Hansen wrote:
On Mon, 2010-09-27 at 14:25 -0500, Nathan Fontenot wrote:
+static inline int base_memory_block_id(int section_nr)
+{
+ return section_nr / sections_per_block;
+}
...
- mutex_lock(mem_sysfs_mutex);
-
- mem-phys_index = __section_nr(section);
+ scn_nr = __section_nr(section);
+ mem-phys_index = base_memory_block_id(scn_nr) * sections_per_block;
I'm really regretting giving this variable such a horrid name. I suck.
I think this is correct now:
mem-phys_index = base_memory_block_id(scn_nr) * sections_per_block;
mem-phys_index = section_nr / sections_per_block * sections_per_block;
mem-phys_index = section_nr
Since it gets exported to userspace this way:
+static ssize_t show_mem_start_phys_index(struct sys_device *dev,
struct sysdev_attribute *attr, char *buf)
{
struct memory_block *mem =
container_of(dev, struct memory_block, sysdev);
- return sprintf(buf, %08lx\n, mem-phys_index / sections_per_block);
+ unsigned long phys_index;
+
+ phys_index = mem-start_phys_index / sections_per_block;
+ return sprintf(buf, %08lx\n, phys_index);
+}
The only other thing I'd say is that we need to put phys_index out of
its misery and call it what it is now: a section number. I think it's
OK to call them start/end_section_nr, at least inside the kernel. I
intentionally used phys_index terminology in sysfs so that we _could_
eventually do this stuff and break the relationship between sections and
the sysfs dirs, but I think keeping the terminology around inside the
kernel is confusing now.
Yes, it took me a couple o looks to get the phys_index - section number
correlation. I think changing the kernel names to start/end_section_number
is a good idea.
-Nathan
-- Dave
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 2/8] v2 Add section count to memory_block struct
On 09/28/2010 04:31 AM, Robin Holt wrote:
In the next patch, you introduce a mutex for adding/removing memory blocks.
Is there really a need for this to be atomic? If you reorder the patches
so the mutex comes first, would the atomic be needed any longer?
I think you're right. Looking at the code with all patches applied I am only
updating the atomic when holding the mem_sysfs_mutex. I think the atomic
could safely be changed to a regular int.
-Nathan
Robin
On Mon, Sep 27, 2010 at 02:22:24PM -0500, Nathan Fontenot wrote:
Add a section count property to the memory_block struct to track the number
of memory sections that have been added/removed from a memory block. This
allows us to know when the last memory section of a memory block has been
removed so we can remove the memory block.
Signed-off-by: Nathan Fontenot nf...@austin.ibm.com
---
drivers/base/memory.c | 16 ++--
include/linux/memory.h |3 +++
2 files changed, 13 insertions(+), 6 deletions(-)
Index: linux-next/drivers/base/memory.c
===
--- linux-next.orig/drivers/base/memory.c2010-09-27 09:17:20.0
-0500
+++ linux-next/drivers/base/memory.c 2010-09-27 09:31:35.0 -0500
@@ -478,6 +478,7 @@
mem-phys_index = __section_nr(section);
mem-state = state;
+atomic_inc(mem-section_count);
mutex_init(mem-state_mutex);
start_pfn = section_nr_to_pfn(mem-phys_index);
mem-phys_device = arch_get_memory_phys_device(start_pfn);
@@ -505,12 +506,15 @@
struct memory_block *mem;
mem = find_memory_block(section);
-unregister_mem_sect_under_nodes(mem);
-mem_remove_simple_file(mem, phys_index);
-mem_remove_simple_file(mem, state);
-mem_remove_simple_file(mem, phys_device);
-mem_remove_simple_file(mem, removable);
-unregister_memory(mem, section);
+
+if (atomic_dec_and_test(mem-section_count)) {
+unregister_mem_sect_under_nodes(mem);
+mem_remove_simple_file(mem, phys_index);
+mem_remove_simple_file(mem, state);
+mem_remove_simple_file(mem, phys_device);
+mem_remove_simple_file(mem, removable);
+unregister_memory(mem, section);
+}
return 0;
}
Index: linux-next/include/linux/memory.h
===
--- linux-next.orig/include/linux/memory.h 2010-09-27 09:17:20.0
-0500
+++ linux-next/include/linux/memory.h2010-09-27 09:22:56.0
-0500
@@ -19,10 +19,13 @@
#include linux/node.h
#include linux/compiler.h
#include linux/mutex.h
+#include asm/atomic.h
struct memory_block {
unsigned long phys_index;
unsigned long state;
+atomic_t section_count;
+
/*
* This serializes all state change requests. It isn't
* held during creation because the control files are
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 0/8] v2 De-Couple sysfs memory directories from memory sections
On 09/28/2010 07:38 AM, Robin Holt wrote: I was tasked with looking at a slowdown in similar sized SGI machines booting x86_64. Jack Steiner had already looked into the memory_dev_init. I was looking at link_mem_sections(). I made a dramatic improvement on a 16TB machine in that function by merely caching the most recent memory section and checking to see if the next memory section happens to be the subsequent in the linked list of kobjects. That simple cache reduced the time for link_mem_sections from 1 hour 27 minutes down to 46 seconds. Nice! I would like to propose we implement something along those lines also, but I am currently swamped. I can probably get you a patch tomorrow afternoon that applies at the end of this set. Should this be done as a separate patch? This patch set concentrates on updates to the memory code with the node updates only being done due to the memory changes. I think its a good idea to do the caching and have no problem adding on to this patchset if no one else has any objections. -Nathan Thanks, Robin On Mon, Sep 27, 2010 at 02:09:31PM -0500, Nathan Fontenot wrote: This set of patches decouples the concept that a single memory section corresponds to a single directory in /sys/devices/system/memory/. On systems with large amounts of memory (1+ TB) there are perfomance issues related to creating the large number of sysfs directories. For a powerpc machine with 1 TB of memory we are creating 63,000+ directories. This is resulting in boot times of around 45-50 minutes for systems with 1 TB of memory and 8 hours for systems with 2 TB of memory. With this patch set applied I am now seeing boot times of 5 minutes or less. The root of this issue is in sysfs directory creation. Every time a directory is created a string compare is done against all sibling directories to ensure we do not create duplicates. The list of directory nodes in sysfs is kept as an unsorted list which results in this being an exponentially longer operation as the number of directories are created. The solution solved by this patch set is to allow a single directory in sysfs to span multiple memory sections. This is controlled by an optional architecturally defined function memory_block_size_bytes(). The default definition of this routine returns a memory block size equal to the memory section size. This maintains the current layout of sysfs memory directories as it appears to userspace to remain the same as it is today. For architectures that define their own version of this routine, as is done for powerpc in this patchset, the view in userspace would change such that each memoryXXX directory would span multiple memory sections. The number of sections spanned would depend on the value reported by memory_block_size_bytes. In both cases a new file 'end_phys_index' is created in each memoryXXX directory. This file will contain the physical id of the last memory section covered by the sysfs directory. For the default case, the value in 'end_phys_index' will be the same as in the existing 'phys_index' file. This version of the patch set includes an update to to properly report block_size_bytes, phys_index, and end_phys_index. Additionally, the patch that adds the end_phys_index sysfs file is now patch 5/8 instead of being patch 2/8 as in the previous version of the patches. -Nathan Fontenot -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 8/8] v2 Update memory hotplug documentation
On 09/28/2010 07:45 AM, Avi Kivity wrote: On 09/27/2010 09:28 PM, Nathan Fontenot wrote: For example, assume 1GiB section size. A device for a memory starting at 0x1 is /sys/device/system/memory/memory4 (0x1 / 1Gib = 4) This device covers address range [0x1 ... 0x14000) -Under each section, you can see 4 files. +Under each section, you can see 5 files. Shouldn't this be, 4 or 5 files depending on kernel version? Correct, I'll update this. Thanks. -Nathan ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 4/8] v2 Allow memory block to span multiple memory sections
On 09/28/2010 07:48 AM, Robin Holt wrote:
+u32 __weak memory_block_size_bytes(void)
+{
+return MIN_MEMORY_BLOCK_SIZE;
+}
+
+static u32 get_memory_block_size(void)
Can we make this an unsigned long? We are testing on a system whose
smallest possible configuration is 4GB per socket with 512 sockets.
We would like to be able to specify this as 2GB by default (results
in the least lost memory) and suggest we add a command line option
which overrides this value. We have many installations where 16GB may
be optimal. Large configurations will certainly become more prevalent.
Works for me.
...
@@ -551,12 +608,16 @@
unsigned int i;
int ret;
int err;
+int block_sz;
This one needs to match the return above. In our tests, we ended up
with a negative sections_per_block which caused very unexpected results.
Oh, nice catch. I'll update both of these.
-Nathan
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Parsing a bus fault message?
On Tue, 28 Sep 2010 08:31:54 -0700 Ira W. Snyder i...@ovro.caltech.edu wrote: On Tue, Sep 28, 2010 at 09:26:51AM -0500, david.hag...@gmail.com wrote: Alternatively, can somebody see a hint in the message that I don't know enough to pick out? At this point, my code is trying to memcpy() from the PCIe bus (mapped via the outbound ATMU) to local memory, so the fault is either a) the ATMU is not accessible b) the ATMU is accessible but not mapped (which I would have thought the ioremap call I made would have handled) or c) the chip is not able to bus master on the PCI bus. Check the LAWs, the outbound ATMU, and the PCI device's BAR. Make sure the address goes where you're expecting at each level. Machine check in kernel mode. Caused by (from SRR1=149030): Transfer error ack signal ^^^ this is the line that contains some critical info In the 86xx CPU manual, you should be able to find information about the SRR1 register. Decoding the hex SRR1=0x149030 may help. The kernel is telling you this is a TEA (transfer error acknowledge) error. I've only seen this when I get an unhandled timeout on the local bus. For example, a FPGA that has died in the middle of a request. I've seen it when you access a physical address that has no device backing it up. On the PCI bus, I haven't seen this error. The 83xx PCI controller is smart enough to return 0x when reading a non-existent device. I believe that behavior is configurable. -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH v3 0/2] Add USB Host support for MPC5121 SoC
Version 3 of the patches to add MPC512x USB support in mainline kernel. USB OTG support is not included in this patch series, it will be submitted later. There are only two patches now: patches 1/3 and 2/3 of the previous version are merged into the first patch and now bisectable. Additionally the 2nd patch of the previous version is changed as requested by Grant. Please consider for inclusion in 2.6.37. Anatolij Gustschin (2): USB: add platform glue driver for FSL USB DR controller USB: add USB EHCI support for MPC5121 SoC Documentation/powerpc/dts-bindings/fsl/usb.txt | 22 ++ arch/powerpc/sysdev/fsl_soc.c | 163 - drivers/usb/Kconfig|1 + drivers/usb/gadget/Kconfig |1 + drivers/usb/host/Kconfig | 10 +- drivers/usb/host/Makefile |1 + drivers/usb/host/ehci-fsl.c| 99 ++--- drivers/usb/host/ehci-fsl.h| 13 +- drivers/usb/host/ehci-mem.c|2 +- drivers/usb/host/fsl-mph-dr-of.c | 308 include/linux/fsl_devices.h| 15 ++ 11 files changed, 440 insertions(+), 195 deletions(-) create mode 100644 drivers/usb/host/fsl-mph-dr-of.c ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH v3 1/2] USB: add platform glue driver for FSL USB DR controller
Replace FSL USB platform code by simple platform driver for
creation of FSL USB platform devices.
The driver creates platform devices based on the information
from USB nodes in the flat device tree. This is the replacement
for old arch fsl_soc usb code removed by this patch. The driver
uses usual of-style binding, available EHCI-HCD and UDC
drivers can be bound to the created devices. The new of-style
driver additionaly instantiates USB OTG platform device, as the
appropriate USB OTG driver will be added soon.
Signed-off-by: Anatolij Gustschin ag...@denx.de
Cc: Kumar Gala ga...@kernel.crashing.org
Cc: Grant Likely grant.lik...@secretlab.ca
---
v3:
- merged patches 1/3 and 2/3 of the previous version
- changed to platform_driver as requested
- fixed probe() to avoid modification of driver's
shared platform data struct pointed to by 'data' in
the match table which is added by the next patch of
the series
arch/powerpc/sysdev/fsl_soc.c| 163
drivers/usb/gadget/Kconfig |1 +
drivers/usb/host/Kconfig |4 +
drivers/usb/host/Makefile|1 +
drivers/usb/host/fsl-mph-dr-of.c | 219 ++
5 files changed, 225 insertions(+), 163 deletions(-)
create mode 100644 drivers/usb/host/fsl-mph-dr-of.c
diff --git a/arch/powerpc/sysdev/fsl_soc.c b/arch/powerpc/sysdev/fsl_soc.c
index b91f7ac..49a51f1 100644
--- a/arch/powerpc/sysdev/fsl_soc.c
+++ b/arch/powerpc/sysdev/fsl_soc.c
@@ -209,169 +209,6 @@ static int __init of_add_fixed_phys(void)
arch_initcall(of_add_fixed_phys);
#endif /* CONFIG_FIXED_PHY */
-static enum fsl_usb2_phy_modes determine_usb_phy(const char *phy_type)
-{
- if (!phy_type)
- return FSL_USB2_PHY_NONE;
- if (!strcasecmp(phy_type, ulpi))
- return FSL_USB2_PHY_ULPI;
- if (!strcasecmp(phy_type, utmi))
- return FSL_USB2_PHY_UTMI;
- if (!strcasecmp(phy_type, utmi_wide))
- return FSL_USB2_PHY_UTMI_WIDE;
- if (!strcasecmp(phy_type, serial))
- return FSL_USB2_PHY_SERIAL;
-
- return FSL_USB2_PHY_NONE;
-}
-
-static int __init fsl_usb_of_init(void)
-{
- struct device_node *np;
- unsigned int i = 0;
- struct platform_device *usb_dev_mph = NULL, *usb_dev_dr_host = NULL,
- *usb_dev_dr_client = NULL;
- int ret;
-
- for_each_compatible_node(np, NULL, fsl-usb2-mph) {
- struct resource r[2];
- struct fsl_usb2_platform_data usb_data;
- const unsigned char *prop = NULL;
-
- memset(r, 0, sizeof(r));
- memset(usb_data, 0, sizeof(usb_data));
-
- ret = of_address_to_resource(np, 0, r[0]);
- if (ret)
- goto err;
-
- of_irq_to_resource(np, 0, r[1]);
-
- usb_dev_mph =
- platform_device_register_simple(fsl-ehci, i, r, 2);
- if (IS_ERR(usb_dev_mph)) {
- ret = PTR_ERR(usb_dev_mph);
- goto err;
- }
-
- usb_dev_mph-dev.coherent_dma_mask = 0xUL;
- usb_dev_mph-dev.dma_mask = usb_dev_mph-dev.coherent_dma_mask;
-
- usb_data.operating_mode = FSL_USB2_MPH_HOST;
-
- prop = of_get_property(np, port0, NULL);
- if (prop)
- usb_data.port_enables |= FSL_USB2_PORT0_ENABLED;
-
- prop = of_get_property(np, port1, NULL);
- if (prop)
- usb_data.port_enables |= FSL_USB2_PORT1_ENABLED;
-
- prop = of_get_property(np, phy_type, NULL);
- usb_data.phy_mode = determine_usb_phy(prop);
-
- ret =
- platform_device_add_data(usb_dev_mph, usb_data,
-sizeof(struct
- fsl_usb2_platform_data));
- if (ret)
- goto unreg_mph;
- i++;
- }
-
- for_each_compatible_node(np, NULL, fsl-usb2-dr) {
- struct resource r[2];
- struct fsl_usb2_platform_data usb_data;
- const unsigned char *prop = NULL;
-
- if (!of_device_is_available(np))
- continue;
-
- memset(r, 0, sizeof(r));
- memset(usb_data, 0, sizeof(usb_data));
-
- ret = of_address_to_resource(np, 0, r[0]);
- if (ret)
- goto unreg_mph;
-
- of_irq_to_resource(np, 0, r[1]);
-
- prop = of_get_property(np, dr_mode, NULL);
-
- if (!prop || !strcmp(prop, host)) {
- usb_data.operating_mode = FSL_USB2_DR_HOST;
- usb_dev_dr_host = platform_device_register_simple(
- fsl-ehci, i, r, 2);
-
[PATCH v3 2/2] USB: add USB EHCI support for MPC5121 SoC
Extends FSL EHCI platform driver glue layer to support
MPC5121 USB controllers. MPC5121 Rev 2.0 silicon EHCI
registers are in big endian format. The appropriate flags
are set using the information in the platform data structure.
MPC83xx system interface registers are not available on
MPC512x, so the access to these registers is isolated in
MPC512x case. Furthermore the USB controller clocks
must be enabled before 512x register accesses which is
done by providing platform specific init callback.
The MPC512x internal USB PHY doesn't provide supply voltage.
For boards using different power switches allow specifying
DRVVBUS and PWR_FAULT signal polarity of the MPC5121 internal
PHY using fsl,invert-drvvbus and fsl,invert-pwr-fault
properties in the device tree USB nodes. Adds documentation
for this new device tree bindings.
Signed-off-by: Anatolij Gustschin ag...@denx.de
Cc: Grant Likely grant.lik...@secretlab.ca
---
v3:
- rebased after changing of_platform_driver to platform_driver
Documentation/powerpc/dts-bindings/fsl/usb.txt | 22 +
drivers/usb/Kconfig|1 +
drivers/usb/host/Kconfig |6 +-
drivers/usb/host/ehci-fsl.c| 99 +---
drivers/usb/host/ehci-fsl.h| 13 +++-
drivers/usb/host/ehci-mem.c|2 +-
drivers/usb/host/fsl-mph-dr-of.c | 89 +
include/linux/fsl_devices.h| 15
8 files changed, 215 insertions(+), 32 deletions(-)
diff --git a/Documentation/powerpc/dts-bindings/fsl/usb.txt
b/Documentation/powerpc/dts-bindings/fsl/usb.txt
index b001524..bd5723f 100644
--- a/Documentation/powerpc/dts-bindings/fsl/usb.txt
+++ b/Documentation/powerpc/dts-bindings/fsl/usb.txt
@@ -8,6 +8,7 @@ and additions :
Required properties :
- compatible : Should be fsl-usb2-mph for multi port host USB
controllers, or fsl-usb2-dr for dual role USB controllers
+ or fsl,mpc5121-usb2-dr for dual role USB controllers of MPC5121
- phy_type : For multi port host USB controllers, should be one of
ulpi, or serial. For dual role USB controllers, should be
one of ulpi, utmi, utmi_wide, or serial.
@@ -33,6 +34,12 @@ Recommended properties :
- interrupt-parent : the phandle for the interrupt controller that
services interrupts for this device.
+Optional properties :
+ - fsl,invert-drvvbus : boolean; for MPC5121 USB0 only. Indicates the
+ port power polarity of internal PHY signal DRVVBUS is inverted.
+ - fsl,invert-pwr-fault : boolean; for MPC5121 USB0 only. Indicates
+ the PWR_FAULT signal polarity is inverted.
+
Example multi port host USB controller device node :
u...@22000 {
compatible = fsl-usb2-mph;
@@ -57,3 +64,18 @@ Example dual role USB controller device node :
dr_mode = otg;
phy = ulpi;
};
+
+Example dual role USB controller device node for MPC5121ADS:
+
+ u...@4000 {
+ compatible = fsl,mpc5121-usb2-dr;
+ reg = 0x4000 0x1000;
+ #address-cells = 1;
+ #size-cells = 0;
+ interrupt-parent = ipic ;
+ interrupts = 44 0x8;
+ dr_mode = otg;
+ phy_type = utmi_wide;
+ fsl,invert-drvvbus;
+ fsl,invert-pwr-fault;
+ };
diff --git a/drivers/usb/Kconfig b/drivers/usb/Kconfig
index 4aa00e6..67eb377 100644
--- a/drivers/usb/Kconfig
+++ b/drivers/usb/Kconfig
@@ -59,6 +59,7 @@ config USB_ARCH_HAS_OHCI
config USB_ARCH_HAS_EHCI
boolean
default y if PPC_83xx
+ default y if PPC_MPC512x
default y if SOC_AU1200
default y if ARCH_IXP4XX
default y if ARCH_W90X900
diff --git a/drivers/usb/host/Kconfig b/drivers/usb/host/Kconfig
index f3a90b0..bf2e7d2 100644
--- a/drivers/usb/host/Kconfig
+++ b/drivers/usb/host/Kconfig
@@ -93,12 +93,14 @@ config USB_EHCI_TT_NEWSCHED
config USB_EHCI_BIG_ENDIAN_MMIO
bool
- depends on USB_EHCI_HCD (PPC_CELLEB || PPC_PS3 || 440EPX ||
ARCH_IXP4XX || XPS_USB_HCD_XILINX)
+ depends on USB_EHCI_HCD (PPC_CELLEB || PPC_PS3 || 440EPX ||
ARCH_IXP4XX || \
+ XPS_USB_HCD_XILINX || PPC_MPC512x)
default y
config USB_EHCI_BIG_ENDIAN_DESC
bool
- depends on USB_EHCI_HCD (440EPX || ARCH_IXP4XX || XPS_USB_HCD_XILINX)
+ depends on USB_EHCI_HCD (440EPX || ARCH_IXP4XX || XPS_USB_HCD_XILINX
|| \
+ PPC_MPC512x)
default y
config XPS_USB_HCD_XILINX
diff --git a/drivers/usb/host/ehci-fsl.c b/drivers/usb/host/ehci-fsl.c
index 8600317..86e4289 100644
--- a/drivers/usb/host/ehci-fsl.c
+++ b/drivers/usb/host/ehci-fsl.c
@@ -116,13 +116,33 @@ static int usb_hcd_fsl_probe(const struct hc_driver
*driver,
goto err3;
}
- /* Enable USB controller */
- temp = in_be32(hcd-regs + 0x500);
-
Re: [PATCH 1/1 v3] Add kernel parameter to disable batched hcalls
This introduces a pair of kernel parameters that can be used to disable
the MULTITCE and BULK_REMOVE h-calls.
By default, those hcalls are enabled, active, and good for throughput
and performance. The ability to disable them will be useful for some of
the PREEMPT_RT related investigation and work occurring on Power.
Signed-off-by: Will Schmidt will_schm...@vnet.ibm.com
cc: Olof Johansson o...@lixom.net
cc: Anton Blanchard an...@samba.org
cc: Benjamin Herrenschmidt b...@kernel.crashing.org
---
v2 - Per feedback from Olof, the code is reworked to utilize kernel
parameter runtime checks, rather than CONFIG options.
- Added relevant change to kernel-parameters.txt
v3 - ran through checkpatch and fixed whitespace issues.
- consolidated the if() staircases to save indentation.
diff --git a/Documentation/kernel-parameters.txt
b/Documentation/kernel-parameters.txt
index e2c7487..5c40801 100644
--- a/Documentation/kernel-parameters.txt
+++ b/Documentation/kernel-parameters.txt
@@ -426,6 +426,10 @@ and is between 256 and 4096 characters. It is defined in
the file
bttv.pll= See Documentation/video4linux/bttv/Insmod-options
bttv.tuner= and Documentation/video4linux/bttv/CARDLIST
+ bulk_remove=off [PPC] This parameter disables the use of the pSeries
+ firmware feature for flushing multiple hpte entries
+ at a time.
+
BusLogic= [HW,SCSI]
See drivers/scsi/BusLogic.c, comment before function
BusLogic_ParseDriverOptions().
@@ -1499,6 +1503,10 @@ and is between 256 and 4096 characters. It is defined in
the file
mtdparts= [MTD]
See drivers/mtd/cmdlinepart.c.
+ multitce=off[PPC] This parameter disables the use of the pSeries
+ firmware feature for updating multiple TCE entries
+ at a time.
+
onenand.bdry= [HW,MTD] Flex-OneNAND Boundary Configuration
Format:
[die0_boundary][,die0_lock][,die1_boundary][,die1_lock]
diff --git a/arch/powerpc/platforms/pseries/iommu.c
b/arch/powerpc/platforms/pseries/iommu.c
index 902987d..e174a2f 100644
--- a/arch/powerpc/platforms/pseries/iommu.c
+++ b/arch/powerpc/platforms/pseries/iommu.c
@@ -625,3 +625,17 @@ void iommu_init_early_pSeries(void)
set_pci_dma_ops(dma_iommu_ops);
}
+static int __init disable_multitce(char *str)
+{
+ if (strcmp(str, off) == 0
+ firmware_has_feature(FW_FEATURE_LPAR)
+ firmware_has_feature(FW_FEATURE_MULTITCE)) {
+ printk(KERN_INFO Disabling MULTITCE firmware feature\n);
+ ppc_md.tce_build = tce_build_pSeriesLP;
+ ppc_md.tce_free = tce_free_pSeriesLP;
+ powerpc_firmware_features = ~FW_FEATURE_MULTITCE;
+ }
+ return 1;
+}
+
+__setup(multitce=, disable_multitce);
diff --git a/arch/powerpc/platforms/pseries/lpar.c
b/arch/powerpc/platforms/pseries/lpar.c
index 0707653..82d15e7 100644
--- a/arch/powerpc/platforms/pseries/lpar.c
+++ b/arch/powerpc/platforms/pseries/lpar.c
@@ -599,6 +599,18 @@ static void pSeries_lpar_flush_hash_range(unsigned long
number, int local)
spin_unlock_irqrestore(pSeries_lpar_tlbie_lock, flags);
}
+static int __init disable_bulk_remove(char *str)
+{
+ if (strcmp(str, off) == 0
+ firmware_has_feature(FW_FEATURE_BULK_REMOVE)) {
+ printk(KERN_INFO Disabling BULK_REMOVE firmware
feature);
+ powerpc_firmware_features = ~FW_FEATURE_BULK_REMOVE;
+ }
+ return 1;
+}
+
+__setup(bulk_remove=, disable_bulk_remove);
+
void __init hpte_init_lpar(void)
{
ppc_md.hpte_invalidate = pSeries_lpar_hpte_invalidate;
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH (Option 1)] of/i2c: fix module load order issue caused by of_i2c.c
On Fri, Sep 24, 2010 at 04:14:53PM -0600, Grant Likely wrote:
Commit 959e85f7, i2c: add OF-style registration and binding caused a
module dependency loop where of_i2c.c calls functions in i2c-core, and
i2c-core calls of_i2c_register_devices() in of_i2c. This means that
when i2c support is built as a module when CONFIG_OF is set, then
neither i2c_core nor of_i2c are able to be loaded.
This patch fixes the problem by moving the of_i2c_register_devices()
function into the body of i2c_core and renaming it to
i2c_scan_of_devices (of_i2c_register_devices is analogous to the
existing i2c_scan_static_board_info function and so should be named
similarly). This function isn't called by any code outside of
i2c_core, and it must always be present when CONFIG_OF is selected, so
it makes sense to locate it there. When CONFIG_OF is not selected,
of_i2c_register_devices() becomes a no-op.
Signed-off-by: Grant Likely grant.lik...@secretlab.ca
---
drivers/i2c/i2c-core.c | 61
++--
drivers/of/of_i2c.c| 57 -
include/linux/of_i2c.h |7 --
3 files changed, 59 insertions(+), 66 deletions(-)
diff --git a/drivers/i2c/i2c-core.c b/drivers/i2c/i2c-core.c
index 6649176..64a261b 100644
--- a/drivers/i2c/i2c-core.c
+++ b/drivers/i2c/i2c-core.c
@@ -32,8 +32,8 @@
#include linux/init.h
#include linux/idr.h
#include linux/mutex.h
-#include linux/of_i2c.h
#include linux/of_device.h
+#include linux/of_irq.h
#include linux/completion.h
#include linux/hardirq.h
#include linux/irqflags.h
@@ -818,6 +818,63 @@ static void i2c_scan_static_board_info(struct
i2c_adapter *adapter)
up_read(__i2c_board_lock);
}
+#ifdef CONFIG_OF
+void i2c_scan_of_devices(struct i2c_adapter *adap)
+{
+ void *result;
+ struct device_node *node;
+
+ /* Only register child devices if the adapter has a node pointer set */
+ if (!adap-dev.of_node)
+ return;
+
+ for_each_child_of_node(adap-dev.of_node, node) {
+ struct i2c_board_info info = {};
+ struct dev_archdata dev_ad = {};
+ const __be32 *addr;
+ int len;
+
+ dev_dbg(adap-dev, of_i2c: register %s\n, node-full_name);
+ if (of_modalias_node(node, info.type, sizeof(info.type)) 0) {
+ dev_err(adap-dev, of_i2c: modalias failure on %s\n,
+ node-full_name);
+ continue;
+ }
+
+ addr = of_get_property(node, reg, len);
+ if (!addr || (len sizeof(int))) {
+ dev_err(adap-dev, of_i2c: invalid reg on %s\n,
+ node-full_name);
+ continue;
+ }
+
+ info.addr = be32_to_cpup(addr);
+ if (info.addr (1 10) - 1) {
+ dev_err(adap-dev, of_i2c: invalid addr=%x on %s\n,
+ info.addr, node-full_name);
+ continue;
+ }
+
+ info.irq = irq_of_parse_and_map(node, 0);
+ info.of_node = of_node_get(node);
+ info.archdata = dev_ad;
+
+ request_module(%s, info.type);
+
+ result = i2c_new_device(adap, info);
+ if (result == NULL) {
+ dev_err(adap-dev, of_i2c: Failure registering %s\n,
+ node-full_name);
+ of_node_put(node);
+ irq_dispose_mapping(info.irq);
+ continue;
+ }
+ }
+}
+#else
+static inline void i2c_scan_of_devices(struct i2c_adapter *adap) { }
+#endif
Is there any advantage to just making the definition in the header
file a static inline and removing the #else part of this?
--
Ben
Q: What's a light-year?
A: One-third less calories than a regular year.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH (Option 1)] of/i2c: fix module load order issue caused by of_i2c.c
On Fri, Sep 24, 2010 at 04:14:53PM -0600, Grant Likely wrote: Commit 959e85f7, i2c: add OF-style registration and binding caused a module dependency loop where of_i2c.c calls functions in i2c-core, and i2c-core calls of_i2c_register_devices() in of_i2c. This means that when i2c support is built as a module when CONFIG_OF is set, then neither i2c_core nor of_i2c are able to be loaded. This patch fixes the problem by moving the of_i2c_register_devices() function into the body of i2c_core and renaming it to i2c_scan_of_devices (of_i2c_register_devices is analogous to the existing i2c_scan_static_board_info function and so should be named similarly). This function isn't called by any code outside of i2c_core, and it must always be present when CONFIG_OF is selected, so it makes sense to locate it there. When CONFIG_OF is not selected, of_i2c_register_devices() becomes a no-op. I sort of go with this one. -- Ben Q: What's a light-year? A: One-third less calories than a regular year. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 0/8] v2 De-Couple sysfs memory directories from memory sections
On Tue, Sep 28, 2010 at 10:12:18AM -0500, Robin Holt wrote: On Tue, Sep 28, 2010 at 02:44:40PM +0200, Avi Kivity wrote: On 09/27/2010 09:09 PM, Nathan Fontenot wrote: This set of patches decouples the concept that a single memory section corresponds to a single directory in /sys/devices/system/memory/. On systems with large amounts of memory (1+ TB) there are perfomance issues related to creating the large number of sysfs directories. For a powerpc machine with 1 TB of memory we are creating 63,000+ directories. This is resulting in boot times of around 45-50 minutes for systems with 1 TB of memory and 8 hours for systems with 2 TB of memory. With this patch set applied I am now seeing boot times of 5 minutes or less. The root of this issue is in sysfs directory creation. Every time a directory is created a string compare is done against all sibling directories to ensure we do not create duplicates. The list of directory nodes in sysfs is kept as an unsorted list which results in this being an exponentially longer operation as the number of directories are created. The solution solved by this patch set is to allow a single directory in sysfs to span multiple memory sections. This is controlled by an optional architecturally defined function memory_block_size_bytes(). The default definition of this routine returns a memory block size equal to the memory section size. This maintains the current layout of sysfs memory directories as it appears to userspace to remain the same as it is today. Why not update sysfs directory creation to be fast, for example by using an rbtree instead of a linked list. This fixes an implementation problem in the kernel instead of working around it and creating a new ABI. Because the old ABI creates 129,000+ entries inside /sys/devices/system/memory with their associated links from /sys/devices/system/node/node*/ back to those directory entries. Thankfully things like rpm, hald, and other miscellaneous commands scan that information. Really? Why? Why would rpm care about this? hald is dead now so we don't need to worry about that anymore, but what other commands/programs read this information? thanks, greg k-h ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
