* How to create custom ramdisk
From: Neeraj Garg @ 2008-07-22 13:12 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 250 bytes --]
Hi,
I want to create a custom ramdisk (initrd which can be placed in
arch/ppc/boot/images). Can anybody guide me steps to built the same. My
host have RHEL-4.
--
-------------------------------------------------------------------
Neeraj Garg
[-- Attachment #2: Type: text/html, Size: 606 bytes --]
^ permalink raw reply
* Re: [PATCH] Make u64 long long on all architectures (was: the printk problem)
From: Benjamin Herrenschmidt @ 2008-07-22 11:36 UTC (permalink / raw)
To: michael
Cc: linux-arch, linux-ia64, Matthew Wilcox, linux-kernel,
linuxppc-dev, Peter Anvin, Andrew Morton, Linus Torvalds,
David S. Miller
In-Reply-To: <1216722995.8357.4.camel@localhost>
On Tue, 2008-07-22 at 20:36 +1000, Michael Ellerman wrote:
> concordia powerpc(master) $ find arch/powerpc/ ! -name '*32.*' | xargs
> grep "%l" | grep -v "%ll" | wc -l
> 635
>
>
> Someone's gonna get a lot of git points for fixing all those. Might
> keep
> the speeling fix crowd busy for a
But a bunch of those might actually be real longs, not u64's ...
Easier to do the change and build something like ppc6xx_defconfig to get
a better approximation.
Ben.
^ permalink raw reply
* [PATCH 1/3] ASoC: Make OpenFirmware helper include file conditional
From: Mark Brown @ 2008-07-22 11:53 UTC (permalink / raw)
To: Grant Likely
Cc: alsa-project.org, linuxppc-dev, Mark Brown, timur, liam.girdwood
In-Reply-To: <20080722115205.GA12555@sirena.org.uk>
The OpenFirmware API headers don't build on all platforms so ensure
that they are not included unless they are being used.
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
---
include/sound/soc-of-simple.h | 4 ++++
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/include/sound/soc-of-simple.h b/include/sound/soc-of-simple.h
index 696fc51..a064e19 100644
--- a/include/sound/soc-of-simple.h
+++ b/include/sound/soc-of-simple.h
@@ -7,6 +7,8 @@
#ifndef _INCLUDE_SOC_OF_H_
#define _INCLUDE_SOC_OF_H_
+#if defined(CONFIG_SND_SOC_OF_SIMPLE) || defined(CONFIG_SND_SOC_OF_SIMPLE_MODULE)
+
#include <linux/of.h>
#include <sound/soc.h>
@@ -18,4 +20,6 @@ int of_snd_soc_register_platform(struct snd_soc_platform *platform,
struct device_node *node,
struct snd_soc_dai *cpu_dai);
+#endif
+
#endif /* _INCLUDE_SOC_OF_H_ */
--
1.5.6.3
^ permalink raw reply related
* [PATCH 2/3] ASoC: Export DAI and codec for TLV320AIC26
From: Mark Brown @ 2008-07-22 11:53 UTC (permalink / raw)
To: Grant Likely
Cc: alsa-project.org, linuxppc-dev, Mark Brown, timur, liam.girdwood
In-Reply-To: <1216727589-19544-1-git-send-email-broonie@opensource.wolfsonmicro.com>
This fixes sparse warnings and allows non-OpenFirmware systems to attempt
to bind to the device.
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
---
sound/soc/codecs/tlv320aic26.c | 1 +
sound/soc/codecs/tlv320aic26.h | 3 +++
2 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/sound/soc/codecs/tlv320aic26.c b/sound/soc/codecs/tlv320aic26.c
index 4621fda..73b7027 100644
--- a/sound/soc/codecs/tlv320aic26.c
+++ b/sound/soc/codecs/tlv320aic26.c
@@ -383,6 +383,7 @@ struct snd_soc_codec_device aic26_soc_codec_dev = {
.probe = aic26_probe,
.remove = aic26_remove,
};
+EXPORT_SYMBOL_GPL(aic26_soc_codec_dev);
/* ---------------------------------------------------------------------
* SPI device portion of driver: sysfs files for debugging
diff --git a/sound/soc/codecs/tlv320aic26.h b/sound/soc/codecs/tlv320aic26.h
index 62b1f22..786ba16 100644
--- a/sound/soc/codecs/tlv320aic26.h
+++ b/sound/soc/codecs/tlv320aic26.h
@@ -90,4 +90,7 @@ enum aic26_wlen {
AIC26_WLEN_32 = 3 << 10,
};
+extern struct snd_soc_dai aic26_dai;
+extern struct snd_soc_codec_device aic26_soc_codec_dev;
+
#endif /* _TLV320AIC16_H_ */
--
1.5.6.3
^ permalink raw reply related
* [PATCH 3/3] ASoC: Staticise keyclick dev_attr in tlv320aic26
From: Mark Brown @ 2008-07-22 11:53 UTC (permalink / raw)
To: Grant Likely
Cc: alsa-project.org, linuxppc-dev, Mark Brown, timur, liam.girdwood
In-Reply-To: <1216727589-19544-2-git-send-email-broonie@opensource.wolfsonmicro.com>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
---
sound/soc/codecs/tlv320aic26.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/sound/soc/codecs/tlv320aic26.c b/sound/soc/codecs/tlv320aic26.c
index 73b7027..bed8a9e 100644
--- a/sound/soc/codecs/tlv320aic26.c
+++ b/sound/soc/codecs/tlv320aic26.c
@@ -418,7 +418,7 @@ static ssize_t aic26_keyclick_set(struct device *dev,
return count;
}
-DEVICE_ATTR(keyclick, 0644, aic26_keyclick_show, aic26_keyclick_set);
+static DEVICE_ATTR(keyclick, 0644, aic26_keyclick_show, aic26_keyclick_set);
/* ---------------------------------------------------------------------
* SPI device portion of driver: probe and release routines and SPI
--
1.5.6.3
^ permalink raw reply related
* Re: [PATCH v3 0/3] ALSA SoC: MPC5200 audio driver
From: Mark Brown @ 2008-07-22 11:52 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-dev, alsa-devel, timur, liam.girdwood
In-Reply-To: <fa686aa40807212358p17c824ia1d6516a87a7aac1@mail.gmail.com>
On Tue, Jul 22, 2008 at 12:58:09AM -0600, Grant Likely wrote:
> Here is the latest series for adding MPC5200 I2S and TI AIC26 codec
> support to ALSA SoC. I believe all the comments are addressed and I
> hope that this series is now ready to be merged. I would really like
> to see these ones land in 2.6.27.
I added the changes in the following fairly trivial patch series to
these to allow tlv320aic26 build cleanly on my ARM platforms.
^ permalink raw reply
* Re: [PATCH] Make u64 long long on all architectures (was: the printk problem)
From: Benjamin Herrenschmidt @ 2008-07-22 11:35 UTC (permalink / raw)
To: Andrew Morton
Cc: linux-arch, linux-ia64, Matthew Wilcox, linux-kernel,
linuxppc-dev, Peter Anvin, Linus Torvalds, David S. Miller
In-Reply-To: <20080722030506.206a2cc2.akpm@linux-foundation.org>
>
> This is (IMO) a desirable change and will prevent a heck of a lot of
> goofing around, and will permit a lot of prior goofing around to
> be removed.
>
> But I bet there are lots of instalces of printk("%l", some_u64) down in
> arch code where the type of u64 _is_ known which will now spew warnings.
Well, I'm about to call a big "warning fixing day" on the powerpc list,
I saw a few today when building a couple of configs and that hurts my
eyes so we may as well fold that in :-)
Cheers,
Ben.
^ permalink raw reply
* Re: [PATCH] serial: fix struct uart_info change fallout
From: Alan Cox @ 2008-07-22 10:44 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: ppc-dev, linux-next, Linus Torvalds, LKML
In-Reply-To: <20080722130152.f115224d.sfr@canb.auug.org.au>
> What is your problem with the linux-next tree. The problem was
> discovered and reported when I first merged the ttydev tree into
> linux-next on July 1. The fixes were in linux-next on July 2.
Yes .. and ? The clashes kept happening despite that when I was doing the
merges (and going on holiday for a week and trying to sort it out with
limited time and internet access)
Sorry I don't follow your line of discussion at all here ?
> > just going to break the tree again and mean I have to run another set of
> > tests and regressions.
>
> Please give what until tomorrow?
it - the situation. The patches have all gone to Linus.
Alan
^ permalink raw reply
* Re: [PATCH] Make u64 long long on all architectures (was: the printk problem)
From: Andrew Morton @ 2008-07-22 10:53 UTC (permalink / raw)
To: michael
Cc: linux-arch, linux-ia64, Matthew Wilcox, linux-kernel,
linuxppc-dev, Peter Anvin, Linus Torvalds, David S. Miller
In-Reply-To: <1216722995.8357.4.camel@localhost>
On Tue, 22 Jul 2008 20:36:35 +1000 Michael Ellerman <michael@ellerman.id.au> wrote:
> On Tue, 2008-07-22 at 03:05 -0700, Andrew Morton wrote:
> > On Fri, 4 Jul 2008 20:03:51 -0600 Matthew Wilcox <matthew@wil.cx> wrote:
> >
> > > [PATCH] Make u64 long long on all architectures
> > >
> > > It is currently awkward to print a u64 type. Some architectures use
> > > unsigned long while others use unsigned long long. Since unsigned long
> > > long is 64-bit for all existing Linux architectures, change those that
> > > use long to use long long. Note that this applies only within the
> > > kernel. If u64 is being used in a C++ method definition, the symbol
> > > mangling would change.
> > >
> > > Signed-off-by: Matthew Wilcox <willy@linux.intel.com>
> > >
> > > diff --git a/include/asm-generic/int-l64.h b/include/asm-generic/int-l64.h
> > > index 2af9b75..32f07bd 100644
> > > --- a/include/asm-generic/int-l64.h
> > > +++ b/include/asm-generic/int-l64.h
> > > @@ -23,8 +23,13 @@ typedef unsigned short __u16;
> > > typedef __signed__ int __s32;
> > > typedef unsigned int __u32;
> > >
> > > +#ifdef __KERNEL__
> > > +typedef __signed__ long long __s64;
> > > +typedef unsigned long long __u64;
> > > +#else
> > > typedef __signed__ long __s64;
> > > typedef unsigned long __u64;
> > > +#endif
> > >
> > > #endif /* __ASSEMBLY__ */
> >
> > This is (IMO) a desirable change and will prevent a heck of a lot of
> > goofing around, and will permit a lot of prior goofing around to
> > be removed.
> >
> > But I bet there are lots of instalces of printk("%l", some_u64) down in
> > arch code where the type of u64 _is_ known which will now spew warnings.
> >
> > Oh well.
>
> As a rough estimate:
>
> concordia powerpc(master) $ find arch/powerpc/ ! -name '*32.*' | xargs grep "%l" | grep -v "%ll" | wc -l
> 635
lolz. If yesterdays-linux-next on todays-mainline wasn't such a
hilarious trainwreck I'd test your grepping. I guess that could be
done on mainline too.
> Someone's gonna get a lot of git points for fixing all those. Might keep
> the speeling fix crowd busy for a while.
I'm not sure I have the energy for this.
But we really should do it.
^ permalink raw reply
* Re: Calling the kernel from a mini-bootloader
From: Guillaume Dargaud @ 2008-07-22 10:49 UTC (permalink / raw)
To: ppcdev
In-Reply-To: <007a845ba2b60b02a256b58632490b27@bga.com>
Thank you Milton for the detailed explanation. It'll take me quite a while
to digest it.
As a follow up to my previous messages, I now have a working kernel and a
working bootloader... but not when they are both together.
Case in point:
- load zImage.elf to DRAM 0x400000 with JTAG debugger. Run it. It runs fine.
- Load Bootloader.elf to BRAM 0xFFFF0000 with JTAG debugger. Run it. It runs
fine (but it doesn't do much yet).
- Now load both of the previous ones, and have the bootloader perform a jump
to kernel:
typedef void tFunc(void);
((tFunc *)0x400000)();
The kernel seems to start:
loaded at: 00400000 004EA19C
board data at: 004E8120 004E819C
relocated to: 0040405C 004040D8
zimage at: 00404E48 004E7A7E
avail ram: 004EB000 08000000
Linux/PPC load: console=ttyUL0,115200 rw root=/dev/nfs ip=bootp
Uncompressing Linux...done.
Now booting the kernel
But then it hangs for exactly 3 minutes, nothing on the serial port, before
the bootloader restarts.
Why should the behavior be different whether it's started from the debugger
or from my bootloader ?
--
Guillaume Dargaud
http://www.gdargaud.net/
^ permalink raw reply
* Re: [PATCH] Make u64 long long on all architectures (was: the printk problem)
From: Michael Ellerman @ 2008-07-22 10:36 UTC (permalink / raw)
To: Andrew Morton
Cc: linux-arch, linux-ia64, Matthew Wilcox, linux-kernel,
linuxppc-dev, Peter Anvin, Linus Torvalds, David S. Miller
In-Reply-To: <20080722030506.206a2cc2.akpm@linux-foundation.org>
[-- Attachment #1: Type: text/plain, Size: 2086 bytes --]
On Tue, 2008-07-22 at 03:05 -0700, Andrew Morton wrote:
> On Fri, 4 Jul 2008 20:03:51 -0600 Matthew Wilcox <matthew@wil.cx> wrote:
>
> > [PATCH] Make u64 long long on all architectures
> >
> > It is currently awkward to print a u64 type. Some architectures use
> > unsigned long while others use unsigned long long. Since unsigned long
> > long is 64-bit for all existing Linux architectures, change those that
> > use long to use long long. Note that this applies only within the
> > kernel. If u64 is being used in a C++ method definition, the symbol
> > mangling would change.
> >
> > Signed-off-by: Matthew Wilcox <willy@linux.intel.com>
> >
> > diff --git a/include/asm-generic/int-l64.h b/include/asm-generic/int-l64.h
> > index 2af9b75..32f07bd 100644
> > --- a/include/asm-generic/int-l64.h
> > +++ b/include/asm-generic/int-l64.h
> > @@ -23,8 +23,13 @@ typedef unsigned short __u16;
> > typedef __signed__ int __s32;
> > typedef unsigned int __u32;
> >
> > +#ifdef __KERNEL__
> > +typedef __signed__ long long __s64;
> > +typedef unsigned long long __u64;
> > +#else
> > typedef __signed__ long __s64;
> > typedef unsigned long __u64;
> > +#endif
> >
> > #endif /* __ASSEMBLY__ */
>
> This is (IMO) a desirable change and will prevent a heck of a lot of
> goofing around, and will permit a lot of prior goofing around to
> be removed.
>
> But I bet there are lots of instalces of printk("%l", some_u64) down in
> arch code where the type of u64 _is_ known which will now spew warnings.
>
> Oh well.
As a rough estimate:
concordia powerpc(master) $ find arch/powerpc/ ! -name '*32.*' | xargs grep "%l" | grep -v "%ll" | wc -l
635
Someone's gonna get a lot of git points for fixing all those. Might keep
the speeling fix crowd busy for a while.
cheers
--
Michael Ellerman
OzLabs, IBM Australia Development Lab
wwweb: http://michael.ellerman.id.au
phone: +61 2 6212 1183 (tie line 70 21183)
We do not inherit the earth from our ancestors,
we borrow it from our children. - S.M.A.R.T Person
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH v3 3/3] ALSA SoC: Add Texas Instruments TLV320AIC26 codec driver
From: Mark Brown @ 2008-07-22 10:34 UTC (permalink / raw)
To: Grant Likely; +Cc: timur, linuxppc-dev, alsa-devel, liam.girdwood
In-Reply-To: <20080722065403.7306.53226.stgit@trillian.secretlab.ca>
On Tue, Jul 22, 2008 at 12:54:03AM -0600, Grant Likely wrote:
> Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
with the same comments about outstanding issues as applied to the CPU
side.
> +static int aic26_hw_params(struct snd_pcm_substream *substream,
> + struct snd_pcm_hw_params *params)
> +{
> + switch (params_rate(params)) {
> + case 8000: fsref = 48000; divisor = AIC26_DIV_6; break;
> + /* Configure PLL */
> + pval = 1;
> + jval = (fsref == 44100) ? 7 : 8;
> + dval = (fsref == 44100) ? 5264 : 1920;
Without having looked at the chip datasheet these parameters probably
all need to depend on the input clock rate and the PLL configuration
should be done in a set_pll() rather than here.
> +#if defined(CONFIG_SND_SOC_OF_SIMPLE)
> + /* Tell the of_soc helper about this codec */
> + of_snd_soc_register_codec(&aic26_soc_codec_dev, aic26, &aic26_dai,
> + spi->dev.archdata.of_node);
> +#endif
This won't work if the OF_SIMPLE stuff is a module. There's also a
checkpatch issue which I'll fix up.
^ permalink raw reply
* Re: [PATCH v3 2/3] ALSA SoC: Add mpc5200-psc I2S driver
From: Mark Brown @ 2008-07-22 10:09 UTC (permalink / raw)
To: Grant Likely; +Cc: timur, linuxppc-dev, alsa-devel, liam.girdwood
In-Reply-To: <20080722065358.7306.9412.stgit@trillian.secretlab.ca>
On Tue, Jul 22, 2008 at 12:53:58AM -0600, Grant Likely wrote:
> Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
There's a few issues that were raised on the previous review cycle that
still need to be addressed but they should be fixable in incremental
patches (and easier to review that way):
> +static int psc_i2s_trigger(struct snd_pcm_substream *substream, int cmd)
> + spin_lock_irqsave(&psc_i2s->lock, flags);
> + /* first make sure it is low */
> + while ((in_8(®s->ipcr_acr.ipcr) & 0x80) != 0)
> + ;
> + /* then wait for the transition to high */
> + while ((in_8(®s->ipcr_acr.ipcr) & 0x80) == 0)
> + ;
These loops should really have some sort of time limit on them,
otherwise they'll lock hard if the expected events don't happen. Given
that in slave mode they're synchronising with an externally generated
clock this is something that might happen in practice and should produce
better diagnostics.
> + default:
> + dev_dbg(psc_i2s->dev, "invalid command\n");
> + return -EINVAL;
> + }
I'd really expect to see the other possible triggers handled, even if
the appropriate action is to silently ignore them, rather than having
them generate an error message.
^ permalink raw reply
* Re: [PATCH] Make u64 long long on all architectures (was: the printk problem)
From: Andrew Morton @ 2008-07-22 10:05 UTC (permalink / raw)
To: Matthew Wilcox
Cc: linux-arch, linux-ia64, linux-kernel, linuxppc-dev, Peter Anvin,
Linus Torvalds, David S. Miller
In-Reply-To: <20080705020350.GN14894@parisc-linux.org>
On Fri, 4 Jul 2008 20:03:51 -0600 Matthew Wilcox <matthew@wil.cx> wrote:
> [PATCH] Make u64 long long on all architectures
>
> It is currently awkward to print a u64 type. Some architectures use
> unsigned long while others use unsigned long long. Since unsigned long
> long is 64-bit for all existing Linux architectures, change those that
> use long to use long long. Note that this applies only within the
> kernel. If u64 is being used in a C++ method definition, the symbol
> mangling would change.
>
> Signed-off-by: Matthew Wilcox <willy@linux.intel.com>
>
> diff --git a/include/asm-generic/int-l64.h b/include/asm-generic/int-l64.h
> index 2af9b75..32f07bd 100644
> --- a/include/asm-generic/int-l64.h
> +++ b/include/asm-generic/int-l64.h
> @@ -23,8 +23,13 @@ typedef unsigned short __u16;
> typedef __signed__ int __s32;
> typedef unsigned int __u32;
>
> +#ifdef __KERNEL__
> +typedef __signed__ long long __s64;
> +typedef unsigned long long __u64;
> +#else
> typedef __signed__ long __s64;
> typedef unsigned long __u64;
> +#endif
>
> #endif /* __ASSEMBLY__ */
This is (IMO) a desirable change and will prevent a heck of a lot of
goofing around, and will permit a lot of prior goofing around to
be removed.
But I bet there are lots of instalces of printk("%l", some_u64) down in
arch code where the type of u64 _is_ known which will now spew warnings.
Oh well.
^ permalink raw reply
* Re: [Cbe-oss-dev] [patch 7/9] azfs: initial submit of azfs, a non-buffered filesystem
From: Christoph Hellwig @ 2008-07-22 9:49 UTC (permalink / raw)
To: arnd; +Cc: cbe-oss-dev, linuxppc-dev
In-Reply-To: <20080715195739.820365109@arndb.de>
On Tue, Jul 15, 2008 at 09:51:46PM +0200, arnd@arndb.de wrote:
> From: Maxim Shchetynin <maxim@linux.vnet.ibm.com>
>
> AZFS is a file system which keeps all files on memory mapped random
> access storage. It was designed to work on the axonram device driver
> for IBM QS2x blade servers, but can operate on any block device
> that exports a direct_access method.
I don't thinks it's quite ready yet. I've had another look through the
code and here's some issues I came up with:
- first thing is that it's not sparse clean, which is a bit of a red
flag. The __iomem and __user annotations are there for a reason.
- then even with annotations we still have the issue of
copy_{from,to}_user into mmio regions. According to benh that's
still an open issue, but it at least needs very good explanations in
comments.
- the aio_read and aio_write methods don't handle actually vectored
writes. They need to iterate over all iovecs. Or just implement
plain read/write given that it's not actually asynchronous.
- the persistent superblock hack needs to go away. Just clean up
everything in ->put_super. If we want a fully persistant fs
we should just be using ext2 + xip
- azfs_open looks very fishy. there's never a need to do seeks
inside open. if O_APPEND is set the VFS makes sure the read and
write methods get the right ppos pointer passed.
And truncation is done by the VFS for O_TRUNC opens through
->setattr
- azfs_znode should not have a size field of it's own, but the
filesystem should only use the inode one
- the lists and inode_init_once should be called from the slab
constructor as in other filesystems
- I don't think there is any point of having a slab cache
for the azfs_block structures
- disk->driverfs_dev is not writeable to the filesystem, but for
driver use. The information azfs stores in there is not used
anyway, so it could easily be removed.
- lots of duplicated field in azfs_super where the superblock
ones should be used:
media_size -> sb->s_maxbytes
sector_size -> not needed at all
blkdev -> sb->s_bdev
root -> sb->s_root
^ permalink raw reply
* Re: how to allocate 9MB of memory in kernel ?
From: Marco Stornelli @ 2008-07-22 9:47 UTC (permalink / raw)
To: Misbah khan; +Cc: linuxppc-embedded
In-Reply-To: <200807221131.32556.arnd@arndb.de>
> On Tuesday 22 July 2008, Misbah khan wrote:
>> I am getting kernel panic while trying these as suggested by you ,the
>> following points will elaborate my concern :-
>> i am allocating memory using vmalloc and remaping to the SDRAM area as :-
>>
>> buf_area = vmalloc(sizeof(circularbuffer_S));
>> if(!buf_area)
>> {
>> printk(KERN_ALERT"vmalloc failed \n");
>> return -1;
>> }
>>
>> buf_area = (circularbuffer_S *)ioremap(7700000,900000);
>> if(!buf_area)
>> {
>> printk(KERN_ALERT"ioremap failed \n");
>> return -1;
>> }
Misbah I suggest you, before to write in a Linux mailing list, to read
Understanding the Linux kernel, Linux device drivers, Understanding the
Linux virtual memory manager and so on, to study them very well, to
think well about your problem and then ask for help in a mailing list.
Regards,
--
Marco Stornelli
Embedded Software Engineer
CoRiTeL - Consorzio di Ricerca sulle Telecomunicazioni
http://www.coritel.it
marco.stornelli@coritel.it
+39 06 72582838
^ permalink raw reply
* Re: how to allocate 9MB of memory in kernel ?
From: Arnd Bergmann @ 2008-07-22 9:31 UTC (permalink / raw)
To: linuxppc-embedded; +Cc: Misbah khan
In-Reply-To: <18582612.post@talk.nabble.com>
On Tuesday 22 July 2008, Misbah khan wrote:
> I am getting kernel panic while trying these as suggested by you ,the
> following points will elaborate my concern :-
Please post the entire driver, when you only post fragments that
don't compile, we can't really help you.
> i am allocating memory using vmalloc and remaping to the SDRAM area as :-
>=20
> buf_area =3D vmalloc(sizeof(circularbuffer_S));
> =A0=A0=A0=A0=A0=A0=A0=A0if(!buf_area)
> =A0=A0=A0=A0=A0=A0=A0=A0{
> =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0printk(KERN_ALERT"vmalloc=
failed \n");
> =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0return -1;
> =A0=A0=A0=A0=A0=A0=A0=A0}
>=20
> =A0=A0=A0=A0=A0=A0=A0=A0buf_area =3D (circularbuffer_S *)ioremap(7700000,=
900000);
> =A0=A0=A0=A0=A0=A0=A0=A0if(!buf_area)
> =A0=A0=A0=A0=A0=A0=A0=A0{
> =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0printk(KERN_ALERT"ioremap=
failed \n");
> =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0return -1;
> =A0=A0=A0=A0=A0=A0=A0=A0}
You really need to decide whether you want to allocate memory or
want to remap an I/O range. ioremap is *only* for I/O ranges
on SoC or similar devices, and when you have that, you don't allocate
memory. Besides, the addresses you pass are really strange,
e.g. 900,000 bytes are not 9MB. Normally, you would get the
I/O address from the device tree, using of_iomap(), and then
use of_translate_address/remap_pfn_range to map it to user
space.
Arnd <><
^ permalink raw reply
* Re: [PATCH v3 1/3] ALSA SoC: Add OpenFirmware helper for matching bus and codec drivers
From: Mark Brown @ 2008-07-22 9:27 UTC (permalink / raw)
To: Grant Likely; +Cc: timur, linuxppc-dev, alsa-devel, liam.girdwood
In-Reply-To: <20080722065352.7306.60679.stgit@trillian.secretlab.ca>
On Tue, Jul 22, 2008 at 12:53:53AM -0600, Grant Likely wrote:
> This is most likely temporary glue code to work around limitations in
> the ASoC v1 framework. When v2 is merged, most of this driver will
> need to be reworked.
Whatever is needed in v2 can probably have the client registration
functions integrated into the core registration functions.
> Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
^ permalink raw reply
* Re: [alsa-devel] [PATCH v3 0/3] ALSA SoC: MPC5200 audio driver
From: Mark Brown @ 2008-07-22 9:26 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-dev, alsa-devel, timur, liam.girdwood
In-Reply-To: <fa686aa40807212358p17c824ia1d6516a87a7aac1@mail.gmail.com>
On Tue, Jul 22, 2008 at 12:58:09AM -0600, Grant Likely wrote:
> Here is the latest series for adding MPC5200 I2S and TI AIC26 codec
> support to ALSA SoC. I believe all the comments are addressed and I
> hope that this series is now ready to be merged. I would really like
> to see these ones land in 2.6.27.
That might be a bit of a push given how far into the merge window we
are and Takashi's holiday this week, though as they are new drivers
things could be a bit more relaxed.
Takashi, I'll queue these (and other ASoC patches) for submission in
bulk once you return.
^ permalink raw reply
* Re: [PATCH 1/4][V2] powerpc : add support for linux, usable-memory properties for drconf memory
From: Benjamin Herrenschmidt @ 2008-07-22 9:12 UTC (permalink / raw)
To: Chandru; +Cc: linuxppc-dev, Michael Neuling, Stephen Rothwell
In-Reply-To: <200807221431.49268.chandru@in.ibm.com>
On Tue, 2008-07-22 at 14:31 +0530, Chandru wrote:
> Scan for linux,usable-memory properties in case of dynamic reconfiguration
> memory . Support for kexec/kdump.
>
> Signed-off-by: Chandru Siddalingappa <chandru@in.ibm.com>
> ---
>
> Patch applies on powerpc tree. Patch was reviewed by Nathan Fontenot, Stephen
> Rothwell, Michael Neuling.
Any reason why there's no acks there then ? I don't have an objection to
the patch per-se and I was planning to review it this week too, but if
you had positive reviews and you addressed whatever comments the people
had, there should be Acked-by: lines in your patch (ie, don't invent
them, only put them there if you actually got that from the reviewers).
Cheers,
Ben.
> arch/powerpc/kernel/prom.c | 40 +++++++++++++++++++++++------
> arch/powerpc/mm/numa.c | 48 ++++++++++++++++++++++++-----------
> 2 files changed, 65 insertions(+), 23 deletions(-)
>
> diff -Naurp powerpc-orig/arch/powerpc/kernel/prom.c
> powerpc/arch/powerpc/kernel/prom.c
> --- powerpc-orig/arch/powerpc/kernel/prom.c 2008-07-22 14:11:53.000000000
> +0530
> +++ powerpc/arch/powerpc/kernel/prom.c 2008-07-22 14:12:17.000000000 +0530
> @@ -888,9 +888,10 @@ static u64 __init dt_mem_next_cell(int s
> */
> static int __init early_init_dt_scan_drconf_memory(unsigned long node)
> {
> - cell_t *dm, *ls;
> - unsigned long l, n, flags;
> + cell_t *dm, *ls, *usm;
> + unsigned long l, n, flags, ranges;
> u64 base, size, lmb_size;
> + char buf[32];
>
> ls = (cell_t *)of_get_flat_dt_prop(node, "ibm,lmb-size", &l);
> if (ls == NULL || l < dt_root_size_cells * sizeof(cell_t))
> @@ -914,14 +915,37 @@ static int __init early_init_dt_scan_drc
> or if the block is not assigned to this partition (0x8) */
> if ((flags & 0x80) || !(flags & 0x8))
> continue;
> - size = lmb_size;
> - if (iommu_is_off) {
> + if (iommu_is_off)
> if (base >= 0x80000000ul)
> continue;
> - if ((base + size) > 0x80000000ul)
> - size = 0x80000000ul - base;
> - }
> - lmb_add(base, size);
> + size = lmb_size;
> +
> + /*
> + * Append 'n' to 'linux,usable-memory' to get special
> + * properties passed in by tools like kexec-tools. Relevant
> + * only if this is a kexec/kdump kernel.
> + */
> + sprintf(buf, "linux,usable-memory%d", (int)n);
> + usm = of_get_flat_dt_prop(node, buf, &l);
> + ranges = 1;
> + if (usm != NULL)
> + ranges = (l >> 2)/(dt_root_addr_cells
> + + dt_root_size_cells);
> + do {
> + if (usm != NULL) {
> + base = dt_mem_next_cell(dt_root_addr_cells,
> + &usm);
> + size = dt_mem_next_cell(dt_root_size_cells,
> + &usm);
> + if (size == 0)
> + break;
> + }
> + if (iommu_is_off)
> + if ((base + size) > 0x80000000ul)
> + size = 0x80000000ul - base;
> +
> + lmb_add(base, size);
> + } while (--ranges);
> }
> lmb_dump_all();
> return 0;
> diff -Naurp powerpc-orig/arch/powerpc/mm/numa.c powerpc/arch/powerpc/mm/numa.c
> --- powerpc-orig/arch/powerpc/mm/numa.c 2008-07-22 14:11:53.000000000 +0530
> +++ powerpc/arch/powerpc/mm/numa.c 2008-07-22 14:12:17.000000000 +0530
> @@ -493,11 +493,13 @@ static unsigned long __init numa_enforce
> */
> static void __init parse_drconf_memory(struct device_node *memory)
> {
> - const u32 *dm;
> - unsigned int n, rc;
> - unsigned long lmb_size, size;
> + const u32 *dm, *usm;
> + unsigned int n, rc, len, ranges;
> + unsigned long lmb_size, size, sz;
> int nid;
> struct assoc_arrays aa;
> + char buf[32];
> + u64 base;
>
> n = of_get_drconf_memory(memory, &dm);
> if (!n)
> @@ -524,19 +526,35 @@ static void __init parse_drconf_memory(s
>
> nid = of_drconf_to_nid_single(&drmem, &aa);
>
> - fake_numa_create_new_node(
> - ((drmem.base_addr + lmb_size) >> PAGE_SHIFT),
> - &nid);
> -
> - node_set_online(nid);
> -
> - size = numa_enforce_memory_limit(drmem.base_addr, lmb_size);
> - if (!size)
> - continue;
> + /*
> + * Append 'n' to 'linux,usable-memory' to get special
> + * properties passed in by tools like kexec-tools. Relevant
> + * only if this is a kexec/kdump kernel.
> + */
> + sprintf(buf, "linux,usable-memory%d", (int)n);
> + usm = of_get_property(memory, buf, &len);
> + ranges = 1;
> + if (usm != NULL)
> + ranges = (len >> 2) /
> + (n_mem_addr_cells + n_mem_size_cells);
> +
> + base = drmem.base_addr;
> + size = lmb_size;
> + do {
> + if (usm != NULL) {
> + base = read_n_cells(n_mem_addr_cells, &usm);
> + size = read_n_cells(n_mem_size_cells, &usm);
> + }
>
> - add_active_range(nid, drmem.base_addr >> PAGE_SHIFT,
> - (drmem.base_addr >> PAGE_SHIFT)
> - + (size >> PAGE_SHIFT));
> + fake_numa_create_new_node(((base + size) >> PAGE_SHIFT),
> + &nid);
> + node_set_online(nid);
> + sz = numa_enforce_memory_limit(base, size);
> + if (sz)
> + add_active_range(nid, base >> PAGE_SHIFT,
> + (base >> PAGE_SHIFT)
> + + (sz >> PAGE_SHIFT));
> + } while (--ranges);
> }
> }
^ permalink raw reply
* Re: [PATCH 1/4][V2] powerpc : add support for linux, usable-memory properties for drconf memory
From: Paul Mackerras @ 2008-07-22 9:16 UTC (permalink / raw)
To: Chandru; +Cc: Michael Neuling, Stephen Rothwell, linuxppc-dev
In-Reply-To: <200807221431.49268.chandru@in.ibm.com>
Chandru writes:
> Scan for linux,usable-memory properties in case of dynamic reconfiguration
> memory . Support for kexec/kdump.
>
> Signed-off-by: Chandru Siddalingappa <chandru@in.ibm.com>
Could we *please* have a more comprehensive patch description that
that? Something which will help people coming along in two (or five
or ten) years time to understand what problem exists in the code, how
this patch solves it, and why this approach was chosen over any
alternative approaches?
Thanks,
Paul.
^ permalink raw reply
* Re: radeonfb, dedicate memory to something else
From: Matt Sealey @ 2008-07-22 9:05 UTC (permalink / raw)
To: Michel Dänzer; +Cc: ppc-dev
In-Reply-To: <1216716723.15900.128.camel@thor.sulgenrain.local>
Michel Dänzer wrote:
> On Tue, 2008-07-22 at 09:31 +0100, Matt Sealey wrote:
>> or other graphics drivers can be told "please only use the first 32MB" and
>> then either manually or automatically, map the rest as ramdisk.
>
> You can limit the amount of video RAM used by X using the VideoRam
> directive in xorg.conf(5).
Ah okay. So now.. how do we do this for framebuffers?
Is it safe to poke around in radeon_identify_vram and maybe supply a kernel
argument videomem=32M and let it check, if it's bigger, then limit it, and
if not, keep the old size in rinfo->video_ram?
Can/could this be moved to all relevant framebuffer drivers?
> GART doesn't have anything to do with this. I suspect he was thinking of
> the PCI BARs not covering all video RAM.
That's certainly not the case here.
--
Matt Sealey <matt@genesi-usa.com>
Genesi, Manager, Developer Relations
^ permalink raw reply
* Re: [PATCH 1/4][V2] powerpc : add support for linux, usable-memory properties for drconf memory
From: Chandru @ 2008-07-22 9:01 UTC (permalink / raw)
To: benh; +Cc: linuxppc-dev, Michael Neuling, Stephen Rothwell
In-Reply-To: <200807111919.36401.chandru@in.ibm.com>
Scan for linux,usable-memory properties in case of dynamic reconfiguration
memory . Support for kexec/kdump.
Signed-off-by: Chandru Siddalingappa <chandru@in.ibm.com>
---
Patch applies on powerpc tree. Patch was reviewed by Nathan Fontenot, Stephen
Rothwell, Michael Neuling.
arch/powerpc/kernel/prom.c | 40 +++++++++++++++++++++++------
arch/powerpc/mm/numa.c | 48 ++++++++++++++++++++++++-----------
2 files changed, 65 insertions(+), 23 deletions(-)
diff -Naurp powerpc-orig/arch/powerpc/kernel/prom.c
powerpc/arch/powerpc/kernel/prom.c
--- powerpc-orig/arch/powerpc/kernel/prom.c 2008-07-22 14:11:53.000000000
+0530
+++ powerpc/arch/powerpc/kernel/prom.c 2008-07-22 14:12:17.000000000 +0530
@@ -888,9 +888,10 @@ static u64 __init dt_mem_next_cell(int s
*/
static int __init early_init_dt_scan_drconf_memory(unsigned long node)
{
- cell_t *dm, *ls;
- unsigned long l, n, flags;
+ cell_t *dm, *ls, *usm;
+ unsigned long l, n, flags, ranges;
u64 base, size, lmb_size;
+ char buf[32];
ls = (cell_t *)of_get_flat_dt_prop(node, "ibm,lmb-size", &l);
if (ls == NULL || l < dt_root_size_cells * sizeof(cell_t))
@@ -914,14 +915,37 @@ static int __init early_init_dt_scan_drc
or if the block is not assigned to this partition (0x8) */
if ((flags & 0x80) || !(flags & 0x8))
continue;
- size = lmb_size;
- if (iommu_is_off) {
+ if (iommu_is_off)
if (base >= 0x80000000ul)
continue;
- if ((base + size) > 0x80000000ul)
- size = 0x80000000ul - base;
- }
- lmb_add(base, size);
+ size = lmb_size;
+
+ /*
+ * Append 'n' to 'linux,usable-memory' to get special
+ * properties passed in by tools like kexec-tools. Relevant
+ * only if this is a kexec/kdump kernel.
+ */
+ sprintf(buf, "linux,usable-memory%d", (int)n);
+ usm = of_get_flat_dt_prop(node, buf, &l);
+ ranges = 1;
+ if (usm != NULL)
+ ranges = (l >> 2)/(dt_root_addr_cells
+ + dt_root_size_cells);
+ do {
+ if (usm != NULL) {
+ base = dt_mem_next_cell(dt_root_addr_cells,
+ &usm);
+ size = dt_mem_next_cell(dt_root_size_cells,
+ &usm);
+ if (size == 0)
+ break;
+ }
+ if (iommu_is_off)
+ if ((base + size) > 0x80000000ul)
+ size = 0x80000000ul - base;
+
+ lmb_add(base, size);
+ } while (--ranges);
}
lmb_dump_all();
return 0;
diff -Naurp powerpc-orig/arch/powerpc/mm/numa.c powerpc/arch/powerpc/mm/numa.c
--- powerpc-orig/arch/powerpc/mm/numa.c 2008-07-22 14:11:53.000000000 +0530
+++ powerpc/arch/powerpc/mm/numa.c 2008-07-22 14:12:17.000000000 +0530
@@ -493,11 +493,13 @@ static unsigned long __init numa_enforce
*/
static void __init parse_drconf_memory(struct device_node *memory)
{
- const u32 *dm;
- unsigned int n, rc;
- unsigned long lmb_size, size;
+ const u32 *dm, *usm;
+ unsigned int n, rc, len, ranges;
+ unsigned long lmb_size, size, sz;
int nid;
struct assoc_arrays aa;
+ char buf[32];
+ u64 base;
n = of_get_drconf_memory(memory, &dm);
if (!n)
@@ -524,19 +526,35 @@ static void __init parse_drconf_memory(s
nid = of_drconf_to_nid_single(&drmem, &aa);
- fake_numa_create_new_node(
- ((drmem.base_addr + lmb_size) >> PAGE_SHIFT),
- &nid);
-
- node_set_online(nid);
-
- size = numa_enforce_memory_limit(drmem.base_addr, lmb_size);
- if (!size)
- continue;
+ /*
+ * Append 'n' to 'linux,usable-memory' to get special
+ * properties passed in by tools like kexec-tools. Relevant
+ * only if this is a kexec/kdump kernel.
+ */
+ sprintf(buf, "linux,usable-memory%d", (int)n);
+ usm = of_get_property(memory, buf, &len);
+ ranges = 1;
+ if (usm != NULL)
+ ranges = (len >> 2) /
+ (n_mem_addr_cells + n_mem_size_cells);
+
+ base = drmem.base_addr;
+ size = lmb_size;
+ do {
+ if (usm != NULL) {
+ base = read_n_cells(n_mem_addr_cells, &usm);
+ size = read_n_cells(n_mem_size_cells, &usm);
+ }
- add_active_range(nid, drmem.base_addr >> PAGE_SHIFT,
- (drmem.base_addr >> PAGE_SHIFT)
- + (size >> PAGE_SHIFT));
+ fake_numa_create_new_node(((base + size) >> PAGE_SHIFT),
+ &nid);
+ node_set_online(nid);
+ sz = numa_enforce_memory_limit(base, size);
+ if (sz)
+ add_active_range(nid, base >> PAGE_SHIFT,
+ (base >> PAGE_SHIFT)
+ + (sz >> PAGE_SHIFT));
+ } while (--ranges);
}
}
^ permalink raw reply
* Re: radeonfb, dedicate memory to something else
From: Michel Dänzer @ 2008-07-22 8:52 UTC (permalink / raw)
To: Matt Sealey; +Cc: ppc-dev
In-Reply-To: <48859AD2.6050404@genesi-usa.com>
On Tue, 2008-07-22 at 09:31 +0100, Matt Sealey wrote:
> Jon Smirl wrote:
> > On 7/20/08, Matt Sealey <matt@genesi-usa.com> wrote:
> >> Hi guys,
> >>
> >> I know this isn't a PPC question, but since some of the RadeonFB developers
> >> live here I thought best (and it's about a PPC platform).
> >>
> >> Is there any way to hack up the RadeonFB driver - or anything related - to
> >> reserve portions of the memory for a "fake" MTD or so, and still use the
> >> Radeon as a graphics device? What I am talking about basically is turning
> >> a 64MB Radeon card into a 32MB Radeon card, or a 128MB one into a 64MB
> >> card..
> >
> > Somebody write this long ago. Maybe around 2000. That's all I
> > remember. I think they made the video memory into a ram disk.
>
> Yeah making it into a ramdisk precludes the use of the card as a video card
> though.. this is what I am trying to get around. If fbdev and X can cooperate
> on believing that a 64MB card is a 32MB card, then the upper 32MB can be used
> to attach the MTD "ram" driver at a certain address (maybe we can even make a
> hacky stub driver that recognizes this configuration based on OF tree..)
>
> There are obvious limitations in that the Pegasos/Efika firmware only will
> map 128MB of video memory, and the PCI BAR is limited to 256MB chunks anyway,
> but that shouldn't matter. I just wonder, how it can be done that radeonfb
> or other graphics drivers can be told "please only use the first 32MB" and
> then either manually or automatically, map the rest as ramdisk.
You can limit the amount of video RAM used by X using the VideoRam
directive in xorg.conf(5).
> > I believe there is more to it, the GART window may be smaller than the
> > total RAM on the card. You need to use the GART to map in the
> > appropriate pieces.
>
> The problem here is the PCI bus on the Efika is a PCI bus, with an AGP
> riser. It doesn't add any AGP functionality like real GART on the host
> controller side, so there is nothing to map system memory into AGP's
> view of the system.. it always confused me how "pcigart" is meant to
> work and how an AGP GART does anything different to how PCI works in
> the first place (the documentation/spec doesn't make it that clear in
> my opinion :)
GART doesn't have anything to do with this. I suspect he was thinking of
the PCI BARs not covering all video RAM.
--
Earthling Michel Dänzer | http://tungstengraphics.com
Libre software enthusiast | Debian, X and DRI developer
^ permalink raw reply
* Re: radeonfb, dedicate memory to something else
From: Matt Sealey @ 2008-07-22 8:31 UTC (permalink / raw)
To: Jon Smirl; +Cc: ppc-dev
In-Reply-To: <9e4733910807200826m22b676aewa89de8df9fd6da33@mail.gmail.com>
Jon Smirl wrote:
> On 7/20/08, Matt Sealey <matt@genesi-usa.com> wrote:
>> Hi guys,
>>
>> I know this isn't a PPC question, but since some of the RadeonFB developers
>> live here I thought best (and it's about a PPC platform).
>>
>> Is there any way to hack up the RadeonFB driver - or anything related - to
>> reserve portions of the memory for a "fake" MTD or so, and still use the
>> Radeon as a graphics device? What I am talking about basically is turning
>> a 64MB Radeon card into a 32MB Radeon card, or a 128MB one into a 64MB
>> card..
>
> Somebody write this long ago. Maybe around 2000. That's all I
> remember. I think they made the video memory into a ram disk.
Yeah making it into a ramdisk precludes the use of the card as a video card
though.. this is what I am trying to get around. If fbdev and X can cooperate
on believing that a 64MB card is a 32MB card, then the upper 32MB can be used
to attach the MTD "ram" driver at a certain address (maybe we can even make a
hacky stub driver that recognizes this configuration based on OF tree..)
There are obvious limitations in that the Pegasos/Efika firmware only will
map 128MB of video memory, and the PCI BAR is limited to 256MB chunks anyway,
but that shouldn't matter. I just wonder, how it can be done that radeonfb
or other graphics drivers can be told "please only use the first 32MB" and
then either manually or automatically, map the rest as ramdisk.
> I believe there is more to it, the GART window may be smaller than the
> total RAM on the card. You need to use the GART to map in the
> appropriate pieces.
The problem here is the PCI bus on the Efika is a PCI bus, with an AGP
riser. It doesn't add any AGP functionality like real GART on the host
controller side, so there is nothing to map system memory into AGP's
view of the system.. it always confused me how "pcigart" is meant to
work and how an AGP GART does anything different to how PCI works in
the first place (the documentation/spec doesn't make it that clear in
my opinion :)
You would certainly know better than I..
--
Matt Sealey <matt@genesi-usa.com>
Genesi, Manager, Developer Relations
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox