Re: [PATCH net-next v4 0/3] can: mscan-mpc5xxx: add support for the Freescale MPC512x
From: Wolfgang Grandegger Date: Thu, 7 Jan 2010 20:43:05 +0100 > This patch series adds support for the MPC512x from Freescale to the > mpc5xxx_can MSCAN driver. It has been tested on a MPC5121 and MPC5200B > board. So are these ready to go or should I wait for another round of review? :-) ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH net-next v4 0/3] can: mscan-mpc5xxx: add support for the Freescale MPC512x
David Miller wrote: > From: Wolfgang Grandegger > Date: Thu, 7 Jan 2010 20:43:05 +0100 > >> This patch series adds support for the MPC512x from Freescale to the >> mpc5xxx_can MSCAN driver. It has been tested on a MPC5121 and MPC5200B >> board. > > So are these ready to go or should I wait for another round > of review? :-) >From my point of view they can go in now, finally. Thanks, Wolfgang. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH net-next v4 0/3] can: mscan-mpc5xxx: add support for the Freescale MPC512x
From: Wolfgang Grandegger Date: Fri, 08 Jan 2010 09:58:58 +0100 > David Miller wrote: >> From: Wolfgang Grandegger >> Date: Thu, 7 Jan 2010 20:43:05 +0100 >> >>> This patch series adds support for the MPC512x from Freescale to the >>> mpc5xxx_can MSCAN driver. It has been tested on a MPC5121 and MPC5200B >>> board. >> >> So are these ready to go or should I wait for another round >> of review? :-) > >>From my point of view they can go in now, finally. Ok, all applied to net-next-2.6, thanks. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: kernel panic on MPC8323 custom board
Scott Wood-2 wrote:
>
> Dario Presti wrote:
>> Hello,
>> I'm working on MPC8323_rdb board whit 1 new flash device S29GL512P
>> instead
>> of original flash devices.
>> the bootloader is u-boot 1.1.6 (I know is too old and I'm going to
>> upgrade
>> it) and the kernel is 2.6.20.
>
> 2.6.20 is also too old. :-)
>
>> I did this modification to the bootloader to support new flash:
>>
>> 1)I modified the board/mpc8323rdb/config.mk file to set TEXT_BASE from
>> 0xFE00 TO 0xFC00
>> 2)I modified the file /include/configs/MPC8323RDB.h:
>>
>> #define CFG_FLASH_BASE 0xFC00 /* FLASH base address
>> */
>> #define CFG_FLASH_SIZE 64 /* FLASH size is 64M */
>> #define CFG_LBLAWBAR0_PRELIM CFG_FLASH_BASE /* Window base at flash base
>> */
>> #define CFG_LBLAWAR0_PRELIM 0x8019 /* 64MB window size */
>> #define CFG_OR0_PRELIM 0xfc006ff7 /* 64MB Flash size */
>> #define CFG_MAX_FLASH_BANKS 1 /* number of banks */
>> #define CFG_MAX_FLASH_SECT 512 /* sectors per device */
>>
>> 3)I modify and recompiled .dts file
>>
>> fl...@fc00 {
>> device_type = "jedec-flash";
>> compatible = "direct-mapped";
>> probe-type = "CFI";
>> reg = <0xfc00 0x100>;
>> bank-width = <0x2>;
>> partitions = <0x0 0x80001 0x8 0x2 0xa 0x18
>> 0x22
>> 0xde>;
>> partition-names = "U-Boot", "dtb", "Kernel", "rootfs";
>> };
>>
>> but the kernel find the flash at 0xFE00 and the boot stop because
>> kernel
>> panic. The log is:
>
> Is the kernel even using that node, or some other means to determine the
> flash location? The "MPC8323RDB Flash Bank 1" messages make me think
> you've got a custom flash map driver.
>
> -Scott
> ___
> Linuxppc-dev mailing list
> Linuxppc-dev@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev
>
>
Thanks Scott,
I did not find where the custom map flash driver is in the kernel source,
where it is?
How can I say to the kernel to use device tree instead of custom map of
flash?
Regards
Dario
--
View this message in context:
http://old.nabble.com/kernel-panic-on-MPC8323-custom-board-tp27059752p27073289.html
Sent from the linuxppc-dev mailing list archive at Nabble.com.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Any patch for MTD_FSL_UPM_NAND with OF_GPIO
Hi I am using linux-2.6.26.8 kernel. In drivers/mtd/nand/Kconfig, MTD_NAND_FSL_UPM depends on MTD_NAND && OF_GPIO && (PPC_83xx || PPC_85xx). But I didnt find any way to select OF_GPIO option in "make menuconfig". So I removed it from Kconfig file and got MTD_NAND_FSL_UPM in menuconfig. I selected it and did "make uImage". This is giving few errors: include/asm-generic/gpio.h: In function 'gpio_get_value_cansleep': include/asm-generic/gpio.h:135: error: implicit declaration of function 'gpio_get_value' include/asm-generic/gpio.h: In function 'gpio_set_value_cansleep': include/asm-generic/gpio.h:141: error: implicit declaration of function 'gpio_set_value' In file included from drivers/mtd/nand/fsl_upm.c:21: include/linux/of_gpio.h: At top level: include/linux/of_gpio.h:26: error: field 'gc' has incomplete type include/linux/of_gpio.h: In function 'to_of_gpio_chip': include/linux/of_gpio.h:34: warning: type defaults to 'int' in declaration of '__mptr' include/linux/of_gpio.h:34: warning: initialization from incompatible pointer type drivers/mtd/nand/fsl_upm.c: In function 'fun_probe': drivers/mtd/nand/fsl_upm.c:203: error: implicit declaration of function 'gpio_request' drivers/mtd/nand/fsl_upm.c:208: error: implicit declaration of function 'gpio_direction_input' drivers/mtd/nand/fsl_upm.c:242: error: implicit declaration of function 'gpio_free' make[3]: *** [drivers/mtd/nand/fsl_upm.o] Error 1 make[2]: *** [drivers/mtd/nand] Error 2 make[1]: *** [drivers/mtd] Error 2 make: *** [drivers] Error 2 I am suspection that some gpio lib is missing. So any patch is there to this problem?? Regards Koteswar ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] 8xx: fix user space TLB walk in dcbX fixup
The newly added fixup for buggy dcbX insn's has a bug that always trigger a kernel TLB walk so a user space dcbX insn will cause a Kernel Machine Check if it hits DTLB error. Signed-off-by: Joakim Tjernlund --- I found this problem in 2.4 and forward ported it to 2.6. I cannot test it so I cannot be 100% sure I got it right. arch/powerpc/kernel/head_8xx.S |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/arch/powerpc/kernel/head_8xx.S b/arch/powerpc/kernel/head_8xx.S index ce327c5..91bef6e 100644 --- a/arch/powerpc/kernel/head_8xx.S +++ b/arch/powerpc/kernel/head_8xx.S @@ -542,11 +542,11 @@ DARFixed:/* Return from dcbx instruction bug workaround, r10 holds value of DAR FixupDAR:/* Entry point for dcbx workaround. */ /* fetch instruction from memory. */ mfspr r10, SPRN_SRR0 + andis. r11, r10, 0x8000/* Address >= 0x8000 */ DO_8xx_CPU6(0x3780, r3) mtspr SPRN_MD_EPN, r10 mfspr r11, SPRN_M_TWB /* Get level 1 table entry address */ - cmplwi cr0, r11, 0x0800 - blt-3f /* Branch if user space */ + beq-3f /* Branch if user space */ lis r11, (swapper_pg_dir-PAGE_OFFSET)@h ori r11, r11, (swapper_pg_dir-PAGE_OFFSET)@l rlwimi r11, r10, 32-20, 0xffc /* r11 = r11&~0xffc|(r10>>20)&0xffc */ -- 1.6.4.4 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: kernel panic on MPC8323 custom board
Dario Presti wrote: Thanks Scott, I did not find where the custom map flash driver is in the kernel source, where it is? Grep your kernel tree for "MPC8323RDB Flash". How can I say to the kernel to use device tree instead of custom map of flash? Turn off that mapping driver, and turn on CONFIG_MTD_PHYSMAP_OF. This stuff was very new in 2.6.20, though, so there may be issues. I'd upgrade if you can. -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: "status" property checks
On Thu, 2010-01-07 at 20:35 -0600, Hunter Cobbs wrote: > I think that is definitely a solution. It does centralize the testing > for this particular issue. The only thing question I have is if its > really better to have the upper level do the check. Shouldn't the > driver itself handle the hardware and device node status? Practically speaking, all drivers doing the checks today just return -ENODEV. They don't try to do anything to "handle" the situation. The definition of the status property implies it's outside of software's control, for example: "disabled" "Indicates that the device is not presently operational, but it might become operational in the future (for example, something is not plugged in, or switched off)." If a device is "not operational" in this sense, I don't think there's anything for a device driver to do. -- Hollis Blanchard Mentor Graphics, Embedded Systems Division > On Thu, 2010-01-07 at 15:07 -0800, Hollis Blanchard wrote: > > Right now, a number of drivers honor the "status" property on device > > nodes (via of_device_is_available() checks), but it's open-coded in each > > driver. I'm thinking of "hiding" arbitrary devices from the kernel, and > > setting this property seems like the best approach, but at the moment > > that would require modifying all OF drivers to check for it. > > > > Wouldn't the better approach be to have of_platform_device_probe() > > itself do the check, and not call the driver's probe() routine if the > > device isn't available? > > > > ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 1/2] pmac-zilog: add platform driver
On Sat, Jan 2, 2010 at 17:39, Finn Thain wrote:
> On Sat, 2 Jan 2010, Geert Uytterhoeven wrote:
>> On Tue, Nov 17, 2009 at 10:04, Finn Thain wrote:
>> BTW, there are a few other minor checkpatch issues with some of the
>> other patches in the series, too.
>
> I ran checkpatch on all those patches before I submitted them. I ignored
> some of the complaints about whitespace where I felt that checkpatch got
> it wrong (space character following tab character, IIRC).
>
> checkpatch found lots of mistakes that I did fix, but it can't determine
> the most human readable style in all cases, especially where consistency
> with the surrounding code is actually more conducive to readability than
> strict but sporadic conformance to simple rules would be.
It seems your editor adds spaces to lines that are continuations of
the previous statement.
I fixes them up and applied all your patches to linux-m68k.git.
The other warnings were indeed false positives or complains about
keeping consistency
with the surrounding code.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: "status" property checks
Hollis Blanchard wrote: On Thu, 2010-01-07 at 20:35 -0600, Hunter Cobbs wrote: I think that is definitely a solution. It does centralize the testing for this particular issue. The only thing question I have is if its really better to have the upper level do the check. Shouldn't the driver itself handle the hardware and device node status? Practically speaking, all drivers doing the checks today just return -ENODEV. They don't try to do anything to "handle" the situation. The definition of the status property implies it's outside of software's control, for example: "disabled" "Indicates that the device is not presently operational, but it might become operational in the future (for example, something is not plugged in, or switched off)." If a device is "not operational" in this sense, I don't think there's anything for a device driver to do. I could see situations where there is some software action that could enable the device (e.g. multiple devices sharing pins, where only one can be active at a time) -- but it's likely to not be the driver itself that knows how to do that. If the need arises, there could be a mechanism where the enabling entity can tell the platform bus that it has enabled a previously-disabled device, overriding the status in the device tree (and likewise if it wants take down a device that was previously enabled). -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: "status" property checks
On Fri, 2010-01-08 at 13:28 -0600, Scott Wood wrote: > Hollis Blanchard wrote: > > On Thu, 2010-01-07 at 20:35 -0600, Hunter Cobbs wrote: > >> I think that is definitely a solution. It does centralize the testing > >> for this particular issue. The only thing question I have is if its > >> really better to have the upper level do the check. Shouldn't the > >> driver itself handle the hardware and device node status? > > > > Practically speaking, all drivers doing the checks today just return > > -ENODEV. They don't try to do anything to "handle" the situation. > > > > The definition of the status property implies it's outside of software's > > control, for example: > > "disabled" > > "Indicates that the device is not presently operational, but it > > might become operational in the future (for example, something > > is not plugged in, or switched off)." > > > > If a device is "not operational" in this sense, I don't think there's > > anything for a device driver to do. > > I could see situations where there is some software action that could > enable the device (e.g. multiple devices sharing pins, where only one > can be active at a time) -- but it's likely to not be the driver itself > that knows how to do that. > > If the need arises, there could be a mechanism where the enabling entity > can tell the platform bus that it has enabled a previously-disabled > device, overriding the status in the device tree (and likewise if it > wants take down a device that was previously enabled). OK, that makes sense to me. I'll put together a patch for the original idea, and the enable/disable part can come later as needed. -- Hollis Blanchard Mentor Graphics, Embedded Systems Division ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] serial/mpc52xx_uart: Drop outdated comments
Most things mentioned are either obsolete (platform-support) or wrong (device numbering, DCD spport) these days. The remaining rest is obvious. Signed-off-by: Wolfram Sang Cc: Grant Likely --- drivers/serial/mpc52xx_uart.c | 33 - 1 files changed, 0 insertions(+), 33 deletions(-) diff --git a/drivers/serial/mpc52xx_uart.c b/drivers/serial/mpc52xx_uart.c index 7ce9e9f..c7ec1a2 100644 --- a/drivers/serial/mpc52xx_uart.c +++ b/drivers/serial/mpc52xx_uart.c @@ -29,39 +29,6 @@ * kind, whether express or implied. */ -/* Platform device Usage : - * - * Since PSCs can have multiple function, the correct driver for each one - * is selected by calling mpc52xx_match_psc_function(...). The function - * handled by this driver is "uart". - * - * The driver init all necessary registers to place the PSC in uart mode without - * DCD. However, the pin multiplexing aren't changed and should be set either - * by the bootloader or in the platform init code. - * - * The idx field must be equal to the PSC index (e.g. 0 for PSC1, 1 for PSC2, - * and so on). So the PSC1 is mapped to /dev/ttyPSC0, PSC2 to /dev/ttyPSC1 and - * so on. But be warned, it's an ABSOLUTE REQUIREMENT ! This is needed mainly - * fpr the console code : without this 1:1 mapping, at early boot time, when we - * are parsing the kernel args console=ttyPSC?, we wouldn't know which PSC it - * will be mapped to. - */ - -/* OF Platform device Usage : - * - * This driver is only used for PSCs configured in uart mode. The device - * tree will have a node for each PSC with "mpc52xx-psc-uart" in the compatible - * list. - * - * By default, PSC devices are enumerated in the order they are found. However - * a particular PSC number can be forces by adding 'device_no = ' - * to the device node. - * - * The driver init all necessary registers to place the PSC in uart mode without - * DCD. However, the pin multiplexing aren't changed and should be set either - * by the bootloader or in the platform init code. - */ - #undef DEBUG #include -- 1.6.5 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: "status" property checks
On Fri, Jan 08, 2010 at 11:45:28AM -0800, Hollis Blanchard wrote: > On Fri, 2010-01-08 at 13:28 -0600, Scott Wood wrote: > > Hollis Blanchard wrote: > > > On Thu, 2010-01-07 at 20:35 -0600, Hunter Cobbs wrote: > > >> I think that is definitely a solution. It does centralize the testing > > >> for this particular issue. The only thing question I have is if its > > >> really better to have the upper level do the check. Shouldn't the > > >> driver itself handle the hardware and device node status? > > > > > > Practically speaking, all drivers doing the checks today just return > > > -ENODEV. They don't try to do anything to "handle" the situation. > > > > > > The definition of the status property implies it's outside of software's > > > control, for example: > > > "disabled" > > > "Indicates that the device is not presently operational, but it > > > might become operational in the future (for example, something > > > is not plugged in, or switched off)." > > > > > > If a device is "not operational" in this sense, I don't think there's > > > anything for a device driver to do. > > > > I could see situations where there is some software action that could > > enable the device (e.g. multiple devices sharing pins, where only one > > can be active at a time) -- but it's likely to not be the driver itself > > that knows how to do that. > > > > If the need arises, there could be a mechanism where the enabling entity > > can tell the platform bus that it has enabled a previously-disabled > > device, overriding the status in the device tree (and likewise if it > > wants take down a device that was previously enabled). > > OK, that makes sense to me. I'll put together a patch for the original > idea, and the enable/disable part can come later as needed. Sounds good to me to. Only thing I'd add, is that I'd also suggest a helper function to do an explicit check on the status property (or do we have that already?). This could be useful for drivers which are bound primarily to one device tree node, but also need to (possibly optionally) check/use some other node. -- 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 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: "status" property checks
On Sat, 2010-01-09 at 10:46 +1100, David Gibson wrote: > On Fri, Jan 08, 2010 at 11:45:28AM -0800, Hollis Blanchard wrote: > > On Fri, 2010-01-08 at 13:28 -0600, Scott Wood wrote: > > > Hollis Blanchard wrote: > > > > On Thu, 2010-01-07 at 20:35 -0600, Hunter Cobbs wrote: > > > >> I think that is definitely a solution. It does centralize the testing > > > >> for this particular issue. The only thing question I have is if its > > > >> really better to have the upper level do the check. Shouldn't the > > > >> driver itself handle the hardware and device node status? > > > > > > > > Practically speaking, all drivers doing the checks today just return > > > > -ENODEV. They don't try to do anything to "handle" the situation. > > > > > > > > The definition of the status property implies it's outside of software's > > > > control, for example: > > > > "disabled" > > > > "Indicates that the device is not presently operational, but it > > > > might become operational in the future (for example, something > > > > is not plugged in, or switched off)." > > > > > > > > If a device is "not operational" in this sense, I don't think there's > > > > anything for a device driver to do. > > > > > > I could see situations where there is some software action that could > > > enable the device (e.g. multiple devices sharing pins, where only one > > > can be active at a time) -- but it's likely to not be the driver itself > > > that knows how to do that. > > > > > > If the need arises, there could be a mechanism where the enabling entity > > > can tell the platform bus that it has enabled a previously-disabled > > > device, overriding the status in the device tree (and likewise if it > > > wants take down a device that was previously enabled). > > > > OK, that makes sense to me. I'll put together a patch for the original > > idea, and the enable/disable part can come later as needed. > > Sounds good to me to. Only thing I'd add, is that I'd also suggest a > helper function to do an explicit check on the status property (or do > we have that already?). This could be useful for drivers which are > bound primarily to one device tree node, but also need to (possibly > optionally) check/use some other node. of_device_is_available() exists and is used already, so I think we're OK there. -- Hollis Blanchard Mentor Graphics, Embedded Systems Division ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 1/2] pmac-zilog: add platform driver
On Fri, 8 Jan 2010, Geert Uytterhoeven wrote:
> On Sat, Jan 2, 2010 at 17:39, Finn Thain
> wrote:
> > On Sat, 2 Jan 2010, Geert Uytterhoeven wrote:
> >> On Tue, Nov 17, 2009 at 10:04, Finn Thain
> >> wrote: BTW, there are a few other minor
> >> checkpatch issues with some of the other patches in the series, too.
> >
> > I ran checkpatch on all those patches before I submitted them. I
> > ignored some of the complaints about whitespace where I felt that
> > checkpatch got it wrong (space character following tab character,
> > IIRC).
> >
> > checkpatch found lots of mistakes that I did fix, but it can't
> > determine the most human readable style in all cases, especially where
> > consistency with the surrounding code is actually more conducive to
> > readability than strict but sporadic conformance to simple rules would
> > be.
>
> It seems your editor adds spaces to lines that are continuations of the
> previous statement.
I put in spaces after tabs for hard wrapped lines so that code always
renders properly regardless of the tab settings that might to be applied
by any editor, browser, word processor, mailer, tty discipline, publisher,
etc. that might stand between the human reader and the code.
Documentation/CodingStyle says that those indented lines should be
"substantially to the right", but checkpatch doesn't conform and nor does
most kernel code. Some code does follow my preference, which is more
readable, and also happens to follow the example of the lisp code found in
the same style guide.
But if you prefer no spaces after tabs, I can do that instead. I'm not
fussed.
> I fixes them up and applied all your patches to linux-m68k.git.
Thanks. I'll resend the patch to address your comments earlier in the
thread.
Finn
> The other warnings were indeed false positives or complains about
> keeping consistency
> with the surrounding code.
>
> Gr{oetje,eeting}s,
>
> Geert
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
