[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH] Exynos4: added RTC device

From: Evgeny Voevodin
Subject: Re: [Qemu-devel] [PATCH] Exynos4: added RTC device
Date: Tue, 26 Jun 2012 07:18:46 +0400
User-agent: Mozilla/5.0 (X11; Linux i686; rv:12.0) Gecko/20120430 Thunderbird/12.0.1

On 25.06.2012 16:00, Andreas Färber wrote:
Am 25.06.2012 13:46, schrieb Evgeny Voevodin:
On 25.06.2012 13:24, Andreas Färber wrote:
Am 25.06.2012 09:55, schrieb Oleg Ogurtsov:
Signed-off-by: Oleg Ogurtsov<address@hidden>
   hw/arm/Makefile.objs |    1 +
   hw/exynos4210.c      |    8 +
   hw/exynos4210_rtc.c  |  607
   3 files changed, 616 insertions(+), 0 deletions(-)
   create mode 100644 hw/exynos4210_rtc.c
This RTC like many other Exynos devices has no dependency on the CPU. I
have a patch in preparation that moves such devices from
hw/arm/Makefile.objs to hw/Makefile.objs.
I don't object to this patch, not even minor style nits spotted,
compliment, but if you have to respin for some reason, it would be nice
if you could consider that improvement.
These devices are SOC specific and this SOC is based on ARM only.
Do we really need to move them?
For one, they do not need to be rebuilt when cpu.h changes and they
should get the usual device poisoning for proper modeling.
For another, someone on IRC started work on an armeb-softmmu, for which
we would probably not want to compile in the Exynos devices. Or if we
do, we certainly don't want to compile everything twice (cf. xilinx).

If devices are ARM-specific and need access to the CPU (e.g., machines,
PICs) then according to Paolo they should be placed in hw/arm/ with the
new scheme. I'm trying to stay away from moving other people's files
around, but the Makefile changes are pretty non-intrusive and can go
through arm-devs.next.


Oh, I see. Should we place this device to hw/Makefile.objs in v2?

Kind regards,
Evgeny Voevodin,
Leading Software Engineer,
ASWG, Moscow R&D center, Samsung Electronics
e-mail: address@hidden

reply via email to

[Prev in Thread] Current Thread [Next in Thread]