* Re: Please pull linux-2.6-mpc52xx.git
From: Grant Likely @ 2008-03-17 23:43 UTC (permalink / raw)
To: Wolfgang Denk; +Cc: linuxppc-dev
In-Reply-To: <20080317222836.AFA66241A2@gemini.denx.de>
On Mon, Mar 17, 2008 at 4:28 PM, Wolfgang Denk <wd@denx.de> wrote:
> In message <fa686aa40803171443q7a53f0balbb49740116c6552@mail.gmail.com> you wrote:
>
> * The TQM5200 configuration as provided is intended for shipping as
> default configuration for this board. The "engineer responsible"
> already *did* the tailoring and put that state in the defconfig
> file.
>
> * The CM5200 and Motion-Pro boards are custom designs, where the
> defconfig file matches exactly the requirements of the respective
> customers.
>
> I feel it is very important to be able to include this configuration
> information somewhere with the kernel source tree - and to me the
> defconfig file for a board is the most natural place to put such
> information.
(copied from my comments in an off-list conversation)
However, I have declined (for now) to pick up the defconfigs for those
boards and instead merged in the config features they require into the
mpc5200 defconfig. My primary reason for doing so is to increase the
likelyhood that full featured kernels are built and tested so that
situations where board ports conflict with each other are caught and
fixed.
ojn has also been complaining about the number of defconfigs he needs
to build to test all the powerpc configurations without any
indications about which ones are important and which ones are not.
There has been some discussion about having a subdirectory for
optimized board configs, but nobody has done anything about it yet.
The one part that I have a really strong opinion on is that there
should be a full featured mpc5200 defconfig for build testing. Beyond
that (and if ojn can also be appeased) I can probably be convinced. :-)
> > All these boards are supported with
> > arch/powerpc/platforms/mpc5200_simple.c. A kernel built for that
> > platform will boot on any of those boards as long as it is passed the
> > correct device tree.
>
> I don't doubt that the kernel will boot. But that does not mean that
> it is ready for use for the intended purpose. For example,
> arch/powerpc/platforms/52xx/motionpro.c contains code to setup some
> custom LEDs on this board. I can't find that code in
>
> arch/powerpc/platforms/mpc5200_simple.c.
>
> It may be argued that this code should be moved somewhere else, but I
> don't remeber to have seen any such review comments.
The LED code just hasn't been picked up. IIRC, it was reworked to
make it a proper driver in drivers/leds. I need to look at it again,
but it is a lot of code for a very simple thing and I wasn't sure if I
should be the one to pick it up because it is in drivers/leds which
has a different maintainer.
Cheers,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: [PATCH] [POWERPC] 83xx: MPC837xRDB's VSC7385 ethernet switch isn't on the MDIO bus
From: Joakim Tjernlund @ 2008-03-17 23:53 UTC (permalink / raw)
To: Timur Tabi; +Cc: linuxppc-dev
In-Reply-To: <47DEF9E7.5030808@freescale.com>
On Mon, 2008-03-17 at 18:08 -0500, Timur Tabi wrote:
> Joakim Tjernlund wrote:
>
> > eth0 is also up, was it commit 4942bd80e83d13bf394df4a8109bee39d861820f
> > that fixed that bug?
>
> Yep. Unfortunately, I don't really know enough about the ucc_geth driver to
> know what could be wrong. I just noticed your message and remembered that old bug.
>
I noticed that ugeth_graceful_stop_rx() is lacking in_8()/out_8() so I
am adding that, but I cant test until tmw.
Also notice that there is a lot of in_beX()/out_beX() in the driver and
those functions use the sync instruction. Won't that much suny usage
hurt performance and is sync really needed?
Jocke
^ permalink raw reply
* Re: [PATCH] net: NEWEMAC: Support for Pause packets in EMAC driver
From: Benjamin Herrenschmidt @ 2008-03-17 23:55 UTC (permalink / raw)
To: Jeff Garzik; +Cc: netdev, Stefan Roese, linuxppc-dev
In-Reply-To: <47DEF159.3020504@garzik.org>
On Mon, 2008-03-17 at 18:31 -0400, Jeff Garzik wrote:
> > Jeff, do you mind if we get those patches through the powerpc tree ?
> > EMAC is very powerpc specific and these are mostly internal driver
> > cuisine.
>
> Fine with me in concept, though I haven't seen the patches in
> question.
Yup, I've asked people to copy you on them so you get a chance to ack
them :-)
Cheers,
Ben.
^ permalink raw reply
* Re: [PATCH v2] pasemi_dma: Driver for PA Semi PWRficient on-chip DMAengine
From: Olof Johansson @ 2008-03-18 0:21 UTC (permalink / raw)
To: Nelson, Shannon
Cc: hskinnemoen, Sosnowski, Maciej, linux-kernel, linuxppc-dev,
pasemi-linux, Williams, Dan J
In-Reply-To: <BAE9DCEF64577A439B3A37F36F9B691C043E6716@orsmsx418.amr.corp.intel.com>
Hi,
On Mon, Mar 17, 2008 at 01:34:05PM -0700, Nelson, Shannon wrote:
> In the future please copy Maciej as one of "the DMA guys" as he has
> taken over ioatdma for me. Beyond that, one little picky comment
> below...
Time to set up a list, or have everyone monitor lkml, I'd say. I'd
prefer the former.
> >+static unsigned int channels = 4;
> >+module_param(channels, uint, S_IRUGO);
> >+MODULE_PARM_DESC(channels, "Number of channels for copy
> >(default: 2)");
>
> Is the number of channels defaulting to 2 or 4?
Ah, yes, good catch.
-Olof
^ permalink raw reply
* Re: Please pull linux-2.6-mpc52xx.git
From: Wolfgang Denk @ 2008-03-18 0:26 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-dev
In-Reply-To: <fa686aa40803171643y7db21cadsc454a713ba6c4342@mail.gmail.com>
Dear Grant,
in message <fa686aa40803171643y7db21cadsc454a713ba6c4342@mail.gmail.com> you wrote:
>
> However, I have declined (for now) to pick up the defconfigs for those
> boards and instead merged in the config features they require into the
> mpc5200 defconfig. My primary reason for doing so is to increase the
> likelyhood that full featured kernels are built and tested so that
> situations where board ports conflict with each other are caught and
> fixed.
I know what you mean, and I agree with the idea.
Unfortunately I think it's impossible to implement, especially on such
embedded processors with their high level of pin multiplexing.
For example, if you want to include testing of the FEC ethernet
driver, you will probably fail to test the second USB port. I think
it's simply not possible to test all possible options in a single
kernel configuration - first it doesn't work (for example because of
pin multiplexing issues), second you will likely not be able to find
hardware that implements all features at once.
My dream is to have a distributed test environment - a framework
which can be used for automatic testing which includes building and
running the code on a set of systems, and which will then report the
test results to a central location.
We have the same problem (probably to a much higher degree) in
U-Boot; nobody can test all board configurations because nobody has
all the cross-tools installed nor the 500+ boards available.
> ojn has also been complaining about the number of defconfigs he needs
> to build to test all the powerpc configurations without any
> indications about which ones are important and which ones are not.
again, some distributed test tool might help - we would get not only
information abouyt test results, but also which configurations have
been tested how frequently.
> There has been some discussion about having a subdirectory for
> optimized board configs, but nobody has done anything about it yet.
Is this a hint?
> The one part that I have a really strong opinion on is that there
> should be a full featured mpc5200 defconfig for build testing. Beyond
> that (and if ojn can also be appeased) I can probably be convinced. :-)
Maybe my expectations for "full featured' are just too high..
> The LED code just hasn't been picked up. IIRC, it was reworked to
> make it a proper driver in drivers/leds. I need to look at it again,
> but it is a lot of code for a very simple thing and I wasn't sure if I
> should be the one to pick it up because it is in drivers/leds which
> has a different maintainer.
I see. Thanks.
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
If some day we are defeated, well, war has its fortunes, good and
bad.
-- Commander Kor, "Errand of Mercy", stardate 3201.7
^ permalink raw reply
* Re: [PATCH v2] Force 4K pages for IO addresses.
From: Olof Johansson @ 2008-03-18 0:34 UTC (permalink / raw)
To: Tony Breeds
Cc: LinuxPPC-dev, Jan-Bernd Themann, Paul Mackerras, Stephen Rothwell
In-Reply-To: <20080317035419.GH6887@bakeyournoodle.com>
On Mon, Mar 17, 2008 at 02:54:19PM +1100, Tony Breeds wrote:
> Currently HEA requires 4K pages for IO resources. Just set the pages size to
> IO to 4K.
Well, that's too bad. Why penalize all platforms for it?
I.e.: Nack, we use 64K iopages on pa6t and it works well. No need to
waste tlb and erat space.
-Olof
^ permalink raw reply
* Re: [PATCH v2] pasemi_dma: Driver for PA Semi PWRficient on-chip DMA engine
From: Olof Johansson @ 2008-03-18 0:27 UTC (permalink / raw)
To: Dan Williams
Cc: linuxppc-dev, pasemi-linux, shannon.nelson, linux-kernel,
hskinnemoen
In-Reply-To: <e9c3a7c20803171146m5a7f0e11m31e074634de22b42@mail.gmail.com>
On Mon, Mar 17, 2008 at 11:46:39AM -0700, Dan Williams wrote:
> Looks good, makes me want to go back and cleanup iop-adma a bit. A
> few fyi's below, but no other review comments.
>
> > Note that this still needs to go on top of the powerpc.git tree due to the
> > pasemi_dma.h updates that this driver depends on. I suggest merging this
> > through pasemi.git->powerpc.git->linus with an Acked-by from the DMA guys.
>
> Ok, it still may not compile in mainline until after 2.6.26-rc1 due to
> additional dmaengine cleanups like the ack-to-flags change I posted
> earlier. Any better way to handle this? Go through -mm?
Either go through -mm where Andrew can keep it applied in appropriate
order and send upstream, or just merge it late. It's a new driver, and
they're normally OK to go in a little later. That might be the easiest
solution in this case.
> Acked-by: Dan Williams <dan.j.williams@intel.com>
Thanks!
-Olof
^ permalink raw reply
* Re: [Patch] 8xx: MGSUVD support
From: Vitaly Bordug @ 2008-03-18 0:27 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev, hs
In-Reply-To: <20080317223821.GA3622@loki.buserror.net>
On Mon, 17 Mar 2008 17:38:21 -0500
Scott Wood wrote:
> On Sun, Mar 09, 2008 at 07:59:14PM +0300, Vitaly Bordug wrote:
> > I would like all the comments to be consistent C style (because
> > that's it for the most other dts'es).
>
> $ fgrep -rI // arch/powerpc/boot/dts/ | wc -l
> 539
>
So, we should go ahead and add a bit more hassle :) ?
By consistent C style I mean:
+ clock-frequency = <0>; /* Filled in by u-boot */ */
+ interrupts = <f 2>; // decrementer interrupt
using either one or other way for same-type comments.
-Vitaly
^ permalink raw reply
* Re: [PATCH] Fix PMU + soft interrupt disable bug
From: Olof Johansson @ 2008-03-18 0:36 UTC (permalink / raw)
To: Anton Blanchard; +Cc: linuxppc-dev, paulus
In-Reply-To: <20080317042709.GA10594@kryten>
On Sun, Mar 16, 2008 at 11:27:09PM -0500, Anton Blanchard wrote:
>
> Since the PMU is an NMI now, it can come at any time we are only soft
> disabled. We must hard disable around the two places we allow the kernel
> stack SLB and r1 to go out of sync. Otherwise the PMU exception can
> force a kernel stack SLB into another slot.
>
> Signed-off-by: Anton Blanchard <anton@samba.org>
Acked-by: Olof Johansson <olof@lixom.net>
This fixes some problems we've seen with multi-slb hits when running
oprofile.
^ permalink raw reply
* Re: [PATCH] net: NEWEMAC: Support for Pause packets in EMAC driver
From: Josh Boyer @ 2008-03-18 1:08 UTC (permalink / raw)
To: Jeff Garzik; +Cc: linuxppc-dev, Stefan Roese, netdev
In-Reply-To: <47DEF159.3020504@garzik.org>
On Mon, 17 Mar 2008 18:31:53 -0400
Jeff Garzik <jeff@garzik.org> wrote:
> Benjamin Herrenschmidt wrote:
> >> There's also the section mismatch patch I sent you. I don't care who's
> >> tree they go through, but I'd need to know either way so keep me in the
> >> loop please.
> >
> > Jeff, do you mind if we get those patches through the powerpc tree ?
> > EMAC is very powerpc specific and these are mostly internal driver
> > cuisine.
>
> Fine with me in concept, though I haven't seen the patches in question.
http://marc.info/?l=linux-netdev&m=120449748701492&w=2
I sent it to Ben with netdev on CC because you asked the various people
sending NEWEMAC patches to you to find a single person.
So from now on, what are we going to do? It seems we're playing net
maintainer russian roulette for NEWEMAC and it's getting old.
josh
^ permalink raw reply
* Re: [PATCH 1/4] Emerson ATCA-C125 bootwrapper
From: David Gibson @ 2008-03-18 1:28 UTC (permalink / raw)
To: Alexandr Smirnov; +Cc: linuxppc-dev
In-Reply-To: <47DE61E1.6060300@ru.mvista.com>
On Mon, Mar 17, 2008 at 03:19:45PM +0300, Alexandr Smirnov wrote:
> David,
>>> + /* Unfortunately, the specific model number is encoded in the
>>> + * soc node name in existing dts files -- once that is fixed,
>>> + * this can do a simple path lookup.
>>> + */
>>>
>>
>> Since this is a new board, couldn't you name the soc node /soc and
>> dispense with this more complicated way of doing things? Or would
>> that break other versions of u-boot that are in use?
>>
> As I understand you would like to rename /soc8548 node to /soc and make a
> simple path lookup like following:
> - soc = find_node_by_devtype(NULL, "soc");
> + soc = finddevice("/soc");
> Is this correct?
That's right.
> But fsl_soc code still uses of_find_node_by_type so we can't remove
> device_type property from node /soc and therefor simplify device
> tree.
It does? Grrr... I thought that had been fixed and the only reason
the device_type was still needed was because some u-boot versions
needed it. But you're right, that's not the case.
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
* RE: XUPV2P board opb_emac cannot work with linux-2.6-xlnx
From: Qin Lin @ 2008-03-18 2:03 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <20080317155805.1FFB6538064@mail141-sin.bigfish.com>
Hi Steve,
I think the booting message tell me that the interrupt line is connect
OK,isn't it ?
> [ 1.151038] eth0: Xilinx 10/100 EMAC at 0x40C00000 mapped to
0xD0020000, irq=2
and if you can tell me what should be care about in hard design and in
kernel config with net?
Stephen Neuendorffer wrote:
>
>
> It should... (I use it regularly on the xup board)
> Did you remember to connect the interrupt line in your design?
>
> Steve
>
> .....
>> [ 1.151038] eth0: Xilinx 10/100 EMAC at 0x40C00000 mapped to
> 0xD0020000, irq=2
> ......
>
--
View this message in context: http://www.nabble.com/XUPV2P-board-opb_emac-cannot-work-with-linux-2.6-xlnx-tp16089631p16112213.html
Sent from the linuxppc-embedded mailing list archive at Nabble.com.
^ permalink raw reply
* RE: XUPV2P board opb_emac cannot work with linux-2.6-xlnx
From: Qin Lin @ 2008-03-18 2:17 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <20080317155805.1FFB6538064@mail141-sin.bigfish.com>
HI Steve:
when i design the system ,i chose opb_emac_1.04a ,No DMA, Use interrupt ?
Is it the correct setting for the current driver?
Thanks
Stephen Neuendorffer wrote:
>
>
> It should... (I use it regularly on the xup board)
> Did you remember to connect the interrupt line in your design?
>
> Steve
>
>> -----Original Message-----
>> From: linuxppc-embedded-bounces+stephen=neuendorffer.name@ozlabs.org
> [mailto:linuxppc-embedded-
>> bounces+stephen=neuendorffer.name@ozlabs.org] On Behalf Of Qin Lin
>> Sent: Monday, March 17, 2008 12:36 AM
>> To: linuxppc-embedded@ozlabs.org
>> Subject: XUPV2P board opb_emac cannot work with linux-2.6-xlnx
>>
>>
>> HI all,
>>
>> Is anyone have the opb_emac (no DMA) work with the kernel
> linux-2.6-xlnx
>> from git.xilinx.com.
>> the message seams that it does work ,but the command ping return
> nothing!
>>
>> Could you kindly suggest me what to do?
>>
>> ps:
>> the kernel booting message
>> [ 0.258674] net_namespace: 64 bytes
>> [ 0.269780] NET: Registered protocol family 16
>> [ 0.290415] Registering device xilinx_emac:0
>> [ 0.381687] NET: Registered protocol family 2
>> [ 0.392324] IP route cache hash table entries: 2048 (order: 1, 8192
>> bytes)
>> [ 0.399556] TCP established hash table entries: 8192 (order: 4,
> 65536
>> bytes)
>> [ 0.403403] TCP bind hash table entries: 8192 (order: 3, 32768
> bytes)
>> [ 0.405409] TCP: Hash tables configured (established 8192 bind
> 8192)
>> [ 0.405489] TCP reno registered
>> [ 0.412758] sysctl table check failed: /kernel/l2cr .1.31 Missing
>> strategy
>> [ 0.413189] Call Trace:
>> [ 0.413244] [cf41feb0] [c0008178] show_stack+0x48/0x184
> (unreliable)
>> [ 0.413467] [cf41fed0] [c00303c8] set_fail+0x50/0x68
>> [ 0.413640] [cf41fef0] [c0030b54] sysctl_check_table+0x64c/0x698
>> [ 0.413724] [cf41ff20] [c0030b68] sysctl_check_table+0x660/0x698
>> [ 0.413802] [cf41ff50] [c001e810] register_sysctl_table+0x64/0xb4
>> [ 0.414141] [cf41ff70] [c01e4b1c]
> register_ppc_htab_sysctl+0x18/0x2c
>> [ 0.414311] [cf41ff80] [c01de1e4] kernel_init+0xc8/0x284
>> [ 0.414384] [cf41fff0] [c0004ab8] kernel_thread+0x44/0x60
>>
>> [ 1.116395] xilinx_emac xilinx_emac.0: MAC address is now 2: 0: 0:
> 0: 0:
>> 0
>> [ 1.123790] XEmac: using fifo mode.
>> [ 1.128188] XEmac: Detected PHY at address 0, ManufID 0x0013, Rev.
>> 0x78e2.
>> [ 1.135715] eth0: Dropping NETIF_F_SG since no checksum feature.
>> [ 1.151038] eth0: Xilinx 10/100 EMAC at 0x40C00000 mapped to
> 0xD0020000,
>> irq=2
>> [ 1.158713] eth0: XEmac id 1.4a, block id 128, type 1
>> [ 1.194661] TCP cubic registered
>> [ 1.198647] NET: Registered protocol family 1
>> [ 1.203728] NET: Registered protocol family 17
>>
>>
>> #ping 192.168.26.1 &
>> # ifconfig eth0
>> eth0 Link encap:Ethernet HWaddr 02:00:00:00:00:00
>> inet addr:192.168.26.127 Bcast:192.168.26.255
> Mask:255.255.255.0
>> UP BROADCAST RUNNING MTU:1500 Metric:1
>> RX packets:0 errors:0 dropped:0 overruns:0 frame:0
>> TX packets:16 errors:0 dropped:0 overruns:0 carrier:0
>> collisions:0 txqueuelen:1000
>> RX bytes:0 (0.0 B) TX bytes:672 (672.0 B)
>> Interrupt:2 Memory:40c00000-40c0ffff
>>
>> Regards
>>
>> Qin Lin
>> --
>> View this message in context:
> http://www.nabble.com/XUPV2P-board-opb_emac-cannot-work-with-linux-2.6-
>> xlnx-tp16089631p16089631.html
>> Sent from the linuxppc-embedded mailing list archive at Nabble.com.
>>
>> _______________________________________________
>> Linuxppc-embedded mailing list
>> Linuxppc-embedded@ozlabs.org
>> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
>
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
>
--
View this message in context: http://www.nabble.com/XUPV2P-board-opb_emac-cannot-work-with-linux-2.6-xlnx-tp16089631p16112415.html
Sent from the linuxppc-embedded mailing list archive at Nabble.com.
^ permalink raw reply
* Re: Please pull linux-2.6-mpc52xx.git
From: Grant Likely @ 2008-03-18 2:42 UTC (permalink / raw)
To: Wolfgang Denk; +Cc: linuxppc-dev
In-Reply-To: <20080318002650.AE701246C5@gemini.denx.de>
On Mon, Mar 17, 2008 at 6:26 PM, Wolfgang Denk <wd@denx.de> wrote:
> Dear Grant,
>
>
> in message <fa686aa40803171643y7db21cadsc454a713ba6c4342@mail.gmail.com> you wrote:
> >
> > However, I have declined (for now) to pick up the defconfigs for those
> > boards and instead merged in the config features they require into the
> > mpc5200 defconfig. My primary reason for doing so is to increase the
> > likelyhood that full featured kernels are built and tested so that
> > situations where board ports conflict with each other are caught and
> > fixed.
>
> I know what you mean, and I agree with the idea.
>
> Unfortunately I think it's impossible to implement, especially on such
> embedded processors with their high level of pin multiplexing.
>
> For example, if you want to include testing of the FEC ethernet
> driver, you will probably fail to test the second USB port. I think
> it's simply not possible to test all possible options in a single
> kernel configuration - first it doesn't work (for example because of
> pin multiplexing issues), second you will likely not be able to find
> hardware that implements all features at once.
I don't think this example really applies. Yes, I agree that I cannot
test all the functions, but that does not preclude building in all the
drivers and making sure that they don't cause a conflict by just being
present. For instance, I can build a single kernel image right now
that should boot and fully run on the Efika, lite5200, tqm and motion
pro boards (although the Efika has a different wrapper). I can only
test it on the Efika and lite5200 boards and I have to rely on other
people for the boards I don't have. If it breaks; I expect to receive
an irate email in my Inbox telling me to fix it!
pin multiplexing shouldn't be an issue at all. Only the devices which
are instantiated in the device tree will actually get initialized so
if the pins aren't hooked up then it shouldn't be in the tree.
Ideally, the bootloader should take care of the pin multiplexing
setup, but even if it doesn't it can be setup by platform code and
CONFIG_MULTIPLATFORM supports building multiple platforms into a
single image (within a processor family of course; you can't build a
405+6xx multiplatform kernel.) tqm, motionpro and cm boards can all
use simple platform because they all have good firmware ports that
setup the hardware correctly in the first place. lite5200(b) does not
because there are quite a few lite5200 boards 'in the wild' with
firmware that doesn't setup the board the way it should be (or at
least the way Linux likes it).
> > There has been some discussion about having a subdirectory for
> > optimized board configs, but nobody has done anything about it yet.
>
> Is this a hint?
Oh, probably. :-)
Cheers,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: [PATCH] net: NEWEMAC: Support for Pause packets in EMAC driver
From: Benjamin Herrenschmidt @ 2008-03-18 2:41 UTC (permalink / raw)
To: Josh Boyer; +Cc: netdev, Stefan Roese, Jeff Garzik, linuxppc-dev
In-Reply-To: <20080317200855.2954971a@zod.rchland.ibm.com>
> http://marc.info/?l=linux-netdev&m=120449748701492&w=2
>
> I sent it to Ben with netdev on CC because you asked the various people
> sending NEWEMAC patches to you to find a single person.
>
> So from now on, what are we going to do? It seems we're playing net
> maintainer russian roulette for NEWEMAC and it's getting old.
I'm happy to collect the patches. I said I would do it, I was just taken
aback a bit by Jeff suddenly merging two of Stefan patches directly :-)
I was actually planning this week to post a serie of all the pending
EMAC patches for final review.
Cheers,
Ben.
^ permalink raw reply
* Re: [PATCH v2] Force 4K pages for IO addresses.
From: Benjamin Herrenschmidt @ 2008-03-18 2:43 UTC (permalink / raw)
To: Olof Johansson
Cc: LinuxPPC-dev, Stephen Rothwell, Paul Mackerras, Jan-Bernd Themann
In-Reply-To: <20080318003434.GA671@lixom.net>
On Mon, 2008-03-17 at 19:34 -0500, Olof Johansson wrote:
> On Mon, Mar 17, 2008 at 02:54:19PM +1100, Tony Breeds wrote:
> > Currently HEA requires 4K pages for IO resources. Just set the pages size to
> > IO to 4K.
>
> Well, that's too bad. Why penalize all platforms for it?
>
> I.e.: Nack, we use 64K iopages on pa6t and it works well. No need to
> waste tlb and erat space.
We would have to make that pSeries specific for now I suppose...
We don't have a way to know that there "can" be an EHEA right ? It may
not be in the device-tree at boot and dynamically added to the
partition... And we can't dynamically "demote" the ioremap area like we
do for userspace as we have no tracking of bolted entries hashed in
early during boot (I plan to fix that but that will take a while).
Cheers,
Ben.
^ permalink raw reply
* dtc: Change exit code for usage message
From: David Gibson @ 2008-03-18 3:04 UTC (permalink / raw)
To: Jon Loeliger; +Cc: linuxppc-dev
If dtc's command line arguments are invalid, it prints a usage message
and returns exit code 2. That's the same exit code as for a failed
check, which is potentially confusing if running dtc from an automated
harness. Therefore this patch changes the usage exit code to 3.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Index: dtc/dtc.c
===================================================================
--- dtc.orig/dtc.c 2008-03-18 14:02:42.000000000 +1100
+++ dtc/dtc.c 2008-03-18 14:02:46.000000000 +1100
@@ -106,7 +106,7 @@ static void __attribute__ ((noreturn))
fprintf(stderr, "\t\tForce - try to produce output even if the input tree has errors\n");
fprintf(stderr, "\t-v\n");
fprintf(stderr, "\t\tPrint DTC version and exit\n");
- exit(2);
+ exit(3);
}
int main(int argc, char *argv[])
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
* Re: [PATCH] net: NEWEMAC: Support for Pause packets in EMAC driver
From: Josh Boyer @ 2008-03-18 3:56 UTC (permalink / raw)
To: benh; +Cc: netdev, Stefan Roese, Jeff Garzik, linuxppc-dev
In-Reply-To: <1205808100.26869.204.camel@pasglop>
On Tue, 18 Mar 2008 13:41:40 +1100
Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:
>
> > http://marc.info/?l=linux-netdev&m=120449748701492&w=2
> >
> > I sent it to Ben with netdev on CC because you asked the various people
> > sending NEWEMAC patches to you to find a single person.
> >
> > So from now on, what are we going to do? It seems we're playing net
> > maintainer russian roulette for NEWEMAC and it's getting old.
>
> I'm happy to collect the patches. I said I would do it, I was just taken
> aback a bit by Jeff suddenly merging two of Stefan patches directly :-)
>
> I was actually planning this week to post a serie of all the pending
> EMAC patches for final review.
Ok. Either way, if it helps someone I'd be happy to roll them into a
newemac branch in my git tree.
josh
^ permalink raw reply
* Re: [PATCH] net: NEWEMAC: Support for Pause packets in EMAC driver
From: Jeff Garzik @ 2008-03-18 4:06 UTC (permalink / raw)
To: benh; +Cc: netdev, Stefan Roese, linuxppc-dev
In-Reply-To: <1205808100.26869.204.camel@pasglop>
Benjamin Herrenschmidt wrote:
>> http://marc.info/?l=linux-netdev&m=120449748701492&w=2
>>
>> I sent it to Ben with netdev on CC because you asked the various people
>> sending NEWEMAC patches to you to find a single person.
>>
>> So from now on, what are we going to do? It seems we're playing net
>> maintainer russian roulette for NEWEMAC and it's getting old.
>
> I'm happy to collect the patches. I said I would do it, I was just taken
> aback a bit by Jeff suddenly merging two of Stefan patches directly :-)
Sorry... they were CC'd to me and netdev, Stefan had previously
contributed acceptable patches, and the patches looked OK, so... :)
^ permalink raw reply
* RE: XUPV2P board opb_emac cannot work with linux-2.6-xlnx
From: Stephen Neuendorffer @ 2008-03-18 4:30 UTC (permalink / raw)
To: Qin Lin, linuxppc-embedded
In-Reply-To: <16112415.post@talk.nabble.com>
[-- Attachment #1: Type: text/plain, Size: 4682 bytes --]
Yes that should work...
Steve
-----Original Message-----
From: linuxppc-embedded-bounces+stephen=neuendorffer.name@ozlabs.org on behalf of Qin Lin
Sent: Mon 3/17/2008 7:17 PM
To: linuxppc-embedded@ozlabs.org
Subject: RE: XUPV2P board opb_emac cannot work with linux-2.6-xlnx
HI Steve:
when i design the system ,i chose opb_emac_1.04a ,No DMA, Use interrupt ?
Is it the correct setting for the current driver?
Thanks
Stephen Neuendorffer wrote:
>
>
> It should... (I use it regularly on the xup board)
> Did you remember to connect the interrupt line in your design?
>
> Steve
>
>> -----Original Message-----
>> From: linuxppc-embedded-bounces+stephen=neuendorffer.name@ozlabs.org
> [mailto:linuxppc-embedded-
>> bounces+stephen=neuendorffer.name@ozlabs.org] On Behalf Of Qin Lin
>> Sent: Monday, March 17, 2008 12:36 AM
>> To: linuxppc-embedded@ozlabs.org
>> Subject: XUPV2P board opb_emac cannot work with linux-2.6-xlnx
>>
>>
>> HI all,
>>
>> Is anyone have the opb_emac (no DMA) work with the kernel
> linux-2.6-xlnx
>> from git.xilinx.com.
>> the message seams that it does work ,but the command ping return
> nothing!
>>
>> Could you kindly suggest me what to do?
>>
>> ps:
>> the kernel booting message
>> [ 0.258674] net_namespace: 64 bytes
>> [ 0.269780] NET: Registered protocol family 16
>> [ 0.290415] Registering device xilinx_emac:0
>> [ 0.381687] NET: Registered protocol family 2
>> [ 0.392324] IP route cache hash table entries: 2048 (order: 1, 8192
>> bytes)
>> [ 0.399556] TCP established hash table entries: 8192 (order: 4,
> 65536
>> bytes)
>> [ 0.403403] TCP bind hash table entries: 8192 (order: 3, 32768
> bytes)
>> [ 0.405409] TCP: Hash tables configured (established 8192 bind
> 8192)
>> [ 0.405489] TCP reno registered
>> [ 0.412758] sysctl table check failed: /kernel/l2cr .1.31 Missing
>> strategy
>> [ 0.413189] Call Trace:
>> [ 0.413244] [cf41feb0] [c0008178] show_stack+0x48/0x184
> (unreliable)
>> [ 0.413467] [cf41fed0] [c00303c8] set_fail+0x50/0x68
>> [ 0.413640] [cf41fef0] [c0030b54] sysctl_check_table+0x64c/0x698
>> [ 0.413724] [cf41ff20] [c0030b68] sysctl_check_table+0x660/0x698
>> [ 0.413802] [cf41ff50] [c001e810] register_sysctl_table+0x64/0xb4
>> [ 0.414141] [cf41ff70] [c01e4b1c]
> register_ppc_htab_sysctl+0x18/0x2c
>> [ 0.414311] [cf41ff80] [c01de1e4] kernel_init+0xc8/0x284
>> [ 0.414384] [cf41fff0] [c0004ab8] kernel_thread+0x44/0x60
>>
>> [ 1.116395] xilinx_emac xilinx_emac.0: MAC address is now 2: 0: 0:
> 0: 0:
>> 0
>> [ 1.123790] XEmac: using fifo mode.
>> [ 1.128188] XEmac: Detected PHY at address 0, ManufID 0x0013, Rev.
>> 0x78e2.
>> [ 1.135715] eth0: Dropping NETIF_F_SG since no checksum feature.
>> [ 1.151038] eth0: Xilinx 10/100 EMAC at 0x40C00000 mapped to
> 0xD0020000,
>> irq=2
>> [ 1.158713] eth0: XEmac id 1.4a, block id 128, type 1
>> [ 1.194661] TCP cubic registered
>> [ 1.198647] NET: Registered protocol family 1
>> [ 1.203728] NET: Registered protocol family 17
>>
>>
>> #ping 192.168.26.1 &
>> # ifconfig eth0
>> eth0 Link encap:Ethernet HWaddr 02:00:00:00:00:00
>> inet addr:192.168.26.127 Bcast:192.168.26.255
> Mask:255.255.255.0
>> UP BROADCAST RUNNING MTU:1500 Metric:1
>> RX packets:0 errors:0 dropped:0 overruns:0 frame:0
>> TX packets:16 errors:0 dropped:0 overruns:0 carrier:0
>> collisions:0 txqueuelen:1000
>> RX bytes:0 (0.0 B) TX bytes:672 (672.0 B)
>> Interrupt:2 Memory:40c00000-40c0ffff
>>
>> Regards
>>
>> Qin Lin
>> --
>> View this message in context:
> http://www.nabble.com/XUPV2P-board-opb_emac-cannot-work-with-linux-2.6-
>> xlnx-tp16089631p16089631.html
>> Sent from the linuxppc-embedded mailing list archive at Nabble.com.
>>
>> _______________________________________________
>> Linuxppc-embedded mailing list
>> Linuxppc-embedded@ozlabs.org
>> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
>
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
>
--
View this message in context: http://www.nabble.com/XUPV2P-board-opb_emac-cannot-work-with-linux-2.6-xlnx-tp16089631p16112415.html
Sent from the linuxppc-embedded mailing list archive at Nabble.com.
_______________________________________________
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded
[-- Attachment #2: Type: text/html, Size: 7440 bytes --]
^ permalink raw reply
* Re: powerpc: cuImage.* creation error
From: Grant Likely @ 2008-03-18 5:10 UTC (permalink / raw)
To: Paul Gortmaker; +Cc: linuxppc-dev, Adrian Bunk, Paul Mackerras, linux-kernel
In-Reply-To: <fa686aa40803171622j2183369ei7b384ada72d329d6@mail.gmail.com>
On Mon, Mar 17, 2008 at 5:22 PM, Grant Likely <grant.likely@secretlab.ca> wrote:
> On Mon, Mar 17, 2008 at 4:46 PM, Paul Gortmaker
> > The wrapper script didn't have entries for the TQM8540 board and the
> > SBC8548 or SBC8560 boards. I've assumed that the TQM8540 console is
> > 8250 based and not CPM based by looking at its defconfig. There was
> > also a trailing * on the TQM8555 entry that I removed too.
> >
> >
> > Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
> Acked-by: Grant Likely <grant.likely@secretlab.ca>
Actually, I looked again and tweaked a few details in the patch (it
was duplicating an existing clause in the wrapper script). I'm just
about to post the edited version which I've tested in my environment.
Cheers,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* [PATCH][POWERPC] bootwrapper: Add entries for tqm8540 and sbc85xx
From: Grant Likely @ 2008-03-18 5:13 UTC (permalink / raw)
To: bunk, paul.gortmaker, galak, paulus, linuxppc-dev, linux-kernel
From: Paul Gortmaker <paul.gortmaker@windriver.com>
The wrapper script didn't have entries for the TQM8540 board and the
SBC8548 or SBC8560 boards. I've assumed that the TQM8540 console is
8250 based and not CPM based by looking at its defconfig. There was
also a trailing * on the TQM8555 entry that I removed too.
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
---
Paulus; this fixes the broken defconfig issues that Adrian raised. Can you
please pick this up for merger into 2.6.25?
Thanks,
g.
arch/powerpc/boot/Makefile | 4 ++--
arch/powerpc/boot/wrapper | 4 ++--
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/powerpc/boot/Makefile b/arch/powerpc/boot/Makefile
index 4974d9e..1aded8f 100644
--- a/arch/powerpc/boot/Makefile
+++ b/arch/powerpc/boot/Makefile
@@ -253,8 +253,8 @@ image-$(CONFIG_TQM8540) += cuImage.tqm8540
image-$(CONFIG_TQM8541) += cuImage.tqm8541
image-$(CONFIG_TQM8555) += cuImage.tqm8555
image-$(CONFIG_TQM8560) += cuImage.tqm8560
-image-$(CONFIG_SBC8548) += cuImage.tqm8548
-image-$(CONFIG_SBC8560) += cuImage.tqm8560
+image-$(CONFIG_SBC8548) += cuImage.sbc8548
+image-$(CONFIG_SBC8560) += cuImage.sbc8560
# Board ports in arch/powerpc/platform/embedded6xx/Kconfig
image-$(CONFIG_STORCENTER) += cuImage.storcenter
diff --git a/arch/powerpc/boot/wrapper b/arch/powerpc/boot/wrapper
index d50e498..8f8b849 100755
--- a/arch/powerpc/boot/wrapper
+++ b/arch/powerpc/boot/wrapper
@@ -174,10 +174,10 @@ cuboot*)
*-mpc83*)
platformo=$object/cuboot-83xx.o
;;
- *-tqm8541|*-mpc8560*|*-tqm8560|*-tqm8555*)
+ *-tqm8541|*-mpc8560*|*-tqm8560|*-tqm8555)
platformo=$object/cuboot-85xx-cpm2.o
;;
- *-mpc85*)
+ *-mpc85*|*-tqm8540|*-sbc85*)
platformo=$object/cuboot-85xx.o
;;
esac
^ permalink raw reply related
* [BUG]2.6.25-rc6:Unable to handle kernel paging request
From: Sudhir Kumar @ 2008-03-18 5:29 UTC (permalink / raw)
To: linux-kernel; +Cc: Poornima Nayak, linuxppc-dev, akpm
Hi,
I found the following bug at kernel boot up on my power machine
with 2.6.25-rc6 kernel.
USB Mass Storage support registered.
mice: PS/2 mouse device common for all mice
Unable to handle kernel paging request for data at address
0xd00008000000002e
Faulting instruction address: 0xc00000000074ded8
cpu 0x0: Vector: 300 (Data Access) at [c00000003e073aa0]
pc: c00000000074ded8: .f71805f_find+0x44/0x32c
lr: c00000000074e1f8: .f71805f_init+0x38/0x194
sp: c00000003e073d20
msr: 8000000000009032
dar: d00008000000002e
dsisr: 42000000
current = 0xc0000000220851c0
paca = 0xc0000000007c2700
pid = 1, comm = swapper
enter ? for help
[c00000003e073dc0] c00000000074e1f8 .f71805f_init+0x38/0x194
[c00000003e073ea0] c000000000724bdc .kernel_init+0x204/0x3c8
[c00000003e073f90] c000000000025df4 .kernel_thread+0x4c/0x68
For further reference some of the debug info is:
0:mon> r
R00 = d00008000000002e R16 = 4000000001c00000
R01 = c00000003e073d20 R17 = c00000000066ecc8
R02 = c0000000008f4458 R18 = 0000000000000000
R03 = 000000000000002e R19 = 00000000003a1000
R04 = c00000003e073e30 R20 = 000000000235a3d0
R05 = c00000003e073e34 R21 = c00000000075a3d0
R06 = 0000000024000044 R22 = 000000000235a640
R07 = c000000000010bcc R23 = c00000000075a640
R08 = c00000003e073570 R24 = c00000000066fe90
R09 = d000080000000000 R25 = 0000000000000000
R10 = cf000000009c2d60 R26 = c00000003e070000
R11 = ffffffffffffff87 R27 = c00000003e073e30
R12 = 0000000000000000 R28 = c00000003e073e34
R13 = c0000000007c2700 R29 = 000000000000002e
R14 = 0000000000000000 R30 = c000000000880278
R15 = c000000000670448 R31 = c00000000078e050
pc = c00000000074ded8 .f71805f_find+0x44/0x32c
lr = c00000000074e1f8 .f71805f_init+0x38/0x194
msr = 8000000000009032 cr = 24000042
ctr = c00000000074e1c0 xer = 0000000000000005 trap = 300
dar = d00008000000002e dsisr = 42000000
0:mon> e
cpu 0x0: Vector: 300 (Data Access) at [c00000003e073aa0]
pc: c00000000074ded8: .f71805f_find+0x44/0x32c
lr: c00000000074e1f8: .f71805f_init+0x38/0x194
sp: c00000003e073d20
msr: 8000000000009032
dar: d00008000000002e
dsisr: 42000000
current = 0xc0000000220851c0
paca = 0xc0000000007c2700
pid = 1, comm = swapper
0:mon> di %pc
c00000000074ded8 7d6919ae stbx r11,r9,r3
c00000000074dedc 39000001 li r8,1
c00000000074dee0 990d01dc stb r8,476(r13)
c00000000074dee4 e93f0000 ld r9,0(r31)
c00000000074dee8 7c034a14 add r0,r3,r9
c00000000074deec 7c0004ac sync
c00000000074def0 7d6919ae stbx r11,r9,r3
c00000000074def4 990d01dc stb r8,476(r13)
c00000000074def8 38800023 li r4,35
c00000000074defc 4bcc95e1 bl c0000000004174dc #
.superio_inw+0x0/0x134
c00000000074df00 3940ffed li r10,-19
c00000000074df04 5463043e clrlwi r3,r3,16
c00000000074df08 2f831934 cmpwi cr7,r3,6452
c00000000074df0c 409e0260 bne cr7,c00000000074e16c #
.f71805f_find+0x2d8/0x32c
c00000000074df10 e93e8038 ld r9,-32712(r30)
c00000000074df14 a0690000 lhz r3,0(r9)
0:mon>
Thanks
Sudhir Kumar
ISTL, IBM
Bangalore
^ permalink raw reply
* Re: [PATCH] net: NEWEMAC: Support for Pause packets in EMAC driver
From: Benjamin Herrenschmidt @ 2008-03-18 5:35 UTC (permalink / raw)
To: Jeff Garzik; +Cc: netdev, Stefan Roese, linuxppc-dev
In-Reply-To: <47DF3FC7.6070500@garzik.org>
On Tue, 2008-03-18 at 00:06 -0400, Jeff Garzik wrote:
> Benjamin Herrenschmidt wrote:
> >> http://marc.info/?l=linux-netdev&m=120449748701492&w=2
> >>
> >> I sent it to Ben with netdev on CC because you asked the various people
> >> sending NEWEMAC patches to you to find a single person.
> >>
> >> So from now on, what are we going to do? It seems we're playing net
> >> maintainer russian roulette for NEWEMAC and it's getting old.
> >
> > I'm happy to collect the patches. I said I would do it, I was just taken
> > aback a bit by Jeff suddenly merging two of Stefan patches directly :-)
>
> Sorry... they were CC'd to me and netdev, Stefan had previously
> contributed acceptable patches, and the patches looked OK, so... :)
Sure they were fine, it's just a matter of getting the right
procedure :-)
Now, I'll collect the remaining ones and will send them for
review again.
Cheers,
Ben.
^ permalink raw reply
* Re: [PATCH v2] 8xx: Add support for the MPC852 based board from keymile.
From: Heiko Schocher @ 2008-03-18 7:13 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: linuxppc-dev
In-Reply-To: <20080315102508.bc698a90.sfr@canb.auug.org.au>
Hello Stephen,
Stephen Rothwell wrote:
> On Fri, 14 Mar 2008 10:24:30 +0100 Heiko Schocher <hs@denx.de> wrote:
[...]
>> +struct cpm_pin {
>> + int port, pin, flags;
>> +};
>
> I wish someone would consolidate all these definitions of cpm_pin.
Hmm... do you mean something like, moving this struct
in cpm1.h and ...
>> +static void __init init_ioports(void)
>> +{
>> + int i;
>> +
>> + for (i = 0; i < ARRAY_SIZE(mgsuvd_pins); i++) {
>> + struct cpm_pin *pin = &mgsuvd_pins[i];
>> + cpm1_set_pin(pin->port, pin->pin, pin->flags);
>> + }
>
> And the code that uses them ...
making in arch/powerpc/sysdev/cpm1.c a function
cpm1_setup_pins (struct cpm_pin *pins) ?
>> +static void __init mgsuvd_setup_arch(void)
>> +{
>> + struct device_node *cpu;
>> +
>> + cpu = of_find_node_by_type(NULL, "cpu");
>> + if (cpu != 0) {
>
> "cpu" is a pointer, so "cpu != NULL" or just "cpu"
>
>> + const unsigned int *fp;
>> +
>> + fp = of_get_property(cpu, "clock-frequency", NULL);
>> + if (fp != 0)
>
> Ditto for "fp" test
Its no longer necessary, thanks to Scott
bye,
Heiko
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
^ 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