Re: [Qemu-devel] Re: [RFC][PATCH 4/4] Add support for Marvell 88w8618 / MusicPal

[andrzej zaborowski]

On 18/04/2008, Jan Kiszka <address@hidden> 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.

>
>
>  >>>   - 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.

>
>  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)
and for such machines the -m parameter would be invalid.  I'll try to
come up with a patch.
-- 
Please do not print this email unless absolutely necessary. Spread
environmental awareness.