* Re: [Alsa-devel] [RFC 5/7] snd-aoa: add layout-id fabric
From: Johannes Berg @ 2006-05-30 12:37 UTC (permalink / raw)
To: Takashi Iwai; +Cc: linuxppc-dev, alsa-devel
In-Reply-To: <s5h64jp9ge4.wl%tiwai@suse.de>
[-- Attachment #1: Type: text/plain, Size: 323 bytes --]
On Mon, 2006-05-29 at 14:14 +0200, Takashi Iwai wrote:
> Just from curiosity: Does this work properly?
> I remember that there was a deadlock when you call request_module()
> during module probe.
Yes, it works, but I don't think this is actually done during module
probe (would have to check though)
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 793 bytes --]
^ permalink raw reply
* Re: [Alsa-devel] [RFC 4/7] snd-aoa: add codecs
From: Johannes Berg @ 2006-05-30 12:43 UTC (permalink / raw)
To: Takashi Iwai; +Cc: linuxppc-dev, alsa-devel
In-Reply-To: <s5h8xol9gom.wl%tiwai@suse.de>
[-- Attachment #1: Type: text/plain, Size: 2268 bytes --]
On Mon, 2006-05-29 at 14:08 +0200, Takashi Iwai wrote:
> > + 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" ?
Nah, look at the first line I quoted :)
> I'd define a constant for 128.
#define OFFSET_BECAUSE_ALSA_USERSPACE_PROGRAMS_SUCK 128
;)
Just kidding, will do.
> Fold lines to fit with 80 columns (heh, blaming other one's code is
> easy :)
Heh. I thought I'd Lindent'ed most of it.
> > + /* 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).
Does it have to? This way there's an event, but...
> > +static u8 initial_values[] = {
>
> Should have ARRAY_SIZE(register_map) since this size must be identical
> with register_map.
Good point.
> > +#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?
Hmm, yeah, I guess it should have error checks. Will revisit that.
> Use strlcpy, or MAX_CODEC_NAME_LEN-1. Similar lines are found in
> tas driver too.
Right.
> Looks a bit too hacky. IMO, it's better to define a struct
Maybe I'll just get rid of it completely, it's never hooked up as far as
I know. But yeah, I guess you're right.
> > +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[]
Any particular reason?
> > +/* I need help here!
>
> Use ifdef. Nested comments are bad.
I know. Temporary code, probably going away completely.
> > + aoa_snd_ctl_add(snd_ctl_new1(&volume_control, tas));
>
> Error checks please.
What should it do on such errors?
Thanks,
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 793 bytes --]
^ permalink raw reply
* Re: [Alsa-devel] [RFC 2/7] snd-aoa: add aoa core
From: Johannes Berg @ 2006-05-30 12:44 UTC (permalink / raw)
To: Takashi Iwai; +Cc: linuxppc-dev, alsa-devel
In-Reply-To: <s5hac919jzl.wl%tiwai@suse.de>
[-- Attachment #1: Type: text/plain, Size: 390 bytes --]
On Mon, 2006-05-29 at 12:57 +0200, Takashi Iwai wrote:
> > + 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.
Are you saying I should add an index module option and pass that?
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 793 bytes --]
^ permalink raw reply
* Re: Linux kernel thread with Linux 2.6.x
From: almoeli @ 2006-05-30 13:17 UTC (permalink / raw)
Cc: linuxppc-embedded
In-Reply-To: <20060530112343.GB24129@wohnheim.fh-wedel.de>
Hi,
do you have to use the semaphore or does a spinlock also meet your needs?
If you are in kernel 2.4 you can use one of the task_queues (e.g the
scheduler queue, timer and immediate queue also run at irq context) but
that won't have a better speed than your solution because it also gets
the processor when tasks are scheduled (all 10ms I think). In 2.6 it
would be the work_queue (schedule_work()).
So the best way is to use spinlocks and do the work in a tasklet at
interrupt context.
Oliver
Jörn Engel schrieb:
> On Tue, 30 May 2006 11:46:09 +0200, Laurent Lagrange wrote:
>> Thanks for your answer, but a tasklet runs in interrupt context
>> (in_interrupt() != 0) so it doesn't support schedule() call
>> included in "down" semaphore function.
>
> Do you have code you can show?
>
> Jörn
>
^ permalink raw reply
* MPC8270 on Microsys PM827 Kernel 2.6 Oops: kernel access of bad area, sig: 11 [#1]
From: Behre, Frederik - LT @ 2006-05-30 12:46 UTC (permalink / raw)
To: linuxppc-embedded
Hello=20
I compile my kernel with=20
pm82x_deconfig and PCI disabled.
Did I forgot something ??
After error Oops: kernel access of bad area, sig: 11 [#1] the Board
restarts.
Thanks for Helping
Freddy
U-Boot 1.1.4 (May 15 2006 - 09:13:13)
MPC8260 Reset Status: External Soft, External Hard
MPC8260 Clock Configuration
- Bus-to-Core Mult 2.5x, VCO Div 4, 60x Bus Freq 20-60 , Core Freq
50-120
- dfbrg 0, corecnf 0x11, busdf 3, cpmdf 1, plldf 0, pllmf 3, pcidf 3
- vco_out 400000000, scc_clk 100000000, brg_clk 100000000
- cpu_clk 250000000, cpm_clk 200000000, bus_clk 100000000
CPU: MPC8260 (HiP7 Rev 13, Mask 0.1 1K49M) at 250 MHz
Board: PM828
I2C: ready
DRAM: (60x:9COL) 128 MB
FLASH: 32 MB
In: serial
Out: serial
Err: serial
DOC: No DiskOnChip found
Net: FCC1 ETHERNET, FCC2 ETHERNET
BEDBUG:ready
Hit any key to stop autoboot: 0
Using FCC1 ETHERNET device
TFTP from server 192.168.0.1; our IP address is 192.168.0.2
Filename 'uImage-2.6'.
Load address: 0x400000
Loading:
#################################################################
=20
#################################################################
#######################################################
done
Bytes transferred =3D 945041 (e6b91 hex)
## Booting image at 00400000 ...
Image Name: Linux-2.6.14
Created: 2006-05-30 7:59:00 UTC
Image Type: PowerPC Linux Kernel Image (gzip compressed)
Data Size: 944977 Bytes =3D 922.8 kB
Load Address: 00000000
Entry Point: 00000000
Verifying Checksum ... OK
Uncompressing Kernel Image ... OK
Linux version 2.6.14 (root@c3415) (gcc version 4.0.0 (DENX ELDK 4.0
4.0.0)) #1 Tue May 30 09:58:59 CEST 2006=20
Microsys PM82x PowerPC port=20
Built 1 zonelists Kernel command line: root=3D/dev/nfs rw
nfsroot=3D192.168.0.1:/lop/eldk400/ppc_6xx/ console=3DttyCPM1
ip=3D192.168.0.2:192.168.0.1:192.168.0.1:255.255.255.0:ppc_82xx::off
panic=3D1
PID hash table entries: 1024 (order: 10, 16384 bytes)=20
Dentry cache hash table entries: 32768 (order: 5, 131072 bytes)=20
Inode-cache hash table entries: 16384 (order: 4, 65536 bytes)
Memory: 127744k available (1556k kernel code, 384k data, 100k init, 0k
highmem)
Mount-cache hash table entries: 512
softlockup thread 0 started up.
NET: Registered protocol family 16
Generic RTC Driver v1.07
Serial: CPM driver $Revision: 0.01 $
ttyCPM0 at MMIO 0xf0011a80 (irq =3D 4) is a CPM UART
ttyCPM1 at MMIO 0xf0011a90 (irq =3D 5) is a CPM UART
ttyCPM2 at MMIO 0xf0011a00 (irq =3D 40) is a CPM UART
ttyCPM3 at MMIO 0xf0011a20 (irq =3D 41) is a CPM UART
ttyCPM4 at MMIO 0xf0011a40 (irq =3D 42) is a CPM UART
ttyCPM5 at MMIO 0xf0011a60 (irq =3D 43) is a CPM UART=20
io scheduler noop registered=20
io scheduler anticipatory registered=20
io scheduler deadline registered=20
io scheduler cfq registered=20
RAMDISK driver initialized: 16 RAM disks of 4096K size 1024 blocksize=20
NFTL driver: nftlcore.c $Revision: 1.97 $, nftlmount.c $Revision: 1.40 $
Oops: kernel access of bad area, sig: 11 [#1]
NIP: C0107A14 LR: C0106660 SP: C036FE30 REGS: c036fd80 TRAP: 0300 Not
tainted
MSR: 00003032 EE: 0 PR: 0 FP: 1 ME: 1 IR/DR: 11
DAR: 00000000, DSISR: 20000000
TASK =3D c0349ae0[1] 'swapper' THREAD: c036e000 Last syscall: 120
GPR00: C036FE38 C036FE30 C0349AE0 C7CD5EE0 C036FE68 00002AA8 C9002AA8
00AA00AA
GPR08: 00AA00AA C036FE40 00009032 00001032 00AA00AA FFFDFFB7 07FFC000
00000001
GPR16: 00800000 07FFF7BC C0180000 00000000 07FF9484 00000000 07FAE1C0
00000001
GPR24: C036FE58 00000000 C7CD5EE0 C01F0000 C7CD5EE0 C01C4BF4 C036FF18
C036FE68
Call trace: [0000000d] [c0106104] [c010637c] [c01011ec] [c01e1ed4]
[c00039e8] [c0006b84] Kernel panic - not syncing: Attempted to kill
init!
<0>Rebooting in 1 seconds..=20
^ permalink raw reply
* Re: [Alsa-devel] [RFC 4/7] snd-aoa: add codecs
From: Takashi Iwai @ 2006-05-30 13:19 UTC (permalink / raw)
To: Johannes Berg; +Cc: linuxppc-dev, alsa-devel
In-Reply-To: <1148992996.3102.8.camel@johannes>
At Tue, 30 May 2006 14:43:16 +0200,
Johannes Berg wrote:
>
> On Mon, 2006-05-29 at 14:08 +0200, Takashi Iwai wrote:
> > > + 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" ?
>
> Nah, look at the first line I quoted :)
Ah, OK it's anyway same...
> > > + /* 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).
>
> Does it have to? This way there's an event, but...
Yes, in principle. As mentioned, it works even without the check,
though.
> > > +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[]
>
> Any particular reason?
Well, I meant the position of asterisk to follow the conventional C
coding style. Of course it should be static.
> > > + aoa_snd_ctl_add(snd_ctl_new1(&volume_control, tas));
> >
> > Error checks please.
>
> What should it do on such errors?
The driver should give up the initialization and fail to load.
Usually the error from snd_ctl_add() is critical, either no memory or
a duplicated control element is found.
Takashi
^ permalink raw reply
* Re: [Alsa-devel] [RFC 2/7] snd-aoa: add aoa core
From: Takashi Iwai @ 2006-05-30 13:20 UTC (permalink / raw)
To: Johannes Berg; +Cc: linuxppc-dev, alsa-devel
In-Reply-To: <1148993072.3102.10.camel@johannes>
At Tue, 30 May 2006 14:44:31 +0200,
Johannes Berg wrote:
>
> On Mon, 2006-05-29 at 12:57 +0200, Takashi Iwai wrote:
> > > + 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.
>
> Are you saying I should add an index module option and pass that?
Yep, all other drivers do so.
Takashi
^ permalink raw reply
* Re: [Alsa-devel] [RFC 4/7] snd-aoa: add codecs
From: Johannes Berg @ 2006-05-30 13:26 UTC (permalink / raw)
To: Takashi Iwai; +Cc: linuxppc-dev, alsa-devel
In-Reply-To: <s5hr72bbqfm.wl%tiwai@suse.de>
[-- Attachment #1: Type: text/plain, Size: 1035 bytes --]
> > > > + return 1;
> > >
> > > The put callback is supposed to return 0 if the values are unchanged
> > > (although most apps ignore the return value).
> >
> > Does it have to? This way there's an event, but...
>
> Yes, in principle. As mentioned, it works even without the check,
> though.
Hmm. I thought it worked like this:
0 -> no change
1 -> change applied, and other apps are notified, 0 returned to the app
-err -> error returned to app
Is that wrong?
> Well, I meant the position of asterisk to follow the conventional C
> coding style. Of course it should be static.
Ah. Yeah, I'll see to that and probably just Lindent the files (cleaning
up after it...)
> The driver should give up the initialization and fail to load.
> Usually the error from snd_ctl_add() is critical, either no memory or
> a duplicated control element is found.
Hmm, that's a bit hard to do since the driver here consists of more than
one module, but I suppose I can do something about it.
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 793 bytes --]
^ permalink raw reply
* Re: fs_enet segfaults when adding network interface to bridge
From: Vitaly Bordug @ 2006-05-30 13:27 UTC (permalink / raw)
To: Laurent Pinchart; +Cc: linuxppc-embedded
In-Reply-To: <200605301351.11967.laurent.pinchart@tbox.biz>
On Tue, 30 May 2006 13:51:11 +0200
Laurent Pinchart <laurent.pinchart@tbox.biz> wrote:
> Hi everybody,
>
> I ran into a segfault in the fs_enet driver when adding the network interface
> to an ethernet bridge. This only happens when the interface is down.
>
> ----- Kernel version -----
> Linux tbox-cp11 2.6.17-rc3-g7f02f290-dirty #549 Tue May 30 13:25:37 CEST 2006
> ppc unknown
> (from main linux-2.6 git repository)
> ----- End of kernel version -----
>
> ----- Oops report -----
> Oops: kernel access of bad area, sig: 11 [#1]
> NIP: C0109884 LR: C010D420 CTR: 00000000
> REGS: c027d7f0 TRAP: 0300 Tainted: P (2.6.17-rc3-g7f02f290-dirty)
> MSR: 00009032 <EE,ME,IR,DR> CR: 24000222 XER: 00000000
> DAR: 00000140, DSISR: 20000000
> TASK = c0851090[42] 'brctl' THREAD: c027c000
> GPR00: C010D414 C027D8A0 C0851090 00000000 C027D8D0 FFFFFFFF F00000A0 EFFFFFFF
> GPR08: C026E380 C0210000 00000000 C0230000 C0210000 1001D150 00FFE000 00000001
> GPR16: FFFFFFFF 00000000 007FFF00 7FDD0AC0 00000000 10072C94 7FDD0AD8 10072CA4
> GPR24: 00000000 10000A48 00000000 C027D8D0 C027D8D0 C08A1A60 C027DC50 C08A1800
> NIP [C0109884] phy_ethtool_gset+0x0/0x48
> LR [C010D420] fs_get_settings+0x34/0x48
> Call Trace:
> [C027D8A0] [C010D414] fs_get_settings+0x28/0x48 (unreliable)
> [C027D8C0] [C013DDC0] dev_ethtool+0x9bc/0x13c8
> [C027DC40] [C018CBC0] port_cost+0x58/0x108
> [C027DCB0] [C018D3E8] br_add_if+0x174/0x2f4
> [C027DCE0] [C018D9AC] add_del_if+0x94/0x98
> [C027DD00] [C018DD68] br_dev_ioctl+0x70/0xae4
> [C027DE00] [C013B42C] dev_ifsioc+0x17c/0x404
> [C027DE20] [C013BA4C] dev_ioctl+0x398/0x4e8
> [C027DEB0] [C012EEFC] sock_ioctl+0x154/0x220
> [C027DEE0] [C0067164] do_ioctl+0x88/0x9c
> [C027DEF0] [C0067230] vfs_ioctl+0xb8/0x3f0
> [C027DF10] [C00675A8] sys_ioctl+0x40/0x74
> [C027DF40] [C00040E0] ret_from_syscall+0x0/0x38
> Instruction dump:
> 7c0803a6 4e800020 2f800000 409eff78 4bffffb8 8804000e 2b800001 40bdff70
> 3860ffea 4bffffd4 61200040 4bffff84 <81230140> 91240004 80030144 90040008
> ----- End of oops report -----
>
> ----- Source lines -----
> [C0109884] phy_ethtool_gset+0x0/0x48 (drivers/net/phy/phy.c:290)
> [C010D414] fs_get_settings+0x28/0x48 (drivers/net/fs_enet/fs_enet-main.c:885)
> [C013DDC0] dev_ethtool+0x9bc/0x13c8 (net/core/ethtool.c:122)
> [C018CBC0] port_cost+0x58/0x108 (net/bridge/br_if.c:54)
> ----- End of source lines -----
>
> phy_ethtool_gset segfaults when trying to access phydev->supported because
> phydev is NULL.
>
> As I'm not familiar with the fs_enet driver, I'm looking for advices regarding
> what to fix and how to fix it.
>
IIRC, fs_enet got bound to phydev only being ->up. So in down state, phydev may be either null, or last assigned (need to have a look into source to tell for certain). So what is the proper behavior from your point of view?
--
Sincerely,
Vitaly
^ permalink raw reply
* Re: [Alsa-devel] [RFC 4/7] snd-aoa: add codecs
From: Takashi Iwai @ 2006-05-30 13:35 UTC (permalink / raw)
To: Johannes Berg; +Cc: linuxppc-dev, alsa-devel
In-Reply-To: <1148995575.4372.5.camel@johannes>
At Tue, 30 May 2006 15:26:10 +0200,
Johannes Berg wrote:
>
> > > > > + return 1;
> > > >
> > > > The put callback is supposed to return 0 if the values are unchanged
> > > > (although most apps ignore the return value).
> > >
> > > Does it have to? This way there's an event, but...
> >
> > Yes, in principle. As mentioned, it works even without the check,
> > though.
>
> Hmm. I thought it worked like this:
> 0 -> no change
> 1 -> change applied, and other apps are notified, 0 returned to the app
> -err -> error returned to app
>
> Is that wrong?
It's correct.
And I thought the put callbacks in your code always return either 1 or
-err?
Takashi
^ permalink raw reply
* Re: fs_enet segfaults when adding network interface to bridge
From: Laurent Pinchart @ 2006-05-30 13:39 UTC (permalink / raw)
To: Vitaly Bordug; +Cc: linuxppc-embedded
In-Reply-To: <20060530172700.198bba36@vitb.ru.mvista.com>
> > Hi everybody,
> >
> > I ran into a segfault in the fs_enet driver when adding the network
> > interface to an ethernet bridge. This only happens when the interface is
> > down.
> >
> > ----- Kernel version -----
> > Linux tbox-cp11 2.6.17-rc3-g7f02f290-dirty #549 Tue May 30 13:25:37 CEST
> > 2006 ppc unknown
> > (from main linux-2.6 git repository)
> > ----- End of kernel version -----
> >
> > ----- Oops report -----
> > Oops: kernel access of bad area, sig: 11 [#1]
> > NIP: C0109884 LR: C010D420 CTR: 00000000
> > REGS: c027d7f0 TRAP: 0300 Tainted: P (2.6.17-rc3-g7f02f290-dirty)
> > MSR: 00009032 <EE,ME,IR,DR> CR: 24000222 XER: 00000000
> > DAR: 00000140, DSISR: 20000000
> > TASK = c0851090[42] 'brctl' THREAD: c027c000
> > GPR00: C010D414 C027D8A0 C0851090 00000000 C027D8D0 FFFFFFFF F00000A0
> > EFFFFFFF GPR08: C026E380 C0210000 00000000 C0230000 C0210000 1001D150
> > 00FFE000 00000001 GPR16: FFFFFFFF 00000000 007FFF00 7FDD0AC0 00000000
> > 10072C94 7FDD0AD8 10072CA4 GPR24: 00000000 10000A48 00000000 C027D8D0
> > C027D8D0 C08A1A60 C027DC50 C08A1800 NIP [C0109884]
> > phy_ethtool_gset+0x0/0x48
> > LR [C010D420] fs_get_settings+0x34/0x48
> > Call Trace:
> > [C027D8A0] [C010D414] fs_get_settings+0x28/0x48 (unreliable)
> > [C027D8C0] [C013DDC0] dev_ethtool+0x9bc/0x13c8
> > [C027DC40] [C018CBC0] port_cost+0x58/0x108
> > [C027DCB0] [C018D3E8] br_add_if+0x174/0x2f4
> > [C027DCE0] [C018D9AC] add_del_if+0x94/0x98
> > [C027DD00] [C018DD68] br_dev_ioctl+0x70/0xae4
> > [C027DE00] [C013B42C] dev_ifsioc+0x17c/0x404
> > [C027DE20] [C013BA4C] dev_ioctl+0x398/0x4e8
> > [C027DEB0] [C012EEFC] sock_ioctl+0x154/0x220
> > [C027DEE0] [C0067164] do_ioctl+0x88/0x9c
> > [C027DEF0] [C0067230] vfs_ioctl+0xb8/0x3f0
> > [C027DF10] [C00675A8] sys_ioctl+0x40/0x74
> > [C027DF40] [C00040E0] ret_from_syscall+0x0/0x38
> > Instruction dump:
> > 7c0803a6 4e800020 2f800000 409eff78 4bffffb8 8804000e 2b800001 40bdff70
> > 3860ffea 4bffffd4 61200040 4bffff84 <81230140> 91240004 80030144 90040008
> > ----- End of oops report -----
> >
> > ----- Source lines -----
> > [C0109884] phy_ethtool_gset+0x0/0x48 (drivers/net/phy/phy.c:290)
> > [C010D414] fs_get_settings+0x28/0x48
> > (drivers/net/fs_enet/fs_enet-main.c:885) [C013DDC0]
> > dev_ethtool+0x9bc/0x13c8 (net/core/ethtool.c:122)
> > [C018CBC0] port_cost+0x58/0x108 (net/bridge/br_if.c:54)
> > ----- End of source lines -----
> >
> > phy_ethtool_gset segfaults when trying to access phydev->supported
> > because phydev is NULL.
> >
> > As I'm not familiar with the fs_enet driver, I'm looking for advices
> > regarding what to fix and how to fix it.
>
> IIRC, fs_enet got bound to phydev only being ->up. So in down state, phydev
> may be either null, or last assigned (need to have a look into source to
> tell for certain). So what is the proper behavior from your point of view?
I have no idea :-) What I know is that the driver should not segfault when
asked to report the port speed. Either we should return an error or have the
phy device bound to fs_enet at all time. It might also be a bridge issue,
maybe the bridge code should turn the interface up before reading its speed.
How do other ethernet drivers proceed ?
Laurent Pinchart
^ permalink raw reply
* Re: [Alsa-devel] [RFC 4/7] snd-aoa: add codecs
From: Johannes Berg @ 2006-05-30 13:39 UTC (permalink / raw)
To: Takashi Iwai; +Cc: linuxppc-dev, alsa-devel
In-Reply-To: <s5hmzczbpps.wl%tiwai@suse.de>
[-- Attachment #1: Type: text/plain, Size: 394 bytes --]
On Tue, 2006-05-30 at 15:35 +0200, Takashi Iwai wrote:
> And I thought the put callbacks in your code always return either 1 or
> -err?
Yeah, they return 1 if the change was applied (or no change) and -err if
there's an error about the change (only in very few cases).
I figured the extra notification wouldn't hurt, and to the application
there wouldn't be a problem.
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 793 bytes --]
^ permalink raw reply
* Re: [Alsa-devel] [RFC 4/7] snd-aoa: add codecs
From: Takashi Iwai @ 2006-05-30 13:48 UTC (permalink / raw)
To: Johannes Berg; +Cc: linuxppc-dev, alsa-devel
In-Reply-To: <1148996349.4372.7.camel@johannes>
At Tue, 30 May 2006 15:39:09 +0200,
Johannes Berg wrote:
>
> On Tue, 2006-05-30 at 15:35 +0200, Takashi Iwai wrote:
>
> > And I thought the put callbacks in your code always return either 1 or
> > -err?
>
> Yeah, they return 1 if the change was applied (or no change) and -err if
> there's an error about the change (only in very few cases).
>
> I figured the extra notification wouldn't hurt, and to the application
> there wouldn't be a problem.
Actually the extra notification won't hurt much in practice.
I've seen that some drivers also don't check the unchanged case and
return always 1, so apparently the apps work. But, it's of course
better to check the state on the driver side.
Takashi
^ permalink raw reply
* Re: [patch] fix RTC/NVRAM accesses on Maple
From: jfaslist @ 2006-05-30 13:49 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: linuxppc-dev
In-Reply-To: <ecea6f4aafae5a453662340020d4cc88@kernel.crashing.org>
> Hollis' latest patch is needed still. We agreed not to solve it
> completely correctly yet, as we'll need more surgery in other parts
> of the PowerPC kernel first.
>
> Segher
>
I am trying to apply it on a 2.6.16.18 kernel but the two hunks of it
are rejected. Any specific version to use?
Thanks,
-jfs
___________________________________________________________________________
Yahoo! Mail réinvente le mail ! Découvrez le nouveau Yahoo! Mail et son interface révolutionnaire.
http://fr.mail.yahoo.com
^ permalink raw reply
* Re: [Alsa-devel] [RFC 4/7] snd-aoa: add codecs
From: Johannes Berg @ 2006-05-30 13:53 UTC (permalink / raw)
To: Takashi Iwai; +Cc: linuxppc-dev, alsa-devel
In-Reply-To: <s5hpshvfwta.wl%tiwai@suse.de>
[-- Attachment #1: Type: text/plain, Size: 581 bytes --]
On Tue, 2006-05-30 at 15:48 +0200, Takashi Iwai wrote:
> Actually the extra notification won't hurt much in practice.
> I've seen that some drivers also don't check the unchanged case and
> return always 1, so apparently the apps work. But, it's of course
> better to check the state on the driver side.
Yeah, agreed. I'll fix it.
How about making alsamixer actually handle the error cases? In the onyx
codec, there's some things that prohibit changing the s/pdif output if
you dno't use a bitrate that can handle, but alsamixer 'changes' it
anyway...
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 793 bytes --]
^ permalink raw reply
* Re: [RFC/PATCH 0/8] Overhaul of virt IRQ configuration. / Kill ppc64_interrupt_controller.
From: Michal Ostrowski @ 2006-05-30 13:54 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev
In-Reply-To: <1148938117.5959.24.camel@localhost.localdomain>
On Tue, 2006-05-30 at 07:28 +1000, Benjamin Herrenschmidt wrote:
> Hi ! Interesting.. I've start looking at reworking that with a slightly
> different approach though...
>
> We need irq controller instances (which we get from the genirq patch
> from Ingo & Thomas Gleixner), and we decided that interrupt controller
> nodes are mandatory in the device-tree thus we can do something like:
>
The genirq patches were not available until this morning, but now that
I've got them here are some more thought as to what can be done.
> - Each interrupt controller instance, when allocated, requests a certain
> number of interrupts and gets that allocated (gets an offset allocated).
> It can locally use the virtual irq remapping too, I'm still toying with
> the best way to deal with that. This interrupt controller structure is
> associated to the device-node of the controller (or the root node of the
> tree if no controller node is found)
A PIC would not need to reserve anything is when it is allocated. Only
when interrupt numbers need to be presented to generic kernel code is a
virq number required.
One can use irq_desc->chip_data to easily go from virq -> (PIC, line).
The PIC then maintains an array to map each of it's lines to virq.
This allows for all re-mappings to always be arbitrary in nature and
still allows for O(1) look-up in either direction.
>
> - Interrupt 0..15 are reserved. 0 is always invalid. Only ISA PICs that
> carry legacy devices can request those (by passing a special flag to the
> allocation routine).
Always create an ISA PIC that immediately requests lines 0..15.
Should one actually exists, we can associate the ISA PIC with the
appropriate device node. Should ISA devices exist, once they request
interrupts (using (PIC,line) as arguments) we'll short-circuit virq
allocation since all ISA PIC mappings already exists.
Then there's no need to special case anything (and all other interrupts
are forced to be remapped out of the 0..15 range, without an explicit
"offset" concept).
> Any other gets remapped (including powermac MPICs).
> That will avoid endless problems that we never properly solved with
> legacy drivers and the fact that Linus decided that 0 should be the
> invalid interrupt number on all platforms
>
> - Provide in prom_parse.c functions for obtaining the PIC node and
> local interrupt number of a given device based on a passed-in array
> matching the semantics of an "interrupts" property and a parent node.
> Along with a helper that may just take a child node. The former is
> needed for PCI devices that have no device node. Provide a
> pci_ppc_map_interrupt() that takes a pci_dev and does the interrupt
> mapping, either by using the standard OF approach if a device-node is
> present, or walking up the PCI tree while doing standard swizzling until
> it reaches a device node
How is this different from the current use of map_interrupt() in
finish_node_interrupts()?
It seems to me that it would be better to have the struct device_node
store the raw interrupt vector data as presented in the dev tree
(without remapping) along with a pointer to the struct device_node for
the appropriate PIC.
Later on, when we need to provide interrupt lines to the PCI device
structures (e.g. pci_read_irq_line()) we have the PIC and the raw
interrupt vectors identified and we ask the PIC to provide us with a
kernel/virt IRQ.
Deferring the remapping of the interrupt vectors to this later time
should allow for some simplification opportunities. All code that
handles device nodes would not need to deal with offsets or remapping,
only when IRQ information crosses the boundary between powerpc and
generic code would one need to be aware of the need to re-map (i.e.
dev->irq = ??? and ppc_md.get_irq(regs);/ __do_IRQ() interactions ).
Since arbitrary re-mappings need to be supported, the reservation of
vectors 0..15 can be hidden as a re-mapping implementation detail.
Consequently one could eliminate irq_offset_up() and irq_offset_down()
altogether.
--
Michal Ostrowski <mostrows@watson.ibm.com>
^ permalink raw reply
* Re: [Alsa-devel] [RFC 4/7] snd-aoa: add codecs
From: Takashi Iwai @ 2006-05-30 13:56 UTC (permalink / raw)
To: Johannes Berg; +Cc: linuxppc-dev, alsa-devel
In-Reply-To: <1148997206.4372.13.camel@johannes>
At Tue, 30 May 2006 15:53:25 +0200,
Johannes Berg wrote:
>
> On Tue, 2006-05-30 at 15:48 +0200, Takashi Iwai wrote:
>
> > Actually the extra notification won't hurt much in practice.
> > I've seen that some drivers also don't check the unchanged case and
> > return always 1, so apparently the apps work. But, it's of course
> > better to check the state on the driver side.
>
> Yeah, agreed. I'll fix it.
>
> How about making alsamixer actually handle the error cases? In the onyx
> codec, there's some things that prohibit changing the s/pdif output if
> you dno't use a bitrate that can handle, but alsamixer 'changes' it
> anyway...
Oh, it should be called as a "bug"... ;)
Takashi
^ permalink raw reply
* regarding mvme6100 on kernel 2.6.13
From: Kiran Kumar.A @ 2006-05-30 14:09 UTC (permalink / raw)
To: linuxppc-embedded
Hi all,
I'm porting mvme6100 for 2.6.13.=20
But its hanging after "Now Booting the kernel.."
Can anybody guide me in this regard.
thanks and regards
--=20
_______________________________________________
Search for businesses by name, location, or phone number. -Lycos Yellow Pa=
ges
http://r.lycos.com/r/yp_emailfooter/http://yellowpages.lycos.com/default.as=
p?SRC=3Dlycos10
^ permalink raw reply
* Re: [SOLVED] LXT973 support (dual PHY with single MDIO)
From: Vitaly Bordug @ 2006-05-30 14:22 UTC (permalink / raw)
To: Laurent Pinchart; +Cc: linuxppc-embedded
In-Reply-To: <200605301128.48580.laurent.pinchart@tbox.biz>
On Tue, 30 May 2006 11:28:48 +0200
Laurent Pinchart <laurent.pinchart@tbox.biz> wrote:
> Hi,
>
> once again, posting to a mailing list helped me solving my problem. It should
> have been obvious that the MDIO bus is really a bus, and can as such support
> several devices. The issue was that the drivers/net/fs_enet driver set
> bus->phy_mask to ~0x9, and the LXT973 uses addresses 0 and 1. Address 1 thus
> never got probed. What's the reason for probing addresses 0 and 3 only ?
The reason is obvious: bitbang read of PHY id with not-existent PHY, does not return expected (0, iirc), that confuse mdio bus device-driver bound (it assumes error and returns -1), and prevents from probing other phys. So, as that seems to be a "feature" on CPM2 only, we are working that around specifying phy_mask to prevent probing inexistent phys w/over bitbang thing.
--
Sincerely,
Vitaly
^ permalink raw reply
* Re: regarding mvme6100 on kernel 2.6.13
From: Brent Cook @ 2006-05-30 15:12 UTC (permalink / raw)
To: linuxppc-embedded; +Cc: Kiran Kumar.A
In-Reply-To: <20060530140929.88FBD3384B@ws7-3.us4.outblaze.com>
On Tuesday 30 May 2006 09:09, Kiran Kumar.A wrote:
> Hi all,
>
> I'm porting mvme6100 for 2.6.13.
> But its hanging after "Now Booting the kernel.."
>
> Can anybody guide me in this regard.
>
> thanks and regards
Eh, it's probably not hanging at all - you're just not seeing anything because
the device naming scheme changed and the serial console not getting
initialized correctly. Be sure that in your platform_notify function has
a '.' in the platform device name - this was added around 2.6.11 or so.
An example from another board I have:
static int xes_mv64x60_platform_notify(struct device *dev)
{
static struct {
char *bus_id;
void ((*rtn) (struct platform_device * pdev));
} dev_map[] = {
#ifdef CONFIG_SERIAL_MPSC
{
MPSC_CTLR_NAME ".0", xes_mv64x60_fixup_mpsc_pdata}, {
MPSC_CTLR_NAME ".1", xes_mv64x60_fixup_mpsc_pdata},
#endif
}
Also, be sure to enable early boot messages - they help a lot. Also, don't
overlook setting console=ttyMM0,9600 in the kernel args.
- Brent
^ permalink raw reply
* Re: Setting I&D cache enable in the same mtspr instruction
From: Mark A. Greer @ 2006-05-30 18:27 UTC (permalink / raw)
To: Roger Larsson; +Cc: linuxppc-embedded
In-Reply-To: <200605291415.14908.roger.larsson@norran.net>
On Mon, May 29, 2006 at 02:15:14PM +0200, Roger Larsson wrote:
> Is the patch reversed?
Sure looks like it.
> 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).
Good point.
> /RogerL
Also, please send the patches *inline*.
Mark
^ permalink raw reply
* [PATCH] fix of_parse_dma_window. was: Re: [PATCH 1/2] powerpc: Add of_parse_dma_window()
From: Will Schmidt @ 2006-05-30 18:38 UTC (permalink / raw)
To: Olof Johansson, jk; +Cc: linuxppc-dev, paulus
In-Reply-To: <20060518231306.GG8220@pb15.lixom.net>
On Thu, 2006-05-18 at 18:13 -0500, Olof Johansson wrote:
> On Fri, May 19, 2006 at 01:11:51AM +0200, Segher Boessenkool wrote:
> > > Acked-by: Olof Johansson <olof@lixom.net>
> > >
> > > (I'm assuming you've booted it on POWER4 LPAR and JS20, I don't
> > > have access to either to make sure it doesn't break there. Main worry
> > > would be if it lacked ibm,#dma*-properties for some reason.)
> >
> > The code seems to be resilient against that. Haven't tested though.
>
> Well, yes. I should have said: if it lacks the ibm,#dma- and the
> normal addr-cells properties aren't the same as we assumed before.
My js20 appears to lack the ibm,#dma- properties, and boot fails with a
"Kernel panic - not syncing: iommu_init_table: Can't allocate 0 bytes"
message.
This adds a fallback to the "#address-cells" property in case the
"#ibm,dma-address-cells" property is missing. Tested on js20 and
power5 lpar.
Unless there is a more elegant solution... :-)
Signed-off-by: Will Schmidt <willschm@us.ibm.com>
diff --git a/arch/powerpc/kernel/prom_parse.c b/arch/powerpc/kernel/prom_parse.c
index 23bb060..45df420 100644
--- a/arch/powerpc/kernel/prom_parse.c
+++ b/arch/powerpc/kernel/prom_parse.c
@@ -561,6 +561,9 @@ void of_parse_dma_window(struct device_n
*busno = *(dma_window++);
prop = get_property(dn, "ibm,#dma-address-cells", NULL);
+ if (!prop)
+ prop = get_property(dn, "#address-cells", NULL);
+
cells = prop ? *(u32 *)prop : prom_n_addr_cells(dn);
*phys = of_read_addr(dma_window, cells);
^ permalink raw reply related
* Re: [PATCH 1/2] powerpc: Add of_parse_dma_window()
From: Kumar Gala @ 2006-05-30 18:55 UTC (permalink / raw)
To: Jeremy Kerr; +Cc: linuxppc-dev
In-Reply-To: <1147933251.463191.267166640873.qpush@pokey>
On May 18, 2006, at 1:20 AM, Jeremy Kerr wrote:
> Add a function for generic parsing of dma-window properties (ie,
> ibm,dma-window and ibm,my-dma-window) of pci and virtual device nodes.
>
> This function will also be used by cell.
Any possibly of renaming this to of_parse_ibm_dma_window() since it
handle an IBM specific attribute?
- kumar
>
> Signed-off-by: Jeremy Kerr <jk@ozlabs.org>
>
> arch/powerpc/kernel/prom_parse.c | 23 +++++++++++++++++++++++
> include/asm-powerpc/prom.h | 6 ++++++
> 2 files changed, 29 insertions(+)
>
> Index: linux-2.6/arch/powerpc/kernel/prom_parse.c
> ===================================================================
> --- linux-2.6.orig/arch/powerpc/kernel/prom_parse.c
> +++ linux-2.6/arch/powerpc/kernel/prom_parse.c
> @@ -548,3 +548,26 @@ int of_pci_address_to_resource(struct de
> return __of_address_to_resource(dev, addrp, size, flags, r);
> }
> EXPORT_SYMBOL_GPL(of_pci_address_to_resource);
> +
> +void of_parse_dma_window(struct device_node *dn, unsigned char
> *dma_window_prop,
> + unsigned long *busno, unsigned long *phys, unsigned long *size)
> +{
> + u32 *dma_window, cells;
> + unsigned char *prop;
> +
> + dma_window = (u32 *)dma_window_prop;
> +
> + /* busno is always one cell */
> + *busno = *(dma_window++);
> +
> + prop = get_property(dn, "ibm,#dma-address-cells", NULL);
> + cells = prop ? *(u32 *)prop : prom_n_addr_cells(dn);
> + *phys = of_read_addr(dma_window, cells);
> +
> + dma_window += cells;
> +
> + prop = get_property(dn, "ibm,#dma-size-cells", NULL);
> + cells = prop ? *(u32 *)prop : prom_n_size_cells(dn);
> + *size = of_read_addr(dma_window, cells);
> +}
> +EXPORT_SYMBOL_GPL(of_parse_dma_window);
> Index: linux-2.6/include/asm-powerpc/prom.h
> ===================================================================
> --- linux-2.6.orig/include/asm-powerpc/prom.h
> +++ linux-2.6/include/asm-powerpc/prom.h
> @@ -230,6 +230,12 @@ extern int of_address_to_resource(struct
> extern int of_pci_address_to_resource(struct device_node *dev, int
> bar,
> struct resource *r);
>
> +/* Parse the ibm,dma-window property of an OF node into the busno,
> phys and
> + * size parameters.
> + */
> +void of_parse_dma_window(struct device_node *dn, unsigned char
> *dma_window_prop,
> + unsigned long *busno, unsigned long *phys, unsigned long *size);
> +
> extern void kdump_move_device_tree(void);
>
> #endif /* __KERNEL__ */
>
> To: linuxppc-dev@ozlabs.org
> From: Jeremy Kerr <jk@ozlabs.org>
> Date: Thu, 18 May 2006 16:20:51 +1000
> Subject: [PATCH 2/2] powerpc: pseries: Use generic dma-window
> parsing function
> Message-Id: <1147933251.472945.297063284077.qpush@pokey>
>
> Change the pseries iommu init code to use the new
> of_parse_dma_window()
> to parse the ibm,dma-window and ibm,my-dma-window properties of pci
> and
> virtual device nodes.
>
> Also, clean up vio_build_iommu_table() a little.
>
> Tested on pseries, with both vio and pci devices.
>
> Signed-off-by: Jeremy Kerr <jk@ozlabs.org>
>
> arch/powerpc/platforms/pseries/iommu.c | 29 +++++++++
> +-------------------
> arch/powerpc/platforms/pseries/vio.c | 32 +++++++++++++
> +------------------
> 2 files changed, 24 insertions(+), 37 deletions(-)
>
> Index: linux-2.6/arch/powerpc/platforms/pseries/iommu.c
> ===================================================================
> --- linux-2.6.orig/arch/powerpc/platforms/pseries/iommu.c
> +++ linux-2.6/arch/powerpc/platforms/pseries/iommu.c
> @@ -299,30 +299,22 @@ static void iommu_table_setparms(struct
> * iommu_table_setparms_lpar
> *
> * Function: On pSeries LPAR systems, return TCE table info, given
> a pci bus.
> - *
> - * ToDo: properly interpret the ibm,dma-window property. The
> definition is:
> - * logical-bus-number (1 word)
> - * phys-address (#address-cells words)
> - * size (#cell-size words)
> - *
> - * Currently we hard code these sizes (more or less).
> */
> static void iommu_table_setparms_lpar(struct pci_controller *phb,
> struct device_node *dn,
> struct iommu_table *tbl,
> - unsigned int *dma_window)
> + unsigned char *dma_window)
> {
> + unsigned long offset, size;
> +
> tbl->it_busno = PCI_DN(dn)->bussubno;
> + of_parse_dma_window(dn, dma_window, &tbl->it_index, &offset, &size);
>
> - /* TODO: Parse field size properties properly. */
> - tbl->it_size = (((unsigned long)dma_window[4] << 32) |
> - (unsigned long)dma_window[5]) >> PAGE_SHIFT;
> - tbl->it_offset = (((unsigned long)dma_window[2] << 32) |
> - (unsigned long)dma_window[3]) >> PAGE_SHIFT;
> tbl->it_base = 0;
> - tbl->it_index = dma_window[0];
> tbl->it_blocksize = 16;
> tbl->it_type = TCE_PCI;
> + tbl->it_offset = offset >> PAGE_SHIFT;
> + tbl->it_size = size >> PAGE_SHIFT;
> }
>
> static void iommu_bus_setup_pSeries(struct pci_bus *bus)
> @@ -414,7 +406,7 @@ static void iommu_bus_setup_pSeriesLP(st
> struct iommu_table *tbl;
> struct device_node *dn, *pdn;
> struct pci_dn *ppci;
> - unsigned int *dma_window = NULL;
> + unsigned char *dma_window = NULL;
>
> DBG("iommu_bus_setup_pSeriesLP, bus %p, bus->self %p\n", bus, bus-
> >self);
>
> @@ -422,7 +414,7 @@ static void iommu_bus_setup_pSeriesLP(st
>
> /* Find nearest ibm,dma-window, walking up the device tree */
> for (pdn = dn; pdn != NULL; pdn = pdn->parent) {
> - dma_window = (unsigned int *)get_property(pdn, "ibm,dma-window",
> NULL);
> + dma_window = get_property(pdn, "ibm,dma-window", NULL);
> if (dma_window != NULL)
> break;
> }
> @@ -516,7 +508,7 @@ static void iommu_dev_setup_pSeriesLP(st
> {
> struct device_node *pdn, *dn;
> struct iommu_table *tbl;
> - int *dma_window = NULL;
> + unsigned char *dma_window = NULL;
> struct pci_dn *pci;
>
> DBG("iommu_dev_setup_pSeriesLP, dev %p (%s)\n", dev, pci_name(dev));
> @@ -531,8 +523,7 @@ static void iommu_dev_setup_pSeriesLP(st
>
> for (pdn = dn; pdn && PCI_DN(pdn) && !PCI_DN(pdn)->iommu_table;
> pdn = pdn->parent) {
> - dma_window = (unsigned int *)
> - get_property(pdn, "ibm,dma-window", NULL);
> + dma_window = get_property(pdn, "ibm,dma-window", NULL);
> if (dma_window)
> break;
> }
> Index: linux-2.6/arch/powerpc/platforms/pseries/vio.c
> ===================================================================
> --- linux-2.6.orig/arch/powerpc/platforms/pseries/vio.c
> +++ linux-2.6/arch/powerpc/platforms/pseries/vio.c
> @@ -108,32 +108,28 @@ __initcall(vio_bus_init_pseries);
> */
> static struct iommu_table *vio_build_iommu_table(struct vio_dev *dev)
> {
> - unsigned int *dma_window;
> - struct iommu_table *newTceTable;
> - unsigned long offset;
> - int dma_window_property_size;
> + unsigned char *dma_window;
> + struct iommu_table *tbl;
> + unsigned long offset, size;
>
> - dma_window = (unsigned int *) get_property(dev-
> >dev.platform_data, "ibm,my-dma-window", &dma_window_property_size);
> - if(!dma_window) {
> + dma_window = get_property(dev->dev.platform_data,
> + "ibm,my-dma-window", NULL);
> + if (!dma_window)
> return NULL;
> - }
>
> - newTceTable = (struct iommu_table *) kmalloc(sizeof(struct
> iommu_table), GFP_KERNEL);
> + tbl = (struct iommu_table *)kmalloc(sizeof(*tbl), GFP_KERNEL);
>
> - /* There should be some code to extract the phys-encoded offset
> - using prom_n_addr_cells(). However, according to a comment
> - on earlier versions, it's always zero, so we don't bother */
> - offset = dma_window[1] >> PAGE_SHIFT;
> + of_parse_dma_window(dev->dev.platform_data, dma_window,
> + &tbl->it_index, &offset, &size);
>
> /* TCE table size - measured in tce entries */
> - newTceTable->it_size = dma_window[4] >> PAGE_SHIFT;
> + tbl->it_size = size >> PAGE_SHIFT;
> /* offset for VIO should always be 0 */
> - newTceTable->it_offset = offset;
> - newTceTable->it_busno = 0;
> - newTceTable->it_index = (unsigned long)dma_window[0];
> - newTceTable->it_type = TCE_VB;
> + tbl->it_offset = offset >> PAGE_SHIFT;
> + tbl->it_busno = 0;
> + tbl->it_type = TCE_VB;
>
> - return iommu_init_table(newTceTable);
> + return iommu_init_table(tbl);
> }
>
> /**
>
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
^ permalink raw reply
* Re: [PATCH/2.6.17-rc4 4/10]Powerpc: Add tsi108 pic support
From: Kumar Gala @ 2006-05-30 19:18 UTC (permalink / raw)
To: Zang Roy-r61911
Cc: Yang Xin-Xin-r48390, Paul Mackerras, Alexandre.Bounine,
linuxppc-dev list
In-Reply-To: <9FCDBA58F226D911B202000BDBAD467306585F22@zch01exm40.ap.freescale.net>
On May 29, 2006, at 10:28 PM, Zang Roy-r61911 wrote:
>>
>> On Wed, 2006-05-17 at 18:14 +0800, Zang Roy-r61911 wrote:
>>> Add Tundra Semiconductor tsi108 host bridge interrupt
>> controller support.
>>
>> It looks a bit like an hacked up MPIC... Is it different
>> enough to justify a separate driver ? Or would it be possible
>> to define a TSI108 flag to pass the current mpic driver and
>> add the necessary bits to it ?
>>
>
> Tsi108 implementation of MPIC has many differences form the
> original one, the following
> code implements it with mpic. Any comment? The following patch is
> just based on
> my previous send out patches.
In the future please provide it against the base, much easier to read.
> Integrate Tundra Semiconductor tsi108 host bridge interrupt controller
> to mpic arch.
>
> Signed-off-by: Alexandre Bounine <alexandreb@tundra.com>
>
[snip]
>
> --- linux-2.6.17-rc4-tun/arch/powerpc/sysdev/mpic.c 2006-03-20
> 00:53:29.000000000 -0500
> +++ linux-2.6.17-rc4-hpc2/arch/powerpc/sysdev/mpic.c 2006-05-29
> 16:07:03.000000000 -0400
> @@ -81,7 +81,7 @@ static inline void _mpic_write(unsigned
> static inline u32 _mpic_ipi_read(struct mpic *mpic, unsigned int ipi)
> {
> unsigned int be = (mpic->flags & MPIC_BIG_ENDIAN) != 0;
> - unsigned int offset = MPIC_GREG_IPI_VECTOR_PRI_0 + (ipi * 0x10);
> + unsigned int offset = MPIC_GREG_IPI_VECTOR_PRI_0 + (ipi *
> MPIC_GREG_IPI_STRIDE);
>
> if (mpic->flags & MPIC_BROKEN_IPI)
> be = !be;
> @@ -90,7 +90,7 @@ static inline u32 _mpic_ipi_read(struct
>
> static inline void _mpic_ipi_write(struct mpic *mpic, unsigned int
> ipi, u32 value)
> {
> - unsigned int offset = MPIC_GREG_IPI_VECTOR_PRI_0 + (ipi * 0x10);
> + unsigned int offset = MPIC_GREG_IPI_VECTOR_PRI_0 + (ipi *
> MPIC_GREG_IPI_STRIDE);
>
> _mpic_write(mpic->flags & MPIC_BIG_ENDIAN, mpic->gregs, offset,
> value);
> }
> @@ -393,7 +393,11 @@ static inline struct mpic * mpic_from_ir
> static inline void mpic_eoi(struct mpic *mpic)
> {
> mpic_cpu_write(MPIC_CPU_EOI, 0);
> +#ifndef CONFIG_TSI108_BRIDGE
> (void)mpic_cpu_read(MPIC_CPU_WHOAMI);
> +#else
> + (void)mpic_cpu_read(MPIC_CPU_OUTPUT);
> +#endif
> }
>
> #ifdef CONFIG_SMP
> @@ -514,9 +518,26 @@ static void mpic_end_irq(unsigned int ir
> }
> #endif /* CONFIG_MPIC_BROKEN_U3 */
>
> +#ifdef CONFIG_TSI108_BRIDGE
> + if ((irq_desc[irq].status & IRQ_LEVEL) != 0)
> +#endif
Why do you have to check if its a LEVEL irq?
> mpic_eoi(mpic);
> }
>
> +#ifdef CONFIG_TSI108_BRIDGE
> +static void mpic_ack_irq(unsigned int irq)
> +{
> + struct mpic *mpic = mpic_from_irq(irq);
> +
> +#ifdef DEBUG_IRQ
> + DBG("%s: ack_irq: %d\n", mpic->name, irq);
> +#endif
> +
> + if ((irq_desc[irq].status & IRQ_LEVEL) == 0)
> + mpic_eoi(mpic);
> +}
> +#endif /* CONFIG_TSI108_BRIDGE */
> +
if the PIC works like other openpic's you dont need an 'ack' we
handle it via 'end'
> #ifdef CONFIG_SMP
>
> static void mpic_enable_ipi(unsigned int irq)
> @@ -596,6 +617,9 @@ struct mpic * __init mpic_alloc(unsigned
> mpic->hc_irq.enable = mpic_enable_irq;
> mpic->hc_irq.disable = mpic_disable_irq;
> mpic->hc_irq.end = mpic_end_irq;
> +#ifdef CONFIG_TSI108_BRIDGE
> + mpic->hc_irq.ack = mpic_ack_irq;
> +#endif
> if (flags & MPIC_PRIMARY)
> mpic->hc_irq.set_affinity = mpic_set_affinity;
> #ifdef CONFIG_SMP
> @@ -955,8 +979,13 @@ void mpic_send_ipi(unsigned int ipi_no,
> DBG("%s: send_ipi(ipi_no: %d)\n", mpic->name, ipi_no);
> #endif
>
> +#ifndef CONFIG_TSI108_BRIDGE
> mpic_cpu_write(MPIC_CPU_IPI_DISPATCH_0 + ipi_no * 0x10,
> mpic_physmask(cpu_mask & cpus_addr(cpu_online_map)[0]));
> +#else /* CONFIG_TSI108_BRIDGE */
> + mpic_write(mpic->gregs, MPIC_CPU_IPI_DISPATCH,
> + mpic_physmask(cpu_mask & cpus_addr(cpu_online_map)[0]));
> +#endif /* !CONFIG_TSI108_BRIDGE */
> }
>
> int mpic_get_one_irq(struct mpic *mpic, struct pt_regs *regs)
> @@ -972,11 +1001,20 @@ int mpic_get_one_irq(struct mpic *mpic,
> DBG("%s: cascading ...\n", mpic->name);
> #endif
> irq = mpic->cascade(regs, mpic->cascade_data);
> +#ifdef DEBUG_LOW
> + DBG("%s: cascaded irq: %d\n", mpic->name, irq);
> +#endif
> +#ifndef CONFIG_TSI108_BRIDGE
> mpic_eoi(mpic);
> +#endif
> return irq;
> }
> - if (unlikely(irq == MPIC_VEC_SPURRIOUS))
> + if (unlikely(irq == MPIC_VEC_SPURRIOUS)) {
> +#ifdef CONFIG_TSI108_BRIDGE
> + mpic_eoi(mpic);
> +#endif
> return -1;
> + }
why the changes to where we do mpic_eoi for TSI108?
> if (irq < MPIC_VEC_IPI_0) {
> #ifdef DEBUG_IRQ
> DBG("%s: irq %d\n", mpic->name, irq + mpic->irq_offset);
[snip]
^ permalink raw reply
* Re: [patch] fix RTC/NVRAM accesses on Maple
From: Hollis Blanchard @ 2006-05-30 19:21 UTC (permalink / raw)
To: jfaslist; +Cc: linuxppc-dev
In-Reply-To: <447C4D4F.2020808@yahoo.fr>
[resend from the correct email address]
On Tue, 2006-05-30 at 15:49 +0200, jfaslist wrote:
> > Hollis' latest patch is needed still. We agreed not to solve it
> > completely correctly yet, as we'll need more surgery in other parts
> > of the PowerPC kernel first.
> I am trying to apply it on a 2.6.16.18 kernel but the two hunks of it
> are rejected. Any specific version to use?
You could look at the file to see why you're getting rejects. The patch
wasn't committed until 26 May, and 2.6.16.18 was released on 22 May, so
it's more likely you've done something on your side like try to apply
the patch twice (e.g. the original version and then the final version).
-Hollis
^ 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