* [PATCH v4 0/2] SPI support for fsl_soc and mpc832x_rdb
From: Anton Vorontsov @ 2007-08-21 13:45 UTC (permalink / raw)
To: linuxppc-dev
Hi all,
Thanks for the previous reviews, this is v4 against Linus' tree,
as of today.
Changelog:
v3 -> v4
- removed fsl,device-id property from SPI nodes;
- instead of fsl_spi_info structure, now fsl_spi_init() accepting
four arguments;
- machine_is(mpc832x_rdb) added in the beginning of
mpc832x_spi_init().
v2 -> v3
o Device tree:
- completely removed mmc node;
- removed pio-handles and pio-maps.
o board file:
- Instead of par_io_of_config(), now par_io_config_pin() used to
configure GPIO pins, which does not require device tree node.
v1 -> v2
o Device tree:
- cosmetic cleanups (@01 -> @1);
- device-id renamed to fsl,device-id;
- removed max-chipselect and sysclk properties from spi node;
- removed chipselect property from mmc node, now reg property
used for this purpose, thereby address-cells and size-cells
added to the spi node;
- other non-mandatory (device-id, device_type, compatible, ...)
properties removed from mmc node, today board file is using
of_find_node_by_name(), instead of of_find_compatible_node();
- "qe" mode renamed to "cpu-qe".
o board file <-> fsl_soc interaction
- fsl_soc no longer scans for SPI nodes in the arch initcall.
Also it's no longer exports any global variables. Instead, it's
export fsl_spi_init function now, which accepts pointer to the
fsl_spi_board_info structure;
- board file fills fsl_spi_board_info structure and issues
fsl_spi_init(), which register SPI devices and SPI board infos.
Various sanity checks also perfromed.
I'd want to note that if spi_mpc83xx will be converted to
of_platform_driver then the scheme described above will not
work anymore, and I'll have to revert back ugly hacks:
global variables for activate/deactivate_cs functions. I see
no other options.
Thanks,
--
Anton Vorontsov
email: cbou@mail.ru
backup email: ya-cbou@yandex.ru
irc://irc.freenode.net/bd2
^ permalink raw reply
* [PATCH v4 1/2] [POWERPC] fsl_soc: add support for fsl_spi
From: Anton Vorontsov @ 2007-08-21 13:47 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <20070821134537.GA7428@localhost.localdomain>
Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
---
arch/powerpc/sysdev/fsl_soc.c | 85 +++++++++++++++++++++++++++++++++++++++++
arch/powerpc/sysdev/fsl_soc.h | 7 +++
2 files changed, 92 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/sysdev/fsl_soc.c b/arch/powerpc/sysdev/fsl_soc.c
index 1cf29c9..25a96b5 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,87 @@ err:
arch_initcall(cpm_smc_uart_of_init);
#endif /* CONFIG_8xx */
+
+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))
+{
+ 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);
+}
+EXPORT_SYMBOL(fsl_spi_init);
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 v4 2/2] [POWERPC] MPC832x_RDB: update dts to use SPI1 in QE, register mmc_spi stub
From: Anton Vorontsov @ 2007-08-21 13:47 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <20070821134537.GA7428@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: OF /chosen/initrd,* variables - patch, official?
From: David Gibson @ 2007-08-21 13:54 UTC (permalink / raw)
To: Matt Sealey; +Cc: ppc-dev, linuxppc-embedded
In-Reply-To: <46CAE177.3010508@genesi-usa.com>
On Tue, Aug 21, 2007 at 01:58:31PM +0100, Matt Sealey wrote:
>
> David Gibson wrote:
> > Uh... no... this is in the bootwrapper, long before ppc_md even
> > exists. platform_init() is called from arch/powerpc/boot/crt0.S,
> > immediately before main().
>
> Oh *THAT* platform init.
>
> So I could just drop a
>
> } else {
> dt_find_initrd();
> }
>
> .. at the end and nobody would be too disgusted or have any problems?
Err.. at the end of what? Each platform has it's own version of
platform_init().
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
* Re: OF /chosen/initrd,* variables - patch, official?
From: Matt Sealey @ 2007-08-21 14:24 UTC (permalink / raw)
To: Matt Sealey, ppc-dev, linuxppc-embedded
In-Reply-To: <20070821135449.GA7438@localhost.localdomain>
David Gibson wrote:
> On Tue, Aug 21, 2007 at 01:58:31PM +0100, Matt Sealey wrote:
>> David Gibson wrote:
>>> Uh... no... this is in the bootwrapper, long before ppc_md even
>>> exists. platform_init() is called from arch/powerpc/boot/crt0.S,
>>> immediately before main().
>> Oh *THAT* platform init.
>>
>> So I could just drop a
>>
>> } else {
>> dt_find_initrd();
>> }
>>
>> .. at the end and nobody would be too disgusted or have any problems?
>
> Err.. at the end of what? Each platform has it's own version of
> platform_init().
arch/powerpc/boot/of.c since it's not really relevant to me for non-OF
platforms?
--
Matt Sealey <matt@genesi-usa.com>
Genesi, Manager, Developer Relations
^ permalink raw reply
* Re: Patches for ppc?
From: Segher Boessenkool @ 2007-08-21 15:14 UTC (permalink / raw)
To: David Gibson; +Cc: Linuxppc-dev, David Woodhouse
In-Reply-To: <20070821052514.GC21169@localhost.localdomain>
> 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".
Segher
^ permalink raw reply
* [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
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