* Re: [PATCH] powerpc/mm: add ZONE_NORMAL zone for 64 bit kernel
From: Scott Wood @ 2012-07-23 16:17 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: Mingkai Hu, linuxppc-dev, Shaohui Xie, Chen Yuanquan
In-Reply-To: <1343023569.2957.19.camel@pasglop>
On 07/23/2012 01:06 AM, Benjamin Herrenschmidt wrote:
> On Fri, 2012-07-20 at 20:21 +0800, Shaohui Xie wrote:
>> PowerPC platform only supports ZONE_DMA zone for 64bit kernel, so all the
>> memory will be put into this zone. If the memory size is greater than
>> the device's DMA capability and device uses dma_alloc_coherent to allocate
>> memory, it will get an address which is over the device's DMA addressing,
>> the device will fail.
>>
>> So we split the memory to two zones by adding a zone ZONE_NORMAL, since
>> we already allocate PCICSRBAR/PEXCSRBAR right below the 4G boundary (if the
>> lowest PCI address is above 4G), so we constrain the DMA zone ZONE_DMA
>> to 2GB, also, we clear the flag __GFP_DMA and set it only if the device's
>> dma_mask < total memory size. By doing this, devices which cannot DMA all
>> the memory will be limited to ZONE_DMA, but devices which can DMA all the
>> memory will not be affected by this limitation.
>
> This is wrong.
How so?
> Don't you have an iommu do deal with those devices anyway ?
Yes, but we don't yet have DMA API support for it, it would lower
performance because we'd have to use a lot of subwindows which are
poorly cached (and even then we wouldn't be able to map more than 256
pages at once on a given device), and the IOMMU may not be available at
all if we're being virtualized.
> What about swiotlb ?
That doesn't help with alloc_coherent().
> If you *really* need to honor 32 (or 31 even) bit DMAs,
31-bit is to accommodate PCI, which has PEXCSRBAR that must live under 4
GiB and can't be disabled.
> what you -may- want to do is create a ZONE_DMA32 like other architectures, do not
> hijack the historical ZONE_DMA.
Could you point me to somewhere that clearly defines what ZONE_DMA is to
be used for, such that this counts as hijacking (but using ZONE_DMA32 to
mean 31-bit wouldn't)? The only arches I see using ZONE_DMA32 (x86 and
mips) also have a separate, more restrictive ZONE_DMA. PowerPC doesn't.
It uses ZONE_DMA to point to all of memory (except highmem on 32-bit)
-- how is that not hijacking, if this is? We can't have ZONE_DMA be
less restrictive than ZONE_DMA32, because the fallback rules are
hardcoded the other way around in generic code.
The exact threshold for ZONE_DMA could be made platform-configurable.
> But even then, I'm dubious this is really needed.
We'd like our drivers to stop crashing with more than 4GiB of RAM on 64-bit.
-Scott
^ permalink raw reply
* Re: [2/3][PATCH][upstream] TDM Framework
From: Tabi Timur-B04825 @ 2012-07-23 16:33 UTC (permalink / raw)
To: Singh Sandeep-B37400
Cc: Aggrwal Poonam-B10812, linuxppc-dev@lists.ozlabs.org,
Singh Sandeep-B37400
In-Reply-To: <1343040588-16002-1-git-send-email-b37400@freescale.com>
On Mon, Jul 23, 2012 at 5:49 AM, <b37400@freescale.com> wrote:
> From: Sandeep Singh <Sandeep@freescale.com>
Please fix your git configuration so that the From: line in your
emails contains your full name. This patch was sent with this From:
line:
From: <b37400@freescale.com>
It should say:
From: Sandeep Singh <sandeep@freescale.com>
Three more things:
1) You don't need to add [upstream] to patches that are posted upstream.
2) This patch needs to be CC'd to linux-kernel@vger.kernel.org and
devel@driverdev.osuosl.org.
3) I'm concerned that there is no "struct device" anywhere in this
framework. I think that's a serious omission, and you need to figure
out where you can put this.
> diff --git a/drivers/tdm/tdm-core.c b/drivers/tdm/tdm-core.c
> new file mode 100644
> index 0000000..9973b6b
> --- /dev/null
> +++ b/drivers/tdm/tdm-core.c
> @@ -0,0 +1,1082 @@
> +/* driver/tdm/tdm-core.c
> + *
> + * Copyright (C) 2012 Freescale Semiconductor, Inc, All rights reserved.
I've been seeing this copyright messages a lot recently, and I don't
understand why. This message is incorrectly formatted. The "(C)" is
redundant, and the phrase "All rights reserved." is wrong. This patch
is licensed under the GPL, so we are NOT reserving all rights, we are
actually giving up some rights.
Please change this to:
Copyright 2012 Freescale Semiconductor, Inc.
> + *
> + * TDM core is the interface between TDM clients and TDM devices.
> + * It is also intended to serve as an interface for line controlled
> + * devices later on.
> + *
> + * Author:Hemant Agrawal <hemant@freescale.com>
> + * Rajesh Gumasta <rajesh.gumasta@freescale.com>
If these two are the authors, why are they not on the signed-off-by lines?
> + *
> + * Modified by Sandeep Kr Singh <sandeep@freescale.com>
> + * Poonam Aggarwal <poonam.aggarwal@freescale.com>
Do not add "modified" by lines to the code. That's why we have a git histo=
ry.
> + * 1. Added framework based initialization of device.
> + * 2. All the init/run time configuration is now done by framework.
> + * 3. Added channel level operations.
> + * 4. Added sysfs knob to configure use_latest_tdm_data at runtime.
Again, this is not information that belongs in the source file.
> + *
> + * Note that some parts of this code may have been derived from i2c subs=
ystem.
> + *
> + * 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 y=
our
> + * option) any later version.
> + *
> + * This program is distributed in the hope that it will be useful, but
> + * WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
> + * General Public License for more details.
> + *
> + * You should have received a copy of the GNU General Public License al=
ong
> + * with this program; if not, write to the Free Software Foundation, In=
c.,
> + * 675 Mass Ave, Cambridge, MA 02139, USA.
> + */
> +
> +
> +#include <linux/module.h>
> +#include <linux/kernel.h>
> +#include <linux/errno.h>
> +#include <linux/slab.h>
> +#include <linux/tdm.h>
> +#include <linux/init.h>
> +#include <linux/idr.h>
> +#include <linux/mutex.h>
> +#include <linux/completion.h>
> +#include <linux/hardirq.h>
> +#include <linux/irqflags.h>
> +#include <linux/list.h>
> +#include <linux/uaccess.h>
> +#include <linux/io.h>
Are you sure you need all of these header files?
> +
> +
> +static DEFINE_MUTEX(tdm_core_lock);
> +static DEFINE_IDR(tdm_adapter_idr);
> +/* List of TDM adapters registered with TDM framework */
> +LIST_HEAD(adapter_list);
> +
> +/* List of TDM clients registered with TDM framework */
> +LIST_HEAD(driver_list);
> +
> +/* In case the previous data is not fetched by the client driver, the
> + * de-interleaving function will discard the old data and rewrite the
> + * new data */
Proper multi-line comment format is like this:
/*
* In case the previous data is not fetched by the client driver, the
* de-interleaving function will discard the old data and rewrite the
* new data.
*/
> +static int use_latest_tdm_data =3D 1;
> +
> +/* Data structures required for sysfs */
> +static struct tdm_sysfs attr =3D {
> + .attr.name =3D "use_latest_data",
> + .attr.mode =3D 0664,
> + .cmd_type =3D TDM_LATEST_DATA,
> +};
> +
> +static struct attribute *tdm_attr[] =3D {
> + &attr.attr,
> + NULL
> +};
> +
> +const struct sysfs_ops tdm_ops =3D {
> + .show =3D tdm_show_sysfs,
> + .store =3D tdm_store_sysfs,
> +};
> +
> +static struct kobj_type tdm_type =3D {
> + .sysfs_ops =3D &tdm_ops,
> + .default_attrs =3D tdm_attr,
> +};
Why are some of these 'const' and some aren't? They should all be 'const'
> +
> +/* tries to match client driver with the adapter */
> +static int tdm_device_match(struct tdm_driver *driver, struct tdm_adapte=
r *adap)
> +{
> + /* match on an id table if there is one */
> + if (driver->id_table && driver->id_table->name[0]) {
> + if (!(strcmp(driver->id_table->name, adap->name)))
> + return (int)driver->id_table;
> + }
> + return TDM_E_OK;
Get rid of TDM_E_OK. It's the only error code that you've defined,
and it's set to 0. That doesn't mean anything.
> +}
> +
> +static int tdm_attach_driver_adap(struct tdm_driver *driver,
> + struct tdm_adapter *adap)
> +{
> + int ret =3D TDM_E_OK;
> + /* if driver is already attached to any other adapter, return*/
> + if (driver->adapter && (driver->adapter !=3D adap))
> + return ret;
> +
> + driver->adapter =3D adap;
> +
> + if (driver->attach_adapter) {
> + ret =3D driver->attach_adapter(adap);
> + if (ret < 0) {
> + pr_err("attach_adapter failed for driver [%s] err=
:%d\n"
> + , driver->name, ret);
> + return ret;
> + }
> + }
> + adap->drv_count++;
> +
> + if (!adap->tasklet_conf) {
> + tdm_sysfs_init();
> + tasklet_init(&adap->tdm_data_tasklet, tdm_data_tasklet_fn=
,
> + (unsigned long)adap);
> + adap->tasklet_conf =3D 1;
> + }
> +
> + return ret;
If 'ret' can only be 0, then just return 0.
return 0;
> +/* tdm_adap_send - issue a TDM write
> + * @adap: Handle to TDM device
> + * @buf: Data that will be written to the TDM device
> + * @count: How many bytes to write
> + *
> + * Returns negative errno, or else the number of bytes written.
"Returns negative error number, or else the number of bytes written."
You're typing this on a full keyboard, not a smart phone. Please
don't use abbreviations unnecessarily.
> + */
> +int tdm_adap_send(struct tdm_adapter *adap, void **buf, int count)
> +{
> + int res;
> +
> + if (adap->algo->tdm_write)
> + res =3D adap->algo->tdm_write(adap, buf, count);
Why does tdm_write() return a u32? And shouldn't 'res' also be a u32,
to make tdm_write()?
> +/* Port Level APIs of TDM Framework */
> +int tdm_port_open(struct tdm_driver *driver, struct tdm_port **h_port)
> +{
> + struct tdm_port *port;
> + struct tdm_adapter *adap;
> + unsigned long flags;
> + int res =3D TDM_E_OK;
> +
> + adap =3D tdm_get_adapter(driver->adapter->id);
> + if (!adap)
> + return -ENODEV;
> +
> + /* This creates an anonymous tdm_port, which may later be
> + * pointed to some slot.
> + *
> + */
> + port =3D kzalloc(sizeof(*port), GFP_KERNEL);
> + if (!port) {
> + res =3D -ENOMEM;
> + goto out;
> + }
Just return here. You don't need to "goto out". And I think you
forgot to call tdm_put_adapter(), although it might be easier if you
call kzalloc() first, and then tdm_get_adapter().
> +
> + port->rx_max_frames =3D NUM_SAMPLES_PER_FRAME;
> + port->port_cfg.port_mode =3D TDM_PORT_CHANNELIZED;
> +
> + snprintf(driver->name, TDM_NAME_SIZE, "tdm-dev");
> + port->driver =3D driver;
> + port->adapter =3D adap;
> +
> + spin_lock_irqsave(&adap->portlist_lock, flags);
> + list_add_tail(&port->list, &adap->myports);
> + spin_unlock_irqrestore(&adap->portlist_lock, flags);
Are you sure you need to disable interrupts? That seems excessive.
> +int tdm_channel_read(struct tdm_port *h_port, struct tdm_channel *h_chan=
nel,
> + void *p_data, u16 *size)
> +{
> + struct tdm_channel *channel;
> + struct tdm_bd *rx_bd;
> + unsigned long flags;
> + int i, res =3D TDM_E_OK;
> + unsigned short *buf, *buf1;
> + channel =3D h_channel;
> +
> + if (!channel->p_ch_data || !channel->in_use)
> + return -EIO;
> +
> + spin_lock_irqsave(&channel->p_ch_data->rx_channel_lock, flags);
> + rx_bd =3D channel->p_ch_data->rx_out_data;
> +
> + if (rx_bd->flag) {
> + *size =3D rx_bd->length;
> + buf =3D (u16 *) p_data;
> + buf1 =3D (u16 *)rx_bd->p_data;
> + for (i =3D 0; i < NUM_SAMPLES_PER_FRAME; i++)
> + buf[i] =3D buf1[i];
Use memcpy() instead.
> +int tdm_channel_write(struct tdm_port *h_port, struct tdm_channel *h_cha=
nnel,
> + void *p_data, u16 size)
> +{
> + struct tdm_port *port;
> + struct tdm_channel *channel;
> + struct tdm_bd *tx_bd;
> + unsigned long flags;
> + int err =3D TDM_E_OK;
> + port =3D h_port;
> + channel =3D h_channel;
> +#ifdef DEBUG
> + bool data_flag =3D 0;
> +#endif
> +
> + if (p_data =3D=3D NULL) { /* invalid data*/
> + pr_err("Invalid Data");
> + return -EFAULT;
> + }
EFAULT is for invalid memory access. I think you mean EINVAL here.
> +
> + if (!channel->p_ch_data || !channel->in_use)
> + return -EIO;
> +
> + spin_lock_irqsave(&channel->p_ch_data->tx_channel_lock, flags);
> + tx_bd =3D channel->p_ch_data->tx_in_data;
> +
> + if (!tx_bd->flag) {
> + tx_bd->length =3D size;
> + memcpy(tx_bd->p_data, p_data,
> + size * port->adapter->adapt_cfg.slot_widt=
h);
> + tx_bd->flag =3D 1;
> + tx_bd->offset =3D 0;
> + channel->p_ch_data->tx_in_data =3D (tx_bd->wrap) ?
> + channel->p_ch_data->tx_data_fifo : tx_bd+1;
> + port->port_stat.tx_pkt_count++;
> +#ifdef DEBUG
> + data_flag =3D 1;
> +#endif
> + } else {
> + spin_unlock_irqrestore(&channel->p_ch_data->tx_channel_lo=
ck,
> + flags);
> + port->port_stat.tx_pkt_drop_count++;
> + pr_err("E_NO_MEMORY -Failed Transmit");
Please review ALL of your error messages, and make sure that have a
proper prefix ("tdm: ") and all look the same. Don't use __func__ in
any of them, and make sure the error messages are clear, English text.
> + return -ENOMEM;
I'm not sure ENOMEM is appropriate here.
> + }
> + spin_unlock_irqrestore(&channel->p_ch_data->tx_channel_lock, flag=
s);
> +
> +#ifdef DEBUG
> + if (data_flag) {
> + int k;
> + pr_info("\nTX port:%d - Write - Port TX-%d\n",
> + port->port_id, size);
> + for (k =3D 0; k < size; k++)
> + pr_info("%x", p_data[k]);
> + pr_info("\n");
> + }
> +#endif
> + return err;
> +}
> +EXPORT_SYMBOL(tdm_channel_write);
> +
> +/* Driver Function for select and poll. Based on Channel, it sleeps on
> + * waitqueue */
> +int tdm_ch_poll(struct tdm_channel *h_channel, unsigned int wait_time)
> +{
> + struct tdm_channel *channel;
> + unsigned long timeout =3D msecs_to_jiffies(wait_time);
> + channel =3D h_channel;
> +
> + if (!channel->p_ch_data || !channel->in_use)
> + return -EIO;
> +
> + if (channel->p_ch_data->rx_out_data->flag) {
> + pr_debug("Data Available");
> + return TDM_E_OK;
> + }
> + if (timeout) {
> + wait_event_interruptible_timeout(channel->ch_wait_queue,
It'd be more efficient if you did this:
if (wait_time) {
unsigned long timeout =3D msecs_to_jiffies(wait_time);
wait_event_interruptible_timeout(channel->ch_wait_queue,
> + channel->p_ch_data->rx_out_data->flag,
> + timeout);
> +
> + if (channel->p_ch_data->rx_out_data->flag) {
> + pr_debug("Data Available");
> + return TDM_E_OK;
> + }
> + }
> + return -EAGAIN;
> +}
> +EXPORT_SYMBOL(tdm_ch_poll);
> +
> +unsigned int tdm_port_get_stats(struct tdm_port *h_port,
> + struct tdm_port_stats *portStat)
Do not use CamelCase in variable names.
> diff --git a/include/linux/tdm.h b/include/linux/tdm.h
> new file mode 100644
> index 0000000..a2f9628
> --- /dev/null
> +++ b/include/linux/tdm.h
> @@ -0,0 +1,338 @@
> +/* include/linux/tdm.h
> + *
> + * Copyright (C) 2012 Freescale Semiconductor, Inc, All rights reserved.
> + *
> + * tdm.h - definitions for the tdm-device framework interface
> + *
> + * Author:Hemant Agrawal <hemant@freescale.com>
> + * Rajesh Gumasta <rajesh.gumasta@freescale.com>
> + *
> + * 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 y=
our
> + * option) any later version.
> + *
> + * This program is distributed in the hope that it will be useful, but
> + * WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
> + * General Public License for more details.
> + *
> + * You should have received a copy of the GNU General Public License al=
ong
> + * with this program; if not, write to the Free Software Foundation, In=
c.,
> + * 675 Mass Ave, Cambridge, MA 02139, USA.
> + */
> +
> +
> +#ifndef _LINUX_TDM_H
> +#define _LINUX_TDM_H
> +
> +#include <linux/types.h>
> +#include <linux/module.h>
> +#include <linux/mod_devicetable.h>
> +#include <linux/device.h> /* for struct device */
> +#include <linux/sched.h> /* for completion */
> +#include <linux/mutex.h>
> +#include <linux/interrupt.h>
> +#include <linux/sysfs.h>
> +
> +#define TDM_LATEST_DATA 1
> +#define CHANNEL_8BIT_LIN 0 /* 8 bit linear */
> +#define CHANNEL_8BIT_ULAW 1 /* 8 bit Mu-law */
> +#define CHANNEL_8BIT_ALAW 2 /* 8 bit A-law */
> +#define CHANNEL_16BIT_LIN 3 /* 16 bit Linear */
> +
> +/*
> + * Default adapter configuration. All the TDM adapters registered with
> + * framework will be configured with following default configuration.
> + */
> +#define NUM_CHANNELS 16
> +
> +/* Default configuration for typical voice data sample. These parameters
> + * will generally not be required to be changed for voice type applicati=
ons.
> + */
> +#define NUM_SAMPLES_PER_MS 8 /* 8 samples per milli sec per
> + channel. Req for voice data */
> +#define NUM_MS 10
> +#define NUM_SAMPLES_PER_FRAME (NUM_MS * NUM_SAMPLES_PER_MS) /* Number o=
f
> + samples for 1 client buff=
er */
> +#define NUM_OF_TDM_BUF 3
> +
> +/* General options */
> +
> +struct tdm_adapt_algorithm;
> +struct tdm_adapter;
> +struct tdm_port;
> +struct tdm_driver;
I don't think you need "struct tdm_driver;"
> +/* tdm_adapter_mode is to define in mode of the device */
> +enum tdm_adapter_mode {
> + TDM_ADAPTER_MODE_NONE =3D 0x00,
> + TDM_ADAPTER_MODE_T1 =3D 0x01,
> + TDM_ADAPTER_MODE_E1 =3D 0x02,
> + TDM_ADAPTER_MODE_T1_RAW =3D 0x10,
> + TDM_ADAPTER_MODE_E1_RAW =3D 0x20,
Where did these numbers come from?
--=20
Timur Tabi
Linux kernel developer at Freescale=
^ permalink raw reply
* Re: mpc8xxx PCIe hotplug needs fixing, some clues ..
From: Joakim Tjernlund @ 2012-07-23 16:45 UTC (permalink / raw)
Cc: scottwood, linuxppc-dev
In-Reply-To: <OF85435159.0952793A-ONC1257A42.0058090C-C1257A42.0058F2A6@LocalDomain>
Joakim Tjernlund/Transmode wrote on 2012/07/21 18:11:32:
>
> Kumar Gala <galak@kernel.crashing.org> wrote on 2012/07/20 20:53:10:
> >
> >
> > On Jul 20, 2012, at 2:17 AM, Joakim Tjernlund wrote:
> >
> > >
> > > Hi Guys
> > >
> > > I see that you have been hacking Freescale PCI before so I send this to you(and the list)
> > >
> > > We are using PCIe(as RC) on P2010(basically a mpc85xx) and have PCI device that
> > > started from user space (needs advance clock conf) so when linux boots there is
> > > no device at all.
> > > Trying to "hotplug" the device after it is enabled fails, no amount of recan/remove using
> > > either fake or real hotplug makes a difference.
> > >
> > > I found the cause eventually but I can't fix it properly as I known almost nothing about PCI.
> > > Cause:
> > > indirect_pci.c:indirect_read_config() tests for if (hose->indirect_type & PPC_INDIRECT_TYPE_NO_PCIE_LINK)
> > > and returns PCIBIOS_DEVICE_NOT_FOUND
> > >
> > > PPC_INDIRECT_TYPE_NO_PCIE_LINK get set by fsl_pci.c (look for fsl_pcie_check_link) but is never cleared.
> > > Clearing it as appropriate makes a small difference. If you
> > > remove the RC and do a few of rescan's then the device appears.
> > >
> > > Hacking some more, like so:
> > >
> > > int fsl_pcie_check_link(struct pci_controller *hose)
> > > {
> > > u32 val;
> > >
> > > early_read_config_dword(hose, 0, 0, PCIE_LTSSM, &val);
> > > hose->indirect_type |= PPC_INDIRECT_TYPE_NO_PCIE_LINK;
> > > if (val < PCIE_LTSSM_L0)
> > > return 1;
> > > hose->indirect_type &= ~PPC_INDIRECT_TYPE_NO_PCIE_LINK;
> > > return 0;
> > > }
> > > and then using it carefully(it is easy to make linux hang) in indirect_read_config():
> > > indirect_read_config(struct pci_bus *bus, unsigned int devfn, int offset,
> > > int len, u32 *val)
> > > {
> > > struct pci_controller *hose = pci_bus_to_host(bus);
> > > volatile void __iomem *cfg_data;
> > > u8 cfg_type = 0;
> > > u32 bus_no, reg;
> > >
> > > if (hose->indirect_type & PPC_INDIRECT_TYPE_NO_PCIE_LINK) {
> > > if (bus->number != hose->first_busno ||
> > > devfn != 0) {
> > > fsl_pcie_check_link(hose);
> > > return PCIBIOS_DEVICE_NOT_FOUND;
> > > }
> > > }
> > >
> > > Now it works, just one rescan and the device appears!
> > > This is a hack, I don't known what other trouble it can cause, I hope you can
> > > sort this out.
> >
> > How are you forcing the re-scan? We can see if we can add a re-check of the link state in that flow somewhere.
>
> echo 1 > /sys/bus/pci/rescan
>
> Why is that check important? Seems like some very ppc specific workaround for something.
>
> >
> > Can you do a dump_stack() or something to get a call chain?
> here?
> indirect_read_config(struct pci_bus *bus, unsigned int devfn, int offset,
> int len, u32 *val)
> {
> struct pci_controller *hose = pci_bus_to_host(bus);
> volatile void __iomem *cfg_data;
> u8 cfg_type = 0;
> u32 bus_no, reg;
> static int first_dump;
>
> if (!first_dump) {
> dump_stack();
> first_dump = 1;
> }
> ...
>
> I am not at work and and my board needs a reset button press to recover :(
> Furthermore, my vacation starts next week, not sure I can get it fixed soon enough
So I managed to get someone to connect the BDI. Here is a dump according to the above:
Memory CAM mapping: 256/256 Mb, residual: 0Mb
Linux version 3.4.0+ (jocke@gentoo-jocke) (gcc version 4.5.3 (Gentoo 4.5.3-r2 p1.1, pie-0.4.7) ) #2088 PREEMPT Sat Jul 21 18:05:10 CEST 2012
bootconsole [udbg0] enabled
setup_arch: bootmem
p1010_rdb_setup_arch()
Call Trace:
[c0399e50] [c0006f28] show_stack+0x54/0x158 (unreliable)
[c0399e90] [c0019390] indirect_read_config+0x23c/0x250
[c0399ec0] [c017e630] pci_bus_read_config_byte+0x4c/0x94
[c0399ef0] [c000f4d4] early_read_config_byte+0x30/0x44
[c0399f10] [c0364524] fsl_add_bridge+0x118/0xa5c
[c0399f90] [c03655b4] p1010_rdb_setup_arch+0x8c/0xcc
[c0399fb0] [c0361850] setup_arch+0x1a8/0x1e8
[c0399fc0] [c035d558] start_kernel+0x80/0x2f0
[c0399ff0] [c00003ac] skpinv+0x298/0x2d4
Found FSL PCI host bridge at 0x00000000ff70a000. Firmware bus number: 0->1
PCI host bridge /pcie@ff70a000 ranges:
MEM 0x0000000080000000..0x000000009fffffff -> 0x0000000080000000
IO 0x00000000ffc00000..0x00000000ffc0ffff -> 0x0000000000000000
/pcie@ff70a000: PCICSRBAR @ 0xfff00000
So early_read_config_byte uses indirect_read_config so obviously you cannot
use early_read_config_xxx from within indirect_read_config as this gets you
into a nice recursion loop :)
Anyhow, I will be travelling for the better part of this week and will
have very limited Internet access.
Jocke
^ permalink raw reply
* Re: Memory management problems on a custom PPC 8270 board
From: Scott Wood @ 2012-07-23 16:48 UTC (permalink / raw)
To: Geoffrey Bugniot; +Cc: linuxppc-dev
In-Reply-To: <loom.20120723T170223-328@post.gmane.org>
On 07/23/2012 10:34 AM, Geoffrey Bugniot wrote:
> Hi,
>
> I've ported on a custom board U-Boot and Linux 2.6.39.4. It seems to work
> well until the kernel is begin to manipulate "data/file" with a size larger
> than about 5 Mo. I suppose that's a VM management problem, but I'm not
> sure.
>
> In fact, when I use "cp file1 file2" with file1 >= 5/6 Mo, the kernel panics.
> Same behaviour with a command like "tar cvf file.tar.gz file1 file2...".
>
> I got something like that :
>
> [ 148.891584] Kernel panic - not syncing: Attempted to kill init!
Was there anything before this?
> [ 148.897503] Call Trace:
> [ 148.899934] [c7829d10] [c0008fbc] show_stack+0x4c/0x138 (unreliable)
> [ 148.906470] [c7829d50] [c03be7d8] panic+0xa4/0x1e8
> [ 148.911401] [c7829db0] [c0025580] do_exit+0x94/0x630
> [ 148.916501] [c7829e00] [c0025bdc] do_group_exit+0x80/0xac
> [ 148.922071] [c7829e10] [c00340d8] get_signal_to_deliver+0x474/0x490
> [ 148.928515] [c7829e70] [c0009aa4] do_signal_pending.constprop.9+0x40/0x22c
> [ 148.935586] [c7829f30] [c0009d88] do_signal+0x24/0x50
> [ 148.940793] [c7829f40] [c000f76c] do_user_signal+0x74/0xc4
> [ 148.946419] --- Exception: 700 at 0xfec5394
> [ 148.946433] LR = 0x1000410c
> [ 148.954009] Rebooting in 3 seconds..
This looks like your init process crashed. You could try enabling
show_unhandled_signals in arch/powerpc/signal.c.
What are you running as your init process? Do you have a normal
init/login scheme, or are you running a shell (esp. busybox, which would
have cp built in) directly as init?
> When I use netsniff-ng, with default parameters, kernel hangs too. But If I
> specify a small ring buffer size with option "netsniff-ng -S 3MB" all is
> running fine. Here, is the dump when netsniff-ng causes a crash:
>
> root@pLinesE_VMEb:~# netsniff-ng
> netsniff-ng 0.5.5.0 -- pid (245)
> [ 36.065574] device eth0 entered promiscuous mode
> nice (0), scheduler (0 prio 0)
> 1 of 1 CPUs online, affinity bitstring (1)
> No device specified, using `eth0`.
> No filter applied. Switching to `all traffic`.
>
> [ 36.159714] BUG: Bad page state in process netsniff-ng pfn:05401
> [ 36.165759] page:c0401020 count:0 mapcount:1 mapping: (null) index:0x0
> [ 36.172548] page flags: 0x0()
Could you have bad memory timings (or bad memory)? Usually when I see
things like this, it's because memory is getting corrupted.
-Scott
^ permalink raw reply
* [PATCH] powerpc/85xx: p1022ds: fix DIU/LBC switching with NAND enabled
From: Timur Tabi @ 2012-07-23 20:43 UTC (permalink / raw)
To: Kumar Gala, linuxppc-dev
In order for indirect mode on the PIXIS to work properly, both chip selects
need to be set to GPCM mode, otherwise writes to the chip select base
addresses will not actually post to the local bus -- they'll go to the
NAND controller instead. Therefore, we need to set BR0 and BR1 to GPCM
mode before switching to indirect mode.
Signed-off-by: Timur Tabi <timur@freescale.com>
---
arch/powerpc/platforms/85xx/p1022_ds.c | 64 +++++++++++++++++++++++++++++++-
1 files changed, 62 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/platforms/85xx/p1022_ds.c b/arch/powerpc/platforms/85xx/p1022_ds.c
index 5ca2823a..3c732ac 100644
--- a/arch/powerpc/platforms/85xx/p1022_ds.c
+++ b/arch/powerpc/platforms/85xx/p1022_ds.c
@@ -208,6 +208,7 @@ static void p1022ds_set_monitor_port(enum fsl_diu_monitor_port port)
u8 __iomem *lbc_lcs0_ba = NULL;
u8 __iomem *lbc_lcs1_ba = NULL;
phys_addr_t cs0_addr, cs1_addr;
+ u32 br0, or0, br1, or1;
const __be32 *iprop;
unsigned int num_laws;
u8 b;
@@ -256,11 +257,70 @@ static void p1022ds_set_monitor_port(enum fsl_diu_monitor_port port)
}
num_laws = be32_to_cpup(iprop);
- cs0_addr = lbc_br_to_phys(ecm, num_laws, in_be32(&lbc->bank[0].br));
- cs1_addr = lbc_br_to_phys(ecm, num_laws, in_be32(&lbc->bank[1].br));
+ /*
+ * Indirect mode requires both BR0 and BR1 to be set to "GPCM",
+ * otherwise writes to these addresses won't actually appear on the
+ * local bus, and so the PIXIS won't see them.
+ *
+ * In FCM mode, writes go to the NAND controller, which does not pass
+ * them to the localbus directly. So we force BR0 and BR1 into GPCM
+ * mode, since we don't care about what's behind the localbus any
+ * more.
+ */
+ br0 = in_be32(&lbc->bank[0].br);
+ br1 = in_be32(&lbc->bank[1].br);
+ or0 = in_be32(&lbc->bank[0].or);
+ or1 = in_be32(&lbc->bank[1].or);
+
+ /* Make sure CS0 and CS1 are programmed */
+ if (!(br0 & BR_V) || !(br1 & BR_V)) {
+ pr_err("p1022ds: CS0 and/or CS1 is not programmed\n");
+ goto exit;
+ }
+
+ /*
+ * Use the existing BRx/ORx values if it's already GPCM. Otherwise,
+ * force the values to simple 32KB GPCM windows with the most
+ * conservative timing.
+ */
+ if ((br0 & BR_MSEL) != BR_MS_GPCM) {
+ br0 = (br0 & BR_BA) | BR_V;
+ or0 = 0xFFFF8000 | 0xFF7;
+ out_be32(&lbc->bank[0].br, br0);
+ out_be32(&lbc->bank[0].or, or0);
+ }
+ if ((br1 & BR_MSEL) != BR_MS_GPCM) {
+ br1 = (br1 & BR_BA) | BR_V;
+ or1 = 0xFFFF8000 | 0xFF7;
+ out_be32(&lbc->bank[1].br, br1);
+ out_be32(&lbc->bank[1].or, or1);
+ }
+
+ cs0_addr = lbc_br_to_phys(ecm, num_laws, br0);
+ if (!cs0_addr) {
+ pr_err("p1022ds: could not determine physical address for CS0"
+ " (BR0=%08x)\n", br0);
+ goto exit;
+ }
+ cs1_addr = lbc_br_to_phys(ecm, num_laws, br1);
+ if (!cs0_addr) {
+ pr_err("p1022ds: could not determine physical address for CS1"
+ " (BR1=%08x)\n", br1);
+ goto exit;
+ }
lbc_lcs0_ba = ioremap(cs0_addr, 1);
+ if (!lbc_lcs0_ba) {
+ pr_err("p1022ds: could not ioremap CS0 address %llx\n",
+ (unsigned long long)cs0_addr);
+ goto exit;
+ }
lbc_lcs1_ba = ioremap(cs1_addr, 1);
+ if (!lbc_lcs1_ba) {
+ pr_err("p1022ds: could not ioremap CS1 address %llx\n",
+ (unsigned long long)cs1_addr);
+ goto exit;
+ }
/* Make sure we're in indirect mode first. */
if ((in_be32(&guts->pmuxcr) & PMUXCR_ELBCDIU_MASK) !=
--
1.7.3.4
^ permalink raw reply related
* Re: [PATCH] powerpc/mm: add ZONE_NORMAL zone for 64 bit kernel
From: Benjamin Herrenschmidt @ 2012-07-23 22:20 UTC (permalink / raw)
To: Scott Wood; +Cc: Mingkai Hu, linuxppc-dev, Shaohui Xie, Chen Yuanquan
In-Reply-To: <500D7921.6060804@freescale.com>
On Mon, 2012-07-23 at 11:17 -0500, Scott Wood wrote:
> > This is wrong.
>
> How so?
>
> > Don't you have an iommu do deal with those devices anyway ?
>
> Yes, but we don't yet have DMA API support for it, it would lower
> performance because we'd have to use a lot of subwindows which are
> poorly cached (and even then we wouldn't be able to map more than 256
> pages at once on a given device), and the IOMMU may not be available at
> all if we're being virtualized.
Ugh ? You mean some designers need to be fired urgently and wasted
everybody's time implementing an unusable iommu ? Nice one ...
> > What about swiotlb ?
>
> That doesn't help with alloc_coherent().
Somewhat... you can use the pool, but it sucks.
> > If you *really* need to honor 32 (or 31 even) bit DMAs,
>
> 31-bit is to accommodate PCI, which has PEXCSRBAR that must live under 4
> GiB and can't be disabled.
>
> > what you -may- want to do is create a ZONE_DMA32 like other architectures, do not
> > hijack the historical ZONE_DMA.
>
> Could you point me to somewhere that clearly defines what ZONE_DMA is to
> be used for, such that this counts as hijacking (but using ZONE_DMA32 to
> mean 31-bit wouldn't)?
Habit and history. ZONE_DMA used to be about ISA DMA, doesn't apply to
us, and in general ZONE_NORMAL alias to it iirc. It's old stuff I
haven't looked for a long time.
However, my understanding is that what you are trying to solve is
exactly what ZONE_DMA32 was created for.
> The only arches I see using ZONE_DMA32 (x86 and
> mips) also have a separate, more restrictive ZONE_DMA.
And ? Who cares ? Drivers who know about a 32-bit limitations use
GFP_DMA32, that's what is expected, don't mess around with ZONE_DMA.
> PowerPC doesn't.
> It uses ZONE_DMA to point to all of memory (except highmem on 32-bit)
> -- how is that not hijacking, if this is? We can't have ZONE_DMA be
> less restrictive than ZONE_DMA32, because the fallback rules are
> hardcoded the other way around in generic code.
>
> The exact threshold for ZONE_DMA could be made platform-configurable.
>
> > But even then, I'm dubious this is really needed.
>
> We'd like our drivers to stop crashing with more than 4GiB of RAM on 64-bit.
Fix your HW :-)
Cheers,
Ben.
^ permalink raw reply
* Re: next/mmotm unbootable on G5: irqdomain
From: Benjamin Herrenschmidt @ 2012-07-23 22:26 UTC (permalink / raw)
To: Grant Likely
Cc: Stephen Rothwell, Hugh Dickins, linux-kernel, Milton Miller,
Paul Mundt, Rob Herring, Andrew Morton, linuxppc-dev,
Thomas Gleixner
In-Reply-To: <CACxGe6uFvtro7iR8FewgChLr_6PnZA-EaRMKQjrFEaEHg7SKRQ@mail.gmail.com>
On Mon, 2012-07-23 at 01:59 -0600, Grant Likely wrote:
> My tree must be rebased to eliminate bisect breakage. The existing
> commits in my tree have the breakage, and fiddling with the merge
> order doesn't affect that. I don't want to rebase though. The safest
> approach (smallest window of breakage) is to apply that fix onto my
> irqdomain tree.
With your other breakage on pseries I'm thinking rebasing might be the
only option...
Cheers,
Ben.
^ permalink raw reply
* Re: next/mmotm unbootable on G5: irqdomain
From: Grant Likely @ 2012-07-23 22:31 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: Stephen Rothwell, Hugh Dickins, linux-kernel, Milton Miller,
Paul Mundt, Rob Herring, Andrew Morton, linuxppc-dev,
Thomas Gleixner
In-Reply-To: <1343082371.2957.39.camel@pasglop>
On Mon, Jul 23, 2012 at 4:26 PM, Benjamin Herrenschmidt
<benh@kernel.crashing.org> wrote:
> On Mon, 2012-07-23 at 01:59 -0600, Grant Likely wrote:
>> My tree must be rebased to eliminate bisect breakage. The existing
>> commits in my tree have the breakage, and fiddling with the merge
>> order doesn't affect that. I don't want to rebase though. The safest
>> approach (smallest window of breakage) is to apply that fix onto my
>> irqdomain tree.
>
> With your other breakage on pseries I'm thinking rebasing might be the
> only option...
Fair enough. I'm not planning to ask Linus to pull for a few days yet
anyway. I've been pretty useless as a kernel maintainer for the last 3
months so I want to give a bit more time in linux-next to catch
fallout before it gets merged.
As-is I'm backing off from the linear/legacy/tree merge patch as just
too risky. I've already pulled that stuff out of linux-next.
g.
^ permalink raw reply
* Re: next/mmotm unbootable on G5: irqdomain
From: Grant Likely @ 2012-07-23 22:32 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: Stephen Rothwell, Hugh Dickins, linux-kernel, Milton Miller,
Paul Mundt, Rob Herring, Andrew Morton, linuxppc-dev,
Thomas Gleixner
In-Reply-To: <CACxGe6uo8jx3GQFQpQ5RTHF5JyN2hEgvcvdmSYfGyTQnzK9fOA@mail.gmail.com>
On Mon, Jul 23, 2012 at 4:31 PM, Grant Likely <grant.likely@secretlab.ca> wrote:
> On Mon, Jul 23, 2012 at 4:26 PM, Benjamin Herrenschmidt
> <benh@kernel.crashing.org> wrote:
>> On Mon, 2012-07-23 at 01:59 -0600, Grant Likely wrote:
>>> My tree must be rebased to eliminate bisect breakage. The existing
>>> commits in my tree have the breakage, and fiddling with the merge
>>> order doesn't affect that. I don't want to rebase though. The safest
>>> approach (smallest window of breakage) is to apply that fix onto my
>>> irqdomain tree.
>>
>> With your other breakage on pseries I'm thinking rebasing might be the
>> only option...
>
> Fair enough. I'm not planning to ask Linus to pull for a few days yet
> anyway. I've been pretty useless as a kernel maintainer for the last 3
> months so I want to give a bit more time in linux-next to catch
> fallout before it gets merged.
>
> As-is I'm backing off from the linear/legacy/tree merge patch as just
> too risky. I've already pulled that stuff out of linux-next.
Can I pull you pseries fix into my tree (my preference), or do I need
to rebase on top of yours?
g.
^ permalink raw reply
* Re: [PATCH] powerpc/mm: add ZONE_NORMAL zone for 64 bit kernel
From: Tabi Timur-B04825 @ 2012-07-23 23:08 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: Wood Scott-B07421, Hu Mingkai-B21284,
linuxppc-dev@lists.ozlabs.org, Xie Shaohui-B21989,
Chen Yuanquan-B41889
In-Reply-To: <1343082030.2957.38.camel@pasglop>
On Mon, Jul 23, 2012 at 5:20 PM, Benjamin Herrenschmidt
<benh@kernel.crashing.org> wrote:
> And ? Who cares ? Drivers who know about a 32-bit limitations use
> GFP_DMA32, that's what is expected, don't mess around with ZONE_DMA.
I thought drivers are supposed to set a dma_mask, and
dma_alloc_coherent() is supposed to use that to figure out how to
honor that mask.
--=20
Timur Tabi
Linux kernel developer at Freescale=
^ permalink raw reply
* Re: [PATCH] powerpc/mm: add ZONE_NORMAL zone for 64 bit kernel
From: Benjamin Herrenschmidt @ 2012-07-23 23:12 UTC (permalink / raw)
To: Tabi Timur-B04825
Cc: Wood Scott-B07421, Hu Mingkai-B21284,
linuxppc-dev@lists.ozlabs.org, Xie Shaohui-B21989,
Chen Yuanquan-B41889
In-Reply-To: <CAOZdJXXd6GuLAed_Z4zNMjDN+DBBXHdd0yVRHof+BJ_eiUMbqQ@mail.gmail.com>
On Mon, 2012-07-23 at 23:08 +0000, Tabi Timur-B04825 wrote:
>
> > And ? Who cares ? Drivers who know about a 32-bit limitations use
> > GFP_DMA32, that's what is expected, don't mess around with ZONE_DMA.
>
> I thought drivers are supposed to set a dma_mask, and
> dma_alloc_coherent() is supposed to use that to figure out how to
> honor that mask.
Sure, that's the right way to go, I meant bits of pieces of the
infrastructure in between. Why diverge from other archs gratuituously
here ?
Cheers,
Ben.
^ permalink raw reply
* [PATCH] powerpc/85xx: introduce support for the Freescale / iVeia P1022RDK
From: Timur Tabi @ 2012-07-23 23:12 UTC (permalink / raw)
To: Kumar Gala, linuxppc-dev
The Freescale / iVeia P1022RDK reference board is a small-factor board
with a Freescale P1022 SOC. It includes:
1) 512 MB 64-bit DDR3-800 (max) memory
2) 8MB SPI serial flash memory for boot loader
3) Bootable 4-bit SD/MMC port
4) Two 10/100/1000 Ethernet connectors
5) One SATA port
6) Two USB ports
7) One PCIe x4 slot
8) DVI video connector
9) Audio input and output jacks, powered by a Wolfson WM8960 codec.
Unlike the P1022DS, the P1022RDK does not have any localbus devices,
presumably because of the localbus / DIU multiplexing restriction of
the P1022 SOC.
Signed-off-by: Timur Tabi <timur@freescale.com>
---
arch/powerpc/boot/dts/p1022rdk.dts | 188 +++++++++++++++++++++++++++
arch/powerpc/configs/mpc85xx_defconfig | 1 +
arch/powerpc/configs/mpc85xx_smp_defconfig | 1 +
arch/powerpc/platforms/85xx/Kconfig | 7 +
arch/powerpc/platforms/85xx/Makefile | 1 +
arch/powerpc/platforms/85xx/p1022_rdk.c | 195 ++++++++++++++++++++++++++++
6 files changed, 393 insertions(+), 0 deletions(-)
create mode 100644 arch/powerpc/boot/dts/p1022rdk.dts
create mode 100644 arch/powerpc/platforms/85xx/p1022_rdk.c
diff --git a/arch/powerpc/boot/dts/p1022rdk.dts b/arch/powerpc/boot/dts/p1022rdk.dts
new file mode 100644
index 0000000..51d82de
--- /dev/null
+++ b/arch/powerpc/boot/dts/p1022rdk.dts
@@ -0,0 +1,188 @@
+/*
+ * P1022 RDK 32-bit Physical Address Map Device Tree Source
+ *
+ * Copyright 2012 Freescale Semiconductor Inc.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions are met:
+ * * Redistributions of source code must retain the above copyright
+ * notice, this list of conditions and the following disclaimer.
+ * * Redistributions in binary form must reproduce the above copyright
+ * notice, this list of conditions and the following disclaimer in the
+ * documentation and/or other materials provided with the distribution.
+ * * Neither the name of Freescale Semiconductor nor the
+ * names of its contributors may be used to endorse or promote products
+ * derived from this software without specific prior written permission.
+ *
+ *
+ * ALTERNATIVELY, this software may be distributed under the terms of the
+ * GNU General Public License ("GPL") as published by the Free Software
+ * Foundation, either version 2 of that License or (at your option) any
+ * later version.
+ *
+ * THIS SOFTWARE IS PROVIDED BY Freescale Semiconductor "AS IS" AND ANY
+ * EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED
+ * WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
+ * DISCLAIMED. IN NO EVENT SHALL Freescale Semiconductor BE LIABLE FOR ANY
+ * DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES
+ * (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;
+ * LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND
+ * ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
+ * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS
+ * SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+ */
+
+/include/ "fsl/p1022si-pre.dtsi"
+/ {
+ model = "fsl,P1022RDK";
+ compatible = "fsl,P1022RDK";
+
+ memory {
+ device_type = "memory";
+ };
+
+ board_lbc: lbc: localbus@ffe05000 {
+ /* The P1022 RDK does not have any localbus devices */
+ status = "disabled";
+ };
+
+ board_soc: soc: soc@ffe00000 {
+ ranges = <0x0 0x0 0xffe00000 0x100000>;
+
+ i2c@3100 {
+ wm8960:codec@1a {
+ compatible = "wlf,wm8960";
+ reg = <0x1a>;
+ /* MCLK source is a stand-alone oscillator */
+ clock-frequency = <12288000>;
+ };
+ rtc@68 {
+ compatible = "stm,m41t62";
+ reg = <0x68>;
+ };
+ adt7461@4c{
+ compatible = "adi,adt7461";
+ reg = <0x4c>;
+ };
+ zl6100@21{
+ compatible = "isil,zl6100";
+ reg = <0x21>;
+ };
+ zl6100@24{
+ compatible = "isil,zl6100";
+ reg = <0x24>;
+ };
+ zl6100@26{
+ compatible = "isil,zl6100";
+ reg = <0x26>;
+ };
+ zl6100@29{
+ compatible = "isil,zl6100";
+ reg = <0x29>;
+ };
+ };
+
+ spi@7000 {
+ flash@0 {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ compatible = "spansion,m25p80";
+ reg = <0>;
+ spi-max-frequency = <1000000>;
+ partition@0 {
+ label = "full-spi-flash";
+ reg = <0x00000000 0x00100000>;
+ };
+ };
+ };
+
+ ssi@15000 {
+ fsl,mode = "i2s-slave";
+ codec-handle = <&wm8960>;
+ };
+
+ usb@22000 {
+ phy_type = "ulpi";
+ };
+
+ usb@23000 {
+ phy_type = "ulpi";
+ };
+
+ mdio@24000 {
+ phy0: ethernet-phy@0 {
+ interrupts = <3 1 0 0>;
+ reg = <0x1>;
+ };
+ phy1: ethernet-phy@1 {
+ interrupts = <9 1 0 0>;
+ reg = <0x2>;
+ };
+ };
+
+ mdio@25000 {
+ tbi0: tbi-phy@11 {
+ reg = <0x11>;
+ device_type = "tbi-phy";
+ };
+ };
+
+ ethernet@b0000 {
+ phy-handle = <&phy0>;
+ phy-connection-type = "rgmii-id";
+ };
+
+ ethernet@b1000 {
+ phy-handle = <&phy1>;
+ tbi-handle = <&tbi0>;
+ phy-connection-type = "sgmii";
+ };
+ };
+
+ pci0: pcie@ffe09000 {
+ ranges = <0x2000000 0x0 0xe0000000 0 0xa0000000 0x0 0x20000000
+ 0x1000000 0x0 0x00000000 0 0xffc10000 0x0 0x10000>;
+ reg = <0x0 0xffe09000 0 0x1000>;
+ pcie@0 {
+ ranges = <0x2000000 0x0 0xe0000000
+ 0x2000000 0x0 0xe0000000
+ 0x0 0x20000000
+
+ 0x1000000 0x0 0x0
+ 0x1000000 0x0 0x0
+ 0x0 0x100000>;
+ };
+ };
+
+ pci1: pcie@ffe0a000 {
+ ranges = <0x2000000 0x0 0xe0000000 0 0xc0000000 0x0 0x20000000
+ 0x1000000 0x0 0x00000000 0 0xffc20000 0x0 0x10000>;
+ reg = <0 0xffe0a000 0 0x1000>;
+ pcie@0 {
+ ranges = <0x2000000 0x0 0xe0000000
+ 0x2000000 0x0 0xe0000000
+ 0x0 0x20000000
+
+ 0x1000000 0x0 0x0
+ 0x1000000 0x0 0x0
+ 0x0 0x100000>;
+ };
+ };
+
+ pci2: pcie@ffe0b000 {
+ ranges = <0x2000000 0x0 0xe0000000 0 0x80000000 0x0 0x20000000
+ 0x1000000 0x0 0x00000000 0 0xffc00000 0x0 0x10000>;
+ reg = <0 0xffe0b000 0 0x1000>;
+ pcie@0 {
+ ranges = <0x2000000 0x0 0xe0000000
+ 0x2000000 0x0 0xe0000000
+ 0x0 0x20000000
+
+ 0x1000000 0x0 0x0
+ 0x1000000 0x0 0x0
+ 0x0 0x100000>;
+ };
+ };
+};
+
+/include/ "fsl/p1022si-post.dtsi"
diff --git a/arch/powerpc/configs/mpc85xx_defconfig b/arch/powerpc/configs/mpc85xx_defconfig
index 03ee911c..ae9d852 100644
--- a/arch/powerpc/configs/mpc85xx_defconfig
+++ b/arch/powerpc/configs/mpc85xx_defconfig
@@ -26,6 +26,7 @@ CONFIG_MPC85xx_DS=y
CONFIG_MPC85xx_RDB=y
CONFIG_P1010_RDB=y
CONFIG_P1022_DS=y
+CONFIG_P1022_RDK=y
CONFIG_P1023_RDS=y
CONFIG_SOCRATES=y
CONFIG_KSI8560=y
diff --git a/arch/powerpc/configs/mpc85xx_smp_defconfig b/arch/powerpc/configs/mpc85xx_smp_defconfig
index fdfa84d..8d1c2a4 100644
--- a/arch/powerpc/configs/mpc85xx_smp_defconfig
+++ b/arch/powerpc/configs/mpc85xx_smp_defconfig
@@ -28,6 +28,7 @@ CONFIG_MPC85xx_DS=y
CONFIG_MPC85xx_RDB=y
CONFIG_P1010_RDB=y
CONFIG_P1022_DS=y
+CONFIG_P1022_RDK=y
CONFIG_P1023_RDS=y
CONFIG_SOCRATES=y
CONFIG_KSI8560=y
diff --git a/arch/powerpc/platforms/85xx/Kconfig b/arch/powerpc/platforms/85xx/Kconfig
index 159c01e..f0f2c85 100644
--- a/arch/powerpc/platforms/85xx/Kconfig
+++ b/arch/powerpc/platforms/85xx/Kconfig
@@ -104,6 +104,13 @@ config P1022_DS
help
This option enables support for the Freescale P1022DS reference board.
+config P1022_RDK
+ bool "Freescale / iVeia P1022 RDK"
+ select DEFAULT_UIMAGE
+ help
+ This option enables support for the Freescale / iVeia P1022RDK
+ reference board.
+
config P1023_RDS
bool "Freescale P1023 RDS"
select DEFAULT_UIMAGE
diff --git a/arch/powerpc/platforms/85xx/Makefile b/arch/powerpc/platforms/85xx/Makefile
index 3dfe811..af417d2 100644
--- a/arch/powerpc/platforms/85xx/Makefile
+++ b/arch/powerpc/platforms/85xx/Makefile
@@ -15,6 +15,7 @@ obj-$(CONFIG_MPC85xx_MDS) += mpc85xx_mds.o
obj-$(CONFIG_MPC85xx_RDB) += mpc85xx_rdb.o
obj-$(CONFIG_P1010_RDB) += p1010rdb.o
obj-$(CONFIG_P1022_DS) += p1022_ds.o
+obj-$(CONFIG_P1022_RDK) += p1022_rdk.o
obj-$(CONFIG_P1023_RDS) += p1023_rds.o
obj-$(CONFIG_P2041_RDB) += p2041_rdb.o corenet_ds.o
obj-$(CONFIG_P3041_DS) += p3041_ds.o corenet_ds.o
diff --git a/arch/powerpc/platforms/85xx/p1022_rdk.c b/arch/powerpc/platforms/85xx/p1022_rdk.c
new file mode 100644
index 0000000..b3cf11b
--- /dev/null
+++ b/arch/powerpc/platforms/85xx/p1022_rdk.c
@@ -0,0 +1,195 @@
+/*
+ * P1022 RDK board specific routines
+ *
+ * Copyright 2012 Freescale Semiconductor, Inc.
+ *
+ * Author: Timur Tabi <timur@freescale.com>
+ *
+ * Based on p1022_ds.c
+ *
+ * This file is licensed under the terms of the GNU General Public License
+ * version 2. This program is licensed "as is" without any warranty of any
+ * kind, whether express or implied.
+ */
+
+#include <linux/pci.h>
+#include <linux/of_platform.h>
+#include <linux/memblock.h>
+#include <asm/div64.h>
+#include <asm/mpic.h>
+#include <asm/swiotlb.h>
+
+#include <sysdev/fsl_soc.h>
+#include <sysdev/fsl_pci.h>
+#include <asm/udbg.h>
+#include <asm/fsl_guts.h>
+#include "smp.h"
+
+#include "mpc85xx.h"
+
+#if defined(CONFIG_FB_FSL_DIU) || defined(CONFIG_FB_FSL_DIU_MODULE)
+
+/* DIU Pixel Clock bits of the CLKDVDR Global Utilities register */
+#define CLKDVDR_PXCKEN 0x80000000
+#define CLKDVDR_PXCKINV 0x10000000
+#define CLKDVDR_PXCKDLY 0x06000000
+#define CLKDVDR_PXCLK_MASK 0x00FF0000
+
+/**
+ * p1022rdk_set_monitor_port: switch the output to a different monitor port
+ */
+static void p1022rdk_set_monitor_port(enum fsl_diu_monitor_port port)
+{
+ if (port != FSL_DIU_PORT_DVI) {
+ pr_err("p1022rdk: unsupported monitor port %i\n", port);
+ return;
+ }
+}
+
+/**
+ * p1022rdk_set_pixel_clock: program the DIU's clock
+ *
+ * @pixclock: the wavelength, in picoseconds, of the clock
+ */
+void p1022rdk_set_pixel_clock(unsigned int pixclock)
+{
+ struct device_node *guts_np = NULL;
+ struct ccsr_guts __iomem *guts;
+ unsigned long freq;
+ u64 temp;
+ u32 pxclk;
+
+ /* Map the global utilities registers. */
+ guts_np = of_find_compatible_node(NULL, NULL, "fsl,p1022-guts");
+ if (!guts_np) {
+ pr_err("p1022rdk: missing global utilties device node\n");
+ return;
+ }
+
+ guts = of_iomap(guts_np, 0);
+ of_node_put(guts_np);
+ if (!guts) {
+ pr_err("p1022rdk: could not map global utilties device\n");
+ return;
+ }
+
+ /* Convert pixclock from a wavelength to a frequency */
+ temp = 1000000000000ULL;
+ do_div(temp, pixclock);
+ freq = temp;
+
+ /*
+ * 'pxclk' is the ratio of the platform clock to the pixel clock.
+ * This number is programmed into the CLKDVDR register, and the valid
+ * range of values is 2-255.
+ */
+ pxclk = DIV_ROUND_CLOSEST(fsl_get_sys_freq(), freq);
+ pxclk = clamp_t(u32, pxclk, 2, 255);
+
+ /* Disable the pixel clock, and set it to non-inverted and no delay */
+ clrbits32(&guts->clkdvdr,
+ CLKDVDR_PXCKEN | CLKDVDR_PXCKDLY | CLKDVDR_PXCLK_MASK);
+
+ /* Enable the clock and set the pxclk */
+ setbits32(&guts->clkdvdr, CLKDVDR_PXCKEN | (pxclk << 16));
+
+ iounmap(guts);
+}
+
+/**
+ * p1022rdk_valid_monitor_port: set the monitor port for sysfs
+ */
+enum fsl_diu_monitor_port
+p1022rdk_valid_monitor_port(enum fsl_diu_monitor_port port)
+{
+ return FSL_DIU_PORT_DVI;
+}
+
+#endif
+
+void __init p1022_rdk_pic_init(void)
+{
+ struct mpic *mpic = mpic_alloc(NULL, 0, MPIC_BIG_ENDIAN |
+ MPIC_SINGLE_DEST_CPU,
+ 0, 256, " OpenPIC ");
+ BUG_ON(mpic == NULL);
+ mpic_init(mpic);
+}
+
+/*
+ * Setup the architecture
+ */
+static void __init p1022_rdk_setup_arch(void)
+{
+#ifdef CONFIG_PCI
+ struct device_node *np;
+#endif
+ dma_addr_t max = 0xffffffff;
+
+ if (ppc_md.progress)
+ ppc_md.progress("p1022_rdk_setup_arch()", 0);
+
+#ifdef CONFIG_PCI
+ for_each_compatible_node(np, "pci", "fsl,p1022-pcie") {
+ struct resource rsrc;
+ struct pci_controller *hose;
+
+ of_address_to_resource(np, 0, &rsrc);
+
+ if ((rsrc.start & 0xfffff) == 0x8000)
+ fsl_add_bridge(np, 1);
+ else
+ fsl_add_bridge(np, 0);
+
+ hose = pci_find_hose_for_OF_device(np);
+ max = min(max, hose->dma_window_base_cur +
+ hose->dma_window_size);
+ }
+#endif
+
+#if defined(CONFIG_FB_FSL_DIU) || defined(CONFIG_FB_FSL_DIU_MODULE)
+ diu_ops.set_monitor_port = p1022rdk_set_monitor_port;
+ diu_ops.set_pixel_clock = p1022rdk_set_pixel_clock;
+ diu_ops.valid_monitor_port = p1022rdk_valid_monitor_port;
+#endif
+
+ mpc85xx_smp_init();
+
+#ifdef CONFIG_SWIOTLB
+ if ((memblock_end_of_DRAM() - 1) > max) {
+ ppc_swiotlb_enable = 1;
+ set_pci_dma_ops(&swiotlb_dma_ops);
+ ppc_md.pci_dma_dev_setup = pci_dma_dev_setup_swiotlb;
+ }
+#endif
+
+ pr_info("Freescale / iVeia P1022 RDK reference board\n");
+}
+
+machine_device_initcall(p1022_rdk, mpc85xx_common_publish_devices);
+
+machine_arch_initcall(p1022_rdk, swiotlb_setup_bus_notifier);
+
+/*
+ * Called very early, device-tree isn't unflattened
+ */
+static int __init p1022_rdk_probe(void)
+{
+ unsigned long root = of_get_flat_dt_root();
+
+ return of_flat_dt_is_compatible(root, "fsl,p1022rdk");
+}
+
+define_machine(p1022_rdk) {
+ .name = "P1022 RDK",
+ .probe = p1022_rdk_probe,
+ .setup_arch = p1022_rdk_setup_arch,
+ .init_IRQ = p1022_rdk_pic_init,
+#ifdef CONFIG_PCI
+ .pcibios_fixup_bus = fsl_pcibios_fixup_bus,
+#endif
+ .get_irq = mpic_get_irq,
+ .restart = fsl_rstcr_restart,
+ .calibrate_decr = generic_calibrate_decr,
+ .progress = udbg_progress,
+};
--
1.7.3.4
^ permalink raw reply related
* Re: [PATCH] powerpc/mm: add ZONE_NORMAL zone for 64 bit kernel
From: Timur Tabi @ 2012-07-23 23:15 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: Wood Scott-B07421, Hu Mingkai-B21284,
linuxppc-dev@lists.ozlabs.org, Xie Shaohui-B21989,
Chen Yuanquan-B41889
In-Reply-To: <1343085145.2957.44.camel@pasglop>
Benjamin Herrenschmidt wrote:
> Sure, that's the right way to go, I meant bits of pieces of the
> infrastructure in between. Why diverge from other archs gratuituously
> here ?
Ok, I'm confused. Are you suggesting that drivers do this:
u64 fsl_dma_dmamask = DMA_BIT_MASK(36);
dev->dma_mask = &fsl_dma_dmamask;
v = dma_alloc_coherent(dev, ..., GFP_DMA32);
That is, set the DMA mask *and* set GFP_DMA32? That seems redundant.
I don't understand why a driver would set GFP_DMA32 if it has already set
the mask.
--
Timur Tabi
Linux kernel developer at Freescale
^ permalink raw reply
* Re: [PATCH] powerpc/mm: add ZONE_NORMAL zone for 64 bit kernel
From: Benjamin Herrenschmidt @ 2012-07-23 23:29 UTC (permalink / raw)
To: Timur Tabi
Cc: Wood Scott-B07421, Hu Mingkai-B21284,
linuxppc-dev@lists.ozlabs.org, Xie Shaohui-B21989,
Chen Yuanquan-B41889
In-Reply-To: <500DDB1B.9030900@freescale.com>
On Mon, 2012-07-23 at 18:15 -0500, Timur Tabi wrote:
> Benjamin Herrenschmidt wrote:
> > Sure, that's the right way to go, I meant bits of pieces of the
> > infrastructure in between. Why diverge from other archs gratuituously
> > here ?
>
> Ok, I'm confused. Are you suggesting that drivers do this:
>
> u64 fsl_dma_dmamask = DMA_BIT_MASK(36);
> dev->dma_mask = &fsl_dma_dmamask;
> v = dma_alloc_coherent(dev, ..., GFP_DMA32);
>
> That is, set the DMA mask *and* set GFP_DMA32? That seems redundant.
No, but dma_alloc_coherent would under the hood.
> I don't understand why a driver would set GFP_DMA32 if it has already set
> the mask.
The layers in between, not the well behaved drivers. Again, we have
ZONE_DMA32 specifically for the purpose, why use something else ?
In any case, make the whole thing at the very least a config option, I
don't want sane HW to have to deal with split zones.
Cheers,
Ben.
^ permalink raw reply
* Re: [PATCH] powerpc/mm: add ZONE_NORMAL zone for 64 bit kernel
From: Benjamin Herrenschmidt @ 2012-07-23 23:30 UTC (permalink / raw)
To: Timur Tabi
Cc: Wood Scott-B07421, Hu Mingkai-B21284,
linuxppc-dev@lists.ozlabs.org, Xie Shaohui-B21989,
Chen Yuanquan-B41889
In-Reply-To: <1343086186.2957.46.camel@pasglop>
On Tue, 2012-07-24 at 09:29 +1000, Benjamin Herrenschmidt wrote:
> The layers in between, not the well behaved drivers. Again, we have
> ZONE_DMA32 specifically for the purpose, why use something else ?
>
> In any case, make the whole thing at the very least a config option, I
> don't want sane HW to have to deal with split zones.
Or if possible a flag set by machine probe()
Cheers,
Ben.
^ permalink raw reply
* Re: [PATCH] powerpc/mm: add ZONE_NORMAL zone for 64 bit kernel
From: Timur Tabi @ 2012-07-23 23:36 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: Wood Scott-B07421, Hu Mingkai-B21284,
linuxppc-dev@lists.ozlabs.org, Xie Shaohui-B21989,
Chen Yuanquan-B41889
In-Reply-To: <1343086186.2957.46.camel@pasglop>
Benjamin Herrenschmidt wrote:
> No, but dma_alloc_coherent would under the hood.
Which is what Shaohui's patch does. Well, it does it for GFP_DMA instead
of GFP_DMA32, but still.
When you said, "Drivers who know about a 32-bit limitations use
GFP_DMA32", I thought you meant that drivers should *set* GFP_DMA32.
>> I don't understand why a driver would set GFP_DMA32 if it has already set
>> the mask.
>
> The layers in between, not the well behaved drivers. Again, we have
> ZONE_DMA32 specifically for the purpose, why use something else ?
>
> In any case, make the whole thing at the very least a config option, I
> don't want sane HW to have to deal with split zones.
The DMA zone only kicks in if the DMA mask is set to a size smaller that
available physical memory. Sane HW should set the DMA mask to
DMA_BIT_MASK(36). And we have plenty of sane HW on our SOCs, but not
every device is like that.
The whole point behind this patch is that some drivers are setting a DMA
mask of 32, but still getting memory above 4GB.
--
Timur Tabi
Linux kernel developer at Freescale
^ permalink raw reply
* Re: [PATCH] powerpc/mm: add ZONE_NORMAL zone for 64 bit kernel
From: Scott Wood @ 2012-07-24 1:37 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: Wood Scott-B07421, Xie Shaohui-B21989, Hu Mingkai-B21284,
Chen Yuanquan-B41889, linuxppc-dev@lists.ozlabs.org, Timur Tabi
In-Reply-To: <1343086215.2957.47.camel@pasglop>
On 07/23/2012 06:30 PM, Benjamin Herrenschmidt wrote:
> On Tue, 2012-07-24 at 09:29 +1000, Benjamin Herrenschmidt wrote:
>
>> The layers in between, not the well behaved drivers. Again, we have
>> ZONE_DMA32 specifically for the purpose, why use something else ?
>>
>> In any case, make the whole thing at the very least a config option, I
>> don't want sane HW to have to deal with split zones.
>
> Or if possible a flag set by machine probe()
I suggested making the threshold configurable by platform code. Sane
hardware would leave it at its default of infinity (~0ULL), and you
wouldn't have a split zone. Our hardware would set it at 31-bit.
It looks like this is already sort-of done for ISA_DMA_THRESHOLD for
32-bit non-coherent-DMA platforms (amigaone sets a 24-bit threshold),
though I don't see where ZONE_DMA is limited accordingly.
We'd add an additional threshold for ZONE_DMA32, make it actually affect
the zone definition, and make the standard alloc_coherent() honor it.
-Scott
^ permalink raw reply
* Re: [PATCH] powerpc/mm: add ZONE_NORMAL zone for 64 bit kernel
From: Scott Wood @ 2012-07-24 1:49 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: Mingkai Hu, linuxppc-dev, Shaohui Xie, Chen Yuanquan
In-Reply-To: <1343082030.2957.38.camel@pasglop>
On 07/23/2012 05:20 PM, Benjamin Herrenschmidt wrote:
> On Mon, 2012-07-23 at 11:17 -0500, Scott Wood wrote:
>>> This is wrong.
>>
>> How so?
>>
>>> Don't you have an iommu do deal with those devices anyway ?
>>
>> Yes, but we don't yet have DMA API support for it, it would lower
>> performance because we'd have to use a lot of subwindows which are
>> poorly cached (and even then we wouldn't be able to map more than 256
>> pages at once on a given device), and the IOMMU may not be available at
>> all if we're being virtualized.
>
> Ugh ? You mean some designers need to be fired urgently and wasted
> everybody's time implementing an unusable iommu ? Nice one ...
Yeah, that's old news.
It's somewhat usable for specific purposes, using very large pages, but
not for arbitrary use.
>>> But even then, I'm dubious this is really needed.
>>
>> We'd like our drivers to stop crashing with more than 4GiB of RAM on 64-bit.
>
> Fix your HW :-)
I wish... Some hardware people may solicit input from us every now and
again, but ultimately they do what they want.
Returning addresses in excess of a device's declared DMA mask is
something that needs fixing too, though.
-Scott
^ permalink raw reply
* Re: [PATCH] mpc85xx_defconfig: add IDE support for MPC85xxCDS
From: Zhao Chenhui @ 2012-07-24 2:30 UTC (permalink / raw)
To: Alan Cox; +Cc: linuxppc-dev, linux-kernel
In-Reply-To: <20120720150900.082afc7c@pyramind.ukuu.org.uk>
On Fri, Jul 20, 2012 at 03:09:00PM +0100, Alan Cox wrote:
> On Fri, 20 Jul 2012 20:45:25 +0800
> Zhao Chenhui <chenhui.zhao@freescale.com> wrote:
>
> > Add IDE support for MPC85xxCDS.
> >
> > Signed-off-by: Zhao Chenhui <chenhui.zhao@freescale.com>
> > ---
> > arch/powerpc/configs/mpc85xx_defconfig | 2 ++
> > 1 files changed, 2 insertions(+), 0 deletions(-)
> >
> > diff --git a/arch/powerpc/configs/mpc85xx_defconfig b/arch/powerpc/configs/mpc85xx_defconfig
> > index 03ee911..45eda33 100644
> > --- a/arch/powerpc/configs/mpc85xx_defconfig
> > +++ b/arch/powerpc/configs/mpc85xx_defconfig
> > @@ -105,6 +105,8 @@ CONFIG_BLK_DEV_RAM=y
> > CONFIG_BLK_DEV_RAM_SIZE=131072
> > CONFIG_MISC_DEVICES=y
> > CONFIG_EEPROM_LEGACY=y
> > +CONFIG_IDE=y
> > +CONFIG_BLK_DEV_VIA82CXXX=y
>
> CONFIG_IDE is obsolete we shouldn't be adding it to anything as it will
> eventually go away. Please use the ATA drivers.
>
Thanks. I will replace it with the ATA driver.
-Chenhui
^ permalink raw reply
* Re: [PATCH] powerpc/mm: add ZONE_NORMAL zone for 64 bit kernel
From: Benjamin Herrenschmidt @ 2012-07-24 3:08 UTC (permalink / raw)
To: Timur Tabi
Cc: Wood Scott-B07421, Hu Mingkai-B21284,
linuxppc-dev@lists.ozlabs.org, Xie Shaohui-B21989,
Chen Yuanquan-B41889
In-Reply-To: <500DDFF3.3000408@freescale.com>
On Mon, 2012-07-23 at 18:36 -0500, Timur Tabi wrote:
> The DMA zone only kicks in if the DMA mask is set to a size smaller
> that
> available physical memory. Sane HW should set the DMA mask to
> DMA_BIT_MASK(36). And we have plenty of sane HW on our SOCs, but not
> every device is like that.
>
> The whole point behind this patch is that some drivers are setting a
> DMA
> mask of 32, but still getting memory above 4GB.
Sure but I don't want to create the zones in the first place (and thus
introduce the added pressure on the memory management) on machines that
don't need it.
Cheers,
Ben.
^ permalink raw reply
* Re: next/mmotm unbootable on G5: irqdomain
From: Benjamin Herrenschmidt @ 2012-07-24 3:21 UTC (permalink / raw)
To: Grant Likely
Cc: Stephen Rothwell, Hugh Dickins, linux-kernel, Milton Miller,
Paul Mundt, Rob Herring, Andrew Morton, linuxppc-dev,
Thomas Gleixner
In-Reply-To: <CACxGe6udruWL7oo6Qp6jkwQYceduTO1h1gKFz9TFX1TPZoNFNQ@mail.gmail.com>
On Mon, 2012-07-23 at 16:32 -0600, Grant Likely wrote:
> > As-is I'm backing off from the linear/legacy/tree merge patch as just
> > too risky. I've already pulled that stuff out of linux-next.
>
> Can I pull you pseries fix into my tree (my preference), or do I need
> to rebase on top of yours?
The mpic fix for the g5 is in Linus tree already, I added it on top of
powerpc -next before I asked Linus to pull.
For pseries (ie the fix for irq_find_mapping vs. radix), I don't have a
formal patch, just the one I hand typed in my previous email, so do
whatever you want with it.
Cheers,
Ben.
^ permalink raw reply
* Re: [PATCH] powerpc/mm: add ZONE_NORMAL zone for 64 bit kernel
From: Tabi Timur-B04825 @ 2012-07-24 3:52 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: Wood Scott-B07421, Hu Mingkai-B21284,
linuxppc-dev@lists.ozlabs.org, Xie Shaohui-B21989,
Chen Yuanquan-B41889
In-Reply-To: <1343099318.3715.0.camel@pasglop>
Benjamin Herrenschmidt wrote:
> Sure but I don't want to create the zones in the first place (and thus
> introduce the added pressure on the memory management) on machines that
> don't need it.
Ah yes, I forgot about memory pressure.
--=20
Timur Tabi
Linux kernel developer at Freescale=
^ permalink raw reply
* RE: [PATCH] powerpc/mm: add ZONE_NORMAL zone for 64 bit kernel
From: Zang Roy-R61911 @ 2012-07-24 3:59 UTC (permalink / raw)
To: Benjamin Herrenschmidt, Tabi Timur-B04825, Wood Scott-B07421
Cc: linuxppc-dev@lists.ozlabs.org, Hu Mingkai-B21284,
Chen Yuanquan-B41889, Xie Shaohui-B21989
In-Reply-To: <1343099318.3715.0.camel@pasglop>
> -----Original Message-----
> From: Linuxppc-dev [mailto:linuxppc-dev-bounces+tie-
> fei.zang=3Dfreescale.com@lists.ozlabs.org] On Behalf Of Benjamin
> Herrenschmidt
> Sent: Tuesday, July 24, 2012 11:09 AM
> To: Tabi Timur-B04825
> Cc: Wood Scott-B07421; Hu Mingkai-B21284; linuxppc-dev@lists.ozlabs.org;
> Xie Shaohui-B21989; Chen Yuanquan-B41889
> Subject: Re: [PATCH] powerpc/mm: add ZONE_NORMAL zone for 64 bit kernel
>=20
> On Mon, 2012-07-23 at 18:36 -0500, Timur Tabi wrote:
> > The DMA zone only kicks in if the DMA mask is set to a size smaller
> > that
> > available physical memory. Sane HW should set the DMA mask to
> > DMA_BIT_MASK(36). And we have plenty of sane HW on our SOCs, but not
> > every device is like that.
> >
> > The whole point behind this patch is that some drivers are setting a
> > DMA
> > mask of 32, but still getting memory above 4GB.
>=20
> Sure but I don't want to create the zones in the first place (and thus
> introduce the added pressure on the memory management) on machines that
> don't need it.
OK, then how do you think Scott's suggestion to add a configurable threshol=
d?
Roy
^ permalink raw reply
* Re: [PATCH] powerpc/mm: add ZONE_NORMAL zone for 64 bit kernel
From: Tabi Timur-B04825 @ 2012-07-24 4:04 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: Wood Scott-B07421, Hu Mingkai-B21284,
linuxppc-dev@lists.ozlabs.org, Xie Shaohui-B21989,
Chen Yuanquan-B41889
In-Reply-To: <1343099318.3715.0.camel@pasglop>
Benjamin Herrenschmidt wrote:
> Sure but I don't want to create the zones in the first place (and thus
> introduce the added pressure on the memory management) on machines that
> don't need it.
One thing that does confuse me -- by default, we don't create a=20
ZONE_NORMAL. We only create a ZONE_DMA. Why is that? Shouldn't it be=20
the other way around?
--=20
Timur Tabi
Linux kernel developer at Freescale=
^ permalink raw reply
* Re: next/mmotm unbootable on G5: irqdomain
From: Grant Likely @ 2012-07-24 4:37 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: Stephen Rothwell, Hugh Dickins, linux-kernel, Milton Miller,
Paul Mundt, Rob Herring, Andrew Morton, linuxppc-dev,
Thomas Gleixner
In-Reply-To: <1343100106.3715.2.camel@pasglop>
On Mon, Jul 23, 2012 at 9:21 PM, Benjamin Herrenschmidt
<benh@kernel.crashing.org> wrote:
> On Mon, 2012-07-23 at 16:32 -0600, Grant Likely wrote:
>> > As-is I'm backing off from the linear/legacy/tree merge patch as just
>> > too risky. I've already pulled that stuff out of linux-next.
>>
>> Can I pull you pseries fix into my tree (my preference), or do I need
>> to rebase on top of yours?
>
> The mpic fix for the g5 is in Linus tree already, I added it on top of
> powerpc -next before I asked Linus to pull.
>
> For pseries (ie the fix for irq_find_mapping vs. radix), I don't have a
> formal patch, just the one I hand typed in my previous email, so do
> whatever you want with it.
Okay, I'll merge in Linus' tree at the appropriate point to protect
against bisection, and I'll fix up the appropriate patch that touches
irq_find_mapping.
g.
^ 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