From: b29396@freescale.com (Dong Aisheng)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 0/5] mmc: sdhci-esdhc-imx: eliminate enum imx_esdhc_type
Date: Tue, 15 Oct 2013 15:36:32 +0800 [thread overview]
Message-ID: <20131015073631.GA21188@b29396-Latitude-E6410> (raw)
In-Reply-To: <1381739024-24924-1-git-send-email-shawn.guo@linaro.org>
On Mon, Oct 14, 2013 at 04:23:39PM +0800, Shawn Guo wrote:
> When I was reviewing Dong's imx6sl standard tuning patches, I found that
> it's a little clumsy to use enum imx_esdhc_type for handling features
> and quirks on different esdhc variants.
>
> Instead, the approach used in
> fec driver (drivers/net/ethernet/freescale/fec_main.c) should be more
> scalable in the long run. It defines flags for all those features and
> quirks and creates a mapping between esdhc variant and the flags.
>
It cause troubles if i try to rebase my patch series based on it
because esdhc/usdhc also have a lot register difference.
Originally we could simply use is_imx*_usdhc to handle those tiny difference,
however, now if you eliminate the entire is_imx*_usdhc, we may have to
add a lot arbitrary and hard to naming flags for register offset/mask
different issue.
It does not make too much sense.
e.g.
http://www.spinics.net/lists/arm-kernel/msg278507.html
http://permalink.gmane.org/gmane.linux.kernel.mmc/22934
Add maybe even more when we keep adding new features like:
mx5 DDR support and etc.(register offset is different between imx5&imx6)
It's hard to say how many similar cases left for me currently.
Looking at fec_main.c, the flags seem more like for simply features.
Not the same complicated situation as esdhc/usdhc.
I'm not sure this is so suitable for esdhc/usdhc.
Due to the problems this patch may introduce, it's probably may be good
to stick the old way to me since i did not see quite neccessary to switch
to new way on current code.
Or you may find a better fix for this issue.
Regards
Dong Aisheng
> Actually, sdhci-esdhc-imx driver already has one such flag, i.e.
> ESDHC_FLAG_MULTIBLK_NO_INT, but there is currently an unnecessary
> translation between the flag and imx_esdhc_type. The series creates
> another 3 flags and identify features/quirks using these flags and then
> eliminate enum imx_esdhc_type completely.
>
> Shawn Guo (5):
> mmc: sdhci-esdhc-imx: add flag ESDHC_FLAG_NO_DMAS_BITS
> mmc: sdhci-esdhc-imx: add flag ESDHC_FLAG_ENGCM07207
> mmc: sdhci-esdhc-imx: add flag ESDHC_FLAG_USDHC
> mmc: sdhci-esdhc-imx: pdev->id_entry should be immutable
> mmc: sdhci-esdhc-imx: eliminate enum imx_esdhc_type
>
> drivers/mmc/host/sdhci-esdhc-imx.c | 108 +++++++++++++++---------------------
> 1 file changed, 45 insertions(+), 63 deletions(-)
>
> --
> 1.7.9.5
>
next prev parent reply other threads:[~2013-10-15 7:36 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-10-14 8:23 [PATCH 0/5] mmc: sdhci-esdhc-imx: eliminate enum imx_esdhc_type Shawn Guo
2013-10-14 8:23 ` [PATCH 1/5] mmc: sdhci-esdhc-imx: add flag ESDHC_FLAG_NO_DMAS_BITS Shawn Guo
2013-10-14 8:23 ` [PATCH 2/5] mmc: sdhci-esdhc-imx: add flag ESDHC_FLAG_ENGCM07207 Shawn Guo
2013-10-15 6:49 ` Lucas Stach
2013-10-14 8:23 ` [PATCH 3/5] mmc: sdhci-esdhc-imx: add flag ESDHC_FLAG_USDHC Shawn Guo
2013-10-14 8:23 ` [PATCH 4/5] mmc: sdhci-esdhc-imx: pdev->id_entry should be immutable Shawn Guo
2013-10-14 8:23 ` [PATCH 5/5] mmc: sdhci-esdhc-imx: eliminate enum imx_esdhc_type Shawn Guo
2013-10-14 8:31 ` Lucas Stach
2013-10-14 13:27 ` Shawn Guo
2013-10-14 13:56 ` Shawn Guo
2013-10-14 8:44 ` Lothar Waßmann
2013-10-15 4:55 ` [PATCH 6/6] mmc: sdhci-esdhc-imx: create struct esdhc_soc_data Shawn Guo
2013-10-15 6:50 ` [PATCH 0/5] mmc: sdhci-esdhc-imx: eliminate enum imx_esdhc_type Lucas Stach
2013-10-15 7:36 ` Dong Aisheng [this message]
2013-10-15 8:54 ` Shawn Guo
2013-10-16 15:19 ` Shawn Guo
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20131015073631.GA21188@b29396-Latitude-E6410 \
--to=b29396@freescale.com \
--cc=linux-arm-kernel@lists.infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox