This is a fix for the LPC47M192 SuperIO on the MPC8641 HPCN.
Specifically this fixes support for the I8042 Keyboard/Mouse and the
GPIO on the chip.
Also, the mouse needs to use IRQ 12, which is currently in use by some
PCI devices. Move those devices to IRQ 11, and reserve IRQ 12 for the
mouse.
Signed-off-by: Wade Farnsworth <redacted>
---
Note that I submitted this previously as part of a larger patchset.
Most of the other patches in the set have been obsoleted, so I'm now
submitting this as a standalone patch.
arch/powerpc/boot/dts/mpc8641_hpcn.dts | 4 -
arch/powerpc/platforms/86xx/mpc86xx_hpcn.c | 43 +++++++++++++++----
2 files changed, 38 insertions(+), 9 deletions(-)
Index: linux-2.6-powerpc-8641/arch/powerpc/boot/dts/mpc8641_hpcn.dts
===================================================================
@@ -211,7 +211,7 @@ static void __devinit quirk_uli1575(strupirq_map_word|=(uli1575_irq_route_table[i]&0xf)<<((irq2pin[i]-PIRQA)*4);-/* ULI1575 IRQ mapping conf register default value is 0xb9317542 */+/* ULI1575 IRQ mapping conf register default value is 0x09317542 */DBG("Setup ULI1575 IRQ mapping configuration register value = 0x%x\n",pirq_map_word);pci_write_config_dword(dev,0x48,pirq_map_word);
@@ -266,9 +266,9 @@ static void __devinit quirk_uli1575(strupci_write_config_byte(dev,0x44,0x30|uli1575_irq_route_table[14]);pci_write_config_byte(dev,0x75,uli1575_irq_route_table[15]);-/* Set IRQ14 and IRQ15 to legacy IRQs */+/* Set IRQ1, IRQ12, IRQ14 and IRQ15 to legacy IRQs */pci_read_config_word(dev,0x46,&temp);-temp|=0xc000;+temp|=0xd002;pci_write_config_word(dev,0x46,temp);/* Set i8259 interrupt trigger
eyboard */
Hardcoded I/O port numbers always worry me a little. I know that this is
supposed to work in general, but can't you read the I/O port range from
a device tree property?
Arnd <><
Hardcoded I/O port numbers always worry me a little. I know that this=20=
is
supposed to work in general, but can't you read the I/O port range =
from
a device tree property?
This code is writing hardcoded values into IRQ#
and address window registers, the superio configuration
address should be the least of your worries ;-)
Segher
Hardcoded I/O port numbers always worry me a little. I know that this is
supposed to work in general, but can't you read the I/O port range from
a device tree property?
I suppose I could create a device node for the Super I/O config
registers and use those instead of hardcoding it here.
Something to the effect of:
superio_cfg@4e {
reg = <1 4e 2>;
compatible = "smsc-lpc47m192-cfg";
};
I'm not sure if the name and compatible properties are appropriate
though. Any recommendations?
--Wade
Hardcoded I/O port numbers always worry me a little. I know that this
is
supposed to work in general, but can't you read the I/O port range
from
a device tree property?
I suppose I could create a device node for the Super I/O config
registers and use those instead of hardcoding it here.
I'd just hide it all, do this setup in the firmware,
where it belongs, and don't expose the superio config
in the device tree.
superio_cfg@4e {
reg = <1 4e 2>;
compatible = "smsc-lpc47m192-cfg";
};
I'm not sure if the name and compatible properties are appropriate
though. Any recommendations?
"superio" and "smsc,lpc47m192" I'd say. You also
then should link the logical devices on the superio
to the device nodes that represent those. I'm not
sure this is all worth it, this is low-level setup
the firmware should do and everything else can treat
it as a black box.
Segher
m1575 legacy interface device register 0x63 is the legacy I/O decoding
control.
Writing 0x90 enables ports 0x4e and 0x4f for Super I/O configuration and
ports 0x60 and 0x64 for keyboard/mouse.
On Thu, 2007-06-07 at 18:35 +0200, Segher Boessenkool wrote:
quoted
quoted
Hardcoded I/O port numbers always worry me a little. I know that this
is
supposed to work in general, but can't you read the I/O port range
from
a device tree property?
I suppose I could create a device node for the Super I/O config
registers and use those instead of hardcoding it here.
I'd just hide it all, do this setup in the firmware,
where it belongs, and don't expose the superio config
in the device tree.
That's a valid point. This probably could (should?) be handled by
U-boot.
Jon, or others do you have any opinions on this?
quoted
superio_cfg@4e {
reg = <1 4e 2>;
compatible = "smsc-lpc47m192-cfg";
};
I'm not sure if the name and compatible properties are appropriate
though. Any recommendations?
"superio" and "smsc,lpc47m192" I'd say. You also
then should link the logical devices on the superio
to the device nodes that represent those. I'm not
sure this is all worth it, this is low-level setup
the firmware should do and everything else can treat
it as a black box.
OK, if we decide to keep this, I'll use those instead.
Thanks.
--Wade
m1575 legacy interface device register 0x63 is the legacy I/O decoding
control.
Writing 0x90 enables ports 0x4e and 0x4f for Super I/O configuration
and
ports 0x60 and 0x64 for keyboard/mouse.
Ah I see. Copy this explanation into your next
version of the patch? :-)
Segher
From: Andy Fleming <hidden> Date: 2007-06-07 20:03:36
On Jun 7, 2007, at 11:35, Segher Boessenkool wrote:
quoted
quoted
Hardcoded I/O port numbers always worry me a little. I know that
this
is
supposed to work in general, but can't you read the I/O port range
from
a device tree property?
I suppose I could create a device node for the Super I/O config
registers and use those instead of hardcoding it here.
I'd just hide it all, do this setup in the firmware,
where it belongs, and don't expose the superio config
in the device tree.
No more. No more firmware-only initializations. It sounds great, in
principle, until you actually have to figure out why someone's setup
isn't working. I'm tired of having to see if the dts, u-boot, and
Linux are in sync. If Linux wants to use a device, I think it's not
unreasonable to have it setup the device itself. That way, Linux can
do whatever it wants with the device, and not have to rely on U-Boot
(or some other firmware) setting up the appropriate bits.
quoted
superio_cfg@4e {
reg = <1 4e 2>;
compatible = "smsc-lpc47m192-cfg";
};
I'm not sure if the name and compatible properties are appropriate
though. Any recommendations?
"superio" and "smsc,lpc47m192" I'd say. You also
then should link the logical devices on the superio
to the device nodes that represent those. I'm not
sure this is all worth it, this is low-level setup
the firmware should do and everything else can treat
it as a black box.
Please...no. What happens next is that we find a small bug that
requires we modify U-Boot to do the initialization slightly
differently, and then requires Linux to act slightly differently.
And then I get emails every day from people wondering why their
boards don't work.
Andy
I suppose I could create a device node for the Super I/O config
registers and use those instead of hardcoding it here.
I'd just hide it all, do this setup in the firmware,
where it belongs, and don't expose the superio config
in the device tree.
No more. No more firmware-only initializations.
This setup is very board specific, and the board cannot
reasonably work without that setup being done right. You
really want to push _that_ into Linux? Alternatively,
you could put it into the device tree, but that doesn't
help anything either.
It sounds great, in principle, until you actually have to figure out
why someone's setup isn't working. I'm tired of having to see if the
dts, u-boot, and Linux are in sync. If Linux wants to use a device, I
think it's not unreasonable to have it setup the device itself. That
way, Linux can do whatever it wants with the device, and not have to
rely on U-Boot (or some other firmware) setting up the appropriate
bits.
There is one and only one way to set up the superio for
a certain board (assuming the legacy I/O and IRQ values
are considered fixed values).
Please...no. What happens next is that we find a small bug that
requires we modify U-Boot to do the initialization slightly
differently, and then requires Linux to act slightly differently.
This is equivalent to needing a board-level fix really.
Segher