* Re: [PATCH V2] powerpc/85xx: Merge 85xx/p1023_defconfig into mpc85xx_smp_defconfig and mpc85xx_defconfig
From: Scott Wood @ 2013-11-12 23:09 UTC (permalink / raw)
To: Zang Roy-R61911; +Cc: Pan Lijun-B44306, linuxppc-dev@ozlabs.org
In-Reply-To: <3E027F8168735B46AC006B1D0C7BB0020B37817C@039-SN2MPN1-011.039d.mgd.msft.net>
On Tue, 2013-11-12 at 17:05 -0600, Zang Roy-R61911 wrote:
>
> > -----Original Message-----
> > From: Wood Scott-B07421
> > Sent: Tuesday, November 12, 2013 4:52 PM
> > To: Zang Roy-R61911
> > Cc: Pan Lijun-B44306; linuxppc-dev@ozlabs.org
> > Subject: Re: [PATCH V2] powerpc/85xx: Merge 85xx/p1023_defconfig into
> > mpc85xx_smp_defconfig and mpc85xx_defconfig
> >
> > On Tue, 2013-11-12 at 16:49 -0600, Zang Roy-R61911 wrote:
> > >
> > > > -----Original Message-----
> > > > From: Linuxppc-dev [mailto:linuxppc-dev-bounces+tie-
> > > > fei.zang=freescale.com@lists.ozlabs.org] On Behalf Of Scott Wood
> > > > Sent: Tuesday, November 12, 2013 4:05 PM
> > > > To: Pan Lijun-B44306
> > > > Cc: linuxppc-dev@ozlabs.org
> > > > Subject: Re: [PATCH V2] powerpc/85xx: Merge 85xx/p1023_defconfig
> > > > into mpc85xx_smp_defconfig and mpc85xx_defconfig
> > > >
> > > > 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.
> > > P1023 has dpaa.
> > > Will mpc85xx_defconfig or mpc85xx_smp_defconfig support dpaa?
> >
> > That's the question I'm asking. Though I suppose we could take a patch
> > like this one for now, and then introduce mpc85xx_dpaa_defconfig when it
> > becomes relevant (which would make clear why the defconfig is separate).
> > p1023 would still work with the non-dpaa defconfigs, but without dpaa
> > support.
>
> It will be hard to find a seat for P1023 in mpc85xx_dpaa_defconfig.
What do you mean?
> P1023 does not have corenet. It has e500v2 core.
> All the other DPAA SOCs have corenet.
> I suggest leaving p1023 defconfig standalone.
I didn't say "mpc85xx_corenet_defconfig", nor did I suggest that
mpc85xx_dpaa_defconfig replace corenet32_defconfig. Perhaps
e500v2_dpaa_defconfig would be a better name. It would effectively be a
standalone p1023 defconfig, but with a name that reflects the reason for
it, and which would accommodate future e500v2 dpaa chips in the unlikely
case that such things are made.
Do you know how large the current SDK datapath code is? Though perhaps
the eventual upstream version will be smaller.
-Scott
^ 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 1:46 UTC (permalink / raw)
To: Emil Medve; +Cc: linuxppc-dev
In-Reply-To: <5282B277.4090300@Freescale.com>
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? Do we have any config fragments in the tree so far?
-Scott
^ permalink raw reply
* Re: [PATCH 1/3] powerpc/p1010rdb:add P1010RDB-PB platform support
From: Scott Wood @ 2013-11-13 1:50 UTC (permalink / raw)
To: Zhao Qiang; +Cc: tony, devicetree, linuxppc-dev, bcousson
In-Reply-To: <1383791369-29324-1-git-send-email-B45475@freescale.com>
On Thu, 2013-11-07 at 10:29 +0800, Zhao Qiang wrote:
> The P1010RDB-PB is similar to P1010RDB(P1010RDB-PA).
> So, P1010RDB-PB use the same platform file as P1010RDB.
> Then Add support for P1010RDB-PB platform.
>
> Signed-off-by: Zhao Qiang <B45475@freescale.com>
> ---
> arch/powerpc/platforms/85xx/p1010rdb.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/arch/powerpc/platforms/85xx/p1010rdb.c b/arch/powerpc/platforms/85xx/p1010rdb.c
> index 0252961..d6a3dd3 100644
> --- a/arch/powerpc/platforms/85xx/p1010rdb.c
> +++ b/arch/powerpc/platforms/85xx/p1010rdb.c
> @@ -66,6 +66,8 @@ static int __init p1010_rdb_probe(void)
>
> if (of_flat_dt_is_compatible(root, "fsl,P1010RDB"))
> return 1;
> + if (of_flat_dt_is_compatible(root, "fsl,P1010RDB-PB"))
> + return 1;
> return 0;
> }
>
This had already been merged into Ben's tree when you reposted it
(without any indication that it was a repost/respin), and is now in
Linus's tree.
-Scott
^ permalink raw reply
* RE: [PATCH 1/4] phylib: Add Clause 45 read/write functions
From: Shaohui Xie @ 2013-11-13 1:51 UTC (permalink / raw)
To: Scott Wood, shh.xie@gmail.com
Cc: Shruti Kanetkar, linuxppc-dev@lists.ozlabs.org,
linux-kernel@vger.kernel.org, Madalin-Cristian Bucur
In-Reply-To: <1384293487.1403.67.camel@snotra.buserror.net>
PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBXb29kIFNjb3R0LUIwNzQyMQ0K
PiBTZW50OiBXZWRuZXNkYXksIE5vdmVtYmVyIDEzLCAyMDEzIDU6NTggQU0NCj4gVG86IHNoaC54
aWVAZ21haWwuY29tDQo+IENjOiBsaW51eHBwYy1kZXZAbGlzdHMub3psYWJzLm9yZzsgbGludXgt
a2VybmVsQHZnZXIua2VybmVsLm9yZzsgS2FuZXRrYXINCj4gU2hydXRpLUI0NDQ1NDsgWGllIFNo
YW9odWktQjIxOTg5OyBCdWN1ciBNYWRhbGluLUNyaXN0aWFuLUIzMjcxNg0KPiBTdWJqZWN0OiBS
ZTogW1BBVENIIDEvNF0gcGh5bGliOiBBZGQgQ2xhdXNlIDQ1IHJlYWQvd3JpdGUgZnVuY3Rpb25z
DQo+IA0KPiBPbiBNb24sIDIwMTMtMTEtMTEgYXQgMTk6MDQgKzA4MDAsIHNoaC54aWVAZ21haWwu
Y29tIHdyb3RlOg0KPiA+IEZyb206IEFuZHkgRmxlbWluZw0KPiA+DQo+ID4gWW91IG5lZWQgYW4g
ZXh0cmEgcGFyYW1ldGVyIHRvIHJlYWQgb3Igd3JpdGUgQ2xhdXNlIDQ1IFBIWXMsIHNvIHdlDQo+
ID4gbmVlZCBhIGRpZmZlcmVudCBBUEkgd2l0aCB0aGUgZXh0cmEgcGFyYW1ldGVyLg0KPiA+DQo+
ID4gU2lnbmVkLW9mZi1ieTogQW5keSBGbGVtaW5nDQo+ID4gU2lnbmVkLW9mZi1ieTogU2hhb2h1
aSBYaWUgPFNoYW9odWkuWGllQGZyZWVzY2FsZS5jb20+DQo+IA0KPiBXaHkgZGlkIHlvdSByZW1v
dmUgQW5keSdzIGUtbWFpbCBhZGRyZXNzPyAgRXZlbiB0aG91Z2ggaXQncyBubyBsb25nZXIgdmFs
aWQsIGl0DQo+IGhlbHBzIGlkZW50aWZ5IHdoaWNoIHNwZWNpZmljIHBlcnNvbiB5b3UncmUgdGFs
a2luZyBhYm91dC4NCj4gDQpbUy5IXSBBbmR5J3MgZS1tYWlsIGFkZHJlc3MgaXMgbm90IHZhbGlk
IGFuZCBnaXQtc2VuZC1tYWlsIHdpbGwgZmFpbCwgSSBoYXZlIHRvIHJlbW92ZSBpdCB0byBtYWtl
IGdpdCB3b3JrLg0KDQoNCkJlc3QgUmVnYXJkcywgDQpTaGFvaHVpIFhpZQ0K
^ permalink raw reply
* Re: [PATCH 1/4] phylib: Add Clause 45 read/write functions
From: Scott Wood @ 2013-11-13 1:54 UTC (permalink / raw)
To: Xie Shaohui-B21989
Cc: shh.xie@gmail.com, Kanetkar Shruti-B44454,
linuxppc-dev@lists.ozlabs.org, linux-kernel@vger.kernel.org,
Bucur Madalin-Cristian-B32716
In-Reply-To: <ED492CCEAF882048BC2237DE806547C91512489F@039-SN2MPN1-013.039d.mgd.msft.net>
On Tue, 2013-11-12 at 19:51 -0600, Xie Shaohui-B21989 wrote:
> > -----Original Message-----
> > From: Wood Scott-B07421
> > Sent: Wednesday, November 13, 2013 5:58 AM
> > To: shh.xie@gmail.com
> > Cc: linuxppc-dev@lists.ozlabs.org; linux-kernel@vger.kernel.org; Kanetkar
> > Shruti-B44454; Xie Shaohui-B21989; Bucur Madalin-Cristian-B32716
> > Subject: Re: [PATCH 1/4] phylib: Add Clause 45 read/write functions
> >
> > On Mon, 2013-11-11 at 19:04 +0800, shh.xie@gmail.com wrote:
> > > From: Andy Fleming
> > >
> > > You need an extra parameter to read or write Clause 45 PHYs, so we
> > > need a different API with the extra parameter.
> > >
> > > Signed-off-by: Andy Fleming
> > > Signed-off-by: Shaohui Xie <Shaohui.Xie@freescale.com>
> >
> > Why did you remove Andy's e-mail address? Even though it's no longer valid, it
> > helps identify which specific person you're talking about.
> >
> [S.H] Andy's e-mail address is not valid and git-send-mail will fail, I have to remove it to make git work.
Tell git send-email to not include that address, e.g. using
--suppress-cc, --no-signed-off-by-cc, --suppress-from, etc.
-Scott
^ permalink raw reply
* Re: [PATCH 1/4] phylib: Add Clause 45 read/write functions
From: Emil Medve @ 2013-11-13 1:54 UTC (permalink / raw)
Cc: linuxppc-dev@lists.ozlabs.org, linux-kernel@vger.kernel.org
In-Reply-To: <ED492CCEAF882048BC2237DE806547C91512489F@039-SN2MPN1-013.039d.mgd.msft.net>
Hello Xiao-Hui,
On 11/12/2013 07:51 PM, Shaohui Xie wrote:
>> -----Original Message-----
>> From: Wood Scott-B07421
>> Sent: Wednesday, November 13, 2013 5:58 AM
>> To: shh.xie@gmail.com
>> Cc: linuxppc-dev@lists.ozlabs.org; linux-kernel@vger.kernel.org; Kanetkar
>> Shruti-B44454; Xie Shaohui-B21989; Bucur Madalin-Cristian-B32716
>> Subject: Re: [PATCH 1/4] phylib: Add Clause 45 read/write functions
>>
>> On Mon, 2013-11-11 at 19:04 +0800, shh.xie@gmail.com wrote:
>>> From: Andy Fleming
>>>
>>> You need an extra parameter to read or write Clause 45 PHYs, so we
>>> need a different API with the extra parameter.
>>>
>>> Signed-off-by: Andy Fleming
>>> Signed-off-by: Shaohui Xie <Shaohui.Xie@freescale.com>
>>
>> Why did you remove Andy's e-mail address? Even though it's no longer valid, it
>> helps identify which specific person you're talking about.
>>
> [S.H] Andy's e-mail address is not valid and git-send-mail will fail, I have to remove it to make git work.
Just use Andy's GMail address: afleming@gmail.com
Cheers,
^ permalink raw reply
* RE: [PATCH 1/4] phylib: Add Clause 45 read/write functions
From: Shaohui Xie @ 2013-11-13 2:01 UTC (permalink / raw)
To: Scott Wood
Cc: shh.xie@gmail.com, Shruti Kanetkar, linuxppc-dev@lists.ozlabs.org,
linux-kernel@vger.kernel.org, Madalin-Cristian Bucur
In-Reply-To: <1384307679.1403.122.camel@snotra.buserror.net>
PiBPbiBUdWUsIDIwMTMtMTEtMTIgYXQgMTk6NTEgLTA2MDAsIFhpZSBTaGFvaHVpLUIyMTk4OSB3
cm90ZToNCj4gPiA+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ID4gPiBGcm9tOiBXb29k
IFNjb3R0LUIwNzQyMQ0KPiA+ID4gU2VudDogV2VkbmVzZGF5LCBOb3ZlbWJlciAxMywgMjAxMyA1
OjU4IEFNDQo+ID4gPiBUbzogc2hoLnhpZUBnbWFpbC5jb20NCj4gPiA+IENjOiBsaW51eHBwYy1k
ZXZAbGlzdHMub3psYWJzLm9yZzsgbGludXgta2VybmVsQHZnZXIua2VybmVsLm9yZzsNCj4gPiA+
IEthbmV0a2FyIFNocnV0aS1CNDQ0NTQ7IFhpZSBTaGFvaHVpLUIyMTk4OTsgQnVjdXINCj4gPiA+
IE1hZGFsaW4tQ3Jpc3RpYW4tQjMyNzE2DQo+ID4gPiBTdWJqZWN0OiBSZTogW1BBVENIIDEvNF0g
cGh5bGliOiBBZGQgQ2xhdXNlIDQ1IHJlYWQvd3JpdGUgZnVuY3Rpb25zDQo+ID4gPg0KPiA+ID4g
T24gTW9uLCAyMDEzLTExLTExIGF0IDE5OjA0ICswODAwLCBzaGgueGllQGdtYWlsLmNvbSB3cm90
ZToNCj4gPiA+ID4gRnJvbTogQW5keSBGbGVtaW5nDQo+ID4gPiA+DQo+ID4gPiA+IFlvdSBuZWVk
IGFuIGV4dHJhIHBhcmFtZXRlciB0byByZWFkIG9yIHdyaXRlIENsYXVzZSA0NSBQSFlzLCBzbyB3
ZQ0KPiA+ID4gPiBuZWVkIGEgZGlmZmVyZW50IEFQSSB3aXRoIHRoZSBleHRyYSBwYXJhbWV0ZXIu
DQo+ID4gPiA+DQo+ID4gPiA+IFNpZ25lZC1vZmYtYnk6IEFuZHkgRmxlbWluZw0KPiA+ID4gPiBT
aWduZWQtb2ZmLWJ5OiBTaGFvaHVpIFhpZSA8U2hhb2h1aS5YaWVAZnJlZXNjYWxlLmNvbT4NCj4g
PiA+DQo+ID4gPiBXaHkgZGlkIHlvdSByZW1vdmUgQW5keSdzIGUtbWFpbCBhZGRyZXNzPyAgRXZl
biB0aG91Z2ggaXQncyBubw0KPiA+ID4gbG9uZ2VyIHZhbGlkLCBpdCBoZWxwcyBpZGVudGlmeSB3
aGljaCBzcGVjaWZpYyBwZXJzb24geW91J3JlIHRhbGtpbmcgYWJvdXQuDQo+ID4gPg0KPiA+IFtT
LkhdIEFuZHkncyBlLW1haWwgYWRkcmVzcyBpcyBub3QgdmFsaWQgYW5kIGdpdC1zZW5kLW1haWwg
d2lsbCBmYWlsLCBJIGhhdmUNCj4gdG8gcmVtb3ZlIGl0IHRvIG1ha2UgZ2l0IHdvcmsuDQo+IA0K
PiBUZWxsIGdpdCBzZW5kLWVtYWlsIHRvIG5vdCBpbmNsdWRlIHRoYXQgYWRkcmVzcywgZS5nLiB1
c2luZyAtLXN1cHByZXNzLWNjLCAtLW5vLQ0KPiBzaWduZWQtb2ZmLWJ5LWNjLCAtLXN1cHByZXNz
LWZyb20sIGV0Yy4NCj4gDQpbUy5IXSBPSy4gVGhhbmsgeW91IQ0KDQoNCkJlc3QgUmVnYXJkcywg
DQpTaGFvaHVpIFhpZQ0K
^ 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 2:34 UTC (permalink / raw)
Cc: linuxppc-dev
In-Reply-To: <1384307175.1403.118.camel__32063.4016803981$1384307228$gmane$org@snotra.buserror.net>
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
> 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
Cheers,
^ permalink raw reply
* RE: [PATCH] Add a vga alias node for P1022
From: Zhengxiong Jin @ 2013-11-13 6:28 UTC (permalink / raw)
To: Scott Wood, galak@kernel.crashing.org; +Cc: linuxppc-dev@lists.ozlabs.org
In-Reply-To: <1378459957-26334-1-git-send-email-Jason.Jin@freescale.com>
> -----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
>=20
> From: Jason Jin <Jason.jin@freescale.com>
>=20
> 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.
>=20
> 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.
^ permalink raw reply
* [PATCH v9] PPC: POWERNV: move iommu_add_device earlier
From: Alexey Kardashevskiy @ 2013-11-13 6:30 UTC (permalink / raw)
To: linuxppc-dev
Cc: Alexey Kardashevskiy, Alex Graf, Bharat Bhushan, linux-kernel
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.
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.
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.
iommu_add_device() and iommu_del_device() are public now.
Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
---
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
v8:
* added the check for iommu_group!=NULL before removing device from a group
as suggested by Wei Yang <weiyang@linux.vnet.ibm.com>
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(-)
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);
+}
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 *tbl)
}
EXPORT_SYMBOL_GPL(iommu_release_ownership);
-static int iommu_add_device(struct device *dev)
+int iommu_add_device(struct device *dev)
{
struct iommu_table *tbl;
int ret = 0;
@@ -1134,46 +1134,13 @@ static int iommu_add_device(struct device *dev)
return ret;
}
+EXPORT_SYMBOL_GPL(iommu_add_device);
-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 = 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 = {
- .notifier_call = iommu_bus_notifier,
-};
-
-static int __init tce_iommu_init(void)
-{
- struct pci_dev *pdev = 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);
#else
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;
pe = &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);
}
static void pnv_ioda_setup_bus_dma(struct pnv_ioda_pe *pe, struct pci_bus *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;
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);
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);
@@ -722,7 +722,7 @@ static void pnv_pci_ioda2_setup_dma_pe(struct pnv_phb *phb,
iommu_init_table(tbl, phb->hose->node);
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);
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);
}
- set_iommu_table_base(&pdev->dev, &phb->p5ioc2.iommu_table);
+ set_iommu_table_base_and_group(&pdev->dev, &phb->p5ioc2.iommu_table);
}
static void __init pnv_pci_init_p5ioc2_phb(struct device_node *np, u64 hub_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_controller *hose,
pdn->iommu_table = 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);
}
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 = pnv_teardown_msi_irqs;
#endif
}
+
+static int tce_iommu_bus_notifier(struct notifier_block *nb,
+ unsigned long action, void *data)
+{
+ struct device *dev = 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 = {
+ .notifier_call = 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 = 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;
}
@@ -699,7 +700,8 @@ static void pci_dma_dev_setup_pSeries(struct pci_dev *dev)
dn = dn->parent;
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);
}
- set_iommu_table_base(&dev->dev, pci->iommu_table);
+ set_iommu_table_base_and_group(&dev->dev, pci->iommu_table);
}
static int dma_set_mask_pSeriesLP(struct device *dev, u64 dma_mask)
--
1.8.4.rc4
^ permalink raw reply related
* Re: Problem reading and programming memory location...
From: Anatolij Gustschin @ 2013-11-13 7:32 UTC (permalink / raw)
To: neorf3k; +Cc: Linux Ppc Dev List Dev List
In-Reply-To: <985685C7-0122-4D45-96D1-4412E9774A5D@gmail.com>
On Tue, 12 Nov 2013 20:23:20 +0100
neorf3k <neorf3k@gmail.com> wrote:
> we have tried to read and program an 8bit register with 32bit address.
> we have mapped it with: ioremap, kmalloc etc=E2=80=A6 and then using: out=
b,
> iowrite8 etc.. but when we write to it, the value doesn=E2=80=99t change=
=E2=80=A6
> 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?
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,
Anatolij
^ permalink raw reply
* [patch] ALSA: snd-aoa: two copy and paste bugs
From: Dan Carpenter @ 2013-11-13 7:45 UTC (permalink / raw)
To: Johannes Berg
Cc: alsa-devel, Takashi Iwai, kernel-janitors, Jaroslav Kysela,
linuxppc-dev
These functions were cut and paste and the tests for NULL weren't
updated properly.
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
diff --git a/sound/aoa/fabrics/layout.c b/sound/aoa/fabrics/layout.c
index 61ab640..9dc5806 100644
--- a/sound/aoa/fabrics/layout.c
+++ b/sound/aoa/fabrics/layout.c
@@ -644,7 +644,7 @@ static int n##_control_put(struct snd_kcontrol *kcontrol, \
struct snd_ctl_elem_value *ucontrol) \
{ \
struct gpio_runtime *gpio = snd_kcontrol_chip(kcontrol); \
- if (gpio->methods && gpio->methods->get_##n) \
+ if (gpio->methods && gpio->methods->set_##n) \
gpio->methods->set_##n(gpio, \
!!ucontrol->value.integer.value[0]); \
return 1; \
@@ -1135,7 +1135,7 @@ static int aoa_fabric_layout_resume(struct soundbus_dev *sdev)
{
struct layout_dev *ldev = dev_get_drvdata(&sdev->ofdev.dev);
- if (ldev->gpio.methods && ldev->gpio.methods->all_amps_off)
+ if (ldev->gpio.methods && ldev->gpio.methods->all_amps_restore)
ldev->gpio.methods->all_amps_restore(&ldev->gpio);
return 0;
^ permalink raw reply related
* Re: [patch] ALSA: snd-aoa: two copy and paste bugs
From: Takashi Iwai @ 2013-11-13 8:29 UTC (permalink / raw)
To: Dan Carpenter
Cc: alsa-devel, kernel-janitors, Jaroslav Kysela, Johannes Berg,
linuxppc-dev
In-Reply-To: <20131113074520.GD25541@elgon.mountain>
At Wed, 13 Nov 2013 10:45:20 +0300,
Dan Carpenter wrote:
>
> These functions were cut and paste and the tests for NULL weren't
> updated properly.
>
> Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Thanks, applied.
Takashi
>
> diff --git a/sound/aoa/fabrics/layout.c b/sound/aoa/fabrics/layout.c
> index 61ab640..9dc5806 100644
> --- a/sound/aoa/fabrics/layout.c
> +++ b/sound/aoa/fabrics/layout.c
> @@ -644,7 +644,7 @@ static int n##_control_put(struct snd_kcontrol *kcontrol, \
> struct snd_ctl_elem_value *ucontrol) \
> { \
> struct gpio_runtime *gpio = snd_kcontrol_chip(kcontrol); \
> - if (gpio->methods && gpio->methods->get_##n) \
> + if (gpio->methods && gpio->methods->set_##n) \
> gpio->methods->set_##n(gpio, \
> !!ucontrol->value.integer.value[0]); \
> return 1; \
> @@ -1135,7 +1135,7 @@ static int aoa_fabric_layout_resume(struct soundbus_dev *sdev)
> {
> struct layout_dev *ldev = dev_get_drvdata(&sdev->ofdev.dev);
>
> - if (ldev->gpio.methods && ldev->gpio.methods->all_amps_off)
> + if (ldev->gpio.methods && ldev->gpio.methods->all_amps_restore)
> ldev->gpio.methods->all_amps_restore(&ldev->gpio);
>
> return 0;
>
^ permalink raw reply
* Re: [patch] ALSA: snd-aoa: two copy and paste bugs
From: Johannes Berg @ 2013-11-13 8:29 UTC (permalink / raw)
To: Takashi Iwai
Cc: alsa-devel, kernel-janitors, Jaroslav Kysela, linuxppc-dev,
Dan Carpenter
In-Reply-To: <s5h4n7gso19.wl%tiwai@suse.de>
On Wed, 2013-11-13 at 09:29 +0100, Takashi Iwai wrote:
> At Wed, 13 Nov 2013 10:45:20 +0300,
> Dan Carpenter wrote:
> >
> > These functions were cut and paste and the tests for NULL weren't
> > updated properly.
> >
> > Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
>
> Thanks, applied.
FWIW, looks fine to me - I wonder how long this has been broken though,
must be practically forever. I guess we never got it wrong and missed
adding some pointers? :-)
johannes
^ 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
* 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 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 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: 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
* [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
* [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 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 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 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
* 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
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