Re: [RFC PATCH v2 04/11] pstore: Add compression support to pstore
On Wednesday 04 September 2013 07:14 AM, Seiji Aguchi wrote: Aruna, Sorry for the late response. Seiji, Could you let us know the efivars buffer size with which the pstore is registered when the failure occurred. I looked into the issue today. I added some debug message just before pstore_compress(). As you can see below, the buffer size is a fixed value(1024). Therefore, the size doesn't seem to be related to the failure directly. Also, in the failure case, zlib_deflate() returns Z_OK and stream.avail_out is zero. So, I thought big_oops_buf_sz is too big in my environment. And then, I tuned big_oops_buf_sz to (psinfo->bufsize * 100) / 53. Seiji, Thank you for the analysis. The reason behind compression failure is the size of big_oops_buf which is too big for efivars case. I will do some experiments with different kind of texts for buffer size 1024 to check if 100/53 suits for all the cases. At the same time, while looking into this issue, I had two concerns about current cording. 1) In pstore_decompress(), why not use zlib_inflateInit2() instead of zlib_inflateInit()? If you use zlib_deflateInit2() for specifying window_bit at compressing time, zlib_inflateInit2() seems to be appropriate for decompressing. (Please see a comment about inflateInit2() in include/linux/zlib.h and source code of crypto/deflate.c) Yes this can be changed to zlib_inflateInit2(). 2) As looking at crypto/deflate.c, stream->workspace is kzalloced at the beginning of compressing/decompressing time. So, in pstore case, stream.workspace must be initialized to 0 with memset() in pstore_compress()/decompress(). Hmm.. I don't think this is a issue. If you see fs/logfs/compr.c from which I derived the compression algorithms for pstore as well, they have not initialized stream.workspace. Since the space will be overwritten during the calculation, I dont think it will matter. The above 2 things you have suggested are good to have. But the reason behind compression failure is the big_oops_buf_sz which is too big for efivars. I did three things above, tuning big_oops_buf_sz, using zlib_inflateInit2() and initializing stream.workspace , in my environment. As a result, compressions/decmpressions of all entries succeeded with efivars driver. Panic#2 Part1 <4>[ 75.665020] [] SyS_write+0x4c/0xa0 <4>[ 75.665020] [] system_call_fastpath+0x16/0x1b <4>[ 75.665020] Code: ef e8 ff f7 ff ff eb d8 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 00 0f 1f 44 00 00 55 c7 05 cc f3 c9 00 01 00 00 00 48 89 e5 0f ae f8 04 25 00 00 00 00 01 5d c3 0f 1f 44 00 00 55 31 c0 c7 05 5e <1>[ 75.665020] RIP [] sysrq_handle_crash+0x16/0x20 <4>[ 75.665020] RSP <4>[ 75.665020] CR2: <4>[ 75.665020] ---[ end trace 97bb4a1f8d3fe7b2 ]--- <3>[ 75.665020] pstore_dump hsize=13 len=2155 big_oops_buf_sz=2275 psinfo->bufsize=1024 <3>[ 75.665020] pstore_dump hsize=13 len=2246 big_oops_buf_sz=2275 psinfo->bufsize=1024 <3>[ 75.665020] pstore: compression failed for Part 2 returned -5 <3>[ 75.665020] pstore: Capture uncompressed oops/panic report of Part 2 <3>[ 75.665020] pstore_dump hsize=13 len=2239 big_oops_buf_sz=2275 psinfo->bufsize=1024 <3>[ 75.665020] pstore_dump hsize=13 len=2231 big_oops_buf_sz=2275 psinfo->bufsize=1024 <3>[ 75.665020] pstore_dump hsize=13 len=2185 big_oops_buf_sz=2275 psinfo->bufsize=1024 <3>[ 75.665020] pstore: compression failed for Part 5 returned -5 <3>[ 75.665020] pstore: Capture uncompressed oops/panic report of Part 5 <3>[ 75.665020] pstore_dump hsize=13 len=2234 big_oops_buf_sz=2275 psinfo->bufsize=1024 <3>[ 75.665020] pstore_dump hsize=13 len=2208 big_oops_buf_sz=2275 psinfo->bufsize=1024 <3>[ 75.665020] pstore_dump hsize=13 len=2218 big_oops_buf_sz=2275 psinfo->bufsize=1024 <3>[ 75.665020] pstore_dump hsize=13 len= big_oops_buf_sz=2275 psinfo->bufsize=1024 <3>[ 75.665020] pstore: compression failed for Part 9 returned -5 <3>[ 75.665020] pstore: Capture uncompressed oops/panic report of Part 9 <3>[ 75.665020] pstore_dump hsize=14 len=2256 big_oops_buf_sz=2275 psinfo->bufsize=1024 <3>[ 75.665020] pstore_dump hsize=14 len=2219 big_oops_buf_sz=2275 psinfo->bufsize=1024 <3>[ 75.665020] pstore_dump hsize=14 len=2226 big_oops_buf_sz=2275 psinfo->bufsize=1024 <0>[ 75.665020] Kernel panic - not syncing: Fatal exception <3>[ 75.665020] drm_kms_helper: panic occurred, switching back to text console Seiji ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] powerpc: Add I2C bus multiplexer node for B4 and T4240QDS
On 09/04/2013 12:03 PM, Tang Yuantian-B29983 wrote:
> Hi,
> I noticed that there are already some nodes in i2c bus.
Sorry for my late response, yeah, just as you noticed, some eeprom nodes
already are inside i2c bus.:-)
Wei
> You should at least move the existing node into PCA9547.
>
> Thanks,
> Yuantian
>
>
>> -Original Message-
>> From: Linuxppc-dev [mailto:linuxppc-dev-
>> bounces+b29983=freescale@lists.ozlabs.org] On Behalf Of Jia Hongtao-
>> B38951
>> Sent: 2013年9月4日 星期三 11:38
>> To: Yang,Wei
>> Cc: Wood Scott-B07421; linuxppc-dev@lists.ozlabs.org
>> Subject: RE: [PATCH] powerpc: Add I2C bus multiplexer node for B4 and
>> T4240QDS
>>
>> Hi Wei,
>>
>> I totally agree that the i2c nodes topology should end up like you said.
>>
>> But I think adding sub-nodes should step by step.
>> Actually the hardware i2c topology are huge like on T4.
>> So I'd like to adding nodes when we needed.
>> If you think the sub-nodes are needed please send another patch based on
>> mine.
>> I think this is the more reasonable way.
>>
>> Thanks.
>>
>> -Hongtao
>>
>>
>>> -Original Message-
>>> From: Yang,Wei [mailto:wei.y...@windriver.com]
>>> Sent: Wednesday, September 04, 2013 9:27 AM
>>> To: Jia Hongtao-B38951
>>> Cc: linuxppc-dev@lists.ozlabs.org; Wood Scott-B07421; Jia
>>> Hongtao-B38951
>>> Subject: Re: [PATCH] powerpc: Add I2C bus multiplexer node for B4 and
>>> T4240QDS
>>>
>>> On 09/03/2013 03:51 PM, Jia Hongtao wrote:
In both B4 and T4240QDS platform PCA9547 I2C bus multiplexer is used.
>>> Hi Hongtao,
>>>
>>> If you want to support I2C bus multiplexer, for T4 and B4QDS platform,
>>> since some eeprom devices is connected to PCA9574 I2C bus multiplexer,
>>> so these devices should be connected to pca9547 node. Just like the
>>> following, what do you think of it?
>>>
>>> + pca9547@77 {
>>> + compatible = "philips,pca9547";
>>> + reg = <0x77>;
>>> + #address-cells = <1>;
>>> + #size-cells = <0>;
>>> + channel@0 {
>>> + #address-cells = <1>;
>>> + #size-cells = <0>;
>>> + reg = <0>;
>>> + eeprom@51 {
>>> + compatible =
>>> "at24,24c256";
>>> + reg = <0x51>;
>>> + };
>>> + eeprom@52 {
>>> + compatible =
>>> "at24,24c256";
>>> + reg = <0x52>;
>>> + };
>>> + eeprom@53 {
>>> + compatible =
>>> "at24,24c256";
>>> + reg = <0x53>;
>>> + };
>>> + eeprom@54 {
>>> + compatible =
>>> "at24,24c256";
>>> + reg = <0x54>;
>>> + };
>>> + eeprom@55 {
>>> + compatible =
>>> "at24,24c256";
>>> + reg = <0x55>;
>>> + };
>>> + eeprom@56 {
>>> + compatible =
>>> "at24,24c256";
>>> + reg = <0x56>;
>>> + };
>>> + rtc@68 {
>>> + compatible =
>>> "dallas,ds3232";
>>> + reg = <0x68>;
>>> + interrupts =
>>> <0x1 0x1 0 0>;
>>> + };
>>> + };
>>>
>>> Wei
Signed-off-by: Jia Hongtao
---
arch/powerpc/boot/dts/b4qds.dtsi | 4
arch/powerpc/boot/dts/t4240qds.dts | 4
2 files changed, 8 insertions(+)
diff --git a/arch/powerpc/boot/dts/b4qds.dtsi
b/arch/powerpc/boot/dts/b4qds.dtsi
index e6d2f8f..2aa3399 100644
--- a/arch/powerpc/boot/dts/b4qds.dtsi
+++ b/arch/powerpc/boot/dts/b4qds.dtsi
@@ -120,6 +120,10 @@
};
i2c@118000 {
+ pca9547@77 {
+
RE: [PATCH] powerpc: Add I2C bus multiplexer node for B4 and T4240QDS
Hi Yuantian,
Yes, you are right.
Hi Wei,
I misunderstood your idea.
I agree it and I will submit V2 patch to update it soon.
Thanks.
-Hongtao
> -Original Message-
> From: Tang Yuantian-B29983
> Sent: Wednesday, September 04, 2013 12:04 PM
> To: Jia Hongtao-B38951; Yang,Wei
> Cc: Wood Scott-B07421; linuxppc-dev@lists.ozlabs.org
> Subject: RE: [PATCH] powerpc: Add I2C bus multiplexer node for B4 and
> T4240QDS
>
> Hi,
> I noticed that there are already some nodes in i2c bus.
> You should at least move the existing node into PCA9547.
>
> Thanks,
> Yuantian
>
>
> > -Original Message-
> > From: Linuxppc-dev [mailto:linuxppc-dev-
> > bounces+b29983=freescale@lists.ozlabs.org] On Behalf Of Jia
> > bounces+Hongtao-
> > B38951
> > Sent: 2013年9月4日 星期三 11:38
> > To: Yang,Wei
> > Cc: Wood Scott-B07421; linuxppc-dev@lists.ozlabs.org
> > Subject: RE: [PATCH] powerpc: Add I2C bus multiplexer node for B4 and
> > T4240QDS
> >
> > Hi Wei,
> >
> > I totally agree that the i2c nodes topology should end up like you said.
> >
> > But I think adding sub-nodes should step by step.
> > Actually the hardware i2c topology are huge like on T4.
> > So I'd like to adding nodes when we needed.
> > If you think the sub-nodes are needed please send another patch based
> > on mine.
> > I think this is the more reasonable way.
> >
> > Thanks.
> >
> > -Hongtao
> >
> >
> > > -Original Message-
> > > From: Yang,Wei [mailto:wei.y...@windriver.com]
> > > Sent: Wednesday, September 04, 2013 9:27 AM
> > > To: Jia Hongtao-B38951
> > > Cc: linuxppc-dev@lists.ozlabs.org; Wood Scott-B07421; Jia
> > > Hongtao-B38951
> > > Subject: Re: [PATCH] powerpc: Add I2C bus multiplexer node for B4
> > > and T4240QDS
> > >
> > > On 09/03/2013 03:51 PM, Jia Hongtao wrote:
> > > > In both B4 and T4240QDS platform PCA9547 I2C bus multiplexer is
> used.
> > >
> > > Hi Hongtao,
> > >
> > > If you want to support I2C bus multiplexer, for T4 and B4QDS
> > > platform, since some eeprom devices is connected to PCA9574 I2C bus
> > > multiplexer, so these devices should be connected to pca9547 node.
> > > Just like the following, what do you think of it?
> > >
> > > + pca9547@77 {
> > > + compatible = "philips,pca9547";
> > > + reg = <0x77>;
> > > + #address-cells = <1>;
> > > + #size-cells = <0>;
> > > + channel@0 {
> > > + #address-cells = <1>;
> > > + #size-cells = <0>;
> > > + reg = <0>;
> > > + eeprom@51 {
> > > + compatible =
> > > "at24,24c256";
> > > + reg = <0x51>;
> > > + };
> > > + eeprom@52 {
> > > + compatible =
> > > "at24,24c256";
> > > + reg = <0x52>;
> > > + };
> > > + eeprom@53 {
> > > + compatible =
> > > "at24,24c256";
> > > + reg = <0x53>;
> > > + };
> > > + eeprom@54 {
> > > + compatible =
> > > "at24,24c256";
> > > + reg = <0x54>;
> > > + };
> > > + eeprom@55 {
> > > + compatible =
> > > "at24,24c256";
> > > + reg = <0x55>;
> > > + };
> > > + eeprom@56 {
> > > + compatible =
> > > "at24,24c256";
> > > + reg = <0x56>;
> > > + };
> > > + rtc@68 {
> > > + compatible =
> > > "dallas,ds3232";
> > > + reg = <0x68>;
> > > + interrupts =
> > > <0x1 0x1 0 0>;
> > > + };
> > > + };
> > >
> > > Wei
> > > >
> > > > Signed-off-by: Jia Hongtao
> > > > ---
> > > > arch/powerpc/boot/dts/
RE: [PATCH] powerpc: Add I2C bus multiplexer node for B4 and T4240QDS
Hi,
I noticed that there are already some nodes in i2c bus.
You should at least move the existing node into PCA9547.
Thanks,
Yuantian
> -Original Message-
> From: Linuxppc-dev [mailto:linuxppc-dev-
> bounces+b29983=freescale@lists.ozlabs.org] On Behalf Of Jia Hongtao-
> B38951
> Sent: 2013年9月4日 星期三 11:38
> To: Yang,Wei
> Cc: Wood Scott-B07421; linuxppc-dev@lists.ozlabs.org
> Subject: RE: [PATCH] powerpc: Add I2C bus multiplexer node for B4 and
> T4240QDS
>
> Hi Wei,
>
> I totally agree that the i2c nodes topology should end up like you said.
>
> But I think adding sub-nodes should step by step.
> Actually the hardware i2c topology are huge like on T4.
> So I'd like to adding nodes when we needed.
> If you think the sub-nodes are needed please send another patch based on
> mine.
> I think this is the more reasonable way.
>
> Thanks.
>
> -Hongtao
>
>
> > -Original Message-
> > From: Yang,Wei [mailto:wei.y...@windriver.com]
> > Sent: Wednesday, September 04, 2013 9:27 AM
> > To: Jia Hongtao-B38951
> > Cc: linuxppc-dev@lists.ozlabs.org; Wood Scott-B07421; Jia
> > Hongtao-B38951
> > Subject: Re: [PATCH] powerpc: Add I2C bus multiplexer node for B4 and
> > T4240QDS
> >
> > On 09/03/2013 03:51 PM, Jia Hongtao wrote:
> > > In both B4 and T4240QDS platform PCA9547 I2C bus multiplexer is used.
> >
> > Hi Hongtao,
> >
> > If you want to support I2C bus multiplexer, for T4 and B4QDS platform,
> > since some eeprom devices is connected to PCA9574 I2C bus multiplexer,
> > so these devices should be connected to pca9547 node. Just like the
> > following, what do you think of it?
> >
> > + pca9547@77 {
> > + compatible = "philips,pca9547";
> > + reg = <0x77>;
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > + channel@0 {
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > + reg = <0>;
> > + eeprom@51 {
> > + compatible =
> > "at24,24c256";
> > + reg = <0x51>;
> > + };
> > + eeprom@52 {
> > + compatible =
> > "at24,24c256";
> > + reg = <0x52>;
> > + };
> > + eeprom@53 {
> > + compatible =
> > "at24,24c256";
> > + reg = <0x53>;
> > + };
> > + eeprom@54 {
> > + compatible =
> > "at24,24c256";
> > + reg = <0x54>;
> > + };
> > + eeprom@55 {
> > + compatible =
> > "at24,24c256";
> > + reg = <0x55>;
> > + };
> > + eeprom@56 {
> > + compatible =
> > "at24,24c256";
> > + reg = <0x56>;
> > + };
> > + rtc@68 {
> > + compatible =
> > "dallas,ds3232";
> > + reg = <0x68>;
> > + interrupts =
> > <0x1 0x1 0 0>;
> > + };
> > + };
> >
> > Wei
> > >
> > > Signed-off-by: Jia Hongtao
> > > ---
> > > arch/powerpc/boot/dts/b4qds.dtsi | 4
> > > arch/powerpc/boot/dts/t4240qds.dts | 4
> > > 2 files changed, 8 insertions(+)
> > >
> > > diff --git a/arch/powerpc/boot/dts/b4qds.dtsi
> > > b/arch/powerpc/boot/dts/b4qds.dtsi
> > > index e6d2f8f..2aa3399 100644
> > > --- a/arch/powerpc/boot/dts/b4qds.dtsi
> > > +++ b/arch/powerpc/boot/dts/b4qds.dtsi
> > > @@ -120,6 +120,10 @@
> > > };
> > >
> > > i2c@118000 {
> > > + pca9547@77 {
> > > + compatible = "philips,pca9547";
> > > + reg = <0x77>;
> > > + };
> > > ee
Power PC Build problem
Hi everyone, I apologise if the question is inappropriate for this list but here goes. I'm using buildroot to build for an APC8272ADS (PPC 603e) chip with Intel/Sharp Memory chips on board. I have an old build of the kernel (2.6.18) that does appear to work correctly the relevant portion is -- Serial: CPM driver $Revision: 0.02 $ ttyCPM0 at MMIO 0xf0011a00 (irq = 40) is a CPM UART ttyCPM1 at MMIO 0xf0011a60 (irq = 43) is a CPM UART RAMDISK driver initialized: 16 RAM disks of 32768K size 1024 blocksize physmap platform flash device: 0100 at ff00 physmap-flash.0: Found 1 x16 devices at 0x0 in 16-bit bank Intel/Sharp Extended Query Table at 0x010A Intel/Sharp Extended Query Table at 0x010A Intel/Sharp Extended Query Table at 0x010A Intel/Sharp Extended Query Table at 0x010A Intel/Sharp Extended Query Table at 0x010A Using buffer write method cfi_cmdset_0001: Erase suspend on write enabled erase region 0: offset=0x0,size=0x8000,blocks=4 erase region 1: offset=0x2,size=0x2,blocks=127 3 cmdlinepart partitions found on MTD device physmap-flash.0 Creating 3 MTD partitions on "physmap-flash.0": 0x-0x0008 : "U-Boot" 0x0008-0x0018 : "Linux" 0x0018-0x0100 : "root" eth0: FCC ENET Version 0.3, de:ad:be:ef:12:34 --- But when I try building it with the latest buildroot (2013.08) and I configure the kernel (3.10.10) I get one of two things. If I don't include specific settings for physmap compat support (Device Drivers -> MTD Support -> Mapping drivers for chip access) then I get a kernel panic when it can't mount the root filesystem as follows --- Linux/PowerPC load: console=ttyCPM0,115200 root=31:02 rw rootfstype=jffs2 init=s mtdparts=physmap-flash.0:512k(U-Boot),3072k(Linux),-(root) ip=192.168.1.231:192.168.1.148::255.255.255.0:eclipse:eth0:on panic=1 Finalizing device tree... flat tree at 0x7f9420 Using Freescale MPC8272 ADS machine description Linux version 3.10.10 (jason@piDevel) (gcc version 4.7.3 (Buildroot 2013.08) ) #13 PREEMPT Wed Sep 4 10:47:47 EST 2013 PCI host bridge /pci@f0010800 (primary) ranges: MEM 0x8000..0x9fff -> 0x8000 Prefetch MEM 0xa000..0xbfff -> 0xa000 IO 0xf600..0xf7ff -> 0x Zone ranges: DMA [mem 0x-0x03ff] Normal empty Movable zone start for each node Early memory node ranges node 0: [mem 0x-0x03ff] Built 1 zonelists in Zone order, mobility grouping on. Total pages: 16256 Kernel command line: console=ttyCPM0,115200 root=31:02 rw rootfstype=jffs2 init=s mtdparts=physmap-flash.0:512k(U-Boot),3072k(Linux),-(root) ip=192.168.1.231:192.168.1.148::255.255.255.0:eclipse:eth0:on panic=1 PID hash table entries: 256 (order: -2, 1024 bytes) Dentry cache hash table entries: 8192 (order: 3, 32768 bytes) Inode-cache hash table entries: 4096 (order: 2, 16384 bytes) Sorting __ex_table... Memory: 60880k/65536k available (3760k kernel code, 4656k reserved, 144k data, 85k bss, 160k init) Kernel virtual memory layout: * 0xfffdf000..0xf000 : fixmap * 0xfcfb4000..0xfe00 : early ioremap * 0xc500..0xfcfb4000 : vmalloc & ioremap SLUB: HWalign=32, Order=0-3, MinObjects=0, CPUs=1, Nodes=1 Preemptible hierarchical RCU implementation. NR_IRQS:512 nr_irqs:512 16 clocksource: timebase mult[3c9b26ca] shift[24] registered console [ttyCPM0] enabled pid_max: default: 32768 minimum: 301 Mount-cache hash table entries: 512 devtmpfs: initialized NET: Registered protocol family 16 PCI: Probing PCI hardware PCI host bridge to bus :00 pci_bus :00: root bus resource [io 0x-0xff] pci_bus :00: root bus resource [mem 0x8000-0x9fff pref] pci_bus :00: root bus resource [mem 0xa000-0xbfff] pci_bus :00: root bus resource [bus 00-ff] Can't get bus-range for /pci@f0010800, assuming it starts at 0 bio: create slab at 0 pps_core: LinuxPPS API ver. 1 registered pps_core: Software ver. 5.3.6 - Copyright 2005-2007 Rodolfo Giometti PTP clock support registered Switching to clocksource timebase NET: Registered protocol family 2 TCP established hash table entries: 512 (order: 0, 4096 bytes) TCP bind hash table entries: 512 (order: -1, 2048 bytes) TCP: Hash tables configured (established 512 bind 512) TCP: reno registered UDP hash table entries: 256 (order: 0, 4096 bytes) UDP-Lite hash table entries: 256 (order: 0, 4096 bytes) NET: Registered protocol family 1 RPC: Registered named UNIX socket transport module. RPC: Registered udp transport module. RPC: Registered tcp transport module. RPC: Registered tcp NFSv4.1 backchannel transport module. jffs2: version 2.2. (NAND) (SUMMARY) © 2001-2006 Red Hat, Inc. msgmni has been set to 118 Block layer SCSI generic (bsg) driver version 0.4 loaded (major 252) io scheduler noop registered io scheduler deadline registered io scheduler cfq registered (default) f0011a00.serial: ttyCPM0 at MMIO 0xc505ea00 (i
RE: [PATCH] powerpc: Add I2C bus multiplexer node for B4 and T4240QDS
Hi Wei,
I totally agree that the i2c nodes topology should end up like you said.
But I think adding sub-nodes should step by step.
Actually the hardware i2c topology are huge like on T4.
So I'd like to adding nodes when we needed.
If you think the sub-nodes are needed please send another patch based on mine.
I think this is the more reasonable way.
Thanks.
-Hongtao
> -Original Message-
> From: Yang,Wei [mailto:wei.y...@windriver.com]
> Sent: Wednesday, September 04, 2013 9:27 AM
> To: Jia Hongtao-B38951
> Cc: linuxppc-dev@lists.ozlabs.org; Wood Scott-B07421; Jia Hongtao-B38951
> Subject: Re: [PATCH] powerpc: Add I2C bus multiplexer node for B4 and
> T4240QDS
>
> On 09/03/2013 03:51 PM, Jia Hongtao wrote:
> > In both B4 and T4240QDS platform PCA9547 I2C bus multiplexer is used.
>
> Hi Hongtao,
>
> If you want to support I2C bus multiplexer, for T4 and B4QDS platform,
> since some eeprom devices is connected to PCA9574 I2C bus multiplexer, so
> these devices should be connected to pca9547 node. Just like the
> following, what do you think of it?
>
> + pca9547@77 {
> + compatible = "philips,pca9547";
> + reg = <0x77>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> + channel@0 {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + reg = <0>;
> + eeprom@51 {
> + compatible =
> "at24,24c256";
> + reg = <0x51>;
> + };
> + eeprom@52 {
> + compatible =
> "at24,24c256";
> + reg = <0x52>;
> + };
> + eeprom@53 {
> + compatible =
> "at24,24c256";
> + reg = <0x53>;
> + };
> + eeprom@54 {
> + compatible =
> "at24,24c256";
> + reg = <0x54>;
> + };
> + eeprom@55 {
> + compatible =
> "at24,24c256";
> + reg = <0x55>;
> + };
> + eeprom@56 {
> + compatible =
> "at24,24c256";
> + reg = <0x56>;
> + };
> + rtc@68 {
> + compatible =
> "dallas,ds3232";
> + reg = <0x68>;
> + interrupts =
> <0x1 0x1 0 0>;
> + };
> + };
>
> Wei
> >
> > Signed-off-by: Jia Hongtao
> > ---
> > arch/powerpc/boot/dts/b4qds.dtsi | 4
> > arch/powerpc/boot/dts/t4240qds.dts | 4
> > 2 files changed, 8 insertions(+)
> >
> > diff --git a/arch/powerpc/boot/dts/b4qds.dtsi
> > b/arch/powerpc/boot/dts/b4qds.dtsi
> > index e6d2f8f..2aa3399 100644
> > --- a/arch/powerpc/boot/dts/b4qds.dtsi
> > +++ b/arch/powerpc/boot/dts/b4qds.dtsi
> > @@ -120,6 +120,10 @@
> > };
> >
> > i2c@118000 {
> > + pca9547@77 {
> > + compatible = "philips,pca9547";
> > + reg = <0x77>;
> > + };
> > eeprom@50 {
> > compatible = "at24,24c64";
> > reg = <0x50>;
> > diff --git a/arch/powerpc/boot/dts/t4240qds.dts
> > b/arch/powerpc/boot/dts/t4240qds.dts
> > index 0555976..084db57 100644
> > --- a/arch/powerpc/boot/dts/t4240qds.dts
> > +++ b/arch/powerpc/boot/dts/t4240qds.dts
> > @@ -118,6 +118,10 @@
> > };
> >
> > i2c@118000 {
> > + pca9547@77 {
> > + compatible = "philips,pca9547";
> > + reg = <0x77>;
> > + };
> > eeprom@51 {
> > compatible = "at24,24c256";
> >
RE: [PATCH] powerpc: Add I2C bus multiplexer node for B4 and T4240QDS
Hi,
These eeproms are never used by kernel. So no need to add them.
Thanks,
Yuantian
> -Original Message-
> From: Linuxppc-dev [mailto:linuxppc-dev-
> bounces+b29983=freescale@lists.ozlabs.org] On Behalf Of Yang,Wei
> Sent: 2013年9月4日 星期三 9:27
> To: Jia Hongtao-B38951
> Cc: Wood Scott-B07421; linuxppc-dev@lists.ozlabs.org; Jia Hongtao-B38951
> Subject: Re: [PATCH] powerpc: Add I2C bus multiplexer node for B4 and
> T4240QDS
>
> On 09/03/2013 03:51 PM, Jia Hongtao wrote:
> > In both B4 and T4240QDS platform PCA9547 I2C bus multiplexer is used.
>
> Hi Hongtao,
>
> If you want to support I2C bus multiplexer, for T4 and B4QDS platform,
> since some eeprom devices is connected to PCA9574 I2C bus multiplexer, so
> these devices should be connected to pca9547 node. Just like the
> following, what do you think of it?
>
> + pca9547@77 {
> + compatible = "philips,pca9547";
> + reg = <0x77>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> + channel@0 {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + reg = <0>;
> + eeprom@51 {
> + compatible =
> "at24,24c256";
> + reg = <0x51>;
> + };
> + eeprom@52 {
> + compatible =
> "at24,24c256";
> + reg = <0x52>;
> + };
> + eeprom@53 {
> + compatible =
> "at24,24c256";
> + reg = <0x53>;
> + };
> + eeprom@54 {
> + compatible =
> "at24,24c256";
> + reg = <0x54>;
> + };
> + eeprom@55 {
> + compatible =
> "at24,24c256";
> + reg = <0x55>;
> + };
> + eeprom@56 {
> + compatible =
> "at24,24c256";
> + reg = <0x56>;
> + };
> + rtc@68 {
> + compatible =
> "dallas,ds3232";
> + reg = <0x68>;
> + interrupts =
> <0x1 0x1 0 0>;
> + };
> + };
>
> Wei
> >
> > Signed-off-by: Jia Hongtao
> > ---
> > arch/powerpc/boot/dts/b4qds.dtsi | 4
> > arch/powerpc/boot/dts/t4240qds.dts | 4
> > 2 files changed, 8 insertions(+)
> >
> > diff --git a/arch/powerpc/boot/dts/b4qds.dtsi
> > b/arch/powerpc/boot/dts/b4qds.dtsi
> > index e6d2f8f..2aa3399 100644
> > --- a/arch/powerpc/boot/dts/b4qds.dtsi
> > +++ b/arch/powerpc/boot/dts/b4qds.dtsi
> > @@ -120,6 +120,10 @@
> > };
> >
> > i2c@118000 {
> > + pca9547@77 {
> > + compatible = "philips,pca9547";
> > + reg = <0x77>;
> > + };
> > eeprom@50 {
> > compatible = "at24,24c64";
> > reg = <0x50>;
> > diff --git a/arch/powerpc/boot/dts/t4240qds.dts
> > b/arch/powerpc/boot/dts/t4240qds.dts
> > index 0555976..084db57 100644
> > --- a/arch/powerpc/boot/dts/t4240qds.dts
> > +++ b/arch/powerpc/boot/dts/t4240qds.dts
> > @@ -118,6 +118,10 @@
> > };
> >
> > i2c@118000 {
> > + pca9547@77 {
> > + compatible = "philips,pca9547";
> > + reg = <0x77>;
> > + };
> > eeprom@51 {
> > compatible = "at24,24c256";
> > reg = <0x51>;
>
> ___
> Linuxppc-dev mailing list
> Linuxppc-dev@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev
_
Re: [PATCH 3/7] powerpc/pci: use pci_is_pcie() to simplify code
>Use pci_is_pcie() to simplify code.
>
>Signed-off-by: Yijing Wang
>Cc: Gavin Shan
>Cc: Benjamin Herrenschmidt
>Cc: Paul Mackerras
>Cc: linuxppc-dev@lists.ozlabs.org
>Cc: linux-ker...@vger.kernel.org
It looks good to me:
Reviewed-by: Gavin Shan
Thanks,
Gavin
>---
> arch/powerpc/kernel/eeh.c |3 +--
> arch/powerpc/sysdev/fsl_pci.c |2 +-
> 2 files changed, 2 insertions(+), 3 deletions(-)
>
>diff --git a/arch/powerpc/kernel/eeh.c b/arch/powerpc/kernel/eeh.c
>index 39954fe..b0bd41a 100644
>--- a/arch/powerpc/kernel/eeh.c
>+++ b/arch/powerpc/kernel/eeh.c
>@@ -189,8 +189,7 @@ static size_t eeh_gather_pci_data(struct eeh_dev *edev,
>char * buf, size_t len)
> }
>
> /* If PCI-E capable, dump PCI-E cap 10, and the AER */
>- cap = pci_find_capability(dev, PCI_CAP_ID_EXP);
>- if (cap) {
>+ if (pci_is_pcie(dev)) {
> n += scnprintf(buf+n, len-n, "pci-e cap10:\n");
> printk(KERN_WARNING
> "EEH: PCI-E capabilities and status follow:\n");
>diff --git a/arch/powerpc/sysdev/fsl_pci.c b/arch/powerpc/sysdev/fsl_pci.c
>index 46ac1dd..5402a1d 100644
>--- a/arch/powerpc/sysdev/fsl_pci.c
>+++ b/arch/powerpc/sysdev/fsl_pci.c
>@@ -41,7 +41,7 @@ static void quirk_fsl_pcie_header(struct pci_dev *dev)
> u8 hdr_type;
>
> /* if we aren't a PCIe don't bother */
>- if (!pci_find_capability(dev, PCI_CAP_ID_EXP))
>+ if (!pci_is_pcie(dev))
> return;
>
> /* if we aren't in host mode don't bother */
>--
>1.7.1
>
>
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [RFC PATCH v1 1/1] powerpc/85xx: Wakeup kexec smp slave cpus in second kernel
On 08/31/2013 05:12 PM, Yu Chen wrote:
>From 1ccf579b871dfd5938ce958f729361a203485c74 Mon Sep 17 00:00:00 2001
From: Yu Chen
Date: Sat, 31 Aug 2013 23:52:31 +0800
Subject: [PATCH] powerpc/85xx: Wakeup kexec smp slave cpus in second kernel
In current 85xx smp kexec implementation,master cpu reset slave cpus
by mpic_reset_core,
before jump to second kernel.In order to wake slave cpus up in second
kernel,we debug
this patch on p2041rdb.
What problem causes that you do the modification? I am just curious as
kexec feature always is fine on our
P2041RDB board.:-)
Wei
The main principle of this patch,is to get slave cpus polling for flag
to change,
thus waiting for master cpu to set it with non-zero cpu number(see misc_32.S).
This flag is placed in kexec control page,so it would not be
overlapped when copying kimage.
The master cpu put flag's physical address in r28 as a parameter
passed to second kernel,
so the latter knows how to wake slave cpus up in smp_85xx_kick_cpu.
The pseudo-code may be like:
void slave_cpu_spin(void)
{
int cpu = smp_processor_id();
while (*kexec_poll != cpu)
;
/*slave wakeup and jump*/
jump(*(kexec_poll+1));
}
void master_cpu_wakeup(unsigned long *kexec_poll, int cpu)
{
*(kexec_poll+1) = __early_start;
mb();
*kexec_poll = cpu;
}
However,after applied this patch,we got some kernel exception during
booting second kernel,
I'm not sure if it's caused by improper treament of cache,or tlb,or
other.So I put this
patch here hoping someone can check and review it.
Signed-off-by: Yu Chen
---
arch/powerpc/kernel/head_fsl_booke.S |7 ++
arch/powerpc/kernel/misc_32.S| 66 +-
arch/powerpc/platforms/85xx/smp.c| 166 ++
3 files changed, 222 insertions(+), 17 deletions(-)
mode change 100644 => 100755 arch/powerpc/kernel/head_fsl_booke.S
mode change 100644 => 100755 arch/powerpc/kernel/misc_32.S
mode change 100644 => 100755 arch/powerpc/platforms/85xx/smp.c
diff --git a/arch/powerpc/kernel/head_fsl_booke.S
b/arch/powerpc/kernel/head_fsl_booke.S
old mode 100644
new mode 100755
index d10a7ca..63c8392
--- a/arch/powerpc/kernel/head_fsl_booke.S
+++ b/arch/powerpc/kernel/head_fsl_booke.S
@@ -178,6 +178,13 @@ _ENTRY(__early_start)
* This is where the main kernel code starts.
*/
+#if defined(CONFIG_KEXEC) && defined(CONFIG_SMP)
+/* r28 contain position where slave cpus spin*/
+lisr1,kexec_poll_phy@h
+orir1,r1,kexec_poll_phy@l
+stwr28,0(r1)
+#endif
+
/* ptr to current */
lisr2,init_task@h
orir2,r2,init_task@l
diff --git a/arch/powerpc/kernel/misc_32.S b/arch/powerpc/kernel/misc_32.S
old mode 100644
new mode 100755
index e469f30..d9eefc2
--- a/arch/powerpc/kernel/misc_32.S
+++ b/arch/powerpc/kernel/misc_32.S
@@ -120,7 +120,7 @@ _GLOBAL(reloc_got2)
addir4,r4,1b@l
subfr0,r4,r0
addr7,r0,r7
-2:lwzr0,0(r7)
+2:lwzr0,0(r7)
addr0,r0,r3
stwr0,0(r7)
addir7,r7,4
@@ -692,6 +692,7 @@ _GLOBAL(__main)
blr
#ifdef CONFIG_KEXEC
+#define KEXEC_MAGIC 0xdeadbeef
/*
* Must be relocatable PIC code callable as a C function.
*/
@@ -707,6 +708,16 @@ relocate_new_kernel:
mrr30, r4
mrr31, r5
+#ifdef CONFIG_SMP
+bl1f
+1:mflrr8
+addir8,r8,kexec_flag-1b
+lis r7,PAGE_OFFSET@h
+ori r7,r7,PAGE_OFFSET@l
+/*r28 contain slave cpu spin physical address */
+subfr28, r7, r8
+#endif
+
#define ENTRY_MAPPING_KEXEC_SETUP
#include "fsl_booke_entry_mapping.S"
#undef ENTRY_MAPPING_KEXEC_SETUP
@@ -1172,4 +1183,57 @@ relocate_new_kernel_end:
.globl relocate_new_kernel_size
relocate_new_kernel_size:
.long relocate_new_kernel_end - relocate_new_kernel
+#ifdef CONFIG_FSL_BOOKE
+/**
+* Slave cpus wait for kexec_flag to change
+*/
+.globl relocate_smp_cpu_offset
+relocate_smp_cpu_offset:
+.long relocate_smp_cpu_wait-relocate_new_kernel
+
+.globl relocate_smp_cpu_wait
+relocate_smp_cpu_wait:
+
+bl1f
+1:mflrr5
+addir5,r5,kexec_flag-1b
+/*see if anyone calls me?*/
+mfspr r24,SPRN_PIR
+99:lwzr4,4(r5)
+cmpwr4,r24
+msync
+bne99b
+
+msync
+/*r4 contains jump address*/
+lwzr4,8(r5)
+msync
+lisr5,MSR_KERNEL@h
+orir5,r5,MSR_KERNEL@l
+msync
+isync
+mtsprSPRN_SRR1, r5
+mtsprSPRN_SRR0, r4
+msync
+isync
+rfi
+isync
+1:b1b
+
+/**
+* kexec_flag indicates a kexec magic
+* kexec_flag+4 bytes supposed to be set with cpu number
+* kexec_flag+8 countain addr for slave cpu to jump into
+*/
+.globl kexec_flag
+kexec_flag:
+.long KEXEC_MAGIC
+.long0
+.long0
+relocate_smp_cpu_wait_end:
+.globl relocate_smp_cpu_size
+relocate_smp_cpu_size:
RE: [RFC PATCH v2 04/11] pstore: Add compression support to pstore
Aruna, Sorry for the late response. > Seiji, > > Could you let us know the efivars buffer size with which the pstore is > registered when > the failure occurred. I looked into the issue today. I added some debug message just before pstore_compress(). As you can see below, the buffer size is a fixed value(1024). Therefore, the size doesn't seem to be related to the failure directly. Also, in the failure case, zlib_deflate() returns Z_OK and stream.avail_out is zero. So, I thought big_oops_buf_sz is too big in my environment. And then, I tuned big_oops_buf_sz to (psinfo->bufsize * 100) / 53. At the same time, while looking into this issue, I had two concerns about current cording. 1) In pstore_decompress(), why not use zlib_inflateInit2() instead of zlib_inflateInit()? If you use zlib_deflateInit2() for specifying window_bit at compressing time, zlib_inflateInit2() seems to be appropriate for decompressing. (Please see a comment about inflateInit2() in include/linux/zlib.h and source code of crypto/deflate.c) 2) As looking at crypto/deflate.c, stream->workspace is kzalloced at the beginning of compressing/decompressing time. So, in pstore case, stream.workspace must be initialized to 0 with memset() in pstore_compress()/decompress(). I did three things above, tuning big_oops_buf_sz, using zlib_inflateInit2() and initializing stream.workspace , in my environment. As a result, compressions/decmpressions of all entries succeeded with efivars driver. Panic#2 Part1 <4>[ 75.665020] [] SyS_write+0x4c/0xa0 <4>[ 75.665020] [] system_call_fastpath+0x16/0x1b <4>[ 75.665020] Code: ef e8 ff f7 ff ff eb d8 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 00 0f 1f 44 00 00 55 c7 05 cc f3 c9 00 01 00 00 00 48 89 e5 0f ae f8 04 25 00 00 00 00 01 5d c3 0f 1f 44 00 00 55 31 c0 c7 05 5e <1>[ 75.665020] RIP [] sysrq_handle_crash+0x16/0x20 <4>[ 75.665020] RSP <4>[ 75.665020] CR2: <4>[ 75.665020] ---[ end trace 97bb4a1f8d3fe7b2 ]--- <3>[ 75.665020] pstore_dump hsize=13 len=2155 big_oops_buf_sz=2275 psinfo->bufsize=1024 <3>[ 75.665020] pstore_dump hsize=13 len=2246 big_oops_buf_sz=2275 psinfo->bufsize=1024 <3>[ 75.665020] pstore: compression failed for Part 2 returned -5 <3>[ 75.665020] pstore: Capture uncompressed oops/panic report of Part 2 <3>[ 75.665020] pstore_dump hsize=13 len=2239 big_oops_buf_sz=2275 psinfo->bufsize=1024 <3>[ 75.665020] pstore_dump hsize=13 len=2231 big_oops_buf_sz=2275 psinfo->bufsize=1024 <3>[ 75.665020] pstore_dump hsize=13 len=2185 big_oops_buf_sz=2275 psinfo->bufsize=1024 <3>[ 75.665020] pstore: compression failed for Part 5 returned -5 <3>[ 75.665020] pstore: Capture uncompressed oops/panic report of Part 5 <3>[ 75.665020] pstore_dump hsize=13 len=2234 big_oops_buf_sz=2275 psinfo->bufsize=1024 <3>[ 75.665020] pstore_dump hsize=13 len=2208 big_oops_buf_sz=2275 psinfo->bufsize=1024 <3>[ 75.665020] pstore_dump hsize=13 len=2218 big_oops_buf_sz=2275 psinfo->bufsize=1024 <3>[ 75.665020] pstore_dump hsize=13 len= big_oops_buf_sz=2275 psinfo->bufsize=1024 <3>[ 75.665020] pstore: compression failed for Part 9 returned -5 <3>[ 75.665020] pstore: Capture uncompressed oops/panic report of Part 9 <3>[ 75.665020] pstore_dump hsize=14 len=2256 big_oops_buf_sz=2275 psinfo->bufsize=1024 <3>[ 75.665020] pstore_dump hsize=14 len=2219 big_oops_buf_sz=2275 psinfo->bufsize=1024 <3>[ 75.665020] pstore_dump hsize=14 len=2226 big_oops_buf_sz=2275 psinfo->bufsize=1024 <0>[ 75.665020] Kernel panic - not syncing: Fatal exception <3>[ 75.665020] drm_kms_helper: panic occurred, switching back to text console Seiji ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] powerpc: Add I2C bus multiplexer node for B4 and T4240QDS
On 09/03/2013 03:51 PM, Jia Hongtao wrote:
In both B4 and T4240QDS platform PCA9547 I2C bus multiplexer is used.
Hi Hongtao,
If you want to support I2C bus multiplexer, for T4 and B4QDS platform,
since some eeprom devices is connected to PCA9574 I2C bus
multiplexer, so these devices should be connected to pca9547 node. Just
like the following, what do you think of it?
+ pca9547@77 {
+ compatible = "philips,pca9547";
+ reg = <0x77>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ channel@0 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0>;
+ eeprom@51 {
+ compatible =
"at24,24c256";
+ reg = <0x51>;
+ };
+ eeprom@52 {
+ compatible =
"at24,24c256";
+ reg = <0x52>;
+ };
+ eeprom@53 {
+ compatible =
"at24,24c256";
+ reg = <0x53>;
+ };
+ eeprom@54 {
+ compatible =
"at24,24c256";
+ reg = <0x54>;
+ };
+ eeprom@55 {
+ compatible =
"at24,24c256";
+ reg = <0x55>;
+ };
+ eeprom@56 {
+ compatible =
"at24,24c256";
+ reg = <0x56>;
+ };
+ rtc@68 {
+ compatible =
"dallas,ds3232";
+ reg = <0x68>;
+ interrupts =
<0x1 0x1 0 0>;
+ };
+ };
Wei
Signed-off-by: Jia Hongtao
---
arch/powerpc/boot/dts/b4qds.dtsi | 4
arch/powerpc/boot/dts/t4240qds.dts | 4
2 files changed, 8 insertions(+)
diff --git a/arch/powerpc/boot/dts/b4qds.dtsi b/arch/powerpc/boot/dts/b4qds.dtsi
index e6d2f8f..2aa3399 100644
--- a/arch/powerpc/boot/dts/b4qds.dtsi
+++ b/arch/powerpc/boot/dts/b4qds.dtsi
@@ -120,6 +120,10 @@
};
i2c@118000 {
+ pca9547@77 {
+ compatible = "philips,pca9547";
+ reg = <0x77>;
+ };
eeprom@50 {
compatible = "at24,24c64";
reg = <0x50>;
diff --git a/arch/powerpc/boot/dts/t4240qds.dts
b/arch/powerpc/boot/dts/t4240qds.dts
index 0555976..084db57 100644
--- a/arch/powerpc/boot/dts/t4240qds.dts
+++ b/arch/powerpc/boot/dts/t4240qds.dts
@@ -118,6 +118,10 @@
};
i2c@118000 {
+ pca9547@77 {
+ compatible = "philips,pca9547";
+ reg = <0x77>;
+ };
eeprom@51 {
compatible = "at24,24c256";
reg = <0x51>;
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] ppc: bpf_jit: support MOD operation
On 09/03/2013 09:58 PM, Vladimir Murzin wrote:
On Tue, Sep 03, 2013 at 06:45:50AM +1000, Benjamin Herrenschmidt wrote:
On Mon, 2013-09-02 at 19:48 +0200, Vladimir Murzin wrote:
Ping
On Wed, Aug 28, 2013 at 02:49:52AM +0400, Vladimir Murzin wrote:
commit b6069a9570 (filter: add MOD operation) added generic
support for modulus operation in BPF.
Sorry, nobody got a chance to review that yet. Unfortunately Matt
doesn't work for us anymore and none of us has experience with the
BPF code, so somebody (possibly me) will need to spend a bit of time
figuring it out before verifying that is correct.
Do you have a test case/suite by any chance ?
Ben.
Hi Ben!
Thanks for your feedback.
This patch is only compile tested. I have no real hardware, but I'll
probably bring up qemu ppc64 till end of the week...
Meanwhile, I've made simple how-to for testing. You can use it if you wish.
It is mainly based on the [1] and rechecked on x86-64.
Please also cc netdev on BPF related changes.
Actually, your test plan can be further simplified ...
For retrieving and disassembling the JIT image, we have bpf_jit_disasm [1].
1) echo 2 > /proc/sys/net/core/bpf_jit_enable
2) ... attach filter ...
3) bpf_jit_disasm -o
For generating a simple stupid test filter, you can use bpfc [2] (also
see its man page). E.g. ...
# cat blub
ldi #10
mod #8
ret a
# bpfc blub
{ 0x0, 0, 0, 0x000a },
{ 0x94, 0, 0, 0x0008 },
{ 0x16, 0, 0, 0x },
And load this array e.g. either into a small C program that attaches this
as BPF filter, or simply do bpfc blub > blub2 and run netsniff-ng -f blub2\
-s -i eth0, that should also do it.
Then, when attached, the kernel should truncate incoming frames for pf_packet
into max length of 2, just as an example.
[1] kernel tree, tools/net/bpf_jit_disasm.c
[2] git clone git://github.com/borkmann/netsniff-ng.git
1. get the tcpdump utility (git clone git://bpf.tcpdump.org/tcpdump)
2. get the libcap library (git clone git://bpf.tcpdump.org/libpcap)
2.1. apply patch for libcap [2] (against libcap-1.3 branch)
2.2. build libcap (./configure && make && ln -s libcap.so.1.3.0 libcap.so)
3. build tcpdump (LDFLAGS="-L/path/to/libcap" ./configure && make)
4. run
# ./tcpdump -d "(ip[2:2] - 20) % 5 != 0 && ip[6] & 0x20 = 0x20"
(000) ldh [14]
(001) jeq #0x800 jt 2 jf 10
(002) ldh [18]
(003) sub #20
(004) mod #5
(005) jeq #0x0 jt 10 jf 6
(006) ldb [22]
(007) and #0x20
(008) jeq #0x20 jt 9 jf 10
(009) ret #65535
(010) ret #0
to get pseudo code (we are interested the most into line #4)
5. enable bpf jit compiler
# echo 2 > /proc/sys/net/core/bpf_jit_enable
6. run
./tcpdump -nv "(ip[2:2] - 20) % 5 != 0 && ip[6] & 0x20 = 0x20"
7. check dmesg for lines starting with (output for x86-64 is provided as an
example)
[ 3768.329253] flen=11 proglen=99 pass=3 image=a003c000
[ 3768.329254] JIT code: a003c000: 55 48 89 e5 48 83 ec 60 48 89 5d f8
44 8b 4f 60
[ 3768.329255] JIT code: a003c010: 44 2b 4f 64 4c 8b 87 c0 00 00 00 0f
b7 47 76 86
[ 3768.329256] JIT code: a003c020: c4 3d 00 08 00 00 75 37 be 02 00 00
00 e8 9f 3e
[ 3768.329257] JIT code: a003c030: 02 e1 83 e8 14 31 d2 b9 05 00 00 00
f7 f1 89 d0
[ 3768.329258] JIT code: a003c040: 85 c0 74 1b be 06 00 00 00 e8 9f 3e
02 e1 25 20
[ 3768.329259] JIT code: a003c050: 00 00 00 83 f8 20 75 07 b8 ff ff 00
00 eb 02 31
[ 3768.329259] JIT code: a003c060: c0 c9 c3
8. make sure generated opcodes (JIT code) implement pseudo code form step 4.
Reference
[1] http://comments.gmane.org/gmane.linux.network/242456
[2] http://permalink.gmane.org/gmane.network.tcpdump.devel/5973
P.S.
I hope net people will corect me if I'm wrong there
Cheers
Vladimir Murzin
This patch brings JIT support for PPC64
Signed-off-by: Vladimir Murzin
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Please pull 'next' branch of 5xxx tree
Hi Ben ! Please pull mpc5xxx patches for v3.12. There are cleanups for some mpc5121 specific drivers and DTS files in preparation to switch mpc5121 clock support to a clock driver based on common clock framework. Additionally Sebastian fixed the mpc52xx PIC driver so that it builds when using older gcc versions. All these patches have already been in linux-next for a while. Thanks, Anatolij The following changes since commit d4e4ab86bcba5a72779c43dc1459f71fea3d89c8: Linux 3.11-rc5 (2013-08-11 18:04:20 -0700) are available in the git repository at: git://git.denx.de/linux-2.6-agust.git next for you to fetch changes up to f2110cb961200e5c382e9d0878ded015109b5dd6: dts: mpc512x: prepare for preprocessor support (2013-08-24 00:18:55 +0200) Gerhard Sittig (6): serial: mpc512x: cleanup clock API use USB: fsl-mph-dr-of: cleanup clock API use mtd: mpc5121_nfc: cleanup clock API use fsl-viu: cleanup clock API use powerpc: mpc512x: array decl for MCLK registers in CCM dts: mpc512x: prepare for preprocessor support Sebastian Siewior (1): powerpc: 52xx: provide a default in mpc52xx_irqhost_map() arch/powerpc/boot/dts/ac14xx.dts |2 +- arch/powerpc/boot/dts/include/dt-bindings |1 + arch/powerpc/boot/dts/mpc5121ads.dts |2 +- arch/powerpc/boot/dts/pdm360ng.dts|2 +- arch/powerpc/include/asm/mpc5121.h| 18 +- arch/powerpc/platforms/52xx/mpc52xx_pic.c |3 +- drivers/media/platform/fsl-viu.c | 23 --- drivers/mtd/nand/mpc5121_nfc.c| 21 --- drivers/tty/serial/mpc52xx_uart.c | 98 - drivers/usb/host/fsl-mph-dr-of.c | 16 ++--- 10 files changed, 123 insertions(+), 63 deletions(-) create mode 12 arch/powerpc/boot/dts/include/dt-bindings ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] ppc: bpf_jit: support MOD operation
On Tue, Sep 03, 2013 at 06:45:50AM +1000, Benjamin Herrenschmidt wrote:
> On Mon, 2013-09-02 at 19:48 +0200, Vladimir Murzin wrote:
> > Ping
> >
> > On Wed, Aug 28, 2013 at 02:49:52AM +0400, Vladimir Murzin wrote:
> > > commit b6069a9570 (filter: add MOD operation) added generic
> > > support for modulus operation in BPF.
> > >
> Sorry, nobody got a chance to review that yet. Unfortunately Matt
> doesn't work for us anymore and none of us has experience with the
> BPF code, so somebody (possibly me) will need to spend a bit of time
> figuring it out before verifying that is correct.
>
> Do you have a test case/suite by any chance ?
>
> Ben.
>
Hi Ben!
Thanks for your feedback.
This patch is only compile tested. I have no real hardware, but I'll
probably bring up qemu ppc64 till end of the week...
Meanwhile, I've made simple how-to for testing. You can use it if you wish.
It is mainly based on the [1] and rechecked on x86-64.
1. get the tcpdump utility (git clone git://bpf.tcpdump.org/tcpdump)
2. get the libcap library (git clone git://bpf.tcpdump.org/libpcap)
2.1. apply patch for libcap [2] (against libcap-1.3 branch)
2.2. build libcap (./configure && make && ln -s libcap.so.1.3.0 libcap.so)
3. build tcpdump (LDFLAGS="-L/path/to/libcap" ./configure && make)
4. run
# ./tcpdump -d "(ip[2:2] - 20) % 5 != 0 && ip[6] & 0x20 = 0x20"
(000) ldh [14]
(001) jeq #0x800 jt 2 jf 10
(002) ldh [18]
(003) sub #20
(004) mod #5
(005) jeq #0x0 jt 10 jf 6
(006) ldb [22]
(007) and #0x20
(008) jeq #0x20 jt 9 jf 10
(009) ret #65535
(010) ret #0
to get pseudo code (we are interested the most into line #4)
5. enable bpf jit compiler
# echo 2 > /proc/sys/net/core/bpf_jit_enable
6. run
./tcpdump -nv "(ip[2:2] - 20) % 5 != 0 && ip[6] & 0x20 = 0x20"
7. check dmesg for lines starting with (output for x86-64 is provided as an
example)
[ 3768.329253] flen=11 proglen=99 pass=3 image=a003c000
[ 3768.329254] JIT code: a003c000: 55 48 89 e5 48 83 ec 60 48 89 5d f8
44 8b 4f 60
[ 3768.329255] JIT code: a003c010: 44 2b 4f 64 4c 8b 87 c0 00 00 00 0f
b7 47 76 86
[ 3768.329256] JIT code: a003c020: c4 3d 00 08 00 00 75 37 be 02 00 00
00 e8 9f 3e
[ 3768.329257] JIT code: a003c030: 02 e1 83 e8 14 31 d2 b9 05 00 00 00
f7 f1 89 d0
[ 3768.329258] JIT code: a003c040: 85 c0 74 1b be 06 00 00 00 e8 9f 3e
02 e1 25 20
[ 3768.329259] JIT code: a003c050: 00 00 00 83 f8 20 75 07 b8 ff ff 00
00 eb 02 31
[ 3768.329259] JIT code: a003c060: c0 c9 c3
8. make sure generated opcodes (JIT code) implement pseudo code form step 4.
Reference
[1] http://comments.gmane.org/gmane.linux.network/242456
[2] http://permalink.gmane.org/gmane.network.tcpdump.devel/5973
P.S.
I hope net people will corect me if I'm wrong there
Cheers
Vladimir Murzin
> > > This patch brings JIT support for PPC64
> > >
> > > Signed-off-by: Vladimir Murzin
> > > ---
> > > arch/powerpc/net/bpf_jit_comp.c | 22 ++
> > > 1 file changed, 22 insertions(+)
> > >
> > > diff --git a/arch/powerpc/net/bpf_jit_comp.c
> > > b/arch/powerpc/net/bpf_jit_comp.c
> > > index bf56e33..96f24dc 100644
> > > --- a/arch/powerpc/net/bpf_jit_comp.c
> > > +++ b/arch/powerpc/net/bpf_jit_comp.c
> > > @@ -193,6 +193,28 @@ static int bpf_jit_build_body(struct sk_filter *fp,
> > > u32 *image,
> > > PPC_MUL(r_A, r_A, r_scratch1);
> > > }
> > > break;
> > > + case BPF_S_ALU_MOD_X: /* A %= X; */
> > > + ctx->seen |= SEEN_XREG;
> > > + PPC_CMPWI(r_X, 0);
> > > + if (ctx->pc_ret0 != -1) {
> > > + PPC_BCC(COND_EQ, addrs[ctx->pc_ret0]);
> > > + } else {
> > > + PPC_BCC_SHORT(COND_NE, (ctx->idx*4)+12);
> > > + PPC_LI(r_ret, 0);
> > > + PPC_JMP(exit_addr);
> > > + }
> > > + PPC_DIVWU(r_scratch1, r_A, r_X);
> > > + PPC_MUL(r_scratch1, r_X, r_scratch1);
> > > + PPC_SUB(r_A, r_A, r_scratch1);
> > > + break;
> > > + case BPF_S_ALU_MOD_K: /* A %= K; */
> > > +#define r_scratch2 (r_scratch1 + 1)
> > > + PPC_LI32(r_scratch2, K);
> > > + PPC_DIVWU(r_scratch1, r_A, r_scratch2);
> > > + PPC_MUL(r_scratch1, r_scratch2, r_scratch1);
> > > + PPC_SUB(r_A, r_A, r_scratch1);
> > > +#undef r_scratch2
> > > + break;
> > > case BPF_S_ALU_DIV_X: /* A /= X; */
> > > ctx->seen |= SEEN_XREG;
> > > PPC_CMPWI(r_X, 0);
> > > --
> > > 1.8.1.5
> > >
>
>
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v9 12/13] KVM: PPC: Add support for IOMMU in-kernel handling
On 09/03/2013 08:53 PM, Gleb Natapov wrote:
> On Mon, Sep 02, 2013 at 01:14:29PM +1000, Alexey Kardashevskiy wrote:
>> On 09/01/2013 10:06 PM, Gleb Natapov wrote:
>>> On Wed, Aug 28, 2013 at 06:50:41PM +1000, Alexey Kardashevskiy wrote:
This allows the host kernel to handle H_PUT_TCE, H_PUT_TCE_INDIRECT
and H_STUFF_TCE requests targeted an IOMMU TCE table without passing
them to user space which saves time on switching to user space and back.
Both real and virtual modes are supported. The kernel tries to
handle a TCE request in the real mode, if fails it passes the request
to the virtual mode to complete the operation. If it a virtual mode
handler fails, the request is passed to user space.
The first user of this is VFIO on POWER. Trampolines to the VFIO external
user API functions are required for this patch.
This adds a "SPAPR TCE IOMMU" KVM device to associate a logical bus
number (LIOBN) with an VFIO IOMMU group fd and enable in-kernel handling
of map/unmap requests. The device supports a single attribute which is
a struct with LIOBN and IOMMU fd. When the attribute is set, the device
establishes the connection between KVM and VFIO.
Tests show that this patch increases transmission speed from 220MB/s
to 750..1020MB/s on 10Gb network (Chelsea CXGB3 10Gb ethernet card).
Signed-off-by: Paul Mackerras
Signed-off-by: Alexey Kardashevskiy
---
Changes:
v9:
* KVM_CAP_SPAPR_TCE_IOMMU ioctl to KVM replaced with "SPAPR TCE IOMMU"
KVM device
* release_spapr_tce_table() is not shared between different TCE types
* reduced the patch size by moving VFIO external API
trampolines to separate patche
* moved documentation from Documentation/virtual/kvm/api.txt to
Documentation/virtual/kvm/devices/spapr_tce_iommu.txt
v8:
* fixed warnings from check_patch.pl
2013/07/11:
* removed multiple #ifdef IOMMU_API as IOMMU_API is always enabled
for KVM_BOOK3S_64
* kvmppc_gpa_to_hva_and_get also returns host phys address. Not much sense
for this here but the next patch for hugepages support will use it more.
2013/07/06:
* added realmode arch_spin_lock to protect TCE table from races
in real and virtual modes
* POWERPC IOMMU API is changed to support real mode
* iommu_take_ownership and iommu_release_ownership are protected by
iommu_table's locks
* VFIO external user API use rewritten
* multiple small fixes
2013/06/27:
* tce_list page is referenced now in order to protect it from accident
invalidation during H_PUT_TCE_INDIRECT execution
* added use of the external user VFIO API
2013/06/05:
* changed capability number
* changed ioctl number
* update the doc article number
2013/05/20:
* removed get_user() from real mode handlers
* kvm_vcpu_arch::tce_tmp usage extended. Now real mode handler puts there
translated TCEs, tries realmode_get_page() on those and if it fails, it
passes control over the virtual mode handler which tries to finish
the request handling
* kvmppc_lookup_pte() now does realmode_get_page() protected by BUSY bit
on a page
* The only reason to pass the request to user mode now is when the user
mode
did not register TCE table in the kernel, in all other cases the virtual
mode
handler is expected to do the job
---
.../virtual/kvm/devices/spapr_tce_iommu.txt| 37 +++
arch/powerpc/include/asm/kvm_host.h| 4 +
arch/powerpc/kvm/book3s_64_vio.c | 310
-
arch/powerpc/kvm/book3s_64_vio_hv.c| 122
arch/powerpc/kvm/powerpc.c | 1 +
include/linux/kvm_host.h | 1 +
virt/kvm/kvm_main.c| 5 +
7 files changed, 477 insertions(+), 3 deletions(-)
create mode 100644 Documentation/virtual/kvm/devices/spapr_tce_iommu.txt
diff --git a/Documentation/virtual/kvm/devices/spapr_tce_iommu.txt
b/Documentation/virtual/kvm/devices/spapr_tce_iommu.txt
new file mode 100644
index 000..4bc8fc3
--- /dev/null
+++ b/Documentation/virtual/kvm/devices/spapr_tce_iommu.txt
@@ -0,0 +1,37 @@
+SPAPR TCE IOMMU device
+
+Capability: KVM_CAP_SPAPR_TCE_IOMMU
+Architectures: powerpc
+
+Device type supported: KVM_DEV_TYPE_SPAPR_TCE_IOMMU
+
+Groups:
+ KVM_DEV_SPAPR_TCE_IOMMU_ATTR_LINKAGE
+ Attributes: single attribute with pair { LIOBN, IOMMU fd}
+
+This is completely made up device which provides API to link
+logical bus number (LIOBN) and IOMMU group. The user space has
+to create a new SPAPR TCE IOMMU device per a logical bus.
+
>>> Wh
Re: [PATCH v9 12/13] KVM: PPC: Add support for IOMMU in-kernel handling
On Mon, Sep 02, 2013 at 01:14:29PM +1000, Alexey Kardashevskiy wrote:
> On 09/01/2013 10:06 PM, Gleb Natapov wrote:
> > On Wed, Aug 28, 2013 at 06:50:41PM +1000, Alexey Kardashevskiy wrote:
> >> This allows the host kernel to handle H_PUT_TCE, H_PUT_TCE_INDIRECT
> >> and H_STUFF_TCE requests targeted an IOMMU TCE table without passing
> >> them to user space which saves time on switching to user space and back.
> >>
> >> Both real and virtual modes are supported. The kernel tries to
> >> handle a TCE request in the real mode, if fails it passes the request
> >> to the virtual mode to complete the operation. If it a virtual mode
> >> handler fails, the request is passed to user space.
> >>
> >> The first user of this is VFIO on POWER. Trampolines to the VFIO external
> >> user API functions are required for this patch.
> >>
> >> This adds a "SPAPR TCE IOMMU" KVM device to associate a logical bus
> >> number (LIOBN) with an VFIO IOMMU group fd and enable in-kernel handling
> >> of map/unmap requests. The device supports a single attribute which is
> >> a struct with LIOBN and IOMMU fd. When the attribute is set, the device
> >> establishes the connection between KVM and VFIO.
> >>
> >> Tests show that this patch increases transmission speed from 220MB/s
> >> to 750..1020MB/s on 10Gb network (Chelsea CXGB3 10Gb ethernet card).
> >>
> >> Signed-off-by: Paul Mackerras
> >> Signed-off-by: Alexey Kardashevskiy
> >>
> >> ---
> >>
> >> Changes:
> >> v9:
> >> * KVM_CAP_SPAPR_TCE_IOMMU ioctl to KVM replaced with "SPAPR TCE IOMMU"
> >> KVM device
> >> * release_spapr_tce_table() is not shared between different TCE types
> >> * reduced the patch size by moving VFIO external API
> >> trampolines to separate patche
> >> * moved documentation from Documentation/virtual/kvm/api.txt to
> >> Documentation/virtual/kvm/devices/spapr_tce_iommu.txt
> >>
> >> v8:
> >> * fixed warnings from check_patch.pl
> >>
> >> 2013/07/11:
> >> * removed multiple #ifdef IOMMU_API as IOMMU_API is always enabled
> >> for KVM_BOOK3S_64
> >> * kvmppc_gpa_to_hva_and_get also returns host phys address. Not much sense
> >> for this here but the next patch for hugepages support will use it more.
> >>
> >> 2013/07/06:
> >> * added realmode arch_spin_lock to protect TCE table from races
> >> in real and virtual modes
> >> * POWERPC IOMMU API is changed to support real mode
> >> * iommu_take_ownership and iommu_release_ownership are protected by
> >> iommu_table's locks
> >> * VFIO external user API use rewritten
> >> * multiple small fixes
> >>
> >> 2013/06/27:
> >> * tce_list page is referenced now in order to protect it from accident
> >> invalidation during H_PUT_TCE_INDIRECT execution
> >> * added use of the external user VFIO API
> >>
> >> 2013/06/05:
> >> * changed capability number
> >> * changed ioctl number
> >> * update the doc article number
> >>
> >> 2013/05/20:
> >> * removed get_user() from real mode handlers
> >> * kvm_vcpu_arch::tce_tmp usage extended. Now real mode handler puts there
> >> translated TCEs, tries realmode_get_page() on those and if it fails, it
> >> passes control over the virtual mode handler which tries to finish
> >> the request handling
> >> * kvmppc_lookup_pte() now does realmode_get_page() protected by BUSY bit
> >> on a page
> >> * The only reason to pass the request to user mode now is when the user
> >> mode
> >> did not register TCE table in the kernel, in all other cases the virtual
> >> mode
> >> handler is expected to do the job
> >> ---
> >> .../virtual/kvm/devices/spapr_tce_iommu.txt| 37 +++
> >> arch/powerpc/include/asm/kvm_host.h| 4 +
> >> arch/powerpc/kvm/book3s_64_vio.c | 310
> >> -
> >> arch/powerpc/kvm/book3s_64_vio_hv.c| 122
> >> arch/powerpc/kvm/powerpc.c | 1 +
> >> include/linux/kvm_host.h | 1 +
> >> virt/kvm/kvm_main.c| 5 +
> >> 7 files changed, 477 insertions(+), 3 deletions(-)
> >> create mode 100644 Documentation/virtual/kvm/devices/spapr_tce_iommu.txt
> >>
> >> diff --git a/Documentation/virtual/kvm/devices/spapr_tce_iommu.txt
> >> b/Documentation/virtual/kvm/devices/spapr_tce_iommu.txt
> >> new file mode 100644
> >> index 000..4bc8fc3
> >> --- /dev/null
> >> +++ b/Documentation/virtual/kvm/devices/spapr_tce_iommu.txt
> >> @@ -0,0 +1,37 @@
> >> +SPAPR TCE IOMMU device
> >> +
> >> +Capability: KVM_CAP_SPAPR_TCE_IOMMU
> >> +Architectures: powerpc
> >> +
> >> +Device type supported: KVM_DEV_TYPE_SPAPR_TCE_IOMMU
> >> +
> >> +Groups:
> >> + KVM_DEV_SPAPR_TCE_IOMMU_ATTR_LINKAGE
> >> + Attributes: single attribute with pair { LIOBN, IOMMU fd}
> >> +
> >> +This is completely made up device which provides API to link
> >> +logical bus number (LIOBN) and IOMMU group. The user space has
> >> +to create a new SPAPR TCE IOMMU device per a logical bus.
> >> +
> > Why not have one device that can handle multimple
[PATCH] powerpc: xmon: Fix printing of set of CPUs in xmon
Commit 24ec2125f3 ("powerpc/xmon: Use cpumask iterator to avoid warning")
replaced a loop from 0 to NR_CPUS-1 with a for_each_possible_cpu() loop,
which means that if the last possible cpu is in xmon, we print the
wrong value for the end of the range. For example, if 4 cpus are
possible, NR_CPUS is 128, and all cpus are in xmon, we print "0-7f"
rather than "0-3". The code also assumes that the set of possible
cpus is contiguous, which may not necessarily be true.
This fixes the code to check explicitly for contiguity, and to print
the ending value correctly.
Signed-off-by: Paul Mackerras
---
arch/powerpc/xmon/xmon.c | 24
1 file changed, 12 insertions(+), 12 deletions(-)
diff --git a/arch/powerpc/xmon/xmon.c b/arch/powerpc/xmon/xmon.c
index 1fcdc2e..a7f176c 100644
--- a/arch/powerpc/xmon/xmon.c
+++ b/arch/powerpc/xmon/xmon.c
@@ -972,27 +972,27 @@ static void bootcmds(void)
static int cpu_cmd(void)
{
#ifdef CONFIG_SMP
- unsigned long cpu;
+ unsigned long cpu, first_cpu, last_cpu;
int timeout;
- int count;
if (!scanhex(&cpu)) {
/* print cpus waiting or in xmon */
printf("cpus stopped:");
- count = 0;
+ last_cpu = first_cpu = NR_CPUS;
for_each_possible_cpu(cpu) {
if (cpumask_test_cpu(cpu, &cpus_in_xmon)) {
- if (count == 0)
- printf(" %x", cpu);
- ++count;
- } else {
- if (count > 1)
- printf("-%x", cpu - 1);
- count = 0;
+ if (cpu == last_cpu + 1) {
+ last_cpu = cpu;
+ } else {
+ if (last_cpu != first_cpu)
+ printf("-%lx", last_cpu);
+ last_cpu = first_cpu = cpu;
+ printf(" %lx", cpu);
+ }
}
}
- if (count > 1)
- printf("-%x", NR_CPUS - 1);
+ if (last_cpu != first_cpu)
+ printf("-%lx", last_cpu);
printf("\n");
return 0;
}
--
1.8.4.rc3
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] powerpc/fsl/defconfig: enable CONFIG_AT803X_PHY
Enable CONFIG_AT803X_PHY to support AR8030/8033/8035 PHY. Signed-off-by: Shengzhou Liu --- arch/powerpc/configs/corenet32_smp_defconfig |1 + arch/powerpc/configs/mpc85xx_defconfig |1 + arch/powerpc/configs/mpc85xx_smp_defconfig |1 + 3 files changed, 3 insertions(+), 0 deletions(-) diff --git a/arch/powerpc/configs/corenet32_smp_defconfig b/arch/powerpc/configs/corenet32_smp_defconfig index 60027c2..ccb9d12 100644 --- a/arch/powerpc/configs/corenet32_smp_defconfig +++ b/arch/powerpc/configs/corenet32_smp_defconfig @@ -103,6 +103,7 @@ CONFIG_FSL_PQ_MDIO=y CONFIG_E1000=y CONFIG_E1000E=y CONFIG_VITESSE_PHY=y +CONFIG_AT803X_PHY=y CONFIG_FIXED_PHY=y # CONFIG_INPUT_MOUSEDEV is not set # CONFIG_INPUT_KEYBOARD is not set diff --git a/arch/powerpc/configs/mpc85xx_defconfig b/arch/powerpc/configs/mpc85xx_defconfig index 5a58882..2ddbba5 100644 --- a/arch/powerpc/configs/mpc85xx_defconfig +++ b/arch/powerpc/configs/mpc85xx_defconfig @@ -136,6 +136,7 @@ CONFIG_MARVELL_PHY=y CONFIG_DAVICOM_PHY=y CONFIG_CICADA_PHY=y CONFIG_VITESSE_PHY=y +CONFIG_AT803X_PHY=y CONFIG_FIXED_PHY=y CONFIG_INPUT_FF_MEMLESS=m # CONFIG_INPUT_MOUSEDEV is not set diff --git a/arch/powerpc/configs/mpc85xx_smp_defconfig b/arch/powerpc/configs/mpc85xx_smp_defconfig index 152fa05..b08ba94 100644 --- a/arch/powerpc/configs/mpc85xx_smp_defconfig +++ b/arch/powerpc/configs/mpc85xx_smp_defconfig @@ -136,6 +136,7 @@ CONFIG_MARVELL_PHY=y CONFIG_DAVICOM_PHY=y CONFIG_CICADA_PHY=y CONFIG_VITESSE_PHY=y +CONFIG_AT803X_PHY=y CONFIG_FIXED_PHY=y CONFIG_INPUT_FF_MEMLESS=m # CONFIG_INPUT_MOUSEDEV is not set -- 1.7.0.4 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v9 2/3] DMA: Freescale: Add new 8-channel DMA engine device tree nodes
On 09/02/2013 11:58 PM, Mark Rutland wrote:
Hi,
On Fri, Aug 30, 2013 at 12:26:19PM +0100, hongbo.zh...@freescale.com wrote:
From: Hongbo Zhang
Freescale QorIQ T4 and B4 introduce new 8-channel DMA engines, this patch adds
the device tree nodes for them.
Signed-off-by: Hongbo Zhang
---
.../devicetree/bindings/powerpc/fsl/dma.txt| 67
arch/powerpc/boot/dts/fsl/b4si-post.dtsi |4 +-
arch/powerpc/boot/dts/fsl/elo3-dma-0.dtsi | 82
arch/powerpc/boot/dts/fsl/elo3-dma-1.dtsi | 82
arch/powerpc/boot/dts/fsl/t4240si-post.dtsi|4 +-
5 files changed, 235 insertions(+), 4 deletions(-)
create mode 100644 arch/powerpc/boot/dts/fsl/elo3-dma-0.dtsi
create mode 100644 arch/powerpc/boot/dts/fsl/elo3-dma-1.dtsi
diff --git a/Documentation/devicetree/bindings/powerpc/fsl/dma.txt
b/Documentation/devicetree/bindings/powerpc/fsl/dma.txt
index ddf17af..332ac77 100644
--- a/Documentation/devicetree/bindings/powerpc/fsl/dma.txt
+++ b/Documentation/devicetree/bindings/powerpc/fsl/dma.txt
@@ -126,6 +126,73 @@ Example:
};
};
+** Freescale Elo3 DMA Controller
+ This is EloPlus controller with 8 channels, used in Freescale Txxx and Bxxx
I was under the impression EloPlus was the previous revision. Should
that say Elo3, or is Elo3 considered to be an EloPlus implementation?
In this patch 1/3 I revise the doc to make it clear we have Elo and
EloPlus, and I'm adding another new Elo3. Yes the only difference
between Elo3 and EloPlus is channel numbers(8 channels vs 4 channels),
so we can call "Elo3 is an 8-channel EloPlus"
+ series chips, such as t1040, t4240, b4860.
+
+Required properties:
+
+- compatible: must include "fsl,elo3-dma"
+- reg :
The example has two reg entries. What both are should be specified. From
what you described last time, it sounds like each is a status register
for four channels.
Presumably the first covers the channels at 0x0,0x80,0x100,0x180, and
the second covers the channels at 0x300,0x380,0x400,0x480? If the
registers have specific names in a datasheet, it would be worth
mentioning them.
Yes, each is a status register for four channels, you got it -- this
means my statement works.
Is it necessary to specify all the register names?
I can describe my two registers, but in other cases the reg entryies can
cover tens even hundreds of registers, just a summary is OK I think.
If the specification of the DMA controller allows for more channels, it
may be worth describing that case now.
This DMA controller doesn't allows for more channels. (Even if it does,
it should be another new controller)
+- ranges: describes the mapping between the address space of the
+ DMA channels and the address space of the DMA controller
This looks odd as a required property, and I'm slightly confused. Is
this used to map the reg values of the DMA channels, or is it used when
mapping the DMA address space (for which dma-ranges exists in ePAPR and
other bindings).
It is used to map the reg values of DMA channels.
+
+- DMA channel nodes:
+- compatible: must include "fsl,eloplus-dma-channel"
+- reg :
What does this represent? What are valid values?
In the example below it looks like these are offsets of control
registers within the dma controller.
Yes, they are offsets of control registers within dma controller, but
the contents in these registers are for dma channels.
Physically we have dma controller registers and dma channel registers,
they are in one continuous physical address space, we divide all these
registers into two controller/channel parts, according to contents in
these registers, common status registers for all channels are called dma
controller registers, otherwise channel specific registers are called
dma channel registers.
If the reg property may have any value, how do they get mapped to bits
in the status register(s)?
In fact, each channel has its own status register(and also other
registers), the dma controller status register is just aggregation of
all channel status register. (that seems duplicated somehow, maybe this
is due to hardware compatibility with legacy one, and the device tree
just describes the physical hardware without lie)
May some channels be unusable for some reason, or will all eight
channels be wired on any given Elo3 DMA?
Sorry, not get your point clearly, maybe you are clear now because of my
previous explanations.
Cheers,
Mark.
+- interrupts:
+- interrupt-parent : optional, if needed for interrupt mapping
+
+Example:
+dma@100300 {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ compatible = "fsl,elo3-dma";
+ reg = <0x100300 0x4>,
+ <0x100600 0x4>;
+ ranges = <0x0 0x100100 0x500>;
+ dma-channel@0 {
+ compatible = "fsl,eloplus-dm
[PATCH] powerpc: Add I2C bus multiplexer node for B4 and T4240QDS
In both B4 and T4240QDS platform PCA9547 I2C bus multiplexer is used.
Signed-off-by: Jia Hongtao
---
arch/powerpc/boot/dts/b4qds.dtsi | 4
arch/powerpc/boot/dts/t4240qds.dts | 4
2 files changed, 8 insertions(+)
diff --git a/arch/powerpc/boot/dts/b4qds.dtsi b/arch/powerpc/boot/dts/b4qds.dtsi
index e6d2f8f..2aa3399 100644
--- a/arch/powerpc/boot/dts/b4qds.dtsi
+++ b/arch/powerpc/boot/dts/b4qds.dtsi
@@ -120,6 +120,10 @@
};
i2c@118000 {
+ pca9547@77 {
+ compatible = "philips,pca9547";
+ reg = <0x77>;
+ };
eeprom@50 {
compatible = "at24,24c64";
reg = <0x50>;
diff --git a/arch/powerpc/boot/dts/t4240qds.dts
b/arch/powerpc/boot/dts/t4240qds.dts
index 0555976..084db57 100644
--- a/arch/powerpc/boot/dts/t4240qds.dts
+++ b/arch/powerpc/boot/dts/t4240qds.dts
@@ -118,6 +118,10 @@
};
i2c@118000 {
+ pca9547@77 {
+ compatible = "philips,pca9547";
+ reg = <0x77>;
+ };
eeprom@51 {
compatible = "at24,24c256";
reg = <0x51>;
--
1.8.0
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 3/7] powerpc/pci: use pci_is_pcie() to simplify code
Use pci_is_pcie() to simplify code.
Signed-off-by: Yijing Wang
Cc: Gavin Shan
Cc: Benjamin Herrenschmidt
Cc: Paul Mackerras
Cc: linuxppc-dev@lists.ozlabs.org
Cc: linux-ker...@vger.kernel.org
---
arch/powerpc/kernel/eeh.c |3 +--
arch/powerpc/sysdev/fsl_pci.c |2 +-
2 files changed, 2 insertions(+), 3 deletions(-)
diff --git a/arch/powerpc/kernel/eeh.c b/arch/powerpc/kernel/eeh.c
index 39954fe..b0bd41a 100644
--- a/arch/powerpc/kernel/eeh.c
+++ b/arch/powerpc/kernel/eeh.c
@@ -189,8 +189,7 @@ static size_t eeh_gather_pci_data(struct eeh_dev *edev,
char * buf, size_t len)
}
/* If PCI-E capable, dump PCI-E cap 10, and the AER */
- cap = pci_find_capability(dev, PCI_CAP_ID_EXP);
- if (cap) {
+ if (pci_is_pcie(dev)) {
n += scnprintf(buf+n, len-n, "pci-e cap10:\n");
printk(KERN_WARNING
"EEH: PCI-E capabilities and status follow:\n");
diff --git a/arch/powerpc/sysdev/fsl_pci.c b/arch/powerpc/sysdev/fsl_pci.c
index 46ac1dd..5402a1d 100644
--- a/arch/powerpc/sysdev/fsl_pci.c
+++ b/arch/powerpc/sysdev/fsl_pci.c
@@ -41,7 +41,7 @@ static void quirk_fsl_pcie_header(struct pci_dev *dev)
u8 hdr_type;
/* if we aren't a PCIe don't bother */
- if (!pci_find_capability(dev, PCI_CAP_ID_EXP))
+ if (!pci_is_pcie(dev))
return;
/* if we aren't in host mode don't bother */
--
1.7.1
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
