From: Alexey Brodkin <Alexey.Brodkin@synopsys.com>
To: "jh80.chung@samsung.com" <jh80.chung@samsung.com>
Cc: "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"linux-mmc@vger.kernel.org" <linux-mmc@vger.kernel.org>,
"marex@denx.de" <marex@denx.de>,
"vladimir_zapolskiy@mentor.com" <vladimir_zapolskiy@mentor.com>,
"robh+dt@kernel.org" <robh+dt@kernel.org>,
"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>
Subject: Re: ARC dw-mshc binding compat string
Date: Mon, 28 Mar 2016 10:55:37 +0000 [thread overview]
Message-ID: <1459162537.4785.45.camel@synopsys.com> (raw)
In-Reply-To: <56F908A1.3070701@samsung.com>
Hi Jaehoon,
On Mon, 2016-03-28 at 19:34 +0900, Jaehoon Chung wrote:
> Hi,
[snip]
> > > > > > > >
> > > > > > > > That said, I would rather prefer to see "snps,dw-mshc" prefix on description
> > > > > > > > of an MMC controller found on SoCFPGA series, "altr,socfpga-dw-mshc" seems
> > > > > > > > to be redundant.
> Yes..it's redundant..i should be combined to "snps,dw-mshc".
So for socfpga platform compat string should be something like "snps,dw-mshc-socfpga" then?
> >
> > >
> > > >
> > > > >
> > > > > >
> > > > > > >
> > > > > > > According to drivers/mmc/host/dw_mmc-pltfm.c , the Altera SoCFPGA one
> > > > > > > "altr,socfpga-dw-mshc" and also Imagination Technology Pistacio one
> > > > > > > "img,pistachio-dw-mshc" need specialty bit (SDMMC_CMD_USE_HOLD_REG),
> > > > > > > while the stock one "snps,dw-mshc" does not. I am not sure if the ARC
> > > > > > > one needs it as well, but most likely yes.
> > > > > > >
> > > > > > > I wonder if that bit is needed on some particular version of the DWMMC
> > > > > > > core. In that case, should we have "snps,dw-mshc" and "snps,dw-mshc-vN"
> > > > > > > binding ? Or should we use DT property to discern the need for this bit ?
> > > > > > >
> > > > > > That's the most common way to take into account peculiarities, add
> > > > > > a property and handle it from the driver.
> > > > > And by "that" you mean which of those two I listed , the
> > > > > "snps,dw-mshc-vN" or adding new DT prop ?
> > > > >
> > > > I meant to add a new property, not a new compatible, but that's just
> > > > my experience.
> > > >
> > > > Let me say it __might__ happen that a particular change you need is
> > > > specific to a particular version of the DWMMC IP (query Synopsys
> > > > by the way), but more probably it might be e.g. the same IP version with
> > > > a different reduced or extended configuration or a minor fix/improvement
> > > > to the IP block without resulting version number bump.
> > > >
> > > > For example I don't remember that errata fixes in IP blocks result in
> > > > a new compatible, instead there are quite common optional "quirk"
> > > > properties for broken IPs -- e.g. check bindings/usb/dwc3.txt :)
> > > Right, this very much matches how I see it as well. Thanks for confirming.
> > >
> > > Alexey, can you tell us if the requirement for setting
> > > SDMMC_CMD_USE_HOLD_REG came with some new revision of the core or
> > > disappeared with some revision OR if this is some configuration
> > > option of the core during synthesis ?
> > Sorry for not following that discussion during my weekend but I'll try
> > to address all questions now.
> SDMMC_CMD_USE_HOLD_REG didn't come with new revision..It's using continuously.
> But it's difficult to use the generic feature..because it's considered the below things.
>
> If Card is SDR50/SDR104/DDR50 mode..
> 1) and phase shift of cclk_in_drv is 0 then SDMMC_CMD_USE_HOLD_REG bit is set to 0,
> 2) and phase shift of cclk_in_drv > 0 then SDMMC_CMD_USE_HOLD_REG bit is set to 1,
> If Card is SDR12/SDR25 mode, then this bit is set to 1.
So card type is also important here and for certain card type we don't need to
set SDMMC_CMD_USE_HOLD_REG, right?
> We need to check phase shift scheme..but as i knew, each SoC have been implemented differently for phase shift.
> (Phase shift have dependency to SoC.)
Given my assumption above we need to check 2 things:
* Card type
* SoC-specific implementation detail (phase shift scheme)
> And it have to check HCON register..there is IMPLEMENT_HOLD_REG(bit[22]).
> (It described whether IP have hold register or not)
Ah actually 3 things
+ IMPLEMENT_HOLD_REG
> I didn't read this thread entirely.
> I'm not sure what you have discussed..but my understanding is right..i recommend to use "snps,dw-mshc" for ARC compat
> string.
> Otherwise it need to add "dw_mmc-<SoC>.c". dw_mmc-pltfm.c should provide the basic dw-mmc controller functionality.
Hm, interesting looks like you already made some changes here:
http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=aaaaeb7a933471f6413ca44dd36efd57f2fa9429
So now driver checks if SoC has HOLD REG then SDMMC_CMD_USE_HOLD_REG will be set
(regardless card type).
And what's interesting and connected to this discussion since mentioned commit
there's no point in having both "altr,socfpga-dw-mshc" and "img,pistachio-dw-mshc"
compat strings because the do nothing now. I.e. it's time to replace both mentioned
compat strings with generic "snps,dw-mshc".
Anybody volunteers for that .dts* cleanup?
-Alexey
next prev parent reply other threads:[~2016-03-28 10:55 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-03-26 10:14 ARC dw-mshc binding compat string Marek Vasut
2016-03-26 17:26 ` Vladimir Zapolskiy
[not found] ` <56F6C639.5000301-nmGgyN9QBj3QT0dZR+AlfA@public.gmane.org>
2016-03-26 17:30 ` Marek Vasut
2016-03-26 17:46 ` Alexey Brodkin
2016-03-26 17:52 ` Vladimir Zapolskiy
[not found] ` <56F6CC68.5040408-nmGgyN9QBj3QT0dZR+AlfA@public.gmane.org>
2016-03-26 18:10 ` Marek Vasut
2016-03-26 18:16 ` Vladimir Zapolskiy
[not found] ` <56F6D1E9.3050606-nmGgyN9QBj3QT0dZR+AlfA@public.gmane.org>
2016-03-26 19:52 ` Marek Vasut
[not found] ` <56F6E860.8070207-ynQEQJNshbs@public.gmane.org>
2016-03-26 20:12 ` Vladimir Zapolskiy
[not found] ` <56F6ED41.5020908-nmGgyN9QBj3QT0dZR+AlfA@public.gmane.org>
2016-03-26 20:24 ` Marek Vasut
2016-03-28 9:37 ` Alexey Brodkin
[not found] ` <1459157818.4785.5.camel-HKixBCOQz3hWk0Htik3J/w@public.gmane.org>
2016-03-28 10:34 ` Jaehoon Chung
2016-03-28 10:55 ` Alexey Brodkin [this message]
2016-03-28 11:44 ` Jaehoon Chung
2016-03-28 12:43 ` Rob Herring
2016-03-28 12:52 ` Marek Vasut
2016-03-28 12:50 ` Marek Vasut
2016-03-28 16:16 ` Vladimir Zapolskiy
2016-03-28 19:00 ` Rob Herring
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=1459162537.4785.45.camel@synopsys.com \
--to=alexey.brodkin@synopsys.com \
--cc=devicetree@vger.kernel.org \
--cc=jh80.chung@samsung.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mmc@vger.kernel.org \
--cc=marex@denx.de \
--cc=robh+dt@kernel.org \
--cc=vladimir_zapolskiy@mentor.com \
/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;
as well as URLs for NNTP newsgroup(s).