* Re: [PATCH 2/2] maps/mtd-ram: add an of-platform driver
From: Grant Likely @ 2009-05-19 20:36 UTC (permalink / raw)
To: Wolfram Sang; +Cc: linuxppc-dev, linux-mtd, ben-linux
In-Reply-To: <20090519203014.GC27476@pengutronix.de>
On Tue, May 19, 2009 at 2:30 PM, Wolfram Sang <w.sang@pengutronix.de> wrote=
:
>> This name is too generic for an of_platform device. =A0'mtd' needs to be
>> in there somewhere.
>
> Will "of-mtd-ram" do? (I'd think so)
fine by me.
g
--=20
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: mpc5200 fec error
From: Robert Schwebel @ 2009-05-19 20:36 UTC (permalink / raw)
To: Wolfram Sang; +Cc: linuxppc-dev, Eric Millbrandt
In-Reply-To: <A88094362DE0AE49A118AB9B4EB3612403F9DEB6@dekaexchange.deka.local>
Wolfram, have you seen this mail? You recently tested -rt on 2.6.29,
right? Did you only test that on the customer hardware or also on the
phyCORE-MPC5200B?
rsc
On Mon, May 18, 2009 at 01:36:27PM -0400, Eric Millbrandt wrote:
> Hello all,
>
>
>
> I am testing a 2.6.29.3 (with preempt_rt patches) kernel on a phytec pcm030 and
> am getting a kernel hang when testing the fec Ethernet controller. The error
> only occurs when running the preempt-patched kernel, an unmodified kernel works
> fine. Is anyone out there using preempt_rt on an MPC5200 successfully?
>
>
>
> Eric
>
>
>
> root@rudolph-ui:/root> iperf -c linux-5200bdevl01 -P 2 -i 1 -p 5001 -f k -t 600
>
> ------------------------------------------------------------
>
> Client connecting to linux-5200bdevl01, TCP port 5001
>
> TCP window size: 36.2 KByte (default)
>
> ------------------------------------------------------------
>
> [ 4] local 10.1.4.88 port 37872 connected with 10.1.5.234 port 5001
>
> [ 3] local 10.1.4.88 port 37871 connected with 10.1.5.234 port 5001
>
> [ ID] Interval Transfer Bandwidth
>
> [ 3] 0.0- 1.0 sec 3824 KBytes 31326 Kbits/sec
>
> [ ID] Interval Transfer Bandwidth
>
> [ 4] 0.0- 1.0 sec 3656 KBytes 29950 Kbits/sec
>
> [SUM] 0.0- 1.0 sec 7480 KBytes 61276 Kbits/sec
>
> [ ID] Interval Transfer Bandwidth
>
> [ 4] 1.0- 2.0 sec 3760 KBytes 30802 Kbits/sec
>
> [ ID] Interval Transfer Bandwidth
>
> [ 3] 1.0- 2.0 sec 3752 KBytes 30736 Kbits/sec
>
> [SUM] 1.0- 2.0 sec 7512 KBytes 61538 Kbits/sec
>
> [ ID] Interval Transfer Bandwidth
>
> [ 4] 2.0- 3.0 sec 3728 KBytes 30540 Kbits/sec
>
> [ ID] Interval Transfer Bandwidth
>
> [ 3] 2.0- 3.0 sec 3816 KBytes 31261 Kbits/sec
>
> [SUM] 2.0- 3.0 sec 7544 KBytes 61800 Kbits/sec
>
> [ ID] Interval Transfer Bandwidth
>
> [ 3] 3.0- 4.0 sec 3712 KBytes 30409 Kbits/sec
>
> [ ID] Interval Transfer Bandwidth
>
> [ 4] 3.0- 4.0 sec 3824 KBytes 31326 Kbits/sec
>
> [SUM] 3.0- 4.0 sec 7536 KBytes 61735 Kbits/sec
>
> [ ID] Interval Transfer Bandwidth
>
> [ 3] 4.0- 5.0 sec 3968 KBytes 32506 Kbits/sec
>
> [ ID] Interval Transfer Bandwidth
>
> [ 4] 4.0- 5.0 sec 3624 KBytes 29688 Kbits/sec
>
> [SUM] 4.0- 5.0 sec 7592 KBytes 62194 Kbits/sec
>
> [ 5761.999175] net eth0: transmit queue overrun
>
> [ 5762.003591] net eth0: transmit queue overrun
>
> [ 5762.007948] net eth0: transmit queue overrun
>
> [ 5762.012302] net eth0: transmit queue overrun
>
> [ 5762.016658] net eth0: transmit queue overrun
>
> [ 5762.021013] net eth0: transmit queue overrun
>
> [ 5762.025381] net eth0: transmit queue overrun
>
> [ 5762.029735] net eth0: transmit queue overrun
>
> [ 5762.034090] net eth0: transmit queue overrun
>
> [ 5762.038445] net eth0: transmit queue overrun
>
> [ 5767.000928] net eth0: transmit queue overrun
>
> [ 5767.005278] net eth0: transmit queue overrun
>
> [ 5767.009634] net eth0: transmit queue overrun
>
> [ 5767.013990] net eth0: transmit queue overrun
>
> [ 5767.018345] net eth0: transmit queue overrun
>
> [ 5767.022701] net eth0: transmit queue overrun
>
> ?.
>
>
>
> _____________________________________________________________________________
>
> This e-mail and the information, including any attachments, it contains are
> intended to be a confidential communication only to the person or entity to
> whom it is addressed and may contain information that is privileged. If the
> reader of this message is not the intended recipient, you are hereby notified
> that any dissemination, distribution or copying of this communication is
> strictly prohibited. If you have received this communication in error, please
> immediately notify the sender and destroy the original message.
>
> Thank you.
>
>
>
> Please consider the environment before printing this email.
>
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
^ permalink raw reply
* Re: [PATCH 2/2] maps/mtd-ram: add an of-platform driver
From: Wolfram Sang @ 2009-05-19 20:30 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-dev, linux-mtd, ben-linux
In-Reply-To: <fa686aa40905190757w68b35333j6f0fa84ea253a486@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 6437 bytes --]
Hi Grant,
thanks a lot for the review!
On Tue, May 19, 2009 at 08:57:15AM -0600, Grant Likely wrote:
> On Wed, Jan 21, 2009 at 11:41 AM, Wolfram Sang <w.sang@pengutronix.de> wrote:
> > Create an of-aware driver using the now exported generic functions from
> > plat-ram.c. A typical oftree snipplet for it looks like this:
> >
> > sram@04e00000 {
> > compatible = "mtd-ram";
> > reg = <0x04e00000 0x00200000>;
> > bank-width = <2>;
> > };
> >
> > Partitions on this device are not yet supported.
>
> This is a new device tree binding. It must be documented in
> Documentation/powerpc/dts-bindings and posted to
> devicetree-discuss@ozlabs.org for review.
Yeah, noticed that myself. I wanted to start another try to mainline this
driver next week, then also asking devicetree-discuss; will do it happily this
week, too :)
>
> > diff --git a/drivers/mtd/maps/Makefile b/drivers/mtd/maps/Makefile
> > index 6d9ba35..f8e3908 100644
> > --- a/drivers/mtd/maps/Makefile
> > +++ b/drivers/mtd/maps/Makefile
> > @@ -58,6 +58,7 @@ obj-$(CONFIG_MTD_WRSBC8260) += wr_sbc82xx_flash.o
> > obj-$(CONFIG_MTD_DMV182) += dmv182.o
> > obj-$(CONFIG_MTD_SHARP_SL) += sharpsl-flash.o
> > obj-$(CONFIG_MTD_PLATRAM) += plat-ram.o
> > +obj-$(CONFIG_MTD_OFRAM) += of-ram.o
> > obj-$(CONFIG_MTD_OMAP_NOR) += omap_nor.o
> > obj-$(CONFIG_MTD_INTEL_VR_NOR) += intel_vr_nor.o
> > obj-$(CONFIG_MTD_BFIN_ASYNC) += bfin-async-flash.o
> > diff --git a/drivers/mtd/maps/of-ram.c b/drivers/mtd/maps/of-ram.c
> > new file mode 100644
> > index 0000000..4d334a9
> > --- /dev/null
> > +++ b/drivers/mtd/maps/of-ram.c
> > @@ -0,0 +1,120 @@
> > +/*
> > + * drivers/mtd/maps/of-ram.c
> > + *
> > + * Generic of device based RAM map
> > + *
> > + * Copyright (C) 2009 Wolfram Sang, Pengutronix
> > + *
> > + * Using plat-ram.c by Ben Dooks
> > + *
> > + * This program is free software; you can redistribute it and/or modify it
> > + * under the terms of the GNU General Public License version 2 as published by
> > + * the Free Software Foundation.
> > + */
> > +
> > +#include <linux/module.h>
> > +#include <linux/types.h>
> > +#include <linux/init.h>
> > +#include <linux/kernel.h>
> > +#include <linux/device.h>
> > +#include <linux/platform_device.h>
> > +#include <linux/of_device.h>
> > +#include <linux/of_platform.h>
> > +#include <linux/mtd/plat-ram.h>
> > +
> > +static int of_ram_probe(struct of_device *op, const struct of_device_id *match)
>
> __devinit
Oops, missed all of those.
>
> > +{
> > + struct platdata_mtd_ram *pdata;
> > + struct resource *resource;
> > + const char *name;
> > + const u32 *bankwidth;
> > + int ret = -ENOMEM;
> > +
> > + pdata = kzalloc(sizeof(*pdata), GFP_KERNEL);
> > + if (!pdata)
> > + goto bad0;
> > + op->dev.platform_data = pdata;
> > +
> > + name = of_get_property(op->node, "name", NULL);
> > + if (!name) {
> > + ret = -ENOENT;
> > + dev_dbg(&op->dev, "could not get node name\n");
> > + goto bad1;
> > + }
> > +
> > + resource = kzalloc(sizeof(struct resource), GFP_KERNEL);
> > + if (!resource)
> > + goto bad1;
>
> Why isn't resource on the stack?
Point taken.
>
> > +
> > + if (of_address_to_resource(op->node, 0, resource)) {
> > + ret = -ENXIO;
> > + dev_dbg(&op->dev, "could not create resource\n");
> > + goto bad2;
> > + }
> > +
> > + bankwidth = of_get_property(op->node, "bank-width", NULL);
> > + if (*bankwidth == 0) {
> > + ret = -ENOENT;
> > + dev_dbg(&op->dev, "bank width not set\n");
> > + goto bad2;
> > + }
> > + pdata->bankwidth = *bankwidth;
> > +
> > + ret = __platram_probe(&op->dev, name, resource, pdata);
> > + kfree(resource);
> > +
> > + if (ret)
> > + goto bad1;
> > +
> > + return 0;
> > +
> > + bad2:
> > + kfree(resource);
> > + bad1:
> > + op->dev.platform_data = NULL;
> > + kfree(pdata);
> > + bad0:
> > + return ret;
>
> I'd rather see more meaningful labels. ie "err_kalloc:" and
> "err_platram_probe:".
Okay.
>
> > +}
> > +
> > +static int of_ram_remove(struct of_device *op)
>
> __devexit
>
> > +{
> > + int ret;
> > + struct platdata_mtd_ram *pdata = op->dev.platform_data;
> > +
> > + ret = __platram_remove(&op->dev);
> > + op->dev.platform_data = NULL;
> > + kfree(pdata);
> > + return ret;
> > +}
> > +
> > +static struct of_device_id of_ram_match[] = {
> > + { .compatible = "mtd-ram", },
> > + {},
> > +};
> > +MODULE_DEVICE_TABLE(of, of_ram_match);
> > +
> > +static struct of_platform_driver of_ram_driver = {
>
> __devinitdata
>
> > + .owner = THIS_MODULE,
> > + .name = "of-ram",
>
> This name is too generic for an of_platform device. 'mtd' needs to be
> in there somewhere.
Will "of-mtd-ram" do? (I'd think so)
>
> > + .match_table = of_ram_match,
> > + .probe = of_ram_probe,
> > + .remove = of_ram_remove,
>
> __devexit_p()
>
> > +};
> > +
> > +static int __init of_ram_init(void)
> > +{
> > + return of_register_platform_driver(&of_ram_driver);
> > +}
> > +
> > +static void __exit of_ram_exit(void)
> > +{
> > + of_unregister_platform_driver(&of_ram_driver);
> > +}
> > +
> > +module_init(of_ram_init);
>
> Put the module_init() statement directly after the of_ram_init() definition.
>
> > +module_exit(of_ram_exit);
> > +
> > +MODULE_AUTHOR("Wolfram Sang");
> > +MODULE_DESCRIPTION("MTD OF RAM map driver");
> > +MODULE_LICENSE("GPL v2");
> > --
> > 1.5.6.5
> >
> > _______________________________________________
> > Linuxppc-dev mailing list
> > Linuxppc-dev@ozlabs.org
> > https://ozlabs.org/mailman/listinfo/linuxppc-dev
> >
>
>
>
> --
> Grant Likely, B.Sc., P.Eng.
> Secret Lab Technologies Ltd.
Will send V2 after some tests tomorrow...
Thanks,
Wolfram
--
Pengutronix e.K. | Wolfram Sang |
Industrial Linux Solutions | http://www.pengutronix.de/ |
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: [PATCH 2/2] qe: add polling timeout to qe_issue_cmd()
From: Grant Likely @ 2009-05-19 20:10 UTC (permalink / raw)
To: Timur Tabi; +Cc: linuxppc-dev, smaclennan
In-Reply-To: <1242761199-17875-3-git-send-email-timur@freescale.com>
On Tue, May 19, 2009 at 1:26 PM, Timur Tabi <timur@freescale.com> wrote:
> The qe_issue_cmd() function (Freescale PowerPC QUICC Engine library) poll=
s on
> a register until a status bit changes, but does not include a timeout to
> handle the situation if the bit never changes. =A0Change the code to use =
the new
> spin_event_timeout() macro, which simplifies polling on a register withou=
t
> a timeout.
>
> Signed-off-by: Timur Tabi <timur@freescale.com>
> ---
>
> This patch depends on my previous patch, "powerpc: introduce macro
> spin_event_timeout()".
>
> =A0arch/powerpc/sysdev/qe_lib/qe.c | =A0 =A09 ++++++---
> =A01 files changed, 6 insertions(+), 3 deletions(-)
>
> diff --git a/arch/powerpc/sysdev/qe_lib/qe.c b/arch/powerpc/sysdev/qe_lib=
/qe.c
> index 01bce37..810e1df 100644
> --- a/arch/powerpc/sysdev/qe_lib/qe.c
> +++ b/arch/powerpc/sysdev/qe_lib/qe.c
> @@ -111,6 +111,7 @@ int qe_issue_cmd(u32 cmd, u32 device, u8 mcn_protocol=
, u32 cmd_input)
> =A0{
> =A0 =A0 =A0 =A0unsigned long flags;
> =A0 =A0 =A0 =A0u8 mcn_shift =3D 0, dev_shift =3D 0;
> + =A0 =A0 =A0 int ret;
>
> =A0 =A0 =A0 =A0spin_lock_irqsave(&qe_lock, flags);
> =A0 =A0 =A0 =A0if (cmd =3D=3D QE_RESET) {
> @@ -138,11 +139,13 @@ int qe_issue_cmd(u32 cmd, u32 device, u8 mcn_protoc=
ol, u32 cmd_input)
> =A0 =A0 =A0 =A0}
>
> =A0 =A0 =A0 =A0/* wait for the QE_CR_FLG to clear */
> - =A0 =A0 =A0 while(in_be32(&qe_immr->cp.cecr) & QE_CR_FLG)
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 cpu_relax();
> + =A0 =A0 =A0 spin_event_timeout((in_be32(&qe_immr->cp.cecr) & QE_CR_FLG)=
=3D=3D 0,
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0100, 0, ret);
> + =A0 =A0 =A0 /* On timeout (e.g. failure), the expression will be false =
(ret =3D=3D 0),
> + =A0 =A0 =A0 =A0 =A0otherwise it will be true (ret =3D=3D 1). */
> =A0 =A0 =A0 =A0spin_unlock_irqrestore(&qe_lock, flags);
>
> - =A0 =A0 =A0 return 0;
> + =A0 =A0 =A0 return ret =3D=3D 1;
Hmmm, the ret value is backwards from what most coders would expect
(zero on success, non-zero on failure). I'd personally recommend
reversing the polarity in the macro.
Otherwise, feel free to add my acked-by line to both patches.
g.
--=20
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: [PATCH V2 2/3] powerpc: Add support for swiotlb on 32-bit
From: Becky Bruce @ 2009-05-19 20:06 UTC (permalink / raw)
To: Kumar Gala; +Cc: fujita.tomonori, linuxppc-dev
In-Reply-To: <13F18475-1D3E-4D9E-B10C-8BE48FBA9DF5@kernel.crashing.org>
On May 19, 2009, at 8:04 AM, Kumar Gala wrote:
>
> On May 18, 2009, at 4:49 PM, Benjamin Herrenschmidt wrote:
>
>> On Mon, 2009-05-18 at 08:25 -0500, Kumar Gala wrote:
>>>
>>> Part of this is how the generic swiotlb code works and part of it
>>> was
>>> our desire not to bloat dev archdata by adding such info that as you
>>> say is either bus specific or conveyed in the dma addr mask.
>>
>> Right but perf sucks :-)
>>
>> Maybe an option is to clamp the DMA mask when it's set by the
>> driver to
>> limit it to the available inbound window ?
>
> Clamping the DMA mask is even worse than the additional indirection
> for us. We have valid scenarios in which we'd have 512M of outbound
> PCI address space and 4G of mem and thus 3.5G of inbound PCI address
> space. With the DMA mask we'd be limited to 2G and bouncing from
> 2..3.5G when we don't need to.
>
>
> I think our options are to change archdata as follows:
>
> Option 1 - just add a new data member to dev_archdata
>
> struct dev_archdata {
> /* Optional pointer to an OF device node */
> struct device_node *of_node;
>
> /* DMA operations on that device */
> struct dma_mapping_ops *dma_ops;
> void *dma_data;
> dma_addr_t direct_dma_addr;
> };
>
> Option 2 - introduce a proper container for how we use dma_data.
> This may just be moving the indirection from an indirection function
> call to an indirection data reference:
>
> struct dma_data {
> dma_addr_t offset;
> dma_addr_t direct_dma_addr;
> struct iommu_table *iommu_table;
> };
>
> struct dev_archdata {
> /* Optional pointer to an OF device node */
> struct device_node *of_node;
>
> /* DMA operations on that device */
> struct dma_mapping_ops *dma_ops;
> struct dma_data *dma_data;
> };
Personally, I prefer this. However, I understand Ben has some
objection here. At a minimum, I *do* need to change dma_data to be
able to contain a 64-bit number on a 32-bit platform as part of the
optimization for 64-bit PCI devices. It should probably be a
dma_addr_t for that, looking at how it's being used. However, that is
a bit of a philosophical break from the type of dma_data being generic
void *. I'm open to suggestions here.
>
>
> Option 3 - use dma_data to keep the addr at which we need to bounce
> vs not for SWIOTLB - this has potential issues w/conflicting with
> dma_data being used as the dma_offset. (need to think on that a bit
> more). Additionally this has the benefit in that we need dma_data
> to be a 64-bit quantity on ppc32 w/>32-bit phys addr.
>
> struct dev_archdata {
> /* Optional pointer to an OF device node */
> struct device_node *of_node;
>
> /* DMA operations on that device */
> struct dma_mapping_ops *dma_ops;
> dma_addr_t dma_data;
> };
>
This won't work. I need the dma offset that's currently stored there
for 64-bit PCI devices.
It sounds like we want to do some combination of the above:
1) add a max_dma_addr field to archdata to indicate the boundary
beyond which a device must bounce buffer (we currently don't have
anything that requires a start/size type paradigm here - does anyone
know of any cases that I don't know about here?)
2) change the type of dma_data so it can hold 64 bits on a 32-bit
platform.
-Becky
^ permalink raw reply
* Re: Musings on PCI busses
From: Grant Likely @ 2009-05-19 20:02 UTC (permalink / raw)
To: David Miller; +Cc: linuxppc-dev, thunderbird2k, John.Linn, arnd
In-Reply-To: <20090519.120514.26253637.davem@davemloft.net>
On Tue, May 19, 2009 at 1:05 PM, David Miller <davem@davemloft.net> wrote:
> From: Arnd Bergmann <arnd@arndb.de>
> Date: Tue, 19 May 2009 18:12:02 +0200
>
>> On Tuesday 19 May 2009, Grant Likely wrote:
>>> 1) Probe the host controller in an of_platform driver. =A0This has the
>>> advantage of simplicity. =A0The probe routine will get automatically
>>> called when the PCI host controller device tree node is registered
>>> with the of_platform bus. =A0The bus parenthood also gets reflected in
>>> the device model and sysfs. =A0The disadvantage is that it defers PCI
>>> bus probing until after the of_platform bus is probed (maybe this is
>>> okay; maybe this already happens anyway).
>>
>> This is also what we do on 64-bit systems (well, Cell at this time).
>> There are no fundamental problems with this, just some slightly
>> unexpected interactions e.g. when you have use a PCI serial port
>> as your console before probing PCI.
>
> This is also what sparc64 does :-)
>
> All of the individual sparc64 PCI controller types have a OF driver
> and then there is a common layer of OF PCI helper code to do most
> of the work.
Cool, well I have my solution then. :-)
g.
--=20
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* [PATCH 0/2] introduce macro spin_event_timeout()
From: Timur Tabi @ 2009-05-19 19:26 UTC (permalink / raw)
To: linuxppc-dev, benh, grant.likely, smaclennan
Introduce the spin_event_timeout() macro, and update the QE library to use it.
^ permalink raw reply
* [PATCH 2/2] qe: add polling timeout to qe_issue_cmd()
From: Timur Tabi @ 2009-05-19 19:26 UTC (permalink / raw)
To: linuxppc-dev, benh, grant.likely, smaclennan
In-Reply-To: <1242761199-17875-2-git-send-email-timur@freescale.com>
The qe_issue_cmd() function (Freescale PowerPC QUICC Engine library) polls on
a register until a status bit changes, but does not include a timeout to
handle the situation if the bit never changes. Change the code to use the new
spin_event_timeout() macro, which simplifies polling on a register without
a timeout.
Signed-off-by: Timur Tabi <timur@freescale.com>
---
This patch depends on my previous patch, "powerpc: introduce macro
spin_event_timeout()".
arch/powerpc/sysdev/qe_lib/qe.c | 9 ++++++---
1 files changed, 6 insertions(+), 3 deletions(-)
diff --git a/arch/powerpc/sysdev/qe_lib/qe.c b/arch/powerpc/sysdev/qe_lib/qe.c
index 01bce37..810e1df 100644
--- a/arch/powerpc/sysdev/qe_lib/qe.c
+++ b/arch/powerpc/sysdev/qe_lib/qe.c
@@ -111,6 +111,7 @@ int qe_issue_cmd(u32 cmd, u32 device, u8 mcn_protocol, u32 cmd_input)
{
unsigned long flags;
u8 mcn_shift = 0, dev_shift = 0;
+ int ret;
spin_lock_irqsave(&qe_lock, flags);
if (cmd == QE_RESET) {
@@ -138,11 +139,13 @@ int qe_issue_cmd(u32 cmd, u32 device, u8 mcn_protocol, u32 cmd_input)
}
/* wait for the QE_CR_FLG to clear */
- while(in_be32(&qe_immr->cp.cecr) & QE_CR_FLG)
- cpu_relax();
+ spin_event_timeout((in_be32(&qe_immr->cp.cecr) & QE_CR_FLG) == 0,
+ 100, 0, ret);
+ /* On timeout (e.g. failure), the expression will be false (ret == 0),
+ otherwise it will be true (ret == 1). */
spin_unlock_irqrestore(&qe_lock, flags);
- return 0;
+ return ret == 1;
}
EXPORT_SYMBOL(qe_issue_cmd);
--
1.6.0.6
^ permalink raw reply related
* [PATCH 1/2 v8] powerpc: introduce macro spin_event_timeout()
From: Timur Tabi @ 2009-05-19 19:26 UTC (permalink / raw)
To: linuxppc-dev, benh, grant.likely, smaclennan
In-Reply-To: <1242761199-17875-1-git-send-email-timur@freescale.com>
The macro spin_event_timeout() takes a condition and timeout value
(in microseconds) as parameters. It spins until either the condition is true
or the timeout expires. It returns the result of the condition when the loop
was terminated.
This primary purpose of this macro is to poll on a hardware register until a
status bit changes. The timeout ensures that the loop still terminates if the
bit doesn't change as expected. This macro makes it easier for driver
developers to perform this kind of operation properly.
Signed-off-by: Timur Tabi <timur@freescale.com>
---
v8: added a copyright notice
arch/powerpc/include/asm/delay.h | 33 +++++++++++++++++++++++++++++++++
1 files changed, 33 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/include/asm/delay.h b/arch/powerpc/include/asm/delay.h
index f9200a6..af4a270 100644
--- a/arch/powerpc/include/asm/delay.h
+++ b/arch/powerpc/include/asm/delay.h
@@ -2,8 +2,11 @@
#define _ASM_POWERPC_DELAY_H
#ifdef __KERNEL__
+#include <asm/time.h>
+
/*
* Copyright 1996, Paul Mackerras.
+ * Copyright (C) 2009 Freescale Semiconductor, Inc. All rights reserved.
*
* This program is free software; you can redistribute it and/or
* modify it under the terms of the GNU General Public License
@@ -30,5 +33,35 @@ extern void udelay(unsigned long usecs);
#define mdelay(n) udelay((n) * 1000)
#endif
+/**
+ * spin_event_timeout - spin until a condition gets true or a timeout elapses
+ * @condition: a C expression to evalate
+ * @timeout: timeout, in microseconds
+ * @delay: the number of microseconds to delay between eache evaluation of
+ * @condition
+ * @rc: the last value of the condition
+ *
+ * The process spins until the condition evaluates to true (non-zero) or the
+ * timeout elapses. Upon exit, @rc contains the value of the condition. This
+ * allows you to test the condition without incurring any side effects.
+ *
+ * This primary purpose of this macro is to poll on a hardware register
+ * until a status bit changes. The timeout ensures that the loop still
+ * terminates even if the bit never changes. The delay is for devices that
+ * need a delay in between successive reads.
+ *
+ * gcc will optimize out the if-statement if @delay is a constant.
+ */
+#define spin_event_timeout(condition, timeout, delay, rc) \
+{ \
+ unsigned long __loops = tb_ticks_per_usec * timeout; \
+ unsigned long __start = get_tbl(); \
+ while (!(rc = (condition)) && (tb_ticks_since(__start) <= __loops)) \
+ if (delay) \
+ udelay(delay); \
+ else \
+ cpu_relax(); \
+}
+
#endif /* __KERNEL__ */
#endif /* _ASM_POWERPC_DELAY_H */
--
1.6.0.6
^ permalink raw reply related
* Re: Musings on PCI busses
From: David Miller @ 2009-05-19 19:05 UTC (permalink / raw)
To: arnd; +Cc: linuxppc-dev, thunderbird2k, John.Linn
In-Reply-To: <200905191812.03347.arnd@arndb.de>
From: Arnd Bergmann <arnd@arndb.de>
Date: Tue, 19 May 2009 18:12:02 +0200
> On Tuesday 19 May 2009, Grant Likely wrote:
>> 1) Probe the host controller in an of_platform driver. =A0This has t=
he
>> advantage of simplicity. =A0The probe routine will get automatically=
>> called when the PCI host controller device tree node is registered
>> with the of_platform bus. =A0The bus parenthood also gets reflected =
in
>> the device model and sysfs. =A0The disadvantage is that it defers PC=
I
>> bus probing until after the of_platform bus is probed (maybe this is=
>> okay; maybe this already happens anyway).
> =
> This is also what we do on 64-bit systems (well, Cell at this time).
> There are no fundamental problems with this, just some slightly
> unexpected interactions e.g. when you have use a PCI serial port
> as your console before probing PCI.
This is also what sparc64 does :-)
All of the individual sparc64 PCI controller types have a OF driver
and then there is a common layer of OF PCI helper code to do most
of the work.
^ permalink raw reply
* Re: Q: MTD RAM in OF Device Tree
From: Albrecht Dreß @ 2009-05-19 18:00 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <20090519122714.GH30753@pengutronix.de>
[-- Attachment #1: Type: text/plain, Size: 979 bytes --]
Hi Wolfram!
Am 19.05.09 14:27 schrieb(en) Wolfram Sang:
> I wrote such a driver (yet without partitioning support) and I am
> trying to get it mainline, just didn't get any comments so far:
>
> http://patchwork.ozlabs.org/patch/23557/
> http://patchwork.ozlabs.org/patch/23556/
Thanks a lot, this is *exactly* what I was looking for! Actually,
partition support is not important as I want to use the whole chip -
512k isn't *that* much...
> I'd be happy if you could give it a try and donate some
> {Acked|Tested|Reviewed}-by tags. Maybe this will help for my next try
> to get it mainline.
Will do that once I get it running completely. The first test
triggered some strange problems when I wrote to /dev/mtdn and read back
the data (which is supposed to give "raw" direct access, right?) - the
last dword in each 512 byte block is partly broken. Probably something
in the localbus layout or timing...
Thanks again,
Albrecht.
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: Musings on PCI busses
From: Grant Likely @ 2009-05-19 16:30 UTC (permalink / raw)
To: Stephen Neuendorffer; +Cc: linuxppc-dev, Roderick Colenbrander, John Linn
In-Reply-To: <20090519162511.7454D17E8058@mail19-dub.bigfish.com>
On Tue, May 19, 2009 at 10:25 AM, Stephen Neuendorffer
<stephen.neuendorffer@xilinx.com> wrote:
>
>> 1) Probe the host controller in an of_platform driver. =A0This has the
>> advantage of simplicity. =A0The probe routine will get automatically
>> called when the PCI host controller device tree node is registered
>> with the of_platform bus. =A0The bus parenthood also gets reflected in
>> the device model and sysfs. =A0The disadvantage is that it defers PCI
>> bus probing until after the of_platform bus is probed (maybe this is
>> okay; maybe this already happens anyway).
>>
>> 2) Probe the host controller in an subsys_initcall(). =A0Advantage is
>> PCI can be probed earlier in the init path. =A0Disadvantages (minor) are
>> that it will always get called if the driver is enabled, and it needs
>> to manually search the device tree for PCI nodes.
>>
>> I'm leaning towards making it an of_platform driver. =A0Doing so also
>> makes it available to other powerpc processors (not just virtex) in
>> the case where a Xilinx FPGA is welded up to a discrete SoC and a host
>> controller instance is put into the FPGA. =A0(one of those weird things
>> people do when they have an FPGA in their system).
>
> I agree that something is called for... =A0The first might be slightly
> simpler, since it would probably transparently deal with the presence
> of more than one PLB->PCI bridge?
Yes, I think so.
g.
--=20
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* RE: Musings on PCI busses
From: Stephen Neuendorffer @ 2009-05-19 16:25 UTC (permalink / raw)
To: Grant Likely, Benjamin Herrenschmidt, Kumar Gala, Josh Boyer,
Roderick Colenbrander, John Linn, linuxppc-dev
In-Reply-To: <fa686aa40905190828x251765dek586f5bf8e73e4cf7@mail.gmail.com>
> 1) Probe the host controller in an of_platform driver. This has the
> advantage of simplicity. The probe routine will get automatically
> called when the PCI host controller device tree node is registered
> with the of_platform bus. The bus parenthood also gets reflected in
> the device model and sysfs. The disadvantage is that it defers PCI
> bus probing until after the of_platform bus is probed (maybe this is
> okay; maybe this already happens anyway).
> =
> 2) Probe the host controller in an subsys_initcall(). Advantage is
> PCI can be probed earlier in the init path. Disadvantages (minor) are
> that it will always get called if the driver is enabled, and it needs
> to manually search the device tree for PCI nodes.
> =
> I'm leaning towards making it an of_platform driver. Doing so also
> makes it available to other powerpc processors (not just virtex) in
> the case where a Xilinx FPGA is welded up to a discrete SoC and a host
> controller instance is put into the FPGA. (one of those weird things
> people do when they have an FPGA in their system).
I agree that something is called for... The first might be slightly
simpler, since it would probably transparently deal with the presence
of more than one PLB->PCI bridge?
Steve
This email and any attachments are intended for the sole use of the named r=
ecipient(s) and contain(s) confidential information that may be proprietary=
, privileged or copyrighted under applicable law. If you are not the intend=
ed recipient, do not read, copy, or forward this email message or any attac=
hments. Delete this email message and any attachments immediately.
^ permalink raw reply
* Re: Musings on PCI busses
From: Arnd Bergmann @ 2009-05-19 16:12 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Roderick Colenbrander, John Linn
In-Reply-To: <fa686aa40905190828x251765dek586f5bf8e73e4cf7@mail.gmail.com>
On Tuesday 19 May 2009, Grant Likely wrote:
> 1) Probe the host controller in an of_platform driver. =A0This has the
> advantage of simplicity. =A0The probe routine will get automatically
> called when the PCI host controller device tree node is registered
> with the of_platform bus. =A0The bus parenthood also gets reflected in
> the device model and sysfs. =A0The disadvantage is that it defers PCI
> bus probing until after the of_platform bus is probed (maybe this is
> okay; maybe this already happens anyway).
This is also what we do on 64-bit systems (well, Cell at this time).
There are no fundamental problems with this, just some slightly
unexpected interactions e.g. when you have use a PCI serial port
as your console before probing PCI.
Making CONFIG_PPC_OF_PLATFORM_PCI probably requires some more
consolidation between pci_32.c and pci_64.c, but I'd consider
this a good thing.
Arnd <><
^ permalink raw reply
* Musings on PCI busses
From: Grant Likely @ 2009-05-19 15:28 UTC (permalink / raw)
To: Benjamin Herrenschmidt, Kumar Gala, Josh Boyer,
Roderick Colenbrander, John Linn, linuxppc-dev
Hey all,
I've been having some thoughts on PCI host controller probing and how
best to handle it. Currently AFAICT, the SoC platform code explicitly
calls the PCI setup code. In all of the existing SoCs this works fine
because there is SoC specific platform code which knows what PCI
busses to expect on the SoC.
I'm now looking at the case of Xilinx Virtex FPGA support. Because it
is an FPGA and the SW view of the design is so flexible and fluid, I'm
trying to keep platform code unified for all Virtex platforms. (ie.
two radically different board layouts can look identical from the
CPU's perspective, or the behaviour of one board can be completely
changed with a new bitstream).
Roderick has written a patch to support one of the Xilinx reference
designs that includes a PCI host controller. Right now the patch adds
a separate platform file, but I'm not comfortable with the approach
(despite suggesting it to Roderick in the first place) because it
relegates PCI support to only work with the ml510 reference design.
ie. PCI will not be automatically supported for anyone who modifies
the reference design or adds the PCI host controller to their own
design. So I've been thinking of alternatives. Here's what I've come
up with.
1) Probe the host controller in an of_platform driver. This has the
advantage of simplicity. The probe routine will get automatically
called when the PCI host controller device tree node is registered
with the of_platform bus. The bus parenthood also gets reflected in
the device model and sysfs. The disadvantage is that it defers PCI
bus probing until after the of_platform bus is probed (maybe this is
okay; maybe this already happens anyway).
2) Probe the host controller in an subsys_initcall(). Advantage is
PCI can be probed earlier in the init path. Disadvantages (minor) are
that it will always get called if the driver is enabled, and it needs
to manually search the device tree for PCI nodes.
I'm leaning towards making it an of_platform driver. Doing so also
makes it available to other powerpc processors (not just virtex) in
the case where a Xilinx FPGA is welded up to a discrete SoC and a host
controller instance is put into the FPGA. (one of those weird things
people do when they have an FPGA in their system).
Comments? Opinions?
Cheers,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: [PATCH 2/2] maps/mtd-ram: add an of-platform driver
From: Grant Likely @ 2009-05-19 14:57 UTC (permalink / raw)
To: Wolfram Sang; +Cc: linuxppc-dev, linux-mtd, ben-linux
In-Reply-To: <1232559685-2268-3-git-send-email-w.sang@pengutronix.de>
On Wed, Jan 21, 2009 at 11:41 AM, Wolfram Sang <w.sang@pengutronix.de> wrot=
e:
> Create an of-aware driver using the now exported generic functions from
> plat-ram.c. A typical oftree snipplet for it looks like this:
>
> sram@04e00000 {
> =A0 =A0 =A0 =A0compatible =3D "mtd-ram";
> =A0 =A0 =A0 =A0reg =3D <0x04e00000 0x00200000>;
> =A0 =A0 =A0 =A0bank-width =3D <2>;
> };
>
> Partitions on this device are not yet supported.
This is a new device tree binding. It must be documented in
Documentation/powerpc/dts-bindings and posted to
devicetree-discuss@ozlabs.org for review.
> diff --git a/drivers/mtd/maps/Makefile b/drivers/mtd/maps/Makefile
> index 6d9ba35..f8e3908 100644
> --- a/drivers/mtd/maps/Makefile
> +++ b/drivers/mtd/maps/Makefile
> @@ -58,6 +58,7 @@ obj-$(CONFIG_MTD_WRSBC8260) =A0 +=3D wr_sbc82xx_flash.o
> =A0obj-$(CONFIG_MTD_DMV182) =A0 =A0 =A0 +=3D dmv182.o
> =A0obj-$(CONFIG_MTD_SHARP_SL) =A0 =A0 +=3D sharpsl-flash.o
> =A0obj-$(CONFIG_MTD_PLATRAM) =A0 =A0 =A0+=3D plat-ram.o
> +obj-$(CONFIG_MTD_OFRAM) =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0+=3D of-ram.o
> =A0obj-$(CONFIG_MTD_OMAP_NOR) =A0 =A0 +=3D omap_nor.o
> =A0obj-$(CONFIG_MTD_INTEL_VR_NOR) +=3D intel_vr_nor.o
> =A0obj-$(CONFIG_MTD_BFIN_ASYNC) =A0 +=3D bfin-async-flash.o
> diff --git a/drivers/mtd/maps/of-ram.c b/drivers/mtd/maps/of-ram.c
> new file mode 100644
> index 0000000..4d334a9
> --- /dev/null
> +++ b/drivers/mtd/maps/of-ram.c
> @@ -0,0 +1,120 @@
> +/*
> + * drivers/mtd/maps/of-ram.c
> + *
> + * Generic of device based RAM map
> + *
> + * Copyright (C) 2009 Wolfram Sang, Pengutronix
> + *
> + * Using plat-ram.c by Ben Dooks
> + *
> + * This program is free software; you can redistribute it and/or modify =
it
> + * under the terms of the GNU General Public License version 2 as publis=
hed by
> + * the Free Software Foundation.
> + */
> +
> +#include <linux/module.h>
> +#include <linux/types.h>
> +#include <linux/init.h>
> +#include <linux/kernel.h>
> +#include <linux/device.h>
> +#include <linux/platform_device.h>
> +#include <linux/of_device.h>
> +#include <linux/of_platform.h>
> +#include <linux/mtd/plat-ram.h>
> +
> +static int of_ram_probe(struct of_device *op, const struct of_device_id =
*match)
__devinit
> +{
> + =A0 =A0 =A0 struct platdata_mtd_ram *pdata;
> + =A0 =A0 =A0 struct resource *resource;
> + =A0 =A0 =A0 const char *name;
> + =A0 =A0 =A0 const u32 *bankwidth;
> + =A0 =A0 =A0 int ret =3D -ENOMEM;
> +
> + =A0 =A0 =A0 pdata =3D kzalloc(sizeof(*pdata), GFP_KERNEL);
> + =A0 =A0 =A0 if (!pdata)
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 goto bad0;
> + =A0 =A0 =A0 op->dev.platform_data =3D pdata;
> +
> + =A0 =A0 =A0 name =3D of_get_property(op->node, "name", NULL);
> + =A0 =A0 =A0 if (!name) {
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 ret =3D -ENOENT;
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 dev_dbg(&op->dev, "could not get node name\=
n");
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 goto bad1;
> + =A0 =A0 =A0 }
> +
> + =A0 =A0 =A0 resource =3D kzalloc(sizeof(struct resource), GFP_KERNEL);
> + =A0 =A0 =A0 if (!resource)
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 goto bad1;
Why isn't resource on the stack?
> +
> + =A0 =A0 =A0 if (of_address_to_resource(op->node, 0, resource)) {
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 ret =3D -ENXIO;
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 dev_dbg(&op->dev, "could not create resourc=
e\n");
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 goto bad2;
> + =A0 =A0 =A0 }
> +
> + =A0 =A0 =A0 bankwidth =3D of_get_property(op->node, "bank-width", NULL)=
;
> + =A0 =A0 =A0 if (*bankwidth =3D=3D 0) {
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 ret =3D -ENOENT;
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 dev_dbg(&op->dev, "bank width not set\n");
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 goto bad2;
> + =A0 =A0 =A0 }
> + =A0 =A0 =A0 pdata->bankwidth =3D *bankwidth;
> +
> + =A0 =A0 =A0 ret =3D __platram_probe(&op->dev, name, resource, pdata);
> + =A0 =A0 =A0 kfree(resource);
> +
> + =A0 =A0 =A0 if (ret)
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 goto bad1;
> +
> + =A0 =A0 =A0 return 0;
> +
> + bad2:
> + =A0 =A0 =A0 kfree(resource);
> + bad1:
> + =A0 =A0 =A0 op->dev.platform_data =3D NULL;
> + =A0 =A0 =A0 kfree(pdata);
> + bad0:
> + =A0 =A0 =A0 return ret;
I'd rather see more meaningful labels. ie "err_kalloc:" and
"err_platram_probe:".
> +}
> +
> +static int of_ram_remove(struct of_device *op)
__devexit
> +{
> + =A0 =A0 =A0 int ret;
> + =A0 =A0 =A0 struct platdata_mtd_ram *pdata =3D op->dev.platform_data;
> +
> + =A0 =A0 =A0 ret =3D __platram_remove(&op->dev);
> + =A0 =A0 =A0 op->dev.platform_data =3D NULL;
> + =A0 =A0 =A0 kfree(pdata);
> + =A0 =A0 =A0 return ret;
> +}
> +
> +static struct of_device_id of_ram_match[] =3D {
> + =A0 =A0 =A0 { .compatible =3D "mtd-ram", },
> + =A0 =A0 =A0 {},
> +};
> +MODULE_DEVICE_TABLE(of, of_ram_match);
> +
> +static struct of_platform_driver of_ram_driver =3D {
__devinitdata
> + =A0 =A0 =A0 .owner =3D THIS_MODULE,
> + =A0 =A0 =A0 .name =3D "of-ram",
This name is too generic for an of_platform device. 'mtd' needs to be
in there somewhere.
> + =A0 =A0 =A0 .match_table =3D of_ram_match,
> + =A0 =A0 =A0 .probe =3D of_ram_probe,
> + =A0 =A0 =A0 .remove =3D of_ram_remove,
__devexit_p()
> +};
> +
> +static int __init of_ram_init(void)
> +{
> + =A0 =A0 =A0 return of_register_platform_driver(&of_ram_driver);
> +}
> +
> +static void __exit of_ram_exit(void)
> +{
> + =A0 =A0 =A0 of_unregister_platform_driver(&of_ram_driver);
> +}
> +
> +module_init(of_ram_init);
Put the module_init() statement directly after the of_ram_init() definition=
.
> +module_exit(of_ram_exit);
> +
> +MODULE_AUTHOR("Wolfram Sang");
> +MODULE_DESCRIPTION("MTD OF RAM map driver");
> +MODULE_LICENSE("GPL v2");
> --
> 1.5.6.5
>
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
>
--=20
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: [PATCH 1/2] maps/mtd-ram: refactor probe and remove
From: Grant Likely @ 2009-05-19 14:41 UTC (permalink / raw)
To: Wolfram Sang; +Cc: linuxppc-dev, linux-mtd, ben-linux
In-Reply-To: <1232559685-2268-2-git-send-email-w.sang@pengutronix.de>
On Wed, Jan 21, 2009 at 11:41 AM, Wolfram Sang <w.sang@pengutronix.de> wrot=
e:
> Refactor the probe and remove routines of the mtd-ram driver to export
> a generic part which can later be accessed by an of-counterpart of this
> driver. Tested with a phyCORE-MPC5200B-IO.
>
> Signed-off-by: Wolfram Sang <w.sang@pengutronix.de>
On brief review, looks okay by me.
Acked-by: Grant Likely <grant.likely@secretlab.ca>
> ---
> =A0drivers/mtd/maps/plat-ram.c =A0| =A0123 +++++++++++++++++++++---------=
------------
> =A0include/linux/mtd/plat-ram.h | =A0 =A04 ++
> =A02 files changed, 66 insertions(+), 61 deletions(-)
>
> diff --git a/drivers/mtd/maps/plat-ram.c b/drivers/mtd/maps/plat-ram.c
> index e7dd9c8..1582cd6 100644
> --- a/drivers/mtd/maps/plat-ram.c
> +++ b/drivers/mtd/maps/plat-ram.c
> @@ -50,16 +50,6 @@ struct platram_info {
> =A0 =A0 =A0 =A0struct platdata_mtd_ram *pdata;
> =A0};
>
> -/* to_platram_info()
> - *
> - * device private data to struct platram_info conversion
> -*/
> -
> -static inline struct platram_info *to_platram_info(struct platform_devic=
e *dev)
> -{
> - =A0 =A0 =A0 return (struct platram_info *)platform_get_drvdata(dev);
> -}
> -
> =A0/* platram_setrw
> =A0*
> =A0* call the platform device's set rw/ro control
> @@ -77,18 +67,14 @@ static inline void platram_setrw(struct platram_info =
*info, int to)
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0(info->pdata->set_rw)(info->dev, to);
> =A0}
>
> -/* platram_remove
> - *
> - * called to remove the device from the driver's control
> -*/
> -
> -static int platram_remove(struct platform_device *pdev)
> +int __platram_remove(struct device *dev)
> =A0{
> - =A0 =A0 =A0 struct platram_info *info =3D to_platram_info(pdev);
> + =A0 =A0 =A0 struct platram_info *info;
>
> - =A0 =A0 =A0 platform_set_drvdata(pdev, NULL);
> + =A0 =A0 =A0 dev_dbg(dev, "removing device\n");
>
> - =A0 =A0 =A0 dev_dbg(&pdev->dev, "removing device\n");
> + =A0 =A0 =A0 info =3D dev_get_drvdata(dev);
> + =A0 =A0 =A0 dev_set_drvdata(dev, NULL);
>
> =A0 =A0 =A0 =A0if (info =3D=3D NULL)
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0return 0;
> @@ -123,68 +109,49 @@ static int platram_remove(struct platform_device *p=
dev)
>
> =A0 =A0 =A0 =A0return 0;
> =A0}
> +EXPORT_SYMBOL_GPL(__platram_remove);
>
> -/* platram_probe
> +/* platram_remove
> =A0*
> - * called from device drive system when a device matching our
> - * driver is found.
> + * called to remove the device from the driver's control
> =A0*/
>
> -static int platram_probe(struct platform_device *pdev)
> +static int platram_remove(struct platform_device *pdev)
> +{
> + =A0 =A0 =A0 return __platram_remove(&pdev->dev);
> +}
> +
> +int __platram_probe(struct device *dev, const char *name,
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 struct resource *res, struc=
t platdata_mtd_ram *pdata)
> =A0{
> - =A0 =A0 =A0 struct platdata_mtd_ram *pdata;
> =A0 =A0 =A0 =A0struct platram_info *info;
> - =A0 =A0 =A0 struct resource *res;
> =A0 =A0 =A0 =A0int err =3D 0;
>
> - =A0 =A0 =A0 dev_dbg(&pdev->dev, "probe entered\n");
> -
> - =A0 =A0 =A0 if (pdev->dev.platform_data =3D=3D NULL) {
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 dev_err(&pdev->dev, "no platform data suppl=
ied\n");
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 err =3D -ENOENT;
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 goto exit_error;
> - =A0 =A0 =A0 }
> -
> - =A0 =A0 =A0 pdata =3D pdev->dev.platform_data;
> -
> =A0 =A0 =A0 =A0info =3D kzalloc(sizeof(*info), GFP_KERNEL);
> =A0 =A0 =A0 =A0if (info =3D=3D NULL) {
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 dev_err(&pdev->dev, "no memory for flash in=
fo\n");
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 dev_err(dev, "no memory for flash info\n");
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0err =3D -ENOMEM;
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0goto exit_error;
> =A0 =A0 =A0 =A0}
>
> - =A0 =A0 =A0 platform_set_drvdata(pdev, info);
> + =A0 =A0 =A0 dev_set_drvdata(dev, info);
>
> - =A0 =A0 =A0 info->dev =3D &pdev->dev;
> + =A0 =A0 =A0 info->dev =3D dev;
> =A0 =A0 =A0 =A0info->pdata =3D pdata;
>
> - =A0 =A0 =A0 /* get the resource for the memory mapping */
> -
> - =A0 =A0 =A0 res =3D platform_get_resource(pdev, IORESOURCE_MEM, 0);
> -
> - =A0 =A0 =A0 if (res =3D=3D NULL) {
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 dev_err(&pdev->dev, "no memory resource spe=
cified\n");
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 err =3D -ENOENT;
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 goto exit_free;
> - =A0 =A0 =A0 }
> -
> - =A0 =A0 =A0 dev_dbg(&pdev->dev, "got platform resource %p (0x%llx)\n", =
res,
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 (unsigned long long)res->start);
> -
> =A0 =A0 =A0 =A0/* setup map parameters */
>
> =A0 =A0 =A0 =A0info->map.phys =3D res->start;
> =A0 =A0 =A0 =A0info->map.size =3D (res->end - res->start) + 1;
> =A0 =A0 =A0 =A0info->map.name =3D pdata->mapname !=3D NULL ?
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 (char *)pdata->mapname : (c=
har *)pdev->name;
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 (char *)pdata->mapname : (c=
har *)name;
> =A0 =A0 =A0 =A0info->map.bankwidth =3D pdata->bankwidth;
>
> =A0 =A0 =A0 =A0/* register our usage of the memory area */
>
> - =A0 =A0 =A0 info->area =3D request_mem_region(res->start, info->map.siz=
e, pdev->name);
> + =A0 =A0 =A0 info->area =3D request_mem_region(res->start, info->map.siz=
e, name);
> =A0 =A0 =A0 =A0if (info->area =3D=3D NULL) {
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 dev_err(&pdev->dev, "failed to request memo=
ry region\n");
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 dev_err(dev, "failed to request memory regi=
on\n");
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0err =3D -EIO;
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0goto exit_free;
> =A0 =A0 =A0 =A0}
> @@ -192,17 +159,17 @@ static int platram_probe(struct platform_device *pd=
ev)
> =A0 =A0 =A0 =A0/* remap the memory area */
>
> =A0 =A0 =A0 =A0info->map.virt =3D ioremap(res->start, info->map.size);
> - =A0 =A0 =A0 dev_dbg(&pdev->dev, "virt %p, %lu bytes\n", info->map.virt,=
info->map.size);
> + =A0 =A0 =A0 dev_dbg(dev, "virt %p, %lu bytes\n", info->map.virt, info->=
map.size);
>
> =A0 =A0 =A0 =A0if (info->map.virt =3D=3D NULL) {
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 dev_err(&pdev->dev, "failed to ioremap() re=
gion\n");
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 dev_err(dev, "failed to ioremap() region\n"=
);
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0err =3D -EIO;
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0goto exit_free;
> =A0 =A0 =A0 =A0}
>
> =A0 =A0 =A0 =A0simple_map_init(&info->map);
>
> - =A0 =A0 =A0 dev_dbg(&pdev->dev, "initialised map, probing for mtd\n");
> + =A0 =A0 =A0 dev_dbg(dev, "initialised map, probing for mtd\n");
>
> =A0 =A0 =A0 =A0/* probe for the right mtd map driver
> =A0 =A0 =A0 =A0 * supplied by the platform_data struct */
> @@ -218,7 +185,7 @@ static int platram_probe(struct platform_device *pdev=
)
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0info->mtd =3D do_map_probe("map_ram", &inf=
o->map);
>
> =A0 =A0 =A0 =A0if (info->mtd =3D=3D NULL) {
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 dev_err(&pdev->dev, "failed to probe for ma=
p_ram\n");
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 dev_err(dev, "failed to probe for map_ram\n=
");
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0err =3D -ENOMEM;
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0goto exit_free;
> =A0 =A0 =A0 =A0}
> @@ -249,20 +216,54 @@ static int platram_probe(struct platform_device *pd=
ev)
> =A0#endif /* CONFIG_MTD_PARTITIONS */
>
> =A0 =A0 =A0 =A0if (add_mtd_device(info->mtd)) {
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 dev_err(&pdev->dev, "add_mtd_device() faile=
d\n");
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 dev_err(dev, "add_mtd_device() failed\n");
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0err =3D -ENOMEM;
> =A0 =A0 =A0 =A0}
>
> =A0 =A0 =A0 =A0if (!err)
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 dev_info(&pdev->dev, "registered mtd device=
\n");
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 dev_info(dev, "registered mtd device\n");
>
> =A0 =A0 =A0 =A0return err;
>
> =A0exit_free:
> - =A0 =A0 =A0 platram_remove(pdev);
> + =A0 =A0 =A0 __platram_remove(dev);
> =A0exit_error:
> =A0 =A0 =A0 =A0return err;
> =A0}
> +EXPORT_SYMBOL_GPL(__platram_probe);
> +
> +/* platram_probe
> + *
> + * called from device drive system when a device matching our
> + * driver is found.
> +*/
> +
> +static int platram_probe(struct platform_device *pdev)
> +{
> + =A0 =A0 =A0 struct platdata_mtd_ram *pdata;
> + =A0 =A0 =A0 struct resource *res;
> +
> + =A0 =A0 =A0 dev_dbg(&pdev->dev, "probe entered\n");
> +
> + =A0 =A0 =A0 pdata =3D pdev->dev.platform_data;
> + =A0 =A0 =A0 if (pdata =3D=3D NULL) {
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 dev_err(&pdev->dev, "no platform data suppl=
ied\n");
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 return -ENOENT;
> + =A0 =A0 =A0 }
> +
> + =A0 =A0 =A0 /* get the resource for the memory mapping */
> +
> + =A0 =A0 =A0 res =3D platform_get_resource(pdev, IORESOURCE_MEM, 0);
> + =A0 =A0 =A0 if (res =3D=3D NULL) {
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 dev_err(&pdev->dev, "no memory resource spe=
cified\n");
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 return -ENOENT;
> + =A0 =A0 =A0 }
> +
> + =A0 =A0 =A0 dev_dbg(&pdev->dev, "got platform resource %p (0x%llx)\n", =
res,
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 (unsigned long long)res->start);
> +
> + =A0 =A0 =A0 return __platram_probe(&pdev->dev, pdev->name, res, pdata);
> +}
>
> =A0/* device driver info */
>
> diff --git a/include/linux/mtd/plat-ram.h b/include/linux/mtd/plat-ram.h
> index e07890a..c522562 100644
> --- a/include/linux/mtd/plat-ram.h
> +++ b/include/linux/mtd/plat-ram.h
> @@ -31,4 +31,8 @@ struct platdata_mtd_ram {
> =A0 =A0 =A0 =A0void =A0 =A0(*set_rw)(struct device *dev, int to);
> =A0};
>
> +extern int __platram_probe(struct device *dev, const char *name,
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 struct resource *res, struc=
t platdata_mtd_ram *pdata);
> +extern int __platram_remove(struct device *dev);
> +
> =A0#endif /* __LINUX_MTD_PLATRAM_H */
> --
> 1.5.6.5
>
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
>
--=20
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: Q: MTD RAM in OF Device Tree
From: Grant Likely @ 2009-05-19 14:39 UTC (permalink / raw)
To: Wolfram Sang; +Cc: Albrecht Dreß, linux-mtd, linuxppc-dev
In-Reply-To: <20090519122714.GH30753@pengutronix.de>
On Tue, May 19, 2009 at 6:27 AM, Wolfram Sang <w.sang@pengutronix.de> wrote=
:
> Hello Albrecht,
>
> (adding linux-mtd)
>
> On Tue, May 19, 2009 at 01:59:00PM +0200, Albrecht Dre=DF wrote:
>>
>> is there a standard way to define a ram chip (in my case a battery-buffe=
red
>> nv ram, attached to the 5200's Local Bus) in the OF tree, and are there =
any
>> drivers (on 2.6.29.1) which pick up the chip/partition specification for=
mtd?
>> Does such a driver exist, or do I have to write one (probably based on
>> plat-ram.c?)? =A0I think of something like
>
> I wrote such a driver (yet without partitioning support) and I am trying =
to get
> it mainline, just didn't get any comments so far:
>
> http://patchwork.ozlabs.org/patch/23557/
> http://patchwork.ozlabs.org/patch/23556/
>
> I'd be happy if you could give it a try and donate some
> {Acked|Tested|Reviewed}-by tags. Maybe this will help for my next try to =
get
> it mainline.
I missed them when you posted them. I'll go look now.
--=20
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Initialize DBCR0 for PPC440 targets
From: srikanth krishnakar @ 2009-05-19 13:08 UTC (permalink / raw)
To: Linuxppc-dev; +Cc: Linuxppc-embedded
Hi,
kernel- 2.6.29
Debug technique: KGDB
The PowerPC kernel does not initialize the PPC440 DBCR0 register. This
prevents the use of software breakpoints in case of internal debug
mode. Looking into head_fsl_booke.S for initialization of DBCR0 is
used by boot-loaders.
It seems head_44x.S lacks this step of DBCR0 register initialization.
So fixing this with initializing the DBCR0 register as shown below :
Subject: [PATCH] powerpc: 44x: Initialize DBCR0 for targets not having
bootloader
The kernel does not initialize the PPC440 DBCR0 register.
This prevents (among other things) the use of software
breakpoints with GDB. The boot loaders probably do initialize
this but few targets run without a boot loader
---
arch/powerpc/kernel/head_44x.S | 12 ++++++++++++
1 files changed, 12 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/kernel/head_44x.S b/arch/powerpc/kernel/head_44x.S
index a4a890a..b413bc4 100644
--- a/arch/powerpc/kernel/head_44x.S
+++ b/arch/powerpc/kernel/head_44x.S
@@ -240,6 +240,18 @@ skpinv: addi r4,r4,1 /* Increment */
lis r4,interrupt_base@h /* IVPR only uses the high 16-bits */
mtspr SPRN_IVPR,r4
+#if !defined(CONFIG_BDI_SWITCH)
+ /*
+ * The Abatron BDI JTAG debugger does not tolerate others
+ * mucking with the debug registers.
+ */
+ lis r2,DBCR0_IDM@h
+ mtspr SPRN_DBCR0,r2
+ isync
+ /* clear any residual debug events */
+ li r2,-1
+ mtspr SPRN_DBSR,r2
+#endif
/*
* This is where the main kernel code starts.
*/
Any suggestions or comments on this ?
Thanks,
-Srikant
^ permalink raw reply related
* Re: [PATCH V2 2/3] powerpc: Add support for swiotlb on 32-bit
From: Kumar Gala @ 2009-05-19 13:04 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: fujita.tomonori, linuxppc-dev
In-Reply-To: <1242683395.16901.0.camel@pasglop>
On May 18, 2009, at 4:49 PM, Benjamin Herrenschmidt wrote:
> On Mon, 2009-05-18 at 08:25 -0500, Kumar Gala wrote:
>>
>> Part of this is how the generic swiotlb code works and part of it
>> was
>> our desire not to bloat dev archdata by adding such info that as you
>> say is either bus specific or conveyed in the dma addr mask.
>
> Right but perf sucks :-)
>
> Maybe an option is to clamp the DMA mask when it's set by the driver
> to
> limit it to the available inbound window ?
Clamping the DMA mask is even worse than the additional indirection
for us. We have valid scenarios in which we'd have 512M of outbound
PCI address space and 4G of mem and thus 3.5G of inbound PCI address
space. With the DMA mask we'd be limited to 2G and bouncing from
2..3.5G when we don't need to.
I think our options are to change archdata as follows:
Option 1 - just add a new data member to dev_archdata
struct dev_archdata {
/* Optional pointer to an OF device node */
struct device_node *of_node;
/* DMA operations on that device */
struct dma_mapping_ops *dma_ops;
void *dma_data;
dma_addr_t direct_dma_addr;
};
Option 2 - introduce a proper container for how we use dma_data. This
may just be moving the indirection from an indirection function call
to an indirection data reference:
struct dma_data {
dma_addr_t offset;
dma_addr_t direct_dma_addr;
struct iommu_table *iommu_table;
};
struct dev_archdata {
/* Optional pointer to an OF device node */
struct device_node *of_node;
/* DMA operations on that device */
struct dma_mapping_ops *dma_ops;
struct dma_data *dma_data;
};
Option 3 - use dma_data to keep the addr at which we need to bounce vs
not for SWIOTLB - this has potential issues w/conflicting with
dma_data being used as the dma_offset. (need to think on that a bit
more). Additionally this has the benefit in that we need dma_data to
be a 64-bit quantity on ppc32 w/>32-bit phys addr.
struct dev_archdata {
/* Optional pointer to an OF device node */
struct device_node *of_node;
/* DMA operations on that device */
struct dma_mapping_ops *dma_ops;
dma_addr_t dma_data;
};
others??
- k
^ permalink raw reply
* Re: [PATCH v7] introduce macro spin_event_timeout()
From: Grant Likely @ 2009-05-19 12:30 UTC (permalink / raw)
To: Sean MacLennan; +Cc: scottwood, linuxppc-dev, Timur Tabi
In-Reply-To: <20090518235756.7a0b1061@lappy.seanm.ca>
On Mon, May 18, 2009 at 9:57 PM, Sean MacLennan <smaclennan@pikatech.com> w=
rote:
> On Mon, 18 May 2009 20:58:03 -0600
> Grant Likely <grant.likely@secretlab.ca> wrote:
>
>> Then let it lie fallow on the list and in patchwork. =A0It is published,
>> and people know that it is available (I'll certainly consider it as I
>> do driver work), but there must be real (not just theoretical) in
>> kernel users of the interface. =A0I someone wants to use it, then they
>> can add it to their series or ping the list about getting it merged.
>
> That's too bad. If it is ever merged, could you also ping the list?
If you intend to use it, then post a patch to do so and state that it
depends on Timur's patch.
g.
--=20
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: Q: MTD RAM in OF Device Tree
From: Wolfram Sang @ 2009-05-19 12:27 UTC (permalink / raw)
To: Albrecht Dreß; +Cc: linuxppc-dev, linux-mtd
In-Reply-To: <5023288.1242734340173.JavaMail.ngmail@webmail15.arcor-online.net>
[-- Attachment #1: Type: text/plain, Size: 1022 bytes --]
Hello Albrecht,
(adding linux-mtd)
On Tue, May 19, 2009 at 01:59:00PM +0200, Albrecht Dreß wrote:
>
> is there a standard way to define a ram chip (in my case a battery-buffered
> nv ram, attached to the 5200's Local Bus) in the OF tree, and are there any
> drivers (on 2.6.29.1) which pick up the chip/partition specification for mtd?
> Does such a driver exist, or do I have to write one (probably based on
> plat-ram.c?)? I think of something like
I wrote such a driver (yet without partitioning support) and I am trying to get
it mainline, just didn't get any comments so far:
http://patchwork.ozlabs.org/patch/23557/
http://patchwork.ozlabs.org/patch/23556/
I'd be happy if you could give it a try and donate some
{Acked|Tested|Reviewed}-by tags. Maybe this will help for my next try to get
it mainline.
Regards,
Wolfram
--
Pengutronix e.K. | Wolfram Sang |
Industrial Linux Solutions | http://www.pengutronix.de/ |
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Q: MTD RAM in OF Device Tree
From: Albrecht Dreß @ 2009-05-19 11:59 UTC (permalink / raw)
To: linuxppc-dev
Hi all,
is there a standard way to define a ram chip (in my case a battery-buffered=
nv ram, attached to the 5200's Local Bus) in the OF tree, and are there an=
y drivers (on 2.6.29.1) which pick up the chip/partition specification for =
mtd? Does such a driver exist, or do I have to write one (probably based o=
n plat-ram.c?)? I think of something like
localbus {
=09[...]
=09ranges =3D < 0 0 0xfe000000 0x02000000
=09=09 1 0 0xfc000000 0x00080000>;
flash@0,0 {
=09=09[flash definition & partitions]
=09};
=09nvram@1,0 {
=09=09compatible =3D "mtd-ram";
=09=09reg =3D <1 0x0 0x00080000>;
=09=09bank-width =3D <2>;
=09=09device-width =3D <2>;
=09=09#size-cells =3D <1>;
=09=09#address-cells =3D <1>;
=09=09part@0 {
=09=09=09label =3D "pdata";
=09=09=09reg =3D <0x00000000 0x00080000>;
=09=09};
=09};
};
Thanks,
Albrecht.
Arcor.de Gaming Area - kostenfrei daddeln bis der Arzt kommt!
Jetzt checken und aus =FCber 80 Spielen w=E4hlen!
http://www.arcor.de/footer-gaming/
^ permalink raw reply
* Re: [PATCH 02/12] fs_enet: Add MPC5121 FEC support.
From: Piotr Zięcik @ 2009-05-19 11:26 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: Becky Bruce, Wolfgang Denk, Detlev Zundel, John Rigby, netdev,
linuxppc-dev, Scott Wood
In-Reply-To: <1242685051.16901.6.camel@pasglop>
Tuesday 19 May 2009 00:17:31 Benjamin Herrenschmidt wrote:
>
> We are close to the point where we can make this a runtime option
> though, by just having a different set of dma_ops hooked in.
>
Is somebody currently working on it? If yes, where we can see
code ?
=2D-=20
Best Regards.
Piotr Zi=EAcik
^ permalink raw reply
* [PATCH] powerpc/86xx: Add I2C device mappings in DTS for SBC610
From: Martyn Welch @ 2009-05-19 9:40 UTC (permalink / raw)
To: galak, linuxppc-dev
Mappings for temperature sensors (adt7461 and lm92) are missing from the
SBC610's DTS file.
Signed-off-by: Martyn Welch <martyn.welch@gefanuc.com>
---
arch/powerpc/boot/dts/gef_sbc610.dts | 10 ++++++++++
1 files changed, 10 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/boot/dts/gef_sbc610.dts b/arch/powerpc/boot/dts/gef_sbc610.dts
index 6898d7e..85d1416 100644
--- a/arch/powerpc/boot/dts/gef_sbc610.dts
+++ b/arch/powerpc/boot/dts/gef_sbc610.dts
@@ -153,6 +153,16 @@
interrupt-parent = <&mpic>;
dfsrr;
+ hwmon@48 {
+ compatible = "national,lm92";
+ reg = <0x48>;
+ };
+
+ hwmon@4c {
+ compatible = "adi,adt7461";
+ reg = <0x4c>;
+ };
+
rtc@51 {
compatible = "epson,rx8581";
reg = <0x00000051>;
^ 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