Re: [Qemu-devel] [PATCH v6 1/4] hw: introduce standard SD host controller

[Peter Maydell <peter.maydell@linaro.org>]

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