* [PATCH v5 0/2] SPI support for fsl_soc and mpc832x_rdb
From: Anton Vorontsov @ 2007-08-21 15:27 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <20070821134537.GA7428@localhost.localdomain>
On Tue, Aug 21, 2007 at 05:45:37PM +0400, Anton Vorontsov wrote:
> Hi all,
>
> Thanks for the previous reviews, this is v4 against Linus' tree,
> as of today.
Okay, here is brand-new, shiny v5. Today and only today it comes
without section mismatch warnings, don't miss your chance. Get it
free of charge! ;-)
--
Anton Vorontsov
email: cbou@mail.ru
backup email: ya-cbou@yandex.ru
irc://irc.freenode.net/bd2
^ permalink raw reply
* [PATCH v5 1/2] [POWERPC] fsl_soc: add support for fsl_spi
From: Anton Vorontsov @ 2007-08-21 15:29 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <20070821152745.GA28986@localhost.localdomain>
Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
---
arch/powerpc/sysdev/fsl_soc.c | 84 +++++++++++++++++++++++++++++++++++++++++
arch/powerpc/sysdev/fsl_soc.h | 7 +++
2 files changed, 91 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/sysdev/fsl_soc.c b/arch/powerpc/sysdev/fsl_soc.c
index 1cf29c9..2bdaeb2 100644
--- a/arch/powerpc/sysdev/fsl_soc.c
+++ b/arch/powerpc/sysdev/fsl_soc.c
@@ -24,6 +24,7 @@
#include <linux/platform_device.h>
#include <linux/of_platform.h>
#include <linux/phy.h>
+#include <linux/spi/spi.h>
#include <linux/fsl_devices.h>
#include <linux/fs_enet_pd.h>
#include <linux/fs_uart_pd.h>
@@ -1187,3 +1188,86 @@ err:
arch_initcall(cpm_smc_uart_of_init);
#endif /* CONFIG_8xx */
+
+int __init fsl_spi_init(struct spi_board_info *board_infos,
+ unsigned int num_board_infos,
+ void (*activate_cs)(u8 cs, u8 polarity),
+ void (*deactivate_cs)(u8 cs, u8 polarity))
+{
+ struct device_node *np;
+ unsigned int i;
+ u32 sysclk;
+
+ np = of_find_node_by_type(NULL, "qe");
+ if (!np)
+ return -ENODEV;
+
+ sysclk = *(u32 *)of_get_property(np, "bus-frequency", NULL);
+
+ for (np = NULL, i = 1;
+ (np = of_find_compatible_node(np, "spi", "fsl_spi")) != NULL;
+ i++) {
+ int ret = 0;
+ unsigned int j;
+ const char *mode;
+ struct resource res[2];
+ struct platform_device *pdev = NULL;
+ struct fsl_spi_platform_data pdata = {
+ .activate_cs = activate_cs,
+ .deactivate_cs = deactivate_cs,
+ };
+
+ memset(res, 0, sizeof(res));
+
+ mode = of_get_property(np, "mode", NULL);
+ pdata.sysclk = sysclk;
+ pdata.bus_num = *(u32 *)of_get_property(np, "reg", NULL);
+
+ for (j = 0; j < num_board_infos; j++) {
+ if (board_infos[j].bus_num == pdata.bus_num)
+ pdata.max_chipselect++;
+ }
+
+ if (!pdata.max_chipselect)
+ goto err;
+
+ if (!strcmp(mode, "cpu-qe"))
+ pdata.qe_mode = 1;
+
+ ret = of_address_to_resource(np, 0, &res[0]);
+ if (ret)
+ goto err;
+
+ res[1].start = res[2].end = irq_of_parse_and_map(np, 0);
+ if (res[1].start == NO_IRQ)
+ goto err;
+
+ res[1].name = "mpc83xx_spi";
+ res[1].flags = IORESOURCE_IRQ;;
+
+ pdev = platform_device_alloc("mpc83xx_spi", i);
+ if (!pdev)
+ goto err;
+
+ ret = platform_device_add_data(pdev, &pdata, sizeof(pdata));
+ if (ret)
+ goto unreg;
+
+ ret = platform_device_add_resources(pdev, res,
+ ARRAY_SIZE(res));
+ if (ret)
+ goto unreg;
+
+ ret = platform_device_register(pdev);
+ if (ret)
+ goto unreg;
+
+ continue;
+unreg:
+ platform_device_del(pdev);
+err:
+ continue;
+ }
+
+ return spi_register_board_info(board_infos, num_board_infos);
+}
diff --git a/arch/powerpc/sysdev/fsl_soc.h b/arch/powerpc/sysdev/fsl_soc.h
index 04e145b..618d91d 100644
--- a/arch/powerpc/sysdev/fsl_soc.h
+++ b/arch/powerpc/sysdev/fsl_soc.h
@@ -8,5 +8,12 @@ extern phys_addr_t get_immrbase(void);
extern u32 get_brgfreq(void);
extern u32 get_baudrate(void);
+struct spi_board_info;
+
+extern int fsl_spi_init(struct spi_board_info *board_infos,
+ unsigned int num_board_infos,
+ void (*activate_cs)(u8 cs, u8 polarity),
+ void (*deactivate_cs)(u8 cs, u8 polarity));
+
#endif
#endif
--
1.5.0.6
^ permalink raw reply related
* [PATCH v5 2/2] [POWERPC] MPC832x_RDB: update dts to use SPI1 in QE, register mmc_spi stub
From: Anton Vorontsov @ 2007-08-21 15:29 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <20070821152745.GA28986@localhost.localdomain>
mmc_spi already tested to work. When it will hit mainline
the only change that will be needed is replacing "spidev"
with "mmc_spi".
Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
---
arch/powerpc/boot/dts/mpc832x_rdb.dts | 2 +-
arch/powerpc/platforms/83xx/mpc832x_rdb.c | 50 +++++++++++++++++++++++++++++
2 files changed, 51 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/boot/dts/mpc832x_rdb.dts b/arch/powerpc/boot/dts/mpc832x_rdb.dts
index e9c332f..1ac0025 100644
--- a/arch/powerpc/boot/dts/mpc832x_rdb.dts
+++ b/arch/powerpc/boot/dts/mpc832x_rdb.dts
@@ -211,7 +211,7 @@
reg = <4c0 40>;
interrupts = <2>;
interrupt-parent = <&qeic>;
- mode = "cpu";
+ mode = "cpu-qe";
};
spi@500 {
diff --git a/arch/powerpc/platforms/83xx/mpc832x_rdb.c b/arch/powerpc/platforms/83xx/mpc832x_rdb.c
index e021b08..cf58d06 100644
--- a/arch/powerpc/platforms/83xx/mpc832x_rdb.c
+++ b/arch/powerpc/platforms/83xx/mpc832x_rdb.c
@@ -15,6 +15,7 @@
*/
#include <linux/pci.h>
+#include <linux/spi/spi.h>
#include <asm/of_platform.h>
#include <asm/time.h>
@@ -24,6 +25,7 @@
#include <asm/qe_ic.h>
#include "mpc83xx.h"
+#include "../../sysdev/fsl_soc.h"
#undef DEBUG
#ifdef DEBUG
@@ -32,6 +34,54 @@
#define DBG(fmt...)
#endif
+extern int par_io_data_set(u8 port, u8 pin, u8 val);
+extern int par_io_config_pin(u8 port, u8 pin, int dir, int open_drain,
+ int assignment, int has_irq);
+
+static void mpc83xx_spi_activate_cs(u8 cs, u8 polarity)
+{
+ pr_debug("%s %d %d\n", __func__, cs, polarity);
+ par_io_data_set(3, 13, polarity);
+}
+
+static void mpc83xx_spi_deactivate_cs(u8 cs, u8 polarity)
+{
+ pr_debug("%s %d %d\n", __func__, cs, polarity);
+ par_io_data_set(3, 13, !polarity);
+}
+
+static struct spi_board_info mpc832x_spi_boardinfo = {
+ .bus_num = 0x4c0,
+ .chip_select = 0,
+ .max_speed_hz = 50000000,
+ /*
+ * XXX: This is spidev (spi in userspace) stub, should
+ * be replaced by "mmc_spi" when mmc_spi will hit mainline.
+ */
+ .modalias = "spidev",
+};
+
+static int __init mpc832x_spi_init(void)
+{
+ if (!machine_is(mpc832x_rdb))
+ return 0;
+
+ par_io_config_pin(3, 0, 3, 0, 1, 0); /* SPI1 MOSI, I/O */
+ par_io_config_pin(3, 1, 3, 0, 1, 0); /* SPI1 MISO, I/O */
+ par_io_config_pin(3, 2, 3, 0, 1, 0); /* SPI1 CLK, I/O */
+ par_io_config_pin(3, 3, 2, 0, 1, 0); /* SPI1 SEL, I */
+
+ par_io_config_pin(3, 13, 1, 0, 0, 0); /* !SD_CS, O */
+ par_io_config_pin(3, 14, 2, 0, 0, 0); /* SD_INSERT, I */
+ par_io_config_pin(3, 15, 2, 0, 0, 0); /* SD_PROTECT,I */
+
+ return fsl_spi_init(&mpc832x_spi_boardinfo, 1,
+ mpc83xx_spi_activate_cs,
+ mpc83xx_spi_deactivate_cs);
+}
+
+device_initcall(mpc832x_spi_init);
+
/* ************************************************************************
*
* Setup the architecture
--
1.5.0.6
^ permalink raw reply related
* Re: [PATCH 05/20] bootwrapper: flatdevtree fixes
From: Scott Wood @ 2007-08-21 16:09 UTC (permalink / raw)
To: David Gibson; +Cc: linuxppc-dev, paulus
In-Reply-To: <20070821023044.GF15469@localhost.localdomain>
David Gibson wrote:
> On Mon, Aug 20, 2007 at 12:39:49PM -0500, Scott Wood wrote:
>
>>1. ft_create_node was returning the internal pointer rather than a phandle.
>>2. ft_find_device_rel was treating a "top" phandle of NULL as an error,
>>rather than as the root of the tree.
>>3. Return the node's name when getprop() is called with the "name"
>>property.
>
>
> Hrm. I'm not convinced. (1) certainly needs fixing. (2) is kind of
> unclear - there is an ft_find_device() after all for doing root-based
> searches.
The point of #2 was as part of the fix to #1 -- otherwise, the same
check for NULL would have to be moved into ft_create_node to
conditionally call ft_find_device or ft_find_device_rel.
The non-relative function should probably be removed, though.
> (3) I really dislike; I just don't see the point.
It's needed by dt_get_path().
-Scott
^ permalink raw reply
* Re: Patches for ppc?
From: Phil Terry @ 2007-08-21 16:11 UTC (permalink / raw)
To: segher; +Cc: Linuxppc-dev, David Woodhouse, David Gibson
In-Reply-To: <ae3d7296a5c3e83f19817a04841d099f@kernel.crashing.org>
On Tue, 2007-08-21 at 17:14 +0200, Segher Boessenkool wrote:
> > It's not a question of indivudual files being copied over - things are
> > done differently in arch/powerpc. Things are gradually being ported
> > over to arch/powerpc as people get the time - that's why arch/ppc
> > isn't gone yet.
>
> And to be blunt, one of the points of arch/powerpc vs. arch/ppc is
> to actually leave behind some stuff. "If no one ports it, no one
> wants it".
So am I alone in getting a mixed message from "Linux community" to
"embedded community"?
On the one hand we have people like GKH telling embedded people to stop
being private company/device specific forks but to submit their hardware
to the tree where it will be supported "for free" by the kernel hackers,
saving us the "chore" of supporting "our" code through all the kernel
changes and forever chasing it.
On the other hand we have people telling us that because we are too lazy
to support "our" code the kernel guys aren't going to pull it forward
for us.
So in fact people 3rd party people like me are in between real problems,
we base our code on say a Freescale chip, who submit to the kernel to
save their support issues and we base our code on that. Now, the
Freescale guys are too busy porting their "latest" chips across the
PPC/Powerpc divide to port the "old" stuff so it gets "left behind".
That old stuff is still selling and the people who based code on it had
the expectation that the code would continue to be supported. So now I'm
being told not only to "port my stuff or lose it" but now also port
freescale's stuff or lose it.
And then we get beaten up because we "stayed" with "ancient stuff" like
2.6.21!!!
Not picking on Freescale, or Segher, just trying to wave the flag, lots
of people want it, they are just not all in a position to save it
because we "embedded" people are by nature a fractured community of
niche players with products that don't turn over with out customers
every six months, some people will want to buy a product for years...
And yes I do understand the "Linux kernel hackers are nothing more than
a group of diverse people from many companies so why is embedded any
different" argument, I just don't have an answer right now other than it
is.
Cheers
Phil
>
>
> Segher
>
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
>
>
^ permalink raw reply
* Re: [PATCH 09/20] bootwrapper: Declare udelay() in ops.h.
From: Scott Wood @ 2007-08-21 16:12 UTC (permalink / raw)
To: David Gibson; +Cc: linuxppc-dev, paulus
In-Reply-To: <20070821023943.GI15469@localhost.localdomain>
David Gibson wrote:
> On Mon, Aug 20, 2007 at 12:39:55PM -0500, Scott Wood wrote:
>
>>Declarations in various users are removed.
>>
>>Signed-off-by: Scott Wood <scottwood@freescale.com>
>
>
> Hrm... it should go in a header, certainly, but I wonder if io.h would
> be more suitable than the already rather bloated ops.h.
It's not really I/O either... Maybe we should make a misc.h to put
stuff in that doesn't fit anywhere else and doesn't really warrant its
own header file?
-Scott
^ permalink raw reply
* Re: [PATCH 10/20] bootwrapper: Add CPM serial driver.
From: Scott Wood @ 2007-08-21 16:15 UTC (permalink / raw)
To: David Gibson; +Cc: linuxppc-dev, paulus
In-Reply-To: <20070821024200.GJ15469@localhost.localdomain>
David Gibson wrote:
>>diff --git a/arch/powerpc/boot/serial.c b/arch/powerpc/boot/serial.c
>>index 944f0ee..d47f8e0 100644
>>--- a/arch/powerpc/boot/serial.c
>>+++ b/arch/powerpc/boot/serial.c
>>@@ -121,6 +121,11 @@ int serial_console_init(void)
>> rc = ns16550_console_init(devp, &serial_cd);
>> else if (dt_is_compatible(devp, "marvell,mpsc"))
>> rc = mpsc_console_init(devp, &serial_cd);
>>+ else if (dt_is_compatible(devp, "fsl,cpm1-scc-uart") ||
>>+ dt_is_compatible(devp, "fsl,cpm1-smc-uart") ||
>>+ dt_is_compatible(devp, "fsl,cpm2-scc-uart") ||
>>+ dt_is_compatible(devp, "fsl,cpm2-smc-uart"))
>>+ rc = cpm_console_init(devp, &serial_cd);
>
>
> If all these variants admit a compatible driver, there really should
> be defined a compatible value that they all include in the device
> tree.
That's what I did last time, and several people complained. :-)
The issue was that while there is a lot in common between these
variants, there's no one common subset that can be used to drive the
device without knowledge of what variant it is (or knowledge of where
the firmware placed the descriptors).
> But I guess you'd still need all these tests for device trees
> which didn't have it.
Nah, this is a new binding.
-Scott
^ permalink raw reply
* Re: [PATCH 12/20] bootwrapper: Add 8xx cuboot support.
From: Scott Wood @ 2007-08-21 16:20 UTC (permalink / raw)
To: David Gibson; +Cc: linuxppc-dev, paulus
In-Reply-To: <20070821024432.GL15469@localhost.localdomain>
David Gibson wrote:
> On Mon, Aug 20, 2007 at 12:40:01PM -0500, Scott Wood wrote:
>
>>This allows booting on legacy, non-device-tree aware versions of
>>U-boot.
>
>
> Is this really sufficient for all 8xx platforms?
It should be enough for all u-boot-based 8xx boards, barring some u-boot
which needs special fixups (as is done in cuboot-pq2.c). If such a need
arises, they can be added to cuboot-8xx.c (if they're generic enough to
work on all boards, even if not actually needed) or to a board-specific
platform file (which can coexist just fine with the generic 8xx one).
-Scott
^ permalink raw reply
* Re: [PATCH 14/20] bootwrapper: Add strtoull().
From: Scott Wood @ 2007-08-21 16:20 UTC (permalink / raw)
To: David Gibson; +Cc: linuxppc-dev, paulus
In-Reply-To: <20070821024713.GM15469@localhost.localdomain>
David Gibson wrote:
>>+/* Not currently supported: leading whitespace, sign, 0x prefix, zero base */
>>+unsigned long long int strtoull(const char *ptr, char **end, int base)
>>+{
>>+ unsigned long long ret = 0;
>>+
>>+ while (*ptr) {
>>+ int digit;
>>+
>>+ if (*ptr >= '0' && *ptr <= '9')
>>+ digit = *ptr - '0';
>>+ else if (*ptr >= 'A' && *ptr <= 'Z')
>>+ digit = *ptr - 'A' + 10;
>>+ else if (*ptr >= 'a' && *ptr <= 'z')
>>+ digit = *ptr - 'a' + 10;
>>+ else
>>+ break;
>
>
> Hrm... I note this has no sort of error checking if the string has
> digits which don't fit in the given base.
Oops. I'll fix that.
-Scott
^ permalink raw reply
* Re: [PATCH 17/20] bootwrapper: Add PlanetCore firmware support.
From: Scott Wood @ 2007-08-21 16:29 UTC (permalink / raw)
To: David Gibson; +Cc: linuxppc-dev, paulus
In-Reply-To: <20070821031658.GQ15469@localhost.localdomain>
David Gibson wrote:
>>+void planetcore_prepare_table(char *table)
>>+{
>>+ int last_was_newline = 0;
>>+
>>+ while (*table != 10 || !last_was_newline) {
>>+ if (*table == 10) {
>>+ *table = 0;
>>+ last_was_newline = 1;
>>+ } else {
>>+ last_was_newline = 0;
>>+ }
>>+
>>+ table++;
>>+ }
>
>
> Hrm.. this loop makes my brain hurt. It's correct as far as I can
> determine what it's supposed to be doing, but I think there's got to
> be a way to make what it's doing a little more obvious.
How about something like this:
char last = 0;
while (1) {
if (*table == '\n') {
*table = 0;
if (last == *table)
return;
}
last = *table++;
}
-Scott
^ permalink raw reply
* Re: [PATCH 20/20] bootwrapper: Add fsl_get_immr(), mpc885_get_clock(), and pq2_get_clocks().
From: Scott Wood @ 2007-08-21 16:34 UTC (permalink / raw)
To: David Gibson; +Cc: linuxppc-dev, paulus
In-Reply-To: <20070821032546.GS15469@localhost.localdomain>
David Gibson wrote:
> On Mon, Aug 20, 2007 at 12:40:13PM -0500, Scott Wood wrote:
>
>>fsl_get_immr() is equivalent to the kernel's get_immrbase() function.
>
> I notice that this function assumes that P==V. Is that true for all
> relevant platforms at this point?
Yes. If that ever changes, we'd probably need to add a virtual-immr or
similar.
>>mpc885_get_clock() transforms a crystal frequency into a system frequency
>>according to the PLL register settings.
>>
>>pq2_get_clocks() does the same as the above for the PowerQUICC II,
>>except that it produces several different clocks.
>
> I'd prefer if these functions worked analagously to the
> ibm440gp_fixup_clocks() function in ebony.c and fixed up the clock
> values in the device tree directly, rather than returning them (where
> the caller will presumably poke them into the device tree).
I wanted to separate the register interpretation from the knowledge of
where things are in the device tree.
-Scott
^ permalink raw reply
* Re: Patches for ppc?
From: Josh Boyer @ 2007-08-21 16:35 UTC (permalink / raw)
To: pterry; +Cc: Linuxppc-dev, David Woodhouse, David Gibson
In-Reply-To: <1187712684.13726.32.camel@pterry-fc6.micromemory.com>
On Tue, 21 Aug 2007 09:11:24 -0700
Phil Terry <pterry@micromemory.com> wrote:
> On Tue, 2007-08-21 at 17:14 +0200, Segher Boessenkool wrote:
> > > It's not a question of indivudual files being copied over - things are
> > > done differently in arch/powerpc. Things are gradually being ported
> > > over to arch/powerpc as people get the time - that's why arch/ppc
> > > isn't gone yet.
> >
> > And to be blunt, one of the points of arch/powerpc vs. arch/ppc is
> > to actually leave behind some stuff. "If no one ports it, no one
> > wants it".
>
> So am I alone in getting a mixed message from "Linux community" to
> "embedded community"?
I don't think so..
> On the one hand we have people like GKH telling embedded people to stop
> being private company/device specific forks but to submit their hardware
> to the tree where it will be supported "for free" by the kernel hackers,
> saving us the "chore" of supporting "our" code through all the kernel
> changes and forever chasing it.
Yes. Just submit it to the arch/powerpc tree instead of arch/ppc. But
this is only an issue for the _initial_ submit, and only while the
merge is on-going.
> On the other hand we have people telling us that because we are too lazy
> to support "our" code the kernel guys aren't going to pull it forward
> for us.
That's more of a issue for _existing_ code, not new code.
> So in fact people 3rd party people like me are in between real problems,
> we base our code on say a Freescale chip, who submit to the kernel to
> save their support issues and we base our code on that. Now, the
> Freescale guys are too busy porting their "latest" chips across the
> PPC/Powerpc divide to port the "old" stuff so it gets "left behind".
Or maybe it's just not ported yet?
> That old stuff is still selling and the people who based code on it had
> the expectation that the code would continue to be supported. So now I'm
> being told not only to "port my stuff or lose it" but now also port
> freescale's stuff or lose it.
Well... it's not really going away until June 2008. There's time.
josh
^ permalink raw reply
* Re: Patches for ppc?
From: Kumar Gala @ 2007-08-21 16:40 UTC (permalink / raw)
To: pterry; +Cc: Linuxppc-dev, David Woodhouse, David Gibson
In-Reply-To: <1187712684.13726.32.camel@pterry-fc6.micromemory.com>
On Aug 21, 2007, at 11:11 AM, Phil Terry wrote:
> On Tue, 2007-08-21 at 17:14 +0200, Segher Boessenkool wrote:
>>> It's not a question of indivudual files being copied over -
>>> things are
>>> done differently in arch/powerpc. Things are gradually being ported
>>> over to arch/powerpc as people get the time - that's why arch/ppc
>>> isn't gone yet.
>>
>> And to be blunt, one of the points of arch/powerpc vs. arch/ppc is
>> to actually leave behind some stuff. "If no one ports it, no one
>> wants it".
>
> So am I alone in getting a mixed message from "Linux community" to
> "embedded community"?
>
> On the one hand we have people like GKH telling embedded people to
> stop
> being private company/device specific forks but to submit their
> hardware
> to the tree where it will be supported "for free" by the kernel
> hackers,
> saving us the "chore" of supporting "our" code through all the kernel
> changes and forever chasing it.
>
> On the other hand we have people telling us that because we are too
> lazy
> to support "our" code the kernel guys aren't going to pull it forward
> for us.
There is clearly a balance here. While I don't think too many people
are going to disagree with GKH intent, there is a practicality about
it. If no kernel hacker has access to a particular board that was
supported in arch/ppc and no one seems to care about it than it seems
to be a candidate to not move forward.
> So in fact people 3rd party people like me are in between real
> problems,
> we base our code on say a Freescale chip, who submit to the kernel to
> save their support issues and we base our code on that. Now, the
> Freescale guys are too busy porting their "latest" chips across the
> PPC/Powerpc divide to port the "old" stuff so it gets "left behind".
> That old stuff is still selling and the people who based code on it
> had
> the expectation that the code would continue to be supported. So
> now I'm
> being told not only to "port my stuff or lose it" but now also port
> freescale's stuff or lose it.
If there is some specific freescale board/chip that is being left
behind that you're concerned about please let me know.
> And then we get beaten up because we "stayed" with "ancient stuff"
> like
> 2.6.21!!!
>
> Not picking on Freescale, or Segher, just trying to wave the flag,
> lots
> of people want it, they are just not all in a position to save it
> because we "embedded" people are by nature a fractured community of
> niche players with products that don't turn over with out customers
> every six months, some people will want to buy a product for years...
>
> And yes I do understand the "Linux kernel hackers are nothing more
> than
> a group of diverse people from many companies so why is embedded any
> different" argument, I just don't have an answer right now other
> than it
> is.
I'd ask you to mention specific boards/chip/functionality rather than
generic statements so we can actual be aware of things we're
forgetting or are important to people that we are not aware of.
The fact that arch/ppc is 'dead' has been posted on the lists
numerous times to give people the opportunity to let us all know
what's important to people.
- k
^ permalink raw reply
* Re: [PATCH 6/7 v2] fs_enet: Be an of_platform device when CONFIG_PPC_CPM_NEW_BINDING is set.
From: Scott Wood @ 2007-08-21 16:47 UTC (permalink / raw)
To: Vitaly Bordug; +Cc: netdev, jgarzik, linuxppc-dev
In-Reply-To: <20070821130155.43898b68@localhost.localdomain>
Vitaly Bordug wrote:
> On Fri, 17 Aug 2007 13:17:18 -0500
> Scott Wood wrote:
>
>
>>The existing OF glue code was crufty and broken. Rather than fix it,
>>it will be removed, and the ethernet driver now talks to the device
>>tree directly.
>>
>
> A bit short description, I'd rather expect some specific improvements list,
> that are now up and running using device tree. Or if it is just move to new
> infrastucture, let's state that, too.
Some of specific binding changes (there are too many to exhaustively
list) are enumerated in the "new CPM binding" patch, which I'll send
after Kumar's include/asm-ppc patch goes in (since it modifies one of
those files).
>>+#ifdef CONFIG_PPC_CPM_NEW_BINDING
>>+static int __devinit find_phy(struct device_node *np,
>>+ struct fs_platform_info *fpi)
>>+{
>>+ struct device_node *phynode, *mdionode;
>>+ struct resource res;
>>+ int ret = 0, len;
>>+
>>+ const u32 *data = of_get_property(np, "phy-handle", &len);
>>+ if (!data || len != 4)
>>+ return -EINVAL;
>>+
>>+ phynode = of_find_node_by_phandle(*data);
>>+ if (!phynode)
>>+ return -EINVAL;
>>+
>>+ mdionode = of_get_parent(phynode);
>>+ if (!phynode)
>>+ goto out_put_phy;
>>+
>>+ ret = of_address_to_resource(mdionode, 0, &res);
>>+ if (ret)
>>+ goto out_put_mdio;
>>+
>>+ data = of_get_property(phynode, "reg", &len);
>>+ if (!data || len != 4)
>>+ goto out_put_mdio;
>>+
>>+ snprintf(fpi->bus_id, 16, PHY_ID_FMT, res.start, *data);
>>+
>>+out_put_mdio:
>>+ of_node_put(mdionode);
>>+out_put_phy:
>>+ of_node_put(phynode);
>>+ return ret;
>>+}
>
> And without phy node?
It returns -EINVAL. :-)
>>+#ifdef CONFIG_FS_ENET_HAS_FEC
>>+#define IS_FEC(match) ((match)->data == &fs_fec_ops)
>>+#else
>>+#define IS_FEC(match) 0
>>+#endif
>>+
>
> Since we're talking directly with device tree, why bother with CONFIG_ stuff? We are able to figure it out from dts..
We are figuring it out from the DTS (that's what match->data is). I
just didn't want boards without a FEC to have to build in support for it
and waste memory.
>>+ fpi->rx_ring = 32;
>>+ fpi->tx_ring = 32;
>>+ fpi->rx_copybreak = 240;
>>+ fpi->use_napi = 0;
>>+ fpi->napi_weight = 17;
>>+
>
>
> move params over to dts?
No. These aren't attributes of the hardware, they're choices the driver
makes about how much memory to use and how to interact with the rest of
the kernel.
>>+ ret = find_phy(ofdev->node, fpi);
>>+ if (ret)
>>+ goto out_free_fpi;
>>+
>
> so we're hosed without phy node.
How is that different from the old code, where you're hosed without
fep->fpi->bus_id?
>>+static struct of_device_id fs_enet_match[] = {
>>+#ifdef CONFIG_FS_ENET_HAS_SCC
>
>
> same nagging. Are we able to get rid of Kconfig arcane defining which SoC currently plays the game for fs_enet?
No, it's still needed for mpc885ads to determine pin setup and
conflicting device tree node removal (though that could go away if the
device tree is changed to reflect the jumper settings).
It's also useful for excluding unwanted code. I don't like using
8xx/CPM2 as the decision point for that -- why should I build in
mac-scc.c if I have no intention of using an SCC ethernet (either
because my board doesn't have one, or because it's slow and conflicts
with other devices)?
-Scott
^ permalink raw reply
* Re: Patches for ppc?
From: Phil Terry @ 2007-08-21 17:12 UTC (permalink / raw)
To: galak; +Cc: Linuxppc-dev, David Woodhouse, David Gibson
In-Reply-To: <116C1903-CE42-4066-8524-F9216003BE9A@kernel.crashing.org>
Ooops,
Sorry guys, this is probably the wrong forum and I didn't mean to sound
like I was trashing anyones efforts here.
As I said, I'm not picking on Freescale or anyone else on this list. I'm
just trying to understand this process as an embedded developer who
works at companies which use code bases provided by other 3rd parties.
I understand its an ongoing process, change is the only constant. So I
try not to whine that my particular board/chip/issue isn't fixed in the
latest kernel, patch, support package and I try to patch things up and
make progress on *my* project by pulling bits and pieces together
hoping that my stuff will eventually get fixed.
But then I see comments from other people who I assume are in the same
boat and the response is, "no one uses that. Theres no demand for it.
We're dropping that" Its like when I go to a pub in England and ask for
a pint of "mild" ale. "We don't serve that here, there's no demand for
it." Huh, didn't I just demand it? So then I get worried, how do I know
who's plan and schedule include/excludes my board/chip/issue?
I was trying to raise that generic issue, which is why I tried to be
generic. Didn't mean to gore anyones ox.
Cheers
Phil (who now has to drink American Beer.....)
On Tue, 2007-08-21 at 11:40 -0500, Kumar Gala wrote:
> On Aug 21, 2007, at 11:11 AM, Phil Terry wrote:
>
> > On Tue, 2007-08-21 at 17:14 +0200, Segher Boessenkool wrote:
> >>> It's not a question of indivudual files being copied over -
> >>> things are
> >>> done differently in arch/powerpc. Things are gradually being ported
> >>> over to arch/powerpc as people get the time - that's why arch/ppc
> >>> isn't gone yet.
> >>
> >> And to be blunt, one of the points of arch/powerpc vs. arch/ppc is
> >> to actually leave behind some stuff. "If no one ports it, no one
> >> wants it".
> >
> > So am I alone in getting a mixed message from "Linux community" to
> > "embedded community"?
> >
> > On the one hand we have people like GKH telling embedded people to
> > stop
> > being private company/device specific forks but to submit their
> > hardware
> > to the tree where it will be supported "for free" by the kernel
> > hackers,
> > saving us the "chore" of supporting "our" code through all the kernel
> > changes and forever chasing it.
> >
> > On the other hand we have people telling us that because we are too
> > lazy
> > to support "our" code the kernel guys aren't going to pull it forward
> > for us.
>
> There is clearly a balance here. While I don't think too many people
> are going to disagree with GKH intent, there is a practicality about
> it. If no kernel hacker has access to a particular board that was
> supported in arch/ppc and no one seems to care about it than it seems
> to be a candidate to not move forward.
>
> > So in fact people 3rd party people like me are in between real
> > problems,
> > we base our code on say a Freescale chip, who submit to the kernel to
> > save their support issues and we base our code on that. Now, the
> > Freescale guys are too busy porting their "latest" chips across the
> > PPC/Powerpc divide to port the "old" stuff so it gets "left behind".
> > That old stuff is still selling and the people who based code on it
> > had
> > the expectation that the code would continue to be supported. So
> > now I'm
> > being told not only to "port my stuff or lose it" but now also port
> > freescale's stuff or lose it.
>
> If there is some specific freescale board/chip that is being left
> behind that you're concerned about please let me know.
>
> > And then we get beaten up because we "stayed" with "ancient stuff"
> > like
> > 2.6.21!!!
> >
> > Not picking on Freescale, or Segher, just trying to wave the flag,
> > lots
> > of people want it, they are just not all in a position to save it
> > because we "embedded" people are by nature a fractured community of
> > niche players with products that don't turn over with out customers
> > every six months, some people will want to buy a product for years...
> >
> > And yes I do understand the "Linux kernel hackers are nothing more
> > than
> > a group of diverse people from many companies so why is embedded any
> > different" argument, I just don't have an answer right now other
> > than it
> > is.
>
> I'd ask you to mention specific boards/chip/functionality rather than
> generic statements so we can actual be aware of things we're
> forgetting or are important to people that we are not aware of.
>
> The fact that arch/ppc is 'dead' has been posted on the lists
> numerous times to give people the opportunity to let us all know
> what's important to people.
>
> - k
>
>
^ permalink raw reply
* Re: Patches for ppc?
From: Linas Vepstas @ 2007-08-21 17:22 UTC (permalink / raw)
To: Phil Terry; +Cc: Linuxppc-dev, David Woodhouse, David Gibson
In-Reply-To: <1187712684.13726.32.camel@pterry-fc6.micromemory.com>
On Tue, Aug 21, 2007 at 09:11:24AM -0700, Phil Terry wrote:
> On Tue, 2007-08-21 at 17:14 +0200, Segher Boessenkool wrote:
> > > It's not a question of indivudual files being copied over - things are
> > > done differently in arch/powerpc. Things are gradually being ported
> > > over to arch/powerpc as people get the time - that's why arch/ppc
> > > isn't gone yet.
> >
> > And to be blunt, one of the points of arch/powerpc vs. arch/ppc is
> > to actually leave behind some stuff. "If no one ports it, no one
> > wants it".
>
> So am I alone in getting a mixed message from "Linux community" to
> "embedded community"?
>
> On the one hand we have people like GKH telling embedded people to stop
> being private company/device specific forks but to submit their hardware
> to the tree where it will be supported "for free" by the kernel hackers,
> saving us the "chore" of supporting "our" code through all the kernel
> changes and forever chasing it.
>
> On the other hand we have people telling us that because we are too lazy
> to support "our" code the kernel guys aren't going to pull it forward
> for us.
You've got to keep things in perspective. Some devices do get old and
stale, and no one ever uses them any more. These devices do disappear
from the kernel tree over time. Its not unreasonable to have a "sunset"
policy for old stuff. Some devices continue to have an active, interested
community that helps maintain them.
Some kernel changes are big, and some are small. Sometimes big changes
are so big that they can't be done without having everybody pitch in
and help out. The transition from ppc to powerpc is like that. To
cross over such humps, its not just a matter of laziness -- I have
enough work to keep ten of me occupied -- but its also access to
equipment: someone needs to verify that old hardware still works
with the new changes. Embedded is particularly dicey: there are so
many platforms, most developers will never have seen the one in question.
> So in fact people 3rd party people like me are in between real problems,
> we base our code on say a Freescale chip, who submit to the kernel to
> save their support issues and we base our code on that. Now, the
> Freescale guys are too busy porting their "latest" chips across the
> PPC/Powerpc divide to port the "old" stuff so it gets "left behind".
> That old stuff is still selling and the people who based code on it had
> the expectation that the code would continue to be supported.
For example, Redhat RHEL 4 is based on the 2.6.9 kernel, and god
help me I'm *still* posting patches and fixes to that, although
its a rather unpleasent task. There's a real economic motivation
to do this --- and its called "support". Someone out there cares
enough to want this old stuff to work across a whole range of h/w.
> So now I'm
> being told not only to "port my stuff or lose it" but now also port
> freescale's stuff or lose it.
>
> And then we get beaten up because we "stayed" with "ancient stuff" like
> 2.6.21!!!
You get beaten up if you are trying to get new stuff to work on old
code bases -- for good reason.
> Not picking on Freescale, or Segher, just trying to wave the flag, lots
> of people want it, they are just not all in a position to save it
> because we "embedded" people are by nature a fractured community of
> niche players with products that don't turn over with out customers
> every six months, some people will want to buy a product for years...
RHEL 4 is several years old, and it will be around for years more,
and its based on the 2.6.9 kernel, and, if it works for your customers,
they should use that. Once you've got a working software installation,
don't upgrade it! Upgrades do break things, so if it works, don't mess
with it.
But if you are building a new product, and adding new features, then
it does not make sense to try to do that to an old kernel. And, yes,
there's a non-trivial effort to stay current and surf the cutting edge.
And, yes, there can be dangerous rip-tides, like the ppc->powerpc
migration, that can catch ahold of you.
--linas
^ permalink raw reply
* [2.6 patch] ppc .gitignore update
From: Adrian Bunk @ 2007-08-21 16:57 UTC (permalink / raw)
To: Andrew Morton, Paul Mackerras; +Cc: linuxppc-dev, linux-kernel
From: Grant Likely <grant.likely@secretlab.ca>
arch/ppc/.gitignore shouldn't exclude arch/ppc/boot/include
Signed-off-by: Adrian Bunk <bunk@kernel.org>
---
--- a/arch/ppc/.gitignore
+++ b/arch/ppc/.gitignore
@@ -1 +1 @@
-include
+/include
^ permalink raw reply
* Re: Patches for ppc?
From: Scott Wood @ 2007-08-21 17:30 UTC (permalink / raw)
To: Phil Terry; +Cc: Linuxppc-dev, David Woodhouse, David Gibson
In-Reply-To: <1187716337.13726.48.camel@pterry-fc6.micromemory.com>
On Tue, Aug 21, 2007 at 10:12:17AM -0700, Phil Terry wrote:
> Sorry guys, this is probably the wrong forum and I didn't mean to sound
> like I was trashing anyones efforts here.
I don't think it was taken that way -- rather, we want to know what
hardware people are still using with recent kernels. Greg KH's "offer"
was a bit over-idealistic; hacker-hours are a finite resource, and
there's not much point spending it on hardware which is primarily
installed in landfills. :-)
The offer seems to be founded on the assumption that the user base of a
given device among kernel hackers is proportional to the user base in the
general population, which is less likely to be true with embedded
hardware. Thus, we need feedback on which hardware is being actively
developed on.
> But then I see comments from other people who I assume are in the same
> boat and the response is, "no one uses that. Theres no demand for it.
> We're dropping that" Its like when I go to a pub in England and ask for
> a pint of "mild" ale. "We don't serve that here, there's no demand for
> it." Huh, didn't I just demand it?
Yes, and if they found themselves repeating that answer on a regular
basis, they might decide to add a tap. Again, non-finite resources. :-)
> So then I get worried, how do I know who's plan and schedule
> include/excludes my board/chip/issue?
You ask.
> Cheers
> Phil (who now has to drink American Beer.....)
Mmm... beer...
I just *hate* it when I have to drink a nice Rogue, Stone, Breckenridge,
Victory, etc. :-)
-Scott
^ permalink raw reply
* Re: Patches for ppc?
From: Segher Boessenkool @ 2007-08-21 18:09 UTC (permalink / raw)
To: pterry; +Cc: Linuxppc-dev, David Woodhouse, David Gibson
In-Reply-To: <1187716337.13726.48.camel@pterry-fc6.micromemory.com>
> So then I get worried, how do I know
> who's plan and schedule include/excludes my board/chip/issue?
The arch/ppc -> arch/powerpc changeover is exceptional for various
reasons.
First, it is a huge change taking multiple years to complete.
Only recently it has been decided when to finally drop arch/ppc
completely; and that's not going to happen until almost a year
from now.
Secondly, it really does change many things at the core. It
is almost impossible for people without in-depth knowledge of
specific hardware too correctly port support code for that
hardware over those core changes, and certainly impossible to
actually test the ported code. So the only sane approach was
to only port the hardware support code people _did_ have access
to. Which isn't to say the other platforms still "in demand"
will be left behind of course, some are still being ported over,
and there is nothing preventing such a port even after arch/ppc
is dead and gone either.
Thirdly, Greg KH is talking more about generic drivers (PCI
device drivers, for example) than about low-level platform code;
at least that's my impression. The good news is that in the
arch/powerpc world much more of the low-level stuff will be
abstracted away, or at least sanely abstracted at all, so in
the future we won't have all that many problems making even
the biggest core changes anymore.
> I was trying to raise that generic issue, which is why I tried to be
> generic. Didn't mean to gore anyones ox.
Don't worry, you didn't offend anyone as far as I can see :-)
All of the "more generic" stuff (e.g., CPU/SoC support) should
be ported over soon enough (if not, shout); some more specific
stuff (support for some specific board, etc.) you will have to
do yourself, or find someone else to do it for you. And you can
always ask for help here, we're all very helpful and friendly
here (if you believe that ;-) )
Segher
^ permalink raw reply
* C67x00 Driver IRQ Problem.
From: Robertson, Joseph M. @ 2007-08-21 18:57 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 4968 bytes --]
Hi all.
I got the driver registered and have spent some time tracking down a IRQ problem.
It just ignores me when it gets to 'request_irq' with a 'nobody cared' response.
The memory appears right and the test IRQ of 3 is supposed to be correct.
I never see the HCD driver load up, does that have to startup first?
I tried also waking the c67300 chip by writing a Interrupt Enable Reg (0xC00E) a value to enable the ints.
Do I need a /dev/usb device tree of some kind? I have a fixed dev tree since we are a embedded sys.
I added some printk messages to help us out...
Any helpful info would be much appreciated.
Kernel code is 2.6.17.3, much hacked and maligned by me.
I made a module of the c67x00, heres the load results.
Load Results -----
c67x00 init.<6>bus platform: add driver c67x00
before kset = bus->drivers.
c67x00 drv probing...
c67x00 drv get mem resource.
platform_get_resource, num resources=2.
dev->resource[0]=512
c67x00 drv get irq resource.
platform_get_resource, num resources=2.
dev->resource[0]=512
dev->resource[1]=1024
c67x00 drv get platform data.
c67x00 drv setup sies.
c67x00 c67x00.0: USB OTG controller, p:0x43e00000, v:0xc5058000, irq:3
irq 3: nobody cared (try booting with the "irqpoll" option)
Call Trace:
[C0F0FA50] [C0009BC0] show_stack+0x44/0x194 (unreliable)
[C0F0FA90] [C004A118] __report_bad_irq+0x34/0xac
[C0F0FAB0] [C004A268] note_interrupt+0xbc/0x13c
[C0F0FAE0] [C00498E8] __do_IRQ+0x1a8/0x1c0
[C0F0FB10] [C0007360] do_IRQ+0x48/0x78
[C0F0FB30] [C00033FC] ret_from_except+0x0/0x18
[C0F0FBF0] [C0F0FC90] 0xc0f0fc90
[C0F0FC20] [C00073F4] do_softirq+0x64/0x74
[C0F0FC40] [C0028358] irq_exit+0x60/0x64
[C0F0FC60] [C0007364] do_IRQ+0x4c/0x78
[C0F0FC80] [C00033FC] ret_from_except+0x0/0x18
[C0F0FD40] [C5058000] 0xc5058000
[C0F0FD70] [C0049EC0] request_irq+0x94/0xc8
[C0F0FDA0] [C50715B4] usb_c67x00_drv_probe+0x240/0x2f4 [c67x00]
[C0F0FDF0] [C0142124] platform_drv_probe+0x20/0x30
[C0F0FE00] [C013FA58] driver_probe_device+0x7c/0x110
[C0F0FE20] [C013EE70] bus_for_each_drv+0x74/0xa4
[C0F0FE60] [C013FB98] device_attach+0xa8/0xb8
[C0F0FE80] [C013F004] bus_add_device+0x34/0xa0
[C0F0FEA0] [C013D900] device_add+0x128/0x188
[C0F0FED0] [C0141EDC] platform_device_add+0xd4/0x194
[C0F0FF00] [C502D074] c67x00_init+0x74/0x118 [c67x00]
[C0F0FF20] [C00433A8] sys_init_module+0x188/0x240
[C0F0FF40] [C0002DB4] ret_from_syscall+0x0/0x3c
handlers:
[<c5071220>] (c67x00_irq+0x0/0x154 [c67x00])
Disabling IRQ #3
Badness in ll_recv_msg at drivers/usb/c67x00/c67x00-ll-hpi.c:246
Call Trace:
[C0F0FC50] [C0009BC0] show_stack+0x44/0x194 (unreliable)
[C0F0FC90] [C0003F64] check_bug_trap+0x84/0xac
[C0F0FCA0] [C0004130] program_check_exception+0x1a4/0x1f8
[C0F0FCC0] [C00033B0] ret_from_except_full+0x0/0x4c
[C0F0FD80] [C5072A6C] c67x00_ll_reset+0x84/0xe0 [c67x00]
[C0F0FDA0] [C50715FC] usb_c67x00_drv_probe+0x288/0x2f4 [c67x00]
[C0F0FDF0] [C0142124] platform_drv_probe+0x20/0x30
[C0F0FE00] [C013FA58] driver_probe_device+0x7c/0x110
[C0F0FE20] [C013EE70] bus_for_each_drv+0x74/0xa4
[C0F0FE60] [C013FB98] device_attach+0xa8/0xb8
[C0F0FE80] [C013F004] bus_add_device+0x34/0xa0
[C0F0FEA0] [C013D900] device_add+0x128/0x188
[C0F0FED0] [C0141EDC] platform_device_add+0xd4/0x194
[C0F0FF00] [C502D074] c67x00_init+0x74/0x118 [c67x00]
[C0F0FF20] [C00433A8] sys_init_module+0x188/0x240
[C0F0FF40] [C0002DB4] ret_from_syscall+0x0/0x3c
c67x00 c67x00.0: Device reset failed
c67x00: probe of c67x00.0 failed with error 65531
c67x00 udc init.
ECAU-9999:#
End Load Results -----
Memory Check-----
ECAU-9999:# cat /proc/iomem
40401003-40401022 : serial
40421003-40421022 : serial
43e00000-43e0000f : c67x00.0
End Memory CHeck------
Many Thanks,
Joe Robertson
Joseph.Robertson@sanmina-sci.com
CONFIDENTIALITY
This e-mail message and any attachments thereto, is intended only for use by the addressee(s) named herein and may contain legally privileged and/or confidential information. If you are not the intended recipient of this e-mail message, you are hereby notified that any dissemination, distribution or copying of this e-mail message, and any attachments thereto, is strictly prohibited. If you have received this e-mail message in error, please immediately notify the sender and permanently delete the original and any copies of this email and any prints thereof.
ABSENT AN EXPRESS STATEMENT TO THE CONTRARY HEREINABOVE, THIS E-MAIL IS NOT INTENDED AS A SUBSTITUTE FOR A WRITING. Notwithstanding the Uniform Electronic Transactions Act or the applicability of any other law of similar substance and effect, absent an express statement to the contrary hereinabove, this e-mail message its contents, and any attachments hereto are not intended to represent an offer or acceptance to enter into a contract and are not otherwise intended to bind the sender, Sanmina-SCI Corporation (or any of its subsidiaries), or any other person or entity.
[-- Attachment #2: Type: text/html, Size: 5794 bytes --]
^ permalink raw reply
* Re: [patch 1/2] powerpc: rmb fix
From: Joel Schopp @ 2007-08-21 19:07 UTC (permalink / raw)
To: Nick Piggin; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <20070821021143.GB2909@wotan.suse.de>
> #define mb() __asm__ __volatile__ ("sync" : : : "memory")
> -#define rmb() __asm__ __volatile__ (__stringify(LWSYNC) : : : "memory")
> +#define rmb() __asm__ __volatile__ ("sync" : : : "memory")
> #define wmb() __asm__ __volatile__ ("sync" : : : "memory")
> #define read_barrier_depends() do { } while(0)
>
> @@ -42,7 +42,7 @@
> #ifdef __KERNEL__
> #ifdef CONFIG_SMP
> #define smp_mb() mb()
> -#define smp_rmb() rmb()
> +#define smp_rmb() __asm__ __volatile__ (__stringify(LWSYNC) : : : "memory")
> #define smp_wmb() eieio()
> #define smp_read_barrier_depends() read_barrier_depends()
> #else
I had to think about this one for awhile. It looks at first glance to be the right
thing to do. But I do wonder how long rmb() has been lwsync and if as a practical
matter that has caused any problems? If this isn't causing any problems maybe there
is some loigic we are overlooking?
^ permalink raw reply
* Re: [patch 1/2] powerpc: rmb fix
From: Segher Boessenkool @ 2007-08-21 19:43 UTC (permalink / raw)
To: Joel Schopp; +Cc: Nick Piggin, linuxppc-dev, Paul Mackerras
In-Reply-To: <46CB37D4.2080609@austin.ibm.com>
>> #define mb() __asm__ __volatile__ ("sync" : : : "memory")
>> -#define rmb() __asm__ __volatile__ (__stringify(LWSYNC) : : :
>> "memory")
>> +#define rmb() __asm__ __volatile__ ("sync" : : : "memory")
>> #define wmb() __asm__ __volatile__ ("sync" : : : "memory")
>> #define read_barrier_depends() do { } while(0)
>>
>> @@ -42,7 +42,7 @@
>> #ifdef __KERNEL__
>> #ifdef CONFIG_SMP
>> #define smp_mb() mb()
>> -#define smp_rmb() rmb()
>> +#define smp_rmb() __asm__ __volatile__ (__stringify(LWSYNC) : : :
>> "memory")
>> #define smp_wmb() eieio()
>> #define smp_read_barrier_depends() read_barrier_depends()
>> #else
>
> I had to think about this one for awhile. It looks at first glance to
> be the right
> thing to do. But I do wonder how long rmb() has been lwsync
Since the {ppc,ppc64} -> powerpc merge.
> and if as a practical matter that has caused any problems?
It has not as far as I know.
> If this isn't causing any problems maybe there
> is some loigic we are overlooking?
The I/O accessor functions enforce the necessary ordering
already I believe.
Segher
^ permalink raw reply
* [PATCH] Check _PAGE_RW and _PAGE_PRESENT on kernel addresses.
From: Scott Wood @ 2007-08-21 21:10 UTC (permalink / raw)
To: paulus; +Cc: linuxppc-dev
Previously, the TLB miss handlers assumed that pages above KERNELBASE are
always present and read/write. This assumption is false in the case of
CONFIG_DEBUG_PAGEALLOC.
Signed-off-by: Scott Wood <scottwood@freescale.com>
---
arch/powerpc/kernel/head_32.S | 12 ++++++------
1 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/arch/powerpc/kernel/head_32.S b/arch/powerpc/kernel/head_32.S
index 7d73a13..2d3b804 100644
--- a/arch/powerpc/kernel/head_32.S
+++ b/arch/powerpc/kernel/head_32.S
@@ -475,10 +475,10 @@ InstructionTLBMiss:
li r1,_PAGE_USER|_PAGE_PRESENT /* low addresses tested as user */
lwz r2,PGDIR(r2)
blt+ 112f
+ mfspr r2,SPRN_SRR1 /* and MSR_PR bit from SRR1 */
+ rlwinm r1,r2,32-12,29,29 /* shift MSR_PR to _PAGE_USER posn */
lis r2,swapper_pg_dir@ha /* if kernel address, use */
addi r2,r2,swapper_pg_dir@l /* kernel page table */
- mfspr r1,SPRN_SRR1 /* and MSR_PR bit from SRR1 */
- rlwinm r1,r1,32-12,29,29 /* shift MSR_PR to _PAGE_USER posn */
112: tophys(r2,r2)
rlwimi r2,r3,12,20,29 /* insert top 10 bits of address */
lwz r2,0(r2) /* get pmd entry */
@@ -549,10 +549,10 @@ DataLoadTLBMiss:
li r1,_PAGE_USER|_PAGE_PRESENT /* low addresses tested as user */
lwz r2,PGDIR(r2)
blt+ 112f
+ mfspr r2,SPRN_SRR1 /* and MSR_PR bit from SRR1 */
+ rlwinm r1,r2,32-12,29,29 /* shift MSR_PR to _PAGE_USER posn */
lis r2,swapper_pg_dir@ha /* if kernel address, use */
addi r2,r2,swapper_pg_dir@l /* kernel page table */
- mfspr r1,SPRN_SRR1 /* and MSR_PR bit from SRR1 */
- rlwinm r1,r1,32-12,29,29 /* shift MSR_PR to _PAGE_USER posn */
112: tophys(r2,r2)
rlwimi r2,r3,12,20,29 /* insert top 10 bits of address */
lwz r2,0(r2) /* get pmd entry */
@@ -621,10 +621,10 @@ DataStoreTLBMiss:
li r1,_PAGE_RW|_PAGE_USER|_PAGE_PRESENT /* access flags */
lwz r2,PGDIR(r2)
blt+ 112f
+ mfspr r2,SPRN_SRR1 /* and MSR_PR bit from SRR1 */
+ rlwimi r1,r2,32-12,29,29 /* shift MSR_PR to _PAGE_USER posn */
lis r2,swapper_pg_dir@ha /* if kernel address, use */
addi r2,r2,swapper_pg_dir@l /* kernel page table */
- mfspr r1,SPRN_SRR1 /* and MSR_PR bit from SRR1 */
- rlwinm r1,r1,32-12,29,29 /* shift MSR_PR to _PAGE_USER posn */
112: tophys(r2,r2)
rlwimi r2,r3,12,20,29 /* insert top 10 bits of address */
lwz r2,0(r2) /* get pmd entry */
--
1.5.0.3
^ permalink raw reply related
* Re: [patch 1/2] powerpc: rmb fix
From: Linas Vepstas @ 2007-08-21 21:42 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: Nick Piggin, Paul Mackerras, linuxppc-dev
In-Reply-To: <d9f43b5c31fde5851a7af1d0f36eb134@kernel.crashing.org>
On Tue, Aug 21, 2007 at 09:43:17PM +0200, Segher Boessenkool wrote:
> >> #define mb() __asm__ __volatile__ ("sync" : : : "memory")
> >> -#define rmb() __asm__ __volatile__ (__stringify(LWSYNC) : : :
> >> "memory")
> >> +#define rmb() __asm__ __volatile__ ("sync" : : : "memory")
> >> #define wmb() __asm__ __volatile__ ("sync" : : : "memory")
> >> #define read_barrier_depends() do { } while(0)
> >>
> >> @@ -42,7 +42,7 @@
> >> #ifdef __KERNEL__
> >> #ifdef CONFIG_SMP
> >> #define smp_mb() mb()
> >> -#define smp_rmb() rmb()
> >> +#define smp_rmb() __asm__ __volatile__ (__stringify(LWSYNC) : : :
> >> "memory")
> >> #define smp_wmb() eieio()
> >> #define smp_read_barrier_depends() read_barrier_depends()
> >> #else
> >
> > I had to think about this one for awhile. It looks at first glance to
> > be the right
> > thing to do. But I do wonder how long rmb() has been lwsync
>
> Since the {ppc,ppc64} -> powerpc merge.
>
> > and if as a practical matter that has caused any problems?
>
> It has not as far as I know.
>
> > If this isn't causing any problems maybe there
> > is some loigic we are overlooking?
>
> The I/O accessor functions enforce the necessary ordering
> already I believe.
So, is this patch desirable?
--linas
^ permalink raw reply
* [PATCH] powerpc: Fix race in the pasemi timebase calibration
From: Olof Johansson @ 2007-08-21 22:06 UTC (permalink / raw)
To: paulus; +Cc: linuxppc-dev
Make sure the new timebase value is available by the time take_timebase
completes. Otherwise take_timebase might race with give_timebase,
causing severe badness when the value later is modified (think looong
hang trying to catch up with a very large number of lost ticks).
This has shown up lately, possibly because of other code paths in the
startup of secondary cpus being slimmed down enough that the race happened
more often.
Signed-off-by: Olof Johansson <olof@lixom.net>
---
Paul,
This started showing up in the 2.6.22 timeframe, and noone else seems
to have hit it yet, so there's no urge to get it into 2.6.23. Please
queue it for .24 though.
Thanks,
-Olof
Index: mainline/arch/powerpc/platforms/pasemi/setup.c
===================================================================
--- mainline.orig/arch/powerpc/platforms/pasemi/setup.c
+++ mainline/arch/powerpc/platforms/pasemi/setup.c
@@ -50,6 +50,7 @@ static void pas_restart(char *cmd)
#ifdef CONFIG_SMP
static DEFINE_SPINLOCK(timebase_lock);
+static unsigned long timebase_avail;
static void __devinit pas_give_timebase(void)
{
@@ -61,6 +62,7 @@ static void __devinit pas_give_timebase(
mtspr(SPRN_TBCTL, TBCTL_UPDATE_LOWER | (tb & 0xffffffff));
mtspr(SPRN_TBCTL, TBCTL_UPDATE_UPPER | (tb >> 32));
mtspr(SPRN_TBCTL, TBCTL_RESTART);
+ timebase_avail = 1;
spin_unlock(&timebase_lock);
pr_debug("pas_give_timebase: cpu %d gave tb %lx\n",
smp_processor_id(), tb);
@@ -68,6 +70,8 @@ static void __devinit pas_give_timebase(
static void __devinit pas_take_timebase(void)
{
+ while (!timebase_avail)
+ smp_rmb();
pr_debug("pas_take_timebase: cpu %d has tb %lx\n",
smp_processor_id(), mftb());
}
^ 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