On Thu, Oct 17, 2013 at 7:13 AM, Mark Rutland <mark.rutland@xxxxxxx> wrote:
> On Wed, Oct 16, 2013 at 10:47:10PM +0100, Tim Kryger wrote:
>> Enable the external clock needed by the host controller during the
>> probe and disable it during the remove.
>
> This requires a biding document update.
The current best practice for declaring the association of a clock
with a consumer device is to embed the common clock bindings 'clocks'
property inside its node but this is not the only way it may be done.
Given that clk_get() still works for clocks found using string
matching, is it appropriate to mandate that all drivers that uses the
clk api mention the common clock bindings 'clocks' property in the
documentation for their device's binding?
> I note that the binding is already incomplete (it does not describe the
> interrupts or reg).
The current document reflects the standard for
Documentation/devicetree/bindings/mmc where normal properties are
described in mmc.txt and only the deviations described in vendor
specific files.
>>
>> Signed-off-by: Tim Kryger <tim.kryger@xxxxxxxxxx>
>> Reviewed-by: Markus Mayer <markus.mayer@xxxxxxxxxx>
>> Reviewed-by: Matt Porter <matt.porter@xxxxxxxxxx>
>> ---
>> drivers/mmc/host/sdhci-bcm-kona.c | 30 ++++++++++++++++++++++++++++--
>> 1 file changed, 28 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/mmc/host/sdhci-bcm-kona.c b/drivers/mmc/host/sdhci-bcm-kona.c
>> index 85472d3..91db099 100644
>> --- a/drivers/mmc/host/sdhci-bcm-kona.c
>> +++ b/drivers/mmc/host/sdhci-bcm-kona.c
>> @@ -54,6 +54,7 @@
>>
>> struct sdhci_bcm_kona_dev {
>> struct mutex write_lock; /* protect back to back writes */
>> + struct clk *external_clk;
>
> Is this the only clock input the unit has?
The SDHCI block only receives one clock.
> Are there any other external resources the device needs (e.g. gpios,
> regulators)?
Yes but the cd-gpio and vmmc/vqmmc regulators are handled by the
common SDHCI driver.
>
>> };
>>
>>
>> @@ -252,11 +253,29 @@ static int sdhci_bcm_kona_probe(struct platform_device *pdev)
>> mmc_of_parse(host->mmc);
>>
>> if (!host->mmc->f_max) {
>> - dev_err(&pdev->dev, "Missing max-freq for SDHCI cfg\n");
>> + dev_err(dev, "Missing max-freq for SDHCI cfg\n");
>
> This seems like an unrelated change.
Agreed. I will remove this change.
>> ret = -ENXIO;
>> goto err_pltfm_free;
>> }
>>
>> + /* Get and enable the external clock */
>> + kona_dev->external_clk = devm_clk_get(dev, NULL);
>> + if (IS_ERR(kona_dev->external_clk)) {
>> + dev_err(dev, "Failed to get external clock\n");
>> + ret = PTR_ERR(kona_dev->external_clk);
>> + goto err_pltfm_free;
>
> This seems like a pretty clear breakage of existing DTBs.
>
> Why?
The defconfig that builds this driver and DTBs currently sets
CONFIG_ARM_APPENDED_DTB=y so there isn't any actual breakage risk.
--
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
