* Re: Gianfar tx-babbling-errors
From: Kumar Gala @ 2009-02-19 17:03 UTC (permalink / raw)
To: sjoyeau; +Cc: linuxppc-dev, Scott Coulter
In-Reply-To: <d194b8ce0902190848hb53166cj32e7d0bd65021d2e@mail.gmail.com>
On Feb 19, 2009, at 10:48 AM, sjoyeau@wanadoo.fr wrote:
> Hi Scott,
>
> Your issue may come from data setup (or corruption) instead of code
> path: babbling error may occurs when a TSEC TX descriptor hasn't its
> "last frame" bit set or when the data length is greated than max
> frame length.
>
> --
Take a look at TxBD[TR] and see if its getting set ever.
- k
^ permalink raw reply
* Re: [RFC v1] virtio: add virtio-over-PCI driver
From: Ira Snyder @ 2009-02-19 17:03 UTC (permalink / raw)
To: Kumar Gala
Cc: Arnd Bergmann, Jan-Bernd Themann, netdev, Rusty Russell,
linux-kernel, linuxppc-dev
In-Reply-To: <C04B22C6-BCE8-4D99-A160-22F8846C8209@kernel.crashing.org>
On Thu, Feb 19, 2009 at 10:51:43AM -0600, Kumar Gala wrote:
>
> On Feb 19, 2009, at 12:13 AM, Zang Roy-R61911 wrote:
>
>>
>>
>>> -----Original Message-----
>>> From:
>>> linuxppc-dev-bounces+tie-fei.zang=freescale.com@ozlabs.org
>>> [mailto:linuxppc-dev-bounces+tie-fei.zang=freescale.com@ozlabs
>>> .org] On Behalf Of Kumar Gala
>>> Sent: Thursday, February 19, 2009 0:47 AM
>>> To: Ira Snyder
>>> Cc: Arnd Bergmann; Jan-Bernd Themann; netdev@vger.kernel.org;
>>> Rusty Russell; linux-kernel@vger.kernel.org; linuxppc-dev@ozlabs.org
>>> Subject: Re: [RFC v1] virtio: add virtio-over-PCI driver
>>>
>>>
>>> On Feb 17, 2009, at 4:24 PM, Ira Snyder wrote:
>>>
>>>>
>>>> Documentation/virtio-over-PCI.txt | 61 ++
>>>> arch/powerpc/boot/dts/mpc834x_mds.dts | 7 +
>>>
>>> we'll have to review the .dts and expect a documentation update for
>>> the node. But that's pretty minor at this point.
>>>
>>>> drivers/virtio/Kconfig | 22 +
>>>> drivers/virtio/Makefile | 2 +
>>>> drivers/virtio/vop.h | 119 ++
>>>> drivers/virtio/vop_fsl.c | 1911
>>> ++++++++++++++++++++++++
>>>> +++++++++
>>>
>>> make this vop_fsl_mpc83xx.c or something along those lines.
>> why?
>
> so we can deal with 85xx as well. We just need to isolate the 83xx
> specific bits (message usage)
>
In fact, most of the driver has nothing to do with hardware, and
everything to do with managing memory.
Most of the driver could be shared between implementations. The only
things that would be hardware specific are setting up the descriptor
memory, and raising/handling interrupts.
I just wanted to get something working and out here to discuss. I
figured that more hardware support, features, etc. could come later.
Just like everything else in the kernel, I'm sure this will have to
evolve over time as well.
Thanks,
Ira
^ permalink raw reply
* Re: [RFC v1] virtio: add virtio-over-PCI driver
From: Kumar Gala @ 2009-02-19 16:51 UTC (permalink / raw)
To: Zang Roy-R61911
Cc: Arnd Bergmann, Jan-Bernd Themann, netdev, Rusty Russell,
linux-kernel, linuxppc-dev, Ira Snyder
In-Reply-To: <7DF0AF56456B8F4081E3C44CCCE311DE1519A3@zch01exm23.fsl.freescale.net>
On Feb 19, 2009, at 12:13 AM, Zang Roy-R61911 wrote:
>
>
>> -----Original Message-----
>> From:
>> linuxppc-dev-bounces+tie-fei.zang=freescale.com@ozlabs.org
>> [mailto:linuxppc-dev-bounces+tie-fei.zang=freescale.com@ozlabs
>> .org] On Behalf Of Kumar Gala
>> Sent: Thursday, February 19, 2009 0:47 AM
>> To: Ira Snyder
>> Cc: Arnd Bergmann; Jan-Bernd Themann; netdev@vger.kernel.org;
>> Rusty Russell; linux-kernel@vger.kernel.org; linuxppc-dev@ozlabs.org
>> Subject: Re: [RFC v1] virtio: add virtio-over-PCI driver
>>
>>
>> On Feb 17, 2009, at 4:24 PM, Ira Snyder wrote:
>>
>>>
>>> Documentation/virtio-over-PCI.txt | 61 ++
>>> arch/powerpc/boot/dts/mpc834x_mds.dts | 7 +
>>
>> we'll have to review the .dts and expect a documentation update for
>> the node. But that's pretty minor at this point.
>>
>>> drivers/virtio/Kconfig | 22 +
>>> drivers/virtio/Makefile | 2 +
>>> drivers/virtio/vop.h | 119 ++
>>> drivers/virtio/vop_fsl.c | 1911
>> ++++++++++++++++++++++++
>>> +++++++++
>>
>> make this vop_fsl_mpc83xx.c or something along those lines.
> why?
so we can deal with 85xx as well. We just need to isolate the 83xx
specific bits (message usage)
- k
^ permalink raw reply
* Re: [RFC v1] virtio: add virtio-over-PCI driver
From: Ira Snyder @ 2009-02-19 16:49 UTC (permalink / raw)
To: Rusty Russell
Cc: linuxppc-dev, netdev, linux-kernel, Arnd Bergmann,
Jan-Bernd Themann
In-Reply-To: <200902192148.05651.rusty@rustcorp.com.au>
On Thu, Feb 19, 2009 at 09:48:04PM +1030, Rusty Russell wrote:
> On Thursday 19 February 2009 03:08:35 Ira Snyder wrote:
> > On Wed, Feb 18, 2009 at 05:13:03PM +1030, Rusty Russell wrote:
> > > don't restrict yourself to 32 feature bits (only PCI does this, and they're
> > > going to have to hack when we reach feature 32).
> >
> > There isn't any problem adding more feature bits. Do you think 128 bits
> > is enough?
>
> Probably. We have unlimited bits in lguest and s390, but 128 is reasonable
> for the forseeable future (if not, you end up using bit 128 to mean "look
> somewhere else for the rest of the bits).
>
Ok. There currently isn't an interface to access more than 32 bits
anyway.
> > > How about prepending a 4 byte length on the host buffers? Allows host to
> > > specify length (for host->guest), and guest writes it to allow truncated
> > > buffers on guest->host.
> > >
> > > That won't allow you to transfer *more* than one buffersize to the host, but
> > > you could use a different method (perhaps the 4 bytes indicates the *total*
> > > length?).
> >
> > I don't understand how this will help.
> >
> > I looked at virtio_net's implemention with VIRTIO_NET_F_MRG_RXBUF, which
> > seems like it could really help performance. The problems with that are:
> > 1) virtio_net doesn't write the merged header's num_buffers field
> > 2) virtio_net doesn't actually split packets in xmit
> ...
> > I'm using two instances of virtio_net to talk to each other, rather than
> > a special userspace implementation like lguest and kvm use. Is this a
> > good approach?
>
> Well, virtio in general is guest-host asymmetric. I originally explored
> symmetry, but it didn't seem to offer any concrete advantages, so we didn't
> require it. You aren't actually directly connecting two guests, are you?
> So this is just a simplification for your implementation?
>
I'm not connecting two guests directly. My eventual setup will have a
single x86 computer (the host) and many guest systems. I don't care if
the guests cannot communicate between each other, just that they can
communicate with the host.
I wanted to avoid the extra trip to userspace, so I just connected two
instances of virtio_net together. This way you just recv packets in the
kernel, rather than jumping to userspace and then using TAP/TUN to drive
packets back into the kernel. Plus, I have no idea how I would do a
userspace interface. I'd definitely need help.
> You could always add a VIRTIO_NET_F_MRG_TXBUF which did what you want, but
> note that symmetry breaks down for other virtio uses, too: block definitely
> isn't symmetric of course, but I haven't audited the others.
>
I have no need to use virtio_blk, so I pretty much ignored it. In fact, I
didn't make any attempt to support RO and WO buffers in the same queue.
Virtio_net only uses queues this way, and it was much easier for me to
wrap my head around.
I don't think that virtio_console is symmetric either, but I haven't
really studied it. I was thinking about implementing a virtio_uart which
would be symmetric. That would be plenty for my needs.
> So I'd recommend asymmetry; hack your host to understand chained buffers.
>
It's not that virtio_net doesn't understand chained buffers, it just
doesn't write them. Grep for uses of the num_buffers field in
virtio_net. It uses them in recv, it just doesn't write them in xmit.
It assumes that add_buf() can accept something like:
idx address len flags next
0 XXXXXXX 12 N 1
1 XXXXXXX 8000 - 2
That would mean it can shove an 8000 byte packet into the virtqueue. It
doesn't have any way of knowing to split packets up into chunks, nor how
many chunks are available. It assumes that the receiver can read from
any address on the sender.
I think that this is a perfectly reasonable assumption in a shared
memory system, but it breaks down in my case. I cannot just tell the
host "the packet data is at this address" because it cannot do DMA. I
have to use the guest system to do DMA. The host has to have
pre-allocated the recv memory so the DMA engine has somewhere to copy
the data to.
Maybe I'm explaining this poorly, but try to think about it this way:
1) Unlike a virtual machine, both systems are NOT sharing memory
2) Both systems have some limited access to each other's memory
3) Both systems can write descriptors equally fast
4) Copying payload data is extremely slow for the host
5) Copying payload data is extremely fast for the guest
It would be possible to just alter virtio_net's headers in-flight to set
the number of buffers actually used. This would split the 8000 byte
packet up into two chunks, 4096 byte and 3904 byte, then set num_buffers
to 2. This would add some complexity, but I think it is probably
reasonable.
Ira
^ permalink raw reply
* Re: Gianfar tx-babbling-errors
From: sjoyeau @ 2009-02-19 16:48 UTC (permalink / raw)
To: Scott Coulter; +Cc: linuxppc-dev
In-Reply-To: <43EB80E07C42E1408726E4905FB96B04C07700@CYBORG3.cyclone.com>
[-- Attachment #1: Type: text/plain, Size: 1650 bytes --]
Hi Scott,
Your issue may come from data setup (or corruption) instead of code path:
babbling error may occurs when a TSEC TX descriptor hasn't its "last frame"
bit set or when the data length is greated than max frame length.
--
sj
2009/2/19 Scott Coulter <scott.coulter@cyclone.com>
>
>
> Kumar,
>
> >
> > can't think of any. How about adding a BUG_ON() in the tx path to see
> > if the buffer size > MTU and re-run your tests.
> >
>
> So, here are the checks I've tried in gfar_start_xmit():
>
> BUG_ON(skb->len > DEFAULT_RX_BUFFER_SIZE)
>
> BUG_ON(skb->len > priv->regs->maxfrm)
>
> Neither produces a bug check yet ethtool reports non-zero
> tx-babbling-errors. The last check appears to be the definition of
> tx-babbling-errors. Is there a transmit path that I have missed?
>
> Scott
>
> ___________________________________________________________________
>
> Scott N. Coulter
> Senior Software Engineer
>
> Cyclone Microsystems
> 370 James Street Phone: 203.786.5536 ext. 118
> New Haven, CT 06513-3051 Email: scott.coulter@cyclone.com
> U.S.A. Web: http://www.cyclone.com
> ___________________________________________________________________
>
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
>
--
------------------
Sylvain JOYEAU
Freelance Engineer
Software RT-OS R&D
sylvain.joyeau@gmail.com
Tél: +33-(0)667 477 052
"A good idea is one side of the coin. The other side is the practical
usefulness". J. Liedke.
[-- Attachment #2: Type: text/html, Size: 2679 bytes --]
^ permalink raw reply
* Re: [PATCH] powerpc/83xx: Do not configure or probe disabled FSL DR USB controllers
From: Kumar Gala @ 2009-02-19 16:43 UTC (permalink / raw)
To: Anton Vorontsov; +Cc: Liu Dave, Andy Fleming, linuxppc-dev
In-Reply-To: <20090219160223.GA2095@oksana.dev.rtsoft.ru>
On Feb 19, 2009, at 10:02 AM, Anton Vorontsov wrote:
> On MPC837X CPUs Dual-Role USB isn't always available (for example DR
> USB pins can be muxed away to eSDHC).
>
> U-Boot adds status = "disabled" property into the DR USB nodes to
> indicate that we must not try to configure or probe Dual-Role USB,
> otherwise we'll break eSDHC support on targets with MPC837X CPUs.
>
> Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
> ---
> arch/powerpc/platforms/83xx/usb.c | 3 ++-
> arch/powerpc/sysdev/fsl_soc.c | 4 ++++
> 2 files changed, 6 insertions(+), 1 deletions(-)
applied to next
- k
^ permalink raw reply
* Re: [PATCH] fix the interrupt loss problem on powerpc IPIC(2.6.25-2.6.28)
From: Kumar Gala @ 2009-02-19 16:41 UTC (permalink / raw)
To: <dayu@datangmobile.cn>; +Cc: olof, linuxppc-dev, leoli, linux-kernel
In-Reply-To: <D728AD1FA2543948B89DE29C5BF4CD0716AF9623@bjmail1.bj.datangmobile.com>
On Feb 17, 2009, at 11:47 PM, <dayu@datangmobile.cn> <dayu@datangmobile.cn
> wrote:
>
> From: Da Yu <dayu@datangmobile.cn>
> Date: Wed, 18 Feb 2009 19:58:20 +0800
> Subject: [PATCH] fix the interrupt loss problem on powerpc IPIC
> (2.6.25-2.6.28)
>
> Description: The interrupt pending register is write 1 clear. If
> there are more than one external interrupts pending at the same
> time, acking the first interrupt by reading pending register then OR
> the corresponding bit and write back to pending register will also
> clear other interrupt pending bits. That will cause loss of
> interrupt.
>
> Signed-off-by: Da Yu <dayu@datangmobile.cn>
> ---
applied to next
- k
^ permalink raw reply
* Re: [PATCH] i2c-mpc: do not allow interruptions when waiting for I2C to complete
From: Kumar Gala @ 2009-02-19 16:41 UTC (permalink / raw)
To: Timur Tabi; +Cc: linuxppc-dev, broonie, linux-i2c, mditto
In-Reply-To: <1233928837-3401-1-git-send-email-timur@freescale.com>
On Feb 6, 2009, at 8:00 AM, Timur Tabi wrote:
> The i2c_wait() function is using wait_event_interruptible_timeout()
> to wait for
> the I2C controller to signal that it has completed an I2C bus
> operation. If
> the process that causes the I2C operation terminated abruptly, the
> wait will
> be interrupted, returning an error. It is better to let the I2C
> operation
> finished before the process exits.
>
> It is safe to use wait_event_timeout() instead, because the timeout
> will allow
> the process to exit if the I2C bus hangs. It's also better to allow
> the
> I2C operation to finish, because unacknowledged I2C operations can
> cause the
> I2C bus to hang.
>
> Signed-off-by: Timur Tabi <timur@freescale.com>
> ---
>
> A similar change should probably be done to i2c-cpm.c, and maybe all
> other
> I2C drivers. Not many use wait_event_interruptible_timeout().
>
> drivers/i2c/busses/i2c-mpc.c | 9 +++------
> 1 files changed, 3 insertions(+), 6 deletions(-)
applied to next
- k
^ permalink raw reply
* RE: Gianfar tx-babbling-errors
From: Scott Coulter @ 2009-02-19 16:38 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev
In-Reply-To: <A543F487-78F9-4791-ABEB-2D8D017A516B@kernel.crashing.org>
>=20
> What specific processor & rev are you running on?
>
I've only been running the modified kernel with the added BUG_ON() code
on the 8568E processor, but I've seen the errors reported on the 8572E
as well.
According to the u-boot startup:
8568E, Version: 1.1, (0x807d0011)
Core: E500, Version: 2.2 (0x80210022)
8572E, Version: 1.1, (0x80e80011)
Core: E500, Version: 3.0 (0x80210030)
Scott
___________________________________________________________________
Scott N. Coulter
Senior Software Engineer
=20
Cyclone Microsystems =20
370 James Street Phone: 203.786.5536 ext. 118
New Haven, CT 06513-3051 Email: scott.coulter@cyclone.com
U.S.A. Web: http://www.cyclone.com
___________________________________________________________________
^ permalink raw reply
* Re: Gianfar tx-babbling-errors
From: Kumar Gala @ 2009-02-19 16:29 UTC (permalink / raw)
To: Scott Coulter; +Cc: linuxppc-dev
In-Reply-To: <43EB80E07C42E1408726E4905FB96B04C07700@CYBORG3.cyclone.com>
On Feb 19, 2009, at 10:17 AM, Scott Coulter wrote:
>
>
> Kumar,
>
>>
>> can't think of any. How about adding a BUG_ON() in the tx path to
>> see
>> if the buffer size > MTU and re-run your tests.
>>
>
> So, here are the checks I've tried in gfar_start_xmit():
>
> BUG_ON(skb->len > DEFAULT_RX_BUFFER_SIZE)
>
> BUG_ON(skb->len > priv->regs->maxfrm)
>
> Neither produces a bug check yet ethtool reports non-zero
> tx-babbling-errors. The last check appears to be the definition of
> tx-babbling-errors. Is there a transmit path that I have missed?
What specific processor & rev are you running on?
- k
^ permalink raw reply
* Re: [PATCH] powerpc/83xx: Do not configure or probe disabled FSL DR USB controllers
From: Kumar Gala @ 2009-02-19 16:19 UTC (permalink / raw)
To: Anton Vorontsov; +Cc: Liu Dave, Andy Fleming, linuxppc-dev
In-Reply-To: <20090219160223.GA2095@oksana.dev.rtsoft.ru>
On Feb 19, 2009, at 10:02 AM, Anton Vorontsov wrote:
> On MPC837X CPUs Dual-Role USB isn't always available (for example DR
> USB pins can be muxed away to eSDHC).
>
> U-Boot adds status = "disabled" property into the DR USB nodes to
> indicate that we must not try to configure or probe Dual-Role USB,
> otherwise we'll break eSDHC support on targets with MPC837X CPUs.
>
> Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
> ---
> arch/powerpc/platforms/83xx/usb.c | 3 ++-
> arch/powerpc/sysdev/fsl_soc.c | 4 ++++
> 2 files changed, 6 insertions(+), 1 deletions(-)
Mind looking at possibly killing the fsl_soc.c usb code and making
the usb a real of-platform driver?
- k
^ permalink raw reply
* Re: mpc8270 and fs_enet
From: James Black @ 2009-02-19 16:18 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev
In-Reply-To: <b77025b40901291527j74705c10y322e8bd8a0828600@mail.gmail.com>
Turns out the problem was with the PSDMR register. We had a cas
latency of 3 and the memory stick required 2. Also, the MPTPR register
had a value of 0x1e00 and we changed it to 0x1f00. We use ECC memory
sticks.
Those 2 changes got rid of the error in the buffer descriptor
ready/empty bits. The interesting thing was that our SDRAM memory test
passes and there are no errors logged in the TESCR1, TESCR2 or the
SDSR registers.
Strange problem, and difficult to find. Thought I'd get this out for
future reference.
On Thu, Jan 29, 2009 at 4:27 PM, James Black <jblack547@gmail.com> wrote:
> I thought the same thing. So I verified the memory map. We did have a
> conflict with the SPI stomping the FCC temp so we moved that. An
> interesting note is that we drop packets from time to time on the MCC
> as well due to a similar ready bit problem. The CPM never clears the
> bit.
>
> ------------------------------------------------------------------
> IMMR memory map
> ------------------------------------------------------------------
>> FCC1 Parameters 0x8400 256
>> FCC1 Temp buffer 0x9000 128
>> SCC1 Parameters 0x8000 256
>> SCC2 Parameters 0x8100 256
>> SCC4 Parameters 0x8300 256
>> SMC1 Parameters 0x0000 64
>> SMC2 Parameters 0x0040 64
>> SCC1 Buff Desc 0x0080 64
>> SCC2 Buff Desc 0x00C0 64
>> SCC4 Buff Desc 0x0100 64
>> SPI Param Pointer 0x89FC 2
>> SPI Parameters 0x9000 76
>> MCC2 Global Param 0x8800 128
>> MCC2 HDLC Param 0x2000 8192
>> MCC2 Extra Param 0xB000 1024
>
>
>
> On Thu, Jan 29, 2009 at 4:05 PM, Scott Wood <scottwood@freescale.com> wrote:
>> James Black wrote:
>>>
>>> I've got an mpc8270 running the fs_enet v1.0 driver and we are having
>>> problems with randomly corrupted tx buffer descriptor ready bits. The
>>> CPM never clears the bit. This is a 2.6.19.2 kernel. We have the same
>>> kernel with the 8260_io driver (kernel is from the denx ELDK4.2)
>>> running on the mpc8250 that works perfect.
>>
>> Is it possible that some other CPM block is configured to use the same DPRAM
>> area that the descriptors are in?
>>
>> -Scott
>>
>
>
>
> --
> Jim Black
> Senior Software Engineer
> Aztek Networks, Inc.
> 2477 55th Street, Suite 202
> Boulder, CO 80301
> www.azteknetworks.com
>
--
Jim Black
Senior Software Engineer
Aztek Networks, Inc.
2477 55th Street, Suite 202
Boulder, CO 80301
www.azteknetworks.com
^ permalink raw reply
* RE: Gianfar tx-babbling-errors
From: Scott Coulter @ 2009-02-19 16:17 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev
In-Reply-To: <6BBF4AB4-FFB0-46ED-B591-17DEC3BE547F@kernel.crashing.org>
Kumar,
>=20
> can't think of any. How about adding a BUG_ON() in the tx path to see
> if the buffer size > MTU and re-run your tests.
>
So, here are the checks I've tried in gfar_start_xmit():
BUG_ON(skb->len > DEFAULT_RX_BUFFER_SIZE)
BUG_ON(skb->len > priv->regs->maxfrm)
Neither produces a bug check yet ethtool reports non-zero
tx-babbling-errors. The last check appears to be the definition of
tx-babbling-errors. Is there a transmit path that I have missed?
Scott
___________________________________________________________________
Scott N. Coulter
Senior Software Engineer
=20
Cyclone Microsystems =20
370 James Street Phone: 203.786.5536 ext. 118
New Haven, CT 06513-3051 Email: scott.coulter@cyclone.com
U.S.A. Web: http://www.cyclone.com
___________________________________________________________________
^ permalink raw reply
* Re: [RFC v1] virtio: add virtio-over-PCI driver
From: Ira Snyder @ 2009-02-19 16:14 UTC (permalink / raw)
To: Zang Roy-R61911
Cc: Arnd Bergmann, Jan-Bernd Themann, netdev, Rusty Russell,
linux-kernel, linuxppc-dev
In-Reply-To: <7DF0AF56456B8F4081E3C44CCCE311DE15199F@zch01exm23.fsl.freescale.net>
On Thu, Feb 19, 2009 at 02:10:08PM +0800, Zang Roy-R61911 wrote:
>
>
> > -----Original Message-----
> > From:
> > linuxppc-dev-bounces+tie-fei.zang=freescale.com@ozlabs.org
> > [mailto:linuxppc-dev-bounces+tie-fei.zang=freescale.com@ozlabs
> > .org] On Behalf Of Ira Snyder
> > Sent: Wednesday, February 18, 2009 6:24 AM
> > To: linux-kernel@vger.kernel.org
> > Cc: linuxppc-dev@ozlabs.org; netdev@vger.kernel.org; Rusty
> > Russell; Arnd Bergmann; Jan-Bernd Themann
> > Subject: [RFC v1] virtio: add virtio-over-PCI driver
> snip
> > diff --git a/drivers/virtio/Kconfig b/drivers/virtio/Kconfig
> > index 3dd6294..efcf56b 100644
> > --- a/drivers/virtio/Kconfig
> > +++ b/drivers/virtio/Kconfig
> > @@ -33,3 +33,25 @@ config VIRTIO_BALLOON
> >
> > If unsure, say M.
> >
> > +config VIRTIO_OVER_PCI_HOST
> > + tristate "Virtio-over-PCI Host support (EXPERIMENTAL)"
> > + depends on PCI && EXPERIMENTAL
> > + select VIRTIO
> > + ---help---
> > + This driver provides the host support necessary for
> > using virtio
> > + over the PCI bus with a Freescale MPC8349EMDS
> > evaluation board.
> > +
> > + If unsure, say N.
> > +
> > +config VIRTIO_OVER_PCI_FSL
> > + tristate "Virtio-over-PCI Guest support (EXPERIMENTAL)"
> > + depends on MPC834x_MDS && EXPERIMENTAL
> > + select VIRTIO
> > + select DMA_ENGINE
> > + select FSL_DMA
> > + ---help---
> > + This driver provides the guest support necessary for
> > using virtio
> > + over the PCI bus.
> > +
> > + If unsure, say N.
> > +
> > diff --git a/drivers/virtio/Makefile b/drivers/virtio/Makefile
> > index 6738c44..f31afaa 100644
> > --- a/drivers/virtio/Makefile
> > +++ b/drivers/virtio/Makefile
> > @@ -2,3 +2,5 @@ obj-$(CONFIG_VIRTIO) += virtio.o
> > obj-$(CONFIG_VIRTIO_RING) += virtio_ring.o
> > obj-$(CONFIG_VIRTIO_PCI) += virtio_pci.o
> > obj-$(CONFIG_VIRTIO_BALLOON) += virtio_balloon.o
> > +obj-$(CONFIG_VIRTIO_OVER_PCI_HOST) += vop_host.o
> > +obj-$(CONFIG_VIRTIO_OVER_PCI_FSL) += vop_fsl.o
> I suppose we need to build the kernel twice. one for vop_host (on host
> with pci enabled) and the
> other is for vop_fsl ( on agent with pci disabled). Is it possible to
> build one image for both host and
> agent. We do not scan the pci bus if the controller is configured to
> agent.
>
You should be able to build a kernel with support for both host and
guest operation, and then use the device tree to switch which driver you
get. The host driver won't be used without a PCI bus, and the guest
driver won't be used without the message unit.
> Also, is it possible to include mpc85xx architecture? They should be
> same.
> There is some code for 85xx in Fresscale BSP.
> http://www.bitshrine.org/gpp/linux-fsl-2.6.23-MPC8568MDS_PCI_Agent_PCIe_
> EP_Drvier.patch
I looked at the cardnet driver before I implemented my PCINet driver. I
hunch it would be rejected for the same reasons, but maybe not. Also, it
makes no use of DMA, which is critical for good transfer speed. Using
memcpy() in PCINet gives performance around 10 mbit/sec, which is
terrible.
I'm sure the driver isn't very hard to port to 85xx, I just don't have
any 85xx boards to test with. The driver only directly interacts with
the messaging unit, which is a pretty simple piece of hardware.
Thanks,
Ira
^ permalink raw reply
* [PATCH] powerpc/83xx: Do not configure or probe disabled FSL DR USB controllers
From: Anton Vorontsov @ 2009-02-19 16:02 UTC (permalink / raw)
To: Kumar Gala; +Cc: Liu Dave, Andy Fleming, linuxppc-dev
On MPC837X CPUs Dual-Role USB isn't always available (for example DR
USB pins can be muxed away to eSDHC).
U-Boot adds status = "disabled" property into the DR USB nodes to
indicate that we must not try to configure or probe Dual-Role USB,
otherwise we'll break eSDHC support on targets with MPC837X CPUs.
Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
---
arch/powerpc/platforms/83xx/usb.c | 3 ++-
arch/powerpc/sysdev/fsl_soc.c | 4 ++++
2 files changed, 6 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/platforms/83xx/usb.c b/arch/powerpc/platforms/83xx/usb.c
index cc99c28..11e1fac 100644
--- a/arch/powerpc/platforms/83xx/usb.c
+++ b/arch/powerpc/platforms/83xx/usb.c
@@ -14,6 +14,7 @@
#include <linux/stddef.h>
#include <linux/kernel.h>
#include <linux/errno.h>
+#include <linux/of.h>
#include <asm/io.h>
#include <asm/prom.h>
@@ -210,7 +211,7 @@ int mpc837x_usb_cfg(void)
int ret = 0;
np = of_find_compatible_node(NULL, NULL, "fsl-usb2-dr");
- if (!np)
+ if (!np || !of_device_is_available(np))
return -ENODEV;
prop = of_get_property(np, "phy_type", NULL);
diff --git a/arch/powerpc/sysdev/fsl_soc.c b/arch/powerpc/sysdev/fsl_soc.c
index 18e49ef..afe8dbc 100644
--- a/arch/powerpc/sysdev/fsl_soc.c
+++ b/arch/powerpc/sysdev/fsl_soc.c
@@ -22,6 +22,7 @@
#include <linux/module.h>
#include <linux/device.h>
#include <linux/platform_device.h>
+#include <linux/of.h>
#include <linux/of_platform.h>
#include <linux/phy.h>
#include <linux/phy_fixed.h>
@@ -328,6 +329,9 @@ static int __init fsl_usb_of_init(void)
struct fsl_usb2_platform_data usb_data;
const unsigned char *prop = NULL;
+ if (!of_device_is_available(np))
+ continue;
+
memset(&r, 0, sizeof(r));
memset(&usb_data, 0, sizeof(usb_data));
--
1.5.6.5
^ permalink raw reply related
* Re: Newby trying to get Ethernet going on MPC83xx series device.
From: Timur Tabi @ 2009-02-19 15:17 UTC (permalink / raw)
To: Dushara Jayasinghe; +Cc: linuxppc-dev@ozlabs.org, Aggrwal Poonam-B10812
In-Reply-To: <DE0CCFFBFF707949BEABD4537A14ACBA0C04B4054B@mailsvr>
On Thu, Feb 19, 2009 at 12:58 AM, Dushara Jayasinghe
<DusharaJ@optiscan.com> wrote:
> I based my board specific file on mpc834x_itx.c which had
>
> static struct of_device_id __initdata mpc834x_itx_ids[] = {
> { .compatible = "fsl,pq2pro-localbus", },
> { .compatible = "simple-bus", },
> {},
> };
>
> Don't know if this is broken?
Actually, it's your device tree that's broken. The above is the right
way to do it. The other way:
static struct of_device_id mpc834x_ids[] = {
{ .type = "soc", },
{ .compatible = "soc", },
{ .compatible = "simple-bus", },
{},
};
is the old way. You're missing a compatible=simple-bus in your device tree.
--
Timur Tabi
Linux kernel developer at Freescale
^ permalink raw reply
* Re: [PATCH] powerpc: New cpu type shows up as "unknown" even when logical PVR is recognized
From: Dave Kleikamp @ 2009-02-19 15:07 UTC (permalink / raw)
To: michael; +Cc: ppc-dev, Paul Mackerras
In-Reply-To: <1234620007.10265.7.camel@localhost>
On Sun, 2009-02-15 at 01:00 +1100, Michael Ellerman wrote:
> On Fri, 2009-02-13 at 14:45 -0600, Dave Kleikamp wrote:
> > When identify_cpu() is called a second time with a logical PVR, it only
> > copies a subset of the cpu_spec structure to avoid overwriting the
> > performance monitor fields that were initialized based on the real PVR.
> >
> > If the real PVR is not recognized, the structure is initialized with
> > default data in which the pvr_mask field is zero. Overriding the default
> > definition with the one based on the logical PVR does not update the
> > pvr_mask field. Since the pvr_mask field remains zero, show_cpuinfo()
> > reports the cpu as "unknown".
> >
> > identify_cpu() should update the pvr_mask, so that show_cpuinfo() reports
> > the logical cpu name, as it would if the kernel recognized the real PVR.
> >
> > For completeness, this patch also updates pvr_value, although its only
> > use appears to be in booke_wdt_init() setting ident.firmware_version. I'm
> > not sure which value (the real or logical) is the most useful here, if it
> > matters at all.
> >
> > Signed-off-by: Dave Kleikamp <shaggy@linux.vnet.ibm.com>
> >
> > diff --git a/arch/powerpc/kernel/cputable.c b/arch/powerpc/kernel/cputable.c
> > index 923f87a..a216fad 100644
> > --- a/arch/powerpc/kernel/cputable.c
> > +++ b/arch/powerpc/kernel/cputable.c
> > @@ -1780,6 +1780,8 @@ struct cpu_spec * __init identify_cpu(unsigned long offset, unsigned int pvr)
> > * performance monitor fields.
> > */
> > if (t->num_pmcs && !s->num_pmcs) {
> > + t->pvr_mask = s->pvr_mask;
> > + t->pvr_value = s->pvr_value;
> > t->cpu_name = s->cpu_name;
> > t->cpu_features = s->cpu_features;
> > t->cpu_user_features = s->cpu_user_features;
>
> Seems like we'd be better off copying the whole structure, and then
> putting back the performance monitor fields. So we don't end up with
> another bug if something's added to struct cpu_spec.
I feel that may be a bit of overkill, but I don't feel strongly either
way. I'd like the patch to be picked up in one fashion or another.
Thanks,
Shaggy
--
David Kleikamp
IBM Linux Technology Center
^ permalink raw reply
* Re: [PATCH v2] Configure PSC4 and PSC5 as UART.
From: Grant Likely @ 2009-02-19 14:23 UTC (permalink / raw)
To: Grzegorz Bernacki; +Cc: linuxppc-dev
In-Reply-To: <499D6805.8040202@semihalf.com>
On Thu, Feb 19, 2009 at 7:09 AM, Grzegorz Bernacki <gjb@semihalf.com> wrote:
> Hi Grant,
>
> Could you tell me when you are going to apply this patch
> and "Defconfig for mpc5200 updates" patch into your repository?
soon. Busy putting out another fire at the moment, but I'll pick it up soon.
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: [PATCH v2] Configure PSC4 and PSC5 as UART.
From: Grzegorz Bernacki @ 2009-02-19 14:09 UTC (permalink / raw)
To: grant.likely; +Cc: linuxppc-dev
In-Reply-To: <12345415932889-git-send-email-gjb@semihalf.com>
Hi Grant,
Could you tell me when you are going to apply this patch
and "Defconfig for mpc5200 updates" patch into your repository?
Thanks,
Grzesiek
^ permalink raw reply
* Re: BUG: MAX_STACK_TRACE_ENTRIES too low!
From: Gary Thomas @ 2009-02-19 13:16 UTC (permalink / raw)
To: Geert Uytterhoeven; +Cc: Linux/PPC Development, Linux Kernel Development
In-Reply-To: <alpine.LRH.2.00.0902191334550.15109@vixen.sonytel.be>
Geert Uytterhoeven wrote:
> When running 2.6.29-rc5+ on PS3 (ppc64), I got the following BUG once during
> bootup:
>
> | Freeing unused kernel memory: 3436k freed
> | BUG: MAX_STACK_TRACE_ENTRIES too low!
> | turning off the locking correctness validator.
> | Call Trace:
> | [c000000006e1b640] [c00000000000f850] .show_stack+0x6c/0x16c (unreliable)
> | [c000000006e1b6f0] [c00000000007cf6c] .save_trace+0xe0/0x108
> | [c000000006e1b780] [c00000000007d058] .add_lock_to_list+0xc4/0x124
> | [c000000006e1b830] [c0000000000816d0] .__lock_acquire+0x13c4/0x17c8
> | [c000000006e1b930] [c000000000081b78] .lock_acquire+0xa4/0xec
> | [c000000006e1b9f0] [c0000000003be034] ._spin_lock+0x34/0x58
> | [c000000006e1ba80] [c0000000000d3e40] .kmem_cache_free+0x84/0x1a8
> | [c000000006e1bb30] [c0000000001f9abc] .idr_remove+0x214/0x248
> | [c000000006e1bbf0] [c00000000002867c] .destroy_context+0x34/0x64
> | [c000000006e1bc80] [c00000000005008c] .__mmdrop+0x4c/0x7c
> | [c000000006e1bd10] [c00000000004de90] .finish_task_switch+0xec/0x14c
> | [c000000006e1bdb0] [c00000000004e6fc] .schedule_tail+0x2c/0xa0
> | [c000000006e1be30] [c000000000007738] .ret_from_fork+0x4/0xcc
> | [c000000006e1be30] [c000000000007738] .ret_from_fork+0x4/0xcc
> | [c000000006e1be30] [c000000000007738] .ret_from_fork+0x4/0xcc
> | [c000000006e1be30] [c000000000007738] .ret_from_fork+0x4/0xcc
> | [c000000006e1be30] [c000000000007738] .ret_from_fork+0x4/0xcc
> | [c000000006e1be30] [c000000000007738] .ret_from_fork+0x4/0xcc
> | [c000000006e1be30] [c000000000007738] .ret_from_fork+0x4/0xcc
> | [c000000006e1be30] [c000000000007738] .ret_from_fork+0x4/0xcc
> | [c000000006e1be30] [c000000000007738] .ret_from_fork+0x4/0xcc
> | [c000000006e1be30] [c000000000007738] .ret_from_fork+0x4/0xcc
> | [c000000006e1be30] [c000000000007738] .ret_from_fork+0x4/0xcc
> | [c000000006e1be30] [c000000000007738] .ret_from_fork+0x4/0xcc
> | [c000000006e1be30] [c000000000007738] .ret_from_fork+0x4/0xcc
> | [c000000006e1be30] [c000000000007738] .ret_from_fork+0x4/0xcc
> | [c000000006e1be30] [c000000000007738] .ret_from_fork+0x4/0xcc
> | [c000000006e1be30] [c000000000007738] .ret_from_fork+0x4/0xcc
> | [c000000006e1be30] [c000000000007738] .ret_from_fork+0x4/0xcc
> | [c000000006e1be30] [c000000000007738] .ret_from_fork+0x4/0xcc
> | [c000000006e1be30] [c000000000007738] .ret_from_fork+0x4/0xcc
> | [c000000006e1be30] [c000000000007738] .ret_from_fork+0x4/0xcc
> | [c000000006e1be30] [c000000000007738] .ret_from_fork+0x4/0xcc
> | [c000000006e1be30] [c000000000007738] .ret_from_fork+0x4/0xcc
> | [c000000006e1be30] [c000000000007738] .ret_from_fork+0x4/0xcc
> | [c000000006e1be30] [c000000000007738] .ret_from_fork+0x4/0xcc
> | [c000000006e1be30] [c000000000007738] .ret_from_fork+0x4/0xcc
> | [c000000006e1be30] [c000000000007738] .ret_from_fork+0x4/0xcc
> | [c000000006e1be30] [c000000000007738] .ret_from_fork+0x4/0xcc
> | [c000000006e1be30] [c000000000007738] .ret_from_fork+0x4/0xcc
> | [c000000006e1be30] [c000000000007738] .ret_from_fork+0x4/0xcc
> | [c000000006e1be30] [c000000000007738] .ret_from_fork+0x4/0xcc
> | [c000000006e1be30] [c000000000007738] .ret_from_fork+0x4/0xcc
> | [c000000006e1be30] [c000000000007738] .ret_from_fork+0x4/0xcc
> | [c000000006e1be30] [c000000000007738] .ret_from_fork+0x4/0xcc
> | [c000000006e1be30] [c000000000007738] .ret_from_fork+0x4/0xcc
> | [c000000006e1be30] [c000000000007738] .ret_from_fork+0x4/0xcc
> | [c000000006e1be30] [c000000000007738] .ret_from_fork+0x4/0xcc
> | [c000000006e1be30] [c000000000007738] .ret_from_fork+0x4/0xcc
> | [c000000006e1be30] [c000000000007738] .ret_from_fork+0x4/0xcc
> | [c000000006e1be30] [c000000000007738] .ret_from_fork+0x4/0xcc
> | [c000000006e1be30] [c000000000007738] .ret_from_fork+0x4/0xcc
> | [c000000006e1be30] [c000000000007738] .ret_from_fork+0x4/0xcc
> | [c000000006e1be30] [c000000000007738] .ret_from_fork+0x4/0xcc
> | [c000000006e1be30] [c000000000007738] .ret_from_fork+0x4/0xcc
> | [c000000006e1be30] [c000000000007738] .ret_from_fork+0x4/0xcc
> | [c000000006e1be30] [c000000000007738] .ret_from_fork+0x4/0xcc
> | [c000000006e1be30] [c000000000007738] .ret_from_fork+0x4/0xcc
> | [c000000006e1be30] [c000000000007738] .ret_from_fork+0x4/0xcc
> | [c000000006e1be30] [c000000000007738] .ret_from_fork+0x4/0xcc
> | [c000000006e1be30] [c000000000007738] .ret_from_fork+0x4/0xcc
> | [c000000006e1be30] [c000000000007738] .ret_from_fork+0x4/0xcc
> | [c000000006e1be30] [c000000000007738] .ret_from_fork+0x4/0xcc
> | [c000000006e1be30] [c000000000007738] .ret_from_fork+0x4/0xcc
> | [c000000006e1be30] [c000000000007738] .ret_from_fork+0x4/0xcc
>
> (There are 65 call trace lines)
>
> After that the system continued.
It looks like the stack trace code got stuck in a loop (the last
53 entries are identical) - increasing the limit won't change this,
it would just keep more entries.
--
------------------------------------------------------------
Gary Thomas | Consulting for the
MLB Associates | Embedded world
------------------------------------------------------------
^ permalink raw reply
* BUG: MAX_STACK_TRACE_ENTRIES too low!
From: Geert Uytterhoeven @ 2009-02-19 12:37 UTC (permalink / raw)
To: Linux/PPC Development; +Cc: Linux Kernel Development
When running 2.6.29-rc5+ on PS3 (ppc64), I got the following BUG once during
bootup:
| Freeing unused kernel memory: 3436k freed
| BUG: MAX_STACK_TRACE_ENTRIES too low!
| turning off the locking correctness validator.
| Call Trace:
| [c000000006e1b640] [c00000000000f850] .show_stack+0x6c/0x16c (unreliable)
| [c000000006e1b6f0] [c00000000007cf6c] .save_trace+0xe0/0x108
| [c000000006e1b780] [c00000000007d058] .add_lock_to_list+0xc4/0x124
| [c000000006e1b830] [c0000000000816d0] .__lock_acquire+0x13c4/0x17c8
| [c000000006e1b930] [c000000000081b78] .lock_acquire+0xa4/0xec
| [c000000006e1b9f0] [c0000000003be034] ._spin_lock+0x34/0x58
| [c000000006e1ba80] [c0000000000d3e40] .kmem_cache_free+0x84/0x1a8
| [c000000006e1bb30] [c0000000001f9abc] .idr_remove+0x214/0x248
| [c000000006e1bbf0] [c00000000002867c] .destroy_context+0x34/0x64
| [c000000006e1bc80] [c00000000005008c] .__mmdrop+0x4c/0x7c
| [c000000006e1bd10] [c00000000004de90] .finish_task_switch+0xec/0x14c
| [c000000006e1bdb0] [c00000000004e6fc] .schedule_tail+0x2c/0xa0
| [c000000006e1be30] [c000000000007738] .ret_from_fork+0x4/0xcc
| [c000000006e1be30] [c000000000007738] .ret_from_fork+0x4/0xcc
| [c000000006e1be30] [c000000000007738] .ret_from_fork+0x4/0xcc
| [c000000006e1be30] [c000000000007738] .ret_from_fork+0x4/0xcc
| [c000000006e1be30] [c000000000007738] .ret_from_fork+0x4/0xcc
| [c000000006e1be30] [c000000000007738] .ret_from_fork+0x4/0xcc
| [c000000006e1be30] [c000000000007738] .ret_from_fork+0x4/0xcc
| [c000000006e1be30] [c000000000007738] .ret_from_fork+0x4/0xcc
| [c000000006e1be30] [c000000000007738] .ret_from_fork+0x4/0xcc
| [c000000006e1be30] [c000000000007738] .ret_from_fork+0x4/0xcc
| [c000000006e1be30] [c000000000007738] .ret_from_fork+0x4/0xcc
| [c000000006e1be30] [c000000000007738] .ret_from_fork+0x4/0xcc
| [c000000006e1be30] [c000000000007738] .ret_from_fork+0x4/0xcc
| [c000000006e1be30] [c000000000007738] .ret_from_fork+0x4/0xcc
| [c000000006e1be30] [c000000000007738] .ret_from_fork+0x4/0xcc
| [c000000006e1be30] [c000000000007738] .ret_from_fork+0x4/0xcc
| [c000000006e1be30] [c000000000007738] .ret_from_fork+0x4/0xcc
| [c000000006e1be30] [c000000000007738] .ret_from_fork+0x4/0xcc
| [c000000006e1be30] [c000000000007738] .ret_from_fork+0x4/0xcc
| [c000000006e1be30] [c000000000007738] .ret_from_fork+0x4/0xcc
| [c000000006e1be30] [c000000000007738] .ret_from_fork+0x4/0xcc
| [c000000006e1be30] [c000000000007738] .ret_from_fork+0x4/0xcc
| [c000000006e1be30] [c000000000007738] .ret_from_fork+0x4/0xcc
| [c000000006e1be30] [c000000000007738] .ret_from_fork+0x4/0xcc
| [c000000006e1be30] [c000000000007738] .ret_from_fork+0x4/0xcc
| [c000000006e1be30] [c000000000007738] .ret_from_fork+0x4/0xcc
| [c000000006e1be30] [c000000000007738] .ret_from_fork+0x4/0xcc
| [c000000006e1be30] [c000000000007738] .ret_from_fork+0x4/0xcc
| [c000000006e1be30] [c000000000007738] .ret_from_fork+0x4/0xcc
| [c000000006e1be30] [c000000000007738] .ret_from_fork+0x4/0xcc
| [c000000006e1be30] [c000000000007738] .ret_from_fork+0x4/0xcc
| [c000000006e1be30] [c000000000007738] .ret_from_fork+0x4/0xcc
| [c000000006e1be30] [c000000000007738] .ret_from_fork+0x4/0xcc
| [c000000006e1be30] [c000000000007738] .ret_from_fork+0x4/0xcc
| [c000000006e1be30] [c000000000007738] .ret_from_fork+0x4/0xcc
| [c000000006e1be30] [c000000000007738] .ret_from_fork+0x4/0xcc
| [c000000006e1be30] [c000000000007738] .ret_from_fork+0x4/0xcc
| [c000000006e1be30] [c000000000007738] .ret_from_fork+0x4/0xcc
| [c000000006e1be30] [c000000000007738] .ret_from_fork+0x4/0xcc
| [c000000006e1be30] [c000000000007738] .ret_from_fork+0x4/0xcc
| [c000000006e1be30] [c000000000007738] .ret_from_fork+0x4/0xcc
| [c000000006e1be30] [c000000000007738] .ret_from_fork+0x4/0xcc
| [c000000006e1be30] [c000000000007738] .ret_from_fork+0x4/0xcc
| [c000000006e1be30] [c000000000007738] .ret_from_fork+0x4/0xcc
| [c000000006e1be30] [c000000000007738] .ret_from_fork+0x4/0xcc
| [c000000006e1be30] [c000000000007738] .ret_from_fork+0x4/0xcc
| [c000000006e1be30] [c000000000007738] .ret_from_fork+0x4/0xcc
| [c000000006e1be30] [c000000000007738] .ret_from_fork+0x4/0xcc
| [c000000006e1be30] [c000000000007738] .ret_from_fork+0x4/0xcc
| [c000000006e1be30] [c000000000007738] .ret_from_fork+0x4/0xcc
| [c000000006e1be30] [c000000000007738] .ret_from_fork+0x4/0xcc
| [c000000006e1be30] [c000000000007738] .ret_from_fork+0x4/0xcc
| [c000000006e1be30] [c000000000007738] .ret_from_fork+0x4/0xcc
(There are 65 call trace lines)
After that the system continued.
With kind regards,
Geert Uytterhoeven
Software Architect
Sony Techsoft Centre Europe
The Corporate Village · Da Vincilaan 7-D1 · B-1935 Zaventem · Belgium
Phone: +32 (0)2 700 8453
Fax: +32 (0)2 700 8622
E-mail: Geert.Uytterhoeven@sonycom.com
Internet: http://www.sony-europe.com/
A division of Sony Europe (Belgium) N.V.
VAT BE 0413.825.160 · RPR Brussels
Fortis · BIC GEBABEBB · IBAN BE41293037680010
^ permalink raw reply
* Re: Regarding irq_of_parse_and_map
From: Vijay Nikam @ 2009-02-19 11:51 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Scott Wood
In-Reply-To: <20090218165724.GA26391@ld0162-tx32.am.freescale.net>
> Because dtc will generate phandles automatically when you reference the
> node with the & operator.
Yes the same statement I found in dts-bindings for gpio txt, sorry I
missed it somehow ...
> Do you want your changes to ever make it into the upstream kernel?
Yes I would like to do that ... but the reason I asked is as it is my
first try so I am thinking that I will edit the same file and do it in
the same way ofcourse I will follow for device node gpio-controller
the new apporach and later if it works then I will create new dts with
upstream Linux base ...
Now I have created the mpc8313erdb.dts with gpio-controller device
node. I would like to ask that now I should compile it with dtc and
generate dtb and I should load this dtb on board/target, Right ? ? ?
please correct me if I am wrong ...
Also is it possible to compile device tree on Linux host and genreate
dtb for powerpc ? ? ? If yes, then how ? ? ? please let me know ...
thanks ...
Before I tried to generate virtual irq using irq_create_mapping and I
got the same number as hw_irq_no i.e. 74 as virtual irq. Also the
entry was made in proc/interrupts and trigger was 8 (Level). But when
I tried to interrupt and the handler was never called ? ? ? Was it
because of gpio device node missing in device tree ? ? ? please let me
know ... thanks ...
Kindly please acknowledge ... thank you ...
Kind Regards,
Vijay Nikam
On 2/18/09, Scott Wood <scottwood@freescale.com> wrote:
> On Wed, Feb 18, 2009 at 05:31:34PM +0530, Vijay Nikam wrote:
> > > Don't specify this explicitly. Please base new development off of the
> > > device tree that is in upstream Linux, not the very old tree in your BSP.
> >
> > May I know the reason why I should not specify it explicitly ? ? ?
>
> Because dtc will generate phandles automatically when you reference the
> node with the & operator.
>
> > Also what would be the problem if I do in the same way as it is given
> > in BSP mpc8313erdb.dts ? ? ?
>
> Do you want your changes to ever make it into the upstream kernel?
>
> > And should I use gpio-controller as a gpio device node ? ? ?
>
> Yes, the node should label itself as a gpio controller.
>
> -Scott
>
^ permalink raw reply
* [PATCH] ehea: Fix memory hotplug handling
From: Thomas Klein @ 2009-02-19 11:32 UTC (permalink / raw)
To: Jeff Garzik
Cc: Jan-Bernd Themann, netdev, Hannes Hering, linux-kernel, linux-ppc,
Christoph Raisch
Added missing set_bit() to disable data transfer when a memchange notification is handled
Signed-off-by: Thomas Klein <tklein@de.ibm.com>
---
diff -Nurp -X dontdiff linux-2.6.29-rc4/drivers/net/ehea/ehea.h patched_kernel/drivers/net/ehea/ehea.h
--- linux-2.6.29-rc4/drivers/net/ehea/ehea.h 2009-02-18 16:59:54.000000000 +0100
+++ patched_kernel/drivers/net/ehea/ehea.h 2009-02-18 17:01:12.000000000 +0100
@@ -40,7 +40,7 @@
#include <asm/io.h>
#define DRV_NAME "ehea"
-#define DRV_VERSION "EHEA_0098"
+#define DRV_VERSION "EHEA_0099"
/* eHEA capability flags */
#define DLPAR_PORT_ADD_REM 1
diff -Nurp -X dontdiff linux-2.6.29-rc4/drivers/net/ehea/ehea_main.c patched_kernel/drivers/net/ehea/ehea_main.c
--- linux-2.6.29-rc4/drivers/net/ehea/ehea_main.c 2009-02-18 16:59:54.000000000 +0100
+++ patched_kernel/drivers/net/ehea/ehea_main.c 2009-02-18 17:01:12.000000000 +0100
@@ -3517,12 +3517,14 @@ static int ehea_mem_notifier(struct noti
/* Readd canceled memory block */
case MEM_ONLINE:
ehea_info("memory is going online");
+ set_bit(__EHEA_STOP_XFER, &ehea_driver_flags);
if (ehea_add_sect_bmap(arg->start_pfn, arg->nr_pages))
return NOTIFY_BAD;
ehea_rereg_mrs(NULL);
break;
case MEM_GOING_OFFLINE:
ehea_info("memory is going offline");
+ set_bit(__EHEA_STOP_XFER, &ehea_driver_flags);
if (ehea_rem_sect_bmap(arg->start_pfn, arg->nr_pages))
return NOTIFY_BAD;
ehea_rereg_mrs(NULL);
^ permalink raw reply
* Re: [RFC v1] virtio: add virtio-over-PCI driver
From: Rusty Russell @ 2009-02-19 11:18 UTC (permalink / raw)
To: Ira Snyder
Cc: linuxppc-dev, netdev, linux-kernel, Arnd Bergmann,
Jan-Bernd Themann
In-Reply-To: <20090218163835.GA29728@ovro.caltech.edu>
On Thursday 19 February 2009 03:08:35 Ira Snyder wrote:
> On Wed, Feb 18, 2009 at 05:13:03PM +1030, Rusty Russell wrote:
> > don't restrict yourself to 32 feature bits (only PCI does this, and they're
> > going to have to hack when we reach feature 32).
>
> There isn't any problem adding more feature bits. Do you think 128 bits
> is enough?
Probably. We have unlimited bits in lguest and s390, but 128 is reasonable
for the forseeable future (if not, you end up using bit 128 to mean "look
somewhere else for the rest of the bits).
> > How about prepending a 4 byte length on the host buffers? Allows host to
> > specify length (for host->guest), and guest writes it to allow truncated
> > buffers on guest->host.
> >
> > That won't allow you to transfer *more* than one buffersize to the host, but
> > you could use a different method (perhaps the 4 bytes indicates the *total*
> > length?).
>
> I don't understand how this will help.
>
> I looked at virtio_net's implemention with VIRTIO_NET_F_MRG_RXBUF, which
> seems like it could really help performance. The problems with that are:
> 1) virtio_net doesn't write the merged header's num_buffers field
> 2) virtio_net doesn't actually split packets in xmit
...
> I'm using two instances of virtio_net to talk to each other, rather than
> a special userspace implementation like lguest and kvm use. Is this a
> good approach?
Well, virtio in general is guest-host asymmetric. I originally explored
symmetry, but it didn't seem to offer any concrete advantages, so we didn't
require it. You aren't actually directly connecting two guests, are you?
So this is just a simplification for your implementation?
You could always add a VIRTIO_NET_F_MRG_TXBUF which did what you want, but
note that symmetry breaks down for other virtio uses, too: block definitely
isn't symmetric of course, but I haven't audited the others.
So I'd recommend asymmetry; hack your host to understand chained buffers.
Cheers,
Rusty.
^ permalink raw reply
* Re: [git pull] for both tip and powerpc
From: Ingo Molnar @ 2009-02-19 11:14 UTC (permalink / raw)
To: Steven Rostedt
Cc: linuxppc-dev, Andrew Morton, LKML, Frédéric Weisbecker
In-Reply-To: <alpine.DEB.1.10.0902181408160.11411@gandalf.stny.rr.com>
* Steven Rostedt <rostedt@goodmis.org> wrote:
> Ingo and Benjamin,
>
> As discussed, I made a branch called mainline/function-graph-tracer
> based off of Linus's commit:
>
> commit d2f8d7ee1a9b4650b4e43325b321801264f7c37a
> Author: Linus Torvalds <torvalds@linux-foundation.org>
> Date: Fri Feb 13 15:31:30 2009 -0800
>
> Linux 2.6.29-rc5
>
>
> and cherry picked the below change. I added Ingo's Acked-by as well. If
> both of you pull this change in (assuming both trees are already based
> off of Linus's 2.6.29-rc5) then there should be no conflicts when this
> gets merged back to Linus's tree.
>
> I will not touch this branch again, until it is officially in mainline.
>
> Please pull the latest mainline/function-graph tree, which can be found at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-2.6-trace.git
> mainline/function-graph
>
>
> Steven Rostedt (1):
> tracing/function-graph-tracer: make arch generic push pop functions
>
> ----
> arch/x86/include/asm/ftrace.h | 25 -----------
> arch/x86/kernel/dumpstack.c | 1 +
> arch/x86/kernel/ftrace.c | 75 +---------------------------------
> include/linux/ftrace.h | 24 +++++++++++
> kernel/trace/trace_functions_graph.c | 75 ++++++++++++++++++++++++++++++++++
> 5 files changed, 101 insertions(+), 99 deletions(-)
Pulled into tip:tracing/function-graph-tracer, thanks Steve!
Ingo
^ 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