* Re: [PATCH v5 1/1] powerpc/embedded6xx: Add support for Motorola/Emerson MVME5100
From: Scott Wood @ 2014-01-07 23:51 UTC (permalink / raw)
To: Stephen Chivers; +Cc: linuxppc-dev
In-Reply-To: <20140106012306.A6AB5E06BF@canberra.localdomain>
On Mon, 2014-01-06 at 12:23 +1100, Stephen Chivers wrote:
> Add support for the Motorola/Emerson MVME5100 Single Board Computer.
>
> The MVME5100 is a 6U form factor VME64 computer with:
>
> - A single MPC7410 or MPC750 CPU
> - A HAWK Processor Host Bridge (CPU to PCI) and
> MultiProcessor Interrupt Controller (MPIC)
> - Up to 500Mb of onboard memory
> - A M48T37 Real Time Clock (RTC) and Non-Volatile Memory chip
> - Two 16550 compatible UARTS
> - Two Intel E100 Fast Ethernets
> - Two PCI Mezzanine Card (PMC) Slots
> - PPCBug Firmware
>
> The HAWK PHB/MPIC is compatible with the MPC10x devices.
>
> There is no onboard disk support. This is usually provided by installing a PMC
> in first PMC slot.
>
> This patch revives the board support, it was present in early 2.6
> series kernels. The board support in those days was by Matt Porter of
> MontaVista Software.
>
> CSC Australia has around 31 of these boards in service. The kernel in use
> for the boards is based on 2.6.31. The boards are operated without disks
> from a file server.
>
> This patch is based on linux-3.13-rc2 and has been boot tested.
>
> Only boards with 512 Mb of memory are known to work.
>
> V1->V2:
> Address comments by Kumar Gala and Scott Wood.
> Minor adjustment to platforms/embedded6xx/Kconfig to ensure
> correct indentation where possible.
>
> V2->V3:
> Address comments by Scott Wood and Ben Herrenschmidt.
> Address errors reported by checkpatch.
>
> V3->V4:
> Address comment by Geert Uytterhoeven
> Add tested by Alessio Bogani.
>
> V4->V5:
> Correct horrible typo in patch history.
> Kular Gama is Kumar Gala.
The patch history should go below the --- line, as it's for reviewers
who have seen previous versions rather than for the git history.
-Scott
^ permalink raw reply
* Re: [v3, 3/7] powerpc: enable the relocatable support for the fsl booke 32bit kernel
From: Scott Wood @ 2014-01-07 23:46 UTC (permalink / raw)
To: Kevin Hao; +Cc: linuxppc
In-Reply-To: <20140104063452.GA11548@pek-khao-d1.corp.ad.wrs.com>
On Sat, 2014-01-04 at 14:34 +0800, Kevin Hao wrote:
> On Fri, Jan 03, 2014 at 06:49:09PM -0600, Scott Wood wrote:
> > On Fri, 2013-12-20 at 15:43 +0800, Kevin Hao wrote:
> > > On Wed, Dec 18, 2013 at 05:48:25PM -0600, Scott Wood wrote:
> > > > On Wed, Aug 07, 2013 at 09:18:31AM +0800, Kevin Hao wrote:
> > > > > This is based on the codes in the head_44x.S. The difference is that
> > > > > the init tlb size we used is 64M. With this patch we can only load the
> > > > > kernel at address between memstart_addr ~ memstart_addr + 64M. We will
> > > > > fix this restriction in the following patches.
> > > >
> > > > Which following patch fixes the restriction? With all seven patches
> > > > applied, I was still only successful booting within 64M of memstart_addr.
> > >
> > > There is bug in this patch series when booting above the 64M. It seems
> > > that I missed to test this previously. Sorry for that. With the following
> > > change I can boot the kernel at 0x5000000.
> >
> > I tried v4 and it still doesn't work for me over 64M (without increasing
> > the start of memory). I pulled the following out of the log buffer when
> > booting at 0x5000000 (after cleaning up the binary goo -- is that
> > something new?):
> >
> > Unable to handle kernel paging request for data at address 0xbffe4008
>
> Actually there still have one limitation that we have to make sure
> that the kernel and dtb are in the 64M memory mapped by the init tlb entry.
> I booted the kernel successfully by using the following u-boot commands:
> setenv fdt_high 0xffffffff
> dhcp 6000000 128.224.162.196:/vlm-boards/p5020/uImage
> tftp 6f00000 128.224.162.196:/vlm-boards/p5020/p5020ds.dtb
> bootm 6000000 - 6f00000
OK, that was it -- I hadn't set fdt_high and thus U-Boot was relocating
the fdt under 64M.
We should probably be using ioremap_prot() (or some other mechanism) to
create a special mapping, rather than assuming the fdt is covered by the
initial TLB entry. That doesn't need to happen as part of this
patchset, of course, as it's not a new limitation.
> > I'm having a hard time following the logic here. What is PAGE_OFFSET -
> > offset supposed to be? Why would we map anything belowe PAGE_OFFSET?
>
> No, we don't map the address below PAGE_OFFSET.
> memstart_addr is the physical start address of RAM.
> start is the kernel running physical address aligned with 64M.
>
> offset = memstart_addr - start
>
> So if memstart_addr < start, the offset is negative. The PAGE_OFFSET - offset
> is the virtual start address we should use for the init 64M map. It's above
> the PAGE_OFFSET instead of below.
Oh. I think it'd be more readable to do "offset = start -
memstart_addr" and add offset instead of subtracting it.
Also, offset should be phys_addr_t -- even if you don't expect to
support offsets greater than 4G on 32-bit, it's semantically the right
type to use. Plus, "int" would break if this code were ever used with
64-bit.
If you're OK with these changes, I can fix it while applying.
-Scott
^ permalink raw reply
* Re: [PATCH] powerpc/mpic: supply a .disable callback
From: Benjamin Herrenschmidt @ 2014-01-07 23:11 UTC (permalink / raw)
To: Dongsheng.Wang@freescale.com; +Cc: Scott Wood, linuxppc-dev@lists.ozlabs.org
In-Reply-To: <a889eb6414b44d418a34bc5e61fc538a@BN1PR03MB188.namprd03.prod.outlook.com>
On Tue, 2014-01-07 at 10:18 +0000, Dongsheng.Wang@freescale.com wrote:
>
> > -----Original Message-----
> > From: Benjamin Herrenschmidt [mailto:benh@kernel.crashing.org]
> > Sent: Tuesday, January 07, 2014 1:50 PM
> > To: Wang Dongsheng-B40534
> > Cc: Wood Scott-B07421; linuxppc-dev@lists.ozlabs.org
> > Subject: Re: [PATCH] powerpc/mpic: supply a .disable callback
> >
> > On Tue, 2014-01-07 at 13:38 +0800, Dongsheng Wang wrote:
> > > From: Wang Dongsheng <dongsheng.wang@freescale.com>
> > >
> > > Currently MPIC provides .mask, but not .disable. This means that
> > > effectively disable_irq() soft-disables the interrupt, and you get
> > > a .mask call if an interrupt actually occurs.
> > >
> > > I'm not sure if this was intended as a performance benefit (it seems common
> > > to omit .disable on powerpc interrupt controllers, but nowhere else), but it
> > > interacts badly with threaded/workqueue interrupts (including KVM
> > > reflection). In such cases, where the real interrupt handler does a
> > > disable_irq_nosync(), schedules defered handling, and returns, we get two
> > > interrupts for every real interrupt. The second interrupt does nothing
> > > but see that IRQ_DISABLED is set, and decide that it would be a good
> > > idea to actually call .mask.
> >
> > We probably don't want to do that for edge, only level interrupts.
> >
> Sorry Ben, I am not understand your comments.
>
> This issue is the kernel api irq_disable() only use chip->irq_disable(), but mpic
> not have this interface so we don't real disable the interrupt.
Yes, because we want to keep the existing behaviour of "lazy disable"
for edge interrupts. It's faster.
Cheers,
Ben.
> -Dongsheng
>
> > Cheers,
> > Ben.
> >
>
^ permalink raw reply
* Re: [PATCH] powerpc/mpic: supply a .disable callback
From: Scott Wood @ 2014-01-07 21:19 UTC (permalink / raw)
To: Wang Dongsheng-B40534; +Cc: linuxppc-dev@lists.ozlabs.org
In-Reply-To: <a889eb6414b44d418a34bc5e61fc538a@BN1PR03MB188.namprd03.prod.outlook.com>
On Tue, 2014-01-07 at 04:18 -0600, Wang Dongsheng-B40534 wrote:
>
> > -----Original Message-----
> > From: Benjamin Herrenschmidt [mailto:benh@kernel.crashing.org]
> > Sent: Tuesday, January 07, 2014 1:50 PM
> > To: Wang Dongsheng-B40534
> > Cc: Wood Scott-B07421; linuxppc-dev@lists.ozlabs.org
> > Subject: Re: [PATCH] powerpc/mpic: supply a .disable callback
> >
> > On Tue, 2014-01-07 at 13:38 +0800, Dongsheng Wang wrote:
> > > From: Wang Dongsheng <dongsheng.wang@freescale.com>
> > >
> > > Currently MPIC provides .mask, but not .disable. This means that
> > > effectively disable_irq() soft-disables the interrupt, and you get
> > > a .mask call if an interrupt actually occurs.
> > >
> > > I'm not sure if this was intended as a performance benefit (it seems common
> > > to omit .disable on powerpc interrupt controllers, but nowhere else), but it
> > > interacts badly with threaded/workqueue interrupts (including KVM
> > > reflection). In such cases, where the real interrupt handler does a
> > > disable_irq_nosync(), schedules defered handling, and returns, we get two
> > > interrupts for every real interrupt. The second interrupt does nothing
> > > but see that IRQ_DISABLED is set, and decide that it would be a good
> > > idea to actually call .mask.
> >
> > We probably don't want to do that for edge, only level interrupts.
> >
> Sorry Ben, I am not understand your comments.
>
> This issue is the kernel api irq_disable() only use chip->irq_disable(), but mpic
> not have this interface so we don't real disable the interrupt.
I think he means that the "two interrupts for every real interrupt"
effect will only happen with level triggered interrupts, and he'd like
to keep the potential performance benefit of lazy disabling for edge
interrupts.
To implement this for "ordinary" edge interrupts (not IPI, timer, etc)
we'd need to add a new .irq_disable() function that checks whether it's
level/edge and only calls .irq_mask() if level -- or, introduce a
separate struct irq_chip for edge versus level.
-Scott
^ permalink raw reply
* Re: [PATCH 2/2] powerpc/85xx: handle the eLBC error interrupt if it exist in dts
From: Scott Wood @ 2014-01-07 20:45 UTC (permalink / raw)
To: Wang Dongsheng-B40534; +Cc: linuxppc-dev@lists.ozlabs.org, Xie Shaohui-B21989
In-Reply-To: <1acd410af7444ba89e81dc004f2d6e89@BN1PR03MB188.namprd03.prod.outlook.com>
On Tue, 2014-01-07 at 04:01 -0600, Wang Dongsheng-B40534 wrote:
>
> > -----Original Message-----
> > From: Wood Scott-B07421
> > Sent: Tuesday, January 07, 2014 2:58 PM
> > To: Wang Dongsheng-B40534
> > Cc: linuxppc-dev@lists.ozlabs.org; Xie Shaohui-B21989; Kumar Gala
> > Subject: Re: [PATCH 2/2] powerpc/85xx: handle the eLBC error interrupt if it
> > exist in dts
> >
> > On Tue, 2014-01-07 at 14:27 +0800, Dongsheng Wang wrote:
> > > From: Wang Dongsheng <dongsheng.wang@freescale.com>
> >
> > AFAICT this patch was originally written by Shaohui Xie.
> >
> > > On P3041, P1020, P1021, P1022, P1023 eLBC event interrupts are routed
> > > to Int9(P3041) & Int3(P102x) while ELBC error interrupts are routed to
> > > Int0, we need to call request_irq for each.
> >
> > For p3041 I thought that was only on early silicon revs that we don't
> > support anymore.
> >
> > As for p102x, have you tested that this is actually what happens? How
> > would we distinguish eLBC errors from other error sources, given that
> > there's no EISR0? Do we just hope that no other error interrupts
> > happen?
> Yes, I tested. The interrupt is shard eLBC interrupt handler could check the error.
> This patch is fix "nobody cared" the error interrupt. After sleep resume the lbc
> will get a chip select error.
s/no other error interrupts happen/no other error interrupts for which
we don't have a handler registered or which don't even have an
associated status register happen/
-Scott
^ permalink raw reply
* Re: [PATCH 2/2] fsl/pci: The new pci suspend/resume implementation
From: Rafael J. Wysocki @ 2014-01-07 20:41 UTC (permalink / raw)
To: Dongsheng Wang
Cc: linux-pci, galak, scottwood, roy.zang, bhelgaas, linuxppc-dev
In-Reply-To: <1389081848-26506-2-git-send-email-dongsheng.wang@freescale.com>
On Tuesday, January 07, 2014 04:04:08 PM Dongsheng Wang wrote:
> From: Wang Dongsheng <dongsheng.wang@freescale.com>
>
> The new suspend/resume implementation, send pme turnoff message
> in suspend, and send pme exit message in resume.
>
> Add a PME handler, to response PME & message interrupt.
>
> Change platform_driver->suspend/resume to syscore->suspend/resume.
Can you please first describe the problem you're trying to address?
Thanks!
> pci-driver will call back EP device, to save EP state in
> pci_pm_suspend_noirq, so we need to keep the link, until
> pci_pm_suspend_noirq finish.
>
> Signed-off-by: Wang Dongsheng <dongsheng.wang@freescale.com>
>
> diff --git a/arch/powerpc/platforms/85xx/c293pcie.c b/arch/powerpc/platforms/85xx/c293pcie.c
> index 213d5b8..84476b6 100644
> --- a/arch/powerpc/platforms/85xx/c293pcie.c
> +++ b/arch/powerpc/platforms/85xx/c293pcie.c
> @@ -68,6 +68,7 @@ define_machine(c293_pcie) {
> .init_IRQ = c293_pcie_pic_init,
> #ifdef CONFIG_PCI
> .pcibios_fixup_bus = fsl_pcibios_fixup_bus,
> + .pcibios_fixup_phb = fsl_pcibios_fixup_phb,
> #endif
> .get_irq = mpic_get_irq,
> .restart = fsl_rstcr_restart,
> diff --git a/arch/powerpc/platforms/85xx/corenet_generic.c b/arch/powerpc/platforms/85xx/corenet_generic.c
> index fbd871e..aa8b9a3 100644
> --- a/arch/powerpc/platforms/85xx/corenet_generic.c
> +++ b/arch/powerpc/platforms/85xx/corenet_generic.c
> @@ -163,6 +163,7 @@ define_machine(corenet_generic) {
> .init_IRQ = corenet_gen_pic_init,
> #ifdef CONFIG_PCI
> .pcibios_fixup_bus = fsl_pcibios_fixup_bus,
> + .pcibios_fixup_phb = fsl_pcibios_fixup_phb,
> #endif
> .get_irq = mpic_get_coreint_irq,
> .restart = fsl_rstcr_restart,
> diff --git a/arch/powerpc/platforms/85xx/ge_imp3a.c b/arch/powerpc/platforms/85xx/ge_imp3a.c
> index e6285ae..11790e0 100644
> --- a/arch/powerpc/platforms/85xx/ge_imp3a.c
> +++ b/arch/powerpc/platforms/85xx/ge_imp3a.c
> @@ -215,6 +215,7 @@ define_machine(ge_imp3a) {
> .show_cpuinfo = ge_imp3a_show_cpuinfo,
> #ifdef CONFIG_PCI
> .pcibios_fixup_bus = fsl_pcibios_fixup_bus,
> + .pcibios_fixup_phb = fsl_pcibios_fixup_phb,
> #endif
> .get_irq = mpic_get_irq,
> .restart = fsl_rstcr_restart,
> diff --git a/arch/powerpc/platforms/85xx/mpc8536_ds.c b/arch/powerpc/platforms/85xx/mpc8536_ds.c
> index 15ce4b5..a378ba3 100644
> --- a/arch/powerpc/platforms/85xx/mpc8536_ds.c
> +++ b/arch/powerpc/platforms/85xx/mpc8536_ds.c
> @@ -76,6 +76,7 @@ define_machine(mpc8536_ds) {
> .init_IRQ = mpc8536_ds_pic_init,
> #ifdef CONFIG_PCI
> .pcibios_fixup_bus = fsl_pcibios_fixup_bus,
> + .pcibios_fixup_phb = fsl_pcibios_fixup_phb,
> #endif
> .get_irq = mpic_get_irq,
> .restart = fsl_rstcr_restart,
> diff --git a/arch/powerpc/platforms/85xx/mpc85xx_cds.c b/arch/powerpc/platforms/85xx/mpc85xx_cds.c
> index 7a31a0e..b0753e2 100644
> --- a/arch/powerpc/platforms/85xx/mpc85xx_cds.c
> +++ b/arch/powerpc/platforms/85xx/mpc85xx_cds.c
> @@ -385,6 +385,7 @@ define_machine(mpc85xx_cds) {
> #ifdef CONFIG_PCI
> .restart = mpc85xx_cds_restart,
> .pcibios_fixup_bus = mpc85xx_cds_fixup_bus,
> + .pcibios_fixup_phb = fsl_pcibios_fixup_phb,
> #else
> .restart = fsl_rstcr_restart,
> #endif
> diff --git a/arch/powerpc/platforms/85xx/mpc85xx_ds.c b/arch/powerpc/platforms/85xx/mpc85xx_ds.c
> index 9ebb91e..ffdf021 100644
> --- a/arch/powerpc/platforms/85xx/mpc85xx_ds.c
> +++ b/arch/powerpc/platforms/85xx/mpc85xx_ds.c
> @@ -209,6 +209,7 @@ define_machine(mpc8544_ds) {
> .init_IRQ = mpc85xx_ds_pic_init,
> #ifdef CONFIG_PCI
> .pcibios_fixup_bus = fsl_pcibios_fixup_bus,
> + .pcibios_fixup_phb = fsl_pcibios_fixup_phb,
> #endif
> .get_irq = mpic_get_irq,
> .restart = fsl_rstcr_restart,
> @@ -223,6 +224,7 @@ define_machine(mpc8572_ds) {
> .init_IRQ = mpc85xx_ds_pic_init,
> #ifdef CONFIG_PCI
> .pcibios_fixup_bus = fsl_pcibios_fixup_bus,
> + .pcibios_fixup_phb = fsl_pcibios_fixup_phb,
> #endif
> .get_irq = mpic_get_irq,
> .restart = fsl_rstcr_restart,
> @@ -237,6 +239,7 @@ define_machine(p2020_ds) {
> .init_IRQ = mpc85xx_ds_pic_init,
> #ifdef CONFIG_PCI
> .pcibios_fixup_bus = fsl_pcibios_fixup_bus,
> + .pcibios_fixup_phb = fsl_pcibios_fixup_phb,
> #endif
> .get_irq = mpic_get_irq,
> .restart = fsl_rstcr_restart,
> diff --git a/arch/powerpc/platforms/85xx/mpc85xx_mds.c b/arch/powerpc/platforms/85xx/mpc85xx_mds.c
> index a7b3621..6cd3b8a 100644
> --- a/arch/powerpc/platforms/85xx/mpc85xx_mds.c
> +++ b/arch/powerpc/platforms/85xx/mpc85xx_mds.c
> @@ -416,6 +416,7 @@ define_machine(mpc8568_mds) {
> .progress = udbg_progress,
> #ifdef CONFIG_PCI
> .pcibios_fixup_bus = fsl_pcibios_fixup_bus,
> + .pcibios_fixup_phb = fsl_pcibios_fixup_phb,
> #endif
> };
>
> @@ -437,6 +438,7 @@ define_machine(mpc8569_mds) {
> .progress = udbg_progress,
> #ifdef CONFIG_PCI
> .pcibios_fixup_bus = fsl_pcibios_fixup_bus,
> + .pcibios_fixup_phb = fsl_pcibios_fixup_phb,
> #endif
> };
>
> @@ -459,6 +461,7 @@ define_machine(p1021_mds) {
> .progress = udbg_progress,
> #ifdef CONFIG_PCI
> .pcibios_fixup_bus = fsl_pcibios_fixup_bus,
> + .pcibios_fixup_phb = fsl_pcibios_fixup_phb,
> #endif
> };
>
> diff --git a/arch/powerpc/platforms/85xx/mpc85xx_rdb.c b/arch/powerpc/platforms/85xx/mpc85xx_rdb.c
> index 53b6fb0..3e2bc3d 100644
> --- a/arch/powerpc/platforms/85xx/mpc85xx_rdb.c
> +++ b/arch/powerpc/platforms/85xx/mpc85xx_rdb.c
> @@ -254,6 +254,7 @@ define_machine(p2020_rdb) {
> .init_IRQ = mpc85xx_rdb_pic_init,
> #ifdef CONFIG_PCI
> .pcibios_fixup_bus = fsl_pcibios_fixup_bus,
> + .pcibios_fixup_phb = fsl_pcibios_fixup_phb,
> #endif
> .get_irq = mpic_get_irq,
> .restart = fsl_rstcr_restart,
> @@ -268,6 +269,7 @@ define_machine(p1020_rdb) {
> .init_IRQ = mpc85xx_rdb_pic_init,
> #ifdef CONFIG_PCI
> .pcibios_fixup_bus = fsl_pcibios_fixup_bus,
> + .pcibios_fixup_phb = fsl_pcibios_fixup_phb,
> #endif
> .get_irq = mpic_get_irq,
> .restart = fsl_rstcr_restart,
> @@ -282,6 +284,7 @@ define_machine(p1021_rdb_pc) {
> .init_IRQ = mpc85xx_rdb_pic_init,
> #ifdef CONFIG_PCI
> .pcibios_fixup_bus = fsl_pcibios_fixup_bus,
> + .pcibios_fixup_phb = fsl_pcibios_fixup_phb,
> #endif
> .get_irq = mpic_get_irq,
> .restart = fsl_rstcr_restart,
> @@ -296,6 +299,7 @@ define_machine(p2020_rdb_pc) {
> .init_IRQ = mpc85xx_rdb_pic_init,
> #ifdef CONFIG_PCI
> .pcibios_fixup_bus = fsl_pcibios_fixup_bus,
> + .pcibios_fixup_phb = fsl_pcibios_fixup_phb,
> #endif
> .get_irq = mpic_get_irq,
> .restart = fsl_rstcr_restart,
> @@ -310,6 +314,7 @@ define_machine(p1025_rdb) {
> .init_IRQ = mpc85xx_rdb_pic_init,
> #ifdef CONFIG_PCI
> .pcibios_fixup_bus = fsl_pcibios_fixup_bus,
> + .pcibios_fixup_phb = fsl_pcibios_fixup_phb,
> #endif
> .get_irq = mpic_get_irq,
> .restart = fsl_rstcr_restart,
> @@ -324,6 +329,7 @@ define_machine(p1020_mbg_pc) {
> .init_IRQ = mpc85xx_rdb_pic_init,
> #ifdef CONFIG_PCI
> .pcibios_fixup_bus = fsl_pcibios_fixup_bus,
> + .pcibios_fixup_phb = fsl_pcibios_fixup_phb,
> #endif
> .get_irq = mpic_get_irq,
> .restart = fsl_rstcr_restart,
> @@ -338,6 +344,7 @@ define_machine(p1020_utm_pc) {
> .init_IRQ = mpc85xx_rdb_pic_init,
> #ifdef CONFIG_PCI
> .pcibios_fixup_bus = fsl_pcibios_fixup_bus,
> + .pcibios_fixup_phb = fsl_pcibios_fixup_phb,
> #endif
> .get_irq = mpic_get_irq,
> .restart = fsl_rstcr_restart,
> @@ -352,6 +359,7 @@ define_machine(p1020_rdb_pc) {
> .init_IRQ = mpc85xx_rdb_pic_init,
> #ifdef CONFIG_PCI
> .pcibios_fixup_bus = fsl_pcibios_fixup_bus,
> + .pcibios_fixup_phb = fsl_pcibios_fixup_phb,
> #endif
> .get_irq = mpic_get_irq,
> .restart = fsl_rstcr_restart,
> @@ -366,6 +374,7 @@ define_machine(p1020_rdb_pd) {
> .init_IRQ = mpc85xx_rdb_pic_init,
> #ifdef CONFIG_PCI
> .pcibios_fixup_bus = fsl_pcibios_fixup_bus,
> + .pcibios_fixup_phb = fsl_pcibios_fixup_phb,
> #endif
> .get_irq = mpic_get_irq,
> .restart = fsl_rstcr_restart,
> @@ -380,6 +389,7 @@ define_machine(p1024_rdb) {
> .init_IRQ = mpc85xx_rdb_pic_init,
> #ifdef CONFIG_PCI
> .pcibios_fixup_bus = fsl_pcibios_fixup_bus,
> + .pcibios_fixup_phb = fsl_pcibios_fixup_phb,
> #endif
> .get_irq = mpic_get_irq,
> .restart = fsl_rstcr_restart,
> diff --git a/arch/powerpc/platforms/85xx/p1010rdb.c b/arch/powerpc/platforms/85xx/p1010rdb.c
> index d6a3dd3..ad1a3d4 100644
> --- a/arch/powerpc/platforms/85xx/p1010rdb.c
> +++ b/arch/powerpc/platforms/85xx/p1010rdb.c
> @@ -78,6 +78,7 @@ define_machine(p1010_rdb) {
> .init_IRQ = p1010_rdb_pic_init,
> #ifdef CONFIG_PCI
> .pcibios_fixup_bus = fsl_pcibios_fixup_bus,
> + .pcibios_fixup_phb = fsl_pcibios_fixup_phb,
> #endif
> .get_irq = mpic_get_irq,
> .restart = fsl_rstcr_restart,
> diff --git a/arch/powerpc/platforms/85xx/p1022_ds.c b/arch/powerpc/platforms/85xx/p1022_ds.c
> index e611e79..6ac986d 100644
> --- a/arch/powerpc/platforms/85xx/p1022_ds.c
> +++ b/arch/powerpc/platforms/85xx/p1022_ds.c
> @@ -567,6 +567,7 @@ define_machine(p1022_ds) {
> .init_IRQ = p1022_ds_pic_init,
> #ifdef CONFIG_PCI
> .pcibios_fixup_bus = fsl_pcibios_fixup_bus,
> + .pcibios_fixup_phb = fsl_pcibios_fixup_phb,
> #endif
> .get_irq = mpic_get_irq,
> .restart = fsl_rstcr_restart,
> diff --git a/arch/powerpc/platforms/85xx/p1022_rdk.c b/arch/powerpc/platforms/85xx/p1022_rdk.c
> index 8c92971..7a180f0 100644
> --- a/arch/powerpc/platforms/85xx/p1022_rdk.c
> +++ b/arch/powerpc/platforms/85xx/p1022_rdk.c
> @@ -147,6 +147,7 @@ define_machine(p1022_rdk) {
> .init_IRQ = p1022_rdk_pic_init,
> #ifdef CONFIG_PCI
> .pcibios_fixup_bus = fsl_pcibios_fixup_bus,
> + .pcibios_fixup_phb = fsl_pcibios_fixup_phb,
> #endif
> .get_irq = mpic_get_irq,
> .restart = fsl_rstcr_restart,
> diff --git a/arch/powerpc/platforms/85xx/p1023_rds.c b/arch/powerpc/platforms/85xx/p1023_rds.c
> index 2ae9d49..0e61400 100644
> --- a/arch/powerpc/platforms/85xx/p1023_rds.c
> +++ b/arch/powerpc/platforms/85xx/p1023_rds.c
> @@ -126,6 +126,7 @@ define_machine(p1023_rds) {
> .progress = udbg_progress,
> #ifdef CONFIG_PCI
> .pcibios_fixup_bus = fsl_pcibios_fixup_bus,
> + .pcibios_fixup_phb = fsl_pcibios_fixup_phb,
> #endif
> };
>
> @@ -140,5 +141,6 @@ define_machine(p1023_rdb) {
> .progress = udbg_progress,
> #ifdef CONFIG_PCI
> .pcibios_fixup_bus = fsl_pcibios_fixup_bus,
> + .pcibios_fixup_phb = fsl_pcibios_fixup_phb,
> #endif
> };
> diff --git a/arch/powerpc/platforms/85xx/qemu_e500.c b/arch/powerpc/platforms/85xx/qemu_e500.c
> index 5cefc5a..7f26732 100644
> --- a/arch/powerpc/platforms/85xx/qemu_e500.c
> +++ b/arch/powerpc/platforms/85xx/qemu_e500.c
> @@ -66,6 +66,7 @@ define_machine(qemu_e500) {
> .init_IRQ = qemu_e500_pic_init,
> #ifdef CONFIG_PCI
> .pcibios_fixup_bus = fsl_pcibios_fixup_bus,
> + .pcibios_fixup_phb = fsl_pcibios_fixup_phb,
> #endif
> .get_irq = mpic_get_coreint_irq,
> .restart = fsl_rstcr_restart,
> diff --git a/arch/powerpc/platforms/85xx/sbc8548.c b/arch/powerpc/platforms/85xx/sbc8548.c
> index f621218..b072146 100644
> --- a/arch/powerpc/platforms/85xx/sbc8548.c
> +++ b/arch/powerpc/platforms/85xx/sbc8548.c
> @@ -135,6 +135,7 @@ define_machine(sbc8548) {
> .restart = fsl_rstcr_restart,
> #ifdef CONFIG_PCI
> .pcibios_fixup_bus = fsl_pcibios_fixup_bus,
> + .pcibios_fixup_phb = fsl_pcibios_fixup_phb,
> #endif
> .calibrate_decr = generic_calibrate_decr,
> .progress = udbg_progress,
> diff --git a/arch/powerpc/platforms/85xx/xes_mpc85xx.c b/arch/powerpc/platforms/85xx/xes_mpc85xx.c
> index dcbf7e4..1a9c108 100644
> --- a/arch/powerpc/platforms/85xx/xes_mpc85xx.c
> +++ b/arch/powerpc/platforms/85xx/xes_mpc85xx.c
> @@ -170,6 +170,7 @@ define_machine(xes_mpc8572) {
> .init_IRQ = xes_mpc85xx_pic_init,
> #ifdef CONFIG_PCI
> .pcibios_fixup_bus = fsl_pcibios_fixup_bus,
> + .pcibios_fixup_phb = fsl_pcibios_fixup_phb,
> #endif
> .get_irq = mpic_get_irq,
> .restart = fsl_rstcr_restart,
> @@ -184,6 +185,7 @@ define_machine(xes_mpc8548) {
> .init_IRQ = xes_mpc85xx_pic_init,
> #ifdef CONFIG_PCI
> .pcibios_fixup_bus = fsl_pcibios_fixup_bus,
> + .pcibios_fixup_phb = fsl_pcibios_fixup_phb,
> #endif
> .get_irq = mpic_get_irq,
> .restart = fsl_rstcr_restart,
> @@ -198,6 +200,7 @@ define_machine(xes_mpc8540) {
> .init_IRQ = xes_mpc85xx_pic_init,
> #ifdef CONFIG_PCI
> .pcibios_fixup_bus = fsl_pcibios_fixup_bus,
> + .pcibios_fixup_phb = fsl_pcibios_fixup_phb,
> #endif
> .get_irq = mpic_get_irq,
> .restart = fsl_rstcr_restart,
> diff --git a/arch/powerpc/sysdev/fsl_pci.c b/arch/powerpc/sysdev/fsl_pci.c
> index 4dfd61d..98cb3d4 100644
> --- a/arch/powerpc/sysdev/fsl_pci.c
> +++ b/arch/powerpc/sysdev/fsl_pci.c
> @@ -22,10 +22,13 @@
> #include <linux/delay.h>
> #include <linux/string.h>
> #include <linux/init.h>
> +#include <linux/interrupt.h>
> #include <linux/bootmem.h>
> #include <linux/memblock.h>
> #include <linux/log2.h>
> #include <linux/slab.h>
> +#include <linux/suspend.h>
> +#include <linux/syscore_ops.h>
> #include <linux/uaccess.h>
>
> #include <asm/io.h>
> @@ -1085,55 +1088,167 @@ void fsl_pci_assign_primary(void)
> }
> }
>
> -static int fsl_pci_probe(struct platform_device *pdev)
> +#ifdef CONFIG_PM
> +static irqreturn_t fsl_pci_pme_handle(int irq, void *dev_id)
> {
> - int ret;
> - struct device_node *node;
> + struct pci_controller *hose = dev_id;
> + struct ccsr_pci __iomem *pci = hose->private_data;
> + u32 dr;
>
> - node = pdev->dev.of_node;
> - ret = fsl_add_bridge(pdev, fsl_pci_primary == node);
> + dr = in_be32(&pci->pex_pme_mes_dr);
> + if (dr)
> + out_be32(&pci->pex_pme_mes_dr, dr);
> + else
> + return IRQ_NONE;
>
> - mpc85xx_pci_err_probe(pdev);
> + return IRQ_HANDLED;
> +}
> +
> +static int fsl_pci_pme_probe(struct pci_controller *hose)
> +{
> + struct ccsr_pci __iomem *pci;
> + struct pci_dev *dev = hose->bus->self;
> + u16 pms;
> + int pme_irq;
> + int res;
> +
> + /* PME Disable */
> + pci_read_config_word(dev, dev->pm_cap + PCI_PM_CTRL, &pms);
> + pms &= ~PCI_PM_CTRL_PME_ENABLE;
> + pci_write_config_word(dev, dev->pm_cap + PCI_PM_CTRL, pms);
> +
> + pme_irq = irq_of_parse_and_map(hose->dn, 0);
> + if (!pme_irq) {
> + pr_warn("Failed to map PME interrupt.\n");
> +
> + return -ENXIO;
> + }
> +
> + res = devm_request_irq(hose->parent, pme_irq,
> + fsl_pci_pme_handle,
> + IRQF_DISABLED | IRQF_SHARED,
> + "[PCI] PME", hose);
> + if (res < 0) {
> + pr_warn("Unable to requiest irq %d for PME\n", pme_irq);
> + irq_dispose_mapping(pme_irq);
> +
> + return -ENODEV;
> + }
> +
> + pci = hose->private_data;
> +
> + /* Enable PTOD, ENL23D & EXL23D */
> + out_be32(&pci->pex_pme_mes_disr, 0);
> + setbits32(&pci->pex_pme_mes_disr,
> + PME_DISR_EN_PTOD | PME_DISR_EN_ENL23D | PME_DISR_EN_EXL23D);
> +
> + out_be32(&pci->pex_pme_mes_ier, 0);
> + setbits32(&pci->pex_pme_mes_ier,
> + PME_DISR_EN_PTOD | PME_DISR_EN_ENL23D | PME_DISR_EN_EXL23D);
> +
> + /* PME Enable */
> + pci_read_config_word(dev, dev->pm_cap + PCI_PM_CTRL, &pms);
> + pms |= PCI_PM_CTRL_PME_ENABLE;
> + pci_write_config_word(dev, dev->pm_cap + PCI_PM_CTRL, pms);
>
> return 0;
> }
>
> -#ifdef CONFIG_PM
> -static int fsl_pci_resume(struct device *dev)
> +static void send_pme_turnoff_message(struct pci_controller *hose)
> {
> - struct pci_controller *hose;
> - struct resource pci_rsrc;
> + struct ccsr_pci __iomem *pci = hose->private_data;
> + u32 dr;
> + int i;
>
> - hose = pci_find_hose_for_OF_device(dev->of_node);
> - if (!hose)
> - return -ENODEV;
> + /* Send PME_Turn_Off Message Request */
> + setbits32(&pci->pex_pmcr, PEX_PMCR_PTOMR);
>
> - if (of_address_to_resource(dev->of_node, 0, &pci_rsrc)) {
> - dev_err(dev, "Get pci register base failed.");
> - return -ENODEV;
> + for (i = 0; i < 150; i++) {
> + dr = in_be32(&pci->pex_pme_mes_dr);
> + if (dr) {
> + out_be32(&pci->pex_pme_mes_dr, dr);
> + break;
> + } else {
> + udelay(1000);
> + }
> }
> +}
>
> - setup_pci_atmu(hose);
> +static void fsl_pci_syscore_do_suspend(struct pci_controller *hose)
> +{
> + send_pme_turnoff_message(hose);
> +}
> +
> +static int fsl_pci_syscore_suspend(void)
> +{
> + struct pci_controller *hose, *tmp;
> +
> + list_for_each_entry_safe(hose, tmp, &hose_list, list_node)
> + fsl_pci_syscore_do_suspend(hose);
>
> return 0;
> }
>
> -static const struct dev_pm_ops pci_pm_ops = {
> - .resume = fsl_pci_resume,
> -};
> +static void fsl_pci_syscore_do_resume(struct pci_controller *hose)
> +{
> + struct ccsr_pci __iomem *pci = hose->private_data;
> + u32 dr;
> + int i;
>
> -#define PCI_PM_OPS (&pci_pm_ops)
> + /* Send Exit L2 State Message */
> + setbits32(&pci->pex_pmcr, PEX_PMCR_EXL2S);
>
> -#else
> + /* wait exit done */
> + for (i = 0; i < 150; i++) {
> + dr = in_be32(&pci->pex_pme_mes_dr);
> + if (dr) {
> + out_be32(&pci->pex_pme_mes_dr, dr);
> + break;
> + } else {
> + udelay(1000);
> + }
> + }
> +
> + setup_pci_atmu(hose);
> +}
>
> -#define PCI_PM_OPS NULL
> +static void fsl_pci_syscore_resume(void)
> +{
> + struct pci_controller *hose, *tmp;
> +
> + list_for_each_entry_safe(hose, tmp, &hose_list, list_node)
> + fsl_pci_syscore_do_resume(hose);
> +}
>
> +static struct syscore_ops pci_syscore_pm_ops = {
> + .suspend = fsl_pci_syscore_suspend,
> + .resume = fsl_pci_syscore_resume,
> +};
> #endif
>
> +void fsl_pcibios_fixup_phb(struct pci_controller *phb)
> +{
> +#ifdef CONFIG_PM
> + fsl_pci_pme_probe(phb);
> +#endif
> +}
> +
> +static int fsl_pci_probe(struct platform_device *pdev)
> +{
> + int ret;
> + struct device_node *node;
> +
> + node = pdev->dev.of_node;
> + ret = fsl_add_bridge(pdev, fsl_pci_primary == node);
> +
> + mpc85xx_pci_err_probe(pdev);
> +
> + return 0;
> +}
> +
> static struct platform_driver fsl_pci_driver = {
> .driver = {
> .name = "fsl-pci",
> - .pm = PCI_PM_OPS,
> .of_match_table = pci_ids,
> },
> .probe = fsl_pci_probe,
> @@ -1141,6 +1256,9 @@ static struct platform_driver fsl_pci_driver = {
>
> static int __init fsl_pci_init(void)
> {
> +#ifdef CONFIG_PM
> + register_syscore_ops(&pci_syscore_pm_ops);
> +#endif
> return platform_driver_register(&fsl_pci_driver);
> }
> arch_initcall(fsl_pci_init);
> diff --git a/arch/powerpc/sysdev/fsl_pci.h b/arch/powerpc/sysdev/fsl_pci.h
> index 8d455df..c1cec77 100644
> --- a/arch/powerpc/sysdev/fsl_pci.h
> +++ b/arch/powerpc/sysdev/fsl_pci.h
> @@ -32,6 +32,13 @@ struct platform_device;
> #define PIWAR_WRITE_SNOOP 0x00005000
> #define PIWAR_SZ_MASK 0x0000003f
>
> +#define PEX_PMCR_PTOMR 0x1
> +#define PEX_PMCR_EXL2S 0x2
> +
> +#define PME_DISR_EN_PTOD 0x00008000
> +#define PME_DISR_EN_ENL23D 0x00002000
> +#define PME_DISR_EN_EXL23D 0x00001000
> +
> /* PCI/PCI Express outbound window reg */
> struct pci_outbound_window_regs {
> __be32 potar; /* 0x.0 - Outbound translation address register */
> @@ -111,6 +118,7 @@ struct ccsr_pci {
>
> extern int fsl_add_bridge(struct platform_device *pdev, int is_primary);
> extern void fsl_pcibios_fixup_bus(struct pci_bus *bus);
> +extern void fsl_pcibios_fixup_phb(struct pci_controller *phb);
> extern int mpc83xx_add_bridge(struct device_node *dev);
> u64 fsl_pci_immrbar_base(struct pci_controller *hose);
>
>
--
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.
^ permalink raw reply
* Re: [alsa-devel] [PATCH] ASoC: fsl_ssi: Fixed wrong printf format identifier
From: Mark Brown @ 2014-01-07 11:11 UTC (permalink / raw)
To: Fabio Estevam
Cc: alsa-devel@alsa-project.org, Alexander Shiyan, Takashi Iwai,
Liam Girdwood, Timur Tabi, linuxppc-dev@lists.ozlabs.org
In-Reply-To: <CAOMZO5AK3=d322K80a6Y16xWKFYy9dWJEupF6W8mqLxm0_=j8g@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 187 bytes --]
On Tue, Jan 07, 2014 at 08:08:14AM -0200, Fabio Estevam wrote:
> I have sent the same fix as well as I haven't seen your patch before I
> submitted mine.
I saw Fabio's patch first too.
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [PATCH 1/2] powerpc/dts: fix lbc lack of error interrupt
From: Mark Rutland @ 2014-01-07 10:34 UTC (permalink / raw)
To: Dongsheng Wang
Cc: scottwood@freescale.com, devicetree@vger.kernel.org,
linuxppc-dev@lists.ozlabs.org, galak@codeaurora.org
In-Reply-To: <1389076002-18674-1-git-send-email-dongsheng.wang@freescale.com>
On Tue, Jan 07, 2014 at 06:26:42AM +0000, Dongsheng Wang wrote:
> From: Wang Dongsheng <dongsheng.wang@freescale.com>
>
> P1020, P1021, P1022, P1023 when the lbc get error, the error
> interrupt will be triggered. The corresponding interrupt is
> internal IRQ0. So system have to process the lbc IRQ0 interrupt.
>
> The corresponding lbc general interrupt is internal IRQ3.
>
> Signed-off-by: Wang Dongsheng <dongsheng.wang@freescale.com>
>
> diff --git a/arch/powerpc/boot/dts/fsl/p1020si-post.dtsi b/arch/powerpc/boot/dts/fsl/p1020si-post.dtsi
> index 68cc5e7..13f209f 100644
> --- a/arch/powerpc/boot/dts/fsl/p1020si-post.dtsi
> +++ b/arch/powerpc/boot/dts/fsl/p1020si-post.dtsi
> @@ -36,7 +36,8 @@
> #address-cells = <2>;
> #size-cells = <1>;
> compatible = "fsl,p1020-elbc", "fsl,elbc", "simple-bus";
> - interrupts = <19 2 0 0>;
> + interrupts = <19 2 0 0
> + 16 2 0 0>;
Minor nit: please bracket individual list elements like so:
interrupts = <19 2 0 0>,
<16 2 0 0>;
Otherwise this looks fine to me.
Thanks,
Mark.
^ permalink raw reply
* Re: [PATCH] slub: Don't throw away partial remote slabs if there is no local memory
From: Wanpeng Li @ 2014-01-07 10:28 UTC (permalink / raw)
To: Anton Blanchard
Cc: cl, nacc, penberg, linux-mm, Andi Kleen, paulus, mpm, Joonsoo Kim,
linuxppc-dev
In-Reply-To: <20140107132100.5b5ad198@kryten>
On Tue, Jan 07, 2014 at 01:21:00PM +1100, Anton Blanchard wrote:
>
>We noticed a huge amount of slab memory consumed on a large ppc64 box:
>
>Slab: 2094336 kB
>
>Almost 2GB. This box is not balanced and some nodes do not have local
>memory, causing slub to be very inefficient in its slab usage.
>
>Each time we call kmem_cache_alloc_node slub checks the per cpu slab,
>sees it isn't node local, deactivates it and tries to allocate a new
>slab. On empty nodes we will allocate a new remote slab and use the
>first slot, but as explained above when we get called a second time
>we will just deactivate that slab and retry.
>
Deactive cpu slab cache doesn't always mean free the slab cache to buddy system,
maybe the slab cache will be putback to the remote node's partial list if there
are objects still in used in this unbalance situation. In this case, the slub slow
path can freeze the partial slab in remote node again. So why the slab cache is
fragmented as below?
Regards,
Wanpeng Li
>As such we end up only using 1 entry in each slab:
>
>slab mem objects
> used active
>------------------------------------
>kmalloc-16384 1404 MB 4.90%
>task_struct 668 MB 2.90%
>kmalloc-128 193 MB 3.61%
>kmalloc-192 152 MB 5.23%
>kmalloc-8192 72 MB 23.40%
>kmalloc-16 64 MB 7.43%
>kmalloc-512 33 MB 22.41%
>
>The patch below checks that a node is not empty before deactivating a
>slab and trying to allocate it again. With this patch applied we now
>use about 352MB:
>
>Slab: 360192 kB
>
>And our efficiency is much better:
>
>slab mem objects
> used active
>------------------------------------
>kmalloc-16384 92 MB 74.27%
>task_struct 23 MB 83.46%
>idr_layer_cache 18 MB 100.00%
>pgtable-2^12 17 MB 100.00%
>kmalloc-65536 15 MB 100.00%
>inode_cache 14 MB 100.00%
>kmalloc-256 14 MB 97.81%
>kmalloc-8192 14 MB 85.71%
>
>Signed-off-by: Anton Blanchard <anton@samba.org>
>---
>
>Thoughts? It seems like we could hit a similar situation if a machine
>is balanced but we run out of memory on a single node.
>
>Index: b/mm/slub.c
>===================================================================
>--- a/mm/slub.c
>+++ b/mm/slub.c
>@@ -2278,10 +2278,17 @@ redo:
>
> if (unlikely(!node_match(page, node))) {
> stat(s, ALLOC_NODE_MISMATCH);
>- deactivate_slab(s, page, c->freelist);
>- c->page = NULL;
>- c->freelist = NULL;
>- goto new_slab;
>+
>+ /*
>+ * If the node contains no memory there is no point in trying
>+ * to allocate a new node local slab
>+ */
>+ if (node_spanned_pages(node)) {
>+ deactivate_slab(s, page, c->freelist);
>+ c->page = NULL;
>+ c->freelist = NULL;
>+ goto new_slab;
>+ }
> }
>
> /*
>
>--
>To unsubscribe, send a message with 'unsubscribe linux-mm' in
>the body to majordomo@kvack.org. For more info on Linux MM,
>see: http://www.linux-mm.org/ .
>Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* RE: [PATCH] powerpc/mpic: supply a .disable callback
From: Dongsheng.Wang @ 2014-01-07 10:18 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: Scott Wood, linuxppc-dev@lists.ozlabs.org
In-Reply-To: <1389073776.4672.5.camel@pasglop>
DQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogQmVuamFtaW4gSGVycmVu
c2NobWlkdCBbbWFpbHRvOmJlbmhAa2VybmVsLmNyYXNoaW5nLm9yZ10NCj4gU2VudDogVHVlc2Rh
eSwgSmFudWFyeSAwNywgMjAxNCAxOjUwIFBNDQo+IFRvOiBXYW5nIERvbmdzaGVuZy1CNDA1MzQN
Cj4gQ2M6IFdvb2QgU2NvdHQtQjA3NDIxOyBsaW51eHBwYy1kZXZAbGlzdHMub3psYWJzLm9yZw0K
PiBTdWJqZWN0OiBSZTogW1BBVENIXSBwb3dlcnBjL21waWM6IHN1cHBseSBhIC5kaXNhYmxlIGNh
bGxiYWNrDQo+IA0KPiBPbiBUdWUsIDIwMTQtMDEtMDcgYXQgMTM6MzggKzA4MDAsIERvbmdzaGVu
ZyBXYW5nIHdyb3RlOg0KPiA+IEZyb206IFdhbmcgRG9uZ3NoZW5nIDxkb25nc2hlbmcud2FuZ0Bm
cmVlc2NhbGUuY29tPg0KPiA+DQo+ID4gQ3VycmVudGx5IE1QSUMgcHJvdmlkZXMgLm1hc2ssIGJ1
dCBub3QgLmRpc2FibGUuICBUaGlzIG1lYW5zIHRoYXQNCj4gPiBlZmZlY3RpdmVseSBkaXNhYmxl
X2lycSgpIHNvZnQtZGlzYWJsZXMgdGhlIGludGVycnVwdCwgYW5kIHlvdSBnZXQNCj4gPiBhIC5t
YXNrIGNhbGwgaWYgYW4gaW50ZXJydXB0IGFjdHVhbGx5IG9jY3Vycy4NCj4gPg0KPiA+IEknbSBu
b3Qgc3VyZSBpZiB0aGlzIHdhcyBpbnRlbmRlZCBhcyBhIHBlcmZvcm1hbmNlIGJlbmVmaXQgKGl0
IHNlZW1zIGNvbW1vbg0KPiA+IHRvIG9taXQgLmRpc2FibGUgb24gcG93ZXJwYyBpbnRlcnJ1cHQg
Y29udHJvbGxlcnMsIGJ1dCBub3doZXJlIGVsc2UpLCBidXQgaXQNCj4gPiBpbnRlcmFjdHMgYmFk
bHkgd2l0aCB0aHJlYWRlZC93b3JrcXVldWUgaW50ZXJydXB0cyAoaW5jbHVkaW5nIEtWTQ0KPiA+
IHJlZmxlY3Rpb24pLiAgSW4gc3VjaCBjYXNlcywgd2hlcmUgdGhlIHJlYWwgaW50ZXJydXB0IGhh
bmRsZXIgZG9lcyBhDQo+ID4gZGlzYWJsZV9pcnFfbm9zeW5jKCksIHNjaGVkdWxlcyBkZWZlcmVk
IGhhbmRsaW5nLCBhbmQgcmV0dXJucywgd2UgZ2V0IHR3bw0KPiA+IGludGVycnVwdHMgZm9yIGV2
ZXJ5IHJlYWwgaW50ZXJydXB0LiAgVGhlIHNlY29uZCBpbnRlcnJ1cHQgZG9lcyBub3RoaW5nDQo+
ID4gYnV0IHNlZSB0aGF0IElSUV9ESVNBQkxFRCBpcyBzZXQsIGFuZCBkZWNpZGUgdGhhdCBpdCB3
b3VsZCBiZSBhIGdvb2QNCj4gPiBpZGVhIHRvIGFjdHVhbGx5IGNhbGwgLm1hc2suDQo+IA0KPiBX
ZSBwcm9iYWJseSBkb24ndCB3YW50IHRvIGRvIHRoYXQgZm9yIGVkZ2UsIG9ubHkgbGV2ZWwgaW50
ZXJydXB0cy4NCj4gDQpTb3JyeSBCZW4sIEkgYW0gbm90IHVuZGVyc3RhbmQgeW91ciBjb21tZW50
cy4NCg0KVGhpcyBpc3N1ZSBpcyB0aGUga2VybmVsIGFwaSBpcnFfZGlzYWJsZSgpIG9ubHkgdXNl
IGNoaXAtPmlycV9kaXNhYmxlKCksIGJ1dCBtcGljDQpub3QgaGF2ZSB0aGlzIGludGVyZmFjZSBz
byB3ZSBkb24ndCByZWFsIGRpc2FibGUgdGhlIGludGVycnVwdC4NCg0KLURvbmdzaGVuZw0KDQo+
IENoZWVycywNCj4gQmVuLg0KPiANCg0K
^ permalink raw reply
* Re: [alsa-devel] [PATCH] ASoC: fsl_ssi: Fixed wrong printf format identifier
From: Fabio Estevam @ 2014-01-07 10:08 UTC (permalink / raw)
To: Alexander Shiyan
Cc: alsa-devel@alsa-project.org, Takashi Iwai, Liam Girdwood,
Timur Tabi, Mark Brown, linuxppc-dev@lists.ozlabs.org
In-Reply-To: <1389074690-21654-1-git-send-email-shc_work@mail.ru>
On Tue, Jan 7, 2014 at 4:04 AM, Alexander Shiyan <shc_work@mail.ru> wrote:
> sound/soc/fsl/fsl_ssi.c: In function 'fsl_ssi_probe':
> sound/soc/fsl/fsl_ssi.c:1180:6: warning: format '%d' expects argument
> of type 'int', but argument 3 has type 'long int' [-Wformat=]
>
> Reported-by: kbuild test robot <fengguang.wu@intel.com>
> Signed-off-by: Alexander Shiyan <shc_work@mail.ru>
I have sent the same fix as well as I haven't seen your patch before I
submitted mine.
It is usually a good idea to specify in the commit log what was the
commit that caused the warning.
Regards,
Fabio Estevam
^ permalink raw reply
* RE: [PATCH 2/2] powerpc/85xx: handle the eLBC error interrupt if it exist in dts
From: Dongsheng.Wang @ 2014-01-07 10:01 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev@lists.ozlabs.org, Shaohui Xie
In-Reply-To: <1389077881.11795.137.camel@snotra.buserror.net>
DQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogV29vZCBTY290dC1CMDc0
MjENCj4gU2VudDogVHVlc2RheSwgSmFudWFyeSAwNywgMjAxNCAyOjU4IFBNDQo+IFRvOiBXYW5n
IERvbmdzaGVuZy1CNDA1MzQNCj4gQ2M6IGxpbnV4cHBjLWRldkBsaXN0cy5vemxhYnMub3JnOyBY
aWUgU2hhb2h1aS1CMjE5ODk7IEt1bWFyIEdhbGENCj4gU3ViamVjdDogUmU6IFtQQVRDSCAyLzJd
IHBvd2VycGMvODV4eDogaGFuZGxlIHRoZSBlTEJDIGVycm9yIGludGVycnVwdCBpZiBpdA0KPiBl
eGlzdCBpbiBkdHMNCj4gDQo+IE9uIFR1ZSwgMjAxNC0wMS0wNyBhdCAxNDoyNyArMDgwMCwgRG9u
Z3NoZW5nIFdhbmcgd3JvdGU6DQo+ID4gRnJvbTogV2FuZyBEb25nc2hlbmcgPGRvbmdzaGVuZy53
YW5nQGZyZWVzY2FsZS5jb20+DQo+IA0KPiBBRkFJQ1QgdGhpcyBwYXRjaCB3YXMgb3JpZ2luYWxs
eSB3cml0dGVuIGJ5IFNoYW9odWkgWGllLg0KPiANCj4gPiBPbiBQMzA0MSwgUDEwMjAsIFAxMDIx
LCBQMTAyMiwgUDEwMjMgZUxCQyBldmVudCBpbnRlcnJ1cHRzIGFyZSByb3V0ZWQNCj4gPiB0byBJ
bnQ5KFAzMDQxKSAmIEludDMoUDEwMngpIHdoaWxlIEVMQkMgZXJyb3IgaW50ZXJydXB0cyBhcmUg
cm91dGVkIHRvDQo+ID4gSW50MCwgd2UgbmVlZCB0byBjYWxsIHJlcXVlc3RfaXJxIGZvciBlYWNo
Lg0KPiANCj4gRm9yIHAzMDQxIEkgdGhvdWdodCB0aGF0IHdhcyBvbmx5IG9uIGVhcmx5IHNpbGlj
b24gcmV2cyB0aGF0IHdlIGRvbid0DQo+IHN1cHBvcnQgYW55bW9yZS4NCj4gDQo+IEFzIGZvciBw
MTAyeCwgaGF2ZSB5b3UgdGVzdGVkIHRoYXQgdGhpcyBpcyBhY3R1YWxseSB3aGF0IGhhcHBlbnM/
ICBIb3cNCj4gd291bGQgd2UgZGlzdGluZ3Vpc2ggZUxCQyBlcnJvcnMgZnJvbSBvdGhlciBlcnJv
ciBzb3VyY2VzLCBnaXZlbiB0aGF0DQo+IHRoZXJlJ3Mgbm8gRUlTUjA/ICBEbyB3ZSBqdXN0IGhv
cGUgdGhhdCBubyBvdGhlciBlcnJvciBpbnRlcnJ1cHRzDQo+IGhhcHBlbj8NClllcywgSSB0ZXN0
ZWQuIFRoZSBpbnRlcnJ1cHQgaXMgc2hhcmQgZUxCQyBpbnRlcnJ1cHQgaGFuZGxlciBjb3VsZCBj
aGVjayB0aGUgZXJyb3IuDQpUaGlzIHBhdGNoIGlzIGZpeCAibm9ib2R5IGNhcmVkIiB0aGUgZXJy
b3IgaW50ZXJydXB0LiBBZnRlciBzbGVlcCByZXN1bWUgdGhlIGxiYw0Kd2lsbCBnZXQgYSBjaGlw
IHNlbGVjdCBlcnJvci4NCg0KLURvbmdzaGVuZw0KDQo+IA0KPiAtU2NvdHQNCj4gDQoNCg==
^ permalink raw reply
* RE: [PATCH] powerpc/mpic: supply a .disable callback
From: Dongsheng.Wang @ 2014-01-07 9:55 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev@lists.ozlabs.org
In-Reply-To: <1389076738.11795.122.camel@snotra.buserror.net>
DQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogV29vZCBTY290dC1CMDc0
MjENCj4gU2VudDogVHVlc2RheSwgSmFudWFyeSAwNywgMjAxNCAyOjM5IFBNDQo+IFRvOiBXYW5n
IERvbmdzaGVuZy1CNDA1MzQNCj4gQ2M6IGJlbmhAa2VybmVsLmNyYXNoaW5nLm9yZzsgbGludXhw
cGMtZGV2QGxpc3RzLm96bGFicy5vcmcNCj4gU3ViamVjdDogUmU6IFtQQVRDSF0gcG93ZXJwYy9t
cGljOiBzdXBwbHkgYSAuZGlzYWJsZSBjYWxsYmFjaw0KPiANCj4gT24gVHVlLCAyMDE0LTAxLTA3
IGF0IDEzOjM4ICswODAwLCBEb25nc2hlbmcgV2FuZyB3cm90ZToNCj4gPiBGcm9tOiBXYW5nIERv
bmdzaGVuZyA8ZG9uZ3NoZW5nLndhbmdAZnJlZXNjYWxlLmNvbT4NCj4gDQo+IFdoeSBkaWQgeW91
IGNoYW5nZSB0aGUgYXV0aG9yIGZpZWxkPw0KPiANCjooLiBJIGZvcmdvdCB0aGF0LCBJIGFkZGVk
IHRoaXMgY29kZSwgbm90IHVzZSBnaXQuDQpTb3JyeSBhYm91dCB0aGF0LCBJJ2xsIGNoYW5nZSBi
YWNrIGFmdGVyIG91ciBkaXNjdXNzaW9uDQoNCi1Eb25nc2hlbmcNCj4gLVNjb3R0DQo+IA0KDQo=
^ permalink raw reply
* Re: [PATCH] slub: Don't throw away partial remote slabs if there is no local memory
From: Wanpeng Li @ 2014-01-07 9:52 UTC (permalink / raw)
To: Joonsoo Kim
Cc: cl, nacc, penberg, linux-mm, paulus, Anton Blanchard, mpm,
linuxppc-dev
In-Reply-To: <20140107074136.GA4011@lge.com>
On Tue, Jan 07, 2014 at 04:41:36PM +0900, Joonsoo Kim wrote:
>On Tue, Jan 07, 2014 at 01:21:00PM +1100, Anton Blanchard wrote:
>>
>> We noticed a huge amount of slab memory consumed on a large ppc64 box:
>>
>> Slab: 2094336 kB
>>
>> Almost 2GB. This box is not balanced and some nodes do not have local
>> memory, causing slub to be very inefficient in its slab usage.
>>
>> Each time we call kmem_cache_alloc_node slub checks the per cpu slab,
>> sees it isn't node local, deactivates it and tries to allocate a new
>> slab. On empty nodes we will allocate a new remote slab and use the
>> first slot, but as explained above when we get called a second time
>> we will just deactivate that slab and retry.
>>
>> As such we end up only using 1 entry in each slab:
>>
>> slab mem objects
>> used active
>> ------------------------------------
>> kmalloc-16384 1404 MB 4.90%
>> task_struct 668 MB 2.90%
>> kmalloc-128 193 MB 3.61%
>> kmalloc-192 152 MB 5.23%
>> kmalloc-8192 72 MB 23.40%
>> kmalloc-16 64 MB 7.43%
>> kmalloc-512 33 MB 22.41%
>>
>> The patch below checks that a node is not empty before deactivating a
>> slab and trying to allocate it again. With this patch applied we now
>> use about 352MB:
>>
>> Slab: 360192 kB
>>
>> And our efficiency is much better:
>>
>> slab mem objects
>> used active
>> ------------------------------------
>> kmalloc-16384 92 MB 74.27%
>> task_struct 23 MB 83.46%
>> idr_layer_cache 18 MB 100.00%
>> pgtable-2^12 17 MB 100.00%
>> kmalloc-65536 15 MB 100.00%
>> inode_cache 14 MB 100.00%
>> kmalloc-256 14 MB 97.81%
>> kmalloc-8192 14 MB 85.71%
>>
>> Signed-off-by: Anton Blanchard <anton@samba.org>
>> ---
>>
>> Thoughts? It seems like we could hit a similar situation if a machine
>> is balanced but we run out of memory on a single node.
>>
>> Index: b/mm/slub.c
>> ===================================================================
>> --- a/mm/slub.c
>> +++ b/mm/slub.c
>> @@ -2278,10 +2278,17 @@ redo:
>>
>> if (unlikely(!node_match(page, node))) {
>> stat(s, ALLOC_NODE_MISMATCH);
>> - deactivate_slab(s, page, c->freelist);
>> - c->page = NULL;
>> - c->freelist = NULL;
>> - goto new_slab;
>> +
>> + /*
>> + * If the node contains no memory there is no point in trying
>> + * to allocate a new node local slab
>> + */
>> + if (node_spanned_pages(node)) {
>> + deactivate_slab(s, page, c->freelist);
>> + c->page = NULL;
>> + c->freelist = NULL;
>> + goto new_slab;
>> + }
>> }
>>
>> /*
>
>Hello,
>
>I think that we need more efforts to solve unbalanced node problem.
>
>With this patch, even if node of current cpu slab is not favorable to
>unbalanced node, allocation would proceed and we would get the unintended memory.
>
>And there is one more problem. Even if we have some partial slabs on
>compatible node, we would allocate new slab, because get_partial() cannot handle
>this unbalance node case.
>
>To fix this correctly, how about following patch?
>
>Thanks.
>
>------------->8--------------------
>diff --git a/mm/slub.c b/mm/slub.c
>index c3eb3d3..a1f6dfa 100644
>--- a/mm/slub.c
>+++ b/mm/slub.c
>@@ -1672,7 +1672,19 @@ static void *get_partial(struct kmem_cache *s, gfp_t flags, int node,
> {
> void *object;
> int searchnode = (node == NUMA_NO_NODE) ? numa_node_id() : node;
>+ struct zonelist *zonelist;
>+ struct zoneref *z;
>+ struct zone *zone;
>+ enum zone_type high_zoneidx = gfp_zone(flags);
>
>+ if (!node_present_pages(searchnode)) {
>+ zonelist = node_zonelist(searchnode, flags);
>+ for_each_zone_zonelist(zone, z, zonelist, high_zoneidx) {
>+ searchnode = zone_to_nid(zone);
>+ if (node_present_pages(searchnode))
>+ break;
>+ }
>+ }
Why change searchnode instead of depending on fallback zones/nodes in
get_any_partial() to allocate partial slabs?
Regards,
Wanpeng Li
> object = get_partial_node(s, get_node(s, searchnode), c, flags);
> if (object || node != NUMA_NO_NODE)
> return object;
>
>--
>To unsubscribe, send a message with 'unsubscribe linux-mm' in
>the body to majordomo@kvack.org. For more info on Linux MM,
>see: http://www.linux-mm.org/ .
>Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* RE: [PATCH 1/2] pci: Fix root port bus->self is NULL
From: Dongsheng.Wang @ 2014-01-07 9:51 UTC (permalink / raw)
To: Jiang Liu, Yijing Wang, bhelgaas@google.com, rjw@rjwysocki.net
Cc: Scott Wood, linux-pci@vger.kernel.org,
linuxppc-dev@lists.ozlabs.org, galak@codeaurora.org
In-Reply-To: <52CBC0B6.1090904@linux.intel.com>
PiA+PiBkaWZmIC0tZ2l0IGEvZHJpdmVycy9wY2kvcHJvYmUuYyBiL2RyaXZlcnMvcGNpL3Byb2Jl
LmMgaW5kZXgNCj4gPj4gMzhlNDAzZC4uN2YyZDFhYiAxMDA2NDQNCj4gPj4gLS0tIGEvZHJpdmVy
cy9wY2kvcHJvYmUuYw0KPiA+PiArKysgYi9kcml2ZXJzL3BjaS9wcm9iZS5jDQo+ID4+IEBAIC0x
NDcyLDYgKzE0NzIsOSBAQCBpbnQgcGNpX3NjYW5fc2xvdChzdHJ1Y3QgcGNpX2J1cyAqYnVzLCBp
bnQgZGV2Zm4pDQo+ID4+ICAJaWYgKCFkZXYtPmlzX2FkZGVkKQ0KPiA+PiAgCQlucisrOw0KPiA+
Pg0KPiA+PiArCWlmIChwY2lfcGNpZV90eXBlKGRldikgPT0gUENJX0VYUF9UWVBFX1JPT1RfUE9S
VCkNCj4gPj4gKwkJYnVzLT5zZWxmID0gZGV2Ow0KPiA+DQo+ID4gSW4gdGhpcyBjYXNlLCBidXMg
aXMgdGhlIHBjaSByb290IGJ1cyBJIHRoaW5rLCBzbyB3aHkgc2V0IGJ1cy0+c2VsZiA9IHJvb3QN
Cj4gcG9ydCA/DQo+ID4gImJ1cy0+c2VsZiIgc2hvdWxkIHBvaW50ZXIgdG8gdGhlIHBjaSBkZXZp
Y2UgdGhhdCBicmlkZ2Ugb3V0IHRoaXMgYnVzLg0KPiBZZXMsIHRoaXMgcGF0Y2ggc2VlbXMgd3Jv
bmcuIElmIGRldiBpcyByb290IHBvcnQsIGJ1cyBzaG91bGQgYmUgcm9vdCBidXMsIHNvIHdlDQo+
IHNob3VsZG4ndCBzZXQgcm9vdF9idXMtPnNlbGYgPSBwY2lfZGV2X29mX3Jvb3RfcG9ydC4NCj4g
DQpXaHkgdGhlIHJvb3QgYnVzLT5zZWxmIHBvaW50ZXIgdG8gdGhlIGJyaWRnZT8NCklmIGNoaWxk
IGJ1cyBjcmVhdGUgZnJvbSByb290IGJ1cywgdGhlIGNoaWxkLT5zZWxmIHdpbGwgZ2V0IHRoZSBi
cmlkZ2Uocm9vdCBwb3J0KSBwY2kgZGV2aWNlLg0KDQo+IEFjdHVhbGx5IFBDSSBjb3JlIGhhcyBj
b3JyZWN0bHkgc2V0dXAgcGNpX2J1cy0+c2VsZiBmb3Igc2Vjb25kYXJ5IGJ1cyBvZiBQQ0llDQo+
IHJvb3QgcG9ydC4NClllcywgcmlnaHQuIEJ1dCB0aGUgcm9vdC1idXMtPnNlbGYgaXMgTlVMTC4g
SSB0aGluayB0aGUgcm9vdCBidXMgc2hvdWxkIGdldCByb290IHBvcnQNCnBjaSBkZXZpY2UgZm9y
IGl0c2VsZi4gSWYgdGhlcmUgaXMgbm8gYnJpZGdlIGF0IGJvYXJkIGhvdyB0byBnZXQgdGhlIHJv
b3QgcG9ydCBkZXZpY2U/DQoNCi1Eb25nc2hlbmcNCg0KPiANCj4gVGhhbmtzIQ0KPiBHZXJyeQ0K
PiANCg0K
^ permalink raw reply
* RE: [PATCH] slub: Don't throw away partial remote slabs if there is no local memory
From: David Laight @ 2014-01-07 9:42 UTC (permalink / raw)
To: 'Anton Blanchard', benh@kernel.crashing.org,
paulus@samba.org, cl@linux-foundation.org, penberg@kernel.org,
mpm@selenic.com, nacc@linux.vnet.ibm.com
Cc: linux-mm@kvack.org, linuxppc-dev@lists.ozlabs.org
In-Reply-To: <20140107132100.5b5ad198@kryten>
> From: Anton Blanchard
> We noticed a huge amount of slab memory consumed on a large ppc64 box:
>=20
> Slab: 2094336 kB
>=20
> Almost 2GB. This box is not balanced and some nodes do not have local
> memory, causing slub to be very inefficient in its slab usage.
>=20
> Each time we call kmem_cache_alloc_node slub checks the per cpu slab,
> sees it isn't node local, deactivates it and tries to allocate a new
> slab. ...
...
> if (unlikely(!node_match(page, node))) {
> stat(s, ALLOC_NODE_MISMATCH);
> deactivate_slab(s, page, c->freelist);
> c->page =3D NULL;
> c->freelist =3D NULL;
> goto new_slab;
> }
Why not just delete the entire test?
Presumably some time a little earlier no local memory was available.
Even if there is some available now, it is very likely that some won't
be available again in the near future.
David.
^ permalink raw reply
* Re: [PATCH] slub: Don't throw away partial remote slabs if there is no local memory
From: Wanpeng Li @ 2014-01-07 9:49 UTC (permalink / raw)
To: Joonsoo Kim
Cc: cl, nacc, penberg, linux-mm, paulus, Anton Blanchard, mpm,
linuxppc-dev
In-Reply-To: <20140107093156.GA10157@lge.com>
On Tue, Jan 07, 2014 at 06:31:56PM +0900, Joonsoo Kim wrote:
>On Tue, Jan 07, 2014 at 05:21:45PM +0800, Wanpeng Li wrote:
>> On Tue, Jan 07, 2014 at 06:10:16PM +0900, Joonsoo Kim wrote:
>> >On Tue, Jan 07, 2014 at 04:48:40PM +0800, Wanpeng Li wrote:
>> >> Hi Joonsoo,
>> >> On Tue, Jan 07, 2014 at 04:41:36PM +0900, Joonsoo Kim wrote:
>> >> >On Tue, Jan 07, 2014 at 01:21:00PM +1100, Anton Blanchard wrote:
>> >> >>
>> >> [...]
>> >> >Hello,
>> >> >
>> >> >I think that we need more efforts to solve unbalanced node problem.
>> >> >
>> >> >With this patch, even if node of current cpu slab is not favorable to
>> >> >unbalanced node, allocation would proceed and we would get the unintended memory.
>> >> >
>> >>
>> >> We have a machine:
>> >>
>> >> [ 0.000000] Node 0 Memory:
>> >> [ 0.000000] Node 4 Memory: 0x0-0x10000000 0x20000000-0x60000000 0x80000000-0xc0000000
>> >> [ 0.000000] Node 6 Memory: 0x10000000-0x20000000 0x60000000-0x80000000
>> >> [ 0.000000] Node 10 Memory: 0xc0000000-0x180000000
>> >>
>> >> [ 0.041486] Node 0 CPUs: 0-19
>> >> [ 0.041490] Node 4 CPUs:
>> >> [ 0.041492] Node 6 CPUs:
>> >> [ 0.041495] Node 10 CPUs:
>> >>
>> >> The pages of current cpu slab should be allocated from fallback zones/nodes
>> >> of the memoryless node in buddy system, how can not favorable happen?
>> >
>> >Hi, Wanpeng.
>> >
>> >IIRC, if we call kmem_cache_alloc_node() with certain node #, we try to
>> >allocate the page in fallback zones/node of that node #. So fallback list isn't
>> >related to fallback one of memoryless node #. Am I wrong?
>> >
>>
>> Anton add node_spanned_pages(node) check, so current cpu slab mentioned
>> above is against memoryless node. If I miss something?
>
>I thought following scenario.
>
>memoryless node # : 1
>1's fallback node # : 0
>
>On node 1's cpu,
>
>1. kmem_cache_alloc_node (node 2)
>2. allocate the page on node 2 for the slab, now cpu slab is that one.
>3. kmem_cache_alloc_node (local node, that is, node 1)
>4. It check node_spanned_pages() and find it is memoryless node.
>So return node 2's memory.
>
>Is it impossible scenario?
>
Indeed, it can happen.
Regards,
Wanpeng Li
>Thanks.
^ permalink raw reply
* RE: [RFC] linux/pci: move pci_platform_pm_ops to linux/pci.h
From: Dongsheng.Wang @ 2014-01-07 9:35 UTC (permalink / raw)
To: Rafael J. Wysocki, Bjorn Helgaas
Cc: Linux PM list, linux-pci@vger.kernel.org, Scott Wood,
linuxppc-dev
In-Reply-To: <2276888.ovWFBgDtau@vostro.rjw.lan>
DQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogUmFmYWVsIEouIFd5c29j
a2kgW21haWx0bzpyandAcmp3eXNvY2tpLm5ldF0NCj4gU2VudDogTW9uZGF5LCBKYW51YXJ5IDA2
LCAyMDE0IDg6MTMgUE0NCj4gVG86IEJqb3JuIEhlbGdhYXMNCj4gQ2M6IFdhbmcgRG9uZ3NoZW5n
LUI0MDUzNDsgWmFuZyBSb3ktUjYxOTExOyBXb29kIFNjb3R0LUIwNzQyMTsgS3VtYXIgR2FsYTsg
TGludXgNCj4gUE0gbGlzdDsgbGludXgtcGNpQHZnZXIua2VybmVsLm9yZzsgbGludXhwcGMtZGV2
DQo+IFN1YmplY3Q6IFJlOiBbUkZDXSBsaW51eC9wY2k6IG1vdmUgcGNpX3BsYXRmb3JtX3BtX29w
cyB0byBsaW51eC9wY2kuaA0KPiANCj4gT24gRnJpZGF5LCBEZWNlbWJlciAyMCwgMjAxMyAwOTo0
Mjo1OSBBTSBCam9ybiBIZWxnYWFzIHdyb3RlOg0KPiA+IE9uIEZyaSwgRGVjIDIwLCAyMDEzIGF0
IDM6MDMgQU0sIERvbmdzaGVuZyBXYW5nDQo+ID4gPGRvbmdzaGVuZy53YW5nQGZyZWVzY2FsZS5j
b20+IHdyb3RlOg0KPiA+ID4gRnJvbTogV2FuZyBEb25nc2hlbmcgPGRvbmdzaGVuZy53YW5nQGZy
ZWVzY2FsZS5jb20+DQo+ID4gPg0KPiA+ID4gbWFrZSBGcmVlc2NhbGUgcGxhdGZvcm0gdXNlIHBj
aV9wbGF0Zm9ybV9wbV9vcHMgc3RydWN0Lg0KPiA+DQo+ID4gVGhpcyBjaGFuZ2Vsb2cgZG9lc24n
dCBzYXkgYW55dGhpbmcgYWJvdXQgd2hhdCB0aGUgcGF0Y2ggZG9lcy4NCj4gPg0KPiA+IEkgaW5m
ZXIgdGhhdCB5b3Ugd2FudCB0byB1c2UgcGNpX3BsYXRmb3JtX3BtX29wcyBmcm9tIHNvbWUgRnJl
ZXNjYWxlDQo+ID4gY29kZS4gIFRoaXMgcGF0Y2ggc2hvdWxkIGJlIHBvc3RlZCBhbG9uZyB3aXRo
IHRoZSBwYXRjaGVzIHRoYXQgYWRkDQo+ID4gdGhhdCBGcmVlc2NhbGUgY29kZSwgc28gd2UgY2Fu
IHNlZSBob3cgeW91IGludGVuZCB0byB1c2UgaXQuDQo+ID4NCj4gPiBUaGUgZXhpc3RpbmcgdXNl
IGlzIGluIGRyaXZlcnMvcGNpL3BjaS1hY3BpLmMsIHNvIGl0J3MgcG9zc2libGUgdGhhdA0KPiA+
IHlvdXIgbmV3IHVzZSBzaG91bGQgYmUgYWRkZWQgaW4gdGhlIHNhbWUgd2F5LCBpbiBkcml2ZXJz
L3BjaSwgc28gd2UNCj4gPiBkb24ndCBoYXZlIHRvIG1ha2UgcGNpX3BsYXRmb3JtX3BtX29wcyBw
YXJ0IG9mIHRoZSBwdWJsaWMgUENJDQo+ID4gaW50ZXJmYWNlIGluIGluY2x1ZGUvbGludXgvcGNp
LmguDQo+ID4NCj4gPiBUaGF0IHNhaWQsIGlmIFJhcGhhZWwgdGhpbmtzIHRoaXMgbWFrZXMgc2Vu
c2UsIGl0J3MgT0sgd2l0aCBtZS4NCj4gDQo+IFdlbGwsIEknZCBsaWtlIHRvIGtub3cgd2h5IGV4
YWN0bHkgdGhlIGNoYW5nZSBpcyBuZWVkZWQgaW4gdGhlIGZpcnN0IHBsYWNlLg0KPiANClRoYW5r
cyBmb3IgcmV2aWV3LCBJIHRoaW5rIHRoZSBpZGVhIGlzIG5vdCBzdWl0YWJsZSBmb3IgZnJlZXNj
YWxlIHBsYXRmb3JtDQppbXBsZW1lbnRhdGlvbiBvZiB0aGUgcmlnaHQgbm93Lg0KDQpJIHdpbGwg
ZHJvcCB0aGlzIFJGQyBwYXRjaC4NCg0KLURvbmdzaGVuZw0KDQo+IFRoYW5rcyENCj4gDQo+IC0t
DQo+IEkgc3BlYWsgb25seSBmb3IgbXlzZWxmLg0KPiBSYWZhZWwgSi4gV3lzb2NraSwgSW50ZWwg
T3BlbiBTb3VyY2UgVGVjaG5vbG9neSBDZW50ZXIuDQo+IA0KDQo=
^ permalink raw reply
* Re: [PATCH] slub: Don't throw away partial remote slabs if there is no local memory
From: Joonsoo Kim @ 2014-01-07 9:31 UTC (permalink / raw)
To: Wanpeng Li
Cc: cl, nacc, penberg, linux-mm, paulus, Anton Blanchard, mpm,
linuxppc-dev
In-Reply-To: <52cbc738.c727440a.5ead.27a3SMTPIN_ADDED_BROKEN@mx.google.com>
On Tue, Jan 07, 2014 at 05:21:45PM +0800, Wanpeng Li wrote:
> On Tue, Jan 07, 2014 at 06:10:16PM +0900, Joonsoo Kim wrote:
> >On Tue, Jan 07, 2014 at 04:48:40PM +0800, Wanpeng Li wrote:
> >> Hi Joonsoo,
> >> On Tue, Jan 07, 2014 at 04:41:36PM +0900, Joonsoo Kim wrote:
> >> >On Tue, Jan 07, 2014 at 01:21:00PM +1100, Anton Blanchard wrote:
> >> >>
> >> [...]
> >> >Hello,
> >> >
> >> >I think that we need more efforts to solve unbalanced node problem.
> >> >
> >> >With this patch, even if node of current cpu slab is not favorable to
> >> >unbalanced node, allocation would proceed and we would get the unintended memory.
> >> >
> >>
> >> We have a machine:
> >>
> >> [ 0.000000] Node 0 Memory:
> >> [ 0.000000] Node 4 Memory: 0x0-0x10000000 0x20000000-0x60000000 0x80000000-0xc0000000
> >> [ 0.000000] Node 6 Memory: 0x10000000-0x20000000 0x60000000-0x80000000
> >> [ 0.000000] Node 10 Memory: 0xc0000000-0x180000000
> >>
> >> [ 0.041486] Node 0 CPUs: 0-19
> >> [ 0.041490] Node 4 CPUs:
> >> [ 0.041492] Node 6 CPUs:
> >> [ 0.041495] Node 10 CPUs:
> >>
> >> The pages of current cpu slab should be allocated from fallback zones/nodes
> >> of the memoryless node in buddy system, how can not favorable happen?
> >
> >Hi, Wanpeng.
> >
> >IIRC, if we call kmem_cache_alloc_node() with certain node #, we try to
> >allocate the page in fallback zones/node of that node #. So fallback list isn't
> >related to fallback one of memoryless node #. Am I wrong?
> >
>
> Anton add node_spanned_pages(node) check, so current cpu slab mentioned
> above is against memoryless node. If I miss something?
I thought following scenario.
memoryless node # : 1
1's fallback node # : 0
On node 1's cpu,
1. kmem_cache_alloc_node (node 2)
2. allocate the page on node 2 for the slab, now cpu slab is that one.
3. kmem_cache_alloc_node (local node, that is, node 1)
4. It check node_spanned_pages() and find it is memoryless node.
So return node 2's memory.
Is it impossible scenario?
Thanks.
^ permalink raw reply
* Re: [PATCH] slub: Don't throw away partial remote slabs if there is no local memory
From: Wanpeng Li @ 2014-01-07 9:21 UTC (permalink / raw)
To: Joonsoo Kim
Cc: cl, nacc, penberg, linux-mm, paulus, Anton Blanchard, mpm,
linuxppc-dev
In-Reply-To: <20140107091016.GA21965@lge.com>
On Tue, Jan 07, 2014 at 06:10:16PM +0900, Joonsoo Kim wrote:
>On Tue, Jan 07, 2014 at 04:48:40PM +0800, Wanpeng Li wrote:
>> Hi Joonsoo,
>> On Tue, Jan 07, 2014 at 04:41:36PM +0900, Joonsoo Kim wrote:
>> >On Tue, Jan 07, 2014 at 01:21:00PM +1100, Anton Blanchard wrote:
>> >>
>> [...]
>> >Hello,
>> >
>> >I think that we need more efforts to solve unbalanced node problem.
>> >
>> >With this patch, even if node of current cpu slab is not favorable to
>> >unbalanced node, allocation would proceed and we would get the unintended memory.
>> >
>>
>> We have a machine:
>>
>> [ 0.000000] Node 0 Memory:
>> [ 0.000000] Node 4 Memory: 0x0-0x10000000 0x20000000-0x60000000 0x80000000-0xc0000000
>> [ 0.000000] Node 6 Memory: 0x10000000-0x20000000 0x60000000-0x80000000
>> [ 0.000000] Node 10 Memory: 0xc0000000-0x180000000
>>
>> [ 0.041486] Node 0 CPUs: 0-19
>> [ 0.041490] Node 4 CPUs:
>> [ 0.041492] Node 6 CPUs:
>> [ 0.041495] Node 10 CPUs:
>>
>> The pages of current cpu slab should be allocated from fallback zones/nodes
>> of the memoryless node in buddy system, how can not favorable happen?
>
>Hi, Wanpeng.
>
>IIRC, if we call kmem_cache_alloc_node() with certain node #, we try to
>allocate the page in fallback zones/node of that node #. So fallback list isn't
>related to fallback one of memoryless node #. Am I wrong?
>
Anton add node_spanned_pages(node) check, so current cpu slab mentioned
above is against memoryless node. If I miss something?
Regards,
Wanpeng Li
>Thanks.
>
>>
>> >And there is one more problem. Even if we have some partial slabs on
>> >compatible node, we would allocate new slab, because get_partial() cannot handle
>> >this unbalance node case.
>> >
>> >To fix this correctly, how about following patch?
>> >
>>
>> So I think we should fold both of your two patches to one.
>>
>> Regards,
>> Wanpeng Li
>>
>> >Thanks.
>> >
>> >------------->8--------------------
>> >diff --git a/mm/slub.c b/mm/slub.c
>> >index c3eb3d3..a1f6dfa 100644
>> >--- a/mm/slub.c
>> >+++ b/mm/slub.c
>> >@@ -1672,7 +1672,19 @@ static void *get_partial(struct kmem_cache *s, gfp_t flags, int node,
>> > {
>> > void *object;
>> > int searchnode = (node == NUMA_NO_NODE) ? numa_node_id() : node;
>> >+ struct zonelist *zonelist;
>> >+ struct zoneref *z;
>> >+ struct zone *zone;
>> >+ enum zone_type high_zoneidx = gfp_zone(flags);
>> >
>> >+ if (!node_present_pages(searchnode)) {
>> >+ zonelist = node_zonelist(searchnode, flags);
>> >+ for_each_zone_zonelist(zone, z, zonelist, high_zoneidx) {
>> >+ searchnode = zone_to_nid(zone);
>> >+ if (node_present_pages(searchnode))
>> >+ break;
>> >+ }
>> >+ }
>> > object = get_partial_node(s, get_node(s, searchnode), c, flags);
>> > if (object || node != NUMA_NO_NODE)
>> > return object;
>> >
>> >--
>> >To unsubscribe, send a message with 'unsubscribe linux-mm' in
>> >the body to majordomo@kvack.org. For more info on Linux MM,
>> >see: http://www.linux-mm.org/ .
>> >Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
>>
>> --
>> To unsubscribe, send a message with 'unsubscribe linux-mm' in
>> the body to majordomo@kvack.org. For more info on Linux MM,
>> see: http://www.linux-mm.org/ .
>> Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* Re: [PATCH] slub: Don't throw away partial remote slabs if there is no local memory
From: Joonsoo Kim @ 2014-01-07 9:10 UTC (permalink / raw)
To: Wanpeng Li
Cc: cl, nacc, penberg, linux-mm, paulus, Anton Blanchard, mpm,
linuxppc-dev
In-Reply-To: <52cbbf7b.2792420a.571c.ffffd476SMTPIN_ADDED_BROKEN@mx.google.com>
On Tue, Jan 07, 2014 at 04:48:40PM +0800, Wanpeng Li wrote:
> Hi Joonsoo,
> On Tue, Jan 07, 2014 at 04:41:36PM +0900, Joonsoo Kim wrote:
> >On Tue, Jan 07, 2014 at 01:21:00PM +1100, Anton Blanchard wrote:
> >>
> [...]
> >Hello,
> >
> >I think that we need more efforts to solve unbalanced node problem.
> >
> >With this patch, even if node of current cpu slab is not favorable to
> >unbalanced node, allocation would proceed and we would get the unintended memory.
> >
>
> We have a machine:
>
> [ 0.000000] Node 0 Memory:
> [ 0.000000] Node 4 Memory: 0x0-0x10000000 0x20000000-0x60000000 0x80000000-0xc0000000
> [ 0.000000] Node 6 Memory: 0x10000000-0x20000000 0x60000000-0x80000000
> [ 0.000000] Node 10 Memory: 0xc0000000-0x180000000
>
> [ 0.041486] Node 0 CPUs: 0-19
> [ 0.041490] Node 4 CPUs:
> [ 0.041492] Node 6 CPUs:
> [ 0.041495] Node 10 CPUs:
>
> The pages of current cpu slab should be allocated from fallback zones/nodes
> of the memoryless node in buddy system, how can not favorable happen?
Hi, Wanpeng.
IIRC, if we call kmem_cache_alloc_node() with certain node #, we try to
allocate the page in fallback zones/node of that node #. So fallback list isn't
related to fallback one of memoryless node #. Am I wrong?
Thanks.
>
> >And there is one more problem. Even if we have some partial slabs on
> >compatible node, we would allocate new slab, because get_partial() cannot handle
> >this unbalance node case.
> >
> >To fix this correctly, how about following patch?
> >
>
> So I think we should fold both of your two patches to one.
>
> Regards,
> Wanpeng Li
>
> >Thanks.
> >
> >------------->8--------------------
> >diff --git a/mm/slub.c b/mm/slub.c
> >index c3eb3d3..a1f6dfa 100644
> >--- a/mm/slub.c
> >+++ b/mm/slub.c
> >@@ -1672,7 +1672,19 @@ static void *get_partial(struct kmem_cache *s, gfp_t flags, int node,
> > {
> > void *object;
> > int searchnode = (node == NUMA_NO_NODE) ? numa_node_id() : node;
> >+ struct zonelist *zonelist;
> >+ struct zoneref *z;
> >+ struct zone *zone;
> >+ enum zone_type high_zoneidx = gfp_zone(flags);
> >
> >+ if (!node_present_pages(searchnode)) {
> >+ zonelist = node_zonelist(searchnode, flags);
> >+ for_each_zone_zonelist(zone, z, zonelist, high_zoneidx) {
> >+ searchnode = zone_to_nid(zone);
> >+ if (node_present_pages(searchnode))
> >+ break;
> >+ }
> >+ }
> > object = get_partial_node(s, get_node(s, searchnode), c, flags);
> > if (object || node != NUMA_NO_NODE)
> > return object;
> >
> >--
> >To unsubscribe, send a message with 'unsubscribe linux-mm' in
> >the body to majordomo@kvack.org. For more info on Linux MM,
> >see: http://www.linux-mm.org/ .
> >Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
>
> --
> To unsubscribe, send a message with 'unsubscribe linux-mm' in
> the body to majordomo@kvack.org. For more info on Linux MM,
> see: http://www.linux-mm.org/ .
> Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* Re: [PATCH 1/2] pci: Fix root port bus->self is NULL
From: Jiang Liu @ 2014-01-07 8:54 UTC (permalink / raw)
To: Yijing Wang, Dongsheng Wang, bhelgaas, rjw
Cc: scottwood, roy.zang, linux-pci, linuxppc-dev, galak
In-Reply-To: <52CBBA86.7020401@huawei.com>
On 2014/1/7 16:27, Yijing Wang wrote:
> On 2014/1/7 16:04, Dongsheng Wang wrote:
>> From: Wang Dongsheng <dongsheng.wang@freescale.com>
>>
>> the root port bus->self always NULL, so put root port pci device
>> into root port bus->self.
>>
>> Signed-off-by: Wang Dongsheng <dongsheng.wang@freescale.com>
>>
>> diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c
>> index 38e403d..7f2d1ab 100644
>> --- a/drivers/pci/probe.c
>> +++ b/drivers/pci/probe.c
>> @@ -1472,6 +1472,9 @@ int pci_scan_slot(struct pci_bus *bus, int devfn)
>> if (!dev->is_added)
>> nr++;
>>
>> + if (pci_pcie_type(dev) == PCI_EXP_TYPE_ROOT_PORT)
>> + bus->self = dev;
>
> In this case, bus is the pci root bus I think, so why set bus->self = root port ?
> "bus->self" should pointer to the pci device that bridge out this bus.
Yes, this patch seems wrong. If dev is root port, bus should be root
bus, so we shouldn't set root_bus->self = pci_dev_of_root_port.
Actually PCI core has correctly setup pci_bus->self for secondary bus
of PCIe root port.
Thanks!
Gerry
>
>> +
>> for (fn = next_fn(bus, dev, 0); fn > 0; fn = next_fn(bus, dev, fn)) {
>> dev = pci_scan_single_device(bus, devfn + fn);
>> if (dev) {
>>
>
>
^ permalink raw reply
* Re: [PATCH] slub: Don't throw away partial remote slabs if there is no local memory
From: Wanpeng Li @ 2014-01-07 8:48 UTC (permalink / raw)
To: Joonsoo Kim
Cc: cl, nacc, penberg, linux-mm, paulus, Anton Blanchard, mpm,
linuxppc-dev
In-Reply-To: <20140107074136.GA4011@lge.com>
Hi Joonsoo,
On Tue, Jan 07, 2014 at 04:41:36PM +0900, Joonsoo Kim wrote:
>On Tue, Jan 07, 2014 at 01:21:00PM +1100, Anton Blanchard wrote:
>>
[...]
>Hello,
>
>I think that we need more efforts to solve unbalanced node problem.
>
>With this patch, even if node of current cpu slab is not favorable to
>unbalanced node, allocation would proceed and we would get the unintended memory.
>
We have a machine:
[ 0.000000] Node 0 Memory:
[ 0.000000] Node 4 Memory: 0x0-0x10000000 0x20000000-0x60000000 0x80000000-0xc0000000
[ 0.000000] Node 6 Memory: 0x10000000-0x20000000 0x60000000-0x80000000
[ 0.000000] Node 10 Memory: 0xc0000000-0x180000000
[ 0.041486] Node 0 CPUs: 0-19
[ 0.041490] Node 4 CPUs:
[ 0.041492] Node 6 CPUs:
[ 0.041495] Node 10 CPUs:
The pages of current cpu slab should be allocated from fallback zones/nodes
of the memoryless node in buddy system, how can not favorable happen?
>And there is one more problem. Even if we have some partial slabs on
>compatible node, we would allocate new slab, because get_partial() cannot handle
>this unbalance node case.
>
>To fix this correctly, how about following patch?
>
So I think we should fold both of your two patches to one.
Regards,
Wanpeng Li
>Thanks.
>
>------------->8--------------------
>diff --git a/mm/slub.c b/mm/slub.c
>index c3eb3d3..a1f6dfa 100644
>--- a/mm/slub.c
>+++ b/mm/slub.c
>@@ -1672,7 +1672,19 @@ static void *get_partial(struct kmem_cache *s, gfp_t flags, int node,
> {
> void *object;
> int searchnode = (node == NUMA_NO_NODE) ? numa_node_id() : node;
>+ struct zonelist *zonelist;
>+ struct zoneref *z;
>+ struct zone *zone;
>+ enum zone_type high_zoneidx = gfp_zone(flags);
>
>+ if (!node_present_pages(searchnode)) {
>+ zonelist = node_zonelist(searchnode, flags);
>+ for_each_zone_zonelist(zone, z, zonelist, high_zoneidx) {
>+ searchnode = zone_to_nid(zone);
>+ if (node_present_pages(searchnode))
>+ break;
>+ }
>+ }
> object = get_partial_node(s, get_node(s, searchnode), c, flags);
> if (object || node != NUMA_NO_NODE)
> return object;
>
>--
>To unsubscribe, send a message with 'unsubscribe linux-mm' in
>the body to majordomo@kvack.org. For more info on Linux MM,
>see: http://www.linux-mm.org/ .
>Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* Re: [02/12,v3] pci: fsl: add structure fsl_pci
From: Scott Wood @ 2014-01-07 8:33 UTC (permalink / raw)
To: Lian Minghuan-b31939
Cc: Bjorn Helgaas, Minghuan Lian, linuxppc-dev, Zang Roy-R61911,
linux-pci
In-Reply-To: <52CA48C0.2020307@freescale.com>
On Mon, 2014-01-06 at 14:10 +0800, Lian Minghuan-b31939 wrote:
> On 01/04/2014 06:19 AM, Scott Wood wrote:
> > I don't like the extent to which this duplicates (not moves) PPC's struct
> > pci_controller. Also this leaves some fields like "indirect_type"
> > unexplained (PPC_INDIRECT_TYPE_xxx is only in the PPC header).
> >
> > Does the arch-independent part of the driver really need all this? Given
> > how closely this tracks the PPC code, how would this work on ARM?
> [Minghuan] I added the duplicate fields because PPC's struct
> pci_controller need them.
I think a better approach would be to create a cleanly architected
arch-independent driver. Share what you reasonably can with the current
fsl_pci.c, but not to the extent of propagating PPCisms that don't match
up with what we ultimately want to see in generic code, or copying
things that ought to be controller-independent infrastructure into
controller-specific code.
See these threads:
http://www.spinics.net/lists/linux-pci/msg25769.html
https://lkml.org/lkml/2013/5/4/103
> The following is for ARM, I will submit them after verification:
[snip]
> +static int fsl_pcie_register(struct fsl_pcie *pcie)
> +{
> + pcie->controller = fsl_hw_pcie.nr_controllers;
> + fsl_hw_pcie.nr_controllers = 1;
> + fsl_hw_pcie.private_data = (void **)&pcie;
I believe this should be:
fsl_hw_pcie.private_data = pcie;
> + pci_common_init(&fsl_hw_pcie);
> + pci_assign_unassigned_resources();
> +#ifdef CONFIG_PCI_DOMAINS
> + fsl_hw_pcie.domain++;
> +#endif
What serializes that non-atomic increment?
-Scott
^ permalink raw reply
* Re: [PATCH 1/2] pci: Fix root port bus->self is NULL
From: Yijing Wang @ 2014-01-07 8:27 UTC (permalink / raw)
To: Dongsheng Wang, bhelgaas, rjw
Cc: scottwood, roy.zang, linux-pci, linuxppc-dev, galak
In-Reply-To: <1389081848-26506-1-git-send-email-dongsheng.wang@freescale.com>
On 2014/1/7 16:04, Dongsheng Wang wrote:
> From: Wang Dongsheng <dongsheng.wang@freescale.com>
>
> the root port bus->self always NULL, so put root port pci device
> into root port bus->self.
>
> Signed-off-by: Wang Dongsheng <dongsheng.wang@freescale.com>
>
> diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c
> index 38e403d..7f2d1ab 100644
> --- a/drivers/pci/probe.c
> +++ b/drivers/pci/probe.c
> @@ -1472,6 +1472,9 @@ int pci_scan_slot(struct pci_bus *bus, int devfn)
> if (!dev->is_added)
> nr++;
>
> + if (pci_pcie_type(dev) == PCI_EXP_TYPE_ROOT_PORT)
> + bus->self = dev;
In this case, bus is the pci root bus I think, so why set bus->self = root port ?
"bus->self" should pointer to the pci device that bridge out this bus.
> +
> for (fn = next_fn(bus, dev, 0); fn > 0; fn = next_fn(bus, dev, fn)) {
> dev = pci_scan_single_device(bus, devfn + fn);
> if (dev) {
>
--
Thanks!
Yijing
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox