* Re: [PATCH] powerpc: Fix buglet with MMU hash management
From: Olof Johansson @ 2006-05-30 4:36 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev list, Paul Mackerras
In-Reply-To: <1148962460.15722.19.camel@localhost.localdomain>
On Tue, May 30, 2006 at 02:14:19PM +1000, Benjamin Herrenschmidt wrote:
> This fixes by allowing the updating of the protection bits in the native
> hash handling to also set (but not clear) the "C" bit, and, in order to
> also improve performances in the general case, by always setting that
> bit on newly inserted hash PTE so that writeback really never happens.
Good catch!
However, you'll have a writeback on the R bit too, you should set that
together with C.
-Olof
^ permalink raw reply
* Re: [PATCH] powerpc: Fix buglet with MMU hash management
From: Benjamin Herrenschmidt @ 2006-05-30 4:55 UTC (permalink / raw)
To: Olof Johansson; +Cc: linuxppc-dev list, Paul Mackerras
In-Reply-To: <20060530043626.GC5101@pb15.lixom.net>
On Mon, 2006-05-29 at 23:36 -0500, Olof Johansson wrote:
> On Tue, May 30, 2006 at 02:14:19PM +1000, Benjamin Herrenschmidt wrote:
>
> > This fixes by allowing the updating of the protection bits in the native
> > hash handling to also set (but not clear) the "C" bit, and, in order to
> > also improve performances in the general case, by always setting that
> > bit on newly inserted hash PTE so that writeback really never happens.
>
> Good catch!
>
> However, you'll have a writeback on the R bit too, you should set that
> together with C.
Nope, R is always set at PTE insertion (it's _PAGE_ACCESSED)
Ben.
^ permalink raw reply
* [PATCH] kexec ppc64: fix segv when missing root= on cmdline
From: Michael Neuling @ 2006-05-30 5:02 UTC (permalink / raw)
To: linuxppc-dev, Fastboot mailing list; +Cc: miltonm
If the first kernel command line or the --command-line parameter doesn't
have a 'root=', we seg fault on ppc64.
Patch below is against Maneesh's kexec-tools-1.101-kdump8 patches.
Signed-off-by: Michael Neuling <mikey@neuling.org>
--
kexec/arch/ppc64/fs2dt.c | 10 ++++++----
1 file changed, 6 insertions(+), 4 deletions(-)
Index: kexec-tools-1.101/kexec/arch/ppc64/fs2dt.c
===================================================================
--- kexec-tools-1.101.orig/kexec/arch/ppc64/fs2dt.c
+++ kexec-tools-1.101/kexec/arch/ppc64/fs2dt.c
@@ -267,10 +267,12 @@ void putprops(char *fn, struct dirent **
char *old_param;
memcpy(temp_cmdline, dt, len);
param = strstr(temp_cmdline, "root=");
- old_param = strtok(param, " ");
- if (cmd_len != 0)
- strcat(local_cmdline, " ");
- strcat(local_cmdline, old_param);
+ if (param) {
+ old_param = strtok(param, " ");
+ if (cmd_len != 0)
+ strcat(local_cmdline, " ");
+ strcat(local_cmdline, old_param);
+ }
}
strcat(local_cmdline, " ");
cmd_len = strlen(local_cmdline);
^ permalink raw reply
* [PATCH] kexec ppc64: add missing usage info for options
From: Michael Neuling @ 2006-05-30 6:06 UTC (permalink / raw)
To: linuxppc-dev, Fastboot mailing list
I had to look through the source to remember what these are one too many
times.
Patch below is against Maneesh's kexec-tools-1.101-kdump8 patches.
Signed-off-by: Michael Neuling <mikey@neuling.org>
---
kexec/arch/ppc64/kexec-ppc64.c | 4 ++++
1 file changed, 4 insertions(+)
Index: kexec-tools-1.101/kexec/arch/ppc64/kexec-ppc64.c
===================================================================
--- kexec-tools-1.101.orig/kexec/arch/ppc64/kexec-ppc64.c
+++ kexec-tools-1.101/kexec/arch/ppc64/kexec-ppc64.c
@@ -552,6 +552,10 @@ int file_types = sizeof(file_type) / siz
void arch_usage(void)
{
+ fprintf(stderr, " --command-line=<Command line> command line to append.\n");
+ fprintf(stderr, " --append=<Command line> same as --command-line.\n");
+ fprintf(stderr, " --ramdisk=<filename> Initial RAM disk.\n");
+ fprintf(stderr, " --initrd=<filename> same as --ramdisk.\n");
fprintf(stderr, " --devicetreeblob=<filename> Specify device tree blob file.\n");
fprintf(stderr, " --elf64-core-headers Prepare core headers in ELF64 format\n");
}
^ permalink raw reply
* Re: [PATCH] powerpc vdso updates
From: Ingo Molnar @ 2006-05-30 6:24 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: Andrew Morton, linuxppc-dev list, Paul Mackerras,
Linux Kernel list
In-Reply-To: <1148961097.15722.11.camel@localhost.localdomain>
* Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:
> This patch cleans up some locking & error handling in the ppc vdso and
> moves the vdso base pointer from the thread struct to the mm context
> where it more logically belongs. It brings the powerpc implementation
> closer to Ingo's new x86 one and also adds an arch_vma_name() function
> allowing to print [vsdo] in /proc/<pid>/maps if Ingo's x86 vdso patch
> is also applied.
looks good to me.
> Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Reviewed-by: Ingo Molnar <mingo@elte.hu>
> This is 2.6.18 material, hopefully should go along with Ingo's x86
> vdso updates. Ingo, if you change something to arch_vma_name(), please
> let me know.
ok. There's one bit that could potentially be 2.6.17 material:
> * at vdso_base which is the "natural" base for it, but we might fail
> * and end up putting it elsewhere.
> */
> + down_write(&mm->mmap_sem);
> vdso_base = get_unmapped_area(NULL, vdso_base,
> vdso_pages << PAGE_SHIFT, 0, 0);
get_unmapped_area() without holding the mmap semaphore seems dangerous.
The VDSO setup itself should be 'private' to the process, but i'm not
totally sure that no other kernel code could get access to this mm. For
example the swapout code? Am i missing something?
Ingo
^ permalink raw reply
* Re: [PATCH] powerpc vdso updates
From: Benjamin Herrenschmidt @ 2006-05-30 7:21 UTC (permalink / raw)
To: Ingo Molnar
Cc: Andrew Morton, linuxppc-dev list, Paul Mackerras,
Linux Kernel list
In-Reply-To: <20060530062447.GD19870@elte.hu>
> get_unmapped_area() without holding the mmap semaphore seems dangerous.
> The VDSO setup itself should be 'private' to the process, but i'm not
> totally sure that no other kernel code could get access to this mm. For
> example the swapout code? Am i missing something?
Well, all of this happens so early, I doubt anything will cause actual
harm, for get_unmapped_area to be a problem, something would have to
concurrently allocate a VMA (or dispose of) I think that can't happen at
this point before we even run the binary but yes, better safe than
sorry... I supose the whole patch could get in 2.6.17 even without the
arch_vma_name (that is it can be there, it wont be used though until
your patch gets in).
Ben.
^ permalink raw reply
* undefined symbols of modules
From: Josef Angermeier @ 2006-05-30 7:45 UTC (permalink / raw)
To: linuxppc-embedded
Hello,
when i try to compile my kernel extension as modul, i get some undefined
references. But a look in System.map shows, that the relevant symbols
are defined in the main kernel. Why then those undefined references ?
Any hint is appreciated!
bye
Josef
make ARCH=ppc -C linux modules
make[1]: Entering directory `/scratch-local/esm/linux'
CHK include/linux/version.h
Building modules, stage 2.
MODPOST
*** Warning: "cpm_load_patch" [drivers/usb/host/m82xx-hcd.ko] undefined!
*** Warning: "cpmp" [drivers/usb/host/m82xx-hcd.ko] undefined!
^ permalink raw reply
* Re: undefined symbols of modules
From: Eugene Surovegin @ 2006-05-30 8:06 UTC (permalink / raw)
To: Josef Angermeier; +Cc: linuxppc-embedded
In-Reply-To: <447BF82A.8000503@cs.fau.de>
On Tue, May 30, 2006 at 09:45:46AM +0200, Josef Angermeier wrote:
> Hello,
>
> when i try to compile my kernel extension as modul, i get some undefined
> references. But a look in System.map shows, that the relevant symbols
> are defined in the main kernel. Why then those undefined references ?
Symbol must be exported to be available for modules, just being listed
in System.map isn't enough.
Try adding EXPORT_SYMBOL(...) for those "undefined" references.
--
Eugene
^ permalink raw reply
* Re: [Done] Re: snd-aoa: Sound gone after snd-aoa updates, on PB5,8
From: Michel Dänzer @ 2006-05-30 7:44 UTC (permalink / raw)
To: Wolfgang Pfeiffer; +Cc: linuxppc-dev, Johannes Berg
In-Reply-To: <20060529221730.GA3138@localhost>
On Tue, 2006-05-30 at 00:17 +0200, Wolfgang Pfeiffer wrote:
>=20
> The problem is: with libasound2 1.0.11-6 I cannot even *start*=20
> alsamixer:
>=20
> ------------------------
> $ alsamixer
> ALSA lib control.c:816:(snd_ctl_open_noupdate) Invalid CTL default
>=20
> alsamixer: function snd_ctl_open failed for default: No such file or dire=
ctory
See http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=3D369478 and friends.
--=20
Earthling Michel D=C3=A4nzer | http://tungstengraphics.c=
om
Libre software enthusiast | Debian, X and DRI developer
^ permalink raw reply
* LXT973 support (dual PHY with single MDIO)
From: Laurent Pinchart @ 2006-05-30 8:48 UTC (permalink / raw)
To: linuxppc-embedded
Hi everybody,
I'm trying to bring up the two ethernet ports on a LXT973 dual-PHY chip. I've
declared two FCC platform devices, which are detected and handled by the
driver/net/fs_enet driver. My issue comes from MDIO support.
The LXT973 has a single MDIO port which answers to two addresses, one for each
PHY. The MDC and MDIO lines are connected to GPIO pins (no PHY interrupt), so
I'm using the bitbang MDIO driver. I've declared a MPC82xx_MDIO_BB platform
device, and set bus_id to "0:00" for both FCC ethernet devices. The first
ethernet device works fine, but the second complains that the PHY is already
in use.
As the PHY read/write accesses are protected by the bus->mdio_lock, I thought
about declaring a second MDIO platform device using the same I/O pins as the
first. Does anybody knows any problem I could run into using that approach ?
Is there a better method to handle the LXT973 MDIO ?
Thanks in advance for any help you can provide.
Best regards,
Laurent Pinchart
^ permalink raw reply
* Re: LXT973 support (dual PHY with single MDIO)
From: Wojciech Kromer @ 2006-05-30 9:05 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <200605301048.01209.laurent.pinchart@tbox.biz>
I'm sucesfully using this chip with denx.de 2.4.25 kernel and single
MDIO port.
You need to change auto PHY-addr detection method. By default it
detects both PHYs on same addr.
^ permalink raw reply
* Re: [SOLVED] LXT973 support (dual PHY with single MDIO)
From: Laurent Pinchart @ 2006-05-30 9:28 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <200605301048.01209.laurent.pinchart@tbox.biz>
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 ?
Laurent Pinchart
^ permalink raw reply
* Re: Can't get CoralP drivers to work
From: jourdan @ 2006-05-30 9:39 UTC (permalink / raw)
To: Wolfgang Denk; +Cc: linuxppc-embedded
In-Reply-To: <1758.194.3.133.184.1148897976.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?
>
> 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.
>
As I said earlier, when the driver loads, my monitor don't receive any
video signal. I can force it by calling at the end of the initialization
of the driver :
reg = MB86290FB_READ_DISP_REGISTER(GDC_DISP_REG_EXT_MODE);
MB86290FB_WRITE_DISP_REGISTER(GDC_DISP_REG_EXT_MODE, reg | 0x80010000);
This command enables the display, and "garbage" appears on the monitor.
Then if i do :
# cat /dev/urandom > /dev/fb0
I should see dummy pixels on the screen but in fact nothing happens. This
is still the same garbage on the screen.
I use a custom processor card based on a MPC8270. I can't figure out if
the problem comes from the configuration of my kernel (all the needed
options are enabled) or if it is in the code of the initialisation of my
platform.
This is the first time I try to use framebuffer graphics, so I'm new with
it. Can the framebuffer work from a serial console on a platform without
keyboard ?
Thanks for your help.
^ permalink raw reply
* RE: Linux kernel thread with Linux 2.6.x
From: Laurent Lagrange @ 2006-05-30 9:46 UTC (permalink / raw)
To: 'Thiago Galesi'; +Cc: linuxppc-embedded
In-Reply-To: <82ecf08e0605291013t7bd1627bg92d13908b3d0b7b7@mail.gmail.com>
Hi,
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.
Any other idea ?
Laurent.
> -----Message d'origine-----
> De : Thiago Galesi [mailto:thiagogalesi@gmail.com]
> Envoyé : lun. 29 mai 2006 18:13
> À : Laurent Lagrange
> Cc : linuxppc-embedded@ozlabs.org
> Objet : Re: Linux kernel thread with Linux 2.6.x
>
>
> >
> > 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] fix RTC/NVRAM accesses on Maple
From: jfaslist @ 2006-05-30 10:39 UTC (permalink / raw)
To: Hollis Blanchard; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <1148593014.15517.32.camel@basalt.austin.ibm.com>
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=us-ascii; format=flowed, Size: 594 bytes --]
Hi,
So the RTC/NVRAM patch is no longer needed for the Maple?
Thanks
-jf simon
Hollis Blanchard wrote:
>On Fri, 2006-05-19 at 08:58 +1000, Paul Mackerras wrote:
>
>
>>Care to redo the patch?
>>
>>
>
>After some offline discussion, I think we're in agreement that these
>properties are fine, since Linux's device tree code can't handle
>multiple ranges. Right Segher?
>
>
>
___________________________________________________________________________
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: [Done #2] Re: snd-aoa: Sound gone after snd-aoa updates, on PB5, 8
From: Wolfgang Pfeiffer @ 2006-05-30 11:23 UTC (permalink / raw)
To: Michel Dänzer; +Cc: linuxppc-dev, Johannes Berg
In-Reply-To: <1148975072.27856.294.camel@thor.lorrainebruecke.local>
On Tue, May 30, 2006 at 09:44:32AM +0200, Michel Dänzer wrote:
> On Tue, 2006-05-30 at 00:17 +0200, Wolfgang Pfeiffer wrote:
> >
> > The problem is: with libasound2 1.0.11-6 I cannot even *start*
> > alsamixer:
> >
> > ------------------------
> > $ alsamixer
> > ALSA lib control.c:816:(snd_ctl_open_noupdate) Invalid CTL default
> >
> > alsamixer: function snd_ctl_open failed for default: No such file or directory
>
> See http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=369478 and friends.
Thanks.
And the bug already seems to be fixed with a new version: I just
installed it (libasound2 1.0.11-7) and at least alsamixer and amixer
started without error. Plus: Restarting the KDE sound system after
installing this new version also worked liked a charm.
Thanks to everyone involved :)
Best Regards
Wolfgang
--
Wolfgang Pfeiffer: /ICQ: 286585973/ + + + /AIM: crashinglinux/
http://profiles.yahoo.com/wolfgangpfeiffer
Key ID: E3037113
http://keyserver.mine.nu/pks/lookup?search=0xE3037113&fingerprint=on
^ permalink raw reply
* Re: [patch] fix RTC/NVRAM accesses on Maple
From: Segher Boessenkool @ 2006-05-30 11:38 UTC (permalink / raw)
To: jfaslist; +Cc: linuxppc-dev, Paul Mackerras, Hollis Blanchard
In-Reply-To: <447C20C4.50804@yahoo.fr>
> So the RTC/NVRAM patch is no longer needed for the Maple?
> Thanks
> -jf simon
[Post-top not do. Backwards read not do people.]
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
^ permalink raw reply
* fs_enet segfaults when adding network interface to bridge
From: Laurent Pinchart @ 2006-05-30 11:51 UTC (permalink / raw)
To: linuxppc-embedded
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.
Laurent Pinchart
^ permalink raw reply
* Re: Linux kernel thread with Linux 2.6.x
From: Jörn Engel @ 2006-05-30 11:23 UTC (permalink / raw)
To: Laurent Lagrange; +Cc: linuxppc-embedded
In-Reply-To: <000a01c683cd$e3f29ca0$5201a8c0@GEG2400>
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
--
Data expands to fill the space available for storage.
-- Parkinson's Law
^ permalink raw reply
* Re: Can't get CoralP drivers to work
From: jourdan @ 2006-05-30 12:00 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <2095.194.3.133.184.1148990341.squirrel@webmail.enib.fr>
> Does the 8270 swap bytes on the PCI bus? The CoralP drivers are written
> for
> the 5200, which assumes any PCI card to be little-endian, and thus swaps
> bytes. That is, if you write a 32-bit word, say 0x01020304, the 5200
> PCI
> will actually write 0x04030201. So if 8270 does *not* swap bytes like
> that
> it would be a problem.
>
I checked this and the byte swapping is OK.
^ permalink raw reply
* fs_enet turns promiscous mode off in restart()
From: Laurent Pinchart @ 2006-05-30 12:34 UTC (permalink / raw)
To: linuxppc-embedded
Hi everybody,
I'm having an issue with promiscuous mode in the fs_enet driver. The restart()
function in drivers/net/fs_enet/mac-fcc.c writes to the FPSMR register:
W32(fccp, fcc_fpsmr, FCC_PSMR_ENCRC);
This disable promiscuous mode. Shouldn't set_multicast_list() be called at the
end of restart() to restore promiscuous (and multicast) settings ?
A similar issue exists for the FEC and SCC backends.
Laurent Pinchart
^ permalink raw reply
* 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
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