On 6 August 2012 12:28, Igor Mitsyanko <i.mitsya...@samsung.com> wrote:
> On 08/06/2012 02:30 PM, Peter Maydell wrote:
>>> +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?
>
>
> Spec never says it explicitly, but it's quite obvious that descriptor table
> has a little endian format. There is even a comment in linux SDHCI driver
> that says:
>
> /*
> * The spec does not specify endianness of descriptor table.
> * We currently guess that it is LE.
> */
OK; we could probably use a similar comment.
-- PMM
