From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([140.186.70.92]:57377)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <gceq-qemu-devel@m.gmane.org>) id 1RarSn-0000GI-43
	for qemu-devel@nongnu.org; Wed, 14 Dec 2011 11:13:50 -0500
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <gceq-qemu-devel@m.gmane.org>) id 1RarSi-00038Z-QD
	for qemu-devel@nongnu.org; Wed, 14 Dec 2011 11:13:49 -0500
Received: from lo.gmane.org ([80.91.229.12]:52064)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <gceq-qemu-devel@m.gmane.org>) id 1RarSi-00038T-Ic
	for qemu-devel@nongnu.org; Wed, 14 Dec 2011 11:13:44 -0500
Received: from list by lo.gmane.org with local (Exim 4.69)
	(envelope-from <gceq-qemu-devel@m.gmane.org>) id 1RarSg-00064f-LY
	for qemu-devel@nongnu.org; Wed, 14 Dec 2011 17:13:42 +0100
Received: from 213.33.220.118 ([213.33.220.118])
	by main.gmane.org with esmtp (Gmexim 0.1 (Debian))
	id 1AlnuQ-0007hv-00
	for <qemu-devel@nongnu.org>; Wed, 14 Dec 2011 17:13:42 +0100
Received: from m.kozlov by 213.33.220.118 with local (Gmexim 0.1 (Debian))
	id 1AlnuQ-0007hv-00
	for <qemu-devel@nongnu.org>; Wed, 14 Dec 2011 17:13:42 +0100
From: "Maksim E. Kozlov" <m.kozlov@samsung.com>
Date: Wed, 14 Dec 2011 20:08:39 +0300
Message-ID: <jcahv8$7qj$1@dough.gmane.org>
References: <1323672206-11891-1-git-send-email-e.voevodin@samsung.com>	<1323672206-11891-3-git-send-email-e.voevodin@samsung.com>
	<CAFEAcA_kSShKPpuk+OtER9fQi+ddo7g2EwWqHohn8axTEe0X=w@mail.gmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
In-Reply-To: <CAFEAcA_kSShKPpuk+OtER9fQi+ddo7g2EwWqHohn8axTEe0X=w@mail.gmail.com>
Subject: Re: [Qemu-devel] [PATCH v3 02/14] ARM: exynos4210: CMU support
List-Id: <qemu-devel.nongnu.org>
List-Unsubscribe: <https://lists.nongnu.org/mailman/options/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.nongnu.org/archive/html/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <https://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: qemu-devel@nongnu.org

>> +
>> +/*
>> + * There are five CMUs:
>> + *
>> + *  CMU_LEFTBUS
>> + *  CMU_RIGHTBUS
>> + *  CMU_TOP
>> + *  CMU_DMC
>> + *  CMU_CPU
>> + *
>> + *  each of them uses 16KB address space for SFRs
>> + *
>> + *  + 0x4000 because SFR region for CMUs starts at 0x10030000,
>> + *  but the first CMU (CMU_LEFTBUS) starts with this offset
>> + *
>> + */
>> +#define EXYNOS4210_CMU_REGS_MEM_SIZE   (0x4000 * 5 + 0x4000)
>
> It seems a bit unlikely to me that there's really a single indivisble
> bit of hardware with 23 kilobytes worth of register area. Is there
> a better way of structuring this so that there are a number of
> sub-memory-regions that cover this space each with their own
> read/write functions (and perhaps with their own state structs)?
> (eg instantiate five CPUs at the right locations.)
>

Dear Peter,

Sorry, but I don't quite understand what do you mean. Which 23 kilobytes 
you have in mind?
And what benefits we get from division whole region into some 
sub-regions? Current approach seems quite simple and clear. Isn't it?