re: patch for am7930 audio
> By the way, I'm not so familiar to sparc. > audioamd(4) has many assembly code (though they look very old stuff). > Is there any (historical or traditional) reason why I should not > remove these? i would just ignore it. it's currently unused and if someone wants to fix it up, it's sitting there easy to look at, but it is not currently used and is known needing work for years ago API changes, so don't feel you can't change the code around it. it's just more work for someone who may eventually revive it. .mrg.
Re: patch for am7930 audio
mo...@rodents-montreal.org (Mouse) writes: >Some SPARCs have audio hardware not capable of more than 8kHz. Some >have hardware that can handle CD-quality audio (and possibly better). >I don't know where the 7930 falls on that spectrum. The am7930 is an ISDN chip and limited to 8kHz uLaw or aLaw audio, it can do some filtering and generate dial tones, but not CD-quality. -- -- Michael van Elst Internet: mlel...@serpens.de "A potential Snark may lurk in every tree."
Trying to write a kernel module for (un)mounting tmpfs
Hi, I'm trying to write a kernel module as example for mounting and unmounting tmpfs. For that, I read the mount_tmpfs code and in line 247 I found the call for mount() syscall here: https://nxr.netbsd.org/xref/src/sbin/mount_tmpfs/mount_tmpfs.c#247 Then I looked for how the kernel mounts file systems and found there are _mount() function for every file system: https://nxr.netbsd.org/xref/src/sys/sys/mount.h#254 Now, I just needed to know how to use tmpfs_mount() and find it here: https://nxr.netbsd.org/xref/src/sys/fs/tmpfs/tmpfs_vfsops.c#86 but I still don't know how to use it. I created the struct [tmpfs_args](https://nxr.netbsd.org/source/s?defs=tmpfs_args=src) [args](https://nxr.netbsd.org/source/s?refs=args=src) and size_t args_len = sizeof args variables to pass to data and data_len arguments in tmpfs_mount(). And the directory I'm mounting is "/tmp". So, I have 3 of 4 arguments needed to tmpfs_mount(), the last one is the struct mount *mp. I know the mount() syscall takes [MOUNT_TMPFS](https://nxr.netbsd.org/source/s?defs=MOUNT_TMPFS=src) as first argument, but I'm not understanding the magic behind struct mount mp and what I need to assign to the struct mount variable to pass it to that argument. Any hint? Thanks for the help, Bruno Melo.
Re: patch for am7930 audio
> am7930intr.s [...] already has been disabled 11 years ago due to > adapt to MI softint(9) [*]. Oh! Okay, then, yes, if it's not even being used there's no point keeping it. Anyone who needs it can get it back from revision history. >> [...] significant impact on performance at higher sample rates. > I think that am7930 works only at 8000Hz. > Does sparc's one support sample rate other than 8000Hz? Some SPARCs have audio hardware not capable of more than 8kHz. Some have hardware that can handle CD-quality audio (and possibly better). I don't know where the 7930 falls on that spectrum. /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTMLmo...@rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
Re: patch for am7930 audio
At Wed, 9 Sep 2020 10:53:09 -0400 (EDT), Mouse wrote: > >>> audioamd(4) has many assembly code (though they look very old stuff). > >> [...] I see no assembly code in arch/sparc/dev/audioamd* on 5.2 [...] > > It's in sparc/sparc/amd7930intr.s. : > Personally, I would be inclined to preserve that. It handles the > interrupt entirely in the trap window, which, for something that > interrupts frequently, can significantly lessen the impact of the > interrupts on performance. Isaki-san did not give any indication what > motivated the removal of that assembly (and presumably its replacement > with C), but I would hesitate to do it without, at the very least, > measuring the performance impact of such a change. Thank you for comment. As you said, there were too little description about this... am7930intr.s seems have been ported from C as a fast interrupt path. But it already has been disabled 11 years ago due to adapt to MI softint(9) [*]. Therefore, "asm vs C" was not a main topic here. Sorry for confusing. *: http://mail-index.netbsd.org/source-changes/2009/12/19/msg004585.html In addition, I changed the buffer structure used in interrupt handler for sharing. For these two reasons (or even if I have not changed the structure, for one reason above), to enable fast path again would require manpower. For such substitutable assembly code, unless someone continues to maintain them well, it should be removed, I personally think. > Yes, code sharing > is good - other things being equal. I suspect, though I haven't > measured it either, that "other things" are *not* equal here, that > replacing that assembly code with C (or, more precisely, the associated > potential window spilling) would have a significant impact on > performance at higher sample rates. I think that am7930 works only at 8000Hz. Does sparc's one support sample rate other than 8000Hz? Thanks, --- Tetsuya Isaki
