Re: tracking of PCI address space
On Wed, 2009-04-08 at 15:53 -0500, Kumar Gala wrote: I was wondering if we have anything that tracks regions associated with the inbound side of a pci_bus. What I mean is on embedded PPC we have window/mapping registers for both inbound (accessing memory on the SoC) and outbound (access PCI device MMIO, IO etc). The combination of the inbound outbound convey what exists in the PCI address space vs CPU physical address space (and how to map from one to the other). Today in the PPC land we only attach outbound windows to the pci_bus. So technically the inbound side information (like what subset of physical memory is visible on the PCI bus) seems to be lost. On powerpc, we do keep track of the offset, but that's about it. Tracking inbound ranges is very platform specific though. You can have multiple inbound windows with different translations, in some cases some via iommu and some not, or windows aliasing the same target memory but with different attributes, etc... I don't think there's that much interest in trying to create generic code to keep track. Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: tracking of PCI address space
On Wed, Apr 08, 2009 at 03:53:55PM -0500, Kumar Gala wrote: I was wondering if we have anything that tracks regions associated with the inbound side of a pci_bus. What I mean is on embedded PPC we have window/mapping registers for both inbound (accessing memory on the SoC) and outbound (access PCI device MMIO, IO etc). The combination of the inbound outbound convey what exists in the PCI address space vs CPU physical address space (and how to map from one to the other). Most PCI Host bus controllers will negatively decode the outbound ranges for inbound traffic. PARISC and IA64 have extra registers to play some games with that. But routing between PCI bus controllers to make them look like a single PCI segment was the main intent of that. I've not found any other uses to subvert that. Today in the PPC land we only attach outbound windows to the pci_bus. So technically the inbound side information (like what subset of physical memory is visible on the PCI bus) seems to be lost. What did you need inbound routing map for? thanks, grant ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
RE: tracking of PCI address space
I agree. Every processor(SOC) has unique of setting inbound window. What I noticed is Inbound regions are created big enough to map whole DDR region. And uses physical address of ram as a source/destination address. For example if a PCI-E SATA card wants to do DMA transfers to DDR region. It will create dma_alloc_noncoherent() region and uses physical address as source/destination address for data transfers. From: linuxppc-dev-bounces+tmarri=amcc@ozlabs.org on behalf of Benjamin Herrenschmidt Sent: Wed 4/8/2009 11:21 PM To: Kumar Gala Cc: linux-...@vger.kernel.org; Linux Kernel Mailing List; Jesse Barnes; Linux/PPC Development Subject: Re: tracking of PCI address space On Wed, 2009-04-08 at 15:53 -0500, Kumar Gala wrote: I was wondering if we have anything that tracks regions associated with the inbound side of a pci_bus. What I mean is on embedded PPC we have window/mapping registers for both inbound (accessing memory on the SoC) and outbound (access PCI device MMIO, IO etc). The combination of the inbound outbound convey what exists in the PCI address space vs CPU physical address space (and how to map from one to the other). Today in the PPC land we only attach outbound windows to the pci_bus. So technically the inbound side information (like what subset of physical memory is visible on the PCI bus) seems to be lost. On powerpc, we do keep track of the offset, but that's about it. Tracking inbound ranges is very platform specific though. You can have multiple inbound windows with different translations, in some cases some via iommu and some not, or windows aliasing the same target memory but with different attributes, etc... I don't think there's that much interest in trying to create generic code to keep track. Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
MPC5200 FEC driver crashing on 2.6.30-rc1....
Hi all, Seems like there are some NAPI changes not being (correctly) applied to the MPC5200 FEC driver... [ 1319.265289] [ cut here ] [ 1319.274699] kernel BUG at .../arch/powerpc/include/asm/dma-mapping.h:164! [ 1319.297488] Oops: Exception in kernel mode, sig: 5 [#1] [ 1319.308086] PREEMPT mpc5200-simple-platform [ 1319.316572] Modules linked in: [ 1319.322773] NIP: c01dbef8 LR: c01dbec8 CTR: [ 1319.332852] REGS: c3a9dc80 TRAP: 0700 Not tainted (2.6.29-07103-gd0b70e8-dirty) [ 1319.348212] MSR: 00029032 EE,ME,CE,IR,DR CR: 42008448 XER: 2000 [ 1319.361684] TASK = c387acb0[1876] 'ifconfig' THREAD: c3a9c000 [ 1319.372988] GPR00: 0001 c3a9dd30 c387acb0 c3a13820 c3a13820 c3a13e11 c520 [ 1319.389982] GPR08: 0001 c5001000 0008 22008444 100adabc 03fc1000 0001 [ 1319.406973] GPR16: 007fff00 03fbb790 c3a9de08 8914 c388410c c386b400 [ 1319.423967] GPR24: c3884100 c394b640 c040 c386b5e8 c386b400 c5001000 c39c3600 c39bb3c0 [ 1319.441359] NIP [c01dbef8] mpc52xx_fec_alloc_rx_buffers+0xac/0x1a8 [ 1319.453914] LR [c01dbec8] mpc52xx_fec_alloc_rx_buffers+0x7c/0x1a8 [ 1319.466276] Call Trace: [ 1319.471250] [c3a9dd30] [c01dbeb0] mpc52xx_fec_alloc_rx_buffers+0x64/0x1a8 (unreliable) [ 1319.487345] [c3a9dd60] [c01dc444] mpc52xx_fec_open+0x128/0x2d0 [ 1319.499221] [c3a9dda0] [c02458f4] dev_open+0xc0/0x118 [ 1319.509493] [c3a9ddc0] [c0244678] dev_change_flags+0x84/0x1ac [ 1319.521176] [c3a9dde0] [c028b1b8] devinet_ioctl+0x638/0x758 [ 1319.532501] [c3a9de50] [c028bca8] inet_ioctl+0xcc/0xf8 [ 1319.542956] [c3a9de60] [c02325a8] sock_ioctl+0x60/0x2e8 [ 1319.553576] [c3a9de80] [c0096e44] vfs_ioctl+0x40/0xc0 [ 1319.563840] [c3a9dea0] [c009728c] do_vfs_ioctl+0x3c8/0x748 [ 1319.574986] [c3a9df10] [c009764c] sys_ioctl+0x40/0x74 [ 1319.585284] [c3a9df40] [c0011878] ret_from_syscall+0x0/0x38 [ 1319.596606] --- Exception: c01 at 0xfe8b6a4 [ 1319.596622] LR = 0xff0573c [ 1319.611264] Instruction dump: [ 1319.617281] a13f0018 380005f2 817f0020 815f000c 7d2959d6 7c09512e 7fa95214 80be0098 [ 1319.633037] 41920104 813c0264 7d200034 5400d97e 0f00 801a5218 3c854000 7f63db78 [ 1319.649160] ---[ end trace a3057d5e6d98e2c6 ]--- Best regards, -- David Jander Protonic Holland. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] AOA: Convert onyx and tas codecs to new-style i2c drivers
Hi Jean! Yes, probing would be duplicated if we had to support more than one bus. But as far as I can see, the onyx and tas devices can only be found on i2c-powermac buses, so this shouldn't be an issue. And there isn't really any probing going on, it's really only a matter of walking a small subset of the device tree (the children of the I2C bus) and instantiating I2C devices. Right, it was just an unrelated thought, it's not related to this in particular. Now, aoa will currently automatically load from the layout fabric module, and then pull in the modules for the codecs it _knows_ to be present on the bus. Therefore, it seems that your patch makes things less efficient because you probe for all those codecs, and there's no machine that has all of them. The aoa fabric only loads the modules for those it knows to be present, and they then probe (and in reality the probing never fails because they really are there). Can you please point me to the layout fabric / aoa fabric? I'd like to understand how it works. Then I may be able to rewrite my patch completely differently. That's in sound/aoa/fabric/layout.c There are basically two ways to instantiate I2C devices in the new model. The first method is to declare the I2C devices as platform data and let i2c-core instantiate them. The second method is to have the i2c bus driver instantiate the clients. My patch uses the second method because I didn't know how to use the first method. However using the first method would solve the issues you raised. But I need some help from someone more familiar with the powermac platform initialization code to get it right. Interesting. Does it need to be _platform_ data, or could sound/aoa/fabric/layout.c declare the devices instead? Now, since aoa needs information on how the entire system is glued together (the fabric I was talking about with the line-in example), it has to infer that from platform data, in this case the device tree. Because I do not have any older machines, am lazy and snd-powermac works for the old machines, snd-powermac with its tumbler is a driver for the same tas3004 codec, but on a different, older, fabric. I think I've found that one by now (snd_pmac_detect in sound/ppc/pmac.c, right?), thanks for the clarification. That's snd-powermac, yes. BTW, that code doesn't seem significantly different from what my patch is adding to i2c-powermac. That would be true, yes, with your patch I don't understand how to load snd-powermac _or_ snd-aoa based on the platform data (or in the case of snd-powermac, not load it automatically at all). Hmm, OK, I expected the code I moved from the aoa drivers to i2c-powermac to only match the subset of machines actually supported by aoa. If that's not the case then indeed it is incorrect. Yeah, that's not the case, I think the 'deq' node will be present on older machines as well and you would load snd-aoa-codec-tas where snd-powermac should be loaded. Therefore, probing the codecs in i2c-powermac and automatically loading the corresponding aoa module will break sound on old machines. Does this mean that manually loading snd_aoa_codec_tas today on an old system with a TAS would break sound too? Yes, I'm pretty sure it does on some systems. Actually, I'm not entirely sure, because I don't know whether the i2c core will prevent two drivers from talking to the same chip on the same bus, and if it doesn't then this might still work but it would at least be very strange wrt. suspend resume. Anyway, the key point of my patch is to get rid of the legacy i2c binding model, not efficiency. Yes, I understand :) Since I'm away from all machines I could test this with I have no data on any that or the module device table thing I pointed out for now. Anyway, some more technical comments on your patch: * I realise you just copied things around but it would be nice to clean up the coding style, especially comment style, a little while at it. (yeah, it's my fault) I can fix anything you like, just tell me what :) I think CodingStyle wants /* * ... * ... */ * aoa_codec_* is the module name, I see no reason to use that as the i2c name, that should be the codec's name instead (aka pcm3052 etc) The names are totally arbitrary and we can change them if you like. Keep in mind though that we should avoid using mere chip names for non-generic drivers. The aoa drivers are powermac-specific, we don't want the names we pick to collide with another driver, that's why I chose to keep the aoa prefix. Oh ok, that kinda ties in with my very first question about what happens if the same chip is known in different contexts, on different buses etc. Makes sense in that case I guess. But I still think that you shouldn't auto-load the aoa codec modules based on this anyway. johannes signature.asc Description: This is a digitally signed message part
problem with yellowstone
-- View this message in context: http://www.nabble.com/problem-with-yellowstone-tp22967168p22967168.html Sent from the linuxppc-dev mailing list archive at Nabble.com. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
problem with yellowstone
I am using VIA VT6421 pci chipset.. when i am connecting my 250GB SATA drive i am getting this dump it seems that interrupt from UIC0(interrupt 25) wich is hooked to PCI_INTA is not getting cleared and because of this interrupt is not getting cleared it is calling interrupt handler 10 times and then give up. so please mail me if there is any way to clear the interrupt or anything which could help. I IBM/AMCC PowerPC 440 GR Rev. B Board: AMCC YELLOWSTONE VCO: 1066 MHz CPU: 533 MHz PLB: 133 MHz OPB: 66 MHz PER: 66 MHz PCI: 33 MHz I2C: ready DRAM: 256 MB FLASH: 32 MB PCI: Bus Dev VenId DevId Class Int 00 0c 1106 3038 0c03 00 00 0c 1106 3038 0c03 00 00 0c 1106 3104 0c03 00 00 0c 1106 3249 0104 0e In:serial Out: serial Err: serial Net: ppc_440x_eth0, ppc_440x_eth1 Hit any key to stop autoboot: 0 = tftp 20 ij4 Waiting for PHY auto negotiation to complete.. done Using ppc_440x_eth0 device TFTP from server 192.168.0.100; our IP address is 192.168.0.101 Filename 'ij4'. Load address: 0x20 Loading: T # # # # done Bytes transferred = 1408179 (157cb3 hex) = bootm ## Booting image at 0020 ... Image Name: Linux-2.6.26.8 Created: 2009-04-01 10:33:56 UTC Image Type: PowerPC Linux Kernel Image (gzip compressed) Data Size:1408115 Bytes = 1.3 MB Load Address: Entry Point: Verifying Checksum ... OK Uncompressing Kernel Image ... OK Linux version 2.6.26.8 (r...@debian) (gcc version 4.2.2) #24 Wed Apr 1 03:32:139AMCC PowerPC 440GR Yellowstone Platform Zone PFN ranges: DMA 0 -65536 Normal 65536 -65536 Movable zone start PFN for each node early_node_map[1] active PFN ranges 0:0 -65536 Built 1 zonelists in Zone order, mobility grouping on. Total pages: 65024 Kernel command line: root=/dev/nfs rw nfsroot=192.168.0.100:/opt/eldk4.2/ppc_4xlMisrouted IRQ fixup and polling support enabled This may significantly impact system performance PID hash table entries: 1024 (order: 10, 4096 bytes) console [ttyS0] enabled Dentry cache hash table entries: 32768 (order: 5, 131072 bytes) Inode-cache hash table entries: 16384 (order: 4, 65536 bytes) Memory: 256768k available (2120k kernel code, 716k data, 156k init, 0k highmem) Mount-cache hash table entries: 512 net_namespace: 480 bytes NET: Registered protocol family 16 PCI: Probing PCI hardware SCSI subsystem initialized NET: Registered protocol family 2 IP route cache hash table entries: 2048 (order: 1, 8192 bytes) TCP established hash table entries: 8192 (order: 4, 65536 bytes) TCP bind hash table entries: 8192 (order: 3, 32768 bytes) TCP: Hash tables configured (established 8192 bind 8192) TCP reno registered NET: Registered protocol family 1 msgmni has been set to 501 io scheduler noop registered io scheduler anticipatory registered (default) io scheduler deadline registered io scheduler cfq registered Serial: 8250/16550 driver $Revision: 1.90 $ 4 ports, IRQ sharing enabled serial8250: ttyS0 at MMIO 0x0 (irq = 0) is a 16550A serial8250: ttyS1 at MMIO 0x0 (irq = 1) is a 16550A brd: module loaded PPC 4xx OCP EMAC driver, version 3.54 mal0: initialized, 4 TX channels, 2 RX channels zmii0: bridge in RMII mode eth0: emac0, MAC 00:10:ec:00:89:89 eth0: found Generic MII PHY (0x01) eth1: emac1, MAC 00:10:ec:80:89:89 eth1: found Generic MII PHY (0x03) Uniform Multi-Platform E-IDE driver ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx ide_generic: please use probe_mask=0x3f module parameter for probing all legasDriver 'sd' needs updating - please use bus_type methods sata_via :00:0c.3: routed to hard irq line 9 irq 25: nobody cared (try booting with the irqpoll option) Call Trace: [cfc21ac0] [c0008344] show_stack+0x44/0x1ac (unreliable) [cfc21b00] [c003ec14] __report_bad_irq+0x34/0xb8 [cfc21b20] [c003ef20] note_interrupt+0x288/0x2f0 [cfc21b50] [c003e1b4] __do_IRQ+0x100/0x118 [cfc21b70] [c0006784] do_IRQ+0xbc/0xc0 [cfc21b80] [c0001c64] ret_from_except+0x0/0x18 [cfc21c40] [] 0x0 [cfc21c60] [c000650c] do_softirq+0x54/0x58 [cfc21c70] [c001e97c] irq_exit+0x48/0x58 [cfc21c80] [c0006734] do_IRQ+0x6c/0xc0 [cfc21c90] [c0001c64]
Re: [PATCH v3 0/5] i2c: i2c-mpc: make I2C bus speed configurable
Wolfgang Grandegger wrote:
Kumar Gala wrote:
On Apr 8, 2009, at 2:25 AM, Wolfgang Grandegger wrote:
So I'm a bit concerned with the output we now get:
mpc-i2c fffe03000.i2c: clock 0 Hz (dfsrr=16 fdr=49)
why 0? is that right?
This is the backward compatibility mode using hard-coded FDR values. The
output is missleading, I agree.
Wolfgang.
Can the output be fixed. 0 Hz seemed bad to me.
Of course. No info message will be printed for the legacy case
like it was with the old driver version. I just realized a bug in the
MPC52xx part. Will send patches tomorrow, after some more thorough testing.
The patch below fixes both issues. Ben, could you please apply it. Sorry for
the inconvenience caused.
Thanks,
Wolfgang.
[PATCH] i2c: i2c-mpc: bug fix for MPC52xx clock setting and printout
The clock setting did not work for the MPC52xx due to a stupid bug.
Furthermore, the dev info output clock=0 for old device trees was
misleading. This patch fixes both issues.
Signed-off-by: Wolfgang Grandegger w...@grandegger.com
---
drivers/i2c/busses/i2c-mpc.c | 34 --
1 file changed, 20 insertions(+), 14 deletions(-)
Index: linux-2.6-galak/drivers/i2c/busses/i2c-mpc.c
===
--- linux-2.6-galak.orig/drivers/i2c/busses/i2c-mpc.c 2009-04-08
21:51:31.771719368 +0200
+++ linux-2.6-galak/drivers/i2c/busses/i2c-mpc.c2009-04-09
11:18:45.812969033 +0200
@@ -164,7 +164,7 @@
return 0;
}
-#ifdef CONFIG_PPC_52xx
+#ifdef CONFIG_PPC_MPC52xx
static const struct mpc_i2c_divider mpc_i2c_dividers_52xx[] = {
{20, 0x20}, {22, 0x21}, {24, 0x22}, {26, 0x23},
{28, 0x24}, {30, 0x01}, {32, 0x25}, {34, 0x02},
@@ -188,7 +188,7 @@
int mpc_i2c_get_fdr_52xx(struct device_node *node, u32 clock, int prescaler)
{
- const struct mpc52xx_i2c_divider *div = NULL;
+ const struct mpc_i2c_divider *div = NULL;
unsigned int pvr = mfspr(SPRN_PVR);
u32 divider;
int i;
@@ -203,7 +203,7 @@
* We want to choose an FDR/DFSR that generates an I2C bus speed that
* is equal to or lower than the requested speed.
*/
- for (i = 0; i ARRAY_SIZE(mpc52xx_i2c_dividers); i++) {
+ for (i = 0; i ARRAY_SIZE(mpc_i2c_dividers_52xx); i++) {
div = mpc_i2c_dividers_52xx[i];
/* Old MPC5200 rev A CPUs do not support the high bits */
if (div-fdr 0xc0 pvr == 0x80822011)
@@ -219,20 +219,23 @@
struct mpc_i2c *i2c,
u32 clock, u32 prescaler)
{
- int fdr = mpc52xx_i2c_get_fdr(node, clock, prescaler);
+ int ret, fdr;
+
+ ret = mpc_i2c_get_fdr_52xx(node, clock, prescaler);
+ fdr = (ret = 0) ? ret : 0x3f; /* backward compatibility */
- if (fdr 0)
- fdr = 0x3f; /* backward compatibility */
writeb(fdr 0xff, i2c-base + MPC_I2C_FDR);
- dev_info(i2c-dev, clock %d Hz (fdr=%d)\n, clock, fdr);
+
+ if (ret = 0)
+ dev_info(i2c-dev, clock %d Hz (fdr=%d)\n, clock, fdr);
}
-#else /* !CONFIG_PPC_52xx */
+#else /* !CONFIG_PPC_MPC52xx */
static void mpc_i2c_setclock_52xx(struct device_node *node,
struct mpc_i2c *i2c,
u32 clock, u32 prescaler)
{
}
-#endif /* CONFIG_PPC_52xx*/
+#endif /* CONFIG_PPC_MPC52xx*/
#ifdef CONFIG_FSL_SOC
static const struct mpc_i2c_divider mpc_i2c_dividers_8xxx[] = {
@@ -321,14 +324,17 @@
struct mpc_i2c *i2c,
u32 clock, u32 prescaler)
{
- int fdr = mpc_i2c_get_fdr_8xxx(node, clock, prescaler);
+ int ret, fdr;
+
+ ret = mpc_i2c_get_fdr_8xxx(node, clock, prescaler);
+ fdr = (ret = 0) ? ret : 0x1031; /* backward compatibility */
- if (fdr 0)
- fdr = 0x1031; /* backward compatibility */
writeb(fdr 0xff, i2c-base + MPC_I2C_FDR);
writeb((fdr 8) 0xff, i2c-base + MPC_I2C_DFSRR);
- dev_info(i2c-dev, clock %d Hz (dfsrr=%d fdr=%d)\n,
-clock, fdr 8, fdr 0xff);
+
+ if (ret = 0)
+ dev_info(i2c-dev, clock %d Hz (dfsrr=%d fdr=%d)\n,
+clock, fdr 8, fdr 0xff);
}
#else /* !CONFIG_FSL_SOC */
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] AOA: Convert onyx and tas codecs to new-style i2c drivers
Hi Johannes, On Thu, 09 Apr 2009 09:44:49 +0200, Johannes Berg wrote: Can you please point me to the layout fabric / aoa fabric? I'd like to understand how it works. Then I may be able to rewrite my patch completely differently. That's in sound/aoa/fabric/layout.c OK, I understand how it works now, thanks for pointing me to the relevant piece of code. It's easier to modify the code when you understand the current logic ;) There are basically two ways to instantiate I2C devices in the new model. The first method is to declare the I2C devices as platform data and let i2c-core instantiate them. The second method is to have the i2c bus driver instantiate the clients. My patch uses the second method because I didn't know how to use the first method. However using the first method would solve the issues you raised. But I need some help from someone more familiar with the powermac platform initialization code to get it right. Interesting. Does it need to be _platform_ data, or could sound/aoa/fabric/layout.c declare the devices instead? It can be anywhere as long as it is early enough. Early enough means that the code must run before device drivers can loaded. As snd-aoa-fabric-layout can be built as a module, it doesn't seem right. The idea is to assign fixed i2c bus numbers to the relevant i2c buses, and declare the i2c devices connected to each bus by bus number and device address. The i2c-powermac buses are created in arch/powerpc/platforms/powermac/low_i2c.c, so you would have to instantiate the i2c devices there too. That would basically mean merging part of snd-aoa-fabric-layout into arch/powerpc/platforms/powermac/low_i2c.c as I understand it, I don't know if this sounds reasonable to you. More generally, in order to instantiate an i2c device (for the new binding model), you need at least two things: a reference to the underlying i2c bus, and the address of the i2c device. The address can be read from the device tree, but what is more difficult is to get the reference to the underlying i2c bus. That reference can be the i2c_adapter number (which only makes sense in a fixed-bus-number scheme), or a pointer to the i2c_adapter. For now the powermac systems do not have fixed i2c bus numbers, which is why I put the code instantiating the devices in i2c-powermac: there I have a pointer to the i2c_adapter. So I think we have two options: switch the powermac systems to fixed i2c bus numbers and instantiate the i2c sound devices from arch/powerpc/platforms/powermac/*, or find a way to obtain a reference to the relevant i2c_adapter. I think I have found a way to achieve the latter. This isn't exactly how the new model was supposed to work, but it has the advantage to be way less intrusive than my original proposal. It may require larger changes in the future as the i2c-core cleanups go on, but this should do for now. (...) I think I've found that one by now (snd_pmac_detect in sound/ppc/pmac.c, right?), thanks for the clarification. That's snd-powermac, yes. BTW, that code doesn't seem significantly different from what my patch is adding to i2c-powermac. That would be true, yes, with your patch I don't understand how to load snd-powermac _or_ snd-aoa based on the platform data (or in the case of snd-powermac, not load it automatically at all). My patch was really only about snd-aoa, it did not take care about snd-powermac at all, because I expected them to be essentially independent. Of course, if the code I added to i2c-powermac instantiates devices on systems which were previous handled by snd-powermac, it would break. More work would be needed to handle the systems supported by snd-powermac. (...) Oh ok, that kinda ties in with my very first question about what happens if the same chip is known in different contexts, on different buses etc. Makes sense in that case I guess. But I still think that you shouldn't auto-load the aoa codec modules based on this anyway. My new approach doesn't auto-load anything. Here we go, what you think? This time there is no logic change, I'm really only turning legacy code into new-style i2c code (basically calling i2c_new_device() instead of i2c_attach_client()) and that's about it. (Once again this is only build-tested and I would like people with the hardware to give it a try.) From: Jean Delvare kh...@linux-fr.org Subject: AOA: Convert onyx and tas codecs to new-style i2c drivers The legacy i2c binding model is going away soon, so convert the AOA codec drivers to the new model or they'll break. Signed-off-by: Jean Delvare kh...@linux-fr.org Cc: Johannes Berg johan...@sipsolutions.net Cc: Benjamin Herrenschmidt b...@kernel.crashing.org --- sound/aoa/codecs/onyx.c | 71 +-- sound/aoa/codecs/tas.c | 63 + 2 files changed, 84 insertions(+), 50 deletions(-) --- linux-2.6.30-rc1.orig/sound/aoa/codecs/onyx.c 2009-04-09
Re: [PATCH] AOA: Convert onyx and tas codecs to new-style i2c drivers
Hi Jean,
OK, I understand how it works now, thanks for pointing me to the
relevant piece of code. It's easier to modify the code when you
understand the current logic ;)
:)
The idea is to assign fixed i2c bus numbers to the relevant i2c buses,
and declare the i2c devices connected to each bus by bus number and
device address. The i2c-powermac buses are created in
arch/powerpc/platforms/powermac/low_i2c.c, so you would have to
instantiate the i2c devices there too. That would basically mean
merging part of snd-aoa-fabric-layout into
arch/powerpc/platforms/powermac/low_i2c.c as I understand it, I don't
know if this sounds reasonable to you.
That doesn't sound too hot -- the fabric module is quite a lot of code
and data.
So I think we have two options: switch the powermac systems to fixed
i2c bus numbers and instantiate the i2c sound devices from
arch/powerpc/platforms/powermac/*, or find a way to obtain a reference
to the relevant i2c_adapter.
I think I have found a way to achieve the latter. This isn't exactly
how the new model was supposed to work, but it has the advantage to be
way less intrusive than my original proposal. It may require larger
changes in the future as the i2c-core cleanups go on, but this should
do for now.
Heh :)
My new approach doesn't auto-load anything. Here we go, what you think?
This time there is no logic change, I'm really only turning legacy code
into new-style i2c code (basically calling i2c_new_device() instead of
i2c_attach_client()) and that's about it.
(Once again this is only build-tested and I would like people with the
hardware to give it a try.)
Looks reasonable.
static int onyx_create(struct i2c_adapter *adapter,
struct device_node *node,
int addr)
{
+ struct i2c_board_info info;
+ struct i2c_client *client;
+
+ memset(info, 0, sizeof(struct i2c_board_info));
+ strlcpy(info.type, aoa_codec_onyx, I2C_NAME_SIZE);
+ if (node) {
+ info.addr = addr;
+ info.platform_data = node;
+ client = i2c_new_device(adapter, info);
+ } else {
+ /* probe both possible addresses for the onyx chip */
+ unsigned short probe_onyx[] = {
+ 0x46, 0x47, I2C_CLIENT_END
+ };
+
+ client = i2c_new_probed_device(adapter, info, probe_onyx);
+ }
+ if (!client)
+ return -ENODEV;
+
+ list_add_tail(client-detected, client-driver-clients);
That list_add looks a little hackish, and wouldn't it be racy?
+static const struct i2c_device_id onyx_i2c_id[] = {
+ { aoa_codec_onyx, 0 },
+ { }
+};
+MODULE_DEVICE_TABLE(i2c, onyx_i2c_id);
Should it really export the device table?
(same comments for tas)
It'll be until mid next week that I can test anything.
johannes
signature.asc
Description: This is a digitally signed message part
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] Xilinx : Framebuffer Driver: Add PLB support (non-DCR)
On Wed, Apr 08, 2009 at 03:11:25PM -0600, John Linn wrote:
From: Suneel [mailto:suneel.garap...@xilinx.com]
Added support for the new xps tft controller.
The new core has PLB interface support in addition to existing
DCR interface.
The driver has been modified to support this new core which
can be connected on PLB or DCR bus.
Signed-off-by: Suneel sune...@xilinx.com
Signed-off-by: John Linn john.l...@xilinx.com
---
drivers/video/xilinxfb.c | 227 --
1 files changed, 160 insertions(+), 67 deletions(-)
diff --git a/drivers/video/xilinxfb.c b/drivers/video/xilinxfb.c
index a82c530..a28a834 100644
--- a/drivers/video/xilinxfb.c
+++ b/drivers/video/xilinxfb.c
@@ -1,17 +1,24 @@
/*
- * xilinxfb.c
*
- * Xilinx TFT LCD frame buffer driver
+ * Xilinx TFT frame buffer driver
*
* Author: MontaVista Software, Inc.
* sou...@mvista.com
*
* 2002-2007 (c) MontaVista Software, Inc.
* 2007 (c) Secret Lab Technologies, Ltd.
+ * 2009 (c) Xilinx Inc.
*
- * This file is licensed under the terms of the GNU General Public License
- * version 2. This program is licensed as is without any warranty of any
- * kind, whether express or implied.
+ * 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.
+ *
+ * You should have received a copy of the GNU General Public
+ * License along with this program; if not, write to the Free
+ * Software Foundation, Inc., 675 Mass Ave, Cambridge, MA
+ * 02139, USA.
*/
What Stephen said.
#define NUM_REGS 2
#define REG_FB_ADDR 0
@@ -112,6 +123,11 @@ struct xilinxfb_drvdata {
struct fb_info info; /* FB driver info record */
+ u32 regs_phys; /* phys. address of the control
+ registers */
Is this driver usable on the 440 based Xilinx devices? If so, is it possible
to have the physical address of the registers above 4GiB, so is common with
almost all the I/O on the other 440 boards?
+ void __iomem*regs; /* virt. address of the control
+ registers */
+
dcr_host_t dcr_host;
unsigned intdcr_start;
unsigned intdcr_len;
@@ -120,6 +136,10 @@ struct xilinxfb_drvdata {
dma_addr_t fb_phys;/* phys. address of the frame buffer */
int fb_alloced; /* Flag, was the fb memory alloced? */
+ u32 dcr_splb_slave_if;
+ /* True, if control interface is
+ connected through plb */
+
Do you need a full 32-bit variable for a simple boolean? It might be best for
structure alignment, but you might want to look at using a flags variable or
something that could be extended with feature bits in a single word.
u32 reg_ctrl_default;
u32 pseudo_palette[PALETTE_ENTRIES_NO];
@@ -130,14 +150,19 @@ struct xilinxfb_drvdata {
container_of(_info, struct xilinxfb_drvdata, info)
/*
- * The LCD controller has DCR interface to its registers, but all
- * the boards and configurations the driver has been tested with
- * use opb2dcr bridge. So the registers are seen as memory mapped.
- * This macro is to make it simple to add the direct DCR access
- * when it's needed.
+ * The XPS TFT Controller can be accessed through PLB or DCR interface.
+ * To perform the read/write on the registers we need to check on
+ * which bus its connected and call the appropriate write API.
*/
-#define xilinx_fb_out_be32(driverdata, offset, val) \
- dcr_write(driverdata-dcr_host, offset, val)
+static void xilinx_fb_out_be32(struct xilinxfb_drvdata *drvdata, u32 offset,
+ u32 val)
+{
+ if (drvdata-dcr_splb_slave_if == 1)
+ out_be32(drvdata-regs + (offset 2), val);
+ else
+ dcr_write(drvdata-dcr_host, offset, val);
+
+}
static int
xilinx_fb_setcolreg(unsigned regno, unsigned red, unsigned green, unsigned
blue,
@@ -175,7 +200,8 @@ xilinx_fb_blank(int blank_mode, struct fb_info *fbi)
switch (blank_mode) {
case FB_BLANK_UNBLANK:
/* turn on panel */
- xilinx_fb_out_be32(drvdata, REG_CTRL,
drvdata-reg_ctrl_default);
+ xilinx_fb_out_be32(drvdata, REG_CTRL,
+ drvdata-reg_ctrl_default);
break;
case FB_BLANK_NORMAL:
@@ -191,8 +217,7 @@ xilinx_fb_blank(int blank_mode, struct fb_info *fbi)
return 0; /* success */
}
-static struct fb_ops xilinxfb_ops =
-{
+static struct fb_ops xilinxfb_ops = {
.owner = THIS_MODULE,
.fb_setcolreg = xilinx_fb_setcolreg,
.fb_blank =
[BUILD FAILURE 01] Next April 9 : PPC64 randconfig [drivers/net/fs_enet/fs_enet-main.c]
Observed the following build error: drivers/net/fs_enet/fs_enet-main.c: In function ‘fs_enet_probe’: drivers/net/fs_enet/fs_enet-main.c:1096: error: ‘struct net_device’ has no member named ‘open’ drivers/net/fs_enet/fs_enet-main.c:1097: error: ‘struct net_device’ has no member named ‘hard_start_xmit’ drivers/net/fs_enet/fs_enet-main.c:1098: error: ‘struct net_device’ has no member named ‘tx_timeout’ drivers/net/fs_enet/fs_enet-main.c:1100: error: ‘struct net_device’ has no member named ‘stop’ drivers/net/fs_enet/fs_enet-main.c:1101: error: ‘struct net_device’ has no member named ‘get_stats’ drivers/net/fs_enet/fs_enet-main.c:1102: error: ‘struct net_device’ has no member named ‘set_multicast_list’ drivers/net/fs_enet/fs_enet-main.c:: error: ‘struct net_device’ has no member named ‘do_ioctl’ make[3]: *** [drivers/net/fs_enet/fs_enet-main.o] Error 1 make[2]: *** [drivers/net/fs_enet] Error 2 make[1]: *** [drivers/net] Error 2 make: *** [drivers] Error 2 Regards-- Subrata # # Automatically generated make config: don't edit # Linux kernel version: 2.6.30-rc1 # Thu Apr 9 06:27:57 2009 # # CONFIG_PPC64 is not set # # Processor support # CONFIG_6xx=y # CONFIG_PPC_85xx is not set # CONFIG_PPC_8xx is not set # CONFIG_40x is not set # CONFIG_44x is not set # CONFIG_E200 is not set CONFIG_PPC_BOOK3S=y CONFIG_PPC_FPU=y CONFIG_ALTIVEC=y CONFIG_PPC_STD_MMU=y CONFIG_PPC_STD_MMU_32=y # CONFIG_PPC_MM_SLICES is not set CONFIG_SMP=y CONFIG_NR_CPUS=4 CONFIG_NOT_COHERENT_CACHE=y CONFIG_PPC32=y CONFIG_WORD_SIZE=32 # CONFIG_ARCH_PHYS_ADDR_T_64BIT is not set CONFIG_MMU=y CONFIG_GENERIC_CMOS_UPDATE=y CONFIG_GENERIC_TIME=y CONFIG_GENERIC_TIME_VSYSCALL=y CONFIG_GENERIC_CLOCKEVENTS=y CONFIG_GENERIC_HARDIRQS=y # CONFIG_HAVE_SETUP_PER_CPU_AREA is not set CONFIG_IRQ_PER_CPU=y CONFIG_STACKTRACE_SUPPORT=y CONFIG_HAVE_LATENCYTOP_SUPPORT=y CONFIG_LOCKDEP_SUPPORT=y CONFIG_RWSEM_XCHGADD_ALGORITHM=y CONFIG_GENERIC_LOCKBREAK=y CONFIG_ARCH_HAS_ILOG2_U32=y CONFIG_GENERIC_HWEIGHT=y CONFIG_GENERIC_CALIBRATE_DELAY=y CONFIG_GENERIC_FIND_NEXT_BIT=y CONFIG_GENERIC_GPIO=y # CONFIG_ARCH_NO_VIRT_TO_BUS is not set CONFIG_PPC=y CONFIG_EARLY_PRINTK=y CONFIG_GENERIC_NVRAM=y CONFIG_SCHED_OMIT_FRAME_POINTER=y CONFIG_ARCH_MAY_HAVE_PC_FDC=y CONFIG_PPC_OF=y CONFIG_OF=y CONFIG_PPC_UDBG_16550=y CONFIG_GENERIC_TBSYNC=y CONFIG_AUDIT_ARCH=y CONFIG_GENERIC_BUG=y CONFIG_SYS_SUPPORTS_APM_EMULATION=y CONFIG_DEFAULT_UIMAGE=y CONFIG_ARCH_SUSPEND_POSSIBLE=y # CONFIG_PPC_DCR_NATIVE is not set # CONFIG_PPC_DCR_MMIO is not set CONFIG_ARCH_SUPPORTS_DEBUG_PAGEALLOC=y CONFIG_DEFCONFIG_LIST=/lib/modules/$UNAME_RELEASE/.config # # General setup # # CONFIG_EXPERIMENTAL is not set CONFIG_LOCK_KERNEL=y CONFIG_INIT_ENV_ARG_LIMIT=32 CONFIG_LOCALVERSION= CONFIG_LOCALVERSION_AUTO=y CONFIG_SWAP=y CONFIG_SYSVIPC=y CONFIG_SYSVIPC_SYSCTL=y # CONFIG_BSD_PROCESS_ACCT is not set # CONFIG_TASKSTATS is not set # CONFIG_AUDIT is not set # # RCU Subsystem # # CONFIG_CLASSIC_RCU is not set # CONFIG_TREE_RCU is not set CONFIG_PREEMPT_RCU=y CONFIG_RCU_TRACE=y # CONFIG_TREE_RCU_TRACE is not set CONFIG_PREEMPT_RCU_TRACE=y CONFIG_IKCONFIG=m CONFIG_IKCONFIG_PROC=y CONFIG_LOG_BUF_SHIFT=17 CONFIG_CGROUPS=y CONFIG_CGROUP_DEBUG=y CONFIG_CGROUP_NS=y CONFIG_CGROUP_FREEZER=y CONFIG_CPUSETS=y # CONFIG_PROC_PID_CPUSET is not set CONFIG_CGROUP_CPUACCT=y CONFIG_RESOURCE_COUNTERS=y CONFIG_CGROUP_MEM_RES_CTLR=y CONFIG_MM_OWNER=y # CONFIG_SYSFS_DEPRECATED_V2 is not set CONFIG_RELAY=y CONFIG_NAMESPACES=y # CONFIG_UTS_NS is not set CONFIG_IPC_NS=y CONFIG_BLK_DEV_INITRD=y CONFIG_INITRAMFS_SOURCE= CONFIG_RD_GZIP=y CONFIG_RD_BZIP2=y CONFIG_RD_LZMA=y # CONFIG_CC_OPTIMIZE_FOR_SIZE is not set CONFIG_SYSCTL=y CONFIG_ANON_INODES=y CONFIG_EMBEDDED=y # CONFIG_SYSCTL_SYSCALL is not set CONFIG_KALLSYMS=y CONFIG_KALLSYMS_ALL=y CONFIG_KALLSYMS_EXTRA_PASS=y CONFIG_HOTPLUG=y # CONFIG_PRINTK is not set CONFIG_BUG=y CONFIG_ELF_CORE=y CONFIG_BASE_FULL=y CONFIG_FUTEX=y # CONFIG_EPOLL is not set CONFIG_SIGNALFD=y CONFIG_TIMERFD=y # CONFIG_EVENTFD is not set CONFIG_SHMEM=y # CONFIG_AIO is not set CONFIG_VM_EVENT_COUNTERS=y CONFIG_PCI_QUIRKS=y CONFIG_COMPAT_BRK=y # CONFIG_SLAB is not set # CONFIG_SLUB is not set # CONFIG_SLQB is not set CONFIG_SLOB=y CONFIG_PROFILING=y CONFIG_TRACEPOINTS=y CONFIG_MARKERS=y CONFIG_OPROFILE=m CONFIG_HAVE_OPROFILE=y # CONFIG_KPROBES is not set CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS=y CONFIG_HAVE_IOREMAP_PROT=y CONFIG_HAVE_KPROBES=y CONFIG_HAVE_KRETPROBES=y CONFIG_HAVE_ARCH_TRACEHOOK=y CONFIG_USE_GENERIC_SMP_HELPERS=y CONFIG_HAVE_CLK=y # CONFIG_SLOW_WORK is not set # CONFIG_HAVE_GENERIC_DMA_COHERENT is not set CONFIG_RT_MUTEXES=y CONFIG_BASE_SMALL=0 CONFIG_MODULES=y CONFIG_MODULE_FORCE_LOAD=y CONFIG_MODULE_UNLOAD=y CONFIG_MODVERSIONS=y # CONFIG_MODULE_SRCVERSION_ALL is not set CONFIG_STOP_MACHINE=y CONFIG_BLOCK=y CONFIG_LBD=y CONFIG_BLK_DEV_INTEGRITY=y # # IO Schedulers # CONFIG_IOSCHED_NOOP=y CONFIG_IOSCHED_AS=m CONFIG_IOSCHED_DEADLINE=y CONFIG_IOSCHED_CFQ=m # CONFIG_DEFAULT_AS is not set #
[BUILD FAILURE 02] Next April 9 : PPC64 randconfig [arch/powerpc/platforms/pseries/dtl.c]
Observed the following build error: arch/powerpc/platforms/pseries/dtl.c: In function ‘dtl_init’: arch/powerpc/platforms/pseries/dtl.c:238: error: implicit declaration of function ‘firmware_has_feature’ arch/powerpc/platforms/pseries/dtl.c:238: error: ‘FW_FEATURE_SPLPAR’ undeclared (first use in this function) arch/powerpc/platforms/pseries/dtl.c:238: error: (Each undeclared identifier is reported only once arch/powerpc/platforms/pseries/dtl.c:238: error: for each function it appears in.) make[2]: *** [arch/powerpc/platforms/pseries/dtl.o] Error 1 make[1]: *** [arch/powerpc/platforms/pseries] Error 2 make: *** [arch/powerpc/platforms] Error 2 Regards-- Subrata # # Automatically generated make config: don't edit # Linux kernel version: 2.6.30-rc1 # Thu Apr 9 08:25:52 2009 # CONFIG_PPC64=y # # Processor support # CONFIG_PPC_BOOK3S=y # CONFIG_POWER4_ONLY is not set CONFIG_POWER3=y CONFIG_POWER4=y # CONFIG_TUNE_CELL is not set CONFIG_PPC_FPU=y # CONFIG_ALTIVEC is not set CONFIG_PPC_STD_MMU=y CONFIG_PPC_STD_MMU_64=y CONFIG_PPC_MM_SLICES=y # CONFIG_VIRT_CPU_ACCOUNTING is not set # CONFIG_SMP is not set CONFIG_64BIT=y CONFIG_WORD_SIZE=64 CONFIG_ARCH_PHYS_ADDR_T_64BIT=y CONFIG_MMU=y CONFIG_GENERIC_CMOS_UPDATE=y CONFIG_GENERIC_TIME=y CONFIG_GENERIC_TIME_VSYSCALL=y CONFIG_GENERIC_CLOCKEVENTS=y CONFIG_GENERIC_HARDIRQS=y CONFIG_HAVE_SETUP_PER_CPU_AREA=y CONFIG_IRQ_PER_CPU=y CONFIG_STACKTRACE_SUPPORT=y CONFIG_HAVE_LATENCYTOP_SUPPORT=y CONFIG_TRACE_IRQFLAGS_SUPPORT=y CONFIG_LOCKDEP_SUPPORT=y CONFIG_RWSEM_XCHGADD_ALGORITHM=y CONFIG_ARCH_HAS_ILOG2_U32=y CONFIG_ARCH_HAS_ILOG2_U64=y CONFIG_GENERIC_HWEIGHT=y CONFIG_GENERIC_CALIBRATE_DELAY=y CONFIG_GENERIC_FIND_NEXT_BIT=y CONFIG_GENERIC_GPIO=y CONFIG_ARCH_NO_VIRT_TO_BUS=y CONFIG_PPC=y CONFIG_EARLY_PRINTK=y CONFIG_COMPAT=y CONFIG_SYSVIPC_COMPAT=y CONFIG_SCHED_OMIT_FRAME_POINTER=y CONFIG_ARCH_MAY_HAVE_PC_FDC=y CONFIG_PPC_OF=y CONFIG_OF=y CONFIG_PPC_UDBG_16550=y CONFIG_GENERIC_TBSYNC=y CONFIG_AUDIT_ARCH=y # CONFIG_DEFAULT_UIMAGE is not set CONFIG_HIBERNATE_32=y CONFIG_HIBERNATE_64=y CONFIG_ARCH_HIBERNATION_POSSIBLE=y CONFIG_ARCH_SUSPEND_POSSIBLE=y # CONFIG_PPC_DCR_NATIVE is not set CONFIG_PPC_DCR_MMIO=y CONFIG_PPC_DCR=y CONFIG_PPC_OF_PLATFORM_PCI=y CONFIG_ARCH_SUPPORTS_DEBUG_PAGEALLOC=y CONFIG_DEFCONFIG_LIST=/lib/modules/$UNAME_RELEASE/.config # # General setup # CONFIG_EXPERIMENTAL=y CONFIG_BROKEN_ON_SMP=y CONFIG_INIT_ENV_ARG_LIMIT=32 CONFIG_LOCALVERSION= CONFIG_LOCALVERSION_AUTO=y CONFIG_SYSVIPC=y CONFIG_SYSVIPC_SYSCTL=y # CONFIG_POSIX_MQUEUE is not set # CONFIG_BSD_PROCESS_ACCT is not set CONFIG_TASKSTATS=y CONFIG_TASK_DELAY_ACCT=y CONFIG_TASK_XACCT=y CONFIG_TASK_IO_ACCOUNTING=y CONFIG_AUDIT=y CONFIG_AUDITSYSCALL=y CONFIG_AUDIT_TREE=y # # RCU Subsystem # CONFIG_CLASSIC_RCU=y # CONFIG_TREE_RCU is not set # CONFIG_PREEMPT_RCU is not set # CONFIG_TREE_RCU_TRACE is not set # CONFIG_PREEMPT_RCU_TRACE is not set CONFIG_IKCONFIG=y CONFIG_LOG_BUF_SHIFT=17 CONFIG_GROUP_SCHED=y # CONFIG_FAIR_GROUP_SCHED is not set # CONFIG_RT_GROUP_SCHED is not set CONFIG_USER_SCHED=y # CONFIG_CGROUP_SCHED is not set CONFIG_CGROUPS=y # CONFIG_CGROUP_DEBUG is not set CONFIG_CGROUP_NS=y CONFIG_CGROUP_FREEZER=y CONFIG_CGROUP_DEVICE=y # CONFIG_CPUSETS is not set CONFIG_CGROUP_CPUACCT=y # CONFIG_RESOURCE_COUNTERS is not set CONFIG_SYSFS_DEPRECATED=y CONFIG_SYSFS_DEPRECATED_V2=y CONFIG_RELAY=y CONFIG_NAMESPACES=y CONFIG_UTS_NS=y # CONFIG_IPC_NS is not set CONFIG_USER_NS=y CONFIG_PID_NS=y CONFIG_NET_NS=y CONFIG_BLK_DEV_INITRD=y CONFIG_INITRAMFS_SOURCE= # CONFIG_RD_GZIP is not set CONFIG_RD_BZIP2=y CONFIG_RD_LZMA=y # CONFIG_CC_OPTIMIZE_FOR_SIZE is not set CONFIG_SYSCTL=y CONFIG_ANON_INODES=y CONFIG_EMBEDDED=y CONFIG_SYSCTL_SYSCALL=y CONFIG_KALLSYMS=y CONFIG_KALLSYMS_ALL=y CONFIG_KALLSYMS_EXTRA_PASS=y CONFIG_HOTPLUG=y CONFIG_PRINTK=y # CONFIG_BUG is not set CONFIG_ELF_CORE=y CONFIG_PCSPKR_PLATFORM=y CONFIG_BASE_FULL=y CONFIG_FUTEX=y CONFIG_EPOLL=y CONFIG_SIGNALFD=y CONFIG_TIMERFD=y CONFIG_EVENTFD=y CONFIG_SHMEM=y # CONFIG_AIO is not set CONFIG_VM_EVENT_COUNTERS=y CONFIG_PCI_QUIRKS=y CONFIG_COMPAT_BRK=y # CONFIG_SLAB is not set # CONFIG_SLUB is not set CONFIG_SLQB=y # CONFIG_SLOB is not set CONFIG_PROFILING=y CONFIG_TRACEPOINTS=y CONFIG_MARKERS=y CONFIG_OPROFILE=m CONFIG_HAVE_OPROFILE=y CONFIG_KPROBES=y CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS=y CONFIG_HAVE_SYSCALL_WRAPPERS=y CONFIG_KRETPROBES=y CONFIG_HAVE_IOREMAP_PROT=y CONFIG_HAVE_KPROBES=y CONFIG_HAVE_KRETPROBES=y CONFIG_HAVE_ARCH_TRACEHOOK=y CONFIG_HAVE_DMA_ATTRS=y # CONFIG_SLOW_WORK is not set # CONFIG_HAVE_GENERIC_DMA_COHERENT is not set CONFIG_RT_MUTEXES=y CONFIG_BASE_SMALL=0 CONFIG_MODULES=y CONFIG_MODULE_FORCE_LOAD=y CONFIG_MODULE_UNLOAD=y CONFIG_MODULE_FORCE_UNLOAD=y CONFIG_MODVERSIONS=y # CONFIG_MODULE_SRCVERSION_ALL is not set # CONFIG_BLOCK is not set CONFIG_FREEZER=y CONFIG_PPC_MSI_BITMAP=y # # Platform support # CONFIG_PPC_PSERIES=y CONFIG_PPC_SPLPAR=y CONFIG_EEH=y CONFIG_PSERIES_MSI=y CONFIG_SCANLOG=m # CONFIG_LPARCFG is not set
[BUILD FAILURE 03] Next April 9 : PPC64 randconfig [arch/powerpc/platforms/pasemi/setup.o]
Observed the following build error: CC arch/powerpc/platforms/pasemi/setup.o arch/powerpc/platforms/pasemi/setup.c:48: error: redefinition of ‘smp_send_stop’ include/linux/smp.h:125: error: previous definition of ‘smp_send_stop’ was here make[2]: *** [arch/powerpc/platforms/pasemi/setup.o] Error 1 make[1]: *** [arch/powerpc/platforms/pasemi] Error 2 make: *** [arch/powerpc/platforms] Error 2 Regards-- Subrata # # Automatically generated make config: don't edit # Linux kernel version: 2.6.30-rc1 # Thu Apr 9 06:28:12 2009 # CONFIG_PPC64=y # # Processor support # CONFIG_PPC_BOOK3S=y CONFIG_POWER4_ONLY=y CONFIG_POWER4=y # CONFIG_TUNE_CELL is not set CONFIG_PPC_FPU=y CONFIG_ALTIVEC=y # CONFIG_VSX is not set CONFIG_PPC_STD_MMU=y CONFIG_PPC_STD_MMU_64=y CONFIG_PPC_MM_SLICES=y CONFIG_VIRT_CPU_ACCOUNTING=y # CONFIG_SMP is not set CONFIG_64BIT=y CONFIG_WORD_SIZE=64 CONFIG_ARCH_PHYS_ADDR_T_64BIT=y CONFIG_MMU=y CONFIG_GENERIC_CMOS_UPDATE=y CONFIG_GENERIC_TIME=y CONFIG_GENERIC_TIME_VSYSCALL=y CONFIG_GENERIC_CLOCKEVENTS=y CONFIG_GENERIC_HARDIRQS=y CONFIG_HAVE_SETUP_PER_CPU_AREA=y CONFIG_IRQ_PER_CPU=y CONFIG_STACKTRACE_SUPPORT=y CONFIG_HAVE_LATENCYTOP_SUPPORT=y CONFIG_TRACE_IRQFLAGS_SUPPORT=y CONFIG_LOCKDEP_SUPPORT=y CONFIG_RWSEM_XCHGADD_ALGORITHM=y CONFIG_ARCH_HAS_ILOG2_U32=y CONFIG_ARCH_HAS_ILOG2_U64=y CONFIG_GENERIC_HWEIGHT=y CONFIG_GENERIC_CALIBRATE_DELAY=y CONFIG_GENERIC_FIND_NEXT_BIT=y CONFIG_GENERIC_GPIO=y CONFIG_ARCH_NO_VIRT_TO_BUS=y CONFIG_PPC=y CONFIG_EARLY_PRINTK=y CONFIG_COMPAT=y CONFIG_SYSVIPC_COMPAT=y CONFIG_SCHED_OMIT_FRAME_POINTER=y CONFIG_ARCH_MAY_HAVE_PC_FDC=y CONFIG_PPC_OF=y CONFIG_OF=y CONFIG_PPC_UDBG_16550=y CONFIG_GENERIC_TBSYNC=y CONFIG_AUDIT_ARCH=y CONFIG_GENERIC_BUG=y # CONFIG_DEFAULT_UIMAGE is not set CONFIG_HIBERNATE_32=y # CONFIG_PPC_DCR_NATIVE is not set CONFIG_PPC_DCR_MMIO=y CONFIG_PPC_DCR=y # CONFIG_PPC_OF_PLATFORM_PCI is not set CONFIG_ARCH_SUPPORTS_DEBUG_PAGEALLOC=y CONFIG_DEFCONFIG_LIST=/lib/modules/$UNAME_RELEASE/.config # # General setup # # CONFIG_EXPERIMENTAL is not set CONFIG_BROKEN_ON_SMP=y CONFIG_INIT_ENV_ARG_LIMIT=32 CONFIG_LOCALVERSION= CONFIG_LOCALVERSION_AUTO=y # CONFIG_SWAP is not set CONFIG_SYSVIPC=y CONFIG_SYSVIPC_SYSCTL=y CONFIG_BSD_PROCESS_ACCT=y # CONFIG_BSD_PROCESS_ACCT_V3 is not set CONFIG_TASKSTATS=y CONFIG_TASK_DELAY_ACCT=y CONFIG_TASK_XACCT=y CONFIG_TASK_IO_ACCOUNTING=y # CONFIG_AUDIT is not set # # RCU Subsystem # CONFIG_CLASSIC_RCU=y # CONFIG_TREE_RCU is not set # CONFIG_PREEMPT_RCU is not set # CONFIG_TREE_RCU_TRACE is not set # CONFIG_PREEMPT_RCU_TRACE is not set # CONFIG_IKCONFIG is not set CONFIG_LOG_BUF_SHIFT=17 CONFIG_CGROUPS=y CONFIG_CGROUP_DEBUG=y # CONFIG_CGROUP_NS is not set # CONFIG_CGROUP_FREEZER is not set CONFIG_CPUSETS=y CONFIG_PROC_PID_CPUSET=y # CONFIG_CGROUP_CPUACCT is not set # CONFIG_RESOURCE_COUNTERS is not set # CONFIG_SYSFS_DEPRECATED_V2 is not set CONFIG_RELAY=y CONFIG_NAMESPACES=y # CONFIG_UTS_NS is not set CONFIG_IPC_NS=y CONFIG_BLK_DEV_INITRD=y CONFIG_INITRAMFS_SOURCE= CONFIG_RD_GZIP=y CONFIG_RD_BZIP2=y CONFIG_RD_LZMA=y CONFIG_CC_OPTIMIZE_FOR_SIZE=y CONFIG_SYSCTL=y CONFIG_ANON_INODES=y # CONFIG_EMBEDDED is not set CONFIG_SYSCTL_SYSCALL=y CONFIG_KALLSYMS=y CONFIG_KALLSYMS_ALL=y CONFIG_KALLSYMS_EXTRA_PASS=y CONFIG_HOTPLUG=y CONFIG_PRINTK=y CONFIG_BUG=y CONFIG_ELF_CORE=y CONFIG_BASE_FULL=y CONFIG_FUTEX=y CONFIG_EPOLL=y CONFIG_SIGNALFD=y CONFIG_TIMERFD=y CONFIG_EVENTFD=y CONFIG_SHMEM=y CONFIG_AIO=y CONFIG_VM_EVENT_COUNTERS=y CONFIG_PCI_QUIRKS=y CONFIG_COMPAT_BRK=y CONFIG_SLAB=y # CONFIG_SLUB is not set # CONFIG_SLQB is not set # CONFIG_SLOB is not set CONFIG_PROFILING=y CONFIG_TRACEPOINTS=y CONFIG_MARKERS=y # CONFIG_OPROFILE is not set CONFIG_HAVE_OPROFILE=y CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS=y CONFIG_HAVE_SYSCALL_WRAPPERS=y CONFIG_HAVE_IOREMAP_PROT=y CONFIG_HAVE_KPROBES=y CONFIG_HAVE_KRETPROBES=y CONFIG_HAVE_ARCH_TRACEHOOK=y CONFIG_HAVE_DMA_ATTRS=y # CONFIG_SLOW_WORK is not set # CONFIG_HAVE_GENERIC_DMA_COHERENT is not set CONFIG_SLABINFO=y CONFIG_RT_MUTEXES=y CONFIG_BASE_SMALL=0 # CONFIG_MODULES is not set CONFIG_BLOCK=y # CONFIG_BLK_DEV_INTEGRITY is not set CONFIG_BLOCK_COMPAT=y # # IO Schedulers # CONFIG_IOSCHED_NOOP=y CONFIG_IOSCHED_AS=y # CONFIG_IOSCHED_DEADLINE is not set # CONFIG_IOSCHED_CFQ is not set CONFIG_DEFAULT_AS=y # CONFIG_DEFAULT_DEADLINE is not set # CONFIG_DEFAULT_CFQ is not set # CONFIG_DEFAULT_NOOP is not set CONFIG_DEFAULT_IOSCHED=anticipatory # CONFIG_FREEZER is not set # # Platform support # # CONFIG_PPC_PSERIES is not set # CONFIG_LPARCFG is not set CONFIG_PPC_ISERIES=y # # iSeries device drivers # CONFIG_VIODASD=y # CONFIG_VIOCD is not set CONFIG_VIOTAPE=y CONFIG_VIOPATH=y CONFIG_PPC_PMAC=y CONFIG_PPC_PMAC64=y # CONFIG_PPC_MAPLE is not set CONFIG_PPC_PASEMI=y # # PA Semi PWRficient options # CONFIG_PPC_PASEMI_IOMMU=y # CONFIG_PPC_PASEMI_IOMMU_DMA_FORCE is not set # CONFIG_PPC_PS3 is not set CONFIG_PPC_CELL=y CONFIG_PPC_CELL_COMMON=y # CONFIG_PPC_CELL_NATIVE is not set # CONFIG_PPC_IBM_CELL_BLADE
[BUILD FAILURE 04] Next April 9 : PPC64 randconfig [drivers/net/ibm_newemac/core.c]
Observed the following build error: CC drivers/net/ibm_newemac/core.o drivers/net/ibm_newemac/core.c: In function ‘emac_probe’: drivers/net/ibm_newemac/core.c:2831: error: ‘struct net_device’ has no member named ‘open’ drivers/net/ibm_newemac/core.c:2834: error: ‘struct net_device’ has no member named ‘tx_timeout’ drivers/net/ibm_newemac/core.c:2836: error: ‘struct net_device’ has no member named ‘stop’ drivers/net/ibm_newemac/core.c:2837: error: ‘struct net_device’ has no member named ‘get_stats’ drivers/net/ibm_newemac/core.c:2838: error: ‘struct net_device’ has no member named ‘set_multicast_list’ drivers/net/ibm_newemac/core.c:2839: error: ‘struct net_device’ has no member named ‘do_ioctl’ drivers/net/ibm_newemac/core.c:2841: error: ‘struct net_device’ has no member named ‘hard_start_xmit’ drivers/net/ibm_newemac/core.c:2842: error: ‘struct net_device’ has no member named ‘change_mtu’ drivers/net/ibm_newemac/core.c:2845: error: ‘struct net_device’ has no member named ‘hard_start_xmit’ make[3]: *** [drivers/net/ibm_newemac/core.o] Error 1 make[2]: *** [drivers/net/ibm_newemac] Error 2 make[1]: *** [drivers/net] Error 2 make: *** [drivers] Error 2 Regards-- Subrata # # Automatically generated make config: don't edit # Linux kernel version: 2.6.30-rc1 # Thu Apr 9 06:28:20 2009 # CONFIG_PPC64=y # # Processor support # CONFIG_PPC_BOOK3S=y # CONFIG_POWER4_ONLY is not set CONFIG_POWER3=y CONFIG_POWER4=y CONFIG_TUNE_CELL=y CONFIG_PPC_FPU=y CONFIG_ALTIVEC=y CONFIG_VSX=y CONFIG_PPC_STD_MMU=y CONFIG_PPC_STD_MMU_64=y # CONFIG_PPC_MM_SLICES is not set # CONFIG_VIRT_CPU_ACCOUNTING is not set CONFIG_SMP=y CONFIG_NR_CPUS=32 CONFIG_64BIT=y CONFIG_WORD_SIZE=64 CONFIG_ARCH_PHYS_ADDR_T_64BIT=y CONFIG_MMU=y CONFIG_GENERIC_CMOS_UPDATE=y CONFIG_GENERIC_TIME=y CONFIG_GENERIC_TIME_VSYSCALL=y CONFIG_GENERIC_CLOCKEVENTS=y CONFIG_GENERIC_HARDIRQS=y CONFIG_HAVE_SETUP_PER_CPU_AREA=y CONFIG_IRQ_PER_CPU=y CONFIG_STACKTRACE_SUPPORT=y CONFIG_HAVE_LATENCYTOP_SUPPORT=y CONFIG_TRACE_IRQFLAGS_SUPPORT=y CONFIG_LOCKDEP_SUPPORT=y CONFIG_RWSEM_XCHGADD_ALGORITHM=y CONFIG_ARCH_HAS_ILOG2_U32=y CONFIG_ARCH_HAS_ILOG2_U64=y CONFIG_GENERIC_HWEIGHT=y CONFIG_GENERIC_CALIBRATE_DELAY=y CONFIG_GENERIC_FIND_NEXT_BIT=y CONFIG_ARCH_NO_VIRT_TO_BUS=y CONFIG_PPC=y CONFIG_EARLY_PRINTK=y CONFIG_COMPAT=y CONFIG_SYSVIPC_COMPAT=y CONFIG_SCHED_OMIT_FRAME_POINTER=y CONFIG_ARCH_MAY_HAVE_PC_FDC=y CONFIG_PPC_OF=y CONFIG_OF=y CONFIG_PPC_UDBG_16550=y CONFIG_GENERIC_TBSYNC=y CONFIG_AUDIT_ARCH=y CONFIG_GENERIC_BUG=y # CONFIG_DEFAULT_UIMAGE is not set # CONFIG_PPC_DCR_NATIVE is not set CONFIG_PPC_DCR_MMIO=y CONFIG_PPC_DCR=y CONFIG_PPC_OF_PLATFORM_PCI=y CONFIG_ARCH_SUPPORTS_DEBUG_PAGEALLOC=y CONFIG_DEFCONFIG_LIST=/lib/modules/$UNAME_RELEASE/.config # # General setup # CONFIG_EXPERIMENTAL=y CONFIG_LOCK_KERNEL=y CONFIG_INIT_ENV_ARG_LIMIT=32 CONFIG_LOCALVERSION= CONFIG_LOCALVERSION_AUTO=y CONFIG_SYSVIPC=y # CONFIG_POSIX_MQUEUE is not set # CONFIG_BSD_PROCESS_ACCT is not set CONFIG_TASKSTATS=y CONFIG_TASK_DELAY_ACCT=y CONFIG_TASK_XACCT=y CONFIG_TASK_IO_ACCOUNTING=y CONFIG_AUDIT=y CONFIG_AUDITSYSCALL=y CONFIG_AUDIT_TREE=y # # RCU Subsystem # CONFIG_CLASSIC_RCU=y # CONFIG_TREE_RCU is not set # CONFIG_PREEMPT_RCU is not set # CONFIG_TREE_RCU_TRACE is not set # CONFIG_PREEMPT_RCU_TRACE is not set CONFIG_IKCONFIG=y CONFIG_LOG_BUF_SHIFT=17 # CONFIG_GROUP_SCHED is not set # CONFIG_CGROUPS is not set CONFIG_SYSFS_DEPRECATED=y CONFIG_SYSFS_DEPRECATED_V2=y # CONFIG_RELAY is not set CONFIG_NAMESPACES=y CONFIG_UTS_NS=y CONFIG_IPC_NS=y CONFIG_USER_NS=y CONFIG_PID_NS=y # CONFIG_NET_NS is not set # CONFIG_BLK_DEV_INITRD is not set CONFIG_CC_OPTIMIZE_FOR_SIZE=y CONFIG_ANON_INODES=y CONFIG_EMBEDDED=y # CONFIG_SYSCTL_SYSCALL is not set CONFIG_KALLSYMS=y CONFIG_KALLSYMS_ALL=y CONFIG_KALLSYMS_EXTRA_PASS=y # CONFIG_HOTPLUG is not set CONFIG_PRINTK=y CONFIG_BUG=y CONFIG_ELF_CORE=y CONFIG_PCSPKR_PLATFORM=y CONFIG_BASE_FULL=y # CONFIG_FUTEX is not set # CONFIG_EPOLL is not set # CONFIG_SIGNALFD is not set CONFIG_TIMERFD=y CONFIG_EVENTFD=y CONFIG_SHMEM=y CONFIG_AIO=y CONFIG_VM_EVENT_COUNTERS=y CONFIG_PCI_QUIRKS=y # CONFIG_SLUB_DEBUG is not set CONFIG_COMPAT_BRK=y # CONFIG_SLAB is not set CONFIG_SLUB=y # CONFIG_SLQB is not set # CONFIG_SLOB is not set CONFIG_PROFILING=y CONFIG_TRACEPOINTS=y CONFIG_MARKERS=y # CONFIG_OPROFILE is not set CONFIG_HAVE_OPROFILE=y CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS=y CONFIG_HAVE_SYSCALL_WRAPPERS=y CONFIG_HAVE_IOREMAP_PROT=y CONFIG_HAVE_KPROBES=y CONFIG_HAVE_KRETPROBES=y CONFIG_HAVE_ARCH_TRACEHOOK=y CONFIG_HAVE_DMA_ATTRS=y CONFIG_USE_GENERIC_SMP_HELPERS=y CONFIG_SLOW_WORK=y # CONFIG_HAVE_GENERIC_DMA_COHERENT is not set CONFIG_BASE_SMALL=0 # CONFIG_MODULES is not set # CONFIG_BLOCK is not set # CONFIG_FREEZER is not set CONFIG_PPC_MSI_BITMAP=y # # Platform support # CONFIG_PPC_PSERIES=y # CONFIG_PPC_SPLPAR is not set CONFIG_EEH=y CONFIG_PSERIES_MSI=y CONFIG_SCANLOG=y CONFIG_LPARCFG=y CONFIG_PPC_PSERIES_DEBUG=y CONFIG_PPC_SMLPAR=y CONFIG_CMM=y # CONFIG_PPC_ISERIES
RE: [PATCH] Xilinx : Framebuffer Driver: Add PLB support (non-DCR)
-Original Message- From: Stephen Rothwell [mailto:s...@canb.auug.org.au] Sent: Wednesday, April 08, 2009 7:52 PM To: John Linn Cc: grant.lik...@secretlab.ca; jwbo...@linux.vnet.ibm.com; linuxppc-dev@ozlabs.org; linux-fbdev-de...@lists.sourceforge.net; akonova...@ru.mvista.com; adap...@gmail.com; Suneel Garapati; Suneel Subject: Re: [PATCH] Xilinx : Framebuffer Driver: Add PLB support (non-DCR) Hi John, On Wed, 8 Apr 2009 15:11:25 -0600 John Linn john.l...@xilinx.com wrote: * 2002-2007 (c) MontaVista Software, Inc. * 2007 (c) Secret Lab Technologies, Ltd. + * 2009 (c) Xilinx Inc. * - * This file is licensed under the terms of the GNU General Public License - * version 2. This program is licensed as is without any warranty of any - * kind, whether express or implied. + * 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. + * + * You should have received a copy of the GNU General Public + * License along with this program; if not, write to the Free + * Software Foundation, Inc., 675 Mass Ave, Cambridge, MA + * 02139, USA. This changes the license for this file (from GPLv2 to GPLv2 or later). Have you asked the other copyright owners about that? Andrei was copied on the patch, we'll see if he has any thoughts about it. Thanks, John -- Cheers, Stephen Rothwells...@canb.auug.org.au http://www.canb.auug.org.au/~sfr/ This email and any attachments are intended for the sole use of the named recipient(s) and contain(s) confidential information that may be proprietary, privileged or copyrighted under applicable law. If you are not the intended recipient, do not read, copy, or forward this email message or any attachments. Delete this email message and any attachments immediately. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] Xilinx : Framebuffer Driver: Add PLB support (non-DCR)
On Thu, Apr 9, 2009 at 2:46 PM, Josh Boyer jwbo...@linux.vnet.ibm.comwrote:
On Wed, Apr 08, 2009 at 03:11:25PM -0600, John Linn wrote:
From: Suneel [mailto:suneel.garap...@xilinx.com]
Added support for the new xps tft controller.
The new core has PLB interface support in addition to existing
DCR interface.
The driver has been modified to support this new core which
can be connected on PLB or DCR bus.
Signed-off-by: Suneel sune...@xilinx.com
Signed-off-by: John Linn john.l...@xilinx.com
---
drivers/video/xilinxfb.c | 227
--
1 files changed, 160 insertions(+), 67 deletions(-)
diff --git a/drivers/video/xilinxfb.c b/drivers/video/xilinxfb.c
index a82c530..a28a834 100644
--- a/drivers/video/xilinxfb.c
+++ b/drivers/video/xilinxfb.c
@@ -1,17 +1,24 @@
/*
- * xilinxfb.c
*
- * Xilinx TFT LCD frame buffer driver
+ * Xilinx TFT frame buffer driver
*
* Author: MontaVista Software, Inc.
* sou...@mvista.com
*
* 2002-2007 (c) MontaVista Software, Inc.
* 2007 (c) Secret Lab Technologies, Ltd.
+ * 2009 (c) Xilinx Inc.
*
- * This file is licensed under the terms of the GNU General Public
License
- * version 2. This program is licensed as is without any warranty of
any
- * kind, whether express or implied.
+ * 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.
+ *
+ * You should have received a copy of the GNU General Public
+ * License along with this program; if not, write to the Free
+ * Software Foundation, Inc., 675 Mass Ave, Cambridge, MA
+ * 02139, USA.
*/
What Stephen said.
#define NUM_REGS 2
#define REG_FB_ADDR 0
@@ -112,6 +123,11 @@ struct xilinxfb_drvdata {
struct fb_info info; /* FB driver info record */
+ u32 regs_phys; /* phys. address of the control
+ registers */
Is this driver usable on the 440 based Xilinx devices? If so, is it
possible
to have the physical address of the registers above 4GiB, so is common with
almost all the I/O on the other 440 boards?
The driver works fine on 440 based Xilinx boards (the ML510 I use has a 440
core). It might be nice to move physical addresses above 4GB for devices but
in all Xilinx tools and reference designs addresses below 4GB are used for
periperhals and I think even below 2GB (or even below 1GB). It depends on
the design.
Roderick Colenbrander
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] AOA: Convert onyx and tas codecs to new-style i2c drivers
Hi Johannes,
On Thu, 09 Apr 2009 14:34:44 +0200, Johannes Berg wrote:
My new approach doesn't auto-load anything. Here we go, what you think?
This time there is no logic change, I'm really only turning legacy code
into new-style i2c code (basically calling i2c_new_device() instead of
i2c_attach_client()) and that's about it.
(Once again this is only build-tested and I would like people with the
hardware to give it a try.)
Looks reasonable.
static int onyx_create(struct i2c_adapter *adapter,
struct device_node *node,
int addr)
{
+ struct i2c_board_info info;
+ struct i2c_client *client;
+
+ memset(info, 0, sizeof(struct i2c_board_info));
+ strlcpy(info.type, aoa_codec_onyx, I2C_NAME_SIZE);
+ if (node) {
+ info.addr = addr;
+ info.platform_data = node;
+ client = i2c_new_device(adapter, info);
+ } else {
+ /* probe both possible addresses for the onyx chip */
+ unsigned short probe_onyx[] = {
+ 0x46, 0x47, I2C_CLIENT_END
+ };
+
+ client = i2c_new_probed_device(adapter, info, probe_onyx);
+ }
+ if (!client)
+ return -ENODEV;
+
+ list_add_tail(client-detected, client-driver-clients);
That list_add looks a little hackish, and wouldn't it be racy?
Yes it is a little hackish, the idea is to let i2c-core remove the
device if our i2c_driver is removed (which happens when you rmmod the
module). I'll add a comment to explain that. If there are more use
cases I might move that to a helper function in i2c-core.
No it's not racy, we're called with i2c-core's main mutex held.
+static const struct i2c_device_id onyx_i2c_id[] = {
+ { aoa_codec_onyx, 0 },
+ { }
+};
+MODULE_DEVICE_TABLE(i2c, onyx_i2c_id);
Should it really export the device table?
(same comments for tas)
No, that's a leftover, I intended to remove it but forgot. It's gone
now. That being said, it's useless, but I don't think it would hurt.
It'll be until mid next week that I can test anything.
OK, thanks.
--
Jean Delvare
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
converting fs_enet to net_device_ops
Can someone look at converting drivers/net/fs_enet over to the new net_device_ops. Dave, Are you willing to take such a patch in for .30? Otherwise we need to add a select COMPAT_NET_DEV_OPS in Kconfig for this driver (and any others that might not have been converted over). drivers/net/ ibm_newemac/ is another. - k ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [BUILD FAILURE 01] Next April 9 : PPC64 randconfig [drivers/net/fs_enet/fs_enet-main.c]
On Apr 9, 2009, at 8:50 AM, Subrata Modak wrote: Observed the following build error: drivers/net/fs_enet/fs_enet-main.c: In function ‘fs_enet_probe’: drivers/net/fs_enet/fs_enet-main.c:1096: error: ‘struct net_device’ has no member named ‘open’ drivers/net/fs_enet/fs_enet-main.c:1097: error: ‘struct net_device’ has no member named ‘hard_start_xmit’ drivers/net/fs_enet/fs_enet-main.c:1098: error: ‘struct net_device’ has no member named ‘tx_timeout’ drivers/net/fs_enet/fs_enet-main.c:1100: error: ‘struct net_device’ has no member named ‘stop’ drivers/net/fs_enet/fs_enet-main.c:1101: error: ‘struct net_device’ has no member named ‘get_stats’ drivers/net/fs_enet/fs_enet-main.c:1102: error: ‘struct net_device’ has no member named ‘set_multicast_list’ drivers/net/fs_enet/fs_enet-main.c:: error: ‘struct net_device’ has no member named ‘do_ioctl’ make[3]: *** [drivers/net/fs_enet/fs_enet-main.o] Error 1 make[2]: *** [drivers/net/fs_enet] Error 2 make[1]: *** [drivers/net] Error 2 make: *** [drivers] Error 2 Regards-- Subrata randconfig1-ppc64-next20090409.txt This is because CONFIG_COMPAT_NET_DEV_OPS isnt set and needs to be for this driver to build. I've asked the netdev guys about either fixing the driver or adding the proper thing to Kconfig to select CONFIG_COMPAT_NET_DEV_OPS. - k ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [BUILD FAILURE 04] Next April 9 : PPC64 randconfig [drivers/net/ibm_newemac/core.c]
On Apr 9, 2009, at 8:52 AM, Subrata Modak wrote: Observed the following build error: CC drivers/net/ibm_newemac/core.o drivers/net/ibm_newemac/core.c: In function ‘emac_probe’: drivers/net/ibm_newemac/core.c:2831: error: ‘struct net_device’ has no member named ‘open’ drivers/net/ibm_newemac/core.c:2834: error: ‘struct net_device’ has no member named ‘tx_timeout’ drivers/net/ibm_newemac/core.c:2836: error: ‘struct net_device’ has no member named ‘stop’ drivers/net/ibm_newemac/core.c:2837: error: ‘struct net_device’ has no member named ‘get_stats’ drivers/net/ibm_newemac/core.c:2838: error: ‘struct net_device’ has no member named ‘set_multicast_list’ drivers/net/ibm_newemac/core.c:2839: error: ‘struct net_device’ has no member named ‘do_ioctl’ drivers/net/ibm_newemac/core.c:2841: error: ‘struct net_device’ has no member named ‘hard_start_xmit’ drivers/net/ibm_newemac/core.c:2842: error: ‘struct net_device’ has no member named ‘change_mtu’ drivers/net/ibm_newemac/core.c:2845: error: ‘struct net_device’ has no member named ‘hard_start_xmit’ make[3]: *** [drivers/net/ibm_newemac/core.o] Error 1 make[2]: *** [drivers/net/ibm_newemac] Error 2 make[1]: *** [drivers/net] Error 2 make: *** [drivers] Error 2 Regards-- Subrata randconfig4-ppc64-next20090409.txt This is because CONFIG_COMPAT_NET_DEV_OPS isnt set and needs to be for this driver to build. I've asked the netdev guys about either fixing the driver or adding the proper thing to Kconfig to select CONFIG_COMPAT_NET_DEV_OPS. - k ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] Xilinx : Framebuffer Driver: Add PLB support (non-DCR)
On Thu, Apr 9, 2009 at 7:16 AM, John Linn john.l...@xilinx.com wrote: -Original Message- From: Stephen Rothwell [mailto:s...@canb.auug.org.au] Sent: Wednesday, April 08, 2009 7:52 PM To: John Linn Cc: grant.lik...@secretlab.ca; jwbo...@linux.vnet.ibm.com; linuxppc-dev@ozlabs.org; linux-fbdev-de...@lists.sourceforge.net; akonova...@ru.mvista.com; adap...@gmail.com; Suneel Garapati; Suneel Subject: Re: [PATCH] Xilinx : Framebuffer Driver: Add PLB support (non-DCR) Hi John, On Wed, 8 Apr 2009 15:11:25 -0600 John Linn john.l...@xilinx.com wrote: * 2002-2007 (c) MontaVista Software, Inc. * 2007 (c) Secret Lab Technologies, Ltd. + * 2009 (c) Xilinx Inc. * - * This file is licensed under the terms of the GNU General Public License - * version 2. This program is licensed as is without any warranty of any - * kind, whether express or implied. + * 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. + * + * You should have received a copy of the GNU General Public + * License along with this program; if not, write to the Free + * Software Foundation, Inc., 675 Mass Ave, Cambridge, MA + * 02139, USA. This changes the license for this file (from GPLv2 to GPLv2 or later). Have you asked the other copyright owners about that? Andrei was copied on the patch, we'll see if he has any thoughts about it. I also hold copyright on this file and I want the license to stay GPLv2. 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: [BUILD FAILURE 04] Next April 9 : PPC64 randconfig [drivers/net/ibm_newemac/core.c]
On Thu, Apr 09, 2009 at 09:28:23AM -0500, Kumar Gala wrote: On Apr 9, 2009, at 8:52 AM, Subrata Modak wrote: Observed the following build error: CC drivers/net/ibm_newemac/core.o drivers/net/ibm_newemac/core.c: In function ‘emac_probe’: drivers/net/ibm_newemac/core.c:2831: error: ‘struct net_device’ has no member named ‘open’ drivers/net/ibm_newemac/core.c:2834: error: ‘struct net_device’ has no member named ‘tx_timeout’ drivers/net/ibm_newemac/core.c:2836: error: ‘struct net_device’ has no member named ‘stop’ drivers/net/ibm_newemac/core.c:2837: error: ‘struct net_device’ has no member named ‘get_stats’ drivers/net/ibm_newemac/core.c:2838: error: ‘struct net_device’ has no member named ‘set_multicast_list’ drivers/net/ibm_newemac/core.c:2839: error: ‘struct net_device’ has no member named ‘do_ioctl’ drivers/net/ibm_newemac/core.c:2841: error: ‘struct net_device’ has no member named ‘hard_start_xmit’ drivers/net/ibm_newemac/core.c:2842: error: ‘struct net_device’ has no member named ‘change_mtu’ drivers/net/ibm_newemac/core.c:2845: error: ‘struct net_device’ has no member named ‘hard_start_xmit’ make[3]: *** [drivers/net/ibm_newemac/core.o] Error 1 make[2]: *** [drivers/net/ibm_newemac] Error 2 make[1]: *** [drivers/net] Error 2 make: *** [drivers] Error 2 Regards-- Subrata randconfig4-ppc64-next20090409.txt This is because CONFIG_COMPAT_NET_DEV_OPS isnt set and needs to be for this driver to build. I've asked the netdev guys about either fixing the driver or adding the proper thing to Kconfig to select CONFIG_COMPAT_NET_DEV_OPS. Thanks! If someone has pointers on what needs to be done to fix it, let me know. josh ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] Xilinx : Framebuffer Driver: Add PLB support (non-DCR)
On Thu, Apr 09, 2009 at 04:06:56PM +0200, Roderick Colenbrander wrote:
On Thu, Apr 9, 2009 at 2:46 PM, Josh Boyer jwbo...@linux.vnet.ibm.comwrote:
#define NUM_REGS 2
#define REG_FB_ADDR 0
@@ -112,6 +123,11 @@ struct xilinxfb_drvdata {
struct fb_info info; /* FB driver info record */
+ u32 regs_phys; /* phys. address of the control
+ registers */
Is this driver usable on the 440 based Xilinx devices? If so, is it
possible
to have the physical address of the registers above 4GiB, so is common with
almost all the I/O on the other 440 boards?
The driver works fine on 440 based Xilinx boards (the ML510 I use has a 440
core). It might be nice to move physical addresses above 4GB for devices but
in all Xilinx tools and reference designs addresses below 4GB are used for
periperhals and I think even below 2GB (or even below 1GB). It depends on
the design.
Right. The depends on the design part is what I'm worried about. Perhaps
using resource_size_t here is more appropriate, given that designs can change
and put the regs above 4GiB. That way you can set the Kconfig option
appropriately for both cases.
josh
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
RE: [PATCH] Xilinx : Framebuffer Driver: Add PLB support (non-DCR)
-Original Message-
From: Josh Boyer [mailto:jwbo...@linux.vnet.ibm.com]
Sent: Thursday, April 09, 2009 6:47 AM
To: John Linn
Cc: grant.lik...@secretlab.ca; linuxppc-dev@ozlabs.org;
linux-fbdev-de...@lists.sourceforge.net;
akonova...@ru.mvista.com; adap...@gmail.com; Suneel; Suneel Garapati
Subject: Re: [PATCH] Xilinx : Framebuffer Driver: Add PLB
support (non-DCR)
On Wed, Apr 08, 2009 at 03:11:25PM -0600, John Linn wrote:
From: Suneel [mailto:suneel.garap...@xilinx.com]
Added support for the new xps tft controller.
The new core has PLB interface support in addition to existing
DCR interface.
The driver has been modified to support this new core which
can be connected on PLB or DCR bus.
Signed-off-by: Suneel sune...@xilinx.com
Signed-off-by: John Linn john.l...@xilinx.com
---
drivers/video/xilinxfb.c | 227
--
1 files changed, 160 insertions(+), 67 deletions(-)
diff --git a/drivers/video/xilinxfb.c b/drivers/video/xilinxfb.c
index a82c530..a28a834 100644
--- a/drivers/video/xilinxfb.c
+++ b/drivers/video/xilinxfb.c
@@ -1,17 +1,24 @@
/*
- * xilinxfb.c
*
- * Xilinx TFT LCD frame buffer driver
+ * Xilinx TFT frame buffer driver
*
* Author: MontaVista Software, Inc.
* sou...@mvista.com
*
* 2002-2007 (c) MontaVista Software, Inc.
* 2007 (c) Secret Lab Technologies, Ltd.
+ * 2009 (c) Xilinx Inc.
*
- * This file is licensed under the terms of the GNU General
Public License
- * version 2. This program is licensed as is without any
warranty of any
- * kind, whether express or implied.
+ * 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.
+ *
+ * You should have received a copy of the GNU General Public
+ * License along with this program; if not, write to the Free
+ * Software Foundation, Inc., 675 Mass Ave, Cambridge, MA
+ * 02139, USA.
*/
What Stephen said.
Grant commented, I'll respin it after other comments to leave that
alone.
#define NUM_REGS2
#define REG_FB_ADDR 0
@@ -112,6 +123,11 @@ struct xilinxfb_drvdata {
struct fb_info info; /* FB driver info record */
+u32 regs_phys; /* phys. address of the control
+registers */
Is this driver usable on the 440 based Xilinx devices? If
so, is it possible
to have the physical address of the registers above 4GiB, so
is common with
almost all the I/O on the other 440 boards?
It is used on the 440. As Roderick said,
devices are mapped using the 32 bits of address in the Xilinx tools so
it would be best to stay below 4 Gig to my knowledge.
+void __iomem*regs; /* virt. address of the control
+registers */
+
dcr_host_t dcr_host;
unsigned intdcr_start;
unsigned intdcr_len;
@@ -120,6 +136,10 @@ struct xilinxfb_drvdata {
dma_addr_t fb_phys;/* phys. address of the
frame buffer */
int fb_alloced; /* Flag, was the fb
memory alloced? */
+u32 dcr_splb_slave_if;
+/* True, if control interface is
+connected through plb */
+
Do you need a full 32-bit variable for a simple boolean? It
might be best for
structure alignment, but you might want to look at using a
flags variable or
something that could be extended with feature bits in a single word.
It could be a flag I think. This was easy as it mapped to the device
tree property.
u32 reg_ctrl_default;
u32 pseudo_palette[PALETTE_ENTRIES_NO];
@@ -130,14 +150,19 @@ struct xilinxfb_drvdata {
container_of(_info, struct xilinxfb_drvdata, info)
/*
- * The LCD controller has DCR interface to its registers, but all
- * the boards and configurations the driver has been tested with
- * use opb2dcr bridge. So the registers are seen as memory mapped.
- * This macro is to make it simple to add the direct DCR access
- * when it's needed.
+ * The XPS TFT Controller can be accessed through PLB or
DCR interface.
+ * To perform the read/write on the registers we need to check on
+ * which bus its connected and call the appropriate write API.
*/
-#define xilinx_fb_out_be32(driverdata, offset, val) \
-dcr_write(driverdata-dcr_host, offset, val)
+static void xilinx_fb_out_be32(struct xilinxfb_drvdata
*drvdata, u32 offset,
+u32 val)
+{
+if (drvdata-dcr_splb_slave_if == 1)
+out_be32(drvdata-regs + (offset 2), val);
+else
+dcr_write(drvdata-dcr_host, offset, val);
+
+}
static int
Re: [PATCH] Xilinx : Framebuffer Driver: Add PLB support (non-DCR)
On Thu, Apr 9, 2009 at 7:06 AM, Roderick Colenbrander
thunderbir...@gmail.com wrote:
On Thu, Apr 9, 2009 at 2:46 PM, Josh Boyer jwbo...@linux.vnet.ibm.com
wrote:
On Wed, Apr 08, 2009 at 03:11:25PM -0600, John Linn wrote:
From: Suneel [mailto:suneel.garap...@xilinx.com]
Added support for the new xps tft controller.
The new core has PLB interface support in addition to existing
DCR interface.
The driver has been modified to support this new core which
can be connected on PLB or DCR bus.
Signed-off-by: Suneel sune...@xilinx.com
Signed-off-by: John Linn john.l...@xilinx.com
---
drivers/video/xilinxfb.c | 227
--
1 files changed, 160 insertions(+), 67 deletions(-)
diff --git a/drivers/video/xilinxfb.c b/drivers/video/xilinxfb.c
index a82c530..a28a834 100644
--- a/drivers/video/xilinxfb.c
+++ b/drivers/video/xilinxfb.c
@@ -1,17 +1,24 @@
/*
- * xilinxfb.c
*
- * Xilinx TFT LCD frame buffer driver
+ * Xilinx TFT frame buffer driver
*
* Author: MontaVista Software, Inc.
* sou...@mvista.com
*
* 2002-2007 (c) MontaVista Software, Inc.
* 2007 (c) Secret Lab Technologies, Ltd.
+ * 2009 (c) Xilinx Inc.
*
- * This file is licensed under the terms of the GNU General Public
License
- * version 2. This program is licensed as is without any warranty of
any
- * kind, whether express or implied.
+ * 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.
+ *
+ * You should have received a copy of the GNU General Public
+ * License along with this program; if not, write to the Free
+ * Software Foundation, Inc., 675 Mass Ave, Cambridge, MA
+ * 02139, USA.
*/
What Stephen said.
#define NUM_REGS 2
#define REG_FB_ADDR 0
@@ -112,6 +123,11 @@ struct xilinxfb_drvdata {
struct fb_info info; /* FB driver info record */
+ u32 regs_phys; /* phys. address of the control
+ registers */
Is this driver usable on the 440 based Xilinx devices? If so, is it
possible
to have the physical address of the registers above 4GiB, so is common
with
almost all the I/O on the other 440 boards?
The driver works fine on 440 based Xilinx boards (the ML510 I use has a 440
core). It might be nice to move physical addresses above 4GB for devices but
in all Xilinx tools and reference designs addresses below 4GB are used for
periperhals and I think even below 2GB (or even below 1GB). It depends on
the design.
Regardless, it is good practice to use phys_addr_t instead of u32 for
physical addresses.
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] Xilinx : Framebuffer Driver: Add PLB support (non-DCR)
-Original Message-
From: Grant Likely [mailto:grant.lik...@secretlab.ca]
Sent: Thursday, April 09, 2009 8:35 AM
To: Roderick Colenbrander
Cc: Josh Boyer; linux-fbdev-de...@lists.sourceforge.net;
adap...@gmail.com; Suneel Garapati; linuxppc-dev@ozlabs.org;
akonova...@ru.mvista.com; John Linn
Subject: Re: [PATCH] Xilinx : Framebuffer Driver: Add PLB
support (non-DCR)
On Thu, Apr 9, 2009 at 7:06 AM, Roderick Colenbrander
thunderbir...@gmail.com wrote:
On Thu, Apr 9, 2009 at 2:46 PM, Josh Boyer
jwbo...@linux.vnet.ibm.com
wrote:
On Wed, Apr 08, 2009 at 03:11:25PM -0600, John Linn wrote:
From: Suneel [mailto:suneel.garap...@xilinx.com]
Added support for the new xps tft controller.
The new core has PLB interface support in addition to existing
DCR interface.
The driver has been modified to support this new core which
can be connected on PLB or DCR bus.
Signed-off-by: Suneel sune...@xilinx.com
Signed-off-by: John Linn john.l...@xilinx.com
---
drivers/video/xilinxfb.c | 227
--
1 files changed, 160 insertions(+), 67 deletions(-)
diff --git a/drivers/video/xilinxfb.c b/drivers/video/xilinxfb.c
index a82c530..a28a834 100644
--- a/drivers/video/xilinxfb.c
+++ b/drivers/video/xilinxfb.c
@@ -1,17 +1,24 @@
/*
- * xilinxfb.c
*
- * Xilinx TFT LCD frame buffer driver
+ * Xilinx TFT frame buffer driver
*
* Author: MontaVista Software, Inc.
* sou...@mvista.com
*
* 2002-2007 (c) MontaVista Software, Inc.
* 2007 (c) Secret Lab Technologies, Ltd.
+ * 2009 (c) Xilinx Inc.
*
- * This file is licensed under the terms of the GNU
General Public
License
- * version 2. This program is licensed as is without
any warranty of
any
- * kind, whether express or implied.
+ * 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.
+ *
+ * You should have received a copy of the GNU General Public
+ * License along with this program; if not, write to the Free
+ * Software Foundation, Inc., 675 Mass Ave, Cambridge, MA
+ * 02139, USA.
*/
What Stephen said.
#define NUM_REGS 2
#define REG_FB_ADDR 0
@@ -112,6 +123,11 @@ struct xilinxfb_drvdata {
struct fb_info info; /* FB driver info record */
+ u32 regs_phys; /* phys. address
of the control
+ registers */
Is this driver usable on the 440 based Xilinx devices? If
so, is it
possible
to have the physical address of the registers above 4GiB,
so is common
with
almost all the I/O on the other 440 boards?
The driver works fine on 440 based Xilinx boards (the ML510
I use has a 440
core). It might be nice to move physical addresses above
4GB for devices but
in all Xilinx tools and reference designs addresses below
4GB are used for
periperhals and I think even below 2GB (or even below 1GB).
It depends on
the design.
Regardless, it is good practice to use phys_addr_t instead of u32 for
physical addresses.
I can change that when I respin to incorporate comments.
Thanks,
John
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
This email and any attachments are intended for the sole use of the named
recipient(s) and contain(s) confidential information that may be proprietary,
privileged or copyrighted under applicable law. If you are not the intended
recipient, do not read, copy, or forward this email message or any attachments.
Delete this email message and any attachments immediately.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] fs_enet: convert to netdev_ops
Reported-by: Subrata Modak subr...@linux.vnet.ibm.com
Signed-off-by: Alexander Beregalov a.berega...@gmail.com
---
drivers/net/fs_enet/fs_enet-main.c | 27 +--
1 files changed, 17 insertions(+), 10 deletions(-)
diff --git a/drivers/net/fs_enet/fs_enet-main.c
b/drivers/net/fs_enet/fs_enet-main.c
index b037ce9..a9cbc31 100644
--- a/drivers/net/fs_enet/fs_enet-main.c
+++ b/drivers/net/fs_enet/fs_enet-main.c
@@ -1019,6 +1019,22 @@ out_put_phy:
#define IS_FEC(match) 0
#endif
+static const struct net_device_ops fs_enet_netdev_ops = {
+ .ndo_open = fs_enet_open,
+ .ndo_stop = fs_enet_close,
+ .ndo_get_stats = fs_enet_get_stats,
+ .ndo_start_xmit = fs_enet_start_xmit,
+ .ndo_tx_timeout = fs_timeout,
+ .ndo_set_multicast_list = fs_set_multicast_list,
+ .ndo_do_ioctl = fs_ioctl,
+ .ndo_validate_addr = eth_validate_addr,
+ .ndo_set_mac_address= eth_mac_addr,
+ .ndo_change_mtu = eth_change_mtu,
+#ifdef CONFIG_NET_POLL_CONTROLLER
+ .ndo_poll_controller= fs_enet_netpoll,
+#endif
+};
+
static int __devinit fs_enet_probe(struct of_device *ofdev,
const struct of_device_id *match)
{
@@ -1093,22 +1109,13 @@ static int __devinit fs_enet_probe(struct of_device
*ofdev,
fep-tx_ring = fpi-tx_ring;
fep-rx_ring = fpi-rx_ring;
- ndev-open = fs_enet_open;
- ndev-hard_start_xmit = fs_enet_start_xmit;
- ndev-tx_timeout = fs_timeout;
+ ndev-netdev_ops = fs_enet_netdev_ops;
ndev-watchdog_timeo = 2 * HZ;
- ndev-stop = fs_enet_close;
- ndev-get_stats = fs_enet_get_stats;
- ndev-set_multicast_list = fs_set_multicast_list;
-#ifdef CONFIG_NET_POLL_CONTROLLER
- ndev-poll_controller = fs_enet_netpoll;
-#endif
if (fpi-use_napi)
netif_napi_add(ndev, fep-napi, fs_enet_rx_napi,
fpi-napi_weight);
ndev-ethtool_ops = fs_ethtool_ops;
- ndev-do_ioctl = fs_ioctl;
init_timer(fep-phy_timer_list);
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] fs_enet: convert to netdev_ops
On Thu, 2009-04-09 at 18:46 +0400, Alexander Beregalov wrote:
Reported-by: Subrata Modak subr...@linux.vnet.ibm.com
Signed-off-by: Alexander Beregalov a.berega...@gmail.com
Thanks. Adding Sachin in Cc:
Regards--
Subrata
---
drivers/net/fs_enet/fs_enet-main.c | 27 +--
1 files changed, 17 insertions(+), 10 deletions(-)
diff --git a/drivers/net/fs_enet/fs_enet-main.c
b/drivers/net/fs_enet/fs_enet-main.c
index b037ce9..a9cbc31 100644
--- a/drivers/net/fs_enet/fs_enet-main.c
+++ b/drivers/net/fs_enet/fs_enet-main.c
@@ -1019,6 +1019,22 @@ out_put_phy:
#define IS_FEC(match) 0
#endif
+static const struct net_device_ops fs_enet_netdev_ops = {
+ .ndo_open = fs_enet_open,
+ .ndo_stop = fs_enet_close,
+ .ndo_get_stats = fs_enet_get_stats,
+ .ndo_start_xmit = fs_enet_start_xmit,
+ .ndo_tx_timeout = fs_timeout,
+ .ndo_set_multicast_list = fs_set_multicast_list,
+ .ndo_do_ioctl = fs_ioctl,
+ .ndo_validate_addr = eth_validate_addr,
+ .ndo_set_mac_address= eth_mac_addr,
+ .ndo_change_mtu = eth_change_mtu,
+#ifdef CONFIG_NET_POLL_CONTROLLER
+ .ndo_poll_controller= fs_enet_netpoll,
+#endif
+};
+
static int __devinit fs_enet_probe(struct of_device *ofdev,
const struct of_device_id *match)
{
@@ -1093,22 +1109,13 @@ static int __devinit fs_enet_probe(struct of_device
*ofdev,
fep-tx_ring = fpi-tx_ring;
fep-rx_ring = fpi-rx_ring;
- ndev-open = fs_enet_open;
- ndev-hard_start_xmit = fs_enet_start_xmit;
- ndev-tx_timeout = fs_timeout;
+ ndev-netdev_ops = fs_enet_netdev_ops;
ndev-watchdog_timeo = 2 * HZ;
- ndev-stop = fs_enet_close;
- ndev-get_stats = fs_enet_get_stats;
- ndev-set_multicast_list = fs_set_multicast_list;
-#ifdef CONFIG_NET_POLL_CONTROLLER
- ndev-poll_controller = fs_enet_netpoll;
-#endif
if (fpi-use_napi)
netif_napi_add(ndev, fep-napi, fs_enet_rx_napi,
fpi-napi_weight);
ndev-ethtool_ops = fs_ethtool_ops;
- ndev-do_ioctl = fs_ioctl;
init_timer(fep-phy_timer_list);
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: converting fs_enet to net_device_ops
2009/4/9 Kumar Gala ga...@kernel.crashing.org: Can someone look at converting drivers/net/fs_enet over to the new net_device_ops. Dave, Are you willing to take such a patch in for .30? Otherwise we need to add a select COMPAT_NET_DEV_OPS in Kconfig for this driver (and any others that might not have been converted over). drivers/net/ibm_newemac/ is another. Hi I did not this mail. I have sent a patch for it. http://patchwork.ozlabs.org/patch/25781/ ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [BUILD FAILURE 05] Next April 9 : PPC64 randconfig [drivers/net/wan/wanxlfw.inc]
On Thu, 9 Apr 2009, Subrata Modak wrote: Observed the following error: BLD FW drivers/net/wan/wanxlfw.inc /bin/sh: as68k: command not found make[3]: *** [drivers/net/wan/wanxlfw.inc] Error 127 make[2]: *** [drivers/net/wan] Error 2 make[1]: *** [drivers/net] Error 2 make: *** [drivers] Error 2 Yeah, if you enable CONFIG_WANXL_BUILD_FIRMWARE without CONFIG_PREVENT_FIRMWARE_BUILD (the trick for allmodconfig?), you need the appropriate tools installed... With kind regards, Geert Uytterhoeven Software Architect Sony Techsoft Centre Europe The Corporate Village · Da Vincilaan 7-D1 · B-1935 Zaventem · Belgium Phone:+32 (0)2 700 8453 Fax: +32 (0)2 700 8622 E-mail: geert.uytterhoe...@sonycom.com Internet: http://www.sony-europe.com/ A division of Sony Europe (Belgium) N.V. VAT BE 0413.825.160 · RPR Brussels Fortis · BIC GEBABEBB · IBAN BE41293037680010 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: ahci: drop intx manipulation on msi enable breaks ULI M1575
On Thu, Apr 9, 2009 at 12:32 AM, Jeff Garzik j...@garzik.org wrote: 3) As a result, Timur's 'ahci' is no longer receiving interrupts. Presumably this means that BOTH of the following conditions are true a) INTX is disabled b) MSI is not available Today I am thinking we should either revert the libata commit (a5bfc4714b3f01365aef89a92673f2ceb1ccf246), or poke PCI to twiddle INTX for us at pci_enable_device() time, perhaps. I lean towards the former, but maybe the platform folks prefer a third solution? Well, I was hoping that the latest U-Boot would fix this problem, but it doesn't. Earlier U-Boot couldn't find my SATA drive, so I thought that was a clue. The latest U-Boot does find the SATA drive, but the Linux driver still doesn't get interrupts. -- Timur Tabi Linux kernel developer at Freescale ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[BUILD FAILURE 08] Next April 9 : PPC64 randconfig [drivers/net/pasemi_mac_driver.ko]
Observed the following build errors: Building modules, stage 2. MODPOST 549 modules ERROR: .lro_receive_skb [drivers/net/pasemi_mac_driver.ko] undefined! ERROR: .lro_flush_all [drivers/net/pasemi_mac_driver.ko] undefined! WARNING: modpost: Found 8 section mismatch(es). To see full details build your kernel with: 'make CONFIG_DEBUG_SECTION_MISMATCH=y' make[1]: *** [__modpost] Error 1 make: *** [modules] Error 2 Regards-- Subrata # # Automatically generated make config: don't edit # Linux kernel version: 2.6.30-rc1 # Thu Apr 9 08:49:19 2009 # CONFIG_PPC64=y # # Processor support # CONFIG_PPC_BOOK3S=y # CONFIG_POWER4_ONLY is not set CONFIG_POWER3=y CONFIG_POWER4=y # CONFIG_TUNE_CELL is not set CONFIG_PPC_FPU=y CONFIG_ALTIVEC=y # CONFIG_VSX is not set CONFIG_PPC_STD_MMU=y CONFIG_PPC_STD_MMU_64=y CONFIG_PPC_MM_SLICES=y CONFIG_VIRT_CPU_ACCOUNTING=y CONFIG_SMP=y CONFIG_NR_CPUS=32 CONFIG_64BIT=y CONFIG_WORD_SIZE=64 CONFIG_ARCH_PHYS_ADDR_T_64BIT=y CONFIG_MMU=y CONFIG_GENERIC_CMOS_UPDATE=y CONFIG_GENERIC_TIME=y CONFIG_GENERIC_TIME_VSYSCALL=y CONFIG_GENERIC_CLOCKEVENTS=y CONFIG_GENERIC_HARDIRQS=y CONFIG_HAVE_SETUP_PER_CPU_AREA=y CONFIG_IRQ_PER_CPU=y CONFIG_STACKTRACE_SUPPORT=y CONFIG_HAVE_LATENCYTOP_SUPPORT=y CONFIG_TRACE_IRQFLAGS_SUPPORT=y CONFIG_LOCKDEP_SUPPORT=y CONFIG_RWSEM_XCHGADD_ALGORITHM=y CONFIG_GENERIC_LOCKBREAK=y CONFIG_ARCH_HAS_ILOG2_U32=y CONFIG_ARCH_HAS_ILOG2_U64=y CONFIG_GENERIC_HWEIGHT=y CONFIG_GENERIC_CALIBRATE_DELAY=y CONFIG_GENERIC_FIND_NEXT_BIT=y CONFIG_GENERIC_GPIO=y CONFIG_ARCH_NO_VIRT_TO_BUS=y CONFIG_PPC=y CONFIG_EARLY_PRINTK=y CONFIG_COMPAT=y CONFIG_SYSVIPC_COMPAT=y CONFIG_SCHED_OMIT_FRAME_POINTER=y CONFIG_ARCH_MAY_HAVE_PC_FDC=y CONFIG_PPC_OF=y CONFIG_OF=y CONFIG_PPC_UDBG_16550=y CONFIG_GENERIC_TBSYNC=y CONFIG_AUDIT_ARCH=y CONFIG_GENERIC_BUG=y # CONFIG_DEFAULT_UIMAGE is not set CONFIG_ARCH_SUSPEND_POSSIBLE=y # CONFIG_PPC_DCR_NATIVE is not set CONFIG_PPC_DCR_MMIO=y CONFIG_PPC_DCR=y CONFIG_PPC_OF_PLATFORM_PCI=y CONFIG_ARCH_SUPPORTS_DEBUG_PAGEALLOC=y CONFIG_DEFCONFIG_LIST=/lib/modules/$UNAME_RELEASE/.config # # General setup # # CONFIG_EXPERIMENTAL is not set CONFIG_LOCK_KERNEL=y CONFIG_INIT_ENV_ARG_LIMIT=32 CONFIG_LOCALVERSION= # CONFIG_LOCALVERSION_AUTO is not set CONFIG_SWAP=y CONFIG_SYSVIPC=y CONFIG_SYSVIPC_SYSCTL=y CONFIG_BSD_PROCESS_ACCT=y CONFIG_BSD_PROCESS_ACCT_V3=y CONFIG_TASKSTATS=y CONFIG_TASK_DELAY_ACCT=y CONFIG_TASK_XACCT=y # CONFIG_TASK_IO_ACCOUNTING is not set CONFIG_AUDIT=y CONFIG_AUDITSYSCALL=y CONFIG_AUDIT_TREE=y # # RCU Subsystem # # CONFIG_CLASSIC_RCU is not set # CONFIG_TREE_RCU is not set CONFIG_PREEMPT_RCU=y CONFIG_RCU_TRACE=y # CONFIG_TREE_RCU_TRACE is not set CONFIG_PREEMPT_RCU_TRACE=y # CONFIG_IKCONFIG is not set CONFIG_LOG_BUF_SHIFT=17 # CONFIG_CGROUPS is not set CONFIG_SYSFS_DEPRECATED=y CONFIG_SYSFS_DEPRECATED_V2=y CONFIG_RELAY=y CONFIG_NAMESPACES=y # CONFIG_UTS_NS is not set CONFIG_IPC_NS=y CONFIG_BLK_DEV_INITRD=y CONFIG_INITRAMFS_SOURCE= CONFIG_RD_GZIP=y CONFIG_RD_BZIP2=y CONFIG_RD_LZMA=y CONFIG_CC_OPTIMIZE_FOR_SIZE=y CONFIG_SYSCTL=y CONFIG_ANON_INODES=y # CONFIG_EMBEDDED is not set CONFIG_SYSCTL_SYSCALL=y CONFIG_KALLSYMS=y CONFIG_KALLSYMS_ALL=y CONFIG_KALLSYMS_EXTRA_PASS=y CONFIG_HOTPLUG=y CONFIG_PRINTK=y CONFIG_BUG=y CONFIG_ELF_CORE=y CONFIG_BASE_FULL=y CONFIG_FUTEX=y CONFIG_EPOLL=y CONFIG_SIGNALFD=y CONFIG_TIMERFD=y CONFIG_EVENTFD=y CONFIG_SHMEM=y CONFIG_AIO=y CONFIG_VM_EVENT_COUNTERS=y CONFIG_PCI_QUIRKS=y CONFIG_SLUB_DEBUG=y # CONFIG_COMPAT_BRK is not set # CONFIG_SLAB is not set CONFIG_SLUB=y # CONFIG_SLQB is not set # CONFIG_SLOB is not set # CONFIG_PROFILING is not set CONFIG_TRACEPOINTS=y CONFIG_MARKERS=y CONFIG_HAVE_OPROFILE=y CONFIG_KPROBES=y CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS=y CONFIG_HAVE_SYSCALL_WRAPPERS=y CONFIG_KRETPROBES=y CONFIG_HAVE_IOREMAP_PROT=y CONFIG_HAVE_KPROBES=y CONFIG_HAVE_KRETPROBES=y CONFIG_HAVE_ARCH_TRACEHOOK=y CONFIG_HAVE_DMA_ATTRS=y CONFIG_USE_GENERIC_SMP_HELPERS=y # CONFIG_SLOW_WORK is not set # CONFIG_HAVE_GENERIC_DMA_COHERENT is not set CONFIG_SLABINFO=y CONFIG_RT_MUTEXES=y CONFIG_BASE_SMALL=0 CONFIG_MODULES=y # CONFIG_MODULE_FORCE_LOAD is not set CONFIG_MODULE_UNLOAD=y CONFIG_MODVERSIONS=y CONFIG_MODULE_SRCVERSION_ALL=y CONFIG_STOP_MACHINE=y CONFIG_BLOCK=y CONFIG_BLK_DEV_INTEGRITY=y CONFIG_BLOCK_COMPAT=y # # IO Schedulers # CONFIG_IOSCHED_NOOP=y # CONFIG_IOSCHED_AS is not set # CONFIG_IOSCHED_DEADLINE is not set CONFIG_IOSCHED_CFQ=m # CONFIG_DEFAULT_AS is not set # CONFIG_DEFAULT_DEADLINE is not set # CONFIG_DEFAULT_CFQ is not set CONFIG_DEFAULT_NOOP=y CONFIG_DEFAULT_IOSCHED=noop # CONFIG_FREEZER is not set CONFIG_PPC_MSI_BITMAP=y # # Platform support # # CONFIG_PPC_PSERIES is not set CONFIG_LPARCFG=y CONFIG_PPC_ISERIES=y # # iSeries device drivers # # CONFIG_VIODASD is not set # CONFIG_VIOCD is not set CONFIG_VIOTAPE=m CONFIG_VIOPATH=y CONFIG_PPC_PMAC=y CONFIG_PPC_PMAC64=y # CONFIG_PPC_MAPLE is not set CONFIG_PPC_PASEMI=y # # PA Semi PWRficient options # CONFIG_PPC_PASEMI_IOMMU=y CONFIG_PPC_PASEMI_IOMMU_DMA_FORCE=y
[CFQ/OOPS] rb_erase with April 9 next tree
any other information. Thanks -Sachin -- - Sachin Sant IBM Linux Technology Center India Systems and Technology Labs Bangalore, India - Oops: Kernel access of bad area, sig: 11 [#1] SMP NR_CPUS=1024 NUMA pSeries Modules linked in: ipv6(F) fuse(F) loop(F) dm_mod(F) ehea(F) NIP: c02ee1b0 LR: c02e14d0 CTR: c02e35ac REGS: c000f20d2940 TRAP: 0300 Tainted: GF (2.6.30-rc1-next-20090409) MSR: 80009032 EE,ME,IR,DR CR: 44024448 XER: 0001 DAR: 0010, DSISR: 4000 TASK = c000f9346a00[3684] 'sh' THREAD: c000f20d CPU: 1 GPR00: c000f941f030 c000f20d2bc0 c09986e8 c000fbe91c50 GPR04: c000fb8af038 fff0 0001 c000f941edb0 GPR08: c000f941edb0 0001 c000fbb3cb50 GPR12: c000f975ed00 c0a92500 c000f20d0080 c000f20d34c0 GPR16: c06d2c92 0004 c000f20d3010 GPR20: c000f20d2ff0 0080 02c8bc82 0085 GPR24: c000fbaf c000f98ef010 c000fb8af000 GPR28: c000fb8af038 c000fb8af038 c0923360 NIP [c02ee1b0] .rb_erase+0x16c/0x3b4 LR [c02e14d0] .cfq_prio_tree_add+0x58/0x120 Call Trace: [c000f20d2bc0] [c02e1450] .cfq_service_tree_add+0x23c/0x264 (unreliable) [c000f20d2c50] [c02e14d0] .cfq_prio_tree_add+0x58/0x120 [c000f20d2cf0] [c02e16c8] .__cfq_slice_expired+0xc8/0x11c [c000f20d2d80] [c02e3920] .cfq_insert_request+0x374/0x3f4 [c000f20d2e20] [c02cf448] .elv_insert+0x234/0x348 [c000f20d2ec0] [c02d3348] .__make_request+0x514/0x5b0 [c000f20d2f80] [c02d1348] .generic_make_request+0x430/0x4c8 [c000f20d30b0] [c02d14dc] .submit_bio+0xfc/0x124 [c000f20d3170] [c0156998] .submit_bh+0x14c/0x198 [c000f20d3200] [c0158814] .bh_submit_read+0x70/0xd0 [c000f20d3290] [c01dbf6c] .read_block_bitmap+0xb8/0x238 [c000f20d3330] [c01dc2d4] .ext3_free_blocks_sb+0x178/0x5e4 [c000f20d3450] [c01dc780] .ext3_free_blocks+0x40/0xe4 [c000f20d34e0] [c01e3e70] .ext3_clear_blocks+0x1d8/0x21c [c000f20d35a0] [c01e3fcc] .ext3_free_data+0x118/0x190 [c000f20d3650] [c01e49c0] .ext3_truncate+0x670/0xa80 [c000f20d37b0] [c00fda70] .vmtruncate+0xf0/0x134 [c000f20d3850] [c01457c0] .inode_setattr+0x44/0x180 [c000f20d38f0] [c01e15e8] .ext3_setattr+0x1ec/0x298 [c000f20d39a0] [c0145afc] .notify_change+0x200/0x3dc [c000f20d3a60] [c012905c] .do_truncate+0x84/0xbc [c000f20d3b40] [c0137630] .may_open+0x1fc/0x2f4 [c000f20d3be0] [c013a5c4] .do_filp_open+0x400/0x95c [c000f20d3d80] [c0127e68] .do_sys_open+0x80/0x140 [c000f20d3e30] [c00084ac] syscall_exit+0x0/0x40 Instruction dump: e8090010 7fa01800 409e000c f9090010 4810 f9090008 4808 f91d 2f860001 7cff3b78 409e0238 48000200 e95f0010 7faa4000 409e00ec e95f0008 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
RE: [PATCH] Xilinx : Framebuffer Driver: Add PLB support (non-DCR)
-Original Message- From: Dale Farnsworth [mailto:d...@farnsworth.org] Sent: Thursday, April 09, 2009 9:36 AM To: John Linn; linuxppc-dev@ozlabs.org Subject: Re: [PATCH] Xilinx : Framebuffer Driver: Add PLB support (non-DCR) -Original Message- From: Stephen Rothwell [mailto:s...@canb.auug.org.au] Sent: Wednesday, April 08, 2009 7:52 PM To: John Linn Cc: grant.lik...@secretlab.ca; jwbo...@linux.vnet.ibm.com; linuxppc-dev@ozlabs.org; linux-fbdev-de...@lists.sourceforge.net; akonova...@ru.mvista.com; adap...@gmail.com; Suneel Garapati; Suneel Subject: Re: [PATCH] Xilinx : Framebuffer Driver: Add PLB support (non-DCR) Hi John, On Wed, 8 Apr 2009 15:11:25 -0600 John Linn john.l...@xilinx.com wrote: * 2002-2007 (c) MontaVista Software, Inc. * 2007 (c) Secret Lab Technologies, Ltd. + * 2009 (c) Xilinx Inc. * - * This file is licensed under the terms of the GNU General Public License - * version 2. This program is licensed as is without any warranty of any - * kind, whether express or implied. + * 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. + * + * You should have received a copy of the GNU General Public + * License along with this program; if not, write to the Free + * Software Foundation, Inc., 675 Mass Ave, Cambridge, MA + * 02139, USA. This changes the license for this file (from GPLv2 to GPLv2 or later). Have you asked the other copyright owners about that? Andrei was copied on the patch, we'll see if he has any thoughts about it. Although I work for MontaVista, I don't speak for them on licensing issues. In my opinion, unless someone can come up with a compelling reason for changing the license terms of a file, they shouldn't be changed. MontaVista made a deliberate, considered decision to license that file under GPLv2 and not GPLv2 or later. Those who use and distribute modifications to GPLv2 licensed work need to respect the license. Thanks Dale, we agree, Grant said the same thing. I'll fix that when I respin the patch. -- John -Dale This email and any attachments are intended for the sole use of the named recipient(s) and contain(s) confidential information that may be proprietary, privileged or copyrighted under applicable law. If you are not the intended recipient, do not read, copy, or forward this email message or any attachments. Delete this email message and any attachments immediately. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] Xilinx : Framebuffer Driver: Add PLB support (non-DCR)
-Original Message- From: Stephen Rothwell [mailto:s...@canb.auug.org.au] Sent: Wednesday, April 08, 2009 7:52 PM To: John Linn Cc: grant.lik...@secretlab.ca; jwbo...@linux.vnet.ibm.com; linuxppc-dev@ozlabs.org; linux-fbdev-de...@lists.sourceforge.net; akonova...@ru.mvista.com; adap...@gmail.com; Suneel Garapati; Suneel Subject: Re: [PATCH] Xilinx : Framebuffer Driver: Add PLB support (non-DCR) Hi John, On Wed, 8 Apr 2009 15:11:25 -0600 John Linn john.l...@xilinx.com wrote: * 2002-2007 (c) MontaVista Software, Inc. * 2007 (c) Secret Lab Technologies, Ltd. + * 2009 (c) Xilinx Inc. * - * This file is licensed under the terms of the GNU General Public License - * version 2. This program is licensed as is without any warranty of any - * kind, whether express or implied. + * 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. + * + * You should have received a copy of the GNU General Public + * License along with this program; if not, write to the Free + * Software Foundation, Inc., 675 Mass Ave, Cambridge, MA + * 02139, USA. This changes the license for this file (from GPLv2 to GPLv2 or later). Have you asked the other copyright owners about that? Andrei was copied on the patch, we'll see if he has any thoughts about it. Although I work for MontaVista, I don't speak for them on licensing issues. In my opinion, unless someone can come up with a compelling reason for changing the license terms of a file, they shouldn't be changed. MontaVista made a deliberate, considered decision to license that file under GPLv2 and not GPLv2 or later. Those who use and distribute modifications to GPLv2 licensed work need to respect the license. -Dale ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Xilinx board and NPTL support lockup
Hi Kevin, This doesn't look like an NPTL problem to me. It appears you have rebuilt the kernel, and your new kernel has a problem booting on the board. I would check the configuration options you have enabled in the kernel, and I would check that xparameters.h (older kernel) or the device-tree (newer kernel) is right for your hardware design. If you haven't rebuilt the kernel, then I would check your setup. - John khollan wrote: Hi everyone, I have a board similar to the ml410, its been running a linux kernel happily for about a year now, but now the firmware guys want NPTL threading instead of the linuxthread library. I recompiled my gcc 4.0.2 and glibc 2.3.6 library with the NPTL support, and recompiled my kernel with the new tools. Now my kernel gets stuck at the infamous Now Booting the Kernel message. Any thoughts on why this might be happening, or how to verify that my glibc and gcc are functional other than trying to compile things with them (I know this works). Thanks Kevin -- John Bonesio Commercial Linux Solutions john.bone...@xilinx.com (408) 879-5569 This email and any attachments are intended for the sole use of the named recipient(s) and contain(s) confidential information that may be proprietary, privileged or copyrighted under applicable law. If you are not the intended recipient, do not read, copy, or forward this email message or any attachments. Delete this email message and any attachments immediately. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [CFQ/OOPS] rb_erase with April 9 next tree
On Thu, Apr 09 2009, Sachin Sant wrote: I had Next 09 booted on a powerpc box and was compiling a kernel. That's when i ran into this oops. Unable to handle kernel paging request for data at address 0x0010. Faulting instruction address: 0xc02ee1b0... 0:mon e cpu 0x0: Vector: 300 (Data Access) at [c000d6cf63c0] pc: c02ee1b0: .rb_erase+0x16c/0x3b4 lr: c02e14d0: .cfq_prio_tree_add+0x58/0x120 sp: c000d6cf6640 msr: 80009032 dar: 10 dsisr: 4000 current = 0xc000fbdf5880 paca= 0xc0a92300 pid = 1867, comm = ld 0:mon t [c000d6cf66d0] c02e14d0 .cfq_prio_tree_add+0x58/0x120 [c000d6cf6770] c02e16c8 .__cfq_slice_expired+0xc8/0x11c [c000d6cf6800] c02e3920 .cfq_insert_request+0x374/0x3f4 [c000d6cf68a0] c02cf448 .elv_insert+0x234/0x348 [c000d6cf6940] c02d3348 .__make_request+0x514/0x5b0 [c000d6cf6a00] c02d1348 .generic_make_request+0x430/0x4c8 [c000d6cf6b30] c02d14dc .submit_bio+0xfc/0x124 [c000d6cf6bf0] c0156998 .submit_bh+0x14c/0x198 [c000d6cf6c80] c015ba78 .block_read_full_page+0x394/0x40c [c000d6cf7180] c0163080 .do_mpage_readpage+0x680/0x688 [c000d6cf7690] c0163200 .mpage_readpages+0x104/0x190 [c000d6cf77f0] c01e2aac .ext3_readpages+0x28/0x40 [c000d6cf7870] c00ebd20 .__do_page_cache_readahead+0x180/0x278 [c000d6cf7960] c00ec16c .ondemand_readahead+0x1ac/0x1d8 [c000d6cf7a00] c00e1f28 .generic_file_aio_read+0x260/0x6b0 [c000d6cf7b40] c0129f74 .do_sync_read+0xcc/0x130 [c000d6cf7ce0] c012af44 .vfs_read+0xd0/0x1bc [c000d6cf7d80] c012b138 .SyS_read+0x58/0xa0 [c000d6cf7e30] c00084ac syscall_exit+0x0/0x40 Just ran into this myself, too. I'll pull that bad patch from -next asap. I wont be able to fix this before next week. -- Jens Axboe ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [CFQ/OOPS] rb_erase with April 9 next tree
On Thu, Apr 09 2009, Jens Axboe wrote: On Thu, Apr 09 2009, Sachin Sant wrote: I had Next 09 booted on a powerpc box and was compiling a kernel. That's when i ran into this oops. Unable to handle kernel paging request for data at address 0x0010. Faulting instruction address: 0xc02ee1b0... 0:mon e cpu 0x0: Vector: 300 (Data Access) at [c000d6cf63c0] pc: c02ee1b0: .rb_erase+0x16c/0x3b4 lr: c02e14d0: .cfq_prio_tree_add+0x58/0x120 sp: c000d6cf6640 msr: 80009032 dar: 10 dsisr: 4000 current = 0xc000fbdf5880 paca= 0xc0a92300 pid = 1867, comm = ld 0:mon t [c000d6cf66d0] c02e14d0 .cfq_prio_tree_add+0x58/0x120 [c000d6cf6770] c02e16c8 .__cfq_slice_expired+0xc8/0x11c [c000d6cf6800] c02e3920 .cfq_insert_request+0x374/0x3f4 [c000d6cf68a0] c02cf448 .elv_insert+0x234/0x348 [c000d6cf6940] c02d3348 .__make_request+0x514/0x5b0 [c000d6cf6a00] c02d1348 .generic_make_request+0x430/0x4c8 [c000d6cf6b30] c02d14dc .submit_bio+0xfc/0x124 [c000d6cf6bf0] c0156998 .submit_bh+0x14c/0x198 [c000d6cf6c80] c015ba78 .block_read_full_page+0x394/0x40c [c000d6cf7180] c0163080 .do_mpage_readpage+0x680/0x688 [c000d6cf7690] c0163200 .mpage_readpages+0x104/0x190 [c000d6cf77f0] c01e2aac .ext3_readpages+0x28/0x40 [c000d6cf7870] c00ebd20 .__do_page_cache_readahead+0x180/0x278 [c000d6cf7960] c00ec16c .ondemand_readahead+0x1ac/0x1d8 [c000d6cf7a00] c00e1f28 .generic_file_aio_read+0x260/0x6b0 [c000d6cf7b40] c0129f74 .do_sync_read+0xcc/0x130 [c000d6cf7ce0] c012af44 .vfs_read+0xd0/0x1bc [c000d6cf7d80] c012b138 .SyS_read+0x58/0xa0 [c000d6cf7e30] c00084ac syscall_exit+0x0/0x40 Just ran into this myself, too. I'll pull that bad patch from -next asap. I wont be able to fix this before next week. Can you see if this fixes it for you? diff --git a/block/cfq-iosched.c b/block/cfq-iosched.c index e01b103..64de5c0 100644 --- a/block/cfq-iosched.c +++ b/block/cfq-iosched.c @@ -1654,6 +1654,7 @@ retry: } RB_CLEAR_NODE(cfqq-rb_node); + RB_CLEAR_NODE(cfqq-p_node); INIT_LIST_HEAD(cfqq-fifo); atomic_set(cfqq-ref, 0); -- Jens Axboe ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
RE: Xilinx board and NPTL support lockup
Thanks for your help. This was a kernel setup issue, I had forgotten to strip the debug information out of my new libraries and my initramfs was too large. I believe the zImage was decompressing onto itself, thats why it was stuck at the now booting. I probably could have fixed it by changing my boot link/load address in the kernel config but I just stripped the files and it booted fine after it was smaller. Hope this helps out anybody else with similar problems. Kevin From: John Bonesio [john.bone...@xilinx.com] Sent: Thursday, April 09, 2009 11:50 AM To: Kevin Holland Cc: linuxppc-dev@ozlabs.org Subject: Re: Xilinx board and NPTL support lockup Hi Kevin, This doesn't look like an NPTL problem to me. It appears you have rebuilt the kernel, and your new kernel has a problem booting on the board. I would check the configuration options you have enabled in the kernel, and I would check that xparameters.h (older kernel) or the device-tree (newer kernel) is right for your hardware design. If you haven't rebuilt the kernel, then I would check your setup. - John khollan wrote: Hi everyone, I have a board similar to the ml410, its been running a linux kernel happily for about a year now, but now the firmware guys want NPTL threading instead of the linuxthread library. I recompiled my gcc 4.0.2 and glibc 2.3.6 library with the NPTL support, and recompiled my kernel with the new tools. Now my kernel gets stuck at the infamous Now Booting the Kernel message. Any thoughts on why this might be happening, or how to verify that my glibc and gcc are functional other than trying to compile things with them (I know this works). Thanks Kevin -- John Bonesio Commercial Linux Solutions john.bone...@xilinx.com (408) 879-5569 This email and any attachments are intended for the sole use of the named recipient(s) and contain(s) confidential information that may be proprietary, privileged or copyrighted under applicable law. If you are not the intended recipient, do not read, copy, or forward this email message or any attachments. Delete this email message and any attachments immediately. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] Quieten arch/powerpc in a allmodconfig build.
Gah, gcc sucks. It should just not warn in these cases where it doesn't know wth is going on. I don't think you'll get any arguments. it only there was a - Wnowarnunused! -Wno-unused or -Wno-unused-pparameter and/or -Wno-unused-variable. But I thought this was about uninitialised var warnings? -Wno-uninitialized for that one. If you are asking for a GCC option that will warn for all suspect cases _except_ for the ones where it is obvious to you there is no problem: you could try -Wesp. Segher ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] Quieten arch/powerpc in a allmodconfig build.
On Fri, Apr 10, 2009 at 12:46:06AM +0200, Segher Boessenkool wrote: -Wno-unused or -Wno-unused-pparameter and/or -Wno-unused-variable. But I thought this was about uninitialised var warnings? -Wno-uninitialized for that one. If you are asking for a GCC option that will warn for all suspect cases _except_ for the ones where it is obvious to you there is no problem: you could try -Wesp. Ooops I was asking for -Wno-uninitialized. I'll try a build with: -Wno-uninitialized -Wesp and see how that goes. Thanks. Yours Tony ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] Quieten arch/powerpc in a allmodconfig build.
On Fri, 10 Apr 2009 08:45:53 +1000 Tony Breeds t...@bakeyournoodle.com wrote: On Fri, Apr 10, 2009 at 12:46:06AM +0200, Segher Boessenkool wrote: -Wno-unused or -Wno-unused-pparameter and/or -Wno-unused-variable. But I thought this was about uninitialised var warnings? -Wno-uninitialized for that one. Ooops I was asking for -Wno-uninitialized. I'll try a build with: -Wno-uninitialized -Wesp and see how that goes. Unfortunately -Wno-uninitialized also suppresses the warnings that point to real bugs. (but, I guess, the -Wesp might help there :-)) -- Cheers, Stephen Rothwells...@canb.auug.org.au http://www.canb.auug.org.au/~sfr/ pgprU1u2ye9Yc.pgp Description: PGP signature ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] Quieten arch/powerpc in a allmodconfig build.
-Wno-unused or -Wno-unused-pparameter and/or -Wno-unused- variable. But I thought this was about uninitialised var warnings? -Wno- uninitialized for that one. If you are asking for a GCC option that will warn for all suspect cases _except_ for the ones where it is obvious to you there is no problem: you could try -Wesp. Ooops I was asking for -Wno-uninitialized. I'll try a build with: -Wno-uninitialized -Wesp and see how that goes. -Wesp was a joke: I was trying to say that the compiler cannot read minds. It doesn't know what potentially unused variables are obviously (to you) actually used. Segher ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] Quieten arch/powerpc in a allmodconfig build.
Unfortunately -Wno-uninitialized also suppresses the warnings that point to real bugs. It's a double-edged sword, yes. Warnings are always like that: if the compiler could know that something _is_ wrong for certain, it wouldn't need a warning (it would use an error, instead -- and it does do this in certain cases); if it would know something is not really wrong, it would just shut up. (but, I guess, the -Wesp might help there :-)) Yeah, it's the holy grail of compiler architecture. Do what I want, not what I say :-) Segher ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 3/3] powerpc: allow 256kB pages with SHMEM
On Mon, 6 Apr 2009 22:01:15 +0100 (BST) Hugh Dickins h...@veritas.com wrote: Now that shmem's divisions by zero and SHMEM_MAX_BYTES are fixed, let powerpc 256kB pages coexist with CONFIG_SHMEM again. Signed-off-by: Hugh Dickins h...@veritas.com --- Added linuxppc-dev and some other Cc's for this 3/3: sorry if you didn't see 1/3 and 2/3, they were just in mm/shmem.c. Do we think these patches should be in 2.6.30? ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [BUILD FAILURE 04] Next April 9 : PPC64 randconfig [drivers/net/ibm_newemac/core.c]
On Thu, Apr 09, 2009 at 10:31:12AM -0400, Josh Boyer wrote:
On Thu, Apr 09, 2009 at 09:28:23AM -0500, Kumar Gala wrote:
On Apr 9, 2009, at 8:52 AM, Subrata Modak wrote:
Observed the following build error:
CC drivers/net/ibm_newemac/core.o
drivers/net/ibm_newemac/core.c: In function ???emac_probe???:
drivers/net/ibm_newemac/core.c:2831: error: ???struct net_device??? has no
member named ???open???
drivers/net/ibm_newemac/core.c:2834: error: ???struct net_device??? has no
member named ???tx_timeout???
drivers/net/ibm_newemac/core.c:2836: error: ???struct net_device??? has no
member named ???stop???
drivers/net/ibm_newemac/core.c:2837: error: ???struct net_device??? has no
member named ???get_stats???
drivers/net/ibm_newemac/core.c:2838: error: ???struct net_device??? has no
member named ???set_multicast_list???
drivers/net/ibm_newemac/core.c:2839: error: ???struct net_device??? has no
member named ???do_ioctl???
drivers/net/ibm_newemac/core.c:2841: error: ???struct net_device??? has no
member named ???hard_start_xmit???
drivers/net/ibm_newemac/core.c:2842: error: ???struct net_device??? has no
member named ???change_mtu???
drivers/net/ibm_newemac/core.c:2845: error: ???struct net_device??? has no
member named ???hard_start_xmit???
make[3]: *** [drivers/net/ibm_newemac/core.o] Error 1
make[2]: *** [drivers/net/ibm_newemac] Error 2
make[1]: *** [drivers/net] Error 2
make: *** [drivers] Error 2
Regards--
Subrata
randconfig4-ppc64-next20090409.txt
This is because CONFIG_COMPAT_NET_DEV_OPS isnt set and needs to be for
this driver to build. I've asked the netdev guys about either fixing
the driver or adding the proper thing to Kconfig to select
CONFIG_COMPAT_NET_DEV_OPS.
Thanks!
If someone has pointers on what needs to be done to fix it, let me know.
From: Alexander Beregalov a.berega...@gmail.com
Subject: [PATCH] ibm_newemac: convert to netdev_ops
Reported-by: Subrata Modak subr...@linux.vnet.ibm.com
Signed-off-by: Alexander Beregalov a.berega...@gmail.com
---
drivers/net/ibm_newemac/core.c | 41 ---
1 files changed, 29 insertions(+), 12 deletions(-)
diff --git a/drivers/net/ibm_newemac/core.c b/drivers/net/ibm_newemac/core.c
index 77e4b5b..806533c 100644
--- a/drivers/net/ibm_newemac/core.c
+++ b/drivers/net/ibm_newemac/core.c
@@ -2686,6 +2686,32 @@ static int __devinit emac_init_config(struct
emac_instance *dev)
return 0;
}
+static const struct net_device_ops emac_netdev_ops = {
+ .ndo_open = emac_open,
+ .ndo_stop = emac_close,
+ .ndo_get_stats = emac_stats,
+ .ndo_set_multicast_list = emac_set_multicast_list,
+ .ndo_do_ioctl = emac_ioctl,
+ .ndo_tx_timeout = emac_tx_timeout,
+ .ndo_validate_addr = eth_validate_addr,
+ .ndo_set_mac_address= eth_mac_addr,
+ .ndo_start_xmit = emac_start_xmit,
+ .ndo_change_mtu = eth_change_mtu,
+};
+
+static const struct net_device_ops emac_gige_netdev_ops = {
+ .ndo_open = emac_open,
+ .ndo_stop = emac_close,
+ .ndo_get_stats = emac_stats,
+ .ndo_set_multicast_list = emac_set_multicast_list,
+ .ndo_do_ioctl = emac_ioctl,
+ .ndo_tx_timeout = emac_tx_timeout,
+ .ndo_validate_addr = eth_validate_addr,
+ .ndo_set_mac_address= eth_mac_addr,
+ .ndo_start_xmit = emac_start_xmit_sg,
+ .ndo_change_mtu = emac_change_mtu,
+};
+
static int __devinit emac_probe(struct of_device *ofdev,
const struct of_device_id *match)
{
@@ -2827,23 +2853,14 @@ static int __devinit emac_probe(struct of_device *ofdev,
if (err != 0)
goto err_detach_tah;
- /* Fill in the driver function table */
- ndev-open = emac_open;
if (dev-tah_dev)
ndev-features |= NETIF_F_IP_CSUM | NETIF_F_SG;
- ndev-tx_timeout = emac_tx_timeout;
ndev-watchdog_timeo = 5 * HZ;
- ndev-stop = emac_close;
- ndev-get_stats = emac_stats;
- ndev-set_multicast_list = emac_set_multicast_list;
- ndev-do_ioctl = emac_ioctl;
if (emac_phy_supports_gige(dev-phy_mode)) {
- ndev-hard_start_xmit = emac_start_xmit_sg;
- ndev-change_mtu = emac_change_mtu;
+ ndev-netdev_ops = emac_gige_netdev_ops;
dev-commac.ops = emac_commac_sg_ops;
- } else {
- ndev-hard_start_xmit = emac_start_xmit;
- }
+ } else
+ ndev-netdev_ops = emac_netdev_ops;
SET_ETHTOOL_OPS(ndev, emac_ethtool_ops);
netif_carrier_off(ndev);
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] Quieten arch/powerpc in a allmodconfig build.
Tony Breeds t...@bakeyournoodle.com wrote: On Wed, Apr 08, 2009 at 01:47:36PM -0500, Nathan Lynch wrote: I think I had some reason for doing it this way, but I'm drawing a blank right now. In the meantime, can someone post the warnings that gcc emits for cacheinfo.c, as well as the gcc version? I can't reproduce them with 4.3.2 on Fedora. --- [t...@thor ~]$ egrep cacheinfo tmp/build.log /scratch/tony/working/arch/powerpc/kernel/cacheinfo.c: In function 'associativity_show': /scratch/tony/working/arch/powerpc/kernel/cacheinfo.c:562: warning: 'associativity' may be used uninitialized in this function /scratch/tony/working/arch/powerpc/kernel/cacheinfo.c: In function 'size_show': /scratch/tony/working/arch/powerpc/kernel/cacheinfo.c:513: warning: 'size_kb' may be used uninitialized in this function Thanks. So I think I've convinced myself that the warnings are incorrect and that uninitialized use is not possible. But I find it odd that gcc gives warnings for these sites but not others in the file that use the same idiom (e.g. line_size_show, nr_sets_show). I'd guess that inlining is implicated somehow. Would I be justified in worrying that this version of gcc is generating incorrect code? If not, then I'm fine with the uninitialized_var() changes, but do please include the warnings and the compiler version in the changelog. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
