On Thursday 09 October 2008, Steven A. Falco wrote:
> This patch adds support for the GPIO functions of PPC40x and PPC44x
> SOCs.
Thanks. Tested successfully on 405EP board.
I only have one comment below left.
> Signed-off-by: Steve Falco
> ---
>
> I looked more closely at the datasheet. Stefa
On Fri, 2008-10-10 at 02:10 +0400, Anton Vorontsov wrote:
> You should keep resending the patches till somebody merge them. ;-)
>
> As for my patches... David, could you please apply that patch:
> http://lists.infradead.org/pipermail/linux-mtd/2008-September/023038.html
Applied, along with $SUBJE
[EMAIL PROTECTED] writes:
> The current 64 bit csum_partial_copy_generic function is based on the 32
> bit version and never was optimized for 64 bit. This patch takes the 64 bit
> memcpy and adapts it to also do the sum. It has been tested on a variety
> of input sizes and alignments on Powe
On Fri, Oct 10, 2008 at 1:02 AM, Benjamin Herrenschmidt
<[EMAIL PROTECTED]> wrote:
> On Thu, 2008-10-09 at 23:06 -0500, Bill Gatliff wrote:
>> Benjamin Herrenschmidt wrote:
>> > On Wed, 2008-10-08 at 11:43 -0500, Bill Gatliff wrote:
>> >> This series proposes a "generic PWM" driver API.
>> >>
>> >>
On Thu, 2008-10-09 at 15:18 -0500, Jon Tollefson wrote:
> If there are multiple reserved memory blocks via lmb_reserve() that are
> contiguous addresses and on different NUMA nodes we are losing track of which
> address ranges to reserve in bootmem on which node. I discovered this
> when I recen
On Thu, 2008-10-09 at 23:06 -0500, Bill Gatliff wrote:
> Benjamin Herrenschmidt wrote:
> > On Wed, 2008-10-08 at 11:43 -0500, Bill Gatliff wrote:
> >> This series proposes a "generic PWM" driver API.
> >>
> >> This proposed API is motivated by the author's need to support
> >> pluggable devices; a
On Wed, 2008-09-24 at 16:53 -0500, Becky Bruce wrote:
> Most of the platforms were printing the size of the memory
> in their show_cpuinfo implementations. This moves that to
> the common show_cpuinfo, so that all 32-bit platforms will
> now print the size of memory. I also update the code
> to de
On Wed, 2008-09-24 at 08:39 +0200, Arnd Bergmann wrote:
> The ppc_select function was introduced in linux-2.3.48 in order to support
> code confusing the legacy select() calling convention with the standard one.
> Even 11 years ago, all correctly built code should not have done this and
> could hav
On Tue, 2008-09-09 at 15:04 +1000, David Gibson wrote:
> The typesafe version of the powerpc pagetable handling (with
> USE_STRICT_MM_TYPECHECKS defined) has bitrotted again. This patch
> makes a bunch of small fixes to get it building again.
>
> Signed-off-by: David Gibson <[EMAIL PROTECTED]>
D
On Thu, 2008-09-25 at 23:43 +0200, Sebastian Siewior wrote:
> * Milton Miller | 2008-09-23 20:46:18 [-0500]:
>
> >On Wed Sep 24 at about 06:38:57 EST in 2008, Sebastian Siewior wrote:
> >> My mylinux binary incl. bss is ~5 MiB without bss less than 4 MiB.
> >> Therefore I though that I could repla
Previosly the FDT header field boot_cpuid_phys wasn't actually used
on ppc32. Instead the physical boot cpuid was assumed to be 0 for
!CONFIG_SMP.
Signed-off-by: Kumar Gala <[EMAIL PROTECTED]>
---
arch/powerpc/include/asm/smp.h |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff -
Benjamin Herrenschmidt wrote:
> On Wed, 2008-10-08 at 11:43 -0500, Bill Gatliff wrote:
>> Signed-off-by: Bill Gatliff <[EMAIL PROTECTED]>
>> ---
>
> And you haven't provided -any- changeset comment. That isn't good :-)
Apparently not. :)
b.g.
--
Bill Gatliff
[EMAIL PROTECTED]
Benjamin Herrenschmidt wrote:
> On Wed, 2008-10-08 at 11:43 -0500, Bill Gatliff wrote:
>> This series proposes a "generic PWM" driver API.
>>
>> This proposed API is motivated by the author's need to support
>> pluggable devices; a secondary objective is to consolidate the
>> existing PWM implement
On Wed, 2008-10-01 at 23:20 +0200, Sebastian Andrzej Siewior wrote:
> +#define KEXEC_MODE_NOMMU 1
> +#define KEXEC_MODE_BOOKE 2
No need for runtime detection here, you cannot and likely never will be
able to build a kernel that does bot BookE and real mode...
> +
> +/* 1. Find the index of the e
Removed the Kconfig associated with 'NDFC NanD Flash Controller'.
We can't enable !CONFIG_PPC_MERGE so there is no way to enable
this. Additionally the code needs to get updated for arch/powerpc.
For the time being lets just remove the Kconfig option so we can
actually remove CONFIG_PPC_MERGE.
S
> > A virtual address will typically be needed to perform the flush; why
> > pass the bus address?
> Because it is a sync API. You want to make sure that a physical memory
> area is in sync with the caches, not the virtual address. This
> distinction can become important in the event where the p
On Oct 8, 2008, at 11:15 AM, Grant Likely wrote:
On Wed, Oct 8, 2008 at 6:38 AM, Kumar Gala
<[EMAIL PROTECTED]> wrote:
On Oct 7, 2008, at 4:13 PM, John Rigby wrote:
Uses mpc83xx_add_bridge in fsl_pci.c
Adds second register tuple to pci node register property
as done for 83xx device trees
> + for (i = 0; i < list_cells; cur_index++) {
> + const u32 *cells;
> + const phandle *phandle;
> +
> + phandle = list + i;
> + args = phandle + 1;
Rather than incrementing i, I would just use a running pointer "list"
and drop "i" totally. Not
On Wed, 2008-10-08 at 11:43 -0500, Bill Gatliff wrote:
> Signed-off-by: Bill Gatliff <[EMAIL PROTECTED]>
> ---
And you haven't provided -any- changeset comment. That isn't good :-)
Ben.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozl
On Wed, 2008-10-08 at 11:43 -0500, Bill Gatliff wrote:
> This series proposes a "generic PWM" driver API.
>
> This proposed API is motivated by the author's need to support
> pluggable devices; a secondary objective is to consolidate the
> existing PWM implementations behind an agreeable, consiste
Anton Vorontsov-2 wrote:
>
> This happens just before the PATA information is printed. I'm not
> libata expert; and from the brief look I don't see where libata
> clears any pending "unexpected" irqs. Just a guesswork,
> could you try this patch?
>
This patch did not appear to change anything.
After Becky's work we can almost have different DMA offsets
between on-chip devices and PCI. Almost because there's a
problem with the non-coherent DMA code that basically ignores
the programmed offset to use the global one for everything.
This fixes it.
Signed-off-by: Benjamin Herrenschmidt <[EMA
On Thu, 2008-10-09 at 20:51 -0500, Timur Tabi wrote:
> On Thu, Oct 9, 2008 at 8:22 PM, Kumar Gala <[EMAIL PROTECTED]> wrote:
>
> >> The problem with making all platforms default to N is that if you take
> >> the default values for all config options you end up with a config
> >> that won't build.
On Thu, 2008-10-09 at 20:22 -0500, Kumar Gala wrote:
> > Historically they have been the most important 32-bit platforms, along
> > with PReP.
> >
> > The problem with making all platforms default to N is that if you take
> > the default values for all config options you end up with a config
> > th
This adds support for ISA memory holes on the PCI, PCI-X and
PCI-E busses of the 4xx platforms. The patch includes changes
to the Bamboo and Canyonlands device-trees to add such a hole,
others can be updated separately.
The ISA memory hole is an additional outbound window configured
in the bridge
After Becky's work we can almost have different DMA offsets
between on-chip devices and PCI. Almost because there's a
problem with the non-coherent DMA code that basically ignores
the programmed offset to use the global one for everything.
This fixes it.
Signed-off-by: Benjamin Herrenschmidt <[EMA
This patch adds support for legacy_io and legacy_mem files in
bus class directories in sysfs for powerpc
Signed-off-by: Benjamin Herrenschmidt <[EMAIL PROTECTED]>
---
This is version 2, slightly different approach for getting at VGA
memory which works a lot better with bridges providing a separat
On Thursday 09 October 2008, Anton Vorontsov wrote:
>
> > I've incorporated the other changes, with one exception. I want
> > ppc4xx_gpio_get() to return 0 or 1 (rather than Anton's comment that any
> > non-zero value is ok), because when you use the new "export feature" in
> > sysfs, you see the
How 8349mITX's compact flash is wired? If it is wired using 8 bit data bus line,
without another patch, data transfer can't be done.
Looking at logs Sam Sparks provided (without irq):
ata1.00: failed to IDENTIFY (I/O error, err_mask=0x4)
it seems data transfer failed.
I have a 8 bit data trans
On Thu, Oct 9, 2008 at 8:22 PM, Kumar Gala <[EMAIL PROTECTED]> wrote:
>> The problem with making all platforms default to N is that if you take
>> the default values for all config options you end up with a config
>> that won't build. So we want at least one platform to default to Y,
>> and pmac
On Oct 9, 2008, at 7:43 PM, Paul Mackerras wrote:
Timur Tabi writes:
I'm waiting for someone to explain to me what's so special about CHRP
and PMAC that these two platforms should be enabled by default, when
all other PowerPC platforms are disabled by default.
Historically they have been th
Hi Paul / Ben,
Please do a:
git pull \
git://git.kernel.org/pub/scm/linux/kernel/git/jk/spufs.git merge
For a few spufs fixes for 2.6.28
Cheers,
Jeremy
---
diffstat:
arch/powerpc/platforms/cell/spufs/inode.c | 11 ++
1 file changed, 7 insertions(+), 4 deletions(-)
3 c
Timur Tabi writes:
> I'm waiting for someone to explain to me what's so special about CHRP
> and PMAC that these two platforms should be enabled by default, when
> all other PowerPC platforms are disabled by default.
Historically they have been the most important 32-bit platforms, along
with PReP
On Thu, Oct 09, 2008 at 09:42:38PM +0200, Wolfgang Grandegger wrote:
> Wolfgang Grandegger wrote:
> > Hello,
> >
> > I would like to ask for the status of the patch below and the related
> > ones. Any chance to get them in for 2.6.27.
>
> Already sometime ago I asked for the status of these patch
On Wed, 08 Oct 2008 16:56:54 -0400
"Steven A. Falco" <[EMAIL PROTECTED]> wrote:
> have begun writing a driver for the GPIOs of the PPC440EPx. I just
> noticed that the PIKA Warp .dts references a device "ibm,gpio-440ep",
> but so far I have not been able to find a driver for that device.
It's j
Sven Luther wrote:
> You just turn it on by default for 64bit and idsable it for 32bit :)
That hack might work for now, but it will break once we have 64-bit embedded
systems. Regardless, it doesn't address the core issue - there should be no
default platform for PowerPC.
--
Timur Tabi
Linux k
Matt Sealey wrote:
> I'm all for this if you manage it.
>
> The code and API looks good. We have some projects which involve PWM
> and having a nice clean standard API like the GPIO API was on the
> wishlist.. this will make it so much easier to do fan control,
> backlight control, drive motors, a
On Thu, Oct 09, 2008 at 04:14:36PM -0500, Timur Tabi wrote:
> On Thu, Oct 9, 2008 at 3:18 PM, Sven Luther <[EMAIL PROTECTED]> wrote:
> >> Not really true. Having the default be disabled for specific
> >> platforms can make a big difference in compile time.
> >
> > Notice that the defconfigs answer
On Thu, Oct 09, 2008 at 04:05:28PM -0400, Steven A. Falco wrote:
> This patch adds support for the GPIO functions of PPC40x and PPC44x
> SOCs.
>
> Signed-off-by: Steve Falco
> ---
>
> I looked more closely at the datasheet. Stefan is correct that the
> shadow registers are not needed for these
On Thu, Oct 9, 2008 at 3:18 PM, Sven Luther <[EMAIL PROTECTED]> wrote:
>> Not really true. Having the default be disabled for specific
>> platforms can make a big difference in compile time.
>
> Notice that the defconfigs answer also applies here :)
Not really. In order for me to create a new de
I'm all for this if you manage it.
The code and API looks good. We have some projects which involve PWM
and having a nice clean standard API like the GPIO API was on the
wishlist.. this will make it so much easier to do fan control,
backlight control, drive motors, audio output, and the billion
o
If there are multiple reserved memory blocks via lmb_reserve() that are
contiguous addresses and on different NUMA nodes we are losing track of which
address ranges to reserve in bootmem on which node. I discovered this
when I recently got to try 16GB huge pages on a system with more then 2 node
On Thu, Oct 09, 2008 at 12:23:06PM -0500, Timur Tabi wrote:
> On Thu, Oct 9, 2008 at 11:49 AM, Matt Sealey <[EMAIL PROTECTED]> wrote:
> > Because they are by far the historically most common configuration, and
> > still in production as the defacto standard PowerPC system configuration.
>
> Not re
This patch adds support for the GPIO functions of PPC40x and PPC44x
SOCs.
Signed-off-by: Steve Falco
---
I looked more closely at the datasheet. Stefan is correct that the
shadow registers are not needed for these processors, because they have
separate registers for input and output.
I've inco
Hi,
[ http://bugzilla.kernel.org/show_bug.cgi?id=11143 has it all]
targeting ppc(32), e.g. 405 (!fp), previously i got:
CC drivers/char/hw_random/rng-core.mod.o
LD [M] drivers/char/hw_random/rng-core.ko
/there/src/buildroot.git.ppc/build_powerpc_nofpu/staging_dir/usr/bin/powerpc-linux-u
Wolfgang Grandegger wrote:
> Hello,
>
> I would like to ask for the status of the patch below and the related
> ones. Any chance to get them in for 2.6.27.
Already sometime ago I asked for the status of these patches but I never
got an answer and they did make it into 2.6.27, like the related pat
On Thu, Oct 09, 2008 at 08:46:44PM +0200, Stefan Roese wrote:
[...]
> > +struct ppc4xx_gpio_chip {
> > + struct of_mm_gpio_chip mm_gc;
> > + spinlock_t lock;
> > + u32 shadow_or;
> > + u32 shadow_tcr;
> > + u32 shadow_osrl;
> > + u32 shadow_osrh;
> > + u32 shadow_tsrl;
> > + u32 sha
Steve,
On Thursday 09 October 2008, Steven A. Falco wrote:
> I've moved the config variable to platforms/44x, and added the #include
> of linux/types.h.
>
> Since I don't have any PPC405 boards, I am unable to test with that CPU.
> So, I am reluctant to add the config variable to platforms/40x. I
The version on the CD does not seem to see it at all:
[...]
U-Boot 1.3.4-rc1-00012-g1953d12 (Jul 28 2008 - 09:09:09) MPC83XX
[...]
Linux version 2.6.13.4 ([EMAIL PROTECTED]) (gcc version 3.4.3)
#1 Thu Oct 19 16:27:15 EDT 2006
PCI2 confirm: isa_io_base = 0xfc00
Configure PCI2 controller isa_i
I've moved the config variable to platforms/44x, and added the #include
of linux/types.h.
Since I don't have any PPC405 boards, I am unable to test with that CPU.
So, I am reluctant to add the config variable to platforms/40x. It
would be trivial to add, if someone else has a suitable setup and c
On Wed, 2008-10-08 at 08:22 +1100, Benjamin Herrenschmidt wrote:
> On Tue, 2008-10-07 at 14:05 -0700, Remi Machet wrote:
> > + /*
> > +* Mark the pages as Reserved: this memory is used by a DMA
> > engine,
> > +* it cannot be swapped.
> > +* Also mark each page as un-c
On Thu, Oct 09, 2008 at 01:09:18PM -0400, Steven A. Falco wrote:
> Please disregard the previous version, and consider this one instead.
> The only difference is making better use of to_ppc4xx_gpiochip(), which
> helps readability.
>
> Signed-off-by: Steve Falco
[...]
> #endif /* __ASM_POWERPC_P
On Thu, Oct 9, 2008 at 12:00 PM, Jeff Borlin <[EMAIL PROTECTED]> wrote:
>
> Can you point me to where that can be found?
It's on the CD that came with the board.
--
Timur Tabi
Linux kernel developer at Freescale
___
Linuxppc-dev mailing list
Linuxppc-d
On Thu, Oct 09, 2008 at 08:52:09AM -0700, Jeff Borlin wrote:
>
> I have taken over this effort to get Compact Flash working on the 8349mITX
> board and am running into these same issues. I can get uBoot to list the
> contents of a CF card,
U-Boot doesn't use interrupts.
> but am running into a
On Thu, Oct 9, 2008 at 11:49 AM, Matt Sealey <[EMAIL PROTECTED]> wrote:
> Because they are by far the historically most common configuration, and
> still in production as the defacto standard PowerPC system configuration.
Not really. PMAC systems are not being built any more. So that leaves CHRP
Please disregard the previous version, and consider this one instead.
The only difference is making better use of to_ppc4xx_gpiochip(), which
helps readability.
Signed-off-by: Steve Falco
diff --git a/arch/powerpc/include/asm/ppc4xx.h
b/arch/powerpc/include/asm/ppc4xx.h
index 033039a..589ff5c 1
Can you point me to where that can be found?
Timur Tabi-3 wrote:
>
> I've heard on-and-off that there are problems with the CF support on
> the 8349 ITX, but I've never had the chance to investigate it.
>
> Can you try using the latest BSP kernel and see if the problem is
> present there? S
Thanks again for the comments. I followed the structure of your
qe_lib/gpio.c; here is the result. At this point, I've tested input
and output, so it is looking pretty good for me.
I added __init to the ppc4xx_gpio_save_regs because it looks like it is
only needed when first adding the gpios.
S
Timur Tabi wrote:
On Thu, Oct 9, 2008 at 10:59 AM, Matt Sealey <[EMAIL PROTECTED]> wrote:
If you really want to build a single-cpu single-board kernel, disable CHRP
and PMAC for those board configs, but the default definitely should be to
enable them all within reason
The problem is that thi
Hi Paul,
Thank you for the review. I will implement the changes you suggested and
send the patches.
Regards,
Mohan.
Mohan Kumar M writes:
Support for relocatable kdump kernel
[snip]
@@ -1384,7 +1392,15 @@ _STATIC(__after_prom_start)
/* process relocations for the final address
Paul Mackerras wrote:
Hmmm. Is there any reason to continue to support non-relocatable
64-bit kernels being kdump kernels? In other words, for 64-bit,
couldn't we make CONFIG_CRASH_DUMP depend on CONFIG_RELOCATABLE?
We wanted to support legacy kdump feature on 64 bit kernels for some
time.
On Thu, Oct 9, 2008 at 10:52 AM, Jeff Borlin <[EMAIL PROTECTED]> wrote:
>
> I have taken over this effort to get Compact Flash working on the 8349mITX
> board and am running into these same issues. I can get uBoot to list the
> contents of a CF card, but am running into a couple problems through t
On Thu, Oct 9, 2008 at 10:59 AM, Matt Sealey <[EMAIL PROTECTED]> wrote:
> If you really want to build a single-cpu single-board kernel, disable CHRP
> and PMAC for those board configs, but the default definitely should be to
> enable them all within reason
The problem is that this is inconsistent
On Thu, Oct 09, 2008 at 11:10:25AM -0400, Steven A. Falco wrote:
> Anton - thanks very much for your comments. I learned a lot, and I've
> incorporated your suggestions into the driver, copy attached.
>
> Stefan - hope I didn't step on your toes, but I was not aware you were
> also working on thi
Timur Tabi wrote:
Benjamin Herrenschmidt wrote:
I'm happy with -all- platforms for a given CPU type defaulting to y.
I'm not sure I understand. The current Kconfigs defaults to Y for CHRP and PMAC
on *all* PowerPC systems, including those that are neither CHRP nor PMAC. Are
you saying that
I have taken over this effort to get Compact Flash working on the 8349mITX
board and am running into these same issues. I can get uBoot to list the
contents of a CF card, but am running into a couple problems through the
kernel. There appears to be an IRQ problem and a general communication
prob
Hi Stefan,
On Thu, Oct 09, 2008 at 04:53:34PM +0200, Stefan Roese wrote:
> This patch adds a 4xx gpio driver. Tested on a 405EP and a 440EPx
> platform.
>
> Signed-off-by: Stefan Roese <[EMAIL PROTECTED]>
> ---
>
> This driver probably needs some final polishing. E.g. some parts can
> be extrace
Paul Mackerras wrote:
Dominik Bozek writes:
Actually I made couple of other tests on that mpc8313. Most of them are
to ugly to publish them, but... My problem is that I have to boost the
gigabit interface on the mpc8313. I made simple substitution and
__copy_tofrom_user was used instead of memc
On Thursday 09 October 2008, Steven A. Falco wrote:
> Anton - thanks very much for your comments. I learned a lot, and I've
> incorporated your suggestions into the driver, copy attached.
>
> Stefan - hope I didn't step on your toes, but I was not aware you were
> also working on this.
Not at all
Anton - thanks very much for your comments. I learned a lot, and I've
incorporated your suggestions into the driver, copy attached.
Stefan - hope I didn't step on your toes, but I was not aware you were
also working on this. Anyway, it seemed like a good place to make my
first "significant" cont
This patch adds a 4xx gpio driver. Tested on a 405EP and a 440EPx
platform.
Signed-off-by: Stefan Roese <[EMAIL PROTECTED]>
---
This driver probably needs some final polishing. E.g. some parts can
be extraced from ppc4xx_gpio_dir_in()/ppc4xx_gpio_dir_out() and moved
into seperate functions to mak
On Wednesday 08 October 2008, Steven A. Falco wrote:
> I have begun writing a driver for the GPIOs of the PPC440EPx. I just
> noticed that the PIKA Warp .dts references a device "ibm,gpio-440ep",
> but so far I have not been able to find a driver for that device.
>
> So, here is what I have so far
Hi Steven,
On Wed, Oct 08, 2008 at 04:56:54PM -0400, Steven A. Falco wrote:
> I have begun writing a driver for the GPIOs of the PPC440EPx. I just
> noticed that the PIKA Warp .dts references a device "ibm,gpio-440ep",
> but so far I have not been able to find a driver for that device.
>
> So, h
Hello all,
On Thu, Oct 9, 2008 at 1:41 PM, Dominik Bozek <[EMAIL PROTECTED]> wrote:
> Paul Mackerras wrote:
>> Dominik Bozek writes:
>>> Actually I made couple of other tests on that mpc8313. Most of them are
>>> to ugly to publish them, but... My problem is that I have to boost the
>>> gigabit in
Paul Mackerras wrote:
> Dominik Bozek writes:
>
>
>> Actually I made couple of other tests on that mpc8313. Most of them are
>> to ugly to publish them, but... My problem is that I have to boost the
>> gigabit interface on the mpc8313. I made simple substitution and
>> __copy_tofrom_user was use
Dominik Bozek writes:
> Actually I made couple of other tests on that mpc8313. Most of them are
> to ugly to publish them, but... My problem is that I have to boost the
> gigabit interface on the mpc8313. I made simple substitution and
> __copy_tofrom_user was used instead of memcpy. I know, it's
Benjamin Herrenschmidt wrote:
> I'm happy with -all- platforms for a given CPU type defaulting to y.
I'm not sure I understand. The current Kconfigs defaults to Y for CHRP and PMAC
on *all* PowerPC systems, including those that are neither CHRP nor PMAC. Are
you saying that's a good thing?
--
Hi Ben,
Can you please pull my mpc52xx support tree?
Thanks,
g.
The following changes since commit 7c12d906f4ef690c65e60111375856640f63a545:
Benjamin Herrenschmidt (1):
powerpc: Fix sysfs pci mmap on 32-bit machines with 64-bit PCI
are available in the git repository at:
git://git.
On Fri, Sep 26, 2008 at 6:10 PM, Remi Machet <[EMAIL PROTECTED]> wrote:
> Hi Paul,
>
> This patch breaks my build with the following error:
>
> /u1/rmachet/projects/c2k/linux-powerpc-git $ make cuImage.c2k modules
> ARCH=powerpc V=1
> ...
> powerpc-linux-gnu-ld -m elf32ppc -Bstatic -o .tmp_vmli
79 matches
Mail list logo
