From: Sascha Hauer <s.hauer-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
To: Anatolij Gustschin <agust-ynQEQJNshbs@public.gmane.org>
Cc: devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org,
Chris Ball <cjb-2X9k7bc8m7Mdnm+yROfE0A@public.gmane.org>,
linux-mmc-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Subject: Re: [PATCH 1/5] mmc: mxcmmc: add mpc512x SDHC support
Date: Thu, 14 Mar 2013 21:05:56 +0100 [thread overview]
Message-ID: <20130314200556.GR1906@pengutronix.de> (raw)
In-Reply-To: <20130314191332.44ca64c9@crub>
On Thu, Mar 14, 2013 at 07:13:32PM +0100, Anatolij Gustschin wrote:
> On Thu, 14 Mar 2013 17:50:08 +0100
> Arnd Bergmann <arnd-r2nGTMty4D4@public.gmane.org> wrote:
>
> > On Thursday 14 March 2013 17:40:49 Anatolij Gustschin wrote:
> >
> > > +
> > > +struct mxcmci_reg_ops mxcmci_reg_ops = {
> > > + .read_l = mpcmci_readl,
> > > + .write_l = mpcmci_writel,
> > > + .read_w = mpcmci_readw,
> > > + .write_w = mpcmci_writew,
> > > +};
> > > +#else
> > > +struct mxcmci_reg_ops mxcmci_reg_ops;
> > > +#endif
> >
> > Should the struct be static?
>
> yes, it should.
>
> > > +static inline u32 mxcmci_readl(struct mxcmci_host *host, int reg)
> > > +{
> > > + if (host->reg_ops->read_l)
> > > + return host->reg_ops->read_l(host, reg);
> > > + else
> > > + return readl(host->base + reg);
> > > +}
> >
> > This seems a bit strange. I would suggest you either use the ops structure
> > all the time and provide an imx variant, or you make it completely
> > compile-time selected.
>
> I wanted to avoid additional levels of indirection and function calls
> on i.MX. If something like
>
> static inline u32 mxcmci_readl(struct mxcmci_host *host, int reg)
> {
> #if IS_ENABLED(CONFIG_PPC_MPC512x)
> return in_be32(host->base + reg);
> #else
> return readl(host->base + reg);
> #endif
I really wish we would have native endianess accessors...
>
> is acceptable, I'll use it.
Looks better to me.
> > > @@ -1026,24 +1115,33 @@ static int mxcmci_probe(struct platform_device *pdev)
> > > host->res = r;
> > > host->irq = irq;
> > >
> > > - host->clk_ipg = devm_clk_get(&pdev->dev, "ipg");
> > > - if (IS_ERR(host->clk_ipg)) {
> > > - ret = PTR_ERR(host->clk_ipg);
> > > - goto out_iounmap;
> > > - }
> > > + if (!is_mpc512x_mmc(host)) {
> > > + host->clk_ipg = devm_clk_get(&pdev->dev, "ipg");
> > > + if (IS_ERR(host->clk_ipg)) {
> > > + ret = PTR_ERR(host->clk_ipg);
> > > + goto out_iounmap;
> > > + }
> >
> > Does mpc512x have no clock management? I think it should still
> > work without modifications if CONFIG_HAVE_CLK is disabled.
> > In that case, devm_clk_get() will return NULL and we don't
> > error out here.
>
> It does have some clock management (a platform clock driver) and
> the platform selects CONFIG_HAVE_CLK. But we do not have "ipg"
> and "per" clocks on that platform, but "sdhc_clk" instead.
The clocks should be modelled after the input clocks the MMC controller
has, not after the clocks the SoC provides control for. So if you cannot
software control a clock then you should provide a dummy clock for it.
That said, 'ipg' is not a very good name for a mpc SoC,
something like 'bus' would probably be better.
Sascha
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
next prev parent reply other threads:[~2013-03-14 20:05 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-03-14 16:40 [PATCH 0/5] mmc: mxcmmc: add mpc512x support Anatolij Gustschin
2013-03-14 16:40 ` [PATCH 1/5] mmc: mxcmmc: add mpc512x SDHC support Anatolij Gustschin
2013-03-14 16:50 ` Arnd Bergmann
2013-03-14 18:13 ` Anatolij Gustschin
2013-03-14 20:05 ` Sascha Hauer [this message]
2013-03-14 22:52 ` Arnd Bergmann
2013-03-14 16:40 ` [PATCH 2/5] mmc: mxcmmc: use slot-gpio API for write-protect detection Anatolij Gustschin
2013-03-14 16:40 ` [PATCH 3/5] mmc: mxcmmc: constify mxcmci_devtype and fix build warning Anatolij Gustschin
2013-03-14 16:40 ` Anatolij Gustschin
2013-03-14 18:15 ` Anatolij Gustschin
2013-03-14 16:40 ` [PATCH 4/5] mmc: mxcmmc: enable DMA support on mpc512x Anatolij Gustschin
2013-03-14 20:11 ` Sascha Hauer
2013-03-14 21:18 ` Anatolij Gustschin
2013-03-14 16:40 ` [PATCH 5/5] mmc: mxcmmc: fix race conditions for host->req and host->data access Anatolij Gustschin
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=20130314200556.GR1906@pengutronix.de \
--to=s.hauer-bicnvbalz9megne8c9+irq@public.gmane.org \
--cc=agust-ynQEQJNshbs@public.gmane.org \
--cc=cjb-2X9k7bc8m7Mdnm+yROfE0A@public.gmane.org \
--cc=devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org \
--cc=linux-mmc-u79uwXL29TY76Z2rM5mHXA@public.gmane.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.