Re: [PATCH] Miscellaneous for Taco
On Saturday 05 January 2008, Benjamin Herrenschmidt wrote: diff --git a/drivers/usb/Kconfig b/drivers/usb/Kconfig index 7580aa5..480580c 100644 --- a/drivers/usb/Kconfig +++ b/drivers/usb/Kconfig @@ -39,6 +39,7 @@ config USB_ARCH_HAS_OHCI # PPC: default y if STB03xxx default y if PPC_MPC52xx + default y if TACO # MIPS: default y if SOC_AU1X00 # more: I think we should instead reference use the 440EP here, I vote for adding 440EP here. Best regards, Stefan ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] MTD for Taco
On Saturday 05 January 2008, Sean MacLennan wrote:
This patch adds the maps for the taco. It also gets the ndfc.c NAND
driver in a compilable state. The map is guaranteed to change since the
exact NOR/NAND flash configuration is in flux right now when we found
the 256M NAND flash won't boot properly.
Currently it configures the NOR in a reasonable fashion and leaves the
NAND as one honkin' parition.
snip
diff --git a/drivers/mtd/nand/ndfc.c b/drivers/mtd/nand/ndfc.c
index 1c0e89f..f5e93cf 100644
--- a/drivers/mtd/nand/ndfc.c
+++ b/drivers/mtd/nand/ndfc.c
@@ -24,11 +24,6 @@
#include linux/platform_device.h
#include asm/io.h
-#ifdef CONFIG_40x
-#include asm/ibm405.h
-#else
-#include asm/ibm44x.h
-#endif
You do break arch/ppc support with this patch. We have to still support
arch/ppc a few month, so please don't break this support for now.
struct ndfc_nand_mtd {
struct mtd_info mtd;
@@ -110,6 +105,40 @@ static int ndfc_calculate_ecc(struct mtd_info *mtd,
return 0;
}
+#ifdef CONFIG_TACO
+/* The NDFC may allow 32bit read/writes, but it sure doesn't work on
+ * the taco!
+ */
We definitely don't want to see such board specific stuff in the common
NDFC driver. And I really doubt that you need this change for your board.
We are using this ndfc driver on multiple boards, and all have no
problems accessing the controller with 32bit read/writes. So you most
likely have a problem with your board port. Perhaps something with
with the EBC setup. Please re-check and compare with boards that are know
to work, like Sequoia.
+static void ndfc_read_buf(struct mtd_info *mtd, uint8_t *buf, int len)
+{
+ struct ndfc_controller *ndfc = ndfc_ctrl;
+ uint8_t *p = (uint8_t *) buf;
+
+ for(;len 0; len -= 1)
+ *p++ = __raw_readb(ndfc-ndfcbase + NDFC_DATA);
+}
+
+static void ndfc_write_buf(struct mtd_info *mtd, const uint8_t *buf, int
len) +{
+ struct ndfc_controller *ndfc = ndfc_ctrl;
+ uint8_t *p = (uint8_t *) buf;
+
+ for(;len 0; len -= 1)
+ __raw_writeb(*p++, ndfc-ndfcbase + NDFC_DATA);
+}
+
+static int ndfc_verify_buf(struct mtd_info *mtd, const uint8_t *buf, int
len) +{
+ struct ndfc_controller *ndfc = ndfc_ctrl;
+ uint8_t *p = (uint8_t *) buf;
+
+ for(;len 0; len -= 1)
+ if (*p++ != __raw_readb(ndfc-ndfcbase + NDFC_DATA))
+ return -EFAULT;
+
+ return 0;
+}
+#else
snip
+++ drivers/mtd/maps/taco.c 2008-01-02 13:07:43.0 -0500
@@ -0,0 +1,140 @@
+/*
+ * $Id: $
+ *
+ * drivers/mtd/maps/taco.c
+ *
+ * Mapping for PIKA Taco flash
I'm pretty sure that you don't need a board specific mapping driver
for NOR flash. physmap_of should be exactly what you need. You just need
to fill the device tree properties correctly.
BTW: I noticed you are using the boot wrapper approach. This is not
necessary anymore, since the latest U-Boot version has flattened
device tree support included for 4xx too. Let me know if you have any
questions about this.
Best regards,
Stefan
=
DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: [EMAIL PROTECTED]
=
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] ibm_newemac: Increase number of default rx-/tx-buffers
Performance tests done by AMCC have shown that 256 buffer increase the performance of the Linux EMAC driver. So let's update the default values to match this setup. Signed-off-by: Stefan Roese [EMAIL PROTECTED] --- drivers/net/ibm_newemac/Kconfig |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/net/ibm_newemac/Kconfig b/drivers/net/ibm_newemac/Kconfig index 0d3e738..5a06727 100644 --- a/drivers/net/ibm_newemac/Kconfig +++ b/drivers/net/ibm_newemac/Kconfig @@ -9,12 +9,12 @@ config IBM_NEW_EMAC config IBM_NEW_EMAC_RXB int Number of receive buffers depends on IBM_NEW_EMAC - default 128 + default 256 config IBM_NEW_EMAC_TXB int Number of transmit buffers depends on IBM_NEW_EMAC - default 64 + default 256 config IBM_NEW_EMAC_POLL_WEIGHT int MAL NAPI polling weight -- 1.5.4.rc2 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH v2] [POWERPC] Provide a way to protect 4k subpages when using 64k pages
Using 64k pages on 64-bit PowerPC systems makes life difficult for
emulators that are trying to emulate an ISA, such as x86, which use a
smaller page size, since the emulator can no longer use the MMU and
the normal system calls for controlling page protections. Of course,
the emulator can emulate the MMU by checking and possibly remapping
the address for each memory access in software, but that is pretty
slow.
This provides a facility for such programs to control the access
permissions on individual 4k sub-pages of 64k pages. The idea is
that the emulator supplies an array of protection masks to apply to a
specified range of virtual addresses. These masks are applied at the
level where hardware PTEs are inserted into the hardware page table
based on the Linux PTEs, so the Linux PTEs are not affected. Note
that this new mechanism does not allow any access that would otherwise
be prohibited; it can only prohibit accesses that would otherwise be
allowed. This new facility is only available on 64-bit PowerPC and
only when the kernel is configured for 64k pages.
The masks are supplied using a new subpage_prot system call, which
takes a starting virtual address and length, and a pointer to an array
of protection masks in memory. The array has a 32-bit word per 64k
page to be protected; each 32-bit word consists of 16 2-bit fields,
for which 0 allows any access (that is otherwise allowed), 1 prevents
write accesses, and 2 or 3 prevent any access.
Implicit in this is that the regions of the address space that are
protected are switched to use 4k hardware pages rather than 64k
hardware pages (on machines with hardware 64k page support). In fact
the whole process is switched to use 4k hardware pages when the
subpage_prot system call is used, but this could be improved in future
to switch only the affected segments.
The subpage protection bits are stored in a 3 level tree akin to the
page table tree. The top level of this tree is stored in a structure
that is appended to the top level of the page table tree, i.e., the
pgd array. Since it will often only be 32-bit addresses (below 4GB)
that are protected, the pointers to the first four bottom level pages
are also stored in this structure (each bottom level page contains the
protection bits for 1GB of address space), so the protection bits for
addresses below 4GB can be accessed with one fewer loads than those
for higher addresses.
Signed-off-by: Paul Mackerras [EMAIL PROTECTED]
---
This version allocates a new system call number for the subpage_prot
syscall.
diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index 66a3d8c..53d0955 100644
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@ -342,6 +342,14 @@ config PPC_64K_PAGES
while on hardware with such support, it will be used to map
normal application pages.
+config PPC_SUBPAGE_PROT
+ bool Support setting protections for 4k subpages
+ depends on PPC_64K_PAGES
+ help
+ This option adds support for a system call to allow user programs
+ to set access permissions (read/write, readonly, or no access)
+ on the 4k subpages of each 64k page.
+
config SCHED_SMT
bool SMT (Hyperthreading) scheduler support
depends on PPC64 SMP
diff --git a/arch/powerpc/kernel/head_64.S b/arch/powerpc/kernel/head_64.S
index c349868..11b4f6d 100644
--- a/arch/powerpc/kernel/head_64.S
+++ b/arch/powerpc/kernel/head_64.S
@@ -903,6 +903,7 @@ handle_page_fault:
* the PTE insertion
*/
12:bl .save_nvgprs
+ mr r5,r3
addir3,r1,STACK_FRAME_OVERHEAD
ld r4,_DAR(r1)
bl .low_hash_fault
diff --git a/arch/powerpc/kernel/syscalls.c b/arch/powerpc/kernel/syscalls.c
index 3b1d5dd..18be22e 100644
--- a/arch/powerpc/kernel/syscalls.c
+++ b/arch/powerpc/kernel/syscalls.c
@@ -328,3 +328,7 @@ void do_show_syscall_exit(unsigned long r3)
{
printk( - %lx, current=%p cpu=%d\n, r3, current, smp_processor_id());
}
+
+#ifndef CONFIG_PPC_SUBPAGE_PROT
+cond_syscall(subpage_prot);
+#endif
diff --git a/arch/powerpc/mm/Makefile b/arch/powerpc/mm/Makefile
index 20629ae..41649a5 100644
--- a/arch/powerpc/mm/Makefile
+++ b/arch/powerpc/mm/Makefile
@@ -22,3 +22,4 @@ obj-$(CONFIG_FSL_BOOKE) += fsl_booke_mmu.o
obj-$(CONFIG_NEED_MULTIPLE_NODES) += numa.o
obj-$(CONFIG_PPC_MM_SLICES)+= slice.o
obj-$(CONFIG_HUGETLB_PAGE) += hugetlbpage.o
+obj-$(CONFIG_PPC_SUBPAGE_PROT) += subpage-prot.o
diff --git a/arch/powerpc/mm/hash_low_64.S b/arch/powerpc/mm/hash_low_64.S
index e935edd..21d2484 100644
--- a/arch/powerpc/mm/hash_low_64.S
+++ b/arch/powerpc/mm/hash_low_64.S
@@ -331,7 +331,8 @@ htab_pte_insert_failure:
*/
/* _hash_page_4K(unsigned long ea, unsigned long access, unsigned long vsid,
- * pte_t *ptep, unsigned long trap, int local, int ssize)
+ * pte_t *ptep, unsigned long trap,
Re: [PATCH 2/3] Look for include files in the directory of the including file.
On Thu, Jan 03, 2008 at 05:43:31PM -0600, Scott Wood wrote:
Looking in the diretory dtc is invoked from is not very useful behavior.
As part of the code reorganization to implement this, I removed the
uniquifying of name storage -- it seemed a rather dubious optimization
given likely usage, and some aspects of it would have been mildly awkward
to integrate with the new code.
Signed-off-by: Scott Wood [EMAIL PROTECTED]
Would have been kind of nice to see the two parts as separate
patches. But no big deal, again, I'd really like to see this in for
1.1.
Acked-by: David Gibson [EMAIL PROTECTED]
A few comments nonetheless:
[snip]
@@ -260,7 +259,19 @@ int push_input_file(const char *filename)
return 0;
}
- f = dtc_open_file(filename);
+ if (srcpos_file) {
+ search.dir = srcpos_file-dir;
+ search.next = NULL;
+ search.prev = NULL;
+ searchptr = search;
+ }
+
+ newfile = dtc_open_file(filename, searchptr);
+ if (!newfile) {
+ yyerrorf(Couldn't open \%s\: %s,
+ filename, strerror(errno));
+ exit(1);
Use die() here, that's what it's for.
+ }
incl_file = malloc(sizeof(struct incl_file));
if (!incl_file) {
And we should be using xmalloc() here (not your change, I realise).
[snip]
-FILE *dtc_open_file(const char *fname)
+static int dtc_open_one(struct dtc_file *file,
+const char *search,
+const char *fname)
{
- FILE *f;
-
- if (lookup_file_name(fname, 1) 0)
- die(Too many files opened\n);
-
- if (streq(fname, -))
- f = stdin;
- else
- f = fopen(fname, r);
+ char *fullname;
+
+ if (search) {
+ fullname = malloc(strlen(search) + strlen(fname) + 2);
+ if (!fullname)
+ die(Out of memory\n);
xmalloc() again (your fault, this time).
+ strcpy(fullname, search);
+ strcat(fullname, /);
+ strcat(fullname, fname);
+ } else {
+ fullname = strdup(fname);
+ }
- if (! f)
- die(Couldn't open \%s\: %s\n, fname, strerror(errno));
+ file-file = fopen(fullname, r);
+ if (!file-file) {
+ free(fullname);
+ return 0;
+ }
- return f;
+ file-name = fullname;
+ return 1;
}
-
-/*
- * Locate and optionally add filename fname in the file_names[] array.
- *
- * If the filename is currently not in the array and the boolean
- * add_it is non-zero, an attempt to add the filename will be made.
- *
- * Returns;
- *Index [0..MAX_N_FILE_NAMES) where the filename is kept
- *-1 if the name can not be recorded
- */
-
-int lookup_file_name(const char *fname, int add_it)
+struct dtc_file *dtc_open_file(const char *fname,
+ const struct search_path *search)
{
- int i;
-
- for (i = 0; i n_file_names; i++) {
- if (strcmp(file_names[i], fname) == 0)
- return i;
+ static const struct search_path default_search = { NULL, NULL, NULL };
+
+ struct dtc_file *file;
+ const char *slash;
+
+ file = malloc(sizeof(struct dtc_file));
+ if (!file)
+ die(Out of memory\n);
xmalloc() again.
+ slash = strrchr(fname, '/');
+ if (slash) {
+ char *dir = malloc(slash - fname + 1);
+ if (!dir)
+ die(Out of memory\n);
And again.
+ memcpy(dir, fname, slash - fname);
+ dir[slash - fname] = 0;
+ file-dir = dir;
+ } else {
+ file-dir = NULL;
}
- if (add_it) {
- if (n_file_names MAX_N_FILE_NAMES) {
- file_names[n_file_names] = strdup(fname);
- return n_file_names++;
- }
+ if (streq(fname, -)) {
+ file-name = stdin;
+ file-file = stdin;
+ return file;
}
- return -1;
-}
+ if (!search)
+ search = default_search;
+ while (search) {
+ if (dtc_open_one(file, search-dir, fname))
+ return file;
Don't we need a different case here somewhere for if someone specifies
an include file as an absolute path? Have I missed something?
[snip]
+struct search_path {
+ const char *dir; /* NULL for current directory */
+ struct search_path *prev, *next;
+};
I wouldn't suggest a doubly linked list here. Or at least not without
converting our many existing singly linked lists at the same time.
--
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
Re: [PATCH 1/3] Add yyerrorf() for formatted error messages.
On Thu, Jan 03, 2008 at 05:43:29PM -0600, Scott Wood wrote: Signed-off-by: Scott Wood [EMAIL PROTECTED] I don't really like adding any yy*() functions that aren't actually part of the fixed lex/yacc interface. But, despite that, let's merge this, and parth 2/3 because I think we should get in sane include searching for 1.1. I'll look at polishing the message printing stuff later. Acked-by: David Gibson [EMAIL PROTECTED] -- 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] ASoC drivers for the Freescale MPC8610 SoC
On Thu, Jan 03, 2008 at 09:54:45AM -0500, Jon Smirl wrote: On 1/2/08, David Gibson [EMAIL PROTECTED] wrote: [snip] Instantiating the fabric driver off any node is wrong, precisely because it is an abstraction. The fabric driver should be instantiated by the platform code. Instantiating it from the platform code forces me to put it either the of_platform_bus or the platform_bus since there aren't any other buses around when the platform code runs. Platform bus doesn't implement dynamic module loading. So that means it has to go onto the of_platform_bus. That implies that is it a pseudo-device without a pseudo-device entry in the device tree which is fine with me. I'll need to poke around in the of_bus code and see if the driver will load without a device tree entry. You're letting implementation warts influence basic design decisions. This is not sensible. Step back and think for a moment, work out a sane organization *then* think how you might need to fix or workaround limitations of existing infrastructure. A simple fix to this would be to let me instantiate the driver off from the root node of the tree. That's the conceptually correct place for instantiating a driver that extends the platform code. Should I try adjusting the of probing code to pass the node in, or are there major objections? The current probing system can't instantiate a device for the root node in any sane way, since it takes a list of suitable busses. The constructor based approach we're looking at implementing could do it. It should, in any case, be constructing a platform_device - so the platform bus code would still need to be extended to handle the module loading. Creating it as an of_platform device bound to the root node might be a workable interim solution though. of_platform_device simply does not *ever* make sense conceptually: the type of struct device wrapper in use depends on the bus the device is attached to, not on how we figured out the device was there. OF can potentially give information about any sort of device be it simple-bus, i2c, PCI or whatever connected. Also, as others have pointed out, this driver is not an abstraction. It represents the mess of wires hooking the codec up to the jacks on the back panel and possibly GPIO pins that control the wiring. You need this because the pins on HD audio codecs are completely reconfigurable and the same chip can be wired in a thousand different ways. It lets you have a generic codec driver and the move the platform specific code out of the driver. Well, abstraction is maybe not the right word. But the point is that the fabric driver doesn't represent a neatly isolated device with well defined bus connections. Instead it represents the tangle of essentially every link between audio devices in the platform. About the clearest possible example of a true platform device (as opposed to a device on some bus that just doesn't have any bus-specific logic). -- 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 3/3] Return a non-zero exit code if an error occurs during dts parsing.
On Thu, Jan 03, 2008 at 05:43:33PM -0600, Scott Wood wrote:
Previously, only failure to parse caused the reading of the tree to fail;
semantic errors that called yyerror() but not YYERROR only emitted a message,
without signalling make to stop the build.
This one, however, I don't like.
[snip]
diff --git a/dtc.h b/dtc.h
index 9b89689..cba9d28 100644
--- a/dtc.h
+++ b/dtc.h
@@ -233,6 +233,7 @@ struct reserve_info *add_reserve_entry(struct
reserve_info *list,
struct boot_info {
struct reserve_info *reservelist;
struct node *dt;/* the device tree */
+ int error;
};
This is unequivocally wrong. boot_info should have information about
the contents of the blob, not state information like the error.
If you're going to use an ugly global, then use it everywhere.
--
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] i2c-ibm_iic driver
On Saturday 05 January 2008, Sean MacLennan wrote:
I converted the i2c-ibm_iic driver from an ocp driver to an of_platform
driver. Since this driver is in the kernel.org kernel, should I rename
it and keep the old one around? I notice this was done with the emac
network driver.
The interesting question is whether there are any functional users in
arch/ppc left for the original driver. If all platforms that used
to use i2c-ibm_iic are broken already, you can can go ahead with
the conversion. Otherwise, there are two options:
1. duplicate the driver like you suggested
2. make the same driver both a ocp and of_platform, depending on
the configuration options.
Since most of the driver is untouched by your patch, I'd lean to
the second option, but of course, that is more work for you.
Your patch otherwise looks good, but I have a few comments on
details:
--- a/drivers/i2c/busses/Kconfig
+++ b/drivers/i2c/busses/Kconfig
@@ -241,7 +241,6 @@ config I2C_PIIX4
config I2C_IBM_IIC
tristate IBM PPC 4xx on-chip I2C interface
- depends on IBM_OCP
help
Say Y here if you want to use IIC peripheral found on
embedded IBM PPC 4xx based systems.
In any way, this one now needs to depend on PPC_MERGE now, you
could even make it depend on PPC_4xx, but it's often better to
allow building the driver when you can, even if it doesn't make
sense on your hardware. This gives a better compile coverage.
diff --git a/drivers/i2c/busses/i2c-ibm_iic.c
b/drivers/i2c/busses/i2c-ibm_iic.c
index 9b43ff7..838006f 100644
--- a/drivers/i2c/busses/i2c-ibm_iic.c
+++ b/drivers/i2c/busses/i2c-ibm_iic.c
@@ -3,6 +3,10 @@
*
* Support for the IIC peripheral on IBM PPC 4xx
*
+ * Copyright (c) 2008 PIKA Technologies
+ * Sean MacLennan [EMAIL PROTECTED]
+ * Converted to an of_platform_driver.
+ *
Changelogs in the file itself are discouraged. In this case, it's just
one line, so it's not really harmful.
I think the convention is for copyrights to be in chronological order,
so you should put the copyright below Eugene's.
* Copyright (c) 2003, 2004 Zultys Technologies.
* Eugene Surovegin [EMAIL PROTECTED] or [EMAIL PROTECTED]
*
+ dev-idx = index++;
+
+ dev_set_drvdata(ofdev-dev, dev);
+
+ if((addrp = of_get_address(np, 0, NULL, NULL)) == NULL ||
+ (addr = of_translate_address(np, addrp)) == OF_BAD_ADDR) {
+ printk(KERN_CRIT ibm-iic%d: Unable to get iic address\n,
+ dev-idx);
ret = -EBUSY;
goto fail1;
}
- if (!(dev-vaddr = ioremap(ocp-def-paddr, sizeof(struct
iic_regs{
+ if (!(dev-vaddr = ioremap(addr, sizeof(struct iic_regs{
printk(KERN_CRIT ibm-iic%d: failed to ioremap device
registers\n,
dev-idx);
ret = -ENXIO;
- goto fail2;
+ goto fail1;
}
Use of_iomap here to save a few lines.
init_waitqueue_head(dev-wq);
- dev-irq = iic_force_poll ? -1 : ocp-def-irq;
- if (dev-irq = 0){
+ if(iic_force_poll)
+ dev-irq = -1;
+ else if((dev-irq = irq_of_parse_and_map(np, 0)) == NO_IRQ) {
+ printk(KERN_ERR __FILE__ : irq_of_parse_and_map failed\n);
+ dev-irq = -1;
+ }
+
+ if (dev-irq = 0) {
/* Disable interrupts until we finish initialization,
assumes level-sensitive IRQ setup...
*/
This was in the original driver, but I think it's wrong anyway:
irq == 0 could be valid, so you shouldn't compare against that
in general. Use NO_IRQ as a symbolic way to express an invalid
IRQ (yes, I'm aware that NO_IRQ is currently defined to 0).
@@ -711,23 +722,30 @@ static int __devinit iic_probe(struct ocp_device *ocp){
if (dev-irq 0)
printk(KERN_WARNING ibm-iic%d: using polling mode\n,
- dev-idx);
+ dev-idx);
/* Board specific settings */
- dev-fast_mode = iic_force_fast ? 1 : (iic_data ? iic_data-fast_mode
: 0);
+ dev-fast_mode = iic_force_fast ? 1 : 0;
If there is a good reason to specify fast or slow mode per board, you may want
to make that a property in the device node.
+
+static struct of_device_id ibm_iic_match[] =
{
- { .vendor = OCP_VENDOR_IBM, .function = OCP_FUNC_IIC },
- { .vendor = OCP_VENDOR_INVALID }
+ { .type = i2c, .compatible = ibm,iic, },
+ {}
};
This is probably not specific enough. I'm rather sure that someone at IBM
has implemented an i2c chip that this driver doesn't support. Maybe
.compatible = ibm,405-iic
or similar would be a better thing to check for.
Arnd
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
Re: [patch 2/3] PS3: Add logical performance monitor device support
On Saturday 05 January 2008, Geoff Levand wrote:
+ struct layout {
+ struct ps3_system_bus_device dev;
+ } *p;
What's the point of this data structure? You don't use the
struct anywhere, and it only has one member, so you could
just declare that directly.
+ if (tmp1 != tmp2) {
+ pr_debug(%s:%d: wrong lpar\n,
+ __func__, __LINE__);
+ result = -1;
+ goto fail_rights;
+ }
+
+ if (!(p-dev.lpm.rights PS3_LPM_RIGHTS_USE_LPM)) {
+ pr_debug(%s:%d: don't have rights to use lpm\n,
+ __func__, __LINE__);
+ result = -1;
+ goto fail_rights;
+ }
+
I think __init functions should return error codes like -EPERM or
-EINVAL, not numeric -1.
Apart from that, the patch looks good.
Arnd
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Enable RTC for Ebony and Walnut
On Fri, Dec 21, 2007 at 03:29:22PM -0600, Olof Johansson wrote: Hi, On Fri, Dec 21, 2007 at 01:21:30PM +1100, David Gibson wrote: Index: working-2.6/arch/powerpc/platforms/Kconfig === --- working-2.6.orig/arch/powerpc/platforms/Kconfig 2007-12-10 10:52:44.0 +1100 +++ working-2.6/arch/powerpc/platforms/Kconfig 2007-12-21 13:11:34.0 +1100 @@ -315,6 +315,9 @@ config FSL_ULI1575 config CPM bool +config OF_RTC + bool + New config options should have descriptions, even if they're silent ones. Uh.. but if there's a description, won't kconfig prompt for the option? This one should only ever be selected by the platform options. -- 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 3/3] PS3: Add logical performance monitor driver support
On Saturday 05 January 2008, Geoff Levand wrote:
From: Takashi Yamamoto [EMAIL PROTECTED]
Add PS3 logical performance monitor (lpm) device driver.
The PS3's LV1 hypervisor provides a Logical Performance Monitor that
abstarcts the Cell processor's performance monitor features for use
by guest operating systems.
Signed-off-by: Takashi Yamamoto [EMAIL PROTECTED]
Signed-off-by: Geoff Levand [EMAIL PROTECTED]
Wow, great stuff!
One bit of information I'm missing in the description is what the users
of this code are. Your Kconfig text mentions that can be used for both
perfmon and oprofile. Are these, or one of them, currently under
work as well?
--- a/arch/powerpc/platforms/ps3/Kconfig
+++ b/arch/powerpc/platforms/ps3/Kconfig
@@ -138,4 +138,18 @@ config PS3_FLASH
be disabled on the kernel command line using ps3flash=off, to
not allocate this fixed buffer.
+config PS3_LPM
+ tristate PS3 Logical Performance Monitor support
+ depends on PPC_PS3
+ default n
'default n' is redundant.
+ help
+ Include support for the PS3 Logical Performance Monitor.
+
+ This support is required to use the logical performance monitor
+ of the PS3's LV1 hypervisor.
+
+ If you intend to use the advanced performance monitoring and
+ profiling support of the Cell processor with programs like
+ oprofile and perfmon, then say Y or M, otherwise say N.
+
Should that be perfmon2 instead of perfmon?
I think once they high-level drivers are merged, it would make sense
to autoselected by these, so the user doesn't have to read through
the help text.
+/**
+ * struct ps3_lpm_priv - private lpm device data.
+ *
+ * @mutex: Open/close mutex.
+ * @rights: The lpm rigths granted by the system policy module.
+ * @pu_id: The lv1 id of the BE prosessor for this lpm instance.
+ * @lpm_id: The lv1 id of this lpm instance.
+ * @outlet_id: The outlet created by lv1 for this lpm instance.
+ * @constructed: A flag indicating the lpm driver has been opened -- can we
just use (lpm_id == ???)
+ * @tb_size: The lv1 trace buffer size
+ * @tb_cache: Trace buffer cache
+ * @tb_cache_internal: A flag indicating the trace buffer cache was allocated
+ * by the driver.
+ * @tb_cache: Trace buffer cache
+ * @sizeof_traced_data: Traced data size
+ * @sbd: the struct ps3_system_bus_device attached to this driver
+ */
+
+struct ps3_lpm_priv {
+ struct mutex mutex;
+ u64 rights;
+ u64 pu_id;
+ u64 lpm_id;
+ u64 outlet_id;
+ int constructed;
+ u64 tb_size;
+ void *tb_cache;
+ u64 tb_cache_size;
+ int tb_cache_internal;
+ u64 sizeof_traced_data;
+ u64 sizeof_total_copied_data;
+ u64 shadow_pm_control;
+ u64 shadow_pm_start_stop;
+ u64 shadow_pm_interval;
+ u64 shadow_group_control;
+ u64 shadow_debug_bus_control;
+ struct ps3_system_bus_device *sbd;
+};
Some of the members in this struct are not present in the comment,
which is somewhat confusing.
+
+/**
+ * lpm_priv - Static instance of the lpm data.
+ *
+ * Since the exported routines don't support the notion of a device
+ * instance we need to hold the instance in this static variable
+ * and only allow at most one instance to be created.
+ */
+
+static struct ps3_lpm_priv *lpm_priv;
Hmmm, my gut feeling about this is that it would be better to actually
pass this around through the exported functions. That would also
provide some arbitration between the possible users, e.g. oprofile
would get -EBUSY when asking for the ps3_lpm while perfmon2 is
already active.
+/* bookmark spr address */
+#define BOOKMARK_SPR_ADDR 1020
This one belongs to asm/reg.h and should be named SRPN_BKMK.
+inline u32 ps3_get_hw_thread_id(int cpu)
+{
+ return cpu;
+}
+EXPORT_SYMBOL_GPL(ps3_get_hw_thread_id);
The 'inline' is bogus, as that doesn't work across exported functions
and you are not using the function in this file.
Should you perhaps return hard_smp_processor_id(cpu) instead of cpu
here?
+/**
+ * _ps3_copy_trace_buffer - Copy the trace buffer.
+ */
+
+static u64 _ps3_copy_trace_buffer(u64 offset, u64 size, u64 *to, int to_user)
+{
+ int result;
+ u64 sizeof_copied_data;
+
+ if (offset = lpm_priv-sizeof_traced_data)
+ return 0;
+
+ result = lv1_copy_lpm_trace_buffer(lpm_priv-lpm_id, offset, size,
+ sizeof_copied_data);
+ if (result) {
+ dev_err(sbd_core(), %s:%u: lv1_copy_lpm_trace_buffer failed:
+ offset 0x%lx, size 0x%lx: %s\n, __func__, __LINE__,
+ offset, size, ps3_result(result));
+ return 0;
+ }
+
+ if (to_user) {
+ result = copy_to_user((void __user *)to, lpm_priv-tb_cache,
+ sizeof_copied_data);
+ if (result) {
+
Re: [PATCH v2] [POWERPC] Provide a way to protect 4k subpages when using 64k pages
On Saturday 05 January 2008, Paul Mackerras wrote:
This version allocates a new system call number for the subpage_prot
syscall.
Ah, good. Thanks!
--- a/arch/powerpc/kernel/syscalls.c
+++ b/arch/powerpc/kernel/syscalls.c
@@ -328,3 +328,7 @@ void do_show_syscall_exit(unsigned long r3)
{
printk( - %lx, current=%p cpu=%d\n, r3, current,
smp_processor_id());
}
+
+#ifndef CONFIG_PPC_SUBPAGE_PROT
+cond_syscall(subpage_prot);
+#endif
cond_syscall is defined in a way that you don't need the #ifdef here,
and the other users always have it unconditionally.
+/*
+ * Copy in a subpage protection map for an address range.
+ * The map has 2 bits per 4k subpage, so 32 bits per 64k page.
+ * Each 2-bit field is 0 to allow any access, 1 to prevent writes,
+ * 2 or 3 to prevent all accesses.
+ * Note that the normal page protections also apply; the subpage
+ * protection mechanism is an additional constraint, so putting 0
+ * in a 2-bit field won't allow writes to a page that is otherwise
+ * write-protected.
+ */
+long sys_subpage_prot(unsigned long addr, unsigned long len, u32 __user *map)
syscalls are normally marked asmlinkage, right? I know that it doesn't
have an effect on powerpc, but so far, we have been using the convention
anyway, AFAIK.
Also, I think there should be a declaration in asm/syscalls.h so we don't
get a warning about an undeclared global function from sparse.
diff --git a/include/asm-powerpc/systbl.h b/include/asm-powerpc/systbl.h
index 11d5383..0c8b0d6 100644
--- a/include/asm-powerpc/systbl.h
+++ b/include/asm-powerpc/systbl.h
@@ -313,3 +313,4 @@ COMPAT_SYS_SPU(timerfd)
SYSCALL_SPU(eventfd)
COMPAT_SYS_SPU(sync_file_range2)
COMPAT_SYS(fallocate)
+SYSCALL(subpage_prot)
The convention I've used for SPU syscalls is to allow them unless there is
a specific reason why it's harmful or not possible for the SPU to do it.
I think it should be SYSCALL_SPU because of that.
I already missed the addition of fallocate, which I think should have been
COMPAT_SYS_SPU. I can send you a patch for that one if you like.
Arnd
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] ibm_newemac: Increase number of default rx-/tx-buffers
On Saturday 05 January 2008, Benjamin Herrenschmidt wrote: On Sat, 2008-01-05 at 10:50 +0100, Stefan Roese wrote: Performance tests done by AMCC have shown that 256 buffer increase the performance of the Linux EMAC driver. So let's update the default values to match this setup. Signed-off-by: Stefan Roese [EMAIL PROTECTED] --- Do we have the numbers ? Did they also measure latency ? I hoped this question would not come. ;) No, unfortunately I don't have any numbers. Just the recommendation from AMCC to always use 256 buffers. Best regards, Stefan ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] i2c-ibm_iic driver
On Saturday 05 January 2008, Arnd Bergmann wrote:
On Saturday 05 January 2008, Sean MacLennan wrote:
I converted the i2c-ibm_iic driver from an ocp driver to an of_platform
driver. Since this driver is in the kernel.org kernel, should I rename
it and keep the old one around? I notice this was done with the emac
network driver.
The interesting question is whether there are any functional users in
arch/ppc left for the original driver. If all platforms that used
to use i2c-ibm_iic are broken already, you can can go ahead with
the conversion.
No, they are not all broken. We still have to support arch/ppc till mid of
this year.
Otherwise, there are two options:
1. duplicate the driver like you suggested
2. make the same driver both a ocp and of_platform, depending on
the configuration options.
Since most of the driver is untouched by your patch, I'd lean to
the second option, but of course, that is more work for you.
I did send a patch for such a combined driver a few months ago:
http://patchwork.ozlabs.org/linuxppc/patch?person=305id=14181
There were still same open issues and I didn't find the time till now to
address them. It would be great if you could take care of these issues and
submit a reworked version.
Your patch otherwise looks good, but I have a few comments on
details:
--- a/drivers/i2c/busses/Kconfig
+++ b/drivers/i2c/busses/Kconfig
@@ -241,7 +241,6 @@ config I2C_PIIX4
config I2C_IBM_IIC
tristate IBM PPC 4xx on-chip I2C interface
- depends on IBM_OCP
help
Say Y here if you want to use IIC peripheral found on
embedded IBM PPC 4xx based systems.
In any way, this one now needs to depend on PPC_MERGE now, you
could even make it depend on PPC_4xx, but it's often better to
allow building the driver when you can, even if it doesn't make
sense on your hardware. This gives a better compile coverage.
diff --git a/drivers/i2c/busses/i2c-ibm_iic.c
b/drivers/i2c/busses/i2c-ibm_iic.c index 9b43ff7..838006f 100644
--- a/drivers/i2c/busses/i2c-ibm_iic.c
+++ b/drivers/i2c/busses/i2c-ibm_iic.c
@@ -3,6 +3,10 @@
*
* Support for the IIC peripheral on IBM PPC 4xx
*
+ * Copyright (c) 2008 PIKA Technologies
+ * Sean MacLennan [EMAIL PROTECTED]
+ * Converted to an of_platform_driver.
+ *
Changelogs in the file itself are discouraged. In this case, it's just
one line, so it's not really harmful.
I think the convention is for copyrights to be in chronological order,
so you should put the copyright below Eugene's.
* Copyright (c) 2003, 2004 Zultys Technologies.
* Eugene Surovegin [EMAIL PROTECTED] or [EMAIL PROTECTED]
*
+ dev-idx = index++;
+
+ dev_set_drvdata(ofdev-dev, dev);
+
+ if((addrp = of_get_address(np, 0, NULL, NULL)) == NULL ||
+ (addr = of_translate_address(np, addrp)) == OF_BAD_ADDR) {
+ printk(KERN_CRIT ibm-iic%d: Unable to get iic
address\n, + dev-idx);
ret = -EBUSY;
goto fail1;
}
- if (!(dev-vaddr = ioremap(ocp-def-paddr, sizeof(struct
iic_regs{ + if (!(dev-vaddr = ioremap(addr, sizeof(struct
iic_regs{ printk(KERN_CRIT ibm-iic%d: failed to ioremap device
registers\n, dev-idx);
ret = -ENXIO;
- goto fail2;
+ goto fail1;
}
Use of_iomap here to save a few lines.
init_waitqueue_head(dev-wq);
- dev-irq = iic_force_poll ? -1 : ocp-def-irq;
- if (dev-irq = 0){
+ if(iic_force_poll)
+ dev-irq = -1;
+ else if((dev-irq = irq_of_parse_and_map(np, 0)) == NO_IRQ) {
+ printk(KERN_ERR __FILE__ : irq_of_parse_and_map
failed\n); + dev-irq = -1;
+ }
+
+ if (dev-irq = 0) {
/* Disable interrupts until we finish initialization,
assumes level-sensitive IRQ setup...
*/
This was in the original driver, but I think it's wrong anyway:
irq == 0 could be valid, so you shouldn't compare against that
in general. Use NO_IRQ as a symbolic way to express an invalid
IRQ (yes, I'm aware that NO_IRQ is currently defined to 0).
@@ -711,23 +722,30 @@ static int __devinit iic_probe(struct ocp_device
*ocp){
if (dev-irq 0)
printk(KERN_WARNING ibm-iic%d: using polling mode\n,
- dev-idx);
+ dev-idx);
/* Board specific settings */
- dev-fast_mode = iic_force_fast ? 1 : (iic_data ?
iic_data-fast_mode : 0); + dev-fast_mode = iic_force_fast ? 1 :
0;
If there is a good reason to specify fast or slow mode per board, you may
want to make that a property in the device node.
+
+static struct of_device_id ibm_iic_match[] =
{
- { .vendor = OCP_VENDOR_IBM, .function =
Re: [PATCH] i2c-ibm_iic driver
On Saturday 05 January 2008, Stefan Roese wrote: This is probably not specific enough. I'm rather sure that someone at IBM has implemented an i2c chip that this driver doesn't support. Maybe .compatible = ibm,405-iic or similar would be a better thing to check for. .compatible = ibm,4xx-iic please, since 405 and 440 have the same I2C controller. But that's not how compatible properties work -- they should not contain wildcards. If you have different devices that are backwards compatible, you should list the older one in all newer devices, e.g. the 440 can list that it is compatible with both ibm,405-iic and ibm,440-iic. If there was an earlier 401 that had iic as well, you may even want to include that in the device tree. Arnd ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] i2c-ibm_iic driver
On Saturday 05 January 2008, Arnd Bergmann wrote: This is probably not specific enough. I'm rather sure that someone at IBM has implemented an i2c chip that this driver doesn't support. Maybe .compatible = ibm,405-iic or similar would be a better thing to check for. .compatible = ibm,4xx-iic please, since 405 and 440 have the same I2C controller. But that's not how compatible properties work -- they should not contain wildcards. If you have different devices that are backwards compatible, you should list the older one in all newer devices, e.g. the 440 can list that it is compatible with both ibm,405-iic and ibm,440-iic. If there was an earlier 401 that had iic as well, you may even want to include that in the device tree. OK. Thanks for clarifying. Best regards, Stefan ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] MTD for Taco
Stefan Roese wrote:
On Saturday 05 January 2008, Sean MacLennan wrote:
This patch adds the maps for the taco. It also gets the ndfc.c NAND
driver in a compilable state. The map is guaranteed to change since the
exact NOR/NAND flash configuration is in flux right now when we found
the 256M NAND flash won't boot properly.
Currently it configures the NOR in a reasonable fashion and leaves the
NAND as one honkin' parition.
snip
diff --git a/drivers/mtd/nand/ndfc.c b/drivers/mtd/nand/ndfc.c
index 1c0e89f..f5e93cf 100644
--- a/drivers/mtd/nand/ndfc.c
+++ b/drivers/mtd/nand/ndfc.c
@@ -24,11 +24,6 @@
#include linux/platform_device.h
#include asm/io.h
-#ifdef CONFIG_40x
-#include asm/ibm405.h
-#else
-#include asm/ibm44x.h
-#endif
You do break arch/ppc support with this patch. We have to still support
arch/ppc a few month, so please don't break this support for now.
Gotcha. Is CONFIG_PPC_MERGED the right flag for things like this?
struct ndfc_nand_mtd {
struct mtd_info mtd;
@@ -110,6 +105,40 @@ static int ndfc_calculate_ecc(struct mtd_info *mtd,
return 0;
}
+#ifdef CONFIG_TACO
+/* The NDFC may allow 32bit read/writes, but it sure doesn't work on
+ * the taco!
+ */
We definitely don't want to see such board specific stuff in the common
NDFC driver. And I really doubt that you need this change for your board.
We are using this ndfc driver on multiple boards, and all have no
problems accessing the controller with 32bit read/writes. So you most
likely have a problem with your board port. Perhaps something with
with the EBC setup. Please re-check and compare with boards that are know
to work, like Sequoia.
Does the Sequoia use a Rev C chip? We had to modify u-boot the same way.
As soon as we do an 8-bit access we get a machine check exception.
To be honest, I don't know what more to check.
+static void ndfc_read_buf(struct mtd_info *mtd, uint8_t *buf, int len)
+{
+ struct ndfc_controller *ndfc = ndfc_ctrl;
+ uint8_t *p = (uint8_t *) buf;
+
+ for(;len 0; len -= 1)
+ *p++ = __raw_readb(ndfc-ndfcbase + NDFC_DATA);
+}
+
+static void ndfc_write_buf(struct mtd_info *mtd, const uint8_t *buf, int
len) +{
+ struct ndfc_controller *ndfc = ndfc_ctrl;
+ uint8_t *p = (uint8_t *) buf;
+
+ for(;len 0; len -= 1)
+ __raw_writeb(*p++, ndfc-ndfcbase + NDFC_DATA);
+}
+
+static int ndfc_verify_buf(struct mtd_info *mtd, const uint8_t *buf, int
len) +{
+ struct ndfc_controller *ndfc = ndfc_ctrl;
+ uint8_t *p = (uint8_t *) buf;
+
+ for(;len 0; len -= 1)
+ if (*p++ != __raw_readb(ndfc-ndfcbase + NDFC_DATA))
+ return -EFAULT;
+
+ return 0;
+}
+#else
snip
+++ drivers/mtd/maps/taco.c 2008-01-02 13:07:43.0 -0500
@@ -0,0 +1,140 @@
+/*
+ * $Id: $
+ *
+ * drivers/mtd/maps/taco.c
+ *
+ * Mapping for PIKA Taco flash
I'm pretty sure that you don't need a board specific mapping driver
for NOR flash. physmap_of should be exactly what you need. You just need
to fill the device tree properties correctly.
Yes, this was copied straight from the PPC port. The whole NOR/NAND
flash is in flux. Marketing really really wants to drop NOR for price
reasons. So I will probably leave this until a final decision is made.
BTW: I noticed you are using the boot wrapper approach. This is not
necessary anymore, since the latest U-Boot version has flattened
device tree support included for 4xx too. Let me know if you have any
questions about this.
I did this port over Christmas and had no access to the hardware guys so
I stayed away from u-boot since I had no way to recover from mistakes. I
hope to make towards the tree image approach but for now the in-kernel
version is much easier for me to work with.
Cheers,
Sean
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] Base Taco Platform support
Benjamin Herrenschmidt wrote: On Fri, 2008-01-04 at 23:49 -0500, Sean MacLennan wrote: Here is a patch for the base taco platform. It is against for-2.6.25. It adds basically everything in the arch/powerpc. Care to tell us a bit more about what Taco is ? Even better is to also do that in your Kconfig entry, maybe along with a URL to your web site. Cheers, Ben. Can do, if I can figure out what it is ;) Basically it is a telephony appliance geared mainly to low-density asterisk users. I will update the Kconfig. Cheers, Sean ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] Miscellaneous for Taco
Stefan Roese wrote: On Saturday 05 January 2008, Benjamin Herrenschmidt wrote: diff --git a/drivers/usb/Kconfig b/drivers/usb/Kconfig index 7580aa5..480580c 100644 --- a/drivers/usb/Kconfig +++ b/drivers/usb/Kconfig @@ -39,6 +39,7 @@ config USB_ARCH_HAS_OHCI # PPC: default y if STB03xxx default y if PPC_MPC52xx + default y if TACO # MIPS: default y if SOC_AU1X00 # more: I think we should instead reference use the 440EP here, I vote for adding 440EP here. Best regards, Stefan Ok. I thought of that, but most 440EP boards have PCI set and don't need the special option. I was worried if I put 440EP someone down the road might remove it as extraneous. We are probably the only 440EP board with no PCI ;) Cheers, Sean ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] Hwmon for Taco
Benjamin Herrenschmidt wrote: +module_exit(ad7414_exit); --- /dev/null2005-11-20 22:22:37.0 -0500 +++ drivers/hwmon/taco-dtm.c 2008-01-05 00:06:21.0 -0500 @@ -0,0 +1,78 @@ +/* + * drivers/hwmon/taco-dtm.c + * + * Overview: On the Taco, the fpga controls the fan. This provides + * the temperature to the fpga. + * + * Copyright (c) 2008 PIKA Technologies + *Sean MacLennan [EMAIL PROTECTED] + * + * This program is free software; you can redistribute it and/or modify it + * under the terms of the GNU General Public License as published by the + * Free Software Foundation; either version 2 of the License, or (at your + * option) any later version. + * + */ + +#include linux/module.h +#include linux/kthread.h +#include linux/io.h + + +#define TACO_FPGA_BASE 0x8000 That should be in the device-tree... Cheers, Ben. It is in the device tree, I just forgot to update the driver to use it. Thanks. Cheers, Sean ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] i2c-ibm_iic driver
Arnd Bergmann wrote:
On Saturday 05 January 2008, Sean MacLennan wrote:
I converted the i2c-ibm_iic driver from an ocp driver to an of_platform
driver. Since this driver is in the kernel.org kernel, should I rename
it and keep the old one around? I notice this was done with the emac
network driver.
The interesting question is whether there are any functional users in
arch/ppc left for the original driver. If all platforms that used
to use i2c-ibm_iic are broken already, you can can go ahead with
the conversion. Otherwise, there are two options:
1. duplicate the driver like you suggested
2. make the same driver both a ocp and of_platform, depending on
the configuration options.
Since most of the driver is untouched by your patch, I'd lean to
the second option, but of course, that is more work for you.
Given Stefan subsequent post, I'll go with the second option.
Your patch otherwise looks good, but I have a few comments on
details:
--- a/drivers/i2c/busses/Kconfig
+++ b/drivers/i2c/busses/Kconfig
@@ -241,7 +241,6 @@ config I2C_PIIX4
config I2C_IBM_IIC
tristate IBM PPC 4xx on-chip I2C interface
- depends on IBM_OCP
help
Say Y here if you want to use IIC peripheral found on
embedded IBM PPC 4xx based systems.
In any way, this one now needs to depend on PPC_MERGE now, you
could even make it depend on PPC_4xx, but it's often better to
allow building the driver when you can, even if it doesn't make
sense on your hardware. This gives a better compile coverage.
diff --git a/drivers/i2c/busses/i2c-ibm_iic.c
b/drivers/i2c/busses/i2c-ibm_iic.c
index 9b43ff7..838006f 100644
--- a/drivers/i2c/busses/i2c-ibm_iic.c
+++ b/drivers/i2c/busses/i2c-ibm_iic.c
@@ -3,6 +3,10 @@
*
* Support for the IIC peripheral on IBM PPC 4xx
*
+ * Copyright (c) 2008 PIKA Technologies
+ * Sean MacLennan [EMAIL PROTECTED]
+ * Converted to an of_platform_driver.
+ *
Changelogs in the file itself are discouraged. In this case, it's just
one line, so it's not really harmful.
I think the convention is for copyrights to be in chronological order,
so you should put the copyright below Eugene's.
Ok, I will change it. To be honest, I didn't think it was enough of a
change to actually be worth a copyright, but PIKA is a little touchy
about copyrights right now and I wanted to point out I *only* did the
port. I will remove the changelog and move the copyright notice.
* Copyright (c) 2003, 2004 Zultys Technologies.
* Eugene Surovegin [EMAIL PROTECTED] or [EMAIL PROTECTED]
*
+ dev-idx = index++;
+
+ dev_set_drvdata(ofdev-dev, dev);
+
+ if((addrp = of_get_address(np, 0, NULL, NULL)) == NULL ||
+ (addr = of_translate_address(np, addrp)) == OF_BAD_ADDR) {
+ printk(KERN_CRIT ibm-iic%d: Unable to get iic address\n,
+ dev-idx);
ret = -EBUSY;
goto fail1;
}
- if (!(dev-vaddr = ioremap(ocp-def-paddr, sizeof(struct
iic_regs{
+ if (!(dev-vaddr = ioremap(addr, sizeof(struct iic_regs{
printk(KERN_CRIT ibm-iic%d: failed to ioremap device
registers\n,
dev-idx);
ret = -ENXIO;
- goto fail2;
+ goto fail1;
}
Use of_iomap here to save a few lines.
Cool, I didn't notice that function.
init_waitqueue_head(dev-wq);
- dev-irq = iic_force_poll ? -1 : ocp-def-irq;
- if (dev-irq = 0){
+ if(iic_force_poll)
+ dev-irq = -1;
+ else if((dev-irq = irq_of_parse_and_map(np, 0)) == NO_IRQ) {
+ printk(KERN_ERR __FILE__ : irq_of_parse_and_map failed\n);
+ dev-irq = -1;
+ }
+
+ if (dev-irq = 0) {
/* Disable interrupts until we finish initialization,
assumes level-sensitive IRQ setup...
*/
This was in the original driver, but I think it's wrong anyway:
irq == 0 could be valid, so you shouldn't compare against that
in general. Use NO_IRQ as a symbolic way to express an invalid
IRQ (yes, I'm aware that NO_IRQ is currently defined to 0).
Ok.
@@ -711,23 +722,30 @@ static int __devinit iic_probe(struct ocp_device *ocp){
if (dev-irq 0)
printk(KERN_WARNING ibm-iic%d: using polling mode\n,
- dev-idx);
+ dev-idx);
/* Board specific settings */
- dev-fast_mode = iic_force_fast ? 1 : (iic_data ?
iic_data-fast_mode : 0);
+ dev-fast_mode = iic_force_fast ? 1 : 0;
If there is a good reason to specify fast or slow mode per board, you may want
to make that a property in the device node.
Ok. I really don't know, none of the board ports I looked at used fast mode.
+
Re: [PATCH] i2c-ibm_iic driver
Stefan Roese wrote: Otherwise, there are two options: 1. duplicate the driver like you suggested 2. make the same driver both a ocp and of_platform, depending on the configuration options. Since most of the driver is untouched by your patch, I'd lean to the second option, but of course, that is more work for you. I did send a patch for such a combined driver a few months ago: http://patchwork.ozlabs.org/linuxppc/patch?person=305id=14181 There were still same open issues and I didn't find the time till now to address them. It would be great if you could take care of these issues and submit a reworked version. I can look into this. Thanks! Cheers, Sean ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] i2c-ibm_iic driver
On Saturday 05 January 2008, Sean MacLennan wrote: Ok. The 44x based .dts files do not list 405-iic, so would I think I will add two compatibility matches, one for 405 and one for 440EP. That way I do not break all the current .dts files. Everybody ok with that? Sounds good. There are obviously no other drivers that know only about 405 but not about 440, so there is no backwards compatibility problem. If we ever get a 450/460/470/... that we want to support with this driver, it can simply claim to be compatible with 440 or 405 if not both. Arnd ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] MTD for Taco
On Saturday 05 January 2008, Sean MacLennan wrote: You do break arch/ppc support with this patch. We have to still support arch/ppc a few month, so please don't break this support for now. Gotcha. Is CONFIG_PPC_MERGED the right flag for things like this? Yes, but it it's spelled CONFIG_PPC_MERGE, not CONFIG_PPC_MERGED. Arnd ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] ibm_newemac: Increase number of default rx-/tx-buffers
On Sat, 2008-01-05 at 13:38 +0100, Stefan Roese wrote: On Saturday 05 January 2008, Benjamin Herrenschmidt wrote: On Sat, 2008-01-05 at 10:50 +0100, Stefan Roese wrote: Performance tests done by AMCC have shown that 256 buffer increase the performance of the Linux EMAC driver. So let's update the default values to match this setup. Signed-off-by: Stefan Roese [EMAIL PROTECTED] --- Do we have the numbers ? Did they also measure latency ? I hoped this question would not come. ;) No, unfortunately I don't have any numbers. Just the recommendation from AMCC to always use 256 buffers. Ok. Well, it's just a .config option so I suppose the patch is fine. Can you also update the defconfigs (at least for the recent AMCC boards) ? Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] Miscellaneous for Taco
On Sat, 2008-01-05 at 13:22 -0500, Sean MacLennan wrote: Ok. I thought of that, but most 440EP boards have PCI set and don't need the special option. I was worried if I put 440EP someone down the road might remove it as extraneous. We are probably the only 440EP board with no PCI ;) Well, it's different PCI is an option that can be enabled ... or not by the board. In our case, the HAS_OHCI thing is just a switch to indicate that an OHCI can exist, it's not actually adding code, so it can be safely left ON whenever a 440EP processor is there, it has no bloat and won't conflict with the PCI option. Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] ibm_newemac: Increase number of default rx-/tx-buffers
On Sun, 06 Jan 2008 07:53:06 +1100 Benjamin Herrenschmidt [EMAIL PROTECTED] wrote: On Sat, 2008-01-05 at 13:38 +0100, Stefan Roese wrote: On Saturday 05 January 2008, Benjamin Herrenschmidt wrote: On Sat, 2008-01-05 at 10:50 +0100, Stefan Roese wrote: Performance tests done by AMCC have shown that 256 buffer increase the performance of the Linux EMAC driver. So let's update the default values to match this setup. Signed-off-by: Stefan Roese [EMAIL PROTECTED] --- Do we have the numbers ? Did they also measure latency ? I hoped this question would not come. ;) No, unfortunately I don't have any numbers. Just the recommendation from AMCC to always use 256 buffers. Ok. Well, it's just a .config option so I suppose the patch is fine. Can you also update the defconfigs (at least for the recent AMCC boards) ? No need for a defconfig update patch. Paul or I usually do a general defconfig update for most boards before the next kernel version. This will get picked up then. josh ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] ibm_newemac: Increase number of default rx-/tx-buffers
On Sat, 2008-01-05 at 15:48 -0600, Josh Boyer wrote: No need for a defconfig update patch. Paul or I usually do a general defconfig update for most boards before the next kernel version. This will get picked up then. Will it ? I think the defconfigs will stick to the old value. Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] i2c-ibm_iic driver
On Sat, Jan 05, 2008 at 08:18:22PM +0100, Arnd Bergmann wrote: On Saturday 05 January 2008, Sean MacLennan wrote: Ok. The 44x based .dts files do not list 405-iic, so would I think I will add two compatibility matches, one for 405 and one for 440EP. That way I do not break all the current .dts files. Everybody ok with that? Sounds good. There are obviously no other drivers that know only about 405 but not about 440, so there is no backwards compatibility problem. If we ever get a 450/460/470/... that we want to support with this driver, it can simply claim to be compatible with 440 or 405 if not both. Actually, I think checking for ibm,iic is ok. I'm sure there are other IBM produced i2c chips, but IIC is also the name of the ASIC block that implements this controller. ibm,iic in the compatible is supposed to refer to this family of i2c bridges. Not a great choice on my part, perhaps, but not so awful as to go changing the existing device trees I think. -- 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/3] Add support for binary includes.
On Fri, Jan 04, 2008 at 03:10:43PM -0600, Scott Wood wrote:
A property's data can be populated with a file's contents
as follows:
node {
prop = /incbin/(path/to/data);
};
A subset of a file can be included by passing start and size parameters.
For example, to include bytes 8 through 23:
node {
prop = /incbin/(path/to/data, 8, 16);
};
Hrm. Can we leave this one until after 1.1? Since it adds new
syntax, I think it would be worth cogitating a bit longer.
--
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] MTD for Taco
On Sat, Jan 05, 2008 at 10:41:17AM +0100, Stefan Roese wrote: On Saturday 05 January 2008, Sean MacLennan wrote: +++ drivers/mtd/maps/taco.c 2008-01-02 13:07:43.0 -0500 @@ -0,0 +1,140 @@ +/* + * $Id: $ + * + * drivers/mtd/maps/taco.c + * + * Mapping for PIKA Taco flash I'm pretty sure that you don't need a board specific mapping driver for NOR flash. physmap_of should be exactly what you need. You just need to fill the device tree properties correctly. Absolutely. We should not be using C-coded maps in arch/powerpc -- 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] ibm_newemac: Increase number of default rx-/tx-buffers
On Sun, 06 Jan 2008 08:54:28 +1100 Benjamin Herrenschmidt [EMAIL PROTECTED] wrote: On Sat, 2008-01-05 at 15:48 -0600, Josh Boyer wrote: No need for a defconfig update patch. Paul or I usually do a general defconfig update for most boards before the next kernel version. This will get picked up then. Will it ? I think the defconfigs will stick to the old value. Put another way, if Kconfig doesn't update it automagically, I'll be sure to do it myself. :) josh ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] MTD for Taco
David Gibson wrote: I'm pretty sure that you don't need a board specific mapping driver for NOR flash. physmap_of should be exactly what you need. You just need to fill the device tree properties correctly. Absolutely. We should not be using C-coded maps in arch/powerpc Ok a couple of questions. How do I find out the size of the NOR flash? It was in a global in the ppc arch. Also, where is the best place to fixup the partitions? We have paritions that must be at the top and ones that must be at the bottom, so we dynamically setup the partitions based on the NOR size. The NOR size is variable. And is it ok the name the paritions in the dts based on an index? I notice others use an address, but since I don't know the address up front I just used index numbers. Cheers, Sean ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [alsa-devel] [PATCH] ASoC drivers for the Freescale MPC8610 SoC
On Fri, Jan 04, 2008 at 08:39:54PM -0600, Timur Tabi wrote: David Gibson wrote: And what distinction are you drawing between first and second here? Oh, that's an easy one: The CS4270 can work without an I2C or SPI connection, but it will never work without an I2S connection. Why would the I2S need to scan for codecs? Wouldn't it be up to the codec driver to register with I2S? Not in ASoC V1. The codec driver registers with ASoC, but the actual connection to other devices (e.g. the I2S driver) is done either in the I2S driver or in the fabric driver, depending on your mood. And that connection is done via a pointer to a structure in the codec driver. Ok, but couldn't you strucutre your I2S or fabric driver so that it only becomes fully operational once the codec driver has registered with it? -- 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 2/3] Handle absolute pathnames correctly in dtc_open_file.
On Fri, Jan 04, 2008 at 03:10:45PM -0600, Scott Wood wrote:
Also, free file-dir when freeing file.
Signed-off-by: Scott Wood [EMAIL PROTECTED]
---
srcpos.c | 12
1 files changed, 12 insertions(+), 0 deletions(-)
diff --git a/srcpos.c b/srcpos.c
index 7340c33..7a0c47e 100644
--- a/srcpos.c
+++ b/srcpos.c
@@ -86,6 +86,16 @@ struct dtc_file *dtc_open_file(const char *fname,
return file;
}
+ if (fname[0] == '/') {
+ file-file = fopen(fname, r);
+
+ if (!file-file)
+ goto out;
+
+ file-name = strdup(fname);
+ return file;
+ }
+
if (!search)
search = default_search;
@@ -100,6 +110,7 @@ struct dtc_file *dtc_open_file(const char *fname,
}
out:
+ free((void *)file-dir);
That cast shouldn't be there.
free(file);
return NULL;
}
@@ -109,5 +120,6 @@ void dtc_close_file(struct dtc_file *file)
if (fclose(file-file))
die(Error closing \%s\: %s\n, file-name, strerror(errno));
+ free((void *)file-dir);
Or here.
--
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] MTD for Taco
On Sat, Jan 05, 2008 at 10:20:58PM -0500, Sean MacLennan wrote: David Gibson wrote: I'm pretty sure that you don't need a board specific mapping driver for NOR flash. physmap_of should be exactly what you need. You just need to fill the device tree properties correctly. Absolutely. We should not be using C-coded maps in arch/powerpc Ok a couple of questions. How do I find out the size of the NOR flash? It was in a global in the ppc arch. The flash size goes in the reg property of the flash node. Also, where is the best place to fixup the partitions? We have paritions that must be at the top and ones that must be at the bottom, so we dynamically setup the partitions based on the NOR size. The NOR size is variable. Ok, you can fix this up in the bootwrapper. And is it ok the name the paritions in the dts based on an index? I notice others use an address, but since I don't know the address up front I just used index numbers. No, the node name must match the node's reg property, which is the partition's offset. If you're creating the partition nodess on the fly in the bootwrapper you can get that right there. I'm also hoping soon to add a function to fixup node names to libfdt, which will then be usable in the wrapper. -- 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
