Re: [PATCH 0/6] powerpc topology updates
On Sun, 2008-07-27 at 00:24 -0500, Nathan Lynch wrote: > This series consists of a couple of cleanups and a few feature > additions, all of which are more or less related to system topology > (threads, cores, caches, sysfs...) These are independent of > each other except for 4 and 5 (core sibling and core id info). > > I'd say the highlights are the last three patches, which add core and > cache information to sysfs. Here is some example output with the > patches applied: Applied with minor changes. I made cpu_to_l2cache() use of_find_device_by_phandle() which should work as well on pseries and should have the added advantage of working on others too (ie. it will use device_node->linux_phandle to do the compare, which is setup with the base phandle and overriden by the ibm,phandle if there is one). I also did a few cleanups of printk's and error checking. Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] powerpc: Disable 64K huge page support when doing 64K SPU mappings
The 64K SPU local store mapping feature is incompatible with the
64K huge pages support due to the inability of some parts of
the memory management to differenciate between them while they
use a different page table format.
For now, disable 64K huge pages when CONFIG_SPU_FS_64K_LS,
in the long run, this can be fixed by making this feature use
the hugetlb page table format.
Signed-off-by: Benjamin Herrenschmidt <[EMAIL PROTECTED]>
Index: linux-work/arch/powerpc/mm/hugetlbpage.c
===
--- linux-work.orig/arch/powerpc/mm/hugetlbpage.c 2008-07-28
15:57:48.0 +1000
+++ linux-work/arch/powerpc/mm/hugetlbpage.c2008-07-28 15:59:25.0
+1000
@@ -736,14 +736,21 @@ static int __init hugetlbpage_init(void)
if (!cpu_has_feature(CPU_FTR_16M_PAGE))
return -ENODEV;
+
/* Add supported huge page sizes. Need to change HUGE_MAX_HSTATE
* and adjust PTE_NONCACHE_NUM if the number of supported huge page
* sizes changes.
*/
set_huge_psize(MMU_PAGE_16M);
- set_huge_psize(MMU_PAGE_64K);
set_huge_psize(MMU_PAGE_16G);
+ /* Temporarily disable support for 64K huge pages when 64K SPU local
+* store support is enabled as the current implementation conflicts.
+*/
+#ifndef CONFIG_SPU_FS_64K_LS
+ set_huge_psize(MMU_PAGE_64K);
+#endif
+
for (psize = 0; psize < MMU_PAGE_COUNT; ++psize) {
if (mmu_huge_psizes[psize]) {
huge_pgtable_cache(psize) = kmem_cache_create(
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] of: i2c: improve last resort compatible entry selection
In message: <[EMAIL PROTECTED]> "Jon Smirl" <[EMAIL PROTECTED]> writes: : On 7/27/08, Segher Boessenkool <[EMAIL PROTECTED]> wrote: : > > : > > > : > > > > compatible = "atmel,24c32wp", "24c32", "eeprom"; : > > > > : > > > : > > : > : > : > > : > > > I know this is just an example; but to keep thinks clear, the second : > > > and third values in this compatible property are completely bogus (for : > > > device trees). The manufacturer prefix needs to be present and : > > > 'eeprom' is far to vague. : > > > : > > : > > Isn't 24c32 a generic, cross manufacturer term used for these devices? : > > : > : > Sure it is. But "compatible" values are a global namespace so care : > needs to be taken not to cause collisions. One mechanism for that : > is to use vendor prefixes (and that just shifts the problem so it : > is less global); another is to choose good names that have a lower : > chance to collide with the name for another device. And the most : > important way to prevent collisions is to write up a binding, so : > everyone knows you have claimed that name. It still needs to be : > a good name, of course. : > : > : > > What if I have a socket and use a different vendor's chip each week? : > > : > : > You use sockets for your seeproms? Wow :-) But yes, it shouldn't : > be necessary to put the exact make of the device in the device : > tree, for such generic devices. It certainly doesn't hurt to do : > so though (if the exact model is known). : > : > A reasonable "compatible" value would be something like : > "serial-eeprom-24c32". : > You can go a little bit more generic than that, if you write up in : > your binding how the driver should figure out the device size and : > the protocol used. : : Matching on "serial-eeprom-24c32" requires me to convince the at24 : authors to add that string as an alias binding for their driver. How : about "serial-eeprom,24c32" or "generic,24x32"? Many of the serial eeproms have a common way to access them. There's a few organizations of eeproms made by a number of different manufacturers that are actually accessed the same. Warner ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Please pull mpc52xx-next
On Sun, Jul 27, 2008 at 3:48 PM, Grant Likely <[EMAIL PROTECTED]> wrote: > On Fri, Jul 25, 2008 at 10:00 PM, Grant Likely > <[EMAIL PROTECTED]> wrote: >> Hey Ben, here are a few more patches for .27. I would have had this >> stuff in earlier, but they depended on another patch that I didn't >> feel like I should push that was in Andrew's queue. >> >> Grant Likely (4): >> of: adapt of_find_i2c_driver() to be usable by SPI also >> spi: split up spi_new_device() to allow two stage registration. >> spi: Add OF binding support for SPI busses >> powerpc/mpc5200: Add mpc5200-spi (non-PSC) device driver > > Oops, I shouldn't have merged this last one. Please don't pull this > tree yet. I'll fix it up this evening. Okay, I've got it sorted out now. Here is the new pull request: The following changes since commit 024e8ac04453b3525448c31ef39848cf675ba6db: Roland McGrath (1): x86_64: fix ia32 AMD syscall audit fast-path are available in the git repository at: git://git.secretlab.ca/git/linux-2.6-mpc52xx next Grant Likely (3): of: adapt of_find_i2c_driver() to be usable by SPI also spi: split up spi_new_device() to allow two stage registration. spi: Add OF binding support for SPI busses drivers/of/Kconfig |6 ++ drivers/of/Makefile |1 + drivers/of/base.c | 88 ++ drivers/of/of_i2c.c | 64 +- drivers/of/of_spi.c | 93 +++ drivers/spi/spi.c | 139 --- include/linux/of.h |1 + include/linux/of_spi.h | 18 ++ include/linux/spi/spi.h | 12 9 files changed, 317 insertions(+), 105 deletions(-) create mode 100644 drivers/of/of_spi.c create mode 100644 include/linux/of_spi.h -- 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/ibmveth: fix multiple errors with dma_mapping_error conversion
On Mon, 28 Jul 2008, Stephen Rothwell wrote: > I hope that we all can discuss procedures for API changes at the Kernel > Summit ... "all" as in, whoever was invited (the only transparent aspect of was a silly count of # of commits for the initial shortlist), or was on the committee, or bought seats via sponsorship. - James (co- maintainer/author of several kernel subsystems over 8+ years and apparently not invited, because ?) -- James Morris <[EMAIL PROTECTED]> ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
powerpc/powermac: Fixup default serial port device for pmac_zilog
This removes the non-working code in legacy_serial that tried to handle
the powermac SCC ports, and instead add a (now working) function to the
powermac platform code to find the default serial console if any.
Signed-off-by: Benjamin Herrenschmidt <[EMAIL PROTECTED]>
diff --git a/arch/powerpc/kernel/legacy_serial.c
b/arch/powerpc/kernel/legacy_serial.c
index 4d96e1d..bd8c838 100644
--- a/arch/powerpc/kernel/legacy_serial.c
+++ b/arch/powerpc/kernel/legacy_serial.c
@@ -493,18 +493,18 @@ static int __init serial_dev_init(void)
device_initcall(serial_dev_init);
+#ifdef CONFIG_SERIAL_8250_CONSOLE
/*
* This is called very early, as part of console_init() (typically just after
* time_init()). This function is respondible for trying to find a good
* default console on serial ports. It tries to match the open firmware
- * default output with one of the available serial console drivers, either
- * one of the platform serial ports that have been probed earlier by
- * find_legacy_serial_ports() or some more platform specific ones.
+ * default output with one of the available serial console drivers that have
+ * been probed earlier by find_legacy_serial_ports()
*/
static int __init check_legacy_serial_console(void)
{
struct device_node *prom_stdout = NULL;
- int speed = 0, offset = 0;
+ int i, speed = 0, offset = 0;
const char *name;
const u32 *spd;
@@ -548,33 +548,22 @@ static int __init check_legacy_serial_console(void)
if (spd)
speed = *spd;
- if (0)
- ;
-#ifdef CONFIG_SERIAL_8250_CONSOLE
- else if (strcmp(name, "serial") == 0) {
- int i;
- /* Look for it in probed array */
- for (i = 0; i < legacy_serial_count; i++) {
- if (prom_stdout != legacy_serial_infos[i].np)
- continue;
- offset = i;
- speed = legacy_serial_infos[i].speed;
- break;
- }
- if (i >= legacy_serial_count)
- goto not_found;
+ if (strcmp(name, "serial") != 0)
+ goto not_found;
+
+ /* Look for it in probed array */
+ for (i = 0; i < legacy_serial_count; i++) {
+ if (prom_stdout != legacy_serial_infos[i].np)
+ continue;
+ offset = i;
+ speed = legacy_serial_infos[i].speed;
+ break;
}
-#endif /* CONFIG_SERIAL_8250_CONSOLE */
-#ifdef CONFIG_SERIAL_PMACZILOG_CONSOLE
- else if (strcmp(name, "ch-a") == 0)
- offset = 0;
- else if (strcmp(name, "ch-b") == 0)
- offset = 1;
-#endif /* CONFIG_SERIAL_PMACZILOG_CONSOLE */
- else
+ if (i >= legacy_serial_count)
goto not_found;
- of_node_put(prom_stdout);
+ of_node_put(prom_stdout);
+
DBG("Found serial console at ttyS%d\n", offset);
if (speed) {
@@ -591,3 +580,4 @@ static int __init check_legacy_serial_console(void)
}
console_initcall(check_legacy_serial_console);
+#endif /* CONFIG_SERIAL_8250_CONSOLE */
diff --git a/arch/powerpc/platforms/powermac/setup.c
b/arch/powerpc/platforms/powermac/setup.c
index 3163544..88ccf3a 100644
--- a/arch/powerpc/platforms/powermac/setup.c
+++ b/arch/powerpc/platforms/powermac/setup.c
@@ -541,6 +541,78 @@ static int __init pmac_declare_of_platform_devices(void)
}
machine_device_initcall(powermac, pmac_declare_of_platform_devices);
+#ifdef CONFIG_SERIAL_PMACZILOG_CONSOLE
+/*
+ * This is called very early, as part of console_init() (typically just after
+ * time_init()). This function is respondible for trying to find a good
+ * default console on serial ports. It tries to match the open firmware
+ * default output with one of the available serial console drivers.
+ */
+static int __init check_pmac_serial_console(void)
+{
+ struct device_node *prom_stdout = NULL;
+ int offset = 0;
+ const char *name;
+#ifdef CONFIG_SERIAL_PMACZILOG_TTYS
+ char *devname = "ttyS";
+#else
+ char *devname = "ttyPZ";
+#endif
+
+ pr_debug(" -> check_pmac_serial_console()\n");
+
+ /* The user has requested a console so this is already set up. */
+ if (strstr(boot_command_line, "console=")) {
+ pr_debug(" console was specified !\n");
+ return -EBUSY;
+ }
+
+ if (!of_chosen) {
+ pr_debug(" of_chosen is NULL !\n");
+ return -ENODEV;
+ }
+
+ /* We are getting a weird phandle from OF ... */
+ /* ... So use the full path instead */
+ name = of_get_property(of_chosen, "linux,stdout-path", NULL);
+ if (name == NULL) {
+ pr_debug(" no linux,stdout-path !\n");
+ return -ENODEV;
+ }
+ prom_stdout = of_find_node_by_path(name);
+ if (!prom_stdout) {
+ pr_debug(" can't fi
Re: gigantci pages patches
On Sun, 2008-07-27 at 20:17 -0700, Andrew Morton wrote: > s > > OK. Although I'm no longer sure what patches "for the series" refers to. > > I am currently retaining > > powerpc-implement-pte_special.patch > powerpc-implement-pte_special-update.patch > powerpc-lockless-get_user_pages.patch > > and frankly I'm unsure what the status is. I have a note that benh had > concerns about powerpc-lockless-get_user_pages.patch, but iirc they > were waffly and vague ;) > > So I'm thinking I'll stick these patches onto my send-to-ben list. Ok, send the latest ones you have to me, and I'll sort things you. Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: gigantci pages patches
On Mon, 28 Jul 2008 11:07:57 +1000 David Gibson <[EMAIL PROTECTED]> wrote: > On Tue, Jul 22, 2008 at 03:22:36PM -0500, Jon Tollefson wrote: > > David Gibson wrote: > > > On Fri, Jul 11, 2008 at 05:45:15PM +1000, Stephen Rothwell wrote: > > > > > >> Hi all, > > >> > > >> Could people take one last look at these patches and if there are no > > >> issues, please send Ack-bys to Andrew who will push them to Linus for > > >> 2.6.27. > > >> > > >> [PATCH 1/6 v2] allow arch specific function for allocating gigantic pages > > >> http://patchwork.ozlabs.org/linuxppc/patch?&id=18437 > > >> Patch: [PATCH 2/6 v2] powerpc: function for allocating gigantic pages > > >> http://patchwork.ozlabs.org/linuxppc/patch?&id=18438 > > >> Patch: [PATCH 3/6 v2] powerpc: scan device tree and save gigantic page > > >> locations > > >> http://patchwork.ozlabs.org/linuxppc/patch?&id=18439 > > >> Patch: [PATCH 4/6 v2] powerpc: define page support for 16G pages > > >> http://patchwork.ozlabs.org/linuxppc/patch?&id=18440 > > >> Patch: [PATCH 5/6 v2] check for overflow > > >> http://patchwork.ozlabs.org/linuxppc/patch?&id=18441 > > >> Patch: [PATCH 6/6] powerpc: support multiple huge page sizes > > >> http://patchwork.ozlabs.org/linuxppc/patch?&id=18442 > > >> > > > > > > Sorry, I should have looked at these properly when they went past in > > > May, but obviously I missed them. > > > > > > They mostly look ok. I'm a bit confused on 2/6 though - it seems the > > > new powerpc alloc_bootmem_huge_page() function is specific to the 16G > > > gigantic pages. But can't that function also get called for the > > > normal 16M hugepages depending on how the hugepage pool is > > > initialized. > > > > > > Or am I missing something (wouldn't surprise me given my brain's > > > sluggishness today)? > > > > > The alloc_bootmem_huge_page() function is only called for pages >= > > MAX_ORDER. The 16M pages are always allocated within the generic > > hugetlbfs code with alloc_pages_node(). > > Ah, ok. Well, in that case: > > Acked-by: David Gibson <[EMAIL PROTECTED]> > > for the series OK. Although I'm no longer sure what patches "for the series" refers to. I am currently retaining powerpc-implement-pte_special.patch powerpc-implement-pte_special-update.patch powerpc-lockless-get_user_pages.patch and frankly I'm unsure what the status is. I have a note that benh had concerns about powerpc-lockless-get_user_pages.patch, but iirc they were waffly and vague ;) So I'm thinking I'll stick these patches onto my send-to-ben list. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] powerpc/ibmveth: fix multiple errors with dma_mapping_error conversion
On Mon, 28 Jul 2008 11:07:40 +1000 (EST) James Morris <[EMAIL PROTECTED]> wrote: > On Mon, 28 Jul 2008, Stephen Rothwell wrote: > > > I hope that we all can discuss procedures for API changes at the Kernel > > Summit ... > > "all" as in, whoever was invited (the only transparent aspect of was a > silly count of # of commits for the initial shortlist), or was on the > committee, or bought seats via sponsorship. > Yeah. We do all our work via email. If there's some particular issue that we feel cannot be resolved effectively via email then I'd really like to know what that issue is, and why. > - James (co- maintainer/author of several kernel subsystems over 8+ years > and apparently not invited, because ?) - Andrew, who asked everyone two years ago whether we can justify annual kernel summits, and who still awaits a convincing answer. But for this particular problem I don't think there's much to be discussed. It should have been implemented as s/dma_mapping_error/dma_mapping_error2/g with eventual removal of dma_mapping_error(). But I failed to appreciate how many dma_mapping_error()s there are and I failed to predict how many _new_ dma_mapping_error()s would turn up across the -rc phase. So I suck, what's new? otoh, I don't reeealy worry too much about compile errors during the merge window. People get all hot under the collar and shout at each other, but they're trivial to find (the compiler tells you!) and almost always trivial to fix and they are almost always trivially worked around via config if you hit one during a bisect. Shrug, fix them and move on. It's the runtime errors which are far, far, far more of a problem for us. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH v2] leds: make the default trigger name const
The default_trigger fields of struct gpio_led and thus struct led_classdev
are pretty much always assigned from a string literal, which means the
string can't be modified. Which is fine, since there is no reason to
modify the string and in fact it never is.
But they should be marked const to prevent such code from being added, to
prevent warnings if -Wwrite-strings is used and when assigned from a
constant string other than a string literal (which produces a warning under
current kernel compiler flags), and for general good coding practices.
Signed-off-by: Trent Piepho <[EMAIL PROTECTED]>
---
include/linux/leds.h |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/include/linux/leds.h b/include/linux/leds.h
index 519df72..defe693 100644
--- a/include/linux/leds.h
+++ b/include/linux/leds.h
@@ -48,7 +48,7 @@ struct led_classdev {
struct device *dev;
struct list_head node; /* LED Device list */
- char*default_trigger; /* Trigger to use */
+ const char *default_trigger; /* Trigger to use */
#ifdef CONFIG_LEDS_TRIGGERS
/* Protects the trigger data below */
@@ -121,7 +121,7 @@ extern void ledtrig_ide_activity(void);
/* For the leds-gpio driver */
struct gpio_led {
const char *name;
- char *default_trigger;
+ const char *default_trigger;
unsignedgpio;
u8 active_low;
};
--
1.5.4.3
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] powerpc/powermac: Use sane default baudrate for SCC debugging
When using the "sccdbg" option to route early kernel messages and
xmon to the SCC serial port on PowerMacs, when this wasn't the
configured output port of Open Firmware, we initialize the baudrate
to 57600bps. This isn't a very good default on some powermacs where
both the FW and pmac_zilog will default to 38400. This fixes it to
use the same logic as pmac_zilog to pick a default speed.
Signed-off-by: Benjamin Herrenschmidt <[EMAIL PROTECTED]>
diff --git a/arch/powerpc/platforms/powermac/udbg_scc.c
b/arch/powerpc/platforms/powermac/udbg_scc.c
index 47de4d3..572771f 100644
--- a/arch/powerpc/platforms/powermac/udbg_scc.c
+++ b/arch/powerpc/platforms/powermac/udbg_scc.c
@@ -125,13 +125,23 @@ void udbg_scc_init(int force_scc)
out_8(sccc, 0xc0);
/* If SCC was the OF output port, read the BRG value, else
-* Setup for 57600 8N1
+* Setup for 38400 or 57600 8N1 depending on the machine
*/
if (ch_def != NULL) {
out_8(sccc, 13);
scc_inittab[1] = in_8(sccc);
out_8(sccc, 12);
scc_inittab[3] = in_8(sccc);
+ } else if (machine_is_compatible("RackMac1,1")
+ || machine_is_compatible("RackMac1,2")
+ || machine_is_compatible("MacRISC4")) {
+ /* Xserves and G5s default to 57600 */
+ scc_inittab[1] = 0;
+ scc_inittab[3] = 0;
+ } else {
+ /* Others default to 38400 */
+ scc_inittab[1] = 0;
+ scc_inittab[3] = 1;
}
for (i = 0; i < sizeof(scc_inittab); ++i)
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: ide pmac breakage
On Mon, 2008-07-28 at 11:29 +1000, Benjamin Herrenschmidt wrote: > The current ide-pmac upstream is broken. It calls > media_bay_set_ide_infos() with an uninitialized "hwif" argument. > > It's not a trivial mistake, there's a chicken-and-egg problem in the > init code in there. > > I've locally fixed it with this patch that i'll merge via the powerpc > tree unless you have an objection. > > However, the machine crashes when removing the media-bay CD-ROM drive. > > Crash appears to be a NULL deref, possibly in elv_may_queue() though > I don't have a clean backtrace yet, working on it... Here's a backtrace: Vector: 300 (Data Access) at [c58b7b80] pc: c014f264: elv_may_queue+0x10/0x44 lr: c0152750: get_request+0x2c/0x2c0 sp: c58b7c30 msr: 1032 dar: c dsisr: 4000 current = 0xc58aaae0 pid = 854, comm = media-bay enter ? for help mon> t [c58b7c40] c0152750 get_request+0x2c/0x2c0 [c58b7c70] c0152a08 get_request_wait+0x24/0xec [c58b7cc0] c0225674 ide_cd_queue_pc+0x58/0x1a0 [c58b7d40] c022672c ide_cdrom_packet+0x9c/0xdc [c58b7d70] c0261810 cdrom_get_disc_info+0x60/0xd0 [c58b7dc0] c026208c cdrom_mrw_exit+0x1c/0x11c [c58b7e30] c0260f7c unregister_cdrom+0x84/0xe8 [c58b7e50] c022395c ide_cd_release+0x80/0x84 [c58b7e70] c0163650 kref_put+0x54/0x6c [c58b7e80] c0223884 ide_cd_put+0x40/0x5c [c58b7ea0] c0211100 generic_ide_remove+0x28/0x3c [c58b7eb0] c01e9d34 __device_release_driver+0x78/0xb4 [c58b7ec0] c01e9e44 device_release_driver+0x28/0x44 [c58b7ee0] c01e8f7c bus_remove_device+0xac/0xd8 [c58b7f00] c01e7424 device_del+0x104/0x198 [c58b7f20] c01e74d0 device_unregister+0x18/0x30 [c58b7f40] c02121c4 __ide_port_unregister_devices+0x6c/0x88 [c58b7f60] c0212398 ide_port_unregister_devices+0x38/0x80 [c58b7f80] c0208ca4 media_bay_step+0x1cc/0x5c0 [c58b7fb0] c0209124 media_bay_task+0x8c/0xcc [c58b7fd0] c00485c0 kthread+0x48/0x84 [c58b7ff0] c0011b20 kernel_thread+0x44/0x60 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 1/2] leds: make the default trigger name const
On Sun, 27 Jul 2008, Stephen Rothwell wrote: > On Sat, 26 Jul 2008 20:08:57 -0600 Grant Likely <[EMAIL PROTECTED]> wrote: >> On Fri, Jul 25, 2008 at 02:01:44PM -0700, Trent Piepho wrote: >>> The default_trigger fields of struct gpio_led and thus struct led_classdev >>> are pretty much always assigned from a string literal, which means the >>> string can't be modified. Which is fine, since there is no reason to >>> modify the string and in fact it never is. >>> >>> But they should be marked const to prevent such code from being added, to >>> prevent warnings if -Wwrite-strings is used and when assigned from a >>> constant string other than a string literal (which produces a warning under >>> current kernel compiler flags), and for general good coding practices. >>> >>> Signed-off-by: Trent Piepho <[EMAIL PROTECTED]> >> Acked-by: Grant Likely <[EMAIL PROTECTED]> > > I would ack this as well, except I am not sure what tree this patch is > against. In the current powerpc next tree, It was against powerpc next from Jul 22nd, current at the time I made the patch. It looks like that file has changed in the last few days. There is a patch from Anton Vorontsov, "leds: mark led_classdev.default_trigger as const", which adds const to one of the structs I modified, but doesn't get the other one (struct gpio_led). Then another patch from Nate Case added a new LED chip driver, and the platform data for this driver was added as "generic led platform data", which I don't entirely agree with. And this new struct didn't make default_trigger const, probably because it was just copied from the gpio led platform data with some fields removed (so it's not really that generic then, is it?). I'll send an updated patch for current powerpc next. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: mISDN still breaking the allmodconfig build...
David Miller writes:
> From: Marcel Holtmann <[EMAIL PROTECTED]>
> Date: Mon, 28 Jul 2008 03:03:04 +0200
>
> > > More fallout from the premature mISDN driver merge:
> > >
> > > drivers/isdn/hardware/mISDN/hfcmulti.c:5255:2: error: #error "not
> > > running on big endian machines now"
> >
> > is that only the HFC driver or the whole mISDN stack?
> >
> > I know that the two old ISDN stacks where really bad on big endian,
> > but my assumption was that we did sort this out in the end.
>
> One of the two mISDN drivers uses the deprecated virt_to_bus()
> interface for handling DMA addresses (that doesn't even work on many
> x86 systems these days) and the other mISDN driver gives the above
> big-endian compile time error.
>
> In short, this driver was not ready for merging at all.
Why on earth does a generic (I hope) protocol driver (some ISDN
thingy in this case) care about endianess at all?
Or has things come to a "the world's an x86" ("the world's a VAX" for
old-timers but add 25+ years or so) situation where the majority of
coders don't even consider that machines might be different from what
they use? If so, a deep sigh of sadness.
(Not that I prefer a particular endianess. My point being that coders
shouldn't make endianess assumptions unless they're really^3 important.)>
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: mISDN still breaking the allmodconfig build...
Hi Dave, More fallout from the premature mISDN driver merge: drivers/isdn/hardware/mISDN/hfcmulti.c:5255:2: error: #error "not running on big endian machines now" is that only the HFC driver or the whole mISDN stack? I know that the two old ISDN stacks where really bad on big endian, but my assumption was that we did sort this out in the end. Regards Marcel ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: mISDN still breaking the allmodconfig build...
Hi Dave, More fallout from the premature mISDN driver merge: drivers/isdn/hardware/mISDN/hfcmulti.c:5255:2: error: #error "not running on big endian machines now" is that only the HFC driver or the whole mISDN stack? I know that the two old ISDN stacks where really bad on big endian, but my assumption was that we did sort this out in the end. One of the two mISDN drivers uses the deprecated virt_to_bus() interface for handling DMA addresses (that doesn't even work on many x86 systems these days) and the other mISDN driver gives the above big-endian compile time error. In short, this driver was not ready for merging at all. I am not defending it and agree that this driver should have had at least one test run in linux-next. However mISDN is a whole ISDN stack. So does mISDN has an issue too or do we only have a really broken driver. Karsten? Regards Marcel ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
ide pmac breakage
The current ide-pmac upstream is broken. It calls
media_bay_set_ide_infos() with an uninitialized "hwif" argument.
It's not a trivial mistake, there's a chicken-and-egg problem in the
init code in there.
I've locally fixed it with this patch that i'll merge via the powerpc
tree unless you have an objection.
However, the machine crashes when removing the media-bay CD-ROM drive.
Crash appears to be a NULL deref, possibly in elv_may_queue() though
I don't have a clean backtrace yet, working on it...
Cheers,
Ben.
diff --git a/drivers/ide/ppc/pmac.c b/drivers/ide/ppc/pmac.c
index c521bf6..fa2be26 100644
--- a/drivers/ide/ppc/pmac.c
+++ b/drivers/ide/ppc/pmac.c
@@ -1086,6 +1086,11 @@ static int __devinit
pmac_ide_setup_device(pmac_ide_hwif_t *pmif, hw_regs_t *hw)
/* Make sure we have sane timings */
sanitize_timings(pmif);
+ host = ide_host_alloc(&d, hws);
+ if (host == NULL)
+ return -ENOMEM;
+ hwif = host->ports[0];
+
#ifndef CONFIG_PPC64
/* XXX FIXME: Media bay stuff need re-organizing */
if (np->parent && np->parent->name
@@ -1119,11 +1124,11 @@ static int __devinit
pmac_ide_setup_device(pmac_ide_hwif_t *pmif, hw_regs_t *hw)
pmif->mdev ? "macio" : "PCI", pmif->aapl_bus_id,
pmif->mediabay ? " (mediabay)" : "", hw->irq);
- rc = ide_host_add(&d, hws, &host);
- if (rc)
+ rc = ide_host_register(host, &d, hws);
+ if (rc) {
+ ide_host_free(host);
return rc;
-
- hwif = host->ports[0];
+ }
return 0;
}
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: gigantci pages patches
On Tue, Jul 22, 2008 at 03:22:36PM -0500, Jon Tollefson wrote: > David Gibson wrote: > > On Fri, Jul 11, 2008 at 05:45:15PM +1000, Stephen Rothwell wrote: > > > >> Hi all, > >> > >> Could people take one last look at these patches and if there are no > >> issues, please send Ack-bys to Andrew who will push them to Linus for > >> 2.6.27. > >> > >> [PATCH 1/6 v2] allow arch specific function for allocating gigantic pages > >> http://patchwork.ozlabs.org/linuxppc/patch?&id=18437 > >> Patch: [PATCH 2/6 v2] powerpc: function for allocating gigantic pages > >> http://patchwork.ozlabs.org/linuxppc/patch?&id=18438 > >> Patch: [PATCH 3/6 v2] powerpc: scan device tree and save gigantic page > >> locations > >> http://patchwork.ozlabs.org/linuxppc/patch?&id=18439 > >> Patch: [PATCH 4/6 v2] powerpc: define page support for 16G pages > >> http://patchwork.ozlabs.org/linuxppc/patch?&id=18440 > >> Patch: [PATCH 5/6 v2] check for overflow > >> http://patchwork.ozlabs.org/linuxppc/patch?&id=18441 > >> Patch: [PATCH 6/6] powerpc: support multiple huge page sizes > >> http://patchwork.ozlabs.org/linuxppc/patch?&id=18442 > >> > > > > Sorry, I should have looked at these properly when they went past in > > May, but obviously I missed them. > > > > They mostly look ok. I'm a bit confused on 2/6 though - it seems the > > new powerpc alloc_bootmem_huge_page() function is specific to the 16G > > gigantic pages. But can't that function also get called for the > > normal 16M hugepages depending on how the hugepage pool is > > initialized. > > > > Or am I missing something (wouldn't surprise me given my brain's > > sluggishness today)? > > > The alloc_bootmem_huge_page() function is only called for pages >= > MAX_ORDER. The 16M pages are always allocated within the generic > hugetlbfs code with alloc_pages_node(). Ah, ok. Well, in that case: Acked-by: David Gibson <[EMAIL PROTECTED]> for the series. -- 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: mISDN still breaking the allmodconfig build...
From: Marcel Holtmann <[EMAIL PROTECTED]> Date: Mon, 28 Jul 2008 03:03:04 +0200 > > More fallout from the premature mISDN driver merge: > > > > drivers/isdn/hardware/mISDN/hfcmulti.c:5255:2: error: #error "not > > running on big endian machines now" > > is that only the HFC driver or the whole mISDN stack? > > I know that the two old ISDN stacks where really bad on big endian, > but my assumption was that we did sort this out in the end. One of the two mISDN drivers uses the deprecated virt_to_bus() interface for handling DMA addresses (that doesn't even work on many x86 systems these days) and the other mISDN driver gives the above big-endian compile time error. In short, this driver was not ready for merging at all. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: mISDN still breaking the allmodconfig build...
On Mon, 28 Jul 2008 10:13:42 +1000 "Benjamin Herrenschmidt" <[EMAIL PROTECTED]> wrote: > On Sun, 2008-07-27 at 17:02 -0700, David Miller wrote: > > More fallout from the premature mISDN driver merge: > > > > drivers/isdn/hardware/mISDN/hfcmulti.c:5255:2: error: #error "not > > running on big endian machines now" > > Lovely... mISDN is notoriously bad on big endian machines. Cheers, Sean ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] powerpc/ibmveth: fix multiple errors with dma_mapping_error conversion
Hi Andrew, On Sun, 27 Jul 2008 12:24:14 -0700 Andrew Morton <[EMAIL PROTECTED]> wrote: > > On Mon, 28 Jul 2008 02:14:24 +1000 Stephen Rothwell <[EMAIL PROTECTED]> wrote: > > > The addition of an argument to dma_mapping_error() in commit > > 8d8bb39b9eba32dd70e87fd5ad5c5dd4ba118e06 "dma-mapping: add the device > > argument to dma_mapping_error()" left a bit of fallout: > > Yeah, sorry, that patch was a horror - I fixed it perhaps ten times. I > think people were madly adding new dma_mapping_error() calls while we > were trying to maintain it as well. > > It should have been dome as a two-stage conversion. Yes, indeed (my new favourite word :-)) I hope that we all can discuss procedures for API changes at the Kernel Summit ... -- Cheers, Stephen Rothwell[EMAIL PROTECTED] http://www.canb.auug.org.au/~sfr/ pgpnaVeodLzFW.pgp Description: PGP signature ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] isdn: mISDN HFC PCI support depends on virt_to_bus()
Hi Sean, On Sun, 27 Jul 2008 13:39:18 -0400 Sean MacLennan <[EMAIL PROTECTED]> wrote: > > On Mon, 28 Jul 2008 02:37:32 +1000 > "Stephen Rothwell" <[EMAIL PROTECTED]> wrote: > > > On powerpc (allyesconfig build) we get this error: > > > > drivers/isdn/hardware/mISDN/hfcpci.c:1991: error: implicit > > declaration of function 'virt_to_bus' > > When did mISDN make it into the kernel? And which kernel tree is it in? > I don't see it in the Linux next tree Its not in linux-next (will be today). It went straight into Linus' tree late last week. > I am very interested since we are trying to get mISDN working on the > Warp. There was no notice that they got 2.6.26 compiling. It won't even build on powerpc64, powercp32 should at least build. -- Cheers, Stephen Rothwell[EMAIL PROTECTED] http://www.canb.auug.org.au/~sfr/ pgphj9SXyWJry.pgp Description: PGP signature ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] isdn: mISDN HFC PCI support depends on virt_to_bus()
Hi Dave, On Sun, 27 Jul 2008 16:14:32 -0700 (PDT) David Miller <[EMAIL PROTECTED]> wrote: > > The driver went directly into Linus's tree. > > Stephen hit the build problem once he synced linux-next up with > Linus's current tree. It didn't even get as far as linux-next, I was just browsing the bloodbath that is/was Linus' tree (http://kisskb.ellerman.id.au/kisskb/branch/3/) :-(. -- Cheers, Stephen Rothwell[EMAIL PROTECTED] http://www.canb.auug.org.au/~sfr/ pgpqLy3X1qfwa.pgp Description: PGP signature ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] isdn: mISDN HFC PCI support depends on virt_to_bus()
Hi Sam, On Sun, 27 Jul 2008 22:43:55 +0200 Sam Ravnborg <[EMAIL PROTECTED]> wrote: > > On Sun, Jul 27, 2008 at 01:33:49PM -0700, Roland Dreier wrote: > > > IMHO, this driver was really rushed in and that was a huge mistake. > > > If it had gone through linux-next we could have tidied all of this > > > stuff up in a less "rushed" manner. > > > > ?? This thread *is* about a build failure in linux-next. > mISDN are in -linus which is part of -next and Stephens point is that if > we have had mISDN in -next then this would have been fixed before hitting > -linus. Dave made that point, not me. -- Cheers, Stephen Rothwell[EMAIL PROTECTED] http://www.canb.auug.org.au/~sfr/ pgpqniPdks7Uk.pgp Description: PGP signature ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] isdn: mISDN HFC PCI support depends on virt_to_bus()
Hi Roland, On Sun, 27 Jul 2008 13:33:49 -0700 Roland Dreier <[EMAIL PROTECTED]> wrote: > > > IMHO, this driver was really rushed in and that was a huge mistake. > > If it had gone through linux-next we could have tidied all of this > > stuff up in a less "rushed" manner. > > ?? This thread *is* about a build failure in linux-next. I noticed this in Linus' tree ... I did not mention linux-next. -- Cheers, Stephen Rothwell[EMAIL PROTECTED] http://www.canb.auug.org.au/~sfr/ pgpEsY0DSMz7F.pgp Description: PGP signature ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] isdn: mISDN HFC PCI support depends on virt_to_bus()
On Sun, 27 Jul 2008 18:27:09 +0100 Alan Cox <[EMAIL PROTECTED]> wrote: > > On Mon, 28 Jul 2008 02:37:32 +1000 Stephen Rothwell <[EMAIL PROTECTED]> wrote: > > > On powerpc (allyesconfig build) we get this error: > > > > drivers/isdn/hardware/mISDN/hfcpci.c:1991: error: implicit declaration of > > function 'virt_to_bus' > > > > Signed-off-by: Stephen Rothwell <[EMAIL PROTECTED]> > > Can we please not merge new virt_to_bus users and instead fix the actual > code to use the right functions? Absolutely. But I currently just want my trees to build (I am a bear of little brain with simple needs :-)) -- Cheers, Stephen Rothwell[EMAIL PROTECTED] http://www.canb.auug.org.au/~sfr/ pgpOvxtLWzqsE.pgp Description: PGP signature ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: mISDN still breaking the allmodconfig build...
On Sun, 2008-07-27 at 17:02 -0700, David Miller wrote: > More fallout from the premature mISDN driver merge: > > drivers/isdn/hardware/mISDN/hfcmulti.c:5255:2: error: #error "not running on > big endian machines now" Lovely... Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
mISDN still breaking the allmodconfig build...
More fallout from the premature mISDN driver merge: drivers/isdn/hardware/mISDN/hfcmulti.c:5255:2: error: #error "not running on big endian machines now" ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] isdn: mISDN HFC PCI support depends on virt_to_bus()
From: Roland Dreier <[EMAIL PROTECTED]> Date: Sun, 27 Jul 2008 13:33:49 -0700 > > IMHO, this driver was really rushed in and that was a huge mistake. > > If it had gone through linux-next we could have tidied all of this > > stuff up in a less "rushed" manner. > > ?? This thread *is* about a build failure in linux-next. The driver went directly into Linus's tree. Stephen hit the build problem once he synced linux-next up with Linus's current tree. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [spi-devel-general] [PATCH 1/4] [SPI] [POWERPC] spi_mpc83xx: handles Freescale MPC8610 as well
On Friday 16 May 2008, Scott Wood wrote: > On Fri, May 16, 2008 at 08:50:52PM +0400, Anton Vorontsov wrote: > > config SPI_MPC83xx > > tristate "Freescale MPC83xx/QUICC Engine SPI controller" > > - depends on SPI_MASTER && (PPC_83xx || QUICC_ENGINE) && EXPERIMENTAL > > + depends on SPI_MASTER && (PPC_83xx || QUICC_ENGINE || PPC_86xx) && > > EXPERIMENTAL > > How about "depends on SPI_MASTER && FSL_SOC && EXPERIMENTAL"? > > Plus, we should change the option text to something like "MPC8xxx SPI > controller". Is there an approved-by-powerpc-folk version of this patch yet? (Noting that SPI_MASTER is now implicit ...) ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] of: i2c: improve last resort compatible entry selection
On 7/27/08, Segher Boessenkool <[EMAIL PROTECTED]> wrote: > > > > > > > > > compatible = "atmel,24c32wp", "24c32", "eeprom"; > > > > > > > > > > > > > > > > I know this is just an example; but to keep thinks clear, the second > > > and third values in this compatible property are completely bogus (for > > > device trees). The manufacturer prefix needs to be present and > > > 'eeprom' is far to vague. > > > > > > > Isn't 24c32 a generic, cross manufacturer term used for these devices? > > > > Sure it is. But "compatible" values are a global namespace so care > needs to be taken not to cause collisions. One mechanism for that > is to use vendor prefixes (and that just shifts the problem so it > is less global); another is to choose good names that have a lower > chance to collide with the name for another device. And the most > important way to prevent collisions is to write up a binding, so > everyone knows you have claimed that name. It still needs to be > a good name, of course. > > > > What if I have a socket and use a different vendor's chip each week? > > > > You use sockets for your seeproms? Wow :-) But yes, it shouldn't > be necessary to put the exact make of the device in the device > tree, for such generic devices. It certainly doesn't hurt to do > so though (if the exact model is known). > > A reasonable "compatible" value would be something like > "serial-eeprom-24c32". > You can go a little bit more generic than that, if you write up in > your binding how the driver should figure out the device size and > the protocol used. Matching on "serial-eeprom-24c32" requires me to convince the at24 authors to add that string as an alias binding for their driver. How about "serial-eeprom,24c32" or "generic,24x32"? > > > eeprom is the vague Linuxism that at24 is attempting to correct. > > eeprom just goes and searches for anything resembling an eeprom. It > > will trigger on chips that aren't eeproms. > > > > Yeah. And no driver should need to probe _anything_ if it has a > device tree node describing the device -- certainly it shouldn't > probe for what kind of device it is! > > > Segher > > -- Jon Smirl [EMAIL PROTECTED] ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] of: i2c: improve last resort compatible entry selection
compatible = "atmel,24c32wp", "24c32", "eeprom"; I know this is just an example; but to keep thinks clear, the second and third values in this compatible property are completely bogus (for device trees). The manufacturer prefix needs to be present and 'eeprom' is far to vague. Isn't 24c32 a generic, cross manufacturer term used for these devices? Sure it is. But "compatible" values are a global namespace so care needs to be taken not to cause collisions. One mechanism for that is to use vendor prefixes (and that just shifts the problem so it is less global); another is to choose good names that have a lower chance to collide with the name for another device. And the most important way to prevent collisions is to write up a binding, so everyone knows you have claimed that name. It still needs to be a good name, of course. What if I have a socket and use a different vendor's chip each week? You use sockets for your seeproms? Wow :-) But yes, it shouldn't be necessary to put the exact make of the device in the device tree, for such generic devices. It certainly doesn't hurt to do so though (if the exact model is known). A reasonable "compatible" value would be something like "serial-eeprom-24c32". You can go a little bit more generic than that, if you write up in your binding how the driver should figure out the device size and the protocol used. eeprom is the vague Linuxism that at24 is attempting to correct. eeprom just goes and searches for anything resembling an eeprom. It will trigger on chips that aren't eeproms. Yeah. And no driver should need to probe _anything_ if it has a device tree node describing the device -- certainly it shouldn't probe for what kind of device it is! Segher ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH v3 0/4 REPOST] OF infrastructure for SPI devices
On Friday 25 July 2008, Grant Likely wrote: > I don't know what to do with these patches. I'd really like to see them > in .27, and now that akpm has cleared his queue, the prerequisite patch > has been merged so they are ready to go in. However, even though there > has been favourable reception on the SPI and linuxppc lists for these > changes I don't have any acks from anybody yet. > > David, can you please reply on if you are okay with these patches > getting merged? If so, do you want me to merge them via my tree, or > do you want to pick them up? OK ... to recap, #1 and #3 are OF-specific, I'll be agnostic. If other OF folk think it's OK, great. Some cleanup was needed for #2, but it was basically ok ... I'd like to see the final version, and if it goes via an OF push that's OK by me. (Though I'd like to see that change make it into 2.6.27 regardless, so let me know.) And #4 isn't quite cooked yet. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Please pull mpc52xx-next
On Fri, Jul 25, 2008 at 10:00 PM, Grant Likely <[EMAIL PROTECTED]> wrote: > Hey Ben, here are a few more patches for .27. I would have had this > stuff in earlier, but they depended on another patch that I didn't > feel like I should push that was in Andrew's queue. > > Grant Likely (4): > of: adapt of_find_i2c_driver() to be usable by SPI also > spi: split up spi_new_device() to allow two stage registration. > spi: Add OF binding support for SPI busses > powerpc/mpc5200: Add mpc5200-spi (non-PSC) device driver Oops, I shouldn't have merged this last one. Please don't pull this tree yet. I'll fix it up this evening. 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 v3 4/4] powerpc/mpc5200: Add mpc5200-spi (non-PSC) device driver
On Friday 25 July 2008, Grant Likely wrote:
> From: Grant Likely <[EMAIL PROTECTED]>
>
> Adds support for the dedicated SPI device on the Freescale MPC5200(b)
> SoC.
It'd be a bit more clear if you said dedicated SPI "controller";
"device" sounds like it's a "struct spi_device".
Capsule summary: fault handling needs work. (Details below.)
> Signed-off-by: Grant Likely <[EMAIL PROTECTED]>
> ---
>
> drivers/spi/Kconfig |8 +
> drivers/spi/Makefile|1
> drivers/spi/mpc52xx_spi.c | 595
> +++
> include/linux/spi/mpc52xx_spi.h | 10 +
> 4 files changed, 614 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/spi/Kconfig b/drivers/spi/Kconfig
> index 2303521..68e4a4a 100644
> --- a/drivers/spi/Kconfig
> +++ b/drivers/spi/Kconfig
> @@ -116,6 +116,14 @@ config SPI_LM70_LLP
> which interfaces to an LM70 temperature sensor using
> a parallel port.
>
> +config SPI_MPC52xx
> + tristate "Freescale MPC52xx SPI (non-PSC) controller support"
> + depends on PPC_MPC52xx && SPI
> + select SPI_MASTER_OF
> + help
> + This drivers supports the MPC52xx SPI controller in master SPI
> + mode.
> +
> config SPI_MPC52xx_PSC
> tristate "Freescale MPC52xx PSC SPI controller"
> depends on PPC_MPC52xx && EXPERIMENTAL
> diff --git a/drivers/spi/Makefile b/drivers/spi/Makefile
> index 7fca043..340b878 100644
> --- a/drivers/spi/Makefile
> +++ b/drivers/spi/Makefile
> @@ -22,6 +22,7 @@ obj-$(CONFIG_SPI_PXA2XX)+= pxa2xx_spi.o
> obj-$(CONFIG_SPI_OMAP_UWIRE) += omap_uwire.o
> obj-$(CONFIG_SPI_OMAP24XX) += omap2_mcspi.o
> obj-$(CONFIG_SPI_MPC52xx_PSC)+= mpc52xx_psc_spi.o
> +obj-$(CONFIG_SPI_MPC52xx)+= mpc52xx_spi.o
> obj-$(CONFIG_SPI_MPC83xx)+= spi_mpc83xx.o
> obj-$(CONFIG_SPI_S3C24XX_GPIO) += spi_s3c24xx_gpio.o
> obj-$(CONFIG_SPI_S3C24XX)+= spi_s3c24xx.o
> diff --git a/drivers/spi/mpc52xx_spi.c b/drivers/spi/mpc52xx_spi.c
> new file mode 100644
> index 000..453690f
> --- /dev/null
> +++ b/drivers/spi/mpc52xx_spi.c
> @@ -0,0 +1,595 @@
> +/*
> + * MPC52xx SPI master driver.
> + * Copyright (C) 2008 Secret Lab Technologies Ltd.
> + *
> + * This is the driver for the MPC5200's dedicated SPI device (not for a
> + * PSC in SPI mode)
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +MODULE_AUTHOR("Grant Likely <[EMAIL PROTECTED]>");
> +MODULE_DESCRIPTION("MPC52xx SPI (non-PSC) Driver");
> +MODULE_LICENSE("GPL");
> +
> +/* Register offsets */
> +#define SPI_CTRL10x00
> +#define SPI_CTRL1_SPIE (1 << 7)
> +#define SPI_CTRL1_SPE(1 << 6)
> +#define SPI_CTRL1_MSTR (1 << 4)
> +#define SPI_CTRL1_CPOL (1 << 3)
> +#define SPI_CTRL1_CPHA (1 << 2)
> +#define SPI_CTRL1_SSOE (1 << 1)
> +#define SPI_CTRL1_LSBFE (1 << 0)
> +
> +#define SPI_CTRL20x01
> +#define SPI_BRR 0x04
> +
> +#define SPI_STATUS 0x05
> +#define SPI_STATUS_SPIF (1 << 7)
> +#define SPI_STATUS_WCOL (1 << 6)
> +#define SPI_STATUS_MODF (1 << 4)
> +
> +#define SPI_DATA 0x09
> +#define SPI_PORTDATA 0x0d
> +#define SPI_DATADIR 0x10
> +
> +/* FSM state return values */
> +#define FSM_STOP 0
> +#define FSM_POLL 1
> +#define FSM_CONTINUE 2
> +
> +/* Driver internal data */
> +struct mpc52xx_spi {
> + struct spi_master *master;
> + u32 sysclk;
> + void __iomem *regs;
> + int irq0; /* MODF irq */
> + int irq1; /* SPIF irq */
> + int ipb_freq;
> +
> + /* Statistics */
> + int msg_count;
> + int wcol_count;
> + int wcol_ticks;
> + u32 wcol_tx_timestamp;
> + int modf_count;
> + int byte_count;
> +
> + /* Hooks for platform modification of behaviour */
> + void (*premessage)(struct spi_message *m, void *context);
> + void *premessage_context;
> +
> + struct list_head queue; /* queue of pending messages */
> + spinlock_t lock;
> + struct work_struct work;
> +
> +
> + /* Details of current transfer (length, and buffer pointers) */
> + struct spi_message *message;/* current message */
> + struct spi_transfer *transfer; /* current transfer */
> + int (*state)(int irq, struct mpc52xx_spi *ms, u8 status, u8 data);
> + int len;
> + int timestamp;
> + u8 *rx_buf;
> + const u8 *tx_buf;
> + int cs_change;
> +};
> +
> +/*
> + * CS control function
> + */
> +static void mpc52xx_spi_chipsel(struct mpc52xx_spi *ms, int value)
> +{
> + if (value)
> + writeb(0, ms->regs + SPI_PORTDATA); /* Assert SS pin */
> + else
> + writeb(0x08, ms->regs + SPI_PORTDATA); /* Deassert SS pin */
> +}
> +
> +/*
> + * Start a new transfe
Re: [PATCH] powerpc/mpc5200: Fix locking on mpc52xx_spi driver
Applying patch mpc52xx-spi-fix0.patch
patching file drivers/spi/mpc52xx_spi.c
Hunk #1 FAILED at 149.
Hunk #2 succeeded at 154 (offset -7 lines).
Hunk #3 succeeded at 311 (offset -7 lines).
1 out of 3 hunks FAILED -- rejects in file drivers/spi/mpc52xx_spi.c
Patch mpc52xx-spi-fix0.patch does not apply (enforce with -f)
... looks like chunk #1 was against something other than
what you posted, and was partly reversed ..
> +static irqreturn_t mpc52xx_spi_irq(int irq, void *_ms)
> +{
> + struct mpc52xx_spi *ms = _ms;
> + spin_lock(&ms->lock);
Blank line after variable declaration blocks please ... and
also, since you're not using IRQF_DISABLED when you request
this IRQ, you've got locking trouble here. Either specify
IRQF_DISABLED (my preference) or use spin_lock_irqsave().
> + mpc52xx_spi_fsm_process(irq, ms);
> + spin_unlock(&ms->lock);
> return IRQ_HANDLED;
> }
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] isdn: mISDN HFC PCI support depends on virt_to_bus()
On Sun, Jul 27, 2008 at 01:33:49PM -0700, Roland Dreier wrote: > > IMHO, this driver was really rushed in and that was a huge mistake. > > If it had gone through linux-next we could have tidied all of this > > stuff up in a less "rushed" manner. > > ?? This thread *is* about a build failure in linux-next. mISDN are in -linus which is part of -next and Stephens point is that if we have had mISDN in -next then this would have been fixed before hitting -linus. Maybe Karsten should use davem as gateway as he has anyway been so for other isdn patches lately? Sam ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] isdn: mISDN HFC PCI support depends on virt_to_bus()
> IMHO, this driver was really rushed in and that was a huge mistake. > If it had gone through linux-next we could have tidied all of this > stuff up in a less "rushed" manner. ?? This thread *is* about a build failure in linux-next. - R. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] isdn: mISDN HFC PCI support depends on virt_to_bus()
From: Alan Cox <[EMAIL PROTECTED]> Date: Sun, 27 Jul 2008 18:27:09 +0100 > On Mon, 28 Jul 2008 02:37:32 +1000 > Stephen Rothwell <[EMAIL PROTECTED]> wrote: > > > On powerpc (allyesconfig build) we get this error: > > > > drivers/isdn/hardware/mISDN/hfcpci.c:1991: error: implicit declaration of > > function 'virt_to_bus' > > > > Signed-off-by: Stephen Rothwell <[EMAIL PROTECTED]> > > Can we please not merge new virt_to_bus users and instead fix the actual > code to use the right functions? Yes, please. IMHO, this driver was really rushed in and that was a huge mistake. If it had gone through linux-next we could have tidied all of this stuff up in a less "rushed" manner. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] powerpc/ibmveth: fix multiple errors with dma_mapping_error conversion
On Mon, 28 Jul 2008 02:14:24 +1000 Stephen Rothwell <[EMAIL PROTECTED]> wrote: > The addition of an argument to dma_mapping_error() in commit > 8d8bb39b9eba32dd70e87fd5ad5c5dd4ba118e06 "dma-mapping: add the device > argument to dma_mapping_error()" left a bit of fallout: Yeah, sorry, that patch was a horror - I fixed it perhaps ten times. I think people were madly adding new dma_mapping_error() calls while we were trying to maintain it as well. It should have been dome as a two-stage conversion. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] isdn: mISDN HFC PCI support depends on virt_to_bus()
On Mon, 28 Jul 2008 02:37:32 +1000 Stephen Rothwell <[EMAIL PROTECTED]> wrote: > On powerpc (allyesconfig build) we get this error: > > drivers/isdn/hardware/mISDN/hfcpci.c:1991: error: implicit declaration of > function 'virt_to_bus' > > Signed-off-by: Stephen Rothwell <[EMAIL PROTECTED]> Can we please not merge new virt_to_bus users and instead fix the actual code to use the right functions? ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] isdn: mISDN HFC PCI support depends on virt_to_bus()
On Mon, 28 Jul 2008 02:37:32 +1000 "Stephen Rothwell" <[EMAIL PROTECTED]> wrote: > On powerpc (allyesconfig build) we get this error: > > drivers/isdn/hardware/mISDN/hfcpci.c:1991: error: implicit > declaration of function 'virt_to_bus' When did mISDN make it into the kernel? And which kernel tree is it in? I don't see it in the Linux next tree I am very interested since we are trying to get mISDN working on the Warp. There was no notice that they got 2.6.26 compiling. Cheers, Sean ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] powerpc: Use new printk extension %pS to print symbols on oops
On Sun, 27 Jul 2008, David Woodhouse wrote: > > Out of interest, why is it %pS and not %Sp? Shouldn't the modifier come > first? What if we want to print a pointer immediately followed by a > capital S? Try it. Linus ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] isdn: mISDN HFC PCI support depends on virt_to_bus()
On powerpc (allyesconfig build) we get this error: drivers/isdn/hardware/mISDN/hfcpci.c:1991: error: implicit declaration of function 'virt_to_bus' Signed-off-by: Stephen Rothwell <[EMAIL PROTECTED]> --- drivers/isdn/hardware/mISDN/Kconfig |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/drivers/isdn/hardware/mISDN/Kconfig b/drivers/isdn/hardware/mISDN/Kconfig index 1479348..9cd5f5f 100644 --- a/drivers/isdn/hardware/mISDN/Kconfig +++ b/drivers/isdn/hardware/mISDN/Kconfig @@ -7,6 +7,7 @@ config MISDN_HFCPCI tristate "Support for HFC PCI cards" depends on MISDN depends on PCI + depends on VIRT_TO_BUS help Enable support for cards with Cologne Chip AG's HFC PCI chip. -- 1.5.6.3 -- Cheers, Stephen Rothwell[EMAIL PROTECTED] http://www.canb.auug.org.au/~sfr/ ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] powerpc/vio: more fallout from dma_mapping_error API change
arch/powerpc/kernel/vio.c:533: error: too few arguments to function
'dma_mapping_error'
Signed-off-by: Stephen Rothwell <[EMAIL PROTECTED]>
---
arch/powerpc/kernel/vio.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
Compile tested for ppc64_defconfig.
diff --git a/arch/powerpc/kernel/vio.c b/arch/powerpc/kernel/vio.c
index ade8aea..49a166d 100644
--- a/arch/powerpc/kernel/vio.c
+++ b/arch/powerpc/kernel/vio.c
@@ -530,7 +530,7 @@ static dma_addr_t vio_dma_iommu_map_single(struct device
*dev, void *vaddr,
}
ret = dma_iommu_ops.map_single(dev, vaddr, size, direction, attrs);
- if (unlikely(dma_mapping_error(ret))) {
+ if (unlikely(dma_mapping_error(dev, ret))) {
vio_cmo_dealloc(viodev, roundup(size, IOMMU_PAGE_SIZE));
atomic_inc(&viodev->cmo.allocs_failed);
}
--
1.5.6.3
--
Cheers,
Stephen Rothwell[EMAIL PROTECTED]
http://www.canb.auug.org.au/~sfr/
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] powerpc/ibmveth: fix multiple errors with dma_mapping_error conversion
The addition of an argument to dma_mapping_error() in commit
8d8bb39b9eba32dd70e87fd5ad5c5dd4ba118e06 "dma-mapping: add the device
argument to dma_mapping_error()" left a bit of fallout:
drivers/net/ibmveth.c:263: error: too few arguments to function
'dma_mapping_error'
drivers/net/ibmveth.c:264: error: expected ')' before 'goto'
drivers/net/ibmveth.c:284: error: expected expression before '}' token
drivers/net/ibmveth.c:297: error: too few arguments to function
'dma_mapping_error'
drivers/net/ibmveth.c:298: error: expected ')' before 'dma_unmap_single'
drivers/net/ibmveth.c:306: error: expected expression before '}' token
drivers/net/ibmveth.c:491: error: too few arguments to function
'dma_mapping_error'
drivers/net/ibmveth.c:927: error: too few arguments to function
'dma_mapping_error'
drivers/net/ibmveth.c:927: error: expected ')' before '{' token
drivers/net/ibmveth.c:974: error: expected expression before '}' token
drivers/net/ibmveth.c:914: error: label 'out' used but not defined m
Signed-off-by: Stephen Rothwell <[EMAIL PROTECTED]>
---
drivers/net/ibmveth.c |8
1 files changed, 4 insertions(+), 4 deletions(-)
Compiler tested for ppc64_defconfig.
diff --git a/drivers/net/ibmveth.c b/drivers/net/ibmveth.c
index 91ec9fd..a03fe1f 100644
--- a/drivers/net/ibmveth.c
+++ b/drivers/net/ibmveth.c
@@ -260,7 +260,7 @@ static void ibmveth_replenish_buffer_pool(struct
ibmveth_adapter *adapter, struc
dma_addr = dma_map_single(&adapter->vdev->dev, skb->data,
pool->buff_size, DMA_FROM_DEVICE);
- if (dma_mapping_error((&adapter->vdev->dev, dma_addr))
+ if (dma_mapping_error(&adapter->vdev->dev, dma_addr))
goto failure;
pool->free_map[free_index] = IBM_VETH_INVALID_MAP;
@@ -294,7 +294,7 @@ failure:
pool->consumer_index = pool->size - 1;
else
pool->consumer_index--;
- if (!dma_mapping_error((&adapter->vdev->dev, dma_addr))
+ if (!dma_mapping_error(&adapter->vdev->dev, dma_addr))
dma_unmap_single(&adapter->vdev->dev,
pool->dma_addr[index], pool->buff_size,
DMA_FROM_DEVICE);
@@ -488,7 +488,7 @@ static void ibmveth_cleanup(struct ibmveth_adapter *adapter)
&adapter->rx_buff_pool[i]);
if (adapter->bounce_buffer != NULL) {
- if (!dma_mapping_error(adapter->bounce_buffer_dma)) {
+ if (!dma_mapping_error(dev, adapter->bounce_buffer_dma)) {
dma_unmap_single(&adapter->vdev->dev,
adapter->bounce_buffer_dma,
adapter->netdev->mtu + IBMVETH_BUFF_OH,
@@ -924,7 +924,7 @@ static int ibmveth_start_xmit(struct sk_buff *skb, struct
net_device *netdev)
buf[1] = 0;
}
- if (dma_mapping_error((&adapter->vdev->dev, data_dma_addr)) {
+ if (dma_mapping_error(&adapter->vdev->dev, data_dma_addr)) {
if (!firmware_has_feature(FW_FEATURE_CMO))
ibmveth_error_printk("tx: unable to map xmit buffer\n");
skb_copy_from_linear_data(skb, adapter->bounce_buffer,
--
1.5.6.3
--
Cheers,
Stephen Rothwell[EMAIL PROTECTED]
http://www.canb.auug.org.au/~sfr/
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] powerpc/cmo: fix sysdev attribute API change fallout
Noticed due to these wanings:
arch/powerpc/platforms/pseries/cmm.c:298: warning: initialization from
incompatible pointer type
arch/powerpc/platforms/pseries/cmm.c:299: warning: initialization from
incompatible pointer type
arch/powerpc/platforms/pseries/cmm.c:320: warning: initialization from
incompatible pointer type
arch/powerpc/platforms/pseries/cmm.c:320: warning: initialization from
incompatible pointer type
Signed-off-by: Stephen Rothwell <[EMAIL PROTECTED]>
---
arch/powerpc/platforms/pseries/cmm.c |8 ++--
1 files changed, 6 insertions(+), 2 deletions(-)
Only build tested with ppc64_defconfig.
diff --git a/arch/powerpc/platforms/pseries/cmm.c
b/arch/powerpc/platforms/pseries/cmm.c
index c6b3be0..38fe32a 100644
--- a/arch/powerpc/platforms/pseries/cmm.c
+++ b/arch/powerpc/platforms/pseries/cmm.c
@@ -289,7 +289,9 @@ static int cmm_thread(void *dummy)
}
#define CMM_SHOW(name, format, args...)\
- static ssize_t show_##name(struct sys_device *dev, char *buf) \
+ static ssize_t show_##name(struct sys_device *dev, \
+ struct sysdev_attribute *attr, \
+ char *buf) \
{ \
return sprintf(buf, format, ##args);\
} \
@@ -298,12 +300,14 @@ static int cmm_thread(void *dummy)
CMM_SHOW(loaned_kb, "%lu\n", PAGES2KB(loaned_pages));
CMM_SHOW(loaned_target_kb, "%lu\n", PAGES2KB(loaned_pages_target));
-static ssize_t show_oom_pages(struct sys_device *dev, char *buf)
+static ssize_t show_oom_pages(struct sys_device *dev,
+ struct sysdev_attribute *attr, char *buf)
{
return sprintf(buf, "%lu\n", PAGES2KB(oom_freed_pages));
}
static ssize_t store_oom_pages(struct sys_device *dev,
+ struct sysdev_attribute *attr,
const char *buf, size_t count)
{
unsigned long val = simple_strtoul (buf, NULL, 10);
--
1.5.6.3
--
Cheers,
Stephen Rothwell[EMAIL PROTECTED]
http://www.canb.auug.org.au/~sfr/
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] Fix powerpc64 build if CONFIG_EPOLL=n
Hi Jimi, On Sun, 27 Jul 2008 08:48:09 -0400 Jimi Xenidis <[EMAIL PROTECTED]> wrote: > > Declate compat_sys_epoll_pwait as a conditional syscall like the rest > of the epoll interfaces. > We could have put an #ifdef around the entry in include/asm-powerpc/ > systbl.h, but IMHO this is ultimately correct patch. Already in Linus' tree - commit 5f17156fc55abac476d180e480bedb0f07f01b14 "Fix build on COMPAT platforms when CONFIG_EPOLL is disabled" -- Cheers, Stephen Rothwell[EMAIL PROTECTED] http://www.canb.auug.org.au/~sfr/ pgpbJ2O4RPiIE.pgp Description: PGP signature ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] of: i2c: improve last resort compatible entry selection
On 7/27/08, Grant Likely <[EMAIL PROTECTED]> wrote: > On Sun, Jul 27, 2008 at 1:05 AM, Jon Smirl <[EMAIL PROTECTED]> wrote: > > On 7/26/08, Grant Likely <[EMAIL PROTECTED]> wrote: > >> On Mon, Jul 14, 2008 at 09:54:37PM +0400, Anton Vorontsov wrote: > >> > Currently of_i2c will select first compatible property as a last resort > >> > option. This isn't best choice though, because generic compatible > entries > >> > are listed last, not first. For example, two compatible entries given > for > >> > the MCU node: > >> > > >> > "fsl,mc9s08qg8-mpc837xrdb", "fsl,mcu-mpc8349emitx"; > >> > > >> > Since no sane driver will ever match specific devices, what we want is > >> > to select most generic option (last). Then driver may call > >> > of_device_is_compatible() if it is really interested in details. > >> > >> > >> I highly suspect that this will actually be a rare condition and that > >> most of the time the driver you want will bind against the first entry > >> in the list (I'm basing this on what discussion I've seen on the list > >> and it seems to me that Jiri does want i2c devices to list the exact set > >> of chips that each driver binds against). > > > > Can we put a loop on request_module() and have it try each one down > > the list until something matches? request_module() returns errors, but > > I can't tell from the source if one of those errors is "no matching > > module found" since it invokes a user space helper. > > > What will request_module() do if the modules is compiled in > statically? If it is workable then I'm not opposed to this approach. I'm no expert on request_module, from the comments: It appears to be synchronous with user space... call_usermodehelper wait flag, and remove exec_usermodehelper. Rusty Russell <[EMAIL PROTECTED]> Jan 2003 * Load a module using the user mode module loader. The function returns * zero on success or a negative errno code on failure. Note that a * successful module load does not mean the module did not then unload * and exit on an error of its own. Callers must check that the service * they requested is now available not blindly invoke it. Is this really a problem? If the specific driver gets loaded and then errors out, then something must be wrong. The appropriate action probably should not be to load the next driver on the list. It looks like it should work. Compiled in moduled and modules that are already loaded are essentially the same so they should return 0 from request module. > > > > That would work for this compatible string: > > compatible = "atmel,24c32wp", "24c32", "eeprom"; > > > > request_module will always fail for the first entry. If you have at24 > > in your system the second one will succeed. If you have eeprom the > > third one works. All of those names are valid in a device tree. > > > I know this is just an example; but to keep thinks clear, the second > and third values in this compatible property are completely bogus (for > device trees). The manufacturer prefix needs to be present and > 'eeprom' is far to vague. Isn't 24c32 a generic, cross manufacturer term used for these devices? What if I have a socket and use a different vendor's chip each week? eeprom is the vague Linuxism that at24 is attempting to correct. eeprom just goes and searches for anything resembling an eeprom. It will trigger on chips that aren't eeproms. > > -- > Grant Likely, B.Sc., P.Eng. > Secret Lab Technologies Ltd. > -- Jon Smirl [EMAIL PROTECTED] ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 2/2] Allow a custom ASOC machine driver with soc-of-simple
On 7/27/08, Grant Likely <[EMAIL PROTECTED]> wrote:
> On Sun, Jul 27, 2008 at 12:44 AM, Jon Smirl <[EMAIL PROTECTED]> wrote:
> > On 7/26/08, Grant Likely <[EMAIL PROTECTED]> wrote:
> >> On Tue, Jul 22, 2008 at 07:53:51PM -0400, Jon Smirl wrote:
> >>
> >> > Allow a custom ASOC machine driver with soc-of-simple
> >> >
> >> > Signed-off-by: Jon Smirl <[EMAIL PROTECTED]>
>
> >> > diff --git a/sound/soc/fsl/soc-of-simple.c
> >> b/sound/soc/fsl/soc-of-simple.c
> >> > index 0382fda..dd2fa23 100644
> >> > --- a/sound/soc/fsl/soc-of-simple.c
> >> > +++ b/sound/soc/fsl/soc-of-simple.c
> >> > @@ -38,8 +38,8 @@ struct of_snd_soc_device {
> >> > struct device_node *codec_node;
> >> > };
> >> >
> >> > -static struct snd_soc_ops of_snd_soc_ops = {
> >> > -};
> >> > +static struct snd_soc_ops *machine_ops = NULL;
> >> > +static char *machine_name = NULL;
> >>
> >>
> >> Doing this prevents multiple instances of this machine driver (which is
> >> exactly what I have on my board). To register a machine driver it
> >> creates a 3-way bind condition instead of the existing 2-way one. Right
> >> now it is easy to match up codec and platform drivers because a common
> >> key is available in the device tree.
> >>
> >> Alternately, it might be okay to only allow for a single machine driver
> >> that is able to create multiple sound card instances, but this current
> >> code just uses the same name and ops for each registered device.
> >>
> > We need to call them fabric drivers since we already have machine
> > drivers in arch/ It is too confusing.
>
>
> heh, even worse; we've already got platform drivers under drivers/.
> :-P I disagree. We need to be consistent with ALSA terminology, but
> I will be more diligent to call them ASoC Machine drivers.
>
>
> > My fabric driver was getting probed after the rest of ASOC bound,
> > that's why I had to add the third condition.
> >
> > An important feature for me is the ability to compile in multiple
> > fabric drivers and then get the right one selected based on the
> > machine name in the device tree.
>
>
> Absolutely; this is a hard requirement as far as I'm concerned.
>
> It is also a hard requirement for either multiple *active* ASoC
> machine drivers, or support ASoC machine drivers that control multiple
> ASoC device instances.
>
>
> > I'm doing via my machine driver.
> >
> > Could we dynamically build an OF fabric device entry with a compatible
> > string like this: compatible="machinename-fabric,generic-fabric"
> > Now a hard requirement for a fabric driver is ok since one of those
> > two will load for sure. generic-fabric is just a do nothing driver
> > that is always built in.
>
>
> Ugh; unfortunately that results in Linux internal details getting
> leaked out to the device tree. Not a good idea; especially when we
> *know* this driver is a stop gap measure until v2 changes things on
> us.
It has been pointed out several times that the sound fabric (wires,
external chips) really is a device so why can't it have a device tree
entry?
ASOCv2 still has this same problem of triggering the load of the fabric driver.
The Linuxism being exposed here is the split between the machine
driver and the fabric driver. Machine drivers are dynamically selected
by the device tree. The device tree model is assuming these are
combined into a single unit.
Simulating the merge of these two two into a single unit is why I
added the platform device creation code for my fabric driver to my
machine driver. But then we run in to the problem that Linux doesn't
support device drivers that override each other. There is no way to
have a dspeak01-fabric override a generic-fabric.
One solution to the override problem would be to make an overridable
callout in the machine driver that always creates a generic-fabric
platform device. I would then set a bit in my machine driver which
would cause the name to change from generic-fabric to dspeak01-fabric.
Another Linuxism involved here is creating devices without knowing
when or if a driver is ever going to show up. You hit this when making
the ASOC devices, say we only created a dspeak01-fabric platform
device and it hasn't been probed yet. How do you know if it is safe to
assume a generic-fabric? Is dspeak01-fabric coming and it just hasn't
been probed yet, or is it never coming at all?
>
> But that still doesn't help the question of how to trigger loading of
> the board specific machine drivers. grumble. But I do think that the
> sanest approach is still to trigger on the top level model property in
> the tree.
>
> Oh well, if I need to add a dummy machine driver that matches on my
> board, then that's what I'll do. It certainly sidesteps all the ugly
> heuristics of figuring out when custom code is needed.
>
>
> > /* Trigger the platform specific ASOC driver to load */
> > static struct platform_device platform = {
> >.name = "dspeak01
Re: [PATCH 1/2] leds: make the default trigger name const
Hi Trent,
On Sat, 26 Jul 2008 20:08:57 -0600 Grant Likely <[EMAIL PROTECTED]> wrote:
>
> On Fri, Jul 25, 2008 at 02:01:44PM -0700, Trent Piepho wrote:
> > The default_trigger fields of struct gpio_led and thus struct led_classdev
> > are pretty much always assigned from a string literal, which means the
> > string can't be modified. Which is fine, since there is no reason to
> > modify the string and in fact it never is.
> >
> > But they should be marked const to prevent such code from being added, to
> > prevent warnings if -Wwrite-strings is used and when assigned from a
> > constant string other than a string literal (which produces a warning under
> > current kernel compiler flags), and for general good coding practices.
> >
> > Signed-off-by: Trent Piepho <[EMAIL PROTECTED]>
> Acked-by: Grant Likely <[EMAIL PROTECTED]>
I would ack this as well, except I am not sure what tree this patch is
against. In the current powerpc next tree,
> > +++ b/include/linux/leds.h
> > @@ -48,7 +48,7 @@ struct led_classdev {
> >
> > struct device *dev;
> > struct list_head node; /* LED Device list */
> > - char*default_trigger; /* Trigger to use */
> > + const char *default_trigger; /* Trigger to use */
this is already const, but there is another structure slightly further
down (struct led_info) that has a non-const default_tigger.
--
Cheers,
Stephen Rothwell[EMAIL PROTECTED]
http://www.canb.auug.org.au/~sfr/
pgpFhCLEc4jMK.pgp
Description: PGP signature
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] Fix powerpc64 build if CONFIG_EPOLL=n
Declate compat_sys_epoll_pwait as a conditional syscall like the rest of the epoll interfaces. We could have put an #ifdef around the entry in include/asm-powerpc/ systbl.h, but IMHO this is ultimately correct patch. Signed-off-by: Jimi Xenidis <[EMAIL PROTECTED]> --- diff --git a/kernel/sys_ni.c b/kernel/sys_ni.c index 5b9b467..0fea0ee 100644 --- a/kernel/sys_ni.c +++ b/kernel/sys_ni.c @@ -59,6 +59,7 @@ cond_syscall(sys_epoll_create); cond_syscall(sys_epoll_ctl); cond_syscall(sys_epoll_wait); cond_syscall(sys_epoll_pwait); +cond_syscall(compat_sys_epoll_pwait); cond_syscall(sys_semget); cond_syscall(sys_semop); cond_syscall(sys_semtimedop); ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 0/5] powerpc tracehook
> > Thanks for this. I haven't followed the story of tracehook so far, are > > those patches dependent on something else or it's all already upstream > > and do you think that's still 2.6.27 material ? > > The infrastructure is in Linus's tree. Thanks David. I'll review these on monday and if Paul has no objection, I suppose we can still merge them. Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 0/5] powerpc tracehook
From: Benjamin Herrenschmidt <[EMAIL PROTECTED]> Date: Sun, 27 Jul 2008 17:52:45 +1000 > On Sat, 2008-07-26 at 23:48 -0700, Roland McGrath wrote: > > These patches are posted for review, but you can just pull the GIT branch > > if you prefer. Patch 1/5 corrects a long-standing (minor) error in ptrace > > behavior. The others change no existing behavior, just enable new and > > future features to work on the arch. > > Hi Roland ! > > Thanks for this. I haven't followed the story of tracehook so far, are > those patches dependent on something else or it's all already upstream > and do you think that's still 2.6.27 material ? The infrastructure is in Linus's tree. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 0/5] powerpc tracehook
On Sat, 2008-07-26 at 23:48 -0700, Roland McGrath wrote: > These patches are posted for review, but you can just pull the GIT branch > if you prefer. Patch 1/5 corrects a long-standing (minor) error in ptrace > behavior. The others change no existing behavior, just enable new and > future features to work on the arch. Hi Roland ! Thanks for this. I haven't followed the story of tracehook so far, are those patches dependent on something else or it's all already upstream and do you think that's still 2.6.27 material ? Cheers, Ben. > The following changes since commit 8be1a6d6c77ab4532e4476fdb8177030ef48b52c: > Linus Torvalds (1): > Merge branch 'for-linus' of git://git.kernel.org/.../roland/infiniband > > are available in the git repository at: > > git://git.kernel.org/pub/scm/linux/kernel/git/frob/linux-2.6-utrace.git > powerpc-tracehook > > Roland McGrath (5): > powerpc: tracehook_signal_handler > powerpc: tracehook syscall > powerpc: tracehook: asm/syscall.h > powerpc: tracehook: TIF_NOTIFY_RESUME > powerpc: tracehook: CONFIG_HAVE_ARCH_TRACEHOOK > > arch/powerpc/Kconfig |1 + > arch/powerpc/kernel/entry_32.S| 11 - > arch/powerpc/kernel/entry_64.S| 10 +++- > arch/powerpc/kernel/ptrace.c | 47 ++--- > arch/powerpc/kernel/signal.c | 21 - > include/asm-powerpc/ptrace.h |1 + > include/asm-powerpc/signal.h |3 +- > include/asm-powerpc/syscall.h | 84 > + > include/asm-powerpc/thread_info.h |5 ++- > 9 files changed, 147 insertions(+), 36 deletions(-) > create mode 100644 include/asm-powerpc/syscall.h > > > Thanks, > Roland > -- > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
