On Mon, Jul 14, 2008 at 12:45:55PM +0100, Mark Brown wrote:
> On Sat, Jul 12, 2008 at 02:39:39AM -0600, Grant Likely wrote:
>
> > ASoC Codec driver for the TLV320AIC26 device. This driver uses the ASoC
> > v1 API, so I don't expect it to get merged as-is, but I want to get it
> > out there for re
Benjamin Herrenschmidt wrote:
On Fri, 2008-07-18 at 00:10 +0530, Mohan Kumar M wrote:
Extract list of relocation offsets
Extract list of offsets in the vmlinux file for which the relocation
delta has to be patched. Currently only following type of relocation
types are considered: R_PPC64_ADDR16
On Fri, Jul 18, 2008 at 03:42:01AM +0400, Anton Vorontsov wrote:
>
> So..
>
> Trent, I encourage you to collect your patch snippets into complete patch,
> and post it so it could slip into 2.6.27 (the bad thing is that your
> approach involves changes to the existing drivers, not just adding new
On Fri, Jul 18, 2008 at 01:35:12PM +1000, David Gibson wrote:
> This brings us back to the issue we also have with DCR controlled
> devices. Possibly we should have two ways of representing these
> connections: for "pure" GPIO-only or DCR-only devices, they appear
> under the relevant controller w
On Thu, Jul 17, 2008 at 11:14:11AM -0500, Milton Miller wrote:
> On Thu Jul 17 at 23:22:28 EST in 2008, Guillaume Dargaud wrote:
[snip]
>> Maybe the main() of the kernel can receive argv/argc the usual way,
>> and I
>> just need to call "0x40(argc, argv);" but I have no idea if that
>> work
On Thu, Jul 17, 2008 at 09:19:49PM +0300, Adrian Bunk wrote:
> gcc 4.3 correctly determines that input() is unused and gives the
> following warning:
>
> <-- snip -->
>
> ...
> HOSTCC arch/powerpc/boot/dtc-src/dtc-lexer.lex.o
> dtc-lexer.lex.c:1436: warning: ‘input’ defined but not used
> .
On Thu, Jul 17, 2008 at 09:07:15AM -0600, Grant Likely wrote:
> On Thu, Jul 17, 2008 at 03:07:30PM +0400, Anton Vorontsov wrote:
> > On Thu, Jul 17, 2008 at 07:59:03AM +0200, Segher Boessenkool wrote:
> > > What would be the parent node of this, btw?
> >
> > This is tricky question. Personally I p
On Thu, Jul 17, 2008 at 09:18:54PM +0300, Adrian Bunk wrote:
> For C code spaces versus tabs is just a religious issue,
> but for Makefiles it actually matters.
>
> This patch fixes he following errors:
> /home/bunk/linux/kernel-2.6/git/linux-2.6/arch/powerpc/boot/Makefile:166: ***
> missing sepa
Andrew Morton wrote:
> On Thu, 17 Jul 2008 17:19:32 -0500
> Nathan Lynch <[EMAIL PROTECTED]> wrote:
>
>
>> [snip]
>> A new aux vector entry, AT_BASE_PLATFORM, will denote the actual hardware.
[snip]
> OK.
>
> But it conflicts directly with the already-queued
> execve-filename-document-and-expor
On Thu, Jul 17, 2008 at 01:18:18PM -0700, Trent Piepho wrote:
> On Thu, 17 Jul 2008, Grant Likely wrote:
> > Alternately, I would also be okay with a scheme where all LED nodes
> > have a common parent and an of_platform driver would bind against the
> > parent node; not the individual children. T
On Sat, Jul 12, 2008 at 06:36:10PM +0100, Mark Brown wrote:
> On Sat, Jul 12, 2008 at 12:00:18AM -0600, Grant Likely wrote:
> It wouldn't be the only driver not to implement PLL configuration in
> this way so that's probably be OK for an initial merge. What's expected
> for PLL configuration is t
On Thu, 17 Jul 2008 17:19:32 -0500
Nathan Lynch <[EMAIL PROTECTED]> wrote:
> Some IBM POWER-based platforms have the ability to run in a
> mode which mostly appears to the OS as a different processor from the
> actual hardware. For example, a Power6 system may appear to be a
> Power5+, which make
David, are you going to pick up this and the other SPI of support
patches (linked below)? Or should I push them through my tree? (I'm
assuming that all the comments are addressed and they are ready to be
merged).
http://patchwork.ozlabs.org/linuxppc/patch?id=19597
http://patchwork.ozlabs.org/lin
Some IBM POWER-based platforms have the ability to run in a
mode which mostly appears to the OS as a different processor from the
actual hardware. For example, a Power6 system may appear to be a
Power5+, which makes the AT_PLATFORM value "power5+". This means that
programs are restricted to the I
On Thursday 17 July 2008, Rune Torgersen wrote:
> Arnd Bergmann wrote:
> > So again, nothing conclusive. I'm running out of ideas.
>
> Is the syscall path different or the same on ppc and powerpc?
> Any differences in the task switching, irq handling or page fault
> handling?
>
It's all differen
On Tue, 2008-07-15 at 19:19 +0400, Anton Vorontsov wrote:
> + led->cdev.name = of_get_property(np, "label", NULL);
> + if (!led->cdev.name)
> + led->cdev.name = dev_name(&ofdev->dev);
How about also supporting a "trigger" property which would set
cdev.default_trigger in t
On Thu, Jul 17, 2008 at 01:18:18PM -0700, Trent Piepho wrote:
> On Thu, 17 Jul 2008, Grant Likely wrote:
> > Alternately, I would also be okay with a scheme where all LED nodes
> > have a common parent and an of_platform driver would bind against the
> > parent node; not the individual children. T
Description:
While running on a system with new hardware and a kernel where the
cpu_specs[] table does not recognize the new hardware, the identify_cpu()
routine will select the default case as it searches through cpu_specs[]
in an attempt to match the real PVR. Once the default case is selecte
> All these operations are done assuming that tlb_gather_mmu disables
> preemption and tlb_finish_mmu enables preemption again.
> This is not true for -rt.
> For x86, none of the code paths between tlb_gather_mmu and
> tlb_finish_mmu access any per_cpu variables.
> But this is not true for powerpc
On Thu, 17 Jul 2008, Grant Likely wrote:
> Alternately, I would also be okay with a scheme where all LED nodes
> have a common parent and an of_platform driver would bind against the
> parent node; not the individual children. Then the leds-gpio driver
> could be refactored to have both platform a
> Ok, this makes sense. I've followed the bit down in the specification,
> and now it seems like we can't just set relaxed ordering in the IOMMU
> but should use the value that comes from the PCIe device.
>
> The flow of the order bit in this machine is as follows:
>
> 1. The device can select r
On Thu, 2008-07-17 at 16:53 +0200, Arnd Bergmann wrote:
>
> Peter and Hans were involved in the discussion that led to the
> decision
> to change step 3 from per-transfer default to always weak ordering.
> I think they verified that this is safe for all the peripherals that
> we
> have on the QS21
On Fri, 2008-07-18 at 00:10 +0530, Mohan Kumar M wrote:
> Extract list of relocation offsets
>
> Extract list of offsets in the vmlinux file for which the relocation
> delta has to be patched. Currently only following type of relocation
> types are considered: R_PPC64_ADDR16_HI, R_PPC64_TOC and R_
On Thu, 17 Jul 2008, Anton Vorontsov wrote:
> On Wed, Jul 16, 2008 at 10:13:06PM -0700, Trent Piepho wrote:
>> Ok, how about adding code the existing leds-gpio driver so that it can
>> creates
>> LEDs from of_platform devices too?
>
> Few comments below.
>
>> I've made a patch to do this and it wo
Arnd Bergmann wrote:
> So again, nothing conclusive. I'm running out of ideas.
Is the syscall path different or the same on ppc and powerpc?
Any differences in the task switching, irq handling or page fault
handling?
___
Linuxppc-dev mailing list
Linux
On Thursday 17 July 2008, Rune Torgersen wrote:
> Arnd Bergmann wrote:
> > Seeing more hits in handle_mm_fault suggests that you have
> > a higher page fault rate. A trivial reason for this might
> > be that the amount of memory was misdetected in the new
> > code (maybe broken device tree). What i
On Thu, Jul 17, 2008 at 11:02:15AM +0200, Oliver Rutsch wrote:
> Hi,
>
> We're using the latest 2.4.25-Kernel from DENX on a custom mpc5200b board.
> We have a RS485 device which sends continuously its data at a rate of
> 1.25 MBit/s. The problem here is that it takes nearly 90% of system time
Linus Torvalds wrote:
>
>
> On Thu, 17 Jul 2008, Benjamin Herrenschmidt wrote:
> >
> > Should I seek somebody's ack before merging a patch like the one below ?
> >
> > I'm a bit reluctant to merge via the powerpc.git tree some changes to
> > generic files without at least an ack from somebody e
Relocation support
This patch changes all LOAD_REG_ADDR macro calls to LOAD_REG_IMMEDIATE
to make sure that we load the correct address. It also takes care of
when accessing absolute symbols in the code by adding the relocation
kernel base address.
Signed-off-by: Mohan Kumar M <[EMAIL PROTECTED]>
Apply relocation
This code is a wrapper around regular kernel. This checks whether the
kernel is loaded at 32MB, if its not loaded at 32MB, its treated as a
regular kernel and the control is given to the kernel immediately. If
the kernel is loaded at 32MB, it applies relocation delta to each offse
Build files needed for relocation
This patch builds vmlinux file with relocation sections and contents so
that relocs user space program can extract the required relocation
offsets. This packs final relocatable vmlinux kernel as following:
earlier part of relocation apply code, vmlinux, rest of re
--- Benjamin Herrenschmidt <[EMAIL PROTECTED]> wrote:
> Arnd, Maxim, please, next time, send that patch or at least CC the
> bluesmoke-devel list for EDAC related bits.
>
> Doug, if you are ok with this patch, I'll merge it via the powerpc
fine with me, acked below
doug t
> tree.
>
> Cheers,
Extract list of relocation offsets
Extract list of offsets in the vmlinux file for which the relocation
delta has to be patched. Currently only following type of relocation
types are considered: R_PPC64_ADDR16_HI, R_PPC64_TOC and R_PPC64_ADDR64
The offsets are sorted according to the relocation t
Hi,
Following four patches enable the "relocatable kernel" feature for
PPC64 kernels.
1. extract_relocation_info.patch
2. relocation_build.patch
3. apply_relocation.patch
4. relocation_support.patch
With the patchset, vmcore image of a crashed system can be capture
Arnd Bergmann wrote:
> Seeing more hits in handle_mm_fault suggests that you have
> a higher page fault rate. A trivial reason for this might
> be that the amount of memory was misdetected in the new
> code (maybe broken device tree). What is the content of
> /proc/meminfo after a fresh boot?
Power
gcc 4.3 correctly determines that input() is unused and gives the
following warning:
<-- snip -->
...
HOSTCC arch/powerpc/boot/dtc-src/dtc-lexer.lex.o
dtc-lexer.lex.c:1436: warning: ‘input’ defined but not used
...
<-- snip -->
Fix it by adding %option noinput to
arch/powerpc/boot/dtc-
For C code spaces versus tabs is just a religious issue,
but for Makefiles it actually matters.
This patch fixes he following errors:
/home/bunk/linux/kernel-2.6/git/linux-2.6/arch/powerpc/boot/Makefile:166: ***
missing separator. Stop.
/home/bunk/linux/kernel-2.6/git/linux-2.6/arch/powerpc/boot
The real option is above in the same Kconfig file.
Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
---
2251e74345df51309579a0a5fd8339e2f14762b9
diff --git a/arch/powerpc/platforms/Kconfig.cputype
b/arch/powerpc/platforms/Kconfig.cputype
index 5bc4b61..6489d57 100644
--- a/arch/powerpc/platforms/
On Thu, Jul 17, 2008 at 9:20 AM, Anton Vorontsov
<[EMAIL PROTECTED]> wrote:
> On Thu, Jul 17, 2008 at 09:04:22AM -0600, Grant Likely wrote:
>> On Thu, Jul 17, 2008 at 06:13:35PM +0400, Anton Vorontsov wrote:
>> > On Thu, Jul 17, 2008 at 06:05:19PM +0400, Anton Vorontsov wrote:
>> > [...]
>> > > > I
On Thu, Jul 17, 2008 at 4:37 AM, Wolfgang Grandegger <[EMAIL PROTECTED]> wrote:
> This patch suppresses I2C device probing by clearing the class field
> of the "struct i2c_adapter" for the MPC I2C bus adapters. Some board
> configurations which rely on probing must be fixed up by adding a
> proper
Andrew Morton wrote:
> > On Tue, 2008-07-15 at 18:58 -0500, Nathan Lynch wrote:
> > > diff --git a/fs/binfmt_elf.c b/fs/binfmt_elf.c
> > > index d48ff5f..834c2c4 100644
> > > --- a/fs/binfmt_elf.c
> > > +++ b/fs/binfmt_elf.c
> > > @@ -131,6 +131,10 @@ static int padzero(unsigned long elf_bss)
> > >
On Thu, 17 Jul 2008 10:51:43 -0500
Kumar Gala <[EMAIL PROTECTED]> wrote:
>
> On Jul 17, 2008, at 10:27 AM, Kim Phillips wrote:
>
> > On Thu, 17 Jul 2008 07:26:14 -0500
> > Kumar Gala <[EMAIL PROTECTED]> wrote:
> >
> >>
> >> On Jul 17, 2008, at 7:17 AM, Herbert Xu wrote:
> >>
> >>> On Wed, Jul 16
On Thu Jul 17 at 23:22:28 EST in 2008, Guillaume Dargaud wrote:
Hello all,
I'm in the process of writing a mini-bootloaler for a custom board and
would
like some feedback on my boot methodology.
Basically the kernel code (elf file) is copied into memory by a JTAG
debugger. A custom program (y
On Thu, 17 Jul 2008, Benjamin Herrenschmidt wrote:
>
> Should I seek somebody's ack before merging a patch like the one below ?
>
> I'm a bit reluctant to merge via the powerpc.git tree some changes to
> generic files without at least an ack from somebody else :-)
Gaah. Generally we don't, but
This patch adds the binding for the property "read-fetch-delay" to the
sub-nodes of the "fsl,upm-nand" compatible nodes. It will be used by a
patch extending the support of the FSL UPM NAND driver for the TQM8548
modules, which do not have the R/B pin of the NAND chip connected.
Furthermore it doc
Grant Likely wrote:
> + aic26->codec.reg_cache_size = sizeof(aic26->reg_cache);
> + aic26->codec.reg_cache = aic26->reg_cache;
...
> + /* Register the sysfs files for debugging */
> + /* Create SysFS files */
> + rc = device_create_file(&spi->dev, &dev_attr_regs);
> + rc
On Jul 17, 2008, at 10:27 AM, Kim Phillips wrote:
On Thu, 17 Jul 2008 07:26:14 -0500
Kumar Gala <[EMAIL PROTECTED]> wrote:
On Jul 17, 2008, at 7:17 AM, Herbert Xu wrote:
On Wed, Jul 16, 2008 at 06:33:45PM -0500, Kumar Gala wrote:
On Jul 16, 2008, at 6:22 PM, Kim Phillips wrote:
use GFP
Arnd Bergmann wrote:
> Seeing more hits in handle_mm_fault suggests that you have
> a higher page fault rate. A trivial reason for this might
> be that the amount of memory was misdetected in the new
> code (maybe broken device tree). What is the content of
> /proc/meminfo after a fresh boot?
I al
On Thursday 17 July 2008, Rune Torgersen wrote:
> Arnd Bergmann wrote:
> > If you can't get it to work, readprofile(1) is a much simpler
> > tool, both in what it can do and what it requires you to do.
>
> One thing that pops out is that handle_mm_fault uses twice as many
> ticks in arch/powerpc.
On Jul 16, 2008, at 12:01 AM, Benjamin Herrenschmidt wrote:
On Wed, 2008-07-16 at 00:20 -0400, Dave Jones wrote:
On Wed, Jul 16, 2008 at 11:34:03AM +1000, Ben Herrenschmidt wrote:
Linus,
I apologize in advance for the couple of merge commits in there. I
merged your tree yesterday in order to
On Thu, 17 Jul 2008 07:26:14 -0500
Kumar Gala <[EMAIL PROTECTED]> wrote:
>
> On Jul 17, 2008, at 7:17 AM, Herbert Xu wrote:
>
> > On Wed, Jul 16, 2008 at 06:33:45PM -0500, Kumar Gala wrote:
> >>
> >> On Jul 16, 2008, at 6:22 PM, Kim Phillips wrote:
> >>
> >>> use GFP_ATOMIC when necessary; use a
On Thu, Jul 17, 2008 at 09:04:22AM -0600, Grant Likely wrote:
> On Thu, Jul 17, 2008 at 06:13:35PM +0400, Anton Vorontsov wrote:
> > On Thu, Jul 17, 2008 at 06:05:19PM +0400, Anton Vorontsov wrote:
> > [...]
> > > > I think it would be better to have a module that scans the device tree
> > > > for
Arnd Bergmann wrote:
> If you can't get it to work, readprofile(1) is a much simpler
> tool, both in what it can do and what it requires you to do.
One thing that pops out is that handle_mm_fault uses twice as many ticks
in arch/powerpc.
Top 20 calls from readprofile
2.6.25 arch/ppc
305993 total
On Thu, Jul 17, 2008 at 03:07:30PM +0400, Anton Vorontsov wrote:
> On Thu, Jul 17, 2008 at 07:59:03AM +0200, Segher Boessenkool wrote:
> > What would be the parent node of this, btw?
>
> This is tricky question. Personally I place them inside the gpio
> controller node that is responsible for the
On Thu, Jul 17, 2008 at 06:13:35PM +0400, Anton Vorontsov wrote:
> On Thu, Jul 17, 2008 at 06:05:19PM +0400, Anton Vorontsov wrote:
> [...]
> > > I think it would be better to have a module that scans the device tree
> > > for LED nodes and registers a single leds-gpio platform device for the
> > >
On Thu, 17 Jul 2008 15:07:30 +0400
"Anton Vorontsov" <[EMAIL PROTECTED]> wrote:
> This is tricky question. Personally I place them inside the gpio
> controller node that is responsible for the LED. But I think placing
> the led nodes at top level would be also fine (maybe with "leds { }"
> node as
On Thursday 17 July 2008, Benjamin Herrenschmidt wrote:
> On Wed, 2008-07-16 at 09:54 +0200, Arnd Bergmann wrote:
> > On Wednesday 16 July 2008, Roland Dreier wrote:
> > > > Strong ordering is only active when both the bridge and the IOMMU
> > > > enable it, but for correctly written drivers, thi
On Thu, Jul 17, 2008 at 06:05:19PM +0400, Anton Vorontsov wrote:
[...]
> > I think it would be better to have a module that scans the device tree
> > for LED nodes and registers a single leds-gpio platform device for the
> > whole lot.
> >
> > Thoughts?
>
> I like the idea, thanks.
Ugh, no. The
Hello all,
I'm in the process of writing a mini-bootloaler for a custom board and would
like some feedback on my boot methodology.
Basically the kernel code (elf file) is copied into memory by a JTAG
debugger. A custom program (yet to be finished) then copies it onto an
onboard flash memory u
On Wed, Jul 16, 2008 at 10:15:31PM -0600, Grant Likely wrote:
> On Wed, Jul 16, 2008 at 04:18:52PM -0700, Trent Piepho wrote:
> > On Tue, 15 Jul 2008, Anton Vorontsov wrote:
> > > Despite leds-gpio and leds-openfirmware-gpio similar purposes, there
> > > is not much code can be shared between the t
The OF parsing code for PCI addresses isn't always treating properly
the address space indication 0b11 (ie. 0x3) as meaning 64 bits
memory space.
This means that it fails to parse addresses for PCI BARs that have
this encoding set by the firmware, which happens on some SLOF
versions and breaks of
On Wed, Jul 16, 2008 at 10:13:06PM -0700, Trent Piepho wrote:
> on Wed, 16 Jul 2008, Grant Likely wrote:
> > On Wed, Jul 16, 2008 at 04:18:52PM -0700, Trent Piepho wrote:
> >> On Tue, 15 Jul 2008, Anton Vorontsov wrote:
> >>> Despite leds-gpio and leds-openfirmware-gpio similar purposes, there
> >>
David Gibson wrote:
On Wed, Jul 16, 2008 at 01:53:57PM -0400, Paul Gortmaker wrote:
It seems that some machines, like a default RHEL4 install, will
not have a definition for YYRHSLOC, and that prevents building
dtc. This supplies what appears to be the standard definition
for it in the event
Previous threads have mentioned that binutil-2.17 is broken for
building powerpc kernels. It is fixed in binutils-2.18.
Yes.
I have encountered this and upgrading to 2.18 fixed my build. The
symptom is large kernel sizes and a long time in gzip. In my case it
was gziping a 2GB file.
Are you
Hi Benjamin,
Thanks for the review
* Benjamin Herrenschmidt <[EMAIL PROTECTED]> [2008-07-15 11:32:01]:
> On Wed, 2008-07-09 at 21:35 +0530, Chirag Jog wrote:
> > Hi,
> > This patch fixes various paths in the -rt kernel on powerpc64 where per_cpu
> > variables are accessed in a preempt unsafe wa
On Jul 17, 2008, at 7:28 AM, Kumar Gala wrote:
On Jul 17, 2008, at 2:17 AM, Michael Ellerman wrote:
No change to the generated code.
Signed-off-by: Michael Ellerman <[EMAIL PROTECTED]>
---
arch/powerpc/lib/string.S | 18 ++
1 files changed, 6 insertions(+), 12 deletions(-)
On Jul 17, 2008, at 7:28 AM, Kumar Gala wrote:
On Jul 17, 2008, at 2:17 AM, Michael Ellerman wrote:
Signed-off-by: Michael Ellerman <[EMAIL PROTECTED]>
---
include/asm-powerpc/uaccess.h | 21 +
1 files changed, 9 insertions(+), 12 deletions(-)
What's the reason for the
On Jul 17, 2008, at 2:17 AM, Michael Ellerman wrote:
No change to the generated code.
Signed-off-by: Michael Ellerman <[EMAIL PROTECTED]>
---
arch/powerpc/lib/string.S | 18 ++
1 files changed, 6 insertions(+), 12 deletions(-)
What's the reason for the change?
- k
On Jul 17, 2008, at 2:17 AM, Michael Ellerman wrote:
Signed-off-by: Michael Ellerman <[EMAIL PROTECTED]>
---
include/asm-powerpc/uaccess.h | 21 +
1 files changed, 9 insertions(+), 12 deletions(-)
What's the reason for the change?
- k
On Jul 17, 2008, at 7:17 AM, Herbert Xu wrote:
On Wed, Jul 16, 2008 at 06:33:45PM -0500, Kumar Gala wrote:
On Jul 16, 2008, at 6:22 PM, Kim Phillips wrote:
use GFP_ATOMIC when necessary; use atomic_t when allocating
submit_count.
why?
You mean why are atomics required? Yes that is a goo
On Wed, Jul 16, 2008 at 06:33:45PM -0500, Kumar Gala wrote:
>
> On Jul 16, 2008, at 6:22 PM, Kim Phillips wrote:
>
> >use GFP_ATOMIC when necessary; use atomic_t when allocating
> >submit_count.
>
> why?
You mean why are atomics required? Yes that is a good question.
Kim?
Cheers,
--
Visit
On Wed, Jul 16, 2008 at 06:21:46PM -0500, Kim Phillips wrote:
> From: Lee Nipper <[EMAIL PROTECTED]>
>
> Remove of_node_put calls since there is no corresponding of_node_get.
> This patch prevents an exception when talitos is loaded a 2nd time.
> This sequence: modprobe talitos; rmmod talitos; mod
On 7/17/08, Nobin Mathew <[EMAIL PROTECTED]> wrote:
> Hi Dinesh,
>
> If that is your requirement then go and see the actual code
> sound/arm/aaci.c. They are not using DMA. It is programmed IO.
Search around the list archives, the first version of the
Efika/mpc5200 ac97 driver was programmed IO.
On Thu, 2008-07-17 at 18:48 +0800, Jin Zhengxiong wrote:
> Ack, Tested the patch set on Freescale board and working good.
> Thanks
Thanks for testing.
cheers
--
Michael Ellerman
OzLabs, IBM Australia Development Lab
wwweb: http://michael.ellerman.id.au
phone: +61 2 6212 1183 (tie line 70 21183
Hi Dinesh,
If that is your requirement then go and see the actual code
sound/arm/aaci.c. They are not using DMA. It is programmed IO.
Thanks
Nobin Mathew
On 7/17/08, Mark Brown <[EMAIL PROTECTED]> wrote:
>
> On Thu, Jul 17, 2008 at 11:33:31AM +0530, dinesh wrote:
>
> > What i want is that i hav
On Thu, Jul 17, 2008 at 07:59:03AM +0200, Segher Boessenkool wrote:
>> diff --git a/Documentation/powerpc/dts-bindings/gpio/led.txt
>> b/Documentation/powerpc/dts-bindings/gpio/led.txt
>> new file mode 100644
>> index 000..7e9ce81
>> --- /dev/null
>> +++ b/Documentation/powerpc/dts-bindings/g
On Thu, Jul 17, 2008 at 11:33:31AM +0530, dinesh wrote:
> What i want is that i have a buffer in driver code which is also handled
> by some other application i want that this buffer data is to be used for
> capture and playback stream fills data to another buffer which i can
> passover to my oth
Together with the previous patch, I've tested this on mmotm, including
with 64K base pages. However I only have a machine with a single possible
hugepage size, so testing a real multi size system would be nice.
Thanks to Dave for reworking for multiple hugepage sizes (Dave, I had to
make a small
Ack, Tested the patch set on Freescale board and working good.
Thanks
Jason Jin
> -Original Message-
> From: Michael Ellerman [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, July 15, 2008 10:46 PM
> To: Benjamin Herrenschmidt
> Cc: linuxppc-dev@ozlabs.org; Olof Johannsson; Gala Kumar; Jin
>
This can be folded into powerpc-implement-pte_special.patch
--
Ben has now freed up a pte bit on 64k pages. Use it for special pte bit.
Signed-off-by: Nick Piggin <[EMAIL PROTECTED]>
---
Index: linux-2.6/include/asm-powerpc/pgtable-64k.h
==
Grant Likely wrote:
On Thu, Jul 17, 2008 at 09:31:24AM +0200, Wolfgang Grandegger wrote:
Jean Delvare wrote:
On Wed, 16 Jul 2008 10:18:26 -0400, Jon Smirl wrote:
I've found this thread now. Why can't we totally remove probing from
i2c-mpc? These are embedded systems, not open boxes like a PC.
This patch suppresses I2C device probing by clearing the class field
of the "struct i2c_adapter" for the MPC I2C bus adapters. Some board
configurations which rely on probing must be fixed up by adding a
proper I2C device node to the DTS file, like the TQM85xx modules.
Signed-off-by: Wolfgang Gra
Hello, all:
I am building a Linux kernel module for PPC405EP. My developing
board is PPChameleonEVB. I am debugging with BDI2000 and GDB, and my
problem is:
In GDB, a section of the codes is disassembled to:
mfmsr r0
ori r0,r0,32768
mtmsr r0
blr
From BDI2
Hi,
on an Apple Powerbook G3 (Lombard) with a PPC 740 running at 333 MHz, the
PCI host bridge is condigured to allow "downstream" devices to use iomem
0xfd00 - 0xfdff
However, when using it for PCMCIA purposes, there's a machine check. Any
ideas on why this PCI host bridge is mis-configu
Hi,
We're using the latest 2.4.25-Kernel from DENX on a custom mpc5200b board.
We have a RS485 device which sends continuously its data at a rate of
1.25 MBit/s. The problem here is that it takes nearly 90% of system time
just to read these data. I had a look into the driver
(arch/ppc/5xxx_io/
On Thu, Jul 17, 2008 at 09:31:24AM +0200, Wolfgang Grandegger wrote:
> Jean Delvare wrote:
>> On Wed, 16 Jul 2008 10:18:26 -0400, Jon Smirl wrote:
>>> I've found this thread now. Why can't we totally remove probing from
>>> i2c-mpc? These are embedded systems, not open boxes like a PC. If a
>>> i2c
Jean Delvare wrote:
On Wed, 16 Jul 2008 10:18:26 -0400, Jon Smirl wrote:
On 7/16/08, Grant Likely <[EMAIL PROTECTED]> wrote:
On Wed, Jul 16, 2008 at 12:10:59PM +0200, Jean Delvare wrote:
> On Wed, 16 Jul 2008 11:50:15 +0200, Wolfgang Grandegger wrote:
> > Jean Delvare wrote:
> >
Yep, as pr
Signed-off-by: Michael Ellerman <[EMAIL PROTECTED]>
---
arch/powerpc/kernel/ftrace.c | 13 +++--
1 files changed, 3 insertions(+), 10 deletions(-)
diff --git a/arch/powerpc/kernel/ftrace.c b/arch/powerpc/kernel/ftrace.c
index 49a2049..0e9fc10 100644
--- a/arch/powerpc/kernel/ftrace.c
++
Use create_branch() rather than doing it by hand. It's possible that
we are unable to create a branch to the address, if it's too far away,
in which case just return a nop. This will break the tracing, but
shouldn't crash the kernel at least.
Signed-off-by: Michael Ellerman <[EMAIL PROTECTED]>
---
Signed-off-by: Michael Ellerman <[EMAIL PROTECTED]>
---
arch/powerpc/kernel/ftrace.c | 10 +-
1 files changed, 1 insertions(+), 9 deletions(-)
diff --git a/arch/powerpc/kernel/ftrace.c b/arch/powerpc/kernel/ftrace.c
index 78f4423..1d6f174 100644
--- a/arch/powerpc/kernel/ftrace.c
+++ b/
And move ftrace_nop into the only function it's used in.
Signed-off-by: Michael Ellerman <[EMAIL PROTECTED]>
---
arch/powerpc/kernel/ftrace.c |5 +++--
1 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/kernel/ftrace.c b/arch/powerpc/kernel/ftrace.c
index 3855ceb..78f
No change to the generated code.
Signed-off-by: Michael Ellerman <[EMAIL PROTECTED]>
---
arch/powerpc/lib/string.S | 18 ++
1 files changed, 6 insertions(+), 12 deletions(-)
diff --git a/arch/powerpc/lib/string.S b/arch/powerpc/lib/string.S
index 49eb1f1..64e2e49 100644
--- a/a
Signed-off-by: Michael Ellerman <[EMAIL PROTECTED]>
---
include/asm-powerpc/uaccess.h | 21 +
1 files changed, 9 insertions(+), 12 deletions(-)
diff --git a/include/asm-powerpc/uaccess.h b/include/asm-powerpc/uaccess.h
index 1a0736f..bd0fb84 100644
--- a/include/asm-powerpc/
Add a #define for aligning to a long-sized boundary. It would be nice
to use sizeof(long) for this, but that requires generating the value
with asm-offsets.c, and asm-offsets.c includes asm-compat.h and we
descend into some sort of recursive include hell.
Signed-off-by: Michael Ellerman <[EMAIL PR
On Thu, 17 Jul 2008 16:35:39 +1000 Benjamin Herrenschmidt <[EMAIL PROTECTED]>
wrote:
> Hi Linus, Andrew !
>
> Should I seek somebody's ack before merging a patch like the one below ?
I think it's good to do so.
> I'm a bit reluctant to merge via the powerpc.git tree some changes to
> generic f
95 matches
Mail list logo
