* Re: [PATCH] pseries: asm/pci-bridge.h CONFIG_ minor cleanup
From: Michael Ellerman @ 2007-05-22 0:40 UTC (permalink / raw)
To: Linas Vepstas; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <20070521231816.GH5921@austin.ibm.com>
[-- Attachment #1: Type: text/plain, Size: 2325 bytes --]
On Mon, 2007-05-21 at 18:18 -0500, Linas Vepstas wrote:
> Use the correct CONFIG_ option to mark off the EEH bits.
> Move the EEH bits to the bottom of the struct.
>
> Signed-off-by: Linas Vepstas <linas@austin.ibm.com>
>
> ----
> include/asm-powerpc/pci-bridge.h | 15 ++++++++-------
> 1 file changed, 8 insertions(+), 7 deletions(-)
>
> Index: linux-2.6.22-rc1/include/asm-powerpc/pci-bridge.h
> ===================================================================
> --- linux-2.6.22-rc1.orig/include/asm-powerpc/pci-bridge.h 2007-05-21 18:13:00.000000000 -0500
> +++ linux-2.6.22-rc1/include/asm-powerpc/pci-bridge.h 2007-05-21 18:13:36.000000000 -0500
> @@ -70,19 +70,20 @@ struct pci_dn {
> int devfn; /* pci device and function number */
> int class_code; /* pci device class */
>
> -#ifdef CONFIG_PPC_PSERIES
> - int eeh_mode; /* See eeh.h for possible EEH_MODEs */
> - int eeh_config_addr;
> - int eeh_pe_config_addr; /* new-style partition endpoint address */
> - int eeh_check_count; /* # times driver ignored error */
> - int eeh_freeze_count; /* # times this device froze up. */
> -#endif
You're making the struct 4 bytes larger by creating a hole here :(
> int pci_ext_config_space; /* for pci devices */
> struct pci_controller *phb; /* for pci devices */
> struct iommu_table *iommu_table; /* for phb's or bridges */
> struct pci_dev *pcidev; /* back-pointer to the pci device */
> struct device_node *node; /* back-pointer to the device_node */
> +
> +#ifdef CONFIG_EEH
> + int eeh_mode; /* See eeh.h for possible EEH_MODEs */
> + int eeh_config_addr;
> + int eeh_pe_config_addr; /* new-style partition endpoint address */
> + int eeh_check_count; /* # times driver ignored error */
> + int eeh_freeze_count; /* # times this device froze up. */
> u32 config_space[16]; /* saved PCI config space */
> +#endif
It looks correct, but I think it's worth mentioning in the changelog
that config_space was previously unconditionally defined, but is now
within CONFIG_EEH.
cheers
--
Michael Ellerman
OzLabs, IBM Australia Development Lab
wwweb: http://michael.ellerman.id.au
phone: +61 2 6212 1183 (tie line 70 21183)
We do not inherit the earth from our ancestors,
we borrow it from our children. - S.M.A.R.T Person
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH 1/13] powerpc: Add Makefile rules to wrap dts file in zImage
From: David Gibson @ 2007-05-22 0:23 UTC (permalink / raw)
To: Mark A. Greer; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <20070521181043.GB7120@mag.az.mvista.com>
On Mon, May 21, 2007 at 11:10:43AM -0700, Mark A. Greer wrote:
> On Mon, May 14, 2007 at 10:33:32AM +1000, David Gibson wrote:
> > On Fri, May 11, 2007 at 05:53:36PM -0700, Mark A. Greer wrote:
> > > +$(obj)/zImage.dts: $(addprefix $(obj)/, $(dts-y))
> > > + @rm -f $@; ln $< $@
> > > +$(obj)/zImage.dts_initrd: $(addprefix $(obj)/, $(dts_initrd-y))
> > > + @rm -f $@; ln $< $@
> > > +
> >
> > I thought you said you were going to drop this bit?
>
> Hi David.
>
> Would you elaborate on what your alternative is? A lot of the Makefile
> stuff is still black magic to me.
Just leave them out. As long as you add the correct specific
zImage.dts.% and zImage.dts_initrd.% targets to image-y and initrd-y,
then a "make zImage" from the top-level Makefile will get them built.
You'd want to remove the .dts versions from BOOT_TARGETS, too.
--
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: Interrupt routing broken on TiBook IV with 2.6.21.x ?
From: Christian Böhme @ 2007-05-21 23:44 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev
In-Reply-To: <1179789304.32247.760.camel@localhost.localdomain>
Benjamin Herrenschmidt wrote:
> I'm not sure what you are talking about here. DMA mapping has existed in
> linux for years.
I do admit that it's been a while since that last look ;) The topic came up
when discussing PCI and bus systems in general with micro/real-time kernel
people whom I assumed to be experts in this since they had Linux kernels
running on top of their scheduling scheme. As it turned out, using an
abstraction such as a DMA map was a totally new concept to them. They
even questioned the usefulness of such an approach.
Cheers,
Christian
^ permalink raw reply
* [PATCH] pseries: asm/pci-bridge.h CONFIG_ minor cleanup
From: Linas Vepstas @ 2007-05-21 23:18 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev
Use the correct CONFIG_ option to mark off the EEH bits.
Move the EEH bits to the bottom of the struct.
Signed-off-by: Linas Vepstas <linas@austin.ibm.com>
----
include/asm-powerpc/pci-bridge.h | 15 ++++++++-------
1 file changed, 8 insertions(+), 7 deletions(-)
Index: linux-2.6.22-rc1/include/asm-powerpc/pci-bridge.h
===================================================================
--- linux-2.6.22-rc1.orig/include/asm-powerpc/pci-bridge.h 2007-05-21 18:13:00.000000000 -0500
+++ linux-2.6.22-rc1/include/asm-powerpc/pci-bridge.h 2007-05-21 18:13:36.000000000 -0500
@@ -70,19 +70,20 @@ struct pci_dn {
int devfn; /* pci device and function number */
int class_code; /* pci device class */
-#ifdef CONFIG_PPC_PSERIES
- int eeh_mode; /* See eeh.h for possible EEH_MODEs */
- int eeh_config_addr;
- int eeh_pe_config_addr; /* new-style partition endpoint address */
- int eeh_check_count; /* # times driver ignored error */
- int eeh_freeze_count; /* # times this device froze up. */
-#endif
int pci_ext_config_space; /* for pci devices */
struct pci_controller *phb; /* for pci devices */
struct iommu_table *iommu_table; /* for phb's or bridges */
struct pci_dev *pcidev; /* back-pointer to the pci device */
struct device_node *node; /* back-pointer to the device_node */
+
+#ifdef CONFIG_EEH
+ int eeh_mode; /* See eeh.h for possible EEH_MODEs */
+ int eeh_config_addr;
+ int eeh_pe_config_addr; /* new-style partition endpoint address */
+ int eeh_check_count; /* # times driver ignored error */
+ int eeh_freeze_count; /* # times this device froze up. */
u32 config_space[16]; /* saved PCI config space */
+#endif
};
/* Get the pointer to a device_node's pci_dn */
^ permalink raw reply
* Re: Interrupt routing broken on TiBook IV with 2.6.21.x ?
From: Benjamin Herrenschmidt @ 2007-05-21 23:15 UTC (permalink / raw)
To: Christian Böhme; +Cc: linuxppc-dev
In-Reply-To: <4652219D.6050308@gmx.de>
On Tue, 2007-05-22 at 00:47 +0200, Christian Böhme wrote:
> It's not that I am not interested nor completely new to this, it's just that
> I am currently a little short on time for things like these. The last time
> I checked, the Linux people have just started to make use of DMA maps, a
> concept that other OS/architecture combos employed for years already. Is
> that what is used in the TiBooks to allocate DMA channels ?
I'm not sure what you are talking about here. DMA mapping has existed in
linux for years.
Ben.
^ permalink raw reply
* Re: Interrupt routing broken on TiBook IV with 2.6.21.x ?
From: Christian Böhme @ 2007-05-21 22:47 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev
In-Reply-To: <1179785502.32247.748.camel@localhost.localdomain>
Benjamin Herrenschmidt wrote:
> Or it could be the DMA channel going dead though I fail to see why it
> would just start doing that now.
...
> Not sure where to start :-) I'll first see if I can reproduce.
It's not that I am not interested nor completely new to this, it's just that
I am currently a little short on time for things like these. The last time
I checked, the Linux people have just started to make use of DMA maps, a
concept that other OS/architecture combos employed for years already. Is
that what is used in the TiBooks to allocate DMA channels ?
Cheers,
Christian
^ permalink raw reply
* Re: Interrupt routing broken on TiBook IV with 2.6.21.x ?
From: Benjamin Herrenschmidt @ 2007-05-21 22:11 UTC (permalink / raw)
To: Christian Böhme; +Cc: linuxppc-dev
In-Reply-To: <4651FC48.8000002@gmx.de>
On Mon, 2007-05-21 at 22:08 +0200, Christian Böhme wrote:
> Benjamin Herrenschmidt wrote:
>
> > Nope... it can't be a routing problem since interrupt -is- routed (you
> > are getting it !)
>
> Actually, these were the exact words from the ALSA developer. For some
> reason, however, the interrupt count does not increase after some (variable)
> time. It looks as if the ALSA code waits for but not receiving them. After
> a restart, an audio signal does leave the jack and the interrupt count
> increases but only for about a second (sometimes more, often less). No idea
> whether interrupts must be routed/are routable on this very machine I have at
> all ...
Or it could be the DMA channel going dead though I fail to see why it
would just start doing that now.
> > Which exact tipb model is this ? (cat /proc/device-tree/model)
>
> PowerBook3,5 of the 2002-11 release variety.
Ok, I think I have access to one of these, I'll try to reproduce myself.
> I stuck to OSS up to the 2.6.19.x kernels where everything (surprisingly)
> ``just worked''. Then came the 2.6.20.x series and <root>/sound/oss/\
> dmasound/dmasound_awacs.c started spitting out loads of ``tx-irq: xfer died -
> patching it up...'' messages with stuttering audio output but nothing
> different in their respective implementations from 2.6.19.x to 2.6.20.x.
>
> Is there anything particular I can dive into myself to expedite finding the
> cause of the problem without learning the full details of the PPC implemen-
> tation ?
Not sure where to start :-) I'll first see if I can reproduce.
Cheers,
Ben.
^ permalink raw reply
* Re: vm changes from linux-2.6.14 to linux-2.6.15
From: Benjamin Herrenschmidt @ 2007-05-21 22:09 UTC (permalink / raw)
To: Tom "spot" Callaway
Cc: mark, linux-mm, wli, linuxppc-dev, andrea, sparclinux,
Hugh Dickins, akpm, David Miller
In-Reply-To: <1179757647.6254.235.camel@localhost.localdomain>
On Mon, 2007-05-21 at 09:27 -0500, Tom "spot" Callaway wrote:
> On Tue, 2007-05-15 at 16:56 +1000, Benjamin Herrenschmidt wrote:
> > > Ok, I'll cook a patch today.
> >
> > Let's make it tomorrow :-( Got delayed by other urgent things
>
> Not to be annoying, but I'm patiently waiting on this patch. Would like
> to test sun4c before shipping Aurora 3.0. Any status?
Damn, kick me harder ! I totally forgot... probably what happens when
one is deep into bringing up some new HW toys !
Sorry about that, I'll do it asap.
Cheers
Ben.
^ permalink raw reply
* Re: fsl booke MM vs. SMP questions
From: Benjamin Herrenschmidt @ 2007-05-21 22:07 UTC (permalink / raw)
To: Dave Liu; +Cc: ppc-dev, Paul Mackerras, Kumar Gala
In-Reply-To: <1179747448.3660.22.camel@localhost.localdomain>
> > The tlb miss handler does:
> >
> > - tlbbusy = 1
> > - barrier (make sure the following read is in order vs. the previous
> > store to tlbbusy)
> > - read linux PTE value
> > - write it to the HW TLB
>
> and write the linux PTE with referenced bit?
I've kept the reference bit rewrite out of that pseudo-code because I
was approaching a different issue but yes. The idea i have there is to
do break down the linux PTE operation that way:
1 - rX = read PTE value (normal load)
2 - if (!_PAGE_PRESENT)) -> out
3 - rY = rX | _PAGE_ACCESSED
4 - if (rX != rY)
5 - rZ = lwarx PTE value
6 - if (rZ != rX)
7 - stdcx. PTE, rZ (rewrite just read value to clear reserv)
8 - goto 1 (try again)
9 - stdcx. PTE, rY
10 - if failed -> goto 1 (try again)
11 - that's it !
In addition, I suppose performance can be improved by also dealing with
dirty bit right in the TLB refill if the access is a write and the page
is writeable rather than taking a double fault.
> > - appropriate sync
> > - tlbbusy = 0
> >
> > Now, the tlb invalidation code (which can use a batch to be even more
> > efficient, see how 64 bits or x86 use batching for TLB invalidations)
> > can then use the fact that the mm carries a cpu bitmask of all CPUs that
> > ever touched that mm and thus can do, after a PTE has changed and before
> > broadcasting an invalidation:
>
> How to interlock this PTE change with the PTE change of tlb miss?
Look at pgtables-ppc32.h. PTE changes done by linux are atomic. If you
use the procedure I outlined above, you will also have PTE modifications
done by the TLB miss handler be atomic, though you also skip the atomic
bit when not necessary (when _PAGE_ACCESSED is already set for example).
Thus, the situation is basically that linux PTE changes need to
- update the PTE
- barrier
- make sure that change is visible to all other CPUs and that
they all have been out of a TLB miss handler at least once
which is what my proposed algorithm does
- broadcast invalidation
> > - make a local copy "mask" of the mm->cpu_vm_mask
> > - clear bit for the current cpu from the mask
> > - while there is still a bit in the mask
> > - for each bit in the mask, check if tlbbusy for that cpu is 0
> > -> if 0, clear the bit in the mask
> > - loop until there's nop more bit in the mask
> > - perform the tlbivax
>
> It looks like good idea, but what is the bad things with the batch
> invalidation?
Why bad ?
Batch invalidations allow you to do the whole operation of sync'ing with
other CPUs only once for a whole lot of invalidations:
- clear lots of PTEs
- sync once
- send lots of tlbivax
You don't have to implement batch invalidates but it will improve
performances.
> > In addition, if you have a "local" version of tlbivax (no broadcast),
> > you can do a nice optimisation if after step 2 (clear bit for the
> > current cpu) the mask is already 0 (that means the mm only ever existed
> > on the local cpu), in which case you can do a local tlbivax and return.
>
> The BookE has the "local" version of tlbivax with the tlbwe inst. Yes,
> It actually can reduce the bus traffic.
And is probably faster too :-)
The above method need to also be looked at carefully for the TLB storage
interrupt (that is TLB present but with wrong permission).
Ben.
^ permalink raw reply
* Re: [PATCH] power-management elements for 603e/fsl (version 2)
From: Guennadi Liakhovetski @ 2007-05-21 20:50 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev, Johannes Berg, Paul Mackerras
In-Reply-To: <20070521155712.GA16235@ld0162-tx32.am.freescale.net>
On Mon, 21 May 2007, Scott Wood wrote:
> On Sat, May 19, 2007 at 09:22:10PM +0200, Guennadi Liakhovetski wrote:
> > + local_irq_disable();
>
> IRQs are already disabled when this function is called.
ok
> > + /* go zzzzz... (re-enabling interrupts) */
> > + fsl_low_sleep();
>
> IRQs really shouldn't be enabled here without something like the "Handle
> HID0_SLEEP in the TLF_NAPPING hack" patch I posted recently.
Ok, I'd be happy to rely on those your patches... as long as they make it
into the kernel. Paulus, what's the plan? I'll try to apply them locally
for now and adjust my code accordingly. A recent powerpc.git should be
fine, I guess - the arch_suspend_{disable,enable}_irqs hooks are already
there, or are there any further dependencies?
> > + /* Re-enable local CPU interrupts */
> > + local_irq_enable();
>
> Just leave them off.
ok
> > @@ -112,10 +155,15 @@ static int __init ls_uarts_init(void)
> >
> > avr_clock = *(u32*)of_get_property(avr, "clock-frequency", &len);
> > phys_addr = ((u32*)of_get_property(avr, "reg", &len))[0];
> > + irq = ((u32*)get_property(avr, "interrupts", &len))[0];
>
> Oopsing if a property is missing isn't nice.
Hm, it is in .dts in the kernel tree, do I still have to care a possible
non-compliant version? Probably, you're right, will fix.
> > + local_irq_save(flags);
> > + /* Apparently, MacOS uses NAP mode for Grackle ??? */
> > + pmcr1 &= ~(MPC10X_DOZE | MPC10X_NAP);
> > + pmcr1 |= MPC10X_PM | MPC10X_SLEEP | MPC10X_LP_REF_EN;
> > + pci_write_config_word(bridge, 0x70, pmcr1);
> > + local_irq_restore(flags);
>
> This should probably be something like mpc10x_suspend. Also, IRQs should
> already be disabled when this is called.
well, I'd also prefer a more specific namespace than "fsl." Would it be ok
to call them with mpc10x (has been discussed on irc, I remember there have
been objections against this as mpc10x are just some host-pci bridges from
older Apple (not only?) machines)? And if we use mpc10x, is it ok to leave
them in fsl_soc.c?
> > + /* Make sure the decrementer won't interrupt us */
> > + asm volatile("mtdec %0" : : "r" (0x7fffffff));
> > + /* Make sure any pending DEC interrupt occurring while we did
> > + * the above didn't re-enable the DEC */
> > + mb();
> > + asm volatile("mtdec %0" : : "r" (0x7fffffff)); /* 8 seconds */
>
> IRQs are already disabled here, so if it was pending it still will be (at
> least with some cores). It needs to be done with the arch suspend hook.
as above, will test with your patches.
Thanks for comments!
Guennadi
---
Guennadi Liakhovetski
^ permalink raw reply
* Re: Interrupt routing broken on TiBook IV with 2.6.21.x ?
From: Christian Böhme @ 2007-05-21 20:08 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev
In-Reply-To: <1179712614.32247.597.camel@localhost.localdomain>
Benjamin Herrenschmidt wrote:
> Nope... it can't be a routing problem since interrupt -is- routed (you
> are getting it !)
Actually, these were the exact words from the ALSA developer. For some
reason, however, the interrupt count does not increase after some (variable)
time. It looks as if the ALSA code waits for but not receiving them. After
a restart, an audio signal does leave the jack and the interrupt count
increases but only for about a second (sometimes more, often less). No idea
whether interrupts must be routed/are routable on this very machine I have at
all ...
> Which exact tipb model is this ? (cat /proc/device-tree/model)
PowerBook3,5 of the 2002-11 release variety.
I stuck to OSS up to the 2.6.19.x kernels where everything (surprisingly)
``just worked''. Then came the 2.6.20.x series and <root>/sound/oss/\
dmasound/dmasound_awacs.c started spitting out loads of ``tx-irq: xfer died -
patching it up...'' messages with stuttering audio output but nothing
different in their respective implementations from 2.6.19.x to 2.6.20.x.
Is there anything particular I can dive into myself to expedite finding the
cause of the problem without learning the full details of the PPC implemen-
tation ?
Cheers,
Christian
^ permalink raw reply
* Re: [PATCH 1/13] powerpc: Add Makefile rules to wrap dts file in zImage
From: Mark A. Greer @ 2007-05-21 18:10 UTC (permalink / raw)
To: Mark A. Greer, Paul Mackerras, linuxppc-dev
In-Reply-To: <20070514003332.GE6517@localhost.localdomain>
On Mon, May 14, 2007 at 10:33:32AM +1000, David Gibson wrote:
> On Fri, May 11, 2007 at 05:53:36PM -0700, Mark A. Greer wrote:
> > +$(obj)/zImage.dts: $(addprefix $(obj)/, $(dts-y))
> > + @rm -f $@; ln $< $@
> > +$(obj)/zImage.dts_initrd: $(addprefix $(obj)/, $(dts_initrd-y))
> > + @rm -f $@; ln $< $@
> > +
>
> I thought you said you were going to drop this bit?
Hi David.
Would you elaborate on what your alternative is? A lot of the Makefile
stuff is still black magic to me.
Thanks,
Mark
^ permalink raw reply
* Re: vm changes from linux-2.6.14 to linux-2.6.15
From: Tom "spot" Callaway @ 2007-05-21 14:27 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: mark, linux-mm, wli, linuxppc-dev, andrea, sparclinux,
Hugh Dickins, akpm, David Miller
In-Reply-To: <1179212184.32247.163.camel@localhost.localdomain>
On Tue, 2007-05-15 at 16:56 +1000, Benjamin Herrenschmidt wrote:
> > Ok, I'll cook a patch today.
>
> Let's make it tomorrow :-( Got delayed by other urgent things
Not to be annoying, but I'm patiently waiting on this patch. Would like
to test sun4c before shipping Aurora 3.0. Any status?
~spot
^ permalink raw reply
* Re: [PATCH] remove geometry support from ps3 storage driver
From: Olaf Hering @ 2007-05-21 17:14 UTC (permalink / raw)
To: Christoph Hellwig; +Cc: linuxppc-dev
In-Reply-To: <20070521143938.GA20321@lst.de>
On Mon, May 21, Christoph Hellwig wrote:
> On Mon, May 21, 2007 at 02:53:11PM +0200, Olaf Hering wrote:
> >
> > The old ps3_storage driver did not support DOS geometry, so there is no
> > point to start adding code for it.
>
> That's not quite true. sd applies some heuristics and has a default
> geometry if there is no ->bios_param method. Then again this whole
> gemetry thing really only makes sense on x86.
Ok, if it really matters, the values should match sd.
^ permalink raw reply
* Re: [PATCH 2/5] Add legacy devices to mpc8641_hpcn.dts
From: Wade Farnsworth @ 2007-05-21 16:51 UTC (permalink / raw)
To: Jon Loeliger; +Cc: linuxppc-dev
In-Reply-To: <1179763854.13019.8.camel@ld0161-tx32>
On Mon, 2007-05-21 at 11:10 -0500, Jon Loeliger wrote:
> On Mon, 2007-05-21 at 11:04, Wade Farnsworth wrote:
>
> > I wonder if you're running into the locked RTC problem on the m1575.
> > The version of u-boot that I'm using (recent pull from
> > opensource.freescale.com)
>
> Which repository? I ask because it is highly likely that
> I placed it there...
http://opensource.freescale.com/pub/scm/u-boot-jdl.git
>
> > has a workaround for that. Can you verify if
> > this is the problem?
>
> Can you point to "the workaround" to which you refer?
commit a59a76edd7c475329c083d5c21f6bca8bb5b8476
Re-enable a PCIE hack access for RTC on 8641HPCN.
>
> > For the benefit of those who aren't aware of the problem, the RTC on the
> > m1575 is locked on boot until PCI memory space is read.
>
> Hmmm. I'm pretty sure this is being done already.
If you're sure your u-boot is doing this, then maybe it is a
configuration problem after all.
>
> > Maybe we should put the workaround in the kernel instead. Any opinions?
>
> How are you getting it to work now as it is, then?
In addition to the u-boot hack, I have the following config options
enabled:
CONFIG_PCI=y
CONFIG_RTC_LIB=y
CONFIG_RTC_CLASS=y
CONFIG_RTC_HCTOSYS=y
CONFIG_RTC_HCTOSYS_DEVICE="rtc0"
CONFIG_RTC_INTF_SYSFS=y
CONFIG_RTC_INTF_PROC=y
CONFIG_RTC_INTF_DEV=y
CONFIG_RTC_DRV_CMOS=y
I believe this is all you should need to enable the RTC. You should
then see a boot message indicating that the system clock has been set:
rtc_cmos rtc_cmos: setting the system clock to 2007-05-21 21:29:13
(1179782953)
In order to use hwclock to access the RTC you have to make a symlink
from /dev/rtc0 to /dev/rtc.
--Wade
^ permalink raw reply
* Re: [PATCH 2/5] Add legacy devices to mpc8641_hpcn.dts
From: Jon Loeliger @ 2007-05-21 16:10 UTC (permalink / raw)
To: Wade Farnsworth; +Cc: linuxppc-dev
In-Reply-To: <1179763484.8132.293.camel@rhino>
On Mon, 2007-05-21 at 11:04, Wade Farnsworth wrote:
> I wonder if you're running into the locked RTC problem on the m1575.
> The version of u-boot that I'm using (recent pull from
> opensource.freescale.com)
Which repository? I ask because it is highly likely that
I placed it there...
> has a workaround for that. Can you verify if
> this is the problem?
Can you point to "the workaround" to which you refer?
> For the benefit of those who aren't aware of the problem, the RTC on the
> m1575 is locked on boot until PCI memory space is read.
Hmmm. I'm pretty sure this is being done already.
> Maybe we should put the workaround in the kernel instead. Any opinions?
How are you getting it to work now as it is, then?
jdl
^ permalink raw reply
* Re: [PATCH 2/5] Add legacy devices to mpc8641_hpcn.dts
From: Wade Farnsworth @ 2007-05-21 16:04 UTC (permalink / raw)
To: Jon Loeliger; +Cc: linuxppc-dev
In-Reply-To: <1179506692.19188.2.camel@ld0161-tx32>
On Fri, 2007-05-18 at 11:44 -0500, Jon Loeliger wrote:
>
> And I haven't actually gotten it to work yet either...
> Am I missing something? Like a CONFIG_ option beyond
> the RTC and CMOS variant that is necessary?
>
> Dumbly,
> jdl
>
>
I wonder if you're running into the locked RTC problem on the m1575.
The version of u-boot that I'm using (recent pull from
opensource.freescale.com) has a workaround for that. Can you verify if
this is the problem?
For the benefit of those who aren't aware of the problem, the RTC on the
m1575 is locked on boot until PCI memory space is read.
Maybe we should put the workaround in the kernel instead. Any opinions?
^ permalink raw reply
* RE: [PATCH 5/5] PCI fixes for the MPC8641 Rev 2.0 silicon and Rev1.02hardware
From: Wade Farnsworth @ 2007-05-21 16:01 UTC (permalink / raw)
To: Zhang Wei-r63237; +Cc: linuxppc-dev
In-Reply-To: <46B96294322F7D458F9648B60E15112C23466B@zch01exm26.fsl.freescale.net>
On Fri, 2007-05-18 at 18:20 +0800, Zhang Wei-r63237 wrote:
> For support rev 1.0 boards, you can only remove the
> pci@00:pci@00:interrupt-map sector. The pci driver can use
> pci@8000:interrupt-map for irq mapping.
>
> Such as below:
>
> diff --git a/arch/powerpc/boot/dts/mpc8641_hpcn.dts
> b/arch/powerpc/boot/dts/mpc8641_hpcn.dts
> index 260b264..04626b1 100644
> --- a/arch/powerpc/boot/dts/mpc8641_hpcn.dts
> +++ b/arch/powerpc/boot/dts/mpc8641_hpcn.dts
> @@ -297,6 +297,12 @@
> interrupts = <49 2>;
> interrupt-parent = <&mpic>;
> };
> + uli1575: uli1575@100 {
> + reg = <0 0 0 0 0>;
> + pci_bridge@200 {
> + reg = <0 0 0 0 0>;
> + };
> + };
>
> };
>
> Cheers,
> Wei
Hmm. For some reason I thought that wouldn't work, but after some
testing it appears I was wrong. I'll incorporate that into the next
version of the patchset.
Thanks.
--Wade
^ permalink raw reply
* RE: [PATCH 5/5] PCI fixes for the MPC8641 Rev 2.0 silicon and Rev1.02 hardware
From: Wade Farnsworth @ 2007-05-21 15:59 UTC (permalink / raw)
To: Jin Zhengxiong-R64188; +Cc: linuxppc-dev
In-Reply-To: <CC27DED0F8F39E48A7E75FD768688B7A2FD493@zch01exm27.fsl.freescale.net>
On Fri, 2007-05-18 at 14:52 +0800, Jin Zhengxiong-R64188 wrote:
>
> As you changed the class of the bridge, dev->transparent will be set
> again in the later code, if you remove the 0x01 here, the
> dev->transparent will be set to 0 later. So if you changed the class
> like this, you do not need to set dev->transparent = 1 in your patch.
>
> Jason
It is my understanding that neither dev->transparent, nor that bit in
the PCI class should be set.
--Wade
^ permalink raw reply
* Re: [PATCH] power-management elements for 603e/fsl (version 2)
From: Scott Wood @ 2007-05-21 15:57 UTC (permalink / raw)
To: Guennadi Liakhovetski; +Cc: linuxppc-dev, Johannes Berg, Paul Mackerras
In-Reply-To: <Pine.LNX.4.60.0705192013010.10162@poirot.grange>
On Sat, May 19, 2007 at 09:22:10PM +0200, Guennadi Liakhovetski wrote:
> +static int ls_pm_enter(suspend_state_t state)
> +{
> + char ier;
> + int ret = 0;
> + u64 tb;
> +
> + /* Stop preemption */
> + preempt_disable();
> +
> + if ((ret = fsl_suspend(state)) < 0) {
> + preempt_enable();
> + return ret;
> + }
> +
> + local_irq_disable();
IRQs are already disabled when this function is called.
> + /* go zzzzz... (re-enabling interrupts) */
> + fsl_low_sleep();
IRQs really shouldn't be enabled here without something like the "Handle
HID0_SLEEP in the TLF_NAPPING hack" patch I posted recently.
> + /* Re-enable local CPU interrupts */
> + local_irq_enable();
Just leave them off.
> @@ -112,10 +155,15 @@ static int __init ls_uarts_init(void)
>
> avr_clock = *(u32*)of_get_property(avr, "clock-frequency", &len);
> phys_addr = ((u32*)of_get_property(avr, "reg", &len))[0];
> + irq = ((u32*)get_property(avr, "interrupts", &len))[0];
Oopsing if a property is missing isn't nice.
> +
> +#ifdef CONFIG_PM
> +#include <linux/pci.h>
> +#include <asm/pci-bridge.h>
> +
> +#define MPC10X_LP_REF_EN (1<<12)
> +#define MPC10X_PM (1<<7)
> +#define MPC10X_DOZE (1<<5)
> +#define MPC10X_NAP (1<<4)
> +#define MPC10X_SLEEP (1<<3)
> +
> +int fsl_suspend(suspend_state_t state)
> +{
> + struct pci_dev *bridge;
> + unsigned long flags;
> + u16 pmcr1;
> +
> + bridge = pci_find_slot(0, 0);
> + if (!bridge)
> + return -ENODEV;
> +
> + pci_read_config_word(bridge, 0x70, &pmcr1);
> + local_irq_save(flags);
> + /* Apparently, MacOS uses NAP mode for Grackle ??? */
> + pmcr1 &= ~(MPC10X_DOZE | MPC10X_NAP);
> + pmcr1 |= MPC10X_PM | MPC10X_SLEEP | MPC10X_LP_REF_EN;
> + pci_write_config_word(bridge, 0x70, pmcr1);
> + local_irq_restore(flags);
This should probably be something like mpc10x_suspend. Also, IRQs should
already be disabled when this is called.
> + /* Make sure the decrementer won't interrupt us */
> + asm volatile("mtdec %0" : : "r" (0x7fffffff));
> + /* Make sure any pending DEC interrupt occurring while we did
> + * the above didn't re-enable the DEC */
> + mb();
> + asm volatile("mtdec %0" : : "r" (0x7fffffff)); /* 8 seconds */
IRQs are already disabled here, so if it was pending it still will be (at
least with some cores). It needs to be done with the arch suspend hook.
-Scott
^ permalink raw reply
* Re: [PATCH] set module owner in ps3 modules
From: Geoff Levand @ 2007-05-21 15:52 UTC (permalink / raw)
To: Olaf Hering; +Cc: linuxppc-dev
In-Reply-To: <20070521125426.GA27730@aepfle.de>
Olaf Hering wrote:
> setting ->owner will help with refcounting (?) and it provides proper
> symlinks in sysfs.
Thanks. I'm in the middle of re-doing the system bus and drivers to
work as loadable modules, and this will help.
-Geoff
^ permalink raw reply
* RE: BDI2000 configuration file for MPC8313E-RDB
From: Leonid @ 2007-05-21 15:27 UTC (permalink / raw)
To: Frank Prepelica; +Cc: linuxppc-embedded
In-Reply-To: <29DC34A6B43468409F5A371CFE34E8491768E6@ex01.ads.ubidyne.de>
On Monday, May 21, 2007 12:25 AM Frank Prepelica wrote:
> Sorry, but the BDI does not support programming any NAND flash.
> You can write your own driver. Then load the data and the driver into=20
> SDRAM via the BDI and execute it.
> Well, I think I have to try this, if there's really no other way.=20
> I'm not quite sure, maybe you know the PowerTAB Pro JTAG Debugger,
> (it's recommended in the manuals) could this one get directly access
> to NAND memory?
No, I don't but I would like to learn more about NAND flash programmers.
> Uhm, it's possible that achieved that in an "indirect" way that I was
> not aware of. But as I said, the complete flash and ram was empty,
just
> loaded=20
> the corresponding BDI config file to BDI2000 JTAG and I got access to
> flash memory where I placed the bootloader image. Hmm, anyway ;)
> The BDI config: http://www.ultsol.com/config/Emb%20Planet/83xx.cfg
It's still not clear from your description what has been done - "I got
access to flash memory" sounds too vague. It's quite possible that SW
you are using does the trick; at least you have some file, loaded from
the host to RAM:
[HOST]
IP 10.0.0.198
FILE PCB82xx120.ep
Where did you get this PCB82xx120.ep file from?
In any rate, FLASH section of this configuration file specifies NOR
flash so it's out of question that BDI2000 could program NAND by itself:
[FLASH]
CHIPTYPE MIRRORX16 ;Flash type: Micron Q-Flash MT28F640J3
Moreover, since workspace is disabled, direct image programming shall be
really slooow - you had to notice that. Did you? Most likely not - SW
burned your flash.
Best regards
Leonid.
^ permalink raw reply
* Re: [i2c] [PATCH 3/5] powerpc: Document device nodes for I2C devices.
From: Scott Wood @ 2007-05-21 14:57 UTC (permalink / raw)
To: Jean Delvare; +Cc: linuxppc-dev, i2c
In-Reply-To: <20070520135353.6b4dba0b@hyperion.delvare>
Jean Delvare wrote:
> Hi Scott,
>
> On Fri, 18 May 2007 12:55:45 -0500, Scott Wood wrote:
>
>>Fair enough. I'm still interested in what you think would need to be
>>done to support switches and muxes, from the context of standardizing it
>>in ePAPR. The bus numbering shouldn't be an issue as long as you keep
>>the bus numbers local to the switch/mux, and don't pretend that they
>>have anything to do with any global i2c bus number that the OS may or
>>may not have.
>
>
> But then you cannot declare devices on these segments and expect Linux
> to instantiate them. You'll have to wait for the segments to be created
> and only then you'll be able to create the devices on them (using
> i2c_new_device()).
You can declare devices by having platform code assign Linux bus numbers
to them, just as with non-switched buses. Of course, platform code
would have to know about the switch to do that; it may be easier to just
have the platform code register the switch driver and pass it a device
tree node (or more generally, something opaque in platform data that
gets passed back to platform code for registration) to do
i2c_new_device()-based enumeration.
> Also, what's the point of giving numbers to the segments in the first
> place, if they don't correspond to anything?
The switch-local bus numbers are used to tell the switch which bus is
being accessed. The Linux bus numbers are used for device
preregistration and user API.
They're both used, just for different purposes.
-Scott
^ permalink raw reply
* Re: [PATCH] remove geometry support from ps3 storage driver
From: Christoph Hellwig @ 2007-05-21 14:39 UTC (permalink / raw)
To: Olaf Hering; +Cc: linuxppc-dev
In-Reply-To: <20070521125311.GA27626@aepfle.de>
On Mon, May 21, 2007 at 02:53:11PM +0200, Olaf Hering wrote:
>
> The old ps3_storage driver did not support DOS geometry, so there is no
> point to start adding code for it.
That's not quite true. sd applies some heuristics and has a default
geometry if there is no ->bios_param method. Then again this whole
gemetry thing really only makes sense on x86.
^ permalink raw reply
* Re: [PATCH] remove geometry support from ps3 storage driver
From: Geert Uytterhoeven @ 2007-05-21 14:36 UTC (permalink / raw)
To: Olaf Hering; +Cc: linuxppc-dev
In-Reply-To: <20070521125311.GA27626@aepfle.de>
Hi Olaf,
On Mon, 21 May 2007, Olaf Hering wrote:
> The old ps3_storage driver did not support DOS geometry, so there is no
> point to start adding code for it.
Thanks! I didn't know the .getgeo() routine is optional. I thought it was used
by disk partitioning software.
cfdisk seems to be happy after this change.
sfdisk complains it cannot get the geometry, but it continuous, assuming H=64
and S=32.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- Sony Network and Software Technology Center Europe (NSCE)
Geert.Uytterhoeven@sonycom.com ------- The Corporate Village, Da Vincilaan 7-D1
Voice +32-2-7008453 Fax +32-2-7008622 ---------------- B-1935 Zaventem, Belgium
^ 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