* Re: [PATCH v9 12/13] KVM: PPC: Add support for IOMMU in-kernel handling
From: Benjamin Herrenschmidt @ 2013-09-05 4:05 UTC (permalink / raw)
To: Gleb Natapov
Cc: kvm, Alexey Kardashevskiy, Alexander Graf, kvm-ppc, linux-kernel,
linux-mm, Paul Mackerras, Paolo Bonzini, linuxppc-dev,
David Gibson
In-Reply-To: <20130903105315.GY22899@redhat.com>
On Tue, 2013-09-03 at 13:53 +0300, Gleb Natapov wrote:
> > Or supporting all IOMMU links (and leaving emulated stuff as is) in on
> > "device" is the last thing I have to do and then you'll ack the patch?
> >
> I am concerned more about API here. Internal implementation details I
> leave to powerpc experts :)
So Gleb, I want to step in for a bit here.
While I understand that the new KVM device API is all nice and shiny and that this
whole thing should probably have been KVM devices in the first place (had they
existed or had we been told back then), the point is, the API for handling
HW IOMMUs that Alexey is trying to add is an extension of an existing mechanism
used for emulated IOMMUs.
The internal data structure is shared, and fundamentally, by forcing him to
use that new KVM device for the "new stuff", we create a oddball API with
an ioctl for one type of iommu and a KVM device for the other, which makes
the implementation a complete mess in the kernel (and you should care :-)
So for something completely new, I would tend to agree with you. However, I
still think that for this specific case, we should just plonk-in the original
ioctl proposed by Alexey and be done with it.
Cheers,
Ben.
^ permalink raw reply
* RE: [V2,2/2] powerpc/85xx: workaround for chips with MSI hardware errata
From: Jia Hongtao-B38951 @ 2013-09-05 4:00 UTC (permalink / raw)
To: Jia Hongtao-B38951, Wood Scott-B07421; +Cc: linuxppc-dev@lists.ozlabs.org
In-Reply-To: <20130628022833.GA28050@home.buserror.net>
> -----Original Message-----
> From: Jia Hongtao-B38951
> Sent: Monday, July 01, 2013 5:36 PM
> To: Wood Scott-B07421
> Cc: linuxppc-dev@lists.ozlabs.org; galak@kernel.crashing.org
> Subject: RE: [V2,2/2] powerpc/85xx: workaround for chips with MSI
> hardware errata
>=20
> > -----Original Message-----
> > From: Wood Scott-B07421
> > Sent: Friday, June 28, 2013 10:29 AM
> > To: Jia Hongtao-B38951
> > Cc: linuxppc-dev@lists.ozlabs.org; galak@kernel.crashing.org; Wood
> > Scott-
> > B07421
> > Subject: Re: [V2,2/2] powerpc/85xx: workaround for chips with MSI
> > hardware errata
> >
> > On Wed, Apr 03, 2013 at 10:03:18AM +0800, Hongtao Jia wrote:
> > > The MPIC version 2.0 has a MSI errata (errata PIC1 of mpc8544), It
> > > causes that neither MSI nor MSI-X can work fine. This is a
> > > workaround to allow MSI-X to function properly.
> > >
> > > Signed-off-by: Liu Shuo <soniccat.liu@gmail.com>
> > > Signed-off-by: Li Yang <leoli@freescale.com>
> > > Signed-off-by: Jia Hongtao <hongtao.jia@freescale.com>
> >
> > Building on 83xx:
> >
> > arch/powerpc/sysdev/built-in.o: In function `fsl_of_msi_probe':
> > fsl_msi.c:(.text+0x1464): undefined reference to
> > `fsl_mpic_primary_get_version'
> > make[1]: *** [vmlinux] Error 1
> > make: *** [sub-make] Error 2
> >
> > fsl_msi.c supports IPIC as well.
> >
> > -Scott
>=20
> Hi Scott,
> I updated the patch to fix this compile error just now.
> please refer to:
> http://patchwork.ozlabs.org/patch/256018/
>=20
> Thanks.
> -Hongtao
Hi Scott,
The 83xx compile issue has already been fixed.
Please have a review on this patch.
Thanks.
-Hongtao
^ permalink raw reply
* [PATCH V2] powerpc: Add I2C bus multiplexer node for B4 and T4240QDS
From: Jia Hongtao @ 2013-09-05 2:41 UTC (permalink / raw)
To: linuxppc-dev, B07421; +Cc: hongtao.jia, Wei.Yang
In both B4 and T4240QDS platform PCA9547 I2C bus multiplexer is used.
The sub-nodes are also reorganized according to right I2C topology.
Signed-off-by: Jia Hongtao <hongtao.jia@freescale.com>
---
V2 change log:
Reorganized the sub-nodes under I2C multiplexer to represent right topology.
arch/powerpc/boot/dts/b4qds.dtsi | 49 +++++++++++++++++-----------
arch/powerpc/boot/dts/t4240qds.dts | 67 ++++++++++++++++++++++----------------
2 files changed, 69 insertions(+), 47 deletions(-)
diff --git a/arch/powerpc/boot/dts/b4qds.dtsi b/arch/powerpc/boot/dts/b4qds.dtsi
index e6d2f8f..de8cb38 100644
--- a/arch/powerpc/boot/dts/b4qds.dtsi
+++ b/arch/powerpc/boot/dts/b4qds.dtsi
@@ -120,25 +120,36 @@
};
i2c@118000 {
- eeprom@50 {
- compatible = "at24,24c64";
- reg = <0x50>;
- };
- eeprom@51 {
- compatible = "at24,24c256";
- reg = <0x51>;
- };
- eeprom@53 {
- compatible = "at24,24c256";
- reg = <0x53>;
- };
- eeprom@57 {
- compatible = "at24,24c256";
- reg = <0x57>;
- };
- rtc@68 {
- compatible = "dallas,ds3232";
- reg = <0x68>;
+ pca9547@77 {
+ compatible = "philips,pca9547";
+ reg = <0x77>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ channel@0 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0>;
+ eeprom@50 {
+ compatible = "at24,24c64";
+ reg = <0x50>;
+ };
+ eeprom@51 {
+ compatible = "at24,24c256";
+ reg = <0x51>;
+ };
+ eeprom@53 {
+ compatible = "at24,24c256";
+ reg = <0x53>;
+ };
+ eeprom@57 {
+ compatible = "at24,24c256";
+ reg = <0x57>;
+ };
+ rtc@68 {
+ compatible = "dallas,ds3232";
+ reg = <0x68>;
+ };
+ };
};
};
diff --git a/arch/powerpc/boot/dts/t4240qds.dts b/arch/powerpc/boot/dts/t4240qds.dts
index 0555976..ae68595 100644
--- a/arch/powerpc/boot/dts/t4240qds.dts
+++ b/arch/powerpc/boot/dts/t4240qds.dts
@@ -118,34 +118,45 @@
};
i2c@118000 {
- 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>;
+ 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>;
+ };
+ };
};
};
};
--
1.8.0
^ permalink raw reply related
* Re: [PATCH] [RFC PATCH v1 1/1] powerpc/85xx: Wakeup kexec smp slave cpus in second kernel
From: chen.yu10 @ 2013-09-05 2:22 UTC (permalink / raw)
To: wei.yang
Cc: chenhui.zhao, wangshilong1991, liu.xiang6, lu.zhongjun,
linuxppc-dev
In-Reply-To: <1378160357-3653-1-git-send-email-chenyu105@gmail.com>
> From: Chen Yu <chen.yu10@zte.com.cn>
>
> 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
Well, there might be someting wrong with my debug version.
It succeed this morning on linux 3.10.7 ,arch/powerpc/boot/corenet32_smp_defconfig,with kexec-tools-2.0.4,
The second kernel is up with 4 cpus.
I'll check my previous version.
Thank you.
^ permalink raw reply
* Re: [PATCH 3/7] powerpc/pci: use pci_is_pcie() to simplify code
From: Kumar Gala @ 2013-09-04 21:07 UTC (permalink / raw)
To: Yijing Wang
Cc: Gavin Shan, Hanjun Guo, linux-kernel, James E.J. Bottomley,
Paul Mackerras, linux-pci, Bjorn Helgaas, linuxppc-dev,
David S. Miller
In-Reply-To: <1378193715-25328-3-git-send-email-wangyijing@huawei.com>
On Sep 3, 2013, at 2:35 AM, Yijing Wang wrote:
> Use pci_is_pcie() to simplify code.
>
> Signed-off-by: Yijing Wang <wangyijing@huawei.com>
> Cc: Gavin Shan <shangw@linux.vnet.ibm.com>
> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> Cc: Paul Mackerras <paulus@samba.org>
> Cc: linuxppc-dev@lists.ozlabs.org
> Cc: linux-kernel@vger.kernel.org
> ---
> arch/powerpc/kernel/eeh.c | 3 +--
> arch/powerpc/sysdev/fsl_pci.c | 2 +-
> 2 files changed, 2 insertions(+), 3 deletions(-)
Acked-by: Kumar Gala <galak@kernel.crashing.org>
(for the fsl_pci.c) change
- k
^ permalink raw reply
* Re: Ethernet over PCIe driver for Inter-Processor Communication
From: David Hawkins @ 2013-09-04 19:28 UTC (permalink / raw)
To: Saravanan S
Cc: naishab, linuxppc-dev@lists.ozlabs.org, Michael George,
Ira W. Snyder
In-Reply-To: <CAEqOc-SYzOFSaUPLY2HS32c0PVnzwBNSVy3EG=EHOv2of2AGaQ@mail.gmail.com>
Hi S.Saravanan,
>> You'll have two drivers;
>> * The root-complex.
>> This is a standard PCIe driver, so you'll just follow convention
>> there
>> * The end-point driver.
>> This driver needs to use the PCIe bus, but its not responsible
>> for the PCIe bus in the way a root-complex is. The driver needs
>> to know what the root-complex is interrupting it for, eg.,
>> "transmitter empty" (I've read your last message) or "receiver
>> ready" (there is a message from me, waiting for you).
>> So you need at least two unique interrupts or messages from the
>> root-complex to the end-point.
>
> I am happy to inform you that I finally found a way to register for the
> interrupts from RC to EP. Now I have made a simple root and end point
> network driver for two MPC8640 nodes that are now up and running and I
> could successfully ping across them.
That is awesome! :)
> The basic flow is as follows.
>
> _Root Complex Driver_:
> 1. It discovers the EP processor node and gets its base
> addresses.(BAR 1 and BAR 2)
> 2. It sets a single inbound window mapping a portion of its RAM to
> PCI space.(This is to allow inbound memory writes from EP).
> 3.It enables the MSI interrupt for the EP and registers an interrupt
> handler for the same.(To receive interrupts from EP. Note this is
> conventional PCI method)
> 4. On receiving a transmit request from kernel it initiates a DMA
> memory copy of the packet(in the socket buffer) to the EP memory through
> BAR 1. After DMA finishes it sends an interrupt to EP by writing to its
> msi register mapped in BAR2.
> 5 . On reception of a packet(from EP) the msi interrupt handler is
> called and it copies the packet in RAM to a socket buffer and passes it
> to the kernel.
> _
> _
> _End Point Driver:
>
> _
> 1. It sets up the internal msi interrupt structure and registers an
> interrupt handler.(To receive interrupts from RC. Note this is not done
> by default in kernel as it is a slave and thus is added in the driver.)
> 2. It sets two inbound windows
> i) BAR1 maps to RAM area.(To allow inbound memory write from RC)
> ii) BAR2 is mapped to PIC register area.(To allow inbound message
> interrupt register write from RC)
> 3. It sets up one outbound window to map its local address to PCI
> address of RC .(To allow outbound memory write to RC RAM space).
> 4. On receiving a transmit request from kernel it initiates a DMA memory
> copy of the packet(in the socket buffer) to the RC memory through the
> outbound window. After DMA finishes it sends an interrupt to RC through
> the conventional PCI MSI transaction.
> 5. On reception of a packet(from RC) the msi interrupt handler is
> called and it copies the packet in RAM to a socket buffer and passes it
> to the kernel.
>
> So basically a bidirectional communication channel has been established
> but the driver is not ready for performance checks yet. I am working on
> it now. I will report any improvements obtained in this regard.
Now that you have processor-to-processor communications working,
it would be useful to figure out an architecture for the driver
that will make it acceptable to the community at large.
For example, can you make this driver work from U-Boot too?
Eg., can your driver support a root-complex running Linux and
end-points running U-Boot that fetch their kernel via the
PCIe network, and then boot Linux, and switch over to using
the Linux version of the PCIe network driver.
This is what Ira has done with the PCInet driver, and it allows
us to have an x86 PCI host CPU that then boots multiple
MPC8349EA PowerPC peripheral CPUs.
Ira had discussions with various kernel developers, and I believe
the general feedback was "Can this be made to work with virtio?".
Ira can comment more on that.
>> You're on the right track. When I looked at using the messaging
>> registers on the PLX PCI device, I started by simply creating
>> what was effectively a serial port (one char at a time).
>> Section 4 explains the interlocking required between two processors
>>
>> <http://www.ovro.caltech.edu/~dwh/correlator/pdf/cobra_driver.pdf>
>
> Thank You for this document . Was very helpful in understanding the
> basics of a Host Target Communication and implementation of a virtual
> driver for the same.
I'm glad to hear it helped.
Cheers,
Dave
^ permalink raw reply
* Re: Ethernet over PCIe driver for Inter-Processor Communication
From: Saravanan S @ 2013-09-04 18:34 UTC (permalink / raw)
To: David Hawkins
Cc: naishab, linuxppc-dev@lists.ozlabs.org, Michael George,
Ira W. Snyder
In-Reply-To: <5220DF42.2030208@ovro.caltech.edu>
[-- Attachment #1: Type: text/plain, Size: 6636 bytes --]
Hi All,
On Fri, Aug 30, 2013 at 11:36 PM, David Hawkins <dwh@ovro.caltech.edu>wrote:
> Hi S.Saravanan,
>
>>
>> I successfully mapped the Programmable Interrupt Controller registers
>> in the EP to the PCI space. Thus now I can write the shared message
>>
>> interrupt registers in the EP from the RC over PCI.
>>
>
> Excellent.
>
>
> But I am facing the following problems now.
>>
>> 1) In my driver at EP, to register for this interrupt I need to know the
>> hardware irq number but I can't find any interrupt number assigned by
>> the PIC for the messages interrupt sources(Page 451 , MPC8641DRM manual).
>> 2) Otherwise i need to get the virtual irq number assigned by kernel
>> corresponding to the message interrupt . I am unable to find a method to
>> get this also.
>>
>
> I recall having to ask a similar question when trying to map a
> GPIO interrupt into a Linux interrupt number. I forget the
> convention (I'm "the hardware guy"). It may be a device tree
> thing, or an offset, I'll let someone more knowledgeable comment.
>
> In the RC side driver i get the virtual irq number after calling
>> pci_enable_msi() which is straightforward.
>> I studied the RC code which sets up shared message interrupts (Page 481,
>> MPC manual) for PCI MSI interrupts . When msi is enabled the
>> "arch_setup_msi_irqs()" is called leading to the fsl_setup_msi_irqs()
>> (http://lxr.free-electrons.**com/source/arch/powerpc/**
>> sysdev/fsl_msi.c?v=3.7#L151<http://lxr.free-electrons.com/source/arch/powerpc/sysdev/fsl_msi.c?v=3.7#L151>
>> )
>> . In this function the virtual irq no is obtained as below:
>>
>> /virq = irq_create_mapping(msi_data->**irqhost, hwirq);/
>>
>>
>> In the above function the hardware irq number is same as the value
>> written into the Shared Message Signaled Interrupt Index Register (Page
>> 482) which is strange. Further these functions are called in the RC
>> during pci_probe at boot time or when pci_enable_msi() is called . Thus
>> there is a always a PCI slave device context to it. However I require
>> to do it in the EP which has no pci probing nor any pci device
>> reference whatsoever as it a slave. Is this approach right ?
>>
>
> I'm not sure.
>
> You'll have two drivers;
> * The root-complex.
> This is a standard PCIe driver, so you'll just follow convention
> there
> * The end-point driver.
> This driver needs to use the PCIe bus, but its not responsible
> for the PCIe bus in the way a root-complex is. The driver needs
> to know what the root-complex is interrupting it for, eg.,
> "transmitter empty" (I've read your last message) or "receiver
> ready" (there is a message from me, waiting for you).
> So you need at least two unique interrupts or messages from the
> root-complex to the end-point.
>
I am happy to inform you that I finally found a way to register for the
interrupts from RC to EP. Now I have made a simple root and end point
network driver for two MPC8640 nodes that are now up and running and I
could successfully ping across them. The basic flow is as follows.
*Root Complex Driver*:
1. It discovers the EP processor node and gets its base addresses.(BAR 1
and BAR 2)
2. It sets a single inbound window mapping a portion of its RAM to PCI
space.(This is to allow inbound memory writes from EP).
3.It enables the MSI interrupt for the EP and registers an interrupt
handler for the same.(To receive interrupts from EP. Note this is
conventional PCI method)
4. On receiving a transmit request from kernel it initiates a DMA
memory copy of the packet(in the socket buffer) to the EP memory through
BAR 1. After DMA finishes it sends an interrupt to EP by writing to its msi
register mapped in BAR2.
5 . On reception of a packet(from EP) the msi interrupt handler is
called and it copies the packet in RAM to a socket buffer and passes it to
the kernel.
*
*
*End Point Driver:
*
1. It sets up the internal msi interrupt structure and registers an
interrupt handler.(To receive interrupts from RC. Note this is not done by
default in kernel as it is a slave and thus is added in the driver.)
2. It sets two inbound windows
i) BAR1 maps to RAM area.(To allow inbound memory write from RC)
ii) BAR2 is mapped to PIC register area.(To allow inbound message
interrupt register write from RC)
3. It sets up one outbound window to map its local address to PCI address
of RC .(To allow outbound memory write to RC RAM space).
4. On receiving a transmit request from kernel it initiates a DMA memory
copy of the packet(in the socket buffer) to the RC memory through the
outbound window. After DMA finishes it sends an interrupt to RC through the
conventional PCI MSI transaction.
5. On reception of a packet(from RC) the msi interrupt handler is called
and it copies the packet in RAM to a socket buffer and passes it to the
kernel.
So basically a bidirectional communication channel has been established
but the driver is not ready for performance checks yet. I am working on it
now. I will report any improvements obtained in this regard.
> Its always a good idea to discuss different options, and to stub out
>>> drivers or create minimal (but functional) drivers. That way you'll
>>> be able to see how similar your new driver is to other drivers, and
>>> you'll quickly discover if there is a hardware feature in the
>>> existing driver that you cannot emulate (eg., some SRIO feature
>>> used by the rionet driver).
>>>
>>
>> Right now I am trying a very primitive driver just to check the
>> feasibility of bi-directional communication between the RC and the EP.
>> Once this is established I will be in a better position to get inputs
>> on making it a more effective one.
>>
>
> You're on the right track. When I looked at using the messaging
> registers on the PLX PCI device, I started by simply creating
> what was effectively a serial port (one char at a time).
> Section 4 explains the interlocking required between two processors
>
> http://www.ovro.caltech.edu/~**dwh/correlator/pdf/cobra_**driver.pdf<http://www.ovro.caltech.edu/~dwh/correlator/pdf/cobra_driver.pdf>
>
> Thank You for this document . Was very helpful in understanding the basics
of a Host Target Communication and implementation of a virtual driver for
the same.
> The mailbox/interrupt registers are effectively being used to
> implement a mutex between the two processors.
>
> I think at one point Ira took similar code to this and hooked
> it into the actual serial layer, so that you had a tty over
> PCI. You could always start with a simplification like that too.
>
> Cheers,
> Dave
>
>
Regards,
S.Saravanan
[-- Attachment #2: Type: text/html, Size: 8771 bytes --]
^ permalink raw reply
* [PATCH] powerpc: default arch idle could cede processor on pseries
From: Vaidyanathan Srinivasan @ 2013-09-04 18:19 UTC (permalink / raw)
To: Paul Mackerras, Benjamin Herrenschmidt; +Cc: Deepthi Dharwar, linuxppc-dev
Hi,
Idle routines on pseries were rearranged so that cpuidle can do
an optimized idle state selection. However, until cpuidle takes
over during boot, the idle loop spins for a short while. This
actually affected bootup time since spinning idle sibling threads
slows down master cpu that executes bootup code.
The following patch enables pseries system to yield to hypervisor and
stop spinning by calling cede_processor() until cpuidle can take over
and do optimal idle state selection.
Bootup time can be reduced to half on small guest where most of the
time is spend before device init.
--Vaidy
powerpc: default arch idle should cede processor on pseries
On IBM POWER platform (pseries), use cede_processor()
in arch idle to save cycles until cpuidle takes over.
This helps speedup boot by having SMT threads stop and yield to
master thread rather than spinning until cpuidle in initialized.
Reported-by: Paul Mackerras <paulus@samba.org>
Signed-off-by: Vaidyanathan Srinivasan <svaidy@linux.vnet.ibm.com>
Acked-by: Deepthi Dharwar <deepthi@linux.vnet.ibm.com>
diff --git a/arch/powerpc/platforms/pseries/setup.c b/arch/powerpc/platforms/pseries/setup.c
index c11c823..fd4f995 100644
--- a/arch/powerpc/platforms/pseries/setup.c
+++ b/arch/powerpc/platforms/pseries/setup.c
@@ -362,10 +362,22 @@ static void pSeries_idle(void)
if (cpuidle_idle_call()) {
/* On error, execute default handler
* to go into low thread priority and possibly
- * low power mode.
+ * low power mode by ceding processor to hypervisor
*/
- HMT_low();
- HMT_very_low();
+
+ /* Indicate to hypervisor that we are idle. */
+ get_lppaca()->idle = 1;
+
+ /*
+ * Yield the processor to the hypervisor. We return if
+ * an external interrupt occurs (which are driven prior
+ * to returning here) or if a prod occurs from another
+ * processor. When returning here, external interrupts
+ * are enabled.
+ */
+ cede_processor();
+
+ get_lppaca()->idle = 0;
}
}
^ permalink raw reply related
* RE: [RFC PATCH v2 04/11] pstore: Add compression support to pstore
From: Seiji Aguchi @ 2013-09-04 16:39 UTC (permalink / raw)
To: Luck, Tony, Aruna Balakrishnaiah
Cc: jkenisto@linux.vnet.ibm.com, keescook@chromium.org,
mahesh@linux.vnet.ibm.com, cbouatmailru@gmail.com,
linux-kernel@vger.kernel.org, linuxppc-dev@ozlabs.org,
ccross@android.com
In-Reply-To: <3908561D78D1C84285E8C5FCA982C28F31CDB23E@ORSMSX106.amr.corp.intel.com>
> But let's make sure that efivars, erst,
> etc. are all happy with the changes we make before I ask Linus to pull an=
other
> pstore piece.
I will test efivars when Aruna posts the bugfix patches.
Seiji
> -----Original Message-----
> From: Luck, Tony [mailto:tony.luck@intel.com]
> Sent: Wednesday, September 04, 2013 12:11 PM
> To: Aruna Balakrishnaiah; Seiji Aguchi
> Cc: jkenisto@linux.vnet.ibm.com; keescook@chromium.org; mahesh@linux.vnet=
.ibm.com; ccross@android.com; linux-
> kernel@vger.kernel.org; linuxppc-dev@ozlabs.org; cbouatmailru@gmail.com
> Subject: RE: [RFC PATCH v2 04/11] pstore: Add compression support to psto=
re
>=20
> > 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.
> ...
>=20
> > Yes this can be changed to zlib_inflateInit2().
>=20
> Original patch series was just pulled by Linus ... so we'll need a patch =
on top
> of current Linus git tree to fix these issues. But let's make sure that =
efivars, erst,
> etc. are all happy with the changes we make before I ask Linus to pull an=
other
> pstore piece.
>=20
> Thanks
>=20
> -Tony
^ permalink raw reply
* Re: [PATCH V3 1/2] powerpc/85xx: Add QE common init functions
From: Scott Wood @ 2013-09-04 16:26 UTC (permalink / raw)
To: Xie Xiaobo; +Cc: linuxppc-dev
In-Reply-To: <1378116699-18826-1-git-send-email-X.Xie@freescale.com>
On Mon, 2013-09-02 at 18:11 +0800, Xie Xiaobo wrote:
> Define two QE init functions in common file, and avoid
> the same codes being duplicated in board files.
>
> Signed-off-by: Xie Xiaobo <X.Xie@freescale.com>
> ---
> V3 -> V2: Nochange
>
> arch/powerpc/platforms/85xx/common.c | 47 +++++++++++++++++++++++++++++++++++
> arch/powerpc/platforms/85xx/mpc85xx.h | 8 ++++++
> 2 files changed, 55 insertions(+)
Don't just copy it; remove it from the place you copied from and have
that code call the common version.
-Scott
^ permalink raw reply
* Re: [PATCH V3 2/2] powerpc/85xx: Add TWR-P1025 board support
From: Scott Wood @ 2013-09-04 16:25 UTC (permalink / raw)
To: Xie Xiaobo; +Cc: linuxppc-dev, Michael Johnston
In-Reply-To: <1378116699-18826-2-git-send-email-X.Xie@freescale.com>
On Mon, 2013-09-02 at 18:11 +0800, Xie Xiaobo wrote:
> +&soc {
> + usb@22000 {
> + phy_type = "ulpi";
> + };
> +
> + mdio@24000 {
> + phy0: ethernet-phy@2 {
> + interrupt-parent = <&mpic>;
> + interrupts = <1 1>;
> + reg = <0x2>;
> + };
> +
> + phy1: ethernet-phy@1 {
> + interrupt-parent = <&mpic>;
> + interrupts = <2 1>;
> + reg = <0x1>;
> + };
Again, #interrupt-cells is 4.
Please respond to feedback rather than ignoring it and reposting the
same thing without comment.
-Scott
^ permalink raw reply
* RE: [RFC PATCH v2 04/11] pstore: Add compression support to pstore
From: Luck, Tony @ 2013-09-04 16:11 UTC (permalink / raw)
To: Aruna Balakrishnaiah, Seiji Aguchi
Cc: jkenisto@linux.vnet.ibm.com, keescook@chromium.org,
mahesh@linux.vnet.ibm.com, cbouatmailru@gmail.com,
linux-kernel@vger.kernel.org, linuxppc-dev@ozlabs.org,
ccross@android.com
In-Reply-To: <5226CC9D.30904@linux.vnet.ibm.com>
> The reason behind compression failure is the size of big_oops_buf which i=
s too
> big for efivars case. I will do some experiments with different kind of t=
exts
> for buffer size 1024 to check if 100/53 suits for all the cases.
...
> Yes this can be changed to zlib_inflateInit2().
Original patch series was just pulled by Linus ... so we'll need a patch on=
top
of current Linus git tree to fix these issues. But let's make sure that ef=
ivars, erst,
etc. are all happy with the changes we make before I ask Linus to pull anot=
her
pstore piece.
Thanks
-Tony
^ permalink raw reply
* [PATCH 1/2] mm/arch: use __free_reserved_page() to simplify the code
From: Xishi Qiu @ 2013-09-04 10:41 UTC (permalink / raw)
To: plagnioj, tomi.valkeinen, james.hogan, monstr, benh, paulus,
Andrew Morton
Cc: linux-fbdev, microblaze-uclinux, LKML, linux-mm, Xishi Qiu,
linuxppc-dev
Use __free_reserved_page() to simplify the code in arch.
It used split_page() in consistent_alloc()/__dma_alloc_coherent()/dma_alloc_coherent(),
so page->_count == 1, and we can free it safely.
__free_reserved_page()
ClearPageReserved()
init_page_count() // it won't change the value
__free_page()
Signed-off-by: Xishi Qiu <qiuxishi@huawei.com>
---
arch/metag/kernel/dma.c | 4 +---
arch/microblaze/mm/consistent.c | 7 ++-----
arch/powerpc/mm/dma-noncoherent.c | 4 +---
3 files changed, 4 insertions(+), 11 deletions(-)
diff --git a/arch/metag/kernel/dma.c b/arch/metag/kernel/dma.c
index 8c00ded..db589ad 100644
--- a/arch/metag/kernel/dma.c
+++ b/arch/metag/kernel/dma.c
@@ -305,9 +305,7 @@ void dma_free_coherent(struct device *dev, size_t size,
if (pfn_valid(pfn)) {
struct page *page = pfn_to_page(pfn);
- ClearPageReserved(page);
-
- __free_page(page);
+ __free_reserved_page(page);
continue;
}
}
diff --git a/arch/microblaze/mm/consistent.c b/arch/microblaze/mm/consistent.c
index 5226b09..dbbf224 100644
--- a/arch/microblaze/mm/consistent.c
+++ b/arch/microblaze/mm/consistent.c
@@ -176,8 +176,7 @@ void consistent_free(size_t size, void *vaddr)
page = virt_to_page(vaddr);
do {
- ClearPageReserved(page);
- __free_page(page);
+ __free_reserved_page(page);
page++;
} while (size -= PAGE_SIZE);
#else
@@ -194,9 +193,7 @@ void consistent_free(size_t size, void *vaddr)
pte_clear(&init_mm, (unsigned int)vaddr, ptep);
if (pfn_valid(pfn)) {
page = pfn_to_page(pfn);
-
- ClearPageReserved(page);
- __free_page(page);
+ __free_reserved_page(page);
}
}
vaddr += PAGE_SIZE;
diff --git a/arch/powerpc/mm/dma-noncoherent.c b/arch/powerpc/mm/dma-noncoherent.c
index 6747eec..7b6c107 100644
--- a/arch/powerpc/mm/dma-noncoherent.c
+++ b/arch/powerpc/mm/dma-noncoherent.c
@@ -287,9 +287,7 @@ void __dma_free_coherent(size_t size, void *vaddr)
pte_clear(&init_mm, addr, ptep);
if (pfn_valid(pfn)) {
struct page *page = pfn_to_page(pfn);
-
- ClearPageReserved(page);
- __free_page(page);
+ __free_reserved_page(page);
}
}
addr += PAGE_SIZE;
--
1.7.1
^ permalink raw reply related
* [PATCH 2/2] mm/driver: use __free_reserved_page() to simplify the code
From: Xishi Qiu @ 2013-09-04 10:41 UTC (permalink / raw)
To: plagnioj, tomi.valkeinen, james.hogan, monstr, benh, paulus,
Andrew Morton
Cc: linux-fbdev, microblaze-uclinux, LKML, linux-mm, Xishi Qiu,
linuxppc-dev
Use __free_reserved_page() to simplify the code in the others.
Signed-off-by: Xishi Qiu <qiuxishi@huawei.com>
---
drivers/video/acornfb.c | 4 +---
1 files changed, 1 insertions(+), 3 deletions(-)
diff --git a/drivers/video/acornfb.c b/drivers/video/acornfb.c
index 6488a73..4ef302a 100644
--- a/drivers/video/acornfb.c
+++ b/drivers/video/acornfb.c
@@ -1205,9 +1205,7 @@ free_unused_pages(unsigned int virtual_start, unsigned int virtual_end)
* the page.
*/
page = virt_to_page(virtual_start);
- ClearPageReserved(page);
- init_page_count(page);
- free_page(virtual_start);
+ __free_reserved_page(page);
virtual_start += PAGE_SIZE;
mb_freed += PAGE_SIZE / 1024;
--
1.7.1
^ permalink raw reply related
* Re: [PATCH] ppc: bpf_jit: support MOD operation
From: Daniel Borkmann @ 2013-09-04 7:04 UTC (permalink / raw)
To: Vladimir Murzin; +Cc: Matt Evans, paulus, netdev, linuxppc-dev, davem
In-Reply-To: <52264C0D.3000409@redhat.com>
On 09/03/2013 10:52 PM, Daniel Borkmann wrote:
> On 09/03/2013 09:58 PM, Vladimir Murzin wrote:
[...]
>>> 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, 0x0000000a },
> { 0x94, 0, 0, 0x00000008 },
> { 0x16, 0, 0, 0x00000000 },
Plus something like ...
ldxi #0
mod x
ret a
For longer-term testing, also trinity has BPF support. ;)
> 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
^ permalink raw reply
* Re: [RFC PATCH v2 04/11] pstore: Add compression support to pstore
From: Aruna Balakrishnaiah @ 2013-09-04 6:01 UTC (permalink / raw)
To: Seiji Aguchi
Cc: jkenisto@linux.vnet.ibm.com, Luck, Tony, keescook@chromium.org,
mahesh@linux.vnet.ibm.com, cbouatmailru@gmail.com,
linux-kernel@vger.kernel.org, linuxppc-dev@ozlabs.org,
ccross@android.com
In-Reply-To: <A5ED84D3BB3A384992CBB9C77DEDA4D443E9E24D@USINDEM103.corp.hds.com>
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.
>
> <snip>
> Panic#2 Part1
> <4>[ 75.665020] [<ffffffff811af59c>] SyS_write+0x4c/0xa0
> <4>[ 75.665020] [<ffffffff8168be82>] 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 <c6> 04 25 00 00 00 00 01 5d c3 0f 1f 44 00 00 55 31 c0 c7 05 5e
> <1>[ 75.665020] RIP [<ffffffff813d3946>] sysrq_handle_crash+0x16/0x20
> <4>[ 75.665020] RSP <ffff88007852de80>
> <4>[ 75.665020] CR2: 0000000000000000
> <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=2222 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
> <snip>
>
> Seiji
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev
>
^ permalink raw reply
* Re: [PATCH] powerpc: Add I2C bus multiplexer node for B4 and T4240QDS
From: Yang,Wei @ 2013-09-04 4:27 UTC (permalink / raw)
To: Tang Yuantian-B29983
Cc: Wood Scott-B07421, linuxppc-dev@lists.ozlabs.org,
Jia Hongtao-B38951
In-Reply-To: <D07C73A334FF604B95B3CBD2A545D07B15056D2E@039-SN2MPN1-011.039d.mgd.msft.net>
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.com@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.Yang@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 <hongtao.jia@freescale.com>
>>>> ---
>>>> 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
^ permalink raw reply
* RE: [PATCH] powerpc: Add I2C bus multiplexer node for B4 and T4240QDS
From: Jia Hongtao-B38951 @ 2013-09-04 4:10 UTC (permalink / raw)
To: Tang Yuantian-B29983, Yang,Wei
Cc: Wood Scott-B07421, linuxppc-dev@lists.ozlabs.org
In-Reply-To: <D07C73A334FF604B95B3CBD2A545D07B15056D2E@039-SN2MPN1-011.039d.mgd.msft.net>
SGkgWXVhbnRpYW4sDQpZZXMsIHlvdSBhcmUgcmlnaHQuDQoNCkhpIFdlaSwNCkkgbWlzdW5kZXJz
dG9vZCB5b3VyIGlkZWEuDQpJIGFncmVlIGl0IGFuZCBJIHdpbGwgc3VibWl0IFYyIHBhdGNoIHRv
IHVwZGF0ZSBpdCBzb29uLg0KDQpUaGFua3MuDQotSG9uZ3Rhbw0KDQo+IC0tLS0tT3JpZ2luYWwg
TWVzc2FnZS0tLS0tDQo+IEZyb206IFRhbmcgWXVhbnRpYW4tQjI5OTgzDQo+IFNlbnQ6IFdlZG5l
c2RheSwgU2VwdGVtYmVyIDA0LCAyMDEzIDEyOjA0IFBNDQo+IFRvOiBKaWEgSG9uZ3Rhby1CMzg5
NTE7IFlhbmcsV2VpDQo+IENjOiBXb29kIFNjb3R0LUIwNzQyMTsgbGludXhwcGMtZGV2QGxpc3Rz
Lm96bGFicy5vcmcNCj4gU3ViamVjdDogUkU6IFtQQVRDSF0gcG93ZXJwYzogQWRkIEkyQyBidXMg
bXVsdGlwbGV4ZXIgbm9kZSBmb3IgQjQgYW5kDQo+IFQ0MjQwUURTDQo+IA0KPiBIaSwNCj4gSSBu
b3RpY2VkIHRoYXQgdGhlcmUgYXJlIGFscmVhZHkgc29tZSBub2RlcyBpbiBpMmMgYnVzLg0KPiBZ
b3Ugc2hvdWxkIGF0IGxlYXN0IG1vdmUgdGhlIGV4aXN0aW5nIG5vZGUgaW50byBQQ0E5NTQ3Lg0K
PiANCj4gVGhhbmtzLA0KPiBZdWFudGlhbg0KPiANCj4gDQo+ID4gLS0tLS1PcmlnaW5hbCBNZXNz
YWdlLS0tLS0NCj4gPiBGcm9tOiBMaW51eHBwYy1kZXYgW21haWx0bzpsaW51eHBwYy1kZXYtDQo+
ID4gYm91bmNlcytiMjk5ODM9ZnJlZXNjYWxlLmNvbUBsaXN0cy5vemxhYnMub3JnXSBPbiBCZWhh
bGYgT2YgSmlhDQo+ID4gYm91bmNlcytIb25ndGFvLQ0KPiA+IEIzODk1MQ0KPiA+IFNlbnQ6IDIw
MTPE6jnUwjTI1SDQx8bayP0gMTE6MzgNCj4gPiBUbzogWWFuZyxXZWkNCj4gPiBDYzogV29vZCBT
Y290dC1CMDc0MjE7IGxpbnV4cHBjLWRldkBsaXN0cy5vemxhYnMub3JnDQo+ID4gU3ViamVjdDog
UkU6IFtQQVRDSF0gcG93ZXJwYzogQWRkIEkyQyBidXMgbXVsdGlwbGV4ZXIgbm9kZSBmb3IgQjQg
YW5kDQo+ID4gVDQyNDBRRFMNCj4gPg0KPiA+IEhpIFdlaSwNCj4gPg0KPiA+IEkgdG90YWxseSBh
Z3JlZSB0aGF0IHRoZSBpMmMgbm9kZXMgdG9wb2xvZ3kgc2hvdWxkIGVuZCB1cCBsaWtlIHlvdSBz
YWlkLg0KPiA+DQo+ID4gQnV0IEkgdGhpbmsgYWRkaW5nIHN1Yi1ub2RlcyBzaG91bGQgc3RlcCBi
eSBzdGVwLg0KPiA+IEFjdHVhbGx5IHRoZSBoYXJkd2FyZSBpMmMgdG9wb2xvZ3kgYXJlIGh1Z2Ug
bGlrZSBvbiBUNC4NCj4gPiBTbyBJJ2QgbGlrZSB0byBhZGRpbmcgbm9kZXMgd2hlbiB3ZSBuZWVk
ZWQuDQo+ID4gSWYgeW91IHRoaW5rIHRoZSBzdWItbm9kZXMgYXJlIG5lZWRlZCBwbGVhc2Ugc2Vu
ZCBhbm90aGVyIHBhdGNoIGJhc2VkDQo+ID4gb24gbWluZS4NCj4gPiBJIHRoaW5rIHRoaXMgaXMg
dGhlIG1vcmUgcmVhc29uYWJsZSB3YXkuDQo+ID4NCj4gPiBUaGFua3MuDQo+ID4NCj4gPiAtSG9u
Z3Rhbw0KPiA+DQo+ID4NCj4gPiA+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ID4gPiBG
cm9tOiBZYW5nLFdlaSBbbWFpbHRvOldlaS5ZYW5nQHdpbmRyaXZlci5jb21dDQo+ID4gPiBTZW50
OiBXZWRuZXNkYXksIFNlcHRlbWJlciAwNCwgMjAxMyA5OjI3IEFNDQo+ID4gPiBUbzogSmlhIEhv
bmd0YW8tQjM4OTUxDQo+ID4gPiBDYzogbGludXhwcGMtZGV2QGxpc3RzLm96bGFicy5vcmc7IFdv
b2QgU2NvdHQtQjA3NDIxOyBKaWENCj4gPiA+IEhvbmd0YW8tQjM4OTUxDQo+ID4gPiBTdWJqZWN0
OiBSZTogW1BBVENIXSBwb3dlcnBjOiBBZGQgSTJDIGJ1cyBtdWx0aXBsZXhlciBub2RlIGZvciBC
NA0KPiA+ID4gYW5kIFQ0MjQwUURTDQo+ID4gPg0KPiA+ID4gT24gMDkvMDMvMjAxMyAwMzo1MSBQ
TSwgSmlhIEhvbmd0YW8gd3JvdGU6DQo+ID4gPiA+IEluIGJvdGggQjQgYW5kIFQ0MjQwUURTIHBs
YXRmb3JtIFBDQTk1NDcgSTJDIGJ1cyBtdWx0aXBsZXhlciBpcw0KPiB1c2VkLg0KPiA+ID4NCj4g
PiA+IEhpIEhvbmd0YW8sDQo+ID4gPg0KPiA+ID4gSWYgeW91IHdhbnQgdG8gc3VwcG9ydCBJMkMg
YnVzIG11bHRpcGxleGVyLCBmb3IgVDQgYW5kIEI0UURTDQo+ID4gPiBwbGF0Zm9ybSwgc2luY2Ug
c29tZSBlZXByb20gZGV2aWNlcyBpcyBjb25uZWN0ZWQgdG8gUENBOTU3NCBJMkMgYnVzDQo+ID4g
PiBtdWx0aXBsZXhlciwgc28gdGhlc2UgZGV2aWNlcyBzaG91bGQgYmUgY29ubmVjdGVkIHRvIHBj
YTk1NDcgbm9kZS4NCj4gPiA+IEp1c3QgbGlrZSB0aGUgZm9sbG93aW5nLCB3aGF0IGRvIHlvdSB0
aGluayBvZiBpdD8NCj4gPiA+DQo+ID4gPiArICAgICAgICAgICAgICAgICAgICAgICBwY2E5NTQ3
QDc3IHsNCj4gPiA+ICsgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgY29tcGF0aWJsZSA9
ICJwaGlsaXBzLHBjYTk1NDciOw0KPiA+ID4gKyAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICByZWcgPSA8MHg3Nz47DQo+ID4gPiArICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICNh
ZGRyZXNzLWNlbGxzID0gPDE+Ow0KPiA+ID4gKyAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAjc2l6ZS1jZWxscyA9IDwwPjsNCj4gPiA+ICsgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgY2hhbm5lbEAwIHsNCj4gPiA+ICsgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAjYWRkcmVzcy1jZWxscyA9IDwxPjsNCj4gPiA+ICsgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAjc2l6ZS1jZWxscyA9IDwwPjsNCj4gPiA+ICsgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICByZWcgPSA8MD47DQo+ID4gPiArICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBlZXByb21ANTEgew0KPiA+ID4gKyAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBjb21w
YXRpYmxlID0NCj4gPiA+ICJhdDI0LDI0YzI1NiI7DQo+ID4gPiArICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHJlZyA9IDwweDUxPjsNCj4gPiA+
ICsgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIH07DQo+ID4g
PiArICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBlZXByb21A
NTIgew0KPiA+ID4gKyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICBjb21wYXRpYmxlID0NCj4gPiA+ICJhdDI0LDI0YzI1NiI7DQo+ID4gPiArICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHJlZyA9
IDwweDUyPjsNCj4gPiA+ICsgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgIH07DQo+ID4gPiArICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICBlZXByb21ANTMgew0KPiA+ID4gKyAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICBjb21wYXRpYmxlID0NCj4gPiA+ICJhdDI0LDI0YzI1
NiI7DQo+ID4gPiArICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgIHJlZyA9IDwweDUzPjsNCj4gPiA+ICsgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgIH07DQo+ID4gPiArICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICBlZXByb21ANTQgew0KPiA+ID4gKyAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBjb21wYXRpYmxlID0NCj4g
PiA+ICJhdDI0LDI0YzI1NiI7DQo+ID4gPiArICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgIHJlZyA9IDwweDU0PjsNCj4gPiA+ICsgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIH07DQo+ID4gPiArICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBlZXByb21ANTUgew0KPiA+ID4g
KyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBj
b21wYXRpYmxlID0NCj4gPiA+ICJhdDI0LDI0YzI1NiI7DQo+ID4gPiArICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHJlZyA9IDwweDU1PjsNCj4g
PiA+ICsgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIH07DQo+
ID4gPiArICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBlZXBy
b21ANTYgew0KPiA+ID4gKyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICBjb21wYXRpYmxlID0NCj4gPiA+ICJhdDI0LDI0YzI1NiI7DQo+ID4gPiAr
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHJl
ZyA9IDwweDU2PjsNCj4gPiA+ICsgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgIH07DQo+ID4gPiArICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICBydGNANjggew0KPiA+ID4gKyAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICBjb21wYXRpYmxlID0NCj4gPiA+ICJkYWxsYXMsZHMz
MjMyIjsNCj4gPiA+ICsgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgcmVnID0gPDB4Njg+Ow0KPiA+ID4gKyAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBpbnRlcnJ1cHRzID0NCj4gPiA+IDwweDEg
MHgxIDAgMD47DQo+ID4gPiArICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICB9Ow0KPiA+ID4gKyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
IH07DQo+ID4gPg0KPiA+ID4gV2VpDQo+ID4gPiA+DQo+ID4gPiA+IFNpZ25lZC1vZmYtYnk6IEpp
YSBIb25ndGFvIDxob25ndGFvLmppYUBmcmVlc2NhbGUuY29tPg0KPiA+ID4gPiAtLS0NCj4gPiA+
ID4gICBhcmNoL3Bvd2VycGMvYm9vdC9kdHMvYjRxZHMuZHRzaSAgIHwgNCArKysrDQo+ID4gPiA+
ICAgYXJjaC9wb3dlcnBjL2Jvb3QvZHRzL3Q0MjQwcWRzLmR0cyB8IDQgKysrKw0KPiA+ID4gPiAg
IDIgZmlsZXMgY2hhbmdlZCwgOCBpbnNlcnRpb25zKCspDQo+ID4gPiA+DQo+ID4gPiA+IGRpZmYg
LS1naXQgYS9hcmNoL3Bvd2VycGMvYm9vdC9kdHMvYjRxZHMuZHRzaQ0KPiA+ID4gPiBiL2FyY2gv
cG93ZXJwYy9ib290L2R0cy9iNHFkcy5kdHNpDQo+ID4gPiA+IGluZGV4IGU2ZDJmOGYuLjJhYTMz
OTkgMTAwNjQ0DQo+ID4gPiA+IC0tLSBhL2FyY2gvcG93ZXJwYy9ib290L2R0cy9iNHFkcy5kdHNp
DQo+ID4gPiA+ICsrKyBiL2FyY2gvcG93ZXJwYy9ib290L2R0cy9iNHFkcy5kdHNpDQo+ID4gPiA+
IEBAIC0xMjAsNiArMTIwLDEwIEBADQo+ID4gPiA+ICAgCQl9Ow0KPiA+ID4gPg0KPiA+ID4gPiAg
IAkJaTJjQDExODAwMCB7DQo+ID4gPiA+ICsJCQlwY2E5NTQ3QDc3IHsNCj4gPiA+ID4gKwkJCQlj
b21wYXRpYmxlID0gInBoaWxpcHMscGNhOTU0NyI7DQo+ID4gPiA+ICsJCQkJcmVnID0gPDB4Nzc+
Ow0KPiA+ID4gPiArCQkJfTsNCj4gPiA+ID4gICAJCQllZXByb21ANTAgew0KPiA+ID4gPiAgIAkJ
CQljb21wYXRpYmxlID0gImF0MjQsMjRjNjQiOw0KPiA+ID4gPiAgIAkJCQlyZWcgPSA8MHg1MD47
DQo+ID4gPiA+IGRpZmYgLS1naXQgYS9hcmNoL3Bvd2VycGMvYm9vdC9kdHMvdDQyNDBxZHMuZHRz
DQo+ID4gPiA+IGIvYXJjaC9wb3dlcnBjL2Jvb3QvZHRzL3Q0MjQwcWRzLmR0cw0KPiA+ID4gPiBp
bmRleCAwNTU1OTc2Li4wODRkYjU3IDEwMDY0NA0KPiA+ID4gPiAtLS0gYS9hcmNoL3Bvd2VycGMv
Ym9vdC9kdHMvdDQyNDBxZHMuZHRzDQo+ID4gPiA+ICsrKyBiL2FyY2gvcG93ZXJwYy9ib290L2R0
cy90NDI0MHFkcy5kdHMNCj4gPiA+ID4gQEAgLTExOCw2ICsxMTgsMTAgQEANCj4gPiA+ID4gICAJ
CX07DQo+ID4gPiA+DQo+ID4gPiA+ICAgCQlpMmNAMTE4MDAwIHsNCj4gPiA+ID4gKwkJCXBjYTk1
NDdANzcgew0KPiA+ID4gPiArCQkJCWNvbXBhdGlibGUgPSAicGhpbGlwcyxwY2E5NTQ3IjsNCj4g
PiA+ID4gKwkJCQlyZWcgPSA8MHg3Nz47DQo+ID4gPiA+ICsJCQl9Ow0KPiA+ID4gPiAgIAkJCWVl
cHJvbUA1MSB7DQo+ID4gPiA+ICAgCQkJCWNvbXBhdGlibGUgPSAiYXQyNCwyNGMyNTYiOw0KPiA+
ID4gPiAgIAkJCQlyZWcgPSA8MHg1MT47DQo+ID4gPg0KPiA+DQo+ID4NCj4gPiBfX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiA+IExpbnV4cHBjLWRldiBt
YWlsaW5nIGxpc3QNCj4gPiBMaW51eHBwYy1kZXZAbGlzdHMub3psYWJzLm9yZw0KPiA+IGh0dHBz
Oi8vbGlzdHMub3psYWJzLm9yZy9saXN0aW5mby9saW51eHBwYy1kZXYNCg0K
^ permalink raw reply
* RE: [PATCH] powerpc: Add I2C bus multiplexer node for B4 and T4240QDS
From: Tang Yuantian-B29983 @ 2013-09-04 4:03 UTC (permalink / raw)
To: Jia Hongtao-B38951, Yang,Wei
Cc: Wood Scott-B07421, linuxppc-dev@lists.ozlabs.org
In-Reply-To: <412C8208B4A0464FA894C5F0C278CD5D01D32795@039-SN1MPN1-002.039d.mgd.msft.net>
SGksDQpJIG5vdGljZWQgdGhhdCB0aGVyZSBhcmUgYWxyZWFkeSBzb21lIG5vZGVzIGluIGkyYyBi
dXMuDQpZb3Ugc2hvdWxkIGF0IGxlYXN0IG1vdmUgdGhlIGV4aXN0aW5nIG5vZGUgaW50byBQQ0E5
NTQ3Lg0KDQpUaGFua3MsDQpZdWFudGlhbg0KDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0t
LS0NCj4gRnJvbTogTGludXhwcGMtZGV2IFttYWlsdG86bGludXhwcGMtZGV2LQ0KPiBib3VuY2Vz
K2IyOTk4Mz1mcmVlc2NhbGUuY29tQGxpc3RzLm96bGFicy5vcmddIE9uIEJlaGFsZiBPZiBKaWEg
SG9uZ3Rhby0NCj4gQjM4OTUxDQo+IFNlbnQ6IDIwMTPE6jnUwjTI1SDQx8bayP0gMTE6MzgNCj4g
VG86IFlhbmcsV2VpDQo+IENjOiBXb29kIFNjb3R0LUIwNzQyMTsgbGludXhwcGMtZGV2QGxpc3Rz
Lm96bGFicy5vcmcNCj4gU3ViamVjdDogUkU6IFtQQVRDSF0gcG93ZXJwYzogQWRkIEkyQyBidXMg
bXVsdGlwbGV4ZXIgbm9kZSBmb3IgQjQgYW5kDQo+IFQ0MjQwUURTDQo+IA0KPiBIaSBXZWksDQo+
IA0KPiBJIHRvdGFsbHkgYWdyZWUgdGhhdCB0aGUgaTJjIG5vZGVzIHRvcG9sb2d5IHNob3VsZCBl
bmQgdXAgbGlrZSB5b3Ugc2FpZC4NCj4gDQo+IEJ1dCBJIHRoaW5rIGFkZGluZyBzdWItbm9kZXMg
c2hvdWxkIHN0ZXAgYnkgc3RlcC4NCj4gQWN0dWFsbHkgdGhlIGhhcmR3YXJlIGkyYyB0b3BvbG9n
eSBhcmUgaHVnZSBsaWtlIG9uIFQ0Lg0KPiBTbyBJJ2QgbGlrZSB0byBhZGRpbmcgbm9kZXMgd2hl
biB3ZSBuZWVkZWQuDQo+IElmIHlvdSB0aGluayB0aGUgc3ViLW5vZGVzIGFyZSBuZWVkZWQgcGxl
YXNlIHNlbmQgYW5vdGhlciBwYXRjaCBiYXNlZCBvbg0KPiBtaW5lLg0KPiBJIHRoaW5rIHRoaXMg
aXMgdGhlIG1vcmUgcmVhc29uYWJsZSB3YXkuDQo+IA0KPiBUaGFua3MuDQo+IA0KPiAtSG9uZ3Rh
bw0KPiANCj4gDQo+ID4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gPiBGcm9tOiBZYW5n
LFdlaSBbbWFpbHRvOldlaS5ZYW5nQHdpbmRyaXZlci5jb21dDQo+ID4gU2VudDogV2VkbmVzZGF5
LCBTZXB0ZW1iZXIgMDQsIDIwMTMgOToyNyBBTQ0KPiA+IFRvOiBKaWEgSG9uZ3Rhby1CMzg5NTEN
Cj4gPiBDYzogbGludXhwcGMtZGV2QGxpc3RzLm96bGFicy5vcmc7IFdvb2QgU2NvdHQtQjA3NDIx
OyBKaWENCj4gPiBIb25ndGFvLUIzODk1MQ0KPiA+IFN1YmplY3Q6IFJlOiBbUEFUQ0hdIHBvd2Vy
cGM6IEFkZCBJMkMgYnVzIG11bHRpcGxleGVyIG5vZGUgZm9yIEI0IGFuZA0KPiA+IFQ0MjQwUURT
DQo+ID4NCj4gPiBPbiAwOS8wMy8yMDEzIDAzOjUxIFBNLCBKaWEgSG9uZ3RhbyB3cm90ZToNCj4g
PiA+IEluIGJvdGggQjQgYW5kIFQ0MjQwUURTIHBsYXRmb3JtIFBDQTk1NDcgSTJDIGJ1cyBtdWx0
aXBsZXhlciBpcyB1c2VkLg0KPiA+DQo+ID4gSGkgSG9uZ3RhbywNCj4gPg0KPiA+IElmIHlvdSB3
YW50IHRvIHN1cHBvcnQgSTJDIGJ1cyBtdWx0aXBsZXhlciwgZm9yIFQ0IGFuZCBCNFFEUyBwbGF0
Zm9ybSwNCj4gPiBzaW5jZSBzb21lIGVlcHJvbSBkZXZpY2VzIGlzIGNvbm5lY3RlZCB0byBQQ0E5
NTc0IEkyQyBidXMgbXVsdGlwbGV4ZXIsDQo+ID4gc28gdGhlc2UgZGV2aWNlcyBzaG91bGQgYmUg
Y29ubmVjdGVkIHRvIHBjYTk1NDcgbm9kZS4gSnVzdCBsaWtlIHRoZQ0KPiA+IGZvbGxvd2luZywg
d2hhdCBkbyB5b3UgdGhpbmsgb2YgaXQ/DQo+ID4NCj4gPiArICAgICAgICAgICAgICAgICAgICAg
ICBwY2E5NTQ3QDc3IHsNCj4gPiArICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGNvbXBh
dGlibGUgPSAicGhpbGlwcyxwY2E5NTQ3IjsNCj4gPiArICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgIHJlZyA9IDwweDc3PjsNCj4gPiArICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICNhZGRyZXNzLWNlbGxzID0gPDE+Ow0KPiA+ICsgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgI3NpemUtY2VsbHMgPSA8MD47DQo+ID4gKyAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICBjaGFubmVsQDAgew0KPiA+ICsgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAjYWRkcmVzcy1jZWxscyA9IDwxPjsNCj4gPiArICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgI3NpemUtY2VsbHMgPSA8MD47DQo+ID4gKyAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgIHJlZyA9IDwwPjsNCj4gPiArICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICBlZXByb21ANTEgew0KPiA+ICsgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgY29tcGF0aWJsZSA9DQo+
ID4gImF0MjQsMjRjMjU2IjsNCj4gPiArICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgIHJlZyA9IDwweDUxPjsNCj4gPiArICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB9Ow0KPiA+ICsgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGVlcHJvbUA1MiB7DQo+ID4gKyAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBjb21wYXRpYmxl
ID0NCj4gPiAiYXQyNCwyNGMyNTYiOw0KPiA+ICsgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgcmVnID0gPDB4NTI+Ow0KPiA+ICsgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIH07DQo+ID4gKyAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgZWVwcm9tQDUzIHsNCj4gPiArICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGNvbXBh
dGlibGUgPQ0KPiA+ICJhdDI0LDI0YzI1NiI7DQo+ID4gKyAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICByZWcgPSA8MHg1Mz47DQo+ID4gKyAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfTsNCj4gPiArICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBlZXByb21ANTQgew0KPiA+
ICsgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
Y29tcGF0aWJsZSA9DQo+ID4gImF0MjQsMjRjMjU2IjsNCj4gPiArICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHJlZyA9IDwweDU0PjsNCj4gPiAr
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB9Ow0KPiA+ICsg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGVlcHJvbUA1NSB7
DQo+ID4gKyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICBjb21wYXRpYmxlID0NCj4gPiAiYXQyNCwyNGMyNTYiOw0KPiA+ICsgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgcmVnID0gPDB4NTU+Ow0K
PiA+ICsgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIH07DQo+
ID4gKyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgZWVwcm9t
QDU2IHsNCj4gPiArICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgIGNvbXBhdGlibGUgPQ0KPiA+ICJhdDI0LDI0YzI1NiI7DQo+ID4gKyAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICByZWcgPSA8MHg1
Nj47DQo+ID4gKyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
fTsNCj4gPiArICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBy
dGNANjggew0KPiA+ICsgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgY29tcGF0aWJsZSA9DQo+ID4gImRhbGxhcyxkczMyMzIiOw0KPiA+ICsgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgcmVnID0g
PDB4Njg+Ow0KPiA+ICsgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgaW50ZXJydXB0cyA9DQo+ID4gPDB4MSAweDEgMCAwPjsNCj4gPiArICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB9Ow0KPiA+ICsgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB9Ow0KPiA+DQo+ID4gV2VpDQo+ID4gPg0K
PiA+ID4gU2lnbmVkLW9mZi1ieTogSmlhIEhvbmd0YW8gPGhvbmd0YW8uamlhQGZyZWVzY2FsZS5j
b20+DQo+ID4gPiAtLS0NCj4gPiA+ICAgYXJjaC9wb3dlcnBjL2Jvb3QvZHRzL2I0cWRzLmR0c2kg
ICB8IDQgKysrKw0KPiA+ID4gICBhcmNoL3Bvd2VycGMvYm9vdC9kdHMvdDQyNDBxZHMuZHRzIHwg
NCArKysrDQo+ID4gPiAgIDIgZmlsZXMgY2hhbmdlZCwgOCBpbnNlcnRpb25zKCspDQo+ID4gPg0K
PiA+ID4gZGlmZiAtLWdpdCBhL2FyY2gvcG93ZXJwYy9ib290L2R0cy9iNHFkcy5kdHNpDQo+ID4g
PiBiL2FyY2gvcG93ZXJwYy9ib290L2R0cy9iNHFkcy5kdHNpDQo+ID4gPiBpbmRleCBlNmQyZjhm
Li4yYWEzMzk5IDEwMDY0NA0KPiA+ID4gLS0tIGEvYXJjaC9wb3dlcnBjL2Jvb3QvZHRzL2I0cWRz
LmR0c2kNCj4gPiA+ICsrKyBiL2FyY2gvcG93ZXJwYy9ib290L2R0cy9iNHFkcy5kdHNpDQo+ID4g
PiBAQCAtMTIwLDYgKzEyMCwxMCBAQA0KPiA+ID4gICAJCX07DQo+ID4gPg0KPiA+ID4gICAJCWky
Y0AxMTgwMDAgew0KPiA+ID4gKwkJCXBjYTk1NDdANzcgew0KPiA+ID4gKwkJCQljb21wYXRpYmxl
ID0gInBoaWxpcHMscGNhOTU0NyI7DQo+ID4gPiArCQkJCXJlZyA9IDwweDc3PjsNCj4gPiA+ICsJ
CQl9Ow0KPiA+ID4gICAJCQllZXByb21ANTAgew0KPiA+ID4gICAJCQkJY29tcGF0aWJsZSA9ICJh
dDI0LDI0YzY0IjsNCj4gPiA+ICAgCQkJCXJlZyA9IDwweDUwPjsNCj4gPiA+IGRpZmYgLS1naXQg
YS9hcmNoL3Bvd2VycGMvYm9vdC9kdHMvdDQyNDBxZHMuZHRzDQo+ID4gPiBiL2FyY2gvcG93ZXJw
Yy9ib290L2R0cy90NDI0MHFkcy5kdHMNCj4gPiA+IGluZGV4IDA1NTU5NzYuLjA4NGRiNTcgMTAw
NjQ0DQo+ID4gPiAtLS0gYS9hcmNoL3Bvd2VycGMvYm9vdC9kdHMvdDQyNDBxZHMuZHRzDQo+ID4g
PiArKysgYi9hcmNoL3Bvd2VycGMvYm9vdC9kdHMvdDQyNDBxZHMuZHRzDQo+ID4gPiBAQCAtMTE4
LDYgKzExOCwxMCBAQA0KPiA+ID4gICAJCX07DQo+ID4gPg0KPiA+ID4gICAJCWkyY0AxMTgwMDAg
ew0KPiA+ID4gKwkJCXBjYTk1NDdANzcgew0KPiA+ID4gKwkJCQljb21wYXRpYmxlID0gInBoaWxp
cHMscGNhOTU0NyI7DQo+ID4gPiArCQkJCXJlZyA9IDwweDc3PjsNCj4gPiA+ICsJCQl9Ow0KPiA+
ID4gICAJCQllZXByb21ANTEgew0KPiA+ID4gICAJCQkJY29tcGF0aWJsZSA9ICJhdDI0LDI0YzI1
NiI7DQo+ID4gPiAgIAkJCQlyZWcgPSA8MHg1MT47DQo+ID4NCj4gDQo+IA0KPiBfX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBMaW51eHBwYy1kZXYgbWFp
bGluZyBsaXN0DQo+IExpbnV4cHBjLWRldkBsaXN0cy5vemxhYnMub3JnDQo+IGh0dHBzOi8vbGlz
dHMub3psYWJzLm9yZy9saXN0aW5mby9saW51eHBwYy1kZXYNCg0K
^ permalink raw reply
* RE: [PATCH] powerpc: Add I2C bus multiplexer node for B4 and T4240QDS
From: Jia Hongtao-B38951 @ 2013-09-04 3:37 UTC (permalink / raw)
To: Yang,Wei; +Cc: Wood Scott-B07421, linuxppc-dev@lists.ozlabs.org
In-Reply-To: <52268C7E.4040209@windriver.com>
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 mi=
ne.
I think this is the more reasonable way.
Thanks.
-Hongtao
> -----Original Message-----
> From: Yang,Wei [mailto:Wei.Yang@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
>=20
> On 09/03/2013 03:51 PM, Jia Hongtao wrote:
> > In both B4 and T4240QDS platform PCA9547 I2C bus multiplexer is used.
>=20
> Hi Hongtao,
>=20
> 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?
>=20
> + pca9547@77 {
> + compatible =3D "philips,pca9547";
> + reg =3D <0x77>;
> + #address-cells =3D <1>;
> + #size-cells =3D <0>;
> + channel@0 {
> + #address-cells =3D <1>;
> + #size-cells =3D <0>;
> + reg =3D <0>;
> + eeprom@51 {
> + compatible =3D
> "at24,24c256";
> + reg =3D <0x51>;
> + };
> + eeprom@52 {
> + compatible =3D
> "at24,24c256";
> + reg =3D <0x52>;
> + };
> + eeprom@53 {
> + compatible =3D
> "at24,24c256";
> + reg =3D <0x53>;
> + };
> + eeprom@54 {
> + compatible =3D
> "at24,24c256";
> + reg =3D <0x54>;
> + };
> + eeprom@55 {
> + compatible =3D
> "at24,24c256";
> + reg =3D <0x55>;
> + };
> + eeprom@56 {
> + compatible =3D
> "at24,24c256";
> + reg =3D <0x56>;
> + };
> + rtc@68 {
> + compatible =3D
> "dallas,ds3232";
> + reg =3D <0x68>;
> + interrupts =3D
> <0x1 0x1 0 0>;
> + };
> + };
>=20
> Wei
> >
> > Signed-off-by: Jia Hongtao <hongtao.jia@freescale.com>
> > ---
> > 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 =3D "philips,pca9547";
> > + reg =3D <0x77>;
> > + };
> > eeprom@50 {
> > compatible =3D "at24,24c64";
> > reg =3D <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 =3D "philips,pca9547";
> > + reg =3D <0x77>;
> > + };
> > eeprom@51 {
> > compatible =3D "at24,24c256";
> > reg =3D <0x51>;
>=20
^ permalink raw reply
* RE: [PATCH] powerpc: Add I2C bus multiplexer node for B4 and T4240QDS
From: Tang Yuantian-B29983 @ 2013-09-04 3:30 UTC (permalink / raw)
To: Yang,Wei, Jia Hongtao-B38951
Cc: Wood Scott-B07421, linuxppc-dev@lists.ozlabs.org,
Jia Hongtao-B38951
In-Reply-To: <52268C7E.4040209@windriver.com>
SGksDQoNClRoZXNlIGVlcHJvbXMgYXJlIG5ldmVyIHVzZWQgYnkga2VybmVsLiBTbyBubyBuZWVk
IHRvIGFkZCB0aGVtLg0KDQpUaGFua3MsDQpZdWFudGlhbg0KDQoNCj4gLS0tLS1PcmlnaW5hbCBN
ZXNzYWdlLS0tLS0NCj4gRnJvbTogTGludXhwcGMtZGV2IFttYWlsdG86bGludXhwcGMtZGV2LQ0K
PiBib3VuY2VzK2IyOTk4Mz1mcmVlc2NhbGUuY29tQGxpc3RzLm96bGFicy5vcmddIE9uIEJlaGFs
ZiBPZiBZYW5nLFdlaQ0KPiBTZW50OiAyMDEzxOo51MI0yNUg0MfG2sj9IDk6MjcNCj4gVG86IEpp
YSBIb25ndGFvLUIzODk1MQ0KPiBDYzogV29vZCBTY290dC1CMDc0MjE7IGxpbnV4cHBjLWRldkBs
aXN0cy5vemxhYnMub3JnOyBKaWEgSG9uZ3Rhby1CMzg5NTENCj4gU3ViamVjdDogUmU6IFtQQVRD
SF0gcG93ZXJwYzogQWRkIEkyQyBidXMgbXVsdGlwbGV4ZXIgbm9kZSBmb3IgQjQgYW5kDQo+IFQ0
MjQwUURTDQo+IA0KPiBPbiAwOS8wMy8yMDEzIDAzOjUxIFBNLCBKaWEgSG9uZ3RhbyB3cm90ZToN
Cj4gPiBJbiBib3RoIEI0IGFuZCBUNDI0MFFEUyBwbGF0Zm9ybSBQQ0E5NTQ3IEkyQyBidXMgbXVs
dGlwbGV4ZXIgaXMgdXNlZC4NCj4gDQo+IEhpIEhvbmd0YW8sDQo+IA0KPiBJZiB5b3Ugd2FudCB0
byBzdXBwb3J0IEkyQyBidXMgbXVsdGlwbGV4ZXIsIGZvciBUNCBhbmQgQjRRRFMgcGxhdGZvcm0s
DQo+IHNpbmNlIHNvbWUgZWVwcm9tIGRldmljZXMgaXMgY29ubmVjdGVkIHRvIFBDQTk1NzQgSTJD
IGJ1cyBtdWx0aXBsZXhlciwgc28NCj4gdGhlc2UgZGV2aWNlcyBzaG91bGQgYmUgY29ubmVjdGVk
IHRvIHBjYTk1NDcgbm9kZS4gSnVzdCBsaWtlIHRoZQ0KPiBmb2xsb3dpbmcsIHdoYXQgZG8geW91
IHRoaW5rIG9mIGl0Pw0KPiANCj4gKyAgICAgICAgICAgICAgICAgICAgICAgcGNhOTU0N0A3NyB7
DQo+ICsgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgY29tcGF0aWJsZSA9ICJwaGlsaXBz
LHBjYTk1NDciOw0KPiArICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHJlZyA9IDwweDc3
PjsNCj4gKyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAjYWRkcmVzcy1jZWxscyA9IDwx
PjsNCj4gKyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAjc2l6ZS1jZWxscyA9IDwwPjsN
Cj4gKyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBjaGFubmVsQDAgew0KPiArICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgI2FkZHJlc3MtY2VsbHMgPSA8MT47DQo+
ICsgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAjc2l6ZS1jZWxscyA9IDww
PjsNCj4gKyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHJlZyA9IDwwPjsN
Cj4gKyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgZWVwcm9t
QDUxIHsNCj4gKyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICBjb21wYXRpYmxlID0NCj4gImF0MjQsMjRjMjU2IjsNCj4gKyAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICByZWcgPSA8MHg1MT47DQo+
ICsgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIH07DQo+ICsg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGVlcHJvbUA1MiB7
DQo+ICsgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgY29tcGF0aWJsZSA9DQo+ICJhdDI0LDI0YzI1NiI7DQo+ICsgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgcmVnID0gPDB4NTI+Ow0KPiArICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB9Ow0KPiArICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBlZXByb21ANTMgew0KPiAr
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGNv
bXBhdGlibGUgPQ0KPiAiYXQyNCwyNGMyNTYiOw0KPiArICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHJlZyA9IDwweDUzPjsNCj4gKyAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfTsNCj4gKyAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgZWVwcm9tQDU0IHsNCj4gKyAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBjb21wYXRp
YmxlID0NCj4gImF0MjQsMjRjMjU2IjsNCj4gKyAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICByZWcgPSA8MHg1ND47DQo+ICsgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIH07DQo+ICsgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGVlcHJvbUA1NSB7DQo+ICsgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgY29tcGF0aWJsZSA9
DQo+ICJhdDI0LDI0YzI1NiI7DQo+ICsgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgcmVnID0gPDB4NTU+Ow0KPiArICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICB9Ow0KPiArICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICBlZXByb21ANTYgew0KPiArICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGNvbXBhdGlibGUgPQ0KPiAi
YXQyNCwyNGMyNTYiOw0KPiArICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgIHJlZyA9IDwweDU2PjsNCj4gKyAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgfTsNCj4gKyAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgcnRjQDY4IHsNCj4gKyAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBjb21wYXRpYmxlID0NCj4gImRhbGxhcyxk
czMyMzIiOw0KPiArICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgIHJlZyA9IDwweDY4PjsNCj4gKyAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICBpbnRlcnJ1cHRzID0NCj4gPDB4MSAweDEgMCAwPjsN
Cj4gKyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfTsNCj4g
KyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIH07DQo+IA0KPiBXZWkNCj4g
Pg0KPiA+IFNpZ25lZC1vZmYtYnk6IEppYSBIb25ndGFvIDxob25ndGFvLmppYUBmcmVlc2NhbGUu
Y29tPg0KPiA+IC0tLQ0KPiA+ICAgYXJjaC9wb3dlcnBjL2Jvb3QvZHRzL2I0cWRzLmR0c2kgICB8
IDQgKysrKw0KPiA+ICAgYXJjaC9wb3dlcnBjL2Jvb3QvZHRzL3Q0MjQwcWRzLmR0cyB8IDQgKysr
Kw0KPiA+ICAgMiBmaWxlcyBjaGFuZ2VkLCA4IGluc2VydGlvbnMoKykNCj4gPg0KPiA+IGRpZmYg
LS1naXQgYS9hcmNoL3Bvd2VycGMvYm9vdC9kdHMvYjRxZHMuZHRzaQ0KPiA+IGIvYXJjaC9wb3dl
cnBjL2Jvb3QvZHRzL2I0cWRzLmR0c2kNCj4gPiBpbmRleCBlNmQyZjhmLi4yYWEzMzk5IDEwMDY0
NA0KPiA+IC0tLSBhL2FyY2gvcG93ZXJwYy9ib290L2R0cy9iNHFkcy5kdHNpDQo+ID4gKysrIGIv
YXJjaC9wb3dlcnBjL2Jvb3QvZHRzL2I0cWRzLmR0c2kNCj4gPiBAQCAtMTIwLDYgKzEyMCwxMCBA
QA0KPiA+ICAgCQl9Ow0KPiA+DQo+ID4gICAJCWkyY0AxMTgwMDAgew0KPiA+ICsJCQlwY2E5NTQ3
QDc3IHsNCj4gPiArCQkJCWNvbXBhdGlibGUgPSAicGhpbGlwcyxwY2E5NTQ3IjsNCj4gPiArCQkJ
CXJlZyA9IDwweDc3PjsNCj4gPiArCQkJfTsNCj4gPiAgIAkJCWVlcHJvbUA1MCB7DQo+ID4gICAJ
CQkJY29tcGF0aWJsZSA9ICJhdDI0LDI0YzY0IjsNCj4gPiAgIAkJCQlyZWcgPSA8MHg1MD47DQo+
ID4gZGlmZiAtLWdpdCBhL2FyY2gvcG93ZXJwYy9ib290L2R0cy90NDI0MHFkcy5kdHMNCj4gPiBi
L2FyY2gvcG93ZXJwYy9ib290L2R0cy90NDI0MHFkcy5kdHMNCj4gPiBpbmRleCAwNTU1OTc2Li4w
ODRkYjU3IDEwMDY0NA0KPiA+IC0tLSBhL2FyY2gvcG93ZXJwYy9ib290L2R0cy90NDI0MHFkcy5k
dHMNCj4gPiArKysgYi9hcmNoL3Bvd2VycGMvYm9vdC9kdHMvdDQyNDBxZHMuZHRzDQo+ID4gQEAg
LTExOCw2ICsxMTgsMTAgQEANCj4gPiAgIAkJfTsNCj4gPg0KPiA+ICAgCQlpMmNAMTE4MDAwIHsN
Cj4gPiArCQkJcGNhOTU0N0A3NyB7DQo+ID4gKwkJCQljb21wYXRpYmxlID0gInBoaWxpcHMscGNh
OTU0NyI7DQo+ID4gKwkJCQlyZWcgPSA8MHg3Nz47DQo+ID4gKwkJCX07DQo+ID4gICAJCQllZXBy
b21ANTEgew0KPiA+ICAgCQkJCWNvbXBhdGlibGUgPSAiYXQyNCwyNGMyNTYiOw0KPiA+ICAgCQkJ
CXJlZyA9IDwweDUxPjsNCj4gDQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fDQo+IExpbnV4cHBjLWRldiBtYWlsaW5nIGxpc3QNCj4gTGludXhwcGMtZGV2
QGxpc3RzLm96bGFicy5vcmcNCj4gaHR0cHM6Ly9saXN0cy5vemxhYnMub3JnL2xpc3RpbmZvL2xp
bnV4cHBjLWRldg0KDQo=
^ permalink raw reply
* Re: [PATCH 3/7] powerpc/pci: use pci_is_pcie() to simplify code
From: Gavin Shan @ 2013-09-04 3:16 UTC (permalink / raw)
To: Yijing Wang
Cc: Gavin Shan, Hanjun Guo, linux-kernel, James E.J. Bottomley,
Paul Mackerras, linux-pci, Bjorn Helgaas, linuxppc-dev,
David S. Miller
In-Reply-To: <1378193715-25328-3-git-send-email-wangyijing@huawei.com>
>Use pci_is_pcie() to simplify code.
>
>Signed-off-by: Yijing Wang <wangyijing@huawei.com>
>Cc: Gavin Shan <shangw@linux.vnet.ibm.com>
>Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
>Cc: Paul Mackerras <paulus@samba.org>
>Cc: linuxppc-dev@lists.ozlabs.org
>Cc: linux-kernel@vger.kernel.org
It looks good to me:
Reviewed-by: Gavin Shan <shangw@linux.vnet.ibm.com>
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
>
>
^ permalink raw reply
* Power PC Build problem
From: Jason Rennie @ 2013-09-04 3:07 UTC (permalink / raw)
To: linuxppc-dev@ozlabs.org
[-- Attachment #1: Type: text/plain, Size: 8688 bytes --]
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: 01000000 at ff000000
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=0x20000,size=0x20000,blocks=127
3 cmdlinepart partitions found on MTD device physmap-flash.0
Creating 3 MTD partitions on "physmap-flash.0":
0x00000000-0x00080000 : "U-Boot"
0x00080000-0x00180000 : "Linux"
0x00180000-0x01000000 : "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 0x0000000080000000..0x000000009fffffff -> 0x0000000080000000 Prefetch
MEM 0x00000000a0000000..0x00000000bfffffff -> 0x00000000a0000000
IO 0x00000000f6000000..0x00000000f7ffffff -> 0x0000000000000000
Zone ranges:
DMA [mem 0x00000000-0x03ffffff]
Normal empty
Movable zone start for each node
Early memory node ranges
node 0: [mem 0x00000000-0x03ffffff]
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..0xfffff000 : fixmap
* 0xfcfb4000..0xfe000000 : early ioremap
* 0xc5000000..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 0000:00
pci_bus 0000:00: root bus resource [io 0x0000-0xffffff]
pci_bus 0000:00: root bus resource [mem 0x80000000-0x9fffffff pref]
pci_bus 0000:00: root bus resource [mem 0xa0000000-0xbfffffff]
pci_bus 0000:00: root bus resource [bus 00-ff]
Can't get bus-range for /pci@f0010800, assuming it starts at 0
bio: create slab <bio-0> at 0
pps_core: LinuxPPS API ver. 1 registered
pps_core: Software ver. 5.3.6 - Copyright 2005-2007 Rodolfo Giometti
<giometti@linux.it>
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 (irq = 40) is a CPM UART
f0011a60.serial: ttyCPM1 at MMIO 0xc5060a60 (irq = 43) is a CPM UART
brd: module loaded
tun: Universal TUN/TAP device driver, 1.6
tun: (C) 1999-2004 Max Krasnyansky <maxk@qualcomm.com>
eth0: fs_enet: de:ad:be:ef:01:d7
eth1: fs_enet: 00:00:00:00:00:00
libphy: CPM2 Bitbanged MII: probed
TCP: cubic registered
NET: Registered protocol family 10
sit: IPv6 over IPv4 tunneling driver
NET: Registered protocol family 17
IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready
IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
IP-Config: Complete:
device=eth0, hwaddr=de:ad:be:ef:01:d7, ipaddr=192.168.1.231,
mask=255.255.255.0, gw=255.255.255.255
host=eclipse, domain=, nis-domain=(none)
bootserver=192.168.1.148, rootserver=192.168.1.148, rootpath=
VFS: Cannot open root device "31:02" or unknown-block(31,2): error -19
Please append a correct "root=" boot option; here are the available
partitions:
Kernel panic - not syncing: VFS: Unable to mount root fs on
unknown-block(31,2)
Rebooting in 1 seconds..
-----------
and when I do include the physmap settings
<*> Flash device in physical memory map
[*] Physmap compat support
(0xFF000000) Physical start address of flash mapping
(0x1000000) Physical length of flash mapping
(2) Bank width in octets
which I took from the earlier build and do seem to be right, it does the
following.
--------------------
f0011a00.serial: ttyCPM0 at MMIO 0xc505ea00 (irq = 40) is a CPM UART
f0011a60.serial: ttyCPM1 at MMIO 0xc5060a60 (irq = 43) is a CPM UART
brd: module loaded
physmap platform flash device: 01000000 at ff000000
Machine check in kernel mode.
Caused by (from SRR1=49030): Transfer error ack signal
Oops: Machine check, sig: 7 [#1]
PREEMPT Freescale MPC8272 ADS
Modules linked in:
CPU: 0 PID: 1 Comm: swapper Not tainted 3.10.10 #12
task: c3830000 ti: c3832000 task.ti: c3832000
NIP: c01a5da8 LR: c01a6200 CTR: c01a60cc
REGS: c3833c00 TRAP: 0200 Not tainted (3.10.10)
MSR: 00049030 <EE,ME,IR,DR> CR: 22000022 XER: 00000000
GPR00: c01a59a0 c3833cb0 c3830000 00000000 c39c0e24 c3833cf8 00000002
00000aaa
GPR08: c5080000 0000aaaa 00000002 00000002 42000024 00000000 c000406c
00000000
GPR16: 00000000 00000000 c39c0e24 c02c9ff4 00000001 c02c8d30 c02c9fe8
c0356e23
GPR24: c02c8d78 00000001 00000000 00000001 c03b89d8 00000000 c39c0e24
c3833cf8
NIP [c01a5da8] jedec_reset+0x124/0x448
LR [c01a6200] jedec_probe_chip+0x134/0x1050
Call Trace:
[c3833cb0] [c002d900] call_usermodehelper_exec+0x154/0x160 (unreliable)
[c3833cf0] [c01a59a0] mtd_do_chip_probe+0x78/0x34c
[c3833d70] [c01a73a8] physmap_flash_probe+0x1ec/0x30c
[c3833db0] [c01996c8] driver_probe_device+0xb8/0x1f4
[c3833dd0] [c0197a64] bus_for_each_drv+0x60/0xa8
[c3833e00] [c01995d8] device_attach+0x7c/0x94
[c3833e20] [c0198ac4] bus_probe_device+0x34/0xac
[c3833e40] [c0196f94] device_add+0x3d4/0x570
[c3833e80] [c019acd0] platform_device_add+0x164/0x1dc
[c3833ea0] [c039a438] physmap_init+0x34/0x50
[c3833ec0] [c0003acc] do_one_initcall+0xdc/0x180
[c3833ef0] [c0386bcc] kernel_init_freeable+0x11c/0x1c0
[c3833f30] [c0004088] kernel_init+0x1c/0xf4
[c3833f40] [c000d3a8] ret_from_kernel_thread+0x5c/0x64
Instruction dump:
5529063e 7d2839ae 48000024 2f8a0002 40be0010 5529043e 7d283b2e 48000010
2f8a0004 409e0324 7d28392e 7c0004ac <81250008> 8105000c 81440018 7d6849d6
---[ end trace 06e97f39189bf8ef ]---
Kernel panic - not syncing: Attempted to kill init! exitcode=0x00000007
Rebooting in 1 seconds..
--------------------
I assume it is crashing when it tries to probe the flash chips?
I'm at a loss to work out what I am doing wrong here. Can anybody offer
any pointers?
Jason
[-- Attachment #2: Type: text/html, Size: 12664 bytes --]
^ permalink raw reply
* Re: [RFC PATCH v1 1/1] powerpc/85xx: Wakeup kexec smp slave cpus in second kernel
From: Yang,Wei @ 2013-09-04 1:46 UTC (permalink / raw)
To: Yu Chen; +Cc: b24347, chenhui.zhao, linux-kernel, paulus, msm, linuxppc-dev
In-Reply-To: <CANHg-x7q4y6go_Bc8z5ZSYUJdQ72OQekg=SU+UVJopztknu6Ew@mail.gmail.com>
On 08/31/2013 05:12 PM, Yu Chen wrote:
> >From 1ccf579b871dfd5938ce958f729361a203485c74 Mon Sep 17 00:00:00 2001
> From: Yu Chen <chenyu105@gmail.com>
> 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 <chenyu105@gmail.com>
> ---
> 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*/
> + lis r1,kexec_poll_phy@h
> + ori r1,r1,kexec_poll_phy@l
> + stw r28,0(r1)
> +#endif
> +
> /* ptr to current */
> lis r2,init_task@h
> ori r2,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)
> addi r4,r4,1b@l
> subf r0,r4,r0
> add r7,r0,r7
> -2: lwz r0,0(r7)
> + 2: lwz r0,0(r7)
> add r0,r0,r3
> stw r0,0(r7)
> addi r7,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:
> mr r30, r4
> mr r31, r5
>
> +#ifdef CONFIG_SMP
> + bl 1f
> +1: mflr r8
> + addi r8,r8,kexec_flag-1b
> + lis r7,PAGE_OFFSET@h
> + ori r7,r7,PAGE_OFFSET@l
> + /*r28 contain slave cpu spin physical address */
> + subf r28, 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:
> +
> + bl 1f
> +1: mflr r5
> + addi r5,r5,kexec_flag-1b
> + /*see if anyone calls me?*/
> + mfspr r24,SPRN_PIR
> +99: lwz r4,4(r5)
> + cmpw r4,r24
> + msync
> + bne 99b
> +
> + msync
> + /*r4 contains jump address*/
> + lwz r4,8(r5)
> + msync
> + lis r5,MSR_KERNEL@h
> + ori r5,r5,MSR_KERNEL@l
> + msync
> + isync
> + mtspr SPRN_SRR1, r5
> + mtspr SPRN_SRR0, r4
> + msync
> + isync
> + rfi
> + isync
> +1: b 1b
> +
> + /**
> + * 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
> + .long 0
> + .long 0
> +relocate_smp_cpu_wait_end:
> + .globl relocate_smp_cpu_size
> +relocate_smp_cpu_size:
> + .long relocate_smp_cpu_wait_end-relocate_smp_cpu_wait
> +#endif
> +
> #endif
> diff --git a/arch/powerpc/platforms/85xx/smp.c
> b/arch/powerpc/platforms/85xx/smp.c
> old mode 100644
> new mode 100755
> index 5ced4f5..c4f5c4c
> --- a/arch/powerpc/platforms/85xx/smp.c
> +++ b/arch/powerpc/platforms/85xx/smp.c
> @@ -140,6 +140,70 @@ static inline u32 read_spin_table_addr_l(void *spin_table)
> (ulong)spin_table + sizeof(struct epapr_spin_table));
> return in_be32(&((struct epapr_spin_table *)spin_table)->addr_l);
> }
> +#ifdef CONFIG_KEXEC
> +
> +#define KEXEC_MAGIC 0xdeadbeef
> +#define KEXEC_RESERVE_LIMIT 0x10
> +unsigned long kexec_poll_phy;
> +extern void reserve_kexec_bootmem(unsigned long poll_phy, int size);
> +
> +/*
> + * Reserved bootmem for slave cpus kexec spin area.
> + */
> +void mpc85xx_smp_reserve_kexec(void)
> +{
> + unsigned long kexec_poll_virt;
> + unsigned long *kexec_magic_virt;
> +
> + if (!kexec_poll_phy ||
> + kexec_poll_phy >= __max_low_memory)
> + return;
> +
> + kexec_poll_virt = (unsigned long)phys_to_virt(kexec_poll_phy);
> + kexec_magic_virt = (unsigned long *)kexec_poll_virt;
> +
> + if (*kexec_magic_virt == KEXEC_MAGIC)
> + reserve_kexec_bootmem(kexec_poll_phy, KEXEC_RESERVE_LIMIT);
> +}
> +
> +/*
> + * Kick slave cpus from kexec spin area.
> + */
> +int mpc85xx_smp_kick_kexec_cpus(int nr)
> +{
> + unsigned long kexec_poll_virt;
> + unsigned long *kexec_flag_virt;
> + unsigned long *kexec_magic_virt;
> + unsigned long *kexec_jump_virt;
> +
> + /*verify accessible*/
> + if (!kexec_poll_phy ||
> + kexec_poll_phy >= __max_low_memory)
> + return -EBUSY;
> +
> + kexec_poll_virt = (unsigned long)phys_to_virt(kexec_poll_phy);
> +
> + kexec_magic_virt = (unsigned long *)kexec_poll_virt;
> + kexec_flag_virt = (unsigned long *)kexec_poll_virt + 1;
> + kexec_jump_virt = (unsigned long *)kexec_poll_virt + 2;
> +
> + /*verify a valid kexec kick*/
> + if (*kexec_magic_virt == KEXEC_MAGIC) {
> + flush_dcache_range((ulong)kexec_poll_virt,
> + (ulong)kexec_poll_virt + L1_CACHE_BYTES-1);
> + *kexec_jump_virt = (unsigned long)__early_start;
> + mb();
> + /*kick cpu[nr] up*/
> + *kexec_flag_virt = nr;
> + mb();
> + flush_dcache_range((ulong)kexec_poll_virt,
> + (ulong)kexec_poll_virt + L1_CACHE_BYTES-1);
> +
> + return 0;
> + }
> + return -EBUSY;
> +}
> +#endif
>
> static int smp_85xx_kick_cpu(int nr)
> {
> @@ -181,6 +245,10 @@ static int smp_85xx_kick_cpu(int nr)
>
> local_irq_save(flags);
> #ifdef CONFIG_PPC32
> +#ifdef CONFIG_KEXEC
> + if (!mpc85xx_smp_kick_kexec_cpus(nr))
> + goto kexec_kick_done;
> +#endif
> #ifdef CONFIG_HOTPLUG_CPU
> /* Corresponding to generic_set_cpu_dead() */
> generic_set_cpu_up(nr);
> @@ -225,7 +293,9 @@ static int smp_85xx_kick_cpu(int nr)
> out_be32(&spin_table->pir, hw_cpu);
> out_be32(&spin_table->addr_l, __pa(__early_start));
> flush_spin_table(spin_table);
> -
> +#ifdef CONFIG_KEXEC
> +kexec_kick_done:
> +#endif
> /* Wait a bit for the CPU to ack. */
> if (!spin_event_timeout(__secondary_hold_acknowledge == hw_cpu,
> 10000, 100)) {
> @@ -266,7 +336,13 @@ struct smp_ops_t smp_85xx_ops = {
> };
>
> #ifdef CONFIG_KEXEC
> +
> atomic_t kexec_down_cpus = ATOMIC_INIT(0);
> +atomic_t kexec_ready_to_reboot = ATOMIC_INIT(0);
> +atomic_t kexec_slave_finish = ATOMIC_INIT(0);
> +unsigned long wait_code_buffer;
> +static struct kimage *save_image;
> +extern const unsigned int relocate_smp_cpu_size;
>
> void mpc85xx_smp_kexec_cpu_down(int crash_shutdown, int secondary)
> {
> @@ -274,8 +350,29 @@ void mpc85xx_smp_kexec_cpu_down(int
> crash_shutdown, int secondary)
>
> if (secondary) {
> atomic_inc(&kexec_down_cpus);
> - /* loop forever */
> - while (1);
> + mb();
> +
> + if (crash_shutdown) {
> + /* loop forever */
> + while (1)
> + ;
> + } else {
> + while (!atomic_read(&kexec_ready_to_reboot))
> + cpu_relax();
> + /*flush destination*/
> + if (save_image)
> + mpc85xx_smp_flush_dcache_kexec(save_image, 1);
> +
> + flush_icache_range(wait_code_buffer,
> + wait_code_buffer + relocate_smp_cpu_size);
> + flush_dcache_range(wait_code_buffer,
> + wait_code_buffer + relocate_smp_cpu_size);
> +
> + atomic_inc(&kexec_slave_finish);
> +
> + ((void (*)(void)) wait_code_buffer)();
> + /* NOTREACHED */
> + }
> }
> }
>
> @@ -285,13 +382,23 @@ static void mpc85xx_smp_kexec_down(void *arg)
> ppc_md.kexec_cpu_down(0,1);
> }
>
> -static void map_and_flush(unsigned long paddr)
> +static void map_and_flush(unsigned long paddr, int atomic)
> {
> struct page *page = pfn_to_page(paddr >> PAGE_SHIFT);
> - unsigned long kaddr = (unsigned long)kmap(page);
> + unsigned long kaddr;
> +
> + if (atomic)
> + kaddr = (unsigned long)kmap_atomic(page);
> + else
> + kaddr = (unsigned long)kmap(page);
>
> flush_dcache_range(kaddr, kaddr + PAGE_SIZE);
> - kunmap(page);
> + flush_icache_range(kaddr, kaddr + PAGE_SIZE);
> +
> + if (atomic)
> + kunmap_atomic((void *)kaddr);
> + else
> + kunmap(page);
> }
>
> /**
> @@ -300,7 +407,7 @@ static void map_and_flush(unsigned long paddr)
> * are performed out of an overabundance of caution as interrupts are not
> * disabled yet and we can switch cores
> */
> -static void mpc85xx_smp_flush_dcache_kexec(struct kimage *image)
> +static void mpc85xx_smp_flush_dcache_kexec(struct kimage *image, int atomic)
> {
> kimage_entry_t *ptr, entry;
> unsigned long paddr;
> @@ -312,18 +419,18 @@ static void
> mpc85xx_smp_flush_dcache_kexec(struct kimage *image)
> ptr = (entry & IND_INDIRECTION) ?
> phys_to_virt(entry & PAGE_MASK) : ptr + 1) {
> if (!(entry & IND_DESTINATION)) {
> - map_and_flush(entry);
> + map_and_flush(entry, atomic);
> }
> }
> /* flush out last IND_DONE page */
> - map_and_flush(entry);
> + map_and_flush(entry, atomic);
> } else {
> /* crash type kexec images are copied to the crash region */
> for (i = 0; i < image->nr_segments; i++) {
> struct kexec_segment *seg = &image->segment[i];
> for (paddr = seg->mem; paddr < seg->mem + seg->memsz;
> paddr += PAGE_SIZE) {
> - map_and_flush(paddr);
> + map_and_flush(paddr, atomic);
> }
> }
> }
> @@ -335,13 +442,18 @@ static void
> mpc85xx_smp_flush_dcache_kexec(struct kimage *image)
>
> static void mpc85xx_smp_machine_kexec(struct kimage *image)
> {
> + extern const unsigned char relocate_smp_cpu_wait[];
> + extern const unsigned int relocate_smp_cpu_offset;
> int timeout = INT_MAX;
> int i, num_cpus = num_present_cpus();
>
> mpc85xx_smp_flush_dcache_kexec(image);
>
> - if (image->type == KEXEC_TYPE_DEFAULT)
> + if (image->type == KEXEC_TYPE_DEFAULT) {
> + save_image = image;
> + mb();
> smp_call_function(mpc85xx_smp_kexec_down, NULL, 0);
> + }
>
> while ( (atomic_read(&kexec_down_cpus) != (num_cpus - 1)) &&
> ( timeout > 0 ) )
> @@ -352,12 +464,34 @@ static void mpc85xx_smp_machine_kexec(struct
> kimage *image)
> if ( !timeout )
> printk(KERN_ERR "Unable to bring down secondary cpu(s)");
>
> - for_each_online_cpu(i)
> - {
> - if ( i == smp_processor_id() ) continue;
> - mpic_reset_core(i);
> - }
> + if (image->type == KEXEC_TYPE_DEFAULT) {
>
> + wait_code_buffer =
> + (unsigned long)page_address(image->control_code_page)+
> + relocate_smp_cpu_offset;
> +
> + /* copy slave cpu spin code to the control code page */
> + memcpy((void *)wait_code_buffer, relocate_smp_cpu_wait,
> + relocate_smp_cpu_size);
> + atomic_set(&kexec_ready_to_reboot, 1);
> + mb();
> + timeout = INT_MAX;
> +
> + while ((atomic_read(&kexec_slave_finish) != (num_cpus-1)) &&
> + (timeout > 0))
> + timeout--;
> +
> + if (!timeout)
> + printk(KERN_ERR "Unable to wait for secondary cpu(s) to
> flush caches\n");
> +
> + } else {
> + for_each_online_cpu(i)
> + {
> + if (i == smp_processor_id())
> + continue;
> + mpic_reset_core(i);
> + }
> + }
> default_machine_kexec(image);
> }
> #endif /* CONFIG_KEXEC */
^ permalink raw reply
* RE: [RFC PATCH v2 04/11] pstore: Add compression support to pstore
From: Seiji Aguchi @ 2013-09-04 1:44 UTC (permalink / raw)
To: Aruna Balakrishnaiah, Luck, Tony
Cc: jkenisto@linux.vnet.ibm.com, keescook@chromium.org,
mahesh@linux.vnet.ibm.com, ccross@android.com,
linux-kernel@vger.kernel.org, linuxppc-dev@ozlabs.org,
cbouatmailru@gmail.com
In-Reply-To: <521C36F4.8030607@linux.vnet.ibm.com>
Aruna,
Sorry for the late response.
> Seiji,
>=20
> 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 c=
urrent cording.
1) In pstore_decompress(), why not use zlib_inflateInit2() instead of zlib_=
inflateInit()?
If you use zlib_deflateInit2() for specifying window_bit at compressi=
ng time,=20
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 be=
ginning of=20
compressing/decompressing time.
So, in pstore case, stream.workspace must be initialized to 0 with mem=
set() 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 efiva=
rs driver.
<snip>
Panic#2 Part1
<4>[ 75.665020] [<ffffffff811af59c>] SyS_write+0x4c/0xa0
<4>[ 75.665020] [<ffffffff8168be82>] 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 <c6> 04 25 00 00 00 00 01 5d c3 0f 1f 44 00 00 55 31 c0 c7 05 5e=20
<1>[ 75.665020] RIP [<ffffffff813d3946>] sysrq_handle_crash+0x16/0x20
<4>[ 75.665020] RSP <ffff88007852de80>
<4>[ 75.665020] CR2: 0000000000000000
<4>[ 75.665020] ---[ end trace 97bb4a1f8d3fe7b2 ]---
<3>[ 75.665020] pstore_dump hsize=3D13 len=3D2155 big_oops_buf_sz=3D2275 =
psinfo->bufsize=3D1024
<3>[ 75.665020] pstore_dump hsize=3D13 len=3D2246 big_oops_buf_sz=3D2275 =
psinfo->bufsize=3D1024
<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=3D13 len=3D2239 big_oops_buf_sz=3D2275 =
psinfo->bufsize=3D1024
<3>[ 75.665020] pstore_dump hsize=3D13 len=3D2231 big_oops_buf_sz=3D2275 =
psinfo->bufsize=3D1024
<3>[ 75.665020] pstore_dump hsize=3D13 len=3D2185 big_oops_buf_sz=3D2275 =
psinfo->bufsize=3D1024
<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=3D13 len=3D2234 big_oops_buf_sz=3D2275 =
psinfo->bufsize=3D1024
<3>[ 75.665020] pstore_dump hsize=3D13 len=3D2208 big_oops_buf_sz=3D2275 =
psinfo->bufsize=3D1024
<3>[ 75.665020] pstore_dump hsize=3D13 len=3D2218 big_oops_buf_sz=3D2275 =
psinfo->bufsize=3D1024
<3>[ 75.665020] pstore_dump hsize=3D13 len=3D2222 big_oops_buf_sz=3D2275 =
psinfo->bufsize=3D1024
<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=3D14 len=3D2256 big_oops_buf_sz=3D2275 =
psinfo->bufsize=3D1024
<3>[ 75.665020] pstore_dump hsize=3D14 len=3D2219 big_oops_buf_sz=3D2275 =
psinfo->bufsize=3D1024
<3>[ 75.665020] pstore_dump hsize=3D14 len=3D2226 big_oops_buf_sz=3D2275 =
psinfo->bufsize=3D1024
<0>[ 75.665020] Kernel panic - not syncing: Fatal exception
<3>[ 75.665020] drm_kms_helper: panic occurred, switching back to text co=
nsole
<snip>
Seiji
^ 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