* Re: [git pull] Please pull powerpc.git merge branch
From: Michael Ellerman @ 2010-11-19 5:44 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: linuxppc-dev list
In-Reply-To: <20101119163104.624d264d.sfr@canb.auug.org.au>
[-- Attachment #1: Type: text/plain, Size: 446 bytes --]
On Fri, 2010-11-19 at 16:31 +1100, Stephen Rothwell wrote:
> On Fri, 19 Nov 2010 09:08:02 +1100 Michael Ellerman <michael@ellerman.id.au> wrote:
> >
> > I vote for:
> >
> > -> Exception: 401 (Instruction Access) at 00000000f7937794
>
> Or:
>
> ☛ Exception: 401 (Instruction Access) at 00000000f7937794
Let's get serious, it's _really_ like a phone call:
☎ Exception: 401 (Instruction Access) at 00000000f7937794
cheers
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply
* Re: [git pull] Please pull powerpc.git merge branch
From: Michael Neuling @ 2010-11-19 6:02 UTC (permalink / raw)
To: michael; +Cc: Stephen Rothwell, linuxppc-dev list
In-Reply-To: <1290145458.2867.3.camel@concordia>
> On Fri, 2010-11-19 at 16:31 +1100, Stephen Rothwell wrote:
> > On Fri, 19 Nov 2010 09:08:02 +1100 Michael Ellerman <michael@ellerman.id.=
> au> wrote:
> > >
> > > I vote for:
> > >=20
> > > -> Exception: 401 (Instruction Access) at 00000000f7937794
> >=20
> > Or:
> >=20
> > =E2=98=9B Exception: 401 (Instruction Access) at 00000000f7937794
>
> Let's get serious, it's _really_ like a phone call:
>
> =E2=98=8E Exception: 401 (Instruction Access) at 00000000f7937794
We need a dedicated NACK char!
Mikey
^ permalink raw reply
* Change in PCI behaviour
From: Gary Thomas @ 2010-11-19 15:42 UTC (permalink / raw)
To: Linux PPC Development
I'm upgrading from 2.6.28 to 2.6.32 (yes, I know it's not the latest,
but it's the best I can do at the moment). There seems to have been
a change in how the PCI bus is scanned/assigned which is causing me
some hardware problems. My hardware is FSL MPC8347 and the problem
is likely specific to the FSL PCI code.
My system has 256MB RAM, fully mapped into the PCI export window.
There are an additional 2 devices on the PCI bus. On 2.6.28, I
get this layout:
PCI: Probing PCI hardware
pci 0000:00:00.0: reg 10 32bit mmio: [0x000000-0x0fffff]
pci 0000:00:00.0: reg 18 64bit mmio: [0x000000-0xfffffff]
pci 0000:00:0b.0: reg 10 io port: [0x1000-0x1007]
pci 0000:00:0b.0: reg 14 io port: [0x1008-0x100b]
pci 0000:00:0b.0: reg 18 io port: [0x1010-0x1017]
pci 0000:00:0b.0: reg 1c io port: [0x1018-0x101b]
pci 0000:00:0b.0: reg 20 io port: [0x1020-0x102f]
pci 0000:00:0b.0: reg 24 32bit mmio: [0x100000-0x1001ff]
pci 0000:00:0b.0: reg 30 32bit mmio: [0x000000-0x07ffff]
pci 0000:00:0b.0: supports D1 D2
pci 0000:00:0c.0: reg 10 32bit mmio: [0x4000000-0x7ffffff]
PCI: Cannot allocate resource region 5 of device 0000:00:0b.0, will remap
PCI: Cannot allocate resource region 0 of device 0000:00:0c.0, will remap
bus: 00 index 0 io port: [0x00-0xfffff]
bus: 00 index 1 mmio: [0xc0000000-0xdfffffff]
There are no notices, but the key item is that device 0000:00:0c.0 gets
mapped at PCI address 0xD0000000.
On 2.6.32, I get this:
PCI: Probing PCI hardware
pci 0000:00:0b.0: reg 10: [io 0x1000-0x1007]
pci 0000:00:0b.0: reg 14: [io 0x1008-0x100b]
pci 0000:00:0b.0: reg 18: [io 0x1010-0x1017]
pci 0000:00:0b.0: reg 1c: [io 0x1018-0x101b]
pci 0000:00:0b.0: reg 20: [io 0x1020-0x102f]
pci 0000:00:0b.0: reg 24: [mem 0x00100000-0x001001ff]
pci 0000:00:0b.0: reg 30: [mem 0x00000000-0x0007ffff pref]
pci 0000:00:0b.0: supports D1 D2
pci 0000:00:0c.0: reg 10: [mem 0x04000000-0x07ffffff]
PCI: Cannot allocate resource region 5 of device 0000:00:0b.0, will remap
PCI: Cannot allocate resource region 0 of device 0000:00:0c.0, will remap
pci 0000:00:0c.0: BAR 0: assigned [mem 0xc0000000-0xc3ffffff]
pci 0000:00:0c.0: BAR 0: set to [mem 0xc0000000-0xc3ffffff] (PCI address [0xc0000000-0xc3ffffff]
pci 0000:00:0b.0: BAR 6: assigned [mem 0xc4000000-0xc407ffff pref]
pci 0000:00:0b.0: BAR 5: assigned [mem 0xc4080000-0xc40801ff]
pci 0000:00:0b.0: BAR 5: set to [mem 0xc4080000-0xc40801ff] (PCI address [0xc4080000-0xc40801ff]
pci_bus 0000:00: resource 0 [io 0x0000-0xfffff]
pci_bus 0000:00: resource 1 [mem 0xc0000000-0xdfffffff]
In this case, note that PCI device 0000:00:0c.0 is at 0xc0000000.
This causes problems because it's a truly stupid device that does
not work properly at PCI [relative] address 0x00000000. It simply
does not respond at that address. Pick anywhere else and it will
work fine!
On 2.6.28, I get this layout:
# ls -l /sys/bus/pci/devices
lrwxrwxrwx 1 root root 0 Jan 1 1970 0000:00:00.0 -> ../../../devices/pci0000:00/0000:00:00.0
lrwxrwxrwx 1 root root 0 Jan 1 1970 0000:00:0b.0 -> ../../../devices/pci0000:00/0000:00:0b.0
lrwxrwxrwx 1 root root 0 Jan 1 1970 0000:00:0c.0 -> ../../../devices/pci0000:00/0000:00:0c.0
# cat /sys/bus/pci/devices/0000\:00\:0c.0/resource
0x00000000d0000000 0x00000000d3ffffff 0x0000000000020200
0x0000000000000000 0x0000000000000000 0x0000000000000000
0x0000000000000000 0x0000000000000000 0x0000000000000000
0x0000000000000000 0x0000000000000000 0x0000000000000000
0x0000000000000000 0x0000000000000000 0x0000000000000000
0x0000000000000000 0x0000000000000000 0x0000000000000000
0x0000000000000000 0x0000000000000000 0x0000000000000000
On 2.6.32, the final layout looks like this:
# ls -l /sys/bus/pci/devices/
lrwxrwxrwx 1 root root 0 Jan 1 1970 0000:00:0b.0 -> ../../../devices/pci0000:00/0000:00:0b.0
lrwxrwxrwx 1 root root 0 Jan 1 1970 0000:00:0c.0 -> ../../../devices/pci0000:00/0000:00:0c.0
# cat /sys/bus/pci/devices/0000\:00\:0c.0/resource
0x00000000c0000000 0x00000000c3ffffff 0x0000000000020200
0x0000000000000000 0x0000000000000000 0x0000000000000000
0x0000000000000000 0x0000000000000000 0x0000000000000000
0x0000000000000000 0x0000000000000000 0x0000000000000000
0x0000000000000000 0x0000000000000000 0x0000000000000000
0x0000000000000000 0x0000000000000000 0x0000000000000000
0x0000000000000000 0x0000000000000000 0x0000000000000000
Bottom line: how can I get this behaviour back (so as to get my
stupid graphics controller working again)??
Thanks for any ideas
--
------------------------------------------------------------
Gary Thomas | Consulting for the
MLB Associates | Embedded world
------------------------------------------------------------
^ permalink raw reply
* Re: Change in PCI behaviour
From: Benjamin Herrenschmidt @ 2010-11-19 21:46 UTC (permalink / raw)
To: Gary Thomas; +Cc: Linux PPC Development
In-Reply-To: <4CE69AF6.6090408@mlbassoc.com>
On Fri, 2010-11-19 at 08:42 -0700, Gary Thomas wrote:
> In this case, note that PCI device 0000:00:0c.0 is at 0xc0000000.
> This causes problems because it's a truly stupid device that does
> not work properly at PCI [relative] address 0x00000000. It simply
> does not respond at that address. Pick anywhere else and it will
> work fine!
Hrm, we used to have a trick avoid giving out the first meg of a bus to
avoid that sort of thing, I suppose it got lost. The rest is related to
the way you map your PCI I suppose in your dts. You can switch back to a
1:1 instead of 1:0 mapping I suppose.
One way to achieve the above result would be to, in your platform code,
reserve the mem region that corresponds to PCI 0...1M (c0000000...+1M)
before the device resources are assigned/allocated.
I though we had code to do that with the "legacy" regions somewhere...
oh well, no code at hand to check right now.
Cheers,
Ben.
^ permalink raw reply
* Re: [PATCH 1/3] misc: at24: parse OF-data, too
From: Stijn Devriendt @ 2010-11-20 10:54 UTC (permalink / raw)
To: Wolfram Sang; +Cc: linuxppc-dev, devicetree-discuss
In-Reply-To: <1289995250-17927-2-git-send-email-w.sang@pengutronix.de>
Hi Wolfram,
I'm surprised that this would work. I've patched the at24 driver as well
to use OF data, but took a different approach.
As far as I could tell, using compatible = <24c64>; didn't load the right
module
(module name is at24) and using at24 caused a device id mismatch because
at24 is not a known device ID. I could be wrong here and if so, I'd very
much
like a source code hint as to why...
My patch worked by changing drivers/of/of_i2c.c to allow a generic
kind = " " statement that was filled in as i2c_board_info.type, to allow
the module name and the device id to be different.
This makes the at24 driver no longer rely on probing (which it claims
is buggy anyway) and also benefits other drivers that support multiple
devices, but where probing is difficult (e.g. lm90 driver).
I'm in the process of getting employer approval to get these patches
upstream.
Regards,
Stijn
-----Oorspronkelijk bericht-----
From: Wolfram Sang
Sent: Wednesday, November 17, 2010 1:00 PM
To: devicetree-discuss@ozlabs.org
Cc: linuxppc-dev@ozlabs.org
Subject: [PATCH 1/3] misc: at24: parse OF-data, too
Information about the pagesize and read-only-status may also come from
the devicetree. Parse this data, too, and act accordingly. While we are
here, change the initialization printout a bit. write_max is useful to
know to detect performance bottlenecks, the rest is superfluous.
Signed-off-by: Wolfram Sang <w.sang@pengutronix.de>
---
Changes since last version:
- use __be32 instead of u32
Documentation/powerpc/dts-bindings/eeprom.txt | 28 +++++++++++++++++++++
drivers/misc/eeprom/at24.c | 33
++++++++++++++++++++----
2 files changed, 55 insertions(+), 6 deletions(-)
create mode 100644 Documentation/powerpc/dts-bindings/eeprom.txt
diff --git a/Documentation/powerpc/dts-bindings/eeprom.txt
b/Documentation/powerpc/dts-bindings/eeprom.txt
new file mode 100644
index 0000000..4342c10
--- /dev/null
+++ b/Documentation/powerpc/dts-bindings/eeprom.txt
@@ -0,0 +1,28 @@
+EEPROMs (I2C)
+
+Required properties:
+
+ - compatible : should be "<manufacturer>,<type>"
+ If there is no specific driver for <manufacturer>, a generic
+ driver based on <type> is selected. Possible types are:
+ 24c00, 24c01, 24c02, 24c04, 24c08, 24c16, 24c32, 24c64,
+ 24c128, 24c256, 24c512, 24c1024, spd
+
+ - reg : the I2C address of the EEPROM
+
+Optional properties:
+
+ - pagesize : the length of the pagesize for writing. Please consult the
+ manual of your device, that value varies a lot. A wrong
value
+ may result in data loss! If not specified, a safety value of
+ '1' is used which will be very slow.
+
+ - read-only: this parameterless property disables writes to the eeprom
+
+Example:
+
+eeprom@52 {
+ compatible = "atmel,24c32";
+ reg = <0x52>;
+ pagesize = <32>;
+};
diff --git a/drivers/misc/eeprom/at24.c b/drivers/misc/eeprom/at24.c
index 559b0b3..3a53efc 100644
--- a/drivers/misc/eeprom/at24.c
+++ b/drivers/misc/eeprom/at24.c
@@ -20,6 +20,7 @@
#include <linux/log2.h>
#include <linux/bitops.h>
#include <linux/jiffies.h>
+#include <linux/of.h>
#include <linux/i2c.h>
#include <linux/i2c/at24.h>
@@ -457,6 +458,27 @@ static ssize_t at24_macc_write(struct memory_accessor
*macc, const char *buf,
/*-------------------------------------------------------------------------*/
+#ifdef CONFIG_OF
+static void at24_get_ofdata(struct i2c_client *client,
+ struct at24_platform_data *chip)
+{
+ const __be32 *val;
+ struct device_node *node = client->dev.of_node;
+
+ if (node) {
+ if (of_get_property(node, "read-only", NULL))
+ chip->flags |= AT24_FLAG_READONLY;
+ val = of_get_property(node, "pagesize", NULL);
+ if (val)
+ chip->page_size = be32_to_cpup(val);
+ }
+}
+#else
+static void at24_get_ofdata(struct i2c_client *client,
+ struct at24_platform_data *chip)
+{ }
+#endif /* CONFIG_OF */
+
static int at24_probe(struct i2c_client *client, const struct i2c_device_id
*id)
{
struct at24_platform_data chip;
@@ -485,6 +507,9 @@ static int at24_probe(struct i2c_client *client, const
struct i2c_device_id *id)
*/
chip.page_size = 1;
+ /* update chipdata if OF is present */
+ at24_get_ofdata(client, &chip);
+
chip.setup = NULL;
chip.context = NULL;
}
@@ -597,19 +622,15 @@ static int at24_probe(struct i2c_client *client, const
struct i2c_device_id *id)
i2c_set_clientdata(client, at24);
- dev_info(&client->dev, "%zu byte %s EEPROM %s\n",
+ dev_info(&client->dev, "%zu byte %s EEPROM, %s, %u bytes/write\n",
at24->bin.size, client->name,
- writable ? "(writable)" : "(read-only)");
+ writable ? "writable" : "read-only", at24->write_max);
if (use_smbus == I2C_SMBUS_WORD_DATA ||
use_smbus == I2C_SMBUS_BYTE_DATA) {
dev_notice(&client->dev, "Falling back to %s reads, "
"performance will suffer\n", use_smbus ==
I2C_SMBUS_WORD_DATA ? "word" : "byte");
}
- dev_dbg(&client->dev,
- "page_size %d, num_addresses %d, write_max %d, use_smbus %d\n",
- chip.page_size, num_addresses,
- at24->write_max, use_smbus);
/* export data to kernel code */
if (chip.setup)
--
1.7.2.3
_______________________________________________
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
^ permalink raw reply related
* Re: [PATCH 1/3] misc: at24: parse OF-data, too
From: Wolfram Sang @ 2010-11-20 12:42 UTC (permalink / raw)
To: Stijn Devriendt; +Cc: linuxppc-dev, devicetree-discuss
In-Reply-To: <5F1D4949966C4C509360407B0F948EFE@HIGHGuY>
[-- Attachment #1: Type: text/plain, Size: 1288 bytes --]
Hi,
> As far as I could tell, using compatible = <24c64>; didn't load the right
> module (module name is at24) and using at24 caused a device id mismatch
> because at24 is not a known device ID. I could be wrong here and if so, I'd
> very much like a source code hint as to why...
Have you tried "<vendor>, 24c64"? All I can say is that it works for me. Plain
at24 worked for years with pcm030.dts and pcm032.dts, so I don't know which
issue you are facing. This patch is just about extending the support.
> My patch worked by changing drivers/of/of_i2c.c to allow a generic
> kind = " " statement that was filled in as i2c_board_info.type, to allow
> the module name and the device id to be different.
> This makes the at24 driver no longer rely on probing (which it claims
> is buggy anyway) and also benefits other drivers that support multiple
> devices, but where probing is difficult (e.g. lm90 driver).
>
> I'm in the process of getting employer approval to get these patches
> upstream.
I hope you will get it approved, it is a lot easier to talk about code :)
Best 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
* Re: [PATCH 1/3] misc: at24: parse OF-data, too
From: Stijn Devriendt @ 2010-11-20 14:07 UTC (permalink / raw)
To: Wolfram Sang; +Cc: linuxppc-dev, devicetree-discuss
In-Reply-To: <20101120124226.GB11936@pengutronix.de>
On Sat, Nov 20, 2010 at 1:42 PM, Wolfram Sang <w.sang@pengutronix.de> wrote=
:
> Hi,
>
>> As far as I could tell, using compatible =3D <24c64>; didn't load the ri=
ght
>> module (module name is at24) and using at24 caused a device id mismatch
>> because at24 is not a known device ID. I could be wrong here and if so, =
I'd
>> very =A0much like a source code hint as to why...
>
> Have you tried "<vendor>, 24c64"? All I can say is that it works for me. =
Plain
> at24 worked for years with pcm030.dts and pcm032.dts, so I don't know whi=
ch
> issue you are facing. This patch is just about extending the support.
According to of_modalias_node, the prefix is stripped anyway, so that
wouldn't help.
The code probably worked using the buggy probing...
>
>> My patch worked by changing drivers/of/of_i2c.c to allow a generic
>> kind =3D " " statement that was filled in as i2c_board_info.type, to all=
ow
>> the module name and the device id to be different.
>> This makes the at24 driver no longer rely on probing (which it claims
>> is buggy anyway) and also benefits other drivers that support multiple
>> devices, but where probing is difficult (e.g. lm90 driver).
>>
>> I'm in the process of getting employer approval to get these patches
>> upstream.
>
It'll get approved ;) It's the first time I'm taking these steps, but
the procedures
are there, so at most it'll take some extra time.
> I hope you will get it approved, it is a lot easier to talk about code :)
>
> Best regards,
>
> =A0 Wolfram
>
> --
> Pengutronix e.K. =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | Wo=
lfram Sang =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0|
> Industrial Linux Solutions =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | http://www.p=
engutronix.de/ =A0|
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.9 (GNU/Linux)
>
> iEYEARECAAYFAkznwjIACgkQD27XaX1/VRssnwCgg55UCwZFLcMI8kJI3mhCJQxL
> N7kAoJHpLn5BJpNjET+ngaQFrGxUBQm1
> =3DtyTb
> -----END PGP SIGNATURE-----
>
>
^ permalink raw reply
* Re: Change in PCI behaviour
From: Gary Thomas @ 2010-11-21 17:59 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: Linux PPC Development
In-Reply-To: <1290203218.32570.48.camel@pasglop>
On 11/19/2010 02:46 PM, Benjamin Herrenschmidt wrote:
> On Fri, 2010-11-19 at 08:42 -0700, Gary Thomas wrote:
>> In this case, note that PCI device 0000:00:0c.0 is at 0xc0000000.
>> This causes problems because it's a truly stupid device that does
>> not work properly at PCI [relative] address 0x00000000. It simply
>> does not respond at that address. Pick anywhere else and it will
>> work fine!
>
> Hrm, we used to have a trick avoid giving out the first meg of a bus to
> avoid that sort of thing, I suppose it got lost. The rest is related to
> the way you map your PCI I suppose in your dts. You can switch back to a
> 1:1 instead of 1:0 mapping I suppose.
>
> One way to achieve the above result would be to, in your platform code,
> reserve the mem region that corresponds to PCI 0...1M (c0000000...+1M)
> before the device resources are assigned/allocated.
>
> I though we had code to do that with the "legacy" regions somewhere...
> oh well, no code at hand to check right now.
Thanks, I found a combo of regions in my DTS that fixed this.
That went well and the system is now running, but it's not stable :-(
It will crash randomly, generally leaving no trace of what went wrong.
I've attached a BDI to it, but mostly all it can tell me is "it's dead"
The one thing that seems to pop up is it looks like it's jumping into
space (aka the wrong place) when doing rfi (this is a guess). I've
seen things like the MSR ends up loaded with an address, or similar
strangeness.
Were there any system level changes during this period (I know it's
some time ago) that might have introduced such an instability? It's
tough to scan through the diffs and get a feeling for any little details
like this.
Any ideas or hints greatly appreciated, thanks
--
------------------------------------------------------------
Gary Thomas | Consulting for the
MLB Associates | Embedded world
------------------------------------------------------------
^ permalink raw reply
* Re: [git pull] Please pull powerpc.git merge branch
From: Michael Ellerman @ 2010-11-21 23:05 UTC (permalink / raw)
To: Michael Neuling; +Cc: Stephen Rothwell, linuxppc-dev list
In-Reply-To: <30421.1290146540@neuling.org>
[-- Attachment #1: Type: text/plain, Size: 622 bytes --]
On Fri, 2010-11-19 at 17:02 +1100, Michael Neuling wrote:
> > On Fri, 2010-11-19 at 16:31 +1100, Stephen Rothwell wrote:
> > > On Fri, 19 Nov 2010 09:08:02 +1100 Michael Ellerman <michael@ellerman.id.=
> > au> wrote:
> > > >
> > > > I vote for:
> > > >=20
> > > > -> Exception: 401 (Instruction Access) at 00000000f7937794
> > >=20
> > > Or:
> > >=20
> > > =E2=98=9B Exception: 401 (Instruction Access) at 00000000f7937794
> >
> > Let's get serious, it's _really_ like a phone call:
> >
> > =E2=98=8E Exception: 401 (Instruction Access) at 00000000f7937794
>
> We need a dedicated NACK char!
␕!
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply
* Re: Change in PCI behaviour
From: Gary Thomas @ 2010-11-22 10:01 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: Linux PPC Development
In-Reply-To: <4CE95E11.1050606@mlbassoc.com>
On 11/21/2010 10:59 AM, Gary Thomas wrote:
> On 11/19/2010 02:46 PM, Benjamin Herrenschmidt wrote:
>> On Fri, 2010-11-19 at 08:42 -0700, Gary Thomas wrote:
>>> In this case, note that PCI device 0000:00:0c.0 is at 0xc0000000.
>>> This causes problems because it's a truly stupid device that does
>>> not work properly at PCI [relative] address 0x00000000. It simply
>>> does not respond at that address. Pick anywhere else and it will
>>> work fine!
>>
>> Hrm, we used to have a trick avoid giving out the first meg of a bus to
>> avoid that sort of thing, I suppose it got lost. The rest is related to
>> the way you map your PCI I suppose in your dts. You can switch back to a
>> 1:1 instead of 1:0 mapping I suppose.
>>
>> One way to achieve the above result would be to, in your platform code,
>> reserve the mem region that corresponds to PCI 0...1M (c0000000...+1M)
>> before the device resources are assigned/allocated.
>>
>> I though we had code to do that with the "legacy" regions somewhere...
>> oh well, no code at hand to check right now.
>
> Thanks, I found a combo of regions in my DTS that fixed this.
>
> That went well and the system is now running, but it's not stable :-(
> It will crash randomly, generally leaving no trace of what went wrong.
> I've attached a BDI to it, but mostly all it can tell me is "it's dead"
> The one thing that seems to pop up is it looks like it's jumping into
> space (aka the wrong place) when doing rfi (this is a guess). I've
> seen things like the MSR ends up loaded with an address, or similar
> strangeness.
>
> Were there any system level changes during this period (I know it's
> some time ago) that might have introduced such an instability? It's
> tough to scan through the diffs and get a feeling for any little details
> like this.
>
> Any ideas or hints greatly appreciated, thanks
>
I have a bit more information on this. I'm pretty sure that the failures
are only happening in my SCSI (SATA actually) code. My board (8347ea) has
a PCI bus with a SIL SATA controller. This combo works perfectly in 2.6.28.
In 2.6.32, it will run for a while (possibly quite a while), then timeout
trying to do a large block write - typically 256 blocks. Once this timeout
happens, the SIL controller is stuck and accesses to it will eventually
cause the whole system to hang (as above).
Was there any major change in how PCI or DMA was handled between 2.6.28
and 2.6.32? Given the ephemeral nature of these failures (multiple runs
all eventually fail, but never the same twice), my only hope of fixing it
will be to have some ideas what might have changed.
Thanks for any ideas
--
------------------------------------------------------------
Gary Thomas | Consulting for the
MLB Associates | Embedded world
------------------------------------------------------------
^ permalink raw reply
* Re: Change in PCI behaviour
From: Gabriel Paubert @ 2010-11-22 10:37 UTC (permalink / raw)
To: Gary Thomas; +Cc: Linux PPC Development
In-Reply-To: <4CE69AF6.6090408@mlbassoc.com>
On Fri, Nov 19, 2010 at 08:42:46AM -0700, Gary Thomas wrote:
> In this case, note that PCI device 0000:00:0c.0 is at 0xc0000000.
> This causes problems because it's a truly stupid device that does
> not work properly at PCI [relative] address 0x00000000. It simply
> does not respond at that address. Pick anywhere else and it will
> work fine!
Yes, but it was one upon a time in the PCI spec that setting the
a base register to 0 should disable the corresponding decoder.
I don't know whether this has changed (I actually never had the
final PCI spec, only drafts). However I once had a device who
actually did not disable base addresses set to zero and this was
described as a bug in its (numerous) errata. This also caused
a lot of mayhem since in some versions/configurations it used
up to 64kB of PCI I/O space (especially fun on x86...).
Gabriel
^ permalink raw reply
* [PATCHv4] Xilinx Virtex 4 FX Soft FPU support
From: Sergey Temerkhanov @ 2010-11-22 10:50 UTC (permalink / raw)
To: linuxppc-dev
This patch enables support for Xilinx Virtex 4 FX singe-float FPU.> This patch
enables support for Xilinx Virtex 4 FX singe-float FPU.
Changelog v3-v4
-Added help for CONFIG_XILINX_SOFTFPU option
-Made kernel math emulation dependent on !PPC_FPU.
Changelog v2-v3:
-Fixed whitespaces for SAVE_FPR/REST_FPR.
-Changed description of MSR_AP bit.
-Removed the stub for APU unavailable exception.
Changelog v1->v2:
-Added MSR_AP bit definition
-Renamed CONFIG_XILINX_FPU to CONFIG_XILINX_SOFTFPU, moved it to
'Platform support' and made it Virtex4-FX-only.
-Changed SAVE_FPR/REST_FPR definition style.
Caveats:
- Hard-float binaries which rely on in-kernel math emulation will
give wrong results since they expect 64-bit double-precision instead
of 32-bit single-precision numbers which Xilinx V4-FX Soft FPU produces.
Signed-off-by: Sergey Temerkhanov<temerkhanov@cifronik.ru>
diff -r df25ff2b70a4 arch/powerpc/Kconfig
--- a/arch/powerpc/Kconfig Fri Aug 27 21:10:12 2010 +0400
+++ b/arch/powerpc/Kconfig Fri Sep 10 13:08:13 2010 +0400
@@ -293,7 +293,7 @@
config MATH_EMULATION
bool "Math emulation"
- depends on 4xx || 8xx || E200 || PPC_MPC832x || E500
+ depends on (4xx || 8xx || E200 || PPC_MPC832x || E500) && !PPC_FPU
---help---
Some PowerPC chips designed for embedded applications do not have
a floating-point unit and therefore do not implement the
diff -r df25ff2b70a4 arch/powerpc/include/asm/ppc_asm.h
--- a/arch/powerpc/include/asm/ppc_asm.h Fri Aug 27 21:10:12 2010 +0400
+++ b/arch/powerpc/include/asm/ppc_asm.h Fri Sep 10 13:08:13 2010 +0400
@@ -85,13 +85,21 @@
#define REST_8GPRS(n, base) REST_4GPRS(n, base); REST_4GPRS(n+4, base)
#define REST_10GPRS(n, base) REST_8GPRS(n, base); REST_2GPRS(n+8, base)
-#define SAVE_FPR(n, base) stfd n,THREAD_FPR0+8*TS_FPRWIDTH*(n)(base)
+
+#ifdef CONFIG_XILINX_SOFTFPU
+#define SAVE_FPR(n, base) stfs n,THREAD_FPR0+8*TS_FPRWIDTH*(n)(base)
+#define REST_FPR(n, base) lfs n,THREAD_FPR0+8*TS_FPRWIDTH*(n)(base)
+#else
+#define SAVE_FPR(n, base) stfd n,THREAD_FPR0+8*TS_FPRWIDTH*(n)(base)
+#define REST_FPR(n, base) lfd n,THREAD_FPR0+8*TS_FPRWIDTH*(n)(base)
+#endif
+
#define SAVE_2FPRS(n, base) SAVE_FPR(n, base); SAVE_FPR(n+1, base)
#define SAVE_4FPRS(n, base) SAVE_2FPRS(n, base); SAVE_2FPRS(n+2, base)
#define SAVE_8FPRS(n, base) SAVE_4FPRS(n, base); SAVE_4FPRS(n+4, base)
#define SAVE_16FPRS(n, base) SAVE_8FPRS(n, base); SAVE_8FPRS(n+8, base)
#define SAVE_32FPRS(n, base) SAVE_16FPRS(n, base); SAVE_16FPRS(n+16, base)
-#define REST_FPR(n, base) lfd n,THREAD_FPR0+8*TS_FPRWIDTH*(n)(base)
+
#define REST_2FPRS(n, base) REST_FPR(n, base); REST_FPR(n+1, base)
#define REST_4FPRS(n, base) REST_2FPRS(n, base); REST_2FPRS(n+2, base)
#define REST_8FPRS(n, base) REST_4FPRS(n, base); REST_4FPRS(n+4, base)
diff -r df25ff2b70a4 arch/powerpc/include/asm/reg.h
--- a/arch/powerpc/include/asm/reg.h Fri Aug 27 21:10:12 2010 +0400
+++ b/arch/powerpc/include/asm/reg.h Fri Sep 10 13:08:13 2010 +0400
@@ -30,6 +30,7 @@
#define MSR_ISF_LG 61 /* Interrupt 64b mode valid on 630 */
#define MSR_HV_LG 60 /* Hypervisor state */
#define MSR_VEC_LG 25 /* Enable AltiVec */
+#define MSR_AP_LG 25 /* Enable APU */
#define MSR_VSX_LG 23 /* Enable VSX */
#define MSR_POW_LG 18 /* Enable Power Management */
#define MSR_WE_LG 18 /* Wait State Enable */
@@ -71,6 +72,7 @@
#define MSR_HV 0
#endif
+#define MSR_AP __MASK(MSR_AP_LG) /* Enable APU */
#define MSR_VEC __MASK(MSR_VEC_LG) /* Enable AltiVec */
#define MSR_VSX __MASK(MSR_VSX_LG) /* Enable VSX */
#define MSR_POW __MASK(MSR_POW_LG) /* Enable Power Management */
diff -r df25ff2b70a4 arch/powerpc/kernel/fpu.S
--- a/arch/powerpc/kernel/fpu.S Fri Aug 27 21:10:12 2010 +0400
+++ b/arch/powerpc/kernel/fpu.S Fri Sep 10 13:08:13 2010 +0400
@@ -57,6 +57,9 @@
_GLOBAL(load_up_fpu)
mfmsr r5
ori r5,r5,MSR_FP
+#ifdef CONFIG_XILINX_SOFTFPU
+ oris r5,r5,MSR_AP@h
+#endif
#ifdef CONFIG_VSX
BEGIN_FTR_SECTION
oris r5,r5,MSR_VSX@h
@@ -85,6 +88,9 @@
toreal(r5)
PPC_LL r4,_MSR-STACK_FRAME_OVERHEAD(r5)
li r10,MSR_FP|MSR_FE0|MSR_FE1
+#ifdef CONFIG_XILINX_SOFTFPU
+ oris r10,r10,MSR_AP@h
+#endif
andc r4,r4,r10 /* disable FP for previous task */
PPC_STL r4,_MSR-STACK_FRAME_OVERHEAD(r5)
1:
@@ -94,6 +100,9 @@
mfspr r5,SPRN_SPRG_THREAD /* current task's THREAD (phys) */
lwz r4,THREAD_FPEXC_MODE(r5)
ori r9,r9,MSR_FP /* enable FP for current */
+#ifdef CONFIG_XILINX_SOFTFPU
+ oris r9,r9,MSR_AP@h
+#endif
or r9,r9,r4
#else
ld r4,PACACURRENT(r13)
@@ -124,6 +133,9 @@
_GLOBAL(giveup_fpu)
mfmsr r5
ori r5,r5,MSR_FP
+#ifdef CONFIG_XILINX_SOFTFPU
+ oris r5,r5,MSR_AP@h
+#endif
#ifdef CONFIG_VSX
BEGIN_FTR_SECTION
oris r5,r5,MSR_VSX@h
@@ -145,6 +157,9 @@
beq 1f
PPC_LL r4,_MSR-STACK_FRAME_OVERHEAD(r5)
li r3,MSR_FP|MSR_FE0|MSR_FE1
+#ifdef CONFIG_XILINX_SOFTFPU
+ oris r3,r3,MSR_AP@h
+#endif
#ifdef CONFIG_VSX
BEGIN_FTR_SECTION
oris r3,r3,MSR_VSX@h
diff -r df25ff2b70a4 arch/powerpc/kernel/head_40x.S
--- a/arch/powerpc/kernel/head_40x.S Fri Aug 27 21:10:12 2010 +0400
+++ b/arch/powerpc/kernel/head_40x.S Fri Sep 10 13:08:13 2010 +0400
@@ -420,7 +420,19 @@
addi r3,r1,STACK_FRAME_OVERHEAD
EXC_XFER_STD(0x700, program_check_exception)
+/* 0x0800 - FPU unavailable Exception */
+#ifdef CONFIG_PPC_FPU
+ START_EXCEPTION(0x0800, FloatingPointUnavailable)
+ NORMAL_EXCEPTION_PROLOG
+ beq 1f; \
+ bl load_up_fpu; /* if from user, just load it up */ \
+ b fast_exception_return; \
+1: addi r3,r1,STACK_FRAME_OVERHEAD; \
+ EXC_XFER_EE_LITE(0x800, kernel_fp_unavailable_exception)
+#else
EXCEPTION(0x0800, Trap_08, unknown_exception, EXC_XFER_EE)
+#endif
+
EXCEPTION(0x0900, Trap_09, unknown_exception, EXC_XFER_EE)
EXCEPTION(0x0A00, Trap_0A, unknown_exception, EXC_XFER_EE)
EXCEPTION(0x0B00, Trap_0B, unknown_exception, EXC_XFER_EE)
@@ -432,7 +444,7 @@
EXCEPTION(0x0D00, Trap_0D, unknown_exception, EXC_XFER_EE)
EXCEPTION(0x0E00, Trap_0E, unknown_exception, EXC_XFER_EE)
- EXCEPTION(0x0F00, Trap_0F, unknown_exception, EXC_XFER_EE)
+ EXCEPTION(0x0F20, Trap_0F, unknown_exception, EXC_XFER_EE)
/* 0x1000 - Programmable Interval Timer (PIT) Exception */
START_EXCEPTION(0x1000, Decrementer)
@@ -821,8 +833,10 @@
* The PowerPC 4xx family of processors do not have an FPU, so this just
* returns.
*/
+#ifndef CONFIG_PPC_FPU
_ENTRY(giveup_fpu)
blr
+#endif
/* This is where the main kernel code starts.
*/
diff -r df25ff2b70a4 arch/powerpc/platforms/Kconfig
--- a/arch/powerpc/platforms/Kconfig Fri Aug 27 21:10:12 2010 +0400
+++ b/arch/powerpc/platforms/Kconfig Fri Sep 10 13:08:13 2010 +0400
@@ -338,4 +338,15 @@
bool "Xilinx PCI host bridge support"
depends on PCI && XILINX_VIRTEX
+config XILINX_SOFTFPU
+ bool "Xilinx Soft FPU support"
+ select PPC_FPU
+ depends on XILINX_VIRTEX_4_FX && !PPC40x_SIMPLE && !405GP && !405GPR
+ help
+ Say Y to enable support for Xilinx Virtex 4 FX singe-float FPU.
+ Caveats:
+ - Hard-float binaries which rely on in-kernel math emulation will give
wrong
+ results since they expect 64-bit double-precision instead of 32-bit
+ single-precision numbers which Virtex-4 soft FPU produces.
+
endmenu
^ permalink raw reply
* Re: [git pull] Please pull powerpc.git merge branch
From: Josh Boyer @ 2010-11-22 11:25 UTC (permalink / raw)
To: michael; +Cc: Stephen Rothwell, Michael Neuling, linuxppc-dev list
In-Reply-To: <1290380744.4961.7.camel@concordia>
On Sun, Nov 21, 2010 at 6:05 PM, Michael Ellerman
<michael@ellerman.id.au> wrote:
> On Fri, 2010-11-19 at 17:02 +1100, Michael Neuling wrote:
>> > On Fri, 2010-11-19 at 16:31 +1100, Stephen Rothwell wrote:
>> > > On Fri, 19 Nov 2010 09:08:02 +1100 Michael Ellerman <michael@ellerma=
n.id.=3D
>> > au> wrote:
>> > > >
>> > > > I vote for:
>> > > >=3D20
>> > > > =C2=A0-> Exception: 401 (Instruction Access) at 00000000f7937794
>> > >=3D20
>> > > Or:
>> > >=3D20
>> > > =3DE2=3D98=3D9B Exception: 401 (Instruction Access) at 00000000f7937=
794
>> >
>> > Let's get serious, it's _really_ like a phone call:
>> >
>> > =3DE2=3D98=3D8E Exception: 401 (Instruction Access) at 00000000f793779=
4
>>
>> We need a dedicated NACK char!
>
> =E2=90=95!
Surely it would be: =E2=98=A3
josh
^ permalink raw reply
* Re: [PATCH 1/3] misc: at24: parse OF-data, too
From: Stijn Devriendt @ 2010-11-22 16:48 UTC (permalink / raw)
To: Wolfram Sang; +Cc: linuxppc-dev, devicetree-discuss
In-Reply-To: <20101120124226.GB11936@pengutronix.de>
Hi Wolfram,
I seem to be mistaken. I retried "compatible=3D<linux,24c64>" and it did
all the right
things. I was mistaken that request_module() only takes the driver
name, at24 in this
case, and not all device names in the table_ids.
This pretty much makes my patch redundant. Thanks for helping me clear
things out.
Regards,
Stijn
On Sat, Nov 20, 2010 at 1:42 PM, Wolfram Sang <w.sang@pengutronix.de> wrote=
:
> Hi,
>
>> As far as I could tell, using compatible =3D <24c64>; didn't load the ri=
ght
>> module (module name is at24) and using at24 caused a device id mismatch
>> because at24 is not a known device ID. I could be wrong here and if so, =
I'd
>> very =A0much like a source code hint as to why...
>
> Have you tried "<vendor>, 24c64"? All I can say is that it works for me. =
Plain
> at24 worked for years with pcm030.dts and pcm032.dts, so I don't know whi=
ch
> issue you are facing. This patch is just about extending the support.
>
>> My patch worked by changing drivers/of/of_i2c.c to allow a generic
>> kind =3D " " statement that was filled in as i2c_board_info.type, to all=
ow
>> the module name and the device id to be different.
>> This makes the at24 driver no longer rely on probing (which it claims
>> is buggy anyway) and also benefits other drivers that support multiple
>> devices, but where probing is difficult (e.g. lm90 driver).
>>
>> I'm in the process of getting employer approval to get these patches
>> upstream.
>
> I hope you will get it approved, it is a lot easier to talk about code :)
>
> Best regards,
>
> =A0 Wolfram
>
> --
> Pengutronix e.K. =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | Wo=
lfram Sang =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0|
> Industrial Linux Solutions =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | http://www.p=
engutronix.de/ =A0|
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.9 (GNU/Linux)
>
> iEYEARECAAYFAkznwjIACgkQD27XaX1/VRssnwCgg55UCwZFLcMI8kJI3mhCJQxL
> N7kAoJHpLn5BJpNjET+ngaQFrGxUBQm1
> =3DtyTb
> -----END PGP SIGNATURE-----
>
>
^ permalink raw reply
* Re: [git pull] Please pull powerpc.git merge branch
From: Scott Wood @ 2010-11-22 18:45 UTC (permalink / raw)
To: michael; +Cc: Stephen Rothwell, linuxppc-dev list
In-Reply-To: <1290145458.2867.3.camel@concordia>
On Fri, 19 Nov 2010 16:44:18 +1100
Michael Ellerman <michael@ellerman.id.au> wrote:
> On Fri, 2010-11-19 at 16:31 +1100, Stephen Rothwell wrote:
> > On Fri, 19 Nov 2010 09:08:02 +1100 Michael Ellerman <michael@ellerman.i=
d.au> wrote:
> > >
> > > I vote for:
> > >=20
> > > -> Exception: 401 (Instruction Access) at 00000000f7937794
> >=20
> > Or:
> >=20
> > =E2=98=9B Exception: 401 (Instruction Access) at 00000000f7937794
>=20
> Let's get serious, it's _really_ like a phone call:
>=20
> =E2=98=8E Exception: 401 (Instruction Access) at 00000000f7937794
Sparc got it right:
void die_if_kernel(char *str, struct pt_regs *regs)
{
static int die_counter;
int count =3D 0;
=09
/* Amuse the user. */
printk(
" \\|/ ____ \\|/\n"
" \"@'/ .. \\`@\"\n"
" /_| \\__/ |_\\\n"
" \\__U_/\n");
-Scott
^ permalink raw reply
* Re: Change in PCI behaviour
From: Benjamin Herrenschmidt @ 2010-11-22 20:26 UTC (permalink / raw)
To: Gary Thomas; +Cc: Linux PPC Development
In-Reply-To: <4CEA3F87.9080102@mlbassoc.com>
On Mon, 2010-11-22 at 03:01 -0700, Gary Thomas wrote:
> I have a bit more information on this. I'm pretty sure that the failures
> are only happening in my SCSI (SATA actually) code. My board (8347ea) has
> a PCI bus with a SIL SATA controller. This combo works perfectly in 2.6.28.
> In 2.6.32, it will run for a while (possibly quite a while), then timeout
> trying to do a large block write - typically 256 blocks. Once this timeout
> happens, the SIL controller is stuck and accesses to it will eventually
> cause the whole system to hang (as above).
>
> Was there any major change in how PCI or DMA was handled between 2.6.28
> and 2.6.32? Given the ephemeral nature of these failures (multiple runs
> all eventually fail, but never the same twice), my only hope of fixing it
> will be to have some ideas what might have changed.
Maybe the changes you did to the PCI outbound windows are now breaking
DMA ? Make sure the outbound and inbound don't overlap for example and
that all RAM is reachable for inbound.
Cheers,
Ben.
^ permalink raw reply
* [PATCH] MPC5200: Eliminate duplicate include of of_device.h
From: Jesper Juhl @ 2010-11-22 21:54 UTC (permalink / raw)
To: alsa-devel
Cc: Takashi Iwai, Mark Brown, linux-kernel, linuxppc-dev,
Liam Girdwood
Eliminate duplicate #include <linux/of_device.h> from
sound/soc/fsl/mpc5200_dma.c
Signed-off-by: Jesper Juhl <jj@chaosbits.net>
---
mpc5200_dma.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/sound/soc/fsl/mpc5200_dma.c b/sound/soc/fsl/mpc5200_dma.c
index dce6b55..f92dca0 100644
--- a/sound/soc/fsl/mpc5200_dma.c
+++ b/sound/soc/fsl/mpc5200_dma.c
@@ -9,7 +9,6 @@
#include <linux/module.h>
#include <linux/of_device.h>
#include <linux/slab.h>
-#include <linux/of_device.h>
#include <linux/of_platform.h>
#include <sound/soc.h>
--
Jesper Juhl <jj@chaosbits.net> http://www.chaosbits.net/
Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html
Plain text mails only, please.
^ permalink raw reply related
* [PATCH] powerpc, time: printk time stamp init not correct
From: Heiko Schocher @ 2010-11-23 7:30 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Heiko Schocher, Wolfgang Denk
problem:
I see sometimes on my mpc5200 based board such printk timing
information:
[ 0.000000] NR_IRQS:512 nr_irqs:512 16
[ 0.000000] MPC52xx PIC is up and running!
[ 0.000000] clocksource: timebase mult[79364d9] shift[22] registered
[ 0.000000] console [ttyPSC0] enabled
[ 130.300633] pid_max: default: 32768 minimum: 301
[ 130.305647] Mount-cache hash table entries: 512
[ 130.315818] NET: Registered protocol family 16
reason:
if the tbu not starts from 0 when linux boots, boot_tb
maybe could not store the real 64 bit tbu value, because
boot_tp is only a 32 bit unsigned long.
solution:
change boot_tb to unsigned long long
Signed-off-by: Heiko Schocher <hs@denx.de>
cc: Wolfgang Denk <wd@denx.de>
---
arch/powerpc/kernel/time.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/kernel/time.c b/arch/powerpc/kernel/time.c
index fa91732..a66df7d 100644
--- a/arch/powerpc/kernel/time.c
+++ b/arch/powerpc/kernel/time.c
@@ -155,7 +155,7 @@ EXPORT_SYMBOL_GPL(rtc_lock);
static u64 tb_to_ns_scale __read_mostly;
static unsigned tb_to_ns_shift __read_mostly;
-static unsigned long boot_tb __read_mostly;
+static unsigned long long boot_tb __read_mostly;
extern struct timezone sys_tz;
static long timezone_offset;
--
1.7.2.3
^ permalink raw reply related
* [PATCH v1] ppc44x:PHY fixup for USB on canyonlands board
From: Rupjyoti Sarmah @ 2010-11-23 12:56 UTC (permalink / raw)
To: linuxppc-dev, linux-kernel; +Cc: rsarmah
This fix is a reset for USB PHY that requires some amount of time for power to be stable on Canyonlands.
Signed-off-by: Rupjyoti Sarmah <rsarmah@apm.com>
---
arch/powerpc/boot/dts/canyonlands.dts | 13 +++
arch/powerpc/platforms/44x/44x.h | 5 +
arch/powerpc/platforms/44x/Makefile | 1 +
arch/powerpc/platforms/44x/canyonlands.c | 122 ++++++++++++++++++++++++++++
arch/powerpc/platforms/44x/ppc44x_simple.c | 1 -
5 files changed, 141 insertions(+), 1 deletions(-)
create mode 100644 arch/powerpc/platforms/44x/canyonlands.c
diff --git a/arch/powerpc/boot/dts/canyonlands.dts b/arch/powerpc/boot/dts/canyonlands.dts
index a303703..a9f7538 100644
--- a/arch/powerpc/boot/dts/canyonlands.dts
+++ b/arch/powerpc/boot/dts/canyonlands.dts
@@ -224,6 +224,13 @@
};
};
+ cpld@2,0 {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ compatible = "apm,ppc460ex-bcsr";
+ reg = <2 0x0 0x9>;
+ };
+
ndfc@3,0 {
compatible = "ibm,ndfc";
reg = <0x00000003 0x00000000 0x00002000>;
@@ -320,6 +327,12 @@
interrupts = <0x3 0x4>;
};
+ GPIO0: gpio@ef600b00 {
+ compatible = "ibm,ppc4xx-gpio";
+ reg = <0xef600b00 0x00000048>;
+ gpio-controller;
+ };
+
ZMII0: emac-zmii@ef600d00 {
compatible = "ibm,zmii-460ex", "ibm,zmii";
reg = <0xef600d00 0x0000000c>;
diff --git a/arch/powerpc/platforms/44x/44x.h b/arch/powerpc/platforms/44x/44x.h
index dbc4d2b..bc2ab7a 100644
--- a/arch/powerpc/platforms/44x/44x.h
+++ b/arch/powerpc/platforms/44x/44x.h
@@ -4,4 +4,9 @@
extern u8 as1_readb(volatile u8 __iomem *addr);
extern void as1_writeb(u8 data, volatile u8 __iomem *addr);
+#define BCSR_USB_EN 0x11
+#define GPIO0_OSRH 0xC
+#define GPIO0_TSRH 0x14
+#define GPIO0_ISR1H 0x34
+
#endif /* __POWERPC_PLATFORMS_44X_44X_H */
diff --git a/arch/powerpc/platforms/44x/Makefile b/arch/powerpc/platforms/44x/Makefile
index 82ff326..6854e73 100644
--- a/arch/powerpc/platforms/44x/Makefile
+++ b/arch/powerpc/platforms/44x/Makefile
@@ -6,3 +6,4 @@ obj-$(CONFIG_WARP) += warp.o
obj-$(CONFIG_XILINX_VIRTEX_5_FXT) += virtex.o
obj-$(CONFIG_XILINX_ML510) += virtex_ml510.o
obj-$(CONFIG_ISS4xx) += iss4xx.o
+obj-$(CONFIG_CANYONLANDS)+= canyonlands.o
diff --git a/arch/powerpc/platforms/44x/canyonlands.c b/arch/powerpc/platforms/44x/canyonlands.c
new file mode 100644
index 0000000..f13b62f
--- /dev/null
+++ b/arch/powerpc/platforms/44x/canyonlands.c
@@ -0,0 +1,122 @@
+/*
+ * This contain platform specific code for Canyonalnds board based on
+ * APM ppc44x series of processors.
+ *
+ * Copyright (c) 2010, Applied Micro Circuits Corporation
+ * Author: Rupjyoti Sarmah <rsarmah@apm.com>
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston,
+ * MA 02111-1307 USA
+ *
+ */
+#include <linux/kernel.h>
+#include <linux/init.h>
+#include <asm/pci-bridge.h>
+#include <asm/ppc4xx.h>
+#include <asm/udbg.h>
+#include <asm/uic.h>
+#include <linux/of_platform.h>
+#include "44x.h"
+
+static __initdata struct of_device_id ppc44x_of_bus[] = {
+ { .compatible = "ibm,plb4", },
+ { .compatible = "ibm,opb", },
+ { .compatible = "ibm,ebc", },
+ { .compatible = "simple-bus", },
+ {},
+};
+
+static int __init ppc44x_device_probe(void)
+{
+ of_platform_bus_probe(NULL, ppc44x_of_bus, NULL);
+
+ return 0;
+}
+machine_device_initcall(canyonlands, ppc44x_device_probe);
+
+/* Using this code only for the Canyonlands board. */
+
+static int __init ppc44x_probe(void)
+{
+ unsigned long root = of_get_flat_dt_root();
+ if (of_flat_dt_is_compatible(root, "amcc,canyonlands")) {
+ ppc_pci_set_flags(PPC_PCI_REASSIGN_ALL_RSRC);
+ return 1;
+ }
+ return 0;
+}
+
+/* PHY fixup code on Canyonlands kit. */
+
+static int __init ppc460ex_canyonlands_fixup(void)
+{
+ u8 __iomem *bcsr ;
+ void __iomem *vaddr;
+ struct device_node *np;
+ u32 val ;
+
+ np = of_find_compatible_node(NULL, NULL, "apm,ppc460ex-bcsr");
+ if (!np) {
+ printk(KERN_ERR "failed did not find apm, ppc460ex bcsr node\n");
+ return -ENODEV;
+ }
+
+ bcsr = of_iomap(np, 0);
+ of_node_put(np);
+
+ if (!bcsr) {
+ printk(KERN_CRIT "Could not remap bcsr\n");
+ return -ENODEV;
+ }
+
+ np = of_find_compatible_node(NULL, NULL, "ibm,ppc4xx-gpio");
+ vaddr = of_iomap(np, 0);
+ if (!vaddr) {
+ printk(KERN_CRIT "Could not get gpio node address\n");
+ return -ENODEV;
+ }
+
+ setbits8(&bcsr[7], BCSR_USB_EN);
+ udelay(100000);
+
+ clrbits8(&bcsr[7], BCSR_USB_EN);
+ udelay(100000);
+
+ /* configure gpio16 and gpio19 as alternate1 */
+
+ /* GPIO0_ISR1H for alternate 1 settings */
+ val = in_be32(vaddr + GPIO0_ISR1H);
+ out_be32((vaddr + GPIO0_ISR1H), val | 0x4200000);
+
+ /* GPIO0_OSRH for alternate 1 settings */
+ val = in_be32(vaddr + GPIO0_OSRH);
+ out_be32((vaddr + GPIO0_OSRH), val | 0x42000000);
+
+ /* GPIO0_TSRH for alternate 1 settings */
+ val = in_be32(vaddr + GPIO0_TSRH);
+ out_be32((vaddr + GPIO0_TSRH), val | 0x42000000);
+ of_node_put(np);
+ return 0;
+}
+machine_device_initcall(canyonlands, ppc460ex_canyonlands_fixup);
+define_machine(canyonlands) {
+ .name = "Canyonlands",
+ .probe = ppc44x_probe,
+ .progress = udbg_progress,
+ .init_IRQ = uic_init_tree,
+ .get_irq = uic_get_irq,
+ .restart = ppc4xx_reset_system,
+ .calibrate_decr = generic_calibrate_decr,
+};
diff --git a/arch/powerpc/platforms/44x/ppc44x_simple.c b/arch/powerpc/platforms/44x/ppc44x_simple.c
index 7ddcba3..c81c19c 100644
--- a/arch/powerpc/platforms/44x/ppc44x_simple.c
+++ b/arch/powerpc/platforms/44x/ppc44x_simple.c
@@ -53,7 +53,6 @@ static char *board[] __initdata = {
"amcc,arches",
"amcc,bamboo",
"amcc,bluestone",
- "amcc,canyonlands",
"amcc,glacier",
"ibm,ebony",
"amcc,eiger",
--
1.5.6.3
^ permalink raw reply related
* Re: [PATCH v1] ppc44x:PHY fixup for USB on canyonlands board
From: Stefan Roese @ 2010-11-23 13:21 UTC (permalink / raw)
To: linuxppc-dev; +Cc: linuxppc-dev, Rupjyoti Sarmah, rsarmah, linux-kernel
In-Reply-To: <201011231256.oANCur3N016433@amcc.com>
Hi Rup,
On Tuesday 23 November 2010 13:56:53 Rupjyoti Sarmah wrote:
> This fix is a reset for USB PHY that requires some amount of time for power
> to be stable on Canyonlands.
Since this is version 2 of your patch, "[PATCH v2]" would have been a bit
better in the subject line. Its also a good practice to summarize the changes
between patch versions below the "---" line.
Please find a some further comments below.
<snip>
> --- a/arch/powerpc/platforms/44x/44x.h
> +++ b/arch/powerpc/platforms/44x/44x.h
> @@ -4,4 +4,9 @@
> extern u8 as1_readb(volatile u8 __iomem *addr);
> extern void as1_writeb(u8 data, volatile u8 __iomem *addr);
>
> +#define BCSR_USB_EN 0x11
This define is wrong here. Its not common for all 44x platforms but
Canyonlands specific.
> +#define GPIO0_OSRH 0xC
> +#define GPIO0_TSRH 0x14
> +#define GPIO0_ISR1H 0x34
> +
> #endif /* __POWERPC_PLATFORMS_44X_44X_H */
> diff --git a/arch/powerpc/platforms/44x/Makefile
> b/arch/powerpc/platforms/44x/Makefile index 82ff326..6854e73 100644
> --- a/arch/powerpc/platforms/44x/Makefile
> +++ b/arch/powerpc/platforms/44x/Makefile
> @@ -6,3 +6,4 @@ obj-$(CONFIG_WARP) += warp.o
> obj-$(CONFIG_XILINX_VIRTEX_5_FXT) += virtex.o
> obj-$(CONFIG_XILINX_ML510) += virtex_ml510.o
> obj-$(CONFIG_ISS4xx) += iss4xx.o
> +obj-$(CONFIG_CANYONLANDS)+= canyonlands.o
> diff --git a/arch/powerpc/platforms/44x/canyonlands.c
> b/arch/powerpc/platforms/44x/canyonlands.c new file mode 100644
> index 0000000..f13b62f
> --- /dev/null
> +++ b/arch/powerpc/platforms/44x/canyonlands.c
> @@ -0,0 +1,122 @@
> +/*
> + * This contain platform specific code for Canyonalnds board based on
^^^^^^^^^^^
Canyonlands
> + * APM ppc44x series of processors.
> + *
> + * Copyright (c) 2010, Applied Micro Circuits Corporation
> + * Author: Rupjyoti Sarmah <rsarmah@apm.com>
> + *
> + * This program is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public License as
> + * published by the Free Software Foundation; either version 2 of
> + * the License, or (at your option) any later version.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + * GNU General Public License for more details.
> + *
> + * You should have received a copy of the GNU General Public License
> + * along with this program; if not, write to the Free Software
> + * Foundation, Inc., 59 Temple Place, Suite 330, Boston,
> + * MA 02111-1307 USA
> + *
> + */
> +#include <linux/kernel.h>
> +#include <linux/init.h>
> +#include <asm/pci-bridge.h>
> +#include <asm/ppc4xx.h>
> +#include <asm/udbg.h>
> +#include <asm/uic.h>
> +#include <linux/of_platform.h>
> +#include "44x.h"
> +
> +static __initdata struct of_device_id ppc44x_of_bus[] = {
> + { .compatible = "ibm,plb4", },
> + { .compatible = "ibm,opb", },
> + { .compatible = "ibm,ebc", },
> + { .compatible = "simple-bus", },
> + {},
> +};
> +
> +static int __init ppc44x_device_probe(void)
> +{
> + of_platform_bus_probe(NULL, ppc44x_of_bus, NULL);
> +
> + return 0;
> +}
> +machine_device_initcall(canyonlands, ppc44x_device_probe);
> +
> +/* Using this code only for the Canyonlands board. */
> +
> +static int __init ppc44x_probe(void)
> +{
> + unsigned long root = of_get_flat_dt_root();
> + if (of_flat_dt_is_compatible(root, "amcc,canyonlands")) {
> + ppc_pci_set_flags(PPC_PCI_REASSIGN_ALL_RSRC);
> + return 1;
> + }
> + return 0;
> +}
> +
> +/* PHY fixup code on Canyonlands kit. */
PHY is a bit unspecific. One might think that this is an ethernet PHY (see
remark below about better comments in the code)?
> +
> +static int __init ppc460ex_canyonlands_fixup(void)
> +{
> + u8 __iomem *bcsr ;
> + void __iomem *vaddr;
Double space before *vaddr.
> + struct device_node *np;
> + u32 val ;
> +
> + np = of_find_compatible_node(NULL, NULL, "apm,ppc460ex-bcsr");
> + if (!np) {
> + printk(KERN_ERR "failed did not find apm, ppc460ex bcsr
node\n");
> + return -ENODEV;
> + }
> +
> + bcsr = of_iomap(np, 0);
> + of_node_put(np);
> +
> + if (!bcsr) {
> + printk(KERN_CRIT "Could not remap bcsr\n");
> + return -ENODEV;
> + }
> +
> + np = of_find_compatible_node(NULL, NULL, "ibm,ppc4xx-gpio");
> + vaddr = of_iomap(np, 0);
> + if (!vaddr) {
> + printk(KERN_CRIT "Could not get gpio node address\n");
> + return -ENODEV;
> + }
> +
> + setbits8(&bcsr[7], BCSR_USB_EN);
> + udelay(100000);
> +
> + clrbits8(&bcsr[7], BCSR_USB_EN);
> + udelay(100000);
Thats a total bootup delay of 200ms. Is this really needed?
> +
> + /* configure gpio16 and gpio19 as alternate1 */
> +
> + /* GPIO0_ISR1H for alternate 1 settings */
> + val = in_be32(vaddr + GPIO0_ISR1H);
> + out_be32((vaddr + GPIO0_ISR1H), val | 0x4200000);
setbits32 might be even simpler.
> + /* GPIO0_OSRH for alternate 1 settings */
> + val = in_be32(vaddr + GPIO0_OSRH);
> + out_be32((vaddr + GPIO0_OSRH), val | 0x42000000);
Same here.
> + /* GPIO0_TSRH for alternate 1 settings */
> + val = in_be32(vaddr + GPIO0_TSRH);
> + out_be32((vaddr + GPIO0_TSRH), val | 0x42000000);
And here.
And I suggest to add a few comments to the code explaining why exactly you are
setting/clearing the bits in the BCSR and the GPIO registers.
Cheers,
Stefan
^ permalink raw reply
* [PATCH v3 02/22] bitops: rename generic little-endian bitops functions
From: Akinobu Mita @ 2010-11-23 13:38 UTC (permalink / raw)
To: linux-kernel, linux-arch, Andrew Morton
Cc: rds-devel, kvm, Marcelo Tosatti, Akinobu Mita, Andy Grover,
linux-m68k, netdev, Andreas Schwab, Avi Kivity, Greg Ungerer,
Geert Uytterhoeven, linuxppc-dev, David S. Miller, Paul Mackerras
In-Reply-To: <1290519504-3958-1-git-send-email-akinobu.mita@gmail.com>
As a preparation for providing little-endian bitops for all architectures,
This removes generic_ prefix from little-endian bitops function names
in asm-generic/bitops/le.h.
s/generic_find_next_le_bit/find_next_le_bit/
s/generic_find_next_zero_le_bit/find_next_zero_le_bit/
s/generic_find_first_zero_le_bit/find_first_zero_le_bit/
s/generic___test_and_set_le_bit/__test_and_set_le_bit/
s/generic___test_and_clear_le_bit/__test_and_clear_le_bit/
s/generic_test_le_bit/test_le_bit/
s/generic___set_le_bit/__set_le_bit/
s/generic___clear_le_bit/__clear_le_bit/
s/generic_test_and_set_le_bit/test_and_set_le_bit/
s/generic_test_and_clear_le_bit/test_and_clear_le_bit/
Signed-off-by: Akinobu Mita <akinobu.mita@gmail.com>
Acked-by: Arnd Bergmann <arnd@arndb.de>
Acked-by: Hans-Christian Egtvedt <hans-christian.egtvedt@atmel.com>
Cc: Geert Uytterhoeven <geert@linux-m68k.org>
Cc: Roman Zippel <zippel@linux-m68k.org>
Cc: Andreas Schwab <schwab@linux-m68k.org>
Cc: linux-m68k@lists.linux-m68k.org
Cc: Greg Ungerer <gerg@uclinux.org>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Paul Mackerras <paulus@samba.org>
Cc: linuxppc-dev@lists.ozlabs.org
Cc: Andy Grover <andy.grover@oracle.com>
Cc: rds-devel@oss.oracle.com
Cc: "David S. Miller" <davem@davemloft.net>
Cc: netdev@vger.kernel.org
Cc: Avi Kivity <avi@redhat.com>
Cc: Marcelo Tosatti <mtosatti@redhat.com>
Cc: kvm@vger.kernel.org
---
No change from previous submission
arch/avr32/kernel/avr32_ksyms.c | 4 ++--
arch/avr32/lib/findbit.S | 4 ++--
arch/m68k/include/asm/bitops_mm.h | 8 ++++----
arch/m68k/include/asm/bitops_no.h | 2 +-
arch/powerpc/include/asm/bitops.h | 11 ++++++-----
include/asm-generic/bitops/ext2-non-atomic.h | 12 ++++++------
include/asm-generic/bitops/le.h | 26 +++++++++++++-------------
include/asm-generic/bitops/minix-le.h | 10 +++++-----
lib/find_next_bit.c | 9 ++++-----
net/rds/cong.c | 6 +++---
virt/kvm/kvm_main.c | 2 +-
11 files changed, 47 insertions(+), 47 deletions(-)
diff --git a/arch/avr32/kernel/avr32_ksyms.c b/arch/avr32/kernel/avr32_ksyms.c
index 11e310c..c63b943 100644
--- a/arch/avr32/kernel/avr32_ksyms.c
+++ b/arch/avr32/kernel/avr32_ksyms.c
@@ -58,8 +58,8 @@ EXPORT_SYMBOL(find_first_zero_bit);
EXPORT_SYMBOL(find_next_zero_bit);
EXPORT_SYMBOL(find_first_bit);
EXPORT_SYMBOL(find_next_bit);
-EXPORT_SYMBOL(generic_find_next_le_bit);
-EXPORT_SYMBOL(generic_find_next_zero_le_bit);
+EXPORT_SYMBOL(find_next_le_bit);
+EXPORT_SYMBOL(find_next_zero_le_bit);
/* I/O primitives (lib/io-*.S) */
EXPORT_SYMBOL(__raw_readsb);
diff --git a/arch/avr32/lib/findbit.S b/arch/avr32/lib/findbit.S
index 997b33b..6880d85 100644
--- a/arch/avr32/lib/findbit.S
+++ b/arch/avr32/lib/findbit.S
@@ -123,7 +123,7 @@ ENTRY(find_next_bit)
brgt 1b
retal r11
-ENTRY(generic_find_next_le_bit)
+ENTRY(find_next_le_bit)
lsr r8, r10, 5
sub r9, r11, r10
retle r11
@@ -153,7 +153,7 @@ ENTRY(generic_find_next_le_bit)
brgt 1b
retal r11
-ENTRY(generic_find_next_zero_le_bit)
+ENTRY(find_next_zero_le_bit)
lsr r8, r10, 5
sub r9, r11, r10
retle r11
diff --git a/arch/m68k/include/asm/bitops_mm.h b/arch/m68k/include/asm/bitops_mm.h
index b4ecdaa..f1010ab 100644
--- a/arch/m68k/include/asm/bitops_mm.h
+++ b/arch/m68k/include/asm/bitops_mm.h
@@ -366,9 +366,9 @@ static inline int minix_test_bit(int nr, const void *vaddr)
#define ext2_clear_bit(nr, addr) __test_and_clear_bit((nr) ^ 24, (unsigned long *)(addr))
#define ext2_clear_bit_atomic(lock, nr, addr) test_and_clear_bit((nr) ^ 24, (unsigned long *)(addr))
#define ext2_find_next_zero_bit(addr, size, offset) \
- generic_find_next_zero_le_bit((unsigned long *)addr, size, offset)
+ find_next_zero_le_bit((unsigned long *)addr, size, offset)
#define ext2_find_next_bit(addr, size, offset) \
- generic_find_next_le_bit((unsigned long *)addr, size, offset)
+ find_next_le_bit((unsigned long *)addr, size, offset)
static inline int ext2_test_bit(int nr, const void *vaddr)
{
@@ -398,7 +398,7 @@ static inline int ext2_find_first_zero_bit(const void *vaddr, unsigned size)
return (p - addr) * 32 + res;
}
-static inline unsigned long generic_find_next_zero_le_bit(const unsigned long *addr,
+static inline unsigned long find_next_zero_le_bit(const unsigned long *addr,
unsigned long size, unsigned long offset)
{
const unsigned long *p = addr + (offset >> 5);
@@ -440,7 +440,7 @@ static inline int ext2_find_first_bit(const void *vaddr, unsigned size)
return (p - addr) * 32 + res;
}
-static inline unsigned long generic_find_next_le_bit(const unsigned long *addr,
+static inline unsigned long find_next_le_bit(const unsigned long *addr,
unsigned long size, unsigned long offset)
{
const unsigned long *p = addr + (offset >> 5);
diff --git a/arch/m68k/include/asm/bitops_no.h b/arch/m68k/include/asm/bitops_no.h
index 9d3cbe5..292e1ce 100644
--- a/arch/m68k/include/asm/bitops_no.h
+++ b/arch/m68k/include/asm/bitops_no.h
@@ -325,7 +325,7 @@ found_middle:
}
#define ext2_find_next_bit(addr, size, off) \
- generic_find_next_le_bit((unsigned long *)(addr), (size), (off))
+ find_next_le_bit((unsigned long *)(addr), (size), (off))
#include <asm-generic/bitops/minix.h>
#endif /* __KERNEL__ */
diff --git a/arch/powerpc/include/asm/bitops.h b/arch/powerpc/include/asm/bitops.h
index 30964ae..b4f3f84 100644
--- a/arch/powerpc/include/asm/bitops.h
+++ b/arch/powerpc/include/asm/bitops.h
@@ -294,11 +294,12 @@ static __inline__ int test_le_bit(unsigned long nr,
#define __test_and_clear_le_bit(nr, addr) \
__test_and_clear_bit((nr) ^ BITOP_LE_SWIZZLE, (addr))
-#define find_first_zero_le_bit(addr, size) generic_find_next_zero_le_bit((addr), (size), 0)
-unsigned long generic_find_next_zero_le_bit(const unsigned long *addr,
+#define find_first_zero_le_bit(addr, size) \
+ find_next_zero_le_bit((addr), (size), 0)
+unsigned long find_next_zero_le_bit(const unsigned long *addr,
unsigned long size, unsigned long offset);
-unsigned long generic_find_next_le_bit(const unsigned long *addr,
+unsigned long find_next_le_bit(const unsigned long *addr,
unsigned long size, unsigned long offset);
/* Bitmap functions for the ext2 filesystem */
@@ -317,10 +318,10 @@ unsigned long generic_find_next_le_bit(const unsigned long *addr,
#define ext2_find_first_zero_bit(addr, size) \
find_first_zero_le_bit((unsigned long*)addr, size)
#define ext2_find_next_zero_bit(addr, size, off) \
- generic_find_next_zero_le_bit((unsigned long*)addr, size, off)
+ find_next_zero_le_bit((unsigned long *)addr, size, off)
#define ext2_find_next_bit(addr, size, off) \
- generic_find_next_le_bit((unsigned long *)addr, size, off)
+ find_next_le_bit((unsigned long *)addr, size, off)
/* Bitmap functions for the minix filesystem. */
#define minix_test_and_set_bit(nr,addr) \
diff --git a/include/asm-generic/bitops/ext2-non-atomic.h b/include/asm-generic/bitops/ext2-non-atomic.h
index 63cf822..9c7bb9a 100644
--- a/include/asm-generic/bitops/ext2-non-atomic.h
+++ b/include/asm-generic/bitops/ext2-non-atomic.h
@@ -4,17 +4,17 @@
#include <asm-generic/bitops/le.h>
#define ext2_set_bit(nr,addr) \
- generic___test_and_set_le_bit((nr),(unsigned long *)(addr))
+ __test_and_set_le_bit((nr), (unsigned long *)(addr))
#define ext2_clear_bit(nr,addr) \
- generic___test_and_clear_le_bit((nr),(unsigned long *)(addr))
+ __test_and_clear_le_bit((nr), (unsigned long *)(addr))
#define ext2_test_bit(nr,addr) \
- generic_test_le_bit((nr),(unsigned long *)(addr))
+ test_le_bit((nr), (unsigned long *)(addr))
#define ext2_find_first_zero_bit(addr, size) \
- generic_find_first_zero_le_bit((unsigned long *)(addr), (size))
+ find_first_zero_le_bit((unsigned long *)(addr), (size))
#define ext2_find_next_zero_bit(addr, size, off) \
- generic_find_next_zero_le_bit((unsigned long *)(addr), (size), (off))
+ find_next_zero_le_bit((unsigned long *)(addr), (size), (off))
#define ext2_find_next_bit(addr, size, off) \
- generic_find_next_le_bit((unsigned long *)(addr), (size), (off))
+ find_next_le_bit((unsigned long *)(addr), (size), (off))
#endif /* _ASM_GENERIC_BITOPS_EXT2_NON_ATOMIC_H_ */
diff --git a/include/asm-generic/bitops/le.h b/include/asm-generic/bitops/le.h
index db2be81..6ad46ce 100644
--- a/include/asm-generic/bitops/le.h
+++ b/include/asm-generic/bitops/le.h
@@ -8,42 +8,42 @@
#define BITOP_LE_SWIZZLE 0
-#define generic_find_next_zero_le_bit(addr, size, offset) \
+#define find_next_zero_le_bit(addr, size, offset) \
find_next_zero_bit(addr, size, offset)
-#define generic_find_next_le_bit(addr, size, offset) \
+#define find_next_le_bit(addr, size, offset) \
find_next_bit(addr, size, offset)
#elif defined(__BIG_ENDIAN)
#define BITOP_LE_SWIZZLE ((BITS_PER_LONG-1) & ~0x7)
-extern unsigned long generic_find_next_zero_le_bit(const unsigned long *addr,
+extern unsigned long find_next_zero_le_bit(const unsigned long *addr,
unsigned long size, unsigned long offset);
-extern unsigned long generic_find_next_le_bit(const unsigned long *addr,
+extern unsigned long find_next_le_bit(const unsigned long *addr,
unsigned long size, unsigned long offset);
#else
#error "Please fix <asm/byteorder.h>"
#endif
-#define generic_test_le_bit(nr, addr) \
+#define test_le_bit(nr, addr) \
test_bit((nr) ^ BITOP_LE_SWIZZLE, (addr))
-#define generic___set_le_bit(nr, addr) \
+#define __set_le_bit(nr, addr) \
__set_bit((nr) ^ BITOP_LE_SWIZZLE, (addr))
-#define generic___clear_le_bit(nr, addr) \
+#define __clear_le_bit(nr, addr) \
__clear_bit((nr) ^ BITOP_LE_SWIZZLE, (addr))
-#define generic_test_and_set_le_bit(nr, addr) \
+#define test_and_set_le_bit(nr, addr) \
test_and_set_bit((nr) ^ BITOP_LE_SWIZZLE, (addr))
-#define generic_test_and_clear_le_bit(nr, addr) \
+#define test_and_clear_le_bit(nr, addr) \
test_and_clear_bit((nr) ^ BITOP_LE_SWIZZLE, (addr))
-#define generic___test_and_set_le_bit(nr, addr) \
+#define __test_and_set_le_bit(nr, addr) \
__test_and_set_bit((nr) ^ BITOP_LE_SWIZZLE, (addr))
-#define generic___test_and_clear_le_bit(nr, addr) \
+#define __test_and_clear_le_bit(nr, addr) \
__test_and_clear_bit((nr) ^ BITOP_LE_SWIZZLE, (addr))
-#define generic_find_first_zero_le_bit(addr, size) \
- generic_find_next_zero_le_bit((addr), (size), 0)
+#define find_first_zero_le_bit(addr, size) \
+ find_next_zero_le_bit((addr), (size), 0)
#endif /* _ASM_GENERIC_BITOPS_LE_H_ */
diff --git a/include/asm-generic/bitops/minix-le.h b/include/asm-generic/bitops/minix-le.h
index 4a981c1..ed0ae09 100644
--- a/include/asm-generic/bitops/minix-le.h
+++ b/include/asm-generic/bitops/minix-le.h
@@ -4,14 +4,14 @@
#include <asm-generic/bitops/le.h>
#define minix_test_and_set_bit(nr,addr) \
- generic___test_and_set_le_bit((nr),(unsigned long *)(addr))
+ __test_and_set_le_bit((nr), (unsigned long *)(addr))
#define minix_set_bit(nr,addr) \
- generic___set_le_bit((nr),(unsigned long *)(addr))
+ __set_le_bit((nr), (unsigned long *)(addr))
#define minix_test_and_clear_bit(nr,addr) \
- generic___test_and_clear_le_bit((nr),(unsigned long *)(addr))
+ __test_and_clear_le_bit((nr), (unsigned long *)(addr))
#define minix_test_bit(nr,addr) \
- generic_test_le_bit((nr),(unsigned long *)(addr))
+ test_le_bit((nr), (unsigned long *)(addr))
#define minix_find_first_zero_bit(addr,size) \
- generic_find_first_zero_le_bit((unsigned long *)(addr),(size))
+ find_first_zero_le_bit((unsigned long *)(addr), (size))
#endif /* _ASM_GENERIC_BITOPS_MINIX_LE_H_ */
diff --git a/lib/find_next_bit.c b/lib/find_next_bit.c
index 24c59de..eb8934b 100644
--- a/lib/find_next_bit.c
+++ b/lib/find_next_bit.c
@@ -185,7 +185,7 @@ static inline unsigned long ext2_swab(const unsigned long y)
#endif
}
-unsigned long generic_find_next_zero_le_bit(const unsigned long *addr, unsigned
+unsigned long find_next_zero_le_bit(const unsigned long *addr, unsigned
long size, unsigned long offset)
{
const unsigned long *p = addr + BITOP_WORD(offset);
@@ -226,10 +226,9 @@ found_middle:
found_middle_swap:
return result + ffz(ext2_swab(tmp));
}
+EXPORT_SYMBOL(find_next_zero_le_bit);
-EXPORT_SYMBOL(generic_find_next_zero_le_bit);
-
-unsigned long generic_find_next_le_bit(const unsigned long *addr, unsigned
+unsigned long find_next_le_bit(const unsigned long *addr, unsigned
long size, unsigned long offset)
{
const unsigned long *p = addr + BITOP_WORD(offset);
@@ -271,5 +270,5 @@ found_middle:
found_middle_swap:
return result + __ffs(ext2_swab(tmp));
}
-EXPORT_SYMBOL(generic_find_next_le_bit);
+EXPORT_SYMBOL(find_next_le_bit);
#endif /* __BIG_ENDIAN */
diff --git a/net/rds/cong.c b/net/rds/cong.c
index 75ea686..90ca44f 100644
--- a/net/rds/cong.c
+++ b/net/rds/cong.c
@@ -285,7 +285,7 @@ void rds_cong_set_bit(struct rds_cong_map *map, __be16 port)
i = be16_to_cpu(port) / RDS_CONG_MAP_PAGE_BITS;
off = be16_to_cpu(port) % RDS_CONG_MAP_PAGE_BITS;
- generic___set_le_bit(off, (void *)map->m_page_addrs[i]);
+ __set_le_bit(off, (void *)map->m_page_addrs[i]);
}
void rds_cong_clear_bit(struct rds_cong_map *map, __be16 port)
@@ -299,7 +299,7 @@ void rds_cong_clear_bit(struct rds_cong_map *map, __be16 port)
i = be16_to_cpu(port) / RDS_CONG_MAP_PAGE_BITS;
off = be16_to_cpu(port) % RDS_CONG_MAP_PAGE_BITS;
- generic___clear_le_bit(off, (void *)map->m_page_addrs[i]);
+ __clear_le_bit(off, (void *)map->m_page_addrs[i]);
}
static int rds_cong_test_bit(struct rds_cong_map *map, __be16 port)
@@ -310,7 +310,7 @@ static int rds_cong_test_bit(struct rds_cong_map *map, __be16 port)
i = be16_to_cpu(port) / RDS_CONG_MAP_PAGE_BITS;
off = be16_to_cpu(port) % RDS_CONG_MAP_PAGE_BITS;
- return generic_test_le_bit(off, (void *)map->m_page_addrs[i]);
+ return test_le_bit(off, (void *)map->m_page_addrs[i]);
}
void rds_cong_add_socket(struct rds_sock *rs)
diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c
index 5225052..da16155 100644
--- a/virt/kvm/kvm_main.c
+++ b/virt/kvm/kvm_main.c
@@ -1252,7 +1252,7 @@ void mark_page_dirty(struct kvm *kvm, gfn_t gfn)
if (memslot && memslot->dirty_bitmap) {
unsigned long rel_gfn = gfn - memslot->base_gfn;
- generic___set_le_bit(rel_gfn, memslot->dirty_bitmap);
+ __set_le_bit(rel_gfn, memslot->dirty_bitmap);
}
}
--
1.7.3.2
^ permalink raw reply related
* Re: Change in PCI behaviour
From: Gary Thomas @ 2010-11-23 14:44 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: Linux PPC Development
In-Reply-To: <1290457615.32570.67.camel@pasglop>
On 11/22/2010 01:26 PM, Benjamin Herrenschmidt wrote:
> On Mon, 2010-11-22 at 03:01 -0700, Gary Thomas wrote:
>> I have a bit more information on this. I'm pretty sure that the failures
>> are only happening in my SCSI (SATA actually) code. My board (8347ea) has
>> a PCI bus with a SIL SATA controller. This combo works perfectly in 2.6.28.
>> In 2.6.32, it will run for a while (possibly quite a while), then timeout
>> trying to do a large block write - typically 256 blocks. Once this timeout
>> happens, the SIL controller is stuck and accesses to it will eventually
>> cause the whole system to hang (as above).
>>
>> Was there any major change in how PCI or DMA was handled between 2.6.28
>> and 2.6.32? Given the ephemeral nature of these failures (multiple runs
>> all eventually fail, but never the same twice), my only hope of fixing it
>> will be to have some ideas what might have changed.
>
> Maybe the changes you did to the PCI outbound windows are now breaking
> DMA ? Make sure the outbound and inbound don't overlap for example and
> that all RAM is reachable for inbound.
Here's what I did to work around this - in my DTS, I set up my PCI as
ranges = <0x02000000 0x0 0xC4000000 0xC4000000 0x0 0x1C000000
0x01000000 0x0 0x00000000 0xB8000000 0x0 0x00100000>;
Before, I had it as
ranges = <0x02000000 0x0 0xC0000000 0xC0000000 0x0 0x20000000
0x01000000 0x0 0x00000000 0xB8000000 0x0 0x00100000>;
I wasn't sure how to reserve the memory (based on your earlier suggestion),
so I just narrowed the window. Note that I did not change the PCI hardware
registers (maybe the FSL code does?), so the outbound window should still
be the whole 512MB.
If this isn't viable, perhaps you could explain a bit more how to reserve
such a chunk of memory so that the PCI mappings remain the same.
Thanks again
--
------------------------------------------------------------
Gary Thomas | Consulting for the
MLB Associates | Embedded world
------------------------------------------------------------
^ permalink raw reply
* Re: [PATCH] MPC5200: Eliminate duplicate include of of_device.h
From: Mark Brown @ 2010-11-23 14:53 UTC (permalink / raw)
To: Jesper Juhl
Cc: alsa-devel, Takashi Iwai, linux-kernel, linuxppc-dev,
Liam Girdwood
In-Reply-To: <alpine.LNX.2.00.1011222246250.6285@swampdragon.chaosbits.net>
On Mon, Nov 22, 2010 at 10:54:03PM +0100, Jesper Juhl wrote:
>
> Eliminate duplicate #include <linux/of_device.h> from
> sound/soc/fsl/mpc5200_dma.c
Applied, thanks.
^ permalink raw reply
* [PATCH] Fixing the garbage collector problem after NAND-flash image record in u-boot
From: Sergej.Stepanov @ 2010-11-23 15:10 UTC (permalink / raw)
To: linuxppc-dev
This patch should fix the following problem:
1. the jffs2-image update in the u-boot was ok=20
2. first restart and first mount of the NAND-flash-partition was also ok
3. before the restart of controller there are no any activity on NAND-flas=
h except of the jffs2_gcd_mtdX-process ...
4. BUT after the second restart the NAND-flash-partition could not be real=
ly used after the second mount,
dmesg filled with messages:
...
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x03ce0000: 0xc0=
ff instead
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x03d00000: 0xc0=
ff instead
....
Just for for info: the behaviour observed on mpc8313-based board.
The only activity on NAND-flash was the garbage collector process, that loo=
ks for CLEANMARKER-nodes
Signed-off-by: Sergej Stepanov <Sergej.Stepanov@ids.de>
Cc: Rolf Riehle <Rolf.Riehle@ids.de>
--
diff --git a/drivers/mtd/nand/fsl_elbc_nand.c b/drivers/mtd/nand/fsl_elbc_n=
and.c
index c141b07..775c2f5 100644
--- a/drivers/mtd/nand/fsl_elbc_nand.c
+++ b/drivers/mtd/nand/fsl_elbc_nand.c
@@ -388,6 +388,7 @@ static void fsl_elbc_cmdfunc(struct mtd_info *mtd, unsi=
gned int command,
"page_addr: 0x%x, column: 0x%x.\n",
page_addr, column);
=20
+ elbc_fcm_ctrl->column =3D column;
elbc_fcm_ctrl->use_mdr =3D 1;
=20
fcr =3D (NAND_CMD_STATUS << FCR_CMD1_SHIFT) |
^ permalink raw reply related
* Re: [PATCH] Fixing the garbage collector problem after NAND-flash image record in u-boot
From: Scott Wood @ 2010-11-23 16:50 UTC (permalink / raw)
To: Sergej.Stepanov; +Cc: linuxppc-dev
In-Reply-To: <4206182445660643B9AEB8D4E55BBD0A106A0AA938@HERMES2>
On Tue, 23 Nov 2010 16:10:54 +0100
<Sergej.Stepanov@ids.de> wrote:
> This patch should fix the following problem:
> 1. the jffs2-image update in the u-boot was ok
> 2. first restart and first mount of the NAND-flash-partition was also ok
> 3. before the restart of controller there are no any activity on NAND-flash except of the jffs2_gcd_mtdX-process ...
> 4. BUT after the second restart the NAND-flash-partition could not be really used after the second mount,
> dmesg filled with messages:
> ...
> jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x03ce0000: 0xc0ff instead
> jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x03d00000: 0xc0ff instead
> ....
> Just for for info: the behaviour observed on mpc8313-based board.
> The only activity on NAND-flash was the garbage collector process, that looks for CLEANMARKER-nodes
>
> Signed-off-by: Sergej Stepanov <Sergej.Stepanov@ids.de>
> Cc: Rolf Riehle <Rolf.Riehle@ids.de>
> --
Acked-by: Scott Wood <scottwood@freescale.com>
>
> diff --git a/drivers/mtd/nand/fsl_elbc_nand.c b/drivers/mtd/nand/fsl_elbc_nand.c
> index c141b07..775c2f5 100644
> --- a/drivers/mtd/nand/fsl_elbc_nand.c
> +++ b/drivers/mtd/nand/fsl_elbc_nand.c
> @@ -388,6 +388,7 @@ static void fsl_elbc_cmdfunc(struct mtd_info *mtd, unsigned int command,
> "page_addr: 0x%x, column: 0x%x.\n",
> page_addr, column);
>
> + elbc_fcm_ctrl->column = column;
> elbc_fcm_ctrl->use_mdr = 1;
This was broken by commit 3ab8f2a2e7011c5e83363b42950757e46ef06824
That commit also removed the setting of ctrl->oob to 0, which should
also be restored.
-Scott
^ 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