> Roland McGrath writes:
>
> > This requires the earlier HAVE_SET_RESTORE_SIGMASK patch series.
> > This does the same for powerpc that I posted the x86 change for.
>
> ...
>
> > +static inline void set_restore_sigmask(void)
> > +{
> > + struct thread_info *ti = current_thread_info();
> > +
On Wed, Apr 23, 2008 at 03:41:39PM +1000, Michael Ellerman wrote:
> You add about 30 lines of code in this patch, which you remove in patch
> 3, is there a better way to do it?
>
> Is there any harm dynamically initialising the statically initialised
> pacas, I think that would allow you to basi
On Tue, 2008-04-22 at 15:22 +0200, Segher Boessenkool wrote:
> +static void fsl_compose_msi_msg(struct pci_dev *pdev, int hwirq,
> + struct msi_msg *msg)
>
> > No I mean I'm confused about the maths here. If we pull out the
> > variables it boils down to:
On Tue, 2008-04-22 at 08:31 -0500, Olof Johansson wrote:
> On Fri, Apr 18, 2008 at 05:54:36PM +1000, Michael Ellerman wrote:
> > Signed-off-by: Michael Ellerman <[EMAIL PROTECTED]>
>
> I know it's fun to see yourself in the changeset statistics, but this is
> silly. Please bake together all the si
On Fri, 2008-04-18 at 18:20 +1000, Benjamin Herrenschmidt wrote:
> On Fri, 2008-04-18 at 17:54 +1000, Michael Ellerman wrote:
> > In theory the udbg console should be safe to call basically at any time
> > after boot. It does not need any per-cpu resources or for the cpu to be
> > online, as long a
On Wed, 2008-04-23 at 14:06 +1000, Tony Breeds wrote:
> As the pacas are statically initialised increasing NR_CPUS beyond 128,
> means that any additional pacas will be empty ... which is bad.
>
> This patch adds the required functionality to fill in any excess pacas
> at runtime.
>
> Signed-off
On Wed, 2008-04-23 at 07:06 +0200, Markus Brunner wrote:
> On Wednesday 16 April 2008, Benjamin Herrenschmidt wrote:
>
> > Somebody knows off hand what the standard says the timeout should be ?
>
> Anyone?
>
> I didn't find any documentation on the standard, but I had a look at other
> drivers
This patch doubles the MDIO timeouts in EMAC as there are field
cases where they are two short to communicate with some PHYs.
Signed-off-by: Benjamin Herrenschmidt <[EMAIL PROTECTED]>
---
drivers/net/ibm_newemac/core.c |8
1 file changed, 4 insertions(+), 4 deletions(-)
--- linux-w
On Wednesday 16 April 2008, Benjamin Herrenschmidt wrote:
> Somebody knows off hand what the standard says the timeout should be ?
Anyone?
I didn't find any documentation on the standard, but I had a look at other
drivers.
au1000_eth.c waits 20 ms (20 * 1ms) in mdio_read.
bfin_mac.c waits 500
Roland McGrath writes:
> This requires the earlier HAVE_SET_RESTORE_SIGMASK patch series.
> This does the same for powerpc that I posted the x86 change for.
...
> +static inline void set_restore_sigmask(void)
> +{
> + struct thread_info *ti = current_thread_info();
> + ti->local_flags |=
Mathieu Desnoyers writes:
> Subject: [RFC patch 6/9] Re: [PATCH] Stringify support commas
> > This is a no-no for those archs that still use -traditional.
> > > I dunno if this is a problem for you at the moment and the
> > > right fix is anyway to nuke -traditional.
> > >
> > > Sam
>
>
On Tue, 2008-04-08 at 23:36 +0200, Johannes Berg wrote:
> > > This version fixes the clobbering of r12 by the call to
> > > trace_hardirqs_off() that was pointed out by BenH.
> > >
> > > Johannes, I'd appreciate your trying this version if/when
> > > you get the chance.
> >
> > Thanks Dale, this
With NR_CPUS=1024
textdata bss dec hex filename
137 1704032 0 1704169 1a00e9 arch/powerpc/kernel/paca.o :Before
121 1179744 524288 1704153 1a00d9 arch/powerpc/kernel/paca.o :After
Now that we're not statically allocating the paca, we don't need the
NR_STATIC_PACAS #defin
Currently all iSeries secondary CPU's spin directly on the cpu_start in thier
paca. Make them spin on the global __secondary_hold_spinloop, until after the
pacas have been initialised.
As sfr points out this works because __secondary_hold_spinloop is being set
already, but iSeries isn't looking a
As the pacas are statically initialised increasing NR_CPUS beyond 128,
means that any additional pacas will be empty ... which is bad.
This patch adds the required functionality to fill in any excess pacas
at runtime.
Signed-off-by: Tony Breeds <[EMAIL PROTECTED]>
---
Changes since v1:
- Addres
On Wed, Apr 23, 2008 at 01:44:16PM +1000, Tony Breeds wrote:
> Signed-off-by: Tony Breeds <[EMAIL PROTECTED]>
> Acked-by: Stephen Rothwell <[EMAIL PROTECTED]>
> ---
> Changes since v1:
> - Updated commit message.
Oops some how I got git to merge patches 2 and 3. Please ignore this
and I'll fix
As the pacas are statically initialised increasing NR_CPUS beyond 128,
means that any additional pacas will be empty ... which is bad.
This patch adds the required functionality to fill in any excess pacas
at runtime.
Signed-off-by: Tony Breeds <[EMAIL PROTECTED]>
---
Changes since v1:
- Addres
Currently all iSeries secondary CPU's spin directly on the cpu_start in thier
paca. Make them spin on the global __secondary_hold_spinloop, until after the
pacas have been initialised.
As sfr points out this works because __secondary_hold_spinloop is being set
already, but iSeries isn't looking a
On Tue, Apr 22, 2008 at 6:37 PM, Anton Vorontsov <[EMAIL PROTECTED]> wrote:
> On Tue, Apr 22, 2008 at 02:08:45PM -0600, Grant Likely wrote:
>
> > On Tue, Apr 22, 2008 at 1:41 PM, Anton Vorontsov
> > <[EMAIL PROTECTED]> wrote:
> > > Hi all,
> > >
> > > Here is purposed bindings draft for the new
On Tue, Apr 22, 2008 at 03:50:22PM -0500, Josh Boyer wrote:
> On Tue, 2008-04-22 at 14:08 -0600, Grant Likely wrote:
> > On Tue, Apr 22, 2008 at 1:41 PM, Anton Vorontsov
> > <[EMAIL PROTECTED]> wrote:
> > > Hi all,
> > > +w) NAND on UPM-driven Freescale Localbus
> > > +
> > > + Required pr
On Tue, Apr 22, 2008 at 02:08:45PM -0600, Grant Likely wrote:
> On Tue, Apr 22, 2008 at 1:41 PM, Anton Vorontsov
> <[EMAIL PROTECTED]> wrote:
> > Hi all,
> >
> > Here is purposed bindings draft for the new drivers that I would like to
> > send for this or next merge window, depending on results of
On Tue, 2008-04-22 at 12:23 -0500, Scott Wood wrote:
> On Tue, Apr 22, 2008 at 06:58:33PM +0200, Andre Schwarz wrote:
> > I wonder if the IRQ number should match the vector of the datasheet ...
> > giving :
>
> No. The numbers in /proc/interrupts are virtual IRQ numbers, which are a
> purely Lin
On Tue, 2008-04-22 at 17:55 +0200, Christian Ehrhardt wrote:
> I wanted to ask if there are any known workarounds atm that would
> allow me to use my X11 for now?
X is doing a mmap of /dev/mem instead of /dev/fb ?
You can normally map the fb mapping /dev/fb and then map the registers
using /dev/
On Tue, 2008-04-22 at 19:43 +0400, Sergei Shtylyov wrote:
> Not sure what that change gives us -- this function mostly treats 'addr'
> as unsigned long (casting it to char/void *), ot compares it to 'unsigned
> long' 'base' variable -- which should be made 'resource_size_t' in its turn
> be
> >> radeonfb: EDID probed
> >> Parsing EDID data for panel info
> >> Setting up default mode based on panel info
> >> radeonfb (:00:0a.0): ATI Radeon Y`
> >
> >Hm, what's that Y`?
>
> Thats the final message in the radeonfb driver ater initializing everything.
>printk ("radeonfb (%s
thanks, applied all 5.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
On Tue, 2008-04-22 at 14:08 -0600, Grant Likely wrote:
> On Tue, Apr 22, 2008 at 1:41 PM, Anton Vorontsov
> <[EMAIL PROTECTED]> wrote:
> > Hi all,
> > +w) NAND on UPM-driven Freescale Localbus
> > +
> > + Required properties:
> > + - compatible : "fsl,upm-nand".
> > + - reg : sho
On Tue, Apr 22, 2008 at 2:20 PM, Scott Wood <[EMAIL PROTECTED]> wrote:
> On Tue, Apr 22, 2008 at 02:08:45PM -0600, Grant Likely wrote:
> > > +Example:
> > > +
> > > + [EMAIL PROTECTED] {
> > > + compatible = "fsl,mpc8360-qe-muram-usb-pram",
> > > +
On Tue, Apr 22, 2008 at 02:08:45PM -0600, Grant Likely wrote:
> > +Example:
> > +
> > + [EMAIL PROTECTED] {
> > + compatible = "fsl,mpc8360-qe-muram-usb-pram",
> > +"fsl,qe-muram-usb-pram",
> > +"fsl,cpm-muram-usb-pram"
On Wed, 2008-04-23 at 00:16 +0400, Sergei Shtylyov wrote:
> David Woodhouse wrote:
>
> >>Ok. I'll submit a new patch as soon as we agree on a compatible name.
>
> > Did we?
>
> IIRC, The latest agreement was that we don't need the "compatible" and
> will match on node name.
Ok. Is there a
David Woodhouse wrote:
Ok. I'll submit a new patch as soon as we agree on a compatible name.
Did we?
IIRC, The latest agreement was that we don't need the "compatible" and
will match on node name.
WBR, Sergei
___
Linuxppc-dev mailing list
Li
On Thu, 2008-03-27 at 10:26 +0100, Laurent Pinchart wrote:
> Ok. I'll submit a new patch as soon as we agree on a compatible name.
Did we?
--
dwmw2
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
On Tue, Apr 22, 2008 at 1:41 PM, Anton Vorontsov
<[EMAIL PROTECTED]> wrote:
> Hi all,
>
> Here is purposed bindings draft for the new drivers that I would like to
> send for this or next merge window, depending on results of this RFC. ;-)
> (The new bindings needs to be in-tree or at least Acked be
Hi all,
Here is purposed bindings draft for the new drivers that I would like to
send for this or next merge window, depending on results of this RFC. ;-)
(The new bindings needs to be in-tree or at least Acked before I could
send the drivers.)
Comments and suggestions are highly appreciated.
Th
On Tue, Apr 22, 2008 at 08:51:23PM +0200, Andre Schwarz wrote:
> Scott Wood schrieb:
> >On Tue, Apr 22, 2008 at 07:36:48PM +0200, Andre Schwarz wrote:
> >
> >>thanks - any Idea how to figure out where the BAD comes from ?
> >>Is it simply an unhandled/unacked one ?
> >>
> >
> >It generally ha
Scott Wood schrieb:
On Tue, Apr 22, 2008 at 07:36:48PM +0200, Andre Schwarz wrote:
thanks - any Idea how to figure out where the BAD comes from ?
Is it simply an unhandled/unacked one ?
It generally happens when an interrupt is requested, and the core takes
the exception, but then the
On Thu, 2008-02-28 at 20:17 +0800, Li Yang wrote:
> The generic rule for partition scan is to try all supported
> partition types before an usable partition table is found.
> However the original code returns unsuccessful when there is
> an error in any of the partition types.
>
> Signed-off-by: L
Subject: [RFC patch 6/9] Re: [PATCH] Stringify support commas
> This is a no-no for those archs that still use -traditional.
> > I dunno if this is a problem for you at the moment and the
> > right fix is anyway to nuke -traditional.
> >
> > Sam
Signed-off-by: Mathieu Desnoyers <[EMAIL P
On Tue, Apr 22, 2008 at 07:36:48PM +0200, Andre Schwarz wrote:
> thanks - any Idea how to figure out where the BAD comes from ?
> Is it simply an unhandled/unacked one ?
It generally happens when an interrupt is requested, and the core takes
the exception, but then the interrupt source deasserts i
Scott Wood schrieb:
On Tue, Apr 22, 2008 at 06:58:33PM +0200, Andre Schwarz wrote:
I wonder if the IRQ number should match the vector of the datasheet ...
giving :
No. The numbers in /proc/interrupts are virtual IRQ numbers, which are a
purely Linux-internal construct.
-Scott
___
On Tue, Apr 22, 2008 at 06:58:33PM +0200, Andre Schwarz wrote:
> I wonder if the IRQ number should match the vector of the datasheet ...
> giving :
No. The numbers in /proc/interrupts are virtual IRQ numbers, which are a
purely Linux-internal construct.
-Scott
__
All,
I'm currently running a MPC8343 based board.
Looks like I'm having problems with IRQs of a PCI device.
/proc/interrupts give :
CPU0
16:554 IPIC Level i2c-mpc
17: 11 IPIC Level i2c-mpc
18:134 IPIC Level ath
19: 1557 IPIC L
On Tue, 2008-04-22 at 17:55 +0200, Christian Ehrhardt wrote:
>
> You see it e.g. when you try to initialize X11, the x11 radeon driver
> issues a FBIOGET_FSCREENINFO ioctl [...]
FWIW, current versions of the xf86-video-ati radeon driver no longer use
radeonfb for anything.
--
Earthling Michel
On Tue, Apr 22, 2008 at 05:55:13PM +0200, Laurent Pinchart wrote:
> On Tuesday 22 April 2008 17:36, Scott Wood wrote:
> > The only reason I can see for that would be if the gpiolib version
> > doesn't work on arch/ppc -- but that's not going to be a problem for very
> > much longer.
>
> Didn't you
On Tuesday 22 April 2008 17:36, Scott Wood wrote:
> On Tue, Apr 22, 2008 at 05:21:49PM +0200, Laurent Pinchart wrote:
> > As the openfirmware + gpio + mdio driver might benefit non-powerpc
> > platforms, I plan to create a new driver (probably
> > drivers/net/phy/mdio-ofgpio.c) that mostly ports
>
Benjamin Herrenschmidt wrote:
This fixes radeonfb to not truncate 64 bits resources on 32 bits
platforms. Unfortunately, there are still issues with addresses
returned to userspace via struct fb_fix_screeninfo. This will
have to be dealt with separately.
Thanks for this patch Benjamin, I use it
Benjamin Herrenschmidt wrote:
This fixes atyfb to not truncate 64 bits resources on 32 bits
platforms. Unfortunately, there are still issues with addresses
returned to userspace via struct fb_fix_screeninfo. This will
have to be dealt with separately.
Signed-off-by: Benjamin Herrenschmidt <[E
On Tue, Apr 22, 2008 at 05:21:49PM +0200, Laurent Pinchart wrote:
> As the openfirmware + gpio + mdio driver might benefit non-powerpc platforms,
> I plan to create a new driver (probably drivers/net/phy/mdio-ofgpio.c) that
> mostly ports drivers/net/fs_enet/mii-bitbang.c to the gpiolib (this rep
On Tue, Apr 22, 2008 at 05:21:49PM +0200, Laurent Pinchart wrote:
> On Tuesday 22 April 2008 17:08, Scott Wood wrote:
> > On Tue, Apr 22, 2008 at 10:55:06AM +0200, Laurent Pinchart wrote:
> > > On Monday 21 April 2008 19:56, Scott Wood wrote:
> > > > The memory-constrained platform I had in mind wa
On Tuesday 22 April 2008 17:08, Scott Wood wrote:
> On Tue, Apr 22, 2008 at 10:55:06AM +0200, Laurent Pinchart wrote:
> > On Monday 21 April 2008 19:56, Scott Wood wrote:
> > > The memory-constrained platform I had in mind was 8xx, which doesn't use
> > > bitbanged MDIO. It might nice to keep the
On Tue, Apr 22, 2008 at 10:55:06AM +0200, Laurent Pinchart wrote:
> On Monday 21 April 2008 19:56, Scott Wood wrote:
> > The memory-constrained platform I had in mind was 8xx, which doesn't use
> > bitbanged MDIO. It might nice to keep the gpiolib bit separate to avoid
> > situations such as ep824
On Tue, 2008-04-22 at 16:21 +0200, Christian Ehrhardt wrote:
>
> >> radeonfb: EDID probed
> >> Parsing EDID data for panel info
> >> Setting up default mode based on panel info
> >> radeonfb (:00:0a.0): ATI Radeon Y`
> >
> >Hm, what's that Y`?
>
> Thats the final message in the radeonfb
Sergei Shtylyov wrote:
Hello.
Christian Ehrhardt wrote:
[...]
The Documentation of the 440EPx core lists these spaces:
PCI 1 Memory 1 8000 1 BFFF 1GB
I/O 1 E800 1 E800 64KB
I/O 1 E880 1 EBFF 56MB
Having 2
On Thu, Apr 17, Juergen Beisert wrote:
> if someone is interested: Here the full patch to get sound support for
> MPC5200b and a current 2.6.25 kernel.
It misses a 'MODULE_DEVICE_TABLE(of, mpc52xx_ac97_of_match);' and a nul
termination of struct mpc52xx_ac97_of_match.
This will allow autoload of
Hi Jean,
On Saturday 19 April 2008 18:43, Jochen Friedrich wrote:
> Jean Delvare wrote:
> > On Sat, 19 Apr 2008 15:09:55 +0200, Jochen Friedrich wrote:
> >> Hi Jean,
> >>
> > Is the new-style driver conversion patch in 2.6.25-rc8-mm2 scheduled
> > for 2.6.26 ?
> hope so! :)
> >>> Not
diff --git a/arch/powerpc/sysdev/Makefile b/arch/powerpc/sysdev/
Makefile
index 6d386d0..e60a238 100644
--- a/arch/powerpc/sysdev/Makefile
+++ b/arch/powerpc/sysdev/Makefile
@@ -4,6 +4,7 @@ endif
mpic-msi-obj-$(CONFIG_PCI_MSI) += mpic_msi.o mpic_u3msi.o
mpic_pasemi_msi.o
obj-$(CONFIG_MPIC)
Hello.
Christian Ehrhardt wrote:
Ah, that's what happens -- BAR0 in functions 0/1 takes up the
whole 265 MiB of the PCI memory space (128+128), so no place is left
for other memory BARs.
What's interesting, the Sequoia/Rainier board user manual says that
PCI memory is 0x8000 thru
+ unsigned long kernel_toc = (unsigned long)(&__toc_start) +
0x8000UL;
This line could do with a comment saying what it is doing ...
It does need a comment I agree, but I don't think I can do it justice
:)
... I just used what was already there.
Here, have one:
"The TOC register (GPR2) po
+static void fsl_compose_msi_msg(struct pci_dev *pdev, int hwirq,
+ struct msi_msg *msg)
No I mean I'm confused about the maths here. If we pull out the
variables it boils down to:
data = ((hwirq / 32) << 5) | ((hwirq % 32) & 0x1F)
Which doesn't seem to actuall
On Fri, Apr 18, 2008 at 05:54:36PM +1000, Michael Ellerman wrote:
> Signed-off-by: Michael Ellerman <[EMAIL PROTECTED]>
I know it's fun to see yourself in the changeset statistics, but this is
silly. Please bake together all the simple changes to one patch instead
of one per file. They are all tri
Sergei Shtylyov wrote:
Hello, I wrote:
Ah, that's what happens -- BAR0 in functions 0/1 takes up the whole
265 MiB of the PCI memory space (128+128), so no place is left for
other memory BARs.
What's interesting, the Sequoia/Rainier board user manual says that
PCI memory is 0x8000
This MSI driver can be used on 83xx/85xx/86xx board.
In this driver, virtual interrupt host and chip were
setup. There are 256 MSI interrupts in this host, Every 32
MSI interrupts cascaded to one IPIC/MPIC interrupt.
The chip was treated as edge sensitive and some necessary
functions were setup for
On Monday 21 April 2008 19:56, Scott Wood wrote:
> On Fri, Apr 18, 2008 at 01:34:29PM +0200, Laurent Pinchart wrote:
> > Scott Wood was concerned in
> > http://patchwork.ozlabs.org/linuxppc/patch?id=17490 that the gpio lib
> > might be an unnecessary burden for memory-constraint platforms. Should
On Mon, 2008-04-21 at 12:51 -0500, Kumar Gala wrote:
> I'm not clear on why this is needed. I can see value in having the
> PGD entry in place but the pte PAs would be changing all the time so
> I
> don't see what benefit there is in keeping them in one page.
Because they are accessed as an
64 matches
Mail list logo
