Re: [PATCH] add Altivec/VMX state to coredumps
On Wed, 26 Sep 2007, Kumar Gala wrote: On Sep 25, 2007, at 11:56 PM, Mark Nelson wrote: What cores have SPE at the moment? Also, perhaps more importantly, are there any plans to have Altivec and SPE in the same core? The e500 cores's from Freescale. No, they are pretty much mutually exclusive. Bummer, only now do I realize this thread is not about the Synergistic Processing Elements but about the Signal Processing Extension... With kind regards, Geert Uytterhoeven Software Architect Sony Network and Software Technology Center Europe The Corporate Village · Da Vincilaan 7-D1 · B-1935 Zaventem · Belgium Phone:+32 (0)2 700 8453 Fax: +32 (0)2 700 8622 E-mail: [EMAIL PROTECTED] Internet: http://www.sony-europe.com/ Sony Network and Software Technology Center Europe A division of Sony Service Centre (Europe) N.V. Registered office: Technologielaan 7 · B-1840 Londerzeel · Belgium VAT BE 0413.825.160 · RPR Brussels Fortis Bank Zaventem · Swift GEBABEBB08A · IBAN BE39001382358619___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [patch 5/7] Use extended crashkernel command line on ppc64
Hi,
* Andrew Morton [EMAIL PROTECTED] [2007-09-25 21:45]:
On Tue, 25 Sep 2007 20:23:02 +0200 Bernhard Walle [EMAIL PROTECTED] wrote:
This patch adapts the ppc64 code to use the generic parse_crashkernel()
function introduced in the generic patch of that series.
I really don't like to see patches get a wholesale replacement, especially
when they've been looked at by a few people and have had some testing, etc.
It's not possible to see what changed and people need to re-review stuff
they've already reviewed, etc.
Sorry, I didn't know that this is the preferred way. I just thought
it's more clear if the patches are replaced if the patch set is
finally pushed into Linus' tree.
diff -puN
arch/powerpc/kernel/machine_kexec.c~use-extended-crashkernel-command-line-on-ppc64-update
arch/powerpc/kernel/machine_kexec.c
---
a/arch/powerpc/kernel/machine_kexec.c~use-extended-crashkernel-command-line-on-ppc64-update
+++ a/arch/powerpc/kernel/machine_kexec.c
@@ -63,7 +63,7 @@ NORET_TYPE void machine_kexec(struct kim
void __init reserve_crashkernel(void)
{
- unsigned long long crash_size = 0, crash_base;
+ unsigned long long crash_size, crash_base;
int ret;
/* this is necessary because of lmb_phys_mem_size() */
_
which I suspect will now create a compiler warning.
No, it doesn't. I just verified this.
CHK include/linux/compile.h
CC arch/powerpc/kernel/machine_kexec.o
LD arch/powerpc/kernel/built-in.o
Thanks,
Bernhard
--
Bernhard Walle [EMAIL PROTECTED], Architecture Maintenance
SUSE LINUX Products GmbH, Nürnberg, Germany
GF: Markus Rex, HRB 16746 (AG Nürnberg)
OpenPGP: F61F 34CC 09CA FB82 C9F6 BA4B 8865 3696 DDAF 6454
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 3/5] ibmebus: Add device creation and bus probing based on of_device
+/* These devices will automatically be added to the bus during init
*/
+static struct of_device_id builtin_matches[] = {
+ { .name = lhca },
+ { .compatible = IBM,lhca },
+ { .name = lhea },
+ { .compatible = IBM,lhea },
+ {},
+};
+
Hmm, do you have devices that only have the matching name property
but not the compatible property? If not, I'd suggest only looking
for compatible, so you have less chance of false positives.
If a device that's not an lhca is called lhca, that's its own fault, i
guess ;) But i concur that looking for the compatible property will
probably suffice.
+static int ibmebus_create_device(struct device_node *dn)
[...]
nice!
Thanks.
- rc = IS_ERR(dev) ? PTR_ERR(dev) : count;
+ rc = rc ? rc : count;
the last line looks a bit silly. Maybe instead do
rc = ibmebus_create_device(dn);
of_node_put(dn);
}
kfree(path);
if (rc)
return rc;
return count;
}
More code lines? ;) But yes, that looks more like standard kernel
pattern - I'll change that.
Joachim
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 2/5] ibmebus: Remove bus match/probe/remove functions
Arnd Bergmann [EMAIL PROTECTED] wrote on 25.09.2007 16:29:51:
The description makes it sound like a git-bisect would get broken
by this patch, which should never happen. If the patch indeed
ends up with a broken kernel, it would be better to merge it with
the later patch that fixes the code again.
I took extra care to prevent just that from happening. ibmebus will simply
be disabled during the transition (because of {un,}register_driver being
empty dummies), but the kernel builds and boots without problems. So
unless you're trying to find an ibmebus-based problem, git bisect will be
fine. I'll repost 2/5 with an updated description.
I split the ibmebus rework into three patches because the merged patch was
impossible to read. Makes reviewing easier.
Joachim
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 1/5] PowerPC: Move of_device allocation into of_device.[ch]
Arnd Bergmann [EMAIL PROTECTED] wrote on 25.09.2007 16:27:57: The patch looks good to me, especially since you did exactly what I suggested ;-) Yes, our discussions were very productive. Thanks and sorry I forgot to mention your input. Maybe the description should have another sentence in it about what the change is good for. You have that in the 0/5 mail, but that does not go into the changelog, so the information gets lost in the process. Can do. New patch coming right up! Joachim ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 0/5] [REPOST] PowerPC: ibmebus refactoring and fixes
This patchset will merge the ibmebus and of_platform bus drivers by basing a lot of ibmebus functionality on of_platform code and adding the features specific to ibmebus on top of that. This is a repost of my previous patchset incorporating Arnd's comments. I split the actual ibmebus rework into three patches (2/5-4/5) for easier readability. The kernel will compile during the intermediate states, and ibmebus will not crash, but not work either. As a side-effect of patch 3/5, a problem with bus_id collisions in case of two devices sharing the same location code is resolved -- the bus_id is now determined differently. [1/5] moves of_device allocation into of_device.[ch] [2/5] removes the old bus match/probe/remove functions [3/5] adds device creation and bus probing based on of_device [4/5] finally moves to of_device and of_platform_driver by changing ibmebus.h and matching the eHCA and eHEA drivers [5/5] just changes a nit in ibmebus_store_probe() These patches should apply cleanly, in order, against 2.6.23-rc5 and against Linus' git. Please review and comment them, and queue them up for 2.6.24 if you think they're okay. Thanks and regards, Joachim arch/powerpc/kernel/ibmebus.c | 267 - arch/powerpc/kernel/of_device.c | 80 + arch/powerpc/kernel/of_platform.c | 70 + drivers/infiniband/hw/ehca/ehca_classes.h |2 +- drivers/infiniband/hw/ehca/ehca_eq.c |6 +- drivers/infiniband/hw/ehca/ehca_main.c| 32 ++-- drivers/net/ehea/ehea.h |2 +- drivers/net/ehea/ehea_main.c | 72 include/asm-powerpc/ibmebus.h | 38 + include/asm-powerpc/of_device.h |4 + include/linux/of_device.h |5 + 11 files changed, 228 insertions(+), 350 deletions(-) -- Joachim Fenkes -- eHCA Linux Driver Developer and Hardware Tamer IBM Deutschland Entwicklung GmbH -- Dept. 3627 (I/O Firmware Dev. 2) Schoenaicher Strasse 220 -- 71032 Boeblingen -- Germany eMail: [EMAIL PROTECTED] ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 1/5] PowerPC: Move of_device allocation into of_device.[ch]
Extract generic of_device allocation code from of_platform_device_create()
and move it into of_device.[ch], called of_device_alloc(). Also, there's now
of_device_free() which puts the device node.
This way, bus drivers that build on of_platform (like ibmebus will) can
build upon this code instead of reinventing the wheel.
Signed-off-by: Joachim Fenkes [EMAIL PROTECTED]
---
include/asm-powerpc/of_device.h |4 ++
include/linux/of_device.h |5 ++
arch/powerpc/kernel/of_device.c | 80 +
arch/powerpc/kernel/of_platform.c | 70 +---
4 files changed, 91 insertions(+), 68 deletions(-)
diff --git a/include/asm-powerpc/of_device.h b/include/asm-powerpc/of_device.h
index ec2a8a2..9ab469d 100644
--- a/include/asm-powerpc/of_device.h
+++ b/include/asm-powerpc/of_device.h
@@ -17,6 +17,10 @@ struct of_device
struct device dev;/* Generic device interface */
};
+extern struct of_device *of_device_alloc(struct device_node *np,
+const char *bus_id,
+struct device *parent);
+
extern ssize_t of_device_get_modalias(struct of_device *ofdev,
char *str, ssize_t len);
extern int of_device_uevent(struct device *dev,
diff --git a/include/linux/of_device.h b/include/linux/of_device.h
index 91bf84b..212bffb 100644
--- a/include/linux/of_device.h
+++ b/include/linux/of_device.h
@@ -22,5 +22,10 @@ extern int of_device_register(struct of_device *ofdev);
extern void of_device_unregister(struct of_device *ofdev);
extern void of_release_dev(struct device *dev);
+static inline void of_device_free(struct of_device *dev)
+{
+ of_release_dev(dev-dev);
+}
+
#endif /* __KERNEL__ */
#endif /* _LINUX_OF_DEVICE_H */
diff --git a/arch/powerpc/kernel/of_device.c b/arch/powerpc/kernel/of_device.c
index 89b911e..ecb8b0e 100644
--- a/arch/powerpc/kernel/of_device.c
+++ b/arch/powerpc/kernel/of_device.c
@@ -7,8 +7,88 @@
#include linux/slab.h
#include asm/errno.h
+#include asm/dcr.h
#include asm/of_device.h
+static void of_device_make_bus_id(struct of_device *dev)
+{
+ static atomic_t bus_no_reg_magic;
+ struct device_node *node = dev-node;
+ char *name = dev-dev.bus_id;
+ const u32 *reg;
+ u64 addr;
+ int magic;
+
+ /*
+* If it's a DCR based device, use 'd' for native DCRs
+* and 'D' for MMIO DCRs.
+*/
+#ifdef CONFIG_PPC_DCR
+ reg = of_get_property(node, dcr-reg, NULL);
+ if (reg) {
+#ifdef CONFIG_PPC_DCR_NATIVE
+ snprintf(name, BUS_ID_SIZE, d%x.%s,
+*reg, node-name);
+#else /* CONFIG_PPC_DCR_NATIVE */
+ addr = of_translate_dcr_address(node, *reg, NULL);
+ if (addr != OF_BAD_ADDR) {
+ snprintf(name, BUS_ID_SIZE,
+D%llx.%s, (unsigned long long)addr,
+node-name);
+ return;
+ }
+#endif /* !CONFIG_PPC_DCR_NATIVE */
+ }
+#endif /* CONFIG_PPC_DCR */
+
+ /*
+* For MMIO, get the physical address
+*/
+ reg = of_get_property(node, reg, NULL);
+ if (reg) {
+ addr = of_translate_address(node, reg);
+ if (addr != OF_BAD_ADDR) {
+ snprintf(name, BUS_ID_SIZE,
+%llx.%s, (unsigned long long)addr,
+node-name);
+ return;
+ }
+ }
+
+ /*
+* No BusID, use the node name and add a globally incremented
+* counter (and pray...)
+*/
+ magic = atomic_add_return(1, bus_no_reg_magic);
+ snprintf(name, BUS_ID_SIZE, %s.%d, node-name, magic - 1);
+}
+
+struct of_device *of_device_alloc(struct device_node *np,
+ const char *bus_id,
+ struct device *parent)
+{
+ struct of_device *dev;
+
+ dev = kzalloc(sizeof(*dev), GFP_KERNEL);
+ if (!dev)
+ return NULL;
+
+ dev-node = of_node_get(np);
+ dev-dev.dma_mask = dev-dma_mask;
+ dev-dev.parent = parent;
+ dev-dev.release = of_release_dev;
+ dev-dev.archdata.of_node = np;
+ dev-dev.archdata.numa_node = of_node_to_nid(np);
+
+ if (bus_id)
+ strlcpy(dev-dev.bus_id, bus_id, BUS_ID_SIZE);
+ else
+ of_device_make_bus_id(dev);
+
+ return dev;
+}
+EXPORT_SYMBOL(of_device_alloc);
+
ssize_t of_device_get_modalias(struct of_device *ofdev,
char *str, ssize_t len)
{
diff --git a/arch/powerpc/kernel/of_platform.c
b/arch/powerpc/kernel/of_platform.c
index f70e787..1d96b82 100644
--- a/arch/powerpc/kernel/of_platform.c
+++ b/arch/powerpc/kernel/of_platform.c
@@ -21,7 +21,6 @@
#include linux/pci.h
[PATCH 5/5] ibmebus: More speaking error return code in ibmebus_store_probe()
Signed-off-by: Joachim Fenkes [EMAIL PROTECTED]
---
arch/powerpc/kernel/ibmebus.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/kernel/ibmebus.c b/arch/powerpc/kernel/ibmebus.c
index c1e2963..0bd186c 100644
--- a/arch/powerpc/kernel/ibmebus.c
+++ b/arch/powerpc/kernel/ibmebus.c
@@ -268,10 +268,10 @@ static ssize_t ibmebus_store_probe(struct bus_type *bus,
return -ENOMEM;
if (bus_find_device(ibmebus_bus_type, NULL, path,
-ibmebus_match_path)) {
+ ibmebus_match_path)) {
printk(KERN_WARNING %s: %s has already been probed\n,
__FUNCTION__, path);
- rc = -EINVAL;
+ rc = -EEXIST;
goto out;
}
--
1.5.2
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] add Altivec/VMX state to coredumps
Benjamin Herrenschmidt wrote: On Tue, 2007-09-25 at 19:00 +0100, Matt Sealey wrote: Kumar Gala wrote: I'm wondering how we distinguish a core dump w/altivec state vs one with SPE state. Sheer number of registers saved? Why not put the PVR in core dumps that'd make it all easier.. PVR wouldn't be very useful... What if you have altivec disabled ? Also that would mean your gdb has to know about all new processors... Is that such a big deal? :D Hypothetically it would be impossible to determine if you were running on a G5 with the FPU and AltiVec turned off or an e500 core with SPE, given the data saved. Is that a misfeature of GDB that we even have to worry about this, or some noble plus point of a unified ISA? You decide :) -- Matt Sealey [EMAIL PROTECTED] Genesi, Manager, Developer Relations ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Please pull powerpc.git merge branch
I wrote:
Linus,
Please do
git pull \
git://git.kernel.org/pub/scm/linux/kernel/git/paulus/powerpc.git merge
to get a patch from Roland McGrath that fixes a user-triggerable oops
on 64-bit powerpc.
I have added another commit from Jeremy Kerr fixing a mismerge that
caused a user visible ABI regression from 2.6.22. The diffstat and
log below include both the patch from Roland and this new patch.
Thanks,
Paul.
arch/powerpc/kernel/process.c|7 +++
arch/powerpc/platforms/cell/spufs/file.c |4 ++--
2 files changed, 9 insertions(+), 2 deletions(-)
commit 603c461250b223ac42c10b8d1df653af1a361d44
Author: Jeremy Kerr [EMAIL PROTECTED]
Date: Wed Sep 26 10:53:45 2007 +1000
[POWERPC] spufs: fix mismerge, making context signal{1,2} files readable
again
The commit 8b6f50ef1d5cc86b278eb42bc91630fad455fb10 seems to have
been affected by a mismerge of a duplicate patch
(d054b36ffd302ec65aabec16a0c60ddd9e6b5a62) - both the
spufs_dir_contents and spufs_dir_nosched_contents have been given
write-only signal notification files.
This change reverts the spufs_dir_contents array to use the
readable signal notification file implementation.
Signed-off-by: Jeremy Kerr [EMAIL PROTECTED]
Acked-by: Arnd Bergmann [EMAIL PROTECTED]
Signed-off-by: Paul Mackerras [EMAIL PROTECTED]
commit 474f81967217f3bec2389ae913da72641f2c40e3
Author: Roland McGrath [EMAIL PROTECTED]
Date: Mon Sep 24 16:52:44 2007 -0700
[POWERPC] Ensure FULL_REGS on exec
When PTRACE_O_TRACEEXEC is used, a ptrace call to fetch the registers at
the PTRACE_EVENT_EXEC stop (PTRACE_PEEKUSR) will oops in CHECK_FULL_REGS.
With recent versions, gdb --args /bin/sh -c 'exec /bin/true' and run at
the (gdb) prompt is sufficient to produce this. I also have written an
isolated test case, see
https://bugzilla.redhat.com/show_bug.cgi?id=301791#c15.
This change fixes the problem by clearing the low bit of pt_regs.trap in
start_thread so that FULL_REGS is true again. This is correct since all of
the GPRs that full refers to are cleared in start_thread.
Signed-off-by: Roland McGrath [EMAIL PROTECTED]
Signed-off-by: Paul Mackerras [EMAIL PROTECTED]
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 3/7] Celleb: Support for Power/Reset buttons
On Wednesday 26 September 2007, Ishizaki Kou wrote:
This is a patch to support Power/Reset buttons on Beat on Celleb.
On Beat, we have an event from Beat if Power button or Reset button
is pressed. This patch catches the event and convert it to a signal
to INIT process.
/sbin/inittab have no entry to turn the machine power off so we have
to detect if power button is pressed or not internally in our driver.
This idea is taken from PS3's event handling subsystem.
Signed-off-by: Kou Ishizaki [EMAIL PROTECTED]
Basically looks good. At some point I want to do a similar driver
for the IBM cell blade, but I fear there is not much code we
can share.
+static irqreturn_t beat_power_event(int virq, void *arg)
+{
+ printk(KERN_DEBUG Beat: power button pressed\n);
+ beat_pm_poweroff_flag = 1;
+ if (kill_cad_pid(SIGINT, 1)) {
+ /* Just in case killing init process failed */
+ beat_power_off();
+ }
+ return IRQ_HANDLED;
+}
I think this should call ctrl_alt_del() instead of doing
kill_cad_pid() directly.
Also, I think you should better not call the low-level
beat_power_off() function, but rather a high-level function
that goes through the reboot notifiers first.
kernel_restart() seems appropriate for that.
+static irqreturn_t beat_reset_event(int virq, void *arg)
+{
+ printk(KERN_DEBUG Beat: reset button pressed\n);
+ beat_pm_poweroff_flag = 0;
+ if (kill_cad_pid(SIGINT, 1)) {
+ /* Just in case killing init process failed */
+ beat_restart(NULL);
+ }
+ return IRQ_HANDLED;
+}
same here, except calling kernel_halt() in the end.
+static int __init beat_event_init(void)
+{
+ if (!machine_is(celleb) || !firmware_has_feature(FW_FEATURE_BEAT))
+ return -EINVAL;
Shouldn't one of the two be sufficent? It seems to me that you want to
probe for either celleb or BEAT, but not both, considering that celleb
implies BEAT.
Arnd
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 7/7] Celleb: update for PCI
On Wednesday 26 September 2007, Ishizaki Kou wrote:
This is a patch kit to support PCI bus on Celleb with new I/O routines
for PowerPC. External PCI on Celleb must do explicit synchronization
with devices (Bus has no automatic synchronization feature).
It seems you are duplicating a lot of
arch/powerpc/platforms/cell/io-workarounds.c, in order to work around
the same problem:
+static struct celleb_pci_bus *celleb_pci_find(unsigned long vaddr,
+ unsigned long paddr)
+{
+ int i, j;
+ struct resource *res;
+
+ for (i = 0; i celleb_pci_count; i++) {
+ struct celleb_pci_bus *bus = celleb_pci_busses[i];
+ struct pci_controller *phb = bus-phb;
+ if (paddr)
+ for (j = 0; j 3; j++) {
+ res = phb-mem_resources[j];
+ if (paddr = res-start paddr = res-end)
+ return bus;
+ }
+ res = phb-io_resource;
+ if (vaddr vaddr = res-start vaddr = res-end)
+ return bus;
+ }
+ return NULL;
+}
+
+static void celleb_io_flush(const PCI_IO_ADDR addr)
+{
+ struct celleb_pci_bus *bus;
+ int token;
+
+ token = PCI_GET_ADDR_TOKEN(addr);
+
+ if (token token = celleb_pci_count)
+ bus = celleb_pci_busses[token - 1];
+ else {
+ unsigned long vaddr, paddr;
+ pte_t *ptep;
+
+ vaddr = (unsigned long)PCI_FIX_ADDR(addr);
+ if (vaddr PHB_IO_BASE || vaddr = PHB_IO_END)
+ return;
+
+ ptep = find_linux_pte(init_mm.pgd, vaddr);
+ if (ptep == NULL)
+ paddr = 0;
+ else
+ paddr = pte_pfn(*ptep) PAGE_SHIFT;
+ bus = celleb_pci_find(vaddr, paddr);
+
+ if (bus == NULL)
+ return;
+ }
+
+ if (bus-dummy_read)
+ bus-dummy_read(bus-phb);
+}
+
+static u8 celleb_readb(const PCI_IO_ADDR addr)
+{
+ u8 val;
+ val = __do_readb(addr);
+ celleb_io_flush(addr);
+ return val;
+}
+
+static u16 celleb_readw(const PCI_IO_ADDR addr)
+{
+ u16 val;
+ val = __do_readw(addr);
+ celleb_io_flush(addr);
+ return val;
+}
+
+static u32 celleb_readl(const PCI_IO_ADDR addr)
+{
+ u32 val;
+ val = __do_readl(addr);
+ celleb_io_flush(addr);
+ return val;
+}
+
+static u64 celleb_readq(const PCI_IO_ADDR addr)
+{
+ u64 val;
+ val = __do_readq(addr);
+ celleb_io_flush(addr);
+ return val;
+}
+
+static u16 celleb_readw_be(const PCI_IO_ADDR addr)
+{
+ u16 val;
+ val = __do_readw_be(addr);
+ celleb_io_flush(addr);
+ return val;
+}
+
+static u32 celleb_readl_be(const PCI_IO_ADDR addr)
+{
+ u32 val;
+ val = __do_readl_be(addr);
+ celleb_io_flush(addr);
+ return val;
+}
+
+static u64 celleb_readq_be(const PCI_IO_ADDR addr)
+{
+ u64 val;
+ val = __do_readq_be(addr);
+ celleb_io_flush(addr);
+ return val;
+}
+
+static void celleb_readsb(const PCI_IO_ADDR addr,
+ void *buf, unsigned long count)
+{
+ __do_readsb(addr, buf, count);
+ celleb_io_flush(addr);
+}
+
+static void celleb_readsw(const PCI_IO_ADDR addr,
+ void *buf, unsigned long count)
+{
+ __do_readsw(addr, buf, count);
+ celleb_io_flush(addr);
+}
+
+static void celleb_readsl(const PCI_IO_ADDR addr,
+ void *buf, unsigned long count)
+{
+ __do_readsl(addr, buf, count);
+ celleb_io_flush(addr);
+}
+
+static void celleb_memcpy_fromio(void *dest,
+ const PCI_IO_ADDR src,
+ unsigned long n)
+{
+ __do_memcpy_fromio(dest, src, n);
+ celleb_io_flush(src);
+}
+
+static void __iomem *celleb_ioremap(unsigned long addr,
+ unsigned long size,
+ unsigned long flags)
+{
+ struct celleb_pci_bus *bus;
+ void __iomem *res = __ioremap(addr, size, flags);
+ int busno;
+
+ bus = celleb_pci_find(0, addr);
+ if (bus != NULL) {
+ busno = bus - celleb_pci_busses;
+ PCI_SET_ADDR_TOKEN(res, busno + 1);
+ }
+ return res;
+}
Is there a way that we can make that code common? I guess there could be a
file in arch/powerpc/sysdev that can handle this correctly for all hardware
that requires this particular workaround (currently celleb and QS20, but
potentially more).
Arnd
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 1/7] PowerPC64: Not to insert EA=0 entry at initializing SLB
On Wednesday 26 September 2007, Ishizaki Kou wrote: This is a workaround NOT to insert EA=0 entry at initializing SLB. Without this patch, you can see /sbin/init hanging at a machine which has less or equal than 256MB memory. Can you elaborate? I don't understand why /sbin/init will hang because of an incorrect SLB entry, or how that entry gets initialized from get_paca()-kstack. Are you still trying to find a better fix for 2.6.24, or do you intend to have this patch go in for now? Also, I did not get a patch 4/7 and 5/7. Did you send them to some other mailing list, or did they get lost on the way? Arnd ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: jffs2 file system on MPC8272ADS board
Hello , hi everyone, I m using custom board similar to MPC8272ADS board... 1) For the first time it boots up properly in case if we overwrite any existing binaries using nfs mounted file system on the board, after rebooting it displays fallowing message... Further such events for this erase block will not be printed Eep. Child null (ino #1346) of dir ino #3 doesn't exist! Eep. Child autocomm (ino #463) of dir ino #461 doesn't exist! Eep. Child calibration (ino #464) of dir ino #461 doesn't exist! Eep. Child coredsp_driver.ko (ino #939) of dir ino #336 doesn't exist! Inode #1307 was a directory with children - removing those too... Inode #564 was a directory with children - removing those too... Inode #565 was a directory with children - removing those too... Inode #1112 was a directory with children - removing those too... Inode #1115 was a directory with children - removing those too... Inode #1118 was a directory with children - removing those too... Inode #1123 was a directory with children - removing those too... after this board boots up properlybut it not be having overwritten files Have you created jffs2 file system on flash prior to mounting it? Yes I created jffs2 filesytem using mkfs.jffs2 prior to mounting and then I am over-writing some of the binaries. In case of overwrites from NFS after reboot I see the above errors the binaries/directories gets deleted from the jffs2 partition. 3) when board is running properly in between it starts printing on console repeatedly... Do the proper MTD partitions setup, erase the partition and create jffs2 filesystem on it. If after all those steps you're still getting output, that is prolly flakey flash. Header CRC failed on REF_PRISTINE node at 0x00638a6c: Read 0x, calculated 0x44660075 Node totlen on flash (0x) != totlen from node ref (0x0254) Header CRC failed on REF_PRISTINE node at 0x00638cc0: Read 0x, calculated 0x44660075 [...] and file system is created using fallowing command.. mkfs.jffs2 -r RFS_NEW/ -e 0x2 -o /tftpboot/jffs2_img -b I am recalling playing with the options upper also cured the jffs2 warnings (not as many as yours but anyway) The other options I am wondering about, -c, --cleanmarker=SIZE Size of cleanmarker (default 12) -n, --no-cleanmarkers Don't add a cleanmarker to every eraseblock cleanmaker size will it help the cause? Nethra -- View this message in context: http://www.nabble.com/jffs2-file-system-on-MPC8272ADS-board-tf4513530.html#a12900017 Sent from the linuxppc-dev mailing list archive at Nabble.com. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 2/2] fsl/embedded6xx: don't cast the result of of_get_property
-avr_clock = *(u32*)of_get_property(avr, clock-frequency, len); -phys_addr = ((u32*)of_get_property(avr, reg, len))[0]; +phys_addr = of_get_property(avr, reg, len); +avr_clock_prop = of_get_property(avr, clock-frequency, len); If you don't use the value of the len variable, then you can pass NULL to of_get_property. OTOH, it is almost always an error to not use the length (missing error check). Segher ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 7/7] [POWERPC][SPI] spi_mpc83xx: allow use on any processors with QUICC Engine
On Tue, Sep 25, 2007 at 11:00:38PM -0500, Kumar Gala wrote: I'm still in favor of making it PPC_83xx || QUICC_ENGINE. Submitting... ;-) - - - - From: Anton Vorontsov [EMAIL PROTECTED] Subject: [POWERPC][SPI] spi_mpc83xx: allow use on any processors with QUICC Engine Currently, all QE SPI controllers are almost the same comparing to MPC83xx's, thus let's use that driver for them. Tested to work on MPC85xx in loopback mode. Signed-off-by: Anton Vorontsov [EMAIL PROTECTED] --- drivers/spi/Kconfig | 13 +++-- 1 files changed, 7 insertions(+), 6 deletions(-) diff --git a/drivers/spi/Kconfig b/drivers/spi/Kconfig index b915711..a77ede5 100644 --- a/drivers/spi/Kconfig +++ b/drivers/spi/Kconfig @@ -124,16 +124,17 @@ config SPI_MPC52xx_PSC Controller in master SPI mode. config SPI_MPC83xx - tristate Freescale MPC83xx SPI controller - depends on SPI_MASTER PPC_83xx EXPERIMENTAL + tristate Freescale MPC83xx/QUICC Engine SPI controller + depends on SPI_MASTER (PPC_83xx || QUICC_ENGINE) EXPERIMENTAL select SPI_BITBANG help - This enables using the Freescale MPC83xx SPI controller in master - mode. + This enables using the Freescale MPC83xx and QUICC Engine SPI + controllers in master mode. Note, this driver uniquely supports the SPI controller on the MPC83xx - family of PowerPC processors. The MPC83xx uses a simple set of shift - registers for data (opposed to the CPM based descriptor model). + family of PowerPC processors, plus processors with QUICC Engine + technology. This driver uses a simple set of shift registers for data + (opposed to the CPM based descriptor model). config SPI_OMAP_UWIRE tristate OMAP1 MicroWire -- 1.5.0.6 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] add Altivec/VMX state to coredumps
Why not put the PVR in core dumps that'd make it all easier.. PVR wouldn't be very useful... What if you have altivec disabled ? Also that would mean your gdb has to know about all new processors... Is that such a big deal? :D Hypothetically it would be impossible to determine if you were running on a G5 with the FPU and AltiVec turned off or an e500 core with SPE, given the data saved. And that is exactly as should be: a core dump represents the execution state of a user program, it has nothing to do with the machine it was generated on; it even is possible to restart a core dump generated on e.g. an e500 on a 970, as long as it doesn't use facilities (e.g., SPE) that the latter processor / execution environment doesn't provide. Is that a misfeature of GDB that we even have to worry about this, or some noble plus point of a unified ISA? You decide :) We don't have to worry about it :-) Segher ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] add Altivec/VMX state to coredumps
On Sep 26, 2007, at 8:21 AM, Segher Boessenkool wrote: Why not put the PVR in core dumps that'd make it all easier.. PVR wouldn't be very useful... What if you have altivec disabled ? Also that would mean your gdb has to know about all new processors... Is that such a big deal? :D Hypothetically it would be impossible to determine if you were running on a G5 with the FPU and AltiVec turned off or an e500 core with SPE, given the data saved. And that is exactly as should be: a core dump represents the execution state of a user program, it has nothing to do with the machine it was generated on; it even is possible to restart a core dump generated on e.g. an e500 on a 970, as long as it doesn't use facilities (e.g., SPE) that the latter processor / execution environment doesn't provide. Is that a misfeature of GDB that we even have to worry about this, or some noble plus point of a unified ISA? You decide :) We don't have to worry about it :-) We should worry about it. If one misinterprets the core file you will get unexpected behavior. I see no reason not to do this properly and mark the sections such that its clear if its AltiVec or SPE state, rather than overloading the x86 XFPU type. - k ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] add Altivec/VMX state to coredumps
Why not put the PVR in core dumps that'd make it all easier.. PVR wouldn't be very useful... What if you have altivec disabled ? Also that would mean your gdb has to know about all new processors... Is that such a big deal? :D Hypothetically it would be impossible to determine if you were running on a G5 with the FPU and AltiVec turned off or an e500 core with SPE, given the data saved. And that is exactly as should be: a core dump represents the execution state of a user program, it has nothing to do with the machine it was generated on; it even is possible to restart a core dump generated on e.g. an e500 on a 970, as long as it doesn't use facilities (e.g., SPE) that the latter processor / execution environment doesn't provide. Is that a misfeature of GDB that we even have to worry about this, or some noble plus point of a unified ISA? You decide :) We don't have to worry about it :-) We should worry about it. If one misinterprets the core file you will get unexpected behavior. I read this as worry about the PVR. I see no reason not to do this properly and mark the sections such that its clear if its AltiVec or SPE state, rather than overloading the x86 XFPU type. Yes, certainly, I thought we all agreed on that automatically :-) Segher ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] add Altivec/VMX state to coredumps
Segher Boessenkool wrote: Why not put the PVR in core dumps that'd make it all easier.. PVR wouldn't be very useful... What if you have altivec disabled ? Also that would mean your gdb has to know about all new processors... Is that such a big deal? :D Hypothetically it would be impossible to determine if you were running on a G5 with the FPU and AltiVec turned off or an e500 core with SPE, given the data saved. And that is exactly as should be: a core dump represents the execution state of a user program, it has nothing to do with the machine it was generated on; it even is possible to restart a core dump generated on e.g. an e500 on a 970, as long as it doesn't use facilities (e.g., SPE) that the latter processor / execution environment doesn't provide. A hypothetical question for you then.. What happens if you get a core dump for a G4 app which dynamically detects AltiVec presence (from PVR or /proc) then crashes before AltiVec is enabled in the kernel for that task (i.e. before any vector exception) and you run it on your G3 and it magically carries on (maybe a race condition or so) and causes a vector exception later? Isn't that kind of useless? Wouldn't it? -- Matt Sealey [EMAIL PROTECTED] Genesi, Manager, Developer Relations ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] powerpc: fix pci domain detection
The /proc/bus/pci/* files list PCI domain numbers only for
devices that claim to be on a multi-domain system. The check
for this is broken on powerpc, because the buid value is
truncated to 32 bits.
There is at least one machine (IBM QS21) that only uses
the high-order bits of the buid, so the return value
of pci_proc_domain() ends up being always zero, which
makes /proc/bus/pci useless.
Change the logic to always return '1' for a nonzero
buid value.
Signed-off-by: Arnd Bergmann [EMAIL PROTECTED]
diff --git a/arch/powerpc/kernel/pci_64.c b/arch/powerpc/kernel/pci_64.c
index 291ffbc..9f63bdc 100644
--- a/arch/powerpc/kernel/pci_64.c
+++ b/arch/powerpc/kernel/pci_64.c
@@ -588,7 +588,7 @@ int pci_proc_domain(struct pci_bus *bus)
return 0;
else {
struct pci_controller *hose = pci_bus_to_host(bus);
- return hose-buid;
+ return hose-buid != 0;
}
}
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 2/2]: PCI Error Recovery: Symbios SCSI First Failure
On Fri, Apr 20, 2007 at 03:47:20PM -0500, Linas Vepstas wrote: Implement the so-called first failure data capture (FFDC) for the symbios PCI error recovery. After a PCI error event is reported, the driver requests that MMIO be enabled. Once enabled, it then reads and dumps assorted status registers, and concludes by requesting the usual reset sequence. + /* Request that MMIO be enabled, so register dump can be taken. */ + return PCI_ERS_RESULT_CAN_RECOVER; +} I'm a little concerned by the mention of MMIO. It's entirely possible for the sym2 driver to be using ioports to access the card rather than MMIO. Is it simply that it can't on the platform you test on? -- Intel are signing my paycheques ... these opinions are still mine Bill, look, we understand that you're interested in selling us this operating system, but compare it to ours. We can't possibly take such a retrograde step. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[patch 0/8] PS3 AV Settings Driver patches for 2.6.24
Hi, Here are some new patches for the PS3 AV Settings Driver (ps3av), which is used in close collaboration with the PS3 Virtual Frame Buffer Device Driver (ps3fb): [1] ps3av: eliminate unneeded temporary variables [2] ps3av: eliminate PS3AV_DEBUG [3] ps3av: use PS3 video mode ids in autodetect code [4] ps3av: treat DVI-D like HDMI in autodetect [5] ps3av: add autodetection for VESA modes [6] ps3av: add quirk database for broken monitors [7] ps3av: remove unused ps3av_set_mode() [8] ps3av: don't distinguish between `boot' and `non-boot' autodetection Please review, and queue for 2.6.24 if they're ok. Thanks! Question: As several DVI-D displays advertise they support 1080i modes while they actually don't (cfr. the quirk database), perhaps I should drop 1080i modes completely from the ps3av_preferred_modes[] table? Usually 720p looks better than 1080i anyway. What do you think? With kind regards, Geert Uytterhoeven Software Architect Sony Network and Software Technology Center Europe The Corporate Village · Da Vincilaan 7-D1 · B-1935 Zaventem · Belgium Phone:+32 (0)2 700 8453 Fax: +32 (0)2 700 8622 E-mail: [EMAIL PROTECTED] Internet: http://www.sony-europe.com/ Sony Network and Software Technology Center Europe A division of Sony Service Centre (Europe) N.V. Registered office: Technologielaan 7 · B-1840 Londerzeel · Belgium VAT BE 0413.825.160 · RPR Brussels Fortis Bank Zaventem · Swift GEBABEBB08A · IBAN BE39001382358619 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[patch 1/8] ps3av: eliminate unneeded temporary variables
ps3av: eliminate unneeded temporary variables
Signed-off-by: Geert Uytterhoeven [EMAIL PROTECTED]
---
drivers/ps3/ps3av_cmd.c | 17 ++---
1 files changed, 6 insertions(+), 11 deletions(-)
--- a/drivers/ps3/ps3av_cmd.c
+++ b/drivers/ps3/ps3av_cmd.c
@@ -512,7 +512,6 @@ static const u32 ps3av_ns_table[][5] = {
static void ps3av_cnv_ns(u8 *ns, u32 fs, u32 video_vid)
{
u32 av_vid, ns_val;
- u8 *p = ns;
int d;
d = ns_val = 0;
@@ -551,24 +550,22 @@ static void ps3av_cnv_ns(u8 *ns, u32 fs,
else
ns_val = ps3av_ns_table[PS3AV_CMD_AUDIO_FS_44K-BASE][d];
- *p++ = ns_val 0x00FF;
- *p++ = (ns_val 0xFF00) 8;
- *p = (ns_val 0x00FF) 16;
+ *ns++ = ns_val 0x00FF;
+ *ns++ = (ns_val 0xFF00) 8;
+ *ns = (ns_val 0x00FF) 16;
}
#undef BASE
static u8 ps3av_cnv_enable(u32 source, const u8 *enable)
{
- const u8 *p;
u8 ret = 0;
if (source == PS3AV_CMD_AUDIO_SOURCE_SPDIF) {
ret = 0x03;
} else if (source == PS3AV_CMD_AUDIO_SOURCE_SERIAL) {
- p = enable;
- ret = ((p[0] 4) + (p[1] 5) + (p[2] 6) + (p[3] 7)) |
- 0x01;
+ ret = ((enable[0] 4) + (enable[1] 5) + (enable[2] 6) +
+ (enable[3] 7)) | 0x01;
} else
printk(KERN_ERR %s failed, source:%x\n, __func__, source);
return ret;
@@ -576,11 +573,9 @@ static u8 ps3av_cnv_enable(u32 source, c
static u8 ps3av_cnv_fifomap(const u8 *map)
{
- const u8 *p;
u8 ret = 0;
- p = map;
- ret = p[0] + (p[1] 2) + (p[2] 4) + (p[3] 6);
+ ret = map[0] + (map[1] 2) + (map[2] 4) + (map[3] 6);
return ret;
}
--
With kind regards,
Geert Uytterhoeven
Software Architect
Sony Network and Software Technology Center Europe
The Corporate Village · Da Vincilaan 7-D1 · B-1935 Zaventem · Belgium
Phone:+32 (0)2 700 8453
Fax: +32 (0)2 700 8622
E-mail: [EMAIL PROTECTED]
Internet: http://www.sony-europe.com/
Sony Network and Software Technology Center Europe
A division of Sony Service Centre (Europe) N.V.
Registered office: Technologielaan 7 · B-1840 Londerzeel · Belgium
VAT BE 0413.825.160 · RPR Brussels
Fortis Bank Zaventem · Swift GEBABEBB08A · IBAN BE39001382358619
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[patch 2/8] ps3av: eliminate PS3AV_DEBUG
ps3av: eliminate PS3AV_DEBUG
- Move ps3av_cmd_av_monitor_info_dump from ps3av_cmd.c to ps3av.c, as it's
used there only
- Integrate ps3av_cmd_av_hw_conf_dump() into its sole user
- Use pr_debug() for printing debug info
Signed-off-by: Geert Uytterhoeven [EMAIL PROTECTED]
---
drivers/ps3/ps3av.c | 72
drivers/ps3/ps3av_cmd.c | 66
include/asm-powerpc/ps3av.h |7
3 files changed, 67 insertions(+), 78 deletions(-)
--- a/drivers/ps3/ps3av.c
+++ b/drivers/ps3/ps3av.c
@@ -656,6 +656,64 @@ static int ps3av_hdmi_get_vid(struct ps3
return vid;
}
+static void ps3av_monitor_info_dump(const struct ps3av_pkt_av_get_monitor_info
*monitor_info)
+{
+ const struct ps3av_info_monitor *info = monitor_info-info;
+ const struct ps3av_info_audio *audio = info-audio;
+ char id[sizeof(info-monitor_id)*3+1];
+ int i;
+
+ pr_debug(Monitor Info: size %u\n, monitor_info-send_hdr.size);
+
+ pr_debug(avport: %02x\n, info-avport);
+ for (i = 0; i sizeof(info-monitor_id); i++)
+ sprintf(id[i*3], %02x, info-monitor_id[i]);
+ pr_debug(monitor_id: %s\n, id);
+ pr_debug(monitor_type: %02x\n, info-monitor_type);
+ pr_debug(monitor_name: %.*s\n, (int)sizeof(info-monitor_name),
+info-monitor_name);
+
+ /* resolution */
+ pr_debug(resolution_60: bits: %08x native: %08x\n,
+info-res_60.res_bits, info-res_60.native);
+ pr_debug(resolution_50: bits: %08x native: %08x\n,
+info-res_50.res_bits, info-res_50.native);
+ pr_debug(resolution_other: bits: %08x native: %08x\n,
+info-res_other.res_bits, info-res_other.native);
+ pr_debug(resolution_vesa: bits: %08x native: %08x\n,
+info-res_vesa.res_bits, info-res_vesa.native);
+
+ /* color space */
+ pr_debug(color spacergb: %02x\n, info-cs.rgb);
+ pr_debug(color space yuv444: %02x\n, info-cs.yuv444);
+ pr_debug(color space yuv422: %02x\n, info-cs.yuv422);
+
+ /* color info */
+ pr_debug(color info red: X %04x Y %04x\n, info-color.red_x,
+info-color.red_y);
+ pr_debug(color info green: X %04x Y %04x\n, info-color.green_x,
+info-color.green_y);
+ pr_debug(color info blue: X %04x Y %04x\n, info-color.blue_x,
+info-color.blue_y);
+ pr_debug(color info white: X %04x Y %04x\n, info-color.white_x,
+info-color.white_y);
+ pr_debug(color info gamma: %08x\n, info-color.gamma);
+
+ /* other info */
+ pr_debug(supported_AI: %02x\n, info-supported_ai);
+ pr_debug(speaker_info: %02x\n, info-speaker_info);
+ pr_debug(num of audio: %02x\n, info-num_of_audio_block);
+
+ /* audio block */
+ for (i = 0; i info-num_of_audio_block; i++) {
+ pr_debug(audio[%d] type: %02x max_ch: %02x fs: %02x sbit:
+%02x\n,
+i, audio-type, audio-max_num_of_ch, audio-fs,
+audio-sbit);
+ audio++;
+ }
+}
+
static int ps3av_auto_videomode(struct ps3av_pkt_av_get_hw_conf *av_hw_conf,
int boot)
{
@@ -671,7 +729,7 @@ static int ps3av_auto_videomode(struct p
if (res 0)
return -1;
- ps3av_cmd_av_monitor_info_dump(monitor_info);
+ ps3av_monitor_info_dump(monitor_info);
info = monitor_info.info;
/* check DVI */
if (info-monitor_type == PS3AV_MONITOR_TYPE_DVI) {
@@ -727,23 +785,27 @@ static int ps3av_auto_videomode(struct p
static int ps3av_get_hw_conf(struct ps3av *ps3av)
{
int i, j, k, res;
+ const struct ps3av_pkt_av_get_hw_conf *hw_conf;
/* get av_hw_conf */
res = ps3av_cmd_av_get_hw_conf(ps3av-av_hw_conf);
if (res 0)
return -1;
- ps3av_cmd_av_hw_conf_dump(ps3av-av_hw_conf);
+ hw_conf = ps3av-av_hw_conf;
+ pr_debug(av_h_conf: num of hdmi: %u\n, hw_conf-num_of_hdmi);
+ pr_debug(av_h_conf: num of avmulti: %u\n, hw_conf-num_of_avmulti);
+ pr_debug(av_h_conf: num of spdif: %u\n, hw_conf-num_of_spdif);
for (i = 0; i PS3AV_HEAD_MAX; i++)
ps3av-head[i] = PS3AV_CMD_VIDEO_HEAD_A + i;
for (i = 0; i PS3AV_OPT_PORT_MAX; i++)
ps3av-opt_port[i] = PS3AV_CMD_AVPORT_SPDIF_0 + i;
- for (i = 0; i ps3av-av_hw_conf.num_of_hdmi; i++)
+ for (i = 0; i hw_conf-num_of_hdmi; i++)
ps3av-av_port[i] = PS3AV_CMD_AVPORT_HDMI_0 + i;
- for (j = 0; j ps3av-av_hw_conf.num_of_avmulti; j++)
+ for (j = 0; j hw_conf-num_of_avmulti; j++)
ps3av-av_port[i + j] = PS3AV_CMD_AVPORT_AVMULTI_0 + j;
- for (k = 0; k ps3av-av_hw_conf.num_of_spdif; k++)
+
[patch 4/8] ps3av: treat DVI-D like HDMI in autodetect
ps3av: treat DVI-D monitors like HDMI monitors when autodetecting the best
video mode
Signed-off-by: Geert Uytterhoeven [EMAIL PROTECTED]
---
drivers/ps3/ps3av.c | 24
include/asm-powerpc/ps3av.h |1 -
2 files changed, 8 insertions(+), 17 deletions(-)
--- a/drivers/ps3/ps3av.c
+++ b/drivers/ps3/ps3av.c
@@ -620,9 +620,6 @@ static int ps3av_hdmi_get_id(struct ps3a
u32 res_50, res_60;
int id;
- if (info-monitor_type != PS3AV_MONITOR_TYPE_HDMI)
- return 0;
-
/* check native resolution */
res_50 = info-res_50.native PS3AV_RES_MASK_50;
res_60 = info-res_60.native PS3AV_RES_MASK_60;
@@ -712,7 +709,7 @@ static int ps3av_auto_videomode(struct p
struct ps3av_info_monitor *info;
/* get mode id for hdmi */
- for (i = 0; i av_hw_conf-num_of_hdmi; i++) {
+ for (i = 0; i av_hw_conf-num_of_hdmi !id; i++) {
res = ps3av_cmd_video_get_monitor_info(monitor_info,
PS3AV_CMD_AVPORT_HDMI_0 +
i);
@@ -720,24 +717,19 @@ static int ps3av_auto_videomode(struct p
return -1;
ps3av_monitor_info_dump(monitor_info);
+
info = monitor_info.info;
- /* check DVI */
- if (info-monitor_type == PS3AV_MONITOR_TYPE_DVI) {
+ switch (info-monitor_type) {
+ case PS3AV_MONITOR_TYPE_DVI:
dvi = PS3AV_MODE_DVI;
- break;
- }
- /* check HDMI */
- id = ps3av_hdmi_get_id(info);
- if (id) {
- /* got valid mode id */
+ /* fall through */
+ case PS3AV_MONITOR_TYPE_HDMI:
+ id = ps3av_hdmi_get_id(info);
break;
}
}
- if (dvi) {
- /* DVI mode */
- id = PS3AV_DEFAULT_DVI_MODE_ID;
- } else if (!id) {
+ if (!id) {
/* no HDMI interface or HDMI is off */
if (ps3av-region PS3AV_REGION_60)
id = PS3AV_DEFAULT_AVMULTI_MODE_ID_REG_60;
--- a/include/asm-powerpc/ps3av.h
+++ b/include/asm-powerpc/ps3av.h
@@ -305,7 +305,6 @@
#define PS3AV_DEFAULT_AVMULTI_MODE_ID_REG_60 1 /* 480i */
#define PS3AV_DEFAULT_HDMI_MODE_ID_REG_50 7 /* 576p */
#define PS3AV_DEFAULT_AVMULTI_MODE_ID_REG_50 6 /* 576i */
-#define PS3AV_DEFAULT_DVI_MODE_ID 2 /* 480p */
#define PS3AV_REGION_600x01
#define PS3AV_REGION_500x02
--
With kind regards,
Geert Uytterhoeven
Software Architect
Sony Network and Software Technology Center Europe
The Corporate Village · Da Vincilaan 7-D1 · B-1935 Zaventem · Belgium
Phone:+32 (0)2 700 8453
Fax: +32 (0)2 700 8622
E-mail: [EMAIL PROTECTED]
Internet: http://www.sony-europe.com/
Sony Network and Software Technology Center Europe
A division of Sony Service Centre (Europe) N.V.
Registered office: Technologielaan 7 · B-1840 Londerzeel · Belgium
VAT BE 0413.825.160 · RPR Brussels
Fortis Bank Zaventem · Swift GEBABEBB08A · IBAN BE39001382358619
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[patch 7/8] ps3av: remove unused ps3av_set_mode()
ps3av: remove unused ps3av_set_mode()
Signed-off-by: Geert Uytterhoeven [EMAIL PROTECTED]
---
drivers/ps3/ps3av.c | 21 -
include/asm-powerpc/ps3av.h |1 -
2 files changed, 22 deletions(-)
--- a/drivers/ps3/ps3av.c
+++ b/drivers/ps3/ps3av.c
@@ -903,27 +903,6 @@ int ps3av_get_auto_mode(int boot)
EXPORT_SYMBOL_GPL(ps3av_get_auto_mode);
-int ps3av_set_mode(u32 id, int boot)
-{
- int res;
-
- res = ps3av_set_video_mode(id, boot);
- if (res)
- return res;
-
- res = ps3av_set_audio_mode(PS3AV_CMD_AUDIO_NUM_OF_CH_2,
- PS3AV_CMD_AUDIO_FS_48K,
- PS3AV_CMD_AUDIO_WORD_BITS_16,
- PS3AV_CMD_AUDIO_FORMAT_PCM,
- PS3AV_CMD_AUDIO_SOURCE_SERIAL);
- if (res)
- return res;
-
- return 0;
-}
-
-EXPORT_SYMBOL_GPL(ps3av_set_mode);
-
int ps3av_get_mode(void)
{
return ps3av ? ps3av-ps3av_mode : 0;
--- a/include/asm-powerpc/ps3av.h
+++ b/include/asm-powerpc/ps3av.h
@@ -712,7 +712,6 @@ extern int ps3av_cmd_video_get_monitor_i
extern int ps3av_set_video_mode(u32, int);
extern int ps3av_set_audio_mode(u32, u32, u32, u32, u32);
extern int ps3av_get_auto_mode(int);
-extern int ps3av_set_mode(u32, int);
extern int ps3av_get_mode(void);
extern int ps3av_get_scanmode(int);
extern int ps3av_get_refresh_rate(int);
--
With kind regards,
Geert Uytterhoeven
Software Architect
Sony Network and Software Technology Center Europe
The Corporate Village · Da Vincilaan 7-D1 · B-1935 Zaventem · Belgium
Phone:+32 (0)2 700 8453
Fax: +32 (0)2 700 8622
E-mail: [EMAIL PROTECTED]
Internet: http://www.sony-europe.com/
Sony Network and Software Technology Center Europe
A division of Sony Service Centre (Europe) N.V.
Registered office: Technologielaan 7 · B-1840 Londerzeel · Belgium
VAT BE 0413.825.160 · RPR Brussels
Fortis Bank Zaventem · Swift GEBABEBB08A · IBAN BE39001382358619
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[patch 5/8] ps3av: add autodetection for VESA modes
ps3av: add autodetection for VESA modes
Signed-off-by: Geert Uytterhoeven [EMAIL PROTECTED]
---
drivers/ps3/ps3av.c | 93 ++--
include/asm-powerpc/ps3av.h | 11 -
2 files changed, 67 insertions(+), 37 deletions(-)
--- a/drivers/ps3/ps3av.c
+++ b/drivers/ps3/ps3av.c
@@ -585,54 +585,73 @@ static void ps3avd(struct work_struct *w
complete(ps3av-done);
}
-static int ps3av_resbit2id(u32 res_50, u32 res_60)
+#define SHIFT_50 0
+#define SHIFT_60 4
+#define SHIFT_VESA 8
+
+static const struct {
+ unsigned mask : 19;
+ unsigned id : 4;
+} ps3av_preferred_modes[] = {
+ { .mask = PS3AV_RESBIT_WUXGA SHIFT_VESA, .id = 13 },
+ { .mask = PS3AV_RESBIT_1920x1080PSHIFT_60,.id = 5 },
+ { .mask = PS3AV_RESBIT_1920x1080PSHIFT_50,.id = 10 },
+ { .mask = PS3AV_RESBIT_1920x1080ISHIFT_60,.id = 4 },
+ { .mask = PS3AV_RESBIT_1920x1080ISHIFT_50,.id = 9 },
+ { .mask = PS3AV_RESBIT_SXGA SHIFT_VESA, .id = 12 },
+ { .mask = PS3AV_RESBIT_WXGA SHIFT_VESA, .id = 11 },
+ { .mask = PS3AV_RESBIT_1280x720P SHIFT_60,.id = 3 },
+ { .mask = PS3AV_RESBIT_1280x720P SHIFT_50,.id = 8 },
+ { .mask = PS3AV_RESBIT_720x480P SHIFT_60,.id = 2 },
+ { .mask = PS3AV_RESBIT_720x576P SHIFT_50,.id = 7 },
+};
+
+static int ps3av_resbit2id(u32 res_50, u32 res_60, u32 res_vesa)
{
- int id = 0;
+ unsigned int i;
+ u32 res_all;
- if (res_50 res_60) { /* if res_50 == res_60, res_60 will be used */
- if (res_50 PS3AV_RESBIT_1920x1080P)
- id = 10;
- else if (res_50 PS3AV_RESBIT_1920x1080I)
- id = 9;
- else if (res_50 PS3AV_RESBIT_1280x720P)
- id = 8;
- else if (res_50 PS3AV_RESBIT_720x576P)
- id = 7;
- else
- id = 0;
- } else {
- if (res_60 PS3AV_RESBIT_1920x1080P)
- id = 5;
- else if (res_60 PS3AV_RESBIT_1920x1080I)
- id = 4;
- else if (res_60 PS3AV_RESBIT_1280x720P)
- id = 3;
- else if (res_60 PS3AV_RESBIT_720x480P)
- id = 2;
- else
- id = 0;
- }
- return id;
+ /*
+* We mask off the resolution bits we care about and combine the
+* results in one bitfield, so make sure there's no overlap
+*/
+ BUILD_BUG_ON(PS3AV_RES_MASK_50 SHIFT_50
+PS3AV_RES_MASK_60 SHIFT_60);
+ BUILD_BUG_ON(PS3AV_RES_MASK_50 SHIFT_50
+PS3AV_RES_MASK_VESA SHIFT_VESA);
+ BUILD_BUG_ON(PS3AV_RES_MASK_60 SHIFT_60
+PS3AV_RES_MASK_VESA SHIFT_VESA);
+ res_all = (res_50 PS3AV_RES_MASK_50) SHIFT_50 |
+ (res_60 PS3AV_RES_MASK_60) SHIFT_60 |
+ (res_vesa PS3AV_RES_MASK_VESA) SHIFT_VESA;
+
+ if (!res_all)
+ return 0;
+
+ for (i = 0; i ARRAY_SIZE(ps3av_preferred_modes); i++)
+ if (res_all ps3av_preferred_modes[i].mask)
+ return ps3av_preferred_modes[i].id;
+
+ return 0;
}
static int ps3av_hdmi_get_id(struct ps3av_info_monitor *info)
{
- u32 res_50, res_60;
int id;
/* check native resolution */
- res_50 = info-res_50.native PS3AV_RES_MASK_50;
- res_60 = info-res_60.native PS3AV_RES_MASK_60;
- if (res_50 || res_60) {
- id = ps3av_resbit2id(res_50, res_60);
+ id = ps3av_resbit2id(info-res_50.native, info-res_60.native,
+info-res_vesa.native);
+ if (id) {
+ pr_debug(%s: Using native mode %d\n, __func__, id);
return id;
}
- /* check resolution */
- res_50 = info-res_50.res_bits PS3AV_RES_MASK_50;
- res_60 = info-res_60.res_bits PS3AV_RES_MASK_60;
- if (res_50 || res_60) {
- id = ps3av_resbit2id(res_50, res_60);
+ /* check supported resolutions */
+ id = ps3av_resbit2id(info-res_50.res_bits, info-res_60.res_bits,
+info-res_vesa.res_bits);
+ if (id) {
+ pr_debug(%s: Using supported mode %d\n, __func__, id);
return id;
}
@@ -640,6 +659,7 @@ static int ps3av_hdmi_get_id(struct ps3a
id = PS3AV_DEFAULT_HDMI_MODE_ID_REG_60;
else
id = PS3AV_DEFAULT_HDMI_MODE_ID_REG_50;
+ pr_debug(%s: Using default mode %d\n, __func__, id);
return id;
}
@@ -737,6 +757,7 @@ static int ps3av_auto_videomode(struct p
id = PS3AV_DEFAULT_AVMULTI_MODE_ID_REG_50;
[patch 8/8] ps3av: dont distinguish between `boot and `non-boot autodetection
ps3av: don't distinguish between `boot' and `non-boot' autodetection now the
autodetection code has been improved
Signed-off-by: Geert Uytterhoeven [EMAIL PROTECTED]
---
drivers/ps3/ps3av.c | 35 ++-
drivers/video/ps3fb.c |6 ++
include/asm-powerpc/ps3av.h |4 ++--
3 files changed, 10 insertions(+), 35 deletions(-)
--- a/drivers/ps3/ps3av.c
+++ b/drivers/ps3/ps3av.c
@@ -760,8 +760,7 @@ static void ps3av_fixup_monitor_info(str
}
}
-static int ps3av_auto_videomode(struct ps3av_pkt_av_get_hw_conf *av_hw_conf,
- int boot)
+static int ps3av_auto_videomode(struct ps3av_pkt_av_get_hw_conf *av_hw_conf)
{
int i, res, id = 0, dvi = 0, rgb = 0;
struct ps3av_pkt_av_get_monitor_info monitor_info;
@@ -799,28 +798,6 @@ static int ps3av_auto_videomode(struct p
if (ps3av-region PS3AV_REGION_RGB)
rgb = PS3AV_MODE_RGB;
pr_debug(%s: Using avmulti mode %d\n, __func__, id);
- } else if (boot) {
- /* HDMI: using DEFAULT HDMI_MODE_ID while booting up */
- info = monitor_info.info;
- if (ps3av-region PS3AV_REGION_60) {
- if (info-res_60.res_bits PS3AV_RESBIT_720x480P)
- id = PS3AV_DEFAULT_HDMI_MODE_ID_REG_60;
- else if (info-res_50.res_bits PS3AV_RESBIT_720x576P)
- id = PS3AV_DEFAULT_HDMI_MODE_ID_REG_50;
- else {
- /* default */
- id = PS3AV_DEFAULT_HDMI_MODE_ID_REG_60;
- }
- } else {
- if (info-res_50.res_bits PS3AV_RESBIT_720x576P)
- id = PS3AV_DEFAULT_HDMI_MODE_ID_REG_50;
- else if (info-res_60.res_bits PS3AV_RESBIT_720x480P)
- id = PS3AV_DEFAULT_HDMI_MODE_ID_REG_60;
- else {
- /* default */
- id = PS3AV_DEFAULT_HDMI_MODE_ID_REG_50;
- }
- }
}
return id | dvi | rgb;
@@ -862,7 +839,7 @@ static int ps3av_get_hw_conf(struct ps3a
}
/* set mode using id */
-int ps3av_set_video_mode(u32 id, int boot)
+int ps3av_set_video_mode(u32 id)
{
int size;
u32 option;
@@ -876,7 +853,7 @@ int ps3av_set_video_mode(u32 id, int boo
/* auto mode */
option = id ~PS3AV_MODE_MASK;
if ((id PS3AV_MODE_MASK) == 0) {
- id = ps3av_auto_videomode(ps3av-av_hw_conf, boot);
+ id = ps3av_auto_videomode(ps3av-av_hw_conf);
if (id 1) {
printk(KERN_ERR %s: invalid id :%d\n, __func__, id);
return -EINVAL;
@@ -896,9 +873,9 @@ int ps3av_set_video_mode(u32 id, int boo
EXPORT_SYMBOL_GPL(ps3av_set_video_mode);
-int ps3av_get_auto_mode(int boot)
+int ps3av_get_auto_mode(void)
{
- return ps3av_auto_videomode(ps3av-av_hw_conf, boot);
+ return ps3av_auto_videomode(ps3av-av_hw_conf);
}
EXPORT_SYMBOL_GPL(ps3av_get_auto_mode);
@@ -1044,7 +1021,7 @@ static int ps3av_probe(struct ps3_system
res);
ps3av_get_hw_conf(ps3av);
- id = ps3av_auto_videomode(ps3av-av_hw_conf, 1);
+ id = ps3av_auto_videomode(ps3av-av_hw_conf);
mutex_lock(ps3av-mutex);
ps3av-ps3av_mode = id;
mutex_unlock(ps3av-mutex);
--- a/drivers/video/ps3fb.c
+++ b/drivers/video/ps3fb.c
@@ -548,7 +548,6 @@ static int ps3fb_set_par(struct fb_info
unsigned int mode;
int i;
unsigned long offset;
- static int first = 1;
DPRINTK(xres:%d xv:%d yres:%d yv:%d clock:%d\n,
info-var.xres, info-var.xres_virtual,
@@ -572,10 +571,9 @@ static int ps3fb_set_par(struct fb_info
/* Keep the special bits we cannot set using fb_var_screeninfo */
ps3fb_mode = (ps3fb_mode ~PS3AV_MODE_MASK) | mode;
- if (ps3av_set_video_mode(ps3fb_mode, first))
+ if (ps3av_set_video_mode(ps3fb_mode))
return -EINVAL;
- first = 0;
return 0;
}
@@ -737,7 +735,7 @@ static int ps3fb_ioctl(struct fb_info *i
break;
if (!(val PS3AV_MODE_MASK)) {
- u32 id = ps3av_get_auto_mode(0);
+ u32 id = ps3av_get_auto_mode();
if (id 0)
val = (val ~PS3AV_MODE_MASK) | id;
}
--- a/include/asm-powerpc/ps3av.h
+++ b/include/asm-powerpc/ps3av.h
@@ -709,9 +709,9 @@ extern int ps3av_cmd_av_get_hw_conf(stru
extern int ps3av_cmd_video_get_monitor_info(struct
ps3av_pkt_av_get_monitor_info *,
u32);
-extern
[patch 6/8] ps3av: add quirk database for broken monitors
ps3av: add a quirk database for broken monitors where the `best' advertised
video mode doesn't work
Signed-off-by: Geert Uytterhoeven [EMAIL PROTECTED]
---
drivers/ps3/ps3av.c | 41 +
1 files changed, 41 insertions(+)
--- a/drivers/ps3/ps3av.c
+++ b/drivers/ps3/ps3av.c
@@ -721,6 +721,45 @@ static void ps3av_monitor_info_dump(cons
}
}
+static const struct ps3av_monitor_quirk {
+ const char *monitor_name;
+ u32 clear_60, clear_50, clear_vesa;
+} ps3av_monitor_quirks[] = {
+ {
+ .monitor_name = DELL 2007WFP,
+ .clear_60 = PS3AV_RESBIT_1920x1080I
+ }, {
+ .monitor_name = L226WTQ,
+ .clear_60 = PS3AV_RESBIT_1920x1080I |
+ PS3AV_RESBIT_1920x1080P
+ }, {
+ .monitor_name = SyncMaster,
+ .clear_60 = PS3AV_RESBIT_1920x1080I
+ }
+};
+
+static void ps3av_fixup_monitor_info(struct ps3av_info_monitor *info)
+{
+ unsigned int i;
+ const struct ps3av_monitor_quirk *quirk;
+
+ for (i = 0; i ARRAY_SIZE(ps3av_monitor_quirks); i++) {
+ quirk = ps3av_monitor_quirks[i];
+ if (!strncmp(info-monitor_name, quirk-monitor_name,
+sizeof(info-monitor_name))) {
+ pr_info(%s: Applying quirk for %s\n, __func__,
+ quirk-monitor_name);
+ info-res_60.res_bits = ~quirk-clear_60;
+ info-res_60.native = ~quirk-clear_60;
+ info-res_50.res_bits = ~quirk-clear_50;
+ info-res_50.native = ~quirk-clear_50;
+ info-res_vesa.res_bits = ~quirk-clear_vesa;
+ info-res_vesa.native = ~quirk-clear_vesa;
+ break;
+ }
+ }
+}
+
static int ps3av_auto_videomode(struct ps3av_pkt_av_get_hw_conf *av_hw_conf,
int boot)
{
@@ -739,6 +778,8 @@ static int ps3av_auto_videomode(struct p
ps3av_monitor_info_dump(monitor_info);
info = monitor_info.info;
+ ps3av_fixup_monitor_info(info);
+
switch (info-monitor_type) {
case PS3AV_MONITOR_TYPE_DVI:
dvi = PS3AV_MODE_DVI;
--
With kind regards,
Geert Uytterhoeven
Software Architect
Sony Network and Software Technology Center Europe
The Corporate Village · Da Vincilaan 7-D1 · B-1935 Zaventem · Belgium
Phone:+32 (0)2 700 8453
Fax: +32 (0)2 700 8622
E-mail: [EMAIL PROTECTED]
Internet: http://www.sony-europe.com/
Sony Network and Software Technology Center Europe
A division of Sony Service Centre (Europe) N.V.
Registered office: Technologielaan 7 · B-1840 Londerzeel · Belgium
VAT BE 0413.825.160 · RPR Brussels
Fortis Bank Zaventem · Swift GEBABEBB08A · IBAN BE39001382358619
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] Added missing CEURNR register
According to the publicly available MPC8360E RM (rev. 1 from 09/2006 and rev. 2
from 05/2007) and MPC8323E RM (rev. 1 from 09/2006), CEURNR is the QE microcode
revision number register and is located at offset 0x1b8 within the QE internal
register space
Signed-off-by: Emil Medve [EMAIL PROTECTED]
---
I'm writing a driver and I felt the need to know the microcode revision
This patch is against Paul's tree: c4d5e375470862fd741f93bf0686d7ac2f7fdce4
powerpc scripts/checkpatch.pl 0001-Added-missing-CEURNR-register.patch
Your patch has no obvious style problems and is ready for submission.
include/asm-powerpc/immap_qe.h |5 +++--
1 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/include/asm-powerpc/immap_qe.h b/include/asm-powerpc/immap_qe.h
index 1020b7f..02548f7 100644
--- a/include/asm-powerpc/immap_qe.h
+++ b/include/asm-powerpc/immap_qe.h
@@ -86,8 +86,9 @@ struct cp_qe {
__be16 ceexe4; /* QE external request 4 event register */
u8 res11[0x2];
__be16 ceexm4; /* QE external request 4 mask register */
- u8 res12[0x2];
- u8 res13[0x280];
+ u8 res12[0x3A];
+ __be32 ceurnr; /* QE microcode revision number register */
+ u8 res13[0x244];
} __attribute__ ((packed));
/* QE Multiplexer */
--
1.5.3.GIT
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH v2 1/4] Implement {read,update}_persistent_clock.
Tony, I'm about to release a new -rt patch based on -rc8. This patch series blew up totally in trying to get it applied. I'm leaving it out, so after I release the next series, could you update these patches. Thanks, -- Steve ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH v2 1/4] Implement {read,update}_persistent_clock.
Hello. Steven Rostedt wrote: Tony, I'm about to release a new -rt patch based on -rc8. This patch series blew up totally in trying to get it applied. I'm leaving it out, so after I release the next series, could you update these patches. No wonder here: the -rt patch already has much of this code since around 2.6.21. They have been submitted by me, mostly... and this patchset is against the Linus' tree. WBR, Sergei ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH v2 1/4] Implement {read,update}_persistent_clock.
-- On Wed, 26 Sep 2007, Sergei Shtylyov wrote: Hello. Steven Rostedt wrote: Tony, I'm about to release a new -rt patch based on -rc8. This patch series blew up totally in trying to get it applied. I'm leaving it out, so after I release the next series, could you update these patches. No wonder here: the -rt patch already has much of this code since around 2.6.21. They have been submitted by me, mostly... and this patchset is against the Linus' tree. That would explain it ;-) I was searching the linux-rt-users mailing list for any patches, and pulled in any that looked legit. These happen to in that mailing list too. -- Steve ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH v2 1/4] Implement {read,update}_persistent_clock.
On Wed, 2007-09-26 at 15:44 -0400, Steven Rostedt wrote: No wonder here: the -rt patch already has much of this code since around 2.6.21. They have been submitted by me, mostly... and this patchset is against the Linus' tree. That would explain it ;-) I was searching the linux-rt-users mailing list for any patches, and pulled in any that looked legit. These happen to in that mailing list too. I'll sort that out along with the other hrt updates. tglx ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] [serial gadget] Disable endpoints on unload
After Serial gadget is being unloaded, neither serial itself, nor other gadget stuff can be loaded subsequently. Signed-off-by: Vitaly Bordug [EMAIL PROTECTED] --- drivers/usb/gadget/serial.c |6 ++ 1 files changed, 6 insertions(+), 0 deletions(-) diff --git a/drivers/usb/gadget/serial.c b/drivers/usb/gadget/serial.c index ce4d2e0..594284a 100644 --- a/drivers/usb/gadget/serial.c +++ b/drivers/usb/gadget/serial.c @@ -1487,6 +1487,12 @@ static void /* __init_or_exit */ gs_unbind(struct usb_gadget *gadget) dev-dev_ctrl_req = NULL; } gs_free_ports(dev); + if (dev-dev_notify_ep) + usb_ep_disable(dev-dev_notify_ep); + if (dev-dev_in_ep) + usb_ep_disable(dev-dev_in_ep); + if (dev-dev_out_ep) + usb_ep_disable(dev-dev_out_ep); kfree(dev); set_gadget_data(gadget, NULL); } ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 0/3] PowerPC: Add cpu_setup functionality to 44x platform
On Fri, 21 Sep 2007 18:41:49 +0400 Valentine Barshak [EMAIL PROTECTED] wrote: This patchset adds cpu_setup functionality to PowerPC 44x, moves FPU init to cpu_setup callback and adds 440EPx/440GRx incorrect write to DDR SDRAM errata workaround. This set looks pretty good to me. Aside from the slight oddity of adding an essentially empty file in the first patch. But it makes things nicely bisectable and I asked for it to be done that way. Unless someone has objections, I'll probably pull this in soon after I test a bit. josh ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
really old glibc on 8xx or 403 with bleeding-edge kernel - anyone care?
Since about May 2001, we have put two AT_IGNOREPPC entries at the beginning of the ELF auxiliary vector. The reason for this is that glibc prior to April 2001 rounded up the address of the base of the aux vector to a multiple of 16. I think we can now get rid of the AT_IGNOREPPC entries. Well, in fact what old glibc did was a little more complex than that. It worked out the standard aux vector base (i.e. the address of the word after the end of the environment pointers), and then chose either that or that address rounded up to a multiple of 16 bytes. The way it chose was by checking the word at the rounded address - if it was more than 16 it used the standard base address, otherwise it used the rounded address. So the way the AT_IGNOREPPC hack worked was by putting 4 words (two aux vector entries) at the beginning of the aux vector that all contained the value 22 (AT_IGNOREPPC). That made the old glibc code choose the standard aux vector base address. However, what comes after that is an AT_DCACHEBSIZE (19) entry and an AT_ICACHEBSIZE (20) entry. Thus, as long as the data cache blocksize and the instruction cache blocksize are greater than 16, these two entries will serve just as well as the AT_IGNOREPPC entries at making old glibc choose the standard aux vector base address. The only CPUs that we support with cache line sizes of 16 bytes or less are the 8xx family and the 403 family. So my question is, does anyone care about running ancient userland binaries (from 2001 or earlier) on 8xx or 403 with future kernels (2.6.x for x = 24)? If not then we can remove the AT_IGNOREPPC aux vector entries. Paul. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH v2 1/4] Implement {read,update}_persistent_clock.
On Wed, 2007-09-26 at 23:39 +0400, Sergei Shtylyov wrote: Hello. Steven Rostedt wrote: Tony, I'm about to release a new -rt patch based on -rc8. This patch series blew up totally in trying to get it applied. I'm leaving it out, so after I release the next series, could you update these patches. No wonder here: the -rt patch already has much of this code since around 2.6.21. They have been submitted by me, mostly... and this patchset is against the Linus' tree. Proper approach is to rip off what is altready in -rt there and replace it with Tony patch set. Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [Cbe-oss-dev] [patch 0/8] PS3 AV Settings Driver patches for 2.6.24
On Wed, 2007-09-26 at 18:33 +0200, Geert Uytterhoeven wrote: Hi, Here are some new patches for the PS3 AV Settings Driver (ps3av), which is used in close collaboration with the PS3 Virtual Frame Buffer Device Driver (ps3fb): [1] ps3av: eliminate unneeded temporary variables [2] ps3av: eliminate PS3AV_DEBUG [3] ps3av: use PS3 video mode ids in autodetect code [4] ps3av: treat DVI-D like HDMI in autodetect [5] ps3av: add autodetection for VESA modes [6] ps3av: add quirk database for broken monitors [7] ps3av: remove unused ps3av_set_mode() [8] ps3av: don't distinguish between `boot' and `non-boot' autodetection Please review, and queue for 2.6.24 if they're ok. Thanks! Question: As several DVI-D displays advertise they support 1080i modes while they actually don't (cfr. the quirk database), perhaps I should drop 1080i modes completely from the ps3av_preferred_modes[] table? Usually 720p looks better than 1080i anyway. What do you think? Definitely. If the autodetection fails Linux is basically unusable on PS3 unless you hack the kernel sources and build your own kboot and otheros.bld - not entirely trivial for novice users. So it's pretty important that it works 100%. cheers -- Michael Ellerman OzLabs, IBM Australia Development Lab wwweb: http://michael.ellerman.id.au phone: +61 2 6212 1183 (tie line 70 21183) We do not inherit the earth from our ancestors, we borrow it from our children. - S.M.A.R.T Person signature.asc Description: This is a digitally signed message part ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 8/15] bootwrapper: convert flatdevtree to version 16
On Wed, Sep 26, 2007 at 11:19:47AM -0500, Milton Miller wrote: On Sep 24, 2007, at 10:46 PM, David Gibson wrote: On Mon, Sep 24, 2007 at 01:54:32AM -0500, Milton Miller wrote: On Sep 23, 2007, at 10:36 PM, David Gibson wrote: On Fri, Sep 21, 2007 at 06:05:06PM -0500, Milton Miller wrote: [snip] +#define MIN_VERSION 2 +#define OUT_VERSION 16 Should output version 17. In any case, don't try to be so general - just convert v123 (all basically the same) to latest (i.e. v17) without all the #if nonsense. Outputing v17 instead of 16 requires more words to be added to the header, and the library does fine with v16. For now. libfdt will want v17. Although it will (eventually) have it's own v16-v17 conversion code. If libfdt gets merged without supporting v16 input, then that will be a regression. This code isn't pretending to address that. The current flat tree code works with v16. Hrm, true. Since I'm working on merging libfdt right now, I guess that moves up my schedule for getting the v16-v17 conversion code working. Actually the v1 trees has some other differences such as initrd addresses were kernel linear not real, cpus were assigned logical numbers ... so while the structure didn't change except for the header field, the contents did. !? what's your source for this. v2 and v3 were absolutely supposed to be backwards compatible with v1 which would not be the case with silent semantic changes such as this. What's your souce for saying the were supposed to be backwards compatable? That dtc fills out the struct header so? Sitting next to BenH and knowing he always intended them to be so. My source is my involvment when v2 was defined (they were discovered while writing my device tree generation code): The actual binary structure is compatable, just not the contents of the properties nor how any slave cpus wait (for some trees it doesn't matter). http://git.kernel.org/?p=linux/kernel/git/horms/kexec-tools- testing.git;a=blob;f=kexec/arch/ppc64/fs2dt.c; hb=b84b87747a16f0afbef6f6802bb794a94f4961d9 An old version of fs2dt is hardly definitive. It could just be Plain Wrong, nothing to do with the dt version. And some more changes just before that: http://git.kernel.org/?p=linux/kernel/git/torvalds/old-2.6-bkcvs.git; a=history;f=arch/ppc64/kernel/prom_init.c; h=e570799a84cc5328e9f0fd44592cb0b828d8c13a; hb=4ae24c4e8a8f68950a7774ca1cdfe69bfe4e2ffc I don't know what bit you're referring to in that batch of commits. So its mostly when the kernel generated and required v1 trees, it was ppc64 only and had these other content and handoff semantics. If it were to get a v1 tree, it only copes for the boot cpu determination I'm not aware of any code other than the kernel that would actually generate a v1 tree (other than dtc, which always supporteed v2, and doesn't care about these differences). -- David Gibson| I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_ | _way_ _around_! http://www.ozlabs.org/~dgibson ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] add Altivec/VMX state to coredumps
On Wed, 2007-09-26 at 00:37 -0500, Kumar Gala wrote: On Sep 25, 2007, at 11:56 PM, Mark Nelson wrote: Kumar Gala wrote: On Sep 25, 2007, at 8:22 PM, Mark Nelson wrote: Kumar Gala wrote: On Sep 24, 2007, at 11:03 PM, Mark Nelson wrote: Update dump_task_altivec() (that has so far never been put to use) so that it dumps the Altivec/VMX registers (VR[0] - VR[31], VSCR and VRSAVE) in the same format as the ptrace get_vrregs() and add the appropriate glue typedefs and #defines to include/asm-powerpc/elf.h for it to work. Is there some way to tell if the core dump has altivec registers state in it? I'm wondering how we distinguish a core dump w/altivec state vs one with SPE state. - k If the core dump has the Altivec registers saved in there it will have a note called LINUX as shown below: $ readelf -n core Notes at offset 0x02b4 with length 0x05c8: Owner Data size Description CORE 0x010c NT_PRSTATUS (prstatus structure) CORE 0x0080 NT_PRPSINFO (prpsinfo structure) CORE 0x00b0 NT_AUXV (auxiliary vector) CORE 0x0108 NT_FPREGSET (floating point registers) LINUX 0x0220 NT_PRXFPREG (user_xfpregs structure) This mirrors what occurs with the SSE registers on i386 core dumps in order to keep things as similar as possible. I can't find any place where dump_spe() is called at the moment, but I suppose if it were to be hooked up in the future it could cause confusion. The Altivec register state in the core file is much larger than what would be dumped by the current dump_spe(), but I'm not sure if that matters... There's a patch for GDB that currently reads the contents of these vector registers from the core file, but it's being held until this patch has been commented on and/or approved of, so if it comes to it the note name could be changed to ALTIVEC (or something similar). I think we should NOT overload NT_PRXFPREG and add proper note types NT_ALTIVEC NT_SPE for those register sets. Who on the GDB side would we need to coordinate such a change with? - k You're probably right :) What cores have SPE at the moment? Also, perhaps more importantly, are there any plans to have Altivec and SPE in the same core? The e500 cores's from Freescale. No, they are pretty much mutually exclusive. I've been working with Carlos Eduardo Seo (Cc'ed on this mail) on the GDB side of this. From comments it looks like the expectation is that the combination of note type and name which is expected to be unique. I'm wondering if we should handle this via elf_coredump_extra_notes_size() elf_coredump_extra_notes_write(). Does GDB care about the order it sees the various sections in? I don't think those callbacks will work in this case, they're only called for the primary thread that's doing the coredump, not for each thread. Perhaps there's a way to adapt it though. I think the easiest solution for now is just to make the note type a #define and create a new value for Altivec. cheers -- Michael Ellerman OzLabs, IBM Australia Development Lab wwweb: http://michael.ellerman.id.au phone: +61 2 6212 1183 (tie line 70 21183) We do not inherit the earth from our ancestors, we borrow it from our children. - S.M.A.R.T Person signature.asc Description: This is a digitally signed message part ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
