All of lore.kernel.org
 help / color / mirror / Atom feed
From: Patrick Keller <patrick.keller@hp.com>
To: Yinghai Lu <yinghai@kernel.org>
Cc: Jesse Barnes <jbarnes@virtuousgeek.org>,
	Ingo Molnar <mingo@elte.hu>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	Ivan Kokshaysky <ink@jurassic.park.msu.ru>,
	Kenji Kaneshige <kaneshige.kenji@jp.fujitsu.com>,
	"Chiang, Alexander" <achiang@hp.com>,
	"Helgaas, Bjorn" <bjorn.helgaas@hp.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linux-pci@vger.kernel.org" <linux-pci@vger.kernel.org>
Subject: Re: [PATCH 00/14] pci: update pci bridge resources
Date: Fri, 08 Jan 2010 14:33:37 -0700	[thread overview]
Message-ID: <1262986417.2877.1.camel@pLaptop> (raw)
In-Reply-To: <1261522954-12591-1-git-send-email-yinghai@kernel.org>



On Tue, 2009-12-22 at 23:02 +0000, Yinghai Lu wrote:
> this patchset is trying to update pci bridge BAR when that BAR is big enough.
> 
> 1. boot time:
> 
> BIOS separate IO range between several IOHs, and on some slots, BIOS assign
> the resource to the bridge, but stop assigning resource to the device under
> that bridge, because the device need big resource.
> 
> so patches (first 8) are trying to
> a. pci assign unassign and record the failed device resource.
> b. clear the BIOS assigned resource of the parent bridge of fail device
> c. go back and call pci assign unsigned
> d. if it still fail, will go up more bridges. and clear and try again.
> 
> v2: Jesse doesn't like it is in find_free_bus_resource...
>     try to move out of pci_bus_size_bridges loop.
> v3: add pci_setup_bridge calling after pci_bridge_release_not_used_res.
>     only clear release those res for x86.
> v4: Bjorn want to release use dev instead of bus.
> v5: Kenji pointed out it will have problem with several level bridge.
>     so let only handle leaf bridge.
> v6: address Kenji's request (new pci_bus_release...). and change applying order
>     move back release to pci_assign_unassigned_resource
> v7: change functions name pci_bus_release_unused_bridge_res according to Jesse
> v8: address Eric's concern, only overwrite leaf bridge resource that is not big
>     enough need to do it in two steps, and first step recore the failed res,
>     and don't touch bridge res that programmed by firmware. second step will
>     try to release bridge resource that is too small at first.
> v9: refresh to be applied after bjorn's patch, and remove trick about save
>     size and restore resource second try.
> v11:add pci=try=5, about more try to change more bridge
> v12:not shrink pci bridge resource
> 
> 2. hotplug:
> BIOS separate IO range between several IOHs, and on some slots, BIOS assign
> the resource to every bridge. (8M) but when insert one card that big resource,
> the card can not get resource. because kernel will not touch the bridge
> resource.
> 
> so patches (9-11) are trying to
> a. assign resource to devices with that slot. and record fail devices
> b. if there is some failed, will clear sepcifically io port of bridge, or mmio of bridge, or mmio pref of bridge.
> c. try to assign the parent bridge of the slot.
> 
> v2: address Alex's concern about pci remove/rescan feature about
>     pci_setup_bridge changes.
> v3: Kenji pointed out that pci_config_slot need to be called before
>     pci_bus_add_devices()
> v4: move out pci_is_enabled checkout of pci_setup_bridge()
> v5: change the applying sequence.
> v6: change the functions name according to Jesse
> v8: address Eric's concern, only overwrite leaf bridge resource that is not
>      big enough
> v9: refresh to be applied after bjorn's patch, and remove trick about save
>     size and restore resource second try.
> v10:alex found need to have export for pci_assign_unassigned_bridge_resources
> v11: pass check_leaf with pci_bus_release_unused_bridge_res
> 
> patches (12-13)
> will try to shrink, the pci hotplug related pcie port, so could save some for
> others.
> 
> -v13: change resource_list to resource_list_x, to save size and flags aside,
>       otherwise grandchild res will get confused with son's res as could be used
> 
> -v14: default it is disabled.  could use pci=try=2 to enable it.
> -v15: seperate release_child_resources aside.
> 
> Thanks
> 
> Yinghai
> 
> 
> 
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-pci" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

I'm going to work on testing this patch series today with a focus on
hotplug and fakephp functionality. 

Pat


  parent reply	other threads:[~2010-01-08 21:34 UTC|newest]

Thread overview: 42+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-12-22 23:02 [PATCH 00/14] pci: update pci bridge resources Yinghai Lu
2009-12-22 23:02 ` [PATCH 01/14] pci: separate pci_setup_bridge to small functions Yinghai Lu
2010-01-15 18:54   ` Jesse Barnes
2009-12-22 23:02 ` [PATCH 02/14] resource: add release_child_resources Yinghai Lu
2010-01-15 18:54   ` Jesse Barnes
2009-12-22 23:02 ` [PATCH 03/14] pci: add pci_bridge_release_unused_res and pci_bus_release_unused_bridge_res Yinghai Lu
2010-01-15 18:53   ` Jesse Barnes
2010-01-16  0:20     ` Yinghai Lu
2009-12-22 23:02 ` [PATCH 04/14] pci: don't dump it when bus resource flags is not used Yinghai Lu
2010-01-15 18:54   ` Jesse Barnes
2009-12-22 23:02 ` [PATCH 05/14] pci: add failed_list to record failed one for pci_bus_assign_resources Yinghai Lu
2010-01-15 18:56   ` Jesse Barnes
2010-01-15 21:13     ` Yinghai Lu
2010-01-15 21:41   ` Bjorn Helgaas
2009-12-22 23:02 ` [PATCH 06/14] pci: reject mmio range start from 0 on pci_bridge read Yinghai Lu
2010-01-15 19:19   ` Jesse Barnes
2010-01-15 21:15     ` Yinghai Lu
2009-12-22 23:02 ` [PATCH 07/14] pci: don't shrink bridge resources Yinghai Lu
2010-01-15 19:04   ` Jesse Barnes
2010-01-15 21:09     ` Yinghai Lu
2010-01-15 21:31       ` Jesse Barnes
2010-01-16  0:32         ` Yinghai Lu
2009-12-22 23:02 ` [PATCH 08/14] pci: update bridge res to get more big range in pci assign unssign Yinghai Lu
2010-01-15 19:12   ` Jesse Barnes
2010-01-15 21:12     ` Yinghai Lu
2010-01-15 21:34       ` Bjorn Helgaas
2010-01-15 21:34       ` Jesse Barnes
2009-12-22 23:02 ` [PATCH 09/14] pci: introduce pci_assign_unassigned_bridge_resources Yinghai Lu
2010-01-13  0:50   ` Kenji Kaneshige
2010-01-13  1:58     ` Yinghai Lu
2010-01-13  7:31       ` Kenji Kaneshige
2010-01-13  7:52         ` Yinghai Lu
2009-12-22 23:02 ` [PATCH 10/14] pci: pciehp clean flow in pciehp_configure_device Yinghai Lu
2010-01-15 19:14   ` Jesse Barnes
2010-01-15 21:14     ` Yinghai Lu
2009-12-22 23:02 ` [PATCH 11/14] pci: pciehp second try to get big range for pcie devices Yinghai Lu
2009-12-22 23:02 ` [PATCH 12/14] pci: pci_bridge_release_res Yinghai Lu
2009-12-22 23:02 ` [PATCH 13/14] pciehp: add support for bridge resource reallocation Yinghai Lu
2009-12-22 23:02 ` [PATCH 14/14] pci: set PCI_PREF_RANGE_TYPE_64 in pci_bridge_check_ranges Yinghai Lu
2010-01-08 21:33 ` Patrick Keller [this message]
2010-01-11 21:57 ` [PATCH 00/14] pci: update pci bridge resources Patrick Keller
2010-01-12 18:18   ` Jesse Barnes

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1262986417.2877.1.camel@pLaptop \
    --to=patrick.keller@hp.com \
    --cc=achiang@hp.com \
    --cc=bjorn.helgaas@hp.com \
    --cc=ink@jurassic.park.msu.ru \
    --cc=jbarnes@virtuousgeek.org \
    --cc=kaneshige.kenji@jp.fujitsu.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=torvalds@linux-foundation.org \
    --cc=yinghai@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.