Re: [PATCH] drivers/base: export gpl (un)register_memory_notifier
Dave Hansen <[EMAIL PROTECTED]> wrote on 13.02.2008 18:05:00: > On Wed, 2008-02-13 at 16:17 +0100, Jan-Bernd Themann wrote: > > Constraints imposed by HW / FW: > > - eHEA has own MMU > > - eHEA Memory Regions (MRs) are used by the eHEA MMU to translate virtual > > addresses to absolute addresses (like DMA mapped memory on a PCI bus) > > - The number of MRs is limited (not enough to have one MR per packet) > > Are there enough to have one per 16MB section? Unfortunately this won't work. This was one of our first ideas we tossed out, but the number of MRs will not be sufficient. > > > Our current understanding about the current Memory Hotplug System are > > (please correct me if I'm wrong): > > > > - depends on sparse mem > > You're wrong ;). In mainline, this is true. There was a version of the > SUSE kernel that did otherwise. But you can not and should not depend > on this never changing. But, someone is perfectly free to go out an > implement something better than sparsemem for memory hotplug. If they > go and do this, your driver may get left behind. We understand that the add/remove area is not as settled in the kernel like for example f_ops ;-) Are there already base working assumptions which are very unlikely to change? > > > - only whole memory sections are added / removed > > - for each section a memory resource is registered > > True, and true. (There might be exceptions to the whole sections one, > but that's blatant abuse and should be fixed. :) > > > From the driver side we need: > > - some kind of memory notification mechanism. > > For memory add we can live without any external memory notification > > event. For memory remove we do need an external trigger (see explanation > > above). > > You can export and use (un)register_memory_notifier. You just need to > do it in a reasonable way that compiles for randconfig on your > architecture. Believe me, we don't want to start teaching drivers about > sparsemem. I'm a little confused here ...the existing add/remove code depends on sparse mem. Other pieces on the POWER6 version of the architecture do as well. So we could either chose to disable add/remove if sparsemem is not there, or disable the driver by Kconfig in this case. > > - a way to iterate over all kernel pages and a way to detect holes in the > > kernel memory layout in order to build up our own ehea_bmap. > > Look at kernel/resource.c > > But, I'm really not convinced that you can actually keep this map > yourselves. It's not as simple as you think. What happens if you get > on an LPAR with two sections, one [EMAIL PROTECTED] and another > [EMAIL PROTECTED] That's quite possible. I think your vmalloc'd > array will eat all of memory. I'm glad you mention this part. There are many algorithms out there to handle this problem, hashes/trees/... all of these trade speed for smaller memory footprint. We based the table decission on the existing implementations of the architecture. Do you see such a case coming along for the next generation POWER systems? I would guess these drastic changes would also require changes in base kernel. Will you provide a generic mapping system with a contiguous virtual address space like the ehea_bmap we can query? This would need to be a "stable" part of the implementation, including translation functions from kernel to nextgen_ehea_generic_bmap like virt_to_abs. > > That's why we have SPARSEMEM_EXTREME and SPARSEMEM_VMEMMAP implemented > in the core, so that we can deal with these kinds of problems, once and > *NOT* in every single little driver out there. > > > Functions to use while building ehea_bmap + MRs: > > - Use either the functions that are used by the memory hotplug system as > > well, that means using the section defines + functions (section_nr_to_pfn, > > pfn_valid) > > Basically, you can't use anything related to sections outside of the > core code. You can use things like pfn_valid(), or you can create new > interfaces that are properly abstracted. We picked sections instead of PFNs because this keeps the ehea_bmap in a reasonable range on the existing systems. But if you provide a abstract method handling exactly the problem we mention we'll be happy to use that and dump our private implementation. > > > - Use currently other not exported functions in kernel/resource.c, like > > walk_memory_resource (where we would still need the maximum > possible number > > of pages NR_MEM_SECTIONS) > > It isn't the act of exporting that's the problem. It's making sure that > the exports won't be prone to abuse and that people are using them > properly. You should assume that you can export and use > walk_memory_resource(). So this seems to come down to a basic question: New hardware seems to have a tendency to get "private MMUs", which need private mappings from the kernel address space into a "HW defined address space with potentially unique characteristics" RDMA in Openfabrics with global MR is the most pro
Re: [PATCH] [POWERPC] Enable correct operation of serial ports with nonzero regshift.
Kumar Gala wrote: > > On Feb 13, 2008, at 3:19 PM, Pavel Kiryukhin wrote: > >> Add regshift reading to serial drivers. >> This enables correct operation of serial ports with nonzero regshift. > > what device needs this? > > - k Xilinx opb 16550 uart -- Pavel ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [BUG] 2.6.25-rc1-git1 softlockup while bootup on powerpc
Ingo Molnar wrote:
> * Kamalesh Babulal <[EMAIL PROTECTED]> wrote:
>
>> While booting with the 2.6.25-rc1-git1 kernel on the powerbox the
>> softlockup is seen, with following trace.
>
>> BUG: soft lockup - CPU#1 stuck for 61s! [insmod:377]
>> TASK = c0077cb2f0e0[377] 'insmod' THREAD: c0077cb28000 CPU: 1
>> NIP [c01b172c] .radix_tree_gang_lookup+0xdc/0x1e4
>> LR [c01a6f00] .call_for_each_cic+0x50/0x10c
>> Call Trace:
>> [c0077cb2bb20] [c01a6f60] .call_for_each_cic+0xb0/0x10c
>> (unreliable)
>> [c0077cb2bc60] [c019ecd8] .exit_io_context+0xf0/0x110
>> [c0077cb2bcf0] [c006254c] .do_exit+0x820/0x850
>> [c0077cb2bda0] [c0062648] .do_group_exit+0xcc/0xe8
>> [c0077cb2be30] [c000872c] syscall_exit+0x0/0x40
>
> this call_for_each_cic/radix_tree_gang_lookup locked up, and all other
> CPUs deadlocked in stopmachine, due to this one.
>
> call_for_each_cic is in ./block/cfq-iosched.c uses RCU, but you've got
> classic-RCU:
>
> CONFIG_CLASSIC_RCU=y
> # CONFIG_PREEMPT_RCU is not set
>
> so it's not related to the preempt-RCU changes either.
>
> It is this part that locks up:
>
> do {
> ...
> nr = radix_tree_gang_lookup(&ioc->radix_root, (void **) cics,
> index, CIC_GANG_NR);
> ...
> } while (nr == CIC_GANG_NR);
> ...
>
> it seems the radix tree will yield new entries again and again. Either
> it got corrupted, or some other CPU is filling it faster than we can
> deplete it [unlikely i think].
>
> Ingo
This softlockup is seen with the 2.6.25-rc1-git3 also. Let me know if you
need more details.
--
Thanks & Regards,
Kamalesh Babulal,
Linux Technology Center,
IBM, ISTL.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: /proc/bus/pci and domains
Hi Greg! > I have no idea, it sounds like a PPC specific thing, not anything the > PCI core does, right? So I'll add the ppc list to the cc: and ask if > anyone there has any ideas? Unfortunately, this is not PPC specific at all -- proc_attach_device() calls pci_proc_domain(bus), which is an arch-specific hook turning on the weird behavior I described. This hook can return non-zero even on x86 if there are buses outside domain 0. I think that the hook itself is correct, it only should trigger more consistent behavior of the generic code :) Would it be acceptable for the PPC folks to modify the code to add domain numbers to the device numbers in /proc/bus/pci/devices in the same format as the bus directories already have? If so, I will cook up a patch. Have a nice fortnight -- Martin `MJ' Mares <[EMAIL PROTECTED]> http://mj.ucw.cz/ Faculty of Math and Physics, Charles University, Prague, Czech Rep., Earth "Dijkstra probably hates me." -- /usr/src/linux/kernel/sched.c ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH/RFC] [POWERPC] Add i2c pins to dts and board setup on 01-31-08
Hi Nima,
> I've got a couple of comments about the above patch - I'm not quite sure
> how to add my comments to the ozlab.org site.
simply replying to the original mail will add your comments.
> 1 -
> -- a/arch/powerpc/boot/dts/mpc8272ads.dts
> [snip]
> + [EMAIL PROTECTED] {
> + compatible = "fsl,mpc8248-i2c",
> [NIMA] Are you sure it should be mpc8248, or do you want 8272. I know
> they are essentially the same chip, but just to avoid confusion, it
> maybe better as 8272.
Good catch, thanks! As i don't have a CPM2 chip myself, i had a tester with
a MPC8248. I just took his dts parts.
> 2-
> +++ b/arch/powerpc/platforms/82xx/mpc8272_ads.c
> @@ -96,6 +96,11 @@ static struct cpm_pin mpc8272_ads_pins[] = {
> {1, 31, CPM_PIN_OUTPUT | CPM_PIN_PRIMARY},
> {2, 16, CPM_PIN_INPUT | CPM_PIN_PRIMARY},
> {2, 17, CPM_PIN_INPUT | CPM_PIN_PRIMARY},
> +
> + /* I2C */
> + {3, 26, CPM_PIN_INPUT | CPM_PIN_SECONDARY | CPM_PIN_OPENDRAIN},
> + {3, 27, CPM_PIN_INPUT | CPM_PIN_SECONDARY | CPM_PIN_OPENDRAIN},
>
> [NIMA] The MPC8272 manual states that it should be pins 14/15 and not
> 26/27.
Ah thanks.
> However, in all my accesses,
> - 1st write is successful
> - 1st read fails (times out)
> - 2nd read succeeds
>
> Here is the debug log:
> i2c-adapter i2c-0: ioctl, cmd=0x703, arg=0x40
> i2c-dev: i2c-0 writing 2 bytes.
> i2c-adapter i2c-0: master_xfer[0] W, addr=0x40, len=2
> i2c-adapter i2c-0: i2c-algo-cpm.o: R: 0 T: 0
> i2c-adapter i2c-0: cpm_iic_write(abyte=0x80)
> i2c-adapter i2c-0: tx sc 0 bc00
> i2c-adapter i2c-0: test ready.
> i2c-adapter i2c-0: not ready.
> i2c-adapter i2c-0: Interrupt: 2
> i2c-adapter i2c-0: Interrupt: 1
> i2c-adapter i2c-0: test ready.
> i2c-adapter i2c-0: ready.
> i2c-adapter i2c-0: tx sc 0 3c00
> i2c-dev: i2c-0 reading 1 bytes.
> i2c-adapter i2c-0: master_xfer[0] R, addr=0x40, len=1
> i2c-adapter i2c-0: i2c-algo-cpm.o: R: 0 T: 0
> i2c-adapter i2c-0: cpm_i2c_read(abyte=0x81)
> i2c-adapter i2c-0: test ready.
> i2c-adapter i2c-0: not ready.
> i2c-adapter i2c-0: I2C read: timeout!
> i2c-adapter i2c-0: cpm_i2c_force_close()
> i2c-dev: i2c-0 reading 1 bytes.
> i2c-adapter i2c-0: master_xfer[0] R, addr=0x40, len=1
> i2c-adapter i2c-0: i2c-algo-cpm.o: R: 0 T: 0
> i2c-adapter i2c-0: cpm_i2c_read(abyte=0x81)
> i2c-adapter i2c-0: test ready.
> i2c-adapter i2c-0: not ready.
> i2c-adapter i2c-0: Interrupt: 1
> i2c-adapter i2c-0: test ready.
> i2c-adapter i2c-0: ready.
> i2c-adapter i2c-0: rx sc 2c00, rx sc 1800
>
> Any ideas?
What does you chip expect? Start-Write-Start-Read-Stop or Start-Write-Stop,
Start-Read-Stop?
Did you try chaining the write and read request (put them into the same msg)?
Thanks,
Jochen
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: libfdt: Fix NOP handling bug in fdt_add_subnode_namelen()
So, like, the other day David Gibson mumbled: > fdt_add_subnode_namelen() has a bug if asked to add a subnode to a > node which has NOP tags interspersed with its properties. In this > case fdt_add_subnode_namelen() will put the new subnode before the > first NOP tag, even if there are properties after it, which will > result in an invalid blob. > > This patch fixes the bug, and adds a testcase for it. > > Signed-off-by: David Gibson <[EMAIL PROTECTED]> Applied. Thanks, jdl ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] [POWERPC] Enable correct operation of serial ports with nonzero regshift.
On Feb 14, 2008, at 3:10 AM, Pavel Kiryukhin wrote: > Kumar Gala wrote: >> >> On Feb 13, 2008, at 3:19 PM, Pavel Kiryukhin wrote: >> >>> Add regshift reading to serial drivers. >>> This enables correct operation of serial ports with nonzero >>> regshift. >> >> what device needs this? >> >> - k > > Xilinx opb 16550 uart please add that info to the commit message so we know why this change was made. Other it looks ok to me. - k ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] remove unused CONFIG_WANT_DEVICE_TREE
On Wed, 13 Feb 2008 21:14:09 -0700 Grant Likely <[EMAIL PROTECTED]> wrote: > From: Grant Likely <[EMAIL PROTECTED]> > > CONFIG_DEVICE_TREE was the only user of CONFIG_WANT_DEVICE_TREE but > it was removed in commit id 25431333813686654907ab987fb5de10c10a16db > (bootwrapper: Build multiple cuImages). > > This patch removes CONFIG_WANT_DEVICE_TREE from Kconfig and the defconfigs > > Signed-off-by: Grant Likely <[EMAIL PROTECTED]> Tested on Ebony for 4xx. Seems Paul already has it queued up. I have some other changes coming and I'll update the defconfigs for 4xx to remove reference to it. josh ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] emac/zmii link warnings
On Thu, 07 Feb 2008 00:08:33 -0500 Sean MacLennan <[EMAIL PROTECTED]> wrote: > Ok, here is my best shot at removing the warnings. It seems to me that > functions called from a dev_init section should not be dev_exit. This seems to fix those specific warnings, but there are others lurking in some of the other files (rgmii, tah, etc). We should probably get those fixed up too. josh ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
BUG: ucc_geth, MDIO only works for UCC3([EMAIL PROTECTED]) on MPC8321
Trying to use other UCC2 or UCC4 for ethernet instead of UCC3 makes MDIO unusable. UCC2 can not find its PHY if not UCC3 is present too. Seems like only UCC3 is able to drive the MDIO bus. Jocke ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] drivers/base: export gpl (un)register_memory_notifier
On Thu, 2008-02-14 at 09:46 +0100, Christoph Raisch wrote: > Dave Hansen <[EMAIL PROTECTED]> wrote on 13.02.2008 18:05:00: > > On Wed, 2008-02-13 at 16:17 +0100, Jan-Bernd Themann wrote: > > > Constraints imposed by HW / FW: > > > - eHEA has own MMU > > > - eHEA Memory Regions (MRs) are used by the eHEA MMU to translate > virtual > > > addresses to absolute addresses (like DMA mapped memory on a PCI bus) > > > - The number of MRs is limited (not enough to have one MR per packet) > > > > Are there enough to have one per 16MB section? > > Unfortunately this won't work. This was one of our first ideas we tossed > out, > but the number of MRs will not be sufficient. Can you give a ballpark of how many there are to work with? 10? 100? 1000? > We understand that the add/remove area is not as > settled in the kernel like for example f_ops ;-) > Are there already base working assumptions which are very unlikely to > change? If you use good interfaces, and someone changes them, they'll likely also fix your driver. If you use bad interfaces, people may not even notice when they break. As I showed you with those compile failures, you're using bad interfaces that don't even compile on some .configs. > I'm a little confused here > ...the existing add/remove code depends on sparse mem. > Other pieces on the POWER6 version of the architecture do as well. > So we could either chose to disable add/remove if sparsemem is not there, > or disable the driver by Kconfig in this case. Technically, you can do this. But, it's not a sign of a professionally written driver that is going to get its patches accepted into mainline. Technically, you can also use lots of magic numbers and not obey CodingStyle. But, you'll probably get review comments asking you to change it. > > > - a way to iterate over all kernel pages and a way to detect holes in > the > > > kernel memory layout in order to build up our own ehea_bmap. > > > > Look at kernel/resource.c > > > > But, I'm really not convinced that you can actually keep this map > > yourselves. It's not as simple as you think. What happens if you get > > on an LPAR with two sections, one [EMAIL PROTECTED] and another > > [EMAIL PROTECTED] That's quite possible. I think your vmalloc'd > > array will eat all of memory. > I'm glad you mention this part. There are many algorithms out there to > handle this problem, > hashes/trees/... all of these trade speed for smaller memory footprint. > We based the table decission on the existing implementations of the > architecture. > Do you see such a case coming along for the next generation POWER systems? Dude. It exists *TODAY*. Go take a machine, add tens of gigabytes of memory to it. Then, remove all of the sections of memory in the middle. You'll be left with a very sparse memory configuration that we *DO* handle today in the core VM. We handle it quite well, actually. The hypervisor does not shrink memory from the top down. It pulls things out of the middle and shuffles things around. In fact, a NUMA node's memory isn't even contiguous. Your code will OOM the machine in this case. I consider the ehea driver buggy in this regard. > I would guess these drastic changes would also require changes in base > kernel. No, we actually solved those a couple years ago. > Will you provide a generic mapping system with a contiguous virtual address > space > like the ehea_bmap we can query? This would need to be a "stable" part of > the implementation, > including translation functions from kernel to nextgen_ehea_generic_bmap > like virt_to_abs. Yes, that's a real possibility, especially if some other users for it come forward. We could definitely add something like that to the generic code. But, you'll have to be convincing that what we have now is insufficient. Does this requirement: "- MRs cover a contiguous virtual memory block (no holes)" come from the hardware? Is that *EACH* MR? OR all MRs? Where does EHEA_BUSMAP_START come from? Is that defined in the hardware? Have you checked to ensure that no other users might want a chunk of memory in that area? Can you query the existing MRs? Not change them in place, but can you query their contents? > > That's why we have SPARSEMEM_EXTREME and SPARSEMEM_VMEMMAP implemented > > in the core, so that we can deal with these kinds of problems, once and > > *NOT* in every single little driver out there. > > > > > Functions to use while building ehea_bmap + MRs: > > > - Use either the functions that are used by the memory hotplug system > as > > > well, that means using the section defines + functions > (section_nr_to_pfn, > > > pfn_valid) > > > > Basically, you can't use anything related to sections outside of the > > core code. You can use things like pfn_valid(), or you can create new > > interfaces that are properly abstracted. > > We picked sections instead of PFNs because this keeps the ehea_bmap in a > reasonable range > on the existing systems. > But i
Re: [PATCH] drivers/base: export gpl (un)register_memory_notifier
On Thu, 2008-02-14 at 09:12 -0800, Dave Hansen wrote: .. > > > > - Use currently other not exported functions in kernel/resource.c, like > > > > walk_memory_resource (where we would still need the maximum > > > possible number > > > > of pages NR_MEM_SECTIONS) > > > > > > It isn't the act of exporting that's the problem. It's making sure that > > > the exports won't be prone to abuse and that people are using them > > > properly. You should assume that you can export and use > > > walk_memory_resource(). > > > > So this seems to come down to a basic question: > > New hardware seems to have a tendency to get "private MMUs", > > which need private mappings from the kernel address space into a > > "HW defined address space with potentially unique characteristics" > > RDMA in Openfabrics with global MR is the most prominent example heading > > there > > That's not a question. ;) > > Please explain to me why walk_memory_resource() is insufficient for your > needs. I've now pointed it out to you at least 3 times. I am not sure what you are trying to do with walk_memory_resource(). The behavior is different on ppc64. Hotplug memory usage assumes that all the memory resources (all system memory, not just IOMEM) are represented in /proc/iomem. Its the case with i386 and ia64. But on ppc64 is contains ONLY iomem related. Paulus didn't want to export all the system memory into /proc/iomem on ppc64. So I had to workaround by providing arch-specific walk_memory_resource() function for ppc64. Thanks, Badari ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] drivers/base: export gpl (un)register_memory_notifier
On Thu, 2008-02-14 at 09:36 -0800, Badari Pulavarty wrote: > > I am not sure what you are trying to do with walk_memory_resource(). > The > behavior is different on ppc64. Hotplug memory usage assumes that all > the memory resources (all system memory, not just IOMEM) are > represented > in /proc/iomem. Its the case with i386 and ia64. But on ppc64 is > contains ONLY iomem related. Paulus didn't want to export all the > system > memory into /proc/iomem on ppc64. So I had to workaround by providing > arch-specific walk_memory_resource() function for ppc64. OK, let's use that one. -- Dave ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] Fix ucc_geth MII master selection
Remove bogus UCC regs range test and correct
off by one error in call to ucc_set_qe_mux_mii_mng()
Signed-off-by: Joakim Tjernlund <[EMAIL PROTECTED]>
---
I am not 100% sure this is the correct fix, please ACK or NACK
drivers/net/ucc_geth_mii.c | 26 +++---
1 files changed, 11 insertions(+), 15 deletions(-)
diff --git a/drivers/net/ucc_geth_mii.c b/drivers/net/ucc_geth_mii.c
index 6c257b8..472d5a1 100644
--- a/drivers/net/ucc_geth_mii.c
+++ b/drivers/net/ucc_geth_mii.c
@@ -200,21 +200,17 @@ static int uec_mdio_probe(struct of_device *ofdev, const
struct of_device_id *ma
if (err)
goto bus_register_fail;
- /* if our mdio regs fall within this UCC regs range */
- if ((res.start >= tempres.start) &&
- (res.end <= tempres.end)) {
- /* set this UCC to be the MII master */
- const u32 *id = of_get_property(tempnp, "device-id",
NULL);
- if (id == NULL)
- goto bus_register_fail;
-
- ucc_set_qe_mux_mii_mng(*id - 1);
-
- /* assign the TBI an address which won't
-* conflict with the PHYs */
- out_be32(®s->utbipar, UTBIPAR_INIT_TBIPA);
- break;
- }
+ /* set this UCC to be the MII master */
+ const u32 *id = of_get_property(tempnp, "device-id", NULL);
+ if (id == NULL)
+ goto bus_register_fail;
+
+ ucc_set_qe_mux_mii_mng(*id);
+
+ /* assign the TBI an address which won't
+* conflict with the PHYs */
+ out_be32(®s->utbipar, UTBIPAR_INIT_TBIPA);
+ break;
}
err = mdiobus_register(new_bus);
--
1.5.3.8
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 04/14] arch/powerpc/platforms/iseries/pci.c: Use time_* macros
The functions time_before, time_before_eq, time_after, and time_after_eq are
more robust for comparing jiffies against other values.
So following patch implements usage of the time_after() macro, defined at
linux/jiffies.h, which deals with wrapping correctly
Cc: linuxppc-dev@ozlabs.org
Signed-off-by: S.Çağlar Onur <[EMAIL PROTECTED]>
---
arch/powerpc/platforms/iseries/pci.c |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/platforms/iseries/pci.c
b/arch/powerpc/platforms/iseries/pci.c
index cc562e4..02a634f 100644
--- a/arch/powerpc/platforms/iseries/pci.c
+++ b/arch/powerpc/platforms/iseries/pci.c
@@ -23,6 +23,7 @@
#undef DEBUG
+#include
#include
#include
#include
@@ -586,7 +587,7 @@ static inline struct device_node *xlate_iomm_address(
static unsigned long last_jiffies;
static int num_printed;
- if ((jiffies - last_jiffies) > 60 * HZ) {
+ if (time_after(jiffies, last_jiffies + 60 * HZ)) {
last_jiffies = jiffies;
num_printed = 0;
}
--
1.5.3.7
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: /proc/bus/pci and domains
On Thursday, February 14, 2008 1:40 am Martin Mares wrote: > Hi Greg! > > > I have no idea, it sounds like a PPC specific thing, not anything the > > PCI core does, right? So I'll add the ppc list to the cc: and ask if > > anyone there has any ideas? > > Unfortunately, this is not PPC specific at all -- proc_attach_device() > calls pci_proc_domain(bus), which is an arch-specific hook turning on > the weird behavior I described. This hook can return non-zero even on > x86 if there are buses outside domain 0. > > I think that the hook itself is correct, it only should trigger more > consistent behavior of the generic code :) > > Would it be acceptable for the PPC folks to modify the code to add > domain numbers to the device numbers in /proc/bus/pci/devices in the > same format as the bus directories already have? > > If so, I will cook up a patch. I've run into this too, on machines with many domains. It's unfortunate that there's no way to preserve compatibility, but I agree that the brokenness may as well be consistent. Jesse ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
RE: [PATCH] [POWERPC] Enable correct operation of serial ports withnonzero regshift.
> --- a/arch/powerpc/kernel/legacy_serial.c > +++ b/arch/powerpc/kernel/legacy_serial.c > + /* get regshift if present*/ > + regshift = get_property(np, "reg-shift", NULL); of_get_property, presumably? --- a/drivers/serial/of_serial.c +++ b/drivers/serial/of_serial.c > + regshift = get_property(np, "reg-shift", NULL); ditto... Otherwise, Acked-by: Stephen Neuendorffer <[EMAIL PROTECTED]> Also, can you post a patch to the Xilinx portion of booting-without-of.txt that has the device tree entries necessary to get the uart to work? (Since I happened to be tracking down what I assume is the same issue when you posted the patch!) Steve ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 0/4]: Respun LMB patches.
On Feb 13, 2008, at 7:09 PM, David Miller wrote: > > I've taken into consideration the various feedback, and > ported the bug fix and other LMB patches posted recently > in an effort to keep the patch churn by others down wrt. > my moving of these files. > > 1) Use HAVE_LMB as suggested by Sam. > > 2) Fix potential build errors wrt. asm/prom.h dependencies. > >My algorithm was: > >a) If the file only included asm/lmb.h I added an include > of both linux/lmb.c and asm/prom.h > >b) If the file already includes asm/prom.h, I merely > changed the asm/lmb.h to linux/lmb.h > >Header include mimimizations can be done as followon patches. > > 3) Integrate Kumar Gala's initial region fix. > > 4) Integrate Becky Bruce's large physical addressing change, >but using u64 instead of phys_addr_t. > > It's all at: > > master.kernel.org:/pub/scm/linux/kernel/git/davem/lmb-2.6.git > > like before. Thanks for picking up the patches from Kumar and myself and fitting them into your series - this is much appreciated. FYI, I applied the entire patch series to my local tree and test-booted both mpc8641 and mpc8568mds and both build and boot cleanly. I also built pasemi and ebony, those build cleanly as well. Cheers, Becky ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 05/11] ppc/mpc8xx: remove ppc_ide_md hooks
On Thu, 14 Feb 2008 01:36:56 +0100
Bartlomiej Zolnierkiewicz wrote:
> * Initialize IDE ports in mpc8xx_ide_probe().
>
> * Remove m8xx_ide_init() and ppc_ide_md hooks - no need for them
> (IDE mpc8xx host driver takes care of all this setup).
>
> * Remove needless 'if (irq)' and 'if (data_port >= MAX_HWIFS)' checks
> from m8xx_ide_init_hwif_ports().
>
> * Remove 'ctrl_port' and 'irq' arguments from
> m8xx_ide_init_hwif_ports().
>
> * Rename m8xx_ide_init_hwif_ports() to m8xx_ide_init_ports().
>
> * Add __init tag to m8xx_ide_init_ports().
>
> This patch fixes hwif->irq always being overriden to 0 (==
> auto-probe, is this even working on PPC?) because of
> ide_init_default_irq() call in ide.c.
>
> There should be no other functional changes.
>
> Cc: Benjamin Herrenschmidt <[EMAIL PROTECTED]>
> Signed-off-by: Bartlomiej Zolnierkiewicz <[EMAIL PROTECTED]>
Acked-by: Vitaly Bordug <[EMAIL PROTECTED]>
> ---
> arch/ppc/syslib/m8xx_setup.c |6 ---
> drivers/ide/ppc/mpc8xx.c | 86
> +++ 2 files changed, 22
> insertions(+), 70 deletions(-)
>
> Index: b/arch/ppc/syslib/m8xx_setup.c
> ===
> --- a/arch/ppc/syslib/m8xx_setup.c
> +++ b/arch/ppc/syslib/m8xx_setup.c
> @@ -87,8 +87,6 @@ void m8xx_calibrate_decr(void);
>
> unsigned char __res[sizeof(bd_t)];
>
> -extern void m8xx_ide_init(void);
> -
> extern unsigned long find_available_memory(void);
> extern void m8xx_cpm_reset(void);
> extern void m8xx_wdt_handler_install(bd_t *bp);
> @@ -474,8 +472,4 @@ platform_init(unsigned long r3, unsigned
>
> ppc_md.find_end_of_memory = m8xx_find_end_of_memory;
> ppc_md.setup_io_mappings= m8xx_map_io;
> -
> -#if defined(CONFIG_BLK_DEV_MPC8xx_IDE)
> - m8xx_ide_init();
> -#endif
> }
> Index: b/drivers/ide/ppc/mpc8xx.c
> ===
> --- a/drivers/ide/ppc/mpc8xx.c
> +++ b/drivers/ide/ppc/mpc8xx.c
> @@ -99,32 +99,6 @@ static int _slot_ = -1;/*
> will be rea /* Make clock cycles and always round up */
> #define PCMCIA_MK_CLKS( t, T ) (( (t) * ((T)/100) + 999U ) /
> 1000U )
> -
> -
> -/*
> - * IDE stuff.
> - */
> -static int
> -m8xx_ide_default_irq(unsigned long base)
> -{
> -#ifdef CONFIG_BLK_DEV_MPC8xx_IDE
> - if (base >= MAX_HWIFS)
> - return 0;
> -
> - printk("[%d] m8xx_ide_default_irq
> %d\n",__LINE__,ioport_dsc[base].irq);
> -
> - return (ioport_dsc[base].irq);
> -#else
> -return 9;
> -#endif
> -}
> -
> -static unsigned long
> -m8xx_ide_default_io_base(int index)
> -{
> -return index;
> -}
> -
> #define M8XX_PCMCIA_CD2(slot) (0x1000 >> (slot << 4))
> #define M8XX_PCMCIA_CD1(slot) (0x0800 >> (slot << 4))
>
> @@ -149,12 +123,11 @@ static int pcmcia_schlvl = PCMCIA_SCHLVL
> */
>
> /*
> - * m8xx_ide_init_hwif_ports for a direct IDE interface _using_
> + * m8xx_ide_init_ports() for a direct IDE interface _using_
> + * MPC8xx's internal PCMCIA interface
> */
> #if defined(CONFIG_IDE_8xx_PCCARD) || defined(CONFIG_IDE_8xx_DIRECT)
> -static void
> -m8xx_ide_init_hwif_ports(hw_regs_t *hw, unsigned long data_port,
> - unsigned long ctrl_port, int *irq)
> +static void __init m8xx_ide_init_ports(hw_regs_t *hw, unsigned long
> data_port) {
> unsigned long *p = hw->io_ports;
> int i;
> @@ -173,8 +146,6 @@ m8xx_ide_init_hwif_ports(hw_regs_t *hw,
> unsigned long base;
>
> *p = 0;
> - if (irq)
> - *irq = 0;
>
> pcmp = (pcmconf8xx_t *)(&(((immap_t
> *)IMAP_ADDR)->im_pcmcia));
> @@ -248,9 +219,6 @@ m8xx_ide_init_hwif_ports(hw_regs_t *hw,
> }
> }
>
> - if (data_port >= MAX_HWIFS)
> - return;
> -
> if (_slot_ == -1) {
> printk ("PCMCIA slot has not been defined! Using A
> as default\n"); _slot_ = 0;
> @@ -292,11 +260,13 @@ m8xx_ide_init_hwif_ports(hw_regs_t *hw,
> *p++ = base + ioport_dsc[data_port].reg_off[i];
> }
>
> - if (irq) {
> + hw->irq = ioport_dsc[data_port].irq;
> + hw->ack_intr = (ide_ack_intr_t *)ide_interrupt_ack;
> +
> #ifdef CONFIG_IDE_8xx_PCCARD
> + {
> unsigned int reg;
>
> - *irq = ioport_dsc[data_port].irq;
> if (_slot_)
> pgcrx = &((immap_t *)
> IMAP_ADDR)->im_pcmcia.pcmc_pgcrb; else
> @@ -306,14 +276,11 @@ m8xx_ide_init_hwif_ports(hw_regs_t *hw,
> reg |= mk_int_int_mask (pcmcia_schlvl) << 24;
> reg |= mk_int_int_mask (pcmcia_schlvl) << 16;
> *pgcrx = reg;
> -#else/* direct connected IDE drive, i.e. external IRQ, not
> the PCMCIA irq */
> - *irq = ioport_dsc[data_port].irq;
> -#endif /* CONFIG_IDE_8xx_PCCARD */
> }
> +#endif /* CONFIG_IDE_8xx_PCCARD */
>
> ide_hwifs[data_port].pio_mask = ATA_PIO4;
>
Re: [PATCH 0/4]: Respun LMB patches.
On Thu, 14 Feb 2008 14:58:22 -0600 Becky Bruce <[EMAIL PROTECTED]> wrote: > > On Feb 13, 2008, at 7:09 PM, David Miller wrote: > > > > > I've taken into consideration the various feedback, and > > ported the bug fix and other LMB patches posted recently > > in an effort to keep the patch churn by others down wrt. > > my moving of these files. > > > > 1) Use HAVE_LMB as suggested by Sam. > > > > 2) Fix potential build errors wrt. asm/prom.h dependencies. > > > >My algorithm was: > > > >a) If the file only included asm/lmb.h I added an include > > of both linux/lmb.c and asm/prom.h > > > >b) If the file already includes asm/prom.h, I merely > > changed the asm/lmb.h to linux/lmb.h > > > >Header include mimimizations can be done as followon patches. > > > > 3) Integrate Kumar Gala's initial region fix. > > > > 4) Integrate Becky Bruce's large physical addressing change, > >but using u64 instead of phys_addr_t. > > > > It's all at: > > > > master.kernel.org:/pub/scm/linux/kernel/git/davem/lmb-2.6.git > > > > like before. > > > Thanks for picking up the patches from Kumar and myself and fitting > them into your series - this is much appreciated. FYI, I applied the > entire patch series to my local tree and test-booted both mpc8641 and > mpc8568mds and both build and boot cleanly. I also built pasemi and > ebony, those build cleanly as well. I plan on actually testing this on Ebony, Walnut, and Bamboo either later tonight or tomorrow. I don't expect many issues. Dave, those above boards would cover the build of PowerPC 4xx CPU cores. Just an FYI. josh ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Please pull powerpc.git merge branch
Linus,
Please do
git pull \
git://git.kernel.org/pub/scm/linux/kernel/git/paulus/powerpc.git merge
to get a collection of bug-fixes and very minor cleanups for powerpc
(plus one commit wiring up the timerfd syscalls).
Thanks,
Paul.
arch/powerpc/Kconfig |4 ---
arch/powerpc/boot/Makefile |2 +
arch/powerpc/boot/ps3-hvcall.S |2 +
arch/powerpc/kernel/Makefile |2 +
arch/powerpc/kernel/process.c |2 +
arch/powerpc/kernel/vdso.c | 12
arch/powerpc/platforms/512x/Kconfig|1 -
arch/powerpc/platforms/52xx/Kconfig|2 -
arch/powerpc/platforms/Kconfig |2 -
arch/powerpc/platforms/Kconfig.cputype |4 ---
arch/powerpc/platforms/cell/ras.c | 11 ++-
arch/powerpc/platforms/embedded6xx/Kconfig |4 ---
arch/powerpc/platforms/iseries/vio.c |2 +
drivers/char/hvc_rtas.c|2 +
drivers/ps3/ps3-lpm.c | 22 --
drivers/ps3/ps3-sys-manager.c | 44
include/asm-powerpc/systbl.h |4 ++-
include/asm-powerpc/unistd.h |6 +++-
include/asm-ppc/page.h |2 +
19 files changed, 76 insertions(+), 54 deletions(-)
Adrian Bunk (3):
[POWERPC] vdso_do_func_patch{32,64}() must be __init
[POWERPC] free_property() must not be __init
[POWERPC] hvc_rtas_init() must be __init
Geoff Levand (4):
[POWERPC] PS3: Fix bootwrapper hang bug
[POWERPC] PS3: Use system reboot on restart
[POWERPC] PS3: Sys-manager code cleanup
[POWERPC] PS3: Update sys-manager button events
Grant Likely (1):
[POWERPC] Remove unused CONFIG_WANT_DEVICE_TREE
Hugh Dickins (1):
[POWERPC] Fix DEBUG_PREEMPT warning when warning
Kumar Gala (1):
[POWERPC] Remove generated files on make clean
Michael Ellerman (1):
[POWERPC] Cell RAS: Remove DEBUG, and add license and copyright
Stefan Roese (1):
[POWERPC] Fix arch/ppc compilation - add typedef for pgtable_t
Stephen Rothwell (1):
[POWERPC] Wire up new timerfd syscalls
Takashi Yamamoto (2):
[POWERPC] PS3: Fix setting bookmark in logical performance monitor
[POWERPC] PS3: Fix reading pm interval in logical performance monitor
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 0/4]: Respun LMB patches.
From: Becky Bruce <[EMAIL PROTECTED]> Date: Thu, 14 Feb 2008 14:58:22 -0600 > Thanks for picking up the patches from Kumar and myself and fitting > them into your series - this is much appreciated. FYI, I applied the > entire patch series to my local tree and test-booted both mpc8641 and > mpc8568mds and both build and boot cleanly. I also built pasemi and > ebony, those build cleanly as well. Thanks for all of the testing. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: /proc/bus/pci and domains
On Thu, Feb 14, 2008 at 01:43:05PM -0800, David Miller wrote: > From: Martin Mares <[EMAIL PROTECTED]> > Date: Thu, 14 Feb 2008 10:40:22 +0100 > > > Would it be acceptable for the PPC folks to modify the code to add > > domain numbers to the device numbers in /proc/bus/pci/devices in the > > same format as the bus directories already have? > > Be careful, things like the X server parse that file, and X's > parser does not expect domain numbers there so you will break > things :-( It might be best if we only place domain 0 in that file. -- Intel are signing my paycheques ... these opinions are still mine "Bill, look, we understand that you're interested in selling us this operating system, but compare it to ours. We can't possibly take such a retrograde step." ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: /proc/bus/pci and domains
Hi! > > Be careful, things like the X server parse that file, and X's > > parser does not expect domain numbers there so you will break > > things :-( > > It might be best if we only place domain 0 in that file. Yes, that's another possilibity. However, in such cases we should probably create the subdirectories only for domain 0 as well. Have a nice fortnight -- Martin `MJ' Mares <[EMAIL PROTECTED]> http://mj.ucw.cz/ Faculty of Math and Physics, Charles University, Prague, Czech Rep., Earth "Beware of bugs in the above code; I have only proved it correct, not tried it." -- D.E.K. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: /proc/bus/pci and domains
From: Martin Mares <[EMAIL PROTECTED]> Date: Thu, 14 Feb 2008 10:40:22 +0100 > Would it be acceptable for the PPC folks to modify the code to add > domain numbers to the device numbers in /proc/bus/pci/devices in the > same format as the bus directories already have? Be careful, things like the X server parse that file, and X's parser does not expect domain numbers there so you will break things :-( ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: /proc/bus/pci and domains
Hi! > > Would it be acceptable for the PPC folks to modify the code to add > > domain numbers to the device numbers in /proc/bus/pci/devices in the > > same format as the bus directories already have? > > Be careful, things like the X server parse that file, and X's > parser does not expect domain numbers there so you will break > things :-( Yes, but neither does it expect domain numbers in the directory names, I guess :-) But thanks for the tip, I will check X before I post the patch. Have a nice fortnight -- Martin `MJ' Mares <[EMAIL PROTECTED]> http://mj.ucw.cz/ Faculty of Math and Physics, Charles University, Prague, Czech Rep., Earth A student who changes the course of history is probably taking an exam. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 0/4]: Respun LMB patches.
From: Josh Boyer <[EMAIL PROTECTED]> Date: Thu, 14 Feb 2008 15:24:48 -0600 > I plan on actually testing this on Ebony, Walnut, and Bamboo either > later tonight or tomorrow. I don't expect many issues. > > Dave, those above boards would cover the build of PowerPC 4xx CPU cores. Ok. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: /proc/bus/pci and domains
From: Martin Mares <[EMAIL PROTECTED]> Date: Thu, 14 Feb 2008 22:45:14 +0100 > But thanks for the tip, I will check X before I post the patch. X now uses sysfs when available, therefore I think it's best not to try and muck with this deprecated interface if possible. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: /proc/bus/pci and domains
> X now uses sysfs when available, therefore I think it's > best not to try and muck with this deprecated interface > if possible. However, the interface is fatally broken on machines with domains and the breakage is visible (e.g., run lspci when /sys is not mounted). I originally intended to just disable the proc backend on the affected architectures, but it turned out than even x86 can be affected. Have a nice fortnight -- Martin `MJ' Mares <[EMAIL PROTECTED]> http://mj.ucw.cz/ Faculty of Math and Physics, Charles University, Prague, Czech Rep., Earth "God doesn't play dice." -- Albert Einstein ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 2/8] pseries: phyp dump: reserve-release proof-of-concept
On Thu, Feb 14, 2008 at 02:46:21PM +1100, Tony Breeds wrote: > Hi Manish, > Sorry for the minor nits but this should be: > > --- > * Linas Vepstas, Manish Ahuja 2008 > * Copyright 2008 IBM Corp. > --- > > You can optionally use the '??' symbol after word 'Copyright' but you > shouldn't use '(c)' anymore. > > Also in at least one place you've misspelt "Copyright" If we're going to nitpick, then I'd like to point out that the whole series needs to be run through checkpatch and at least the whitespace issues should be taken care of. I'm still not convinced that this is a useful feature compared to hardening kdump, especially now that ehea can handle kexec/kdump (patch posted the other day). But in the end it's up to Paul if he wants to take it or not, not me. -Olof ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 0/4]: Respun LMB patches.
On Thu, Feb 14, 2008 at 02:58:22PM -0600, Becky Bruce wrote: > Thanks for picking up the patches from Kumar and myself and fitting > them into your series - this is much appreciated. FYI, I applied the > entire patch series to my local tree and test-booted both mpc8641 and > mpc8568mds and both build and boot cleanly. I also built pasemi and > ebony, those build cleanly as well. pasemi_defconfig boots happily on my boards here. I've kicked off my "build all powerpc defconfigs" script while I leave the house for a couple of hours, but as others have said, no problems are expected... -Olof ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
RE: [PATCH] [POWERPC] Enable correct operation of serial ports withnonzero regshift.
gcc knows better. :) > -Original Message- > From: Stephen Rothwell [mailto:[EMAIL PROTECTED] > Sent: Thursday, February 14, 2008 3:27 PM > To: Stephen Neuendorffer > Cc: Pavel Kiryukhin; linuxppc-dev@ozlabs.org > Subject: Re: [PATCH] [POWERPC] Enable correct operation of serial ports withnonzero regshift. > > On Thu, 14 Feb 2008 10:55:31 -0800 "Stephen Neuendorffer" <[EMAIL PROTECTED]> wrote: > > > > > --- a/arch/powerpc/kernel/legacy_serial.c > > > +++ b/arch/powerpc/kernel/legacy_serial.c > > > + /* get regshift if present*/ > > > + regshift = get_property(np, "reg-shift", NULL); > > > > of_get_property, presumably? > > Damn, how did I miss that? :-) > > -- > Cheers, > Stephen Rothwell[EMAIL PROTECTED] > http://www.canb.auug.org.au/~sfr/ ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] [POWERPC] Enable correct operation of serial ports withnonzero regshift.
On Thu, 14 Feb 2008 10:55:31 -0800 "Stephen Neuendorffer" <[EMAIL PROTECTED]> wrote: > > > --- a/arch/powerpc/kernel/legacy_serial.c > > +++ b/arch/powerpc/kernel/legacy_serial.c > > + /* get regshift if present*/ > > + regshift = get_property(np, "reg-shift", NULL); > > of_get_property, presumably? Damn, how did I miss that? :-) -- Cheers, Stephen Rothwell[EMAIL PROTECTED] http://www.canb.auug.org.au/~sfr/ pgpNg9UlWVuGe.pgp Description: PGP signature ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 0/4]: Respun LMB patches.
On Thu, 14 Feb 2008 17:21:52 -0600 Olof Johansson <[EMAIL PROTECTED]> wrote: > > On Thu, Feb 14, 2008 at 02:58:22PM -0600, Becky Bruce wrote: > > > Thanks for picking up the patches from Kumar and myself and fitting > > them into your series - this is much appreciated. FYI, I applied the > > entire patch series to my local tree and test-booted both mpc8641 and > > mpc8568mds and both build and boot cleanly. I also built pasemi and > > ebony, those build cleanly as well. > > pasemi_defconfig boots happily on my boards here. I've kicked off my > "build all powerpc defconfigs" script while I leave the house for a > couple of hours, but as others have said, no problems are expected... It builds and boots on legacy iSeries (and seems to be working ok) as well. -- Cheers, Stephen Rothwell[EMAIL PROTECTED] http://www.canb.auug.org.au/~sfr/ pgpOvmZWAM2QI.pgp Description: PGP signature ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 3/8] pseries: phyp dump: use sysfs to release reserved mem
On Tue, Feb 12, 2008 at 01:11:58AM -0600, Manish Ahuja wrote:
> +static ssize_t
> +show_release_region(struct kset * kset, char *buf)
> +{
> + return sprintf(buf, "ola\n");
> +}
> +
> +static struct subsys_attribute rr = __ATTR(release_region, 0600,
> + show_release_region,
> + store_release_region);
Any reason this sysfs attribute can't be write only? The show method
doesn't seem needed.
> +static int __init phyp_dump_setup(void)
> +{
> + /* Is there dump data waiting for us? */
> + rtas = of_find_node_by_path("/rtas");
> + dump_header = of_get_property(rtas, "ibm,kernel-dump", &header_len);
Hmm this isn't good. You need to check rtas != NULL.
> + if (dump_header == NULL) {
> + release_all();
> + return 0;
> + }
> +
> + /* Should we create a dump_subsys, analogous to s390/ipl.c ? */
> + rc = subsys_create_file(&kernel_subsys, &rr);
> + if (rc) {
> + printk (KERN_ERR "phyp-dump: unable to create sysfs file
> (%d)\n", rc);
> + release_all();
> + return 0;
> + }
>
> return 0;
> }
> -
> subsys_initcall(phyp_dump_setup);
Hmm I think this really should be a:
machine_subsys_initcall(pseries, phyp_dump_setup)
Yours Tony
linux.conf.auhttp://linux.conf.au/ || http://lca2008.linux.org.au/
Jan 28 - Feb 02 2008 The Australian Linux Technical Conference!
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
dtc: Fold comment handling test into testsuite
For ages dtc has included a sample dts, comment-test.dts, for checking
various lexical corner cases in comment processing. In fact, it
predates the automated testsuite, and has never been integrated into
it. This patch addresses this oversight, folding the comment handling
test in with the rest of the testsuite.
Signed-off-by: David Gibson <[EMAIL PROTECTED]>
Index: dtc/comment-test.dts
===
--- dtc.orig/comment-test.dts 2008-02-15 15:01:06.0 +1100
+++ /dev/null 1970-01-01 00:00:00.0 +
@@ -1,38 +0,0 @@
-/* regexps for lexing comments are.. tricky. Check if we've actually
- * got it right */
-
-/ {
- // line comment
- prop1;
- /* comment */
- prop2;
- /* multiline
-
- notaprop1;
-
- comment */
- prop3;
- /**/
- prop4;
- /***/
- prop5;
- //
- prop6;
- /* another
-* multiline
-* comment */
- prop7;
- /* yet
-* another
-* multline
-* comment
-*/
- prop8;
- /** try this */
- prop9;
- /* and this **/
- prop10;
- child /* finally */ {
- };
-};
-/* final comment */
Index: dtc/tests/comments.dts
===
--- /dev/null 1970-01-01 00:00:00.0 +
+++ dtc/tests/comments.dts 2008-02-15 15:05:50.0 +1100
@@ -0,0 +1,39 @@
+/* regexps for lexing comments are.. tricky. Check if we've actually
+ * got it right */
+/dts-v1/;
+
+/ {
+ // line comment
+ prop1;
+ /* comment */
+ prop2;
+ /* multiline
+
+ notaprop1;
+
+ comment */
+ prop3;
+ /**/
+ prop4;
+ /***/
+ prop5;
+ //
+ prop6;
+ /* another
+* multiline
+* comment */
+ prop7;
+ /* yet
+* another
+* multline
+* comment
+*/
+ prop8;
+ /** try this */
+ prop9;
+ /* and this **/
+ prop10;
+ child /* finally */ {
+ };
+};
+/* final comment */
Index: dtc/tests/run_tests.sh
===
--- dtc.orig/tests/run_tests.sh 2008-02-15 15:01:20.0 +1100
+++ dtc/tests/run_tests.sh 2008-02-15 15:08:09.0 +1100
@@ -155,6 +155,10 @@ dtc_tests () {
run_test dtc.sh -I dts -O dtb -o dtc_path-references.test.dtb
path-references.dts
run_test path-references dtc_path-references.test.dtb
+run_test dtc.sh -I dts -O dtb -o dtc_comments.test.dtb comments.dts
+run_test dtc.sh -I dts -O dtb -o dtc_comments-cmp.test.dtb comments-cmp.dts
+run_test dtbs_equal_ordered dtc_comments.test.dtb dtc_comments-cmp.test.dtb
+
# Check -Odts mode preserve all dtb information
for tree in test_tree1.dtb dtc_tree1.test.dtb dtc_escapes.test.dtb ; do
run_test dtc.sh -I dtb -O dts -o odts_$tree.test.dts $tree
Index: dtc/tests/comments-cmp.dts
===
--- /dev/null 1970-01-01 00:00:00.0 +
+++ dtc/tests/comments-cmp.dts 2008-02-15 15:07:04.0 +1100
@@ -0,0 +1,16 @@
+/dts-v1/;
+
+/ {
+ prop1;
+ prop2;
+ prop3;
+ prop4;
+ prop5;
+ prop6;
+ prop7;
+ prop8;
+ prop9;
+ prop10;
+ child {
+ };
+};
--
David Gibson| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
a question on an error of building 2.6.24.2
Hi there, I am using a cross-compiler gcc 4.1.2 and glibc 2.3.6 to build 2.6.24.2 for a adder875 board. At the end of building, the ld gives the following error messages: LD init/built-in.o LD vmlinux `.exit.data' referenced in section `.exit.text' of drivers/built-in.o: defined in discarded section `.exit.data' of drivers/built-in.o `.exit.data' referenced in section `.exit.text' of drivers/built-in.o: defined in discarded section `.exit.data' of drivers/built-in.o `.exit.data' referenced in section `.exit.text' of drivers/built-in.o: defined in discarded section `.exit.data' of drivers/built-in.o `.exit.data' referenced in section `.exit.text' of drivers/built-in.o: defined in discarded section `.exit.data' of drivers/built-in.o make: *** [vmlinux] Error 1 .config file is also attached. Is it gcc problem, or something else? Thanks. Jingyu ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 04/11] [RFC][GPIOLIB] add gpio_set_dedicated() routine
On Sunday 03 February 2008, Anton Vorontsov wrote:
> On Sun, Feb 03, 2008 at 01:22:08PM -0800, David Brownell wrote:
> [...]
>
> > So when you assume that a GPIO number can uniquely specify a pin for
> > use in function multiplexing ... you're stressing a "nonportable"
> > aspect of this issue.
> >
> > Ditto when you assume that the multiplexing is on a per-pin basis,
> > rather than affecting a defined group of pins. (More common, and
> > less annoying, than the OMAP1 issue.)
> >
> > (And that doesn't even touch issues like configurable drive strength,
> > pullups, pulldowns, and so on.)
>
> This is all true, of course.
And a related truism: with at best rare exceptions, those things
get set up once at board setup and don't change later. So the
audience for reconfiguring pins is quite limited ... basically
it'd all be for code which is already hardware-specific.
That's much less true of GPIOs. It really *is* practical to have
generic GPIO based drivers for LEDs, keypad buttons, bitbanged
I2C, 1-wire, SPI ... etc.
> > > Imagine some
> > > GPIO controller that can't do inputs, or outputs. First one will be
> > > still suitable for gpio_leds, second one will be suitable for gpio_keys.
> >
> > The interface easily handles input-only and output-only GPIOs.
> > Make the relevant gpio_direction_*() methods fail those requests.
>
> The point was: GPIOs could be "input only" but you still have
> "output" callback, and that doesn't troubles anybody. Not sure
> why set_dedicated() such a big issue then, it could fail too! :-)
See above: you're equating pin and gpio ... and while GPIOs
have (by definition) standardized boolean input and output
functionality, the rest of what can be done with a pin isn't.
> We're talking about General Purpose IOs, right? They're general
> enough to support not only input/output stuff. And we want some
> API for these General Purpose IOs. GPIO LIB is the best candidate
> and we can implement such API at almost no cost, few lines of code.
GPIOs are not intended to be a kitchen sink though; and that's
the sense in which you seem to mean "best candidate": it's a
clean lightweight interface, not gummed up with all kinds of
unrelated stuff.
Take your ideas and use them to create a pin configuration
interface. On some platforms, configurable pins will map
onto GPIOs, one-to-one. On others, there will be configurable
pins that aren't GPIOs ... GPIOs that can be mapped to any of
several pins ... pins that can be used with several GPIOs ...
pins that can only be used with GPIOs ... and so on.
> He-he. Actually, I have a patch that adds "to_irq" callback
> to GPIO LIB. :-) But I just didn't find time yet to cleanup
> the "user" of that addition (ARM-based "samcop" companion chip).
>
> Briefly: gpio<->irq mapping there isn't "flat". It is messed
> all around. GPIO 1 is IRQ 12, GPIO 2 if IRQ 45 and so on... no
> common pattern. So, to support gpio_to_irq() we have to either:
>
> 1. change the mappings of the IRQs, to match GPIOs.
> or
> 2. implement to_irq() callback (way easier).
That seems like maybe a reasonable thing to add to gpiolib.
It's fully within the current scope of the GPIO interface.
Show it when you've got a cleaned up version...
And although the original notion was that those mappings
cost on the order of an addition, I think that's not a big
deal ... except maybe sometimes for irq_to_gpio().
> > > So, down below is the proposal patch: gpio_set_dedicated() routine.
> > >
> > > There are other options, tough. But I don't like them:
> > >
> > > ...
> > >
> > > - Another option?
> >
> > The way it's usually done: platform-specific code to handle those
> > platform-specific pin configuration issues.
>
> There is a problem. Driver could be cross-platform. For example,
> we have platforms with "CPM1", "CPM2" and "QE" on-chip gpio
> controllers.
So "platform" isn't exactly the right word. "Hardware-specific"
is more to the point. You know you're using and
that means you must reconfigure because ; or
likewise, must be reconfigured etc.
> And despite special _set_dedicated() function, this driver
> actually does _use_ pins as GPIOs. And as dedicated functions.
> And as GPIOs. The same pins, but at the different times.
But you're assuming that GPIO identifiers can be used as pin/ball
identifiers ... and as I pointed out, that's chip-specific.
> Will you agree to export "chips" so we can write
> GPIO LIB "platform extensions", like
>
> qe_set_dedicated(unsigned int value_that_we_got_from_gpio_request)
gpio_request() returns zero-or-negative-errno. Never unsigned int. ;)
> {
> qe_chip = container_of(gpio_to_chip(...), struct qe_chip, chip);
> ...
You know, you can write all this yourself, without needing any
support from the GPIO framework whatsoever. The QE stuff that
registered a gpio_chip interface to its hardware probably keeps
some records itself, sufficient for such (infrequent) mappings.
> > > +int gpio_set
Re: [PATCH 1/2] fb: add support for foreign endianness
On Tue, 5 Feb 2008 18:44:32 +0300 Anton Vorontsov <[EMAIL PROTECTED]> wrote:
> This patch adds support for the framebuffers with non-native
> endianness. This is done via FBINFO_FOREIGN_ENDIAN flag that will
> be used by the drivers. Depending on the host endianness this flag
> will be overwritten by FBINFO_BE_MATH internal flag, or cleared.
>
> Tested to work on MPC8360E-RDK (BE) + Fujitsu MINT framebuffer (LE).
That's a pretty large patch to fbdev core, and Tony appears to have gone
offline again and you didn't cc the fbdev mailing list.
I fixed the third problem. Could the other fbdev developers please review
and comment on this?
Thanks.
Actually... should CONFIG_FB_FOREIGN_ENDIAN exist, or should this feature
be permanently enabled?
I'd like to at least queue a patch in -mm so that CONFIG_FB_FOREIGN_ENDIAN
is forced-on, so the code gets some runtime testing. Will that break
anything?
From: Anton Vorontsov <[EMAIL PROTECTED]>
Add support for the framebuffers with non-native endianness. This is done via
FBINFO_FOREIGN_ENDIAN flag that will be used by the drivers. Depending on the
host endianness this flag will be overwritten by FBINFO_BE_MATH internal flag,
or cleared.
Tested to work on MPC8360E-RDK (BE) + Fujitsu MINT framebuffer (LE).
Signed-off-by: Anton Vorontsov <[EMAIL PROTECTED]>
Cc: "Antonino A. Daplas" <[EMAIL PROTECTED]>
Cc: Benjamin Herrenschmidt <[EMAIL PROTECTED]>
Cc: Paul Mackerras <[EMAIL PROTECTED]>
Signed-off-by: Andrew Morton <[EMAIL PROTECTED]>
---
drivers/video/Kconfig |9 +
drivers/video/cfbcopyarea.c | 23 ---
drivers/video/cfbfillrect.c | 48 +--
drivers/video/cfbimgblt.c | 52 +-
drivers/video/fb_draw.h | 31 +++-
drivers/video/fbmem.c |8 +
drivers/video/syscopyarea.c | 20 ++---
drivers/video/sysfillrect.c | 49
drivers/video/sysimgblt.c | 47 ++
include/linux/fb.h | 36 +--
10 files changed, 183 insertions(+), 140 deletions(-)
diff -puN drivers/video/Kconfig~fb-add-support-for-foreign-endianness
drivers/video/Kconfig
--- a/drivers/video/Kconfig~fb-add-support-for-foreign-endianness
+++ a/drivers/video/Kconfig
@@ -139,6 +139,15 @@ config FB_SYS_IMAGEBLIT
blitting. This is used by drivers that don't provide their own
(accelerated) version and the framebuffer is in system RAM.
+config FB_FOREIGN_ENDIAN
+ bool "Enable support for foreign endianness"
+ depends on FB
+ ---help---
+ This option enables support for the framebuffers with non-native
+ endianness (e.g. Little-Endian framebuffer on a Big-Endian machine).
+ You probably don't have such hardware, so in most cases it's safe to
+ say "n" here.
+
config FB_SYS_FOPS
tristate
depends on FB
diff -puN drivers/video/cfbcopyarea.c~fb-add-support-for-foreign-endianness
drivers/video/cfbcopyarea.c
--- a/drivers/video/cfbcopyarea.c~fb-add-support-for-foreign-endianness
+++ a/drivers/video/cfbcopyarea.c
@@ -44,15 +44,16 @@
*/
static void
-bitcpy(unsigned long __iomem *dst, int dst_idx, const unsigned long __iomem
*src,
- int src_idx, int bits, unsigned n, u32 bswapmask)
+bitcpy(struct fb_info *p, unsigned long __iomem *dst, int dst_idx,
+ const unsigned long __iomem *src, int src_idx, int bits,
+ unsigned n, u32 bswapmask)
{
unsigned long first, last;
int const shift = dst_idx-src_idx;
int left, right;
- first = fb_shifted_pixels_mask_long(dst_idx, bswapmask);
- last = ~fb_shifted_pixels_mask_long((dst_idx+n) % bits, bswapmask);
+ first = fb_shifted_pixels_mask_long(p, dst_idx, bswapmask);
+ last = ~fb_shifted_pixels_mask_long(p, (dst_idx+n) % bits, bswapmask);
if (!shift) {
// Same alignment for source and dest
@@ -202,8 +203,9 @@ bitcpy(unsigned long __iomem *dst, int d
*/
static void
-bitcpy_rev(unsigned long __iomem *dst, int dst_idx, const unsigned long
__iomem *src,
- int src_idx, int bits, unsigned n, u32 bswapmask)
+bitcpy_rev(struct fb_info *p, unsigned long __iomem *dst, int dst_idx,
+ const unsigned long __iomem *src, int src_idx, int bits,
+ unsigned n, u32 bswapmask)
{
unsigned long first, last;
int shift;
@@ -221,8 +223,9 @@ bitcpy_rev(unsigned long __iomem *dst, i
shift = dst_idx-src_idx;
- first = fb_shifted_pixels_mask_long(bits - 1 - dst_idx, bswapmask);
- last = ~fb_shifted_pixels_mask_long(bits - 1 - ((dst_idx-n) % bits),
bswapmask);
+ first = fb_shifted_pixels_mask_long(p, bits - 1 - dst_idx, bswapmask);
+ last = ~fb_shifted_pixels_mask_long(p, bits - 1 - ((dst_idx-n) % bits),
+ bswapmask);
if (!sh
Re: [PATCH 2/8] pseries: phyp dump: reserve-release proof-of-concept
Olof, I will run it through checkpatch before resubmitting. Thanks, Manish Olof Johansson wrote: > On Thu, Feb 14, 2008 at 02:46:21PM +1100, Tony Breeds wrote: > >> Hi Manish, >> Sorry for the minor nits but this should be: >> >> --- >> * Linas Vepstas, Manish Ahuja 2008 >> * Copyright 2008 IBM Corp. >> --- >> >> You can optionally use the '??' symbol after word 'Copyright' but you >> shouldn't use '(c)' anymore. >> >> Also in at least one place you've misspelt "Copyright" > > If we're going to nitpick, then I'd like to point out that the whole > series needs to be run through checkpatch and at least the whitespace > issues should be taken care of. > > I'm still not convinced that this is a useful feature compared to > hardening kdump, especially now that ehea can handle kexec/kdump (patch > posted the other day). But in the end it's up to Paul if he wants to > take it or not, not me. > > > -Olof ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 3/8] pseries: phyp dump: use sysfs to release reserved mem
Tony Breeds wrote:
> On Tue, Feb 12, 2008 at 01:11:58AM -0600, Manish Ahuja wrote:
>
>
>
>> +static ssize_t
>> +show_release_region(struct kset * kset, char *buf)
>> +{
>> +return sprintf(buf, "ola\n");
>> +}
>> +
>> +static struct subsys_attribute rr = __ATTR(release_region, 0600,
>> + show_release_region,
>> + store_release_region);
>
> Any reason this sysfs attribute can't be write only? The show method
> doesn't seem needed.
yes, its used later in the code.
>
>> +static int __init phyp_dump_setup(void)
>> +{
>
>
>
>> +/* Is there dump data waiting for us? */
>> +rtas = of_find_node_by_path("/rtas");
>> +dump_header = of_get_property(rtas, "ibm,kernel-dump", &header_len);
>
> Hmm this isn't good. You need to check rtas != NULL.
yes, will fix this as well.
>
>> +if (dump_header == NULL) {
>> +release_all();
>> +return 0;
>> +}
>> +
>> +/* Should we create a dump_subsys, analogous to s390/ipl.c ? */
>> +rc = subsys_create_file(&kernel_subsys, &rr);
>> +if (rc) {
>> +printk (KERN_ERR "phyp-dump: unable to create sysfs file
>> (%d)\n", rc);
>> +release_all();
>> +return 0;
>> +}
>>
>> return 0;
>> }
>> -
>> subsys_initcall(phyp_dump_setup);
>
> Hmm I think this really should be a:
> machine_subsys_initcall(pseries, phyp_dump_setup)
>
> Yours Tony
>
> linux.conf.auhttp://linux.conf.au/ || http://lca2008.linux.org.au/
> Jan 28 - Feb 02 2008 The Australian Linux Technical Conference!
>
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
