[PATCH 1/2] powerpc/p1022ds: fix rtc compatible string
From: Wang Dongsheng dongsheng.w...@freescale.com
RTC Hardware(ds3232) and rtc compatible string does not match.
Change dallas,ds1339 to dallas,ds3232.
Signed-off-by: Wang Dongsheng dongsheng.w...@freescale.com
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
[PATCH 2/2] powerpc/p1022ds: add a interrupt for rtc node
From: Wang Dongsheng dongsheng.w...@freescale.com
Add an external interrupt for rtc node.
Signed-off-by: Wang Dongsheng dongsheng.w...@freescale.com
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
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
Re: [PATCH] powerpc: book3s: kvm: Don't abuse host r2 in exit path
On 18.12.2013, at 08:35, Aneesh Kumar K.V aneesh.ku...@linux.vnet.ibm.com 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 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: 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: [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
[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 alexandre.boun...@idt.com Cc: Matt Porter mpor...@kernel.crashing.org Cc: Jean Delvare jdelv...@suse.de Cc: Ralf Baechle r...@linux-mips.org Cc: Benjamin Herrenschmidt b...@kernel.crashing.org Cc: Li Yang le...@freescale.com 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: [PATCH v1 0/4] powerpc/512x: update COMMON_CLK support for MPC5125
On Tue, 10 Dec 2013 14:11:33 +0100 Gerhard Sittig g...@denx.de 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
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 g...@denx.de 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 ag...@denx.de Cc: linuxppc-dev@lists.ozlabs.org Cc: devicet...@vger.kernel.org Signed-off-by: Gerhard Sittig g...@denx.de --- 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] powerpc: book3s: kvm: Use the saved dsisr and dar values
On 11.11.2013, at 15:02, Aneesh Kumar K.V aneesh.ku...@linux.vnet.ibm.com wrote: From: Aneesh Kumar K.V aneesh.ku...@linux.vnet.ibm.com Don't try to compute these values. Signed-off-by: Aneesh Kumar K.V aneesh.ku...@linux.vnet.ibm.com --- 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 ag...@suse.de 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 ag...@suse.de Signed-off-by: Avi Kivity a...@redhat.com 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 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 tony.l...@intel.com ___ 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 mturque...@linaro.org
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 linux/clk-provider.h 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: [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: [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: [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 aneesh.ku...@linux.vnet.ibm.com wrote: From: Aneesh Kumar K.V aneesh.ku...@linux.vnet.ibm.com Don't try to compute these values. Signed-off-by: Aneesh Kumar K.V aneesh.ku...@linux.vnet.ibm.com --- 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 ag...@suse.de 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 ag...@suse.de Signed-off-by: Avi Kivity a...@redhat.com 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: [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: 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: [PATCH] powerpc: book3s: kvm: Use the saved dsisr and dar values
Alexander Graf ag...@suse.de writes: On 11.11.2013, at 15:02, Aneesh Kumar K.V aneesh.ku...@linux.vnet.ibm.com wrote: From: Aneesh Kumar K.V aneesh.ku...@linux.vnet.ibm.com Don't try to compute these values. Signed-off-by: Aneesh Kumar K.V aneesh.ku...@linux.vnet.ibm.com --- 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 ag...@suse.de 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 ag...@suse.de Signed-off-by: Avi Kivity a...@redhat.com 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
