On 6 August 2012 04:25, Peter A. G. Crosthwaite
<peter.crosthwa...@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
