* Re: [PATCH v2 03/22] MSI: Remove the redundant irq_set_chip_data()
From: Thierry Reding @ 2014-09-26 8:09 UTC (permalink / raw)
To: Yijing Wang
Cc: linux-mips, linux-ia64, linux-pci, Bharat.Bhushan, sparclinux,
linux-arch, linux-s390, Russell King, Joerg Roedel, x86,
Sebastian Ott, xen-devel, arnab.basu, Arnd Bergmann,
Konrad Rzeszutek Wilk, Chris Metcalf, Bjorn Helgaas,
Thomas Gleixner, linux-arm-kernel, Thomas Petazzoni, Xinwei Hu,
Tony Luck, Sergei Shtylyov, linux-kernel, Ralf Baechle, iommu,
David Vrabel, Wuyun, linuxppc-dev, David S. Miller, Lucas Stach
In-Reply-To: <5424C9BD.3040506@huawei.com>
[-- Attachment #1: Type: text/plain, Size: 1480 bytes --]
On Fri, Sep 26, 2014 at 10:04:45AM +0800, Yijing Wang wrote:
> On 2014/9/25 15:19, Thierry Reding wrote:
> > On Thu, Sep 25, 2014 at 11:14:13AM +0800, Yijing Wang wrote:
> >> Currently, pcie-designware, pcie-rcar, pci-tegra drivers
> >> use irq chip_data to save the msi_chip pointer. They
> >> already call irq_set_chip_data() in their own MSI irq map
> >> functions. So irq_set_chip_data() in arch_setup_msi_irq()
> >> is useless.
> >
> > Again, I think this should be the other way around. If drivers do
> > something that's already handled by the core, then the duplicate code
> > should be dropped from the drivers.
>
> Hi Thierry, this is different thing, because chip_data is specific to IRQ
> controller, and in other platform, like in x86, chip_data is used to save irq_cfg.
> So we can not call irq_set_chip_data() in core code.
>
> x86 irq piece code
>
> int arch_setup_hwirq(unsigned int irq, int node)
> {
> struct irq_cfg *cfg;
> unsigned long flags;
> int ret;
>
> cfg = alloc_irq_cfg(irq, node);
> if (!cfg)
> return -ENOMEM;
>
> raw_spin_lock_irqsave(&vector_lock, flags);
> ret = __assign_irq_vector(irq, cfg, apic->target_cpus());
> raw_spin_unlock_irqrestore(&vector_lock, flags);
>
> if (!ret)
> irq_set_chip_data(irq, cfg); ------------->Save irq_cfg
> else
> free_irq_cfg(irq, cfg);
> return ret;
> }
Okay, makes sense to keep irq_set_chip_data() for driver-specific data
then.
Thierry
[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCH v2 03/22] MSI: Remove the redundant irq_set_chip_data()
From: Thierry Reding @ 2014-09-26 8:09 UTC (permalink / raw)
To: Yijing Wang
Cc: linux-mips, linux-ia64, linux-pci, Bharat.Bhushan, sparclinux,
linux-arch, linux-s390, Russell King, Joerg Roedel, x86,
Sebastian Ott, xen-devel, arnab.basu, Arnd Bergmann,
Konrad Rzeszutek Wilk, Chris Metcalf, Bjorn Helgaas,
Thomas Gleixner, linux-arm-kernel, Thomas Petazzoni, Xinwei Hu,
Tony Luck, Sergei Shtylyov, linux-kernel, Ralf Baechle, iommu,
David Vrabel, Wuyun, linuxppc-dev, David S. Miller, Lucas Stach
In-Reply-To: <1411614872-4009-4-git-send-email-wangyijing@huawei.com>
[-- Attachment #1: Type: text/plain, Size: 1174 bytes --]
On Thu, Sep 25, 2014 at 11:14:13AM +0800, Yijing Wang wrote:
> Currently, pcie-designware, pcie-rcar, pci-tegra drivers
> use irq chip_data to save the msi_chip pointer. They
> already call irq_set_chip_data() in their own MSI irq map
> functions. So irq_set_chip_data() in arch_setup_msi_irq()
> is useless.
>
> Signed-off-by: Yijing Wang <wangyijing@huawei.com>
> ---
> drivers/pci/msi.c | 5 ++---
> 1 files changed, 2 insertions(+), 3 deletions(-)
Reviewed-by: Thierry Reding <treding@nvidia.com>
>
> diff --git a/drivers/pci/msi.c b/drivers/pci/msi.c
> index 51d7e62..50f67a3 100644
> --- a/drivers/pci/msi.c
> +++ b/drivers/pci/msi.c
> @@ -41,14 +41,13 @@ int __weak arch_setup_msi_irq(struct pci_dev *dev, struct msi_desc *desc)
> if (err < 0)
> return err;
>
> - irq_set_chip_data(desc->irq, chip);
> -
> return 0;
> }
>
> void __weak arch_teardown_msi_irq(unsigned int irq)
> {
> - struct msi_chip *chip = irq_get_chip_data(irq);
> + struct msi_desc *entry = irq_get_msi_desc(irq);
> + struct msi_chip *chip = entry->dev->bus->msi;
>
> if (!chip || !chip->teardown_irq)
> return;
> --
> 1.7.1
>
[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCH v2 00/22] Use MSI chip framework to configure MSI/MSI-X in all platforms
From: Liviu Dudau @ 2014-09-26 8:50 UTC (permalink / raw)
To: Yijing Wang
Cc: linux-mips, linux-ia64, linux-pci, Bharat.Bhushan, Thierry Reding,
sparclinux, linux-arch, linux-s390, Russell King, Joerg Roedel,
x86, Sebastian Ott, xen-devel, arnab.basu, Arnd Bergmann,
Konrad Rzeszutek Wilk, Chris Metcalf, Bjorn Helgaas,
Thomas Gleixner, linux-arm-kernel, Thomas Petazzoni, Xinwei Hu,
Tony Luck, Sergei Shtylyov, linux-kernel, Ralf Baechle, iommu,
David Vrabel, Wuyun, linuxppc-dev, David S. Miller, Lucas Stach
In-Reply-To: <5424E09F.50701@huawei.com>
On Fri, Sep 26, 2014 at 11:42:23AM +0800, Yijing Wang wrote:
> >> I am actually in disagreement with you, Thierry. I don't like the general direction
> >> of the patches, or at least I don't like the fact that we don't have a portable
> >> way of setting up the msi_chip without having to rely on weak architectural hooks.
> >
> > Oh, good. That's actually one of the things I said I wasn't happy with
> > either. =)
>
> Hm, I decide to drop weak arch_find_msi_chip(), no one likes it.
> Let's find a better solution :)
>
> >
> >> I'm surprised no one considers the case of a platform having more than one host
> >> bridge and possibly more than one MSI unit. With the current proposed patchset I
> >> can't see how that would work.
> >
> > The PCI core can already deal with that. An MSI chip can be set per bus
> > and the weak pcibios_add_bus() can be used to set that. Often it might
> > not even be necessary to do it via pcibios_add_bus() if you create the
> > root bus directly, since you can attach the MSI chip at that time.
>
> Yes, PCI hostbridge driver find the matched msi chip during its initialization,
> and assign the msi chip to PCI bus in pcibios_add_bus().
>
> >
> >> What I would like to see is a way of creating the pci_host_bridge structure outside
> >> the pci_create_root_bus(). That would then allow us to pass this sort of platform
> >> details like associated msi_chip into the host bridge and the child busses will
> >> have an easy way of finding the information needed by finding the root bus and then
> >> the host bridge structure. Then the generic pci_scan_root_bus() can be used by (mostly)
> >> everyone and the drivers can remove their kludges that try to work around the
> >> current limitations.
>
> So I think maybe save msi chip in PCI arch sysdata is a good candidate.
Except that arch sysdata at the moment is an opaque pointer. I am all in favour in
changing the type of sysdata from void* into pci_host_bridge* and arches can wrap their old
sysdata around the pci_host_bridge*.
Best regards,
Liviu
>
> >
> > I think both issues are orthogonal. Last time I checked a lot of work
> > was still necessary to unify host bridges enough so that it could be
> > shared across architectures. But perhaps some of that work has
> > happened in the meantime.
> >
> > But like I said, when you create the root bus, you can easily attach the
> > MSI chip to it.
> >
> > Thierry
> >
>
>
> --
> Thanks!
> Yijing
>
>
--
-------------------
.oooO
( )
\ ( Oooo.
\_) ( )
) /
(_/
One small step
for me ...
^ permalink raw reply
* Re: [PATCH v2 00/22] Use MSI chip framework to configure MSI/MSI-X in all platforms
From: Thierry Reding @ 2014-09-26 8:54 UTC (permalink / raw)
To: Yijing Wang
Cc: linux-mips, linux-ia64, linux-pci, Xinwei Hu, sparclinux,
linux-arch, linux-s390, Russell King, Joerg Roedel, x86,
Sebastian Ott, Bharat.Bhushan, xen-devel, arnab.basu,
Arnd Bergmann, Konrad Rzeszutek Wilk, Chris Metcalf,
Bjorn Helgaas, Thomas Gleixner, linux-arm-kernel,
Thomas Petazzoni, Liviu Dudau, Tony Luck, Sergei Shtylyov,
linux-kernel, Ralf Baechle, iommu, David Vrabel, Wuyun,
linuxppc-dev, David S. Miller, Lucas Stach
In-Reply-To: <542505B3.7040208@huawei.com>
[-- Attachment #1: Type: text/plain, Size: 3627 bytes --]
On Fri, Sep 26, 2014 at 02:20:35PM +0800, Yijing Wang wrote:
> >> The PCI core can already deal with that. An MSI chip can be set per bus
> >> and the weak pcibios_add_bus() can be used to set that. Often it might
> >> not even be necessary to do it via pcibios_add_bus() if you create the
> >> root bus directly, since you can attach the MSI chip at that time.
> >
> > But I'm thinking that we need to move away from pcibios_add_bus() interface to do
> > something that should be generic. You don't need to be called for every bus when all
> > you want is just the root bus in order to add the MSI chip. Also, from looking at
> > the current patchset, a lot of architectures would set the MSI chip to a global
> > variable, which means you don't have an option to choose the MSI chip based on the
> > bus.
>
> I also agree to remove the pcibios_add_bus() in arm which call .add_bus() to associate msi_chip
> and PCI bus.
>
> In my opinions, all PCI devices under the same PCI hostbridge must share same msi chip, right ?
> So if we can associate msi chip and PCI hostbridge, every PCI device can find correct msi chip.
> PCI hostbridge private attributes can be saved in PCI sysdata, and this data will be propagate to
> PCI root bus and its child buses.
struct pci_sys_data is architecture specific, so the code won't become
any more generic than it is now.
> >>> What I would like to see is a way of creating the pci_host_bridge structure outside
> >>> the pci_create_root_bus(). That would then allow us to pass this sort of platform
> >>> details like associated msi_chip into the host bridge and the child busses will
> >>> have an easy way of finding the information needed by finding the root bus and then
> >>> the host bridge structure. Then the generic pci_scan_root_bus() can be used by (mostly)
> >>> everyone and the drivers can remove their kludges that try to work around the
> >>> current limitations.
> >>
> >> I think both issues are orthogonal. Last time I checked a lot of work
> >> was still necessary to unify host bridges enough so that it could be
> >> shared across architectures. But perhaps some of that work has
> >> happened in the meantime.
> >
> > Breaking out the host bridge creation from root bus creation is not difficult, just not
> > agree upon. That would be the first step in making the generic host brige structure
> > useful for sharing, specially if used as a sort of "parent" structure that you can
> > wrap with your actual host bridge structure.
>
> Breaking out the host bridge creation is a good idea, but there need a lot of changes, we can
> do it in another series.
I agree, this can be done step by step.
> And if we save msi chip in pci sysdata now, it will be easy to
> move it to generic pci host bridge. We can also move the pci domain number and other common info to it.
But like I said above, we wouldn't gain anything by moving the MSI chip
into struct pci_sys_data, since the core code couldn't access it from
there. The code wouldn't become more generic than the current approach
of using pcibios_add_bus(). At least for Tegra it's trivial to just hook
it up in tegra_pcie_scan_bus() directly (patch attached). So I think a
generic solution would be to allow it to be easily associated with a
bus.
Perhaps it would be as simple as adding a pci_scan_root_bus_with_msi()
or something with a less awkward name, or extending the existing
pci_scan_root_bus() with an MSI chip parameter. The function already has
too many arguments for my taste, though, so I'd like to avoid the
latter.
Thierry
[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCH v2 00/22] Use MSI chip framework to configure MSI/MSI-X in all platforms
From: Thierry Reding @ 2014-09-26 9:05 UTC (permalink / raw)
To: Yijing Wang
Cc: linux-mips, linux-ia64, linux-pci, Xinwei Hu, sparclinux,
linux-arch, linux-s390, Russell King, Joerg Roedel, x86,
Sebastian Ott, Bharat.Bhushan, xen-devel, arnab.basu,
Arnd Bergmann, Konrad Rzeszutek Wilk, Chris Metcalf,
Bjorn Helgaas, Thomas Gleixner, linux-arm-kernel,
Thomas Petazzoni, Liviu Dudau, Tony Luck, Sergei Shtylyov,
linux-kernel, Ralf Baechle, iommu, David Vrabel, Wuyun,
linuxppc-dev, David S. Miller, Lucas Stach
In-Reply-To: <20140926085430.GG31106@ulmo>
[-- Attachment #1.1: Type: text/plain, Size: 214 bytes --]
On Fri, Sep 26, 2014 at 10:54:32AM +0200, Thierry Reding wrote:
[...]
> At least for Tegra it's trivial to just hook it up in tegra_pcie_scan_bus()
> directly (patch attached).
Really attached this time.
Thierry
[-- Attachment #1.2: 0001-PCI-tegra-Remove-.add_bus-callback.patch --]
[-- Type: text/x-diff, Size: 1945 bytes --]
From 2cedfcf38cdfe21688d1363659f28e271ce43358 Mon Sep 17 00:00:00 2001
From: Thierry Reding <treding@nvidia.com>
Date: Fri, 26 Sep 2014 10:35:47 +0200
Subject: [PATCH] PCI: tegra: Remove .add_bus() callback
The .add_bus() callback is called for every bus and used to associate an
MSI chip with each bus. However the PCI core code already propagates the
root bus' MSI chip to child busses, so it is enough to associate the MSI
chip with the root bus upon creation. Conveniently the Tegra PCIe host
bridge driver creates the root bus directly, so the association can be
done at the same time.
Signed-off-by: Thierry Reding <treding@nvidia.com>
---
drivers/pci/host/pci-tegra.c | 13 +++----------
1 file changed, 3 insertions(+), 10 deletions(-)
diff --git a/drivers/pci/host/pci-tegra.c b/drivers/pci/host/pci-tegra.c
index 3d43874319be..d314e549ac0c 100644
--- a/drivers/pci/host/pci-tegra.c
+++ b/drivers/pci/host/pci-tegra.c
@@ -694,15 +694,6 @@ static int tegra_pcie_map_irq(const struct pci_dev *pdev, u8 slot, u8 pin)
return irq;
}
-static void tegra_pcie_add_bus(struct pci_bus *bus)
-{
- if (IS_ENABLED(CONFIG_PCI_MSI)) {
- struct tegra_pcie *pcie = sys_to_pcie(bus->sysdata);
-
- bus->msi = &pcie->msi.chip;
- }
-}
-
static struct pci_bus *tegra_pcie_scan_bus(int nr, struct pci_sys_data *sys)
{
struct tegra_pcie *pcie = sys_to_pcie(sys);
@@ -713,6 +704,9 @@ static struct pci_bus *tegra_pcie_scan_bus(int nr, struct pci_sys_data *sys)
if (!bus)
return NULL;
+ if (IS_ENABLED(CONFIG_PCI_MSI))
+ bus->msi = &pcie->msi.chip;
+
pci_scan_child_bus(bus);
return bus;
@@ -1885,7 +1879,6 @@ static int tegra_pcie_enable(struct tegra_pcie *pcie)
hw.private_data = (void **)&pcie;
hw.setup = tegra_pcie_setup;
hw.map_irq = tegra_pcie_map_irq;
- hw.add_bus = tegra_pcie_add_bus;
hw.scan = tegra_pcie_scan_bus;
hw.ops = &tegra_pcie_ops;
--
2.1.0
[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply related
* Re: [PATCH v2 06/22] PCI/MSI: Introduce weak arch_find_msi_chip() to find MSI chip
From: Thomas Gleixner @ 2014-09-26 10:38 UTC (permalink / raw)
To: Yijing Wang
Cc: linux-mips, linux-ia64, linux-pci, Bharat.Bhushan, Thierry Reding,
sparclinux, linux-arch, linux-s390, Russell King, Joerg Roedel,
x86, Sebastian Ott, xen-devel, arnab.basu, Arnd Bergmann,
Konrad Rzeszutek Wilk, Chris Metcalf, Bjorn Helgaas,
linux-arm-kernel, Thomas Petazzoni, Xinwei Hu, Tony Luck,
Sergei Shtylyov, linux-kernel, Ralf Baechle, iommu, David Vrabel,
Wuyun, linuxppc-dev, David S. Miller, Lucas Stach
In-Reply-To: <5424D30A.6040900@huawei.com>
On Fri, 26 Sep 2014, Yijing Wang wrote:
> On 2014/9/25 18:38, Thomas Gleixner wrote:
> > On Thu, 25 Sep 2014, Yijing Wang wrote:
> >
> >> Introduce weak arch_find_msi_chip() to find the match msi_chip.
> >> Currently, MSI chip associates pci bus to msi_chip. Because in
> >> ARM platform, there may be more than one MSI controller in system.
> >> Associate pci bus to msi_chip help pci device to find the match
> >> msi_chip and setup MSI/MSI-X irq correctly. But in other platform,
> >> like in x86. we only need one MSI chip, because all device use
> >> the same MSI address/data and irq etc. So it's no need to associate
> >> pci bus to MSI chip, just use a arch function, arch_find_msi_chip()
> >> to return the MSI chip for simplicity. The default weak
> >> arch_find_msi_chip() used in ARM platform, find the MSI chip
> >> by pci bus.
> >
> > This is really backwards. On one hand you try to get rid of the weak
> > arch functions zoo and then you invent new ones for no good
> > reason. Why can't x86 store the chip in the pci bus?
> >
> > Looking deeper, I'm questioning the whole notion of different
> > msi_chips. Are this really different MSI controllers with a different
> > feature set or are this defacto multiple instances of the same
> > controller which just need a different data set?
>
> MSI chip in this series is to setup MSI irq, including IRQ allocation, Map,
> compose MSI msg ..., in different platform, many arch specific MSI irq details in it.
> It's difficult to extract the common data and code.
>
> I have a plan to rework MSI related irq_chips in kernel, PCI and Non-PCI, currently,
> HPET, DMAR and PCI have their own irq_chip and MSI related functions, write_msi_msg(),
> mask_msi_irq(), etc... I want to extract the common data set for that, so we can
> remove lots of unnecessary MSI code.
That makes sense. Can you please make sure that this does not conflict
with the ongoing work Jiang is doing in the x86 irq area with
hierarchical irqdomains to distangle layered levels like MSI from the
underlying vector/irqremap mechanics.
Thanks,
tglx
^ permalink raw reply
* Re: [PATCH 02/15] powerpc/cell: Move data segment faulting code out of cell platform
From: Michael Neuling @ 2014-09-26 11:19 UTC (permalink / raw)
To: Anton Blanchard
Cc: cbe-oss-dev, arnd, greg, linux-kernel, imunsie, linuxppc-dev, jk
In-Reply-To: <20140926140506.3d8fdac3@kryten>
On Fri, 2014-09-26 at 14:05 +1000, Anton Blanchard wrote:
> > From: Ian Munsie <imunsie@au1.ibm.com>
> >=20
> > __spu_trap_data_seg() currently contains code to determine the VSID
> > and ESID required for a particular EA and mm struct.
> >=20
> > This code is generically useful for other co-processors. This moves
> > the code of the cell platform so it can be used by other powerpc code.
>=20
> Could we also mention:
>=20
> and adds 1TB segment support.
Good point. I'll add.
> > Signed-off-by: Ian Munsie <imunsie@au1.ibm.com>
> > Signed-off-by: Michael Neuling <mikey@neuling.org>
>=20
> Reviewed-by: Anton Blanchard <anton@samba.org>
Thanks,
Mikey
^ permalink raw reply
* Re: [PATCH 10/15] powerpc/mm: Add hooks for cxl
From: Michael Neuling @ 2014-09-26 11:33 UTC (permalink / raw)
To: Anton Blanchard
Cc: cbe-oss-dev, arnd, greg, linux-kernel, imunsie, linuxppc-dev, jk
In-Reply-To: <20140926143309.33c0eeac@kryten>
On Fri, 2014-09-26 at 14:33 +1000, Anton Blanchard wrote:
> > From: Ian Munsie <imunsie@au1.ibm.com>
> >=20
> > This add a hook into tlbie() so that we use global invalidations when
> > there are cxl contexts active.
> >=20
> > Normally cxl snoops broadcast tlbie. cxl can have TLB entries
> > invalidated via MMIO, but we aren't doing that yet. So for now we
> > are just disabling local tlbies when cxl contexts are active. In
> > future we can make tlbie() local mode smarter so that it invalidates
> > cxl contexts explicitly when it needs to.
> >=20
> > This also adds a hooks for when SLBs are invalidated to ensure any
> > corresponding SLBs in cxl are also invalidated at the same time.
> >=20
> > Signed-off-by: Ian Munsie <imunsie@au1.ibm.com>
> > Signed-off-by: Michael Neuling <mikey@neuling.org>
>=20
> > + use_local =3D local && mmu_has_feature(MMU_FTR_TLBIEL) && !cxl_ctx_in=
_use();
>=20
> Seems reasonable until we can get the MMIO based optimisation in.
>=20
> Will all CAPI cached translations be invalidated before we finish using
> a CAPI context?=20
I'm not sure I understand. Can you elaborate?
> And conversely, could CAPI cache any translations when a
> context isn't active?=20
The kernel invalidates all translations when the file descriptor is
closed. So no, unless the PSL was badly behaving and ignoring the
invalidations.... but if we can't trust the PSL we're screwed.
> I'm mostly concerned that we can't have a
> situation where badly behaving userspace could result in a stale
> translation.
We only map what a user processes maps and we tear it down when the
process is teared down (on the file descriptor release). So I think we
are ok. =20
Unless there's some lazy teardown you're alluding to that I'm missing?
>=20
> > spu_flush_all_slbs(mm);
> > #endif
> > + cxl_slbia(mm);
>=20
> > spu_flush_all_slbs(mm);
> > #endif
> > + cxl_slbia(mm);
>=20
> > spu_flush_all_slbs(mm);
> > #endif
> > + cxl_slbia(mm);
>=20
> > spu_flush_all_slbs(mm);
> > #endif
> > + cxl_slbia(mm);
>=20
> Should we combine the SPU vs CXL callouts into something common -
> perhaps copro_flush_all_slbs()?
Sounds good. I'll update.
Mikey
^ permalink raw reply
* Re: [PATCH 10/15] powerpc/mm: Add hooks for cxl
From: Anton Blanchard @ 2014-09-26 13:24 UTC (permalink / raw)
To: Michael Neuling
Cc: cbe-oss-dev, arnd, greg, linux-kernel, imunsie, linuxppc-dev, jk
In-Reply-To: <1411731209.1733.51.camel@ale.ozlabs.ibm.com>
Hi Mikey,
> We only map what a user processes maps and we tear it down when the
> process is teared down (on the file descriptor release). So I think
> we are ok.
>
> Unless there's some lazy teardown you're alluding to that I'm missing?
I was trying to make sure things like the TLB batching code won't allow
a tlbie to be postponed until after a CAPI mapping is destroyed. It's
been ages since I looked at that part of the mm code.
Anton
^ permalink raw reply
* Re: [PATCH][V2] Freescale Frame Manager Device Tree binding document
From: Bob Cochran @ 2014-09-26 16:37 UTC (permalink / raw)
To: Igal.Liberman, devicetree, linuxppc-dev, netdev; +Cc: scottwood, Emilian.Medve
In-Reply-To: <1410952110-32733-1-git-send-email-igal.liberman@freescale.com>
On 09/17/2014 07:08 AM, Igal.Liberman wrote:
> From: Igal Liberman <Igal.Liberman@freescale.com>
>
> The Frame Manager (FMan) combines the Ethernet network interfaces with packet
> distribution logic to provide intelligent distribution and queuing decisions
> for incoming traffic at line rate.
>
> This binding document describes Freescale's Frame Manager hardware attributes
> that are used by the Frame Manager driver for its basic initialization and
> configuration.
>
> Difference between [V1] and [V2]:
> Addressed all comments recieved from Scott in [V1]
>
> Signed-off-by: Igal Liberman <Igal.Liberman@freescale.com>
Is there a reference (FMAN) dts file I can compare this against? I was
reviewing this against my (combined) dts file for my t1040rdb built with
either FSL's SDK1.6 or Yocto Project meta-fsl-ppc master branch, and I'm
not finding a good match between the nodes / properties in my dts file
and what you have here.
For example, I don't find the required "clocks" or
"fsl,qman-channel-range" properties under my <fman0: fman@400000 ...>
node.
I'm wondering if this document is trailing or leading the source in the
latest published FSL SDK (1.6).
And a minor nit pick: twice you write "bellow" where you should have "below"
Thanks
Bob
> ---
> .../devicetree/bindings/powerpc/fsl/fman.txt | 529 ++++++++++++++++++++
> 1 file changed, 529 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/powerpc/fsl/fman.txt
>
> diff --git a/Documentation/devicetree/bindings/powerpc/fsl/fman.txt b/Documentation/devicetree/bindings/powerpc/fsl/fman.txt
> new file mode 100644
> index 0000000..da8e5f2
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/powerpc/fsl/fman.txt
> @@ -0,0 +1,529 @@
> +=============================================================================
> +Freescale Frame Manager Device Bindings
> +
> +CONTENTS
> + - FMan Node
> + - FMan Port Node
> + - FMan MURAM Node
> + - FMan dTSEC/XGEC/mEMAC Node
> + - FMan IEEE 1588 Node
> + - Example
> +
> +=============================================================================
> +FMan Node
> +
> +DESCRIPTION
> +
> +Due to the fact that the FMan is an aggregation of sub-engines (ports, MACs,
> +etc.) the FMan node will have child nodes for each of them.
> +
> +PROPERTIES
> +
> +- compatible
> + Usage: required
> + Value type: <stringlist>
> + Definition: Must include "fsl,fman"
> + FMan version can be determined via FM_IP_REV_1 register in the
> + FMan block. The offset is 0xc4 from the beginning of the
> + Frame Processing Manager memory map (0xc3000 from the
> + beginning of the FMan node).
> +
> +- cell-index
> + Usage: required
> + Value type: <u32>
> + Definition: Specifies the index of the FMan unit.
> +
> + The cell-index value may be used by the SoC, to identify the
> + FMan unit in the SoC memory map. In the table bellow,
> + there's a description of the cell-index use in each SoC:
> +
> + - P1023:
> + register[bit] FMan unit cell-index
> + ============================================================
> + DEVDISR[1] 1 0
> +
> + - P2041, P3041, P4080 P5020, P5040:
> + register[bit] FMan unit cell-index
> + ============================================================
> + DCFG_DEVDISR2[6] 1 0
> + DCFG_DEVDISR2[14] 2 1
> + (Second FM available only in P4080 and P5040)
> +
> + - B4860, T1040, T2080, T4240:
> + register[bit] FMan unit cell-index
> + ============================================================
> + DCFG_CCSR_DEVDISR2[24] 1 0
> + DCFG_CCSR_DEVDISR2[25] 2 1
> + (Second FM available only in T4240)
> +
> + DEVDISR, DCFG_DEVDISR2 and DCFG_CCSR_DEVDISR2 are located in
> + the specific SoC "Device Configuration/Pin Control" Memory
> + Map.
> +
> +- reg
> + Usage: required
> + Value type: <prop-encoded-array>
> + Definition: A standard property. Specifies the offset of the
> + following configuration registers:
> + - BMI configuration registers.
> + - QMI configuration registers.
> + - DMA configuration registers.
> + - FPM configuration registers.
> + - FMan controller configuration registers.
> +
> +- ranges
> + Usage: required
> + Value type: <prop-encoded-array>
> + Definition: A standard property.
> +
> +- clocks
> + Usage: required
> + Value type: <prop-encoded-array>
> + Definition: phandle for fman clock.
> +
> +- clock-names
> + usage: optional
> + Value type: <stringlist>
> + Definition: A standard property
> +
> +- interrupts
> + Usage: required
> + Value type: <prop-encoded-array>
> + Definition: A pair of IRQs are specified in this property.
> + The first element is associated with the event interrupts and
> + the second element is associated with the error interrupts.
> +
> +- fsl,qman-channel-range
> + Usage: required
> + Value type: <prop-encoded-array>
> + Definition: Specifies the range of the available dedicated
> + channels in the FMan. The first cell specifies the beginning
> + of the range and the second cell specifies the number of
> + channels.
> + Further information available at:
> + "Work Queue (WQ) Channel Assignments in the QMan" section
> + in DPAA Reference Manual.
> +
> +=============================================================================
> +FMan MURAM Node
> +
> +DESCRIPTION
> +
> +FMan Internal memory - shared between all the FMan modules.
> +It contains data structures that are common and written to or read by
> +the modules.
> +FMan internal memory is split into the following parts:
> + Packet buffering (Tx/Rx FIFOs)
> + Frames internal context
> +
> +PROPERTIES
> +
> +- compatible
> + Usage: required
> + Value type: <stringlist>
> + Definition: Must include "fsl,fman-muram"
> +
> +- ranges
> + Usage: required
> + Value type: <prop-encoded-array>
> + Definition: A standard property.
> + Specifies the multi-user memory offset and the size within
> + the FMan.
> +
> +EXAMPLE
> +
> +muram@0 {
> + compatible = "fsl,fman-muram";
> + ranges = <0 0x000000 0x28000>;
> +};
> +
> +=============================================================================
> +FMan Port Node
> +
> +DESCRIPTION
> +
> +The Frame Manager (FMan) supports several types of hardware ports:
> + Ethernet receiver (RX)
> + Ethernet transmitter (TX)
> + Offline/Host command (O/H)
> +
> +PROPERTIES
> +
> +- compatible
> + Usage: required
> + Value type: <stringlist>
> + Definition: A standard property.
> + Must include one of the following:
> + - "fsl,fman-v2-port-oh" for FManV2 OH ports
> + - "fsl,fman-v2-port-rx" for FManV2 RX ports
> + - "fsl,fman-v2-port-tx" for FManV2 TX ports
> + - "fsl,fman-v3-port-oh" for FManV3 OH ports
> + - "fsl,fman-v3-port-rx" for FManV3 RX ports
> + - "fsl,fman-v3-port-tx" for FManV3 TX ports
> +
> +- cell-index
> + Usage: required
> + Value type: <u32>
> + Definition: Specifies the hardware port id.
> + Each hardware port on the FMan has its own hardware PortID.
> + Super set of all hardware Port IDs available at FMan Reference
> + Manual under "FMan Hardware Ports in Freescale Devices" table.
> +
> + Each hardware port is assigned a 4KB, port-specific page in
> + the FMan hardware port memory region (which is part of the
> + FMan memory map). The first 4 KB in the FMan hardware ports
> + memory region is used for what are called common registers.
> + The subsequent 63 4KB pages are allocated to the hardware
> + ports.
> + The page of a specific port is determined by the cell-index.
> +
> +- reg
> + Usage: required
> + Value type: <prop-encoded-array>
> + Definition: There is one reg region describing the port
> + configuration registers.
> +
> +EXAMPLE
> +
> +port@a8000 {
> + cell-index = <0x28>;
> + compatible = "fsl,fman-v2-port-tx";
> + reg = <0xa8000 0x1000>;
> +};
> +
> +port@88000 {
> + cell-index = <0x8>;
> + compatible = "fsl,fman-v2-port-rx";
> + reg = <0x88000 0x1000>;
> +};
> +
> +port@81000 {
> + cell-index = <0x1>;
> + compatible = "fsl,fman-v2-port-oh";
> + reg = <0x81000 0x1000>;
> +};
> +
> +=============================================================================
> +FMan dTSEC/XGEC/mEMAC Node
> +
> +DESCRIPTION
> +
> +mEMAC/dTSEC/XGEC are the Ethernet network interfaces
> +
> +PROPERTIES
> +
> +- compatible
> + Usage: required
> + Value type: <stringlist>
> + Definition: A standard property.
> + Must include one of the following:
> + - "fsl,fman-dtsec" for dTSEC MAC
> + - "fsl,fman-xgec" for XGEC MAC
> + - "fsl,fman-memac for mEMAC MAC
> +
> +- cell-index
> + Usage: required
> + Value type: <u32>
> + Definition: Specifies the MAC id.
> +
> + The cell-index value may be used by the FMan or the SoC, to
> + identify the MAC unit in the FMan (or SoC) memory map.
> + In the tables bellow there's a description of the cell-index
> + use, there are two tables, one describes the use of cell-index
> + by the FMan, the second describes the use by the SoC:
> +
> + 1. FMan Registers
> +
> + FManV2:
> + register[bit] MAC cell-index
> + ============================================================
> + FM_EPI[16] XGEC 8
> + FM_EPI[16+n] dTSECn n-1
> + FM_NPI[11+n] dTSECn n-1
> + n = 1,..,5
> +
> + FManV3:
> + register[bit] MAC cell-index
> + ============================================================
> + FM_EPI[16+n] mEMACn n-1
> + FM_EPI[25] mEMAC10 9
> +
> + FM_NPI[11+n] mEMACn n-1
> + FM_NPI[10] mEMAC10 9
> + FM_NPI[11] mEMAC9 8
> + n = 1,..8
> +
> + FM_EPI and FM_NPI are located in the FMan memory map.
> +
> + 2. SoC registers:
> +
> + - P2041, P3041, P4080 P5020, P5040:
> + register[bit] FMan MAC cell
> + Unit index
> + ============================================================
> + DCFG_DEVDISR2[7] 1 XGEC 8
> + DCFG_DEVDISR2[7+n] 1 dTSECn n-1
> + DCFG_DEVDISR2[15] 2 XGEC 8
> + DCFG_DEVDISR2[15+n] 2 dTSECn n-1
> + n = 1,..5
> +
> + - T1040, T2080, T4240, B4860:
> + register[bit] FMan MAC cell
> + Unit index
> + ============================================================
> + DCFG_CCSR_DEVDISR2[n-1] 1 mEMACn n-1
> + DCFG_CCSR_DEVDISR2[11+n] 2 mEMACn n-1
> + n = 1,..6,9,10
> +
> + EVDISR, DCFG_DEVDISR2 and DCFG_CCSR_DEVDISR2 are located in
> + the specific SoC "Device Configuration/Pin Control" Memory
> + Map.
> +
> +- reg
> + Usage: required
> + Value type: <prop-encoded-array>
> + Definition: A standard property.
> +
> +- fsl,fman-ports
> + Usage: required
> + Value type: <prop-encoded-array>
> + Definition: An array of two phandles - the first references is
> + the FMan RX port and the second is the TX port used by this
> + MAC.
> +
> +- ptp-timer
> + Usage required
> + Value type: <phandle>
> + Definition: A phandle for 1EEE1588 timer.
> +
> +EXAMPLE
> +
> +fman1_tx28: port@a8000 {
> + cell-index = <0x28>;
> + compatible = "fsl,fman-v2-port-tx";
> + reg = <0xa8000 0x1000>;
> +};
> +
> +fman1_rx8: port@88000 {
> + cell-index = <0x8>;
> + compatible = "fsl,fman-v2-port-rx";
> + reg = <0x88000 0x1000>;
> +};
> +
> +ptp-timer: ptp_timer@fe000 {
> + compatible = "fsl,fman-ptp-timer";
> + reg = <0xfe000 0x1000>;
> +};
> +
> +ethernet@e0000 {
> + compatible = "fsl,fman-dtsec";
> + cell-index = <0>;
> + reg = <0xe0000 0x1000>;
> + fsl,fman-ports = <&fman1_rx8 &fman1_tx28>;
> + ptp-timer = <&ptp-timer>;
> +};
> +
> +============================================================================
> +FMan IEEE 1588 Node
> +
> +DESCRIPTION
> +
> +The FMan interface to support IEEE 1588
> +
> +
> +PROPERTIES
> +
> +- compatible
> + Usage: required
> + Value type: <stringlist>
> + Definition: A standard property.
> + Must include "fsl,fman-ptp-timer".
> +
> +- reg
> + Usage: required
> + Value type: <prop-encoded-array>
> + Definition: A standard property.
> +
> +EXAMPLE
> +
> +ptp-timer@fe000 {
> + compatible = "fsl,fman-ptp-timer";
> + reg = <0xfe000 0x1000>;
> +};
> +
> +=============================================================================
> +Example
> +
> +fman@400000 {
> + #address-cells = <1>;
> + #size-cells = <1>;
> + cell-index = <1>;
> + compatible = "fsl,fman"
> + ranges = <0 0x400000 0x100000>;
> + reg = <0x400000 0x100000>;
> + clocks = <&fman_clk>;
> + clock-names = "fmanclk";
> + interrupts = <
> + 96 2 0 0
> + 16 2 1 1>;
> + fsl,qman-channel-range = <0x40 0xc>;
> +
> + muram@0 {
> + compatible = "fsl,fman-muram";
> + reg = <0x0 0x28000>;
> + };
> +
> + port@81000 {
> + cell-index = <1>;
> + compatible = "fsl,fman-v2-port-oh";
> + reg = <0x81000 0x1000>;
> + };
> +
> + port@82000 {
> + cell-index = <2>;
> + compatible = "fsl,fman-v2-port-oh";
> + reg = <0x82000 0x1000>;
> + };
> +
> + port@83000 {
> + cell-index = <3>;
> + compatible = "fsl,fman-v2-port-oh";
> + reg = <0x83000 0x1000>;
> + };
> +
> + port@84000 {
> + cell-index = <4>;
> + compatible = "fsl,fman-v2-port-oh";
> + reg = <0x84000 0x1000>;
> + };
> +
> + port@85000 {
> + cell-index = <5>;
> + compatible = "fsl,fman-v2-port-oh";
> + reg = <0x85000 0x1000>;
> + };
> +
> + port@86000 {
> + cell-index = <6>;
> + compatible = "fsl,fman-v2-port-oh";
> + reg = <0x86000 0x1000>;
> + };
> +
> + fman1_rx_0x8: port@88000 {
> + cell-index = <0x8>;
> + compatible = "fsl,fman-v2-port-rx";
> + reg = <0x88000 0x1000>;
> + };
> +
> + fman1_rx_0x9: port@89000 {
> + cell-index = <0x9>;
> + compatible = "fsl,fman-v2-port-rx";
> + reg = <0x89000 0x1000>;
> + };
> +
> + fman1_rx_0xa: port@8a000 {
> + cell-index = <0xa>;
> + compatible = "fsl,fman-v2-port-rx";
> + reg = <0x8a000 0x1000>;
> + };
> +
> + fman1_rx_0xb: port@8b000 {
> + cell-index = <0xb>;
> + compatible = "fsl,fman-v2-port-rx";
> + reg = <0x8b000 0x1000>;
> + };
> +
> + fman1_rx_0xc: port@8c000 {
> + cell-index = <0xc>;
> + compatible = "fsl,fman-v2-port-rx";
> + reg = <0x8c000 0x1000>;
> + };
> +
> + fman1_rx_0x10: port@90000 {
> + cell-index = <0x10>;
> + compatible = "fsl,fman-v2-port-rx";
> + reg = <0x90000 0x1000>;
> + };
> +
> + fman1_tx_0x28: port@a8000 {
> + cell-index = <0x28>;
> + compatible = "fsl,fman-v2-port-tx";
> + reg = <0xa8000 0x1000>;
> + };
> +
> + fman1_tx_0x29: port@a9000 {
> + cell-index = <0x29>;
> + compatible = "fsl,fman-v2-port-tx";
> + reg = <0xa9000 0x1000>;
> + };
> +
> + fman1_tx_0x2a: port@aa000 {
> + cell-index = <0x2a>;
> + compatible = "fsl,fman-v2-port-tx";
> + reg = <0xaa000 0x1000>;
> + };
> +
> + fman1_tx_0x2b: port@ab000 {
> + cell-index = <0x2b>;
> + compatible = "fsl,fman-v2-port-tx";
> + reg = <0xab000 0x1000>;
> + };
> +
> + fman1_tx_0x2c: port@ac0000 {
> + cell-index = <0x2c>;
> + compatible = "fsl,fman-v2-port-tx";
> + reg = <0xac000 0x1000>;
> + };
> +
> + fman1_tx_0x30: port@b0000 {
> + cell-index = <0x30>;
> + compatible = "fsl,fman-v2-port-tx";
> + reg = <0xb0000 0x1000>;
> + };
> +
> + ethernet@e0000 {
> + compatible = "fsl,fman-dtsec";
> + cell-index = <0>;
> + reg = <0xe0000 0x1000>;
> + fsl,fman-ports = <&fman1_rx_0x8 &fman1_tx_0x28>;
> + };
> +
> + ethernet@e2000 {
> + compatible = "fsl,fman-dtsec";
> + cell-index = <1>;
> + reg = <0xe2000 0x1000>;
> + fsl,fman-ports = <&fman1_rx_0x9 &fman1_tx_0x29>;
> + };
> +
> + ethernet@e4000 {
> + compatible = "fsl,fman-dtsec";
> + cell-index = <2>;
> + reg = <0xe4000 0x1000>;
> + fsl,fman-ports = <&fman1_rx_0xa &fman1_tx_0x2a>;
> + };
> +
> + ethernet@e6000 {
> + compatible = "fsl,fman-dtsec";
> + cell-index = <3>;
> + reg = <0xe6000 0x1000>;
> + fsl,fman-ports = <&fman1_rx_0xb &fman1_tx_0x2b>;
> + };
> +
> + ethernet@e8000 {
> + compatible = "fsl,fman-dtsec";
> + cell-index = <4>;
> + reg = <0xf0000 0x1000>;
> + fsl,fman-ports = <&fman1_rx_0xc &fman1_tx_0x2c>;
> +
> + ethernet@f0000 {
> + cell-index = <8>;
> + compatible = "fsl,fman-xgec";
> + reg = <0xf0000 0x1000>;
> + fsl,fman-ports = <&fman1_rx_0x10 &fman1_tx_0x30>;
> + };
> +
> + ptp-timer@fe000 {
> + compatible = "fsl,fman-ptp-timer";
> + reg = <0xfe000 0x1000>;
> + };
> +};
>
^ permalink raw reply
* Re: [PATCHv4] clk: ppc-corenet: rename to ppc-qoriq and add CLK_OF_DECLARE support
From: Mike Turquette @ 2014-09-26 23:29 UTC (permalink / raw)
To: Scott Wood
Cc: linuxppc-dev@lists.ozlabs.org, linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, Lu Jingchang-B35083
In-Reply-To: <1411685780.13320.209.camel@snotra.buserror.net>
Quoting Scott Wood (2014-09-25 15:56:20)
> On Thu, 2014-09-25 at 15:54 -0700, Mike Turquette wrote:
> > Quoting Scott Wood (2014-09-25 13:08:00)
> > > Well, like I said, I'd rather see the CLK_OF_DECLARE stuff be made to
> > > work on PPC rather than have the driver carry around two binding
> > > methods.
> > =
> > I guess that is an existing problem, and not related directly to this
> > patch? This patch is essentially just renames (though the V1.0/V2.0
> > stuff seems weird).
> =
> This patch is adding CLK_OF_DECLARE.
I'm fine taking this patch but your comments are still unresolved. What
do you think needs to be done to fix the problems that you see?
Regards,
Mike
> =
> -Scott
> =
>=20
^ permalink raw reply
* Re: [PATCH 3/3] powerpc/ftrace: simplify prepare_ftrace_return
From: Segher Boessenkool @ 2014-09-27 0:22 UTC (permalink / raw)
To: Anton Blanchard; +Cc: paulus, linuxppc-dev, Steven Rostedt, Alan Modra
In-Reply-To: <20140924123307.7649bec8@kryten>
On Wed, Sep 24, 2014 at 12:33:07PM +1000, Anton Blanchard wrote:
> We are scratching our heads trying to remember details of the issue
> right now. In retrospect we should have linked the gcc bugzilla or
> gcc commit details in the kernel commit message :)
There have been many GCC bugs in this area.
30282 (for 32-bit)
44199 (for 64-bit)
52828 (for everything, and this one should finally handle things for good)
Also a bunch of duplicates, and I'm sure I've missed some more.
The original issue as far as I remember: when using a frame pointer, GCC
would sometimes schedule the epilogue to do the stack adjust before
restoring all regs from the stack. Then an interrupt comes in, those
saved regs are clobbered, kaboom. We cannot disable the frame pointer
because -pg forces it (although PowerPC does not need it). The
-mno-sched-epilog flag is a workaround: the epilogue (and prologue) will
not be reordered by instruction scheduling. Slow code is better than
blowing up fast ;-)
Segher
^ permalink raw reply
* Re: [PATCH v2 00/22] Use MSI chip framework to configure MSI/MSI-X in all platforms
From: Yijing Wang @ 2014-09-28 2:16 UTC (permalink / raw)
To: Liviu Dudau
Cc: linux-mips, linux-ia64, linux-pci, Bharat.Bhushan, Thierry Reding,
sparclinux, linux-arch, linux-s390, Russell King, Joerg Roedel,
x86, Sebastian Ott, xen-devel, arnab.basu, Arnd Bergmann,
Konrad Rzeszutek Wilk, Chris Metcalf, Bjorn Helgaas,
Thomas Gleixner, linux-arm-kernel, Thomas Petazzoni, Xinwei Hu,
Tony Luck, Sergei Shtylyov, linux-kernel, Ralf Baechle, iommu,
David Vrabel, Wuyun, linuxppc-dev, David S. Miller, Lucas Stach
In-Reply-To: <20140926085030.GE31157@bart.dudau.co.uk>
>>>> What I would like to see is a way of creating the pci_host_bridge structure outside
>>>> the pci_create_root_bus(). That would then allow us to pass this sort of platform
>>>> details like associated msi_chip into the host bridge and the child busses will
>>>> have an easy way of finding the information needed by finding the root bus and then
>>>> the host bridge structure. Then the generic pci_scan_root_bus() can be used by (mostly)
>>>> everyone and the drivers can remove their kludges that try to work around the
>>>> current limitations.
>>
>> So I think maybe save msi chip in PCI arch sysdata is a good candidate.
>
> Except that arch sysdata at the moment is an opaque pointer. I am all in favour in
> changing the type of sysdata from void* into pci_host_bridge* and arches can wrap their old
> sysdata around the pci_host_bridge*.
I inspected every arch and found there are almost no common stuff, and generic data struct should
be created in generic PCI code. Another, I don't like associate msi chip and every PCI device, further more,
almost all platforms except arm have only one MSI controller, and currently, PCI enumerating code doesn't need
to know the MSI chip details, like for legacy IRQ, PCI device doesn't need to know which IRQ controller they
should deliver IRQ to. I would think more about it, and hope other PCI guys can give some comments, especially from Bjorn.
Thanks!
Yijing.
>
> Best regards,
> Liviu
>
>>
>>>
>>> I think both issues are orthogonal. Last time I checked a lot of work
>>> was still necessary to unify host bridges enough so that it could be
>>> shared across architectures. But perhaps some of that work has
>>> happened in the meantime.
>>>
>>> But like I said, when you create the root bus, you can easily attach the
>>> MSI chip to it.
>>>
>>> Thierry
>>>
>>
>>
>> --
>> Thanks!
>> Yijing
>>
>>
>
--
Thanks!
Yijing
^ permalink raw reply
* Re: [PATCH v2 00/22] Use MSI chip framework to configure MSI/MSI-X in all platforms
From: Yijing Wang @ 2014-09-28 2:32 UTC (permalink / raw)
To: Thierry Reding
Cc: linux-mips, linux-ia64, linux-pci, Xinwei Hu, sparclinux,
linux-arch, linux-s390, Russell King, Joerg Roedel, x86,
Sebastian Ott, Bharat.Bhushan, xen-devel, arnab.basu,
Arnd Bergmann, Konrad Rzeszutek Wilk, Chris Metcalf,
Bjorn Helgaas, Thomas Gleixner, linux-arm-kernel,
Thomas Petazzoni, Liviu Dudau, Tony Luck, Sergei Shtylyov,
linux-kernel, Ralf Baechle, iommu, David Vrabel, Wuyun,
linuxppc-dev, David S. Miller, Lucas Stach
In-Reply-To: <20140926090537.GH31106@ulmo>
On 2014/9/26 17:05, Thierry Reding wrote:
> On Fri, Sep 26, 2014 at 10:54:32AM +0200, Thierry Reding wrote:
> [...]
>> At least for Tegra it's trivial to just hook it up in tegra_pcie_scan_bus()
>> directly (patch attached).
>
> Really attached this time.
>
> Thierry
>
It looks good to me, so I will update the arm pci hostbridge driver to assign
pci root bus the msi chip instead of current pcibios_add_bus(). But for other
platforms which only have a one msi chip, I will kept the arch_find_msi_chip()
temporarily for more comments, especially from Bjorn.
Thanks!
Yijing.
--
Thanks!
Yijing
^ permalink raw reply
* Re: [PATCH v2 06/22] PCI/MSI: Introduce weak arch_find_msi_chip() to find MSI chip
From: Yijing Wang @ 2014-09-28 2:35 UTC (permalink / raw)
To: Thomas Gleixner
Cc: linux-mips, linux-ia64, linux-pci, Bharat.Bhushan, Thierry Reding,
sparclinux, linux-arch, linux-s390, Russell King, Joerg Roedel,
x86, Sebastian Ott, xen-devel, arnab.basu, Arnd Bergmann,
Konrad Rzeszutek Wilk, Chris Metcalf, Bjorn Helgaas,
linux-arm-kernel, Thomas Petazzoni, Xinwei Hu, Tony Luck,
Sergei Shtylyov, linux-kernel, Ralf Baechle, iommu, David Vrabel,
Wuyun, linuxppc-dev, David S. Miller, Lucas Stach
In-Reply-To: <alpine.DEB.2.11.1409261236160.4567@nanos>
>> MSI chip in this series is to setup MSI irq, including IRQ allocation, Map,
>> compose MSI msg ..., in different platform, many arch specific MSI irq details in it.
>> It's difficult to extract the common data and code.
>>
>> I have a plan to rework MSI related irq_chips in kernel, PCI and Non-PCI, currently,
>> HPET, DMAR and PCI have their own irq_chip and MSI related functions, write_msi_msg(),
>> mask_msi_irq(), etc... I want to extract the common data set for that, so we can
>> remove lots of unnecessary MSI code.
>
> That makes sense. Can you please make sure that this does not conflict
> with the ongoing work Jiang is doing in the x86 irq area with
> hierarchical irqdomains to distangle layered levels like MSI from the
> underlying vector/irqremap mechanics.
Yes, I'm reviewing Jiang hierarchical irqdomains series, I'm interested in that changes.
Thanks!
Yijing.
>
> Thanks,
>
> tglx
>
> .
>
--
Thanks!
Yijing
^ permalink raw reply
* RE: [PATCHv4] clk: ppc-corenet: rename to ppc-qoriq and add CLK_OF_DECLARE support
From: Yuantian Tang @ 2014-09-28 2:18 UTC (permalink / raw)
To: Mike Turquette, Scott Wood
Cc: linuxppc-dev@lists.ozlabs.org, linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, Jingchang Lu
In-Reply-To: <20140926232900.19023.35854@quantum>
PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBMaW51eHBwYy1kZXYNCj4gW21h
aWx0bzpsaW51eHBwYy1kZXYtYm91bmNlcytiMjk5ODM9ZnJlZXNjYWxlLmNvbUBsaXN0cy5vemxh
YnMub3JnXSBPbg0KPiBCZWhhbGYgT2YgTWlrZSBUdXJxdWV0dGUNCj4gU2VudDogU2F0dXJkYXks
IFNlcHRlbWJlciAyNywgMjAxNCA3OjI5IEFNDQo+IFRvOiBXb29kIFNjb3R0LUIwNzQyMQ0KPiBD
YzogbGludXhwcGMtZGV2QGxpc3RzLm96bGFicy5vcmc7IGxpbnV4LWtlcm5lbEB2Z2VyLmtlcm5l
bC5vcmc7DQo+IGxpbnV4LWFybS1rZXJuZWxAbGlzdHMuaW5mcmFkZWFkLm9yZzsgTHUgSmluZ2No
YW5nLUIzNTA4Mw0KPiBTdWJqZWN0OiBSZTogW1BBVENIdjRdIGNsazogcHBjLWNvcmVuZXQ6IHJl
bmFtZSB0byBwcGMtcW9yaXEgYW5kIGFkZA0KPiBDTEtfT0ZfREVDTEFSRSBzdXBwb3J0DQo+IA0K
PiBRdW90aW5nIFNjb3R0IFdvb2QgKDIwMTQtMDktMjUgMTU6NTY6MjApDQo+ID4gT24gVGh1LCAy
MDE0LTA5LTI1IGF0IDE1OjU0IC0wNzAwLCBNaWtlIFR1cnF1ZXR0ZSB3cm90ZToNCj4gPiA+IFF1
b3RpbmcgU2NvdHQgV29vZCAoMjAxNC0wOS0yNSAxMzowODowMCkNCj4gPiA+ID4gV2VsbCwgbGlr
ZSBJIHNhaWQsIEknZCByYXRoZXIgc2VlIHRoZSBDTEtfT0ZfREVDTEFSRSBzdHVmZiBiZSBtYWRl
DQo+ID4gPiA+IHRvIHdvcmsgb24gUFBDIHJhdGhlciB0aGFuIGhhdmUgdGhlIGRyaXZlciBjYXJy
eSBhcm91bmQgdHdvDQo+ID4gPiA+IGJpbmRpbmcgbWV0aG9kcy4NCj4gPiA+DQo+ID4gPiBJIGd1
ZXNzIHRoYXQgaXMgYW4gZXhpc3RpbmcgcHJvYmxlbSwgYW5kIG5vdCByZWxhdGVkIGRpcmVjdGx5
IHRvDQo+ID4gPiB0aGlzIHBhdGNoPyBUaGlzIHBhdGNoIGlzIGVzc2VudGlhbGx5IGp1c3QgcmVu
YW1lcyAodGhvdWdoIHRoZQ0KPiA+ID4gVjEuMC9WMi4wIHN0dWZmIHNlZW1zIHdlaXJkKS4NCj4g
Pg0KPiA+IFRoaXMgcGF0Y2ggaXMgYWRkaW5nIENMS19PRl9ERUNMQVJFLg0KPiANCj4gSSdtIGZp
bmUgdGFraW5nIHRoaXMgcGF0Y2ggYnV0IHlvdXIgY29tbWVudHMgYXJlIHN0aWxsIHVucmVzb2x2
ZWQuIFdoYXQgZG8geW91DQo+IHRoaW5rIG5lZWRzIHRvIGJlIGRvbmUgdG8gZml4IHRoZSBwcm9i
bGVtcyB0aGF0IHlvdSBzZWU/DQo+IA0KQ0xLX09GX0RFQ0xBUkUgaXMgdG90YWxseSB3b3JrZWQg
b24gUFBDLiBJIHdpbGwgZG8gaXQgaW4gYSBzZXBhcmF0ZSBwYXRjaC4NClJlZ2FyZGluZyBWMS4w
IGFuZCBWMi4wLCBpdCBpcyBub3Qgd2lyZWQganVzdCBzYW1lIGZvciBub3cuIEJ1dCB3ZSBhcmUg
bm90IHN1cmUgaWYgaXQgaXMgc2FtZSBmb3IgdjMuMCBpbiB0aGUgZnV0dXJlLg0KDQpCZXNpZGVz
IHVwZGF0aW5nIGRyaXZlcnMvY3B1ZnJlcS9LY29uZmlnLnBvd2VycGMsIHRoZXJlIGlzIG9uZSBt
b3JlIHRoaW5nIEkgYW0gbm90IGNvbWZvcnRhYmxlIHdpdGg6DQpUaGlzIHBhdGNoIHVzZXMgIiBm
aXhlZC1jbG9jayIgYXMgc3lzY2xrJ3MgY29tcGF0aWJsZSBzdHJpbmcsIHdoaWxlIG9uIFBQQyB3
ZSB0cmVhdGVkIGl0IGFzICIgZnNsLHFvcmlxLXN5c2Nsay1bMS0yXS4wIi4NClRoYXQncyBpbmNv
bnNpc3RlbnQgb24gYm90aCBBUk0gYW5kIFBQQyBwbGF0Zm9ybXMsIG5laXRoZXIgZGlkIG9uIGJp
bmRpbmdzLg0KDQpUaGFua3MsDQpZdWFudGlhbg0KDQo+IFJlZ2FyZHMsDQo+IE1pa2UNCj4gDQo+
ID4NCj4gPiAtU2NvdHQNCj4gPg0KPiA+DQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fDQo+IExpbnV4cHBjLWRldiBtYWlsaW5nIGxpc3QNCj4gTGludXhw
cGMtZGV2QGxpc3RzLm96bGFicy5vcmcNCj4gaHR0cHM6Ly9saXN0cy5vemxhYnMub3JnL2xpc3Rp
bmZvL2xpbnV4cHBjLWRldg0K
^ permalink raw reply
* Re: [PATCH v2 00/22] Use MSI chip framework to configure MSI/MSI-X in all platforms
From: Yijing Wang @ 2014-09-28 6:11 UTC (permalink / raw)
To: Thierry Reding
Cc: linux-mips, linux-ia64, linux-pci, Xinwei Hu, sparclinux,
linux-arch, linux-s390, Russell King, Joerg Roedel, x86,
Sebastian Ott, Bharat.Bhushan, xen-devel, arnab.basu,
Arnd Bergmann, Konrad Rzeszutek Wilk, Chris Metcalf,
Bjorn Helgaas, Thomas Gleixner, linux-arm-kernel,
Thomas Petazzoni, Liviu Dudau, Tony Luck, Sergei Shtylyov,
linux-kernel, Ralf Baechle, iommu, David Vrabel, Wuyun,
linuxppc-dev, David S. Miller, Lucas Stach
In-Reply-To: <54277327.6070500@huawei.com>
On 2014/9/28 10:32, Yijing Wang wrote:
> On 2014/9/26 17:05, Thierry Reding wrote:
>> On Fri, Sep 26, 2014 at 10:54:32AM +0200, Thierry Reding wrote:
>> [...]
>>> At least for Tegra it's trivial to just hook it up in tegra_pcie_scan_bus()
>>> directly (patch attached).
>>
>> Really attached this time.
>>
>> Thierry
>>
>
> It looks good to me, so I will update the arm pci hostbridge driver to assign
> pci root bus the msi chip instead of current pcibios_add_bus(). But for other
> platforms which only have a one msi chip, I will kept the arch_find_msi_chip()
> temporarily for more comments, especially from Bjorn.
Oh, sorry, I found designware and rcar use pci_scan_root_bus(), so we can not simply
assign msi chip to root bus in all host drivers's scan functions.
>
> Thanks!
> Yijing.
>
--
Thanks!
Yijing
^ permalink raw reply
* RE: [PATCHv4] clk: ppc-corenet: rename to ppc-qoriq and add CLK_OF_DECLARE support
From: Jingchang Lu @ 2014-09-28 10:01 UTC (permalink / raw)
To: Laurentiu.Tudor@freescale.com, mturquette@linaro.org
Cc: Scott Wood, linuxppc-dev@lists.ozlabs.org,
linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <542410D3.2060507@freescale.com>
Pi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+RnJvbTogVHVkb3IgTGF1cmVudGl1LUIxMDcx
Ng0KPlNlbnQ6IFRodXJzZGF5LCBTZXB0ZW1iZXIgMjUsIDIwMTQgODo1NiBQTQ0KPlRvOiBMdSBK
aW5nY2hhbmctQjM1MDgzOyBtdHVycXVldHRlQGxpbmFyby5vcmcNCj5DYzogV29vZCBTY290dC1C
MDc0MjE7IGxpbnV4cHBjLWRldkBsaXN0cy5vemxhYnMub3JnOyBsaW51eC0NCj5rZXJuZWxAdmdl
ci5rZXJuZWwub3JnOyBsaW51eC1hcm0ta2VybmVsQGxpc3RzLmluZnJhZGVhZC5vcmcNCj5TdWJq
ZWN0OiBSZTogW1BBVENIdjRdIGNsazogcHBjLWNvcmVuZXQ6IHJlbmFtZSB0byBwcGMtcW9yaXEg
YW5kIGFkZA0KPkNMS19PRl9ERUNMQVJFIHN1cHBvcnQNCj4NCj5IaSBKaW5nY2hhbmcsDQo+DQo+
T24gMDkvMjMvMjAxNCAwOTo0NiBBTSwgSmluZ2NoYW5nIEx1IHdyb3RlOg0KPj4gVGhlIElQIGlz
IHNoYXJlZCBieSBQUEMgYW5kIEFSTSwgdGhpcyByZW5hbWVzIGl0IHRvIHFvcmlxIGZvciBiZXR0
ZXINCj4+IHJlcHJlc2VudGlvbiwgYW5kIHRoaXMgYWxzbyBhZGRzIHRoZSBDTEtfT0ZfREVDTEFS
RSBzdXBwb3J0IGZvciBiZWluZw0KPj4gaW5pdGlhbGl6ZWQgYnkgb2ZfY2xrX2luaXQoKSBvbiBB
Uk0uDQo+Pg0KPg0KPkkgdGhpbmsgeW91IG5lZWQgdG8gYWxzbyB1cGRhdGUgZHJpdmVycy9jcHVm
cmVxL0tjb25maWcucG93ZXJwYyB0byB1c2UgdGhlDQo+cmVuYW1lZCBjb25maWcgb3B0aW9uLg0K
Pg0KDQpUaGFua3MsIEkgd2lsbCB1cGRhdGUgdGhhdCBzZWxlY3RlZCBjb25maWcgb3B0aW9uIG9m
IENMS19QUENfQ09SRU5FVC4NCg0KQmVzdCBSZWdhcmRzLA0KSmluZ2NoYW5nDQo+LS0tDQo+QmVz
dCBSZWdhcmRzLCBMYXVyZW50aXUNCg0KDQo=
^ permalink raw reply
* Re: [PATCH v2 00/22] Use MSI chip framework to configure MSI/MSI-X in all platforms
From: Liviu Dudau @ 2014-09-28 11:21 UTC (permalink / raw)
To: Yijing Wang
Cc: linux-mips, linux-ia64, linux-pci, Bharat.Bhushan, Thierry Reding,
sparclinux, linux-arch, linux-s390, Russell King, Joerg Roedel,
x86, Sebastian Ott, xen-devel, arnab.basu, Arnd Bergmann,
Konrad Rzeszutek Wilk, Chris Metcalf, Bjorn Helgaas,
Thomas Gleixner, linux-arm-kernel, Thomas Petazzoni, Xinwei Hu,
Tony Luck, Sergei Shtylyov, linux-kernel, Ralf Baechle, iommu,
David Vrabel, Wuyun, linuxppc-dev, David S. Miller, Lucas Stach
In-Reply-To: <54276F6C.5010705@huawei.com>
On Sun, Sep 28, 2014 at 10:16:12AM +0800, Yijing Wang wrote:
> >>>> What I would like to see is a way of creating the pci_host_bridge structure outside
> >>>> the pci_create_root_bus(). That would then allow us to pass this sort of platform
> >>>> details like associated msi_chip into the host bridge and the child busses will
> >>>> have an easy way of finding the information needed by finding the root bus and then
> >>>> the host bridge structure. Then the generic pci_scan_root_bus() can be used by (mostly)
> >>>> everyone and the drivers can remove their kludges that try to work around the
> >>>> current limitations.
> >>
> >> So I think maybe save msi chip in PCI arch sysdata is a good candidate.
> >
> > Except that arch sysdata at the moment is an opaque pointer. I am all in favour in
> > changing the type of sysdata from void* into pci_host_bridge* and arches can wrap their old
> > sysdata around the pci_host_bridge*.
>
> I inspected every arch and found there are almost no common stuff,
I will disagree here. Most (all?) of the structures that are passed as sysdata argument to
pci_create_root_bus() or pci_scan_root_bus() have a set of resources for storing the MEM and
IO ranges, which struct pci_host_bridge already has. So that can be factored out of the
arch code. Same for pci_domain_nr. Then there are some variables that are used for communication
with the platform code due to convoluted way(s) in which PCI code gets instantiated.
What I am arguing here is not that the arch equivalent of pci_host_bridge structure is already
common, but that by moving the members that are common out of arch sysdata into pci_host_bridge
we will have more commonality and it will be easier to re-factor the code.
> and generic data struct should
> be created in generic PCI code.
Not necessarily. What I have in mind is something like this:
- drivers/pci/ exports pci_init_host_bridge() that does the initialisation of bridge->windows
and anything else that is needed (like find_pci_host_bridge() function).
- arch code does:
struct pci_controller {
struct pci_host_bridge bridge;
.....
};
#define to_pci_controller(bridge) container_of(bridge, struct pci_controller, bridge)
static inline struct pci_controller *get_host_controller(const struct pci_bus *bus)
{
struct pci_host_bridge *bridge = find_pci_host_bridge(bus);
if (bridge)
return to_pci_controller(bridge);
return NULL;
}
int arch_pci_init(....)
{
struct pci_controller *hose;
....
hose = kzalloc(sizeof(*hose), GFP_KERNEL);
pci_init_host_bridge(&hose->bridge);
....
pci_scan_root_bus(...., &hose->bridge, &resources);
....
return 0;
}
Then finding the right structure will be easy.
> Another, I don't like associate msi chip and every PCI device, further more,
> almost all platforms except arm have only one MSI controller, and currently, PCI enumerating code doesn't need
> to know the MSI chip details, like for legacy IRQ, PCI device doesn't need to know which IRQ controller they
> should deliver IRQ to. I would think more about it, and hope other PCI guys can give some comments, especially from Bjorn.
>
I wasn't suggesing to associate an msi chip with every PCI device, but with the pci_host_bridge.
I don't expect a host bridge to have more than one msi chip, so that should be OK. Also, I'm
thinking that getting the associated msi chip should be some sort of pci_host_bridge ops function,
and for arches that don't care about MSI it doesn't get implemented.
Best regards,
Liviu
> Thanks!
> Yijing.
>
> >
> > Best regards,
> > Liviu
> >
> >>
> >>>
> >>> I think both issues are orthogonal. Last time I checked a lot of work
> >>> was still necessary to unify host bridges enough so that it could be
> >>> shared across architectures. But perhaps some of that work has
> >>> happened in the meantime.
> >>>
> >>> But like I said, when you create the root bus, you can easily attach the
> >>> MSI chip to it.
> >>>
> >>> Thierry
> >>>
> >>
> >>
> >> --
> >> Thanks!
> >> Yijing
> >>
> >>
> >
>
>
> --
> Thanks!
> Yijing
>
>
--
-------------------
.oooO
( )
\ ( Oooo.
\_) ( )
) /
(_/
One small step
for me ...
^ permalink raw reply
* Re: [PATCH v2 00/22] Use MSI chip framework to configure MSI/MSI-X in all platforms
From: Yijing Wang @ 2014-09-29 1:44 UTC (permalink / raw)
To: Liviu Dudau
Cc: linux-mips, linux-ia64, linux-pci, Bharat.Bhushan, Thierry Reding,
sparclinux, linux-arch, linux-s390, Russell King, Joerg Roedel,
x86, Sebastian Ott, xen-devel, arnab.basu, Arnd Bergmann,
Konrad Rzeszutek Wilk, Chris Metcalf, Bjorn Helgaas,
Thomas Gleixner, linux-arm-kernel, Thomas Petazzoni, Xinwei Hu,
Tony Luck, Sergei Shtylyov, linux-kernel, Ralf Baechle, iommu,
David Vrabel, Wuyun, linuxppc-dev, David S. Miller, Lucas Stach
In-Reply-To: <20140928112144.GA4671@bart.dudau.co.uk>
On 2014/9/28 19:21, Liviu Dudau wrote:
> On Sun, Sep 28, 2014 at 10:16:12AM +0800, Yijing Wang wrote:
>>>>>> What I would like to see is a way of creating the pci_host_bridge structure outside
>>>>>> the pci_create_root_bus(). That would then allow us to pass this sort of platform
>>>>>> details like associated msi_chip into the host bridge and the child busses will
>>>>>> have an easy way of finding the information needed by finding the root bus and then
>>>>>> the host bridge structure. Then the generic pci_scan_root_bus() can be used by (mostly)
>>>>>> everyone and the drivers can remove their kludges that try to work around the
>>>>>> current limitations.
>>>>
>>>> So I think maybe save msi chip in PCI arch sysdata is a good candidate.
>>>
>>> Except that arch sysdata at the moment is an opaque pointer. I am all in favour in
>>> changing the type of sysdata from void* into pci_host_bridge* and arches can wrap their old
>>> sysdata around the pci_host_bridge*.
>>
>> I inspected every arch and found there are almost no common stuff,
>
> I will disagree here. Most (all?) of the structures that are passed as sysdata argument to
Most.
> pci_create_root_bus() or pci_scan_root_bus() have a set of resources for storing the MEM and
> IO ranges, which struct pci_host_bridge already has. So that can be factored out of the
> arch code. Same for pci_domain_nr. Then there are some variables that are used for communication
> with the platform code due to convoluted way(s) in which PCI code gets instantiated.
Yes, currently some archs store MEM and IO resource in pci sysdata, and others not, move the MEM and IO
resource to pci_host_bride could make code become simple, we can clean up the resource list argument in
pci scan functions.
>
> What I am arguing here is not that the arch equivalent of pci_host_bridge structure is already
> common, but that by moving the members that are common out of arch sysdata into pci_host_bridge
> we will have more commonality and it will be easier to re-factor the code.
Now, I got it, thanks!
>
>> and generic data struct should
>> be created in generic PCI code.
>
> Not necessarily. What I have in mind is something like this:
This is a good idea, what I'm worried is this series is already large, so I think we need to post
another series to do it.
>
> - drivers/pci/ exports pci_init_host_bridge() that does the initialisation of bridge->windows
> and anything else that is needed (like find_pci_host_bridge() function).
> - arch code does:
>
> struct pci_controller {
> struct pci_host_bridge bridge;
> .....
> };
>
> #define to_pci_controller(bridge) container_of(bridge, struct pci_controller, bridge)
>
> static inline struct pci_controller *get_host_controller(const struct pci_bus *bus)
> {
> struct pci_host_bridge *bridge = find_pci_host_bridge(bus);
> if (bridge)
> return to_pci_controller(bridge);
>
> return NULL;
> }
>
> int arch_pci_init(....)
> {
> struct pci_controller *hose;
> ....
> hose = kzalloc(sizeof(*hose), GFP_KERNEL);
> pci_init_host_bridge(&hose->bridge);
> ....
> pci_scan_root_bus(...., &hose->bridge, &resources);
> ....
> return 0;
> }
>
> Then finding the right structure will be easy.
>
>> Another, I don't like associate msi chip and every PCI device, further more,
>> almost all platforms except arm have only one MSI controller, and currently, PCI enumerating code doesn't need
>> to know the MSI chip details, like for legacy IRQ, PCI device doesn't need to know which IRQ controller they
>> should deliver IRQ to. I would think more about it, and hope other PCI guys can give some comments, especially from Bjorn.
>>
>
> I wasn't suggesing to associate an msi chip with every PCI device, but with the pci_host_bridge.
> I don't expect a host bridge to have more than one msi chip, so that should be OK. Also, I'm
> thinking that getting the associated msi chip should be some sort of pci_host_bridge ops function,
> and for arches that don't care about MSI it doesn't get implemented.
Currently, a property "msi-parent" was introduced in arm, and all msi chip integrated in irq chip controller will
be added to of_pci_msi_chip_list. PCI host driver find the match msi chip by its of_node.
Thanks!
Yijing.
>
> Best regards,
> Liviu
>
>
>> Thanks!
>> Yijing.
>>
>>>
>>> Best regards,
>>> Liviu
>>>
>>>>
>>>>>
>>>>> I think both issues are orthogonal. Last time I checked a lot of work
>>>>> was still necessary to unify host bridges enough so that it could be
>>>>> shared across architectures. But perhaps some of that work has
>>>>> happened in the meantime.
>>>>>
>>>>> But like I said, when you create the root bus, you can easily attach the
>>>>> MSI chip to it.
>>>>>
>>>>> Thierry
>>>>>
>>>>
>>>>
>>>> --
>>>> Thanks!
>>>> Yijing
>>>>
>>>>
>>>
>>
>>
>> --
>> Thanks!
>> Yijing
>>
>>
>
--
Thanks!
Yijing
^ permalink raw reply
* [PATCH] KVM: PPC: BOOK3S: HV: CMA: Reserve cma region only in hypervisor mode
From: Aneesh Kumar K.V @ 2014-09-29 8:02 UTC (permalink / raw)
To: agraf, benh, paulus; +Cc: linuxppc-dev, kvm, kvm-ppc, Aneesh Kumar K.V
We use cma reserved area for creating guest hash page table.
Don't do the reservation in non-hypervisor mode. This avoids unnecessary
CMA reservation when booting with limited memory configs like
fadump and kdump.
Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
---
arch/powerpc/kvm/book3s_hv_builtin.c | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/arch/powerpc/kvm/book3s_hv_builtin.c b/arch/powerpc/kvm/book3s_hv_builtin.c
index b9615ba5b083..4fdc27c80f4c 100644
--- a/arch/powerpc/kvm/book3s_hv_builtin.c
+++ b/arch/powerpc/kvm/book3s_hv_builtin.c
@@ -163,6 +163,12 @@ void __init kvm_cma_reserve(void)
unsigned long align_size;
struct memblock_region *reg;
phys_addr_t selected_size = 0;
+
+ /*
+ * We need CMA reservation only when we are in HV mode
+ */
+ if (!cpu_has_feature(CPU_FTR_HVMODE))
+ return;
/*
* We cannot use memblock_phys_mem_size() here, because
* memblock_analyze() has not been called yet.
--
1.9.1
^ permalink raw reply related
* Re: [PATCH] KVM: PPC: BOOK3S: HV: CMA: Reserve cma region only in hypervisor mode
From: Alexander Graf @ 2014-09-29 8:28 UTC (permalink / raw)
To: Aneesh Kumar K.V, benh, paulus; +Cc: linuxppc-dev, kvm, kvm-ppc
In-Reply-To: <1411977758-24506-1-git-send-email-aneesh.kumar@linux.vnet.ibm.com>
On 29.09.14 10:02, Aneesh Kumar K.V wrote:
> We use cma reserved area for creating guest hash page table.
> Don't do the reservation in non-hypervisor mode. This avoids unnecessary
> CMA reservation when booting with limited memory configs like
> fadump and kdump.
>
> Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
Thanks, applied to kvm-ppc-queue.
Alex
^ permalink raw reply
* Re: [PATCH 02/15] powerpc/cell: Move data segment faulting code out of cell platform
From: Aneesh Kumar K.V @ 2014-09-29 8:30 UTC (permalink / raw)
To: Michael Neuling, greg, arnd, mpe, benh
Cc: cbe-oss-dev, mikey, linux-kernel, linuxppc-dev, jk, imunsie,
anton
In-Reply-To: <1411028820-29933-3-git-send-email-mikey@neuling.org>
Michael Neuling <mikey@neuling.org> writes:
> From: Ian Munsie <imunsie@au1.ibm.com>
>
> __spu_trap_data_seg() currently contains code to determine the VSID and ESID
> required for a particular EA and mm struct.
>
> This code is generically useful for other co-processors. This moves the code
> of the cell platform so it can be used by other powerpc code.
>
> Signed-off-by: Ian Munsie <imunsie@au1.ibm.com>
> Signed-off-by: Michael Neuling <mikey@neuling.org>
> ---
> arch/powerpc/include/asm/mmu-hash64.h | 2 ++
> arch/powerpc/mm/copro_fault.c | 48 ++++++++++++++++++++++++++++++++++
> arch/powerpc/mm/slb.c | 3 ---
> arch/powerpc/platforms/cell/spu_base.c | 41 +++--------------------------
> 4 files changed, 54 insertions(+), 40 deletions(-)
>
> diff --git a/arch/powerpc/include/asm/mmu-hash64.h b/arch/powerpc/include/asm/mmu-hash64.h
> index d765144..fd19a53 100644
> --- a/arch/powerpc/include/asm/mmu-hash64.h
> +++ b/arch/powerpc/include/asm/mmu-hash64.h
> @@ -180,6 +180,8 @@ static inline unsigned int mmu_psize_to_shift(unsigned int mmu_psize)
> * we work in all cases including 4k page size.
> */
> #define VPN_SHIFT 12
> +#define slb_vsid_shift(ssize) \
> + ((ssize) == MMU_SEGSIZE_256M ? SLB_VSID_SHIFT : SLB_VSID_SHIFT_1T)
can it be static inline similar to segment_shift() ?
>
> /*
> * HPTE Large Page (LP) details
> diff --git a/arch/powerpc/mm/copro_fault.c b/arch/powerpc/mm/copro_fault.c
> index ba7df14..4105a63 100644
> --- a/arch/powerpc/mm/copro_fault.c
> +++ b/arch/powerpc/mm/copro_fault.c
> @@ -90,3 +90,51 @@ out_unlock:
> return ret;
> }
> EXPORT_SYMBOL_GPL(copro_handle_mm_fault);
> +
> +int copro_data_segment(struct mm_struct *mm, u64 ea, u64 *esid, u64 *vsid)
> +{
> + int psize, ssize;
> +
> + *esid = (ea & ESID_MASK) | SLB_ESID_V;
> +
> + switch (REGION_ID(ea)) {
> + case USER_REGION_ID:
> + pr_devel("copro_data_segment: 0x%llx -- USER_REGION_ID\n", ea);
> +#ifdef CONFIG_PPC_MM_SLICES
> + psize = get_slice_psize(mm, ea);
> +#else
> + psize = mm->context.user_psize;
> +#endif
We don't need that.
#ifdef CONFIG_PPC_STD_MMU_64
#define get_slice_psize(mm, addr) ((mm)->context.user_psize)
> + ssize = user_segment_size(ea);
> + *vsid = (get_vsid(mm->context.id, ea, ssize)
> + << slb_vsid_shift(ssize)) | SLB_VSID_USER
> + | (ssize == MMU_SEGSIZE_1T ? SLB_VSID_B_1T : 0);
> + break;
> + case VMALLOC_REGION_ID:
> + pr_devel("copro_data_segment: 0x%llx -- VMALLOC_REGION_ID\n", ea);
> + if (ea < VMALLOC_END)
> + psize = mmu_vmalloc_psize;
> + else
> + psize = mmu_io_psize;
> + *vsid = (get_kernel_vsid(ea, mmu_kernel_ssize)
> + << SLB_VSID_SHIFT) | SLB_VSID_KERNEL
> + | (mmu_kernel_ssize == MMU_SEGSIZE_1T ? SLB_VSID_B_1T : 0);
> + break;
> + case KERNEL_REGION_ID:
> + pr_devel("copro_data_segment: 0x%llx -- KERNEL_REGION_ID\n", ea);
> + psize = mmu_linear_psize;
> + *vsid = (get_kernel_vsid(ea, mmu_kernel_ssize)
> + << SLB_VSID_SHIFT) | SLB_VSID_KERNEL
> + | (mmu_kernel_ssize == MMU_SEGSIZE_1T ? SLB_VSID_B_1T : 0);
> + break;
> + default:
> + /* Future: support kernel segments so that drivers can use the
> + * CoProcessors */
> + pr_debug("invalid region access at %016llx\n", ea);
> + return 1;
> + }
> + *vsid |= mmu_psize_defs[psize].sllp;
> +
> + return 0;
> +}
large part of this is same as what we do in hash_page. And we are not
really updating vsid here, it is vsid slb encoding. So why not abstract
the vsid part and use that in hash_page also ? That would have also taken
care of the above #ifdef.
> +EXPORT_SYMBOL_GPL(copro_data_segment);
> diff --git a/arch/powerpc/mm/slb.c b/arch/powerpc/mm/slb.c
> index 0399a67..6e450ca 100644
> --- a/arch/powerpc/mm/slb.c
> +++ b/arch/powerpc/mm/slb.c
> @@ -46,9 +46,6 @@ static inline unsigned long mk_esid_data(unsigned long ea, int ssize,
> return (ea & slb_esid_mask(ssize)) | SLB_ESID_V | slot;
> }
>
> -#define slb_vsid_shift(ssize) \
> - ((ssize) == MMU_SEGSIZE_256M? SLB_VSID_SHIFT: SLB_VSID_SHIFT_1T)
> -
> static inline unsigned long mk_vsid_data(unsigned long ea, int ssize,
> unsigned long flags)
> {
> diff --git a/arch/powerpc/platforms/cell/spu_base.c b/arch/powerpc/platforms/cell/spu_base.c
> index 2930d1e..fe004b1 100644
> --- a/arch/powerpc/platforms/cell/spu_base.c
> +++ b/arch/powerpc/platforms/cell/spu_base.c
> @@ -167,45 +167,12 @@ static inline void spu_load_slb(struct spu *spu, int slbe, struct spu_slb *slb)
>
> static int __spu_trap_data_seg(struct spu *spu, unsigned long ea)
> {
> - struct mm_struct *mm = spu->mm;
> struct spu_slb slb;
> - int psize;
> -
> - pr_debug("%s\n", __func__);
> -
> - slb.esid = (ea & ESID_MASK) | SLB_ESID_V;
> + int ret;
>
> - switch(REGION_ID(ea)) {
> - case USER_REGION_ID:
> -#ifdef CONFIG_PPC_MM_SLICES
> - psize = get_slice_psize(mm, ea);
> -#else
> - psize = mm->context.user_psize;
> -#endif
> - slb.vsid = (get_vsid(mm->context.id, ea, MMU_SEGSIZE_256M)
> - << SLB_VSID_SHIFT) | SLB_VSID_USER;
> - break;
> - case VMALLOC_REGION_ID:
> - if (ea < VMALLOC_END)
> - psize = mmu_vmalloc_psize;
> - else
> - psize = mmu_io_psize;
> - slb.vsid = (get_kernel_vsid(ea, MMU_SEGSIZE_256M)
> - << SLB_VSID_SHIFT) | SLB_VSID_KERNEL;
> - break;
> - case KERNEL_REGION_ID:
> - psize = mmu_linear_psize;
> - slb.vsid = (get_kernel_vsid(ea, MMU_SEGSIZE_256M)
> - << SLB_VSID_SHIFT) | SLB_VSID_KERNEL;
> - break;
> - default:
> - /* Future: support kernel segments so that drivers
> - * can use SPUs.
> - */
> - pr_debug("invalid region access at %016lx\n", ea);
> - return 1;
> - }
> - slb.vsid |= mmu_psize_defs[psize].sllp;
> + ret = copro_data_segment(spu->mm, ea, &slb.esid, &slb.vsid);
> + if (ret)
> + return ret;
>
> spu_load_slb(spu, spu->slb_replace, &slb);
>
-aneesh
^ permalink raw reply
* Re: [PATCH v2 00/22] Use MSI chip framework to configure MSI/MSI-X in all platforms
From: Lucas Stach @ 2014-09-29 8:37 UTC (permalink / raw)
To: Yijing Wang
Cc: linux-mips, linux-ia64, linux-pci, Xinwei Hu, Thierry Reding,
sparclinux, linux-arch, linux-s390, Russell King, Joerg Roedel,
x86, Sebastian Ott, Bharat.Bhushan, xen-devel, arnab.basu,
Arnd Bergmann, Konrad Rzeszutek Wilk, Chris Metcalf,
Bjorn Helgaas, Thomas Gleixner, linux-arm-kernel,
Thomas Petazzoni, Liviu Dudau, Tony Luck, Sergei Shtylyov,
linux-kernel, Ralf Baechle, iommu, David Vrabel, Wuyun,
linuxppc-dev, David S. Miller
In-Reply-To: <5427A6A0.5040703@huawei.com>
Am Sonntag, den 28.09.2014, 14:11 +0800 schrieb Yijing Wang:
> On 2014/9/28 10:32, Yijing Wang wrote:
> > On 2014/9/26 17:05, Thierry Reding wrote:
> >> On Fri, Sep 26, 2014 at 10:54:32AM +0200, Thierry Reding wrote:
> >> [...]
> >>> At least for Tegra it's trivial to just hook it up in tegra_pcie_scan_bus()
> >>> directly (patch attached).
> >>
> >> Really attached this time.
> >>
> >> Thierry
> >>
> >
> > It looks good to me, so I will update the arm pci hostbridge driver to assign
> > pci root bus the msi chip instead of current pcibios_add_bus(). But for other
> > platforms which only have a one msi chip, I will kept the arch_find_msi_chip()
> > temporarily for more comments, especially from Bjorn.
>
> Oh, sorry, I found designware and rcar use pci_scan_root_bus(), so we can not simply
> assign msi chip to root bus in all host drivers's scan functions.
Designware will switch away from pci_scan_root_bus() in the 3.18 cycle
and I would think it would be no problem to to the same with rcar.
Regards,
Lucas
--
Pengutronix e.K. | Lucas Stach |
Industrial Linux Solutions | http://www.pengutronix.de/ |
^ permalink raw reply
* Re: [PATCH 08/15] powerpc/mm: Add new hash_page_mm()
From: Aneesh Kumar K.V @ 2014-09-29 8:50 UTC (permalink / raw)
To: Michael Neuling, greg, arnd, mpe, benh
Cc: cbe-oss-dev, mikey, linux-kernel, linuxppc-dev, jk, imunsie,
anton
In-Reply-To: <1411028820-29933-9-git-send-email-mikey@neuling.org>
Michael Neuling <mikey@neuling.org> writes:
> From: Ian Munsie <imunsie@au1.ibm.com>
>
> This adds a new function hash_page_mm() based on the existing hash_page().
> This version allows any struct mm to be passed in, rather than assuming
> current. This is useful for servicing co-processor faults which are not in the
> context of the current running process.
>
> We need to be careful here as the current hash_page() assumes current in a few
> places.
Can you also explain calling semantics. ie, why would we want to call
this with anything other than current ? Should we flush slb now or
should it be skipped ? so what would happen if the new hash page can
result in segment demotion ? You don't put that under if (mm ==
current->mm). is that ok ?
if ((pte_val(*ptep) & _PAGE_4K_PFN) && psize == MMU_PAGE_64K) {
demote_segment_4k(mm, ea);
psize = MMU_PAGE_4K;
}
We also update paca context there
if (get_paca_psize(addr) != MMU_PAGE_4K) {
get_paca()->context = mm->context;
slb_flush_and_rebolt();
}
You also added code to handle KERNEL_REGION_ID in
[PATCH 02/15] powerpc/cell: Move data segment faulting code out of cell
platform. do we need to handle that here ?
>
> Signed-off-by: Ian Munsie <imunsie@au1.ibm.com>
> Signed-off-by: Michael Neuling <mikey@neuling.org>
> ---
> arch/powerpc/include/asm/mmu-hash64.h | 1 +
> arch/powerpc/mm/hash_utils_64.c | 20 +++++++++++++-------
> 2 files changed, 14 insertions(+), 7 deletions(-)
>
> diff --git a/arch/powerpc/include/asm/mmu-hash64.h b/arch/powerpc/include/asm/mmu-hash64.h
> index fd19a53..a3b85e9 100644
> --- a/arch/powerpc/include/asm/mmu-hash64.h
> +++ b/arch/powerpc/include/asm/mmu-hash64.h
> @@ -319,6 +319,7 @@ extern int __hash_page_64K(unsigned long ea, unsigned long access,
> unsigned int local, int ssize);
> struct mm_struct;
> unsigned int hash_page_do_lazy_icache(unsigned int pp, pte_t pte, int trap);
> +extern int hash_page_mm(struct mm_struct *mm, unsigned long ea, unsigned long access, unsigned long trap);
> extern int hash_page(unsigned long ea, unsigned long access, unsigned long trap);
> int __hash_page_huge(unsigned long ea, unsigned long access, unsigned long vsid,
> pte_t *ptep, unsigned long trap, int local, int ssize,
> diff --git a/arch/powerpc/mm/hash_utils_64.c b/arch/powerpc/mm/hash_utils_64.c
> index 0f73367..66071af 100644
> --- a/arch/powerpc/mm/hash_utils_64.c
> +++ b/arch/powerpc/mm/hash_utils_64.c
> @@ -991,26 +991,24 @@ static void check_paca_psize(unsigned long ea, struct mm_struct *mm,
> * -1 - critical hash insertion error
> * -2 - access not permitted by subpage protection mechanism
> */
> -int hash_page(unsigned long ea, unsigned long access, unsigned long trap)
> +int hash_page_mm(struct mm_struct *mm, unsigned long ea, unsigned long access, unsigned long trap)
> {
> enum ctx_state prev_state = exception_enter();
> pgd_t *pgdir;
> unsigned long vsid;
> - struct mm_struct *mm;
> pte_t *ptep;
> unsigned hugeshift;
> const struct cpumask *tmp;
> int rc, user_region = 0, local = 0;
> int psize, ssize;
>
> - DBG_LOW("hash_page(ea=%016lx, access=%lx, trap=%lx\n",
> - ea, access, trap);
> + DBG_LOW("%s(ea=%016lx, access=%lx, trap=%lx\n",
> + __func__, ea, access, trap);
>
> /* Get region & vsid */
> switch (REGION_ID(ea)) {
> case USER_REGION_ID:
> user_region = 1;
> - mm = current->mm;
> if (! mm) {
> DBG_LOW(" user region with no mm !\n");
> rc = 1;
> @@ -1106,7 +1104,8 @@ int hash_page(unsigned long ea, unsigned long access, unsigned long trap)
> WARN_ON(1);
> }
> #endif
> - check_paca_psize(ea, mm, psize, user_region);
> + if (current->mm == mm)
> + check_paca_psize(ea, mm, psize, user_region);
>
> goto bail;
> }
> @@ -1149,7 +1148,8 @@ int hash_page(unsigned long ea, unsigned long access, unsigned long trap)
> }
> }
>
> - check_paca_psize(ea, mm, psize, user_region);
> + if (current->mm == mm)
> + check_paca_psize(ea, mm, psize, user_region);
> #endif /* CONFIG_PPC_64K_PAGES */
>
> #ifdef CONFIG_PPC_HAS_HASH_64K
> @@ -1184,6 +1184,12 @@ bail:
> exception_exit(prev_state);
> return rc;
> }
> +EXPORT_SYMBOL_GPL(hash_page_mm);
> +
> +int hash_page(unsigned long ea, unsigned long access, unsigned long trap)
> +{
> + return hash_page_mm(current->mm, ea, access, trap);
> +}
> EXPORT_SYMBOL_GPL(hash_page);
>
> void hash_preload(struct mm_struct *mm, unsigned long ea,
> --
> 1.9.1
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
^ 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