Hi Simon,
On Wed, Aug 2, 2017 at 2:48 PM, Simon Horman <horms+renesas@xxxxxxxxxxxx> wrote:
> Provide a whitelist for Gen3 SoC ES versions for both the SYS DMAC and
> internal DMAC variants of the SDHI driver. This is to allow drivers to
> only initialise for Gen3 SoC ES versions for which they are the appropriate
> DMAC implementation. Currently internal DMAC is the appropriate
> implementation for all supported Gen3 SoC ES versions.
>
> Signed-off-by: Simon Horman <horms+renesas@xxxxxxxxxxxx>
> ---
> drivers/mmc/host/renesas_sdhi_internal_dmac.c | 15 +++++++++++++++
> drivers/mmc/host/renesas_sdhi_sys_dmac.c | 15 +++++++++++++++
> 2 files changed, 30 insertions(+)
>
> diff --git a/drivers/mmc/host/renesas_sdhi_internal_dmac.c b/drivers/mmc/host/renesas_sdhi_internal_dmac.c
> index a26c6ed8e029..6717003888e2 100644
> --- a/drivers/mmc/host/renesas_sdhi_internal_dmac.c
> +++ b/drivers/mmc/host/renesas_sdhi_internal_dmac.c
> @@ -241,8 +242,22 @@ static struct tmio_mmc_dma_ops renesas_sdhi_internal_dmac_dma_ops = {
> .dataend = renesas_sdhi_internal_dmac_dataend_dma,
> };
>
> +/*
> + * Whitelist of specific R-Car Gen3 SoC ES versions to use this DMAC
> + * implementation as others may use a different implementation.
> + */
> +static const struct soc_device_attribute gen3_soc_whitelist[] = {
> + { .soc_id = "r8a7795", .revision = "ES1.*" },
> + { .soc_id = "r8a7795", .revision = "ES2.0" },
> + { .soc_id = "r8a7796", .revision = "ES1.0" },
> + { /* sentinel */ }
> +};
> +
> static int renesas_sdhi_internal_dmac_probe(struct platform_device *pdev)
> {
> + if (!soc_device_match(gen3_soc_whitelist))
> + return -ENODEV;
The pattern followed here is different from the pattern followed so far in
other places where we use soc_device_match(): instead of implementing a
specific behavior for early SoC revisions, and another behavior for later (and
future!) SoC revisions, this check tests for all current SoC revisions, and
breaks[*] for future versions (R-Car H3 ES2.1 and later, R-Car M3-W ES1.1 and
later).
I guess this is done this way because we don't have any R-Car Gen3 SoCs yet
that do support SYS-DMAC for SDHI?
[*] I understand it doesn't really break, but falls back to PIO on future
revisions? Hence it should be OK.
> +
> return renesas_sdhi_probe(pdev, &renesas_sdhi_internal_dmac_dma_ops);
> }
>
> diff --git a/drivers/mmc/host/renesas_sdhi_sys_dmac.c b/drivers/mmc/host/renesas_sdhi_sys_dmac.c
> index b6789f5197b3..718cb8a9d2ce 100644
> --- a/drivers/mmc/host/renesas_sdhi_sys_dmac.c
> +++ b/drivers/mmc/host/renesas_sdhi_sys_dmac.c
> @@ -459,8 +461,21 @@ static const struct tmio_mmc_dma_ops renesas_sdhi_sys_dmac_dma_ops = {
> .dataend = renesas_sdhi_sys_dmac_dataend_dma,
> };
>
> +/*
> + * Whitelist of specific R-Car Gen3 SoC ES versions to use this DMAC
> + * implementation. Currently empty as all supported ES versions use
> + * the internal DMAC.
> + */
> +static const struct soc_device_attribute gen3_soc_whitelist[] = {
> + { /* sentinel */ }
> +};
> +
> static int renesas_sdhi_sys_dmac_probe(struct platform_device *pdev)
> {
> + if (of_device_get_match_data(&pdev->dev) == &of_rcar_gen3_compatible &&
> + !soc_device_match(gen3_soc_whitelist))
> + return -ENODEV;
> +
> return renesas_sdhi_probe(pdev, &renesas_sdhi_sys_dmac_dma_ops);
> }
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@xxxxxxxxxxxxxx
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
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
