Make it so that SPE support can be determined at runtime. This is similiar
to how we handle AltiVec. This allows us to have SPE support built in and
work on processors with and without SPE.
Signed-off-by: Kumar Gala <[EMAIL PROTECTED]>
---
arch/powerpc/kernel/cputable.c | 23 +++--
Now that the generic code doesn't assign resources for Freescale
PHBs we dont have to explicitly exclude it.
Signed-off-by: Kumar Gala <[EMAIL PROTECTED]>
---
arch/powerpc/platforms/83xx/mpc8313_rdb.c |2 --
arch/powerpc/platforms/83xx/mpc832x_mds.c |1 -
arch/powerpc/platforms/83xx/mpc83
Removed the following cruft from .dts files:
* 32-bit in cpu node -- doesn't exist in any spec and not used by kernel
* removed built-in (chrp legacy)
* Removed #interrupt-cells in places they don't need to be set
* Fixed ranges on lite5200*
* Removed clock-frequency from i8259 pic node, not sure w
Added basic board port for MPC8572 DS reference platform that is
similiar to the MPC8544/33 DS reference platform in uniprocessor mode.
Signed-off-by: Kumar Gala <[EMAIL PROTECTED]>
---
arch/powerpc/boot/dts/mpc8572ds.dts | 404
arch/powerpc/configs/mpc8572_ds_defconfig | 1496 +++
These patches are my latest round of patches for 2.6.24. Posted here for
review/comment.
All these patches exist in:
master.kernel.org:/pub/scm/linux/kernel/git/galak/powerpc.git for-2.6.24
- k
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs
Hi, Sivaji,
I've tested the newest git tree of Paul's, which is aleady updated to
2.6.23-rc4. The kernel is no problem with the u-boot of our released BSP
(Jun, 2007) on MPC8641HPCN board.
Maybe you could update to the newest kernel git tree and try again.
Cheers!
-zw
> -Original Message---
On Sep 13, 2007, at 1:22 AM, David Gibson wrote:
> The only difference between m82xx_calibrate_decr() and
> generic_calibrate_decr() is that the former computes the timebase
> frequency from the cpu node's bus-frequency property, instead of
> directly from the timebase-frequency property.
>
> But
> diff --git a/arch/powerpc/boot/dts/pq2fads.dts b/arch/powerpc/boot/
> dts/pq2fads.dts
> new file mode 100644
> index 000..ad736f8
> --- /dev/null
> +++ b/arch/powerpc/boot/dts/pq2fads.dts
> @@ -0,0 +1,236 @@
> +/*
> + * Device Tree for the PQ2FADS-ZU board with an MPC8280 chip.
> + *
> + * C
The only difference between m82xx_calibrate_decr() and
generic_calibrate_decr() is that the former computes the timebase
frequency from the cpu node's bus-frequency property, instead of
directly from the timebase-frequency property.
But there's no reason the timebase-frequency shouldn't be correct
On Thu, 2007-09-13 at 00:13 -0500, Kumar Gala wrote:
> On Sep 12, 2007, at 11:47 PM, sivaji wrote:
>
> >
> >
> > Hi,
> > I have JTAG Debugger connected to the board. I was given the
> > following commands in the root path of the kernel source
>
> If you can dump memory w/o connecting GD
On Sep 13, 2007, at 12:23 AM, lakshminarayana babu wrote:
> sir,
>can you plese suggest any book for pci driver writing...At
> present i am studying linux device drivers by alexandrorubini
That's about as good as it gets. It covers writing a pci driver in
there.
- k
___
Hi,
Sorry i specify the wrong version, we r using 1.2.0. This uboot
was taken from the BSP which was released by Freescale. Previously we tested
linux 2.6.21 kernel, we got linux prompt. For this we are using the same
uboot(1.2.0).
In that version we face some issues in the pci express,
On Wed, Sep 12, 2007 at 10:24:22PM -0700, sivaji wrote:
>
>
> Hi,
> I am not willing to upgrade the uboot. Becuase it takes some time to
> port the new uboot for my custom boad.
> whether the current problem is related to uboot ? One more point, previously
> i tried 2.6.21 with the same u
Hi,
I am not willing to upgrade the uboot. Becuase it takes some time to
port the new uboot for my custom boad.
whether the current problem is related to uboot ? One more point, previously
i tried 2.6.21 with the same uboot(1.1.6) we got linux prompt but we face
some issue in the pci expr
sir,
can you plese suggest any book for pci driver writing...At present i am
studying linux device drivers by alexandrorubini
On 9/13/07, Olof Johansson <[EMAIL PROTECTED]> wrote:
>
> On Thu, Sep 13, 2007 at 10:01:36AM +0530, lakshminarayana babu wrote:
> > i am new to the linux.can you tel
Yes, It's too old. Maybe not fully supports FDT. You can try the version
of Kumar said or in the BSP of Freescale released.
- zw
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]
> g] On Behalf Of Kumar Gala
> Sent: Thursday, September 13, 2007 1:11 PM
> To: siva
On Wed, Sep 12, 2007 at 08:07:06PM +0400, Vitaly Bordug wrote:
> 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.
> >
> >
On Sep 12, 2007, at 11:47 PM, sivaji wrote:
>
>
> Hi,
> I have JTAG Debugger connected to the board. I was given the
> following commands in the root path of the kernel source
If you can dump memory w/o connecting GDB, I suggest the following.
Look in your kernel build for System.map
On Sep 12, 2007, at 11:52 PM, sivaji wrote:
>
>
> Hi,
> I tired to move the dtb to 0x200, but the result was
> same.
> uboot version is 1.1.6
seems like a pretty old u-boot. Willing to try a 1.3.0-rc1?
- k
___
Linuxppc-dev mailing lis
Hi,
I tired to move the dtb to 0x200, but the result was same.
uboot version is 1.1.6
by
Sivaji
Zhang Wei-r63237 wrote:
>
> Hi,
>
> Your flat device tree address seems too low. Try to move the dtb to
> higher address such as 0x200.
>
> And which version of your u-boot?
>
Hi,
I have JTAG Debugger connected to the board. I was given the
following commands in the root path of the kernel source
1. ${CROSS_COMPILE}gdb vmlinux
2. I got th GDB prompt after that i give
target remote 172.29.38.213:2001 i got following results
(gdb) target re
On Thu, Sep 13, 2007 at 10:01:36AM +0530, lakshminarayana babu wrote:
> i am new to the linux.can you tell me how to access the pci
> configuration space using ioremap function...but it is implicit function
> declaration...
That is architecture and platform dependent. Some platforms don't eve
Hi,
Your flat device tree address seems too low. Try to move the dtb to
higher address such as 0x200.
And which version of your u-boot?
Cheers!
- zw
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]
> g] On Behalf Of sivaji
> Sent: Thursday, September 13,
> -#define HCA_CAP_MR_PGSIZE_4K 1
> -#define HCA_CAP_MR_PGSIZE_64K 2
> -#define HCA_CAP_MR_PGSIZE_1M 4
> -#define HCA_CAP_MR_PGSIZE_16M 8
> +#define HCA_CAP_MR_PGSIZE_4K 0x8000
> +#define HCA_CAP_MR_PGSIZE_64K 0x4000
> +#define HCA_CAP_MR_PGSIZE_1M 0x2000
> +#define HCA_CAP_
i am new to the linux.can you tell me how to access the pci
configuration space using ioremap function...but it is implicit function
declaration...
On 9/13/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]>
wrote:
>
> Send Linuxppc-dev mailing list submissions to
> linuxppc-dev@ozlabs.org
>
>
On Wed, Sep 12, 2007 at 10:28:24PM -0500, Kumar Gala wrote:
[snip]
> >> + [EMAIL PROTECTED] {
> >
> > You should put an interrupt-parent in here, so you can get rid of
> > it in all the children.
>
> Are interrupt-parent's inherited by child nodes?
Strictly speaking, a node's default interrupt-p
It would be nice to be able to do:
for_each_thing(thing) {
error = sysfs_create_group(&thing->kobj, attrs);
if (error) {
for_each_thing(thing)
sysfs_remove_group(&thing->kobj, attrs);
return error;
}
}
But there's a B
On Sep 12, 2007, at 11:18 PM, sivaji wrote:
>
> Hi,
> I am try to boot the 2.6.23-rc3 kernel to my custom board
> based on
> 8641D Processor. After uncompressing the kernel it was hang. I got the
> following messages.
>
>Uncompressing Kernel Image ... OK
>Booting using flat devi
Hi,
I am try to boot the 2.6.23-rc3 kernel to my custom board based on
8641D Processor. After uncompressing the kernel it was hang. I got the
following messages.
Uncompressing Kernel Image ... OK
Booting using flat device tree at 0x60.
Then i tried to debug with GDB. In
Jan-Bernd Themann wrote:
> Introduces a module parameter to decide whether the physical
> port link state is propagated to the network stack or not.
> It makes sense not to take the physical port state into account
> on machines with more logical partitions that communicate
> with each other. This
On Sep 12, 2007, at 8:36 AM, Segher Boessenkool wrote:
> Looks a lot better, thanks!
>
> Some minor nits and suggestions...
>
>> +/ {
>> +model = "fsl,MPC8572DS";
>> +compatible = "fsl,MPC8572DS", "fsl,MPC85xxDS";
>
> We don't want "xx" compatible entries; especially here it makes
> no se
On Sep 12, 2007, at 9:10 AM, Segher Boessenkool wrote:
+ i8259: [EMAIL PROTECTED] {
+ reg = <1 20 2
+ 1 a0 2
+
On Sep 12, 2007, at 8:20 AM, Segher Boessenkool wrote:
+ [EMAIL PROTECTED] {
+ compatible = "fsl,8572-l2-cache-controller";
+ reg = <2 1000>;
+ cache-line-size = <20>; // 32 bytes
+ cache-siz
On Sep 12, 2007, at 5:10 PM, Segher Boessenkool wrote:
>> * 32-bit in cpu node -- doesn't exist in any spec and not used by
>> kernel
>
> Yeah.
>
>> * built-in for non-standard buses (ISA, PCI)
>
> "built-in" is some weird CHRP property, so yes we don't need it
> or want it.
Do you suggest we
>>> + [EMAIL PROTECTED] {
>>> + compatible = "fsl,8572-l2-cache-controller";
>>> + reg = <2 1000>;
>>> + cache-line-size = <20>; // 32 bytes
>>> + cache-size = <8>; // L2, 512K
>>> + interr
+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?
>>> well the ifdefs are orthogonal. We don't have a way of knowing
>>> primary from the device tree today.
>>
>> How about something like "fsl,primary-phb" in the bus device node? I
>> don't
>> know, maybe it's already been discussed and turned down for some
>> reason.
>
> It's more of a Linux i
> * 32-bit in cpu node -- doesn't exist in any spec and not used by
> kernel
Yeah.
> * built-in for non-standard buses (ISA, PCI)
"built-in" is some weird CHRP property, so yes we don't need it
or want it.
> * Removed #interrupt-cells in places they don't need to be set
Great :-)
> * Fixed r
> + [EMAIL PROTECTED] {
> + #address-cells = <1>;
> + #size-cells = <1>;
> + device_type = "soc";
> + ranges = < ffe0 0010>;
> + reg = ; // CCSRBAR & soc regs, remove
> once parse
> code for immrbase fixed
Hrm,
>>> + i8259: [EMAIL PROTECTED] {
>>> + reg = <1 20 2
>>> + 1 a0 2
>>> + 1 4d0 2>;
>>> +
>> 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.
Str
+ [EMAIL PROTECTED] {
+ 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" f
Looks a lot better, thanks!
Some minor nits and suggestions...
> +/ {
> + model = "fsl,MPC8572DS";
> + compatible = "fsl,MPC8572DS", "fsl,MPC85xxDS";
We don't want "xx" compatible entries; especially here it makes
no sense at all. If the board is compatible to some other (older)
board,
On Wed, 2007-09-12 at 10:47 +0200, Arnd Bergmann wrote:
> On Wednesday 12 September 2007, Michael Ellerman wrote:
> > On Wed, 2007-09-12 at 17:43 +1000, Michael Ellerman wrote:
> > > This patch adds DEFINE_SPUFS_ATTRIBUTE(), a wraper around
> > > DEFINE_SIMPLE_ATTRIBUTE which does the specified loc
Esben Haabendal wrote:
> Also, fs_enet_mdio_bb_exit does not work, as shown in the log below.
> Not that I need it, but I guess it should be working when it is there.
I think this is a generic PHY issue, addressed by this patch:
http://ozlabs.org/pipermail/linuxppc-dev/2007-September/042342.html
What happens if someone runs the new driver with older firmware? Or
what if someone upgrades the firmware without updating the driver?
- R.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Anton Vorontsov wrote:
> This patch is against paulus/powerpc.git or galak/powerpc.git tree.
> Both affected.
Acked-by: Timur Tabi <[EMAIL PROTECTED]>
This is an important fix. Without it, 836x and 832x won't build.
--
Timur Tabi
Linux Kernel Developer @ Freescale
_
On 9/12/07, S. Fricke <[EMAIL PROTECTED]> wrote:
> Hello,
>
> > > I have looked up "kernel/irq/manage.c". "-ENOSYS" is returned on function
> > > "setup_irq" because the used irq(MPC52xx_IRQ2) is the same as no_irq_chip.
> > >
> > > THE MPC52xx_IRQ2 is a excerpt from "include/ppc/mpc52xx.h" (per co
Hello,
> > I have looked up "kernel/irq/manage.c". "-ENOSYS" is returned on function
> > "setup_irq" because the used irq(MPC52xx_IRQ2) is the same as no_irq_chip.
> >
> > THE MPC52xx_IRQ2 is a excerpt from "include/ppc/mpc52xx.h" (per copy
> > paste), but mpc52xx is (now) a powerpc-arch. What is
Linus,
Please do
git pull \
git://git.kernel.org/pub/scm/linux/kernel/git/paulus/powerpc.git merge
to get four small bug-fixes for embedded powerpc from Kumar, plus a
one-liner from Olof that I missed putting in the previous batch.
Thanks,
Paul.
arch/powerpc/kernel/legacy_serial.c|
On Sep 12, 2007, at 06:26, Anton Vorontsov wrote:
> Lately I've got this nice badness on mdio bus removal:
>
> Device 'e0103120:06' does not have a release() function, it is
> broken and must be fixed.
> [ cut here ]
> Badness at drivers/base/core.c:107
> NIP: c015c1a8 L
On Wednesday September 12, [EMAIL PROTECTED] wrote:
> On Wednesday 12 September 2007 20:01, Greg KH wrote:
> > On Wed, Sep 12, 2007 at 07:32:07AM +0200, Robert Schwebel wrote:
> > > On Tue, Sep 11, 2007 at 11:43:17AM +0200, Heiko Schocher wrote:
> > > > I have developed a device driver and use the
On Wednesday 12 September 2007 20:01, Greg KH wrote:
> On Wed, Sep 12, 2007 at 07:32:07AM +0200, Robert Schwebel wrote:
> > On Tue, Sep 11, 2007 at 11:43:17AM +0200, Heiko Schocher wrote:
> > > I have developed a device driver and use the sysFS to export some
> > > registers to userspace.
> >
> > U
On Wed, Sep 12, 2007 at 12:04:20PM -0500, Kumar Gala wrote:
> I'm leaving them for now to match the others, we can clean them all
> up at the same time.
OK.
> Technically built-in is spec'd by the CHRP spec for ISA/PCI.
I looked in the CHRP I/O Device Reference and didn't see it, though I may
On Sep 12, 2007, at 11:36 AM, Scott Wood wrote:
> On Wed, Sep 12, 2007 at 11:20:06AM -0500, Kumar Gala wrote:
>> +[EMAIL PROTECTED] {
>> +reg = <0 0 0 0 0>;
>> +#size-cells = <2>;
>> +#address-cells = <3>;
>> +
Removed the following cruft from .dts files:
* 32-bit in cpu node -- doesn't exist in any spec and not used by kernel
* built-in for non-standard buses (ISA, PCI)
* Removed #interrupt-cells in places they don't need to be set
* Fixed ranges on lite5200*
---
Exists in my for-2.6.24 branch
arch/p
On Wed, Sep 12, 2007 at 11:20:06AM -0500, Kumar Gala wrote:
> + [EMAIL PROTECTED] {
> + reg = <0 0 0 0 0>;
> + #size-cells = <2>;
> + #address-cells = <3>;
> + device_type = "pci";
> + [E
Added basic board port for MPC8572 DS reference platform that is
similiar to the MPC8544/33 DS reference platform in uniprocessor mode.
Signed-off-by: Kumar Gala <[EMAIL PROTECTED]>
---
Updated device tree based on comments.
arch/powerpc/boot/dts/mpc8572ds.dts | 385
arch/powerp
On Thu, 13 Sep 2007, Paul Mackerras wrote:
>
> 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.
Yeah, I'll take this one. I just wanted to understand why it triggered
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 mak
On 9/12/07, Kumar Gala <[EMAIL PROTECTED]> 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://pa
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 dwa
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.ozla
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
On Wednesday 12 September 2007, Christoph Raisch wrote:
> David Miller <[EMAIL PROTECTED]> 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 d
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 804ace8881d211ac448082e871dd312132393
On Sep 12, 2007, at 9:45 AM, Josh Boyer wrote:
> On Thu, 30 Aug 2007 10:33:28 +0200
> Stefan Roese <[EMAIL PROTECTED]> 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 suppor
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
Hi David and Grant
>> > For example emaclite driver needs information about turning on/off ping
>> > pong
buffer...
>> >
>> > I would like to make this properly.
>>
>> FDT design is just as much art as it is science. It takes taste and
>> judgement to desgin a nice set of bindings. Your best op
+ reg = ;
+ fsl,has-rstcr;
+ };
+
+ mpic: [EMAIL PROTECTED] {
+ clock-frequency = <0>;
+ interrupt-controller;
+ #address-cells = <0>;
+
David,
I'm splitting this up since the mdio & phy comments are more general
that the 8572.dts
>>> [snip]
+ [EMAIL PROTECTED] {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ device_type = "mdio";
>>>
>>> I don't thi
On Thu, 30 Aug 2007 10:33:28 +0200
Stefan Roese <[EMAIL PROTECTED]> 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
> val
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 <[EMAIL PROTECTED]>
---
This is the same patch, but with smp_processor_id() replaced by
raw_smp_processor_id(), as kindly pointed out
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_processo
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?
>
From: Christoph Raisch <[EMAIL PROTECTED]>
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.
>
David Miller <[EMAIL PROTECTED]> wrote on 12.09.2007 14:50:04:
> From: Jan-Bernd Themann <[EMAIL PROTECTED]>
> 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
> >
From: Hoang-Nam Nguyen <[EMAIL PROTECTED]>
...because, on virtualized hardware like System p, we can't be sure that the
physical pages behind them are contiguous.
Signed-off-by: Joachim Fenkes <[EMAIL PROTECTED]>
---
Another patch for 2.6.24 that will apply cleanly on top of my previous
patchset
Hello Greg,
Am Mittwoch, den 12.09.2007, 04:39 -0700 schrieb Greg KH:
> > > Do an lseek back to 0 and then re-read, you will get called in your
> > > driver again.
> >
> > No thats not true. I thought this too, but if I make a:
> >
> > seek (fd, 0L, SEEK_SET);
> >
> > in Userspace, there is no
On Wed, Sep 12, 2007 at 12:34:09PM +0100, Christoph Hellwig wrote:
> On Wed, Sep 12, 2007 at 04:01:09AM -0700, Andrew Morton wrote:
> > On Wed, 12 Sep 2007 12:20:32 +0200 Heiko Carstens <[EMAIL PROTECTED]> wrote:
> >
> > > On Wed, Sep 12, 2007 at 12:04:39PM +1000, Michael Neuling wrote:
> > > > Th
2.6.22.5 crashes on resume on an iBook G3 600MHz. when cpufreq_userspace is
active. System is PowerBook4,3, 750FX revision 2.3
2.6.18 crashed also on resume, but I dont know if this was the same bug.
The oopes differ. Once I get an 'Unrecoverable FP Unavailable
Exception 801' in audit_log_vformat
On Wed, Sep 12, 2007 at 01:13:32PM +0200, Heiko Schocher wrote:
> Hello Greg
>
> Am Mittwoch, den 12.09.2007, 03:01 -0700 schrieb Greg KH:
> > On Wed, Sep 12, 2007 at 07:32:07AM +0200, Robert Schwebel wrote:
> > > On Tue, Sep 11, 2007 at 11:43:17AM +0200, Heiko Schocher wrote:
> > > > I have devel
On Wednesday 12 September 2007, Michael Ellerman wrote:
> The routine to dump the local store, __spufs_mem_read(), does not take the
> spu_lslr_RW value into account - so we shouldn't check it when we're
> calculating the size either.
>
> Signed-off-by: Michael Ellerman <[EMAIL PROTECTED]>
Acked-
On Wed, Sep 12, 2007 at 04:01:09AM -0700, Andrew Morton wrote:
> On Wed, 12 Sep 2007 12:20:32 +0200 Heiko Carstens <[EMAIL PROTECTED]> wrote:
>
> > On Wed, Sep 12, 2007 at 12:04:39PM +1000, Michael Neuling wrote:
> > > The "tty: termios locking functions break with new termios type" patch
> > > (f
Lately I've got this nice badness on mdio bus removal:
Device 'e0103120:06' does not have a release() function, it is broken and must
be fixed.
[ cut here ]
Badness at drivers/base/core.c:107
NIP: c015c1a8 LR: c015c1a8 CTR: c0157488
REGS: c34bdcf0 TRAP: 0700 Not tainted
There was probably a typo in the documentation, or it's hw errata.
Recent u-boot also using 0x7.
Signed-off-by: Anton Vorontsov <[EMAIL PROTECTED]>
---
arch/powerpc/boot/dts/mpc8568mds.dts |8
1 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/powerpc/boot/dts/mpc856
Timur, want to take this along with your qe_lib cleanup queue?
- - - -
From: Anton Vorontsov <[EMAIL PROTECTED]>
Signed-off-by: Anton Vorontsov <[EMAIL PROTECTED]>
---
arch/powerpc/sysdev/qe_lib/ucc_fast.c | 40
1 files changed, 20 insertions(+), 20 deletions(-
- uccf should be set to NULL to not double-free memory on
subsequent calls;
- ind_hash_q and group_hash_q lists should be initialized in the
probe() function, instead of struct_init() (called by open()),
otherwise there will be an oops if ucc_geth_driver removed
prior 'ifconfig ethX up';
-
This patch is against paulus/powerpc.git or galak/powerpc.git tree.
Both affected.
- - - -
From: Anton Vorontsov <[EMAIL PROTECTED]>
There is no qe_bd_t typedef any longer, now it's struct qe_bd.
Signed-off-by: Anton Vorontsov <[EMAIL PROTECTED]>
---
drivers/net/ucc_geth.c |2 +-
1 files ch
In message <[EMAIL PROTECTED]> you wrote:
> On Wed, 12 Sep 2007 12:20:32 +0200 Heiko Carstens <[EMAIL PROTECTED]> wrote:
>
> > On Wed, Sep 12, 2007 at 12:04:39PM +1000, Michael Neuling wrote:
> > > The "tty: termios locking functions break with new termios type" patch
> > > (f629307c857c030d5a3dd7
Hello Greg
Am Mittwoch, den 12.09.2007, 03:01 -0700 schrieb Greg KH:
> On Wed, Sep 12, 2007 at 07:32:07AM +0200, Robert Schwebel wrote:
> > On Tue, Sep 11, 2007 at 11:43:17AM +0200, Heiko Schocher wrote:
> > > I have developed a device driver and use the sysFS to export some
> > > registers to use
On Wednesday 12 September 2007, Michael Ellerman wrote:
> Because the SPU coredump code might be built as part of a module (spufs),
> we have a stub which is called by the coredump code, this routine then calls
> into spufs if it's loaded.
>
> Unfortunately the stub returns -ENOSYS if spufs is not
On Wed, 12 Sep 2007 12:20:32 +0200 Heiko Carstens <[EMAIL PROTECTED]> wrote:
> On Wed, Sep 12, 2007 at 12:04:39PM +1000, Michael Neuling wrote:
> > The "tty: termios locking functions break with new termios type" patch
> > (f629307c857c030d5a3dd777fee37c8bb395e171) breaks the powerpc compile.
> >
On Wed, Sep 12, 2007 at 12:04:39PM +1000, Michael Neuling wrote:
> The "tty: termios locking functions break with new termios type" patch
> (f629307c857c030d5a3dd777fee37c8bb395e171) breaks the powerpc compile.
> [...]
> I'm guessing other architectures are broken too?
FWIW, the above quoted patch
> > >
> > > On Fri, Sep 07, 2007 at 04:43:35PM +0200, Segher
> Boessenkool wrote:
> > > > > + l) Freescale DMA
> > > >
> > > > > +- compatible : Should be "fsl,dma".
> > > >
> > > > Please choose some more specific name. "fsl,mpc8540-dma" would
> > > > be a reasonable choice perhaps.
> >
On Wed, Sep 12, 2007 at 07:32:07AM +0200, Robert Schwebel wrote:
> On Tue, Sep 11, 2007 at 11:43:17AM +0200, Heiko Schocher wrote:
> > I have developed a device driver and use the sysFS to export some
> > registers to userspace.
>
> Uuuh, uggly. Don't do that. Device drivers are there to abstract
Konstantin Boyanov wrote:
> Hello everybody,
>
> I have a simple question - where can I find an Adeos patch for a
> 2.6.15 kernel? I'm trying to integrate Xenomai in it, but as I read in
> the installation notes i first must patch a fresh kernel with a
> corresponding adeos patch. I googled ar
Hello everybody,
I have a simple question - where can I find an Adeos patch for a
2.6.15kernel? I'm trying to integrate Xenomai in it, but as I read in
the
installation notes i first must patch a fresh kernel with a corresponding
adeos patch. I googled around but found nothing of use, only the lat
On Wednesday 12 September 2007, Michael Ellerman wrote:
> The spufs_coredump_read array is NULL terminated, and we also store the size.
> We only need one or the other, and storing the size should save a teensy bit
> of memory vs NULL terminating, so do that.
Given that we have another array in th
On Wednesday 12 September 2007, Michael Ellerman wrote:
> The SPUFS attribute get routines take a void * because the generic attribute
> code doesn't know what sort of data it's passing around.
>
> However our internal __spufs_get_foo() routines can take a spu_context *
> directly, which saves plo
1 - 100 of 127 matches
Mail list logo
