From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Jmv5V-0003KL-9E for qemu-devel@nongnu.org; Fri, 18 Apr 2008 14:13:29 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Jmv5T-0003Hz-BK for qemu-devel@nongnu.org; Fri, 18 Apr 2008 14:13:28 -0400 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Jmv5T-0003Hn-7y for qemu-devel@nongnu.org; Fri, 18 Apr 2008 14:13:27 -0400 Received: from fmmailgate01.web.de ([217.72.192.221]) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1Jmv5T-0000QL-IP for qemu-devel@nongnu.org; Fri, 18 Apr 2008 14:13:27 -0400 Received: from smtp06.web.de (fmsmtp06.dlan.cinetic.de [172.20.5.172]) by fmmailgate01.web.de (Postfix) with ESMTP id 26951DBD12FE for ; Fri, 18 Apr 2008 20:13:22 +0200 (CEST) Received: from [88.64.10.35] (helo=[192.168.1.198]) by smtp06.web.de with asmtp (TLSv1:AES256-SHA:256) (WEB.DE 4.109 #226) id 1Jmv5M-0003es-00 for qemu-devel@nongnu.org; Fri, 18 Apr 2008 20:13:20 +0200 Message-ID: <4808E49D.6020107@web.de> Date: Fri, 18 Apr 2008 20:12:45 +0200 From: Jan Kiszka MIME-Version: 1.0 References: <4801DC59.1010403@web.de> <48079FA6.3080104@web.de> In-Reply-To: <48079FA6.3080104@web.de> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig2AFE6E03E319DAE7AEC8D558" Sender: jan.kiszka@web.de Subject: [Qemu-devel] Re: [RFC][PATCH 4/4] Add support for Marvell 88w8618 / MusicPal Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig2AFE6E03E319DAE7AEC8D558 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Jan Kiszka wrote: > andrzej zaborowski wrote: >> Hi, >> >> On 13/04/2008, Jan Kiszka wrote: >>> This is the board emulation for Freecom's MusicPal, featuring >>> - rudimentary PIT and PIC >>> - up to 2 UARTs >>> - 88W8xx8 Ethernet controller >>> - 88W8618 audio controller >>> - Wolfson WM8750 mixer chip (volume control and mute only) >> Are you sure that hw/wm8750.c is not reusable? It's probably better >> to extend it with volume control, and audio data transmission through >> i2c, instead of having two implementations in QEMU. >=20 > Will check again, but I don't think it is helpful, at least at this > point. The thing is that the MusicPal uses the on-chip DAC, not the one= > of the Wolfson. The latter seems to be responsible for analogous mixing= > only. That was nonsense: The audio architecture of the MusicPal appears to be much like the one of the Spitz. Redirecting the audio stream to the Wolfson should be feasible. However, lacking support for volume control and muting currently prevents this. Andrzej, as you have written the wm8750, do you already know where which volume level would have to be applied (open-coded or via some AUD_set_volume)? I'm currently only using LOUT2VOL, and I'm a bit lazy to study the datasheet /wrt all the mixer details. >>> - 128=C3=9764 display with brightness control >>> - all input buttons >>> >>> Using up to 32 MB flash, I hit a limit /wrt phys_ram_size. I worked >>> around this for now by extending MAX_BIOS_SIZE to 32 MB, surely not = a >>> nice solution. >> You can use -m 150 or similar. >> >> Please also format the code similarly to rest of Qemu. >=20 > That would just increase ram_size, thus won't help as I need memory > beyond it (here for the pflash in R/W mode). OK, I see what you mean after looking at your N800 patches: You apply a fixed RAM size, leaving the rest of what the user provided via -m to SRAM and flash. Not optimal IMHO, you may sometimes also want to play with the RAM size even if the real devices has a fixed amount. And it is far from being intuitive as well. The only true solution I see right now is moving qemu_vmalloc into the machine initialization code. Is there anything between current qemu_vmalloc and machine->init that relies on phys_ram_base being valid (and which can't be moved after the machine init) and thus prevents this?= Jan --------------enig2AFE6E03E319DAE7AEC8D558 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4-svn0 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org iD8DBQFICOS1niDOoMHTA+kRAjKaAJ9IYG8Mil+6qHIAIaa0lCRIssqS0gCffqPF gcBCkn032A6R6WrTiBvCWto= =kiJG -----END PGP SIGNATURE----- --------------enig2AFE6E03E319DAE7AEC8D558--