* [PATCH v5 2/2] powerpc: add support for new hcall H_BEST_ENERGY
From: Vaidyanathan Srinivasan @ 2010-10-06 18:37 UTC (permalink / raw)
To: Benjamin Herrenschmidt, Paul Mackerras, Anton Blanchard
Cc: Michael Neuling, linuxppc-dev
In-Reply-To: <20101006182948.7006.75088.stgit@drishya.in.ibm.com>
Create sysfs interface to export data from H_BEST_ENERGY hcall
that can be used by administrative tools on supported pseries
platforms for energy management optimizations.
/sys/device/system/cpu/pseries_(de)activate_hint_list and
/sys/device/system/cpu/cpuN/pseries_(de)activate_hint will provide
hints for activation and deactivation of cpus respectively.
These hints are abstract number given by the hypervisor based
on the extended knowledge the hypervisor has regarding the
current system topology and resource mappings.
The activate and the deactivate sysfs entry is for the two
distinct operations that we could do for energy savings. When
we have more capacity than required, we could deactivate few
core to save energy. The choice of the core to deactivate
will be based on /sys/devices/system/cpu/deactivate_hint_list.
The comma separated list of cpus (cores) will be the preferred
choice. If we have to activate some of the deactivated cores,
then /sys/devices/system/cpu/activate_hint_list will be used.
The per-cpu file
/sys/device/system/cpu/cpuN/pseries_(de)activate_hint further
provide more fine grain information by exporting the value of
the hint itself.
Added new driver module
arch/powerpc/platforms/pseries/pseries_energy.c
under new config option CONFIG_PSERIES_ENERGY
Signed-off-by: Vaidyanathan Srinivasan <svaidy@linux.vnet.ibm.com>
---
arch/powerpc/include/asm/hvcall.h | 3
arch/powerpc/platforms/pseries/Kconfig | 10 +
arch/powerpc/platforms/pseries/Makefile | 1
arch/powerpc/platforms/pseries/pseries_energy.c | 326 +++++++++++++++++++++++
4 files changed, 339 insertions(+), 1 deletions(-)
create mode 100644 arch/powerpc/platforms/pseries/pseries_energy.c
diff --git a/arch/powerpc/include/asm/hvcall.h b/arch/powerpc/include/asm/hvcall.h
index de03ca5..bf86b03 100644
--- a/arch/powerpc/include/asm/hvcall.h
+++ b/arch/powerpc/include/asm/hvcall.h
@@ -232,7 +232,8 @@
#define H_GET_EM_PARMS 0x2B8
#define H_SET_MPP 0x2D0
#define H_GET_MPP 0x2D4
-#define MAX_HCALL_OPCODE H_GET_MPP
+#define H_BEST_ENERGY 0x2F4
+#define MAX_HCALL_OPCODE H_BEST_ENERGY
#ifndef __ASSEMBLY__
diff --git a/arch/powerpc/platforms/pseries/Kconfig b/arch/powerpc/platforms/pseries/Kconfig
index c667f0f..8323622 100644
--- a/arch/powerpc/platforms/pseries/Kconfig
+++ b/arch/powerpc/platforms/pseries/Kconfig
@@ -33,6 +33,16 @@ config PSERIES_MSI
depends on PCI_MSI && EEH
default y
+config PSERIES_ENERGY
+ tristate "pSeries energy management capabilities driver"
+ depends on PPC_PSERIES
+ default y
+ help
+ Provides interface to platform energy management capabilities
+ on supported PSERIES platforms.
+ Provides: /sys/devices/system/cpu/pseries_(de)activation_hint_list
+ and /sys/devices/system/cpu/cpuN/pseries_(de)activation_hint
+
config SCANLOG
tristate "Scanlog dump interface"
depends on RTAS_PROC && PPC_PSERIES
diff --git a/arch/powerpc/platforms/pseries/Makefile b/arch/powerpc/platforms/pseries/Makefile
index 046ace9..50a7ea3 100644
--- a/arch/powerpc/platforms/pseries/Makefile
+++ b/arch/powerpc/platforms/pseries/Makefile
@@ -16,6 +16,7 @@ obj-$(CONFIG_EEH) += eeh.o eeh_cache.o eeh_driver.o eeh_event.o eeh_sysfs.o
obj-$(CONFIG_KEXEC) += kexec.o
obj-$(CONFIG_PCI) += pci.o pci_dlpar.o
obj-$(CONFIG_PSERIES_MSI) += msi.o
+obj-$(CONFIG_PSERIES_ENERGY) += pseries_energy.o
obj-$(CONFIG_HOTPLUG_CPU) += hotplug-cpu.o
obj-$(CONFIG_MEMORY_HOTPLUG) += hotplug-memory.o
diff --git a/arch/powerpc/platforms/pseries/pseries_energy.c b/arch/powerpc/platforms/pseries/pseries_energy.c
new file mode 100644
index 0000000..c8b3c69
--- /dev/null
+++ b/arch/powerpc/platforms/pseries/pseries_energy.c
@@ -0,0 +1,326 @@
+/*
+ * POWER platform energy management driver
+ * Copyright (C) 2010 IBM Corporation
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * version 2 as published by the Free Software Foundation.
+ *
+ * This pseries platform device driver provides access to
+ * platform energy management capabilities.
+ */
+
+#include <linux/module.h>
+#include <linux/types.h>
+#include <linux/errno.h>
+#include <linux/init.h>
+#include <linux/seq_file.h>
+#include <linux/sysdev.h>
+#include <linux/cpu.h>
+#include <linux/of.h>
+#include <asm/cputhreads.h>
+#include <asm/page.h>
+#include <asm/hvcall.h>
+
+
+#define MODULE_VERS "1.0"
+#define MODULE_NAME "pseries_energy"
+
+/* Driver flags */
+
+static int sysfs_entries;
+
+/* Helper routines */
+
+/*
+ * Routine to detect firmware support for hcall
+ * return 1 if H_BEST_ENERGY is supported
+ * else return 0
+ */
+
+static int check_for_h_best_energy(void)
+{
+ struct device_node *rtas = NULL;
+ const char *hypertas, *s;
+ int length;
+ int rc = 0;
+
+ rtas = of_find_node_by_path("/rtas");
+ if (!rtas)
+ return 0;
+
+ hypertas = of_get_property(rtas, "ibm,hypertas-functions", &length);
+ if (!hypertas) {
+ of_node_put(rtas);
+ return 0;
+ }
+
+ /* hypertas will have list of strings with hcall names */
+ for (s = hypertas; s < hypertas + length; s += strlen(s) + 1) {
+ if (!strncmp("hcall-best-energy-1", s, 19)) {
+ rc = 1; /* Found the string */
+ break;
+ }
+ }
+ of_node_put(rtas);
+ return rc;
+}
+
+/* Helper Routines to convert between drc_index to cpu numbers */
+
+static u32 cpu_to_drc_index(int cpu)
+{
+ struct device_node *dn = NULL;
+ const int *indexes;
+ int i;
+ int rc = 1;
+ u32 ret = 0;
+
+ dn = of_find_node_by_path("/cpus");
+ if (dn == NULL)
+ goto err;
+ indexes = of_get_property(dn, "ibm,drc-indexes", NULL);
+ if (indexes == NULL)
+ goto err_of_node_put;
+ /* Convert logical cpu number to core number */
+ i = cpu_core_index_of_thread(cpu);
+ /*
+ * The first element indexes[0] is the number of drc_indexes
+ * returned in the list. Hence i+1 will get the drc_index
+ * corresponding to core number i.
+ */
+ WARN_ON(i > indexes[0]);
+ ret = indexes[i + 1];
+ rc = 0;
+
+err_of_node_put:
+ of_node_put(dn);
+err:
+ if (rc)
+ printk(KERN_WARNING "cpu_to_drc_index(%d) failed", cpu);
+ return ret;
+}
+
+static int drc_index_to_cpu(u32 drc_index)
+{
+ struct device_node *dn = NULL;
+ const int *indexes;
+ int i, cpu = 0;
+ int rc = 1;
+
+ dn = of_find_node_by_path("/cpus");
+ if (dn == NULL)
+ goto err;
+ indexes = of_get_property(dn, "ibm,drc-indexes", NULL);
+ if (indexes == NULL)
+ goto err_of_node_put;
+ /*
+ * First element in the array is the number of drc_indexes
+ * returned. Search through the list to find the matching
+ * drc_index and get the core number
+ */
+ for (i = 0; i < indexes[0]; i++) {
+ if (indexes[i + 1] == drc_index)
+ break;
+ }
+ /* Convert core number to logical cpu number */
+ cpu = cpu_first_thread_of_core(i);
+ rc = 0;
+
+err_of_node_put:
+ of_node_put(dn);
+err:
+ if (rc)
+ printk(KERN_WARNING "drc_index_to_cpu(%d) failed", drc_index);
+ return cpu;
+}
+
+/*
+ * pseries hypervisor call H_BEST_ENERGY provides hints to OS on
+ * preferred logical cpus to activate or deactivate for optimized
+ * energy consumption.
+ */
+
+#define FLAGS_MODE1 0x004E200000080E01
+#define FLAGS_MODE2 0x004E200000080401
+#define FLAGS_ACTIVATE 0x100
+
+static ssize_t get_best_energy_list(char *page, int activate)
+{
+ int rc, cnt, i, cpu;
+ unsigned long retbuf[PLPAR_HCALL9_BUFSIZE];
+ unsigned long flags = 0;
+ u32 *buf_page;
+ char *s = page;
+
+ buf_page = (u32 *) get_zeroed_page(GFP_KERNEL);
+ if (!buf_page)
+ return -ENOMEM;
+
+ flags = FLAGS_MODE1;
+ if (activate)
+ flags |= FLAGS_ACTIVATE;
+
+ rc = plpar_hcall9(H_BEST_ENERGY, retbuf, flags, 0, __pa(buf_page),
+ 0, 0, 0, 0, 0, 0);
+ if (rc != H_SUCCESS) {
+ free_page((unsigned long) buf_page);
+ return -EINVAL;
+ }
+
+ cnt = retbuf[0];
+ for (i = 0; i < cnt; i++) {
+ cpu = drc_index_to_cpu(buf_page[2*i+1]);
+ if ((cpu_online(cpu) && !activate) ||
+ (!cpu_online(cpu) && activate))
+ s += sprintf(s, "%d,", cpu);
+ }
+ if (s > page) { /* Something to show */
+ s--; /* Suppress last comma */
+ s += sprintf(s, "\n");
+ }
+
+ free_page((unsigned long) buf_page);
+ return s-page;
+}
+
+static ssize_t get_best_energy_data(struct sys_device *dev,
+ char *page, int activate)
+{
+ int rc;
+ unsigned long retbuf[PLPAR_HCALL9_BUFSIZE];
+ unsigned long flags = 0;
+
+ flags = FLAGS_MODE2;
+ if (activate)
+ flags |= FLAGS_ACTIVATE;
+
+ rc = plpar_hcall9(H_BEST_ENERGY, retbuf, flags,
+ cpu_to_drc_index(dev->id),
+ 0, 0, 0, 0, 0, 0, 0);
+
+ if (rc != H_SUCCESS)
+ return -EINVAL;
+
+ return sprintf(page, "%lu\n", retbuf[1] >> 32);
+}
+
+/* Wrapper functions */
+
+static ssize_t cpu_activate_hint_list_show(struct sysdev_class *class,
+ struct sysdev_class_attribute *attr, char *page)
+{
+ return get_best_energy_list(page, 1);
+}
+
+static ssize_t cpu_deactivate_hint_list_show(struct sysdev_class *class,
+ struct sysdev_class_attribute *attr, char *page)
+{
+ return get_best_energy_list(page, 0);
+}
+
+static ssize_t percpu_activate_hint_show(struct sys_device *dev,
+ struct sysdev_attribute *attr, char *page)
+{
+ return get_best_energy_data(dev, page, 1);
+}
+
+static ssize_t percpu_deactivate_hint_show(struct sys_device *dev,
+ struct sysdev_attribute *attr, char *page)
+{
+ return get_best_energy_data(dev, page, 0);
+}
+
+/*
+ * Create sysfs interface:
+ * /sys/devices/system/cpu/pseries_activate_hint_list
+ * /sys/devices/system/cpu/pseries_deactivate_hint_list
+ * Comma separated list of cpus to activate or deactivate
+ * /sys/devices/system/cpu/cpuN/pseries_activate_hint
+ * /sys/devices/system/cpu/cpuN/pseries_deactivate_hint
+ * Per-cpu value of the hint
+ */
+
+struct sysdev_class_attribute attr_cpu_activate_hint_list =
+ _SYSDEV_CLASS_ATTR(pseries_activate_hint_list, 0444,
+ cpu_activate_hint_list_show, NULL);
+
+struct sysdev_class_attribute attr_cpu_deactivate_hint_list =
+ _SYSDEV_CLASS_ATTR(pseries_deactivate_hint_list, 0444,
+ cpu_deactivate_hint_list_show, NULL);
+
+struct sysdev_attribute attr_percpu_activate_hint =
+ _SYSDEV_ATTR(pseries_activate_hint, 0444,
+ percpu_activate_hint_show, NULL);
+
+struct sysdev_attribute attr_percpu_deactivate_hint =
+ _SYSDEV_ATTR(pseries_deactivate_hint, 0444,
+ percpu_deactivate_hint_show, NULL);
+
+static int __init pseries_energy_init(void)
+{
+ int cpu, err;
+ struct sys_device *cpu_sys_dev;
+
+ if (!check_for_h_best_energy()) {
+ printk(KERN_INFO "Hypercall H_BEST_ENERGY not supported\n");
+ return 0;
+ }
+ /* Create the sysfs files */
+ err = sysfs_create_file(&cpu_sysdev_class.kset.kobj,
+ &attr_cpu_activate_hint_list.attr);
+ if (!err)
+ err = sysfs_create_file(&cpu_sysdev_class.kset.kobj,
+ &attr_cpu_deactivate_hint_list.attr);
+
+ if (err)
+ return err;
+ for_each_possible_cpu(cpu) {
+ cpu_sys_dev = get_cpu_sysdev(cpu);
+ err = sysfs_create_file(&cpu_sys_dev->kobj,
+ &attr_percpu_activate_hint.attr);
+ if (err)
+ break;
+ err = sysfs_create_file(&cpu_sys_dev->kobj,
+ &attr_percpu_deactivate_hint.attr);
+ if (err)
+ break;
+ }
+
+ if (err)
+ return err;
+
+ sysfs_entries = 1; /* Removed entries on cleanup */
+ return 0;
+
+}
+
+static void __exit pseries_energy_cleanup(void)
+{
+ int cpu;
+ struct sys_device *cpu_sys_dev;
+
+ if (!sysfs_entries)
+ return;
+
+ /* Remove the sysfs files */
+ sysfs_remove_file(&cpu_sysdev_class.kset.kobj,
+ &attr_cpu_activate_hint_list.attr);
+
+ sysfs_remove_file(&cpu_sysdev_class.kset.kobj,
+ &attr_cpu_deactivate_hint_list.attr);
+
+ for_each_possible_cpu(cpu) {
+ cpu_sys_dev = get_cpu_sysdev(cpu);
+ sysfs_remove_file(&cpu_sys_dev->kobj,
+ &attr_percpu_activate_hint.attr);
+ sysfs_remove_file(&cpu_sys_dev->kobj,
+ &attr_percpu_deactivate_hint.attr);
+ }
+}
+
+module_init(pseries_energy_init);
+module_exit(pseries_energy_cleanup);
+MODULE_DESCRIPTION("Driver for pSeries platform energy management");
+MODULE_AUTHOR("Vaidyanathan Srinivasan");
+MODULE_LICENSE("GPL");
^ permalink raw reply related
* Re: Linuxppc-dev Digest, Vol 74, Issue 31
From: Gorelik, Jacob (335F) @ 2010-10-06 22:56 UTC (permalink / raw)
To: linuxppc-dev@lists.ozlabs.org
In-Reply-To: <mailman.1656.1286390250.3010.linuxppc-dev@lists.ozlabs.org>
Hello,
In start_kernel function, locked_initial() is called; however, it does not =
do anything. Is it not needed?
Thank you,
Jacob
On Oct 6, 2010, at 11:38 AM, "linuxppc-dev-request@lists.ozlabs.org" <linux=
ppc-dev-request@lists.ozlabs.org> wrote:
> Send Linuxppc-dev mailing list submissions to
> linuxppc-dev@lists.ozlabs.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://lists.ozlabs.org/listinfo/linuxppc-dev
> or, via email, send a message with subject or body 'help' to
> linuxppc-dev-request@lists.ozlabs.org
>
> You can reach the person managing the list at
> linuxppc-dev-owner@lists.ozlabs.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Linuxppc-dev digest..."
>
>
> Today's Topics:
>
> 1. MPC8641D PCI Endpoint incoming interrupts?
> (david.hagood@gmail.com)
> 2. Re: powerpc, fs_enet: scanning PHY after Linux is up
> (Grant Likely)
> 3. Re: powerpc, fs_enet: scanning PHY after Linux is up
> (Grant Likely)
> 4. [PATCH v5 0/2] powerpc: add support for new hcall
> H_BEST_ENERGY (Vaidyanathan Srinivasan)
> 5. [PATCH v5 1/2] powerpc: cleanup APIs for cpu/thread/core
> mappings (Vaidyanathan Srinivasan)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Wed, 6 Oct 2010 11:20:11 -0500
> From: david.hagood@gmail.com
> To: linuxppc-dev@lists.ozlabs.org
> Subject: MPC8641D PCI Endpoint incoming interrupts?
> Message-ID: <56e21593e98493b02bcda171b200241a.squirrel@localhost>
> Content-Type: text/plain;charset=3Diso-8859-1
>
> I'm trying to use an MPC8641D as a PCIe endpoint device, and I'm trying t=
o
> work out how the host root complex CPU can interrupt the PPC core. It's
> not very clear how to do all of this, and I'd like some help fitting the
> pieces together. If there's a good how-to online I've yet to find it.
>
> As I read it, on the host side, I'd do one of:
> 1) a write to the PPC's BAR0, offset 0x41400 (MSGR0) with some message va=
lue
> 2) a write to BAR0 offset 0x41600 (MSIR0) and set a bit within it.
> 3) a write to 0x41740 (MSIIR) to set a bit in MSIR0
>
> So question #1 is "which of those should I use?" (or should I use
> something else?)
>
> Then, as I read it, I'd have to somehow convert the interrupt vector the
> PIC uses into a virtual interrupt number suitable for request_irq. I've
> seen mentions of irq_of_parse_and_map(), but I've not found a good
> description of how to use it. Does anybody have any (non-null) pointers o=
n
> this?
>
> Once I get to request_irq I'm on familiar ground.
>
>
>
>
> ------------------------------
>
> Message: 2
> Date: Wed, 6 Oct 2010 10:52:52 -0600
> From: Grant Likely <grant.likely@secretlab.ca>
> To: hs@denx.de
> Cc: linuxppc-dev@ozlabs.org, devicetree-discuss@lists.ozlabs.org,
> Holger Brunck <holger.brunck@keymile.com>, Detlev Zundel
> <dzu@denx.de>, netdev@vger.kernel.org
> Subject: Re: powerpc, fs_enet: scanning PHY after Linux is up
> Message-ID:
> <AANLkTi=3DGkkD_-Vu-NswNedhgVuPaYePOHWa_2ytQgMf_@mail.gmail.com>
> Content-Type: text/plain; charset=3DISO-8859-1
>
> On Wed, Oct 6, 2010 at 3:53 AM, Heiko Schocher <hs@denx.de> wrote:
>> Hello Grant,
>>
>> Thanks for your answer!
>>
>> Grant Likely wrote:
>>> On Mon, Oct 4, 2010 at 1:32 AM, Heiko Schocher <hs@denx.de> wrote:
>>>> Hello all,
>>>>
>>>> we have on the mgcoge arch/powerpc/boot/dts/mgcoge.dts 3 fs_enet
>>>> devices. The first is accessible on boot, and so get correct
>>>> probed and works fine. For the other two fs_enet devices the PHYs
>>>> are on startup in reset, and gets later, through userapplikations,
>>>> out of reset ... so, on bootup, this 2 fs_enet devices could
>>>> not detect the PHY in drivers/of/of_mdio.c of_mdiobus_register(),
>>>> and if we want to use them later, we get for example:
>>>>
>>>> -bash-3.2# ifconfig eth2 172.31.31.33
>>>> net eth2: Could not attach to PHY
>>>> SIOCSIFFLAGS: No such device
>>>>
>>>> So the problem is, that we cannot rescan the PHYs, if they are
>>>> accessible. Also we could not load the fs_enet driver as a module,
>>>> because the first port is used fix.
>>>>
>>>> So, first question which comes in my mind, is:
>>>>
>>>> Is detecting the phy in drivers/of/of_mdio.c of_mdiobus_register()
>>>> the right place, or should it not better be done, when really
>>>> using the port?
>>>>
>>>> But we found another way to solve this issue:
>>>>
>>>> After the PHYs are out of reset, we just have to rescan the PHYs
>>>> with (for example PHY with addr 1)
>>>>
>>>> err =3D mdiobus_scan(bus, 1);
>>>>
>>>> and
>>>>
>>>> of_find_node_by_path("/soc@f0000000/cpm@119c0/mdio@10d40/ethernet-phy@=
1");
>>>> of_node_get(np);
>>>> dev_archdata_set_node(&err->dev.archdata, np);
>>>>
>>>> but thats just a hack ...
>>>
>>> Yeah, that's a hack. ?It really needs to be done via the of_mdio
>>> mechanisms so that dt <--> phy_device linkages remain consistent.
>>
>> Yep, I know, thats the reason why I ask ;-)
>>
>>>> So, the question is, is there a possibility to solve this problem?
>>>>
>>>> If there is no standard option, what would be with adding a
>>>> "scan_phy" file in
>>>>
>>>> /proc/device-tree/soc\@f0000000/cpm\@119c0/mdio\@10d40
>>>> (or better destination?)
>>>>
>>>> which with we could rescan a PHY with
>>>> "echo addr > /proc/device-tree/soc\@f0000000/cpm\@119c0/mdio\@10d40/sc=
an_phy"
>>>> (so there is no need for using of_find_node_by_path(), as we should
>>>> ?have the associated device node here, and can step through the child
>>>> ?nodes with "for_each_child_of_node(np, child)" and check if reg =3D=
=3D addr)
>>>>
>>>> or shouldn;t be at least, if the phy couldn;t be found when opening
>>>> the port, retrigger a scanning, if the phy now is accessible?
>>>
>>> One option would be to still register a phy_device for each phy
>>> described in the device tree, but defer binding a driver to each phy
>>> that doesn't respond. ?Then at of_phy_find_device() time, if it
>>
>> Maybe I din;t get the trick, but the problem is, that
>> you can;t register a phy_device in drivers/of/of_mdio.c
>> of_mdiobus_register(), if the phy didn;t respond with the
>> phy_id ... and of_phy_find_device() is not (yet) used in fs_enet
>
> I'm suggesting modifying the phy layer so that it is possible to
> register a phy_device that doesn't (yet) respond.
>
>>> matches with a phy_device that isn't bound to a driver yet, then
>>> re-trigger the binding operation. ?At which point the phy id can be
>>> probed and the correct driver can be chosen. ?If binding succeeds,
>>> then return the phy_device handle. ?If not, then fail as it currently
>>> does.
>>
>> Wouldn;t it be good, just if we need a PHY (on calling fs_enet_open)
>> to look if there is one?
>>
>> Something like that (not tested):
>>
>> in drivers/net/fs_enet/fs_enet-main.c in fs_init_phy()
>> called from fs_enet_open():
>>
>> Do first:
>> phydev =3D ?of_phy_find_device(fep->fpi->phy_node);
>>
>> Look if there is a driver (phy_dev->drv =3D=3D NULL ?)
>>
>> If not, call new function
>> of_mdiobus_register_phy(mii_bus, fep->fpi->phy_node)
>> see below patch for it.
>>
>> If this succeeds, all is OK, and we can use this phy,
>> else ethernet not work.
>
> I don't like this approach because it muddies the concept of which
> device is actually responsible for managing the phys on the bus. Is
> it managed by the mdio bus device or the Ethernet device? It also has
> a potential race condition. Whereas triggering a late driver bind
> will be safe.
>
> Alternately, I'd also be okay with a common method to trigger a
> reprobe of a particular phy from userspace, but I fear that would be a
> significantly more complex solution.
>
>>
>> !!just no idea, how to get mii_bus pointer ...
>
> You'd have to get the parent of the phy node, and then loop over all
> the registered mdio busses looking for a bus that uses that node.
>
>>
>> here the patch for the new function of_mdiobus_register_phy():
>>
>> diff --git a/drivers/of/of_mdio.c b/drivers/of/of_mdio.c
>> index b474833..7afbb0b 100644
>> --- a/drivers/of/of_mdio.c
>> +++ b/drivers/of/of_mdio.c
>> @@ -21,6 +21,51 @@
>> ?MODULE_AUTHOR("Grant Likely <grant.likely@secretlab.ca>");
>> ?MODULE_LICENSE("GPL");
>>
>> +int of_mdiobus_register_phy(struct mii_bus *mdio, struct device_node *c=
hild)
>> +{
>> + ? ? ? struct phy_device *phy;
>> + ? ? ? const __be32 *addr;
>> + ? ? ? int len;
>> + ? ? ? int rc;
>> +
>> + ? ? ? /* A PHY must have a reg property in the range [0-31] */
>> + ? ? ? addr =3D of_get_property(child, "reg", &len);
>> + ? ? ? if (!addr || len < sizeof(*addr) || *addr >=3D 32 || *addr < 0) =
{
>> + ? ? ? ? ? ? ? dev_err(&mdio->dev, "%s has invalid PHY address\n",
>> + ? ? ? ? ? ? ? ? ? ? ? child->full_name);
>> + ? ? ? ? ? ? ? return -1;
>> + ? ? ? }
>> +
>> + ? ? ? if (mdio->irq) {
>> + ? ? ? ? ? ? ? mdio->irq[*addr] =3D irq_of_parse_and_map(child, 0);
>> + ? ? ? ? ? ? ? if (!mdio->irq[*addr])
>> + ? ? ? ? ? ? ? ? ? ? ? mdio->irq[*addr] =3D PHY_POLL;
>> + ? ? ? }
>> +
>> + ? ? ? phy =3D get_phy_device(mdio, be32_to_cpup(addr));
>> + ? ? ? if (!phy || IS_ERR(phy)) {
>> + ? ? ? ? ? ? ? dev_err(&mdio->dev, "error probing PHY at address %i\n",
>> + ? ? ? ? ? ? ? ? ? ? ? *addr);
>> + ? ? ? ? ? ? ? return -2;
>> + ? ? ? }
>> + ? ? ? phy_scan_fixups(phy);
>> + ? ? ? /* Associate the OF node with the device structure so it
>> + ? ? ? ?* can be looked up later */
>> + ? ? ? of_node_get(child);
>> + ? ? ? dev_archdata_set_node(&phy->dev.archdata, child);
>> +
>> + ? ? ? /* All data is now stored in the phy struct; register it */
>> + ? ? ? rc =3D phy_device_register(phy);
>> + ? ? ? if (rc) {
>> + ? ? ? ? ? ? ? phy_device_free(phy);
>> + ? ? ? ? ? ? ? of_node_put(child);
>> + ? ? ? ? ? ? ? return -3;
>> + ? ? ? }
>> +
>> + ? ? ? dev_dbg(&mdio->dev, "registered phy %s at address %i\n",
>> + ? ? ? ? ? ? ? child->name, *addr);
>> +}
>> +
>> ?/**
>> ?* of_mdiobus_register - Register mii_bus and create PHYs from the devic=
e tree
>> ?* @mdio: pointer to mii_bus structure
>> @@ -31,7 +76,6 @@ MODULE_LICENSE("GPL");
>> ?*/
>> ?int of_mdiobus_register(struct mii_bus *mdio, struct device_node *np)
>> ?{
>> - ? ? ? struct phy_device *phy;
>> ? ? ? ?struct device_node *child;
>> ? ? ? ?int rc, i;
>>
>> @@ -51,46 +95,7 @@ int of_mdiobus_register(struct mii_bus *mdio, struct =
device_node *np)
>>
>> ? ? ? ?/* Loop over the child nodes and register a phy_device for each o=
ne */
>> ? ? ? ?for_each_child_of_node(np, child) {
>> - ? ? ? ? ? ? ? const __be32 *addr;
>> - ? ? ? ? ? ? ? int len;
>> -
>> - ? ? ? ? ? ? ? /* A PHY must have a reg property in the range [0-31] */
>> - ? ? ? ? ? ? ? addr =3D of_get_property(child, "reg", &len);
>> - ? ? ? ? ? ? ? if (!addr || len < sizeof(*addr) || *addr >=3D 32 || *ad=
dr < 0) {
>> - ? ? ? ? ? ? ? ? ? ? ? dev_err(&mdio->dev, "%s has invalid PHY address\=
n",
>> - ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? child->full_name);
>> - ? ? ? ? ? ? ? ? ? ? ? continue;
>> - ? ? ? ? ? ? ? }
>> -
>> - ? ? ? ? ? ? ? if (mdio->irq) {
>> - ? ? ? ? ? ? ? ? ? ? ? mdio->irq[*addr] =3D irq_of_parse_and_map(child,=
0);
>> - ? ? ? ? ? ? ? ? ? ? ? if (!mdio->irq[*addr])
>> - ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? mdio->irq[*addr] =3D PHY_POLL;
>> - ? ? ? ? ? ? ? }
>> -
>> - ? ? ? ? ? ? ? phy =3D get_phy_device(mdio, be32_to_cpup(addr));
>> - ? ? ? ? ? ? ? if (!phy || IS_ERR(phy)) {
>> - ? ? ? ? ? ? ? ? ? ? ? dev_err(&mdio->dev, "error probing PHY at addres=
s %i\n",
>> - ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? *addr);
>> - ? ? ? ? ? ? ? ? ? ? ? continue;
>> - ? ? ? ? ? ? ? }
>> - ? ? ? ? ? ? ? phy_scan_fixups(phy);
>> -
>> - ? ? ? ? ? ? ? /* Associate the OF node with the device structure so it
>> - ? ? ? ? ? ? ? ?* can be looked up later */
>> - ? ? ? ? ? ? ? of_node_get(child);
>> - ? ? ? ? ? ? ? dev_archdata_set_node(&phy->dev.archdata, child);
>> -
>> - ? ? ? ? ? ? ? /* All data is now stored in the phy struct; register it=
*/
>> - ? ? ? ? ? ? ? rc =3D phy_device_register(phy);
>> - ? ? ? ? ? ? ? if (rc) {
>> - ? ? ? ? ? ? ? ? ? ? ? phy_device_free(phy);
>> - ? ? ? ? ? ? ? ? ? ? ? of_node_put(child);
>> - ? ? ? ? ? ? ? ? ? ? ? continue;
>> - ? ? ? ? ? ? ? }
>> -
>> - ? ? ? ? ? ? ? dev_dbg(&mdio->dev, "registered phy %s at address %i\n",
>> - ? ? ? ? ? ? ? ? ? ? ? child->name, *addr);
>> + ? ? ? ? ? ? ? of_mdiobus_register_phy(mdio, child);
>> ? ? ? ?}
>>
>> ? ? ? ?return 0;
>>
>> With this change, it would work on boot as actual (phy_device_register()
>> will fail for the PHYs who don;t work when booting).
>>
>> Later, when opening the ethernet device, fs_init_phy, will look, if
>> we have a valid phy with driver, if not we try to register it again.
>> If this is successfull, we can use the device, if not we will fail,
>> as now ... what do you think?
>
> As mentioned above, it has the potential for some nasty confusion
> about where exactly phy devices get registered, not to mention an
> unlikely but potential race condition between the mdio bus and the
> ethernet device trying to register the same phy since the MDIO bus
> gets registered first, and then the bus loops over the phy nodes while
> the bus is 'live'.
>
> g.
>
>
> ------------------------------
>
> Message: 3
> Date: Wed, 6 Oct 2010 11:30:19 -0600
> From: Grant Likely <grant.likely@secretlab.ca>
> To: Holger brunck <holger.brunck@keymile.com>
> Cc: linuxppc-dev@ozlabs.org, devicetree-discuss@lists.ozlabs.org,
> hs@denx.de, Detlev Zundel <dzu@denx.de>, netdev@vger.kernel.or=
g
> Subject: Re: powerpc, fs_enet: scanning PHY after Linux is up
> Message-ID:
> <AANLkTinWGw5AR8KSSdCyOWqCaMVL-wZH+2uB7zh404_i@mail.gmail.com>
> Content-Type: text/plain; charset=3DISO-8859-1
>
> On Wed, Oct 6, 2010 at 7:50 AM, Holger brunck <holger.brunck@keymile.com>=
wrote:
>> Hello Heiko,
>>
>> On 10/06/2010 11:53 AM, Heiko Schocher wrote:
>>>>> So, the question is, is there a possibility to solve this problem?
>>>>>
>>>>> If there is no standard option, what would be with adding a
>>>>> "scan_phy" file in
>>>>>
>>>>> /proc/device-tree/soc\@f0000000/cpm\@119c0/mdio\@10d40
>>>>> (or better destination?)
>>>>>
>>>>> which with we could rescan a PHY with
>>>>> "echo addr > /proc/device-tree/soc\@f0000000/cpm\@119c0/mdio\@10d40/s=
can_phy"
>>>>> (so there is no need for using of_find_node_by_path(), as we should
>>>>> ?have the associated device node here, and can step through the child
>>>>> ?nodes with "for_each_child_of_node(np, child)" and check if reg =3D=
=3D addr)
>>>>>
>>>>> or shouldn;t be at least, if the phy couldn;t be found when opening
>>>>> the port, retrigger a scanning, if the phy now is accessible?
>>>>
>>>> One option would be to still register a phy_device for each phy
>>>> described in the device tree, but defer binding a driver to each phy
>>>> that doesn't respond. ?Then at of_phy_find_device() time, if it
>>>
>>> Maybe I din;t get the trick, but the problem is, that
>>> you can;t register a phy_device in drivers/of/of_mdio.c
>>> of_mdiobus_register(), if the phy didn;t respond with the
>>> phy_id ... and of_phy_find_device() is not (yet) used in fs_enet
>>>
>>>> matches with a phy_device that isn't bound to a driver yet, then
>>>> re-trigger the binding operation. ?At which point the phy id can be
>>>> probed and the correct driver can be chosen. ?If binding succeeds,
>>>> then return the phy_device handle. ?If not, then fail as it currently
>>>> does.
>>>
>>> Wouldn;t it be good, just if we need a PHY (on calling fs_enet_open)
>>> to look if there is one?
>>>
>>> Something like that (not tested):
>>>
>>> in drivers/net/fs_enet/fs_enet-main.c in fs_init_phy()
>>> called from fs_enet_open():
>>>
>>> Do first:
>>> phydev =3D ?of_phy_find_device(fep->fpi->phy_node);
>>>
>>> Look if there is a driver (phy_dev->drv =3D=3D NULL ?)
>>>
>>> If not, call new function
>>> of_mdiobus_register_phy(mii_bus, fep->fpi->phy_node)
>>> see below patch for it.
>>>
>>> If this succeeds, all is OK, and we can use this phy,
>>> else ethernet not work.
>>>
>>> !!just no idea, how to get mii_bus pointer ...
>>>
>>
>> in my understanding it should be posssible to get this pointer via the p=
arent of
>> the device_node you got via the private data of the fs_enet:
>> fep->fpi->phy_node->parent should point you to the device_node for the m=
dio_bus.
>
> Yes, this will give you the mdio bus node pointer.
>
>> In the next step you should be able to get the pointer of of_device for =
the
>> mdio_bus:
>> ofdevice* ofdev =3D to_of_device(fep->fpi->phy_node->parent);
>
> of_device is just an alias for platform_device now, and not all mdio
> busses will be instantiated by a platform device. This method won't
> always work. What is really needed is the pointer to the mii_bus
> structure. That can be obtained by looping over the members of the
> mdio_bus_class and comparing the mii_bus->device.parent->of_node to
> the parent node from above.
>
> g.
>
>
> ------------------------------
>
> Message: 4
> Date: Thu, 07 Oct 2010 00:06:49 +0530
> From: Vaidyanathan Srinivasan <svaidy@linux.vnet.ibm.com>
> To: Benjamin Herrenschmidt <benh@kernel.crashing.org>, Paul Mackerras
> <paulus@samba.org>, Anton Blanchard <anton@samba.org>
> Cc: Michael Neuling <mikey@neuling.org>, linuxppc-dev@lists.ozlabs.org
> Subject: [PATCH v5 0/2] powerpc: add support for new hcall
> H_BEST_ENERGY
> Message-ID: <20101006182948.7006.75088.stgit@drishya.in.ibm.com>
> Content-Type: text/plain; charset=3D"utf-8"
>
> Hi Ben,
>
> The following series adds a new kernel module for powerpc pseries
> platforms in order to export platform energy management capabilities.
>
> The module exports data from a new hypervisor call H_BEST_ENERGY.
>
> Comments and suggestions made on the previous iteration of the
> patch related to function naming has been incorporated.
>
> Changes in v5:
>
> * Renamed cpu_{left,right}most_thread_sibling() to
> cpu_{first,last}_thread_sibling()
>
> * Renamed cpu_core_of_thread() to cpu_core_index_of_thread()
> (these function work on core index)
>
> * Rebased to 2.6.36-rc6 and tested on a supported platform
>
> Changes in v4:
>
> [4] [PATCH v4 0/2] powerpc: add support for new hcall H_BEST_ENERGY
> http://lists.ozlabs.org/pipermail/linuxppc-dev/2010-July/084217.html
>
> * Added more documentation
> * Added check_for_h_best_energy() to look in ibm,hypertas-functions so
> that sysfs entries are not created in an unsupported platform
> * Added cleaner error checks and correct of_node_put()
> * Rebased and tested on 2.6.35-rc5
>
> Changed in v3:
>
> [3] [PATCH v3 0/2] powerpc: add support for new hcall H_BEST_ENERGY
> http://lists.ozlabs.org/pipermail/linuxppc-dev/2010-June/083414.html
>
> * Added more documentation in the cleanup patch
> * Removed RFC tag, rebased and tested on 2.6.35-rc3
> * Ready for inclusion in powerpc/next tree for further testing
>
> Changes in v2:
>
> [2] [RFC PATCH v2 0/2] powerpc: add support for new hcall H_BEST_ENERGY
> http://lists.ozlabs.org/pipermail/linuxppc-dev/2010-May/082246.html
>
> * Cleanup cpu/thread/core APIs
> * Export APIs to module instead of threads_per_core
> * Use of_find_node_by_path() instead of of_find_node_by_name()
> * Error checking and whitespace cleanups
>
> First version:
> [1] [RFC] powerpc: add support for new hcall H_BEST_ENERGY
> http://lists.ozlabs.org/pipermail/linuxppc-dev/2010-March/080796.html
>
> This patch series will apply on 2.6.36-rc6 as well as powerpc/next
> tree. Please review and include in powerpc/next tree for further
> testing.
>
> I could incrementally reduce some of the error checks as suggested by
> Michael Neuling as next steps. This patch series is conservative and
> has more error checking in device tree parsing and drc index matching
> code than what may be required.
>
> Thanks,
> Vaidy
> ---
>
> Vaidyanathan Srinivasan (2):
> powerpc: cleanup APIs for cpu/thread/core mappings
> powerpc: add support for new hcall H_BEST_ENERGY
>
>
> arch/powerpc/include/asm/cputhreads.h | 15 +
> arch/powerpc/include/asm/hvcall.h | 3
> arch/powerpc/kernel/smp.c | 19 +
> arch/powerpc/mm/mmu_context_nohash.c | 12 -
> arch/powerpc/platforms/pseries/Kconfig | 10 +
> arch/powerpc/platforms/pseries/Makefile | 1
> arch/powerpc/platforms/pseries/pseries_energy.c | 326 ++++++++++++++++++=
+++++
> 7 files changed, 370 insertions(+), 16 deletions(-)
> create mode 100644 arch/powerpc/platforms/pseries/pseries_energy.c
>
>
>
> ------------------------------
>
> Message: 5
> Date: Thu, 07 Oct 2010 00:06:59 +0530
> From: Vaidyanathan Srinivasan <svaidy@linux.vnet.ibm.com>
> To: Benjamin Herrenschmidt <benh@kernel.crashing.org>, Paul Mackerras
> <paulus@samba.org>, Anton Blanchard <anton@samba.org>
> Cc: Michael Neuling <mikey@neuling.org>, linuxppc-dev@lists.ozlabs.org
> Subject: [PATCH v5 1/2] powerpc: cleanup APIs for cpu/thread/core
> mappings
> Message-ID: <20101006183659.7006.76509.stgit@drishya.in.ibm.com>
> Content-Type: text/plain; charset=3D"utf-8"
>
> These APIs take logical cpu number as input
> Change cpu_first_thread_in_core() to cpu_first_thread_sibling()
> Change cpu_last_thread_in_core() to cpu_last_thread_sibling()
>
> These APIs convert core number (index) to logical cpu/thread numbers
> Add cpu_first_thread_of_core(int core)
> Changed cpu_thread_to_core() to cpu_core_index_of_thread(int cpu)
>
> The goal is to make 'threads_per_core' accessible to the
> pseries_energy module. Instead of making an API to read
> threads_per_core, this is a higher level wrapper function to
> convert from logical cpu number to core number.
>
> The current APIs cpu_first_thread_in_core() and
> cpu_last_thread_in_core() returns logical CPU number while
> cpu_thread_to_core() returns core number or index which is
> not a logical CPU number. The new APIs are now clearly named to
> distinguish 'core number' versus first and last 'logical cpu
> number' in that core.
>
> The new APIs cpu_{first,last}_thread_sibling() work on
> logical cpu numbers. While cpu_first_thread_of_core() and
> cpu_core_index_of_thread() work on core index.
>
> Example usage: (4 threads per core system)
>
> cpu_first_thread_sibling(5) =3D 4
> cpu_last_thread_sibling(5) =3D 7
> cpu_core_index_of_thread(5) =3D 1
> cpu_first_thread_of_core(1) =3D 4
>
> cpu_core_index_of_thread() is used in cpu_to_drc_index() in the
> module and cpu_first_thread_of_core() is used in
> drc_index_to_cpu() in the module.
>
> Make API changes to few callers. Export symbols for use in modules.
>
> Signed-off-by: Vaidyanathan Srinivasan <svaidy@linux.vnet.ibm.com>
> ---
> arch/powerpc/include/asm/cputhreads.h | 15 +++++++++------
> arch/powerpc/kernel/smp.c | 19 ++++++++++++++++---
> arch/powerpc/mm/mmu_context_nohash.c | 12 ++++++------
> 3 files changed, 31 insertions(+), 15 deletions(-)
>
> diff --git a/arch/powerpc/include/asm/cputhreads.h b/arch/powerpc/include=
/asm/cputhreads.h
> index a8e1844..f71bb4c 100644
> --- a/arch/powerpc/include/asm/cputhreads.h
> +++ b/arch/powerpc/include/asm/cputhreads.h
> @@ -61,22 +61,25 @@ static inline cpumask_t cpu_online_cores_map(void)
> return cpu_thread_mask_to_cores(cpu_online_map);
> }
>
> -static inline int cpu_thread_to_core(int cpu)
> -{
> - return cpu >> threads_shift;
> -}
> +#ifdef CONFIG_SMP
> +int cpu_core_index_of_thread(int cpu);
> +int cpu_first_thread_of_core(int core);
> +#else
> +static inline int cpu_core_index_of_thread(int cpu) { return cpu; }
> +static inline int cpu_first_thread_of_core(int core) { return core; }
> +#endif
>
> static inline int cpu_thread_in_core(int cpu)
> {
> return cpu & (threads_per_core - 1);
> }
>
> -static inline int cpu_first_thread_in_core(int cpu)
> +static inline int cpu_first_thread_sibling(int cpu)
> {
> return cpu & ~(threads_per_core - 1);
> }
>
> -static inline int cpu_last_thread_in_core(int cpu)
> +static inline int cpu_last_thread_sibling(int cpu)
> {
> return cpu | (threads_per_core - 1);
> }
> diff --git a/arch/powerpc/kernel/smp.c b/arch/powerpc/kernel/smp.c
> index 0008bc5..012d6e2 100644
> --- a/arch/powerpc/kernel/smp.c
> +++ b/arch/powerpc/kernel/smp.c
> @@ -466,7 +466,20 @@ out:
> return id;
> }
>
> -/* Must be called when no change can occur to cpu_present_mask,
> +/* Helper routines for cpu to core mapping */
> +int cpu_core_index_of_thread(int cpu)
> +{
> + return cpu >> threads_shift;
> +}
> +EXPORT_SYMBOL_GPL(cpu_core_index_of_thread);
> +
> +int cpu_first_thread_of_core(int core)
> +{
> + return core << threads_shift;
> +}
> +EXPORT_SYMBOL_GPL(cpu_first_thread_of_core);
> +
> +/* Must be called when no change can occur to cpu_present_map,
> * i.e. during cpu online or offline.
> */
> static struct device_node *cpu_to_l2cache(int cpu)
> @@ -517,7 +530,7 @@ int __devinit start_secondary(void *unused)
> notify_cpu_starting(cpu);
> set_cpu_online(cpu, true);
> /* Update sibling maps */
> - base =3D cpu_first_thread_in_core(cpu);
> + base =3D cpu_first_thread_sibling(cpu);
> for (i =3D 0; i < threads_per_core; i++) {
> if (cpu_is_offline(base + i))
> continue;
> @@ -596,7 +609,7 @@ int __cpu_disable(void)
> return err;
>
> /* Update sibling maps */
> - base =3D cpu_first_thread_in_core(cpu);
> + base =3D cpu_first_thread_sibling(cpu);
> for (i =3D 0; i < threads_per_core; i++) {
> cpumask_clear_cpu(cpu, cpu_sibling_mask(base + i));
> cpumask_clear_cpu(base + i, cpu_sibling_mask(cpu));
> diff --git a/arch/powerpc/mm/mmu_context_nohash.c b/arch/powerpc/mm/mmu_c=
ontext_nohash.c
> index ddfd7ad..9aa754c 100644
> --- a/arch/powerpc/mm/mmu_context_nohash.c
> +++ b/arch/powerpc/mm/mmu_context_nohash.c
> @@ -111,8 +111,8 @@ static unsigned int steal_context_smp(unsigned int id=
)
> * a core map instead but this will do for now.
> */
> for_each_cpu(cpu, mm_cpumask(mm)) {
> - for (i =3D cpu_first_thread_in_core(cpu);
> - i <=3D cpu_last_thread_in_core(cpu); i++)
> + for (i =3D cpu_first_thread_sibling(cpu);
> + i <=3D cpu_last_thread_sibling(cpu); i++)
> __set_bit(id, stale_map[i]);
> cpu =3D i - 1;
> }
> @@ -264,14 +264,14 @@ void switch_mmu_context(struct mm_struct *prev, str=
uct mm_struct *next)
> */
> if (test_bit(id, stale_map[cpu])) {
> pr_hardcont(" | stale flush %d [%d..%d]",
> - id, cpu_first_thread_in_core(cpu),
> - cpu_last_thread_in_core(cpu));
> + id, cpu_first_thread_sibling(cpu),
> + cpu_last_thread_sibling(cpu));
>
> local_flush_tlb_mm(next);
>
> /* XXX This clear should ultimately be part of local_flush=
_tlb_mm */
> - for (i =3D cpu_first_thread_in_core(cpu);
> - i <=3D cpu_last_thread_in_core(cpu); i++) {
> + for (i =3D cpu_first_thread_sibling(cpu);
> + i <=3D cpu_last_thread_sibling(cpu); i++) {
> __clear_bit(id, stale_map[i]);
> }
> }
>
>
>
> ------------------------------
>
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev
>
> End of Linuxppc-dev Digest, Vol 74, Issue 31
> ********************************************
^ permalink raw reply
* Re: Linux on ppc440gp
From: Benjamin Herrenschmidt @ 2010-10-06 23:51 UTC (permalink / raw)
To: Gorelik, Jacob (335F); +Cc: linuxppc-dev@lists.ozlabs.org
In-Reply-To: <C8D1D750.272D%Jacob.Gorelik@jpl.nasa.gov>
On Wed, 2010-10-06 at 07:35 -0700, Gorelik, Jacob (335F) wrote:
> UIC0 (32 IRQ sources) at DCR 0xc0
> UIC1 (32 IRQ sources) at DCR 0xd0
That looks bad. Your device-tree probably. Check the DCR bindings.
I'm on vacation right now, I don't have time to review it in details,
but ask me again next week if you don't find some help in the meantime.
Cheers,
Ben.
^ permalink raw reply
* Re: use of BAT before taking over the MMU
From: Albert Cahalan @ 2010-10-07 2:05 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: linuxppc-dev
In-Reply-To: <B30ADD93-5210-4FFC-A7AA-C6B21A785B09@kernel.crashing.org>
On Tue, Oct 5, 2010 at 11:31 AM, Segher Boessenkool
<segher@kernel.crashing.org> wrote:
> An OS shouldn't expect to have more than its own program image
> RAM mapped, in general.
Linux actually makes calls to allocate more. I'm thankful
that Linux always specifies an address, so I was able to
get away with simply returning success. I wonder how this
works for a firmware implementation that resides in RAM,
using the memory that Linux demands. Must the firmware
move itself out of the way?
>> Of course that faults immediately, so I have a handler that
>> loads IBAT0 with a 128 KiB mapping. I treat the BAT like a
>> direct-mapped software-loaded TLB. (like MIPS arch MMU)
>
> Just map the first 256MB and don't worry about anything else?
> Seems a lot simpler to me ;-)
I was expecting that Linux would demand plenty of mappings,
including small ones and ones for IO. I was preparing myself
for that.
>> Note that Linux can fail even with a firmware that doesn't touch
>> the BAT registers. The MMU is on,
>
> You can boot Linux with the MMU off as well.
That wasn't obvious for the prom_init path. IEEE docs seemed
to suggest that the firmware must provide MMU handling.
>> and 0xc0000000 may be
>> where the firmware expects to have... MMIO for the console,
>> the client interface entry point, a forth stack, whatever.
>> The BAT takes priority, and thus the firmware splatters stuff
>> right onto the kernel or dies trying to read something it left there.
>
> Like I said, you're supposed to swap OS BATs with firmware BATs
> in your client interface entry and exit. =A0You have to switch
> a lot of other registers there as well already, so that's no
> big deal.
Well no. This isn't real hardware. My prom entry point looks
something like this:
eciwx r0,r0,r0
blr
My ISI and DSI handlers look something like this:
ecowx r0,r0,r0
rfi
The firmware doesn't need **any** registers. It's magic. I was
just using the BAT registers to map what Linux wanted mapped.
Anyway, I'm no longer able to reproduce the problem. I think
something unrelated was causing strange behavior. This is a
bit of a surprise since I would've expected a crash. Oh well.
^ permalink raw reply
* Re: [PATCH 2/2] powerpc/85xx: add DIU support to the Freecale P1022DS reference board
From: Kumar Gala @ 2010-10-07 5:28 UTC (permalink / raw)
To: Timur Tabi; +Cc: linuxppc-dev, linux-fbdev, yorksun
In-Reply-To: <1284057597-17126-2-git-send-email-timur@freescale.com>
On Sep 9, 2010, at 1:39 PM, Timur Tabi wrote:
> +static void p1022ds_set_monitor_port(int monitor_port)
> +{
> + struct device_node *pixis_node;
> + u8 __iomem *brdcfg1;
> +
> + pixis_node = of_find_compatible_node(NULL, NULL, "fsl,fpga-pixis");
> + if (!pixis_node) {
> + pr_err("p1022ds: missing ngPIXIS node\n");
> + return;
> + }
> +
update based on change to compatible in .dts
- k
^ permalink raw reply
* Re: [RFC] arch/powerpc: Remove duplicate/redundant Altivec entries
From: Kumar Gala @ 2010-10-07 5:31 UTC (permalink / raw)
To: Paul Mackerras; +Cc: Matthew McClintock, linuxppc-dev
In-Reply-To: <20100908015916.GB17010@brick.ozlabs.ibm.com>
On Sep 7, 2010, at 8:59 PM, Paul Mackerras wrote:
> On Tue, Sep 07, 2010 at 01:56:55PM -0500, Matthew McClintock wrote:
>=20
>> In lieu of having multiple similiar lines, we can just have one
>> generic cpu-as line for CONFIG_ALTIVEC
>>=20
>> ---
>> Was hoping to get comments about this change and if anyone sees any =
potential
>> problems?
>=20
> I have a memory that we can get some altivec instructions even with
> CONFIG_ALTIVEC =3D n, though presumably they never get executed. We
> would have to check that before applying your patch.
How would we check that?
- k=
^ permalink raw reply
* Re: [PATCH 1/2] powerpc/85xx: add ngPIXIS FPGA device tree node to the P1022DS board
From: Kumar Gala @ 2010-10-07 5:27 UTC (permalink / raw)
To: Timur Tabi; +Cc: Linuxppc-dev list, York Sun
In-Reply-To: <1284057597-17126-1-git-send-email-timur@freescale.com>
On Sep 9, 2010, at 1:39 PM, Timur Tabi wrote:
> The device tree for Freescale's P1022DS reference board is missing the =
node
> for the ngPIXIS FPGA.
>=20
> Signed-off-by: Timur Tabi <timur@freescale.com>
> ---
> arch/powerpc/boot/dts/p1022ds.dts | 9 +++++++++
> 1 files changed, 9 insertions(+), 0 deletions(-)
>=20
> diff --git a/arch/powerpc/boot/dts/p1022ds.dts =
b/arch/powerpc/boot/dts/p1022ds.dts
> index 8bcb10b..e61b42d 100644
> --- a/arch/powerpc/boot/dts/p1022ds.dts
> +++ b/arch/powerpc/boot/dts/p1022ds.dts
> @@ -148,6 +148,15 @@
> label =3D "reserved-nand";
> };
> };
> +
> + board-control@3,0 {
> + #address-cells =3D <1>;
> + #size-cells =3D <1>;
these aren't need if we don't have a child node.
> + compatible =3D "fsl,fpga-pixis";
lets make this "fsl,p1022ds-pixis"
> + reg =3D <3 0 0x30>;
> + interrupt-parent =3D <&mpic>;
> + interrupts =3D <8 8>;
what do we think about adding a comment about what this interrupt is for
> + };
> };
>=20
> soc@fffe00000 {
> --=20
> 1.7.2.2
>=20
>=20
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev
^ permalink raw reply
* Re: [PATCH 1/2] [v2] powerpc: export ppc_proc_freq and ppc_tb_freq as GPL symbols
From: Kumar Gala @ 2010-10-07 5:59 UTC (permalink / raw)
To: Timur Tabi; +Cc: linux-watchdog, linuxppc-dev
In-Reply-To: <1284999822-24753-1-git-send-email-timur@freescale.com>
On Sep 20, 2010, at 11:23 AM, Timur Tabi wrote:
> Export the global variable 'ppc_tb_freq', so that modules (like the =
Book-E
> watchdog driver) can use it. To maintain consistency, ppc_proc_freq =
is changed
> to a GPL-only export. This is okay, because any module that needs =
this symbol
> should be an actual Linux driver, which must be GPL-licensed.
>=20
> Signed-off-by: Timur Tabi <timur@freescale.com>
> ---
>=20
> This export is necessary for the Book-E watchdog driver to be compiled =
as a
> module.
>=20
> arch/powerpc/kernel/time.c | 3 ++-
> 1 files changed, 2 insertions(+), 1 deletions(-)
applied to next
- k=
^ permalink raw reply
* Re: [PATCH 1/4] powerpc/kexec: make masking/disabling interrupts generic
From: Kumar Gala @ 2010-10-07 6:00 UTC (permalink / raw)
To: Matthew McClintock; +Cc: linuxppc-dev
In-Reply-To: <1284677906-23787-1-git-send-email-msm@freescale.com>
On Sep 16, 2010, at 5:58 PM, Matthew McClintock wrote:
> Right now just the kexec crash pathway turns turns off the
> interrupts. Pull that out and make a generic version for
> use elsewhere
>
> Signed-off-by: Matthew McClintock <msm@freescale.com>
> ---
> arch/powerpc/include/asm/kexec.h | 1 +
> arch/powerpc/kernel/crash.c | 13 +------------
> arch/powerpc/kernel/machine_kexec.c | 24 ++++++++++++++++++++++++
> arch/powerpc/kernel/machine_kexec_32.c | 4 ++++
> 4 files changed, 30 insertions(+), 12 deletions(-)
applied to next
- k
^ permalink raw reply
* Re: [PATCH 3/4] powerpc/85xx: Minor fixups for kexec on 85xx
From: Kumar Gala @ 2010-10-07 6:00 UTC (permalink / raw)
To: Matthew McClintock; +Cc: linuxppc-dev
In-Reply-To: <1284677906-23787-3-git-send-email-msm@freescale.com>
On Sep 16, 2010, at 5:58 PM, Matthew McClintock wrote:
> Make kexec_down_cpus atmoic since it will be incremented by all
> cores as they are coming down
>
> Remove duplicate calls to mpc85xx_smp_kexec_down, now it's called
> by the crash and normal kexec pathway only once
>
> Increase the timeout to wait for other cores to shutdown
>
> Signed-off-by: Matthew McClintock <msm@freescale.com>
> ---
> arch/powerpc/platforms/85xx/smp.c | 24 +++++++++++-------------
> 1 files changed, 11 insertions(+), 13 deletions(-)
applied to next
- k
^ permalink raw reply
* Re: [PATCH][v3] mpc8308_p1m: support for MPC8308 P1M board
From: Kumar Gala @ 2010-10-07 6:00 UTC (permalink / raw)
To: Ilya Yanok; +Cc: scottwood, vlad, linuxppc-dev, wd, dzu
In-Reply-To: <1283990116-29441-1-git-send-email-yanok@emcraft.com>
On Sep 8, 2010, at 6:55 PM, Ilya Yanok wrote:
> This patch adds support for MPC8308 P1M board.
> Supported devices:
> DUART
> Dual Ethernet
> NOR flash
> Both I2C controllers
> USB in peripheral mode
> PCI Express
>=20
> Signed-off-by: Ilya Yanok <yanok@emcraft.com>
> ---
>=20
> Changed 'compatible' entry for 'cpld' node to "denx,mpc8308_p1m-cpld"
>=20
> arch/powerpc/boot/dts/mpc8308_p1m.dts | 332 =
+++++++++++++++++++++++++++++
> arch/powerpc/platforms/83xx/Kconfig | 4 +-
> arch/powerpc/platforms/83xx/mpc830x_rdb.c | 3 +-
> 3 files changed, 336 insertions(+), 3 deletions(-)
> create mode 100644 arch/powerpc/boot/dts/mpc8308_p1m.dts
applied to next
- k=
^ permalink raw reply
* Re: [PATCH] powerpc/fsl-pci: Fix MSI support on 83xx platforms
From: Kumar Gala @ 2010-10-07 6:01 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev, wd, yanok
In-Reply-To: <1280995347-6550-1-git-send-email-galak@kernel.crashing.org>
On Aug 5, 2010, at 3:02 AM, Kumar Gala wrote:
> The following commit broke 83xx because it assumed the 83xx platforms
> exposed the "IMMR" address in BAR0 like the 85xx/86xx/QoriQ devices =
do:
>=20
> commit 3da34aae03d498ee62f75aa7467de93cce3030fd
> Author: Kumar Gala <galak@kernel.crashing.org>
> Date: Tue May 12 15:51:56 2009 -0500
>=20
> powerpc/fsl: Support unique MSI addresses per PCIe Root Complex
>=20
> However that is not true, so we have to search through the inbound
> window settings on 83xx to find which one matches the IMMR address to
> determine its PCI address.
>=20
> Reported-by: Ilya Yanok <yanok@emcraft.com>
> Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
> ---
> arch/powerpc/sysdev/fsl_msi.c | 9 +++----
> arch/powerpc/sysdev/fsl_pci.c | 43 =
++++++++++++++++++++++++++++++++++++++++-
> arch/powerpc/sysdev/fsl_pci.h | 1 +
> 3 files changed, 47 insertions(+), 6 deletions(-)
applied to next
- k=
^ permalink raw reply
* Re: [PATCH 2/4] powerpc/85xx: Remove call to mpic_teardown_this_cpu in kexec
From: Kumar Gala @ 2010-10-07 6:00 UTC (permalink / raw)
To: Matthew McClintock; +Cc: linuxppc-dev
In-Reply-To: <1284677906-23787-2-git-send-email-msm@freescale.com>
On Sep 16, 2010, at 5:58 PM, Matthew McClintock wrote:
> We no longer need to call this explicitly as a generic version is
> called by default
>
> Signed-off-by: Matthew McClintock <msm@freescale.com>
> ---
> arch/powerpc/platforms/85xx/smp.c | 2 --
> 1 files changed, 0 insertions(+), 2 deletions(-)
applied to next
- k
^ permalink raw reply
* Re: [PATCH 2/2] [v2] powerpc/watchdog: allow the e500 watchdog driver to be compiled as a module
From: Kumar Gala @ 2010-10-07 6:00 UTC (permalink / raw)
To: Timur Tabi; +Cc: linux-watchdog, linuxppc-dev
In-Reply-To: <1284999822-24753-2-git-send-email-timur@freescale.com>
On Sep 20, 2010, at 11:23 AM, Timur Tabi wrote:
> Register the __init and __exit functions in the PowerPC e500 watchdog =
driver
> as module entry/exit functions, and modify the Kconfig entry.
>=20
> Add a .release method for the PowerPC e500 watchdog driver, so that =
the
> watchdog is disabled when the driver is closed.
>=20
> Loosely based on original code from Jiang Yutang =
<b14898@freescale.com>.
>=20
> Signed-off-by: Timur Tabi <timur@freescale.com>
> ---
>=20
> This patch requires:
>=20
> powerpc: export ppc_proc_freq and ppc_tb_freq as GPL symbols
>=20
> drivers/watchdog/Kconfig | 5 ++++-
> drivers/watchdog/booke_wdt.c | 39 =
+++++++++++++++++++++++++++++++++++++--
> 2 files changed, 41 insertions(+), 3 deletions(-)
applied to next [fixed comment message to say Book-E instead of e500]
- k=
^ permalink raw reply
* Re: [PATCH] powerpc: Fix invalid page flags in create TLB CAM path for PTE_64BIT
From: Kumar Gala @ 2010-10-07 6:05 UTC (permalink / raw)
To: Paul Gortmaker; +Cc: Scott Wood, linuxppc-dev
In-Reply-To: <20100924164451.GA14042@windriver.com>
On Sep 24, 2010, at 11:44 AM, Paul Gortmaker wrote:
>>=20
>> =46rom d48ebb58b8214f9faec775a5e06902f638f165cf Mon Sep 17 00:00:00 =
2001
> From: Tiejun Chen <tiejun.chen@windriver.com>
> Date: Tue, 21 Sep 2010 19:31:31 +0800
> Subject: [PATCH] powerpc: Fix invalid page flags in create TLB CAM =
path for PTE_64BIT
>=20
> There exists a four line chunk of code, which when configured for
> 64 bit address space, can incorrectly set certain page flags during
> the TLB creation. It turns out that this is code which isn't used,
> but might still serve a purpose. Since it isn't obvious why it exists
> or why it causes problems, the below description covers both in =
detail.
>=20
> For powerpc bootstrap, the physical memory (at most 768M), is mapped
> into the kernel space via the following path:
>=20
> MMU_init()
> |
> + adjust_total_lowmem()
> |
> + map_mem_in_cams()
> |
> + settlbcam(i, virt, phys, cam_sz, PAGE_KERNEL_X, =
0);
>=20
> On settlbcam(), the kernel will create TLB entries according to the =
flag,
> PAGE_KERNEL_X.
>=20
> settlbcam()
> {
> ...
> TLBCAM[index].MAS1 =3D MAS1_VALID
> | MAS1_IPROT | MAS1_TSIZE(tsize) | =
MAS1_TID(pid);
> ^
> These entries cannot be invalidated by the
> kernel since MAS1_IPROT is set on TLB property.
> ...
> if (flags & _PAGE_USER) {
> TLBCAM[index].MAS3 |=3D MAS3_UX | MAS3_UR;
> TLBCAM[index].MAS3 |=3D ((flags & _PAGE_RW) ? MAS3_UW : 0);
> }
>=20
> For classic BookE (flags & _PAGE_USER) is 'zero' so it's fine.
> But on boards like the the Freescale P4080, we want to support 36-bit
> physical address on it. So the following options may be set:
>=20
> CONFIG_FSL_BOOKE=3Dy
> CONFIG_PTE_64BIT=3Dy
> CONFIG_PHYS_64BIT=3Dy
>=20
> As a result, boards like the P4080 will introduce PTE format as =
Book3E.
> As per the file: arch/powerpc/include/asm/pgtable-ppc32.h
>=20
> * #elif defined(CONFIG_FSL_BOOKE) && defined(CONFIG_PTE_64BIT)
> * #include <asm/pte-book3e.h>
>=20
> So PAGE_KERNEL_X is __pgprot(_PAGE_BASE | _PAGE_KERNEL_RWX) and the
> book3E version of _PAGE_KERNEL_RWX is defined with:
>=20
> (_PAGE_BAP_SW | _PAGE_BAP_SR | _PAGE_DIRTY | _PAGE_BAP_SX)
>=20
> Note the _PAGE_BAP_SR, which is also defined in the book3E _PAGE_USER:
>=20
> #define _PAGE_USER (_PAGE_BAP_UR | _PAGE_BAP_SR) /* Can be =
read */
>=20
> So the possibility exists to wrongly assign the user MAS3_U<RWX> bits
> to kernel (PAGE_KERNEL_X) address space via the following code =
fragment:
>=20
> if (flags & _PAGE_USER) {
> TLBCAM[index].MAS3 |=3D MAS3_UX | MAS3_UR;
> TLBCAM[index].MAS3 |=3D ((flags & _PAGE_RW) ? MAS3_UW : 0);
> }
>=20
> Here is a dump of the TLB info from Simics with the above code =
present:
> ------
> L2 TLB1
> GT SSS =
UUU V I
> Row Logical Physical SS TLPID TID WIMGE XWR =
XWR F P V
> ----- ----------------- ------------------- -- ----- ----- ----- --- =
--- - - -
> 0 c0000000-cfffffff 000000000-00fffffff 00 0 0 M XWR =
XWR 0 1 1
> 1 d0000000-dfffffff 010000000-01fffffff 00 0 0 M XWR =
XWR 0 1 1
> 2 e0000000-efffffff 020000000-02fffffff 00 0 0 M XWR =
XWR 0 1 1
>=20
> Actually this conditional code was used for two legacy functions:
>=20
> 1: support KGDB to set break point.
> KGDB already dropped this; now uses its core write to set break =
point.
>=20
> 2: io_block_mapping() to create TLB in segmentation size (not =
PAGE_SIZE)
> for device IO space.
> This use case is also removed from the latest PowerPC kernel.
>=20
> However, there may still be a use case for it in the future, like
> large user pages, so we can't remove it entirely. As an alternative,
> we match on all bits of _PAGE_USER instead of just any bits, so the
> case where just _PAGE_BAP_SR is set can't sneak through.
>=20
> With this done, the TLB appears without U having XWR as below:
>=20
> -------
> L2 TLB1
> GT SSS =
UUU V I
> Row Logical Physical SS TLPID TID WIMGE XWR =
XWR F P V
> ----- ----------------- ------------------- -- ----- ----- ----- --- =
--- - - -
> 0 c0000000-cfffffff 000000000-00fffffff 00 0 0 M XWR =
0 1 1
> 1 d0000000-dfffffff 010000000-01fffffff 00 0 0 M XWR =
0 1 1
> 2 e0000000-efffffff 020000000-02fffffff 00 0 0 M XWR =
0 1 1
>=20
> Signed-off-by: Tiejun Chen <tiejun.chen@windriver.com>
> Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
> ---
> arch/powerpc/include/asm/pte-common.h | 7 +++++++
> arch/powerpc/mm/fsl_booke_mmu.c | 3 ++-
> 2 files changed, 9 insertions(+), 1 deletions(-)
applied to next
- k
^ permalink raw reply
* Re: [PATCH 4/4] powerpc/85xx: flush dcache before resetting cores
From: Kumar Gala @ 2010-10-07 6:00 UTC (permalink / raw)
To: Matthew McClintock; +Cc: linuxppc-dev
In-Reply-To: <1284677906-23787-4-git-send-email-msm@freescale.com>
On Sep 16, 2010, at 5:58 PM, Matthew McClintock wrote:
> When we do an mpic_reset_core we need to make sure the dcache
> is flushed
>=20
> Signed-off-by: Matthew McClintock <msm@freescale.com>
> ---
> arch/powerpc/platforms/85xx/smp.c | 50 =
+++++++++++++++++++++++++++++++++++++
> 1 files changed, 50 insertions(+), 0 deletions(-)
applied to next
- k=
^ permalink raw reply
* Re: [PATCH v2] powerpc/fsl_soc: Search all global-utilities nodes for rstccr
From: Kumar Gala @ 2010-10-07 6:10 UTC (permalink / raw)
To: Matthew McClintock; +Cc: linuxppc-dev, timur
In-Reply-To: <1283294691-18765-1-git-send-email-msm@freescale.com>
On Aug 31, 2010, at 5:44 PM, Matthew McClintock wrote:
> The first global-utilities node might not contain the rstcr
> property, so we should search all the nodes
>
> Signed-off-by: Matthew McClintock <msm@freescale.com>
> ---
> -Changed KERN_EMERG to KERN_ERR
> -Break if we do not find rstcr mapped
> -Restore of_put_node that was dropped
>
> arch/powerpc/sysdev/fsl_soc.c | 20 +++++++++++++-------
> 1 files changed, 13 insertions(+), 7 deletions(-)
applied to next
- k
^ permalink raw reply
* Re: [PATCH] edac: mpc85xx: Add support for new MPCxxx/Pxxxx EDAC controllers (fix)
From: Kumar Gala @ 2010-10-07 6:18 UTC (permalink / raw)
To: Anton Vorontsov
Cc: linuxppc-dev, linux-kernel, Dave Jiang, Peter Tyser,
Doug Thompson, Scott Wood, Andrew Morton
In-Reply-To: <20100801105419.GA352@oksana.dev.rtsoft.ru>
On Aug 1, 2010, at 5:54 AM, Anton Vorontsov wrote:
> On Wed, Jul 21, 2010 at 06:21:08PM -0500, Scott Wood wrote:
> [...]
>>>>> + { .compatible =3D "fsl,p4080-l2-cache-controller", },
>>>>=20
>>>> L2 on the p4080 is quite different from those other chips. It's =
part
>>>> of the core, controlled by SPRs.
>>>=20
>>> erm, was that an ack or a nack?
>>=20
>> NACK, p4080 doesn't belong in this table, at least not its L2.
>>=20
>> L3 on p4080 is similar to L2 on these other chips, though, and it
>> wouldn't take much to get this driver working on it -- but the match
>> table entry should wait until the differences are accommodated.
>=20
> Signed-off-by: Anton Vorontsov <avorontsov@mvista.com>
> ---
>=20
> Scott, thanks for catching this!
>=20
> Andrew, please merge this patch into
> edac-mpc85xx-add-support-for-new-mpcxxx-pxxxx-edac-controllers.patch
>=20
> Thanks!
>=20
> drivers/edac/mpc85xx_edac.c | 1 -
> 1 files changed, 0 insertions(+), 1 deletions(-)
>=20
> diff --git a/drivers/edac/mpc85xx_edac.c b/drivers/edac/mpc85xx_edac.c
> index cfa86f7..b178cfa 100644
> --- a/drivers/edac/mpc85xx_edac.c
> +++ b/drivers/edac/mpc85xx_edac.c
> @@ -652,7 +652,6 @@ static struct of_device_id =
mpc85xx_l2_err_of_match[] =3D {
> { .compatible =3D "fsl,p1020-l2-cache-controller", },
> { .compatible =3D "fsl,p1021-l2-cache-controller", },
> { .compatible =3D "fsl,p2020-l2-cache-controller", },
> - { .compatible =3D "fsl,p4080-l2-cache-controller", },
> {},
> };
> MODULE_DEVICE_TABLE(of, mpc85xx_l2_err_of_match);
> --=20
> 1.7.0.5
Can you post a new patch as it doesn't look like this got merged by =
Andrew so we need to clean up after ourselves.
- k
^ permalink raw reply
* Re: [PATCH 2/2] powerpc/fsl_booke: Add support to boot from core other than 0
From: Kumar Gala @ 2010-10-07 6:10 UTC (permalink / raw)
To: Matthew McClintock; +Cc: linuxppc-dev
In-Reply-To: <1283297085-3455-2-git-send-email-msm@freescale.com>
On Aug 31, 2010, at 6:24 PM, Matthew McClintock wrote:
> First we check to see if we are the first core booting up. This
> is accomplished by comparing the boot_cpuid with -1, if it is we
> assume this is the first core coming up.
>
> Secondly, we need to update the initial thread info structure
> to reflect the actual cpu we are running on otherwise
> smp_processor_id() and related functions will return the default
> initialization value of the struct or 0.
>
> Signed-off-by: Matthew McClintock <msm@freescale.com>
> ---
> arch/powerpc/kernel/head_fsl_booke.S | 10 ++++++++--
> arch/powerpc/kernel/setup_32.c | 2 +-
> 2 files changed, 9 insertions(+), 3 deletions(-)
Are we sticking with this or not?
- k
^ permalink raw reply
* Re: [PATCH] edac: mpc85xx: Add support for new MPCxxx/Pxxxx EDAC controllers (fix)
From: Anton Vorontsov @ 2010-10-07 6:29 UTC (permalink / raw)
To: Kumar Gala
Cc: linuxppc-dev, linux-kernel, Dave Jiang, Peter Tyser,
Doug Thompson, Scott Wood, Andrew Morton
In-Reply-To: <5628792F-9A5F-4200-90B3-FB3939F02969@kernel.crashing.org>
On Thu, Oct 07, 2010 at 01:18:19AM -0500, Kumar Gala wrote:
[...]
> > diff --git a/drivers/edac/mpc85xx_edac.c b/drivers/edac/mpc85xx_edac.c
> > index cfa86f7..b178cfa 100644
> > --- a/drivers/edac/mpc85xx_edac.c
> > +++ b/drivers/edac/mpc85xx_edac.c
> > @@ -652,7 +652,6 @@ static struct of_device_id mpc85xx_l2_err_of_match[] = {
> > { .compatible = "fsl,p1020-l2-cache-controller", },
> > { .compatible = "fsl,p1021-l2-cache-controller", },
> > { .compatible = "fsl,p2020-l2-cache-controller", },
> > - { .compatible = "fsl,p4080-l2-cache-controller", },
> > {},
> > };
> > MODULE_DEVICE_TABLE(of, mpc85xx_l2_err_of_match);
> > --
> > 1.7.0.5
>
> Can you post a new patch as it doesn't look like this got merged by Andrew so we need to clean up after ourselves.
It's already in Linus' tree.
Thanks,
- - - -
commit cd1542c8197fc3c2eb3a8301505d5d9738fab1e4
Author: Anton Vorontsov <avorontsov@mvista.com>
Date: Tue Aug 10 18:03:21 2010 -0700
edac: mpc85xx: add support for new MPCxxx/Pxxxx EDAC controllers
Simply add proper IDs into the device table.
Signed-off-by: Anton Vorontsov <avorontsov@mvista.com>
Cc: Scott Wood <scottwood@freescale.com>
Cc: Peter Tyser <ptyser@xes-inc.com>
Cc: Dave Jiang <djiang@mvista.com>
Cc: Doug Thompson <dougthompson@xmission.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
diff --git a/drivers/edac/mpc85xx_edac.c b/drivers/edac/mpc85xx_edac.c
index fdbad55..af75e27 100644
--- a/drivers/edac/mpc85xx_edac.c
+++ b/drivers/edac/mpc85xx_edac.c
@@ -647,7 +647,10 @@ static struct of_device_id mpc85xx_l2_err_of_match[] = {
{ .compatible = "fsl,mpc8555-l2-cache-controller", },
{ .compatible = "fsl,mpc8560-l2-cache-controller", },
{ .compatible = "fsl,mpc8568-l2-cache-controller", },
+ { .compatible = "fsl,mpc8569-l2-cache-controller", },
{ .compatible = "fsl,mpc8572-l2-cache-controller", },
+ { .compatible = "fsl,p1020-l2-cache-controller", },
+ { .compatible = "fsl,p1021-l2-cache-controller", },
{ .compatible = "fsl,p2020-l2-cache-controller", },
{},
};
@@ -1125,7 +1128,10 @@ static struct of_device_id mpc85xx_mc_err_of_match[] = {
{ .compatible = "fsl,mpc8569-memory-controller", },
{ .compatible = "fsl,mpc8572-memory-controller", },
{ .compatible = "fsl,mpc8349-memory-controller", },
+ { .compatible = "fsl,p1020-memory-controller", },
+ { .compatible = "fsl,p1021-memory-controller", },
{ .compatible = "fsl,p2020-memory-controller", },
+ { .compatible = "fsl,p4080-memory-controller", },
{},
};
MODULE_DEVICE_TABLE(of, mpc85xx_mc_err_of_match);
^ permalink raw reply related
* Re: [PATCH] powerpc/p1022: add probing for individual DMA channels, not just DMA controllers
From: Kumar Gala @ 2010-10-07 6:27 UTC (permalink / raw)
To: Timur Tabi; +Cc: linuxppc-dev
In-Reply-To: <1282253292-19420-1-git-send-email-timur@freescale.com>
On Aug 19, 2010, at 4:28 PM, Timur Tabi wrote:
> Like the MPC8610 HPCD, the P1022DS ASoC DMA driver probes on =
individual DMA
> channel nodes, so the DMA controller nodes' compatible string must be =
listed in
> p1022_ds_ids[] to work.
>=20
> Signed-off-by: Timur Tabi <timur@freescale.com>
> ---
>=20
> This is for -next.
>=20
> I don't know why I forgot to include this change in the original =
P1022DS patch.
>=20
> arch/powerpc/platforms/85xx/p1022_ds.c | 2 ++
> 1 files changed, 2 insertions(+), 0 deletions(-)
applied to next
- k=
^ permalink raw reply
* Re: [PATCH] edac: mpc85xx: Add support for new MPCxxx/Pxxxx EDAC controllers (fix)
From: Kumar Gala @ 2010-10-07 6:37 UTC (permalink / raw)
To: Anton Vorontsov
Cc: linuxppc-dev, linux-kernel, Dave Jiang, Peter Tyser,
Doug Thompson, Scott Wood, Andrew Morton
In-Reply-To: <20101007062909.GA27110@oksana.dev.rtsoft.ru>
>=20
> It's already in Linus' tree.
Yeah, the problem is what's merged in linus's tree has p4080 listed and =
it shouldn't
>=20
> Thanks,
>=20
> - - - -
> commit cd1542c8197fc3c2eb3a8301505d5d9738fab1e4
> Author: Anton Vorontsov <avorontsov@mvista.com>
> Date: Tue Aug 10 18:03:21 2010 -0700
>=20
> edac: mpc85xx: add support for new MPCxxx/Pxxxx EDAC controllers
>=20
> Simply add proper IDs into the device table.
>=20
> Signed-off-by: Anton Vorontsov <avorontsov@mvista.com>
> Cc: Scott Wood <scottwood@freescale.com>
> Cc: Peter Tyser <ptyser@xes-inc.com>
> Cc: Dave Jiang <djiang@mvista.com>
> Cc: Doug Thompson <dougthompson@xmission.com>
> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
>=20
> diff --git a/drivers/edac/mpc85xx_edac.c b/drivers/edac/mpc85xx_edac.c
> index fdbad55..af75e27 100644
> --- a/drivers/edac/mpc85xx_edac.c
> +++ b/drivers/edac/mpc85xx_edac.c
> @@ -647,7 +647,10 @@ static struct of_device_id =
mpc85xx_l2_err_of_match[] =3D {
> { .compatible =3D "fsl,mpc8555-l2-cache-controller", },
> { .compatible =3D "fsl,mpc8560-l2-cache-controller", },
> { .compatible =3D "fsl,mpc8568-l2-cache-controller", },
> + { .compatible =3D "fsl,mpc8569-l2-cache-controller", },
> { .compatible =3D "fsl,mpc8572-l2-cache-controller", },
> + { .compatible =3D "fsl,p1020-l2-cache-controller", },
> + { .compatible =3D "fsl,p1021-l2-cache-controller", },
> { .compatible =3D "fsl,p2020-l2-cache-controller", },
> {},
> };
> @@ -1125,7 +1128,10 @@ static struct of_device_id =
mpc85xx_mc_err_of_match[] =3D {
> { .compatible =3D "fsl,mpc8569-memory-controller", },
> { .compatible =3D "fsl,mpc8572-memory-controller", },
> { .compatible =3D "fsl,mpc8349-memory-controller", },
> + { .compatible =3D "fsl,p1020-memory-controller", },
> + { .compatible =3D "fsl,p1021-memory-controller", },
> { .compatible =3D "fsl,p2020-memory-controller", },
> + { .compatible =3D "fsl,p4080-memory-controller", },
This line should be here ;)
> {},
> };
> MODULE_DEVICE_TABLE(of, mpc85xx_mc_err_of_match);
^ permalink raw reply
* Re: [PATCH] edac: mpc85xx: Add support for new MPCxxx/Pxxxx EDAC controllers (fix)
From: Kumar Gala @ 2010-10-07 7:00 UTC (permalink / raw)
To: Kumar Gala
Cc: linuxppc-dev, Doug Thompson, linux-kernel, Dave Jiang,
Peter Tyser, Scott Wood, Andrew Morton
In-Reply-To: <0778A3B9-E242-4BCC-B318-154BE9ECB2C6@kernel.crashing.org>
On Oct 7, 2010, at 1:37 AM, Kumar Gala wrote:
>> @ -1125,7 +1128,10 @@ static struct of_device_id =
mpc85xx_mc_err_of_match[] =3D {
>> { .compatible =3D "fsl,mpc8569-memory-controller", },
>> { .compatible =3D "fsl,mpc8572-memory-controller", },
>> { .compatible =3D "fsl,mpc8349-memory-controller", },
>> + { .compatible =3D "fsl,p1020-memory-controller", },
>> + { .compatible =3D "fsl,p1021-memory-controller", },
>> { .compatible =3D "fsl,p2020-memory-controller", },
>> + { .compatible =3D "fsl,p4080-memory-controller", },
>=20
> This line should be here ;)
should NOT be here.
- k=
^ permalink raw reply
* Re: [PATCH] edac: mpc85xx: Add support for new MPCxxx/Pxxxx EDAC controllers (fix)
From: Anton Vorontsov @ 2010-10-07 7:12 UTC (permalink / raw)
To: Kumar Gala
Cc: linuxppc-dev, linux-kernel, Dave Jiang, Peter Tyser,
Doug Thompson, Scott Wood, Andrew Morton
In-Reply-To: <4A00FECC-3840-45E1-AB2A-6BDBD0FE09E0@kernel.crashing.org>
On Thu, Oct 07, 2010 at 02:00:50AM -0500, Kumar Gala wrote:
>
> On Oct 7, 2010, at 1:37 AM, Kumar Gala wrote:
>
> >> @ -1125,7 +1128,10 @@ static struct of_device_id mpc85xx_mc_err_of_match[] = {
> >> { .compatible = "fsl,mpc8569-memory-controller", },
> >> { .compatible = "fsl,mpc8572-memory-controller", },
> >> { .compatible = "fsl,mpc8349-memory-controller", },
> >> + { .compatible = "fsl,p1020-memory-controller", },
> >> + { .compatible = "fsl,p1021-memory-controller", },
> >> { .compatible = "fsl,p2020-memory-controller", },
> >> + { .compatible = "fsl,p4080-memory-controller", },
> >
> > This line should be here ;)
>
> should NOT be here.
Hm. Are you sure? I thought that only L2 cache controller is
not applicable (and based on Scott's comment I removed
the l2 cache compatible entry for p4080). But I guess
memory-controller is somewhat similar to all other 85xx?
If it's not, I can surely prepare a patch that removes
p4080 entry.
Thanks,
--
Anton Vorontsov
email: cbouatmailru@gmail.com
irc://irc.freenode.net/bd2
^ permalink raw reply
* Re: Linux on ppc440gp
From: Stefan Roese @ 2010-10-07 7:32 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Gorelik, Jacob (335F)
In-Reply-To: <1286409104.2463.373.camel@pasglop>
On Thursday 07 October 2010 01:51:44 Benjamin Herrenschmidt wrote:
> On Wed, 2010-10-06 at 07:35 -0700, Gorelik, Jacob (335F) wrote:
> > UIC0 (32 IRQ sources) at DCR 0xc0
> > UIC1 (32 IRQ sources) at DCR 0xd0
>
> That looks bad. Your device-tree probably. Check the DCR bindings.
Why does this look bad? On 440EPx this looks like this:
UIC0 (32 IRQ sources) at DCR 0xc0
UIC1 (32 IRQ sources) at DCR 0xd0
UIC2 (32 IRQ sources) at DCR 0xe0
So I don't see a problem with the output above.
Cheers,
Stefan
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox