Re: [PATCH] Use of_get_next_child() in k2_sata_proc_info()
Benjamin Herrenschmidt wrote:
On Wed, 2007-10-24 at 14:25 +1000, Michael Ellerman wrote:
k2_sata_proc_info() uses its own hand-rolled loop to check a nodes
children for a property, this is not safe WRT refcounting, so fix it
to use of_get_next_child().
Signed-off-by: Michael Ellerman [EMAIL PROTECTED]
Acked-by: Benjamin Herrenschmidt [EMAIL PROTECTED]
(Pending you test boot it on one of our G5s first !)
---
drivers/ata/sata_svw.c |5 -
1 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/drivers/ata/sata_svw.c b/drivers/ata/sata_svw.c
index 12d613c..64c3812 100644
--- a/drivers/ata/sata_svw.c
+++ b/drivers/ata/sata_svw.c
@@ -289,7 +289,10 @@ static int k2_sata_proc_info(struct Scsi_Host *shost,
char *page, char **start,
/* Match it to a port node */
index = (ap == ap-host-ports[0]) ? 0 : 1;
-for (np = np-child; np != NULL; np = np-sibling) {
+
+for (np = of_get_next_child(np, NULL);
+ np != NULL;
+ np = of_get_next_child(np, np)) {
const u32 *reg = of_get_property(np, reg, NULL);
This sort of thing I would prefer to ACK (ACK!), and let it go upstream
via the powerpc tree.
Jeff
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] Use of_get_next_child() in k2_sata_proc_info()
On Wed, 2007-10-24 at 02:04 -0400, Jeff Garzik wrote:
Benjamin Herrenschmidt wrote:
On Wed, 2007-10-24 at 14:25 +1000, Michael Ellerman wrote:
k2_sata_proc_info() uses its own hand-rolled loop to check a nodes
children for a property, this is not safe WRT refcounting, so fix it
to use of_get_next_child().
Signed-off-by: Michael Ellerman [EMAIL PROTECTED]
Acked-by: Benjamin Herrenschmidt [EMAIL PROTECTED]
(Pending you test boot it on one of our G5s first !)
---
drivers/ata/sata_svw.c |5 -
1 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/drivers/ata/sata_svw.c b/drivers/ata/sata_svw.c
index 12d613c..64c3812 100644
--- a/drivers/ata/sata_svw.c
+++ b/drivers/ata/sata_svw.c
@@ -289,7 +289,10 @@ static int k2_sata_proc_info(struct Scsi_Host *shost,
char *page, char **start,
/* Match it to a port node */
index = (ap == ap-host-ports[0]) ? 0 : 1;
- for (np = np-child; np != NULL; np = np-sibling) {
+
+ for (np = of_get_next_child(np, NULL);
+ np != NULL;
+ np = of_get_next_child(np, np)) {
const u32 *reg = of_get_property(np, reg, NULL);
This sort of thing I would prefer to ACK (ACK!), and let it go upstream
via the powerpc tree.
Sure thing, just ACK (ACK!) (ACK?) it, and I'll pester paulus to merge
it via his tree.
cheers
--
Michael Ellerman
OzLabs, IBM Australia Development Lab
wwweb: http://michael.ellerman.id.au
phone: +61 2 6212 1183 (tie line 70 21183)
We do not inherit the earth from our ancestors,
we borrow it from our children. - S.M.A.R.T Person
signature.asc
Description: This is a digitally signed message part
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] taskstats scaled time cleanup
This moves the ability to scale cputime into generic code. This
allows us to fix the issue in kernel/timer.c (noticed by Balbir) where
we could only add an unscaled value to the scaled utime/stime.
This adds a cputime_to_scaled function. As before, the POWERPC
version does the scaling based on the last SPURR/PURR ratio
calculated. The generic and s390 (only other arch to implement
asm/cputime.h) versions are both NOPs.
Also moves the SPURR and PURR snapshots closer.
Signed-off-by: Michael Neuling [EMAIL PROTECTED]
---
arch/powerpc/kernel/time.c| 14 +++---
include/asm-generic/cputime.h |1 +
include/asm-powerpc/cputime.h | 14 ++
include/asm-powerpc/paca.h|2 --
include/asm-s390/cputime.h|1 +
kernel/timer.c|9 +
6 files changed, 28 insertions(+), 13 deletions(-)
Index: linux-2.6-ozlabs/arch/powerpc/kernel/time.c
===
--- linux-2.6-ozlabs.orig/arch/powerpc/kernel/time.c
+++ linux-2.6-ozlabs/arch/powerpc/kernel/time.c
@@ -66,6 +66,7 @@
#include asm/smp.h
#include asm/vdso_datapage.h
#include asm/firmware.h
+#include asm/cputime.h
#ifdef CONFIG_PPC_ISERIES
#include asm/iseries/it_lp_queue.h
#include asm/iseries/hv_call_xm.h
@@ -186,6 +187,8 @@ u64 __cputime_sec_factor;
EXPORT_SYMBOL(__cputime_sec_factor);
u64 __cputime_clockt_factor;
EXPORT_SYMBOL(__cputime_clockt_factor);
+DEFINE_PER_CPU(unsigned long, cputime_last_delta);
+DEFINE_PER_CPU(unsigned long, cputime_scaled_last_delta);
static void calc_cputime_factors(void)
{
@@ -232,9 +235,9 @@ void account_system_vtime(struct task_st
local_irq_save(flags);
now = read_purr();
+ nowscaled = read_spurr(now);
delta = now - get_paca()-startpurr;
get_paca()-startpurr = now;
- nowscaled = read_spurr(now);
deltascaled = nowscaled - get_paca()-startspurr;
get_paca()-startspurr = nowscaled;
if (!in_interrupt()) {
@@ -247,9 +250,9 @@ void account_system_vtime(struct task_st
get_paca()-system_time = 0;
}
account_system_time(tsk, 0, delta);
- get_paca()-purrdelta = delta;
+ per_cpu(cputime_last_delta, smp_processor_id()) = delta;
account_system_time_scaled(tsk, deltascaled);
- get_paca()-spurrdelta = deltascaled;
+ per_cpu(cputime_scaled_last_delta, smp_processor_id()) = deltascaled;
local_irq_restore(flags);
}
@@ -267,10 +270,7 @@ void account_process_vtime(struct task_s
get_paca()-user_time = 0;
account_user_time(tsk, utime);
- /* Estimate the scaled utime by scaling the real utime based
-* on the last spurr to purr ratio */
- utimescaled = utime * get_paca()-spurrdelta / get_paca()-purrdelta;
- get_paca()-spurrdelta = get_paca()-purrdelta = 0;
+ utimescaled = cputime_to_scaled(utime);
account_user_time_scaled(tsk, utimescaled);
}
Index: linux-2.6-ozlabs/include/asm-generic/cputime.h
===
--- linux-2.6-ozlabs.orig/include/asm-generic/cputime.h
+++ linux-2.6-ozlabs/include/asm-generic/cputime.h
@@ -18,6 +18,7 @@ typedef unsigned long cputime_t;
#define cputime_lt(__a, __b) ((__a) (__b))
#define cputime_le(__a, __b) ((__a) = (__b))
#define cputime_to_jiffies(__ct) (__ct)
+#define cputime_to_scaled(__ct)(__ct)
#define jiffies_to_cputime(__hz) (__hz)
typedef u64 cputime64_t;
Index: linux-2.6-ozlabs/include/asm-powerpc/cputime.h
===
--- linux-2.6-ozlabs.orig/include/asm-powerpc/cputime.h
+++ linux-2.6-ozlabs/include/asm-powerpc/cputime.h
@@ -52,12 +52,26 @@ typedef u64 cputime64_t;
* Convert cputime - jiffies
*/
extern u64 __cputime_jiffies_factor;
+DECLARE_PER_CPU(unsigned long, cputime_last_delta);
+DECLARE_PER_CPU(unsigned long, cputime_scaled_last_delta);
static inline unsigned long cputime_to_jiffies(const cputime_t ct)
{
return mulhdu(ct, __cputime_jiffies_factor);
}
+/* Estimate the scaled cputime by scaling the real cputime based on
+ * the last scaled to real ratio */
+static inline cputime_t cputime_to_scaled(const cputime_t ct)
+{
+ if (cpu_has_feature(CPU_FTR_SPURR)
+ per_cpu(cputime_last_delta, smp_processor_id()))
+ return ct *
+ per_cpu(cputime_scaled_last_delta, smp_processor_id())/
+ per_cpu(cputime_last_delta, smp_processor_id());
+ return ct;
+}
+
static inline cputime_t jiffies_to_cputime(const unsigned long jif)
{
cputime_t ct;
Index: linux-2.6-ozlabs/include/asm-powerpc/paca.h
===
--- linux-2.6-ozlabs.orig/include/asm-powerpc/paca.h
+++ linux-2.6-ozlabs/include/asm-powerpc/paca.h
@@ -115,8 +115,6 @@ struct paca_struct {
u64
libfdt: Add some documenting comments in libfdt.h
This patch adds some internal documentation in libfdt.h, in the form of comments on the error codes and some functions. Only a couple of functions are covered so far, leaving the documentation still woefully inadequate, but hey, it's a start. Signed-off-by: David Gibson [EMAIL PROTECTED] Index: dtc/libfdt/libfdt.h === --- dtc.orig/libfdt/libfdt.h2007-10-24 15:56:14.0 +1000 +++ dtc/libfdt/libfdt.h 2007-10-24 16:55:09.0 +1000 @@ -59,27 +59,64 @@ /* Error codes: informative error codes */ #define FDT_ERR_NOTFOUND 1 + /* FDT_ERR_NOTFOUND: The requested node or property does not exist */ #define FDT_ERR_EXISTS 2 + /* FDT_ERR_EXISTS: Attemped to create a node or property which +* already exists */ #define FDT_ERR_NOSPACE3 + /* FDT_ERR_NOSPACE: Operation needed to expand the device +* tree, but its buffer did not have sufficient space to +* contain the expanded tree. Use fdt_open_into() to move the +* device tree to a buffer with more space. */ /* Error codes: codes for bad parameters */ #define FDT_ERR_BADOFFSET 4 + /* FDT_ERR_BADOFFSET: Function was passed a structure block +* offset which is out-of-bounds, or which points to an +* unsuitable part of the structure for the operation. */ #define FDT_ERR_BADPATH5 + /* FDT_ERR_BADPATH: Function was passed a badly formatted path +* (e.g. missing a leading / for a function which requires an +* absolute path) */ #define FDT_ERR_BADSTATE 6 + /* FDT_ERR_BADSTATE: Function was passed an incomplete device +* tree created by the sequential-write functions, which is +* not sufficiently complete for the requested operation. */ /* Error codes: codes for bad device tree blobs */ #define FDT_ERR_TRUNCATED 7 + /* FDT_ERR_TRUNCATED: Structure block of the given device tree +* ends without an FDT_END tag. */ #define FDT_ERR_BADMAGIC 8 + /* FDT_ERR_BADMAGIC: Given device tree appears not to be a +* device tree at all - it is missing the flattened device +* tree magic number. */ #define FDT_ERR_BADVERSION 9 + /* FDT_ERR_BADVERSION: Given device tree has a version which +* can't be handled by the requested operation. For +* read-write functions, this may mean that fdt_open_into() is +* required to convert the tree to the expected version. */ #define FDT_ERR_BADSTRUCTURE 10 + /* FDT_ERR_BADSTRUCTURE: Given device tree has a corrupt +* structure block or other serious error (e.g. misnested +* nodes, or subnodes preceding properties). */ #define FDT_ERR_BADLAYOUT 11 + /* FDT_ERR_BADLAYOUT: For read-write functions, the given +* device tree has it's sub-blocks in an order that the +* function can't handle (memory reserve map, then structure, +* then strings). Use fdt_open_into() to reorganize the tree +* into a form suitable for the read-write operations. */ /* Can't happen error indicating a bug in libfdt */ #define FDT_ERR_INTERNAL 12 + /* FDT_ERR_INTERNAL: libfdt has failed an internal assertion. +* Indicates a bug in libfdt itself. */ #define FDT_ERR_MAX12 -/* Low-level functions (you probably don't need these) */ +/**/ +/* Low-level functions (you probably don't need these)*/ +/**/ const void *fdt_offset_ptr(const void *fdt, int offset, int checklen); static inline void *fdt_offset_ptr_w(void *fdt, int offset, int checklen) @@ -94,7 +131,10 @@ static inline void *fdt_offset_ptr_w(voi uint32_t fdt_next_tag(const void *fdt, int offset, int *nextoffset); -/* General functions */ +/**/ +/* General functions */ +/**/ + #define fdt_get_header(fdt, field) \ (fdt32_to_cpu(((const struct fdt_header *)(fdt))-field)) #define fdt_magic(fdt) (fdt_get_header(fdt, magic)) @@ -111,15 +151,91 @@ uint32_t fdt_next_tag(const void *fdt, i #define fdt_set_header(fdt, field, val) \ ((struct fdt_header *)(fdt))-field = cpu_to_fdt32(val) +/** + * fdt_check_header - sanity check a device tree or possible device tree + * @fdt: pointer to data which might be a flattened device tree + * + * fdt_check_header() checks that the given buffer contains what + * appears to be a flattened device tree with sane information in its + * header. + * + * returns: + * 0, if the buffer appears to contain a valid device tree + * -FDT_ERR_BADMAGIC, + *
Re: [PATCH 01/11] [POWERPC] Add 'machine: ...' line to common show_cpuinfo()
On Wed, 24 Oct 2007 01:13:09 +0200 Marian Balakowicz [EMAIL PROTECTED] wrote: + root = of_find_node_by_path(/); + if (root) + model = of_get_property(root, model, NULL); + of_node_put(root); The paranoid part of me says: if (model) + seq_printf(m, machine\t\t: %s\n, model); -- Cheers, Stephen Rothwell[EMAIL PROTECTED] http://www.canb.auug.org.au/~sfr/ pgpVk2wSx5hpX.pgp Description: PGP signature ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 03/11] [POWERPC] Add common mpc52xx_setup_pci() routine
On Wed, 24 Oct 2007 01:13:21 +0200 Marian Balakowicz [EMAIL PROTECTED] wrote:
+++ b/arch/powerpc/platforms/52xx/lite5200.c
@@ -155,11 +155,7 @@ static void __init lite5200_setup_arch(void)
#endif
#ifdef CONFIG_PCI
- np = of_find_node_by_type(NULL, pci);
- if (np) {
- mpc52xx_add_bridge(np);
- of_node_put(np);
- }
+ mpc52xx_setup_pci();
#endif
Normally we would have no #ifdef CONFIG_PCI here but instead define a
static inline void mpc52xx_setup_pci(void) { }
in the header file for the non PCI case.
--
Cheers,
Stephen Rothwell[EMAIL PROTECTED]
http://www.canb.auug.org.au/~sfr/
pgpTKlqzkOGK1.pgp
Description: PGP signature
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] fix powerpc breakage in sg chaining code (again)
Commit 33ff910f0f466184ffc3514628f18403dcd86761 fixed commit
78bdc3106a877cfa50439fa66b52acbc4e7868df but the code that got put in
uses struct scatterlist-page which no longer exists since commit
18dabf473e15850c0dbc8ff13ac1e2806d542c15 which requires using
sg_page(sg) instead of sg-page.
Signed-off-by: Johannes Berg [EMAIL PROTECTED]
---
If it was fixed before please ignore, I just ran into this.
--- linux-2.6.orig/include/asm/dma-mapping.h2007-10-23 22:55:33.551133142
+0200
+++ linux-2.6/include/asm/dma-mapping.h 2007-10-23 22:56:07.081133142 +0200
@@ -285,9 +285,9 @@ dma_map_sg(struct device *dev, struct sc
BUG_ON(direction == DMA_NONE);
for_each_sg(sgl, sg, nents, i) {
- BUG_ON(!sg-page);
- __dma_sync_page(sg-page, sg-offset, sg-length, direction);
- sg-dma_address = page_to_bus(sg-page) + sg-offset;
+ BUG_ON(!sg_page(sg));
+ __dma_sync_page(sg_page(sg), sg-offset, sg-length, direction);
+ sg-dma_address = page_to_bus(sg_page(sg)) + sg-offset;
}
return nents;
@@ -328,7 +328,7 @@ static inline void dma_sync_sg_for_cpu(s
BUG_ON(direction == DMA_NONE);
for_each_sg(sgl, sg, nents, i)
- __dma_sync_page(sg-page, sg-offset, sg-length, direction);
+ __dma_sync_page(sg_page(sg), sg-offset, sg-length, direction);
}
static inline void dma_sync_sg_for_device(struct device *dev,
@@ -341,7 +341,7 @@ static inline void dma_sync_sg_for_devic
BUG_ON(direction == DMA_NONE);
for_each_sg(sgl, sg, nents, i)
- __dma_sync_page(sg-page, sg-offset, sg-length, direction);
+ __dma_sync_page(sg_page(sg), sg-offset, sg-length, direction);
}
static inline int dma_mapping_error(dma_addr_t dma_addr)
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] fix powerpc breakage in sg chaining code (again)
On Tue, 2007-10-23 at 23:00 +0200, Johannes Berg wrote: Commit 33ff910f0f466184ffc3514628f18403dcd86761 fixed commit 78bdc3106a877cfa50439fa66b52acbc4e7868df but the code that got put in uses struct scatterlist-page which no longer exists since commit 18dabf473e15850c0dbc8ff13ac1e2806d542c15 which requires using sg_page(sg) instead of sg-page. This doesn't help though, when I boot I get a NULL-pointer dereference that looks approximately like this: NIP blk_rq_map_sg + 0x64/0x190 LR ide_map_sg + 0x38/? Call trace: cfq_remove_request + 0x168 (unreliable) cfq_dispatch_request + 0x44 ide_build_sglist + 0x38? pmac_ide_dma_setup + 0xa0? ide_do_rw_disk? + ? [...] I can upload the picture I took but it's hardly readable (taken with my crappy cell phone) johannes signature.asc Description: This is a digitally signed message part ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] fix powerpc breakage in sg chaining code (again)
On Tue, Oct 23 2007, Johannes Berg wrote: On Tue, 2007-10-23 at 23:00 +0200, Johannes Berg wrote: Commit 33ff910f0f466184ffc3514628f18403dcd86761 fixed commit 78bdc3106a877cfa50439fa66b52acbc4e7868df but the code that got put in uses struct scatterlist-page which no longer exists since commit 18dabf473e15850c0dbc8ff13ac1e2806d542c15 which requires using sg_page(sg) instead of sg-page. This doesn't help though, when I boot I get a NULL-pointer dereference that looks approximately like this: NIP blk_rq_map_sg + 0x64/0x190 LR ide_map_sg + 0x38/? Call trace: cfq_remove_request + 0x168 (unreliable) cfq_dispatch_request + 0x44 ide_build_sglist + 0x38? pmac_ide_dma_setup + 0xa0? ide_do_rw_disk? + ? [...] I can upload the picture I took but it's hardly readable (taken with my crappy cell phone) I lost track - which kernel are you booting? This looks like something that should be fixed, did you try 2.6.24-rc1? -- Jens Axboe ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] fix powerpc breakage in sg chaining code (again)
On Wed, 2007-10-24 at 11:14 +0200, Jens Axboe wrote: I lost track - which kernel are you booting? This looks like something that should be fixed, did you try 2.6.24-rc1? No, it came out after I pulled, I was on v2.6.23-6815-g0895e91. I'll give it a try, but I don't think I can confirm it works before tomorrow. I see the build failure got fixed with commit 5edadbd0ae35d2daabaf6b44f2c58d67d4021ed2 too. johannes signature.asc Description: This is a digitally signed message part ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] fix powerpc breakage in sg chaining code (again)
On Wed, 2007-10-24 at 11:22 +0200, Johannes Berg wrote: No, it came out after I pulled, I was on v2.6.23-6815-g0895e91. I'll give it a try, but I don't think I can confirm it works before tomorrow. I see the build failure got fixed with commit 5edadbd0ae35d2daabaf6b44f2c58d67d4021ed2 too. Wait, now I lost track. This patch is identical to that commit 5edad..., what I was thinking of was the oops I got. johannes signature.asc Description: This is a digitally signed message part ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] fix powerpc breakage in sg chaining code (again)
On Wed, 2007-10-24 at 11:23 +0200, Johannes Berg wrote: On Wed, 2007-10-24 at 11:22 +0200, Johannes Berg wrote: No, it came out after I pulled, I was on v2.6.23-6815-g0895e91. I'll give it a try, but I don't think I can confirm it works before tomorrow. I see the build failure got fixed with commit 5edadbd0ae35d2daabaf6b44f2c58d67d4021ed2 too. Wait, now I lost track. This patch is identical to that commit 5edad..., what I was thinking of was the oops I got. Nah, never mind. Apologies to everybody. I'm confused, Jens says the oops was fixed. I'll verify that. johannes signature.asc Description: This is a digitally signed message part ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] fix powerpc breakage in sg chaining code (again)
On Wed, Oct 24 2007, Johannes Berg wrote: On Wed, 2007-10-24 at 11:14 +0200, Jens Axboe wrote: I lost track - which kernel are you booting? This looks like something that should be fixed, did you try 2.6.24-rc1? No, it came out after I pulled, I was on v2.6.23-6815-g0895e91. I'll give it a try, but I don't think I can confirm it works before tomorrow. I see the build failure got fixed with commit 5edadbd0ae35d2daabaf6b44f2c58d67d4021ed2 too. 0895e91d60ef9bdef426d1ce14bb94bd5875870d is definitely too old, so it will break on IDE. I'm confident that a newer kernel will solve this issue. -- Jens Axboe ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] ehea: fix port_napi_disable/enable
napi_disable / napi_enable must be applied on all ehea queues.
Signed-off-by: Jan-Bernd Themann [EMAIL PROTECTED]
---
drivers/net/ehea/ehea.h |2 +-
drivers/net/ehea/ehea_main.c |7 +++
2 files changed, 4 insertions(+), 5 deletions(-)
diff --git a/drivers/net/ehea/ehea.h b/drivers/net/ehea/ehea.h
index b557bb4..4b4b74e 100644
--- a/drivers/net/ehea/ehea.h
+++ b/drivers/net/ehea/ehea.h
@@ -40,7 +40,7 @@
#include asm/io.h
#define DRV_NAME ehea
-#define DRV_VERSIONEHEA_0078
+#define DRV_VERSIONEHEA_0079
/* eHEA capability flags */
#define DLPAR_PORT_ADD_REM 1
diff --git a/drivers/net/ehea/ehea_main.c b/drivers/net/ehea/ehea_main.c
index fe5ffac..a8b05d2 100644
--- a/drivers/net/ehea/ehea_main.c
+++ b/drivers/net/ehea/ehea_main.c
@@ -2329,7 +2329,7 @@ static void port_napi_disable(struct ehea_port *port)
{
int i;
- for (i = 0; i port-num_def_qps; i++)
+ for (i = 0; i port-num_def_qps + port-num_add_tx_qps; i++)
napi_disable(port-port_res[i].napi);
}
@@ -2337,7 +2337,7 @@ static void port_napi_enable(struct ehea_port *port)
{
int i;
- for (i = 0; i port-num_def_qps; i++)
+ for (i = 0; i port-num_def_qps + port-num_add_tx_qps; i++)
napi_enable(port-port_res[i].napi);
}
@@ -2373,8 +2373,6 @@ static int ehea_down(struct net_device *dev)
ehea_drop_multicast_list(dev);
ehea_free_interrupts(dev);
- port_napi_disable(port);
-
port-state = EHEA_PORT_DOWN;
ret = ehea_clean_all_portres(port);
@@ -2396,6 +2394,7 @@ static int ehea_stop(struct net_device *dev)
flush_scheduled_work();
down(port-port_lock);
netif_stop_queue(dev);
+ port_napi_disable(port);
ret = ehea_down(dev);
up(port-port_lock);
return ret;
--
1.5.2
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] taskstats scaled time cleanup
Michael Neuling wrote: This moves the ability to scale cputime into generic code. This allows us to fix the issue in kernel/timer.c (noticed by Balbir) where we could only add an unscaled value to the scaled utime/stime. This adds a cputime_to_scaled function. As before, the POWERPC version does the scaling based on the last SPURR/PURR ratio calculated. The generic and s390 (only other arch to implement asm/cputime.h) versions are both NOPs. Also moves the SPURR and PURR snapshots closer. Signed-off-by: Michael Neuling [EMAIL PROTECTED] Looks good to me Acked-by: Balbir Singh [EMAIL PROTECTED] -- Warm Regards, Balbir Singh Linux Technology Center IBM, ISTL ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] fix appletouch geyser 1 breakage
The patch 46249ea60fbb61a72ee6929b831b1f3e6865f024 was obviously done
without testing on a Geyser 1, and I'm a very annoyed that it was
applied. It causes appletouch to continuously printk:
drivers/input/mouse/appletouch.c: Could not do mode read request from device
(Geyser 3 mode)
because the Geyser 1 doesn't respond to that. The patch description also
states:
if we see 10 empty packets the touchpad needs to be reset; good
touchpads should not send empty packets anyway.
which is *TOTALLY* bogus since Geyser 1 touchpads have no notion of
empty packets, the simply continuously send measurements. One look at
the specification would have confirmed that.
This reverts the clueless commit.
Signed-off-by: Johannes Berg [EMAIL PROTECTED]
---
--- linux-2.6.orig/drivers/input/mouse/appletouch.c 2007-10-24
12:37:39.140210069 +0200
+++ linux-2.6/drivers/input/mouse/appletouch.c 2007-10-24 12:37:50.000215820
+0200
@@ -504,22 +504,25 @@ static void atp_complete(struct urb* urb
memset(dev-xy_acc, 0, sizeof(dev-xy_acc));
}
- input_report_key(dev-input, BTN_LEFT, key);
- input_sync(dev-input);
-
- /* Many Geysers will continue to send packets continually after
+ /* Geyser 3 will continue to send packets continually after
the first touch unless reinitialised. Do so if it's been
idle for a while in order to avoid waking the kernel up
several hundred times a second */
- if (!x !y !key) {
- dev-idlecount++;
- if (dev-idlecount == 10) {
- dev-valid = 0;
- schedule_work(dev-work);
+ if (atp_is_geyser_3(dev)) {
+ if (!x !y !key) {
+ dev-idlecount++;
+ if (dev-idlecount == 10) {
+ dev-valid = 0;
+ schedule_work(dev-work);
+ }
}
- } else
- dev-idlecount = 0;
+ else
+ dev-idlecount = 0;
+ }
+
+ input_report_key(dev-input, BTN_LEFT, key);
+ input_sync(dev-input);
exit:
retval = usb_submit_urb(dev-urb, GFP_ATOMIC);
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] PowerPC 440EPx Sequoia USB OHCI DTS entry
Dale Farnsworth wrote: Valentine wrote: Actually I also don't see much reason for the USB_OHCI_HCD_PPC_OF_BE/USB_OHCI_HCD_PPC_OF_LE stuff. Is this really needed? I think so. The SOC host controllers are BE and the PCI host controllers are LE. Or, do you have an alternative method of handling both types? -Dale Yes, PCI controllers are LE, but do we really need user-selectable USB_OHCI_HCD_PPC_OF_LE option, since USB_OHCI_LITTLE_ENDIAN is selected by default for USB_OHCI_HCD_PCI? The USB_OHCI_HCD_PPC_OF_LE/BE stuff is related to PPC OF glue only. I think it's useless. We should always enable USB_OHCI_BIG_ENDIAN_DESC and USB_OHCI_BIG_ENDIAN_MMIO for PPC OF and the real LE/BE implementation should be selected by the corresponding properties in the device tree. Thanks, Valentine. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH v2 3/4] Implement clockevents driver for powerpc
Hello, I wrote: The only thing I'm still unusre about is that deterministic accounting. Could you point me at the patch which deals with this (at least for System 390 See efe567fc8281661524ffa75477a7c4ca9b466c63 in Linus' tree, and look Wait, how this is related to the hrtimer's event handlers not being able to call account_process_time() from arch/powerpc/kernel/time.c instead of update_process_timess()? I've just realized that I've missed the call to account_process_time() in the new timer_interrupt(). :- Anyway, this leads to each tick being accounted twice if the deterministic accounting is not enabled -- first by timer_interrupt() and then by the hrtimers core, doesn't it? WBR, Sergei ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] PowerPC 440EPx Sequoia USB OHCI DTS entry
On Wed, Oct 24, 2007 at 03:19:14PM +0400, Valentine Barshak wrote: Dale Farnsworth wrote: Valentine wrote: Actually I also don't see much reason for the USB_OHCI_HCD_PPC_OF_BE/USB_OHCI_HCD_PPC_OF_LE stuff. Is this really needed? I think so. The SOC host controllers are BE and the PCI host controllers are LE. Or, do you have an alternative method of handling both types? Yes, PCI controllers are LE, but do we really need user-selectable USB_OHCI_HCD_PPC_OF_LE option, since USB_OHCI_LITTLE_ENDIAN is selected by default for USB_OHCI_HCD_PCI? The USB_OHCI_HCD_PPC_OF_LE/BE stuff is related to PPC OF glue only. I think it's useless. We should always enable USB_OHCI_BIG_ENDIAN_DESC and USB_OHCI_BIG_ENDIAN_MMIO for PPC OF and the real LE/BE implementation should be selected by the corresponding properties in the device tree. I agree that they don't need to be user selectable. It is far preferable to deduce their values from existing information, if possible. -Dale ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] fix appletouch geyser 1 breakage
Hi Johannes, On 10/24/07, Johannes Berg [EMAIL PROTECTED] wrote: The patch 46249ea60fbb61a72ee6929b831b1f3e6865f024 was obviously done without testing on a Geyser 1, My fault, sorry. However Anton's device has product ID of 90x30B which is Geyser 1 as far as I understand... But yes, we should not expect other geysers respond to Geyser 3-specific commands. and I'm a very annoyed that it was applied. It causes appletouch to continuously printk: drivers/input/mouse/appletouch.c: Could not do mode read request from device (Geyser 3 mode) because the Geyser 1 doesn't respond to that. The patch description also states: if we see 10 empty packets the touchpad needs to be reset; good touchpads should not send empty packets anyway. which is *TOTALLY* bogus since Geyser 1 touchpads have no notion of empty packets, the simply continuously send measurements. One look at the specification would have confirmed that. Is there a way to plug these Geysers? Waking up the kernel continuously is not nice. -- Dmitry ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: libfdt: Rename and publish _fdt_check_header()
So, like, the other day David Gibson mumbled: It's potentially useful for users of libfdt to sanity check a device tree (or, rather, a blob of data which may or may not be a device tree) before processing it in more detail with libfdt. This patch renames the libfdt internal function _fdt_check_header() to fdt_check_header() and makes it a published function, so it can now be used for this purpose. Signed-off-by: David Gibson [EMAIL PROTECTED] Applied. Thanks, jdl ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] fix powerpc breakage in sg chaining code (again)
On Wed, 2007-10-24 at 11:23 +0200, Jens Axboe wrote: On Wed, Oct 24 2007, Johannes Berg wrote: On Wed, 2007-10-24 at 11:14 +0200, Jens Axboe wrote: I lost track - which kernel are you booting? This looks like something that should be fixed, did you try 2.6.24-rc1? No, it came out after I pulled, I was on v2.6.23-6815-g0895e91. I'll give it a try, but I don't think I can confirm it works before tomorrow. I see the build failure got fixed with commit 5edadbd0ae35d2daabaf6b44f2c58d67d4021ed2 too. 0895e91d60ef9bdef426d1ce14bb94bd5875870d is definitely too old, so it will break on IDE. I'm confident that a newer kernel will solve this issue. It does indeed, 2.6.24-rc1 runs fine. Thanks. johannes signature.asc Description: This is a digitally signed message part ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] fix appletouch geyser 1 breakage
On Wed, 2007-10-24 at 12:44 +0200, Johannes Berg wrote: The patch 46249ea60fbb61a72ee6929b831b1f3e6865f024 was obviously done without testing on a Geyser 1, and I'm a very annoyed that it was applied. It causes appletouch to continuously printk: I spoke too soon, I don't have a Geyser 1 but rather a Fountain touchpad on my powerbook. johannes signature.asc Description: This is a digitally signed message part ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH v2] appletouch: fix fountain touchpad breakage
The patch 46249ea60fbb61a72ee6929b831b1f3e6865f024 was obviously done
without testing on a fountain touchpad. It causes appletouch to
continuously printk:
drivers/input/mouse/appletouch.c: Could not do mode read request from device
(Geyser 3 mode)
because the fountain touchpad doesn't respond to that. The patch description
also states:
if we see 10 empty packets the touchpad needs to be reset; good
touchpads should not send empty packets anyway.
which is *TOTALLY* bogus since fountain touchpads have no notion of
empty packets, the simply continuously send measurements. One look at
the specification would have confirmed that.
This reverts the clueless commit, a better solution for geyser 1
touchpads must be found.
Signed-off-by: Johannes Berg [EMAIL PROTECTED]
---
What I'd advocate for 2.6.25 is to split appletouch into two drivers:
appletouch for fountain touchpads and maybe appletouch2 for geyser
touchpads, this will get rid of many of the huge if statements in the
packet processing path and make sure that the macbook crowd will no
longer have to workaround the powerbook touchpads seeing that we seem to
hardly talk to each other.
Or maybe Soeren Sonnenburg's rewrite could be used for Geyser touchpads.
drivers/input/mouse/appletouch.c | 25 ++---
1 file changed, 14 insertions(+), 11 deletions(-)
--- linux-2.6.orig/drivers/input/mouse/appletouch.c 2007-10-24
12:37:39.140210069 +0200
+++ linux-2.6/drivers/input/mouse/appletouch.c 2007-10-24 12:37:50.000215820
+0200
@@ -504,22 +504,25 @@ static void atp_complete(struct urb* urb
memset(dev-xy_acc, 0, sizeof(dev-xy_acc));
}
- input_report_key(dev-input, BTN_LEFT, key);
- input_sync(dev-input);
-
- /* Many Geysers will continue to send packets continually after
+ /* Geyser 3 will continue to send packets continually after
the first touch unless reinitialised. Do so if it's been
idle for a while in order to avoid waking the kernel up
several hundred times a second */
- if (!x !y !key) {
- dev-idlecount++;
- if (dev-idlecount == 10) {
- dev-valid = 0;
- schedule_work(dev-work);
+ if (atp_is_geyser_3(dev)) {
+ if (!x !y !key) {
+ dev-idlecount++;
+ if (dev-idlecount == 10) {
+ dev-valid = 0;
+ schedule_work(dev-work);
+ }
}
- } else
- dev-idlecount = 0;
+ else
+ dev-idlecount = 0;
+ }
+
+ input_report_key(dev-input, BTN_LEFT, key);
+ input_sync(dev-input);
exit:
retval = usb_submit_urb(dev-urb, GFP_ATOMIC);
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
ioctl32 unknown cmds with 2.6.24-rc1
I've been getting these warnings (many more of them but this is a list
of unique ones) on my quad G5 with 32-bit userspace:
ioctl32(cdrom_id:1078): Unknown cmd fd(3) cmd(5331){t:'S';sz:0}
arg() on /dev/.tmp-3-0
ioctl32(ata_id:1095): Unknown cmd fd(3) cmd(030d){t:03;sz:0} arg(ff863970)
on /dev/.tmp-3-0
ioctl32(smartd:3563): Unknown cmd fd(3) cmd(031f){t:03;sz:0} arg(ffeb5480)
on /dev/sda
ioctl32(hald-probe-stor:3761): Unknown cmd fd(4) cmd(5320){t:'S';sz:0}
arg(0004) on /dev/hda
ioctl32(gnome-terminal:4187): Unknown cmd fd(19) cmd(530b){t:'S';sz:0}
arg(0fd8e400) on /dev/pts/0
Does anybody know whether this is expected?
johannes
signature.asc
Description: This is a digitally signed message part
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] fix appletouch geyser 1 breakage
Hi, My fault, sorry. No, actually, I was wrong about Geyser 1, mine is a fountain. Is there a way to plug these Geysers? Waking up the kernel continuously is not nice. Not sure really, maybe checking for is_geyser instead of is_geyser_3? johannes signature.asc Description: This is a digitally signed message part ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] fix appletouch geyser 1 breakage
On 10/24/07, Johannes Berg [EMAIL PROTECTED] wrote: Hi, My fault, sorry. No, actually, I was wrong about Geyser 1, mine is a fountain. Is there a way to plug these Geysers? Waking up the kernel continuously is not nice. Not sure really, maybe checking for is_geyser instead of is_geyser_3? Well, but what about fountains then? Regardless of the model, if there is a way to stop empty meaurements, we should do it. -- Dmitry ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] fix appletouch geyser 1 breakage
On Wed, 2007-10-24 at 09:34 -0400, Dmitry Torokhov wrote: Well, but what about fountains then? Regardless of the model, if there is a way to stop empty meaurements, we should do it. There is no way on fountains though. We could check the measurement ourselves and if no finger is detected decrease the polling frequency or something, but there's no hw support. johannes signature.asc Description: This is a digitally signed message part ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] PowerPC 440EPx Sequoia USB OHCI DTS entry
Dale Farnsworth wrote: On Wed, Oct 24, 2007 at 03:19:14PM +0400, Valentine Barshak wrote: Dale Farnsworth wrote: Valentine wrote: Actually I also don't see much reason for the USB_OHCI_HCD_PPC_OF_BE/USB_OHCI_HCD_PPC_OF_LE stuff. Is this really needed? I think so. The SOC host controllers are BE and the PCI host controllers are LE. Or, do you have an alternative method of handling both types? Yes, PCI controllers are LE, but do we really need user-selectable USB_OHCI_HCD_PPC_OF_LE option, since USB_OHCI_LITTLE_ENDIAN is selected by default for USB_OHCI_HCD_PCI? The USB_OHCI_HCD_PPC_OF_LE/BE stuff is related to PPC OF glue only. I think it's useless. We should always enable USB_OHCI_BIG_ENDIAN_DESC and USB_OHCI_BIG_ENDIAN_MMIO for PPC OF and the real LE/BE implementation should be selected by the corresponding properties in the device tree. I agree that they don't need to be user selectable. It is far preferable to deduce their values from existing information, if possible. -Dale This is the original thread: http://ozlabs.org/pipermail/linuxppc-embedded/2006-November/025054.html I think the USB_OHCI_HCD_PPC_OF_LE/BE should be removed. We can't avoid the slight overhead even using these options, since USB_OHCI_BIG_ENDIAN_MMIO/DESC should always be anabled for PPC OF and we we still enable USB_OHCI_LITTLE_ENDIAN for USB_OHCI_HCD_PCI even if USB_OHCI_HCD_PPC_OF_LE is not set. Thanks, Valentine. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 04/11] [POWERPC] Add generic support for MPC5200 based boards
On 10/23/07, Marian Balakowicz [EMAIL PROTECTED] wrote:
This patch adds support for 'generic-mpc5200' compatible
boards which do not need a platform specific setup.
Signed-off-by: Marian Balakowicz [EMAIL PROTECTED]
I like this patch and I think it will make it easier to support
multiple 5200 based boards. However, we must be very clear here what
'generic-mpc5200' is (in fact, my suggestion of the name
generic-mpc5200 might be a bad one. mpc5200-simple-platform might
be a better name).
Please add documentation to both the Kconfig and the generic_mpc5200.c
files describing exactly the assumptions which are made for this
platform. For example:
- port_config and clocking are setup correctly by firmware,
- if the fsl,has-wdt property is present in one of the gpt nodes, then
it is safe to use it to reset the board
etc.
Cheers,
g.
---
arch/powerpc/platforms/52xx/Kconfig |8 ++-
arch/powerpc/platforms/52xx/Makefile |1
arch/powerpc/platforms/52xx/generic_mpc5200.c | 63
+
3 files changed, 70 insertions(+), 2 deletions(-)
create mode 100644 arch/powerpc/platforms/52xx/generic_mpc5200.c
diff --git a/arch/powerpc/platforms/52xx/Kconfig
b/arch/powerpc/platforms/52xx/Kconfig
index 2938d49..59c67b5 100644
--- a/arch/powerpc/platforms/52xx/Kconfig
+++ b/arch/powerpc/platforms/52xx/Kconfig
@@ -19,6 +19,12 @@ config PPC_MPC5200_BUGFIX
It is safe to say 'Y' here
+config PPC_GENERIC_MPC5200
+ bool Generic support for MPC5200 based boards
+ depends on PPC_MULTIPLATFORM PPC32
+ select PPC_MPC5200
+ default n
+
config PPC_EFIKA
bool bPlan Efika 5k2. MPC5200B based computer
depends on PPC_MULTIPLATFORM PPC32
@@ -34,5 +40,3 @@ config PPC_LITE5200
select WANT_DEVICE_TREE
select PPC_MPC5200
default n
-
-
diff --git a/arch/powerpc/platforms/52xx/Makefile
b/arch/powerpc/platforms/52xx/Makefile
index 307dbc1..bea05df 100644
--- a/arch/powerpc/platforms/52xx/Makefile
+++ b/arch/powerpc/platforms/52xx/Makefile
@@ -6,6 +6,7 @@ obj-y += mpc52xx_pic.o
mpc52xx_common.o
obj-$(CONFIG_PCI) += mpc52xx_pci.o
endif
+obj-$(CONFIG_PPC_GENERIC_MPC5200) += generic_mpc5200.o
obj-$(CONFIG_PPC_EFIKA)+= efika.o
obj-$(CONFIG_PPC_LITE5200) += lite5200.o
diff --git a/arch/powerpc/platforms/52xx/generic_mpc5200.c
b/arch/powerpc/platforms/52xx/generic_mpc5200.c
new file mode 100644
index 000..a4ec899
--- /dev/null
+++ b/arch/powerpc/platforms/52xx/generic_mpc5200.c
@@ -0,0 +1,63 @@
+/*
+ * Support for 'generic-mpc5200' compatible platforms.
+ *
+ * Written by Marian Balakowicz [EMAIL PROTECTED]
+ * Copyright (C) 2007 Semihalf
+ *
+ * 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.
+ */
+
+#undef DEBUG
+#include linux/init.h
+#include linux/pci.h
+#include linux/of.h
+#include asm/time.h
+#include asm/io.h
+#include asm/machdep.h
+#include asm/prom.h
+#include asm/mpc52xx.h
+
+/*
+ * Setup the architecture
+ */
+static void __init generic_mpc5200_setup_arch(void)
+{
+ if (ppc_md.progress)
+ ppc_md.progress(generic_mpc5200_setup_arch(), 0);
+
+ /* Some mpc5200 mpc5200b related configuration */
+ mpc5200_setup_xlb_arbiter();
+
+ /* Map wdt for mpc52xx_restart() */
+ mpc52xx_map_wdt();
+
+#ifdef CONFIG_PCI
+ mpc52xx_setup_pci();
+#endif
+}
+
+/*
+ * Called very early, MMU is off, device-tree isn't unflattened
+ */
+static int __init generic_mpc5200_probe(void)
+{
+ unsigned long node = of_get_flat_dt_root();
+
+ if (!of_flat_dt_is_compatible(node, generic-mpc5200))
+ return 0;
+ return 1;
+}
+
+define_machine(generic_mpc5200) {
+ .name = generic-mpc5200,
+ .probe = generic_mpc5200_probe,
+ .setup_arch = generic_mpc5200_setup_arch,
+ .init = mpc52xx_declare_of_platform_devices,
+ .init_IRQ = mpc52xx_init_irq,
+ .get_irq= mpc52xx_get_irq,
+ .restart= mpc52xx_restart,
+ .calibrate_decr = generic_calibrate_decr,
+};
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
[EMAIL PROTECTED]
(403) 399-0195
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 05/11] [POWERPC] TQM5200 DTS
On 10/23/07, David Gibson [EMAIL PROTECTED] wrote:
On Wed, Oct 24, 2007 at 01:13:33AM +0200, Marian Balakowicz wrote:
Add device tree source file for TQM5200 board.
Signed-off-by: Marian Balakowicz [EMAIL PROTECTED]
---
arch/powerpc/boot/dts/tqm5200.dts | 236
+
1 files changed, 236 insertions(+), 0 deletions(-)
create mode 100644 arch/powerpc/boot/dts/tqm5200.dts
diff --git a/arch/powerpc/boot/dts/tqm5200.dts
b/arch/powerpc/boot/dts/tqm5200.dts
new file mode 100644
index 000..01c7778
--- /dev/null
+++ b/arch/powerpc/boot/dts/tqm5200.dts
@@ -0,0 +1,236 @@
+/*
+ * TQM5200 board Device Tree Source
[snip]
+ [EMAIL PROTECTED] {
I thought we were moving towards calling these just /[EMAIL PROTECTED]
The only reason this is still like this is that u-boot does a path
based lookup for the soc5200 node on the TQM board. We need to change
u-boot too before the 5200 can be dropped.
+ model = fsl,mpc5200;
+ compatible = mpc5200;
That should have a vendor prefix.
[snip]
+ [EMAIL PROTECTED] { // PSC1
+ device_type = serial;
+ compatible = mpc5200-psc-uart;
+ port-number = 0; // Logical port assignment
How are these port-number things used? The device tree shouldn't
generally contain information that isn't inherent to the hardware.
There can be reasons for hacks like this, but we should avoid them if
possible.
This was an approach I was taking a while back to assign logical ports
(ttyPSC0) to a PSC. I'm working on eliminating this. As you
suggested, I'm looking into using aliases for this.
+ cell-index = 0;
cell-index should only be used if the index number is used when
manipulating the hardware (e.g. if there's a global control register
which takes this number).
And there is in this case.
[snip]
+ [EMAIL PROTECTED] {
+ device_type = ata;
No such thing as device_type = ata, drop it. In general, never
include a device_type unless a binding explicitly says to do so.
Again, my fault from the lite5200.
[snip]
+ [EMAIL PROTECTED] {
+ model = fsl,lpb;
+ compatible = lpb;
Not nearly specific enough. Must include a vendor prefix at least,
and should have a lot more revision information. You should always be
able to pick the right driver with compatible alone, model should
generally be for human consumption, the driver shouldn't need it.
+ device_type = lpb;
Drop this. Again, presence of a device_type property is the
exception, not the rule.
+ ranges = 0 fc00 0200;
You need #address-cells and #size-cells properties, too.
[snip]
--
David Gibson| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
[EMAIL PROTECTED]
(403) 399-0195
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Audio codec device tree entries
Jon Smirl wrote:
Is this consensus on how the tree should look?
There is no attempt to describe the codec connections inside the
device tree.
I don't think I agree with that. The device tree should indicate which codec
is
connected to which I2S/AC97 device.
I see that you do that for the AC97 node, but not the I2S node. Why?
I'm still not clear on how to trigger the load of the fabric driver.
Right now I have a single kernel that works on Efika and my target
hardware. This gets sorted out by define_machine(). I'll write
some code tonight to figure out how to load drivers and match on
codec0, codec1, etc. But how do I probe for the fabric driver I need
to figure out whether to load the Efika one or my target one.
I've been struggling with that one, too. To keep it simple, I have the fabric
driver just search for all the I2S nodes in my tree, and create ASoC objects
for
each one it finds. There's some hackery there, but I don't think we need to
solve all the problems at once. The only thing that *has* to be right the
first
time is the device tree.
[EMAIL PROTECTED] { // PSC2
compatible = fsl,mpc5200b-psc-i2s,fsl,mpc5200-psc-i2s;
cell-index = 1;
reg = 2200 100;
interrupts = 2 2 0;
interrupt-parent = mpc5200_pic;
};
[EMAIL PROTECTED] {
compatible = fsl,mpc5200b-i2c, fsl,mpc5200-i2c, fsl-i2c;
#address-cells = 1;
#size-cells = 0;
cell-index = 0;
reg = 3d00 40;
interrupts = 2 f 0;
interrupt-parent = mpc5200_pic;
fsl5200-clocking;
codec0: [EMAIL PROTECTED] {
compatible = ti,tas5508;
reg = 0;
i2s-handle = [EMAIL PROTECTED];
};
I'd do this the other way around -- that is:
[EMAIL PROTECTED] { // PSC2
compatible = fsl,mpc5200b-psc-i2s,fsl,mpc5200-psc-i2s;
...
i2c-handle = codec0; /* Or something like that */
};
The reason is because I think the I2S driver will be instantiated *first* as an
I2S driver and then it will create the I2C instantiation.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 09/11] [POWERPC] Motion-PRO: Add LED support.
On 10/23/07, Marian Balakowicz [EMAIL PROTECTED] wrote:
Add LED driver for Promess Motion-PRO board.
Signed-off-by: Jan Wrobel [EMAIL PROTECTED]
Signed-off-by: Marian Balakowicz [EMAIL PROTECTED]
---
drivers/leds/Kconfig |7 +
drivers/leds/Makefile |3 -
drivers/leds/leds-motionpro.c | 222
+
include/asm-powerpc/mpc52xx.h |5 +
4 files changed, 236 insertions(+), 1 deletions(-)
create mode 100644 drivers/leds/leds-motionpro.c
diff --git a/drivers/leds/Kconfig b/drivers/leds/Kconfig
index ec568fa..1567ed6 100644
--- a/drivers/leds/Kconfig
+++ b/drivers/leds/Kconfig
@@ -55,6 +55,13 @@ config LEDS_TOSA
This option enables support for the LEDs on Sharp Zaurus
SL-6000 series.
+config LEDS_MOTIONPRO
+ tristate Motion-PRO LEDs Support
+ depends on LEDS_CLASS PPC_MPC5200
+ help
+ This option enables support for status and ready LEDs connected
+ to GPIO lines on Motion-PRO board.
+
config LEDS_S3C24XX
tristate LED Support for Samsung S3C24XX GPIO LEDs
depends on LEDS_CLASS ARCH_S3C2410
diff --git a/drivers/leds/Makefile b/drivers/leds/Makefile
index a60de1b..a56d399 100644
--- a/drivers/leds/Makefile
+++ b/drivers/leds/Makefile
@@ -18,7 +18,8 @@ obj-$(CONFIG_LEDS_H1940) += leds-h1940.o
obj-$(CONFIG_LEDS_COBALT_QUBE) += leds-cobalt-qube.o
obj-$(CONFIG_LEDS_COBALT_RAQ) += leds-cobalt-raq.o
obj-$(CONFIG_LEDS_GPIO)+= leds-gpio.o
-obj-$(CONFIG_LEDS_CM_X270) += leds-cm-x270.o
+obj-$(CONFIG_LEDS_CM_X270) += leds-cm-x270.o
+obj-$(CONFIG_LEDS_MOTIONPRO) += leds-motionpro.o
# LED Triggers
obj-$(CONFIG_LEDS_TRIGGER_TIMER) += ledtrig-timer.o
diff --git a/drivers/leds/leds-motionpro.c b/drivers/leds/leds-motionpro.c
new file mode 100644
index 000..d4b872c
--- /dev/null
+++ b/drivers/leds/leds-motionpro.c
@@ -0,0 +1,222 @@
+/*
+ * LEDs driver for the Motionpro board.
+ *
+ * Copyright (C) 2007 Semihalf
+ *
+ * Author: Jan Wrobel [EMAIL PROTECTED]
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License version 2 as published
by
+ * the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful, but
WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for
+ * more details.
+ *
+ * You should have received a copy of the GNU General Public License along
+ * with this program; if not, write to the Free Software Foundation, Inc., 51
+ * Franklin St, Fifth Floor, Boston, MA 02110-1301 USA
+ *
+ *
+ * This driver enables control over Motionpro's status and ready LEDs through
+ * sysfs. LEDs can be controlled by writing to sysfs files:
+ * class/leds/motionpro-(ready|status)led/(brightness|delay_off|delay_on).
+ * See Documentation/leds-class.txt for more details
+ *
+ * Before user issues first control command via sysfs, LED blinking is
+ * controlled by the kernel. By default status LED is blinking fast and ready
+ * LED is turned off.
+ */
+
+#include linux/module.h
+#include linux/types.h
+#include linux/kernel.h
+#include linux/device.h
+#include linux/leds.h
+
+#include asm/mpc52xx.h
+#include asm/io.h
+
+/* Led status */
+#define LED_NOT_REGISTERED 0
+#define LED_KERNEL_CONTROLLED 1
+#define LED_USER_CONTROLLED2
+
+/* Led control bits */
+#define LED_ON MPC52xx_GPT_OUTPUT_1
+
+static void mpled_set(struct led_classdev *led_cdev,
+ enum led_brightness brightness);
+
+struct motionpro_led{
+ /* Protects the led data */
+ spinlock_t led_lock;
+
+ /* Path to led's control register DTS node */
+ char *reg_compat;
+
+ /* Address to access led's register */
+ void __iomem *reg_addr;
+
+ int status;
+
+ /* Blinking timer used when led is controlled by the kernel */
+ struct timer_list kernel_mode_timer;
+
+ /*
+* Delay between blinks when led is controlled by the kernel.
+* If set to 0 led blinking is off.
+*/
+ int kernel_mode_delay;
+
+ struct led_classdev classdev;
+};
+
+static struct motionpro_led led[] = {
+ {
+ .reg_compat = promess,motionpro-statusled,
+ .reg_addr = 0,
+ .led_lock = SPIN_LOCK_UNLOCKED,
+ .status = LED_NOT_REGISTERED,
+ .kernel_mode_delay = HZ / 10,
+ .classdev = {
+ .name = motionpro-statusled,
+ .brightness_set = mpled_set,
+ .default_trigger = timer,
+ },
+ },
+ {
+ .reg_compat =
Re: [PATCH] PowerPC 440EPx Sequoia USB OHCI DTS entry
On Wed, Oct 24, 2007 at 05:44:51PM +0400, Valentine Barshak wrote: Dale Farnsworth wrote: On Wed, Oct 24, 2007 at 03:19:14PM +0400, Valentine Barshak wrote: Dale Farnsworth wrote: Valentine wrote: Actually I also don't see much reason for the USB_OHCI_HCD_PPC_OF_BE/USB_OHCI_HCD_PPC_OF_LE stuff. Is this really needed? I think so. The SOC host controllers are BE and the PCI host controllers are LE. Or, do you have an alternative method of handling both types? Yes, PCI controllers are LE, but do we really need user-selectable USB_OHCI_HCD_PPC_OF_LE option, since USB_OHCI_LITTLE_ENDIAN is selected by default for USB_OHCI_HCD_PCI? The USB_OHCI_HCD_PPC_OF_LE/BE stuff is related to PPC OF glue only. I think it's useless. We should always enable USB_OHCI_BIG_ENDIAN_DESC and USB_OHCI_BIG_ENDIAN_MMIO for PPC OF and the real LE/BE implementation should be selected by the corresponding properties in the device tree. I agree that they don't need to be user selectable. It is far preferable to deduce their values from existing information, if possible. -Dale This is the original thread: http://ozlabs.org/pipermail/linuxppc-embedded/2006-November/025054.html I think the USB_OHCI_HCD_PPC_OF_LE/BE should be removed. We can't avoid the slight overhead even using these options, since USB_OHCI_BIG_ENDIAN_MMIO/DESC should always be anabled for PPC OF and we we still enable USB_OHCI_LITTLE_ENDIAN for USB_OHCI_HCD_PCI even if USB_OHCI_HCD_PPC_OF_LE is not set. I believe you are saying that we can select any valid combination of USB_OHCI_BIG_ENDIAN_DESC, USB_OHCI_BIG_ENDIAN_MMIO, and USB_OHCI_LITTLE_ENDIAN, without using USB_OHCI_HCD_PPC_OF_BE and USB_OHCI_HCD_PPC_OF_LE. I agree. It looks like we can get rid of these last two with zero loss in performance or functionality. Do you have a patch? -Dale ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] PowerPC 440EPx Sequoia USB OHCI DTS entry
Dale Farnsworth wrote: On Wed, Oct 24, 2007 at 05:44:51PM +0400, Valentine Barshak wrote: Dale Farnsworth wrote: On Wed, Oct 24, 2007 at 03:19:14PM +0400, Valentine Barshak wrote: Dale Farnsworth wrote: Valentine wrote: Actually I also don't see much reason for the USB_OHCI_HCD_PPC_OF_BE/USB_OHCI_HCD_PPC_OF_LE stuff. Is this really needed? I think so. The SOC host controllers are BE and the PCI host controllers are LE. Or, do you have an alternative method of handling both types? Yes, PCI controllers are LE, but do we really need user-selectable USB_OHCI_HCD_PPC_OF_LE option, since USB_OHCI_LITTLE_ENDIAN is selected by default for USB_OHCI_HCD_PCI? The USB_OHCI_HCD_PPC_OF_LE/BE stuff is related to PPC OF glue only. I think it's useless. We should always enable USB_OHCI_BIG_ENDIAN_DESC and USB_OHCI_BIG_ENDIAN_MMIO for PPC OF and the real LE/BE implementation should be selected by the corresponding properties in the device tree. I agree that they don't need to be user selectable. It is far preferable to deduce their values from existing information, if possible. -Dale This is the original thread: http://ozlabs.org/pipermail/linuxppc-embedded/2006-November/025054.html I think the USB_OHCI_HCD_PPC_OF_LE/BE should be removed. We can't avoid the slight overhead even using these options, since USB_OHCI_BIG_ENDIAN_MMIO/DESC should always be anabled for PPC OF and we we still enable USB_OHCI_LITTLE_ENDIAN for USB_OHCI_HCD_PCI even if USB_OHCI_HCD_PPC_OF_LE is not set. I believe you are saying that we can select any valid combination of USB_OHCI_BIG_ENDIAN_DESC, USB_OHCI_BIG_ENDIAN_MMIO, and USB_OHCI_LITTLE_ENDIAN, without using USB_OHCI_HCD_PPC_OF_BE and USB_OHCI_HCD_PPC_OF_LE. I agree. It looks like we can get rid of these last two with zero loss in performance or functionality. Do you have a patch? No I don't have it yet :) I planed to make, test and submit it a bit later. Thanks, Valentine. -Dale ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: ioctl32 unknown cmds with 2.6.24-rc1
On Wednesday 24 October 2007, Johannes Berg wrote:
Show Details
I've been getting these warnings (many more of them but this is a list
of unique ones) on my quad G5 with 32-bit userspace:
ioctl32(cdrom_id:1078): Unknown cmd fd(3) cmd(5331){t:'S';sz:0}
arg() on /dev/.tmp-3-0
ioctl32(ata_id:1095): Unknown cmd fd(3) cmd(030d){t:03;sz:0}
arg(ff863970) on /dev/.tmp-3-0
ioctl32(smartd:3563): Unknown cmd fd(3) cmd(031f){t:03;sz:0}
arg(ffeb5480) on /dev/sda
ioctl32(hald-probe-stor:3761): Unknown cmd fd(4) cmd(5320){t:'S';sz:0}
arg(0004) on /dev/hda
ioctl32(gnome-terminal:4187): Unknown cmd fd(19) cmd(530b){t:'S';sz:0}
arg(0fd8e400) on /dev/pts/0
Does anybody know whether this is expected?
It's probably my fault, since I changed the compat ioctl handling for
block devices. Geert already reported the same, but I haven't had
a chance to reproduce it on my system to look into what went wrong.
Probably a trivial bug I introduced in block/compat_ioctl.c
Arnd
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] fix appletouch geyser 1 breakage
On 10/24/07, Johannes Berg [EMAIL PROTECTED] wrote: On Wed, 2007-10-24 at 09:34 -0400, Dmitry Torokhov wrote: Well, but what about fountains then? Regardless of the model, if there is a way to stop empty meaurements, we should do it. There is no way on fountains though. We could check the measurement ourselves and if no finger is detected decrease the polling frequency or something, but there's no hw support. Do yo know who has powerbooks with older geyser models (0x214, 215, 216)? It would be nice to know if they send the data continiously and whether the geyser 3 reset hack works on them. -- Dmitry ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: libfdt: Rename and publish _fdt_next_tag()
So, like, the other day David Gibson mumbled: Although it's a low-level function that shouldn't normally be needed, there are circumstances where it's useful for users of libfdt to use the _fdt_next_tag() function. Therefore, this patch renames it to fdt_next_tag() and publishes it in libfdt.h. In addition, this patch adds a new testcase using fdt_next_tag(), dtbs_equal_ordered. This testcase tests for structural equality of two dtbs, including the order of properties and subnodes, but ignoring NOP tags, the order of the dtb sections and the layout of strings in the strings block. This will be useful for testing other dtc functionality in the future. Signed-off-by: David Gibson [EMAIL PROTECTED] Applied. Thanks, jdl ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: libfdt: Add some documenting comments in libfdt.h
So, like, the other day David Gibson mumbled: This patch adds some internal documentation in libfdt.h, in the form of comments on the error codes and some functions. Only a couple of functions are covered so far, leaving the documentation still woefully inadequate, but hey, it's a start. Signed-off-by: David Gibson [EMAIL PROTECTED] Applied. I did miss the fdt_next_tag patch earlier. These are not the droids you are looking for. Move along. jdl ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Audio codec device tree entries
Jon Smirl wrote:
What I meant was that there is no attempt to describe how the codec is
connected to the external world. Those connections are described in
the fabric driver.
Hmmm, I'm not sure I'm okay with that. We can always add properties to those
nodes if it's necessary. However, now you're basically defining some parts of
the board layout in the DTS, and some parts in the fabric driver. On PowerPC
platforms, the fabric driver is supposed to get board layout information from
the device tree.
I'm getting conflicting opinions on how the devices should be linked
into the tree. We should pick one and add it to the documentation.
It's a battle of wills!
The DTC experts need to tell us which way to make the pointers between
i2s and i2c for the codec. Here's a another way it could be done that
looks more like the ac97 model.
[EMAIL PROTECTED] { // PSC1
compatible = fsl,mpc5200b-psc-i2s,fsl,mpc5200-psc-i2s;
cell-index = 0;
reg = 2000 100;
interrupts = 2 1 0;
interrupt-parent = mpc5200_pic;
codec0: [EMAIL PROTECTED] {
compatible = ti,tas5508;
reg = 0;
i2c-handle = [EMAIL PROTECTED];
};
codec1: [EMAIL PROTECTED] {
compatible = ti,tas5508;
reg = 1;
i2c-handle = [EMAIL PROTECTED];
};
};
[EMAIL PROTECTED] { // PSC2
compatible = fsl,mpc5200b-psc-i2s,fsl,mpc5200-psc-i2s;
cell-index = 1;
reg = 2200 100;
interrupts = 2 2 0;
interrupt-parent = mpc5200_pic;
codec2: [EMAIL PROTECTED] {
This should probably be codec0, since it's the first code on this I2S bus.
compatible = wolson,wm8750;
reg = 2;
i2c-handle = [EMAIL PROTECTED];
};
};
[EMAIL PROTECTED] {
compatible = fsl,mpc5200b-i2c, fsl,mpc5200-i2c, fsl-i2c;
#address-cells = 1;
#size-cells = 0;
cell-index = 0;
reg = 3d00 40;
interrupts = 2 f 0;
interrupt-parent = mpc5200_pic;
fsl5200-clocking;
}
My vote is for this version. In fact, I think it *has* to be this way. If
you're using a CS4270 codec (as I am), the I2C interface is *optional*. So I
want the I2S node to point to the I2C node if it exists.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Audio codec device tree entries
On 10/24/07, Timur Tabi [EMAIL PROTECTED] wrote:
codec0: [EMAIL PROTECTED] {
compatible = ti,tas5508;
reg = 0;
i2s-handle = [EMAIL PROTECTED];
};
I'd do this the other way around -- that is:
[EMAIL PROTECTED] { // PSC2
compatible = fsl,mpc5200b-psc-i2s,fsl,mpc5200-psc-i2s;
...
i2c-handle = codec0; /* Or something like that */
i2c-handle is a poor property name here. It should be 'codec-handle'.
The codec could theoretically live on just about *any* control bus;
not just i2c.
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
[EMAIL PROTECTED]
(403) 399-0195
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Audio codec device tree entries
On 10/24/07, Jon Smirl [EMAIL PROTECTED] wrote: On 10/24/07, Timur Tabi [EMAIL PROTECTED] wrote: Jon Smirl wrote: Is this consensus on how the tree should look? There is no attempt to describe the codec connections inside the device tree. I don't think I agree with that. The device tree should indicate which codec is connected to which I2S/AC97 device. What I meant was that there is no attempt to describe how the codec is connected to the external world. Those connections are described in the fabric driver. I'm getting conflicting opinions on how the devices should be linked into the tree. We should pick one and add it to the documentation. Two valid methods have been proposed 1. a codec- The DTC experts need to tell us which way to make the pointers between i2s and i2c for the codec. Here's a another way it could be done that looks more like the ac97 model. I *really* don't think this is a good idea. Put the node on the bus that the device is addressed from. I2S is the *data* path, not the *control* path, but you cannot control the codec from there. Your suggestion only looks more like the AC97 model if you're looking at the data path. If you're looking at the control path it looks completely different. The device tree convention is to orient around the control path. g. -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. [EMAIL PROTECTED] (403) 399-0195 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Audio codec device tree entries
On 10/24/07, Grant Likely [EMAIL PROTECTED] wrote:
On 10/24/07, Timur Tabi [EMAIL PROTECTED] wrote:
codec0: [EMAIL PROTECTED] {
compatible = ti,tas5508;
reg = 0;
i2s-handle = [EMAIL PROTECTED];
};
I'd do this the other way around -- that is:
[EMAIL PROTECTED] { // PSC2
compatible = fsl,mpc5200b-psc-i2s,fsl,mpc5200-psc-i2s;
...
i2c-handle = codec0; /* Or something like that */
i2c-handle is a poor property name here. It should be 'codec-handle'.
The codec could theoretically live on just about *any* control bus;
not just i2c.
That's one of the reasons I put the second option in the post.
In the second option the i2s driver would instantiate first. Next the
generic code would get loaded. The generic codec will know the control
but for the device and it can go look in the i2c node for the address.
i2c node still lists all of the devices on the i2c bus. But the codecs
are in the i2c-handle property so they don't trigger a second loading
of the codec.
A fundamental question is, which bus should trigger the loading of the
generic codec driver. The answer to this determines how the device
tree should look.
I'm using the model that a child node means load the driver and a
reference does not load a driver.
--
Jon Smirl
[EMAIL PROTECTED]
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Audio codec device tree entries
On 10/24/07, Timur Tabi [EMAIL PROTECTED] wrote:
Jon Smirl wrote:
Is this consensus on how the tree should look?
There is no attempt to describe the codec connections inside the
device tree.
I don't think I agree with that. The device tree should indicate which codec
is
connected to which I2S/AC97 device.
What I meant was that there is no attempt to describe how the codec is
connected to the external world. Those connections are described in
the fabric driver.
I'm getting conflicting opinions on how the devices should be linked
into the tree. We should pick one and add it to the documentation.
The DTC experts need to tell us which way to make the pointers between
i2s and i2c for the codec. Here's a another way it could be done that
looks more like the ac97 model.
[EMAIL PROTECTED] { // PSC1
compatible = fsl,mpc5200b-psc-i2s,fsl,mpc5200-psc-i2s;
cell-index = 0;
reg = 2000 100;
interrupts = 2 1 0;
interrupt-parent = mpc5200_pic;
codec0: [EMAIL PROTECTED] {
compatible = ti,tas5508;
reg = 0;
i2c-handle = [EMAIL PROTECTED];
};
codec1: [EMAIL PROTECTED] {
compatible = ti,tas5508;
reg = 1;
i2c-handle = [EMAIL PROTECTED];
};
};
[EMAIL PROTECTED] { // PSC2
compatible = fsl,mpc5200b-psc-i2s,fsl,mpc5200-psc-i2s;
cell-index = 1;
reg = 2200 100;
interrupts = 2 2 0;
interrupt-parent = mpc5200_pic;
codec2: [EMAIL PROTECTED] {
compatible = wolson,wm8750;
reg = 2;
i2c-handle = [EMAIL PROTECTED];
};
};
[EMAIL PROTECTED] {
compatible = fsl,mpc5200b-i2c, fsl,mpc5200-i2c, fsl-i2c;
#address-cells = 1;
#size-cells = 0;
cell-index = 0;
reg = 3d00 40;
interrupts = 2 f 0;
interrupt-parent = mpc5200_pic;
fsl5200-clocking;
}
- or would this be better? -
[EMAIL PROTECTED] { // PSC1
compatible = fsl,mpc5200b-psc-i2s,fsl,mpc5200-psc-i2s;
cell-index = 0;
reg = 2000 100;
interrupts = 2 1 0;
interrupt-parent = mpc5200_pic;
[EMAIL PROTECTED] {
compatible = ti,tas5508;
reg = 0;
};
[EMAIL PROTECTED] {
compatible = ti,tas5508;
reg = 1;
};
};
[EMAIL PROTECTED] { // PSC2
compatible = fsl,mpc5200b-psc-i2s,fsl,mpc5200-psc-i2s;
cell-index = 1;
reg = 2200 100;
interrupts = 2 2 0;
interrupt-parent = mpc5200_pic;
[EMAIL PROTECTED] {
compatible = wolson,wm8750;
reg = 2;
};
};
[EMAIL PROTECTED] {
compatible = fsl,mpc5200b-i2c, fsl,mpc5200-i2c, fsl-i2c;
#address-cells = 1;
#size-cells = 0;
cell-index = 0;
reg = 3d00 40;
interrupts = 2 f 0;
interrupt-parent = mpc5200_pic;
fsl5200-clocking;
i2c-handle = [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED]
}
I see that you do that for the AC97 node, but not the I2S node. Why?
I'm still not clear on how to trigger the load of the fabric driver.
Right now I have a single kernel that works on Efika and my target
hardware. This gets sorted out by define_machine(). I'll write
some code tonight to figure out how to load drivers and match on
codec0, codec1, etc. But how do I probe for the fabric driver I need
to figure out whether to load the Efika one or my target one.
I've been struggling with that one, too. To keep it simple, I have the fabric
driver just search for all the I2S nodes in my tree, and create ASoC objects
for
each one it finds. There's some hackery there, but I don't think we need to
solve all the problems at once. The only thing that *has* to be right the
first
time is the device tree.
[EMAIL PROTECTED] { // PSC2
compatible = fsl,mpc5200b-psc-i2s,fsl,mpc5200-psc-i2s;
cell-index = 1;
reg = 2200 100;
interrupts = 2 2 0;
interrupt-parent = mpc5200_pic;
};
[EMAIL PROTECTED] {
compatible = fsl,mpc5200b-i2c, fsl,mpc5200-i2c, fsl-i2c;
#address-cells = 1;
#size-cells = 0;
cell-index = 0;
reg = 3d00 40;
interrupts = 2 f 0;
interrupt-parent = mpc5200_pic;
fsl5200-clocking;
codec0: [EMAIL PROTECTED] {
compatible = ti,tas5508;
reg = 0;
i2s-handle = [EMAIL PROTECTED];
};
I'd do this the other way around -- that is:
[EMAIL PROTECTED] { // PSC2
compatible = fsl,mpc5200b-psc-i2s,fsl,mpc5200-psc-i2s;
...
i2c-handle = codec0; /* Or something like that */
};
The reason is because I think the I2S driver will be instantiated *first* as
an
I2S driver and then it will create the I2C instantiation.
--
Jon Smirl
[EMAIL PROTECTED]
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
Re: Audio codec device tree entries
On 10/24/07, Grant Likely [EMAIL PROTECTED] wrote: Two valid methods have been proposed 1. a codec- oops 1. a codec-handle property in the i2s node 2. an i2s-handle property in the codec node Either are reasonable. I prefer putting the handle in the i2s node; but I'm looking at it from the way that ethernet phys are being described currently. The other is also perfectly valid. I suppose it depends on what point of view you see the system from; either: a. the codec is supported by the i2s bus, in which case use the i2s-handle property b. the i2s bus is supported by the codec; in which case use the codec-handle property. Do you want to pick one and add it to the device tree documentation with an example for i2s and ac97? I'll use which ever one is picked. -- Jon Smirl [EMAIL PROTECTED] ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Audio codec device tree entries
On 10/24/07, Timur Tabi [EMAIL PROTECTED] wrote:
Jon Smirl wrote:
What I meant was that there is no attempt to describe how the codec is
connected to the external world. Those connections are described in
the fabric driver.
Hmmm, I'm not sure I'm okay with that. We can always add properties to those
nodes if it's necessary. However, now you're basically defining some parts of
the board layout in the DTS, and some parts in the fabric driver. On PowerPC
platforms, the fabric driver is supposed to get board layout information from
the device tree.
No, not always; if the description is too complex (like gpio's for
instance) then it is perfectly valid to build the knowledge into the
platform code. It should be avoided; but the device tree doesn't need
to describe *everything*.
[EMAIL PROTECTED] { // PSC2
compatible = fsl,mpc5200b-psc-i2s,fsl,mpc5200-psc-i2s;
cell-index = 1;
reg = 2200 100;
interrupts = 2 2 0;
interrupt-parent = mpc5200_pic;
codec2: [EMAIL PROTECTED] {
This should probably be codec0, since it's the first code on this I2S bus.
compatible = wolson,wm8750;
reg = 2;
i2c-handle = [EMAIL PROTECTED];
};
};
[EMAIL PROTECTED] {
compatible = fsl,mpc5200b-i2c, fsl,mpc5200-i2c, fsl-i2c;
#address-cells = 1;
#size-cells = 0;
cell-index = 0;
reg = 3d00 40;
interrupts = 2 f 0;
interrupt-parent = mpc5200_pic;
fsl5200-clocking;
}
My vote is for this version. In fact, I think it *has* to be this way. If
you're using a CS4270 codec (as I am), the I2C interface is *optional*. So I
want the I2S node to point to the I2C node if it exists.
It doesn't have to be this way. If the codec does not have a control
interface, then it can happily be a child of the i2s node. But if it
*does*; don't break convention by separating it from it's control
interface.
I strongly recommend following the lead of ethernet phys and mdio busses here.
Cheers,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
[EMAIL PROTECTED]
(403) 399-0195
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Audio codec device tree entries
Jon Smirl wrote: I see your point about putting the child node onto the control bus. ac97 is both a control and data bus. For the i2s case the child should go onto the i2c bus. I know AC97 is *also* a control bus, but treating I2S and AC97 differently is bad, IMHO. If you're going to put the child node in the AC97 node, you should also put it in the I2S node. The 8610 has an SSI that can operate as either AC97 or I2S. If I want to switch from AC97 to I2S, I should not have to move the child node out of the AC97 node. I should instead just add an I2C node and point to it. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Audio codec device tree entries
On 10/24/07, Jon Smirl [EMAIL PROTECTED] wrote:
On 10/24/07, Grant Likely [EMAIL PROTECTED] wrote:
Two valid methods have been proposed
1. a codec-
oops
1. a codec-handle property in the i2s node
2. an i2s-handle property in the codec node
Either are reasonable. I prefer putting the handle in the i2s node;
but I'm looking at it from the way that ethernet phys are being
described currently. The other is also perfectly valid.
I suppose it depends on what point of view you see the system from; either:
a. the codec is supported by the i2s bus, in which case use the
i2s-handle property
b. the i2s bus is supported by the codec; in which case use the
codec-handle property.
Do you want to pick one and add it to the device tree documentation
with an example for i2s and ac97? I'll use which ever one is picked.
Sure, I'll draft something up and post it for review.
On the device probing front; what about this method:
Rather than trying to figure things out from the board model, or the
combination of the codec and i2s bus; add another node to represent
the sound circuit. All that node would need is a unique compatible
property and a phandle to either the i2s bus or the codec (depending
on which binding approach is used). It could have additional
properties to represent optional features, etc.
For example:
[EMAIL PROTECTED] {
compatible = mfg,board,sound // The board might have
more than one sound i/f which could be wired differently
codec-handle = codec0;
};
This would give your fabric driver something unique to probe on; but
the i2c, i2s and codec nodes which actually describe interconnects
will still be present.
Cheers,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
[EMAIL PROTECTED]
(403) 399-0195
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Audio codec device tree entries
On 10/24/07, Grant Likely [EMAIL PROTECTED] wrote: The DTC experts need to tell us which way to make the pointers between i2s and i2c for the codec. Here's a another way it could be done that looks more like the ac97 model. I *really* don't think this is a good idea. Put the node on the bus that the device is addressed from. I2S is the *data* path, not the *control* path, but you cannot control the codec from there. Your suggestion only looks more like the AC97 model if you're looking at the data path. If you're looking at the control path it looks completely different. The device tree convention is to orient around the control path. It doesn't make any difference to me which one we pick. I'm just listing all of the possible combinations. I just want to pick a model so that we can write the code. I see your point about putting the child node onto the control bus. ac97 is both a control and data bus. For the i2s case the child should go onto the i2c bus. -- Jon Smirl [EMAIL PROTECTED] ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [patch v3] Cell: Wrap master run control bit
On Sun, 23 Sep 2007, Geoff Levand wrote:
Subject: Cell: Wrap master run control bit
From: Masato Noguchi [EMAIL PROTECTED]
Add platform specific SPU run control routines to the spufs. The current
spufs implementation uses the SPU master run control bit (MFC_SR1[S]) to
control SPE execution, but the PS3 hypervisor does not support the use of
this feature.
This change adds the run control wrapper routies spu_enable_spu() and
spu_disable_spu(). The bare metal routines use the master run control
bit, and the PS3 specific routines use the priv2 run control register.
An outstanding enhancement for the PS3 would be to add a guard to check
for incorrect access to the spu problem state when the spu context is
disabled. This check could be implemented with a flag added to the spu
context that would inhibit mapping problem state pages, and a routine
to unmap spu problem state pages. When the spu is enabled with
ps3_enable_spu() the flag would be set allowing pages to be mapped,
and when the spu is disabled with ps3_disable_spu() the flag would be
cleared and mapped problem state pages would be unmapped.
Signed-off-by: Masato Noguchi [EMAIL PROTECTED]
Signed-off-by: Geoff Levand [EMAIL PROTECTED]
---
Jeremy,
Here is an updated version for 2.6.24. Noguchi-san will
As 2.6.24-rc1 is out and Geoff is offline: what's the status of this patch?
work on the LS unmapping feature for 2.6.25.
-Geoff
v2:
o Added comments about unmapping PS pages when disabled.
v3:
o Changed routines to return void instead of int.
o Rebased to apply to Jeremy's 2.6.23-rc work-around.
arch/powerpc/platforms/cell/spu_manage.c| 13 +++
arch/powerpc/platforms/cell/spufs/backing_ops.c |6 +
arch/powerpc/platforms/cell/spufs/hw_ops.c | 10
arch/powerpc/platforms/cell/spufs/run.c |4 +--
arch/powerpc/platforms/cell/spufs/spufs.h |1
arch/powerpc/platforms/ps3/spu.c| 27
++--
include/asm-powerpc/spu_priv1.h | 15 +
7 files changed, 72 insertions(+), 4 deletions(-)
--- a/arch/powerpc/platforms/cell/spu_manage.c
+++ b/arch/powerpc/platforms/cell/spu_manage.c
@@ -35,6 +35,7 @@
#include asm/firmware.h
#include asm/prom.h
+#include spufs/spufs.h
#include interrupt.h
struct device_node *spu_devnode(struct spu *spu)
@@ -369,6 +370,16 @@ static int of_destroy_spu(struct spu *sp
return 0;
}
+static void enable_spu_by_master_run(struct spu_context *ctx)
+{
+ ctx-ops-master_start(ctx);
+}
+
+static void disable_spu_by_master_run(struct spu_context *ctx)
+{
+ ctx-ops-master_stop(ctx);
+}
+
/* Hardcoded affinity idxs for qs20 */
#define QS20_SPES_PER_BE 8
static int qs20_reg_idxs[QS20_SPES_PER_BE] = { 0, 2, 4, 6, 7, 5, 3, 1 };
@@ -535,5 +546,7 @@ const struct spu_management_ops spu_mana
.enumerate_spus = of_enumerate_spus,
.create_spu = of_create_spu,
.destroy_spu = of_destroy_spu,
+ .enable_spu = enable_spu_by_master_run,
+ .disable_spu = disable_spu_by_master_run,
.init_affinity = init_affinity,
};
--- a/arch/powerpc/platforms/cell/spufs/backing_ops.c
+++ b/arch/powerpc/platforms/cell/spufs/backing_ops.c
@@ -285,6 +285,11 @@ static void spu_backing_runcntl_write(st
spin_unlock(ctx-csa.register_lock);
}
+static void spu_backing_runcntl_stop(struct spu_context *ctx)
+{
+ spu_backing_runcntl_write(ctx, SPU_RUNCNTL_STOP);
+}
+
static void spu_backing_master_start(struct spu_context *ctx)
{
struct spu_state *csa = ctx-csa;
@@ -381,6 +386,7 @@ struct spu_context_ops spu_backing_ops =
.get_ls = spu_backing_get_ls,
.runcntl_read = spu_backing_runcntl_read,
.runcntl_write = spu_backing_runcntl_write,
+ .runcntl_stop = spu_backing_runcntl_stop,
.master_start = spu_backing_master_start,
.master_stop = spu_backing_master_stop,
.set_mfc_query = spu_backing_set_mfc_query,
--- a/arch/powerpc/platforms/cell/spufs/hw_ops.c
+++ b/arch/powerpc/platforms/cell/spufs/hw_ops.c
@@ -220,6 +220,15 @@ static void spu_hw_runcntl_write(struct
spin_unlock_irq(ctx-spu-register_lock);
}
+static void spu_hw_runcntl_stop(struct spu_context *ctx)
+{
+ spin_lock_irq(ctx-spu-register_lock);
+ out_be32(ctx-spu-problem-spu_runcntl_RW, SPU_RUNCNTL_STOP);
+ while (in_be32(ctx-spu-problem-spu_status_R) SPU_STATUS_RUNNING)
+ cpu_relax();
+ spin_unlock_irq(ctx-spu-register_lock);
+}
+
static void spu_hw_master_start(struct spu_context *ctx)
{
struct spu *spu = ctx-spu;
@@ -321,6 +330,7 @@ struct spu_context_ops spu_hw_ops = {
.get_ls = spu_hw_get_ls,
.runcntl_read = spu_hw_runcntl_read,
.runcntl_write = spu_hw_runcntl_write,
+ .runcntl_stop = spu_hw_runcntl_stop,
.master_start = spu_hw_master_start,
.master_stop =
Re: Audio codec device tree entries
On 10/24/07, Timur Tabi [EMAIL PROTECTED] wrote: Jon Smirl wrote: I see your point about putting the child node onto the control bus. ac97 is both a control and data bus. For the i2s case the child should go onto the i2c bus. I know AC97 is *also* a control bus, but treating I2S and AC97 differently is bad, IMHO. If you're going to put the child node in the AC97 node, you should also put it in the I2S node. They *are* different. The choice you're making is whether or not you keep them similar in the control path or the data path; but you still have to choose. The 8610 has an SSI that can operate as either AC97 or I2S. If I want to switch from AC97 to I2S, I should not have to move the child node out of the AC97 node. I should instead just add an I2C node and point to it. But you need a different codec node regardless. The board/system will in the vast majority of cases designed to only use AC97 or only use I2S. It's not moving a node. It's deleting an ac97 codec node and adding an i2s codec node. Besides; correctness is more important that how many device tree changes need to be made to go from one board design to another. Cheers, g. -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. [EMAIL PROTECTED] (403) 399-0195 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Audio codec device tree entries
On 10/24/07, Grant Likely [EMAIL PROTECTED] wrote:
Do you want to pick one and add it to the device tree documentation
with an example for i2s and ac97? I'll use which ever one is picked.
Sure, I'll draft something up and post it for review.
On the device probing front; what about this method:
Rather than trying to figure things out from the board model, or the
combination of the codec and i2s bus; add another node to represent
the sound circuit. All that node would need is a unique compatible
property and a phandle to either the i2s bus or the codec (depending
on which binding approach is used). It could have additional
properties to represent optional features, etc.
That's the pseudo-sound node proposal that other people objected to.
It makes sense to me, there needs to be some way to trigger loading
the fabric driver.
For example:
[EMAIL PROTECTED] {
compatible = mfg,board,sound // The board might have
more than one sound i/f which could be wired differently
codec-handle = codec0;
};
Do you even need the parameters, how about simply this?
sound-fabric {
};
That will trigger loading all of the sound-fabric drivers built into
the kernel. In their probe functions they can look in the device tree
and extract the machine name and then decide to stay loaded or fail
the probe.
This would give your fabric driver something unique to probe on; but
the i2c, i2s and codec nodes which actually describe interconnects
will still be present.
Cheers,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
[EMAIL PROTECTED]
(403) 399-0195
--
Jon Smirl
[EMAIL PROTECTED]
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Audio codec device tree entries
Jon Smirl wrote: It makes sense to me, there needs to be some way to trigger loading the fabric driver. Well, you only really two have choices: 1) Probe on the AC97/SSI nodes 2) When the driver initializes, just scan all the nodes in the device tree (no probing). I think option #2 makes the most sense, because option #1 says that your fabric driver is really an AC97 driver, which it isn't. You can try to make the fabric driver into a bus driver, but I think that just complicates things. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: linux-2.6.git: cannot build PS3 image
On Wed, 17 Oct 2007, Scott Wood wrote:
Geert Uytterhoeven wrote:
diff --git a/arch/powerpc/boot/wrapper b/arch/powerpc/boot/wrapper
index 39b27e5..795f988 100755
--- a/arch/powerpc/boot/wrapper
+++ b/arch/powerpc/boot/wrapper
@@ -232,7 +232,7 @@ base=0x`${CROSS}nm $ofile | grep ' _start$' | cut
-d' ' -f1`
entry=`${CROSS}objdump -f $ofile | grep '^start address ' | cut -d' '
-f3`
if [ -n $binary ]; then
-mv $ofile $ofile.elf
+cp $ofile $ofile.elf
${CROSS}objcopy -O binary $ofile.elf $ofile.bin
fi
No comments?
That'd work in this case, though it'd probably be better to make the
$ofile be the end result that will boot on the ps3, and leave a suffix
on the intermediate files.
The $ofile is the end result to boot using kboot (2nd stage kernel).
otheros.bld is the end result to write to FLASH ROM (1st stage kernel).
The funny thing is that we pass `-o arch/powerpc/boot/zImage.ps3' to the
wrapper script (which indicates the _output_ file, i.e. $ofile, as per the
documentation at the top of the wrapper script), while this output file is
no longer created by the wrapper script!
Instead it creates arch/powerpc/boot/zImage.ps3.elf.
So I do think your change broke the expected and obvious behavior.
With kind regards,
Geert Uytterhoeven
Software Architect
Sony Network and Software Technology Center Europe
The Corporate Village · Da Vincilaan 7-D1 · B-1935 Zaventem · Belgium
Phone:+32 (0)2 700 8453
Fax: +32 (0)2 700 8622
E-mail: [EMAIL PROTECTED]
Internet: http://www.sony-europe.com/
Sony Network and Software Technology Center Europe
A division of Sony Service Centre (Europe) N.V.
Registered office: Technologielaan 7 · B-1840 Londerzeel · Belgium
VAT BE 0413.825.160 · RPR Brussels
Fortis Bank Zaventem · Swift GEBABEBB08A · IBAN BE39001382358619___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 0/2] USB: Rework OHCI PPC OF driver to support new bindings
These patches update ohci-ppc-of and the dts files for the new bindings. The compatible is set to usb-ohci and the big-endian quirkiness is expressed by a property, not by the compatible name. Also user-selectable USB_OHCI_HCD_PPC_OF_BE/USB_OHCI_HCD_PPC_OF_LE config options are removed, since the USB_OHCI_BIG_ENDIAN/USB_OHCI_LITTLE_ENDIAN selection is made by default for PPC/PCI OHCI controllers. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 1/2] USB: Rework OHCI PPC OF for new bindings
Rework ohci-ppc-of driver to use big-endian property instead of
ohci-be/ohci-le compatible strings. Also remove unnecessary
user-selectable USB_OHCI_HCD_PPC_OF_LE/BE stuff, because
USB_OHCI_BIG_ENDIAN_DESC/MMIO should always be enabled for ppc
and USB_OHCI_LITTLE_ENDIAN is selected for USB_OHCI_HCD_PCI by default.
Signed-off-by: Valentine Barshak [EMAIL PROTECTED]
---
drivers/usb/host/Kconfig | 17 +++--
drivers/usb/host/ohci-ppc-of.c | 38 ++
2 files changed, 9 insertions(+), 46 deletions(-)
diff -pruN linux-2.6.orig/drivers/usb/host/Kconfig
linux-2.6/drivers/usb/host/Kconfig
--- linux-2.6.orig/drivers/usb/host/Kconfig 2007-10-24 18:44:25.0
+0400
+++ linux-2.6/drivers/usb/host/Kconfig 2007-10-24 19:37:18.0 +0400
@@ -128,23 +128,12 @@ config USB_OHCI_HCD_PPC_OF
bool OHCI support for PPC USB controller on OF platform bus
depends on USB_OHCI_HCD PPC_OF
default y
+ select USB_OHCI_BIG_ENDIAN_DESC
+ select USB_OHCI_BIG_ENDIAN_MMIO
---help---
Enables support for the USB controller PowerPC present on the
OpenFirmware platform bus.
-config USB_OHCI_HCD_PPC_OF_BE
- bool Support big endian HC
- depends on USB_OHCI_HCD_PPC_OF
- default y
- select USB_OHCI_BIG_ENDIAN_DESC
- select USB_OHCI_BIG_ENDIAN_MMIO
-
-config USB_OHCI_HCD_PPC_OF_LE
- bool Support little endian HC
- depends on USB_OHCI_HCD_PPC_OF
- default n
- select USB_OHCI_LITTLE_ENDIAN
-
config USB_OHCI_HCD_PCI
bool OHCI support for PCI-bus USB controllers
depends on USB_OHCI_HCD PCI (STB03xxx || PPC_MPC52xx ||
USB_OHCI_HCD_PPC_OF)
@@ -180,7 +169,7 @@ config USB_OHCI_BIG_ENDIAN_MMIO
config USB_OHCI_LITTLE_ENDIAN
bool
depends on USB_OHCI_HCD
- default n if STB03xxx || PPC_MPC52xx
+ default n if STB03xxx || PPC_MPC52xx || USB_OHCI_HCD_PPC_OF
default y
config USB_UHCI_HCD
diff -pruN linux-2.6.orig/drivers/usb/host/ohci-ppc-of.c
linux-2.6/drivers/usb/host/ohci-ppc-of.c
--- linux-2.6.orig/drivers/usb/host/ohci-ppc-of.c 2007-10-24
18:44:25.0 +0400
+++ linux-2.6/drivers/usb/host/ohci-ppc-of.c2007-10-24 19:32:21.0
+0400
@@ -15,8 +15,8 @@
#include linux/signal.h
-#include asm/of_platform.h
-#include asm/prom.h
+#include linux/of.h
+#include linux/of_platform.h
static int __devinit
@@ -91,15 +91,10 @@ ohci_hcd_ppc_of_probe(struct of_device *
int irq;
int rv;
- int is_bigendian;
if (usb_disabled())
return -ENODEV;
- is_bigendian =
- of_device_is_compatible(dn, ohci-bigendian) ||
- of_device_is_compatible(dn, ohci-be);
-
dev_dbg(op-dev, initializing PPC-OF USB Controller\n);
rv = of_address_to_resource(dn, 0, res);
@@ -134,9 +129,10 @@ ohci_hcd_ppc_of_probe(struct of_device *
}
ohci = hcd_to_ohci(hcd);
- if (is_bigendian) {
+
+ if (of_get_property(dn, big-endian, NULL)) {
ohci-flags |= OHCI_QUIRK_BE_MMIO | OHCI_QUIRK_BE_DESC;
- if (of_device_is_compatible(dn, mpc5200-ohci))
+ if (of_device_is_compatible(dn, mpc5200-usb-ohci))
ohci-flags |= OHCI_QUIRK_FRAME_NO;
}
@@ -187,35 +183,13 @@ static int ohci_hcd_ppc_of_shutdown(stru
static struct of_device_id ohci_hcd_ppc_of_match[] = {
-#ifdef CONFIG_USB_OHCI_HCD_PPC_OF_BE
- {
- .name = usb,
- .compatible = ohci-bigendian,
- },
- {
- .name = usb,
- .compatible = ohci-be,
- },
-#endif
-#ifdef CONFIG_USB_OHCI_HCD_PPC_OF_LE
- {
- .name = usb,
- .compatible = ohci-littledian,
- },
{
- .name = usb,
- .compatible = ohci-le,
+ .compatible = usb-ohci,
},
-#endif
{},
};
MODULE_DEVICE_TABLE(of, ohci_hcd_ppc_of_match);
-#if!defined(CONFIG_USB_OHCI_HCD_PPC_OF_BE) \
- !defined(CONFIG_USB_OHCI_HCD_PPC_OF_LE)
-#error No endianess selected for ppc-of-ohci
-#endif
-
static struct of_platform_driver ohci_hcd_ppc_of_driver = {
.name = ppc-of-ohci,
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 2/2] PowerPC: Update USB OHCI DTS entires for new bindings
Adjust mpc52xx DTS entries to support reworked ohci-ppc-of driver.
Use compatible usb-ohci and an empty big-endian property for
USB_OHCI_BIG_ENDIAN_DESC and USB_OHCI_BIG_ENDIAN_MMIO support.
This also adds OHCI DTS entry for Sequoia PowerPC 440EPx board.
Signed-off-by: Valentine Barshak [EMAIL PROTECTED]
---
arch/powerpc/boot/dts/lite5200.dts |5 +++--
arch/powerpc/boot/dts/lite5200b.dts |5 +++--
arch/powerpc/boot/dts/sequoia.dts |8
3 files changed, 14 insertions(+), 4 deletions(-)
diff -pruN linux-2.6.orig/arch/powerpc/boot/dts/lite5200b.dts
linux-2.6/arch/powerpc/boot/dts/lite5200b.dts
--- linux-2.6.orig/arch/powerpc/boot/dts/lite5200b.dts 2007-10-24
18:44:00.0 +0400
+++ linux-2.6/arch/powerpc/boot/dts/lite5200b.dts 2007-10-24
19:20:31.0 +0400
@@ -183,8 +183,9 @@
};
[EMAIL PROTECTED] {
- device_type = usb-ohci-be;
- compatible = mpc5200b-ohci,mpc5200-ohci,ohci-be;
+ device_type = usb-ohci;
+ compatible =
mpc5200b-usb-ohci,mpc5200-usb-ohci,usb-ohci;
+ big-endian;
reg = 1000 ff;
interrupts = 2 6 0;
interrupt-parent = mpc5200_pic;
diff -pruN linux-2.6.orig/arch/powerpc/boot/dts/lite5200.dts
linux-2.6/arch/powerpc/boot/dts/lite5200.dts
--- linux-2.6.orig/arch/powerpc/boot/dts/lite5200.dts 2007-10-24
18:44:00.0 +0400
+++ linux-2.6/arch/powerpc/boot/dts/lite5200.dts2007-10-24
19:21:57.0 +0400
@@ -183,8 +183,9 @@
};
[EMAIL PROTECTED] {
- device_type = usb-ohci-be;
- compatible = mpc5200-ohci,ohci-be;
+ device_type = usb-ohci;
+ compatible = mpc5200-usb-ohci,usb-ohci;
+ big-endian;
reg = 1000 ff;
interrupts = 2 6 0;
interrupt-parent = mpc5200_pic;
diff -pruN linux-2.6.orig/arch/powerpc/boot/dts/sequoia.dts
linux-2.6/arch/powerpc/boot/dts/sequoia.dts
--- linux-2.6.orig/arch/powerpc/boot/dts/sequoia.dts2007-10-24
18:44:00.0 +0400
+++ linux-2.6/arch/powerpc/boot/dts/sequoia.dts 2007-10-24 19:30:36.0
+0400
@@ -122,6 +122,14 @@
interrupt-map-mask = ;
};
+ USB1: [EMAIL PROTECTED] {
+ compatible = usb-ohci-440epx, usb-ohci;
+ reg = 0 e400 60;
+ big-endian;
+ interrupt-parent = UIC0;
+ interrupts = 15 8;
+ };
+
POB0: opb {
compatible = ibm,opb-440epx, ibm,opb;
#address-cells = 1;
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Audio codec device tree entries
On 10/24/07, Jon Smirl [EMAIL PROTECTED] wrote:
On 10/24/07, Grant Likely [EMAIL PROTECTED] wrote:
Do you want to pick one and add it to the device tree documentation
with an example for i2s and ac97? I'll use which ever one is picked.
Sure, I'll draft something up and post it for review.
On the device probing front; what about this method:
Rather than trying to figure things out from the board model, or the
combination of the codec and i2s bus; add another node to represent
the sound circuit. All that node would need is a unique compatible
property and a phandle to either the i2s bus or the codec (depending
on which binding approach is used). It could have additional
properties to represent optional features, etc.
That's the pseudo-sound node proposal that other people objected to.
Heh, I'm one of the folks who objected to it; here's what was written:
[EMAIL PROTECTED] { // use to trigger loading platform specific fabric
driver
device_type = pseudo-sound
};
I don't think this is a good idea. The device tree is for describing
your hardware; so the layout should reflect that. Make the platform
code do the right thing with the real nodes.
What I objected to was that the pseudo-sound node didn't contain any
real information. It was just being a hook to trigger calling a probe
function. If you're going to do that then you might as well just call
it directly from platform code.
For example:
[EMAIL PROTECTED] {
compatible = mfg,board,sound // The board might have
more than one sound i/f which could be wired differently
codec-handle = codec0;
};
The difference here is that the node provides real information about
the board. It has a compatible field which tells you *exactly* what
sound circuit is present on the board. It can have additional
information that does make sense to encode into the device tree (ie.
the codec that is used). It's not addressable (no registers or
anything), but it does describe the board.
It would be possible and reasonable for a single fabric driver to work
with many different circuit layouts as long as it has the information
needed to adapt each instance.
Do you even need the parameters, how about simply this?
sound-fabric {
};
But this goes back to having nodes that don't provide any information.
You don't want that.
That will trigger loading all of the sound-fabric drivers built into
the kernel. In their probe functions they can look in the device tree
and extract the machine name and then decide to stay loaded or fail
the probe.
...
Now is probably a good time to mention that there is *nothing* in the
device tree that enforces a 1:1 relationship between device tree nodes
and driver instances. Sure, it make sense to register the i2s and
codec drivers from probing on the i2s and codec nodes. However, there
is nothing that prevents the codec driver from *also* registering a
fabric driver based on a property in the codec node or the board-level
compatible property.
Fabric drivers are codec specific anyway. It's not all that
unrealistic for the device tree binding for a codec to have a list of
fabric drivers that it can register.
Cheers,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
[EMAIL PROTECTED]
(403) 399-0195
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Audio codec device tree entries
Grant Likely wrote: Now is probably a good time to mention that there is *nothing* in the device tree that enforces a 1:1 relationship between device tree nodes and driver instances. Sure, it make sense to register the i2s and codec drivers from probing on the i2s and codec nodes. However, there is nothing that prevents the codec driver from *also* registering a fabric driver based on a property in the codec node or the board-level compatible property. Wouldn't it make more sense for the fabric driver to register the codec driver? The fabric driver is the master of the other drivers, should it needs to load and run first. Fabric drivers are codec specific anyway. Yes and no. They're really platform-specific, but they should be able to scan the device tree, determine which codecs are actually on the system, and then link in the appropriate codec driver. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Audio codec device tree entries
Grant Likely wrote: If you need to scan the tree, don't do it when the driver registers, do it in the platform code instead. Otherwise you unconditionally incur the penalty of scanning the whole device tree on every system that loads the driver, regardless of whether or not the device is present. So your saying that the fabric driver should be embedded in the platform driver? ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Audio codec device tree entries
On 10/24/07, Timur Tabi [EMAIL PROTECTED] wrote: Grant Likely wrote: If you need to scan the tree, don't do it when the driver registers, do it in the platform code instead. Otherwise you unconditionally incur the penalty of scanning the whole device tree on every system that loads the driver, regardless of whether or not the device is present. So your saying that the fabric driver should be embedded in the platform driver? No; that's not what I mean. But the scanning of the device tree to decide whether or not to instantiate the driver should be called from platform code. The device tree should not be scanned on driver loading. In other words: populate either a platform_device or an of_platform_device that the driver can bind against. Cheers, g. -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. [EMAIL PROTECTED] (403) 399-0195 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Audio codec device tree entries
On 10/24/07, Timur Tabi [EMAIL PROTECTED] wrote: Grant Likely wrote: Now is probably a good time to mention that there is *nothing* in the device tree that enforces a 1:1 relationship between device tree nodes and driver instances. Sure, it make sense to register the i2s and codec drivers from probing on the i2s and codec nodes. However, there is nothing that prevents the codec driver from *also* registering a fabric driver based on a property in the codec node or the board-level compatible property. Wouldn't it make more sense for the fabric driver to register the codec driver? The fabric driver is the master of the other drivers, should it needs to load and run first. It doesn't really matter. There doesn't need to be a 1:1 relationship between driver instances and device nodes. A probe on one device node can cause the instantiation of both a fabric driver and a codec driver (just put the appropriate calls in the of_platform_bus probe hook). Fabric drivers are codec specific anyway. Yes and no. They're really platform-specific, but they should be able to scan the device tree, determine which codecs are actually on the system, and then link in the appropriate codec driver. My point is; most likely if you change the codec, you need to change the fabric driver too. There will be many fabric drivers using a single codec, but there will not be many codec drivers using a single fabric. g. -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. [EMAIL PROTECTED] (403) 399-0195 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] wrapper: Revert ps3 binary flag usage, and remove .bin suffix.
The ps3 target produces two images, and the binary one is not the
primary image that corresponds to the -o flag; thus, it no longer
uses the generic binary flag.
On platforms which do use the binary flag, it no longer produces a
.bin suffix, so that the output file matches what was passed to the -o flag.
This should fix the zImage ln problems for the ps3 target.
Signed-off-by: Scott Wood [EMAIL PROTECTED]
---
arch/powerpc/boot/wrapper | 13 +++--
1 files changed, 7 insertions(+), 6 deletions(-)
diff --git a/arch/powerpc/boot/wrapper b/arch/powerpc/boot/wrapper
index 39b27e5..ece6f49 100755
--- a/arch/powerpc/boot/wrapper
+++ b/arch/powerpc/boot/wrapper
@@ -149,7 +149,6 @@ cuboot*)
ps3)
platformo=$object/ps3-head.o $object/ps3-hvcall.o $object/ps3.o
lds=$object/zImage.ps3.lds
-binary=y
gzip=
ext=bin
objflags=-O binary --set-section-flags=.bss=contents,alloc,load,data
@@ -233,7 +232,7 @@ entry=`${CROSS}objdump -f $ofile | grep '^start address '
| cut -d' ' -f3`
if [ -n $binary ]; then
mv $ofile $ofile.elf
-${CROSS}objcopy -O binary $ofile.elf $ofile.bin
+${CROSS}objcopy -O binary $ofile.elf $ofile
fi
# post-processing needed for some platforms
@@ -246,9 +245,9 @@ coff)
$object/hack-coff $ofile
;;
cuboot*)
-gzip -f -9 $ofile.bin
+gzip -f -9 $ofile
mkimage -A ppc -O linux -T kernel -C gzip -a $base -e $entry \
-$uboot_version -d $ofile.bin.gz $ofile
+$uboot_version -d $ofile.gz $ofile
;;
treeboot*)
mv $ofile $ofile.elf
@@ -269,11 +268,11 @@ ps3)
# then copied to offset 0x100. At runtime the bootwrapper program
# copies the 0x100 bytes at __system_reset_kernel to addr 0x100.
-system_reset_overlay=0x`${CROSS}nm $ofile.elf \
+system_reset_overlay=0x`${CROSS}nm $ofile \
| grep ' __system_reset_overlay$' \
| cut -d' ' -f1`
system_reset_overlay=`printf %d $system_reset_overlay`
-system_reset_kernel=0x`${CROSS}nm $ofile.elf \
+system_reset_kernel=0x`${CROSS}nm $ofile \
| grep ' __system_reset_kernel$' \
| cut -d' ' -f1`
system_reset_kernel=`printf %d $system_reset_kernel`
@@ -282,6 +281,8 @@ ps3)
rm -f $object/otheros.bld
+${CROSS}objcopy -O binary $ofile $ofile.bin
+
msg=$(dd if=$ofile.bin of=$ofile.bin conv=notrunc \
skip=$overlay_dest seek=$system_reset_kernel \
count=$overlay_size bs=1 21)
--
1.5.3.4
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Audio codec device tree entries
On 10/24/07, Grant Likely [EMAIL PROTECTED] wrote:
Heh, I'm one of the folks who objected to it; here's what was written:
[EMAIL PROTECTED] { // use to trigger loading platform specific fabric
driver
device_type = pseudo-sound
};
I don't think this is a good idea. The device tree is for describing
your hardware; so the layout should reflect that. Make the platform
code do the right thing with the real nodes.
What I objected to was that the pseudo-sound node didn't contain any
real information. It was just being a hook to trigger calling a probe
function. If you're going to do that then you might as well just call
it directly from platform code.
Calling it directly from the platform code is an option, but where
does the fabric driver code live? It doesn't make a lot of sense to
put ALSA code into arch/powerpc/platforms/52xx. I could make a
function call from arch/powerpc/platforms/52xx over to
sound/soc/powerpc but that's not very pretty.
Another option is to make the fabric driver a struct platform_driver
instead of a struct of_platform_driver. struct platform_driver is
not being probed in the current mpc5200 code. This option makes senses
to me, struct platform_driver will load without a device tree node.
The driver will still need to check and see if it is on the right
platform when more than one is compiled in.
For example:
[EMAIL PROTECTED] {
compatible = mfg,board,sound // The board might have
more than one sound i/f which could be wired differently
codec-handle = codec0;
};
The difference here is that the node provides real information about
the board. It has a compatible field which tells you *exactly* what
sound circuit is present on the board. It can have additional
information that does make sense to encode into the device tree (ie.
the codec that is used). It's not addressable (no registers or
anything), but it does describe the board.
It would be possible and reasonable for a single fabric driver to work
with many different circuit layouts as long as it has the information
needed to adapt each instance.
That is how the Apple driver is implemented. There is a single fabric
driver that uses layout-id to set everything up to match the physical
PCB.
sound/aoa/fabrics/snd-aoa-fabric-layout.c
But Apple put the layout id down inside the a sound node:
/proc/device-tree/[EMAIL PROTECTED]/[EMAIL PROTECTED]/[EMAIL PROTECTED]/[EMAIL
PROTECTED]/sound:
name sound
device_type soundchip
compatible AOAbase
built-in
layout-id0046 (70)
object-model-version 0002
vendor-id106b (4203)
platform-tas-codec-ref ff98cba8
linux,phandleff985d48
Do you even need the parameters, how about simply this?
sound-fabric {
};
But this goes back to having nodes that don't provide any information.
You don't want that.
That will trigger loading all of the sound-fabric drivers built into
the kernel. In their probe functions they can look in the device tree
and extract the machine name and then decide to stay loaded or fail
the probe.
...
Now is probably a good time to mention that there is *nothing* in the
device tree that enforces a 1:1 relationship between device tree nodes
and driver instances. Sure, it make sense to register the i2s and
codec drivers from probing on the i2s and codec nodes. However, there
is nothing that prevents the codec driver from *also* registering a
fabric driver based on a property in the codec node or the board-level
compatible property.
But there is something in the kernel that enforces it. I haven't
checked the powerpc code, but the PCI code won't probe anymore drivers
once one has attached to a device. The rule of one driver per device
is a good one. Places where that rule has been broken have caused a
lot of problems (fbdev vs DRM).
Fabric drivers are codec specific anyway. It's not all that
unrealistic for the device tree binding for a codec to have a list of
fabric drivers that it can register.
The codec drivers in asoc are completely agnostic. The same codec
driver works on x86, arm, powerpc, etc.
Cheers,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
[EMAIL PROTECTED]
(403) 399-0195
--
Jon Smirl
[EMAIL PROTECTED]
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Audio codec device tree entries
On 10/24/07, Jon Smirl [EMAIL PROTECTED] wrote:
On 10/24/07, Grant Likely [EMAIL PROTECTED] wrote:
Heh, I'm one of the folks who objected to it; here's what was written:
[EMAIL PROTECTED] { // use to trigger loading platform specific
fabric driver
device_type = pseudo-sound
};
I don't think this is a good idea. The device tree is for describing
your hardware; so the layout should reflect that. Make the platform
code do the right thing with the real nodes.
What I objected to was that the pseudo-sound node didn't contain any
real information. It was just being a hook to trigger calling a probe
function. If you're going to do that then you might as well just call
it directly from platform code.
Calling it directly from the platform code is an option, but where
does the fabric driver code live? It doesn't make a lot of sense to
put ALSA code into arch/powerpc/platforms/52xx. I could make a
function call from arch/powerpc/platforms/52xx over to
sound/soc/powerpc but that's not very pretty.
Another option is to make the fabric driver a struct platform_driver
instead of a struct of_platform_driver. struct platform_driver is
not being probed in the current mpc5200 code. This option makes senses
to me, struct platform_driver will load without a device tree node.
The driver will still need to check and see if it is on the right
platform when more than one is compiled in.
Yes, this is a good approach.
It would be possible and reasonable for a single fabric driver to work
with many different circuit layouts as long as it has the information
needed to adapt each instance.
That is how the Apple driver is implemented. There is a single fabric
driver that uses layout-id to set everything up to match the physical
PCB.
sound/aoa/fabrics/snd-aoa-fabric-layout.c
But Apple put the layout id down inside the a sound node:
/proc/device-tree/[EMAIL PROTECTED]/[EMAIL PROTECTED]/[EMAIL
PROTECTED]/[EMAIL PROTECTED]/sound:
name sound
device_type soundchip
compatible AOAbase
built-in
layout-id0046 (70)
object-model-version 0002
vendor-id106b (4203)
platform-tas-codec-ref ff98cba8
linux,phandleff985d48
Yes, this is the same idea. I don't think benh and segher were
particularly fond of it though. I think Segher in particular had a
preference for the platform code probing approach.
Now is probably a good time to mention that there is *nothing* in the
device tree that enforces a 1:1 relationship between device tree nodes
and driver instances. Sure, it make sense to register the i2s and
codec drivers from probing on the i2s and codec nodes. However, there
is nothing that prevents the codec driver from *also* registering a
fabric driver based on a property in the codec node or the board-level
compatible property.
But there is something in the kernel that enforces it. I haven't
checked the powerpc code, but the PCI code won't probe anymore drivers
once one has attached to a device. The rule of one driver per device
is a good one. Places where that rule has been broken have caused a
lot of problems (fbdev vs DRM).
heh; there's isn't a 1:1 relationship between device tree nodes and
device objects either. You create the device objects that you need;
either on the platform bus or the of_platform bus.
The probe of an of_platform device can trigger the creation of a
plaform_device node for *another* driver. This approach is safe.
Fabric drivers are codec specific anyway. It's not all that
unrealistic for the device tree binding for a codec to have a list of
fabric drivers that it can register.
The codec drivers in asoc are completely agnostic. The same codec
driver works on x86, arm, powerpc, etc.
Yes the *driver* is agnostic; but the *binding* doesn't have to be. :-)
Cheers,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
[EMAIL PROTECTED]
(403) 399-0195
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 2/2] mpc5200: psc-spi driver must not touch port_config or cdm registers
From: Grant Likely [EMAIL PROTECTED]
port_config and the cdm are the responsibility of firmware; and if
firmware doesn't set it up correctly, it should be fixed up by
platform code on a per-board basis because it's a property of the
board.
Drivers should never touch these registers.
Signed-off-by: Grant Likely [EMAIL PROTECTED]
---
drivers/spi/mpc52xx_psc_spi.c | 84 -
1 files changed, 8 insertions(+), 76 deletions(-)
diff --git a/drivers/spi/mpc52xx_psc_spi.c b/drivers/spi/mpc52xx_psc_spi.c
index 7051e6c..44d1110 100644
--- a/drivers/spi/mpc52xx_psc_spi.c
+++ b/drivers/spi/mpc52xx_psc_spi.c
@@ -328,77 +328,15 @@ static void mpc52xx_psc_spi_cleanup(struct spi_device
*spi)
kfree(spi-controller_state);
}
-static int mpc52xx_psc_spi_port_config(int psc_id, struct mpc52xx_psc_spi *mps)
+static int mpc52xx_psc_spi_config(int psc_id, struct mpc52xx_psc_spi *mps)
{
- struct mpc52xx_cdm __iomem *cdm;
- struct mpc52xx_gpio __iomem *gpio;
struct mpc52xx_psc __iomem *psc = mps-psc;
- u32 ul;
- u32 mclken_div;
- int ret = 0;
+ int rc;
-#if defined(CONFIG_PPC_MERGE)
- cdm = mpc52xx_find_and_map(mpc5200-cdm);
- gpio = mpc52xx_find_and_map(mpc5200-gpio);
-#else
- cdm = ioremap(MPC52xx_PA(MPC52xx_CDM_OFFSET), MPC52xx_CDM_SIZE);
- gpio = ioremap(MPC52xx_PA(MPC52xx_GPIO_OFFSET), MPC52xx_GPIO_SIZE);
-#endif
- if (!cdm || !gpio) {
- printk(KERN_ERR Error mapping CDM/GPIO\n);
- ret = -EFAULT;
- goto unmap_regs;
- }
-
- /* default sysclk is 512MHz */
- mclken_div = 0x8000 |
- (((mps-sysclk ? mps-sysclk : 51200) / MCLK) 0x1FF);
-
- switch (psc_id) {
- case 1:
- ul = in_be32(gpio-port_config);
- ul = 0xFFF8;
- ul |= 0x0006;
- out_be32(gpio-port_config, ul);
- out_be16(cdm-mclken_div_psc1, mclken_div);
- ul = in_be32(cdm-clk_enables);
- ul |= 0x0020;
- out_be32(cdm-clk_enables, ul);
- break;
- case 2:
- ul = in_be32(gpio-port_config);
- ul = 0xFF8F;
- ul |= 0x0060;
- out_be32(gpio-port_config, ul);
- out_be16(cdm-mclken_div_psc2, mclken_div);
- ul = in_be32(cdm-clk_enables);
- ul |= 0x0040;
- out_be32(cdm-clk_enables, ul);
- break;
- case 3:
- ul = in_be32(gpio-port_config);
- ul = 0xF0FF;
- ul |= 0x0600;
- out_be32(gpio-port_config, ul);
- out_be16(cdm-mclken_div_psc3, mclken_div);
- ul = in_be32(cdm-clk_enables);
- ul |= 0x0080;
- out_be32(cdm-clk_enables, ul);
- break;
- case 6:
- ul = in_be32(gpio-port_config);
- ul = 0xFF8F;
- ul |= 0x0070;
- out_be32(gpio-port_config, ul);
- out_be16(cdm-mclken_div_psc6, mclken_div);
- ul = in_be32(cdm-clk_enables);
- ul |= 0x0010;
- out_be32(cdm-clk_enables, ul);
- break;
- default:
- ret = -EINVAL;
- goto unmap_regs;
- }
+ /* Setup a desirable MCLK */
+ rc = mpc52xx_cdm_set_psc_clk(psc_id, MCLK);
+ if (rc)
+ return rc;
/* Reset the PSC into a known state */
out_8(psc-command, MPC52xx_PSC_RST_RX);
@@ -422,13 +360,7 @@ static int mpc52xx_psc_spi_port_config(int psc_id, struct
mpc52xx_psc_spi *mps)
mps-bits_per_word = 8;
-unmap_regs:
- if (cdm)
- iounmap(cdm);
- if (gpio)
- iounmap(gpio);
-
- return ret;
+ return 0;
}
static irqreturn_t mpc52xx_psc_spi_isr(int irq, void *dev_id)
@@ -493,7 +425,7 @@ static int __init mpc52xx_psc_spi_do_probe(struct device
*dev, u32 regaddr,
if (ret)
goto free_master;
- ret = mpc52xx_psc_spi_port_config(master-bus_num, mps);
+ ret = mpc52xx_psc_spi_config(master-bus_num-1, mps);
if (ret 0)
goto free_irq;
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 0/2] mpc52xx: stop drivers from accessing clock config directly
Domen, Here's a real solution to the problem. I've somewhat tested this on the lite5200b. Can you give it a spin on efika and see if SPI still works for you? Thanks, g. -- Grant Likely, B.Sc. P.Eng. Secret Lab Technologies Ltd. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] PowerPC: Add BCM5248 and Marvell 88E1111 PHY support to NEW EMAC.
Benjamin Herrenschmidt wrote:
On Tue, 2007-10-23 at 20:57 -0500, Valentine Barshak wrote:
+static int m88e_init(struct mii_phy *phy)
+{
+printk(%s: Marvell 88E Ethernet\n, __FUNCTION__);
+phy_write(phy, 0x14, 0x0ce3);
+phy_write(phy, 0x18, 0x4101);
+phy_write(phy, 0x09, 0x0e00);
+phy_write(phy, 0x04, 0x01e1);
+phy_write(phy, 0x00, 0x9140);
+phy_write(phy, 0x00, 0x1140);
+
+return 0;
+}
Care to put a few comments on why the above is necessary and what it
does ?
I think this set's up Marvell ext control (0x14) and led control (0x18)
registers with some default values, Also sets some bits in the
CTRL1000, ADVERTISE and basic mode control registers and resets the phy
for the changes to take effect. Unfortunately, I don't have a detailed
88E description and can't tell anything about it. Looks like the
code was originally ported from u-boot and is needed to init the phy :)
Stefan, do you have any info on this?
Thanks,
Valentine.
Thanks !
Ben.
+static struct mii_phy_ops m88e_phy_ops = {
+.init = m88e_init,
+.setup_aneg = genmii_setup_aneg,
+.setup_forced = genmii_setup_forced,
+.poll_link = genmii_poll_link,
+.read_link = genmii_read_link
+};
+
+static struct mii_phy_def m88e_phy_def = {
+
+.phy_id = 0x01410CC0,
+.phy_id_mask= 0x0ff0,
+.name = Marvell 88E Ethernet,
+.ops= m88e_phy_ops,
+};
+
static struct mii_phy_def *mii_phy_table[] = {
cis8201_phy_def,
+bcm5248_phy_def,
+m88e_phy_def,
genmii_phy_def,
NULL
};
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Audio codec device tree entries
On 10/24/07, Timur Tabi [EMAIL PROTECTED] wrote: Jon Smirl wrote: Calling it directly from the platform code is an option, but where does the fabric driver code live? It doesn't make a lot of sense to put ALSA code into arch/powerpc/platforms/52xx. I could make a function call from arch/powerpc/platforms/52xx over to sound/soc/powerpc but that's not very pretty. sound/soc/fsl is where the non-codec ASoC drivers for Freescale parts should go. Why are you using a vendor named directory? I don't believe vendor named directories are used anywhere in the kernel. The directories are always named after the platform or architecture. Vendor directories end up in a big mess if Freescale decides to sell a CPU to someone else. The codec drivers in asoc are completely agnostic. The same codec driver works on x86, arm, powerpc, etc. Well, in theory at least. I never tried my cs4270 driver on anything but PowerPC. -- Jon Smirl [EMAIL PROTECTED] ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Audio codec device tree entries
Jon Smirl wrote: Why are you using a vendor named directory? I don't believe vendor named directories are used anywhere in the kernel. The directories are always named after the platform or architecture. Vendor directories end up in a big mess if Freescale decides to sell a CPU to someone else. Two reasons: 1) The sound/soc directory already has names like at91 and pxa, so I thought fsl is appropriate. 2) There may not be any directories named fsl, but there are plenty of files with that name: ./arch/powerpc/boot/fsl-soc.c ./arch/powerpc/boot/fsl-soc.h ./arch/powerpc/boot/fsl-soc.o ./arch/powerpc/mm/fsl_booke_mmu.c ./arch/powerpc/platforms/fsl_uli1575.c ./arch/powerpc/sysdev/fsl_pci.c ./arch/powerpc/sysdev/fsl_pci.h ./arch/powerpc/sysdev/fsl_soc.c ./arch/powerpc/sysdev/fsl_soc.h ./arch/powerpc/sysdev/fsl_soc.o ./arch/ppc/mm/fsl_booke_mmu.c ./drivers/usb/gadget/fsl_usb2_udc.c ./drivers/usb/gadget/fsl_usb2_udc.h ./include/linux/fsl_devices.h ./include/config/fsl Having said all that, if you really think sound/soc/powerpc is better than sound/soc/fsl, I won't complain. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
RE: Ocotea board?
The AMCC 440GX processor is by no means obsolete. There are more customers for this processor every month. There is a new, comprehensive evaluation kit called Taishan (http://www.amcc.com/Embedded/evalkits/440GX_PB_1_04.pdf), which AMCC provides to customers and partners. Ocotea is a board that was originally designed and used for processor validation purposes. Regards, Charlie -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jeff Mock Sent: Wednesday, October 24, 2007 12:10 PM To: linuxppc-dev@ozlabs.org; [EMAIL PROTECTED] Subject: Re: Ocotea board? Thanks for all of the replies, it's nice to hear that the 440GX isn't obsolete yet... A relatively arbitrary decision, but I'm going to send the Ocotea board to Josh. jeff Jeff Mock wrote: Is the Ocotea board (the original 440GX eval board) still interesting? I'm wrapping up a project using the 440GX, I started out hacking on the Ocotea board to get started, but we moved off Ocotea long ago onto our own hardware. I'm cleaning up the lab now that the project is nearly finished and I would like to give the board to someone that will put it to good use. I've sponged off this mailing list quite a lot, it's about time I give a little something back. The board has been hacked a little bit but still works fine. I just powered it up and it happily booted Linux via TFTP. The boot ROM now has u-boot, the original PIBs (or whatever) is long gone. All I ask is that you're self-sufficient and don't bug me too much about it... Can someone recommend a good home? Otherwise it will wind up in storeroom purgatory. jeff ___ Linuxppc-embedded mailing list [EMAIL PROTECTED] https://ozlabs.org/mailman/listinfo/linuxppc-embedded ___ Linuxppc-embedded mailing list [EMAIL PROTECTED] https://ozlabs.org/mailman/listinfo/linuxppc-embedded CONFIDENTIALITY NOTICE: This e-mail message, including any attachments, is for the sole use of the intended recipient(s) and contains information that is confidential and proprietary to Applied Micro Circuits Corporation or its subsidiaries. It is to be used solely for the purpose of furthering the parties' business relationship. All unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Audio codec device tree entries
On 10/24/07, Timur Tabi [EMAIL PROTECTED] wrote: Jon Smirl wrote: Why are you using a vendor named directory? I don't believe vendor named directories are used anywhere in the kernel. The directories are always named after the platform or architecture. Vendor directories end up in a big mess if Freescale decides to sell a CPU to someone else. Two reasons: 1) The sound/soc directory already has names like at91 and pxa, so I thought fsl is appropriate. pxa is the processor family. Intel sold the pxa cpus to Marvell six months ago. 2) There may not be any directories named fsl, but there are plenty of files with that name: ./arch/powerpc/boot/fsl-soc.c ./arch/powerpc/boot/fsl-soc.h ./arch/powerpc/boot/fsl-soc.o ./arch/powerpc/mm/fsl_booke_mmu.c ./arch/powerpc/platforms/fsl_uli1575.c ./arch/powerpc/sysdev/fsl_pci.c ./arch/powerpc/sysdev/fsl_pci.h ./arch/powerpc/sysdev/fsl_soc.c ./arch/powerpc/sysdev/fsl_soc.h ./arch/powerpc/sysdev/fsl_soc.o ./arch/ppc/mm/fsl_booke_mmu.c ./drivers/usb/gadget/fsl_usb2_udc.c ./drivers/usb/gadget/fsl_usb2_udc.h ./include/linux/fsl_devices.h ./include/config/fsl Having said all that, if you really think sound/soc/powerpc is better than sound/soc/fsl, I won't complain. -- Jon Smirl [EMAIL PROTECTED] ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: New time code miscalculates cpu usage
On Wed, Oct 17, 2007 at 04:07:48PM +1000, Tony Breeds wrote:
On Tue, Oct 16, 2007 at 03:25:25PM -0500, Olof Johansson wrote:
Hi,
Not sure when this started happening, but I wanted to report it. I'll
start bisecting in a day or two if noone else has gotten around to
looking at it:
$ echo int main(void) { while(1); } test.c ; gcc test.c
$ time ./a.out sleep 2 ; killall a.out
real0m2.008s
user0m4.014s
sys 0m0.002s
Seen on POWER5 and PA6T, haven't tried anything else yet.
For what it's worth, this is my bug. I suspected it, and git bisect
confirmed it.I have an ugly work around now, but hope to have something
better out tomorrow.
Hi Tony,
Any news?
-Olof
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 0/2] mpc52xx: stop drivers from accessing clock config directly
On 10/24/07, Domen Puncer [EMAIL PROTECTED] wrote: On 24/10/07 12:24 -0600, Grant Likely wrote: Domen, Here's a real solution to the problem. I've somewhat tested this on the lite5200b. Can you give it a spin on efika and see if SPI still works for you? My test case was lite5200b too, I don't think I ever tried SPI on efika. (Are even the right pins on irda connector, or is a necessary line missing?) Hmm, I guess that's right. Can you at least make sure it still boots on Efika? Some of the clock detection stuff has changed so I want to make sure it still boots. Are you setup to do your SPI test easily on you lite5200b? When I say somewhat tested; I mean I probed the driver and it didn't crash. :-) I haven't tried to run traffic over it. Can you check that on your system? If not, can you email me what setup/programs you used for testing? I know very little about the SPI infrastructure. Thanks, g. -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. [EMAIL PROTECTED] (403) 399-0195 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: New time code miscalculates cpu usage
Hello.
Olof Johansson wrote:
Not sure when this started happening, but I wanted to report it. I'll
start bisecting in a day or two if noone else has gotten around to
looking at it:
$ echo int main(void) { while(1); } test.c ; gcc test.c
$ time ./a.out sleep 2 ; killall a.out
real0m2.008s
user0m4.014s
sys 0m0.002s
Seen on POWER5 and PA6T, haven't tried anything else yet.
I'm not surprised -- the kernel accounts twice for each tick.
WBR, Sergei
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 0/2] mpc52xx: stop drivers from accessing clock config directly
On 24/10/07 14:14 -0600, Grant Likely wrote:
On 10/24/07, Domen Puncer [EMAIL PROTECTED] wrote:
On 24/10/07 12:24 -0600, Grant Likely wrote:
Domen,
Here's a real solution to the problem. I've somewhat tested this on
the lite5200b. Can you give it a spin on efika and see if SPI still
works for you?
My test case was lite5200b too, I don't think I ever tried SPI on
efika.
(Are even the right pins on irda connector, or is a necessary line
missing?)
Hmm, I guess that's right. Can you at least make sure it still boots
on Efika? Some of the clock detection stuff has changed so I want to
make sure it still boots.
OK. I'll do that tomorrow.
Are you setup to do your SPI test easily on you lite5200b? When I say
somewhat tested; I mean I probed the driver and it didn't crash.
:-) I haven't tried to run traffic over it.
Sorry, lite5200b is resting these days. :-(
Can you check that on your system? If not, can you email me what
setup/programs you used for testing? I know very little about the SPI
infrastructure.
For userspace part I used something like: Documentation/spi/spidev
And for kernel the attached, to fill get binded to spidev driver.
Domen
Thanks,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
[EMAIL PROTECTED]
(403) 399-0195
--
Domen Puncer | Research Development
.
Telargo d.o.o. | Zagrebška cesta 20 | 2000 Maribor | Slovenia
.
www.telargo.com
---
drivers/spi/Makefile |1 +
drivers/spi/spi_test_devices.c | 38 ++
2 files changed, 39 insertions(+)
Index: work-powerpc.git/drivers/spi/Makefile
===
--- work-powerpc.git.orig/drivers/spi/Makefile
+++ work-powerpc.git/drivers/spi/Makefile
@@ -35,3 +35,4 @@ obj-$(CONFIG_SPI_SPIDEV) += spidev.o
# SPI slave drivers (protocol for that link)
# ... add above this line ...
+obj-m += spi_test_devices.o
Index: work-powerpc.git/drivers/spi/spi_test_devices.c
===
--- /dev/null
+++ work-powerpc.git/drivers/spi/spi_test_devices.c
@@ -0,0 +1,38 @@
+#include linux/module.h
+#include linux/device.h
+#include linux/spi/spi.h
+
+static struct spi_board_info spi_info[7];
+static struct spi_device *spidev[7];
+static int testdev_init(void)
+{
+ struct spi_board_info *info;
+ int i;
+
+ for (i=0; i7; i++) {
+ struct spi_master *master;
+
+ info = spi_info[i];
+ //info-max_speed_hz = 2*100;
+ info-max_speed_hz = 10;
+ //info-max_speed_hz = 1*100;
+ strcpy(info-modalias, spidev);
+
+ master = spi_busnum_to_master(i);
+ if (master)
+ spidev[i] = spi_new_device(master, info);
+ }
+ return 0;
+}
+
+static void testdev_exit(void)
+{
+ /* there is no _remove? */
+ /*for (i=0; i7; i++) {
+ }*/
+}
+
+module_init(testdev_init);
+module_exit(testdev_exit);
+
+MODULE_LICENSE(GPL);
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
i2c-mpc.c driver issues
While browsing the i2c-mpc.c driver I noticed some things that look odd to me so I figured I report them. Could not find a maintainer in the MAINTANERS file so I sent here, cc:ed linuxppc-dev as well. 1) There are a lot of return -1 error code that is propagated back to userspace. Should be changed to proper -Exxx codes. 2) mpc_read(), according to the comment below it sends a STOP condition here but this function does not known if this is the last read or not. mpc_xfer is the one that knows when the transaction is over and should send the stop, which it already does. /* Generate stop on last byte */ if (i == length - 1) writeccr(i2c, CCR_MIEN | CCR_MEN | CCR_TXAK); Jocke ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: New time code miscalculates cpu usage
On Thu, 2007-10-25 at 00:17 +0400, Sergei Shtylyov wrote:
Hello.
Olof Johansson wrote:
Not sure when this started happening, but I wanted to report it. I'll
start bisecting in a day or two if noone else has gotten around to
looking at it:
$ echo int main(void) { while(1); } test.c ; gcc test.c
$ time ./a.out sleep 2 ; killall a.out
real0m2.008s
user0m4.014s
sys 0m0.002s
Seen on POWER5 and PA6T, haven't tried anything else yet.
I'm not surprised -- the kernel accounts twice for each tick.
Your input would be much more valuable if you actually pointed out where
that happens and why since you seem to know it.
Ben.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 1/2] USB: Rework OHCI PPC OF for new bindings
Valentine Barshak wrote:
Rework ohci-ppc-of driver to use big-endian property instead of
ohci-be/ohci-le compatible strings. Also remove unnecessary
user-selectable USB_OHCI_HCD_PPC_OF_LE/BE stuff, because
USB_OHCI_BIG_ENDIAN_DESC/MMIO should always be enabled for ppc
and USB_OHCI_LITTLE_ENDIAN is selected for USB_OHCI_HCD_PCI by default.
Signed-off-by: Valentine Barshak [EMAIL PROTECTED]
---
[snip]
config USB_UHCI_HCD
diff -pruN linux-2.6.orig/drivers/usb/host/ohci-ppc-of.c
linux-2.6/drivers/usb/host/ohci-ppc-of.c
--- linux-2.6.orig/drivers/usb/host/ohci-ppc-of.c 2007-10-24
18:44:25.0 +0400
+++ linux-2.6/drivers/usb/host/ohci-ppc-of.c 2007-10-24 19:32:21.0
+0400
@@ -15,8 +15,8 @@
#include linux/signal.h
-#include asm/of_platform.h
-#include asm/prom.h
+#include linux/of.h
+#include linux/of_platform.h
static int __devinit
@@ -91,15 +91,10 @@ ohci_hcd_ppc_of_probe(struct of_device *
int irq;
int rv;
- int is_bigendian;
if (usb_disabled())
return -ENODEV;
- is_bigendian =
- of_device_is_compatible(dn, ohci-bigendian) ||
- of_device_is_compatible(dn, ohci-be);
-
dev_dbg(op-dev, initializing PPC-OF USB Controller\n);
rv = of_address_to_resource(dn, 0, res);
@@ -134,9 +129,10 @@ ohci_hcd_ppc_of_probe(struct of_device *
}
ohci = hcd_to_ohci(hcd);
- if (is_bigendian) {
+
+ if (of_get_property(dn, big-endian, NULL)) {
ohci-flags |= OHCI_QUIRK_BE_MMIO | OHCI_QUIRK_BE_DESC;
- if (of_device_is_compatible(dn, mpc5200-ohci))
+ if (of_device_is_compatible(dn, mpc5200-usb-ohci))
ohci-flags |= OHCI_QUIRK_FRAME_NO;
}
Just a note, this is a fairly destructive change and will stop the Efika
from having it's USB ports detected.
I've updated the Efika Device Tree Supplement script internally, but I
would really rather not have users be forced to update their kernel and
firmware quite so often just for what is, here, a merely aesthetic
change.
Can we just make sure real quickly that the changing of compatibles
doesn't break existing, not-easily-flashable firmwares?
At least work in 'mpc5200-ohci' for the endian check (it's always big
endian, but our device tree has no big-endian property by default and
does not contain mpc5200-usb-ohci or usb-ohci properties) otherwise we are
going to have users complain. To you guys.
--
Matt Sealey [EMAIL PROTECTED]
Genesi, Manager, Developer Relations
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: i2c-mpc.c driver issues
On 10/24/07, Tjernlund [EMAIL PROTECTED] wrote: While browsing the i2c-mpc.c driver I noticed some things that look odd to me so I figured I report them. Could not find a maintainer in the MAINTANERS file so I sent here, cc:ed linuxppc-dev as well. There appear to be more issues with this driver. It is still registering as platform driver instead of a of_platform driver. On the mpc5200 the probe function for platform drivers is not getting called, so fsl_i2c_probe never gets called. It's not clear to me that this driver is functioning on the mpc5200. 1) There are a lot of return -1 error code that is propagated back to userspace. Should be changed to proper -Exxx codes. 2) mpc_read(), according to the comment below it sends a STOP condition here but this function does not known if this is the last read or not. mpc_xfer is the one that knows when the transaction is over and should send the stop, which it already does. /* Generate stop on last byte */ if (i == length - 1) writeccr(i2c, CCR_MIEN | CCR_MEN | CCR_TXAK); Jocke ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev -- Jon Smirl [EMAIL PROTECTED] ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Ocotea board?
Well, I suppose that it was really just a little poke to see if anyone from AMCC reads the mailing list :) No offense intended. The 440GX worked out great for my project, a new spectrometer for the radio telescope in Arecibo. There are 14 of these boxes running in parallel at the telescope. We got good performance out of the 440GX in all respects with no major hangups during development. jeff Charlie Ashton wrote: The AMCC 440GX processor is by no means obsolete. There are more customers for this processor every month. There is a new, comprehensive evaluation kit called Taishan (http://www.amcc.com/Embedded/evalkits/440GX_PB_1_04.pdf), which AMCC provides to customers and partners. Ocotea is a board that was originally designed and used for processor validation purposes. Regards, Charlie -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jeff Mock Sent: Wednesday, October 24, 2007 12:10 PM To: linuxppc-dev@ozlabs.org; [EMAIL PROTECTED] Subject: Re: Ocotea board? Thanks for all of the replies, it's nice to hear that the 440GX isn't obsolete yet... A relatively arbitrary decision, but I'm going to send the Ocotea board to Josh. jeff Jeff Mock wrote: Is the Ocotea board (the original 440GX eval board) still interesting? I'm wrapping up a project using the 440GX, I started out hacking on the Ocotea board to get started, but we moved off Ocotea long ago onto our own hardware. I'm cleaning up the lab now that the project is nearly finished and I would like to give the board to someone that will put it to good use. I've sponged off this mailing list quite a lot, it's about time I give a little something back. The board has been hacked a little bit but still works fine. I just powered it up and it happily booted Linux via TFTP. The boot ROM now has u-boot, the original PIBs (or whatever) is long gone. All I ask is that you're self-sufficient and don't bug me too much about it... Can someone recommend a good home? Otherwise it will wind up in storeroom purgatory. jeff ___ Linuxppc-embedded mailing list [EMAIL PROTECTED] https://ozlabs.org/mailman/listinfo/linuxppc-embedded ___ Linuxppc-embedded mailing list [EMAIL PROTECTED] https://ozlabs.org/mailman/listinfo/linuxppc-embedded CONFIDENTIALITY NOTICE: This e-mail message, including any attachments, is for the sole use of the intended recipient(s) and contains information that is confidential and proprietary to Applied Micro Circuits Corporation or its subsidiaries. It is to be used solely for the purpose of furthering the parties' business relationship. All unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] taskstats scaled time cleanup
On Wed, 24 Oct 2007 16:54:57 +1000
Michael Neuling [EMAIL PROTECTED] wrote:
+/* Estimate the scaled cputime by scaling the real cputime based on
+ * the last scaled to real ratio */
+static inline cputime_t cputime_to_scaled(const cputime_t ct)
+{
+ if (cpu_has_feature(CPU_FTR_SPURR)
+ per_cpu(cputime_last_delta, smp_processor_id()))
+ return ct *
+ per_cpu(cputime_scaled_last_delta, smp_processor_id())/
+ per_cpu(cputime_last_delta, smp_processor_id());
+ return ct;
+}
This looks far too large to be inlined.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Audio codec device tree entries
On Wed, Oct 24, 2007 at 09:28:42AM -0600, Grant Likely wrote: On 10/24/07, Timur Tabi [EMAIL PROTECTED] wrote: Jon Smirl wrote: [snip] My vote is for this version. In fact, I think it *has* to be this way. If you're using a CS4270 codec (as I am), the I2C interface is *optional*. So I want the I2S node to point to the I2C node if it exists. It doesn't have to be this way. If the codec does not have a control interface, then it can happily be a child of the i2s node. But if it *does*; don't break convention by separating it from it's control interface. I strongly recommend following the lead of ethernet phys and mdio busses here. Yes. Devices should appear on the bus from which they're addressable, that is from the control interface in this case. Sometimes different things need to be done for bus-bridges which are configured from a different bus than the one they bridge, but this is not such a situation. -- David Gibson| I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_ | _way_ _around_! http://www.ozlabs.org/~dgibson ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Audio codec device tree entries
On Wed, Oct 24, 2007 at 11:54:23AM -0400, Jon Smirl wrote:
On 10/24/07, Grant Likely [EMAIL PROTECTED] wrote:
Do you want to pick one and add it to the device tree documentation
with an example for i2s and ac97? I'll use which ever one is picked.
Sure, I'll draft something up and post it for review.
On the device probing front; what about this method:
Rather than trying to figure things out from the board model, or the
combination of the codec and i2s bus; add another node to represent
the sound circuit. All that node would need is a unique compatible
property and a phandle to either the i2s bus or the codec (depending
on which binding approach is used). It could have additional
properties to represent optional features, etc.
That's the pseudo-sound node proposal that other people objected to.
It makes sense to me, there needs to be some way to trigger loading
the fabric driver.
For example:
[EMAIL PROTECTED] {
compatible = mfg,board,sound // The board might have
more than one sound i/f which could be wired differently
codec-handle = codec0;
};
Do you even need the parameters, how about simply this?
sound-fabric {
};
That will trigger loading all of the sound-fabric drivers built into
the kernel. In their probe functions they can look in the device tree
and extract the machine name and then decide to stay loaded or fail
the probe.
We shouldn't be basing driver configuration on the machine name unless
we really have to. We should be able to find a sane way to encode the
necessary information in the tree proper.
--
David Gibson| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Audio codec device tree entries
On Wed, Oct 24, 2007 at 10:38:11AM -0600, Grant Likely wrote:
On 10/24/07, Jon Smirl [EMAIL PROTECTED] wrote:
On 10/24/07, Grant Likely [EMAIL PROTECTED] wrote:
[snip]
For example:
[EMAIL PROTECTED] {
compatible = mfg,board,sound // The board might have
more than one sound i/f which could be wired differently
codec-handle = codec0;
};
The difference here is that the node provides real information about
the board. It has a compatible field which tells you *exactly* what
sound circuit is present on the board. It can have additional
information that does make sense to encode into the device tree (ie.
the codec that is used). It's not addressable (no registers or
anything), but it does describe the board.
It would be possible and reasonable for a single fabric driver to work
with many different circuit layouts as long as it has the information
needed to adapt each instance.
This still seems nasty, since it seems to do little but duplicate the
platform information.
I'm afraid I still don't understand quite what information this
fabric driver is conveying. Is it really inherently platform
specific, or is it something that can be encoded directly in a
sensible way. If the latter we could have a general device tree
fabric driver that will handle all systems with the layout correctly
encoded in the device tree.
--
David Gibson| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Audio codec device tree entries
On Wed, Oct 24, 2007 at 11:19:33AM -0400, Jon Smirl wrote:
On 10/24/07, Grant Likely [EMAIL PROTECTED] wrote:
On 10/24/07, Timur Tabi [EMAIL PROTECTED] wrote:
codec0: [EMAIL PROTECTED] {
compatible = ti,tas5508;
reg = 0;
i2s-handle = [EMAIL PROTECTED];
};
I'd do this the other way around -- that is:
[EMAIL PROTECTED] { // PSC2
compatible = fsl,mpc5200b-psc-i2s,fsl,mpc5200-psc-i2s;
...
i2c-handle = codec0; /* Or something like that */
i2c-handle is a poor property name here. It should be 'codec-handle'.
The codec could theoretically live on just about *any* control bus;
not just i2c.
That's one of the reasons I put the second option in the post.
In the second option the i2s driver would instantiate first. Next the
generic code would get loaded. The generic codec will know the control
but for the device and it can go look in the i2c node for the address.
i2c node still lists all of the devices on the i2c bus. But the codecs
are in the i2c-handle property so they don't trigger a second loading
of the codec.
A fundamental question is, which bus should trigger the loading of the
generic codec driver. The answer to this determines how the device
tree should look.
No! Device tree layout should not be determined by the instantiation
model used by Linux drivers right now.
--
David Gibson| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH v2 3/4] Implement clockevents driver for powerpc
Sergei Shtylyov writes: I've just realized that I've missed the call to account_process_time() in the new timer_interrupt(). :- Which is bogus. I had removed it in the version of the patch that I posted in early September, but apparently it crept back in. Anyway, this leads to each tick being accounted twice if the deterministic accounting is not enabled -- first by timer_interrupt() and then by the hrtimers core, doesn't it? Yep. Actually, I thought I was told that with CFS, the total process time was accounted accurately using sched_clock(), then apportioned between utime and stime (using counts of ticks in user/system state, which are somewhat inaccurate). At the time I thought that would be OK, but now I'm not so sure. Paul. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Audio codec device tree entries
On 10/24/07, David Gibson [EMAIL PROTECTED] wrote: I'm afraid I still don't understand quite what information this fabric driver is conveying. Is it really inherently platform specific, or is it something that can be encoded directly in a sensible way. If the latter we could have a general device tree fabric driver that will handle all systems with the layout correctly encoded in the device tree. Codecs are like GPIOs, all of their pins are programmable. So the same codec can be wired into various boards quite differently and then software programmed to work the same. The fabric driver contains the mapping information. People were making a codec driver for each board, but this resulted in lots of similar codec drivers for the same chips. I believe a common Wolfson chip had eight drivers in the kernel. In the new model the codec drivers are generic and the fabric driver describes the mapping. A side effect of this is that we need to load the fabric driver which doesn't have a device associated with it. This is a complex mapping from a STAC9277 used with an Intel hda chip. Codec: SigmaTel STAC9227 Address: 2 Vendor Id: 0x83847618 Subsystem Id: 0x102801db Revision Id: 0x100201 No Modem Function Group found Default PCM: rates [0x7e0]: 44100 48000 88200 96000 176400 192000 bits [0xe]: 16 20 24 formats [0x1]: PCM Default Amp-In caps: ofs=0x00, nsteps=0x0e, stepsize=0x05, mute=0 Default Amp-Out caps: ofs=0x7f, nsteps=0x7f, stepsize=0x02, mute=1 Node 0x02 [Audio Output] wcaps 0xd0c05: Stereo Amp-Out Amp-Out caps: N/A Amp-Out vals: [0x62 0x62] Power: 0x0 Node 0x03 [Audio Output] wcaps 0xd0c05: Stereo Amp-Out Amp-Out caps: N/A Amp-Out vals: [0xe4 0xe4] Power: 0x0 Node 0x04 [Audio Output] wcaps 0xd0c05: Stereo Amp-Out Amp-Out caps: N/A Amp-Out vals: [0x62 0x62] Power: 0x0 Node 0x05 [Audio Output] wcaps 0xd0c05: Stereo Amp-Out Amp-Out caps: N/A Amp-Out vals: [0xe4 0xe4] Power: 0x0 Node 0x06 [Vendor Defined Widget] wcaps 0xfd0c05: Stereo Amp-Out Amp-Out caps: N/A Amp-Out vals: [0xff 0xff] Power: 0x0 Node 0x07 [Audio Input] wcaps 0x1d0541: Stereo Power: 0x0 Connection: 1 0x1b Node 0x08 [Audio Input] wcaps 0x1d0541: Stereo Power: 0x0 Connection: 1 0x1c Node 0x09 [Audio Input] wcaps 0x1d0541: Stereo Power: 0x0 Connection: 1 0x1d Node 0x0a [Pin Complex] wcaps 0x400181: Stereo Pincap 0x08173f: IN OUT HP Detect Pin Default 0x0221101f: [Jack] HP Out at Ext Front Conn = 1/8, Color = Black Pin-ctls: 0xc0: OUT HP Connection: 2 0x02* 0x03 Node 0x0b [Pin Complex] wcaps 0x400181: Stereo Pincap 0x08173f: IN OUT HP Detect Pin Default 0x02a11020: [Jack] Mic at Ext Front Conn = 1/8, Color = Black Pin-ctls: 0x24: IN Connection: 2 0x02* 0x03 Node 0x0c [Pin Complex] wcaps 0x400181: Stereo Pincap 0x081737: IN OUT Detect Pin Default 0x01a19021: [Jack] Mic at Ext Rear Conn = 1/8, Color = Pink Pin-ctls: 0x24: IN Connection: 1 0x03 Node 0x0d [Pin Complex] wcaps 0x400181: Stereo Pincap 0x08173f: IN OUT HP Detect Pin Default 0x01014010: [Jack] Line Out at Ext Rear Conn = 1/8, Color = Green Pin-ctls: 0x40: OUT Connection: 1 0x02 Node 0x0e [Pin Complex] wcaps 0x400181: Stereo Pincap 0x081737: IN OUT Detect Pin Default 0x01011012: [Jack] Line Out at Ext Rear Conn = 1/8, Color = Black Pin-ctls: 0x40: OUT Connection: 1 0x04 Node 0x0f [Pin Complex] wcaps 0x400181: Stereo Pincap 0x081737: IN OUT Detect Pin Default 0x01016011: [Jack] Line Out at Ext Rear Conn = 1/8, Color = Orange Pin-ctls: 0x40: OUT Connection: 1 0x05 Node 0x10 [Pin Complex] wcaps 0x400181: Stereo Pincap 0x0837: IN OUT Detect Pin Default 0x0181302e: [Jack] Line In at Ext Rear Conn = 1/8, Color = Blue Pin-ctls: 0x20: IN Connection: 1 0x04 Node 0x11 [Pin Complex] wcaps 0x400181: Stereo Pincap 0x0837: IN OUT Detect Pin Default 0x01012014: [Jack] Line Out at Ext Rear Conn = 1/8, Color = Grey Pin-ctls: 0x40: OUT Connection: 1 0x03 Node 0x12 [Pin Complex] wcaps 0x41: Stereo Pincap 0x0820: IN Pin Default 0x40f000f1: [N/A] Other at Ext N/A Conn = Unknown, Color = Unknown Pin-ctls: 0x00: Node 0x13 [Vendor Defined Widget] wcaps 0xf1: Stereo Node 0x14 [Vendor Defined Widget] wcaps 0xf1: Stereo Node 0x15 [Audio Selector] wcaps 0x30010d: Stereo Amp-Out Amp-Out caps: ofs=0x00, nsteps=0x04, stepsize=0x27, mute=0 Amp-Out vals: [0x00 0x00] Connection: 9 0x0e 0x12 0x0f 0x0b 0x0c* 0x0d 0x0a 0x10 0x11 Node 0x16 [Audio Selector] wcaps 0x30010d: Stereo Amp-Out Amp-Out caps: ofs=0x00, nsteps=0x04, stepsize=0x27, mute=0 Amp-Out vals: [0x00 0x00] Connection: 9 0x0e 0x12 0x0f 0x0b 0x0c* 0x0d 0x0a 0x10 0x11 Node 0x17 [Audio Selector] wcaps 0x30010d: Stereo Amp-Out Amp-Out caps: ofs=0x00, nsteps=0x04, stepsize=0x27, mute=0 Amp-Out vals: [0x00 0x00] Connection: 9 0x0e 0x12 0x0f 0x0b 0x0c* 0x0d 0x0a 0x10 0x11 Node 0x18 [Audio Selector]
Re: New time code miscalculates cpu usage
Benjamin Herrenschmidt writes: Your input would be much more valuable if you actually pointed out where that happens and why since you seem to know it. He did already, a couple of messages ago. Paul. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Audio codec device tree entries
On Wed, Oct 24, 2007 at 08:17:57PM -0400, Jon Smirl wrote:
On 10/24/07, David Gibson [EMAIL PROTECTED] wrote:
I'm afraid I still don't understand quite what information this
fabric driver is conveying. Is it really inherently platform
specific, or is it something that can be encoded directly in a
sensible way. If the latter we could have a general device tree
fabric driver that will handle all systems with the layout correctly
encoded in the device tree.
Codecs are like GPIOs, all of their pins are programmable. So the same
codec can be wired into various boards quite differently and then
software programmed to work the same. The fabric driver contains the
mapping information.
People were making a codec driver for each board, but this resulted in
lots of similar codec drivers for the same chips. I believe a common
Wolfson chip had eight drivers in the kernel. In the new model the
codec drivers are generic and the fabric driver describes the mapping.
Ok, but the fabric driver is about the wiring of a specific codec
chip, yes? If a board was foolishly designed to have two identical
codec chips, but each wired differently, it would need two instances
of the same codec driver, plus one instance each of two different
fabric drivers?
If this is so, then the fabric information *must* be per-codec, and
should therefore go with the codec node.
A side effect of this is that we need to load the fabric driver which
doesn't have a device associated with it.
Well, it does have a device associated with it, it's just a question
of how to represent it. There's not reason a single device node can't
cause instantiation of multiple driver instances. Depending on the
complexity of typical fabric arrangements, one of the following
options might make sense:
- the device node's compatible has enough information to
specify both fabric and codec driver. The fabric driver is
instantiated from this node, and instantiates the codec driver itself
(since I gather fabric drivers are frequently codec specific in any
case).
- both fabric and codec drivers are instantiated from the same
device node, and co-ordinate with each other.
- The codec is represented as:
[EMAIL PROTECTED] {
compatible = ...;
properties describing the fabric
codec {
compatible = ...;
properties describing the codec
}
}
This is different from a pseudo node, because the codec-fabric node
represents a real piece of hardware: specifically the cluster of
wires between the sound bus and the codec.
Remember: the device tree describes the hardware, how the chooses to
structure its driver model to meet the demands of that hardware is up
to it. Don't put the cart before the horse.
--
David Gibson| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 1/2] mpc52xx: add cdm (clock module) helper function for PSCs
On Wed, 24 Oct 2007 12:24:26 -0600 Grant Likely [EMAIL PROTECTED] wrote: +static spinlock_t mpc52xx_cdm_lock = SPIN_LOCK_UNLOCKED; static DEFINE_SPINLOCK(mpc52xx_cdm_lock); -- Cheers, Stephen Rothwell[EMAIL PROTECTED] http://www.canb.auug.org.au/~sfr/ pgpgXWtYRBJgy.pgp Description: PGP signature ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: New time code miscalculates cpu usage
On Thu, 2007-10-25 at 10:19 +1000, Paul Mackerras wrote: Benjamin Herrenschmidt writes: Your input would be much more valuable if you actually pointed out where that happens and why since you seem to know it. He did already, a couple of messages ago. Allright, I missed that. Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
libfdt: Documentation (patch the second)
Add documentation for another handful of libfdt functions to libfdt.h Signed-off-by: David Gibson [EMAIL PROTECTED] Index: dtc/libfdt/libfdt.h === --- dtc.orig/libfdt/libfdt.h2007-10-25 10:52:31.0 +1000 +++ dtc/libfdt/libfdt.h 2007-10-25 11:26:26.0 +1000 @@ -237,13 +237,91 @@ */ int fdt_get_mem_rsv(const void *fdt, int n, uint64_t *address, uint64_t *size); +/** + * fdt_subnode_offset_namelen - find a subnode based on substring + * @fdt: pointer to the device tree blob + * @parentoffset: structure block offset of a node + * @name: name of the subnode to locate + * @namelen: number of characters of name to consider + * + * Identical to fdt_subnode_offset(), but only examine the first + * namelen characters of name for matching the subnode name. This is + * useful for finding subnodes based on a portion of a larger string, + * such as a full path. + */ int fdt_subnode_offset_namelen(const void *fdt, int parentoffset, const char *name, int namelen); +/** + * fdt_subnode_offset - find a subnode of a given node + * @fdt: pointer to the device tree blob + * @parentoffset: structure block offset of a node + * @name: name of the subnode to locate + * + * fdt_subnode_offset() finds a subnode of the node at structure block + * offset parentoffset with the given name. name may include a unit + * address, in which case fdt_subnode_offset() will find the subnode + * with that unit address, or the unit address may be omitted, in + * which case fdt_subnode_offset() will find an arbitrary subnode + * whose name excluding unit address matches the given name. + * + * returns: + * structure block offset of the requested subnode (=0), on success + * -FDT_ERR_NOTFOUND, if the requested subnode does not exist + * -FDT_ERR_BADOFFSET, if parentoffset did not point to an FDT_BEGIN_NODE tag + * -FDT_ERR_BADMAGIC, + * -FDT_ERR_BADVERSION, + * -FDT_ERR_BADSTATE, + * -FDT_ERR_BADSTRUCTURE, + * -FDT_ERR_TRUNCATED, standard meanings. + */ int fdt_subnode_offset(const void *fdt, int parentoffset, const char *name); +/** + * fdt_path_offset - find a tree node by its full path + * @fdt: pointer to the device tree blob + * @path: full path of the node to locate + * + * fdt_path_offset() finds a node of a given path in the device tree. + * Each path component may omit the unit address portion, but the + * results of this are undefined if any such path component is + * ambiguous (that is if there are multiple nodes at the relevant + * level matching the given component, differentiated only by unit + * address). + * + * returns: + * structure block offset of the node with the requested path (=0), on success + * -FDT_ERR_BADPATH, given path does not begin with '/' or is invalid + * -FDT_ERR_NOTFOUND, if the requested node does not exist + * -FDT_ERR_BADMAGIC, + * -FDT_ERR_BADVERSION, + * -FDT_ERR_BADSTATE, + * -FDT_ERR_BADSTRUCTURE, + * -FDT_ERR_TRUNCATED, standard meanings. + */ int fdt_path_offset(const void *fdt, const char *path); -const char *fdt_get_name(const void *fdt, int nodeoffset, int *baselen); +/** + * fdt_get_name - retreive the name of a given node + * @fdt: pointer to the device tree blob + * @nodeoffset: structure block offset of the starting node + * @len: pointer to an intger variable (will be overwritten) or NULL + * + * fdt_get_name() retrieves the name (including unit address) of the + * device tree node at structure block offset nodeoffset. If len is + * non-NULL, the length of this name is also returned, in the integer + * pointed to by len. + * + * returns: + * pointer to the node's name, on success + * *len contains the length of that name (=0) + * NULL, on error + * *len contains an error code (0): + * -FDT_ERR_BADOFFSET, nodeoffset did not point to FDT_BEGIN_NODE tag + * -FDT_ERR_BADMAGIC, + * -FDT_ERR_BADVERSION, + * -FDT_ERR_BADSTATE, standard meanings + */ +const char *fdt_get_name(const void *fdt, int nodeoffset, int *len); const struct fdt_property *fdt_get_property(const void *fdt, int nodeoffset, const char *name, int *lenp); -- David Gibson| I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_ | _way_ _around_! http://www.ozlabs.org/~dgibson ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] Use of_get_parent() in pci_dma_dev_setup_pSeriesLP()
On Wed, 2007-10-24 at 14:24 +1000, Michael Ellerman wrote: The loop to check parent nodes for a dma-window property in pci_dma_dev_setup_pSeriesLP() does not use the of_* accessors and does not properly manage refcounts, fix it to do so. Signed-off-by: Michael Ellerman [EMAIL PROTECTED] --- arch/powerpc/platforms/pseries/iommu.c | 17 - 1 files changed, 12 insertions(+), 5 deletions(-) I'm starting to make a habit of this .. but nack. Stephen points out that there are several other places in this file that need fixing up, so I'll do them all as one series. cheers -- Michael Ellerman OzLabs, IBM Australia Development Lab wwweb: http://michael.ellerman.id.au phone: +61 2 6212 1183 (tie line 70 21183) We do not inherit the earth from our ancestors, we borrow it from our children. - S.M.A.R.T Person signature.asc Description: This is a digitally signed message part ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [linux-usb-devel] [PATCH 1/2] USB: Rework OHCI PPC OF for new bindings
On Wednesday 24 October 2007, Matt Sealey wrote: Can we just make sure real quickly that the changing of compatibles doesn't break existing, not-easily-flashable firmwares? Yeah, I'm not keen on such breakage either... ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [linux-usb-devel] [PATCH 1/2] USB: Rework OHCI PPC OF for new bindings
On 10/24/07, David Brownell [EMAIL PROTECTED] wrote: On Wednesday 24 October 2007, Matt Sealey wrote: Can we just make sure real quickly that the changing of compatibles doesn't break existing, not-easily-flashable firmwares? Yeah, I'm not keen on such breakage either... Add my voice to the chorus. It's okay to change the binding, but make sure the old binding is still supported. Cheers, g. -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. [EMAIL PROTECTED] (403) 399-0195 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Audio codec device tree entries
On 10/24/07, David Gibson [EMAIL PROTECTED] wrote:
On Wed, Oct 24, 2007 at 08:17:57PM -0400, Jon Smirl wrote:
On 10/24/07, David Gibson [EMAIL PROTECTED] wrote:
I'm afraid I still don't understand quite what information this
fabric driver is conveying. Is it really inherently platform
specific, or is it something that can be encoded directly in a
sensible way. If the latter we could have a general device tree
fabric driver that will handle all systems with the layout correctly
encoded in the device tree.
Codecs are like GPIOs, all of their pins are programmable. So the same
codec can be wired into various boards quite differently and then
software programmed to work the same. The fabric driver contains the
mapping information.
People were making a codec driver for each board, but this resulted in
lots of similar codec drivers for the same chips. I believe a common
Wolfson chip had eight drivers in the kernel. In the new model the
codec drivers are generic and the fabric driver describes the mapping.
Ok, but the fabric driver is about the wiring of a specific codec
chip, yes? If a board was foolishly designed to have two identical
codec chips, but each wired differently, it would need two instances
of the same codec driver, plus one instance each of two different
fabric drivers?
AFAIK no one has built that case. My target board has two different
codec chips. I was handling them both in a single fabric driver but
there is no reason the code couldn't be split.
I was thinking that there was a single fabric for the board, but you
are right in observing that it is per codec chip.
The term fabric is coming from the Apple aoa driver. They only have a
single fabric per board. But there is no reason the Apple driver
couldn't also be adjusted.
If this is so, then the fabric information *must* be per-codec, and
should therefore go with the codec node.
A side effect of this is that we need to load the fabric driver which
doesn't have a device associated with it.
Well, it does have a device associated with it, it's just a question
of how to represent it. There's not reason a single device node can't
cause instantiation of multiple driver instances. Depending on the
complexity of typical fabric arrangements, one of the following
options might make sense:
- the device node's compatible has enough information to
specify both fabric and codec driver. The fabric driver is
instantiated from this node, and instantiates the codec driver itself
(since I gather fabric drivers are frequently codec specific in any
case).
This could work. The generic codec is a alsa soc_device_driver, not a
of_device_driver. The codec node could instantiate the fabric as a
of_device_driver which could then instantiate the soc_device_driver
for the generic codec.
The generic codecs are supposed to work cross platform so they can't
include code that munges the of device tree.
- both fabric and codec drivers are instantiated from the same
device node, and co-ordinate with each other.
- The codec is represented as:
[EMAIL PROTECTED] {
compatible = ...;
properties describing the fabric
codec {
compatible = ...;
properties describing the codec
}
}
This is different from a pseudo node, because the codec-fabric node
represents a real piece of hardware: specifically the cluster of
wires between the sound bus and the codec.
Remember: the device tree describes the hardware, how the chooses to
structure its driver model to meet the demands of that hardware is up
to it. Don't put the cart before the horse.
--
David Gibson| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
--
Jon Smirl
[EMAIL PROTECTED]
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
libfdt: Remove un-const-safe fdt_set_header macro
The fdt_set_header() macro casts an arbitrary pointer into (struct
fdt_header *) to set fdt header fields. While we need to change the
type, so that we can use this macro on the usual (void *) used to
represent a device tree blob, the current macro also casts away any
const on the input pointer, which loses an important check.
This patch replaces the fdt_set_header() macro with a set of inline
functions, one for each header field which do a similar thing, but
which won't silently remove const from a given pointer. This approach
is also more in keeping with the individual accessor macros we use for
reading fdt header fields.
Signed-off-by: David Gibson [EMAIL PROTECTED]
Index: dtc/libfdt/libfdt.h
===
--- dtc.orig/libfdt/libfdt.h2007-10-25 14:15:30.0 +1000
+++ dtc/libfdt/libfdt.h 2007-10-25 14:25:07.0 +1000
@@ -149,8 +149,23 @@
#define fdt_size_dt_strings(fdt) (fdt_get_header(fdt, size_dt_strings))
#define fdt_size_dt_struct(fdt)(fdt_get_header(fdt,
size_dt_struct))
-#define fdt_set_header(fdt, field, val) \
- ((struct fdt_header *)(fdt))-field = cpu_to_fdt32(val)
+#define __fdt_set_hdr(name) \
+ static inline void fdt_set_##name(void *fdt, uint32_t val) \
+ { \
+ struct fdt_header *fdth = fdt; \
+ fdth-name = cpu_to_fdt32(val); \
+ }
+__fdt_set_hdr(magic);
+__fdt_set_hdr(totalsize);
+__fdt_set_hdr(off_dt_struct);
+__fdt_set_hdr(off_dt_strings);
+__fdt_set_hdr(off_mem_rsvmap);
+__fdt_set_hdr(version);
+__fdt_set_hdr(last_comp_version);
+__fdt_set_hdr(boot_cpuid_phys);
+__fdt_set_hdr(size_dt_strings);
+__fdt_set_hdr(size_dt_struct);
+#undef __fdt_set_hdr
/**
* fdt_check_header - sanity check a device tree or possible device tree
Index: dtc/libfdt/fdt_rw.c
===
--- dtc.orig/libfdt/fdt_rw.c2007-10-25 14:15:30.0 +1000
+++ dtc/libfdt/fdt_rw.c 2007-10-25 14:24:09.0 +1000
@@ -109,8 +109,8 @@
err = _blob_splice(fdt, p, oldn * sizeof(*p), newn * sizeof(*p));
if (err)
return err;
- fdt_set_header(fdt, off_dt_struct, fdt_off_dt_struct(fdt) + delta);
- fdt_set_header(fdt, off_dt_strings, fdt_off_dt_strings(fdt) + delta);
+ fdt_set_off_dt_struct(fdt, fdt_off_dt_struct(fdt) + delta);
+ fdt_set_off_dt_strings(fdt, fdt_off_dt_strings(fdt) + delta);
return 0;
}
@@ -123,8 +123,8 @@
if ((err = _blob_splice(fdt, p, oldlen, newlen)))
return err;
- fdt_set_header(fdt, size_dt_struct, fdt_size_dt_struct(fdt) + delta);
- fdt_set_header(fdt, off_dt_strings, fdt_off_dt_strings(fdt) + delta);
+ fdt_set_size_dt_struct(fdt, fdt_size_dt_struct(fdt) + delta);
+ fdt_set_off_dt_strings(fdt, fdt_off_dt_strings(fdt) + delta);
return 0;
}
@@ -136,7 +136,7 @@
if ((err = _blob_splice(fdt, p, 0, newlen)))
return err;
- fdt_set_header(fdt, size_dt_strings, fdt_size_dt_strings(fdt) + newlen);
+ fdt_set_size_dt_strings(fdt, fdt_size_dt_strings(fdt) + newlen);
return 0;
}
@@ -349,7 +349,7 @@
fdt = buf;
- fdt_set_header(fdt, totalsize, bufsize);
+ fdt_set_totalsize(fdt, bufsize);
/* FIXME: re-order if necessary */
@@ -369,6 +369,6 @@
return err;
/* FIXME: pack components */
- fdt_set_header(fdt, totalsize, _blob_data_size(fdt));
+ fdt_set_totalsize(fdt, _blob_data_size(fdt));
return 0;
}
Index: dtc/libfdt/fdt_sw.c
===
--- dtc.orig/libfdt/fdt_sw.c2007-10-25 14:15:30.0 +1000
+++ dtc/libfdt/fdt_sw.c 2007-10-25 14:15:35.0 +1000
@@ -73,7 +73,7 @@
if ((offset + len offset) || (offset + len spaceleft))
return NULL;
- fdt_set_header(fdt, size_dt_struct, offset + len);
+ fdt_set_size_dt_struct(fdt, offset + len);
return fdt_offset_ptr_w(fdt, offset, len);
}
@@ -86,15 +86,15 @@
memset(buf, 0, bufsize);
- fdt_set_header(fdt, magic, SW_MAGIC);
- fdt_set_header(fdt, version, FDT_LAST_SUPPORTED_VERSION);
- fdt_set_header(fdt, last_comp_version, FDT_FIRST_SUPPORTED_VERSION);
- fdt_set_header(fdt, totalsize, bufsize);
-
- fdt_set_header(fdt, off_mem_rsvmap, ALIGN(sizeof(struct fdt_header),
- sizeof(struct
fdt_reserve_entry)));
- fdt_set_header(fdt, off_dt_struct, fdt_off_mem_rsvmap(fdt));
- fdt_set_header(fdt, off_dt_strings, bufsize);
+ fdt_set_magic(fdt, SW_MAGIC);
+ fdt_set_version(fdt, FDT_LAST_SUPPORTED_VERSION);
+ fdt_set_last_comp_version(fdt, FDT_FIRST_SUPPORTED_VERSION);
+ fdt_set_totalsize(fdt, bufsize);
+
+ fdt_set_off_mem_rsvmap(fdt, ALIGN(sizeof(struct fdt_header),
+
Re: [PATCH 01/11] [POWERPC] Add 'machine: ...' line to common show_cpuinfo()
On Wed Oct 24 17:11:29 EST 2007, Stephen Rothwell wrote: On Wed, 24 Oct 2007 01:13:09 +0200 Marian Balakowicz wrote: +root = of_find_node_by_path(/); +if (root) +model = of_get_property(root, model, NULL); +of_node_put(root); The paranoid part of me says: if (model) +seq_printf(m, machine\t\t: %s\n, model); My thoughts too (don't fail if no model property in /), and that means that +const char *model = ; can change to + const char *model = NULL; However, a quick grep shows there are several platforms that print out machine\t\t: something in show_cpuinfo. Some are fixed strings (eg linkstation, holly, iSeries), some print model with a fallback (powermac), some augment the model (chrp, pseries, cell), some print something else (52xx/efika). There are others. All of those need to be dealt with or another tag chosen. milton ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
libfdt: Test on trees with different block layouts
At present, all the example dtbs we use in the testsuite are version
17 and have reservation map, then structure block then strings block
(the natural ordering based on alignment constraints). However, all
libfdt's read-only and in-place write functions should also work on
v16 trees, and on trees with other layouts.
This patch adds a testcase / utility function to rearrange the blocks
of a dtb and/or regress a v17 tree to v16, and uses it to run tests on
trees with different layouts and versions.
Signed-off-by: David Gibson [EMAIL PROTECTED]
Index: dtc/tests/mangle-layout.c
===
--- /dev/null 1970-01-01 00:00:00.0 +
+++ dtc/tests/mangle-layout.c 2007-10-25 14:51:55.0 +1000
@@ -0,0 +1,166 @@
+/*
+ * libfdt - Flat Device Tree manipulation
+ * Testcase/tool for rearranging blocks of a dtb
+ * Copyright (C) 2006 David Gibson, IBM Corporation.
+ *
+ * This library is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public License
+ * as published by the Free Software Foundation; either version 2.1 of
+ * the License, or (at your option) any later version.
+ *
+ * This library is distributed in the hope that it will be useful, but
+ * WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with this library; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA
+ */
+
+#include stdlib.h
+#include stdio.h
+#include string.h
+#include limits.h
+#include stdint.h
+
+#include fdt.h
+#include libfdt.h
+
+#include tests.h
+#include testdata.h
+
+struct bufstate {
+ void *buf;
+ int size;
+};
+
+void expand_buf(struct bufstate *buf, int newsize)
+{
+ buf-buf = realloc(buf-buf, newsize);
+ if (!buf-buf)
+ CONFIG(Allocation failure);
+ buf-size = newsize;
+}
+
+void new_header(struct bufstate *buf, int version, const void *fdt)
+{
+ int hdrsize;
+
+ if (version == 16)
+ hdrsize = FDT_V16_SIZE;
+ else if (version == 17)
+ hdrsize = FDT_V17_SIZE;
+ else
+ CONFIG(Bad version %d, version);
+
+ expand_buf(buf, hdrsize);
+ memset(buf-buf, 0, hdrsize);
+
+ fdt_set_magic(buf-buf, FDT_MAGIC);
+ fdt_set_version(buf-buf, version);
+ fdt_set_last_comp_version(buf-buf, 16);
+ fdt_set_boot_cpuid_phys(buf-buf, fdt_boot_cpuid_phys(fdt));
+}
+
+void add_block(struct bufstate *buf, int version, char block, const void *fdt)
+{
+ int align, size;
+ const void *src;
+ int offset;
+
+ switch (block) {
+ case 'm':
+ /* Memory reserve map */
+ align = 8;
+ src = fdt + fdt_off_mem_rsvmap(fdt);
+ size = (fdt_num_mem_rsv(fdt) + 1)
+ * sizeof(struct fdt_reserve_entry);
+ break;
+
+ case 't':
+ /* Structure block */
+ align = 4;
+ src = fdt + fdt_off_dt_struct(fdt);
+ size = fdt_size_dt_struct(fdt);
+ break;
+
+ case 's':
+ /* Strings block */
+ align = 1;
+ src = fdt + fdt_off_dt_strings(fdt);
+ size = fdt_size_dt_strings(fdt);
+ break;
+ default:
+ CONFIG(Bad block '%c', block);
+ }
+
+ offset = ALIGN(buf-size, align);
+ fprintf(stderr, Moving block %c from %p, to offset %d, size %d\n,
+ block, src, offset, size);
+
+ expand_buf(buf, offset+size);
+
+ memcpy(buf-buf + offset, src, size);
+
+ switch (block) {
+ case 'm':
+ fdt_set_off_mem_rsvmap(buf-buf, offset);
+ break;
+
+ case 't':
+ fdt_set_off_dt_struct(buf-buf, offset);
+ if (version = 17)
+ fdt_set_size_dt_struct(buf-buf, size);
+ break;
+
+ case 's':
+ fdt_set_off_dt_strings(buf-buf, offset);
+ fdt_set_size_dt_strings(buf-buf, size);
+ break;
+ }
+}
+
+int main(int argc, char *argv[])
+{
+ void *fdt;
+ int version;
+ const char *blockorder;
+ struct bufstate buf = {NULL, 0};
+ int err;
+ const char *inname;
+ char outname[PATH_MAX];
+
+ test_init(argc, argv);
+ if (argc != 4)
+ CONFIG(Usage: %s dtb file version block order, argv[0]);
+
+ inname = argv[1];
+ fdt = load_blob(argv[1]);
+ version = atoi(argv[2]);
+ blockorder = argv[3];
+ sprintf(outname, v%d.%s.%s, version, blockorder, inname);
+
+ if ((version != 16) (version != 17))
+
