* [PATCH 2/2] ASoC: fsl_ssi: Add monaural audio support for non-ac97 interface
From: Nicolin Chen @ 2013-11-14 11:07 UTC (permalink / raw)
To: timur, shawn.guo, broonie
Cc: mark.rutland, devicetree, alsa-devel, linux, pawel.moll,
ijc+devicetree, swarren, linux-kernel, rob.herring, lgirdwood,
linuxppc-dev, linux-arm-kernel
In-Reply-To: <1384427230-979-1-git-send-email-b42378@freescale.com>
The normal mode of SSI allows it to send/receive data to/from the first
slot of each period. So we can use this normal mode to trick I2S signal
by puting/getting data to/from the first slot only (the left channel)
so as to support monaural audio playback and recording.
Signed-off-by: Nicolin Chen <b42378@freescale.com>
---
sound/soc/fsl/fsl_ssi.c | 22 +++++++++++++++++++---
1 file changed, 19 insertions(+), 3 deletions(-)
diff --git a/sound/soc/fsl/fsl_ssi.c b/sound/soc/fsl/fsl_ssi.c
index f43be6d..ccf1d38 100644
--- a/sound/soc/fsl/fsl_ssi.c
+++ b/sound/soc/fsl/fsl_ssi.c
@@ -517,10 +517,12 @@ static int fsl_ssi_hw_params(struct snd_pcm_substream *substream,
{
struct fsl_ssi_private *ssi_private = snd_soc_dai_get_drvdata(cpu_dai);
struct ccsr_ssi __iomem *ssi = ssi_private->ssi;
+ unsigned int channels = params_channels(hw_params);
unsigned int sample_size =
snd_pcm_format_width(params_format(hw_params));
u32 wl = CCSR_SSI_SxCCR_WL(sample_size);
int enabled = read_ssi(&ssi->scr) & CCSR_SSI_SCR_SSIEN;
+ static u8 i2s_mode;
/*
* If we're in synchronous mode, and the SSI is already enabled,
@@ -546,6 +548,21 @@ static int fsl_ssi_hw_params(struct snd_pcm_substream *substream,
else
write_ssi_mask(&ssi->srccr, CCSR_SSI_SxCCR_WL_MASK, wl);
+ if (ssi_private->imx_ac97)
+ return 0;
+
+ /* Save i2s mode configuration so that we can restore it later */
+ switch (read_ssi(&ssi->scr) & CCSR_SSI_SCR_I2S_MODE_MASK) {
+ case CCSR_SSI_SCR_I2S_MODE_SLAVE:
+ case CCSR_SSI_SCR_I2S_MODE_MASTER:
+ i2s_mode = read_ssi(&ssi->scr) & CCSR_SSI_SCR_I2S_MODE_MASK;
+ default:
+ break;
+ }
+
+ write_ssi_mask(&ssi->scr, CCSR_SSI_SCR_NET | CCSR_SSI_SCR_I2S_MODE_MASK,
+ channels == 1 ? 0 : CCSR_SSI_SCR_NET | i2s_mode);
+
return 0;
}
@@ -658,14 +675,13 @@ static const struct snd_soc_dai_ops fsl_ssi_dai_ops = {
static struct snd_soc_dai_driver fsl_ssi_dai_template = {
.probe = fsl_ssi_dai_probe,
.playback = {
- /* The SSI does not support monaural audio. */
- .channels_min = 2,
+ .channels_min = 1,
.channels_max = 2,
.rates = FSLSSI_I2S_RATES,
.formats = FSLSSI_I2S_FORMATS,
},
.capture = {
- .channels_min = 2,
+ .channels_min = 1,
.channels_max = 2,
.rates = FSLSSI_I2S_RATES,
.formats = FSLSSI_I2S_FORMATS,
--
1.8.4
^ permalink raw reply related
* [PATCH 1/2] ARM: dts: imx: specify the value of audmux pinctrl instead of 0x80000000
From: Nicolin Chen @ 2013-11-14 11:07 UTC (permalink / raw)
To: timur, shawn.guo, broonie
Cc: mark.rutland, devicetree, alsa-devel, linux, pawel.moll,
ijc+devicetree, swarren, linux-kernel, rob.herring, lgirdwood,
linuxppc-dev, linux-arm-kernel
In-Reply-To: <1384427230-979-1-git-send-email-b42378@freescale.com>
We must specify the value of audmux pinctrl if we want to use pinctrl_pm().
Thus change bypass value 0x80000000 to what we exactly need.
This patch also seperately unset PUE bit for TXD so that IOMUX won't pull
up/down the pin after turning into tristate. When we use SSI normal mode to
playback monaural audio via I2S signal, there'd be a pulled curve occur to
its signal at the second slot if setting PUE bit for TXD. And it will make
the second channel to play a constant noise. So by keeping the signal level
in the second slot, we can get a constant high level signal (-1) or a low
level one (0).
Signed-off-by: Nicolin Chen <b42378@freescale.com>
---
arch/arm/boot/dts/imx6qdl.dtsi | 22 +++++++++++-----------
1 file changed, 11 insertions(+), 11 deletions(-)
diff --git a/arch/arm/boot/dts/imx6qdl.dtsi b/arch/arm/boot/dts/imx6qdl.dtsi
index 6e096ca..6b76e55 100644
--- a/arch/arm/boot/dts/imx6qdl.dtsi
+++ b/arch/arm/boot/dts/imx6qdl.dtsi
@@ -601,27 +601,27 @@
audmux {
pinctrl_audmux_1: audmux-1 {
fsl,pins = <
- MX6QDL_PAD_SD2_DAT0__AUD4_RXD 0x80000000
- MX6QDL_PAD_SD2_DAT3__AUD4_TXC 0x80000000
- MX6QDL_PAD_SD2_DAT2__AUD4_TXD 0x80000000
- MX6QDL_PAD_SD2_DAT1__AUD4_TXFS 0x80000000
+ MX6QDL_PAD_SD2_DAT0__AUD4_RXD 0x130b0
+ MX6QDL_PAD_SD2_DAT3__AUD4_TXC 0x130b0
+ MX6QDL_PAD_SD2_DAT2__AUD4_TXD 0x110b0
+ MX6QDL_PAD_SD2_DAT1__AUD4_TXFS 0x130b0
>;
};
pinctrl_audmux_2: audmux-2 {
fsl,pins = <
- MX6QDL_PAD_CSI0_DAT7__AUD3_RXD 0x80000000
- MX6QDL_PAD_CSI0_DAT4__AUD3_TXC 0x80000000
- MX6QDL_PAD_CSI0_DAT5__AUD3_TXD 0x80000000
- MX6QDL_PAD_CSI0_DAT6__AUD3_TXFS 0x80000000
+ MX6QDL_PAD_CSI0_DAT7__AUD3_RXD 0x130b0
+ MX6QDL_PAD_CSI0_DAT4__AUD3_TXC 0x130b0
+ MX6QDL_PAD_CSI0_DAT5__AUD3_TXD 0x110b0
+ MX6QDL_PAD_CSI0_DAT6__AUD3_TXFS 0x130b0
>;
};
pinctrl_audmux_3: audmux-3 {
fsl,pins = <
- MX6QDL_PAD_DISP0_DAT16__AUD5_TXC 0x80000000
- MX6QDL_PAD_DISP0_DAT18__AUD5_TXFS 0x80000000
- MX6QDL_PAD_DISP0_DAT19__AUD5_RXD 0x80000000
+ MX6QDL_PAD_DISP0_DAT16__AUD5_TXC 0x130b0
+ MX6QDL_PAD_DISP0_DAT18__AUD5_TXFS 0x130b0
+ MX6QDL_PAD_DISP0_DAT19__AUD5_RXD 0x130b0
>;
};
};
--
1.8.4
^ permalink raw reply related
* [PATCH 0/2] Add monaural audio support for fsl_ssi.c
From: Nicolin Chen @ 2013-11-14 11:07 UTC (permalink / raw)
To: timur, shawn.guo, broonie
Cc: mark.rutland, devicetree, alsa-devel, linux, pawel.moll,
ijc+devicetree, swarren, linux-kernel, rob.herring, lgirdwood,
linuxppc-dev, linux-arm-kernel
This series of patches need to be applied into one single tree because
the second patch depends on the first one. Without it, SSI would playback
constant noise to the right channel when playback monaural audio files on
i.MX6 Series board.
We might also need to apply the iomux change to the other i.MX platforms,
just currently I don't have those boards so I drop their changes for now.
Nicolin Chen (2):
ARM: dts: imx: specify the value of audmux pinctrl instead of
0x80000000
ASoC: fsl_ssi: Add monaural audio support for non-ac97 interface
arch/arm/boot/dts/imx6qdl.dtsi | 22 +++++++++++-----------
sound/soc/fsl/fsl_ssi.c | 22 +++++++++++++++++++---
2 files changed, 30 insertions(+), 14 deletions(-)
--
1.8.4
^ permalink raw reply
* Re: Problem reading and programming memory location...
From: neorf3k @ 2013-11-14 9:49 UTC (permalink / raw)
To: Anatolij Gustschin; +Cc: Linux Ppc Dev List Dev List
In-Reply-To: <20131114100917.31f674d7@crub>
[-- Attachment #1: Type: text/plain, Size: 914 bytes --]
Sorry, the address is 0x10020000.
I've executed this code:
/* code */
unsigned char *virt_base;
u8 regval;
/* map 4kbyte reg. space */
virt_base = ioremap(0x10020000, 0x1000);
if (!virt_base) {
printk("fpga ioremap failed\n");
return;
}
regval = in_8(virt_base);
printk("reg. value 0x%02x\n", regval);
printk("reg. value %x\n", virt_base);
/* code */
and i've:
reg. value 0x10
address c90e8000
in U-BOOT in reg. value i've: 0xf8
Thank you so much again…
Lorenzo
On 14/nov/2013, at 10:09 AM, Anatolij Gustschin <agust@denx.de> wrote:
> u8 regval;
>
> /* map 4kbyte reg. space */
> virt_base = ioremap(0x10020000, 0x1000);
> if (!virt_base) {
> printk("fpga ioremap failed\n");
> return;
> }
>
> regval = in_8(virt_base);
>
> printk("reg. value 0x%02x\n", regval);
[-- Attachment #2: Type: text/html, Size: 8691 bytes --]
^ permalink raw reply
* Re: [PATCH 00/11] Consolidate asm/fixmap.h files
From: Michal Simek @ 2013-11-14 9:39 UTC (permalink / raw)
To: Mark Salter
Cc: linux-arch, linux-mips, James Hogan, Russell King, Arnd Bergmann,
linux-hexagon, linux-kernel, Ralf Baechle, Richard Kuo,
microblaze-uclinux, Paul Mackerras, linuxppc-dev, linux-metag,
linux-arm-kernel
In-Reply-To: <1384271711.24631.5.camel@deneb.redhat.com>
[-- Attachment #1: Type: text/plain, Size: 1503 bytes --]
On 11/12/2013 04:55 PM, Mark Salter wrote:
> On Tue, 2013-11-12 at 16:39 +0100, Michal Simek wrote:
>> On 11/12/2013 02:22 PM, Mark Salter wrote:
>>>
>>> arch/arm/include/asm/fixmap.h | 25 ++------
>>> arch/hexagon/include/asm/fixmap.h | 40 +------------
>>> arch/metag/include/asm/fixmap.h | 32 +----------
>>> arch/microblaze/include/asm/fixmap.h | 44 +-------------
>>> arch/mips/include/asm/fixmap.h | 33 +----------
>>> arch/powerpc/include/asm/fixmap.h | 44 +-------------
>>> arch/sh/include/asm/fixmap.h | 39 +------------
>>> arch/tile/include/asm/fixmap.h | 33 +----------
>>> arch/um/include/asm/fixmap.h | 40 +------------
>>> arch/x86/include/asm/fixmap.h | 59 +------------------
>>> include/asm-generic/fixmap.h | 107 +++++++++++++++++++++++++++++++++++
>>> 11 files changed, 125 insertions(+), 371 deletions(-)
>>> create mode 100644 include/asm-generic/fixmap.h
>>
>> Any repo/branch with all these patches will be helpful.
>
> https://github.com/mosalter/linux (fixmap branch)
Thanks,
For Microblaze
Tested-by: Michal Simek <monstr@monstr.eu>
Thanks,
Michal
--
Michal Simek, Ing. (M.Eng), OpenPGP -> KeyID: FE3D1F91
w: www.monstr.eu p: +42-0-721842854
Maintainer of Linux kernel - Microblaze cpu - http://www.monstr.eu/fdt/
Maintainer of Linux kernel - Xilinx Zynq ARM architecture
Microblaze U-BOOT custodian and responsible for u-boot arm zynq platform
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 263 bytes --]
^ permalink raw reply
* Re: Problem reading and programming memory location...
From: neorf3k @ 2013-11-14 8:38 UTC (permalink / raw)
To: Anatolij Gustschin
In-Reply-To: <20131113190606.2a5d08fb@crub>
Thank you again=85
we have checked, and the settings in Chip Select 4 Configuration, seems =
to be ok=85
The strange thing is the return value from ioremap(). In U-Boot return =
value from address 0x1002000 is 0x45f80360=85 if we try to map it in our =
module, then we use ioremap(), return value is 0x10101010. So maybe the =
register address is mapped wrong=85 what could i fix it?
Then, after we have setted up the reg at 0x1002000 and we boot linux=85 =
the 0x1002000 doesn=92t change its value=85=20
Thanks again=85
Lorenzo
On 13/nov/2013, at 07:06 PM, Anatolij Gustschin <agust@denx.de> wrote:
> On Wed, 13 Nov 2013 14:48:24 +0100
> neorf3k <neorf3k@gmail.com> wrote:
>=20
>> Yes, that is a device on the lpb via an fpga. We have tried to =
configure
>> the chip select 4 configuration register at address MBAR + 0x0310, =
and it
>> seems to be ok. what do you mean with =93chip select parameters=94?
>=20
> I meant the settings you can set up in the Chip Select 1=967 =
Configuration
> Registers, like address and data bus size, wait-states, etc.
>=20
>> We have been able to edit it in U-BOOT, and the board (that chip) now =
works=85
>> The strange thing, is that when we read in linux, at that address, we =
see
>> other content value=85
>> Suggestions?
>=20
> if you can access the register under U-Boot and read out the
> expected values, then the access should work under Linux too,
> assuming the chip select config is not overwritten somewhere
> while booting and the register address range is mapped correctly.
> I don't know your code, so I would first check if the register
> mapping is done correctly, i.e. check the return value of ioremap()
> for errors, then check if the chip select configuration is still
> valid when the kernel is up. Also verify that your fpga is not
> in the reset state when Linux is running.
>=20
> thanks,
>=20
> Anatolij
^ permalink raw reply
* RE: [PATCH] Add a vga alias node for P1022
From: Zhengxiong Jin @ 2013-11-14 7:29 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev@lists.ozlabs.org
In-Reply-To: <1384363303.1403.143.camel@snotra.buserror.net>
DQo+ID4gPg0KPiA+ID4gV2hlbiB0aGUgdmdhIHdhcyBzZXQgYXMgdGhlIHN0ZG91dCBhbmQgc3Rk
ZXJyIGluIHUtYm9vdCwgdGhlIHN0ZG91dA0KPiA+ID4gZml4dXAgY29kZSBpbiB1LWJvb3QgbmVl
ZCB0byBmaW5kIG91dCB0aGUgdmdhIGFsaWFzIG5vZGUgaW4gZHRiLg0KPiA+ID4NCj4gPiA+IFNp
Z25lZC1vZmYtYnk6IEphc29uIEppbiA8SmFzb24uamluQGZyZWVzY2FsZS5jb20+DQo+ID4gPiAt
LS0NCj4gPiA+ICBhcmNoL3Bvd2VycGMvYm9vdC9kdHMvZnNsL3AxMDIyc2ktcG9zdC5kdHNpIHwg
MiArLQ0KPiA+ID4gYXJjaC9wb3dlcnBjL2Jvb3QvZHRzL2ZzbC9wMTAyMnNpLXByZS5kdHNpICB8
IDEgKw0KPiA+ID4gIDIgZmlsZXMgY2hhbmdlZCwgMiBpbnNlcnRpb25zKCspLCAxIGRlbGV0aW9u
KC0pDQo+ID4NCj4gPiBbSmFzb24gSmluLVI2NDE4OF0gQW55IGNvbW1lbnRzIGFib3V0IHRoaXMg
cGF0Y2g/IFRoYW5rcy4NCj4gDQo+IFRoaXMgaXNuJ3QgYSBWR0EtY29tcGF0aWJsZSBkZXZpY2Uu
ICBJZiB0aGlzIGlzIG5lZWRlZCBieSBVLUJvb3QsIHBsZWFzZQ0KPiBwcm92aWRlIGEgY29tbWVu
dCBleHBsYWluaW5nIHRoZSBjb21wYXRpYmlsaXR5IGlzc3VlLCBhbmQgaWRlYWxseSBhbHNvDQo+
IHByb3ZpZGUgYSBkaXNwbGF5IGFsaWFzIHNvIHRoYXQgbm8gb3RoZXIgY29tcG9uZW50cyBncm93
IGRlcGVuZGVuY2llcyBvbg0KPiB0aGUgdmdhIGFsaWFzLg0KPiANCj4gLVNjb3R0DQo+IA0KW0ph
c29uIEppbi1SNjQxODhdIFRoYW5rcywgd2lsbCBhZGQgZGVzY3JpcHRpb24gZm9yIHdoeSB0aGUg
dmdhIGFsaWFzIG5vZGUgaXMgbmVlZGVkIGJ5IHUtYm9vdCwgYW5kIGFkZCBhbm90aGVyIGRpc3Bs
YXkgYWxpYXMgbm9kZS4NCg==
^ permalink raw reply
* [PATCH] powerpc: fix __get_user_pages_fast() irq handling
From: Benjamin Herrenschmidt @ 2013-11-14 4:01 UTC (permalink / raw)
To: linuxppc-dev list; +Cc: Heiko Carstens
From: Heiko Carstens <heiko.carstens@de.ibm.com>
__get_user_pages_fast() may be called with interrupts disabled (see e.g.
get_futex_key() in kernel/futex.c) and therefore should use local_irq_save()
and local_irq_restore() instead of local_irq_disable()/enable().
Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com>
---
(Was originally sent to lkml only, sending to linuxppc-dev so patchwork gets it)
arch/powerpc/mm/gup.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/mm/gup.c b/arch/powerpc/mm/gup.c
index 6936547..c5f734e 100644
--- a/arch/powerpc/mm/gup.c
+++ b/arch/powerpc/mm/gup.c
@@ -123,6 +123,7 @@ int __get_user_pages_fast(unsigned long start, int nr_pages, int write,
struct mm_struct *mm = current->mm;
unsigned long addr, len, end;
unsigned long next;
+ unsigned long flags;
pgd_t *pgdp;
int nr = 0;
@@ -156,7 +157,7 @@ int __get_user_pages_fast(unsigned long start, int nr_pages, int write,
* So long as we atomically load page table pointers versus teardown,
* we can follow the address down to the the page and take a ref on it.
*/
- local_irq_disable();
+ local_irq_save(flags);
pgdp = pgd_offset(mm, addr);
do {
@@ -179,7 +180,7 @@ int __get_user_pages_fast(unsigned long start, int nr_pages, int write,
break;
} while (pgdp++, addr = next, addr != end);
- local_irq_enable();
+ local_irq_restore(flags);
return nr;
}
--
1.8.3.4
^ permalink raw reply related
* [PATCH v3] powerpc/85xx: Merge 85xx/p1023_defconfig into mpc85xx_smp_defconfig and mpc85xx_defconfig
From: Lijun Pan @ 2013-11-13 23:24 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Lijun Pan
In-Reply-To: <1384197913-24610-1-git-send-email-Lijun.Pan@freescale.com>
mpc85xx_smp_defconfig and mpc85xx_defconfig already have CONFIG_P1023RDS=y.
Merge CONFIG_P1023RDB=y and other relevant configurations into mpc85xx_smp_defconfig and mpc85_defconfig.
Signed-off-by: Lijun Pan <Lijun.Pan@freescale.com>
---
arch/powerpc/configs/85xx/p1023_defconfig | 188 ----------------------------
arch/powerpc/configs/mpc85xx_defconfig | 3 +
arch/powerpc/configs/mpc85xx_smp_defconfig | 3 +
3 files changed, 6 insertions(+), 188 deletions(-)
delete mode 100644 arch/powerpc/configs/85xx/p1023_defconfig
diff --git a/arch/powerpc/configs/85xx/p1023_defconfig b/arch/powerpc/configs/85xx/p1023_defconfig
deleted file mode 100644
index b06d37d..0000000
--- a/arch/powerpc/configs/85xx/p1023_defconfig
+++ /dev/null
@@ -1,188 +0,0 @@
-CONFIG_PPC_85xx=y
-CONFIG_SMP=y
-CONFIG_NR_CPUS=2
-CONFIG_SYSVIPC=y
-CONFIG_POSIX_MQUEUE=y
-CONFIG_BSD_PROCESS_ACCT=y
-CONFIG_AUDIT=y
-CONFIG_NO_HZ=y
-CONFIG_HIGH_RES_TIMERS=y
-CONFIG_RCU_FANOUT=32
-CONFIG_IKCONFIG=y
-CONFIG_IKCONFIG_PROC=y
-CONFIG_LOG_BUF_SHIFT=14
-CONFIG_BLK_DEV_INITRD=y
-CONFIG_KALLSYMS_ALL=y
-CONFIG_EMBEDDED=y
-CONFIG_MODULES=y
-CONFIG_MODULE_UNLOAD=y
-CONFIG_MODULE_FORCE_UNLOAD=y
-CONFIG_MODVERSIONS=y
-# CONFIG_BLK_DEV_BSG is not set
-CONFIG_PARTITION_ADVANCED=y
-CONFIG_MAC_PARTITION=y
-CONFIG_PHYSICAL_START=0x00000000
-CONFIG_P1023_RDB=y
-CONFIG_P1023_RDS=y
-CONFIG_QUICC_ENGINE=y
-CONFIG_QE_GPIO=y
-CONFIG_CPM2=y
-CONFIG_HIGHMEM=y
-# CONFIG_CORE_DUMP_DEFAULT_ELF_HEADERS is not set
-CONFIG_BINFMT_MISC=m
-CONFIG_MATH_EMULATION=y
-CONFIG_SWIOTLB=y
-CONFIG_PCI=y
-CONFIG_PCIEPORTBUS=y
-# CONFIG_PCIEAER is not set
-# CONFIG_PCIEASPM is not set
-CONFIG_PCI_MSI=y
-CONFIG_NET=y
-CONFIG_PACKET=y
-CONFIG_UNIX=y
-CONFIG_XFRM_USER=y
-CONFIG_NET_KEY=y
-CONFIG_INET=y
-CONFIG_IP_MULTICAST=y
-CONFIG_IP_ADVANCED_ROUTER=y
-CONFIG_IP_MULTIPLE_TABLES=y
-CONFIG_IP_ROUTE_MULTIPATH=y
-CONFIG_IP_ROUTE_VERBOSE=y
-CONFIG_IP_PNP=y
-CONFIG_IP_PNP_DHCP=y
-CONFIG_IP_PNP_BOOTP=y
-CONFIG_IP_PNP_RARP=y
-CONFIG_NET_IPIP=y
-CONFIG_IP_MROUTE=y
-CONFIG_IP_PIMSM_V1=y
-CONFIG_IP_PIMSM_V2=y
-CONFIG_ARPD=y
-CONFIG_INET_ESP=y
-# CONFIG_INET_XFRM_MODE_BEET is not set
-# CONFIG_INET_LRO is not set
-CONFIG_IPV6=y
-CONFIG_IP_SCTP=m
-CONFIG_UEVENT_HELPER_PATH="/sbin/hotplug"
-CONFIG_DEVTMPFS=y
-CONFIG_DEVTMPFS_MOUNT=y
-CONFIG_MTD=y
-CONFIG_MTD_CMDLINE_PARTS=y
-CONFIG_MTD_CHAR=y
-CONFIG_MTD_BLOCK=y
-CONFIG_MTD_CFI=y
-CONFIG_MTD_CFI_AMDSTD=y
-CONFIG_MTD_PHYSMAP_OF=y
-CONFIG_MTD_NAND=y
-CONFIG_MTD_NAND_FSL_ELBC=y
-CONFIG_PROC_DEVICETREE=y
-CONFIG_BLK_DEV_LOOP=y
-CONFIG_BLK_DEV_RAM=y
-CONFIG_BLK_DEV_RAM_SIZE=131072
-CONFIG_EEPROM_AT24=y
-CONFIG_EEPROM_LEGACY=y
-CONFIG_BLK_DEV_SD=y
-CONFIG_CHR_DEV_ST=y
-CONFIG_BLK_DEV_SR=y
-CONFIG_CHR_DEV_SG=y
-CONFIG_SCSI_MULTI_LUN=y
-CONFIG_SCSI_LOGGING=y
-CONFIG_ATA=y
-CONFIG_SATA_FSL=y
-CONFIG_SATA_SIL24=y
-CONFIG_NETDEVICES=y
-CONFIG_DUMMY=y
-CONFIG_FS_ENET=y
-CONFIG_FSL_PQ_MDIO=y
-CONFIG_E1000E=y
-CONFIG_PHYLIB=y
-CONFIG_AT803X_PHY=y
-CONFIG_MARVELL_PHY=y
-CONFIG_DAVICOM_PHY=y
-CONFIG_CICADA_PHY=y
-CONFIG_VITESSE_PHY=y
-CONFIG_FIXED_PHY=y
-CONFIG_INPUT_FF_MEMLESS=m
-# CONFIG_INPUT_MOUSEDEV is not set
-# CONFIG_INPUT_KEYBOARD is not set
-# CONFIG_INPUT_MOUSE is not set
-CONFIG_SERIO_LIBPS2=y
-CONFIG_SERIAL_8250=y
-CONFIG_SERIAL_8250_CONSOLE=y
-CONFIG_SERIAL_8250_NR_UARTS=2
-CONFIG_SERIAL_8250_RUNTIME_UARTS=2
-CONFIG_SERIAL_8250_EXTENDED=y
-CONFIG_SERIAL_8250_MANY_PORTS=y
-CONFIG_SERIAL_8250_SHARE_IRQ=y
-CONFIG_SERIAL_8250_DETECT_IRQ=y
-CONFIG_SERIAL_8250_RSA=y
-CONFIG_HW_RANDOM=y
-CONFIG_NVRAM=y
-CONFIG_I2C=y
-CONFIG_I2C_CHARDEV=y
-CONFIG_I2C_CPM=m
-CONFIG_I2C_MPC=y
-CONFIG_GPIO_MPC8XXX=y
-# CONFIG_HWMON is not set
-CONFIG_VIDEO_OUTPUT_CONTROL=y
-CONFIG_SOUND=y
-CONFIG_SND=y
-CONFIG_SND_MIXER_OSS=y
-CONFIG_SND_PCM_OSS=y
-# CONFIG_SND_SUPPORT_OLD_API is not set
-CONFIG_USB=y
-CONFIG_USB_DEVICEFS=y
-CONFIG_USB_MON=y
-CONFIG_USB_EHCI_HCD=y
-CONFIG_USB_EHCI_FSL=y
-CONFIG_USB_STORAGE=y
-CONFIG_EDAC=y
-CONFIG_EDAC_MM_EDAC=y
-CONFIG_RTC_CLASS=y
-CONFIG_RTC_DRV_DS1307=y
-CONFIG_RTC_DRV_CMOS=y
-CONFIG_DMADEVICES=y
-CONFIG_FSL_DMA=y
-# CONFIG_NET_DMA is not set
-CONFIG_STAGING=y
-CONFIG_EXT2_FS=y
-CONFIG_EXT3_FS=y
-# CONFIG_EXT3_DEFAULTS_TO_ORDERED is not set
-CONFIG_ISO9660_FS=m
-CONFIG_JOLIET=y
-CONFIG_ZISOFS=y
-CONFIG_UDF_FS=m
-CONFIG_MSDOS_FS=m
-CONFIG_VFAT_FS=y
-CONFIG_NTFS_FS=y
-CONFIG_PROC_KCORE=y
-CONFIG_TMPFS=y
-CONFIG_ADFS_FS=m
-CONFIG_AFFS_FS=m
-CONFIG_HFS_FS=m
-CONFIG_HFSPLUS_FS=m
-CONFIG_BEFS_FS=m
-CONFIG_BFS_FS=m
-CONFIG_EFS_FS=m
-CONFIG_CRAMFS=y
-CONFIG_VXFS_FS=m
-CONFIG_HPFS_FS=m
-CONFIG_QNX4FS_FS=m
-CONFIG_SYSV_FS=m
-CONFIG_UFS_FS=m
-CONFIG_NFS_FS=y
-CONFIG_NFS_V4=y
-CONFIG_ROOT_NFS=y
-CONFIG_NFSD=y
-CONFIG_CRC_T10DIF=y
-CONFIG_FRAME_WARN=8092
-CONFIG_DEBUG_FS=y
-CONFIG_DETECT_HUNG_TASK=y
-# CONFIG_DEBUG_BUGVERBOSE is not set
-CONFIG_DEBUG_INFO=y
-CONFIG_STRICT_DEVMEM=y
-CONFIG_CRYPTO_PCBC=m
-CONFIG_CRYPTO_SHA256=y
-CONFIG_CRYPTO_SHA512=y
-CONFIG_CRYPTO_AES=y
-# CONFIG_CRYPTO_ANSI_CPRNG is not set
-CONFIG_CRYPTO_DEV_FSL_CAAM=y
diff --git a/arch/powerpc/configs/mpc85xx_defconfig b/arch/powerpc/configs/mpc85xx_defconfig
index d2e0fab..83d3550 100644
--- a/arch/powerpc/configs/mpc85xx_defconfig
+++ b/arch/powerpc/configs/mpc85xx_defconfig
@@ -31,6 +31,7 @@ CONFIG_C293_PCIE=y
CONFIG_P1010_RDB=y
CONFIG_P1022_DS=y
CONFIG_P1022_RDK=y
+CONFIG_P1023_RDB=y
CONFIG_P1023_RDS=y
CONFIG_SOCRATES=y
CONFIG_KSI8560=y
@@ -113,6 +114,7 @@ CONFIG_BLK_DEV_LOOP=y
CONFIG_BLK_DEV_NBD=y
CONFIG_BLK_DEV_RAM=y
CONFIG_BLK_DEV_RAM_SIZE=131072
+CONFIG_EEPROM_AT24=y
CONFIG_EEPROM_LEGACY=y
CONFIG_BLK_DEV_SD=y
CONFIG_CHR_DEV_ST=y
@@ -211,6 +213,7 @@ CONFIG_EDAC=y
CONFIG_EDAC_MM_EDAC=y
CONFIG_RTC_CLASS=y
CONFIG_RTC_DRV_CMOS=y
+CONFIG_RTC_DRV_DS1307=y
CONFIG_DMADEVICES=y
CONFIG_FSL_DMA=y
# CONFIG_NET_DMA is not set
diff --git a/arch/powerpc/configs/mpc85xx_smp_defconfig b/arch/powerpc/configs/mpc85xx_smp_defconfig
index 4cb7b59..4b68629 100644
--- a/arch/powerpc/configs/mpc85xx_smp_defconfig
+++ b/arch/powerpc/configs/mpc85xx_smp_defconfig
@@ -34,6 +34,7 @@ CONFIG_C293_PCIE=y
CONFIG_P1010_RDB=y
CONFIG_P1022_DS=y
CONFIG_P1022_RDK=y
+CONFIG_P1023_RDB=y
CONFIG_P1023_RDS=y
CONFIG_SOCRATES=y
CONFIG_KSI8560=y
@@ -116,6 +117,7 @@ CONFIG_BLK_DEV_LOOP=y
CONFIG_BLK_DEV_NBD=y
CONFIG_BLK_DEV_RAM=y
CONFIG_BLK_DEV_RAM_SIZE=131072
+CONFIG_EEPROM_AT24=y
CONFIG_EEPROM_LEGACY=y
CONFIG_BLK_DEV_SD=y
CONFIG_CHR_DEV_ST=y
@@ -212,6 +214,7 @@ CONFIG_EDAC=y
CONFIG_EDAC_MM_EDAC=y
CONFIG_RTC_CLASS=y
CONFIG_RTC_DRV_CMOS=y
+CONFIG_RTC_DRV_DS1307=y
CONFIG_DMADEVICES=y
CONFIG_FSL_DMA=y
# CONFIG_NET_DMA is not set
--
1.7.9.7
^ permalink raw reply related
* Re: [PATCH V2] powerpc/85xx: Merge 85xx/p1023_defconfig into mpc85xx_smp_defconfig and mpc85xx_defconfig
From: Scott Wood @ 2013-11-13 19:41 UTC (permalink / raw)
To: Emil Medve; +Cc: linuxppc-dev
In-Reply-To: <5283C51F.9090708@Freescale.com>
On Wed, 2013-11-13 at 12:29 -0600, Emil Medve wrote:
> Somebody gratuitously added a P1023 defconfig more then two years ago
> with the notion that P1023 is special due to its datapath and we're
> still one year out before we'll have the (P1023) datapath driver
> upstream. As of now this defconfig is just bit-rotting in the tree
> creating confusion. Let's just remove it for now and we'll deal with the
> entire e500v2_dpaa business when the datapath support will be upstreamed
Sure.
-Scott
^ permalink raw reply
* Re: [PATCH V2] powerpc/85xx: Merge 85xx/p1023_defconfig into mpc85xx_smp_defconfig and mpc85xx_defconfig
From: Emil Medve @ 2013-11-13 18:29 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <1384366750.1403.154.camel@snotra.buserror.net>
Hello Scott,
On 11/13/2013 12:19 PM, Scott Wood wrote:
> On Tue, 2013-11-12 at 20:34 -0600, Emil Medve wrote:
>> Hello Scott,
>>
>>
>> On 11/12/2013 07:46 PM, Scott Wood wrote:
>>> On Tue, 2013-11-12 at 16:57 -0600, Emil Medve wrote:
>>>> Hello Scott,
>>>>
>>>>
>>>> On 11/12/2013 04:04 PM, Scott Wood wrote:
>>>>> On Mon, 2013-11-11 at 13:25 -0600, Lijun Pan wrote:
>>>>>> mpc85xx_smp_defconfig and mpc85xx_defconfig already have CONFIG_P1023RDS=y.
>>>>>> Merge CONFIG_P1023RDB=y and other relevant configurations into mpc85xx_smp_defconfig and mpc85_defconfig.
>>>>>>
>>>>>> Signed-off-by: Lijun Pan <Lijun.Pan@freescale.com>
>>>>>> ---
>>>>>> arch/powerpc/configs/85xx/p1023_defconfig | 188 ----------------------------
>>>>>> arch/powerpc/configs/mpc85xx_defconfig | 18 +++
>>>>>> arch/powerpc/configs/mpc85xx_smp_defconfig | 17 +++
>>>>>> 3 files changed, 35 insertions(+), 188 deletions(-)
>>>>>> delete mode 100644 arch/powerpc/configs/85xx/p1023_defconfig
>>>>>
>>>>> Are we still going to want to have one defconfig if and when we finally
>>>>> get datapath support upstream? That's a lot of code to add to the 85xx
>>>>> config just for this one chip.
>>>>
>>>> Yes. But for mpc85xx_/smp_defconfig the datapath support shouldn't be
>>>> enabled by default given that just one SoC in that family has the
>>>> datapath (and we don't plan to put it in another e500v2 based SoC). For
>>>> regression/automation purposes config fragments should be used
>>>
>>> Is there any way to specify a meta-config for p1023 (or e500v2-dpaa or
>>> whatever) that says to combine mpc85xx_smp_defconfig with a dpaa
>>> fragment?
>>
>> Not aware of it
>
> Then it's not yet a substitute for having a defconfig.
>
>>> Do we have any config fragments in the tree so far?
>>
>> Nope. However, just to make sure, the fragment was my secondary point
>> and not necessarily as a candidate for upstreaming. My main point was
>> that the datapath support should simply not be enabled by default in the
>> mpc85xx_[smp_]defconfig
>
> I think we should get numbers on how big the datapath code is (in its
> eventual upstream form) before deciding that, but if we do end up
> deciding not to enable it in mpc85xx_smp_defconfig, then there should be
> a separate defconfig for p1023 (possibly with a more generic name as
> discussed earlier). If and when there's support for defconfigs that
> direct fragments to be included, then we can change the p1023 defconfig
> to use that, but I don't want to just leave it up to the user to enable
> manually.
>
> If there's any way we can get the datapath code down to a reasonable
> size for inclusion in mpc85xx_smp_defconfig, that would be ideal.
Somebody gratuitously added a P1023 defconfig more then two years ago
with the notion that P1023 is special due to its datapath and we're
still one year out before we'll have the (P1023) datapath driver
upstream. As of now this defconfig is just bit-rotting in the tree
creating confusion. Let's just remove it for now and we'll deal with the
entire e500v2_dpaa business when the datapath support will be upstreamed
Cheers,
^ permalink raw reply
* Re: [PATCH V2] powerpc/85xx: Merge 85xx/p1023_defconfig into mpc85xx_smp_defconfig and mpc85xx_defconfig
From: Scott Wood @ 2013-11-13 18:19 UTC (permalink / raw)
To: Emil Medve; +Cc: linuxppc-dev
In-Reply-To: <5282E52B.2040306@Freescale.com>
On Tue, 2013-11-12 at 20:34 -0600, Emil Medve wrote:
> Hello Scott,
>
>
> On 11/12/2013 07:46 PM, Scott Wood wrote:
> > On Tue, 2013-11-12 at 16:57 -0600, Emil Medve wrote:
> >> Hello Scott,
> >>
> >>
> >> On 11/12/2013 04:04 PM, Scott Wood wrote:
> >>> On Mon, 2013-11-11 at 13:25 -0600, Lijun Pan wrote:
> >>>> mpc85xx_smp_defconfig and mpc85xx_defconfig already have CONFIG_P1023RDS=y.
> >>>> Merge CONFIG_P1023RDB=y and other relevant configurations into mpc85xx_smp_defconfig and mpc85_defconfig.
> >>>>
> >>>> Signed-off-by: Lijun Pan <Lijun.Pan@freescale.com>
> >>>> ---
> >>>> arch/powerpc/configs/85xx/p1023_defconfig | 188 ----------------------------
> >>>> arch/powerpc/configs/mpc85xx_defconfig | 18 +++
> >>>> arch/powerpc/configs/mpc85xx_smp_defconfig | 17 +++
> >>>> 3 files changed, 35 insertions(+), 188 deletions(-)
> >>>> delete mode 100644 arch/powerpc/configs/85xx/p1023_defconfig
> >>>
> >>> Are we still going to want to have one defconfig if and when we finally
> >>> get datapath support upstream? That's a lot of code to add to the 85xx
> >>> config just for this one chip.
> >>
> >> Yes. But for mpc85xx_/smp_defconfig the datapath support shouldn't be
> >> enabled by default given that just one SoC in that family has the
> >> datapath (and we don't plan to put it in another e500v2 based SoC). For
> >> regression/automation purposes config fragments should be used
> >
> > Is there any way to specify a meta-config for p1023 (or e500v2-dpaa or
> > whatever) that says to combine mpc85xx_smp_defconfig with a dpaa
> > fragment?
>
> Not aware of it
Then it's not yet a substitute for having a defconfig.
> > Do we have any config fragments in the tree so far?
>
> Nope. However, just to make sure, the fragment was my secondary point
> and not necessarily as a candidate for upstreaming. My main point was
> that the datapath support should simply not be enabled by default in the
> mpc85xx_[smp_]defconfig
I think we should get numbers on how big the datapath code is (in its
eventual upstream form) before deciding that, but if we do end up
deciding not to enable it in mpc85xx_smp_defconfig, then there should be
a separate defconfig for p1023 (possibly with a more generic name as
discussed earlier). If and when there's support for defconfigs that
direct fragments to be included, then we can change the p1023 defconfig
to use that, but I don't want to just leave it up to the user to enable
manually.
If there's any way we can get the datapath code down to a reasonable
size for inclusion in mpc85xx_smp_defconfig, that would be ideal.
-Scott
^ permalink raw reply
* Re: Problem reading and programming memory location...
From: Anatolij Gustschin @ 2013-11-13 18:06 UTC (permalink / raw)
To: neorf3k; +Cc: Linux Ppc Dev List Dev List
In-Reply-To: <50EBA514-5BB1-40B3-B27B-309A829D2E05@gmail.com>
On Wed, 13 Nov 2013 14:48:24 +0100
neorf3k <neorf3k@gmail.com> wrote:
> Yes, that is a device on the lpb via an fpga. We have tried to configure
> the chip select 4 configuration register at address MBAR + 0x0310, and it
> seems to be ok. what do you mean with =E2=80=9Cchip select parameters=E2=
=80=9D?
I meant the settings you can set up in the Chip Select 1=E2=80=937 Configur=
ation
Registers, like address and data bus size, wait-states, etc.
> We have been able to edit it in U-BOOT, and the board (that chip) now wor=
ks=E2=80=A6
> The strange thing, is that when we read in linux, at that address, we see
> other content value=E2=80=A6
> Suggestions?
if you can access the register under U-Boot and read out the
expected values, then the access should work under Linux too,
assuming the chip select config is not overwritten somewhere
while booting and the register address range is mapped correctly.
I don't know your code, so I would first check if the register
mapping is done correctly, i.e. check the return value of ioremap()
for errors, then check if the chip select configuration is still
valid when the kernel is up. Also verify that your fpga is not
in the reset state when Linux is running.
thanks,
Anatolij
^ permalink raw reply
* Re: [PATCH] Add a vga alias node for P1022
From: Scott Wood @ 2013-11-13 17:21 UTC (permalink / raw)
To: Jin Zhengxiong-R64188; +Cc: linuxppc-dev@lists.ozlabs.org
In-Reply-To: <13F8657A829DAB49A2A937FD6FC10F790B5CF17A@039-SN2MPN1-013.039d.mgd.msft.net>
On Wed, 2013-11-13 at 00:28 -0600, Jin Zhengxiong-R64188 wrote:
> > -----Original Message-----
> > From: Jin Zhengxiong-R64188
> > Sent: Friday, September 06, 2013 5:33 PM
> > To: Wood Scott-B07421
> > Cc: linuxppc-dev@lists.ozlabs.org; galak@kernel.crashing.org; Jin
> > Zhengxiong-R64188
> > Subject: [PATCH] Add a vga alias node for P1022
> >
> > From: Jason Jin <Jason.jin@freescale.com>
> >
> > When the vga was set as the stdout and stderr in u-boot, the stdout fixup
> > code in u-boot need to find out the vga alias node in dtb.
> >
> > Signed-off-by: Jason Jin <Jason.jin@freescale.com>
> > ---
> > arch/powerpc/boot/dts/fsl/p1022si-post.dtsi | 2 +-
> > arch/powerpc/boot/dts/fsl/p1022si-pre.dtsi | 1 +
> > 2 files changed, 2 insertions(+), 1 deletion(-)
>
> [Jason Jin-R64188] Any comments about this patch? Thanks.
This isn't a VGA-compatible device. If this is needed by U-Boot, please
provide a comment explaining the compatibility issue, and ideally also
provide a display alias so that no other components grow dependencies on
the vga alias.
-Scott
^ permalink raw reply
* Re: BookE "branch taken" behavior vis-a-vis updating the NIP register
From: James Yang @ 2013-11-13 17:20 UTC (permalink / raw)
To: pegasus; +Cc: linuxppc-dev
In-Reply-To: <1384241835150-78036.post@n7.nabble.com>
On Tue, 12 Nov 2013, pegasus wrote:
> So, off I went and downloaded the latest version of
> arch/powerpc/kernel/traps.c hoping to see those very changes in
> them. However it didn't match one on one with what was written in
> that thread. Ditto for the other files in your patch. Looks like
> your patch didn't make it to upstream but it looks exactly like what
> I need here.
The patches were posted RFC -- request for comment. Thank you for
posting your comments.
> So requesting PTRACE_CONT has to happen inside the SIGTRAP signal
> handler right?
After you get the SIGTRAP from the branch, yeah.
> Now as for the second patch, as far as I can see, implements the
> same functionality. However it makes the change permanent and any
> tool which is used to the NIP pointing to the branch target will be
> broken.
The second patch places the burden of determining if you are BookE or
server on the tool. I feel this is important because the Server and
Book-E branch exceptions are fundamentally incompatible, and the
behavior of PTRACE_SINGLEBLOCK can not be made to be identical by the
kernel for both subarch, so a tool will have to adjust accordingly.
> Anyways, for me either of them will work. But I think the first patch makes
> everyone happy by using the 'addr' field of ptrace. This also means I will
> have to make my (broken) ptrace working which, it seems is not as easy
> adding an enum field as you suggested. May be theres a check somewhere in
> the actual ptrace code which checks for illegal values and hence even after
> adding an enum, it is being reported as illegal in my case. However getting
> that to work is another story.
Actually, I provided the first patch to show why it probably should
not be done even though technically possible, since it requires ptrace
API to be extended to now recognize addr field, needs a TIF flag, etc.
The second patch seems to me more reasonable to support, since nobody
has come forth to say that there are actually any tools that rely upon
the existing hack for BookE or even PTRACE_SINGLEBLOCK. And the
existing hack's behavior makes things somewhat useless on BookE, as
you and I have confirmed.
> Please confirm my understanding of your patches and since these
> patches have not made their way to the upstream kernel, will have to
> use them myself directly. By the way, I'm using 2.6.32.10 (you
> know..the long-term kernel) and I couldn't find any of your changes
> in them but then again I couldn't find it in the latest 3.12 version
> either.
You will have to backport the patches to your kernel if you want to
use them. Both patches change the behavior of existing API, and I
guess we are still waiting to hear if anyone cares which way it should
be fixed.
^ permalink raw reply
* [PATCH v7 4/4] ARM: dts: imx: use dual-fifo sdma script for ssi
From: Nicolin Chen @ 2013-11-13 14:55 UTC (permalink / raw)
To: vinod.koul, dan.j.williams, s.hauer, timur, shawn.guo, broonie
Cc: mark.rutland, devicetree, alsa-devel, pawel.moll, linux-doc,
swarren, linux-kernel, rob.herring, dmaengine, ijc+devicetree,
linuxppc-dev, linux-arm-kernel
In-Reply-To: <cover.1384352281.git.b42378@freescale.com>
Use dual-fifo sdma scripts instead of shared scripts for ssi on i.MX series.
Signed-off-by: Nicolin Chen <b42378@freescale.com>
Acked-by: Shawn Guo <shawn.guo@linaro.org>
---
arch/arm/boot/dts/imx51.dtsi | 4 ++--
arch/arm/boot/dts/imx53.dtsi | 4 ++--
arch/arm/boot/dts/imx6qdl.dtsi | 12 ++++++------
arch/arm/boot/dts/imx6sl.dtsi | 12 ++++++------
4 files changed, 16 insertions(+), 16 deletions(-)
diff --git a/arch/arm/boot/dts/imx51.dtsi b/arch/arm/boot/dts/imx51.dtsi
index 54cee65..1a71eac 100644
--- a/arch/arm/boot/dts/imx51.dtsi
+++ b/arch/arm/boot/dts/imx51.dtsi
@@ -154,8 +154,8 @@
reg = <0x70014000 0x4000>;
interrupts = <30>;
clocks = <&clks 49>;
- dmas = <&sdma 24 1 0>,
- <&sdma 25 1 0>;
+ dmas = <&sdma 24 22 0>,
+ <&sdma 25 22 0>;
dma-names = "rx", "tx";
fsl,fifo-depth = <15>;
fsl,ssi-dma-events = <25 24 23 22>; /* TX0 RX0 TX1 RX1 */
diff --git a/arch/arm/boot/dts/imx53.dtsi b/arch/arm/boot/dts/imx53.dtsi
index 4307e80..7208fde 100644
--- a/arch/arm/boot/dts/imx53.dtsi
+++ b/arch/arm/boot/dts/imx53.dtsi
@@ -153,8 +153,8 @@
reg = <0x50014000 0x4000>;
interrupts = <30>;
clocks = <&clks 49>;
- dmas = <&sdma 24 1 0>,
- <&sdma 25 1 0>;
+ dmas = <&sdma 24 22 0>,
+ <&sdma 25 22 0>;
dma-names = "rx", "tx";
fsl,fifo-depth = <15>;
fsl,ssi-dma-events = <25 24 23 22>; /* TX0 RX0 TX1 RX1 */
diff --git a/arch/arm/boot/dts/imx6qdl.dtsi b/arch/arm/boot/dts/imx6qdl.dtsi
index 57e9c38..6e096ca 100644
--- a/arch/arm/boot/dts/imx6qdl.dtsi
+++ b/arch/arm/boot/dts/imx6qdl.dtsi
@@ -223,8 +223,8 @@
reg = <0x02028000 0x4000>;
interrupts = <0 46 0x04>;
clocks = <&clks 178>;
- dmas = <&sdma 37 1 0>,
- <&sdma 38 1 0>;
+ dmas = <&sdma 37 22 0>,
+ <&sdma 38 22 0>;
dma-names = "rx", "tx";
fsl,fifo-depth = <15>;
fsl,ssi-dma-events = <38 37>;
@@ -236,8 +236,8 @@
reg = <0x0202c000 0x4000>;
interrupts = <0 47 0x04>;
clocks = <&clks 179>;
- dmas = <&sdma 41 1 0>,
- <&sdma 42 1 0>;
+ dmas = <&sdma 41 22 0>,
+ <&sdma 42 22 0>;
dma-names = "rx", "tx";
fsl,fifo-depth = <15>;
fsl,ssi-dma-events = <42 41>;
@@ -249,8 +249,8 @@
reg = <0x02030000 0x4000>;
interrupts = <0 48 0x04>;
clocks = <&clks 180>;
- dmas = <&sdma 45 1 0>,
- <&sdma 46 1 0>;
+ dmas = <&sdma 45 22 0>,
+ <&sdma 46 22 0>;
dma-names = "rx", "tx";
fsl,fifo-depth = <15>;
fsl,ssi-dma-events = <46 45>;
diff --git a/arch/arm/boot/dts/imx6sl.dtsi b/arch/arm/boot/dts/imx6sl.dtsi
index c46651e..b32ba99 100644
--- a/arch/arm/boot/dts/imx6sl.dtsi
+++ b/arch/arm/boot/dts/imx6sl.dtsi
@@ -195,8 +195,8 @@
reg = <0x02028000 0x4000>;
interrupts = <0 46 0x04>;
clocks = <&clks IMX6SL_CLK_SSI1>;
- dmas = <&sdma 37 1 0>,
- <&sdma 38 1 0>;
+ dmas = <&sdma 37 22 0>,
+ <&sdma 38 22 0>;
dma-names = "rx", "tx";
fsl,fifo-depth = <15>;
status = "disabled";
@@ -207,8 +207,8 @@
reg = <0x0202c000 0x4000>;
interrupts = <0 47 0x04>;
clocks = <&clks IMX6SL_CLK_SSI2>;
- dmas = <&sdma 41 1 0>,
- <&sdma 42 1 0>;
+ dmas = <&sdma 41 22 0>,
+ <&sdma 42 22 0>;
dma-names = "rx", "tx";
fsl,fifo-depth = <15>;
status = "disabled";
@@ -219,8 +219,8 @@
reg = <0x02030000 0x4000>;
interrupts = <0 48 0x04>;
clocks = <&clks IMX6SL_CLK_SSI3>;
- dmas = <&sdma 45 1 0>,
- <&sdma 46 1 0>;
+ dmas = <&sdma 45 22 0>,
+ <&sdma 46 22 0>;
dma-names = "rx", "tx";
fsl,fifo-depth = <15>;
status = "disabled";
--
1.8.4
^ permalink raw reply related
* [PATCH v7 3/4] ASoC: fsl_ssi: Add dual fifo mode support
From: Nicolin Chen @ 2013-11-13 14:55 UTC (permalink / raw)
To: vinod.koul, dan.j.williams, s.hauer, timur, shawn.guo, broonie
Cc: mark.rutland, devicetree, alsa-devel, pawel.moll, linux-doc,
swarren, linux-kernel, rob.herring, dmaengine, ijc+devicetree,
linuxppc-dev, linux-arm-kernel
In-Reply-To: <cover.1384352281.git.b42378@freescale.com>
By enabling dual fifo mode, it would allow SSI enter a better performance
to transimit/receive data without occasional hardware underrun/overrun.
Signed-off-by: Nicolin Chen <b42378@freescale.com>
Acked-by: Timur Tabi <timur@tabi.org>
Acked-by: Mark Brown <broonie@linaro.org>
---
sound/soc/fsl/fsl_ssi.c | 27 ++++++++++++++++++++++++++-
1 file changed, 26 insertions(+), 1 deletion(-)
diff --git a/sound/soc/fsl/fsl_ssi.c b/sound/soc/fsl/fsl_ssi.c
index 35e2773..f43be6d 100644
--- a/sound/soc/fsl/fsl_ssi.c
+++ b/sound/soc/fsl/fsl_ssi.c
@@ -143,6 +143,7 @@ struct fsl_ssi_private {
bool ssi_on_imx;
bool imx_ac97;
bool use_dma;
+ bool use_dual_fifo;
struct clk *clk;
struct snd_dmaengine_dai_dma_data dma_params_tx;
struct snd_dmaengine_dai_dma_data dma_params_rx;
@@ -413,6 +414,12 @@ static int fsl_ssi_setup(struct fsl_ssi_private *ssi_private)
write_ssi(CCSR_SSI_SOR_WAIT(3), &ssi->sor);
}
+ if (ssi_private->use_dual_fifo) {
+ write_ssi_mask(&ssi->srcr, 0, CCSR_SSI_SRCR_RFEN1);
+ write_ssi_mask(&ssi->stcr, 0, CCSR_SSI_STCR_TFEN1);
+ write_ssi_mask(&ssi->scr, 0, CCSR_SSI_SCR_TCH_EN);
+ }
+
return 0;
}
@@ -480,6 +487,15 @@ static int fsl_ssi_startup(struct snd_pcm_substream *substream,
ssi_private->second_stream = substream;
}
+ /* When using dual fifo mode, it is safer to ensure an even period
+ * size. If appearing to an odd number while DMA always starts its
+ * task from fifo0, fifo1 would be neglected at the end of each
+ * period. But SSI would still access fifo1 with an invalid data.
+ */
+ if (ssi_private->use_dual_fifo)
+ snd_pcm_hw_constraint_step(substream->runtime, 0,
+ SNDRV_PCM_HW_PARAM_PERIOD_SIZE, 2);
+
return 0;
}
@@ -947,7 +963,7 @@ static int fsl_ssi_probe(struct platform_device *pdev)
ssi_private->fifo_depth = 8;
if (of_device_is_compatible(pdev->dev.of_node, "fsl,imx21-ssi")) {
- u32 dma_events[2];
+ u32 dma_events[2], dmas[4];
ssi_private->ssi_on_imx = true;
ssi_private->clk = devm_clk_get(&pdev->dev, NULL);
@@ -1001,6 +1017,15 @@ static int fsl_ssi_probe(struct platform_device *pdev)
dma_events[0], shared ? IMX_DMATYPE_SSI_SP : IMX_DMATYPE_SSI);
imx_pcm_dma_params_init_data(&ssi_private->filter_data_rx,
dma_events[1], shared ? IMX_DMATYPE_SSI_SP : IMX_DMATYPE_SSI);
+ if (!of_property_read_u32_array(pdev->dev.of_node, "dmas", dmas, 4)
+ && dmas[2] == IMX_DMATYPE_SSI_DUAL) {
+ ssi_private->use_dual_fifo = true;
+ /* When using dual fifo mode, we need to keep watermark
+ * as even numbers due to dma script limitation.
+ */
+ ssi_private->dma_params_tx.maxburst &= ~0x1;
+ ssi_private->dma_params_rx.maxburst &= ~0x1;
+ }
} else if (ssi_private->use_dma) {
/* The 'name' should not have any slashes in it. */
ret = devm_request_irq(&pdev->dev, ssi_private->irq,
--
1.8.4
^ permalink raw reply related
* [PATCH v7 2/4] dma: imx-sdma: Add new dma type for ssi dual fifo script
From: Nicolin Chen @ 2013-11-13 14:55 UTC (permalink / raw)
To: vinod.koul, dan.j.williams, s.hauer, timur, shawn.guo, broonie
Cc: mark.rutland, devicetree, alsa-devel, pawel.moll, linux-doc,
swarren, linux-kernel, rob.herring, dmaengine, ijc+devicetree,
linuxppc-dev, linux-arm-kernel
In-Reply-To: <cover.1384352281.git.b42378@freescale.com>
This patch adds a new DMA_TYPE for SSI dual FIFO script, included
in SDMA firmware version 2. This script would allow SSI use dual
fifo mode to transimit/receive data without occasional hardware
underrun/overrun.
Signed-off-by: Nicolin Chen <b42378@freescale.com>
Acked-by: Kumar Gala <galak@codeaurora.org>
Acked-by: Sascha Hauer <s.hauer@pengutronix.de>
---
Documentation/devicetree/bindings/dma/fsl-imx-sdma.txt | 1 +
drivers/dma/imx-sdma.c | 4 ++++
include/linux/platform_data/dma-imx.h | 1 +
3 files changed, 6 insertions(+)
diff --git a/Documentation/devicetree/bindings/dma/fsl-imx-sdma.txt b/Documentation/devicetree/bindings/dma/fsl-imx-sdma.txt
index 4fa814d..68b83ec 100644
--- a/Documentation/devicetree/bindings/dma/fsl-imx-sdma.txt
+++ b/Documentation/devicetree/bindings/dma/fsl-imx-sdma.txt
@@ -42,6 +42,7 @@ The full ID of peripheral types can be found below.
19 IPU Memory
20 ASRC
21 ESAI
+ 22 SSI Dual FIFO (needs firmware ver >= 2)
The third cell specifies the transfer priority as below.
diff --git a/drivers/dma/imx-sdma.c b/drivers/dma/imx-sdma.c
index 43a8441..efe9d6a 100644
--- a/drivers/dma/imx-sdma.c
+++ b/drivers/dma/imx-sdma.c
@@ -725,6 +725,10 @@ static void sdma_get_pc(struct sdma_channel *sdmac,
per_2_emi = sdma->script_addrs->app_2_mcu_addr;
emi_2_per = sdma->script_addrs->mcu_2_app_addr;
break;
+ case IMX_DMATYPE_SSI_DUAL:
+ per_2_emi = sdma->script_addrs->ssish_2_mcu_addr;
+ emi_2_per = sdma->script_addrs->mcu_2_ssish_addr;
+ break;
case IMX_DMATYPE_SSI_SP:
case IMX_DMATYPE_MMC:
case IMX_DMATYPE_SDHC:
diff --git a/include/linux/platform_data/dma-imx.h b/include/linux/platform_data/dma-imx.h
index beac6b8..bcbc6c3 100644
--- a/include/linux/platform_data/dma-imx.h
+++ b/include/linux/platform_data/dma-imx.h
@@ -39,6 +39,7 @@ enum sdma_peripheral_type {
IMX_DMATYPE_IPU_MEMORY, /* IPU Memory */
IMX_DMATYPE_ASRC, /* ASRC */
IMX_DMATYPE_ESAI, /* ESAI */
+ IMX_DMATYPE_SSI_DUAL, /* SSI Dual FIFO */
};
enum imx_dma_prio {
--
1.8.4
^ permalink raw reply related
* [PATCH v7 1/4] dma: imx-sdma: Add sdma firmware version 2 support
From: Nicolin Chen @ 2013-11-13 14:55 UTC (permalink / raw)
To: vinod.koul, dan.j.williams, s.hauer, timur, shawn.guo, broonie
Cc: mark.rutland, devicetree, alsa-devel, pawel.moll, linux-doc,
swarren, linux-kernel, rob.herring, dmaengine, ijc+devicetree,
linuxppc-dev, linux-arm-kernel
In-Reply-To: <cover.1384352281.git.b42378@freescale.com>
On i.MX5/6 series, SDMA is using new version firmware to support SSI
dual FIFO feature and HDMI Audio (i.MX6Q/DL only). Thus add it.
Signed-off-by: Nicolin Chen <b42378@freescale.com>
Acked-by: Sascha Hauer <s.hauer@pengutronix.de>
---
drivers/dma/imx-sdma.c | 15 ++++++++++++++-
include/linux/platform_data/dma-imx-sdma.h | 5 +++++
2 files changed, 19 insertions(+), 1 deletion(-)
diff --git a/drivers/dma/imx-sdma.c b/drivers/dma/imx-sdma.c
index fc43603..43a8441 100644
--- a/drivers/dma/imx-sdma.c
+++ b/drivers/dma/imx-sdma.c
@@ -323,6 +323,7 @@ struct sdma_engine {
struct clk *clk_ipg;
struct clk *clk_ahb;
spinlock_t channel_0_lock;
+ u32 script_number;
struct sdma_script_start_addrs *script_addrs;
const struct sdma_driver_data *drvdata;
};
@@ -1238,6 +1239,7 @@ static void sdma_issue_pending(struct dma_chan *chan)
}
#define SDMA_SCRIPT_ADDRS_ARRAY_SIZE_V1 34
+#define SDMA_SCRIPT_ADDRS_ARRAY_SIZE_V2 38
static void sdma_add_scripts(struct sdma_engine *sdma,
const struct sdma_script_start_addrs *addr)
@@ -1246,7 +1248,7 @@ static void sdma_add_scripts(struct sdma_engine *sdma,
s32 *saddr_arr = (u32 *)sdma->script_addrs;
int i;
- for (i = 0; i < SDMA_SCRIPT_ADDRS_ARRAY_SIZE_V1; i++)
+ for (i = 0; i < sdma->script_number; i++)
if (addr_arr[i] > 0)
saddr_arr[i] = addr_arr[i];
}
@@ -1272,6 +1274,17 @@ static void sdma_load_firmware(const struct firmware *fw, void *context)
goto err_firmware;
if (header->ram_code_start + header->ram_code_size > fw->size)
goto err_firmware;
+ switch (header->version_major) {
+ case 1:
+ sdma->script_number = SDMA_SCRIPT_ADDRS_ARRAY_SIZE_V1;
+ break;
+ case 2:
+ sdma->script_number = SDMA_SCRIPT_ADDRS_ARRAY_SIZE_V2;
+ break;
+ default:
+ dev_err(sdma->dev, "unknown firmware version\n");
+ goto err_firmware;
+ }
addr = (void *)header + header->script_addrs_start;
ram_code = (void *)header + header->ram_code_start;
diff --git a/include/linux/platform_data/dma-imx-sdma.h b/include/linux/platform_data/dma-imx-sdma.h
index 3a39428..eabac4e 100644
--- a/include/linux/platform_data/dma-imx-sdma.h
+++ b/include/linux/platform_data/dma-imx-sdma.h
@@ -43,6 +43,11 @@ struct sdma_script_start_addrs {
s32 dptc_dvfs_addr;
s32 utra_addr;
s32 ram_code_start_addr;
+ /* End of v1 array */
+ s32 mcu_2_ssish_addr;
+ s32 ssish_2_mcu_addr;
+ s32 hdmi_dma_addr;
+ /* End of v2 array */
};
/**
--
1.8.4
^ permalink raw reply related
* [PATCH v7 0/4] Add dual-fifo mode support of i.MX ssi
From: Nicolin Chen @ 2013-11-13 14:55 UTC (permalink / raw)
To: vinod.koul, dan.j.williams, s.hauer, timur, shawn.guo, broonie
Cc: mark.rutland, devicetree, alsa-devel, pawel.moll, linux-doc,
swarren, linux-kernel, rob.herring, dmaengine, ijc+devicetree,
linuxppc-dev, linux-arm-kernel
* ! This series of patches has a direct dependency between them. When
* ! applying them, we need to apply to one single branch. Otherwise,
* ! it would break currect branches.
Changelog
v7:
* Appended missing Acked-by to all four patches.
* Sorry that I didn't add them at the first place.
v6:
* PATCH-1: Use goto err_firmware instead of return directly.
*
* Nothing changes for the other three ack-ed patches
v5:
* PATCH-3: Add period size constraint when using dual fifo mode
*
* Nothing changes for the other three patches
v4:
* PATCH-3: Drop useless register configuration.
*
* Nothing changes for the other three patches
v3:
* PATCH-1: Add comments to indicate the end of v1 and v2 array.
* PATCH-3: Use better way to keep watermark as even number.
*
* Nothing changes for PATCH-2 and PATCH-4
v2:
* Instead of adding rogue scripts to current SDMA driver based on firmware
* V1, we define the new SDMA firmware as version 2 and bisect the PATCH-1
* to two patches: The first is to add version check code to the SDMA driver;
* And the second is to add SSI dual FIFO DMATYPE.
*
* Nothing changes for the last two patches.
v1:
* SSI can reduce hardware overrun/underrun possibility when using dual
* fifo mode. To support this mode, we need to first update sdma sciprt
* list, and then enable dual fifo BIT in SSI driver, and last update DT
* bindings of i.MX series.
Nicolin Chen (4):
dma: imx-sdma: Add sdma firmware version 2 support
dma: imx-sdma: Add new dma type for ssi dual fifo script
ASoC: fsl_ssi: Add dual fifo mode support
ARM: dts: imx: use dual-fifo sdma script for ssi
.../devicetree/bindings/dma/fsl-imx-sdma.txt | 1 +
arch/arm/boot/dts/imx51.dtsi | 4 ++--
arch/arm/boot/dts/imx53.dtsi | 4 ++--
arch/arm/boot/dts/imx6qdl.dtsi | 12 +++++-----
arch/arm/boot/dts/imx6sl.dtsi | 12 +++++-----
drivers/dma/imx-sdma.c | 19 ++++++++++++++-
include/linux/platform_data/dma-imx-sdma.h | 5 ++++
include/linux/platform_data/dma-imx.h | 1 +
sound/soc/fsl/fsl_ssi.c | 27 +++++++++++++++++++++-
9 files changed, 67 insertions(+), 18 deletions(-)
--
1.8.4
^ permalink raw reply
* Re: Problem reading and programming memory location...
From: neorf3k @ 2013-11-13 13:48 UTC (permalink / raw)
To: Anatolij Gustschin; +Cc: Linux Ppc Dev List Dev List
In-Reply-To: <20131113083259.1b69ed18@crub>
Yes, that is a device on the lpb via an fpga. We have tried to =
configure the chip select 4 configuration register at address MBAR + =
0x0310, and it seems to be ok. what do you mean with =93chip select =
parameters=94?
We have been able to edit it in U-BOOT, and the board (that chip) now =
works=85
The strange thing, is that when we read in linux, at that address, we =
see other content value=85
Suggestions?
Thanks
Lorenzo
On 13/nov/2013, at 08:32 AM, Anatolij Gustschin <agust@denx.de> wrote:
> On Tue, 12 Nov 2013 20:23:20 +0100
> neorf3k <neorf3k@gmail.com> wrote:
>=20
>> we have tried to read and program an 8bit register with 32bit =
address.
>> we have mapped it with: ioremap, kmalloc etc=85 and then using: outb,
>> iowrite8 etc.. but when we write to it, the value doesn=92t change=85
>> with other memory location is ok.
>> That is an 8 bit register, located at 0x10020000 in a mpc5200b
>> architecture. we are using kernel 2.6.33.=20
>> what could be?
>=20
> 0x10020000 is not in the internal register memory map, so it
> is probably a device on the LocalPlus bus. Did you configure
> the chip select parameters for this device and did you enable
> the associated chip select?
>=20
> HTH,
>=20
> Anatolij
>=20
^ permalink raw reply
* RE: [PATCH 2/4] phylib: Add generic 10G driver
From: Shaohui Xie @ 2013-11-13 11:56 UTC (permalink / raw)
To: Florian Fainelli, shh.xie@gmail.com
Cc: Shruti Kanetkar, linuxppc-dev, linux-kernel@vger.kernel.org,
Madalin-Cristian Bucur
In-Reply-To: <CAGVrzcZa2-yduRDxwGnYeoLJcRFjDr9OHtkUReAPF0cDseamJg@mail.gmail.com>
SGVsbG8sIEZsb3JpYW4sDQoNClRoYW5rIHlvdSBmb3IgcmV2aWV3aW5nIHRoZSBwYXRjaGVzIQ0K
UGxlYXNlIHNlZSBteSBjb21tZW50cyBpbmxpbmUuDQoNCkJlc3QgUmVnYXJkcywgDQpTaGFvaHVp
IFhpZQ0KDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogRmxvcmlhbiBG
YWluZWxsaSBbbWFpbHRvOmYuZmFpbmVsbGlAZ21haWwuY29tXQ0KPiBTZW50OiBXZWRuZXNkYXks
IE5vdmVtYmVyIDEzLCAyMDEzIDE6NTQgQU0NCj4gVG86IHNoaC54aWVAZ21haWwuY29tDQo+IENj
OiBsaW51eHBwYy1kZXY7IGxpbnV4LWtlcm5lbEB2Z2VyLmtlcm5lbC5vcmc7IEJ1Y3VyIE1hZGFs
aW4tQ3Jpc3RpYW4tDQo+IEIzMjcxNjsgS2FuZXRrYXIgU2hydXRpLUI0NDQ1NDsgWGllIFNoYW9o
dWktQjIxOTg5DQo+IFN1YmplY3Q6IFJlOiBbUEFUQ0ggMi80XSBwaHlsaWI6IEFkZCBnZW5lcmlj
IDEwRyBkcml2ZXINCj4gDQo+IEhlbGxvIFNoYW9odWksDQo+IA0KPiAyMDEzLzExLzExICA8c2ho
LnhpZUBnbWFpbC5jb20+Og0KPiA+IEZyb206IEFuZHkgRmxlbWluZw0KPiA+DQo+ID4gVmVyeSBp
bmNvbXBsZXRlLCBidXQgd2lsbCBhbGxvdyBmb3IgYmluZGluZyBhbiBldGhlcm5ldCBjb250cm9s
bGVyIHRvDQo+ID4gaXQuDQo+ID4NCj4gPiBBbHNvLCBBZGQgWEdNSUkgaW50ZXJmYWNlIHR5cGUN
Cj4gDQo+IFNvIHRoYXQgc2hvdWxkIGJlIHR3byBzZXBhcmF0ZSBwYXRjaGVzLCBhbmQNCj4gZHJp
dmVycy9vZi9vZl9uZXQuYzo6b2ZfZ2V0X3BoeV9tb2RlKCkgbXVzdCBiZSB1cGRhdGVkIHRvIGtu
b3cgYWJvdXQNCj4gWE1HSUkuDQo+IA0KPiA+DQo+ID4gU2lnbmVkLW9mZi1ieTogQW5keSBGbGVt
aW5nDQo+IA0KPiBNaXNzaW5nIEFuZHkncyBTaWduZWQtb2ZmLWJ5IHRhZy4NCltTLkhdIFdpbGwg
YWRkIGluIG5leHQgdmVyc2lvbiwgSSByZW1vdmVkIGl0IHRvIG1ha2UgZ2l0IHdvcmsgc2luY2Ug
QW5keSdzIGUtbWFpbCBhZGRyZXNzIGlzIG5vdCB2YWxpZC4NCg0KPiANCj4gPiBTaWduZWQtb2Zm
LWJ5OiBTaGFvaHVpIFhpZSA8U2hhb2h1aS5YaWVAZnJlZXNjYWxlLmNvbT4NCj4gPiAtLS0NCj4g
PiAgZHJpdmVycy9uZXQvcGh5L3BoeV9kZXZpY2UuYyB8IDEwMQ0KPiArKysrKysrKysrKysrKysr
KysrKysrKysrKysrKysrKysrKysrKysrKystDQo+ID4gIGluY2x1ZGUvbGludXgvcGh5LmggICAg
ICAgICAgfCAgIDEgKw0KPiA+ICAyIGZpbGVzIGNoYW5nZWQsIDEwMSBpbnNlcnRpb25zKCspLCAx
IGRlbGV0aW9uKC0pDQo+ID4NCj4gPiBkaWZmIC0tZ2l0IGEvZHJpdmVycy9uZXQvcGh5L3BoeV9k
ZXZpY2UuYw0KPiA+IGIvZHJpdmVycy9uZXQvcGh5L3BoeV9kZXZpY2UuYyBpbmRleCA3NDYzMGU5
Li4zMGJmMmQ1IDEwMDY0NA0KPiA+IC0tLSBhL2RyaXZlcnMvbmV0L3BoeS9waHlfZGV2aWNlLmMN
Cj4gPiArKysgYi9kcml2ZXJzL25ldC9waHkvcGh5X2RldmljZS5jDQo+ID4gQEAgLTMyLDYgKzMy
LDcgQEANCj4gPiAgI2luY2x1ZGUgPGxpbnV4L21vZHVsZS5oPg0KPiA+ICAjaW5jbHVkZSA8bGlu
dXgvbWlpLmg+DQo+ID4gICNpbmNsdWRlIDxsaW51eC9ldGh0b29sLmg+DQo+ID4gKyNpbmNsdWRl
IDxsaW51eC9tZGlvLmg+DQo+ID4gICNpbmNsdWRlIDxsaW51eC9waHkuaD4NCj4gPg0KPiA+ICAj
aW5jbHVkZSA8YXNtL2lvLmg+DQo+ID4gQEAgLTY4OSw2ICs2OTAsMTMgQEAgc3RhdGljIGludCBn
ZW5waHlfY29uZmlnX2FkdmVydChzdHJ1Y3QgcGh5X2RldmljZQ0KPiAqcGh5ZGV2KQ0KPiA+ICAg
ICAgICAgcmV0dXJuIGNoYW5nZWQ7DQo+ID4gIH0NCj4gPg0KPiA+ICtpbnQgZ2VuMTBnX2NvbmZp
Z19hZHZlcnQoc3RydWN0IHBoeV9kZXZpY2UgKmRldikgew0KPiA+ICsgICAgICAgcmV0dXJuIDA7
DQo+ID4gK30NCj4gPiArRVhQT1JUX1NZTUJPTChnZW4xMGdfY29uZmlnX2FkdmVydCk7DQo+ID4g
Kw0KPiA+ICsNCj4gPiAgLyoqDQo+ID4gICAqIGdlbnBoeV9zZXR1cF9mb3JjZWQgLSBjb25maWd1
cmVzL2ZvcmNlcyBzcGVlZC9kdXBsZXggZnJvbSBAcGh5ZGV2DQo+ID4gICAqIEBwaHlkZXY6IHRh
cmdldCBwaHlfZGV2aWNlIHN0cnVjdA0KPiA+IEBAIC03NDIsNiArNzUwLDEyIEBAIGludCBnZW5w
aHlfcmVzdGFydF9hbmVnKHN0cnVjdCBwaHlfZGV2aWNlDQo+ID4gKnBoeWRldikgIH0gIEVYUE9S
VF9TWU1CT0woZ2VucGh5X3Jlc3RhcnRfYW5lZyk7DQo+ID4NCj4gPiAraW50IGdlbjEwZ19yZXN0
YXJ0X2FuZWcoc3RydWN0IHBoeV9kZXZpY2UgKnBoeWRldikgew0KPiA+ICsgICAgICAgcmV0dXJu
IDA7DQo+ID4gK30NCj4gPiArRVhQT1JUX1NZTUJPTChnZW4xMGdfcmVzdGFydF9hbmVnKTsNCj4g
PiArDQo+ID4NCj4gPiAgLyoqDQo+ID4gICAqIGdlbnBoeV9jb25maWdfYW5lZyAtIHJlc3RhcnQg
YXV0by1uZWdvdGlhdGlvbiBvciB3cml0ZSBCTUNSIEBADQo+ID4gLTc4NCw2ICs3OTgsMTMgQEAg
aW50IGdlbnBoeV9jb25maWdfYW5lZyhzdHJ1Y3QgcGh5X2RldmljZSAqcGh5ZGV2KSAgfQ0KPiA+
IEVYUE9SVF9TWU1CT0woZ2VucGh5X2NvbmZpZ19hbmVnKTsNCj4gPg0KPiA+ICtpbnQgZ2VuMTBn
X2NvbmZpZ19hbmVnKHN0cnVjdCBwaHlfZGV2aWNlICpwaHlkZXYpIHsNCj4gPiArICAgICAgIHJl
dHVybiAwOw0KPiA+ICt9DQo+ID4gK0VYUE9SVF9TWU1CT0woZ2VuMTBnX2NvbmZpZ19hbmVnKTsN
Cj4gPiArDQo+ID4gKw0KPiA+ICAvKioNCj4gPiAgICogZ2VucGh5X3VwZGF0ZV9saW5rIC0gdXBk
YXRlIGxpbmsgc3RhdHVzIGluIEBwaHlkZXYNCj4gPiAgICogQHBoeWRldjogdGFyZ2V0IHBoeV9k
ZXZpY2Ugc3RydWN0DQo+ID4gQEAgLTkxMyw2ICs5MzQsMzUgQEAgaW50IGdlbnBoeV9yZWFkX3N0
YXR1cyhzdHJ1Y3QgcGh5X2RldmljZSAqcGh5ZGV2KQ0KPiA+IH0gIEVYUE9SVF9TWU1CT0woZ2Vu
cGh5X3JlYWRfc3RhdHVzKTsNCj4gPg0KPiA+ICtpbnQgZ2VuMTBnX3JlYWRfc3RhdHVzKHN0cnVj
dCBwaHlfZGV2aWNlICpwaHlkZXYpIHsNCj4gPiArICAgICAgIGludCBkZXZhZCwgcmVnOw0KPiA+
ICsgICAgICAgdTMyIG1tZF9tYXNrID0gcGh5ZGV2LT5jNDVfaWRzLmRldmljZXNfaW5fcGFja2Fn
ZTsNCj4gPiArDQo+ID4gKyAgICAgICBwaHlkZXYtPmxpbmsgPSAxOw0KPiA+ICsNCj4gPiArICAg
ICAgIC8qIEZvciBub3cganVzdCBsaWUgYW5kIHNheSBpdCdzIDEwRyBhbGwgdGhlIHRpbWUgKi8N
Cj4gPiArICAgICAgIHBoeWRldi0+c3BlZWQgPSAxMDAwMDsNCj4gDQo+IENhbiB5b3UgYXQgbGVh
c3QgbWFrZSB0aGlzIGEgbGl0dGxlIG1vcmUgcHJvb2Y/IFNvbWV0aGluZyBhbG9uZzoNCj4gDQo+
IGlmIChwaHlkZXYtPnN1cHBvcnRlZCAmIChTVVBQT1JURURfMTAwMDBiYXNlVF9GdWxsKSkNCj4g
ICAgICAgICAgICAgcGh5ZGV2LT5zcGVlZCA9IFNQRUVEXzEwMDAwOyBlbHNlIGlmIChwaHlkZXYt
PnN1cHBvcnRlZCAmDQo+IChTVVBQT1JURURfMTAwMGJhc2VUX0Z1bGwpDQo+ICAgICAgICAgICAg
IHBoeWRldi0+c3BlZWQgPSBTUEVFRF8xMDAwOw0KW1MuSF0gc29tZSAxMEcgUEhZIG9ubHkgc3Vw
cG9ydCAxMEcgc3BlZWQuDQoNCj4gDQo+IEFsdGhvdWdoIGlkZWFsbHkgd2Ugc2hvdWxkIGJlIHJl
YWRpbmcgdGhlIHJlbGV2YW50IHJlZ2lzdGVycyB0byBmaWd1cmUNCj4gb3V0IHdoYXQgdG8gZG8u
DQpbUy5IXSBZZXMsIGNvZGUgYmVsb3cgd2lsbCB0cnkgdG8gcmVhZCB0aGUgbW1kcyB0byBnZXQg
c3RhdHVzLg0KDQo+IA0KPiA+ICsgICAgICAgcGh5ZGV2LT5kdXBsZXggPSBEVVBMRVhfRlVMTDsN
Cj4gPiArDQo+ID4gKyAgICAgICBmb3IgKGRldmFkID0gMDsgbW1kX21hc2s7IGRldmFkKyssIG1t
ZF9tYXNrID0gbW1kX21hc2sgPj4gMSkgew0KPiA+ICsgICAgICAgICAgICAgICBpZiAoIShtbWRf
bWFzayAmIDEpKQ0KPiA+ICsgICAgICAgICAgICAgICAgICAgICAgIGNvbnRpbnVlOw0KPiA+ICsN
Cj4gPiArICAgICAgICAgICAgICAgLyogUmVhZCB0d2ljZSBiZWNhdXNlIGxpbmsgc3RhdGUgaXMg
bGF0Y2hlZCBhbmQgYQ0KPiA+ICsgICAgICAgICAgICAgICAgKiByZWFkIG1vdmVzIHRoZSBjdXJy
ZW50IHN0YXRlIGludG8gdGhlIHJlZ2lzdGVyDQo+ID4gKyAgICAgICAgICAgICAgICAqLw0KPiA+
ICsgICAgICAgICAgICAgICBwaHlfcmVhZF9tbWQocGh5ZGV2LCBkZXZhZCwgTURJT19TVEFUMSk7
DQo+ID4gKyAgICAgICAgICAgICAgIHJlZyA9IHBoeV9yZWFkX21tZChwaHlkZXYsIGRldmFkLCBN
RElPX1NUQVQxKTsNCj4gPiArICAgICAgICAgICAgICAgaWYgKHJlZyA8IDAgfHwgIShyZWcgJiBN
RElPX1NUQVQxX0xTVEFUVVMpKQ0KPiA+ICsgICAgICAgICAgICAgICAgICAgICAgIHBoeWRldi0+
bGluayA9IDA7DQo+ID4gKyAgICAgICB9DQo+ID4gKw0KPiA+ICsgICAgICAgcmV0dXJuIDA7DQo+
ID4gK30NCj4gPiArRVhQT1JUX1NZTUJPTChnZW4xMGdfcmVhZF9zdGF0dXMpOw0KPiA+ICsNCj4g
PiArDQo+ID4gIHN0YXRpYyBpbnQgZ2VucGh5X2NvbmZpZ19pbml0KHN0cnVjdCBwaHlfZGV2aWNl
ICpwaHlkZXYpICB7DQo+ID4gICAgICAgICBpbnQgdmFsOw0KPiA+IEBAIC05NTksNiArMTAwOSwx
NSBAQCBzdGF0aWMgaW50IGdlbnBoeV9jb25maWdfaW5pdChzdHJ1Y3QgcGh5X2RldmljZQ0KPiA+
ICpwaHlkZXYpDQo+ID4NCj4gPiAgICAgICAgIHJldHVybiAwOw0KPiA+ICB9DQo+ID4gKw0KPiA+
ICtzdGF0aWMgaW50IGdlbjEwZ19jb25maWdfaW5pdChzdHJ1Y3QgcGh5X2RldmljZSAqcGh5ZGV2
KSB7DQo+ID4gKyAgICAgICAvKiBUZW1wb3JhcmlseSBqdXN0IHNheSB3ZSBzdXBwb3J0IGV2ZXJ5
dGhpbmcgKi8NCj4gPiArICAgICAgIHBoeWRldi0+c3VwcG9ydGVkID0gcGh5ZGV2LT5hZHZlcnRp
c2luZyA9DQo+ID4gK1NVUFBPUlRFRF8xMDAwMGJhc2VUX0Z1bGw7DQo+IA0KPiBGb3IgY29uc2lz
dGVuY3kgeW91IHNob3VsZCBzZXQgU1VQUE9SVEVEX1RQLCAxMDAwYmFzZVRfRnVsbCBkb2VzIG5v
dCBtYWtlDQo+IHNlbnNlIGZvciBhbnl0aGluZyBidXQgdHdpc3RlZCBwYWlycyBBRkFJUi4NCltT
LkhdIE9LLg0KDQo+IA0KPiA+ICsNCj4gPiArICAgICAgIHJldHVybiAwOw0KPiA+ICt9DQo+ID4g
Kw0KPiA+ICBpbnQgZ2VucGh5X3N1c3BlbmQoc3RydWN0IHBoeV9kZXZpY2UgKnBoeWRldikgIHsN
Cj4gPiAgICAgICAgIGludCB2YWx1ZTsNCj4gPiBAQCAtOTc0LDYgKzEwMzMsMTMgQEAgaW50IGdl
bnBoeV9zdXNwZW5kKHN0cnVjdCBwaHlfZGV2aWNlICpwaHlkZXYpICB9DQo+ID4gRVhQT1JUX1NZ
TUJPTChnZW5waHlfc3VzcGVuZCk7DQo+ID4NCj4gPiAraW50IGdlbjEwZ19zdXNwZW5kKHN0cnVj
dCBwaHlfZGV2aWNlICpwaHlkZXYpIHsNCj4gPiArICAgICAgIHJldHVybiAwOw0KPiA+ICt9DQo+
ID4gK0VYUE9SVF9TWU1CT0woZ2VuMTBnX3N1c3BlbmQpOw0KPiA+ICsNCj4gPiArDQo+ID4gIGlu
dCBnZW5waHlfcmVzdW1lKHN0cnVjdCBwaHlfZGV2aWNlICpwaHlkZXYpICB7DQo+ID4gICAgICAg
ICBpbnQgdmFsdWU7DQo+ID4gQEAgLTk4OSw2ICsxMDU1LDEzIEBAIGludCBnZW5waHlfcmVzdW1l
KHN0cnVjdCBwaHlfZGV2aWNlICpwaHlkZXYpICB9DQo+ID4gRVhQT1JUX1NZTUJPTChnZW5waHlf
cmVzdW1lKTsNCj4gPg0KPiA+ICtpbnQgZ2VuMTBnX3Jlc3VtZShzdHJ1Y3QgcGh5X2RldmljZSAq
cGh5ZGV2KSB7DQo+ID4gKyAgICAgICByZXR1cm4gMDsNCj4gPiArfQ0KPiA+ICtFWFBPUlRfU1lN
Qk9MKGdlbjEwZ19yZXN1bWUpOw0KPiA+ICsNCj4gPiArDQo+ID4gIC8qKg0KPiA+ICAgKiBwaHlf
cHJvYmUgLSBwcm9iZSBhbmQgaW5pdCBhIFBIWSBkZXZpY2UNCj4gPiAgICogQGRldjogZGV2aWNl
IHRvIHByb2JlIGFuZCBpbml0DQo+ID4gQEAgLTExMjksNiArMTIwMiwyMCBAQCBzdGF0aWMgc3Ry
dWN0IHBoeV9kcml2ZXIgZ2VucGh5X2RyaXZlciA9IHsNCj4gPiAgICAgICAgIC5kcml2ZXIgICAg
ICAgICA9IHsub3duZXI9IFRISVNfTU9EVUxFLCB9LA0KPiA+ICB9Ow0KPiA+DQo+ID4gK3N0YXRp
YyBzdHJ1Y3QgcGh5X2RyaXZlciBnZW4xMGdfZHJpdmVyID0gew0KPiA+ICsgICAgICAgLnBoeV9p
ZCAgICAgICAgID0gMHhmZmZmZmZmZiwNCj4gPiArICAgICAgIC5waHlfaWRfbWFzayAgICA9IDB4
ZmZmZmZmZmYsDQo+ID4gKyAgICAgICAubmFtZSAgICAgICAgICAgPSAiR2VuZXJpYyAxMEcgUEhZ
IiwNCj4gPiArICAgICAgIC5jb25maWdfaW5pdCAgICA9IGdlbjEwZ19jb25maWdfaW5pdCwNCj4g
PiArICAgICAgIC5mZWF0dXJlcyAgICAgICA9IDAsDQo+IA0KPiBUaGlzIHNob3VsZCBiZSB1cGRh
dGVkIHRvIGJlIFBIWV8xMEdCSVRfRkVBVFVSRVMgd2hlcmUNCj4gUEhZXzEwR0JJVF9GRUFUVVJF
UyBpcyBkZWZpbmVkIHRvIGNvbnRhaW4gYXQgbGVhc3QgUEhZX0dCSVRfRkVBVFVSRVMuDQpbUy5I
XSBmb3IgYSBnZW5lcmljIDEwRyBQSFksIHdoYXQgaXMgdGhlIGZlYXR1cmUgc2hvdWxkIGJlIHN1
cHBvcnRlZD8NCg0KPiANCj4gPiArICAgICAgIC5jb25maWdfYW5lZyAgICA9IGdlbjEwZ19jb25m
aWdfYW5lZywNCj4gPiArICAgICAgIC5yZWFkX3N0YXR1cyAgICA9IGdlbjEwZ19yZWFkX3N0YXR1
cywNCj4gPiArICAgICAgIC5zdXNwZW5kICAgICAgICA9IGdlbjEwZ19zdXNwZW5kLA0KPiA+ICsg
ICAgICAgLnJlc3VtZSAgICAgICAgID0gZ2VuMTBnX3Jlc3VtZSwNCj4gPiArICAgICAgIC5kcml2
ZXIgICAgICAgICA9IHsub3duZXIgPSBUSElTX01PRFVMRSwgfSwNCj4gPiArfTsNCj4gPiArDQo+
ID4gKw0KPiA+ICBzdGF0aWMgaW50IF9faW5pdCBwaHlfaW5pdCh2b2lkKQ0KPiA+ICB7DQo+ID4g
ICAgICAgICBpbnQgcmM7DQo+ID4gQEAgLTExMzksMTMgKzEyMjYsMjUgQEAgc3RhdGljIGludCBf
X2luaXQgcGh5X2luaXQodm9pZCkNCj4gPg0KPiA+ICAgICAgICAgcmMgPSBwaHlfZHJpdmVyX3Jl
Z2lzdGVyKCZnZW5waHlfZHJpdmVyKTsNCj4gPiAgICAgICAgIGlmIChyYykNCj4gPiAtICAgICAg
ICAgICAgICAgbWRpb19idXNfZXhpdCgpOw0KPiA+ICsgICAgICAgICAgICAgICBnb3RvIGdlbnBo
eV9yZWdpc3Rlcl9mYWlsZWQ7DQo+ID4gKw0KPiA+ICsgICAgICAgcmMgPSBwaHlfZHJpdmVyX3Jl
Z2lzdGVyKCZnZW4xMGdfZHJpdmVyKTsNCj4gPiArICAgICAgIGlmIChyYykNCj4gPiArICAgICAg
ICAgICAgICAgZ290byBnZW4xMGdfcmVnaXN0ZXJfZmFpbGVkOw0KPiA+ICsNCj4gPiArICAgICAg
IHJldHVybiByYzsNCj4gPiArDQo+ID4gK2dlbjEwZ19yZWdpc3Rlcl9mYWlsZWQ6DQo+ID4gKyAg
ICAgICBwaHlfZHJpdmVyX3VucmVnaXN0ZXIoJmdlbnBoeV9kcml2ZXIpOw0KPiA+ICtnZW5waHlf
cmVnaXN0ZXJfZmFpbGVkOg0KPiA+ICsgICAgICAgbWRpb19idXNfZXhpdCgpOw0KPiANCj4gQXMg
YSBzdWJzZXF1ZW50IHBhdGNoIHlvdSBjb3VsZCB1c2UgcGh5X2RyaXZlcnNfcmVnaXN0ZXIoKQ0K
W1MuSF0geW91IG1lYW4gbGlrZSBwaHlfZHJpdmVyc19yZWdpc3RlcihnZW4xMGdfZHJpdmVyLCBB
UlJBWV9TSVpFKGdlbjEwZ19kcml2ZXIpKT8NCg==
^ permalink raw reply
* Re: [PATCH v11 0/3] DMA: Freescale: Add support for 8-channel DMA engine
From: Hongbo Zhang @ 2013-11-13 9:54 UTC (permalink / raw)
To: Vinod Koul
Cc: mark.rutland, devicetree, ian.campbell, pawel.moll, swarren,
linux-kernel, rob.herring, djbw, linuxppc-dev
In-Reply-To: <20131113085705.GR8834@intel.com>
On 11/13/2013 04:57 PM, Vinod Koul wrote:
> On Thu, Sep 26, 2013 at 05:33:40PM +0800, hongbo.zhang@freescale.com wrote:
>> From: Hongbo Zhang <hongbo.zhang@freescale.com>
>>
>> Hi DMA and DT maintainers, please have a look at these V11 patches.
>>
>> Freescale QorIQ T4 and B4 introduce new 8-channel DMA engines, this patch set
>> adds support this DMA engine.
>>
> Applied all
Thanks.
> Thanks
> ~Vinod
>
^ permalink raw reply
* Re: [PATCH v11 0/3] DMA: Freescale: Add support for 8-channel DMA engine
From: Vinod Koul @ 2013-11-13 8:57 UTC (permalink / raw)
To: hongbo.zhang
Cc: mark.rutland, devicetree, ian.campbell, pawel.moll, swarren,
linux-kernel, rob.herring, djbw, linuxppc-dev
In-Reply-To: <1380188023-3936-1-git-send-email-hongbo.zhang@freescale.com>
On Thu, Sep 26, 2013 at 05:33:40PM +0800, hongbo.zhang@freescale.com wrote:
> From: Hongbo Zhang <hongbo.zhang@freescale.com>
>
> Hi DMA and DT maintainers, please have a look at these V11 patches.
>
> Freescale QorIQ T4 and B4 introduce new 8-channel DMA engines, this patch set
> adds support this DMA engine.
>
Applied all
Thanks
~Vinod
^ permalink raw reply
* RE: [PATCH v9] PPC: POWERNV: move iommu_add_device earlier
From: Bharat Bhushan @ 2013-11-13 9:19 UTC (permalink / raw)
To: Alexey Kardashevskiy, linuxppc-dev@lists.ozlabs.org, Alex Graf
Cc: linux-kernel@vger.kernel.org
In-Reply-To: <1384324220-30109-1-git-send-email-aik@ozlabs.ru>
> -----Original Message-----
> From: Alexey Kardashevskiy [mailto:aik@ozlabs.ru]
> Sent: Wednesday, November 13, 2013 12:00 PM
> To: linuxppc-dev@lists.ozlabs.org
> Cc: Alexey Kardashevskiy; Benjamin Herrenschmidt; Bhushan Bharat-R65777; =
Alex
> Graf; linux-kernel@vger.kernel.org
> Subject: [PATCH v9] PPC: POWERNV: move iommu_add_device earlier
>=20
> The current implementation of IOMMU on sPAPR does not use iommu_ops
> and therefore does not call IOMMU API's bus_set_iommu() which
> 1) sets iommu_ops for a bus
> 2) registers a bus notifier
> Instead, PCI devices are added to IOMMU groups from
> subsys_initcall_sync(tce_iommu_init) which does basically the same
> thing without using iommu_ops callbacks.
>=20
> However Freescale PAMU driver (https://lkml.org/lkml/2013/7/1/158)
> implements iommu_ops and when tce_iommu_init is called, every PCI device
> is already added to some group so there is a conflict.
>=20
> This patch does 2 things:
> 1. removes the loop in which PCI devices were added to groups and
> adds explicit iommu_add_device() calls to add devices as soon as they get
> the iommu_table pointer assigned to them.
> 2. moves a bus notifier to powernv code in order to avoid conflict with
> the notifier from Freescale driver.
>=20
> iommu_add_device() and iommu_del_device() are public now.
>=20
> Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
Tested-by: Bharat Bhushan <bharat.bhushan@freescale.com>
> ---
> Changes:
> v9:
> * removed "KVM" from the subject as it is not really a KVM patch so
> PPC mainainter (hi Ben!) can review/include it into his tree
>=20
> v8:
> * added the check for iommu_group!=3DNULL before removing device from a g=
roup
> as suggested by Wei Yang <weiyang@linux.vnet.ibm.com>
>=20
> v2:
> * added a helper - set_iommu_table_base_and_group - which does
> set_iommu_table_base() and iommu_add_device()
> ---
> arch/powerpc/include/asm/iommu.h | 9 +++++++
> arch/powerpc/kernel/iommu.c | 41 +++--------------------=
------
> arch/powerpc/platforms/powernv/pci-ioda.c | 8 +++---
> arch/powerpc/platforms/powernv/pci-p5ioc2.c | 2 +-
> arch/powerpc/platforms/powernv/pci.c | 33 ++++++++++++++++++++++-
> arch/powerpc/platforms/pseries/iommu.c | 8 +++---
> 6 files changed, 55 insertions(+), 46 deletions(-)
>=20
> diff --git a/arch/powerpc/include/asm/iommu.h b/arch/powerpc/include/asm/=
iommu.h
> index c34656a..19ad77f 100644
> --- a/arch/powerpc/include/asm/iommu.h
> +++ b/arch/powerpc/include/asm/iommu.h
> @@ -103,6 +103,15 @@ extern struct iommu_table *iommu_init_table(struct
> iommu_table * tbl,
> int nid);
> extern void iommu_register_group(struct iommu_table *tbl,
> int pci_domain_number, unsigned long pe_num);
> +extern int iommu_add_device(struct device *dev);
> +extern void iommu_del_device(struct device *dev);
> +
> +static inline void set_iommu_table_base_and_group(struct device *dev,
> + void *base)
> +{
> + set_iommu_table_base(dev, base);
> + iommu_add_device(dev);
> +}
>=20
> extern int iommu_map_sg(struct device *dev, struct iommu_table *tbl,
> struct scatterlist *sglist, int nelems,
> diff --git a/arch/powerpc/kernel/iommu.c b/arch/powerpc/kernel/iommu.c
> index 572bb5b..ecbf468 100644
> --- a/arch/powerpc/kernel/iommu.c
> +++ b/arch/powerpc/kernel/iommu.c
> @@ -1105,7 +1105,7 @@ void iommu_release_ownership(struct iommu_table *tb=
l)
> }
> EXPORT_SYMBOL_GPL(iommu_release_ownership);
>=20
> -static int iommu_add_device(struct device *dev)
> +int iommu_add_device(struct device *dev)
> {
> struct iommu_table *tbl;
> int ret =3D 0;
> @@ -1134,46 +1134,13 @@ static int iommu_add_device(struct device *dev)
>=20
> return ret;
> }
> +EXPORT_SYMBOL_GPL(iommu_add_device);
>=20
> -static void iommu_del_device(struct device *dev)
> +void iommu_del_device(struct device *dev)
> {
> iommu_group_remove_device(dev);
> }
> -
> -static int iommu_bus_notifier(struct notifier_block *nb,
> - unsigned long action, void *data)
> -{
> - struct device *dev =3D data;
> -
> - switch (action) {
> - case BUS_NOTIFY_ADD_DEVICE:
> - return iommu_add_device(dev);
> - case BUS_NOTIFY_DEL_DEVICE:
> - iommu_del_device(dev);
> - return 0;
> - default:
> - return 0;
> - }
> -}
> -
> -static struct notifier_block tce_iommu_bus_nb =3D {
> - .notifier_call =3D iommu_bus_notifier,
> -};
> -
> -static int __init tce_iommu_init(void)
> -{
> - struct pci_dev *pdev =3D NULL;
> -
> - BUILD_BUG_ON(PAGE_SIZE < IOMMU_PAGE_SIZE);
> -
> - for_each_pci_dev(pdev)
> - iommu_add_device(&pdev->dev);
> -
> - bus_register_notifier(&pci_bus_type, &tce_iommu_bus_nb);
> - return 0;
> -}
> -
> -subsys_initcall_sync(tce_iommu_init);
> +EXPORT_SYMBOL_GPL(iommu_del_device);
>=20
> #else
>=20
> diff --git a/arch/powerpc/platforms/powernv/pci-ioda.c
> b/arch/powerpc/platforms/powernv/pci-ioda.c
> index 084cdfa..614356c 100644
> --- a/arch/powerpc/platforms/powernv/pci-ioda.c
> +++ b/arch/powerpc/platforms/powernv/pci-ioda.c
> @@ -460,7 +460,7 @@ static void pnv_pci_ioda_dma_dev_setup(struct pnv_phb=
*phb,
> struct pci_dev *pdev
> return;
>=20
> pe =3D &phb->ioda.pe_array[pdn->pe_number];
> - set_iommu_table_base(&pdev->dev, &pe->tce32_table);
> + set_iommu_table_base_and_group(&pdev->dev, &pe->tce32_table);
> }
>=20
> static void pnv_ioda_setup_bus_dma(struct pnv_ioda_pe *pe, struct pci_bu=
s *bus)
> @@ -468,7 +468,7 @@ static void pnv_ioda_setup_bus_dma(struct pnv_ioda_pe=
*pe,
> struct pci_bus *bus)
> struct pci_dev *dev;
>=20
> list_for_each_entry(dev, &bus->devices, bus_list) {
> - set_iommu_table_base(&dev->dev, &pe->tce32_table);
> + set_iommu_table_base_and_group(&dev->dev, &pe->tce32_table);
> if (dev->subordinate)
> pnv_ioda_setup_bus_dma(pe, dev->subordinate);
> }
> @@ -644,7 +644,7 @@ static void pnv_pci_ioda_setup_dma_pe(struct pnv_phb =
*phb,
> iommu_register_group(tbl, pci_domain_nr(pe->pbus), pe->pe_number);
>=20
> if (pe->pdev)
> - set_iommu_table_base(&pe->pdev->dev, tbl);
> + set_iommu_table_base_and_group(&pe->pdev->dev, tbl);
> else
> pnv_ioda_setup_bus_dma(pe, pe->pbus);
>=20
> @@ -722,7 +722,7 @@ static void pnv_pci_ioda2_setup_dma_pe(struct pnv_phb=
*phb,
> iommu_init_table(tbl, phb->hose->node);
>=20
> if (pe->pdev)
> - set_iommu_table_base(&pe->pdev->dev, tbl);
> + set_iommu_table_base_and_group(&pe->pdev->dev, tbl);
> else
> pnv_ioda_setup_bus_dma(pe, pe->pbus);
>=20
> diff --git a/arch/powerpc/platforms/powernv/pci-p5ioc2.c
> b/arch/powerpc/platforms/powernv/pci-p5ioc2.c
> index f8b4bd8..e3807d6 100644
> --- a/arch/powerpc/platforms/powernv/pci-p5ioc2.c
> +++ b/arch/powerpc/platforms/powernv/pci-p5ioc2.c
> @@ -92,7 +92,7 @@ static void pnv_pci_p5ioc2_dma_dev_setup(struct pnv_phb=
*phb,
> pci_domain_nr(phb->hose->bus), phb->opal_id);
> }
>=20
> - set_iommu_table_base(&pdev->dev, &phb->p5ioc2.iommu_table);
> + set_iommu_table_base_and_group(&pdev->dev, &phb->p5ioc2.iommu_table);
> }
>=20
> static void __init pnv_pci_init_p5ioc2_phb(struct device_node *np, u64 h=
ub_id,
> diff --git a/arch/powerpc/platforms/powernv/pci.c
> b/arch/powerpc/platforms/powernv/pci.c
> index 4eb33a9..6f3d49c 100644
> --- a/arch/powerpc/platforms/powernv/pci.c
> +++ b/arch/powerpc/platforms/powernv/pci.c
> @@ -536,7 +536,7 @@ static void pnv_pci_dma_fallback_setup(struct pci_con=
troller
> *hose,
> pdn->iommu_table =3D pnv_pci_setup_bml_iommu(hose);
> if (!pdn->iommu_table)
> return;
> - set_iommu_table_base(&pdev->dev, pdn->iommu_table);
> + set_iommu_table_base_and_group(&pdev->dev, pdn->iommu_table);
> }
>=20
> static void pnv_pci_dma_dev_setup(struct pci_dev *pdev)
> @@ -657,3 +657,34 @@ void __init pnv_pci_init(void)
> ppc_md.teardown_msi_irqs =3D pnv_teardown_msi_irqs;
> #endif
> }
> +
> +static int tce_iommu_bus_notifier(struct notifier_block *nb,
> + unsigned long action, void *data)
> +{
> + struct device *dev =3D data;
> +
> + switch (action) {
> + case BUS_NOTIFY_ADD_DEVICE:
> + return iommu_add_device(dev);
> + case BUS_NOTIFY_DEL_DEVICE:
> + if (dev->iommu_group)
> + iommu_del_device(dev);
> + return 0;
> + default:
> + return 0;
> + }
> +}
> +
> +static struct notifier_block tce_iommu_bus_nb =3D {
> + .notifier_call =3D tce_iommu_bus_notifier,
> +};
> +
> +static int __init tce_iommu_bus_notifier_init(void)
> +{
> + BUILD_BUG_ON(PAGE_SIZE < IOMMU_PAGE_SIZE);
> +
> + bus_register_notifier(&pci_bus_type, &tce_iommu_bus_nb);
> + return 0;
> +}
> +
> +subsys_initcall_sync(tce_iommu_bus_notifier_init);
> diff --git a/arch/powerpc/platforms/pseries/iommu.c
> b/arch/powerpc/platforms/pseries/iommu.c
> index f253361..a80af6c 100644
> --- a/arch/powerpc/platforms/pseries/iommu.c
> +++ b/arch/powerpc/platforms/pseries/iommu.c
> @@ -687,7 +687,8 @@ static void pci_dma_dev_setup_pSeries(struct pci_dev =
*dev)
> iommu_table_setparms(phb, dn, tbl);
> PCI_DN(dn)->iommu_table =3D iommu_init_table(tbl, phb->node);
> iommu_register_group(tbl, pci_domain_nr(phb->bus), 0);
> - set_iommu_table_base(&dev->dev, PCI_DN(dn)->iommu_table);
> + set_iommu_table_base_and_group(&dev->dev,
> + PCI_DN(dn)->iommu_table);
> return;
> }
>=20
> @@ -699,7 +700,8 @@ static void pci_dma_dev_setup_pSeries(struct pci_dev =
*dev)
> dn =3D dn->parent;
>=20
> if (dn && PCI_DN(dn))
> - set_iommu_table_base(&dev->dev, PCI_DN(dn)->iommu_table);
> + set_iommu_table_base_and_group(&dev->dev,
> + PCI_DN(dn)->iommu_table);
> else
> printk(KERN_WARNING "iommu: Device %s has no iommu table\n",
> pci_name(dev));
> @@ -1193,7 +1195,7 @@ static void pci_dma_dev_setup_pSeriesLP(struct pci_=
dev
> *dev)
> pr_debug(" found DMA window, table: %p\n", pci->iommu_table);
> }
>=20
> - set_iommu_table_base(&dev->dev, pci->iommu_table);
> + set_iommu_table_base_and_group(&dev->dev, pci->iommu_table);
> }
>=20
> static int dma_set_mask_pSeriesLP(struct device *dev, u64 dma_mask)
> --
> 1.8.4.rc4
>=20
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox