* Re: [PATCH 1/1] drivers/char/tpm: remove tasklet and cleanup
From: key @ 2012-09-24 15:48 UTC (permalink / raw)
To: key
Cc: rcj, linux-kernel, James Morris, linux-security-module,
tpmdd-devel, adlai, Ashley Lai, linuxppc-dev
In-Reply-To: <20120924141041.GA2741@ennui.austin.ibm.com>
On Mon, Sep 24, 2012 at 09:10:41AM -0500, key@linux.vnet.ibm.com wrote:
> On Mon, Sep 24, 2012 at 12:26:05PM +1000, James Morris wrote:
> > On Wed, 12 Sep 2012, Ashley Lai wrote:
> >
> > > This patch removed the tasklet and moved the wait queue into the
> > > private structure. It also cleaned up the response CRQ path.
> > >
> > > Signed-off-by: Ashley Lai <adlai@us.ibm.com>
> >
> >
> > Kent: any comment on this? You should probably push this to me via your
> > tree.
>
> Oh, I thought we were waiting on Ben. This looks good to me, I'll get
> this to you today.
Ashley tells me Ben's review is in the works, so I'll send once we
have it.
Kent
>
> Kent
>
^ permalink raw reply
* Please pull 'next' branch of 5xxx tree
From: Anatolij Gustschin @ 2012-09-24 14:45 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev list
Hi Ben,
please pull mpc5xxx patches for next. Thanks!
Anatolij
The following changes since commit 55d512e245bc7699a8800e23df1a24195dd08217:
Linux 3.6-rc5 (2012-09-08 16:43:45 -0700)
are available in the git repository at:
git://git.denx.de/linux-2.6-agust.git next
Anatolij Gustschin (3):
powerpc/mpc5200: add dts files for ifm camera machines
dt/misc: add bindings documentation for ifm camera sensor interface
powerpc/mpc52xx_lpbfifo: optionally defer fifo transfer start
Paul Gortmaker (1):
powerpc: Option FB_FSL_DIU is not really optional for mpc512x
Richard Weinberger (1):
powerpc: 512x: Fix mpc5121_clk_get()
Documentation/devicetree/bindings/misc/ifm-csi.txt | 41 ++++++
arch/powerpc/boot/dts/o2d.dts | 47 +++++++
arch/powerpc/boot/dts/o2d.dtsi | 139 ++++++++++++++++++++
arch/powerpc/boot/dts/o2d300.dts | 52 ++++++++
arch/powerpc/boot/dts/o2dnt2.dts | 48 +++++++
arch/powerpc/boot/dts/o2i.dts | 33 +++++
arch/powerpc/boot/dts/o2mnt.dts | 33 +++++
arch/powerpc/boot/dts/o3dnt.dts | 48 +++++++
arch/powerpc/include/asm/mpc52xx.h | 2 +
arch/powerpc/platforms/512x/Kconfig | 1 +
arch/powerpc/platforms/512x/clock.c | 6 +-
arch/powerpc/platforms/512x/mpc512x_shared.c | 6 -
arch/powerpc/platforms/52xx/mpc5200_simple.c | 1 +
arch/powerpc/platforms/52xx/mpc52xx_lpbfifo.c | 35 +++++-
14 files changed, 483 insertions(+), 9 deletions(-)
create mode 100644 Documentation/devicetree/bindings/misc/ifm-csi.txt
create mode 100644 arch/powerpc/boot/dts/o2d.dts
create mode 100644 arch/powerpc/boot/dts/o2d.dtsi
create mode 100644 arch/powerpc/boot/dts/o2d300.dts
create mode 100644 arch/powerpc/boot/dts/o2dnt2.dts
create mode 100644 arch/powerpc/boot/dts/o2i.dts
create mode 100644 arch/powerpc/boot/dts/o2mnt.dts
create mode 100644 arch/powerpc/boot/dts/o3dnt.dts
^ permalink raw reply
* RE: [PATCH v3] powerpc/usb: fix bug of CPU hang when missing USB PHY clock
From: Liu Shengzhou-B36685 @ 2012-09-24 14:44 UTC (permalink / raw)
To: Greg KH, Kumar Gala
Cc: linux-usb@vger.kernel.org, linuxppc-dev@lists.ozlabs.org
In-Reply-To: <20120922144853.GA10935@kroah.com>
DQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IEdyZWcgS0ggW21haWx0bzpn
cmVnQGtyb2FoLmNvbV0NCj4gU2VudDogMjAxMsTqOdTCMjLI1SAyMjo0OQ0KPiBUbzogS3VtYXIg
R2FsYQ0KPiBDYzogTGl1IFNoZW5nemhvdS1CMzY2ODU7IGxpbnV4cHBjLWRldkBsaXN0cy5vemxh
YnMub3JnOyBsaW51eC0NCj4gdXNiQHZnZXIua2VybmVsLm9yZw0KPiBTdWJqZWN0OiBSZTogW1BB
VENIIHYzXSBwb3dlcnBjL3VzYjogZml4IGJ1ZyBvZiBDUFUgaGFuZyB3aGVuIG1pc3NpbmcNCj4g
VVNCIFBIWSBjbG9jaw0KPiANCj4gT24gU2F0LCBTZXAgMjIsIDIwMTIgYXQgMDk6Mzk6MTVBTSAt
MDUwMCwgS3VtYXIgR2FsYSB3cm90ZToNCj4gPg0KPiA+IE9uIFNlcCAyMSwgMjAxMiwgYXQgMTE6
NDMgQU0sIEdyZWcgS0ggd3JvdGU6DQo+ID4NCj4gPiA+IE9uIFR1ZSwgU2VwIDE4LCAyMDEyIGF0
IDA0OjUyOjM5UE0gKzA4MDAsIFNoZW5nemhvdSBMaXUgd3JvdGU6DQo+ID4gPj4gd2hlbiBtaXNz
aW5nIFVTQiBQSFkgY2xvY2ssIGtlcm5lbCBib290aW5nIHVwIHdpbGwgaGFuZyBkdXJpbmcgVVNC
DQo+ID4gPj4gaW5pdGlhbGl6YXRpb24uIFdlIHNob3VsZCBjaGVjayBVU0JHUFtQSFlfQ0xLX1ZB
TElEXSBiaXQgdG8gYXZvaWQNCj4gPiA+PiBDUFUgaGFuZ2luZyBpbiB0aGlzIGNhc2UuDQo+ID4g
Pj4NCj4gPiA+PiBTaWduZWQtb2ZmLWJ5OiBTaGVuZ3pob3UgTGl1IDxTaGVuZ3pob3UuTGl1QGZy
ZWVzY2FsZS5jb20+DQo+ID4gPj4gLS0tDQo+ID4gPj4gdjMgY2hhbmdlOiBubyBjaGVjayBmb3Ig
VVRNSSBQSFkuDQo+ID4gPj4gdjIgY2hhbmdlOiB1c2Ugc3Bpbl9ldmVudF90aW1lb3V0KCkgaW5z
dGVhZC4NCj4gPiA+Pg0KPiA+ID4+IGRyaXZlcnMvdXNiL2hvc3QvZWhjaS1mc2wuYyB8ICAgNTcg
KysrKysrKysrKysrKysrKysrKysrKysrKysrKystLQ0KPiAtLS0tLS0tLS0tLQ0KPiA+ID4+IGRy
aXZlcnMvdXNiL2hvc3QvZWhjaS1mc2wuaCB8ICAgIDEgKw0KPiA+ID4+IGluY2x1ZGUvbGludXgv
ZnNsX2RldmljZXMuaCB8ICAgIDEgKw0KPiA+ID4+IDMgZmlsZXMgY2hhbmdlZCwgNDEgaW5zZXJ0
aW9ucygrKSwgMTggZGVsZXRpb25zKC0pDQo+ID4gPg0KPiA+ID4gVGhpcyBpcyBhbHJlYWR5IGFw
cGxpZWQsIHJpZ2h0Pw0KPiA+ID4NCj4gPiA+IGdyZWcgay1oDQo+ID4NCj4gPiBJdCBhcHBlYXJz
IHRoYXQgdjIgb2YgdGhlIHBhdGNoIGlzIGFwcGxpZWQgdG8geW91ciB1c2ItbmV4dCBicmFuY2gu
DQo+ID4NCj4gPiBpbiBkcml2ZXJzL3VzYi9ob3N0L2VoY2ktZnNsLmMNCj4gPg0KPiA+IFYyOg0K
PiA+IEBAIC0yNjIsMjMgKzI2NiwzNCBAQCBzdGF0aWMgdm9pZCBlaGNpX2ZzbF9zZXR1cF9waHko
c3RydWN0IHVzYl9oY2QNCj4gKmhjZCwNCj4gPiAgICAgICAgIGNhc2UgRlNMX1VTQjJfUEhZX05P
TkU6DQo+ID4gICAgICAgICAgICAgICAgIGJyZWFrOw0KPiA+ICAgICAgICAgfQ0KPiA+ICsNCj4g
PiArICAgICAgIGlmICgocGRhdGEtPmNvbnRyb2xsZXJfdmVyKSAmJiAoKHBoeV9tb2RlID09DQo+
IEZTTF9VU0IyX1BIWV9VTFBJKSB8fA0KPiA+ICsgICAgICAgICAgICAgICAgICAgICAgIChwaHlf
bW9kZSA9PSBGU0xfVVNCMl9QSFlfVVRNSSkpKSB7DQo+ID4NCj4gPiBWMzoNCj4gPg0KPiA+IEBA
IC0yNjIsMjMgKzI2NiwzMyBAQCAgc3RhdGljIHZvaWQgZWhjaV9mc2xfc2V0dXBfcGh5KHN0cnVj
dCB1c2JfaGNkDQo+ICpoY2QsDQo+ID4NCj4gPiAgCWNhc2UgRlNMX1VTQjJfUEhZX05PTkU6DQo+
ID4gIAkJYnJlYWs7DQo+ID4gIAl9DQo+ID4NCj4gPiArDQo+ID4gKwlpZiAocGRhdGEtPmNvbnRy
b2xsZXJfdmVyICYmIChwaHlfbW9kZSA9PSBGU0xfVVNCMl9QSFlfVUxQSSkpIHsNCj4gPiArCQkv
KiBjaGVjayBQSFlfQ0xLX1ZBTElEIHRvIGdldCBwaHkgY2xrIHZhbGlkICovDQo+IA0KPiBPaywg
Y2FuIHNvbWVvbmUgcGxlYXNlIG1ha2UgdGhlIGluY3JlbWVudGFsIHBhdGNoIHRoYXQgSSBuZWVk
IHRvIGFwcGx5DQo+IGhlcmUgYW5kIHNlbmQgaXQgdG8gbWU/DQo+IA0KPiB0aGFua3MsDQo+IA0K
PiBncmVnIGstaA0KDQpIaSBncmVnLA0KDQpJIGhhdmUgc2VudCB0aGUgYmVsb3cgaW5jcmVtZW50
YWwgcGF0Y2ggdG8geW91LCBwbGVhc2Ugc3F1YXNoIGl0IGludG8gdGhlIHByZXZpb3VzIHBhdGNo
IHYyLCB3aGljaCBoYWQgYmVlbiBhcHBsaWVkIGluIHlvdXIgdXNiLW5leHQgYnJhbmNoLiANCmh0
dHA6Ly9wYXRjaHdvcmsub3psYWJzLm9yZy9wYXRjaC8xODY0NDMvDQoNClRoYW5rcywNClNoZW5n
emhvdQ0KDQo=
^ permalink raw reply
* Re: [PATCH v3 1/2] mmc: Move mmc_delay() to include/linux/mmc/core.h
From: Tabi Timur-B04825 @ 2012-09-24 14:38 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Lan Chunhe-B25806, linuxppc-dev@lists.ozlabs.org,
Gala Kumar-B11780, cjb@laptop.org, linux-mmc@vger.kernel.org
In-Reply-To: <201209241317.32425.arnd@arndb.de>
On Mon, Sep 24, 2012 at 8:17 AM, Arnd Bergmann <arnd@arndb.de> wrote:
>
>> static inline void mmc_delay(unsigned int ms)
>> {
>> msleep(ms);
>> }
>
> That would be my preferred choice, unless someone has specific issues wit=
h this.
If we're going to do that, then just get rid of mmc_delay and replace
all calls to it with msleep(). Why bother with the inline function?
There's nothing really MMC-specific about it.
--=20
Timur Tabi
Linux kernel developer at Freescale=
^ permalink raw reply
* [PATCH] powerpc/usb: remove checking PHY_CLK_VALID for UTMI PHY
From: Shengzhou Liu @ 2012-09-24 14:01 UTC (permalink / raw)
To: linuxppc-dev, greg; +Cc: linux-usb, Shengzhou Liu
PHY_CLK_VALID bit doesn't work properly with UTMI PHY.
e.g. This bit is always zero on P5040, etc.
There is no need to check this bit for UTMI PHY, just keep
checking for ULPI PHY to prevent system hanging.
This patch should be squashed into previous commit 3735ba8db8e6e
"powerpc/usb: fix bug of CPU hang when missing USB PHY clock"
Signed-off-by: Shengzhou Liu <Shengzhou.Liu@freescale.com>
---
drivers/usb/host/ehci-fsl.c | 3 +--
include/linux/fsl_devices.h | 2 +-
2 files changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/usb/host/ehci-fsl.c b/drivers/usb/host/ehci-fsl.c
index 11ff4b4..9bfde82 100644
--- a/drivers/usb/host/ehci-fsl.c
+++ b/drivers/usb/host/ehci-fsl.c
@@ -267,8 +267,7 @@ static int ehci_fsl_setup_phy(struct usb_hcd *hcd,
break;
}
- if ((pdata->controller_ver) && ((phy_mode == FSL_USB2_PHY_ULPI) ||
- (phy_mode == FSL_USB2_PHY_UTMI))) {
+ if (pdata->controller_ver && (phy_mode == FSL_USB2_PHY_ULPI)) {
/* check PHY_CLK_VALID to get phy clk valid */
if (!spin_event_timeout(in_be32(non_ehci + FSL_SOC_USB_CTRL) &
PHY_CLK_VALID, FSL_USB_PHY_CLK_TIMEOUT, 0)) {
diff --git a/include/linux/fsl_devices.h b/include/linux/fsl_devices.h
index ccfc4bb..700bf31 100644
--- a/include/linux/fsl_devices.h
+++ b/include/linux/fsl_devices.h
@@ -19,7 +19,7 @@
#define FSL_UTMI_PHY_DLY 10 /*As per P1010RM, delay for UTMI
PHY CLK to become stable - 10ms*/
-#define FSL_USB_PHY_CLK_TIMEOUT 1000 /* uSec */
+#define FSL_USB_PHY_CLK_TIMEOUT 10000 /* uSec */
#define FSL_USB_VER_OLD 0
#define FSL_USB_VER_1_6 1
#define FSL_USB_VER_2_2 2
--
1.6.4
^ permalink raw reply related
* Re: [PATCH 1/1] drivers/char/tpm: remove tasklet and cleanup
From: key @ 2012-09-24 14:10 UTC (permalink / raw)
To: James Morris
Cc: key, linux-kernel, Ashley Lai, linux-security-module, tpmdd-devel,
adlai, rcj, linuxppc-dev
In-Reply-To: <alpine.LRH.2.02.1209241225230.678@tundra.namei.org>
On Mon, Sep 24, 2012 at 12:26:05PM +1000, James Morris wrote:
> On Wed, 12 Sep 2012, Ashley Lai wrote:
>
> > This patch removed the tasklet and moved the wait queue into the
> > private structure. It also cleaned up the response CRQ path.
> >
> > Signed-off-by: Ashley Lai <adlai@us.ibm.com>
>
>
> Kent: any comment on this? You should probably push this to me via your
> tree.
Oh, I thought we were waiting on Ben. This looks good to me, I'll get
this to you today.
Kent
>
>
> > ---
> > James,
> >
> > This patch is based on your "next" branch.
> > git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/linux-security.git
> >
> > Thanks,
> > Ashley Lai
> > ---
> > drivers/char/tpm/tpm_ibmvtpm.c | 81 +++++++++++++++---------------------------
> > drivers/char/tpm/tpm_ibmvtpm.h | 5 ++-
> > 2 files changed, 30 insertions(+), 56 deletions(-)
> >
> > diff --git a/drivers/char/tpm/tpm_ibmvtpm.c b/drivers/char/tpm/tpm_ibmvtpm.c
> > index efc4ab3..88a95ea 100644
> > --- a/drivers/char/tpm/tpm_ibmvtpm.c
> > +++ b/drivers/char/tpm/tpm_ibmvtpm.c
> > @@ -38,8 +38,6 @@ static struct vio_device_id tpm_ibmvtpm_device_table[] __devinitdata = {
> > };
> > MODULE_DEVICE_TABLE(vio, tpm_ibmvtpm_device_table);
> >
> > -DECLARE_WAIT_QUEUE_HEAD(wq);
> > -
> > /**
> > * ibmvtpm_send_crq - Send a CRQ request
> > * @vdev: vio device struct
> > @@ -83,6 +81,7 @@ static int tpm_ibmvtpm_recv(struct tpm_chip *chip, u8 *buf, size_t count)
> > {
> > struct ibmvtpm_dev *ibmvtpm;
> > u16 len;
> > + int sig;
> >
> > ibmvtpm = (struct ibmvtpm_dev *)chip->vendor.data;
> >
> > @@ -91,22 +90,23 @@ static int tpm_ibmvtpm_recv(struct tpm_chip *chip, u8 *buf, size_t count)
> > return 0;
> > }
> >
> > - wait_event_interruptible(wq, ibmvtpm->crq_res.len != 0);
> > + sig = wait_event_interruptible(ibmvtpm->wq, ibmvtpm->res_len != 0);
> > + if (sig)
> > + return -EINTR;
> > +
> > + len = ibmvtpm->res_len;
> >
> > - if (count < ibmvtpm->crq_res.len) {
> > + if (count < len) {
> > dev_err(ibmvtpm->dev,
> > "Invalid size in recv: count=%ld, crq_size=%d\n",
> > - count, ibmvtpm->crq_res.len);
> > + count, len);
> > return -EIO;
> > }
> >
> > spin_lock(&ibmvtpm->rtce_lock);
> > - memcpy((void *)buf, (void *)ibmvtpm->rtce_buf, ibmvtpm->crq_res.len);
> > - memset(ibmvtpm->rtce_buf, 0, ibmvtpm->crq_res.len);
> > - ibmvtpm->crq_res.valid = 0;
> > - ibmvtpm->crq_res.msg = 0;
> > - len = ibmvtpm->crq_res.len;
> > - ibmvtpm->crq_res.len = 0;
> > + memcpy((void *)buf, (void *)ibmvtpm->rtce_buf, len);
> > + memset(ibmvtpm->rtce_buf, 0, len);
> > + ibmvtpm->res_len = 0;
> > spin_unlock(&ibmvtpm->rtce_lock);
> > return len;
> > }
> > @@ -273,7 +273,6 @@ static int __devexit tpm_ibmvtpm_remove(struct vio_dev *vdev)
> > int rc = 0;
> >
> > free_irq(vdev->irq, ibmvtpm);
> > - tasklet_kill(&ibmvtpm->tasklet);
> >
> > do {
> > if (rc)
> > @@ -372,7 +371,6 @@ static int ibmvtpm_reset_crq(struct ibmvtpm_dev *ibmvtpm)
> > static int tpm_ibmvtpm_resume(struct device *dev)
> > {
> > struct ibmvtpm_dev *ibmvtpm = ibmvtpm_get_data(dev);
> > - unsigned long flags;
> > int rc = 0;
> >
> > do {
> > @@ -387,10 +385,11 @@ static int tpm_ibmvtpm_resume(struct device *dev)
> > return rc;
> > }
> >
> > - spin_lock_irqsave(&ibmvtpm->lock, flags);
> > - vio_disable_interrupts(ibmvtpm->vdev);
> > - tasklet_schedule(&ibmvtpm->tasklet);
> > - spin_unlock_irqrestore(&ibmvtpm->lock, flags);
> > + rc = vio_enable_interrupts(ibmvtpm->vdev);
> > + if (rc) {
> > + dev_err(dev, "Error vio_enable_interrupts rc=%d\n", rc);
> > + return rc;
> > + }
> >
> > rc = ibmvtpm_crq_send_init(ibmvtpm);
> > if (rc)
> > @@ -467,7 +466,7 @@ static struct ibmvtpm_crq *ibmvtpm_crq_get_next(struct ibmvtpm_dev *ibmvtpm)
> > if (crq->valid & VTPM_MSG_RES) {
> > if (++crq_q->index == crq_q->num_entry)
> > crq_q->index = 0;
> > - rmb();
> > + smp_rmb();
> > } else
> > crq = NULL;
> > return crq;
> > @@ -535,11 +534,9 @@ static void ibmvtpm_crq_process(struct ibmvtpm_crq *crq,
> > ibmvtpm->vtpm_version = crq->data;
> > return;
> > case VTPM_TPM_COMMAND_RES:
> > - ibmvtpm->crq_res.valid = crq->valid;
> > - ibmvtpm->crq_res.msg = crq->msg;
> > - ibmvtpm->crq_res.len = crq->len;
> > - ibmvtpm->crq_res.data = crq->data;
> > - wake_up_interruptible(&wq);
> > + /* len of the data in rtce buffer */
> > + ibmvtpm->res_len = crq->len;
> > + wake_up_interruptible(&ibmvtpm->wq);
> > return;
> > default:
> > return;
> > @@ -559,38 +556,19 @@ static void ibmvtpm_crq_process(struct ibmvtpm_crq *crq,
> > static irqreturn_t ibmvtpm_interrupt(int irq, void *vtpm_instance)
> > {
> > struct ibmvtpm_dev *ibmvtpm = (struct ibmvtpm_dev *) vtpm_instance;
> > - unsigned long flags;
> > -
> > - spin_lock_irqsave(&ibmvtpm->lock, flags);
> > - vio_disable_interrupts(ibmvtpm->vdev);
> > - tasklet_schedule(&ibmvtpm->tasklet);
> > - spin_unlock_irqrestore(&ibmvtpm->lock, flags);
> > -
> > - return IRQ_HANDLED;
> > -}
> > -
> > -/**
> > - * ibmvtpm_tasklet - Interrupt handler tasklet
> > - * @data: ibm vtpm device struct
> > - *
> > - * Returns:
> > - * Nothing
> > - **/
> > -static void ibmvtpm_tasklet(void *data)
> > -{
> > - struct ibmvtpm_dev *ibmvtpm = data;
> > struct ibmvtpm_crq *crq;
> > - unsigned long flags;
> >
> > - spin_lock_irqsave(&ibmvtpm->lock, flags);
> > + /* while loop is needed for initial setup (get version and
> > + * get rtce_size). There should be only one tpm request at any
> > + * given time.
> > + */
> > while ((crq = ibmvtpm_crq_get_next(ibmvtpm)) != NULL) {
> > ibmvtpm_crq_process(crq, ibmvtpm);
> > crq->valid = 0;
> > - wmb();
> > + smp_wmb();
> > }
> >
> > - vio_enable_interrupts(ibmvtpm->vdev);
> > - spin_unlock_irqrestore(&ibmvtpm->lock, flags);
> > + return IRQ_HANDLED;
> > }
> >
> > /**
> > @@ -650,9 +628,6 @@ static int __devinit tpm_ibmvtpm_probe(struct vio_dev *vio_dev,
> > goto reg_crq_cleanup;
> > }
> >
> > - tasklet_init(&ibmvtpm->tasklet, (void *)ibmvtpm_tasklet,
> > - (unsigned long)ibmvtpm);
> > -
> > rc = request_irq(vio_dev->irq, ibmvtpm_interrupt, 0,
> > tpm_ibmvtpm_driver_name, ibmvtpm);
> > if (rc) {
> > @@ -666,13 +641,14 @@ static int __devinit tpm_ibmvtpm_probe(struct vio_dev *vio_dev,
> > goto init_irq_cleanup;
> > }
> >
> > + init_waitqueue_head(&ibmvtpm->wq);
> > +
> > crq_q->index = 0;
> >
> > ibmvtpm->dev = dev;
> > ibmvtpm->vdev = vio_dev;
> > chip->vendor.data = (void *)ibmvtpm;
> >
> > - spin_lock_init(&ibmvtpm->lock);
> > spin_lock_init(&ibmvtpm->rtce_lock);
> >
> > rc = ibmvtpm_crq_send_init(ibmvtpm);
> > @@ -689,7 +665,6 @@ static int __devinit tpm_ibmvtpm_probe(struct vio_dev *vio_dev,
> >
> > return rc;
> > init_irq_cleanup:
> > - tasklet_kill(&ibmvtpm->tasklet);
> > do {
> > rc1 = plpar_hcall_norets(H_FREE_CRQ, vio_dev->unit_address);
> > } while (rc1 == H_BUSY || H_IS_LONG_BUSY(rc1));
> > diff --git a/drivers/char/tpm/tpm_ibmvtpm.h b/drivers/char/tpm/tpm_ibmvtpm.h
> > index 4296eb4..bd82a79 100644
> > --- a/drivers/char/tpm/tpm_ibmvtpm.h
> > +++ b/drivers/char/tpm/tpm_ibmvtpm.h
> > @@ -38,13 +38,12 @@ struct ibmvtpm_dev {
> > struct vio_dev *vdev;
> > struct ibmvtpm_crq_queue crq_queue;
> > dma_addr_t crq_dma_handle;
> > - spinlock_t lock;
> > - struct tasklet_struct tasklet;
> > u32 rtce_size;
> > void __iomem *rtce_buf;
> > dma_addr_t rtce_dma_handle;
> > spinlock_t rtce_lock;
> > - struct ibmvtpm_crq crq_res;
> > + wait_queue_head_t wq;
> > + u16 res_len;
> > u32 vtpm_version;
> > };
> >
> > --
> > 1.7.11.2
> >
> >
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> > the body of a message to majordomo@vger.kernel.org
> > More majordomo info at http://vger.kernel.org/majordomo-info.html
> > Please read the FAQ at http://www.tux.org/lkml/
> >
>
> --
> James Morris
> <jmorris@namei.org>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
^ permalink raw reply
* Re: PCI device not working
From: Davide Viti @ 2012-09-24 13:27 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <CAKpAL0nTu9XXFgz7i5-1LmetrV05qfQcdf1zGxqHzODgQ7xjKA@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 4724 bytes --]
Hi,
does the output I've included show anything wrong or should I post
something else to help identifying the cause of the problem?
thank you in advance,
Davide
2012/9/21 Davide Viti <zinosat@tiscali.it>
> I mean there are two controllers and both of them have a device
> "subtended" (both 0x1b65:0xabba).
> u-boot can see both devices, linux detects only the device attached to the
> first controller.
>
> Here's the output of lspci and /proc/iomem :
>
> root@(none):/# lspci -v
>
> 0000:00:00.0 Class 0604: Device 1957:0100 (rev 11)
>
> Flags: bus master, fast devsel, latency 0
>
> Memory at <ignored> (32-bit, non-prefetchable)
>
> Bus: primary=00, secondary=01, subordinate=01, sec-latency=0
>
> I/O behind bridge: 00000000-00000fff
>
> Memory behind bridge: a0000000-afffffff
>
> Capabilities: [44] Power Management version 2
>
> Capabilities: [4c] Express Root Port (Slot-), MSI 00
>
> Capabilities: [100] Advanced Error Reporting
>
>
>
> 0000:01:00.0 Class 0280: Device 1b65:abba (rev 01)
>
> Flags: bus master, fast devsel, latency 0, IRQ 16
>
> Memory at a0000000 (32-bit, non-prefetchable) [size=1K]
>
> Memory at a0010000 (32-bit, non-prefetchable) [size=64K]
>
> Capabilities: [50] MSI: Enable- Count=1/1 Maskable- 64bit+
>
> Capabilities: [78] Power Management version 3
>
> Capabilities: [80] Express Endpoint, MSI 00
>
> Capabilities: [100] Virtual Channel <?>
>
> Capabilities: [800] Advanced Error Reporting
>
>
>
> 0001:02:00.0 Class 0604: Device 1957:0100 (rev 11)
>
> Flags: bus master, fast devsel, latency 0
>
> Memory at <ignored> (32-bit, non-prefetchable)
>
> Bus: primary=00, secondary=03, subordinate=03, sec-latency=0
>
> I/O behind bridge: 00000000-00000fff
>
> Memory behind bridge: b0000000-bfffffff
>
> Capabilities: [44] Power Management version 2
>
> Capabilities: [4c] Express Root Port (Slot-), MSI 00
>
> Capabilities: [100] Advanced Error Reporting
>
>
> root@(none):/# cat /proc/iomem
>
> a0000000-afffffff : /pcie@ffe09000
>
> a0000000-afffffff : PCI Bus 0000:01
>
> a0000000-a00003ff : 0000:01:00.0
>
> a0010000-a001ffff : 0000:01:00.0
>
> b0000000-bfffffff : /pcie@ffe0a000
>
> b0000000-bfffffff : PCI Bus 0001:03
>
> ef000000-efffffff : ef000000.nor
>
> ffe04500-ffe04507 : serial
>
> ffe04600-ffe04607 : serial
>
>
> thanx for your help,
>
> Davide
>
>
> I mean that the kernel detects the first controller and the device
> attached to it, plus the second controller: the device on the second
> controller is not detected (same device as the one detected on the first
> controller)
>
> 2012/9/21 Kumar Gala <galak@kernel.crashing.org>
>
>>
>> On Sep 21, 2012, at 6:33 AM, Davide Viti wrote:
>>
>> > Hi,
>> > I'm working on a custom board based on P1020 with two (identical) PCI
>> devices attached;
>> > The work is derived from another board with a single instance of that
>> device.
>> > The system is based on u-boot-2009.11 and Linux 2.6.34.6
>> >
>> > The "pci" command on u-boot, shows me both the PCI controllers and
>> > the attached devices:
>> >
>> > Scanning PCI devices on bus 0
>> > BusDevFun VendorId DeviceId Device Class Sub-Class
>> > _____________________________________________________________
>> > 00.00.00 0x1957 0x0100 Processor 0x20
>> >
>> > Scanning PCI devices on bus 1
>> > BusDevFun VendorId DeviceId Device Class Sub-Class
>> > _____________________________________________________________
>> > 01.00.00 0x1b65 0xabba Network controller 0x80
>> >
>> > Scanning PCI devices on bus 2
>> > BusDevFun VendorId DeviceId Device Class Sub-Class
>> > _____________________________________________________________
>> > 02.00.00 0x1957 0x0100 Processor 0x20
>> >
>> > Scanning PCI devices on bus 3
>> > BusDevFun VendorId DeviceId Device Class Sub-Class
>> > _____________________________________________________________
>> > 03.00.00 0x1b65 0xabba Network controller 0x80
>> >
>> > The kernel detects only the first instance of the device.
>>
>> What do you mean by first instance of the device ?
>>
>> > Didn't get very far while looking at dts file and kernel logs, so I'm
>> > asking for some help on narrowing down the problem.
>> >
>> > I'm wondering if I can assume that the problem is restricted to
>> > kernel/dts and avoid concentrating on uboot.
>> > I can provide any log (didn't want to post tons of details on the first
>> > message)
>>
>> Probably a dts issue.
>>
>> What does lspci in linux say?
>>
>> - k
>>
>>
>
[-- Attachment #2: Type: text/html, Size: 10282 bytes --]
^ permalink raw reply
* Re: PCI device not working
From: Davide Viti @ 2012-09-24 13:25 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <CAKpAL0nTu9XXFgz7i5-1LmetrV05qfQcdf1zGxqHzODgQ7xjKA@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 4561 bytes --]
2012/9/21 Davide Viti <zinosat@tiscali.it>
> I mean there are two controllers and both of them have a device
> "subtended" (both 0x1b65:0xabba).
> u-boot can see both devices, linux detects only the device attached to the
> first controller.
>
> Here's the output of lspci and /proc/iomem :
>
> root@(none):/# lspci -v
>
> 0000:00:00.0 Class 0604: Device 1957:0100 (rev 11)
>
> Flags: bus master, fast devsel, latency 0
>
> Memory at <ignored> (32-bit, non-prefetchable)
>
> Bus: primary=00, secondary=01, subordinate=01, sec-latency=0
>
> I/O behind bridge: 00000000-00000fff
>
> Memory behind bridge: a0000000-afffffff
>
> Capabilities: [44] Power Management version 2
>
> Capabilities: [4c] Express Root Port (Slot-), MSI 00
>
> Capabilities: [100] Advanced Error Reporting
>
>
>
> 0000:01:00.0 Class 0280: Device 1b65:abba (rev 01)
>
> Flags: bus master, fast devsel, latency 0, IRQ 16
>
> Memory at a0000000 (32-bit, non-prefetchable) [size=1K]
>
> Memory at a0010000 (32-bit, non-prefetchable) [size=64K]
>
> Capabilities: [50] MSI: Enable- Count=1/1 Maskable- 64bit+
>
> Capabilities: [78] Power Management version 3
>
> Capabilities: [80] Express Endpoint, MSI 00
>
> Capabilities: [100] Virtual Channel <?>
>
> Capabilities: [800] Advanced Error Reporting
>
>
>
> 0001:02:00.0 Class 0604: Device 1957:0100 (rev 11)
>
> Flags: bus master, fast devsel, latency 0
>
> Memory at <ignored> (32-bit, non-prefetchable)
>
> Bus: primary=00, secondary=03, subordinate=03, sec-latency=0
>
> I/O behind bridge: 00000000-00000fff
>
> Memory behind bridge: b0000000-bfffffff
>
> Capabilities: [44] Power Management version 2
>
> Capabilities: [4c] Express Root Port (Slot-), MSI 00
>
> Capabilities: [100] Advanced Error Reporting
>
>
> root@(none):/# cat /proc/iomem
>
> a0000000-afffffff : /pcie@ffe09000
>
> a0000000-afffffff : PCI Bus 0000:01
>
> a0000000-a00003ff : 0000:01:00.0
>
> a0010000-a001ffff : 0000:01:00.0
>
> b0000000-bfffffff : /pcie@ffe0a000
>
> b0000000-bfffffff : PCI Bus 0001:03
>
> ef000000-efffffff : ef000000.nor
>
> ffe04500-ffe04507 : serial
>
> ffe04600-ffe04607 : serial
>
>
> thanx for your help,
>
> Davide
>
>
> I mean that the kernel detects the first controller and the device
> attached to it, plus the second controller: the device on the second
> controller is not detected (same device as the one detected on the first
> controller)
>
> 2012/9/21 Kumar Gala <galak@kernel.crashing.org>
>
>>
>> On Sep 21, 2012, at 6:33 AM, Davide Viti wrote:
>>
>> > Hi,
>> > I'm working on a custom board based on P1020 with two (identical) PCI
>> devices attached;
>> > The work is derived from another board with a single instance of that
>> device.
>> > The system is based on u-boot-2009.11 and Linux 2.6.34.6
>> >
>> > The "pci" command on u-boot, shows me both the PCI controllers and
>> > the attached devices:
>> >
>> > Scanning PCI devices on bus 0
>> > BusDevFun VendorId DeviceId Device Class Sub-Class
>> > _____________________________________________________________
>> > 00.00.00 0x1957 0x0100 Processor 0x20
>> >
>> > Scanning PCI devices on bus 1
>> > BusDevFun VendorId DeviceId Device Class Sub-Class
>> > _____________________________________________________________
>> > 01.00.00 0x1b65 0xabba Network controller 0x80
>> >
>> > Scanning PCI devices on bus 2
>> > BusDevFun VendorId DeviceId Device Class Sub-Class
>> > _____________________________________________________________
>> > 02.00.00 0x1957 0x0100 Processor 0x20
>> >
>> > Scanning PCI devices on bus 3
>> > BusDevFun VendorId DeviceId Device Class Sub-Class
>> > _____________________________________________________________
>> > 03.00.00 0x1b65 0xabba Network controller 0x80
>> >
>> > The kernel detects only the first instance of the device.
>>
>> What do you mean by first instance of the device ?
>>
>> > Didn't get very far while looking at dts file and kernel logs, so I'm
>> > asking for some help on narrowing down the problem.
>> >
>> > I'm wondering if I can assume that the problem is restricted to
>> > kernel/dts and avoid concentrating on uboot.
>> > I can provide any log (didn't want to post tons of details on the first
>> > message)
>>
>> Probably a dts issue.
>>
>> What does lspci in linux say?
>>
>> - k
>>
>>
>
[-- Attachment #2: Type: text/html, Size: 9528 bytes --]
^ permalink raw reply
* Re: [PATCH] Powerpc 8xx CPM_UART setting MAXIDL register proportionaly to baud rate
From: Alan Cox @ 2012-09-24 13:21 UTC (permalink / raw)
To: Christophe Leroy
Cc: Marcelo Tosatti, linuxppc-dev, linux-kernel, linux-serial
In-Reply-To: <201209240639.q8O6di6f029596@localhost.localdomain>
On Mon, 24 Sep 2012 08:39:44 +0200
Christophe Leroy <christophe.leroy@c-s.fr> wrote:
> MAXIDL is the timeout after which a receive buffer is closed when not
> full if no more characters are received. We calculate it from the
> baudrate so that the duration is always the same at standard rates:
> about 4ms. At 9600 bauds it gives a timeout of 4 characters, which is
> the timeout on the 8250 UART.
>
> Signed-off-by: Christophe Leroy <christophe.leroy@c-s.fr>
Looks good tome - series Acked-by: Alan Cox <alan@linux.intel.com>
^ permalink raw reply
* Re: [PATCH v3 1/2] mmc: Move mmc_delay() to include/linux/mmc/core.h
From: Arnd Bergmann @ 2012-09-24 13:17 UTC (permalink / raw)
To: Chunhe Lan; +Cc: kumar.gala, linux-mmc, cjb, linuxppc-dev, Chunhe Lan
In-Reply-To: <50607A5A.3060103@freescale.com>
On Monday 24 September 2012, Chunhe Lan wrote:
> OK. As you have mentioned, it would been modified to such:
>
> static inline void mmc_delay(unsigned int ms)
> {
> if (ms < 1000 / HZ) {
> cond_resched();
> msleep(ms);
> } else {
> msleep(ms);
> }
> }
This version would be rather broken, because it compares times
in two different units (ms and jiffies), and because it
does a cond_resched() directly before an msleep: both of which
end up calling schedule() and being away for some time,
cond_resched() for an unknown time, and msleep for a minimum
time on top of that.
> OR such:
>
> static inline void mmc_delay(unsigned int ms)
> {
> msleep(ms);
> }
That would be my preferred choice, unless someone has specific issues with this.
> OR other code?
Well, in principle, you could implement something like
static inline void mmc_delay(unsigned int ms)
{
ktime_t end = ktime_add_us(ktime_get(), ms * 1000);
while (1) {
s64 remaining;
cond_resched();
remaining = ktime_to_us(ktime_sub(end, ktime_get()));
if (remaining < 0)
break;
udelay(min_t(u32, remaining, 100));
}
}
Arnd
^ permalink raw reply
* Re: [PATCH][v2] powerpc/mm: using two zones for freescale 64 bit kernel
From: Kumar Gala @ 2012-09-24 12:31 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: linuxppc-dev@lists.ozlabs.org list, Hu Mingkai-B21284,
Chen Yuanquan-B41889, Xie Shaohui-B21989
In-Reply-To: <B042FA91-05A5-4AE8-BCCE-74F843491F50@kernel.crashing.org>
On Sep 20, 2012, at 8:36 AM, Kumar Gala wrote:
>=20
> On Sep 20, 2012, at 5:14 AM, Xie Shaohui-B21989 wrote:
>=20
>>>> On Thu, 2012-08-30 at 15:49 -0500, Kumar Gala wrote:
>>>>> On Aug 24, 2012, at 5:50 AM, Shaohui Xie wrote:
>>>>>=20
>>>>>> PowerPC platform only supports ZONE_DMA zone for 64bit kernel, so
>>>>>> all the memory will be put into this zone. If the memory size is
>>>>>> greater than the device's DMA capability and device uses
>>>>>> dma_alloc_coherent to allocate memory, it will get an address
>>>>>> which is over the device's DMA addressing, the device will fail.
>>>>>>=20
>>>>>> So we split the memory to two zones: zone ZONE_DMA32 &
>>>>>> ZONE_NORMAL, since we already allocate PCICSRBAR/PEXCSRBAR right
>>>>>> below the 4G boundary (if the lowest PCI address is above 4G), so
>>>>>> we constrain the DMA zone ZONE_DMA32 to 2GB, also, we clear flag
>>>>>> __GFP_DMA &
>>>>>> __GFP_DMA32 and set __GFP_DMA32 only if the device's dma_mask <
>>>>>> total memory size. By doing this, devices which cannot DMA all =
the
>>>>>> memory will be limited to ZONE_DMA32, but devices which can DMA
>>>>>> all
>>>> the memory will not be affected by this limitation.
>>>>>>=20
>>>>>> Signed-off-by: Shaohui Xie <Shaohui.Xie@freescale.com>
>>>>>> Signed-off-by: Mingkai Hu <Mingkai.hu@freescale.com>
>>>>>> Signed-off-by: Chen Yuanquan <B41889@freescale.com>
>>>>>> ---
>>>>>> changes for v2:
>>>>>> 1. use a config option for using two zones (ZONE_DMA32 &
>>>>>> ZONE_NORMAL) in freescale 64 bit kernel.
>>>>>>=20
>>>>=20
>>>> There must have been a misunderstanding. I think this should be a
>>>> runtime choice, possibly by the platform code. Any reason that =
can't be
>>> done ?
>>>>=20
>>> [S.H] Do you mean this:
>>>=20
>>> phys_addr_t platform_dma_size (maybe a default value should be used, =
then
>>> platform code will change it)
>>>=20
>>> if (top_of_ram > platform_dma_size)
>>> max_zone_pfns[ZONE_DMA] =3D platform_dma_size >> PAGE_SHIFT; =
else
>>> max_zone_pfns[ZONE_DMA] =3D top_of_ram >> PAGE_SHIFT;
>>>=20
>>> max_zone_pfns[ZONE_NORMAL] =3D top_of_ram >> PAGE_SHIFT;
>>>=20
>>>> Also how does Intel do it ?
>>> [S.H] below are codes in Intel:
>>>=20
>>> 403 void __init zone_sizes_init(void)
>>> 404 {
>>> 405 unsigned long max_zone_pfns[MAX_NR_ZONES];
>>> 406
>>> 407 memset(max_zone_pfns, 0, sizeof(max_zone_pfns));
>>> 408
>>> 409 #ifdef CONFIG_ZONE_DMA
>>> 410 max_zone_pfns[ZONE_DMA] =3D MAX_DMA_PFN;
>>> 411 #endif
>>> 412 #ifdef CONFIG_ZONE_DMA32
>>> 413 max_zone_pfns[ZONE_DMA32] =3D MAX_DMA32_PFN;
>>> 414 #endif
>>> 415 max_zone_pfns[ZONE_NORMAL] =3D max_low_pfn;
>>> 416 #ifdef CONFIG_HIGHMEM
>>> 417 max_zone_pfns[ZONE_HIGHMEM] =3D max_pfn;
>>> 418 #endif
>>> 419
>>>=20
>>> For x86_64, there is no CONFIG_HIGHMEM, so there will be three =
zones:
>>> ZONE_DMA/ZONE_DMA32/ZONE_NORMAL.
>>>=20
>> [S.H] Hello, Ben,
>>=20
>> I have some questions, though I'm still expecting your comments.
>> PPC does not have ZONE_DMA32 by default, if we want to use it, we =
need to add "config ZONE_DMA32" in Kconfig first.
>> If setting multiple zones without ZONE_DMA, kmalloc in =
"include/linux/slab_def.h" will fail if it uses flag GFP_DMA.
>> For the runtime choice in 64-bit kernel, what exactly multiple zones =
should be used?
>> "ZONE_DMA & ZONE_NORMAL" or "ZONE_DMA & ZONE_DMA32 & ZONE_NORMAL"?
>> Then what the size should be set for them respectively?
>>=20
>> Please comment, Thanks!
>=20
> I think Ben is saying that Kconfig would enable ZONE_DMA32 for all =
PPC64, but make it runtime/per platform how we setup the zone's such =
that either ZONE_DMA32 is set to MAX_DMA32_PFN or it set to same value =
as ZONE_DMA.
>=20
> However that's just a guess.
Ben,
Can you help clarify your thoughts here.
thanks
- k=
^ permalink raw reply
* Re: Probing for native availability of isel from userspace
From: Benjamin Herrenschmidt @ 2012-09-24 9:41 UTC (permalink / raw)
To: Gabriel Paubert; +Cc: malc, linuxppc-dev, hollis
In-Reply-To: <20120924080633.GA8127@visitor2.iram.es>
On Mon, 2012-09-24 at 10:06 +0200, Gabriel Paubert wrote:
> > Which we do. mfpvr is available as a fallback (essentially because if we
> > don't do it somebody's going to parse /proc/cpuinfo which is arguably
> > worse :-)
>
> Fine. But I believe that mfpvr emulation came first, which is the point
> I object to (see the mess that the fact that CPUID is available to
> applications made to x86 when SSE registers were added).
Heh, possibly, I don't remember... I added the cputable, I think we
added mfpvr because we didn't have anything, then I added cputable which
got us the HW caps, but some old stuff still relied on mfpvr so we
couldn't completely remove it.
> Bottom line, the mappin between PVR and capabilities offered to
> applications should happen in one place, and this place is the kernel.
Yes, we all agree here.
> >
> > We should definitely advertise the availability of isel.
>
> Agreed.
If somebody has 5mn, patch welcome :-)
Cheers,
Ben.
^ permalink raw reply
* Re: Probing for native availability of isel from userspace
From: Gabriel Paubert @ 2012-09-24 8:06 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: malc, linuxppc-dev, hollis
In-Reply-To: <1348473517.1132.87.camel@pasglop>
On Mon, Sep 24, 2012 at 05:58:37PM +1000, Benjamin Herrenschmidt wrote:
> On Mon, 2012-09-24 at 09:55 +0200, Gabriel Paubert wrote:
> > On Sun, Sep 23, 2012 at 03:46:06AM +0200, Segher Boessenkool wrote:
> > > Why does the kernel emulate this, btw? I can see emulation is useful
> > > for running older binaries, for instructions that have been removed
> > > from the architecture; but for newly added instructions, or optional
> > > instructions, it hurts more than it helps?
> >
> > Indeed. I also don't understand why mfpvr is emulated. That's the kind
> > of information that should be passed to the executables through auxiliary
> > vectors. After all, you can (or could at least) compile a kernel without
> > Altivec support and run it on a processor with Altivec.
> >
> > Therefore, whether Altivec is supported or not, is a matter of
> > processor and kernel options. Provide this information through
> > the auxiliary vector and the problem is solved.
>
> Which we do. mfpvr is available as a fallback (essentially because if we
> don't do it somebody's going to parse /proc/cpuinfo which is arguably
> worse :-)
Fine. But I believe that mfpvr emulation came first, which is the point
I object to (see the mess that the fact that CPUID is available to
applications made to x86 when SSE registers were added).
Bottom line, the mappin between PVR and capabilities offered to
applications should happen in one place, and this place is the kernel.
>
> We should definitely advertise the availability of isel.
Agreed.
Cheers,
Gabriel
^ permalink raw reply
* Re: Probing for native availability of isel from userspace
From: Benjamin Herrenschmidt @ 2012-09-24 7:58 UTC (permalink / raw)
To: Gabriel Paubert; +Cc: malc, linuxppc-dev, hollis
In-Reply-To: <20120924075546.GA4263@visitor2.iram.es>
On Mon, 2012-09-24 at 09:55 +0200, Gabriel Paubert wrote:
> On Sun, Sep 23, 2012 at 03:46:06AM +0200, Segher Boessenkool wrote:
> > Why does the kernel emulate this, btw? I can see emulation is useful
> > for running older binaries, for instructions that have been removed
> > from the architecture; but for newly added instructions, or optional
> > instructions, it hurts more than it helps?
>
> Indeed. I also don't understand why mfpvr is emulated. That's the kind
> of information that should be passed to the executables through auxiliary
> vectors. After all, you can (or could at least) compile a kernel without
> Altivec support and run it on a processor with Altivec.
>
> Therefore, whether Altivec is supported or not, is a matter of
> processor and kernel options. Provide this information through
> the auxiliary vector and the problem is solved.
Which we do. mfpvr is available as a fallback (essentially because if we
don't do it somebody's going to parse /proc/cpuinfo which is arguably
worse :-)
We should definitely advertise the availability of isel.
Cheers,
Ben.
^ permalink raw reply
* Re: Probing for native availability of isel from userspace
From: Gabriel Paubert @ 2012-09-24 7:55 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: malc, linuxppc-dev, hollis
In-Reply-To: <35A5B006-1E4E-4355-A6A4-CA5F7371D21C@kernel.crashing.org>
On Sun, Sep 23, 2012 at 03:46:06AM +0200, Segher Boessenkool wrote:
> Why does the kernel emulate this, btw? I can see emulation is useful
> for running older binaries, for instructions that have been removed
> from the architecture; but for newly added instructions, or optional
> instructions, it hurts more than it helps?
Indeed. I also don't understand why mfpvr is emulated. That's the kind
of information that should be passed to the executables through auxiliary
vectors. After all, you can (or could at least) compile a kernel without
Altivec support and run it on a processor with Altivec.
Therefore, whether Altivec is supported or not, is a matter of
processor and kernel options. Provide this information through
the auxiliary vector and the problem is solved.
Gabriel
^ permalink raw reply
* Re: [RFC PATCH powerpc] Fix a lazy irq related WARING in arch_local_irq_restore()
From: Li Zhong @ 2012-09-24 6:42 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: Paul Mackerras, Paul E. McKenney, PowerPC email list
In-Reply-To: <1348464657.1132.86.camel@pasglop>
On Mon, 2012-09-24 at 15:30 +1000, Benjamin Herrenschmidt wrote:
> On Mon, 2012-09-24 at 11:56 +0800, Li Zhong wrote:
> > This patch tries to fix a WARNING in irq.c(below), when doing cpu offline/online.
> >
> > The reason is that if the preferred offline state is CPU_STATE_INACTIVE, when
> > cpu offline, pseries_mach_cpu_die() calls extended_cede_processor() to cede
> > the processor. After the hv call returns, the MSR_EE is enabled, while
> > the irq_happened in paca should already be set as PACA_IRQ_HARD_DIS.
> >
> > Then when the cpu is put online again, the warning is reported when
> > start_secondary() tries to enable irq. [ Sometimes, we don't see this warning,
> > that's because when we come to local_irq_enable(), there might already have been
> > some interrupts occurred, e.g. PACA_IRQ_DEC is already set. ]
> >
> > The patch tries to clear MSR_EE by calling __hard_irq_disable() after cede
> > returns, and before calling start_secondary_resume().
>
Hi Ben,
> Is that enough ? Do we know for sure we won't get a stray IPI or
> interrupt which then will reach us with an inconsistent HW/SW enable
> state ?
I thought when coming to here, there should be no IPI or interrupt for
this cpu ...
> We might need to "sanitize" the enable state in the PACA before we
> actually enter NAP or in the return from NAP code, like we do for normal
> idle code...
Do you mean something like this in extended_cede_processor() to make
sure HW/SW enable state consistent?
+ prep_irq_for_idle();
rc = cede_processor();
+#ifdef CONFIG_TRACE_IRQFLAGS
+ /* Ensure that H_CEDE returns with IRQs on */
+ if (WARN_ON(!(mfmsr() & MSR_EE)))
+ __hard_irq_enable();
+#endif
So, normally, we will have irqs SW/HW enabled consistently. But if the
above happens (some missing IPI/interrupt ), I'm not sure whether we can
leave it to be handled after cpu online again?
Please correct me if I misunderstood something.
Thanks, Zhong
> Cheers,
> Ben.
>
> > [ 56.618846] WARNING: at arch/powerpc/kernel/irq.c:240
> > [ 56.618851] Modules linked in: rcutorture ipv6 dm_mod ext3 jbd mbcache sg sd_mod crc_t10dif ibmvscsic scsi_transport_srp scsi_tgt ibmveth
> > [ 56.618883] NIP: c00000000000ff94 LR: c00000000067a5e0 CTR: 0000000000000001
> > [ 56.618889] REGS: c0000001fef6bbe0 TRAP: 0700 Not tainted (3.6.0-rc1-autokern1)
> > [ 56.618894] MSR: 8000000000029032 <SF,EE,ME,IR,DR,RI> CR: 42000082 XER: 20000000
> > [ 56.618913] SOFTE: 1
> > [ 56.618916] CFAR: c00000000067a5dc
> > [ 56.618920] TASK = c0000001feed79a0[0] 'swapper/5' THREAD: c0000001fef68000 CPU: 5
> > GPR00: 0000000000000001 c0000001fef6be60 c000000000f9ca08 0000000000000001
> > GPR04: 0000000000000001 0000000000000008 0000000000000001 0000000000000000
> > GPR08: 0000000000000000 c0000001feed79a0 0008a80000000000 0000000000000000
> > GPR12: 0000000022000082 c00000000f330f00 c0000001fef6bf90 000000000f394b4c
> > GPR16: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
> > GPR20: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
> > GPR24: c000000000fe8f80 0000000000000008 0000000000000028 0000000000000000
> > GPR28: 0000000000000000 0000000000000020 c000000000f1ab40 0000000000000001
> > [ 56.619014] NIP [c00000000000ff94] .arch_local_irq_restore+0x34/0xa0
> > [ 56.619020] LR [c00000000067a5e0] .start_secondary+0x368/0x37c
> > [ 56.619025] Call Trace:
> > [ 56.619030] [c0000001fef6be60] [c000000001ba0500] 0xc000000001ba0500 (unreliable)
> > [ 56.619038] [c0000001fef6bed0] [c00000000067a5e0] .start_secondary+0x368/0x37c
> > [ 56.619046] [c0000001fef6bf90] [c000000000009380] .start_secondary_resume+0x10/0x14
> > [ 56.619052] Instruction dump:
> > [ 56.619056] f8010010 f821ff91 986d022a 2fa30000 419e0054 880d022b 78000621 41820048
> > [ 56.619071] 2f800001 40de0064 7c0000a6 78008fe2 <0b000000> 2fa00000 40de0050 38000000
> > [ 56.619088] ---[ end trace 0199c0d783d7f9ba ]---
> >
> > Reported-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
> > Signed-off-by: Li Zhong <zhong@linux.vnet.ibm.com>
> > ---
> > arch/powerpc/platforms/pseries/hotplug-cpu.c | 2 ++
> > 1 files changed, 2 insertions(+), 0 deletions(-)
> >
> > diff --git a/arch/powerpc/platforms/pseries/hotplug-cpu.c b/arch/powerpc/platforms/pseries/hotplug-cpu.c
> > index 64c97d8..8de539a 100644
> > --- a/arch/powerpc/platforms/pseries/hotplug-cpu.c
> > +++ b/arch/powerpc/platforms/pseries/hotplug-cpu.c
> > @@ -137,6 +137,8 @@ static void pseries_mach_cpu_die(void)
> > if (get_preferred_offline_state(cpu) == CPU_STATE_ONLINE) {
> > unregister_slb_shadow(hwcpu);
> >
> > + __hard_irq_disable();
> > +
> > /*
> > * Call to start_secondary_resume() will not return.
> > * Kernel stack will be reset and start_secondary()
>
>
^ permalink raw reply
* [PATCH] Powerpc 8xx CPM_UART setting MAXIDL register proportionaly to baud rate
From: Christophe Leroy @ 2012-09-24 6:39 UTC (permalink / raw)
To: Alan Cox, Vitaly Bordug, Marcelo Tosatti
Cc: linuxppc-dev, linux-kernel, linux-serial
MAXIDL is the timeout after which a receive buffer is closed when not full if
no more characters are received. We calculate it from the baudrate so that the
duration is always the same at standard rates: about 4ms. At 9600 bauds it gives
a timeout of 4 characters, which is the timeout on the 8250 UART.
Signed-off-by: Christophe Leroy <christophe.leroy@c-s.fr>
--- linux-3.5-vanilla/drivers/tty/serial/cpm_uart/cpm_uart_core.c 2012-07-21 22:58:29.000000000 +0200
+++ linux-3.5/drivers/tty/serial/cpm_uart/cpm_uart_core.c 2012-08-09 17:38:37.000000000 +0200
@@ -501,6 +501,7 @@
struct uart_cpm_port *pinfo = (struct uart_cpm_port *)port;
smc_t __iomem *smcp = pinfo->smcp;
scc_t __iomem *sccp = pinfo->sccp;
+ int maxidl;
pr_debug("CPM uart[%d]:set_termios\n", port->line);
@@ -511,6 +512,17 @@
else
pinfo->rx_fifosize = RX_BUF_SIZE;
+ /* MAXIDL is the timeout after which a receive buffer is closed
+ * when not full if no more characters are received.
+ * We calculate it from the baudrate so that the duration is
+ * always the same at standard rates: about 4ms.
+ */
+ maxidl = baud / 2400;
+ if (maxidl < 1)
+ maxidl = 1;
+ if (maxidl > 0x10)
+ maxidl = 0x10;
+
/* Character length programmed into the mode register is the
* sum of: 1 start bit, number of data bits, 0 or 1 parity bit,
* 1 or 2 stop bits, minus 1.
@@ -611,6 +623,7 @@
* SMC/SCC receiver is disabled.
*/
out_be16(&pinfo->smcup->smc_mrblr, pinfo->rx_fifosize);
+ out_be16(&pinfo->smcup->smc_maxidl, maxidl);
/* Set the mode register. We want to keep a copy of the
* enables, because we want to put them back if they were
@@ -623,6 +636,7 @@
SMCMR_SM_UART | prev_mode);
} else {
out_be16(&pinfo->sccup->scc_genscc.scc_mrblr, pinfo->rx_fifosize);
+ out_be16(&pinfo->sccup->scc_maxidl, maxidl);
out_be16(&sccp->scc_psmr, (sbits << 12) | scval);
}
^ permalink raw reply
* [PATCH] Powerpc 8xx CPM_UART maxidl should not depend on fifo size
From: Christophe Leroy @ 2012-09-24 6:20 UTC (permalink / raw)
To: Alan Cox, Vitaly Bordug, Marcelo Tosatti
Cc: linuxppc-dev, linux-kernel, linux-serial
maxidl register was set to fifo size. There is no reason to set this
register to same value as fifo size. Setting it now to 0x10 by default
as in the UCC UART driver.
Signed-off-by: Christophe Leroy <christophe.leroy@c-s.fr>
--- linux-3.5-vanilla/drivers/tty/serial/cpm_uart/cpm_uart_core.c 2012-07-21 22:58:29.000000000 +0200
+++ linux-3.5/drivers/tty/serial/cpm_uart/cpm_uart_core.c 2012-08-09 17:38:37.000000000 +0200
@@ -799,7 +799,7 @@
cpm_set_scc_fcr(sup);
out_be16(&sup->scc_genscc.scc_mrblr, pinfo->rx_fifosize);
- out_be16(&sup->scc_maxidl, pinfo->rx_fifosize);
+ out_be16(&sup->scc_maxidl, 0x10);
out_be16(&sup->scc_brkcr, 1);
out_be16(&sup->scc_parec, 0);
out_be16(&sup->scc_frmec, 0);
@@ -873,7 +873,7 @@
/* Using idle character time requires some additional tuning. */
out_be16(&up->smc_mrblr, pinfo->rx_fifosize);
- out_be16(&up->smc_maxidl, pinfo->rx_fifosize);
+ out_be16(&up->smc_maxidl, 0x10);
out_be16(&up->smc_brklen, 0);
out_be16(&up->smc_brkec, 0);
out_be16(&up->smc_brkcr, 1);
^ permalink raw reply
* [PATCH] Powerpc 8xx CPM_UART too many interrupts
From: Christophe Leroy @ 2012-09-24 6:19 UTC (permalink / raw)
To: Alan Cox, Vitaly Bordug, Marcelo Tosatti
Cc: linuxppc-dev, linux-kernel, linux-serial
Setting the fifo to only 1 byte generates one interrupt every 1ms at 9600 bauds.
This is too much. This patch reduces the threshold to speeds below 2400 bauds
like in the 8250 UART driver.
Signed-off-by: Christophe Leroy <christophe.leroy@c-s.fr>
--- linux-3.5-vanilla/drivers/tty/serial/cpm_uart/cpm_uart_core.c 2012-07-21 22:58:29.000000000 +0200
+++ linux-3.5/drivers/tty/serial/cpm_uart/cpm_uart_core.c 2012-08-09 17:38:37.000000000 +0200
@@ -71,7 +71,7 @@
/**************************************************************/
-#define HW_BUF_SPD_THRESHOLD 9600
+#define HW_BUF_SPD_THRESHOLD 2400
/*
* Check, if transmit buffers are processed
@@ -505,7 +505,7 @@
pr_debug("CPM uart[%d]:set_termios\n", port->line);
baud = uart_get_baud_rate(port, termios, old, 0, port->uartclk / 16);
- if (baud <= HW_BUF_SPD_THRESHOLD ||
+ if (baud < HW_BUF_SPD_THRESHOLD ||
(pinfo->port.state && pinfo->port.state->port.tty->low_latency))
pinfo->rx_fifosize = 1;
else
^ permalink raw reply
* [PATCH v2] Powerpc 8xx CPM_UART desynchronisation
From: Christophe Leroy @ 2012-09-24 6:17 UTC (permalink / raw)
To: Alan Cox, Vitaly Bordug, Marcelo Tosatti
Cc: linuxppc-dev, linux-kernel, linux-serial
This patch fixes a desynchronisation problem with CPM UART driver on
Powerpc MPC8xx. The problem happens if data is received before the device
is open by the user application.
Signed-off-by: Christophe Leroy <christophe.leroy@c-s.fr>
--- linux-3.5-vanilla/drivers/tty/serial/cpm_uart/cpm_uart_core.c 2012-07-21 22:58:29.000000000 +0200
+++ linux-3.5/drivers/tty/serial/cpm_uart/cpm_uart_core.c 2012-08-09 17:38:37.000000000 +0200
@@ -417,6 +417,7 @@
clrbits32(&pinfo->sccp->scc_gsmrl, SCC_GSMRL_ENR);
clrbits16(&pinfo->sccp->scc_sccm, UART_SCCM_RX);
}
+ cpm_uart_initbd(pinfo);
cpm_line_cr_cmd(pinfo, CPM_CR_INIT_TRX);
}
/* Install interrupt handler. */
^ permalink raw reply
* [PATCH][v2] powerpc/fsl-pci: use 'Header Type' to identify PCIE mode
From: Minghuan Lian @ 2012-09-24 5:50 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Minghuan Lian
The original code uses 'Programming Interface' field to judge if PCIE is
EP or RC mode, however, some latest silicons do not support this functionality.
According to PCIE specification, 'Header Type' offset 0x0e is used to
indicate header type, so change code to use 'Header Type' field to
judge PCIE mode. Because FSL PCI controller does not support 'Header Type',
patch still uses 'Programming Interface' to identify PCI mode.
Signed-off-by: Minghuan Lian <Minghuan.Lian@freescale.com>
Signed-off-by: Roy Zang <tie-fei.zang@freescale.com>
---
Change log:
v2 -
keep the original PCI initialization order according to kumar's recommendations.
arch/powerpc/sysdev/fsl_pci.c | 37 ++++++++++++++++++++++++-------------
1 file changed, 24 insertions(+), 13 deletions(-)
diff --git a/arch/powerpc/sysdev/fsl_pci.c b/arch/powerpc/sysdev/fsl_pci.c
index c37f461..468e76c 100644
--- a/arch/powerpc/sysdev/fsl_pci.c
+++ b/arch/powerpc/sysdev/fsl_pci.c
@@ -38,15 +38,15 @@ static int fsl_pcie_bus_fixup, is_mpc83xx_pci;
static void __devinit quirk_fsl_pcie_header(struct pci_dev *dev)
{
- u8 progif;
+ u8 hdr_type;
/* if we aren't a PCIe don't bother */
if (!pci_find_capability(dev, PCI_CAP_ID_EXP))
return;
/* if we aren't in host mode don't bother */
- pci_read_config_byte(dev, PCI_CLASS_PROG, &progif);
- if (progif & 0x1)
+ pci_read_config_byte(dev, PCI_HEADER_TYPE, &hdr_type);
+ if ((hdr_type & 0x7f) != PCI_HEADER_TYPE_BRIDGE)
return;
dev->class = PCI_CLASS_BRIDGE_PCI << 8;
@@ -425,7 +425,7 @@ int __init fsl_add_bridge(struct device_node *dev, int is_primary)
struct pci_controller *hose;
struct resource rsrc;
const int *bus_range;
- u8 progif;
+ u8 hdr_type, progif;
if (!of_device_is_available(dev)) {
pr_warning("%s: disabled\n", dev->full_name);
@@ -457,15 +457,17 @@ int __init fsl_add_bridge(struct device_node *dev, int is_primary)
setup_indirect_pci(hose, rsrc.start, rsrc.start + 0x4,
PPC_INDIRECT_TYPE_BIG_ENDIAN);
- early_read_config_byte(hose, 0, 0, PCI_CLASS_PROG, &progif);
- if ((progif & 1) == 1) {
- /* unmap cfg_data & cfg_addr separately if not on same page */
- if (((unsigned long)hose->cfg_data & PAGE_MASK) !=
- ((unsigned long)hose->cfg_addr & PAGE_MASK))
- iounmap(hose->cfg_data);
- iounmap(hose->cfg_addr);
- pcibios_free_controller(hose);
- return -ENODEV;
+ if (early_find_capability(hose, 0, 0, PCI_CAP_ID_EXP)) {
+ /* For PCIE read HEADER_TYPE to identify controler mode */
+ early_read_config_byte(hose, 0, 0, PCI_HEADER_TYPE, &hdr_type);
+ if ((hdr_type & 0x7f) != PCI_HEADER_TYPE_BRIDGE)
+ goto no_bridge;
+
+ } else {
+ /* For PCI read PROG to identify controller mode */
+ early_read_config_byte(hose, 0, 0, PCI_CLASS_PROG, &progif);
+ if ((progif & 1) == 1)
+ goto no_bridge;
}
setup_pci_cmd(hose);
@@ -494,6 +496,15 @@ int __init fsl_add_bridge(struct device_node *dev, int is_primary)
setup_pci_atmu(hose, &rsrc);
return 0;
+
+no_bridge:
+ /* unmap cfg_data & cfg_addr separately if not on same page */
+ if (((unsigned long)hose->cfg_data & PAGE_MASK) !=
+ ((unsigned long)hose->cfg_addr & PAGE_MASK))
+ iounmap(hose->cfg_data);
+ iounmap(hose->cfg_addr);
+ pcibios_free_controller(hose);
+ return -ENODEV;
}
#endif /* CONFIG_FSL_SOC_BOOKE || CONFIG_PPC_86xx */
--
1.7.9.5
^ permalink raw reply related
* Re: [RFC PATCH powerpc] Fix a lazy irq related WARING in arch_local_irq_restore()
From: Benjamin Herrenschmidt @ 2012-09-24 5:30 UTC (permalink / raw)
To: Li Zhong; +Cc: Paul Mackerras, Paul E. McKenney, PowerPC email list
In-Reply-To: <1348458962.2475.8.camel@ThinkPad-T420>
On Mon, 2012-09-24 at 11:56 +0800, Li Zhong wrote:
> This patch tries to fix a WARNING in irq.c(below), when doing cpu offline/online.
>
> The reason is that if the preferred offline state is CPU_STATE_INACTIVE, when
> cpu offline, pseries_mach_cpu_die() calls extended_cede_processor() to cede
> the processor. After the hv call returns, the MSR_EE is enabled, while
> the irq_happened in paca should already be set as PACA_IRQ_HARD_DIS.
>
> Then when the cpu is put online again, the warning is reported when
> start_secondary() tries to enable irq. [ Sometimes, we don't see this warning,
> that's because when we come to local_irq_enable(), there might already have been
> some interrupts occurred, e.g. PACA_IRQ_DEC is already set. ]
>
> The patch tries to clear MSR_EE by calling __hard_irq_disable() after cede
> returns, and before calling start_secondary_resume().
Is that enough ? Do we know for sure we won't get a stray IPI or
interrupt which then will reach us with an inconsistent HW/SW enable
state ?
We might need to "sanitize" the enable state in the PACA before we
actually enter NAP or in the return from NAP code, like we do for normal
idle code...
Cheers,
Ben.
> [ 56.618846] WARNING: at arch/powerpc/kernel/irq.c:240
> [ 56.618851] Modules linked in: rcutorture ipv6 dm_mod ext3 jbd mbcache sg sd_mod crc_t10dif ibmvscsic scsi_transport_srp scsi_tgt ibmveth
> [ 56.618883] NIP: c00000000000ff94 LR: c00000000067a5e0 CTR: 0000000000000001
> [ 56.618889] REGS: c0000001fef6bbe0 TRAP: 0700 Not tainted (3.6.0-rc1-autokern1)
> [ 56.618894] MSR: 8000000000029032 <SF,EE,ME,IR,DR,RI> CR: 42000082 XER: 20000000
> [ 56.618913] SOFTE: 1
> [ 56.618916] CFAR: c00000000067a5dc
> [ 56.618920] TASK = c0000001feed79a0[0] 'swapper/5' THREAD: c0000001fef68000 CPU: 5
> GPR00: 0000000000000001 c0000001fef6be60 c000000000f9ca08 0000000000000001
> GPR04: 0000000000000001 0000000000000008 0000000000000001 0000000000000000
> GPR08: 0000000000000000 c0000001feed79a0 0008a80000000000 0000000000000000
> GPR12: 0000000022000082 c00000000f330f00 c0000001fef6bf90 000000000f394b4c
> GPR16: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
> GPR20: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
> GPR24: c000000000fe8f80 0000000000000008 0000000000000028 0000000000000000
> GPR28: 0000000000000000 0000000000000020 c000000000f1ab40 0000000000000001
> [ 56.619014] NIP [c00000000000ff94] .arch_local_irq_restore+0x34/0xa0
> [ 56.619020] LR [c00000000067a5e0] .start_secondary+0x368/0x37c
> [ 56.619025] Call Trace:
> [ 56.619030] [c0000001fef6be60] [c000000001ba0500] 0xc000000001ba0500 (unreliable)
> [ 56.619038] [c0000001fef6bed0] [c00000000067a5e0] .start_secondary+0x368/0x37c
> [ 56.619046] [c0000001fef6bf90] [c000000000009380] .start_secondary_resume+0x10/0x14
> [ 56.619052] Instruction dump:
> [ 56.619056] f8010010 f821ff91 986d022a 2fa30000 419e0054 880d022b 78000621 41820048
> [ 56.619071] 2f800001 40de0064 7c0000a6 78008fe2 <0b000000> 2fa00000 40de0050 38000000
> [ 56.619088] ---[ end trace 0199c0d783d7f9ba ]---
>
> Reported-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
> Signed-off-by: Li Zhong <zhong@linux.vnet.ibm.com>
> ---
> arch/powerpc/platforms/pseries/hotplug-cpu.c | 2 ++
> 1 files changed, 2 insertions(+), 0 deletions(-)
>
> diff --git a/arch/powerpc/platforms/pseries/hotplug-cpu.c b/arch/powerpc/platforms/pseries/hotplug-cpu.c
> index 64c97d8..8de539a 100644
> --- a/arch/powerpc/platforms/pseries/hotplug-cpu.c
> +++ b/arch/powerpc/platforms/pseries/hotplug-cpu.c
> @@ -137,6 +137,8 @@ static void pseries_mach_cpu_die(void)
> if (get_preferred_offline_state(cpu) == CPU_STATE_ONLINE) {
> unregister_slb_shadow(hwcpu);
>
> + __hard_irq_disable();
> +
> /*
> * Call to start_secondary_resume() will not return.
> * Kernel stack will be reset and start_secondary()
^ permalink raw reply
* [RFC PATCH powerpc] Fix a lazy irq related WARING in arch_local_irq_restore()
From: Li Zhong @ 2012-09-24 3:56 UTC (permalink / raw)
To: PowerPC email list; +Cc: Paul E. McKenney, Paul Mackerras
This patch tries to fix a WARNING in irq.c(below), when doing cpu offline/online.
The reason is that if the preferred offline state is CPU_STATE_INACTIVE, when
cpu offline, pseries_mach_cpu_die() calls extended_cede_processor() to cede
the processor. After the hv call returns, the MSR_EE is enabled, while
the irq_happened in paca should already be set as PACA_IRQ_HARD_DIS.
Then when the cpu is put online again, the warning is reported when
start_secondary() tries to enable irq. [ Sometimes, we don't see this warning,
that's because when we come to local_irq_enable(), there might already have been
some interrupts occurred, e.g. PACA_IRQ_DEC is already set. ]
The patch tries to clear MSR_EE by calling __hard_irq_disable() after cede
returns, and before calling start_secondary_resume().
[ 56.618846] WARNING: at arch/powerpc/kernel/irq.c:240
[ 56.618851] Modules linked in: rcutorture ipv6 dm_mod ext3 jbd mbcache sg sd_mod crc_t10dif ibmvscsic scsi_transport_srp scsi_tgt ibmveth
[ 56.618883] NIP: c00000000000ff94 LR: c00000000067a5e0 CTR: 0000000000000001
[ 56.618889] REGS: c0000001fef6bbe0 TRAP: 0700 Not tainted (3.6.0-rc1-autokern1)
[ 56.618894] MSR: 8000000000029032 <SF,EE,ME,IR,DR,RI> CR: 42000082 XER: 20000000
[ 56.618913] SOFTE: 1
[ 56.618916] CFAR: c00000000067a5dc
[ 56.618920] TASK = c0000001feed79a0[0] 'swapper/5' THREAD: c0000001fef68000 CPU: 5
GPR00: 0000000000000001 c0000001fef6be60 c000000000f9ca08 0000000000000001
GPR04: 0000000000000001 0000000000000008 0000000000000001 0000000000000000
GPR08: 0000000000000000 c0000001feed79a0 0008a80000000000 0000000000000000
GPR12: 0000000022000082 c00000000f330f00 c0000001fef6bf90 000000000f394b4c
GPR16: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
GPR20: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
GPR24: c000000000fe8f80 0000000000000008 0000000000000028 0000000000000000
GPR28: 0000000000000000 0000000000000020 c000000000f1ab40 0000000000000001
[ 56.619014] NIP [c00000000000ff94] .arch_local_irq_restore+0x34/0xa0
[ 56.619020] LR [c00000000067a5e0] .start_secondary+0x368/0x37c
[ 56.619025] Call Trace:
[ 56.619030] [c0000001fef6be60] [c000000001ba0500] 0xc000000001ba0500 (unreliable)
[ 56.619038] [c0000001fef6bed0] [c00000000067a5e0] .start_secondary+0x368/0x37c
[ 56.619046] [c0000001fef6bf90] [c000000000009380] .start_secondary_resume+0x10/0x14
[ 56.619052] Instruction dump:
[ 56.619056] f8010010 f821ff91 986d022a 2fa30000 419e0054 880d022b 78000621 41820048
[ 56.619071] 2f800001 40de0064 7c0000a6 78008fe2 <0b000000> 2fa00000 40de0050 38000000
[ 56.619088] ---[ end trace 0199c0d783d7f9ba ]---
Reported-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
Signed-off-by: Li Zhong <zhong@linux.vnet.ibm.com>
---
arch/powerpc/platforms/pseries/hotplug-cpu.c | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/platforms/pseries/hotplug-cpu.c b/arch/powerpc/platforms/pseries/hotplug-cpu.c
index 64c97d8..8de539a 100644
--- a/arch/powerpc/platforms/pseries/hotplug-cpu.c
+++ b/arch/powerpc/platforms/pseries/hotplug-cpu.c
@@ -137,6 +137,8 @@ static void pseries_mach_cpu_die(void)
if (get_preferred_offline_state(cpu) == CPU_STATE_ONLINE) {
unregister_slb_shadow(hwcpu);
+ __hard_irq_disable();
+
/*
* Call to start_secondary_resume() will not return.
* Kernel stack will be reset and start_secondary()
--
1.7.1
^ permalink raw reply related
* Re: [PATCH v3 1/2] mmc: Move mmc_delay() to include/linux/mmc/core.h
From: Chunhe Lan @ 2012-09-24 15:20 UTC (permalink / raw)
To: Arnd Bergmann; +Cc: kumar.gala, linux-mmc, cjb, linuxppc-dev, Chunhe Lan
In-Reply-To: <201209211233.54545.arnd@arndb.de>
On 09/21/2012 08:33 AM, Arnd Bergmann wrote:
> On Friday 21 September 2012, Chunhe Lan wrote:
>> On 08/10/2012 09:27 AM, Arnd Bergmann wrote:
>>> On Friday 10 August 2012, Chunhe Lan wrote:
>>>
>>> cond_resched();
>>> mdelay(ms);
>>>
>>> sets off alarm bells, and I would always replace that with msleep().
>> I think that it does not replace with msleep().
>> When the time of sleep is very short, program should not been scheduled
>> in the context. Because it expends the more time.
>>
> A time measured in miliseconds is never "very short" for the scheduler,
> a lot of things can happen during that time span. The code I quoted
> also does not care too much about accuracy, otherwise it would adapt
> the time in the mdelay based on whether the cond_resched() actually
> schedules to another thread.
OK. As you have mentioned, it would been modified to such:
static inline void mmc_delay(unsigned int ms)
{
if (ms < 1000 / HZ) {
cond_resched();
msleep(ms);
} else {
msleep(ms);
}
}
OR such:
static inline void mmc_delay(unsigned int ms)
{
msleep(ms);
}
OR other code?
Thanks,
Chunhe
>
> Arnd
>
^ permalink raw reply
* RE: [PATCH][V4] powerpc/fsl-pci: Add pci inbound/outbound PM support
From: Jia Hongtao-B38951 @ 2012-09-24 2:47 UTC (permalink / raw)
To: Kumar Gala
Cc: Wood Scott-B07421, linuxppc-dev@lists.ozlabs.org, Li Yang-R58472
In-Reply-To: <95B12FA1-EC53-4632-8DFB-64109668BA9C@kernel.crashing.org>
[-- Attachment #1: Type: text/plain, Size: 4972 bytes --]
> -----Original Message-----
> From: Kumar Gala [mailto:galak@kernel.crashing.org]
> Sent: Friday, September 21, 2012 9:16 PM
> To: Jia Hongtao-B38951
> Cc: Li Yang-R58472; linuxppc-dev@lists.ozlabs.org; Wood Scott-B07421
> Subject: Re: [PATCH][V4] powerpc/fsl-pci: Add pci inbound/outbound PM
> support
>
> >>>>>>>
> >>>>>>> On Sep 17, 2012, at 9:10 PM, Jia Hongtao wrote:
> >>>>>>>
> >>>>>>>> Power supply for PCI inbound/outbound window registers is off
> >>>>>>>> when system go to deep-sleep state. We save the values of
> >>>>>>>> registers
> >>>> before
> >>>>>>>> suspend and restore to registers after resume.
> >>>>>>>>
> >>>>>>>> Signed-off-by: Jiang Yutang <b14898@freescale.com>
> >>>>>>>> Signed-off-by: Jia Hongtao <B38951@freescale.com>
> >>>>>>>> Signed-off-by: Li Yang <leoli@freescale.com>
> >>>>>>>> ---
> >>>>>>>> Changes for V4:
> >>>>>>>> We just rebase the patch upon following patch:
> >>>>>>>> powerpc/fsl-pci: Unify pci/pcie initialization code
> >>>>>>>>
> >>>>>>>> arch/powerpc/include/asm/pci-bridge.h | 2 +-
> >>>>>>>> arch/powerpc/sysdev/fsl_pci.c | 121
> >>>>>>> +++++++++++++++++++++++++++++++++
> >>>>>>>> 2 files changed, 122 insertions(+), 1 deletions(-)
> >>>>>>>
> >>>>>>> Did you ever compare this to just re-parsing device tree method?
> >>>>>>>
> >>>>>>> - k
> >>>>>>
> >>>>>> I tested the re-parsing way by using setup_pci_atmu() when resume.
> >>>>>> And I found out that re-parsing will *change* outbound IO
> >>>>>> translation address regitster.
> >>>>>>
> >>>>>> It seems that in the first bootup, after setup_atmu()
> >>>>>> pcibios_setup_phb_resources() may update hose->io_resource, but
> >>>>>> atmu is not updated according to the new hose->io_resource value.
> >>>>>> In resume from sleep setup_atmu() will reset atmu according to
> >>>>>> the new hose->io_resource value. So the setup_atmu() will cause
> >>>>>> different result on outbound IO register between first bootup and
> >>>>>> resume from sleep.
> >>>>>>
> >>>>>> So... There's a possibility that in the first bootup atmu is not
> >>>>>> setup properly.
> >>>>>
> >>>>> [Are you seeing this happen in your testing? If so its a bug we
> >>>>> need
> >>>> to look at fixing.]
> >>>>>
> >>>>> Yes, I see this in my testing.
> >>>>> Also PCIe ethernet card works well after resuming from sleep in
> >>>>> both
> >>>> save/restore
> >>>>> and re-parsing way. (Maybe PCIe ethernet card don't need outbound
> >>>>> IO
> >>>> resource)
> >>>>> So, I guess the result of re-parsing (actually it's re-setup) is
> >>>>> right
> >>>> and ATMU is not setup
> >>>>> properly at the first bootup.
> >>>>
> >>>> Are you seeing the following message - "PCI: I/O resource not set
> >>>> for host bridge" ?
> >>>
> >>> No.
> >>>
> >>>>
> >>>> Trying to understand why you'd hit the reassignment of io_resource.
> >>>>
> >>>> - k
> >>>>
> >>>
> >>> I did some investigations and the conclusion is:
> >>>
> >>> io_resource.flags & IORESOURCE_IO are both positive but
> >>> io_resource.start is 0 before pcibios_setup_phb_io_space() is done.
> >>>
> >>> The sequence of related process listed below:
> >>> fsl_add_bridge() -> setup_pci_atmu()
> >>> pcibios_init() -> pcibios_scan_phb() -> pcibios_setup_phb_io_space()
> >>>
> >>> Because fsl_add_bridge() must be finished before pcibios_init() so
> >>> ATMU is set when io_resource.start is 0. That means outbound IO regs
> >>> are not set.
> >>>
> >>> If system re-setup ATMU the io_resource.start has already updated so
> >>> outbound IO regs are set.
> >>>
> >>> My question is:
> >>> Is there any problem if outbound IO regs are not set in first bootup?
>
> Yes, it means that IO transactions would not work.
I agree.
>
> >> Please also provide the IO resource address range before and after the
> >> pci scan. Then we can evaluate if the range is needed to be mapped
> via
> >> ATMU.
> >>
> >> Leo
> >
> > Since potar is set by out_be32(&pci->pow[j].potar, (hose-
> >io_resource.start >> 12);
> > I provide the result of hose->io_resource.start >> 12 as follows:
> >
> > pcie@ffe09000:
> > before pci scan: io_resource.start >> 12: 0
> > after pci scan : io_resource.start >> 12: ff7ed
> >
> > pcie@ffe0a000:
> > before pci scan: io_resource.start >> 12: 0
> > after pci scan : io_resource.start >> 12: ff7db
> >
> > pcie@ffe0b000:
> > before pci scan: io_resource.start >> 12: 0
> > after pci scan : io_resource.start >> 12: ff7c9
> >
> > Note that I tested on P1022DS.
> >
> > - Hongtao.
>
> 1. What's the device tree nodes for PCIe look like?
> 2. Can you get the pr_debug() in setup_pci_atmu() to print and report
> results (as well as full boot log)
Please refer to the attached file.
In the log file I also print the device tree.
- Hongtao.
>
> However, I think the change of the io_resource.start is normal and
> correct behavior.
>
> - k
>
[-- Attachment #2: pci_pm_setup_pci_atmu_debug.log --]
[-- Type: application/octet-stream, Size: 55671 bytes --]
U-Boot 2009.11-00132-gd404dfa (Sep 26 2010 - 14:57:28)
CPU0: P1022E, Version: 1.0, (0x80ee0010)
Core: E500, Version: 5.0, (0x80211050)
Clock Configuration:
CPU0:1199.988 MHz, CPU1:1199.988 MHz,
CCB:599.994 MHz,
DDR:399.996 MHz (799.992 MT/s data rate) (Asynchronous), LBC:37.500 MHz
L1: D-cache 32 kB enabled
I-cache 32 kB enabled
Board: P1022DS Sys ID: 0x19, Sys Ver: 0x03, FPGA Ver: 0x09, vBank: 0
I2C: ready
SPI: ready
DRAM: Initializing.... DDR: 2 GB (DDR3, 64-bit, CL=6, ECC off)
Now running in RAM - U-Boot at: 7ff30000
FLASH: 128 MB
L2: 256 KB enabled
NAND: 1024 MiB
MMC: FSL_ESDHC: 0
EEPROM: NXID v0
PCIE1 connected to Slot 1 as Root Complex (base addr ffe0a000)
PCIE1 on bus 00 - 00
PCIE2 connected to Slot 3 as Root Complex (base addr ffe09000)
PCIE2 on bus 01 - 01
PCIE3 connected to Slot 2 as Root Complex (base addr ffe0b000)
PCIE3 on bus 02 - 02
In: serial
Out: serial
Err: serial
Net: eTSEC1, eTSEC2
Hit any key to stop autoboot: 0
=> setenv fdtprint "tftp $fdtaddr $fdtfile;fdt addr $fdtaddr;fdt boardsetup;fdt print"
=> sav
Saving Environment to Flash...
Un-Protected 1 sectors
Erasing Flash...
. done
Erased 1 sectors
Writing to Flash... 9....8....7....6....5....4....3....2....1....done
Protected 1 sectors
=> run fdtprint
Speed: 1000, full duplex
Using eTSEC1 device
TFTP from server 10.193.20.106; our IP address is 10.193.20.176
Filename 'jiaht/p1022ds_32b.dtb'.
Load address: 0xc00000
Loading: ###
done
Bytes transferred = 14645 (3935 hex)
/ {
compatible = "fsl,P1022DS";
#address-cells = <0x2>;
#size-cells = <0x2>;
interrupt-parent = <0x1>;
model = "fsl,P1022DS";
cpus {
power-isa-version = "2.03";
power-isa-b;
power-isa-e;
power-isa-atb;
power-isa-cs;
power-isa-e.le;
power-isa-e.pm;
power-isa-ecl;
power-isa-mmc;
power-isa-sp;
power-isa-sp.fd;
power-isa-sp.fs;
power-isa-sp.fv;
mmu-type = "power-embedded";
#address-cells = <0x1>;
#size-cells = <0x0>;
PowerPC,P1022@0 {
i-cache-sets = <0x80>;
i-cache-size = <0x8000>;
i-cache-block-size = <0x20>;
d-cache-sets = <0x80>;
d-cache-size = <0x8000>;
d-cache-block-size = <0x20>;
status = "okay";
clock-frequency = <0x47865d2c>;
bus-frequency = <0x23c32e96>;
timebase-frequency = <0x47865d3>;
device_type = "cpu";
reg = <0x0>;
next-level-cache = <0x2>;
};
PowerPC,P1022@1 {
i-cache-sets = <0x80>;
i-cache-size = <0x8000>;
i-cache-block-size = <0x20>;
d-cache-sets = <0x80>;
d-cache-size = <0x8000>;
d-cache-block-size = <0x20>;
cpu-release-addr = <0x0 0x7ffff2a0>;
enable-method = "spin-table";
status = "disabled";
clock-frequency = <0x47865d2c>;
bus-frequency = <0x23c32e96>;
timebase-frequency = <0x47865d3>;
device_type = "cpu";
reg = <0x1>;
next-level-cache = <0x2>;
};
};
aliases {
serial0 = "/soc@ffe00000/serial@4500";
serial1 = "/soc@ffe00000/serial@4600";
ethernet0 = "/soc@ffe00000/ethernet@b0000";
ethernet1 = "/soc@ffe00000/ethernet@b1000";
pci0 = "/pcie@ffe09000";
pci1 = "/pcie@ffe0a000";
pci2 = "/pcie@ffe0b000";
};
memory {
reg = <0x0 0x0 0x0 0x80000000>;
device_type = "memory";
};
localbus@ffe05000 {
bus-frequency = <0x23c32e9>;
reg = <0x0 0xffe05000 0x0 0x1000>;
ranges = <0x0 0x0 0x0 0xe8000000 0x8000000 0x1 0x0 0x0 0xe0000000 0x8000000 0x2 0x0 0x0 0xff800000 0x40000 0x3 0x0 0x0 0xffdf0000 0x8000>;
#address-cells = <0x2>;
#size-cells = <0x1>;
compatible = "fsl,p1022-elbc", "fsl,elbc";
interrupts = <0x13 0x2 0x0 0x0>;
board-control@0,0 {
compatible = "fsl,p1022ds-indirect-pixis";
reg = <0x0 0x0 0x1 0x1 0x0 0x1>;
interrupt-parent = <0x1>;
interrupts = <0x8 0x0 0x0 0x0>;
};
nor@0,0 {
#address-cells = <0x1>;
#size-cells = <0x1>;
compatible = "cfi-flash";
reg = <0x0 0x0 0x8000000>;
bank-width = <0x2>;
device-width = <0x1>;
partition@0 {
reg = <0x0 0x3000000>;
label = "ramdisk-nor";
read-only;
};
partition@3000000 {
reg = <0x3000000 0xe00000>;
label = "diagnostic-nor";
read-only;
};
partition@3e00000 {
reg = <0x3e00000 0x200000>;
label = "dink-nor";
read-only;
};
partition@4000000 {
reg = <0x4000000 0x400000>;
label = "kernel-nor";
read-only;
};
partition@4400000 {
reg = <0x4400000 0x3b00000>;
label = "jffs2-nor";
};
partition@7f00000 {
reg = <0x7f00000 0x80000>;
label = "dtb-nor";
read-only;
};
partition@7f80000 {
reg = <0x7f80000 0x80000>;
label = "u-boot-nor";
read-only;
};
};
nand@2,0 {
#address-cells = <0x1>;
#size-cells = <0x1>;
compatible = "fsl,elbc-fcm-nand";
reg = <0x2 0x0 0x40000>;
partition@0 {
reg = <0x0 0x2000000>;
label = "u-boot-nand";
read-only;
};
partition@2000000 {
reg = <0x2000000 0x10000000>;
label = "jffs2-nand";
};
partition@12000000 {
reg = <0x12000000 0x10000000>;
label = "ramdisk-nand";
read-only;
};
partition@22000000 {
reg = <0x22000000 0x4000000>;
label = "kernel-nand";
};
partition@26000000 {
reg = <0x26000000 0x1000000>;
label = "dtb-nand";
read-only;
};
partition@27000000 {
reg = <0x27000000 0x19000000>;
label = "reserved-nand";
};
};
board-control@3,0 {
compatible = "fsl,p1022ds-fpga", "fsl,fpga-ngpixis";
reg = <0x3 0x0 0x30>;
interrupt-parent = <0x1>;
interrupts = <0x8 0x0 0x0 0x0>;
};
};
soc@ffe00000 {
ranges = <0x0 0x0 0xffe00000 0x100000>;
#address-cells = <0x1>;
#size-cells = <0x1>;
device_type = "soc";
compatible = "fsl,p1022-immr", "simple-bus";
bus-frequency = <0x23c32e96>;
ecm-law@0 {
compatible = "fsl,ecm-law";
reg = <0x0 0x1000>;
fsl,num-laws = <0xc>;
};
ecm@1000 {
compatible = "fsl,p1022-ecm", "fsl,ecm";
reg = <0x1000 0x1000>;
interrupts = <0x10 0x2 0x0 0x0>;
};
memory-controller@2000 {
compatible = "fsl,p1022-memory-controller";
reg = <0x2000 0x1000>;
interrupts = <0x10 0x2 0x0 0x0>;
};
i2c@3000 {
#address-cells = <0x1>;
#size-cells = <0x0>;
cell-index = <0x0>;
compatible = "fsl-i2c";
reg = <0x3000 0x100>;
interrupts = <0x2b 0x2 0x0 0x0>;
dfsrr;
};
i2c@3100 {
#address-cells = <0x1>;
#size-cells = <0x0>;
cell-index = <0x1>;
compatible = "fsl-i2c";
reg = <0x3100 0x100>;
interrupts = <0x2b 0x2 0x0 0x0>;
dfsrr;
codec@1a {
compatible = "wlf,wm8776";
reg = <0x1a>;
linux,phandle = <0x5>;
phandle = <0x5>;
};
rtc@68 {
compatible = "dallas,ds1339";
reg = <0x68>;
};
adt7461@4c {
compatible = "adi,adt7461";
reg = <0x4c>;
};
};
serial@4500 {
cell-index = <0x0>;
device_type = "serial";
compatible = "fsl,ns16550", "ns16550";
reg = <0x4500 0x100>;
clock-frequency = <0x23c32e96>;
interrupts = <0x2a 0x2 0x0 0x0>;
};
serial@4600 {
cell-index = <0x1>;
device_type = "serial";
compatible = "fsl,ns16550", "ns16550";
reg = <0x4600 0x100>;
clock-frequency = <0x23c32e96>;
interrupts = <0x2a 0x2 0x0 0x0>;
};
spi@7000 {
#address-cells = <0x1>;
#size-cells = <0x0>;
compatible = "fsl,mpc8536-espi";
reg = <0x7000 0x1000>;
interrupts = <0x3b 0x2 0x0 0x0>;
fsl,espi-num-chipselects = <0x4>;
flash@0 {
#address-cells = <0x1>;
#size-cells = <0x1>;
compatible = "spansion,s25sl12801";
reg = <0x0>;
spi-max-frequency = <0x2625a00>;
partition@0 {
label = "u-boot-spi";
reg = <0x0 0x100000>;
read-only;
};
partition@100000 {
label = "kernel-spi";
reg = <0x100000 0x500000>;
read-only;
};
partition@600000 {
label = "dtb-spi";
reg = <0x600000 0x100000>;
read-only;
};
partition@700000 {
label = "file system-spi";
reg = <0x700000 0x900000>;
};
};
slic@0 {
compatible = "zarlink,le88266";
reg = <0x1>;
spi-max-frequency = <0x7a1200>;
};
slic@1 {
compatible = "zarlink,le88266";
reg = <0x2>;
spi-max-frequency = <0x7a1200>;
};
};
dma@c300 {
#address-cells = <0x1>;
#size-cells = <0x1>;
compatible = "fsl,eloplus-dma";
reg = <0xc300 0x4>;
ranges = <0x0 0xc100 0x200>;
cell-index = <0x1>;
dma-channel@0 {
compatible = "fsl,ssi-dma-channel";
reg = <0x0 0x80>;
cell-index = <0x0>;
interrupts = <0x4c 0x2 0x0 0x0>;
linux,phandle = <0x3>;
phandle = <0x3>;
};
dma-channel@80 {
compatible = "fsl,ssi-dma-channel";
reg = <0x80 0x80>;
cell-index = <0x1>;
interrupts = <0x4d 0x2 0x0 0x0>;
linux,phandle = <0x4>;
phandle = <0x4>;
};
dma-channel@100 {
compatible = "fsl,eloplus-dma-channel";
reg = <0x100 0x80>;
cell-index = <0x2>;
interrupts = <0x4e 0x2 0x0 0x0>;
};
dma-channel@180 {
compatible = "fsl,eloplus-dma-channel";
reg = <0x180 0x80>;
cell-index = <0x3>;
interrupts = <0x4f 0x2 0x0 0x0>;
};
};
gpio-controller@f000 {
#gpio-cells = <0x2>;
compatible = "fsl,pq3-gpio";
reg = <0xf000 0x100>;
interrupts = <0x2f 0x2 0x0 0x0>;
gpio-controller;
};
display@10000 {
compatible = "fsl,diu", "fsl,p1022-diu";
reg = <0x10000 0x3e8>;
interrupts = <0x40 0x2 0x0 0x0>;
};
ssi@15000 {
compatible = "fsl,mpc8610-ssi";
cell-index = <0x0>;
reg = <0x15000 0x100>;
interrupts = <0x4b 0x2 0x0 0x0>;
fsl,playback-dma = <0x3>;
fsl,capture-dma = <0x4>;
fsl,fifo-depth = <0xf>;
fsl,mode = "i2s-slave";
codec-handle = <0x5>;
fsl,ssi-asynchronous;
};
tdm@16000 {
compatible = "fsl,tdm1.0";
reg = <0x16000 0x200 0x2c000 0x2000>;
clock-frequency = <0x0>;
interrupts = <0x3e 0x8 0x0 0x0>;
fsl,max-time-slots = <0x80>;
};
sata@18000 {
compatible = "fsl,pq-sata-v2";
reg = <0x18000 0x1000>;
cell-index = <0x1>;
interrupts = <0x4a 0x2 0x0 0x0>;
};
sata@19000 {
compatible = "fsl,pq-sata-v2";
reg = <0x19000 0x1000>;
cell-index = <0x2>;
interrupts = <0x29 0x2 0x0 0x0>;
};
l2-cache-controller@20000 {
cache-level = <0x2>;
cache-sets = <0x400>;
cache-block-size = <0x20>;
cache-unified;
compatible = [66 73 6c 2c 70 31 30 32 32 2d 6c 32 2d 63 61 63 68 65 2d 63 6f 6e 74 72 6f 6c 6c 65 72 00 63 61 63 68 65 00 7f fa];
reg = <0x20000 0x1000>;
cache-line-size = <0x20>;
cache-size = <0x40000>;
interrupts = <0x10 0x2 0x0 0x0>;
linux,phandle = <0x2>;
phandle = <0x2>;
};
dma@21300 {
#address-cells = <0x1>;
#size-cells = <0x1>;
compatible = "fsl,eloplus-dma";
reg = <0x21300 0x4>;
ranges = <0x0 0x21100 0x200>;
cell-index = <0x0>;
dma-channel@0 {
compatible = "fsl,eloplus-dma-channel";
reg = <0x0 0x80>;
cell-index = <0x0>;
interrupts = <0x14 0x2 0x0 0x0>;
};
dma-channel@80 {
compatible = "fsl,eloplus-dma-channel";
reg = <0x80 0x80>;
cell-index = <0x1>;
interrupts = <0x15 0x2 0x0 0x0>;
};
dma-channel@100 {
compatible = "fsl,eloplus-dma-channel";
reg = <0x100 0x80>;
cell-index = <0x2>;
interrupts = <0x16 0x2 0x0 0x0>;
};
dma-channel@180 {
compatible = "fsl,eloplus-dma-channel";
reg = <0x180 0x80>;
cell-index = <0x3>;
interrupts = <0x17 0x2 0x0 0x0>;
};
};
usb@22000 {
compatible = "fsl-usb2-dr-v1.6", "fsl-usb2-dr";
reg = <0x22000 0x1000>;
#address-cells = <0x1>;
#size-cells = <0x0>;
interrupts = <0x1c 0x2 0x0 0x0>;
phy_type = "ulpi";
};
usb@23000 {
compatible = "fsl-usb2-dr-v1.6", "fsl-usb2-dr";
reg = <0x23000 0x1000>;
#address-cells = <0x1>;
#size-cells = <0x0>;
interrupts = <0x2e 0x2 0x0 0x0>;
status = "disabled";
};
sdhc@2e000 {
status = "disabled";
compatible = "fsl,p1022-esdhc", "fsl,esdhc";
reg = <0x2e000 0x1000>;
interrupts = <0x48 0x2 0x0 0x0>;
clock-frequency = <0x0>;
sdhci,auto-cmd12;
};
crypto@30000 {
compatible = "fsl,sec3.3", "fsl,sec3.1", "fsl,sec3.0", "fsl,sec2.4", "fsl,sec2.2", "fsl,sec2.1", "fsl,sec2.0";
reg = <0x30000 0x10000>;
interrupts = <0x2d 0x2 0x0 0x0 0x3a 0x2 0x0 0x0>;
fsl,num-channels = <0x4>;
fsl,channel-fifo-len = <0x18>;
fsl,exec-units-mask = <0x97c>;
fsl,descriptor-types-mask = <0x3a30abf>;
};
pic@40000 {
interrupt-controller;
#address-cells = <0x0>;
#interrupt-cells = <0x4>;
reg = <0x40000 0x40000>;
compatible = "fsl,mpic";
device_type = "open-pic";
linux,phandle = <0x1>;
phandle = <0x1>;
};
timer@41100 {
compatible = "fsl,mpic-global-timer";
reg = <0x41100 0x100 0x41300 0x4>;
interrupts = <0x0 0x0 0x3 0x0 0x1 0x0 0x3 0x0 0x2 0x0 0x3 0x0 0x3 0x0 0x3 0x0>;
};
msi@41600 {
compatible = "fsl,mpic-msi";
reg = <0x41600 0x80>;
msi-available-ranges = <0x0 0x100>;
interrupts = <0xe0 0x0 0x0 0x0 0xe1 0x0 0x0 0x0 0xe2 0x0 0x0 0x0 0xe3 0x0 0x0 0x0 0xe4 0x0 0x0 0x0 0xe5 0x0 0x0 0x0 0xe6 0x0 0x0 0x0 0xe7 0x0 0x0 0x0>;
};
timer@42100 {
compatible = "fsl,mpic-global-timer";
reg = <0x42100 0x100 0x42300 0x4>;
interrupts = <0x4 0x0 0x3 0x0 0x5 0x0 0x3 0x0 0x6 0x0 0x3 0x0 0x7 0x0 0x3 0x0>;
};
mdio@24000 {
#address-cells = <0x1>;
#size-cells = <0x0>;
compatible = "fsl,etsec2-mdio";
reg = <0x24000 0x1000 0xb0030 0x4>;
ethernet-phy@0 {
interrupts = <0x3 0x1 0x0 0x0>;
reg = <0x1>;
linux,phandle = <0x7>;
phandle = <0x7>;
};
ethernet-phy@1 {
interrupts = <0x9 0x1 0x0 0x0>;
reg = <0x2>;
linux,phandle = <0xa>;
phandle = <0xa>;
};
tbi-phy@2 {
device_type = "tbi-phy";
reg = <0x2>;
};
};
ethernet@b0000 {
rx-stash-idx = <0x0>;
rx-stash-len = <0x60>;
bd-stash;
#address-cells = <0x1>;
#size-cells = <0x1>;
device_type = "network";
model = "eTSEC";
compatible = "fsl,etsec2";
fsl,num_rx_queues = <0x8>;
fsl,num_tx_queues = <0x8>;
fsl,magic-packet;
local-mac-address = [00 e0 0c 02 00 fd];
fsl,wake-on-filer;
fsl,pmc-handle = <0x6>;
phy-handle = <0x7>;
phy-connection-type = "rgmii-id";
ptimer-handle = <0x8>;
queue-group@b0000 {
#address-cells = <0x1>;
#size-cells = <0x1>;
reg = <0xb0000 0x1000>;
interrupts = <0x1d 0x2 0x0 0x0 0x1e 0x2 0x0 0x0 0x22 0x2 0x0 0x0>;
};
queue-group@b4000 {
#address-cells = <0x1>;
#size-cells = <0x1>;
reg = <0xb4000 0x1000>;
interrupts = <0x11 0x2 0x0 0x0 0x12 0x2 0x0 0x0 0x18 0x2 0x0 0x0>;
};
};
mdio@25000 {
#address-cells = <0x1>;
#size-cells = <0x0>;
compatible = "fsl,etsec2-tbi";
reg = <0x25000 0x1000 0xb1030 0x4>;
};
ethernet@b1000 {
rx-stash-idx = <0x0>;
rx-stash-len = <0x60>;
bd-stash;
#address-cells = <0x1>;
#size-cells = <0x1>;
device_type = "network";
model = "eTSEC";
compatible = "fsl,etsec2";
fsl,num_rx_queues = <0x8>;
fsl,num_tx_queues = <0x8>;
fsl,magic-packet;
local-mac-address = [00 e0 0c 02 01 fd];
fsl,wake-on-filer;
fsl,pmc-handle = <0x9>;
phy-handle = <0xa>;
phy-connection-type = "rgmii-id";
ptimer-handle = <0x8>;
queue-group@b1000 {
#address-cells = <0x1>;
#size-cells = <0x1>;
reg = <0xb1000 0x1000>;
interrupts = <0x23 0x2 0x0 0x0 0x24 0x2 0x0 0x0 0x28 0x2 0x0 0x0>;
};
queue-group@b5000 {
#address-cells = <0x1>;
#size-cells = <0x1>;
reg = <0xb5000 0x1000>;
interrupts = <0x33 0x2 0x0 0x0 0x34 0x2 0x0 0x0 0x43 0x2 0x0 0x0>;
};
};
global-utilities@e0000 {
compatible = "fsl,p1022-guts";
reg = <0xe0000 0x1000>;
fsl,has-rstcr;
};
power@e0070 {
compatible = "fsl,p1022-pmc", "fsl,mpc8536-pmc", "fsl,mpc8548-pmc";
reg = <0xe0070 0x20>;
soc-clk@24 {
fsl,pmcdr-mask = <0x80>;
linux,phandle = <0x6>;
phandle = <0x6>;
};
soc-clk@25 {
fsl,pmcdr-mask = <0x40>;
linux,phandle = <0x9>;
phandle = <0x9>;
};
soc-clk@26 {
fsl,pmcdr-mask = <0x20>;
};
};
ptimer@b0e00 {
compatible = "fsl,gianfar-ptp-timer";
reg = <0xb0e00 0xb0>;
fsl,ts-to-buffer;
fsl,tmr-prsc = <0x2>;
fsl,clock-source-select = <0x1>;
linux,phandle = <0x8>;
phandle = <0x8>;
};
};
pcie@ffe09000 {
dma-ranges = <0x2000000 0x0 0xfff00000 0x0 0xffe00000 0x0 0x100000 0x42000000 0x0 0x0 0x0 0x0 0x0 0x80000000>;
reg = <0x0 0xffe09000 0x0 0x1000>;
ranges = <0x2000000 0x0 0xe0000000 0x0 0xa0000000 0x0 0x20000000 0x1000000 0x0 0x0 0x0 0xffc10000 0x0 0x10000>;
compatible = "fsl,p1022-pcie";
device_type = "pci";
#size-cells = <0x2>;
#address-cells = <0x3>;
bus-range = <0x0 0x0>;
clock-frequency = <0x1fca055>;
interrupts = <0x10 0x2 0x0 0x0>;
pcie@0 {
ranges = <0x2000000 0x0 0xe0000000 0x2000000 0x0 0xe0000000 0x0 0x20000000 0x1000000 0x0 0x0 0x1000000 0x0 0x0 0x0 0x100000>;
reg = <0x0 0x0 0x0 0x0 0x0>;
#interrupt-cells = <0x1>;
#size-cells = <0x2>;
#address-cells = <0x3>;
device_type = "pci";
interrupts = <0x10 0x2 0x0 0x0>;
interrupt-map-mask = <0xf800 0x0 0x0 0x7>;
interrupt-map = <0x0 0x0 0x0 0x1 0x1 0x4 0x1 0x0 0x0 0x0 0x0 0x0 0x2 0x1 0x5 0x1 0x0 0x0 0x0 0x0 0x0 0x3 0x1 0x6 0x1 0x0 0x0 0x0 0x0 0x0 0x4 0x1 0x7 0x1 0x0 0x0>;
};
};
pcie@ffe0a000 {
reg = <0x0 0xffe0a000 0x0 0x1000>;
ranges = <0x2000000 0x0 0xe0000000 0x0 0xc0000000 0x0 0x20000000 0x1000000 0x0 0x0 0x0 0xffc20000 0x0 0x10000>;
compatible = "fsl,p1022-pcie";
device_type = "pci";
#size-cells = <0x2>;
#address-cells = <0x3>;
bus-range = <0x0 0x0>;
clock-frequency = <0x1fca055>;
interrupts = <0x10 0x2 0x0 0x0>;
pcie@0 {
ranges = <0x2000000 0x0 0xe0000000 0x2000000 0x0 0xe0000000 0x0 0x20000000 0x1000000 0x0 0x0 0x1000000 0x0 0x0 0x0 0x100000>;
reg = <0x0 0x0 0x0 0x0 0x0>;
#interrupt-cells = <0x1>;
#size-cells = <0x2>;
#address-cells = <0x3>;
device_type = "pci";
interrupts = <0x10 0x2 0x0 0x0>;
interrupt-map-mask = <0xf800 0x0 0x0 0x7>;
interrupt-map = <0x0 0x0 0x0 0x1 0x1 0x0 0x1 0x0 0x0 0x0 0x0 0x0 0x2 0x1 0x1 0x1 0x0 0x0 0x0 0x0 0x0 0x3 0x1 0x2 0x1 0x0 0x0 0x0 0x0 0x0 0x4 0x1 0x3 0x1 0x0 0x0>;
};
};
pcie@ffe0b000 {
dma-ranges = <0x2000000 0x0 0xfff00000 0x0 0xffe00000 0x0 0x100000 0x42000000 0x0 0x0 0x0 0x0 0x0 0x80000000>;
reg = <0x0 0xffe0b000 0x0 0x1000>;
ranges = <0x2000000 0x0 0xe0000000 0x0 0x80000000 0x0 0x20000000 0x1000000 0x0 0x0 0x0 0xffc00000 0x0 0x10000>;
compatible = "fsl,p1022-pcie";
device_type = "pci";
#size-cells = <0x2>;
#address-cells = <0x3>;
bus-range = <0x0 0x0>;
clock-frequency = <0x1fca055>;
interrupts = <0x10 0x2 0x0 0x0>;
pcie@0 {
ranges = <0x2000000 0x0 0xe0000000 0x2000000 0x0 0xe0000000 0x0 0x20000000 0x1000000 0x0 0x0 0x1000000 0x0 0x0 0x0 0x100000>;
reg = <0x0 0x0 0x0 0x0 0x0>;
#interrupt-cells = <0x1>;
#size-cells = <0x2>;
#address-cells = <0x3>;
device_type = "pci";
interrupts = <0x10 0x2 0x0 0x0>;
interrupt-map-mask = <0xf800 0x0 0x0 0x7>;
interrupt-map = <0x0 0x0 0x0 0x1 0x1 0x8 0x1 0x0 0x0 0x0 0x0 0x0 0x2 0x1 0x9 0x1 0x0 0x0 0x0 0x0 0x0 0x3 0x1 0xa 0x1 0x0 0x0 0x0 0x0 0x0 0x4 0x1 0xb 0x1 0x0 0x0>;
};
};
};
=>
=>
=>
=> run ramboot
Speed: 1000, full duplex
Using eTSEC1 device
TFTP from server 10.193.20.106; our IP address is 10.193.20.176
Filename 'jiaht/ramdisk.small'.
Load address: 0x2000000
Loading: #################################################################
#################################################################
#################################################################
#################################################################
#################################################################
#################################################################
#################################################################
#################################################################
#################################################################
#################################################################
#################################################################
#################################################################
##############################################################
done
Bytes transferred = 4306189 (41b50d hex)
Speed: 1000, full duplex
Using eTSEC1 device
TFTP from server 10.193.20.106; our IP address is 10.193.20.176
Filename 'jiaht/uImage_1022_pm_re_parse_debug'.
Load address: 0x1000000
Loading: #################################################################
#################################################################
#################################################################
#################################################################
#################################################################
#################################################################
#################################################################
#################################################################
#################################################################
#################################################################
#################################################################
#######
done
Bytes transferred = 3695062 (3861d6 hex)
Speed: 1000, full duplex
Using eTSEC1 device
TFTP from server 10.193.20.106; our IP address is 10.193.20.176
Filename 'jiaht/p1022ds_32b.dtb'.
Load address: 0xc00000
Loading: ###
done
Bytes transferred = 14645 (3935 hex)
WARNING: adjusting available memory to 30000000
## Booting kernel from Legacy Image at 01000000 ...
Image Name: Linux-3.0.43-rt64-01350-g826673b
Image Type: PowerPC Linux Kernel Image (gzip compressed)
Data Size: 3694998 Bytes = 3.5 MB
Load Address: 00000000
Entry Point: 00000000
Verifying Checksum ... OK
## Loading init Ramdisk from Legacy Image at 02000000 ...
Image Name: uboot ext2 ramdisk rootfs
Image Type: PowerPC Linux RAMDisk Image (gzip compressed)
Data Size: 4306125 Bytes = 4.1 MB
Load Address: 00000000
Entry Point: 00000000
Verifying Checksum ... OK
## Flattened Device Tree blob at 00c00000
Booting using the fdt blob at 0xc00000
Uncompressing Kernel Image ... OK
Loading Ramdisk to 2fbe4000, end 2ffff4cd ... OK
debug: ignoring loglevel setting.
Using P1022 DS machine description
Memory CAM mapping: 256/256/256 Mb, residual: 1280Mb
Linux version 3.0.43-rt64-01350-g826673b-dirty (jiaht@rock) (gcc version 4.5.2 (Sourcery G++ Lite 2011.03-38) ) #67 SMP Mon Sep 24 10:01:40 CST 2012
Found initrd at 0xefbe4000:0xeffff4cd
Found legacy serial port 0 for /soc@ffe00000/serial@4500
mem=ffe04500, taddr=ffe04500, irq=0, clk=599994006, speed=0
Found legacy serial port 1 for /soc@ffe00000/serial@4600
mem=ffe04600, taddr=ffe04600, irq=0, clk=599994006, speed=0
CPU maps initialized for 1 thread per core
(thread shift is 0)
bootconsole [udbg0] enabled
setup_arch: bootmem
p1022_ds_setup_arch()
Adding PCI host bridge /pcie@ffe09000
Found FSL PCI host bridge at 0x00000000ffe09000. Firmware bus number: 0->0
->Hose at 0xc0765000, cfg_addr=0xff7fd000,cfg_data=0xff7fd004
PCI host bridge /pcie@ffe09000 ranges:
MEM 0x00000000a0000000..0x00000000bfffffff -> 0x00000000e0000000
IO 0x00000000ffc10000..0x00000000ffc1ffff -> 0x0000000000000000
PCI memory map start 0x00000000ffe09000, size 0x0000000000001000
PCI MEM resource start 0x00000000a0000000, size 0x0000000020000000.
PCI IO resource start 0x0000000000000000, size 0x0000000000010000, phy base 0x00000000ffc10000.
/pcie@ffe09000: PCICSRBAR @ 0xfff00000
Adding PCI host bridge /pcie@ffe0a000
Found FSL PCI host bridge at 0x00000000ffe0a000. Firmware bus number: 0->0
->Hose at 0xc07650e0, cfg_addr=0xff7eb000,cfg_data=0xff7eb004
PCI host bridge /pcie@ffe0a000 ranges:
MEM 0x00000000c0000000..0x00000000dfffffff -> 0x00000000e0000000
IO 0x00000000ffc20000..0x00000000ffc2ffff -> 0x0000000000000000
PCI memory map start 0x00000000ffe0a000, size 0x0000000000001000
PCI MEM resource start 0x00000000c0000000, size 0x0000000020000000.
PCI IO resource start 0x0000000000000000, size 0x0000000000010000, phy base 0x00000000ffc20000.
/pcie@ffe0a000: PCICSRBAR @ 0xfff00000
Adding PCI host bridge /pcie@ffe0b000
Found FSL PCI host bridge at 0x00000000ffe0b000. Firmware bus number: 0->0
->Hose at 0xc07651c0, cfg_addr=0xff7d9000,cfg_data=0xff7d9004
PCI host bridge /pcie@ffe0b000 ranges:
MEM 0x0000000080000000..0x000000009fffffff -> 0x00000000e0000000
IO 0x00000000ffc00000..0x00000000ffc0ffff -> 0x0000000000000000
PCI memory map start 0x00000000ffe0b000, size 0x0000000000001000
PCI MEM resource start 0x0000000080000000, size 0x0000000020000000.
PCI IO resource start 0x0000000000000000, size 0x0000000000010000, phy base 0x00000000ffc00000.
/pcie@ffe0b000: PCICSRBAR @ 0xfff00000
Freescale P1022 DS reference board
arch: exit
Top of RAM: 0x80000000, Total RAM: 0x80000000
Memory hole size: 0MB
Zone PFN ranges:
DMA 0x00000000 -> 0x00030000
Normal empty
HighMem 0x00030000 -> 0x00080000
Movable zone start PFN for each node
early_node_map[1] active PFN ranges
0: 0x00000000 -> 0x00080000
On node 0 totalpages: 524288
free_area_init_node: node 0, pgdat c072e380, node_mem_map c0c04000
DMA zone: 1536 pages used for memmap
DMA zone: 0 pages reserved
DMA zone: 195072 pages, LIFO batch:31
HighMem zone: 2560 pages used for memmap
HighMem zone: 325120 pages, LIFO batch:31
MMU: Allocated 1088 bytes of context maps for 255 contexts
PERCPU: Embedded 7 pages/cpu @c1c10000 s4768 r8192 d15712 u32768
pcpu-alloc: s4768 r8192 d15712 u32768 alloc=8*4096
pcpu-alloc: [0] 0 [0] 1
Built 1 zonelists in Zone order, mobility grouping on. Total pages: 520192
Kernel command line: root=/dev/ram rw console=ttyS0,115200 ramdisk_size=400000 cache-sram-size=0x8000 cache-sram-offset=0xfff00000 no_console_suspend ignore_loglevel
PID hash table entries: 4096 (order: 2, 16384 bytes)
Dentry cache hash table entries: 131072 (order: 7, 524288 bytes)
Inode-cache hash table entries: 65536 (order: 6, 262144 bytes)
High memory: 1310716k
Memory: 2067952k/2097152k available (7160k kernel code, 29200k reserved, 236k data, 174k bss, 268k init)
Kernel virtual memory layout:
* 0xfff5f000..0xfffff000 : fixmap
* 0xff800000..0xffc00000 : highmem PTEs
* 0xff7c7000..0xff800000 : early ioremap
* 0xf1000000..0xff7c7000 : vmalloc & ioremap
SLUB: Genslabs=15, HWalign=32, Order=0-3, MinObjects=0, CPUs=2, Nodes=1
Hierarchical RCU implementation.
NR_IRQS:512 nr_irqs:512 16
mpic: Resetting
mpic: Setting up MPIC " OpenPIC " version 1.2 at ffe40000, max 2 CPUs
mpic: ISU size: 256, shift: 8, mask: ff
mpic: Initializing for 256 sources
time_init: decrementer frequency = 74.999251 MHz
time_init: processor frequency = 1199.988012 MHz
clocksource: timebase mult[3555784] shift[22] registered
clockevent: decrementer mult[133326a2] shift[32] cpu[0]
Console: colour dummy device 80x25
pid_max: default: 32768 minimum: 301
Mount-cache hash table entries: 512
mpic: requesting IPIs...
Brought up 2 CPUs
NET: Registered protocol family 16
PCI: Probing PCI hardware
pci 0000:00:00.0: [1957:0110] type 1 class 0x000b20
pci 0000:00:00.0: ignoring class b20 (doesn't match header type 01)
pci 0000:00:00.0: supports D1 D2
pci 0000:00:00.0: PME# supported from D0 D1 D2 D3hot D3cold
pci 0000:00:00.0: PME# disabled
pci 0000:00:00.0: PCI bridge to [bus 01-ff]
pci 0000:00:00.0: bridge window [io 0x0000-0x0000] (disabled)
pci 0000:00:00.0: bridge window [mem 0x00000000-0x000fffff] (disabled)
pci 0000:00:00.0: bridge window [mem 0x00000000-0x000fffff pref] (disabled)
pci 0001:02:00.0: [1957:0110] type 1 class 0x000b20
pci 0001:02:00.0: ignoring class b20 (doesn't match header type 01)
pci 0001:02:00.0: supports D1 D2
pci 0001:02:00.0: PME# supported from D0 D1 D2 D3hot D3cold
pci 0001:02:00.0: PME# disabled
pci 0001:02:00.0: PCI bridge to [bus 03-ff]
pci 0001:02:00.0: bridge window [io 0x0000-0x0000] (disabled)
pci 0001:02:00.0: bridge window [mem 0x00000000-0x000fffff] (disabled)
pci 0001:02:00.0: bridge window [mem 0x00000000-0x000fffff pref] (disabled)
pci 0002:04:00.0: [1957:0110] type 1 class 0x000b20
pci 0002:04:00.0: ignoring class b20 (doesn't match header type 01)
pci 0002:04:00.0: supports D1 D2
pci 0002:04:00.0: PME# supported from D0 D1 D2 D3hot D3cold
pci 0002:04:00.0: PME# disabled
pci 0002:04:00.0: PCI bridge to [bus 05-ff]
pci 0002:04:00.0: bridge window [io 0x0000-0x0000] (disabled)
pci 0002:04:00.0: bridge window [mem 0x00000000-0x000fffff] (disabled)
pci 0002:04:00.0: bridge window [mem 0x00000000-0x000fffff pref] (disabled)
PCI 0000:00 Cannot reserve Legacy IO [io 0xff7ed000-0xff7edfff]
PCI 0001:02 Cannot reserve Legacy IO [io 0xff7db000-0xff7dbfff]
PCI 0002:04 Cannot reserve Legacy IO [io 0xff7c9000-0xff7c9fff]
PCI: max bus depth: 1 pci_try_num: 2
pci 0000:00:00.0: PCI bridge to [bus 01-01]
pci 0000:00:00.0: bridge window [io 0xff7ed000-0xff7fcfff]
pci 0000:00:00.0: bridge window [mem 0xa0000000-0xbfffffff]
pci 0000:00:00.0: bridge window [mem pref disabled]
pci 0001:02:00.0: PCI bridge to [bus 03-03]
pci 0001:02:00.0: bridge window [io 0xff7db000-0xff7eafff]
pci 0001:02:00.0: bridge window [mem 0xc0000000-0xdfffffff]
pci 0001:02:00.0: bridge window [mem pref disabled]
pci 0002:04:00.0: PCI bridge to [bus 05-05]
pci 0002:04:00.0: bridge window [io 0xff7c9000-0xff7d8fff]
pci 0002:04:00.0: bridge window [mem 0x80000000-0x9fffffff]
pci 0002:04:00.0: bridge window [mem pref disabled]
pci 0000:00:00.0: enabling device (0106 -> 0107)
pci 0001:02:00.0: enabling device (0106 -> 0107)
pci 0002:04:00.0: enabling device (0106 -> 0107)
pci_bus 0000:00: resource 0 [io 0xff7ed000-0xff7fcfff]
pci_bus 0000:00: resource 1 [mem 0xa0000000-0xbfffffff]
pci_bus 0000:01: resource 0 [io 0xff7ed000-0xff7fcfff]
pci_bus 0000:01: resource 1 [mem 0xa0000000-0xbfffffff]
pci_bus 0001:02: resource 0 [io 0xff7db000-0xff7eafff]
pci_bus 0001:02: resource 1 [mem 0xc0000000-0xdfffffff]
pci_bus 0001:03: resource 0 [io 0xff7db000-0xff7eafff]
pci_bus 0001:03: resource 1 [mem 0xc0000000-0xdfffffff]
pci_bus 0002:04: resource 0 [io 0xff7c9000-0xff7d8fff]
pci_bus 0002:04: resource 1 [mem 0x80000000-0x9fffffff]
pci_bus 0002:05: resource 0 [io 0xff7c9000-0xff7d8fff]
pci_bus 0002:05: resource 1 [mem 0x80000000-0x9fffffff]
Registering qe_ic with sysfs...
bio: create slab <bio-0> at 0
raid6: int32x1 172 MB/s
raid6: int32x2 301 MB/s
raid6: int32x4 427 MB/s
raid6: int32x8 358 MB/s
raid6: using algorithm int32x4 (427 MB/s)
Freescale Elo / Elo Plus DMA driver
vgaarb: loaded
SCSI subsystem initialized
libata version 3.00 loaded.
usbcore: registered new interface driver usbfs
usbcore: registered new interface driver hub
usbcore: registered new device driver usb
Advanced Linux Sound Architecture Driver Version 1.0.24.
Switching to clocksource timebase
Switched to NOHz mode on CPU #0
Switched to NOHz mode on CPU #1
NET: Registered protocol family 2
IP route cache hash table entries: 32768 (order: 5, 131072 bytes)
TCP established hash table entries: 131072 (order: 8, 1048576 bytes)
TCP bind hash table entries: 65536 (order: 7, 524288 bytes)
TCP: Hash tables configured (established 131072 bind 65536)
TCP reno registered
UDP hash table entries: 512 (order: 2, 16384 bytes)
UDP-Lite hash table entries: 512 (order: 2, 16384 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.
PCI: CLS 0 bytes, default 32
Trying to unpack rootfs image as initramfs...
rootfs image is not initramfs (no cpio magic); looks like an initrd
Freeing initrd memory: 4208k freed
fsl-elo-dma ffe0c300.dma: #2 (fsl,eloplus-dma-channel), irq 78
fsl-elo-dma ffe0c300.dma: #3 (fsl,eloplus-dma-channel), irq 79
fsl-l2ctlr ffe20000.l2-cache-controller: Entire L2 as cache, provide valid sram address and size
fsl-l2ctlr: probe of ffe20000.l2-cache-controller failed with error -22
fsl-elo-dma ffe21300.dma: #0 (fsl,eloplus-dma-channel), irq 20
fsl-elo-dma ffe21300.dma: #1 (fsl,eloplus-dma-channel), irq 21
fsl-elo-dma ffe21300.dma: #2 (fsl,eloplus-dma-channel), irq 22
fsl-elo-dma ffe21300.dma: #3 (fsl,eloplus-dma-channel), irq 23
Setting up Freescale MSI support
Freescale PowerQUICC MII Bus: probed
fsl-pq_mdio: probe of ffe25000.mdio failed with error -16
Freescale PMC driver
audit: initializing netlink socket (disabled)
type=2000 audit(0.704:1): initialized
highmem bounce pool size: 64 pages
Installing knfsd (copyright (C) 1996 okir@monad.swb.de).
NTFS driver 2.1.30 [Flags: R/O].
JFFS2 version 2.2. (NAND) ?? 2001-2006 Red Hat, Inc.
Allocated 267980 bytes for deflate workspace
Allocated 42284 bytes for inflate workspace
Registering JFFS2 compressor "zlib"
Registering JFFS2 compressor "rtime"
JFFS2: default compression mode: priority
msgmni has been set to 1487
io scheduler noop registered
io scheduler deadline registered
io scheduler cfq registered (default)
Freescale DIU driver
Console: switching to colour frame buffer device 128x48
fb0: Panel0 fb device registered successfully.
fb1: fb device registered successfully.
fb2: fb device registered successfully.
fb3: fb device registered successfully.
fb4: fb device registered successfully.
Serial: 8250/16550 driver, 2 ports, IRQ sharing enabled
serial8250.0: ttyS0 at MMIO 0xffe04500 (irq = 42) is a 16550A
console [ttyS0] enabled, bootconsole disabled
console [ttyS0] enabled, bootconsole disabled
serial8250.0: ttyS1 at MMIO 0xffe04600 (irq = 42) is a 16550A
Generic non-volatile memory driver v1.1
brd: module loaded
loop: module loaded
nbd: registered device at major 43
st: Version 20101219, fixed bufsize 32768, s/g segs 256
fsl-sata ffe18000.sata: Sata FSL Platform/CSB Driver init
scsi0 : sata_fsl
ata1: SATA max UDMA/133 irq 74
fsl-sata ffe19000.sata: Sata FSL Platform/CSB Driver init
scsi1 : sata_fsl
ata2: SATA max UDMA/133 irq 41
e8000000.nor: Found 1 x16 devices at 0x0 in 16-bit bank. Manufacturer ID 0x000001 Chip ID 0x002801
Amd/Fujitsu Extended Query Table at 0x0040
Amd/Fujitsu Extended Query version 1.3.
number of CFI chips: 1
Creating 7 MTD partitions on "e8000000.nor":
0x000000000000-0x000003000000 : "ramdisk-nor"
ftl_cs: FTL header not found.
0x000003000000-0x000003e00000 : "diagnostic-nor"
ftl_cs: FTL header not found.
0x000003e00000-0x000004000000 : "dink-nor"
ftl_cs: FTL header not found.
0x000004000000-0x000004400000 : "kernel-nor"
ftl_cs: FTL header not found.
0x000004400000-0x000007f00000 : "jffs2-nor"
ftl_cs: FTL header not found.
0x000007f00000-0x000007f80000 : "dtb-nor"
ftl_cs: FTL header not found.
0x000007f80000-0x000008000000 : "u-boot-nor"
ftl_cs: FTL header not found.
fsl-lbc ffe05000.localbus: address did not match any chip selects
m25p80 spi32766.0: s25sl12801 (16384 Kbytes)
Creating 4 MTD partitions on "spi32766.0":
0x000000000000-0x000000100000 : "u-boot-spi"
ftl_cs: FTL header not found.
0x000000100000-0x000000600000 : "kernel-spi"
ftl_cs: FTL header not found.
0x000000600000-0x000000700000 : "dtb-spi"
ftl_cs: FTL header not found.
0x000000700000-0x000001000000 : "file system-spi"
ftl_cs: FTL header not found.
fsl_espi ffe07000.spi: at 0xf1064000 (irq = 59)
Fixed MDIO Bus: probed
e1000e: Intel(R) PRO/1000 Network Driver - 1.3.10-k2
e1000e: Copyright(c) 1999 - 2011 Intel Corporation.
fsl-gianfar ethernet.4: eth0: mac: 00:e0:0c:02:00:fd
fsl-gianfar ethernet.4: eth0: Running with NAPI enabled
fsl-gianfar ethernet.4: eth0: RX BD ring size for Q[0]: 256
fsl-gianfar ethernet.4: eth0: RX BD ring size for Q[1]: 256
fsl-gianfar ethernet.4: eth0: RX BD ring size for Q[2]: 256
fsl-gianfar ethernet.4: eth0: RX BD ring size for Q[3]: 256
fsl-gianfar ethernet.4: eth0: RX BD ring size for Q[4]: 256
fsl-gianfar ethernet.4: eth0: RX BD ring size for Q[5]: 256
fsl-gianfar ethernet.4: eth0: RX BD ring size for Q[6]: 256
fsl-gianfar ethernet.4: eth0: RX BD ring size for Q[7]: 256
fsl-gianfar ethernet.4: eth0: TX BD ring size for Q[0]: 256
fsl-gianfar ethernet.4: eth0: TX BD ring size for Q[1]: 256
fsl-gianfar ethernet.4: eth0: TX BD ring size for Q[2]: 256
fsl-gianfar ethernet.4: eth0: TX BD ring size for Q[3]: 256
fsl-gianfar ethernet.4: eth0: TX BD ring size for Q[4]: 256
fsl-gianfar ethernet.4: eth0: TX BD ring size for Q[5]: 256
fsl-gianfar ethernet.4: eth0: TX BD ring size for Q[6]: 256
fsl-gianfar ethernet.4: eth0: TX BD ring size for Q[7]: 256
fsl-gianfar ethernet.5: eth1: mac: 00:e0:0c:02:01:fd
fsl-gianfar ethernet.5: eth1: Running with NAPI enabled
fsl-gianfar ethernet.5: eth1: RX BD ring size for Q[0]: 256
fsl-gianfar ethernet.5: eth1: RX BD ring size for Q[1]: 256
fsl-gianfar ethernet.5: eth1: RX BD ring size for Q[2]: 256
fsl-gianfar ethernet.5: eth1: RX BD ring size for Q[3]: 256
fsl-gianfar ethernet.5: eth1: RX BD ring size for Q[4]: 256
fsl-gianfar ethernet.5: eth1: RX BD ring size for Q[5]: 256
fsl-gianfar ethernet.5: eth1: RX BD ring size for Q[6]: 256
fsl-gianfar ethernet.5: eth1: RX BD ring size for Q[7]: 256
fsl-gianfar ethernet.5: eth1: TX BD ring size for Q[0]: 256
fsl-gianfar ethernet.5: eth1: TX BD ring size for Q[1]: 256
fsl-gianfar ethernet.5: eth1: TX BD ring size for Q[2]: 256
fsl-gianfar ethernet.5: eth1: TX BD ring size for Q[3]: 256
fsl-gianfar ethernet.5: eth1: TX BD ring size for Q[4]: 256
fsl-gianfar ethernet.5: eth1: TX BD ring size for Q[5]: 256
fsl-gianfar ethernet.5: eth1: TX BD ring size for Q[6]: 256
fsl-gianfar ethernet.5: eth1: TX BD ring size for Q[7]: 256
ucc_geth: QE UCC Gigabit Ethernet Controller
ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver
ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver
/soc@ffe00000/usb@22000: Invalid 'dr_mode' property, fallback to host mode
fsl-ehci fsl-ehci.0: Freescale On-Chip EHCI Host Controller
fsl-ehci fsl-ehci.0: new USB bus registered, assigned bus number 1
fsl-ehci fsl-ehci.0: irq 28, io mem 0xffe22000
fsl-ehci fsl-ehci.0: USB 2.0 started, EHCI 1.00
hub 1-0:1.0: USB hub found
hub 1-0:1.0: 1 port detected
Initializing USB Mass Storage driver...
usbcore: registered new interface driver usb-storage
USB Mass Storage support registered.
mpc-i2c ffe03000.i2c: timeout 1000000 us
mpc-i2c ffe03100.i2c: timeout 1000000 us
EDAC MC: Ver: 2.1.0
sdhci: Secure Digital Host Controller Interface driver
sdhci: Copyright(c) Pierre Ossman
talitos ffe30000.crypto: hwrng
talitos ffe30000.crypto: fsl,sec3.3 algorithms registered in /proc/crypto
usbcore: registered new interface driver usbhid
usbhid: USB HID core driver
Freescale Synchronous Serial Interface (SSI) ASoC Driver
snd-soc-p1022ds snd-soc-p1022ds.0: codec bus-frequency property is missing or invalid
snd-soc-p1022ds: probe of snd-soc-p1022ds.0 failed with error -22
ata1: No Device OR PHYRDY change,Hstatus = 0xa0000000
ata1: SATA link down (SStatus 0 SControl 300)
Freescale Elo DMA ASoC PCM Driver
ALSA device list:
No soundcards found.
ata2: No Device OR PHYRDY change,Hstatus = 0xa0000000
ata2: SATA link down (SStatus 0 SControl 300)
IPv4 over IPv4 tunneling driver
TCP cubic registered
Initializing XFRM netlink socket
NET: Registered protocol family 10
IPv6 over IPv4 tunneling driver
NET: Registered protocol family 17
NET: Registered protocol family 15
Registering the dns_resolver key type
drivers/rtc/hctosys.c: unable to open rtc device (rtc0)
RAMDISK: gzip image found at block 0
VFS: Mounted root (ext2 filesystem) on device 1:0.
Freeing unused kernel memory: 268k freed
Mounting /proc and /sys
Setting the hostname to mpc8572ds
Running depmod
WARNING: Couldn't open directory /lib/modules/3.0.43-rt64-01350-g826673b-dirty: No such file or directory
FATAL: Could not open /lib/modules/3.0.43-rt64-01350-g826673b-dirty/modules.dep.temp for writing: No such file or directory
Mounting filesystems
Starting syslogd and klogd
Running sysctl
Setting up networking on loopback device:
Setting up networking on eth0:
ADDRCONF(NETDEV_UP): eth0: link is not ready
Adding static route for default gateway to 192.168.1.1:
Setting nameserver to 192.168.1.1 in /etc/resolv.conf:
Setting up networking on eth1:
ADDRCONF(NETDEV_UP): eth1: link is not ready
Adding static route for default gateway to 192.168.1.1:
Setting nameserver to 192.168.1.1 in /etc/resolv.conf:
Starting inetd:
Please set the system time using
date <mmddhhmnyyyy>
/sbin/hwclock -w
Welcome to Freescale Semiconductor Embedded Linux Environment
!!!!! WARNING !!!!!!!
The default password for the root account is: root
please change this password using the 'passwd' command
and then edit this message (/etc/issue) to remove this message
mpc8572ds login: PHY: mdio@ffe24000:01 - Link is Up - 1000/Full
ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
eth0: no IPv6 routers present
Welcome to Freescale Semiconductor Embedded Linux Environment
!!!!! WARNING !!!!!!!
The default password for the root account is: root
please change this password using the 'passwd' command
and then edit this message (/etc/issue) to remove this message
mpc8572ds login:
^ 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