* Re: [PATCH v4 7/8] DMA: Freescale: use spin_lock_bh instead of spin_lock_irqsave
From: Vinod Koul @ 2014-05-02 16:51 UTC (permalink / raw)
To: hongbo.zhang
Cc: leo.li, vkoul, linux-kernel, scottwood, dmaengine, dan.j.williams,
linuxppc-dev
In-Reply-To: <1397809071-5353-8-git-send-email-hongbo.zhang@freescale.com>
On Fri, Apr 18, 2014 at 04:17:50PM +0800, hongbo.zhang@freescale.com wrote:
> From: Hongbo Zhang <hongbo.zhang@freescale.com>
>
> The usage of spin_lock_irqsave() is a stronger locking mechanism than is
> required throughout the driver. The minimum locking required should be used
> instead. Interrupts will be turned off and context will be saved, it is
> unnecessary to use irqsave.
>
> This patch changes all instances of spin_lock_irqsave() to spin_lock_bh(). All
> manipulation of protected fields is done using tasklet context or weaker, which
> makes spin_lock_bh() the correct choice.
>
This doesnt apply, perhpas due to depends on 6/8
--
~Vinod
> Signed-off-by: Hongbo Zhang <hongbo.zhang@freescale.com>
> Signed-off-by: Qiang Liu <qiang.liu@freescale.com>
> ---
> drivers/dma/fsldma.c | 25 ++++++++++---------------
> 1 file changed, 10 insertions(+), 15 deletions(-)
>
> diff --git a/drivers/dma/fsldma.c b/drivers/dma/fsldma.c
> index 374ca97..6e1c9b3 100644
> --- a/drivers/dma/fsldma.c
> +++ b/drivers/dma/fsldma.c
> @@ -396,10 +396,9 @@ static dma_cookie_t fsl_dma_tx_submit(struct dma_async_tx_descriptor *tx)
> struct fsldma_chan *chan = to_fsl_chan(tx->chan);
> struct fsl_desc_sw *desc = tx_to_fsl_desc(tx);
> struct fsl_desc_sw *child;
> - unsigned long flags;
> dma_cookie_t cookie = -EINVAL;
>
> - spin_lock_irqsave(&chan->desc_lock, flags);
> + spin_lock_bh(&chan->desc_lock);
>
> /*
> * assign cookies to all of the software descriptors
> @@ -412,7 +411,7 @@ static dma_cookie_t fsl_dma_tx_submit(struct dma_async_tx_descriptor *tx)
> /* put this transaction onto the tail of the pending queue */
> append_ld_queue(chan, desc);
>
> - spin_unlock_irqrestore(&chan->desc_lock, flags);
> + spin_unlock_bh(&chan->desc_lock);
>
> return cookie;
> }
> @@ -726,15 +725,14 @@ static void fsldma_free_desc_list_reverse(struct fsldma_chan *chan,
> static void fsl_dma_free_chan_resources(struct dma_chan *dchan)
> {
> struct fsldma_chan *chan = to_fsl_chan(dchan);
> - unsigned long flags;
>
> chan_dbg(chan, "free all channel resources\n");
> - spin_lock_irqsave(&chan->desc_lock, flags);
> + spin_lock_bh(&chan->desc_lock);
> fsldma_cleanup_descriptors(chan);
> fsldma_free_desc_list(chan, &chan->ld_pending);
> fsldma_free_desc_list(chan, &chan->ld_running);
> fsldma_free_desc_list(chan, &chan->ld_completed);
> - spin_unlock_irqrestore(&chan->desc_lock, flags);
> + spin_unlock_bh(&chan->desc_lock);
>
> dma_pool_destroy(chan->desc_pool);
> chan->desc_pool = NULL;
> @@ -953,7 +951,6 @@ static int fsl_dma_device_control(struct dma_chan *dchan,
> {
> struct dma_slave_config *config;
> struct fsldma_chan *chan;
> - unsigned long flags;
> int size;
>
> if (!dchan)
> @@ -963,7 +960,7 @@ static int fsl_dma_device_control(struct dma_chan *dchan,
>
> switch (cmd) {
> case DMA_TERMINATE_ALL:
> - spin_lock_irqsave(&chan->desc_lock, flags);
> + spin_lock_bh(&chan->desc_lock);
>
> /* Halt the DMA engine */
> dma_halt(chan);
> @@ -974,7 +971,7 @@ static int fsl_dma_device_control(struct dma_chan *dchan,
> fsldma_free_desc_list(chan, &chan->ld_completed);
> chan->idle = true;
>
> - spin_unlock_irqrestore(&chan->desc_lock, flags);
> + spin_unlock_bh(&chan->desc_lock);
> return 0;
>
> case DMA_SLAVE_CONFIG:
> @@ -1016,11 +1013,10 @@ static int fsl_dma_device_control(struct dma_chan *dchan,
> static void fsl_dma_memcpy_issue_pending(struct dma_chan *dchan)
> {
> struct fsldma_chan *chan = to_fsl_chan(dchan);
> - unsigned long flags;
>
> - spin_lock_irqsave(&chan->desc_lock, flags);
> + spin_lock_bh(&chan->desc_lock);
> fsl_chan_xfer_ld_queue(chan);
> - spin_unlock_irqrestore(&chan->desc_lock, flags);
> + spin_unlock_bh(&chan->desc_lock);
> }
>
> /**
> @@ -1119,11 +1115,10 @@ static irqreturn_t fsldma_chan_irq(int irq, void *data)
> static void dma_do_tasklet(unsigned long data)
> {
> struct fsldma_chan *chan = (struct fsldma_chan *)data;
> - unsigned long flags;
>
> chan_dbg(chan, "tasklet entry\n");
>
> - spin_lock_irqsave(&chan->desc_lock, flags);
> + spin_lock_bh(&chan->desc_lock);
>
> /* the hardware is now idle and ready for more */
> chan->idle = true;
> @@ -1131,7 +1126,7 @@ static void dma_do_tasklet(unsigned long data)
> /* Run all cleanup for descriptors which have been completed */
> fsldma_cleanup_descriptors(chan);
>
> - spin_unlock_irqrestore(&chan->desc_lock, flags);
> + spin_unlock_bh(&chan->desc_lock);
>
> chan_dbg(chan, "tasklet exit\n");
> }
> --
> 1.7.9.5
>
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe dmaengine" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
^ permalink raw reply
* Re: [PATCH v4 5/8] DMA: Freescale: move functions to avoid forward declarations
From: Vinod Koul @ 2014-05-02 16:50 UTC (permalink / raw)
To: hongbo.zhang
Cc: leo.li, vkoul, linux-kernel, scottwood, dmaengine, dan.j.williams,
linuxppc-dev
In-Reply-To: <1397809071-5353-6-git-send-email-hongbo.zhang@freescale.com>
On Fri, Apr 18, 2014 at 04:17:48PM +0800, hongbo.zhang@freescale.com wrote:
> From: Hongbo Zhang <hongbo.zhang@freescale.com>
>
> These functions will be modified in the next patch in the series. By moving the
> function in a patch separate from the changes, it will make review easier.
>
Applied, thanks
--
~Vinod
^ permalink raw reply
* Re: [PATCH v4 8/8] DMA: Freescale: add suspend resume functions for DMA driver
From: Vinod Koul @ 2014-05-02 16:46 UTC (permalink / raw)
To: hongbo.zhang
Cc: leo.li, vkoul, linux-kernel, scottwood, dmaengine, dan.j.williams,
linuxppc-dev
In-Reply-To: <1397809071-5353-9-git-send-email-hongbo.zhang@freescale.com>
On Fri, Apr 18, 2014 at 04:17:51PM +0800, hongbo.zhang@freescale.com wrote:
> From: Hongbo Zhang <hongbo.zhang@freescale.com>
>
> This patch adds suspend resume functions for Freescale DMA driver.
> .prepare callback is used to stop further descriptors from being added into the
> pending queue, and also issue pending queues into execution if there is any.
> .suspend callback makes sure all the pending jobs are cleaned up and all the
> channels are idle, and save the mode registers.
> .resume callback re-initializes the channels by restore the mode registers.
>
> +
> +static const struct dev_pm_ops fsldma_pm_ops = {
> + .prepare = fsldma_prepare,
> + .suspend = fsldma_suspend,
> + .resume = fsldma_resume,
> +};
I think this is not correct. We discussed this sometime back on list. The
DMAengine drivers should use late resume and early suspend to ensure they get
suspended after clients (who should use normal ones) and resume before them
--
~Vinod
^ permalink raw reply
* Re: [PATCH RFC v12 3/7] dma: mpc512x: add support for peripheral transfers
From: Vinod Koul @ 2014-05-02 17:03 UTC (permalink / raw)
To: Alexander Popov
Cc: Lars-Peter Clausen, Arnd Bergmann, Gerhard Sittig,
Andy Shevchenko, dmaengine, Dan Williams, Anatolij Gustschin,
linuxppc-dev
In-Reply-To: <1398261209-5578-4-git-send-email-a13xp0p0v88@gmail.com>
On Wed, Apr 23, 2014 at 05:53:25PM +0400, Alexander Popov wrote:
> Introduce support for slave s/g transfer preparation and the associated
> device control callback in the MPC512x DMA controller driver, which adds
> support for data transfers between memory and peripheral I/O to the
> previously supported mem-to-mem transfers.
>
> Signed-off-by: Alexander Popov <a13xp0p0v88@gmail.com>
> ---
> drivers/dma/mpc512x_dma.c | 239 +++++++++++++++++++++++++++++++++++++++++++++-
> 1 file changed, 234 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/dma/mpc512x_dma.c b/drivers/dma/mpc512x_dma.c
> index 0b17f4d..ca2fe03 100644
> --- a/drivers/dma/mpc512x_dma.c
> +++ b/drivers/dma/mpc512x_dma.c
> @@ -2,6 +2,7 @@
> * Copyright (C) Freescale Semicondutor, Inc. 2007, 2008.
> * Copyright (C) Semihalf 2009
> * Copyright (C) Ilya Yanok, Emcraft Systems 2010
> + * Copyright (C) Alexander Popov, Promcontroller 2014
> *
> * Written by Piotr Ziecik <kosmo@semihalf.com>. Hardware description
> * (defines, structures and comments) was taken from MPC5121 DMA driver
> @@ -29,8 +30,17 @@
> */
>
> /*
> - * This is initial version of MPC5121 DMA driver. Only memory to memory
> - * transfers are supported (tested using dmatest module).
> + * MPC512x and MPC8308 DMA driver. It supports
> + * memory to memory data transfers (tested using dmatest module) and
> + * data transfers between memory and peripheral I/O memory
> + * by means of slave s/g with these limitations:
> + * - chunked transfers (transfers with more than one part) are refused
> + * as long as proper support for scatter/gather is missing;
> + * - transfers on MPC8308 always start from software as this SoC appears
> + * not to have external request lines for peripheral flow control;
> + * - minimal memory <-> I/O memory transfer chunk is 4 bytes and consequently
> + * source and destination addresses must be 4-byte aligned
> + * and transfer size must be aligned on (4 * maxburst) boundary;
> */
>
> #include <linux/module.h>
> @@ -189,6 +199,7 @@ struct mpc_dma_desc {
> dma_addr_t tcd_paddr;
> int error;
> struct list_head node;
> + int will_access_peripheral;
> };
>
> struct mpc_dma_chan {
> @@ -201,6 +212,12 @@ struct mpc_dma_chan {
> struct mpc_dma_tcd *tcd;
> dma_addr_t tcd_paddr;
>
> + /* Settings for access to peripheral FIFO */
> + dma_addr_t src_per_paddr;
> + u32 src_tcd_nunits;
> + dma_addr_t dst_per_paddr;
> + u32 dst_tcd_nunits;
> +
> /* Lock for this structure */
> spinlock_t lock;
> };
> @@ -251,8 +268,23 @@ static void mpc_dma_execute(struct mpc_dma_chan *mchan)
> struct mpc_dma_desc *mdesc;
> int cid = mchan->chan.chan_id;
>
> - /* Move all queued descriptors to active list */
> - list_splice_tail_init(&mchan->queued, &mchan->active);
> + while (!list_empty(&mchan->queued)) {
> + mdesc = list_first_entry(&mchan->queued,
> + struct mpc_dma_desc, node);
> + /*
> + * Grab either several mem-to-mem transfer descriptors
> + * or one peripheral transfer descriptor,
> + * don't mix mem-to-mem and peripheral transfer descriptors
> + * within the same 'active' list.
> + */
> + if (mdesc->will_access_peripheral) {
> + if (list_empty(&mchan->active))
> + list_move_tail(&mdesc->node, &mchan->active);
> + break;
> + } else {
> + list_move_tail(&mdesc->node, &mchan->active);
> + }
> + }
>
> /* Chain descriptors into one transaction */
> list_for_each_entry(mdesc, &mchan->active, node) {
> @@ -278,7 +310,17 @@ static void mpc_dma_execute(struct mpc_dma_chan *mchan)
>
> if (first != prev)
> mdma->tcd[cid].e_sg = 1;
> - out_8(&mdma->regs->dmassrt, cid);
> +
> + if (mdma->is_mpc8308) {
> + /* MPC8308, no request lines, software initiated start */
> + out_8(&mdma->regs->dmassrt, cid);
> + } else if (first->will_access_peripheral) {
> + /* Peripherals involved, start by external request signal */
> + out_8(&mdma->regs->dmaserq, cid);
> + } else {
> + /* Memory to memory transfer, software initiated start */
> + out_8(&mdma->regs->dmassrt, cid);
> + }
> }
>
> /* Handle interrupt on one half of DMA controller (32 channels) */
> @@ -596,6 +638,7 @@ mpc_dma_prep_memcpy(struct dma_chan *chan, dma_addr_t dst, dma_addr_t src,
> }
>
> mdesc->error = 0;
> + mdesc->will_access_peripheral = 0;
> tcd = mdesc->tcd;
>
> /* Prepare Transfer Control Descriptor for this transaction */
> @@ -643,6 +686,189 @@ mpc_dma_prep_memcpy(struct dma_chan *chan, dma_addr_t dst, dma_addr_t src,
> return &mdesc->desc;
> }
>
> +static struct dma_async_tx_descriptor *
> +mpc_dma_prep_slave_sg(struct dma_chan *chan, struct scatterlist *sgl,
> + unsigned int sg_len, enum dma_transfer_direction direction,
> + unsigned long flags, void *context)
> +{
> + struct mpc_dma *mdma = dma_chan_to_mpc_dma(chan);
> + struct mpc_dma_chan *mchan = dma_chan_to_mpc_dma_chan(chan);
> + struct mpc_dma_desc *mdesc = NULL;
> + dma_addr_t per_paddr;
> + u32 tcd_nunits;
> + struct mpc_dma_tcd *tcd;
> + unsigned long iflags;
> + struct scatterlist *sg;
> + size_t len;
> + int iter, i;
> +
> + /* Currently there is no proper support for scatter/gather */
Why? Is this HW or SW limitation?
> + if (sg_len != 1)
> + return NULL;
> +
> + if (!is_slave_direction(direction))
> + return NULL;
> +
> + for_each_sg(sgl, sg, sg_len, i) {
Then this doesn't make sense...
> + spin_lock_irqsave(&mchan->lock, iflags);
> +
> + mdesc = list_first_entry(&mchan->free,
> + struct mpc_dma_desc, node);
> + if (!mdesc) {
> + spin_unlock_irqrestore(&mchan->lock, iflags);
> + /* Try to free completed descriptors */
> + mpc_dma_process_completed(mdma);
> + return NULL;
> + }
> +
> + list_del(&mdesc->node);
> +
> + if (direction == DMA_DEV_TO_MEM) {
> + per_paddr = mchan->src_per_paddr;
> + tcd_nunits = mchan->src_tcd_nunits;
> + } else {
> + per_paddr = mchan->dst_per_paddr;
> + tcd_nunits = mchan->dst_tcd_nunits;
> + }
> +
> + spin_unlock_irqrestore(&mchan->lock, iflags);
> +
> + if (per_paddr == 0 || tcd_nunits == 0)
> + goto err_prep;
> +
> + mdesc->error = 0;
> + mdesc->will_access_peripheral = 1;
> +
> + /* Prepare Transfer Control Descriptor for this transaction */
> + tcd = mdesc->tcd;
> +
> + memset(tcd, 0, sizeof(struct mpc_dma_tcd));
> +
> + if (!IS_ALIGNED(sg_dma_address(sg), 4))
> + goto err_prep;
> +
> + if (direction == DMA_DEV_TO_MEM) {
> + tcd->saddr = per_paddr;
> + tcd->daddr = sg_dma_address(sg);
> + tcd->soff = 0;
> + tcd->doff = 4;
what are these?
> + } else {
> + tcd->saddr = sg_dma_address(sg);
> + tcd->daddr = per_paddr;
> + tcd->soff = 4;
> + tcd->doff = 0;
> + }
> +
> + tcd->ssize = MPC_DMA_TSIZE_4;
> + tcd->dsize = MPC_DMA_TSIZE_4;
> +
> + len = sg_dma_len(sg);
> + tcd->nbytes = tcd_nunits * 4;
> + if (!IS_ALIGNED(len, tcd->nbytes))
> + goto err_prep;
> +
> + iter = len / tcd->nbytes;
> + if (iter >= 1 << 15) {
> + /* len is too big */
> + goto err_prep;
> + }
> + /* citer_linkch contains the high bits of iter */
> + tcd->biter = iter & 0x1ff;
> + tcd->biter_linkch = iter >> 9;
> + tcd->citer = tcd->biter;
> + tcd->citer_linkch = tcd->biter_linkch;
> +
> + tcd->e_sg = 0;
> + tcd->d_req = 1;
> +
> + /* Place descriptor in prepared list */
> + spin_lock_irqsave(&mchan->lock, iflags);
> + list_add_tail(&mdesc->node, &mchan->prepared);
> + spin_unlock_irqrestore(&mchan->lock, iflags);
> + }
> +
> + return &mdesc->desc;
> +
> +err_prep:
> + /* Put the descriptor back */
> + spin_lock_irqsave(&mchan->lock, iflags);
> + list_add_tail(&mdesc->node, &mchan->free);
> + spin_unlock_irqrestore(&mchan->lock, iflags);
> +
> + return NULL;
> +}
> +
> +static int mpc_dma_device_control(struct dma_chan *chan, enum dma_ctrl_cmd cmd,
> + unsigned long arg)
> +{
> + struct mpc_dma_chan *mchan;
> + struct mpc_dma *mdma;
> + struct dma_slave_config *cfg;
> + unsigned long flags;
> +
> + mchan = dma_chan_to_mpc_dma_chan(chan);
> + switch (cmd) {
> + case DMA_TERMINATE_ALL:
> + /* Disable channel requests */
> + mdma = dma_chan_to_mpc_dma(chan);
> +
> + spin_lock_irqsave(&mchan->lock, flags);
> +
> + out_8(&mdma->regs->dmacerq, chan->chan_id);
> + list_splice_tail_init(&mchan->prepared, &mchan->free);
> + list_splice_tail_init(&mchan->queued, &mchan->free);
> + list_splice_tail_init(&mchan->active, &mchan->free);
> +
> + spin_unlock_irqrestore(&mchan->lock, flags);
> +
> + return 0;
empty line after this pls
> + case DMA_SLAVE_CONFIG:
> + /*
> + * Constraints:
> + * - only transfers between a peripheral device and
> + * memory are supported;
> + * - minimal transfer chunk is 4 bytes and consequently
> + * source and destination addresses must be 4-byte aligned
> + * and transfer size must be aligned on (4 * maxburst)
> + * boundary;
> + * - during the transfer RAM address is being incremented by
> + * the size of minimal transfer chunk;
> + * - peripheral port's address is constant during the transfer.
> + */
> +
> + cfg = (void *)arg;
> +
> + if (cfg->src_addr_width != DMA_SLAVE_BUSWIDTH_4_BYTES ||
> + cfg->dst_addr_width != DMA_SLAVE_BUSWIDTH_4_BYTES ||
and why this limtation, doesnt seem covered above?
> + !IS_ALIGNED(cfg->src_addr, 4) ||
> + !IS_ALIGNED(cfg->dst_addr, 4)) {
> + return -EINVAL;
> + }
> +
> + spin_lock_irqsave(&mchan->lock, flags);
> +
> + mchan->src_per_paddr = cfg->src_addr;
> + mchan->src_tcd_nunits = cfg->src_maxburst;
> + mchan->dst_per_paddr = cfg->dst_addr;
> + mchan->dst_tcd_nunits = cfg->dst_maxburst;
> +
> + /* Apply defaults */
> + if (mchan->src_tcd_nunits == 0)
> + mchan->src_tcd_nunits = 1;
> + if (mchan->dst_tcd_nunits == 0)
> + mchan->dst_tcd_nunits = 1;
> +
> + spin_unlock_irqrestore(&mchan->lock, flags);
> +
> + return 0;
empty line here too
> + default:
> + /* Unknown command */
> + break;
> + }
> +
> + return -ENXIO;
> +}
> +
> static int mpc_dma_probe(struct platform_device *op)
> {
> struct device_node *dn = op->dev.of_node;
> @@ -727,9 +953,12 @@ static int mpc_dma_probe(struct platform_device *op)
> dma->device_issue_pending = mpc_dma_issue_pending;
> dma->device_tx_status = mpc_dma_tx_status;
> dma->device_prep_dma_memcpy = mpc_dma_prep_memcpy;
> + dma->device_prep_slave_sg = mpc_dma_prep_slave_sg;
> + dma->device_control = mpc_dma_device_control;
>
> INIT_LIST_HEAD(&dma->channels);
> dma_cap_set(DMA_MEMCPY, dma->cap_mask);
> + dma_cap_set(DMA_SLAVE, dma->cap_mask);
>
> for (i = 0; i < dma->chancnt; i++) {
> mchan = &mdma->channels[i];
> --
> 1.8.4.2
>
--
~Vinod
^ permalink raw reply
* Re: [PATCH RFC v12 5/7] dma: of: add common xlate function for matching by channel id
From: Vinod Koul @ 2014-05-02 17:04 UTC (permalink / raw)
To: Alexander Popov, Arnd Bergmann
Cc: devicetree, Lars-Peter Clausen, Gerhard Sittig, Andy Shevchenko,
dmaengine, Dan Williams, Anatolij Gustschin, linuxppc-dev
In-Reply-To: <1398261209-5578-6-git-send-email-a13xp0p0v88@gmail.com>
On Wed, Apr 23, 2014 at 05:53:27PM +0400, Alexander Popov wrote:
> This patch adds a new common OF dma xlate callback function which will match a
> channel by it's id. The binding expects one integer argument which it will use to
> lookup the channel by the id.
>
> Unlike of_dma_simple_xlate this function is able to handle a system with
> multiple DMA controllers. When registering the of dma provider with
> of_dma_controller_register a pointer to the dma_device struct which is
> associated with the dt node needs to passed as the data parameter.
> New function will use this pointer to match only channels which belong to the
> specified DMA controller.
This patch needs review by DT folks too
>
> Signed-off-by: Alexander Popov <a13xp0p0v88@gmail.com>
> ---
> drivers/dma/of-dma.c | 35 +++++++++++++++++++++++++++++++++++
> include/linux/of_dma.h | 4 ++++
> 2 files changed, 39 insertions(+)
>
> diff --git a/drivers/dma/of-dma.c b/drivers/dma/of-dma.c
> index e8fe9dc..d5fbeaa 100644
> --- a/drivers/dma/of-dma.c
> +++ b/drivers/dma/of-dma.c
> @@ -218,3 +218,38 @@ struct dma_chan *of_dma_simple_xlate(struct of_phandle_args *dma_spec,
> &dma_spec->args[0]);
> }
> EXPORT_SYMBOL_GPL(of_dma_simple_xlate);
> +
> +/**
> + * of_dma_xlate_by_chan_id - Translate dt property to DMA channel by channel id
> + * @dma_spec: pointer to DMA specifier as found in the device tree
> + * @of_dma: pointer to DMA controller data
> + *
> + * This function can be used as the of xlate callback for DMA driver which wants
> + * to match the channel based on the channel id. When using this xlate function
> + * the #dma-cells propety of the DMA controller dt node needs to be set to 1.
> + * The data parameter of of_dma_controller_register must be a pointer to the
> + * dma_device struct the function should match upon.
> + *
> + * Returns pointer to appropriate dma channel on success or NULL on error.
> + */
> +struct dma_chan *of_dma_xlate_by_chan_id(struct of_phandle_args *dma_spec,
> + struct of_dma *ofdma)
> +{
> + struct dma_device *dev = ofdma->of_dma_data;
> + struct dma_chan *chan, *candidate = NULL;
> +
> + if (!dev || dma_spec->args_count != 1)
> + return NULL;
> +
> + list_for_each_entry(chan, &dev->channels, device_node)
> + if (chan->chan_id == dma_spec->args[0]) {
> + candidate = chan;
> + break;
> + }
> +
> + if (!candidate)
> + return NULL;
> +
> + return dma_get_slave_channel(candidate);
> +}
> +EXPORT_SYMBOL_GPL(of_dma_xlate_by_chan_id);
> diff --git a/include/linux/of_dma.h b/include/linux/of_dma.h
> index ae36298..56bc026 100644
> --- a/include/linux/of_dma.h
> +++ b/include/linux/of_dma.h
> @@ -41,6 +41,8 @@ extern struct dma_chan *of_dma_request_slave_channel(struct device_node *np,
> const char *name);
> extern struct dma_chan *of_dma_simple_xlate(struct of_phandle_args *dma_spec,
> struct of_dma *ofdma);
> +extern struct dma_chan *of_dma_xlate_by_chan_id(struct of_phandle_args *dma_spec,
> + struct of_dma *ofdma);
> #else
> static inline int of_dma_controller_register(struct device_node *np,
> struct dma_chan *(*of_dma_xlate)
> @@ -66,6 +68,8 @@ static inline struct dma_chan *of_dma_simple_xlate(struct of_phandle_args *dma_s
> return NULL;
> }
>
> +#define of_dma_xlate_by_chan_id NULL
> +
> #endif
>
> #endif /* __LINUX_OF_DMA_H */
> --
> 1.8.4.2
>
--
^ permalink raw reply
* Re: [PATCH RFC v12 1/7] dma: mpc512x: reorder mpc8308 specific instructions
From: Vinod Koul @ 2014-05-02 17:06 UTC (permalink / raw)
To: Alexander Popov
Cc: Lars-Peter Clausen, Arnd Bergmann, Gerhard Sittig,
Andy Shevchenko, dmaengine, Dan Williams, Anatolij Gustschin,
linuxppc-dev
In-Reply-To: <1398261209-5578-2-git-send-email-a13xp0p0v88@gmail.com>
On Wed, Apr 23, 2014 at 05:53:23PM +0400, Alexander Popov wrote:
> Concentrate the specific code for MPC8308 in the 'if' branch
> and handle MPC512x in the 'else' branch.
> This modification only reorders instructions but doesn't change behaviour.
>
> Signed-off-by: Alexander Popov <a13xp0p0v88@gmail.com>
> Acked-by: Anatolij Gustschin <agust@denx.de>
Applied, thanks
--
~Vinod
^ permalink raw reply
* Re: [PATCH RFC v12 2/7] dma: mpc512x: separate 'compatible' values for MPC512x and MPC8308
From: Vinod Koul @ 2014-05-02 17:07 UTC (permalink / raw)
To: Alexander Popov
Cc: devicetree, Lars-Peter Clausen, Arnd Bergmann, Gerhard Sittig,
Andy Shevchenko, dmaengine, Dan Williams, Anatolij Gustschin,
linuxppc-dev
In-Reply-To: <1398261209-5578-3-git-send-email-a13xp0p0v88@gmail.com>
On Wed, Apr 23, 2014 at 05:53:24PM +0400, Alexander Popov wrote:
> MPC512x and MPC8308 have similar DMA controllers, but are independent SoCs.
> DMA controller driver should have separate 'compatible' values for these SoCs.
>
> Signed-off-by: Alexander Popov <a13xp0p0v88@gmail.com>
Applied, thanks
--
~Vinod
^ permalink raw reply
* Re: [PATCH RFC v12 4/7] dma: mpc512x: fix freeing resources in mpc_dma_probe() and mpc_dma_remove()
From: Vinod Koul @ 2014-05-02 17:07 UTC (permalink / raw)
To: Alexander Popov
Cc: Lars-Peter Clausen, Arnd Bergmann, Gerhard Sittig,
Andy Shevchenko, dmaengine, Dan Williams, Anatolij Gustschin,
linuxppc-dev
In-Reply-To: <1398261209-5578-5-git-send-email-a13xp0p0v88@gmail.com>
On Wed, Apr 23, 2014 at 05:53:26PM +0400, Alexander Popov wrote:
> Fix mpc_dma_probe() error path and mpc_dma_remove(): manually free IRQs and
> dispose IRQ mappings before devm_* takes care of other resources.
> Moreover replace devm_request_irq() with request_irq() since there is no need
> to use it because the original code always frees IRQ manually with
> devm_free_irq(). Replace devm_free_irq() with free_irq() accordingly.
Applied, thanks
--
~Vinod
^ permalink raw reply
* Re: [PATCH 1/1] powerpc: crtsaveres.o needed only when -Os flag is enabled
From: Ram Pai @ 2014-05-02 17:47 UTC (permalink / raw)
To: Aneesh Kumar K.V; +Cc: hartb, paulus, anton, tony, linuxppc-dev
In-Reply-To: <87wqe4age2.fsf@linux.vnet.ibm.com>
On Fri, May 02, 2014 at 11:09:17AM +0530, Aneesh Kumar K.V wrote:
> Ram Pai <linuxram@us.ibm.com> writes:
>
> > powerpc: crtsaveres.o needed only when -Os flag is enabled
> >
> > Currently on powerpc arch, out-of-tree module fails to build without
> > crtsaveres.o, even when the module has no dependency on the symbols
> > provided by the file; when built without the -Os flag.
> >
> > BTW: '-Os' flag is enabled when CONFIG_CC_OPTIMIZE_FOR_SIZE is
> > configured.
> >
> > This patch fixes that problem.
> >
> > Signed-off-by: Ram Pai <linuxram@us.ibm.com>
> >
> > diff --git a/arch/powerpc/Makefile b/arch/powerpc/Makefile
> > index 4c0cedf..cf12f38 100644
> > --- a/arch/powerpc/Makefile
> > +++ b/arch/powerpc/Makefile
> > @@ -157,7 +157,10 @@ CPP = $(CC) -E $(KBUILD_CFLAGS)
> >
> > CHECKFLAGS += -m$(CONFIG_WORD_SIZE) -D__powerpc__ -D__powerpc$(CONFIG_WORD_SIZE)__
> >
> > +ifdef CONFIG_CC_OPTIMIZE_FOR_SIZE
> > KBUILD_LDFLAGS_MODULE += arch/powerpc/lib/crtsavres.o
> > +endif
> > +
> >
> > # No AltiVec or VSX instructions when building kernel
> > KBUILD_CFLAGS += $(call cc-option,-mno-altivec)
> >
>
> So if we enable CONFIG_CC_OPTIMIZE_FOR_SIZE can we build out-of-tree
> module with this patch ?
Yes, provided crtsaveres.o is available.
If crtsaveres.o is not available; some distro dont ship it, than
out-of-tree module linking will fail.
Some distro don't ship crtsaveres.o since they do not want
kernel and modules to be built with space optimization. In such cases
requiring crtsaveres.o to be available during module building, even
when the module is not built for space optimization is wrong.
This patch fixes that issue.
RP
^ permalink raw reply
* RE: [PATCH v2 1/4] KVM: PPC: e500mc: Revert "add load inst fixup"
From: mihai.caraman @ 2014-05-02 23:14 UTC (permalink / raw)
To: Alexander Graf
Cc: linuxppc-dev@lists.ozlabs.org, kvm@vger.kernel.org,
kvm-ppc@vger.kernel.org
In-Reply-To: <53636436.60002@suse.de>
> From: Alexander Graf <agraf@suse.de>=0A=
> Sent: Friday, May 2, 2014 12:24 PM=0A=
> To: Caraman Mihai Claudiu-B02008=0A=
> Cc: kvm-ppc@vger.kernel.org; kvm@vger.kernel.org; linuxppc-dev@lists.ozla=
bs.org=0A=
> Subject: Re: [PATCH v2 1/4] KVM: PPC: e500mc: Revert "add load inst fixup=
"=0A=
> =0A=
> On 05/01/2014 02:45 AM, Mihai Caraman wrote:=0A=
> > The commit 1d628af7 "add load inst fixup" made an attempt to handle=0A=
> > failures generated by reading the guest current instruction. The fixup=
=0A=
> > code that was added works by chance hiding the real issue.=0A=
> >=0A=
> > Load external pid (lwepx) instruction, used by KVM to read guest=0A=
> > instructions, is executed in a subsituted guest translation context=0A=
> > (EPLC[EGS] =3D 1). In consequence lwepx's TLB error and data storage=0A=
> > interrupts need to be handled by KVM, even though these interrupts=0A=
> > are generated from host context (MSR[GS] =3D 0).=0A=
> >=0A=
> > Currently, KVM hooks only interrupts generated from guest context=0A=
> > (MSR[GS] =3D 1), doing minimal checks on the fast path to avoid host=0A=
> > performance degradation. As a result, the host kernel handles lwepx=0A=
> > faults searching the faulting guest data address (loaded in DEAR) in=0A=
> > its own Logical Partition ID (LPID) 0 context. In case a host translati=
on=0A=
> > is found the execution returns to the lwepx instruction instead of the=
=0A=
> > fixup, the host ending up in an infinite loop.=0A=
> >=0A=
> > Revert the commit "add load inst fixup". lwepx issue will be addressed=
=0A=
> > in a subsequent patch without needing fixup code.=0A=
> >=0A=
> > Signed-off-by: Mihai Caraman <mihai.caraman@freescale.com>=0A=
> =0A=
> Just a random idea: Could we just switch IVOR2 during the critical lwepx=
=0A=
> phase? In fact, we could even do that later when we're already in C code=
=0A=
> and try to recover the last instruction. The code IVOR2 would point to=0A=
> would simply set the register we're trying to read to as LAST_INST_FAIL=
=0A=
> and rfi.=0A=
=0A=
This was the first idea that sprang to my mind inspired from how DO_KVM=0A=
is hooked on PR. I actually did a simple POC for e500mc/e5500, but this wil=
l=0A=
not work on e6500 which has shared IVORs between HW threads.=0A=
=0A=
-Mike=
^ permalink raw reply
* Re: powerpc/mpc85xx: Remove P1023 RDS support
From: Scott Wood @ 2014-05-03 0:13 UTC (permalink / raw)
To: Lijun Pan; +Cc: linuxppc-dev, Emilian.Medve
In-Reply-To: <1397841480-2652-1-git-send-email-Lijun.Pan@freescale.com>
On Fri, Apr 18, 2014 at 12:18:00PM -0500, Lijun Pan wrote:
> P1023RDS is no longer supported by Freescale while P1023RDB is still supported.
Please wrap changelogs at no more than 75 columns.
> Signed-off-by: Lijun Pan <Lijun.Pan@freescale.com>
>
> ---
> arch/powerpc/boot/dts/p1023rds.dts | 219 ---------------------
> arch/powerpc/configs/mpc85xx_defconfig | 1 -
> arch/powerpc/configs/mpc85xx_smp_defconfig | 1 -
> arch/powerpc/platforms/85xx/Kconfig | 6 +-
> arch/powerpc/platforms/85xx/Makefile | 2 +-
> .../platforms/85xx/{p1023_rds.c => p1023_rdb.c} | 36 +---
> 6 files changed, 10 insertions(+), 255 deletions(-)
> delete mode 100644 arch/powerpc/boot/dts/p1023rds.dts
> rename arch/powerpc/platforms/85xx/{p1023_rds.c => p1023_rdb.c} (75%)
As discussed internally, I'd like to see more of an explanation for why
it should be removed upstream -- what sort of maintenance burden it's
causing, or why this board should be considered of so little interest to
users that we should remove it regardless of current maintenance burden.
-Scott
^ permalink raw reply
* Re: powerpc/mpc85xx: Add BSC9132 QDS Support
From: Scott Wood @ 2014-05-03 0:23 UTC (permalink / raw)
To: harninder rai; +Cc: linuxppc-dev, Ruchika Gupta
In-Reply-To: <1395128102-12983-1-git-send-email-harninder.rai@freescale.com>
On Tue, Mar 18, 2014 at 01:05:02PM +0530, harninder rai wrote:
> +&ifc {
> + nor@0,0 {
> + #address-cells = <1>;
> + #size-cells = <1>;
> + compatible = "cfi-flash";
> + reg = <0x0 0x0 0x8000000>;
> + bank-width = <2>;
> + device-width = <1>;
> +
> + partition@40000 {
> + /* 256KB for DTB Image */
> + reg = <0x00040000 0x00040000>;
> + label = "NOR DTB Image";
> + };
> +
> + partition@80000 {
> + /* 7MB for Linux Kernel Image */
> + reg = <0x00080000 0x00700000>;
> + label = "NAND Linux Kernel Image";
> + };
> +
> + partition@800000 {
> + /* 55MB for Root file system */
> + reg = <0x00800000 0x03700000>;
> + label = "NOR RFS Image";
> + };
> +
> + partition@3f00000 {
> + /* This location must not be altered */
> + /* 512KB for u-boot Bootloader Image */
> + /* 512KB for u-boot Environment Variables */
> + reg = <0x03f00000 0x00100000>;
> + label = "NOR U-boot Image";
> + read-only;
> + };
> + };
> +
> + nand@1,0 {
> + #address-cells = <1>;
> + #size-cells = <1>;
> + compatible = "fsl,ifc-nand";
> + reg = <0x1 0x0 0x4000>;
> +
> + partition@0 {
> + /* This location must not be altered */
> + /* 3MB for u-boot Bootloader Image */
> + reg = <0x0 0x00300000>;
> + label = "NAND U-Boot Image";
> + read-only;
> + };
> +
> + partition@300000 {
> + /* 1MB for DTB Image */
> + reg = <0x00300000 0x00100000>;
> + label = "NAND DTB Image";
> + };
> +
> + partition@400000 {
> + /* 8MB for Linux Kernel Image */
> + reg = <0x00400000 0x00800000>;
> + label = "NAND Linux Kernel Image";
> + };
> +
> + partition@c00000 {
> + /* Rest space for Root file System Image */
> + reg = <0x00c00000 0x07400000>;
> + label = "NAND RFS Image";
> + };
> + };
> +};
Please keep partition definitions out of the dts file, as has been
recently requested of other boards. You can use U-Boot to create the
partition nodes based on the mtdparts variable, or you can use the Linux
mtdparts command line option.
-Scott
^ permalink raw reply
* Re: powerpc/mpc85xx: Add BSC9132 QDS Support
From: Scott Wood @ 2014-05-03 0:31 UTC (permalink / raw)
To: harninder rai; +Cc: linuxppc-dev, Ruchika Gupta
In-Reply-To: <1395128102-12983-1-git-send-email-harninder.rai@freescale.com>
On Tue, Mar 18, 2014 at 01:05:02PM +0530, harninder rai wrote:
> +&ifc {
> + #address-cells = <2>;
> + #size-cells = <1>;
> + compatible = "fsl,ifc", "simple-bus";
> + /* FIXME: Test whether interrupts are split */
> + interrupts = <16 2 0 0 20 2 0 0>;
> +};
Have you done this test yet?
-Scott
^ permalink raw reply
* Re: powerpc/mpc85xx: Remove P1023 RDS support
From: Emil Medve @ 2014-05-03 6:44 UTC (permalink / raw)
To: Scott Wood, Lijun Pan; +Cc: linuxppc-dev
In-Reply-To: <20140503001318.GA19925@home.buserror.net>
Hello Scott,
On 05/02/2014 07:13 PM, Scott Wood wrote:
> On Fri, Apr 18, 2014 at 12:18:00PM -0500, Lijun Pan wrote:
>> P1023RDS is no longer supported by Freescale while P1023RDB is still supported.
>
> Please wrap changelogs at no more than 75 columns.
>
>> Signed-off-by: Lijun Pan <Lijun.Pan@freescale.com>
>>
>> ---
>> arch/powerpc/boot/dts/p1023rds.dts | 219 ---------------------
>> arch/powerpc/configs/mpc85xx_defconfig | 1 -
>> arch/powerpc/configs/mpc85xx_smp_defconfig | 1 -
>> arch/powerpc/platforms/85xx/Kconfig | 6 +-
>> arch/powerpc/platforms/85xx/Makefile | 2 +-
>> .../platforms/85xx/{p1023_rds.c => p1023_rdb.c} | 36 +---
>> 6 files changed, 10 insertions(+), 255 deletions(-)
>> delete mode 100644 arch/powerpc/boot/dts/p1023rds.dts
>> rename arch/powerpc/platforms/85xx/{p1023_rds.c => p1023_rdb.c} (75%)
>
> As discussed internally, I'd like to see more of an explanation for why
> it should be removed upstream -- what sort of maintenance burden it's
> causing, or why this board should be considered of so little interest to
> users that we should remove it regardless of current maintenance burden.
When discussed internally I believe we addressed these points but I
guess not to your satisfaction. I suspect you're not asking for a replay
so I'm trying to get actual numbers of boards sold hoping that would
make the conversation a bit more objective
Cheers,
^ permalink raw reply
* Re: [PATCH 4/6] powerpc/corenet: Create the dts components for the DPAA FMan
From: Emil Medve @ 2014-05-03 10:02 UTC (permalink / raw)
To: Scott Wood, Shruti Kanetkar, devicetree,
linuxppc-dev@lists.ozlabs.org
In-Reply-To: <1398118262.1694.188.camel__8135.6513932862$1398128944$gmane$org@snotra.buserror.net>
Hello Scott,
On 04/21/2014 05:11 PM, Scott Wood wrote:
> On Fri, 2014-04-18 at 07:21 -0500, Shruti Kanetkar wrote:
>> +fman@400000 {
>> + mdio@f1000 {
>> + #address-cells = <1>;
>> + #size-cells = <0>;
>> + compatible = "fsl,fman-xmdio";
>> + reg = <0xf1000 0x1000>;
>> + };
>> +};
>
> I'd like to see a complete fman binding before we start adding pieces.
The driver for the FMan 10 Gb/s MDIO has upstreamed a couple of years
ago: '9f35a73 net/fsl: introduce Freescale 10G MDIO driver', granted
without a binding writeup. This patch series should probably include a
binding blurb. However, let's not gate this patchset on a complete
binding for the FMan
As you know we don't own the FMan work and the FMan work is... not ready
for upstreaming. In an attempt to make some sort of progress we've
decided to upstream the pieces that are less controversial and MDIO is
an obvious candidate
>> +fman@400000 {
>> + mdio0: mdio@e1120 {
>> + #address-cells = <1>;
>> + #size-cells = <0>;
>> + compatible = "fsl,fman-mdio";
>> + reg = <0xe1120 0xee0>;
>> + };
>> +};
>
> What is the difference between "fsl,fman-mdio" and "fsl,fman-xmdio"? I
> don't see the latter on the list of compatibles in patch 3/6.
'fsl,fman-mdio' is the 1 Gb/s MDIO (Clause 22 only). 'fsl,fman-xmdio' is
the 10 Gb/s MDIO (Clause 45 only). We can respin this patch wi
I believe 'fsl,fman-mdio' (and others on that list) was added
gratuitously as the FMan MDIO is completely compatible with the
eTSEC/gianfar MDIO driver, but we can deal with that later
> Within each category, is the exact fman version discoverable from the
> mdio registers?
No, but that's irrelevant as that's not the difference between the two
compatibles
>> diff --git a/arch/powerpc/boot/dts/fsl/qoriq-fman3-1.dtsi b/arch/powerpc/boot/dts/fsl/qoriq-fman3-1.dtsi
>> new file mode 100644
>> index 0000000..ced5786
>> --- /dev/null
>> +++ b/arch/powerpc/boot/dts/fsl/qoriq-fman3-1.dtsi
>> @@ -0,0 +1,52 @@
>> +/*
>> + * QorIQ FMan v3 device tree stub [ controller @ offset 0x500000 ]
>> + *
>> + * 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.
>> +*/
>> +
>> +fman@500000 {
>> + #address-cells = <1>;
>> + #size-cells = <1>;
>> + compatible = "simple-bus";
>
> Why is this simple-bus?
Because that's the translation type for the FMan sub-nodes. We need it
now to get the MDIO nodes probed and we'll needed later to probe other
nodes/devices that will have standalone drivers: MAC, MURAM. etc. I
don't think we need to add another entry into the platform probe list
(which is already quite long) as a simple synonym
>> +
>> + /* mdio nodes for fman v3 @ 0x500000 */
>> + mdio@fc000 {
>> + #address-cells = <1>;
>> + #size-cells = <0>;
>> + reg = <0xfc000 0x1000>;
>> + };
>> +
>> + mdio@fd000 {
>> + #address-cells = <1>;
>> + #size-cells = <0>;
>> + reg = <0xfd000 0x1000>;
>> + };
>> +};
>
> Where's the compatible? Why is this file different from all the others?
The FMan v3 MDIO block (supports both Clause 22/45) is compatible with
the FMan v2 10 Gb/s MDIO (the xgmac-mdio driver). However, the driver
needs a small clean-up patch (still in internal review) that will get it
working for FMan v3 MDIO. With that patch will add the compatible to
these nodes. However, we need these nodes now for the board level MDIO
bus muxing support (included in this patchset)
Cheers,
^ permalink raw reply
* RE: MPC8641 based custom board Kernel stuck at 1000Mhz core clock
From: curieux.khetan @ 2014-05-03 16:40 UTC (permalink / raw)
To: sanjeev sharma
Cc: scottwood@freescale.com, linuxppc-dev@lists.ozlabs.org,
Valdis Kletnieks, kernelnewbies
[-- Attachment #1: Type: text/plain, Size: 6685 bytes --]
hi thanks for your reply. the problem is still there. At 800MHZ core its working fine but for 1Ghz its still happening.
Any suggestion or check point I can monitor.
From: sanjeev sharma
Sent: 02 May 2014 09:22
To: Ashish
CC: Valdis Kletnieks; scottwood@freescale.com; linuxppc-dev@lists.ozlabs.org; kernelnewbies
Subject: Re: MPC8641 based custom board Kernel stuck at 1000Mhz core clock
Hello Ashish,
is this issue resolved and is this always happening when you are changing core to 1Ghz because i am confused here with sometime Keyword.
Regards
Sanjeev Sharma
On Fri, Apr 4, 2014 at 1:12 PM, Ashish <curieux.khetan@gmail.com> wrote:
On Thursday 03 April 2014 08:55 AM, sanjeev sharma wrote:
Are you able to capture kernel logs ?
Regards
Sanjeev Sharma
On Thu, Mar 27, 2014 at 10:01 PM, <Valdis.Kletnieks@vt.edu> wrote:
On Thu, 27 Mar 2014 16:04:37 +0530, Ashish said:
> Hi,
>
> I am using MPC8641-HPCN based custom board and able to boot linux at
> MPX clock 400Mhz and core clock 800mhz. When I am increasing core
> frequency ie MPX clock at 400Mhz and core at 1Ghz, kernel stuck.
Step 0: Prove to us that your core actually runs reliable and stably at 1Ghz.
Step 1: Figure out *where* it gets stuck. If you have earlyprintk working on
your board, adding 'initcall_debug ignore_loglevel' to the kernel cmdline often
helps track down where a kernel hangs during boot.
_______________________________________________
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Hi,
Does kernel logs means debugging information that kernel prints while booting using printk or it is something else?
Here is kernel boot logs that kernel printed while booting...
U-Boot 2013.04 (Jan 27 2014 - 11:21:21)
Unicore software on multiprocessor system!!
To enable mutlticore build define CONFIG_MP
CPU: 8641, Version: 2.1, (0x80900021)
Core: E600 Core 0, Version: 2.2, (0x80040202)
Clock Configuration:
CPU:1000 MHz, MPX:400 MHz
DDR:200 MHz (400 MT/s data rate), LBC:25 MHz
L1: D-cache 32 KB enabled
I-cache 32 KB enabled
L2: 512 KB enabled
Board: MPC8641-HPCN
I2C: ready
DRAM: 512 MiB
SDRAM test phase 1:
SDRAM test phase 2:
SDRAM test passed.
Flash: 16 MiB
EEPROM: NXID v1
In: serial
Out: serial
Err: serial
Net: eTSEC1, eTSEC2, eTSEC3, eTSEC4 [PRIME]
Hit any key to stop autoboot:
Speed: 1000, full duplex
Using eTSEC4 device
TFTP from server 192.168.10.1; our IP address is 192.168.10.2
Filename 'uRamdisk'.
Load address: 0x600000
Loading: * #################################################################
#################################################################
#################################################################
#################################################################
#################################################################
#################################################################
#################################################################
#################################################################
#################################################################
#################################################################
#################################################################
#################################################################
#################################################################
#################################################################
#################################################################
#################################################################
#################################################################
#################################################################
#################################################################
#################################################################
#################################################################
#################################################################
#################################################################
##################################################
13.1 MiB/s
done
Bytes transferred = 22680188 (15a127c hex)
Speed: 1000, full duplex
Using eTSEC4 device
TFTP from server 192.168.10.1; our IP address is 192.168.10.2
Filename 'uImage'.
Load address: 0x16000000
Loading: * #################################################################
#################################################################
#######################################
14 MiB/s
done
Bytes transferred = 2476304 (25c910 hex)
Speed: 1000, full duplex
Using eTSEC4 device
TFTP from server 192.168.10.1; our IP address is 192.168.10.2
Filename 'mpc8641_hpcn.dtb'.
Load address: 0x14000000
Loading: * #
2.6 MiB/s
done
Bytes transferred = 5540 (15a4 hex)
## Booting kernel from Legacy Image at 16000000 ...
Image Name: Linux-3.13.6
Image Type: PowerPC Linux Kernel Image (gzip compressed)
Data Size: 2476240 Bytes = 2.4 MiB
Load Address: 00000000
Entry Point: 00000000
Verifying Checksum ... OK
## Loading init Ramdisk from Legacy Image at 00600000 ...
Image Name: rootfs
Image Type: PowerPC Linux RAMDisk Image (gzip compressed)
Data Size: 22680124 Bytes = 21.6 MiB
Load Address: 00000000
Entry Point: 00000000
Verifying Checksum ... OK
## Flattened Device Tree blob at 14000000
Booting using the fdt blob at 0x14000000
Uncompressing Kernel Image ... OK
Loading Ramdisk to 1e923000, end 1fec423c ... OK
Loading Device Tree to 007fb000, end 007ff5a3 ... OK (some times it stucking here)
Using MPC86xx HPCN machine description
Total memory = 512MB; using 1024kB for hash table (at cff00000)
Linux version 3.13.6 (ashish@ashish-VirtualBox) (gcc version 4.7.2 (GCC) ) #8 Sat Mar 29 10:31:58 IST 2014
Found initrd at 0xde923000:0xdfec423c
bootconsole [udbg0] enabled
setup_arch: bootmem
mpc86xx_hpcn_setup_arch()
MPC86xx HPCN board from Freescale Semiconductor
arch: exit
Zone ranges:
DMA [mem 0x00000000-0x1fffffff]
Normal empty
HighMem empty
Movable zone start for each node
Early memory node ranges
node 0: [mem 0x00000000-0x1fffffff] (some times here)
[-- Attachment #2: Type: text/html, Size: 10983 bytes --]
^ permalink raw reply
* Re: [PATCH v2 1/4] KVM: PPC: e500mc: Revert "add load inst fixup"
From: Alexander Graf @ 2014-05-03 22:14 UTC (permalink / raw)
To: mihai.caraman@freescale.com
Cc: linuxppc-dev@lists.ozlabs.org, kvm@vger.kernel.org,
kvm-ppc@vger.kernel.org
In-Reply-To: <1399072472827.57968@freescale.com>
Am 03.05.2014 um 01:14 schrieb "mihai.caraman@freescale.com" <mihai.caraman@=
freescale.com>:
>> From: Alexander Graf <agraf@suse.de>
>> Sent: Friday, May 2, 2014 12:24 PM
>> To: Caraman Mihai Claudiu-B02008
>> Cc: kvm-ppc@vger.kernel.org; kvm@vger.kernel.org; linuxppc-dev@lists.ozla=
bs.org
>> Subject: Re: [PATCH v2 1/4] KVM: PPC: e500mc: Revert "add load inst fixup=
"
>>=20
>>> On 05/01/2014 02:45 AM, Mihai Caraman wrote:
>>> The commit 1d628af7 "add load inst fixup" made an attempt to handle
>>> failures generated by reading the guest current instruction. The fixup
>>> code that was added works by chance hiding the real issue.
>>>=20
>>> Load external pid (lwepx) instruction, used by KVM to read guest
>>> instructions, is executed in a subsituted guest translation context
>>> (EPLC[EGS] =3D 1). In consequence lwepx's TLB error and data storage
>>> interrupts need to be handled by KVM, even though these interrupts
>>> are generated from host context (MSR[GS] =3D 0).
>>>=20
>>> Currently, KVM hooks only interrupts generated from guest context
>>> (MSR[GS] =3D 1), doing minimal checks on the fast path to avoid host
>>> performance degradation. As a result, the host kernel handles lwepx
>>> faults searching the faulting guest data address (loaded in DEAR) in
>>> its own Logical Partition ID (LPID) 0 context. In case a host translatio=
n
>>> is found the execution returns to the lwepx instruction instead of the
>>> fixup, the host ending up in an infinite loop.
>>>=20
>>> Revert the commit "add load inst fixup". lwepx issue will be addressed
>>> in a subsequent patch without needing fixup code.
>>>=20
>>> Signed-off-by: Mihai Caraman <mihai.caraman@freescale.com>
>>=20
>> Just a random idea: Could we just switch IVOR2 during the critical lwepx
>> phase? In fact, we could even do that later when we're already in C code
>> and try to recover the last instruction. The code IVOR2 would point to
>> would simply set the register we're trying to read to as LAST_INST_FAIL
>> and rfi.
>=20
> This was the first idea that sprang to my mind inspired from how DO_KVM
> is hooked on PR. I actually did a simple POC for e500mc/e5500, but this wi=
ll
> not work on e6500 which has shared IVORs between HW threads.
What if we combine the ideas? On read we flip the IVOR to a separate handler=
that checks for a field in the PACA. Only if that field is set, we treat th=
e fault as kvm fault, otherwise we jump into the normal handler.
I suppose we'd have to also take a lock to make sure we don't race with the o=
ther thread when it wants to also read a guest instruction, but you get the i=
dea.
I have no idea whether this would be any faster, it's more of a brainstormin=
g thing really. But regardless this patch set would be a move into the right=
direction.
Btw, do we have any guarantees that we don't get scheduled away before we ru=
n kvmppc_get_last_inst()? If we run on a different core we can't read the in=
st anymore. Hrm.
Alex
^ permalink raw reply
* Re: [PATCH 00/13] Refactor pci_is_brdige() to simplify code
From: Yijing Wang @ 2014-05-04 4:16 UTC (permalink / raw)
To: Bjorn Helgaas
Cc: Tony Luck, linux-ia64@vger.kernel.org, x86@kernel.org,
linux-kernel@vger.kernel.org, sparclinux, Thomas Gleixner,
linuxppc-dev, David S. Miller
In-Reply-To: <CAErSpo4fa=fmajhxGA7PRm42S1fS2wV_7w+EWaVh_qiawRAQxA@mail.gmail.com>
> This needs to be posted to the linux-pci list. The fact that it
> wasn't means it's not in patchwork, so it's not on my to-do list.
>
> Currently we have one interface: pci_is_bridge().
>
> After your series, we would have two interfaces: pci_is_bridge() and
> pci_has_subordinate(). Presumably, both are used, and you should
> explain how you decided which to use at each place.
>
> I assume the difference is that the old pci_is_bridge() is true for a
> bridge that has a subordinate bus. The new pci_is_bridge() is true
> for any bridge, even if there is no subordinate bus. When do we even
> have a bridge with no subordinate bus? This is the sort of stuff you
> need to explain so we know why we should apply these patches.
>
Hi Bjorn, sorry forgot to cc pci list, will resend the v2 patchset with
some new description for new pci_is_bridge().
>
>> Yijing Wang (13):
>> PCI: rename pci_is_bridge() to pci_has_subordinate()
>> PCI: Introduce new pci_is_bridge() helper function
>> PCI: Use new pci_is_bridge() to simplify code
>> x86/PCI: Use new pci_is_bridge() to simplify code
>> IA64/PCI: Use new pci_is_bridge() to simplify code
>> powerpc/PCI: Use new pci_is_bridge() to simplify code
>> sparc/PCI: Use new pci_is_bridge() to simplify code
>> PCI, rpaphp: Use new pci_is_bridge() to simplify code
>> PCI, shpchp: Use new pci_is_bridge() to simplify code
>> PCI, cpcihp: Use new pci_is_bridge() to simplify code
>> PCI, acpiphp: Use new pci_is_bridge() to simplify code
>> PCI, pcmcia: Use new pci_is_bridge() to simplify code
>> PCI, pciehp: Use new pci_is_bridge() to simplify code
>>
>> arch/ia64/pci/fixup.c | 4 +---
>> arch/powerpc/kernel/pci-hotplug.c | 3 +--
>> arch/powerpc/kernel/pci_of_scan.c | 3 +--
>> arch/sparc/kernel/pci.c | 3 +--
>> arch/x86/pci/fixup.c | 4 +---
>> drivers/pci/hotplug/acpiphp_glue.c | 3 +--
>> drivers/pci/hotplug/cpci_hotplug_pci.c | 3 +--
>> drivers/pci/hotplug/pciehp_pci.c | 3 +--
>> drivers/pci/hotplug/rpadlpar_core.c | 3 +--
>> drivers/pci/hotplug/shpchp_pci.c | 3 +--
>> drivers/pci/pci-acpi.c | 8 +-------
>> drivers/pci/pci-driver.c | 8 ++++----
>> drivers/pci/pci.h | 2 +-
>> drivers/pci/probe.c | 3 +--
>> drivers/pci/setup-bus.c | 4 +---
>> drivers/pcmcia/cardbus.c | 3 +--
>> include/linux/pci.h | 6 ++++++
>> 17 files changed, 25 insertions(+), 41 deletions(-)
>>
>>
>
> .
>
--
Thanks!
Yijing
^ permalink raw reply
* [PATCH v2 01/13] PCI: rename pci_is_bridge() to pci_has_subordinate()
From: Yijing Wang @ 2014-05-04 4:23 UTC (permalink / raw)
To: Bjorn Helgaas
Cc: Tony Luck, linux-ia64, x86, Yijing Wang, linux-pci, sparclinux,
Thomas Gleixner, linuxppc-dev, David S. Miller
In-Reply-To: <1399177428-3784-1-git-send-email-wangyijing@huawei.com>
pci_is_bridge() which seems to determine whether device is a bridge,
returns true only when the subordinate bus exists. This confuses
people. PCI device is a bridge means its header type(bit 0 through 6)
is 0x1(PCI bridge) or 0x2(CardBus bridge). Rename the current
pci_is_bridge() helper function to pci_has_subordinate().
Signed-off-by: Yijing Wang <wangyijing@huawei.com>
---
drivers/pci/pci-driver.c | 8 ++++----
drivers/pci/pci.h | 2 +-
2 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/pci/pci-driver.c b/drivers/pci/pci-driver.c
index d911e0c..b7850cb 100644
--- a/drivers/pci/pci-driver.c
+++ b/drivers/pci/pci-driver.c
@@ -580,14 +580,14 @@ static void pci_pm_default_resume(struct pci_dev *pci_dev)
{
pci_fixup_device(pci_fixup_resume, pci_dev);
- if (!pci_is_bridge(pci_dev))
+ if (!pci_has_subordinate(pci_dev))
pci_enable_wake(pci_dev, PCI_D0, false);
}
static void pci_pm_default_suspend(struct pci_dev *pci_dev)
{
/* Disable non-bridge devices without PM support */
- if (!pci_is_bridge(pci_dev))
+ if (!pci_has_subordinate(pci_dev))
pci_disable_enabled_device(pci_dev);
}
@@ -717,7 +717,7 @@ static int pci_pm_suspend_noirq(struct device *dev)
if (!pci_dev->state_saved) {
pci_save_state(pci_dev);
- if (!pci_is_bridge(pci_dev))
+ if (!pci_has_subordinate(pci_dev))
pci_prepare_to_sleep(pci_dev);
}
@@ -971,7 +971,7 @@ static int pci_pm_poweroff_noirq(struct device *dev)
return error;
}
- if (!pci_dev->state_saved && !pci_is_bridge(pci_dev))
+ if (!pci_dev->state_saved && !pci_has_subordinate(pci_dev))
pci_prepare_to_sleep(pci_dev);
/*
diff --git a/drivers/pci/pci.h b/drivers/pci/pci.h
index 6bd0822..65108fc 100644
--- a/drivers/pci/pci.h
+++ b/drivers/pci/pci.h
@@ -77,7 +77,7 @@ static inline void pci_wakeup_event(struct pci_dev *dev)
pm_wakeup_event(&dev->dev, 100);
}
-static inline bool pci_is_bridge(struct pci_dev *pci_dev)
+static inline bool pci_has_subordinate(struct pci_dev *pci_dev)
{
return !!(pci_dev->subordinate);
}
--
1.7.1
^ permalink raw reply related
* [PATCH v2 08/13] PCI, rpaphp: Use new pci_is_bridge() to simplify code
From: Yijing Wang @ 2014-05-04 4:23 UTC (permalink / raw)
To: Bjorn Helgaas
Cc: Tony Luck, linux-ia64, x86, Yijing Wang, linux-pci, sparclinux,
Thomas Gleixner, linuxppc-dev, David S. Miller
In-Reply-To: <1399177428-3784-1-git-send-email-wangyijing@huawei.com>
Now we can use new pci_is_bridge() helper function
to simplify code.
Acked-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Yijing Wang <wangyijing@huawei.com>
---
drivers/pci/hotplug/rpadlpar_core.c | 3 +--
1 files changed, 1 insertions(+), 2 deletions(-)
diff --git a/drivers/pci/hotplug/rpadlpar_core.c b/drivers/pci/hotplug/rpadlpar_core.c
index 4fcdeed..7660232 100644
--- a/drivers/pci/hotplug/rpadlpar_core.c
+++ b/drivers/pci/hotplug/rpadlpar_core.c
@@ -157,8 +157,7 @@ static void dlpar_pci_add_bus(struct device_node *dn)
}
/* Scan below the new bridge */
- if (dev->hdr_type == PCI_HEADER_TYPE_BRIDGE ||
- dev->hdr_type == PCI_HEADER_TYPE_CARDBUS)
+ if (pci_is_bridge(dev))
of_scan_pci_bridge(dev);
/* Map IO space for child bus, which may or may not succeed */
--
1.7.1
^ permalink raw reply related
* [PATCH v2 00/13] Refactor pci_is_brdige() to simplify code
From: Yijing Wang @ 2014-05-04 4:23 UTC (permalink / raw)
To: Bjorn Helgaas
Cc: Tony Luck, linux-ia64, x86, Yijing Wang, linux-pci, sparclinux,
Thomas Gleixner, linuxppc-dev, David S. Miller
v1->v2: Add comments for new pci_is_bridge().
This patchset rename the current pci_is_bridge() to pci_has_subordinate(),
and introduce a new pci_is_bridge() which determine pci bridge by check
dev->hdr_type. The new one is more accurate. PCI Spec define the pci
device is a bridge by the dev->hdr_type = 0x01 || 0x02.
There is no guarantee that a PCI bridge must attached a subordinate bus.
When PCI bridge is created but before the scan child bus, it has no
subordinate bus. Also users can remove the pci bus using
interface pci_remove_bus() in remove.c.
So use new pci_is_bridge() check if the PCI device is bridge is better
choice. If user want check PCI bridge whether has a subordinate bus,
pci_has_subordinate() is a candidate.
Yijing Wang (13):
PCI: rename pci_is_bridge() to pci_has_subordinate()
PCI: Introduce new pci_is_bridge() helper function
PCI: Use new pci_is_bridge() to simplify code
x86/PCI: Use new pci_is_bridge() to simplify code
IA64/PCI: Use new pci_is_bridge() to simplify code
powerpc/PCI: Use new pci_is_bridge() to simplify code
sparc/PCI: Use new pci_is_bridge() to simplify code
PCI, rpaphp: Use new pci_is_bridge() to simplify code
PCI, shpchp: Use new pci_is_bridge() to simplify code
PCI, cpcihp: Use new pci_is_bridge() to simplify code
PCI, acpiphp: Use new pci_is_bridge() to simplify code
PCI, pcmcia: Use new pci_is_bridge() to simplify code
PCI, pciehp: Use new pci_is_bridge() to simplify code
arch/ia64/pci/fixup.c | 4 +---
arch/powerpc/kernel/pci-hotplug.c | 3 +--
arch/powerpc/kernel/pci_of_scan.c | 3 +--
arch/sparc/kernel/pci.c | 3 +--
arch/x86/pci/fixup.c | 4 +---
drivers/pci/hotplug/acpiphp_glue.c | 3 +--
drivers/pci/hotplug/cpci_hotplug_pci.c | 3 +--
drivers/pci/hotplug/pciehp_pci.c | 3 +--
drivers/pci/hotplug/rpadlpar_core.c | 3 +--
drivers/pci/hotplug/shpchp_pci.c | 3 +--
drivers/pci/pci-acpi.c | 8 +-------
drivers/pci/pci-driver.c | 8 ++++----
drivers/pci/pci.h | 2 +-
drivers/pci/probe.c | 3 +--
drivers/pci/setup-bus.c | 4 +---
drivers/pcmcia/cardbus.c | 3 +--
include/linux/pci.h | 13 +++++++++++++
17 files changed, 32 insertions(+), 41 deletions(-)
^ permalink raw reply
* [PATCH v2 05/13] IA64/PCI: Use new pci_is_bridge() to simplify code
From: Yijing Wang @ 2014-05-04 4:23 UTC (permalink / raw)
To: Bjorn Helgaas
Cc: Tony Luck, linux-ia64, x86, Yijing Wang, linux-pci, sparclinux,
Thomas Gleixner, linuxppc-dev, David S. Miller
In-Reply-To: <1399177428-3784-1-git-send-email-wangyijing@huawei.com>
Now we can use new pci_is_bridge() helper function
to simplify code.
Signed-off-by: Yijing Wang <wangyijing@huawei.com>
---
arch/ia64/pci/fixup.c | 4 +---
1 files changed, 1 insertions(+), 3 deletions(-)
diff --git a/arch/ia64/pci/fixup.c b/arch/ia64/pci/fixup.c
index eee069a..1fe9aa5 100644
--- a/arch/ia64/pci/fixup.c
+++ b/arch/ia64/pci/fixup.c
@@ -49,9 +49,7 @@ static void pci_fixup_video(struct pci_dev *pdev)
* type BRIDGE, or CARDBUS. Host to PCI controllers use
* PCI header type NORMAL.
*/
- if (bridge
- &&((bridge->hdr_type == PCI_HEADER_TYPE_BRIDGE)
- ||(bridge->hdr_type == PCI_HEADER_TYPE_CARDBUS))) {
+ if (bridge && (pci_is_bridge(bridge))) {
pci_read_config_word(bridge, PCI_BRIDGE_CONTROL,
&config);
if (!(config & PCI_BRIDGE_CTL_VGA))
--
1.7.1
^ permalink raw reply related
* [PATCH v2 09/13] PCI, shpchp: Use new pci_is_bridge() to simplify code
From: Yijing Wang @ 2014-05-04 4:23 UTC (permalink / raw)
To: Bjorn Helgaas
Cc: Tony Luck, linux-ia64, x86, Yijing Wang, linux-pci, sparclinux,
Thomas Gleixner, linuxppc-dev, David S. Miller
In-Reply-To: <1399177428-3784-1-git-send-email-wangyijing@huawei.com>
Now we can use new pci_is_bridge() helper function
to simplify code.
Signed-off-by: Yijing Wang <wangyijing@huawei.com>
---
drivers/pci/hotplug/shpchp_pci.c | 3 +--
1 files changed, 1 insertions(+), 2 deletions(-)
diff --git a/drivers/pci/hotplug/shpchp_pci.c b/drivers/pci/hotplug/shpchp_pci.c
index 2bf69fe..ea8ad31 100644
--- a/drivers/pci/hotplug/shpchp_pci.c
+++ b/drivers/pci/hotplug/shpchp_pci.c
@@ -64,8 +64,7 @@ int __ref shpchp_configure_device(struct slot *p_slot)
list_for_each_entry(dev, &parent->devices, bus_list) {
if (PCI_SLOT(dev->devfn) != p_slot->device)
continue;
- if ((dev->hdr_type == PCI_HEADER_TYPE_BRIDGE) ||
- (dev->hdr_type == PCI_HEADER_TYPE_CARDBUS))
+ if (pci_is_bridge(dev))
pci_hp_add_bridge(dev);
}
--
1.7.1
^ permalink raw reply related
* [PATCH v2 11/13] PCI, acpiphp: Use new pci_is_bridge() to simplify code
From: Yijing Wang @ 2014-05-04 4:23 UTC (permalink / raw)
To: Bjorn Helgaas
Cc: Tony Luck, linux-ia64, x86, Yijing Wang, linux-pci, sparclinux,
Thomas Gleixner, linuxppc-dev, David S. Miller
In-Reply-To: <1399177428-3784-1-git-send-email-wangyijing@huawei.com>
Now we can use new pci_is_bridge() helper function
to simplify code.
Signed-off-by: Yijing Wang <wangyijing@huawei.com>
---
drivers/pci/hotplug/acpiphp_glue.c | 3 +--
1 files changed, 1 insertions(+), 2 deletions(-)
diff --git a/drivers/pci/hotplug/acpiphp_glue.c b/drivers/pci/hotplug/acpiphp_glue.c
index bccc27e..f1f9bd1 100644
--- a/drivers/pci/hotplug/acpiphp_glue.c
+++ b/drivers/pci/hotplug/acpiphp_glue.c
@@ -516,8 +516,7 @@ static void __ref enable_slot(struct acpiphp_slot *slot)
if (PCI_SLOT(dev->devfn) != slot->device)
continue;
- if (dev->hdr_type == PCI_HEADER_TYPE_BRIDGE ||
- dev->hdr_type == PCI_HEADER_TYPE_CARDBUS) {
+ if (pci_is_bridge(dev)) {
max = pci_scan_bridge(bus, dev, max, pass);
if (pass && dev->subordinate) {
check_hotplug_bridge(slot, dev);
--
1.7.1
^ permalink raw reply related
* [PATCH v2 06/13] powerpc/PCI: Use new pci_is_bridge() to simplify code
From: Yijing Wang @ 2014-05-04 4:23 UTC (permalink / raw)
To: Bjorn Helgaas
Cc: Tony Luck, linux-ia64, x86, Yijing Wang, linux-pci, sparclinux,
Thomas Gleixner, linuxppc-dev, David S. Miller
In-Reply-To: <1399177428-3784-1-git-send-email-wangyijing@huawei.com>
Now we can use new pci_is_bridge() helper function
to simplify code.
Signed-off-by: Yijing Wang <wangyijing@huawei.com>
---
arch/powerpc/kernel/pci-hotplug.c | 3 +--
arch/powerpc/kernel/pci_of_scan.c | 3 +--
2 files changed, 2 insertions(+), 4 deletions(-)
diff --git a/arch/powerpc/kernel/pci-hotplug.c b/arch/powerpc/kernel/pci-hotplug.c
index c1e17ae..5b78917 100644
--- a/arch/powerpc/kernel/pci-hotplug.c
+++ b/arch/powerpc/kernel/pci-hotplug.c
@@ -98,8 +98,7 @@ void pcibios_add_pci_devices(struct pci_bus * bus)
max = bus->busn_res.start;
for (pass = 0; pass < 2; pass++) {
list_for_each_entry(dev, &bus->devices, bus_list) {
- if (dev->hdr_type == PCI_HEADER_TYPE_BRIDGE ||
- dev->hdr_type == PCI_HEADER_TYPE_CARDBUS)
+ if (pci_is_bridge(dev))
max = pci_scan_bridge(bus, dev,
max, pass);
}
diff --git a/arch/powerpc/kernel/pci_of_scan.c b/arch/powerpc/kernel/pci_of_scan.c
index 83c26d8..059e244 100644
--- a/arch/powerpc/kernel/pci_of_scan.c
+++ b/arch/powerpc/kernel/pci_of_scan.c
@@ -362,8 +362,7 @@ static void __of_scan_bus(struct device_node *node, struct pci_bus *bus,
/* Now scan child busses */
list_for_each_entry(dev, &bus->devices, bus_list) {
- if (dev->hdr_type == PCI_HEADER_TYPE_BRIDGE ||
- dev->hdr_type == PCI_HEADER_TYPE_CARDBUS) {
+ if (pci_is_bridge(dev)) {
of_scan_pci_bridge(dev);
}
}
--
1.7.1
^ permalink raw reply related
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