* Re: [PATCH] scsi/ibmvscsi: add module alias for ibmvscsic
From: Benjamin Herrenschmidt @ 2012-07-31 3:08 UTC (permalink / raw)
To: Brian J King; +Cc: linuxppc-dev, Olaf Hering, linux-scsi, James E.J. Bottomley
In-Reply-To: <20120730190606.GD3155@aepfle.de>
On Mon, 2012-07-30 at 21:06 +0200, Olaf Hering wrote:
> > So while this would work, I do wonder however whether we could
> instead
> > fix it by simplifying the whole thing as follow since iSeries is now
> > gone and so we don't need split backends anymore:
> >
> > scsi/ibmvscsi: Remove backend abstraction
>
> I cant that these things myself anymore.
Brian, can somebody from your side own these ?
Cheers,
Ben.
^ permalink raw reply
* RE: [PATCH v4 3/7] fsl-dma: change release process of dma descriptor for supporting async_tx
From: Liu Qiang-B32616 @ 2012-07-31 4:09 UTC (permalink / raw)
To: Ira W. Snyder
Cc: Li Yang-R58472, Vinod Koul, Phillips Kim-R1AAHA,
dan.j.williams@gmail.com, linux-crypto@vger.kernel.org,
linuxppc-dev@lists.ozlabs.org, davem@davemloft.net,
herbert@gondor.apana.org.au
In-Reply-To: <20120730211004.GA12430@ovro.caltech.edu>
> -----Original Message-----
> From: Ira W. Snyder [mailto:iws@ovro.caltech.edu]
> Sent: Tuesday, July 31, 2012 5:10 AM
> To: Liu Qiang-B32616
> Cc: linux-crypto@vger.kernel.org; linuxppc-dev@lists.ozlabs.org; Phillips
> Kim-R1AAHA; herbert@gondor.hengli.com.au; davem@davemloft.net; Dan
> Williams; Vinod Koul; Li Yang-R58472
> Subject: Re: [PATCH v4 3/7] fsl-dma: change release process of dma
> descriptor for supporting async_tx
>=20
> On Fri, Jul 27, 2012 at 05:16:09PM +0800, qiang.liu@freescale.com wrote:
> > From: Qiang Liu <qiang.liu@freescale.com>
> >
> > Fix the potential risk when enable config NET_DMA and ASYNC_TX.
> > Async_tx is lack of support in current release process of dma
> descriptor,
> > all descriptors will be released whatever is acked or no-acked by
> async_tx,
> > so there is a potential race condition when dma engine is uesd by
> others
> > clients (e.g. when enable NET_DMA to offload TCP).
> >
> > In our case, a race condition which is raised when use both of talitos
> > and dmaengine to offload xor is because napi scheduler will sync all
> > pending requests in dma channels, it affects the process of raid
> operations
> > due to ack_tx is not checked in fsl dma. The no-acked descriptor is
> freed
> > which is submitted just now, as a dependent tx, this freed descriptor
> trigger
> > BUG_ON(async_tx_test_ack(depend_tx)) in async_tx_submit().
> >
>=20
> I'm preparing an alternative version of this patch that I think is
> easier to understand (it is much shorter). I'll post it up here as soon
> as I finish testing.
Can you give a simple description/idea about your patch? My patch is for fi=
x the
problems when I build a raid environment with talitos offload xor.
I think the new interface is clear enough and similar with the implement of=
other dma devices.
And do you have any comments about this patch?
>=20
> It would be nice to know how to easily reproduce this bug, without
> needing to set up a RAID system. I don't have access to any such
> hardware. A driver similar to drivers/dma/dmatest.c (using the async_tx
> API instead) would be wonderful.
You can refer to raid5.c if you do not want to use hardware. Or you can use
you ram (or other storage devices) to build a raid env to test.
Thanks.
>=20
> Thanks,
> Ira
>=20
> > TASK =3D ee1a94a0[1390] 'md0_raid5' THREAD: ecf40000 CPU: 0
> > GPR00: 00000001 ecf41ca0 ee44/921a94a0 0000003f 00000001 c00593e4
> 00000000 00000001
> > GPR08: 00000000 a7a7a7a7 00000001 045/920000002 42028042 100a38d4
> ed576d98 00000000
> > GPR16: ed5a11b0 00000000 2b162000 00000200 046/920000000 2d555000
> ed3015e8 c15a7aa0
> > GPR24: 00000000 c155fc40 00000000 ecb63220 ecf41d28 e47/92f640bb0
> ef640c30 ecf41ca0
> > NIP [c02b048c] async_tx_submit+0x6c/0x2b4
> > LR [c02b068c] async_tx_submit+0x26c/0x2b4
> > Call Trace:
> > [ecf41ca0] [c02b068c] async_tx_submit+0x26c/0x2b448/92 (unreliable)
> > [ecf41cd0] [c02b0a4c] async_memcpy+0x240/0x25c
> > [ecf41d20] [c0421064] async_copy_data+0xa0/0x17c
> > [ecf41d70] [c0421cf4] __raid_run_ops+0x874/0xe10
> > [ecf41df0] [c0426ee4] handle_stripe+0x820/0x25e8
> > [ecf41e90] [c0429080] raid5d+0x3d4/0x5b4
> > [ecf41f40] [c04329b8] md_thread+0x138/0x16c
> > [ecf41f90] [c008277c] kthread+0x8c/0x90
> > [ecf41ff0] [c0011630] kernel_thread+0x4c/0x68
> >
> > Cc: Dan Williams <dan.j.williams@intel.com>
> > Cc: Vinod Koul <vinod.koul@intel.com>
> > Cc: Li Yang <leoli@freescale.com>
> > Cc: Ira W. Snyder <iws@ovro.caltech.edu>
> > Signed-off-by: Qiang Liu <qiang.liu@freescale.com>
> > ---
> > drivers/dma/fsldma.c | 242 +++++++++++++++++++++++++++++++++++-------
> --------
> > drivers/dma/fsldma.h | 1 +
> > 2 files changed, 172 insertions(+), 71 deletions(-)
> >
> > diff --git a/drivers/dma/fsldma.c b/drivers/dma/fsldma.c
> > index 4f2f212..87f52c0 100644
> > --- a/drivers/dma/fsldma.c
> > +++ b/drivers/dma/fsldma.c
> > @@ -400,6 +400,125 @@ out_splice:
> > list_splice_tail_init(&desc->tx_list, &chan->ld_pending);
> > }
> >
> > +static void fsldma_cleanup_descriptor(struct fsldma_chan *chan);
> > +static void fsl_chan_xfer_ld_queue(struct fsldma_chan *chan);
> > +
> > +/**
> > + * fsldma_clean_completed_descriptor - free all descriptors which
> > + * has been completed and acked
> > + * @chan: Freescale DMA channel
> > + *
> > + * This function is used on all completed and acked descriptors.
> > + * All descriptors should only be freed in this function.
> > + */
> > +static int
> > +fsldma_clean_completed_descriptor(struct fsldma_chan *chan)
> > +{
> > + struct fsl_desc_sw *desc, *_desc;
> > +
> > + /* Run the callback for each descriptor, in order */
> > + list_for_each_entry_safe(desc, _desc, &chan->ld_completed, node) {
> > +
> > + if (async_tx_test_ack(&desc->async_tx)) {
> > + /* Remove from the list of transactions */
> > + list_del(&desc->node);
> > +#ifdef FSL_DMA_LD_DEBUG
> > + chan_dbg(chan, "LD %p free\n", desc);
> > +#endif
> > + dma_pool_free(chan->desc_pool, desc,
> > + desc->async_tx.phys);
> > + }
> > + }
> > +
> > + return 0;
> > +}
> > +
> > +/**
> > + * fsldma_run_tx_complete_actions - cleanup and free a single link
> descriptor
> > + * @chan: Freescale DMA channel
> > + * @desc: descriptor to cleanup and free
> > + * @cookie: Freescale DMA transaction identifier
> > + *
> > + * This function is used on a descriptor which has been executed by
> the DMA
> > + * controller. It will run any callbacks, submit any dependencies.
> > + */
> > +static dma_cookie_t fsldma_run_tx_complete_actions(struct fsl_desc_sw
> *desc,
> > + struct fsldma_chan *chan, dma_cookie_t cookie)
> > +{
> > + struct dma_async_tx_descriptor *txd =3D &desc->async_tx;
> > + struct device *dev =3D chan->common.device->dev;
> > + dma_addr_t src =3D get_desc_src(chan, desc);
> > + dma_addr_t dst =3D get_desc_dst(chan, desc);
> > + u32 len =3D get_desc_cnt(chan, desc);
> > +
> > + BUG_ON(txd->cookie < 0);
> > +
> > + if (txd->cookie > 0) {
> > + cookie =3D txd->cookie;
> > +
> > + /* Run the link descriptor callback function */
> > + if (txd->callback) {
> > +#ifdef FSL_DMA_LD_DEBUG
> > + chan_dbg(chan, "LD %p callback\n", desc);
> > +#endif
> > + txd->callback(txd->callback_param);
> > + }
> > +
> > + /* Unmap the dst buffer, if requested */
> > + if (!(txd->flags & DMA_COMPL_SKIP_DEST_UNMAP)) {
> > + if (txd->flags & DMA_COMPL_DEST_UNMAP_SINGLE)
> > + dma_unmap_single(dev, dst, len, DMA_FROM_DEVICE);
> > + else
> > + dma_unmap_page(dev, dst, len, DMA_FROM_DEVICE);
> > + }
> > +
> > + /* Unmap the src buffer, if requested */
> > + if (!(txd->flags & DMA_COMPL_SKIP_SRC_UNMAP)) {
> > + if (txd->flags & DMA_COMPL_SRC_UNMAP_SINGLE)
> > + dma_unmap_single(dev, src, len, DMA_TO_DEVICE);
> > + else
> > + dma_unmap_page(dev, src, len, DMA_TO_DEVICE);
> > + }
> > + }
> > +
> > + /* Run any dependencies */
> > + dma_run_dependencies(txd);
> > +
> > + return cookie;
> > +}
> > +
> > +/**
> > + * fsldma_clean_running_descriptor - move the completed descriptor
> from
> > + * ld_running to ld_completed
> > + * @chan: Freescale DMA channel
> > + * @desc: the descriptor which is completed
> > + *
> > + * Free the descriptor directly if acked by async_tx api, or move it
> to
> > + * queue ld_completed.
> > + */
> > +static int
> > +fsldma_clean_running_descriptor(struct fsldma_chan *chan,
> > + struct fsl_desc_sw *desc)
> > +{
> > + /* Remove from the list of transactions */
> > + list_del(&desc->node);
> > + /*
> > + * the client is allowed to attach dependent operations
> > + * until 'ack' is set
> > + */
> > + if (!async_tx_test_ack(&desc->async_tx)) {
> > + /*
> > + * Move this descriptor to the list of descriptors which is
> > + * completed, but still awaiting the 'ack' bit to be set.
> > + */
> > + list_add_tail(&desc->node, &chan->ld_completed);
> > + return 0;
> > + }
> > +
> > + dma_pool_free(chan->desc_pool, desc, desc->async_tx.phys);
> > + return 0;
> > +}
> > +
> > static dma_cookie_t fsl_dma_tx_submit(struct dma_async_tx_descriptor
> *tx)
> > {
> > struct fsldma_chan *chan =3D to_fsl_chan(tx->chan);
> > @@ -534,8 +653,10 @@ static void fsl_dma_free_chan_resources(struct
> dma_chan *dchan)
> >
> > chan_dbg(chan, "free all channel resources\n");
> > spin_lock_irqsave(&chan->desc_lock, flags);
> > + fsldma_cleanup_descriptor(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);
> >
> > dma_pool_destroy(chan->desc_pool);
> > @@ -819,46 +940,53 @@ static int fsl_dma_device_control(struct dma_chan
> *dchan,
> > * controller. It will run any callbacks, submit any dependencies, and
> then
> > * free the descriptor.
> > */
> > -static void fsldma_cleanup_descriptor(struct fsldma_chan *chan,
> > - struct fsl_desc_sw *desc)
> > +static void fsldma_cleanup_descriptor(struct fsldma_chan *chan)
> > {
> > - struct dma_async_tx_descriptor *txd =3D &desc->async_tx;
> > - struct device *dev =3D chan->common.device->dev;
> > - dma_addr_t src =3D get_desc_src(chan, desc);
> > - dma_addr_t dst =3D get_desc_dst(chan, desc);
> > - u32 len =3D get_desc_cnt(chan, desc);
> > + struct fsl_desc_sw *desc, *_desc;
> > + dma_cookie_t cookie =3D 0;
> > + dma_addr_t curr_phys =3D get_cdar(chan);
> > + int idle =3D dma_is_idle(chan);
> > + int seen_current =3D 0;
> >
> > - /* Run the link descriptor callback function */
> > - if (txd->callback) {
> > -#ifdef FSL_DMA_LD_DEBUG
> > - chan_dbg(chan, "LD %p callback\n", desc);
> > -#endif
> > - txd->callback(txd->callback_param);
> > - }
> > + fsldma_clean_completed_descriptor(chan);
> >
> > - /* Run any dependencies */
> > - dma_run_dependencies(txd);
> > + /* Run the callback for each descriptor, in order */
> > + list_for_each_entry_safe(desc, _desc, &chan->ld_running, node) {
> > + /*
> > + * do not advance past the current descriptor loaded into the
> > + * hardware channel, subsequent descriptors are either in
> > + * process or have not been submitted
> > + */
> > + if (seen_current)
> > + break;
> >
> > - /* Unmap the dst buffer, if requested */
> > - if (!(txd->flags & DMA_COMPL_SKIP_DEST_UNMAP)) {
> > - if (txd->flags & DMA_COMPL_DEST_UNMAP_SINGLE)
> > - dma_unmap_single(dev, dst, len, DMA_FROM_DEVICE);
> > - else
> > - dma_unmap_page(dev, dst, len, DMA_FROM_DEVICE);
> > - }
> > + /*
> > + * stop the search if we reach the current descriptor and the
> > + * channel is busy
> > + */
> > + if (desc->async_tx.phys =3D=3D curr_phys) {
> > + seen_current =3D 1;
> > + if (!idle)
> > + break;
> > + }
> > +
> > + cookie =3D fsldma_run_tx_complete_actions(desc, chan, cookie);
> > +
> > + if (fsldma_clean_running_descriptor(chan, desc))
> > + break;
> >
> > - /* Unmap the src buffer, if requested */
> > - if (!(txd->flags & DMA_COMPL_SKIP_SRC_UNMAP)) {
> > - if (txd->flags & DMA_COMPL_SRC_UNMAP_SINGLE)
> > - dma_unmap_single(dev, src, len, DMA_TO_DEVICE);
> > - else
> > - dma_unmap_page(dev, src, len, DMA_TO_DEVICE);
> > }
> >
> > -#ifdef FSL_DMA_LD_DEBUG
> > - chan_dbg(chan, "LD %p free\n", desc);
> > -#endif
> > - dma_pool_free(chan->desc_pool, desc, txd->phys);
> > + /*
> > + * Start any pending transactions automatically
> > + *
> > + * In the ideal case, we keep the DMA controller busy while we go
> > + * ahead and free the descriptors below.
> > + */
> > + fsl_chan_xfer_ld_queue(chan);
> > +
> > + if (cookie > 0)
> > + chan->common.completed_cookie =3D cookie;
> > }
> >
> > /**
> > @@ -954,11 +1082,15 @@ static enum dma_status fsl_tx_status(struct
> dma_chan *dchan,
> > enum dma_status ret;
> > unsigned long flags;
> >
> > - spin_lock_irqsave(&chan->desc_lock, flags);
> > ret =3D dma_cookie_status(dchan, cookie, txstate);
> > + if (ret =3D=3D DMA_SUCCESS)
> > + return ret;
> > +
> > + spin_lock_irqsave(&chan->desc_lock, flags);
> > + fsldma_cleanup_descriptor(chan);
> > spin_unlock_irqrestore(&chan->desc_lock, flags);
> >
> > - return ret;
> > + return dma_cookie_status(dchan, cookie, txstate);
> > }
> >
> > /*--------------------------------------------------------------------
> --------*/
> > @@ -1035,52 +1167,19 @@ static irqreturn_t fsldma_chan_irq(int irq,
> void *data)
> > static void dma_do_tasklet(unsigned long data)
> > {
> > struct fsldma_chan *chan =3D (struct fsldma_chan *)data;
> > - struct fsl_desc_sw *desc, *_desc;
> > - LIST_HEAD(ld_cleanup);
> > unsigned long flags;
> >
> > chan_dbg(chan, "tasklet entry\n");
> >
> > spin_lock_irqsave(&chan->desc_lock, flags);
> >
> > - /* update the cookie if we have some descriptors to cleanup */
> > - if (!list_empty(&chan->ld_running)) {
> > - dma_cookie_t cookie;
> > -
> > - desc =3D to_fsl_desc(chan->ld_running.prev);
> > - cookie =3D desc->async_tx.cookie;
> > - dma_cookie_complete(&desc->async_tx);
> > -
> > - chan_dbg(chan, "completed_cookie=3D%d\n", cookie);
> > - }
> > -
> > - /*
> > - * move the descriptors to a temporary list so we can drop the lock
> > - * during the entire cleanup operation
> > - */
> > - list_splice_tail_init(&chan->ld_running, &ld_cleanup);
> > -
> > /* the hardware is now idle and ready for more */
> > chan->idle =3D true;
> >
> > - /*
> > - * Start any pending transactions automatically
> > - *
> > - * In the ideal case, we keep the DMA controller busy while we go
> > - * ahead and free the descriptors below.
> > - */
> > - fsl_chan_xfer_ld_queue(chan);
> > - spin_unlock_irqrestore(&chan->desc_lock, flags);
> > -
> > - /* Run the callback for each descriptor, in order */
> > - list_for_each_entry_safe(desc, _desc, &ld_cleanup, node) {
> > + /* Run all cleanup for this descriptor */
> > + fsldma_cleanup_descriptor(chan);
> >
> > - /* Remove from the list of transactions */
> > - list_del(&desc->node);
> > -
> > - /* Run all cleanup for this descriptor */
> > - fsldma_cleanup_descriptor(chan, desc);
> > - }
> > + spin_unlock_irqrestore(&chan->desc_lock, flags);
> >
> > chan_dbg(chan, "tasklet exit\n");
> > }
> > @@ -1262,6 +1361,7 @@ static int __devinit fsl_dma_chan_probe(struct
> fsldma_device *fdev,
> > spin_lock_init(&chan->desc_lock);
> > INIT_LIST_HEAD(&chan->ld_pending);
> > INIT_LIST_HEAD(&chan->ld_running);
> > + INIT_LIST_HEAD(&chan->ld_completed);
> > chan->idle =3D true;
> >
> > chan->common.device =3D &fdev->common;
> > diff --git a/drivers/dma/fsldma.h b/drivers/dma/fsldma.h
> > index f5c3879..7ede908 100644
> > --- a/drivers/dma/fsldma.h
> > +++ b/drivers/dma/fsldma.h
> > @@ -140,6 +140,7 @@ struct fsldma_chan {
> > spinlock_t desc_lock; /* Descriptor operation lock */
> > struct list_head ld_pending; /* Link descriptors queue */
> > struct list_head ld_running; /* Link descriptors queue */
> > + struct list_head ld_completed; /* Link descriptors queue */
> > struct dma_chan common; /* DMA common channel */
> > struct dma_pool *desc_pool; /* Descriptors pool */
> > struct device *dev; /* Channel device */
> > --
> > 1.7.5.1
> >
> >
^ permalink raw reply
* 3.5+: yaboot, Invalid memory access
From: Christian Kujau @ 2012-07-31 5:46 UTC (permalink / raw)
To: linuxppc-dev
Hi,
when trying to upgrade from 3.5 (final) to today's git checkout from
Linus' tree, yaboot cannot boot and the following is printed:
[...]
returning from prom_init
Invalid memory access at %SRR0: 00c62fd4 %SRR1: 00003030
The whole message: http://nerdbynature.de/bits/3.5.0/yaboot/
The Yaboot version is 1.3.16 (from Debian/testing), I haven't tried 1.3.17
yet, its changelog does not say anything about "newer kernel support" so
I'm not sure if this would help here.
Any other ideas?
Thanks,
Christian.
--
BOFH excuse #389:
/dev/clue was linked to /dev/null
^ permalink raw reply
* RE: [PATCH V3 1/5] powerpc/fsl-pci: Unify pci/pcie initialization code
From: Jia Hongtao-B38951 @ 2012-07-31 6:36 UTC (permalink / raw)
To: Kumar Gala
Cc: Wood Scott-B07421, linuxppc-dev@lists.ozlabs.org, Li Yang-R58472
In-Reply-To: <536EC8A2-60D9-4991-8D38-092C4C8B698F@kernel.crashing.org>
> -----Original Message-----
> From: Kumar Gala [mailto:galak@kernel.crashing.org]
> Sent: Monday, July 30, 2012 10:47 PM
> To: Jia Hongtao-B38951
> Cc: Wood Scott-B07421; linuxppc-dev@lists.ozlabs.org; Li Yang-R58472
> Subject: Re: [PATCH V3 1/5] powerpc/fsl-pci: Unify pci/pcie
> initialization code
>=20
>=20
> On Jul 30, 2012, at 3:26 AM, Jia Hongtao-B38951 wrote:
>=20
> >
> >
> >> -----Original Message-----
> >> From: Kumar Gala [mailto:galak@kernel.crashing.org]
> >> Sent: Saturday, July 28, 2012 5:17 AM
> >> To: Wood Scott-B07421
> >> Cc: Jia Hongtao-B38951; linuxppc-dev@lists.ozlabs.org; Wood Scott-
> B07421;
> >> Li Yang-R58472
> >> Subject: Re: [PATCH V3 1/5] powerpc/fsl-pci: Unify pci/pcie
> >> initialization code
> >>
> >>
> >> On Jul 27, 2012, at 3:24 PM, Scott Wood wrote:
> >>
> >>> On 07/27/2012 05:10 AM, Jia Hongtao-B38951 wrote:
> >>>> Hi kumar,
> >>>>
> >>>> I know "duplicate code from pci_process_bridge_OF_ranges()" is
> >>>> hard to accept but "refactor the code to have a shared function"
> >>>> is knotty. Actually this is the reason I didn't do the refactor.
> >>>
> >>> Maybe we should keep doing the init early? We could still have a
> >>> platform device for the PM stuff, but some init would be done before
> >> probe.
> >>>
> >>> Another possibility is to try to handle swiotlb init later --
> possibly
> >>> by reserving memory for it if the platform indicates it's a
> possibility
> >>> that it will be needed, then freeing the memory if it's not needed.
> >>>
> >>> -Scott
> >>
> >> I think the first option seems reasonable. Can we leave fsl_pci_init(=
)
> >> as we now have it and just have the platform driver deal with PM
> restore
> >> via calling setup_pci_atmu() [probably need to update setup_pci_atmu
> to
> >> handle restore case, but seems like minor changes]
> >>
> >> - k
> >>
> >
> >
> > I think the second option is better if it's hard to decouple swiotlb
> > determination from pci init. I believe the better architecture that
> > PCI init in probe function of platform driver will bring us
> considerable
> > advantage. I really like to keep the completion of pci controller
> > platform driver not only for PM support but also for pci init.
> >
> > -Hongtao.
> >
>=20
> Shifting of swiotlb init has a lot more issues. Why do we need to do the
> PCI init in probe?
>=20
> - k
I investigated the swiotlb init thing and found that in x86 swiotlb init is
done first and free if we don't need it.
-Hongtao.
^ permalink raw reply
* RE: [2/3][PATCH][v2] TDM Framework
From: Singh Sandeep-B37400 @ 2012-07-31 6:40 UTC (permalink / raw)
To: John Stoffel
Cc: devel@driverdev.osuosl.org, linuxppc-dev@lists.ozlabs.org,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org
In-Reply-To: <20502.38341.619003.356462@quad.stoffel.home>
-----Original Message-----
From: John Stoffel [mailto:john@stoffel.org]=20
Sent: Monday, July 30, 2012 7:40 PM
To: Singh Sandeep-B37400
Cc: John Stoffel; linuxppc-dev@lists.ozlabs.org; linux-arm-kernel@lists.inf=
radead.org; galak@kernel.crashing.org; linux-kernel@vger.kernel.org; devel@=
driverdev.osuosl.org
Subject: RE: [2/3][PATCH][v2] TDM Framework
>>>>> "Singh" =3D=3D Singh Sandeep-B37400 <B37400@freescale.com> writes:
Singh> -----Original Message-----
Singh> From: John Stoffel [mailto:john@stoffel.org]
Singh> Sent: 27 July 2012 19:42
Singh> To: Singh Sandeep-B37400
Singh> Cc: linuxppc-dev@lists.ozlabs.org;=20
Singh> linux-arm-kernel@lists.infradead.org; galak@kernel.crashing.org;=20
Singh> linux-kernel@vger.kernel.org; devel@driverdev.osuosl.org
Singh> Subject: Re: [2/3][PATCH][v2] TDM Framework
>> From: Sandeep Singh <Sandeep@freescale.com> TDM Framework is an=20
>> attempt to provide a platform independent layer which can offer a=20
>> standard interface for TDM access to different client modules.
Singh> Please don't use TLAs (Three Letter Acronyms) like TDM without expla=
ining the clearly and up front. It makes it hard for anyone else who doens=
't know your code to look it over without having to spend lots of time poki=
ng around to figure it out from either context or somewhere else.
Singh> [Sandeep] Patch for documentation for TDM is present in this=20
Singh> patch set, which explains TDM in detail. Should we do this in=20
Singh> commit message too?? Link too documentation patch:
Singh> http://patchwork.ozlabs.org/patch/173680/
You should put the expansion of TDM into the initial commit message, and al=
so into the Kconfig text, so that someone configuring the kernel has a clue=
what you're talking about. =20
[Sandeep] Thanks for suggestion. Will take care.
Try to approach this as a brandnew user who doesn't have your knowledge of =
the software. Write for the un-initiated if at all possible.
John
^ permalink raw reply
* RE: [2/3][PATCH][v2] TDM Framework
From: Singh Sandeep-B37400 @ 2012-07-31 6:41 UTC (permalink / raw)
To: Mark Brown, Francois Romieu
Cc: devel@driverdev.osuosl.org, linuxppc-dev@lists.ozlabs.org,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org
In-Reply-To: <20120730154536.GA3218@sirena.org.uk>
-----Original Message-----
From: Mark Brown [mailto:broonie@opensource.wolfsonmicro.com]=20
Sent: Monday, July 30, 2012 9:16 PM
To: Francois Romieu
Cc: Singh Sandeep-B37400; devel@driverdev.osuosl.org; linuxppc-dev@lists.oz=
labs.org; galak@kernel.crashing.org; linux-arm-kernel@lists.infradead.org; =
linux-kernel@vger.kernel.org
Subject: Re: [2/3][PATCH][v2] TDM Framework
On Fri, Jul 27, 2012 at 05:25:42PM +0200, Francois Romieu wrote:
> 2. It would probably make sense to Cc: netdev and serial. There may be
> some kernel client network integration from the start.
Plus audio, quite a few of the buses mentioned as examples of use cases for=
the hardware are audio ones.
[Sandeep] Ok
^ permalink raw reply
* Re: [PATCH V3 1/5] powerpc/fsl-pci: Unify pci/pcie initialization code
From: Li Yang @ 2012-07-31 7:21 UTC (permalink / raw)
To: Kumar Gala
Cc: Wood Scott-B07421, linuxppc-dev@lists.ozlabs.org, Li Yang-R58472,
Jia Hongtao-B38951
In-Reply-To: <536EC8A2-60D9-4991-8D38-092C4C8B698F@kernel.crashing.org>
On Mon, Jul 30, 2012 at 10:46 PM, Kumar Gala <galak@kernel.crashing.org> wrote:
>
> On Jul 30, 2012, at 3:26 AM, Jia Hongtao-B38951 wrote:
>
>>
>>
>>> -----Original Message-----
>>> From: Kumar Gala [mailto:galak@kernel.crashing.org]
>>> Sent: Saturday, July 28, 2012 5:17 AM
>>> To: Wood Scott-B07421
>>> Cc: Jia Hongtao-B38951; linuxppc-dev@lists.ozlabs.org; Wood Scott-B07421;
>>> Li Yang-R58472
>>> Subject: Re: [PATCH V3 1/5] powerpc/fsl-pci: Unify pci/pcie
>>> initialization code
>>>
>>>
>>> On Jul 27, 2012, at 3:24 PM, Scott Wood wrote:
>>>
>>>> On 07/27/2012 05:10 AM, Jia Hongtao-B38951 wrote:
>>>>> Hi kumar,
>>>>>
>>>>> I know "duplicate code from pci_process_bridge_OF_ranges()" is
>>>>> hard to accept but "refactor the code to have a shared function"
>>>>> is knotty. Actually this is the reason I didn't do the refactor.
>>>>
>>>> Maybe we should keep doing the init early? We could still have a
>>>> platform device for the PM stuff, but some init would be done before
>>> probe.
>>>>
>>>> Another possibility is to try to handle swiotlb init later -- possibly
>>>> by reserving memory for it if the platform indicates it's a possibility
>>>> that it will be needed, then freeing the memory if it's not needed.
>>>>
>>>> -Scott
>>>
>>> I think the first option seems reasonable. Can we leave fsl_pci_init()
>>> as we now have it and just have the platform driver deal with PM restore
>>> via calling setup_pci_atmu() [probably need to update setup_pci_atmu to
>>> handle restore case, but seems like minor changes]
>>>
>>> - k
>>>
>>
>>
>> I think the second option is better if it's hard to decouple swiotlb
>> determination from pci init. I believe the better architecture that
>> PCI init in probe function of platform driver will bring us considerable
>> advantage. I really like to keep the completion of pci controller
>> platform driver not only for PM support but also for pci init.
>>
>> -Hongtao.
>>
>
> Shifting of swiotlb init has a lot more issues. Why do we need to do the PCI init in probe?
The ordering issues are introduced by swiotlb. And the ideal way is
to solve the problem within swiotlb instead of changing PCI to
workaround it. Take the implementation of x86 as reference it's
possible to be addressed bu allocating first and free later approach.
It is common sense that the initialization of a device is in the probe
function of the driver of the device. And the change will provide
better unification of PCI controller code. The PCI controller is
generic enough not to be taken care of at the platform area.
Leo
^ permalink raw reply
* [git pull] Please pull powerpc.git merge branch
From: Benjamin Herrenschmidt @ 2012-07-31 7:33 UTC (permalink / raw)
To: Linus Torvalds; +Cc: linuxppc-dev list, Andrew Morton, Linux Kernel list
Hi Linus !
Kumar sent me a handful of Freescale related fixes and I added
another regression fix to the pile.
Cheers,
Ben.
PS. I -will- eventually learn about that signed tag business :-)
The following changes since commit 1fad1e9a747687a7399bf58e87974f9b1bbcae06:
Merge tag 'nfs-for-3.6-1' of git://git.linux-nfs.org/projects/trondmy/linux-nfs (2012-07-30 19:16:57 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/benh/powerpc.git merge
for you to fetch changes up to ad36cb0d1d3e2b7f161cd33932433f9349cade1e:
powerpc/kvm/book3s_32: Fix MTMSR_EERI macro (2012-07-31 15:21:20 +1000)
----------------------------------------------------------------
Alexander Graf (1):
powerpc/kvm/book3s_32: Fix MTMSR_EERI macro
Benjamin Herrenschmidt (1):
Merge remote-tracking branch 'kumar/merge' into merge
Claudiu Manoil (1):
powerpc/85xx: Fix sram_offset parameter type
Shaohui Xie (1):
powerpc/85xx: P3041DS - change espi input-clock from 40MHz to 35MHz
Tang Yuantian (1):
powerpc/85xx: Fix pci base address error for p2020rdb-pc in dts
Timur Tabi (2):
powerpc/85xx: p1022ds: disable the NAND flash node if video is enabled
powerpc/85xx: p1022ds: fix DIU/LBC switching with NAND enabled
arch/powerpc/boot/dts/p2020rdb-pc_32b.dts | 4 +-
arch/powerpc/boot/dts/p2020rdb-pc_36b.dts | 4 +-
arch/powerpc/boot/dts/p3041ds.dts | 2 +-
arch/powerpc/kvm/book3s_rmhandlers.S | 1 -
arch/powerpc/platforms/85xx/p1022_ds.c | 122 +++++++++++++++++++++++------
arch/powerpc/sysdev/fsl_85xx_cache_ctlr.h | 4 +-
arch/powerpc/sysdev/fsl_85xx_l2ctlr.c | 39 ++++-----
7 files changed, 121 insertions(+), 55 deletions(-)
^ permalink raw reply
* RE: [PATCH] powerpc/fsl: mpic timer driver
From: Wang Dongsheng-B40534 @ 2012-07-31 7:58 UTC (permalink / raw)
To: Kumar Gala
Cc: paulus@samba.org, linuxppc-dev@lists.ozlabs.org,
Wood Scott-B07421
In-Reply-To: <2F4F76E5-1ACD-4F30-A997-9811DCE82202@kernel.crashing.org>
> -----Original Message-----
> From: Kumar Gala [mailto:galak@kernel.crashing.org]
> Sent: Friday, July 27, 2012 9:14 PM
> To: Wang Dongsheng-B40534
> Cc: benh@kernel.crashing.org; paulus@samba.org; Wood Scott-B07421;
> linuxppc-dev@lists.ozlabs.org
> Subject: Re: [PATCH] powerpc/fsl: mpic timer driver
>=20
>=20
> On Jul 27, 2012, at 1:20 AM, <Dongsheng.wang@freescale.com>
> <Dongsheng.wang@freescale.com> wrote:
>=20
> > From: Wang Dongsheng <Dongsheng.Wang@freescale.com>
> >
> > Global timers A and B internal to the PIC. The two independent groups
> > of global timer, group A and group B, are identical in their
> functionality.
> > The hardware timer generates an interrupt on every timer cycle.
> > e.g
> > Power management can use the hardware timer to wake up the machine.
> >
> > Signed-off-by: Wang Dongsheng <Dongsheng.Wang@freescale.com>
> > Signed-off-by: Li Yang <leoli@freescale.com>
>=20
> How much of this is FSL specific vs openpic? OpenPIC spec's timer
> support (only a single group).
>=20
[Wang Dongsheng] Yes, OpenPIC only a single group timer.
FSL: add more register, features and group.
This patch only to support FSL chip.
"mpic_timer.c" -> "fsl_mpic_timer.c"
I will modify the description of the patch. how about?
> > +static int set_cascade_timer(struct group_priv *priv, u64 ticks,
> > + unsigned int num)
> > +{
> > + struct cascade_priv *casc_priv;
> > + u32 tmp;
> > + u32 tmp_ticks;
> > + u32 rem_ticks;
> > +
> > + /* set group tcr reg for cascade */
> > + casc_priv =3D priv->timer[num].cascade_handle;
> > + if (!casc_priv)
> > + return -EINVAL;
> > +
> > + tmp =3D casc_priv->tcr_value |
> > + (casc_priv->tcr_value << MPIC_TIMER_TCR_ROVR_OFFSET);
> > + setbits32(priv->group_tcr, tmp);
> > +
> > + tmp_ticks =3D div_u64_rem(ticks, MAX_TIME_CASCADE, &rem_ticks);
> > +
> > + out_be32(&priv->regs[num].gtccr, 0);
> > + out_be32(&priv->regs[num].gtbcr, tmp_ticks | MPIC_TIMER_STOP);
> > +
> > + out_be32(&priv->regs[num - 1].gtccr, 0);
> > + out_be32(&priv->regs[num - 1].gtbcr, rem_ticks);
> > +
> > + return 0;
> > +}
> > +
> > +struct mpic_timer *get_cascade_timer(u64 ticks) {
>=20
> should this be static?
>=20
[Wang Dongsheng] ok.
> > _______________________________________________
> > Linuxppc-dev mailing list
> > Linuxppc-dev@lists.ozlabs.org
> > https://lists.ozlabs.org/listinfo/linuxppc-dev
>=20
^ permalink raw reply
* Re: [PATCH] powerpc: Update g5_defconfig
From: Andreas Schwab @ 2012-07-31 8:09 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev, Ben Skeggs
In-Reply-To: <1343029161.2957.35.camel@pasglop>
It's even worse. Since ec9b3a9de6b2a8a08c5250b466db92adf82b8d65
(drm/nouveau/i2c: resume use of i2c-algo-bit, rather than custom stack)
the system is just powered off in the middle of booting. Since nothing
is calling pmu_request with PMU_SHUTDOWN it must be some kind of bit
banging that causes the PMU to freak out.
Andreas.
--
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
^ permalink raw reply
* Re: [RFC PATCH v5 16/19] memory-hotplug: free memmap of sparse-vmemmap
From: Gerald Schaefer @ 2012-07-31 12:22 UTC (permalink / raw)
To: Wen Congyang
Cc: linux-s390, linux-ia64, linux-acpi, len.brown, linux-sh,
linux-kernel, cmetcalf, linux-mm, Yasuaki ISIMATU, paulus,
minchan.kim, kosaki.motohiro, rientjes, cl, linuxppc-dev, akpm,
liuj97
In-Reply-To: <50126EBE.1020006@cn.fujitsu.com>
On Fri, 27 Jul 2012 18:34:38 +0800
Wen Congyang <wency@cn.fujitsu.com> wrote:
> From: Yasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com>
>
> All pages of virtual mapping in removed memory cannot be freed, since
> some pages used as PGD/PUD includes not only removed memory but also
> other memory. So the patch checks whether page can be freed or not.
>
> How to check whether page can be freed or not?
> 1. When removing memory, the page structs of the revmoved memory are
> filled with 0FD.
> 2. All page structs are filled with 0xFD on PT/PMD, PT/PMD can be
> cleared. In this case, the page used as PT/PMD can be freed.
>
> Applying patch, __remove_section() of CONFIG_SPARSEMEM_VMEMMAP is
> integrated into one. So __remove_section() of
> CONFIG_SPARSEMEM_VMEMMAP is deleted.
There should also be generic or dummy versions of the functions
vmemmap_free_bootmem(), vmemmap_kfree() and
register_page_bootmem_memmap(). It doesn't compile on other
archtitectures than x86 as it is now:
mm/built-in.o: In function `sparse_remove_one_section':
(.text+0x49fa6): undefined reference to `vmemmap_free_bootmem'
mm/built-in.o: In function `sparse_remove_one_section':
(.text+0x49fcc): undefined reference to `vmemmap_kfree'
mm/built-in.o: In function `register_page_bootmem_info_node':
(.text+0x57c06): undefined reference to `register_page_bootmem_memmap'
mm/built-in.o: In function `sparse_add_one_section':
(.meminit.text+0x2506): undefined reference to `vmemmap_kfree'
mm/built-in.o: In function `sparse_add_one_section':
(.meminit.text+0x2528): undefined reference to `vmemmap_kfree'
make: *** [vmlinux] Error 1
^ permalink raw reply
* Re: [RFC PATCH v5 12/19] memory-hotplug: introduce new function arch_remove_memory()
From: Gerald Schaefer @ 2012-07-31 12:40 UTC (permalink / raw)
To: Wen Congyang
Cc: linux-s390, linux-ia64, len.brown, linux-acpi, linux-sh,
Heiko Carstens, linux-kernel, cmetcalf, linux-mm, Yasuaki ISIMATU,
paulus, minchan.kim, kosaki.motohiro, rientjes, cl, linuxppc-dev,
akpm, liuj97
In-Reply-To: <50166379.4090305@cn.fujitsu.com>
On Mon, 30 Jul 2012 18:35:37 +0800
Wen Congyang <wency@cn.fujitsu.com> wrote:
> At 07/30/2012 06:23 PM, Heiko Carstens Wrote:
> > On Fri, Jul 27, 2012 at 06:32:15PM +0800, Wen Congyang wrote:
> >> We don't call __add_pages() directly in the function add_memory()
> >> because some other architecture related things need to be done
> >> before or after calling __add_pages(). So we should introduce
> >> a new function arch_remove_memory() to revert the things
> >> done in arch_add_memory().
> >>
> >> Note: the function for s390 is not implemented(I don't know how to
> >> implement it for s390).
> >=20
> > There is no hardware or firmware interface which could trigger a
> > hot memory remove on s390. So there is nothing that needs to be
> > implemented.
>=20
> Thanks for providing this information.
>=20
> According to this, arch_remove_memory() for s390 can just return
> -EBUSY.
Yes, but there is a prototype mismatch for arch_remove_memory() on s390
and also other architectures (u64 vs. unsigned long).
arch/s390/mm/init.c:262: error: conflicting types for
=E2=80=98arch_remove_memory=E2=80=99 include/linux/memory_hotplug.h:88: err=
or: previous
declaration of =E2=80=98arch_remove_memory=E2=80=99 was here
In memory_hotplug.h you have:
extern int arch_remove_memory(unsigned long start, unsigned long size);
On all archs other than x86 you have:
int arch_remove_memory(u64 start, u64 size)
^ permalink raw reply
* Re: [PATCH 5/6] powerpc/fsl-pci: Add pci inbound/outbound PM support
From: Kumar Gala @ 2012-07-31 13:37 UTC (permalink / raw)
To: Jia Hongtao-B38951
Cc: Wood Scott-B07421, linuxppc-dev@lists.ozlabs.org, Li Yang-R58472
In-Reply-To: <412C8208B4A0464FA894C5F0C278CD5D01A29E98@039-SN1MPN1-002.039d.mgd.msft.net>
On Jul 30, 2012, at 1:09 AM, Jia Hongtao-B38951 wrote:
>> -----Original Message-----
>> From: Kumar Gala [mailto:galak@kernel.crashing.org]
>> Sent: Friday, July 27, 2012 9:24 PM
>> To: Jia Hongtao-B38951
>> Cc: linuxppc-dev@lists.ozlabs.org; Wood Scott-B07421; Li Yang-R58472
>> Subject: Re: [PATCH 5/6] powerpc/fsl-pci: Add pci inbound/outbound PM
>> support
>>=20
>>=20
>> On Jul 24, 2012, at 5:20 AM, Jia Hongtao wrote:
>>=20
>>> Power supply for PCI inbound/outbound window registers is off when
>> system
>>> go to deep-sleep state. We save the values of registers before =
suspend
>>> and restore to registers after resume.
>>>=20
>>> Signed-off-by: Jiang Yutang <b14898@freescale.com>
>>> Signed-off-by: Jia Hongtao <B38951@freescale.com>
>>> Signed-off-by: Li Yang <leoli@freescale.com>
>>> ---
>>> arch/powerpc/include/asm/pci-bridge.h | 2 +-
>>> arch/powerpc/sysdev/fsl_pci.c | 121
>> +++++++++++++++++++++++++++++++++
>>> 2 files changed, 122 insertions(+), 1 deletions(-)
>>=20
>> Remind me why we need to save/restore PCI ATMUs, why not just =
re-parse
>> the device tree to restore?
>>=20
>> - k
>=20
> Save/restore is the more efficient way. Latency of sleep/wakeup is one =
of
> most important features in power management.
>=20
> -Hongtao.
I don't think the time it takes to run through setup_pci_atmu() is that =
long compared to fsl_pci_resume().
Also, don't you need to setup PCICCSRBAR and do setup_pci_cmd() on =
resume?
- k=
^ permalink raw reply
* Re: [PATCH V3 1/5] powerpc/fsl-pci: Unify pci/pcie initialization code
From: Kumar Gala @ 2012-07-31 13:37 UTC (permalink / raw)
To: Li Yang
Cc: Wood Scott-B07421, linuxppc-dev@lists.ozlabs.org, Li Yang-R58472,
Jia Hongtao-B38951
In-Reply-To: <CADRPPNThb68v9h6Dy4qOxv2pwYLg=Zvuk_6+jM4HUxDbuzfhAQ@mail.gmail.com>
On Jul 31, 2012, at 2:21 AM, Li Yang wrote:
> On Mon, Jul 30, 2012 at 10:46 PM, Kumar Gala =
<galak@kernel.crashing.org> wrote:
>>=20
>> On Jul 30, 2012, at 3:26 AM, Jia Hongtao-B38951 wrote:
>>=20
>>>=20
>>>=20
>>>> -----Original Message-----
>>>> From: Kumar Gala [mailto:galak@kernel.crashing.org]
>>>> Sent: Saturday, July 28, 2012 5:17 AM
>>>> To: Wood Scott-B07421
>>>> Cc: Jia Hongtao-B38951; linuxppc-dev@lists.ozlabs.org; Wood =
Scott-B07421;
>>>> Li Yang-R58472
>>>> Subject: Re: [PATCH V3 1/5] powerpc/fsl-pci: Unify pci/pcie
>>>> initialization code
>>>>=20
>>>>=20
>>>> On Jul 27, 2012, at 3:24 PM, Scott Wood wrote:
>>>>=20
>>>>> On 07/27/2012 05:10 AM, Jia Hongtao-B38951 wrote:
>>>>>> Hi kumar,
>>>>>>=20
>>>>>> I know "duplicate code from pci_process_bridge_OF_ranges()" is
>>>>>> hard to accept but "refactor the code to have a shared function"
>>>>>> is knotty. Actually this is the reason I didn't do the refactor.
>>>>>=20
>>>>> Maybe we should keep doing the init early? We could still have a
>>>>> platform device for the PM stuff, but some init would be done =
before
>>>> probe.
>>>>>=20
>>>>> Another possibility is to try to handle swiotlb init later -- =
possibly
>>>>> by reserving memory for it if the platform indicates it's a =
possibility
>>>>> that it will be needed, then freeing the memory if it's not =
needed.
>>>>>=20
>>>>> -Scott
>>>>=20
>>>> I think the first option seems reasonable. Can we leave =
fsl_pci_init()
>>>> as we now have it and just have the platform driver deal with PM =
restore
>>>> via calling setup_pci_atmu() [probably need to update =
setup_pci_atmu to
>>>> handle restore case, but seems like minor changes]
>>>>=20
>>>> - k
>>>>=20
>>>=20
>>>=20
>>> I think the second option is better if it's hard to decouple swiotlb
>>> determination from pci init. I believe the better architecture that
>>> PCI init in probe function of platform driver will bring us =
considerable
>>> advantage. I really like to keep the completion of pci controller
>>> platform driver not only for PM support but also for pci init.
>>>=20
>>> -Hongtao.
>>>=20
>>=20
>> Shifting of swiotlb init has a lot more issues. Why do we need to do =
the PCI init in probe?
>=20
> The ordering issues are introduced by swiotlb. And the ideal way is
> to solve the problem within swiotlb instead of changing PCI to
> workaround it. Take the implementation of x86 as reference it's
> possible to be addressed bu allocating first and free later approach.
>=20
> It is common sense that the initialization of a device is in the probe
> function of the driver of the device. And the change will provide
> better unification of PCI controller code. The PCI controller is
> generic enough not to be taken care of at the platform area.
>=20
> Leo
Than lets look at going with that approach.. Be careful with impact on =
other users of swiotlb on PPC, I believe one 44x board uses swiotlb.
- k=
^ permalink raw reply
* [PATCH] dma/fsldma: fix a compilation warnings
From: Kumar Gala @ 2012-07-31 13:57 UTC (permalink / raw)
To: dan.j.williams; +Cc: vinod.koul, linuxppc-dev
drivers/dma/fsldma.c: In function 'fsl_dma_tx_submit':
drivers/dma/fsldma.c:409:15: warning: 'cookie' may be used uninitialized in this function
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
---
drivers/dma/fsldma.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/dma/fsldma.c b/drivers/dma/fsldma.c
index 8f84761..6194eb7 100644
--- a/drivers/dma/fsldma.c
+++ b/drivers/dma/fsldma.c
@@ -406,7 +406,7 @@ static dma_cookie_t fsl_dma_tx_submit(struct dma_async_tx_descriptor *tx)
struct fsl_desc_sw *desc = tx_to_fsl_desc(tx);
struct fsl_desc_sw *child;
unsigned long flags;
- dma_cookie_t cookie;
+ dma_cookie_t cookie = 0;
spin_lock_irqsave(&chan->desc_lock, flags);
--
1.7.9.7
^ permalink raw reply related
* RE: [PATCH 1/3] powerpc/mpic: finish supporting timer group B on Freescale chips
From: Sethi Varun-B16395 @ 2012-07-31 14:09 UTC (permalink / raw)
To: Wood Scott-B07421, Kumar Gala; +Cc: linuxppc-dev@lists.ozlabs.org
In-Reply-To: <4FFB17F8.3060507@freescale.com>
DQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogV29vZCBTY290dC1CMDc0
MjENCj4gU2VudDogTW9uZGF5LCBKdWx5IDA5LCAyMDEyIDExOjEyIFBNDQo+IFRvOiBLdW1hciBH
YWxhDQo+IENjOiBTZXRoaSBWYXJ1bi1CMTYzOTU7IGxpbnV4cHBjLWRldkBsaXN0cy5vemxhYnMu
b3JnDQo+IFN1YmplY3Q6IFJlOiBbUEFUQ0ggMS8zXSBwb3dlcnBjL21waWM6IGZpbmlzaCBzdXBw
b3J0aW5nIHRpbWVyIGdyb3VwIEIgb24NCj4gRnJlZXNjYWxlIGNoaXBzDQo+IA0KPiBPbiAwNy8w
OS8yMDEyIDEyOjM2IFBNLCBLdW1hciBHYWxhIHdyb3RlOg0KPiA+DQo+ID4gT24gSnVsIDksIDIw
MTIsIGF0IDExOjQzIEFNLCBTY290dCBXb29kIHdyb3RlOg0KPiA+DQo+ID4+IE9uIDA3LzA5LzIw
MTIgMDk6MTIgQU0sIEt1bWFyIEdhbGEgd3JvdGU6DQo+ID4+Pg0KPiA+Pj4gT24gSnVsIDksIDIw
MTIsIGF0IDM6NDUgQU0sIFZhcnVuIFNldGhpIHdyb3RlOg0KPiA+Pj4NCj4gPj4+PiBQcmV2aW91
c2x5LCB0aGVzZSBpbnRlcnJ1cHRzIHdvdWxkIGJlIG1hcHBlZCwgYnV0IHRoZSBvZmZzZXQNCj4g
Pj4+PiBjYWxjdWxhdGlvbiB3YXMgYnJva2VuLCBhbmQgb25seSB0aGUgZmlyc3QgZ3JvdXAgd2Fz
IGluaXRpYWxpemVkLg0KPiA+Pj4+DQo+ID4+Pj4gU2lnbmVkLW9mZi1ieTogU2NvdHQgV29vZCA8
c2NvdHR3b29kQGZyZWVzY2FsZS5jb20+DQo+ID4+Pj4gLS0tDQo+ID4+Pj4gYXJjaC9wb3dlcnBj
L2luY2x1ZGUvYXNtL21waWMuaCB8ICAgIDUgKysrDQo+ID4+Pj4gYXJjaC9wb3dlcnBjL3N5c2Rl
di9tcGljLmMgICAgICB8ICAgNTggKysrKysrKysrKysrKysrKysrKysrKysrKysrKy0NCj4gLS0t
LS0tLS0tLQ0KPiA+Pj4+IDIgZmlsZXMgY2hhbmdlZCwgNDcgaW5zZXJ0aW9ucygrKSwgMTYgZGVs
ZXRpb25zKC0pDQo+ID4+DQpTaWduZWQtb2ZmLWJ5OiBWYXJ1biBTZXRoaSA8dmFydW4uc2V0aGlA
ZnJlZXNjYWxlLmNvbT4NCg==
^ permalink raw reply
* Re: [PATCH v8 5/7] powerpc/85xx: add sleep and deep sleep support
From: Kumar Gala @ 2012-07-31 14:15 UTC (permalink / raw)
To: Zhao Chenhui; +Cc: scottwood, linuxppc-dev, linux-kernel
In-Reply-To: <1342788159-27529-6-git-send-email-chenhui.zhao@freescale.com>
On Jul 20, 2012, at 7:42 AM, Zhao Chenhui wrote:
> In sleep PM mode, the clocks of e500 core and unused IP blocks is
> turned off. IP blocks which are allowed to wake up the processor
> are still running.
>=20
> Some Freescale chips like MPC8536 and P1022 has deep sleep PM mode
> in addtion to the sleep PM mode.
>=20
> While in deep sleep PM mode, additionally, the power supply is
> removed from e500 core and most IP blocks. Only the blocks needed
> to wake up the chip out of deep sleep are ON.
>=20
> This patch supports 32-bit and 36-bit address space.
>=20
> The sleep mode is equal to the Standby state in Linux. The deep sleep
> mode is equal to the Suspend-to-RAM state of Linux Power Management.
>=20
> Command to enter sleep mode.
> echo standby > /sys/power/state
> Command to enter deep sleep mode.
> echo mem > /sys/power/state
>=20
> Signed-off-by: Dave Liu <daveliu@freescale.com>
> Signed-off-by: Li Yang <leoli@freescale.com>
> Signed-off-by: Jin Qing <b24347@freescale.com>
> Signed-off-by: Jerry Huang <Chang-Ming.Huang@freescale.com>
> Cc: Scott Wood <scottwood@freescale.com>
> Signed-off-by: Zhao Chenhui <chenhui.zhao@freescale.com>
> ---
> arch/powerpc/Kconfig | 2 +-
> arch/powerpc/include/asm/cacheflush.h | 2 +
> arch/powerpc/kernel/Makefile | 3 +
> arch/powerpc/kernel/l2cache_85xx.S | 56 +++
> arch/powerpc/platforms/85xx/Makefile | 2 +-
> arch/powerpc/platforms/85xx/sleep.S | 621 =
+++++++++++++++++++++++++++++++++
> arch/powerpc/sysdev/fsl_pmc.c | 98 +++++-
> arch/powerpc/sysdev/fsl_soc.h | 5 +
> 8 files changed, 769 insertions(+), 20 deletions(-)
> create mode 100644 arch/powerpc/kernel/l2cache_85xx.S
> create mode 100644 arch/powerpc/platforms/85xx/sleep.S
>=20
> diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
> index a7c6914..9d6de82 100644
> --- a/arch/powerpc/Kconfig
> +++ b/arch/powerpc/Kconfig
> @@ -665,7 +665,7 @@ config FSL_PCI
> config FSL_PMC
> bool
> default y
> - depends on SUSPEND && (PPC_85xx || PPC_86xx)
> + depends on SUSPEND && (PPC_85xx || PPC_86xx) && !PPC_E500MC
> help
> Freescale MPC85xx/MPC86xx power management controller support
> (suspend/resume). For MPC83xx see platforms/83xx/suspend.c
> diff --git a/arch/powerpc/include/asm/cacheflush.h =
b/arch/powerpc/include/asm/cacheflush.h
> index b843e35..6c5f1c2 100644
> --- a/arch/powerpc/include/asm/cacheflush.h
> +++ b/arch/powerpc/include/asm/cacheflush.h
> @@ -58,6 +58,8 @@ extern void flush_inval_dcache_range(unsigned long =
start, unsigned long stop);
> extern void flush_dcache_phys_range(unsigned long start, unsigned long =
stop);
> #endif
>=20
> +extern void flush_dcache_L1(void);
> +
> #define copy_to_user_page(vma, page, vaddr, dst, src, len) \
> do { \
> memcpy(dst, src, len); \
> diff --git a/arch/powerpc/kernel/Makefile =
b/arch/powerpc/kernel/Makefile
> index 83afacd..0ddef24 100644
> --- a/arch/powerpc/kernel/Makefile
> +++ b/arch/powerpc/kernel/Makefile
> @@ -64,6 +64,9 @@ obj-$(CONFIG_FA_DUMP) +=3D fadump.o
> ifeq ($(CONFIG_PPC32),y)
> obj-$(CONFIG_E500) +=3D idle_e500.o
> endif
> +ifneq ($(CONFIG_PPC_E500MC),y)
> +obj-$(CONFIG_PPC_85xx) +=3D l2cache_85xx.o
> +endif
why do we need this, beyond reduce code size on an e500mc kernel build? =
If so why isn't 85xx/sleep.S doing the same thing?
> obj-$(CONFIG_6xx) +=3D idle_6xx.o l2cr_6xx.o =
cpu_setup_6xx.o
> obj-$(CONFIG_TAU) +=3D tau_6xx.o
> obj-$(CONFIG_HIBERNATION) +=3D swsusp.o suspend.o
> diff --git a/arch/powerpc/kernel/l2cache_85xx.S =
b/arch/powerpc/kernel/l2cache_85xx.S
> new file mode 100644
> index 0000000..e920d69
> --- /dev/null
> +++ b/arch/powerpc/kernel/l2cache_85xx.S
> @@ -0,0 +1,56 @@
> +/*
> + * Copyright (C) 2009-2012 Freescale Semiconductor, Inc. All rights =
reserved.
> + * Scott Wood <scottwood@freescale.com>
> + * Dave Liu <daveliu@freescale.com>
> + * implement the L2 cache operations of e500 based L2 controller
> + *
> + * This program is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public License
> + * as published by the Free Software Foundation; either version
> + * 2 of the License, or (at your option) any later version.
> + */
> +
> +#include <asm/reg.h>
> +#include <asm/cputable.h>
> +#include <asm/ppc_asm.h>
> +#include <asm/asm-offsets.h>
> +
> +#define L2CTL_L2E 0x80000000
> +#define L2CTL_L2I 0x40000000
> +
> + .section .text
> +
> + /* r3 =3D virtual address of L2 controller, WIMG =3D 01xx */
> +_GLOBAL(flush_disable_L2)
> + /* It's a write-through cache, so only invalidation is needed. =
*/
> + mbar
> + isync
> + lwz r4, 0(r3)
> + li r5, 1
> + rlwimi r4, r5, 30, L2CTL_L2E | L2CTL_L2I
> + stw r4, 0(r3)
> +
> + /* Wait for the invalidate to finish */
> +1: lwz r4, 0(r3)
> + andis. r4, r4, L2CTL_L2I@h
> + bne 1b
> + mbar
> +
> + blr
> +
> + /* r3 =3D virtual address of L2 controller, WIMG =3D 01xx */
> +_GLOBAL(invalidate_enable_L2)
> + mbar
> + isync
> + lwz r4, 0(r3)
> + li r5, 3
> + rlwimi r4, r5, 30, L2CTL_L2E | L2CTL_L2I
> + stw r4, 0(r3)
> +
> + /* Wait for the invalidate to finish */
> +1: lwz r4, 0(r3)
> + andis. r4, r4, L2CTL_L2I@h
> + bne 1b
> + mbar
> +
> + blr
> diff --git a/arch/powerpc/platforms/85xx/Makefile =
b/arch/powerpc/platforms/85xx/Makefile
> index 3dfe811..405ab79 100644
> --- a/arch/powerpc/platforms/85xx/Makefile
> +++ b/arch/powerpc/platforms/85xx/Makefile
> @@ -3,7 +3,7 @@
> #
> obj-$(CONFIG_SMP) +=3D smp.o
>=20
> -obj-y +=3D common.o
> +obj-y +=3D common.o sleep.o
>=20
> obj-$(CONFIG_BSC9131_RDB) +=3D bsc913x_rdb.o
> obj-$(CONFIG_MPC8540_ADS) +=3D mpc85xx_ads.o
>=20
- k
^ permalink raw reply
* Re: [PATCH v8 7/7] powerpc/85xx: add support to JOG feature using cpufreq interface
From: Kumar Gala @ 2012-07-31 14:21 UTC (permalink / raw)
To: Zhao Chenhui; +Cc: scottwood, linuxppc-dev, linux-kernel
In-Reply-To: <1342788159-27529-8-git-send-email-chenhui.zhao@freescale.com>
On Jul 20, 2012, at 7:42 AM, Zhao Chenhui wrote:
> Some 85xx silicons like MPC8536 and P1022 have a JOG feature, which =
provides
> a dynamic mechanism to lower or raise the CPU core clock at runtime.
>=20
> This patch adds the support to change CPU frequency using the standard
> cpufreq interface. The ratio CORE to CCB can be 1:1(except MPC8536), =
3:2,
> 2:1, 5:2, 3:1, 7:2 and 4:1.
>=20
> Two CPU cores on P1022 must not in the low power state during the =
frequency
> transition. The driver uses a atomic counter to meet the requirement.
>=20
> The jog mode frequency transition process on the MPC8536 is similar to
> the deep sleep process. The driver need save the CPU state and restore
> it after CPU warm reset.
>=20
> Note:
> * The I/O peripherals such as PCIe and eTSEC may lose packets during
> the jog mode frequency transition.
> * The driver doesn't support MPC8536 Rev 1.0 due to a JOG erratum.
> Subsequent revisions of MPC8536 have corrected the erratum.
>=20
> Signed-off-by: Dave Liu <daveliu@freescale.com>
> Signed-off-by: Li Yang <leoli@freescale.com>
> Signed-off-by: Jerry Huang <Chang-Ming.Huang@freescale.com>
> Signed-off-by: Zhao Chenhui <chenhui.zhao@freescale.com>
> CC: Scott Wood <scottwood@freescale.com>
> ---
> arch/powerpc/platforms/85xx/Makefile | 1 +
> arch/powerpc/platforms/85xx/cpufreq-jog.c | 388 =
+++++++++++++++++++++++++++++
> arch/powerpc/platforms/Kconfig | 11 +
> arch/powerpc/sysdev/fsl_pmc.c | 3 +
> arch/powerpc/sysdev/fsl_soc.h | 2 +
> include/linux/cpu.h | 4 +
> 6 files changed, 409 insertions(+), 0 deletions(-)
> create mode 100644 arch/powerpc/platforms/85xx/cpufreq-jog.c
[snip]
> diff --git a/include/linux/cpu.h b/include/linux/cpu.h
> index 2e9b9eb..c1ba260 100644
> --- a/include/linux/cpu.h
> +++ b/include/linux/cpu.h
> @@ -145,6 +145,8 @@ void notify_cpu_starting(unsigned int cpu);
> extern void cpu_maps_update_begin(void);
> extern void cpu_maps_update_done(void);
>=20
> +extern void cpu_hotplug_disable_before_freeze(void);
> +extern void cpu_hotplug_enable_after_thaw(void);
> #else /* CONFIG_SMP */
>=20
> #define cpu_notifier(fn, pri) do { (void)(fn); } while (0)
> @@ -166,6 +168,8 @@ static inline void cpu_maps_update_done(void)
> {
> }
>=20
> +static inline void cpu_hotplug_disable_before_freeze(void) {}
> +static inline void cpu_hotplug_enable_after_thaw(void) {}
> #endif /* CONFIG_SMP */
> extern struct bus_type cpu_subsys;
Can you pull this change into a separate patch. I want an ACK by Rafael =
J. Wysocki on it.
- k=
^ permalink raw reply
* Re: [PATCH 1/3] powerpc/mpic: finish supporting timer group B on Freescale chips
From: Kumar Gala @ 2012-07-31 14:23 UTC (permalink / raw)
To: Sethi Varun-B16395; +Cc: Wood Scott-B07421, linuxppc-dev@lists.ozlabs.org list
In-Reply-To: <C5ECD7A89D1DC44195F34B25E172658D14C328@039-SN2MPN1-013.039d.mgd.msft.net>
On Jul 31, 2012, at 8:55 AM, Sethi Varun-B16395 wrote:
>
>
>> -----Original Message-----
>> From: Kumar Gala [mailto:galak@kernel.crashing.org]
>> Sent: Tuesday, July 31, 2012 7:20 PM
>> To: Sethi Varun-B16395
>> Cc: Wood Scott-B07421
>> Subject: Re: [PATCH 1/3] powerpc/mpic: finish supporting timer group B on
>> Freescale chips
>>
>>
>> On Jul 9, 2012, at 3:45 AM, Varun Sethi wrote:
>>
>>> Previously, these interrupts would be mapped, but the offset
>>> calculation was broken, and only the first group was initialized.
>>>
>>> Signed-off-by: Scott Wood <scottwood@freescale.com>
>>> ---
>>> arch/powerpc/include/asm/mpic.h | 5 +++
>>> arch/powerpc/sysdev/mpic.c | 58 ++++++++++++++++++++++++++++----
>> -------
>>> 2 files changed, 47 insertions(+), 16 deletions(-)
>>
>> Varun,
>>
>> Can you reply with a Signed-off-by to the thread.
>>
> Signed-off-by: Varun Sethi <varun.sethi@freescale.com>
thanks
applied to next
- k
^ permalink raw reply
* Re: [PATCH v8 1/7] powerpc/smp: use a struct epapr_spin_table to replace macros
From: Kumar Gala @ 2012-07-31 14:24 UTC (permalink / raw)
To: Zhao Chenhui; +Cc: scottwood, linuxppc-dev, linux-kernel
In-Reply-To: <1342788159-27529-2-git-send-email-chenhui.zhao@freescale.com>
On Jul 20, 2012, at 7:42 AM, Zhao Chenhui wrote:
> Signed-off-by: Zhao Chenhui <chenhui.zhao@freescale.com>
> ---
> arch/powerpc/platforms/85xx/smp.c | 46 =
++++++++++++++++++------------------
> 1 files changed, 23 insertions(+), 23 deletions(-)
applied to next
- k=
^ permalink raw reply
* Re: [PATCH v8 2/7] powerpc/smp: add generic_set_cpu_up() to set cpu_state as CPU_UP_PREPARE
From: Kumar Gala @ 2012-07-31 14:24 UTC (permalink / raw)
To: Zhao Chenhui; +Cc: scottwood, linuxppc-dev, linux-kernel
In-Reply-To: <1342788159-27529-3-git-send-email-chenhui.zhao@freescale.com>
On Jul 20, 2012, at 7:42 AM, Zhao Chenhui wrote:
> In the case of cpu hotplug, the cpu_state should be set to =
CPU_UP_PREPARE when kicking cpu.
> Otherwise, the cpu_state is always CPU_DEAD after calling =
generic_set_cpu_dead(), which
> makes the delay in generic_cpu_die() not happen.
>=20
> Signed-off-by: Zhao Chenhui <chenhui.zhao@freescale.com>
> ---
> arch/powerpc/include/asm/smp.h | 1 +
> arch/powerpc/kernel/smp.c | 12 +++++++++++-
> 2 files changed, 12 insertions(+), 1 deletions(-)
applied to next
- k=
^ permalink raw reply
* Re: [PATCH v8 3/7] powerpc/85xx: implement hardware timebase sync
From: Kumar Gala @ 2012-07-31 14:24 UTC (permalink / raw)
To: Zhao Chenhui; +Cc: scottwood, linuxppc-dev, linux-kernel
In-Reply-To: <1342788159-27529-4-git-send-email-chenhui.zhao@freescale.com>
On Jul 20, 2012, at 7:42 AM, Zhao Chenhui wrote:
> Do hardware timebase sync. Firstly, stop all timebases, and transfer
> the timebase value of the boot core to the other core. Finally,
> start all timebases.
>=20
> Only apply to dual-core chips, such as MPC8572, P2020, etc.
>=20
> Signed-off-by: Zhao Chenhui <chenhui.zhao@freescale.com>
> Signed-off-by: Li Yang <leoli@freescale.com>
> ---
> arch/powerpc/include/asm/fsl_guts.h | 2 +
> arch/powerpc/platforms/85xx/smp.c | 82 =
+++++++++++++++++++++++++++++++++++
> 2 files changed, 84 insertions(+), 0 deletions(-)
applied to next
- k=
^ permalink raw reply
* Re: [PATCH v8 4/7] powerpc/85xx: add HOTPLUG_CPU support
From: Kumar Gala @ 2012-07-31 14:24 UTC (permalink / raw)
To: Zhao Chenhui; +Cc: scottwood, linuxppc-dev, linux-kernel
In-Reply-To: <1342788159-27529-5-git-send-email-chenhui.zhao@freescale.com>
On Jul 20, 2012, at 7:42 AM, Zhao Chenhui wrote:
> Add support to disable and re-enable individual cores at runtime
> on MPC85xx/QorIQ SMP machines. Currently support e500v1/e500v2 core.
>=20
> MPC85xx machines use ePAPR spin-table in boot page for CPU kick-off.
> This patch uses the boot page from bootloader to boot core at runtime.
> It supports 32-bit and 36-bit physical address.
>=20
> Signed-off-by: Li Yang <leoli@freescale.com>
> Signed-off-by: Jin Qing <b24347@freescale.com>
> Signed-off-by: Zhao Chenhui <chenhui.zhao@freescale.com>
> ---
> arch/powerpc/Kconfig | 6 ++-
> arch/powerpc/include/asm/cacheflush.h | 2 +
> arch/powerpc/include/asm/smp.h | 1 +
> arch/powerpc/kernel/head_fsl_booke.S | 28 ++++++++++
> arch/powerpc/platforms/85xx/smp.c | 90 =
++++++++++++++++++++++++++++-----
> 5 files changed, 112 insertions(+), 15 deletions(-)
applied to next
- k=
^ permalink raw reply
* Re: [PATCH] powerpc/fsl: mpic timer driver
From: Kumar Gala @ 2012-07-31 14:31 UTC (permalink / raw)
To: Wang Dongsheng-B40534
Cc: paulus@samba.org, linuxppc-dev@lists.ozlabs.org,
Wood Scott-B07421
In-Reply-To: <ABB05CD9C9F68C46A5CEDC7F15439259DA4580@039-SN2MPN1-021.039d.mgd.msft.net>
On Jul 31, 2012, at 2:58 AM, Wang Dongsheng-B40534 wrote:
>=20
>=20
>> -----Original Message-----
>> From: Kumar Gala [mailto:galak@kernel.crashing.org]
>> Sent: Friday, July 27, 2012 9:14 PM
>> To: Wang Dongsheng-B40534
>> Cc: benh@kernel.crashing.org; paulus@samba.org; Wood Scott-B07421;
>> linuxppc-dev@lists.ozlabs.org
>> Subject: Re: [PATCH] powerpc/fsl: mpic timer driver
>>=20
>>=20
>> On Jul 27, 2012, at 1:20 AM, <Dongsheng.wang@freescale.com>
>> <Dongsheng.wang@freescale.com> wrote:
>>=20
>>> From: Wang Dongsheng <Dongsheng.Wang@freescale.com>
>>>=20
>>> Global timers A and B internal to the PIC. The two independent =
groups
>>> of global timer, group A and group B, are identical in their
>> functionality.
>>> The hardware timer generates an interrupt on every timer cycle.
>>> e.g
>>> Power management can use the hardware timer to wake up the machine.
>>>=20
>>> Signed-off-by: Wang Dongsheng <Dongsheng.Wang@freescale.com>
>>> Signed-off-by: Li Yang <leoli@freescale.com>
>>=20
>> How much of this is FSL specific vs openpic? OpenPIC spec's timer
>> support (only a single group).
>>=20
> [Wang Dongsheng] Yes, OpenPIC only a single group timer.
> FSL: add more register, features and group.
> This patch only to support FSL chip.
> "mpic_timer.c" -> "fsl_mpic_timer.c"
> I will modify the description of the patch. how about?
I'd rather we support both, can we not use the MPIC_FSL flag to deal =
with FSL specific behavior?
- k
^ permalink raw reply
* [PATCH 3/3 v3] powerpc/mpic: FSL MPIC error interrupt support.
From: Varun Sethi @ 2012-07-31 14:42 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Bogdan Hamciuc, Varun Sethi
All SOC device error interrupts are muxed and delivered to the core as a single
MPIC error interrupt. Currently all the device drivers requiring access to device
errors have to register for the MPIC error interrupt as a shared interrupt.
With this patch we add interrupt demuxing capability in the mpic driver, allowing
device drivers to register for their individual error interrupts. This is achieved
by handling error interrupts in a cascaded fashion.
MPIC error interrupt is handled by the "error_int_handler", which subsequently demuxes
it using the EISR and delivers it to the respective drivers.
The error interrupt capability is dependent on the MPIC EIMR register, which was
introduced in FSL MPIC version 4.1 (P4080 rev2). So, error interrupt demuxing capability
is dependent on the MPIC version and can be used for versions >= 4.1.
Signed-off-by: Varun Sethi <Varun.Sethi@freescale.com>
Signed-off-by: Bogdan Hamciuc <bogdan.hamciuc@freescale.com>
[In the initial version of the patch we were using handle_simple_irq
as the handler for cascaded error interrupts, this resulted
in issues in case of threaded isrs (with RT kernel). This issue was
debugged by Bogdan and decision was taken to use the handle_level_irq
handler]
---
arch/powerpc/include/asm/mpic.h | 13 +++
arch/powerpc/sysdev/Makefile | 2 +-
arch/powerpc/sysdev/fsl_mpic_err.c | 152 ++++++++++++++++++++++++++++++++++++
arch/powerpc/sysdev/mpic.c | 41 ++++++++++-
arch/powerpc/sysdev/mpic.h | 22 +++++
5 files changed, 228 insertions(+), 2 deletions(-)
create mode 100644 arch/powerpc/sysdev/fsl_mpic_err.c
diff --git a/arch/powerpc/include/asm/mpic.h b/arch/powerpc/include/asm/mpic.h
index e14d35d..5cc8000 100644
--- a/arch/powerpc/include/asm/mpic.h
+++ b/arch/powerpc/include/asm/mpic.h
@@ -118,6 +118,9 @@
#define MPIC_MAX_CPUS 32
#define MPIC_MAX_ISU 32
+#define MPIC_MAX_ERR 32
+#define MPIC_FSL_ERR_INT 16
+
/*
* Tsi108 implementation of MPIC has many differences from the original one
*/
@@ -270,6 +273,7 @@ struct mpic
struct irq_chip hc_ipi;
#endif
struct irq_chip hc_tm;
+ struct irq_chip hc_err;
const char *name;
/* Flags */
unsigned int flags;
@@ -283,6 +287,8 @@ struct mpic
/* vector numbers used for internal sources (ipi/timers) */
unsigned int ipi_vecs[4];
unsigned int timer_vecs[8];
+ /* vector numbers used for FSL MPIC error interrupts */
+ unsigned int err_int_vecs[MPIC_MAX_ERR];
/* Spurious vector to program into unused sources */
unsigned int spurious_vec;
@@ -306,6 +312,11 @@ struct mpic
struct mpic_reg_bank cpuregs[MPIC_MAX_CPUS];
struct mpic_reg_bank isus[MPIC_MAX_ISU];
+ /* ioremap'ed base for error interrupt registers */
+ u32 __iomem *err_regs;
+ /* error interrupt config */
+ u32 err_int_config_done;
+
/* Protected sources */
unsigned long *protected;
@@ -370,6 +381,8 @@ struct mpic
#define MPIC_NO_RESET 0x00004000
/* Freescale MPIC (compatible includes "fsl,mpic") */
#define MPIC_FSL 0x00008000
+/* Freescale MPIC supports EIMR (error interrupt mask register)*/
+#define MPIC_FSL_HAS_EIMR 0x00010000
/* MPIC HW modification ID */
#define MPIC_REGSET_MASK 0xf0000000
diff --git a/arch/powerpc/sysdev/Makefile b/arch/powerpc/sysdev/Makefile
index 1bd7ecb..a57600b 100644
--- a/arch/powerpc/sysdev/Makefile
+++ b/arch/powerpc/sysdev/Makefile
@@ -15,7 +15,7 @@ obj-$(CONFIG_PPC_DCR_NATIVE) += dcr-low.o
obj-$(CONFIG_PPC_PMI) += pmi.o
obj-$(CONFIG_U3_DART) += dart_iommu.o
obj-$(CONFIG_MMIO_NVRAM) += mmio_nvram.o
-obj-$(CONFIG_FSL_SOC) += fsl_soc.o
+obj-$(CONFIG_FSL_SOC) += fsl_soc.o fsl_mpic_err.o
obj-$(CONFIG_FSL_PCI) += fsl_pci.o $(fsl-msi-obj-y)
obj-$(CONFIG_FSL_PMC) += fsl_pmc.o
obj-$(CONFIG_FSL_LBC) += fsl_lbc.o
diff --git a/arch/powerpc/sysdev/fsl_mpic_err.c b/arch/powerpc/sysdev/fsl_mpic_err.c
new file mode 100644
index 0000000..1ebfa36
--- /dev/null
+++ b/arch/powerpc/sysdev/fsl_mpic_err.c
@@ -0,0 +1,152 @@
+/*
+ * Copyright (C) 2012 Freescale Semiconductor, Inc.
+ *
+ * Author: Varun Sethi <varun.sethi@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; version 2 of the
+ * License.
+ *
+ */
+
+#include <linux/irq.h>
+#include <linux/smp.h>
+#include <linux/interrupt.h>
+
+#include <asm/io.h>
+#include <asm/irq.h>
+#include <asm/mpic.h>
+
+#include "mpic.h"
+
+#define MPIC_ERR_INT_BASE 0x3900
+#define MPIC_ERR_INT_EISR 0x0000
+#define MPIC_ERR_INT_EIMR 0x0010
+
+static inline u32 mpic_fsl_err_read(u32 __iomem *base, unsigned int err_reg)
+{
+ return in_be32(base + (err_reg >> 2));
+}
+
+static inline void mpic_fsl_err_write(u32 __iomem *base, u32 value)
+{
+ out_be32(base + (MPIC_ERR_INT_EIMR >> 2), value);
+}
+
+static void fsl_mpic_mask_err(struct irq_data *d)
+{
+ u32 eimr;
+ struct mpic *mpic = irq_data_get_irq_chip_data(d);
+ unsigned int src = virq_to_hw(d->irq) - mpic->err_int_vecs[0];
+
+ eimr = mpic_fsl_err_read(mpic->err_regs, MPIC_ERR_INT_EIMR);
+ eimr |= (1 << (31 - src));
+ mpic_fsl_err_write(mpic->err_regs, eimr);
+}
+
+static void fsl_mpic_unmask_err(struct irq_data *d)
+{
+ u32 eimr;
+ struct mpic *mpic = irq_data_get_irq_chip_data(d);
+ unsigned int src = virq_to_hw(d->irq) - mpic->err_int_vecs[0];
+
+ eimr = mpic_fsl_err_read(mpic->err_regs, MPIC_ERR_INT_EIMR);
+ eimr &= ~(1 << (31 - src));
+ mpic_fsl_err_write(mpic->err_regs, eimr);
+}
+
+static struct irq_chip fsl_mpic_err_chip = {
+ .irq_disable = fsl_mpic_mask_err,
+ .irq_mask = fsl_mpic_mask_err,
+ .irq_unmask = fsl_mpic_unmask_err,
+};
+
+void mpic_setup_error_int(struct mpic *mpic, int intvec)
+{
+ int i;
+
+ mpic->err_regs = ioremap(mpic->paddr + MPIC_ERR_INT_BASE, 0x1000);
+ if (!mpic->err_regs) {
+ pr_err("could not map mpic error registers\n");
+ return;
+ }
+ mpic->hc_err = fsl_mpic_err_chip;
+ mpic->hc_err.name = mpic->name;
+ mpic->flags |= MPIC_FSL_HAS_EIMR;
+ /* allocate interrupt vectors for error interrupts */
+ for (i = MPIC_MAX_ERR - 1; i >= 0; i--)
+ mpic->err_int_vecs[i] = --intvec;
+
+}
+
+int mpic_map_error_int(struct mpic *mpic, unsigned int virq, irq_hw_number_t hw)
+{
+ if ((mpic->flags & MPIC_FSL_HAS_EIMR) &&
+ (hw >= mpic->err_int_vecs[0] &&
+ hw <= mpic->err_int_vecs[MPIC_MAX_ERR - 1])) {
+ WARN_ON(mpic->flags & MPIC_SECONDARY);
+
+ pr_debug("mpic: mapping as Error Interrupt\n");
+ irq_set_chip_data(virq, mpic);
+ irq_set_chip_and_handler(virq, &mpic->hc_err,
+ handle_level_irq);
+ return 1;
+ }
+
+ return 0;
+}
+
+static irqreturn_t fsl_error_int_handler(int irq, void *data)
+{
+ struct mpic *mpic = (struct mpic *) data;
+ u32 eisr, eimr;
+ int errint;
+ unsigned int cascade_irq;
+
+ eisr = mpic_fsl_err_read(mpic->err_regs, MPIC_ERR_INT_EISR);
+ eimr = mpic_fsl_err_read(mpic->err_regs, MPIC_ERR_INT_EIMR);
+
+ if (!(eisr & ~eimr))
+ return IRQ_NONE;
+
+ while (eisr) {
+ errint = __builtin_clz(eisr);
+ cascade_irq = irq_linear_revmap(mpic->irqhost,
+ mpic->err_int_vecs[errint]);
+ WARN_ON(cascade_irq == NO_IRQ);
+ if (cascade_irq != NO_IRQ) {
+ generic_handle_irq(cascade_irq);
+ } else {
+ eimr |= 1 << (31 - errint);
+ mpic_fsl_err_write(mpic->err_regs, eimr);
+ }
+ eisr &= ~(1 << (31 - errint));
+ }
+
+ return IRQ_HANDLED;
+}
+
+int mpic_err_int_init(struct mpic *mpic, irq_hw_number_t irqnum)
+{
+ unsigned int virq;
+ int ret;
+
+ virq = irq_create_mapping(mpic->irqhost, irqnum);
+ if (virq == NO_IRQ) {
+ pr_err("Error interrupt setup failed\n");
+ return 0;
+ }
+
+ /* Mask all error interrupts */
+ mpic_fsl_err_write(mpic->err_regs, ~0);
+
+ ret = request_irq(virq, fsl_error_int_handler, IRQF_NO_THREAD,
+ "mpic-error-int", mpic);
+ if (ret) {
+ pr_err("Failed to register error interrupt handler\n");
+ return 0;
+ }
+
+ return 1;
+}
diff --git a/arch/powerpc/sysdev/mpic.c b/arch/powerpc/sysdev/mpic.c
index 7e32db7..2a0b632 100644
--- a/arch/powerpc/sysdev/mpic.c
+++ b/arch/powerpc/sysdev/mpic.c
@@ -1026,6 +1026,9 @@ static int mpic_host_map(struct irq_domain *h, unsigned int virq,
return 0;
}
+ if (mpic_map_error_int(mpic, virq, hw))
+ return 0;
+
if (hw >= mpic->num_sources)
return -EINVAL;
@@ -1085,7 +1088,16 @@ static int mpic_host_xlate(struct irq_domain *h, struct device_node *ct,
*/
switch (intspec[2]) {
case 0:
- case 1: /* no EISR/EIMR support for now, treat as shared IRQ */
+ break;
+ case 1:
+ if (!mpic->err_int_config_done)
+ break;
+
+ if (intspec[3] >= ARRAY_SIZE(mpic->err_int_vecs))
+ return -EINVAL;
+
+ *out_hwirq = mpic->err_int_vecs[intspec[3]];
+
break;
case 2:
if (intspec[0] >= ARRAY_SIZE(mpic->ipi_vecs))
@@ -1302,6 +1314,8 @@ struct mpic * __init mpic_alloc(struct device_node *node,
mpic_map(mpic, mpic->paddr, &mpic->tmregs, MPIC_INFO(TIMER_BASE), 0x1000);
if (mpic->flags & MPIC_FSL) {
+ u32 brr1, version;
+
/*
* Yes, Freescale really did put global registers in the
* magic per-cpu area -- and they don't even show up in the
@@ -1309,6 +1323,26 @@ struct mpic * __init mpic_alloc(struct device_node *node,
*/
mpic_map(mpic, mpic->paddr, &mpic->thiscpuregs,
MPIC_CPU_THISBASE, 0x1000);
+
+ brr1 = _mpic_read(mpic->reg_type, &mpic->thiscpuregs,
+ MPIC_FSL_BRR1);
+ version = brr1 & MPIC_FSL_BRR1_VER;
+
+ /* Error interrupt mask register (EIMR) is required for
+ * handling individual device error interrupts. EIMR
+ * was added in MPIC version 4.1.
+ *
+ * Over here we reserve vector number space for error
+ * interrupt vectors. This space is stolen from the
+ * global vector number space, as in case of ipis
+ * and timer interrupts.
+ *
+ * Available vector space = intvec_top - 12, where 12
+ * is the number of vectors which have been consumed by
+ * ipis and timer interrupts.
+ */
+ if (version >= 0x401)
+ mpic_setup_error_int(mpic, intvec_top - 12);
}
/* Reset */
@@ -1474,6 +1508,11 @@ void __init mpic_init(struct mpic *mpic)
num_timers = 8;
}
+ /* FSL mpic error interrupt intialization */
+ if (mpic->flags & MPIC_FSL_HAS_EIMR)
+ mpic->err_int_config_done =
+ mpic_err_int_init(mpic, MPIC_FSL_ERR_INT);
+
/* Initialize timers to our reserved vectors and mask them for now */
for (i = 0; i < num_timers; i++) {
unsigned int offset = mpic_tm_offset(mpic, i);
diff --git a/arch/powerpc/sysdev/mpic.h b/arch/powerpc/sysdev/mpic.h
index 13f3e89..1a6995a 100644
--- a/arch/powerpc/sysdev/mpic.h
+++ b/arch/powerpc/sysdev/mpic.h
@@ -40,4 +40,26 @@ extern int mpic_set_affinity(struct irq_data *d,
const struct cpumask *cpumask, bool force);
extern void mpic_reset_core(int cpu);
+#ifdef CONFIG_FSL_SOC
+extern int mpic_map_error_int(struct mpic *mpic, unsigned int virq, irq_hw_number_t hw);
+extern int mpic_err_int_init(struct mpic *mpic, irq_hw_number_t irqnum);
+extern void mpic_setup_error_int(struct mpic *mpic, int intvec);
+#else
+static inline int mpic_map_error_int(struct mpic *mpic, unsigned int virq, irq_hw_number_t hw)
+{
+ return 0;
+}
+
+
+static inline int mpic_err_int_init(struct mpic *mpic, irq_hw_number_t irqnum)
+{
+ return -1;
+}
+
+static inline void mpic_setup_error_int(struct mpic *mpic, int intvec)
+{
+ return;
+}
+#endif
+
#endif /* _POWERPC_SYSDEV_MPIC_H */
--
1.7.4.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