* [PATCH 0/2] QE clock source improvements
From: Timur Tabi @ 2007-12-03 21:17 UTC (permalink / raw)
To: netdev, linuxppc-dev, galak
This patch set adds a new property to make specifying QE clock sources
easier, adds a function to help parse the property, and updates the ucc_geth
driver to take advantage of all this.
Patch #1 is an arch/powerpc patch meant for Kumar's for-2.6.25 branch.
Patch #2 is a netdev patch, so it's either for Jeff G and/or Kumar.
^ permalink raw reply
* [PATCH 2/2] ucc_geth: use rx-clock-name and tx-clock-name device tree properties
From: Timur Tabi @ 2007-12-03 21:17 UTC (permalink / raw)
To: netdev, linuxppc-dev, galak; +Cc: Timur Tabi
In-Reply-To: <1196716680381-git-send-email-timur@freescale.com>
Updates the ucc_geth device driver to check the new rx-clock-name and
tx-clock-name properties first. If present, it uses the new function
qe_clock_source() to obtain the clock source. Otherwise, it checks the
deprecated rx-clock and tx-clock properties.
Update the device trees for 832x, 836x, and 8568 to contain the new property
names only.
Signed-off-by: Timur Tabi <timur@freescale.com>
---
This patch applies to Kumar's for-2.6.25 branch. ucc_geth will compile but not
run if my other patch, "qe: add function qe_clock_source" has not also been
applied.
arch/powerpc/boot/dts/mpc832x_mds.dts | 8 ++--
arch/powerpc/boot/dts/mpc832x_rdb.dts | 8 ++--
arch/powerpc/boot/dts/mpc836x_mds.dts | 8 ++--
arch/powerpc/boot/dts/mpc8568mds.dts | 8 ++--
drivers/net/ucc_geth.c | 55 ++++++++++++++++++++++++++++++--
5 files changed, 67 insertions(+), 20 deletions(-)
diff --git a/arch/powerpc/boot/dts/mpc832x_mds.dts b/arch/powerpc/boot/dts/mpc832x_mds.dts
index c64f303..fe54489 100644
--- a/arch/powerpc/boot/dts/mpc832x_mds.dts
+++ b/arch/powerpc/boot/dts/mpc832x_mds.dts
@@ -223,8 +223,8 @@
*/
mac-address = [ 00 00 00 00 00 00 ];
local-mac-address = [ 00 00 00 00 00 00 ];
- rx-clock = <19>;
- tx-clock = <1a>;
+ rx-clock-name = "clk9";
+ tx-clock-name = "clk10";
phy-handle = < &phy3 >;
pio-handle = < &pio3 >;
};
@@ -244,8 +244,8 @@
*/
mac-address = [ 00 00 00 00 00 00 ];
local-mac-address = [ 00 00 00 00 00 00 ];
- rx-clock = <17>;
- tx-clock = <18>;
+ rx-clock-name = "clk7";
+ tx-clock-name = "clk8";
phy-handle = < &phy4 >;
pio-handle = < &pio4 >;
};
diff --git a/arch/powerpc/boot/dts/mpc832x_rdb.dts b/arch/powerpc/boot/dts/mpc832x_rdb.dts
index 388c8a7..e68a08b 100644
--- a/arch/powerpc/boot/dts/mpc832x_rdb.dts
+++ b/arch/powerpc/boot/dts/mpc832x_rdb.dts
@@ -202,8 +202,8 @@
*/
mac-address = [ 00 00 00 00 00 00 ];
local-mac-address = [ 00 00 00 00 00 00 ];
- rx-clock = <20>;
- tx-clock = <13>;
+ rx-clock-name = "clk16";
+ tx-clock-name = "clk3";
phy-handle = <&phy00>;
pio-handle = <&ucc2pio>;
};
@@ -223,8 +223,8 @@
*/
mac-address = [ 00 00 00 00 00 00 ];
local-mac-address = [ 00 00 00 00 00 00 ];
- rx-clock = <19>;
- tx-clock = <1a>;
+ rx-clock-name = "clk9";
+ tx-clock-name = "clk10";
phy-handle = <&phy04>;
pio-handle = <&ucc3pio>;
};
diff --git a/arch/powerpc/boot/dts/mpc836x_mds.dts b/arch/powerpc/boot/dts/mpc836x_mds.dts
index 0b2d2b5..bfd48d0 100644
--- a/arch/powerpc/boot/dts/mpc836x_mds.dts
+++ b/arch/powerpc/boot/dts/mpc836x_mds.dts
@@ -254,8 +254,8 @@
*/
mac-address = [ 00 00 00 00 00 00 ];
local-mac-address = [ 00 00 00 00 00 00 ];
- rx-clock = <0>;
- tx-clock = <19>;
+ rx-clock-name = "none";
+ tx-clock-name = "clk9";
phy-handle = < &phy0 >;
phy-connection-type = "rgmii-id";
pio-handle = < &pio1 >;
@@ -276,8 +276,8 @@
*/
mac-address = [ 00 00 00 00 00 00 ];
local-mac-address = [ 00 00 00 00 00 00 ];
- rx-clock = <0>;
- tx-clock = <14>;
+ rx-clock-name = "none";
+ tx-clock-name = "clk4";
phy-handle = < &phy1 >;
phy-connection-type = "rgmii-id";
pio-handle = < &pio2 >;
diff --git a/arch/powerpc/boot/dts/mpc8568mds.dts b/arch/powerpc/boot/dts/mpc8568mds.dts
index 5439437..cf45aab 100644
--- a/arch/powerpc/boot/dts/mpc8568mds.dts
+++ b/arch/powerpc/boot/dts/mpc8568mds.dts
@@ -333,8 +333,8 @@
*/
mac-address = [ 00 00 00 00 00 00 ];
local-mac-address = [ 00 00 00 00 00 00 ];
- rx-clock = <0>;
- tx-clock = <20>;
+ rx-clock-name = "none";
+ tx-clock-name = "clk16";
pio-handle = <&pio1>;
phy-handle = <&phy0>;
phy-connection-type = "rgmii-id";
@@ -355,8 +355,8 @@
*/
mac-address = [ 00 00 00 00 00 00 ];
local-mac-address = [ 00 00 00 00 00 00 ];
- rx-clock = <0>;
- tx-clock = <20>;
+ rx-clock-name = "none";
+ tx-clock-name = "clk16";
pio-handle = <&pio2>;
phy-handle = <&phy1>;
phy-connection-type = "rgmii-id";
diff --git a/drivers/net/ucc_geth.c b/drivers/net/ucc_geth.c
index a3ff270..a93342e 100644
--- a/drivers/net/ucc_geth.c
+++ b/drivers/net/ucc_geth.c
@@ -3814,6 +3814,7 @@ static int ucc_geth_probe(struct of_device* ofdev, const struct of_device_id *ma
int err, ucc_num, max_speed = 0;
const phandle *ph;
const unsigned int *prop;
+ const char *sprop;
const void *mac_addr;
phy_interface_t phy_interface;
static const int enet_to_speed[] = {
@@ -3846,10 +3847,56 @@ static int ucc_geth_probe(struct of_device* ofdev, const struct of_device_id *ma
ug_info->uf_info.ucc_num = ucc_num;
- prop = of_get_property(np, "rx-clock", NULL);
- ug_info->uf_info.rx_clock = *prop;
- prop = of_get_property(np, "tx-clock", NULL);
- ug_info->uf_info.tx_clock = *prop;
+ sprop = of_get_property(np, "rx-clock-name", NULL);
+ if (sprop) {
+ ug_info->uf_info.rx_clock = qe_clock_source(sprop);
+ if ((ug_info->uf_info.rx_clock < QE_CLK_NONE) ||
+ (ug_info->uf_info.rx_clock > QE_CLK24)) {
+ printk(KERN_ERR
+ "ucc_geth: invalid rx-clock-name property\n");
+ return -EINVAL;
+ }
+ } else {
+ prop = of_get_property(np, "rx-clock", NULL);
+ if (!prop) {
+ /* If both rx-clock-name and rx-clock are missing,
+ we want to tell people to use rx-clock-name. */
+ printk(KERN_ERR
+ "ucc_geth: missing rx-clock-name property\n");
+ return -EINVAL;
+ }
+ if ((*prop < QE_CLK_NONE) || (*prop > QE_CLK24)) {
+ printk(KERN_ERR
+ "ucc_geth: invalid rx-clock propperty\n");
+ return -EINVAL;
+ }
+ ug_info->uf_info.rx_clock = *prop;
+ }
+
+ sprop = of_get_property(np, "tx-clock-name", NULL);
+ if (sprop) {
+ ug_info->uf_info.tx_clock = qe_clock_source(sprop);
+ if ((ug_info->uf_info.tx_clock < QE_CLK_NONE) ||
+ (ug_info->uf_info.tx_clock > QE_CLK24)) {
+ printk(KERN_ERR
+ "ucc_geth: invalid tx-clock-name property\n");
+ return -EINVAL;
+ }
+ } else {
+ prop = of_get_property(np, "rx-clock", NULL);
+ if (!prop) {
+ printk(KERN_ERR
+ "ucc_geth: mising tx-clock-name property\n");
+ return -EINVAL;
+ }
+ if ((*prop < QE_CLK_NONE) || (*prop > QE_CLK24)) {
+ printk(KERN_ERR
+ "ucc_geth: invalid tx-clock property\n");
+ return -EINVAL;
+ }
+ ug_info->uf_info.tx_clock = *prop;
+ }
+
err = of_address_to_resource(np, 0, &res);
if (err)
return -EINVAL;
--
1.5.2.4
^ permalink raw reply related
* Re: [BUG] 2.6.24-rc3-git2 softlockup detected
From: Andrew Morton @ 2007-12-03 21:11 UTC (permalink / raw)
To: Kamalesh Babulal
Cc: rjw, linux-scsi, willy, linux-kernel, kyle, linuxppc-dev, balbir
In-Reply-To: <474FBB86.5000004@linux.vnet.ibm.com>
On Fri, 30 Nov 2007 12:58:06 +0530
Kamalesh Babulal <kamalesh@linux.vnet.ibm.com> wrote:
> Andrew Morton wrote:
> > On Thu, 29 Nov 2007 23:00:47 -0800 Andrew Morton <akpm@linux-foundation.org> wrote:
> >
> >> On Fri, 30 Nov 2007 01:39:29 -0500 Kyle McMartin <kyle@mcmartin.ca> wrote:
> >>
> >>> On Thu, Nov 29, 2007 at 12:35:33AM -0800, Andrew Morton wrote:
> >>>> ten million is close enough to infinity for me to assume that we broke the
> >>>> driver and that's never going to terminate.
> >>>>
> >>> how about this? doesn't break things on my pa8800:
> >>>
> >>> diff --git a/drivers/scsi/sym53c8xx_2/sym_hipd.c b/drivers/scsi/sym53c8xx_2/sym_hipd.c
> >>> index 463f119..ef01cb1 100644
> >>> --- a/drivers/scsi/sym53c8xx_2/sym_hipd.c
> >>> +++ b/drivers/scsi/sym53c8xx_2/sym_hipd.c
> >>> @@ -1037,10 +1037,13 @@ restart_test:
> >>> /*
> >>> * Wait 'til done (with timeout)
> >>> */
> >>> - for (i=0; i<SYM_SNOOP_TIMEOUT; i++)
> >>> + do {
> >>> if (INB(np, nc_istat) & (INTF|SIP|DIP))
> >>> break;
> >>> - if (i>=SYM_SNOOP_TIMEOUT) {
> >>> + msleep(10);
> >>> + } while (i++ < SYM_SNOOP_TIMEOUT);
> >>> +
> >>> + if (i >= SYM_SNOOP_TIMEOUT) {
> >>> printf ("CACHE TEST FAILED: timeout.\n");
> >>> return (0x20);
> >>> }
> >>> diff --git a/drivers/scsi/sym53c8xx_2/sym_hipd.h b/drivers/scsi/sym53c8xx_2/sym_hipd.h
> >>> index ad07880..85c483b 100644
> >>> --- a/drivers/scsi/sym53c8xx_2/sym_hipd.h
> >>> +++ b/drivers/scsi/sym53c8xx_2/sym_hipd.h
> >>> @@ -339,7 +339,7 @@
> >>> /*
> >>> * Misc.
> >>> */
> >>> -#define SYM_SNOOP_TIMEOUT (10000000)
> >>> +#define SYM_SNOOP_TIMEOUT (1000)
> >>> #define BUS_8_BIT 0
> >>> #define BUS_16_BIT 1
> >>>
> >> That might be the fix, but do we know what we're actually fixing? afaik
> >> 2.6.24-rc3 doesn't get this timeout, 2.6.24-rc3-mm2 does get it and we
> >> don't know why?
> >>
> >
> > <looks at Subject:>
> >
> > <Checks that Rafael was cc'ed>
> >
> > So 2.6.24-rc3 was OK and 2.6.24-rc3-git2 is not?
>
> Yes, the 2.6.24-rc3 was Ok and this is seen from 2.6.24-rc3-git2/3/4.
>
There are effectively no drivers/scsi/ changes after 2.6.24-rc3 and we
don't (I believe) have a clue what caused this regression.
Can you please do a bisection search on this?
Thanks.
^ permalink raw reply
* Re: [PATCH] Generic RTC class support for ppc_md.[gs]et_rtc_time
From: David Woodhouse @ 2007-12-03 21:06 UTC (permalink / raw)
To: benh; +Cc: linuxppc-dev
In-Reply-To: <1196714722.13230.224.camel@pasglop>
On Tue, 2007-12-04 at 07:45 +1100, Benjamin Herrenschmidt wrote:
> On Mon, 2007-12-03 at 17:04 +0000, David Woodhouse wrote:
> > It would be good to migrate the platform code to register RTC devices
> > directly, but for now this will make them functional enough for most
> > purposes...
>
> Wouldn't it be best to do the other way around at some stage ?
Yes, definitely. We can migrate them one at a time to the RTC class.
> We need to solve the problem of ppc_md. stuff being called by the core
> in atomic contexts first though.
Where from?
--
dwmw2
^ permalink raw reply
* [PATCH] Make QSpan PCI work
From: John Tyner @ 2007-12-03 21:05 UTC (permalink / raw)
To: linuxppc-dev
[-- Attachment #1: Type: text/plain, Size: 491 bytes --]
The following patch makes the QSpan PCI code compile and work on my
hardware. The patch is against 2.4, but I'm hoping it will still be viewed
as useful since the code currently does not even compile (2.6 is the
same). I had to make a change to move the PCI setup later in the
m8xx_setup code as well because the kernel would crash during the
pcibios_alloc_controller because the bootmem stuff had not come up yet.
Please CC me on any responses since I'm not subscribed.
Thanks,
John
[-- Attachment #2: qspan.patch --]
[-- Type: text/plain, Size: 24255 bytes --]
diff -ruNa linux-2.4.35.4.orig/arch/ppc/kernel/m8xx_setup.c linux-2.4.35.4/arch/ppc/kernel/m8xx_setup.c
--- linux-2.4.35.4.orig/arch/ppc/kernel/m8xx_setup.c 2007-11-17 09:23:15.000000000 -0800
+++ linux-2.4.35.4/arch/ppc/kernel/m8xx_setup.c 2007-11-29 14:38:41.000000000 -0800
@@ -65,6 +65,10 @@
{
int cpm_page;
+#ifdef CONFIG_PCI
+ m8xx_setup_pci_ptrs();
+#endif
+
cpm_page = (int) alloc_bootmem_pages(PAGE_SIZE);
/* Reset the Communication Processor Module.
@@ -364,10 +368,6 @@
if ( r3 )
memcpy( (void *)__res,(void *)(r3+KERNELBASE), sizeof(bd_t) );
-#ifdef CONFIG_PCI
- m8xx_setup_pci_ptrs();
-#endif
-
#ifdef CONFIG_BLK_DEV_INITRD
/* take care of initrd if we have one */
if ( r4 )
diff -ruNa linux-2.4.35.4.orig/arch/ppc/kernel/qspan_pci.c linux-2.4.35.4/arch/ppc/kernel/qspan_pci.c
--- linux-2.4.35.4.orig/arch/ppc/kernel/qspan_pci.c 2007-11-17 09:23:15.000000000 -0800
+++ linux-2.4.35.4/arch/ppc/kernel/qspan_pci.c 2007-12-03 11:22:44.000000000 -0800
@@ -28,6 +28,7 @@
#include <asm/machdep.h>
#include <asm/pci-bridge.h>
+#include "qspan_pci.h"
/*
* This blows......
@@ -83,7 +84,7 @@
" .align 2\n" \
" .long 1b,3b\n" \
".text" \
- : "=r"(x) : "r"(addr) : " %0")
+ : "+r"(x) : "r"(addr) )
#define QS_CONFIG_ADDR ((volatile uint *)(PCI_CSR_ADDR + 0x500))
#define QS_CONFIG_DATA ((volatile uint *)(PCI_CSR_ADDR + 0x504))
@@ -94,8 +95,8 @@
#define mk_config_type1(bus, dev, offset) \
mk_config_addr(bus, dev, offset) | 1;
-int qspan_pcibios_read_config_byte(unsigned char bus, unsigned char dev_fn,
- unsigned char offset, unsigned char *val)
+static int qspan_pcibios_read_config_byte(struct pci_dev * const dev,
+ int offset, u8 * const val)
{
uint temp;
u_char *cp;
@@ -103,7 +104,7 @@
unsigned long flags;
#endif
- if ((bus > 7) || (dev_fn > 127)) {
+ if ((dev->bus->number > 7) || (dev->devfn > 127)) {
*val = 0xff;
return PCIBIOS_DEVICE_NOT_FOUND;
}
@@ -115,10 +116,10 @@
eieio();
#endif
- if (bus == 0)
- *QS_CONFIG_ADDR = mk_config_addr(bus, dev_fn, offset);
+ if (dev->bus->number == 0)
+ *QS_CONFIG_ADDR = mk_config_addr(dev->bus->number, dev->devfn, offset);
else
- *QS_CONFIG_ADDR = mk_config_type1(bus, dev_fn, offset);
+ *QS_CONFIG_ADDR = mk_config_type1(dev->bus->number, dev->devfn, offset);
__get_qspan_pci_config(temp, QS_CONFIG_DATA, "lwz");
#ifdef CONFIG_RPXCLASSIC
@@ -133,8 +134,8 @@
return PCIBIOS_SUCCESSFUL;
}
-int qspan_pcibios_read_config_word(unsigned char bus, unsigned char dev_fn,
- unsigned char offset, unsigned short *val)
+static int qspan_pcibios_read_config_word(struct pci_dev * const dev,
+ int offset, u16 * const val)
{
uint temp;
ushort *sp;
@@ -142,7 +143,7 @@
unsigned long flags;
#endif
- if ((bus > 7) || (dev_fn > 127)) {
+ if ((dev->bus->number > 7) || (dev->devfn > 127)) {
*val = 0xffff;
return PCIBIOS_DEVICE_NOT_FOUND;
}
@@ -154,10 +155,10 @@
eieio();
#endif
- if (bus == 0)
- *QS_CONFIG_ADDR = mk_config_addr(bus, dev_fn, offset);
+ if (dev->bus->number == 0)
+ *QS_CONFIG_ADDR = mk_config_addr(dev->bus->number, dev->devfn, offset);
else
- *QS_CONFIG_ADDR = mk_config_type1(bus, dev_fn, offset);
+ *QS_CONFIG_ADDR = mk_config_type1(dev->bus->number, dev->devfn, offset);
__get_qspan_pci_config(temp, QS_CONFIG_DATA, "lwz");
offset ^= 0x02;
@@ -172,14 +173,14 @@
return PCIBIOS_SUCCESSFUL;
}
-int qspan_pcibios_read_config_dword(unsigned char bus, unsigned char dev_fn,
- unsigned char offset, unsigned int *val)
+static int qspan_pcibios_read_config_dword(struct pci_dev * const dev,
+ const int offset, u32 * const val)
{
#ifdef CONFIG_RPXCLASSIC
unsigned long flags;
#endif
- if ((bus > 7) || (dev_fn > 127)) {
+ if ((dev->bus->number > 7) || (dev->devfn > 127)) {
*val = 0xffffffff;
return PCIBIOS_DEVICE_NOT_FOUND;
}
@@ -191,10 +192,10 @@
eieio();
#endif
- if (bus == 0)
- *QS_CONFIG_ADDR = mk_config_addr(bus, dev_fn, offset);
+ if (dev->bus->number == 0)
+ *QS_CONFIG_ADDR = mk_config_addr(dev->bus->number, dev->devfn, offset);
else
- *QS_CONFIG_ADDR = mk_config_type1(bus, dev_fn, offset);
+ *QS_CONFIG_ADDR = mk_config_type1(dev->bus->number, dev->devfn, offset);
__get_qspan_pci_config(*val, QS_CONFIG_DATA, "lwz");
#ifdef CONFIG_RPXCLASSIC
@@ -206,8 +207,8 @@
return PCIBIOS_SUCCESSFUL;
}
-int qspan_pcibios_write_config_byte(unsigned char bus, unsigned char dev_fn,
- unsigned char offset, unsigned char val)
+static int qspan_pcibios_write_config_byte(struct pci_dev * const dev,
+ int offset, const u8 val)
{
uint temp;
u_char *cp;
@@ -215,10 +216,10 @@
unsigned long flags;
#endif
- if ((bus > 7) || (dev_fn > 127))
+ if ((dev->bus->number > 7) || (dev->devfn > 127))
return PCIBIOS_DEVICE_NOT_FOUND;
- qspan_pcibios_read_config_dword(bus, dev_fn, offset, &temp);
+ qspan_pcibios_read_config_dword(dev, offset, &temp);
offset ^= 0x03;
cp = ((u_char *)&temp) + (offset & 0x03);
@@ -231,10 +232,10 @@
eieio();
#endif
- if (bus == 0)
- *QS_CONFIG_ADDR = mk_config_addr(bus, dev_fn, offset);
+ if (dev->bus->number == 0)
+ *QS_CONFIG_ADDR = mk_config_addr(dev->bus->number, dev->devfn, offset);
else
- *QS_CONFIG_ADDR = mk_config_type1(bus, dev_fn, offset);
+ *QS_CONFIG_ADDR = mk_config_type1(dev->bus->number, dev->devfn, offset);
*QS_CONFIG_DATA = temp;
#ifdef CONFIG_RPXCLASSIC
@@ -246,8 +247,8 @@
return PCIBIOS_SUCCESSFUL;
}
-int qspan_pcibios_write_config_word(unsigned char bus, unsigned char dev_fn,
- unsigned char offset, unsigned short val)
+static int qspan_pcibios_write_config_word(struct pci_dev * const dev,
+ int offset, const u16 val)
{
uint temp;
ushort *sp;
@@ -255,10 +256,10 @@
unsigned long flags;
#endif
- if ((bus > 7) || (dev_fn > 127))
+ if ((dev->bus->number > 7) || (dev->devfn > 127))
return PCIBIOS_DEVICE_NOT_FOUND;
- qspan_pcibios_read_config_dword(bus, dev_fn, offset, &temp);
+ qspan_pcibios_read_config_dword(dev, offset, &temp);
offset ^= 0x02;
sp = ((ushort *)&temp) + ((offset >> 1) & 1);
@@ -271,10 +272,10 @@
eieio();
#endif
- if (bus == 0)
- *QS_CONFIG_ADDR = mk_config_addr(bus, dev_fn, offset);
+ if (dev->bus->number == 0)
+ *QS_CONFIG_ADDR = mk_config_addr(dev->bus->number, dev->devfn, offset);
else
- *QS_CONFIG_ADDR = mk_config_type1(bus, dev_fn, offset);
+ *QS_CONFIG_ADDR = mk_config_type1(dev->bus->number, dev->devfn, offset);
*QS_CONFIG_DATA = temp;
#ifdef CONFIG_RPXCLASSIC
@@ -286,14 +287,14 @@
return PCIBIOS_SUCCESSFUL;
}
-int qspan_pcibios_write_config_dword(unsigned char bus, unsigned char dev_fn,
- unsigned char offset, unsigned int val)
+static int qspan_pcibios_write_config_dword(struct pci_dev * const dev,
+ const int offset, const u32 val)
{
#ifdef CONFIG_RPXCLASSIC
unsigned long flags;
#endif
- if ((bus > 7) || (dev_fn > 127))
+ if ((dev->bus->number > 7) || (dev->devfn > 127))
return PCIBIOS_DEVICE_NOT_FOUND;
#ifdef CONFIG_RPXCLASSIC
@@ -303,10 +304,10 @@
eieio();
#endif
- if (bus == 0)
- *QS_CONFIG_ADDR = mk_config_addr(bus, dev_fn, offset);
+ if (dev->bus->number == 0)
+ *QS_CONFIG_ADDR = mk_config_addr(dev->bus->number, dev->devfn, offset);
else
- *QS_CONFIG_ADDR = mk_config_type1(bus, dev_fn, offset);
+ *QS_CONFIG_ADDR = mk_config_type1(dev->bus->number, dev->devfn, offset);
*(unsigned int *)QS_CONFIG_DATA = val;
#ifdef CONFIG_RPXCLASSIC
@@ -318,62 +319,140 @@
return PCIBIOS_SUCCESSFUL;
}
-int qspan_pcibios_find_device(unsigned short vendor, unsigned short dev_id,
- unsigned short index, unsigned char *bus_ptr,
- unsigned char *dev_fn_ptr)
+static void qspan_init( void )
{
- int num, devfn;
- unsigned int x, vendev;
+ qspan_t * const qs = (qspan_t *)PCI_CSR_ADDR;
- if (vendor == 0xffff)
- return PCIBIOS_BAD_VENDOR_ID;
- vendev = (dev_id << 16) + vendor;
- num = 0;
- for (devfn = 0; devfn < 32; devfn++) {
- qspan_pcibios_read_config_dword(0, devfn<<3, PCI_VENDOR_ID, &x);
- if (x == vendev) {
- if (index == num) {
- *bus_ptr = 0;
- *dev_fn_ptr = devfn<<3;
- return PCIBIOS_SUCCESSFUL;
- }
- ++num;
- }
- }
- return PCIBIOS_DEVICE_NOT_FOUND;
+ /*
+ * clear all PCI error status
+ * disable SERR, and PERR
+ * disable I/O-space, memory-space, and bus mastering
+ */
+ qs->pci_cs = QSPCI_CS_D_PE | QSPCI_CS_S_SERR | QSPCI_CS_R_MA |
+ QSPCI_CS_R_TA | QSPCI_CS_S_TA | QSPCI_CS_DEVSEL( 1 ) |
+ QSPCI_CS_MD_PED;
+
+ /* Disable i20 mode */
+ qs->i20_cs |= QSI20_CS_I20_EN;
+
+ /* disable all slave and target images */
+ qs->pbti0_ctl = 0;
+ qs->pbti1_ctl = 0;
+ qs->qbsi0_at = 0;
+ qs->qbsi1_at = 0;
+
+ /*
+ * set latency timer to 8 clocks
+ * disable cache line
+ */
+ qs->pci_misc0 = 0;
+
+ /*
+ * allow PCI access to the 4KByte register file in PCI memory space
+ * (put at bottom, the PCI autoconfigure routine places PCI-memory
+ * devices found from the top of PCI memory space down)
+ */
+ qs->pci_bsm = 0;
+
+ /* disable the PCI configuration expansion ROM */
+ qs->pci_bsrom = 0;
+
+ /*
+ * set interrupt line to zero (this is a S/W register, its value
+ * is a don't care for the F/W)
+ */
+ qs->pci_misc1 = 0;
+
+ /* Enable PCI access to CPU DRAM at address 0 (64M) */
+ qs->pbti0_add = 0x00000000;
+ qs->pbti0_ctl = QSPBTI_CTL_EN | QSPBTI_CTL_BS( 10 ) | QSPBTI_CTL_PWEN;
+
+ /*
+ * enable error logging
+ */
+ qs->pb_errcs = QSPB_ERRCS_EN;
+
+ /*
+ * clear all IDMA error status
+ * initialize to PowerQUICC mode
+ */
+ qs->idma_cs = QSIDMA_CS_IRST | QSIDMA_CS_DONE | QSIDMA_CS_IPE |
+ QSIDMA_CS_IQE | QSIDMA_CS_IMODE;
+
+ /*
+ * disable all interrupts
+ * clear all interrupt status
+ * map all interrupts to the QBus
+ */
+ qs->int_ctl = 0;
+ qs->int_stat = ~0;
+ qs->int_dir = 0;
+
+ /*
+ * BG* input is synchronous to QCLK
+ * BG* input is synchronous to QCLK (acknowledge)
+ * QBus is big-endian
+ */
+ qs->misc_ctl = QSMISC_CTL_S_BG | QSMISC_CTL_S_BB |
+ QSMISC_CTL_MSTSLV( 3 );
+ qs->misc_ctl2 &= ~QSMISC_CTL2_QINT_PME;
+
+ /* setup slave image #0, 64KB window to PCI MEM space */
+ qs->qbsi0_ctl = 0;
+ qs->qbsi0_at = QSQBSI_AT_TA( PCI_ISA_MEM_ADDR >> 16 ) |
+ QSQBSI_AT_BS( 0 ) | QSQBSI_AT_EN;
+
+ /*
+ * clear all QBus error status
+ * enable QBus error log
+ */
+ qs->qb_errcs = QSQB_ERRCS_EN | QSQB_ERRCS_ES;
+
+ /* Matrix only enable Memory-space and bus-mastering */
+ qs->pci_cs |= QSPCI_CS_BM | QSPCI_CS_MS;
}
-int qspan_pcibios_find_class(unsigned int class_code, unsigned short index,
- unsigned char *bus_ptr, unsigned char *dev_fn_ptr)
+static struct pci_ops qspan_pci_ops =
{
- int devnr, x, num;
-
- num = 0;
- for (devnr = 0; devnr < 32; devnr++) {
- qspan_pcibios_read_config_dword(0, devnr<<3, PCI_CLASS_REVISION, &x);
- if ((x>>8) == class_code) {
- if (index == num) {
- *bus_ptr = 0;
- *dev_fn_ptr = devnr<<3;
- return PCIBIOS_SUCCESSFUL;
- }
- ++num;
- }
- }
- return PCIBIOS_DEVICE_NOT_FOUND;
-}
+ .read_byte = qspan_pcibios_read_config_byte,
+ .read_word = qspan_pcibios_read_config_word,
+ .read_dword = qspan_pcibios_read_config_dword,
+ .write_byte = qspan_pcibios_write_config_byte,
+ .write_word = qspan_pcibios_write_config_word,
+ .write_dword = qspan_pcibios_write_config_dword,
+};
-void __init
-m8xx_pcibios_fixup(void))
+void __init m8xx_pcibios_fixup(void)
{
- /* Lots to do here, all board and configuration specific. */
+ /* Lots to do here, all board and configuration specific. */
}
-void __init
-m8xx_setup_pci_ptrs(void))
+void __init m8xx_setup_pci_ptrs(void)
{
- set_config_access_method(qspan);
+ struct pci_controller * hose;
+
+ qspan_init();
ppc_md.pcibios_fixup = m8xx_pcibios_fixup;
-}
+ hose = pcibios_alloc_controller();
+ if ( !hose ) {
+ return;
+ }
+
+ hose->ops = &qspan_pci_ops;
+
+ hose->io_space.name = "PCI I/O";
+ hose->io_space.start = PCI_ISA_IO_ADDR;
+ hose->io_space.end = PCI_ISA_IO_ADDR + PCI_ISA_IO_SIZE - 1;
+ hose->io_space.flags = IORESOURCE_IO;
+
+ hose->io_resource = hose->io_space;
+
+ hose->mem_space.name = "PCI Memory";
+ hose->mem_space.start = PCI_ISA_MEM_ADDR;
+ hose->mem_space.end = PCI_ISA_MEM_ADDR + PCI_ISA_MEM_SIZE - 1;
+ hose->mem_space.flags = IORESOURCE_MEM;
+
+ hose->mem_resources[0] = hose->mem_space;
+}
diff -ruNa linux-2.4.35.4.orig/arch/ppc/kernel/qspan_pci.h linux-2.4.35.4/arch/ppc/kernel/qspan_pci.h
--- linux-2.4.35.4.orig/arch/ppc/kernel/qspan_pci.h 1969-12-31 16:00:00.000000000 -0800
+++ linux-2.4.35.4/arch/ppc/kernel/qspan_pci.h 2007-12-03 11:06:29.000000000 -0800
@@ -0,0 +1,195 @@
+#ifndef _PPC_KERNEL_QSPAN_PCI_H
+#define _PPC_KERNEL_QSPAN_PCI_H
+
+typedef struct qspan {
+ u32 pci_id; /* 0x000 - PCI configuration space ID register */
+ u32 pci_cs; /* 0x004 - PCI configuration space control and status register */
+ u32 pci_class; /* 0x008 - PCI configuration class register */
+ u32 pci_misc0; /* 0x00C - PCI configuration miscellaneous 0 register */
+ u32 pci_bsm; /* 0x010 - PCI configuration base address for memory register */
+ u32 pci_bsio; /* 0x014 - PCI configuration base address for I/O register */
+ u32 pci_u0[0x005]; /* 0x018 - PCI unimplemented */
+ u32 pci_sid; /* 0x02C - PCI configuration subsystem ID register */
+ u32 pci_bsrom; /* 0x030 - PCI configuration expansion ROM base address register */
+ u32 pci_r0[0x002]; /* 0x034 - PCI reserved */
+ u32 pci_misc1; /* 0x03C - PCI configuration miscellaneous 1 register */
+ u32 pci_u1[0x030]; /* 0x040 - PCI unimplemented */
+ u32 pbti0_ctl; /* 0x100 - PCI bus target image 0 control register */
+ u32 pbti0_add; /* 0x104 - PCI bus target image 0 address register */
+ u32 qspan_r0[0x002];/* 0x108 - QSpan reserved */
+ u32 pbti1_ctl; /* 0x110 - PCI bus target image 1 control register */
+ u32 pbti1_add; /* 0x114 - PCI bus target image 1 address register */
+ u32 qspan_r1[0x009];/* 0x118 - QSpan reserved */
+ u32 pbrom_ctl; /* 0x13C - PCI bus expansion ROM control register */
+ u32 pb_errcs; /* 0x140 - PCI bus error control and status register */
+ u32 pb_aerr; /* 0x144 - PCI bus address error log register */
+ u32 pb_derr; /* 0x148 - PCI bus data error log register */
+ u32 qspan_r2[0x02D];/* 0x14C - QSpan reserved */
+ u32 i20_cs; /* 0x200 - IDMA control and status register */
+ u32 qspan_r2a[0x07F];/* 0x204 - QSpan reserved */
+ u32 idma_cs; /* 0x400 - IDMA control and status register */
+ u32 idma_add; /* 0x404 - IDMA address register */
+ u32 idma_cnt; /* 0x408 - IDMA transfer count register */
+ u32 qspan_r3[0x03D];/* 0x40C - QSpan reserved */
+ u32 con_add; /* 0x500 - configuration address register */
+ u32 con_data; /* 0x504 - configuration data register */
+ u32 qspan_r4[0x03E];/* 0x508 - QSpan reserved */
+ u32 int_stat; /* 0x600 - interrupt status register */
+ u32 int_ctl; /* 0x604 - interrupt control register */
+ u32 int_dir; /* 0x608 - interrupt direction control register */
+ u32 qspan_r5[0x07D];/* 0x60C - QSpan reserved */
+ u32 misc_ctl; /* 0x800 - miscellaneous control and status register */
+ u32 eepprom_cs; /* 0x804 - reserved */
+ u32 misc_ctl2; /* 0x808 - misc ctl 2 */
+ u32 qspan_r6[0x1BD];/* 0x80c - QSpan reserved */
+ u32 qbsi0_ctl; /* 0xF00 - QBus slave image 0 control register */
+ u32 qbsi0_at; /* 0xF04 - QBus slave image 0 address translation register */
+ u32 qspan_r7[0x002];/* 0xF08 - QSpan reserved */
+ u32 qbsi1_ctl; /* 0xF10 - QBus slave image 1 control register */
+ u32 qbsi1_at; /* 0xF14 - QBus slave image 1 address translation register */
+ u32 qspan_r8[0x01A];/* 0xF18 - QSpan reserved */
+ u32 qb_errcs; /* 0xF80 - QBus error log control and status register */
+ u32 qb_aerr; /* 0xF84 - QBus address error log register */
+ u32 qb_derr; /* 0xF88 - QBus data error log register */
+ u32 qspan_r9[0x01D];/* 0xF8C - QSpan reserved */
+} qspan_t;
+
+#define QSPCI_CS_D_PE ( 1 << 31 )
+#define QSPCI_CS_S_SERR ( 1 << 30 )
+#define QSPCI_CS_R_MA ( 1 << 29 )
+#define QSPCI_CS_R_TA ( 1 << 28 )
+#define QSPCI_CS_S_TA ( 1 << 27 )
+#define QSPCI_CS_DEVSEL( x ) ( ( ( x ) & 0x3 ) << 25 )
+#define QSPCI_CS_MD_PED ( 1 << 24 )
+#define QSPCI_CS_TFBBC ( 1 << 23 )
+#define QSPCI_CS_DEV66 ( 1 << 21 )
+#define QSPCI_CS_CAP_L ( 1 << 20 )
+#define QSPCI_CS_MFFBC ( 1 << 9 )
+#define QSPCI_CS_SERR_EN ( 1 << 8 )
+#define QSPCI_CS_WAIT ( 1 << 7 )
+#define QSPCI_CS_PERESP ( 1 << 6 )
+#define QSPCI_CS_VGAPS ( 1 << 5 )
+#define QSPCI_CS_MWI_EN ( 1 << 4 )
+#define QSPCI_CS_SC ( 1 << 3 )
+#define QSPCI_CS_BM ( 1 << 2 )
+#define QSPCI_CS_MS ( 1 << 1 )
+#define QSPCI_CS_IOS ( 1 << 0 )
+
+#define QSPBTI_CTL_EN ( 1 << 31 )
+#define QSPBTI_CTL_BS( x ) ( ( ( x ) & 0xf ) << 24 )
+#define QSPBTI_CTL_PREN ( 1 << 23 )
+#define QSPBTI_CTL_BRSTWREN ( 1 << 22 )
+#define QSPBTI_CTL_INVEND ( 1 << 19 )
+#define QSPBTI_CTL_TC( x ) ( ( ( x ) & 0xf ) << 12 )
+#define QSPBTI_CTL_DSIZE( x ) ( ( ( x ) & 0x3 ) << 10 )
+#define QSPBTI_CTL_PWEN ( 1 << 7 )
+#define QSPBTI_CTL_PAS ( 1 << 6 )
+
+#define QSPB_ERRCS_EN ( 1 << 31 )
+#define QSPB_ERRCS_ES ( 1 << 24 )
+#define QSPB_ERRCS_UNL_QSC ( 1 << 23 )
+#define QSPB_ERRCS_CMDERR( x ) ( ( ( x ) & 0xf ) << 4 )
+#define QSPB_ERRCS_BE_ERR( x ) ( ( ( x ) & 0xf ) << 0 )
+
+#define QSI20_CS_QIBA( x ) ( ( ( x ) & 0xfff ) << 16 )
+#define QSI20_CS_IF_E ( 1 << 15 )
+#define QSI20_CS_IP_E ( 1 << 14 )
+#define QSI20_CS_OF_E ( 1 << 13 )
+#define QSI20_CS_OP_E ( 1 << 12 )
+#define QSI20_CS_IF_F ( 1 << 11 )
+#define QSI20_CS_IP_F ( 1 << 10 )
+#define QSI20_CS_OF_F ( 1 << 9 )
+#define QSI20_CS_OP_F ( 1 << 8 )
+#define QSI20_CS_FIFO_SIZE( x ) ( ( ( x ) & 0x7 ) << 4 )
+#define QSI20_CS_RR_BP ( 1 << 1 )
+#define QSI20_CS_I20_EN ( 1 << 0 )
+
+#define QSIDMA_CS_GO ( 1 << 31 )
+#define QSIDMA_CS_IRST_REQ ( 1 << 30 )
+#define QSIDMA_CS_ACT ( 1 << 23 )
+#define QSIDMA_CS_IRST ( 1 << 22 )
+#define QSIDMA_CS_DONE ( 1 << 21 )
+#define QSIDMA_CS_IPE ( 1 << 20 )
+#define QSIDMA_CS_IQE ( 1 << 19 )
+#define QSIDMA_CS_CMD ( 1 << 18 )
+#define QSIDMA_CS_IWM( x ) ( ( ( x ) & 0xf ) << 12 )
+#define QSIDMA_CS_TC( x ) ( ( ( x ) & 0xf ) << 8 )
+#define QSIDMA_CS_TC_EN ( 1 << 7 )
+#define QSIDMA_CS_CHAIN ( 1 << 6 )
+#define QSIDMA_CS_DMA ( 1 << 5 )
+#define QSIDMA_CS_DIR ( 1 << 4 )
+#define QSIDMA_CS_IMODE ( 1 << 3 )
+#define QSIDMA_CS_QTERM ( 1 << 2 )
+#define QSIDMA_CS_STERM ( 1 << 1 )
+#define QSIDMA_CS_PORT16 ( 1 << 0 )
+
+#define QSINT_PEL_IS ( 1 << 31 )
+#define QSINT_QEL_IS ( 1 << 30 )
+#define QSINT_MDPED_IS ( 1 << 29 )
+#define QSINT_PCSR_IS ( 1 << 28 )
+#define QSINT_IQE_IS ( 1 << 27 )
+#define QSINT_IPE_IS ( 1 << 26 )
+#define QSINT_IRST_IS ( 1 << 25 )
+#define QSINT_DONE_IS ( 1 << 24 )
+#define QSINT_INT_IS ( 1 << 23 )
+#define QSINT_PERR_IS ( 1 << 22 )
+#define QSINT_SERR_IS ( 1 << 21 )
+#define QSINT_QINT_IS ( 1 << 20 )
+#define QSINT_MB3_IS ( 1 << 19 )
+#define QSINT_MB2_IS ( 1 << 18 )
+#define QSINT_MB1_IS ( 1 << 17 )
+#define QSINT_MB0_IS ( 1 << 16 )
+#define QSINT_QDPE_S ( 1 << 15 )
+#define QSINT_PSC_IS ( 1 << 14 )
+#define QSINT_OPNE_S ( 1 << 13 )
+#define QSINT_IPN_IS ( 1 << 12 )
+#define QSINT_IFE_S ( 1 << 11 )
+#define QSINT_OFE_S ( 1 << 10 )
+#define QSINT_IPF_S ( 1 << 9 )
+#define QSINT_OFF_S ( 1 << 8 )
+#define QSINT_SI3_IS ( 1 << 3 )
+#define QSINT_SI2_IS ( 1 << 2 )
+#define QSINT_SI1_IS ( 1 << 1 )
+#define QSINT_SI0_IS ( 1 << 0 )
+
+#define QSMISC_CTL_SW_RST ( 1 << 31 )
+#define QSMISC_CTL_S_BG ( 1 << 19 )
+#define QSMISC_CTL_S_BB ( 1 << 18 )
+#define QSMISC_CTL_QB_BOC ( 1 << 16 )
+#define QSMISC_CTL_QB_MA_BE_D ( 1 << 12 )
+#define QSMISC_CTL_QFIFO_BLK8 ( 1 << 9 )
+#define QSMISC_CTL_QFIFO_MODE ( 1 << 8 )
+#define QSMISC_CTL_PRCNT( x ) ( ( ( x ) & 0x3f ) << 2 )
+#define QSMISC_CTL_MSTSLV( x ) ( ( ( x ) & 0x3 ) << 0 )
+
+#define QSMISC_CTL2_PCI_DIS ( 1 << 31 )
+#define QSMISC_CTL2_PTP_IB ( 1 << 23 )
+#define QSMISC_CTL2_KEEP_BB ( 1 << 22 )
+#define QSMISC_CTL2_MAX_RTRY( x ) ( ( ( x ) & 0x3 ) << 20 )
+#define QSMISC_CTL2_PTC_PD ( 1 << 19 )
+#define QSMISC_CTL2_TA_BE_EN ( 1 << 18 )
+#define QSMISC_CTL2_BURST_4 ( 1 << 17 )
+#define QSMISC_CTL2_PR_SING ( 1 << 16 )
+#define QSMISC_CTL2_PRCNT2( x ) ( ( ( x ) & 0x3f ) << 10 )
+#define QSMISC_CTL2_REG_AC ( 1 << 9 )
+#define QSMISC_CTL2_QSC_PW ( 1 << 8 )
+#define QSMISC_CTL2_QBUS_PAR ( 1 << 4 )
+#define QSMISC_CTL2_EEPROM_ACC ( 1 << 3 )
+#define QSMISC_CTL2_NOTO ( 1 << 2 )
+#define QSMISC_CTL2_PSC_QRST ( 1 << 1 )
+#define QSMISC_CTL2_QINT_PME ( 1 << 0 )
+
+#define QSQBSI_CTL_PWEN ( 1 << 31 )
+#define QSQBSI_CTL_PAS ( 1 << 24 )
+#define QSQBSI_CTL_PREN ( 1 << 23 )
+
+#define QSQBSI_AT_TA( x ) ( ( ( x ) & 0xffff ) << 16 )
+#define QSQBSI_AT_BS( x ) ( ( ( x ) & 0xf ) << 4 )
+#define QSQBSI_AT_EN ( 1 << 0 )
+
+#define QSQB_ERRCS_EN ( 1 << 31 )
+#define QSQB_ERRCS_ES ( 1 << 24 )
+#define QSQB_ERRCS_TC_ERR( x ) ( ( ( x ) & 0xf ) << 4 )
+#define QSQB_ERRCS_SIZ_ERR( x ) ( ( ( x ) & 0x3 ) << 0 )
+
+#endif
^ permalink raw reply
* Re: [PATCH] Add IPIC MSI interrupt support
From: Benjamin Herrenschmidt @ 2007-12-03 21:03 UTC (permalink / raw)
To: Li Li; +Cc: linuxppc-dev, Gala Kumar, Li Tony
In-Reply-To: <1196672870.14353.21.camel@Guyver>
On Mon, 2007-12-03 at 17:07 +0800, Li Li wrote:
>
> In IPIC, the 8 MSI interrupts is handled as level intrrupt.
> I just provide a versatile in case it is changed.
Level ? Are you sure ? MSIs are by definition edge interrupts... Or do
you have some weird logic that asserts a level input until you go ack
something ? Sounds weird...
Ben.
^ permalink raw reply
* Re: [PATCH] ipic: change ack operation that register is accessed only when needed
From: Benjamin Herrenschmidt @ 2007-12-03 21:02 UTC (permalink / raw)
To: Li Yang; +Cc: linuxppc-dev
In-Reply-To: <1196684780-28408-1-git-send-email-leoli@freescale.com>
> static void ipic_ack_irq(unsigned int virq)
> {
> - struct ipic *ipic = ipic_from_irq(virq);
> unsigned int src = ipic_irq_to_hw(virq);
> - unsigned long flags;
> - u32 temp;
>
> - spin_lock_irqsave(&ipic_lock, flags);
> + /* Only external interrupts in edge mode support ACK */
> + if (unlikely(ipic_info[src].ack &&
> + ((get_irq_desc(virq)->status & IRQ_TYPE_SENSE_MASK) ==
> + IRQ_TYPE_EDGE_FALLING))) {
> + struct ipic *ipic = ipic_from_irq(virq);
> + unsigned long flags;
> + u32 temp;
>
> - temp = ipic_read(ipic->regs, ipic_info[src].pend);
> - temp |= (1 << (31 - ipic_info[src].bit));
> - ipic_write(ipic->regs, ipic_info[src].pend, temp);
> + spin_lock_irqsave(&ipic_lock, flags);
>
> - spin_unlock_irqrestore(&ipic_lock, flags);
> + temp = ipic_read(ipic->regs, ipic_info[src].ack);
> + temp |= (1 << (31 - ipic_info[src].bit));
> + ipic_write(ipic->regs, ipic_info[src].ack, temp);
> +
> + spin_unlock_irqrestore(&ipic_lock, flags);
> + }
> }
That doesn't look right...
That should be handled by the higher level flow handler. The generic
edge one calls ack and the level one mask_and_ack. Just make them do the
right thing, no need to test for the flow type in the low level
function.
Ben.
^ permalink raw reply
* [PATCH] Fix 8xx compile errors
From: John Tyner @ 2007-12-03 20:58 UTC (permalink / raw)
To: linuxppc-dev
[-- Attachment #1: Type: text/plain, Size: 518 bytes --]
Building for 8xx fails to compile due to errors in a couple of places.
The first is due to the casting of an lvalue (if I remember correctly),
and the second was due to the cpmp variable being declared static even
though the headers previously defined it as extern. The following patch
corrects these errors. The patch is against 2.4 since that's what I'm
working with. (I've been unable to get 2.6 to run properly on my
hardware so far.)
Please CC me on any responses since I'm not subscribed.
Thanks,
John
[-- Attachment #2: 8xx_compile.patch --]
[-- Type: text/plain, Size: 1125 bytes --]
diff -ruNa linux-2.4.35.4.orig/arch/ppc/8xx_io/uart.c linux-2.4.35.4/arch/ppc/8xx_io/uart.c
--- linux-2.4.35.4.orig/arch/ppc/8xx_io/uart.c 2007-11-17 09:23:15.000000000 -0800
+++ linux-2.4.35.4/arch/ppc/8xx_io/uart.c 2007-11-27 11:28:09.000000000 -0800
@@ -2292,7 +2292,8 @@
/* Get the address of the host memory buffer.*/
info = &consinfo;
- info->tx_bd_base = (cbd_t *)bdbase = (cbd_t *)&cpmp->cp_dpmem[up->smc_tbase];
+ bdbase = (cbd_t *)&cpmp->cp_dpmem[up->smc_tbase];
+ info->tx_bd_base = (cbd_t *)bdbase;
info->tx_cur = (cbd_t *)bdbase;
}
max_tx_size = console_tx_buf_len;
diff -ruNa linux-2.4.35.4.orig/arch/ppc/boot/simple/m8xx_tty.c linux-2.4.35.4/arch/ppc/boot/simple/m8xx_tty.c
--- linux-2.4.35.4.orig/arch/ppc/boot/simple/m8xx_tty.c 2007-11-17 09:23:15.000000000 -0800
+++ linux-2.4.35.4/arch/ppc/boot/simple/m8xx_tty.c 2007-11-27 11:28:42.000000000 -0800
@@ -30,7 +30,7 @@
#define SMC_INDEX 0
#endif
-static cpm8xx_t *cpmp = (cpm8xx_t *)&(((immap_t *)IMAP_ADDR)->im_cpm);
+cpm8xx_t *cpmp = (cpm8xx_t *)&(((immap_t *)IMAP_ADDR)->im_cpm);
unsigned long
serial_init(int ignored, bd_t *bd)
^ permalink raw reply
* Re: [PATCH 4/5] PowerPC 74xx: Katana Qp base support
From: Benjamin Herrenschmidt @ 2007-12-03 20:54 UTC (permalink / raw)
To: Andrei Dolnikov; +Cc: linuxppc-dev
In-Reply-To: <20071129154200.GE13751@ru.mvista.com>
On Thu, 2007-11-29 at 18:42 +0300, Andrei Dolnikov wrote:
> +config PPC_KATANAQP
> + bool "Emerson-Katana Qp"
> + depends on EMBEDDED6xx
> + select MV64X60
> + select NOT_COHERENT_CACHE
^^^^^^^^^^^^^^^^^^
Just one word: ARGHHHHHHHH !
Oh and another one: WHY ?
Ben.
^ permalink raw reply
* Re: [PATCH 1/5] PowerPC 74xx: Katana Qp device tree
From: Benjamin Herrenschmidt @ 2007-12-03 20:52 UTC (permalink / raw)
To: Andrei Dolnikov; +Cc: linuxppc-dev
In-Reply-To: <20071129152836.GB13751@ru.mvista.com>
> #address-cells = <1>;
> + #size-cells = <1>;
> + model = "Katana-Qp"; /* Default */
> + compatible = "emerson,Katana-Qp";
> + coherency-off;
> +
What do that mean (coherency-off) ?
Somebody is trying again to use a 74xx with non cache coherent DMA ?
That isn't going to fly...
Ben.
^ permalink raw reply
* [PATCH] Add abort for fsl-devices which lack an RSTCR register.
From: Clemens Koller @ 2007-12-03 20:51 UTC (permalink / raw)
To: Linuxppc-embedded, Kumar Gala, robert lazarski
[-- Attachment #1: Type: text/plain, Size: 842 bytes --]
This adds a fallback and calls abort() (in head_fsl_booke.S) to be able
to successfully reset some older freescale devices (i.e. mpc8540)
which don't have a RSTCR register.
Robert, this should also fix your issues. Please test.
Kumar, please ACK/NACK the patch since you touched fsl_rstcr_restart()
last time (2007-10-04). Maybe the call to abort (which resets the processor via
the Debug Control Register 0) could be put somewhere else or
we create another entry for the device tree.
Otherwise, I would prefer to check the PVR/SVR registers and use
a suitable cpu_reset() call which fits to the current cpu.
Regards,
--
Clemens Koller
__________________________________
R&D Imaging Devices
Anagramm GmbH
Rupert-Mayer-Straße 45/1
Linhof Werksgelände
D-81379 München
Tel.089-741518-50
Fax 089-741518-19
http://www.anagramm-technology.com
[-- Attachment #2: powerpc-add-abort-to-reset-systems-without-rstcr-register.patch --]
[-- Type: text/plain, Size: 883 bytes --]
Add a fallback to abort() call (in head_fsl_booke.S) to be able to
successfully reset some older freescale power devices (i.e. mpc8540)
which don't have a rstcr register.
Signed-off-by: Clemens Koller <clemens.koller@anagramm.de>
diff --git a/arch/powerpc/sysdev/fsl_soc.c b/arch/powerpc/sysdev/fsl_soc.c
index 3ace747..6fe674a 100644
--- a/arch/powerpc/sysdev/fsl_soc.c
+++ b/arch/powerpc/sysdev/fsl_soc.c
@@ -42,6 +42,7 @@
extern void init_fcc_ioports(struct fs_platform_info*);
extern void init_fec_ioports(struct fs_platform_info*);
extern void init_smc_ioports(struct fs_uart_platform_info*);
+extern void abort(void);
static phys_addr_t immrbase = -1;
phys_addr_t get_immrbase(void)
@@ -1336,6 +1337,8 @@ void fsl_rstcr_restart(char *cmd)
if (rstcr)
/* set reset control register */
out_be32(rstcr, 0x2); /* HRESET_REQ */
+ else
+ abort();
while (1) ;
}
^ permalink raw reply related
* Re: [PATCH] Generic RTC class support for ppc_md.[gs]et_rtc_time
From: Benjamin Herrenschmidt @ 2007-12-03 20:45 UTC (permalink / raw)
To: David Woodhouse; +Cc: linuxppc-dev
In-Reply-To: <1196701493.13978.163.camel@pmac.infradead.org>
On Mon, 2007-12-03 at 17:04 +0000, David Woodhouse wrote:
> It would be good to migrate the platform code to register RTC devices
> directly, but for now this will make them functional enough for most
> purposes...
Wouldn't it be best to do the other way around at some stage ?
We need to solve the problem of ppc_md. stuff being called by the core
in atomic contexts first though.
Ben.
^ permalink raw reply
* RE: Cannot login via tinylogin on sequoia
From: Leonid @ 2007-12-03 20:25 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <406A31B117F2734987636D6CCC93EE3C028D2294@ehost011-3.exch011.intermedia.net>
I can avoid login procedure at all by replacing tinylogin call by simple
sh in inittab or by removing inittab at all:
#::askfirst:/bin/tinylogin login -f root=20
::askfirst:/bin/sh
I get shell prompt all right without logging. However login doesn't work
and I don't understand why.=20
I tried to change password using passwd (user: root, password: root),
but login still doesn't work:
/ # passwd root
Changing password for root
Enter the new password (minimum of 5, maximum of 8 characters) Please
use a combination of upper and lower case letters and numbers.
Enter new password:
Re-enter new password:
Password changed.
/ # Dec 31 18:02:29 Sequoia auth.info passwd[38]: password for `root'
changed by user `root'
/ # login
Sequoia login: root
Password:
Login incorrect
Does somebody know a way to make tinylogin give out more detailed
iunformation? Of course, I can always debug it since I have source...
Thanks,
Leonid.
-----Original Message-----
From: linuxppc-embedded-bounces+leonid=3Da-k-a.net@ozlabs.org
[mailto:linuxppc-embedded-bounces+leonid=3Da-k-a.net@ozlabs.org] On =
Behalf
Of Leonid
Sent: Friday, November 30, 2007 3:10 PM
To: linuxppc-embedded@ozlabs.org
Subject: Cannot login via tinylogin on sequoia
Hi:
I have built u-boot, kernel and filesystem using ELDK 4.1 for AMCC
PPC440EPx sequoia board. When I boot linux using NFS filesystem,
supplied with ELDK itself, I can login (usrr root, no password). However
I couldn't login while used ramdisk, built by myself or taken from AMCC
resource CD. Combinations root/root or root/nothing don't work.=20
Sequoia login: root
Password:
Login incorrect
Please press Enter to activate this console. Dec 31 18:00:26 Sequoia
auth.warn login[37]: invalid password for `UNKNOWN' on `ttyS0'
Dec 31 18:00:26 Sequoia daemon.info init: Process '/bin/tinylogin login
-f root' (pid 37) exited. Scheduling it for restart.
How I can learn what user/password combination are configured and how do
I change them? This is static/etc/passwd from my SIMPLE filesystem:
root::0:0:root:/root:/bin/sh
bin:*:1:1:bin:/bin:
daemon:*:2:2:daemon:/sbin:
halt:*:7:0:halt:/sbin:/sbin/halt
ftp:*:14:50:FTP User:/
nobody:*:99:99:Nobody:/:
target:$1$x4Rc1j78$n5FVlLwarSyMYoZaMlijU1:200:100:Test
User:/home:/bin/sh
Thanks,
Leonid.
_______________________________________________
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded
^ permalink raw reply
* SMP on linux with Microblaze?
From: khollan @ 2007-12-03 20:06 UTC (permalink / raw)
To: linuxppc-embedded
Now that Full Linux can run on Microblaze with the addition of the MMU, are
there plans to enable Symmetric Multi-Processing of two or more Microblaze
cores running Linux?
--
View this message in context: http://www.nabble.com/SMP-on-linux-with-Microblaze--tf4939013.html#a14137760
Sent from the linuxppc-embedded mailing list archive at Nabble.com.
^ permalink raw reply
* Re: OT: Re: solved: Re: [rtc-linux] Re: DS1337 RTC on I2C broken.
From: Grant Likely @ 2007-12-03 20:05 UTC (permalink / raw)
To: Clemens Koller; +Cc: Alessandro Zummo, rtc-linux, linuxppc-embedded
In-Reply-To: <47545A81.90804@anagramm.de>
On 12/3/07, Clemens Koller <clemens.koller@anagramm.de> wrote:
> Hello, Scott!
>
> Scott Wood schrieb:
> >> Here, the next idea which comes to my mind:
> >> Maybe we should think about a kernel-config -> dts compiler for
> >> the future where the enabled drivers generate their default dts
> >> entries automagically?
> >
> > Sorry, there's just not enough information in .config for that.
>
> If there is really the need to put more information (which I don't
> see in the case of the RTCs) to .config, it might be an idea to
> extend the current structure for this use instead of duplicating
> and maintaining a second repository.
>
> And regarding the DS1337 (or the PCF8563 and similar RTCs):
> It's address (0x68) is immutable fixed by the manufacturer
> of that device. So, why do we include it in the DT, when we
> already told the kernel what driver we want to use?
I2C is an odd bus in that it is only partially probeable; you can
probe for presence, but you can't trust that you know what is there.
The device tree approach sidesteps that uncertainty by just mandating
that you specify that address and type of each device. This is
neither hard or onerous on the developer to do.
If we *could* trust the i2c probing (like we can on PCI), then i2c
devices would *not* need to be in the device tree.
> Even if I have an eeprom which can have varying addresses,
> I can simply tell the driver/the kernel .config what address
> it should use... If I want to be able to alter that address
> for whatever reason by OF, I still don't want to touch a
> separate file in the kernel tree.
Kconfig was never designed for that type of board level detail and it
would be awkward to shoehorn that in (not to mention that it doesn't
solve the problem of one kernel running on many boards.)
Historically we solved the config problem with board specific code in
.c files. A solution I'm sure you'll agree might work, but it's not
sustainable in the long run.
As for modifying the device tree; you've got many choices; choose what
works best for you.
For example, you could:
a. write a separate .dts file per board varient, or
b. write single .dts files which only contains the common properties
and the bootloader populates the board specific ones, or
c. write a single .dts file which contains all possible nodes and the
bootloader deletes the nodes which are irrelevant.
Regardless of what method you choose, you just need to make sure that
the device tree that the kernel receives is an accurate representation
of the hardware (ie. no nodes for non-present devices)
Cheers,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195
^ permalink raw reply
* Re: Maximum ioremap size for ppc arch?
From: David Hawkins @ 2007-12-03 19:51 UTC (permalink / raw)
To: Matt Porter; +Cc: linuxppc-embedded
In-Reply-To: <20071203190723.GB30746@gate.crashing.org>
Hi Matt,
> Yes, same thing. There's N ways to fix it. But I see you're talking
> x86.
>
>> PS. The CPUs in this case are x86 based, while the PCI boards use
>> PLX-9054 bridges. I'm building new peripheral boards with MPC8349EAs
>> so this problem is going to rear its ugly head again soon, when
>> I work on the drivers for the new peripheral boards.
>
> You should be able to do something similar on x86 but the details
> are TBD. I would probably try to limit low memory to 512MB in the
> x86 case.
Yeah, that works for me. The CPUs were ordered with 512MB,
but arrived with 1GB. It was thought a windfall at the time ...
but not-so after the driver weirdness :)
Thanks for the info. Now at least if I want to understand the
problem, I know where to look.
Cheers,
Dave
^ permalink raw reply
* Re: OT: Re: solved: Re: [rtc-linux] Re: DS1337 RTC on I2C broken.
From: Clemens Koller @ 2007-12-03 19:35 UTC (permalink / raw)
To: Scott Wood; +Cc: Alessandro Zummo, rtc-linux, linuxppc-embedded
In-Reply-To: <475445DF.6080202@freescale.com>
Hello, Scott!
Scott Wood schrieb:
>> Here, the next idea which comes to my mind:
>> Maybe we should think about a kernel-config -> dts compiler for
>> the future where the enabled drivers generate their default dts
>> entries automagically?
>
> Sorry, there's just not enough information in .config for that.
If there is really the need to put more information (which I don't
see in the case of the RTCs) to .config, it might be an idea to
extend the current structure for this use instead of duplicating
and maintaining a second repository.
And regarding the DS1337 (or the PCF8563 and similar RTCs):
It's address (0x68) is immutable fixed by the manufacturer
of that device. So, why do we include it in the DT, when we
already told the kernel what driver we want to use?
Even if I have an eeprom which can have varying addresses,
I can simply tell the driver/the kernel .config what address
it should use... If I want to be able to alter that address
for whatever reason by OF, I still don't want to touch a
separate file in the kernel tree.
Regards,
--
Clemens Koller
__________________________________
R&D Imaging Devices
Anagramm GmbH
Rupert-Mayer-Straße 45/1
Linhof Werksgelände
D-81379 München
Tel.089-741518-50
Fax 089-741518-19
http://www.anagramm-technology.com
^ permalink raw reply
* Re: [PATCH] powerpc: fix os-term usage on kernel panic
From: Linas Vepstas @ 2007-12-03 19:32 UTC (permalink / raw)
To: Olaf Hering; +Cc: linuxppc-dev, Will Schmidt, paulus
In-Reply-To: <20071129104147.GA3694@aepfle.de>
On Thu, Nov 29, 2007 at 11:41:47AM +0100, Olaf Hering wrote:
> On Wed, Nov 28, Linas Vepstas wrote:
>
> > On Wed, Nov 28, 2007 at 12:00:37PM +0100, Olaf Hering wrote:
> > > On Tue, Nov 27, Will Schmidt wrote:
>
> > > > > - if (panic_timeout)
> > > > > - return;
> > >
> > > This change is wrong. Booting with panic=123 really means the system
> > > has to reboot in 123 seconds after a panic.
> >
> > And it does.
>
> Have you ever tried it? Current state is that the JS20 hangs after
> panic,
It should printout the "Rebooting in timeout_wait seconds ..."
Then it should wait timeout_wait number of seconds, as usual,
and *then* call the hypervisor.
> simply because it calls into the hypervisor (or whatever).
The hypervisor is not supposed to return at this point. Its supposed
to reboot. Appearently, its not rebooting. Either we are using it
wrong, or the hypervisor is buggy on some systems. It did work on
the machines I was on; but I did not try power5's or blades.
> So, please restore the panic_timeout check.
The problem with this check was that was that the value was never
ever set, and so the branch was never ever taken.
--linas
^ permalink raw reply
* Re: [PATCH 1/5] PowerPC 74xx: Katana Qp device tree
From: Jon Loeliger @ 2007-12-03 19:26 UTC (permalink / raw)
To: David Gibson; +Cc: linuxppc-dev@ozlabs.org
In-Reply-To: <20071203015018.GC26919@localhost.localdomain>
On Sun, 2007-12-02 at 19:50, David Gibson wrote:
> > + clock-frequency = <7f28155>; /* 133.333333 MHz */
> You can use <d# 133333333> to avoid the ugly hex.
Better still, blaze a new trail, convert it to /dts-v1/ and
use clock-frequency = <133333333> straight up!
jdl
^ permalink raw reply
* Re: Maximum ioremap size for ppc arch?
From: Matt Porter @ 2007-12-03 19:07 UTC (permalink / raw)
To: David Hawkins; +Cc: linuxppc-embedded
In-Reply-To: <475441DD.9030601@ovro.caltech.edu>
On Mon, Dec 03, 2007 at 09:50:21AM -0800, David Hawkins wrote:
> Could you comment on a similar problem I had/have.
>
> I have a CPU with 1GB memory, and I use about 20 cPCI boards that
> I give 8MB windows in PCI space. When I was trying to load my
> custom driver with these boards, it would give me ioremap failures.
> On a CPU that had 512MB of memory it worked fine. My 'temporary hack'
> (which is still in place) for the 1GB CPUs was to add mem=512M (or
> whatever it is) to the kernel command line. That was a good
> enough fix at the time :)
>
> I have figured I was running out of page table entries or something
> like that and was going to investigate one of these days ...
>
> However, perhaps it was that I was running out of address space.
> But 0xC0000000 is at 3GB, I can't see that I would be triggering
> an address space issue:
>
> 1GB = 0x40000000
> 20 x 8MB = 160MB
>
> But, I figured I'd ask anyway :)
Yes, same thing. There's N ways to fix it. But I see you're talking
x86.
> PS. The CPUs in this case are x86 based, while the PCI boards use
> PLX-9054 bridges. I'm building new peripheral boards with MPC8349EAs
> so this problem is going to rear its ugly head again soon, when
> I work on the drivers for the new peripheral boards.
You should be able to do something similar on x86 but the details
are TBD. I would probably try to limit low memory to 512MB in the
x86 case.
-Matt
^ permalink raw reply
* Re: [PATCH] [POWERPC] Improved documentation of device tree 'ranges'.
From: Grant Likely @ 2007-12-03 18:09 UTC (permalink / raw)
To: Stephen Neuendorffer; +Cc: linuxppc-dev, Paul Mackerras, david
In-Reply-To: <20071203174403.C740719B0073@mail119-sin.bigfish.com>
On 12/3/07, Stephen Neuendorffer <stephen.neuendorffer@xilinx.com> wrote:
> I was misled by the prior language. I've attempted to clarify how
> 'ranges' are used, in particular, how to get a 1:1 mapping.
>
> Signed-off-by: Stephen Neuendorffer <stephen.neuendorffer@xilinx.com>
Acked-by: Grant Likely <grant.likely@secretlab.ca>
> ---
> Documentation/powerpc/booting-without-of.txt | 11 +++++++----
> 1 files changed, 7 insertions(+), 4 deletions(-)
>
> diff --git a/Documentation/powerpc/booting-without-of.txt b/Documentation/powerpc/booting-without-of.txt
> index e9a3cb1..aad8bf5 100644
> --- a/Documentation/powerpc/booting-without-of.txt
> +++ b/Documentation/powerpc/booting-without-of.txt
> @@ -711,13 +711,14 @@ define a bus type with a more complex address format, including things
> like address space bits, you'll have to add a bus translator to the
> prom_parse.c file of the recent kernels for your bus type.
>
> -The "reg" property only defines addresses and sizes (if #size-cells
> -is non-0) within a given bus. In order to translate addresses upward
> +The "reg" property only defines addresses and sizes (if #size-cells is
> +non-0) within a given bus. In order to translate addresses upward
> (that is into parent bus addresses, and possibly into CPU physical
> addresses), all busses must contain a "ranges" property. If the
> "ranges" property is missing at a given level, it's assumed that
> -translation isn't possible. The format of the "ranges" property for a
> -bus is a list of:
> +translation isn't possible, i.e., the registers are not visible on the
> +parent bus. The format of the "ranges" property for a bus is a list
> +of:
>
> bus address, parent bus address, size
>
> @@ -735,6 +736,8 @@ fit in a single 32-bit word. New 32-bit powerpc boards should use a
> 1/1 format, unless the processor supports physical addresses greater
> than 32-bits, in which case a 2/1 format is recommended.
>
> +Alternatively, the "ranges" property may be empty, indicating that the
> +registers are visible on the parent bus, with 1:1 address translation.
>
> 2) Note about "compatible" properties
> -------------------------------------
> --
> 1.5.3.4
>
>
>
>
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195
^ permalink raw reply
* Re: OT: Re: solved: Re: [rtc-linux] Re: DS1337 RTC on I2C broken.
From: Scott Wood @ 2007-12-03 18:07 UTC (permalink / raw)
To: Clemens Koller; +Cc: Alessandro Zummo, rtc-linux, linuxppc-embedded
In-Reply-To: <47543FAD.7040504@anagramm.de>
Clemens Koller wrote:
> Scott Wood schrieb:
> > The problem is the "probed successfully" bit -- i2c can't be
> > automatically detected like PCI can, and the probing that was being done
> > before was very error-prone.
>
> I think I understood the original purpose of device trees, or it's
> intended advantage but don't see much of this yet.
>
> Before (2.6.22) everything was working fine just by enabling the proper
> kernel config.
Just because it worked fine *for you* doesn't mean it worked fine in
general.
1. This means that you can't use the same kernel with different
hardware, which is precisely what you were complaining that you couldn't do.
2. What if you have two i2c devices at the same address on different
buses? Or if you have two devices, these devices can reside on a
variety of ports, and the driver for one tries to probe the port of the
other? .config doesn't help you now.
3. What if you need to pass in extra information to the driver, such as
the exact chip type when more than one is handled by the same driver, or
the IRQ line if the chip uses one, etc?
> Well, I don't want to start a flamewar on this since we have had
> already enough pro & contra Device Tree discussions. I just want
> to point out that the current situation doesn't really follow
> the KISS principle at all in my eyes.
It should be as simple as it can be and still work, but no simpler.
Before, it was too simple to work.
> Here, the next idea which comes to my mind:
> Maybe we should think about a kernel-config -> dts compiler for
> the future where the enabled drivers generate their default dts
> entries automagically?
Sorry, there's just not enough information in .config for that.
-Scott
^ permalink raw reply
* Re: Maximum ioremap size for ppc arch?
From: David Hawkins @ 2007-12-03 17:50 UTC (permalink / raw)
To: Matt Porter; +Cc: linuxppc-embedded
In-Reply-To: <20071203153009.GA30746@gate.crashing.org>
Hi Matt,
> On Mon, Dec 03, 2007 at 09:22:06AM -0000, michael.firth@bt.com wrote:
>> I'm trying to get am MPC834x system running that has 256MBytes of NOR
>> flash connected.
>>
>> The physmap flash driver is failing to ioremap() that amount of space,
>> while on a similar system with 128Mbytes of flash, there are no
>> problems.
>>
>> Is this a known limitation of ioremap() on the ppc architecture, or
>> specifically the MPC834x family, and is there any (hopefully easy) way
>> to increase this limit?
>
> The answer is "it depends". It depends on the amount of system memory
> you have. By default, your system memory is mapped at 0xc0000000, leaving
> not enough space for vmalloc allocations to grab 256MB for the
> ioremap (and avoid the fixed virtual mapping in the high virtual
> address area).
>
> See the "Advanced setup" menu. Normally, you can set "Set custom kernel
> base address" to 0xa0000000 safely. That will give you an additional
> 256MB of vmalloc space. On arch/powerpc, you'll also have to set
> "Size of user task space" to 0x80000000 or 0xa0000000.
Could you comment on a similar problem I had/have.
I have a CPU with 1GB memory, and I use about 20 cPCI boards that
I give 8MB windows in PCI space. When I was trying to load my
custom driver with these boards, it would give me ioremap failures.
On a CPU that had 512MB of memory it worked fine. My 'temporary hack'
(which is still in place) for the 1GB CPUs was to add mem=512M (or
whatever it is) to the kernel command line. That was a good
enough fix at the time :)
I have figured I was running out of page table entries or something
like that and was going to investigate one of these days ...
However, perhaps it was that I was running out of address space.
But 0xC0000000 is at 3GB, I can't see that I would be triggering
an address space issue:
1GB = 0x40000000
20 x 8MB = 160MB
But, I figured I'd ask anyway :)
Thanks,
Dave
PS. The CPUs in this case are x86 based, while the PCI boards use
PLX-9054 bridges. I'm building new peripheral boards with MPC8349EAs
so this problem is going to rear its ugly head again soon, when
I work on the drivers for the new peripheral boards.
^ permalink raw reply
* [PATCH] [POWERPC] Improved documentation of device tree 'ranges'.
From: Stephen Neuendorffer @ 2007-12-03 17:45 UTC (permalink / raw)
To: grant.likely, david, linuxppc-dev
I was misled by the prior language. I've attempted to clarify how
'ranges' are used, in particular, how to get a 1:1 mapping.
Signed-off-by: Stephen Neuendorffer <stephen.neuendorffer@xilinx.com>
---
Documentation/powerpc/booting-without-of.txt | 11 +++++++----
1 files changed, 7 insertions(+), 4 deletions(-)
diff --git a/Documentation/powerpc/booting-without-of.txt b/Documentation/powerpc/booting-without-of.txt
index e9a3cb1..aad8bf5 100644
--- a/Documentation/powerpc/booting-without-of.txt
+++ b/Documentation/powerpc/booting-without-of.txt
@@ -711,13 +711,14 @@ define a bus type with a more complex address format, including things
like address space bits, you'll have to add a bus translator to the
prom_parse.c file of the recent kernels for your bus type.
-The "reg" property only defines addresses and sizes (if #size-cells
-is non-0) within a given bus. In order to translate addresses upward
+The "reg" property only defines addresses and sizes (if #size-cells is
+non-0) within a given bus. In order to translate addresses upward
(that is into parent bus addresses, and possibly into CPU physical
addresses), all busses must contain a "ranges" property. If the
"ranges" property is missing at a given level, it's assumed that
-translation isn't possible. The format of the "ranges" property for a
-bus is a list of:
+translation isn't possible, i.e., the registers are not visible on the
+parent bus. The format of the "ranges" property for a bus is a list
+of:
bus address, parent bus address, size
@@ -735,6 +736,8 @@ fit in a single 32-bit word. New 32-bit powerpc boards should use a
1/1 format, unless the processor supports physical addresses greater
than 32-bits, in which case a 2/1 format is recommended.
+Alternatively, the "ranges" property may be empty, indicating that the
+registers are visible on the parent bus, with 1:1 address translation.
2) Note about "compatible" properties
-------------------------------------
--
1.5.3.4
^ permalink raw reply related
* OT: Re: solved: Re: [rtc-linux] Re: DS1337 RTC on I2C broken.
From: Clemens Koller @ 2007-12-03 17:41 UTC (permalink / raw)
To: Scott Wood; +Cc: Alessandro Zummo, rtc-linux, linuxppc-embedded
In-Reply-To: <47543351.2080904@freescale.com>
Hello, Scott!
Scott Wood schrieb:
> Clemens Koller wrote:
>> [OT+sarcasm on]
>>
>> So, the time is over, where you just enable a driver in the kernel
>> config and
>> the device gets probed and - if it's probed successfully - it usually
>> works.
>
> The problem is the "probed successfully" bit -- i2c can't be
> automatically detected like PCI can, and the probing that was being done
> before was very error-prone.
I think I understood the original purpose of device trees, or it's
intended advantage but don't see much of this yet.
Before (2.6.22) everything was working fine just by enabling the proper
kernel config. But in it's current implementation I primarily see the
an additional, duplicate, badly documented configuration step for
these - in my case - stupid, usually trivial to handle RTC chips.
> That's the simplest way, but not the only way. You could also have a
> wrapper platform that chooses the proper device tree based on something
> you detect.
Here is the problem:
something it detects = probing (what we planned to avoid)
something I detect = configurating (currently duplicated work).
This wrapper platform doesn't really exist yet in practice.
>> Hmmm... this just s****!
>
> There are some growing pains, but the old method of blindly poking at
> i2c addresses and hoping that the first driver to ask for a port that
> something responds to is actually the right driver for that port is just
> shit.
That's not a good example: Of course, blindly poking is bad...
therefore there is the (kernel.)configuration step to have only
the relevant drivers enabled:
The Philips PCF8563 is on address 0x51 and the DS13x7 on 0x68.
The drivers don't touch foreign addresses at all and they are
fixed. No issues there... proved by 2.6.22.
Well, I don't want to start a flamewar on this since we have had
already enough pro & contra Device Tree discussions. I just want
to point out that the current situation doesn't really follow
the KISS principle at all in my eyes.
Here, the next idea which comes to my mind:
Maybe we should think about a kernel-config -> dts compiler for
the future where the enabled drivers generate their default dts
entries automagically?
Regards,
--
Clemens Koller
__________________________________
R&D Imaging Devices
Anagramm GmbH
Rupert-Mayer-Straße 45/1
Linhof Werksgelände
D-81379 München
Tel.089-741518-50
Fax 089-741518-19
http://www.anagramm-technology.com
^ 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