[...]
>
> 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
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 linux-mmc" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
