andrzej zaborowski wrote: > On 18/04/2008, Jan Kiszka wrote: >> 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. > > 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. > >> >> >>> - 128×64 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. >> > >> > That would just increase ram_size, thus won't help as I need memory >> > beyond it (here for the pflash in R/W mode). > > Yes, I had not looked at how ram_size was used in the musicpal board > initialisation, sorry. > >> >> 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. > > 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). > >> 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? > > 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