* compact flash driver
From: John Wu @ 2006-05-30 3:48 UTC (permalink / raw)
To: linuxppc-embedded
Dear sir
Do you have compact flash card driver supported in u-boot.I need it.If
you don't have it .Can you tell me how the CF card initialize if you
know how to initialize it?
^ permalink raw reply
* Re: compact flash driver
From: KokHow Teh @ 2006-05-29 4:45 UTC (permalink / raw)
To: John Wu <jwu; +Cc: linuxppc-embedded
>Dear sir
>Do you have compact flash card driver supported in u-boot.I need it.If
^^^^^^
You have posted your question to the wrong list.
>you don't have it .Can you tell me how the CF card initialize if you
>know how to initialize it?
Ask more specific question as to what hardware platform you are using.
Specifically, which CF controller....
^ permalink raw reply
* Re: Can't get CoralP drivers to work
From: jourdan @ 2006-05-29 7:07 UTC (permalink / raw)
To: Dan Malek; +Cc: jourdan, linuxppc-embedded
In-Reply-To: <38D2D5EE-A581-42A4-B3E7-FEEBBA67D311@embeddedalley.com>
>
> On May 24, 2006, at 12:54 PM, jourdan@enib.fr wrote:
>
>> I have a MPC8260 processor card with a Coral-P evaluation board
>> (rev 4.0).
>
> Are you sure?
>
> The 8260 does not have a PCI bus and the Coral-P
> is a PCI card :-)
>
Yes indeed my mistake it's a 8270 !
^ permalink raw reply
* Re: Can't get CoralP drivers to work
From: jourdan @ 2006-05-29 7:34 UTC (permalink / raw)
To: Wolfgang Denk; +Cc: jourdan, linuxppc-embedded
In-Reply-To: <20060524195747.0CE6E353BFD@atlas.denx.de>
> In message <3799.194.3.133.184.1148489640.squirrel@webmail.enib.fr> you
> wrote:
>>
>> I have a MPC8260 processor card with a Coral-P evaluation board (rev
>> 4.0).
>> My system do not have keyboard nor mouse (i use the serial console).
>>
>> I use linux kernel 2.4.25 & 2.6.9.
>
> We have instructions on our web site; did you read these?
Yes I did. I use the same jumper configuration (for board rev 4.0) as the
pictures on your web site.
>> I'm trying to get the framebuffer driver to work. During the boot the
>> driver loads fine but the monitor remains blank (no video signal). If i
>> try to `cat /dev/urandom > /dev/fb/0` nothing happens.
>
> Are you using devfs? Don't! Use /dev/fb0
Without devfs, I have /dev/fb0.
During boot sequence, the driver loads fine (built-in, not module) :
...
MB86290: fb_init called.
MB86290: initialize called.
MB86290: GDC base phys address: 0x8c000000
MB86290: GDC base virt address: 0xc5000000
Console: switching to frame buffer device
MB86290: dmamem: GFP success.
MB86290: fb_init finished
...
In /proc I have :
# more /proc/fb
0 MB86290
This seems ok to me but I don't have any video signal. My screen remains
blank.
>> I compiled an Xserver (Release 6.9), and the x11 drivers for the coralp.
>> When I start X, it says that it can not open tty0 (indeed it doesn't
>> exists).
>
> Well, you got an error message (tty0 cannot be opened), you verified
> that it is valid (tty0 does not exist), so fix the problem...
>
Without devfs, I have ttys :
# ls -al tty*
crw-rw-rw- 1 root root 5, 0 May 29 2006 tty
crw--w--w- 1 root 5 4, 0 May 29 2006 tty0
crw-rw---- 1 root 5 4, 1 May 29 2006 tty1
crw-rw---- 1 root 5 4, 2 May 29 2006 tty2
crw-rw---- 1 root 14 4, 64 May 29 2006 ttyS0
crw-rw---- 1 root 14 4, 65 May 29 2006 ttyS1
crw-rw---- 1 root 14 4, 66 May 29 2006 ttyS2
crw-rw---- 1 root 14 4, 67 May 29 2006 ttyS3
crw-rw-rw- 1 root 5 3, 0 May 29 2006 ttyp0
crw-rw-rw- 1 root 5 3, 1 May 29 2006 ttyp1
crw-rw-rw- 1 root 5 3, 2 May 29 2006 ttyp2
crw-rw-rw- 1 root 5 3, 3 May 29 2006 ttyp3
crw-rw-rw- 1 root 5 3, 4 May 29 2006 ttyp4
crw-rw-rw- 1 root 5 3, 5 May 29 2006 ttyp5
crw-rw-rw- 1 root 5 3, 6 May 29 2006 ttyp6
crw-rw-rw- 1 root 5 3, 7 May 29 2006 ttyp7
crw-rw-rw- 1 root 5 3, 8 May 29 2006 ttyp8
crw-rw-rw- 1 root 5 3, 9 May 29 2006 ttyp9
Major and minor codes are ok but when I start X :
...
Fatal server error:
xf86OpenConsole: Cannot open /dev/tty0 (No such file or directory)
...
I have to start X from a serial console. There are no keyboard or mouse
connectors on my board. This is maybe the source of my problems ?
Thanks for your help.
^ permalink raw reply
* Re: Can't get CoralP drivers to work
From: Wolfgang Denk @ 2006-05-29 9:12 UTC (permalink / raw)
To: jourdan; +Cc: linuxppc-embedded
In-Reply-To: <1402.194.3.133.184.1148888040.squirrel@webmail.enib.fr>
In message <1402.194.3.133.184.1148888040.squirrel@webmail.enib.fr> you wrote:
>
> This seems ok to me but I don't have any video signal. My screen remains
> blank.
What's your boot arguments? Where is your console device, on the
serial port or on the frame buffer?
> xf86OpenConsole: Cannot open /dev/tty0 (No such file or directory)
> ...
Did you enable all of the following options in your kernel config?
CONFIG_FB=y
CONFIG_DUMMY_CONSOLE=y
CONFIG_FB_MB86290=y
CONFIG_FBCON_ADVANCED=y
CONFIG_FBCON_CFB16=y
CONFIG_FBCON_FONTS=y
CONFIG_FONT_8x8=y
CONFIG_FONT_8x16=y
CONFIG_VT=y
CONFIG_VT_CONSOLE=y
My guess is that CONFIG_VT and/or CONFIG_VT_CONSOLE might be missing.
Best regards,
Wolfgang Denk
--
Software Engineering: Embedded and Realtime Systems, Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
"There is no distinctly American criminal class except Congress."
- Mark Twain
^ permalink raw reply
* Re: Can't get CoralP drivers to work
From: jourdan @ 2006-05-29 10:19 UTC (permalink / raw)
To: Wolfgang Denk; +Cc: linuxppc-embedded
In-Reply-To: <20060529091257.686CB3525D9@atlas.denx.de>
> In message <1402.194.3.133.184.1148888040.squirrel@webmail.enib.fr> you
> wrote:
>>
>> This seems ok to me but I don't have any video signal. My screen remains
>> blank.
>
> What's your boot arguments? Where is your console device, on the
> serial port or on the frame buffer?
My boot arguments :
# more /proc/cmdline
console=tty0 console=ttyS1,9600 devfs=mount ip=bootp root=/dev/nfs rw
My console is on the serial port (ttyS1 on SMC2).
>> xf86OpenConsole: Cannot open /dev/tty0 (No such file or directory)
>> ...
>
> Did you enable all of the following options in your kernel config?
>
> CONFIG_FB=y
> CONFIG_DUMMY_CONSOLE=y
> CONFIG_FB_MB86290=y
> CONFIG_FBCON_ADVANCED=y
> CONFIG_FBCON_CFB16=y
> CONFIG_FBCON_FONTS=y
> CONFIG_FONT_8x8=y
> CONFIG_FONT_8x16=y
> CONFIG_VT=y
> CONFIG_VT_CONSOLE=y
>
> My guess is that CONFIG_VT and/or CONFIG_VT_CONSOLE might be missing.
All those options are enabled.
^ permalink raw reply
* Re: [Alsa-devel] [RFC 2/7] snd-aoa: add aoa core
From: Takashi Iwai @ 2006-05-29 10:57 UTC (permalink / raw)
To: Johannes Berg; +Cc: linuxppc-dev, alsa-devel
In-Reply-To: <20060528190124.579130000@johannes.berg>
At Sun, 28 May 2006 21:00:28 +0200,
Johannes Berg wrote:
> --- /dev/null
> +++ b/sound/aoa/core/snd-aoa-alsa.c
> @@ -0,0 +1,91 @@
> +/*
> + * Apple Onboard Audio Alsa helpers
> + *
> + * Copyright 2006 Johannes Berg <johannes@sipsolutions.net>
> + *
> + * GPL v2, can be found in COPYING.
> + */
> +#include <linux/module.h>
> +#include "snd-aoa-alsa.h"
> +
> +static struct aoa_card *aoa_card;
> +
> +int aoa_alsa_init(char *name, struct module *mod)
> +{
> + struct snd_card *alsa_card;
> + int err;
> +
> + if (aoa_card)
> + /* cannot be EEXIST due to usage in aoa_fabric_register */
> + return -EBUSY;
> +
> + alsa_card = snd_card_new(-1, name, mod, sizeof(struct aoa_card));
Usually the first argument here is the index module option so that
user may specify the card order (e.g. secondary card) independent from
the order of module loading.
> + if (!alsa_card)
> + return -ENOMEM;
> + aoa_card = alsa_card->private_data;
> + aoa_card->alsa_card = alsa_card;
> + strncpy(alsa_card->driver, "AppleOnbdAudio", sizeof(alsa_card->driver));
> + strncpy(alsa_card->shortname, name, sizeof(alsa_card->shortname));
> + strncpy(alsa_card->longname, name, sizeof(alsa_card->longname));
> + strncpy(alsa_card->mixername, name, sizeof(alsa_card->mixername));
strlcpy is safer. Also, longname usually contains more verbose info.
> --- /dev/null
> +++ b/sound/aoa/core/snd-aoa-core.c
(snip)
> + err = aoa_alsa_init(new_fabric->name, new_fabric->owner);
> + if (err) {
> + return err;
> + }
Remove braces.
Takashi
^ permalink raw reply
* RE: Setting I&D cache enable in the same mtspr instruction
From: Assaf Hoffman @ 2006-05-29 10:59 UTC (permalink / raw)
To: Mark A. Greer; +Cc: Ronen Shitrit, Rita Shtern, linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 482 bytes --]
Hi,
Attached...
-----Original Message-----
From: Mark A. Greer [mailto:mgreer@mvista.com]
Sent: Wednesday, May 24, 2006 1:35 AM
To: Assaf Hoffman
Cc: Mark A. Greer; linuxppc-embedded@ozlabs.org; Rita Shtern; Ronen
Shitrit
Subject: Re: Setting I&D cache enable in the same mtspr instruction
On Tue, May 23, 2006 at 12:55:46PM +0300, Assaf Hoffman wrote:
> Attached.
> Thanks.
Er, how about a *patch* place inline (as in, not as an attachment).
Thanks,
Mark
[-- Attachment #2: cpu_setup_6xx.patch --]
[-- Type: application/octet-stream, Size: 827 bytes --]
--- ../downloads/kernels/linux-2.6.12.6/arch/ppc/kernel/cpu_setup_6xx_patch.S 2006-05-29 13:53:07.000000000 +0300
+++ ../downloads/kernels/linux-2.6.12.6/arch/ppc/kernel/cpu_setup_6xx.S 2005-08-29 19:55:27.000000000 +0300
@@ -79,19 +79,17 @@
/* Enable caches for 603's, 604, 750 & 7400 */
setup_common_caches:
mfspr r11,SPRN_HID0
- ori r8,r11,HID0_DCE
andi. r0,r11,HID0_DCE
+ ori r11,r11,HID0_ICE|HID0_DCE
+ ori r8,r11,HID0_ICFI
bne 1f /* don't invalidate the D-cache */
ori r8,r8,HID0_DCI /* unless it wasn't enabled */
1: sync
mtspr SPRN_HID0,r8 /* enable and invalidate caches */
sync
- ori r8,r11,HID0_ICE|HID0_DCE|HID0_ICFI
- isync
- sync
- mtspr SPRN_HID0,r8 /* enable and invalidate Instruction cache */
+ mtspr SPRN_HID0,r11 /* enable caches */
sync
-
+ isync
blr
/* 604, 604e, 604ev, ...
^ permalink raw reply
* Re: [snd] looking for layout-ids
From: Michael Schmitz @ 2006-05-29 11:49 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: linuxppc-dev list, Johannes Berg, debian-powerpc,
Eddy Petrişor
In-Reply-To: <1148679703.8089.162.camel@localhost.localdomain>
> > > If you get no output, you have no layout-id property. If you do get
> >
> > What are the plans for machines without layout-id, like the 5,2 model?
> > Will there be any alsa/aoa support at some point?
>
> There will be, but let's get the ones with layout-id first since
> snd-powermac should work on the older ones.
It sure does (5,5 at least).
Michael
^ permalink raw reply
* Re: [Alsa-devel] [RFC 4/7] snd-aoa: add codecs
From: Takashi Iwai @ 2006-05-29 12:08 UTC (permalink / raw)
To: Johannes Berg; +Cc: linuxppc-dev, alsa-devel
In-Reply-To: <20060528190125.927852000@johannes.berg>
At Sun, 28 May 2006 21:00:30 +0200,
Johannes Berg wrote:
> --- /dev/null
> +++ b/sound/aoa/codecs/snd-aoa-codec-onyx.c
> +/* both return 0 if all ok, else on error */
> +static int onyx_read_register(struct onyx *onyx, u8 reg, u8 *value)
> +{
> + s32 v;
> +
> + if (reg != ONYX_REG_CONTROL) {
> + *value = onyx->cache[reg-FIRSTREGISTER];
> + return 0;
> + }
> + v = i2c_smbus_read_byte_data(&onyx->i2c, reg);
> + if (v < 0)
> + return -1;
> + *value = (u8)v;
> + onyx->cache[ONYX_REG_CONTROL-FIRSTREGISTER] = *value;
Isn't it "reg - FIRSTREGISTER" ?
> + return 0;
> +}
> +
> +static int onyx_write_register(struct onyx *onyx, u8 reg, u8 value)
> +{
> + int result;
> +
> + result = i2c_smbus_write_byte_data(&onyx->i2c, reg, value);
> + if (!result)
> + onyx->cache[reg-FIRSTREGISTER] = value;
> + return result;
> +}
> +
> +/* alsa stuff */
> +
> +static int onyx_dev_register(struct snd_device *dev)
> +{
> + return 0;
> +}
> +
> +static struct snd_device_ops ops = {
> + .dev_register = onyx_dev_register,
> +};
> +
> +static int onyx_snd_vol_info(struct snd_kcontrol *kcontrol,
> + struct snd_ctl_elem_info *uinfo)
> +{
> + uinfo->type = SNDRV_CTL_ELEM_TYPE_INTEGER;
> + uinfo->count = 2;
> + uinfo->value.integer.min = -128+128;
> + uinfo->value.integer.max = -1+128;
I'd define a constant for 128.
> + return 0;
> +}
> +
> +static int onyx_snd_vol_get(struct snd_kcontrol *kcontrol,
> + struct snd_ctl_elem_value *ucontrol)
> +{
> + struct onyx *onyx = snd_kcontrol_chip(kcontrol);
> + s8 l,r;
> +
> + mutex_lock(&onyx->mutex);
> + onyx_read_register(onyx, ONYX_REG_DAC_ATTEN_LEFT, &l);
> + onyx_read_register(onyx, ONYX_REG_DAC_ATTEN_RIGHT, &r);
> + mutex_unlock(&onyx->mutex);
> +
> + ucontrol->value.integer.value[0] = l+128;
> + ucontrol->value.integer.value[1] = r+128;
> +
> + return 0;
> +}
> +
> +static int onyx_snd_vol_put(struct snd_kcontrol *kcontrol,
> + struct snd_ctl_elem_value *ucontrol)
> +{
> + struct onyx *onyx = snd_kcontrol_chip(kcontrol);
> +
> + mutex_lock(&onyx->mutex);
> + onyx_write_register(onyx, ONYX_REG_DAC_ATTEN_LEFT, ucontrol->value.integer.value[0]-128);
> + onyx_write_register(onyx, ONYX_REG_DAC_ATTEN_RIGHT, ucontrol->value.integer.value[1]-128);
Fold lines to fit with 80 columns (heh, blaming other one's code is
easy :)
> + /* FIXME: we could be checking if anything changed */
> + mutex_unlock(&onyx->mutex);
> +
> + return 1;
The put callback is supposed to return 0 if the values are unchanged
(although most apps ignore the return value).
(snip)
> +static u8 register_map[] = {
> + ONYX_REG_DAC_ATTEN_LEFT,
> + ONYX_REG_DAC_ATTEN_RIGHT,
> + ONYX_REG_CONTROL,
> + ONYX_REG_DAC_CONTROL,
> + ONYX_REG_DAC_DEEMPH,
> + ONYX_REG_DAC_FILTER,
> + ONYX_REG_DAC_OUTPHASE,
> + ONYX_REG_ADC_CONTROL,
> + ONYX_REG_ADC_HPF_BYPASS,
> + ONYX_REG_DIG_INFO1,
> + ONYX_REG_DIG_INFO2,
> + ONYX_REG_DIG_INFO3,
> + ONYX_REG_DIG_INFO4
> +};
> +
> +static u8 initial_values[] = {
Should have ARRAY_SIZE(register_map) since this size must be identical
with register_map.
> + 0x80, 0x80, /* muted */
> + ONYX_MRST | ONYX_SRST, /* but handled specially! */
> + ONYX_MUTE_LEFT | ONYX_MUTE_RIGHT,
> + 0, /* no deemphasis */
> + ONYX_DAC_FILTER_ALWAYS,
> + ONYX_OUTPHASE_INVERTED,
> + (-1 /*dB*/ + 8) & 0xF, /* line in selected, -1 dB gain*/
> + ONYX_ADC_HPF_ALWAYS,
> + (1<<2), /* pcm audio */
> + 2, /* category: pcm coder */
> + 0, /* sampling frequency 44.1 kHz, clock accuracy level II */
> + 1 /* 24 bit depth */
> +};
> +
> +/* reset registers of chip, either to initial or to previous values */
> +static int onyx_register_init(struct onyx *onyx)
> +{
> + int i;
> + u8 val;
> + u8 regs[sizeof(initial_values)];
> +
> + if (!onyx->initialised) {
> + memcpy(regs, initial_values, sizeof(initial_values));
> + if (onyx_read_register(onyx, ONYX_REG_CONTROL, &val))
> + return -1;
> + val &= ~ONYX_SILICONVERSION;
> + val |= initial_values[3];
> + regs[3] = val;
> + } else {
> + for (i=0; i<sizeof(register_map); i++)
> + regs[i] = onyx->cache[register_map[i]-FIRSTREGISTER];
> + }
> +
> + for (i=0; i<sizeof(register_map); i++) {
> + if (onyx_write_register(onyx, register_map[i], regs[i]))
> + return -1;
> + }
> + onyx->initialised = 1;
> + return 0;
> +}
> +
> +static struct transfer_info onyx_transfers[] = {
> + /* this is first so we can skip it if no input is present...
> + * No hardware exists with that, but it's here as an example
> + * of what to do :) */
> + {
> + /* analog input */
> + .formats = SNDRV_PCM_FMTBIT_S8 | SNDRV_PCM_FMTBIT_S16_BE | SNDRV_PCM_FMTBIT_S24_BE,
Too long lines ;)
(snip)
> + if (onyx->codec.soundbus_dev->attach_codec(onyx->codec.soundbus_dev,
> + aoa_get_card(),
> + ci, onyx)) {
> + printk(KERN_ERR PFX "error creating onyx pcm\n");
> + return -ENODEV;
> + }
> +#define ADDCTL(n) \
> + do { \
> + ctl = snd_ctl_new1(&n, onyx); \
> + if (ctl) { \
> + ctl->id.device = \
> + onyx->codec.soundbus_dev->pcm->device; \
> + aoa_snd_ctl_add(ctl); \
No error check?
> + /* we try to read from register ONYX_REG_CONTROL
> + * to check if the codec is present */
> + if (onyx_read_register(onyx, ONYX_REG_CONTROL, &dummy) != 0) {
> + i2c_detach_client(&onyx->i2c);
> + printk(KERN_ERR PFX "failed to read control register\n");
> + goto fail;
> + }
> +
> + strncpy(onyx->codec.name, "onyx", MAX_CODEC_NAME_LEN);
Use strlcpy, or MAX_CODEC_NAME_LEN-1. Similar lines are found in
tas driver too.
> --- /dev/null
> +++ b/sound/aoa/codecs/snd-aoa-codec-tas.c
> @@ -0,0 +1,669 @@
(snip)
> +struct tas {
> + u32 primary_magic;
> + struct aoa_codec codec;
> + /* see comment at top of file */
> + u32 secondary_magic;
> + struct aoa_codec secondary;
> + struct i2c_client i2c;
> + u32 muted_l:1, muted_r:1,
> + controls_created:1;
> + u8 cached_volume_l, cached_volume_r;
> + u8 mixer_l[3], mixer_r[3];
> + u8 acr;
> +};
> +
> +static struct tas *codec_to_tas(struct aoa_codec *codec)
> +{
> + u32 *tmp = (u32*)codec;
> + switch (*(tmp-1)) {
> + case TAS_PRIMARY_MAGIC:
> + return container_of(codec, struct tas, codec);
> + case TAS_SECONDARY_MAGIC:
> + return container_of(codec, struct tas, secondary);
> + default:
> + return NULL;
> + }
> +}
Looks a bit too hacky. IMO, it's better to define a struct
struct tas_codec {
struct aoa_codec codec;
struct tas *tas;
}
to make the above simpler like:
static struct tas *codec_to_tas(struct aoa_codec *codec)
{
return ((struct tas_codec *)codec)->tas;
}
The tas struct becomes:
struct as {
struct tas_codec primary;
struct tas_codec secondary;
...
}
and is initialized like:
tas->primary.tas = tas;
tas->secondary.tas = tas;
> +static int tas_snd_capture_source_info(struct snd_kcontrol *kcontrol,
> + struct snd_ctl_elem_info *uinfo)
> +{
> + static char* texts[] = { "Line-In", "Microphone" };
char *texts[]
> +static int tas_reset_init(struct tas *tas)
> +{
> + u8 tmp;
> +/*
> + char write[8];
> + union i2c_smbus_data read = { 0 };
> + int r1, r2;
> +*/
> + tas->codec.gpio->methods->set_hw_reset(tas->codec.gpio, 0);
> + msleep(1);
> + tas->codec.gpio->methods->set_hw_reset(tas->codec.gpio, 1);
> + msleep(1);
> + tas->codec.gpio->methods->set_hw_reset(tas->codec.gpio, 0);
> + msleep(1);
> +
> + tas->acr &= ~TAS_ACR_ANALOG_PDOWN;
> + tas->acr |= TAS_ACR_B_MONAUREAL | TAS_ACR_B_MON_SEL_RIGHT;
> + if (tas_write_reg(tas, TAS_REG_ACR, 1, &tas->acr))
> + return -ENODEV;
> +
> + tmp = TAS_MCS_SCLK64 | TAS_MCS_SPORT_MODE_I2S | TAS_MCS_SPORT_WL_24BIT;
> + if (tas_write_reg(tas, TAS_REG_MCS, 1, &tmp))
> + return -ENODEV;
> +
> + tmp = 0;
> + if (tas_write_reg(tas, TAS_REG_MCS2, 1, &tmp))
> + return -ENODEV;
> +/* I need help here!
Use ifdef. Nested comments are bad.
> + /* This is a bit tricky, but serves to detect if there really
> + * is a tas codec present.
> + * First, we set the volume register to 00,00,01 (on both channels).
> + * This is almost muted. Then, we read back the last 6 bytes we
> + * wrote to the chip, and check if they are the same.
> + *
> + write[0] = 7;
> + write[1] = TAS_REG_VOL;
> + write[2] = write[3] = 0;
> + write[4] = 1;
> + write[5] = write[6] = 0;
> + write[7] = 1;
> + r1 = tas_write_reg(tas, TAS_REG_VOL, 6, &write[1]);
> + /* Hmm, how am I supposed to do the i2c sequence that
> + * is mentioned on page 45 of the tas3004 datasheet?
> + * This doesn't cut it: *
> + read.block[0] = 7;
> + r2 = i2c_smbus_xfer(tas->i2c.adapter, tas->i2c.addr, tas->i2c.flags,
> + I2C_SMBUS_READ, TAS_REG_VOL,
> + I2C_SMBUS_BLOCK_DATA, &read);
> +
> + printk(KERN_DEBUG "r1 = %d, r2 = %d, read=%x %x %x %x %x %x %x %x\n", r1, r2, read.block[0], read.block[1], read.block[2], read.block[3], read.block[4], read.block[5], read.block[6], read.block[7]);
> +
> + if (r1 || r2 || memcmp(write, read.block, 8))
> + return -ENODEV;
> +*/
> +
> + return 0;
> +}
> +static int tas_init_codec(struct aoa_codec *codec)
> +{
(snip)
> + aoa_snd_ctl_add(snd_ctl_new1(&volume_control, tas));
Error checks please.
Takashi
^ permalink raw reply
* Re: [Alsa-devel] [RFC 5/7] snd-aoa: add layout-id fabric
From: Takashi Iwai @ 2006-05-29 12:14 UTC (permalink / raw)
To: Johannes Berg; +Cc: linuxppc-dev, alsa-devel
In-Reply-To: <20060528190129.503400000@johannes.berg>
At Sun, 28 May 2006 21:00:31 +0200,
Johannes Berg wrote:
>
> The 'fabric' is the thing that pulls all of snd-aoa together, this patch
> adds the 'layout' or 'layout-id' fabric that keys off the 'layout-id'
> property in the device-tree to pull in the proper modules. It itself loads
> if an i2sbus is present with a layout-id (exported in modalias) that it can
> use.
(snip)
> +static void use_layout(struct layout *l)
> +{
> + int i;
> +
> + for (i=0; i<MAX_CODECS_PER_BUS; i++) {
> + if (l->codecs[i].name) {
> + request_module("snd-aoa-codec-%s", l->codecs[i].name);
Just from curiosity: Does this work properly?
I remember that there was a deadlock when you call request_module()
during module probe.
Takashi
^ permalink raw reply
* Re: Setting I&D cache enable in the same mtspr instruction
From: Roger Larsson @ 2006-05-29 12:15 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <B9FFC3F97441D04093A504CEA31B7C41A62B2F@msilexch01.marvell.com>
Is the patch reversed?
diff -Naur old new > patch
And what about comments, are they all still valid?
"enable and invalidate caches" is now only Data cache...
In cases when I am writing code like this I try to
include the reason why it is not "optimized" together
in one write... (or soon someone will do that optimization).
/RogerL
^ permalink raw reply
* RE: Setting I&D cache enable in the same mtspr instruction
From: Assaf Hoffman @ 2006-05-29 12:37 UTC (permalink / raw)
To: Roger Larsson, linuxppc-embedded; +Cc: Ronen Shitrit
[-- Attachment #1: Type: text/plain, Size: 879 bytes --]
Hi,
Attached...
-----Original Message-----
From: linuxppc-embedded-bounces+hoffman=marvell.com@ozlabs.org
[mailto:linuxppc-embedded-bounces+hoffman=marvell.com@ozlabs.org] On
Behalf Of Roger Larsson
Sent: Monday, May 29, 2006 3:15 PM
To: linuxppc-embedded@ozlabs.org
Subject: Re: Setting I&D cache enable in the same mtspr instruction
Importance: Low
Is the patch reversed?
diff -Naur old new > patch
And what about comments, are they all still valid?
"enable and invalidate caches" is now only Data cache...
In cases when I am writing code like this I try to
include the reason why it is not "optimized" together
in one write... (or soon someone will do that optimization).
/RogerL
_______________________________________________
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded
[-- Attachment #2: cpu_setup_6xx.patch --]
[-- Type: application/octet-stream, Size: 1114 bytes --]
--- ../downloads/kernels/linux-2.6.12.6/arch/ppc/kernel/cpu_setup_6xx_patch.S 2006-05-29 15:31:24.000000000 +0300
+++ ../downloads/kernels/linux-2.6.12.6/arch/ppc/kernel/cpu_setup_6xx.S 2005-08-29 19:55:27.000000000 +0300
@@ -77,29 +77,19 @@
blr
/* Enable caches for 603's, 604, 750 & 7400 */
-
-/*
- * HID0[ICFI] and HID0[DCFI] must NOT both be set with the same mtspr
- * instruction, due to the synchronization requirements
- */
-
setup_common_caches:
mfspr r11,SPRN_HID0
- ori r8,r11,HID0_DCE
andi. r0,r11,HID0_DCE
+ ori r11,r11,HID0_ICE|HID0_DCE
+ ori r8,r11,HID0_ICFI
bne 1f /* don't invalidate the D-cache */
ori r8,r8,HID0_DCI /* unless it wasn't enabled */
1: sync
mtspr SPRN_HID0,r8 /* enable and invalidate caches */
- sync
- ori r8,r11,HID0_ICE|HID0_DCE|HID0_ICFI
- isync /* An isync must precede the setting */
- /* of the HID0[ICFI] in order for the */
- /* setting to take effect. */
sync
- mtspr SPRN_HID0,r8 /* enable and invalidate Instruction cache */
+ mtspr SPRN_HID0,r11 /* enable caches */
sync
-
+ isync
blr
/* 604, 604e, 604ev, ...
^ permalink raw reply
* Re: Re: PPC exception 0x320
From: jeanwelly @ 2006-05-29 14:22 UTC (permalink / raw)
To: Becky Bruce; +Cc: linuxppc-embedded@ozlabs.org
In-Reply-To: <4819ACC0-1281-487B-B290-C55071E1EC27@freescale.com>
SGkgQmVja3kgQnJ1Y2UsDQpTb3JyeSBmb3IgbGF0ZSByZXNwb25zZS4gSSBnb3QgbWFpbCB0cmFm
ZmljLi4uDQoNCkkgZW5jb3VudGVyZWQgdGhlIGV4Y2VwdGlvbiAweDMyMCB3aGljaCBjYXVzZWQg
dGhlIFBQQyBjYXJkIGNyYXNoLiBCYXNlZCBvbiBteSB1bmRlcnN0YW5kaW5nLCBJIHRoaW5rIGV4
Y2VwdGlvbiBpcyBhIEhXIGJlaGF2aW91ciwgc28gSSBndWVzcyB0aGVyZSBtYXliZSBleGlzdCBz
b21lIHJlZmVyZW5jZSBvbiBhbGwgdGhlIHN1cHBvcnRlZCBleGNlcHRpb25zIG9mIHNvbWUgdmVy
c2lvbiBvZiBQUEMuIERvIHlvdSBrbm93IHRoaXM/DQoNCk15IHN5c3RlbSB0YWtlIHRoYXQgZXhj
ZXB0aW9uIGFzIGFuICJ1bmtub3duIGV4Y2VwdGlvbiIgYW5kIGNyYXNoIHRoZSBjYXJkLiBTbywg
SSB0aGluayB0aGUgZXhjZXB0aW9uIGlzIGZyb20gdGhlIFBQQyBDUFUsIGJ1dCBkb24ndCB0aGUg
Y29uY3JldGUgbWVhbmluZ3MuDQoNCkFwcHJlY2lhdGUgeW91ciBzdWdnZXN0aW9ucy4NCi0tLQ0K
SmVhbndlbGx5DQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCg0K
PklzIHRoZXJlIHNvbWUgZXJyb3IgbWVzc2FnZSB5b3UgY2FuIHNob3cgbWU/DQo+DQo+LUINCj4N
Cj5PbiBBcHIgMjUsIDIwMDYsIGF0IDEwOjAzIEFNLCBqZWFud2VsbHkgd3JvdGU6DQo+DQo+PiBI
aSBCZWNreSBCcnVjZSwNCj4+IEknbSB1c2luZyBQUEMgNzUwLi4uIEp1c3QgYXMgeW91IHNhaWQs
IDB4MzAwIGlzIGZvciBEU0ksIGFuZCBJICANCj4+IGd1ZXNzIHRoZXkgYXJlIGEgc2V0IG9mIGV4
Y2VwdGlvbnMsIG5vdCBqdXN0IG9uZS4gQW5kIDB4MzIwIGlzIG9uZSAgDQo+PiBvZiB0aGVtLg0K
Pj4gSSBnb3QgYSBib2FyZCBjcmFzaCwgYW5kIFBQQyBhbGFybWVkIGV4Y2VwdGlvbiAweDMyMC4g
Q291bGQgeW91ICANCj4+IHNob3cgbWUgdGhlIG1lY2hhbmlzbSBvZiBoYW5kbGluZyBvZiBhIHNw
ZWNpYWwgZXhjZXB0aW9uIG5vdCBvbmUgc2V0Lg0KPj4gCQ0KPj4NCj4+ID09PT09PT0gMjAwNi0w
NC0yNSAwMjo1MzozNSDE+tTawLTQxdbQ0LS1wKO6PT09PT09PQ0KPj4NCj4+PiBDb3VsZCB5b3Ug
dHJ5IHRvIGJlIG1vcmUgc3BlY2lmaWM/ICBXaGF0IHByb2Nlc3NvciBkbyB5b3UgaGF2ZSwgd2hh
dA0KPj4+IGxpbnV4IHZlcnNpb24gYXJlIHlvdSBydW5uaW5nLCBhbmQgd2hhdCBkbyB5b3UgbWVh
biBleGFjdGx5IHdoZW4geW91DQo+Pj4gc2F5IHlvdSAiZW5jb3VudGVyZWQgUFBDIGV4Y2VwdGlv
biAweDMyMCI/ICBBcyBmYXIgYXMgSSBrbm93LCB0aGUNCj4+PiBwb3dlcnBjIGFyY2hpdGVjdHVy
ZSBkb2VzIG5vdCBkZWZpbmUgYW4gZXhjZXB0aW9uIDB4MzIwLiAgMHgzMDAgaXMNCj4+PiB1c3Vh
bGx5IERTSSBvbiBjbGFzc2ljIHBvd2VycGMgcGFydHMuICBCb29rRSBwYXJ0cyBoYW5kbGUgdGhp
bmdzDQo+Pj4gZGlmZmVyZW50bHkuDQo+Pj4NCj4+PiBUaGFua3MsDQo+Pj4gLUJlY2t5DQo+Pj4N
Cj4+PiBPbiBBcHIgMjQsIDIwMDYsIGF0IDg6NTEgQU0sIGplYW53ZWxseSB3cm90ZToNCj4+Pg0K
Pj4+PiBIaSwNCj4+Pj4gSSBlbmNvdW50ZXJlZCBQUEMgZXhjZXB0aW9uIDB4MzIwLCBidXQgZG9u
J3Qga25vdyB3aGF0IGl0IGZvci4gQW55DQo+Pj4+IG9uZSBjb3VsZCBoZWxwIG1lIG9uIHRoaXM/
DQo+Pj4+IFRoYW5rcyENCj4+Pj4gIAkJCQkNCj4+Pj4NCj4+Pj4goaGhoaGhoaGhoaGhoaGhoWpl
YW53ZWxseQ0KPj4+PiChoaGhoaGhoaGhoaGhoaGhamVhbndlbGx5QDEyNi5jb20NCj4+Pj4goaGh
oaGhoaGhoaGhoaGhoaGhoaEyMDA2LTA0LTI0DQo+Pj4+IF9fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fDQo+Pj4+IExpbnV4cHBjLWVtYmVkZGVkIG1haWxpbmcg
bGlzdA0KPj4+PiBMaW51eHBwYy1lbWJlZGRlZEBvemxhYnMub3JnDQo+Pj4+IGh0dHBzOi8vb3ps
YWJzLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2xpbnV4cHBjLWVtYmVkZGVkDQo+Pj4NCj4+Pg0KPj4+
IC4NCj4+DQo+PiA9ID0gPSA9ID0gPSA9ID0gPSA9ID0gPSA9ID0gPSA9ID0gPSA9ID0NCj4+IAkJ
CQ0KPj4NCj4+IKGhoaGhoaGhoaGhoaGhoaHWwg0KPj4gwPGjoQ0KPj4NCj4+IAkJCQkNCj4+IKGh
oaGhoaGhoaGhoaGhoaFqZWFud2VsbHkNCj4+IKGhoaGhoaGhoaGhoaGhoaFqZWFud2VsbHlAMTI2
LmNvbQ0KPj4goaGhoaGhoaGhoaGhoaGhoaGhoaEyMDA2LTA0LTI1DQo+Pg0KPg0KPg0KPi4NCg0K
PSA9ID0gPSA9ID0gPSA9ID0gPSA9ID0gPSA9ID0gPSA9ID0gPSA9DQoJCQkNCg0KoaGhoaGhoaGh
oaGhoaGhodbCDQrA8aOhDQogDQoJCQkJIA0KoaGhoaGhoaGhoaGhoaGhoWplYW53ZWxseQ0KoaGh
oaGhoaGhoaGhoaGhoWplYW53ZWxseUAxMjYuY29tDQqhoaGhoaGhoaGhoaGhoaGhoaGhoTIwMDYt
MDUtMjkNCg0K
^ permalink raw reply
* Re: [PATCH] Compile failure fix for ppc on 2.6.17-rc4-mm3 (2nd attempt)
From: Mel Gorman @ 2006-05-29 15:49 UTC (permalink / raw)
To: Andrew Morton; +Cc: linuxppc-dev, vgoyal, linux-kernel
In-Reply-To: <20060526094924.10efc515.akpm@osdl.org>
On (26/05/06 09:49), Andrew Morton didst pronounce:
> mel@csn.ul.ie (Mel Gorman) wrote:
> >
> > (Resending with Andrew's email address correct this time)
> >
> > For the last few -mm releases, kernels built for an old RS6000 failed to
> > compile with the message;
> >
> > arch/powerpc/kernel/built-in.o(.init.text+0x77b4): In function `vrsqrtefp':
> > : undefined reference to `__udivdi3'
> > arch/powerpc/kernel/built-in.o(.init.text+0x7800): In function `vrsqrtefp':
> > : undefined reference to `__udivdi3'
> > make: *** [.tmp_vmlinux1] Error 1
>
> A function with a name like that doesn't _deserve_ to compile.
>
heh
> But actually vrsqrtefp() doesn't call __udivdi3 - the error lies somewhere
> else in the kernel and the toolchain gets it wrong, so we don't know where.
>
It explains why I couldn't find where vrsqrtefp() was.
> The way I usually hunt this problem down is to build the .s files (make
> arch/powerpc/kernel/foo.s) and then grep around, find the offending C
> function.
>
That was a good idea, thanks. It showed that check_for_io_childs() in
arch/powerpc/kernel/pci_32.c was the real problem. A quick look showed
that is was doing divisions on resource_type_t which was 64 bits with my
.config. Selecting CONFIG_RESOURCES_32BIT made the problem go away. This
option is introduced by the kconfigurable-resources-* patches so I've cc'd
Vivek Goyal to comment on the potential fixes below.
> > 2.6.17-rc5 is not affected but I didn't search for the culprit patch in
> > -mm. The following patch adds an implementation of __udivdi3 for plain old
> > ppc32. This may not be the correct fix as Google tells me that __udivdi3
> > has been replaced by calls to do_div() in a number of cases. There was no
> > obvious way to do that for vrsqrtefp, hence this workaround. The patch should
> > be acked, rejected or replaced by a ppc expert.
>
> Yes, we've traditionally avoided adding the 64-bit divide library functions.
Understandable. The fixes are obvious in this case. Easiest is for users to
set CONFIG_RESOURCES_32BIT manually although the kernel build error is not
very obvious. A fairly easy bodge is to default CONFIG_RESOURCES_32BIT to Y
when building PPC32 but a determined user may still fail to build a kernel. A
slightly riskier option is this patch that replaces a potential 64 bit divide
with a do_div call. The patch has been successfully boot-tested on a RS6000.
Signed-off-by: Mel Gorman <mel@csn.ul.ie>
diff -rup -X /usr/src/patchset-0.6/bin//dontdiff linux-2.6.17-rc4-mm3-clean/arch/powerpc/kernel/pci_32.c linux-2.6.17-rc4-mm3-resources-32/arch/powerpc/kernel/pci_32.c
--- linux-2.6.17-rc4-mm3-clean/arch/powerpc/kernel/pci_32.c 2006-05-29 15:55:52.000000000 +0100
+++ linux-2.6.17-rc4-mm3-resources-32/arch/powerpc/kernel/pci_32.c 2006-05-29 15:53:43.000000000 +0100
@@ -1115,7 +1115,9 @@ check_for_io_childs(struct pci_bus *bus,
int rc = 0;
#define push_end(res, size) do { unsigned long __sz = (size) ; \
- res->end = ((res->end + __sz) / (__sz + 1)) * (__sz + 1) + __sz; \
+ resource_size_t farEnd = (res->end + __sz); \
+ do_div(farEnd, (__sz + 1)); \
+ res->end = farEnd * (__sz + 1) + __sz; \
} while (0)
list_for_each_entry(dev, &bus->devices, bus_list) {
^ permalink raw reply
* Linux kernel thread with Linux 2.6.x
From: Laurent Lagrange @ 2006-05-29 15:35 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <000001c65d85$5e699890$5201a8c0@GEG2400>
Hello everybody,
I'm writing a custom network driver based on a MPC8260 FCC device for a
2.6.9 linux kernel.
In this driver, I need to use specific buffer allocation functions which use
down and up semaphore functions.
As the interrupt handler can't be scheduled, I have made a kernel thread
which waits forever on a semaphore.
This semaphore is set when a received packet interrupt occured. All that
mechanism works but the performances
are very poor.
Is there any solution to increase the kthread priority in the scheduler ?
Is there another solution than the semaphore to quickly wake up a kthread ?
Thanks a lot for your help.
Laurent
^ permalink raw reply
* Re: [PATCH] Compile failure fix for ppc on 2.6.17-rc4-mm3 (2nd attempt)
From: Segher Boessenkool @ 2006-05-29 16:22 UTC (permalink / raw)
To: Mel Gorman; +Cc: Andrew Morton, linuxppc-dev, vgoyal, linux-kernel
In-Reply-To: <20060529154923.GA9025@skynet.ie>
>>> arch/powerpc/kernel/built-in.o(.init.text+0x77b4): In function
>>> `vrsqrtefp':
>>> : undefined reference to `__udivdi3'
>>> arch/powerpc/kernel/built-in.o(.init.text+0x7800): In function
>>> `vrsqrtefp':
>>> : undefined reference to `__udivdi3'
>>> make: *** [.tmp_vmlinux1] Error 1
>>
>> A function with a name like that doesn't _deserve_ to compile.
Would vector_reciprocal_square_root_estimate_floating_point() be any
better...
Anyway, this is just a machine insn mnemonic, so the function name is
fine
I believe.
> #define push_end(res, size) do { unsigned long __sz = (size) ; \
> - res->end = ((res->end + __sz) / (__sz + 1)) * (__sz + 1) + __sz; \
> + resource_size_t farEnd = (res->end + __sz); \
> + do_div(farEnd, (__sz + 1)); \
> + res->end = farEnd * (__sz + 1) + __sz; \
> } while (0)
Size here is a) a misnomer (size + 1 is the actual size) and b) always
a power
of two minus one. So instead, do
#define push_end(res, mask) res->end = -(-res->end & ~(unsigned
long)mask)
(with a do { } while(0) armour if you prefer).
Segher
^ permalink raw reply
* Re: Linux kernel thread with Linux 2.6.x
From: Thiago Galesi @ 2006-05-29 17:13 UTC (permalink / raw)
To: Laurent Lagrange; +Cc: linuxppc-embedded
In-Reply-To: <000201c68335$7c594b90$5201a8c0@GEG2400>
>
> As the interrupt handler can't be scheduled, I have made a kernel thread
> which waits forever on a semaphore.
> This semaphore is set when a received packet interrupt occured.
You should look into tasklets for this. Not that your system is not
OK, but, as you said it, it's not fast enough.
Note that you still have some limitations using tasklets, but it's
more flexible than Interrupt handlers.
^ permalink raw reply
* Re: [PATCH] Compile failure fix for ppc on 2.6.17-rc4-mm3 (2nd attempt)
From: Mel Gorman @ 2006-05-29 17:38 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: Andrew Morton, linuxppc-dev, vgoyal, linux-kernel
In-Reply-To: <2ebd96e4a7ea753273b2c5f856ba8c7a@kernel.crashing.org>
On Mon, 29 May 2006, Segher Boessenkool wrote:
>>>> arch/powerpc/kernel/built-in.o(.init.text+0x77b4): In function
>>>> `vrsqrtefp':
>>>> : undefined reference to `__udivdi3'
>>>> arch/powerpc/kernel/built-in.o(.init.text+0x7800): In function
>>>> `vrsqrtefp':
>>>> : undefined reference to `__udivdi3'
>>>> make: *** [.tmp_vmlinux1] Error 1
>>>
>>> A function with a name like that doesn't _deserve_ to compile.
>
> Would vector_reciprocal_square_root_estimate_floating_point() be any
> better...
> Anyway, this is just a machine insn mnemonic, so the function name is fine
> I believe.
>
>> #define push_end(res, size) do { unsigned long __sz = (size) ; \
>> - res->end = ((res->end + __sz) / (__sz + 1)) * (__sz + 1) + __sz; \
>> + resource_size_t farEnd = (res->end + __sz); \
>> + do_div(farEnd, (__sz + 1)); \
>> + res->end = farEnd * (__sz + 1) + __sz; \
>> } while (0)
>
> Size here is a) a misnomer (size + 1 is the actual size) and b) always a
> power
> of two minus one. So instead, do
>
> #define push_end(res, mask) res->end = -(-res->end & ~(unsigned long)mask)
>
> (with a do { } while(0) armour if you prefer).
>
It's not doing the same as the old code so is your suggested fix a correct
replacement?
For example, given 0xfff for size the current code rounds res->end to the
next 0x1000 boundary and adds 0xfff. Your propose fix just rounds it to
the next 0x1000 if I'm reading it correctly but is what the code was meant
to do in the first place? Using masks, the equivilant of the current code
is something like;
#define push_end(res, mask) do { \
res->end = -(-res->end & ~(unsigned long)mask); \
res->end += mask; \
} while (0)
--
Mel Gorman
Part-time Phd Student Linux Technology Center
University of Limerick IBM Dublin Software Lab
^ permalink raw reply
* Re: [PATCH] Compile failure fix for ppc on 2.6.17-rc4-mm3 (2nd attempt)
From: Segher Boessenkool @ 2006-05-29 17:56 UTC (permalink / raw)
To: Mel Gorman; +Cc: Andrew Morton, linuxppc-dev, vgoyal, linux-kernel
In-Reply-To: <Pine.LNX.4.64.0605291825500.11234@skynet.skynet.ie>
>>> #define push_end(res, size) do { unsigned long __sz = (size) ; \
>>> - res->end = ((res->end + __sz) / (__sz + 1)) * (__sz + 1) + __sz; \
>>> + resource_size_t farEnd = (res->end + __sz); \
>>> + do_div(farEnd, (__sz + 1)); \
>>> + res->end = farEnd * (__sz + 1) + __sz; \
>>> } while (0)
>>
>> Size here is a) a misnomer (size + 1 is the actual size) and b)
>> always a power
>> of two minus one. So instead, do
>>
>> #define push_end(res, mask) res->end = -(-res->end & ~(unsigned
>> long)mask)
>>
>> (with a do { } while(0) armour if you prefer).
>>
>
> It's not doing the same as the old code so is your suggested fix a
> correct replacement?
>
> For example, given 0xfff for size the current code rounds res->end to
> the next 0x1000 boundary and adds 0xfff. Your propose fix just rounds
> it to the next 0x1000 if I'm reading it correctly but is what the code
> was meant to do in the first place? Using masks, the equivilant of the
> current code is something like;
>
> #define push_end(res, mask) do { \
> res->end = -(-res->end & ~(unsigned long)mask); \
> res->end += mask; \
> } while (0)
Yeah forgot a bit, this looks fine.
Segher
^ permalink raw reply
* Re: [PATCH] powerpc: add dmesg command to xmon
From: Olaf Hering @ 2006-05-29 17:58 UTC (permalink / raw)
To: Andrew Morton, Linus Torvalds, Arnd Bergmann; +Cc: linuxppc-dev
In-Reply-To: <200605281812.09308.arnd@arndb.de>
On Sun, May 28, Arnd Bergmann wrote:
> On Sunday 28 May 2006 14:07, Olaf Hering wrote:
> > > This whole function looks fishy to me. It seems unnecessarily rude to me to
> > > use kallsyms_lookup_name in order to get at a static variable from another
> > > file. Can't you instead add a global function to kernel/printk.c to return
> > > the buffer?
> >
> > Its possible, but it wont end up in Linus tree.
>
> Hmm, so the idea is that because Linus doesn't like kernel debuggers, we just
> obfuscate the code for any improvements to xmon and hope he doesn't notice?
So lets just ask again for support in generic code for a dmesg command in xmon:
http://lkml.org/lkml/2004/10/28/32
vs. these 2 patches
http://ozlabs.org/pipermail/linuxppc-dev/2006-May/023261.html
http://lkml.org/lkml/2006/5/29/55
or no dmesg at all.
^ permalink raw reply
* Re: [PATCH] Compile failure fix for ppc on 2.6.17-rc4-mm3 (2nd attempt)
From: Mel Gorman @ 2006-05-29 19:05 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: Andrew Morton, linuxppc-dev, vgoyal, linux-kernel
In-Reply-To: <c6414fc4b2c627791a49085bf8eea7e8@kernel.crashing.org>
On (29/05/06 19:56), Segher Boessenkool didst pronounce:
> >>> #define push_end(res, size) do { unsigned long __sz = (size) ; \
> >>>- res->end = ((res->end + __sz) / (__sz + 1)) * (__sz + 1) + __sz; \
> >>>+ resource_size_t farEnd = (res->end + __sz); \
> >>>+ do_div(farEnd, (__sz + 1)); \
> >>>+ res->end = farEnd * (__sz + 1) + __sz; \
> >>> } while (0)
> >>
> >>Size here is a) a misnomer (size + 1 is the actual size) and b)
> >>always a power
> >>of two minus one. So instead, do
> >>
> >>#define push_end(res, mask) res->end = -(-res->end & ~(unsigned
> >>long)mask)
> >>
> >>(with a do { } while(0) armour if you prefer).
> >>
> >
> >It's not doing the same as the old code so is your suggested fix a
> >correct replacement?
> >
> >For example, given 0xfff for size the current code rounds res->end to
> >the next 0x1000 boundary and adds 0xfff. Your propose fix just rounds
> >it to the next 0x1000 if I'm reading it correctly but is what the code
> >was meant to do in the first place? Using masks, the equivilant of the
> >current code is something like;
> >
> >#define push_end(res, mask) do { \
> > res->end = -(-res->end & ~(unsigned long)mask); \
> > res->end += mask; \
> >} while (0)
>
> Yeah forgot a bit, this looks fine.
>
Ok. The following patch has been successfully boot tested on the same machine
with 64 bit resource_size_t. Because the mask is assumed to be a
power-of-two - 1, I added a comment and a BUG_ON() to be sure.
Signed-off-by: Mel Gorman <mel@csn.ul.ie>
diff -rup -X /usr/src/patchset-0.6/bin//dontdiff linux-2.6.17-rc4-mm3-clean/arch/powerpc/kernel/pci_32.c linux-2.6.17-rc4-mm3-resources-32/arch/powerpc/kernel/pci_32.c
--- linux-2.6.17-rc4-mm3-clean/arch/powerpc/kernel/pci_32.c 2006-05-29 15:55:52.000000000 +0100
+++ linux-2.6.17-rc4-mm3-resources-32/arch/powerpc/kernel/pci_32.c 2006-05-29 19:09:36.000000000 +0100
@@ -1114,8 +1114,16 @@ check_for_io_childs(struct pci_bus *bus,
int i;
int rc = 0;
-#define push_end(res, size) do { unsigned long __sz = (size) ; \
- res->end = ((res->end + __sz) / (__sz + 1)) * (__sz + 1) + __sz; \
+ /*
+ * Assuming mask is a power of two - 1, push_end
+ * moves res->end to the end of the next
+ * mask-aligned boundary.
+ * e.g. res->end of 0x1fff moves to 0x2fff
+ */
+#define push_end(res, mask) do { \
+ BUG_ON( ((mask+1) & mask) != 0); \
+ res->end = -(-res->end & ~(unsigned long)mask); \
+ res->end += mask; \
} while (0)
list_for_each_entry(dev, &bus->devices, bus_list) {
^ permalink raw reply
* [RFC/PATCH 0/8] Overhaul of virt IRQ configuration. / Kill ppc64_interrupt_controller.
From: Michal Ostrowski @ 2006-05-29 20:41 UTC (permalink / raw)
To: linuxppc-dev
The following set of patches is aimed at killing the
ppc64_interrupt_controller global variable, and similarly that various
global variables used to tweak the parameters of virtual IRQ re-mapping.
Instead each platform can use a single function to configure IRQ
re-mapping in "init_early()".
Platforms can choose the default configuration (which is to
say identity mappings of IRQ vectors 0..511) or specify their own
configuration: an offset (for ISA vectors), the range that is to be
identity mapped and the range of vectors that may be arbitrarily
re-mapper.
This allows us to remove the special-casing based on
ppc64_interrupt_controller in virt_irq_create_mapping().
Subsequently most uses of ppc64_interrupt_controller are on
configuration paths where we can typically obtain comparable information
by alternate means.
In the end, only pSeries-specific code must be aware of the choice of
PIC and it will check to see if an MPIC has been initialized (and if
not, assume XICS). (Thus no platforms beyond pSeries are affected.)
This code has been tested on pSeries LPAR, G5, and Maple. I'll be
re-testing it on a Power3 with MPIC shortly once a system for testing
becomes available again.
--
Michal Ostrowski <mostrows@watson.ibm.com>
^ permalink raw reply
* [PATCH 1/8] Formalize virtual-IRQ remapping configuration.
From: mostrows @ 2006-05-29 20:42 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <1148935262.25048.31.camel@brick>
Instead of setting various global various to configure the behavior of
virtual-IRQ remapping, each platform has the option of calling
virt_irq_config() in "init_early" to specify:
- the offset to be used (i.e. NUM_ISA_INTERRUPTS)
- the number of interrupt vectors which are to be mapped 1-1
- the number of interrupt vectors that may be arbitrarily remapped
If virt_irq_config() is not called, the default configuration will be
used (512 identity-mapped interrupts with no offset).
--
Signed-off-by: Michal Ostrowski <mostrows@watson.ibm.com>
---
arch/powerpc/kernel/irq.c | 62 ++++++++++++++++----------------
arch/powerpc/kernel/prom.c | 4 --
arch/powerpc/kernel/setup_64.c | 6 +++
arch/powerpc/platforms/iseries/setup.c | 3 +-
arch/powerpc/platforms/pseries/setup.c | 10 +++++
include/asm-powerpc/irq.h | 30 +++++++++++----
6 files changed, 70 insertions(+), 45 deletions(-)
2f99449cbcacf67694e38698ec9860f86ba052e2
diff --git a/arch/powerpc/kernel/irq.c b/arch/powerpc/kernel/irq.c
index 57d560c..efcb859 100644
--- a/arch/powerpc/kernel/irq.c
+++ b/arch/powerpc/kernel/irq.c
@@ -268,32 +268,35 @@ void __init init_IRQ(void)
#define UNDEFINED_IRQ 0xffffffff
unsigned int virt_irq_to_real_map[NR_IRQS];
-/*
- * Don't use virtual irqs 0, 1, 2 for devices.
- * The pcnet32 driver considers interrupt numbers < 2 to be invalid,
- * and 2 is the XICS IPI interrupt.
- * We limit virtual irqs to __irq_offet_value less than virt_irq_max so
- * that when we offset them we don't end up with an interrupt
- * number >= virt_irq_max.
- */
-#define MIN_VIRT_IRQ 3
-
-unsigned int virt_irq_max;
+static unsigned int min_virt_irq;
static unsigned int max_virt_irq;
static unsigned int nr_virt_irqs;
void
-virt_irq_init(void)
+virt_irq_config(unsigned int offset,
+ unsigned int num_shifted, unsigned int num_remapped)
{
- int i;
+ __irq_offset_value = offset;
+ min_virt_irq = num_shifted;
+ max_virt_irq = num_shifted + num_remapped - 1;
+ nr_virt_irqs = num_remapped;
- if ((virt_irq_max == 0) || (virt_irq_max > (NR_IRQS - 1)))
- virt_irq_max = NR_IRQS - 1;
- max_virt_irq = virt_irq_max - __irq_offset_value;
- nr_virt_irqs = max_virt_irq - MIN_VIRT_IRQ + 1;
+ BUG_ON(max_virt_irq + __irq_offset_value > (NR_IRQS-1));
+}
+void
+virt_irq_init(void)
+{
+ int i;
for (i = 0; i < NR_IRQS; i++)
virt_irq_to_real_map[i] = UNDEFINED_IRQ;
+
+ /* Configure the default mappings; don't remap interrupts,
+ * use 1-1 virt <-> real mappings. Subsequently platforms may
+ * choose to call virt_irq_config with their own custom settings.
+ */
+ virt_irq_config(0, NR_IRQS, 0);
+
}
/* Create a mapping for a real_irq if it doesn't already exist.
@@ -304,30 +307,25 @@ int virt_irq_create_mapping(unsigned int
unsigned int virq, first_virq;
static int warned;
- if (ppc64_interrupt_controller == IC_OPEN_PIC)
- return real_irq; /* no mapping for openpic (for now) */
-
- if (ppc64_interrupt_controller == IC_CELL_PIC)
- return real_irq; /* no mapping for iic either */
-
- /* don't map interrupts < MIN_VIRT_IRQ */
- if (real_irq < MIN_VIRT_IRQ) {
+ /* don't map interrupts < min_virt_irq */
+ if (real_irq < min_virt_irq) {
virt_irq_to_real_map[real_irq] = real_irq;
return real_irq;
}
- /* map to a number between MIN_VIRT_IRQ and max_virt_irq */
+ /* map to a number between min_virt_irq and max_virt_irq */
virq = real_irq;
if (virq > max_virt_irq)
- virq = (virq % nr_virt_irqs) + MIN_VIRT_IRQ;
+ virq = (virq % nr_virt_irqs) + min_virt_irq;
/* search for this number or a free slot */
first_virq = virq;
while (virt_irq_to_real_map[virq] != UNDEFINED_IRQ) {
if (virt_irq_to_real_map[virq] == real_irq)
return virq;
+
if (++virq > max_virt_irq)
- virq = MIN_VIRT_IRQ;
+ virq = min_virt_irq;
if (virq == first_virq)
goto nospace; /* oops, no free slots */
}
@@ -338,8 +336,10 @@ int virt_irq_create_mapping(unsigned int
nospace:
if (!warned) {
printk(KERN_CRIT "Interrupt table is full\n");
- printk(KERN_CRIT "Increase virt_irq_max (currently %d) "
- "in your kernel sources and rebuild.\n", virt_irq_max);
+ printk(KERN_CRIT "Modify kernel sources to call "
+ "virt_irq_config() with a larger value "
+ "of \"num_remapped\" (currently %d) and rebuild.\n",
+ nr_virt_irqs);
warned = 1;
}
return NO_IRQ;
@@ -358,7 +358,7 @@ unsigned int real_irq_to_virt_slowpath(u
virq = real_irq;
if (virq > max_virt_irq)
- virq = (virq % nr_virt_irqs) + MIN_VIRT_IRQ;
+ virq = (virq % nr_virt_irqs) + min_virt_irq;
first_virq = virq;
diff --git a/arch/powerpc/kernel/prom.c b/arch/powerpc/kernel/prom.c
index 9a07f97..bfbe6a7 100644
--- a/arch/powerpc/kernel/prom.c
+++ b/arch/powerpc/kernel/prom.c
@@ -472,10 +472,6 @@ void __init finish_device_tree(void)
DBG(" -> finish_device_tree\n");
-#ifdef CONFIG_PPC64
- /* Initialize virtual IRQ map */
- virt_irq_init();
-#endif
scan_interrupt_controllers();
/*
diff --git a/arch/powerpc/kernel/setup_64.c b/arch/powerpc/kernel/setup_64.c
index 4467c49..4669179 100644
--- a/arch/powerpc/kernel/setup_64.c
+++ b/arch/powerpc/kernel/setup_64.c
@@ -389,6 +389,12 @@ void __init setup_system(void)
*/
check_for_initrd();
+
+ /* Configure default setting for virtual IRQ remapping.
+ * ppc_md.init_early() may reconfigure this with virt_irq_config()
+ */
+ virt_irq_init();
+
/*
* Do some platform specific early initializations, that includes
* setting up the hash table pointers. It also sets up some interrupt-mapping
diff --git a/arch/powerpc/platforms/iseries/setup.c b/arch/powerpc/platforms/iseries/setup.c
index a6fd9be..6a7d04b 100644
--- a/arch/powerpc/platforms/iseries/setup.c
+++ b/arch/powerpc/platforms/iseries/setup.c
@@ -688,8 +688,9 @@ static int __init iseries_probe(void)
/*
* The Hypervisor only allows us up to 256 interrupt
* sources (the irq number is passed in a u8).
+ * This call provides us with vectors 0 .. 255 without remapping.
*/
- virt_irq_max = 255;
+ virt_irq_config(0, 256, 0);
return 1;
}
diff --git a/arch/powerpc/platforms/pseries/setup.c b/arch/powerpc/platforms/pseries/setup.c
index 5f79f01..9d22265 100644
--- a/arch/powerpc/platforms/pseries/setup.c
+++ b/arch/powerpc/platforms/pseries/setup.c
@@ -270,7 +270,6 @@ static void __init pSeries_discover_pic
* Setup interrupt mapping options that are needed for finish_device_tree
* to properly parse the OF interrupt tree & do the virtual irq mapping
*/
- __irq_offset_value = NUM_ISA_INTERRUPTS;
ppc64_interrupt_controller = IC_INVALID;
for (np = NULL; (np = of_find_node_by_name(np, "interrupt-controller"));) {
typep = (char *)get_property(np, "compatible", NULL);
@@ -286,6 +285,15 @@ static void __init pSeries_discover_pic
printk("pSeries_discover_pic: failed to recognize"
" interrupt-controller\n");
+ /*
+ * Don't use virtual irqs 0, 1, 2 for devices.
+ * The pcnet32 driver considers interrupt numbers < 2 to be invalid,
+ * and 2 is the XICS IPI interrupt.
+ */
+
+ virt_irq_config(NUM_ISA_INTERRUPTS, 3,
+ NR_IRQS - (3 + NUM_ISA_INTERRUPTS));
+
}
static void pSeries_mach_cpu_die(void)
diff --git a/include/asm-powerpc/irq.h b/include/asm-powerpc/irq.h
index 7bc6d73..f2adbc0 100644
--- a/include/asm-powerpc/irq.h
+++ b/include/asm-powerpc/irq.h
@@ -54,18 +54,32 @@
*/
extern unsigned int virt_irq_to_real_map[NR_IRQS];
-/* The maximum virtual IRQ number that we support. This
- * can be set by the platform and will be reduced by the
- * value of __irq_offset_value. It defaults to and is
- * capped by (NR_IRQS - 1).
- */
-extern unsigned int virt_irq_max;
-
/* Create a mapping for a real_irq if it doesn't already exist.
* Return the virtual irq as a convenience.
*/
int virt_irq_create_mapping(unsigned int real_irq);
-void virt_irq_init(void);
+
+/* Initializes the virtual IRQ re-mapping, before ppc_md.init_early() */
+extern void virt_irq_init(void);
+
+/* virt_irq_config - Configure the division of the virtual IRQ space.
+ * Each platform may call this to set it's own specific
+ * IRQ remapping parameters.
+ * @offset: offset of remapped space (i.e. NUM_ISA_INTERRUPTS).
+ * @num_shifted: number of vectors to be simply shifted to account for
+ * the offset with no other remapping.
+ * @num_remapper: number of vectors that may be arbitrarily remapped.
+ *
+ * Virtual IRQ vectors will have the following mappings to the IRQ vectors
+ * as seen by the approrpiate interrupt controller:
+ * 0 .. offset-1 -> 0 .. offset-1 (1-1 mapping)
+ * offset .. offset+num_shifted-1 -> 0 .. num_shifted-1 (shift by offset)
+ * offset+num_shifted .. offset+num_shifted+num_remapped-1 ->
+ * arbitrary mappings to real irq as required.
+ */
+extern void virt_irq_config(unsigned int offset,
+ unsigned int num_linear,
+ unsigned int num_remapped);
static inline unsigned int virt_irq_to_real(unsigned int virt_irq)
{
--
1.1.4.g0b63-dirty
^ permalink raw reply related
* [PATCH 2/8] PIC discovery re-organization.
From: mostrows @ 2006-05-29 20:42 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <1148935262.25048.31.camel@brick>
Change pSeries_discover_pic() to simply return the PIC type, rather
than setting the global "ppc64_interrupt_controller" value. They type of
controller present will be passed down as an argument to functions
that need it.
--
Signed-off-by: Michal Ostrowski <mostrows@watson.ibm.com>
---
arch/powerpc/platforms/pseries/setup.c | 36 +++++++++++++++++---------------
1 files changed, 19 insertions(+), 17 deletions(-)
3675f032e1b03d6f000ffb08b2487ee9aa44fa2d
diff --git a/arch/powerpc/platforms/pseries/setup.c b/arch/powerpc/platforms/pseries/setup.c
index 9d22265..33ae521 100644
--- a/arch/powerpc/platforms/pseries/setup.c
+++ b/arch/powerpc/platforms/pseries/setup.c
@@ -83,6 +83,7 @@ int fwnmi_active; /* TRUE if an FWNMI h
static void pseries_shared_idle_sleep(void);
static void pseries_dedicated_idle_sleep(void);
+static int pSeries_discover_pic(void);
struct mpic *pSeries_mpic;
@@ -195,8 +196,11 @@ static void pseries_lpar_enable_pmcs(voi
static void __init pSeries_setup_arch(void)
{
+ int int_ctrl = pSeries_discover_pic();
+ ppc64_interrupt_controller = int_ctrl;
+
/* Fixup ppc_md depending on the type of interrupt controller */
- if (ppc64_interrupt_controller == IC_OPEN_PIC) {
+ if (int_ctrl == IC_OPEN_PIC) {
ppc_md.init_IRQ = pSeries_init_mpic;
ppc_md.get_irq = mpic_get_irq;
/* Allocate the mpic now, so that find_and_init_phbs() can
@@ -261,39 +265,30 @@ static int __init pSeries_init_panel(voi
}
arch_initcall(pSeries_init_panel);
-static void __init pSeries_discover_pic(void)
+static int __init pSeries_discover_pic(void)
{
struct device_node *np;
char *typep;
-
/*
* Setup interrupt mapping options that are needed for finish_device_tree
* to properly parse the OF interrupt tree & do the virtual irq mapping
*/
- ppc64_interrupt_controller = IC_INVALID;
+ int int_ctrl = IC_INVALID;
for (np = NULL; (np = of_find_node_by_name(np, "interrupt-controller"));) {
typep = (char *)get_property(np, "compatible", NULL);
if (strstr(typep, "open-pic")) {
- ppc64_interrupt_controller = IC_OPEN_PIC;
+ int_ctrl = IC_OPEN_PIC;
break;
} else if (strstr(typep, "ppc-xicp")) {
- ppc64_interrupt_controller = IC_PPC_XIC;
+ int_ctrl = IC_PPC_XIC;
break;
}
}
- if (ppc64_interrupt_controller == IC_INVALID)
+ if (int_ctrl == IC_INVALID)
printk("pSeries_discover_pic: failed to recognize"
" interrupt-controller\n");
- /*
- * Don't use virtual irqs 0, 1, 2 for devices.
- * The pcnet32 driver considers interrupt numbers < 2 to be invalid,
- * and 2 is the XICS IPI interrupt.
- */
-
- virt_irq_config(NUM_ISA_INTERRUPTS, 3,
- NR_IRQS - (3 + NUM_ISA_INTERRUPTS));
-
+ return int_ctrl;
}
static void pSeries_mach_cpu_die(void)
@@ -346,7 +341,14 @@ static void __init pSeries_init_early(vo
iommu_init_early_pSeries();
- pSeries_discover_pic();
+ /*
+ * Don't use virtual irqs 0, 1, 2 for devices.
+ * The pcnet32 driver considers interrupt numbers < 2 to be invalid,
+ * and 2 is the XICS IPI interrupt.
+ */
+
+ virt_irq_config(NUM_ISA_INTERRUPTS, 3,
+ NR_IRQS - (3 + NUM_ISA_INTERRUPTS));
DBG(" <- pSeries_init_early()\n");
}
--
1.1.4.g0b63-dirty
^ permalink raw reply related
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