On 27 August 2015 at 15:34, Ulf Hansson <ulf.hansson@xxxxxxxxxx> wrote:
> [...]
>
>>
>> What I had in mind is replacing in_be32() with a esdhc_ops->readl() in this function. And the esdhc_ops->readl() would be assigned at the beginning according endian.
>>
>> static u32 esdhc_readl(struct sdhci_host *host, int reg)
>> {
>> u32 ret;
>>
>> ret = in_be32(host->ioaddr + reg);
>> /*
>> * The bit of ADMA flag in eSDHC is not compatible with standard
>> * SDHC register, so set fake flag SDHCI_CAN_DO_ADMA2 when ADMA is
>> * supported by eSDHC.
>> * And for many FSL eSDHC controller, the reset value of field
>> * SDHCI_CAN_DO_ADMA1 is one, but some of them can't support ADMA,
>> * only these vendor version is greater than 2.2/0x12 support ADMA.
>> * For FSL eSDHC, must aligned 4-byte, so use 0xFC to read the
>> * the verdor version number, oxFE is SDHCI_HOST_VERSION.
>> */
>> if ((reg == SDHCI_CAPABILITIES) && (ret & SDHCI_CAN_DO_ADMA1)) {
>> u32 tmp = in_be32(host->ioaddr + SDHCI_SLOT_INT_STATUS);
>> tmp = (tmp & SDHCI_VENDOR_VER_MASK) >> SDHCI_VENDOR_VER_SHIFT;
>> if (tmp > VENDOR_V_22)
>> ret |= SDHCI_CAN_DO_ADMA2;
>> }
>>
>> return ret;
>> }
>>
>> The LE and BE accessors could be defined in sdhci-esdhc.h for esdhc_ops->readl() as below.
>> static u32 esdhc_be32bs_readl(struct sdhci_host *host, int reg)
>> {
>> return ioread32be(host->ioaddr + reg);
>> }
>>
>> static u32 esdhc_le32bs_readl(struct sdhci_host *host, int reg)
>> {
>> return ioread32(host->ioaddr + reg);
>> }
>>
>> Do you think it is ok for you?
>
> It becomes a bit "hacky", but currently I can't think of a better solution.
>
>>
>>
>> Or Maybe there is another method, use conditional compilation. The previous method would delete the MMC_SDHCI_BIG_ENDIAN_32BIT_BYTE_SWAPPER to use accessors defined in sdhci-esdhc.h, and add dependency of ARM. This method could use 'select <accessors> if <ARCH>' to compile LE or BE accessors according ARCH.
>
> I don't really follow your suggestion.
>
> Isn't the problem that you need the
> MMC_SDHCI_BIG_ENDIAN_32BIT_BYTE_SWAPPER for configurations and for
> some you don't? More precisely, for those where you don't you would
> rather just use the regulator ioread* functions since those will
/s/regulator/regular
> internally deal with the endianess in runtime?
>
> If you can make these decisions at compile time an depending of the
> ARCH - I believe I would be fine with that as well.
>
> [...]
>
> Kind regards
> Uffe
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
