[PATCH v2 1/2] 82xx, mgcoge: updates for 2.6.32
- add I2C support
- add FCC1 and FCC2 support
- fix bogus gpio numbering in plattformcode
Signed-off-by: Heiko Schocher
---
- against git://git.kernel.org/pub/scm/linux/kernel/git/benh/powerpc.git
next branch
- checked with checkpatch.pl:
$ ./scr
- add I2C support
- add FCC1 and FCC2 support
Signed-off-by: Heiko Schocher
---
- against git://git.kernel.org/pub/scm/linux/kernel/git/benh/powerpc.git
next branch
- checked with checkpatch.pl:
$ ./scripts/checkpatch.pl 0002-82xx-mgcoge-update-defconfig-for-2.6.32.patch
total: 0 errors, 0 warn
Steven Rostedt wrote:
Thanks,
I've seen issues with my PPC box and function graph, but the bugs were
also caused by other changes. I'll boot up my PPC64 box and see if
I see the same issues you have.
Hi Steven,
I can still recreate this issue with 2.6.31-rc5. Let me know
if i can provide an
Check whether index is within bounds before grabbing the element.
Signed-off-by: Roel Kluin
---
diff --git a/drivers/macintosh/macio_asic.c b/drivers/macintosh/macio_asic.c
index a0f6838..588a5b0 100644
--- a/drivers/macintosh/macio_asic.c
+++ b/drivers/macintosh/macio_asic.c
@@ -294,10 +294,11 @
Roel Kluin writes:
> Check whether index is within bounds before grabbing the element.
The change seems unnecessary since we only compute the address of the
element before the bounds check, we don't actually access the
element. I believe that is legal in C.
Paul.
___
Hi all,
due to a new revision of our custimized board, i need to port our current
kernel (2.6.24)
to the latest kernel version 2.6.30.4.
Among other things the UIO interrupt driver makes some trouble. The driver runs
smoothly on 2.6.24 but I'll get kernel faults when running in 2.6.30.4.
It's a
On Mon, Aug 03, 2009 at 10:57:17PM +1000, Paul Mackerras wrote:
> Roel Kluin writes:
>
> > Check whether index is within bounds before grabbing the element.
>
> The change seems unnecessary since we only compute the address of the
> element before the bounds check, we don't actually access the
>
On Sun, 2009-08-02 at 17:50 +1000, Benjamin Herrenschmidt wrote:
> On Sat, 2009-08-01 at 10:00 +0100, David Woodhouse wrote:
> > I'm not sure. Losing 16MiB on a machine which only has 512MiB anyway
> > doesn't seem ideal, and we'll want to make the no-iommu code DTRT
> > _anyway_, surely?
> >
> > S
Hi,
On Fri, 2009-07-31 at 16:10 +1000, David Gibson wrote:
> On Mon, Jul 27, 2009 at 05:41:52AM +0530, K.Prasad wrote:
> > Hi David,
> > I'm back with a new version of patches after a brief hiatus!
> >
> > After much deliberation about modifying the code to change the timing of
> > signal
>
On Aug 2, 2009, at 9:03 PM, Michael Ellerman wrote:
On Sat, 2009-08-01 at 08:29 +1000, Benjamin Herrenschmidt wrote:
On Thu, 2009-07-30 at 22:35 -0500, Kumar Gala wrote:
/* XXX This clear should ultimately be part of
local_flush_tlb_mm */
- __clear_bit(id, stale_map
In the current code, all MPC5200 timers are registered by the
mpc52xx_gpt driver, even if gpt0 (the only one with this capability)
shall be used as hardware watchdog which is indicated by the
"fsl,has-wdt" or "has-wdt" property in the device tree. Thus, the
watchdog driver does never find
On Mon, 2009-08-03 at 11:21 -0500, Kumar Gala wrote:
> On Aug 2, 2009, at 9:03 PM, Michael Ellerman wrote:
>
> > On Sat, 2009-08-01 at 08:29 +1000, Benjamin Herrenschmidt wrote:
> >> On Thu, 2009-07-30 at 22:35 -0500, Kumar Gala wrote:
> /* XXX This clear should ultimately be par
On Mon, 2009-08-03 at 12:06 -0500, Dave Kleikamp wrote:
> On Mon, 2009-08-03 at 11:21 -0500, Kumar Gala wrote:
> > On Aug 2, 2009, at 9:03 PM, Michael Ellerman wrote:
> >
> > > for (cpu = cpu_first_thread_in_core(cpu);
> > > cpu <= cpu_last_thread_in_core(cpu); cpu++)
> > >__clear_bit
On Mon, Aug 3, 2009 at 10:40 AM, Albrecht Dreß wrote:
> In the current code, all MPC5200 timers are registered by the mpc52xx_gpt
> driver, even if gpt0 (the only one with this capability) shall be used as
> hardware watchdog which is indicated by the "fsl,has-wdt" or "has-wdt"
> property in the de
Am 03.08.09 19:50 schrieb(en) Grant Likely:
Just about all mpc5200 device trees have the fsl,has-wdt property on
GPT0 even when it isn't used as a watchdog.
Sorry, I do not understand... The file
Documentation/powerpc/dts-bindings/fsl/mpc5200.txt says
On the mpc5200 and 5200b, GPT0 has a
Hello,
I'm testing KMS on my G4 machine, but it is making problems. I tried different
approaches:
When booting with KMS and agpmode=1 i get this output:
[drm] Initialized drm 1.1.0 20060810
[drm] radeon kernel modesetting enabled.
The change seems unnecessary since we only compute the address of the
element before the bounds check, we don't actually access the
element. I believe that is legal in C.
If you have an array a[N], taking &a[0] .. &a[N] are legal C, everything
else is not.
Segher
On Fri, Jul 31, 2009 at 04:10:13PM +1000, David Gibson wrote:
> On Mon, Jul 27, 2009 at 05:41:52AM +0530, K.Prasad wrote:
> > Reasons
> >
> > - Signal delivery before execution of instruction requires complex
> > workarounds
> > - One of the plausible workarounds is a two-pass hw-break
On Fri, Jul 31, 2009 at 04:16:46PM +1000, David Gibson wrote:
> On Mon, Jul 27, 2009 at 05:43:17AM +0530, K.Prasad wrote:
> > Introduce PPC64 implementation for the generic hardware breakpoint
> > interfaces
> > defined in kernel/hw_breakpoint.c. Enable the HAVE_HW_BREAKPOINT flag and
> > the
> >
> for (cpu = cpu_first_thread_in_core(cpu);
> cpu <= cpu_last_thread_in_core(cpu); cpu++)
> __clear_bit(id, stale_map[cpu]);
>
> ==
>
> cpu = cpu_first_thread_in_core(cpu);
> while (cpu <= cpu_last_thread_in_core(cpu)) {
> __clear_bit(id, stale_map[cpu]);
> cpu++;
> }
>
On Mon, 2009-08-03 at 14:14 +0100, David Woodhouse wrote:
> Do we care about that scenario? I think we might be able to "fix" it by
> setting the memory_limit when we allow pci_set_dma_mask() to succeed?
> That will effectively prevent the addition of memory that our crappy
> device can't reach, w
On Mon, 2009-08-03 at 15:07 +0200, Frank Prepelica wrote:
> Hi all,
>
> due to a new revision of our custimized board, i need to port our current
> kernel (2.6.24)
> to the latest kernel version 2.6.30.4.
>
> Among other things the UIO interrupt driver makes some trouble. The driver
> runs
> sm
Greetings, everyone,
I'm trying to save some data block from a memory mapped device into a
file - real fast, i.e., without any copying.
My approach so far was to get a pointer to the io memory via mmap-ing
/dev/mem, and then writing this pointer to a file (in user space).
This works, if I don't u
23 matches
Mail list logo
