Re: [PATCH] powerpc: book3s: kvm: Use the saved dsisr and dar values
Alexander Graf writes: > On 11.11.2013, at 15:02, Aneesh Kumar K.V > wrote: > >> From: "Aneesh Kumar K.V" >> >> Don't try to compute these values. >> >> Signed-off-by: Aneesh Kumar K.V >> --- >> >> NOTE: I am not sure why we were originally computing dsisr and dar. So may be >> we need a variant of this patch. But with this and the additional patch >> "powerpc: book3s: PR: Enable Little Endian PR guest" I am able to get a >> Little Endian >> PR guest to boot. > > It's quite easy to find out - git blame tells you all the history and points > you to commit ca7f4203b. > > commit ca7f4203b9b66e12d0d9968ff7dfe781f3a9695a > Author: Alexander Graf > Date: Wed Mar 24 21:48:28 2010 +0100 > > KVM: PPC: Implement alignment interrupt > > Mac OS X has some applications - namely the Finder - that require > alignment > interrupts to work properly. So we need to implement them. > > But the spec for 970 and 750 also looks different. While 750 requires the > DSISR and DAR fields to reflect some instruction bits (DSISR) and the > fault > address (DAR), the 970 declares this as an optional feature. So we need > to reconstruct DSISR and DAR manually. > > Signed-off-by: Alexander Graf > Signed-off-by: Avi Kivity > > Read this as "on 970, alignment interrupts don't give us DSISR and DAR of the > faulting instruction" as otherwise I wouldn't have implemented it. > > So this is clearly a nack on this patch :). I can possibly do a if (cpu_has_feature(CPU_FTR_ARCH_201)). But do we need to do that ? According to Paul we should always find DAR. -aneesh ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: commit e38c0a1f breaks powerpc boards with uli1575 chip
> Reverting would break Tegra PCIe, but you should not have to change the > DT either. So we need a solution. > > Is this something like this sufficient to fix it? > > diff --git a/drivers/of/address.c b/drivers/of/address.c > index 4b9317b..378aebd 100644 > --- a/drivers/of/address.c > +++ b/drivers/of/address.c > @@ -74,7 +74,7 @@ static u64 of_bus_default_map(__be32 *addr, const > __be32 *range, > * mapping doesn't specify a physical address. Rather, the > address * specifies an identifier that must match exactly. > */ > - if (na > 2 && memcmp(range, addr, na * 4) != 0) > + if (na > 2 && memcmp(range, addr, (na - 2) * 4) != 0) > return OF_BAD_ADDR; > > if (da < cp || da >= (cp + s)) No, this does not help. I've dumped the actual content of 'range' and 'addr' at the failure point (i.e. ar point that returns error with e38c0a1f but passes without e38c0a1f ): OF: default map, cp=0, s=1, da=70 range: 01 00 00 00 00 00 00 00 00 00 00 00 addr: 00 00 00 00 00 00 00 00 00 00 00 70 Nikita ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [RFC][PATCH v1] ASoC: fsl_ssi: Add DAI master mode support for SSI on i.MX series
On Wed, Dec 18, 2013 at 06:59:52PM +, Mark Brown wrote:
> On Thu, Dec 12, 2013 at 06:44:45PM +0800, Nicolin Chen wrote:
>
> > +/**
> > + * fsl_ssi_set_dai_tdm_slot - set TDM slot number
> > + *
> > + * Note: This function can be only called when using SSI as DAI master
> > + */
> > +static int fsl_ssi_set_dai_tdm_slot(struct snd_soc_dai *cpu_dai, u32
> > tx_mask,
> > + u32 rx_mask, int slots, int slot_width)
> > +{
> > + struct fsl_ssi_private *ssi_private = snd_soc_dai_get_drvdata(cpu_dai);
> > + struct ccsr_ssi __iomem *ssi = ssi_private->ssi;
> > + u32 val;
>
> I'm a bit concernred about what this is for and why it's required - is
> it something that machine drivers have to call and if it is shouldn't
> the driver be defaulting to a sensible configuration?
SSI can control how many slots to generate and which slot to send data. Yes,
the normal case, which should be defaulting to normal two slots I2S case, can
be configured by SSI driver itself as you mentioned. I'll add it to startup().
Then only those machine drivers using multiple slots (>2) need to call it.
Thank you for the comments.
Nicolin Chen
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] powerpc: book3s: kvm: Use the saved dsisr and dar values
On Wed, Dec 18, 2013 at 10:44:08PM +0100, Alexander Graf wrote: > > On 11.11.2013, at 15:02, Aneesh Kumar K.V > wrote: > > > From: "Aneesh Kumar K.V" > > > > Don't try to compute these values. > > > > Signed-off-by: Aneesh Kumar K.V > > --- > > > > NOTE: I am not sure why we were originally computing dsisr and dar. So may > > be > > we need a variant of this patch. But with this and the additional patch > > "powerpc: book3s: PR: Enable Little Endian PR guest" I am able to get a > > Little Endian > > PR guest to boot. > > It's quite easy to find out - git blame tells you all the history and points > you to commit ca7f4203b. > > commit ca7f4203b9b66e12d0d9968ff7dfe781f3a9695a > Author: Alexander Graf > Date: Wed Mar 24 21:48:28 2010 +0100 > > KVM: PPC: Implement alignment interrupt > > Mac OS X has some applications - namely the Finder - that require > alignment > interrupts to work properly. So we need to implement them. > > But the spec for 970 and 750 also looks different. While 750 requires the > DSISR and DAR fields to reflect some instruction bits (DSISR) and the > fault > address (DAR), the 970 declares this as an optional feature. So we need > to reconstruct DSISR and DAR manually. > > Signed-off-by: Alexander Graf > Signed-off-by: Avi Kivity > > Read this as "on 970, alignment interrupts don't give us DSISR and DAR of the > faulting instruction" as otherwise I wouldn't have implemented it. Although it's optional, all IBM POWER cpus, and as far as I know all PowerPC cpus, set DAR on an alignment interrupt to the effective address being accessed. You have a valid point regarding DSISR, but it would be nice to skip the computations where either the host CPU provides the bits, or the virtual CPU doesn't. Paul. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [2/2,v8] powerpc/fsl-booke: Add initial T104x_QDS board support
On Thu, Oct 03, 2013 at 09:14:49AM +0530, Prabhakar Kushwaha wrote:
> diff --git a/arch/powerpc/boot/dts/t104xqds.dtsi
> b/arch/powerpc/boot/dts/t104xqds.dtsi
> new file mode 100644
> index 000..5a518b3
> --- /dev/null
> +++ b/arch/powerpc/boot/dts/t104xqds.dtsi
[snip]
> +/ {
> + model = "fsl,T1040QDS";
> + compatible = "fsl,T1040QDS";
Remove model/compatible; they're supplied by the includer of this file.
> + nand@2,0 {
> + #address-cells = <1>;
> + #size-cells = <1>;
> + compatible = "fsl,ifc-nand";
> + reg = <0x2 0x0 0x1>;
> +
> + partition@0 {
> + /* This location must not be altered */
> + /* 1MB for u-boot Bootloader Image */
> + reg = <0x0 0x0010>;
> + label = "NAND U-Boot Image";
> + read-only;
> + };
> +
> + partition@10 {
> + /* 1MB for DTB Image */
> + reg = <0x0010 0x0010>;
> + label = "NAND DTB Image";
> + };
> +
> + partition@20 {
> + /* 10MB for Linux Kernel Image */
> + reg = <0x0020 0x00A0>;
> + label = "NAND Linux Kernel Image";
> + };
> +
> + partition@C0 {
> + /* 500MB for Root file System Image */
> + reg = <0x00c0 0x1F40>;
> + label = "NAND RFS Image";
> + };
> + };
I'd really like to see us stop putting partition info in the dts files.
Alternatives are using the mtdparts command line option, or having U-Boot
use the mtdparts environment variable to add partition info to the dtb
(there's already code for this).
> + board-control@3,0 {
> + #address-cells = <1>;
> + #size-cells = <1>;
> + compatible = "fsl,tetra-fpga", "fsl,fpga-qixis";
> + reg = <3 0 0x300>;
> + };
Could you explain the relationship between "tetra" and "qixis"?
-Scott
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [v3, 3/7] powerpc: enable the relocatable support for the fsl booke 32bit kernel
On Wed, Aug 07, 2013 at 09:18:31AM +0800, Kevin Hao wrote: > This is based on the codes in the head_44x.S. The difference is that > the init tlb size we used is 64M. With this patch we can only load the > kernel at address between memstart_addr ~ memstart_addr + 64M. We will > fix this restriction in the following patches. Which following patch fixes the restriction? With all seven patches applied, I was still only successful booting within 64M of memstart_addr. -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v1 0/4] powerpc/512x: update COMMON_CLK support for MPC5125
Quoting Gerhard Sittig (2013-12-10 05:11:33)
> this series improves the previously introduced common clock support for
> MPC512x such that SoC variants 5123 and 5125 get addressed appropriately
> (MPC5125 turned out to be rather different from MPC5121 than I perceived
> before -- there is much more than "just two FECs and no MBX")
>
> thus this series depends on "add COMMON_CLK support for PowerPC MPC512x"
> (v6 sent in <1385851897-23475-1-git-send-email-...@denx.de>, applicable
> on top of v3.13-rc1 or later, currently applied to mpc5xxx -next,
> available at git://git.denx.de/linux-2.6-agust.git next)
>
> this series does not address the issue of outdated or missing device
> tree binding documentation for MPC512x peripherals -- that's the scope
> of a pending separate series
For the three clock patches:
Acked-by: Mike Turquette
>
> v1 initial submission (2013-12-10)
> - enforce an even divider value for SDHC (on all MPC512x variants)
> - tell 5121/5123/5125 SoC variants apart and only register the
> appropriate set of clock items (i.e. refuse to access unused and
> reserved bits, and support those components which are only found on
> MPC5125)
> - update the MPC5125 "tower" board DTS (although the code still works in
> the absence of device tree clock specs)
>
> the series passes 'checkpatch.pl --strict' except for two warnings which
> cannot get fixed because dictates the data type
> and "fixing" the warning would break the build
>
> WARNING: static const char * array should probably be static const char *
> const
> #256: FILE: arch/powerpc/platforms/512x/clock-commonclk.c:500:
> +static const char *parent_names_mux0_spdif[] = {
>
> WARNING: static const char * array should probably be static const char *
> const
> #260: FILE: arch/powerpc/platforms/512x/clock-commonclk.c:504:
> +static const char *parent_names_mux0_canin[] = {
>
> total: 0 errors, 2 warnings, 0 checks, 495 lines checked
>
> the series was build-tested, and was run-tested on the MPC5121 ADS board
>
> Matteo, can you verify the crystal frequency in the DTS update, please?
> And that v3.13-rc kernels with v6 of the COMMON_CLK introduction for
> MPC512x plus this series for MPC5125 operate your peripherals, both with
> an updated device tree as well as with a former device tree that lacks
> clock specs? Thank you! Setting CONFIG_COMMON_CLK_DEBUG=y in your
> .config and eyeballing /sys/kernel/debug/clk/clk_summary will help you.
>
> Gerhard Sittig (4):
> powerpc/512x: clk: minor comment updates
> powerpc/512x: clk: enforce even SDHC divider values
> powerpc/512x: clk: support MPC5121/5123/5125 SoC variants
> powerpc/512x: dts: add MPC5125 clock specs
>
> arch/powerpc/boot/dts/mpc5125twr.dts | 53 +++-
> arch/powerpc/include/asm/mpc5121.h|7 +-
> arch/powerpc/platforms/512x/clock-commonclk.c | 369
> +
> include/dt-bindings/clock/mpc512x-clock.h |9 +-
> 4 files changed, 386 insertions(+), 52 deletions(-)
>
> --
> 1.7.10.4
>
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH v2 00/10] Kconfig: cleanup SERIO_I8042 dependencies
> This is v2 of the patch series. Changes from version 1: > > o Added acks. arm, ia64, and sh are only ones without acks. ia64 bits look OK Acked-by: Tony Luck ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] powerpc: book3s: kvm: Use the saved dsisr and dar values
On 11.11.2013, at 15:02, Aneesh Kumar K.V wrote: > From: "Aneesh Kumar K.V" > > Don't try to compute these values. > > Signed-off-by: Aneesh Kumar K.V > --- > > NOTE: I am not sure why we were originally computing dsisr and dar. So may be > we need a variant of this patch. But with this and the additional patch > "powerpc: book3s: PR: Enable Little Endian PR guest" I am able to get a > Little Endian > PR guest to boot. It's quite easy to find out - git blame tells you all the history and points you to commit ca7f4203b. commit ca7f4203b9b66e12d0d9968ff7dfe781f3a9695a Author: Alexander Graf Date: Wed Mar 24 21:48:28 2010 +0100 KVM: PPC: Implement alignment interrupt Mac OS X has some applications - namely the Finder - that require alignment interrupts to work properly. So we need to implement them. But the spec for 970 and 750 also looks different. While 750 requires the DSISR and DAR fields to reflect some instruction bits (DSISR) and the fault address (DAR), the 970 declares this as an optional feature. So we need to reconstruct DSISR and DAR manually. Signed-off-by: Alexander Graf Signed-off-by: Avi Kivity Read this as "on 970, alignment interrupts don't give us DSISR and DAR of the faulting instruction" as otherwise I wouldn't have implemented it. So this is clearly a nack on this patch :). Alex ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v1 1/1] powerpc/512x: dts: remove misplaced IRQ spec from 'soc' node (5125)
On Tue, 10 Dec 2013 10:51:08 +0100 Gerhard Sittig wrote: > the 'soc' node in the MPC5125 "tower" board .dts has an '#interrupt-cells' > property although this node is not an interrupt controller > > remove this erroneously placed property because starting with v3.13-rc1 > lookup and resolution of 'interrupts' specs for peripherals gets misled > (tries to use the 'soc' as the interrupt parent which fails), emits > 'no irq domain found' WARN() messages and breaks the boot process > > [ best viewed with 'git diff -U5' to have DT node names in the context ] > > Cc: Anatolij Gustschin > Cc: linuxppc-dev@lists.ozlabs.org > Cc: devicet...@vger.kernel.org > Signed-off-by: Gerhard Sittig > > --- > > note that this is not a resend of the previous MPC5121 fix, but instead > is a fix for MPC5125 along the same lines of the MPC5121 fix > --- > arch/powerpc/boot/dts/mpc5125twr.dts |1 - > 1 file changed, 1 deletion(-) Applied. Thanks! Anatolij ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v1 0/4] powerpc/512x: update COMMON_CLK support for MPC5125
On Tue, 10 Dec 2013 14:11:33 +0100 Gerhard Sittig wrote: ... > Gerhard Sittig (4): > powerpc/512x: clk: minor comment updates > powerpc/512x: clk: enforce even SDHC divider values > powerpc/512x: clk: support MPC5121/5123/5125 SoC variants > powerpc/512x: dts: add MPC5125 clock specs > > arch/powerpc/boot/dts/mpc5125twr.dts | 53 +++- > arch/powerpc/include/asm/mpc5121.h|7 +- > arch/powerpc/platforms/512x/clock-commonclk.c | 369 > + > include/dt-bindings/clock/mpc512x-clock.h |9 +- > 4 files changed, 386 insertions(+), 52 deletions(-) Applied this series to mpc5xxx next. Thanks! Anatolij ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] rapidio: add modular rapidio core build into powerpc and mips branches
Allow modular build option for RapidIO subsystem core in MIPS and PowerPC architectural branches. At this moment modular RapidIO subsystem build is enabled only for platforms that use PCI/PCIe based RapidIO controllers (e.g. Tsi721). Signed-off-by: Alexandre Bounine Cc: Matt Porter Cc: Jean Delvare Cc: Ralf Baechle Cc: Benjamin Herrenschmidt Cc: Li Yang Cc: linux-m...@linux-mips.org --- arch/mips/Kconfig|2 +- arch/powerpc/Kconfig |4 ++-- 2 files changed, 3 insertions(+), 3 deletions(-) diff --git a/arch/mips/Kconfig b/arch/mips/Kconfig index 650de39..e6a8a7a 100644 --- a/arch/mips/Kconfig +++ b/arch/mips/Kconfig @@ -2442,7 +2442,7 @@ source "drivers/pcmcia/Kconfig" source "drivers/pci/hotplug/Kconfig" config RAPIDIO - bool "RapidIO support" + tristate "RapidIO support" depends on PCI default n help diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig index b44b52c..992531f 100644 --- a/arch/powerpc/Kconfig +++ b/arch/powerpc/Kconfig @@ -790,7 +790,7 @@ config HAS_RAPIDIO default n config RAPIDIO - bool "RapidIO support" + tristate "RapidIO support" depends on HAS_RAPIDIO || PCI help If you say Y here, the kernel will include drivers and @@ -798,7 +798,7 @@ config RAPIDIO config FSL_RIO bool "Freescale Embedded SRIO Controller support" - depends on RAPIDIO && HAS_RAPIDIO + depends on RAPIDIO = y && HAS_RAPIDIO default "n" ---help--- Include support for RapidIO controller on Freescale embedded -- 1.7.8.4 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [RFC][PATCH v1] ASoC: fsl_ssi: Add DAI master mode support for SSI on i.MX series
On Thu, Dec 12, 2013 at 06:44:45PM +0800, Nicolin Chen wrote:
> +/**
> + * fsl_ssi_set_dai_tdm_slot - set TDM slot number
> + *
> + * Note: This function can be only called when using SSI as DAI master
> + */
> +static int fsl_ssi_set_dai_tdm_slot(struct snd_soc_dai *cpu_dai, u32 tx_mask,
> + u32 rx_mask, int slots, int slot_width)
> +{
> + struct fsl_ssi_private *ssi_private = snd_soc_dai_get_drvdata(cpu_dai);
> + struct ccsr_ssi __iomem *ssi = ssi_private->ssi;
> + u32 val;
I'm a bit concernred about what this is for and why it's required - is
it something that machine drivers have to call and if it is shouldn't
the driver be defaulting to a sensible configuration?
signature.asc
Description: Digital signature
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: commit e38c0a1f breaks powerpc boards with uli1575 chip
[fixed DT maillist address]
On 12/17/2013 01:35 AM, Nikita Yushchenko wrote:
> Hi
>
> While trying to make freescale p2020ds and mpc8572ds boards working with
> mainline kernel, I faced that commit
> e38c0a1f (Handle #address-cells > 2 specially) breaks things with these
> boards.
Good to see this broke in v3.7 and is just now found...
>
> Both these boards have uli1575 chip.
> Corresponding part in device tree is something like
>
> uli1575@0 {
> reg = <0x0 0x0 0x0 0x0 0x0>;
> #size-cells = <2>;
> #address-cells = <3>;
> ranges = <0x200 0x0 0x8000
> 0x200 0x0 0x8000
> 0x0 0x2000
>
> 0x100 0x0 0x0
> 0x100 0x0 0x0
> 0x0 0x1>;
> isa@1e {
> ...
>
> I.e. it has #address-cells = <3>
>
>
> With commit e38c0a1f reverted, devices under uli1575 are registered
> correctly, e.g. for rtc
>
> OF: ** translation for device /pcie@ffe09000/pcie@0/uli1575@0/isa@1e/rtc@70 **
> OF: bus is isa (na=2, ns=1) on /pcie@ffe09000/pcie@0/uli1575@0/isa@1e
> OF: translating address: 0001 0070
> OF: parent bus is default (na=3, ns=2) on /pcie@ffe09000/pcie@0/uli1575@0
> OF: walking ranges...
> OF: ISA map, cp=0, s=1000, da=70
> OF: parent translation for: 0100
> OF: with offset: 70
> OF: one level translation: 0070
> OF: parent bus is pci (na=3, ns=2) on /pcie@ffe09000/pcie@0
> OF: walking ranges...
> OF: default map, cp=a000, s=2000, da=70
> OF: default map, cp=0, s=1, da=70
> OF: parent translation for: 0100
> OF: with offset: 70
> OF: one level translation: 0100 0070
> OF: parent bus is pci (na=3, ns=2) on /pcie@ffe09000
> OF: walking ranges...
> OF: PCI map, cp=0, s=1, da=70
> OF: parent translation for: 0100
> OF: with offset: 70
> OF: one level translation: 0100 0070
> OF: parent bus is default (na=2, ns=2) on /
> OF: walking ranges...
> OF: PCI map, cp=0, s=1, da=70
> OF: parent translation for: ffc1
> OF: with offset: 70
> OF: one level translation: ffc10070
> OF: reached root node
>
> With commit e38c0a1f in place, address translation fails:
>
> OF: ** translation for device /pcie@ffe09000/pcie@0/uli1575@0/isa@1e/rtc@70 **
> OF: bus is isa (na=2, ns=1) on /pcie@ffe09000/pcie@0/uli1575@0/isa@1e
> OF: translating address: 0001 0070
> OF: parent bus is default (na=3, ns=2) on /pcie@ffe09000/pcie@0/uli1575@0
> OF: walking ranges...
> OF: ISA map, cp=0, s=1000, da=70
> OF: parent translation for: 0100
> OF: with offset: 70
> OF: one level translation: 0070
> OF: parent bus is pci (na=3, ns=2) on /pcie@ffe09000/pcie@0
> OF: walking ranges...
> OF: default map, cp=a000, s=2000, da=70
> OF: default map, cp=0, s=1, da=70
> OF: not found !
>
> Either e38c0a1f should be reverted, or uli1575 (and perhaps other similar
> devices) have to be described in device
> trees differently.
Reverting would break Tegra PCIe, but you should not have to change the
DT either. So we need a solution.
Is this something like this sufficient to fix it?
diff --git a/drivers/of/address.c b/drivers/of/address.c
index 4b9317b..378aebd 100644
--- a/drivers/of/address.c
+++ b/drivers/of/address.c
@@ -74,7 +74,7 @@ static u64 of_bus_default_map(__be32 *addr, const
__be32 *range,
* mapping doesn't specify a physical address. Rather, the address
* specifies an identifier that must match exactly.
*/
- if (na > 2 && memcmp(range, addr, na * 4) != 0)
+ if (na > 2 && memcmp(range, addr, (na - 2) * 4) != 0)
return OF_BAD_ADDR;
if (da < cp || da >= (cp + s))
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v2 2/6] PCI/MSI: Factor out pci_get_msi_cap() interface
On Thu, Sep 26, 2013 at 08:32:53AM -0400, Mark Lord wrote: > On 13-09-18 05:48 AM, Alexander Gordeev wrote: > > > > The last pattern makes most of sense to me and could be updated with a more > > clear sequence - a call to (bit modified) pci_msix_table_size() followed > > by a call to pci_enable_msix(). I think this pattern can effectively > > supersede the currently recommended "loop" practice. > > The loop is still necessary, because there's a race between those two calls, > so that pci_enable_msix() can still fail due to lack of MSIX slots. Hi Mark, Can you elaborate on this race? My understanding is that pci_msix_table_size() depends only on the "Table Size" field in the MSI-X Message Control register. So if there's a concurrency problem here, it would have to be something like "pci_enable_msix() may not be able to configure the requested number of vectors because it has to allocate from a shared pool." If that's the case, pci_msix_table_size() wouldn't be involved at all, and the only question is how to coordinate between several drivers that each call pci_enable_msix(). I think that would have to be resolved in some arch hook used by the PCI core. Maybe this is already taken care of; I just want to make sure we don't overlook an issue here. Bjorn ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] powerpc: book3s: kvm: Don't abuse host r2 in exit path
On 18.12.2013, at 08:35, Aneesh Kumar K.V wrote: > > Hi Alex, > > Any update on this ? We need this to got into 3.13. Thanks, applied to for-3.13. Alex ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] powerpc: Make 64-bit non-VMX __copy_tofrom_user bi-endian
Hi, > [ This is a rare but nasty LE issue. Most of the time we use the > POWER7 optimised __copy_tofrom_user_power7 loop, but when it hits an > exception we fall back to the base __copy_tofrom_user loop. - Anton ] To try and catch any screw ups in our ppc64 memcpy and copy_tofrom_user loops, I wrote a quick test: http://ozlabs.org/~anton/junkcode/validate_kernel_copyloops.tar.gz "make check" runs through all source and destination alignments for a range of sizes. It verifies the data was copied correctly and the redzone before and after were untouched. It tests: copyuser_64 copyuser_power7 memcpy_64 memcpy_power7 memcpy_64 is currently unused on LE, but I added Paul McKenney's LE fixes regardless. copyuser_64 has the same LE fix (posted yesterday). All loops pass the test on both LE and BE. Anton ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 2/2] powerpc/p1022ds: add a interrupt for rtc node
From: Wang Dongsheng
Add an external interrupt for rtc node.
Signed-off-by: Wang Dongsheng
diff --git a/arch/powerpc/boot/dts/p1022ds.dtsi
b/arch/powerpc/boot/dts/p1022ds.dtsi
index 5725058..957e0dc 100644
--- a/arch/powerpc/boot/dts/p1022ds.dtsi
+++ b/arch/powerpc/boot/dts/p1022ds.dtsi
@@ -148,6 +148,7 @@
rtc@68 {
compatible = "dallas,ds3232";
reg = <0x68>;
+ interrupts = <0x1 0x1 0 0>;
};
adt7461@4c {
compatible = "adi,adt7461";
--
1.8.5
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 1/2] powerpc/p1022ds: fix rtc compatible string
From: Wang Dongsheng
RTC Hardware(ds3232) and rtc compatible string does not match.
Change "dallas,ds1339" to "dallas,ds3232".
Signed-off-by: Wang Dongsheng
diff --git a/arch/powerpc/boot/dts/p1022ds.dtsi
b/arch/powerpc/boot/dts/p1022ds.dtsi
index 873da35..5725058 100644
--- a/arch/powerpc/boot/dts/p1022ds.dtsi
+++ b/arch/powerpc/boot/dts/p1022ds.dtsi
@@ -146,7 +146,7 @@
*/
};
rtc@68 {
- compatible = "dallas,ds1339";
+ compatible = "dallas,ds3232";
reg = <0x68>;
};
adt7461@4c {
--
1.8.5
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
