* [PATCH] pata_mpc52xx: driver needs BMDMA
From: Wolfram Sang @ 2010-12-14 22:32 UTC (permalink / raw)
To: linuxppc-dev; +Cc: linux-ide, Jeff Garzik, linux-kernel
Found by this build-error:
drivers/ata/pata_mpc52xx.c: In function 'mpc52xx_ata_init_one':
drivers/ata/pata_mpc52xx.c:662: error: 'ata_bmdma_interrupt' undeclared (first use in this function)
So, move the Kconfig entry to the proper location.
Signed-off-by: Wolfram Sang <w.sang@pengutronix.de>
---
drivers/ata/Kconfig | 20 ++++++++++----------
drivers/ata/Makefile | 2 +-
2 files changed, 11 insertions(+), 11 deletions(-)
diff --git a/drivers/ata/Kconfig b/drivers/ata/Kconfig
index 11ec911..85756b8 100644
--- a/drivers/ata/Kconfig
+++ b/drivers/ata/Kconfig
@@ -128,16 +128,6 @@ config PDC_ADMA
If unsure, say N.
-config PATA_MPC52xx
- tristate "Freescale MPC52xx SoC internal IDE"
- depends on PPC_MPC52xx && PPC_BESTCOMM
- select PPC_BESTCOMM_ATA
- help
- This option enables support for integrated IDE controller
- of the Freescale MPC52xx SoC.
-
- If unsure, say N.
-
config PATA_OCTEON_CF
tristate "OCTEON Boot Bus Compact Flash support"
depends on CPU_CAVIUM_OCTEON
@@ -491,6 +481,16 @@ config PATA_MARVELL
If unsure, say N.
+config PATA_MPC52xx
+ tristate "Freescale MPC52xx SoC internal IDE"
+ depends on PPC_MPC52xx && PPC_BESTCOMM
+ select PPC_BESTCOMM_ATA
+ help
+ This option enables support for integrated IDE controller
+ of the Freescale MPC52xx SoC.
+
+ If unsure, say N.
+
config PATA_NETCELL
tristate "NETCELL Revolution RAID support"
depends on PCI
diff --git a/drivers/ata/Makefile b/drivers/ata/Makefile
index c501af5..2b67c90 100644
--- a/drivers/ata/Makefile
+++ b/drivers/ata/Makefile
@@ -11,7 +11,6 @@ obj-$(CONFIG_SATA_DWC) += sata_dwc_460ex.o
# SFF w/ custom DMA
obj-$(CONFIG_PDC_ADMA) += pdc_adma.o
-obj-$(CONFIG_PATA_MPC52xx) += pata_mpc52xx.o
obj-$(CONFIG_PATA_OCTEON_CF) += pata_octeon_cf.o
obj-$(CONFIG_SATA_QSTOR) += sata_qstor.o
obj-$(CONFIG_SATA_SX4) += sata_sx4.o
@@ -52,6 +51,7 @@ obj-$(CONFIG_PATA_IT821X) += pata_it821x.o
obj-$(CONFIG_PATA_JMICRON) += pata_jmicron.o
obj-$(CONFIG_PATA_MACIO) += pata_macio.o
obj-$(CONFIG_PATA_MARVELL) += pata_marvell.o
+obj-$(CONFIG_PATA_MPC52xx) += pata_mpc52xx.o
obj-$(CONFIG_PATA_NETCELL) += pata_netcell.o
obj-$(CONFIG_PATA_NINJA32) += pata_ninja32.o
obj-$(CONFIG_PATA_NS87415) += pata_ns87415.o
--
1.7.2.3
^ permalink raw reply related
* RapidIO: multiple mport support for QorIQ
From: Thomas Taranowski @ 2010-12-15 7:29 UTC (permalink / raw)
To: linuxppc-dev
I'm planning to add support for the multiple(2) mports supported by
the Freescale p2020 processor. I'm currently looking at the fsl layer
to add in support for multiple port enumeration, and work up from
there. It looks like the upper layers already have at least partial
support for this. My question is, are there any efforts already
ongoing I can hop in on so as not to duplicate effort? If not, I'll
just do it.
There is some divergance in respect to the memory map that is
non-trivial that I'm not sure how to handle, since it totally hoses
the common fsl_rio.c structures. I think I want to create a new set
that's p2020 specific, but has potential to be shared with the other
QorIQ series, so dumping the pseries-specific code into
platforms/pseries seems like a reasonable way to go. Thoughts?
Thanks!
Thomas Taranowski
Certified netburner consultant
baringforge.com
^ permalink raw reply
* RE: RapidIO: multiple mport support for QorIQ
From: Li Yang-R58472 @ 2010-12-15 8:04 UTC (permalink / raw)
To: Thomas Taranowski, linuxppc-dev@lists.ozlabs.org
In-Reply-To: <AANLkTinwP6kQvWjSO3cxNUqd7tx7dhGEShTdKQXj-+iD@mail.gmail.com>
PiBTdWJqZWN0OiBSYXBpZElPOiBtdWx0aXBsZSBtcG9ydCBzdXBwb3J0IGZvciBRb3JJUQ0KPiAN
Cj4gSSdtIHBsYW5uaW5nIHRvIGFkZCBzdXBwb3J0IGZvciB0aGUgbXVsdGlwbGUoMikgbXBvcnRz
IHN1cHBvcnRlZCBieSB0aGUgRnJlZXNjYWxlDQo+IHAyMDIwIHByb2Nlc3Nvci4gIEknbSBjdXJy
ZW50bHkgbG9va2luZyBhdCB0aGUgZnNsIGxheWVyIHRvIGFkZCBpbiBzdXBwb3J0IGZvcg0KPiBt
dWx0aXBsZSBwb3J0IGVudW1lcmF0aW9uLCBhbmQgd29yayB1cCBmcm9tIHRoZXJlLiAgSXQgbG9v
a3MgbGlrZSB0aGUgdXBwZXINCj4gbGF5ZXJzIGFscmVhZHkgaGF2ZSBhdCBsZWFzdCBwYXJ0aWFs
IHN1cHBvcnQgZm9yIHRoaXMuICBNeSBxdWVzdGlvbiBpcywgYXJlIHRoZXJlDQo+IGFueSBlZmZv
cnRzIGFscmVhZHkgb25nb2luZyBJIGNhbiBob3AgaW4gb24gc28gYXMgbm90IHRvIGR1cGxpY2F0
ZSBlZmZvcnQ/ICBJZiBub3QsDQo+IEknbGwganVzdCBkbyBpdC4NCj4gDQoNCkknbSBub3QgYXdh
cmUgb2Ygc29tZW9uZSB3b3JraW5nIG9uIHRoYXQuDQoNCj4gVGhlcmUgaXMgc29tZSBkaXZlcmdh
bmNlIGluIHJlc3BlY3QgdG8gdGhlIG1lbW9yeSBtYXAgdGhhdCBpcyBub24tdHJpdmlhbCB0aGF0
DQo+IEknbSBub3Qgc3VyZSBob3cgdG8gaGFuZGxlLCBzaW5jZSBpdCB0b3RhbGx5IGhvc2VzIHRo
ZSBjb21tb24gZnNsX3Jpby5jIHN0cnVjdHVyZXMuDQo+IEkgdGhpbmsgSSB3YW50IHRvIGNyZWF0
ZSBhIG5ldyBzZXQgdGhhdCdzIHAyMDIwIHNwZWNpZmljLCBidXQgaGFzIHBvdGVudGlhbCB0byBi
ZQ0KPiBzaGFyZWQgd2l0aCB0aGUgb3RoZXIgUW9ySVEgc2VyaWVzLCBzbyBkdW1waW5nIHRoZSBw
c2VyaWVzLXNwZWNpZmljIGNvZGUgaW50bw0KPiBwbGF0Zm9ybXMvcHNlcmllcyBzZWVtcyBsaWtl
IGEgcmVhc29uYWJsZSB3YXkgdG8gZ28uICBUaG91Z2h0cz8NCg0KVGhlIGR1YWwtcG9ydCBSSU8g
aXMgdmVyeSBjb21tb24gb24gUW9ySVEgY2hpcHMuICBJIHdvbid0IHN1Z2dlc3QgeW91IGFkZCBQ
MjAyMCBzcGVjaWZpYyBtZW1vcnkgbWFwIGZpbGUuICBUaGUgdHdvIHBvcnQgbWVtb3J5IG1hcCBz
aG91bGQgYWxzbyBiZSBjb21wYXRpYmxlIHdpdGggb25lIHBvcnQgZHJpdmVyLg0KDQotTGVvDQoN
Cg==
^ permalink raw reply
* Re: [PATCH V6 00/10] Add-Synopsys-DesignWare-HS-USB-OTG-driver
From: Neil Jones @ 2010-12-15 10:17 UTC (permalink / raw)
To: tmarri; +Cc: linux-usb, linuxppc-dev
In-Reply-To: <AANLkTinE1sPt4YQJGgW7-RHOsA8vF9HB-joSuryYFXpi@mail.gmail.com>
Hi,
I've looked at the patches but your email states there are 10 patches,
I can't see #1 and #10, only 2- 8 ??
It doesn't look like you have resolved the lockdep issues we have been
seeing, please get in contact as it
would be good to discuss our issues with this driver ( and our distain
for Synopsis ;-) ).
Cheers
Neil
On Mon, Dec 13, 2010 at 3:48 PM, Neil Jones <neiljay@gmail.com> wrote:
> Hi,
>
> We are currently using the latest version of this Synopsis IP in some
> of our customers SoC's.
>
> The latest hardware adds a new DMA mode which is less Interrupt
> intensive as well as a few other features.
>
> I have spent (and im still spending) a long time fixing up this driver
> to be linux standards compliant with the intention of pushing it
> upstream once complete, its still not ready yet.
>
> One of the major issues we had is the driver isn't SMP safe, I've not
> had chance to review your patches yet but have your run the driver
> with lock checking turned on ?
>
> Would it be possible to get the changes for the latest version of the
> IP merged into this driver, I can supply my current version as a
> reference.
>
> In my driver :
>
> Currently host support is working well and i've tested it with
> multiple devices and done the test outlined on
> http://www.linux-usb.org/usbtest/, the driver passed checkpatches and
> runs with lockdeps on and on a SMP system, Im still working on the
> device mode (PCD) part of the driver generally it works, but im still
> getting the odd lock dep warning and a panic on un-loading of certain
> gadget kernel modules. The only issue with our driver is I have not
> converted all the bitfield usage to macros so it might make diffing a
> pain.
>
> Cheers
>
> Neil
>
> On Fri, Dec 10, 2010 at 10:44 PM, Greg KH <greg@kroah.com> wrote:
>> On Wed, Dec 08, 2010 at 04:28:59PM -0800, tmarri@apm.com wrote:
>>> From: Tirumala Marri <tmarri@apm.com>
>>>
>>> v6:
>>> =C2=A01. Replaced register definitions and bit fields with macros.
>>> =C2=A02. Replace printks with dev_dbg or dev_err functions.
>>> =C2=A03. Cleanup some assignments.
>>> =C2=A04. Remove chip specific selections in Kconfig file.
>>
>> There are still a lot of checkpatch errors and warnings in these
>> patches. =C2=A0Patch 1-8 has:
>> =C2=A0 =C2=A0 =C2=A0 =C2=A0total: 64 errors, 126 warnings, 13905 lines c=
hecked
>>
>> Care to fix all of these up in your next submission? =C2=A0I can't take =
these
>> as-is, sorry.
>>
>> And, if you haven't run checkpatch.pl before, odds are you haven't run
>> 'sparse'. =C2=A0Please run that as well and resolve the issues it finds.
>>
>> thanks,
>>
>> greg k-h
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-usb" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at =C2=A0http://vger.kernel.org/majordomo-info.html
>>
>
^ permalink raw reply
* [PATCH v6] ppc44x:PHY fixup for USB on canyonlands board
From: Rupjyoti Sarmah @ 2010-12-15 12:27 UTC (permalink / raw)
To: linuxppc-dev, linux-kernel; +Cc: rsarmah
This fix is a reset for USB PHY that requires some amount of time for power to be stable on Canyonlands.
Signed-off-by: Rupjyoti Sarmah <rsarmah@apm.com>
---
changes from previous version:
-- error paths updated
-- leakage of a node corrected
-- iounmap is called on vaddr
arch/powerpc/boot/dts/canyonlands.dts | 11 +++
arch/powerpc/platforms/44x/44x.h | 4 +
arch/powerpc/platforms/44x/Kconfig | 1 -
arch/powerpc/platforms/44x/Makefile | 1 +
arch/powerpc/platforms/44x/canyonlands.c | 134 ++++++++++++++++++++++++++++
arch/powerpc/platforms/44x/ppc44x_simple.c | 1 -
6 files changed, 150 insertions(+), 2 deletions(-)
create mode 100644 arch/powerpc/platforms/44x/canyonlands.c
diff --git a/arch/powerpc/boot/dts/canyonlands.dts b/arch/powerpc/boot/dts/canyonlands.dts
index a303703..8ff1f3f 100644
--- a/arch/powerpc/boot/dts/canyonlands.dts
+++ b/arch/powerpc/boot/dts/canyonlands.dts
@@ -224,6 +224,11 @@
};
};
+ cpld@2,0 {
+ compatible = "amcc,ppc460ex-bcsr";
+ reg = <2 0x0 0x9>;
+ };
+
ndfc@3,0 {
compatible = "ibm,ndfc";
reg = <0x00000003 0x00000000 0x00002000>;
@@ -320,6 +325,12 @@
interrupts = <0x3 0x4>;
};
+ GPIO0: gpio@ef600b00 {
+ compatible = "ibm,ppc4xx-gpio";
+ reg = <0xef600b00 0x00000048>;
+ gpio-controller;
+ };
+
ZMII0: emac-zmii@ef600d00 {
compatible = "ibm,zmii-460ex", "ibm,zmii";
reg = <0xef600d00 0x0000000c>;
diff --git a/arch/powerpc/platforms/44x/44x.h b/arch/powerpc/platforms/44x/44x.h
index dbc4d2b..63f703e 100644
--- a/arch/powerpc/platforms/44x/44x.h
+++ b/arch/powerpc/platforms/44x/44x.h
@@ -4,4 +4,8 @@
extern u8 as1_readb(volatile u8 __iomem *addr);
extern void as1_writeb(u8 data, volatile u8 __iomem *addr);
+#define GPIO0_OSRH 0xC
+#define GPIO0_TSRH 0x14
+#define GPIO0_ISR1H 0x34
+
#endif /* __POWERPC_PLATFORMS_44X_44X_H */
diff --git a/arch/powerpc/platforms/44x/Kconfig b/arch/powerpc/platforms/44x/Kconfig
index 0f979c5..f485fc5 100644
--- a/arch/powerpc/platforms/44x/Kconfig
+++ b/arch/powerpc/platforms/44x/Kconfig
@@ -115,7 +115,6 @@ config CANYONLANDS
bool "Canyonlands"
depends on 44x
default n
- select PPC44x_SIMPLE
select 460EX
select PCI
select PPC4xx_PCI_EXPRESS
diff --git a/arch/powerpc/platforms/44x/Makefile b/arch/powerpc/platforms/44x/Makefile
index 82ff326..6854e73 100644
--- a/arch/powerpc/platforms/44x/Makefile
+++ b/arch/powerpc/platforms/44x/Makefile
@@ -6,3 +6,4 @@ obj-$(CONFIG_WARP) += warp.o
obj-$(CONFIG_XILINX_VIRTEX_5_FXT) += virtex.o
obj-$(CONFIG_XILINX_ML510) += virtex_ml510.o
obj-$(CONFIG_ISS4xx) += iss4xx.o
+obj-$(CONFIG_CANYONLANDS)+= canyonlands.o
diff --git a/arch/powerpc/platforms/44x/canyonlands.c b/arch/powerpc/platforms/44x/canyonlands.c
new file mode 100644
index 0000000..afc5e8e
--- /dev/null
+++ b/arch/powerpc/platforms/44x/canyonlands.c
@@ -0,0 +1,134 @@
+/*
+ * This contain platform specific code for APM PPC460EX based Canyonlands
+ * board.
+ *
+ * Copyright (c) 2010, Applied Micro Circuits Corporation
+ * Author: Rupjyoti Sarmah <rsarmah@apm.com>
+ *
+ * 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.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston,
+ * MA 02111-1307 USA
+ *
+ */
+#include <linux/kernel.h>
+#include <linux/init.h>
+#include <asm/pci-bridge.h>
+#include <asm/ppc4xx.h>
+#include <asm/udbg.h>
+#include <asm/uic.h>
+#include <linux/of_platform.h>
+#include <linux/delay.h>
+#include "44x.h"
+
+#define BCSR_USB_EN 0x11
+
+static __initdata struct of_device_id ppc460ex_of_bus[] = {
+ { .compatible = "ibm,plb4", },
+ { .compatible = "ibm,opb", },
+ { .compatible = "ibm,ebc", },
+ { .compatible = "simple-bus", },
+ {},
+};
+
+static int __init ppc460ex_device_probe(void)
+{
+ of_platform_bus_probe(NULL, ppc460ex_of_bus, NULL);
+
+ return 0;
+}
+machine_device_initcall(canyonlands, ppc460ex_device_probe);
+
+/* Using this code only for the Canyonlands board. */
+
+static int __init ppc460ex_probe(void)
+{
+ unsigned long root = of_get_flat_dt_root();
+ if (of_flat_dt_is_compatible(root, "amcc,canyonlands")) {
+ ppc_pci_set_flags(PPC_PCI_REASSIGN_ALL_RSRC);
+ return 1;
+ }
+ return 0;
+}
+
+/* USB PHY fixup code on Canyonlands kit. */
+
+static int __init ppc460ex_canyonlands_fixup(void)
+{
+ u8 __iomem *bcsr ;
+ void __iomem *vaddr;
+ struct device_node *np;
+ int ret = 0;
+
+ np = of_find_compatible_node(NULL, NULL, "amcc,ppc460ex-bcsr");
+ if (!np) {
+ printk(KERN_ERR "failed did not find amcc, ppc460ex bcsr node\n");
+ return -ENODEV;
+ }
+
+ bcsr = of_iomap(np, 0);
+ of_node_put(np);
+
+ if (!bcsr) {
+ printk(KERN_CRIT "Could not remap bcsr\n");
+ ret = -ENODEV;
+ goto err_bcsr;
+ }
+
+ np = of_find_compatible_node(NULL, NULL, "ibm,ppc4xx-gpio");
+ if (!np) {
+ printk(KERN_ERR "failed did not find ibm,ppc4xx-gpio node\n");
+ return -ENODEV;
+ }
+
+ vaddr = of_iomap(np, 0);
+ of_node_put(np);
+
+ if (!vaddr) {
+ printk(KERN_CRIT "Could not get gpio node address\n");
+ ret = -ENODEV;
+ goto err_gpio;
+ }
+ /* Disable USB, through the BCSR7 bits */
+ setbits8(&bcsr[7], BCSR_USB_EN);
+
+ /* Wait for a while after reset */
+ msleep(100);
+
+ /* Enable USB here */
+ clrbits8(&bcsr[7], BCSR_USB_EN);
+
+ /*
+ * Configure multiplexed gpio16 and gpio19 as alternate1 output
+ * source after USB reset. In this configuration gpio16 will be
+ * USB2HStop and gpio19 will be USB2DStop. For more details refer to
+ * table 34-7 of PPC460EX user manual.
+ */
+ setbits32((vaddr + GPIO0_OSRH), 0x42000000);
+ setbits32((vaddr + GPIO0_TSRH), 0x42000000);
+err_gpio:
+ iounmap(vaddr);
+err_bcsr:
+ iounmap(bcsr);
+ return ret;
+}
+machine_device_initcall(canyonlands, ppc460ex_canyonlands_fixup);
+define_machine(canyonlands) {
+ .name = "Canyonlands",
+ .probe = ppc460ex_probe,
+ .progress = udbg_progress,
+ .init_IRQ = uic_init_tree,
+ .get_irq = uic_get_irq,
+ .restart = ppc4xx_reset_system,
+ .calibrate_decr = generic_calibrate_decr,
+};
diff --git a/arch/powerpc/platforms/44x/ppc44x_simple.c b/arch/powerpc/platforms/44x/ppc44x_simple.c
index 7ddcba3..c81c19c 100644
--- a/arch/powerpc/platforms/44x/ppc44x_simple.c
+++ b/arch/powerpc/platforms/44x/ppc44x_simple.c
@@ -53,7 +53,6 @@ static char *board[] __initdata = {
"amcc,arches",
"amcc,bamboo",
"amcc,bluestone",
- "amcc,canyonlands",
"amcc,glacier",
"ibm,ebony",
"amcc,eiger",
--
1.5.6.3
^ permalink raw reply related
* Unbalanced enable for IRQ => phy_change
From: Jean-Michel Hautbois @ 2010-12-15 13:11 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <AANLkTi=vd4J8DfnLgPROrNC2Q-jxSCsrv=nv371Rhq5i@mail.gmail.com>
Hi !
I am currently using a MPC8548 PowerPC board, and I have encountered
the following problem :
[ =C2=A0 19.867849] Unbalanced enable for IRQ 48
[ =C2=A0 19.867855] ------------[ cut here ]------------
[ =C2=A0 19.873819] Badness at /.../kernel/irq/manage.c:174
[ =C2=A0 19.873823] NIP: c0044acc LR: c0044acc CTR: c0018480
[ =C2=A0 19.873828] REGS: dfc2be60 TRAP: 0700 =C2=A0 Tainted: P
(2.6.24.7_www.men.de_1.1)
[ =C2=A0 19.873831] MSR: 00021000 <ME> =C2=A0CR: 24000022 =C2=A0XER: 000000=
00
[ =C2=A0 19.873839] TASK =3D dfc204e0[5] 'events/0' THREAD: dfc2a000
[ =C2=A0 19.873842] GPR00: c0044acc dfc2bf10 dfc204e0 0000002f 00021000
00000000 00000000 00000000
[ =C2=A0 19.873854] GPR08: 00000034 ffffffff 0000574e de821b20 24000024
100607bc 00008000 00001020
[ =C2=A0 19.873865] GPR16: c0447b44 c0447b2c 00fff018 033327d2 00000008
c044b2c8 c048d1a8 c044b300
[ =C2=A0 19.873877] GPR24: dfc206a0 dfc204e0 dfc01f30 dfc2a000 00029000
c04cb714 00000030 c04cb6e4
[ =C2=A0 19.873890] NIP [c0044acc] enable_irq+0x6c/0xdc
[ =C2=A0 19.873903] LR [c0044acc] enable_irq+0x6c/0xdc
[ =C2=A0 19.873908] Call Trace:
[ =C2=A0 19.873911] [dfc2bf10] [c0044acc] enable_irq+0x6c/0xdc (unreliable)
[ =C2=A0 19.873919] [dfc2bf30] [c0217868] phy_change+0x74/0xe4
[ =C2=A0 19.873926] [dfc2bf50] [c002fb2c] run_workqueue+0xc4/0x15c
[ =C2=A0 19.873933] [dfc2bf90] [c002ffb0] worker_thread+0x74/0xd4
[ =C2=A0 19.873940] [dfc2bfd0] [c0034360] kthread+0x48/0x84
[ =C2=A0 19.873946] [dfc2bff0] [c00047bc] kernel_thread+0x44/0x60
[ =C2=A0 19.873953] Instruction dump:
[ =C2=A0 19.873957] 7fe04a14 3bbf0030 7fa3eb78 483a9461 813f001c 7c7c1b78
2f890000 409e0038
[ =C2=A0 19.873968] 3c60c045 7fc4f378 3863f1d4 4bfd9129 <0fe00000> 7fa3eb78
7f84e378 483a91a5
When looking at the phy_change function in drivers/net/phy/phy.c I
have noticed something quite strange :
We are calling phy_disable_interrupts() and after some operations, enable_i=
rq().
The first thing I thought about is why aren't we calling
disable_irq/enable_irq or phy_disable_interrupts/phy_enable_interrupts
but a mix ?
Next, I took a more deep look at phy_disable_interrupts() and
sepcifically at the phy_config_interrupt() function :
=C2=A0 =C2=A0 =C2=A0 =C2=A0int err =3D 0;
=C2=A0 =C2=A0 =C2=A0 =C2=A0phydev->interrupts =3D interrupts;
=C2=A0 =C2=A0 =C2=A0 =C2=A0if (phydev->drv->config_intr)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0err =3D phydev->drv-=
>config_intr(phydev);
=C2=A0 =C2=A0 =C2=A0 =C2=A0return err;
If phydev->drv->config_intr is not implemented (this is my use case :
I am using the drivers/net/gianfar.c driver), then, nothing will be
done, and there is no disable_irq() call.
I don't know what is better : using disable_irq/enable_irq or the phy
specific functions, but I think that we should avoid using a mix...
Am I wrong ?
Thanks in advance,
Regards,
JM
^ permalink raw reply
* Re: Force FB off
From: Jan Engelhardt @ 2010-12-15 13:39 UTC (permalink / raw)
To: Dave Airlie; +Cc: linux-fbdev, linuxppc-dev
In-Reply-To: <AANLkTimEh+2rEFuq7q+wLcfHw_UKKHVipC0t7mFwSzx8@mail.gmail.com>
On Tuesday 2010-12-14 21:18, Dave Airlie wrote:
>On Wed, Dec 15, 2010 at 3:41 AM, Jan Engelhardt <jengelh@medozas.de> wrote:
>
>>
>>booting with video=off nor video=i915:off has any effect on skipping
>>FB. What is the correct option to stop FB from taking over my boot
>>consoles?
>
>For KMS its not fb taking over its the drm i915 driver, nomodeset will
>stop it however X will no longer work since it relies on the kernel
>driver.
That would make sense. Furthermore I discovered that video=vesafb:off
also has no effect, but here it is clear because the source code ignores
the return value of fb_get_options, and so ignores any off command.
The real strange thing is that video=offb:off on an Apple Xserve G5
PPC64, while probably skipping OFFB initialization, still ends up in a
640x480 mode with a 8x16 font instead of retaining the PROM
console/font.
^ permalink raw reply
* RE: RapidIO: multiple mport support for QorIQ
From: Bounine, Alexandre @ 2010-12-15 14:02 UTC (permalink / raw)
To: Thomas Taranowski, linuxppc-dev
In-Reply-To: <AANLkTinwP6kQvWjSO3cxNUqd7tx7dhGEShTdKQXj-+iD@mail.gmail.com>
Thomas Taranowski wrote:
=20
> I'm planning to add support for the multiple(2) mports supported by
> the Freescale p2020 processor. I'm currently looking at the fsl layer
> to add in support for multiple port enumeration, and work up from
> there. It looks like the upper layers already have at least partial
> support for this. My question is, are there any efforts already
> ongoing I can hop in on so as not to duplicate effort? If not, I'll
> just do it.
>=20
I am working on multiple port support in RapidIO subsystem.
This work is not related to FSL driver - I have a PCI RapidIO controller
which will be added into the subsystem as well. If everything goes as
planned, I hope to publish the first version of new patches in the
second half of January.
=20
=20
^ permalink raw reply
* Re: Force FB off
From: Rui Santos @ 2010-12-15 14:51 UTC (permalink / raw)
To: Jan Engelhardt; +Cc: linuxppc-dev, linux-fbdev, Dave Airlie
In-Reply-To: <alpine.LNX.2.01.1012151430220.2052@obet.zrqbmnf.qr>
Hi Jan,
You could boot with "vga=normal i915.modeset=0". This will provide
you with a 25x80 console.
You can also use vga=ext for an somethingx50 console.
Regards,
Rui
On 15-12-2010 13:39, Jan Engelhardt wrote:
> On Tuesday 2010-12-14 21:18, Dave Airlie wrote:
>> On Wed, Dec 15, 2010 at 3:41 AM, Jan Engelhardt<jengelh@medozas.de> wrote:
>>
>>> booting with video=off nor video=i915:off has any effect on skipping
>>> FB. What is the correct option to stop FB from taking over my boot
>>> consoles?
>> For KMS its not fb taking over its the drm i915 driver, nomodeset will
>> stop it however X will no longer work since it relies on the kernel
>> driver.
> That would make sense. Furthermore I discovered that video=vesafb:off
> also has no effect, but here it is clear because the source code ignores
> the return value of fb_get_options, and so ignores any off command.
>
> The real strange thing is that video=offb:off on an Apple Xserve G5
> PPC64, while probably skipping OFFB initialization, still ends up in a
> 640x480 mode with a 8x16 font instead of retaining the PROM
> console/font.
> --
> To unsubscribe from this list: send the line "unsubscribe linux-fbdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
>
--
Cumprimentos
*Rui Santos*
Email: rsantos@grupopie.com <mailto:rsantos@grupopie.com>
^ permalink raw reply
* Re: [PATCH 3/5] of/device: Make of_get_next_child() check status properties
From: Hollis Blanchard @ 2010-12-15 18:35 UTC (permalink / raw)
To: Michael Ellerman, Scott Wood, devicetree-discuss, linuxppc-dev
In-Reply-To: <20101209030924.GC11856@yookeroo>
On Wed, Dec 8, 2010 at 7:09 PM, David Gibson
<david@gibson.dropbear.id.au> wrote:
> On Thu, Dec 09, 2010 at 12:33:22PM +1100, Michael Ellerman wrote:
>> On Wed, 2010-12-08 at 15:01 -0600, Scott Wood wrote:
>> > On Wed, 8 Dec 2010 11:29:44 -0800
>> > Deepak Saxena <deepak_saxena@mentor.com> wrote:
>> >
>> > > We only return the next child if the device is available.
>> > >
>> > > Signed-off-by: Hollis Blanchard <hollis_blanchard@mentor.com>
>> > > Signed-off-by: Deepak Saxena <deepak_saxena@mentor.com>
>> > > ---
>> > > =A0drivers/of/base.c | =A0 =A04 +++-
>> > > =A01 files changed, 3 insertions(+), 1 deletions(-)
>> > >
>> > > diff --git a/drivers/of/base.c b/drivers/of/base.c
>> > > index 5d269a4..81b2601 100644
>> > > --- a/drivers/of/base.c
>> > > +++ b/drivers/of/base.c
>> > > @@ -321,6 +321,8 @@ struct device_node *of_get_next_parent(struct de=
vice_node *node)
>> > > =A0 *
>> > > =A0 * =A0 =A0 =A0 Returns a node pointer with refcount incremented, =
use
>> > > =A0 * =A0 =A0 =A0 of_node_put() on it when done.
>> > > + *
>> > > + * =A0 =A0 =A0 Does not return nodes marked unavailable by a status=
property.
>> > > =A0 */
>> > > =A0struct device_node *of_get_next_child(const struct device_node *n=
ode,
>> > > =A0 struct device_node *prev)
>> > > @@ -330,7 +332,7 @@ struct device_node *of_get_next_child(const stru=
ct device_node *node,
>> > > =A0 read_lock(&devtree_lock);
>> > > =A0 next =3D prev ? prev->sibling : node->child;
>> > > =A0 for (; next; next =3D next->sibling)
>> > > - =A0 =A0 =A0 =A0 if (of_node_get(next))
>> > > + =A0 =A0 =A0 =A0 if (of_device_is_available(next) && of_node_get(ne=
xt))
>> > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 break;
>> > > =A0 of_node_put(prev);
>> > > =A0 read_unlock(&devtree_lock);
>> >
>> > This seems like too low-level a place to put this. =A0Some code may kn=
ow
>> > how to un-disable a device in certain situations, or it may be part of
>> > debug code trying to dump the whole device tree, etc. =A0Looking
>> > further[1], I see a raw version of this function, but not other things
>> > like of_find_compatible_node.
>>
>> Yeah I agree. I think we'll eventually end up with __ versions of all or
>> lots of them. Not to mention there might be cases you've missed where
>> code expects to see unavailable nodes. The right approach is to add
>> _new_ routines that don't return unavailable nodes, and convert code
>> that you know wants to use them.
>
> Actually, I don't think we really want these status-skipping
> iterators at all. =A0The device tree iterators should give us the device
> tree, as it is. =A0Those old-style drivers which seach for a node rather
> than using the bus probing logic can keep individual checks of the
> status property until they're converted to the new scheme.
So the patch should look something like this?
@@ -321,6 +321,8 @@ struct device_node *of_get_next_parent(struct
device_node *node)
*
* Returns a node pointer with refcount incremented, use
* of_node_put() on it when done.
+ *
+ * Do not use this function.
*/
struct device_node *of_get_next_child(const struct device_node *node,
struct device_node *prev)
...
+ struct device_node *of_get_next_available_child(const struct
device_node *node,
+ struct device_node *prev)
+ ...
+ }
And then (almost) all the of_get_next_child() sites should be changed
to call the new function?
-Hollis
^ permalink raw reply
* Re: Force FB off
From: Geert Uytterhoeven @ 2010-12-15 18:40 UTC (permalink / raw)
To: Jan Engelhardt; +Cc: linuxppc-dev, linux-fbdev, Dave Airlie
In-Reply-To: <alpine.LNX.2.01.1012151430220.2052@obet.zrqbmnf.qr>
On Wed, Dec 15, 2010 at 14:39, Jan Engelhardt <jengelh@medozas.de> wrote:
> On Tuesday 2010-12-14 21:18, Dave Airlie wrote:
>>On Wed, Dec 15, 2010 at 3:41 AM, Jan Engelhardt <jengelh@medozas.de> wrot=
e:
>>
>>>
>>>booting with video=3Doff nor video=3Di915:off has any effect on skipping
>>>FB. What is the correct option to stop FB from taking over my boot
>>>consoles?
>>
>>For KMS its not fb taking over its the drm i915 driver, nomodeset will
>>stop it however X will no longer work since it relies on the kernel
>>driver.
>
> That would make sense. Furthermore I discovered that video=3Dvesafb:off
> also has no effect, but here it is clear because the source code ignores
> the return value of fb_get_options, and so ignores any off command.
>
> The real strange thing is that video=3Doffb:off on an Apple Xserve G5
> PPC64, while probably skipping OFFB initialization, still ends up in a
> 640x480 mode with a 8x16 font instead of retaining the PROM
> console/font.
That just means something different than offb is driving the console now.
What does /proc/fb say?
Gr{oetje,eeting}s,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k=
.org
In personal conversations with technical people, I call myself a hacker. Bu=
t
when I'm talking to journalists I just say "programmer" or something like t=
hat.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0=C2=A0 -- Linus Torvalds
^ permalink raw reply
* Re: RapidIO: multiple mport support for QorIQ
From: Thomas Taranowski @ 2010-12-15 20:40 UTC (permalink / raw)
To: Li Yang-R58472; +Cc: linuxppc-dev@lists.ozlabs.org
In-Reply-To: <3F607A5180246847A760FD34122A1E0503B1D8@039-SN1MPN1-003.039d.mgd.msft.net>
>
>> There is some divergance in respect to the memory map that is non-trivia=
l that
>> I'm not sure how to handle, since it totally hoses the common fsl_rio.c =
structures.
>> I think I want to create a new set that's p2020 specific, but has potent=
ial to be
>> shared with the other QorIQ series, so dumping the pseries-specific code=
into
>> platforms/pseries seems like a reasonable way to go. =A0Thoughts?
>
> The dual-port RIO is very common on QorIQ chips. =A0I won't suggest you a=
dd P2020 specific memory map file. =A0The two port memory map should also b=
e compatible with one port driver.
>
Should be, but isn't. For the most part the new registers introduced
match up with the pad present in the previous processors, but not for
the atmu registers. They are wildly inconsistent, and I don't see a
way to make them compatible.
# The current implementation
struct rio_atmu_regs {
u32 rowtar;
u32 rowtear;
u32 rowbar;
u32 pad2;
u32 rowar;
u32 pad3[3];
};
# The QorIQ p2020 register set.
struct rio_atmu_outb_window_regs {
u32 rowtar0; /* Outbound window translation address register 0 *
u32 rowtear0; /* Outbound window ext. address register 0 */
u32 pad; /* There is no rowbar0. Believe it. */
u32 rowar0; /* Outbound window attribute register 1 */
u32 rowtar1; /* Outbound window translation address register 1 *
u32 rowtear1; /* Outbound window ext. translation address registe
u32 rowbar1; /* Outbound window base address register 1 */
u32 rowar1; /* Outbound window attributes register 1 */
u32 rowsr1[3]; /* Outbound window segment register 1 */
};
struct rio_atmu_inb_window_regs {
u32 iwtar; /* Inbound window translation address register. */
u32 iwbar; /* Inbound window base address register. */
u32 iwar; /* Ibound window attribute register. */
};
struct rio_atmu_regs {
rio_atmu_outb_window_regs outb_window[8]; /* window 1-8, upcounting
rio atmu_inb_window_regs inb_window[4] /* window 4-1, downcounting
};
> -Leo
>
>
^ permalink raw reply
* Re: [PATCH 3/5] of/device: Make of_get_next_child() check status properties
From: Michael Ellerman @ 2010-12-15 22:40 UTC (permalink / raw)
To: Hollis Blanchard; +Cc: Scott Wood, devicetree-discuss, linuxppc-dev
In-Reply-To: <AANLkTimPhs4AZ74e4SZfkyboeDJQaoybL+FGmwy_+bLJ@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 3511 bytes --]
On Wed, 2010-12-15 at 10:35 -0800, Hollis Blanchard wrote:
> On Wed, Dec 8, 2010 at 7:09 PM, David Gibson
> <david@gibson.dropbear.id.au> wrote:
> > On Thu, Dec 09, 2010 at 12:33:22PM +1100, Michael Ellerman wrote:
> >> On Wed, 2010-12-08 at 15:01 -0600, Scott Wood wrote:
> >> > On Wed, 8 Dec 2010 11:29:44 -0800
> >> > Deepak Saxena <deepak_saxena@mentor.com> wrote:
> >> >
> >> > > We only return the next child if the device is available.
> >> > >
> >> > > Signed-off-by: Hollis Blanchard <hollis_blanchard@mentor.com>
> >> > > Signed-off-by: Deepak Saxena <deepak_saxena@mentor.com>
> >> > > ---
> >> > > drivers/of/base.c | 4 +++-
> >> > > 1 files changed, 3 insertions(+), 1 deletions(-)
> >> > >
> >> > > diff --git a/drivers/of/base.c b/drivers/of/base.c
> >> > > index 5d269a4..81b2601 100644
> >> > > --- a/drivers/of/base.c
> >> > > +++ b/drivers/of/base.c
> >> > > @@ -321,6 +321,8 @@ struct device_node *of_get_next_parent(struct device_node *node)
> >> > > *
> >> > > * Returns a node pointer with refcount incremented, use
> >> > > * of_node_put() on it when done.
> >> > > + *
> >> > > + * Does not return nodes marked unavailable by a status property.
> >> > > */
> >> > > struct device_node *of_get_next_child(const struct device_node *node,
> >> > > struct device_node *prev)
> >> > > @@ -330,7 +332,7 @@ struct device_node *of_get_next_child(const struct device_node *node,
> >> > > read_lock(&devtree_lock);
> >> > > next = prev ? prev->sibling : node->child;
> >> > > for (; next; next = next->sibling)
> >> > > - if (of_node_get(next))
> >> > > + if (of_device_is_available(next) && of_node_get(next))
> >> > > break;
> >> > > of_node_put(prev);
> >> > > read_unlock(&devtree_lock);
> >> >
> >> > This seems like too low-level a place to put this. Some code may know
> >> > how to un-disable a device in certain situations, or it may be part of
> >> > debug code trying to dump the whole device tree, etc. Looking
> >> > further[1], I see a raw version of this function, but not other things
> >> > like of_find_compatible_node.
> >>
> >> Yeah I agree. I think we'll eventually end up with __ versions of all or
> >> lots of them. Not to mention there might be cases you've missed where
> >> code expects to see unavailable nodes. The right approach is to add
> >> _new_ routines that don't return unavailable nodes, and convert code
> >> that you know wants to use them.
> >
> > Actually, I don't think we really want these status-skipping
> > iterators at all. The device tree iterators should give us the device
> > tree, as it is. Those old-style drivers which seach for a node rather
> > than using the bus probing logic can keep individual checks of the
> > status property until they're converted to the new scheme.
>
> So the patch should look something like this?
>
> @@ -321,6 +321,8 @@ struct device_node *of_get_next_parent(struct
> device_node *node)
> *
> * Returns a node pointer with refcount incremented, use
> * of_node_put() on it when done.
> + *
> + * Do not use this function.
> */
> struct device_node *of_get_next_child(const struct device_node *node,
> struct device_node *prev)
Haha. No it should say "this function doesn't lie to you".
And the patch should say "this patch _doesn't_ subtly change all callers
of of_get_next_child() without carefully auditing them".
cheers
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply
* Re: [PATCH V6 00/10] Add-Synopsys-DesignWare-HS-USB-OTG-driver
From: Tirumala Marri @ 2010-12-15 22:50 UTC (permalink / raw)
To: Neil Jones; +Cc: linux-usb, linuxppc-dev
In-Reply-To: <AANLkTikOituTX-gTQrr7cr2bXdbvf=A2UqHX0yVf8UDP@mail.gmail.com>
On Wed, Dec 15, 2010 at 2:17 AM, Neil Jones <neiljay@gmail.com> wrote:
> Hi,
>
> I've looked at the patches but your email states there are 10 patches,
> I can't see #1 and #10, only 2- 8 ??
>
> It doesn't look like you have resolved the lockdep issues we have been
> seeing, please get in contact as it
> would be good to discuss our issues with this driver ( and our distain
> for Synopsis ;-) ).
>
> Cheers
>
> Neil
>
> On Mon, Dec 13, 2010 at 3:48 PM, Neil Jones <neiljay@gmail.com> wrote:
>> Hi,
>>
>> We are currently using the latest version of this Synopsis IP in some
>> of our customers SoC's.
>>
>> The latest hardware adds a new DMA mode which is less Interrupt
>> intensive as well as a few other features.
>>
>> I have spent (and im still spending) a long time fixing up this driver
>> to be linux standards compliant with the intention of pushing it
>> upstream once complete, its still not ready yet.
>>
>> One of the major issues we had is the driver isn't SMP safe, I've not
>> had chance to review your patches yet but have your run the driver
>> with lock checking turned on ?
>>
>> Would it be possible to get the changes for the latest version of the
>> IP merged into this driver, I can supply my current version as a
>> reference.
>>
>> In my driver :
>>
>> Currently host support is working well and i've tested it with
>> multiple devices and done the test outlined on
>> http://www.linux-usb.org/usbtest/, the driver passed checkpatches and
>> runs with lockdeps on and on a SMP system, Im still working on the
>> device mode (PCD) part of the driver generally it works, but im still
>> getting the odd lock dep warning and a panic on un-loading of certain
>> gadget kernel modules. The only issue with our driver is I have not
>> converted all the bitfield usage to macros so it might make diffing a
>> pain.
>>
>> Cheers
>>
>> Neil
Hi,
Sorry for the late reply, I was busy working on the patch. Idea is to
functional patch for PPC architecture initially and extend that to SMP
and resolve other bugs if there at all. To push all the features in
one go is kind
of hard and increases the size of patches.
Sure let us discuss further if there are know issues need to be resolved
in the driver.
Thanks,
Marri
^ permalink raw reply
* Re: RapidIO: multiple mport support for QorIQ
From: Thomas Taranowski @ 2010-12-16 5:22 UTC (permalink / raw)
To: Li Yang-R58472; +Cc: linuxppc-dev@lists.ozlabs.org
In-Reply-To: <AANLkTi=OpBXJ04snjY2XGECCRv3zX-zomj4+r=UgeyT7@mail.gmail.com>
I actually take most of this back, it looks like there is a path
available so as not to fork the driver for the pseries.
Thomas Taranowski
Certified netburner consultant
baringforge.com
On Wed, Dec 15, 2010 at 12:40 PM, Thomas Taranowski <tom@baringforge.com> w=
rote:
>>
>>> There is some divergance in respect to the memory map that is non-trivi=
al that
>>> I'm not sure how to handle, since it totally hoses the common fsl_rio.c=
structures.
>>> I think I want to create a new set that's p2020 specific, but has poten=
tial to be
>>> shared with the other QorIQ series, so dumping the pseries-specific cod=
e into
>>> platforms/pseries seems like a reasonable way to go. =A0Thoughts?
>>
>> The dual-port RIO is very common on QorIQ chips. =A0I won't suggest you =
add P2020 specific memory map file. =A0The two port memory map should also =
be compatible with one port driver.
>>
>
> Should be, but isn't. =A0For the most part the new registers introduced
> match up with the pad present in the previous processors, but not for
> the atmu registers. =A0They are wildly inconsistent, and I don't see a
> way to make them compatible.
>
> # The current implementation
> struct rio_atmu_regs {
> =A0 =A0 =A0 =A0u32 rowtar;
> =A0 =A0 =A0 =A0u32 rowtear;
> =A0 =A0 =A0 =A0u32 rowbar;
> =A0 =A0 =A0 =A0u32 pad2;
> =A0 =A0 =A0 =A0u32 rowar;
> =A0 =A0 =A0 =A0u32 pad3[3];
> };
>
> # The QorIQ p2020 register set.
> struct rio_atmu_outb_window_regs {
> =A0 =A0u32 rowtar0; =A0 =A0/* Outbound window translation address registe=
r 0 *
> =A0 =A0u32 rowtear0; =A0 /* Outbound window ext. address register 0 */
> =A0 =A0u32 pad; =A0 =A0 =A0 =A0/* There is no rowbar0. Believe it. */
> =A0 =A0u32 rowar0; =A0 =A0 /* Outbound window attribute register 1 */
> =A0 =A0u32 rowtar1; =A0 =A0/* Outbound window translation address registe=
r 1 *
> =A0 =A0u32 rowtear1; =A0 /* Outbound window ext. translation address regi=
ste
> =A0 =A0u32 rowbar1; =A0 =A0/* Outbound window base address register 1 */
> =A0 =A0u32 rowar1; =A0 =A0 /* Outbound window attributes register 1 */
> =A0 =A0u32 rowsr1[3]; =A0/* Outbound window segment =A0register 1 */
> };
>
> struct rio_atmu_inb_window_regs {
> =A0 =A0u32 iwtar; =A0 =A0 =A0/* Inbound window translation address regist=
er. */
> =A0 =A0u32 iwbar; =A0 =A0 =A0/* Inbound window base address register. */
> =A0 =A0u32 iwar; =A0 =A0 =A0 /* Ibound window attribute register. */
> };
>
> struct rio_atmu_regs {
> =A0 =A0rio_atmu_outb_window_regs outb_window[8]; /* window 1-8, upcountin=
g
> =A0 =A0rio atmu_inb_window_regs =A0inb_window[4] /* window 4-1, downcount=
ing
> };
>
>
>
>
>> -Leo
>>
>>
>
^ permalink raw reply
* Re: [PATCH v4 5/5] fsl-diu-fb: Support setting display mode using EDID
From: Timur Tabi @ 2010-12-16 16:47 UTC (permalink / raw)
To: Anatolij Gustschin; +Cc: linuxppc-dev, linux-fbdev, devicetree-discuss
In-Reply-To: <1279893639-24333-6-git-send-email-agust@denx.de>
On Fri, Jul 23, 2010 at 9:00 AM, Anatolij Gustschin <agust@denx.de> wrote:
> Adds support for encoding display mode information
> in the device tree using verbatim EDID block.
>
> If the EDID entry in the DIU node is present, the
> driver will build mode database using EDID data
> and allow setting the display modes from this database.
> Otherwise display mode will be set using mode
> entries from driver's internal database as usual.
>
> This patch also updates device tree bindings.
>
> Signed-off-by: Anatolij Gustschin <agust@denx.de>
> Acked-by: Timur Tabi <timur@freescale.com>
> Cc: devicetree-discuss@lists.ozlabs.org
Anatolij,
I know this patch is old, but I'm now getting back to working on the
DIU driver. One question I have: why are you reading the EDID data
from the device tree? Why not just read it directly from the device
using I2C? Who is supposed to put the EDID data into the device tree
in the first place?
--
Timur Tabi
Linux kernel developer at Freescale
^ permalink raw reply
* Re: [PATCH v4 5/5] fsl-diu-fb: Support setting display mode using EDID
From: Grant Likely @ 2010-12-16 16:53 UTC (permalink / raw)
To: Timur Tabi
Cc: linuxppc-dev, linux-fbdev, Anatolij Gustschin, devicetree-discuss
In-Reply-To: <AANLkTin-TL5_TKnyHYtZdixosfqpkPNoarSTC+K4tTUb@mail.gmail.com>
On Thu, Dec 16, 2010 at 9:47 AM, Timur Tabi <timur@freescale.com> wrote:
> On Fri, Jul 23, 2010 at 9:00 AM, Anatolij Gustschin <agust@denx.de> wrote=
:
>> Adds support for encoding display mode information
>> in the device tree using verbatim EDID block.
>>
>> If the EDID entry in the DIU node is present, the
>> driver will build mode database using EDID data
>> and allow setting the display modes from this database.
>> Otherwise display mode will be set using mode
>> entries from driver's internal database as usual.
>>
>> This patch also updates device tree bindings.
>>
>> Signed-off-by: Anatolij Gustschin <agust@denx.de>
>> Acked-by: Timur Tabi <timur@freescale.com>
>> Cc: devicetree-discuss@lists.ozlabs.org
>
> Anatolij,
>
> I know this patch is old, but I'm now getting back to working on the
> DIU driver. =A0One question I have: why are you reading the EDID data
> from the device tree? =A0Why not just read it directly from the device
> using I2C? =A0Who is supposed to put the EDID data into the device tree
> in the first place?
This is for devices which don't have an i2c edid channel.
g.
^ permalink raw reply
* Re: [PATCH v4 5/5] fsl-diu-fb: Support setting display mode using EDID
From: Timur Tabi @ 2010-12-16 16:55 UTC (permalink / raw)
To: Grant Likely
Cc: linuxppc-dev, linux-fbdev, Anatolij Gustschin, devicetree-discuss
In-Reply-To: <AANLkTi=NwY_gcBXeKXeGX-qist3tMQ4EWqj3twYGfeWD@mail.gmail.com>
Grant Likely wrote:
> This is for devices which don't have an i2c edid channel.
So are we expecting board-specific code in U-Boot to add the data to the device
tree?
--
Timur Tabi
Linux kernel developer at Freescale
^ permalink raw reply
* Re: [PATCH v4 5/5] fsl-diu-fb: Support setting display mode using EDID
From: Grant Likely @ 2010-12-16 17:06 UTC (permalink / raw)
To: Timur Tabi
Cc: linuxppc-dev, linux-fbdev, Anatolij Gustschin, devicetree-discuss
In-Reply-To: <4D0A446E.5020600@freescale.com>
On Thu, Dec 16, 2010 at 9:55 AM, Timur Tabi <timur@freescale.com> wrote:
> Grant Likely wrote:
>> This is for devices which don't have an i2c edid channel.
>
> So are we expecting board-specific code in U-Boot to add the data to the device
> tree?
No. It is a static property of the board/machine. It is expected it
to be encoded into the board's .dts file.
g.
^ permalink raw reply
* Re: ppc_set_hwdebug vs ptrace_set_debugreg
From: Andreas Schwab @ 2010-12-16 17:07 UTC (permalink / raw)
To: prasad; +Cc: linuxppc-dev, Dave Kleikamp, Srikar Dronamraju, Paul Mackerras
In-Reply-To: <20101214125427.GA2443@in.ibm.com>
"K.Prasad" <prasad@linux.vnet.ibm.com> writes:
> How about the revised patch below? It is only compile-tested; have you
> got a quick test case that I can run?
It crashes the kernel when running the watch-vfork test.
Andreas.
--
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
^ permalink raw reply
* Re: [PATCH v4 5/5] fsl-diu-fb: Support setting display mode using EDID
From: Timur Tabi @ 2010-12-16 17:28 UTC (permalink / raw)
To: Grant Likely
Cc: linuxppc-dev, linux-fbdev, Anatolij Gustschin, devicetree-discuss
In-Reply-To: <AANLkTinOf__X0p3_5G90KkYS9PXpB2j0_06MFhFcZzqO@mail.gmail.com>
Grant Likely wrote:
> No. It is a static property of the board/machine. It is expected it
> to be encoded into the board's .dts file.
Ok, but that only makes sense if the monitor is hard-wired to the board itself.
If a user can attach any monitor he wants, then the EDID data can't be known at
compile time.
I guess it's no different than using hard-coded memory controller programming
instead of SPD. You can safely avoid SPD only if the DDR chips are soldered on
the board.
It looks like I need to add board-specific EDID reading to the DIU driver.
--
Timur Tabi
Linux kernel developer at Freescale
^ permalink raw reply
* Re: [PATCH v4 5/5] fsl-diu-fb: Support setting display mode using EDID
From: Anatolij Gustschin @ 2010-12-16 17:42 UTC (permalink / raw)
To: Timur Tabi; +Cc: linuxppc-dev, linux-fbdev, devicetree-discuss
In-Reply-To: <AANLkTin-TL5_TKnyHYtZdixosfqpkPNoarSTC+K4tTUb@mail.gmail.com>
On Thu, 16 Dec 2010 10:47:53 -0600
Timur Tabi <timur@freescale.com> wrote:
> On Fri, Jul 23, 2010 at 9:00 AM, Anatolij Gustschin <agust@denx.de> wrote:
> > Adds support for encoding display mode information
> > in the device tree using verbatim EDID block.
> >
> > If the EDID entry in the DIU node is present, the
> > driver will build mode database using EDID data
> > and allow setting the display modes from this database.
> > Otherwise display mode will be set using mode
> > entries from driver's internal database as usual.
> >
> > This patch also updates device tree bindings.
> >
> > Signed-off-by: Anatolij Gustschin <agust@denx.de>
> > Acked-by: Timur Tabi <timur@freescale.com>
> > Cc: devicetree-discuss@lists.ozlabs.org
>
> Anatolij,
>
> I know this patch is old, but I'm now getting back to working on the
> DIU driver. One question I have: why are you reading the EDID data
> from the device tree? Why not just read it directly from the device
> using I2C? Who is supposed to put the EDID data into the device tree
> in the first place?
Many embedded boards only hard-wire a panel which does not provide
an i2c edid channel. For such boards the EDID data can be inserted
by the bootloader or encoded in the board's .dts. Look at pdm360ng
U-Boot board code, it inserts the EDID data into device tree using
fdt_add_edid().
Anatolij
^ permalink raw reply
* Re: [PATCH v4 5/5] fsl-diu-fb: Support setting display mode using EDID
From: Grant Likely @ 2010-12-16 17:42 UTC (permalink / raw)
To: Timur Tabi
Cc: linuxppc-dev, linux-fbdev, Anatolij Gustschin, devicetree-discuss
In-Reply-To: <4D0A4C38.3010105@freescale.com>
On Thu, Dec 16, 2010 at 10:28 AM, Timur Tabi <timur@freescale.com> wrote:
> Grant Likely wrote:
>> No. =A0It is a static property of the board/machine. =A0It is expected i=
t
>> to be encoded into the board's .dts file.
>
> Ok, but that only makes sense if the monitor is hard-wired to the board i=
tself.
> =A0If a user can attach any monitor he wants, then the EDID data can't be=
known at
> compile time.
>
> I guess it's no different than using hard-coded memory controller program=
ming
> instead of SPD. =A0You can safely avoid SPD only if the DDR chips are sol=
dered on
> the board.
Correct, if a real EDID i2c channel exists, then an edid property
should *not* be specified in the device tree.
g.
^ permalink raw reply
* [PATCH V2] powerpc/pseries: Fix VPHN build errors on non-SMP systems
From: Jesse Larrew @ 2010-12-18 8:07 UTC (permalink / raw)
To: linuxppc-dev; +Cc: markn, tbreeds, lkessler, Jesse Larrew, mjwolf
From: Jesse Larrew <jlarrew@linux.vnet.ibm.com>
The header asm/hvcall.h was previously included indirectly via
smp.h. On non-SMP systems, however, these declarations are excluded
and the build breaks. This is easily fixed by including asm/hvcall.h
directly.
The VPHN feature is only meaningful on NUMA systems that implement
the SPLPAR option, so exclude the VPHN code on systems without
SPLPAR enabled.
Also, expose unmap_cpu_from_node() on systems with SPLPAR enabled,
even if CONFIG_HOTPLUG_CPU is disabled.
Lastly, map_cpu_to_node() is now needed by VPHN to manipulate the
node masks after boot time, so remove the __cpuinit annotation to
fix a section mismatch.
Signed-off-by: Jesse Larrew <jlarrew@linux.vnet.ibm.com>
---
arch/powerpc/include/asm/topology.h | 20 +++++++++++---------
arch/powerpc/mm/numa.c | 9 ++++++---
2 files changed, 17 insertions(+), 12 deletions(-)
diff --git a/arch/powerpc/include/asm/topology.h b/arch/powerpc/include/asm/topology.h
index aed188b..fbfcfd0 100644
--- a/arch/powerpc/include/asm/topology.h
+++ b/arch/powerpc/include/asm/topology.h
@@ -93,9 +93,20 @@ extern void __init dump_numa_cpu_topology(void);
extern int sysfs_add_device_to_node(struct sys_device *dev, int nid);
extern void sysfs_remove_device_from_node(struct sys_device *dev, int nid);
+#ifdef CONFIG_PPC_SPLPAR
extern int start_topology_update(void);
extern int stop_topology_update(void);
#else
+static inline int start_topology_update(void)
+{
+ return 0;
+}
+static inline int stop_topology_update(void)
+{
+ return 0;
+}
+#endif /* CONFIG_PPC_SPLPAR */
+#else
static inline void dump_numa_cpu_topology(void) {}
@@ -108,15 +119,6 @@ static inline void sysfs_remove_device_from_node(struct sys_device *dev,
int nid)
{
}
-
-static inline int start_topology_update(void)
-{
- return 0;
-}
-static inline int stop_topology_update(void)
-{
- return 0;
-}
#endif /* CONFIG_NUMA */
#include <asm-generic/topology.h>
diff --git a/arch/powerpc/mm/numa.c b/arch/powerpc/mm/numa.c
index 42aa7d1..8f8845e 100644
--- a/arch/powerpc/mm/numa.c
+++ b/arch/powerpc/mm/numa.c
@@ -28,6 +28,7 @@
#include <asm/smp.h>
#include <asm/firmware.h>
#include <asm/paca.h>
+#include <asm/hvcall.h>
static int numa_enabled = 1;
@@ -167,7 +168,7 @@ static void __init get_node_active_region(unsigned long start_pfn,
work_with_active_regions(nid, get_active_region_work_fn, node_ar);
}
-static void __cpuinit map_cpu_to_node(int cpu, int node)
+static void map_cpu_to_node(int cpu, int node)
{
numa_cpu_lookup_table[cpu] = node;
@@ -177,7 +178,7 @@ static void __cpuinit map_cpu_to_node(int cpu, int node)
cpumask_set_cpu(cpu, node_to_cpumask_map[node]);
}
-#ifdef CONFIG_HOTPLUG_CPU
+#if defined(CONFIG_HOTPLUG_CPU) || defined(CONFIG_PPC_SPLPAR)
static void unmap_cpu_from_node(unsigned long cpu)
{
int node = numa_cpu_lookup_table[cpu];
@@ -191,7 +192,7 @@ static void unmap_cpu_from_node(unsigned long cpu)
cpu, node);
}
}
-#endif /* CONFIG_HOTPLUG_CPU */
+#endif /* CONFIG_HOTPLUG_CPU || CONFIG_PPC_SPLPAR */
/* must hold reference to node during call */
static const int *of_get_associativity(struct device_node *dev)
@@ -1263,6 +1264,7 @@ int hot_add_scn_to_nid(unsigned long scn_addr)
#endif /* CONFIG_MEMORY_HOTPLUG */
/* Vrtual Processor Home Node (VPHN) support */
+#ifdef CONFIG_PPC_SPLPAR
#define VPHN_NR_CHANGE_CTRS (8)
static u8 vphn_cpu_change_counts[NR_CPUS][VPHN_NR_CHANGE_CTRS];
static cpumask_t cpu_associativity_changes_mask;
@@ -1505,3 +1507,4 @@ int stop_topology_update(void)
vphn_enabled = 0;
return del_timer_sync(&topology_timer);
}
+#endif /* CONFIG_PPC_SPLPAR */
--
1.7.2.3
^ permalink raw reply related
* Re: Oops in trace_hardirqs_on (powerpc)
From: Jörg Sommer @ 2010-12-19 13:27 UTC (permalink / raw)
To: Steven Rostedt
Cc: Frederic Weisbecker, Ingo Molnar, linux-kernel, linuxppc-dev
In-Reply-To: <1285639094.2989.1.camel@frodo>
[-- Attachment #1: Type: text/plain, Size: 1257 bytes --]
Hi Steven,
Steven Rostedt hat am Mon 27. Sep, 21:58 (-0400) geschrieben:
> On Mon, 2010-09-27 at 14:50 +0200, Jörg Sommer wrote:
> > Hello Steven,
> >
> > Steven Rostedt hat am Wed 22. Sep, 15:44 (-0400) geschrieben:
> > > Sorry for the late reply, but I was on vacation when you sent this, and
> > > I missed it while going through email.
> > >
> > > Do you still have this issue?
> >
> > No. I've rebuild my kernel without TRACE_IRQFLAGS and the problem
> > vanished, as expected. The problem is, that in some cases the stack is
> > only two frames deep, which causes the macro CALLER_ADDR1 makes an
> > invalid access. Someone told me, there a workaround for the problem on
> > i386, too.
> >
> > % sed -n 2p arch/x86/lib/thunk_32.S
> > * Trampoline to trace irqs off. (otherwise CALLER_ADDR1 might crash)
>
> Yes, I remember that problem. When I get back from Tokyo, I'll tried to
> remember to fix it.
Did you've fixed this problem? The bug report is still marked as open.
https://bugzilla.kernel.org/show_bug.cgi?id=16573
Regards, Jörg.
--
Begebenheit aus dem wahren Leben:
Mediziner: ICEs sind die weißen Züge.
Mathematiker: Das ist falsch. Jeder ICE ist zwar weiß, aber nicht alle
weißen Züge sind ICEs.
[-- Attachment #2: Digital signature http://en.wikipedia.org/wiki/OpenPGP --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox