From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1JnIKj-0008SL-PB for qemu-devel@nongnu.org; Sat, 19 Apr 2008 15:02:45 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1JnIKi-0008Pm-8M for qemu-devel@nongnu.org; Sat, 19 Apr 2008 15:02:45 -0400 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1JnIKi-0008Pa-2Q for qemu-devel@nongnu.org; Sat, 19 Apr 2008 15:02:44 -0400 Received: from fmmailgate02.web.de ([217.72.192.227]) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1JnIKh-0002Hz-9N for qemu-devel@nongnu.org; Sat, 19 Apr 2008 15:02:43 -0400 Received: from smtp06.web.de (fmsmtp06.dlan.cinetic.de [172.20.5.172]) by fmmailgate02.web.de (Postfix) with ESMTP id 22B54D96D41A for ; Sat, 19 Apr 2008 21:02:01 +0200 (CEST) Received: from [88.64.18.144] (helo=[192.168.1.198]) by smtp06.web.de with asmtp (TLSv1:AES256-SHA:256) (WEB.DE 4.109 #226) id 1JnIK0-0004es-00 for qemu-devel@nongnu.org; Sat, 19 Apr 2008 21:02:01 +0200 Message-ID: <480A41A3.1000908@web.de> Date: Sat, 19 Apr 2008 21:01:55 +0200 From: Jan Kiszka MIME-Version: 1.0 References: <4801DC59.1010403@web.de> <48079FA6.3080104@web.de> <4808E49D.6020107@web.de> In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig761BA135CE01DA2E2955E7B1" 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) --------------enig761BA135CE01DA2E2955E7B1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable andrzej zaborowski wrote: > On 18/04/2008, Jan Kiszka wrote: >> Andrzej, as you have written the wm8750, do you already know where wh= ich >> 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 laz= y >> to study the datasheet /wrt all the mixer details. >=20 > My idea was to open > http://www.wolfsonmicro.com/uploads/documents/en/WM8750.pdf and on the > first page every Wolfson datasheet has its diagram of all audio paths > (of which there are always too many) and then trace with my finger the > path between the source (the I2C or I2S interfaces) and the sink (the > analog output), and then multiply all the volume values that are > applied there (both analog and digital) and pass that to host mixer > through some functions in audio/ for the given SWVoice - but we don't > have any such functions and I'm ok with using the host mixer manually. > (VirtualBox has them implemented iirc) So yes, maybe it makes sense > to multiply the samples for the moment and use only LOUTnVOL / > ROUTnVOL values as these are used by the guests we're interested in. Done, and it finally works. One of the two quirks I found in wm8750 made the switch a bit hairy. Patches will follow. >=20 >> >> >>> - 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 wor= ked >> >>> 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. >> > >> > That would just increase ram_size, thus won't help as I need memory= >> > beyond it (here for the pflash in R/W mode). >=20 > Yes, I had not looked at how ram_size was used in the musicpal board > initialisation, sorry. >=20 >> >> 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. >=20 > Yes, although you allow the user to set also a smaller RAM than what > the virtual machine expects. That's indeed something the machine should take of (if there are such hard limits). >=20 >> The only true solution I see right now is moving qemu_vmalloc into th= e >> machine initialization code. Is there anything between current >> qemu_vmalloc and machine->init that relies on phys_ram_base being val= id >> (and which can't be moved after the machine init) and thus prevents t= his? >=20 > I had a different idea: add a field ram_constraint in struct > QEMUMachine, which would hold the amount of RAM the machine always > needs (e.g. bios and video RAM), and the low bit could hold a flag > RAM_SIZE_FIXED for machines that have only such RAM (basically the > criteria should be whether it's possible for the guest to detect the > memory size there is on board - on machines like Spitz there's no way) IIRC, embedded boards let the boot loader "detect" this. I see valid scenarios where one wants to play with different sizes and may therefore patch U-Boot - or load the kernel directly which should make QEMU set the related ATAG field appropriately, no? > and for such machines the -m parameter would be invalid. I'll try to > come up with a patch. I originally had the same idea but I dropped it because it would still overload -m with semantics that don't belong there. IMHO -m should only describe the main RAM size, not any additionally by QEMU required memory for establishing fixed SRAM or even for backing up flash devices. That's at least what I would expect from this switch and what the documentation suggests as well so far. Thus, back to square #1: Can't we move qemu_vmalloc into the machine-specific init handlers? Jan --------------enig761BA135CE01DA2E2955E7B1 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 iD8DBQFICkGoniDOoMHTA+kRAvAfAJ9NnpzrsM8Uvo6eSX2Xt3baA1dyHQCfXhgv mwaxjonF6oU93Ii6V1/DT5o= =PnQe -----END PGP SIGNATURE----- --------------enig761BA135CE01DA2E2955E7B1--