Re: MPC8321, ethernet and i2c problems after upgrade from 2.6.25 to 2.6.27
On Mon, Oct 13, 2008 at 02:01:55PM +0200, Joakim Tjernlund wrote:
Secondly i2c, I have this in my platform driver:
static struct i2c_board_info __initdata tmcu_i2c_devices[] = {
{ I2C_BOARD_INFO(rtc-ds1307, 0x68),
.type = ds1337,
},
};
int __init tmcu_i2c_board_devs(void)
{
int ret;
ret = i2c_register_board_info(0, tmcu_i2c_devices,
ARRAY_SIZE(tmcu_i2c_devices));
return ret;
}
arch_initcall(tmcu_i2c_board_devs);
i2c-mpc.c now registers as a dynamically-numbered bus; you need to either
use the device tree, or call i2c_new_device().
-Scott
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] powerpc/chrp: Fix detection of Python PCI host bridge on IBM CHRPs
The detection of the IBM Python PCI host bridge on IBM CHRP
machines such as old RS6000 was broken when we changed
of_device_is_compatible() from strncasecmp to strcasecmp (dropped
the n variant) due to the way IBM encodes the chip version.
We fix that by instead doing a match on the model property like
we do for others bridges in that file. It should be good enough
for those machines. If yours is still broken, let me know.
Signed-off-by: Benjamin Herrenschmidt [EMAIL PROTECTED]
---
arch/powerpc/platforms/chrp/pci.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- linux-work.orig/arch/powerpc/platforms/chrp/pci.c 2008-10-14
16:37:05.0 +1100
+++ linux-work/arch/powerpc/platforms/chrp/pci.c2008-10-14
17:05:09.0 +1100
@@ -266,7 +266,7 @@ chrp_find_bridges(void)
model = of_get_property(dev, model, NULL);
if (model == NULL)
model = none;
- if (of_device_is_compatible(dev, IBM,python)) {
+ if (strncmp(model, IBM, Python, 11) == 0) {
setup_python(hose, dev);
} else if (is_mot
|| strncmp(model, Motorola, Grackle, 17) == 0) {
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [RFC 1/3] hvc_console: rework setup to replace irq functions with callbacks
Am Dienstag, 14. Oktober 2008 schrieb Benjamin Herrenschmidt: Hmmm. Can you try if this patch fixes the lockdep trace? Yup, the patch fixes it, I'll commit it via the powerpc.git tree if you don't have any objection. Sure, go ahead. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] powerpc: Fix CHRP PCI config access for indirect_pci
Recently, indirect_pci was changed to test if the bus number requested is the one hanging straight off the PHB, then it substitutes the bus number with another one contained in a new self_busno field of the pci_controller structure. However, this breaks CHRP which didn't initialize this new field, and which relies on having the right bus number passed to the hardware. This fixes it by initializing this variable properly for all CHRP bridges Signed-off-by: Benjamin Herrenschmidt [EMAIL PROTECTED] --- arch/powerpc/platforms/chrp/pci.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- linux-work.orig/arch/powerpc/platforms/chrp/pci.c 2008-10-14 17:35:12.0 +1100 +++ linux-work/arch/powerpc/platforms/chrp/pci.c2008-10-14 17:35:18.0 +1100 @@ -263,7 +263,7 @@ chrp_find_bridges(void) dev-full_name); continue; } - hose-first_busno = bus_range[0]; + hose-first_busno = hose-self_busno = bus_range[0]; hose-last_busno = bus_range[1]; model = of_get_property(dev, model, NULL); ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [patch] powerpc: implement optimised mutex fastpaths
On Mon, Oct 13, 2008 at 11:20:20AM -0500, Scott Wood wrote:
On Mon, Oct 13, 2008 at 11:15:47AM -0500, Scott Wood wrote:
On Sun, Oct 12, 2008 at 07:47:32AM +0200, Nick Piggin wrote:
+static inline int __mutex_cmpxchg_lock(atomic_t *v, int old, int new)
+{
+ int t;
+
+ __asm__ __volatile__ (
+1: lwarx %0,0,%1 # mutex trylock\n\
+ cmpw0,%0,%2\n\
+ bne-2f\n
+ PPC405_ERR77(0,%1)
+stwcx. %3,0,%1\n\
+ bne-1b
+ ISYNC_ON_SMP
+ \n\
+2:
+ : =r (t)
+ : r (v-counter), r (old), r (new)
+ : cc, memory);
This will break if the compiler picks r0 for v-counter. Use b as the
constraint, or better yet do lwarx %0, %y1, with a Z (v-counter)
constraint.
Sorry, had a morning brain-fart there -- you're not using the base
register.
OK no problem. Do you think it looks OK? Thanks for reviewing...
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [RFC 1/3] hvc_console: rework setup to replace irq functions with callbacks
On Tue, 2008-10-14 at 08:42 +0200, Christian Borntraeger wrote: Am Dienstag, 14. Oktober 2008 schrieb Benjamin Herrenschmidt: Hmmm. Can you try if this patch fixes the lockdep trace? Yup, the patch fixes it, I'll commit it via the powerpc.git tree if you don't have any objection. Sure, go ahead. Allright, I have a batch about ready to go to Linus, so I'll add that and ask him to pull tomorrow. Thanks, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [patch] mutex: optimise generic mutex implementations
On Sun, 2008-10-12 at 07:46 +0200, Nick Piggin wrote: Speed up generic mutex implementations. - atomic operations which both modify the variable and return something imply full smp memory barriers before and after the memory operations involved (failing atomic_cmpxchg, atomic_add_unless, etc don't imply a barrier because they don't modify the target). See Documentation/atomic_ops.txt. So remove extra barriers and branches. - All architectures support atomic_cmpxchg. This has no relation to __HAVE_ARCH_CMPXCHG. We can just take the atomic_cmpxchg path unconditionally This reduces a simple single threaded fastpath lock+unlock test from 590 cycles to 203 cycles on a ppc970 system. Signed-off-by: Nick Piggin [EMAIL PROTECTED] Looks ok. Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[RFC PATCH 1/5] hvc_console: Adding hangup notifier
From: Hendrik Brueckner [EMAIL PROTECTED]
I have added a hangup notifier that can be used by hvc console
backends to handle a tty hangup. The default irq hangup notifier
calls the notifier_del_irq() for compatibility.
Acked-by: Christian Borntraeger [EMAIL PROTECTED]
Signed-off-by: Hendrik Brueckner [EMAIL PROTECTED]
---
drivers/char/hvc_console.c|4 ++--
drivers/char/hvc_console.h|4 +++-
drivers/char/hvc_irq.c|5 +
drivers/char/hvc_iseries.c|1 +
drivers/char/hvc_vio.c|1 +
drivers/char/hvc_xen.c|1 +
drivers/char/virtio_console.c |1 +
7 files changed, 14 insertions(+), 3 deletions(-)
--- a/drivers/char/hvc_console.c2008-10-08 16:08:40.0 +0200
+++ b/drivers/char/hvc_console.c2008-10-09 10:30:13.0 +0200
@@ -416,8 +416,8 @@ static void hvc_hangup(struct tty_struct
hp-n_outbuf = 0;
hp-tty = NULL;
- if (hp-ops-notifier_del)
- hp-ops-notifier_del(hp, hp-data);
+ if (hp-ops-notifier_hangup)
+ hp-ops-notifier_hangup(hp, hp-data);
spin_unlock_irqrestore(hp-lock, flags);
--- a/drivers/char/hvc_console.h2008-10-08 16:08:40.0 +0200
+++ b/drivers/char/hvc_console.h2008-10-09 10:30:13.0 +0200
@@ -65,9 +65,10 @@ struct hv_ops {
int (*get_chars)(uint32_t vtermno, char *buf, int count);
int (*put_chars)(uint32_t vtermno, const char *buf, int count);
- /* Callbacks for notification. Called in open and close */
+ /* Callbacks for notification. Called in open, close and hangup */
int (*notifier_add)(struct hvc_struct *hp, int irq);
void (*notifier_del)(struct hvc_struct *hp, int irq);
+ void (*notifier_hangup)(struct hvc_struct *hp, int irq);
};
/* Register a vterm and a slot index for use as a console (console_init) */
@@ -86,6 +87,7 @@ void hvc_kick(void);
/* default notifier for irq based notification */
extern int notifier_add_irq(struct hvc_struct *hp, int data);
extern void notifier_del_irq(struct hvc_struct *hp, int data);
+extern void notifier_hangup_irq(struct hvc_struct *hp, int data);
#if defined(CONFIG_XMON) defined(CONFIG_SMP)
--- a/drivers/char/hvc_irq.c2008-10-08 16:08:40.0 +0200
+++ b/drivers/char/hvc_irq.c2008-10-09 10:30:13.0 +0200
@@ -42,3 +42,8 @@ void notifier_del_irq(struct hvc_struct
free_irq(irq, hp);
hp-irq_requested = 0;
}
+
+void notifier_hangup_irq(struct hvc_struct *hp, int irq)
+{
+ notifier_del_irq(hp, irq);
+}
--- a/drivers/char/hvc_iseries.c2008-10-08 16:08:40.0 +0200
+++ b/drivers/char/hvc_iseries.c2008-10-09 10:30:13.0 +0200
@@ -202,6 +202,7 @@ static struct hv_ops hvc_get_put_ops = {
.put_chars = put_chars,
.notifier_add = notifier_add_irq,
.notifier_del = notifier_del_irq,
+ .notifier_hangup = notifier_hangup_irq,
};
static int __devinit hvc_vio_probe(struct vio_dev *vdev,
--- a/drivers/char/hvc_xen.c2008-10-08 16:08:40.0 +0200
+++ b/drivers/char/hvc_xen.c2008-10-09 10:30:13.0 +0200
@@ -102,6 +102,7 @@ static struct hv_ops hvc_ops = {
.put_chars = write_console,
.notifier_add = notifier_add_irq,
.notifier_del = notifier_del_irq,
+ .notifier_hangup = notifier_hangup_irq,
};
static int __init xen_init(void)
--- a/drivers/char/hvc_vio.c2008-10-08 16:08:40.0 +0200
+++ b/drivers/char/hvc_vio.c2008-10-09 10:30:13.0 +0200
@@ -82,6 +82,7 @@ static struct hv_ops hvc_get_put_ops = {
.put_chars = hvc_put_chars,
.notifier_add = notifier_add_irq,
.notifier_del = notifier_del_irq,
+ .notifier_hangup = notifier_hangup_irq,
};
static int __devinit hvc_vio_probe(struct vio_dev *vdev,
--- a/drivers/char/virtio_console.c 2008-10-09 10:29:41.0 +0200
+++ b/drivers/char/virtio_console.c 2008-10-09 10:30:23.0 +0200
@@ -198,6 +198,7 @@ static int __devinit virtcons_probe(stru
virtio_cons.put_chars = put_chars;
virtio_cons.notifier_add = notifier_add_vio;
virtio_cons.notifier_del = notifier_del_vio;
+ virtio_cons.notifier_hangup = notifier_del_vio;
/* The first argument of hvc_alloc() is the virtual console number, so
* we use zero. The second argument is the parameter for the
--
Hendrik Brueckner
D/3303 Linux on System z Development
Tel: +49 7031 16-1073
Fax: +49 7031 16-3456
eMail: [EMAIL PROTECTED]
IBM Deutschland Research Development GmbH, Schoenaicher Str. 220, 71032
Boeblingen
IBM Deutschland Research Development GmbH
Vorsitzender des Aufsichtsrats: Martin Jetter
Geschaeftsfuehrung: Erich Baier
Sitz der Gesellschaft: Boeblingen
Registergericht: Amtsgericht Stuttgart, HRB 243294
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
Re: gigE 2.6.27 USB
Kevin Diggs wrote: Hi, I managed to wrestle my gigE to the ground and get it to boot 2.6.27. I have, however, noticed that some messages are showing up in dmesg. There are alot of them. They are continuous. They appear to come from drivers/usb/core/hub.c:2916. It looks like they come in pairs (this beast has two ports (root hubs)). I plugged in a USB CF reader. It appears to work. The keyboard and mouse (a Logitech wireless receiver) seems to work. 2.6.24 did not do this. kevin For what it is worth, I tricked a laptop into booting 2.6.27. It does not appear to generate these messages. The PowerMac is running Yellow Dog 4. kevin ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[RFC][USB] powerpc: Workaround for the PPC440EPX USBH_23 errata [take 2]
A published errata for ppc440epx states, that when running Linux with both
EHCI and OHCI modules loaded, the EHCI module experiences a fatal error
when a high-speed device is connected to the USB2.0, and functions normally
if OHCI module is not loaded.
There used to be recommendation to use only hi-speed or full-speed
devices with specific conditions, when respective module was unloaded.
Later, it was observed that ohci suspend is enough to keep things
going, and it was turned into workaround, as explained below.
Quote from original descriprion:
The 440EPx USB 2.0 Host controller is an EHCI compliant controller. In USB
2.0 Host controllers, each EHCI controller has one or more companion
controllers, which may be OHCI or UHCI. An USB 2.0 Host controller will
contain one or more ports. For each port, only one of the controllers is
connected at any one time. In the 440EPx, there is only one OHCI companion
controller,
and only one USB 2.0 Host port.
All ports on an USB 2.0 controller default to the companion controller. If
you load only an ohci driver, it will have control of the ports and any
deviceplugged in will operate, although high speed devices will be forced to
operate at full speed. When an ehci driver is loaded, it explicitly takes
control
of the ports. If there is a device connected, and / or every time there is a
new device connected, the ehci driver determines if the device is high speed or
not. If it is high speed, the driver retains control of the port. If it
is not, the driver explicitly gives the companion controller control of the
port.
The is a software workaround that uses
Initial version of the software workaround was posted to linux-usb-devel:
http://www.mail-archive.com/[EMAIL PROTECTED]/msg54019.html
and later available from amcc.com:
http://www.amcc.com/Embedded/Downloads/download.html?cat=1family=15ins=2
The patch below is generally based on the latter, but reworked to
powerpc/of_device USB drivers, and uses a few devicetree inquiries to get
rid of (some) hardcoded defines.
Signed-off-by: Vitaly Bordug [EMAIL PROTECTED]
Signed-off-by: Stefan Roese [EMAIL PROTECTED]
---
arch/powerpc/boot/dts/sequoia.dts |2 +-
drivers/usb/host/ehci-hub.c |9 +++
drivers/usb/host/ehci-ppc-of.c| 45 -
drivers/usb/host/ehci.h | 31 +
drivers/usb/host/ohci-ppc-of.c| 25 +
5 files changed, 109 insertions(+), 3 deletions(-)
diff --git a/arch/powerpc/boot/dts/sequoia.dts
b/arch/powerpc/boot/dts/sequoia.dts
index 72d15f0..db04dfa 100644
--- a/arch/powerpc/boot/dts/sequoia.dts
+++ b/arch/powerpc/boot/dts/sequoia.dts
@@ -134,7 +134,7 @@
};
USB1: [EMAIL PROTECTED] {
- compatible = ohci-be;
+ compatible = ibm,usb-ohci-440epx, ohci-be;
reg = 0x 0xe400 0x0060;
interrupt-parent = UIC0;
interrupts = 0x15 0x8;
diff --git a/drivers/usb/host/ehci-hub.c b/drivers/usb/host/ehci-hub.c
index 740835b..c25d8fe 100644
--- a/drivers/usb/host/ehci-hub.c
+++ b/drivers/usb/host/ehci-hub.c
@@ -424,8 +424,15 @@ static int check_reset_complete (
port_status = ~PORT_RWC_BITS;
ehci_writel(ehci, port_status, status_reg);
- } else
+ /* ensure 440EPX ohci controller state is operational */
+ if (ehci-has_amcc_usb23)
+ set_ohci_hcfs(ehci, 1);
+ } else {
ehci_dbg (ehci, port %d high speed\n, index + 1);
+ /* ensure 440EPx ohci controller state is suspended */
+ if (ehci-has_amcc_usb23)
+ set_ohci_hcfs(ehci, 0);
+ }
return port_status;
}
diff --git a/drivers/usb/host/ehci-ppc-of.c b/drivers/usb/host/ehci-ppc-of.c
index b018dee..ef732b7 100644
--- a/drivers/usb/host/ehci-ppc-of.c
+++ b/drivers/usb/host/ehci-ppc-of.c
@@ -107,11 +107,13 @@ ehci_hcd_ppc_of_probe(struct of_device *op, const struct
of_device_id *match)
{
struct device_node *dn = op-node;
struct usb_hcd *hcd;
- struct ehci_hcd *ehci;
+ struct ehci_hcd *ehci = NULL;
struct resource res;
int irq;
int rv;
+ struct device_node *np;
+
if (usb_disabled())
return -ENODEV;
@@ -149,6 +151,20 @@ ehci_hcd_ppc_of_probe(struct of_device *op, const struct
of_device_id *match)
}
ehci = hcd_to_ehci(hcd);
+ np = of_find_compatible_node(NULL, NULL, ibm,usb-ohci-440epx);
+ if (np != NULL) {
+ /* claim we really affected by usb23 erratum */
+ if (!of_address_to_resource(np, 0, res))
+ ehci-ohci_hcctrl_reg = ioremap(res.start +
+ OHCI_HCCTRL_OFFSET, OHCI_HCCTRL_LEN);
+ else
+
[OT] Re: Floating inputs on unused GPIO pins
[Marked off-topic because it is exclusively hardware related] On Mon, Oct 13, 2008 at 08:12:02AM -0500, Bill Gatliff wrote: Laurent Pinchart wrote: There are no internal pull-up or pull-down resistors on the MPC8248 GPIO pins. I know our hardware engineer has a valid point theoretically. Does the point stand practically, or does the MPC8248 state-of-the-art(tm)(c)(whatever) technology make floating inputs safe ? Well, Freescale's own layout recommendations recommend pullups or pulldowns for all input pins, but it's isn't clear what motivates that suggestion. The block diagram, Figure 37-21, is less than helpful. :) I recall a doc somewhere that showed the input protection circuitry ends up providing a modest pullup/down, so the line never truly floats. It's most of the time a couple of reverse biased diodes, one pulling to the ground and the other to the I/O supply for that pin (there may be several differnt I/O voltages in addition to a core voltage but I digress). This prevents the input from going outside the ground to I/O supply range (plus/minus diode threshholds) but can be considered as essentially free floating inside that range. The input may well end up floating at mid-level turning on both transistors of the input gate (actually if the diodes are well matched, it will, but don't try to measure it with a voltmeter). But it's a very high-impedance path, True and that's why it cannot be depended upon. The DC voltage (not taking into account pickup to which it will be very sensitive) and the impedance will depend on several internal (diode characteristics and matching), ambient (temperature) and external factors (resistive pick up through sub pA level surface currents from neighboring pins/tracks). Especially the effective impedance of the diode drops very rapidly with temperature (or if you prefer their leakage current increases with increasing temperature). This makes the circuit much more sensitive to AC pickup at very low temperatures. In this case the only sane solution is, unfortunately, adding external pullup and or pulldown resistors. The resistor value can be high (47k to 1M) to limit current waste when the signal does not have the default value. If you expect most of your signals to be low most of the time, use pull-down resistors, else use pull-ups (or select on a signal by signal basis if you can afford it, but this rule does not apply to the GPIO pin used as a presence detect if there is one). Regards, Gabriel ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [BUILD_FAILURE] 2.6.27-git2 - allyesconfig on powerpc selectsCONFIG_INTEL_IOATDMA=y
On Tue, Oct 14, 2008 at 11:12:30AM +0200, Brice Goglin wrote: Adrian Bunk wrote: But considering that igb is in a similar situation it would be nice if all 3 drivers would handle it the same way. Jesse, What do you think of the below patch? I am not very familiar with Kconfig, but it seems to solve the problem. If a Kconfig guru could double-check... The patch looks good, but the main problem is to get an agreement on the policy. Brice ... cu Adrian -- Is there not promise of rain? Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. Only a promise, Lao Er said. Pearl S. Buck - Dragon Seed ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH V2 4/4] POWERPC: Merge 32 and 64-bit dma code
On Tue, 2008-10-14 at 06:24 -0400, Josh Boyer wrote: I pointed out to Stephen that kisskb.ellerman.id.au hasn't been updating.. there is a chrp32 defconfig in there that would normally catch something like this. Except if kissb catches it, it's already committed in tree. Better than nothing, but it would be nice if people did a buildall before they commit. I have a script that builds a dozen of config's, it looks like it didn't catch that one. I'm going to add a chrp32_defconfig to it. Mistakes happen, hopefully we can at least make sure the common configs are well tested. Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH V2 4/4] POWERPC: Merge 32 and 64-bit dma code
On Mon, 13 Oct 2008 20:52:25 -0500 Kumar Gala [EMAIL PROTECTED] wrote: On Oct 13, 2008, at 6:30 PM, Benjamin Herrenschmidt wrote: On Mon, 2008-10-13 at 13:22 -0500, Kumar Gala wrote: I don't think it matters much when it gets fixed, pre or post -rc1. But it should probably get fixed. My hack was to pull isa_bridge_pcidev into pci-common.c and export it from there. The 64-bit PCI code can initialized it, and the 32-bit can leave it NULL. But I have no idea if that is sane. If so, I can probably submit a patch for it. I was just joking around about our new regression policy.. anyways I hope ben or maybe anton can comment about the ISA code. My policy for that sort of bug is fix ASAP. I'll give it a go when I do my test builds. Funny I didn't catch it, I might be lacking a chrp32 defconfig in my build tests :-) I pointed out to Stephen that kisskb.ellerman.id.au hasn't been updating.. there is a chrp32 defconfig in there that would normally catch something like this. Except if kissb catches it, it's already committed in tree. Better than nothing, but it would be nice if people did a buildall before they commit. josh ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [RFC][USB] powerpc: Workaround for the PPC440EPX USBH_23 errata [take 2]
On Tue, 14 Oct 2008, Vitaly Bordug wrote: A published errata for ppc440epx states, that when running Linux with both EHCI and OHCI modules loaded, the EHCI module experiences a fatal error when a high-speed device is connected to the USB2.0, and functions normally if OHCI module is not loaded. There used to be recommendation to use only hi-speed or full-speed devices with specific conditions, when respective module was unloaded. Later, it was observed that ohci suspend is enough to keep things going, and it was turned into workaround, as explained below. Have you tried building this on a non-PPC440EPx system? It looks like this patch would cause a compile error. Alan Stern ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH]IB/ehca:reject dynamic memory add/remove
On Tue, 2008-10-14 at 14:23 +0200, Stefan Roscher wrote: On Monday 13 October 2008 07:09:26 pm Dave Hansen wrote: On Mon, 2008-10-13 at 13:10 +0200, Stefan Roscher wrote: Since the ehca device driver does not support dynamic memory add and remove operations, the driver must explicitly reject such requests in order to prevent unpredictable behaviors related to memory regions already occupied and being used by InfiniBand applications. The solution is to add a memory notifier to the ehca device driver and if a request for dynamic memory add or remove comes in, ehca will always reject it. Why doesn't the driver support it? This seems like an awfully extreme action to take. Do you have plans to support this in the driver soon? There is currently a slight incompatibility how openfabrics uses MRs and how System p does DMEM add/remove, which basically disables this support. If you want to talk to the firmware developpers, I can give you the right contacts. OK, Stefan and Christoph have very patiently explained the whole situation to me. The ehca driver needs to register any memory to which it might write with the hypervisor (which then talks to the hardware). For normal apps, it does get_user_pages() on the userspace memory and tells the hypervisor which pages it got. But, there are in-kernel users of the hardware as well like NFS and the IP stack. These might potentially write anywhere in memory since, for instance, an skbuf can be allocated anywhere. Due to limitations in the Infiniband software stack, all these users must all share the same L_KEY, which is basically the identifier of the individual Infiniband user. So, ehca registers all of the partition's memory with the hypervisor when it is loaded to prepare for these in-kernel users. (I think of this as mmap(/dev/mem) from a device to kernel memory.) The size of this table is restricted by the starting size of the physical memory allocated to the partition, so we can't oversize it and just fill it in later as memory is added (hypervisor limitation). We also can't resize it at runtime because of other hypervisor limitations. The only way to change it is basically to shut the adapter down, which Infiniband wouldn't deal well with since it doesn't have any retransmitting (Infiniband limitation). We could restrict the kernel area to which the ehca driver could write. We would then just bounce buffer things in and out of it. But, that'd be a latency and complexity nightmare. We could probably also modify each of the existing in-kernel users (NFS, etc...) to check to see whether the memory they're about to touch has been registered with the hypervisor. They could only bounce in cases where it hadn't. We could probably also detect these in-kernel users and only deny hotplugging in case one of them is actually active. But, for now, we take the cowardly approach and simply disable memory hotplug. You can still hotplug to the system, you just need to un-hotplug the ehca adapter from the partition, first. This will, of course be well documented in the already huge IBM manual. :) Back to the patch... Could we be a bit more explicit that a user can go to the HMC (the IBM control console) and remove the adapter? I'm just trying to think of the poor user looking at dmesg. The dude/dudette doing this is going to be sitting at the HMC. Can we get an helpful message to pop up to them? Will they even see dmesg output? -- Dave ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [RFC][USB] powerpc: Workaround for the PPC440EPX USBH_23 errata [take 2]
Have you tried building this on a non-PPC440EPx system? It looks like this patch would cause a compile error. yes, correct, last minute fix didn't make it into the patch, sorry about that. Will refresh, test and resubmit. -Vitaly ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
RE: [BUILD_FAILURE] 2.6.27-git2 - allyesconfig on powerpc selectsCONFIG_INTEL_IOATDMA=y
Brice Goglin wrote: Adrian Bunk wrote: But considering that igb is in a similar situation it would be nice if all 3 drivers would handle it the same way. Jesse, What do you think of the below patch? Seems like a much better solution. I can have Jeff Kirsher work on the equivalent patches for igb, and ixgbe today. I am not very familiar with Kconfig, but it seems to solve the problem. If a Kconfig guru could double-check... Yeah, please Kconfig gurus on the list have a quick look. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] Add new framebuffer driver for Fujitsu MB862xx GDCs
Carminefb driver, though, supports 800x600 resolution. BTW, I tried this patch and I get wrong colors on a patched DirectFB which is changing the endianness on the fly. Is this driver already taking care of this? Regards, M Anton Vorontsov ha scritto: On Tue, Oct 14, 2008 at 03:50:52PM +, Dmitry Baryshkov wrote: Anatolij Gustschin wrote: This patch adds framebuffer driver for Fujitsu Carmine/Coral-P(A)/Lime graphics controllers. Lime GDC support is known to work on PPC440EPx based lwmon5 and MPC8544E based socrates embedded boards, both equipped with Lime GDC. Carmine/Coral-P PCI GDC support is known to work on PPC440EPx based Sequoia board and also on x86 platform. Signed-off-by: Anatolij Gustschin [EMAIL PROTECTED] --- There are some PPC OF bits, so I'm cc'ing linuxppc-dev list. I though there is already carminefb driver. FWIW, I quite like Anatolij's driver: it has PCI and OF bindings, plus the patch description states that the driver supports Mint controllers as well, and I have some hardware that actually needs the support for Mint GDCs. (Today we just configure the GDC in the firmware and linux use offb.c driver with static setup, w/o ability to change modes e.t.c.) ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[RFC PATCH 2/5] hvc_console: Add tty driver flag TTY_DRIVER_RESET_TERMIOS
From: Hendrik Brueckner [EMAIL PROTECTED] After a tty hangup() or close() operation, processes might not reset the termio settings to a sane state. In order to reset the termios to its default settings the tty driver flag TTY_DRIVER_RESET_TERMIOS has been added. TTY driver flag description from include/linux/tty_driver.h: TTY_DRIVER_RESET_TERMIOS --- requests the tty layer to reset the termios setting when the last process has closed the device. Used for PTY's, in particular. Acked-by: Christian Borntraeger [EMAIL PROTECTED] Signed-off-by: Hendrik Brueckner [EMAIL PROTECTED] --- drivers/char/hvc_console.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/drivers/char/hvc_console.c +++ b/drivers/char/hvc_console.c @@ -796,7 +796,7 @@ static int hvc_init(void) drv-minor_start = HVC_MINOR; drv-type = TTY_DRIVER_TYPE_SYSTEM; drv-init_termios = tty_std_termios; - drv-flags = TTY_DRIVER_REAL_RAW; + drv-flags = TTY_DRIVER_REAL_RAW | TTY_DRIVER_RESET_TERMIOS; tty_set_operations(drv, hvc_ops); /* Always start the kthread because there can be hotplug vty adapters -- Hendrik Brueckner D/3303 Linux on System z Development Tel: +49 7031 16-1073 Fax: +49 7031 16-3456 eMail: [EMAIL PROTECTED] IBM Deutschland Research Development GmbH, Schoenaicher Str. 220, 71032 Boeblingen IBM Deutschland Research Development GmbH Vorsitzender des Aufsichtsrats: Martin Jetter Geschaeftsfuehrung: Erich Baier Sitz der Gesellschaft: Boeblingen Registergericht: Amtsgericht Stuttgart, HRB 243294 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [RFC PATCH 4/5] hvc_console: Add tty window resizing
On Tue, Oct 14, 2008 at 10:44:28AM +0100, Alan Cox wrote:
+ hp = container_of(work, struct hvc_struct, tty_resize);
+ if (!hp || !hp-tty)
+ return;
What locks hp-tty here, it can go NULL after the test on a hangup it
seems ?
You are right. Thanks.
See tty_do_resize() for all of this stuff in the latest git. If you can't
use tty_do_resize from your work queue then please let me know why as I'd
like everyone to be using one abstraction.
I have looked at it and I have corrected my patch to use tty_do_resize().
Since tty_do_resize() cannot be called holding the hp spinlock; the code uses
now tty_kref_get/put to keep track of the tty object. I am not sure if the
use of the kref's is correct here, so please let me know if there is a better
solution.
Thanks.
Regards,
Hendrik
[RFC PATCH 4/5 v2] hvc_console: Add tty window resizing using tty_do_resize()
From: Hendrik Brueckner [EMAIL PROTECTED]
The patch provides the hvc_resize() function to update the terminal
window dimensions (struct winsize) for a specified hvc console.
The function stores the new window size and schedules a function
that finally updates the tty winsize and signals the change to
user space (SIGWINCH).
Because the winsize update must acquire a mutex and might sleep,
the function is scheduled instead of being called from hvc_poll()
or khvcd.
This patch uses the tty_do_resize() routine from the tty layer.
A pending resize work is canceled in hvc_close() and hvc_hangup().
Signed-off-by: Hendrik Brueckner [EMAIL PROTECTED]
---
drivers/char/hvc_console.c | 58 +
drivers/char/hvc_console.h |6
2 files changed, 64 insertions(+)
--- a/drivers/char/hvc_console.c2008-10-14 16:13:12.0 +0200
+++ b/drivers/char/hvc_console.c2008-10-14 16:43:03.0 +0200
@@ -374,6 +374,9 @@ static void hvc_close(struct tty_struct
hp-tty = NULL;
spin_unlock_irqrestore(hp-lock, flags);
+ /* cancel pending tty resize work */
+ cancel_work_sync(hp-tty_resize);
+
/*
* Chain calls chars_in_buffer() and returns immediately if
* there is no buffered data otherwise sleeps on a wait queue
@@ -399,6 +402,9 @@ static void hvc_hangup(struct tty_struct
if (!hp)
return;
+ /* cancel pending tty resize work */
+ cancel_work_sync(hp-tty_resize);
+
spin_lock_irqsave(hp-lock, flags);
/*
@@ -494,6 +500,39 @@ static int hvc_write(struct tty_struct *
return written;
}
+/**
+ * hvc_set_winsz() - Resize the hvc tty terminal window.
+ * @work: work structure.
+ *
+ * The routine shall not be called within an atomic context because it
+ * might sleep.
+ *
+ * Locking:hp-lock
+ */
+static void hvc_set_winsz(struct work_struct *work)
+{
+ struct hvc_struct *hp;
+ unsigned long hvc_flags;
+ struct tty_struct *tty;
+ struct winsize ws;
+
+ hp = container_of(work, struct hvc_struct, tty_resize);
+ if (!hp)
+ return;
+
+ spin_lock_irqsave(hp-lock, hvc_flags);
+ if (!hp-tty) {
+ spin_unlock_irqrestore(hp-lock, hvc_flags);
+ return;
+ }
+ ws = hp-ws;
+ tty = tty_kref_get(hp-tty);
+ spin_unlock_irqrestore(hp-lock, hvc_flags);
+
+ tty_do_resize(tty, tty, ws);
+ tty_kref_put(tty);
+}
+
/*
* This is actually a contract between the driver and the tty layer outlining
* how much write room the driver can guarantee will be sent OR BUFFERED. This
@@ -638,6 +677,24 @@ int hvc_poll(struct hvc_struct *hp)
}
EXPORT_SYMBOL_GPL(hvc_poll);
+/**
+ * hvc_resize() - Update terminal window size information.
+ * @hp:HVC console pointer
+ * @ws:Terminal window size structure
+ *
+ * Stores the specified window size information in the hvc structure of @hp.
+ * The function schedule the tty resize update.
+ *
+ * Locking:Locking free; the function MUST be called holding hp-lock
+ */
+void hvc_resize(struct hvc_struct *hp, struct winsize ws)
+{
+ if ((hp-ws.ws_row != ws.ws_row) || (hp-ws.ws_col != ws.ws_col)) {
+ hp-ws = ws;
+ schedule_work(hp-tty_resize);
+ }
+}
+
/*
* This kthread is either polling or interrupt driven. This is determined by
* calling hvc_poll() who determines whether a console adapter support
@@ -720,6 +777,7 @@ struct hvc_struct __devinit *hvc_alloc(u
kref_init(hp-kref);
+ INIT_WORK(hp-tty_resize, hvc_set_winsz);
spin_lock_init(hp-lock);
spin_lock(hvc_structs_lock);
--- a/drivers/char/hvc_console.h2008-10-14 16:13:11.0 +0200
+++ b/drivers/char/hvc_console.h2008-10-14 16:13:13.0 +0200
@@ -27,6 +27,7 @@
#ifndef HVC_CONSOLE_H
#define HVC_CONSOLE_H
#include linux/kref.h
+#include linux/tty.h
/*
* This is the max number of
Re: [PROBLEM] Soft lockup on Linux 2.6.27, 2 patches, Cell/PPC64
On Mon, 13 Oct 2008, Geert Uytterhoeven wrote: On Sun, 12 Oct 2008, Aaron Tokhy wrote: I recently built 2.6.27 with these patches on my PS3. http://www.kernel.org/pub/linux/kernel/people/geoff/cell/ps3-linux-patches/ps3-wip/ps3vram-driver.patch http://www.kernel.org/pub/linux/kernel/people/geoff/cell/ps3-linux-patches/ps3-wip/ps3vram-proc-fs.patch These patches enable the 'ps3vram' module, which creates a MTD node Now I am not sure if the patch is the issue. None of the functions in No, we've seen similar things happen without ps3vram, too. BUG: soft lockup - CPU#0 stuck for 61s! [top:22788] Modules linked in: evdev hci_usb usbhid bluetooth usb_storage snd_ps3 ehci_hcd snd_pcm ohci_hcd snd_page_alloc snd_timer usbcore snd sg ps3_lpm soundcore irq event stamp: 5018780 hardirqs last enabled at (5018779): [c0007c1c] restore+0x1c/0xe4 hardirqs last disabled at (5018780): [c0003600] decrementer_common+0x100/0x180 softirqs last enabled at (5018778): [c0020928] .call_do_softirq+0x14/0x24 softirqs last disabled at (5018773): [c0020928] .call_do_softirq+0x14/0x24 NIP: c0084110 LR: c0084468 CTR: c03181d0 REGS: c6f37280 TRAP: 0901 Not tainted (2.6.27) MSR: 80008032 EE,IR,DR CR: 42004424 XER: TASK = c798[22788] 'top' THREAD: c6f34000 CPU: 0 GPR00: 0001 c6f37500 c05543d0 c6f37570 GPR04: c008427c 0001 GPR08: 0830 0001 c0b96874 GPR12: 80008032 c0586300 NIP [c0084110] .csd_flag_wait+0x14/0x1c LR [c0084468] .smp_call_function_single+0x13c/0x164 Call Trace: [c6f37500] [c0084468] .smp_call_function_single+0x13c/0x164 (unreliable) smp_call_function_single() causes an IPI to be sent to the other CPU thread. However, the IPI never seems to arrive at the other CPU thread, causing the soft lockup message to be printed on the console. If this happens when the BKL is held before sending the IPI, the system will deadlock when the other CPU thread tries to acquire the BKL. In that unfortunate case, you won't see any message on the console of a retail PS3, though. So far we do not know what's the exact cause of the IPI not arriving, hence suggestions are welcome. I've enabled the recently introduced CONFIG_RCU_CPU_STALL_DETECTOR option and got: | 3RCU detected CPU 1 stall (t=4295279718/750 jiffies) | Call Trace: | [c00013e5a940] [c000f314] .show_stack+0x70/0x184 (unreliable) | [c00013e5a9f0] [c009029c] .__rcu_pending+0x9c/0x2b4 | [c00013e5aa90] [c00904ec] .rcu_pending+0x38/0x84 | [c00013e5ab10] [c005d9f0] .update_process_times+0x40/0x8c | [c00013e5aba0] [c0076d4c] .tick_sched_timer+0x154/0x1bc | [c00013e5ac60] [c006e630] .__run_hrtimer+0x8c/0x128 | [c00013e5ad00] [c006f60c] .hrtimer_interrupt+0x10c/0x1c8 | [c00013e5add0] [c001d2d0] .timer_interrupt+0xcc/0x124 | [c00013e5ae80] [c0003614] decrementer_common+0x114/0x180 | --- Exception: 901 at .csd_flag_wait+0x4/0x1c | LR = .smp_call_function_single+0x13c/0x164 | [c00013e5b230] [c0082774] .smp_call_function_mask+0xe4/0x240 | [c00013e5b390] [c00566dc] .on_each_cpu+0x24/0x94 | [c00013e5b430] [c00998bc] .drain_all_pages+0x24/0x3c | [c00013e5b4b0] [c0099ba4] .__alloc_pages_internal+0x2d0/0x464 | [c00013e5b5b0] [c00bb158] .cache_alloc_refill+0x340/0x678 | [c00013e5b680] [c00bb574] .__kmalloc+0xe4/0x170 | [c00013e5b720] [c0297e18] .__alloc_skb+0x7c/0x154 | [c00013e5b7c0] [c02923a8] .sock_alloc_send_skb+0xc4/0x2a4 | [c00013e5b8a0] [c030a464] .unix_stream_sendmsg+0x178/0x384 | [c00013e5b990] [c028e234] .sock_aio_write+0xec/0x114 | [c00013e5baa0] [c00bf2dc] .do_sync_readv_writev+0xc8/0x130 | [c00013e5bc30] [c00fefa0] .compat_do_readv_writev+0x1e0/0x33c | [c00013e5bd90] [c00ff184] .compat_sys_writev+0x88/0xbc | [c00013e5be30] [c00074dc] syscall_exit+0x0/0x40 which points again to smp_call_function_single... With kind regards, Geert Uytterhoeven Software Architect Sony Techsoft Centre Europe The Corporate Village · Da Vincilaan 7-D1 · B-1935 Zaventem · Belgium Phone:+32 (0)2 700 8453 Fax: +32 (0)2 700 8622 E-mail: [EMAIL PROTECTED] Internet: http://www.sony-europe.com/ A division of Sony Europe (Belgium) N.V. VAT BE 0413.825.160 · RPR Brussels Fortis · BIC GEBABEBB · IBAN BE41293037680010___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] Add new framebuffer driver for Fujitsu MB862xx GDCs
On Tue, Oct 14, 2008 at 07:10:55PM +0200, Matteo Fortini wrote: Carminefb driver, though, supports 800x600 resolution. BTW, I tried this patch and I get wrong colors on a patched DirectFB which is changing the endianness on the fly. Is this driver already taking care of this? Yup. But you can change that, just delete FB_*_ENDIAN stuff from drivers/video/Kconfig: +config FB_MB862XX_LIME + bool Lime GDC + depends on FB_MB862XX + select FB_FOREIGN_ENDIAN + select FB_LITTLE_ENDIAN ..but then the kernel's fb console will be with the wrong colors. -- Anton Vorontsov email: [EMAIL PROTECTED] irc://irc.freenode.net/bd2 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [BUILD_FAILURE] 2.6.27-git2 - allyesconfig on powerpc selectsCONFIG_INTEL_IOATDMA=y
On Tue, Oct 14, 2008 at 09:10:33AM -0700, Brandeburg, Jesse wrote: Brice Goglin wrote: Adrian Bunk wrote: But considering that igb is in a similar situation it would be nice if all 3 drivers would handle it the same way. Jesse, What do you think of the below patch? Seems like a much better solution. I can have Jeff Kirsher work on the equivalent patches for igb, and ixgbe today. I am not very familiar with Kconfig, but it seems to solve the problem. If a Kconfig guru could double-check... Yeah, please Kconfig gurus on the list have a quick look. Brice's patch looks fine. cu Adrian -- Is there not promise of rain? Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. Only a promise, Lao Er said. Pearl S. Buck - Dragon Seed ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] [POWERPC] unsigned speed cannot be negative
unsigned speed cannot be negative Signed-off-by: Roel Kluin [EMAIL PROTECTED] --- N.B. It could be possible that a different fix is needed. diff --git a/arch/powerpc/kernel/udbg_16550.c b/arch/powerpc/kernel/udbg_16550.c index cb01ebc..7b7da8c 100644 --- a/arch/powerpc/kernel/udbg_16550.c +++ b/arch/powerpc/kernel/udbg_16550.c @@ -142,7 +142,7 @@ unsigned int udbg_probe_uart_speed(void __iomem *comport, unsigned int clock) speed = (clock / prescaler) / (divisor * 16); /* sanity check */ - if (speed 0 || speed (clock / 16)) + if (speed (clock / 16)) speed = 9600; return speed; ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH]IB/ehca:reject dynamic memory add/remove
On Tue, 2008-10-14 at 14:23 +0200, Stefan Roscher wrote: On Monday 13 October 2008 07:09:26 pm Dave Hansen wrote: On Mon, 2008-10-13 at 13:10 +0200, Stefan Roscher wrote: Since the ehca device driver does not support dynamic memory add and remove operations, the driver must explicitly reject such requests in order to prevent unpredictable behaviors related to memory regions already occupied and being used by InfiniBand applications. The solution is to add a memory notifier to the ehca device driver and if a request for dynamic memory add or remove comes in, ehca will always reject it. Why doesn't the driver support it? This seems like an awfully extreme action to take. Do you have plans to support this in the driver soon? There is currently a slight incompatibility how openfabrics uses MRs and how System p does DMEM add/remove, which basically disables this support. If you want to talk to the firmware developpers, I can give you the right contacts. I wish I knew what an 'MR' is. :( Could you be a bit more specific so we can get a better changelog? Perhaps if we understand the situation better, we can come up with a better solution. Does this have anything in common with the problems with 16GB pages? -- Dave ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] Add new framebuffer driver for Fujitsu MB862xx GDCs
On Tue, Oct 14, 2008 at 03:50:52PM +, Dmitry Baryshkov wrote: Anatolij Gustschin wrote: This patch adds framebuffer driver for Fujitsu Carmine/Coral-P(A)/Lime graphics controllers. Lime GDC support is known to work on PPC440EPx based lwmon5 and MPC8544E based socrates embedded boards, both equipped with Lime GDC. Carmine/Coral-P PCI GDC support is known to work on PPC440EPx based Sequoia board and also on x86 platform. Signed-off-by: Anatolij Gustschin [EMAIL PROTECTED] --- There are some PPC OF bits, so I'm cc'ing linuxppc-dev list. I though there is already carminefb driver. FWIW, I quite like Anatolij's driver: it has PCI and OF bindings, plus the patch description states that the driver supports Mint controllers as well, and I have some hardware that actually needs the support for Mint GDCs. (Today we just configure the GDC in the firmware and linux use offb.c driver with static setup, w/o ability to change modes e.t.c.) -- Anton Vorontsov email: [EMAIL PROTECTED] irc://irc.freenode.net/bd2 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] Add new framebuffer driver for Fujitsu MB862xx GDCs
This patch adds framebuffer driver for Fujitsu Carmine/Coral-P(A)/Lime graphics controllers. Lime GDC support is known to work on PPC440EPx based lwmon5 and MPC8544E based socrates embedded boards, both equipped with Lime GDC. Carmine/Coral-P PCI GDC support is known to work on PPC440EPx based Sequoia board and also on x86 platform. Signed-off-by: Anatolij Gustschin [EMAIL PROTECTED] --- There are some PPC OF bits, so I'm cc'ing linuxppc-dev list. drivers/video/Kconfig | 31 + drivers/video/Makefile |1 + drivers/video/mb862xx/Makefile |5 + drivers/video/mb862xx/mb862xx_reg.h | 138 + drivers/video/mb862xx/mb862xxfb.c | 1061 +++ drivers/video/mb862xx/mb862xxfb.h | 83 +++ 6 files changed, 1319 insertions(+), 0 deletions(-) create mode 100644 drivers/video/mb862xx/Makefile create mode 100644 drivers/video/mb862xx/mb862xx_reg.h create mode 100644 drivers/video/mb862xx/mb862xxfb.c create mode 100644 drivers/video/mb862xx/mb862xxfb.h diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig index f79c204..f13182a 100644 --- a/drivers/video/Kconfig +++ b/drivers/video/Kconfig @@ -2034,6 +2034,37 @@ config FB_METRONOME controller. The pre-release name for this device was 8track and could also have been called by some vendors as PVI-. +config FB_MB862XX + tristate Fujitsu MB862xx GDC support + depends on FB + select FB_CFB_FILLRECT + select FB_CFB_COPYAREA + select FB_CFB_IMAGEBLIT + ---help--- + Frame buffer driver for Fujitsu Carmine/Coral-P(A)/Lime controllers. + +config FB_MB862XX_PCI_GDC + bool Carmine/Coral-P(A) GDC + depends on FB_MB862XX + ---help--- + This enables framebuffer support for Fujitsu Carmine/Coral-P(A) + PCI graphics controller devices. + +config FB_MB862XX_LIME + bool Lime GDC + depends on FB_MB862XX + select FB_FOREIGN_ENDIAN + select FB_LITTLE_ENDIAN + ---help--- + Framebuffer support for Fujitsu Lime GDC on host CPU bus. + +config FB_PRE_INIT_FB + bool Don't reinitialize, use bootloader's GDC/Display configuration + depends on FB_MB862XX_LIME + ---help--- + Select this option if display contents should be inherited as set by + the bootloader. + source drivers/video/omap/Kconfig source drivers/video/backlight/Kconfig diff --git a/drivers/video/Makefile b/drivers/video/Makefile index ad0330b..218fe56 100644 --- a/drivers/video/Makefile +++ b/drivers/video/Makefile @@ -120,6 +120,7 @@ obj-$(CONFIG_FB_SH_MOBILE_LCDC) += sh_mobile_lcdcfb.o obj-$(CONFIG_FB_OMAP) += omap/ obj-$(CONFIG_XEN_FBDEV_FRONTEND) += xen-fbfront.o obj-$(CONFIG_FB_CARMINE) += carminefb.o +obj-$(CONFIG_FB_MB862XX) += mb862xx/ # Platform or fallback drivers go here obj-$(CONFIG_FB_UVESA)+= uvesafb.o diff --git a/drivers/video/mb862xx/Makefile b/drivers/video/mb862xx/Makefile new file mode 100644 index 000..0766481 --- /dev/null +++ b/drivers/video/mb862xx/Makefile @@ -0,0 +1,5 @@ +# +# Makefile for the MB862xx framebuffer driver +# + +obj-$(CONFIG_FB_MB862XX) := mb862xxfb.o diff --git a/drivers/video/mb862xx/mb862xx_reg.h b/drivers/video/mb862xx/mb862xx_reg.h new file mode 100644 index 000..2ba65e1 --- /dev/null +++ b/drivers/video/mb862xx/mb862xx_reg.h @@ -0,0 +1,138 @@ +/* + * Fujitsu MB862xx Graphics Controller Registers/Bits + */ + +#ifndef _MB862XX_REG_H +#define _MB862XX_REG_H + +#ifdef MB862XX_MMIO_BOTTOM +#define MB862XX_MMIO_BASE 0x03fc +#else +#define MB862XX_MMIO_BASE 0x01fc +#endif +#define MB862XX_I2C_BASE 0xc000 +#define MB862XX_DISP_BASE 0x0001 +#define MB862XX_CAP_BASE 0x00018000 +#define MB862XX_DRAW_BASE 0x0003 +#define MB862XX_GEO_BASE 0x00038000 +#define MB862XX_PIO_BASE 0x00038000 +#define MB862XX_MMIO_SIZE 0x4 + +/* Host interface/pio registers */ +#define GC_IST 0x0020 +#define GC_IMASK 0x0024 +#define GC_SRST0x002c +#define GC_CCF 0x0038 +#define GC_CID 0x00f0 +#define GC_REVISION0x0084 + +#define GC_CCF_CGE_100 0x +#define GC_CCF_CGE_133 0x0004 +#define GC_CCF_CGE_166 0x0008 +#define GC_CCF_COT_100 0x +#define GC_CCF_COT_133 0x0001 +#define GC_CID_CNAME_MSK 0xff00 +#define GC_CID_VERSION_MSK 0x00ff + +/* define enabled interrupts hereby */ +#define GC_INT_EN 0x + +/* Memory interface mode register */ +#define GC_MMR 0xfffc + +/* Display Controller registers */ +#define GC_DCM00x +#define GC_HTP 0x0004 +#define GC_HDB_HDP 0x0008 +#define GC_VSW_HSW_HSP 0x000c
Re: [BUILD_FAILURE] 2.6.27-git2 - allyesconfig on powerpc selectsCONFIG_INTEL_IOATDMA=y
Adrian Bunk wrote:
But considering that igb is in a similar situation it would be nice if
all 3 drivers would handle it the same way.
Jesse,
What do you think of the below patch?
I am not very familiar with Kconfig, but it seems to solve the problem.
If a Kconfig guru could double-check...
Brice
myri10ge: Add MYRI10GE_DCA instead of selecting INTEL_IOATDMA
Add a bool MYRI10GE_DCA defined to y if MYRI10GE and DCA are enabled, but
MYRI10GE isn't y while DCA=m. And thus remove the need to select INTEL_IOATDMA
when MYRI10GE is enabled, so that non-x86 architectures can build the myri10ge.
Signed-off-by: Brice Goglin [EMAIL PROTECTED]
diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig
index e9d5294..0162d55 100644
--- a/drivers/net/Kconfig
+++ b/drivers/net/Kconfig
@@ -2462,7 +2462,6 @@ config MYRI10GE
select FW_LOADER
select CRC32
select INET_LRO
- select INTEL_IOATDMA
---help---
This driver supports Myricom Myri-10G Dual Protocol interface in
Ethernet mode. If the eeprom on your board is not recent enough,
@@ -2474,6 +2473,11 @@ config MYRI10GE
To compile this driver as a module, choose M here. The module
will be called myri10ge.
+config MYRI10GE_DCA
+ bool
+ default y
+ depends on MYRI10GE DCA !(MYRI10GE=y DCA=m)
+
config NETXEN_NIC
tristate NetXen Multi port (1/10) Gigabit Ethernet NIC
depends on PCI
diff --git a/drivers/net/myri10ge/myri10ge.c b/drivers/net/myri10ge/myri10ge.c
index 6dce901..a9aebad 100644
--- a/drivers/net/myri10ge/myri10ge.c
+++ b/drivers/net/myri10ge/myri10ge.c
@@ -188,7 +188,7 @@ struct myri10ge_slice_state {
dma_addr_t fw_stats_bus;
int watchdog_tx_done;
int watchdog_tx_req;
-#if (defined CONFIG_DCA) || (defined CONFIG_DCA_MODULE)
+#ifdef CONFIG_MYRI10GE_DCA
int cached_dca_tag;
int cpu;
__be32 __iomem *dca_tag;
@@ -220,7 +220,7 @@ struct myri10ge_priv {
int msi_enabled;
int msix_enabled;
struct msix_entry *msix_vectors;
-#if (defined CONFIG_DCA) || (defined CONFIG_DCA_MODULE)
+#ifdef CONFIG_MYRI10GE_DCA
int dca_enabled;
#endif
u32 link_state;
@@ -902,7 +902,7 @@ static int myri10ge_reset(struct myri10ge_priv *mgp)
struct myri10ge_slice_state *ss;
int i, status;
size_t bytes;
-#if (defined CONFIG_DCA) || (defined CONFIG_DCA_MODULE)
+#ifdef CONFIG_MYRI10GE_DCA
unsigned long dca_tag_off;
#endif
@@ -1012,7 +1012,7 @@ static int myri10ge_reset(struct myri10ge_priv *mgp)
}
put_be32(htonl(mgp-intr_coal_delay), mgp-intr_coal_delay_ptr);
-#if (defined CONFIG_DCA) || (defined CONFIG_DCA_MODULE)
+#ifdef CONFIG_MYRI10GE_DCA
status = myri10ge_send_cmd(mgp, MXGEFW_CMD_GET_DCA_OFFSET, cmd, 0);
dca_tag_off = cmd.data0;
for (i = 0; i mgp-num_slices; i++) {
@@ -1051,7 +1051,7 @@ static int myri10ge_reset(struct myri10ge_priv *mgp)
return status;
}
-#if (defined CONFIG_DCA) || (defined CONFIG_DCA_MODULE)
+#ifdef CONFIG_MYRI10GE_DCA
static void
myri10ge_write_dca(struct myri10ge_slice_state *ss, int cpu, int tag)
{
@@ -1505,7 +1505,7 @@ static int myri10ge_poll(struct napi_struct *napi, int
budget)
struct net_device *netdev = ss-mgp-dev;
int work_done;
-#if (defined CONFIG_DCA) || (defined CONFIG_DCA_MODULE)
+#ifdef CONFIG_MYRI10GE_DCA
if (ss-mgp-dca_enabled)
myri10ge_update_dca(ss);
#endif
@@ -1736,7 +1736,7 @@ static const char
myri10ge_gstrings_main_stats[][ETH_GSTRING_LEN] = {
tx_boundary, WC, irq, MSI, MSIX,
read_dma_bw_MBs, write_dma_bw_MBs, read_write_dma_bw_MBs,
serial_number, watchdog_resets,
-#if (defined CONFIG_DCA) || (defined CONFIG_DCA_MODULE)
+#ifdef CONFIG_MYRI10GE_DCA
dca_capable_firmware, dca_device_present,
#endif
link_changes, link_up, dropped_link_overflow,
@@ -1815,7 +1815,7 @@ myri10ge_get_ethtool_stats(struct net_device *netdev,
data[i++] = (unsigned int)mgp-read_write_dma;
data[i++] = (unsigned int)mgp-serial_number;
data[i++] = (unsigned int)mgp-watchdog_resets;
-#if (defined CONFIG_DCA) || (defined CONFIG_DCA_MODULE)
+#ifdef CONFIG_MYRI10GE_DCA
data[i++] = (unsigned int)(mgp-ss[0].dca_tag != NULL);
data[i++] = (unsigned int)(mgp-dca_enabled);
#endif
@@ -3844,7 +3844,7 @@ static int myri10ge_probe(struct pci_dev *pdev, const
struct pci_device_id *ent)
dev_err(pdev-dev, failed reset\n);
goto abort_with_slices;
}
-#if (defined CONFIG_DCA) || (defined CONFIG_DCA_MODULE)
+#ifdef CONFIG_MYRI10GE_DCA
myri10ge_setup_dca(mgp);
#endif
pci_set_drvdata(pdev, mgp);
@@ -3948,7 +3948,7 @@ static void myri10ge_remove(struct pci_dev *pdev)
netdev = mgp-dev;
unregister_netdev(netdev);
-#if (defined CONFIG_DCA) || (defined CONFIG_DCA_MODULE)
+#ifdef CONFIG_MYRI10GE_DCA
Re: [PATCH] powerpc: enforce a non-spe kernel build even on broken compilers
On Mon, 2008-09-01 at 16:23 +0200, Sebastian Siewior wrote: those two are requried on my fresh gcc 4.3.1 Signed-off-by: Thiemo Seufer [EMAIL PROTECTED] Signed-off-by: Sebastian Siewior [EMAIL PROTECTED] --- Not sure if this is intendent or a gcc bug but with -mno-spe the spe opcodes were not used floating point anymore but for 64bit save/restore for instance. I wouldn't say this is due to a broken compiler. As I understand it, -mabi=no-spe and -mspe=no serve two different purposes. One is for disabling the SPE instructions and the other controls the ABI (which would make those 64-bit save/restores I'm guessing). I don't know why you'd ever want to use the SPE ABI without -mspe=yes, but gcc does provide that flexibility. -mno-spe: Deprecated way to say no SPE instructions -mspe=no: New way to do -mno-spe -mabi=no-spe: Disable SPE ABI Some compilers may enable -mabi=spe and/or -mspe=yes by default, so explicitly disabling both is necessary. I recently built a SPE toolchain which enabled both by default, so I ran into the SPE used in kernel problem when the kernel only passed -mno-spe. - Nate Case [EMAIL PROTECTED] ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [2.6.26 Power5 64bit] oops in ._spin_unlock_irqrestore
(cc's added) On Fri, 10 Oct 2008 16:06:23 +0200 Folkert van Heusden [EMAIL PROTECTED] wrote: Hi, While running my modrobe/rmmod script I got the following oops on a Linux LPAR on a Power5 system: [ 1867.960287] ipr: IBM Power RAID SCSI Device Driver version: 2.4.1 (April 24, 2007) [ 1867.961133] ipr :c0:01.0: Found IOA with IRQ: 321 [ 1867.967519] ipr :c0:01.0: Initializing IOA. [ 1867.979202] Unable to handle kernel paging request for data at address 0xd012b838 [ 1867.979220] Faulting instruction address: 0xc02de1c8 [ 1867.979232] Oops: Kernel access of bad area, sig: 11 [#1] [ 1867.979243] SMP NR_CPUS=32 NUMA pSeries [ 1867.979265] Modules linked in: ipr(+) loop windfarm_max6690_sensor sr_mod sg evdev snd_pcm snd_timer snd_hwdep compat_ioctl32 serio libps2 dm_log cdrom snd_usb_lib snd_page_alloc libata firmware_class snd_rawmidi snd_seq_device videodev dm_mod v4l1_compat ipv6 snd soundcore ibmveth ext3 jbd mbcache sd_mod ibmvscsic scsi_transport_srp scsi_tgt scsi_mod windfarm_smu_sat windfarm_cpufreq_clamp windfarm_core [last unloaded: atkbd] [ 1867.979488] NIP: c02de1c8 LR: d0130878 CTR: c02de1a8 [ 1867.979500] REGS: c000fc40fb40 TRAP: 0300 Not tainted (2.6.26-1-powerpc64) [ 1867.979510] MSR: 80009032 EE,ME,IR,DR CR: 2422 XER: 2001 [ 1867.979533] DAR: d012b838, DSISR: 4000 [ 1867.979543] TASK = c000fbc1d620[959] 'kseriod' THREAD: c000fc40c000 CPU: 7 [ 1867.979554] GPR00: d0130878 c000fc40fdc0 c05f9578 d012b830 [ 1867.979583] GPR04: d012b830 c05dc458 c000ffa0 [ 1867.979602] GPR08: c000fc40faf0 0003 d0134048 c02de1a8 [ 1867.979637] GPR12: d0130ca8 c0624200 [ 1867.979678] GPR16: 41c0 [ 1867.979715] GPR20: c05200c0 02120330 006b6000 c0520330 [ 1867.979743] GPR24: 021200c0 c0628a30 c051ed28 [ 1867.979782] GPR28: 0001 c000fb61a540 c059e558 d012b7e0 [ 1867.979813] NIP [c02de1c8] .driver_attach+0x20/0x40 [ 1867.979839] LR [d0130878] .serio_thread+0x1fc/0x42c [serio] [ 1867.979869] Call Trace: [ 1867.979881] [c000fc40fdc0] [c03d8624] ._spin_unlock_irqrestore+0x50/0x64 (unreliable) [ 1867.979927] [c000fc40fe40] [d0130878] .serio_thread+0x1fc/0x42c [serio] [ 1867.979955] [c000fc40ff00] [c00890f8] .kthread+0x78/0xc4 [ 1867.979979] [c000fc40ff90] [c00252ac] .kernel_thread+0x4c/0x68 [ 1867.980015] Instruction dump: [ 1867.980028] eb81ffe0 eba1ffe8 7c0803a6 4e800020 7c0802a6 fbc1fff0 ebc2b670 7c651b78 [ 1867.980070] 3880 f8010010 f821ff81 e8de8010 e8630008 4bfff5e1 6000 38210080 [ 1867.985180] ---[ end trace 16968366a5589005 ]--- The trigger script can be found here: http://www.vanheusden.com/pyk/ It looks more like a bug in the input code than powerpc. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [RFC PATCH 2/5] hvc_console: Add tty driver flag TTY_DRIVER_RESET_TERMIOS
On Tue, 14 Oct 2008 11:12:49 +0200 Hendrik Brueckner [EMAIL PROTECTED] wrote: From: Hendrik Brueckner [EMAIL PROTECTED] After a tty hangup() or close() operation, processes might not reset the termio settings to a sane state. That is the job of the getty task normally. pty is special as the reissue of the same pty is done as a new device (with new state). Setting this on the hvc would parallel the PC vt console behaviour but differ from most other ports. Anyway its a policy question for PPC64 so if thats how you want it to work Acked-by: Alan Cox [EMAIL PROTECTED] ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: MPC8321, ethernet and i2c problems after upgrade from 2.6.25 to 2.6.27
On Tue, 2008-10-14 at 10:27 -0500, Scott Wood wrote:
On Tue, Oct 14, 2008 at 09:55:31AM +0200, Joakim Tjernlund wrote:
On Mon, 2008-10-13 at 14:03 -0500, Scott Wood wrote:
Joakim Tjernlund wrote:
Because all the kernel comments I can see still implies that this
should work
Which kernel comments?
The one already mentioned and in i2c-boardinfo.c
I already addressed the one already mentioned (it was sloppy terminology
in the comment, written from the perspective of devtree-less arches).
The latter is even less clear, as it doesn't mention dynamic buses at
all.
Feel free to submit a documentation patch clearing it up. :-)
and because this was the only way in earlier releases to add an i2c
device.
We've supported enumerating i2c-mpc devices using the device tree for
almost as long as there's been new-style i2c devices.
Don't know how long that has been but looking at the mpc832x_mds dts
file it has been there less than a year.
commit d13ae8620dfdedfa7e9ab6d1eec294adc0516065 added i2c device probing
from the device tree in 7/21/07, less than 3 months after new-style i2c
devices were added to the i2c core. There were patches floating around
the lists for longer than that.
Why not? U-boot allows you to pass in a device tree dynamically.
I don't use a dynamic device tree, mine is built in.
So do a fixup in your board code.
Just did and this is what I came up with:
/* This should be removed once we have the rtc in u-boot's
device tree */
static struct device_node *new_node(const char *path,
struct device_node *parent)
{
struct device_node *np = kzalloc(sizeof(*np), GFP_KERNEL);
if (!np)
return NULL;
np-full_name = kmalloc(strlen(path) + 1, GFP_KERNEL);
if (!np-full_name) {
kfree(np);
return NULL;
}
strcpy(np-full_name, path);
of_node_set_flag(np, OF_DYNAMIC);
kref_init(np-kref);
np-parent = of_node_get(parent);
return np;
}
static struct property prop_compatible = {
.name compatible,
.value = dallas,ds1337,
.length = sizeof(dallas,ds1337),
};
static const unsigned long rtc_addr = 0x68;
static struct property prop_reg = {
.name reg,
.value = rtc_addr,
.length = sizeof(rtc_addr),
};
int __init tmcu_i2c_board_devs(void)
{
int ret=0;
struct device_node *np, *i2c_np, *rtc_node=NULL;
i2c_np = of_find_node_by_name(NULL, i2c);
if (!i2c_np)
return -1;
np = of_find_node_by_name(i2c_np, rtc);
if (!np) {
rtc_node = new_node(/rtc, i2c_np);
prom_add_property(rtc_node, prop_compatible);
prom_add_property(rtc_node, prop_reg);
of_attach_node(rtc_node);
}
return ret;
}
arch_initcall(tmcu_i2c_board_devs);
Wasn't easy to find out how, strangely I could not find a generic
new_node() function, had to copy one.
I'm not sure how you would even go about building a device tree into
U-boot currently, though.
That is easy :)
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 1/2] powerpc: don't pass unused regs around in head_.*.S
* Benjamin Herrenschmidt | 2008-10-14 10:25:12 [+1100]: On Sun, 2008-10-12 at 16:08 +0200, Sebastian Andrzej Siewior wrote: From: Sebastian Andrzej Siewior [EMAIL PROTECTED] This looks like a relict from arch/ppc. machine_init() is accepting only two parameters (dtb, phys) and is using only the first one. This isn't 100% correct actually... First, the base head_32.S (could be called head_6xx.S I suppose) supports a few more calling conventions such as the real OF one, with added support for initrd and cmdline in registers , and the BootX one. Yep, those extra register are only used in prom_init() or bootx_init(). In case we called one of those two we end up again in __start(dtb, phys, 0) Then, calling convention for the other cases is slightly better defined than just having r3 contain a device-tree pointer. The physical address is an important part of it, the fact that r5 is NULL to differenciate from an OF entry too, and we're moving toward the full ePAPR definition. Okay. Power_ePAPR_APPROVED_v1.0.pdf says we have r4, r5, r8, r9 = 0, r6 = magic and r7 size of the initial mapped area. I don't see the physical address here. Do you want me to update the comment / patch description or leave everything as it? I guess we don't have to pass unused register to machine_init(), do we? Cheers, Ben. Sebastian ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] Add new framebuffer driver for Fujitsu MB862xx GDCs
Anatolij Gustschin wrote: This patch adds framebuffer driver for Fujitsu Carmine/Coral-P(A)/Lime graphics controllers. Lime GDC support is known to work on PPC440EPx based lwmon5 and MPC8544E based socrates embedded boards, both equipped with Lime GDC. Carmine/Coral-P PCI GDC support is known to work on PPC440EPx based Sequoia board and also on x86 platform. Signed-off-by: Anatolij Gustschin [EMAIL PROTECTED] --- There are some PPC OF bits, so I'm cc'ing linuxppc-dev list. I though there is already carminefb driver. Probably you should either merge them or state that carminefb should be dropped. -- With best wishes Dmitry ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[RFC PATCH 3/5] hvc_console: Fix loop if put_char() returns 0
From: Hendrik Brueckner [EMAIL PROTECTED]
If put_char() routine of a hvc console backend returns 0, then the
hvc console starts looping in the following scenarios:
1. hvc_console_print()
If put_char() returns 0 then the while loop may loop forever.
I have added the missing check for 0 to throw away console messages.
2. khvcd may loop:
The thread calls hvc_poll() -- hvc_push()... if there are still
buffered data then the HVC_POLL_WRITE bit is set and causes the
khvcd thread to loop (if yield() returns immediately).
However, instead of looping, the khvcd thread could sleep for
MIN_TIMEOUT (doing the same as for get_chars()).
The MIN_TIMEOUT is set if hvc_push() was not able to write
data to the backend. If data has been written, the timeout is
set to 0 to immediately re-schedule hvc_poll().
Reviewed-by: Christian Borntraeger [EMAIL PROTECTED]
Tested-by: Christian Borntraeger [EMAIL PROTECTED] (virtio_console)
Signed-off-by: Hendrik Brueckner [EMAIL PROTECTED]
---
drivers/char/hvc_console.c | 20 +++-
1 file changed, 11 insertions(+), 9 deletions(-)
--- a/drivers/char/hvc_console.c
+++ b/drivers/char/hvc_console.c
@@ -161,7 +161,7 @@ static void hvc_console_print(struct con
}
} else {
r = cons_ops[index]-put_chars(vtermnos[index], c, i);
- if (r 0) {
+ if (r = 0) {
/* throw away chars on error */
i = 0;
} else if (r 0) {
@@ -431,7 +431,7 @@ static void hvc_hangup(struct tty_struct
* Push buffered characters whether they were just recently buffered or waiting
* on a blocked hypervisor. Call this function with hp-lock held.
*/
-static void hvc_push(struct hvc_struct *hp)
+static int hvc_push(struct hvc_struct *hp)
{
int n;
@@ -439,7 +439,7 @@ static void hvc_push(struct hvc_struct *
if (n = 0) {
if (n == 0) {
hp-do_wakeup = 1;
- return;
+ return 0;
}
/* throw away output on error; this happens when
there is no session connected to the vterm. */
@@ -450,6 +450,8 @@ static void hvc_push(struct hvc_struct *
memmove(hp-outbuf, hp-outbuf + n, hp-n_outbuf);
else
hp-do_wakeup = 1;
+
+ return n;
}
static int hvc_write(struct tty_struct *tty, const unsigned char *buf, int
count)
@@ -538,16 +540,20 @@ int hvc_poll(struct hvc_struct *hp)
char buf[N_INBUF] __ALIGNED__;
unsigned long flags;
int read_total = 0;
+ int written_total = 0;
spin_lock_irqsave(hp-lock, flags);
/* Push pending writes */
if (hp-n_outbuf 0)
- hvc_push(hp);
+ written_total = hvc_push(hp);
/* Reschedule us if still some write pending */
- if (hp-n_outbuf 0)
+ if (hp-n_outbuf 0) {
poll_mask |= HVC_POLL_WRITE;
+ /* If hvc_push() was not able to write, sleep a few msecs */
+ timeout = (written_total) ? 0 : MIN_TIMEOUT;
+ }
/* No tty attached, just skip */
tty = hp-tty;
@@ -659,10 +665,6 @@ static int khvcd(void *unused)
poll_mask |= HVC_POLL_READ;
if (hvc_kicked)
continue;
- if (poll_mask HVC_POLL_WRITE) {
- yield();
- continue;
- }
set_current_state(TASK_INTERRUPTIBLE);
if (!hvc_kicked) {
if (poll_mask == 0)
--
Hendrik Brueckner
D/3303 Linux on System z Development
Tel: +49 7031 16-1073
Fax: +49 7031 16-3456
eMail: [EMAIL PROTECTED]
IBM Deutschland Research Development GmbH, Schoenaicher Str. 220, 71032
Boeblingen
IBM Deutschland Research Development GmbH
Vorsitzender des Aufsichtsrats: Martin Jetter
Geschaeftsfuehrung: Erich Baier
Sitz der Gesellschaft: Boeblingen
Registergericht: Amtsgericht Stuttgart, HRB 243294
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [RFC PATCH 4/5] hvc_console: Add tty window resizing
+ hp = container_of(work, struct hvc_struct, tty_resize); + if (!hp || !hp-tty) + return; What locks hp-tty here, it can go NULL after the test on a hangup it seems ? + * hvc_resize() - Update terminal window size information. + * @hp: HVC console pointer + * @ws: Terminal window size structure See tty_do_resize() for all of this stuff in the latest git. If you can't use tty_do_resize from your work queue then please let me know why as I'd like everyone to be using one abstraction. We also now have a resize operation for devices that want to react to a resize from TIOCSWINSZ ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Please pull 'next' branch of git://git.secretlab.ca/git/linux-2.6-mpc52xx
Hello Grant, On Thu, Oct 09, 2008 at 02:02:41AM -0600, Grant Likely wrote: Wolfram Sang (1): powerpc/mpc5200: trivial printk-fixes in mpc52xx_common Thanks. What about these? :) http://oldpatchwork.ozlabs.org/linuxppc-embedded/patch?id=20188 (remove obsolete code from mpc52xx_phy) http://oldpatchwork.ozlabs.org/linuxppc-embedded/patch?id=20189 (simplify read/write in mpc52xx_phy) We use them for some time now and there are no bad side-effects. And to which tree did this one go? I couldn't find it on git.secretlab.ca. http://oldpatchwork.ozlabs.org/linuxppc-embedded/patch?id=20202 (don't touch pipelining) All the best, Wolfram -- Dipl.-Ing. Wolfram Sang | http://www.pengutronix.de Pengutronix - Linux Solutions for Science and Industry signature.asc Description: Digital signature ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[RFC PATCH 4/5] hvc_console: Add tty window resizing
From: Hendrik Brueckner [EMAIL PROTECTED]
The patch provides the hvc_resize() function to update the terminal
window dimensions (struct winsize) for a specified hvc console.
The function stores the new window size and schedules a function
that finally updates the tty winsize and signals the change to
user space (SIGWINCH).
Because the winsize update must acquire a mutex and might sleep,
the function is scheduled instead of being called from hvc_poll()
or khvcd.
Acked-by: Christian Borntraeger [EMAIL PROTECTED]
Signed-off-by: Hendrik Brueckner [EMAIL PROTECTED]
---
drivers/char/hvc_console.c | 61 +
drivers/char/hvc_console.h |6
2 files changed, 67 insertions(+)
--- a/drivers/char/hvc_console.c
+++ b/drivers/char/hvc_console.c
@@ -494,6 +494,48 @@ static int hvc_write(struct tty_struct *
return written;
}
+/**
+ * hvc_set_winsz() - Resize the hvc tty terminal window.
+ * @work: work structure.
+ *
+ * The routine shall not be called within an atomic context because it
+ * acquires the tty termios mutex and might sleep.
+ *
+ * Locking:hp-lock, tty-termios_mutex and tty-ctrl_lock
+ */
+static void hvc_set_winsz(struct work_struct *work)
+{
+ struct hvc_struct *hp;
+ struct pid *pgrp;
+ unsigned long hvc_flags;
+ unsigned long ctrl_flags;
+
+ hp = container_of(work, struct hvc_struct, tty_resize);
+ if (!hp || !hp-tty)
+ return;
+
+ mutex_lock(hp-tty-termios_mutex);
+ spin_lock_irqsave(hp-lock, hvc_flags);
+
+ if ((hp-ws.ws_row == hp-tty-winsize.ws_row)
+ (hp-ws.ws_col == hp-tty-winsize.ws_col))
+ goto out_mutex_unlock;
+
+ spin_lock_irqsave(hp-tty-ctrl_lock, ctrl_flags);
+ pgrp = get_pid(hp-tty-pgrp);
+ spin_unlock_irqrestore(hp-tty-ctrl_lock, ctrl_flags);
+
+ if (pgrp)
+ kill_pgrp(pgrp, SIGWINCH, 1);
+ put_pid(pgrp);
+
+ hp-tty-winsize = hp-ws;
+
+out_mutex_unlock:
+ spin_unlock_irqrestore(hp-lock, hvc_flags);
+ mutex_unlock(hp-tty-termios_mutex);
+}
+
/*
* This is actually a contract between the driver and the tty layer outlining
* how much write room the driver can guarantee will be sent OR BUFFERED. This
@@ -638,6 +680,24 @@ int hvc_poll(struct hvc_struct *hp)
}
EXPORT_SYMBOL_GPL(hvc_poll);
+/**
+ * hvc_resize() - Update terminal window size information.
+ * @hp:HVC console pointer
+ * @ws:Terminal window size structure
+ *
+ * Stores the specified window size information in the hvc structure of @hp.
+ * The function schedule the tty resize update.
+ *
+ * Locking:Locking free; the function MUST be called holding hp-lock
+ */
+void hvc_resize(struct hvc_struct *hp, struct winsize ws)
+{
+ if ((hp-ws.ws_row != ws.ws_row) || (hp-ws.ws_col != ws.ws_col)) {
+ hp-ws = ws;
+ schedule_work(hp-tty_resize);
+ }
+}
+
/*
* This kthread is either polling or interrupt driven. This is determined by
* calling hvc_poll() who determines whether a console adapter support
@@ -720,6 +780,7 @@ struct hvc_struct __devinit *hvc_alloc(u
kref_init(hp-kref);
+ INIT_WORK(hp-tty_resize, hvc_set_winsz);
spin_lock_init(hp-lock);
spin_lock(hvc_structs_lock);
--- a/drivers/char/hvc_console.h
+++ b/drivers/char/hvc_console.h
@@ -27,6 +27,7 @@
#ifndef HVC_CONSOLE_H
#define HVC_CONSOLE_H
#include linux/kref.h
+#include linux/tty.h
/*
* This is the max number of console adapters that can/will be found as
@@ -56,6 +57,8 @@ struct hvc_struct {
struct hv_ops *ops;
int irq_requested;
int data;
+ struct winsize ws;
+ struct work_struct tty_resize;
struct list_head next;
struct kref kref; /* ref count hvc_struct lifetime */
};
@@ -84,6 +87,9 @@ extern int __devexit hvc_remove(struct h
int hvc_poll(struct hvc_struct *hp);
void hvc_kick(void);
+/* Resize hvc tty terminal window */
+extern void hvc_resize(struct hvc_struct *hp, struct winsize ws);
+
/* default notifier for irq based notification */
extern int notifier_add_irq(struct hvc_struct *hp, int data);
extern void notifier_del_irq(struct hvc_struct *hp, int data);
--
Hendrik Brueckner
D/3303 Linux on System z Development
Tel: +49 7031 16-1073
Fax: +49 7031 16-3456
eMail: [EMAIL PROTECTED]
IBM Deutschland Research Development GmbH, Schoenaicher Str. 220, 71032
Boeblingen
IBM Deutschland Research Development GmbH
Vorsitzender des Aufsichtsrats: Martin Jetter
Geschaeftsfuehrung: Erich Baier
Sitz der Gesellschaft: Boeblingen
Registergericht: Amtsgericht Stuttgart, HRB 243294
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: pca9539 I2C gpio expander
On Tue, Oct 14, 2008 at 02:10:25PM -0400, Steven A. Falco wrote:
I am attempting to use a pca9539 I2C gpio driver on a PPC440EPx board. The
driver is drivers/gpio/pca953x.c. I've added an entry to the .dts file:
IIC0: [EMAIL PROTECTED] {
compatible = ibm,iic-440epx, ibm,iic;
...
[EMAIL PROTECTED] {
compatible = ti,pca9539;
reg = 76;
};
};
of_register_i2c_devices sees this entry and calls i2c_new_device.
i2c_new_device copies info-platform_data to client-dev.platform_data, but
I think that this structure is empty (at least I don't see where
of_register_i2c_devices would set it).
Currently there is no way to pass platform_data to I2C devices
(using device tree, that is). This is known limitation.
pca953x_probe is eventually called, but it expects to find its lowest gpio
number in client-dev.platform_data-gpio_base, which has not been set. So
pca953x_probe returns -ENODEV.
I don't understand where the disconnect is. Should I be able to use the
pca953x.c driver, or is it somehow incompatible?
If it is incompatible, is there a strategy for making it compatible?
We should write OF bindings for that driver. Unfortunately
this isn't easy for I2C devices, since they don't (and probably
should not) know anything about OF...
I have some ideas on how to teach all the I2C GPIO drivers
about the OF (without actually showing them any OF details).
I'll post it soon.
--
Anton Vorontsov
email: [EMAIL PROTECTED]
irc://irc.freenode.net/bd2
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] powerpc: enforce a non-spe kernel build even on broken compilers
On Sep 1, 2008, at 9:23 AM, Sebastian Siewior wrote: From: Thiemo Seufer [EMAIL PROTECTED] those two are requried on my fresh gcc 4.3.1 Signed-off-by: Thiemo Seufer [EMAIL PROTECTED] Signed-off-by: Sebastian Siewior [EMAIL PROTECTED] --- Not sure if this is intendent or a gcc bug but with -mno-spe the spe opcodes were not used floating point anymore but for 64bit save/restore for instance. what code is getting generated for you that is causing issue? arch/powerpc/Makefile |3 +++ 1 files changed, 3 insertions(+), 0 deletions(-) diff --git a/arch/powerpc/Makefile b/arch/powerpc/Makefile index b7d4c4c..3727e4f 100644 --- a/arch/powerpc/Makefile +++ b/arch/powerpc/Makefile @@ -108,7 +108,10 @@ endif KBUILD_CFLAGS += $(call cc-option,-mno-altivec) # No SPE instruction when building kernel +# (We use all available options to help semi-broken compilers) KBUILD_CFLAGS += $(call cc-option,-mno-spe) +KBUILD_CFLAGS += $(call cc-option,-mspe=no) Why does -mno-spe work? From my gcc-4.3 info pages: `-mspe=YES/NO' This option has been deprecated. Use `-mspe' and `-mno-spe' instead. +KBUILD_CFLAGS += $(call cc-option,-mabi=no-spe) is the -mabi=no-spe really needed? - k ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] Add new framebuffer driver for Fujitsu MB862xx GDCs
Matteo Fortini wrote:
Carminefb driver, though, supports 800x600 resolution.
if you use this patch below
diff --git a/drivers/video/mb862xx/mb862xxfb.c
b/drivers/video/mb862xx/mb862xxfb.c
index 26b66cb..904a111 100644
--- a/drivers/video/mb862xx/mb862xxfb.c
+++ b/drivers/video/mb862xx/mb862xxfb.c
@@ -218,6 +218,8 @@ static int mb862xxfb_set_par(struct fb_info *fbi)
if (par-pre_init)
return 0;
+ fbi-fix.line_length = (fbi-var.xres_virtual *
+ fbi-var.bits_per_pixel) / 8;
/* disp off */
reg = inreg(disp, GC_DCM1);
reg = ~GC_DCM01_DEN;
and something like this in user space:
int fd;
struct fb_var_screeninfo var_info;
if ((fd=open(/dev/fb0, O_RDWR))==-1) {
fprintf(stderr, Cannot open /dev/fb0\n);
exit(1);
}
var_info.xres = 800;
var_info.yres = 600;
var_info.xres_virtual = 800;
var_info.yres_virtual = 600;
var_info.pixclock = 25000;
var_info.left_margin = 88;
var_info.right_margin = 40;
var_info.lower_margin = 1;
var_info.upper_margin = 23;
var_info.hsync_len = 128;
var_info.vsync_len = 4;
if (ioctl(fd, FBIOPUT_VSCREENINFO, var_info)0) {
fprintf(stderr, Cannot set fb var_info\n);
exit(1);
}
than 800x600 resolution should be possible too. Also 1024x768
resolution should be possible with appropriate parameters.
BTW, I tried this patch and I get wrong colors on a patched DirectFB
which is changing the endianness on the fly. Is this driver already
taking care of this?
I don't know how it behaves with DirectFB. But to get proper
framebuffer console colors with carmine/coralp GDCs I used a
small patch below:
diff --git a/include/linux/fb.h b/include/linux/fb.h
index ae4ecdf..e998048 100644
--- a/include/linux/fb.h
+++ b/include/linux/fb.h
@@ -891,11 +891,11 @@ struct fb_info {
#define fb_readb __raw_readb
#define fb_readw __raw_readw
-#define fb_readl __raw_readl
+#define fb_readl readl
#define fb_readq __raw_readq
#define fb_writeb __raw_writeb
#define fb_writew __raw_writew
-#define fb_writel __raw_writel
+#define fb_writel writel
#define fb_writeq __raw_writeq
#define fb_memset memset_io
Best regards,
Anatolij
--
DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: [EMAIL PROTECTED]
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: MPC8321, ethernet and i2c problems after upgrade from 2.6.25 to 2.6.27
On Tue, Oct 14, 2008 at 09:55:31AM +0200, Joakim Tjernlund wrote: On Mon, 2008-10-13 at 14:03 -0500, Scott Wood wrote: Joakim Tjernlund wrote: Because all the kernel comments I can see still implies that this should work Which kernel comments? The one already mentioned and in i2c-boardinfo.c I already addressed the one already mentioned (it was sloppy terminology in the comment, written from the perspective of devtree-less arches). The latter is even less clear, as it doesn't mention dynamic buses at all. Feel free to submit a documentation patch clearing it up. :-) and because this was the only way in earlier releases to add an i2c device. We've supported enumerating i2c-mpc devices using the device tree for almost as long as there's been new-style i2c devices. Don't know how long that has been but looking at the mpc832x_mds dts file it has been there less than a year. commit d13ae8620dfdedfa7e9ab6d1eec294adc0516065 added i2c device probing from the device tree in 7/21/07, less than 3 months after new-style i2c devices were added to the i2c core. There were patches floating around the lists for longer than that. Why not? U-boot allows you to pass in a device tree dynamically. I don't use a dynamic device tree, mine is built in. So do a fixup in your board code. I'm not sure how you would even go about building a device tree into U-boot currently, though. -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[RFC PATCH 5/5] hvc_console: Remove __devexit annotation of hvc_remove()
From: Hendrik Brueckner [EMAIL PROTECTED]
Removed __devexit annotation of hvc_remove() to avoid a section mismatch
if the backend initialization fails and hvc_remove() must be used to
clean up allocated hvc structs (called in section __init or __devinit).
Acked-by: Christian Borntraeger [EMAIL PROTECTED]
Signed-off-by: Hendrik Brueckner [EMAIL PROTECTED]
---
drivers/char/hvc_console.c |2 +-
drivers/char/hvc_console.h |2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
--- a/drivers/char/hvc_console.c
+++ b/drivers/char/hvc_console.c
@@ -806,7 +806,7 @@ struct hvc_struct __devinit *hvc_alloc(u
}
EXPORT_SYMBOL_GPL(hvc_alloc);
-int __devexit hvc_remove(struct hvc_struct *hp)
+int hvc_remove(struct hvc_struct *hp)
{
unsigned long flags;
struct tty_struct *tty;
--- a/drivers/char/hvc_console.h
+++ b/drivers/char/hvc_console.h
@@ -81,7 +81,7 @@ extern int hvc_instantiate(uint32_t vter
extern struct hvc_struct * __devinit hvc_alloc(uint32_t vtermno, int data,
struct hv_ops *ops, int outbuf_size);
/* remove a vterm from hvc tty operation (module_exit or hotplug remove) */
-extern int __devexit hvc_remove(struct hvc_struct *hp);
+extern int hvc_remove(struct hvc_struct *hp);
/* data available */
int hvc_poll(struct hvc_struct *hp);
--
Hendrik Brueckner
D/3303 Linux on System z Development
Tel: +49 7031 16-1073
Fax: +49 7031 16-3456
eMail: [EMAIL PROTECTED]
IBM Deutschland Research Development GmbH, Schoenaicher Str. 220, 71032
Boeblingen
IBM Deutschland Research Development GmbH
Vorsitzender des Aufsichtsrats: Martin Jetter
Geschaeftsfuehrung: Erich Baier
Sitz der Gesellschaft: Boeblingen
Registergericht: Amtsgericht Stuttgart, HRB 243294
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[RFC PATCH 0/5] patches for a network-based hvc backend (s390)
Hello, I work on a network-based hvc console backend for s390 that allows to get full-screen terminal access to z/VM guest machines. The solution consists of a HVC backend that provides the terminal interface; and a tool to connect to the terminal via a z/VM specific communication protocol. The network-based backend differs in a few aspects from the notifier-based model of the HVC console; because it has to deal with (dis)connects and must take care of virtual tty hangups. Therefore, I would like to introduce a third notifier for hangups (see patch 1). Further I found out that if put_char() returns 0 in particular cases, the hvc console starts to loop. I tried to address this problem with patch 3 and I hope that it will work for all backends. Finally, I would like to add a function that allows to resize the terminal window of a HVC terminal (patch 4). Here is an overview about the complete patch series: Patch 1 adds a hangup notifier Patch 2 adds tty driver flag TTY_DRIVER_RESET_TERMIOS Patch 3 fixes a loop if put_char() returns 0 Patch 4 adds a function to resize the tty window Patch 5 removes __devexit of hvc_remove() for use in __(dev)init sections Any review feedback would be greatly appreciated. Thank you in advance. Regards, Hendrik -- Hendrik Brueckner D/3303 Linux on System z Development Tel: +49 7031 16-1073 Fax: +49 7031 16-3456 eMail: [EMAIL PROTECTED] IBM Deutschland Research Development GmbH, Schoenaicher Str. 220, 71032 Boeblingen IBM Deutschland Research Development GmbH Vorsitzender des Aufsichtsrats: Martin Jetter Geschaeftsfuehrung: Erich Baier Sitz der Gesellschaft: Boeblingen Registergericht: Amtsgericht Stuttgart, HRB 243294 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [2.6.26 Power5 64bit] oops in ._spin_unlock_irqrestore
(cc's added) While running my modrobe/rmmod script I got the following oops on a Linux LPAR on a Power5 system: [ 1867.960287] ipr: IBM Power RAID SCSI Device Driver version: 2.4.1 (April 24, 2007) [ 1867.961133] ipr :c0:01.0: Found IOA with IRQ: 321 [ 1867.967519] ipr :c0:01.0: Initializing IOA. [ 1867.979202] Unable to handle kernel paging request for data at address 0xd012b838 [ 1867.979220] Faulting instruction address: 0xc02de1c8 [ 1867.979232] Oops: Kernel access of bad area, sig: 11 [#1] [ 1867.979243] SMP NR_CPUS=32 NUMA pSeries [ 1867.979265] Modules linked in: ipr(+) loop windfarm_max6690_sensor sr_mod sg evdev snd_pcm snd_timer snd_hwdep compat_ioctl32 serio libps2 dm_log cdrom snd_usb_lib snd_page_alloc libata firmware_class snd_rawmidi snd_seq_device videodev dm_mod v4l1_compat ipv6 snd soundcore ibmveth ext3 jbd mbcache sd_mod ibmvscsic scsi_transport_srp scsi_tgt scsi_mod windfarm_smu_sat windfarm_cpufreq_clamp windfarm_core [last unloaded: atkbd] [ 1867.979488] NIP: c02de1c8 LR: d0130878 CTR: c02de1a8 [ 1867.979500] REGS: c000fc40fb40 TRAP: 0300 Not tainted (2.6.26-1-powerpc64) [ 1867.979510] MSR: 80009032 EE,ME,IR,DR CR: 2422 XER: 2001 [ 1867.979533] DAR: d012b838, DSISR: 4000 [ 1867.979543] TASK = c000fbc1d620[959] 'kseriod' THREAD: c000fc40c000 CPU: 7 [ 1867.979554] GPR00: d0130878 c000fc40fdc0 c05f9578 d012b830 [ 1867.979583] GPR04: d012b830 c05dc458 c000ffa0 [ 1867.979602] GPR08: c000fc40faf0 0003 d0134048 c02de1a8 [ 1867.979637] GPR12: d0130ca8 c0624200 [ 1867.979678] GPR16: 41c0 [ 1867.979715] GPR20: c05200c0 02120330 006b6000 c0520330 [ 1867.979743] GPR24: 021200c0 c0628a30 c051ed28 [ 1867.979782] GPR28: 0001 c000fb61a540 c059e558 d012b7e0 [ 1867.979813] NIP [c02de1c8] .driver_attach+0x20/0x40 [ 1867.979839] LR [d0130878] .serio_thread+0x1fc/0x42c [serio] [ 1867.979869] Call Trace: [ 1867.979881] [c000fc40fdc0] [c03d8624] ._spin_unlock_irqrestore+0x50/0x64 (unreliable) [ 1867.979927] [c000fc40fe40] [d0130878] .serio_thread+0x1fc/0x42c [serio] [ 1867.979955] [c000fc40ff00] [c00890f8] .kthread+0x78/0xc4 [ 1867.979979] [c000fc40ff90] [c00252ac] .kernel_thread+0x4c/0x68 [ 1867.980015] Instruction dump: [ 1867.980028] eb81ffe0 eba1ffe8 7c0803a6 4e800020 7c0802a6 fbc1fff0 ebc2b670 7c651b78 [ 1867.980070] 3880 f8010010 f821ff81 e8de8010 e8630008 4bfff5e1 6000 38210080 [ 1867.985180] ---[ end trace 16968366a5589005 ]--- The trigger script can be found here: http://www.vanheusden.com/pyk/ It looks more like a bug in the input code than powerpc. Not sure if it matters but I run that script from an ssh session. If it does matter I can run it from within a virtual terminal as well? Folkert van Heusden -- -- Phone: +31-6-41278122, PGP-key: 1F28D8AE, www.vanheusden.com ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] powerpc: enforce a non-spe kernel build even on broken compilers
On Tue, 2008-10-14 at 16:23 -0500, Kumar Gala wrote: Why does -mno-spe work? From my gcc-4.3 info pages: `-mspe=YES/NO' This option has been deprecated. Use `-mspe' and `-mno-spe' instead. +KBUILD_CFLAGS += $(call cc-option,-mabi=no-spe) is the -mabi=no-spe really needed? My guess is that the -mabi=no-spe was the real key of what made it work for him. I went through the same thing with my toolchain. You do need -mabi=no-spe if your toolchain defaults to -mabi=spe like mine does. I know that the more generic toolchains out there (CodeSourcery, ELDK) default to -mabi=no-spe, so in that case it would not be necessary. I don't know what generated instructions are actually to blame, but I do know that if you compile certain programs with -mno-spe -mabi=spe vs. -mno-spe -mabi=no-spe, the results will differ. In the case of the kernel, you'll get a bunch of SPE used in kernel messages with the -mno-spe -mabi=spe combination. - Nate Case [EMAIL PROTECTED] ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] powerpc: enforce a non-spe kernel build even on broken compilers
* Kumar Gala | 2008-10-14 16:23:05 [-0500]: Not sure if this is intendent or a gcc bug but with -mno-spe the spe opcodes were not used floating point anymore but for 64bit save/restore for instance. what code is getting generated for you that is causing issue? Without the patch do_syslog() looks like this: |c0025840 do_syslog: |c0025840: 94 21 ff 50 stwur1,-176(r1) |c0025844: 7c 08 02 a6 mflrr0 |c0025848: 13 21 73 21 evstdd r25,112(r1) |c002584c: 13 41 7b 21 evstdd r26,120(r1) |c0025850: 7c 9a 23 78 mr r26,r4 |c0025854: 13 61 83 21 evstdd r27,128(r1) |c0025858: 7c bb 2b 78 mr r27,r5 |c002585c: 13 e1 a3 21 evstdd r31,160(r1) |c0025860: 7c 7f 1b 78 mr r31,r3 |c0025864: 90 01 00 b4 stw r0,180(r1) |c0025868: 12 21 33 21 evstdd r17,48(r1) |c002586c: 12 41 3b 21 evstdd r18,56(r1) |c0025870: 12 61 43 21 evstdd r19,64(r1) |c0025874: 12 81 4b 21 evstdd r20,72(r1) |c0025878: 12 a1 53 21 evstdd r21,80(r1) |c002587c: 12 c1 5b 21 evstdd r22,88(r1) |c0025880: 12 e1 63 21 evstdd r23,96(r1) |c0025884: 13 01 6b 21 evstdd r24,104(r1) |c0025888: 13 81 8b 21 evstdd r28,136(r1) |c002588c: 13 a1 93 21 evstdd r29,144(r1) |c0025890: 13 c1 9b 21 evstdd r30,152(r1) |c0025894: 48 0f 00 b5 bl c0115948 cap_syslog |c0025898: 7c 79 1b 79 mr. r25,r3 |c002589c: 40 82 04 54 bne-c0025cf0 do_syslog+0x4b0 |c00258a0: 2b 9f 00 0a cmplwi cr7,r31,10 |c00258a4: 41 9d 04 40 bgt-cr7,c0025ce4 do_syslog+0x4a4 |c00258a8: 3d 20 c0 27 lis r9,-16345 |c00258ac: 57 e0 10 3a rlwinm r0,r31,2,0,29 |c00258b0: 39 29 a6 e4 addir9,r9,-22812 |c00258b4: 7c 09 00 2e lwzxr0,r9,r0 |c00258b8: 7c 00 4a 14 add r0,r0,r9 |c00258bc: 7c 09 03 a6 mtctr r0 |c00258c0: 4e 80 04 20 bctr |c00258c4: 3b e0 00 00 li r31,0 do_syslog() is not the only one. 1 files changed, 3 insertions(+), 0 deletions(-) diff --git a/arch/powerpc/Makefile b/arch/powerpc/Makefile index b7d4c4c..3727e4f 100644 --- a/arch/powerpc/Makefile +++ b/arch/powerpc/Makefile @@ -108,7 +108,10 @@ endif KBUILD_CFLAGS += $(call cc-option,-mno-altivec) # No SPE instruction when building kernel +# (We use all available options to help semi-broken compilers) KBUILD_CFLAGS += $(call cc-option,-mno-spe) +KBUILD_CFLAGS += $(call cc-option,-mspe=no) Why does -mno-spe work? Good question. Without this option and only with -mabi=no-spe the do_syslog() looks like the following: |c0025270 do_syslog: |c0025270: 94 21 ff 90 stwur1,-112(r1) |c0025274: 7c 08 02 a6 mflrr0 |c0025278: be 21 00 34 stmwr17,52(r1) |c002527c: 7c 9a 23 78 mr r26,r4 |c0025280: 90 01 00 74 stw r0,116(r1) |c0025284: 7c bb 2b 78 mr r27,r5 |c0025288: 7c 7f 1b 78 mr r31,r3 |c002528c: 48 0e ce c5 bl c0112150 cap_syslog |c0025290: 7c 79 1b 79 mr. r25,r3 |c0025294: 40 82 04 54 bne-c00256e8 do_syslog+0x478 |c0025298: 2b 9f 00 0a cmplwi cr7,r31,10 |c002529c: 41 9d 04 40 bgt-cr7,c00256dc do_syslog+0x46c |c00252a0: 3d 20 c0 26 lis r9,-16346 |c00252a4: 57 e0 10 3a rlwinm r0,r31,2,0,29 |c00252a8: 39 29 36 e4 addir9,r9,14052 |c00252ac: 7c 09 00 2e lwzxr0,r9,r0 |c00252b0: 7c 00 4a 14 add r0,r0,r9 |c00252b4: 7c 09 03 a6 mtctr r0 |c00252b8: 4e 80 04 20 bctr |c00252bc: 3b e0 00 00 li r31,0 |c00252c0: 48 00 01 c4 b c0025484 do_syslog+0x214 |c00252c4: 2f 9a 00 00 cmpwi cr7,r26,0 |c00252c8: 41 9e 04 14 beq-cr7,c00256dc do_syslog+0x46c |c00252cc: 2f 9b 00 00 cmpwi cr7,r27,0 |c00252d0: 41 9c 04 0c blt-cr7,c00256dc do_syslog+0x46c |c00252d4: 41 9e 04 14 beq-cr7,c00256e8 do_syslog+0x478 |c00252d8: 80 02 03 3c lwz r0,828(r2) |c00252dc: 7f 9a 00 40 cmplw cr7,r26,r0 |c00252e0: 41 9d 04 04 bgt-cr7,c00256e4 do_syslog+0x474 |c00252e4: 7c 1a 00 50 subfr0,r26,r0 |c00252e8: 39 3b ff ff addir9,r27,-1 |c00252ec: 7f 89 00 40 cmplw cr7,r9,r0 |c00252f0: 41 9d 03 f4 bgt-cr7,c00256e4 do_syslog+0x474 |c00252f4: 3d 20 c0 39 lis r9,-16327 |c00252f8: 39 09 8e f8 addir8,r9,-28936 |c00252fc: 81 29 8e f8 lwz r9,-28936(r9) |c0025300: 80 08 00 04 lwz r0,4(r8) |c0025304: 7f 80 48 00 cmpwcr7,r0,r9 |c0025308: 40 be 00 a4 bne+cr7,c00253ac do_syslog+0x13c |c002530c: 3d 20 c0 04 lis r9,-16380 |c0025310: 39 61 00 14 addir11,r1,20
Re: [PATCH V2 4/4] POWERPC: Merge 32 and 64-bit dma code
On Oct 14, 2008, at 7:05 AM, Benjamin Herrenschmidt wrote: On Tue, 2008-10-14 at 06:24 -0400, Josh Boyer wrote: I pointed out to Stephen that kisskb.ellerman.id.au hasn't been updating.. there is a chrp32 defconfig in there that would normally catch something like this. Except if kissb catches it, it's already committed in tree. Better than nothing, but it would be nice if people did a buildall before they commit. I have a script that builds a dozen of config's, it looks like it didn't catch that one. I'm going to add a chrp32_defconfig to it. Mistakes happen, hopefully we can at least make sure the common configs are well tested. Blah. I thought I had built everything before I pushed this stuff out. My apologies (and also for being offline for when the fun occurred here I just got back from vacation this morning.) Ben, thanks for fixing - let me know if there's anything you need from my end. -B ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[git pull] Please pull from powerpc.git next branch
Hi Linus ! Here's the powerpc main batch for 2.6.28. It's a bit late mostly due to both Paul and I being distracted by other things at the wrong time, and me trying to run some more tests ( fixing regressions) before sending it all to you. There's a bunch of stuff in there, most of it in arch/powerpc, but you'll notice a few things touching files out of it. Here's a short summary of these: - These are just a trivial change of CONFIG_PPC_MERGE - CONFIG_PPC since the former is no longer useful now that arch/ppc is gone drivers/block/floppy.c drivers/char/ipmi/ipmi_si_intf.c drivers/i2c/busses/i2c-pca-isa.c drivers/input/serio/i8042-io.h drivers/pnp/isapnp/core.c drivers/pnp/pnpbios/core.c - Some other trivial #include fixes for the move of of_device.h from asm/ to linux/ drivers/hwmon/ams/ams.h sound/aoa/soundbus/soundbus.h - The math-emu changes are two fold. Some trivial compile warning fixes and some changes to improve exception reporting acked by davem. Now powerpc uses the generic math-emu code too - Some powerpc specific drivers. They should all have appropriate acks with the possible exception of the pata_of_platform.c one which I merged in while jeff was away and hvc_console for which I believe we are still maintainers of. - Some drivers/of additions that should (hopefully) be of no impact to other users of the OF stuff - a procfs change removing our obsolete ppc_htab stuff And that should be it, hopefully I didn't miss anything :-) I did a merge with your tree to fixup a couple of conflicts so it should be a smooth merge on your side. Cheers, Ben. The following changes since commit 8acd3a60bcca17c6d89c73cee3ad6057eb83ba1e: Linus Torvalds (1): Merge branch 'for-2.6.28' of git://linux-nfs.org/~bfields/linux are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/benh/powerpc.git next Adrian Bunk (1): powerpc: Use bcd2bin/bin2bcd Anton Vorontsov (12): powerpc/83xx: mpc836x_mds: add support for the nor flash powerpc/fsl_soc: remove mpc83xx_wdt code OF: add fsl,mcu-mpc8349emitx to the exception list powerpc: Fix no interrupt handling in pata_of_platform of: Add new helper of_parse_phandles_with_args() powerpc/QE: move QE_GPIO Kconfig symbol into the platforms/Kconfig powerpc/83xx: don't probe broken PCI on mpc837x_mds boards powerpc/83xx: add DS1374 RTC support for the MPC837xE-MDS boards OF: add fsl,mcu-mpc8349emitx to the exception list i2c: MPC8349E-mITX Power Management and GPIO expander driver powerpc/83xx: add NAND support for the MPC8360E-RDK boards powerpc: fix fsl_upm nand driver modular build Becky Bruce (10): powerpc: Rename PTE_SIZE to HPTE_SIZE powerpc/85xx: fix build warning, remove silly cast cpm_uart: Pass actual dev ptr to dma_* in ucc and cpm_uart serial powerpc: Rename dma_64.c to dma.c powerpc: Move iommu dma ops from dma.c to dma-iommu.c powerpc: Drop archdata numa_node powerpc: Merge 32 and 64-bit dma code powerpc: Make dma_addr_t a u64 if CONFIG_PHYS_64BIT is set POWERPC: Allow 32-bit hashed pgtable code to support 36-bit physical powerpc: Drop redundant machine type print in show_cpuinfo Benjamin Herrenschmidt (16): powerpc: Turn get/set_hard_smp_proccessor_id into inlines powerpc: Expose PMCs cache topology in sysfs on 32-bit Merge commit 'kumar/kumar-dma' Merge commit 'kumar/kumar-mmu' Merge commit 'jwb/jwb-next' powerpc: Fix sysfs pci mmap on 32-bit machines with 64-bit PCI Merge commit 'jk/jk-merge' Merge commit 'gcl/gcl-next' Merge commit 'kumar/kumar-next' powerpc: Fix DMA offset for non-coherent DMA powerpc/pci: Improve detection of unassigned bridge resources powerpc: Fix link errors on 32-bit machines using legacy DMA powerpc: Fix 32-bit SMP boot on CHRP powerpc/chrp: Fix detection of Python PCI host bridge on IBM CHRPs powerpc: Fix CHRP PCI config access for indirect_pci Merge commit 'origin' Chandru (1): powerpc: Add support for dynamic reconfiguration memory in kexec/kdump kernels Christian Borntraeger (1): hvc_console: Fix free_irq in spinlocked section Christoph Hellwig (1): powerpc: Use sys_pause for 32-bit pause entry point David Gibson (3): powerpc: Update in-kernel dtc and libfdt to version 1.2.0 powerpc: Clean up hugepage pagetable allocation for powerpc with 16G pages powerpc: Get USE_STRICT_MM_TYPECHECKS working again Geert Uytterhoeven (2): powerpc: Remove remains of /proc/ppc_htab powerpc: Remove outdated Documentation/powerpc/smp.txt Grant Likely (2): powerpc/mpc5200: fix build warnings on mpc52xx_psc_spi driver powerpc/of-bindings: Don't support linux,modalias compatible values Harvey Harrison (2):
Re: performance: memcpy vs. __copy_tofrom_user
Scott Wood wrote: BTW, it's actually simpler than I originally described (I had implemented this years ago in the TimeSys kernel for x86 and some other arches that already use FP or similar resources for memcpy, but the memory was a little fuzzy); the FP restore code doesn't need to test anything, it always restores from the regular spot. The kernel code wishing to use FP saves the user context in an alternate save area (it could even be on the stack, allowing atomic context to use it as well, if it's not too large), and restores it when it's done. Sure, it's simple, the problem is that VRSAVE isn't maintained in the kernel, which means for AltiVec context switches you need to save and restore 32 128-bit registers every time. And that takes a LONG time.. Just imagine if you did a ~512 byte memcpy, you could guarantee that it would take twice as long as it should! There are ways around it, like assembly and fixed registers, and saving the ones you use (this is the sort of thing gcc does for you usually, but you can do it by hand just as well) and restoring the ones you trashed afterwards, but that makes code messier and less readable. Not insurmountable problems, but it makes using AltiVec harder. You would have to really justify a speed increase. I think you could get that on cryptography functions easily. For page zero/copying, I think you would also get the increase to outweigh the prologue/epilogue required and also the loss of preemption. TCP/IP copy with checksum? Probably absolutely definitely.. Straight memcpy? I am not so sure. Like I said I am far more worried about how you'd get a reasonable benchmark out of it. Profiling kernels is a messy business.. -- Matt Sealey [EMAIL PROTECTED] Genesi, Manager, Developer Relations ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] powerpc: dtb and purgatory support for ppc32
On Sun, Oct 12, 2008 at 03:39:55PM +0200, Sebastian Andrzej Siewior wrote: * Simon Horman | 2008-10-08 14:03:26 [+1100]: +#ifdef WITH_GAMECUBE +static int go_purgatory = 0; +#else +static int go_purgatory = 1; +#endif Can you just use WITH_GAMECUBE inside elf_ppc_load() and remove the need for go_purgatory, or do you plan to make go_purgatory switchable at run-time at some point in the future? For the first shot I would prefer to use WITH_GAMECUBE inside of elf_ppc_load(). In longterm I don't see any reason why GameCube can't use the purgatory code like the other archs and get the memory maps from the device tree. However I'm not sure if GameCube still runs on a recent kernel: now that arc/ppc isn't available anymore GameCube has to pass a dtb somehow and this isn't the case. So therefore I would like the keep #ifdef and the exisiting behavior until someone clears this up. Ok, in this case I would like to request that you remove go_purgatory (for now) and just use #ifdef WITH_GAMECUBE instead. I think that it will make things cleaner (for now). -- Simon Horman VA Linux Systems Japan K.K., Sydney, Australia Satellite Office H: www.vergenet.net/~horms/ W: www.valinux.co.jp/en ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] powerpc: Silent SW timebase sync
When no HW method is provided to sync the timebase, linux uses
a software algorithm.
The code for that is very verbose using straight printk's without
log level. A lot of this is mostly useless unless you want to debug
the process, and we didn't have any problem with it for years anyway
so this turns the bunch of them into pr_debug.
Signed-off-by: Benjamin Herrenschmidt [EMAIL PROTECTED]
---
arch/powerpc/kernel/smp-tbsync.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
--- linux-work.orig/arch/powerpc/kernel/smp-tbsync.c2008-10-15
14:42:24.0 +1100
+++ linux-work/arch/powerpc/kernel/smp-tbsync.c 2008-10-15 15:23:03.0
+1100
@@ -113,7 +113,7 @@ void __devinit smp_generic_give_timebase
{
int i, score, score2, old, min=0, max=5000, offset=1000;
- printk(Synchronizing timebase\n);
+ pr_debug(Software timebase sync\n);
/* if this fails then this kernel won't work anyway... */
tbsync = kzalloc( sizeof(*tbsync), GFP_KERNEL );
@@ -123,13 +123,13 @@ void __devinit smp_generic_give_timebase
while (!tbsync-ack)
barrier();
- printk(Got ack\n);
+ pr_debug(Got ack\n);
/* binary search */
for (old = -1; old != offset ; offset = (min+max) / 2) {
score = start_contest(kSetAndTest, offset, NUM_ITER);
- printk(score %d, offset %d\n, score, offset );
+ pr_debug(score %d, offset %d\n, score, offset );
if( score 0 )
max = offset;
@@ -140,8 +140,8 @@ void __devinit smp_generic_give_timebase
score = start_contest(kSetAndTest, min, NUM_ITER);
score2 = start_contest(kSetAndTest, max, NUM_ITER);
- printk(Min %d (score %d), Max %d (score %d)\n,
- min, score, max, score2);
+ pr_debug(Min %d (score %d), Max %d (score %d)\n,
+min, score, max, score2);
score = abs(score);
score2 = abs(score2);
offset = (score score2) ? min : max;
@@ -155,7 +155,7 @@ void __devinit smp_generic_give_timebase
if (score2 = score || score2 20)
break;
}
- printk(Final offset: %d (%d/%d)\n, offset, score2, NUM_ITER );
+ pr_debug(Final offset: %d (%d/%d)\n, offset, score2, NUM_ITER );
/* exiting */
tbsync-cmd = kExit;
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] edac/cell: Fix incorrect edac_mode in csrow causing oops
The cell_edac driver is setting the edac_mode field of the csrow's to an incorrect value, causing the sysfs show routine for that field to go out of an array bound and Oopsing the kernel when used. Signed-off-by: Benjamin Herrenschmidt [EMAIL PROTECTED] --- drivers/edac/cell_edac.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- linux-work.orig/drivers/edac/cell_edac.c2008-10-15 15:35:21.0 +1100 +++ linux-work/drivers/edac/cell_edac.c 2008-10-15 15:35:29.0 +1100 @@ -142,7 +142,7 @@ static void __devinit cell_edac_init_csr csrow-nr_pages = (r.end - r.start + 1) PAGE_SHIFT; csrow-last_page = csrow-first_page + csrow-nr_pages - 1; csrow-mtype = MEM_XDR; - csrow-edac_mode = EDAC_FLAG_EC | EDAC_FLAG_SECDED; + csrow-edac_mode = EDAC_SECDED; dev_dbg(mci-dev, Initialized on node %d, chanmask=0x%x, first_page=0x%lx, nr_pages=0x%x\n, ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: gigE 2.6.27 USB
On Tue, 2008-10-14 at 03:52 -0700, Kevin Diggs wrote: Kevin Diggs wrote: Hi, I managed to wrestle my gigE to the ground and get it to boot 2.6.27. I have, however, noticed that some messages are showing up in dmesg. There are alot of them. They are continuous. They appear to come from drivers/usb/core/hub.c:2916. It looks like they come in pairs (this beast has two ports (root hubs)). I plugged in a USB CF reader. It appears to work. The keyboard and mouse (a Logitech wireless receiver) seems to work. 2.6.24 did not do this. kevin For what it is worth, I tricked a laptop into booting 2.6.27. It does not appear to generate these messages. The PowerMac is running Yellow Dog 4. It would be a lot more useful if you included informations in your report such as : - The actual error output - The full dmesg log - Informations about the adapter including output of lsusb -v - How do you actually trigger the problem It would be even more useful if you CC'ed some relevant list such as the linux-usb one too :-) Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PROBLEM] Soft lockup on Linux 2.6.27, 2 patches, Cell/PPC64
On Tue, 2008-10-14 at 11:32 +0200, Geert Uytterhoeven wrote: which points again to smp_call_function_single... Yup, it doesn't bring more information. At this stage, your 'other' CPU is stuck with interrupts disabled. Hard to tell what's happening without some HW assist. Do you have ways to trigger a non-maskable interrupt such as a 0x100 ? That would allow to catch the other guy in xmon and see what it was doing... It could be something in the ps3vram driver causing the kernel to lockup Now the question is whether the kernel is stuffed with something like a deadlock with interrupts off, or is it a HW problem causing a CPU to lockup on an access to the vram ? I'm afraid only you guys have tools that would allow to debug that sort of problem. Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
