From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([208.118.235.92]:42175)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <peter.maydell@linaro.org>) id 1SyKZx-0001lS-PE
	for qemu-devel@nongnu.org; Mon, 06 Aug 2012 06:30:30 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <peter.maydell@linaro.org>) id 1SyKZt-0002Dk-Hg
	for qemu-devel@nongnu.org; Mon, 06 Aug 2012 06:30:29 -0400
Received: from mail-yx0-f173.google.com ([209.85.213.173]:45813)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <peter.maydell@linaro.org>) id 1SyKZt-0002Dg-DX
	for qemu-devel@nongnu.org; Mon, 06 Aug 2012 06:30:25 -0400
Received: by yenm10 with SMTP id m10so739669yen.4
	for <qemu-devel@nongnu.org>; Mon, 06 Aug 2012 03:30:24 -0700 (PDT)
MIME-Version: 1.0
In-Reply-To: <a3cd1ec7a7010f5bc00b6fb7bae00a084d16d310.1344223191.git.peter.crosthwaite@petalogix.com>
References: <cover.1344223191.git.peter.crosthwaite@petalogix.com>
	<a3cd1ec7a7010f5bc00b6fb7bae00a084d16d310.1344223191.git.peter.crosthwaite@petalogix.com>
Date: Mon, 6 Aug 2012 11:30:24 +0100
Message-ID: <CAFEAcA9F25AssxwDYrW2tH_SMyPYJuMeRgxm30d5BLHymPH=DQ@mail.gmail.com>
From: Peter Maydell <peter.maydell@linaro.org>
Content-Type: text/plain; charset=UTF-8
Subject: Re: [Qemu-devel] [PATCH v6 1/4] hw: introduce standard SD host
	controller
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: "Peter A. G. Crosthwaite" <peter.crosthwaite@petalogix.com>
Cc: i.mitsyanko@samsung.com, e.voevodin@samsung.com, qemu-devel@nongnu.org, kyungmin.park@samsung.com, d.solodkiy@samsung.com, edgar.iglesias@gmail.com, m.kozlov@samsung.com, john.williams@petalogix.com

On 6 August 2012 04:25, Peter A. G. Crosthwaite
<peter.crosthwaite@petalogix.com> wrote:

> +static void sdhci_sdma_transfer_multi_blocks(SDHCIState *s)
> +{
> +    bool page_aligned = false;
> +    unsigned int n, begin;
> +    const uint16_t block_size = s->blksize & 0x0fff;
> +    uint32_t boundary_chk = 1 << (((s->blksize & 0xf000) >> 12) + 12);
> +    uint32_t boundary_count = boundary_chk - (s->sdmasysad % boundary_chk);
> +
> +    /* XXX: Some sd/mmc drivers (for example, u-boot-slp) do not account for
> +     * possible stop at page boundary if initial address is not page aligned,
> +     * allow them to work properly */
> +    if ((s->sdmasysad % boundary_chk) == 0) {
> +        page_aligned = true;
> +    }

It's not quite clear to me what this comment is indicating. Is it
a bit of behaviour which is "not specified but behave as hardware
happens to do because software is accidentally relying on it", or
are we behaving differently from hardware here?

> +static void get_adma_description(SDHCIState *s, ADMADescr *dscr)
> +{
> +    uint32_t adma1 = 0;
> +    uint64_t adma2 = 0;
> +    target_phys_addr_t entry_addr = (target_phys_addr_t)s->admasysaddr;
> +
> +    switch (SDHC_DMA_TYPE(s->hostctl)) {
> +    case SDHC_CTRL_ADMA2_32:
> +        cpu_physical_memory_read(entry_addr, (uint8_t *)&adma2, sizeof(adma2));
> +        dscr->addr = (target_phys_addr_t)((adma2 >> 32) & 0xfffffffc);
> +        dscr->length = (uint16_t)((adma2 >> 16) & 0xFFFF);
> +        dscr->attr = (uint8_t)(adma2 & 0x3F);

Does the SDHCI spec define that these words are interpreted like
this regardless of system endianness, or is this an accidental
assumption of little-endian behaviour?

-- PMM