* Re: [i2c] [PATCH] update module-init-tools to support the i2c subsystem
From: Jon Smirl @ 2008-01-14 14:25 UTC (permalink / raw)
To: Geert Uytterhoeven; +Cc: Jean Delvare, linuxppc-dev, i2c, linux-kernel
In-Reply-To: <Pine.LNX.4.64.0801141154420.3058@vixen.sonytel.be>
On 1/14/08, Geert Uytterhoeven <Geert.Uytterhoeven@sonycom.com> wrote:
> On Sun, 13 Jan 2008, Jon Smirl wrote:
> > On 1/13/08, Jean Delvare <khali@linux-fr.org> wrote:
> > > On Sun, 13 Jan 2008 11:26:07 -0500, Jon Smirl wrote:
> > > > On 1/13/08, Jean Delvare <khali@linux-fr.org> wrote:
> > > > > On Sun, 13 Jan 2008 10:14:14 -0500, Jon Smirl wrote:
> > > > > > On 1/13/08, Jean Delvare <khali@linux-fr.org> wrote:
> > > > > > > On Mon, 17 Dec 2007 21:39:37 -0500, Jon Smirl wrote:
> > > > > > > > Follow on to: "Series to add device tree naming to i2c"
> > > > > > > > Teach module-init-tools about the i2c subsystem.
> > > > > > >
> > > > > > > Can you please explain what this patch does and why it is nee=
ded?
> > > > > >
> > > > > > It generates the entries needed for the user space module tools=
to
> > > > > > work with the aliases. For example modprobe/depmod. It is a sta=
ndard
> > > > > > part of the kernel module system.
> > > > >
> > > > > What entries, where? What can you do after applying your patch th=
at you
> > > > > couldn't do before?
> > > >
> > > > The drivers you are testing with don't depend on other drivers.
> > >
> > > They do. I'm testing with the lm90 driver, which depends on the hwmon
> > > driver. Both load automatically when the underlying i2c-parport drive=
r
> > > instantiate an "adm1032" i2c device.
> >
> > I don't know exactly what those modules tables are used for. I just
> > copied what the other subsystems do. Maybe they are used when you make
> > an initrd to know which drivers to copy into the image.
>
> Module-init-tools needs those table to create module aliases in the *.ko
> files from the MODULE_DEVICE_TABLE(), so udev can load the modules based
> on the device IDs when the devices appear in sysfs.
>
> That's the generic part. How this applies to i2c devices on platforms
> without Open Firmware device trees is another question. I guess that's
> where Jean gets confused (i2c_device_id got _removed_ last year,
> because it didn't make sense (at the time?)).
Last year i2c modules weren't dynamically loadable so it wasn't needed.
>
> With kind regards,
>
> Geert Uytterhoeven
> Software Architect
>
> Sony Network and Software Technology Center Europe
> The Corporate Village =B7 Da Vincilaan 7-D1 =B7 B-1935 Zaventem =B7 Belgi=
um
>
> Phone: +32 (0)2 700 8453
> Fax: +32 (0)2 700 8622
> E-mail: Geert.Uytterhoeven@sonycom.com
> Internet: http://www.sony-europe.com/
>
> Sony Network and Software Technology Center Europe
> A division of Sony Service Centre (Europe) N.V.
> Registered office: Technologielaan 7 =B7 B-1840 Londerzeel =B7 Belgium
> VAT BE 0413.825.160 =B7 RPR Brussels
> Fortis Bank Zaventem =B7 Swift GEBABEBB08A =B7 IBAN BE39001382358619
--=20
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* Re: [PATCH] [POWERPC] make ibmebus use of_(un)register_driver
From: Joachim Fenkes @ 2008-01-14 12:14 UTC (permalink / raw)
To: Stephen Rothwell
Cc: Heiko J Schick, ppc-dev, Christoph Raisch, paulus, Stefan Roscher
In-Reply-To: <20080114174648.bca30b55.sfr@canb.auug.org.au>
On Monday 14 January 2008 07:46, Stephen Rothwell wrote:
> diff --git a/arch/powerpc/kernel/ibmebus.c b/arch/powerpc/kernel/ibmebus.c
> index 1844359..2a6a388 100644
> --- a/arch/powerpc/kernel/ibmebus.c
> +++ b/arch/powerpc/kernel/ibmebus.c
> @@ -197,16 +197,13 @@ int ibmebus_register_driver(struct of_platform_driver *drv)
> /* If the driver uses devices that ibmebus doesn't know, add them */
> ibmebus_create_devices(drv->match_table);
>
> - drv->driver.name = drv->name;
> - drv->driver.bus = &ibmebus_bus_type;
> -
> - return driver_register(&drv->driver);
> + return of_register_driver(drv, &ibmebus_bus_type);
> }
> EXPORT_SYMBOL(ibmebus_register_driver);
>
> void ibmebus_unregister_driver(struct of_platform_driver *drv)
> {
> - driver_unregister(&drv->driver);
> + of_unregister_driver(drv);
> }
> EXPORT_SYMBOL(ibmebus_unregister_driver);
Looks like a transparent change to me. Good one.
Joachim
Acked-by: Joachim Fenkes <fenkes@de.ibm.com>
^ permalink raw reply
* Re: [i2c] [PATCH] update module-init-tools to support the i2c subsystem
From: Geert Uytterhoeven @ 2008-01-14 10:57 UTC (permalink / raw)
To: Jon Smirl; +Cc: Jean Delvare, linuxppc-dev, i2c, linux-kernel
In-Reply-To: <9e4733910801131004i669276e2pde04b195dd10bd90@mail.gmail.com>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 2464 bytes --]
On Sun, 13 Jan 2008, Jon Smirl wrote:
> On 1/13/08, Jean Delvare <khali@linux-fr.org> wrote:
> > On Sun, 13 Jan 2008 11:26:07 -0500, Jon Smirl wrote:
> > > On 1/13/08, Jean Delvare <khali@linux-fr.org> wrote:
> > > > On Sun, 13 Jan 2008 10:14:14 -0500, Jon Smirl wrote:
> > > > > On 1/13/08, Jean Delvare <khali@linux-fr.org> wrote:
> > > > > > On Mon, 17 Dec 2007 21:39:37 -0500, Jon Smirl wrote:
> > > > > > > Follow on to: "Series to add device tree naming to i2c"
> > > > > > > Teach module-init-tools about the i2c subsystem.
> > > > > >
> > > > > > Can you please explain what this patch does and why it is needed?
> > > > >
> > > > > It generates the entries needed for the user space module tools to
> > > > > work with the aliases. For example modprobe/depmod. It is a standard
> > > > > part of the kernel module system.
> > > >
> > > > What entries, where? What can you do after applying your patch that you
> > > > couldn't do before?
> > >
> > > The drivers you are testing with don't depend on other drivers.
> >
> > They do. I'm testing with the lm90 driver, which depends on the hwmon
> > driver. Both load automatically when the underlying i2c-parport driver
> > instantiate an "adm1032" i2c device.
>
> I don't know exactly what those modules tables are used for. I just
> copied what the other subsystems do. Maybe they are used when you make
> an initrd to know which drivers to copy into the image.
Module-init-tools needs those table to create module aliases in the *.ko
files from the MODULE_DEVICE_TABLE(), so udev can load the modules based
on the device IDs when the devices appear in sysfs.
That's the generic part. How this applies to i2c devices on platforms
without Open Firmware device trees is another question. I guess that's
where Jean gets confused (i2c_device_id got _removed_ last year,
because it didn't make sense (at the time?)).
With kind regards,
Geert Uytterhoeven
Software Architect
Sony Network and Software Technology Center Europe
The Corporate Village · Da Vincilaan 7-D1 · B-1935 Zaventem · Belgium
Phone: +32 (0)2 700 8453
Fax: +32 (0)2 700 8622
E-mail: Geert.Uytterhoeven@sonycom.com
Internet: http://www.sony-europe.com/
Sony Network and Software Technology Center Europe
A division of Sony Service Centre (Europe) N.V.
Registered office: Technologielaan 7 · B-1840 Londerzeel · Belgium
VAT BE 0413.825.160 · RPR Brussels
Fortis Bank Zaventem · Swift GEBABEBB08A · IBAN BE39001382358619
^ permalink raw reply
* Re: [PATCH] MTD for Taco
From: Josh Boyer @ 2008-01-14 8:44 UTC (permalink / raw)
To: Sean MacLennan; +Cc: linuxppc-dev, Stefan Roese
In-Reply-To: <478AEB39.70106@pikatech.com>
On Sun, 13 Jan 2008 23:55:21 -0500
Sean MacLennan <smaclennan@pikatech.com> wrote:
> Stefan Roese wrote:
> >
> >> +#ifdef CONFIG_TACO
> >> +/* The NDFC may allow 32bit read/writes, but it sure doesn't work on
> >> + * the taco!
> >> + */
> >>
> >
> > We definitely don't want to see such board specific stuff in the common
> > NDFC driver. And I really doubt that you need this change for your board.
> > We are using this ndfc driver on multiple boards, and all have no
> > problems accessing the controller with 32bit read/writes. So you most
> > likely have a problem with your board port. Perhaps something with
> > with the EBC setup. Please re-check and compare with boards that are know
> > to work, like Sequoia.
> >
> How about adding a config option that lets you specify 8 bit access?
> Something like CONFIG_NDFC_8BIT_ACCESS. We could default it to no and
> put a little blurb that says something like:
>
> On some platforms the 32bit read/writes cause a machine access
> exception. If you get a machine access exception while reading the NAND
> bad block table, try turning on 8 bit access.
But did you go back and verify the EBC settings were correct on your
board? This shouldn't be needed at all if the EBC bank settings and
timings are correct.
josh
^ permalink raw reply
* Re: Problem booting Linux 2.6 on Virtex-4
From: Enno Lübbers @ 2008-01-14 8:37 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <440abda90801132112y76f2899by4ef582c9b58fd6b6@mail.gmail.com>
Hello David,
Am 14.01.2008 um 06:12 schrieb David Baird:
> I'm having trouble with getting Linux to boot farther than early_init.
> [...]
> So, I experimented further and discovered that different memory
> regions seem to be aliased on to each other every 2*32*256 bytes.
This sounds either like a wrong programming of an BRx/ORx memory
controller register pair (which, AFAIK, the PPC405 does not have), or
like a messed up address map in EDK. My guess is that an optimized/
sloppy implementation of the address decoder for some peripheral in an
EDK system could produce something like you described; or there's a
block RAM that's attached to a controller in the wrong way; or the
bank/address parameters of the DDR controller don't match the physical
setup... there's a lot that can go wrong obviously on a configurable
SoC.
Can you be more specific about your hardware platform? Is this a
reference design? What board are you using?
Regards
- Enno
--
Dipl.-Ing. Enno Luebbers
Computer Engineering Group
University of Paderborn
Warburger Str. 100
33098 Paderborn
http://wwwcs.upb.de/cs/ag-platzner
phone: 05251 / 60-5397
fax: 05251 / 60-5377
^ permalink raw reply
* Re: I2C and CAN bus on MPC5200B device tree
From: Wolfgang Grandegger @ 2008-01-14 8:10 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-embedded, ppc-dev
In-Reply-To: <fa686aa40801131635o499c8c08i6a2667cd7df1a72e@mail.gmail.com>
Grant Likely wrote:
> On 1/13/08, Matt Sealey <matt@genesi-usa.com> wrote:
>> Hi guys,
>>
>> I know the I2C stuff is up in the air (I cannot pinpoint the documentation
>> for it) and have not found any CAN bus documentation for device trees.
>>
>> I want to update the firmware tree to add these but, am basically looking
>> for those docs, or someone to go over a few points.. is there some kind of
>> tree standard I should be looking at, or some patch I missed which has
>> a driver which implements something that looks at a compatible tree?
>
> I think some consensus has been achieved for describing i2c busses and
> their attached devices, but I don't think booting-without-of.txt has
> been updated with the details yet. I need to look into that more.
>
> I don't think anyone has tackled CAN. Best bet is to draft a tree in
> the way you think it should be described and post it to the list.
> That will give a starting point for us to discuss it and come to
> consensus.
For MSCAN on the MPC5200 we currently have:
mscan@900 {
device_type = "mscan";
compatible = "mpc5200b-mscan","mpc5200-mscan";
cell-index = <0>;
interrupts = <2 11 0>;
interrupt-parent = <&mpc5200_pic>;
reg = <900 80>;
};
mscan@980 {
device_type = "mscan";
compatible = "mpc5200b-mscan","mpc5200-mscan";
cell-index = <1>;
interrupts = <2 12 0>;
interrupt-parent = <&mpc5200_pic>;
reg = <980 80>;
};
The only thing missing is a property defining the routing of the CAN
signals, CAN 1 on I2C1 pins or CAN 2 on TMR01 pins. I think it does not
make sense to describe CAN devices on the CAN bus like for I2C.
Wolfgang.
^ permalink raw reply
* [PATCH] [POWERPC] make ibmebus use of_(un)register_driver
From: Stephen Rothwell @ 2008-01-14 6:46 UTC (permalink / raw)
To: paulus; +Cc: ppc-dev, Heiko J Schick, Joachim Fenkes
Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
arch/powerpc/kernel/ibmebus.c | 7 ++-----
1 files changed, 2 insertions(+), 5 deletions(-)
diff --git a/arch/powerpc/kernel/ibmebus.c b/arch/powerpc/kernel/ibmebus.c
index 1844359..2a6a388 100644
--- a/arch/powerpc/kernel/ibmebus.c
+++ b/arch/powerpc/kernel/ibmebus.c
@@ -197,16 +197,13 @@ int ibmebus_register_driver(struct of_platform_driver *drv)
/* If the driver uses devices that ibmebus doesn't know, add them */
ibmebus_create_devices(drv->match_table);
- drv->driver.name = drv->name;
- drv->driver.bus = &ibmebus_bus_type;
-
- return driver_register(&drv->driver);
+ return of_register_driver(drv, &ibmebus_bus_type);
}
EXPORT_SYMBOL(ibmebus_register_driver);
void ibmebus_unregister_driver(struct of_platform_driver *drv)
{
- driver_unregister(&drv->driver);
+ of_unregister_driver(drv);
}
EXPORT_SYMBOL(ibmebus_unregister_driver);
--
1.5.3.8
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
^ permalink raw reply related
* Re: [PATCH 2/3] mtd: Factor out OF partition support from the NOR driver.
From: Stephen Rothwell @ 2008-01-14 6:21 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev, dwmw2, linux-mtd
[-- Attachment #1: Type: text/plain, Size: 1305 bytes --]
Hi Scott,
[Corrected list address.]
On Fri, 11 Jan 2008 14:43:16 -0600 Scott Wood <scottwood@freescale.com> wrote:
>
> +++ b/drivers/mtd/ofpart.c
> +int __devinit of_mtd_parse_partitions(struct device *dev,
> + nr_parts = 0;
> + for (pp = node->child; pp; pp = pp->sibling)
for_each_child_of_node(node, pp)
> + nr_parts++;
> + for (pp = of_get_next_child(node, NULL), i = 0; pp;
> + pp = of_get_next_child(node, pp), i++) {
i = 0;
for_each_child_of_node(node, pp) {
> + const u32 *reg;
> + int len;
> +
> + reg = of_get_property(pp, "reg", &len);
> + if (!reg || (len != 2*sizeof(u32))) {
Spaces around '*'.
> + of_node_put(pp);
> + dev_err(dev, "Invalid 'reg' on %s\n", node->full_name);
> + kfree(*pparts);
> + *pparts = NULL;
> + return -EINVAL;
> + }
> + (*pparts)[i].offset = reg[0];
> + (*pparts)[i].size = reg[1];
> +
> + partname = of_get_property(pp, "label", &len);
> + if (!partname)
> + partname = of_get_property(pp, "name", &len);
> + (*pparts)[i].name = (char *)partname;
> +
> + if (of_get_property(pp, "read-only", &len))
> + (*pparts)[i].mask_flags = MTD_WRITEABLE;
i++;
> + }
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH 3/3] Freescale enhanced Local Bus Controller FCM NAND support.
From: Stephen Rothwell @ 2008-01-14 6:19 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev, dwmw2, linux-mtd
[-- Attachment #1: Type: text/plain, Size: 941 bytes --]
Hi Scott,
[Corrected list address.]
On Fri, 11 Jan 2008 14:43:20 -0600 Scott Wood <scottwood@freescale.com> wrote:
>
> +static int __devinit fsl_elbc_ctrl_probe(struct of_device *ofdev,
> + const struct of_device_id *match)
> +{
> + child = NULL;
> + while ((child = of_get_next_child(ofdev->node, child)))
for_each_child_of_node(of_dev->node, child)
> + if (of_device_is_compatible(child, "fsl,elbc-fcm-nand"))
> + fsl_elbc_chip_probe(ctrl, child);
> +static struct of_device_id fsl_elbc_match[] = {
const, please.
> +static struct of_platform_driver fsl_elbc_ctrl_driver = {
.driver = {
> + .name = "fsl-elbc",
},
> + .match_table = fsl_elbc_match,
> + .probe = fsl_elbc_ctrl_probe,
> + .remove = __devexit_p(fsl_elbc_ctrl_remove),
> +};
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH 3/3] Freescale enhanced Local Bus Controller FCM NAND support.
From: Stephen Rothwell @ 2008-01-14 6:13 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev, dwmw2, linux-mtd
In-Reply-To: <20080111204320.GC11215@loki.buserror.net>
[-- Attachment #1: Type: text/plain, Size: 912 bytes --]
Hi Scott,
On Fri, 11 Jan 2008 14:43:20 -0600 Scott Wood <scottwood@freescale.com> wrote:
>
> +static int __devinit fsl_elbc_ctrl_probe(struct of_device *ofdev,
> + const struct of_device_id *match)
> +{
> + child = NULL;
> + while ((child = of_get_next_child(ofdev->node, child)))
for_each_child_of_node(of_dev->node, child)
> + if (of_device_is_compatible(child, "fsl,elbc-fcm-nand"))
> + fsl_elbc_chip_probe(ctrl, child);
> +static struct of_device_id fsl_elbc_match[] = {
const, please.
> +static struct of_platform_driver fsl_elbc_ctrl_driver = {
.driver = {
> + .name = "fsl-elbc",
},
> + .match_table = fsl_elbc_match,
> + .probe = fsl_elbc_ctrl_probe,
> + .remove = __devexit_p(fsl_elbc_ctrl_remove),
> +};
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH 2/3] mtd: Factor out OF partition support from the NOR driver.
From: Stephen Rothwell @ 2008-01-14 6:02 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev, dwmw2, linux-mtd
In-Reply-To: <20080111204316.GB11215@loki.buserror.net>
[-- Attachment #1: Type: text/plain, Size: 1276 bytes --]
Hi Scott,
On Fri, 11 Jan 2008 14:43:16 -0600 Scott Wood <scottwood@freescale.com> wrote:
>
> +++ b/drivers/mtd/ofpart.c
> +int __devinit of_mtd_parse_partitions(struct device *dev,
> + nr_parts = 0;
> + for (pp = node->child; pp; pp = pp->sibling)
for_each_child_of_node(node, pp)
> + nr_parts++;
> + for (pp = of_get_next_child(node, NULL), i = 0; pp;
> + pp = of_get_next_child(node, pp), i++) {
i = 0;
for_each_child_of_node(node, pp) {
> + const u32 *reg;
> + int len;
> +
> + reg = of_get_property(pp, "reg", &len);
> + if (!reg || (len != 2*sizeof(u32))) {
Spaces around '*'.
> + of_node_put(pp);
> + dev_err(dev, "Invalid 'reg' on %s\n", node->full_name);
> + kfree(*pparts);
> + *pparts = NULL;
> + return -EINVAL;
> + }
> + (*pparts)[i].offset = reg[0];
> + (*pparts)[i].size = reg[1];
> +
> + partname = of_get_property(pp, "label", &len);
> + if (!partname)
> + partname = of_get_property(pp, "name", &len);
> + (*pparts)[i].name = (char *)partname;
> +
> + if (of_get_property(pp, "read-only", &len))
> + (*pparts)[i].mask_flags = MTD_WRITEABLE;
i++;
> + }
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH 2/3] mpc82xx: Embedded Planet EP8248E support
From: Stephen Rothwell @ 2008-01-14 5:48 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev
In-Reply-To: <20080111200742.GB696@loki.buserror.net>
[-- Attachment #1: Type: text/plain, Size: 1393 bytes --]
Hi Scott,
On Fri, 11 Jan 2008 14:07:42 -0600 Scott Wood <scottwood@freescale.com> wrote:
>
> +++ b/arch/powerpc/platforms/82xx/ep8248e.c
> +static struct mdiobb_ops ep8248e_mdio_ops = {
const, please.
> +static struct of_platform_driver ep8248e_mdio_driver = {
.driver = {
> + .name = "ep8248e-mdio-bitbang",
},
> +static const struct cpm_pin ep8248_pins[] = {
Could be __initdata
> +static void __init ep8248_setup_arch(void)
> +{
> + ep8248e_bcsr_node =
> + of_find_compatible_node(NULL, NULL, "fsl,ep8248e-bcsr");
> + if (!ep8248e_bcsr_node) {
> + printk(KERN_ERR "No bcsr in device tree\n");
> + return;
> + }
> +
> + ep8248e_bcsr = of_iomap(ep8248e_bcsr_node, 0);
> + if (!ep8248e_bcsr) {
> + printk(KERN_ERR "Cannot map BCSR registers\n");
of_node_put(ep8248e_bcsr_node);
ep8248e_bcsr_node = NULL;
> + return;
> +static int __init declare_of_platform_devices(void)
> +{
> + if (!machine_is(ep8248))
> + return 0;
> +
> + of_platform_bus_probe(NULL, of_bus_ids, NULL);
> + of_register_platform_driver(&ep8248e_mdio_driver);
> +
> + return 0;
> +}
> +device_initcall(declare_of_platform_devices);
machine_device_initcall(ep8248, declare_of_platform_devices);
Then remove the machine_is test above.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH 1/8] pseries: phyp dump: Docmentation
From: Olof Johansson @ 2008-01-14 5:24 UTC (permalink / raw)
To: Linas Vepstas; +Cc: lkessler, linuxppc-dev, Nathan Lynch, mahuja, strosake
In-Reply-To: <3ae3aa420801110857l5e43fd56s5bd1c24ffac939f3@mail.gmail.com>
On Fri, Jan 11, 2008 at 10:57:51AM -0600, Linas Vepstas wrote:
> On 10/01/2008, Nathan Lynch <ntl@pobox.com> wrote:
> > Mike Strosaker wrote:
> > >
> > > At the risk of repeating what others have already said, the PHYP-assistance
> > > method provides some advantages that the kexec method cannot:
> > > - Availability of the system for production use before the dump data is
> > > collected. As was mentioned before, some production systems may choose not
> > > to operate with the limited memory initially available after the reboot,
> > > but it sure is nice to provide the option.
> >
> > I'm more concerned that this design encourages the user to resume a
> > workload *which is almost certainly known to result in a system crash*
> > before collection of crash data is complete. Maybe the gamble will
> > pay off most of the time, but I wouldn't want to be working support
> > when it doesn't.
>
> Workloads that cause crashes within hours of startup tend to be
> weeded-out/discovered during pre-production test of the system
> to be deployed. Since its pre-production test, dumps can be
> taken in a leisurely manner. Heck, even a session at the
> xmon prompt can be contemplated.
>
> The problem is when the crash only reproduces after days or
> weeks of uptime, on a production machine. Since the machine
> is in production, its got to be brought back up ASAP. Since
> its crashing only after days/weeks, the dump should have
> plenty of time to complete. (And if it crashes quickly after
> that reboot ... well, support people always welcome ways
> in which a bug can be reproduced more quickly/easily).
How do you expect to have it in full production if you don't have all
resources available for it? It's not until the dump has finished that you
can return all memory to the production environment and use it.
This can very easily be argued in both direction, with no clear winner:
If the crash is stress-induced (say a slashdotted website), for those
cases it seems more rational to take the time, collect _good data_ even
if it takes a little longer, and then go back into production. Especially
if the alternative is to go back into production immediately, collect
about half of the data, and then crash again. Rinse and repeat.
Anyway -- I can agree that some of the arguments w.r.t robustness and
reliability of collecting dumps can be higher using this approach. It
really surprises me that there's no way to reset a device through PHYP
though. Seems like such a fundamental feature.
I think people are overly optimistic if they think it'll be possible
to do all of this reliably (as in with consistent performance) without
a second reboot though. At least without similar amounts of work being
done as it would have taken to fix kdump's reliability in the first place.
Speaking of reboots. PHYP isn't known for being quick at rebooting a
partition, it used to take in the order of minutes even on a small
machine. Has that been fixed? If not, the avoiding an extra reboot
argument hardly seems like a benefit versus kdump+kexec, which reboots
nearly instantly and without involvement from PHYP.
-Olof
^ permalink raw reply
* Problem booting Linux 2.6 on Virtex-4
From: David Baird @ 2008-01-14 5:12 UTC (permalink / raw)
To: linuxppc-embedded
Hi,
I'm having trouble with getting Linux to boot farther than early_init.
Things start to go obviously wrong after early_init calls memset to
clear the .bss section. The first symptom I noticed was that the
stack (which currently contains the link register) was getting zeroed
by memset. This doesn't make any sense because the stack does not
intersect the .bss section; I confirmed that the do not intersect by
using JTAG+xmd to read the registers and also by inserting print
statements.
So, I experimented further and discovered that different memory
regions seem to be aliased on to each other every 2*32*256 bytes.
e.g.:
char * ptr = 0;
unsigned long addr = 0xc0001234; // pick some address
int n = 1; // pick some integer
// Now write values to two different addresses:
ptr[addr] = 42;
ptr[addr + n*2*32*256] = 24;
volatile asm ("nop");
// Now mysteriously, ptr[addr] == 24
The reason I have written 32*256 is because that corresponds to the
number of bytes per cache line times the number of cache lines ...
because I was suspicious this might be related to caching. However,
with experimentation, I found that the aliasing does not occur every
32*256 bytes, but rather every 32*512 bytes (hence 2*32*256).
Anyways, I looked in embed_config (and confirmed by dumping zImage.elf
with objdump) that the cache is being invalidated with "dccci".
"dccci" is being called, as expected, and therefore everything looks
good in the code.
I am completely perplexed. The cache appears to be initialized
properly. I don't have any trouble in real mode. But as soon the
kernel switches into virtual mode (in head_4xx.S), then this memory
aliasing problem happens. I wrote a completely standalone assembler
script that initializes the cache, TLBs, and virtual mode in the same
way as embed_config and head_4xx.S and so I am able to reproduce the
problem outside of the kernel. I can attach that code if someone
thinks it will be useful - just let me know.
Does anyone have an idea about what might be going wrong? I can send
more information or test anything that you want me to.
-David
^ permalink raw reply
* Re: [PATCH] MTD for Taco
From: Sean MacLennan @ 2008-01-14 4:55 UTC (permalink / raw)
To: Stefan Roese; +Cc: linuxppc-dev
In-Reply-To: <200801051041.18173.sr@denx.de>
Stefan Roese wrote:
>
>> +#ifdef CONFIG_TACO
>> +/* The NDFC may allow 32bit read/writes, but it sure doesn't work on
>> + * the taco!
>> + */
>>
>
> We definitely don't want to see such board specific stuff in the common
> NDFC driver. And I really doubt that you need this change for your board.
> We are using this ndfc driver on multiple boards, and all have no
> problems accessing the controller with 32bit read/writes. So you most
> likely have a problem with your board port. Perhaps something with
> with the EBC setup. Please re-check and compare with boards that are know
> to work, like Sequoia.
>
How about adding a config option that lets you specify 8 bit access?
Something like CONFIG_NDFC_8BIT_ACCESS. We could default it to no and
put a little blurb that says something like:
On some platforms the 32bit read/writes cause a machine access
exception. If you get a machine access exception while reading the NAND
bad block table, try turning on 8 bit access.
Cheers,
Sean
^ permalink raw reply
* Re: I2C and CAN bus on MPC5200B device tree
From: Olof Johansson @ 2008-01-14 4:42 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-embedded, ppc-dev
In-Reply-To: <fa686aa40801131635o499c8c08i6a2667cd7df1a72e@mail.gmail.com>
On Sun, Jan 13, 2008 at 05:35:09PM -0700, Grant Likely wrote:
> On 1/13/08, Matt Sealey <matt@genesi-usa.com> wrote:
> >
> > Hi guys,
> >
> > I know the I2C stuff is up in the air (I cannot pinpoint the documentation
> > for it) and have not found any CAN bus documentation for device trees.
> >
> > I want to update the firmware tree to add these but, am basically looking
> > for those docs, or someone to go over a few points.. is there some kind of
> > tree standard I should be looking at, or some patch I missed which has
> > a driver which implements something that looks at a compatible tree?
>
> I think some consensus has been achieved for describing i2c busses and
> their attached devices, but I don't think booting-without-of.txt has
> been updated with the details yet. I need to look into that more.
I think simple devices might have been agreed upon (but it's been a
while since it was covered). Muxed busses probably hasn't. Either that
or I completely missed the emails.
-Olof
^ permalink raw reply
* Re: Enable RTC for Ebony and Walnut (v2)
From: David Gibson @ 2008-01-14 4:02 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <20080111172957.c0431145.sfr@canb.auug.org.au>
[-- Attachment #1: Type: text/plain, Size: 1227 bytes --]
On Fri, Jan 11, 2008 at 05:29:57PM +1100, Stephen Rothwell wrote:
> On Fri, 11 Jan 2008 14:25:34 +1100 David Gibson <dwg@au1.ibm.com> wrote:
> >
> > +++ working-2.6/arch/powerpc/sysdev/of_rtc.c 2008-01-11 14:17:03.000000000 +1100
>
> > +static __initdata struct {
> > + const char *compatible;
>
> If you make this an array, then the string will become __initdata as well.
Well, yes, but then I'd have to pick a specific size for the string.
Since this is supposed to be a stopgap until I can build a more
general constructor mechanism..
> > + char *plat_name;
> > +} of_rtc_table[] = {
> > + { "ds1743-nvram", "rtc-ds1742" },
> > +};
>
> > + platform_device_register_simple(plat_name, -1, res, 1);
>
> Do we care if this fails?
Well.. sort of, but there's not really any sane way of reporting it.
This will be called from early platform init code, failures shouldn't
cause us not to boot, and failure to register one rtc shouldn't cause
us not to attempt to register others if they're present.
--
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
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: I2C and CAN bus on MPC5200B device tree
From: Grant Likely @ 2008-01-14 0:35 UTC (permalink / raw)
To: Matt Sealey; +Cc: ppc-dev, linuxppc-embedded
In-Reply-To: <478A967E.7080201@genesi-usa.com>
On 1/13/08, Matt Sealey <matt@genesi-usa.com> wrote:
>
> Hi guys,
>
> I know the I2C stuff is up in the air (I cannot pinpoint the documentation
> for it) and have not found any CAN bus documentation for device trees.
>
> I want to update the firmware tree to add these but, am basically looking
> for those docs, or someone to go over a few points.. is there some kind of
> tree standard I should be looking at, or some patch I missed which has
> a driver which implements something that looks at a compatible tree?
I think some consensus has been achieved for describing i2c busses and
their attached devices, but I don't think booting-without-of.txt has
been updated with the details yet. I need to look into that more.
I don't think anyone has tackled CAN. Best bet is to draft a tree in
the way you think it should be described and post it to the list.
That will give a starting point for us to discuss it and come to
consensus.
Cheers,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: [PATCH 1/3] 8xx: Analogue & Micro Adder875 board support.
From: David Gibson @ 2008-01-14 0:01 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev
In-Reply-To: <20080111200705.GA696@loki.buserror.net>
On Fri, Jan 11, 2008 at 02:07:05PM -0600, Scott Wood wrote:
> Signed-off-by: Scott Wood <scottwood@freescale.com>
[snip]
> + aliases {
> + console = &console;
> + enet0 = ð0;
> + enet1 = ð1;
I think most other boards are settling on aliases "ethernet0"
etc. instead of "enet0" (though there's no reason you couldn't have
both.
--
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
* I2C and CAN bus on MPC5200B device tree
From: Matt Sealey @ 2008-01-13 22:53 UTC (permalink / raw)
To: ppc-dev, linuxppc-embedded
Hi guys,
I know the I2C stuff is up in the air (I cannot pinpoint the documentation
for it) and have not found any CAN bus documentation for device trees.
I want to update the firmware tree to add these but, am basically looking
for those docs, or someone to go over a few points.. is there some kind of
tree standard I should be looking at, or some patch I missed which has
a driver which implements something that looks at a compatible tree?
--
Matt Sealey <matt@genesi-usa.com>
Genesi, Manager, Developer Relations
^ permalink raw reply
* Re: [PATCH 1/5] Implement module aliasing for i2c to translate from device tree names
From: Jean Delvare @ 2008-01-13 19:05 UTC (permalink / raw)
To: Jon Smirl; +Cc: Greg KH, i2c, linux-kernel, linuxppc-dev
In-Reply-To: <9e4733910801131050h5349f3c7g459f5dfb07724b19@mail.gmail.com>
On Sun, 13 Jan 2008 13:50:46 -0500, Jon Smirl wrote:
> On 1/13/08, Jean Delvare <khali@linux-fr.org> wrote:
> > The eeprom case might be a bit confusing because that i2c driver
> > supports a single device type, so the driver name is the same as the
> > device name. Take a look at the hwmon/lm90 driver for a better example:
> > this device supports 7 different devices. The devices are mostly
> > compatible so it made sense to have a single driver for them, but they
> > all differ in some way. For example, the LM90 doesn't support PEC,
> > while the ADM1032 does. User-space needs to be able to distinguish
> > between the various types. That's the reason why we export the device
> > name through sysfs.
> >
> > Most i2c sensor drivers support several chip types, and libsensors has
> > been relying heavily on the name attribute. Less so with the lm-sensors
> > 3.0.0 rewrite, where most things are automatically detected, but if
> > nothing else, giving humans a way to distinguish between the different
> > sensor chip types is very useful. Also, not everyone will upgrade to
> > lm-sensors 3.0.0 so we need to keep supporting the previous versions.
>
> Another way to handle this is to have the drivers register multiple
> times using different names. So LM90 would register as both LM90 and
> ADM1032. All the code is shared, you just register it multiple times
> under different names.
This won't let us get rid of the name attribute. As I repeatedly
explained, removing that file now would instantly break at least all
versions of lm-sensors before 3.0.0. This alone is enough to make it
unacceptable for the years to come.
Not to mention that this seems like a waste of kernel memory. The name
attribute certainly takes one order of magnitude less memory than
registering the same driver multiple times.
I'm not sure why you want these i2c chip names to go way, given that
the module aliases you'd like to add are almost the same, just in a
different form and using OF names instead of arbitrary names.
--
Jean Delvare
^ permalink raw reply
* Re: [PATCH 1/5] Implement module aliasing for i2c to translate from device tree names
From: Jon Smirl @ 2008-01-13 18:50 UTC (permalink / raw)
To: Jean Delvare; +Cc: Greg KH, i2c, linux-kernel, linuxppc-dev
In-Reply-To: <20080113194523.51683e97@hyperion.delvare>
On 1/13/08, Jean Delvare <khali@linux-fr.org> wrote:
> Hi Jon,
>
> On Sun, 13 Jan 2008 13:01:06 -0500, Jon Smirl wrote:
> > On 1/13/08, Jean Delvare wrote:
> > > On Sun, 13 Jan 2008 11:24:29 -0500, Jon Smirl wrote:
> > > > The kernel automatically exposes modalias as a sysfs attribute so the
> > > > string must be recorded further down in the driver support layers. No
> > > > need to keep a copy in the i2c structure.
> > >
> > > Really? I didn't know that. So that's another thing that the i2c
> > > subsystem is not doing like the rest of the kernel? Can you please
> > > point me to the code that does this?
> >
> > I never noticed it before either. Just do find | grep modalias in /sys
> > and see that every driver has a modalias attribute. It is probably
> > implement in drivers/base.
>
> This doesn't mean that the kernel does this automatically! It could
> also be that each subsystem does it on its own. Given that the format of
> the modalias depends on the bus type, it wouldn't be all that
> surprising. Anyway, I'll go look at how the other subsystems handle it
> before going on.
>
> > > > Standard devices don't export a 'name' attribute. To see the driver
> > > > name for a device in sysfs look at the 'driver' link.
> > >
> > > The driver name and the device name are different things! The "name"
> > > attribute that i2c devices have tells user-space the device name, not
> > > the driver name.
> >
> > For this system my i2c device names are:
> > 0-0050 0-0051 0-0052 0-0053
>
> These are not device names, these are device bus IDs. They tell you how
> to access the devices, but they do not tell you what these devices are.
>
> > How does the name=eeprom attribute interact with this? All four of my
> > devices have name=eeprom. What is the name field used for in user
> > space?
>
> The eeprom case might be a bit confusing because that i2c driver
> supports a single device type, so the driver name is the same as the
> device name. Take a look at the hwmon/lm90 driver for a better example:
> this device supports 7 different devices. The devices are mostly
> compatible so it made sense to have a single driver for them, but they
> all differ in some way. For example, the LM90 doesn't support PEC,
> while the ADM1032 does. User-space needs to be able to distinguish
> between the various types. That's the reason why we export the device
> name through sysfs.
>
> Most i2c sensor drivers support several chip types, and libsensors has
> been relying heavily on the name attribute. Less so with the lm-sensors
> 3.0.0 rewrite, where most things are automatically detected, but if
> nothing else, giving humans a way to distinguish between the different
> sensor chip types is very useful. Also, not everyone will upgrade to
> lm-sensors 3.0.0 so we need to keep supporting the previous versions.
Another way to handle this is to have the drivers register multiple
times using different names. So LM90 would register as both LM90 and
ADM1032. All the code is shared, you just register it multiple times
under different names.
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* Re: [PATCH 1/5] Implement module aliasing for i2c to translate from device tree names
From: Jean Delvare @ 2008-01-13 18:45 UTC (permalink / raw)
To: Jon Smirl; +Cc: Greg KH, i2c, linux-kernel, linuxppc-dev
In-Reply-To: <9e4733910801131001o604c1474vc2fd021d32b8c2a3@mail.gmail.com>
Hi Jon,
On Sun, 13 Jan 2008 13:01:06 -0500, Jon Smirl wrote:
> On 1/13/08, Jean Delvare wrote:
> > On Sun, 13 Jan 2008 11:24:29 -0500, Jon Smirl wrote:
> > > The kernel automatically exposes modalias as a sysfs attribute so the
> > > string must be recorded further down in the driver support layers. No
> > > need to keep a copy in the i2c structure.
> >
> > Really? I didn't know that. So that's another thing that the i2c
> > subsystem is not doing like the rest of the kernel? Can you please
> > point me to the code that does this?
>
> I never noticed it before either. Just do find | grep modalias in /sys
> and see that every driver has a modalias attribute. It is probably
> implement in drivers/base.
This doesn't mean that the kernel does this automatically! It could
also be that each subsystem does it on its own. Given that the format of
the modalias depends on the bus type, it wouldn't be all that
surprising. Anyway, I'll go look at how the other subsystems handle it
before going on.
> > > Standard devices don't export a 'name' attribute. To see the driver
> > > name for a device in sysfs look at the 'driver' link.
> >
> > The driver name and the device name are different things! The "name"
> > attribute that i2c devices have tells user-space the device name, not
> > the driver name.
>
> For this system my i2c device names are:
> 0-0050 0-0051 0-0052 0-0053
These are not device names, these are device bus IDs. They tell you how
to access the devices, but they do not tell you what these devices are.
> How does the name=eeprom attribute interact with this? All four of my
> devices have name=eeprom. What is the name field used for in user
> space?
The eeprom case might be a bit confusing because that i2c driver
supports a single device type, so the driver name is the same as the
device name. Take a look at the hwmon/lm90 driver for a better example:
this device supports 7 different devices. The devices are mostly
compatible so it made sense to have a single driver for them, but they
all differ in some way. For example, the LM90 doesn't support PEC,
while the ADM1032 does. User-space needs to be able to distinguish
between the various types. That's the reason why we export the device
name through sysfs.
Most i2c sensor drivers support several chip types, and libsensors has
been relying heavily on the name attribute. Less so with the lm-sensors
3.0.0 rewrite, where most things are automatically detected, but if
nothing else, giving humans a way to distinguish between the different
sensor chip types is very useful. Also, not everyone will upgrade to
lm-sensors 3.0.0 so we need to keep supporting the previous versions.
--
Jean Delvare
^ permalink raw reply
* Re: [i2c] [PATCH] update module-init-tools to support the i2c subsystem
From: Jon Smirl @ 2008-01-13 18:04 UTC (permalink / raw)
To: Jean Delvare; +Cc: linuxppc-dev, i2c, linux-kernel
In-Reply-To: <20080113184337.5d4cd546@hyperion.delvare>
On 1/13/08, Jean Delvare <khali@linux-fr.org> wrote:
> On Sun, 13 Jan 2008 11:26:07 -0500, Jon Smirl wrote:
> > On 1/13/08, Jean Delvare <khali@linux-fr.org> wrote:
> > > On Sun, 13 Jan 2008 10:14:14 -0500, Jon Smirl wrote:
> > > > On 1/13/08, Jean Delvare <khali@linux-fr.org> wrote:
> > > > > On Mon, 17 Dec 2007 21:39:37 -0500, Jon Smirl wrote:
> > > > > > Follow on to: "Series to add device tree naming to i2c"
> > > > > > Teach module-init-tools about the i2c subsystem.
> > > > >
> > > > > Can you please explain what this patch does and why it is needed?
> > > >
> > > > It generates the entries needed for the user space module tools to
> > > > work with the aliases. For example modprobe/depmod. It is a standard
> > > > part of the kernel module system.
> > >
> > > What entries, where? What can you do after applying your patch that you
> > > couldn't do before?
> >
> > The drivers you are testing with don't depend on other drivers.
>
> They do. I'm testing with the lm90 driver, which depends on the hwmon
> driver. Both load automatically when the underlying i2c-parport driver
> instantiate an "adm1032" i2c device.
I don't know exactly what those modules tables are used for. I just
copied what the other subsystems do. Maybe they are used when you make
an initrd to know which drivers to copy into the image.
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* Re: [PATCH 1/5] Implement module aliasing for i2c to translate from device tree names
From: Jon Smirl @ 2008-01-13 18:01 UTC (permalink / raw)
To: Jean Delvare; +Cc: Greg KH, i2c, linux-kernel, linuxppc-dev
In-Reply-To: <20080113184017.7e3b409f@hyperion.delvare>
On 1/13/08, Jean Delvare <khali@linux-fr.org> wrote:
> On Sun, 13 Jan 2008 11:24:29 -0500, Jon Smirl wrote:
> > On 1/13/08, Jean Delvare wrote:
> > > On Sat, 12 Jan 2008 11:26:34 -0500, Jon Smirl wrote:
> > > > IMHO, driver_name/type should be removed in new style drivers and
> > > > replaced with aliases on all platforms since aliases are the standard
> > > > kernel mechanism.
> > >
> > > I agree. But we can take your aliasing code now (once you have
> > > addressed the issues I raised) and convert the users of driver_name
> > > later; it doesn't have to be done all at once.
> >
> > GregKH, adding a new dynamically loadable subsystem is not something
> > that happens every day, can you check to make sure all of the standard
> > kernels mechanisms are being used? I'm not totally sure how the
> > modalias naming code is supposed to be done. The subsystem core code
> > in these patches needs review.
> >
> > Jean, could you take over the i2c core portion of the patch? That will
> > let you decide exactly how you want the driver_name/name fields to be
> > dealt with. After you get standard naming support into i2c core I'll
> > rework the rest of the patch to use your new code.
>
> Yes, that could be done, and I agree that it will probably be faster
> than iterative review/rework cycles between you and me. I'll free some
> cycles next week for that.
>
> > I don't think driver_name/name fields should be stored in an i2c
> > structure at all. They are redundant with the standard mechanism.
> >
> > The kernel automatically exposes modalias as a sysfs attribute so the
> > string must be recorded further down in the driver support layers. No
> > need to keep a copy in the i2c structure.
>
> Really? I didn't know that. So that's another thing that the i2c
> subsystem is not doing like the rest of the kernel? Can you please
> point me to the code that does this?
I never noticed it before either. Just do find | grep modalias in /sys
and see that every driver has a modalias attribute. It is probably
implement in drivers/base.
>
> > Standard devices don't export a 'name' attribute. To see the driver
> > name for a device in sysfs look at the 'driver' link.
>
> The driver name and the device name are different things! The "name"
> attribute that i2c devices have tells user-space the device name, not
> the driver name.
For this system my i2c device names are:
0-0050 0-0051 0-0052 0-0053
How does the name=eeprom attribute interact with this? All four of my
devices have name=eeprom. What is the name field used for in user
space?
jonsmirl@terra:/sys/bus/i2c/devices/0-0052$ ls
driver eeprom modalias name power subsystem uevent
jonsmirl@terra:/sys/bus/i2c/devices/0-0052$ cat name
eeprom
jonsmirl@terra:/sys/bus/i2c/devices/0-0052$ ls driver -l
lrwxrwxrwx 1 root root 0 2008-01-13 12:46 driver ->
../../../../../../bus/i2c/drivers/eeprom
jonsmirl@terra:/sys/bus/i2c/devices/0-0052$
jonsmirl@terra:/sys/bus/i2c/drivers$ ls
eeprom
jonsmirl@terra:/sys/bus/i2c/drivers$ ls eeprom
0-0050 0-0051 0-0052 0-0053 bind module uevent unbind
>
> You may not like what the i2c subsystem does but you can't ignore its
> history. The name attribute of i2c devices has been there pretty much
> forever and user-space relies on it, thus we can't remove it.
>
> --
> Jean Delvare
>
--
Jon Smirl
jonsmirl@gmail.com
^ 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