[PATCH] arch/powerpc/: fix kernel-doc warning
From: Wanpeng Li
Warning(arch/powerpc/kernel/pci_of_scan.c:210): Excess function parameter
'node' description in 'of_scan_pci_bridge'
Warning(arch/powerpc/kernel/vio.c:636): No description found for parameter
'desired'
Warning(arch/powerpc/kernel/vio.c:636): Excess function parameter 'new_desired'
description in 'vio_cmo_set_dev_desired'
Warning(arch/powerpc/kernel/vio.c:1270): No description found for parameter
'viodrv'
Warning(arch/powerpc/kernel/vio.c:1270): Excess function parameter 'drv'
description in '__vio_register_driver'
Warning(arch/powerpc/kernel/vio.c:1289): No description found for parameter
'viodrv'
Warning(arch/powerpc/kernel/vio.c:1289): Excess function parameter 'driver'
description in 'vio_unregister_driver'
Signed-off-by: Wanpeng Li
---
arch/powerpc/kernel/pci_of_scan.c |1 -
arch/powerpc/kernel/vio.c |6 +++---
2 files changed, 3 insertions(+), 4 deletions(-)
diff --git a/arch/powerpc/kernel/pci_of_scan.c
b/arch/powerpc/kernel/pci_of_scan.c
index 89dde17..d7dd42b 100644
--- a/arch/powerpc/kernel/pci_of_scan.c
+++ b/arch/powerpc/kernel/pci_of_scan.c
@@ -198,7 +198,6 @@ EXPORT_SYMBOL(of_create_pci_dev);
/**
* of_scan_pci_bridge - Set up a PCI bridge and scan for child nodes
- * @node: device tree node of bridge
* @dev: pci_dev structure for the bridge
*
* of_scan_bus() calls this routine for each PCI bridge that it finds, and
diff --git a/arch/powerpc/kernel/vio.c b/arch/powerpc/kernel/vio.c
index cb87301..06cbc30 100644
--- a/arch/powerpc/kernel/vio.c
+++ b/arch/powerpc/kernel/vio.c
@@ -625,7 +625,7 @@ struct dma_map_ops vio_dma_mapping_ops = {
* vio_cmo_set_dev_desired - Set desired entitlement for a device
*
* @viodev: struct vio_dev for device to alter
- * @new_desired: new desired entitlement level in bytes
+ * @desired: new desired entitlement level in bytes
*
* For use by devices to request a change to their entitlement at runtime or
* through sysfs. The desired entitlement level is changed and a balancing
@@ -1262,7 +1262,7 @@ static int vio_bus_remove(struct device *dev)
/**
* vio_register_driver: - Register a new vio driver
- * @drv: The vio_driver structure to be registered.
+ * @viodrv:The vio_driver structure to be registered.
*/
int __vio_register_driver(struct vio_driver *viodrv, struct module *owner,
const char *mod_name)
@@ -1282,7 +1282,7 @@ EXPORT_SYMBOL(__vio_register_driver);
/**
* vio_unregister_driver - Remove registration of vio driver.
- * @driver:The vio_driver struct to be removed form registration
+ * @viodrv:The vio_driver struct to be removed form registration
*/
void vio_unregister_driver(struct vio_driver *viodrv)
{
--
1.7.9.5
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 2/2] [POWERPC] uprobes: powerpc port
On Tue, Jun 12, 2012 at 02:01:46PM +1000, Michael Ellerman wrote: > On Fri, 2012-06-08 at 14:51 +0530, Ananth N Mavinakayanahalli wrote: > > On Fri, Jun 08, 2012 at 04:38:17PM +1000, Michael Ellerman wrote: > > > On Fri, 2012-06-08 at 11:49 +0530, Ananth N Mavinakayanahalli wrote: > > > > On Fri, Jun 08, 2012 at 04:17:44PM +1000, Michael Ellerman wrote: > > > > > On Fri, 2012-06-08 at 11:31 +0530, Ananth N Mavinakayanahalli wrote: > > > > > > On Fri, Jun 08, 2012 at 03:51:54PM +1000, Michael Ellerman wrote: > > > > > > > On Fri, 2012-06-08 at 10:06 +0530, Ananth N Mavinakayanahalli > > > > > > > wrote: > > > > > > > > > > > > But MSR_PR=1 and hence emulate_step() will return -1 and hence we > > > > > > will > > > > > > end up single-stepping using user_enable_single_step(). Same with > > > > > > rfid. > > > > > > > > > > Right. But that was exactly Jim's point, you may be asked to emulate > > > > > those instructions even though you wouldn't expect to see them in > > > > > userspace code, so you need to handle it. > > > > > > > > > > Luckily it looks like emulate_step() will do the right thing for you. > > > > > It'd be good to test it to make 100% sure. > > > > > > > > Sure. Will add that check and send v2. > > > > > > Sorry I didn't mean add a test in the code, I meant construct a test > > > case to confirm that it works as expected. > > > > Michael, > > > > I just hand-coded the instr to emulate_step() and here are the results: > > > > MSR_PR is set > > insn = 7c600124, ret = 0 /* mtmsr */ > > insn = 7c600164, ret = 0 /* mtmsrd */ > > insn = 4c24, ret = -1 /* rfid */ > > insn = 4c64, ret = 0 /* rfi */ > > > > Also verified that standalone programs with those instructions in inline > > asm will die with a SIGILL. > > > > So, for mtmsr, mtmsrd and rfi, we have to single-step them which will > > result in a SIGILL in turn. > > What happens in the rfid case? You don't handle -1 from emulate_step() > any differently AFAICS, so don't we try to single step that too? -1 is just emulate_step() flagging cases where instructions must not be single-stepped (rfi[d], mtmsr that clears MSR_RI). But as with the other OEA instructions in user space, we fail with a SIGILL. As the application is hozed in any case if we encounter an OEA instruction, I'd think there is no point in handling a -1 from emulate_step() any differently. Ananth ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 2/2] [POWERPC] uprobes: powerpc port
On Fri, 2012-06-08 at 14:51 +0530, Ananth N Mavinakayanahalli wrote: > On Fri, Jun 08, 2012 at 04:38:17PM +1000, Michael Ellerman wrote: > > On Fri, 2012-06-08 at 11:49 +0530, Ananth N Mavinakayanahalli wrote: > > > On Fri, Jun 08, 2012 at 04:17:44PM +1000, Michael Ellerman wrote: > > > > On Fri, 2012-06-08 at 11:31 +0530, Ananth N Mavinakayanahalli wrote: > > > > > On Fri, Jun 08, 2012 at 03:51:54PM +1000, Michael Ellerman wrote: > > > > > > On Fri, 2012-06-08 at 10:06 +0530, Ananth N Mavinakayanahalli wrote: > > > > > > > > > > But MSR_PR=1 and hence emulate_step() will return -1 and hence we will > > > > > end up single-stepping using user_enable_single_step(). Same with > > > > > rfid. > > > > > > > > Right. But that was exactly Jim's point, you may be asked to emulate > > > > those instructions even though you wouldn't expect to see them in > > > > userspace code, so you need to handle it. > > > > > > > > Luckily it looks like emulate_step() will do the right thing for you. > > > > It'd be good to test it to make 100% sure. > > > > > > Sure. Will add that check and send v2. > > > > Sorry I didn't mean add a test in the code, I meant construct a test > > case to confirm that it works as expected. > > Michael, > > I just hand-coded the instr to emulate_step() and here are the results: > > MSR_PR is set > insn = 7c600124, ret = 0 /* mtmsr */ > insn = 7c600164, ret = 0 /* mtmsrd */ > insn = 4c24, ret = -1 /* rfid */ > insn = 4c64, ret = 0 /* rfi */ > > Also verified that standalone programs with those instructions in inline > asm will die with a SIGILL. > > So, for mtmsr, mtmsrd and rfi, we have to single-step them which will > result in a SIGILL in turn. What happens in the rfid case? You don't handle -1 from emulate_step() any differently AFAICS, so don't we try to single step that too? cheers ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH 0/6] Description for PCI patches using platform driver
> -Original Message- > From: Wood Scott-B07421 > Sent: Monday, June 11, 2012 11:43 PM > To: Jia Hongtao-B38951 > Cc: Bhushan Bharat-R65777; linuxppc-dev@lists.ozlabs.org; > ga...@kernel.crashing.org; Li Yang-R58472; b...@kernel.crashing.org; Wood > Scott-B07421 > Subject: Re: [PATCH 0/6] Description for PCI patches using platform > driver > > On 06/10/2012 09:33 PM, Jia Hongtao-B38951 wrote: > >> -Original Message- > >> From: Bhushan Bharat-R65777 > >> Sent: Friday, June 08, 2012 6:47 PM > >> To: Jia Hongtao-B38951; linuxppc-dev@lists.ozlabs.org; > >> ga...@kernel.crashing.org > >> Cc: Li Yang-R58472; b...@kernel.crashing.org; Wood Scott-B07421 > >> Subject: RE: [PATCH 0/6] Description for PCI patches using platform > >> driver > >> > >> > >>> -Original Message- > >>> From: Jia Hongtao-B38951 > >>> Sent: Friday, June 08, 2012 3:12 PM > >>> To: linuxppc-dev@lists.ozlabs.org; ga...@kernel.crashing.org > >>> Cc: Li Yang-R58472; b...@kernel.crashing.org; Wood Scott-B07421; > >> Bhushan Bharat- > >>> R65777; Jia Hongtao-B38951 > >>> Subject: [PATCH 0/6] Description for PCI patches using platform > driver > >>> > >>> This series of patches are to unify pci initialization code and add > PM > >> support > >>> for all 85xx/86xx powerpc boards. But two side effects are introduced > >> by this > >>> mechanism which listed below: > >>> > >>> 1. of_platform_bus_probe() will be called twice but in some cases > >> duplication > >>>warning occured. We fix this in [PATCH 5/6]. > >>> > >>> 2. Edac driver failed to register pci nodes as platform devices. We > fix > >> this > >>>in [PATCH 6/6]. > >> > >> With these patches will not the SWIOTLB will not be initialized even > if > >> PCI/PCIe demanded? > >> > >> Thanks > >> -Bharat > >> > > > > These patches still have the swiotlb init problem if > "ppc_swiotlb_enable" is > > only demanded by PCI/PCIe. One of the purposes of sending out these > patches > > is to let us start a discussion for this problem in upstream. > > When sending out a patchset like that, label it as [RFC PATCH] (request > for comments), and mention all known problems to be resolved. > > -Scott I got it. Thanks for your remind. -Jia Hongtao. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH 0/6] Description for PCI patches using platform driver
> -Original Message-
> From: Bhushan Bharat-R65777
> Sent: Monday, June 11, 2012 9:25 PM
> To: Jia Hongtao-B38951; linuxppc-dev@lists.ozlabs.org;
> ga...@kernel.crashing.org
> Cc: Li Yang-R58472; b...@kernel.crashing.org; Wood Scott-B07421
> Subject: RE: [PATCH 0/6] Description for PCI patches using platform
> driver
>
>
>
> > -Original Message-
> > From: Jia Hongtao-B38951
> > Sent: Monday, June 11, 2012 8:03 AM
> > To: Bhushan Bharat-R65777; linuxppc-dev@lists.ozlabs.org;
> > ga...@kernel.crashing.org
> > Cc: Li Yang-R58472; b...@kernel.crashing.org; Wood Scott-B07421
> > Subject: RE: [PATCH 0/6] Description for PCI patches using platform
> driver
> >
> > > -Original Message-
> > > From: Bhushan Bharat-R65777
> > > Sent: Friday, June 08, 2012 6:47 PM
> > > To: Jia Hongtao-B38951; linuxppc-dev@lists.ozlabs.org;
> > > ga...@kernel.crashing.org
> > > Cc: Li Yang-R58472; b...@kernel.crashing.org; Wood Scott-B07421
> > > Subject: RE: [PATCH 0/6] Description for PCI patches using platform
> > > driver
> > >
> > >
> > > > -Original Message-
> > > > From: Jia Hongtao-B38951
> > > > Sent: Friday, June 08, 2012 3:12 PM
> > > > To: linuxppc-dev@lists.ozlabs.org; ga...@kernel.crashing.org
> > > > Cc: Li Yang-R58472; b...@kernel.crashing.org; Wood Scott-B07421;
> > > Bhushan Bharat-
> > > > R65777; Jia Hongtao-B38951
> > > > Subject: [PATCH 0/6] Description for PCI patches using platform
> > > > driver
> > > >
> > > > This series of patches are to unify pci initialization code and add
> > > > PM
> > > support
> > > > for all 85xx/86xx powerpc boards. But two side effects are
> > > > introduced
> > > by this
> > > > mechanism which listed below:
> > > >
> > > > 1. of_platform_bus_probe() will be called twice but in some cases
> > > duplication
> > > >warning occured. We fix this in [PATCH 5/6].
> > > >
> > > > 2. Edac driver failed to register pci nodes as platform devices. We
> > > > fix
> > > this
> > > >in [PATCH 6/6].
> > >
> > > With these patches will not the SWIOTLB will not be initialized even
> > > if PCI/PCIe demanded?
> > >
> > > Thanks
> > > -Bharat
> > >
> >
> > These patches still have the swiotlb init problem if
> "ppc_swiotlb_enable" is
> > only demanded by PCI/PCIe. One of the purposes of sending out these
> patches is
> > to let us start a discussion for this problem in upstream.
>
> Ok, I did not find any mention of that, so I thought that you have
> resolved the issue by some means in these patches which I did not catch.
>
> So, these patches introduces the issue, that SWIOTLB will not be
> initialized if requested by pci/pcie. The request is raised by setting
> the flag ppc_swiotlb_enable. The swiotlb_init() will be called in
> mem_init() if ppc_swiotlb_enable is set. Now with these patches, the
> request is raised after mem_init() is called. So request not handled :).
>
> Following are the solutions we have thought of during our internal
> discussions (if I did not missed any):
>
> 1. These patches move the code from platform init to device init
> (arch_initcall()). Rather than moving the whole code, let us divide the
> code into two. First, which is needed to raise the swiotlb init request
> and second the rest. Define this first as an function in
> arch/powerpc/sysdev/fsl_pci.c and call this from platform init code of
> the SOCs.
>
> 2. All known devices, the lowest PCIe outbound range starts at 0x8000,
> but there's nothing above 0xc000. So the inbound of size 0x8000_
> is always availbe on all devices. Hardcode the check in platform code to
> check memblock_end_of_DRAM() to 0x8000.
>
> Something like this:
>
> diff --git a/arch/powerpc/platforms/85xx/corenet_ds.c
> b/arch/powerpc/platforms/85xx/corenet_ds.c
> index 1f7028e..ef4e215 100644
> --- a/arch/powerpc/platforms/85xx/corenet_ds.c
> +++ b/arch/powerpc/platforms/85xx/corenet_ds.c
> @@ -79,7 +79,7 @@ void __init corenet_ds_setup_arch(void) #endif
>
> #ifdef CONFIG_SWIOTLB
> - if (memblock_end_of_DRAM() > 0x)
> + if (memblock_end_of_DRAM() > 0xff00)
> ppc_swiotlb_enable = 1; #endif
> pr_info("%s board from Freescale Semiconductor\n", ppc_md.name);
>
> -
>
> 3. Always do swiotlb_init() in mem_init() and later after PCI init, if
> the swiotlb is not needed then free it (swiotlb_free()).
>
> 4. etc, please provide some other better way.
>
> Thanks
> -Bharat
Thanks.
In my point of view the 2nd solution is better for it does not treat PCI/PCIe as
the special kind of devices from others.
-Jia Hongtao.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v2 0/2] Add pcibios_device_change_notifier
On Mon, 2012-06-11 at 16:51 -0600, Bjorn Helgaas wrote: > > This makes me a bit nervous (that doesn't mean it's not right, but > > we need some careful auditing & testing here, which I won't be > > able to do until I'm back from leave). Mostly due to the change in when > > we do the work. > > > > pcibios_fixup_bus() used to be called early on in the initial scan pass. > > > > Your code causes the code to be called -much- later when registering the > > device with the device model. Are we 100% certain nothing will happen in > > between that might rely on the stuff being setup already ? It might well > > be ok, but I want us to triple check that. > > Here's my theory on this: we're setting up DMA and IRQ stuff. DMA and > IRQ usage is device-specific, so the core can't do anything with them. > Only drivers know how to use them. Drivers can't find the device > until it's registered with the device model. So it seems like it > should be safe to move it later. Subject to thinkos and testing in > the real world, of course :) I am aware of that and that's why I say "might well be ok" :-) But this is old code and you know what can happen in there ... might be a quirk here or a piece of platform code there trying to fixup the IRQ for example ... before we set it up. That sort of thing. I should be allright, but I want to test, which I won't be able to do properly before I'm back at work next week. > > Now, if we are ok to do the setup that late (basically right before the > > driver probe() routine gets called), would it make sense to simplify > > things even further ... and do it from pcibios_enable_device() ? Thus > > avoiding the notifier business completely or is that pushing it too > > far ? > > Kenji-san actually suggested using pcibios_enable_device() early on, > and I'm the one who suggested the notifiers instead. I think I > suggested that because I was copying the amd_iommu_init_notifier() > style. > > But I now think that might have been a mistake. Notifiers are > definitely more complicated, and a pcibios_*() hook seems > straightforward. It could be in pcibios_enable_device(), though we > only need it to be called once, and the enable_device() path may be > called many times, e.g., every time a driver claims it. My new vote > is a pcibios_device_add(), with an empty weak definition in > drivers/pci, and a non-empty definition for microblaze and powerpc. Would it be called before or after the notifiers ? I wonder... if others already use the notifiers maybe we should stick to it. I only suggested pcibios_enable_device() because it's already there. > > Also you seem to add: > > > > + /* Setup OF node pointer in the device */ > > + dev->dev.of_node = pci_device_to_OF_node(dev); > > > > This shouldn't be needed anymore, the device node should be setup by the > > core nowadays. Is this just a remnant of you rebasing an old patch or do > > you have a good reason to add this statement ? > > It sounds like you want to remove this line in any case, so I'll wait > for updated patches. Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v2 0/2] Add pcibios_device_change_notifier
On Tue, Jun 5, 2012 at 11:26 PM, Benjamin Herrenschmidt wrote: > On Wed, 2012-05-23 at 11:33 +0900, Hiroo Matsumoto wrote: >> This patchset is for PCI hotplug. >> >> >> pcibios_setup_bus_devices which sets DMA and IRQs of PCI device is called >> only when boot. DMA setting in probe for PCI driver, like dma_set_mask, >> does not work on powerpc platform. So it is need to set DMA and IRQs of >> PCI device when hotplug. >> >> 1. Moving pcibios_setup_bus_devices code to pcibios_device_change_notifier >> which is registered to bus notifier in pcibios_init. >> 2. Removing caller and callee of pcibios_setup_bus_devices bus notifier >> works instead of pcibios_setup_bus_devices. >> 3. Using this bus notifier for microblaze because microblaze/PCI is similer >> with powerpc/PCI. > > This makes me a bit nervous (that doesn't mean it's not right, but > we need some careful auditing & testing here, which I won't be > able to do until I'm back from leave). Mostly due to the change in when > we do the work. > > pcibios_fixup_bus() used to be called early on in the initial scan pass. > > Your code causes the code to be called -much- later when registering the > device with the device model. Are we 100% certain nothing will happen in > between that might rely on the stuff being setup already ? It might well > be ok, but I want us to triple check that. Here's my theory on this: we're setting up DMA and IRQ stuff. DMA and IRQ usage is device-specific, so the core can't do anything with them. Only drivers know how to use them. Drivers can't find the device until it's registered with the device model. So it seems like it should be safe to move it later. Subject to thinkos and testing in the real world, of course :) > Now, if we are ok to do the setup that late (basically right before the > driver probe() routine gets called), would it make sense to simplify > things even further ... and do it from pcibios_enable_device() ? Thus > avoiding the notifier business completely or is that pushing it too > far ? Kenji-san actually suggested using pcibios_enable_device() early on, and I'm the one who suggested the notifiers instead. I think I suggested that because I was copying the amd_iommu_init_notifier() style. But I now think that might have been a mistake. Notifiers are definitely more complicated, and a pcibios_*() hook seems straightforward. It could be in pcibios_enable_device(), though we only need it to be called once, and the enable_device() path may be called many times, e.g., every time a driver claims it. My new vote is a pcibios_device_add(), with an empty weak definition in drivers/pci, and a non-empty definition for microblaze and powerpc. > Also you seem to add: > > + /* Setup OF node pointer in the device */ > + dev->dev.of_node = pci_device_to_OF_node(dev); > > This shouldn't be needed anymore, the device node should be setup by the > core nowadays. Is this just a remnant of you rebasing an old patch or do > you have a good reason to add this statement ? It sounds like you want to remove this line in any case, so I'll wait for updated patches. Bjorn ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: PowerMac PMU programming
On Sun, 2012-06-10 at 23:31 -0400, Justin Hibbits wrote: > I'll settle on just getting the CPU speed change working, losing 333MHz > on my TiBook is a few too many MHz for the poor thing to lose :) I do > have a desktop, but that's my development platform, so needs to be > at least somewhat stable, so my TiBook is my guinea pig. > > I've googled everything I can think of, but do you know of any > definitive PMU documentation? Or can you give me any hints on what's > needed just for that simple operation? No doco no, Darwin and Linux source code are your best bet. It works like sleep as in: you send the switch command and the PMU will reboot the processor with the new frequency whenever the processor enters NAP mode. This is tricky because there's a loss of cache coherency vs. ongoing DMAs, hence tricky bits of code in there to deal with the various caches. > I noticed that you wind down the ADB queue before killing the PMU. Is > this necessary? I only disable the interrupt by writing 0x10 to the > IER, but our interrupt model for the PMU is different from the Linux > one. Well that will not disable CB1 (or the external GPIO one). You need to make sure no other communication with the PMU takes place once you've sent the sleep command and until you're back. > Is it also necessary to disable the interrupt input, even though > the register write should be disabling the PMU's asserting of the > line? There doesn't seem to be much more different than that, and > setting the openpic priority, Linux sets it to 0x0f but I didn't see > anything in OS X doing that (might that be a problem, too?) > > I would love to get my TiBook using the full 1GHz. I don't remember what openpic does in Darwin, I think interrupts are all masked there as a side effect of the code in KeyLargo.cpp but I'm not sure that applies to frequency changes. Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [Doubt] PPC Linux Device Tree Update
On 06/11/2012 02:52 AM, Kay One wrote: > Hi All, > > Currently I am working on p1020rdb soc for some kernel bringing up activity. > I have come across one requirement to update the memory map (MMAP) of > kernel from evaluation board to > some other board who is having the same soc. > > for my eval board I have used the p1020rdb.dts file from 2.6.38 standard > kernel source. Why not start with the latest version? > (PFA) which is working almost fine. > But, I am really not able to find the following mapping as a part of the > attached dts file what I am using. > Can anyone please point me out that dts file is the only one to search > out following base addresses selected in memory map or is there > some specific file of kernel inside which I will be able to search > through to find the following base addresses? > > _F000 4 KB.bootpg This is not expressed in the device tree, though it is marked reserved by U-Boot in the reserve map (part of the dtb, but not part of the actual tree). > FFE0_ 1 MBCCSR That's the "soc" node. > EC00_ 64 MB Flash + alias /localbus@ffe05000/nor@0,0/ ...but it's at 0xef00_ according to the tree you attached. Read the ePAPR spec for a description of how the ranges property works. > 8000_ 1 GBPCI[1:2] mem > FFC0_ 256 KB PCI[1:2] I/O These are encoded in the ranges property of the relevant PCIe node (see version 1.0 of the ePAPR spec for how), but I don't see one with those specific addresses. I don't know what the [1:2] is supposed to mean. > FFB0_ 1 MBVTSS /localbus@ffe05000/L2switch@2,0/ > FFA0_ 1 MBCPLD Not represented in the device tree. The device tree shows NAND at this address. > FF80_ 1 MBNAND /localbus@ffe05000/nand@1,0/ ...but with a different address, as noted above. > _ 1 GBDDR /memory U-Boot fills in the reg property. -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
reserving memory using OF rsvmap feature?
Is it possible to reserve some memory using OF rsvmap such that Linux will not touch this area at all? Think of is as warm start stash area were one could store data which should survive a reboot. One could then create an uio driver which exports this memory to user space I hope. Jocke ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Q: a_ops->readpage() && struct file
On 06/11, Oleg Nesterov wrote: > > Note also that we should move this !UPROBE_COPY_INSN from > install_breakpoint() to somewhere near alloc_uprobe(). The main problem is, uprobe_register() doesn't have struct file for read_mapping_page(). Stupid question. I'm afraid the answer is "no" but I'll ask anyway. Is it safe to pass filp == NULL to mapping->readpage()? In fact I do not understand why it needs "struct file*" and I do not see any example of actual usage. Yes, I didn't try to grep very much and I understand that the filesystem can do something special. Say it can use file->private_data... However. There is read_cache_page_gfp() which does use a_ops->readpage(filp => NULL), and the comment says nothing about the riskiness. If not, is there any other way uprobe_register(struct inode *inode, loff_t offset) can read the page at this offset? And btw, read_mapping_page() accepts "void *data". Why? it uses filler == a_ops->readpage, it shouldn't accept anything but file pointer? Please help, I know nothing about vfs. Oleg. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v2 1/2] uprobes: Pass probed vaddr to arch_uprobe_analyze_insn()
Ananth, Srikar, I think the patch is correct and I am sorry for nit-picking, this is really minor. But, On 06/08, Ananth N Mavinakayanahalli wrote: > > Changes in V2: > Pass (unsigned long)addr Well, IMHO, this is confusing. First of all, why do we have this "addr" or even "vaddr"? It should not exists. We pass it to copy_insn(), but for what?? copy_insn() should simply use uprobe->offset, the virtual address for this particular mapping does not matter at all. I am going to send the cleanup. Note also that we should move this !UPROBE_COPY_INSN from install_breakpoint() to somewhere near alloc_uprobe(). This code is called only once, it looks a bit strange to use the "random" mm (the first mm vma_prio_tree_foreach() finds) and its mapping to verify the insn. In fact this is simply not correct and should be fixed, note that on x86 arch_uprobe_analyze_insn() checks mm->context.ia32_compat. IOW, Perhaps uprobe->offset makes more sense? > --- linux-3.5-rc1.orig/kernel/events/uprobes.c > +++ linux-3.5-rc1/kernel/events/uprobes.c > @@ -697,7 +697,7 @@ install_breakpoint(struct uprobe *uprobe > if (is_swbp_insn((uprobe_opcode_t *)uprobe->arch.insn)) > return -EEXIST; > > - ret = arch_uprobe_analyze_insn(&uprobe->arch, mm); > + ret = arch_uprobe_analyze_insn(&uprobe->arch, mm, addr); Just fyi, this conflicts with "[PATCH 1/3] uprobes: install_breakpoint() should fail if is_swbp_insn() == T" I sent, but the conflict is trivial. Oleg. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Question about MPIC_SINGLE_DEST_CPU on P1020 (e500 core) SMP
On 06/10/2012 03:37 PM, Gopalakrishnan Raman wrote: > Hi > > The P1020 manual states (in the PIC chapter) that in the “Internal > Interrupt Destination” register, only 1 CPU (and not both) can be > selected as the IRQ destination. Right. > How then can we achieve “interrupt > spraying” for the PCI interrupt (we want interrupts to be sent > alternately to CPU0 and CPU1). You'll have to implement it in software by changing the destination each time (and be careful to follow the documented sequence for making such changes). Why do you want to do this? Won't it cause a bunch of cache misses as the IRQ-relevant data structures bounce between CPUs? Distributing different devices' interrupts among multiple CPUs is probably good for load balancing, but distributing a single device's interrupts may not be so good. > Also, we changed the code to ignore the > MPIC_SINGLE_DEST_CPU flag and set both CPUs in the destination of the > PIC_IIDRn register. This does seem to work. What specifically does it seem to do? > But we’re not sure if we can > rely on this behavior and whether it will cause other problems. You cannot rely on this. It is not a supported configuration. -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 0/6] Description for PCI patches using platform driver
On 06/10/2012 09:33 PM, Jia Hongtao-B38951 wrote: >> -Original Message- >> From: Bhushan Bharat-R65777 >> Sent: Friday, June 08, 2012 6:47 PM >> To: Jia Hongtao-B38951; linuxppc-dev@lists.ozlabs.org; >> ga...@kernel.crashing.org >> Cc: Li Yang-R58472; b...@kernel.crashing.org; Wood Scott-B07421 >> Subject: RE: [PATCH 0/6] Description for PCI patches using platform >> driver >> >> >>> -Original Message- >>> From: Jia Hongtao-B38951 >>> Sent: Friday, June 08, 2012 3:12 PM >>> To: linuxppc-dev@lists.ozlabs.org; ga...@kernel.crashing.org >>> Cc: Li Yang-R58472; b...@kernel.crashing.org; Wood Scott-B07421; >> Bhushan Bharat- >>> R65777; Jia Hongtao-B38951 >>> Subject: [PATCH 0/6] Description for PCI patches using platform driver >>> >>> This series of patches are to unify pci initialization code and add PM >> support >>> for all 85xx/86xx powerpc boards. But two side effects are introduced >> by this >>> mechanism which listed below: >>> >>> 1. of_platform_bus_probe() will be called twice but in some cases >> duplication >>>warning occured. We fix this in [PATCH 5/6]. >>> >>> 2. Edac driver failed to register pci nodes as platform devices. We fix >> this >>>in [PATCH 6/6]. >> >> With these patches will not the SWIOTLB will not be initialized even if >> PCI/PCIe demanded? >> >> Thanks >> -Bharat >> > > These patches still have the swiotlb init problem if "ppc_swiotlb_enable" is > only demanded by PCI/PCIe. One of the purposes of sending out these patches > is to let us start a discussion for this problem in upstream. When sending out a patchset like that, label it as [RFC PATCH] (request for comments), and mention all known problems to be resolved. -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: P2010 External HW IRQ number?
On 06/09/2012 04:00 AM, Joakim Tjernlund wrote: > > > Scott Wood wrote on 2012/06/08 21:23:50: > >> From: Scott Wood >> To: Joakim Tjernlund , >> Cc: >> Date: 2012/06/08 21:25 >> Subject: Re: P2010 External HW IRQ number? >> >> On 06/08/2012 06:06 AM, Joakim Tjernlund wrote: >>> >>> I have been trying to figure out what irq number to use for external IRQs >>> for >>> the P2010. There are no HW IRQ numbers in the ref manual and I cannot find >>> any examples in the kernel either. >>> How do specify irq numbers in my dts for external IRQs? >> >> See Documentation/devicetree/bindings/powerpc/fsl/mpic.txt > > Ahh, now I see. however I must say that I didn't until I read this older > version first: > > http://os1a.cs.columbia.edu/lxr/source/Documentation/powerpc/dts-bindings/fsl/mpic.txt?a=x86;v=2.6.34 Yeah, while the information is there in the new version, it's should be more prominent and detailed for something that causes so much confusion. -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH 0/6] Description for PCI patches using platform driver
> -Original Message-
> From: Jia Hongtao-B38951
> Sent: Monday, June 11, 2012 8:03 AM
> To: Bhushan Bharat-R65777; linuxppc-dev@lists.ozlabs.org;
> ga...@kernel.crashing.org
> Cc: Li Yang-R58472; b...@kernel.crashing.org; Wood Scott-B07421
> Subject: RE: [PATCH 0/6] Description for PCI patches using platform driver
>
> > -Original Message-
> > From: Bhushan Bharat-R65777
> > Sent: Friday, June 08, 2012 6:47 PM
> > To: Jia Hongtao-B38951; linuxppc-dev@lists.ozlabs.org;
> > ga...@kernel.crashing.org
> > Cc: Li Yang-R58472; b...@kernel.crashing.org; Wood Scott-B07421
> > Subject: RE: [PATCH 0/6] Description for PCI patches using platform
> > driver
> >
> >
> > > -Original Message-
> > > From: Jia Hongtao-B38951
> > > Sent: Friday, June 08, 2012 3:12 PM
> > > To: linuxppc-dev@lists.ozlabs.org; ga...@kernel.crashing.org
> > > Cc: Li Yang-R58472; b...@kernel.crashing.org; Wood Scott-B07421;
> > Bhushan Bharat-
> > > R65777; Jia Hongtao-B38951
> > > Subject: [PATCH 0/6] Description for PCI patches using platform
> > > driver
> > >
> > > This series of patches are to unify pci initialization code and add
> > > PM
> > support
> > > for all 85xx/86xx powerpc boards. But two side effects are
> > > introduced
> > by this
> > > mechanism which listed below:
> > >
> > > 1. of_platform_bus_probe() will be called twice but in some cases
> > duplication
> > >warning occured. We fix this in [PATCH 5/6].
> > >
> > > 2. Edac driver failed to register pci nodes as platform devices. We
> > > fix
> > this
> > >in [PATCH 6/6].
> >
> > With these patches will not the SWIOTLB will not be initialized even
> > if PCI/PCIe demanded?
> >
> > Thanks
> > -Bharat
> >
>
> These patches still have the swiotlb init problem if "ppc_swiotlb_enable" is
> only demanded by PCI/PCIe. One of the purposes of sending out these patches is
> to let us start a discussion for this problem in upstream.
Ok, I did not find any mention of that, so I thought that you have resolved the
issue by some means in these patches which I did not catch.
So, these patches introduces the issue, that SWIOTLB will not be initialized if
requested by pci/pcie. The request is raised by setting the flag
ppc_swiotlb_enable. The swiotlb_init() will be called in mem_init() if
ppc_swiotlb_enable is set. Now with these patches, the request is raised after
mem_init() is called. So request not handled :).
Following are the solutions we have thought of during our internal discussions
(if I did not missed any):
1. These patches move the code from platform init to device init
(arch_initcall()). Rather than moving the whole code, let us divide the code
into two. First, which is needed to raise the swiotlb init request and second
the rest. Define this first as an function in arch/powerpc/sysdev/fsl_pci.c and
call this from platform init code of the SOCs.
2. All known devices, the lowest PCIe outbound range starts at 0x8000, but
there's nothing above 0xc000. So the inbound of size 0x8000_ is always
availbe on all devices. Hardcode the check in platform code to check
memblock_end_of_DRAM() to 0x8000.
Something like this:
diff --git a/arch/powerpc/platforms/85xx/corenet_ds.c
b/arch/powerpc/platforms/85xx/corenet_ds.c
index 1f7028e..ef4e215 100644
--- a/arch/powerpc/platforms/85xx/corenet_ds.c
+++ b/arch/powerpc/platforms/85xx/corenet_ds.c
@@ -79,7 +79,7 @@ void __init corenet_ds_setup_arch(void) #endif
#ifdef CONFIG_SWIOTLB
- if (memblock_end_of_DRAM() > 0x)
+ if (memblock_end_of_DRAM() > 0xff00)
ppc_swiotlb_enable = 1; #endif
pr_info("%s board from Freescale Semiconductor\n", ppc_md.name);
-
3. Always do swiotlb_init() in mem_init() and later after PCI init, if the
swiotlb is not needed then free it (swiotlb_free()).
4. etc, please provide some other better way.
Thanks
-Bharat
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[Doubt] PPC Linux Device Tree Update
Hi All, Currently I am working on p1020rdb soc for some kernel bringing up activity. I have come across one requirement to update the memory map (MMAP) of kernel from evaluation board to some other board who is having the same soc. for my eval board I have used the p1020rdb.dts file from 2.6.38 standard kernel source. (PFA) which is working almost fine. But, I am really not able to find the following mapping as a part of the attached dts file what I am using. Can anyone please point me out that dts file is the only one to search out following base addresses selected in memory map or is there some specific file of kernel inside which I will be able to search through to find the following base addresses? _F000 4 KB .bootpg FFE0_ 1 MB CCSR EC00_ 64 MB Flash + alias 8000_ 1 GB PCI[1:2] mem FFC0_ 256 KB PCI[1:2] I/O FFB0_ 1 MB VTSS FFA0_ 1 MB CPLD FF80_ 1 MB NAND _ 1 GB DDR So that I can update that address with the newly address given by the vendor of new board on which I am porting the ppc kernel. Any help appreciated, Karnik jain p1020rdb.dts.dts Description: Binary data ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: Question about MPIC_SINGLE_DEST_CPU on P1020 (e500 core) SMP
> Subject: Question about MPIC_SINGLE_DEST_CPU on P1020 (e500 core) SMP > > Hi > The P1020 manual states (in the PIC chapter) that in the "Internal > Interrupt Destination" register, only 1 CPU (and not both) can be > selected as the IRQ destination. How then can we achieve "interrupt > spraying" for the PCI interrupt (we want interrupts to be sent > alternately to CPU0 and CPU1). Also, we changed the code to ignore the > MPIC_SINGLE_DEST_CPU flag and set both CPUs in the destination of the > PIC_IIDRn register. This does seem to work. But we're not sure if we can > rely on this behavior and whether it will cause other problems. I suggest you to follow the UM. The note should be there for a reason although personally I don't know what the specific problem will be. Leo ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
