Re: [PATCH v3 10/27] PCI/MSI: Remove useless bus->msi assignment
On 2014/10/23 13:41, Bjorn Helgaas wrote: > On Wed, Oct 15, 2014 at 11:06:58AM +0800, Yijing Wang wrote: >> Now msi chip is saved in pci_sys_data in arm, >> we could clean the bus->msi assignment in >> pci core. >> >> Signed-off-by: Yijing Wang >> CC: Thierry Reding >> CC: Thomas Petazzoni >> --- >> drivers/pci/probe.c |1 - >> 1 files changed, 0 insertions(+), 1 deletions(-) >> >> diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c >> index efa48dc..98bf4c3 100644 >> --- a/drivers/pci/probe.c >> +++ b/drivers/pci/probe.c >> @@ -682,7 +682,6 @@ static struct pci_bus *pci_alloc_child_bus(struct >> pci_bus *parent, >> >> child->parent = parent; >> child->ops = parent->ops; >> -child->msi = parent->msi; > > This needs an explanation of why ARM was the only arch to depend on this. OK, will add explanation in next version. > >> child->sysdata = parent->sysdata; >> child->bus_flags = parent->bus_flags; >> >> -- >> 1.7.1 >> >> -- >> To unsubscribe from this list: send the line "unsubscribe linux-pci" in >> the body of a message to majord...@vger.kernel.org >> More majordomo info at http://vger.kernel.org/majordomo-info.html > > . > -- Thanks! Yijing ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v3 09/27] arm/PCI: Clean unused pcibios_add_bus() and pcibios_remove_bus()
>> /*
>> * Swizzle the device pin each time we cross a bridge. If a platform does
>> * not provide a swizzle function, we perform the standard PCI swizzling.
>> @@ -478,8 +464,6 @@ static void pcibios_init_hw(struct device *parent,
>> struct hw_pci *hw,
>> sys->swizzle = hw->swizzle;
>> sys->map_irq = hw->map_irq;
>> sys->align_resource = hw->align_resource;
>> -sys->add_bus = hw->add_bus;
>> -sys->remove_bus = hw->remove_bus;
>> INIT_LIST_HEAD(&sys->resources);
>>
>> if (hw->private_data)
>
> What do the core changes below have to do with the ARM changes above?
> They should be a separate patch unless they can't be separated.
Hm, it's not the thing have to do, because the changes below is only used by
arm arch, so I put it here
together. It's ok to split the core changes out to another one.
>
>> diff --git a/drivers/pci/msi.c b/drivers/pci/msi.c
>> index f11108c..56e54ad 100644
>> --- a/drivers/pci/msi.c
>> +++ b/drivers/pci/msi.c
>> @@ -32,12 +32,10 @@ int pci_msi_ignore_mask;
>>
>> int __weak arch_setup_msi_irq(struct pci_dev *dev, struct msi_desc *desc)
>> {
>> -struct msi_chip *chip = dev->bus->msi;
>> +struct msi_chip *chip;
>> int err;
>>
>> -if (!chip)
>> -chip = pci_msi_chip(dev->bus);
>> -
>> +chip = pci_msi_chip(dev->bus);
>> if (!chip || !chip->setup_irq)
>> return -EINVAL;
>>
>> @@ -51,10 +49,7 @@ int __weak arch_setup_msi_irq(struct pci_dev *dev, struct
>> msi_desc *desc)
>> void __weak arch_teardown_msi_irq(unsigned int irq)
>> {
>> struct msi_desc *entry = irq_get_msi_desc(irq);
>> -struct msi_chip *chip = entry->dev->bus->msi;
>> -
>> -if (!chip)
>> -chip = pci_msi_chip(entry->dev->bus);
>> +struct msi_chip *chip = pci_msi_chip(entry->dev->bus);
>>
>> if (!chip || !chip->teardown_irq)
>> return;
>> --
>> 1.7.1
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-pci" in
>> the body of a message to majord...@vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
> .
>
--
Thanks!
Yijing
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v3 04/27] arm/MSI: Save MSI chip in pci_sys_data
>> diff --git a/drivers/pci/msi.c b/drivers/pci/msi.c
>> index 22e413c..f11108c 100644
>> --- a/drivers/pci/msi.c
>> +++ b/drivers/pci/msi.c
>> @@ -35,6 +35,9 @@ int __weak arch_setup_msi_irq(struct pci_dev *dev, struct
>> msi_desc *desc)
>> struct msi_chip *chip = dev->bus->msi;
>> int err;
>>
>> +if (!chip)
>> +chip = pci_msi_chip(dev->bus);
>> +
>> if (!chip || !chip->setup_irq)
>> return -EINVAL;
>>
>> @@ -50,6 +53,9 @@ void __weak arch_teardown_msi_irq(unsigned int irq)
>> struct msi_desc *entry = irq_get_msi_desc(irq);
>> struct msi_chip *chip = entry->dev->bus->msi;
>>
>> +if (!chip)
>> +chip = pci_msi_chip(entry->dev->bus);
>> +
>> if (!chip || !chip->teardown_irq)
>> return;
>>
>> diff --git a/include/linux/pci.h b/include/linux/pci.h
>> index 9cd2721..7a48b40 100644
>> --- a/include/linux/pci.h
>> +++ b/include/linux/pci.h
>> @@ -1433,6 +1433,15 @@ static inline int pci_get_new_domain_nr(void) {
>> return -ENOSYS; }
>>
>> #include
>>
>> +/* Just avoid compile error, will be clean up later */
>> +#ifdef CONFIG_PCI_MSI
>> +
>> +#ifndef pci_msi_chip
>> +#define pci_msi_chip(bus) NULL
>> +#endif
>> +#endif
>
> I don't like the mixture of ARM changes and PCI core changes in the same
> patch. Can you split this into a core patch that does something like this:
>
> struct msi_chip * __weak pcibios_msi_controller(struct pci_bus *bus)
> {
> return NULL;
> }
>
> struct msi_chip *pci_msi_controller(struct pci_bus *bus)
> {
> msi_chip *controller = bus->msi;
>
> if (controller)
> return controller;
> return pcibios_msi_controller(bus);
> }
>
> followed by an ARM patch that puts the msi_chip pointer in struct hw_pci
> and implements pcibios_msi_controller()?
OK, I will split it in half.
>
> I know you're trying to *remove* weak functions, and this adds one, but
> this section of the series is more about getting rid of the ARM
> pcibios_add_bus() because all it was used for was setting the bus->msi
> pointer.
Yes, agree.
>
> Eventually we might have a way to stash an MSI controller pointer in the
> generic pci_host_bridge struct, and then the pcibios_msi_controller()
> interface could go away.
Yep, I am doing the work to make a generic pci_host_bridge, and try to rip it
out from
pci_create_root_bus, that's also a large changes across many archs.
>
>> +
>> /* these helpers provide future and backwards compatibility
>> * for accessing popular PCI BAR info */
>> #define pci_resource_start(dev, bar)((dev)->resource[(bar)].start)
>> --
>> 1.7.1
>>
>
> .
>
--
Thanks!
Yijing
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v3 05/27] PCI: tegra: Save msi chip in pci_sys_data
On 2014/10/23 13:18, Bjorn Helgaas wrote:
> On Wed, Oct 15, 2014 at 11:06:53AM +0800, Yijing Wang wrote:
>> Save msi chip in pci_sys_data instead of assign
>> msi chip to every pci bus in .add_bus().
>>
>> Signed-off-by: Yijing Wang
>> ---
>> drivers/pci/host/pci-tegra.c | 13 +++--
>> 1 files changed, 3 insertions(+), 10 deletions(-)
>>
>> diff --git a/drivers/pci/host/pci-tegra.c b/drivers/pci/host/pci-tegra.c
>> index 3d43874..5af0525 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);
>> @@ -1881,11 +1872,13 @@ static int tegra_pcie_enable(struct tegra_pcie *pcie)
>>
>> memset(&hw, 0, sizeof(hw));
>>
>> +#ifdef CONFIG_PCI_MSI
>> +hw.msi_chip = &pcie->msi.chip;
>> +#endif
>
> Why did you use "#ifdef CONFIG_PCI_MSI" instead of the
> "IS_ENABLED(CONFIG_PCI_MSI)" used previously?
Just personal habit. :)
>
> It's true that CONFIG_PCI_MSI will never be a tristate symbol, so we don't
> really *need* the extra smarts of IS_ENABLED(), but I'm fairly sympathetic
> to James' argument [1] that we should just use IS_ENABLED() all the time
> because it's simpler overall.
>
> If you want to change the #ifdef to IS_ENABLED(), that should be a separate
> patch from your msi_chip change, and we can debate the merits of that by
> itself.
>
> [1] http://lkml.iu.edu//hypermail/linux/kernel/1204.3/00081.html
Hi Bjorn, thanks for your guidance. I will use IS_ENABLED() instead of #ifdef
for simplification
in a separate patch.
>
>> hw.nr_controllers = 1;
>> 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;
>>
>> --
>> 1.7.1
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
>> the body of a message to majord...@vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>> Please read the FAQ at http://www.tux.org/lkml/
>
> .
>
--
Thanks!
Yijing
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v3 00/27] Use MSI chip framework to configure MSI/MSI-X in all platforms
On Wed, Oct 15, 2014 at 11:06:48AM +0800, Yijing Wang wrote: > Now there are a lot of weak arch functions in MSI code. > Thierry Reding Introduced MSI chip framework to configure MSI/MSI-X in arm, > that's a better solution than overriding lots of existing weak arch > functionsin. > This series use MSI chip framework to refactor MSI code across all platforms > to eliminate weak arch functions. Then all MSI irqs will be managed in a > unified framework. Because this series changed a lot of ARCH MSI code, > so tests in the related platforms are warmly welcomed! > > And you may access it at: > https://github.com/YijingWang/msi-chip-v3.git master > > v2->v3: > 1. For patch "x86/xen/MSI: Eliminate...", introduce a new global flag > "pci_msi_ignore_mask" > to control the msi mask instead of replacing the irqchip->mask with nop > function, > the latter method has problem pointed out by Konrad Rzeszutek Wilk. > 2. Save msi chip in arch pci sysdata instead of associating msi chip to pci > bus. > Because pci devices under same host share the same msi chip, so I think > associate > msi chip to pci host/pci sysdata is better than to bother every pci > bus/devices. > A better solution suggested by Liviu is to rip out pci_host_bridge from > pci_create_root_bus(), > then we can save some pci host common attributes like domain_nr, msi_chip, > resources, > into the generic pci_host_bridge. Because this changes to pci host bridge is > also > a large series, so I think we should go step by step, I will try to post it > in another > series later. > 4. Clean up arm pcibios_add_bus() and pcibios_remove_bus() which were used to > associate > msi chip to pci bus. > > v1->v2: > Add a patch to make s390 MSI code build happy between patch "x86/xen/MSI: E.." > and "s390/MSI: Use MSI..". Fix several typo problems found by Lucas. > > RFC->v1: > Updated "[patch 4/21] x86/xen/MSI: Eliminate...", export msi_chip instead > of #ifdef to fix MSI bug in xen running in x86. > Rename arch_get_match_msi_chip() to arch_find_msi_chip(). > Drop use struct device as the msi_chip argument, we will do that > later in another patchset. > > Yijing Wang (27): This is a lot of stuff, and it's not all related, so putting it all together in one series makes it hard for me to deal with it. > MSI: Remove the redundant irq_set_chip_data() This doesn't seem related to eliminating weak functions. > x86/xen/MSI: Eliminate arch_msix_mask_irq() and arch_msi_mask_irq() > s390/MSI: Use __msi_mask_irq() instead of default_msi_mask_irq() These two seem to go together. > arm/MSI: Save MSI chip in pci_sys_data > PCI: tegra: Save msi chip in pci_sys_data > PCI: designware: Save msi chip in pci_sys_data > PCI: rcar: Save msi chip in pci_sys_data > PCI: mvebu: Save msi chip in pci_sys_data > arm/PCI: Clean unused pcibios_add_bus() and pcibios_remove_bus() > PCI/MSI: Remove useless bus->msi assignment These seem to go together (it'd be nice if they were all capitalized the same). I don't like the "msi_chip" name because the "chip" part doesn't convey much information, other than telling us that apparently some sort of semiconductor integrated circuit is involved. I sort of assumed that much :) Something like "msi_controller" would be more descriptive since we're talking about an interrupt controller that accepts writes from a device and turns them into CPU interrupts, e.g., a LAPIC. > PCI/MSI: Refactor struct msi_chip to make it become more common > x86/MSI: Use MSI chip framework to configure MSI/MSI-X irq > x86/xen/MSI: Use MSI chip framework to configure MSI/MSI-X irq > Irq_remapping/MSI: Use MSI chip framework to configure MSI/MSI-X irq > x86/MSI: Remove unused MSI weak arch functions > Mips/MSI: Save msi chip in pci sysdata > MIPS/Octeon/MSI: Use MSI chip framework to configure MSI/MSI-X irq > MIPS/Xlp: Remove the dead function destroy_irq() to fix build error > MIPS/Xlp/MSI: Use MSI chip framework to configure MSI/MSI-X irq > MIPS/Xlr/MSI: Use MSI chip framework to configure MSI/MSI-X irq > Powerpc/MSI: Use MSI chip framework to configure MSI/MSI-X irq > s390/MSI: Use MSI chip framework to configure MSI/MSI-X irq > arm/iop13xx/MSI: Use MSI chip framework to configure MSI/MSI-X irq > IA64/MSI: Use MSI chip framework to configure MSI/MSI-X irq > Sparc/MSI: Use MSI chip framework to configure MSI/MSI-X irq > tile/MSI: Use MSI chip framework to configure MSI/MSI-X irq > PCI/MSI: Clean up unused MSI arch functions > > arch/arm/include/asm/mach/pci.h | 10 +- > arch/arm/include/asm/pci.h |9 ++ > arch/arm/kernel/bios32.c| 19 +--- > arch/arm/mach-iop13xx/include/mach/pci.h|4 + > arch/arm/mach-iop13xx/iq81340mc.c |3 + > arch/arm/mach-iop13xx/iq81340sc.c |5 +- > arch/arm/mach-iop13xx/msi.c | 11 ++- > arch/ia64/include/asm/pci.h
Re: [PATCH v3 10/27] PCI/MSI: Remove useless bus->msi assignment
On Wed, Oct 15, 2014 at 11:06:58AM +0800, Yijing Wang wrote: > Now msi chip is saved in pci_sys_data in arm, > we could clean the bus->msi assignment in > pci core. > > Signed-off-by: Yijing Wang > CC: Thierry Reding > CC: Thomas Petazzoni > --- > drivers/pci/probe.c |1 - > 1 files changed, 0 insertions(+), 1 deletions(-) > > diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c > index efa48dc..98bf4c3 100644 > --- a/drivers/pci/probe.c > +++ b/drivers/pci/probe.c > @@ -682,7 +682,6 @@ static struct pci_bus *pci_alloc_child_bus(struct pci_bus > *parent, > > child->parent = parent; > child->ops = parent->ops; > - child->msi = parent->msi; This needs an explanation of why ARM was the only arch to depend on this. > child->sysdata = parent->sysdata; > child->bus_flags = parent->bus_flags; > > -- > 1.7.1 > > -- > To unsubscribe from this list: send the line "unsubscribe linux-pci" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v3 09/27] arm/PCI: Clean unused pcibios_add_bus() and pcibios_remove_bus()
On Wed, Oct 15, 2014 at 11:06:57AM +0800, Yijing Wang wrote:
> MSI chip will be saved in pci_sys_data, now we can
> clean up pcibios_add_bus() and pcibios_remove_bus()
> in arm, and use pci_find_msi_chip() to get msi chip
> in core MSI code.
>
> Signed-off-by: Yijing Wang
> ---
> arch/arm/include/asm/mach/pci.h |4
> arch/arm/kernel/bios32.c| 16
> drivers/pci/msi.c | 11 +++
> 3 files changed, 3 insertions(+), 28 deletions(-)
>
> diff --git a/arch/arm/include/asm/mach/pci.h b/arch/arm/include/asm/mach/pci.h
> index 59b0d87..230b2c9 100644
> --- a/arch/arm/include/asm/mach/pci.h
> +++ b/arch/arm/include/asm/mach/pci.h
> @@ -39,8 +39,6 @@ struct hw_pci {
> resource_size_t start,
> resource_size_t size,
> resource_size_t align);
> - void(*add_bus)(struct pci_bus *bus);
> - void(*remove_bus)(struct pci_bus *bus);
> };
>
> /*
> @@ -71,8 +69,6 @@ struct pci_sys_data {
> resource_size_t start,
> resource_size_t size,
> resource_size_t align);
> - void(*add_bus)(struct pci_bus *bus);
> - void(*remove_bus)(struct pci_bus *bus);
> void*private_data; /* platform controller private data
> */
> };
>
> diff --git a/arch/arm/kernel/bios32.c b/arch/arm/kernel/bios32.c
> index a19038d..b1b872e 100644
> --- a/arch/arm/kernel/bios32.c
> +++ b/arch/arm/kernel/bios32.c
> @@ -360,20 +360,6 @@ void pcibios_fixup_bus(struct pci_bus *bus)
> }
> EXPORT_SYMBOL(pcibios_fixup_bus);
>
> -void pcibios_add_bus(struct pci_bus *bus)
> -{
> - struct pci_sys_data *sys = bus->sysdata;
> - if (sys->add_bus)
> - sys->add_bus(bus);
> -}
> -
> -void pcibios_remove_bus(struct pci_bus *bus)
> -{
> - struct pci_sys_data *sys = bus->sysdata;
> - if (sys->remove_bus)
> - sys->remove_bus(bus);
> -}
> -
> /*
> * Swizzle the device pin each time we cross a bridge. If a platform does
> * not provide a swizzle function, we perform the standard PCI swizzling.
> @@ -478,8 +464,6 @@ static void pcibios_init_hw(struct device *parent, struct
> hw_pci *hw,
> sys->swizzle = hw->swizzle;
> sys->map_irq = hw->map_irq;
> sys->align_resource = hw->align_resource;
> - sys->add_bus = hw->add_bus;
> - sys->remove_bus = hw->remove_bus;
> INIT_LIST_HEAD(&sys->resources);
>
> if (hw->private_data)
What do the core changes below have to do with the ARM changes above?
They should be a separate patch unless they can't be separated.
> diff --git a/drivers/pci/msi.c b/drivers/pci/msi.c
> index f11108c..56e54ad 100644
> --- a/drivers/pci/msi.c
> +++ b/drivers/pci/msi.c
> @@ -32,12 +32,10 @@ int pci_msi_ignore_mask;
>
> int __weak arch_setup_msi_irq(struct pci_dev *dev, struct msi_desc *desc)
> {
> - struct msi_chip *chip = dev->bus->msi;
> + struct msi_chip *chip;
> int err;
>
> - if (!chip)
> - chip = pci_msi_chip(dev->bus);
> -
> + chip = pci_msi_chip(dev->bus);
> if (!chip || !chip->setup_irq)
> return -EINVAL;
>
> @@ -51,10 +49,7 @@ int __weak arch_setup_msi_irq(struct pci_dev *dev, struct
> msi_desc *desc)
> void __weak arch_teardown_msi_irq(unsigned int irq)
> {
> struct msi_desc *entry = irq_get_msi_desc(irq);
> - struct msi_chip *chip = entry->dev->bus->msi;
> -
> - if (!chip)
> - chip = pci_msi_chip(entry->dev->bus);
> + struct msi_chip *chip = pci_msi_chip(entry->dev->bus);
>
> if (!chip || !chip->teardown_irq)
> return;
> --
> 1.7.1
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-pci" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v3 04/27] arm/MSI: Save MSI chip in pci_sys_data
On Wed, Oct 15, 2014 at 11:06:52AM +0800, Yijing Wang wrote:
> Saving msi chip in pci_sys_data can make pci bus and
> devices don't need to know msi chip detail, it also
> make pci enumeration code be decoupled from msi chip.
> In fact, all pci devices under the same pci hostbridge
> share same msi chip. So msi chip should be seen as one
> of resources or attributes to be initialized in pci host
> bridge driver. Currently, pci hostbridge drivers create
> pci_host_bridge in pci_create_root_bus(), and pass arch
> specific pci sysdata to core pci scan functions. So pci
> arch sysdata is good place to save msi chip.
>
> Signed-off-by: Yijing Wang
> ---
> arch/arm/include/asm/mach/pci.h |6 ++
> arch/arm/include/asm/pci.h |9 +
> arch/arm/kernel/bios32.c|3 +++
> drivers/pci/msi.c |6 ++
> include/linux/pci.h |9 +
> 5 files changed, 33 insertions(+), 0 deletions(-)
>
> diff --git a/arch/arm/include/asm/mach/pci.h b/arch/arm/include/asm/mach/pci.h
> index 7fc4278..59b0d87 100644
> --- a/arch/arm/include/asm/mach/pci.h
> +++ b/arch/arm/include/asm/mach/pci.h
> @@ -22,6 +22,9 @@ struct hw_pci {
> #ifdef CONFIG_PCI_DOMAINS
> int domain;
> #endif
> +#ifdef CONFIG_PCI_MSI
> + struct msi_chip *msi_chip;
> +#endif
> struct pci_ops *ops;
> int nr_controllers;
> void**private_data;
> @@ -47,6 +50,9 @@ struct pci_sys_data {
> #ifdef CONFIG_PCI_DOMAINS
> int domain;
> #endif
> +#ifdef CONFIG_PCI_MSI
> + struct msi_chip *msi_chip;
> +#endif
> struct list_head node;
> int busnr; /* primary bus number
> */
> u64 mem_offset; /* bus->cpu memory mapping offset
> */
> diff --git a/arch/arm/include/asm/pci.h b/arch/arm/include/asm/pci.h
> index 7e95d85..b562c09 100644
> --- a/arch/arm/include/asm/pci.h
> +++ b/arch/arm/include/asm/pci.h
> @@ -31,6 +31,15 @@ static inline int pci_proc_domain(struct pci_bus *bus)
> }
> #endif /* CONFIG_PCI_DOMAINS */
>
> +#ifdef CONFIG_PCI_MSI
> +static inline struct msi_chip *pci_msi_chip(struct pci_bus *bus)
> +{
> + struct pci_sys_data *root = bus->sysdata;
> +
> + return root->msi_chip;
> +}
> +#endif
> +
> /*
> * The PCI address space does equal the physical memory address space.
> * The networking and block device layers use this boolean for bounce
> diff --git a/arch/arm/kernel/bios32.c b/arch/arm/kernel/bios32.c
> index 17a26c1..a19038d 100644
> --- a/arch/arm/kernel/bios32.c
> +++ b/arch/arm/kernel/bios32.c
> @@ -471,6 +471,9 @@ static void pcibios_init_hw(struct device *parent, struct
> hw_pci *hw,
> #ifdef CONFIG_PCI_DOMAINS
> sys->domain = hw->domain;
> #endif
> +#ifdef CONFIG_PCI_MSI
> + sys->msi_chip = hw->msi_chip;
> +#endif
> sys->busnr = busnr;
> sys->swizzle = hw->swizzle;
> sys->map_irq = hw->map_irq;
> diff --git a/drivers/pci/msi.c b/drivers/pci/msi.c
> index 22e413c..f11108c 100644
> --- a/drivers/pci/msi.c
> +++ b/drivers/pci/msi.c
> @@ -35,6 +35,9 @@ int __weak arch_setup_msi_irq(struct pci_dev *dev, struct
> msi_desc *desc)
> struct msi_chip *chip = dev->bus->msi;
> int err;
>
> + if (!chip)
> + chip = pci_msi_chip(dev->bus);
> +
> if (!chip || !chip->setup_irq)
> return -EINVAL;
>
> @@ -50,6 +53,9 @@ void __weak arch_teardown_msi_irq(unsigned int irq)
> struct msi_desc *entry = irq_get_msi_desc(irq);
> struct msi_chip *chip = entry->dev->bus->msi;
>
> + if (!chip)
> + chip = pci_msi_chip(entry->dev->bus);
> +
> if (!chip || !chip->teardown_irq)
> return;
>
> diff --git a/include/linux/pci.h b/include/linux/pci.h
> index 9cd2721..7a48b40 100644
> --- a/include/linux/pci.h
> +++ b/include/linux/pci.h
> @@ -1433,6 +1433,15 @@ static inline int pci_get_new_domain_nr(void) { return
> -ENOSYS; }
>
> #include
>
> +/* Just avoid compile error, will be clean up later */
> +#ifdef CONFIG_PCI_MSI
> +
> +#ifndef pci_msi_chip
> +#define pci_msi_chip(bus)NULL
> +#endif
> +#endif
I don't like the mixture of ARM changes and PCI core changes in the same
patch. Can you split this into a core patch that does something like this:
struct msi_chip * __weak pcibios_msi_controller(struct pci_bus *bus)
{
return NULL;
}
struct msi_chip *pci_msi_controller(struct pci_bus *bus)
{
msi_chip *controller = bus->msi;
if (controller)
return controller;
return pcibios_msi_controller(bus);
}
followed by an ARM patch that puts the msi_chip pointer in struct hw_pci
and implements pcibios_msi_controller()?
I know you're trying to *remove* weak functions, and this adds one, but
this section of the series is more about getting rid of the ARM
pcibios_add_bus() because all it was used for was setting the bus->msi
poin
Re: [PATCH v3 05/27] PCI: tegra: Save msi chip in pci_sys_data
On Wed, Oct 15, 2014 at 11:06:53AM +0800, Yijing Wang wrote:
> Save msi chip in pci_sys_data instead of assign
> msi chip to every pci bus in .add_bus().
>
> Signed-off-by: Yijing Wang
> ---
> drivers/pci/host/pci-tegra.c | 13 +++--
> 1 files changed, 3 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/pci/host/pci-tegra.c b/drivers/pci/host/pci-tegra.c
> index 3d43874..5af0525 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);
> @@ -1881,11 +1872,13 @@ static int tegra_pcie_enable(struct tegra_pcie *pcie)
>
> memset(&hw, 0, sizeof(hw));
>
> +#ifdef CONFIG_PCI_MSI
> + hw.msi_chip = &pcie->msi.chip;
> +#endif
Why did you use "#ifdef CONFIG_PCI_MSI" instead of the
"IS_ENABLED(CONFIG_PCI_MSI)" used previously?
It's true that CONFIG_PCI_MSI will never be a tristate symbol, so we don't
really *need* the extra smarts of IS_ENABLED(), but I'm fairly sympathetic
to James' argument [1] that we should just use IS_ENABLED() all the time
because it's simpler overall.
If you want to change the #ifdef to IS_ENABLED(), that should be a separate
patch from your msi_chip change, and we can debate the merits of that by
itself.
[1] http://lkml.iu.edu//hypermail/linux/kernel/1204.3/00081.html
> hw.nr_controllers = 1;
> 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;
>
> --
> 1.7.1
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v3 02/27] x86/xen/MSI: Eliminate arch_msix_mask_irq() and arch_msi_mask_irq()
On 2014/10/23 12:25, Bjorn Helgaas wrote:
> On Wed, Oct 15, 2014 at 11:06:50AM +0800, Yijing Wang wrote:
>> Commit 0e4ccb1505a9 ("PCI: Add x86_msi.msi_mask_irq() and msix_mask_irq()")
>> introduced two __weak arch functions arch_msix_mask_irq() and
>> arch_msi_mask_irq() to work around a bug when running xen in x86.
>> These two functions made msi code more complex. This patch reverts
>> the commit and introduces a global flag to control msi mask action to
>> avoid the bug. The patch is also preparation for using MSI chip framework
>> instead of weak arch MSI functions in all platforms. Keep
>> default_msi_mask_irq()
>> and default_msix_mask_irq() in linux/msi.h to make s390 MSI code compile
>> happy, they will be removed in the later patch.
>
> This patch is basically a revert of 0e4ccb1505a9 intermingled with the
> addition of the new pci_msi_ignore_mask technique.
>
> Can you please split this into two patches:
>
> - Add the pci_msi_ignore_mask stuff (alongside the existing way)
> - Revert 0e4ccb1505a9
>
> I think that will make it easier to see what's going on.
OK, I will do it, thanks.
Thanks!
Yijing.
>
>> Signed-off-by: Yijing Wang
>> CC: David Vrabel
>> CC: Konrad Rzeszutek Wilk
>> ---
>> Hi David and Konrad,
>>I dropped the Acked-by and tested-by, because this version has a
>> lot changes compared to last. So, I guess you may want to check it again.
>> ---
>> arch/x86/include/asm/x86_init.h |3 ---
>> arch/x86/kernel/x86_init.c | 10 --
>> arch/x86/pci/xen.c | 14 ++
>> drivers/pci/msi.c | 29 -
>> include/linux/msi.h |8 ++--
>> 5 files changed, 20 insertions(+), 44 deletions(-)
>>
>> diff --git a/arch/x86/include/asm/x86_init.h
>> b/arch/x86/include/asm/x86_init.h
>> index e45e4da..f58a9c7 100644
>> --- a/arch/x86/include/asm/x86_init.h
>> +++ b/arch/x86/include/asm/x86_init.h
>> @@ -172,7 +172,6 @@ struct x86_platform_ops {
>>
>> struct pci_dev;
>> struct msi_msg;
>> -struct msi_desc;
>>
>> struct x86_msi_ops {
>> int (*setup_msi_irqs)(struct pci_dev *dev, int nvec, int type);
>> @@ -183,8 +182,6 @@ struct x86_msi_ops {
>> void (*teardown_msi_irqs)(struct pci_dev *dev);
>> void (*restore_msi_irqs)(struct pci_dev *dev);
>> int (*setup_hpet_msi)(unsigned int irq, unsigned int id);
>> -u32 (*msi_mask_irq)(struct msi_desc *desc, u32 mask, u32 flag);
>> -u32 (*msix_mask_irq)(struct msi_desc *desc, u32 flag);
>> };
>>
>> struct IO_APIC_route_entry;
>> diff --git a/arch/x86/kernel/x86_init.c b/arch/x86/kernel/x86_init.c
>> index e48b674..234b072 100644
>> --- a/arch/x86/kernel/x86_init.c
>> +++ b/arch/x86/kernel/x86_init.c
>> @@ -116,8 +116,6 @@ struct x86_msi_ops x86_msi = {
>> .teardown_msi_irqs = default_teardown_msi_irqs,
>> .restore_msi_irqs = default_restore_msi_irqs,
>> .setup_hpet_msi = default_setup_hpet_msi,
>> -.msi_mask_irq = default_msi_mask_irq,
>> -.msix_mask_irq = default_msix_mask_irq,
>> };
>>
>> /* MSI arch specific hooks */
>> @@ -140,14 +138,6 @@ void arch_restore_msi_irqs(struct pci_dev *dev)
>> {
>> x86_msi.restore_msi_irqs(dev);
>> }
>> -u32 arch_msi_mask_irq(struct msi_desc *desc, u32 mask, u32 flag)
>> -{
>> -return x86_msi.msi_mask_irq(desc, mask, flag);
>> -}
>> -u32 arch_msix_mask_irq(struct msi_desc *desc, u32 flag)
>> -{
>> -return x86_msi.msix_mask_irq(desc, flag);
>> -}
>> #endif
>>
>> struct x86_io_apic_ops x86_io_apic_ops = {
>> diff --git a/arch/x86/pci/xen.c b/arch/x86/pci/xen.c
>> index 093f5f4..e5b8b78 100644
>> --- a/arch/x86/pci/xen.c
>> +++ b/arch/x86/pci/xen.c
>> @@ -394,14 +394,6 @@ static void xen_teardown_msi_irq(unsigned int irq)
>> {
>> xen_destroy_irq(irq);
>> }
>> -static u32 xen_nop_msi_mask_irq(struct msi_desc *desc, u32 mask, u32 flag)
>> -{
>> -return 0;
>> -}
>> -static u32 xen_nop_msix_mask_irq(struct msi_desc *desc, u32 flag)
>> -{
>> -return 0;
>> -}
>> #endif
>>
>> int __init pci_xen_init(void)
>> @@ -425,8 +417,7 @@ int __init pci_xen_init(void)
>> x86_msi.setup_msi_irqs = xen_setup_msi_irqs;
>> x86_msi.teardown_msi_irq = xen_teardown_msi_irq;
>> x86_msi.teardown_msi_irqs = xen_teardown_msi_irqs;
>> -x86_msi.msi_mask_irq = xen_nop_msi_mask_irq;
>> -x86_msi.msix_mask_irq = xen_nop_msix_mask_irq;
>> +pci_msi_ignore_mask = 1;
>> #endif
>> return 0;
>> }
>> @@ -506,8 +497,7 @@ int __init pci_xen_initial_domain(void)
>> x86_msi.setup_msi_irqs = xen_initdom_setup_msi_irqs;
>> x86_msi.teardown_msi_irq = xen_teardown_msi_irq;
>> x86_msi.restore_msi_irqs = xen_initdom_restore_msi_irqs;
>> -x86_msi.msi_mask_irq = xen_nop_msi_mask_irq;
>> -x86_msi.msix_mask_irq = xen_nop_msix_mask_irq;
>> +pci_msi_ignore_mask = 1;
>> #endif
>> xen_setup_acpi_sci();
>> __acpi_register_gsi = acpi_register_gsi_xen;
>> diff --git a/dr
Re: [PATCH V2 1/2] mm: Update generic gup implementation to handle hugepage directory
Andrew Morton writes:
> On Fri, 17 Oct 2014 10:08:06 +0530 "Aneesh Kumar K.V"
> wrote:
>
>> Update generic gup implementation with powerpc specific details.
>> On powerpc at pmd level we can have hugepte, normal pmd pointer
>> or a pointer to the hugepage directory.
>>
>> ...
>>
>> --- a/arch/arm/include/asm/pgtable.h
>> +++ b/arch/arm/include/asm/pgtable.h
>> @@ -181,6 +181,8 @@ extern pgd_t swapper_pg_dir[PTRS_PER_PGD];
>> /* to find an entry in a kernel page-table-directory */
>> #define pgd_offset_k(addr) pgd_offset(&init_mm, addr)
>>
>> +#define pgd_huge(pgd) (0)
>> +
>> #define pmd_none(pmd) (!pmd_val(pmd))
>> #define pmd_present(pmd)(pmd_val(pmd))
>>
>> diff --git a/arch/arm64/include/asm/pgtable.h
>> b/arch/arm64/include/asm/pgtable.h
>> index cefd3e825612..ed8f42497ac4 100644
>> --- a/arch/arm64/include/asm/pgtable.h
>> +++ b/arch/arm64/include/asm/pgtable.h
>> @@ -464,6 +464,8 @@ static inline pmd_t pmd_modify(pmd_t pmd, pgprot_t
>> newprot)
>> extern pgd_t swapper_pg_dir[PTRS_PER_PGD];
>> extern pgd_t idmap_pg_dir[PTRS_PER_PGD];
>>
>> +#define pgd_huge(pgd) (0)
>> +
>
> So only arm, arm64 and powerpc implement CONFIG_HAVE_GENERIC_RCU_GUP
> and only powerpc impements pgd_huge().
>
> Could we get a bit of documentation in place for pgd_huge() so that
> people who aren't familiar with powerpc can understand what's going
> on?
Will update
>
>> /*
>> * Encode and decode a swap entry:
>> * bits 0-1: present (must be zero)
>> diff --git a/include/linux/mm.h b/include/linux/mm.h
>> index 02d11ee7f19d..f97732412cb4 100644
>> --- a/include/linux/mm.h
>> +++ b/include/linux/mm.h
>> @@ -1219,6 +1219,32 @@ long get_user_pages(struct task_struct *tsk, struct
>> mm_struct *mm,
>> struct vm_area_struct **vmas);
>> int get_user_pages_fast(unsigned long start, int nr_pages, int write,
>> struct page **pages);
>> +
>> +#ifdef CONFIG_HAVE_GENERIC_RCU_GUP
>> +#ifndef is_hugepd
>
> And is_hugepd is a bit of a mystery. Let's get some description in
> place for this as well? Why it exists, what its role is. Also,
> specifically which arch header file is responsible for defining it.
>
> It takes a hugepd_t argument, but hugepd_t is defined later in this
> header file. This is weird because any preceding implementation of
> is_hugepd() can't actually be implemented because it hasn't seen the
> hugepd_t definition yet! So any is_hugepd() implementation is forced
> to be a simple macro which punts to a C function which *has* seen the
> hugepd_t definition. What a twisty maze.
arch can definitely do
#defne is_hugepd is_hugepd
typedef struct { unsigned long pd; } hugepd_t;
static inline int is_hugepd(hugepd_t hpd)
{
}
I wanted to make sure arch can have their own definition of hugepd_t .
>
> It all seems messy, confusing and poorly documented. Can we clean this
> up?
>
>> +/*
>> + * Some architectures support hugepage directory format that is
>> + * required to support different hugetlbfs sizes.
>> + */
>> +typedef struct { unsigned long pd; } hugepd_t;
>> +#define is_hugepd(hugepd) (0)
>> +#define __hugepd(x) ((hugepd_t) { (x) })
>
> What's this.
macro that is used to convert value to type hugepd_t. We use that style
already for __pte() etc.
>
>> +static inline int gup_hugepd(hugepd_t hugepd, unsigned long addr,
>> + unsigned pdshift, unsigned long end,
>> + int write, struct page **pages, int *nr)
>> +{
>> +return 0;
>> +}
>> +#else
>> +extern int gup_hugepd(hugepd_t hugepd, unsigned long addr,
>> + unsigned pdshift, unsigned long end,
>> + int write, struct page **pages, int *nr);
>> +#endif
>> +extern int gup_huge_pte(pte_t orig, pte_t *ptep, unsigned long addr,
>> +unsigned long sz, unsigned long end, int write,
>> +struct page **pages, int *nr);
>> +#endif
-aneesh
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v3 02/27] x86/xen/MSI: Eliminate arch_msix_mask_irq() and arch_msi_mask_irq()
On Wed, Oct 15, 2014 at 11:06:50AM +0800, Yijing Wang wrote:
> Commit 0e4ccb1505a9 ("PCI: Add x86_msi.msi_mask_irq() and msix_mask_irq()")
> introduced two __weak arch functions arch_msix_mask_irq() and
> arch_msi_mask_irq() to work around a bug when running xen in x86.
> These two functions made msi code more complex. This patch reverts
> the commit and introduces a global flag to control msi mask action to
> avoid the bug. The patch is also preparation for using MSI chip framework
> instead of weak arch MSI functions in all platforms. Keep
> default_msi_mask_irq()
> and default_msix_mask_irq() in linux/msi.h to make s390 MSI code compile
> happy, they will be removed in the later patch.
This patch is basically a revert of 0e4ccb1505a9 intermingled with the
addition of the new pci_msi_ignore_mask technique.
Can you please split this into two patches:
- Add the pci_msi_ignore_mask stuff (alongside the existing way)
- Revert 0e4ccb1505a9
I think that will make it easier to see what's going on.
> Signed-off-by: Yijing Wang
> CC: David Vrabel
> CC: Konrad Rzeszutek Wilk
> ---
> Hi David and Konrad,
>I dropped the Acked-by and tested-by, because this version has a
> lot changes compared to last. So, I guess you may want to check it again.
> ---
> arch/x86/include/asm/x86_init.h |3 ---
> arch/x86/kernel/x86_init.c | 10 --
> arch/x86/pci/xen.c | 14 ++
> drivers/pci/msi.c | 29 -
> include/linux/msi.h |8 ++--
> 5 files changed, 20 insertions(+), 44 deletions(-)
>
> diff --git a/arch/x86/include/asm/x86_init.h b/arch/x86/include/asm/x86_init.h
> index e45e4da..f58a9c7 100644
> --- a/arch/x86/include/asm/x86_init.h
> +++ b/arch/x86/include/asm/x86_init.h
> @@ -172,7 +172,6 @@ struct x86_platform_ops {
>
> struct pci_dev;
> struct msi_msg;
> -struct msi_desc;
>
> struct x86_msi_ops {
> int (*setup_msi_irqs)(struct pci_dev *dev, int nvec, int type);
> @@ -183,8 +182,6 @@ struct x86_msi_ops {
> void (*teardown_msi_irqs)(struct pci_dev *dev);
> void (*restore_msi_irqs)(struct pci_dev *dev);
> int (*setup_hpet_msi)(unsigned int irq, unsigned int id);
> - u32 (*msi_mask_irq)(struct msi_desc *desc, u32 mask, u32 flag);
> - u32 (*msix_mask_irq)(struct msi_desc *desc, u32 flag);
> };
>
> struct IO_APIC_route_entry;
> diff --git a/arch/x86/kernel/x86_init.c b/arch/x86/kernel/x86_init.c
> index e48b674..234b072 100644
> --- a/arch/x86/kernel/x86_init.c
> +++ b/arch/x86/kernel/x86_init.c
> @@ -116,8 +116,6 @@ struct x86_msi_ops x86_msi = {
> .teardown_msi_irqs = default_teardown_msi_irqs,
> .restore_msi_irqs = default_restore_msi_irqs,
> .setup_hpet_msi = default_setup_hpet_msi,
> - .msi_mask_irq = default_msi_mask_irq,
> - .msix_mask_irq = default_msix_mask_irq,
> };
>
> /* MSI arch specific hooks */
> @@ -140,14 +138,6 @@ void arch_restore_msi_irqs(struct pci_dev *dev)
> {
> x86_msi.restore_msi_irqs(dev);
> }
> -u32 arch_msi_mask_irq(struct msi_desc *desc, u32 mask, u32 flag)
> -{
> - return x86_msi.msi_mask_irq(desc, mask, flag);
> -}
> -u32 arch_msix_mask_irq(struct msi_desc *desc, u32 flag)
> -{
> - return x86_msi.msix_mask_irq(desc, flag);
> -}
> #endif
>
> struct x86_io_apic_ops x86_io_apic_ops = {
> diff --git a/arch/x86/pci/xen.c b/arch/x86/pci/xen.c
> index 093f5f4..e5b8b78 100644
> --- a/arch/x86/pci/xen.c
> +++ b/arch/x86/pci/xen.c
> @@ -394,14 +394,6 @@ static void xen_teardown_msi_irq(unsigned int irq)
> {
> xen_destroy_irq(irq);
> }
> -static u32 xen_nop_msi_mask_irq(struct msi_desc *desc, u32 mask, u32 flag)
> -{
> - return 0;
> -}
> -static u32 xen_nop_msix_mask_irq(struct msi_desc *desc, u32 flag)
> -{
> - return 0;
> -}
> #endif
>
> int __init pci_xen_init(void)
> @@ -425,8 +417,7 @@ int __init pci_xen_init(void)
> x86_msi.setup_msi_irqs = xen_setup_msi_irqs;
> x86_msi.teardown_msi_irq = xen_teardown_msi_irq;
> x86_msi.teardown_msi_irqs = xen_teardown_msi_irqs;
> - x86_msi.msi_mask_irq = xen_nop_msi_mask_irq;
> - x86_msi.msix_mask_irq = xen_nop_msix_mask_irq;
> + pci_msi_ignore_mask = 1;
> #endif
> return 0;
> }
> @@ -506,8 +497,7 @@ int __init pci_xen_initial_domain(void)
> x86_msi.setup_msi_irqs = xen_initdom_setup_msi_irqs;
> x86_msi.teardown_msi_irq = xen_teardown_msi_irq;
> x86_msi.restore_msi_irqs = xen_initdom_restore_msi_irqs;
> - x86_msi.msi_mask_irq = xen_nop_msi_mask_irq;
> - x86_msi.msix_mask_irq = xen_nop_msix_mask_irq;
> + pci_msi_ignore_mask = 1;
> #endif
> xen_setup_acpi_sci();
> __acpi_register_gsi = acpi_register_gsi_xen;
> diff --git a/drivers/pci/msi.c b/drivers/pci/msi.c
> index ecb92a5..22e413c 100644
> --- a/drivers/pci/msi.c
> +++ b/drivers/pci/msi.c
> @@ -23,6 +23,7 @@
> #include "pci.h"
>
> static int pci_msi_enable = 1
Re: [PATCH v3 24/27] IA64/MSI: Use MSI chip framework to configure MSI/MSI-X irq
On 2014/10/23 7:53, Bjorn Helgaas wrote:
> On Wed, Oct 15, 2014 at 11:07:12AM +0800, Yijing Wang wrote:
>> Use MSI chip framework instead of arch MSI functions to configure
>> MSI/MSI-X irq. So we can manage MSI/MSI-X irq in a unified framework.
>
> This needs slightly more detail. You're using the MSI chip framework
> "instead of arch MSI functions". Well, there are still arch-specific
> functions, i.e., arch_ia64_setup_msi_irq() and
> arch_ia64_teardown_msi_irq().
>
> We used to have arch_setup_msi_irq() which had a weak default
> implementation, and a strong arch-specific implementation here, and you're
> replacing that model with the new "msi-ops" model. I don't know how you
> want to write that, but it's not that you're getting rid of the
> arch-specific code; you're keeping arch-specific code but structuring it
> differently.
Hm, I will rename the msi-ops functions.
>
>> Signed-off-by: Yijing Wang
>> ---
>> arch/ia64/include/asm/pci.h | 10 ++
>> arch/ia64/kernel/msi_ia64.c | 14 ++
>> arch/ia64/pci/pci.c |1 +
>> 3 files changed, 21 insertions(+), 4 deletions(-)
>>
>> diff --git a/arch/ia64/include/asm/pci.h b/arch/ia64/include/asm/pci.h
>> index 52af5ed..907dcba 100644
>> --- a/arch/ia64/include/asm/pci.h
>> +++ b/arch/ia64/include/asm/pci.h
>> @@ -94,6 +94,7 @@ struct pci_controller {
>> int segment;
>> int node; /* nearest node with memory or NUMA_NO_NODE for
>> global allocation */
>>
>> +struct msi_chip *msi_chip;
>> void *platform_data;
>> };
>>
>> @@ -101,6 +102,15 @@ struct pci_controller {
>> #define PCI_CONTROLLER(busdev) ((struct pci_controller *) busdev->sysdata)
>> #define pci_domain_nr(busdev)(PCI_CONTROLLER(busdev)->segment)
>>
>> +extern struct msi_chip chip;
>
> Please make this name more descriptive. "chip" is way too generic for a
> global name.
OK, what about rename it to ia64_msi_chip, and rename the original static
irq_chip ia64_msi_chip to
static irq_chip msi_chip like in x86.
>
>> +static inline struct msi_chip *pci_msi_chip(struct pci_bus *bus)
>> +{
>> +struct pci_controller *ctrl = bus->sysdata;
>> +
>> +return ctrl->msi_chip;
>> +}
>> +
>> extern struct pci_ops pci_root_ops;
>>
>> static inline int pci_proc_domain(struct pci_bus *bus)
>> diff --git a/arch/ia64/kernel/msi_ia64.c b/arch/ia64/kernel/msi_ia64.c
>> index 8c3730c..401fc98 100644
>> --- a/arch/ia64/kernel/msi_ia64.c
>> +++ b/arch/ia64/kernel/msi_ia64.c
>> @@ -112,15 +112,16 @@ static struct irq_chip ia64_msi_chip = {
>> };
>>
>>
>> -int arch_setup_msi_irq(struct pci_dev *pdev, struct msi_desc *desc)
>> +static int arch_ia64_setup_msi_irq(struct msi_chip *chip,
>> +struct pci_dev *dev, struct msi_desc *desc)
>> {
>> if (platform_setup_msi_irq)
>> -return platform_setup_msi_irq(pdev, desc);
>> +return platform_setup_msi_irq(dev, desc);
>>
>> -return ia64_setup_msi_irq(pdev, desc);
>> +return ia64_setup_msi_irq(dev, desc);
>
> Please don't make gratuitous changes ("pdev" -> "dev") at the same time,
> especially since the rest of the file still uses "pdev".
OK.
>
>> }
>>
>> -void arch_teardown_msi_irq(unsigned int irq)
>> +static void arch_ia64_teardown_msi_irq(struct msi_chip *chip, unsigned int
>> irq)
>> {
>> if (platform_teardown_msi_irq)
>> return platform_teardown_msi_irq(irq);
>> @@ -128,6 +129,11 @@ void arch_teardown_msi_irq(unsigned int irq)
>> return ia64_teardown_msi_irq(irq);
>> }
>>
>> +struct msi_chip chip = {
>> +.setup_irq = arch_ia64_setup_msi_irq,
>> +.teardown_irq = arch_ia64_teardown_msi_irq,
>> +};
>> +
>> #ifdef CONFIG_INTEL_IOMMU
>> #ifdef CONFIG_SMP
>> static int dmar_msi_set_affinity(struct irq_data *data,
>> diff --git a/arch/ia64/pci/pci.c b/arch/ia64/pci/pci.c
>> index 291a582..299b67d 100644
>> --- a/arch/ia64/pci/pci.c
>> +++ b/arch/ia64/pci/pci.c
>> @@ -437,6 +437,7 @@ struct pci_bus *pci_acpi_scan_root(struct acpi_pci_root
>> *root)
>>
>> controller->companion = device;
>> controller->node = acpi_get_node(device->handle);
>> +controller->msi_chip = &chip;
>>
>> info = kzalloc(sizeof(*info), GFP_KERNEL);
>> if (!info) {
>> --
>> 1.7.1
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
>> the body of a message to majord...@vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>> Please read the FAQ at http://www.tux.org/lkml/
>
> .
>
--
Thanks!
Yijing
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v3 24/27] IA64/MSI: Use MSI chip framework to configure MSI/MSI-X irq
On Wed, Oct 15, 2014 at 11:07:12AM +0800, Yijing Wang wrote:
> Use MSI chip framework instead of arch MSI functions to configure
> MSI/MSI-X irq. So we can manage MSI/MSI-X irq in a unified framework.
This needs slightly more detail. You're using the MSI chip framework
"instead of arch MSI functions". Well, there are still arch-specific
functions, i.e., arch_ia64_setup_msi_irq() and
arch_ia64_teardown_msi_irq().
We used to have arch_setup_msi_irq() which had a weak default
implementation, and a strong arch-specific implementation here, and you're
replacing that model with the new "msi-ops" model. I don't know how you
want to write that, but it's not that you're getting rid of the
arch-specific code; you're keeping arch-specific code but structuring it
differently.
> Signed-off-by: Yijing Wang
> ---
> arch/ia64/include/asm/pci.h | 10 ++
> arch/ia64/kernel/msi_ia64.c | 14 ++
> arch/ia64/pci/pci.c |1 +
> 3 files changed, 21 insertions(+), 4 deletions(-)
>
> diff --git a/arch/ia64/include/asm/pci.h b/arch/ia64/include/asm/pci.h
> index 52af5ed..907dcba 100644
> --- a/arch/ia64/include/asm/pci.h
> +++ b/arch/ia64/include/asm/pci.h
> @@ -94,6 +94,7 @@ struct pci_controller {
> int segment;
> int node; /* nearest node with memory or NUMA_NO_NODE for
> global allocation */
>
> + struct msi_chip *msi_chip;
> void *platform_data;
> };
>
> @@ -101,6 +102,15 @@ struct pci_controller {
> #define PCI_CONTROLLER(busdev) ((struct pci_controller *) busdev->sysdata)
> #define pci_domain_nr(busdev)(PCI_CONTROLLER(busdev)->segment)
>
> +extern struct msi_chip chip;
Please make this name more descriptive. "chip" is way too generic for a
global name.
> +static inline struct msi_chip *pci_msi_chip(struct pci_bus *bus)
> +{
> + struct pci_controller *ctrl = bus->sysdata;
> +
> + return ctrl->msi_chip;
> +}
> +
> extern struct pci_ops pci_root_ops;
>
> static inline int pci_proc_domain(struct pci_bus *bus)
> diff --git a/arch/ia64/kernel/msi_ia64.c b/arch/ia64/kernel/msi_ia64.c
> index 8c3730c..401fc98 100644
> --- a/arch/ia64/kernel/msi_ia64.c
> +++ b/arch/ia64/kernel/msi_ia64.c
> @@ -112,15 +112,16 @@ static struct irq_chip ia64_msi_chip = {
> };
>
>
> -int arch_setup_msi_irq(struct pci_dev *pdev, struct msi_desc *desc)
> +static int arch_ia64_setup_msi_irq(struct msi_chip *chip,
> + struct pci_dev *dev, struct msi_desc *desc)
> {
> if (platform_setup_msi_irq)
> - return platform_setup_msi_irq(pdev, desc);
> + return platform_setup_msi_irq(dev, desc);
>
> - return ia64_setup_msi_irq(pdev, desc);
> + return ia64_setup_msi_irq(dev, desc);
Please don't make gratuitous changes ("pdev" -> "dev") at the same time,
especially since the rest of the file still uses "pdev".
> }
>
> -void arch_teardown_msi_irq(unsigned int irq)
> +static void arch_ia64_teardown_msi_irq(struct msi_chip *chip, unsigned int
> irq)
> {
> if (platform_teardown_msi_irq)
> return platform_teardown_msi_irq(irq);
> @@ -128,6 +129,11 @@ void arch_teardown_msi_irq(unsigned int irq)
> return ia64_teardown_msi_irq(irq);
> }
>
> +struct msi_chip chip = {
> + .setup_irq = arch_ia64_setup_msi_irq,
> + .teardown_irq = arch_ia64_teardown_msi_irq,
> +};
> +
> #ifdef CONFIG_INTEL_IOMMU
> #ifdef CONFIG_SMP
> static int dmar_msi_set_affinity(struct irq_data *data,
> diff --git a/arch/ia64/pci/pci.c b/arch/ia64/pci/pci.c
> index 291a582..299b67d 100644
> --- a/arch/ia64/pci/pci.c
> +++ b/arch/ia64/pci/pci.c
> @@ -437,6 +437,7 @@ struct pci_bus *pci_acpi_scan_root(struct acpi_pci_root
> *root)
>
> controller->companion = device;
> controller->node = acpi_get_node(device->handle);
> + controller->msi_chip = &chip;
>
> info = kzalloc(sizeof(*info), GFP_KERNEL);
> if (!info) {
> --
> 1.7.1
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH V2 1/2] mm: Update generic gup implementation to handle hugepage directory
On Fri, 17 Oct 2014 10:08:06 +0530 "Aneesh Kumar K.V"
wrote:
> Update generic gup implementation with powerpc specific details.
> On powerpc at pmd level we can have hugepte, normal pmd pointer
> or a pointer to the hugepage directory.
>
> ...
>
> --- a/arch/arm/include/asm/pgtable.h
> +++ b/arch/arm/include/asm/pgtable.h
> @@ -181,6 +181,8 @@ extern pgd_t swapper_pg_dir[PTRS_PER_PGD];
> /* to find an entry in a kernel page-table-directory */
> #define pgd_offset_k(addr) pgd_offset(&init_mm, addr)
>
> +#define pgd_huge(pgd)(0)
> +
> #define pmd_none(pmd)(!pmd_val(pmd))
> #define pmd_present(pmd) (pmd_val(pmd))
>
> diff --git a/arch/arm64/include/asm/pgtable.h
> b/arch/arm64/include/asm/pgtable.h
> index cefd3e825612..ed8f42497ac4 100644
> --- a/arch/arm64/include/asm/pgtable.h
> +++ b/arch/arm64/include/asm/pgtable.h
> @@ -464,6 +464,8 @@ static inline pmd_t pmd_modify(pmd_t pmd, pgprot_t
> newprot)
> extern pgd_t swapper_pg_dir[PTRS_PER_PGD];
> extern pgd_t idmap_pg_dir[PTRS_PER_PGD];
>
> +#define pgd_huge(pgd)(0)
> +
So only arm, arm64 and powerpc implement CONFIG_HAVE_GENERIC_RCU_GUP
and only powerpc impements pgd_huge().
Could we get a bit of documentation in place for pgd_huge() so that
people who aren't familiar with powerpc can understand what's going on?
> /*
> * Encode and decode a swap entry:
> * bits 0-1: present (must be zero)
> diff --git a/include/linux/mm.h b/include/linux/mm.h
> index 02d11ee7f19d..f97732412cb4 100644
> --- a/include/linux/mm.h
> +++ b/include/linux/mm.h
> @@ -1219,6 +1219,32 @@ long get_user_pages(struct task_struct *tsk, struct
> mm_struct *mm,
> struct vm_area_struct **vmas);
> int get_user_pages_fast(unsigned long start, int nr_pages, int write,
> struct page **pages);
> +
> +#ifdef CONFIG_HAVE_GENERIC_RCU_GUP
> +#ifndef is_hugepd
And is_hugepd is a bit of a mystery. Let's get some description in
place for this as well? Why it exists, what its role is. Also,
specifically which arch header file is responsible for defining it.
It takes a hugepd_t argument, but hugepd_t is defined later in this
header file. This is weird because any preceding implementation of
is_hugepd() can't actually be implemented because it hasn't seen the
hugepd_t definition yet! So any is_hugepd() implementation is forced
to be a simple macro which punts to a C function which *has* seen the
hugepd_t definition. What a twisty maze.
It all seems messy, confusing and poorly documented. Can we clean this
up?
> +/*
> + * Some architectures support hugepage directory format that is
> + * required to support different hugetlbfs sizes.
> + */
> +typedef struct { unsigned long pd; } hugepd_t;
> +#define is_hugepd(hugepd) (0)
> +#define __hugepd(x) ((hugepd_t) { (x) })
What's this.
> +static inline int gup_hugepd(hugepd_t hugepd, unsigned long addr,
> + unsigned pdshift, unsigned long end,
> + int write, struct page **pages, int *nr)
> +{
> + return 0;
> +}
> +#else
> +extern int gup_hugepd(hugepd_t hugepd, unsigned long addr,
> + unsigned pdshift, unsigned long end,
> + int write, struct page **pages, int *nr);
> +#endif
> +extern int gup_huge_pte(pte_t orig, pte_t *ptep, unsigned long addr,
> + unsigned long sz, unsigned long end, int write,
> + struct page **pages, int *nr);
> +#endif
> +
>
> ...
>
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 3/4] dt/bindings: Introduce the FSL QorIQ DPAA QMan
Hello Mark, On 10/22/2014 09:37 AM, Mark Rutland wrote: > On Wed, Oct 22, 2014 at 03:09:31PM +0100, Emil Medve wrote: >> The Queue Manager is part of the Data-Path Acceleration Architecture (DPAA). >> QMan supports queuing and QoS scheduling of frames to CPUs, network >> interfaces >> and DPAA logic modules, maintains packet ordering within flows. Besides >> providing flow-level queuing, is also responsible for congestion management >> functions such as RED/WRED, congestion notifications and tail discards. This >> binding covers the CCSR space programming model >> >> Signed-off-by: Emil Medve >> Change-Id: I3acb223893e42003d6c9dc061db568ec0b10d29b >> --- >> .../devicetree/bindings/powerpc/fsl/qman.txt | 134 >> + >> 1 file changed, 134 insertions(+) >> create mode 100644 Documentation/devicetree/bindings/powerpc/fsl/qman.txt >> >> diff --git a/Documentation/devicetree/bindings/powerpc/fsl/qman.txt >> b/Documentation/devicetree/bindings/powerpc/fsl/qman.txt >> new file mode 100644 >> index 000..b9f288f >> --- /dev/null >> +++ b/Documentation/devicetree/bindings/powerpc/fsl/qman.txt >> @@ -0,0 +1,134 @@ >> +QorIQ DPAA Queue Manager Device Tree Binding >> + >> +Copyright (C) 2008 - 2014 Freescale Semiconductor Inc. >> + >> +CONTENTS >> + >> +- QMan Node >> +- QMan Private Memory Nodes >> +- Example >> + >> +NOTE: The bindings described in this document are preliminary and >> subject to >> +change > > As with the BMan portal binding, I'm rather uncomfortable with a > preliminary binding. Ditto >> + >> +QMan Node >> + >> +PROPERTIES >> + >> +- compatible >> +Usage: Required >> +Value type: >> +Definition: Must include "fsl,qman" >> +May include "fsl,-qman" >> + >> +- reg >> +Usage: Required >> +Value type: >> +Definition: Registers region within the CCSR address space >> + >> +- fsl,liodn >> +Usage: See pamu.txt >> +Value type: >> +Definition: PAMU property used for static LIODN assignment >> + >> +- fsl,iommu-parent >> +Usage: See pamu.txt >> +Value type: >> +Definition: PAMU property used for dynamic LIODN assignment >> + >> +For additional details about the PAMU/LIODN binding(s) see pamu.txt > > This is not present in the example. Is this always required? Sort of. Initial hardware (and current documentation) programming suggestion was to configure all the PAMU instances the same way regardless of what devices were behind them. Given the PAMU internal caches sizes, this proved suboptimal from a performance perspective so we're trying to discover/describe/use the PAMU topology fsl,liodn is part of the undocumented static LIODN assignment binding that the current PAMU driver uses. If fsl,iommu-parent is present, fsl,liodn can be ignored and the LIODN can be assigned dynamically and/or programmed only in the relevant PAMU instance >> + >> +- clocks >> +Usage: See clock-bindings.txt and qoriq-clock.txt >> +Value type: >> +Definition: Half of the platform clock >> + > > I don't understand the description here. What is the clock from the PoV > of the QMan? Which input line on the QMan is this clock attached to? > > Is there only one clock input? Or jsut one that you need to manage at > the moment? As part of the programming model (QoS features specifically) QMan needs to know its clock speed. Prior to the existence of the clock-bindings.txt, a "static" clock-frequency property was/is used convey such information. Using clock-binding.txt to describe the clocking hierarchy in the SoC makes it easier with DFS, power management, etc. The platform clock/PLL binding is part of qoriq-clock.txt > You also seem to have an interrupt in the example. How many do you > expect, and what are their their logical functions? That's the error interrupt and hopefully it never triggers. I didn't add [many] words about it as it's a standard property >> +QMan Private Memory Nodes >> + >> +QMan requires two contiguous range of physical memory used for the backing >> store >> +for QMan Frame Queue Descriptor and Packed Frame Descriptor Record. This >> memory >> +is reserved/allocated as a nodes under the /reserved-memory node >> + >> +The QMan FQD memory node must be named "qman-fqd" >> + >> +PROPERTIES >> + >> +- compatible >> +Usage: required >> +Value type: >> +Definition: Must inclide "fsl,qman-fqd" >> + >> +The QMan PFDR memory node must be named "qman-pfdr" >> + >> +PROPERTIES >> + >> +- compatible >> +Usage: required >> +Value type: >> +Definition: Must inclide "fsl,qman-pfdr" >> + >> +The following constraints are relevant to the FQD and PFDR private memory: >> +- The size must be 2^(size + 1), with size = 11..29. That is 4 KiB to >> + 1 GiB >> +- The alignment must be a muliptle of the memory size >> + >> +The si
Re: [PATCH 2/4] dt/bindings: Introduce the FSL QorIQ DPAA BMan portal(s)
Hello Mark,
Thanks for having a look at this
On 10/22/2014 09:29 AM, Mark Rutland wrote:
> On Wed, Oct 22, 2014 at 03:09:30PM +0100, Emil Medve wrote:
>> Portals are used by software running on processor cores, accelerators and
>> network interfaces to communicate with the BMan
>
> What exactly is a portal?
>
> Is it a region of shared memory? A device?
In a nutshell a (software, i.e. processor core accessible) portal is a
memory mapped interface to the B/QMan that allows low latency, lock-less
interaction by logically separated units of software. The original
intent was to have one affine portal per core. As of now we're
sprinkling portals to use from various (core affine) contexts:
hypervisor, guests, user-space, containers, etc.
I'll make the definition more palatable in the next round
> I only received emails 2 and 3 of this series, so I'm lacking the
> context necessary to understand the bindings.
Some bubble in the pipe... As of now they all seem to have hit the
e-mail list(s), patchwork and hopefully your Inbox
>> Signed-off-by: Emil Medve
>> Change-Id: I6d245ffc14ba3d0e91d403ac7c3b91b75a9e6a95
>> ---
>> .../bindings/powerpc/fsl/bman-portals.txt | 50
>> ++
>> 1 file changed, 50 insertions(+)
>> create mode 100644
>> Documentation/devicetree/bindings/powerpc/fsl/bman-portals.txt
>>
>> diff --git a/Documentation/devicetree/bindings/powerpc/fsl/bman-portals.txt
>> b/Documentation/devicetree/bindings/powerpc/fsl/bman-portals.txt
>> new file mode 100644
>> index 000..40e607e
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/powerpc/fsl/bman-portals.txt
>> @@ -0,0 +1,50 @@
>> +QorIQ DPAA Buffer Manager Portals Device Tree Binding
>> +
>> +Copyright (C) 2008 - 2014 Freescale Semiconductor Inc.
>> +
>> +CONTENTS
>> +
>> +- BMan Portal
>> +- Example
>> +
>> +NOTE: The bindings described in this document are preliminary and
>> subject to
>> +change
>
> While we've tried that elsewhere, unstable DT bindings have been shown
> to be a major source of pain.
Agreed
> I'd feel rather uncomfortable accepting a
> binding that we already believe to be insufficient to describe the
> hardware.
>
> What do you expect to change?
Related bindings seem incomplete. As such, the PAMU binding (pamu.txt)
covers incompletely a dynamic LIODN assignment/programming model. The
current driver uses a static assignment scheme that the binding needs to
include. I also suspect that once the driver starts supporting the
dynamic LIODN assignment/programming we might find some wrinkles
>> +
>> +BMan Portal Node
>> +
>> +PROPERTIES
>> +
>> +- compatible
>> +Usage: Required
>> +Value type:
>> +Definition: Must include "fsl,bman-portal-"
>> +May include "fsl,-bman-portal" or "fsl,bman-portal"
>> +
>> +- reg
>> +Usage: Required
>> +Value type:
>> +Definition: Two regions. The first is the cache-enabled region of
>> +the portal. The second is the cache-inhibited region of
>> +the portal
>> +
>> +EXAMPLE
>> +
>> +The example below shows a (P4080) BMan portals container/bus node with two
>> portals
>
> Is there any particular reason to place these under a simple-bus?
I think they fit the ePAPR definition for simple-bus container. They can
be accessed directly and can be used independently. What are you suggesting?
>> +
>> +bman-portals@ff400 {
>> +#address-cells = <1>;
>> +#size-cells = <1>;
>> +compatible = "simple-bus";
>> +ranges = <0 0xf 0xf400 0x20>;
>> +
>> +bman-portal@0 {
>> +compatible = "fsl,bman-portal-1.0.0", "fsl,bman-portal";
>> +reg = <0x0 0x4000 0x10 0x1000>;
>
> It would be easier to read is each entry had its own set of brackets.
> Initially this looked to me like a single 64-bit address/size pair.
Something like <>, <>? It doesn't seem widely used but I agree is more
readable. I can include it in the the next spin
>> +interrupts = <105 2 0 0>;
>> +};
>
> Given the description above, surely you need to know what the portal is
> used for? Or is that queried from the portal?
We don't need/want to include such information in the DT. Portals are
"allocated" dynamically and used by the respective context
Cheers,
> Thanks,
> Mark.
>
>> +bman-portal@4000 {
>> +compatible = "fsl,bman-portal-1.0.0", "fsl,bman-portal";
>> +reg = <0x4000 0x4000 0x101000 0x1000>;
>> +interrupts = <107 2 0 0>;
>> +};
>> +};
>> --
>> 2.1.2
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] net: fs_enet: set back promiscuity mode after restart
From: Christophe Leroy Date: Wed, 22 Oct 2014 09:05:47 +0200 (CEST) > After interface restart (eg: after link disconnection/reconnection), the > bridge > function doesn't work anymore. This is due to the promiscuous mode being > cleared > by the restart. > > The mac-fcc already includes code to set the promiscuous mode back during the > restart. > This patch adds the same handling to mac-fec and mac-scc. > > Tested with bridge function on MPC885 with FEC. > > Reported-by: Germain Montoies > Signed-off-by: Christophe Leroy Applied, thanks. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] powerpc: Convert power off logic to pm_power_off
On 10/21/2014 09:37 PM, Michael Ellerman wrote: The generic Linux framework to power off the machine is a function pointer called pm_power_off. The trick about this pointer is that device drivers can potentially implement it rather than board files. Today on powerpc we set pm_power_off to invoke our generic full machine power off logic which then calls ppc_md.power_off to invoke machine specific power off. However, when we want to add a power off GPIO via the "gpio-poweroff" driver, this card house falls apart. That driver only registers itself if pm_power_off is NULL to ensure it doesn't override board specific logic. However, since we always set pm_power_off to the generic power off logic (which will just not power off the machine if no ppc_md.power_off call is implemented), we can't implement power off via the generic GPIO power off driver. To fix this up, let's get rid of the ppc_md.power_off logic and just always use pm_power_off as was intended. Then individual drivers such as the GPIO power off driver can implement power off logic via that function pointer. With this patch set applied and a few patches on top of QEMU that implement a power off GPIO on the virt e500 machine, I can successfully turn off my virtual machine after halt. Signed-off-by: Alexander Graf [mpe: Squash into one patch and update changelog based on cover letter] Signed-off-by: Michael Ellerman --- arch/powerpc/include/asm/machdep.h | 1 - arch/powerpc/kernel/setup-common.c | 6 +-- arch/powerpc/platforms/44x/ppc476.c | 2 +- arch/powerpc/platforms/52xx/efika.c | 3 +- arch/powerpc/platforms/83xx/mcu_mpc8349emitx.c | 8 ++-- arch/powerpc/platforms/85xx/corenet_generic.c| 2 +- arch/powerpc/platforms/85xx/sgy_cts1000.c| 4 +- arch/powerpc/platforms/cell/celleb_setup.c | 4 +- arch/powerpc/platforms/cell/qpace_setup.c| 2 +- arch/powerpc/platforms/cell/setup.c | 2 +- arch/powerpc/platforms/chrp/setup.c | 3 +- arch/powerpc/platforms/embedded6xx/gamecube.c| 3 +- arch/powerpc/platforms/embedded6xx/linkstation.c | 4 +- arch/powerpc/platforms/embedded6xx/wii.c | 3 +- arch/powerpc/platforms/maple/setup.c | 4 +- arch/powerpc/platforms/powermac/setup.c | 3 +- arch/powerpc/platforms/powernv/setup.c | 4 +- arch/powerpc/platforms/ps3/setup.c | 2 +- arch/powerpc/platforms/pseries/setup.c | 59 arch/powerpc/sysdev/fsl_soc.c| 2 +- arch/powerpc/xmon/xmon.c | 3 +- 21 files changed, 66 insertions(+), 58 deletions(-) Hi guys, how does this look? If it's OK I'll put it in a topic branch for Guenter. Looks good to me. Guenter ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH v3 30/59] dmaengine: fsl-dma: Split device_control
Split the device_control callback of the Freescale Elo DMA driver to make use
of the newly introduced callbacks, that will eventually be used to retrieve
slave capabilities.
While we're at it, remove the useless prep_sg callback.
Signed-off-by: Maxime Ripard
---
drivers/dma/fsldma.c | 91 ++--
1 file changed, 32 insertions(+), 59 deletions(-)
diff --git a/drivers/dma/fsldma.c b/drivers/dma/fsldma.c
index 994bcb2c6b92..4b557643a737 100644
--- a/drivers/dma/fsldma.c
+++ b/drivers/dma/fsldma.c
@@ -941,37 +941,8 @@ fail:
return NULL;
}
-/**
- * fsl_dma_prep_slave_sg - prepare descriptors for a DMA_SLAVE transaction
- * @chan: DMA channel
- * @sgl: scatterlist to transfer to/from
- * @sg_len: number of entries in @scatterlist
- * @direction: DMA direction
- * @flags: DMAEngine flags
- * @context: transaction context (ignored)
- *
- * Prepare a set of descriptors for a DMA_SLAVE transaction. Following the
- * DMA_SLAVE API, this gets the device-specific information from the
- * chan->private variable.
- */
-static struct dma_async_tx_descriptor *fsl_dma_prep_slave_sg(
- struct dma_chan *dchan, struct scatterlist *sgl, unsigned int sg_len,
- enum dma_transfer_direction direction, unsigned long flags,
- void *context)
-{
- /*
-* This operation is not supported on the Freescale DMA controller
-*
-* However, we need to provide the function pointer to allow the
-* device_control() method to work.
-*/
- return NULL;
-}
-
-static int fsl_dma_device_control(struct dma_chan *dchan,
- enum dma_ctrl_cmd cmd, unsigned long arg)
+static int fsl_dma_device_terminate_all(struct dma_chan *dchan)
{
- struct dma_slave_config *config;
struct fsldma_chan *chan;
int size;
@@ -980,45 +951,47 @@ static int fsl_dma_device_control(struct dma_chan *dchan,
chan = to_fsl_chan(dchan);
- switch (cmd) {
- case DMA_TERMINATE_ALL:
- spin_lock_bh(&chan->desc_lock);
-
- /* Halt the DMA engine */
- dma_halt(chan);
+ spin_lock_bh(&chan->desc_lock);
- /* Remove and free all of the descriptors in the LD queue */
- fsldma_free_desc_list(chan, &chan->ld_pending);
- fsldma_free_desc_list(chan, &chan->ld_running);
- fsldma_free_desc_list(chan, &chan->ld_completed);
- chan->idle = true;
+ /* Halt the DMA engine */
+ dma_halt(chan);
- spin_unlock_bh(&chan->desc_lock);
- return 0;
+ /* Remove and free all of the descriptors in the LD queue */
+ fsldma_free_desc_list(chan, &chan->ld_pending);
+ fsldma_free_desc_list(chan, &chan->ld_running);
+ fsldma_free_desc_list(chan, &chan->ld_completed);
+ chan->idle = true;
- case DMA_SLAVE_CONFIG:
- config = (struct dma_slave_config *)arg;
+ spin_unlock_bh(&chan->desc_lock);
+ return 0;
+}
- /* make sure the channel supports setting burst size */
- if (!chan->set_request_count)
- return -ENXIO;
+static int fsl_dma_device_config(struct dma_chan *dchan,
+struct dma_slave_config *config)
+{
+ struct fsldma_chan *chan;
+ int size;
- /* we set the controller burst size depending on direction */
- if (config->direction == DMA_MEM_TO_DEV)
- size = config->dst_addr_width * config->dst_maxburst;
- else
- size = config->src_addr_width * config->src_maxburst;
+ if (!dchan)
+ return -EINVAL;
- chan->set_request_count(chan, size);
- return 0;
+ chan = to_fsl_chan(dchan);
- default:
+ /* make sure the channel supports setting burst size */
+ if (!chan->set_request_count)
return -ENXIO;
- }
+ /* we set the controller burst size depending on direction */
+ if (config->direction == DMA_MEM_TO_DEV)
+ size = config->dst_addr_width * config->dst_maxburst;
+ else
+ size = config->src_addr_width * config->src_maxburst;
+
+ chan->set_request_count(chan, size);
return 0;
}
+
/**
* fsl_dma_memcpy_issue_pending - Issue the DMA start command
* @chan : Freescale DMA channel
@@ -1396,8 +1369,8 @@ static int fsldma_of_probe(struct platform_device *op)
fdev->common.device_prep_dma_sg = fsl_dma_prep_sg;
fdev->common.device_tx_status = fsl_tx_status;
fdev->common.device_issue_pending = fsl_dma_memcpy_issue_pending;
- fdev->common.device_prep_slave_sg = fsl_dma_prep_slave_sg;
- fdev->common.device_control = fsl_dma_device_control;
+ fdev->common.device_config = fsl_dma_device_config;
+ fdev->common.device_terminate_all = fsl_d
Re: [PATCH v2 08/47] kernel: Move pm_power_off to common code
On Wed, Oct 22, 2014 at 05:31:36PM +0200, Ralf Baechle wrote: > On Mon, Oct 20, 2014 at 09:12:24PM -0700, Guenter Roeck wrote: > > > pm_power_off is defined for all architectures. Move it to common code. > > > > Have all architectures call do_kernel_power_off instead of pm_power_off. > > Some architectures point pm_power_off to machine_power_off. For those, > > call do_kernel_power_off from machine_power_off instead. > > > > Acked-by: David Vrabel > > Acked-by: Geert Uytterhoeven > > Acked-by: Hirokazu Takata > > Acked-by: Jesper Nilsson > > Acked-by: Max Filippov > > Acked-by: Rafael J. Wysocki > > Acked-by: Richard Weinberger > > Acked-by: Xuetao Guan > > Signed-off-by: Guenter Roeck > > Acked-by: Ralf Baechle Thanks! Guenter ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v2 08/47] kernel: Move pm_power_off to common code
On Mon, Oct 20, 2014 at 09:12:24PM -0700, Guenter Roeck wrote: > pm_power_off is defined for all architectures. Move it to common code. > > Have all architectures call do_kernel_power_off instead of pm_power_off. > Some architectures point pm_power_off to machine_power_off. For those, > call do_kernel_power_off from machine_power_off instead. > > Acked-by: David Vrabel > Acked-by: Geert Uytterhoeven > Acked-by: Hirokazu Takata > Acked-by: Jesper Nilsson > Acked-by: Max Filippov > Acked-by: Rafael J. Wysocki > Acked-by: Richard Weinberger > Acked-by: Xuetao Guan > Signed-off-by: Guenter Roeck Acked-by: Ralf Baechle ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 2/3] dt/bindings: qoriq-clock: Add binding for the platform PLL
Signed-off-by: Emil Medve
Change-Id: I7950afa9650d15ec7ce2cca89bb2a1e38586d4a5
---
Documentation/devicetree/bindings/clock/qoriq-clock.txt | 17 +++--
1 file changed, 11 insertions(+), 6 deletions(-)
diff --git a/Documentation/devicetree/bindings/clock/qoriq-clock.txt
b/Documentation/devicetree/bindings/clock/qoriq-clock.txt
index 5666812..407fb01 100644
--- a/Documentation/devicetree/bindings/clock/qoriq-clock.txt
+++ b/Documentation/devicetree/bindings/clock/qoriq-clock.txt
@@ -62,6 +62,8 @@ Required properties:
It takes parent's clock-frequency as its clock.
* "fsl,qoriq-sysclk-2.0": for input system clock (v2.0).
It takes parent's clock-frequency as its clock.
+ * "fsl,qoriq-platform-pll-1.0" for the platform PLL clock (v1.0)
+ * "fsl,qoriq-platform-pll-2.0" for the platform PLL clock (v2.0)
- #clock-cells: From common clock binding. The number of cells in a
clock-specifier. Should be <0> for "fsl,qoriq-sysclk-[1,2].0"
clocks, or <1> for "fsl,qoriq-core-pll-[1,2].0" clocks.
@@ -94,7 +96,6 @@ Example for clock block and clock provider:
compatible = "fsl,qoriq-sysclk-1.0";
clock-output-names = "sysclk";
};
-
pll0: pll0@800 {
#clock-cells = <1>;
reg = <0x800 0x4>;
@@ -102,7 +103,6 @@ Example for clock block and clock provider:
clocks = <&sysclk>;
clock-output-names = "pll0", "pll0-div2";
};
-
pll1: pll1@820 {
#clock-cells = <1>;
reg = <0x820 0x4>;
@@ -110,7 +110,6 @@ Example for clock block and clock provider:
clocks = <&sysclk>;
clock-output-names = "pll1", "pll1-div2";
};
-
mux0: mux0@0 {
#clock-cells = <0>;
reg = <0x0 0x4>;
@@ -119,7 +118,6 @@ Example for clock block and clock provider:
clock-names = "pll0", "pll0-div2", "pll1", "pll1-div2";
clock-output-names = "cmux0";
};
-
mux1: mux1@20 {
#clock-cells = <0>;
reg = <0x20 0x4>;
@@ -128,8 +126,15 @@ Example for clock block and clock provider:
clock-names = "pll0", "pll0-div2", "pll1", "pll1-div2";
clock-output-names = "cmux1";
};
+ platform-pll: platform-pll@c00 {
+ #clock-cells = <1>;
+ reg = <0xc00 0x4>;
+ compatible = "fsl,qoriq-platform-pll-1.0";
+ clocks = <&sysclk>;
+ clock-output-names = "platform-pll",
"platform-pll-div2";
+ };
};
- }
+};
Example for clock consumer:
@@ -139,4 +144,4 @@ Example for clock consumer:
clocks = <&mux0>;
...
};
- }
+};
--
2.1.2
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 1/3] powerpc/dts: Factorize the clock control node
Signed-off-by: Emil Medve
Change-Id: I25ce24a25862b4ca460164159867abefe00ccdd1
---
arch/powerpc/boot/dts/b4860emu.dts | 4 +-
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| 49 +---
arch/powerpc/boot/dts/fsl/p3041si-post.dtsi| 49 +---
arch/powerpc/boot/dts/fsl/p4080si-post.dtsi| 55 +-
arch/powerpc/boot/dts/fsl/p5020si-post.dtsi| 48 +---
arch/powerpc/boot/dts/fsl/p5040si-post.dtsi| 49 +---
arch/powerpc/boot/dts/fsl/qoriq-clockgen1.dtsi | 78 ++
arch/powerpc/boot/dts/fsl/qoriq-clockgen2.dtsi | 61
arch/powerpc/boot/dts/fsl/t1040si-post.dtsi| 33 +--
arch/powerpc/boot/dts/fsl/t2081si-post.dtsi| 30 +-
arch/powerpc/boot/dts/fsl/t4240si-post.dtsi| 34 +--
arch/powerpc/boot/dts/t4240emu.dts | 4 +-
14 files changed, 163 insertions(+), 387 deletions(-)
create mode 100644 arch/powerpc/boot/dts/fsl/qoriq-clockgen1.dtsi
create mode 100644 arch/powerpc/boot/dts/fsl/qoriq-clockgen2.dtsi
diff --git a/arch/powerpc/boot/dts/b4860emu.dts
b/arch/powerpc/boot/dts/b4860emu.dts
index 85646b4..2aa5cd3 100644
--- a/arch/powerpc/boot/dts/b4860emu.dts
+++ b/arch/powerpc/boot/dts/b4860emu.dts
@@ -193,9 +193,9 @@
fsl,liodn-bits = <12>;
};
- clockgen: global-utilities@e1000 {
+/include/ "fsl/qoriq-clockgen2.dtsi"
+ global-utilities@e1000 {
compatible = "fsl,b4-clockgen", "fsl,qoriq-clockgen-2.0";
- reg = <0xe1000 0x1000>;
};
/include/ "fsl/qoriq-dma-0.dtsi"
diff --git a/arch/powerpc/boot/dts/fsl/b4420si-post.dtsi
b/arch/powerpc/boot/dts/fsl/b4420si-post.dtsi
index b34c62e..aced374 100644
--- a/arch/powerpc/boot/dts/fsl/b4420si-post.dtsi
+++ b/arch/powerpc/boot/dts/fsl/b4420si-post.dtsi
@@ -80,33 +80,9 @@
compatible = "fsl,b4420-device-config",
"fsl,qoriq-device-config-2.0";
};
- clockgen: global-utilities@e1000 {
+/include/ "qoriq-clockgen2.dtsi"
+ global-utilities@e1000 {
compatible = "fsl,b4420-clockgen", "fsl,qoriq-clockgen-2.0";
- ranges = <0x0 0xe1000 0x1000>;
- #address-cells = <1>;
- #size-cells = <1>;
-
- sysclk: sysclk {
- #clock-cells = <0>;
- compatible = "fsl,qoriq-sysclk-2.0";
- clock-output-names = "sysclk";
- };
-
- pll0: pll0@800 {
- #clock-cells = <1>;
- reg = <0x800 0x4>;
- compatible = "fsl,qoriq-core-pll-2.0";
- clocks = <&sysclk>;
- clock-output-names = "pll0", "pll0-div2", "pll0-div4";
- };
-
- pll1: pll1@820 {
- #clock-cells = <1>;
- reg = <0x820 0x4>;
- compatible = "fsl,qoriq-core-pll-2.0";
- clocks = <&sysclk>;
- clock-output-names = "pll1", "pll1-div2", "pll1-div4";
- };
mux0: mux0@0 {
#clock-cells = <0>;
diff --git a/arch/powerpc/boot/dts/fsl/b4860si-post.dtsi
b/arch/powerpc/boot/dts/fsl/b4860si-post.dtsi
index 256fac8..3b9bb37 100644
--- a/arch/powerpc/boot/dts/fsl/b4860si-post.dtsi
+++ b/arch/powerpc/boot/dts/fsl/b4860si-post.dtsi
@@ -273,33 +273,9 @@
compatible = "fsl,b4860-device-config",
"fsl,qoriq-device-config-2.0";
};
- clockgen: global-utilities@e1000 {
+/include/ "qoriq-clockgen2.dtsi"
+ global-utilities@e1000 {
compatible = "fsl,b4860-clockgen", "fsl,qoriq-clockgen-2.0";
- ranges = <0x0 0xe1000 0x1000>;
- #address-cells = <1>;
- #size-cells = <1>;
-
- sysclk: sysclk {
- #clock-cells = <0>;
- compatible = "fsl,qoriq-sysclk-2.0";
- clock-output-names = "sysclk";
- };
-
- pll0: pll0@800 {
- #clock-cells = <1>;
- reg = <0x800 0x4>;
- compatible = "fsl,qoriq-core-pll-2.0";
- clocks = <&sysclk>;
- clock-output-names = "pll0", "pll0-div2", "pll0-div4";
- };
-
- pll1: pll1@820 {
- #clock-cells = <1>;
- reg = <0x820 0x4>;
- compatible = "fsl,qoriq-core-pll-2.0";
- clocks = <&sysclk>;
- clock-output-names = "pll1", "pll1-div2", "pll1-div4";
- };
mux0: mux0@0 {
#clock-cells = <0>;
diff --git a/arch/powerpc/bo
[PATCH 3/4] dt/bindings: Introduce the FSL QorIQ DPAA QMan
The Queue Manager is part of the Data-Path Acceleration Architecture (DPAA).
QMan supports queuing and QoS scheduling of frames to CPUs, network interfaces
and DPAA logic modules, maintains packet ordering within flows. Besides
providing flow-level queuing, is also responsible for congestion management
functions such as RED/WRED, congestion notifications and tail discards. This
binding covers the CCSR space programming model
Signed-off-by: Emil Medve
Change-Id: I3acb223893e42003d6c9dc061db568ec0b10d29b
---
.../devicetree/bindings/powerpc/fsl/qman.txt | 134 +
1 file changed, 134 insertions(+)
create mode 100644 Documentation/devicetree/bindings/powerpc/fsl/qman.txt
diff --git a/Documentation/devicetree/bindings/powerpc/fsl/qman.txt
b/Documentation/devicetree/bindings/powerpc/fsl/qman.txt
new file mode 100644
index 000..b9f288f
--- /dev/null
+++ b/Documentation/devicetree/bindings/powerpc/fsl/qman.txt
@@ -0,0 +1,134 @@
+QorIQ DPAA Queue Manager Device Tree Binding
+
+Copyright (C) 2008 - 2014 Freescale Semiconductor Inc.
+
+CONTENTS
+
+ - QMan Node
+ - QMan Private Memory Nodes
+ - Example
+
+NOTE: The bindings described in this document are preliminary and subject to
+ change
+
+QMan Node
+
+PROPERTIES
+
+- compatible
+ Usage: Required
+ Value type:
+ Definition: Must include "fsl,qman"
+ May include "fsl,-qman"
+
+- reg
+ Usage: Required
+ Value type:
+ Definition: Registers region within the CCSR address space
+
+- fsl,liodn
+ Usage: See pamu.txt
+ Value type:
+ Definition: PAMU property used for static LIODN assignment
+
+- fsl,iommu-parent
+ Usage: See pamu.txt
+ Value type:
+ Definition: PAMU property used for dynamic LIODN assignment
+
+ For additional details about the PAMU/LIODN binding(s) see pamu.txt
+
+- clocks
+ Usage: See clock-bindings.txt and qoriq-clock.txt
+ Value type:
+ Definition: Half of the platform clock
+
+QMan Private Memory Nodes
+
+QMan requires two contiguous range of physical memory used for the backing
store
+for QMan Frame Queue Descriptor and Packed Frame Descriptor Record. This memory
+is reserved/allocated as a nodes under the /reserved-memory node
+
+The QMan FQD memory node must be named "qman-fqd"
+
+PROPERTIES
+
+- compatible
+ Usage: required
+ Value type:
+ Definition: Must inclide "fsl,qman-fqd"
+
+The QMan PFDR memory node must be named "qman-pfdr"
+
+PROPERTIES
+
+- compatible
+ Usage: required
+ Value type:
+ Definition: Must inclide "fsl,qman-pfdr"
+
+The following constraints are relevant to the FQD and PFDR private memory:
+ - The size must be 2^(size + 1), with size = 11..29. That is 4 KiB to
+ 1 GiB
+ - The alignment must be a muliptle of the memory size
+
+The size of the FQD and PFDP must be chosen by observing the hardware features
+configured via the RCW and that are relevant to a specific board (e.g. number
of
+MAC(s) pinned-out, number of offline/host command FMan ports, etc.). The size
+configured in the DT must reflect the hardware capabilities and not the
specific
+needs of an application
+
+If the memory reserved in the device tree proves to be larger then the needs of
+the application a QMan driver may provide a method to release the extra memory
+back to the OS
+
+For additional details about reserved memory regions see reserved-memory.txt
+
+EXAMPLE
+
+The example below shows a QMan FQD and a PFDR dynamic allocation memory nodes
+
+ reserved-memory {
+ #address-cells = <2>;
+ #size-cells = <2>;
+ ranges;
+
+ qman-fqd {
+ compatible = "fsl,qman-fqd";
+ alloc-ranges = <0 0 0xf 0x>;
+ size = <0 0x40>;
+ alignment = <0 0x40>;
+ };
+ qman-pfdr {
+ compatible = "fsl,qman-pfdr";
+ alloc-ranges = <0 0 0xf 0x>;
+ size = <0 0x200>;
+ alignment = <0 0x200>;
+ };
+ };
+
+The example below shows a (P4080) QMan CCSR-space node
+
+ clockgen: global-utilities@e1000 {
+ ...
+ sysclk: sysclk {
+ ...
+ };
+ ...
+ platform-pll: platform-pll@c00 {
+ #clock-cells = <1>;
+ reg = <0xc00 0x4>;
+ compatible = "fsl,qoriq-platform-pll-1.0";
+ clocks = <&sysclk>;
+ clock-output-names = "platform-pll",
"platform-pll-div2";
+ };
+ ...
+ };
+
+ qman@318000 {
+
[PATCH 2/4] dt/bindings: Introduce the FSL QorIQ DPAA BMan portal(s)
Portals are used by software running on processor cores, accelerators and
network interfaces to communicate with the BMan
Signed-off-by: Emil Medve
Change-Id: I6d245ffc14ba3d0e91d403ac7c3b91b75a9e6a95
---
.../bindings/powerpc/fsl/bman-portals.txt | 50 ++
1 file changed, 50 insertions(+)
create mode 100644
Documentation/devicetree/bindings/powerpc/fsl/bman-portals.txt
diff --git a/Documentation/devicetree/bindings/powerpc/fsl/bman-portals.txt
b/Documentation/devicetree/bindings/powerpc/fsl/bman-portals.txt
new file mode 100644
index 000..40e607e
--- /dev/null
+++ b/Documentation/devicetree/bindings/powerpc/fsl/bman-portals.txt
@@ -0,0 +1,50 @@
+QorIQ DPAA Buffer Manager Portals Device Tree Binding
+
+Copyright (C) 2008 - 2014 Freescale Semiconductor Inc.
+
+CONTENTS
+
+ - BMan Portal
+ - Example
+
+NOTE: The bindings described in this document are preliminary and subject to
+ change
+
+BMan Portal Node
+
+PROPERTIES
+
+- compatible
+ Usage: Required
+ Value type:
+ Definition: Must include "fsl,bman-portal-"
+ May include "fsl,-bman-portal" or "fsl,bman-portal"
+
+- reg
+ Usage: Required
+ Value type:
+ Definition: Two regions. The first is the cache-enabled region of
+ the portal. The second is the cache-inhibited region of
+ the portal
+
+EXAMPLE
+
+The example below shows a (P4080) BMan portals container/bus node with two
portals
+
+ bman-portals@ff400 {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ compatible = "simple-bus";
+ ranges = <0 0xf 0xf400 0x20>;
+
+ bman-portal@0 {
+ compatible = "fsl,bman-portal-1.0.0", "fsl,bman-portal";
+ reg = <0x0 0x4000 0x10 0x1000>;
+ interrupts = <105 2 0 0>;
+ };
+ bman-portal@4000 {
+ compatible = "fsl,bman-portal-1.0.0", "fsl,bman-portal";
+ reg = <0x4000 0x4000 0x101000 0x1000>;
+ interrupts = <107 2 0 0>;
+ };
+ };
--
2.1.2
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 3/3] powerpc/dts: Add node(s) for the platform PLL
Signed-off-by: Emil Medve
Change-Id: If76cd705a01813abe53396c1486bc13c4289ee92
---
arch/powerpc/boot/dts/fsl/qoriq-clockgen1.dtsi | 7 +++
arch/powerpc/boot/dts/fsl/qoriq-clockgen2.dtsi | 7 +++
2 files changed, 14 insertions(+)
diff --git a/arch/powerpc/boot/dts/fsl/qoriq-clockgen1.dtsi
b/arch/powerpc/boot/dts/fsl/qoriq-clockgen1.dtsi
index 4871048..4ece1ed 100644
--- a/arch/powerpc/boot/dts/fsl/qoriq-clockgen1.dtsi
+++ b/arch/powerpc/boot/dts/fsl/qoriq-clockgen1.dtsi
@@ -75,4 +75,11 @@ global-utilities@e1000 {
clock-names = "pll0", "pll0-div2", "pll1", "pll1-div2";
clock-output-names = "cmux1";
};
+ platform_pll: platform-pll@c00 {
+ #clock-cells = <1>;
+ reg = <0xc00 0x4>;
+ compatible = "fsl,qoriq-platform-pll-1.0";
+ clocks = <&sysclk>;
+ clock-output-names = "platform-pll", "platform-pll-div2";
+ };
};
diff --git a/arch/powerpc/boot/dts/fsl/qoriq-clockgen2.dtsi
b/arch/powerpc/boot/dts/fsl/qoriq-clockgen2.dtsi
index 5d18d2a..48e0b6e 100644
--- a/arch/powerpc/boot/dts/fsl/qoriq-clockgen2.dtsi
+++ b/arch/powerpc/boot/dts/fsl/qoriq-clockgen2.dtsi
@@ -58,4 +58,11 @@ global-utilities@e1000 {
clocks = <&sysclk>;
clock-output-names = "pll1", "pll1-div2", "pll1-div4";
};
+ platform_pll: platform-pll@c00 {
+ #clock-cells = <1>;
+ reg = <0xc00 0x4>;
+ compatible = "fsl,qoriq-platform-pll-2.0";
+ clocks = <&sysclk>;
+ clock-output-names = "platform-pll", "platform-pll-div2";
+ };
};
--
2.1.2
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 3/4] dt/bindings: Introduce the FSL QorIQ DPAA QMan
On Wed, Oct 22, 2014 at 03:09:31PM +0100, Emil Medve wrote:
> The Queue Manager is part of the Data-Path Acceleration Architecture (DPAA).
> QMan supports queuing and QoS scheduling of frames to CPUs, network interfaces
> and DPAA logic modules, maintains packet ordering within flows. Besides
> providing flow-level queuing, is also responsible for congestion management
> functions such as RED/WRED, congestion notifications and tail discards. This
> binding covers the CCSR space programming model
>
> Signed-off-by: Emil Medve
> Change-Id: I3acb223893e42003d6c9dc061db568ec0b10d29b
> ---
> .../devicetree/bindings/powerpc/fsl/qman.txt | 134
> +
> 1 file changed, 134 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/powerpc/fsl/qman.txt
>
> diff --git a/Documentation/devicetree/bindings/powerpc/fsl/qman.txt
> b/Documentation/devicetree/bindings/powerpc/fsl/qman.txt
> new file mode 100644
> index 000..b9f288f
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/powerpc/fsl/qman.txt
> @@ -0,0 +1,134 @@
> +QorIQ DPAA Queue Manager Device Tree Binding
> +
> +Copyright (C) 2008 - 2014 Freescale Semiconductor Inc.
> +
> +CONTENTS
> +
> + - QMan Node
> + - QMan Private Memory Nodes
> + - Example
> +
> +NOTE:The bindings described in this document are preliminary and
> subject to
> + change
As with the BMan portal binding, I'm rather uncomfortable with a
preliminary binding.
> +
> +QMan Node
> +
> +PROPERTIES
> +
> +- compatible
> + Usage: Required
> + Value type:
> + Definition: Must include "fsl,qman"
> + May include "fsl,-qman"
> +
> +- reg
> + Usage: Required
> + Value type:
> + Definition: Registers region within the CCSR address space
> +
> +- fsl,liodn
> + Usage: See pamu.txt
> + Value type:
> + Definition: PAMU property used for static LIODN assignment
> +
> +- fsl,iommu-parent
> + Usage: See pamu.txt
> + Value type:
> + Definition: PAMU property used for dynamic LIODN assignment
> +
> + For additional details about the PAMU/LIODN binding(s) see pamu.txt
This is not present in the example. Is this always required?
> +
> +- clocks
> + Usage: See clock-bindings.txt and qoriq-clock.txt
> + Value type:
> + Definition: Half of the platform clock
> +
I don't understand the description here. What is the clock from the PoV
of the QMan? Which input line on the QMan is this clock attached to?
Is there only one clock input? Or jsut one that you need to manage at
the moment?
You also seem to have an interrupt in the example. How many do you
expect, and what are their their logical functions?
> +QMan Private Memory Nodes
> +
> +QMan requires two contiguous range of physical memory used for the backing
> store
> +for QMan Frame Queue Descriptor and Packed Frame Descriptor Record. This
> memory
> +is reserved/allocated as a nodes under the /reserved-memory node
> +
> +The QMan FQD memory node must be named "qman-fqd"
> +
> +PROPERTIES
> +
> +- compatible
> + Usage: required
> + Value type:
> + Definition: Must inclide "fsl,qman-fqd"
> +
> +The QMan PFDR memory node must be named "qman-pfdr"
> +
> +PROPERTIES
> +
> +- compatible
> + Usage: required
> + Value type:
> + Definition: Must inclide "fsl,qman-pfdr"
> +
> +The following constraints are relevant to the FQD and PFDR private memory:
> + - The size must be 2^(size + 1), with size = 11..29. That is 4 KiB to
> + 1 GiB
> + - The alignment must be a muliptle of the memory size
> +
> +The size of the FQD and PFDP must be chosen by observing the hardware
> features
> +configured via the RCW and that are relevant to a specific board (e.g.
> number of
> +MAC(s) pinned-out, number of offline/host command FMan ports, etc.). The size
> +configured in the DT must reflect the hardware capabilities and not the
> specific
> +needs of an application
> +
> +If the memory reserved in the device tree proves to be larger then the needs
> of
> +the application a QMan driver may provide a method to release the extra
> memory
> +back to the OS
Driver details should be unimportant to the binding. This sentence can
disappear.
Thanks,
Mark.
> +
> +For additional details about reserved memory regions see reserved-memory.txt
> +
> +EXAMPLE
> +
> +The example below shows a QMan FQD and a PFDR dynamic allocation memory nodes
> +
> + reserved-memory {
> + #address-cells = <2>;
> + #size-cells = <2>;
> + ranges;
> +
> + qman-fqd {
> + compatible = "fsl,qman-fqd";
> + alloc-ranges = <0 0 0xf 0x>;
> + size = <0 0x40>;
> + alignment = <0 0x40>;
> + };
> + qman-pfdr {
> +
[PATCH 4/4] dt/bindings: Introduce the FSL QorIQ DPAA QMan portal(s)
Portals are used by software running on processor cores, accelerators and
network interfaces to communicate with the QMan
Signed-off-by: Emil Medve
Change-Id: I29764fa8093b5ce65460abc879446795c50d7185
---
.../bindings/powerpc/fsl/qman-portals.txt | 151 +
1 file changed, 151 insertions(+)
create mode 100644
Documentation/devicetree/bindings/powerpc/fsl/qman-portals.txt
diff --git a/Documentation/devicetree/bindings/powerpc/fsl/qman-portals.txt
b/Documentation/devicetree/bindings/powerpc/fsl/qman-portals.txt
new file mode 100644
index 000..c4e1e98
--- /dev/null
+++ b/Documentation/devicetree/bindings/powerpc/fsl/qman-portals.txt
@@ -0,0 +1,151 @@
+QorIQ DPAA Queue Manager Portals Device Tree Binding
+
+Copyright (C) 2008 - 2014 Freescale Semiconductor Inc.
+
+CONTENTS
+
+ - QMan Portal
+ - QMan Pool Channel
+ - Example
+
+NOTE: The bindings described in this document are preliminary and subject to
+ change
+
+QMan Portal Node
+
+PROPERTIES
+
+- compatible
+ Usage: Required
+ Value type:
+ Definition: Must include "fsl,qman-portal-"
+ May include "fsl,-qman-portal" or "fsl,qman-portal"
+
+- reg
+ Usage: Required
+ Value type:
+ Definition: Two regions. The first is the cache-enabled region of
+ the portal. The second is the cache-inhibited region of
+ the portal
+
+- fsl,liodn
+ Usage: See pamu.txt
+ Value type:
+ Definition: PAMU property used for static LIODN assignment
+
+- fsl,iommu-parent
+ Usage: See pamu.txt
+ Value type:
+ Definition: PAMU property used for dynamic LIODN assignment. This is
+ an optional property. It is a valid configuration for
+ this phandle to be dangling
+
+ For additional details about the PAMU/LIODN binding(s) see pamu.txt
+
+- fsl,qman-channel-id
+ Usage: Required
+ Value type:
+ Definition: The hardware index of the channel. This can also be
+ determined by dividing any of the channel's 8 work queue
+ IDs by 8
+
+In addition to these properties the qman-portals should have sub-nodes to
+represent the HW devices/portals that are connected to the software portal
+described here
+
+The currently support sub-nodes are:
+ * fman@0
+ * fman@1
+ * pme@0
+ * crypto@0
+
+These subnodes should have the following properties:
+
+- fsl,liodn
+ Usage: See pamu.txt
+ Value type:
+ Definition: PAMU property used for static LIODN assignment
+
+- fsl,iommu-parent
+ Usage: See pamu.txt
+ Value type:
+ Definition: PAMU property used for dynamic LIODN assignment
+
+- dev-handle
+ Usage: Required
+ Value type:
+ Definition: The phandle to the particular hardware device that this
+ portal is connected to.
+
+DPAA QMan Pool Channel Nodes
+
+Pool Channels are defined with the following properties.
+
+PROPERTIES
+
+- compatible
+ Usage: Required
+ Value type:
+ Definition: Must include "fsl,qman-pool-channel"
+ May include "fsl,-qman-pool-channel"
+
+- fsl,qman-channel-id
+ Usage: Required
+ Value type:
+ Definition: The hardware index of the channel. This can also be
+ determined by dividing any of the channel's 8 work queue
+ IDs by 8
+
+EXAMPLE
+
+The example below shows a (P4080) BMan portals container/bus node with two
portals
+
+ qman-portals@ff420 {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ compatible = "simple-bus";
+ ranges = <0 0xf 0xf420 0x20>;
+
+ qman-portal@0 {
+ cell-index = <0>;
+ compatible = "fsl,qman-portal-1.2.0", "fsl,qman-portal";
+ reg = <0 0x4000 0x10 0x1000>;
+ interrupts = <104 2 0 0>;
+ fsl,liodn = <1 2>;
+ fsl,qman-channel-id = <0>;
+
+ fman@0 {
+ fsl,liodn = <0x21>;
+ dev-handle = <&fman0>;
+ };
+ fman@1 {
+ fsl,liodn = <0xa1>;
+ dev-handle = <&fman1>;
+ };
+ crypto@0 {
+ fsl,liodn = <0x41 0x66>;
+ dev-handle = <&crypto>;
+ };
+ };
+ qman-portal@4000 {
+ cell-index = <1>;
+ compatible =
[PATCH 1/4] dt/bindings: Introduce the FSL QorIQ DPAA BMan
The Buffer Manager is part of the Data-Path Acceleration Architecture (DPAA).
BMan supports hardware allocation and deallocation of buffers belonging to
pools originally created by software with configurable depletion thresholds.
This binding covers the CCSR space programming model
Signed-off-by: Emil Medve
Change-Id: I3ec479bfb3c91951e96902f091f5d7d2adbef3b2
---
.../devicetree/bindings/powerpc/fsl/bman.txt | 98 ++
1 file changed, 98 insertions(+)
create mode 100644 Documentation/devicetree/bindings/powerpc/fsl/bman.txt
diff --git a/Documentation/devicetree/bindings/powerpc/fsl/bman.txt
b/Documentation/devicetree/bindings/powerpc/fsl/bman.txt
new file mode 100644
index 000..c30bdde
--- /dev/null
+++ b/Documentation/devicetree/bindings/powerpc/fsl/bman.txt
@@ -0,0 +1,98 @@
+QorIQ DPAA Buffer Manager Device Tree Bindings
+
+Copyright (C) 2008 - 2014 Freescale Semiconductor Inc.
+
+CONTENTS
+
+ - BMan Node
+ - BMan Private Memory Node
+ - Example
+
+NOTE: The bindings described in this document are preliminary and subject to
+ change
+
+BMan Node
+
+PROPERTIES
+
+- compatible
+ Usage: Required
+ Value type:
+ Definition: Must include "fsl,bman"
+ May include "fsl,-bman"
+
+- reg
+ Usage: Required
+ Value type:
+ Definition: Registers region within the CCSR address space
+
+- fsl,liodn
+ Usage: See pamu.txt
+ Value type:
+ Definition: PAMU property used for static LIODN assignment
+
+- fsl,iommu-parent
+ Usage: See pamu.txt
+ Value type:
+ Definition: PAMU property used for dynamic LIODN assignment
+
+ For additional details about the PAMU/LIODN binding(s) see pamu.txt
+
+BMan Private Memory Node
+
+BMan requires a contiguous range of physical memory used for the backing store
+for BMan Free Buffer Proxy Records. This memory is reserved/allocated as a node
+under the /reserved-memory node
+
+The BMan FBPR memory node must be named "bman-fbpr"
+
+PROPERTIES
+
+- compatible
+ Usage: required
+ Value type:
+ Definition: Must inclide "fsl,bman-fbpr"
+
+The following constraints are relevant to the FBPR private memory:
+ - The size must be 2^(size + 1), with size = 11..33. That is 4 KiB to
+ 16 GiB
+ - The alignment must be a muliptle of the memory size
+
+The size of the FBPR must be chosen by observing the hardware features
configured
+via the RCW and that are relevant to a specific board (e.g. number of MAC(s)
+pinned-out, number of offline/host command FMan ports, etc.). The size
configured
+in the DT must reflect the hardware capabilities and not the specific needs of
an
+application
+
+If the memory reserved in the device tree proves to be larger then the needs of
+the application a BMan driver may provide a method to release the extra memory
+back to the OS
+
+For additional details about reserved memory regions see reserved-memory.txt
+
+EXAMPLE
+
+The example below shows a BMan FBPR dynamic allocation memory node
+
+ reserved-memory {
+ #address-cells = <2>;
+ #size-cells = <2>;
+ ranges;
+
+ bman-fbpr {
+ compatible = "fsl,bman-fbpr";
+ alloc-ranges = <0 0 0xf 0x>;
+ size = <0 0x100>;
+ alignment = <0 0x100>;
+ };
+
+ };
+
+The example below shows a (P4080) BMan CCSR-space node
+
+ bman@31a000 {
+ compatible = "fsl,bman";
+ reg = <0x31a000 0x1000>;
+ interrupts = <16 2 1 2>;
+ fsl,liodn = <0x17>;
+ };
--
2.1.2
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 2/4] dt/bindings: Introduce the FSL QorIQ DPAA BMan portal(s)
On Wed, Oct 22, 2014 at 03:09:30PM +0100, Emil Medve wrote:
> Portals are used by software running on processor cores, accelerators and
> network interfaces to communicate with the BMan
What exactly is a portal?
Is it a region of shared memory? A device?
I only received emails 2 and 3 of this series, so I'm lacking the
context necessary to understand the bindings.
>
> Signed-off-by: Emil Medve
> Change-Id: I6d245ffc14ba3d0e91d403ac7c3b91b75a9e6a95
> ---
> .../bindings/powerpc/fsl/bman-portals.txt | 50
> ++
> 1 file changed, 50 insertions(+)
> create mode 100644
> Documentation/devicetree/bindings/powerpc/fsl/bman-portals.txt
>
> diff --git a/Documentation/devicetree/bindings/powerpc/fsl/bman-portals.txt
> b/Documentation/devicetree/bindings/powerpc/fsl/bman-portals.txt
> new file mode 100644
> index 000..40e607e
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/powerpc/fsl/bman-portals.txt
> @@ -0,0 +1,50 @@
> +QorIQ DPAA Buffer Manager Portals Device Tree Binding
> +
> +Copyright (C) 2008 - 2014 Freescale Semiconductor Inc.
> +
> +CONTENTS
> +
> + - BMan Portal
> + - Example
> +
> +NOTE:The bindings described in this document are preliminary and
> subject to
> + change
While we've tried that elsewhere, unstable DT bindings have been shown
to be a major source of pain. I'd feel rather uncomfortable accepting a
binding that we already believe to be insufficient to describe the
hardware.
What do you expect to change?
> +
> +BMan Portal Node
> +
> +PROPERTIES
> +
> +- compatible
> + Usage: Required
> + Value type:
> + Definition: Must include "fsl,bman-portal-"
> + May include "fsl,-bman-portal" or "fsl,bman-portal"
> +
> +- reg
> + Usage: Required
> + Value type:
> + Definition: Two regions. The first is the cache-enabled region of
> + the portal. The second is the cache-inhibited region of
> + the portal
> +
> +EXAMPLE
> +
> +The example below shows a (P4080) BMan portals container/bus node with two
> portals
Is there any particular reason to place these under a simple-bus?
> +
> + bman-portals@ff400 {
> + #address-cells = <1>;
> + #size-cells = <1>;
> + compatible = "simple-bus";
> + ranges = <0 0xf 0xf400 0x20>;
> +
> + bman-portal@0 {
> + compatible = "fsl,bman-portal-1.0.0", "fsl,bman-portal";
> + reg = <0x0 0x4000 0x10 0x1000>;
It would be easier to read is each entry had its own set of brackets.
Initially this looked to me like a single 64-bit address/size pair.
> + interrupts = <105 2 0 0>;
> + };
Given the description above, surely you need to know what the portal is
used for? Or is that queried from the portal?
Thanks,
Mark.
> + bman-portal@4000 {
> + compatible = "fsl,bman-portal-1.0.0", "fsl,bman-portal";
> + reg = <0x4000 0x4000 0x101000 0x1000>;
> + interrupts = <107 2 0 0>;
> + };
> + };
> --
> 2.1.2
>
>
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] ucc_geth: invalid rx checksum error values
Hi,
The value in QE UCC ethernet interfaces shows random values:
# ethtool -S eth0
NIC statistics:
...
rx-ip-checksum-errors: 3933892214
The problem is located in a mismatch between the rx_fw_stat_gstrings fields
- used in ucc_geth_ethtool - and the ucc_geth_rx_firmware_statistics_pram
fields - used in ucc_geth.
Although the QE UCC Ethernet Controller includes the Rx checksum error
counter in the 'Rx firmware counters', the related field is missing from the
ucc_geth driver.
After adding the RxChecksumError field in
ucc_geth_rx_firmware_statistics_pram structure the counter works fine.
Signed-off-by: Ioannis Kokkoris
diff -Nru a/drivers/net/ethernet/freescale/ucc_geth.h
b/drivers/net/ethernet/freescale/ucc_geth.h
--- a/drivers/net/ethernet/freescale/ucc_geth.h 2014-10-22
15:19:16.0 +0300
+++ b/drivers/net/ethernet/freescale/ucc_geth.h 2014-10-22
15:24:39.0 +0300
@@ -541,6 +541,8 @@
replaced */
u32 insertvlan; /* total frames that had their VLAN tag
inserted */
+ u32 checksumerr;/* total frames that have IP Checksum Error
+*/
} __packed;
struct ucc_geth_rx_interrupt_coalescing_entry {
Best Regards,
Ioannis
smime.p7s
Description: S/MIME cryptographic signature
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] powernv: Use _GLOBAL_TOC for opal wrappers
Hi Michael, >> Currently, we can't call opal wrappers from modules when using the LE >> ABIv2, which requires a TOC init. > > What happens if we try? Build failure or run time bug? We'll get an arbitrary memory dereference (two, actually) in the opal wrappers, when we try to load the opal entry point & return address from the TOC, as r2 may not point to a valid TOC for the kernel. >> This change uses the _GLOBAL_TOC() macro (rather than _GLOBAL) for the >> opal wrappers, so that we can do non-local calls to them. > > Are we doing that now, or we would like to? We'd like to; although we do EXPORT_SYMBOL on another wrapper (opal_invalid_call()) already. From the call name though, I figure it's not in any mission-critical usage :) Cheers, Jeremy ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v3] rtc/tpo: Driver to support rtc and wakeup on PowerNV platform
On 10/14/2014 02:08 PM, Neelesh Gupta wrote: The patch implements the OPAL rtc driver that binds with the rtc driver subsystem. The driver uses the platform device infrastructure to probe the rtc device and register it to rtc class framework. The 'wakeup' is supported depending upon the property 'has-tpo' present in the OF node. It provides a way to load the generic rtc driver in in the absence of an OPAL driver. The patch also moves the existing OPAL rtc get/set time interfaces to the new driver and exposes the necessary OPAL calls using EXPORT_SYMBOL_GPL. Hi Alessandro, Awaiting Ack from your side, so that we can take this through the powerpc tree. Regards, Neelesh Test results: - Host: [root@tul169p1 ~]# ls -l /sys/class/rtc/ total 0 lrwxrwxrwx 1 root root 0 Oct 14 03:07 rtc0 -> ../../devices/opal-rtc/rtc/rtc0 [root@tul169p1 ~]# cat /sys/devices/opal-rtc/rtc/rtc0/time 08:10:07 [root@tul169p1 ~]# echo `date '+%s' -d '+ 2 minutes'` > /sys/class/rtc/rtc0/wakealarm [root@tul169p1 ~]# cat /sys/class/rtc/rtc0/wakealarm 1413274345 [root@tul169p1 ~]# FSP: $ smgr mfgState standby $ rtim timeofday System time is valid: 2014/10/14 08:12:04.225115 $ smgr mfgState ipling $ Signed-off-by: Neelesh Gupta --- Changes in v3 = - Rebased to the latest tree. Changes in v2 = - Added Documentation/devicetree/bindings/rtc/rtc-opal.txt - Explicitly turn off RTC_UIE mode by setting 'rtc->uie_unsupported' Documentation/devicetree/bindings/rtc/rtc-opal.txt | 16 + arch/powerpc/include/asm/opal.h|7 - arch/powerpc/kernel/time.c |1 arch/powerpc/platforms/powernv/opal-async.c|3 arch/powerpc/platforms/powernv/opal-rtc.c | 65 + arch/powerpc/platforms/powernv/opal-wrappers.S |2 arch/powerpc/platforms/powernv/opal.c |6 arch/powerpc/platforms/powernv/setup.c |2 drivers/rtc/Kconfig| 11 + drivers/rtc/Makefile |1 drivers/rtc/rtc-opal.c | 261 11 files changed, 325 insertions(+), 50 deletions(-) create mode 100644 Documentation/devicetree/bindings/rtc/rtc-opal.txt create mode 100644 drivers/rtc/rtc-opal.c ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] powerpc: Convert power off logic to pm_power_off
On 22.10.14 06:37, Michael Ellerman wrote: > The generic Linux framework to power off the machine is a function pointer > called pm_power_off. The trick about this pointer is that device drivers can > potentially implement it rather than board files. > > Today on powerpc we set pm_power_off to invoke our generic full machine power > off logic which then calls ppc_md.power_off to invoke machine specific power > off. > > However, when we want to add a power off GPIO via the "gpio-poweroff" driver, > this card house falls apart. That driver only registers itself if pm_power_off > is NULL to ensure it doesn't override board specific logic. However, since we > always set pm_power_off to the generic power off logic (which will just not > power off the machine if no ppc_md.power_off call is implemented), we can't > implement power off via the generic GPIO power off driver. > > To fix this up, let's get rid of the ppc_md.power_off logic and just always > use > pm_power_off as was intended. Then individual drivers such as the GPIO power > off > driver can implement power off logic via that function pointer. > > With this patch set applied and a few patches on top of QEMU that implement a > power off GPIO on the virt e500 machine, I can successfully turn off my > virtual > machine after halt. > > Signed-off-by: Alexander Graf > [mpe: Squash into one patch and update changelog based on cover letter] > Signed-off-by: Michael Ellerman > --- > arch/powerpc/include/asm/machdep.h | 1 - > arch/powerpc/kernel/setup-common.c | 6 +-- > arch/powerpc/platforms/44x/ppc476.c | 2 +- > arch/powerpc/platforms/52xx/efika.c | 3 +- > arch/powerpc/platforms/83xx/mcu_mpc8349emitx.c | 8 ++-- > arch/powerpc/platforms/85xx/corenet_generic.c| 2 +- > arch/powerpc/platforms/85xx/sgy_cts1000.c| 4 +- > arch/powerpc/platforms/cell/celleb_setup.c | 4 +- > arch/powerpc/platforms/cell/qpace_setup.c| 2 +- > arch/powerpc/platforms/cell/setup.c | 2 +- > arch/powerpc/platforms/chrp/setup.c | 3 +- > arch/powerpc/platforms/embedded6xx/gamecube.c| 3 +- > arch/powerpc/platforms/embedded6xx/linkstation.c | 4 +- > arch/powerpc/platforms/embedded6xx/wii.c | 3 +- > arch/powerpc/platforms/maple/setup.c | 4 +- > arch/powerpc/platforms/powermac/setup.c | 3 +- > arch/powerpc/platforms/powernv/setup.c | 4 +- > arch/powerpc/platforms/ps3/setup.c | 2 +- > arch/powerpc/platforms/pseries/setup.c | 59 > > arch/powerpc/sysdev/fsl_soc.c| 2 +- > arch/powerpc/xmon/xmon.c | 3 +- > 21 files changed, 66 insertions(+), 58 deletions(-) > > > Hi guys, how does this look? > > If it's OK I'll put it in a topic branch for Guenter. Looks good to me. Thanks for doing the cleanup :). Alex ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] drivers: depend on instead of select BACKLIGHT_CLASS_DEVICE and ACPI_VIDEO
On 18/10/14 00:13, Jani Nikula wrote: > Documentation/kbuild/kconfig-language.txt warns to use select with care, > and in general use select only for non-visible symbols and for symbols > with no dependencies, because select will force a symbol to a value > without visiting the dependencies. > > Select has become particularly problematic, interdependently, with the > BACKLIGHT_CLASS_DEVICE and ACPI_VIDEO configs. For example: > > scripts/kconfig/conf --randconfig Kconfig > KCONFIG_SEED=0x48312B00 > warning: (DRM_RADEON && DRM_NOUVEAU && DRM_I915 && DRM_GMA500 && > DRM_SHMOBILE && DRM_TILCDC && FB_BACKLIGHT && FB_MX3 && USB_APPLEDISPLAY > && FB_OLPC_DCON && ASUS_LAPTOP && SONY_LAPTOP && THINKPAD_ACPI && > EEEPC_LAPTOP && ACPI_CMPC && SAMSUNG_Q10) selects BACKLIGHT_CLASS_DEVICE > which has unmet direct dependencies (HAS_IOMEM && BACKLIGHT_LCD_SUPPORT) > warning: (DRM_RADEON && DRM_NOUVEAU && DRM_I915 && DRM_GMA500 && > DRM_SHMOBILE && DRM_TILCDC && FB_BACKLIGHT && FB_MX3 && USB_APPLEDISPLAY > && FB_OLPC_DCON && ASUS_LAPTOP && SONY_LAPTOP && THINKPAD_ACPI && > EEEPC_LAPTOP && ACPI_CMPC && SAMSUNG_Q10) selects BACKLIGHT_CLASS_DEVICE > which has unmet direct dependencies (HAS_IOMEM && BACKLIGHT_LCD_SUPPORT) > > With tristates it's possible to end up selecting FOO=y depending on > BAR=m in the config, which gets discovered at build time, not config > time, like reported in the thread referenced below. > > Do the following to fix the dependencies: > > * Depend on instead of select BACKLIGHT_CLASS_DEVICE everywhere. Drop > select BACKLIGHT_LCD_SUPPORT in such cases, as it's a dependency of > BACKLIGHT_CLASS_DEVICE. > > * Remove config FB_BACKLIGHT altogether, and replace it with a > dependency on BACKLIGHT_CLASS_DEVICE. All configs selecting > FB_BACKLIGHT select or depend on FB anyway, so we can simplify. > > * Depend on (ACPI && ACPI_VIDEO) || ACPI=n in several places instead of > selecting ACPI_VIDEO and a number of its dependencies if ACPI is > enabled. This is tied to backlight, as ACPI_VIDEO depends on > BACKLIGHT_CLASS_DEVICE. > > * Replace a couple of select INPUT/VT with depends as it seemed to be > necessary. While doing 'depends on' instead of 'select' is an "easy" fix for this, I do dislike it quite a bit. It's a major pain to go around the kernel config, trying to find all the dependencies that a particular driver wants. If I need fb-foobar, I should just be able to enable it, instead of first searching and selecting its minor dependencies individually. So, not a NACK, but a "isn't there an another way to fix this?". Looking at backlight... BACKLIGHT_LCD_SUPPORT seems to be a "meta" option, it only enables a Kconfig submenu. So I think we could just remove the whole BACKLIGHT_LCD_SUPPORT option. But if we do that, all the items in drivers/video/backlight/Kconfig with default 'y' or 'm' would get enabled by default, so I think we should remove the 'default's from that file. That makes sense in any case, as I don't see why "HP Jornada 700 series LCD Driver" should be "default y". BACKLIGHT_CLASS_DEVICE doesn't depend on anything except BACKLIGHT_LCD_SUPPORT, so after removing BACKLIGHT_LCD_SUPPORT it should be safe to 'select' BACKLIGHT_CLASS_DEVICE. BACKLIGHT_CLASS_DEVICE could be made a hidden option, and the drivers in drivers/video/backlight/Kconfig which are under BACKLIGHT_CLASS_DEVICE could be made to select BACKLIGHT_CLASS_DEVICE instead. That doesn't exactly fix anything, but I think it makes sense as BACKLIGHT_CLASS_DEVICE is something that's selected from all around the kernel, so it should be a selectable "library" instead of a Kconfig menu option. I didn't look at the ACPI_VIDEO side, so no idea how messy that is. Tomi signature.asc Description: OpenPGP digital signature ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] powerpc: Enable NUMA balancing in pseries[_le]_defconfig
Michael Neuling writes: > This enables NUMA balancing in pseries[_le]_defconfig. > > NUMA balancing can do some nasty things with the low level mm code and > has been causing some issues with the cxl driver. What sort of issues ? -aneesh ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [RFC 07/11] powerpc: kvm: the stopper func to cease secondary hwthread
Hi Liu,
On 10/17/2014 12:59 AM, kernelf...@gmail.com wrote:
> To enter guest, primary hwtherad schedules the stopper func on
> secondary threads and force them into NAP mode.
> When exit to host,secondary threads hardcode to restore the stack,
> then switch back to the stopper func, i.e host.
>
> Signed-off-by: Liu Ping Fan
> ---
> arch/powerpc/kvm/book3s_hv.c| 15 +++
> arch/powerpc/kvm/book3s_hv_rmhandlers.S | 34
> +
> 2 files changed, 49 insertions(+)
>
> diff --git a/arch/powerpc/kvm/book3s_hv.c b/arch/powerpc/kvm/book3s_hv.c
> index ba258c8..4348abd 100644
> --- a/arch/powerpc/kvm/book3s_hv.c
> +++ b/arch/powerpc/kvm/book3s_hv.c
> @@ -1486,6 +1486,21 @@ static void kvmppc_remove_runnable(struct kvmppc_vcore
> *vc,
> list_del(&vcpu->arch.run_list);
> }
>
> +#ifdef KVMPPC_ENABLE_SECONDARY
> +
> +extern void kvmppc_secondary_stopper_enter();
> +
> +static int kvmppc_secondary_stopper(void *data)
> +{
> + int cpu =smp_processor_id();
> + struct paca_struct *lpaca = get_paca();
> + BUG_ON(!(cpu%thread_per_core));
> +
> + kvmppc_secondary_stopper_enter();
> +}
> +
> +#endif
> +
> static int kvmppc_grab_hwthread(int cpu)
> {
> struct paca_struct *tpaca;
> diff --git a/arch/powerpc/kvm/book3s_hv_rmhandlers.S
> b/arch/powerpc/kvm/book3s_hv_rmhandlers.S
> index d5594b0..254038b 100644
> --- a/arch/powerpc/kvm/book3s_hv_rmhandlers.S
> +++ b/arch/powerpc/kvm/book3s_hv_rmhandlers.S
> @@ -349,7 +349,41 @@ kvm_do_nap:
>
> #ifdef PPCKVM_ENABLE_SECONDARY
> kvm_secondary_exit_trampoline:
> +
> + /* all register is free to use, later kvmppc_secondary_stopper_exit set
> up them*/
> + //loop-wait for the primary to signal that host env is ready
> +
> + LOAD_REG_ADDR(r5, kvmppc_secondary_stopper_exit)
> + /* fixme, load msr from lpaca stack */
> + li r6, MSR_IR | MSR_DR
> + mtsrr0 r5
> + mtsrr1 r6
> + RFI
> +
> +_GLOBAL_TOC(kvmppc_secondary_stopper_enter)
> + mflrr0
> + std r0, PPC_LR_STKOFF(r1)
> + stdur1, -112(r1)
> +
> + /* fixme: store other register such as msr */
> +
> + /* prevent us to enter kernel */
> + li r0, 1
> + stb r0, HSTATE_HWTHREAD_REQ(r13)
> + /* tell the primary that we are ready */
> +li r0,KVM_HWTHREAD_IN_KERNEL
> +stb r0,HSTATE_HWTHREAD_STATE(r13)
> + nap
> b .
This does not look right. Let me explain.
We can get hypervisor decrementer interrupts on the secondary threads
since they are online. And we would ideally want to handle them. They
could be scheduler tick interrupts or some timer queued on that thread
could have fired.
If it is a scheduler tick, we would want to exit to host to schedule the
next task if the timeslice of the vcpu running on the secondary thread
is over.
To the best of my understanding, this is what I can tell happens when we
get a hypervisor decrementer interrupt in the guest. We call all threads
in the core to exit to the kernel. The secondaries now return to the
code in idle_power7.S where the wakeup from idle path takes effect. Then
we do an rfid which lands after the nap code above. And we spin.
From your above code you seem to be indicating that you do not want the
secondary threads to exit to the kernel once they are made to run guest
for the first time. Is this right? Or am I missing something ?
Moreover the changelog in [patch 10/11] says that you cease the
scheduler. This pushes me to think that you do not expect the scheduler
to run on the secondary threads ever again after you have launched the
guest. This does not look right to me.
Regards
Preeti U Murthy
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] net: fs_enet: set back promiscuity mode after restart
After interface restart (eg: after link disconnection/reconnection), the bridge function doesn't work anymore. This is due to the promiscuous mode being cleared by the restart. The mac-fcc already includes code to set the promiscuous mode back during the restart. This patch adds the same handling to mac-fec and mac-scc. Tested with bridge function on MPC885 with FEC. Reported-by: Germain Montoies Signed-off-by: Christophe Leroy --- drivers/net/ethernet/freescale/fs_enet/mac-fec.c | 3 +++ drivers/net/ethernet/freescale/fs_enet/mac-scc.c | 3 +++ 2 files changed, 6 insertions(+) diff --git a/drivers/net/ethernet/freescale/fs_enet/mac-fec.c b/drivers/net/ethernet/freescale/fs_enet/mac-fec.c index 3d4e08b..b34214e 100644 --- a/drivers/net/ethernet/freescale/fs_enet/mac-fec.c +++ b/drivers/net/ethernet/freescale/fs_enet/mac-fec.c @@ -341,6 +341,9 @@ static void restart(struct net_device *dev) FC(fecp, x_cntrl, FEC_TCNTRL_FDEN); /* FD disable */ } + /* Restore multicast and promiscuous settings */ + set_multicast_list(dev); + /* * Enable interrupts we wish to service. */ diff --git a/drivers/net/ethernet/freescale/fs_enet/mac-scc.c b/drivers/net/ethernet/freescale/fs_enet/mac-scc.c index f30411f..7a184e8 100644 --- a/drivers/net/ethernet/freescale/fs_enet/mac-scc.c +++ b/drivers/net/ethernet/freescale/fs_enet/mac-scc.c @@ -355,6 +355,9 @@ static void restart(struct net_device *dev) if (fep->phydev->duplex) S16(sccp, scc_psmr, SCC_PSMR_LPB | SCC_PSMR_FDE); + /* Restore multicast and promiscuous settings */ + set_multicast_list(dev); + S32(sccp, scc_gsmrl, SCC_GSMRL_ENR | SCC_GSMRL_ENT); } -- 2.1.0 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
