* Re: [PATCH 1/2] pmac-zilog: add platform driver
From: Geert Uytterhoeven @ 2010-01-07 21:05 UTC (permalink / raw)
To: Finn Thain; +Cc: linux-m68k, linuxppc-dev
In-Reply-To: <alpine.OSX.2.00.1001030255060.414@localhost>
On Sat, Jan 2, 2010 at 17:39, Finn Thain <fthain@telegraphics.com.au> wrote=
:
> On Sat, 2 Jan 2010, Geert Uytterhoeven wrote:
>> On Tue, Nov 17, 2009 at 10:04, Finn Thain <fthain@telegraphics.com.au>
>> wrote:
>> > Add platform driver to the pmac-zilog driver for mac 68k, putting the
>> > powermac-specific bits inside #ifdef CONFIG_PPC_PMAC.
>>
>> > --- linux-2.6.31.orig/drivers/serial/pmac_zilog.c =C2=A0 =C2=A0 =C2=A0=
2009-11-17 17:07:28.000000000 +1100
>> > +++ linux-2.6.31/drivers/serial/pmac_zilog.c =C2=A0 =C2=A02009-11-17 1=
7:07:38.000000000 +1100
>>
>> > @@ -1427,6 +1439,8 @@ static struct uart_ops pmz_pops =3D {
>> > =C2=A0#endif
>> > =C2=A0};
>> >
>> > +#ifdef CONFIG_PPC_PMAC
>> > +
>> > =C2=A0/*
>> > =C2=A0* Setup one port structure after probing, HW is down at this poi=
nt,
>> > =C2=A0* Unlike sunzilog, we don't need to pre-init the spinlock as we =
don't
>> > @@ -1823,6 +1837,88 @@ next:
>> > =C2=A0 =C2=A0 =C2=A0 =C2=A0return 0;
>> > =C2=A0}
>> >
>> > +#else
>> > +
>> > +extern struct platform_device scc_a_pdev, scc_b_pdev;
>>
>> scripts/checkpatch.pl doesn't like this extern, and it's right.
>> Can't this be found using standard platform device/driver matching?
>
> The console initcall and arch initcall order didn't permit me to easily
> gather the bootinfo data and populate the platform device resources early
> enough. (On powermacs there is the open firmware device tree, but of
> course, we don't have one.)
>
> I would like to further adopt the driver model in order to ditch the
> macintosh_config global, and I'd also like to have proper nubus device
> matching. But I think that the serial console device is a bit exceptional
> so I'm not too fussed about these two globals.
OK
> Anyway, I don't know of a better way to do the serial console but I'm ope=
n
> to suggestions.
>
>> 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.
Sure. I thought I saw a few other, but I'll fix them up myself.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k=
.org
In personal conversations with technical people, I call myself a hacker. Bu=
t
when I'm talking to journalists I just say "programmer" or something like t=
hat.
-- Linus Torvalds
^ permalink raw reply
* Re: [PATCH 1/2] pmac-zilog: add platform driver
From: Geert Uytterhoeven @ 2010-01-07 21:12 UTC (permalink / raw)
To: Finn Thain; +Cc: linux-m68k, linuxppc-dev
In-Reply-To: <alpine.OSX.2.00.0911171657290.371@silk.local>
On Tue, Nov 17, 2009 at 10:04, Finn Thain <fthain@telegraphics.com.au> wrot=
e:
> Add platform driver to the pmac-zilog driver for mac 68k, putting the
> powermac-specific bits inside #ifdef CONFIG_PPC_PMAC.
> --- linux-2.6.31.orig/drivers/serial/pmac_zilog.c =C2=A0 =C2=A0 =C2=A0 20=
09-11-17 17:07:28.000000000 +1100
> +++ linux-2.6.31/drivers/serial/pmac_zilog.c =C2=A0 =C2=A02009-11-17 17:0=
7:38.000000000 +1100
> +static int pmz_attach(struct platform_device *pdev)
__devinit (or __init, see platform_driver_probe() below)
BTW, the same is true for the PowerMac version.
> +{
> + =C2=A0 =C2=A0 =C2=A0 int i;
> +
> + =C2=A0 =C2=A0 =C2=A0 for (i =3D 0; i < pmz_ports_count; i++)
> + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 if (pmz_ports[i].node =
=3D=3D pdev)
> + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 return 0;
> + =C2=A0 =C2=A0 =C2=A0 return -ENODEV;
> +}
> +
> +static int pmz_detach(struct platform_device *pdev)
__devexit (or __exit, see platform_driver_probe() below)
Idem ditto for PowerMac.
> +{
> + =C2=A0 =C2=A0 =C2=A0 return 0;
> +}
> +
> +#endif /* !CONFIG_PPC_PMAC */
> +static struct platform_driver pmz_driver =3D {
> + =C2=A0 =C2=A0 =C2=A0 .probe =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=3D pmz_a=
ttach,
> + =C2=A0 =C2=A0 =C2=A0 .remove =C2=A0 =C2=A0 =C2=A0 =C2=A0 =3D __devexit_=
p(pmz_detach),
> + =C2=A0 =C2=A0 =C2=A0 .driver =C2=A0 =C2=A0 =C2=A0 =C2=A0 =3D {
> + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 .name =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =3D "scc",
> + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 .owner =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0=3D THIS_MODULE,
> + =C2=A0 =C2=A0 =C2=A0 },
> +};
> +
> +#endif /* !CONFIG_PPC_PMAC */
> +
> =C2=A0static int __init init_pmz(void)
> =C2=A0{
> =C2=A0 =C2=A0 =C2=A0 =C2=A0int rc, i;
> @@ -1942,15 +2053,23 @@ static int __init init_pmz(void)
> =C2=A0 =C2=A0 =C2=A0 =C2=A0/*
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 * Then we register the macio driver itself
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 */
> +#ifdef CONFIG_PPC_PMAC
> =C2=A0 =C2=A0 =C2=A0 =C2=A0return macio_register_driver(&pmz_driver);
> +#else
> + =C2=A0 =C2=A0 =C2=A0 return platform_driver_register(&pmz_driver);
Since this device is not hot-pluggable, you could use
platform_driver_probe() instead (and leave pmz_driver.probe() empty).
> --- linux-2.6.31.orig/drivers/serial/pmac_zilog.h =C2=A0 =C2=A0 =C2=A0 20=
09-11-17 17:07:28.000000000 +1100
> +++ linux-2.6.31/drivers/serial/pmac_zilog.h =C2=A0 =C2=A02009-11-17 17:0=
7:38.000000000 +1100
> @@ -1,7 +1,15 @@
> =C2=A0#ifndef __PMAC_ZILOG_H__
> =C2=A0#define __PMAC_ZILOG_H__
>
> +#ifdef CONFIG_PPC_PMAC
> =C2=A0#define pmz_debug(fmt, arg...) dev_dbg(&uap->dev->ofdev.dev, fmt, #=
# arg)
> +#define pmz_error(fmt, arg...) dev_err(&uap->dev->ofdev.dev, fmt, ## arg=
)
> +#define pmz_info(fmt, arg...) =C2=A0dev_info(&uap->dev->ofdev.dev, fmt, =
## arg)
> +#else
> +#define pmz_debug(fmt, arg...) do { } while (0)
> +#define pmz_error(fmt, arg...) printk(KERN_ERR fmt, ## arg)
> +#define pmz_info(fmt, arg...) =C2=A0printk(KERN_INFO fmt, ## arg)
Any chance you can sneak the platform device in and use dev_*()?
Anyway, I'm gonna take it, and feed it upstream if BenH adds his ack. Ben?
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k=
.org
In personal conversations with technical people, I call myself a hacker. Bu=
t
when I'm talking to journalists I just say "programmer" or something like t=
hat.
-- Linus Torvalds
^ permalink raw reply
* "status" property checks
From: Hollis Blanchard @ 2010-01-07 23:07 UTC (permalink / raw)
To: devicetree-discuss; +Cc: linuxppc-dev
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?
--=20
Hollis Blanchard
Mentor Graphics, Embedded Systems Division
^ permalink raw reply
* Re: "status" property checks
From: Hunter Cobbs @ 2010-01-08 2:35 UTC (permalink / raw)
To: Hollis Blanchard; +Cc: devicetree-discuss, linuxppc-dev
In-Reply-To: <1262905673.11702.16.camel@localhost.localdomain>
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?
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?
>
^ permalink raw reply
* Re: [PATCH] Re: ZILOG serial port broken in 2.6.32
From: Benjamin Herrenschmidt @ 2010-01-08 3:00 UTC (permalink / raw)
To: Rob Landley; +Cc: paulus, linuxppc-dev
In-Reply-To: <200912080642.52103.rob@landley.net>
> Ok, here's the fix. It's not the _right_ fix, but it Works For Me (tm) and I'll
> leave it to you guys to figure out what this _means_:
I've failed to reproduce so far on both a Wallstreet powerbook (similar
generation and chipset as your beige G3) and a G5 with an added serial
port using current upstream...
Can you verify it's still there ? I might be able to reproduce on a
Beige G3 as well next week.
Cheers,
Ben.
> Signed-off-by: Rob Landley <rob@landley.net>
>
> diff -ru build/packages/linux/drivers/serial/serial_core.c build/packages/linux2/drivers/serial/serial_core.c
> --- build/packages/linux/drivers/serial/serial_core.c 2009-12-02 21:51:21.000000000 -0600
> +++ build/packages/linux2/drivers/serial/serial_core.c 2009-12-08 06:17:06.000000000 -0600
> @@ -113,7 +113,7 @@
> static void uart_tasklet_action(unsigned long data)
> {
> struct uart_state *state = (struct uart_state *)data;
> - tty_wakeup(state->port.tty);
> + if (state->port.tty) tty_wakeup(state->port.tty);
> }
>
> static inline void
>
> That one line workaround makes the panic go away, and things seem to work fine from there.
>
> I note that pmac_zilog.c function pmz_receiv_chars() has the following chunk:
>
> /* Sanity check, make sure the old bug is no longer happening */
> if (uap->port.state == NULL || uap->port.state->port.tty == NULL) {
> WARN_ON(1);
> (void)read_zsdata(uap);
> return NULL;
> }
>
> Which doesn't catch this because it's the write code path (not the read code path) that's running into
> this.
>
> Rob
^ permalink raw reply
* Any patch for MTD_FSL_UPM_NAND with OF_GPIO
From: Koteswar @ 2010-01-08 6:42 UTC (permalink / raw)
To: linuxppc-dev
[-- Attachment #1: Type: text/plain, Size: 1625 bytes --]
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
[-- Attachment #2: Type: text/html, Size: 1862 bytes --]
^ permalink raw reply
* Re: [PATCH net-next v4 0/3] can: mscan-mpc5xxx: add support for the Freescale MPC512x
From: David Miller @ 2010-01-08 8:41 UTC (permalink / raw)
To: wg; +Cc: Socketcan-core, Netdev, Devicetree-discuss, Linuxppc-dev
In-Reply-To: <1262893388-16218-1-git-send-email-wg@grandegger.com>
From: Wolfgang Grandegger <wg@grandegger.com>
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? :-)
^ permalink raw reply
* Re: [PATCH net-next v4 0/3] can: mscan-mpc5xxx: add support for the Freescale MPC512x
From: Wolfgang Grandegger @ 2010-01-08 8:58 UTC (permalink / raw)
To: David Miller; +Cc: Socketcan-core, Netdev, Devicetree-discuss, Linuxppc-dev
In-Reply-To: <20100108.004102.225115986.davem@davemloft.net>
David Miller wrote:
> From: Wolfgang Grandegger <wg@grandegger.com>
> 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.
^ permalink raw reply
* Re: [PATCH net-next v4 0/3] can: mscan-mpc5xxx: add support for the Freescale MPC512x
From: David Miller @ 2010-01-08 9:02 UTC (permalink / raw)
To: wg; +Cc: Socketcan-core, Netdev, Devicetree-discuss, Linuxppc-dev
In-Reply-To: <4B46F3D2.8070102@grandegger.com>
From: Wolfgang Grandegger <wg@grandegger.com>
Date: Fri, 08 Jan 2010 09:58:58 +0100
> David Miller wrote:
>> From: Wolfgang Grandegger <wg@grandegger.com>
>> 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.
^ permalink raw reply
* Re: kernel panic on MPC8323 custom board
From: Dario Presti @ 2010-01-08 9:23 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <4B46209D.5000605@freescale.com>
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
>> 0xFE000000 TO 0xFC000000
>> 2)I modified the file /include/configs/MPC8323RDB.h:
>>
>> #define CFG_FLASH_BASE 0xFC000000 /* 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 0x80000019 /* 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
>>
>> flash@fc000000 {
>> device_type = "jedec-flash";
>> compatible = "direct-mapped";
>> probe-type = "CFI";
>> reg = <0xfc000000 0x1000000>;
>> bank-width = <0x2>;
>> partitions = <0x0 0x80001 0x80000 0x20000 0xa0000 0x180000 0x220000
>> 0xde0000>;
>> partition-names = "U-Boot", "dtb", "Kernel", "rootfs";
>> };
>>
>> but the kernel find the flash at 0xFE000000 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.
^ permalink raw reply
* [PATCH] 8xx: fix user space TLB walk in dcbX fixup
From: Joakim Tjernlund @ 2010-01-08 16:46 UTC (permalink / raw)
To: Benjamin Herrenschmidt, Scott Wood, linuxppc-dev@ozlabs.org,
Rex Feany
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 <Joakim.Tjernlund@transmode.se>
---
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 >= 0x80000000 */
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
^ permalink raw reply related
* Re: kernel panic on MPC8323 custom board
From: Scott Wood @ 2010-01-08 17:26 UTC (permalink / raw)
To: Dario Presti; +Cc: linuxppc-dev
In-Reply-To: <27073289.post@talk.nabble.com>
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
^ permalink raw reply
* Re: "status" property checks
From: Hollis Blanchard @ 2010-01-08 18:34 UTC (permalink / raw)
To: Hunter Cobbs; +Cc: devicetree-discuss, linuxppc-dev
In-Reply-To: <1262918143.2716.8.camel@ccs-laptop>
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.
--=20
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 eac=
h
> > 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.
> >=20
> > 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?
> >=20
>=20
>=20
^ permalink raw reply
* Re: [PATCH 1/2] pmac-zilog: add platform driver
From: Geert Uytterhoeven @ 2010-01-08 19:17 UTC (permalink / raw)
To: Finn Thain; +Cc: linux-m68k, linuxppc-dev
In-Reply-To: <alpine.OSX.2.00.1001030255060.414@localhost>
On Sat, Jan 2, 2010 at 17:39, Finn Thain <fthain@telegraphics.com.au> wrote:
> On Sat, 2 Jan 2010, Geert Uytterhoeven wrote:
>> On Tue, Nov 17, 2009 at 10:04, Finn Thain <fthain@telegraphics.com.au> 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 -- geert@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
^ permalink raw reply
* Re: "status" property checks
From: Scott Wood @ 2010-01-08 19:28 UTC (permalink / raw)
To: Hollis Blanchard; +Cc: Hunter Cobbs, devicetree-discuss, linuxppc-dev
In-Reply-To: <1262975655.31871.67.camel@localhost.localdomain>
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
^ permalink raw reply
* Re: "status" property checks
From: Hollis Blanchard @ 2010-01-08 19:45 UTC (permalink / raw)
To: Scott Wood; +Cc: Hunter Cobbs, devicetree-discuss, linuxppc-dev
In-Reply-To: <4B478747.8070009@freescale.com>
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?
> >=20
> > Practically speaking, all drivers doing the checks today just return
> > -ENODEV. They don't try to do anything to "handle" the situation.
> >=20
> > 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)."
> >=20
> > If a device is "not operational" in this sense, I don't think there's
> > anything for a device driver to do.
>=20
> I could see situations where there is some software action that could=20
> enable the device (e.g. multiple devices sharing pins, where only one=20
> can be active at a time) -- but it's likely to not be the driver itself=20
> that knows how to do that.
>=20
> If the need arises, there could be a mechanism where the enabling entity=20
> can tell the platform bus that it has enabled a previously-disabled=20
> device, overriding the status in the device tree (and likewise if it=20
> 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.
--=20
Hollis Blanchard
Mentor Graphics, Embedded Systems Division
^ permalink raw reply
* [PATCH] serial/mpc52xx_uart: Drop outdated comments
From: Wolfram Sang @ 2010-01-08 21:19 UTC (permalink / raw)
To: linuxppc-dev; +Cc: linux-serial
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 <w.sang@pengutronix.de>
Cc: Grant Likely <grant.likely@secretlab.ca>
---
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 = <port#>'
- * 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 <linux/device.h>
--
1.6.5
^ permalink raw reply related
* Re: "status" property checks
From: David Gibson @ 2010-01-08 23:46 UTC (permalink / raw)
To: Hollis Blanchard
Cc: Scott Wood, Hunter Cobbs, devicetree-discuss, linuxppc-dev
In-Reply-To: <1262979928.31871.81.camel@localhost.localdomain>
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
^ permalink raw reply
* Re: "status" property checks
From: Hollis Blanchard @ 2010-01-08 23:58 UTC (permalink / raw)
To: David Gibson; +Cc: Scott Wood, Hunter Cobbs, devicetree-discuss, linuxppc-dev
In-Reply-To: <20100108234614.GB2661@yookeroo>
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 tes=
ting
> > > >> for this particular issue. The only thing question I have is if i=
ts
> > > >> really better to have the upper level do the check. Shouldn't the
> > > >> driver itself handle the hardware and device node status?
> > > >=20
> > > > Practically speaking, all drivers doing the checks today just retur=
n
> > > > -ENODEV. They don't try to do anything to "handle" the situation.
> > > >=20
> > > > The definition of the status property implies it's outside of softw=
are's
> > > > control, for example:
> > > > "disabled"
> > > > "Indicates that the device is not presently operational, bu=
t it
> > > > might become operational in the future (for example, someth=
ing
> > > > is not plugged in, or switched off)."
> > > >=20
> > > > If a device is "not operational" in this sense, I don't think there=
's
> > > > anything for a device driver to do.
> > >=20
> > > I could see situations where there is some software action that could=
=20
> > > enable the device (e.g. multiple devices sharing pins, where only one=
=20
> > > can be active at a time) -- but it's likely to not be the driver itse=
lf=20
> > > that knows how to do that.
> > >=20
> > > If the need arises, there could be a mechanism where the enabling ent=
ity=20
> > > can tell the platform bus that it has enabled a previously-disabled=20
> > > device, overriding the status in the device tree (and likewise if it=20
> > > wants take down a device that was previously enabled).
> >=20
> > 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.
>=20
> 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.
--=20
Hollis Blanchard
Mentor Graphics, Embedded Systems Division
^ permalink raw reply
* Re: [PATCH 1/2] pmac-zilog: add platform driver
From: fthain @ 2010-01-09 3:14 UTC (permalink / raw)
To: Geert Uytterhoeven; +Cc: linux-m68k, linuxppc-dev
In-Reply-To: <10f740e81001081117s54c5dd9by4cc0490e0c57d67b@mail.gmail.com>
On Fri, 8 Jan 2010, Geert Uytterhoeven wrote:
> On Sat, Jan 2, 2010 at 17:39, Finn Thain <fthain@telegraphics.com.au>
> wrote:
> > On Sat, 2 Jan 2010, Geert Uytterhoeven wrote:
> >> On Tue, Nov 17, 2009 at 10:04, Finn Thain
> >> <fthain@telegraphics.com.au> 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
^ permalink raw reply
* Re: [PATCH] Re: ZILOG serial port broken in 2.6.32
From: Rob Landley @ 2010-01-09 8:17 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: paulus, linuxppc-dev
In-Reply-To: <1262919644.2173.704.camel@pasglop>
On Thursday 07 January 2010 21:00:43 Benjamin Herrenschmidt wrote:
> > Ok, here's the fix. It's not the _right_ fix, but it Works For Me (tm)
> > and I'll leave it to you guys to figure out what this _means_:
>
> I've failed to reproduce so far on both a Wallstreet powerbook (similar
> generation and chipset as your beige G3) and a G5 with an added serial
> port using current upstream...
>
> Can you verify it's still there ? I might be able to reproduce on a
> Beige G3 as well next week.
It's still there on qemu 0.11.0's "g3beige" emulation when you use
CONFIG_SERIAL_PMACZILOG as the serial console. (QEMU 0.10.x used a 16550
serial chip for its g3beige emulation instead of the actual ZILOG one.) Still
dunno if it's a qemu or bug or a kernel bug, I just know that kernel patch
fixes it for me, and it comes back without the patch.
I tested 2.6.32. Haven't tried the 2.6.32.3 but don't see why it would change
this...
Rob
--
Latency is more important than throughput. It's that simple. - Linus Torvalds
^ permalink raw reply
* Re: [PATCH] proc_devtree: fix THIS_MODULE without module.h
From: Alexey Dobriyan @ 2010-01-09 11:01 UTC (permalink / raw)
To: Jeremy Kerr; +Cc: linuxppc-dev
In-Reply-To: <1262830753.577814.127040702434.1.gpush@pororo>
On Thu, Jan 07, 2010 at 01:19:13PM +1100, Jeremy Kerr wrote:
> Commit e22f628395432b967f2f505858c64450f7835365 introduced a build
> breakage for ARM devtree work: the THIS_MODULE macro was added, but we
> don't have module.h
>
> This change adds the necessary #include to get THIS_MODULE defined.
> While we could just replace it with NULL (PROC_FS is a bool, not a
> tristate), using THIS_MODULE will prevent unexpected breakage if we
> ever do compile this as a module.
I'd say, remove .owner line.
It definitely not needed in non-modular code.
> --- a/fs/proc/proc_devtree.c
> +++ b/fs/proc/proc_devtree.c
> @@ -11,6 +11,7 @@
> #include <linux/stat.h>
> #include <linux/string.h>
> #include <linux/of.h>
> +#include <linux/module.h>
^ permalink raw reply
* [PATCH] macintosh: make Open Firmware device id constant
From: Németh Márton @ 2010-01-10 11:43 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev, Julia Lawall, LKML, cocci
From: Márton Németh <nm127@freemail.hu>
The match_table field of the struct of_device_id is constant in <linux/of_platform.h>
so it is worth to make the initialization data also constant.
The semantic match that finds this kind of pattern is as follows:
(http://coccinelle.lip6.fr/)
// <smpl>
@r@
disable decl_init,const_decl_init;
identifier I1, I2, x;
@@
struct I1 {
...
const struct I2 *x;
...
};
@s@
identifier r.I1, y;
identifier r.x, E;
@@
struct I1 y = {
.x = E,
};
@c@
identifier r.I2;
identifier s.E;
@@
const struct I2 E[] = ... ;
@depends on !c@
identifier r.I2;
identifier s.E;
@@
+ const
struct I2 E[] = ...;
// </smpl>
Signed-off-by: Márton Németh <nm127@freemail.hu>
Cc: Julia Lawall <julia@diku.dk>
Cc: cocci@diku.dk
---
diff -u -p a/drivers/macintosh/therm_windtunnel.c b/drivers/macintosh/therm_windtunnel.c
--- a/drivers/macintosh/therm_windtunnel.c 2010-01-07 19:08:40.000000000 +0100
+++ b/drivers/macintosh/therm_windtunnel.c 2010-01-08 04:47:10.000000000 +0100
@@ -457,7 +457,7 @@ therm_of_remove( struct of_device *dev )
return 0;
}
-static struct of_device_id therm_of_match[] = {{
+static const struct of_device_id therm_of_match[] = {{
.name = "fan",
.compatible = "adm1030"
}, {}
diff -u -p a/drivers/macintosh/smu.c b/drivers/macintosh/smu.c
--- a/drivers/macintosh/smu.c 2009-12-03 04:51:21.000000000 +0100
+++ b/drivers/macintosh/smu.c 2010-01-08 04:47:28.000000000 +0100
@@ -660,7 +660,7 @@ static int smu_platform_probe(struct of_
return 0;
}
-static struct of_device_id smu_platform_match[] =
+static const struct of_device_id smu_platform_match[] =
{
{
.type = "smu",
diff -u -p a/drivers/macintosh/therm_pm72.c b/drivers/macintosh/therm_pm72.c
--- a/drivers/macintosh/therm_pm72.c 2009-12-03 04:51:21.000000000 +0100
+++ b/drivers/macintosh/therm_pm72.c 2010-01-08 04:50:17.000000000 +0100
@@ -2211,7 +2211,7 @@ static int fcu_of_remove(struct of_devic
return 0;
}
-static struct of_device_id fcu_match[] =
+static const struct of_device_id fcu_match[] =
{
{
.type = "fcu",
^ permalink raw reply
* [PATCH 1/2] pmac-zilog: add platform driver, version 2
From: fthain @ 2010-01-10 12:48 UTC (permalink / raw)
To: Geert Uytterhoeven; +Cc: linux-m68k, linuxppc-dev
In-Reply-To: <10f740e81001071312p451de3c0r93d8d9d2782abde8@mail.gmail.com>
Add platform driver support to the pmac-zilog driver, for m68k macs.
Place the powermac-specific code inside #ifdef CONFIG_PPC_PMAC.
This patch should be applied after "[PATCH 3/13] pmac-zilog: cleanup".
Signed-off-by: Finn Thain <fthain@telegraphics.com.au>
---
Version 2 of this patch adopts Geert's suggestions: make better use of
dev_{dbg,err,info} macros, change platform_driver_register() to
platform_driver_probe(), and use __init and __exit attributes.
arch/m68k/configs/mac_defconfig | 5 +
arch/m68k/configs/multi_defconfig | 5 +
drivers/serial/Kconfig | 12 +-
drivers/serial/pmac_zilog.c | 158 +++++++++++++++++++++++++++++++++-----
drivers/serial/pmac_zilog.h | 14 +++
5 files changed, 168 insertions(+), 26 deletions(-)
Index: linux-2.6.31/drivers/serial/Kconfig
===================================================================
--- linux-2.6.31.orig/drivers/serial/Kconfig 2010-01-10 13:13:55.000000000 +1100
+++ linux-2.6.31/drivers/serial/Kconfig 2010-01-10 13:14:18.000000000 +1100
@@ -1079,12 +1079,12 @@ config SERIAL_68360
default y
config SERIAL_PMACZILOG
- tristate "PowerMac z85c30 ESCC support"
- depends on PPC_OF && PPC_PMAC
+ tristate "Mac or PowerMac z85c30 ESCC support"
+ depends on (M68K && MAC) || (PPC_OF && PPC_PMAC)
select SERIAL_CORE
help
This driver supports the Zilog z85C30 serial ports found on
- PowerMac machines.
+ (Power)Mac machines.
Say Y or M if you want to be able to these serial ports.
config SERIAL_PMACZILOG_TTYS
@@ -1109,16 +1109,16 @@ config SERIAL_PMACZILOG_TTYS
unable to use the 8250 module for PCMCIA or other 16C550-style
UARTs.
- Say N unless you need the z85c30 ports on your powermac
+ Say N unless you need the z85c30 ports on your (Power)Mac
to appear as /dev/ttySn.
config SERIAL_PMACZILOG_CONSOLE
- bool "Console on PowerMac z85c30 serial port"
+ bool "Console on Mac or PowerMac z85c30 serial port"
depends on SERIAL_PMACZILOG=y
select SERIAL_CORE_CONSOLE
help
If you would like to be able to use the z85c30 serial port
- on your PowerMac as the console, you can do so by answering
+ on your (Power)Mac as the console, you can do so by answering
Y to this option.
config SERIAL_LH7A40X
Index: linux-2.6.31/arch/m68k/configs/mac_defconfig
===================================================================
--- linux-2.6.31.orig/arch/m68k/configs/mac_defconfig 2010-01-10 13:13:55.000000000 +1100
+++ linux-2.6.31/arch/m68k/configs/mac_defconfig 2010-01-10 13:13:57.000000000 +1100
@@ -701,6 +701,11 @@ CONFIG_VT_HW_CONSOLE_BINDING=y
#
# Non-8250 serial port support
#
+CONFIG_SERIAL_CORE=y
+CONFIG_SERIAL_CORE_CONSOLE=y
+CONFIG_SERIAL_PMACZILOG=y
+CONFIG_SERIAL_PMACZILOG_TTYS=y
+CONFIG_SERIAL_PMACZILOG_CONSOLE=y
CONFIG_UNIX98_PTYS=y
# CONFIG_DEVPTS_MULTIPLE_INSTANCES is not set
CONFIG_LEGACY_PTYS=y
Index: linux-2.6.31/arch/m68k/configs/multi_defconfig
===================================================================
--- linux-2.6.31.orig/arch/m68k/configs/multi_defconfig 2010-01-10 13:13:55.000000000 +1100
+++ linux-2.6.31/arch/m68k/configs/multi_defconfig 2010-01-10 13:13:57.000000000 +1100
@@ -822,6 +822,11 @@ CONFIG_A2232=y
#
# Non-8250 serial port support
#
+CONFIG_SERIAL_CORE=y
+CONFIG_SERIAL_CORE_CONSOLE=y
+CONFIG_SERIAL_PMACZILOG=y
+CONFIG_SERIAL_PMACZILOG_TTYS=y
+CONFIG_SERIAL_PMACZILOG_CONSOLE=y
CONFIG_UNIX98_PTYS=y
# CONFIG_DEVPTS_MULTIPLE_INSTANCES is not set
CONFIG_LEGACY_PTYS=y
Index: linux-2.6.31/drivers/serial/pmac_zilog.c
===================================================================
--- linux-2.6.31.orig/drivers/serial/pmac_zilog.c 2010-01-10 13:13:55.000000000 +1100
+++ linux-2.6.31/drivers/serial/pmac_zilog.c 2010-01-10 13:13:57.000000000 +1100
@@ -63,11 +63,18 @@
#include <asm/sections.h>
#include <asm/io.h>
#include <asm/irq.h>
+
+#ifdef CONFIG_PPC_PMAC
#include <asm/prom.h>
#include <asm/machdep.h>
#include <asm/pmac_feature.h>
#include <asm/dbdma.h>
#include <asm/macio.h>
+#else
+#include <linux/platform_device.h>
+#include <asm/macints.h>
+#define machine_is_compatible(x) (0)
+#endif
#if defined (CONFIG_SERIAL_PMACZILOG_CONSOLE) && defined(CONFIG_MAGIC_SYSRQ)
#define SUPPORT_SYSRQ
@@ -83,11 +90,9 @@
static char version[] __initdata = "pmac_zilog: 0.6 (Benjamin Herrenschmidt <benh@kernel.crashing.org>)";
MODULE_AUTHOR("Benjamin Herrenschmidt <benh@kernel.crashing.org>");
-MODULE_DESCRIPTION("Driver for the PowerMac serial ports.");
+MODULE_DESCRIPTION("Driver for the Mac and PowerMac serial ports.");
MODULE_LICENSE("GPL");
-#define PWRDBG(fmt, arg...) printk(KERN_DEBUG fmt , ## arg)
-
#ifdef CONFIG_SERIAL_PMACZILOG_TTYS
#define PMACZILOG_MAJOR TTY_MAJOR
#define PMACZILOG_MINOR 64
@@ -341,7 +346,7 @@ static struct tty_struct *pmz_receive_ch
uap->curregs[R1] &= ~(EXT_INT_ENAB | TxINT_ENAB | RxINT_MASK);
write_zsreg(uap, R1, uap->curregs[R1]);
zssync(uap);
- dev_err(&uap->dev->ofdev.dev, "pmz: rx irq flood !\n");
+ pmz_error("pmz: rx irq flood !\n");
return tty;
}
@@ -746,6 +751,8 @@ static void pmz_break_ctl(struct uart_po
spin_unlock_irqrestore(&port->lock, flags);
}
+#ifdef CONFIG_PPC_PMAC
+
/*
* Turn power on or off to the SCC and associated stuff
* (port drivers, modem, IR port, etc.)
@@ -781,6 +788,15 @@ static int pmz_set_scc_power(struct uart
return delay;
}
+#else
+
+static int pmz_set_scc_power(struct uart_pmac_port *uap, int state)
+{
+ return 0;
+}
+
+#endif /* !CONFIG_PPC_PMAC */
+
/*
* FixZeroBug....Works around a bug in the SCC receving channel.
* Inspired from Darwin code, 15 Sept. 2000 -DanM
@@ -943,9 +959,9 @@ static int pmz_startup(struct uart_port
}
pmz_get_port_A(uap)->flags |= PMACZILOG_FLAG_IS_IRQ_ON;
- if (request_irq(uap->port.irq, pmz_interrupt, IRQF_SHARED, "PowerMac Zilog", uap)) {
- dev_err(&uap->dev->ofdev.dev,
- "Unable to register zs interrupt handler.\n");
+ if (request_irq(uap->port.irq, pmz_interrupt, IRQF_SHARED,
+ "SCC", uap)) {
+ pmz_error("Unable to register zs interrupt handler.\n");
pmz_set_scc_power(uap, 0);
mutex_unlock(&pmz_irq_mutex);
return -ENXIO;
@@ -1185,7 +1201,7 @@ static void pmz_irda_setup(struct uart_p
while ((read_zsreg(uap, R0) & Tx_BUF_EMP) == 0
|| (read_zsreg(uap, R1) & ALL_SNT) == 0) {
if (--t <= 0) {
- dev_err(&uap->dev->ofdev.dev, "transmitter didn't drain\n");
+ pmz_error("transmitter didn't drain\n");
return;
}
udelay(10);
@@ -1201,7 +1217,7 @@ static void pmz_irda_setup(struct uart_p
read_zsdata(uap);
mdelay(10);
if (--t <= 0) {
- dev_err(&uap->dev->ofdev.dev, "receiver didn't drain\n");
+ pmz_error("receiver didn't drain\n");
return;
}
}
@@ -1222,8 +1238,7 @@ static void pmz_irda_setup(struct uart_p
t = 5000;
while ((read_zsreg(uap, R0) & Rx_CH_AV) == 0) {
if (--t <= 0) {
- dev_err(&uap->dev->ofdev.dev,
- "irda_setup timed out on get_version byte\n");
+ pmz_error("irda_setup timed out on get_version byte\n");
goto out;
}
udelay(10);
@@ -1231,8 +1246,7 @@ static void pmz_irda_setup(struct uart_p
version = read_zsdata(uap);
if (version < 4) {
- dev_info(&uap->dev->ofdev.dev, "IrDA: dongle version %d not supported\n",
- version);
+ pmz_info("IrDA: dongle version %d not supported\n", version);
goto out;
}
@@ -1241,19 +1255,17 @@ static void pmz_irda_setup(struct uart_p
t = 5000;
while ((read_zsreg(uap, R0) & Rx_CH_AV) == 0) {
if (--t <= 0) {
- dev_err(&uap->dev->ofdev.dev,
- "irda_setup timed out on speed mode byte\n");
+ pmz_error("irda_setup timed out on speed mode byte\n");
goto out;
}
udelay(10);
}
t = read_zsdata(uap);
if (t != cmdbyte)
- dev_err(&uap->dev->ofdev.dev,
- "irda_setup speed mode byte = %x (%x)\n", t, cmdbyte);
+ pmz_error("irda_setup speed mode byte = %x (%x)\n", t, cmdbyte);
- dev_info(&uap->dev->ofdev.dev, "IrDA setup for %ld bps, dongle version: %d\n",
- *baud, version);
+ pmz_info("IrDA setup for %ld bps, dongle version: %d\n",
+ *baud, version);
(void)read_zsdata(uap);
(void)read_zsdata(uap);
@@ -1402,7 +1414,7 @@ static void pmz_poll_put_char(struct uar
write_zsdata(uap, c);
}
-#endif
+#endif /* CONFIG_CONSOLE_POLL */
static struct uart_ops pmz_pops = {
.tx_empty = pmz_tx_empty,
@@ -1427,6 +1439,8 @@ static struct uart_ops pmz_pops = {
#endif
};
+#ifdef CONFIG_PPC_PMAC
+
/*
* Setup one port structure after probing, HW is down at this point,
* Unlike sunzilog, we don't need to pre-init the spinlock as we don't
@@ -1823,6 +1837,88 @@ next:
return 0;
}
+#else
+
+extern struct platform_device scc_a_pdev, scc_b_pdev;
+
+static int __init pmz_init_port(struct uart_pmac_port *uap)
+{
+ struct resource *r_ports;
+ int irq;
+
+ r_ports = platform_get_resource(uap->node, IORESOURCE_MEM, 0);
+ irq = platform_get_irq(uap->node, 0);
+ if (!r_ports || !irq)
+ return -ENODEV;
+
+ uap->port.mapbase = r_ports->start;
+ uap->port.membase = (unsigned char __iomem *) r_ports->start;
+ uap->port.iotype = UPIO_MEM;
+ uap->port.irq = irq;
+ uap->port.uartclk = ZS_CLOCK;
+ uap->port.fifosize = 1;
+ uap->port.ops = &pmz_pops;
+ uap->port.type = PORT_PMAC_ZILOG;
+ uap->port.flags = 0;
+
+ uap->control_reg = uap->port.membase;
+ uap->data_reg = uap->control_reg + 4;
+ uap->port_type = 0;
+
+ pmz_convert_to_zs(uap, CS8, 0, 9600);
+
+ return 0;
+}
+
+static int __init pmz_probe(void)
+{
+ int err;
+
+ pmz_ports_count = 0;
+
+ pmz_ports[0].mate = &pmz_ports[1];
+ pmz_ports[0].port.line = 0;
+ pmz_ports[0].flags = PMACZILOG_FLAG_IS_CHANNEL_A;
+ pmz_ports[0].node = &scc_a_pdev;
+ err = pmz_init_port(&pmz_ports[0]);
+ if (err)
+ return err;
+ pmz_ports_count++;
+
+ pmz_ports[1].mate = &pmz_ports[0];
+ pmz_ports[1].port.line = 1;
+ pmz_ports[1].flags = 0;
+ pmz_ports[1].node = &scc_b_pdev;
+ err = pmz_init_port(&pmz_ports[1]);
+ if (err)
+ return err;
+ pmz_ports_count++;
+
+ return 0;
+}
+
+static void pmz_dispose_port(struct uart_pmac_port *uap)
+{
+ memset(uap, 0, sizeof(struct uart_pmac_port));
+}
+
+static int __init pmz_attach(struct platform_device *pdev)
+{
+ int i;
+
+ for (i = 0; i < pmz_ports_count; i++)
+ if (pmz_ports[i].node == pdev)
+ return 0;
+ return -ENODEV;
+}
+
+static int __exit pmz_detach(struct platform_device *pdev)
+{
+ return 0;
+}
+
+#endif /* !CONFIG_PPC_PMAC */
+
#ifdef CONFIG_SERIAL_PMACZILOG_CONSOLE
static void pmz_console_write(struct console *con, const char *s, unsigned int count);
@@ -1883,6 +1979,8 @@ err_out:
return rc;
}
+#ifdef CONFIG_PPC_PMAC
+
static struct of_device_id pmz_match[] =
{
{
@@ -1904,6 +2002,18 @@ static struct macio_driver pmz_driver =
.resume = pmz_resume,
};
+#else
+
+static struct platform_driver pmz_driver = {
+ .remove = __exit_p(pmz_detach),
+ .driver = {
+ .name = "scc",
+ .owner = THIS_MODULE,
+ },
+};
+
+#endif /* !CONFIG_PPC_PMAC */
+
static int __init init_pmz(void)
{
int rc, i;
@@ -1942,15 +2052,23 @@ static int __init init_pmz(void)
/*
* Then we register the macio driver itself
*/
+#ifdef CONFIG_PPC_PMAC
return macio_register_driver(&pmz_driver);
+#else
+ return platform_driver_probe(&pmz_driver, pmz_attach);
+#endif
}
static void __exit exit_pmz(void)
{
int i;
+#ifdef CONFIG_PPC_PMAC
/* Get rid of macio-driver (detach from macio) */
macio_unregister_driver(&pmz_driver);
+#else
+ platform_driver_unregister(&pmz_driver);
+#endif
for (i = 0; i < pmz_ports_count; i++) {
struct uart_pmac_port *uport = &pmz_ports[i];
Index: linux-2.6.31/drivers/serial/pmac_zilog.h
===================================================================
--- linux-2.6.31.orig/drivers/serial/pmac_zilog.h 2010-01-10 13:13:55.000000000 +1100
+++ linux-2.6.31/drivers/serial/pmac_zilog.h 2010-01-10 13:13:57.000000000 +1100
@@ -1,7 +1,15 @@
#ifndef __PMAC_ZILOG_H__
#define __PMAC_ZILOG_H__
+#ifdef CONFIG_PPC_PMAC
#define pmz_debug(fmt, arg...) dev_dbg(&uap->dev->ofdev.dev, fmt, ## arg)
+#define pmz_error(fmt, arg...) dev_err(&uap->dev->ofdev.dev, fmt, ## arg)
+#define pmz_info(fmt, arg...) dev_info(&uap->dev->ofdev.dev, fmt, ## arg)
+#else
+#define pmz_debug(fmt, arg...) dev_dbg(&uap->node->dev, fmt, ## arg)
+#define pmz_error(fmt, arg...) dev_err(&uap->node->dev, fmt, ## arg)
+#define pmz_info(fmt, arg...) dev_info(&uap->node->dev, fmt, ## arg)
+#endif
/*
* At most 2 ESCCs with 2 ports each
@@ -17,6 +25,7 @@ struct uart_pmac_port {
struct uart_port port;
struct uart_pmac_port *mate;
+#ifdef CONFIG_PPC_PMAC
/* macio_dev for the escc holding this port (maybe be null on
* early inited port)
*/
@@ -25,6 +34,9 @@ struct uart_pmac_port {
* of "escc" node (ie. ch-a or ch-b)
*/
struct device_node *node;
+#else
+ struct platform_device *node;
+#endif
/* Port type as obtained from device tree (IRDA, modem, ...) */
int port_type;
@@ -55,10 +67,12 @@ struct uart_pmac_port {
volatile u8 __iomem *control_reg;
volatile u8 __iomem *data_reg;
+#ifdef CONFIG_PPC_PMAC
unsigned int tx_dma_irq;
unsigned int rx_dma_irq;
volatile struct dbdma_regs __iomem *tx_dma_regs;
volatile struct dbdma_regs __iomem *rx_dma_regs;
+#endif
struct ktermios termios_cache;
};
^ permalink raw reply
* Re: PCI-PCI bridge scanning broken on 460EX
From: Felix Radensky @ 2010-01-10 12:56 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev, Stefan Roese, Feng Kan
In-Reply-To: <4B41ADF1.1000400@embedded-sol.com>
Hi, Ben
Felix Radensky wrote:
> Hi, Ben
>
> Adding Feng Kan from AMCC to CC.
>
> Benjamin Herrenschmidt wrote:
>> On Mon, 2009-12-28 at 12:51 +0200, Felix Radensky wrote:
>>
>>> Hi,
>>>
>>> I'm running linux-2.6.33-rc2 on Canyonlands board. When PLX 6254
>>> transparent PCI-PCI
>>> bridge is plugged into PCI slot the kernel simply resets the board
>>> without printing anything
>>> to console. Without PLX bridge kernel boots fine.
>>>
>>
>> Sorry for the late reply...
>>
>
> No need to apologize, I appreciate you help very much.
>
>>
>>> I've tracked down the problem to the following code in
>>> pci_scan_bridge() in drivers/pci/probe.c:
>>>
>>> if (pcibios_assign_all_busses() || broken)
>>> /* Temporarily disable forwarding of the
>>> configuration cycles on all bridges in
>>> this bus segment to avoid possible
>>> conflicts in the second pass between two
>>> bridges programmed with overlapping
>>> bus ranges. */
>>> pci_write_config_dword(dev, PCI_PRIMARY_BUS,
>>> buses & ~0xffffff);
>>>
>>> If test for broken is removed, kernel boots fine, detects the
>>> bridge, but
>>> does not detect the device behind the bridge. The same device plugged
>>> directly into PCI slot is detected correctly.
>>>
>>
>> So we would have a similar mismatch between the initial setup and the
>> kernel... However, I don't quite see yet why the kernel trying to fix
>> it up breaks things, that will need a bit more debugging here...
>>
>> Can you give it a quick try with adding something like :
>>
>> ppc_pci_add_flags(PPC_PCI_REASSIGN_ALL_BUS);
>>
>> Near the end of ppc4xx_pci.c ? It looks like another case of reset
>> not actually resetting bridges (are we not properly doing a fundamental
>> reset ? Stefan what's your take there ?)
>>
>> The above will cause busses to be re-assigned which is risky because it
>> will allow the kernel to assign numbers beyond the limits of what
>> ppc4xx_pci.c supports (see my comments in the thread you quotes).
>>
>> The good thing is that we now have a working fixmap infrastructure, so
>> we could/should just move ppc4xx_pci.c to use that, and just always
>> re-assign busses.
>>
>>
>>> To remind you, tests for broken were added by commit
>>> a1c19894b786f10c76ac40e93c6b5d70c9b946d2,
>>> and were intended to solve device detection problem behind PCI-E
>>> switches, as discussed in this thread:
>>> http://lists.ozlabs.org/pipermail/linuxppc-dev/2008-October/063939.html
>>>
>>
>>
>>> PCI: Probing PCI hardware
>>> pci_bus 0000:00: scanning bus
>>> pci 0000:00:06.0: found [3388:0020] class 000604 header type 01
>>> pci 0000:00:06.0: supports D1 D2
>>> pci 0000:00:06.0: PME# supported from D0 D1 D2 D3hot
>>> pci 0000:00:06.0: PME# disabled
>>> pci_bus 0000:00: fixups for bus
>>> pci 0000:00:06.0: scanning behind bridge, config 000000, pass 0
>>> pci 0000:00:06.0: bus configuration invalid, reconfiguring
>>>
>>
>> Ok so we hit a P2P bridge whose primary, secondary and subordinate bus
>> numbers are all 0, which is clearly unconfigured. I think this is the
>> root complex bridge
>>
>>
>>> pci 0000:00:06.0: scanning behind bridge, config 000000, pass 1
>>>
>>
>> Now this is when the bus should be reconfigured (pass 1). Sadly the code
>> doesn't print much debug.
>>
>> Also from that point, it should renumber things and work...
>>
>>> pci_bus 0000:01: scanning bus
>>>
>>
>> Which it does to some extent. It assigned bus number 1 to it afaik so we
>> now start looking below the RC bridge:
>>
>>
>>> pci 0000:01:06.0: found [3388:0020] class 000604 header type 01
>>>
>>
>> Hrm... class PCI bridge, vendor 3388 device 0020, is that your PLX ?
>> It's not the right vendor ID but maybe that's configurable by our OEM or
>> something...
>>
>
> The bridge and its evaluation board were manufactured by HiNT, later
> purchased by PLX.
> 3388:0020 is HiNT HB6 Universal PCI-PCI bridge in transparent mode.
>
>>
>>> pci 0000:01:06.0: supports D1 D2
>>> pci 0000:01:06.0: PME# supported from D0 D1 D2 D3hot
>>> pci 0000:01:06.0: PME# disabled
>>> pci_bus 0000:01: fixups for bus
>>> pci 0000:00:06.0: PCI bridge to [bus 01-ff]
>>> pci 0000:00:06.0: bridge window [io 0x0000-0x0fff]
>>> pci 0000:00:06.0: bridge window [mem 0x00000000-0x000fffff]
>>> pci 0000:00:06.0: bridge window [mem 0x00000000-0x000fffff 64bit
>>> pref]
>>> pci 0000:01:06.0: scanning behind bridge, config ff0100, pass 0
>>>
>>
>> Allright, that's where it gets interesting. It tries to scan behind the
>> bridge. It gets something it doesn't like. IE, it gets a secondary bus
>> number of 1 (what the heck ? I wonder what your firmware does) which
>> Linux is not happy about and decides to renumber it.
>>
>
> U-boot has problems with this bridge as well, so I had to completely
> disable PCI
> support in u-boot to get linux running.
>>
>>> pci 0000:01:06.0: bus configuration invalid, reconfiguring
>>>
>>
>> Now, that's where Linux should have written 000000 to the register,
>> which is what you commented out.
>>
>>
>>> pci 0000:01:06.0: scanning behind bridge, config ff0100, pass 1
>>> pci_bus 0000:01: bus scan returning with max=01
>>> pci_bus 0000:00: bus scan returning with max=01
>>>
>>
>> Because of that commenting out, it doesn't see the config as 000000 and
>> thus doesn't re-assign a bus number in pass 1, so from there you can't
>> see what's behind the bus.
>>
>> So we have two things here:
>>
>> - It seems like the writing of 000000 to the register in pass 0 is
>> causing your crash. Can you verify that ? IE. Can you verify that it's
>> indeed crashing on this specific statement:
>>
>> pci_write_config_dword(dev, PCI_PRIMARY_BUS,
>> buses & ~0xffffff);
>>
>> When writing to the bridge, and that this seems to be causing a hard
>> reboot of the system ?
>>
>
> Yes, this particular statement causes hard reboot. With original
> broken tests restored
> and writing to bridge commented out the system boots. If writing to
> bridge happens
> I get hard reset.
>
>> It might be useful to ask AMCC how that is possible in HW, ie what kind
>> of signal can be causing that. IE, even if the bridge is causing a PCIe
>> error, that should not cause a reboot ... right ?
>>
>
> Feng, can you please comment on this ?
>> - You can test a quick hack workaround which consists of changing:
>>
>> /* Check if setup is sensible at all */
>> - if (!pass &&
>> - if (1 &&
>> ((buses & 0xff) != bus->number || ((buses >> 8) & 0xff) <=
>> bus->number)) {
>> dev_dbg(&dev->dev, "bus configuration invalid,
>> reconfiguring\n");
>> broken = 1;
>> }
>>
>> In -addition- to your commenting out of the broken test. This will
>> cause the
>> second pass to go through the re-assign code path despite the fact
>> that you
>> have not written 000000 to the bus numbers.
>>
>
> With this change and commented out broken test I still get hard reset.
>
> I didn't try adding ppc_pci_add_flags(PPC_PCI_REASSIGN_ALL_BUS)
> If you still want me to try this, please let me know. Should I leave
> broken
> tests enabled in that case ?
>
> Thanks a lot for your help.
>
> Felix.
I now have a custom board with 460EX and the same PLX bridge, running
2.6.23-rc3
Things look better here, as u-boot is now able to properly detect PLX
and device behind
it, but kernel still has problems. First, I'm still getting hard reset on
pci_write_config_dword(dev, PCI_PRIMARY_BUS,
buses & ~0xffffff);
If this line is removed, PLX is detected twice, see below. I also get
hard reset
if pass test is modified as you requested and broken test removed.
Any ideas how to fix this ? I was suspecting PLX evaluation board, but
PLX on our custom board seems to be OK, so it looks like kernel needs
fixing.
PCI: Probing PCI hardware
pci_bus 0000:00: scanning bus
pci 0000:00:02.0: found [3388:0020] class 000604 header type 01
pci 0000:00:02.0: calling pcibios_fixup_resources+0x0/0xf4
pci 0000:00:02.0: calling fixup_ppc4xx_pci_bridge+0x0/0x154
pci 0000:00:02.0: calling quirk_resource_alignment+0x0/0x200
pci 0000:00:02.0: supports D1 D2
pci 0000:00:02.0: PME# supported from D0 D1 D2 D3hot
pci 0000:00:02.0: PME# disabled
pci_bus 0000:00: fixups for bus
pci 0000:00:02.0: scanning behind bridge, config 010100, pass 0
pci_bus 0000:01: scanning bus
pci 0000:01:02.0: found [3388:0020] class 000604 header type 01
pci 0000:01:02.0: calling pcibios_fixup_resources+0x0/0xf4
pci 0000:01:02.0: calling fixup_ppc4xx_pci_bridge+0x0/0x154
pci 0000:01:02.0: calling quirk_resource_alignment+0x0/0x200
pci 0000:01:02.0: supports D1 D2
pci 0000:01:02.0: PME# supported from D0 D1 D2 D3hot
pci 0000:01:02.0: PME# disabled
pci_bus 0000:01: fixups for bus
pci 0000:00:02.0: PCI bridge to [bus 01-01]
pci 0000:01:02.0: scanning behind bridge, config 010100, pass 0
pci 0000:01:02.0: bus configuration invalid, reconfiguring
pci 0000:01:02.0: scanning behind bridge, config 010100, pass 1
pci_bus 0000:01: bus scan returning with max=01
pci 0000:00:02.0: scanning behind bridge, config 010100, pass 1
pci_bus 0000:00: bus scan returning with max=01
pci 0000:00:02.0: PCI bridge to [bus 01-01]
pci 0000:00:02.0: bridge window [io disabled]
pci 0000:00:02.0: bridge window [mem disabled]
pci 0000:00:02.0: bridge window [mem pref disabled]
pci_bus 0000:00: resource 0 [io 0x0000-0xffff]
pci_bus 0000:00: resource 1 [mem 0xd80000000-0xdffffffff]
Thanks.
Felix.
^ 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