* Re: [RFC PATCH 00/16] Refine PCI host bridge scan interfaces
From: Yijing Wang @ 2014-11-18 12:14 UTC (permalink / raw)
To: Lorenzo Pieralisi, Arnd Bergmann
Cc: Liviu Dudau, Tony Luck, Russell King, linux-pci@vger.kernel.org,
x86@kernel.org, linux-kernel@vger.kernel.org, huxinwei@huawei.com,
Thierry Reding, suravee.suthikulpanit@amd.com, Bjorn Helgaas,
linux-ia64@vger.kernel.org, Thomas Gleixner, Wuyun,
linuxppc-dev@lists.ozlabs.org,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <20141118114518.GA3514@red-moon>
On 2014/11/18 19:45, Lorenzo Pieralisi wrote:
> On Tue, Nov 18, 2014 at 11:30:11AM +0000, Arnd Bergmann wrote:
>> On Tuesday 18 November 2014 19:17:32 Yijing Wang wrote:
>>> On 2014/11/17 22:13, Arnd Bergmann wrote:
>>>> On Monday 17 November 2014 18:21:34 Yijing Wang wrote:
>>>>> This series is based Linux 3.18-rc1 and Lorenzo Pieralisi's
>>>>> arm PCI domain cleanup patches, link:
>>>>> https://patchwork.ozlabs.org/patch/407585/
>>>>>
>>>>> Current pci scan interfaces like pci_scan_root_bus() and directly
>>>>> call pci_create_root_bus()/pci_scan_child_bus() lack flexiblity.
>>>>> Some platform infos like PCI domain and msi_chip have to be
>>>>> associated to PCI bus by some arch specific function.
>>>>> We want to make a generic pci_host_bridge, and make it hold
>>>>> the platform infos or hook. Then we could eliminate the lots
>>>>> of arch pci_domain_nr, also we could associate some platform
>>>>> ops something like pci_get_msi_chip(struct pci_dev *dev)
>>>>> with pci_host_bridge to avoid introduce arch weak functions.
>>>>>
>>>>> This RFC version not for all platforms, just applied the new
>>>>> scan interface in x86/arm/powerpc/ia64, I will refresh other
>>>>> platforms after the core pci scan interfaces are ok.
>>>>
>>>> I think overall this is a good direction to take, in particular
>>>> moving more things into struct pci_host_bridge so we can
>>>> slim down the architecture specific code.
>>>
>>> Hi Arnd, thanks very much for your review and comments!
>>>
>>>>
>>>> I don't particularly like the way you use the 'pci_host_info'
>>>> to pass callback pointers and some of the generic information.
>>>> This duplicates some of the issues we are currently trying
>>>> to untangle in the arm32 code to make drivers easier to share
>>>> between architectures.
>>>
>>> What arm32 code you are trying to untangle for example ?
>>
>> We have a few problems that currently prevent us from using shared
>> drivers across arm32 and arm64:
>>
>> - arm32 has an architecture-defined pci_sys_data structure, but
>> we really want to have one that is defined by the host bridge driver
>> and that is architecture independent. Some core functions depend
>> on this structure at the moment, which Lorenzo is trying to
>> undo
>
> Yes, and on this specific point I would like to understand why we
> are adding yet more pci_sys_data data in the last series that is
> already in -next:
>
> https://lkml.org/lkml/2014/10/27/85
>
> What does this buy us ? The cover letter says already that there *is*
> a better solution, why do not we work on that instead of adding more churn
> to arch specific code ?
In my plan, first save msi_chip in pci_sys_data, so we could remove the lots duplicate
pcibios_add_bus(), second, make a generic pci_host_bridge, and move the msi_chip in that,
so we could eliminate all MSI arch weak functions. And in arm I think it's no need to
associate msi_chip with PCI bus, because all pci devices under the same pci host bridge
share the same msi_chip.
>
> Thanks,
> Lorenzo
>
> .
>
--
Thanks!
Yijing
^ permalink raw reply
* Re: [RFC PATCH 01/16] PCI: Enhance pci_scan_root_bus() to support default IO/MEM resources
From: Yijing Wang @ 2014-11-18 11:46 UTC (permalink / raw)
To: Arnd Bergmann, linux-arm-kernel
Cc: Liviu Dudau, Tony Luck, Russell King, linux-pci, x86,
linux-kernel, Xinwei Hu, Thierry Reding, Suravee.Suthikulpanit,
Bjorn Helgaas, linux-ia64, Thomas Gleixner, Wuyun, linuxppc-dev,
Yijing Wang
In-Reply-To: <2447172.ADYWdCTnMP@wuerfel>
On 2014/11/18 17:36, Arnd Bergmann wrote:
> On Tuesday 18 November 2014 15:44:23 Yijing Wang wrote:
>> On 2014/11/17 18:08, Arnd Bergmann wrote:
>>> On Monday 17 November 2014 18:21:35 Yijing Wang wrote:
>>>> - list_for_each_entry(window, resources, list)
>>>> - if (window->res->flags & IORESOURCE_BUS) {
>>>> - found = true;
>>>> - break;
>>>> - }
>>>> + if (!resources) {
>>>> + pci_add_resource(&default_res, &ioport_resource);
>>>> + pci_add_resource(&default_res, &iomem_resource);
>>>> + pci_add_resource(&default_res, &busn_resource);
>>>> + } else {
>>>>
>>>
>>> Isn't it almost always wrong to do this? You are adding all of the
>>> I/O ports and memory to the host bridge, which will prevent you from
>>> adding another host bridge, and the iomem_resource normally
>>> includes a lot of addresses that are not accessible by the PCI host.
>>
>> Hi Arnd, pci host bridge windows are the ranges allow child devices to setup
>> from. Add all of IO/MEM here just a limit to child devices, no request for these
>> resources, so it won't hurt another host bridge. Some platforms have no dts or ACPI
>> report host bridge resources, in this case, we directly assign ioport/iomem_resources
>> as the root resources of PCI devices.
>
> But it would be wrong to allow hosts to allocate a device BAR that is not
> visible through the host bridge. I think we need to keep these separate
> from the general case: if you call any of the modern interfaces you have
> to provide the resources and a device. I notice that there is only one
> caller of pci_scan_bus_parented(), we should probably change that over to
> pci_scan_root_bus() or your new interface and remove the old one, but
> keep pci_scan_bus() as the only entry point for all of the legacy users
> that do not know about the resources.
Ok, I will move this out of the generic interface.
Thanks!
Yijing.
>
> Arnd
>
> .
>
--
Thanks!
Yijing
^ permalink raw reply
* Re: [RFC PATCH 07/16] PCI: Separate pci_host_bridge creation out of pci_create_root_bus()
From: Yijing Wang @ 2014-11-18 11:44 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Liviu Dudau, Tony Luck, Russell King, linux-pci, x86,
linux-kernel, Xinwei Hu, Thierry Reding, Suravee.Suthikulpanit,
Bjorn Helgaas, linux-ia64, Thomas Gleixner, Wuyun, linuxppc-dev,
linux-arm-kernel
In-Reply-To: <1936415.emTbbPeHqx@wuerfel>
On 2014/11/18 17:30, Arnd Bergmann wrote:
> On Tuesday 18 November 2014 16:32:26 Yijing Wang wrote:
>
>>>> +static struct resource busn_resource = {
>>>> + .name = "PCI busn",
>>>> + .start = 0,
>>>> + .end = 255,
>>>> + .flags = IORESOURCE_BUS,
>>>> +};
>>>
>>> I think it would be better to require callers to pass the bus resource
>>> down to the function.
>>
>> Hmm, I think most of caller will provide the bus resource, but some others
>> will not give any bus resource, extremely, no any resources :(. But we still
>> need properly configure their resources for compatibility.
>
> I think that is what the conversion to pci_scan_bus_parented() is about:
> The idea is that we add the correct bus resource to callers of
> pci_scan_bus_parented or pci_scan_bus and then change them to call
> pci_scan_root_bus instead.
It looks good to me, but for simplification, or I will try to use a wrapper to
process the drivers don't pass the busnr resources, and make sure the generic
pci_create_host_bridge() always get the valid resources.
>
>>>> +struct pci_host_bridge *pci_create_host_bridge(
>>>> + struct device *parent, u32 db,
>>>> + struct pci_ops *ops, void *sysdata,
>>>> + struct list_head *resources)
>>>> +{
>>>
>>> Do we still need to pass the 'sysdata' in here? If we are guaranteed to
>>> have a device pointer, we should always be able to get the driver
>>> private data from dev_get_drvdata(host->dev->parent).
>>
>> We need, some platforms pass NULL pointer as host bridge parent.
>
> But those don't have to use the new pci_create_host_bridge() function,
> right?
As I mentioned in another reply, I hope all pci host drivers could use
pci_create_host_bridge(), keep different PCI scan interfaces in PCI core
make things become complex.
>
>>>> + host = kzalloc(sizeof(*host), GFP_KERNEL);
>>>> + if (!host)
>>>> + return NULL;
>>>
>>> devm_kzalloc maybe?
>>
>> I don't know much detail about devm_kzalloc(), but we have no pci host driver
>> here, and I found no devm_kzalloc() uses in core PCI code before.
>
> It also depends on having a valid device pointer. The idea is that the memory
> is automatically freed if the probe() function returns with an error, or
> the device driver gets unloaded. For the classic PCI hosts that are not
> connected to a device, that wouldn't work of course.
>
> Arnd
>
> .
>
--
Thanks!
Yijing
^ permalink raw reply
* Re: [RFC PATCH 00/16] Refine PCI host bridge scan interfaces
From: Lorenzo Pieralisi @ 2014-11-18 11:45 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Liviu Dudau, Tony Luck, Russell King, linux-pci@vger.kernel.org,
x86@kernel.org, linux-kernel@vger.kernel.org, huxinwei@huawei.com,
Bjorn Helgaas, Thierry Reding, suravee.suthikulpanit@amd.com,
Yijing Wang, linux-ia64@vger.kernel.org, Thomas Gleixner, Wuyun,
linuxppc-dev@lists.ozlabs.org,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <20535707.3sA6NjSINh@wuerfel>
On Tue, Nov 18, 2014 at 11:30:11AM +0000, Arnd Bergmann wrote:
> On Tuesday 18 November 2014 19:17:32 Yijing Wang wrote:
> > On 2014/11/17 22:13, Arnd Bergmann wrote:
> > > On Monday 17 November 2014 18:21:34 Yijing Wang wrote:
> > >> This series is based Linux 3.18-rc1 and Lorenzo Pieralisi's
> > >> arm PCI domain cleanup patches, link:
> > >> https://patchwork.ozlabs.org/patch/407585/
> > >>
> > >> Current pci scan interfaces like pci_scan_root_bus() and directly
> > >> call pci_create_root_bus()/pci_scan_child_bus() lack flexiblity.
> > >> Some platform infos like PCI domain and msi_chip have to be
> > >> associated to PCI bus by some arch specific function.
> > >> We want to make a generic pci_host_bridge, and make it hold
> > >> the platform infos or hook. Then we could eliminate the lots
> > >> of arch pci_domain_nr, also we could associate some platform
> > >> ops something like pci_get_msi_chip(struct pci_dev *dev)
> > >> with pci_host_bridge to avoid introduce arch weak functions.
> > >>
> > >> This RFC version not for all platforms, just applied the new
> > >> scan interface in x86/arm/powerpc/ia64, I will refresh other
> > >> platforms after the core pci scan interfaces are ok.
> > >
> > > I think overall this is a good direction to take, in particular
> > > moving more things into struct pci_host_bridge so we can
> > > slim down the architecture specific code.
> >
> > Hi Arnd, thanks very much for your review and comments!
> >
> > >
> > > I don't particularly like the way you use the 'pci_host_info'
> > > to pass callback pointers and some of the generic information.
> > > This duplicates some of the issues we are currently trying
> > > to untangle in the arm32 code to make drivers easier to share
> > > between architectures.
> >
> > What arm32 code you are trying to untangle for example ?
>
> We have a few problems that currently prevent us from using shared
> drivers across arm32 and arm64:
>
> - arm32 has an architecture-defined pci_sys_data structure, but
> we really want to have one that is defined by the host bridge driver
> and that is architecture independent. Some core functions depend
> on this structure at the moment, which Lorenzo is trying to
> undo
Yes, and on this specific point I would like to understand why we
are adding yet more pci_sys_data data in the last series that is
already in -next:
https://lkml.org/lkml/2014/10/27/85
What does this buy us ? The cover letter says already that there *is*
a better solution, why do not we work on that instead of adding more churn
to arch specific code ?
Thanks,
Lorenzo
^ permalink raw reply
* Re: [RFC PATCH 00/16] Refine PCI host bridge scan interfaces
From: Arnd Bergmann @ 2014-11-18 11:30 UTC (permalink / raw)
To: Yijing Wang
Cc: Liviu Dudau, Tony Luck, Russell King, linux-pci, x86,
linux-kernel, Xinwei Hu, Thierry Reding, Suravee.Suthikulpanit,
Bjorn Helgaas, linux-ia64, Thomas Gleixner, Wuyun, linuxppc-dev,
linux-arm-kernel
In-Reply-To: <546B2ACC.90304@huawei.com>
On Tuesday 18 November 2014 19:17:32 Yijing Wang wrote:
> On 2014/11/17 22:13, Arnd Bergmann wrote:
> > On Monday 17 November 2014 18:21:34 Yijing Wang wrote:
> >> This series is based Linux 3.18-rc1 and Lorenzo Pieralisi's
> >> arm PCI domain cleanup patches, link:
> >> https://patchwork.ozlabs.org/patch/407585/
> >>
> >> Current pci scan interfaces like pci_scan_root_bus() and directly
> >> call pci_create_root_bus()/pci_scan_child_bus() lack flexiblity.
> >> Some platform infos like PCI domain and msi_chip have to be
> >> associated to PCI bus by some arch specific function.
> >> We want to make a generic pci_host_bridge, and make it hold
> >> the platform infos or hook. Then we could eliminate the lots
> >> of arch pci_domain_nr, also we could associate some platform
> >> ops something like pci_get_msi_chip(struct pci_dev *dev)
> >> with pci_host_bridge to avoid introduce arch weak functions.
> >>
> >> This RFC version not for all platforms, just applied the new
> >> scan interface in x86/arm/powerpc/ia64, I will refresh other
> >> platforms after the core pci scan interfaces are ok.
> >
> > I think overall this is a good direction to take, in particular
> > moving more things into struct pci_host_bridge so we can
> > slim down the architecture specific code.
>
> Hi Arnd, thanks very much for your review and comments!
>
> >
> > I don't particularly like the way you use the 'pci_host_info'
> > to pass callback pointers and some of the generic information.
> > This duplicates some of the issues we are currently trying
> > to untangle in the arm32 code to make drivers easier to share
> > between architectures.
>
> What arm32 code you are trying to untangle for example ?
We have a few problems that currently prevent us from using shared
drivers across arm32 and arm64:
- arm32 has an architecture-defined pci_sys_data structure, but
we really want to have one that is defined by the host bridge driver
and that is architecture independent. Some core functions depend
on this structure at the moment, which Lorenzo is trying to
undo
- The pci_common_init interface on arm32 doesn't work well on
loadable drivers, it does not return an error, and it is built
around the assumption that you probe all pci host bridges at
the same time, while the standard Linux driver model assumes
that you probe one at a time.
- The way we pass a temporary structure (hw_pci) with function pointers
into the architecture code makes it relatively hard to follow
how the initialization sequence works.
> Introduce pci_host_info here because I want to make the PCI scan interfaces
> simple to host drviers, host drivers only need to call one scan
> interface(pci_scan_host_bridge), but from your comments,
> The combination pci_create_host_bridge() + pci_scan_xx()
> seems to be more popular.
Yes, I think a simpler interface structure would be better than trying
to minimize the amount of code needed in drivers at the expense of
interface complexity.
> > As a general approach, I'd rather see generic helper functions
> > being exported by the PCI core that a driver may or may not
> > call.
> > The way you split the interface between things that happen
> > before scanning the buses (pci_create_host_bridge) and
> > the actual scanning (__pci_create_root_bus, pci_scan_child_bus)
> > seems very helpful and I think we can expand that concept further:
> >
> > - The normal pci_create_host_bridge() function can contain
> > all of the DT scanning functions (finding bus/mem/io resources,
> > finding the msi-parent), while drivers that don't depend on DT
> > for this information can call the same function and fill the
> > same things after they have the pci_host_bridge pointer.
> >
> > - If a driver needs to set up mapping windows, it can do that after
> > calling pci_create_host_bridge(). E.g. all the dw_pcie glue drivers
> > can call a dw_pcie_setup_windows() function that takes the resources
> > out of the pci_host_bridge pointer before the bus is scanned.
> >
> > - The ACPI code can have a completely different way of creating
> > a struct pci_host_bridge, which is also passed into the same
> > bus scanning functions, but doesn't have to come from
> > pci_create_host_bridge.
>
> I hope platforms with ACPI or DT could both use pci_create_host_bridge().
> Why we need to use two different ways to process it ?
These are completely different use cases:
a) For DT, we want loadable device drivers that start by probing a host
bridge device which was added through the DT platform code. The
driver is self-contained, and eventually we want to be able to unload
it. We have lots of different per-soc drivers that require different
quirks
b) For ACPI, the interface is defined in the ACPI spec across architectures
and SoCs, we don't have host bridge drivers and the code that initializes
the PCI is required early during boot and called from architecture
code. There is no parent device, as ACPI sees PCI as a fundamental building
block by itself, and there are no drivers because the firmware does
the initial hardware setup, so we only have to access the config space.
Arnd
^ permalink raw reply
* Re: [RFC PATCH 00/16] Refine PCI host bridge scan interfaces
From: Yijing Wang @ 2014-11-18 11:17 UTC (permalink / raw)
To: Arnd Bergmann, linux-arm-kernel
Cc: Liviu Dudau, Tony Luck, Russell King, linux-pci, x86,
linux-kernel, Xinwei Hu, Thierry Reding, Suravee.Suthikulpanit,
Bjorn Helgaas, linux-ia64, Thomas Gleixner, Wuyun, linuxppc-dev
In-Reply-To: <1463511.o4kE8TX3Bd@wuerfel>
On 2014/11/17 22:13, Arnd Bergmann wrote:
> On Monday 17 November 2014 18:21:34 Yijing Wang wrote:
>> This series is based Linux 3.18-rc1 and Lorenzo Pieralisi's
>> arm PCI domain cleanup patches, link:
>> https://patchwork.ozlabs.org/patch/407585/
>>
>> Current pci scan interfaces like pci_scan_root_bus() and directly
>> call pci_create_root_bus()/pci_scan_child_bus() lack flexiblity.
>> Some platform infos like PCI domain and msi_chip have to be
>> associated to PCI bus by some arch specific function.
>> We want to make a generic pci_host_bridge, and make it hold
>> the platform infos or hook. Then we could eliminate the lots
>> of arch pci_domain_nr, also we could associate some platform
>> ops something like pci_get_msi_chip(struct pci_dev *dev)
>> with pci_host_bridge to avoid introduce arch weak functions.
>>
>> This RFC version not for all platforms, just applied the new
>> scan interface in x86/arm/powerpc/ia64, I will refresh other
>> platforms after the core pci scan interfaces are ok.
>
> I think overall this is a good direction to take, in particular
> moving more things into struct pci_host_bridge so we can
> slim down the architecture specific code.
Hi Arnd, thanks very much for your review and comments!
>
> I don't particularly like the way you use the 'pci_host_info'
> to pass callback pointers and some of the generic information.
> This duplicates some of the issues we are currently trying
> to untangle in the arm32 code to make drivers easier to share
> between architectures.
What arm32 code you are trying to untangle for example ?
Introduce pci_host_info here because I want to make the PCI scan interfaces
simple to host drviers, host drivers only need to call one scan
interface(pci_scan_host_bridge), but from your comments,
The combination pci_create_host_bridge() + pci_scan_xx()
seems to be more popular.
>
> As a general approach, I'd rather see generic helper functions
> being exported by the PCI core that a driver may or may not
> call.
> The way you split the interface between things that happen
> before scanning the buses (pci_create_host_bridge) and
> the actual scanning (__pci_create_root_bus, pci_scan_child_bus)
> seems very helpful and I think we can expand that concept further:
>
> - The normal pci_create_host_bridge() function can contain
> all of the DT scanning functions (finding bus/mem/io resources,
> finding the msi-parent), while drivers that don't depend on DT
> for this information can call the same function and fill the
> same things after they have the pci_host_bridge pointer.
>
> - If a driver needs to set up mapping windows, it can do that after
> calling pci_create_host_bridge(). E.g. all the dw_pcie glue drivers
> can call a dw_pcie_setup_windows() function that takes the resources
> out of the pci_host_bridge pointer before the bus is scanned.
>
> - The ACPI code can have a completely different way of creating
> a struct pci_host_bridge, which is also passed into the same
> bus scanning functions, but doesn't have to come from
> pci_create_host_bridge.
I hope platforms with ACPI or DT could both use pci_create_host_bridge().
Why we need to use two different ways to process it ?
>
> - The PowerPC of_scan_bus function can take the same pci_host_bridge
> pointer that comes from pci_create_host_bridge(), but we'd call
> either pci_create_root_bus or of_scan_bus instead of calling
> of_scan_bus through an indirect pointer from pci_create_root_bus.
>
> Arnd
>
> .
>
--
Thanks!
Yijing
^ permalink raw reply
* Re: [PATCH] of/platform: Move platform devices under /sys/devices/platform
From: Andrzej Hajda @ 2014-11-18 10:36 UTC (permalink / raw)
To: Grant Likely, devicetree, linux-arm-kernel, linux-kernel,
linuxppc-dev
Cc: Greg Kroah-Hartman, Rob Herring, Arnd Bergmann
In-Reply-To: <1415097920-30014-1-git-send-email-grant.likely@linaro.org>
On 11/04/2014 11:45 AM, Grant Likely wrote:
> Currently the devices created by drivers/of/platform.c get created at
> the root of /sys/devices. This goes against the typical pattern for
> sysfs where the top level /sys/devices structure contains categories of
> devices, and the structure of devices is placed below that. To fix this,
> make the code in drivers/of/platform.c follow the drivers/base/platform.c
> behaviour, and use &platform_bus as the default parent for all new
> platform_devices and amba_devices.
>
> This change has been discussed for a long time, but nobody has actually
> acted on it. Userspace code that expects to find devices under a fixed
> /sys/devices/... path will be affected. It isn't /supposed/ to do that,
> but if anyone complains then I'll add a default-off workaround option to
> put them back into the root.
One of side effects of this change is that platform drivers registering
other platform drivers or devices in their probe callback can deadlock
due to double device_lock on platform device. This is for example case
of exynos_drm driver[1]. I guess it could/should be fixed in exynos_drm.
Anyway it can affect other drivers as well. At least grep shows few
possible candidates:
$ git grep -p platform_driver_register | grep -A1 -P '_probe\(struct
platform_device'
drivers/gpu/drm/exynos/exynos_drm_drv.c=static int
exynos_drm_platform_probe(struct platform_device *pdev)
drivers/gpu/drm/exynos/exynos_drm_drv.c: ret =
platform_driver_register(&fimd_driver);
--
drivers/gpu/drm/sti/sti_drm_drv.c=static int
sti_drm_platform_probe(struct platform_device *pdev)
drivers/gpu/drm/sti/sti_drm_drv.c:
platform_driver_register(&sti_drm_master_driver);
--
drivers/mtd/nand/atmel_nand.c=static int atmel_nand_probe(struct
platform_device *pdev)
drivers/mtd/nand/atmel_nand.c: res =
platform_driver_register(&atmel_nand_nfc_driver);
[1]: http://permalink.gmane.org/gmane.comp.video.dri.devel/117727
Regards
Andrzej
>
> Signed-off-by: Grant Likely <grant.likely@linaro.org>
> Cc: Rob Herring <robh+dt@kernel.org>
> Cc: Arnd Bergmann <arnd@arndb.de>
> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> ---
> drivers/of/platform.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/of/platform.c b/drivers/of/platform.c
> index 3b64d0bf5bba..7c6771986c06 100644
> --- a/drivers/of/platform.c
> +++ b/drivers/of/platform.c
> @@ -138,7 +138,7 @@ struct platform_device *of_device_alloc(struct device_node *np,
> }
>
> dev->dev.of_node = of_node_get(np);
> - dev->dev.parent = parent;
> + dev->dev.parent = parent ? : &platform_bus;
>
> if (bus_id)
> dev_set_name(&dev->dev, "%s", bus_id);
> @@ -291,7 +291,7 @@ static struct amba_device *of_amba_device_create(struct device_node *node,
>
> /* setup generic device info */
> dev->dev.of_node = of_node_get(node);
> - dev->dev.parent = parent;
> + dev->dev.parent = parent ? : &platform_bus;
> dev->dev.platform_data = platform_data;
> if (bus_id)
> dev_set_name(&dev->dev, "%s", bus_id);
>
^ permalink raw reply
* RE: [PATCH] powerpc: Remove more traces of bootmem
From: David Laight @ 2014-11-18 10:26 UTC (permalink / raw)
To: 'Michael Ellerman', linuxppc-dev@ozlabs.org
In-Reply-To: <1416293575-1847-1-git-send-email-mpe@ellerman.id.au>
RnJvbTogTWljaGFlbCBFbGxlcm1hbg0KPiBBbHRob3VnaCB3ZSBhcmUgbm93IHNlbGVjdGluZyBO
T19CT09UTUVNLCB3ZSBzdGlsbCBoYXZlIHNvbWUgdHJhY2VzIG9mDQo+IGJvb3RtZW0gbHlpbmcg
YXJvdW5kLiBUaGF0IGlzIGJlY2F1c2UgZXZlbiB3aXRoIE5PX0JPT1RNRU0gdGhlcmUgaXMNCj4g
c3RpbGwgYSBzaGltIHRoYXQgY29udmVydHMgYm9vdG1lbSBjYWxscyBpbnRvIG1lbWJsb2NrIGNh
bGxzLCBidXQNCj4gdWx0aW1hdGVseSB3ZSB3YW50IHRvIHJlbW92ZSBhbGwgdHJhY2VzIG9mIGJv
b3RtZW0uDQo+IA0KPiBNb3N0IG9mIHRoZSBwYXRjaCBpcyBjb252ZXJzaW9ucyBmcm9tIGFsbG9j
X2Jvb3RtZW0oKSB0bw0KPiBtZW1ibG9ja19hbGxvYygpLiBJbiBnZW5lcmFsIGEgY2FsbCBzdWNo
IGFzOg0KPiANCj4gICBwID0gKHN0cnVjdCBmb28gKilhbGxvY19ib290bWVtKHgpOw0KPiANCj4g
QmVjb21lczoNCj4gDQo+ICAgcCA9IF9fdmEobWVtYmxvY2tfYWxsb2MoeCwgMCkpOw0KPiANCj4g
V2UgbmVlZCBfX3ZhKCkgYmVjYXVzZSBtZW1ibG9jayByZXR1cm5zIGEgcGh5c2ljYWwgYWRkcmVz
cy4gV2UgZG9uJ3QNCj4gbmVlZCB0aGUgY2FzdCBiZWNhdXNlIF9fdmEoKSByZXR1cm5zIGEgdm9p
ZCAqLiBUaGUgYWxpZ25tZW50IHZhbHVlIG9mDQo+IHplcm8gdGVsbHMgbWVtYmxvY2sgdG8gdXNl
IHRoZSBkZWZhdWx0IGFsaWdubWVudCwgd2hpY2ggaXMNCj4gU01QX0NBQ0hFX0JZVEVTLCB0aGUg
c2FtZSB2YWx1ZSBhbGxvY19ib290bWVtKCkgdXNlcy4NCg0KSXQgZG9lc24ndCBzZWVtIHJpZ2h0
IHRvIG1lIHRvIHJlcGxpY2F0ZSBfX3ZhKG1lbWJsb2NrX2FsbG9jKHgsIDApKQ0KdGhhdCBtYW55
IHRpbWVzLiBJIGNhbiBpbWFnaW5lIHRoYXQgdGhlIHJlcXVpcmVkIGNvZGUgd2lsbCBjaGFuZ2UN
CmFnYWluIGF0IHRvIGZ1dHVyZSB0aW1lLCBhbmQgdGhlbiBhbGwgdGhlIHNhbWUgcGxhY2VzIHdv
dWxkIG5lZWQgY2hhbmdpbmcuDQoNCldvdWxkbid0IGl0IGJlIGJldHRlciB0byB1c2U6DQojZGVm
aW5lIGFsbG9jX2Jvb3RtZW0oeCkgX192YShtZW1ibG9ja19hbGxvYyh4LCAwKSkNCnBvc3NpYmx5
IHdpdGggYSByZW5hbWUsIG9yIGFzIGEgc3RhdGljIGlubGluZS4NCklmIF9fdmEoKSBpcyBub24t
dHJpdmlhbCB5b3Ugd2FudCBhIHJlYWwgZnVuY3Rpb24uDQoNCglEYXZpZA0KDQo=
^ permalink raw reply
* Re: [PATCH] powerpc: Remove more traces of bootmem
From: Michael Ellerman @ 2014-11-18 10:28 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <1416293575-1847-1-git-send-email-mpe@ellerman.id.au>
On Tue, 2014-11-18 at 17:52 +1100, Michael Ellerman wrote:
> diff --git a/arch/powerpc/platforms/ps3/setup.c b/arch/powerpc/platforms/ps3/setup.c
> index 009a2004b876..86ed156f468f 100644
> --- a/arch/powerpc/platforms/ps3/setup.c
> +++ b/arch/powerpc/platforms/ps3/setup.c
> @@ -125,12 +125,8 @@ static void __init prealloc(struct ps3_prealloc *p)
> if (!p->size)
> return;
>
> - p->address = __alloc_bootmem(p->size, p->align, __pa(MAX_DMA_ADDRESS));
> - if (!p->address) {
> - printk(KERN_ERR "%s: Cannot allocate %s\n", __func__,
> - p->name);
> - return;
> - }
> + p->address = __va(memblock_alloc_base(p->size, p->align,
> + __pa(MAX_DMA_ADDRESS)));
This should be:
> + p->address = __va(memblock_alloc(p->size, p->align));
And a comment in the change log pointing out that MAX_DMA_ADDRESS is ~0ull on
powerpc, so limiting allocations to that is pointless.
cheers
^ permalink raw reply
* Re: [PATCH] [powerpc] Fix Text randomization
From: Michael Ellerman @ 2014-11-18 10:26 UTC (permalink / raw)
To: Vineeth Vijayan; +Cc: linuxppc-dev, linux-kernel, Anton Blanchard
In-Reply-To: <CAOpNGcuL-0SDSwDbExLWqWxwp=0zRtRnx_MUnNEb9ywSFrhh8A@mail.gmail.com>
On Tue, 2014-11-18 at 12:50 +0530, Vineeth Vijayan wrote:
> On Mon, Nov 17, 2014 at 12:23 PM, Michael Ellerman <mpe@ellerman.id.au> wrote:
> > On Fri, 2014-11-14 at 14:42 +0530, Vineeth Vijayan wrote:
> >> Now there is no way to disable TEXT randomization on a PPC32/PPC64
> >> machine. Text randomization happens even in the case of "echo 0 >
> >> /proc/sys/kernel/randomize_va_space"
> >>
> >> This happens due to the incorrect definition of ELF_ET_DYN_BASE
> >> at arch/powerpc/include/asm/elf.h
> >>
> >> The function randomize_et_dyn is redundant and is removed.
> >
> > The patch looks OK, but for the change log I was thinking something more like
> > this:
> >
> >
> > powerpc: Use generic PIE randomization
> >
> Ok. Thats better.
> Do you want me to send a new patch with updated change log as mentioned ?
No that's OK, I've already merged it.
cheers
^ permalink raw reply
* Re: [RFC PATCH 01/16] PCI: Enhance pci_scan_root_bus() to support default IO/MEM resources
From: Arnd Bergmann @ 2014-11-18 9:36 UTC (permalink / raw)
To: linux-arm-kernel
Cc: Liviu Dudau, Tony Luck, Russell King, linux-pci, x86,
linux-kernel, Xinwei Hu, Bjorn Helgaas, Thierry Reding,
Suravee.Suthikulpanit, Yijing Wang, linux-ia64, Thomas Gleixner,
Wuyun, linuxppc-dev, Yijing Wang
In-Reply-To: <546AF8D7.9010103@huawei.com>
On Tuesday 18 November 2014 15:44:23 Yijing Wang wrote:
> On 2014/11/17 18:08, Arnd Bergmann wrote:
> > On Monday 17 November 2014 18:21:35 Yijing Wang wrote:
> >> - list_for_each_entry(window, resources, list)
> >> - if (window->res->flags & IORESOURCE_BUS) {
> >> - found = true;
> >> - break;
> >> - }
> >> + if (!resources) {
> >> + pci_add_resource(&default_res, &ioport_resource);
> >> + pci_add_resource(&default_res, &iomem_resource);
> >> + pci_add_resource(&default_res, &busn_resource);
> >> + } else {
> >>
> >
> > Isn't it almost always wrong to do this? You are adding all of the
> > I/O ports and memory to the host bridge, which will prevent you from
> > adding another host bridge, and the iomem_resource normally
> > includes a lot of addresses that are not accessible by the PCI host.
>
> Hi Arnd, pci host bridge windows are the ranges allow child devices to setup
> from. Add all of IO/MEM here just a limit to child devices, no request for these
> resources, so it won't hurt another host bridge. Some platforms have no dts or ACPI
> report host bridge resources, in this case, we directly assign ioport/iomem_resources
> as the root resources of PCI devices.
But it would be wrong to allow hosts to allocate a device BAR that is not
visible through the host bridge. I think we need to keep these separate
from the general case: if you call any of the modern interfaces you have
to provide the resources and a device. I notice that there is only one
caller of pci_scan_bus_parented(), we should probably change that over to
pci_scan_root_bus() or your new interface and remove the old one, but
keep pci_scan_bus() as the only entry point for all of the legacy users
that do not know about the resources.
Arnd
^ permalink raw reply
* Re: [RFC PATCH 07/16] PCI: Separate pci_host_bridge creation out of pci_create_root_bus()
From: Arnd Bergmann @ 2014-11-18 9:30 UTC (permalink / raw)
To: Yijing Wang
Cc: Liviu Dudau, Tony Luck, Russell King, linux-pci, x86,
linux-kernel, Xinwei Hu, Thierry Reding, Suravee.Suthikulpanit,
Bjorn Helgaas, linux-ia64, Thomas Gleixner, Wuyun, linuxppc-dev,
linux-arm-kernel
In-Reply-To: <546B041A.4060403@huawei.com>
On Tuesday 18 November 2014 16:32:26 Yijing Wang wrote:
> >> +static struct resource busn_resource = {
> >> + .name = "PCI busn",
> >> + .start = 0,
> >> + .end = 255,
> >> + .flags = IORESOURCE_BUS,
> >> +};
> >
> > I think it would be better to require callers to pass the bus resource
> > down to the function.
>
> Hmm, I think most of caller will provide the bus resource, but some others
> will not give any bus resource, extremely, no any resources :(. But we still
> need properly configure their resources for compatibility.
I think that is what the conversion to pci_scan_bus_parented() is about:
The idea is that we add the correct bus resource to callers of
pci_scan_bus_parented or pci_scan_bus and then change them to call
pci_scan_root_bus instead.
> >> +struct pci_host_bridge *pci_create_host_bridge(
> >> + struct device *parent, u32 db,
> >> + struct pci_ops *ops, void *sysdata,
> >> + struct list_head *resources)
> >> +{
> >
> > Do we still need to pass the 'sysdata' in here? If we are guaranteed to
> > have a device pointer, we should always be able to get the driver
> > private data from dev_get_drvdata(host->dev->parent).
>
> We need, some platforms pass NULL pointer as host bridge parent.
But those don't have to use the new pci_create_host_bridge() function,
right?
> >> + host = kzalloc(sizeof(*host), GFP_KERNEL);
> >> + if (!host)
> >> + return NULL;
> >
> > devm_kzalloc maybe?
>
> I don't know much detail about devm_kzalloc(), but we have no pci host driver
> here, and I found no devm_kzalloc() uses in core PCI code before.
It also depends on having a valid device pointer. The idea is that the memory
is automatically freed if the probe() function returns with an error, or
the device driver gets unloaded. For the classic PCI hosts that are not
connected to a device, that wouldn't work of course.
Arnd
^ permalink raw reply
* Re: [RFC PATCH 07/16] PCI: Separate pci_host_bridge creation out of pci_create_root_bus()
From: Yijing Wang @ 2014-11-18 8:32 UTC (permalink / raw)
To: Arnd Bergmann, linuxppc-dev
Cc: Liviu Dudau, Tony Luck, Russell King, linux-pci, x86,
linux-kernel, Xinwei Hu, Thierry Reding, Suravee.Suthikulpanit,
Bjorn Helgaas, linux-ia64, Thomas Gleixner, Wuyun,
linux-arm-kernel
In-Reply-To: <2507218.mHliopJb05@wuerfel>
>> +LIST_HEAD(pci_host_bridge_list);
>> +DECLARE_RWSEM(pci_host_bridge_sem);
>
> Unless the pci_host_bridge_sem is accessed thousands of times per second,
> it's normally better to use a simple mutex instead.
OK, I will use simple mutex instead.
>
>> +static struct resource busn_resource = {
>> + .name = "PCI busn",
>> + .start = 0,
>> + .end = 255,
>> + .flags = IORESOURCE_BUS,
>> +};
>
> I think it would be better to require callers to pass the bus resource
> down to the function.
Hmm, I think most of caller will provide the bus resource, but some others
will not give any bus resource, extremely, no any resources :(. But we still
need properly configure their resources for compatibility.
>
>> +struct pci_host_bridge *pci_create_host_bridge(
>> + struct device *parent, u32 db,
>> + struct pci_ops *ops, void *sysdata,
>> + struct list_head *resources)
>> +{
>
> Do we still need to pass the 'sysdata' in here? If we are guaranteed to
> have a device pointer, we should always be able to get the driver
> private data from dev_get_drvdata(host->dev->parent).
We need, some platforms pass NULL pointer as host bridge parent.
>
>> + host = kzalloc(sizeof(*host), GFP_KERNEL);
>> + if (!host)
>> + return NULL;
>
> devm_kzalloc maybe?
I don't know much detail about devm_kzalloc(), but we have no pci host driver
here, and I found no devm_kzalloc() uses in core PCI code before.
>
>> + if (!resources) {
>> + /* Use default IO/MEM/BUS resources*/
>> + pci_add_resource(&host->windows, &ioport_resource);
>> + pci_add_resource(&host->windows, &iomem_resource);
>> + pci_add_resource(&host->windows, &busn_resource);
>> + } else {
>> + list_for_each_entry_safe(window, n, resources, list)
>> + list_move_tail(&window->list, &host->windows);
>> + }
>
> I think we should assume that the correct resources are passed. You
> could add a wrapper around this function to convert old platforms
> though.
OK, I will move these code out of pci_create_host_bridge, and add a wrapper
to setup the default resources.
>
>> +EXPORT_SYMBOL(pci_create_host_bridge);
>
> EXPORT_SYMBOL_GPL() maybe?
OK, will update it.
>
>> diff --git a/include/linux/pci.h b/include/linux/pci.h
>> index 8b11b38..daa7f40 100644
>> --- a/include/linux/pci.h
>> +++ b/include/linux/pci.h
>> @@ -402,7 +402,12 @@ struct pci_host_bridge_window {
>> struct pci_host_bridge {
>> struct device dev;
>> struct pci_bus *bus; /* root bus */
>> + struct list_head list;
>> struct list_head windows; /* pci_host_bridge_windows */
>> + int busnum;
>
> The busnum should already be implied through the bus resource.
Yes, I will consider remove it and introduce a helper function to get the root bus number, thanks!
Thanks!
Yijing.
>
> Arnd
>
> .
>
--
Thanks!
Yijing
^ permalink raw reply
* Re: [RFC PATCH 01/16] PCI: Enhance pci_scan_root_bus() to support default IO/MEM resources
From: Yijing Wang @ 2014-11-18 7:44 UTC (permalink / raw)
To: Arnd Bergmann, linux-arm-kernel
Cc: Liviu Dudau, Tony Luck, Russell King, linux-pci, x86,
linux-kernel, Xinwei Hu, Thierry Reding, Suravee.Suthikulpanit,
Bjorn Helgaas, linux-ia64, Thomas Gleixner, Wuyun, linuxppc-dev,
Yijing Wang
In-Reply-To: <2732970.7HG94QvVBv@wuerfel>
On 2014/11/17 18:08, Arnd Bergmann wrote:
> On Monday 17 November 2014 18:21:35 Yijing Wang wrote:
>> - list_for_each_entry(window, resources, list)
>> - if (window->res->flags & IORESOURCE_BUS) {
>> - found = true;
>> - break;
>> - }
>> + if (!resources) {
>> + pci_add_resource(&default_res, &ioport_resource);
>> + pci_add_resource(&default_res, &iomem_resource);
>> + pci_add_resource(&default_res, &busn_resource);
>> + } else {
>>
>
> Isn't it almost always wrong to do this? You are adding all of the
> I/O ports and memory to the host bridge, which will prevent you from
> adding another host bridge, and the iomem_resource normally
> includes a lot of addresses that are not accessible by the PCI host.
Hi Arnd, pci host bridge windows are the ranges allow child devices to setup
from. Add all of IO/MEM here just a limit to child devices, no request for these
resources, so it won't hurt another host bridge. Some platforms have no dts or ACPI
report host bridge resources, in this case, we directly assign ioport/iomem_resources
as the root resources of PCI devices.
Thanks!
Yijing.
>
> Arnd
>
> .
>
--
Thanks!
Yijing
^ permalink raw reply
* Re: [PATCH] [powerpc] Fix Text randomization
From: Vineeth Vijayan @ 2014-11-18 7:20 UTC (permalink / raw)
To: Michael Ellerman; +Cc: linuxppc-dev, linux-kernel, Anton Blanchard
In-Reply-To: <1416207214.2826.3.camel@concordia>
On Mon, Nov 17, 2014 at 12:23 PM, Michael Ellerman <mpe@ellerman.id.au> wrote:
> On Fri, 2014-11-14 at 14:42 +0530, Vineeth Vijayan wrote:
>> Now there is no way to disable TEXT randomization on a PPC32/PPC64
>> machine. Text randomization happens even in the case of "echo 0 >
>> /proc/sys/kernel/randomize_va_space"
>>
>> This happens due to the incorrect definition of ELF_ET_DYN_BASE
>> at arch/powerpc/include/asm/elf.h
>>
>> The function randomize_et_dyn is redundant and is removed.
>
> The patch looks OK, but for the change log I was thinking something more like
> this:
>
>
> powerpc: Use generic PIE randomization
>
Ok. Thats better.
Do you want me to send a new patch with updated change log as mentioned ?
^ permalink raw reply
* Re: [PATCH] [powerpc] Fix Text randomization
From: Vineeth Vijayan @ 2014-11-18 7:10 UTC (permalink / raw)
To: Michael Ellerman; +Cc: linuxppc-dev, linux-kernel, Anton Blanchard
In-Reply-To: <1416207214.2826.3.camel@concordia>
[-- Attachment #1: Type: text/plain, Size: 714 bytes --]
On Mon, Nov 17, 2014 at 12:23 PM, Michael Ellerman <mpe@ellerman.id.au>
wrote:
> On Fri, 2014-11-14 at 14:42 +0530, Vineeth Vijayan wrote:
> > Now there is no way to disable TEXT randomization on a PPC32/PPC64
> > machine. Text randomization happens even in the case of "echo 0 >
> > /proc/sys/kernel/randomize_va_space"
> >
> > This happens due to the incorrect definition of ELF_ET_DYN_BASE
> > at arch/powerpc/include/asm/elf.h
> >
> > The function randomize_et_dyn is redundant and is removed.
>
> The patch looks OK, but for the change log I was thinking something more
> like
> this:
>
>
> powerpc: Use generic PIE randomization
>
> Do you want me to send a new patch with updated change log as mentioned ?
[-- Attachment #2: Type: text/html, Size: 1128 bytes --]
^ permalink raw reply
* Re: [PATCH net-next] PPC: bpf_jit_comp: Unify BPF_MOD | BPF_X and BPF_DIV | BPF_X
From: Denis Kirjanov @ 2014-11-18 6:58 UTC (permalink / raw)
To: Michael Ellerman
Cc: Philippe Bergheaud, netdev, Daniel Borkmann, Alexei Starovoitov,
linuxppc-dev
In-Reply-To: <1416275444.1107.4.camel@concordia>
Hi Michael,
This patch added no new functionality so I haven't put the test
results (of course I ran the test suite to check the patch).
The output :
[ 650.198958] test_bpf: Summary: 60 PASSED, 0 FAILED
On 11/18/14, Michael Ellerman <mpe@ellerman.id.au> wrote:
> On Mon, 2014-11-17 at 23:07 +0300, Denis Kirjanov wrote:
>> Reduce duplicated code by unifying
>> BPF_ALU | BPF_MOD | BPF_X and BPF_ALU | BPF_DIV | BPF_X
>>
>> CC: Alexei Starovoitov<alexei.starovoitov@gmail.com>
>> CC: Daniel Borkmann<dborkman@redhat.com>
>> CC: Philippe Bergheaud<felix@linux.vnet.ibm.com>
>> Signed-off-by: Denis Kirjanov <kda@linux-powerpc.org>
>
> Please include the output of the test suite.
>
> Assuming that's OK I'm happy for it to go in.
>
> cheers
>
>
>
>
^ permalink raw reply
* [PATCH] cpuidle/powernv: Re-enable fastsleep at boot time
From: Preeti U Murthy @ 2014-11-18 6:56 UTC (permalink / raw)
To: mpe, mikey, joel.stanley; +Cc: linuxppc-dev, linux-kernel, rjw
Commit dcb18694 "Fix ipi on palmeto" disabled fastsleep at boot time.
Revert this commit since we no longer need this fix. However we can
continue to use powersave_nap parameter to control entry into deep
idle states beyond snooze.
Signed-off-by: Preeti U. Murthy <preeti@linux.vnet.ibm.com>
---
drivers/cpuidle/cpuidle-powernv.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/cpuidle/cpuidle-powernv.c b/drivers/cpuidle/cpuidle-powernv.c
index b57681d..b430e76 100644
--- a/drivers/cpuidle/cpuidle-powernv.c
+++ b/drivers/cpuidle/cpuidle-powernv.c
@@ -69,8 +69,9 @@ static int fastsleep_loop(struct cpuidle_device *dev,
unsigned long old_lpcr = mfspr(SPRN_LPCR);
unsigned long new_lpcr;
- if (powersave_nap < 2)
- return;
+ if (!(powersave_nap > 0))
+ return index;
+
if (unlikely(system_state < SYSTEM_RUNNING))
return index;
^ permalink raw reply related
* [PATCH] powerpc: Remove more traces of bootmem
From: Michael Ellerman @ 2014-11-18 6:52 UTC (permalink / raw)
To: linuxppc-dev
Although we are now selecting NO_BOOTMEM, we still have some traces of
bootmem lying around. That is because even with NO_BOOTMEM there is
still a shim that converts bootmem calls into memblock calls, but
ultimately we want to remove all traces of bootmem.
Most of the patch is conversions from alloc_bootmem() to
memblock_alloc(). In general a call such as:
p = (struct foo *)alloc_bootmem(x);
Becomes:
p = __va(memblock_alloc(x, 0));
We need __va() because memblock returns a physical address. We don't
need the cast because __va() returns a void *. The alignment value of
zero tells memblock to use the default alignment, which is
SMP_CACHE_BYTES, the same value alloc_bootmem() uses.
We also remove a number of NULL checks on the result of memblock_alloc().
That is because memblock_alloc() will panic if it can't allocate, in
exactly the same way as alloc_bootmem(), so the NULL checks are and
always have been redundant.
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
---
arch/powerpc/kernel/pci-common.c | 1 -
arch/powerpc/kernel/pci_32.c | 6 ++----
arch/powerpc/kernel/setup_64.c | 2 +-
arch/powerpc/lib/alloc.c | 7 +++----
arch/powerpc/mm/hugetlbpage.c | 3 +--
arch/powerpc/mm/mmu_context_nohash.c | 10 +++++-----
arch/powerpc/mm/numa.c | 2 +-
arch/powerpc/platforms/cell/celleb_pci.c | 6 +++---
arch/powerpc/platforms/powermac/nvram.c | 8 ++------
arch/powerpc/platforms/powernv/pci-ioda.c | 12 ++++--------
arch/powerpc/platforms/powernv/pci-p5ioc2.c | 19 ++++++-------------
arch/powerpc/platforms/ps3/setup.c | 10 +++-------
arch/powerpc/sysdev/fsl_pci.c | 1 -
13 files changed, 31 insertions(+), 56 deletions(-)
diff --git a/arch/powerpc/kernel/pci-common.c b/arch/powerpc/kernel/pci-common.c
index bc2dab52a991..37d512d35943 100644
--- a/arch/powerpc/kernel/pci-common.c
+++ b/arch/powerpc/kernel/pci-common.c
@@ -20,7 +20,6 @@
#include <linux/pci.h>
#include <linux/string.h>
#include <linux/init.h>
-#include <linux/bootmem.h>
#include <linux/delay.h>
#include <linux/export.h>
#include <linux/of_address.h>
diff --git a/arch/powerpc/kernel/pci_32.c b/arch/powerpc/kernel/pci_32.c
index 432459c817fa..bf156230a16f 100644
--- a/arch/powerpc/kernel/pci_32.c
+++ b/arch/powerpc/kernel/pci_32.c
@@ -10,7 +10,7 @@
#include <linux/capability.h>
#include <linux/sched.h>
#include <linux/errno.h>
-#include <linux/bootmem.h>
+#include <linux/memblock.h>
#include <linux/irq.h>
#include <linux/list.h>
#include <linux/of.h>
@@ -199,9 +199,7 @@ pci_create_OF_bus_map(void)
struct property* of_prop;
struct device_node *dn;
- of_prop = (struct property*) alloc_bootmem(sizeof(struct property) + 256);
- if (!of_prop)
- return;
+ of_prop = __va(memblock_alloc(sizeof(struct property) + 256, 0));
dn = of_find_node_by_path("/");
if (dn) {
memset(of_prop, -1, sizeof(struct property) + 256);
diff --git a/arch/powerpc/kernel/setup_64.c b/arch/powerpc/kernel/setup_64.c
index 6e5310ddf8c7..49f553bbb360 100644
--- a/arch/powerpc/kernel/setup_64.c
+++ b/arch/powerpc/kernel/setup_64.c
@@ -660,7 +660,7 @@ static void __init emergency_stack_init(void)
}
/*
- * Called into from start_kernel this initializes bootmem, which is used
+ * Called into from start_kernel this initializes memblock, which is used
* to manage page allocation until mem_init is called.
*/
void __init setup_arch(char **cmdline_p)
diff --git a/arch/powerpc/lib/alloc.c b/arch/powerpc/lib/alloc.c
index da22c84a8fed..633d7af89699 100644
--- a/arch/powerpc/lib/alloc.c
+++ b/arch/powerpc/lib/alloc.c
@@ -1,7 +1,7 @@
#include <linux/types.h>
#include <linux/init.h>
#include <linux/slab.h>
-#include <linux/bootmem.h>
+#include <linux/memblock.h>
#include <linux/string.h>
#include <asm/setup.h>
@@ -13,9 +13,8 @@ void * __init_refok zalloc_maybe_bootmem(size_t size, gfp_t mask)
if (mem_init_done)
p = kzalloc(size, mask);
else {
- p = alloc_bootmem(size);
- if (p)
- memset(p, 0, size);
+ p = __va(memblock_alloc(size, 0));
+ memset(p, 0, size);
}
return p;
}
diff --git a/arch/powerpc/mm/hugetlbpage.c b/arch/powerpc/mm/hugetlbpage.c
index af56de82375d..df4eb786d98e 100644
--- a/arch/powerpc/mm/hugetlbpage.c
+++ b/arch/powerpc/mm/hugetlbpage.c
@@ -15,7 +15,6 @@
#include <linux/export.h>
#include <linux/of_fdt.h>
#include <linux/memblock.h>
-#include <linux/bootmem.h>
#include <linux/moduleparam.h>
#include <asm/pgtable.h>
#include <asm/pgalloc.h>
@@ -315,7 +314,7 @@ int alloc_bootmem_huge_page(struct hstate *hstate)
* If gpages can be in highmem we can't use the trick of storing the
* data structure in the page; allocate space for this
*/
- m = alloc_bootmem(sizeof(struct huge_bootmem_page));
+ m = __va(memblock_alloc(sizeof(struct huge_bootmem_page), 0));
m->phys = gpage_freearray[idx].gpage_list[--nr_gpages];
#else
m = phys_to_virt(gpage_freearray[idx].gpage_list[--nr_gpages]);
diff --git a/arch/powerpc/mm/mmu_context_nohash.c b/arch/powerpc/mm/mmu_context_nohash.c
index 928ebe79668b..8810bd8531ed 100644
--- a/arch/powerpc/mm/mmu_context_nohash.c
+++ b/arch/powerpc/mm/mmu_context_nohash.c
@@ -44,7 +44,7 @@
#include <linux/mm.h>
#include <linux/init.h>
#include <linux/spinlock.h>
-#include <linux/bootmem.h>
+#include <linux/memblock.h>
#include <linux/notifier.h>
#include <linux/cpu.h>
#include <linux/slab.h>
@@ -421,12 +421,12 @@ void __init mmu_context_init(void)
/*
* Allocate the maps used by context management
*/
- context_map = alloc_bootmem(CTX_MAP_SIZE);
- context_mm = alloc_bootmem(sizeof(void *) * (last_context + 1));
+ context_map = __va(memblock_alloc(CTX_MAP_SIZE, 0));
+ context_mm = __va(memblock_alloc(sizeof(void *) * (last_context + 1), 0));
#ifndef CONFIG_SMP
- stale_map[0] = alloc_bootmem(CTX_MAP_SIZE);
+ stale_map[0] = __va(memblock_alloc(CTX_MAP_SIZE, 0));
#else
- stale_map[boot_cpuid] = alloc_bootmem(CTX_MAP_SIZE);
+ stale_map[boot_cpuid] = __va(memblock_alloc(CTX_MAP_SIZE, 0));
register_cpu_notifier(&mmu_context_cpu_nb);
#endif
diff --git a/arch/powerpc/mm/numa.c b/arch/powerpc/mm/numa.c
index 417b0a523a47..aba064a17637 100644
--- a/arch/powerpc/mm/numa.c
+++ b/arch/powerpc/mm/numa.c
@@ -11,7 +11,6 @@
#define pr_fmt(fmt) "numa: " fmt
#include <linux/threads.h>
-#include <linux/bootmem.h>
#include <linux/init.h>
#include <linux/mm.h>
#include <linux/mmzone.h>
@@ -19,6 +18,7 @@
#include <linux/nodemask.h>
#include <linux/cpu.h>
#include <linux/notifier.h>
+#include <linux/bootmem.h>
#include <linux/memblock.h>
#include <linux/of.h>
#include <linux/pfn.h>
diff --git a/arch/powerpc/platforms/cell/celleb_pci.c b/arch/powerpc/platforms/cell/celleb_pci.c
index 2b98a36ef8fb..3ce70ded2d6a 100644
--- a/arch/powerpc/platforms/cell/celleb_pci.c
+++ b/arch/powerpc/platforms/cell/celleb_pci.c
@@ -29,7 +29,7 @@
#include <linux/pci.h>
#include <linux/string.h>
#include <linux/init.h>
-#include <linux/bootmem.h>
+#include <linux/memblock.h>
#include <linux/pci_regs.h>
#include <linux/of.h>
#include <linux/of_device.h>
@@ -401,11 +401,11 @@ error:
} else {
if (config && *config) {
size = 256;
- free_bootmem(__pa(*config), size);
+ memblock_free(__pa(*config), size);
}
if (res && *res) {
size = sizeof(struct celleb_pci_resource);
- free_bootmem(__pa(*res), size);
+ memblock_free(__pa(*res), size);
}
}
diff --git a/arch/powerpc/platforms/powermac/nvram.c b/arch/powerpc/platforms/powermac/nvram.c
index 014d06e6d46b..74541254e1a9 100644
--- a/arch/powerpc/platforms/powermac/nvram.c
+++ b/arch/powerpc/platforms/powermac/nvram.c
@@ -18,7 +18,7 @@
#include <linux/errno.h>
#include <linux/adb.h>
#include <linux/pmu.h>
-#include <linux/bootmem.h>
+#include <linux/memblock.h>
#include <linux/completion.h>
#include <linux/spinlock.h>
#include <asm/sections.h>
@@ -513,11 +513,7 @@ static int __init core99_nvram_setup(struct device_node *dp, unsigned long addr)
printk(KERN_ERR "nvram: no address\n");
return -EINVAL;
}
- nvram_image = alloc_bootmem(NVRAM_SIZE);
- if (nvram_image == NULL) {
- printk(KERN_ERR "nvram: can't allocate ram image\n");
- return -ENOMEM;
- }
+ nvram_image = __va(memblock_alloc(NVRAM_SIZE, 0));
nvram_data = ioremap(addr, NVRAM_SIZE*2);
nvram_naddrs = 1; /* Make sure we get the correct case */
diff --git a/arch/powerpc/platforms/powernv/pci-ioda.c b/arch/powerpc/platforms/powernv/pci-ioda.c
index d03503515692..c95af005e82c 100644
--- a/arch/powerpc/platforms/powernv/pci-ioda.c
+++ b/arch/powerpc/platforms/powernv/pci-ioda.c
@@ -18,7 +18,7 @@
#include <linux/delay.h>
#include <linux/string.h>
#include <linux/init.h>
-#include <linux/bootmem.h>
+#include <linux/memblock.h>
#include <linux/irq.h>
#include <linux/io.h>
#include <linux/msi.h>
@@ -1940,11 +1940,7 @@ static void __init pnv_pci_init_ioda_phb(struct device_node *np,
phb_id = be64_to_cpup(prop64);
pr_debug(" PHB-ID : 0x%016llx\n", phb_id);
- phb = alloc_bootmem(sizeof(struct pnv_phb));
- if (!phb) {
- pr_err(" Out of memory !\n");
- return;
- }
+ phb = __va(memblock_alloc(sizeof(struct pnv_phb), 0));
/* Allocate PCI controller */
memset(phb, 0, sizeof(struct pnv_phb));
@@ -1952,7 +1948,7 @@ static void __init pnv_pci_init_ioda_phb(struct device_node *np,
if (!phb->hose) {
pr_err(" Can't allocate PCI controller for %s\n",
np->full_name);
- free_bootmem((unsigned long)phb, sizeof(struct pnv_phb));
+ memblock_free(__pa(phb), sizeof(struct pnv_phb));
return;
}
@@ -2019,7 +2015,7 @@ static void __init pnv_pci_init_ioda_phb(struct device_node *np,
}
pemap_off = size;
size += phb->ioda.total_pe * sizeof(struct pnv_ioda_pe);
- aux = alloc_bootmem(size);
+ aux = __va(memblock_alloc(size, 0));
memset(aux, 0, size);
phb->ioda.pe_alloc = aux;
phb->ioda.m32_segmap = aux + m32map_off;
diff --git a/arch/powerpc/platforms/powernv/pci-p5ioc2.c b/arch/powerpc/platforms/powernv/pci-p5ioc2.c
index 3336fcbdd08a..0282d9d6b58e 100644
--- a/arch/powerpc/platforms/powernv/pci-p5ioc2.c
+++ b/arch/powerpc/platforms/powernv/pci-p5ioc2.c
@@ -16,7 +16,7 @@
#include <linux/delay.h>
#include <linux/string.h>
#include <linux/init.h>
-#include <linux/bootmem.h>
+#include <linux/memblock.h>
#include <linux/irq.h>
#include <linux/io.h>
#include <linux/msi.h>
@@ -122,12 +122,10 @@ static void __init pnv_pci_init_p5ioc2_phb(struct device_node *np, u64 hub_id,
return;
}
- phb = alloc_bootmem(sizeof(struct pnv_phb));
- if (phb) {
- memset(phb, 0, sizeof(struct pnv_phb));
- phb->hose = pcibios_alloc_controller(np);
- }
- if (!phb || !phb->hose) {
+ phb = __va(memblock_alloc(sizeof(struct pnv_phb), 0));
+ memset(phb, 0, sizeof(struct pnv_phb));
+ phb->hose = pcibios_alloc_controller(np);
+ if (!phb->hose) {
pr_err(" Failed to allocate PCI controller\n");
return;
}
@@ -216,12 +214,7 @@ void __init pnv_pci_init_p5ioc2_hub(struct device_node *np)
*
* XXX TODO: Make it chip local if possible
*/
- tce_mem = __alloc_bootmem(P5IOC2_TCE_MEMORY, P5IOC2_TCE_MEMORY,
- __pa(MAX_DMA_ADDRESS));
- if (!tce_mem) {
- pr_err(" Failed to allocate TCE Memory !\n");
- return;
- }
+ tce_mem = __va(memblock_alloc(P5IOC2_TCE_MEMORY, P5IOC2_TCE_MEMORY));
pr_debug(" TCE : 0x%016lx..0x%016lx\n",
__pa(tce_mem), __pa(tce_mem) + P5IOC2_TCE_MEMORY - 1);
rc = opal_pci_set_hub_tce_memory(hub_id, __pa(tce_mem),
diff --git a/arch/powerpc/platforms/ps3/setup.c b/arch/powerpc/platforms/ps3/setup.c
index 009a2004b876..86ed156f468f 100644
--- a/arch/powerpc/platforms/ps3/setup.c
+++ b/arch/powerpc/platforms/ps3/setup.c
@@ -24,7 +24,7 @@
#include <linux/root_dev.h>
#include <linux/console.h>
#include <linux/export.h>
-#include <linux/bootmem.h>
+#include <linux/memblock.h>
#include <asm/machdep.h>
#include <asm/firmware.h>
@@ -125,12 +125,8 @@ static void __init prealloc(struct ps3_prealloc *p)
if (!p->size)
return;
- p->address = __alloc_bootmem(p->size, p->align, __pa(MAX_DMA_ADDRESS));
- if (!p->address) {
- printk(KERN_ERR "%s: Cannot allocate %s\n", __func__,
- p->name);
- return;
- }
+ p->address = __va(memblock_alloc_base(p->size, p->align,
+ __pa(MAX_DMA_ADDRESS)));
printk(KERN_INFO "%s: %lu bytes at %p\n", p->name, p->size,
p->address);
diff --git a/arch/powerpc/sysdev/fsl_pci.c b/arch/powerpc/sysdev/fsl_pci.c
index d8484d7cffaa..6455c1eada1a 100644
--- a/arch/powerpc/sysdev/fsl_pci.c
+++ b/arch/powerpc/sysdev/fsl_pci.c
@@ -23,7 +23,6 @@
#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>
--
1.9.1
^ permalink raw reply related
* Re: [powerpc] init nvram_pstore_info's buf_lock
From: Li Zhong @ 2014-11-18 6:12 UTC (permalink / raw)
To: Michael Ellerman; +Cc: Paul Mackerras, PowerPC email list
In-Reply-To: <20141118043314.4517C14011D@ozlabs.org>
On 二, 2014-11-18 at 15:33 +1100, Michael Ellerman wrote:
> On Mon, 2014-17-11 at 02:52:30 UTC, Li Zhong wrote:
> > It seems nvram_pstore_info's buf_lock is not initialized before
> > registering, which causes some strange behavior when trying to obtain
> > the lock during kdump process.
>
> What kind of strange behaviour? Does it still work and just print a warning?
>
> It's static, so I'd expect it to be unlocked by default.
Yes, you are right. It still works.
I saw it on a UP configuration, noticed the console stopped for a couple
of seconds, then "lockup suspected" warning printed out, but then it
continued to run.
After some further checking, it seems working as designed for the UP
spinlock debug, from the comments in spinlock_up.h
* In the debug case, 1 means unlocked, 0 means locked. (the values
* are inverted, to catch initialization bugs)
So try lock fails, and lockup reported, but then arch_spin_lock()
passes.
Thanks, Zhong
>
> cheers
>
^ permalink raw reply
* Re: [RFC 11/11] powerpc: kvm: Kconfig add an option for enabling secondary hwthread
From: Liu ping fan @ 2014-11-18 5:47 UTC (permalink / raw)
To: Preeti U Murthy; +Cc: Paul Mackerras, linuxppc-dev, Alexander Graf, kvm-ppc
In-Reply-To: <544DE9B0.2050500@linux.vnet.ibm.com>
On Mon, Oct 27, 2014 at 2:44 PM, Preeti U Murthy
<preeti@linux.vnet.ibm.com> wrote:
> On 10/17/2014 01:00 AM, kernelfans@gmail.com wrote:
>> Signed-off-by: Liu Ping Fan <pingfank@linux.vnet.ibm.com>
>> ---
>> arch/powerpc/kvm/Kconfig | 4 ++++
>> 1 file changed, 4 insertions(+)
>>
>> diff --git a/arch/powerpc/kvm/Kconfig b/arch/powerpc/kvm/Kconfig
>> index 602eb51..de38566 100644
>> --- a/arch/powerpc/kvm/Kconfig
>> +++ b/arch/powerpc/kvm/Kconfig
>> @@ -93,6 +93,10 @@ config KVM_BOOK3S_64_HV
>>
>> If unsure, say N.
>>
>> +config KVMPPC_ENABLE_SECONDARY
>> + tristate "KVM support for running on secondary hwthread in host"
>> + depends on KVM_BOOK3S_64_HV
>
> This patch is required ontop of all the rest :) The top patches won't
> compile without this one. Every patch in the patchset should be able to
> compile successfully without the aid of the patches that come after it.
>
I think here is a conflict. If we do so, then we should make effort to
prevent the independent patch to take effect before the whole patchset
is applied.
Thx,
Fan
> Regards
> Preeti U Murthy
>
^ permalink raw reply
* Re: [RFC 09/11] powerpc: kvm: handle time base on secondary hwthread
From: Liu ping fan @ 2014-11-18 5:43 UTC (permalink / raw)
To: Preeti U Murthy; +Cc: Paul Mackerras, linuxppc-dev, Alexander Graf, kvm-ppc
In-Reply-To: <544DE8F9.5070100@linux.vnet.ibm.com>
On Mon, Oct 27, 2014 at 2:40 PM, Preeti U Murthy
<preeti@linux.vnet.ibm.com> wrote:
> On 10/17/2014 12:59 AM, kernelfans@gmail.com wrote:
>> (This is a place holder patch.)
>> We need to store the time base for host on secondary hwthread.
>> Later when switching back, we need to reprogram it with elapse
>> time.
>>
>> Signed-off-by: Liu Ping Fan <pingfank@linux.vnet.ibm.com>
>> ---
>> arch/powerpc/kvm/book3s_hv_rmhandlers.S | 6 ++++++
>> 1 file changed, 6 insertions(+)
>>
>> diff --git a/arch/powerpc/kvm/book3s_hv_rmhandlers.S b/arch/powerpc/kvm/book3s_hv_rmhandlers.S
>> index 89ea16c..a817ba6 100644
>> --- a/arch/powerpc/kvm/book3s_hv_rmhandlers.S
>> +++ b/arch/powerpc/kvm/book3s_hv_rmhandlers.S
>> @@ -371,6 +371,8 @@ _GLOBAL_TOC(kvmppc_secondary_stopper_enter)
>>
>> /* fixme: store other register such as msr */
>>
>> + /* fixme: store the tb, and set it as MAX, so we cease the tick on secondary */
>
> This can lead to serious consequences. First of all, even if we set the
> decrementer(not tb) to MAX, it is bound to fire after 4s. That is the
> maximum time till which you can keep off the decrementer from firing.
>
> In the hotplug path, the offline cpus nap and their decrementers are
> programmed to fire at MAX too. But the difference is that we clear the
> LPCR_PECE1 wakeup bit which prevents cpus from waking up on a
> decrementer interrupt.
>
> We cannot afford to do this here though because there are other tasks on
> the secondary threads' runqueue. They need to be scheduled in.
> There are also timers besides the tick_sched one, which can be queued on
> these secondary threads. These patches have not taken care to migrate
> timers or tasks before entering guest as far as I observed. Hence we
> cannot just turn off time base like this and expect to handle the above
> mentioned events the next time the primary thread decides to exit to the
> host.
>
Yes, that is the nut in this series. My plan is to compensate the
hrtimer when the secondary exit.
But as to the scheduler on secondary, if it is ceased, what is side-effect?
Thx,
Fan
> Regards
> Preeti U Murthy
>> +
>> /* prevent us to enter kernel */
>> li r0, 1
>> stb r0, HSTATE_HWTHREAD_REQ(r13)
>> @@ -382,6 +384,10 @@ _GLOBAL_TOC(kvmppc_secondary_stopper_enter)
>>
>> /* enter with vmode */
>> kvmppc_secondary_stopper_exit:
>> + /* fixme: restore the tb, with the orig val plus time elapse
>> + * so we can fire the hrtimer as soon as possible
>> + */
>> +
>> /* fixme, restore the stack which we store on lpaca */
>>
>> ld r0, 112+PPC_LR_STKOFF(r1)
>>
>
^ permalink raw reply
* Re: [RFC 06/11] powerpc: kvm: introduce online in paca to indicate whether cpu is needed by host
From: Liu ping fan @ 2014-11-18 5:29 UTC (permalink / raw)
To: Preeti U Murthy; +Cc: Paul Mackerras, linuxppc-dev, Alexander Graf, kvm-ppc
In-Reply-To: <544DD8EC.6050403@linux.vnet.ibm.com>
On Mon, Oct 27, 2014 at 1:32 PM, Preeti U Murthy
<preeti@linux.vnet.ibm.com> wrote:
> Hi Liu,
>
> On 10/17/2014 12:59 AM, kernelfans@gmail.com wrote:
>> Nowadays, powerKVM runs with secondary hwthread offline. Although
>> we can make all secondary hwthread online later, we still preserve
>> this behavior for dedicated KVM env. Achieve this by setting
>> paca->online as false.
>>
>> Signed-off-by: Liu Ping Fan <pingfank@linux.vnet.ibm.com>
>> ---
>> arch/powerpc/include/asm/paca.h | 3 +++
>> arch/powerpc/kernel/asm-offsets.c | 3 +++
>> arch/powerpc/kernel/smp.c | 3 +++
>> arch/powerpc/kvm/book3s_hv_rmhandlers.S | 12 ++++++++++++
>> 4 files changed, 21 insertions(+)
>>
>> diff --git a/arch/powerpc/include/asm/paca.h b/arch/powerpc/include/asm/paca.h
>> index a5139ea..67c2500 100644
>> --- a/arch/powerpc/include/asm/paca.h
>> +++ b/arch/powerpc/include/asm/paca.h
>> @@ -84,6 +84,9 @@ struct paca_struct {
>> u8 cpu_start; /* At startup, processor spins until */
>> /* this becomes non-zero. */
>> u8 kexec_state; /* set when kexec down has irqs off */
>> +#ifdef CONFIG_KVMPPC_ENABLE_SECONDARY
>> + u8 online;
>> +#endif
>> #ifdef CONFIG_PPC_STD_MMU_64
>> struct slb_shadow *slb_shadow_ptr;
>> struct dtl_entry *dispatch_log;
>> diff --git a/arch/powerpc/kernel/asm-offsets.c b/arch/powerpc/kernel/asm-offsets.c
>> index 9d7dede..0faa8fe 100644
>> --- a/arch/powerpc/kernel/asm-offsets.c
>> +++ b/arch/powerpc/kernel/asm-offsets.c
>> @@ -182,6 +182,9 @@ int main(void)
>> DEFINE(PACATOC, offsetof(struct paca_struct, kernel_toc));
>> DEFINE(PACAKBASE, offsetof(struct paca_struct, kernelbase));
>> DEFINE(PACAKMSR, offsetof(struct paca_struct, kernel_msr));
>> +#ifdef CONFIG_KVMPPC_ENABLE_SECONDARY
>> + DEFINE(PACAONLINE, offsetof(struct paca_struct, online));
>> +#endif
>> DEFINE(PACASOFTIRQEN, offsetof(struct paca_struct, soft_enabled));
>> DEFINE(PACAIRQHAPPENED, offsetof(struct paca_struct, irq_happened));
>> DEFINE(PACACONTEXTID, offsetof(struct paca_struct, context.id));
>> diff --git a/arch/powerpc/kernel/smp.c b/arch/powerpc/kernel/smp.c
>> index a0738af..4c3843e 100644
>> --- a/arch/powerpc/kernel/smp.c
>> +++ b/arch/powerpc/kernel/smp.c
>> @@ -736,6 +736,9 @@ void start_secondary(void *unused)
>>
>> cpu_startup_entry(CPUHP_ONLINE);
>>
>> +#ifdef CONFIG_KVMPPC_ENABLE_SECONDARY
>> + get_paca()->online = true;
>> +#endif
>> BUG();
>> }
>>
>> diff --git a/arch/powerpc/kvm/book3s_hv_rmhandlers.S b/arch/powerpc/kvm/book3s_hv_rmhandlers.S
>> index f0c4db7..d5594b0 100644
>> --- a/arch/powerpc/kvm/book3s_hv_rmhandlers.S
>> +++ b/arch/powerpc/kvm/book3s_hv_rmhandlers.S
>> @@ -322,6 +322,13 @@ kvm_no_guest:
>> li r0, KVM_HWTHREAD_IN_NAP
>> stb r0, HSTATE_HWTHREAD_STATE(r13)
>> kvm_do_nap:
>> +#ifdef PPCKVM_ENABLE_SECONDARY
>> + /* check the cpu is needed by host or not */
>> + ld r2, PACAONLINE(r13)
>> + ld r3, 0
>> + cmp r2, r3
>> + bne kvm_secondary_exit_trampoline
>> +#endif
>> /* Clear the runlatch bit before napping */
>> mfspr r2, SPRN_CTRLF
>> clrrdi r2, r2, 1
>> @@ -340,6 +347,11 @@ kvm_do_nap:
>> nap
>> b .
>>
>> +#ifdef PPCKVM_ENABLE_SECONDARY
>> +kvm_secondary_exit_trampoline:
>> + b .
>
> Uh? When we have no vcpu to run, we loop here instead of doing a nap?
> What are we achieving?
>
> If I understand the intention of the patch well, we are looking to
> provide a knob whereby the host can indicate if it needs the secondaries
> at all.
>
Yes, you catch it :)
> Today the host does boot with all threads online. There are some init
> scripts which take the secondaries down. So today the host does not have
> a say in preventing this, compile time or runtime. So lets see how we
> can switch between the two behaviors if we don't have the init script,
> which looks like a saner thing to do.
>
> We should set the paca->online flag to false by default. If
> KVM_PPC_ENABLE_SECONDARY is configured, we need to set this flag to
> true. So at compile time, we resolve the flag.
>
> While booting, we look at the flag and decide whether to get the
> secondaries online. So we get the current behavior if we have not
> configured KVM_PPC_ENABLE_SECONDARY. Will this achieve the purpose of
> this patch?
>
At boot time, KVM can not run. So we can achieve the change of the
flag by soft cpu hotplug on/off.
I think this is a more flexible way.
Thx,
Fan
> Regards
> Preeti U Murthy
>
^ permalink raw reply
* Re: [RFC 04/11] powerpc: kvm: introduce a kthread on primary thread to anti tickless
From: Liu ping fan @ 2014-11-18 5:24 UTC (permalink / raw)
To: Preeti U Murthy; +Cc: Paul Mackerras, linuxppc-dev, Alexander Graf, kvm-ppc
In-Reply-To: <544DCDD0.2080508@linux.vnet.ibm.com>
On Mon, Oct 27, 2014 at 12:45 PM, Preeti U Murthy
<preeti@linux.vnet.ibm.com> wrote:
> On 10/17/2014 12:59 AM, kernelfans@gmail.com wrote:
>> (This patch is a place holder.)
>>
>> If there is only one vcpu thread is ready(the other vcpu thread can
>> wait for it to execute), the primary thread can enter tickless mode,
>
> We do not configure NOHZ_FULL to y by default. Hence no thread would
> enter tickless mode.
>
But NOHZ_FULL can be chosen by user, and we should survive from it :)
>> which causes the primary keeps running, so the secondary has no
>> opportunity to exit to host, even they have other tsk on them.
>
> The secondary threads can still get scheduling ticks. The decrementer of
> the secondary threads is still active. So as long as secondary threads
> are busy, scheduling ticks will fire and try to schedule a new task on them.
>
No. As my original thought, after enable KVM on core, the HDEC on
secondary is disabled, otherwise the host exit will be too frequent.
Any suggestion?
Thx,
Fan
> Regards
> Preeti U Murthy
>>
>> Introduce a kthread (anti_tickless) on primary, so when there is only
>> one vcpu thread on primary, the secondary can resort to anti_tickless
>> to keep the primary out of tickless mode.
>> (I thought that anti_tickless thread can goto NAP, so we can let the
>> secondary run).
>>
>> Signed-off-by: Liu Ping Fan <pingfank@linux.vnet.ibm.com>
>> ---
>> arch/powerpc/kernel/sysfs.c | 4 +++-
>> 1 file changed, 3 insertions(+), 1 deletion(-)
>>
>> diff --git a/arch/powerpc/kernel/sysfs.c b/arch/powerpc/kernel/sysfs.c
>> index a2595dd..f0b110e 100644
>> --- a/arch/powerpc/kernel/sysfs.c
>> +++ b/arch/powerpc/kernel/sysfs.c
>> @@ -575,9 +575,11 @@ static ssize_t __used store_kvm_enable(struct device *dev,
>> if (!test_bit(core, &kvm_on_core))
>> for (thr = 1; thr< threads_per_core; thr++)
>> if (cpu_online(thr * threads_per_core + thr))
>> - cpumask_set_cpu(thr * threads_per_core + thr, &stop_cpus);
>> + cpumask_set_cpu(core * threads_per_core + thr, &stop_cpus);
>>
>> stop_machine(xics_migrate_irqs_away_secondary, NULL, &stop_cpus);
>> + /* fixme, create a kthread on primary hwthread to handle tickless mode */
>> + //kthread_create_on_cpu(prevent_tickless, NULL, core * threads_per_core, "ppckvm_prevent_tickless");
>> set_bit(core, &kvm_on_core);
>> return count;
>> }
>>
>
^ permalink raw reply
* Pull request: scottwood/linux.git next
From: Scott Wood @ 2014-11-18 5:20 UTC (permalink / raw)
To: benh, Michael Ellerman; +Cc: linuxppc-dev
Highlights include a bunch of 8xx optimizations, device tree bindings for
Freescale BMan, QMan, and FMan datapath components, misc device tree
updates, and inbound rio window support.
The following changes since commit 0df1f2487d2f0d04703f142813d53615d62a1da4:
Linux 3.18-rc3 (2014-11-02 15:01:51 -0800)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/scottwood/linux.git next
for you to fetch changes up to 76f3e2929bb6b476fb02b519ad953e2e29ee7bd5:
powerpc/config: Enable memory driver (2014-11-17 19:36:42 -0600)
----------------------------------------------------------------
Ashish Kumar (1):
powerpc/mpc85xx: Remove SPI and NAND partition from bsc9131rdb.dtsi
Emil Medve (7):
powerpc/dts: Factorize the clock control node
dt/bindings: qoriq-clock: Add binding for the platform PLL
powerpc/dts: Add node(s) for the platform PLL
dt/bindings: Introduce the FSL QorIQ DPAA BMan
dt/bindings: Introduce the FSL QorIQ DPAA BMan portal(s)
dt/bindings: Introduce the FSL QorIQ DPAA QMan
dt/bindings: Introduce the FSL QorIQ DPAA QMan portal(s)
Hongtao Jia (2):
powerpc: Add ADT7461 to device tree for supported boards
powerpc: Add INA220 to device tree for supported boards
Igal Liberman (2):
powerpc/fsl: Added rcw registers to global utility registers
powerpc/fsl: Frame Manager Device Tree binding document
LEROY Christophe (14):
powerpc/8xx: exception InstructionAccess does not exist on MPC8xx
powerpc/8xx: DataAccess exception not generated by MPC8xx
powerpc/8xx: No need to restore registers and save them again.
powerpc/8xx: Use M_TW instead of M_TWB
powerpc/8xx: Don't use MD_TWC for walk
powerpc/8xx: Use PAGE size related consts
powerpc/8xx: Const for TLB RPN forced value
powerpc/8xx: Implement 16k pages
powerpc/8xx: Better readibility of ERRATA CPU6 handling
powerpc/8xx: set PTE bit 22 off TLBmiss
powerpc/8xx: _PMD_PRESENT already set in level 1 entries
powerpc/8xx: Don't restore regs to save them again.
powerpc/8xx: Use DAR to save r3 for CPU6 ERRATA
powerpc/8xx: Invalidate non present TLB as early as possible
Martijn de Gouw (1):
powerpc/fsl-rio: add support for mapping inbound windows
Paul Bolle (1):
powerpc/8xx: Remove Kconfig symbol FADS
Prabhakar Kushwaha (1):
powerpc/config: Enable memory driver
Scott Wood (1):
powerpc/fsl: Update fman dt binding with clock name and qbman link
.../devicetree/bindings/clock/qoriq-clock.txt | 14 +-
.../devicetree/bindings/powerpc/fsl/fman.txt | 534 +++++++++++++++++++++
.../devicetree/bindings/soc/fsl/bman-portals.txt | 56 +++
Documentation/devicetree/bindings/soc/fsl/bman.txt | 125 +++++
.../devicetree/bindings/soc/fsl/qman-portals.txt | 154 ++++++
Documentation/devicetree/bindings/soc/fsl/qman.txt | 165 +++++++
arch/powerpc/Kconfig | 2 +-
arch/powerpc/boot/dts/b4860emu.dts | 4 +-
arch/powerpc/boot/dts/b4qds.dtsi | 23 +
arch/powerpc/boot/dts/bsc9131rdb.dtsi | 50 --
arch/powerpc/boot/dts/fsl/b4420si-post.dtsi | 28 +-
arch/powerpc/boot/dts/fsl/b4860si-post.dtsi | 28 +-
arch/powerpc/boot/dts/fsl/p2041si-post.dtsi | 48 +-
arch/powerpc/boot/dts/fsl/p3041si-post.dtsi | 48 +-
arch/powerpc/boot/dts/fsl/p4080si-post.dtsi | 48 +-
arch/powerpc/boot/dts/fsl/p5020si-post.dtsi | 48 +-
arch/powerpc/boot/dts/fsl/p5040si-post.dtsi | 48 +-
arch/powerpc/boot/dts/fsl/qoriq-clockgen1.dtsi | 85 ++++
arch/powerpc/boot/dts/fsl/qoriq-clockgen2.dtsi | 68 +++
arch/powerpc/boot/dts/fsl/t1040si-post.dtsi | 30 +-
arch/powerpc/boot/dts/fsl/t2081si-post.dtsi | 29 +-
arch/powerpc/boot/dts/fsl/t4240si-post.dtsi | 29 +-
arch/powerpc/boot/dts/p3041ds.dts | 20 +
arch/powerpc/boot/dts/p5020ds.dts | 20 +
arch/powerpc/boot/dts/p5040ds.dts | 20 +
arch/powerpc/boot/dts/t104xrdb.dtsi | 7 +
arch/powerpc/boot/dts/t208xqds.dtsi | 11 +
arch/powerpc/boot/dts/t4240emu.dts | 4 +-
arch/powerpc/configs/corenet32_smp_defconfig | 1 +
arch/powerpc/configs/corenet64_smp_defconfig | 1 +
arch/powerpc/configs/mpc85xx_defconfig | 1 +
arch/powerpc/configs/mpc85xx_smp_defconfig | 1 +
arch/powerpc/include/asm/fsl_guts.h | 5 +-
arch/powerpc/include/asm/mmu-8xx.h | 2 +
arch/powerpc/include/asm/pgtable-ppc32.h | 20 +
arch/powerpc/include/asm/pte-8xx.h | 7 +-
arch/powerpc/kernel/head_8xx.S | 230 ++++-----
arch/powerpc/mm/fault.c | 7 -
arch/powerpc/platforms/8xx/Kconfig | 4 -
arch/powerpc/sysdev/fsl_rio.c | 104 ++++
arch/powerpc/sysdev/fsl_rio.h | 13 +
41 files changed, 1599 insertions(+), 543 deletions(-)
create mode 100644 Documentation/devicetree/bindings/powerpc/fsl/fman.txt
create mode 100644 Documentation/devicetree/bindings/soc/fsl/bman-portals.txt
create mode 100644 Documentation/devicetree/bindings/soc/fsl/bman.txt
create mode 100644 Documentation/devicetree/bindings/soc/fsl/qman-portals.txt
create mode 100644 Documentation/devicetree/bindings/soc/fsl/qman.txt
create mode 100644 arch/powerpc/boot/dts/fsl/qoriq-clockgen1.dtsi
create mode 100644 arch/powerpc/boot/dts/fsl/qoriq-clockgen2.dtsi
^ 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