* Re: new NAPI interface broken for POWER architecture?
From: Christoph Raisch @ 2007-09-12 13:10 UTC (permalink / raw)
To: David Miller
Cc: ossthema, Paul Mackerras, netdev, Jan-Bernd Themann, linuxppc-dev,
Arnd Bergmann, Michael Ellerman, shemminger
In-Reply-To: <20070912.055004.88490155.davem@davemloft.net>
David Miller <davem@davemloft.net> wrote on 12.09.2007 14:50:04:
> From: Jan-Bernd Themann <ossthema@de.ibm.com>
> Date: Fri, 7 Sep 2007 11:37:02 +0200
>
> > 2) On SMP systems: after netif_rx_complete has been called on CPU1
> > (+interruts enabled), netif_rx_schedule could be called on CPU2
> > (irq handler) before net_rx_action on CPU1 has checked
NAPI_STATE_SCHED.
> > In that case the device would be added to poll lists of CPU1 and
CPU2
> > as net_rx_action would see NAPI_STATE_SCHED set.
> > This must not happen. It will be caught when netif_rx_complete is
> > called the second time (BUG() called)
> >
> > This would mean we have a problem on all SMP machines right now.
>
> This is not a correct statement.
>
> Only on your platform do network device interrupts get moved
> around, no other platform does this.
>
> Sparc64 doesn't, all interrupts stay in one location after
> the cpu is initially choosen.
>
> x86 and x86_64 specifically do not move around network
> device interrupts, even though other device types do
> get dynamic IRQ cpu distribution.
>
> That's why you are the only person seeing this problem.
>
> I agree that it should be fixed, but we should also fix the IRQ
> distribution scheme used on powerpc platforms which is totally
> broken in these cases.
This is definitely not something we can change in the HEA device driver
alone.
It could also affect any other networking cards on POWER (e1000,s2io...).
Paul, Michael, Arndt, what is your opinion here?
Gruss / Regards
Christoph Raisch
^ permalink raw reply
* Re: new NAPI interface broken for POWER architecture?
From: David Miller @ 2007-09-12 13:27 UTC (permalink / raw)
To: RAISCH
Cc: ossthema, pmac, netdev, THEMANN, linuxppc-dev, ARNDB, ellerman,
shemminger
In-Reply-To: <OF2D6ED296.BDB04FBF-ONC1257354.00473703-C1257354.0048406C@de.ibm.com>
From: Christoph Raisch <RAISCH@de.ibm.com>
Date: Wed, 12 Sep 2007 15:10:08 +0200
> This is definitely not something we can change in the HEA device driver
> alone.
And it shouldn't be, x86 implements the policy in irq balance
daemon, powerpc should do it wherever it would be appropriate
there.
> Paul, Michael, Arndt, what is your opinion here?
I'm all ears too :)
^ permalink raw reply
* Re: [PATCH] powerpc: add new required termio functions
From: Christoph Hellwig @ 2007-09-12 13:49 UTC (permalink / raw)
To: Heiko Carstens
Cc: Michael Neuling, linux-kernel, Christoph Hellwig, linuxppc-dev,
paulus, Alan Cox, Andrew Morton, Linus Torvalds, David S. Miller,
Martin Schwidefsky
In-Reply-To: <20070912115257.GC7858@osiris.boeblingen.de.ibm.com>
On Wed, Sep 12, 2007 at 01:52:57PM +0200, Heiko Carstens wrote:
> > I might be missing something, but the the right fix is probably to
> > apply the arch patches from Alan to powerpc and s390. We don't want to
> > be left over without all the nice termios features on these platforms,
> > do we?
>
> But not in rc6 timeframe, I would guess?
Ask Alan..
^ permalink raw reply
* Re: [PATCH v3] [POWERPC] 85xx: Add basic Uniprocessor MPC8572 DS port
From: Segher Boessenkool @ 2007-09-12 14:00 UTC (permalink / raw)
To: David Gibson; +Cc: linuxppc-dev
In-Reply-To: <20070912035351.GF20218@localhost.localdomain>
>>>> + uli1575@0 {
>>>> + reg = <0 0 0 0 0>;
>>>
>>> This looks kind of bogus...
>>
>> Its a PCIe to PCI bridge that is transparent.
>
> Right.... if it has no control registers, I think it should just lack
> 'reg', not define a zero-length register block.
"reg" for PCI config registers has length 0 always, it's defined that
way in the PCI binding.
But if this thing is transparent, it doesn't have PCI config regs.
>>>> + #size-cells = <2>;
>>>> + #address-cells = <3>;
>>>> + ranges = <02000000 0 80000000
>>>> + 02000000 0 80000000
>>>> + 0 20000000
>>>> + 01000000 0 00000000
>>>> + 01000000 0 00000000
>>>> + 0 00100000>;
>
> And if truly transparent, it should perhaps have just ranges;
> indicating that child addresses are identity mapped to parent
> addresses.
If truly transparent, the node should just not be there at all!
>>>> + pci_bridge@0 {
>>>
>>> Ok.. why is pci_bridge nested within uli1575 - with the matching reg
>>> and ranges, it looks like they ought to be one device. Also if this
>>> is a PCI<->PCI bridge, I believe it shold have device_type = "pci".
>>
>> We've been using this as it stands for a while. If there are some
>> changes here that make sense I'm willing to make them.
>
> Right, at present I don't see why you couldn't just ditch the
> pci_bridge node, and drop its contents straight into the uli1575 node.
Yeah. The preferred name for PCI-to-PCI bridge nodes is simply "pci",
btw.
Segher
^ permalink raw reply
* Re: [PATCH v3] [POWERPC] 85xx: Add basic Uniprocessor MPC8572 DS port
From: Segher Boessenkool @ 2007-09-12 14:10 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev, David Gibson
In-Reply-To: <AC5C6EF4-EE8E-487F-BF45-3653A5C2617D@kernel.crashing.org>
>>> + i8259: interrupt-controller@20 {
>>> + reg = <1 20 2
>>> + 1 a0 2
>>> + 1 4d0 2>;
>>> + clock-frequency = <0>;
>>
>> Hrm.. what is clock-frequency for on an i8259? I see that other 8259
>> descriptions have this as well, so it's not a problem with this patch
>> specifically.
>
> Its a copy-paste thing so I don't know.
If your bootwrapper doesn't fill in this value, you should get rid
of this property -- better to have no value than to have the wrong
value, esp. since it's probably unused anyway.
Segher
^ permalink raw reply
* Re: writing to flash from linux
From: David H. Lynch Jr. @ 2007-09-12 14:15 UTC (permalink / raw)
To: Yoni Levin; +Cc: linuxppc-embedded
In-Reply-To: <1E2D24B6DA8A4EE68CFFD33998B2BC26.MAI@mail.livedns.co.il>
Yoni Levin wrote:
> Hi , I have EN29LV640H flash (http://www.eonsdi.com/pdf/EN29LV640.pdf)
>
> On my mpc83xx board.
>
> How can I write data to flash from linux.?
>
> I guess it done with mtd , there is an example somewhere?
>
> Thanks.
>
>
I know nothing specific about your board or flash, but MTD is the
proper system for handling flash.
You need an mtd driver for your board - it is possible something
already exists, but if not you need to write it.
That driver may be extremely simple - if your boards flash system if
not very complex.
Some of the issues are ?
Is your flash partitioned - are there multiple regaions of flash
that each serve different purposes - such as a boot loader, a kernel, an
initrd and separately a file system - or even more than one file system.
Is your flash chip recognized by Linux (likely)
Are there special conditions for reading/writing flash on your board
- i.e. do you have to enable special voltages or protection bits - board
specific protection not chips specific,
Does your board "window" the flash such that only part of it is in
the CPU's memory space at one time.
Does your board have some odd quicks for accessing flash - like
requiring a 32 bit read to get a 16bit value ?
All of these are handled by the mtd driver
If as an example you have a very standard CFI flash chip, that has
no windowing, no special read/write enables, is always fully in the CPU
memory space at the same place,
and all the flash is going to be used for a single filesystem with
no reserved blocks, bootloaders etc.
The mtd driver could be trivial, there might even be something that
can just be used as is.
>
>
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
--
Dave Lynch DLA Systems
Software Development: Embedded Linux
717.627.3770 dhlii@dlasys.net http://www.dlasys.net
fax: 1.253.369.9244 Cell: 1.717.587.7774
Over 25 years' experience in platforms, languages, and technologies too numerous to list.
"Any intelligent fool can make things bigger and more complex... It takes a touch of genius - and a lot of courage to move in the opposite direction."
Albert Einstein
^ permalink raw reply
* MirrorBit FLASH Read/Write Problem
From: Billalabeitia, Jose Carlos (GE Indust, ConsInd) @ 2007-09-12 14:21 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 498 bytes --]
Hello:
I would like to know if someone out there has experienced the
following
problems in the S29GL064M90TFIR60 FLASH (MirrorBit Technology):
- After two consecutive readings at the same random memory location,
the first reading is
all zeros, and the second one is the data OK.
- After programming one word to a random memory location, the data
stored is all zeros or the
adjacent memory location is affected with all zeros.
Thank you
Billa
[-- Attachment #2: Type: text/html, Size: 3150 bytes --]
^ permalink raw reply
* Re: [PATCH 08/12] IB/ehca: Replace get_paca()->paca_index by the more portable smp_processor_id()
From: Joachim Fenkes @ 2007-09-12 14:42 UTC (permalink / raw)
To: Nathan Lynch
Cc: LKML, OF-EWG, LinuxPPC-Dev, Christoph Raisch, OF-General,
Stefan Roscher
In-Reply-To: <20070911145131.GN32388@localdomain>
On Tuesday 11 September 2007 16:51, Nathan Lynch wrote:
> > - get_paca()->paca_index, __FUNCTION__, \
> > + smp_processor_id(), __FUNCTION__, \
>
> I think I see these macros used in preemptible code (e.g. ehca_probe),
> where smp_processor_id() will print a warning when
> CONFIG_DEBUG_PREEMPT=y. Probably better to use raw_smp_processor_id.
You're right, man. The processor id doesn't need to be preemption-safe in this
context, so that would be a bogus warning. Thanks for pointing this out. I'll
post a new version of this patch.
Joachim
^ permalink raw reply
* [PATCH 08/12] IB/ehca: Replace get_paca()->paca_index by the more portable raw_smp_processor_id()
From: Joachim Fenkes @ 2007-09-12 14:44 UTC (permalink / raw)
To: LinuxPPC-Dev, LKML, OF-General, Roland Dreier, OF-EWG
Cc: Stefan Roscher, Christoph Raisch
In-Reply-To: <200709111533.14333.fenkes@de.ibm.com>
We can use raw_smp_processor_id() here because the processor ID is only used
for debug output and may therefore be preemption-unsafe.
Signed-off-by: Joachim Fenkes <fenkes@de.ibm.com>
---
This is the same patch, but with smp_processor_id() replaced by
raw_smp_processor_id(), as kindly pointed out to me by Nathan. Thanks!
drivers/infiniband/hw/ehca/ehca_tools.h | 14 +++++++-------
1 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/drivers/infiniband/hw/ehca/ehca_tools.h b/drivers/infiniband/hw/ehca/ehca_tools.h
index f9b264b..4a8346a 100644
--- a/drivers/infiniband/hw/ehca/ehca_tools.h
+++ b/drivers/infiniband/hw/ehca/ehca_tools.h
@@ -73,37 +73,37 @@ extern int ehca_debug_level;
if (unlikely(ehca_debug_level)) \
dev_printk(KERN_DEBUG, (ib_dev)->dma_device, \
"PU%04x EHCA_DBG:%s " format "\n", \
- get_paca()->paca_index, __FUNCTION__, \
+ raw_smp_processor_id(), __FUNCTION__, \
## arg); \
} while (0)
#define ehca_info(ib_dev, format, arg...) \
dev_info((ib_dev)->dma_device, "PU%04x EHCA_INFO:%s " format "\n", \
- get_paca()->paca_index, __FUNCTION__, ## arg)
+ raw_smp_processor_id(), __FUNCTION__, ## arg)
#define ehca_warn(ib_dev, format, arg...) \
dev_warn((ib_dev)->dma_device, "PU%04x EHCA_WARN:%s " format "\n", \
- get_paca()->paca_index, __FUNCTION__, ## arg)
+ raw_smp_processor_id(), __FUNCTION__, ## arg)
#define ehca_err(ib_dev, format, arg...) \
dev_err((ib_dev)->dma_device, "PU%04x EHCA_ERR:%s " format "\n", \
- get_paca()->paca_index, __FUNCTION__, ## arg)
+ raw_smp_processor_id(), __FUNCTION__, ## arg)
/* use this one only if no ib_dev available */
#define ehca_gen_dbg(format, arg...) \
do { \
if (unlikely(ehca_debug_level)) \
printk(KERN_DEBUG "PU%04x EHCA_DBG:%s " format "\n", \
- get_paca()->paca_index, __FUNCTION__, ## arg); \
+ raw_smp_processor_id(), __FUNCTION__, ## arg); \
} while (0)
#define ehca_gen_warn(format, arg...) \
printk(KERN_INFO "PU%04x EHCA_WARN:%s " format "\n", \
- get_paca()->paca_index, __FUNCTION__, ## arg)
+ raw_smp_processor_id(), __FUNCTION__, ## arg)
#define ehca_gen_err(format, arg...) \
printk(KERN_ERR "PU%04x EHCA_ERR:%s " format "\n", \
- get_paca()->paca_index, __FUNCTION__, ## arg)
+ raw_smp_processor_id(), __FUNCTION__, ## arg)
/**
* ehca_dmp - printk a memory block, whose length is n*8 bytes.
--
1.5.2
^ permalink raw reply related
* Re: [POWERPC] PCI Bug fix for MRM failure in PPC 440EPx
From: Josh Boyer @ 2007-09-12 14:45 UTC (permalink / raw)
To: Stefan Roese; +Cc: linuxppc-dev
In-Reply-To: <200708301033.28423.ml@stefan-roese.de>
On Thu, 30 Aug 2007 10:33:28 +0200
Stefan Roese <ml@stefan-roese.de> wrote:
> Problem Description and Fix : Memory Read Multiples(MRM) do not work
> correctly on PPC 440EPX based systems. A PCI driver determines whether
> MRMs are supported by reading the PCI cache line size register. If this
> value is zero then MRMs are not supported. However some PCI drivers
> write to the PCI cache line size register on initialization. This
> results in MRMs being sent to system memory on 440EPX based systems.
> Since MRMs do not work correctly in 440EPX based systems this may cause
> system hang. This patch solves this problem by modifying the PPC
> platform specific PCI configuration register write function, by forcing
> any value written to PCI_CACHE_LINE_SIZE register to be 0. This fix was
> tested on different PCI cards : i.e. Silicon Image ATA card and Intel
> E1000 GIGE card. On Silicon Image ATA card without this fix in place
> creating a filesystem on IDE drive "mke2fs /dev/hda" was hanging the
> system. MRMs issued by the PCI card were seen on the PCI analyzer since
> the Silicon Image driver was setting the PCI_CACHE_LINE_SIZE register to
> 255. With this patch the PCI_CACHE_LINE_SIZE register was 0 and only
> Memory Reads were seen on PCI analyzer.
>
> Signed-off-by: Pravin M. Bathija <pbathija@amcc.com>
> Signed-off-by: Stefan Roese <sr@denx.de>
>
> ---
> I know this patch is a little "dirty", but perhaps somebody has a better
> idea to fix this problem. Thanks.
For the peanut gallery, Stefan and I discussed this a bit on IRC today
and a different approach for arch/powerpc is going to be looked at
instead. Namely, introducing a new flag for indirect_type in the
pci_controller structure to key off of instead of having ifdefs.
josh
^ permalink raw reply
* RE: futex priority based wakeup
From: Benedict, Michael @ 2007-09-12 14:56 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <1656e050709111714g1a84656bvd7823f5fc43345dd@mail.gmail.com>
Nguyen Nguyen wrote:
> I have seen something similar before. Our fix was to use
> pthread_attr_setinheritsched(&attr, PTHREAD_EXPLICIT_SCHED)
> so child threads wouldn't inherit attribute from parent.
> On 9/11/07, Ilya Lipovsky <lipovsky@cs.bu.edu> wrote:
>=20
> Hmm. Just for kicks - inside the important thread could you add:
<snip>
> printf("important's policy is %d and priority is %d\n",
curpolicy,
<snip>
> Do similar for the unimportant thread, and see if you
> get anything weird -
> e.g. priorities come out to be the same for threads.
Thank you both! You were each correct, and your input has been greatly
appreciated.
Adding the printf() resulted in:
unimportant's policy is 0 and priority is 0
unimportant waiting for futex
important's policy is 0 and priority is 0
important waiting for futex
main's policy is 0 and priority is 0
futex FUTEX_WAKE
unimportant's policy is 0 and priority is 0
unimportant got futex!
important's policy is 0 and priority is 0
important got futex!
Adding the PTHREAD_EXPLICIT_SCHED resulted in:
unimportant's policy is 1 and priority is 1
unimportant waiting for futex
important's policy is 1 and priority is 99
important waiting for futex
main's policy is 0 and priority is 0
futex FUTEX_WAKE
important's policy is 1 and priority is 99
important got futex!
unimportant's policy is 1 and priority is 1
unimportant got futex!
Verifying with pthread_muxtex / glibc 2.3.6:
unimportant's policy is 1 and priority is 1
unimportant waiting for mutex
important's policy is 1 and priority is 99
important waiting for mutex
main's policy is 0 and priority is 0
main unlocking mutex
important's policy is 1 and priority is 99
important got mutex!
unimportant's policy is 1 and priority is 1
unimportant got mutex!
And, to come full circle, regression on 2.6.21 resulted in:
unimportant's policy is 1 and priority is 1
unimportant waiting for futex
important's policy is 1 and priority is 99
important waiting for futex
main's policy is 0 and priority is 0
futex FUTEX_WAKE
unimportant's policy is 1 and priority is 1
unimportant got futex!
important's policy is 1 and priority is 99
important got futex!
Now it is time to audit my other code and make sure to add
PTHREAD_EXPLICIT_SCHED where appropriate. Thank you.
-Michael
^ permalink raw reply
* Re: Which 2.6 kernel for MPC5200
From: Jon Smirl @ 2007-09-12 15:08 UTC (permalink / raw)
To: Robert Schwebel, Domen Puncer; +Cc: Babarovic Ivica, linuxppc-embedded
In-Reply-To: <20070912062819.GI23573@pengutronix.de>
On 9/12/07, Robert Schwebel <r.schwebel@pengutronix.de> wrote:
> We have the OSELAS.BSP patch stack for the PCM030 working ontop of
> Linus' git. It still uses an older version of the Bestcom patches, so if
> you do some work in that area, please keep me informed about your
> progress.
What is the best way to proceed? I need to be on current git since we
are integrating a wireless driver that is tracking current git and the
mac80211 work.
I have Phytec (pcm030) and Efika hardware but I don't have a 5200lite.
Our prototype hardware uses the pcm030 module on a custom baseboard.
The best thing for me would be to get a FEC driver merged. That is the
largest piece of code that is floating around. Getting that merged
would give me a stable base to build future patches on.
I'd also like to get support for the pcm030 (minus real-time) merged.
That isn't a lot of code once FEC is in the kernel.
Domen has posted this driver "[RFC PATCH v0.1] net driver: mpc52xx
fec". I can work on breaking that up, but I don't have a 5200lite so I
will have to port to pcm030. I don't want to start on this if someone
else is already doing it.
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* MDIO & phy device tree bindings (was Re: [PATCH v3] [POWERPC] 85xx: Add basic Uniprocessor MPC8572 DS port)
From: Kumar Gala @ 2007-09-12 15:08 UTC (permalink / raw)
To: David Gibson, Andy Fleming
Cc: linuxppc-dev@ozlabs.org list, Yoder Stuart-B08248
In-Reply-To: <20070912035351.GF20218@localhost.localdomain>
David,
I'm splitting this up since the mdio & phy comments are more general
that the 8572.dts
>>> [snip]
>>>> + mdio@24520 {
>>>> + #address-cells = <1>;
>>>> + #size-cells = <0>;
>>>> + device_type = "mdio";
>>>
>>> I don't think we actually have an mdio device_type binding defined.
>>
>> We've had this on 83xx/85xx/86xx device trees for a far amount of
>> time now. Look at section 2a in booting-without-of.txt
>
> Ah, so we have; sorry. Although the binding as it is currently
> written is pretty much pointless - it should actually define some
> mappings between dt properties / addresses and the standards defining
> the MDIO bus.x
that's a doc issue at this point
>>>> + compatible = "gianfar";
>>>
>>> This needs to be more specific. And it certainly shouldn't be the
>>> same compatible string as the ethernet MACs have.
>>
>> Why not its the same controller? Again, we've been doing this for
>> some period of time already.
>
> Yes you have, but it's still crap. 'compatible' should be sufficient
> to distinguish the driver needed for device nodes, but the MACs and
> MDIO should clearly have different drivers (or at least, different
> parts of a driver).
don't disagree will see about coming up with a better name, and
deprecating 'gianfar'.
>>>> + reg = <24520 20>;
>>>> + phy0: ethernet-phy@0 {
>>>> + interrupt-parent = <&mpic>;
>>>> + interrupts = <a 1>;
>>>> + reg = <0>;
>>>> + device_type = "ethernet-phy";
>>>
>>> Do we actually have an ethernet-phy device_type binding? If not, we
>>> should kill this. 'compatible' properties for phys would
>>> probably be
>>> a good idea, though (giving the actual phy model).
>>
>> Look section 2c in booting-without-of.txt
>
> Ah, yes. That one's a rather less redeemable pointless device_type
> binding. We should kill it from booting-without-of.txt.
agreed, will poke andy on this.
- k
^ permalink raw reply
* Re: [PATCH v3] [POWERPC] 85xx: Add basic Uniprocessor MPC8572 DS port
From: Kumar Gala @ 2007-09-12 15:13 UTC (permalink / raw)
To: David Gibson; +Cc: linuxppc-dev
In-Reply-To: <20070912035351.GF20218@localhost.localdomain>
>>>> + reg = <e0000 1000>;
>>>> + fsl,has-rstcr;
>>>> + };
>>>> +
>>>> + mpic: pic@40000 {
>>>> + clock-frequency = <0>;
>>>> + interrupt-controller;
>>>> + #address-cells = <0>;
>>>> + #interrupt-cells = <2>;
>>>> + reg = <40000 40000>;
>>>> + compatible = "chrp,open-pic";
>>>> + device_type = "open-pic";
>>>> + big-endian;
>>>> + };
>>>> + };
>>>> +
>>>> + pcie@ffe08000 {
>>>> + compatible = "fsl,mpc8548-pcie";
>>>
>>> And again, "fsl,mpc8572-pcie", "fsl,mpc8548-pcie".
>>
>> But why? there is no difference between the PCIe controller in
>> mpc8548 and mpc8572?
>
> As far as you've yet discovered...
Its the same actual block from design. I'll think some on this. If
I had some macro support in the dtc I wouldn't feel so bad about
doing this. Its the edit/modify/fix cycle that's a pain.
>>>> + uli1575@0 {
>>>> + reg = <0 0 0 0 0>;
>>>
>>> This looks kind of bogus...
>>
>> Its a PCIe to PCI bridge that is transparent.
>
> Right.... if it has no control registers, I think it should just lack
> 'reg', not define a zero-length register block.
>
>>>> + #size-cells = <2>;
>>>> + #address-cells = <3>;
>>>> + ranges = <02000000 0 80000000
>>>> + 02000000 0 80000000
>>>> + 0 20000000
>>>> + 01000000 0 00000000
>>>> + 01000000 0 00000000
>>>> + 0 00100000>;
>
> And if truly transparent, it should perhaps have just ranges;
> indicating that child addresses are identity mapped to parent
> addresses.
>
>>>> +
>>>> + pci_bridge@0 {
>>>
>>> Ok.. why is pci_bridge nested within uli1575 - with the matching reg
>>> and ranges, it looks like they ought to be one device. Also if this
>>> is a PCI<->PCI bridge, I believe it shold have device_type = "pci".
>>
>> We've been using this as it stands for a while. If there are some
>> changes here that make sense I'm willing to make them.
>
> Right, at present I don't see why you couldn't just ditch the
> pci_bridge node, and drop its contents straight into the uli1575 node.
upon further review and discussion you are right about dropping the
pci_bridge@0 node from the ULI. However we do need to add a pcie@0
node to cover the virtual P2P bridge in the PHB. So we have something
like:
pcie@ff808000 {
pcie@0 {
uli@0 {
}
}
}
- k
^ permalink raw reply
* Re: Which 2.6 kernel for MPC5200
From: Grant Likely @ 2007-09-12 15:14 UTC (permalink / raw)
To: Jon Smirl; +Cc: linuxppc-embedded, Domen Puncer, Babarovic Ivica
In-Reply-To: <9e4733910709120808i687ab5far924201f8a910759c@mail.gmail.com>
On 9/12/07, Jon Smirl <jonsmirl@gmail.com> wrote:
> On 9/12/07, Robert Schwebel <r.schwebel@pengutronix.de> wrote:
> > We have the OSELAS.BSP patch stack for the PCM030 working ontop of
> > Linus' git. It still uses an older version of the Bestcom patches, so if
> > you do some work in that area, please keep me informed about your
> > progress.
>
> What is the best way to proceed? I need to be on current git since we
> are integrating a wireless driver that is tracking current git and the
> mac80211 work.
>
> I have Phytec (pcm030) and Efika hardware but I don't have a 5200lite.
> Our prototype hardware uses the pcm030 module on a custom baseboard.
>
> The best thing for me would be to get a FEC driver merged. That is the
> largest piece of code that is floating around. Getting that merged
> would give me a stable base to build future patches on.
>
> I'd also like to get support for the pcm030 (minus real-time) merged.
> That isn't a lot of code once FEC is in the kernel.
>
> Domen has posted this driver "[RFC PATCH v0.1] net driver: mpc52xx
> fec". I can work on breaking that up, but I don't have a 5200lite so I
> will have to port to pcm030. I don't want to start on this if someone
> else is already doing it.
Sylvain's bestcomm patches need be cleaned up and resubmitted before
the next merge window opens. AFAIK, the code is pretty much ready,
and all the comments have been addressed. All that is required is the
final push to tidy the patchset and post to the list one more time.
Sylvain said that he was going to get this done last weekend, but I
haven't heard back from him yet.
Sylvain, if you need help, please let me know. I'll happily take on
the last bit of tidy work if that's what is needed to be finished
before the merge window. (And it needs to be ready *before*, not
during if I'm judging the prevailing winds correctly).
Cheers,
g.
>
> --
> Jon Smirl
> jonsmirl@gmail.com
>
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195
^ permalink raw reply
* Define termios_1 functions for powerpc, s390, avr32 and frv
From: Paul Mackerras @ 2007-09-12 15:16 UTC (permalink / raw)
To: Linus Torvalds, akpm
Cc: Michael Neuling, hskinnemoen, heiko.carstens, linux-kernel,
linuxppc-dev, Alan Cox, davem
Commit f629307c857c030d5a3dd777fee37c8bb395e171 introduced uses of
kernel_termios_to_user_termios_1 and user_termios_to_kernel_termios_1
on all architectures. However, powerpc, s390, avr32 and frv don't
currently define those functions since their termios struct didn't
need to be changed when the arbitrary baud rate stuff was added, and
thus the kernel won't currently build on those architectures.
This adds definitions of kernel_termios_to_user_termios_1 and
user_termios_to_kernel_termios_1 to include/asm-generic/termios.h
which are identical to kernel_termios_to_user_termios and
user_termios_to_kernel_termios respectively. The definitions are the
same because the "old" termios and "new" termios are in fact the same
on these architectures (which are the same ones that use
asm-generic/termios.h).
Signed-off-by: Paul Mackerras <paulus@samba.org>
---
Linus, this seems a bit cleaner than putting ifdefs in
drivers/char/tty_ioctl.c, and it fixes the compile error on powerpc.
Your choice whether to use this patch or Tony's.
diff --git a/include/asm-generic/termios.h b/include/asm-generic/termios.h
index 3769e6b..33dca30 100644
--- a/include/asm-generic/termios.h
+++ b/include/asm-generic/termios.h
@@ -63,6 +63,8 @@ static inline int kernel_termios_to_user_termio(struct termio __user *termio,
#define user_termios_to_kernel_termios(k, u) copy_from_user(k, u, sizeof(struct termios))
#define kernel_termios_to_user_termios(u, k) copy_to_user(u, k, sizeof(struct termios))
+#define user_termios_to_kernel_termios_1(k, u) copy_from_user(k, u, sizeof(struct termios))
+#define kernel_termios_to_user_termios_1(u, k) copy_to_user(u, k, sizeof(struct termios))
#endif /* __ARCH_TERMIO_GETPUT */
^ permalink raw reply related
* Re: [POWERPC] PCI Bug fix for MRM failure in PPC 440EPx
From: Kumar Gala @ 2007-09-12 15:14 UTC (permalink / raw)
To: Josh Boyer; +Cc: linuxppc-dev
In-Reply-To: <20070912094536.013bf903@weaponx.rchland.ibm.com>
On Sep 12, 2007, at 9:45 AM, Josh Boyer wrote:
> On Thu, 30 Aug 2007 10:33:28 +0200
> Stefan Roese <ml@stefan-roese.de> wrote:
>
>> Problem Description and Fix : Memory Read Multiples(MRM) do not work
>> correctly on PPC 440EPX based systems. A PCI driver determines
>> whether
>> MRMs are supported by reading the PCI cache line size register. If
>> this
>> value is zero then MRMs are not supported. However some PCI drivers
>> write to the PCI cache line size register on initialization. This
>> results in MRMs being sent to system memory on 440EPX based systems.
>> Since MRMs do not work correctly in 440EPX based systems this may
>> cause
>> system hang. This patch solves this problem by modifying the PPC
>> platform specific PCI configuration register write function, by
>> forcing
>> any value written to PCI_CACHE_LINE_SIZE register to be 0. This
>> fix was
>> tested on different PCI cards : i.e. Silicon Image ATA card and Intel
>> E1000 GIGE card. On Silicon Image ATA card without this fix in place
>> creating a filesystem on IDE drive "mke2fs /dev/hda" was hanging the
>> system. MRMs issued by the PCI card were seen on the PCI analyzer
>> since
>> the Silicon Image driver was setting the PCI_CACHE_LINE_SIZE
>> register to
>> 255. With this patch the PCI_CACHE_LINE_SIZE register was 0 and only
>> Memory Reads were seen on PCI analyzer.
>>
>> Signed-off-by: Pravin M. Bathija <pbathija@amcc.com>
>> Signed-off-by: Stefan Roese <sr@denx.de>
>>
>> ---
>> I know this patch is a little "dirty", but perhaps somebody has a
>> better
>> idea to fix this problem. Thanks.
>
> For the peanut gallery, Stefan and I discussed this a bit on IRC today
> and a different approach for arch/powerpc is going to be looked at
> instead. Namely, introducing a new flag for indirect_type in the
> pci_controller structure to key off of instead of having ifdefs.
I assume you'll be adding to the 'quirk' flags that we already have
in place.
- k
^ permalink raw reply
* Re: [PATCH 1/5] Add Freescale DMA and DMA channel to Documentation/powerpc/booting-without-of.txt file.
From: Scott Wood @ 2007-09-12 15:19 UTC (permalink / raw)
To: Zhang Wei-r63237; +Cc: linuxppc-dev, paulus, David Gibson
In-Reply-To: <46B96294322F7D458F9648B60E15112C85D755@zch01exm26.fsl.freescale.net>
On Wed, Sep 12, 2007 at 03:13:09AM -0700, Zhang Wei-r63237 wrote:
> I have a strange issue here. If I rename 'fsl,dma' to 'fsl,mpc8540-dma',
> the 'fsl,mpc8540-dma-channel' will be also regarded as DMA device not
> DMA channel.
What tree are you using? Commit 804ace8881d211ac448082e871dd312132393049
in Paul's git tree should have fixed that.
-Scott
^ permalink raw reply
* Re: new NAPI interface broken for POWER architecture?
From: Arnd Bergmann @ 2007-09-12 15:18 UTC (permalink / raw)
To: Christoph Raisch
Cc: ossthema, Paul Mackerras, netdev, Jan-Bernd Themann, linuxppc-dev,
Michael Ellerman, shemminger, David Miller
In-Reply-To: <OF2D6ED296.BDB04FBF-ONC1257354.00473703-C1257354.0048406C@de.ibm.com>
On Wednesday 12 September 2007, Christoph Raisch wrote:
> David Miller <davem@davemloft.net> wrote on 12.09.2007 14:50:04:
>
> > I agree that it should be fixed, but we should also fix the IRQ
> > distribution scheme used on powerpc platforms which is totally
> > broken in these cases.
>
> This is definitely not something we can change in the HEA device driver
> alone.
> It could also affect any other networking cards on POWER (e1000,s2io...).
>
> Paul, Michael, Arndt, what is your opinion here?
The situation on Cell with the existing south bridge chips is that
interrupts _never_ get moved around, but are routed to specific
SMT threads by the firmware, while Linux does not interfere with
this.
We have been thinking about changing this so we can distribute
interrupts over all SMT threads in a given NUMA node, or even
over all logical CPUs in the system by reprogramming the
interrupt controller after each interrupt, but the current Axon bridge
chip will always have all devices routed to the same target CPU,
so it's unclear whether that is even an advantage.
Arnd <><
^ permalink raw reply
* Patches for 2.6.24
From: Grant Likely @ 2007-09-12 15:48 UTC (permalink / raw)
To: Kumar Gala, linuxppc-dev, Paul Mackerras
Kumar, can you please pick up the following patches and push them to paulus?
http://patchwork.ozlabs.org/linuxppc-embedded/patch?id=11303
http://patchwork.ozlabs.org/linuxppc/patch?id=13235
http://patchwork.ozlabs.org/linuxppc/patch?id=13249
Thanks,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195
^ permalink raw reply
* Re: Patches for 2.6.24
From: Kumar Gala @ 2007-09-12 15:57 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <fa686aa40709120848x4720554jc46c8cd9ae3f355@mail.gmail.com>
On Sep 12, 2007, at 10:48 AM, Grant Likely wrote:
> Kumar, can you please pick up the following patches and push them
> to paulus?
>
> http://patchwork.ozlabs.org/linuxppc-embedded/patch?id=11303
I'll hand this one.
> http://patchwork.ozlabs.org/linuxppc/patch?id=13235
> http://patchwork.ozlabs.org/linuxppc/patch?id=13249
bootwrapper patches should be ack'd by david gibson and picked up by
paul at this point.
Did you have some other 834x defconfig updates as well?
- k
^ permalink raw reply
* Re: still using stabs debug format?
From: Kumar Gala @ 2007-09-12 16:00 UTC (permalink / raw)
To: bje, Ulrich Weigand
Cc: linuxppc-dev@ozlabs.org list, Paul Mackerras, Ed Swarthout
In-Reply-To: <0D968216-6743-498E-9723-F029FF3746C1@kernel.crashing.org>
Ben, Uli
Paul/BenH suggested that you might be able to help with my question.
> On Aug 17, 2007, at 7:54 PM, Segher Boessenkool wrote:
>
>>> Is anyone really still using the stabs format for kernel debug?
>>>
>>> can we kill off the .stabs references?
>>
>> What, you want to replace them with dwarf markup? Or just
>> get rid of the debug info completely?
>
> There are two users today:
>
> * N_SO for file information we can easily make into .file
> * N_FUN used in _GLOBAL() that marks it a 'function' is a bit
> misleading since we use this for both functions and data. Not sure
> what to do about that one, any suggestions?
#define _GLOBAL(n) \
.text; \
.stabs __stringify(n:F-1),N_FUN,0,0,n;\
.globl n; \
n:
this is the .stabs reference I'm trying to figure out what the dwarf
equiv would be.
- k
^ permalink raw reply
* Re: Patches for 2.6.24
From: Grant Likely @ 2007-09-12 16:02 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <B658701C-576E-459B-9FF4-BF43B429FCBB@kernel.crashing.org>
On 9/12/07, Kumar Gala <galak@kernel.crashing.org> wrote:
>
> On Sep 12, 2007, at 10:48 AM, Grant Likely wrote:
>
> > Kumar, can you please pick up the following patches and push them
> > to paulus?
> >
> > http://patchwork.ozlabs.org/linuxppc-embedded/patch?id=11303
>
> I'll hand this one.
>
> > http://patchwork.ozlabs.org/linuxppc/patch?id=13235
> > http://patchwork.ozlabs.org/linuxppc/patch?id=13249
>
> bootwrapper patches should be ack'd by david gibson and picked up by
> paul at this point.
Okay, David has already acked these. Paulus, can you please pick them up?
Thanks,
g.
>
> Did you have some other 834x defconfig updates as well?
I did; but it look like I need to rebase it again. I'll try to get
that done today.
Cheers,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195
^ permalink raw reply
* Re: PCI target implementation on AMCC PPC CPUs
From: David Hawkins @ 2007-09-12 16:04 UTC (permalink / raw)
To: Matthias Fuchs; +Cc: Leonid, linuxppc-embedded
In-Reply-To: <200709120917.29767.matthias.fuchs@esd-electronics.com>
Hi Matthias,
> I must admit, that the AMCC PowerPC's PCI interrupt capabilities could
> be better:-) In both directions the host CPU has to do PCI
> configuration cycles either to generate or acknowledge an interrupt.
> The later is problematic for some OS coming from Redmond: you
> have to do pci configuration cycles from interrupt level - and
> these OS do not 'like' that.
Yikes. I'm sure there were some headaches there.
> In later designs and where possible we also switched to alternative
> interrupt mechanisms (GPIO for target to host and gated flags in FPGA
> registers for the other direction). Multiple interrupt sources
> are identified by messages that are written to the other sides
> memory.
>
> I think we should stop this discussion because its a little bit
> off-topic on this list.
I think this particular piece of info is important on
this list. It'll help those looking for processor options
that happen to search back through the list messages.
I'm done now, I just wanted to satisfy my curiosity
(and I did learn how the host can interrupt the core!).
I know that Leonid has hardware with these CPUs on them,
and he wanted some feedback on the AMCCs as target processor.
I'd eliminated the processor before getting it fully into
a design; so your experience is a little further on.
However, the conclusion remains the same; try to avoid
using the 440EP as a PCI target device.
Cheers,
Dave
^ permalink raw reply
* Re: [PATCH] [RFC][POWERPC] Merge 32 and 64 bit pci_process_bridge_OF_ranges() instances
From: Vitaly Bordug @ 2007-09-12 16:07 UTC (permalink / raw)
To: Arnd Bergmann; +Cc: linuxppc-dev
In-Reply-To: <200709121013.51500.arnd@arndb.de>
On Wed, 12 Sep 2007 10:13:50 +0200
Arnd Bergmann wrote:
> On Wednesday 12 September 2007, Vitaly Bordug wrote:
>
> >
> > Well, it's more a rewrite than a move, based on 64-bit
> > implementation.
>
> ok.
>
> > > Could you perhaps split the patch into two separate changesets,
> > > one that makes both functions identical in place, and one that
> > > merges them to live in a common location?
> > >
> > I'm not sure I'm following what you are requesting. What is a
> > benefit of code duplication? I was thinking about, if it will look
> > good enough, to provide this function at generic level but changing
> > its name a little, while leaving old stuff in place, and
> > encouraging people to use it in favour of 32 or 64-bit-specific
> > approaches. That way we won't kill many boards at once(in case, for
> > example,odd dts with missed ranges for pci subnode).
>
> I wasn't suggesting to leave the duplicated code in, but rather to
> make the review easier by first modifying the code in place.
>
> If you're taking the 64 bit code as a base, you can for instance make
> the first patch leave pci_32 alone, and modify the 64 bit
> pci_process_bridge_OF_ranges to look exactly like the merged version.
> That allows us to see what changed in the 64 bit case.
>
> The second patch would then move the functions over, but leave the
> code identical to the result of the first patch.
>
ok, makes sense, will do it that way.
> > > > diff --git a/include/asm-powerpc/ppc-pci.h
> > > > b/include/asm-powerpc/ppc-pci.h index b847aa1..882b8bc 100644
> > > > --- a/include/asm-powerpc/ppc-pci.h
> > > > +++ b/include/asm-powerpc/ppc-pci.h
> > > > @@ -15,6 +15,13 @@
> > > > #include <linux/pci.h>
> > > > #include <asm/pci-bridge.h>
> > > >
> > > > +struct ranges_pci {
> > > > + unsigned int pci_space;
> > > > + u64 pci_addr;
> > > > + phys_addr_t phys_addr;
> > > > + u64 size;
> > > > +} __attribute__((packed));
> > > > +
> > >
> > > This structure definition uses unaligned members because of the
> > > 'packed' attribute. Is that really what you intended?
> > >
> > yes, exactly, because I'm mapping this struct on ranges extracted
> > from the dts instead of juggling with ranges[foo] offsets.
>
> I see. It does however look wrong to me, because you are using a
> hardcoded phys_addr_t type. This breaks when phys_addr has a
> different size from what you expect, e.g. when booting a pure 32 bit
> kernel on a machine that has a 64 bit physical address space.
>
I wondered around with "32 bit phys" and "64 bit phys" struct definitions first, but, well, it does not look good.
In fact it already verified with alike case (on 4xx), and I thought it would be fair tradeoff to have 64 bit ranges definition.
otoh, there might be cases when phys_addr_t is u64 and pci stuff resides on some 32-bit SoC bus. I will try to address that next iteration.
--
Sincerely, Vitaly
^ 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