[PATCH] Add for_each_child_of_node() helper for iterating over child nodes
Add for_each_child_of_node() to encapsulate the common idiom of iterating over the children of a device_node. Signed-off-by: Michael Ellerman <[EMAIL PROTECTED]> --- After conducting a straw pole of powerpc hackers, this seems to be the preferred name for such a beast. include/linux/of.h |4 1 files changed, 4 insertions(+), 0 deletions(-) diff --git a/include/linux/of.h b/include/linux/of.h index 5c39b92..c65af7b 100644 --- a/include/linux/of.h +++ b/include/linux/of.h @@ -46,6 +46,10 @@ extern struct device_node *of_find_node_by_phandle(phandle handle); extern struct device_node *of_get_parent(const struct device_node *node); extern struct device_node *of_get_next_child(const struct device_node *node, struct device_node *prev); +#define for_each_child_of_node(parent, child) \ + for (child = of_get_next_child(parent, NULL); child != NULL; \ +child = of_get_next_child(parent, child)) + extern struct property *of_find_property(const struct device_node *np, const char *name, int *lenp); -- 1.5.2.rc1.1884.g59b20 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] ehea: Add kdump support
On Fri, 2007-11-09 at 14:33 +0100, Thomas Klein wrote: > To support ehea driver reloading in a kdump kernel the driver has to perform > firmware handle deregistrations when the original kernel crashes. As there's > currently no notifier chain for machine crashes this patch enables kdump > support > in the ehea driver by bending the ppc_md.machine_crash_shutdown hook to its > own > machine crash handler. The original machine_crash_shutdown() fn is called > afterwards. This works fine as long as the ehea driver is the only one which > does so. Problems may occur if other drivers do the same and unload regularly. > This patch enables 2.6.24-rc2 to use kdump with ehea and only puts a very > low risk on base kernel. In 2.6.24 we know ehea is the only user of this > mechanism. The next step for 2.6.25 would be to add a proper notifier chain. > The full solution might be that register_reboot_notifier() provides sth > like a SYS_CRASH action. Please apply. > > Signed-off-by: Thomas Klein <[EMAIL PROTECTED]> > > --- > drivers/net/ehea/ehea.h |2 +- > drivers/net/ehea/ehea_main.c | 28 > 2 files changed, 29 insertions(+), 1 deletions(-) > Hi Thomas, I'm sorry, but this patch is all wrong IMHO. For kdump we have to assume that the kernel is fundamentally broken, we've panicked, so something bad has happened - every line of kernel code that is run decreases the chance that we'll successfully make it into the kdump kernel. So just calling unregister_driver() is no good, that's going to call lots of code, try to take lots of locks, rely on lots of data structures being uncorrupted etc. etc. And the hijacking of machine_crash_shutdown() is IMO not an acceptable solution, as you say it only works if EHEA is the only driver to do it. And as soon as EHEA does it other drivers will want to do it. What we need is the _minimal_ set of actions that can happen to make EHEA work in the kdump kernel. Solutions that might be better: a) if there are a finite number of handles and we can predict their values, just delete them all in the kdump kernel before the driver loads. b) if there are a small & finite number of handles, save their values in a device tree property and have the kdump kernel read them and delete them before the driver loads. c) if neither of those work, provide a minimal routine that _only_ deletes the handles in the crashed kernel. d) 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] Add for_each_child_of_node() helper for iterating over child nodes
On Mon, 26 Nov 2007 19:03:45 +1100 (EST) Michael Ellerman <[EMAIL PROTECTED]> wrote: > > Add for_each_child_of_node() to encapsulate the common idiom of > iterating over the children of a device_node. > > Signed-off-by: Michael Ellerman <[EMAIL PROTECTED]> Acked-by: Stephen Rothwell <[EMAIL PROTECTED]> -- Cheers, Stephen Rothwell[EMAIL PROTECTED] http://www.canb.auug.org.au/~sfr/ pgp32RLgnX8IJ.pgp Description: PGP signature ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Access to PCI Expansion ROMs on PPC
On Sun, Nov 25, 2007 at 11:41:01AM -0800, Robin H. Johnson wrote:
> I was looking around for a description of the ROM layout, and instead I
> found this: http://developer.apple.com/technotes/tn/tn2000.html
> It was relevant because it explicitly mentioned enabling the
> PCI_COMMAND_MEMORY bit in the PCI_COMMAND register, which is NOT present
> in any path of the sizing code.
...
> By doing:
> # dev="/sys/devices/pci0001:00/0001:00:03.0/0001:06:00.0/"
> # echo 1 >${dev}/enable
> # echo 1 >${dev}/rom
> # cat ${dev}/rom >rom
> The ROM is successfully returned for two of my 3 cards.
> Namely, both of the ones containing x86 BIOS (sata_sil24, ATI X700).
> The X1900 does still not return any ROM.
...
> I broke my testing kernel temporarily, so I need a bit more testing to
> see why the X1900 did not return a ROM. More on that in a couple of
> hours.
(Part of this is from an IRC discussion with benh, summarized with
results here).
Thanks to some friends, I added some more PCIe cards to the test set:
The complete list is now:
x86-BIOS:
- Silicon Image, Inc. SiI 3132 Serial ATA Raid II (sata_sil24)
- ATI X700
OpenFirmware (all get relevant nodes in the device-tree after boot):
- ATI X1900
- Nvidia 6600
- Marvell SATA 7042 (sata_mv) [Sonnet Tempo SATA E4P]
For testing, I explicitly enable the device, and then try to read the
ROM. Additionally, I have some debug printk statements scattered about
rom.c and pci-sysfs.c, to detect various parts of the branching.
Additionaly per Jon's suggestion, I also have a bit of code at the end
of the sizing routine:
if (image == rom) { printk(...); return size; }
On the G5, the results are as follows:
- sata_sil24, X700, sata_mv - ROMS readable and valid.
- Nvidia 6600 - Returns junk data, changes between boots.
pci_get_rom_size fails the size decode, the first two readb() both
return 0x33
- ATI X1900 - Returns nulls. pci_get_rom_size fails here, the readbs()
return 0x00.
On an x86_64 (Core2 Duo), the results are as follows:
- sata_sil24 , X700 - ROMS readable and valid.
- sata_mv - appears in lspci, and works, but lspci does NOT show an 'Expansion
ROM' line.
- Nvidia 6600, ATI X1900 - do not show up the kernel at all, or in
lspci. The PCIe Root port [8086:29a1] is entirely missing from the
lspci output.
Regarding the sub-thread on x86 emulation, that is totally out of scope
for this. The 'AtomBIOS' of the ATI cards, consists of multiple parts (I
may have minor errors here, ask airlied if you need more
clarification):
a) Initialization code (I think arch-specific)
b) AtomBIOS script interpreter (I think arch-specific)
c) AtomBIOS scripts (card-specific, but not arch-specific)
d) Data tables (card-specific, but not arch-specific)
The AtomBIOS parts of the various drivers need data from c+d primarily,
and provide their own script interpreter, or not using the scripts, just
the data tables.
--
Robin Hugh Johnson
Gentoo Linux Developer & Infra Guy
E-Mail : [EMAIL PROTECTED]
GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85
pgpaZ9ER8PI6m.pgp
Description: PGP signature
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Access to PCI Expansion ROMs on PPC
On Mon, 2007-11-26 at 00:59 -0800, Robin H. Johnson wrote: > > Regarding the sub-thread on x86 emulation, that is totally out of scope > for this. The 'AtomBIOS' of the ATI cards, consists of multiple parts (I > may have minor errors here, ask airlied if you need more > clarification): > a) Initialization code (I think arch-specific) > b) AtomBIOS script interpreter (I think arch-specific) > c) AtomBIOS scripts (card-specific, but not arch-specific) > d) Data tables (card-specific, but not arch-specific) > > The AtomBIOS parts of the various drivers need data from c+d primarily, > and provide their own script interpreter, or not using the scripts, just > the data tables. Are you sure the X1900 Mac Edition ROM contains any ATOM data structures though? I rather doubt it. -- Earthling Michel Dänzer | http://tungstengraphics.com Libre software enthusiast | Debian, X and DRI developer ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
perfmon2 needs hard_irq_disable() for powerpc
Hi, I've been reading through the perfmon2 patch for 2.6.23 and it dawned on me that in the powerpc architecture we have the notion of lazy-disabling of interrupts where we don't actually disable interrupts unless we see one come in and then turn them off. I believe a notable exception is the performance monitor interrupt which we allow to break into our critical sections. This is desirable because we want to profile those sections and right now, no in-kernel user of the performance monitor interrupt in powerpc does any synchronization across cpus inside the interrupt handler (oprofile seems to use per-cpu buffers/state for everything). We use hard_irq_disable() when we _really_ have to disable interrupts because we're switching out the kernel stack, etc. Perfmon2 is more demanding in its synchronization requirements and it uses spin_lock_irqsave() in the generic arch-neutral code in several places, I think this will break on powerpc the way we're handling things now. I'm copying a few people to solicit opinions on how best to deal with this. I think it's desirable to keep the property of letting us profile critical sections in the kernel wherever possible. So we would need to add hard_irq_disable/enable calls to the generic code, but want to check with you guys first. Sonny ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: perfmon2 needs hard_irq_disable() for powerpc
Hello Sonny, On Mon, Nov 26, 2007 at 02:44:38AM -0500, Sonny Rao wrote: > Hi, I've been reading through the perfmon2 patch for 2.6.23 and it > dawned on me that in the powerpc architecture we have the notion of > lazy-disabling of interrupts where we don't actually disable > interrupts unless we see one come in and then turn them off. I believe > a notable exception is the performance monitor interrupt which we > allow to break into our critical sections. This is desirable because > we want to profile those sections and right now, no in-kernel user of > the performance monitor interrupt in powerpc does any synchronization > across cpus inside the interrupt handler (oprofile seems to use > per-cpu buffers/state for everything). We use hard_irq_disable() when > we _really_ have to disable interrupts because we're switching out the > kernel stack, etc. > > Perfmon2 is more demanding in its synchronization requirements and it > uses spin_lock_irqsave() in the generic arch-neutral code in several > places, I think this will break on powerpc the way we're handling > things now. > We use spinlocks to serialize access to the perfmon context. The irq masking is here to avoid a race between a user calling into perfmon and a counter interrupt. Allowing PMU interrupts in critical sections is useful, yet it gets complicated very quickly because of locking issues, including within the perfmon code. For instance, a consequence of a interrupt could be that a SIGIO message is posted. If counter interrupts were allowed in the signal code, then we could potentially get dedlock situations. >From what you are saying it seems on powerpc, there may be a way to differentiate interrupts and thus possibly allow a less restrictive locking policy. > I'm copying a few people to solicit opinions on how best to deal with > this. I think it's desirable to keep the property of letting us > profile critical sections in the kernel wherever possible. So we would > need to add hard_irq_disable/enable calls to the generic code, but want to > check with you guys first. > I am open to suggestions. If we can enable monitoring in critical sections and still avoid races and dealocks, at least on powerpc, then I'll be happy to allow this. Thanks. -- -Stephane ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Access to PCI Expansion ROMs on PPC
On Mon, Nov 26, 2007 at 10:20:14AM +0100, Michel D?nzer wrote: > > Regarding the sub-thread on x86 emulation, that is totally out of scope > > for this. The 'AtomBIOS' of the ATI cards, consists of multiple parts (I > > may have minor errors here, ask airlied if you need more > > clarification): > > a) Initialization code (I think arch-specific) > > b) AtomBIOS script interpreter (I think arch-specific) > > c) AtomBIOS scripts (card-specific, but not arch-specific) > > d) Data tables (card-specific, but not arch-specific) > > > > The AtomBIOS parts of the various drivers need data from c+d primarily, > > and provide their own script interpreter, or not using the scripts, just > > the data tables. > Are you sure the X1900 Mac Edition ROM contains any ATOM data structures > though? I rather doubt it. That's what I'm trying to ascertain actually, because it directly impacts what work needs to be done in the drivers. If it was me writing the ROMs in the first place (but it's not), from what I understand of the ATOM, I'd have OpenFirmware versions of a+b, and then could re-use c+d. The fact that both Nvidia and ATI OF-powered cards fail when trying to access their expansion ROMs, I'm inclined to think there is something in accessing them that we are missing, and that the ROMs must exist (the sata_mv one existed and was accessible). On actually accessing the rest of the ATI X1900 card, the avivotool from git://people.freedesktop.org/~airlied/radeontool.git (avivo branch) can actually access the rest of the rest of the card registers. -- Robin Hugh Johnson Gentoo Linux Developer & Infra Guy E-Mail : [EMAIL PROTECTED] GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85 pgpezwRusHB9h.pgp Description: PGP signature ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH revised 3/4] powerpc: Add EXPORT_SYMBOL_GPL for symbols required by fs_enet and cpm_uart
On Sun, 25 Nov 2007 13:02:03 -0800 Dan Malek wrote: > > On Nov 25, 2007, at 8:18 AM, Vitaly Bordug wrote: > > > To prevent using those pointers from within non-GPL modules. kind > > of policy now... > > As the original copyright holder of nearly all of this of > this code, I do not wish this be done. In this particular case this is not going to happen anyway, but I will take your opinion into account for the similar cases. -- Sincerely, Vitaly ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] ehea: Add kdump support
Michael Ellerman wrote on 26.11.2007 09:16:28: > Solutions that might be better: > > a) if there are a finite number of handles and we can predict their > values, just delete them all in the kdump kernel before the driver > loads. Guessing the values does not work, because of the handle structure defined by the hypervisor. > b) if there are a small & finite number of handles, save their values > in a device tree property and have the kdump kernel read them and > delete them before the driver loads. 5*16*nr_ports+1+1= >82. a ML16 has 4 adapters with up to 16 ports, so the number is not small anymore The device tree functions are currently not exported. If you crashdump to a new kernel, will it get the device tree representation of the crashed kernel or of the initial one of open firmware? > c) if neither of those work, provide a minimal routine that _only_ > deletes the handles in the crashed kernel. I would hope this has the highest chance to actually work. For this we would have to add a proper notifier chain. Do you agree? > d) Firmware change? But that's not something you will get very soon. Christoph R. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH revised 3/4] powerpc: Add EXPORT_SYMBOL_GPL for symbols required by fs_enet and cpm_uart
Hi Vitaly, >> Maybe this is a stupid question, but why did you choose >> EXPORT_SYMBOL_GPL and not EXPORT_SYMBOL? >> > To prevent using those pointers from within non-GPL modules. kind of policy > now... In particular in this case, as these pointers are currently not exported, at all. They are currently used by a few drivers and will disappear again once these drivers have been converted to use the propper accessors, which will also prevent access conflicts to the CPM registers. Thanks, Jochen ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 1/3] [NET] phy/fixed.c: rework to not duplicate PHY layer functionality
With that patch fixed.c now fully emulates MDIO bus, thus no need
to duplicate PHY layer functionality. That, in turn, drastically
simplifies the code, and drops down line count.
As an additional bonus, now there is no need to register MDIO bus
for each PHY, all emulated PHYs placed on the platform fixed MDIO bus.
There is also no more need to pre-allocate PHYs via .config option,
this is all now handled dynamically.
p.s. Don't even try to understand patch content! Better: apply patch
and look into resulting drivers/net/phy/fixed.c.
Signed-off-by: Anton Vorontsov <[EMAIL PROTECTED]>
Signed-off-by: Vitaly Bordug <[EMAIL PROTECTED]>
---
drivers/net/phy/Kconfig | 32 +--
drivers/net/phy/fixed.c | 427 -
include/linux/phy_fixed.h | 49 ++---
3 files changed, 176 insertions(+), 332 deletions(-)
diff --git a/drivers/net/phy/Kconfig b/drivers/net/phy/Kconfig
index 54b2ba9..a05c614 100644
--- a/drivers/net/phy/Kconfig
+++ b/drivers/net/phy/Kconfig
@@ -61,34 +61,12 @@ config ICPLUS_PHY
Currently supports the IP175C PHY.
config FIXED_PHY
- tristate "Drivers for PHY emulation on fixed speed/link"
+ tristate "Drivers for MDIO Bus/PHY emulation on fixed speed/link"
---help---
- Adds the driver to PHY layer to cover the boards that do not have any
PHY bound,
- but with the ability to manipulate the speed/link in software. The
relevant MII
- speed/duplex parameters could be effectively handled in a
user-specified function.
- Currently tested with mpc866ads.
-
-config FIXED_MII_10_FDX
- bool "Emulation for 10M Fdx fixed PHY behavior"
- depends on FIXED_PHY
-
-config FIXED_MII_100_FDX
- bool "Emulation for 100M Fdx fixed PHY behavior"
- depends on FIXED_PHY
-
-config FIXED_MII_1000_FDX
- bool "Emulation for 1000M Fdx fixed PHY behavior"
- depends on FIXED_PHY
-
-config FIXED_MII_AMNT
-int "Number of emulated PHYs to allocate "
-depends on FIXED_PHY
-default "1"
----help---
-Sometimes it is required to have several independent emulated
-PHYs on the bus (in case of multi-eth but phy-less HW for instance).
-This control will have specified number allocated for each fixed
-PHY type enabled.
+ Adds the platform "fixed" MDIO Bus to cover the boards that use
+ PHYs that are not connected to the real MDIO bus.
+
+ Currently tested with mpc866ads and mpc8349e-mitx.
config MDIO_BITBANG
tristate "Support for bitbanged MDIO buses"
diff --git a/drivers/net/phy/fixed.c b/drivers/net/phy/fixed.c
index 5619182..31719b3 100644
--- a/drivers/net/phy/fixed.c
+++ b/drivers/net/phy/fixed.c
@@ -1,362 +1,237 @@
/*
- * drivers/net/phy/fixed.c
+ * Fixed MDIO bus (MDIO bus emulation with fixed PHYs)
*
- * Driver for fixed PHYs, when transceiver is able to operate in one fixed
mode.
+ * Author: Vitaly Bordug <[EMAIL PROTECTED]>
+ * Anton Vorontsov <[EMAIL PROTECTED]>
*
- * Author: Vitaly Bordug
- *
- * Copyright (c) 2006 MontaVista Software, Inc.
+ * Copyright (c) 2006-2007 MontaVista Software, Inc.
*
* This program is free software; you can redistribute it and/or modify it
* under the terms of the GNU General Public License as published by the
* Free Software Foundation; either version 2 of the License, or (at your
* option) any later version.
- *
*/
+
#include
-#include
-#include
-#include
-#include
-#include
-#include
-#include
-#include
-#include
-#include
-#include
-#include
#include
+#include
+#include
#include
-#include
#include
#include
-#include
-#include
-#include
-
-/* we need to track the allocated pointers in order to free them on exit */
-static struct fixed_info *fixed_phy_ptrs[CONFIG_FIXED_MII_AMNT*MAX_PHY_AMNT];
-
-/*-
- * If something weird is required to be done with link/speed,
- * network driver is able to assign a function to implement this.
- * May be useful for PHY's that need to be software-driven.
-
*-*/
-int fixed_mdio_set_link_update(struct phy_device *phydev,
- int (*link_update) (struct net_device *,
- struct fixed_phy_status *))
-{
- struct fixed_info *fixed;
-
- if (link_update == NULL)
- return -EINVAL;
-
- if (phydev) {
- if (phydev->bus) {
- fixed = phydev->bus->priv;
- fixed->link_update = link_update;
- return 0;
- }
- }
- return -EINVAL;
-}
+#define MII_REGS_NUM 29
-EXPORT_SYMBOL(fixed_mdio_set_link_update);
+struct fixed_mdio_bus {
+ int irqs[PHY_MAX_ADDR];
+ struct mii_bus mii_bus;
+ struct list_head phys;
[PATCH 2/3] [POWERPC] fsl_soc: add support for gianfar for fixed-link property
fixed-link says: register new "Fixed/emulated PHY", i.e. PHY that
not connected to the real MDIO bus.
Signed-off-by: Vitaly Bordug <[EMAIL PROTECTED]>
Signed-off-by: Anton Vorontsov <[EMAIL PROTECTED]>
---
Documentation/powerpc/booting-without-of.txt |3 +
arch/powerpc/sysdev/fsl_soc.c| 56 ++
2 files changed, 42 insertions(+), 17 deletions(-)
diff --git a/Documentation/powerpc/booting-without-of.txt
b/Documentation/powerpc/booting-without-of.txt
index e9a3cb1..cf25070 100644
--- a/Documentation/powerpc/booting-without-of.txt
+++ b/Documentation/powerpc/booting-without-of.txt
@@ -1254,6 +1254,9 @@ platforms are moved over to use the flattened-device-tree
model.
services interrupts for this device.
- phy-handle : The phandle for the PHY connected to this ethernet
controller.
+- fixed-link : where a is emulated phy id - choose any,
+ but unique to the all specified fixed-links, b is duplex - 0 half,
+ 1 full, c is link speed - d#10/d#100/d#1000.
Recommended properties:
diff --git a/arch/powerpc/sysdev/fsl_soc.c b/arch/powerpc/sysdev/fsl_soc.c
index 3ace747..e06a5c9 100644
--- a/arch/powerpc/sysdev/fsl_soc.c
+++ b/arch/powerpc/sysdev/fsl_soc.c
@@ -24,6 +24,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -193,7 +194,6 @@ static const char *gfar_tx_intr = "tx";
static const char *gfar_rx_intr = "rx";
static const char *gfar_err_intr = "error";
-
static int __init gfar_of_init(void)
{
struct device_node *np;
@@ -277,29 +277,51 @@ static int __init gfar_of_init(void)
gfar_data.interface = PHY_INTERFACE_MODE_MII;
ph = of_get_property(np, "phy-handle", NULL);
- phy = of_find_node_by_phandle(*ph);
+ if (ph == NULL) {
+ struct fixed_phy_status status = {};
+ u32 *fixed_link;
- if (phy == NULL) {
- ret = -ENODEV;
- goto unreg;
- }
+ fixed_link = (u32*)of_get_property(np,
"fixed-link",NULL);
+ if (!fixed_link) {
+ ret = -ENODEV;
+ goto unreg;
+ }
- mdio = of_get_parent(phy);
+ status.link = 1;
+ status.duplex = fixed_link[1];
+ status.speed = fixed_link[2];
+
+ ret = fixed_phy_add(PHY_POLL, fixed_link[0], &status);
+ if (ret)
+ goto unreg;
+
+ gfar_data.bus_id = 0;
+ gfar_data.phy_id = fixed_link[0];
+ } else {
+ phy = of_find_node_by_phandle(*ph);
+
+ if (phy == NULL) {
+ ret = -ENODEV;
+ goto unreg;
+ }
+
+ mdio = of_get_parent(phy);
+
+ id = of_get_property(phy, "reg", NULL);
+ ret = of_address_to_resource(mdio, 0, &res);
+ if (ret) {
+ of_node_put(phy);
+ of_node_put(mdio);
+ goto unreg;
+ }
+
+ gfar_data.phy_id = *id;
+ gfar_data.bus_id = res.start;
- id = of_get_property(phy, "reg", NULL);
- ret = of_address_to_resource(mdio, 0, &res);
- if (ret) {
of_node_put(phy);
of_node_put(mdio);
- goto unreg;
}
- gfar_data.phy_id = *id;
- gfar_data.bus_id = res.start;
-
- of_node_put(phy);
- of_node_put(mdio);
-
ret =
platform_device_add_data(gfar_dev, &gfar_data,
sizeof(struct
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 3/3] [POWERPC] MPC8349E-mITX: Vitesse 7385 PHY is not connected to the MDIO bus
...thus use fixed-link to register proper "Fixed PHY"
Signed-off-by: Anton Vorontsov <[EMAIL PROTECTED]>
Signed-off-by: Vitaly Bordug <[EMAIL PROTECTED]>
---
arch/powerpc/boot/dts/mpc8349emitx.dts | 11 ++-
1 files changed, 2 insertions(+), 9 deletions(-)
diff --git a/arch/powerpc/boot/dts/mpc8349emitx.dts
b/arch/powerpc/boot/dts/mpc8349emitx.dts
index 5072f6d..e2d00f1 100644
--- a/arch/powerpc/boot/dts/mpc8349emitx.dts
+++ b/arch/powerpc/boot/dts/mpc8349emitx.dts
@@ -115,14 +115,6 @@
reg = <1c>;
device_type = "ethernet-phy";
};
-
- /* Vitesse 7385 */
- phy1f: [EMAIL PROTECTED] {
- interrupt-parent = < &ipic >;
- interrupts = <12 8>;
- reg = <1f>;
- device_type = "ethernet-phy";
- };
};
[EMAIL PROTECTED] {
@@ -159,7 +151,8 @@
local-mac-address = [ 00 00 00 00 00 00 ];
interrupts = <23 8 24 8 25 8>;
interrupt-parent = < &ipic >;
- phy-handle = < &phy1f >;
+ /* Vitesse 7385 isn't on the MDIO bus */
+ fixed-link = <1 1 d#1000>;
linux,network-index = <1>;
};
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 2/3] [POWERPC] fsl_soc: add support for gianfar for fixed-link property
On Mon, 2007-11-26 at 17:29 +0300, Vitaly Bordug wrote: > fixed-link says: register new "Fixed/emulated PHY", i.e. PHY that > not connected to the real MDIO bus. > > Signed-off-by: Vitaly Bordug <[EMAIL PROTECTED]> > Signed-off-by: Anton Vorontsov <[EMAIL PROTECTED]> > > --- > > Documentation/powerpc/booting-without-of.txt |3 + > arch/powerpc/sysdev/fsl_soc.c| 56 > ++ > 2 files changed, 42 insertions(+), 17 deletions(-) > > > diff --git a/Documentation/powerpc/booting-without-of.txt > b/Documentation/powerpc/booting-without-of.txt > index e9a3cb1..cf25070 100644 > --- a/Documentation/powerpc/booting-without-of.txt > +++ b/Documentation/powerpc/booting-without-of.txt > @@ -1254,6 +1254,9 @@ platforms are moved over to use the > flattened-device-tree model. >services interrupts for this device. > - phy-handle : The phandle for the PHY connected to this ethernet >controller. > +- fixed-link : where a is emulated phy id - choose any, > + but unique to the all specified fixed-links, b is duplex - 0 half, > + 1 full, c is link speed - d#10/d#100/d#1000. Good work! May I suggest adding a "d" to where d is flow control - 0 no, 1 yes flow control or not just popped up here today so I got a use for it. Jocke ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 1/3] [POWERPC] Add docs for Freescale 83xx SATA device tree nodes
On Nov 25, 2007, at 4:22 PM, Arnd Bergmann wrote: > On Wednesday 21 November 2007, Kumar Gala wrote: >> +* Freescale 8xxx/3.0 Gb/s SATA nodes >> + >> +SATA nodes are defined to describe on-chip Serial ATA >> controllers. >> +Each SATA port should have its own node. >> + >> +Required properties: >> +- compatible: compatible list, contains 2 entries, >> first is >> +"fsl,sata-CHIP", where CHIP is the processor >> +(mpc8315, mpc8379, etc.) and the second is >> +"fsl,sata-pq2pro" >> +- interrupts: >> +- interrupt-parent : optional, if needed for interrupt mapping >> +- reg : >> + > > Should this maybe also mandate a compatible property that is defined > in a way to match the generic (p)ata_of_platform driver? Is there something about the (p)ata_of_platform driver you think we can use. The SATA controller here is a unique piece of HW and requires a unique driver so I'm not sure what we get from (p)ata_of_platform. - k ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] ehea: Add kdump support
On Mon, 2007-11-26 at 19:16 +1100, Michael Ellerman wrote: > > Hi Thomas, > > I'm sorry, but this patch is all wrong IMHO. > > For kdump we have to assume that the kernel is fundamentally broken, > we've panicked, so something bad has happened - every line of kernel > code that is run decreases the chance that we'll successfully make it > into the kdump kernel. I agree with Michael. > Solutions that might be better: > > a) if there are a finite number of handles and we can predict their > values, just delete them all in the kdump kernel before the driver > loads. This is a good solution if handles are predefined. > b) if there are a small & finite number of handles, save their values > in a device tree property and have the kdump kernel read them and > delete them before the driver loads. Also good but is more complicated. > c) if neither of those work, provide a minimal routine that _only_ > deletes the handles in the crashed kernel. > d) Can the driver or configuration method for the driver query PHYP to determine if there are any pre-existing mappings... Regards, Luke ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 3/3] [POWERPC] Add docs for Freescale DMA & DMA channel device tree nodes
Timur Tabi wrote: > David Gibson wrote: > >> Indeed, indexing or writing into shared registers is exactly what >> cell-index is for. > > I don't care whether it's cell-index or device-id, but I need to know > which DMA controller is #0 and which one is #1, and I need to know which > channel is #0, which one is #1, etc. OK, cell-index makes sense there too, then. -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [RFC/PATCHv3] powerpc: Move CPM command handling into the cpm drivers
Jochen Friedrich wrote:
> diff --git a/arch/powerpc/sysdev/commproc.c
> b/arch/powerpc/sysdev/commproc.c
> index f6a6378..2426bcb 100644
> --- a/arch/powerpc/sysdev/commproc.c
> +++ b/arch/powerpc/sysdev/commproc.c
> @@ -240,6 +240,34 @@ void __init cpm_reset(void)
> #endif
> }
>
> +static DEFINE_SPINLOCK(cmd_lock);
> +
> +#define MAX_CR_CMD_LOOPS1
> +
> +int cpm_command(u32 command, u8 opcode)
> +{
> +int i, ret;
> +unsigned long flags;
> +
> +if (command & 0xff0f)
> +return -EINVAL;
> +
> +spin_lock_irqsave(&cmd_lock, flags);
I'm a little uneasy about this -- what's the longest it can take for the
CPM command to complete (or timeout)? I'd rather use a mutex, if we can
make sure that it's never called from atomic context.
> +
> +ret = 0;
> +out_be16(&cpmp->cp_cpcr, command | CPM_CR_FLG | (opcode << 8));
> +for (i = 0; i < MAX_CR_CMD_LOOPS; i++)
> +if ((in_be16(&cpmp->cp_cpcr) & CPM_CR_FLG) == 0)
> +goto out;
> +
> +printk(KERN_ERR "%s(): Not able to issue CPM command\n",
> __FUNCTION__);
> +ret = -EIO;
> +out:
> +spin_unlock_irqrestore(&cmd_lock, flags);
> +return ret;
> +}
> +EXPORT_SYMBOL_GPL(cpm_command);
Can we please not play the GPL DRM game here?
Besides, Documentation/DocBook/kernel-hacking.tmpl explicitly says that
"It implies that the function is considered an internal implementation
issue, and not really an interface."
I don't think this is the case here.
-Scott
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Sequoia EMAC only works if u-boot initializes it?
I have noticed odd behavior on a Sequoia board. Kernel is built from DENX git, ARCH=powerpc, 2.6.23.1. Sequence that works: 1) In u-boot, do "dhcp" (this initializes the PHY) 2) Boot linux from flash 3) ifconfig eth0 192.168.0.101 netmask 255.255.255.0 up Ethernet is now functional, and I can ping the Sequoia (and it can ping my host) Sequence that does not work: 1) Boot linux from flash without letting u-boot touch eth0 2) ifconfig eth0 192.168.0.101 netmask 255.255.255.0 up Ethernet appears to come up, but it is not functional. I.e. I get "eth0: link is up, 100 FDX, pause enabled" but I cannot ping the board, and the board cannot ping my host. So, the kernel appears to be missing some initialization that u-boot provides. However, eth1 is more strange. U-boot can use it (via "setenv ethact ppc_4xx_eth1;dhcp"), however, the kernel cannot use it, whether or not u-boot first initializes it. If anyone has suggestions on where to look, I'd appreciate it. I'm going to look at the PHY register settings and see if there are any clues there... Steve ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 1/3] [POWERPC] Add docs for Freescale 83xx SATA device tree nodes
On Monday 26 November 2007, you wrote: > On Nov 25, 2007, at 4:22 PM, Arnd Bergmann wrote: > > Should this maybe also mandate a compatible property that is defined > > in a way to match the generic (p)ata_of_platform driver? > > Is there something about the (p)ata_of_platform driver you think we > can use. The SATA controller here is a unique piece of HW and > requires a unique driver so I'm not sure what we get from > (p)ata_of_platform. All ata controllers I've dealt with so far are to some degree compatible to the old PC style controllers. My point was that this should ideally be reflected in the device tree so that you could in theory use the ata_of_platform driver, even if you normally would prefer the new driver for performance reasons. If your controller doesn't have the legacy register set, this clearly doesn't make any sense and you should not list it as compatible with something generic. Arnd <>< ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Sequoia EMAC only works if u-boot initializes it?
On Mon, 26 Nov 2007 10:59:35 -0500 "Steven A. Falco" <[EMAIL PROTECTED]> wrote: > I have noticed odd behavior on a Sequoia board. Kernel is built from > DENX git, ARCH=powerpc, 2.6.23.1. > > Sequence that works: > 1) In u-boot, do "dhcp" (this initializes the PHY) > 2) Boot linux from flash > 3) ifconfig eth0 192.168.0.101 netmask 255.255.255.0 up > Ethernet is now functional, and I can ping the Sequoia (and it can ping > my host) > > Sequence that does not work: > 1) Boot linux from flash without letting u-boot touch eth0 > 2) ifconfig eth0 192.168.0.101 netmask 255.255.255.0 up > Ethernet appears to come up, but it is not functional. I.e. I get > "eth0: link is up, 100 FDX, pause enabled" but I cannot ping the board, > and the board cannot ping my host. > > So, the kernel appears to be missing some initialization that u-boot > provides. There are some PHY patches from Valentine that Ben needs to send to Jeff Garzik. josh ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Revisited, audio codec device tree entries.
David Gibson wrote: > 1) We have a "universal" device-tree-based fabric driver which > parses all the above-described interconnection information in the > device tree and handles any situation. Cool, but probably a lot of > work and fiddly to get right. Definitely a lot of work. I suggest we wait until there are a few PowerPC ASOC v2 audio drivers in the kernel before we even consider this. And it may not even be possible. I can easily imagine situations where we need board-specific code that belongs in a machine-specific fabric driver. -- Timur Tabi Linux kernel developer at Freescale ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: time accounting problem (powerpc only?)
Contrary to what I claimed later in the thread, my 64-bit powerpc box (quad-core G5) doesn't suffer from this problem. Does anybody have any idea? I don't even know how to debug it further. johannes 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: Sequoia EMAC only works if u-boot initializes it?
On Monday 26 November 2007, Steven A. Falco wrote: > I have noticed odd behavior on a Sequoia board. Kernel is built from > DENX git, ARCH=powerpc, 2.6.23.1. > > Sequence that works: > 1) In u-boot, do "dhcp" (this initializes the PHY) > 2) Boot linux from flash > 3) ifconfig eth0 192.168.0.101 netmask 255.255.255.0 up > Ethernet is now functional, and I can ping the Sequoia (and it can ping > my host) > > Sequence that does not work: > 1) Boot linux from flash without letting u-boot touch eth0 > 2) ifconfig eth0 192.168.0.101 netmask 255.255.255.0 up > Ethernet appears to come up, but it is not functional. I.e. I get > "eth0: link is up, 100 FDX, pause enabled" but I cannot ping the board, > and the board cannot ping my host. Do you have a 100MBit connection? Or Gbit? Could you please send the complete bootlog. > So, the kernel appears to be missing some initialization that u-boot > provides. > > However, eth1 is more strange. U-boot can use it (via "setenv ethact > ppc_4xx_eth1;dhcp"), however, the kernel cannot use it, whether or not > u-boot first initializes it. > > If anyone has suggestions on where to look, I'd appreciate it. I'm > going to look at the PHY register settings and see if there are any > clues there... Again it would be interesting to see the bootlog here. Best regards, Stefan = 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: [RFC/PATCH] powerpc: Move CPM command handling into the cpm drivers
On Fri, Nov 23, 2007 at 12:51:21AM +0300, Vitaly Bordug wrote: > Even that might be not enough - we may have simultaneous call of this func > in non-smp case... Do you really think that every piece of code that uses spinlocks in the kernel is broken on non-SMP? > I was thinking of some kind of refcount, so one that is going to issue CPM > command, must do say pq_cpmp_get() and another driver won't be able to > mangle with cpcr while it's not done with previous request. How on earth are you going to effect mutual exclusion using reference counting? -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Access to PCI Expansion ROMs on PPC
On 11/26/07, Robin H. Johnson <[EMAIL PROTECTED]> wrote: > On Mon, Nov 26, 2007 at 10:20:14AM +0100, Michel D?nzer wrote: > > > Regarding the sub-thread on x86 emulation, that is totally out of scope > > > for this. The 'AtomBIOS' of the ATI cards, consists of multiple parts (I > > > may have minor errors here, ask airlied if you need more > > > clarification): > > > a) Initialization code (I think arch-specific) > > > b) AtomBIOS script interpreter (I think arch-specific) > > > c) AtomBIOS scripts (card-specific, but not arch-specific) > > > d) Data tables (card-specific, but not arch-specific) > > > > > > The AtomBIOS parts of the various drivers need data from c+d primarily, > > > and provide their own script interpreter, or not using the scripts, just > > > the data tables. > > Are you sure the X1900 Mac Edition ROM contains any ATOM data structures > > though? I rather doubt it. > That's what I'm trying to ascertain actually, because it directly > impacts what work needs to be done in the drivers. > > If it was me writing the ROMs in the first place (but it's not), from > what I understand of the ATOM, I'd have OpenFirmware versions of a+b, > and then could re-use c+d. > > The fact that both Nvidia and ATI OF-powered cards fail when trying to > access their expansion ROMs, I'm inclined to think there is something in > accessing them that we are missing, and that the ROMs must exist (the > sata_mv one existed and was accessible). There may well be bugs in the ROM access code on the PowerPC. I don't own the appropriate hardware nedded to check it out. I'm not sure that the code has been used on the PowerPC very much. People use it on the x86 all of the time so it is working fairly well there. But the generic PowerPC code seems to be working since you can read the sata_mv ROM. Did you check out the cards on x86 and ascertain that they have the standard PCI header in them? 55 AA All PCI ROMs are supposed to have that. If they are missing that the size code in the rom.c isn't going to work right. If these are OF ROM and you are booting on OF firmware, the ROM is getting run. In that case it may not be so simple to turn them back on if they have been hidden using a proprietary register. That's the quirk BenH has referred to. > > On actually accessing the rest of the ATI X1900 card, the avivotool from > git://people.freedesktop.org/~airlied/radeontool.git (avivo branch) can > actually access the rest of the rest of the card registers. > > -- > Robin Hugh Johnson > Gentoo Linux Developer & Infra Guy > E-Mail : [EMAIL PROTECTED] > GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85 > > ___ > Linuxppc-dev mailing list > Linuxppc-dev@ozlabs.org > https://ozlabs.org/mailman/listinfo/linuxppc-dev > > -- Jon Smirl [EMAIL PROTECTED] ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Revisited, audio codec device tree entries.
On 11/26/07, Timur Tabi <[EMAIL PROTECTED]> wrote: > David Gibson wrote: > > > 1) We have a "universal" device-tree-based fabric driver which > > parses all the above-described interconnection information in the > > device tree and handles any situation. Cool, but probably a lot of > > work and fiddly to get right. > > Definitely a lot of work. I suggest we wait until there are a few PowerPC > ASOC > v2 audio drivers in the kernel before we even consider this. And it may not > even be possible. I can easily imagine situations where we need > board-specific > code that belongs in a machine-specific fabric driver. I'm fixing up the asoc v2 code to use MODULE_DEVICE_TABLE() and the real kernel aliasing/insmod system. Half of why we are having trouble is because asoc isn't using this mechanism. I've posted patches fixing i2c to use the same mechanism. I don't have the asoc ones ready yet. > > -- > Timur Tabi > Linux kernel developer at Freescale > -- Jon Smirl [EMAIL PROTECTED] ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: sys_mpc83xx spi driver not probed
On Fri, Nov 23, 2007 at 07:02:23PM +0200, Joel Rouch wrote: > I have a custom 8349 ppc board. I have defined the spi master in the > configuration. > While booting my board, I driver is well added and linked to platform > bus, however I don't see that the probe entry point is reached. > I don't succeed to understand who is triggering the probe. Can someone > point me to the right link or explain me how to force it ? Are you calling of_platform_bus_probe() from your board file? -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Revisited, audio codec device tree entries.
Jon Smirl wrote: > I'm fixing up the asoc v2 code to use MODULE_DEVICE_TABLE() and the > real kernel aliasing/insmod system. Half of why we are having trouble > is because asoc isn't using this mechanism. I've posted patches fixing > i2c to use the same mechanism. I don't have the asoc ones ready yet. I look forward to porting my driver to ASoC V2 once the dust settles. :-) In the meantime, I'll post the V1 version this week or next. -- Timur Tabi Linux kernel developer at Freescale ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] powerpc: kill sparse warning in HPTE_V_COMPARE()
sparse warning: constant 0xff80 is so big it is unsigned long Signed-off-by: Geert Uytterhoeven <[EMAIL PROTECTED]> --- include/asm-powerpc/mmu-hash64.h |2 +- 1 files changed, 1 insertion(+), 1 deletion(-) --- a/include/asm-powerpc/mmu-hash64.h +++ b/include/asm-powerpc/mmu-hash64.h @@ -80,7 +80,7 @@ extern char initial_stab[]; #define HPTE_V_AVPN_SHIFT 7 #define HPTE_V_AVPNASM_CONST(0x3f80) #define HPTE_V_AVPN_VAL(x) (((x) & HPTE_V_AVPN) >> HPTE_V_AVPN_SHIFT) -#define HPTE_V_COMPARE(x,y)(!(((x) ^ (y)) & 0xff80)) +#define HPTE_V_COMPARE(x,y)(!(((x) ^ (y)) & 0xff80UL)) #define HPTE_V_BOLTED ASM_CONST(0x0010) #define HPTE_V_LOCKASM_CONST(0x0008) #define HPTE_V_LARGE ASM_CONST(0x0004) 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: [RFC/PATCHv3] powerpc: Move CPM command handling into the cpm drivers
Hi Scott, >> +spin_lock_irqsave(&cmd_lock, flags); > > I'm a little uneasy about this -- what's the longest it can take for the > CPM command to complete (or timeout)? I'd rather use a mutex, if we can > make sure that it's never called from atomic context. Unfortunately, fs_enet may call this from interrupt context. >> +EXPORT_SYMBOL_GPL(cpm_command); > > Can we please not play the GPL DRM game here? Arnd Bergmann proposed to change that, but you're right. This really is part of the CPM API, so i'll revert this. Thanks, Jochen ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: sys_mpc83xx spi driver not probed
Unfortunately not as I still need to use ARCH=ppc.
I am just using a platform_driver_probe() from the module_init.
static int __init mpc83xx_spi_init(void)
{
return platform_driver_probe(&mpc83xx_spi_driver, mpc83xx_spi_probe);
}
Thanks
Scott Wood wrote:
> On Fri, Nov 23, 2007 at 07:02:23PM +0200, Joel Rouch wrote:
>
>> I have a custom 8349 ppc board. I have defined the spi master in the
>> configuration.
>> While booting my board, I driver is well added and linked to platform
>> bus, however I don't see that the probe entry point is reached.
>> I don't succeed to understand who is triggering the probe. Can someone
>> point me to the right link or explain me how to force it ?
>>
>
> Are you calling of_platform_bus_probe() from your board file?
>
> -Scott
>
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[RFC/PATCHv4] powerpc: Move CPM command handling into the cpm drivers
This patch moves the CPM command handling into commproc.c
for CPM1 and cpm2_common.c. This is yet another preparation
to get rid of drivers accessing the CPM via the global cpmp.
Signed-off-by: Jochen Friedrich <[EMAIL PROTECTED]>
---
arch/powerpc/sysdev/commproc.c | 28
arch/powerpc/sysdev/cpm2_common.c | 25 +
drivers/net/fs_enet/mac-fcc.c | 10 +-
drivers/net/fs_enet/mac-scc.c | 11 +--
drivers/serial/cpm_uart/cpm_uart_cpm1.c |6 +-
drivers/serial/cpm_uart/cpm_uart_cpm2.c |8 +---
include/asm-powerpc/cpm.h |1 +
7 files changed, 58 insertions(+), 31 deletions(-)
diff --git a/arch/powerpc/sysdev/commproc.c b/arch/powerpc/sysdev/commproc.c
index f6a6378..7358a6f 100644
--- a/arch/powerpc/sysdev/commproc.c
+++ b/arch/powerpc/sysdev/commproc.c
@@ -240,6 +240,34 @@ void __init cpm_reset(void)
#endif
}
+static DEFINE_SPINLOCK(cmd_lock);
+
+#define MAX_CR_CMD_LOOPS1
+
+int cpm_command(u32 command, u8 opcode)
+{
+ int i, ret;
+ unsigned long flags;
+
+ if (command & 0xff0f)
+ return -EINVAL;
+
+ spin_lock_irqsave(&cmd_lock, flags);
+
+ ret = 0;
+ out_be16(&cpmp->cp_cpcr, command | CPM_CR_FLG | (opcode << 8));
+ for (i = 0; i < MAX_CR_CMD_LOOPS; i++)
+ if ((in_be16(&cpmp->cp_cpcr) & CPM_CR_FLG) == 0)
+ goto out;
+
+ printk(KERN_ERR "%s(): Not able to issue CPM command\n", __FUNCTION__);
+ ret = -EIO;
+out:
+ spin_unlock_irqrestore(&cmd_lock, flags);
+ return ret;
+}
+EXPORT_SYMBOL(cpm_command);
+
/* We used to do this earlier, but have to postpone as long as possible
* to ensure the kernel VM is now running.
*/
diff --git a/arch/powerpc/sysdev/cpm2_common.c
b/arch/powerpc/sysdev/cpm2_common.c
index 859362f..0a70545 100644
--- a/arch/powerpc/sysdev/cpm2_common.c
+++ b/arch/powerpc/sysdev/cpm2_common.c
@@ -83,6 +83,31 @@ cpm2_reset(void)
cpmp = &cpm2_immr->im_cpm;
}
+static DEFINE_SPINLOCK(cmd_lock);
+
+#define MAX_CR_CMD_LOOPS1
+
+int cpm_command(u32 command, u8 opcode)
+{
+ int i, ret;
+ unsigned long flags;
+
+ spin_lock_irqsave(&cmd_lock, flags);
+
+ ret = 0;
+ out_be32(&cpmp->cp_cpcr, command | opcode | CPM_CR_FLG);
+ for (i = 0; i < MAX_CR_CMD_LOOPS; i++)
+ if ((in_be32(&cpmp->cp_cpcr) & CPM_CR_FLG) == 0)
+ goto out;
+
+ printk(KERN_ERR "%s(): Not able to issue CPM command\n", __FUNCTION__);
+ ret = -EIO;
+out:
+ spin_unlock_irqrestore(&cmd_lock, flags);
+ return ret;
+}
+EXPORT_SYMBOL(cpm_command);
+
/* Set a baud rate generator. This needs lots of work. There are
* eight BRGs, which can be connected to the CPM channels or output
* as clocks. The BRGs are in two different block of internal
diff --git a/drivers/net/fs_enet/mac-fcc.c b/drivers/net/fs_enet/mac-fcc.c
index da4efbc..e363211 100644
--- a/drivers/net/fs_enet/mac-fcc.c
+++ b/drivers/net/fs_enet/mac-fcc.c
@@ -81,16 +81,8 @@
static inline int fcc_cr_cmd(struct fs_enet_private *fep, u32 op)
{
const struct fs_platform_info *fpi = fep->fpi;
- int i;
-
- W32(cpmp, cp_cpcr, fpi->cp_command | op | CPM_CR_FLG);
- for (i = 0; i < MAX_CR_CMD_LOOPS; i++)
- if ((R32(cpmp, cp_cpcr) & CPM_CR_FLG) == 0)
- return 0;
- printk(KERN_ERR "%s(): Not able to issue CPM command\n",
- __FUNCTION__);
- return 1;
+ return cpm_command(fpi->cp_command, op);
}
static int do_pd_setup(struct fs_enet_private *fep)
diff --git a/drivers/net/fs_enet/mac-scc.c b/drivers/net/fs_enet/mac-scc.c
index 03134f4..5ff856d 100644
--- a/drivers/net/fs_enet/mac-scc.c
+++ b/drivers/net/fs_enet/mac-scc.c
@@ -89,21 +89,12 @@
* Delay to wait for SCC reset command to complete (in us)
*/
#define SCC_RESET_DELAY50
-#define MAX_CR_CMD_LOOPS 1
static inline int scc_cr_cmd(struct fs_enet_private *fep, u32 op)
{
const struct fs_platform_info *fpi = fep->fpi;
- int i;
-
- W16(cpmp, cp_cpcr, fpi->cp_command | CPM_CR_FLG | (op << 8));
- for (i = 0; i < MAX_CR_CMD_LOOPS; i++)
- if ((R16(cpmp, cp_cpcr) & CPM_CR_FLG) == 0)
- return 0;
- printk(KERN_ERR "%s(): Not able to issue CPM command\n",
- __FUNCTION__);
- return 1;
+ return cpm_command(fpi->cp_command, op);
}
static int do_pd_setup(struct fs_enet_private *fep)
diff --git a/drivers/serial/cpm_uart/cpm_uart_cpm1.c
b/drivers/serial/cpm_uart/cpm_uart_cpm1.c
index 52fb044..6ea0366 100644
--- a/drivers/serial/cpm_uart/cpm_uart_cpm1.c
+++ b/drivers/serial/cpm_uart/cpm_uart_cpm1.c
@@ -52,11 +52,7 @@
#ifdef CONFIG_PPC_CPM_NEW_BINDING
void cpm_line_cr_cmd(struct uart_cpm_port *port, int cmd)
{
- u16 __iomem *cpcr = &cpmp->
Re: [RFC/PATCHv4] powerpc: Move CPM command handling into the cpm drivers
Jochen Friedrich wrote: > This patch moves the CPM command handling into commproc.c > for CPM1 and cpm2_common.c. This is yet another preparation > to get rid of drivers accessing the CPM via the global cpmp. > > Signed-off-by: Jochen Friedrich <[EMAIL PROTECTED]> Acked-by: Scott Wood <[EMAIL PROTECTED]> -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[patch 0/9] ps3av/fb patches for 2.6.25
Hi, Here is a first bunch of ps3av/fb patches for 2.6.25: [1] ps3av: ps3av_get_scanmode() and ps3av_get_refresh_rate() are unused [2] ps3: Use symbolic names for video modes [3] ps3fb: Kill PS3FB_FULL_MODE_BIT [4] ps3fb: Inline macros that are used only once [5] ps3fb: Kill ps3fb_res[] [6] ps3fb: Make frame buffer offset unsigned int [7] ps3fb: Configurable black borders [8] ps3fb: Reorganize modedb handling [9] ps3fb: Round up video modes Thanks for reviewing! 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 3/9] ps3fb: Kill PS3FB_FULL_MODE_BIT
From: Geert Uytterhoeven <[EMAIL PROTECTED]>
ps3fb: Kill PS3FB_FULL_MODE_BIT, use PS3AV_MODE_FULL instead
Signed-off-by: Geert Uytterhoeven <[EMAIL PROTECTED]>
---
drivers/video/ps3fb.c |8 +++-
1 files changed, 3 insertions(+), 5 deletions(-)
--- a/drivers/video/ps3fb.c
+++ b/drivers/video/ps3fb.c
@@ -56,8 +56,6 @@
#define GPU_ALIGN_UP(x)_ALIGN_UP((x), 64)
#define GPU_MAX_LINE_LENGTH(65536 - 64)
-#define PS3FB_FULL_MODE_BIT0x80
-
#define GPU_INTR_STATUS_VSYNC_00 /* vsync on
head A */
#define GPU_INTR_STATUS_VSYNC_11 /* vsync on
head B */
#define GPU_INTR_STATUS_FLIP_0 3 /* flip head A */
@@ -309,7 +307,7 @@ static int ps3fb_get_res_table(u32 xres,
unsigned int i;
u32 x, y, f;
- full_mode = (mode & PS3FB_FULL_MODE_BIT) ? PS3FB_RES_FULL : 0;
+ full_mode = (mode & PS3AV_MODE_FULL) ? PS3FB_RES_FULL : 0;
for (i = 0;; i++) {
x = ps3fb_res[i].xres;
y = ps3fb_res[i].yres;
@@ -372,7 +370,7 @@ found:
/* Full broadcast modes have the full mode bit set */
mode = i+1;
if (mode > PS3AV_MODE_WUXGA)
- mode = (mode - PS3AV_MODE_WUXGA) | PS3FB_FULL_MODE_BIT;
+ mode = (mode - PS3AV_MODE_WUXGA) | PS3AV_MODE_FULL;
pr_debug("ps3fb_find_mode: mode %u\n", mode);
@@ -389,7 +387,7 @@ static const struct fb_videomode *ps3fb_
flags = id & ~PS3AV_MODE_MASK;
- if (mode <= PS3AV_MODE_1080P50 && flags & PS3FB_FULL_MODE_BIT) {
+ if (mode <= PS3AV_MODE_1080P50 && flags & PS3AV_MODE_FULL) {
/* Full broadcast mode */
return &ps3fb_modedb[mode + PS3AV_MODE_WUXGA - 1];
}
--
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/9] ps3av: ps3av_get_scanmode() and ps3av_get_refresh_rate() are unused
From: Geert Uytterhoeven <[EMAIL PROTECTED]>
ps3av: ps3av_get_scanmode() and ps3av_get_refresh_rate() are unused, so remove
them
Signed-off-by: Geert Uytterhoeven <[EMAIL PROTECTED]>
---
drivers/ps3/ps3av.c | 58 +---
include/asm-powerpc/ps3av.h |2 -
2 files changed, 13 insertions(+), 47 deletions(-)
--- a/drivers/ps3/ps3av.c
+++ b/drivers/ps3/ps3av.c
@@ -78,23 +78,21 @@ static const struct avset_video_mode {
u32 aspect;
u32 x;
u32 y;
- u32 interlace;
- u32 freq;
} video_mode_table[] = {
{ 0, }, /* auto */
- {YUV444, XRGB, PS3AV_CMD_VIDEO_VID_480I, A_N, 720, 480, 1, 60},
- {YUV444, XRGB, PS3AV_CMD_VIDEO_VID_480P, A_N, 720, 480, 0, 60},
- {YUV444, XRGB, PS3AV_CMD_VIDEO_VID_720P_60HZ, A_N, 1280, 720, 0, 60},
- {YUV444, XRGB, PS3AV_CMD_VIDEO_VID_1080I_60HZ, A_W, 1920, 1080, 1, 60},
- {YUV444, XRGB, PS3AV_CMD_VIDEO_VID_1080P_60HZ, A_W, 1920, 1080, 0, 60},
- {YUV444, XRGB, PS3AV_CMD_VIDEO_VID_576I, A_N, 720, 576, 1, 50},
- {YUV444, XRGB, PS3AV_CMD_VIDEO_VID_576P, A_N, 720, 576, 0, 50},
- {YUV444, XRGB, PS3AV_CMD_VIDEO_VID_720P_50HZ, A_N, 1280, 720, 0, 50},
- {YUV444, XRGB, PS3AV_CMD_VIDEO_VID_1080I_50HZ, A_W, 1920, 1080, 1, 50},
- {YUV444, XRGB, PS3AV_CMD_VIDEO_VID_1080P_50HZ, A_W, 1920, 1080, 0, 50},
- { RGB8, XRGB, PS3AV_CMD_VIDEO_VID_WXGA, A_W, 1280, 768, 0, 60},
- { RGB8, XRGB, PS3AV_CMD_VIDEO_VID_SXGA, A_N, 1280, 1024, 0, 60},
- { RGB8, XRGB, PS3AV_CMD_VIDEO_VID_WUXGA, A_W, 1920, 1200, 0, 60},
+ {YUV444, XRGB, PS3AV_CMD_VIDEO_VID_480I, A_N, 720, 480},
+ {YUV444, XRGB, PS3AV_CMD_VIDEO_VID_480P, A_N, 720, 480},
+ {YUV444, XRGB, PS3AV_CMD_VIDEO_VID_720P_60HZ, A_N, 1280, 720},
+ {YUV444, XRGB, PS3AV_CMD_VIDEO_VID_1080I_60HZ, A_W, 1920, 1080},
+ {YUV444, XRGB, PS3AV_CMD_VIDEO_VID_1080P_60HZ, A_W, 1920, 1080},
+ {YUV444, XRGB, PS3AV_CMD_VIDEO_VID_576I, A_N, 720, 576},
+ {YUV444, XRGB, PS3AV_CMD_VIDEO_VID_576P, A_N, 720, 576},
+ {YUV444, XRGB, PS3AV_CMD_VIDEO_VID_720P_50HZ, A_N, 1280, 720},
+ {YUV444, XRGB, PS3AV_CMD_VIDEO_VID_1080I_50HZ, A_W, 1920, 1080},
+ {YUV444, XRGB, PS3AV_CMD_VIDEO_VID_1080P_50HZ, A_W, 1920, 1080},
+ { RGB8, XRGB, PS3AV_CMD_VIDEO_VID_WXGA, A_W, 1280, 768},
+ { RGB8, XRGB, PS3AV_CMD_VIDEO_VID_SXGA, A_N, 1280, 1024},
+ { RGB8, XRGB, PS3AV_CMD_VIDEO_VID_WUXGA, A_W, 1920, 1200},
};
/* supported CIDs */
@@ -889,36 +887,6 @@ int ps3av_get_mode(void)
EXPORT_SYMBOL_GPL(ps3av_get_mode);
-int ps3av_get_scanmode(int id)
-{
- int size;
-
- id = id & PS3AV_MODE_MASK;
- size = ARRAY_SIZE(video_mode_table);
- if (id > size - 1 || id < 0) {
- printk(KERN_ERR "%s: invalid mode %d\n", __func__, id);
- return -EINVAL;
- }
- return video_mode_table[id].interlace;
-}
-
-EXPORT_SYMBOL_GPL(ps3av_get_scanmode);
-
-int ps3av_get_refresh_rate(int id)
-{
- int size;
-
- id = id & PS3AV_MODE_MASK;
- size = ARRAY_SIZE(video_mode_table);
- if (id > size - 1 || id < 0) {
- printk(KERN_ERR "%s: invalid mode %d\n", __func__, id);
- return -EINVAL;
- }
- return video_mode_table[id].freq;
-}
-
-EXPORT_SYMBOL_GPL(ps3av_get_refresh_rate);
-
/* get resolution by video_mode */
int ps3av_video_mode2res(u32 id, u32 *xres, u32 *yres)
{
--- a/include/asm-powerpc/ps3av.h
+++ b/include/asm-powerpc/ps3av.h
@@ -713,8 +713,6 @@ extern int ps3av_set_video_mode(u32);
extern int ps3av_set_audio_mode(u32, u32, u32, u32, u32);
extern int ps3av_get_auto_mode(void);
extern int ps3av_get_mode(void);
-extern int ps3av_get_scanmode(int);
-extern int ps3av_get_refresh_rate(int);
extern int ps3av_video_mode2res(u32, u32 *, u32 *);
extern int ps3av_video_mute(int);
extern int ps3av_audio_mute(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 4/9] ps3fb: Inline macros that are used only once
From: Geert Uytterhoeven <[EMAIL PROTECTED]> ps3fb: inline the X_OFF(), Y_OFF(), WIDTH(), HEIGHT(), and VP_OFF() macros, as they're used in one place only Signed-off-by: Geert Uytterhoeven <[EMAIL PROTECTED]> --- drivers/video/ps3fb.c | 12 1 files changed, 4 insertions(+), 8 deletions(-) --- a/drivers/video/ps3fb.c +++ b/drivers/video/ps3fb.c @@ -286,15 +286,8 @@ static const struct fb_videomode ps3fb_m #define HEAD_A #define HEAD_B -#define X_OFF(i) (ps3fb_res[i].xoff) /* left/right margin (pixel) */ -#define Y_OFF(i) (ps3fb_res[i].yoff) /* top/bottom margin (pixel) */ -#define WIDTH(i) (ps3fb_res[i].xres) /* width of FB */ -#define HEIGHT(i) (ps3fb_res[i].yres) /* height of FB */ #define BPP4 /* number of bytes per pixel */ -/* Start of the virtual frame buffer (relative to fullscreen ) */ -#define VP_OFF(i) ((WIDTH(i) * Y_OFF(i) + X_OFF(i)) * BPP) - static int ps3fb_mode; module_param(ps3fb_mode, int, 0); @@ -609,7 +602,10 @@ static int ps3fb_set_par(struct fb_info par->width = info->var.xres; par->height = info->var.yres; - offset = VP_OFF(i); + + /* Start of the virtual frame buffer (relative to fullscreen) */ + offset = ps3fb_res[i].yoff * ddr_line_length + ps3fb_res[i].xoff * BPP; + par->fb_offset = GPU_ALIGN_UP(offset); par->full_offset = par->fb_offset - offset; par->pan_offset = info->var.yoffset * xdr_line_length + -- 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/9] ps3: Use symbolic names for video modes
From: Geert Uytterhoeven <[EMAIL PROTECTED]>
ps3: Use symbolic names for video modes
Signed-off-by: Geert Uytterhoeven <[EMAIL PROTECTED]>
---
drivers/ps3/ps3av.c | 39 ---
drivers/video/ps3fb.c | 17 ++---
include/asm-powerpc/ps3av.h | 41 ++---
3 files changed, 60 insertions(+), 37 deletions(-)
--- a/drivers/ps3/ps3av.c
+++ b/drivers/ps3/ps3av.c
@@ -542,7 +542,7 @@ static void ps3av_set_videomode_packet(u
static void ps3av_set_videomode_cont(u32 id, u32 old_id)
{
- static int vesa = 0;
+ static int vesa;
int res;
/* video signal off */
@@ -552,9 +552,9 @@ static void ps3av_set_videomode_cont(u32
* AV backend needs non-VESA mode setting at least one time
* when VESA mode is used.
*/
- if (vesa == 0 && (id & PS3AV_MODE_MASK) >= 11) {
+ if (vesa == 0 && (id & PS3AV_MODE_MASK) >= PS3AV_MODE_WXGA) {
/* vesa mode */
- ps3av_set_videomode_packet(2); /* 480P */
+ ps3av_set_videomode_packet(PS3AV_MODE_480P);
}
vesa = 1;
@@ -594,20 +594,21 @@ static const struct {
unsigned mask : 19;
unsigned id : 4;
} ps3av_preferred_modes[] = {
- { .mask = PS3AV_RESBIT_WUXGA<< SHIFT_VESA, .id = 13 },
- { .mask = PS3AV_RESBIT_1920x1080P << SHIFT_60,.id = 5 },
- { .mask = PS3AV_RESBIT_1920x1080P << SHIFT_50,.id = 10 },
- { .mask = PS3AV_RESBIT_1920x1080I << SHIFT_60,.id = 4 },
- { .mask = PS3AV_RESBIT_1920x1080I << SHIFT_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 },
+ { PS3AV_RESBIT_WUXGA << SHIFT_VESA, PS3AV_MODE_WUXGA },
+ { PS3AV_RESBIT_1920x1080P << SHIFT_60, PS3AV_MODE_1080P60 },
+ { PS3AV_RESBIT_1920x1080P << SHIFT_50, PS3AV_MODE_1080P50 },
+ { PS3AV_RESBIT_1920x1080I << SHIFT_60, PS3AV_MODE_1080I60 },
+ { PS3AV_RESBIT_1920x1080I << SHIFT_50, PS3AV_MODE_1080I50 },
+ { PS3AV_RESBIT_SXGA << SHIFT_VESA, PS3AV_MODE_SXGA},
+ { PS3AV_RESBIT_WXGA << SHIFT_VESA, PS3AV_MODE_WXGA},
+ { PS3AV_RESBIT_1280x720P << SHIFT_60, PS3AV_MODE_720P60 },
+ { PS3AV_RESBIT_1280x720P << SHIFT_50, PS3AV_MODE_720P50 },
+ { PS3AV_RESBIT_720x480P << SHIFT_60, PS3AV_MODE_480P},
+ { PS3AV_RESBIT_720x576P << SHIFT_50, PS3AV_MODE_576P},
};
-static int ps3av_resbit2id(u32 res_50, u32 res_60, u32 res_vesa)
+static enum ps3av_mode_num ps3av_resbit2id(u32 res_50, u32 res_60,
+ u32 res_vesa)
{
unsigned int i;
u32 res_all;
@@ -636,9 +637,9 @@ static int ps3av_resbit2id(u32 res_50, u
return 0;
}
-static int ps3av_hdmi_get_id(struct ps3av_info_monitor *info)
+static enum ps3av_mode_num ps3av_hdmi_get_id(struct ps3av_info_monitor *info)
{
- int id;
+ enum ps3av_mode_num id;
if (safe_mode)
return PS3AV_DEFAULT_HDMI_MODE_ID_REG_60;
@@ -852,7 +853,7 @@ int ps3av_set_video_mode(u32 id)
/* auto mode */
option = id & ~PS3AV_MODE_MASK;
- if ((id & PS3AV_MODE_MASK) == 0) {
+ if ((id & PS3AV_MODE_MASK) == PS3AV_MODE_AUTO) {
id = ps3av_auto_videomode(&ps3av->av_hw_conf);
if (id < 1) {
printk(KERN_ERR "%s: invalid id :%d\n", __func__, id);
@@ -958,7 +959,7 @@ static int ps3av_probe(struct ps3_system
return -ENOMEM;
mutex_init(&ps3av->mutex);
- ps3av->ps3av_mode = 0;
+ ps3av->ps3av_mode = PS3AV_MODE_AUTO;
ps3av->dev = dev;
INIT_WORK(&ps3av->work, ps3avd);
--- a/drivers/video/ps3fb.c
+++ b/drivers/video/ps3fb.c
@@ -337,7 +337,7 @@ static int ps3fb_get_res_table(u32 xres,
static unsigned int ps3fb_find_mode(const struct fb_var_screeninfo *var,
u32 *ddr_line_length, u32 *xdr_line_length)
{
- unsigned int i, mode;
+ unsigned int i, fi, mode;
for (i = 0; i < ARRAY_SIZE(ps3fb_modedb); i++)
if (var->xres == ps3fb_modedb[i].xres &&
@@ -358,7 +358,8 @@ static unsigned int ps3fb_find_mode(cons
found:
/* Cropped broadcast modes use the full line length */
- *ddr_line_length = ps3fb_modedb[i < 10 ? i + 13 : i].xres * BPP;
+ fi = i < PS3AV_MODE_1080P50 ? i + PS3AV_MODE_WUXGA : i;
+ *ddr_line_length = ps3fb_modedb[fi].xres * BPP;
if (ps3_compare_firmware_vers
[patch 6/9] ps3fb: Make frame buffer offset unsigned int
From: Geert Uytterhoeven <[EMAIL PROTECTED]>
ps3fb: Frame buffer offsets don't have to be `unsigned long', `unsigned int' is
sufficient
Signed-off-by: Geert Uytterhoeven <[EMAIL PROTECTED]>
---
drivers/video/ps3fb.c |9 -
1 files changed, 4 insertions(+), 5 deletions(-)
--- a/drivers/video/ps3fb.c
+++ b/drivers/video/ps3fb.c
@@ -139,9 +139,9 @@ struct ps3fb_par {
unsigned int ddr_line_length;
unsigned int ddr_frame_size;
unsigned int xdr_frame_size;
- unsigned long full_offset; /* start of fullscreen DDR fb */
- unsigned long fb_offset;/* start of actual DDR fb */
- unsigned long pan_offset;
+ unsigned int full_offset; /* start of fullscreen DDR fb */
+ unsigned int fb_offset; /* start of actual DDR fb */
+ unsigned int pan_offset;
};
@@ -510,8 +510,7 @@ static int ps3fb_set_par(struct fb_info
{
struct ps3fb_par *par = info->par;
unsigned int mode, ddr_line_length, xdr_line_length, lines, maxlines;
- unsigned int ddr_xoff, ddr_yoff;
- unsigned long offset;
+ unsigned int ddr_xoff, ddr_yoff, offset;
const struct fb_videomode *vmode;
u64 dst;
--
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 9/9] ps3fb: Round up video modes
From: Geert Uytterhoeven <[EMAIL PROTECTED]>
ps3fb: Round up arbitrary video modes until they fit (if possible)
Signed-off-by: Geert Uytterhoeven <[EMAIL PROTECTED]>
---
drivers/video/ps3fb.c | 160 +++---
1 files changed, 114 insertions(+), 46 deletions(-)
--- a/drivers/video/ps3fb.c
+++ b/drivers/video/ps3fb.c
@@ -275,29 +275,49 @@ static char *mode_option __devinitdata;
static int ps3fb_cmp_mode(const struct fb_videomode *vmode,
const struct fb_var_screeninfo *var)
{
- /* resolution + black border must match a native resolution */
- if (vmode->left_margin + vmode->xres + vmode->right_margin !=
- var->left_margin + var->xres + var->right_margin ||
- vmode->upper_margin + vmode->yres + vmode->lower_margin !=
- var->upper_margin + var->yres + var->lower_margin)
+ long xres, yres, left_margin, right_margin, upper_margin, lower_margin;
+ long dx, dy;
+
+ /* maximum values */
+ if (var->xres > vmode->xres || var->yres > vmode->yres ||
+ var->pixclock > vmode->pixclock ||
+ var->hsync_len > vmode->hsync_len ||
+ var->vsync_len > vmode->vsync_len)
return -1;
- /* minimum limits for margins */
- if (vmode->left_margin > var->left_margin ||
- vmode->right_margin > var->right_margin ||
- vmode->upper_margin > var->upper_margin ||
- vmode->lower_margin > var->lower_margin)
+ /* progressive/interlaced must match */
+ if ((var->vmode & FB_VMODE_MASK) != vmode->vmode)
return -1;
- /* these fields must match exactly */
- if (vmode->pixclock != var->pixclock ||
- vmode->hsync_len != var->hsync_len ||
- vmode->vsync_len != var->vsync_len ||
- vmode->sync != var->sync ||
- vmode->vmode != (var->vmode & FB_VMODE_MASK))
+ /* minimum resolution */
+ xres = max(var->xres, 1U);
+ yres = max(var->yres, 1U);
+
+ /* minimum margins */
+ left_margin = max(var->left_margin, vmode->left_margin);
+ right_margin = max(var->right_margin, vmode->right_margin);
+ upper_margin = max(var->upper_margin, vmode->upper_margin);
+ lower_margin = max(var->lower_margin, vmode->lower_margin);
+
+ /* resolution + margins may not exceed native parameters */
+ dx = ((long)vmode->left_margin + (long)vmode->xres +
+ (long)vmode->right_margin) -
+(left_margin + xres + right_margin);
+ if (dx < 0)
return -1;
- return 0;
+ dy = ((long)vmode->upper_margin + (long)vmode->yres +
+ (long)vmode->lower_margin) -
+(upper_margin + yres + lower_margin);
+ if (dy < 0)
+ return -1;
+
+ /* exact match */
+ if (!dx && !dy)
+ return 0;
+
+ /* resolution difference */
+ return (vmode->xres - xres) * (vmode->yres - yres);
}
static const struct fb_videomode *ps3fb_native_vmode(enum ps3av_mode_num id)
@@ -323,33 +343,96 @@ static const struct fb_videomode *ps3fb_
static unsigned int ps3fb_find_mode(struct fb_var_screeninfo *var,
u32 *ddr_line_length, u32 *xdr_line_length)
{
- unsigned int id;
+ unsigned int id, best_id;
+ int diff, best_diff;
const struct fb_videomode *vmode;
+ long gap;
+ best_id = 0;
+ best_diff = INT_MAX;
+ pr_debug("%s: wanted %u [%u] %u x %u [%u] %u\n", __func__,
+var->left_margin, var->xres, var->right_margin,
+var->upper_margin, var->yres, var->lower_margin);
for (id = PS3AV_MODE_480I; id <= PS3AV_MODE_WUXGA; id++) {
vmode = ps3fb_native_vmode(id);
- if (!ps3fb_cmp_mode(vmode, var))
- goto found;
+ diff = ps3fb_cmp_mode(vmode, var);
+ pr_debug("%s: mode %u: %u [%u] %u x %u [%u] %u: diff = %d\n",
+__func__, id, vmode->left_margin, vmode->xres,
+vmode->right_margin, vmode->upper_margin,
+vmode->yres, vmode->lower_margin, diff);
+ if (diff < 0)
+ continue;
+ if (diff < best_diff) {
+ best_id = id;
+ if (!diff)
+ break;
+ best_diff = diff;
+ }
}
- pr_debug("%s: mode not found\n", __func__);
- return 0;
+ if (!best_id) {
+ pr_debug("%s: no suitable mode found\n", __func__);
+ return 0;
+ }
+
+ id = best_id;
+ vmode = ps3fb_native_vmode(id);
-found:
*ddr_line_length = vmode->xres * BPP;
- if (!var->xres) {
+ /* minimum resolution */
+ if (!var->xres)
var->xres = 1;
- var->right_m
[patch 7/9] ps3fb: Configurable black borders
From: Geert Uytterhoeven <[EMAIL PROTECTED]>
ps3fb: Allow all video modes where the visible resolution plus the black
borders matches a native resolution
Signed-off-by: Geert Uytterhoeven <[EMAIL PROTECTED]>
--
drivers/video/ps3fb.c | 69 +++---
1 files changed, 49 insertions(+), 20 deletions(-)
--- a/drivers/video/ps3fb.c
+++ b/drivers/video/ps3fb.c
@@ -269,32 +269,57 @@ module_param(ps3fb_mode, int, 0);
static char *mode_option __devinitdata;
-static unsigned int ps3fb_find_mode(const struct fb_var_screeninfo *var,
+static int ps3fb_cmp_mode(const struct fb_videomode *vmode,
+ const struct fb_var_screeninfo *var)
+{
+ /* resolution + black border must match a native resolution */
+ if (vmode->left_margin + vmode->xres + vmode->right_margin !=
+ var->left_margin + var->xres + var->right_margin ||
+ vmode->upper_margin + vmode->yres + vmode->lower_margin !=
+ var->upper_margin + var->yres + var->lower_margin)
+ return -1;
+
+ /* minimum limits for margins */
+ if (vmode->left_margin > var->left_margin ||
+ vmode->right_margin > var->right_margin ||
+ vmode->upper_margin > var->upper_margin ||
+ vmode->lower_margin > var->lower_margin)
+ return -1;
+
+ /* these fields must match exactly */
+ if (vmode->pixclock != var->pixclock ||
+ vmode->hsync_len != var->hsync_len ||
+ vmode->vsync_len != var->vsync_len ||
+ vmode->sync != var->sync ||
+ vmode->vmode != (var->vmode & FB_VMODE_MASK))
+ return -1;
+
+ return 0;
+}
+
+static unsigned int ps3fb_find_mode(struct fb_var_screeninfo *var,
u32 *ddr_line_length, u32 *xdr_line_length)
{
- unsigned int i, fi, mode;
+ unsigned int i, mode;
- for (i = 0; i < ARRAY_SIZE(ps3fb_modedb); i++)
- if (var->xres == ps3fb_modedb[i].xres &&
- var->yres == ps3fb_modedb[i].yres &&
- var->pixclock == ps3fb_modedb[i].pixclock &&
- var->hsync_len == ps3fb_modedb[i].hsync_len &&
- var->vsync_len == ps3fb_modedb[i].vsync_len &&
- var->left_margin == ps3fb_modedb[i].left_margin &&
- var->right_margin == ps3fb_modedb[i].right_margin &&
- var->upper_margin == ps3fb_modedb[i].upper_margin &&
- var->lower_margin == ps3fb_modedb[i].lower_margin &&
- var->sync == ps3fb_modedb[i].sync &&
- (var->vmode & FB_VMODE_MASK) == ps3fb_modedb[i].vmode)
+ for (i = PS3AV_MODE_1080P50; i < ARRAY_SIZE(ps3fb_modedb); i++)
+ if (!ps3fb_cmp_mode(&ps3fb_modedb[i], var))
goto found;
pr_debug("ps3fb_find_mode: mode not found\n");
return 0;
found:
- /* Cropped broadcast modes use the full line length */
- fi = i < PS3AV_MODE_1080P50 ? i + PS3AV_MODE_WUXGA : i;
- *ddr_line_length = ps3fb_modedb[fi].xres * BPP;
+ *ddr_line_length = ps3fb_modedb[i].xres * BPP;
+
+ if (!var->xres) {
+ var->xres = 1;
+ var->right_margin--;
+ }
+ if (!var->yres) {
+ var->yres = 1;
+ var->lower_margin--;
+ }
if (ps3_compare_firmware_version(1, 9, 0) >= 0) {
*xdr_line_length = GPU_ALIGN_UP(max(var->xres,
@@ -304,10 +329,14 @@ found:
} else
*xdr_line_length = *ddr_line_length;
- /* Full broadcast modes have the full mode bit set */
mode = i+1;
- if (mode > PS3AV_MODE_WUXGA)
- mode = (mode - PS3AV_MODE_WUXGA) | PS3AV_MODE_FULL;
+ if (mode > PS3AV_MODE_WUXGA) {
+ mode -= PS3AV_MODE_WUXGA;
+ /* Full broadcast modes have the full mode bit set */
+ if (ps3fb_modedb[i].xres == var->xres &&
+ ps3fb_modedb[i].yres == var->yres)
+ mode |= PS3AV_MODE_FULL;
+ }
pr_debug("ps3fb_find_mode: mode %u\n", mode);
--
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 8/9] ps3fb: Reorganize modedb handling
From: Geert Uytterhoeven <[EMAIL PROTECTED]>
ps3fb: Reorganize modedb handling:
- Reorder the video modes in ps3fb_modedb, for easier indexing using
PS3AV_MODE_* numbers,
- Introduce ps3fb_native_vmode(), to convert from native (PS3AV_MODE_*) mode
numbers to struct fb_videomode *,
- Rename and move ps3fb_default_mode() to ps3fb_vmode().
Signed-off-by: Geert Uytterhoeven <[EMAIL PROTECTED]>
---
drivers/video/ps3fb.c | 116 +-
1 files changed, 60 insertions(+), 56 deletions(-)
--- a/drivers/video/ps3fb.c
+++ b/drivers/video/ps3fb.c
@@ -145,6 +145,8 @@ struct ps3fb_par {
};
+#define FIRST_NATIVE_MODE_INDEX10
+
static const struct fb_videomode ps3fb_modedb[] = {
/* 60 Hz broadcast modes (modes "1" to "5") */
{
@@ -192,24 +194,7 @@ static const struct fb_videomode ps3fb_m
FB_SYNC_BROADCAST, FB_VMODE_NONINTERLACED
},
-/* VESA modes (modes "11" to "13") */
-{
- /* WXGA */
- "wxga", 60, 1280, 768, 12924, 160, 24, 29, 3, 136, 6,
- 0, FB_VMODE_NONINTERLACED,
- FB_MODE_IS_VESA
-}, {
- /* SXGA */
- "sxga", 60, 1280, 1024, 9259, 248, 48, 38, 1, 112, 3,
- FB_SYNC_HOR_HIGH_ACT | FB_SYNC_VERT_HIGH_ACT, FB_VMODE_NONINTERLACED,
- FB_MODE_IS_VESA
-}, {
- /* WUXGA */
- "wuxga", 60, 1920, 1200, 6494, 80, 48, 26, 3, 32, 6,
- FB_SYNC_HOR_HIGH_ACT, FB_VMODE_NONINTERLACED,
- FB_MODE_IS_VESA
-},
-
+[FIRST_NATIVE_MODE_INDEX] =
/* 60 Hz broadcast modes (full resolution versions of modes "1" to "5") */
{
/* 480if */
@@ -254,6 +239,24 @@ static const struct fb_videomode ps3fb_m
/* 1080pf */
"1080pf", 50, 1920, 1080, 6734, 148, 484, 36, 4, 88, 5,
FB_SYNC_BROADCAST, FB_VMODE_NONINTERLACED
+},
+
+/* VESA modes (modes "11" to "13") */
+{
+ /* WXGA */
+ "wxga", 60, 1280, 768, 12924, 160, 24, 29, 3, 136, 6,
+ 0, FB_VMODE_NONINTERLACED,
+ FB_MODE_IS_VESA
+}, {
+ /* SXGA */
+ "sxga", 60, 1280, 1024, 9259, 248, 48, 38, 1, 112, 3,
+ FB_SYNC_HOR_HIGH_ACT | FB_SYNC_VERT_HIGH_ACT, FB_VMODE_NONINTERLACED,
+ FB_MODE_IS_VESA
+}, {
+ /* WUXGA */
+ "wuxga", 60, 1920, 1200, 6494, 80, 48, 26, 3, 32, 6,
+ FB_SYNC_HOR_HIGH_ACT, FB_VMODE_NONINTERLACED,
+ FB_MODE_IS_VESA
}
};
@@ -297,20 +300,43 @@ static int ps3fb_cmp_mode(const struct f
return 0;
}
+static const struct fb_videomode *ps3fb_native_vmode(enum ps3av_mode_num id)
+{
+ return &ps3fb_modedb[FIRST_NATIVE_MODE_INDEX + id - 1];
+}
+
+static const struct fb_videomode *ps3fb_vmode(int id)
+{
+ u32 mode = id & PS3AV_MODE_MASK;
+
+ if (mode < PS3AV_MODE_480I || mode > PS3AV_MODE_WUXGA)
+ return NULL;
+
+ if (mode <= PS3AV_MODE_1080P50 && !(id & PS3AV_MODE_FULL)) {
+ /* Non-fullscreen broadcast mode */
+ return &ps3fb_modedb[mode - 1];
+ }
+
+ return ps3fb_native_vmode(mode);
+}
+
static unsigned int ps3fb_find_mode(struct fb_var_screeninfo *var,
u32 *ddr_line_length, u32 *xdr_line_length)
{
- unsigned int i, mode;
+ unsigned int id;
+ const struct fb_videomode *vmode;
- for (i = PS3AV_MODE_1080P50; i < ARRAY_SIZE(ps3fb_modedb); i++)
- if (!ps3fb_cmp_mode(&ps3fb_modedb[i], var))
+ for (id = PS3AV_MODE_480I; id <= PS3AV_MODE_WUXGA; id++) {
+ vmode = ps3fb_native_vmode(id);
+ if (!ps3fb_cmp_mode(vmode, var))
goto found;
+ }
- pr_debug("ps3fb_find_mode: mode not found\n");
+ pr_debug("%s: mode not found\n", __func__);
return 0;
found:
- *ddr_line_length = ps3fb_modedb[i].xres * BPP;
+ *ddr_line_length = vmode->xres * BPP;
if (!var->xres) {
var->xres = 1;
@@ -329,36 +355,14 @@ found:
} else
*xdr_line_length = *ddr_line_length;
- mode = i+1;
- if (mode > PS3AV_MODE_WUXGA) {
- mode -= PS3AV_MODE_WUXGA;
+ if (vmode->sync & FB_SYNC_BROADCAST) {
/* Full broadcast modes have the full mode bit set */
- if (ps3fb_modedb[i].xres == var->xres &&
- ps3fb_modedb[i].yres == var->yres)
- mode |= PS3AV_MODE_FULL;
- }
-
- pr_debug("ps3fb_find_mode: mode %u\n", mode);
-
- return mode;
-}
-
-static const struct fb_videomode *ps3fb_default_mode(int id)
-{
- u32 mode = id & PS3AV_MODE_MASK;
- u32 flags;
-
- if (mode < PS3AV_MODE_480I || mode > PS3AV_MODE_WUXGA)
- return NULL;
-
- flags = id & ~PS3AV_MODE_MASK;
-
- if (mode <= PS3AV_MODE_1080P50 && flags & PS3AV_MODE_FULL) {
- /* Full broadcast mode */
- return &ps3fb_modedb[mode + PS3AV_MODE_WUXGA - 1];
+ if (vmode->xres == v
[patch 5/9] ps3fb: Kill ps3fb_res
From: Geert Uytterhoeven <[EMAIL PROTECTED]>
ps3fb: kill ps3fb_res[], as all information it contains can be obtained in
some other way.
Signed-off-by: Geert Uytterhoeven <[EMAIL PROTECTED]>
---
drivers/video/ps3fb.c | 108 ++
1 files changed, 22 insertions(+), 86 deletions(-)
--- a/drivers/video/ps3fb.c
+++ b/drivers/video/ps3fb.c
@@ -133,42 +133,17 @@ static struct ps3fb_priv ps3fb;
struct ps3fb_par {
u32 pseudo_palette[16];
int mode_id, new_mode_id;
- int res_index;
unsigned int num_frames;/* num of frame buffers */
unsigned int width;
unsigned int height;
+ unsigned int ddr_line_length;
+ unsigned int ddr_frame_size;
+ unsigned int xdr_frame_size;
unsigned long full_offset; /* start of fullscreen DDR fb */
unsigned long fb_offset;/* start of actual DDR fb */
unsigned long pan_offset;
};
-struct ps3fb_res_table {
- u32 xres;
- u32 yres;
- u32 xoff;
- u32 yoff;
- u32 type;
-};
-#define PS3FB_RES_FULL 1
-static const struct ps3fb_res_table ps3fb_res[] = {
- /* res_x,y margin_x,y full */
- { 720, 480, 72, 48 , 0},
- { 720, 576, 72, 58 , 0},
- { 1280, 720, 78, 38 , 0},
- { 1920, 1080, 116, 58 , 0},
- /* full mode */
- { 720, 480, 0, 0 , PS3FB_RES_FULL},
- { 720, 576, 0, 0 , PS3FB_RES_FULL},
- { 1280, 720, 0, 0 , PS3FB_RES_FULL},
- { 1920, 1080, 0, 0 , PS3FB_RES_FULL},
- /* vesa: normally full mode */
- { 1280, 768, 0, 0 , 0},
- { 1280, 1024, 0, 0 , 0},
- { 1920, 1200, 0, 0 , 0},
- {0,0, 0, 0 , 0} };
-
-/* default resolution */
-#define GPU_RES_INDEX 0 /* 720 x 480 */
static const struct fb_videomode ps3fb_modedb[] = {
/* 60 Hz broadcast modes (modes "1" to "5") */
@@ -294,37 +269,6 @@ module_param(ps3fb_mode, int, 0);
static char *mode_option __devinitdata;
-static int ps3fb_get_res_table(u32 xres, u32 yres, int mode)
-{
- int full_mode;
- unsigned int i;
- u32 x, y, f;
-
- full_mode = (mode & PS3AV_MODE_FULL) ? PS3FB_RES_FULL : 0;
- for (i = 0;; i++) {
- x = ps3fb_res[i].xres;
- y = ps3fb_res[i].yres;
- f = ps3fb_res[i].type;
-
- if (!x) {
- pr_debug("ERROR: ps3fb_get_res_table()\n");
- return -1;
- }
-
- if (full_mode == PS3FB_RES_FULL && f != PS3FB_RES_FULL)
- continue;
-
- if (x == xres && (yres == 0 || y == yres))
- break;
-
- x = x - 2 * ps3fb_res[i].xoff;
- y = y - 2 * ps3fb_res[i].yoff;
- if (x == xres && (yres == 0 || y == yres))
- break;
- }
- return i;
-}
-
static unsigned int ps3fb_find_mode(const struct fb_var_screeninfo *var,
u32 *ddr_line_length, u32 *xdr_line_length)
{
@@ -431,8 +375,7 @@ static void ps3fb_sync_image(struct devi
static int ps3fb_sync(struct fb_info *info, u32 frame)
{
struct ps3fb_par *par = info->par;
- int i, error = 0;
- u32 ddr_line_length, xdr_line_length;
+ int error = 0;
u64 ddr_base, xdr_base;
acquire_console_sem();
@@ -444,16 +387,13 @@ static int ps3fb_sync(struct fb_info *in
goto out;
}
- i = par->res_index;
- xdr_line_length = info->fix.line_length;
- ddr_line_length = ps3fb_res[i].xres * BPP;
- xdr_base = frame * info->var.yres_virtual * xdr_line_length;
- ddr_base = frame * ps3fb_res[i].yres * ddr_line_length;
+ xdr_base = frame * par->xdr_frame_size;
+ ddr_base = frame * par->ddr_frame_size;
ps3fb_sync_image(info->device, ddr_base + par->full_offset,
ddr_base + par->fb_offset, xdr_base + par->pan_offset,
-par->width, par->height, ddr_line_length,
-xdr_line_length);
+par->width, par->height, par->ddr_line_length,
+info->fix.line_length);
out:
release_console_sem();
@@ -570,8 +510,9 @@ static int ps3fb_set_par(struct fb_info
{
struct ps3fb_par *par = info->par;
unsigned int mode, ddr_line_length, xdr_line_length, lines, maxlines;
- int i;
+ unsigned int ddr_xoff, ddr_yoff;
unsigned long offset;
+ const struct fb_videomode *vmode;
u64 dst;
dev_dbg(info->device, "xres:%d xv:%d yres:%d yv:%d clock:%d\n",
@@ -582,8 +523,7 @@ static int ps3fb_set_par(struct fb_info
if (!mode)
return -EINVAL;
- i = ps3fb_get_res_table(info->var.xres, info->var.yres, mode);
- par->res_index = i;
+ vmode = ps3fb_default_mode(mode | PS3AV_MO
Re: sys_mpc83xx spi driver not probed
On Mon, Nov 26, 2007 at 10:39:56AM -0600, Scott Wood wrote: > On Fri, Nov 23, 2007 at 07:02:23PM +0200, Joel Rouch wrote: > > I have a custom 8349 ppc board. I have defined the spi master in the > > configuration. > > While booting my board, I driver is well added and linked to platform > > bus, however I don't see that the probe entry point is reached. > > I don't succeed to understand who is triggering the probe. Can someone > > point me to the right link or explain me how to force it ? > > Are you calling of_platform_bus_probe() from your board file? spi_mpc83xx isn't of_platform_driver, yet. Thus we have to use fsl helper, fsl_spi_init. So far, good example of spi_mpc83xx usage is in arch/powerpc/platforms/83xx/mpc832x_rdb.c Good luck, -- Anton Vorontsov email: [EMAIL PROTECTED] backup email: [EMAIL PROTECTED] irc://irc.freenode.net/bd2 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Access to PCI Expansion ROMs on PPC
On Mon, Nov 26, 2007 at 11:33:00AM -0500, Jon Smirl wrote: > Did you check out the cards on x86 and ascertain that they have the > standard PCI header in them? 55 AA All PCI ROMs are supposed to > have that. If they are missing that the size code in the rom.c isn't > going to work right. See my more recent testing summary post to the list, with the message-id of [EMAIL PROTECTED] (http://ozlabs.org/pipermail/linuxppc-dev/2007-November/046880.html) The X1900 and Nvidia OF-based cards do not turn up on the x86_64 box at all (the PCIe root node is entirely missing with them as well), and the sata_mv claims to not have a ROM, but does otherwise work. > If these are OF ROM and you are booting on OF firmware, the ROM is > getting run. In that case it may not be so simple to turn them back on > if they have been hidden using a proprietary register. That's the > quirk BenH has referred to. That's the path that I was investigating with the register stuff via airlied's avivotool. There was one register he thought about, but it didn't seem to do much. I also found some instructions to try and view the ROMs from inside OF, some I'm going to try that later today, as that will enable seeing if Linux is changing something critical. -- Robin Hugh Johnson Gentoo Linux Developer & Infra Guy E-Mail : [EMAIL PROTECTED] GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85 pgpB9UQ04gAVt.pgp Description: PGP signature ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [RFC/PATCHv4] powerpc: Move CPM command handling into the cpm drivers
On Monday 26 November 2007, Jochen Friedrich wrote: > This patch moves the CPM command handling into commproc.c > for CPM1 and cpm2_common.c. This is yet another preparation > to get rid of drivers accessing the CPM via the global cpmp. > > Signed-off-by: Jochen Friedrich <[EMAIL PROTECTED]> Acked-by: Arnd Bergmann <[EMAIL PROTECTED]> ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] ehea: Add kdump support
Hi, On Mon, Nov 26, 2007 at 01:41:37PM -0200, Luke Browning wrote: > On Mon, 2007-11-26 at 19:16 +1100, Michael Ellerman wrote: > > > For kdump we have to assume that the kernel is fundamentally broken, If I may so humbly suggest: since ehea is a power6 thing only, we should refocus our energies on "hypervisor assisted dump", which solves all of these problems. In short, upon crash, the hypervisor will reset the pci devices into working order, and will then boot a new fresh kernel into a tiny corner of ram. The rest of ram is not cleared, and can be dumped. After the dump, the mem is returned to general use. The key point here, for ehea, is "the hypervisor will reset he device state to something rational". Preliminary patches are at http://patchwork.ozlabs.org/linuxppc/patch?id=14884 and following. --linas ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Sequoia EMAC only works if u-boot initializes it?
I've attached a copy of my bootlog. I added in one patch to enable rgmii but that didn't fix it. (http://ozlabs.org/pipermail/linuxppc-dev/2007-October/043435.html) I am curious why the new emac driver is enabled in the DENX tree but not in the upstream trees. Has DENX successfully used this driver on the Sequoia board? Am I trying something that is known not to work? I'm interested in helping in whatever way I can. I need ARCH=powerpc to use the current Xenomai patches, and I need both EMACs so I can evaluate bonding (for high-availability). Thanks, Steve Stefan Roese wrote: On Monday 26 November 2007, Steven A. Falco wrote: I have noticed odd behavior on a Sequoia board. Kernel is built from DENX git, ARCH=powerpc, 2.6.23.1. Sequence that works: 1) In u-boot, do "dhcp" (this initializes the PHY) 2) Boot linux from flash 3) ifconfig eth0 192.168.0.101 netmask 255.255.255.0 up Ethernet is now functional, and I can ping the Sequoia (and it can ping my host) Sequence that does not work: 1) Boot linux from flash without letting u-boot touch eth0 2) ifconfig eth0 192.168.0.101 netmask 255.255.255.0 up Ethernet appears to come up, but it is not functional. I.e. I get "eth0: link is up, 100 FDX, pause enabled" but I cannot ping the board, and the board cannot ping my host. Do you have a 100MBit connection? Or Gbit? Could you please send the complete bootlog. So, the kernel appears to be missing some initialization that u-boot provides. However, eth1 is more strange. U-boot can use it (via "setenv ethact ppc_4xx_eth1;dhcp"), however, the kernel cannot use it, whether or not u-boot first initializes it. If anyone has suggestions on where to look, I'd appreciate it. I'm going to look at the PHY register settings and see if there are any clues there... Again it would be interesting to see the bootlog here. Best regards, Stefan = 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] = => run saf ## Booting image at fc00 ... Image Name: Linux-2.6.23.1-gb68e890e-dirty Image Type: PowerPC Linux Kernel Image (gzip compressed) Data Size:1623086 Bytes = 1.5 MB Load Address: 0040 Entry Point: 004003e0 Verifying Checksum ... OK Uncompressing Kernel Image ... OK ## Loading RAMDisk Image at fc2c ... Image Name: Sequoia Ramdisk RCD-05 Image Type: PowerPC Linux RAMDisk Image (gzip compressed) Data Size:1169588 Bytes = 1.1 MB Load Address: Entry Point: Verifying Checksum ... OK Loading Ramdisk to 0fe0d000, end 0ff2a8b4 ... OK CPU clock-frequency <- 0x27bc86ae (667MHz) CPU timebase-frequency <- 0x27bc86ae (667MHz) /plb: clock-frequency <- 9ef21ab (167MHz) /plb/opb: clock-frequency <- 4f790d5 (83MHz) /plb/opb/ebc: clock-frequency <- 34fb5e3 (56MHz) /plb/opb/[EMAIL PROTECTED]: clock-frequency <- a8c000 (11MHz) /plb/opb/[EMAIL PROTECTED]: clock-frequency <- a8c000 (11MHz) /plb/opb/[EMAIL PROTECTED]: clock-frequency <- a8c000 (11MHz) /plb/opb/[EMAIL PROTECTED]: clock-frequency <- a8c000 (11MHz) Memory <- <0x0 0x0 0x1000> (256MB) ENET0: local-mac-address <- 00:10:ec:00:e2:85 ENET1: local-mac-address <- 00:10:ec:80:e2:85 zImage starting: loaded at 0x0040 (sp: 0x0ff2b568) Allocating 0x39068c bytes for kernel ... gunzipping (0x <- 0x0040c000:0x0076e178)...done 0x34aaac bytes Using loader supplied ramdisk at 0xfe0d000-0xff2a8b4 initrd head: 0x1f8b0808 Linux/PowerPC load: root=/dev/ram rw console=ttyS0,115200 Finalizing device tree... flat tree at 0x77b3a0 Using Sequoia machine description Linux version 2.6.23.1-gb68e890e-dirty ([EMAIL PROTECTED]) (gcc version 4.0.0 (DENX ELDK 4.1 4.0.0)) #8 Mon Nov 26 13:05:59 EST 2007 Found initrd at 0xcfe0d000:0xcff2a8b4 Zone PFN ranges: DMA 0 ->65536 Normal 65536 ->65536 Movable zone start PFN for each node early_node_map[1] active PFN ranges 0:0 ->65536 Built 1 zonelists in Zone order. Total pages: 65024 Kernel command line: root=/dev/ram rw console=ttyS0,115200 UIC0 (32 IRQ sources) at DCR 0xc0 UIC1 (32 IRQ sources) at DCR 0xd0 UIC2 (32 IRQ sources) at DCR 0xe0 PID hash table entries: 1024 (order: 10, 4096 bytes) I-pipe 2.0-03: pipeline enabled. Dentry cache hash table entries: 32768 (order: 5, 131072 bytes) Inode-cache hash table entries: 16384 (order: 4, 65536 bytes) Memory: 254772k/262144k available (3192k kernel code, 7064k reserved, 160k data, 277k bss, 136k init) Mount-cache hash table entries: 512 NET: Registered protocol family 16 PCI: Probing PCI hardware SCSI subsystem initialized usbcore: registered new interface driver usbfs usbcore: registered new interface driver hub usbcore: regi
Re: pseries (power3) boot hang (pageblock_nr_pages==0)
On Wed, 2007-11-21 at 22:03 +, Mel Gorman wrote: > On (21/11/07 15:55), Will Schmidt didst pronounce: > > Hi Folks, > > > > I imagine this would be properly fixed with something similar to the > > change for iSeries. > > Have you tried with the patch that fixed the iSeries boot problem? > Thanks for tracking down the problem to such a specific place. I had not, but gave this patch a spin this morning, and it does the job. :-)I was thinking (without really looking at it), that the iseries fix was in platform specific code. Silly me. :-) So for the record, this patch also fixes power3 pSeries systems. fwiw: Tested-By: Will Schmidt <[EMAIL PROTECTED]> Thanks, -Will > == > > Ordinarily, the size of a pageblock is determined at compile-time based on > the hugepage size. On PPC64, the hugepage size is determined at runtime based > on what is supported by the machine. On legacy machines such as iSeries which > do not support hugepages, HPAGE_SHIFT is 0. This results in pageblock_order > being set to -PAGE_SHIFT and a crash results shortly afterwards. > > This patch checks that HPAGE_SHIFT is a sensible value before using the > hugepage size. If it is 0, MAX_ORDER-1 is used instead as this is a sensible > value of pageblock_order. > > This is a fix for 2.6.24. > > Credit goes to Stephen Rothwell for identifying the bug and testing on > iSeries. Additional credit goes to David Gibson for testing with the > libhugetlbfs test suite. > > Signed-off-by: Mel Gorman <[EMAIL PROTECTED]> > > --- ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Sequoia EMAC only works if u-boot initializes it?
On Mon, 2007-11-26 at 14:10 -0500, Steven A. Falco wrote: > I've attached a copy of my bootlog. I added in one patch to enable > rgmii but that didn't fix > it.(http://ozlabs.org/pipermail/linuxppc-dev/2007-October/043435.html) > > I am curious why the new emac driver is enabled in the DENX tree but > not in the upstream trees. Has DENX successfully used this driver on > the Sequoia board? Am I trying something that is known not to work? > > I'm interested in helping in whatever way I can. I need ARCH=powerpc > to use the current Xenomai patches, and I need both EMACs so I can > evaluate bonding (for high-availability). Have you tried adding the various patches I posted along with the patches Valentine posted ? I'll re-send a full serie later this week. Let us know if those help or if something is still broken. Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: dtc: Remove some redundant testcases
So, like, the other day David Gibson mumbled: > This patch removes a number of testcases from the testsuite that are > extremely unlikely to find any bugs that won't be found by the other > tests. This speeds up the testsuite. > > - Both loops across the various tree block layouts run the > tree1_tests on the basic mangled tree. This is completely redundant, > so remove the second copy. This removes 456 testcases. > > - We currently run tree1_tests on various trees manipulated by > move_and_save. We replace those with just a dtbs_equal_ordered test > to check that the manipulated tree is equal to the original. What > we're testing here is that fdt_move() operates correctly - it's very > unlikely it would succeed well enough for the ordered_equal test to > succeed, but the tree1_tests would fail on the result. This removes > 162 testcases. > > - Currently we re-ordered with mangle-layout both the basic > test_tree1.dtb and sw_tree1.test.dtb. Since we've already checked > that these dtbs are equivalent with dtbs_ordered_equal, it's very > unlikely that the tests would fail on one but not the other. > Therefore reduce this to only using test_tree1.dtb. This removes 828 > testcases. Applied. Thanks, jdl ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [RFC/PATCH] powerpc: Move CPM command handling into the cpm drivers
On Mon, 26 Nov 2007 10:24:46 -0600 Scott Wood wrote: > On Fri, Nov 23, 2007 at 12:51:21AM +0300, Vitaly Bordug wrote: > > Even that might be not enough - we may have simultaneous call of > > this func in non-smp case... > > Do you really think that every piece of code that uses spinlocks in > the kernel is broken on non-SMP? > No. I think spinlock is not universal save thing in such cases. See below. > > I was thinking of some kind of refcount, so one that is going to > > issue CPM command, must do say pq_cpmp_get() and another driver > > won't be able to mangle with cpcr while it's not done with previous > > request. > > How on earth are you going to effect mutual exclusion using reference > counting? > perhaps I was not clear enough. That was a rough idea how to handle the whole thing, not just cpm_cr_cmd. This cpm command is a corner case, but there can be other actions that may confuse CPM being triggered simultaneously or overlapping. This is part of much bigger problem, and I was intended to have a look what people think about that. -- Sincerely, Vitaly ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [RFC/PATCH] powerpc: Move CPM command handling into the cpm drivers
Vitaly Bordug wrote: > perhaps I was not clear enough. That was a rough idea how to handle > the whole thing, not just cpm_cr_cmd. This cpm command is a corner > case, but there can be other actions that may confuse CPM being > triggered simultaneously or overlapping. What kind of actions did you have in mind? Microcode patching? -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
RE: Xilinx EDK BSP generation of device trees for microblaze and PowerPC
I've pushed the current state up to
git://git.xilinx.com/gen-mhs-devtree.git for your perusing. Comments
below.
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
> Behalf Of Grant Likely
> Sent: Sunday, November 25, 2007 2:47 PM
> To: Stephen Neuendorffer; Segher Boessenkool; David Gibson;
> Jon Loeliger
> Cc: [EMAIL PROTECTED];
> linuxppc-dev@ozlabs.org; Michal Simek; git
> Subject: Re: Xilinx EDK BSP generation of device trees for
> microblaze and PowerPC
>
> On 11/24/07, Stephen Neuendorffer
> <[EMAIL PROTECTED]> wrote:
> >
>
> Thanks for all this work; comments below.
>
> >
> > Here's what I've gotten so far:
> >
> > Hard_Ethernet_MAC: [EMAIL PROTECTED] {
> > #address-cells = <1>;
> > #size-cells = <1>;
> > [EMAIL PROTECTED] {
> > compatible =
> "xlnx,xps-ll-temac-1.00.a",
> > "xlnx,xps-ll-temac";
>
> Drop "xlnx,xps-ll-temac"; it's 100% made up. This should be simply:
> compatible = "xlnx,xps-ll-temac-1.00.a" for version 1.00.a and
> compatible =
> "xlnx,xps-ll-temac-","xlnx,xps-ll-temac-1.00.a" for a future
> version if it maintains register level compatibility.
>
> "xlnx,xps-ll-temac" is far to ambiguous.
What if it was: compatible = "xlnx,xps-ll-temac-1.00.a",
"xlnx,xps-ll-temac-1"?
Basically, I don't want to be responsible for declaring what versions of
IP are backward compatible with ll-temac-1.00.a, and I think it's bad
software design to put that list into the dts generator anyway. In
theory, at least, all ip with the same major version should be
compatible.
> > interrupt-parent = <&xps_intc_0>;
> > interrupts = < 3 0 >;
> > llink-connected = <&PIM3>;
>
> What's this property for?
So that the ll_temac knows whether to use dma or fifo code and where the
dma or fifo control/interrupts are.
>
> > reg = < 81c0 40 >;
>
> If these registers are addressable, then the parent needs a
> 'ranges' property.
I thought ranges weren't necessary in a 1:1 mapping?
> > xlnx,bus2core-clk-ratio = <1>;
> > xlnx,phy-type = <1>;
> > xlnx,phyaddr = <1>;
> > xlnx,rxcsum = <0>;
> > xlnx,rxfifo = <1000>;
> > xlnx,temac-type = <0>;
> > xlnx,txcsum = <0>;
> > xlnx,txfifo = <1000>;
>
> Would be nice to have a 'phy-handle' property as that is what is being
> used on other platforms; but that's not something that EDK knows
> about. It would be nice to have a way to tell EDK what PHY device is
> on the board so it could generate the appropriate mdio and phy nodes.
Yeah, this is going to be a big issue, I think...
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Please pull powerpc.git merge branch
Linus, Please do git pull \ git://git.kernel.org/pub/scm/linux/kernel/git/paulus/powerpc.git merge to get another batch of fixes for powerpc, as listed below. Since the pull request I sent last week while you were away, I have added four more commits from Kumar. Thanks, Paul. Documentation/powerpc/booting-without-of.txt |5 + arch/powerpc/boot/dts/mpc832x_mds.dts | 16 ++- arch/powerpc/boot/dts/mpc834x_mds.dts |9 ++ arch/powerpc/boot/dts/mpc836x_mds.dts |9 ++ arch/powerpc/boot/dts/mpc8544ds.dts| 20 ++-- arch/powerpc/boot/dts/mpc8572ds.dts| 108 ++--- arch/powerpc/boot/dts/mpc8641_hpcn.dts | 126 arch/powerpc/configs/mpc832x_mds_defconfig | 48 + arch/powerpc/configs/mpc832x_rdb_defconfig | 41 +++- arch/powerpc/configs/mpc834x_itx_defconfig |2 arch/powerpc/configs/mpc834x_itxgp_defconfig | 88 + arch/powerpc/configs/mpc834x_mds_defconfig | 48 + arch/powerpc/configs/mpc836x_mds_defconfig | 48 + arch/powerpc/configs/mpc8568mds_defconfig | 48 + arch/powerpc/kernel/asm-offsets.c |4 + arch/powerpc/kernel/rtas.c | 111 - arch/powerpc/kernel/time.c |5 + arch/powerpc/kernel/vdso.c | 11 ++ arch/powerpc/kernel/vdso32/cacheflush.S| 41 ++-- arch/powerpc/kernel/vdso64/cacheflush.S| 41 ++-- arch/powerpc/mm/mem.c |2 arch/powerpc/mm/mmu_decl.h |2 arch/powerpc/mm/stab.c |1 arch/powerpc/platforms/40x/walnut.c|3 - arch/powerpc/platforms/44x/bamboo.c|3 - arch/powerpc/platforms/44x/ebony.c |3 - arch/powerpc/platforms/44x/sequoia.c |3 - arch/powerpc/platforms/83xx/mpc832x_mds.c | 31 +- arch/powerpc/platforms/83xx/mpc832x_rdb.c | 14 ++- arch/powerpc/platforms/83xx/mpc834x_mds.c | 24 - arch/powerpc/platforms/83xx/mpc836x_mds.c | 55 +- arch/powerpc/platforms/83xx/usb.c |8 +- arch/powerpc/platforms/cell/spufs/inode.c |1 arch/powerpc/platforms/embedded6xx/prpmc2800.c |1 arch/powerpc/platforms/pasemi/setup.c |2 arch/powerpc/platforms/pseries/Kconfig |2 arch/powerpc/platforms/pseries/setup.c |3 - arch/powerpc/sysdev/uic.c | 18 +++ arch/ppc/kernel/setup.c|7 + arch/ppc/mm/init.c |2 arch/ppc/mm/mmu_decl.h |2 arch/ppc/platforms/4xx/yucca.c |1 arch/ppc/syslib/virtex_devices.c | 31 ++ include/asm-powerpc/page_32.h |4 + include/asm-powerpc/pci-bridge.h |5 + include/asm-powerpc/rtas.h |3 - include/asm-powerpc/vdso_datapage.h|8 ++ 47 files changed, 832 insertions(+), 236 deletions(-) Anton Vorontsov (2): [POWERPC] 83xx: MPC832x RDB - remove spidev stub, use mmc_spi [POWERPC] 83xx: Update mpc832x_rdb_defconfig to enable MMC-over-SPI Benjamin Herrenschmidt (3): [POWERPC] Fix declaration of pcibios_free_controller [POWERPC] Fix kmalloc alignment on non-coherent DMA platforms [POWERPC] Fix 8xx build breakage due to _tlbie changes Cyrill Gorcunov (1): [POWERPC] Fix potential NULL dereference Grant Likely (1): [POWERPC] 83xx: Update mpc8349emitx(gp) defconfig for USB Jeremy Kerr (1): [POWERPC] spufs: Fix context destroy vs /spu readdir race Joachim Foerster (1): [POWERPC] Xilinx: Register AC97 Controller Reference with the platform bus Jon Loeliger (1): [POWERPC] 4xx: Replace #includes of asm/of_platform.h with linux/of_platform.h. Josh Boyer (1): [POWERPC] 4xx: Use virtual PVR value to init FPU on arch/ppc 440EP Kamalesh Babulal (1): [POWERPC] Fix build failure on legacy iSeries Kim Phillips (5): [POWERPC] 83xx: mpc832x mds: Fix board PHY reset code [POWERPC] 83xx: Fix 2nd UCC entry in mpc832x_mds.dts [POWERPC] Document rgmii-rxid and rgmii-txid phy-connection-types [POWERPC] 83xx: Handle mpc8360 rev. 2.1 RGMII timing erratum [POWERPC] 8xxx: MDS board RTC fixes Kumar Gala (1): [POWERPC] Fix device tree interrupt map for Freescale ULI1575 boards Linas Vepstas (1): [POWERPC] Fix RTAS os-term usage on kernel panic Mark A. Greer (1): [POWERPC] prpmc2800: Enable L2 cache Michael Neuling (1): [POWERPC] Fix possible division by zero in scaled time accounting Nathan Lynch (1): [POWERPC] Fix multiple bugs in rtas_ibm_suspend_me code Olof Johansson (2): [POWERPC] pasemi: Don't reset mpic at boot [POWERPC] vdso: Fixes for cache bl
Re: dtc: Add valgrind support to testsuite
So, like, the other day David Gibson mumbled: > This patch adds some options to the run_tests.sh script allowing it to > run all the testcases under valgrind to check for pointer corruption > bugs and memory leaks. Invoking "make checkm" will run the testsuite > with valgrind. > > It include a mechanism for specifying valgrind errors to be suppressed > on a per-testcase basis, and adds a couple of such suppression files > for the mangle-layout and open_pack testcases which dump for use by > other testcases a buffer which may contain uninitialized sections. We > use suppressions rather than initializing the buffer so that valgrind > will catch any internal access s to the uninitialized data, which > would be a bug. > > The patch also fixes one genuine bug caught by valgrind - > _packblocks() in fdt_rw.c was using memcpy() where it should have been > using memmove(). > > At present the valgrinding won't do anything useful for testcases > invoked via a shell script - which includes all the dtc testcases. I > plan to fix that later. > > Signed-off-by: David Gibson <[EMAIL PROTECTED]> Applied. Thanks, jdl PS -- Clearly, I'm going to have to break down and install valgrind now. :-) ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: dtc: Merge refs and labels into single "markers" list
So, like, the other day David Gibson mumbled: > Currently, every 'data' object, used to represent property values, has > two lists of fixup structures - one for labels and one for references. > Sometimes we want to look at them separately, but other times we need > to consider both types of fixup. > > I'm planning to implement string references, where a full path rather > than a phandle is substituted into a property value. Adding yet > another list of fixups for that would start to get messy. So, this > patch merges the "refs" and "labels" lists into a single list of > "markers", each of which has a type field indicating if it represents > a label or a phandle reference. String references or any other new > type of in-data marker will then just need a new type value - merging > data blocks and other common manipulations will just work. > > While I was at it I made some cleanups to the handling of fixups which > simplify things further. > > Signed-off-by: David Gibson <[EMAIL PROTECTED]> Applied. Thanks, jdl ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: dtc: Flexible tree checking infrastructure (v2)
So, like, the other day David Gibson mumbled: > dtc: Flexible tree checking infrastructure > > Here, at last, is a substantial start on revising dtc's infrastructure > for checking the tree; this is the rework I've been saying was > necessary practically since dtc was first release. > > In the new model, we have a table of "check" structures, each with a > name, references to checking functions, and status variables. Each > check can (in principle) be individually switched off or on (as either > a warning or error). Checks have a list of prerequisites, so if > checks need to rely on results from earlier checks to make sense (or > even to avoid crashing) they just need to list the relevant other > checks there. > > For now, only the "structural" checks and the fixups for phandle > references are converted to the new mechanism. The rather more > involved semantic checks (which is where this new mechanism will > really be useful) will have to be converted in future patches. > > At present, there's no user interface for turning on/off the checks - > the -f option now forces output even if "error" level checks fail. > Again, future patches will be needed to add the fine-grained control, > but that should be quite straightforward with the infrastructure > implemented here. > > Also adds a testcase for the handling of bad references, which catches > a bug encountered while developing this patch. > > Signed-off-by: David Gibson <[EMAIL PROTECTED]> While I've Applied this one, it has introduced this: CC dtc.o dtc.c: In function 'main': dtc.c:199: warning: 'structure_ok' is used uninitialized in this function Followup easy patch? Thanks, jdl ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 0/3][RESEND] fixups for mpc8360 rev. 2.1 erratum #2 (RGMII Timing)
these 3 patches are a resend of patches 2-4 (out of 5) that were originally sent 2007-11-05* (patches 1 and 5 were picked up by Kumar to go through powerpc). Jeff, Leo has acked these, please consider for 2.6.24. Thanks, Kim * http://marc.info/?l=linux-netdev&m=119428688804765&w=1 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 1/3][RESEND] phylib: add PHY interface modes for internal delay for tx and rx only
Allow phylib specification of cases where hardware needs to configure
PHYs for Internal Delay only on either RX or TX (not both).
Signed-off-by: Kim Phillips <[EMAIL PROTECTED]>
Tested-by: Anton Vorontsov <[EMAIL PROTECTED]>
Acked-by: Li Yang <[EMAIL PROTECTED]>
---
include/linux/phy.h |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/include/linux/phy.h b/include/linux/phy.h
index f0742b6..e10763d 100644
--- a/include/linux/phy.h
+++ b/include/linux/phy.h
@@ -58,6 +58,8 @@ typedef enum {
PHY_INTERFACE_MODE_RMII,
PHY_INTERFACE_MODE_RGMII,
PHY_INTERFACE_MODE_RGMII_ID,
+ PHY_INTERFACE_MODE_RGMII_RXID,
+ PHY_INTERFACE_MODE_RGMII_TXID,
PHY_INTERFACE_MODE_RTBI
} phy_interface_t;
--
1.5.2.2
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 2/3][RESEND] phylib: marvell: add support for TX-only and RX-only Internal Delay
Previously, Internal Delay specification implied the delay be
applied to both TX and RX. This patch allows for separate TX/RX-only
internal delay specification.
Signed-off-by: Kim Phillips <[EMAIL PROTECTED]>
Tested-by: Anton Vorontsov <[EMAIL PROTECTED]>
Acked-by: Li Yang <[EMAIL PROTECTED]>
---
drivers/net/phy/marvell.c | 26 +-
1 files changed, 17 insertions(+), 9 deletions(-)
diff --git a/drivers/net/phy/marvell.c b/drivers/net/phy/marvell.c
index 035fd41..f057407 100644
--- a/drivers/net/phy/marvell.c
+++ b/drivers/net/phy/marvell.c
@@ -143,21 +143,29 @@ static int m88e_config_init(struct phy_device *phydev)
int err;
if ((phydev->interface == PHY_INTERFACE_MODE_RGMII) ||
- (phydev->interface == PHY_INTERFACE_MODE_RGMII_ID)) {
+ (phydev->interface == PHY_INTERFACE_MODE_RGMII_ID) ||
+ (phydev->interface == PHY_INTERFACE_MODE_RGMII_RXID) ||
+ (phydev->interface == PHY_INTERFACE_MODE_RGMII_TXID)) {
int temp;
- if (phydev->interface == PHY_INTERFACE_MODE_RGMII_ID) {
- temp = phy_read(phydev, MII_M_PHY_EXT_CR);
- if (temp < 0)
- return temp;
+ temp = phy_read(phydev, MII_M_PHY_EXT_CR);
+ if (temp < 0)
+ return temp;
+ if (phydev->interface == PHY_INTERFACE_MODE_RGMII_ID) {
temp |= (MII_M_RX_DELAY | MII_M_TX_DELAY);
-
- err = phy_write(phydev, MII_M_PHY_EXT_CR, temp);
- if (err < 0)
- return err;
+ } else if (phydev->interface == PHY_INTERFACE_MODE_RGMII_RXID) {
+ temp &= ~MII_M_TX_DELAY;
+ temp |= MII_M_RX_DELAY;
+ } else if (phydev->interface == PHY_INTERFACE_MODE_RGMII_TXID) {
+ temp &= ~MII_M_RX_DELAY;
+ temp |= MII_M_TX_DELAY;
}
+ err = phy_write(phydev, MII_M_PHY_EXT_CR, temp);
+ if (err < 0)
+ return err;
+
temp = phy_read(phydev, MII_M_PHY_EXT_SR);
if (temp < 0)
return temp;
--
1.5.2.2
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 3/3][RESEND] ucc_geth: handle passing of RX-only and TX-only internal delay PHY connection type parameters
Extend the RGMII-Internal Delay specification case to include
TX-only and RX-only variants.
Signed-off-by: Kim Phillips <[EMAIL PROTECTED]>
Tested-by: Anton Vorontsov <[EMAIL PROTECTED]>
Acked-by: Li Yang <[EMAIL PROTECTED]>
---
drivers/net/ucc_geth.c | 10 ++
1 files changed, 10 insertions(+), 0 deletions(-)
diff --git a/drivers/net/ucc_geth.c b/drivers/net/ucc_geth.c
index a3ff270..7f68990 100644
--- a/drivers/net/ucc_geth.c
+++ b/drivers/net/ucc_geth.c
@@ -1460,6 +1460,8 @@ static int adjust_enet_interface(struct ucc_geth_private
*ugeth)
if ((ugeth->phy_interface == PHY_INTERFACE_MODE_RMII) ||
(ugeth->phy_interface == PHY_INTERFACE_MODE_RGMII) ||
(ugeth->phy_interface == PHY_INTERFACE_MODE_RGMII_ID) ||
+ (ugeth->phy_interface == PHY_INTERFACE_MODE_RGMII_RXID) ||
+ (ugeth->phy_interface == PHY_INTERFACE_MODE_RGMII_TXID) ||
(ugeth->phy_interface == PHY_INTERFACE_MODE_RTBI)) {
upsmr |= UPSMR_RPM;
switch (ugeth->max_speed) {
@@ -1557,6 +1559,8 @@ static void adjust_link(struct net_device *dev)
if ((ugeth->phy_interface ==
PHY_INTERFACE_MODE_RMII) ||
(ugeth->phy_interface ==
PHY_INTERFACE_MODE_RGMII) ||
(ugeth->phy_interface ==
PHY_INTERFACE_MODE_RGMII_ID) ||
+ (ugeth->phy_interface ==
PHY_INTERFACE_MODE_RGMII_RXID) ||
+ (ugeth->phy_interface ==
PHY_INTERFACE_MODE_RGMII_TXID) ||
(ugeth->phy_interface ==
PHY_INTERFACE_MODE_RTBI)) {
if (phydev->speed == SPEED_10)
upsmr |= UPSMR_R10M;
@@ -3795,6 +3799,10 @@ static phy_interface_t to_phy_interface(const char
*phy_connection_type)
return PHY_INTERFACE_MODE_RGMII;
if (strcasecmp(phy_connection_type, "rgmii-id") == 0)
return PHY_INTERFACE_MODE_RGMII_ID;
+ if (strcasecmp(phy_connection_type, "rgmii-txid") == 0)
+ return PHY_INTERFACE_MODE_RGMII_TXID;
+ if (strcasecmp(phy_connection_type, "rgmii-rxid") == 0)
+ return PHY_INTERFACE_MODE_RGMII_RXID;
if (strcasecmp(phy_connection_type, "rtbi") == 0)
return PHY_INTERFACE_MODE_RTBI;
@@ -3889,6 +3897,8 @@ static int ucc_geth_probe(struct of_device* ofdev, const
struct of_device_id *ma
case PHY_INTERFACE_MODE_GMII:
case PHY_INTERFACE_MODE_RGMII:
case PHY_INTERFACE_MODE_RGMII_ID:
+ case PHY_INTERFACE_MODE_RGMII_RXID:
+ case PHY_INTERFACE_MODE_RGMII_TXID:
case PHY_INTERFACE_MODE_TBI:
case PHY_INTERFACE_MODE_RTBI:
max_speed = SPEED_1000;
--
1.5.2.2
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: mmap on PPC removes file refcount?
NM, it was a bad test causing weird behavior on PPC. :( Dave Jiang wrote: > It seems the mmap() userland call on PPC causes the kernel to lose the ref > count for the mount point. This is what I did on a prpmc2800 board (74xx) with > latest powerpc.git tree (but also seem to happen on 8548 as well). > > I mounted an IDE partition. The userland test app opens a file on the mounted > partition and sits in a sleep loop while holding the file open. I call umount > on the partition and I get "device is busy" which is suppose to happen. > However, after the test app calls mmap on the file id for the opened file, I > can successfully umount even though it should still say "device is busy". > This > does not happen on x86 so I'm assuming something is going on with just PPC. > > So using lsof I can list the opened files on a particular partition. When the > file is opened, it lists 1 entry. When mmaped, on x86 it would list 2 entries, > but on ppc it lists nothing. Not only did the mmaped entry not show up, the > entry caused by open disappeared as well. Also, I put a printk in do_umount() > to see what the refcount is. On x86, it would be 3 and thus causes device > busy. > On PPC it is 3 when the file is openend, however if mmap is called, the > refcount becomes 2 and thus umount proceeds. It's almost as if the mmap call > wiped out the opened file entry and decremented the mount count as well. > > -- -- Dave Jiang Software Engineer MontaVista Software, Inc. http://www.mvista.com -- ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: dtc: RFC: Fix some lexical problems with references
So, like, the other day David Gibson mumbled:
> The recent change to the lexer to only recognize property and node
> names in the appropriate context removed a number of lexical warts in
> our language that would have gotten ugly as we add expression support
> and so forth.
>
> But there's one nasty one remaining: references can contain a full
> path, including the various problematic node name characters (',', '+'
> and '-', for example). This would cause trouble with expressions, and
> it also causes trouble with the patch I'm working on to allow
> expanding references to paths rather than phandles. This patch
> therefore reworks the lexer to mitigate these problems.
>
> - References to labels cause no problems. These are now
> recognized separately from references to full paths. No syntax change
> here.
>
> - References to full paths, including problematic characters
> are allowed by "quoting" the path with braces
> e.g. &{/[EMAIL PROTECTED]/[EMAIL PROTECTED],8000}. The braces protect any
> internal
> problematic characters from being confused with operators or whatever.
>
> - For compatibility with existing dts files, in v0 dts files
> we allow bare references to paths as before &/foo/bar/whatever - but
> *only* if the path contains no troublesome characters. Specifically
> only [a-zA-Z0-9_@/] are allowed.
>
> This is an incompatible change to the dts-v1 format, but since AFAIK
> no-one has yet switched to dts-v1 files, I think we can get away with
> it. Better to make the transition when people to convert to v1, and
> get rid of the problematic old syntax.
>
> Strictly speaking, it's also an incompatible change to the v0 format,
> since some path references that were allowed before are no longer
> allowed. I suspect no-one has been using the no-longer-supported
> forms (certainly none of the kernel dts files will cause trouble). We
> might need to think about this harder, though.
This all sounds fine by me. We should take the incompatibility hit
once here and now; it shouldn't be a problem to eek in some more still.
Thanks,
jdl
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: mmap on PPC removes file refcount?
On Mon, 2007-11-26 at 15:30 -0700, Dave Jiang wrote: > NM, it was a bad test causing weird behavior on PPC. :( Ah good, because I did spend some time looking at the code and didn't see anything wrong :-) Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Sequoia EMAC only works if u-boot initializes it?
With the following 15 patches on top of the DENX git tree, I have both emac ports working: 1) [PATCH 2/2] PowerPC: Fix Sequoia MAL0 and EMAC dts entries. 2) [PATCH] PowerPC: Add RGMII support for Sequoia 440EPx 3) [PATCH] Fix typo in new EMAC driver. 4) PowerPC: Enable NEW EMAC support for Sequoia 440EPx. 5) [PATCH 1/8] ibm_newemac: Fix possible lockup on close 6) [PATCH 2/8] ibm_newemac: Add BCM5248 and Marvell 88E PHY support 7) [PATCH 3/8] ibm_newemac: Add ET1011c PHY support 8) [PATCH 4/8] ibm_newemac: Fix ZMII refcounting bug 9) [PATCH 5/8] ibm_newemac: Workaround reset timeout when no link 10) [PATCH 6/8] ibm_newemac: Cleanup/Fix RGMII MDIO support detection 11) [PATCH 7/8] ibm_newemac: Cleanup/fix support for STACR register variants 12) [PATCH 8/8] ibm_newemac: Skip EMACs that are marked unused by the firmware 13) [PATCH 1/3] PowerPC: ibm_newemac correct opb_bus_freq value 14) [PATCH 2/3] PowerPC: ibm_newemac tah_ph typo fix 15) [PATCH 3/3] PowerPC: ibm_newemac call dev_set_drvdata() before tah_reset() Steve Benjamin Herrenschmidt wrote: > On Mon, 2007-11-26 at 14:10 -0500, Steven A. Falco wrote: >> I've attached a copy of my bootlog. I added in one patch to enable >> rgmii but that didn't fix >> it.(http://ozlabs.org/pipermail/linuxppc-dev/2007-October/043435.html) >> >> I am curious why the new emac driver is enabled in the DENX tree but >> not in the upstream trees. Has DENX successfully used this driver on >> the Sequoia board? Am I trying something that is known not to work? >> >> I'm interested in helping in whatever way I can. I need ARCH=powerpc >> to use the current Xenomai patches, and I need both EMACs so I can >> evaluate bonding (for high-availability). > > Have you tried adding the various patches I posted along with the > patches Valentine posted ? > > I'll re-send a full serie later this week. Let us know if those help or > if something is still broken. > > Cheers, > Ben. > > > ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Sequoia EMAC only works if u-boot initializes it?
On Mon, 2007-11-26 at 17:46 -0500, Steven A. Falco wrote: > With the following 15 patches on top of the DENX git tree, I have both emac > ports working: .../... Good. All of these should go in 2.6.25 (not .24 at this stage though). I suppose DENX will pick them up asap. Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] e1000: Fix for 32 bits platforms with 64 bits resources
Jeff Garzik wrote: > Benjamin Herrenschmidt wrote: >> The e1000 driver stores the content of the PCI resources into >> unsigned long's before ioremapping. This breaks on 32 bits >> platforms that support 64 bits MMIO resources such as ppc 44x. >> >> This fixes it by removing those temporary variables and passing >> directly the result of pci_resource_start/len to ioremap. >> >> The side effect is that I removed the assignments to the netdev >> fields mem_start, mem_end and base_addr, which are totally useless >> for PCI devices. >> >> Signed-off-by: Benjamin Herrenschmidt <[EMAIL PROTECTED]> >> -- >> >> drivers/net/e1000/e1000_main.c | 18 +- >> 1 file changed, 5 insertions(+), 13 deletions(-) > > Looks good to me. auke? yes, please apply. Acked-by: Auke Kok <[EMAIL PROTECTED]> Auke ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 2/2] [PPC 44x] enable L2-cache for ALPR, Katmai, Ocotea, and Taishan
BTW... Do you know why we can't just enable HW snoop ? The 440SPe documentation seems to indicate that this is supported by the L2 cache via snooping on the PLB. Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [patch 2/9] ps3: Use symbolic names for video modes
On Mon, 26 Nov 2007 18:24:57 +0100 Geert Uytterhoeven <[EMAIL PROTECTED]> wrote:
>
> @@ -594,20 +594,21 @@ static const struct {
> unsigned mask : 19;
> unsigned id : 4;
> } ps3av_preferred_modes[] = {
> - { .mask = PS3AV_RESBIT_WUXGA<< SHIFT_VESA, .id = 13 },
> - { .mask = PS3AV_RESBIT_1920x1080P << SHIFT_60,.id = 5 },
> - { .mask = PS3AV_RESBIT_1920x1080P << SHIFT_50,.id = 10 },
> - { .mask = PS3AV_RESBIT_1920x1080I << SHIFT_60,.id = 4 },
> - { .mask = PS3AV_RESBIT_1920x1080I << SHIFT_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 },
> + { PS3AV_RESBIT_WUXGA << SHIFT_VESA, PS3AV_MODE_WUXGA },
> + { PS3AV_RESBIT_1920x1080P << SHIFT_60, PS3AV_MODE_1080P60 },
> + { PS3AV_RESBIT_1920x1080P << SHIFT_50, PS3AV_MODE_1080P50 },
> + { PS3AV_RESBIT_1920x1080I << SHIFT_60, PS3AV_MODE_1080I60 },
> + { PS3AV_RESBIT_1920x1080I << SHIFT_50, PS3AV_MODE_1080I50 },
> + { PS3AV_RESBIT_SXGA << SHIFT_VESA, PS3AV_MODE_SXGA},
> + { PS3AV_RESBIT_WXGA << SHIFT_VESA, PS3AV_MODE_WXGA},
> + { PS3AV_RESBIT_1280x720P << SHIFT_60, PS3AV_MODE_720P60 },
> + { PS3AV_RESBIT_1280x720P << SHIFT_50, PS3AV_MODE_720P50 },
> + { PS3AV_RESBIT_720x480P << SHIFT_60, PS3AV_MODE_480P},
> + { PS3AV_RESBIT_720x576P << SHIFT_50, PS3AV_MODE_576P},
Why did you remove the C99 style initialisers?
--
Cheers,
Stephen Rothwell[EMAIL PROTECTED]
http://www.canb.auug.org.au/~sfr/
pgp5WmRIvYYjP.pgp
Description: PGP signature
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] ehea: Add kdump support
In message <[EMAIL PROTECTED]> you wrote: > Michael Ellerman wrote on 26.11.2007 09:16:28: > > Solutions that might be better: > > > > a) if there are a finite number of handles and we can predict their > > values, just delete them all in the kdump kernel before the driver > > loads. > > Guessing the values does not work, because of the handle structure > defined by the hypervisor. > > > b) if there are a small & finite number of handles, save their values > > in a device tree property and have the kdump kernel read them and > > delete them before the driver loads. > > 5*16*nr_ports+1+1= >82. a ML16 has 4 adapters with up to 16 ports, so the > number is not small anymore I assume this machine with a huge number of adapters has a huge amount of memory too! :-) > The device tree functions are currently not exported. We can add this. > If you crashdump to a new kernel, will it get the device tree > representation of the crashed kernel or of the initial one of open > firmware? The kexec tools userspace control this. Normally it just takes the current device tree plus some modifications (eg. initrd location changes). So provided the ehea driver export this info somewhere, it can be grabbed by the kexec tools and stuffed in the device tree of the new kernel. That being said, the proper place to have this would be original device tree. > > > c) if neither of those work, provide a minimal routine that _only_ > > deletes the handles in the crashed kernel. > > I would hope this has the highest chance to actually work. > For this we would have to add a proper notifier chain. > Do you agree? > > > d) > > Firmware change? But that's not something you will get very soon. > > Christoph R. > ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
PPC upstream kernel ignored DABR bug
Hi, this testcase: http://people.redhat.com/jkratoch/dabr-lost.c reproduces a PPC DABR kernel bug. The variable `variable' should not get modified as the thread modifying it should be caught by its DABR: $ ./dabr-lost TID 30914: DABR 0x10012a77 NIP 0x80f6ebb318 TID 30915: DABR 0x10012a77 NIP 0x80f6ebb318 TID 30916: DABR 0x10012a77 NIP 0x80f6ebb318 TID 30914: hitting the variable TID 30915: hitting the variable TID 30916: hitting the variable variable found = 30916, caught TID = 30914 TID 30916: DABR 0x10012a77 Variable got modified by a thread which has DABR still set! At the `variable found =' line the parent ptracer found the TID thread 30916 wrote the value into the variable - despite it had DABR alrady set before. As the behavior is dependent on the current weather I expect the scheduling matters there. It is important the target thread is in the `nanosleep' syscall. If you define WORKAROUND_SET_DABR_IN_SYSCALL in the testcase it busyloops in the userland and the bug gets no longer reproduced. I got it reproduced on a utrace-patched kernel on dual-CPU Power5 and Roland McGrath reported it reproduced on the vanilla upstream kernel on a Mac G5. Regards, Jan Kratochvil ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: 2.6.24-rc3: High CPU load -- hardware interrupts
Hi, I can confirm this situation. But it seems, that no one takes care of it Elimar -- Excellent day for drinking heavily. Spike the office water cooler;-) signature.asc Description: Digital signature ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: dtc: Flexible tree checking infrastructure (v2)
On Mon, Nov 26, 2007 at 04:13:32PM -0600, Jon Loeliger wrote: > So, like, the other day David Gibson mumbled: > > dtc: Flexible tree checking infrastructure > > > > Here, at last, is a substantial start on revising dtc's infrastructure > > for checking the tree; this is the rework I've been saying was > > necessary practically since dtc was first release. > > > > In the new model, we have a table of "check" structures, each with a > > name, references to checking functions, and status variables. Each > > check can (in principle) be individually switched off or on (as either > > a warning or error). Checks have a list of prerequisites, so if > > checks need to rely on results from earlier checks to make sense (or > > even to avoid crashing) they just need to list the relevant other > > checks there. > > > > For now, only the "structural" checks and the fixups for phandle > > references are converted to the new mechanism. The rather more > > involved semantic checks (which is where this new mechanism will > > really be useful) will have to be converted in future patches. > > > > At present, there's no user interface for turning on/off the checks - > > the -f option now forces output even if "error" level checks fail. > > Again, future patches will be needed to add the fine-grained control, > > but that should be quite straightforward with the infrastructure > > implemented here. > > > > Also adds a testcase for the handling of bad references, which catches > > a bug encountered while developing this patch. > > > > Signed-off-by: David Gibson <[EMAIL PROTECTED]> > > While I've Applied this one, it has introduced this: > > CC dtc.o > dtc.c: In function 'main': > dtc.c:199: warning: 'structure_ok' is used uninitialized in this function > > Followup easy patch? Crap. For some reason my compiler isn't giving that warning, so I missed that little bug :(. I'm away at the moment, I'll see what I can do. -- 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: dtc: Add valgrind support to testsuite
On Mon, Nov 26, 2007 at 04:10:39PM -0600, Jon Loeliger wrote: > So, like, the other day David Gibson mumbled: > > This patch adds some options to the run_tests.sh script allowing it to > > run all the testcases under valgrind to check for pointer corruption > > bugs and memory leaks. Invoking "make checkm" will run the testsuite > > with valgrind. > > > > It include a mechanism for specifying valgrind errors to be suppressed > > on a per-testcase basis, and adds a couple of such suppression files > > for the mangle-layout and open_pack testcases which dump for use by > > other testcases a buffer which may contain uninitialized sections. We > > use suppressions rather than initializing the buffer so that valgrind > > will catch any internal access s to the uninitialized data, which > > would be a bug. > > > > The patch also fixes one genuine bug caught by valgrind - > > _packblocks() in fdt_rw.c was using memcpy() where it should have been > > using memmove(). > > > > At present the valgrinding won't do anything useful for testcases > > invoked via a shell script - which includes all the dtc testcases. I > > plan to fix that later. > > > > Signed-off-by: David Gibson <[EMAIL PROTECTED]> > > Applied. > > Thanks, > jdl > > PS -- Clearly, I'm going to have to break down and install valgrind now. :-) Absolutely. Actually valgrind didn't show up much interesting on libfdt. Some preliminary investigations suggest it may find some problems in dtc, once I get the shell scripts to pass the valgrind option through properly. Be aware that running the testsuite under valgrind will take a long time. It goes from something like 1s without valgrind to 10 minutes on one of my machines. -- 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: time accounting problem (powerpc only?)
On Mon, Nov 26, 2007 at 05:23:13PM +0100, Johannes Berg wrote: > Contrary to what I claimed later in the thread, my 64-bit powerpc box > (quad-core G5) doesn't suffer from this problem. > > Does anybody have any idea? I don't even know how to debug it further. I'll see if I can grab an appropriate machine tomorrow and have a look at it. I think it's just an accounting bug, which is probably my fault :) Yours Tony linux.conf.auhttp://linux.conf.au/ || http://lca2008.linux.org.au/ Jan 28 - Feb 02 2008 The Australian Linux Technical Conference! ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Booting latest linux kernel(2.6.20) on MPC8548ECDS
On Nov 26, 2007, at 11:54 PM, rajendra prasad wrote: > Hi, > > I am using MPC8548ECDS board from CDS for my telecom application. I am > able to build 2.6.10 linux kernel and boot 2.6.10 kernel on > MPC8548ECDS board.When I take same configuration file and built > successfully but not able to boot on MPC8548E CDS board.I am using > u-boot-1.1.6 as boot loader.I came to know taht latest kernel is > booted with new procedure.Pls tell me the procedure how to boot > procedure. Ask this question on the linuxppc-dev list. You're more likely to get an answer. Its unclear, but you are trying to use the latest kernel on a MPC8548E CDS? - k ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
