* Re: Patches added to 2.6.23 branch
From: Zang Roy-r61911 @ 2007-07-03 8:25 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev list
In-Reply-To: <18057.57417.999506.887803@cargo.ozlabs.ibm.com>
Paul
Could you help to add these patches:
1 add cuboot for 7448hpc2 board
http://ozlabs.org/pipermail/linuxppc-dev/2007-May/036834.html
2. Remove redundant pci_read_irq_line() function for 85xx platform
Acked by Ben
http://ozlabs.org/pipermail/linuxppc-dev/2007-June/037117.html
3. Fix e500 v2 core reboot bug
http://ozlabs.org/pipermail/linuxppc-dev/2007-June/037799.html
4. Document the global utilities node define and example
http://ozlabs.org/pipermail/linuxppc-dev/2007-June/038136.html
http://ozlabs.org/pipermail/linuxppc-dev/2007-June/038137.html
Roy
On Tue, 2007-07-03 at 13:36, Paul Mackerras wrote:
> The following patches have been added to the for-2.6.23 branch on
> powerpc.git. In addition, the master branch has the merge of the
> for-2.6.23 and merge branches, which means that it is up-to-date with
> Linus' 2.6.22-rc7 plus the patches I recently asked Linus to pull for
> inclusion in 2.6.22.
>
> Paul.
^ permalink raw reply
* [PATCH] pata_mpc52xx: suspend/resume support
From: Domen Puncer @ 2007-07-03 8:27 UTC (permalink / raw)
To: linuxppc-embedded; +Cc: linux-ide
Implement suspend and resume routines for mpc52xx ata driver.
Tested on Lite5200b with deep-sleep and low-power (not yet in-tree)
modes.
Signed-off-by: Domen Puncer <domen.puncer@telargo.com>
---
If anyone cares, I attached ATA_DEBUG messages at the end of patch.
Should it take almost 5 seconds?
drivers/ata/pata_mpc52xx.c | 18 ++++++++++++++++--
1 file changed, 16 insertions(+), 2 deletions(-)
Index: work-powerpc.git/drivers/ata/pata_mpc52xx.c
===================================================================
--- work-powerpc.git.orig/drivers/ata/pata_mpc52xx.c
+++ work-powerpc.git/drivers/ata/pata_mpc52xx.c
@@ -467,13 +467,27 @@ mpc52xx_ata_remove(struct of_device *op)
static int
mpc52xx_ata_suspend(struct of_device *op, pm_message_t state)
{
- return 0; /* FIXME : What to do here ? */
+ struct ata_host *host = dev_get_drvdata(&op->dev);
+
+ return ata_host_suspend(host, state);
}
static int
mpc52xx_ata_resume(struct of_device *op)
{
- return 0; /* FIXME : What to do here ? */
+ struct ata_host *host = dev_get_drvdata(&op->dev);
+ struct mpc52xx_ata_priv *priv = host->private_data;
+ int rv;
+
+ rv = mpc52xx_ata_hw_init(priv);
+ if (rv) {
+ printk(KERN_ERR DRV_NAME ": Error during HW init\n");
+ return rv;
+ }
+
+ ata_host_resume(host);
+
+ return 0;
}
#endif
[ 1039.434045] Stopping tasks ... done.
[ 1039.438193] Suspending console(s)
[ 1039.441662] sd 0:0:0:0: [sda] Synchronizing SCSI cache
[ 1039.441749] ata_scsi_dump_cdb: CDB (1:0,0,0) 35 00 00 00 00 00 00 00 00
[ 1039.441817] ata_exec_command: ata1: cmd 0xE7
[ 1039.442191] ata_hsm_move: ata1: protocol 1 task_state 3 (dev_stat 0x50)
[ 1039.442208] ata_hsm_move: ata1: dev 0 command complete, drv_stat 0x50
[ 1039.442310] sd 0:0:0:0: [sda] Stopping disk
[ 1039.442378] ata_scsi_dump_cdb: CDB (1:0,0,0) 1b 00 00 00 00 00 00 00 00
[ 1039.442442] ata_exec_command: ata1: cmd 0xE0
[ 1039.442738] ata_hsm_move: ata1: protocol 1 task_state 3 (dev_stat 0x50)
[ 1039.442754] ata_hsm_move: ata1: dev 0 command complete, drv_stat 0x50
[ 1039.442881] usb_endpoint usbdev1.1_ep81: PM: suspend 0->2, parent 1-0:1.0 already 2
[ 1039.442903] hub 1-0:1.0: PM: suspend 2->2, parent usb1 already 2
[ 1039.442919] usb_endpoint usbdev1.1_ep00: PM: suspend 0->2, parent usb1 already 2
[ 1039.444022] ata_port_schedule_eh: port EH scheduled
[ 1039.444056] ata_scsi_error: ENTER
[ 1039.444065] ata_port_flush_task: ENTER
[ 1039.444074] ata_port_flush_task: flush #1
[ 1039.444087] ata1: ata_port_flush_task: flush #2
[ 1039.444097] ata1: ata_port_flush_task: EXIT
[ 1039.444116] ata_eh_autopsy: ENTER
[ 1039.444133] ata_eh_autopsy: EXIT
[ 1039.444141] ata_eh_recover: ENTER
[ 1039.444151] ata_eh_revalidate_and_attach: ENTER
[ 1039.444162] ata_eh_recover: EXIT, rc=0
[ 1039.444179] __ata_port_freeze: ata1 port frozen
[ 1039.444198] ata_scsi_error: EXIT
[ 1039.447207] ata_port_schedule_eh: port EH scheduled
[ 1039.447270] eth0: Phy @ 0x0, type LXT971 (0x001378e2)
[ 1039.448257] usb_endpoint usbdev1.1_ep00: PM: resume from 0, parent usb1 still 2
[ 1039.448276] usb_endpoint usbdev1.1_ep81: PM: resume from 0, parent 1-0:1.0 still 2
[ 1039.448306] sd 0:0:0:0: [sda] Starting disk
[ 1039.448384] ata_scsi_error: ENTER
[ 1039.448398] ata_port_flush_task: ENTER
[ 1039.448407] ata_port_flush_task: flush #1
[ 1039.448420] ata1: ata_port_flush_task: flush #2
[ 1039.448430] ata1: ata_port_flush_task: EXIT
[ 1039.448451] ata_eh_autopsy: ENTER
[ 1039.448467] ata_eh_recover: ENTER
[ 1039.448481] __ata_port_freeze: ata1 port frozen
[ 1039.956600] ata_std_softreset: ENTER
[ 1039.956648] ata_std_softreset: about to softreset, devmask=3
[ 1039.956661] ata_bus_softreset: ata1: bus reset via SRST
[ 1040.107612] ata_dev_classify: found ATA device by sig
[ 1040.107643] ata_dev_classify: found ATA device by sig
[ 1040.107656] ata_std_softreset: EXIT, classes[0]=1 [1]=5
[ 1040.107667] ata_std_postreset: ENTER
[ 1040.107680] ata_std_postreset: EXIT
[ 1040.107708] ata_eh_thaw_port: ata1 port thawed
[ 1040.107717] ata_eh_revalidate_and_attach: ENTER
[ 1040.107732] ata1.00: ata_dev_read_id: ENTER
[ 1040.107833] ata_exec_command: ata1: cmd 0xEC
[ 1040.110597] ata_hsm_move: ata1: protocol 2 task_state 2 (dev_stat 0x58)
[ 1040.110616] ata_pio_sector: data read
[ 1040.110852] ata_hsm_move: ata1: protocol 2 task_state 3 (dev_stat 0x50)
[ 1040.110867] ata_hsm_move: ata1: dev 0 command complete, drv_stat 0x50
[ 1040.110920] ata_port_flush_task: ENTER
[ 1040.110929] ata_port_flush_task: flush #1
[ 1040.110941] ata1: ata_port_flush_task: flush #2
[ 1040.110952] ata1: ata_port_flush_task: EXIT
[ 1040.111032] ata_dev_set_xfermode: set features - xfer mode
[ 1040.111102] ata_exec_command: ata1: cmd 0xEF
[ 1040.111263] ata_hsm_move: ata1: protocol 1 task_state 3 (dev_stat 0x50)
[ 1040.111281] ata_hsm_move: ata1: dev 0 command complete, drv_stat 0x50
[ 1040.111329] ata_port_flush_task: ENTER
[ 1040.111339] ata_port_flush_task: flush #1
[ 1040.111351] ata1: ata_port_flush_task: flush #2
[ 1040.111361] ata1: ata_port_flush_task: EXIT
[ 1040.111373] ata_dev_set_xfermode: EXIT, err_mask=0
[ 1040.111385] ata1.00: ata_dev_read_id: ENTER
[ 1040.111474] ata_exec_command: ata1: cmd 0xEC
[ 1040.114596] ata_hsm_move: ata1: protocol 2 task_state 2 (dev_stat 0x58)
[ 1040.114615] ata_pio_sector: data read
[ 1040.114713] ata_hsm_move: ata1: protocol 2 task_state 3 (dev_stat 0x50)
[ 1040.114727] ata_hsm_move: ata1: dev 0 command complete, drv_stat 0x50
[ 1040.114775] ata_port_flush_task: ENTER
[ 1040.114784] ata_port_flush_task: flush #1
[ 1040.114796] ata1: ata_port_flush_task: flush #2
[ 1040.114806] ata1: ata_port_flush_task: EXIT
[ 1040.114861] ata_dev_set_mode: xfer_shift=0, xfer_mode=0xc
[ 1040.114873] ata1.00: configured for PIO4
[ 1040.114883] ata_eh_recover: EXIT, rc=0
[ 1040.114907] ata_scsi_error: EXIT
[ 1040.114957] ata_scsi_dump_cdb: CDB (1:0,0,0) 00 00 00 00 00 00 00 00 00
[ 1040.115051] ata_scsi_dump_cdb: CDB (1:0,0,0) 1b 00 00 00 01 00 00 00 00
[ 1040.115118] ata_exec_command: ata1: cmd 0x40
[ 1043.605018] ata_hsm_move: ata1: protocol 1 task_state 3 (dev_stat 0x50)
[ 1043.605039] ata_hsm_move: ata1: dev 0 command complete, drv_stat 0x50
[ 1043.605128] ata_scsi_dump_cdb: CDB (1:0,0,0) 25 00 00 00 00 00 00 00 00
[ 1043.990208] Restarting tasks ... done.
[ 1043.995913] sd 0:0:0:0: [sda] 8404830 512-byte hardware sectors (4303 MB)
[ 1044.004169] ata_scsi_dump_cdb: CDB (1:0,0,0) 5a 00 3f 00 00 00 00 00 08
[ 1044.011083] sd 0:0:0:0: [sda] Write Protect is off
[ 1044.016047] sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00
[ 1044.016134] ata_scsi_dump_cdb: CDB (1:0,0,0) 5a 00 08 00 00 00 00 00 08
[ 1044.023085] ata_scsi_dump_cdb: CDB (1:0,0,0) 5a 00 08 00 00 00 00 00 24
[ 1044.029978] sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
^ permalink raw reply
* RE: Anyone using QE UART mode?
From: Li Yang-r58472 @ 2007-07-03 8:32 UTC (permalink / raw)
To: Ying Lin, Tabi Timur-B04825; +Cc: linuxppc-embedded
In-Reply-To: <8F798BFDA851B943B3A1B2510E9287850350A908@airmail.wirelessworld.airvananet.com>
> -----Original Message-----
> From: linuxppc-embedded-bounces+leoli=3Dfreescale.com@ozlabs.org
> [mailto:linuxppc-embedded-bounces+leoli=3Dfreescale.com@ozlabs.org] On
Behalf
> Of Ying Lin
> Sent: Tuesday, July 03, 2007 12:02 AM
> To: Tabi Timur-B04825
> Cc: linuxppc-embedded@ozlabs.org
> Subject: RE: Anyone using QE UART mode?
>=20
> OK, the missing piece (UART driver) I am looking for is not available
> yet. I will seek alternative solutions (create a simple UART driver,
or
> just wait).
Which chip are you using? There should be separate 16550 compatible
UART controller on MPC8360. The driver is already there and working
pretty well.
- Leo
^ permalink raw reply
* Re: Patches added to 2.6.23 branch
From: Kumar Gala @ 2007-07-03 8:32 UTC (permalink / raw)
To: Zang Roy-r61911; +Cc: linuxppc-dev list, Paul Mackerras
In-Reply-To: <1183451146.14800.4.camel@localhost.localdomain>
On Jul 3, 2007, at 3:25 AM, Zang Roy-r61911 wrote:
> Paul
>
> Could you help to add these patches:
>
> 1 add cuboot for 7448hpc2 board
> http://ozlabs.org/pipermail/linuxppc-dev/2007-May/036834.html
Reviewing this one.
> 2. Remove redundant pci_read_irq_line() function for 85xx platform
> Acked by Ben
> http://ozlabs.org/pipermail/linuxppc-dev/2007-June/037117.html
>
> 3. Fix e500 v2 core reboot bug
> http://ozlabs.org/pipermail/linuxppc-dev/2007-June/037799.html
>
> 4. Document the global utilities node define and example
>
> http://ozlabs.org/pipermail/linuxppc-dev/2007-June/038136.html
> http://ozlabs.org/pipermail/linuxppc-dev/2007-June/038137.html
I've pulled all these into my tree.
- k
^ permalink raw reply
* Re: Patches added to 2.6.23 branch
From: Zang Roy-r61911 @ 2007-07-03 8:44 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev list, Paul Mackerras
In-Reply-To: <D7FB6C3D-BBA4-45A9-84CA-3D671D1FAEB8@kernel.crashing.org>
On Tue, 2007-07-03 at 16:32, Kumar Gala wrote:
> On Jul 3, 2007, at 3:25 AM, Zang Roy-r61911 wrote:
>
> > Paul
> >
> > Could you help to add these patches:
> >
> > 1 add cuboot for 7448hpc2 board
> > http://ozlabs.org/pipermail/linuxppc-dev/2007-May/036834.html
>
> Reviewing this one.
>
It has been stayed in the list for more than one month.
I need it go into 2.6.23.
Roy
^ permalink raw reply
* How to handle patches that cross maintainers?
From: Kumar Gala @ 2007-07-03 9:01 UTC (permalink / raw)
To: Andrew Morton; +Cc: linuxppc-dev list, Paul Mackerras, Linux Kernel Development
Andrew,
I was hoping to get your input on how to handle patches that cross
maintainers. I've got a patch that is pretty PPC specific, but
happens to touch some drivers as well.
Here's the diffstat to get a rough idea:
arch/powerpc/kernel/io.c | 12 ++++++------
arch/powerpc/mm/hash_native_64.c | 2 +-
arch/powerpc/mm/stab.c | 4 ++--
drivers/ide/pci/scc_pata.c | 4 ++--
drivers/media/dvb/bt8xx/bt878.h | 5 ++---
drivers/serial/cpm_uart/cpm_uart_core.c | 2 +-
include/asm-powerpc/system.h | 2 +-
7 files changed, 15 insertions(+), 16 deletions(-)
Now, I've had this issue before w/o any good sense on how to handle it.
Suggestions?
- k
^ permalink raw reply
* Patches added to for_paulus (queue'd for 2.6.23)
From: Kumar Gala @ 2007-07-03 9:17 UTC (permalink / raw)
To: linuxppc-dev list
I'm still working through the back log of patches related to ppc32/
fsl. If there are patches people want to make sure get into 2.6.23
let me know.
David Gibson (2):
[POWERPC] Split out asm-ppc/mmu.h portions for Freescale Book-E
[POWERPC] Split out asm-ppc/mmu.h portions for PowerPC 8xx
Jon Loeliger (1):
[POWERPC] Replace use of GET_64BIT(prop, i) with of_read_number
().
Kumar Gala (4):
[POWERPC] Reworked interrupt numbers for OpenPIC based
Freescale chips
[POWERPC] Kill pcibios_enable_resources()
[POWERPC] Fix up interrupt senses for MPC85xx boards
[POWERPC] Merge asm-ppc/mmu_context.h into asm-power/
mmu_context.h
Li Yang (1):
[POWERPC] qe_lib: export symbols for QE driver to compile as
module
Roy Zang (4):
[POWERPC] Document the global utilities node define and example
[POWERPC] Fix the node index confusion for SOC
[POWERPC] 85xx: Fix 8548CDS reset bug
[POWERPC] Remove redundant pci_read_irq_line() function for
85xx platform
Timur Tabi (1):
[POWERPC] Fix MAC address entries for 83xx, 85xx, and 86xx
device trees
These two patches are queue, but not in the tree (or will be after
some other depency):
* 83xx USB platform code rework
* bootwrapper: adds cuboot for MPC7448HPC2 platform
- k
^ permalink raw reply
* Re: PCI IO range limitation
From: Marian Balakowicz @ 2007-07-03 9:24 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev
In-Reply-To: <1183052634.5521.284.camel@localhost.localdomain>
Benjamin Herrenschmidt wrote:
> On Thu, 2007-06-28 at 12:20 +0200, Marian Balakowicz wrote:
>> I guess that with the above dropping of non-zero based PCI IO ranges
>> this is not supposed to be working. But does anyone know why?
>
> We just fixed that for 64 bits but 32 bits still has the limitation.
> Note that it's not a very good idea to have your IO range at !0 if
> you're going to use anything ISA-like, such as a VGA video card or other
> legacy devices behind a PCI southbridge or SuperIO.
Agree with the zero-based IO range for ISA devices. But, knowing we don't have any ISA stuff on board it should be possible to change the IO base. Are you planning on modifications for 32 bits as well?
Marian
^ permalink raw reply
* [PATCH 2.6.23] 83xx USB platform code rework
From: Li Yang @ 2007-07-03 9:43 UTC (permalink / raw)
To: paulus, galak; +Cc: linuxppc-dev, Li Yang
Add 831x USB platform setup code and rework 834x USB
platform setup code. Move USB platform code to usb.c
for different boards with CPU of the same series to share
the USB initialization code.
Signed-off-by: Li Yang <leoli@freescale.com>
Signed-off-by: Kim Phillips <kim.phillips@freescale.com>
---
Respin for 2.6.22-rc7. Remove USB_EHCI_FSL selects in Kconfig, as they
will be enabled in USB Kconfig.
arch/powerpc/platforms/83xx/Makefile | 2 +-
arch/powerpc/platforms/83xx/mpc8313_rdb.c | 1 +
arch/powerpc/platforms/83xx/mpc834x_mds.c | 49 +-------
arch/powerpc/platforms/83xx/mpc83xx.h | 28 ++++-
arch/powerpc/platforms/83xx/usb.c | 181 +++++++++++++++++++++++++++++
5 files changed, 213 insertions(+), 48 deletions(-)
create mode 100644 arch/powerpc/platforms/83xx/usb.c
diff --git a/arch/powerpc/platforms/83xx/Makefile b/arch/powerpc/platforms/83xx/Makefile
index 31a91b5..5a98f88 100644
--- a/arch/powerpc/platforms/83xx/Makefile
+++ b/arch/powerpc/platforms/83xx/Makefile
@@ -1,7 +1,7 @@
#
# Makefile for the PowerPC 83xx linux kernel.
#
-obj-y := misc.o
+obj-y := misc.o usb.o
obj-$(CONFIG_PCI) += pci.o
obj-$(CONFIG_MPC8313_RDB) += mpc8313_rdb.o
obj-$(CONFIG_MPC832x_RDB) += mpc832x_rdb.o
diff --git a/arch/powerpc/platforms/83xx/mpc8313_rdb.c b/arch/powerpc/platforms/83xx/mpc8313_rdb.c
index 96970ac..a404910 100644
--- a/arch/powerpc/platforms/83xx/mpc8313_rdb.c
+++ b/arch/powerpc/platforms/83xx/mpc8313_rdb.c
@@ -53,6 +53,7 @@ static void __init mpc8313_rdb_setup_arch(void)
ppc_md.pci_exclude_device = mpc83xx_exclude_device;
#endif
+ mpc831x_usb_cfg();
}
void __init mpc8313_rdb_init_IRQ(void)
diff --git a/arch/powerpc/platforms/83xx/mpc834x_mds.c b/arch/powerpc/platforms/83xx/mpc834x_mds.c
index 10394b2..28b3840 100644
--- a/arch/powerpc/platforms/83xx/mpc834x_mds.c
+++ b/arch/powerpc/platforms/83xx/mpc834x_mds.c
@@ -44,55 +44,16 @@ unsigned long isa_mem_base = 0;
#endif
#define BCSR5_INT_USB 0x02
-/* Note: This is only for PB, not for PB+PIB
- * On PB only port0 is connected using ULPI */
-static int mpc834x_usb_cfg(void)
+static int mpc834xemds_usb_cfg(void)
{
- unsigned long sccr, sicrl;
- void __iomem *immap;
+ struct device_node *np;
void __iomem *bcsr_regs = NULL;
u8 bcsr5;
- struct device_node *np = NULL;
- int port0_is_dr = 0;
-
- if ((np = of_find_compatible_node(NULL, "usb", "fsl-usb2-dr")) != NULL)
- port0_is_dr = 1;
- if ((np = of_find_compatible_node(NULL, "usb", "fsl-usb2-mph")) != NULL){
- if (port0_is_dr) {
- printk(KERN_WARNING
- "There is only one USB port on PB board! \n");
- return -1;
- } else if (!port0_is_dr)
- /* No usb port enabled */
- return -1;
- }
-
- immap = ioremap(get_immrbase(), 0x1000);
- if (!immap)
- return -1;
-
- /* Configure clock */
- sccr = in_be32(immap + MPC83XX_SCCR_OFFS);
- if (port0_is_dr)
- sccr |= MPC83XX_SCCR_USB_DRCM_11; /* 1:3 */
- else
- sccr |= MPC83XX_SCCR_USB_MPHCM_11; /* 1:3 */
- out_be32(immap + MPC83XX_SCCR_OFFS, sccr);
-
- /* Configure Pin */
- sicrl = in_be32(immap + MPC83XX_SICRL_OFFS);
- /* set port0 only */
- if (port0_is_dr)
- sicrl |= MPC83XX_SICRL_USB0;
- else
- sicrl &= ~(MPC83XX_SICRL_USB0);
- out_be32(immap + MPC83XX_SICRL_OFFS, sicrl);
-
- iounmap(immap);
+ mpc834x_usb_cfg();
/* Map BCSR area */
np = of_find_node_by_name(NULL, "bcsr");
- if (np != 0) {
+ if (np) {
struct resource res;
of_address_to_resource(np, 0, &res);
@@ -134,7 +95,7 @@ static void __init mpc834x_mds_setup_arch(void)
ppc_md.pci_exclude_device = mpc83xx_exclude_device;
#endif
- mpc834x_usb_cfg();
+ mpc834xemds_usb_cfg();
}
static void __init mpc834x_mds_init_IRQ(void)
diff --git a/arch/powerpc/platforms/83xx/mpc83xx.h b/arch/powerpc/platforms/83xx/mpc83xx.h
index 9cd03b5..a44e5b1 100644
--- a/arch/powerpc/platforms/83xx/mpc83xx.h
+++ b/arch/powerpc/platforms/83xx/mpc83xx.h
@@ -6,6 +6,7 @@
/* System Clock Control Register */
#define MPC83XX_SCCR_OFFS 0xA08
+#define MPC83XX_SCCR_USB_MASK 0x00f00000
#define MPC83XX_SCCR_USB_MPHCM_11 0x00c00000
#define MPC83XX_SCCR_USB_MPHCM_01 0x00400000
#define MPC83XX_SCCR_USB_MPHCM_10 0x00800000
@@ -15,12 +16,31 @@
/* system i/o configuration register low */
#define MPC83XX_SICRL_OFFS 0x114
-#define MPC83XX_SICRL_USB0 0x40000000
-#define MPC83XX_SICRL_USB1 0x20000000
+#define MPC834X_SICRL_USB_MASK 0x60000000
+#define MPC834X_SICRL_USB0 0x40000000
+#define MPC834X_SICRL_USB1 0x20000000
+#define MPC831X_SICRL_USB_MASK 0x00000c00
+#define MPC831X_SICRL_USB_ULPI 0x00000800
/* system i/o configuration register high */
#define MPC83XX_SICRH_OFFS 0x118
-#define MPC83XX_SICRH_USB_UTMI 0x00020000
+#define MPC834X_SICRH_USB_UTMI 0x00020000
+#define MPC831X_SICRH_USB_MASK 0x000000e0
+#define MPC831X_SICRH_USB_ULPI 0x000000a0
+
+/* USB Control Register */
+#define FSL_USB2_CONTROL_OFFS 0x500
+#define CONTROL_UTMI_PHY_EN 0x00000200
+#define CONTROL_REFSEL_48MHZ 0x00000080
+#define CONTROL_PHY_CLK_SEL_ULPI 0x00000400
+#define CONTROL_OTG_PORT 0x00000020
+
+/* USB PORTSC Registers */
+#define FSL_USB2_PORTSC1_OFFS 0x184
+#define FSL_USB2_PORTSC2_OFFS 0x188
+#define PORTSCX_PTW_16BIT 0x10000000
+#define PORTSCX_PTS_UTMI 0x00000000
+#define PORTSCX_PTS_ULPI 0x80000000
/*
* Declaration for the various functions exported by the
@@ -31,5 +51,7 @@ extern int add_bridge(struct device_node *dev);
extern int mpc83xx_exclude_device(u_char bus, u_char devfn);
extern void mpc83xx_restart(char *cmd);
extern long mpc83xx_time_init(void);
+extern int mpc834x_usb_cfg(void);
+extern int mpc831x_usb_cfg(void);
#endif /* __MPC83XX_H__ */
diff --git a/arch/powerpc/platforms/83xx/usb.c b/arch/powerpc/platforms/83xx/usb.c
new file mode 100644
index 0000000..e7fdf01
--- /dev/null
+++ b/arch/powerpc/platforms/83xx/usb.c
@@ -0,0 +1,181 @@
+/*
+ * Freescale 83xx USB SOC setup code
+ *
+ * Copyright (C) 2007 Freescale Semiconductor, Inc.
+ * Author: Li Yang
+ *
+ * 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 <linux/stddef.h>
+#include <linux/kernel.h>
+#include <linux/errno.h>
+
+#include <asm/io.h>
+#include <asm/prom.h>
+#include <sysdev/fsl_soc.h>
+
+#include "mpc83xx.h"
+
+
+#ifdef CONFIG_MPC834x
+int mpc834x_usb_cfg(void)
+{
+ unsigned long sccr, sicrl, sicrh;
+ void __iomem *immap;
+ struct device_node *np = NULL;
+ int port0_is_dr = 0, port1_is_dr = 0;
+ const void *prop, *dr_mode;
+
+ immap = ioremap(get_immrbase(), 0x1000);
+ if (!immap)
+ return -ENOMEM;
+
+ /* Read registers */
+ /* Note: DR and MPH must use the same clock setting in SCCR */
+ sccr = in_be32(immap + MPC83XX_SCCR_OFFS) & ~MPC83XX_SCCR_USB_MASK;
+ sicrl = in_be32(immap + MPC83XX_SICRL_OFFS) & ~MPC834X_SICRL_USB_MASK;
+ sicrh = in_be32(immap + MPC83XX_SICRH_OFFS) & ~MPC834X_SICRH_USB_UTMI;
+
+ np = of_find_compatible_node(NULL, "usb", "fsl-usb2-dr");
+ if (np) {
+ sccr |= MPC83XX_SCCR_USB_DRCM_11; /* 1:3 */
+
+ prop = of_get_property(np, "phy_type", NULL);
+ if (prop && (!strcmp(prop, "utmi") ||
+ !strcmp(prop, "utmi_wide"))) {
+ sicrl |= MPC834X_SICRL_USB0 | MPC834X_SICRL_USB1;
+ sicrh |= MPC834X_SICRH_USB_UTMI;
+ port1_is_dr = 1;
+ } else if (prop && !strcmp(prop, "serial")) {
+ dr_mode = of_get_property(np, "dr_mode", NULL);
+ if (dr_mode && !strcmp(dr_mode, "otg")) {
+ sicrl |= MPC834X_SICRL_USB0 | MPC834X_SICRL_USB1;
+ port1_is_dr = 1;
+ } else {
+ sicrl |= MPC834X_SICRL_USB0;
+ }
+ } else if (prop && !strcmp(prop, "ulpi")) {
+ sicrl |= MPC834X_SICRL_USB0;
+ } else {
+ printk(KERN_WARNING "834x USB PHY type not supported\n");
+ }
+ port0_is_dr = 1;
+ of_node_put(np);
+ }
+ np = of_find_compatible_node(NULL, "usb", "fsl-usb2-mph");
+ if (np) {
+ sccr |= MPC83XX_SCCR_USB_MPHCM_11; /* 1:3 */
+
+ prop = of_get_property(np, "port0", NULL);
+ if (prop) {
+ if (port0_is_dr)
+ printk(KERN_WARNING
+ "834x USB port0 can't be used by both DR and MPH!\n");
+ sicrl |= MPC834X_SICRL_USB0;
+ }
+ prop = of_get_property(np, "port1", NULL);
+ if (prop) {
+ if (port1_is_dr)
+ printk(KERN_WARNING
+ "834x USB port1 can't be used by both DR and MPH!\n");
+ sicrl |= MPC834X_SICRL_USB1;
+ }
+ of_node_put(np);
+ }
+
+ /* Write back */
+ out_be32(immap + MPC83XX_SCCR_OFFS, sccr);
+ out_be32(immap + MPC83XX_SICRL_OFFS, sicrl);
+ out_be32(immap + MPC83XX_SICRH_OFFS, sicrh);
+
+ iounmap(immap);
+ return 0;
+}
+#endif /* CONFIG_MPC834x */
+
+#ifdef CONFIG_PPC_MPC831x
+int mpc831x_usb_cfg(void)
+{
+ u32 temp;
+ void __iomem *immap, *usb_regs;
+ struct device_node *np = NULL;
+ const void *prop;
+ struct resource res;
+ int ret = 0;
+#ifdef CONFIG_USB_OTG
+ const void *dr_mode;
+#endif
+
+ np = of_find_compatible_node(NULL, "usb", "fsl-usb2-dr");
+ if (!np)
+ return -ENODEV;
+ prop = of_get_property(np, "phy_type", NULL);
+
+ /* Map IMMR space for pin and clock settings */
+ immap = ioremap(get_immrbase(), 0x1000);
+ if (!immap) {
+ of_node_put(np);
+ return -ENOMEM;
+ }
+
+ /* Configure clock */
+ temp = in_be32(immap + MPC83XX_SCCR_OFFS);
+ temp &= ~MPC83XX_SCCR_USB_MASK;
+ temp |= MPC83XX_SCCR_USB_DRCM_11; /* 1:3 */
+ out_be32(immap + MPC83XX_SCCR_OFFS, temp);
+
+ /* Configure pin mux for ULPI. There is no pin mux for UTMI */
+ if (!strcmp(prop, "ulpi")) {
+ temp = in_be32(immap + MPC83XX_SICRL_OFFS);
+ temp &= ~MPC831X_SICRL_USB_MASK;
+ temp |= MPC831X_SICRL_USB_ULPI;
+ out_be32(immap + MPC83XX_SICRL_OFFS, temp);
+
+ temp = in_be32(immap + MPC83XX_SICRH_OFFS);
+ temp &= ~MPC831X_SICRH_USB_MASK;
+ temp |= MPC831X_SICRH_USB_ULPI;
+ out_be32(immap + MPC83XX_SICRH_OFFS, temp);
+ }
+
+ iounmap(immap);
+
+ /* Map USB SOC space */
+ ret = of_address_to_resource(np, 0, &res);
+ if (ret) {
+ of_node_put(np);
+ return ret;
+ }
+ usb_regs = ioremap(res.start, res.end - res.start + 1);
+
+ /* Using on-chip PHY */
+ if (!strcmp(prop, "utmi_wide") ||
+ !strcmp(prop, "utmi")) {
+ /* Set UTMI_PHY_EN, REFSEL to 48MHZ */
+ out_be32(usb_regs + FSL_USB2_CONTROL_OFFS,
+ CONTROL_UTMI_PHY_EN | CONTROL_REFSEL_48MHZ);
+ /* Using external UPLI PHY */
+ } else if (!strcmp(prop, "ulpi")) {
+ /* Set PHY_CLK_SEL to ULPI */
+ temp = CONTROL_PHY_CLK_SEL_ULPI;
+#ifdef CONFIG_USB_OTG
+ /* Set OTG_PORT */
+ dr_mode = of_get_property(np, "dr_mode", NULL);
+ if (dr_mode && !strcmp(dr_mode, "otg"))
+ temp |= CONTROL_OTG_PORT;
+#endif /* CONFIG_USB_OTG */
+ out_be32(usb_regs + FSL_USB2_CONTROL_OFFS, temp);
+ } else {
+ printk(KERN_WARNING "831x USB PHY type not supported\n");
+ ret = -EINVAL;
+ }
+
+ iounmap(usb_regs);
+ of_node_put(np);
+ return ret;
+}
+#endif /* CONFIG_PPC_MPC831x */
--
1.5.2.GIT
^ permalink raw reply related
* Re: How to handle patches that cross maintainers?
From: Andrew Morton @ 2007-07-03 9:38 UTC (permalink / raw)
To: Kumar Gala; +Cc: list, linuxppc-dev, Paul Mackerras, Linux Kernel Development
In-Reply-To: <4BEFAFC6-3346-4F29-B1C5-377952E3FBBF@kernel.crashing.org>
On Tue, 3 Jul 2007 04:01:20 -0500 Kumar Gala <galak@kernel.crashing.org> wrote:
> Andrew,
>
> I was hoping to get your input on how to handle patches that cross
> maintainers. I've got a patch that is pretty PPC specific, but
> happens to touch some drivers as well.
>
> Here's the diffstat to get a rough idea:
>
> arch/powerpc/kernel/io.c | 12 ++++++------
> arch/powerpc/mm/hash_native_64.c | 2 +-
> arch/powerpc/mm/stab.c | 4 ++--
> drivers/ide/pci/scc_pata.c | 4 ++--
> drivers/media/dvb/bt8xx/bt878.h | 5 ++---
> drivers/serial/cpm_uart/cpm_uart_core.c | 2 +-
> include/asm-powerpc/system.h | 2 +-
> 7 files changed, 15 insertions(+), 16 deletions(-)
>
> Now, I've had this issue before w/o any good sense on how to handle it.
>
> Suggestions?
>
Well, assuming that all the changes are interdependent and cannot be split
up: send it to the relevant maintainers, gather the acks and merge it up
yourself.
^ permalink raw reply
* Re: [PATCH 3/3] First cut at PReP support for arch/powerpc
From: Gabriel Paubert @ 2007-07-03 9:51 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: linuxppc-dev, Paul Mackerras, David Gibson
In-Reply-To: <f778cbc9a05aafa7527bd14f9259aad2@kernel.crashing.org>
On Mon, Jul 02, 2007 at 01:51:42PM +0200, Segher Boessenkool wrote:
> >>+ external-control;
> >>
> >>Really?
> >
> >Well, is anybody actually using eciwx/ecowx?
>
> That's not the point -- the device tree should only
> say "external-control" if the CPU actually supports
> it; AFAIK, that's 601 only.
I wonder whether you are mixing up external control
and direct-store segments (the "T" bit in segment registers).
>From my docs, external control has been supported by many
processors, up to many variants of the 750 and even 7440/7450.
Now I've never seen any hardware which could make use of these
instructions (you'd need a device on the processor bus that
reacts to the special bus cycles generated by the ec[io]wx
instructions, since no host bridge I've ever met handles them.
I've not seen support for external control in the Linux kernel
either (you'd need to setup the EAR SPR and probablly to modify
it on context switches).
OTOH, the direct-store segments were only implemented in the
original 601, 603 (not 603e) and 604 processors (can't remember
about the 604e) and even then the 601 had special features
in this area.
>
> >>+ pci@80000000 {
> >>+ device_type = "pci";
> >>+ compatible = "prep";
> >>
> >>Is that specific enough?
> >
> >On the MVME5100, actually the mapping is more CHRP like, and PCI I/O
> >space is smaller and at a higher address.
>
> Right, so it's not; "compatible" should specify the
> model of PCI host bridge, instead.
Well, the PCI host bridge is reprogrammable in a very flexible way
and and I actually wrote a boot loader that reprograms it the
way I wanted address space to look like. I shall send it to
you in a PM (it is quite big, it includes an x86 emulator
which is able to initialize the VGA PMC modules I have by
running the BIOS).
Regards,
Gabriel
^ permalink raw reply
* Re: PCI IO range limitation
From: Benjamin Herrenschmidt @ 2007-07-03 11:13 UTC (permalink / raw)
To: Marian Balakowicz; +Cc: linuxppc-dev
In-Reply-To: <468A15D9.7010003@semihalf.com>
On Tue, 2007-07-03 at 11:24 +0200, Marian Balakowicz wrote:
> Benjamin Herrenschmidt wrote:
> > On Thu, 2007-06-28 at 12:20 +0200, Marian Balakowicz wrote:
> >> I guess that with the above dropping of non-zero based PCI IO ranges
> >> this is not supposed to be working. But does anyone know why?
> >
> > We just fixed that for 64 bits but 32 bits still has the limitation.
> > Note that it's not a very good idea to have your IO range at !0 if
> > you're going to use anything ISA-like, such as a VGA video card or other
> > legacy devices behind a PCI southbridge or SuperIO.
>
> Agree with the zero-based IO range for ISA devices. But, knowing we don't
> have any ISA stuff on board it should be possible to change the IO base.
And you don't plan to ever have a VGA video card ?
> Are you planning on modifications for 32 bits as well?
Not right now, but you are welcome to send a patch :-) Though I fail to
see why you want to do it.
Ben
^ permalink raw reply
* RE: [PATCH] ucc_geth.c, make PHY device optional.
From: Joakim Tjernlund @ 2007-07-03 11:19 UTC (permalink / raw)
To: Li Yang-r58472; +Cc: linuxppc-dev Development, Netdev
In-Reply-To: <989B956029373F45A0B8AF0297081890D8383E@zch01exm26.fsl.freescale.net>
On Tue, 2007-07-03 at 16:22 +0800, Li Yang-r58472 wrote:
> > -----Original Message-----
> > From: Joakim Tjernlund [mailto:joakim.tjernlund@transmode.se]
> > Sent: Tuesday, July 03, 2007 3:21 PM
> > To: Li Yang-r58472
> > Cc: linuxppc-dev Development; Netdev; Fleming Andy-afleming
> > Subject: RE: [PATCH] ucc_geth.c, make PHY device optional.
> >
> > On Tue, 2007-07-03 at 11:42 +0800, Li Yang-r58472 wrote:
> > > > -----Original Message-----
> > > > From: netdev-owner@vger.kernel.org
> > > [mailto:netdev-owner@vger.kernel.org] On
> > > > Behalf Of Joakim Tjernlund
> > > > Sent: Tuesday, July 03, 2007 8:52 AM
> > > > To: 'linuxppc-dev Development'; 'Netdev'; Li Yang-r58472
> > > > Subject: [PATCH] ucc_geth.c, make PHY device optional.
> > > >
> > > > > This patch makes the PHY optional for ucc_geth.c ethernet
> driver.
> > > > > This is useful to support a direct mii to mii connection to, for
> > > example,
> > > > > a onboard swicth.
> > > > >
> > > > > Signed-off-by: Joakim Tjernlund <joakim.tjernlund@transmode.se>
> > > > ----
> > > Hi Joakim,
> > >
> > > I'm wondering if we really need to have the option to disable
> phylib.
> >
> > maybe, but it has to be dynamic too. I need to use PHY on UCC2 and mii
> > on UCC3 and UCC4.
> >
> > > Actually we have made phylib selected by default for ucc_geth. Many
> L2
> > > switch chips have the capacity to be controlled. Therefore they can
> be
> > > managed as a phy device.
> >
> > Yes, they can be but why force a PHY impl. when its is of no use? The
> > only thing the eth driver needs from the it is speed and duplex. If
> > these are fixed, you don't need to talk with a PHY.
>
> The driver needs to get and set the link speed/status on runtime (such
> as for ethtool interface). Currently this is implementation through
> phydev interface. IMHO, it will be easier to maintain if we only use
> this standard interface, rather than use different interfaces for
> different cases.
hmm maybe, but there is no need to much around with speed/status
from user space. The speed and duplex must be set before user space
is up.
>
> >
> > > For the MII interface which is not
> > > configurable, shouldn't we use the fixed phy support from Vitaly?
> >
> > Well, I think the the fixed phy is great when your eth driver requires
> a
> > PHY, but it is a workaround with extra processing overhead. IMHO the
> > best impl. is to make the PHY optional in the eth driver and as you
> can
> > see from the patch, that was really simple.
>
> I agree there is overhead. However, it will have the advantage of
> abstracting all the PHY related stuff out of controller driver.
>
> >
> > An useful extension would be to add a new propety in the DTS to hold
> > initial speed and duplex(perhaps extend phy-connection-type). This
> > would be useful for the fixed driver too as one could derive speed and
> > duplex for the fixed phy from that property instead of creating a
> fixed
> > phy for each speed and duplex one want to support.
>
> I agree that there should be a device node to configure it. The current
> fixed phy driver is a little bit too complex to emulate the register
> access. Maybe it's better to have a null phy driver which just reads
> PHY capacity and status from device node.
A null phy driver is better than the current fixed phy, I agree.
Where would you like to put initial speed and duplex? In a fake phy node
or in the ethernet node?
Perhaps this should live in BSP code instead?
Jocke
^ permalink raw reply
* NFS mounting problem in mpc860 based board
From: Barisa kisku @ 2007-07-03 11:23 UTC (permalink / raw)
To: linuxppc-embedded
hi,
I have ported u-boot 1.1.6 in a custom board based on
mpc860.using "tftpboot" command Linux kernel uImage is
downloaded.And it was run with "bootm" command and
controls are transfered to linux properly.
While kernel is mounting root file system through nfs
it is not able to send the message properly.By
observing through "Ethereal" at server machine, no ARP
message is reaching.
Print coming in console of embedded system is:
portmap: "Unable to get port number for nfsd of
server"
But i am able to mount the file system in the given
server from other machine in the LAN.
Again by looking at the status of the BDs it seems
that the ethernet driver is sending message properly
to the LAN.
If anybody has come across this type of problem,
please help me in debugging.
Thanks in advance.
Regards,
Barisa Kisku
__________________________________________________________
Yahoo! India Answers: Share what you know. Learn something new
http://in.answers.yahoo.com/
^ permalink raw reply
* RE: [PATCH] ucc_geth.c, make PHY device optional.
From: Li Yang-r58472 @ 2007-07-03 11:38 UTC (permalink / raw)
To: joakim.tjernlund; +Cc: linuxppc-dev Development, Netdev
In-Reply-To: <1183461586.20673.192.camel@gentoo-jocke.transmode.se>
> -----Original Message-----
> From: Joakim Tjernlund [mailto:joakim.tjernlund@transmode.se]
> Sent: Tuesday, July 03, 2007 7:20 PM
> To: Li Yang-r58472
> Cc: linuxppc-dev Development; Netdev; Fleming Andy-afleming
> Subject: RE: [PATCH] ucc_geth.c, make PHY device optional.
>=20
> On Tue, 2007-07-03 at 16:22 +0800, Li Yang-r58472 wrote:
> > > -----Original Message-----
> > > From: Joakim Tjernlund [mailto:joakim.tjernlund@transmode.se]
> > > Sent: Tuesday, July 03, 2007 3:21 PM
> > > To: Li Yang-r58472
> > > Cc: linuxppc-dev Development; Netdev; Fleming Andy-afleming
> > > Subject: RE: [PATCH] ucc_geth.c, make PHY device optional.
> > >
> > > On Tue, 2007-07-03 at 11:42 +0800, Li Yang-r58472 wrote:
> > > > > -----Original Message-----
> > > > > From: netdev-owner@vger.kernel.org
> > > > [mailto:netdev-owner@vger.kernel.org] On
> > > > > Behalf Of Joakim Tjernlund
> > > > > Sent: Tuesday, July 03, 2007 8:52 AM
> > > > > To: 'linuxppc-dev Development'; 'Netdev'; Li Yang-r58472
> > > > > Subject: [PATCH] ucc_geth.c, make PHY device optional.
> > > > >
> > > > > > This patch makes the PHY optional for ucc_geth.c ethernet
> > driver.
> > > > > > This is useful to support a direct mii to mii connection to,
for
> > > > example,
> > > > > > a onboard swicth.
> > > > > >
> > > > > > Signed-off-by: Joakim Tjernlund
<joakim.tjernlund@transmode.se>
> > > > > ----
> > > > Hi Joakim,
> > > >
> > > > I'm wondering if we really need to have the option to disable
> > phylib.
> > >
> > > maybe, but it has to be dynamic too. I need to use PHY on UCC2 and
mii
> > > on UCC3 and UCC4.
> > >
> > > > Actually we have made phylib selected by default for ucc_geth.
Many
> > L2
> > > > switch chips have the capacity to be controlled. Therefore they
can
> > be
> > > > managed as a phy device.
> > >
> > > Yes, they can be but why force a PHY impl. when its is of no use?
The
> > > only thing the eth driver needs from the it is speed and duplex.
If
> > > these are fixed, you don't need to talk with a PHY.
> >
> > The driver needs to get and set the link speed/status on runtime
(such
> > as for ethtool interface). Currently this is implementation through
> > phydev interface. IMHO, it will be easier to maintain if we only
use
> > this standard interface, rather than use different interfaces for
> > different cases.
>=20
> hmm maybe, but there is no need to much around with speed/status
> from user space. The speed and duplex must be set before user space
> is up.
>=20
> >
> > >
> > > > For the MII interface which is not
> > > > configurable, shouldn't we use the fixed phy support from
Vitaly?
> > >
> > > Well, I think the the fixed phy is great when your eth driver
requires
> > a
> > > PHY, but it is a workaround with extra processing overhead. IMHO
the
> > > best impl. is to make the PHY optional in the eth driver and as
you
> > can
> > > see from the patch, that was really simple.
> >
> > I agree there is overhead. However, it will have the advantage of
> > abstracting all the PHY related stuff out of controller driver.
> >
> > >
> > > An useful extension would be to add a new propety in the DTS to
hold
> > > initial speed and duplex(perhaps extend phy-connection-type). This
> > > would be useful for the fixed driver too as one could derive speed
and
> > > duplex for the fixed phy from that property instead of creating a
> > fixed
> > > phy for each speed and duplex one want to support.
> >
> > I agree that there should be a device node to configure it. The
current
> > fixed phy driver is a little bit too complex to emulate the register
> > access. Maybe it's better to have a null phy driver which just
reads
> > PHY capacity and status from device node.
>=20
> A null phy driver is better than the current fixed phy, I agree.
> Where would you like to put initial speed and duplex? In a fake phy
node
> or in the ethernet node?
I think a fake phy node is better.
- Leo
^ permalink raw reply
* Re: [PATCH] powerpc: Add of_register_i2c_devices()
From: Segher Boessenkool @ 2007-07-03 12:33 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: linuxppc-dev, Paul Mackerras, Guennadi Liakhovetski
In-Reply-To: <1183423369.10386.49.camel@localhost.localdomain>
>>> + addr = of_get_property(node, "reg", &len);
>>> + if (!addr || len < sizeof(int) || *addr > 0xffff)
>>> + continue;
>>
>> Addresses aren't 16 bit AFAIK?
>
> Some i2c busses support 10 bits addressing...
All I2C busses. All I2C devices, too, it's just that
not all of them can decode 10-bit addresses (but they
are fine with seeing those on the bus, they'll just
never be addressed by it themselves).
Anyway, my point was that 10 isn't the same as 16.
Segher
^ permalink raw reply
* Re: [PATCH 3/3] First cut at PReP support for arch/powerpc
From: Segher Boessenkool @ 2007-07-03 12:49 UTC (permalink / raw)
To: Gabriel Paubert; +Cc: linuxppc-dev, Paul Mackerras, David Gibson
In-Reply-To: <20070703095114.GA31118@iram.es>
>>>> + external-control;
>>>>
>>>> Really?
>>>
>>> Well, is anybody actually using eciwx/ecowx?
>>
>> That's not the point -- the device tree should only
>> say "external-control" if the CPU actually supports
>> it; AFAIK, that's 601 only.
>
> I wonder whether you are mixing up external control
> and direct-store segments (the "T" bit in segment registers).
=93external-control=94 prop-encoded-array: <none>
This property, if present, indicates that the PowerPC
microprocessor defined by this CPU node implements the
External Control Facility as described in the =93Optional
Facilities and Instructions=94 appendix of Book II of [2].
The absence of his property indicates that the PowerPC
microprocessor defined by this CPU node does not support
the External Control Facility.
No, I don't think I'm mixing up anything. G2 CPUs don't
support this stuff, do they?
>> =46rom my docs, external control has been supported by many
> processors, up to many variants of the 750 and even 7440/7450.
Hrm I don't think so... </me looks>... erm yeah. It's just
that it isn't usable on any of those systems ;-)
> Now I've never seen any hardware which could make use of these
> instructions (you'd need a device on the processor bus that
> reacts to the special bus cycles generated by the ec[io]wx
> instructions, since no host bridge I've ever met handles them.
Yeah exactly.
> I've not seen support for external control in the Linux kernel
> either (you'd need to setup the EAR SPR and probablly to modify
> it on context switches).
>
> OTOH, the direct-store segments were only implemented in the
> original 601, 603 (not 603e) and 604 processors (can't remember
> about the 604e) and even then the 601 had special features
> in this area.
Yah.
>>>> + pci@80000000 {
>>>> + device_type =3D "pci";
>>>> + compatible =3D "prep";
>>>>
>>>> Is that specific enough?
>>>
>>> On the MVME5100, actually the mapping is more CHRP like, and PCI I/O
>>> space is smaller and at a higher address.
>>
>> Right, so it's not; "compatible" should specify the
>> model of PCI host bridge, instead.
>
> Well, the PCI host bridge is reprogrammable in a very flexible way
> and and I actually wrote a boot loader that reprograms it the
> way I wanted address space to look like.
"compatible" should just say what exactly the hardware is;
"prep" isn't good enough to describe a certain PCI host
bridge (it doesn't say it is a PHB, to start with!)
> I shall send it to
> you in a PM (it is quite big, it includes an x86 emulator
> which is able to initialize the VGA PMC modules I have by
> running the BIOS).
Hrm I'm not sure what I should do with that?
Segher
^ permalink raw reply
* Re: Patches added to 2.6.23 branch
From: Josh Boyer @ 2007-07-03 13:04 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev
In-Reply-To: <18057.57417.999506.887803@cargo.ozlabs.ibm.com>
On Tue, 2007-07-03 at 15:36 +1000, Paul Mackerras wrote:
> The following patches have been added to the for-2.6.23 branch on
> powerpc.git. In addition, the master branch has the merge of the
> for-2.6.23 and merge branches, which means that it is up-to-date with
> Linus' 2.6.22-rc7 plus the patches I recently asked Linus to pull for
> inclusion in 2.6.22.
How about:
http://patchwork.ozlabs.org/linuxppc/patch?id=12014
and maybe:
http://patchwork.ozlabs.org/linuxppc/patch?id=11953
I can fix the apostrophe if you really want ;)
josh
^ permalink raw reply
* RE: Anyone using QE UART mode?
From: Ying Lin @ 2007-07-03 13:15 UTC (permalink / raw)
To: Li Yang-r58472, Tabi Timur-B04825; +Cc: linuxppc-embedded
In-Reply-To: <989B956029373F45A0B8AF0297081890D83844@zch01exm26.fsl.freescale.net>
> Which chip are you using? There should be separate 16550 compatible
> UART controller on MPC8360. The driver is already there and working
> pretty well.
We are using MPC8323E. We have 2 working serial ports from the DUART
controller, but we need more than 2.
We have about 4 weeks to make them working, any suggestion where to
start? We plan to start with CW QE Utility generated codes.
Thanks,
Ying
^ permalink raw reply
* [PATCH v2] Schedule removal of arch/ppc
From: Josh Boyer @ 2007-07-03 13:25 UTC (permalink / raw)
To: paulus; +Cc: linuxppc-dev
The arch/ppc tree has been in a semi-nebulous "bug fix only" state for a
few kernel releases now. The patch below officially declares this as of
the 2.6.22 kernel release and schedules arch/ppc for removal in June of
2008.
Signed-off-by: Josh Boyer <jwboyer@linux.vnet.ibm.com>
---
Documentation/feature-removal-schedule.txt | 12 ++++++++++++
1 file changed, 12 insertions(+)
--- linux-2.6.orig/Documentation/feature-removal-schedule.txt
+++ linux-2.6/Documentation/feature-removal-schedule.txt
@@ -348,3 +348,15 @@ Who: Tejun Heo <htejun@gmail.com>
---------------------------
+What: The arch/ppc and include/asm-ppc directories
+When: Jun 2008
+Why: The arch/powerpc tree is the merged architecture for ppc32 and ppc64
+ platforms. Currently there are efforts underway to port the remaining
+ arch/ppc platforms to the merged tree. New submissions to the arch/ppc
+ tree have been frozen with the 2.6.22 kernel release and that tree will
+ remain in bug-fix only mode until its scheduled removal. Platforms
+ that are not ported by June 2008 will be removed due to the lack of an
+ interested maintainer.
+Who: linuxppc-dev@ozlabs.org
+
+---------------------------
^ permalink raw reply
* Re: Patches added to 2.6.23 branch
From: Christoph Hellwig @ 2007-07-03 14:13 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev
In-Reply-To: <18057.57417.999506.887803@cargo.ozlabs.ibm.com>
On Tue, Jul 03, 2007 at 03:36:09PM +1000, Paul Mackerras wrote:
> [POWERPC] spufs: Add stat file to spufs
> [POWERPC] spufs: Add spu stats in sysfs
These two should not go to Linus yet, they'll probably need quite a bit
of rework.
^ permalink raw reply
* Re: How to handle patches that cross maintainers?
From: Christoph Hellwig @ 2007-07-03 14:13 UTC (permalink / raw)
To: Kumar Gala
Cc: linuxppc-dev list, Andrew Morton, Paul Mackerras,
Linux Kernel Development
In-Reply-To: <4BEFAFC6-3346-4F29-B1C5-377952E3FBBF@kernel.crashing.org>
On Tue, Jul 03, 2007 at 04:01:20AM -0500, Kumar Gala wrote:
> Andrew,
>
> I was hoping to get your input on how to handle patches that cross
> maintainers. I've got a patch that is pretty PPC specific, but
> happens to touch some drivers as well.
I think the real question is why the heck does it touch those drivers?
:)
^ permalink raw reply
* Re: Patches added to 2.6.23 branch
From: Christoph Hellwig @ 2007-07-03 14:15 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev
In-Reply-To: <18057.57417.999506.887803@cargo.ozlabs.ibm.com>
On Tue, Jul 03, 2007 at 03:36:09PM +1000, Paul Mackerras wrote:
> The following patches have been added to the for-2.6.23 branch on
> powerpc.git. In addition, the master branch has the merge of the
> for-2.6.23 and merge branches, which means that it is up-to-date with
> Linus' 2.6.22-rc7 plus the patches I recently asked Linus to pull for
> inclusion in 2.6.22.
What happened to Ben's and my signal and ptrace patches?
^ permalink raw reply
* Re: [PATCH v2] Schedule removal of arch/ppc
From: Tom Gall @ 2007-07-03 14:47 UTC (permalink / raw)
To: Josh Boyer; +Cc: linuxppc-dev, paulus
In-Reply-To: <1183469146.3590.7.camel@weaponx.rchland.ibm.com>
[-- Attachment #1: Type: text/plain, Size: 1656 bytes --]
June 2008 is a long time away to let this linger. Why not say by End of the
year 2007? That should give folks essentially two more 2.6 releases.
Regards,
Tom
On 7/3/07, Josh Boyer <jwboyer@linux.vnet.ibm.com> wrote:
>
> The arch/ppc tree has been in a semi-nebulous "bug fix only" state for a
> few kernel releases now. The patch below officially declares this as of
> the 2.6.22 kernel release and schedules arch/ppc for removal in June of
> 2008.
>
> Signed-off-by: Josh Boyer <jwboyer@linux.vnet.ibm.com>
>
> ---
> Documentation/feature-removal-schedule.txt | 12 ++++++++++++
> 1 file changed, 12 insertions(+)
>
> --- linux-2.6.orig/Documentation/feature-removal-schedule.txt
> +++ linux-2.6/Documentation/feature-removal-schedule.txt
> @@ -348,3 +348,15 @@ Who: Tejun Heo <htejun@gmail.com>
>
> ---------------------------
>
> +What: The arch/ppc and include/asm-ppc directories
> +When: Jun 2008
> +Why: The arch/powerpc tree is the merged architecture for ppc32 and
> ppc64
> + platforms. Currently there are efforts underway to port the
> remaining
> + arch/ppc platforms to the merged tree. New submissions to the
> arch/ppc
> + tree have been frozen with the 2.6.22 kernel release and that tree
> will
> + remain in bug-fix only mode until its scheduled removal. Platforms
> + that are not ported by June 2008 will be removed due to the lack of
> an
> + interested maintainer.
> +Who: linuxppc-dev@ozlabs.org
> +
> +---------------------------
>
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
>
[-- Attachment #2: Type: text/html, Size: 2515 bytes --]
^ permalink raw reply
* Re: Anyone using QE UART mode?
From: Timur Tabi @ 2007-07-03 14:59 UTC (permalink / raw)
To: Ying Lin; +Cc: linuxppc-embedded
In-Reply-To: <8F798BFDA851B943B3A1B2510E9287850350A90D@airmail.wirelessworld.airvananet.com>
Ying Lin wrote:
>
>> Which chip are you using? There should be separate 16550 compatible
>> UART controller on MPC8360. The driver is already there and working
>> pretty well.
>
> We are using MPC8323E. We have 2 working serial ports from the DUART
> controller, but we need more than 2.
>
> We have about 4 weeks to make them working, any suggestion where to
> start? We plan to start with CW QE Utility generated codes.
Have you tried using a PCI UART card?
--
Timur Tabi
Linux Kernel Developer @ Freescale
^ 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