From: sf84@laposte.net (Sebastian Frias)
To: linux-arm-kernel@lists.infradead.org
Subject: Adding a .platform_init callback to sdhci_arasan_ops
Date: Mon, 28 Nov 2016 12:20:42 +0100 [thread overview]
Message-ID: <66751ab5-59a4-ec30-07cd-44ca03694723@laposte.net> (raw)
In-Reply-To: <2a949ade-edd7-4690-cd6a-434ae1e663dc@intel.com>
Hi Adrian,
On 28/11/16 11:30, Adrian Hunter wrote:
> On 28/11/16 09:32, Michal Simek wrote:
>> +Sai for Xilinx perspective.
>>
>> On 25.11.2016 16:24, Sebastian Frias wrote:
>>> Hi,
>>>
>>> When using the Arasan SDHCI HW IP, there is a set of parameters called
>>> "Hardware initialized registers"
>>>
>>> (Table 7, Section "Pin Signals", page 56 of Arasan "SD3.0/SDIO3.0/eMMC4.4
>>> AHB Host Controller", revision 6.0 document)
>>>
>>> In some platforms those signals are connected to registers that need to
>>> be programmed at some point for proper driver/HW initialisation.
>>>
>>> I found that the 'struct sdhci_ops' contains a '.platform_init' callback
>>> that is called from within 'sdhci_pltfm_init', and that seems a good
>>> candidate for a place to program those registers (*).
>>>
>>> Do you agree?
>
> We already killed .platform_init
I just saw that, yet it was the perfect place for the HW initialisation I'm
talking about.
Any way we can restore it?
>
> What is wrong with sdhci_arasan_probe()?
Well, in 4.7 sdhci_arasan_probe() did not call of_match_device(), so I had
put a call to it just before sdhci_pltfm_init(), something like:
+static const struct of_device_id sdhci_arasan_of_match[] = {
+ {
+ .compatible = "arasan,sdhci-8.9a",
+ .data = &sdhci_arasan_ops,
+ },
+ {
+ .compatible = "arasan,sdhci-5.1",
+ .data = &sdhci_arasan_ops,
+ },
+ {
+ .compatible = "arasan,sdhci-4.9a",
+ .data = &sdhci_arasan_ops,
+ },
+ {
+ .compatible = "sigma,smp8734-sdio",
+ .data = &sdhci_arasan_tango4_ops,
+ },
+ { }
+};
+MODULE_DEVICE_TABLE(of, sdhci_arasan_of_match);
...
+ const struct of_device_id *match;
+
+ match = of_match_device(sdhci_arasan_of_match, &pdev->dev);
+ if (match)
+ sdhci_arasan_pdata.ops = match->data;
where 'sdhci_arasan_tango4_ops' contained a pointer to a .platform_init
callback.
However, as I stated earlier, an upstream commit:
commit 3ea4666e8d429223fbb39c1dccee7599ef7657d5
Author: Douglas Anderson <dianders@chromium.org>
Date: Mon Jun 20 10:56:47 2016 -0700
mmc: sdhci-of-arasan: Properly set corecfg_baseclkfreq on rk3399
changed struct 'sdhci_arasan_of_match' to convey different data, which
means that instead of having a generic way of accessing such data (such
as 'of_match_device()' and ".data" field), one must also check for
specific "compatible" strings to make sense of the ".data" field, such as
"rockchip,rk3399-sdhci-5.1"
With the current code:
- there's no 'of_match_device()' before 'sdhci_pltfm_init()'
- the sdhci_pltfm_init() call is made with a static 'sdhci_arasan_pdata'
struct (so it cannot be made dependent on the "compatible" string).
- since 'sdhci_arasan_pdata' is the same for all compatible devices, even
for those that require special handling, more "compatible" matching code is
required
- leading to spread "compatible" matching code; IMHO it would be cleaner if
the 'sdhci_arasan_probe()' code was generic, with just a generic "compatible"
matching, which then proceeded with specific initialisation and generic
initialisation.
In a nutshell, IMHO it would be better if adding support for more SoCs only
involved changing just 'sdhci_arasan_of_match' without the need to change
'sdhci_arasan_probe()'.
That would clearly separate the generic and "SoC"-specific code, thus allowing
better maintenance.
Does that makes sense to you guys?
Best regards,
Sebastian
>
>>>
>>> Best regards,
>>>
>>> Sebastian
>>>
>>>
>>> (*): This has been prototyped on 4.7 as working properly.
>>> However, upstream commit:
>>>
>>> commit 3ea4666e8d429223fbb39c1dccee7599ef7657d5
>>> Author: Douglas Anderson <dianders@chromium.org>
>>> Date: Mon Jun 20 10:56:47 2016 -0700
>>>
>>> mmc: sdhci-of-arasan: Properly set corecfg_baseclkfreq on rk3399
>>> ...
>>>
>>> could affect this solution because of the way the 'sdhci_arasan_of_match'
>>> struct is used after that commit.
>>>
>>
>>
>
next prev parent reply other threads:[~2016-11-28 11:20 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-11-25 15:24 Adding a .platform_init callback to sdhci_arasan_ops Sebastian Frias
2016-11-28 7:32 ` Michal Simek
2016-11-28 10:30 ` Adrian Hunter
2016-11-28 11:20 ` Sebastian Frias [this message]
2016-11-28 11:44 ` Adrian Hunter
2016-11-28 13:28 ` Sebastian Frias
2016-11-28 14:39 ` Sebastian Frias
2016-11-28 17:46 ` Doug Anderson
2016-11-28 19:32 ` Mason
2016-11-28 20:32 ` Doug Anderson
2016-12-05 12:28 ` Sebastian Frias
2016-12-05 16:13 ` Doug Anderson
2016-11-28 18:02 ` Doug Anderson
2016-12-05 12:29 ` Sebastian Frias
2016-12-05 16:30 ` Doug Anderson
2016-12-06 13:42 ` Sebastian Frias
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=66751ab5-59a4-ec30-07cd-44ca03694723@laposte.net \
--to=sf84@laposte.net \
--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