On Dec 11, 2008, at 10:07 PM, Trent Piepho wrote:
On Thu, 11 Dec 2008, Kumar Gala wrote:
On Dec 11, 2008, at 6:04 AM, maillist.kernel wrote:
In the system, the total PCI address needed is about 3GB, so I
want to know
how to support it in linux. mpc8548 has 36-bit real address, and can
suppo
On Thu, 11 Dec 2008, Kumar Gala wrote:
> On Dec 11, 2008, at 6:04 AM, maillist.kernel wrote:
>> In the system, the total PCI address needed is about 3GB, so I want to know
>> how to support it in linux. mpc8548 has 36-bit real address, and can
>> support 32GB PCIE address space, but in linux, the
On Friday 12 December 2008 13:47, Andrew Morton wrote:
> On Fri, 12 Dec 2008 12:31:33 +1000 Nick Piggin
wrote:
> > On Friday 12 December 2008 07:43, Andrew Morton wrote:
> > > On Thu, 11 Dec 2008 20:28:00 +
> > >
> > > > Do they actually cross the page boundaries?
> > >
> > > Some flavours o
On Fri, 12 Dec 2008 12:31:33 +1000 Nick Piggin wrote:
> On Friday 12 December 2008 07:43, Andrew Morton wrote:
> > On Thu, 11 Dec 2008 20:28:00 +
>
> > > Do they actually cross the page boundaries?
> >
> > Some flavours of slab have at times done an order-1 allocation for
> > objects which
On Friday 12 December 2008 07:43, Andrew Morton wrote:
> On Thu, 11 Dec 2008 20:28:00 +
> > Do they actually cross the page boundaries?
>
> Some flavours of slab have at times done an order-1 allocation for
> objects which would fit into an order-0 page (etc) if it looks like
> that will be b
Dear Ron Madrid,
In message <454690.60670...@web83505.mail.sp1.yahoo.com> you wrote:
> Thank you. That took care of it. I knew it was something small.
It's fixed in our tree now, too.
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 1
On Thu, Dec 11, 2008 at 06:19:20PM -0600, Kumar Gala wrote:
>
> On Dec 11, 2008, at 5:48 PM, Ron Madrid wrote:
>
>> Hello all,
>>
>> I got the latest kernel from git://git.denx.de/linux-2.6-denx.git and
>> after
>> configuring with menuconfig I am seeing these errors. I feel like
>> this
>> cou
On Fri, 12 Dec 2008 11:48:29 +1100 Paul Mackerras wrote:
> Andrew Morton writes:
>
> > > +#if (8 * THREAD_SIZE) > PAGE_SIZE
> > > max_threads = mempages / (8 * THREAD_SIZE / PAGE_SIZE);
> > > +#else
> > > + max_threads = mempages * (PAGE_SIZE / (8 * THREAD_SIZE));
> > > +#endif
> >
> > The ex
Andrew Morton writes:
> > +#if (8 * THREAD_SIZE) > PAGE_SIZE
> > max_threads = mempages / (8 * THREAD_SIZE / PAGE_SIZE);
> > +#else
> > + max_threads = mempages * (PAGE_SIZE / (8 * THREAD_SIZE));
> > +#endif
>
> The expression you've chosen here can be quite inacccurate, because
> ((PAGE_SI
Thank you. That took care of it. I knew it was something small.
Ron
- Original Message
> From: Kumar Gala
> To: Ron Madrid
> Cc: linuxppc-dev@ozlabs.org
> Sent: Thursday, December 11, 2008 4:21:26 PM
> Subject: Re: Problem building kernel
>
>
> On Dec 11, 2008, at 5:48 PM, Ron Ma
On Dec 11, 2008, at 5:48 PM, Ron Madrid wrote:
Hello all,
I got the latest kernel from git://git.denx.de/linux-2.6-denx.git
and after
configuring with menuconfig I am seeing these errors. I feel like
this
could be something simple that I am just unaware of, but I'm not sure
and haven't b
On Dec 11, 2008, at 5:48 PM, Ron Madrid wrote:
Hello all,
I got the latest kernel from git://git.denx.de/linux-2.6-denx.git
and after
configuring with menuconfig I am seeing these errors. I feel like
this
could be something simple that I am just unaware of, but I'm not sure
and haven't b
On Mon, 08 Dec 2008 16:39:52 +1100
Benjamin Herrenschmidt wrote:
> We were missing the CPU_FTR_NOEXECUTE bit in our cputable for all
> these processors. The result is that update_mmu_cache() would flush
> the cache for all pages mapped to userspace which is totally
> unnecessary on those processo
Hello all,
I got the latest kernel from git://git.denx.de/linux-2.6-denx.git and after
configuring with menuconfig I am seeing these errors. I feel like this
could be something simple that I am just unaware of, but I'm not sure
and haven't been able to find anything useful when doing a web search
> I'm still working on various issues with the hardware. Soon I'll be able
> to easily test several boards in the same system at the same time. Once
> I've proven that works, I'll start nagging :)
>
> Is there a better subject line I should use to get attention, or should
> I just start CC'ing pe
On Fri, 12 Dec 2008 01:22:32 +0300
Yuri Tikhonov wrote:
> > so how about avoiding the nasty ifdefs and doing
>
> I'm OK with the approach below, but, leading resulting to the same,
> this involves some overhead to the code where there was no this
> overhead before this patch: e.g. your implem
Hello Andrew,
On Thursday, December 11, 2008 you wrote:
[snip]
> The expression you've chosen here can be quite inacccurate, because
> ((PAGE_SIZE / (8 * THREAD_SIZE)) is a small number.
But why is it bad? We do multiplication to 'mempages', not division.
All the numbers in the multiplier a
I rechecked it and I should have taken away all the only-whitespace changes.
The diffs are from the ads5121 branch from Denx.
Regards,
M
Josh Boyer ha scritto:
On Thu, 11 Dec 2008 19:39:21 +0100
Matteo Fortini wrote:
This patch is to avoid breaking some drivers, in my case the ADS7846
t
On Thu, 11 Dec 2008 22:57:56 +0100
Matteo Fortini wrote:
> I rechecked it and I should have taken away all the only-whitespace changes.
No, I mean the patch is corrupted. Your mailer has taken tabs and
turned them into spaces. Thunderbird sucks.
> The diffs are from the ads5121 branch from De
Replace the two boolean properties default_state and keep_state with a
single tristate property that can be set to
LEDS_GPIO_DEFSTATE_(ON|OFF|KEEP). This ends up being more complicated,
requires more code, and makes developers remember not just the name of the
field to set but also the symbolic co
Let GPIO LEDs get their initial value from whatever the current state of
the GPIO line is. On some systems the LEDs are put into some state by the
firmware or hardware before Linux boots, and it is desired to have them
keep this state which is otherwise unknown to Linux.
This requires that the un
Add bindings to support LEDs defined as of_platform devices in addition to
the existing bindings for platform devices.
New options in Kconfig allow the platform binding code and/or the
of_platform code to be turned on. The of_platform code is of course only
available on archs that have OF support
Yes, there is the "default-on" trigger but there are problems with that.
For one, it's a inefficient way to do it and requires led trigger support
to be compiled in.
But the real reason is that is produces a glitch on the LED. The GPIO is
allocate with the LED *off*, then *later* when then trigg
On Wed, 10 Dec 2008, Anton Vorontsov wrote:
>> +gpio_direction_output(led_dat->gpio, led_dat->active_low);
>
> This can fail (yeah, the original code didn't check return value
> either).
I've added a check.
>> +unsigned int flags;
>
> I think it would be better to use `enum of_gpi
On Thu, 2008-12-11 at 07:59 -0700, Gary Thomas wrote:
>
> Notice that of_irq_map_one() can fail for a myriad of reasons - all quiet
> (without debugging on). This function simply masks those into "sorry..."
Right, it's not verbose on failure for various reasons. Most failures
because something w
On Thu, Dec 11, 2008 at 04:05:37PM +0100, Wolfram Sang wrote:
> Make the generic uio-driver also accessible for of devices. It utilizes the
> standard 'reg' and 'interrupt' properties. A typical usage would look like
> this:
>
> fpga...@3000 {
> compatible = "generic-uio";
On Thu, 11 Dec 2008 20:28:00 +
Al Viro wrote:
> On Thu, Dec 11, 2008 at 12:16:35PM -0800, Andrew Morton wrote:
> > > +#if (8 * THREAD_SIZE) > PAGE_SIZE
> > > max_threads = mempages / (8 * THREAD_SIZE / PAGE_SIZE);
> > > +#else
> > > + max_threads = mempages * (PAGE_SIZE / (8 * THREAD_SIZE))
On Thu, Dec 11, 2008 at 12:16:35PM -0800, Andrew Morton wrote:
> > +#if (8 * THREAD_SIZE) > PAGE_SIZE
> > max_threads = mempages / (8 * THREAD_SIZE / PAGE_SIZE);
> > +#else
> > + max_threads = mempages * (PAGE_SIZE / (8 * THREAD_SIZE));
> > +#endif
>
> The expression you've chosen here can b
On Wed, 10 Dec 2008 19:50:51 +0300
Yuri Tikhonov wrote:
>
> The following patch fixes divide-by-zero error for the
> cases of really big PAGE_SIZEs (e.g. 256KB on ppc44x).
> Support for big page sizes on 44x is not present in the
> current kernel yet, but coming soon.
>
> Also this patch fixes
Currently there are a number of platforms that open code access to
the ppc_pci_flags global variable. However, that variable is not
present if CONFIG_PCI is not set, which can lead to a build break.
This introduces a number of accessor functions that are defined
to be empty in the case of CONFIG_
Mark Brown wrote:
> Well, from that point of view now would be a good time for you to start
> backporting your newer code. The concept of having the core wait for
> subdevices to probe is now there which was the major win from the point
> of view of integration with the device tree. What's there
Since "Factor out cpu joining/unjoining the GIQ"
(b4963255ad5a426f04a0bb15c4315fa4bb40cde9) the WARN_ON in
xics_set_cpu_giq() is being triggered during boot on JS20 because the
GIQ indicator is not available on that platform. While the warning is
harmless and the system runs normally, it's nicer t
On Thu, Dec 11, 2008 at 09:45:26AM -0600, Timur Tabi wrote:
> And since I fixed the code in the V2 drivers, I have no interest in fixing it
> in
> the V1 drivers, which are officially in maintenance mode -- only critical bug
> fixes, no new features.
Well, from that point of view now would be a
On Thu, 11 Dec 2008 19:39:21 +0100
Matteo Fortini wrote:
>
> This patch is to avoid breaking some drivers, in my case the ADS7846
> touchscreen one, which use 1 char messages.
> If you put the dummy byte after the 1 char message, you get part of the
> answer to the message in the rxbuf of the
Gah, sorry. I resent my description for the whole series from yesterday
instead of one just for these bug fixes.
The first patch removes a warning in numa.c that I just caused.
The second one is a rework of the bug fix that was at the head of the
series yesterday, addressing some comments that P
This patch is to avoid breaking some drivers, in my case the ADS7846
touchscreen one, which use 1 char messages.
If you put the dummy byte after the 1 char message, you get part of the
answer to the message in the rxbuf of the message, which is thrown away.
The solution is to put the dummy by
careful_allocation() was calling into the bootemem allocator for
nodes which had not been fully initialized and caused a previous
bug. http://patchwork.ozlabs.org/patch/10528/ So, I merged a
few broken out loops in do_init_bootmem() to fix it. That changed
the code ordering.
I think this bug i
The first patch in this series is a genuine bug fix. The rest
are really just an RFC.
Jon introduced a bug a while ago. I introduced another when
trying to fix Jon's bug. I refuse to accept personal blame for
this and, instead, blame the code. :)
The reset of the series are "cleanups" that I t
---
linux-2.6.git-dave/arch/powerpc/mm/numa.c |1 -
1 file changed, 1 deletion(-)
diff -puN arch/powerpc/mm/numa.c~remove-unused-i-var arch/powerpc/mm/numa.c
--- linux-2.6.git/arch/powerpc/mm/numa.c~remove-unused-i-var2008-12-11
09:12:57.0 -0800
+++ linux-2.6.git-dave/arch/pow
Josh,
I will be handling this patch from now on. I will modify the patch and
answer your queries soon.
Thanks,
Marri
Message: 2
Date: Mon, 1 Dec 2008 20:32:56 -0500
From: Josh Boyer
Subject: Re: [PATCH] Add_460SX_Initial_Framework
To: mmadishe...@amcc.com
Cc: linuxppc-dev@ozlabs.org
Message-ID
On Thu, Dec 11, 2008 at 10:04:28PM +1100, Benjamin Herrenschmidt wrote:
> On Wed, 2008-12-10 at 16:17 -0800, Ira Snyder wrote:
> > On Wed, Dec 10, 2008 at 05:29:53PM -0600, Ayman El-Khashab wrote:
> > > My system consists of a pair of 460EXs attached by way of both PCI-E and
> > > PCI. Ultimately
On Dec 11, 2008, at 6:04 AM, maillist.kernel wrote:
Hi, we want to design a system using mpc8548, and linking with an
idt 16 ports PCIE switch.
In the system, the total PCI address needed is about 3GB, so I want
to know how to support it in linux. mpc8548 has 36-bit real address,
and can s
On Thu, Dec 11, 2008 at 09:12:54AM -0600, Timur Tabi wrote:
> On Thu, Dec 11, 2008 at 7:18 AM, Peter Czanik <[EMAIL PROTECTED]> wrote:
> > As far as I can see from comments in the sources, it should work also as
> > a module. Any hints how to achieve that?
> The ASoC V2 version of the driver supp
Mark Brown wrote:
> The only references should be machine->{codec,ssi} and ssi->platform.
> There's a reasonable chance that your drivers would work fine if you
> just marked them all as tristate, though since they're written rather
> differently to other ASoC drivers it's possible something will
On Thu, Dec 11, 2008 at 09:40:55AM -0600, Timur Tabi wrote:
> Mark Brown wrote:
> > ASoC v1 supports loading drivers as modules (and this is fairly heavily
> > used), though as you say the MPC8610 drivers don't support that.
> Well, at the time I wrote the drivers, I didn't see an easy way to sup
Mark Brown wrote:
> ASoC v1 supports loading drivers as modules (and this is fairly heavily
> used), though as you say the MPC8610 drivers don't support that.
Well, at the time I wrote the drivers, I didn't see an easy way to support
modules, since V1 drivers typically have lots of hard-coded ref
Hi Paul,
Please pull the 'next' branch of the 4xx tree to pick up some initial
commits for 2.6.29.
There are a large number of patches from Ben for some MMU rework that
will effect 4xx, but I think most of those are going in either through
you directly, or through Kumar. I have a couple of other
On Thu, Dec 11, 2008 at 7:18 AM, Peter Czanik <[EMAIL PROTECTED]> wrote:
> Hello,
>
> I have an MPC8610HPCD system. The latest stable kernel (2.6.27.8) runs
> fine on this, with a catch: sound only works, when compiled in the
> kernel
That's because the driver doesn't support being compiled as a m
Make the generic uio-driver also accessible for of devices. It utilizes the
standard 'reg' and 'interrupt' properties. A typical usage would look like
this:
[EMAIL PROTECTED] {
compatible = "generic-uio";
reg = <0x3000 0x20>;
interrupts =
Benjamin Herrenschmidt wrote:
[EMAIL PROTECTED] {
device_type = "board-control";
#address-cells = <1>;
#size-cells = <1>;
// Note: includes sub-devices like CAN, A/D, etc
reg = <0xf800 0x10>;
Josh Boyer <[EMAIL PROTECTED]> wrote:
> Is there a reason you renamed all the function names as well when they
> are static?
Well, static functions can still conflict with a function of the same name
that's declared globally in a header file, but mainly because M-x
replace-string doesn't differen
On Thu, 11 Dec 2008 12:53:54 +
David Howells <[EMAIL PROTECTED]> wrote:
> Rename PowerPC's struct vm_region so that I can introduce my own global
> version
> for NOMMU. It's feasible that the PowerPC version may wish to use my global
> one instead.
>
> The NOMMU vm_region struct defines are
On Wed, 10 Dec 2008 19:49:58 +0100
Matteo Fortini <[EMAIL PROTECTED]> wrote:
> From d500e922b750a2bea554d32d8f12937f4da9c80a Mon Sep 17 00:00:00 2001
> From: Matteo Fortini <[EMAIL PROTECTED]>
> Date: Wed, 10 Dec 2008 19:33:16 +0100
> Subject: [PATCH] Fix: put dummy byte to enable fixing EOF bug
Hello,
I have an MPC8610HPCD system. The latest stable kernel (2.6.27.8) runs
fine on this, with a catch: sound only works, when compiled in the
kernel (see:
http://www.alsa-project.org/db/?f=73fb074ce0b41463bb3f32aaa297a1e1f53caf2d
). When the exact same sound options are compiled as modules (see
Rename PowerPC's struct vm_region so that I can introduce my own global version
for NOMMU. It's feasible that the PowerPC version may wish to use my global
one instead.
The NOMMU vm_region struct defines areas of the physical memory map that are
under mmap. This may include chunks of RAM or regi
Hi Paul,
I have one more small fix for 2.6.28 in my merge branch. It fixes
an assembler error with some toolchains, notably ELDK. I've CC'd
Linus in case you don't have anything else pending at the moment.
josh
The following changes since commit ab44f4627e2160cddbddbe8aa8b1d2b2e1559790:
Paul
Hi, we want to design a system using mpc8548, and linking with an idt 16 ports
PCIE switch.
In the system, the total PCI address needed is about 3GB, so I want to know how
to support it in linux. mpc8548 has 36-bit real address, and can support 32GB
PCIE address space, but in linux, there is onl
On Wed, 2008-12-10 at 19:53 -0500, Josh Boyer wrote:
>
> That's fine too. I think you can Michael can have a virtual
> arm-wrestling match to decide whether ppc_pci_has_flag or
> ppc_pci_flags_are_set wins ;)
I vote for _has_flag() :-)
I even wonder if we need the word "flag" in there at all, b
On Wed, 2008-12-10 at 16:17 -0800, Ira Snyder wrote:
> On Wed, Dec 10, 2008 at 05:29:53PM -0600, Ayman El-Khashab wrote:
> > My system consists of a pair of 460EXs attached by way of both PCI-E and
> > PCI. Ultimately my goal is to communicate between them via pci-e (is
> > there anything out ther
Hi Paul,
Today's linux-next build (powerpc allyesconfig) produced this warning:
arch/powerpc/mm/numa.c: In function 'do_init_bootmem':
arch/powerpc/mm/numa.c:932: warning: unused variable 'i'
Caused by commit 4a6186696e7f15b3ea4dafcdb64ee0703e0e4487 ("powerpc: Fix
boot freeze on machine with emp
60 matches
Mail list logo
