* [PATCH 2/3] [libata] pata_of_platform: OF-Platform PATA device driver
From: Anton Vorontsov @ 2007-11-27 15:39 UTC (permalink / raw)
To: linuxppc-dev, linux-ide
In-Reply-To: <20071127153708.GA12490@localhost.localdomain>
This driver nicely wraps around pata_platform library functions,
and provides OF platform bus bindings to the PATA devices.
Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
---
drivers/ata/Kconfig | 10 +++++
drivers/ata/Makefile | 1 +
drivers/ata/pata_of_platform.c | 86 ++++++++++++++++++++++++++++++++++++++++
3 files changed, 97 insertions(+), 0 deletions(-)
create mode 100644 drivers/ata/pata_of_platform.c
diff --git a/drivers/ata/Kconfig b/drivers/ata/Kconfig
index ba63619..5a492fa 100644
--- a/drivers/ata/Kconfig
+++ b/drivers/ata/Kconfig
@@ -614,6 +614,16 @@ config PATA_PLATFORM
If unsure, say N.
+config PATA_OF_PLATFORM
+ tristate "OpenFirmware platform device PATA support"
+ depends on PATA_PLATFORM && PPC_OF
+ help
+ This option enables support for generic directly connected ATA
+ devices commonly found on embedded systems with OpenFirmware
+ bindings.
+
+ If unsure, say N.
+
config PATA_ICSIDE
tristate "Acorn ICS PATA support"
depends on ARM && ARCH_ACORN
diff --git a/drivers/ata/Makefile b/drivers/ata/Makefile
index b13feb2..ebcee64 100644
--- a/drivers/ata/Makefile
+++ b/drivers/ata/Makefile
@@ -67,6 +67,7 @@ obj-$(CONFIG_PATA_IXP4XX_CF) += pata_ixp4xx_cf.o
obj-$(CONFIG_PATA_SCC) += pata_scc.o
obj-$(CONFIG_PATA_BF54X) += pata_bf54x.o
obj-$(CONFIG_PATA_PLATFORM) += pata_platform.o
+obj-$(CONFIG_PATA_OF_PLATFORM) += pata_of_platform.o
obj-$(CONFIG_PATA_ICSIDE) += pata_icside.o
# Should be last but two libata driver
obj-$(CONFIG_PATA_ACPI) += pata_acpi.o
diff --git a/drivers/ata/pata_of_platform.c b/drivers/ata/pata_of_platform.c
new file mode 100644
index 0000000..e6c769c
--- /dev/null
+++ b/drivers/ata/pata_of_platform.c
@@ -0,0 +1,86 @@
+/*
+ * OF-platform PATA driver
+ *
+ * Copyright (c) 2007 MontaVista Software, Inc.
+ * Anton Vorontsov <avorontsov@ru.mvista.com>
+ *
+ * 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/kernel.h>
+#include <linux/module.h>
+#include <linux/of_platform.h>
+#include <linux/pata_platform.h>
+
+static int __devinit pata_of_platform_probe(struct of_device *ofdev,
+ const struct of_device_id *match)
+{
+ int ret;
+ struct device_node *dn = ofdev->node;
+ struct resource io_res;
+ struct resource ctl_res;
+ struct resource irq_res;
+ unsigned int ioport_shift = 0;
+ uint32_t *prop;
+
+ ret = of_address_to_resource(dn, 0, &io_res);
+ if (ret) {
+ dev_err(&ofdev->dev, "can't get IO address from "
+ "device tree\n");
+ return -EINVAL;
+ }
+
+ ret = of_address_to_resource(dn, 1, &ctl_res);
+ if (ret) {
+ dev_err(&ofdev->dev, "can't get CTL address from "
+ "device tree\n");
+ return -EINVAL;
+ }
+
+ ret = of_irq_to_resource(dn, 0, &irq_res);
+ if (ret == NO_IRQ)
+ irq_res.start = irq_res.end = -1;
+ else
+ irq_res.flags = 0;
+
+ prop = (uint32_t *)of_get_property(dn, "ioport-shift", NULL);
+ if (prop)
+ ioport_shift = *prop;
+
+ return __pata_platform_probe(&ofdev->dev, &io_res, &ctl_res, &irq_res,
+ ioport_shift);
+}
+
+static int __devexit pata_of_platform_remove(struct of_device *ofdev)
+{
+ return __pata_platform_remove(&ofdev->dev);
+}
+
+static struct of_device_id pata_of_platform_match[] = {
+ { .compatible = "pata-platform", },
+};
+
+static struct of_platform_driver pata_of_platform_driver = {
+ .name = "pata_of_platform",
+ .match_table = pata_of_platform_match,
+ .probe = pata_of_platform_probe,
+ .remove = __devexit_p(pata_of_platform_remove),
+};
+
+static int __init pata_of_platform_init(void)
+{
+ return of_register_platform_driver(&pata_of_platform_driver);
+}
+module_init(pata_of_platform_init);
+
+static void __exit pata_of_platform_exit(void)
+{
+ of_unregister_platform_driver(&pata_of_platform_driver);
+}
+module_exit(pata_of_platform_exit);
+
+MODULE_DESCRIPTION("OF-platform PATA driver");
+MODULE_AUTHOR("Anton Vorontsov <avorontsov@ru.mvista.com>");
+MODULE_LICENSE("GPL");
--
1.5.2.2
^ permalink raw reply related
* [PATCH 3/3] [POWERPC] MPC8349E-mITX: introduce localbus and pata nodes
From: Anton Vorontsov @ 2007-11-27 15:39 UTC (permalink / raw)
To: linuxppc-dev, linux-ide
In-Reply-To: <20071127153708.GA12490@localhost.localdomain>
This patch adds localbus and pata nodes to use CF IDE interface
on MPC8349E-mITX boards.
Patch also adds code to probe localbus.
Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
---
arch/powerpc/boot/dts/mpc8349emitx.dts | 17 ++++++++++++++++-
arch/powerpc/platforms/83xx/mpc834x_itx.c | 17 +++++++++++++++++
2 files changed, 33 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/boot/dts/mpc8349emitx.dts b/arch/powerpc/boot/dts/mpc8349emitx.dts
index 5072f6d..7a97068 100644
--- a/arch/powerpc/boot/dts/mpc8349emitx.dts
+++ b/arch/powerpc/boot/dts/mpc8349emitx.dts
@@ -249,6 +249,21 @@
device_type = "pci";
};
+ localbus@e0005000 {
+ #address-cells = <2>;
+ #size-cells = <1>;
+ compatible = "fsl,mpc8349emitx-localbus",
+ "fsl,mpc8349e-localbus",
+ "fsl,pq2pro-localbus";
+ reg = <e0005000 d8>;
+ ranges = <3 0 f0000000 210>;
-
+ pata@3,0 {
+ compatible = "fsl,mpc8349emitx-pata", "pata-platform";
+ reg = <3 0 10 3 20c 4>;
+ ioport-shift = <1>;
+ interrupts = <17 8>;
+ interrupt-parent = <&ipic>;
+ };
+ };
};
diff --git a/arch/powerpc/platforms/83xx/mpc834x_itx.c b/arch/powerpc/platforms/83xx/mpc834x_itx.c
index aa76819..ea5f176 100644
--- a/arch/powerpc/platforms/83xx/mpc834x_itx.c
+++ b/arch/powerpc/platforms/83xx/mpc834x_itx.c
@@ -23,6 +23,7 @@
#include <linux/delay.h>
#include <linux/seq_file.h>
#include <linux/root_dev.h>
+#include <linux/of_platform.h>
#include <asm/system.h>
#include <asm/atomic.h>
@@ -37,6 +38,22 @@
#include "mpc83xx.h"
+static struct of_device_id mpc834x_itx_ids[] = {
+ { .name = "localbus", },
+ {},
+};
+
+static int __init mpc834x_itx_declare_of_platform_devices(void)
+{
+ if (!machine_is(mpc834x_itx))
+ return 0;
+
+ of_platform_bus_probe(NULL, mpc834x_itx_ids, NULL);
+
+ return 0;
+}
+device_initcall(mpc834x_itx_declare_of_platform_devices);
+
/* ************************************************************************
*
* Setup the architecture
--
1.5.2.2
^ permalink raw reply related
* Re: [PATCH 3/3] [POWERPC] MPC8349E-mITX: introduce localbus and pata nodes
From: Sergei Shtylyov @ 2007-11-27 15:49 UTC (permalink / raw)
To: Anton Vorontsov; +Cc: linuxppc-dev, linux-ide
In-Reply-To: <20071127153940.GC14183@localhost.localdomain>
Hello.
Anton Vorontsov wrote:
> This patch adds localbus and pata nodes to use CF IDE interface
> on MPC8349E-mITX boards.
> Patch also adds code to probe localbus.
> Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
> ---
> arch/powerpc/boot/dts/mpc8349emitx.dts | 17 ++++++++++++++++-
> arch/powerpc/platforms/83xx/mpc834x_itx.c | 17 +++++++++++++++++
> 2 files changed, 33 insertions(+), 1 deletions(-)
> diff --git a/arch/powerpc/boot/dts/mpc8349emitx.dts b/arch/powerpc/boot/dts/mpc8349emitx.dts
> index 5072f6d..7a97068 100644
> --- a/arch/powerpc/boot/dts/mpc8349emitx.dts
> +++ b/arch/powerpc/boot/dts/mpc8349emitx.dts
> @@ -249,6 +249,21 @@
> device_type = "pci";
> };
>
> + localbus@e0005000 {
> + #address-cells = <2>;
> + #size-cells = <1>;
> + compatible = "fsl,mpc8349emitx-localbus",
Board compatible bus?
> + "fsl,mpc8349e-localbus",
> + "fsl,pq2pro-localbus";
> + reg = <e0005000 d8>;
> + ranges = <3 0 f0000000 210>;
>
> -
> + pata@3,0 {
> + compatible = "fsl,mpc8349emitx-pata", "pata-platform";
> + reg = <3 0 10 3 20c 4>;
> + ioport-shift = <1>;
Bleh... that shift again. And this is surely not a good name for a
property (where's I/O ports in your case?) -- why not call it "reg-shift"
(well, I'd call it "reg-size" or "reg-stride" myself :-)?
MBR, Sergei
^ permalink raw reply
* How to notify userspace of custom bus master/slave access mode changes ?
From: Laurent Pinchart @ 2007-11-27 15:51 UTC (permalink / raw)
To: linuxppc-dev
[-- Attachment #1: Type: text/plain, Size: 2043 bytes --]
Hi everybody,
I'm a bit unsure about how to notify userspace of changes to access mode to a
custom bus. This is more an architecture issue than an implementation issue.
My system has an ISA-like cold-pluggable extension bus. The bus controller
sits on the CPU board which is plugged along with slave devices into a
passive backplane.
To add CPU redundancy support to the system, I implemented master and slave
modes for the CPU board. The slave monitors the master and can disconnect it
from the bus when a failure is detected.
The bus drivers haven't been developed with hotplug in mind, but I eventually
managed to fix them. The kernel is now able to scan the bus when a CPU board
switches from slave to master mode, adding peripherals as they are detected,
and to remove all peripherals when the CPU board switches from master to
slave.
I now have to notify userspace applications of master <-> slave mode changes.
I thought about using kobject netlink notifications, but the kernel only
generates events for individual peripherals (when they are added or removed).
The bus driver registers a peripheral for the bus controller at boot time. I
thought about registering the peripheral only when the system switches from
slave to master, and deregistering it when it switches back to slave mode,
but that's not very clean as the bus controller is always attached to the
CPU, regardless of its bus access mode. Beside, I need to access the bus
controller to detect master <-> slave transitions, so this would be a bit
hackish.
Is there a kobject netlink event I could use that I haven't thought about ? Am
I missing a pseudo-peripheral in my implementation ? Is there a preferred way
to notify userspace of such events ?
Thanks for any help you can provide (and thanks for having read this mail
throughout :-)).
Best regards,
--
Laurent Pinchart
CSE Semaphore Belgium
Chaussée de Bruxelles, 732A
B-1410 Waterloo
Belgium
T +32 (2) 387 42 59
F +32 (2) 387 42 75
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH 3/3] [POWERPC] MPC8349E-mITX: introduce localbus and pata nodes
From: Anton Vorontsov @ 2007-11-27 16:41 UTC (permalink / raw)
To: Sergei Shtylyov; +Cc: linuxppc-dev, linux-ide
In-Reply-To: <474C3C79.5060908@ru.mvista.com>
On Tue, Nov 27, 2007 at 06:49:13PM +0300, Sergei Shtylyov wrote:
> Hello.
Hi Sergei,
> Anton Vorontsov wrote:
>
> >This patch adds localbus and pata nodes to use CF IDE interface
> >on MPC8349E-mITX boards.
>
> >Patch also adds code to probe localbus.
>
> >Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
> >---
> > arch/powerpc/boot/dts/mpc8349emitx.dts | 17 ++++++++++++++++-
> > arch/powerpc/platforms/83xx/mpc834x_itx.c | 17 +++++++++++++++++
> > 2 files changed, 33 insertions(+), 1 deletions(-)
>
> >diff --git a/arch/powerpc/boot/dts/mpc8349emitx.dts
> >b/arch/powerpc/boot/dts/mpc8349emitx.dts
> >index 5072f6d..7a97068 100644
> >--- a/arch/powerpc/boot/dts/mpc8349emitx.dts
> >+++ b/arch/powerpc/boot/dts/mpc8349emitx.dts
> >@@ -249,6 +249,21 @@
> > device_type = "pci";
> > };
> >
> >+ localbus@e0005000 {
> >+ #address-cells = <2>;
> >+ #size-cells = <1>;
> >+ compatible = "fsl,mpc8349emitx-localbus",
>
> Board compatible bus?
This is what Documentation/powerpc/booting-without-of.txt suggests
for localbuses. I'm following.
> >+ "fsl,mpc8349e-localbus",
> >+ "fsl,pq2pro-localbus";
> >+ reg = <e0005000 d8>;
> >+ ranges = <3 0 f0000000 210>;
> >
> >-
> >+ pata@3,0 {
> >+ compatible = "fsl,mpc8349emitx-pata",
> >"pata-platform";
> >+ reg = <3 0 10 3 20c 4>;
> >+ ioport-shift = <1>;
>
> Bleh... that shift again. And this is surely not a good name for a
> property (where's I/O ports in your case?) -- why not call it "reg-shift"
> (well, I'd call it "reg-size" or "reg-stride" myself :-)?
1. "shift" because pata_platform using that name. I don't see any
reason to contrive indirections. ioport-shift is what the whole
Linux kernel using nowadays, and ioport-shift dts property
anyway Linux-specific.
I'm just following todays' conventions.
If you feel really bad about that, I think better to fix that in
the source of the badness -- pata_platform. It's easy, I can do
that. Would you ack patch that converts whole pata_platform and
users? Would Paul ack it?
Still, is there any hardware that needs not power of 2 stride?
2. "ioport" because shift^Wstride ;-) applies only to the io range
(yes, it's obvious, but worth open-wording, no?).
And btw, I can get rid of ioport-shift at all. And do fixups in
the pata_of_platform driver via .compatible matching. But I don't
want: it feels bad to list every needs-to-fixup board in the common
driver. It also feels not so great creating something like
pata-platform-stride-{1,2,4,...} compatible stuff. Heh.
Thanks,
--
Anton Vorontsov
email: cbou@mail.ru
backup email: ya-cbou@yandex.ru
irc://irc.freenode.net/bd2
^ permalink raw reply
* Re: The question about the high memory support on MPC8360?
From: Scott Wood @ 2007-11-27 17:02 UTC (permalink / raw)
To: vijay baskar; +Cc: 郭劲, linuxppc-embedded
In-Reply-To: <474B9CC0.2000803@gdatech.co.in>
vijay baskar wrote:
> The kernel maps the last 1 GB of the virtual address space one to one
> to the physical memory.
No, it maps 768MB of RAM in this manner.
> This is called the kernel space. After the one
> to one mapping is done for the available physical memory, the
> remaining virtual addresses are used for vmalloc and ioremap.
And highmem mappings.
> The kernel also allows hardcoded mapping
> of IO regions into its virtual address space through the
> io_block_mapping interface.
Not in current arch/powerpc kernels.
> Many boards use the block IO mapping to
> map the CCSRBAR/IMMR into the kernel address space, such that the
> physical address and the virutal address is the same. Virtual
> addresses beyond these hardcoded mappings cannot be used by
> vmalloc/ioremap.
And this is why.
> Now as more and more memory is added to the system the addresses
> available for vmalloc and ioremap gets reduced, and memory allocations
> start to fail, due to the lack of availability of virtual addresses.
How so? The size of lowmem is constant once you reach the threshold, as
is the size of the highmem mapping area.
What *does* start to fail eventually, if you have a *lot* of highmem, is
that you run out of lowmem for pagetables and such.
-Scott
^ permalink raw reply
* Re: [PATCH 3/3] [POWERPC] MPC8349E-mITX: introduce localbus and pata nodes
From: Sergei Shtylyov @ 2007-11-27 16:46 UTC (permalink / raw)
To: avorontsov; +Cc: linuxppc-dev, linux-ide
In-Reply-To: <20071127164101.GA14790@localhost.localdomain>
Anton Vorontsov wrote:
>>>This patch adds localbus and pata nodes to use CF IDE interface
>>>on MPC8349E-mITX boards.
>>>Patch also adds code to probe localbus.
>>>Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
>>>---
>>>arch/powerpc/boot/dts/mpc8349emitx.dts | 17 ++++++++++++++++-
>>>arch/powerpc/platforms/83xx/mpc834x_itx.c | 17 +++++++++++++++++
>>>2 files changed, 33 insertions(+), 1 deletions(-)
>>>diff --git a/arch/powerpc/boot/dts/mpc8349emitx.dts
>>>b/arch/powerpc/boot/dts/mpc8349emitx.dts
>>>index 5072f6d..7a97068 100644
>>>--- a/arch/powerpc/boot/dts/mpc8349emitx.dts
>>>+++ b/arch/powerpc/boot/dts/mpc8349emitx.dts
>>>@@ -249,6 +249,21 @@
>>> device_type = "pci";
>>> };
>>>
>>>+ localbus@e0005000 {
>>>+ #address-cells = <2>;
>>>+ #size-cells = <1>;
>>>+ compatible = "fsl,mpc8349emitx-localbus",
>>
>> Board compatible bus?
> This is what Documentation/powerpc/booting-without-of.txt suggests
> for localbuses. I'm following.
Hm...
>>>+ "fsl,mpc8349e-localbus",
>>>+ "fsl,pq2pro-localbus";
>>>+ reg = <e0005000 d8>;
>>>+ ranges = <3 0 f0000000 210>;
>>>
>>>-
>>>+ pata@3,0 {
>>>+ compatible = "fsl,mpc8349emitx-pata",
>>>"pata-platform";
>>>+ reg = <3 0 10 3 20c 4>;
>>>+ ioport-shift = <1>;
>> Bleh... that shift again. And this is surely not a good name for a
>>property (where's I/O ports in your case?) -- why not call it "reg-shift"
>>(well, I'd call it "reg-size" or "reg-stride" myself :-)?
> 1. "shift" because pata_platform using that name. I don't see any
> reason to contrive indirections. ioport-shift is what the whole
> Linux kernel using nowadays, and ioport-shift dts property
> anyway Linux-specific.
It's just a bad name. There's not even I/O ports in this case (and
moreover, the *real* I/O mapped device would always have a shift of 0, I bet
-- larger strides are for memory mapped devices).
> I'm just following todays' conventions.
> If you feel really bad about that, I think better to fix that in
> the source of the badness -- pata_platform. It's easy, I can do
I only feel really bad about the "ioport" part, I can live with "shift"
part. :-)
> that. Would you ack patch that converts whole pata_platform and
> users? Would Paul ack it?
I don't understand -- why the property name should duplicate pata_platform
field name? :-O
> Still, is there any hardware that needs not power of 2 stride?
Not really -- "size" just seems better, aesthetically. :-)
> 2. "ioport" because shift^Wstride ;-) applies only to the io range
> (yes, it's obvious, but worth open-wording, no?).
Contrarywise, to memory range.
> And btw, I can get rid of ioport-shift at all. And do fixups in
> the pata_of_platform driver via .compatible matching. But I don't
> want: it feels bad to list every needs-to-fixup board in the common
> driver. It also feels not so great creating something like
> pata-platform-stride-{1,2,4,...} compatible stuff. Heh.
I didn't propose neither of that. :-)
All I want is that "ioport-*" be renamed.
> Thanks,
MBR, Sergei
^ permalink raw reply
* Re: [PATCH 3/3] [POWERPC] MPC8349E-mITX: introduce localbus and pata nodes
From: Anton Vorontsov @ 2007-11-27 17:27 UTC (permalink / raw)
To: Sergei Shtylyov; +Cc: linuxppc-dev, linux-ide
In-Reply-To: <474C49D5.2000206@ru.mvista.com>
On Tue, Nov 27, 2007 at 07:46:13PM +0300, Sergei Shtylyov wrote:
[...]
> >>>+ ioport-shift = <1>;
>
> >> Bleh... that shift again. And this is surely not a good name for a
> >>property (where's I/O ports in your case?) -- why not call it "reg-shift"
> >>(well, I'd call it "reg-size" or "reg-stride" myself :-)?
>
> >1. "shift" because pata_platform using that name. I don't see any
> > reason to contrive indirections. ioport-shift is what the whole
> > Linux kernel using nowadays, and ioport-shift dts property
> > anyway Linux-specific.
>
> It's just a bad name. There's not even I/O ports in this case (and
> moreover, the *real* I/O mapped device would always have a shift of 0, I
> bet -- larger strides are for memory mapped devices).
>
> > I'm just following todays' conventions.
>
> > If you feel really bad about that, I think better to fix that in
> > the source of the badness -- pata_platform. It's easy, I can do
>
> I only feel really bad about the "ioport" part, I can live with "shift"
> part. :-)
>
> > that. Would you ack patch that converts whole pata_platform and
> > users? Would Paul ack it?
>
> I don't understand -- why the property name should duplicate
> pata_platform field name? :-O
Because:
> >1. [...] I don't see any reason to contrive indirections.
That is, different names for single thing is worse than single
bogus name.
> Not really -- "size" just seems better, aesthetically. :-)
reg-size will look confusing. Is it ata registers' size? No,
can't be. So, what is it? It's stride/shift because of bus, on
which ata resides.
> >And btw, I can get rid of ioport-shift at all. And do fixups in
> >the pata_of_platform driver via .compatible matching. But I don't
> >want: it feels bad to list every needs-to-fixup board in the common
> >driver. It also feels not so great creating something like
> >pata-platform-stride-{1,2,4,...} compatible stuff. Heh.
>
> I didn't propose neither of that. :-)
Yup, that was "by the way"...
> All I want is that "ioport-*" be renamed.
I give up.
The final name is..? I can think out wrong one, so you'd better
convoy me on that way. ;-) reg-shift sounds okay? Or reg-stride
better? No size, please.
Thanks,
--
Anton Vorontsov
email: cbou@mail.ru
backup email: ya-cbou@yandex.ru
irc://irc.freenode.net/bd2
^ permalink raw reply
* Re: [PATCH 3/3] [POWERPC] MPC8349E-mITX: introduce localbus and pata nodes
From: Sergei Shtylyov @ 2007-11-27 17:25 UTC (permalink / raw)
To: avorontsov; +Cc: linuxppc-dev, linux-ide
In-Reply-To: <20071127172758.GA15429@localhost.localdomain>
Anton Vorontsov wrote:
>> All I want is that "ioport-*" be renamed.
> I give up.
Don't. :-)
> The final name is..? I can think out wrong one, so you'd better
> convoy me on that way. ;-) reg-shift sounds okay?
Yes.
> Thanks,
WBR, Sergei
^ permalink raw reply
* Re: [PATCH 3/3] [POWERPC] MPC8349E-mITX: introduce localbus and pata nodes
From: Anton Vorontsov @ 2007-11-27 17:34 UTC (permalink / raw)
To: Sergei Shtylyov; +Cc: linuxppc-dev, linux-ide
In-Reply-To: <474C49D5.2000206@ru.mvista.com>
[ Had cut too much in the previous reply ]
On Tue, Nov 27, 2007 at 07:46:13PM +0300, Sergei Shtylyov wrote:
[...]
> >2. "ioport" because shift^Wstride ;-) applies only to the io range
> > (yes, it's obvious, but worth open-wording, no?).
>
> Contrarywise, to memory range.
By io range I meant "I/O base", in contrast to "CTL base".
There is no need to apply shifting for CTL. That's why ioport-*
appeared in the first place.
--
Anton Vorontsov
email: cbou@mail.ru
backup email: ya-cbou@yandex.ru
irc://irc.freenode.net/bd2
^ permalink raw reply
* Re: [PATCH 3/3] [POWERPC] MPC8349E-mITX: introduce localbus and pata nodes
From: Sergei Shtylyov @ 2007-11-27 17:34 UTC (permalink / raw)
To: avorontsov; +Cc: linuxppc-dev, linux-ide
In-Reply-To: <20071127173456.GA15693@localhost.localdomain>
Anton Vorontsov wrote:
>>>2. "ioport" because shift^Wstride ;-) applies only to the io range
>>> (yes, it's obvious, but worth open-wording, no?).
>> Contrarywise, to memory range.
> By io range I meant "I/O base", in contrast to "CTL base".
> There is no need to apply shifting for CTL. That's why ioport-*
> appeared in the first place.
So, a matter of wrong terminology then. The thing that you meant by "I/O"
is actually called "command block".
MBR, Sergei
^ permalink raw reply
* Re: [PATCH 3/3] [POWERPC] MPC8349E-mITX: introduce localbus and pata nodes
From: Anton Vorontsov @ 2007-11-27 17:48 UTC (permalink / raw)
To: Sergei Shtylyov; +Cc: linuxppc-dev, linux-ide
In-Reply-To: <474C5513.6010801@ru.mvista.com>
On Tue, Nov 27, 2007 at 08:34:11PM +0300, Sergei Shtylyov wrote:
> Anton Vorontsov wrote:
>
> >>>2. "ioport" because shift^Wstride ;-) applies only to the io range
> >>> (yes, it's obvious, but worth open-wording, no?).
>
> >> Contrarywise, to memory range.
>
> >By io range I meant "I/O base", in contrast to "CTL base".
>
> >There is no need to apply shifting for CTL. That's why ioport-*
> >appeared in the first place.
>
> So, a matter of wrong terminology then. The thing that you meant by
> "I/O" is actually called "command block".
Yes. And IO is the second name. It's used widespread in the
drivers/ide/.
Now you understand why I'm so reluctant to hanging up different
labels on the single thing? ;-)
--
Anton Vorontsov
email: cbou@mail.ru
backup email: ya-cbou@yandex.ru
irc://irc.freenode.net/bd2
^ permalink raw reply
* Re: 85xx software reset problems from paulus.git
From: Kumar Gala @ 2007-11-27 16:26 UTC (permalink / raw)
To: Dale Farnsworth; +Cc: linuxppc-embedded
In-Reply-To: <20071127145424.8925.qmail@farnsworth.org>
On Nov 27, 2007, at 8:54 AM, Dale Farnsworth wrote:
> I wrote:
>> Kumar Gala wrote:
>>>>> Yes. The symptoms in 2.6.24RC2 are that during a kernel panic or
>>>>> when
>>>>> calling 'reboot' in the shell, it just hangs. Using the same dts
>>>>> and
>>>>> resets in 2.6.23.1 reboots fine. I don't have a cds reference, but
>>>>> someone who does should be able to confirm whether the issue
>>>>> exists
>>>>> or
>>>>> not by just attempting to reboot via bash.
>>>
>>> Can someone do a git-bisect and find the patch that breaks things?
>>
>> I'll see if I can reproduce it on my 8548cds. If so, I'll then git-
>> bisect.
>
> I tried this with the current powerpc.git tree on my mpc8548cds, and
> the reboot command works for me. The system rebooted just fine.
I'm wondering if there is an issue rebooting if we are in an oops.
- k
^ permalink raw reply
* Re: [PATCH 3/3] [POWERPC] MPC8349E-mITX: introduce localbus and pata nodes
From: Sergei Shtylyov @ 2007-11-27 18:07 UTC (permalink / raw)
To: avorontsov; +Cc: linuxppc-dev, linux-ide
In-Reply-To: <20071127174826.GA15980@localhost.localdomain>
Anton Vorontsov wrote:
>>>>>2. "ioport" because shift^Wstride ;-) applies only to the io range
>>>>>(yes, it's obvious, but worth open-wording, no?).
>>>> Contrarywise, to memory range.
>>>By io range I meant "I/O base", in contrast to "CTL base".
>>>There is no need to apply shifting for CTL. That's why ioport-*
>>>appeared in the first place.
>> So, a matter of wrong terminology then. The thing that you meant by
>> "I/O" is actually called "command block".
> Yes. And IO is the second name.
I'd say the first place in drivers/ide belongs to the historic name
"taskfile". The "command block" which is as ATA standard calls it, is hardly used.
> It's used widespread in the drivers/ide/.
Don't remember seeing it.
> Now you understand why I'm so reluctant to hanging up different
> labels on the single thing? ;-)
:-)
MBR, Sergei
^ permalink raw reply
* Re: Linuxppc-embedded Digest, Vol 39, Issue 48
From: fabio777 @ 2007-11-27 18:59 UTC (permalink / raw)
To: linuxppc-embedded, bwarren
In-Reply-To: <mailman.3149.1196114204.3099.linuxppc-embedded@ozlabs.org>
Thanks Ben,
Here it is
static struct fsl_spi_platform_data k_platform_data = {
.initial_spmode = 0,
.bus_num = 1,
.max_chipselect = 1,
/* board specific information */
.activate_cs = k_cs_activate,
.deactivate_cs = k_cs_deactivate,
.sysclk = 266,
};
static struct spi_board_info spi_board_info[] __initdata = { {
.modalias = "kplus",
.platform_data = &k_platform_data,
.max_speed_hz = 120000,
.bus_num = 1,
.chip_select = 0,
},
};
struct platform_device k_plus = {
.name = "kplus",
.id = 1,
.dev = {
.platform_data = &k_platform_data,
},
};
platform_device_register(&k_plus);
spi_register_board_info(spi_board_info, ARRAY_SIZE(spi_board_info))
and then calls spi_register_driver(&k_driver);
I can't get the into the *probe functions.
Thanks
>
> fabio777 wrote:
>
>> Has anyone been using this driver ?
>>
>>
> I use it, on ARCH=powerpc, though.
>
>> For legacy reasons I need to keep the ppc=arch however I haven't found
>> out how to get this driver probed at start-up even basing my init on
>> Lublock.
>>
>>
>>
> The driver's expecting a platform device with name "mpc83xx_spi" to be
> registered in board init code. If you post your init code I may be able
> to help.
>
> regards,
> Ben
>
>
^ permalink raw reply
* Re: SPI driver for spi_mpc83xx
From: Ben Warren @ 2007-11-27 19:33 UTC (permalink / raw)
To: fabio777; +Cc: linuxppc-embedded
In-Reply-To: <474C6920.3030109@gmail.com>
Fabio,
Note: I've changed the e-mail subject back to the original. In the
future, please ensure that it remains intact.
fabio777 wrote:
> Thanks Ben,
>
> Here it is
>
> static struct fsl_spi_platform_data k_platform_data = {
> .initial_spmode = 0,
> .bus_num = 1,
Probably should be bus_num = 0
> .max_chipselect = 1,
> /* board specific information */
> .activate_cs = k_cs_activate,
> .deactivate_cs = k_cs_deactivate,
> .sysclk = 266,
> };
>
> static struct spi_board_info spi_board_info[] __initdata = { {
> .modalias = "kplus",
> .platform_data = &k_platform_data,
> .max_speed_hz = 120000,
> .bus_num = 1,
Again, bus_num probably should be 0
> .chip_select = 0,
> },
> };
>
>
> struct platform_device k_plus = {
> .name = "kplus",
name should be "mpc83xx_spi". At initialization, the SPI controller
driver searches the registered platform devices (models of board
hardware) for a match. Without a match, it gives up.
> .id = 1,
> .dev = {
> .platform_data = &k_platform_data,
> },
> };
>
> platform_device_register(&k_plus);
>
Do you add the SPI controller's resources (base address and IRQ?) You'll
need to in order for this to work. On my board, I use
'platform_device_register_simple()', passing the name and the two
resources, then call 'platform_add_data()', passing in the platform data
structure.
> spi_register_board_info(spi_board_info, ARRAY_SIZE(spi_board_info))
>
Good
> and then calls spi_register_driver(&k_driver);
I don't think this last call is needed.
>
> I can't get the into the *probe functions.
> Thanks
>
regards,
Ben
^ permalink raw reply
* Re: [PATCH 3/3] [POWERPC] MPC8349E-mITX: introduce localbus and pata nodes
From: Anton Vorontsov @ 2007-11-27 19:50 UTC (permalink / raw)
To: Sergei Shtylyov; +Cc: linuxppc-dev, linux-ide
In-Reply-To: <474C5CD2.7080208@ru.mvista.com>
On Tue, Nov 27, 2007 at 09:07:14PM +0300, Sergei Shtylyov wrote:
> Anton Vorontsov wrote:
>
> >>>>>2. "ioport" because shift^Wstride ;-) applies only to the io range
> >>>>>(yes, it's obvious, but worth open-wording, no?).
>
> >>>> Contrarywise, to memory range.
>
> >>>By io range I meant "I/O base", in contrast to "CTL base".
>
> >>>There is no need to apply shifting for CTL. That's why ioport-*
> >>>appeared in the first place.
>
> >> So, a matter of wrong terminology then. The thing that you meant by
> >> "I/O" is actually called "command block".
>
> > Yes. And IO is the second name.
>
> I'd say the first place in drivers/ide belongs to the historic name
> "taskfile". The "command block" which is as ATA standard calls it, is hardly used.
>
> > It's used widespread in the drivers/ide/.
>
> Don't remember seeing it.
Oops, thinko -- not drivers/ide/, but include/linux/ide.h.
Grep for io_addr.
> > Now you understand why I'm so reluctant to hanging up different
> > labels on the single thing? ;-)
>
> :-)
--
Anton Vorontsov
email: cbou@mail.ru
backup email: ya-cbou@yandex.ru
irc://irc.freenode.net/bd2
^ permalink raw reply
* Re: [PATCH 3/3] [POWERPC] MPC8349E-mITX: introduce localbus and pata nodes
From: Kumar Gala @ 2007-11-27 21:18 UTC (permalink / raw)
To: Sergei Shtylyov; +Cc: linuxppc-dev, linux-ide
In-Reply-To: <474C3C79.5060908@ru.mvista.com>
On Nov 27, 2007, at 9:49 AM, Sergei Shtylyov wrote:
> Hello.
>
> Anton Vorontsov wrote:
>
>> This patch adds localbus and pata nodes to use CF IDE interface
>> on MPC8349E-mITX boards.
>
>> Patch also adds code to probe localbus.
>
>> Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
>> ---
>> arch/powerpc/boot/dts/mpc8349emitx.dts | 17 ++++++++++++++++-
>> arch/powerpc/platforms/83xx/mpc834x_itx.c | 17 +++++++++++++++++
>> 2 files changed, 33 insertions(+), 1 deletions(-)
>
>> diff --git a/arch/powerpc/boot/dts/mpc8349emitx.dts b/arch/powerpc/=20=
>> boot/dts/mpc8349emitx.dts
>> index 5072f6d..7a97068 100644
>> --- a/arch/powerpc/boot/dts/mpc8349emitx.dts
>> +++ b/arch/powerpc/boot/dts/mpc8349emitx.dts
>> @@ -249,6 +249,21 @@
>> device_type =3D "pci";
>> };
>>
>> + localbus@e0005000 {
>> + #address-cells =3D <2>;
>> + #size-cells =3D <1>;
>> + compatible =3D "fsl,mpc8349emitx-localbus",
>
> Board compatible bus?
>
>> + "fsl,mpc8349e-localbus",
>> + "fsl,pq2pro-localbus";
>> + reg =3D <e0005000 d8>;
>> + ranges =3D <3 0 f0000000 210>;
>>
>> -
>> + pata@3,0 {
>> + compatible =3D "fsl,mpc8349emitx-pata", =
"pata-platform";
>> + reg =3D <3 0 10 3 20c 4>;
>> + ioport-shift =3D <1>;
>
> Bleh... that shift again. And this is surely not a good name for a
> property (where's I/O ports in your case?) -- why not call it "reg-=20
> shift"
> (well, I'd call it "reg-size" or "reg-stride" myself :-)?
I'm coming into this late, but if ioport-shift applies to reg (which I =20=
think it does) it should really be called "reg-shift". The ePAPR is =20
using that property name:
Specifies in bytes how far the discrete device registers are separated =20=
from each other. The
individual register location is calculated by using following formula: =20=
=93registers address=94 <<
reg-shift. If unspecified the default value is 0.
- k
^ permalink raw reply
* Re: [PATCH 2/3] [libata] pata_of_platform: OF-Platform PATA device driver
From: Olof Johansson @ 2007-11-27 21:22 UTC (permalink / raw)
To: Anton Vorontsov; +Cc: linuxppc-dev, linux-ide
In-Reply-To: <20071127153908.GB14183@localhost.localdomain>
On Tue, Nov 27, 2007 at 06:39:08PM +0300, Anton Vorontsov wrote:
> This driver nicely wraps around pata_platform library functions,
> and provides OF platform bus bindings to the PATA devices.
> +static struct of_device_id pata_of_platform_match[] = {
> + { .compatible = "pata-platform", },
> +};
"pata-platform" really means nothing outside of linux. A more
generic label would be useful.
-Olof
^ permalink raw reply
* Re: [PATCH 2/3] [libata] pata_of_platform: OF-Platform PATA device driver
From: Arnd Bergmann @ 2007-11-27 21:32 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Olof Johansson, linux-ide
In-Reply-To: <20071127212222.GB10829@lixom.net>
On Tuesday 27 November 2007, Olof Johansson wrote:
> On Tue, Nov 27, 2007 at 06:39:08PM +0300, Anton Vorontsov wrote:
> > This driver nicely wraps around pata_platform library functions,
> > and provides OF platform bus bindings to the PATA devices.
>=20
> > +static struct of_device_id pata_of_platform_match[] =3D {
> > +=A0=A0=A0=A0=A0{ .compatible =3D "pata-platform", },
> > +};
>=20
> "pata-platform" really means nothing outside of linux. A more
> generic label would be useful.
Maybe the name of the standards it supports? Could be
"ata-4", "ata-5" and the like, or the exact transfer mode, like
"pata-udma-5", "pata-pio-3", "sata-150", etc.
Arnd <><
^ permalink raw reply
* Re: Debugging with gdbserver slow
From: khollan @ 2007-11-27 21:38 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <13865715.post@talk.nabble.com>
Fixed. It turns out it was because I'm using VMWare to run Linux on my
windows computer. I booted up Linux natively and it stepped through code
very fast even in multi threaded apps.
--
View this message in context: http://www.nabble.com/Debugging-with-gdbserver-slow-tf4846374.html#a13980499
Sent from the linuxppc-embedded mailing list archive at Nabble.com.
^ permalink raw reply
* Re: [PATCH 1/3] [libata] pata_platform: make probe and remove functions device type neutral
From: Arnd Bergmann @ 2007-11-27 22:31 UTC (permalink / raw)
To: linuxppc-dev; +Cc: linux-ide
In-Reply-To: <20071127153900.GA14183@localhost.localdomain>
On Tuesday 27 November 2007, Anton Vorontsov wrote:
> Split pata_platform_{probe,remove} into two pieces:
> 1. pata_platform_{probe,remove} -- platform_device-dependant bits;
> 2. __ptata_platform_{probe,remove} -- device type neutral bits.
>
> This is done to not duplicate code for the OF-platform driver.
>
> Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
Acked-by: Arnd Bergmann <arnd@arndb.de>
^ permalink raw reply
* Re: PPC upstream kernel ignored DABR bug
From: Arnd Bergmann @ 2007-11-27 22:35 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Paul Mackerras, Jan Kratochvil, Roland McGrath
In-Reply-To: <20071126220224.GA5606@host0.dyn.jankratochvil.net>
On Monday 26 November 2007, Jan Kratochvil wrote:
> Hi,
>=20
> this testcase:
> =A0=A0=A0=A0=A0=A0=A0=A0http://people.redhat.com/jkratoch/dabr-lost.c
>=20
> reproduces a PPC DABR kernel bug. =A0The variable `variable' should not g=
et
> modified as the thread modifying it should be caught by its DABR:
>=20
> $ ./dabr-lost
> TID 30914: DABR 0x10012a77 NIP 0x80f6ebb318
> TID 30915: DABR 0x10012a77 NIP 0x80f6ebb318
> TID 30916: DABR 0x10012a77 NIP 0x80f6ebb318
> TID 30914: hitting the variable
> TID 30915: hitting the variable
> TID 30916: hitting the variable
> variable found =3D 30916, caught TID =3D 30914
> TID 30916: DABR 0x10012a77
> Variable got modified by a thread which has DABR still set!
>=20
This sounds like a bug recently reported by Uli Weigand. BenH
said he'd take a look, but it probably fell under the table.
The problem found by Uli is that on certain processors (Cell/B.E.
in his case), the DABRX register needs to be set in order for
the DABR to take effect.
Arnd <><
^ permalink raw reply
* Unable to Read PPC440EPx Board ID thru Board Control and Status Registers (BCSR)
From: Dell Query @ 2007-11-27 10:47 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 3859 bytes --]
Hi,
I am creating a simple program which will try to read the board ID of the PPC440EPx thru BCSR but when I load it, it gives me "Data Read PLB Error".
I am not sure if I missed out something.
I would really appreciate it if somebody could help me on this.
I have posted the source code below, as well as the complete message.
Many thanks!
SOURCE CODE:
----------------------------------------------------------------------
#include <linux/module.h>
#include <linux/kernel.h>
#include <linux/ioport.h>
#include <linux/delay.h>
#include <linux/init.h>
#include <linux/interrupt.h>
#include <linux/platform_device.h>
#include <asm/irq.h>
#include <asm/io.h>
#include <linux/i2c.h>
#include <linux/i2c-id.h>
#include <asm/ocp.h>
#include <asm/ibm4xx.h>
MODULE_LICENSE("GPL");
#define BCSR_BASE 0xC0002000
#define BCSR0 0
#define BCSR1 1
#define BCSR2 2
#define USER_LED 0x2
#define SIZE_TO_MAP 10
#define LED_ON 0
uint __iomem *bcsrbase = NULL;
static int __init initFunction(void) {
uint tmp;
printk("<1> Calling init function.\n");
printk("<1> bcsrbase value %p...\n",bcsrbase);
printk("<1> Remapping %x...\n",BCSR_BASE);
/*map*/
bcsrbase = ioremap(BCSR_BASE, SIZE_TO_MAP);
printk("<1> bcsrbase new value %p...\n",bcsrbase);
/*read value*/
/*based on PPC440EPx document, BCSR0 is BoardID*/
tmp = in_be32(bcsrbase + BCSR0 /* BCSR0 */);
printk("<1> BCSR0 %x...\n",tmp);
/*try to output something*/
//out_be32(bcsrbase , /*LED_ON*/);
return 0;
}
static void __exit cleanupFunction(void) {
printk("<1> Calling cleanup function.\n");
/*unmap*/
iounmap(bcsrbase);
}
module_init(initFunction);
module_exit(cleanupFunction);
----------------------------------------------------------------------
ERROR MESSAGE:
----------------------------------------------------------------------
/mnt/flash_fs/var/ftp # insmod bcsr.ko
Calling init function.
bcsrbase value 00000000...
Remapping c0002000...
bcsrbase new value d50fe000...
Machine check in kernel mode.
Data Read PLB Error
OPB to PLB3: BSTAT= 0x00000000
PLB3 to PLB4: BEAR=0xffffffffffff7fff BESR0=0x00000000 BESR1=0x00000000
PLB4 to PLB3: BEAR=0xfd7fffffffffffff BESR0=0x00000000 BESR1=0x00000000
PLB3 to OPB: BEAR=0xffffffff BESR0=0x00000000 BESR1=0x00000000
PLB3 arbiter: BEAR=0xbfffffef ACR=0x90000000 BESR=0x00000000
PLB4 to OPB1: BEAR=0x0000000efffbfffb BESR0=0x00000000 BESR1=0x00000000
PLB40 Arbiter: BEAR=0x00000000c0002000 ACR=0xde000000 BESR0=0x0f000000
PLB41 Arbiter: BEAR=0xfffffffffffffffa ACR=0xdf000000 BESR0=0x00000000
POB0: BEAR=0xc27e3194ffffffff BESR0=0x00000000 BESR1=0x00000000
OPB0: BEAR=0x0000000000000000 BSTAT=0x00000000
Oops: machine check, sig: 7 [#1]
NIP: D50FC07C LR: D50FC070 CTR: 00000000
REGS: c02bcf50 TRAP: 0202 Not tainted (2.6.21-rc4)
MSR: 00029000 <EE,ME> CR: 24004022 XER: 00000000
TASK = c05fe490[115] 'insmod' THREAD: cdc6c000
GPR00: D50FC070 CDC6DE80 C05FE490 00000023 0A00C100 00000001 00000000 00000031
GPR08: 00000000 D50FE000 000017E4 C0290000 04004022 1016F458 00000000 00000000
GPR16: 00000000 00000000 00000030 00000030 00000124 D51132BC 00000000 C0035E2C
GPR24: 00000022 D5108000 00000022 D50F7500 CF68A21C D50F0000 CF68A000 C0279CEC
NIP [D50FC07C] initFunction+0x7c/0x128 [bcsr]
LR [D50FC070] initFunction+0x70/0x128 [bcsr]
Call Trace:
[CDC6DE80] [D50FC070] initFunction+0x70/0x128 [bcsr] (unreliable)
[CDC6DEA0] [C003731C] sys_init_module+0xe4/0x1458
[CDC6DF40] [C0001AC4] ret_from_syscall+0x0/0x3c
Instruction dump:
60842000 38600000 48000065 7c601b78 3c60d50f 7c040378 386370e8 901d76a0
4800003d 813d76a0 7c0004ac 80890000 <0c040000> 4c00012c 3c60d50f 38637108
Bus error
----------------------------------------------------------------------
---------------------------------
Be a better pen pal. Text or chat with friends inside Yahoo! Mail. See how.
[-- Attachment #2: Type: text/html, Size: 4726 bytes --]
^ permalink raw reply
* Re: [PATCH] sys_indirect kernel implementation for PowerPC
From: Arnd Bergmann @ 2007-11-27 22:57 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <20071121144245.e8abf9e8.sfr@canb.auug.org.au>
On Wednesday 21 November 2007, Stephen Rothwell wrote:
> > +++ b/include/asm-powerpc/systbl.h
> > @@ -313,3 +313,4 @@ COMPAT_SYS_SPU(timerfd)
> > =A0SYSCALL_SPU(eventfd)
> > =A0COMPAT_SYS_SPU(sync_file_range2)
> > =A0COMPAT_SYS(fallocate)
> > +COMPAT_SYS(indirect)
>=20
> Do the SPUs want this?
Excellent question. Sorry for being late in my reply here. The calls
that are marked non-spu capable are those that are harmful when run
on the SPU, e.g. because they modify the signal mask -- the SPU cannot
receive signals itself.
sys_indirect is potentially very useful on the SPU, but we can't allow
it if it gives you access to all other syscalls. If we want to use it
on the SPU at some point, we may have to provide an alternative
implementation that walks the spu_syscall_table instead.
OTOH, if sys_indirect is mostly useful for the eventual addition of
syslets, we can leave it out, because syslets don't make sense if
you have no multithreading capability.
Arnd <><
^ 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