* Re: [RFC v8 PATCH 04/20] memory-hotplug: offline and remove memory when removing the memory device
From: Andrew Morton @ 2012-08-31 20:55 UTC (permalink / raw)
To: wency
Cc: linux-s390, linux-ia64, len.brown, linux-acpi, linux-sh, x86,
linux-kernel, cmetcalf, linux-mm, isimatu.yasuaki, paulus,
minchan.kim, kosaki.motohiro, rientjes, sparclinux, cl,
linuxppc-dev, liuj97
In-Reply-To: <1346148027-24468-5-git-send-email-wency@cn.fujitsu.com>
On Tue, 28 Aug 2012 18:00:11 +0800
wency@cn.fujitsu.com wrote:
> +int remove_memory(int nid, u64 start, u64 size)
> +{
> + int ret = -EBUSY;
> + lock_memory_hotplug();
> + /*
> + * The memory might become online by other task, even if you offine it.
> + * So we check whether the cpu has been onlined or not.
I think you meant "memory", not "cpu".
Actually, "check whether any part of this memory range has been
onlined" would be better. If that is accurate ;)
> + */
> + if (!is_memblk_offline(start, size)) {
> + pr_warn("memory removing [mem %#010llx-%#010llx] failed, "
> + "because the memmory range is online\n",
> + start, start + size);
> + ret = -EAGAIN;
> + }
> +
> + unlock_memory_hotplug();
> + return ret;
> +
> +}
> +EXPORT_SYMBOL_GPL(remove_memory);
^ permalink raw reply
* Re: [RFC v8 PATCH 00/20] memory-hotplug: hot-remove physical memory
From: Andrew Morton @ 2012-08-31 20:49 UTC (permalink / raw)
To: wency
Cc: linux-s390, linux-ia64, len.brown, linux-acpi, linux-sh, x86,
linux-kernel, cmetcalf, linux-mm, isimatu.yasuaki, paulus,
minchan.kim, kosaki.motohiro, rientjes, sparclinux, cl,
linuxppc-dev, liuj97
In-Reply-To: <1346148027-24468-1-git-send-email-wency@cn.fujitsu.com>
On Tue, 28 Aug 2012 18:00:07 +0800
wency@cn.fujitsu.com wrote:
> This patch series aims to support physical memory hot-remove.
Have you had much review and testing feedback yet?
> The patches can free/remove the following things:
>
> - acpi_memory_info : [RFC PATCH 4/19]
> - /sys/firmware/memmap/X/{end, start, type} : [RFC PATCH 8/19]
> - iomem_resource : [RFC PATCH 9/19]
> - mem_section and related sysfs files : [RFC PATCH 10-11, 13-16/19]
> - page table of removed memory : [RFC PATCH 12/19]
> - node and related sysfs files : [RFC PATCH 18-19/19]
>
> If you find lack of function for physical memory hot-remove, please let me
> know.
I doubt if many people have hardware which permits physical memory
removal? How would you suggest that people with regular hardware can
test these chagnes?
> Known problems:
> 1. memory can't be offlined when CONFIG_MEMCG is selected.
That's quite a problem! Do you have a description of why this is the
case, and a plan for fixing it?
^ permalink raw reply
* RE: [PATCH v7 1/8] Talitos: Support for async_tx XOR offload
From: Liu Qiang-B32616 @ 2012-08-31 10:41 UTC (permalink / raw)
To: Geanta Neag Horia Ioan-B05471, linux-crypto@vger.kernel.org,
dan.j.williams@gmail.com, herbert@gondor.hengli.com.au,
davem@davemloft.net, linux-kernel@vger.kernel.org,
linuxppc-dev@lists.ozlabs.org
Cc: Li Yang-R58472, arnd@arndb.de, vinod.koul@intel.com,
gregkh@linuxfoundation.org, Phillips Kim-R1AAHA, Dan Williams
In-Reply-To: <FD18E5D573A8AB48A365D4D78185DE992E9EFF@039-SN1MPN1-001.039d.mgd.msft.net>
> -----Original Message-----
> From: Geanta Neag Horia Ioan-B05471
> Sent: Friday, August 31, 2012 6:39 PM
> To: Liu Qiang-B32616; linux-crypto@vger.kernel.org;
> dan.j.williams@gmail.com; herbert@gondor.hengli.com.au;
> davem@davemloft.net; linux-kernel@vger.kernel.org; linuxppc-
> dev@lists.ozlabs.org
> Cc: Li Yang-R58472; Phillips Kim-R1AAHA; vinod.koul@intel.com; Dan
> Williams; arnd@arndb.de; gregkh@linuxfoundation.org
> Subject: RE: [PATCH v7 1/8] Talitos: Support for async_tx XOR offload
>=20
> On Fri, 31 Aug 2012 06:08:05 +0300, Liu Qiang-B32616
> <B32616@freescale.com>
> wrote:
> > > -----Original Message-----
> > > From: Geanta Neag Horia Ioan-B05471
> > > Sent: Thursday, August 30, 2012 10:23 PM
> > > To: Liu Qiang-B32616; linux-crypto@vger.kernel.org;
> > > dan.j.williams@gmail.com; herbert@gondor.hengli.com.au;
> > > davem@davemloft.net; linux-kernel@vger.kernel.org; linuxppc-
> > > dev@lists.ozlabs.org
> > > Cc: Li Yang-R58472; Phillips Kim-R1AAHA; vinod.koul@intel.com;
> > > dan.j.williams@intel.com; arnd@arndb.de; gregkh@linuxfoundation.org;
> Liu
> > > Qiang-B32616
> > > Subject: RE: [PATCH v7 1/8] Talitos: Support for async_tx XOR offload
> > >
> > > On Thu, 9 Aug 2012 11:20:48 +0300, qiang.liu@freescale.com wrote:
> > > > From: Qiang Liu <qiang.liu@freescale.com>
> > > >
> > > > Expose Talitos's XOR functionality to be used for RAID parity
> > > > calculation via the Async_tx layer.
> > > >
> > > > Cc: Herbert Xu <herbert@gondor.apana.org.au>
> > > > Cc: David S. Miller <davem@davemloft.net>
> > > > Signed-off-by: Dipen Dudhat <Dipen.Dudhat@freescale.com>
> > > > Signed-off-by: Maneesh Gupta <Maneesh.Gupta@freescale.com>
> > > > Signed-off-by: Kim Phillips <kim.phillips@freescale.com>
> > > > Signed-off-by: Vishnu Suresh <Vishnu@freescale.com>
> > > > Signed-off-by: Qiang Liu <qiang.liu@freescale.com>
> > > > ---
> > > > drivers/crypto/Kconfig | 9 +
> > > > drivers/crypto/talitos.c | 413
> > > ++++++++++++++++++++++++++++++++++++++++++++++
> > > > drivers/crypto/talitos.h | 53 ++++++
> > > > 3 files changed, 475 insertions(+), 0 deletions(-)
> > >
>=20
> > > > +static int talitos_alloc_chan_resources(struct dma_chan *chan)
> > > > +{
> > > > + struct talitos_xor_chan *xor_chan;
> > > > + struct talitos_xor_desc *desc;
> > > > + LIST_HEAD(tmp_list);
> > > > + int i;
> > > > +
> > > > + xor_chan =3D container_of(chan, struct talitos_xor_chan,
> common);
> > > > +
> > > > + if (!list_empty(&xor_chan->free_desc))
> > > > + return xor_chan->total_desc;
> > > > +
> > > > + for (i =3D 0; i < TALITOS_MAX_DESCRIPTOR_NR; i++) {
> > > > + desc =3D talitos_xor_alloc_descriptor(xor_chan,
> > > > + GFP_KERNEL | GFP_DMA);
> > >
> > > talitos_xor_alloc_descriptor() is called here without holding
> > > the xor_chan->desc_lock and it increments xor_chan->total_desc.
> > > Isn't this an issue ?
> >
> > No, please refer to the code as below,
> > + list_add_tail(&desc->node, &tmp_list);
> >
> > The list is temporary list, it will be merged to xor_chan->free_desc in
> next step, here is protected
> > by lock,
> > + spin_lock_bh(&xor_chan->desc_lock);
> > + list_splice_init(&tmp_list, &xor_chan->free_desc);
> > + spin_unlock_bh(&xor_chan->desc_lock);
>=20
> I was not referring to the list, but to xor_chan->total_desc variable.
> The following access:
> talitos_alloc_chan_resources()->talitos_xor_alloc_descriptor()-
> >total_desc++
> is not protected by the xor_chan->desc_lock.
Ok, I will correct it in next series. Thanks.
^ permalink raw reply
* RE: [PATCH v7 1/8] Talitos: Support for async_tx XOR offload
From: Geanta Neag Horia Ioan-B05471 @ 2012-08-31 10:38 UTC (permalink / raw)
To: Liu Qiang-B32616, linux-crypto@vger.kernel.org,
dan.j.williams@gmail.com, herbert@gondor.hengli.com.au,
davem@davemloft.net, linux-kernel@vger.kernel.org,
linuxppc-dev@lists.ozlabs.org
Cc: Li Yang-R58472, arnd@arndb.de, vinod.koul@intel.com,
gregkh@linuxfoundation.org, Phillips Kim-R1AAHA, Dan Williams
In-Reply-To: <BCB48C05FCE8BC4D9E61E841ECBE6DB70FDB13@039-SN2MPN1-011.039d.mgd.msft.net>
On Fri, 31 Aug 2012 06:08:05 +0300, Liu Qiang-B32616 <B32616@freescale.com>
wrote:
> > -----Original Message-----
> > From: Geanta Neag Horia Ioan-B05471
> > Sent: Thursday, August 30, 2012 10:23 PM
> > To: Liu Qiang-B32616; linux-crypto@vger.kernel.org;
> > dan.j.williams@gmail.com; herbert@gondor.hengli.com.au;
> > davem@davemloft.net; linux-kernel@vger.kernel.org; linuxppc-
> > dev@lists.ozlabs.org
> > Cc: Li Yang-R58472; Phillips Kim-R1AAHA; vinod.koul@intel.com;
> > dan.j.williams@intel.com; arnd@arndb.de; gregkh@linuxfoundation.org; Li=
u
> > Qiang-B32616
> > Subject: RE: [PATCH v7 1/8] Talitos: Support for async_tx XOR offload
> >
> > On Thu, 9 Aug 2012 11:20:48 +0300, qiang.liu@freescale.com wrote:
> > > From: Qiang Liu <qiang.liu@freescale.com>
> > >
> > > Expose Talitos's XOR functionality to be used for RAID parity
> > > calculation via the Async_tx layer.
> > >
> > > Cc: Herbert Xu <herbert@gondor.apana.org.au>
> > > Cc: David S. Miller <davem@davemloft.net>
> > > Signed-off-by: Dipen Dudhat <Dipen.Dudhat@freescale.com>
> > > Signed-off-by: Maneesh Gupta <Maneesh.Gupta@freescale.com>
> > > Signed-off-by: Kim Phillips <kim.phillips@freescale.com>
> > > Signed-off-by: Vishnu Suresh <Vishnu@freescale.com>
> > > Signed-off-by: Qiang Liu <qiang.liu@freescale.com>
> > > ---
> > > drivers/crypto/Kconfig | 9 +
> > > drivers/crypto/talitos.c | 413
> > ++++++++++++++++++++++++++++++++++++++++++++++
> > > drivers/crypto/talitos.h | 53 ++++++
> > > 3 files changed, 475 insertions(+), 0 deletions(-)
> >
> > > +static int talitos_alloc_chan_resources(struct dma_chan *chan)
> > > +{
> > > + struct talitos_xor_chan *xor_chan;
> > > + struct talitos_xor_desc *desc;
> > > + LIST_HEAD(tmp_list);
> > > + int i;
> > > +
> > > + xor_chan =3D container_of(chan, struct talitos_xor_chan, common);
> > > +
> > > + if (!list_empty(&xor_chan->free_desc))
> > > + return xor_chan->total_desc;
> > > +
> > > + for (i =3D 0; i < TALITOS_MAX_DESCRIPTOR_NR; i++) {
> > > + desc =3D talitos_xor_alloc_descriptor(xor_chan,
> > > + GFP_KERNEL | GFP_DMA);
> >
> > talitos_xor_alloc_descriptor() is called here without holding
> > the xor_chan->desc_lock and it increments xor_chan->total_desc.
> > Isn't this an issue ?
>=20
> No, please refer to the code as below,
> + list_add_tail(&desc->node, &tmp_list);
>=20
> The list is temporary list, it will be merged to xor_chan->free_desc in n=
ext step, here is protected
> by lock,
> + spin_lock_bh(&xor_chan->desc_lock);
> + list_splice_init(&tmp_list, &xor_chan->free_desc);
> + spin_unlock_bh(&xor_chan->desc_lock);
I was not referring to the list, but to xor_chan->total_desc variable.
The following access:
talitos_alloc_chan_resources()->talitos_xor_alloc_descriptor()->total_desc+=
+
is not protected by the xor_chan->desc_lock.
^ permalink raw reply
* RE: [PATCH v7 1/8] Talitos: Support for async_tx XOR offload
From: Liu Qiang-B32616 @ 2012-08-31 3:08 UTC (permalink / raw)
To: Geanta Neag Horia Ioan-B05471, linux-crypto@vger.kernel.org,
dan.j.williams@gmail.com, herbert@gondor.hengli.com.au,
davem@davemloft.net, linux-kernel@vger.kernel.org,
linuxppc-dev@lists.ozlabs.org
Cc: Li Yang-R58472, arnd@arndb.de, vinod.koul@intel.com,
gregkh@linuxfoundation.org, Phillips Kim-R1AAHA, Dan Williams
In-Reply-To: <FD18E5D573A8AB48A365D4D78185DE992E5C0D@039-SN1MPN1-001.039d.mgd.msft.net>
> -----Original Message-----
> From: Geanta Neag Horia Ioan-B05471
> Sent: Thursday, August 30, 2012 10:23 PM
> To: Liu Qiang-B32616; linux-crypto@vger.kernel.org;
> dan.j.williams@gmail.com; herbert@gondor.hengli.com.au;
> davem@davemloft.net; linux-kernel@vger.kernel.org; linuxppc-
> dev@lists.ozlabs.org
> Cc: Li Yang-R58472; Phillips Kim-R1AAHA; vinod.koul@intel.com;
> dan.j.williams@intel.com; arnd@arndb.de; gregkh@linuxfoundation.org; Liu
> Qiang-B32616
> Subject: RE: [PATCH v7 1/8] Talitos: Support for async_tx XOR offload
>=20
> On Thu, 9 Aug 2012 11:20:48 +0300, qiang.liu@freescale.com wrote:
> > From: Qiang Liu <qiang.liu@freescale.com>
> >
> > Expose Talitos's XOR functionality to be used for RAID parity
> > calculation via the Async_tx layer.
> >
> > Cc: Herbert Xu <herbert@gondor.apana.org.au>
> > Cc: David S. Miller <davem@davemloft.net>
> > Signed-off-by: Dipen Dudhat <Dipen.Dudhat@freescale.com>
> > Signed-off-by: Maneesh Gupta <Maneesh.Gupta@freescale.com>
> > Signed-off-by: Kim Phillips <kim.phillips@freescale.com>
> > Signed-off-by: Vishnu Suresh <Vishnu@freescale.com>
> > Signed-off-by: Qiang Liu <qiang.liu@freescale.com>
> > ---
> > drivers/crypto/Kconfig | 9 +
> > drivers/crypto/talitos.c | 413
> ++++++++++++++++++++++++++++++++++++++++++++++
> > drivers/crypto/talitos.h | 53 ++++++
> > 3 files changed, 475 insertions(+), 0 deletions(-)
>=20
>=20
> > +static void talitos_xor_run_tx_complete_actions(struct
> talitos_xor_desc *desc,
> > + struct talitos_xor_chan *xor_chan)
> > +{
> > + struct device *dev =3D xor_chan->dev;
> > + dma_addr_t dest, addr;
> > + unsigned int src_cnt =3D desc->unmap_src_cnt;
> > + unsigned int len =3D desc->unmap_len;
> > + enum dma_ctrl_flags flags =3D desc->async_tx.flags;
> > + struct dma_async_tx_descriptor *tx =3D &desc->async_tx;
> > +
> > + /* unmap dma addresses */
> > + dest =3D desc->hwdesc.ptr[6].ptr;
> > + if (likely(!(flags & DMA_COMPL_SKIP_DEST_UNMAP)))
> > + dma_unmap_page(dev, dest, len, DMA_BIDIRECTIONAL);
> > +
> > + desc->idx =3D 6 - src_cnt;
> > + if (likely(!(flags & DMA_COMPL_SKIP_SRC_UNMAP))) {
> > + while(desc->idx < 6) {
> > + addr =3D desc->hwdesc.ptr[desc->idx++].ptr;
> > + if (addr =3D=3D dest)
> > + continue;
> > + dma_unmap_page(dev, addr, len, DMA_TO_DEVICE);
> > + }
> > + }
>=20
> No need for braces around the while block.
I will remove it.
>=20
> > + /* run dependent operations */
> > + dma_run_dependencies(tx);
> > +}
>=20
>=20
> > +static void talitos_release_xor(struct device *dev, struct
> talitos_desc *hwdesc,
> > + void *context, int error)
> > +{
> > + struct talitos_xor_desc *desc =3D context;
> > + struct talitos_xor_chan *xor_chan;
> > + dma_async_tx_callback callback;
> > + void *callback_param;
> > +
> > + if (unlikely(error))
> > + dev_err(dev, "xor operation: talitos error %d\n", error);
> > +
> > + xor_chan =3D container_of(desc->async_tx.chan, struct
> talitos_xor_chan,
> > + common);
> > + spin_lock_bh(&xor_chan->desc_lock);
> > + if (xor_chan->completed_cookie < desc->async_tx.cookie)
> > + xor_chan->completed_cookie =3D desc->async_tx.cookie;
> > +
> > + callback =3D desc->async_tx.callback;
> > + callback_param =3D desc->async_tx.callback_param;
> > +
> > + if (callback) {
> > + spin_unlock_bh(&xor_chan->desc_lock);
> > + callback(callback_param);
> > + spin_lock_bh(&xor_chan->desc_lock);
> > + }
>=20
> Since callback_param is used only here, maybe:
>=20
> if (callback) {
> void *callback_param =3D desc->async_tx.callback_param;
>=20
> spin_unlock_bh(&xor_chan->desc_lock);
> callback(callback_param);
> spin_lock_bh(&xor_chan->desc_lock);
> }
Fine. I will modify it in next.
>=20
> > +
> > + talitos_xor_run_tx_complete_actions(desc, xor_chan);
> > +
> > + list_del(&desc->node);
> > + list_add_tail(&desc->node, &xor_chan->free_desc);
> > + spin_unlock_bh(&xor_chan->desc_lock);
> > + if (!list_empty(&xor_chan->pending_q))
> > + talitos_process_pending(xor_chan);
> > +}
>=20
>=20
> > +static int talitos_alloc_chan_resources(struct dma_chan *chan)
> > +{
> > + struct talitos_xor_chan *xor_chan;
> > + struct talitos_xor_desc *desc;
> > + LIST_HEAD(tmp_list);
> > + int i;
> > +
> > + xor_chan =3D container_of(chan, struct talitos_xor_chan, common);
> > +
> > + if (!list_empty(&xor_chan->free_desc))
> > + return xor_chan->total_desc;
> > +
> > + for (i =3D 0; i < TALITOS_MAX_DESCRIPTOR_NR; i++) {
> > + desc =3D talitos_xor_alloc_descriptor(xor_chan,
> > + GFP_KERNEL | GFP_DMA);
>=20
> talitos_xor_alloc_descriptor() is called here without holding
> the xor_chan->desc_lock and it increments xor_chan->total_desc.
> Isn't this an issue ?
No, please refer to the code as below,=20
+ list_add_tail(&desc->node, &tmp_list);
The list is temporary list, it will be merged to xor_chan->free_desc in nex=
t step, here is protected by lock,
+ spin_lock_bh(&xor_chan->desc_lock);
+ list_splice_init(&tmp_list, &xor_chan->free_desc);
+ spin_unlock_bh(&xor_chan->desc_lock);
>=20
> > + if (!desc) {
> > + dev_err(xor_chan->common.device->dev,
> > + "Only %d initial descriptors\n", i);
> > + break;
> > + }
> > + list_add_tail(&desc->node, &tmp_list);
> > + }
> > +
> > + if (!i)
> > + return -ENOMEM;
> > +
> > + /* At least one desc is allocated */
> > + spin_lock_bh(&xor_chan->desc_lock);
> > + list_splice_init(&tmp_list, &xor_chan->free_desc);
> > + spin_unlock_bh(&xor_chan->desc_lock);
> > +
> > + return xor_chan->total_desc;
> > +}
>=20
>=20
> > +/**
> > + * talitos_register_dma_async - Initialize the Freescale XOR ADMA
> device
> > + * It is registered as a DMA device with the capability to perform
> > + * XOR operation with the Async_tx layer.
> > + * The various queues and channel resources are also allocated.
> > + */
> > +static int talitos_register_async_tx(struct device *dev, int
> max_xor_srcs)
> > +{
> > + struct talitos_private *priv =3D dev_get_drvdata(dev);
> > + struct dma_device *dma_dev =3D &priv->dma_dev_common;
> > + struct talitos_xor_chan *xor_chan;
> > + int err;
> > +
> > + xor_chan =3D kzalloc(sizeof(struct talitos_xor_chan), GFP_KERNEL);
> > + if (!xor_chan) {
> > + dev_err(dev, "unable to allocate xor channel\n");
> > + return -ENOMEM;
> > + }
> > +
> > + dma_dev->dev =3D dev;
> > + dma_dev->device_alloc_chan_resources =3D talitos_alloc_chan_resources=
;
> > + dma_dev->device_free_chan_resources =3D talitos_free_chan_resources;
> > + dma_dev->device_prep_dma_xor =3D talitos_prep_dma_xor;
> > + dma_dev->max_xor =3D max_xor_srcs;
> > + dma_dev->device_tx_status =3D talitos_is_tx_complete;
> > + dma_dev->device_issue_pending =3D talitos_issue_pending;
> > + INIT_LIST_HEAD(&dma_dev->channels);
> > + dma_cap_set(DMA_XOR, dma_dev->cap_mask);
> > +
> > + xor_chan->dev =3D dev;
> > + xor_chan->common.device =3D dma_dev;
> > + xor_chan->total_desc =3D 0;
> > + INIT_LIST_HEAD(&xor_chan->submit_q);
> > + INIT_LIST_HEAD(&xor_chan->pending_q);
> > + INIT_LIST_HEAD(&xor_chan->in_progress_q);
> > + INIT_LIST_HEAD(&xor_chan->free_desc);
> > + spin_lock_init(&xor_chan->desc_lock);
> > +
> > + list_add_tail(&xor_chan->common.device_node, &dma_dev->channels);
> > + dma_dev->chancnt++;
> > +
> > + err =3D dma_async_device_register(dma_dev);
> > + if (err) {
> > + dev_err(dev, "Unable to register XOR with Async_tx\n");
> > + goto err_out;
>=20
> Replace the jump with talitos_unregister_async_xor(dev) and
> remove code under err_out label.
No, here should be reserved, it should free xor_chan and remove "dma_dev->c=
hancnt++;".
Actually, I find most of code doesn't care this return value.
I will correct it in next.
>=20
> > + }
> > +
> > + return err;
> > +
> > +err_out:
> > + talitos_unregister_async_xor(dev);
> > + return err;
> > +}
> > +#endif
>=20
>=20
> > diff --git a/drivers/crypto/talitos.h b/drivers/crypto/talitos.h
> > index 61a1405..fc9d125 100644
> > --- a/drivers/crypto/talitos.h
> > +++ b/drivers/crypto/talitos.h
> > @@ -30,6 +30,7 @@
> >
> > #define TALITOS_TIMEOUT 100000
> > #define TALITOS_MAX_DATA_LEN 65535
> > +#define TALITOS_MAX_DESCRIPTOR_NR 256
>=20
> This refers only to xor descriptors, so renaming it similar to
> TALITOS_MAX_XOR_DESCRIPTOR_NR would make sense.
I remember it is applied to other descriptors, I will check it again, if no=
t, I will rename it as you suggested.
>=20
> Besides these:
> 1. As Dan Williams mentioned, you should explain why you are using
> both spin_lock_bh and spin_lock_irqsave on the same lock.
I'm waiting for Dan's feedback about this patch, I will add description or =
correct it with other comments together.
> 2. I don't see anything added to talitos_remove(). Shouldn't
> talitos_unregister_async_xor() be called? Anything else?
> Have you tested with talitos built as a module?
My fault, it should be added in talitos_remove(); I will correct it in next=
.
Thanks for your review.
>=20
> Horia
^ permalink raw reply
* RE: [PATCH V10] powerpc/fsl-pci: Unify pci/pcie initialization code
From: Jia Hongtao-B38951 @ 2012-08-31 2:25 UTC (permalink / raw)
To: Kumar Gala
Cc: Wood Scott-B07421, linuxppc-dev@lists.ozlabs.org, Li Yang-R58472
In-Reply-To: <0B7DF7C8-A3E9-4C9A-8734-B5ACEF52D258@kernel.crashing.org>
> -----Original Message-----
> From: Kumar Gala [mailto:galak@kernel.crashing.org]
> Sent: Friday, August 31, 2012 12:54 AM
> To: Jia Hongtao-B38951
> Cc: linuxppc-dev@lists.ozlabs.org; Li Yang-R58472; Wood Scott-B07421
> Subject: Re: [PATCH V10] powerpc/fsl-pci: Unify pci/pcie initialization
> code
>=20
>=20
> On Aug 28, 2012, at 2:44 AM, Jia Hongtao wrote:
>=20
> > We unified the Freescale pci/pcie initialization by changing the
> > fsl_pci to a platform driver. In previous PCI code architecture the
> > initialization routine is called at board_setup_arch stage. Now the
> > initialization is done in probe function which is architectural
> > better. Also It's convenient for adding PM support for PCI controller
> in later patch.
> >
> > Now we registered pci controllers as platform devices. So we combine
> > two initialization code as one platform driver.
> >
> > Signed-off-by: Jia Hongtao <B38951@freescale.com>
> > Signed-off-by: Li Yang <leoli@freescale.com>
> > Signed-off-by: Chunhe Lan <Chunhe.Lan@freescale.com>
> > ---
> > Changes for V10:
> > * Just update comments for mpc85xx_cds_pci_assign_primary
>=20
> What do we have to say w/regards to Ben's comment about breaking of
> pci_fixup_final by moving to a platform driver?
>=20
> - k
If Ben mean the fixup order I have already gave some explanations as follow=
:
I have already done some investigations and the sequence of fixup
(including early, header, final) will not be changed in platform driver.
We register and init PCI controllers as platform devices at arch_initcall
stage and PCI scanning (pcibios_init) is at subsys_initcall stage in which
early and header fixup will be done in right sequence. The final fixup will
be start at rootfs_initcall stage which is later than early and header fixu=
p.
- Hongtao.
^ permalink raw reply
* Re: [PATCH] clk: Make the generic clock API available by default
From: Stephen Warren @ 2012-08-30 23:40 UTC (permalink / raw)
To: Mark Brown
Cc: linux-mips, Guan Xuetao, Russell King, Arnd Bergmann,
linux-kernel, Ralf Baechle, Paul Mackerras, Haavard Skinnemoen,
linuxppc-dev, linux-arm-kernel, Hans-Christian Egtvedt
In-Reply-To: <20120830171918.GE4356@opensource.wolfsonmicro.com>
On 08/30/12 10:19, Mark Brown wrote:
> On Wed, Aug 29, 2012 at 02:49:34PM -0700, Stephen Warren wrote:
>> On 08/28/12 13:35, Mark Brown wrote:
>
>>> @@ -674,6 +676,7 @@ config ARCH_TEGRA
>>> select GENERIC_CLOCKEVENTS
>>> select GENERIC_GPIO
>>> select HAVE_CLK
>>> + select HAVE_CUSTOM_CLK
>
>> For 3.7, Tegra will switch to the common clock framework. I think
>> this patch would then disable that. How should we resolve this -
>> rebase the Tegra common-clk tree on top of any branch containing
>> this patch in order to remove that select statement?
>
> I'd expect this to be applied on a separate branch so you should be able
> to rebase your conversion on top of it or merge it into your branch
> which should deal with things well enough I think?
That should work.
^ permalink raw reply
* Re: Moving target
From: Michael Ellerman @ 2012-08-30 23:30 UTC (permalink / raw)
To: Guillaume Dargaud; +Cc: linuxppc-dev
In-Reply-To: <503F7555.5060404@lpsc.in2p3.fr>
On Thu, 2012-08-30 at 16:14 +0200, Guillaume Dargaud wrote:
> Hello all,
Hi Guillaume,
> I don't understand the part about address 0x00000030. Does it mean I'm
> trying to wrongly access physical/virtual address 0x30 somewhere in my code?
> [ 16.666231] Unable to handle kernel paging request for data at address 0x00000030
So yes some code is trying to access address 0x30, that is typically a
symptom of dereferencing a NULL pointer.
The 0x30 can be a clue in that it is probably accessing an element of a
structure that is 0x30 past the base of the struct.
> [ 16.673599] Faulting instruction address: 0xc0116fc0
This can be useful if you have the vmlinux around you can look at the
exact instruction that caused the fault.
> [ 16.678495] Oops: Kernel access of bad area, sig: 11 [#1]
> [ 16.683745] Xilinx Virtex
> [ 16.686337] Modules linked in: xad(+)
> [ 16.689978] NIP: c0116fc0 LR: c939a0f8 CTR: c0116fa8
> [ 16.694912] REGS: c789fd90 TRAP: 0300 Not tainted (3.0.0-14.1-build3+)
> [ 16.701629] MSR: 00029030 <EE,ME,CE,IR,DR> CR: 42000022 XER: 20000000
> [ 16.708199] DEAR: 00000030, ESR: 00000000
> [ 16.712185] TASK = c7851420[281] 'insmod' THREAD: c789e000
> [ 16.717441] GPR00: c939a0f8 c789fe40 c7851420 c9397b70 000046d7 ffffffff c0110314 00000000
> [ 16.725736] GPR08: c0337380 00000000 00004000 c0116fa8 22000024 100b99d4 ffffffff ffffffff
> [ 16.734030] GPR16: ffffffff ffffffff 100b5aed bfa54388 100844d8 100844b8 000007a0 00000000
> [ 16.742324] GPR24: c0047edc 00000124 0000001c c9390000 c93973da c9397b08 c93971e8 c9397b70
> [ 16.750870] NIP [c0116fc0] driver_register+0x18/0x144
That is the exact instruction that faulted. You can see it's not
actually in your code, it's in driver_register().
> ///////////////////////////////////////////////////////////////////////////////
> // There should be something in:
> // ll /sys/devices/plb.0/c9800000.xps-acqui-data
> static const struct of_device_id xad_device_id[] = {
> { .compatible = "xlnx,xps-acqui-data-4.00.a" }, // Must match the DTS
> {}
> };
>
> MODULE_DEVICE_TABLE(of, xad_device_id); // Is this necessary ?
>
> static struct device_driver xad_driver = {
> .probe = xad_driver_probe,
> .remove = xad_driver_remove,
> .name = "xad-driver",
> .of_match_table = xad_device_id,
> };
> static int __init xad_init(void) {
> first = MKDEV (my_major, my_minor);
> register_chrdev_region(first, count, DEVNAME);
> my_cdev = cdev_alloc ();
>
> cdev_init(my_cdev, &fops);
> rc=cdev_add (my_cdev, first, count);
>
> rc = driver_register(&xad_driver);
>
> printk(KERN_INFO SD "Driver ready!\n" FL);
> return 0;
> }
I don't think you should be using driver_register().
I think instead you want this to be a platform_driver, and use
platform_driver_register() ?
If you grep for platform_driver_register() in arch/powerpc you will see
several examples.
cheers
^ permalink raw reply
* Re: [PATCH][v2] powerpc/mm: using two zones for freescale 64 bit kernel
From: Kumar Gala @ 2012-08-30 20:49 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: Mingkai Hu, linuxppc-dev@lists.ozlabs.org list, Shaohui Xie,
Chen Yuanquan
In-Reply-To: <1345805425-3829-1-git-send-email-Shaohui.Xie@freescale.com>
On Aug 24, 2012, at 5:50 AM, Shaohui Xie wrote:
> PowerPC platform only supports ZONE_DMA zone for 64bit kernel, so all =
the
> memory will be put into this zone. If the memory size is greater than
> the device's DMA capability and device uses dma_alloc_coherent to =
allocate
> memory, it will get an address which is over the device's DMA =
addressing,
> the device will fail.
>=20
> So we split the memory to two zones: zone ZONE_DMA32 & ZONE_NORMAL, =
since
> we already allocate PCICSRBAR/PEXCSRBAR right below the 4G boundary =
(if the
> lowest PCI address is above 4G), so we constrain the DMA zone =
ZONE_DMA32
> to 2GB, also, we clear flag __GFP_DMA & __GFP_DMA32 and set =
__GFP_DMA32 only
> if the device's dma_mask < total memory size. By doing this, devices =
which
> cannot DMA all the memory will be limited to ZONE_DMA32, but devices =
which
> can DMA all the memory will not be affected by this limitation.
>=20
> Signed-off-by: Shaohui Xie <Shaohui.Xie@freescale.com>
> Signed-off-by: Mingkai Hu <Mingkai.hu@freescale.com>
> Signed-off-by: Chen Yuanquan <B41889@freescale.com>
> ---
> changes for v2:
> 1. use a config option for using two zones (ZONE_DMA32 & ZONE_NORMAL) =
in
> freescale 64 bit kernel.
>=20
> arch/powerpc/Kconfig | 3 +++
> arch/powerpc/kernel/dma.c | 15 +++++++++++++++
> arch/powerpc/mm/mem.c | 4 ++++
> 3 files changed, 22 insertions(+), 0 deletions(-)
Ben,
What's the feeling of doing this on ppc64 always?=20
- k
>=20
> diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
> index 352f416..a96fbbb 100644
> --- a/arch/powerpc/Kconfig
> +++ b/arch/powerpc/Kconfig
> @@ -629,6 +629,9 @@ config ZONE_DMA
> bool
> default y
>=20
> +config ZONE_DMA32
> + def_bool (PPC64 && PPC_FSL_BOOK3E)
> +
> config NEED_DMA_MAP_STATE
> def_bool (PPC64 || NOT_COHERENT_CACHE)
>=20
> diff --git a/arch/powerpc/kernel/dma.c b/arch/powerpc/kernel/dma.c
> index 355b9d8..cbf5ac1 100644
> --- a/arch/powerpc/kernel/dma.c
> +++ b/arch/powerpc/kernel/dma.c
> @@ -41,9 +41,24 @@ void *dma_direct_alloc_coherent(struct device *dev, =
size_t size,
> #else
> struct page *page;
> int node =3D dev_to_node(dev);
> +#ifdef CONFIG_ZONE_DMA32
> + phys_addr_t top_ram_pfn =3D memblock_end_of_DRAM();
>=20
> + /*
> + * check for crappy device which has dma_mask < ZONE_DMA, and
> + * we are not going to support it, just warn and fail.
> + */
> + if (*dev->dma_mask < DMA_BIT_MASK(31)) {
> + dev_err(dev, "Unsupported dma_mask 0x%llx\n", =
*dev->dma_mask);
> + return NULL;
> + }
> /* ignore region specifiers */
> + flag &=3D ~(__GFP_HIGHMEM | __GFP_DMA | __GFP_DMA32);
> + if (*dev->dma_mask < top_ram_pfn - 1)
> + flag |=3D __GFP_DMA32;
> +#else
> flag &=3D ~(__GFP_HIGHMEM);
> +#endif
>=20
> page =3D alloc_pages_node(node, flag, get_order(size));
> if (page =3D=3D NULL)
> diff --git a/arch/powerpc/mm/mem.c b/arch/powerpc/mm/mem.c
> index baaafde..2a11e49 100644
> --- a/arch/powerpc/mm/mem.c
> +++ b/arch/powerpc/mm/mem.c
> @@ -280,6 +280,10 @@ void __init paging_init(void)
> #ifdef CONFIG_HIGHMEM
> max_zone_pfns[ZONE_DMA] =3D lowmem_end_addr >> PAGE_SHIFT;
> max_zone_pfns[ZONE_HIGHMEM] =3D top_of_ram >> PAGE_SHIFT;
> +#elif defined CONFIG_ZONE_DMA32
> + max_zone_pfns[ZONE_DMA32] =3D min_t(phys_addr_t, top_of_ram,
> + 1ull << 31) >> PAGE_SHIFT;
> + max_zone_pfns[ZONE_NORMAL] =3D top_of_ram >> PAGE_SHIFT;
> #else
> max_zone_pfns[ZONE_DMA] =3D top_of_ram >> PAGE_SHIFT;
> #endif
> --=20
> 1.6.4
>=20
>=20
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev
^ permalink raw reply
* Re: [PATCH] clk: Make the generic clock API available by default
From: Mark Brown @ 2012-08-30 17:19 UTC (permalink / raw)
To: Stephen Warren
Cc: linux-mips, Guan Xuetao, Russell King, Arnd Bergmann,
linux-kernel, Ralf Baechle, Paul Mackerras, Haavard Skinnemoen,
linuxppc-dev, linux-arm-kernel, Hans-Christian Egtvedt
In-Reply-To: <503E8E6E.1010101@wwwdotorg.org>
On Wed, Aug 29, 2012 at 02:49:34PM -0700, Stephen Warren wrote:
> On 08/28/12 13:35, Mark Brown wrote:
> >@@ -674,6 +676,7 @@ config ARCH_TEGRA
> > select GENERIC_CLOCKEVENTS
> > select GENERIC_GPIO
> > select HAVE_CLK
> >+ select HAVE_CUSTOM_CLK
> For 3.7, Tegra will switch to the common clock framework. I think
> this patch would then disable that. How should we resolve this -
> rebase the Tegra common-clk tree on top of any branch containing
> this patch in order to remove that select statement?
I'd expect this to be applied on a separate branch so you should be able
to rebase your conversion on top of it or merge it into your branch
which should deal with things well enough I think?
^ permalink raw reply
* Re: [PATCH V10] powerpc/fsl-pci: Unify pci/pcie initialization code
From: Kumar Gala @ 2012-08-30 16:53 UTC (permalink / raw)
To: Jia Hongtao; +Cc: B07421, linuxppc-dev
In-Reply-To: <1346139848-28021-1-git-send-email-B38951@freescale.com>
On Aug 28, 2012, at 2:44 AM, Jia Hongtao wrote:
> We unified the Freescale pci/pcie initialization by changing the =
fsl_pci
> to a platform driver. In previous PCI code architecture the =
initialization
> routine is called at board_setup_arch stage. Now the initialization is =
done
> in probe function which is architectural better. Also It's convenient =
for
> adding PM support for PCI controller in later patch.
>=20
> Now we registered pci controllers as platform devices. So we combine =
two
> initialization code as one platform driver.
>=20
> Signed-off-by: Jia Hongtao <B38951@freescale.com>
> Signed-off-by: Li Yang <leoli@freescale.com>
> Signed-off-by: Chunhe Lan <Chunhe.Lan@freescale.com>
> ---
> Changes for V10:
> * Just update comments for mpc85xx_cds_pci_assign_primary
What do we have to say w/regards to Ben's comment about breaking of =
pci_fixup_final by moving to a platform driver?
- k=
^ permalink raw reply
* Re: [PATCH] powerpc: add adt7461 thermal monitor support to applicable boards
From: Kumar Gala @ 2012-08-30 16:07 UTC (permalink / raw)
To: Jia Hongtao; +Cc: linuxppc-dev
In-Reply-To: <1346119255-19031-1-git-send-email-B38951@freescale.com>
On Aug 27, 2012, at 9:00 PM, Jia Hongtao wrote:
> Add thermal monitor support to following boards:
> P1022DS, MPC8536DS, P2041RDB, P3041DS, P4080DS, P5020DS, P5040DS
>
> Signed-off-by: Jia Hongtao <B38951@freescale.com>
> Signed-off-by: Li Yang <leoli@freescale.com>
> ---
> arch/powerpc/boot/dts/mpc8536ds.dtsi | 4 ++++
> arch/powerpc/boot/dts/p1022ds.dtsi | 4 ++++
> arch/powerpc/boot/dts/p2041rdb.dts | 4 ++++
> arch/powerpc/boot/dts/p3041ds.dts | 4 ++++
> arch/powerpc/boot/dts/p4080ds.dts | 4 ++++
> arch/powerpc/boot/dts/p5020ds.dts | 4 ++++
> arch/powerpc/boot/dts/p5040ds.dts | 4 ++++
> 7 files changed, 28 insertions(+), 0 deletions(-)
applied to next
- k
^ permalink raw reply
* Re: [PATCH] powerpc/8544ds: add partition table for norflash
From: Kumar Gala @ 2012-08-30 16:07 UTC (permalink / raw)
To: <Dongsheng.wang@freescale.com>; +Cc: linuxppc-dev
In-Reply-To: <1346209249-5049-1-git-send-email-Dongsheng.wang@freescale.com>
On Aug 28, 2012, at 10:00 PM, <Dongsheng.wang@freescale.com> =
<Dongsheng.wang@freescale.com> wrote:
> From: Wang Dongsheng <Dongsheng.Wang@freescale.com>
>=20
> create partition table for norflash.
>=20
> Signed-off-by: Wang Dongsheng <Dongsheng.Wang@freescale.com>
> ---
>=20
> arch/powerpc/boot/dts/mpc8544ds.dts | 4 ++-
> arch/powerpc/boot/dts/mpc8544ds.dtsi | 38 =
++++++++++++++++++++++++++++++++++
> 2 files changed, 41 insertions(+), 1 deletions(-)
Added read-only to u-boot partition.
applied to next
- k=
^ permalink raw reply
* Re: Moving target
From: Andreas Schwab @ 2012-08-30 15:25 UTC (permalink / raw)
To: Guillaume Dargaud; +Cc: linuxppc-dev
In-Reply-To: <503F7555.5060404__42569.4412122995$1346339823$gmane$org@lpsc.in2p3.fr>
Guillaume Dargaud <dargaud@lpsc.in2p3.fr> writes:
> I don't understand the part about address 0x00000030. Does it mean I'm
> trying to wrongly access physical/virtual address 0x30 somewhere in my
> code?
More likely a NULL pointer dereference.
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
* Moving target
From: Guillaume Dargaud @ 2012-08-30 14:14 UTC (permalink / raw)
To: linuxppc-dev
Hello all,
I had a homebrew driver that compiled and ran well on 2.6.38 and I
recently upgraded to the latest xilinx kernel and had some trouble
recompiling without adjustments (of_driver/driver,
of_platform_driver/platform_driver and some such).
But now, after those adjustments, it crashes on run.
My first generic question is: is there a clean canonical example of how
to write each part (module init/exit, /dev handling, probing, physical
memory access, interrupt handling, etc) of a basic driver ? Because each
upgrade breaks my code and as driver writing is only one of my duties, I
have a hard time keeping up with the moving target of the
requirements... To say that books are obsolete is an understatement.
And now to the specifics:
[ 16.655868] {xad_init 519} Module xad: loading...
[ 16.661122] {xad_init 528} Module xad: Major=241, Minor=0, Count=1
[ 16.666231] Unable to handle kernel paging request for data at
address 0x00000030
[ 16.673599] Faulting instruction address: 0xc0116fc0
[ 16.678495] Oops: Kernel access of bad area, sig: 11 [#1]
[ 16.683745] Xilinx Virtex
[ 16.686337] Modules linked in: xad(+)
[ 16.689978] NIP: c0116fc0 LR: c939a0f8 CTR: c0116fa8
[ 16.694912] REGS: c789fd90 TRAP: 0300 Not tainted (3.0.0-14.1-build3+)
[ 16.701629] MSR: 00029030 <EE,ME,CE,IR,DR> CR: 42000022 XER: 20000000
[ 16.708199] DEAR: 00000030, ESR: 00000000
[ 16.712185] TASK = c7851420[281] 'insmod' THREAD: c789e000
[ 16.717441] GPR00: c939a0f8 c789fe40 c7851420 c9397b70 000046d7
ffffffff c0110314 00000000
[ 16.725736] GPR08: c0337380 00000000 00004000 c0116fa8 22000024
100b99d4 ffffffff ffffffff
[ 16.734030] GPR16: ffffffff ffffffff 100b5aed bfa54388 100844d8
100844b8 000007a0 00000000
[ 16.742324] GPR24: c0047edc 00000124 0000001c c9390000 c93973da
c9397b08 c93971e8 c9397b70
[ 16.750870] NIP [c0116fc0] driver_register+0x18/0x144
[ 16.755901] LR [c939a0f8] xad_init+0xf8/0x1e8 [xad]
[ 16.760638] Call Trace:
[ 16.763119] [c789fe40] [c93973da] xad_device_id+0x1da/0xfffffef8
[xad] (unreliable)
[ 16.770719] [c789fe60] [c939a0f8] xad_init+0xf8/0x1e8 [xad]
[ 16.776230] [c789fe80] [c0002508] do_one_initcall+0xe0/0x1c0
[ 16.781871] [c789feb0] [c004a08c] sys_init_module+0x15cc/0x17c0
[ 16.787720] [c789ff40] [c000c95c] ret_from_syscall+0x0/0x3c
[ 16.793212] Instruction dump:
[ 16.796155] 80630034 4bfcd669 80010014 38210010 7c0803a6 4e800020
9421ffe0 7c0802a6
[ 16.803842] bf410008 90010024 7c7f1b78 81230004
[ 16.808257] 7c000034 5400d97e 0f000000
[ 16.813362] ---[ end trace e40dbcf43f9d5d57 ]---
I don't understand the part about address 0x00000030. Does it mean I'm
trying to wrongly access physical/virtual address 0x30 somewhere in my code?
Here are the very basics from my code (I've removed all printk, error
checking and what the driver itself does for clarity). I really need a
hand with the changes of of_something:
static dev_t first;
static unsigned int count = 1;
static int my_major = 241, my_minor = 0;
struct cdev *my_cdev=NULL;
typedef struct XadDevice {
// struct platform_device *of_dev;
struct device *dev;
int irq;
resource_size_t hw_phy_base, hw_length; // Address of the IP resource
void *hw_virt; // Virtual of above
#ifdef DEBUG
void *buffer_virt; // Virtual address of the above
#endif
struct resource *hw_region; // Nothing is done with this
...
} tXadDevice;
tXadDevice Xad;
static irqreturn_t XadIsr(int irq, void *dev_id) { ... }
static int xad_driver_probe(struct device * dev)
struct resource res;
struct device_node *dn = dev->of_node;
int rc=0;
printk(KERN_INFO SD "Probing %s\n" FL, dn->full_name);
rc = of_address_to_resource(dn, 0, &res);
Xad.irq = irq_of_parse_and_map(dn, 0);
rc=request_irq(Xad.irq, XadIsr, IRQF_TRIGGER_RISING /* |
IRQF_DISABLED*/ | IRQF_SHARED | IRQF_SAMPLE_RANDOM, "XadIsr", &Xad);
init_waitqueue_head(&Xad.wait);
Xad.hw_region = request_mem_region((unsigned int)Xad.hw_phy_base,
(unsigned int)(Xad.hw_length), "xps-acqui-data");
Xad.hw_virt= ioremap( (unsigned int)Xad.hw_phy_base, (unsigned
int)(Xad.hw_length) );
dev_set_drvdata(Xad.dev, &Xad);
return 0;
}
///////////////////////////////////////////////////////////////////////////////
// There should be something in:
// ll /sys/devices/plb.0/c9800000.xps-acqui-data
static const struct of_device_id xad_device_id[] = {
{ .compatible = "xlnx,xps-acqui-data-4.00.a" }, // Must match the DTS
{}
};
MODULE_DEVICE_TABLE(of, xad_device_id); // Is this necessary ?
static struct device_driver xad_driver = {
.probe = xad_driver_probe,
.remove = xad_driver_remove,
.name = "xad-driver",
.of_match_table = xad_device_id,
};
...
static struct file_operations fops = {
.owner = THIS_MODULE,
.read = xad_read,
.open = xad_open,
.release = xad_close,
.unlocked_ioctl = xad_ioctl,
};
static int __init xad_init(void) {
first = MKDEV (my_major, my_minor);
register_chrdev_region(first, count, DEVNAME);
my_cdev = cdev_alloc ();
cdev_init(my_cdev, &fops);
rc=cdev_add (my_cdev, first, count);
rc = driver_register(&xad_driver);
printk(KERN_INFO SD "Driver ready!\n" FL);
return 0;
}
module_init(xad_init);
Thanks for reading so far !!!
--
Guillaume Dargaud
http://www.gdargaud.net/
^ permalink raw reply
* RE: [PATCH v7 1/8] Talitos: Support for async_tx XOR offload
From: Geanta Neag Horia Ioan-B05471 @ 2012-08-30 14:23 UTC (permalink / raw)
To: Liu Qiang-B32616, linux-crypto@vger.kernel.org,
dan.j.williams@gmail.com, herbert@gondor.hengli.com.au,
davem@davemloft.net, linux-kernel@vger.kernel.org,
linuxppc-dev@lists.ozlabs.org
Cc: Li Yang-R58472, arnd@arndb.de, vinod.koul@intel.com,
gregkh@linuxfoundation.org, Phillips Kim-R1AAHA, Liu Qiang-B32616,
dan.j.williams@intel.com
In-Reply-To: <1344500448-10927-1-git-send-email-qiang.liu@freescale.com>
On Thu, 9 Aug 2012 11:20:48 +0300, qiang.liu@freescale.com wrote:
> From: Qiang Liu <qiang.liu@freescale.com>
>=20
> Expose Talitos's XOR functionality to be used for RAID parity
> calculation via the Async_tx layer.
>=20
> Cc: Herbert Xu <herbert@gondor.apana.org.au>
> Cc: David S. Miller <davem@davemloft.net>
> Signed-off-by: Dipen Dudhat <Dipen.Dudhat@freescale.com>
> Signed-off-by: Maneesh Gupta <Maneesh.Gupta@freescale.com>
> Signed-off-by: Kim Phillips <kim.phillips@freescale.com>
> Signed-off-by: Vishnu Suresh <Vishnu@freescale.com>
> Signed-off-by: Qiang Liu <qiang.liu@freescale.com>
> ---
> drivers/crypto/Kconfig | 9 +
> drivers/crypto/talitos.c | 413 ++++++++++++++++++++++++++++++++++++++++=
++++++
> drivers/crypto/talitos.h | 53 ++++++
> 3 files changed, 475 insertions(+), 0 deletions(-)
> +static void talitos_xor_run_tx_complete_actions(struct talitos_xor_desc =
*desc,
> + struct talitos_xor_chan *xor_chan)
> +{
> + struct device *dev =3D xor_chan->dev;
> + dma_addr_t dest, addr;
> + unsigned int src_cnt =3D desc->unmap_src_cnt;
> + unsigned int len =3D desc->unmap_len;
> + enum dma_ctrl_flags flags =3D desc->async_tx.flags;
> + struct dma_async_tx_descriptor *tx =3D &desc->async_tx;
> +
> + /* unmap dma addresses */
> + dest =3D desc->hwdesc.ptr[6].ptr;
> + if (likely(!(flags & DMA_COMPL_SKIP_DEST_UNMAP)))
> + dma_unmap_page(dev, dest, len, DMA_BIDIRECTIONAL);
> +
> + desc->idx =3D 6 - src_cnt;
> + if (likely(!(flags & DMA_COMPL_SKIP_SRC_UNMAP))) {
> + while(desc->idx < 6) {
> + addr =3D desc->hwdesc.ptr[desc->idx++].ptr;
> + if (addr =3D=3D dest)
> + continue;
> + dma_unmap_page(dev, addr, len, DMA_TO_DEVICE);
> + }
> + }
No need for braces around the while block.
> + /* run dependent operations */
> + dma_run_dependencies(tx);
> +}
> +static void talitos_release_xor(struct device *dev, struct talitos_desc =
*hwdesc,
> + void *context, int error)
> +{
> + struct talitos_xor_desc *desc =3D context;
> + struct talitos_xor_chan *xor_chan;
> + dma_async_tx_callback callback;
> + void *callback_param;
> +
> + if (unlikely(error))
> + dev_err(dev, "xor operation: talitos error %d\n", error);
> +
> + xor_chan =3D container_of(desc->async_tx.chan, struct talitos_xor_chan,
> + common);
> + spin_lock_bh(&xor_chan->desc_lock);
> + if (xor_chan->completed_cookie < desc->async_tx.cookie)
> + xor_chan->completed_cookie =3D desc->async_tx.cookie;
> +
> + callback =3D desc->async_tx.callback;
> + callback_param =3D desc->async_tx.callback_param;
> +
> + if (callback) {
> + spin_unlock_bh(&xor_chan->desc_lock);
> + callback(callback_param);
> + spin_lock_bh(&xor_chan->desc_lock);
> + }
Since callback_param is used only here, maybe:
if (callback) {
void *callback_param =3D desc->async_tx.callback_param;
spin_unlock_bh(&xor_chan->desc_lock);
callback(callback_param);
spin_lock_bh(&xor_chan->desc_lock);
}
> +
> + talitos_xor_run_tx_complete_actions(desc, xor_chan);
> +
> + list_del(&desc->node);
> + list_add_tail(&desc->node, &xor_chan->free_desc);
> + spin_unlock_bh(&xor_chan->desc_lock);
> + if (!list_empty(&xor_chan->pending_q))
> + talitos_process_pending(xor_chan);
> +}
> +static int talitos_alloc_chan_resources(struct dma_chan *chan)
> +{
> + struct talitos_xor_chan *xor_chan;
> + struct talitos_xor_desc *desc;
> + LIST_HEAD(tmp_list);
> + int i;
> +
> + xor_chan =3D container_of(chan, struct talitos_xor_chan, common);
> +
> + if (!list_empty(&xor_chan->free_desc))
> + return xor_chan->total_desc;
> +
> + for (i =3D 0; i < TALITOS_MAX_DESCRIPTOR_NR; i++) {
> + desc =3D talitos_xor_alloc_descriptor(xor_chan,
> + GFP_KERNEL | GFP_DMA);
talitos_xor_alloc_descriptor() is called here without holding
the xor_chan->desc_lock and it increments xor_chan->total_desc.
Isn't this an issue ?
> + if (!desc) {
> + dev_err(xor_chan->common.device->dev,
> + "Only %d initial descriptors\n", i);
> + break;
> + }
> + list_add_tail(&desc->node, &tmp_list);
> + }
> +
> + if (!i)
> + return -ENOMEM;
> +
> + /* At least one desc is allocated */
> + spin_lock_bh(&xor_chan->desc_lock);
> + list_splice_init(&tmp_list, &xor_chan->free_desc);
> + spin_unlock_bh(&xor_chan->desc_lock);
> +
> + return xor_chan->total_desc;
> +}
> +/**
> + * talitos_register_dma_async - Initialize the Freescale XOR ADMA device
> + * It is registered as a DMA device with the capability to perform
> + * XOR operation with the Async_tx layer.
> + * The various queues and channel resources are also allocated.
> + */
> +static int talitos_register_async_tx(struct device *dev, int max_xor_src=
s)
> +{
> + struct talitos_private *priv =3D dev_get_drvdata(dev);
> + struct dma_device *dma_dev =3D &priv->dma_dev_common;
> + struct talitos_xor_chan *xor_chan;
> + int err;
> +
> + xor_chan =3D kzalloc(sizeof(struct talitos_xor_chan), GFP_KERNEL);
> + if (!xor_chan) {
> + dev_err(dev, "unable to allocate xor channel\n");
> + return -ENOMEM;
> + }
> +
> + dma_dev->dev =3D dev;
> + dma_dev->device_alloc_chan_resources =3D talitos_alloc_chan_resources;
> + dma_dev->device_free_chan_resources =3D talitos_free_chan_resources;
> + dma_dev->device_prep_dma_xor =3D talitos_prep_dma_xor;
> + dma_dev->max_xor =3D max_xor_srcs;
> + dma_dev->device_tx_status =3D talitos_is_tx_complete;
> + dma_dev->device_issue_pending =3D talitos_issue_pending;
> + INIT_LIST_HEAD(&dma_dev->channels);
> + dma_cap_set(DMA_XOR, dma_dev->cap_mask);
> +
> + xor_chan->dev =3D dev;
> + xor_chan->common.device =3D dma_dev;
> + xor_chan->total_desc =3D 0;
> + INIT_LIST_HEAD(&xor_chan->submit_q);
> + INIT_LIST_HEAD(&xor_chan->pending_q);
> + INIT_LIST_HEAD(&xor_chan->in_progress_q);
> + INIT_LIST_HEAD(&xor_chan->free_desc);
> + spin_lock_init(&xor_chan->desc_lock);
> +
> + list_add_tail(&xor_chan->common.device_node, &dma_dev->channels);
> + dma_dev->chancnt++;
> +
> + err =3D dma_async_device_register(dma_dev);
> + if (err) {
> + dev_err(dev, "Unable to register XOR with Async_tx\n");
> + goto err_out;
Replace the jump with talitos_unregister_async_xor(dev) and
remove code under err_out label.
> + }
> +
> + return err;
> +
> +err_out:
> + talitos_unregister_async_xor(dev);
> + return err;
> +}
> +#endif
> diff --git a/drivers/crypto/talitos.h b/drivers/crypto/talitos.h
> index 61a1405..fc9d125 100644
> --- a/drivers/crypto/talitos.h
> +++ b/drivers/crypto/talitos.h
> @@ -30,6 +30,7 @@
>=20
> #define TALITOS_TIMEOUT 100000
> #define TALITOS_MAX_DATA_LEN 65535
> +#define TALITOS_MAX_DESCRIPTOR_NR 256
This refers only to xor descriptors, so renaming it similar to
TALITOS_MAX_XOR_DESCRIPTOR_NR would make sense.
Besides these:
1. As Dan Williams mentioned, you should explain why you are using
both spin_lock_bh and spin_lock_irqsave on the same lock.
2. I don't see anything added to talitos_remove(). Shouldn't
talitos_unregister_async_xor() be called? Anything else?
Have you tested with talitos built as a module?
Horia
^ permalink raw reply
* [PATCH] i2c-mpc: Wait for STOP to hit the bus
From: Joakim Tjernlund @ 2012-08-30 10:40 UTC (permalink / raw)
To: linux-i2c, linuxppc-dev
mpc_i2c_stop() only initiates STOP but does not wait for it to
hit the I2C bus. This is a problem when using I2C devices which
uses fairly long clock stretching just before STOP if you also
have an i2c-mux which may switch to another bus before STOP has
been processed.
Signed-off-by: Joakim Tjernlund <Joakim.Tjernlund@transmode.se>
---
drivers/i2c/busses/i2c-mpc.c | 18 +++++++++++++++++-
1 files changed, 17 insertions(+), 1 deletions(-)
diff --git drivers/i2c/busses/i2c-mpc.c drivers/i2c/busses/i2c-mpc.c
index 3d31879..c08f287 100644
--- drivers/i2c/busses/i2c-mpc.c
+++ drivers/i2c/busses/i2c-mpc.c
@@ -574,7 +574,23 @@ static int mpc_xfer(struct i2c_adapter *adap, struct i2c_msg *msgs, int num)
mpc_write(i2c, pmsg->addr, pmsg->buf, pmsg->len, i);
}
}
- mpc_i2c_stop(i2c);
+ mpc_i2c_stop(i2c); /* Initiate STOP */
+ orig_jiffies = jiffies;
+ /* Wait until STOP is seen, allow up to 1 s */
+ while (readb(i2c->base + MPC_I2C_SR) & CSR_MBB) {
+ if (time_after(jiffies, orig_jiffies + HZ)) {
+ u8 status = readb(i2c->base + MPC_I2C_SR);
+
+ dev_dbg(i2c->dev, "timeout\n");
+ if ((status & (CSR_MCF | CSR_MBB | CSR_RXAK)) != 0) {
+ writeb(status & ~CSR_MAL,
+ i2c->base + MPC_I2C_SR);
+ mpc_i2c_fixup(i2c);
+ }
+ return -EIO;
+ }
+ cond_resched();
+ }
return (ret < 0) ? ret : num;
}
--
1.7.8.6
^ permalink raw reply related
* [PATCH] powerpc/mpc52xx_lpbfifo: optionally defer fifo transfer start
From: Anatolij Gustschin @ 2012-08-30 7:33 UTC (permalink / raw)
To: linuxppc-dev; +Cc: dzu
Currently fifo transfer is started when submitting a transfer
request. Add posibility to defer the fifo transfer and start it
later by calling additional function. This change is backward
compatible, the behaviour of mpc52xx_lpbfifo_submit() is the same
for previous driver users, so there is no need to adapt them.
Signed-off-by: Anatolij Gustschin <agust@denx.de>
---
arch/powerpc/include/asm/mpc52xx.h | 2 +
arch/powerpc/platforms/52xx/mpc52xx_lpbfifo.c | 35 ++++++++++++++++++++++++-
2 files changed, 36 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/include/asm/mpc52xx.h b/arch/powerpc/include/asm/mpc52xx.h
index 1f41382..0acc7c7 100644
--- a/arch/powerpc/include/asm/mpc52xx.h
+++ b/arch/powerpc/include/asm/mpc52xx.h
@@ -307,6 +307,7 @@ struct mpc52xx_lpbfifo_request {
size_t size;
size_t pos; /* current position of transfer */
int flags;
+ int defer_xfer_start;
/* What to do when finished */
void (*callback)(struct mpc52xx_lpbfifo_request *);
@@ -323,6 +324,7 @@ struct mpc52xx_lpbfifo_request {
extern int mpc52xx_lpbfifo_submit(struct mpc52xx_lpbfifo_request *req);
extern void mpc52xx_lpbfifo_abort(struct mpc52xx_lpbfifo_request *req);
extern void mpc52xx_lpbfifo_poll(void);
+extern int mpc52xx_lpbfifo_start_xfer(struct mpc52xx_lpbfifo_request *req);
/* mpc52xx_pic.c */
extern void mpc52xx_init_irq(void);
diff --git a/arch/powerpc/platforms/52xx/mpc52xx_lpbfifo.c b/arch/powerpc/platforms/52xx/mpc52xx_lpbfifo.c
index d61fb1c..2351f9e 100644
--- a/arch/powerpc/platforms/52xx/mpc52xx_lpbfifo.c
+++ b/arch/powerpc/platforms/52xx/mpc52xx_lpbfifo.c
@@ -170,7 +170,8 @@ static void mpc52xx_lpbfifo_kick(struct mpc52xx_lpbfifo_request *req)
out_be32(lpbfifo.regs + LPBFIFO_REG_CONTROL, bit_fields);
/* Kick it off */
- out_8(lpbfifo.regs + LPBFIFO_REG_PACKET_SIZE, 0x01);
+ if (!lpbfifo.req->defer_xfer_start)
+ out_8(lpbfifo.regs + LPBFIFO_REG_PACKET_SIZE, 0x01);
if (dma)
bcom_enable(lpbfifo.bcom_cur_task);
}
@@ -421,6 +422,38 @@ int mpc52xx_lpbfifo_submit(struct mpc52xx_lpbfifo_request *req)
}
EXPORT_SYMBOL(mpc52xx_lpbfifo_submit);
+int mpc52xx_lpbfifo_start_xfer(struct mpc52xx_lpbfifo_request *req)
+{
+ unsigned long flags;
+
+ if (!lpbfifo.regs)
+ return -ENODEV;
+
+ spin_lock_irqsave(&lpbfifo.lock, flags);
+
+ /*
+ * If the req pointer is already set and a transfer was
+ * started on submit, then this transfer is in progress
+ */
+ if (lpbfifo.req && !lpbfifo.req->defer_xfer_start) {
+ spin_unlock_irqrestore(&lpbfifo.lock, flags);
+ return -EBUSY;
+ }
+
+ /*
+ * If the req was previously submitted but not
+ * started, start it now
+ */
+ if (lpbfifo.req && lpbfifo.req == req &&
+ lpbfifo.req->defer_xfer_start) {
+ out_8(lpbfifo.regs + LPBFIFO_REG_PACKET_SIZE, 0x01);
+ }
+
+ spin_unlock_irqrestore(&lpbfifo.lock, flags);
+ return 0;
+}
+EXPORT_SYMBOL(mpc52xx_lpbfifo_start_xfer);
+
void mpc52xx_lpbfifo_abort(struct mpc52xx_lpbfifo_request *req)
{
unsigned long flags;
--
1.7.1
^ permalink raw reply related
* [PATCH v2 1/2] powerpc/mpc5200: add dts files for ifm camera machines
From: Anatolij Gustschin @ 2012-08-30 7:31 UTC (permalink / raw)
To: linuxppc-dev; +Cc: devicetree-discuss, dzu
In-Reply-To: <1345822779-32020-1-git-send-email-agust@denx.de>
Add common o2d dtsi file to reuse it for other configurations.
Add machine compatible string to mpc5200 simple platform file.
Add dts files for O2D, O2I, O2MNT, O2DNT2, O2D300 and O3DNT boards.
Signed-off-by: Anatolij Gustschin <agust@denx.de>
---
v2:
- changed flash node description in o2d.dts and tested it
on this board
- fixed white spaces in o2d.dts and o2mnt.dts files
arch/powerpc/boot/dts/o2d.dts | 47 +++++++++
arch/powerpc/boot/dts/o2d.dtsi | 139 ++++++++++++++++++++++++++
arch/powerpc/boot/dts/o2d300.dts | 52 ++++++++++
arch/powerpc/boot/dts/o2dnt2.dts | 48 +++++++++
arch/powerpc/boot/dts/o2i.dts | 33 ++++++
arch/powerpc/boot/dts/o2mnt.dts | 33 ++++++
arch/powerpc/boot/dts/o3dnt.dts | 48 +++++++++
arch/powerpc/platforms/52xx/mpc5200_simple.c | 1 +
8 files changed, 401 insertions(+), 0 deletions(-)
create mode 100644 arch/powerpc/boot/dts/o2d.dts
create mode 100644 arch/powerpc/boot/dts/o2d.dtsi
create mode 100644 arch/powerpc/boot/dts/o2d300.dts
create mode 100644 arch/powerpc/boot/dts/o2dnt2.dts
create mode 100644 arch/powerpc/boot/dts/o2i.dts
create mode 100644 arch/powerpc/boot/dts/o2mnt.dts
create mode 100644 arch/powerpc/boot/dts/o3dnt.dts
diff --git a/arch/powerpc/boot/dts/o2d.dts b/arch/powerpc/boot/dts/o2d.dts
new file mode 100644
index 0000000..9f6dd4d
--- /dev/null
+++ b/arch/powerpc/boot/dts/o2d.dts
@@ -0,0 +1,47 @@
+/*
+ * O2D Device Tree Source
+ *
+ * Copyright (C) 2012 DENX Software Engineering
+ * Anatolij Gustschin <agust@denx.de>
+ *
+ * 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/ "o2d.dtsi"
+
+/ {
+ model = "ifm,o2d";
+ compatible = "ifm,o2d";
+
+ memory {
+ reg = <0x00000000 0x08000000>; // 128MB
+ };
+
+ localbus {
+ ranges = <0 0 0xfc000000 0x02000000
+ 3 0 0xe3000000 0x00100000>;
+
+ flash@0,0 {
+ compatible = "cfi-flash";
+ reg = <0 0 0x02000000>;
+ bank-width = <2>;
+ device-width = <2>;
+ #size-cells = <1>;
+ #address-cells = <1>;
+
+ partition@60000 {
+ label = "kernel";
+ reg = <0x00060000 0x00260000>;
+ read-only;
+ };
+ /* o2d specific partitions */
+ partition@2c0000 {
+ label = "o2d user defined";
+ reg = <0x002c0000 0x01d40000>;
+ };
+ };
+ };
+};
diff --git a/arch/powerpc/boot/dts/o2d.dtsi b/arch/powerpc/boot/dts/o2d.dtsi
new file mode 100644
index 0000000..3444eb8
--- /dev/null
+++ b/arch/powerpc/boot/dts/o2d.dtsi
@@ -0,0 +1,139 @@
+/*
+ * O2D base Device Tree Source
+ *
+ * Copyright (C) 2012 DENX Software Engineering
+ * Anatolij Gustschin <agust@denx.de>
+ *
+ * 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/ "mpc5200b.dtsi"
+
+/ {
+ model = "ifm,o2d";
+ compatible = "ifm,o2d";
+
+ memory {
+ reg = <0x00000000 0x04000000>; // 64MB
+ };
+
+ soc5200@f0000000 {
+
+ gpio_simple: gpio@b00 {
+ };
+
+ timer@600 { // General Purpose Timer
+ #gpio-cells = <2>;
+ gpio-controller;
+ fsl,has-wdt;
+ fsl,wdt-on-boot = <0>;
+ };
+
+ timer@610 {
+ #gpio-cells = <2>;
+ gpio-controller;
+ };
+
+ timer7: timer@670 {
+ };
+
+ rtc@800 {
+ status = "disabled";
+ };
+
+ psc@2000 { // PSC1
+ compatible = "fsl,mpc5200b-psc-spi","fsl,mpc5200-psc-spi";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ cell-index = <0>;
+
+ spidev@0 {
+ compatible = "spidev";
+ spi-max-frequency = <250000>;
+ reg = <0>;
+ };
+ };
+
+ psc@2200 { // PSC2
+ status = "disabled";
+ };
+
+ psc@2400 { // PSC3
+ status = "disabled";
+ };
+
+ psc@2600 { // PSC4
+ compatible = "fsl,mpc5200b-psc-uart","fsl,mpc5200-psc-uart";
+ };
+
+ psc@2800 { // PSC5
+ compatible = "fsl,mpc5200b-psc-uart","fsl,mpc5200-psc-uart";
+ };
+
+ psc@2c00 { // PSC6
+ status = "disabled";
+ };
+
+ ethernet@3000 {
+ phy-handle = <&phy0>;
+ };
+
+ mdio@3000 {
+ phy0: ethernet-phy@0 {
+ reg = <0>;
+ };
+ };
+
+ sclpc@3c00 {
+ compatible = "fsl,mpc5200-lpbfifo";
+ reg = <0x3c00 0x60>;
+ interrupts = <3 23 0>;
+ };
+ };
+
+ localbus {
+ ranges = <0 0 0xff000000 0x01000000
+ 3 0 0xe3000000 0x00100000>;
+
+ // flash device at LocalPlus Bus CS0
+ flash@0,0 {
+ compatible = "cfi-flash";
+ reg = <0 0 0x01000000>;
+ bank-width = <1>;
+ device-width = <2>;
+ #size-cells = <1>;
+ #address-cells = <1>;
+ no-unaligned-direct-access;
+
+ /* common layout for all machines */
+ partition@0 {
+ label = "u-boot";
+ reg = <0x00000000 0x00040000>;
+ read-only;
+ };
+ partition@40000 {
+ label = "env";
+ reg = <0x00040000 0x00020000>;
+ read-only;
+ };
+ };
+
+ csi@3,0 {
+ compatible = "ifm,o2d-csi";
+ reg = <3 0 0x00100000>;
+ ifm,csi-clk-handle = <&timer7>;
+ gpios = <&gpio_simple 23 0 /* imag_capture */
+ &gpio_simple 26 0 /* imag_reset */
+ &gpio_simple 29 0>; /* imag_master_en */
+
+ interrupts = <1 1 2>; /* IRQ1, edge falling */
+
+ ifm,csi-addr-bus-width = <24>;
+ ifm,csi-data-bus-width = <8>;
+ ifm,csi-wait-cycles = <0>;
+ };
+ };
+};
diff --git a/arch/powerpc/boot/dts/o2d300.dts b/arch/powerpc/boot/dts/o2d300.dts
new file mode 100644
index 0000000..29affe0
--- /dev/null
+++ b/arch/powerpc/boot/dts/o2d300.dts
@@ -0,0 +1,52 @@
+/*
+ * O2D300 Device Tree Source
+ *
+ * Copyright (C) 2012 DENX Software Engineering
+ * Anatolij Gustschin <agust@denx.de>
+ *
+ * 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/ "o2d.dtsi"
+
+/ {
+ model = "ifm,o2d300";
+ compatible = "ifm,o2d";
+
+ localbus {
+ ranges = <0 0 0xfc000000 0x02000000
+ 3 0 0xe3000000 0x00100000>;
+ flash@0,0 {
+ compatible = "cfi-flash";
+ reg = <0 0 0x02000000>;
+ bank-width = <2>;
+ device-width = <2>;
+ #size-cells = <1>;
+ #address-cells = <1>;
+
+ partition@40000 {
+ label = "env_1";
+ reg = <0x00040000 0x00020000>;
+ read-only;
+ };
+ partition@60000 {
+ label = "env_2";
+ reg = <0x00060000 0x00020000>;
+ read-only;
+ };
+ partition@80000 {
+ label = "kernel";
+ reg = <0x00080000 0x00260000>;
+ read-only;
+ };
+ /* o2d300 specific partitions */
+ partition@2e0000 {
+ label = "o2d300 user defined";
+ reg = <0x002e0000 0x01d20000>;
+ };
+ };
+ };
+};
diff --git a/arch/powerpc/boot/dts/o2dnt2.dts b/arch/powerpc/boot/dts/o2dnt2.dts
new file mode 100644
index 0000000..a0f5b97
--- /dev/null
+++ b/arch/powerpc/boot/dts/o2dnt2.dts
@@ -0,0 +1,48 @@
+/*
+ * O2DNT2 Device Tree Source
+ *
+ * Copyright (C) 2012 DENX Software Engineering
+ * Anatolij Gustschin <agust@denx.de>
+ *
+ * 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/ "o2d.dtsi"
+
+/ {
+ model = "ifm,o2dnt2";
+ compatible = "ifm,o2d";
+
+ memory {
+ reg = <0x00000000 0x08000000>; // 128MB
+ };
+
+ localbus {
+ ranges = <0 0 0xfc000000 0x02000000
+ 3 0 0xe3000000 0x00100000>;
+
+ flash@0,0 {
+ compatible = "cfi-flash";
+ reg = <0 0 0x02000000>;
+ bank-width = <2>;
+ device-width = <2>;
+ #size-cells = <1>;
+ #address-cells = <1>;
+
+ partition@60000 {
+ label = "kernel";
+ reg = <0x00060000 0x00260000>;
+ read-only;
+ };
+
+ /* o2dnt2 specific partitions */
+ partition@2c0000 {
+ label = "o2dnt2 user defined";
+ reg = <0x002c0000 0x01d40000>;
+ };
+ };
+ };
+};
diff --git a/arch/powerpc/boot/dts/o2i.dts b/arch/powerpc/boot/dts/o2i.dts
new file mode 100644
index 0000000..e3cc99d
--- /dev/null
+++ b/arch/powerpc/boot/dts/o2i.dts
@@ -0,0 +1,33 @@
+/*
+ * O2I Device Tree Source
+ *
+ * Copyright (C) 2012 DENX Software Engineering
+ * Anatolij Gustschin <agust@denx.de>
+ *
+ * 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/ "o2d.dtsi"
+
+/ {
+ model = "ifm,o2i";
+ compatible = "ifm,o2d";
+
+ localbus {
+ flash@0,0 {
+ partition@60000 {
+ label = "kernel";
+ reg = <0x00060000 0x00260000>;
+ read-only;
+ };
+ /* o2i specific partitions */
+ partition@2c0000 {
+ label = "o2i user defined";
+ reg = <0x002c0000 0x00d40000>;
+ };
+ };
+ };
+};
diff --git a/arch/powerpc/boot/dts/o2mnt.dts b/arch/powerpc/boot/dts/o2mnt.dts
new file mode 100644
index 0000000..d91859a
--- /dev/null
+++ b/arch/powerpc/boot/dts/o2mnt.dts
@@ -0,0 +1,33 @@
+/*
+ * O2MNT Device Tree Source
+ *
+ * Copyright (C) 2012 DENX Software Engineering
+ * Anatolij Gustschin <agust@denx.de>
+ *
+ * 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/ "o2d.dtsi"
+
+/ {
+ model = "ifm,o2mnt";
+ compatible = "ifm,o2d";
+
+ localbus {
+ flash@0,0 {
+ partition@60000 {
+ label = "kernel";
+ reg = <0x00060000 0x00260000>;
+ read-only;
+ };
+ /* add o2mnt specific partitions */
+ partition@2c0000 {
+ label = "o2mnt user defined";
+ reg = <0x002c0000 0x00d40000>;
+ };
+ };
+ };
+};
diff --git a/arch/powerpc/boot/dts/o3dnt.dts b/arch/powerpc/boot/dts/o3dnt.dts
new file mode 100644
index 0000000..acce493
--- /dev/null
+++ b/arch/powerpc/boot/dts/o3dnt.dts
@@ -0,0 +1,48 @@
+/*
+ * O3DNT Device Tree Source
+ *
+ * Copyright (C) 2012 DENX Software Engineering
+ * Anatolij Gustschin <agust@denx.de>
+ *
+ * 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/ "o2d.dtsi"
+
+/ {
+ model = "ifm,o3dnt";
+ compatible = "ifm,o2d";
+
+ memory {
+ reg = <0x00000000 0x04000000>; // 64MB
+ };
+
+ localbus {
+ ranges = <0 0 0xfc000000 0x01000000
+ 3 0 0xe3000000 0x00100000>;
+
+ flash@0,0 {
+ compatible = "cfi-flash";
+ reg = <0 0 0x01000000>;
+ bank-width = <2>;
+ device-width = <2>;
+ #size-cells = <1>;
+ #address-cells = <1>;
+
+ partition@60000 {
+ label = "kernel";
+ reg = <0x00060000 0x00260000>;
+ read-only;
+ };
+
+ /* o3dnt specific partitions */
+ partition@2c0000 {
+ label = "o3dnt user defined";
+ reg = <0x002c0000 0x00d40000>;
+ };
+ };
+ };
+};
diff --git a/arch/powerpc/platforms/52xx/mpc5200_simple.c b/arch/powerpc/platforms/52xx/mpc5200_simple.c
index c0aa040..9cf3602 100644
--- a/arch/powerpc/platforms/52xx/mpc5200_simple.c
+++ b/arch/powerpc/platforms/52xx/mpc5200_simple.c
@@ -52,6 +52,7 @@ static void __init mpc5200_simple_setup_arch(void)
static const char *board[] __initdata = {
"anonymous,a4m072",
"anon,charon",
+ "ifm,o2d",
"intercontrol,digsy-mtc",
"manroland,mucmc52",
"manroland,uc101",
--
1.7.1
^ permalink raw reply related
* RE: [PATCH v7 0/8] Raid: enable talitos xor offload for improving performance
From: Liu Qiang-B32616 @ 2012-08-30 6:20 UTC (permalink / raw)
To: Dan Williams
Cc: herbert@gondor.apana.org.au, arnd@arndb.de, Ira W. Snyder,
vinod.koul@intel.com, gregkh@linuxfoundation.org,
linux-kernel@vger.kernel.org, linux-crypto@vger.kernel.org,
linuxppc-dev@lists.ozlabs.org
In-Reply-To: <1346251975.27020.2.camel@localhost.localdomain>
PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBEYW4gV2lsbGlhbXMgW21haWx0
bzpkamJ3QGZiLmNvbV0NCj4gU2VudDogV2VkbmVzZGF5LCBBdWd1c3QgMjksIDIwMTIgMTA6NTMg
UE0NCj4gVG86IExpdSBRaWFuZy1CMzI2MTYNCj4gQ2M6IHZpbm9kLmtvdWxAaW50ZWwuY29tOyBh
cm5kQGFybmRiLmRlOyBoZXJiZXJ0QGdvbmRvci5hcGFuYS5vcmcuYXU7DQo+IGdyZWdraEBsaW51
eGZvdW5kYXRpb24ub3JnOyBsaW51eHBwYy1kZXZAbGlzdHMub3psYWJzLm9yZzsgbGludXgtDQo+
IGtlcm5lbEB2Z2VyLmtlcm5lbC5vcmc7IGxpbnV4LWNyeXB0b0B2Z2VyLmtlcm5lbC5vcmc7IEly
YSBXLiBTbnlkZXINCj4gU3ViamVjdDogUmU6IFtQQVRDSCB2NyAwLzhdIFJhaWQ6IGVuYWJsZSB0
YWxpdG9zIHhvciBvZmZsb2FkIGZvcg0KPiBpbXByb3ZpbmcgcGVyZm9ybWFuY2UNCj4gDQo+IE9u
IFdlZCwgMjAxMi0wOC0yOSBhdCAxMToxNSArMDAwMCwgTGl1IFFpYW5nLUIzMjYxNiB3cm90ZToN
Cj4gPiBIaSBEYW4sDQo+ID4NCj4gPiBQaW5nPw0KPiA+IENhbiB5b3UgYXBwbHkgdGhlc2UgcGF0
Y2hlcz8gVGhhbmtzLg0KPiA+DQo+IA0KPiBJJ20gd29ya2luZyBteSB3YXkgdGhyb3VnaCB0aGVt
Lg0KPiANCj4gVGhlIGZpcnN0IHRoaW5nIEkgbm90aWNlIGlzIHRoYXQgeG9yX2NoYW4tPmRlc2Nf
bG9jayBpcyB0YWtlbg0KPiBpbmNvbnNpc3RlbnRseS4gIEkuZS4gc3Bpbl9sb2NrX2lycXNhdmUo
KSBpbiB0YWxpdG9zX3Byb2Nlc3NfcGVuZGluZygpDQo+IGFuZCBzcGluX2xvY2tfYmgoKSBldmVy
eXdoZXJlIGVsc2UuICBIYXZlIHlvdSBydW4gdGhlc2UgcGF0Y2hlcyB3aXRoDQo+IGxvY2tkZXA/
DQpUaGFua3MgZm9yIHlvdXIgcmVwbHkuDQpMT0NLREVQIGlzIGVuYWJsZWQgYXMgeW91IHN1Z2dl
c3RlZCwgdGhlcmUgaXMgbm90IGFueSBpbmZvIGFib3V0ICJpbmNvbnNpc3RlbnQgbG9jayBzdGF0
ZSIgZGlzcGxheWVkLg0KSSBkb24ndCBrbm93IHdoZXRoZXIgaXQncyBlbm91Z2guDQoNCkknbSBj
b25mdXNlZCBhYm91dCB0aGUgYXR0cmlidXRlIG9mIERNQV9JTlRFUlJVUFQsIG15IHVuZGVyc3Rh
bmRpbmcgaXMgdGhpcyBpbnRlcmZhY2UgaXMgb25seSB1c2VkIHRvIHRyaWdnZXIgYW4gaW50ZXJy
dXB0IChtYWtlIHN1cmUgYWxsIGZvcm1lciBvcGVyYXRpb25zIGFyZSBmaW5pc2hlZCBiZWZvcmUg
c3dpdGNoaW5nIHRvIG90aGVyIGNoYW5uZWxzKSwgYnV0IGZzbC1kbWEgd2lsbCB0cmlnZ2VyIGFu
IGludGVycnVwdCBieSAiUHJvZ3JhbW1lZCBFcnJvciIuIEknbSB3b25kZXJpbmcgd2hldGhlciBv
dGhlciBoYXJkd2FyZSBhcmUgc2FtZSB3aXRoIGZzbC1kbWEgKHRoZSBpbnRlcnJ1cHQgaXMgYSBu
b3JtYWwgaW50ZXJydXB0LCBidXQgbm90IGFuIGVycm9yKSBpLmUuIHhzY2FsZS1pb3A/DQpJZiBv
dGhlciBoYXJkd2FyZSBhbHNvIHRyaWdnZXIgYW4gaW50ZXJydXB0IGJ5IGFuIGFibm9ybWFsIGVy
cm9yLCBtYXliZSBteSBwYXRjaCAyLzggc2hvdWxkIGJlIHJldmVydGVkIGJlY2F1c2UgaXQgdmlv
bGF0ZXMgdGhlIHJ1bGVzIG9mIHRoaXMgYXR0cmlidXRlLg0KDQpCVFcsIGNvdWxkIHlvdSBwbGVh
c2UgcmVwbHkgaW4gdGhlIHBhdGNoIGlmIHlvdSBoYXZlIGFueSBjb21tZW50cy4gVGhhbmtzLg0K
DQo+IA0KPiAtLQ0KPiBEYW4NCj4gDQo+IA0KDQo=
^ permalink raw reply
* Re: The MAX high_addr for `mmap` on PPC64
From: David Gibson @ 2012-08-29 23:39 UTC (permalink / raw)
To: madper; +Cc: linuxppc-dev@lists.ozlabs.org
In-Reply-To: <op.wjsalgstxxpu98@localhost.localdomain>
On Wed, Aug 29, 2012 at 11:57:06AM +0800, madper wrote:
> On Wed, 29 Aug 2012 11:42:58 +0800, David Gibson
> <david@gibson.dropbear.id.au> wrote:
>
> >On Wed, Aug 29, 2012 at 11:34:08AM +0800, madper wrote:
> >>Hi every one,
> >> I use the ltp (Linux-Test-Project) and run it on both ppc64
> >>and x86_64.
> >> There is a code like follows in
> >>`ltp/testcase/kernel/mem/hugetbl/hugemmap/hugemmap03.c`:
> >>`code`
> >> #define HIGH_ADDR (void *)(0x1000000000000)
> >> /* Attempt to mmap into highmem addr, should get ENOMEM */
> >> addr = mmap(HIGH_ADDR, map_sz, PROT_READ,
> >> MAP_SHARED | MAP_FIXED, fildes, 0);
> >>`code ends`
> >> It return ENOMEM on x86_64 as well as we expected. But return
> >>EINVAL on ppc64. So I want to know the MAX high addr for PPC64.
> >
> >That's a pretty bogus test, since the max address is not specified
> >strictly. It's currently 4T on ppc64, but patches that are in the
> >works will change it to 16T.
> >
> Hi, I tested it for rhel6. Also I change the high_addr to
> `0x7ffffffffff` but it got EINVAL again.
0x7ffffffffff is not page aligned, so it probably should get EINVAL.
That said, it wouldn't surprise me if we got the wront error code for
address space overflows.
> So, I nearly certain that rhel6 can only support for 4T.
> So, do you think that I should change the high_addr to `0x3ffffffffff`?
>
> >Also I'm not convinced that "highmem addr" has any meaning in the
> >context of userspace addresses.
> >
> I think may be the coder want to test kernel by userspace program? :-(
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
* Re: [PATCH] clk: Make the generic clock API available by default
From: Stephen Warren @ 2012-08-29 21:49 UTC (permalink / raw)
To: Mark Brown
Cc: linux-mips, Guan Xuetao, Russell King, Arnd Bergmann,
linux-kernel, Ralf Baechle, Paul Mackerras, Haavard Skinnemoen,
linuxppc-dev, linux-arm-kernel, Hans-Christian Egtvedt
In-Reply-To: <1346186104-4083-1-git-send-email-broonie@opensource.wolfsonmicro.com>
On 08/28/12 13:35, Mark Brown wrote:
> Rather than requiring platforms to select the generic clock API to make
> it available make the API available as a user selectable option unless the
> user either selects HAVE_CUSTOM_CLK (if they have their own implementation)
> or selects COMMON_CLK (if they depend on the generic implementation).
>
> All current architectures that HAVE_CLK but don't use the common clock
> framework have selects of HAVE_CUSTOM_CLK added.
>
> This allows drivers to use the generic API on platforms which have no need
> for the clock API at platform level.
> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
> @@ -674,6 +676,7 @@ config ARCH_TEGRA
> select GENERIC_CLOCKEVENTS
> select GENERIC_GPIO
> select HAVE_CLK
> + select HAVE_CUSTOM_CLK
For 3.7, Tegra will switch to the common clock framework. I think this
patch would then disable that. How should we resolve this - rebase the
Tegra common-clk tree on top of any branch containing this patch in
order to remove that select statement?
^ permalink raw reply
* Re: [PATCH v7 0/8] Raid: enable talitos xor offload for improving performance
From: Dan Williams @ 2012-08-29 14:52 UTC (permalink / raw)
To: Liu Qiang-B32616
Cc: herbert@gondor.apana.org.au, arnd@arndb.de, Ira W. Snyder,
vinod.koul@intel.com, gregkh@linuxfoundation.org,
linux-kernel@vger.kernel.org, linux-crypto@vger.kernel.org,
linuxppc-dev@lists.ozlabs.org
In-Reply-To: <BCB48C05FCE8BC4D9E61E841ECBE6DB70FC3CA@039-SN2MPN1-011.039d.mgd.msft.net>
On Wed, 2012-08-29 at 11:15 +0000, Liu Qiang-B32616 wrote:
> Hi Dan,
>
> Ping?
> Can you apply these patches? Thanks.
>
I'm working my way through them.
The first thing I notice is that xor_chan->desc_lock is taken
inconsistently. I.e. spin_lock_irqsave() in talitos_process_pending()
and spin_lock_bh() everywhere else. Have you run these patches with
lockdep?
--
Dan
^ permalink raw reply
* RE: [PATCH v7 0/8] Raid: enable talitos xor offload for improving performance
From: Liu Qiang-B32616 @ 2012-08-29 11:15 UTC (permalink / raw)
To: Dan Williams
Cc: herbert@gondor.apana.org.au, arnd@arndb.de, Ira W. Snyder,
vinod.koul@intel.com, gregkh@linuxfoundation.org,
linux-kernel@vger.kernel.org, linux-crypto@vger.kernel.org,
linuxppc-dev@lists.ozlabs.org
In-Reply-To: <CAA9_cme4tHrx14JaSaHwgcGq79qQK5bv8E205fbC3ega5OpUiQ@mail.gmail.com>
Hi Dan,
Ping?
Can you apply these patches? Thanks.
- Qiang
> -----Original Message-----
> From: dan.j.williams@gmail.com [mailto:dan.j.williams@gmail.com] On
> Behalf Of Dan Williams
> Sent: Wednesday, August 15, 2012 4:02 AM
> To: Liu Qiang-B32616
> Cc: dan.j.williams@intel.com; vinod.koul@intel.com; arnd@arndb.de;
> herbert@gondor.apana.org.au; gregkh@linuxfoundation.org; linuxppc-
> dev@lists.ozlabs.org; linux-kernel@vger.kernel.org; linux-
> crypto@vger.kernel.org; Ira W. Snyder
> Subject: Re: [PATCH v7 0/8] Raid: enable talitos xor offload for
> improving performance
>=20
> On Tue, Aug 14, 2012 at 2:04 AM, Liu Qiang-B32616 <B32616@freescale.com>
> wrote:
> > Hi Vinod,
> >
> > Would you like to apply this series from patch 2/8 to 7/8) in your tree=
?
> > The link as below,
> > http://patchwork.ozlabs.org/patch/176023/
> > http://patchwork.ozlabs.org/patch/176024/
> > http://patchwork.ozlabs.org/patch/176025/
> > http://patchwork.ozlabs.org/patch/176026/
> > http://patchwork.ozlabs.org/patch/176027/
> > http://patchwork.ozlabs.org/patch/176028/
> >
>=20
> Hi, sorry for the recent silence I've been transitioning and am now
> just catching up. I'll take a look and then it's fine for these to go
> through Vinod's tree.
>=20
> --
> Dan
^ permalink raw reply
* Re: [PATCH] clk: Make the generic clock API available by default
From: Hans-Christian Egtvedt @ 2012-08-29 5:56 UTC (permalink / raw)
To: Mark Brown
Cc: linux-mips, Russell King, Arnd Bergmann, linux-kernel,
Ralf Baechle, Paul Mackerras, Guan Xuetao, linuxppc-dev,
linux-arm-kernel, Haavard Skinnemoen
In-Reply-To: <1346186104-4083-1-git-send-email-broonie@opensource.wolfsonmicro.com>
Around Tue 28 Aug 2012 13:35:04 -0700 or thereabout, Mark Brown wrote:
> Rather than requiring platforms to select the generic clock API to make
> it available make the API available as a user selectable option unless the
> user either selects HAVE_CUSTOM_CLK (if they have their own implementation)
> or selects COMMON_CLK (if they depend on the generic implementation).
>
> All current architectures that HAVE_CLK but don't use the common clock
> framework have selects of HAVE_CUSTOM_CLK added.
>
> This allows drivers to use the generic API on platforms which have no need
> for the clock API at platform level.
>
> Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
> ---
>
> This depends on having one of the patches I've sent adding a generic
> clkdev.h added merged - Arnd was expecting to merge one of those, there
> was just the lack of clarity about the most practical Kbuild hookup.
>
> arch/arm/Kconfig | 12 ++++++++++++
> arch/avr32/Kconfig | 1 +
For the AVR32 related changes
Acked-by: Hans-Christian Egtvedt <egtvedt@samfundet.no>
<snipp>
--
mvh
Hans-Christian Egtvedt
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox